Re: [PATCH v3 09/11] power: supply: bq24190_charger: Get input_current_limit from our supplier

ice, which will be removed in a follow-up commit. > > Signed-off-by: Hans de Goede Acked-by: Tony Lindgren ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v3 08/11] power: supply: bq24190_charger: Export 5V boost converter as regulator

he consumer amongst other things). > > Signed-off-by: Hans de Goede This will make it easy for USB PHY drivers to implement USB host mode: Acked-by: Tony Lindgren ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdri

Re: [PATCH v2 08/14] power: supply: Add power_supply_set_input_current_limit_from_supplier helper

* Hans de Goede [170816 10:38]: > Hi, > > On 16-08-17 17:54, Tony Lindgren wrote: > > * Hans de Goede [170815 13:06]: > > > On some devices the USB Type-C port power (USB PD 2.0) negotiation is > > > done by a separate port-controller IC, while the current

Re: [PATCH v2 08/14] power: supply: Add power_supply_set_input_current_limit_from_supplier helper

* Hans de Goede [170815 13:06]: > On some devices the USB Type-C port power (USB PD 2.0) negotiation is > done by a separate port-controller IC, while the current limit is > controlled through another (charger) IC. > > It has been decided to model this by modelling the external Type-C > power bri

Re: [PATCH] mtd: nand: Rename nand.h into rawnand.h

ate a nand.h header > containing all common structure and function prototypes. For omap: Acked-by: Tony Lindgren ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 13/18] power: supply: bq24190_charger: Export 5V boost converter as regulator

* Hans de Goede [170806 05:37]: > Register the 5V boost converter as a regulator named > "regulator-bq24190-usb-vbus". Note the name includes "bq24190" because > the bq24190 family is also used on ACPI devices where there are no > device-tree phandles, so regulator_get will fallback to the name an

Re: [RFC] [PATCH 0/3] media: an attempt to refresh omap1_camera driver

* Hans Verkuil [160617 00:07]: > Hi Janusz, > > On 06/16/2016 07:21 PM, Janusz Krzysztofik wrote: > > As requested by media subsystem maintainers, here is an attempt to > > convert the omap1_camera driver to the vb2 framework. Also, conversion > > to the dmaengine framework, long awaited by ARM

Re: [PATCH 1/2] staging: tidspbridge: remove driver

file before it can be moved out of staging. Until someone can > put in the work to make the driver work again and move it out of > staging, remove it from the kernel. > > Signed-off-by: Kristina Martšenko > Cc: Omar Ramirez Luna > Cc: Suman Anna > Cc: Felipe Contreras

Re: [PATCH 2/2] ARM: OMAP2+: remove DSP platform device

ras This should not affect idling the DSP hardware block either, so Greg feel free to queue with the DSP removal patch: Acked-by: Tony Lindgren ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: Anybody working on tidspbridge?

* Suman Anna [140708 11:40]: > Hi Peter, > > On 07/08/2014 09:36 AM, Greg KH wrote: > > On Tue, Jul 08, 2014 at 03:03:58PM +0200, Peter Meerwald wrote: > >> Hello, > >> > Given the total lack of response here, I suggest just deleting the > driver. No one has ever done the "real work" t