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

imit from an > extcon device, which will be removed in a follow-up commit. > > Signed-off-by: Hans de Goede <hdego...@redhat.com> Acked-by: Tony Lindgren <t...@atomide.com> ___ 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

_data (containing > mappings for the consumer amongst other things). > > Signed-off-by: Hans de Goede <hdego...@redhat.com> This will make it easy for USB PHY drivers to implement USB host mode: Acked-by: Tony Lindgren <t...@atomide.com> ___ dev

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

* Hans de Goede <hdego...@redhat.com> [170816 10:38]: > Hi, > > On 16-08-17 17:54, Tony Lindgren wrote: > > * Hans de Goede <hdego...@redhat.com> [170815 13:06]: > > > On some devices the USB Type-C port power (USB PD 2.0) negotiation is > > >

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

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

include/linux/mtd/rawnand.h so we can later create a nand.h header > containing all common structure and function prototypes. For omap: Acked-by: Tony Lindgren <t...@atomide.com> ___ devel mailing list de...@linuxdriverproject.org http://driverdev.lin

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

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

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

...@copitl.com Cc: Suman Anna s-a...@ti.com Cc: Felipe Contreras felipe.contre...@gmail.com 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 t...@atomide.com

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

-a...@ti.com Cc: Felipe Contreras felipe.contre...@gmail.com Cc: Ohad Ben-Cohen o...@wizery.com Acked-by: Tony Lindgren t...@atomide.com ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: Anybody working on tidspbridge?

* Suman Anna s-a...@ti.com [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 that is