On Wed, May 04, 2016 at 08:59:23AM +0530, Manish Badarkhe wrote:
> > They're in the silicon, it's just a table of values that were put into
> > the silicon at design time. The defines would just be TABLE_ENTRY_1 or
> > whatever.
> Thanks for the clarification, In that case, comments/documentatio
On Wed, May 04, 2016 at 02:01:57PM +0200, Krzysztof Kozlowski wrote:
> This looks like pwrseq for MMC devices so the idea is to:
> 1. Move drivers/mmc/core/pwrseq* to separate directory
> (drivers/power/pwrseq ?)
> 2. Add support for pwrseq to USB core,
> 3. Add new pwrseq driver (or extend existi
On Thu, May 05, 2016 at 01:32:57PM +0800, Lu Baolu wrote:
> + gpiod = gpiod_get(dev, "gpio", GPIOD_ASIS);
> + if (IS_ERR(gpiod))
> + return ERR_PTR(-ENODEV);
> + config->gpio = desc_to_gpio(gpiod);
> + config->enable_high = device_property_read_bool(dev,
> +
On Fri, May 20, 2016 at 02:24:14PM +0200, Arnd Bergmann wrote:
> On Thursday 19 May 2016 14:08:43 Andy Gross wrote:
> > I'd rather do something like what we did for the GSBI. It needed to
> > change some phy related bits in the TCSR as well. We defined the TCSR
> > as a syscon, with binding docu
On Tue, Jun 07, 2016 at 09:42:48PM -0700, Greg Kroah-Hartman wrote:
> On Thu, Jun 02, 2016 at 09:37:23AM +0800, Lu Baolu wrote:
> > Add support to retrieve fixed voltage configure information through
> > ACPI interface. This is needed for Intel Bay Trail devices, where a
> > GPIO is used to contro
On Thu, Jun 09, 2016 at 11:44:18AM +0200, Krzysztof Kozlowski wrote:
> Few drivers have a need of getting regulator supplies without knowing
> their names:
> 1. The Simple Framebuffer driver works on setup provided by bootloader
>(outside of scope of kernel);
> 2. Generic power sequence driver
On Thu, Jun 09, 2016 at 02:50:26PM +0200, Rafael J. Wysocki wrote:
> On Thu, Jun 9, 2016 at 12:29 PM, Mark Brown wrote:
> > The external interface shouldn't be DT specific, the Intel people are
> > busy importing all of DT into ACPI
> Well, not really.
> If you ar
On Mon, Jun 20, 2016 at 11:16:07AM -0500, Rob Herring wrote:
> On Mon, Jun 20, 2016 at 07:26:51PM +0800, Peter Chen wrote:
> > If the node has property "power-sequence", the pwrseq core will create
> > related platform device, and the driver under pwrseq driver will handle
> > power sequence stuff
On Tue, Jun 21, 2016 at 01:30:49PM +0300, Felipe Balbi wrote:
> Baolin Wang writes:
> > @@ -607,8 +647,31 @@ static int wm831x_power_probe(struct platform_device
> > *pdev)
> > }
> > }
> > + if (wm831x_pdata && wm831x_pdata->usb_gadget) {
> > + power->usb_charger =
>
On Tue, Jun 21, 2016 at 02:50:27PM +0300, Felipe Balbi wrote:
> Mark Brown writes:
> > The wm831x has no DT support currently.
> okay, perhaps its time to add it.
The only platform using it would need the DT connector overlays
completing in order to be able to convert to DT. I&
On Fri, Nov 16, 2012 at 12:23:43PM +0200, Roger Quadros wrote:
> How is this supposed to work? How does phandle supplied in vin-supply
> map to config->input_supply?
You should provide a separate property to name the supply, or just pick
a fixed name in the fixed voltage driver.
signature.asc
D
On Thu, Nov 17, 2016 at 05:46:13PM +1100, NeilBrown wrote:
> On Thu, Nov 17 2016, Mark Brown wrote:
> > To me that's pretty much what's being done here, the code just happens
> > to sit in USB instead but fundamentally it's just a blob of helper code,
> > y
On Tue, Nov 22, 2016 at 09:40:07AM +1100, NeilBrown wrote:
> I agree that the question of where the responsibility for information
> aggregation lies is open for discussion. If fact all details on how
> things should work are always open for discussion.
> I don't agree that this is the main differ
On Fri, Sep 09, 2016 at 09:13:31AM +1000, NeilBrown wrote:
> Conceptually, the PHY is separate from the power manager and a solution
> which recognises that will be more universal.
The wm831x driver in the patch series is an example of such hardware -
it is purely a power manager, it has no USB P
On Sat, Sep 10, 2016 at 07:57:26AM +1000, NeilBrown wrote:
> On Fri, Sep 09 2016, Mark Brown wrote:
> > The wm831x driver in the patch series is an example of such hardware -
> > it is purely a power manager, it has no USB PHY hardware at all. It's a
> Th
On Mon, Sep 12, 2016 at 03:27:18PM +0200, NeilBrown wrote:
> On Mon, Sep 12 2016, Mark Brown wrote:
> > It's no worse than any other board file situation - if someone has that
> > problem they get to fix it.
> My point is that the present design does not appear to scal
On Tue, Sep 13, 2016 at 10:00:28AM +0200, NeilBrown wrote:
> On Mon, Sep 12 2016, Mark Brown wrote:
> > That's not actually 100% clear to me - for what the wm831x is doing it
> > probably *does* want the higher limit. This is a system inflow limit
> > (as it should
On Wed, Sep 14, 2016 at 04:11:58PM +0200, NeilBrown wrote:
> On Wed, Sep 14 2016, Mark Brown wrote:
> > Yes, the idea is that the charger will back off charging and stop
> > entirely if the rest of the system is consuming too much power to allow
> > it to continue effecti
On Wed, Sep 14, 2016 at 07:50:00PM +0200, NeilBrown wrote:
> On Wed, Sep 14 2016, Mark Brown wrote:
> Ah my mistake, sorry.
> When earlier you said:
> > It's a
> > current limiter intended to sit in lin
On Thu, Sep 15, 2016 at 12:43:41PM +0100, Build bot for Mark Brown wrote:
Today's -next fails to build both arm and arm64 allmodconfigs due to:
> arm64-allmodconfig
> ERROR: "musb_root_disconnect" [drivers/usb/musb/sunxi.ko] undefined!
>
On Fri, Sep 16, 2016 at 05:47:01PM +0200, Greg Kroah-Hartman wrote:
> On Fri, Sep 16, 2016 at 04:59:36PM +0200, Hans de Goede wrote:
> > +EXPORT_SYMBOL_GPL(musb_root_disconnect);
> Does this fix a build error somehow? Who reported it?
Yes, the sunxi driver uses this symbol and the build bots re
On Thu, Sep 22, 2016 at 06:53:12PM +0800, Baolin Wang wrote:
> From: Badhri Jagan Sridharan
>
> Some USB managament on userspace (like Android system) rely on the uevents
> generated by the composition driver to generate user notifications. Thus this
> patch adds uevents to be generated whenever
On Thu, Sep 22, 2016 at 03:38:30PM +0200, Greg KH wrote:
> On Thu, Sep 22, 2016 at 08:41:09PM +0800, Baolin Wang wrote:
> > OK. I will talk with Badhri if I can upstream these.
> That's not an issue, you can keep the "From:" line on it, if you got it
> in a legal way, and then just have your sign
On Thu, Sep 22, 2016 at 08:30:16AM -0500, Bin Liu wrote:
> On Wed, Sep 21, 2016 at 03:51:33PM -0500, Bin Liu wrote:
> > Applied. Thanks.
> Removed it from my tree, since Greg already picked it.
It's not showing in today's -next...
signature.asc
Description: PGP signature
On Thu, Sep 22, 2016 at 07:28:42PM +0200, Greg Kroah-Hartman wrote:
> On Thu, Sep 22, 2016 at 06:15:26PM +0100, Mark Brown wrote:
> > On Thu, Sep 22, 2016 at 08:30:16AM -0500, Bin Liu wrote:
> > > Removed it from my tree, since Greg already picked it.
> > It's
On Mon, Oct 24, 2016 at 06:46:26PM +0200, ahas...@baylibre.com wrote:
> From: Axel Haslam
>
> Some regulator supplies have an over-current pin that is
> activated when the hw detects an over current condition.
> When this happens, the hardware enters a current limited
> mode.
Please don't mix ra
On Mon, Oct 24, 2016 at 06:46:26PM +0200, ahas...@baylibre.com wrote:
> + if (ret) {
> + pr_err("Failed to request irq: %d\n", ret);
dev_err()
> +++ b/include/linux/regulator/consumer.h
> @@ -74,6 +74,10 @@
> * the most noisy and may not be able to h
On Mon, Oct 24, 2016 at 08:11:40PM +0200, Axel Haslam wrote:
> On Mon, Oct 24, 2016 at 7:53 PM, Mark Brown wrote:
> > does it make sense to report this as a mode, we don't report other error
> > conditions as modes but instead use REGULATOR_STATUS_ with the
> > get_sta
On Tue, Oct 25, 2016 at 02:55:48PM +0200, Axel Haslam wrote:
> To be able to use regulator to handle the overcurrent pin, i need to be able
> to somehow retrieve the over current pin state from the regulator driver.
What makes you say that, none of the existing users need this?
> As i was tryi
On Fri, Oct 28, 2016 at 08:51:41PM +0800, Baolin Wang wrote:
> On 28 October 2016 at 06:00, NeilBrown wrote:
> > 1/ I think we agreed that it doesn't make sense for there to be
> > two chargers registered in a system.
> Yes, until now...
> > However usb_charger_register() still allows that, a
On Mon, Nov 14, 2016 at 03:21:13PM +1100, NeilBrown wrote:
> On Thu, Nov 10 2016, Baolin Wang wrote:
> > Fourth, we need integrate all charger plugin/out
> > event in one framework, not from extcon, maybe type-c in future.
> Why not extcon? Given that a charger is connected by an external
> conn
On Tue, Nov 15, 2016 at 08:35:13AM +1100, NeilBrown wrote:
> On Mon, Nov 14 2016, Mark Brown wrote:
> > Conflating the two seems like the whole point here. We're looking for
> > something that sits between the power supply code and the USB code and
> > tells the p
On Tue, Feb 02, 2016 at 02:02:30PM -0600, Bjorn Helgaas wrote:
> Remove some gpio and regulator #includes when they can be replaced by
> trivial forward struct declarations. Also move a linux/gpio/consumer.h
> #include from a header to the single .c files that uses it.
Please don't CC me on patch
On Mon, Jan 04, 2016 at 11:04:26AM +0800, Baolin Wang wrote:
> Currently the Linux kernel does not provide any standard integration of this
> feature that integrates the USB subsystem with the system power regulation
> provided by PMICs meaning that either vendors must add this in their kernels
>
On Tue, Jul 05, 2016 at 10:15:03AM +0100, Build bot for Mark Brown wrote:
For the past little while both arm and arm64 allmodconfig builds have
been failing with:
> drivers/built-in.o: In function `nbu2ss_drv_probe':
> binder.c:(.text+0x29438c): undefined reference to `usb_ep_set_maxp
On Tue, Jul 26, 2016 at 02:38:00PM +0200, Arnd Bergmann wrote:
> The build report doesn't actually show the error unfortunately, but
> I'm pretty sure it's this one:
> drivers/staging/built-in.o: In function `nbu2ss_drv_probe':
> (.text+0x2428): undefined reference to `usb_ep_set_maxpacke
On Tue, Sep 06, 2016 at 10:45:19AM +0300, Felipe Balbi wrote:
> Stefan Agner writes:
> > According to the device tree bindings the vcc-supply is optional.
This is nonsense unless the device can work without this supply. Given
that the supply is called VCC that doesn't seem entirely likely.
> >
On Tue, Sep 06, 2016 at 11:01:15AM -0700, Stefan Agner wrote:
> On 2016-09-06 01:22, Mark Brown wrote:
> > This is nonsense unless the device can work without this supply. Given
> > that the supply is called VCC that doesn't seem entirely likely.
> Afaik it is kind o
On Mon, Feb 29, 2016 at 11:22:12PM +0900, Mark Brown wrote:
> On Mon, Jan 04, 2016 at 11:04:26AM +0800, Baolin Wang wrote:
I see Felipe is no longer at TI so his e-mail was bouncing - let's
resend this with his kernel.org address:
> > Currently the Linux kernel does not provid
On Wed, Mar 16, 2016 at 01:05:27PM +0200, Felipe Balbi wrote:
> Mark Brown writes:
> > On Mon, Feb 29, 2016 at 11:22:12PM +0900, Mark Brown wrote:
> >> On Mon, Jan 04, 2016 at 11:04:26AM +0800, Baolin Wang wrote:
> > I see Felipe is no longer at TI so his e-mail was bou
On Tue, Mar 29, 2016 at 10:05:23AM +0800, Baolin Wang wrote:
> Yes, The user 'wm831x_power' did not implement any callbacks in
> 'usb_charger_detect_type()' function, but in
> 'usb_charger_detect_type()' function it just supplies different
> callbacks to get the charger type with simple logic. Any
On Mon, Mar 28, 2016 at 03:13:51PM +0800, Peter Chen wrote:
> On Mon, Mar 28, 2016 at 02:51:40PM +0800, Baolin Wang wrote:
> > > I am afraid I still not find the user (udc driver) for this framework, I
> > > would
> > > like to see how udc driver block the enumeration until the charger
> > > det
On Wed, Mar 30, 2016 at 01:09:00PM +0300, Felipe Balbi wrote:
> Baolin Wang writes:
> > +#include
> > +#include
> > +#include
> > +#include
> not very nice to depend on either of or platform_device here. What about
> PCI-based devices ?
The header inclusion shouldn't be conditional though.
On Thu, Mar 31, 2016 at 09:42:58AM +0300, Felipe Balbi wrote:
> Baolin Wang writes:
> > I want to use bus structure to manage the charger device. Maybe choose
> > class to manage them?
> I guess a class would fit better in this case.
IIRC Greg didn't want new classes?
signature.asc
Descriptio
On Fri, Apr 01, 2016 at 08:43:10AM +0300, Felipe Balbi wrote:
> Mark Brown writes:
> > IIRC Greg didn't want new classes?
> good point. Still, this doesn't seem to fit a but_type IMO.
It does in this new world order. IIRC on an earlier round of review
there was some code
On Mon, Apr 04, 2016 at 01:47:50PM +0300, Felipe Balbi wrote:
> Mark Brown writes:
> > It does in this new world order. IIRC on an earlier round of review
> > there was some code that didn't use a bus but that got complaints that
> > it was trying to reimplement the
On Tue, Apr 05, 2016 at 04:12:22PM +0800, Peter Chen wrote:
> On Tue, Apr 05, 2016 at 03:54:31PM +0800, Baolin Wang wrote:
> > Hi Peter,
> > Yeah, this patchset did not give an example to read charger type from
> > PMIC registers. (Cause now the user 'wm831x_power' don't need this.)
> > But I thin
On Tue, Apr 05, 2016 at 05:43:20PM +0800, Peter Chen wrote:
> On Tue, Apr 05, 2016 at 05:34:02PM +0800, Baolin Wang wrote:
> > Mark, could you please address Peter's comments about if the the
> > wm831x can charge more than 1500mA for DCP? (I have no environment to
> > test wm831x) Thanks.
> I do
On Wed, Apr 06, 2016 at 09:15:26AM +0800, Peter Chen wrote:
> > > No, this comment is common one, but only for SW detection. Eg, when
> > > the PMIC tells you it is a SDP, you can't notify to charger IC about
> > > 500mA at once, you need to do it after host allows you to do it.
> > Note that thi
On Mon, Apr 25, 2016 at 04:04:49PM +0800, Lu Baolu wrote:
> This is needed to handle the GPIO connected USB vcc pin found on
> Intel Baytrail devices.
In what way is this needed? The we defualt to using the driver name if
no platform ID table, AFAICT this is just restating the same string?
sig
On Mon, Apr 25, 2016 at 04:04:50PM +0800, Lu Baolu wrote:
> + ret = device_property_read_string(dev, "gpio-name", &gpio_name);
> + if (!ret) {
> + gpiod = gpiod_get(dev, gpio_name, GPIOD_ASIS);
> + if (!IS_ERR(gpiod)) {
This doesn't look like it's a standard ACPI b
On Tue, Apr 26, 2016 at 10:24:56AM +0800, Lu Baolu wrote:
> The GPIO name might be different in different use cases. For my case,
> it is "vbus_en", but other cases should use the different name.
> On ACPI compatible platforms, GPIO resources are reported via ACPI
> tables and (devm_)gpiod_get()
On Wed, Apr 27, 2016 at 08:37:20AM +0300, Felipe Balbi wrote:
> Jisheng Zhang writes:
> > + vbus = devm_regulator_get(&pdev->dev, "vbus");
> devm_regulator_get_optional() ??
Does USB work without a VBUS? Unless the answer is yes then I'd expect
this to be just a normal regulator_get().
>
>
On Wed, Apr 27, 2016 at 01:25:27PM +0300, Felipe Balbi wrote:
> Mark Brown writes:
> > this to be just a normal regulator_get().
> jokes aside, this regulator is optional because not all platforms
> require a SW controlled regulator, no ? Will normal regulator_get() give
> us
On Wed, Apr 27, 2016 at 09:54:10AM +0800, Lu Baolu wrote:
> Please refer to Documentation/acpi/gpio-properties.txt.
That's not visibly what your driver is doing, that is also recommending
using a static name which is what I'm asking for.
> > Why does the device care?It's requesting the GPIO in
>
On Wed, Apr 27, 2016 at 06:25:16PM +0800, Jisheng Zhang wrote:
> On Wed, 27 Apr 2016 10:57:39 +0100 Mark Brown wrote:
> > On Wed, Apr 27, 2016 at 08:37:20AM +0300, Felipe Balbi wrote:
> > > > + vbus = devm_regulator_get(&pdev->dev, "vbus")
On Thu, Apr 28, 2016 at 01:55:35PM +0800, Lu Baolu wrote:
> How about below code?
> + gpiod = gpiod_get(dev, "vbus_en", GPIOD_ASIS);
> + if (IS_ERR(gpiod))
> + return PTR_ERR(gpiod);
> +
> + config->gpio = desc_to_gpio(gpiod);
> + config->enable_high = device
On Fri, Apr 29, 2016 at 12:59:49PM +0200, Krzysztof Kozlowski wrote:
> +++ b/Documentation/devicetree/bindings/usb/usb3503.txt
> @@ -24,6 +24,7 @@ Optional properties:
> pins (optional, if not provided, driver will not set rate of the
> REFCLK signal and assume that a value from the pr
-by: Mark Brown
---
drivers/regulator/max77686-regulator.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/regulator/max77686-regulator.c
b/drivers/regulator/max77686-regulator.c
index d1ab6a4da88f..ac4fa581e0a5 100644
--- a/drivers/regulator/max77686-regulator.c
+++ b/driv
On Fri, Apr 29, 2016 at 01:55:14PM +0200, Krzysztof Kozlowski wrote:
> On 04/29/2016 01:30 PM, Mark Brown wrote:
> > Supplies are only optional if they may be physically absent. In this
> > case it's possible that on device regulators may be used instead, a
> > patte
On Mon, May 02, 2016 at 11:49:12AM +0200, Krzysztof Kozlowski wrote:
> This VDD regulator supply actually is not a usb3503 USB HUB regulator
> supply... but a supply to the LAN attached to this HUB. Regulator off/on
> is needed for LAN to show up. The hub will show up with typical reset
> (which i
On Fri, Apr 29, 2016 at 02:26:32PM +0800, Lu Baolu wrote:
> + gpiod = gpiod_get(dev, "vbus_en", GPIOD_ASIS);
> + if (IS_ERR(gpiod))
> + return PTR_ERR(gpiod);
This is clearly an inappropriate name for the signal in generic code,
it's specific to your use case.
signature.asc
On Tue, May 03, 2016 at 09:30:48AM +0530, Manish Badarkhe wrote:
> On Tue, May 3, 2016 at 9:00 AM, Baolin Wang wrote:
> > +static const unsigned int wm831x_usb_limits[] = {
> > + 0,
> > + 2,
> > + 100,
> > + 500,
> > + 900,
> > + 1500,
> > + 1800,
> > +
On Tue, May 03, 2016 at 09:43:58AM +0800, Lu Baolu wrote:
> On 05/02/2016 07:00 PM, Mark Brown wrote:
> > On Fri, Apr 29, 2016 at 02:26:32PM +0800, Lu Baolu wrote:
> >> + gpiod = gpiod_get(dev, "vbus_en", GPIOD_ASIS);
> >> + if (IS_ERR(gpiod))
> >>
On Mon, Aug 06, 2012 at 03:14:36PM +0200, Lukasz Majewski wrote:
> > On Mon, Aug 06, 2012 at 06:12:05PM +0800, Peiyong Feng wrote:
> > > I got a kernel panic when try hsotg of ok6410 which is based on
> > > s3c6410:
> As you said, you are using the ok6410. And it is "based" on the s3c6410
> CPU. S
On Tue, Jun 18, 2013 at 11:34:26AM +0300, Felipe Balbi wrote:
> MUSB alone has 8 different arch choices. Before, it used to be that core
> driver was dependendent on all of them, so whenever someone wanted to
> build MUSB for another arch, they had to introdude their glue code and
> modify the dep
On Tue, Jul 23, 2013 at 10:37:05AM -0400, Alan Stern wrote:
> On Tue, 23 Jul 2013, Tomasz Figa wrote:
> > > > Okay. Are PHYs _always_ platform devices?
> > > They can be i2c, spi or any other device types as well.
> In those other cases, presumably there is no platform data associated
> with th
On Tue, Jul 23, 2013 at 10:37:11AM -0700, Greg KH wrote:
> On Tue, Jul 23, 2013 at 06:50:29PM +0200, Tomasz Figa wrote:
> > I fully agree that a simple, single string will not scale even in some, not
> > so uncommon cases, but there is already a lot of existing lookup solutions
> > over the kern
On Tue, Jul 23, 2013 at 11:01:10AM -0700, Greg KH wrote:
> On Tue, Jul 23, 2013 at 06:44:56PM +0100, Mark Brown wrote:
> > What are the problems you are seeing with doing things with lookups?
> You don't "know" the id of the device you are looking up, due to
>
On Tue, Jul 23, 2013 at 12:44:23PM -0700, Greg KH wrote:
> On Tue, Jul 23, 2013 at 08:31:05PM +0100, Mark Brown wrote:
> > statement. In any case this is why the APIs doing lookups do the
> > lookups in the context of the requesting device - devices ask for
> > whatever
On Wed, Jul 24, 2013 at 08:32:03PM +0200, Arnd Bergmann wrote:
> Sorry for jumping in to the middle of the discussion, but why does a *new*
> framework even bother defining an interface for board files?
> Can't we just drop any interfaces for platform data passing in the phy
> framework and put t
On Thu, Jul 25, 2013 at 01:00:49PM +0200, Arnd Bergmann wrote:
> I'm not saying that we can't support legacy board files with the common
> PHY framework, but I'd expect things to be much easier if we focus on those
> platforms that are actively being worked on for now, to bring an end to the
> poi
On Wed, Jul 24, 2013 at 01:52:19AM +0200, Tomasz Figa wrote:
> Changes since v2:
> - Reworked to use new PLL registration method introduced by Yadwinder
>Singh Brar's patch series:
>( http://thread.gmane.org/gmane.linux.kernel.samsung-soc/20041 )
I'm not able to test this series since th
On Tue, Jul 23, 2013 at 01:49:22AM +0200, Tomasz Figa wrote:
> This patch modifies s3c64xx DMA driver to prepare and unprepare clocks
> in addition to enableind and disabling, since it is required by common
> clock framework.
Tested-by: Mark Brown
signature.asc
Description: Digital signature
On Wed, Jul 31, 2013 at 10:46:45AM +0200, Uwe Kleine-König wrote:
> OK, so the possible problem is that remove is called while the irq is
> still active. That means you have to assert that all resources the irq
> handler is using (e.g. ioremap, clk_prepare_enable) are only freed
> *after* the irq
On Wed, Jul 31, 2013 at 05:54:11AM -0400, Tejun Heo wrote:
> On Wed, Jul 31, 2013 at 11:44:34AM +0200, Uwe Kleine-König wrote:
> > > > OK, so the possible problem is that remove is called while the irq is
> > > > still active. That means you have to assert that all resources the irq
> If your dri
On Wed, Jul 31, 2013 at 07:32:44AM -0400, Tejun Heo wrote:
> Yeah, if all resources are allocated using devm - note that you can
> hook in non-devm resources using devres_alloc() - all resources which
> would be necessary for the interrupt handler would have been allocated
> before the irq was all
On Wed, Jul 31, 2013 at 07:55:27AM -0400, Tejun Heo wrote:
> If you have DMA / IRQ / command engine deactivations in devm path
> which often is the case with full conversions, freeing any resources
> including DMA areas and host private data in the wrong order is a
> horrible idea. It's worse as
On Wed, Jul 31, 2013 at 09:42:15AM -0400, Tejun Heo wrote:
> On Wed, Jul 31, 2013 at 02:27:08PM +0100, Mark Brown wrote:
> > It's really only interrupts that affect most devices - if there's DMA or
> > anything going on after the remove() then as you said earlier the dri
On Wed, Jul 31, 2013 at 10:07:58AM -0400, Tejun Heo wrote:
> On Wed, Jul 31, 2013 at 02:57:51PM +0100, Mark Brown wrote:
> > That's the only API I've ever heard of doing that. Everything else is
> > just using it to do deallocation.
> I'm not sure why or wha
On Wed, Jul 31, 2013 at 11:29:32AM -0400, Tejun Heo wrote:
> Yeah, sure, thank you very much for your input. It is of course
> strictly ordered and the documentation needs to be updated.
While I note the way you're saying this given the widespread adoption I
think there's a bit more effort neede
From: Andy Green
You might have CONFIG_PM, but you might not have CONFIG_SUSPEND, in which
case these are unused.
Signed-off-by: Andy Green
Signed-off-by: Mark Brown
---
drivers/usb/dwc3/dwc3-pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/dwc3/dwc3
On Tue, Aug 06, 2013 at 10:35:52PM -0300, Fabio Estevam wrote:
> On Tue, Aug 6, 2013 at 12:49 PM, Mark Brown wrote:
> > From: Andy Green
> >
> > You might have CONFIG_PM, but you might not have CONFIG_SUSPEND, in which
> > case these are unused.
> >
> > Si
From: Mark Brown
The intn and connect GPIO properties are swapped in the code which will
cause failures at runtime if these are connected, fix the code.
There are currently no in-tree users of this device to check or update.
Signed-off-by: Mark Brown
---
drivers/usb/misc/usb3503.c | 4
From: Mark Brown
Saves us a bit of code.
Signed-off-by: Mark Brown
---
This depends on my previous patch "usb: misc: Fix swapped properties in
usb3503 DT parsing".
drivers/usb/misc/usb3503.c | 42 +++---
1 file changed, 7 insertions(+), 35
From: Mark Brown
If someone provided meaningful error codes from reset() we should tell the
user what they were.
Signed-off-by: Mark Brown
---
drivers/usb/core/hcd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index
From: Mark Brown
Systems with the common clock API need clk_prepare() as well as the enable
step.
Signed-off-by: Mark Brown
---
drivers/usb/phy/phy-nop.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/phy/phy-nop.c b/drivers/usb/phy/phy-nop.c
index f52b7f8
From: Mark Brown
Since there is no runtime interface for changing modes this is probably
the most sensible default.
Signed-off-by: Mark Brown
---
drivers/usb/misc/usb3503.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/misc/usb3503.c b/drivers/usb/misc
From: Mark Brown
If the connect signal is pulled high then the device will start up meaning
that if we just pull it high on probe then the device will start running
prior to the configuration being written out. Fix this by pulling the GPIO
low when we reset and only pulling it high when
From: Mark Brown
There are no software visible differences that I am aware of but in case
any are discovered allow the DTS to specify exactly which device is
present.
Signed-off-by: Mark Brown
---
Documentation/devicetree/bindings/usb/usb3503.txt | 2 +-
drivers/usb/misc/usb3503.c
From: Mark Brown
The /RESET GPIO is not manipulated from atomic context so support GPIOs
that can't be written from atomic context by using _cansleep().
---
drivers/usb/misc/usb3503.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/misc/usb3503.c b/driver
From: Mark Brown
The intn and connect GPIO properties are swapped in the code which will
cause failures at runtime if these are connected, fix the code.
There are currently no in-tree users of this device to check or update.
Signed-off-by: Mark Brown
---
drivers/usb/misc/usb3503.c | 4
From: Mark Brown
In preparation for supporting operation without an I2C control interface
factor out the I2C-specific parts of the probe routine from those that
don't do any register I/O.
Signed-off-by: Mark Brown
---
drivers/usb/misc/usb3503.c
From: Mark Brown
Signed-off-by: Mark Brown
---
drivers/usb/misc/usb3503.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/misc/usb3503.c b/drivers/usb/misc/usb3503.c
index ca0f789..777102e 100644
--- a/drivers/usb/misc/usb3503.c
+++ b/drivers/usb/misc
From: Mark Brown
Refactor so that register writes for configuration are only performed if
the device has a regmap provided and also register as a platform driver.
This allows the driver to be used to manage GPIO based control of the
device.
Signed-off-by: Mark Brown
Cc: devicet
From: Mark Brown
The binding document says that all properties are required but in fact
almost all are optional (and should be) - update the document to reflect
this.
Signed-off-by: Mark Brown
Cc: devicet...@vger.kernel.org
---
Documentation/devicetree/bindings/usb/usb3503.txt | 2 ++
1 file
From: Mark Brown
This will give access to the diagnostic infrastructure regmap has but
the main point is to support future refactoring.
Signed-off-by: Mark Brown
---
drivers/usb/misc/Kconfig | 1 +
drivers/usb/misc/usb3503.c | 93 ++
2 files
From: Mark Brown
Saves us a bit of code.
Signed-off-by: Mark Brown
---
drivers/usb/misc/usb3503.c | 42 +++---
1 file changed, 7 insertions(+), 35 deletions(-)
diff --git a/drivers/usb/misc/usb3503.c b/drivers/usb/misc/usb3503.c
index 8c06eb2..2e9e100
On Fri, Aug 09, 2013 at 05:38:57PM +0300, Felipe Balbi wrote:
> On Thu, Aug 08, 2013 at 12:35:04PM +0100, Mark Brown wrote:
> > Systems with the common clock API need clk_prepare() as well as the enable
> > step.
> clk_prepare() is done on probe()... -ECONFUSED
Ah, so
From: Mark Brown
Ensure that the definition of ax88172a_info matches the declaration seen
by users and silence sparse warnings about symbols without declarations
in the global namespace by moving the declaration into the shared header
asix.h.
Signed-off-by: Mark Brown
---
drivers/net/usb
1 - 100 of 197 matches
Mail list logo
