Re: [PATCH v2 2/3] spi: add FTDI MPSSE SPI controller driver

On Sat, Nov 10, 2018 at 11:39:58AM +0100, Anatolij Gustschin wrote: > This v2 patch is the only patch of the original series that was > changed, I didn't resend whole series to avoid spamming the lists. Please don't do this, the numbering for a patch series only makes sense for ordering the

Re: [PATCH v2 2/3] spi: add FTDI MPSSE SPI controller driver

On Fri, Nov 09, 2018 at 08:53:56AM +0100, Anatolij Gustschin wrote: > Add SPI bus controller driver for FTDI MPSSE mode. This driver > is supposed to be used together with the FT232H interface driver > for FPGA configuration in drivers/usb/misc/ft232h-intf.c which > adds an mpsse spi platform

Re: [PATCH/RFC 0/6] Allow compile-testing NO_DMA

#2. Having to add an explicit dependency on > HAS_DMA here is cumbersome, and hinders compile-testing. Thanks for doing this, hopefully it'll make everyone's life easier! Reviwed-by: Mark Brown <broo...@kernel.org> signature.asc Description: PGP signature

Re: next/master boot: 264 boots: 62 failed, 199 passed with 3 conflicts (next-20171109)

On Thu, Nov 09, 2017 at 01:45:02PM +, Mark Brown wrote: > On Thu, Nov 09, 2017 at 04:14:26AM -0800, kernelci.org bot wrote: > > Today's -next fails to boot a bcm2836-rpi-2-b on any config in kernelci, > it was working yesterday: > > > bcm2835_defconfig: > &

Re: next/master boot: 264 boots: 62 failed, 199 passed with 3 conflicts (next-20171109)

On Thu, Nov 09, 2017 at 04:14:26AM -0800, kernelci.org bot wrote: Today's -next fails to boot a bcm2836-rpi-2-b on any config in kernelci, it was working yesterday: > bcm2835_defconfig: > bcm2836-rpi-2-b: > lab-collabora: new failure (last pass: next-20171107) The boot

Re: linux-next: manual merge of the usb-gadget tree with the usb tree

On Wed, Oct 18, 2017 at 08:40:04AM -0700, Kees Cook wrote: > On Wed, Oct 18, 2017 at 7:49 AM, Mark Brown <broo...@kernel.org> wrote: > > I fixed it up with the USB version and can carry the fix as necessary. This > > is now fixed as far as linux-next is concerned

linux-next: manual merge of the usb-gadget tree with the usb tree

Hi Felipe, Today's linux-next merge of the usb-gadget tree got a conflict in: drivers/usb/phy/phy-isp1301-omap.c between commit: 4c13fec1ba55595 ("usb: isp1301-omap: Convert timers to use timer_setup()") from the usb tree and commit: 687f272c6b0e89d ("usb: phy: omap: use setup_timer()

linux-next: manual merge of the usb-gadget tree with the usb tree

Hi Felipe, Today's linux-next merge of the usb-gadget tree got a conflict in: drivers/usb/gadget/udc/snps_udc_core.c between commit: 29bce57723351f63d ("usb/gadget/snps_udc_core: Convert timers to use timer_setup()") from the usb tree and commit: 46b614affda8667f9 ("usb: gadget: udc:

Re: [PATCH v2 14/27] ASoC: blackfin: Convert to the new PCM ops

On Thu, Jun 01, 2017 at 10:58:37PM +0200, Takashi Iwai wrote: > Replace the copy and the silence ops with the new PCM ops. > In AC97 and I2S-TDM mode, we need to convert back to frames, but > otherwise the conversion is pretty straightforward. Acked-by: Mark Brown <broo..

Re: [PATCH v2 02/27] ALSA: pcm: Introduce copy_user, copy_kernel and fill_silence ops

e deprecated and removed later once when all callers > are converted. Acked-by: Mark Brown <broo...@kernel.org> signature.asc Description: PGP signature

Re: [PATCH 3/3] mfd: twl: move header file out of I2C realm

On Mon, May 22, 2017 at 12:28:12PM +0200, Wolfram Sang wrote: > If you were not CCed on the other patches, then you are likely not > listed as a maintainer for them? Right, but it does mean that the people who only get a subset of patches are missing context for how things are expected to be

Re: [PATCH 3/3] mfd: twl: move header file out of I2C realm

On Mon, May 22, 2017 at 12:02:10AM +0200, Wolfram Sang wrote: > include/linux/i2c is not for client devices. Move the header file to a > more appropriate location. Acked-by: Mark Brown <broo...@kernel.org> I'm missing the rest of the series and/or the cover letter... signature.asc

Re: [PATCH v18 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

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

Re: [PATCH v18 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

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, > > you could

Re: [PATCH v18 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

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 power

Re: [PATCH v18 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

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 >

Re: [PATCH v18 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

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()

Re: [PATCH/RFT v2 09/17] regulator: fixed: Add over current event

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

Re: [PATCH/RFT v2 09/17] regulator: fixed: Add over current event

On Mon, Oct 24, 2016 at 08:11:40PM +0200, Axel Haslam wrote: > On Mon, Oct 24, 2016 at 7:53 PM, Mark Brown <broo...@kernel.org> 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_ wi

Re: [PATCH/RFT v2 09/17] regulator: fixed: Add over current event

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

Re: [PATCH/RFT v2 09/17] regulator: fixed: Add over current event

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 >

Re: [PATCH v2] musb: Export musb_root_disconnect for use in modules

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 not

Re: [PATCH v2] musb: Export musb_root_disconnect for use in modules

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

Re: [PATCH v2] usb: gadget: Add uevent to notify userspace

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

Re: [PATCH] usb: gadget: Add uevent to notify userspace

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

Re: [PATCH] musb: Export musb_root_disconnect for use in modules

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: next-20160915 build: 2 failures 16 warnings (next-20160915)

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! > arm-a

Re: [PATCH v16 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

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 line wit

Re: [PATCH v16 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

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

Re: [PATCH v16 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

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 b

Re: [PATCH v16 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

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 scale bey

Re: [PATCH v16 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

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 > The &qu

Re: [PATCH v16 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

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

Re: [PATCH] usb: phy: generic: request regulator optionally

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 of a g

Re: [PATCH] usb: phy: generic: request regulator optionally

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

Re: master build: 2 failures 3 warnings (v4.7-1605-ge658052)

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

Re: next-20160705 build: 2 failures 6 warnings (next-20160705)

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_maxpacket

Re: [PATCH v12 4/4] power: wm831x_power: Support USB charger current limit management

On Tue, Jun 21, 2016 at 02:50:27PM +0300, Felipe Balbi wrote: > Mark Brown <broo...@kernel.org> 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 abl

Re: [PATCH v12 4/4] power: wm831x_power: Support USB charger current limit management

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) { > > +

Re: [PATCH 08/12] doc: binding: pwrseq-usb-generic: add binding doc for generic usb power sequence driver

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

Re: [RFC v4 01/14] regulator: of: Add helper for getting all supplies

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 <broo...@kernel.org> wrote: > > The external interface shouldn't be DT specific, the Intel people are > > busy importing all of DT into ACPI > Wel

Re: [RFC v4 01/14] regulator: of: Add helper for getting all supplies

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

Re: [PATCH v10 1/7] regulator: fixed: add support for ACPI interface

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

Re: [RFC 4/8] usb: phy: move TCSR driver into new file

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

Re: [PATCH v8 1/7] regulator: fixed: add support for ACPI interface

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, > +

Re: [RFT PATCH 1/3] usb: misc: usb3503: Fix HUB mode after bootloader initialization

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

Re: [RESEND PATCH v10 4/4] power: wm831x_power: Support USB charger current limit management

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,

Re: [PATCH v7 1/7] regulator: fixed: add support for ACPI interface

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))

Re: [RESEND PATCH v10 4/4] power: wm831x_power: Support USB charger current limit management

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,

Re: [PATCH v7 1/7] regulator: fixed: add support for ACPI interface

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

Re: [RFT PATCH 1/3] usb: misc: usb3503: Fix HUB mode after bootloader initialization

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

Re: [RFT PATCH 1/3] usb: misc: usb3503: Fix HUB mode after bootloader initialization

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 > > patter

Applied "regulator: max77686: Configure enable time to properly handle regulator enable" to the regulator tree

Krzysztof Kozlowski <k.kozlow...@samsung.com> Signed-off-by: Mark Brown <broo...@kernel.org> --- 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 d1ab6

Re: [RFT PATCH 1/3] usb: misc: usb3503: Fix HUB mode after bootloader initialization

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

Re: [PATCH v6 04/10] regulator: fixed: add support for ACPI interface

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 =

Re: [RESEND PATCH v2 7/7] usb: xhci: plat: add vbus regulator control

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(>dev, "vbus"); > > > d

Re: [PATCH v6 04/10] regulator: fixed: add support for ACPI interface

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

Re: [RESEND PATCH v2 7/7] usb: xhci: plat: add vbus regulator control

On Wed, Apr 27, 2016 at 01:25:27PM +0300, Felipe Balbi wrote: > Mark Brown <broo...@kernel.org> 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

Re: [RESEND PATCH v2 7/7] usb: xhci: plat: add vbus regulator control

On Wed, Apr 27, 2016 at 08:37:20AM +0300, Felipe Balbi wrote: > Jisheng Zhang writes: > > + vbus = devm_regulator_get(>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

Re: [PATCH v6 04/10] regulator: fixed: add support for ACPI interface

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()

Re: [PATCH v6 04/10] regulator: fixed: add support for ACPI interface

On Mon, Apr 25, 2016 at 04:04:50PM +0800, Lu Baolu wrote: > + ret = device_property_read_string(dev, "gpio-name", _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

Re: [PATCH v6 03/10] regulator: fixed: add device binding for platform device

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?

Re: [PATCH v9 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

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

Re: [PATCH v9 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

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

Re: [PATCH v9 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

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

Re: [PATCH v7 1/4] gadget: Introduce the usb charger framework

On Mon, Apr 04, 2016 at 01:47:50PM +0300, Felipe Balbi wrote: > Mark Brown <broo...@kernel.org> 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 tr

Re: [PATCH v7 1/4] gadget: Introduce the usb charger framework

On Fri, Apr 01, 2016 at 08:43:10AM +0300, Felipe Balbi wrote: > Mark Brown <broo...@kernel.org> 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 t

Re: [PATCH v7 1/4] gadget: Introduce the usb charger framework

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?

Re: [PATCH v7 1/4] gadget: Introduce the usb charger framework

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

Re: [PATCH v8 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

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 > > >

Re: [PATCH v7 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

On Wed, Mar 16, 2016 at 01:05:27PM +0200, Felipe Balbi wrote: > Mark Brown <broo...@kernel.org> 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

Re: [PATCH v7 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

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 provide any

Re: [PATCH v7 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

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 >

Re: [PATCH 0/3] USB: PHY: minor include cleanups

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

Re: [PATCH v5 1/5] gadget: Introduce the notifier functions

On Fri, Nov 06, 2015 at 08:56:44AM -0800, Greg KH wrote: > On Fri, Nov 06, 2015 at 07:35:10PM +0800, Baolin Wang wrote: > > Thus this patch adds a notifier mechanism for usb gadget to report a > > event to usb charger when the usb gadget state is changed. > I thought we said we did not want

Re: [GIT PULL] On-demand device probing

On Sat, Oct 24, 2015 at 04:17:12PM +0200, Rafael J. Wysocki wrote: > Well, I'm not quite sure why exactly everyone is so focused on probing here. Probe deferral is really noisy even if it's working fine on a given system so it's constantly being highlighted to people in a way that other issues

Re: Alternative approach to solve the deferred probe (was: [GIT PULL] On-demand device probing)

On Tue, Oct 20, 2015 at 04:46:56PM +0100, Russell King - ARM Linux wrote: > Something like this. I haven't put a lot of effort into it to change all > the places which return an -EPROBE_DEFER, and it also looks like we need > some helpers to report when we have only an device_node (or should

Re: [GIT PULL] On-demand device probing

On Thu, Oct 22, 2015 at 04:02:13PM +0100, Russell King - ARM Linux wrote: > If it was such a problem, then in the _eight_ days that this has been > discussed so far, _someone_ would have sent some data showing the > problem. I think the fact is, there is no data. > Someone prove me wrong.

Re: [GIT PULL] On-demand device probing

On Wed, Oct 21, 2015 at 08:59:51AM -0700, Frank Rowand wrote: > On 10/19/2015 5:34 AM, Tomeu Vizoso wrote: > > To be clear, I was saying that this series should NOT affect total > > boot times much. > I'm confused. If I understood correctly, improving boot time was > the key justification for

Re: [GIT PULL] On-demand device probing

On Wed, Oct 21, 2015 at 11:18:08AM -0700, Frank Rowand wrote: > On 10/21/2015 9:27 AM, Mark Brown wrote: > > Overall boot time and time to get some individual built in component up > > and running aren't the same thing - what this'll do is get things up > > more in the l

Re: [GIT PULL] On-demand device probing

On Tue, Oct 20, 2015 at 01:14:46PM -0400, Alan Stern wrote: > On Tue, 20 Oct 2015, Tomeu Vizoso wrote: > > This iteration of the series would make this quite easy, as > > dependencies are calculated before probes are attempted: > > https://lkml.org/lkml/2015/6/17/311 > But what Rafael is

Re: [GIT PULL] On-demand device probing

On Tue, Oct 20, 2015 at 10:40:03AM -0400, Alan Stern wrote: > Furthermore, that applies only to devices that use synchronous suspend. > Async suspend is becoming common, and there the only restrictions are > parent-child relations plus whatever explicit requirements that drivers > impose by

Re: [GIT PULL] On-demand device probing

On Mon, Oct 19, 2015 at 10:44:41AM +0100, David Woodhouse wrote: > On Sun, 2015-10-18 at 20:53 +0100, Mark Brown wrote: > > Do you mean firmware rather than bus here? I think that's the confusion > > I have... > Certainly, if it literally is adding of_* calls th

Re: [GIT PULL] On-demand device probing

On Mon, Oct 19, 2015 at 01:47:50PM +0100, David Woodhouse wrote: > On Mon, 2015-10-19 at 07:35 -0500, Rob Herring wrote: > > See version 2 of the series[1] which did that. It became obvious that > > was pointless because the call paths ended up looking like this: > > Generic subsystem code -> DT

Re: [GIT PULL] On-demand device probing

On Mon, Oct 19, 2015 at 04:29:40PM +0100, David Woodhouse wrote: > On Mon, 2015-10-19 at 15:50 +0100, Mark Brown wrote: > > > But the point I'm making is that we are working towards *fixing* that, > > > and *not* using DT-specific code in places where we should be using t

Re: [GIT PULL] On-demand device probing

On Sat, Oct 17, 2015 at 08:47:09AM -0700, Greg Kroah-Hartman wrote: > On Sat, Oct 17, 2015 at 10:04:55AM -0500, Rob Herring wrote: > > I think Linus W, Mark B, and I all said a similar thing initially in > > that dependencies should be handled in the driver core. We went down > > the path of

Re: [GIT PULL] On-demand device probing

On Sun, Oct 18, 2015 at 12:37:57PM -0700, Greg Kroah-Hartman wrote: > On Sun, Oct 18, 2015 at 08:29:31PM +0100, Mark Brown wrote: > > On Fri, Oct 16, 2015 at 11:57:50PM -0700, Greg Kroah-Hartman wrote: > > > I can't see adding calls like this all over the tree just to solve a

Re: [GIT PULL] On-demand device probing

On Fri, Oct 16, 2015 at 11:57:50PM -0700, Greg Kroah-Hartman wrote: > I can't see adding calls like this all over the tree just to solve a > bus-specific problem, you are adding of_* calls where they aren't > needed, or wanted, at all. This isn't bus specific, I'm not sure what makes you say

Re: [GIT PULL] On-demand device probing

On Wed, Oct 14, 2015 at 10:34:00AM +0200, Tomeu Vizoso wrote: > git+ssh://git.collabora.co.uk/git/user/tomeu/linux.git > on-demand-probes-for-next In don't think that's the URL you intended to use (also everything looks word wrapped here)? signature.asc Description: PGP signature

Re: [PATCH v4 1/5] gadget: Introduce the notifier functions

On Fri, Oct 09, 2015 at 04:17:27PM -0500, Felipe Balbi wrote: > Mark, when can we try to have a discussion about how to get this > upstream ? It seems like designing everything in the mailing list will > just take forever. Any ideas ? Can we take this off-list? I'm in the UK, Baolin is in China

Re: [PATCH v4 1/5] gadget: Introduce the notifier functions

On Mon, Oct 05, 2015 at 10:15:11AM -0500, Felipe Balbi wrote: > On Sun, Oct 04, 2015 at 11:55:06PM +0100, Mark Brown wrote: > > The trouble is getting traction on adoption. Vendors have a habit of doing > > things like finding problems and rather than reportin

Re: [PATCH v4 1/5] gadget: Introduce the notifier functions

On Fri, Oct 02, 2015 at 02:11:25PM -0500, Felipe Balbi wrote: > On Fri, Oct 02, 2015 at 07:49:09PM +0100, Mark Brown wrote: > > On Fri, Oct 02, 2015 at 12:23:11PM -0500, Felipe Balbi wrote: > > > > Things more difficult, if nothing else it means we need to get whatever > &

Re: [PATCH v4 1/5] gadget: Introduce the notifier functions

On Thu, Oct 01, 2015 at 12:58:49PM -0500, Felipe Balbi wrote: > On Thu, Oct 01, 2015 at 06:43:08PM +0100, Mark Brown wrote: > > On Thu, Oct 01, 2015 at 12:29:32PM -0500, Felipe Balbi wrote: > > > Frankly, I wanted all of this to be decided in userland with the > >

Re: [PATCH v4 1/5] gadget: Introduce the notifier functions

On Fri, Oct 02, 2015 at 12:23:11PM -0500, Felipe Balbi wrote: > On Fri, Oct 02, 2015 at 05:47:43PM +0100, Mark Brown wrote: > > Can you elaborate on what the difficulties are and how punting to > > userspace helps? If anything I'd expect punting to userspace to make > the dif

Re: [PATCH v4 1/5] gadget: Introduce the notifier functions

On Thu, Oct 01, 2015 at 12:29:32PM -0500, Felipe Balbi wrote: > Frankly, I wanted all of this to be decided in userland with the > kernel just providing notification and basic safety checks (we don't > want to allow a bogus userspace daemon frying anybody's devices). What's the advantage of

Re: [PATCH v4 5/5] power: wm831x_power: Support USB charger current limit management

without drawing more current than specified from others. Signed-off-by: Mark Brown broo...@kernel.org Signed-off-by: Baolin Wang baolin.w...@linaro.org When people (like Charles and Lee have) have reviewed a change you should add any tags they gave when you resend the change so they don't have

Re: [PATCH v2 3/3] power: wm831x_power: Support USB charger current limit management

On Wed, Aug 19, 2015 at 08:02:37AM +0800, Peter Chen wrote: Below code may be correct for the goal you expressed. for (i = 0; i ARRAY_SIZE(wm831x_usb_limits); i++) { if (limit = wm831x_usb_limits[i] wm831x_usb_limits[best] wm831x_usb_limits[i])

Re: [PATCH v2 3/3] power: wm831x_power: Support USB charger current limit management

On Tue, Aug 18, 2015 at 01:20:12PM +0800, Peter Chen wrote: ok, I just had suspected below function's correctness, after looking it again, it always set 1800 as charging limit, does it be expected? + /* Find the highest supported limit */ + best = 0; + for (i = 0; i

Re: [PATCH v2 3/3] power: wm831x_power: Support USB charger current limit management

On Mon, Aug 17, 2015 at 06:58:16PM -0500, Felipe Balbi wrote: On Mon, Aug 17, 2015 at 10:26:23AM -0700, Mark Brown wrote: On Mon, Aug 17, 2015 at 09:07:08AM +0800, Peter Chen wrote: On Fri, Aug 14, 2015 at 05:47:46PM +0800, Baolin Wang wrote: + if (wm831x_pdata wm831x_pdata

Re: [PATCH v2 3/3] power: wm831x_power: Support USB charger current limit management

On Mon, Aug 17, 2015 at 09:07:08AM +0800, Peter Chen wrote: On Fri, Aug 14, 2015 at 05:47:46PM +0800, Baolin Wang wrote: + 1500, + 1800, + 550, +}; Why 550 is the last, but not 1800? You'd have to ask the hardware engineers who designed the chip. I suspect it's because 550 was

  1   2   >