Use devm_* helpers in the probe function to simplify the error path and
the remove path.
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
Cc: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
now that no UDC driver relies on the extra
'driver' argument to ->udc_stop(), we can
safely remove it.
This commit is based on previous work by
Robert Baldyga <r.baldyga@samsung.com> which
can be found at [1]; however that patch turned
out to have a high probability of regressing
many UDC drivers because of a blind search & replace
s/driver/$udc->driver/ which caused the 'driver'
argument to stop_activity() to be a valid non-NULL
pointer when it should be NULL, thus causing UDCs
to mistakenly call gadget driver's ->disconnect()
callback.
[1] http://markmail.org/message/x5zneg4xea4zntab
Acked-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Currently, we're printing gadget driver name when
registering and UDC name when unregistering. Standardize
on always printing gadget driver name.
Signed-off-by: Felipe Balbi <balbi@ti.com>
now that we provide generic register/unregister
debugging messages from udc-core, we can remove
the same messages from this driver.
Signed-off-by: Felipe Balbi <balbi@ti.com>
now that we provide generic register/unregister
debugging messages from udc-core, we can remove
the same messages from this driver.
Signed-off-by: Felipe Balbi <balbi@ti.com>
now that we provide generic register/unregister
debugging messages from udc-core, we can remove
the same messages from this driver.
Signed-off-by: Felipe Balbi <balbi@ti.com>
now that we provide generic register/unregister
debugging messages from udc-core, we can remove
the same messages from this driver.
Signed-off-by: Felipe Balbi <balbi@ti.com>
now that we provide generic register/unregister
debugging messages from udc-core, we can remove
the same messages from this driver.
Signed-off-by: Felipe Balbi <balbi@ti.com>
now that we provide generic register/unregister
debugging messages from udc-core, we can remove
the same messages from this driver.
Signed-off-by: Felipe Balbi <balbi@ti.com>
now that we provide generic register/unregister
debugging messages from udc-core, we can remove
the same messages from this driver.
Signed-off-by: Felipe Balbi <balbi@ti.com>
now that we provide generic register/unregister
debugging messages from udc-core, we can remove
the same messages from this driver.
Signed-off-by: Felipe Balbi <balbi@ti.com>
now that we provide generic register/unregister
debugging messages from udc-core, we can remove
the same messages from this driver.
Signed-off-by: Felipe Balbi <balbi@ti.com>
We know that our udc points to our gadget and our
gadget_driver, simplify the interface by passing
a single argument.
Signed-off-by: Felipe Balbi <balbi@ti.com>
future patches will remove the extra 'driver'
argument to ->udc_stop(), in order to do that,
we must make sure that our UDC does not rely
on it first.
Signed-off-by: Felipe Balbi <balbi@ti.com>
future patches will remove the extra 'driver'
argument to ->udc_stop(), in order to do that,
we must make sure that our UDC does not rely
on it first.
Signed-off-by: Felipe Balbi <balbi@ti.com>
future patches will remove the extra 'driver'
argument to ->udc_stop(), in order to do that,
we must make sure that our UDC does not rely
on it first.
Signed-off-by: Felipe Balbi <balbi@ti.com>
future patches will remove the extra 'driver'
argument to ->udc_stop(), in order to do that,
we must make sure that our UDC does not rely
on it first.
Signed-off-by: Felipe Balbi <balbi@ti.com>
future patches will remove the extra 'driver'
argument to ->udc_stop(), in order to do that,
we must make sure that our UDC does not rely
on it first.
Signed-off-by: Felipe Balbi <balbi@ti.com>
future patches will remove the extra 'driver'
argument to ->udc_stop(), in order to do that,
we must make sure that our UDC does not rely
on it first.
Signed-off-by: Felipe Balbi <balbi@ti.com>
future patches will remove the extra 'driver'
argument to ->udc_stop(), in order to do that,
we must make sure that our UDC does not rely
on it first.
Signed-off-by: Felipe Balbi <balbi@ti.com>
future patches will remove the extra 'driver'
argument to ->udc_stop(), in order to do that,
we must make sure that our UDC does not rely
on it first.
Signed-off-by: Felipe Balbi <balbi@ti.com>
future patches will remove the extra 'driver'
argument to ->udc_stop(), in order to do that,
we must make sure that our UDC does not rely
on it first.
Signed-off-by: Felipe Balbi <balbi@ti.com>
future patches will remove the extra 'driver'
argument to ->udc_stop(), in order to do that,
we must make sure that our UDC does not rely
on it first.
Signed-off-by: Felipe Balbi <balbi@ti.com>
future patches will remove the extra 'driver'
argument to ->udc_stop(), in order to do that,
we must make sure that our UDC does not rely
on it first.
Signed-off-by: Felipe Balbi <balbi@ti.com>
future patches will remove the extra 'driver'
argument to ->udc_stop(), in order to do that,
we must make sure that our UDC does not rely
on it first.
Signed-off-by: Felipe Balbi <balbi@ti.com>
future patches will remove the extra 'driver'
argument to ->udc_stop(), in order to do that,
we must make sure that our UDC does not rely
on it first.
Signed-off-by: Felipe Balbi <balbi@ti.com>
The drivers should use dmaengine_terminate_all() or dmaengine_slave_config()
API instead of accessing the device_control which will be deprecated soon
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
The memory subsystem has already had similar message for it.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
The memory subsystem has already had similar message for it.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
The memory subsystem has already had similar message for it.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
The memory subsystem has already had similar message for it.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
The memory subsystem has already had similar message for it.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
The memory subsystem has already had similar message for it.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
The memory subsystem has already had similar message for it.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
The memory subsystem has already had similar message for it.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
The memory subsystem has already had similar message for it.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
The memory subsystem has already had similar message for it.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
The memory subsystem has already had similar message for it.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
The memory subsystem has already had similar message for it.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
The memory subsystem has already had similar message for it.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
The memory subsystem has already had similar message for it.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
The memory subsystem has already had similar message for it.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
The memory subsystem has already had similar message for it.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
The memory subsystem has already had similar message for it.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
The memory subsystem has already had similar message for it.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Some gadget/function drivers might want to do
improper request recycling by allocating a single
request from one particular endpoint and queueing
it to another completely unrelated endpoint.
One such case was found with f_loopback.c.
To prevent such cases from happening again, let's
WARN() so we get a loud enough failure and persuade
users to report errors.
Signed-off-by: Felipe Balbi <balbi@ti.com>
whenever we get a Disconnect Interrupt, we should
make sure to update out udc state to NOT_ATTACHED,
otherwise sysfs will show wrong values.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Robert Jarzmik
Felipe Balbi
Vinod Koul
Peter Chen