Re: [PATCH 1/2] power: supply: Add fwnode pointer to power_supply_config struct

[Sebastian Reichel]

Hi,

On Tue, May 22, 2018 at 04:16:23PM +0100, Adam Thomson wrote:
> To allow users of the power supply framework to be hw description
> agnostic, this commit adds the ability to pass a fwnode pointer,
> via the power_supply_config structure, to the initialisation code
> of the core, instead of explicitly specifying of_ndoe. If that
> fwnode pointer is provided then it will automatically resolve down
> to of_node on platforms which support it, otherwise it will be NULL.
> 
> In the future, when ACPI support is added, this can be modified to
> accommodate ACPI without the need to change calling code which
> already provides the fwnode handle in this manner.
> 
> Signed-off-by: Adam Thomson <adam.thomson.opensou...@diasemi.com>
> Suggested-by: Heikki Krogerus <heikki.kroge...@linux.intel.com>
> ---

Reviewed-by: Sebastian Reichel <sebastian.reic...@collabora.co.uk>

-- Sebastian

>  drivers/power/supply/power_supply_core.c | 4 +++-
>  include/linux/power_supply.h | 2 ++
>  2 files changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/power/supply/power_supply_core.c 
> b/drivers/power/supply/power_supply_core.c
> index ecd68c2..f57ab0a 100644
> --- a/drivers/power/supply/power_supply_core.c
> +++ b/drivers/power/supply/power_supply_core.c
> @@ -19,6 +19,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include "power_supply.h"
>  
> @@ -874,7 +875,8 @@ static void psy_unregister_cooler(struct power_supply 
> *psy)
>   psy->desc = desc;
>   if (cfg) {
>   psy->drv_data = cfg->drv_data;
> - psy->of_node = cfg->of_node;
> + psy->of_node =
> + cfg->fwnode ? to_of_node(cfg->fwnode) : cfg->of_node;
>   psy->supplied_to = cfg->supplied_to;
>   psy->num_supplicants = cfg->num_supplicants;
>   }
> diff --git a/include/linux/power_supply.h b/include/linux/power_supply.h
> index 0c9a572..b21c4bd9 100644
> --- a/include/linux/power_supply.h
> +++ b/include/linux/power_supply.h
> @@ -199,6 +199,8 @@ enum power_supply_notifier_events {
>  /* Run-time specific power supply configuration */
>  struct power_supply_config {
>   struct device_node *of_node;
> + struct fwnode_handle *fwnode;
> +
>   /* Driver private data */
>   void *drv_data;
>  
> -- 
> 1.9.1
> 


signature.asc
Description: PGP signature

Re: [PATCH v8 0/6] typec: tcpm: Add sink side support for PPS

[Sebastian Reichel]

Hi,

On Thu, Apr 26, 2018 at 09:33:26AM +0200, Greg Kroah-Hartman wrote:
> On Wed, Apr 25, 2018 at 02:30:45PM +0200, Greg Kroah-Hartman wrote:
> > On Wed, Apr 25, 2018 at 01:26:33AM +0200, Sebastian Reichel wrote:
> > > Hi Greg,
> > > 
> > > On Tue, Apr 24, 2018 at 03:57:49PM +0200, Greg Kroah-Hartman wrote:
> > > > On Mon, Apr 23, 2018 at 03:10:55PM +0100, Adam Thomson wrote:
> > > > > This patch set adds sink side support for the PPS feature introduced 
> > > > > in the
> > > > > USB PD 3.0 specification.
> > > > > 
> > > > > The source PPS supply is represented using the Power Supply framework 
> > > > > to provide
> > > > > access and control APIs for dealing with it's operating voltage and 
> > > > > current,
> > > > > and switching between a standard PDO and PPS APDO operation. During 
> > > > > standard PDO
> > > > > operation the voltage and current is read-only, but for APDO PPS 
> > > > > these are
> > > > > writable as well to allow for control.
> > > > > 
> > > > > It should be noted that the keepalive for PPS is not handled within 
> > > > > TCPM. The
> > > > > expectation is that the external user will be required to ensure 
> > > > > re-requests
> > > > > occur regularly to ensure PPS remains and the source does not hard 
> > > > > reset.
> > > > 
> > > > Sebastian, any objection from me taking this series through my USB tree?
> > > 
> > > I currently have the power-supply bits in a local branch for
> > > testing. I would like to have this in the power-supply
> > > tree, since there is at least one pending driver which could
> > > directly use the newly introduced usb_type.
> > > 
> > > I can either provide an immutable branch with a signed tag, or
> > > you can merged it and provide me an immutable branch.
> > > 
> > > If you merge it via the USB tree patch 2-4 are
> > > 
> > > Reviewed-by: Sebastian Reichel <sebastian.reic...@collabora.co.uk>
> > 
> > I've applied these to a testing branch in my usb tree, and if they
> > survive the 0-day bot, I'll move them to a branch that you can pull from
> > that will not change.
> > 
> > Oh, I had to add a follow-on patch to fix up a gcc warning that really
> > wasn't a warning, but it saves us problems of people complaining about
> > it.
> 
> All looks good now.
> 
> Here's the signed tag you can pull from, with the full information of
> all of the other USB patches that you are going to be getting here
> (sorry about that).

Thanks, merged.

-- Sebastian


signature.asc
Description: PGP signature

Re: [PATCH v8 0/6] typec: tcpm: Add sink side support for PPS

[Sebastian Reichel]

Hi Greg,

On Tue, Apr 24, 2018 at 03:57:49PM +0200, Greg Kroah-Hartman wrote:
> On Mon, Apr 23, 2018 at 03:10:55PM +0100, Adam Thomson wrote:
> > This patch set adds sink side support for the PPS feature introduced in the
> > USB PD 3.0 specification.
> > 
> > The source PPS supply is represented using the Power Supply framework to 
> > provide
> > access and control APIs for dealing with it's operating voltage and current,
> > and switching between a standard PDO and PPS APDO operation. During 
> > standard PDO
> > operation the voltage and current is read-only, but for APDO PPS these are
> > writable as well to allow for control.
> > 
> > It should be noted that the keepalive for PPS is not handled within TCPM. 
> > The
> > expectation is that the external user will be required to ensure re-requests
> > occur regularly to ensure PPS remains and the source does not hard reset.
> 
> Sebastian, any objection from me taking this series through my USB tree?

I currently have the power-supply bits in a local branch for
testing. I would like to have this in the power-supply
tree, since there is at least one pending driver which could
directly use the newly introduced usb_type.

I can either provide an immutable branch with a signed tag, or
you can merged it and provide me an immutable branch.

If you merge it via the USB tree patch 2-4 are

Reviewed-by: Sebastian Reichel <sebastian.reic...@collabora.co.uk>

-- Sebastian


signature.asc
Description: PGP signature

Re: [PATCHv4] phy: mapphone-mdm6600: Add USB PHY driver for MDM6600 on Droid 4

[Sebastian Reichel]

Hi,

On Fri, Mar 23, 2018 at 11:54:55AM +0100, Pavel Machek wrote:
> Hi!
> 
> > > > Do you have the related dts patches picked from next?
> > > > 
> > > > fdd192037fce ("ARM: dts: omap4-droid4: Fix USB PHY port naming")
> > > > e5b9fd7bdeb5 ("ARM: dts: omap4-droid4: Configure MDM6600 USB PHY")
> > > > 
> > > > But yeah all you need to do is have phy-mapphone-mdm6600 and
> > > > ohci-platform loaded and then ifconfig should show four wwan
> > > > interfaces being added.
> > > 
> > > ifconfig? I thought I should get /dev/ttyUSB0..3?
> > 
> > I believe they are QMI via qmi_wwan, not TTYs.
> 
> Well, qmicli expects device path... and I see nothing on ifconfig. Any
> idea how the device would be named?
> 
> But I believe it just does not work, see the qcserial experiment with
> new_id below.

Dan is right, you need qmi_wwan driver. qmicli expects
/dev/cdc-wdm device. I use this on Droid 4:

qmicli -d /dev/cdc-wdm0 --some-other-option

-- Sebastian

> 
> Best regards,
>   Pavel
>   
> > > But qcserial driver does not bind to that. If I attempt to force it:
> > > 
> > > root@devuan:/sys/bus/usb-serial/drivers/qcserial# lsusb
> > > Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> > > Bus 002 Device 002: ID 22b8:2a70 Motorola PCS
> > > Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> > > root@devuan:/sys/bus/usb-serial/drivers/qcserial# echo "22b8 2a70" >
> > > new_id
> > > [ 2059.267730] usb 2-1: unknown number of interfaces: 9
> > > [ 2059.272949] usb 2-1: unknown number of interfaces: 9
> > > [ 2059.278045] usb 2-1: unknown number of interfaces: 9
> > > [ 2059.283233] usb 2-1: unknown number of interfaces: 9
> > > [ 2059.288330] usb 2-1: unknown number of interfaces: 9
> > > [ 2059.293457] usb 2-1: unknown number of interfaces: 9
> > > [ 2059.298553] usb 2-1: unknown number of interfaces: 9
> > > [ 2059.303680] usb 2-1: unknown number of interfaces: 9
> > > [ 2059.308776] usb 2-1: unknown number of interfaces: 9
> > > 
> > > I don't get anything useful. Do I need to boot android before booting
> > > Linux or something? How does your lsusb look like?
> > > 
> > > Thanks,
> > >   Pavel
> 
> -- 
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) 
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html




signature.asc
Description: PGP signature

Re: [PATCH] phy: mapphone-mdm6600: Add USB PHY driver for MDM6600 on Droid 4

[Sebastian Reichel]

Hi Tony,

On Sat, Feb 17, 2018 at 01:07:23PM -0800, Tony Lindgren wrote:
> Let's add support for the GPIO controlled USB PHY on the MDM6600 modem.
> It is used on some Motorola Mapphone series of phones and tablets such
> as Droid 4.
> 
> The MDM6600 is hardwired to the first OHCI port in the Droid 4 case, and
> is controlled by several GPIOs. The USB PHY is integrated into the MDM6600
> device it seems. We know this as we get L3 errors from omap-usb-host if
> trying to use the PHY before MDM6600 is configured.
> 
> The GPIOs controlling MDM6600 are used to power MDM660 on and off, to
> configure the USB start-up mode (normal mode versus USB flashing), and
> they also tell the state of the MDM6600 device.
> 
> The two start-up mode GPIOs are dual-purposed and used for out of band
> (OOB) wake-up for USB and TS 27.010 serial mux. But we need to configure
> the USB start-up mode first to get MDM6600 booted in the right mode to
> be usable in the first place.
> 
> For now, this driver just gives up the two start-up mode GPIOs after the
> modem has been configured to boot in normal mode. One of them we may
> want to configure for USB OOB wake in this driver later on, but that's a
> separate series of patches and needs more work.
> 
> Note that the Motorola Mapphone Linux kernel tree has a "radio-ctrl"
> driver for modems. But it really does not control the radio at all, it
> just controls the modem power and start-up mode for USB. So I came to
> the conclusion that we're better off having this done in the USB PHY
> driver. For adding support for USB flashing mode, we can later on add
> a kernel module option for flash_mode=1 or something similar.
> 
> Also note that currently there is no PM runtime support for the OHCI
> on omap variant SoCs. So for low(er) power idle states, currenty both
> ohci-platform and phy-mapphone-mdm6600 must be unloaded or unbound.
> 
> For reference here is what I measured for total power consumption on
> an idle Droid 4 with and without USB related MDM6600 modules:
> 
> idle lcd off  phy-mapphone-mdm6600ohci-platform
> 153mW 284mW   344mW

So more than twice the idle power... We really want to get runtime
PM working :/

> So it seems that MDM6600 is currently not yet idling even with it's
> radio turned off, but that's something that is beyond the control of
> this USB PHY driver.
> 
> Cc: devicet...@vger.kernel.org
> Cc: Mark Rutland <mark.rutl...@arm.com>
> Cc: Marcel Partap <mpar...@gmx.net>
> Cc: Michael Scott <michael.sc...@linaro.org>
> Cc: Rob Herring <robh...@kernel.org>
> Cc: Sebastian Reichel <s...@kernel.org>
> Signed-off-by: Tony Lindgren <t...@atomide.com>
> ---
>  .../bindings/phy/phy-mapphone-mdm6600.txt  |  30 ++
>  drivers/phy/motorola/Kconfig   |   9 +
>  drivers/phy/motorola/Makefile  |   1 +
>  drivers/phy/motorola/phy-mapphone-mdm6600.c| 490 
> +
>  4 files changed, 530 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/phy/phy-mapphone-mdm6600.txt
>  create mode 100644 drivers/phy/motorola/phy-mapphone-mdm6600.c
> 
> diff --git a/Documentation/devicetree/bindings/phy/phy-mapphone-mdm6600.txt 
> b/Documentation/devicetree/bindings/phy/phy-mapphone-mdm6600.txt
> new file mode 100644
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/phy-mapphone-mdm6600.txt
> @@ -0,0 +1,30 @@
> +Device tree binding documentation for Motorola Mapphone MDM6600 USB PHY
> +
> +Required properties:
> +- compatible Must be "motorola,mapphone-mdm6600"
> +- enable-gpios   GPIO to enable the USB PHY
> +- power-gpiosGPIO to power on the device
> +- reset-gpiosGPIO to reset the device
> +- mode-gpios Two GPIOs to configure MDM6600 USB start-up mode for
> + normal mode versus USB flashing mode
> +- status-gpios   Three GPIOs to read the power state of the MDM6600
> +- cmd-gpios  Three GPIOs to control the power state of the MDM6600
> +
> +Example:
> +
> +fsusb1_phy: fsusb1_phy {
> + compatible = "motorola,mapphone-mdm6600";
> + enable-gpios = < 31 GPIO_ACTIVE_LOW>; /* gpio_95 */
> + power-gpios = < 22 GPIO_ACTIVE_HIGH>; /* gpio_54 */
> + reset-gpios = < 17 GPIO_ACTIVE_HIGH>; /* gpio_49 */
> + mode-gpios = < 20 GPIO_ACTIVE_HIGH>,  /* gpio_148 */
> +  < 21 GPIO_ACTIVE_HIGH>;  /* gpio_149 */
> + status-gpios = < 23 GPIO_ACTIVE_HIGH>,/* gpio_55 */
> +< 21 GPIO_ACTIVE_HIGH>,/* gpio_53 */
> +< 20 GPIO_ACTIVE_HIGH>;/* gpio_52 */
>

Re: [PATCH v4 5/7] power: supply: Add 'connected_type' property and supporting code

[Sebastian Reichel]

Hi,

On Fri, Feb 09, 2018 at 11:28:42AM +, Adam Thomson wrote:
> On 08 February 2018 21:31, Sebastian Reichel wrote:
> > On Tue, Jan 02, 2018 at 03:50:53PM +, Adam Thomson wrote:
> > > This commit adds the 'connected_type' property to represent supplies
> > > which can report a number of different types of supply based on a
> > > connection event.
> > >
> > > Examples of this already exist in drivers whereby the existing 'type'
> > > property is updated, based on an event, to represent what was
> > > connected (e.g. USB_DCP, USB_ACA, ...). Current implementations
> > > however don't show all supported connectable types, so this knowledge
> > > has to be exlicitly known for each driver that supports this.
> > >
> > > The 'connected_type' property is intended to fill this void and show
> > > users all possible types supported by a driver. The property, when
> > > read, shows all available types for the driver, and the one currently
> > > chosen is highlighted/bracketed. It is expected that the 'type'
> > > property would then just show the top-level type, such as 'USB', and
> > > this would be static.
> > >
> > > Currently the 'conn_type' enum contains all of the USB variant types
> > > that exist for the 'type' enum at this time, and in addition has
> > > the PPS type. In the future this can be extended further for other
> > > types which have multiple connected types supported. The mirroring
> > > is intentional so as to not impact existing usage of the 'type'
> > > property.
> > >
> > > Signed-off-by: Adam Thomson <adam.thomson.opensou...@diasemi.com>
> >
> > Thanks for the patch. I think, that it's a good idea to provide the
> > subtype in its own property and just set the type property to "USB".
> > I would prefer to name this "usb_type". Otherwise
> >
> > Reviewed-by: Sebastian Reichel <sebastian.reic...@collabora.co.uk>
> >
> > -- Sebastian
> 
> Thanks for your review. I chose 'connected_type' as I thought this would be 
> more
> generic in case other main types would have some dynamic connection element to
> them and could also benefit from this. If we don't see that as being something
> we want though then I can make this just for USB.

If such a thing appears at some point we can add another property.
I think usb_type is easier to understand from a user point of view
and it helps to keep our enums clean.

-- Sebastian


signature.asc
Description: PGP signature

Re: [PATCH v4 5/7] power: supply: Add 'connected_type' property and supporting code

[Sebastian Reichel]

Hi,

On Tue, Jan 02, 2018 at 03:50:53PM +, Adam Thomson wrote:
> This commit adds the 'connected_type' property to represent supplies
> which can report a number of different types of supply based on a
> connection event.
> 
> Examples of this already exist in drivers whereby the existing 'type'
> property is updated, based on an event, to represent what was
> connected (e.g. USB_DCP, USB_ACA, ...). Current implementations
> however don't show all supported connectable types, so this knowledge
> has to be exlicitly known for each driver that supports this.
> 
> The 'connected_type' property is intended to fill this void and show
> users all possible types supported by a driver. The property, when
> read, shows all available types for the driver, and the one currently
> chosen is highlighted/bracketed. It is expected that the 'type'
> property would then just show the top-level type, such as 'USB', and
> this would be static.
> 
> Currently the 'conn_type' enum contains all of the USB variant types
> that exist for the 'type' enum at this time, and in addition has
> the PPS type. In the future this can be extended further for other
> types which have multiple connected types supported. The mirroring
> is intentional so as to not impact existing usage of the 'type'
> property.
> 
> Signed-off-by: Adam Thomson <adam.thomson.opensou...@diasemi.com>

Thanks for the patch. I think, that it's a good idea to provide the
subtype in its own property and just set the type property to "USB".
I would prefer to name this "usb_type". Otherwise

Reviewed-by: Sebastian Reichel <sebastian.reic...@collabora.co.uk>

-- Sebastian

> ---
>  drivers/power/supply/power_supply_sysfs.c | 50 
> +++
>  include/linux/power_supply.h  | 15 ++
>  2 files changed, 65 insertions(+)
> 
> diff --git a/drivers/power/supply/power_supply_sysfs.c 
> b/drivers/power/supply/power_supply_sysfs.c
> index 5204f11..1b3b202 100644
> --- a/drivers/power/supply/power_supply_sysfs.c
> +++ b/drivers/power/supply/power_supply_sysfs.c
> @@ -46,6 +46,11 @@
>   "USB_PD", "USB_PD_DRP", "BrickID"
>  };
>  
> +static const char * const power_supply_conn_type_text[] = {
> + "Unknown", "USB_DCP", "USB_CDP", "USB_ACA", "USB_C",
> + "USB_PD", "USB_PD_DRP", "USB_PD_PPS", "BrickID"
> +};
> +
>  static const char * const power_supply_status_text[] = {
>   "Unknown", "Charging", "Discharging", "Not charging", "Full"
>  };
> @@ -73,6 +78,46 @@
>   "Unknown", "System", "Device"
>  };
>  
> +static ssize_t power_supply_show_conn_type(struct device *dev,
> +enum power_supply_conn_type 
> *conn_types,
> +ssize_t num_conn_types,
> +union power_supply_propval *value,
> +char *buf)
> +{
> + enum power_supply_conn_type conn_type;
> + ssize_t count = 0;
> + bool match = false;
> + int i;
> +
> + if ((!conn_types) || (num_conn_types <= 0)) {
> + dev_warn(dev, "driver has no valid connected types\n");
> + return -ENODATA;
> + }
> +
> + for (i = 0; i < num_conn_types; ++i) {
> + conn_type = conn_types[i];
> +
> + if (value->intval == conn_type) {
> + count += sprintf(buf + count, "[%s] ",
> +  
> power_supply_conn_type_text[conn_type]);
> + match = true;
> + } else {
> + count += sprintf(buf + count, "%s ",
> +  
> power_supply_conn_type_text[conn_type]);
> + }
> + }
> +
> + if (!match) {
> + dev_warn(dev, "driver reporting unsupported connected type\n");
> + return -EINVAL;
> + }
> +
> + if (count)
> + buf[count - 1] = '\n';
> +
> + return count;
> +}
> +
>  static ssize_t power_supply_show_property(struct device *dev,
> struct device_attribute *attr,
> char *buf) {
> @@ -115,6 +160,10 @@ static ssize_t power_supply_show_property(struct device 
> *dev,
>   else if (off == POWER_SUPPLY_PROP_TYPE)
>   return sprintf(buf, "%s\n",
>  power_s

Re: [PATCH 2/2] usb: chipidea: imx: Fix ULPI on imx53

[Sebastian Reichel]

Hi Peter,

On Mon, Jan 29, 2018 at 11:33:15AM +0800, Peter Chen wrote:
> On Wed, Jan 24, 2018 at 06:14:39PM +0100, Sebastian Reichel wrote:
> > Traditionally, PORTSC should be set before initializing ULPI phys. But
> > setting PORTSC before powering on the phy results in a kernel freeze
> > on imx53 based GE PPD. As a workaround this initializes the phy early
> > in the imx platform code and disables phy power management from the
> > core.
> > 
> > Signed-off-by: Fabien Lahoudere <fabien.lahoud...@collabora.co.uk>
> > Signed-off-by: Sebastian Reichel <sebastian.reic...@collabora.co.uk>
> > ---
> >  drivers/usb/chipidea/ci_hdrc_imx.c | 12 
> >  1 file changed, 12 insertions(+)
> > 
> > diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c 
> > b/drivers/usb/chipidea/ci_hdrc_imx.c
> > index de155c80eb70..e431c5aafe35 100644
> > --- a/drivers/usb/chipidea/ci_hdrc_imx.c
> > +++ b/drivers/usb/chipidea/ci_hdrc_imx.c
> > @@ -83,6 +83,7 @@ struct ci_hdrc_imx_data {
> > struct clk *clk;
> > struct imx_usbmisc_data *usbmisc_data;
> > bool supports_runtime_pm;
> > +   bool override_phy_control;
> > bool in_lpm;
> > /* SoC before i.mx6 (except imx23/imx28) needs three clks */
> > bool need_three_clks;
> > @@ -254,6 +255,7 @@ static int ci_hdrc_imx_probe(struct platform_device 
> > *pdev)
> > int ret;
> > const struct of_device_id *of_id;
> > const struct ci_hdrc_imx_platform_flag *imx_platform_flag;
> > +   struct device_node *np = pdev->dev.of_node;
> >  
> > of_id = of_match_device(ci_hdrc_imx_dt_ids, >dev);
> > if (!of_id)
> > @@ -288,6 +290,14 @@ static int ci_hdrc_imx_probe(struct platform_device 
> > *pdev)
> > }
> >  
> > pdata.usb_phy = data->phy;
> > +
> > +   if (of_device_is_compatible(np, "fsl,imx53-usb") && pdata.usb_phy &&
> > +   of_usb_get_phy_mode(np) == USBPHY_INTERFACE_MODE_ULPI) {
> > +   pdata.flags |= CI_HDRC_OVERRIDE_PHY_CONTROL;
> > +   data->override_phy_control = true;
> > +   usb_phy_init(pdata.usb_phy);
> > +   }
> > +
> > pdata.flags |= imx_platform_flag->flags;
> > if (pdata.flags & CI_HDRC_SUPPORTS_RUNTIME_PM)
> > data->supports_runtime_pm = true;
> > @@ -341,6 +351,8 @@ static int ci_hdrc_imx_remove(struct platform_device 
> > *pdev)
> > pm_runtime_put_noidle(>dev);
> > }
> > ci_hdrc_remove_device(data->ci_pdev);
> > +   if (data->override_phy_control)
> > +   usb_phy_shutdown(data->phy);
> > imx_disable_unprepare_clks(>dev);
> >  
> 
> Sebastian, I have a question, do you have any USB or generic PHY drivers
> for ULPI bus, any power controls are needed for your ULPI peripheral?

The devicetree for GE PPD is available in the mainline kernel:

$ grep -A9 "usbphy[23] {" arch/arm/boot/dts/imx53-ppd.dts
usbphy2: usbphy2 {
compatible = "usb-nop-xceiv";
reset-gpios = < 4 GPIO_ACTIVE_LOW>;
clock-names = "main_clk";
clock-frequency = <2400>;
clocks = < IMX5_CLK_CKO2>;
assigned-clocks = < IMX5_CLK_CKO2_SEL>, < 
IMX5_CLK_OSC>;
assigned-clock-parents = < IMX5_CLK_OSC>;
};

usbphy3: usbphy3 {
compatible = "usb-nop-xceiv";
reset-gpios = < 19 GPIO_ACTIVE_LOW>;
clock-names = "main_clk";

clock-frequency = <2400>;
clocks = < IMX5_CLK_CKO2>;
assigned-clocks = < IMX5_CLK_CKO2_SEL>, < 
IMX5_CLK_OSC>;
assigned-clock-parents = < IMX5_CLK_OSC>;
};

So currently the machine only uses drivers/usb/phy/phy-generic.c. Both
USB phys are actually SMSC USB3315, which is also detected by the kernel:

root@csmon :~# cat /sys/bus/ulpi/devices/ci_hdrc.*.ulpi/uevent 
DEVTYPE=ulpi_device
MODALIAS=ulpi:v0424p0006
DEVTYPE=ulpi_device
MODALIAS=ulpi:v0424p0006

So maybe drivers/usb/phy/phy-ulpi.c should be used, but I don't see
a simple way to do so and using the generic PHY works.

-- Sebastian


signature.asc
Description: PGP signature

[PATCH 1/2] usb: chipidea: imx: Cleanup ci_hdrc_imx_platform_flag

[Sebastian Reichel]

Some trivial cleanups, that do not change functionality.

Signed-off-by: Sebastian Reichel <sebastian.reic...@collabora.co.uk>
---
 drivers/usb/chipidea/ci_hdrc_imx.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c 
b/drivers/usb/chipidea/ci_hdrc_imx.c
index 3b45c25f296e..de155c80eb70 100644
--- a/drivers/usb/chipidea/ci_hdrc_imx.c
+++ b/drivers/usb/chipidea/ci_hdrc_imx.c
@@ -20,7 +20,6 @@
 
 struct ci_hdrc_imx_platform_flag {
unsigned int flags;
-   bool runtime_pm;
 };
 
 static const struct ci_hdrc_imx_platform_flag imx23_usb_data = {
@@ -29,7 +28,7 @@ static const struct ci_hdrc_imx_platform_flag imx23_usb_data 
= {
 };
 
 static const struct ci_hdrc_imx_platform_flag imx27_usb_data = {
-   CI_HDRC_DISABLE_STREAMING,
+   .flags = CI_HDRC_DISABLE_STREAMING,
 };
 
 static const struct ci_hdrc_imx_platform_flag imx28_usb_data = {
-- 
2.15.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/2] usb: chipidea: imx: Fix ULPI on imx53

[Sebastian Reichel]

Traditionally, PORTSC should be set before initializing ULPI phys. But
setting PORTSC before powering on the phy results in a kernel freeze
on imx53 based GE PPD. As a workaround this initializes the phy early
in the imx platform code and disables phy power management from the
core.

Signed-off-by: Fabien Lahoudere <fabien.lahoud...@collabora.co.uk>
Signed-off-by: Sebastian Reichel <sebastian.reic...@collabora.co.uk>
---
 drivers/usb/chipidea/ci_hdrc_imx.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c 
b/drivers/usb/chipidea/ci_hdrc_imx.c
index de155c80eb70..e431c5aafe35 100644
--- a/drivers/usb/chipidea/ci_hdrc_imx.c
+++ b/drivers/usb/chipidea/ci_hdrc_imx.c
@@ -83,6 +83,7 @@ struct ci_hdrc_imx_data {
struct clk *clk;
struct imx_usbmisc_data *usbmisc_data;
bool supports_runtime_pm;
+   bool override_phy_control;
bool in_lpm;
/* SoC before i.mx6 (except imx23/imx28) needs three clks */
bool need_three_clks;
@@ -254,6 +255,7 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev)
int ret;
const struct of_device_id *of_id;
const struct ci_hdrc_imx_platform_flag *imx_platform_flag;
+   struct device_node *np = pdev->dev.of_node;
 
of_id = of_match_device(ci_hdrc_imx_dt_ids, >dev);
if (!of_id)
@@ -288,6 +290,14 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev)
}
 
pdata.usb_phy = data->phy;
+
+   if (of_device_is_compatible(np, "fsl,imx53-usb") && pdata.usb_phy &&
+   of_usb_get_phy_mode(np) == USBPHY_INTERFACE_MODE_ULPI) {
+   pdata.flags |= CI_HDRC_OVERRIDE_PHY_CONTROL;
+   data->override_phy_control = true;
+   usb_phy_init(pdata.usb_phy);
+   }
+
pdata.flags |= imx_platform_flag->flags;
if (pdata.flags & CI_HDRC_SUPPORTS_RUNTIME_PM)
data->supports_runtime_pm = true;
@@ -341,6 +351,8 @@ static int ci_hdrc_imx_remove(struct platform_device *pdev)
pm_runtime_put_noidle(>dev);
}
ci_hdrc_remove_device(data->ci_pdev);
+   if (data->override_phy_control)
+   usb_phy_shutdown(data->phy);
imx_disable_unprepare_clks(>dev);
 
return 0;
-- 
2.15.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH 5/7] power: supply: Add type for USB PD PPS chargers

[Sebastian Reichel]

Hi,

On Wed, Nov 01, 2017 at 05:03:13PM +, Adam Thomson wrote:
> This adds a type to represent USB PPS chargers as defined in the
> USB Power Delivery Specification Revision 3.0 V1.1
> 
> Signed-off-by: Adam Thomson <adam.thomson.opensou...@diasemi.com>

Reviewed-by: Sebastian Reichel <sebastian.reic...@collabora.co.uk>

-- Sebastian

>  drivers/power/supply/power_supply_sysfs.c | 2 +-
>  include/linux/power_supply.h  | 1 +
>  2 files changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/power/supply/power_supply_sysfs.c 
> b/drivers/power/supply/power_supply_sysfs.c
> index 5204f11..efd2469 100644
> --- a/drivers/power/supply/power_supply_sysfs.c
> +++ b/drivers/power/supply/power_supply_sysfs.c
> @@ -43,7 +43,7 @@
>  static const char * const power_supply_type_text[] = {
>   "Unknown", "Battery", "UPS", "Mains", "USB",
>   "USB_DCP", "USB_CDP", "USB_ACA", "USB_C",
> - "USB_PD", "USB_PD_DRP", "BrickID"
> + "USB_PD", "USB_PD_DRP", "USB_PD_PPS", "BrickID"
>  };
>  
>  static const char * const power_supply_status_text[] = {
> diff --git a/include/linux/power_supply.h b/include/linux/power_supply.h
> index 79e90b3..3a79c75 100644
> --- a/include/linux/power_supply.h
> +++ b/include/linux/power_supply.h
> @@ -167,6 +167,7 @@ enum power_supply_type {
>   POWER_SUPPLY_TYPE_USB_TYPE_C,   /* Type C Port */
>   POWER_SUPPLY_TYPE_USB_PD,   /* Power Delivery Port */
>   POWER_SUPPLY_TYPE_USB_PD_DRP,   /* PD Dual Role Port */
> + POWER_SUPPLY_TYPE_USB_PD_PPS,   /* PD Programmable Power Supply 
> */
>   POWER_SUPPLY_TYPE_APPLE_BRICK_ID,   /* Apple Charging Method */
>  };
>  
> -- 
> 1.9.1
> 


signature.asc
Description: PGP signature

Re: [PATCH] extcon: Split out extcon header file for consumer and provider device

[Sebastian Reichel]

Hi,

On Fri, Sep 29, 2017 at 09:01:45AM +0900, Chanwoo Choi wrote:
> The extcon has two type of extcon devices as following.
> - 'extcon provider deivce' adds new extcon device and detect the
>state/properties of external connector. Also, it notifies the
>state/properties to the extcon consumer device.
> - 'extcon consumer device' gets the change state/properties
>from extcon provider device.
> Prior to that, include/linux/extcon.h contains all exported API for
> both provider and consumer device driver. To clarify the meaning of
> header file and to remove the wrong use-case on consumer device,
> this patch separates into extcon.h and extcon-provider.h.
> 
> [Description for include/linux/{extcon.h|extcon-provider.h}]
> - extcon.h includes the extcon API and data structure for extcon consumer
>   device driver. This header file contains the following APIs:
>   : Register/unregister the notifier to catch the change of extcon device
>   : Get the extcon device instance
>   : Get the extcon device name
>   : Get the state of each external connector
>   : Get the property value of each external connector
>   : Get the property capability of each external connector
> 
> - extcon-provider.h includes the extcon API and data structure for extcon
>   provider device driver. This header file contains the following APIs:
>   : Include 'include/linux/extcon.h'
>   : Allocate the memory for extcon device instance
>   : Register/unregister extcon device
>   : Set the state of each external connector
>   : Set the property value of each external connector
>   : Set the property capability of each external connector
> 

[...]

>  drivers/power/supply/qcom_smbb.c  |   2 +-

[...]

Acked-by: Sebastian Reichel <sebastian.reic...@collabora.co.uk>

-- Sebastian


signature.asc
Description: PGP signature

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

[Sebastian Reichel]

Hi,

On Thu, Jul 27, 2017 at 01:14:38PM +0800, Baolin Wang wrote:
> Integrate with the newly added USB charger interface to limit the current
> we draw from the USB input based on the input device configuration
> identified by the USB stack, allowing us to charge more quickly from high
> current inputs 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>
> Acked-by: Lee Jones <lee.jo...@linaro.org>
> Acked-by: Charles Keepax <ckee...@opensource.wolfsonmicro.com>
> ---

Looks ok now.

Acked-by: Sebastian Reichel <sebastian.reic...@collabora.co.uk>

-- Sebastian

>  Documentation/devicetree/bindings/mfd/wm831x.txt |1 +
>  drivers/power/supply/wm831x_power.c  |   72 
> ++
>  2 files changed, 73 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/mfd/wm831x.txt 
> b/Documentation/devicetree/bindings/mfd/wm831x.txt
> index 9f8b743..4e3bc07 100644
> --- a/Documentation/devicetree/bindings/mfd/wm831x.txt
> +++ b/Documentation/devicetree/bindings/mfd/wm831x.txt
> @@ -31,6 +31,7 @@ Required properties:
>  ../interrupt-controller/interrupts.txt
>  
>  Optional sub-nodes:
> +  - usb-phy : Contains a phandle to the USB PHY.
>- regulators : Contains sub-nodes for each of the regulators supplied by
>  the device. The regulators are bound using their names listed below:
>  
> diff --git a/drivers/power/supply/wm831x_power.c 
> b/drivers/power/supply/wm831x_power.c
> index 7082301..dff6473 100644
> --- a/drivers/power/supply/wm831x_power.c
> +++ b/drivers/power/supply/wm831x_power.c
> @@ -13,6 +13,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -31,6 +32,8 @@ struct wm831x_power {
>   char usb_name[20];
>   char battery_name[20];
>   bool have_battery;
> + struct usb_phy *usb_phy;
> + struct notifier_block usb_notify;
>  };
>  
>  static int wm831x_power_check_online(struct wm831x *wm831x, int supply,
> @@ -125,6 +128,43 @@ static int wm831x_usb_get_prop(struct power_supply *psy,
>   POWER_SUPPLY_PROP_VOLTAGE_NOW,
>  };
>  
> +/* In milliamps */
> +static const unsigned int wm831x_usb_limits[] = {
> + 0,
> + 2,
> + 100,
> + 500,
> + 900,
> + 1500,
> + 1800,
> + 550,
> +};
> +
> +static int wm831x_usb_limit_change(struct notifier_block *nb,
> +unsigned long limit, void *data)
> +{
> + struct wm831x_power *wm831x_power = container_of(nb,
> +  struct wm831x_power,
> +  usb_notify);
> + unsigned int i, best;
> +
> + /* Find the highest supported limit */
> + best = 0;
> + for (i = 0; i < ARRAY_SIZE(wm831x_usb_limits); i++) {
> + if (limit >= wm831x_usb_limits[i] &&
> + wm831x_usb_limits[best] < wm831x_usb_limits[i])
> + best = i;
> + }
> +
> + dev_dbg(wm831x_power->wm831x->dev,
> + "Limiting USB current to %umA", wm831x_usb_limits[best]);
> +
> + wm831x_set_bits(wm831x_power->wm831x, WM831X_POWER_STATE,
> + WM831X_USB_ILIM_MASK, best);
> +
> + return 0;
> +}
> +
>  /*
>   *   Battery properties
>   */
> @@ -607,6 +647,33 @@ static int wm831x_power_probe(struct platform_device 
> *pdev)
>   }
>   }
>  
> + power->usb_phy = devm_usb_get_phy_by_phandle(>dev, "usb-phy", 0);
> + ret = PTR_ERR_OR_ZERO(power->usb_phy);
> +
> + switch (ret) {
> + case 0:
> + power->usb_notify.notifier_call = wm831x_usb_limit_change;
> + ret = usb_register_notifier(power->usb_phy, >usb_notify);
> + if (ret) {
> + dev_err(>dev, "Failed to register notifier: %d\n",
> + ret);
> + goto err_bat_irq;
> + }
> + break;
> + case -EINVAL:
> + case -ENODEV:
> + /* ignore missing usb-phy, it's optional */
> + power->usb_phy = NULL;
> + ret = 0;
> + break;
> + default:
> + dev_err(>dev, "Failed to find USB phy: %d\n", ret);
> + /* fall-through */
> + case -EPROBE_DEFER:
> +  

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

[Sebastian Reichel]

Hi,

On Wed, Jul 26, 2017 at 11:05:25AM +0800, Baolin Wang wrote:
> On 25 July 2017 at 17:59, Sebastian Reichel
> <sebastian.reic...@collabora.co.uk> wrote:
> > On Tue, Jul 25, 2017 at 04:00:01PM +0800, Baolin Wang wrote:
> >> Integrate with the newly added USB charger interface to limit the current
> >> we draw from the USB input based on the input device configuration
> >> identified by the USB stack, allowing us to charge more quickly from high
> >> current inputs 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>
> >> ---
> >>  Documentation/devicetree/bindings/mfd/wm831x.txt |1 +
> >>  drivers/power/supply/wm831x_power.c  |   58 
> >> ++
> >>  2 files changed, 59 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/mfd/wm831x.txt 
> >> b/Documentation/devicetree/bindings/mfd/wm831x.txt
> >> index 9f8b743..4e3bc07 100644
> >> --- a/Documentation/devicetree/bindings/mfd/wm831x.txt
> >> +++ b/Documentation/devicetree/bindings/mfd/wm831x.txt
> >> @@ -31,6 +31,7 @@ Required properties:
> >>  ../interrupt-controller/interrupts.txt
> >>
> >>  Optional sub-nodes:
> >> +  - usb-phy : Contains a phandle to the USB PHY.
> >>- regulators : Contains sub-nodes for each of the regulators supplied by
> >>  the device. The regulators are bound using their names listed below:
> >>
> >> diff --git a/drivers/power/supply/wm831x_power.c 
> >> b/drivers/power/supply/wm831x_power.c
> >> index 7082301..d3948ab 100644
> >> --- a/drivers/power/supply/wm831x_power.c
> >> +++ b/drivers/power/supply/wm831x_power.c
> >> @@ -13,6 +13,7 @@
> >>  #include 
> >>  #include 
> >>  #include 
> >> +#include 
> >>
> >>  #include 
> >>  #include 
> >> @@ -31,6 +32,8 @@ struct wm831x_power {
> >>   char usb_name[20];
> >>   char battery_name[20];
> >>   bool have_battery;
> >> + struct usb_phy *usb_phy;
> >> + struct notifier_block usb_notify;
> >>  };
> >>
> >>  static int wm831x_power_check_online(struct wm831x *wm831x, int supply,
> >> @@ -125,6 +128,43 @@ static int wm831x_usb_get_prop(struct power_supply 
> >> *psy,
> >>   POWER_SUPPLY_PROP_VOLTAGE_NOW,
> >>  };
> >>
> >> +/* In milliamps */
> >> +static const unsigned int wm831x_usb_limits[] = {
> >> + 0,
> >> + 2,
> >> + 100,
> >> + 500,
> >> + 900,
> >> + 1500,
> >> + 1800,
> >> + 550,
> >> +};
> >> +
> >> +static int wm831x_usb_limit_change(struct notifier_block *nb,
> >> +unsigned long limit, void *data)
> >> +{
> >> + struct wm831x_power *wm831x_power = container_of(nb,
> >> +  struct wm831x_power,
> >> +  usb_notify);
> >> + unsigned int i, best;
> >> +
> >> + /* Find the highest supported limit */
> >> + best = 0;
> >> + for (i = 0; i < ARRAY_SIZE(wm831x_usb_limits); i++) {
> >> + if (limit >= wm831x_usb_limits[i] &&
> >> + wm831x_usb_limits[best] < wm831x_usb_limits[i])
> >> + best = i;
> >> + }
> >> +
> >> + dev_dbg(wm831x_power->wm831x->dev,
> >> + "Limiting USB current to %umA", wm831x_usb_limits[best]);
> >> +
> >> + wm831x_set_bits(wm831x_power->wm831x, WM831X_POWER_STATE,
> >> + WM831X_USB_ILIM_MASK, best);
> >> +
> >> + return 0;
> >> +}
> >> +
> >>  /*
> >>   *   Battery properties
> >>   */
> >> @@ -607,6 +647,19 @@ static int wm831x_power_probe(struct platform_device 
> >> *pdev)
> >>   }
> >>   }
> >>
> >> + power->usb_phy = devm_usb_get_phy_by_phandle(>dev,
> >> +  "usb-phy", 0);
> >> + if 

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

[Sebastian Reichel]

Hi,

On Tue, Jul 25, 2017 at 04:00:01PM +0800, Baolin Wang wrote:
> Integrate with the newly added USB charger interface to limit the current
> we draw from the USB input based on the input device configuration
> identified by the USB stack, allowing us to charge more quickly from high
> current inputs without drawing more current than specified from others.
> 
> Signed-off-by: Mark Brown 
> Signed-off-by: Baolin Wang 
> ---
>  Documentation/devicetree/bindings/mfd/wm831x.txt |1 +
>  drivers/power/supply/wm831x_power.c  |   58 
> ++
>  2 files changed, 59 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/mfd/wm831x.txt 
> b/Documentation/devicetree/bindings/mfd/wm831x.txt
> index 9f8b743..4e3bc07 100644
> --- a/Documentation/devicetree/bindings/mfd/wm831x.txt
> +++ b/Documentation/devicetree/bindings/mfd/wm831x.txt
> @@ -31,6 +31,7 @@ Required properties:
>  ../interrupt-controller/interrupts.txt
>  
>  Optional sub-nodes:
> +  - usb-phy : Contains a phandle to the USB PHY.
>- regulators : Contains sub-nodes for each of the regulators supplied by
>  the device. The regulators are bound using their names listed below:
>  
> diff --git a/drivers/power/supply/wm831x_power.c 
> b/drivers/power/supply/wm831x_power.c
> index 7082301..d3948ab 100644
> --- a/drivers/power/supply/wm831x_power.c
> +++ b/drivers/power/supply/wm831x_power.c
> @@ -13,6 +13,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -31,6 +32,8 @@ struct wm831x_power {
>   char usb_name[20];
>   char battery_name[20];
>   bool have_battery;
> + struct usb_phy *usb_phy;
> + struct notifier_block usb_notify;
>  };
>  
>  static int wm831x_power_check_online(struct wm831x *wm831x, int supply,
> @@ -125,6 +128,43 @@ static int wm831x_usb_get_prop(struct power_supply *psy,
>   POWER_SUPPLY_PROP_VOLTAGE_NOW,
>  };
>  
> +/* In milliamps */
> +static const unsigned int wm831x_usb_limits[] = {
> + 0,
> + 2,
> + 100,
> + 500,
> + 900,
> + 1500,
> + 1800,
> + 550,
> +};
> +
> +static int wm831x_usb_limit_change(struct notifier_block *nb,
> +unsigned long limit, void *data)
> +{
> + struct wm831x_power *wm831x_power = container_of(nb,
> +  struct wm831x_power,
> +  usb_notify);
> + unsigned int i, best;
> +
> + /* Find the highest supported limit */
> + best = 0;
> + for (i = 0; i < ARRAY_SIZE(wm831x_usb_limits); i++) {
> + if (limit >= wm831x_usb_limits[i] &&
> + wm831x_usb_limits[best] < wm831x_usb_limits[i])
> + best = i;
> + }
> +
> + dev_dbg(wm831x_power->wm831x->dev,
> + "Limiting USB current to %umA", wm831x_usb_limits[best]);
> +
> + wm831x_set_bits(wm831x_power->wm831x, WM831X_POWER_STATE,
> + WM831X_USB_ILIM_MASK, best);
> +
> + return 0;
> +}
> +
>  /*
>   *   Battery properties
>   */
> @@ -607,6 +647,19 @@ static int wm831x_power_probe(struct platform_device 
> *pdev)
>   }
>   }
>  
> + power->usb_phy = devm_usb_get_phy_by_phandle(>dev,
> +  "usb-phy", 0);
> + if (!IS_ERR(power->usb_phy)) {
> + power->usb_notify.notifier_call = wm831x_usb_limit_change;
> + ret = usb_register_notifier(power->usb_phy,
> + >usb_notify);
> + if (ret) {
> + dev_err(>dev, "Failed to register notifier: %d\n",
> + ret);
> + goto err_bat_irq;
> + }
> + }

No error handling for power->usb_phy? I think you should bail out
for all errors except for "not defined in DT". Especially I would
expect probe defer handling in case the power supply driver is
loaded before the phy driver.

>   return ret;
>  
>  err_bat_irq:
> @@ -637,6 +690,11 @@ static int wm831x_power_remove(struct platform_device 
> *pdev)
>   struct wm831x *wm831x = wm831x_power->wm831x;
>   int irq, i;
>  
> + if (!IS_ERR(wm831x_power->usb_phy)) {
> + usb_unregister_notifier(wm831x_power->usb_phy,
> + _power->usb_notify);
> + }
> +
>   for (i = 0; i < ARRAY_SIZE(wm831x_bat_irqs); i++) {
>   irq = wm831x_irq(wm831x, 
>platform_get_irq_byname(pdev,

-- Sebastian


signature.asc
Description: PGP signature

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

[Sebastian Reichel]

Hi,

On Mon, Jul 03, 2017 at 02:07:15PM +0800, Baolin Wang wrote:
> Integrate with the newly added USB charger interface to limit the current
> we draw from the USB input based on the input device configuration
> identified by the USB stack, allowing us to charge more quickly from high
> current inputs without drawing more current than specified from others.
> 
> Signed-off-by: Mark Brown 
> Signed-off-by: Baolin Wang 

Missing DT binding documentation, otherwise fine with me.
Would be nice to convert existing drivers:

$ git grep -l extcon -- drivers/power/supply
drivers/power/supply/axp288_charger.c
drivers/power/supply/bq24190_charger.c
drivers/power/supply/charger-manager.c
drivers/power/supply/qcom_smbb.c

-- Sebastian

> ---
>  drivers/power/supply/wm831x_power.c |   61 
> +++
>  1 file changed, 61 insertions(+)
> 
> diff --git a/drivers/power/supply/wm831x_power.c 
> b/drivers/power/supply/wm831x_power.c
> index 7082301..3e3480708 100644
> --- a/drivers/power/supply/wm831x_power.c
> +++ b/drivers/power/supply/wm831x_power.c
> @@ -13,6 +13,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -31,6 +32,8 @@ struct wm831x_power {
>   char usb_name[20];
>   char battery_name[20];
>   bool have_battery;
> + struct usb_phy *usb_phy;
> + struct notifier_block usb_notify;
>  };
>  
>  static int wm831x_power_check_online(struct wm831x *wm831x, int supply,
> @@ -125,6 +128,43 @@ static int wm831x_usb_get_prop(struct power_supply *psy,
>   POWER_SUPPLY_PROP_VOLTAGE_NOW,
>  };
>  
> +/* In milliamps */
> +static const unsigned int wm831x_usb_limits[] = {
> + 0,
> + 2,
> + 100,
> + 500,
> + 900,
> + 1500,
> + 1800,
> + 550,
> +};
> +
> +static int wm831x_usb_limit_change(struct notifier_block *nb,
> +unsigned long limit, void *data)
> +{
> + struct wm831x_power *wm831x_power = container_of(nb,
> +  struct wm831x_power,
> +  usb_notify);
> + unsigned int i, best;
> +
> + /* Find the highest supported limit */
> + best = 0;
> + for (i = 0; i < ARRAY_SIZE(wm831x_usb_limits); i++) {
> + if (limit >= wm831x_usb_limits[i] &&
> + wm831x_usb_limits[best] < wm831x_usb_limits[i])
> + best = i;
> + }
> +
> + dev_dbg(wm831x_power->wm831x->dev,
> + "Limiting USB current to %umA", wm831x_usb_limits[best]);
> +
> + wm831x_set_bits(wm831x_power->wm831x, WM831X_POWER_STATE,
> + WM831X_USB_ILIM_MASK, best);
> +
> + return 0;
> +}
> +
>  /*
>   *   Battery properties
>   */
> @@ -607,6 +647,22 @@ static int wm831x_power_probe(struct platform_device 
> *pdev)
>   }
>   }
>  
> + power->usb_phy = devm_usb_get_phy_by_phandle(>dev,
> +  "usb-phy", 0);
> + if (IS_ERR(power->usb_phy)) {
> + ret = PTR_ERR(power->usb_phy);
> + dev_err(>dev, "Failed to find USB phy: %d\n", ret);
> + goto err_bat_irq;
> + }
> +
> + power->usb_notify.notifier_call = wm831x_usb_limit_change;
> + ret = usb_register_notifier(power->usb_phy,
> + >usb_notify);
> + if (ret) {
> + dev_err(>dev, "Failed to register notifier: %d\n", ret);
> + goto err_bat_irq;
> + }
> +
>   return ret;
>  
>  err_bat_irq:
> @@ -637,6 +693,11 @@ static int wm831x_power_remove(struct platform_device 
> *pdev)
>   struct wm831x *wm831x = wm831x_power->wm831x;
>   int irq, i;
>  
> + if (wm831x_power->usb_phy) {
> + usb_unregister_notifier(wm831x_power->usb_phy,
> + _power->usb_notify);
> + }
> +
>   for (i = 0; i < ARRAY_SIZE(wm831x_bat_irqs); i++) {
>   irq = wm831x_irq(wm831x, 
>platform_get_irq_byname(pdev,
> -- 
> 1.7.9.5
> 


signature.asc
Description: PGP signature

Re: [PATCH] phy: cpcap-usb: Fix missing return statement

[Sebastian Reichel]

Hi,

On Mon, Jun 12, 2017 at 01:12:23AM -0700, Tony Lindgren wrote:
> Commit 8ae904e3c236 ("phy: cpcap-usb: Add CPCAP PMIC USB support")
> is missing return statement as noted by Colin Ian King
> <colin.k...@canonical.com>. If the optional pins are not configured,
> we just want to return early and not attempt to configure the pins.
> 
> Fixes: 8ae904e3c236 ("phy: cpcap-usb: Add CPCAP PMIC USB support")
> Reported-by: Colin Ian King <colin.k...@canonical.com>
> Signed-off-by: Tony Lindgren <t...@atomide.com>

Reviewed-by: Sebastian Reichel <sebastian.reic...@collabora.co.uk>

-- Sebastian

> ---
>  drivers/phy/motorola/phy-cpcap-usb.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/phy/motorola/phy-cpcap-usb.c 
> b/drivers/phy/motorola/phy-cpcap-usb.c
> --- a/drivers/phy/motorola/phy-cpcap-usb.c
> +++ b/drivers/phy/motorola/phy-cpcap-usb.c
> @@ -468,6 +468,8 @@ static int cpcap_usb_init_optional_pins(struct 
> cpcap_phy_ddata *ddata)
>   dev_info(ddata->dev, "default pins not configured: %ld\n",
>PTR_ERR(ddata->pins));
>   ddata->pins = NULL;
> +
> + return 0;
>   }
>  
>   ddata->pins_ulpi = pinctrl_lookup_state(ddata->pins, "ulpi");
> -- 
> 2.13.0
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


signature.asc
Description: PGP signature

Re: [PATCH 3/3] usb: host: ohci-omap3: Remove driver in favor of ohci-platform

[Sebastian Reichel]

Hi,

On Mon, May 22, 2017 at 09:00:07AM -0700, Tony Lindgren wrote:
> This driver is no longer needed and can be removed. The reason why
> it's safe to remove this driver is that most omap devices don't have a
> USB low-speed or full-speed compatible PHY installed and configured
> with drivers/mfd/omap-usb-host.c. This means that devices like
> beagleboard and pandaboard need to use a high-speed USB hub in order
> to use devices like keyboard and mice.
> 
> Currently the only known configured for a full-speed PHY is the
> mdm6600 modem on droid 4 and I've verified it works just fine with
> ohci-platform.
> 
> Cc: Roger Quadros <rog...@ti.com>
> Cc: Sebastian Reichel <sebastian.reic...@collabora.co.uk>
> Signed-off-by: Tony Lindgren <t...@atomide.com>

Reviewed-by: Sebastian Reichel <sebastian.reic...@collabora.co.uk>

-- Sebastian

> ---
>  drivers/usb/host/Kconfig  |   6 +-
>  drivers/usb/host/Makefile |   1 -
>  drivers/usb/host/ohci-omap3.c | 211 
> --
>  3 files changed, 5 insertions(+), 213 deletions(-)
>  delete mode 100644 drivers/usb/host/ohci-omap3.c
> 
> diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
> --- a/drivers/usb/host/Kconfig
> +++ b/drivers/usb/host/Kconfig
> @@ -473,8 +473,12 @@ config USB_OHCI_HCD_AT91
>  config USB_OHCI_HCD_OMAP3
>   tristate "OHCI support for OMAP3 and later chips"
>   depends on (ARCH_OMAP3 || ARCH_OMAP4 || SOC_OMAP5)
> + select USB_OHCI_HCD_PLATFORM
>   default y
> - ---help---
> + help
> +   This option is deprecated now and the driver was removed, use
> +   USB_OHCI_HCD_PLATFORM instead.
> +
> Enables support for the on-chip OHCI controller on
> OMAP3 and later chips.
>  
> diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
> --- a/drivers/usb/host/Makefile
> +++ b/drivers/usb/host/Makefile
> @@ -52,7 +52,6 @@ obj-$(CONFIG_USB_OHCI_HCD_PCI)  += ohci-pci.o
>  obj-$(CONFIG_USB_OHCI_HCD_PLATFORM)  += ohci-platform.o
>  obj-$(CONFIG_USB_OHCI_EXYNOS)+= ohci-exynos.o
>  obj-$(CONFIG_USB_OHCI_HCD_OMAP1) += ohci-omap.o
> -obj-$(CONFIG_USB_OHCI_HCD_OMAP3) += ohci-omap3.o
>  obj-$(CONFIG_USB_OHCI_HCD_SPEAR) += ohci-spear.o
>  obj-$(CONFIG_USB_OHCI_HCD_STI)   += ohci-st.o
>  obj-$(CONFIG_USB_OHCI_HCD_AT91)  += ohci-at91.o
> diff --git a/drivers/usb/host/ohci-omap3.c b/drivers/usb/host/ohci-omap3.c
> deleted file mode 100644
> --- a/drivers/usb/host/ohci-omap3.c
> +++ /dev/null
> @@ -1,211 +0,0 @@
> -/*
> - * ohci-omap3.c - driver for OHCI on OMAP3 and later processors
> - *
> - * Bus Glue for OMAP3 USBHOST 3 port OHCI controller
> - * This controller is also used in later OMAPs and AM35x chips
> - *
> - * Copyright (C) 2007-2010 Texas Instruments, Inc.
> - * Author: Vikram Pandita <vikram.pand...@ti.com>
> - * Author: Anand Gadiyar <gadi...@ti.com>
> - * Author: Keshava Munegowda <keshava_mgo...@ti.com>
> - *
> - * Based on ehci-omap.c and some other ohci glue layers
> - *
> - * This program is free software; you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License as published by
> - * the Free Software Foundation; either version 2 of the License, or
> - * (at your option) any later version.
> - *
> - * This program is distributed in the hope that it will be useful,
> - * but WITHOUT ANY WARRANTY; without even the implied warranty of
> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> - * GNU General Public License for more details.
> - *
> - * You should have received a copy of the GNU General Public License
> - * along with this program; if not, write to the Free Software
> - * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307 USA
> - *
> - * TODO (last updated Feb 27, 2011):
> - *   - add kernel-doc
> - */
> -
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -
> -#include "ohci.h"
> -
> -#define DRIVER_DESC "OHCI OMAP3 driver"
> -
> -static const char hcd_name[] = "ohci-omap3";
> -static struct hc_driver __read_mostly ohci_omap3_hc_driver;
> -
> -/*
> - * configure so an HC device and id are always provided
> - * always called with process context; sleeping is OK
> - */
> -
> -/**
> - * ohci_hcd_omap3_probe - initialize OMAP-based HCDs
> - *
> - * Allocates basic resources for this USB host controller, and
> - * then invokes the start() method for the HCD associated with it
> - * through the hotplug entry's driver_data.
> - */
> -static i

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

[Sebastian Reichel]

Hi,

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.
> 
> Signed-off-by: Wolfram Sang <w...@the-dreams.de>
> ---
> [...]
>  drivers/power/supply/twl4030_charger.c  | 2 +-
> [...]

Acked-by: Sebastian Reichel <sebastian.reic...@collabora.co.uk>

-- Sebastian


signature.asc
Description: PGP signature

Re: [PATCH 3/4] usb: host: ohci-omap3: Print warning to get people to use ohci-platform

[Sebastian Reichel]

Hi,

On Thu, May 18, 2017 at 07:08:58AM -0700, Tony Lindgren wrote:
> * Sebastian Reichel <s...@kernel.org> [170518 02:18]:
> > On Wed, May 17, 2017 at 03:59:21PM -0700, Tony Lindgren wrote:
> > > We can't just remove ohci-omap3 as that could make some people's
> > > systems unusable for keyboard and mouse. Let's print a warning for
> > > now, and then remove the driver in a year or so.
> >
> > I guess you could drop the driver and modify the Kconfig entry,
> > so that it selects USB_OHCI_HCD_PLATFORM? I just checked and
> > there are already a few examples of this in the USB host Kconfig :)
> 
> Right but there's still nothing telling people to load ohci-platform
> instead of ohci-omap3 if we just remove ohci-omap3 without any warnings.

Shouldn't the driver be loaded automatically due to the DT
compatible value?

> I don't think there's any need to rush to remove ohci-omap3.

Just looked like it can be dropped with trivial changes.

-- Sebastian


signature.asc
Description: PGP signature

Re: [PATCH 3/4] usb: host: ohci-omap3: Print warning to get people to use ohci-platform

[Sebastian Reichel]

Hi,

On Wed, May 17, 2017 at 03:59:21PM -0700, Tony Lindgren wrote:
> We can't just remove ohci-omap3 as that could make some people's
> systems unusable for keyboard and mouse. Let's print a warning for
> now, and then remove the driver in a year or so.
> 
> Cc: Hans de Goede 
> Cc: Rob Herring 
> Cc: Roger Quadros 
> Cc: Yoshihiro Shimoda 
> Signed-off-by: Tony Lindgren 

I guess you could drop the driver and modify the Kconfig entry,
so that it selects USB_OHCI_HCD_PLATFORM? I just checked and
there are already a few examples of this in the USB host Kconfig :)

-- Sebastian

> ---
>  drivers/usb/host/ohci-omap3.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/usb/host/ohci-omap3.c b/drivers/usb/host/ohci-omap3.c
> --- a/drivers/usb/host/ohci-omap3.c
> +++ b/drivers/usb/host/ohci-omap3.c
> @@ -130,6 +130,9 @@ static int ohci_hcd_omap3_probe(struct platform_device 
> *pdev)
>   dev_dbg(dev, "failed to add hcd with err %d\n", ret);
>   goto err_add_hcd;
>   }
> +
> + WARN(1, "ohci-omap3 is deprecated, please use ohci-platform instead\n");
> +
>   device_wakeup_enable(hcd->self.controller);
>  
>   return 0;
> -- 
> 2.13.0
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


signature.asc
Description: PGP signature

Re: [PATCH] phy: cpcap-usb: Add CPCAP PMIC USB support

[Sebastian Reichel]

Hi,

On Thu, Mar 16, 2017 at 08:51:52PM -0700, Tony Lindgren wrote:
> Some Motorola phones like droid 4 use a custom CPCAP PMIC that has a
> multiplexing USB PHY.
> 
> This USB PHY can operate at least in four modes using pin multiplexing
> and two control GPIOS:
> 
> - Pass through companion PHY for the SoC USB PHY
> - ULPI PHY for the SoC
> - Pass through USB for the modem
> - UART debug console for the SoC
> 
> This patch adds support for droid 4 USB PHY and debug UART modes,
> support for other modes can be added later on as needed.
> 
> Both peripheral and host mode are working for the USB. The
> host mode depends on the cpcap-charger driver for VBUS.
> 
> VBUS and ID pin detection are done using cpcap-adc IIO ADC
> driver.

I tested UART, USB slave (cdc-ether) & USB host (keyboard & touchpad
from Atrix lapdock) mode with Droid 4:

Tested-by: Sebastian Reichel <s...@kernel.org>

-- Sebastian


signature.asc
Description: PGP signature

Re: v4.9 to v4.10 regression: oops when USB cable is plugged in.

[Sebastian Reichel]

Hi,

On Fri, Jan 27, 2017 at 10:55:12PM +0100, Pavel Machek wrote:
> Ok, I can try. But so far even -rc1 is a lot of fun. But... I consider
> phone calls core feature of a phone. I'd very much like to get that to
> work. Unfortunately, that means real-time audio, and a lot of
> fun. Plus, as it is touchscreen device, it needs a GUI. 

Talking about testing - kernelci's n900 is broken?

https://kernelci.org/boot/omap3-n900/

-- Sebastian


signature.asc
Description: PGP signature

Re: [PATCH 03/12] power_supply: axp288_charger: Replace the extcon API

[Sebastian Reichel]

Hi Chanwoo,

On Tue, Dec 06, 2016 at 09:26:14AM +0900, Chanwoo Choi wrote:
> Could you please review and pick the patch3/4 for power-supply driver?

Patches look fine. As I expect the merge window to open next week I
would rather not queue this for 4.10 and instead do it once 4.10-rc1
has been tagged.

-- Sebastian


signature.asc
Description: PGP signature

Re: [PATCH v6 2/8] power: add power sequence library

[Sebastian Reichel]

Hi Peter,

On Mon, Aug 22, 2016 at 02:51:58PM +0800, Peter Chen wrote:
> On Mon, Aug 15, 2016 at 05:13:12PM +0800, Peter Chen wrote:
> > We have an well-known problem that the device needs to do some power
> > sequence before it can be recognized by related host, the typical
> > example like hard-wired mmc devices and usb devices.
> > 
> > This power sequence is hard to be described at device tree and handled by
> > related host driver, so we have created a common power sequence
> > library to cover this requirement. The core code has supplied
> > some common helpers for host driver, and individual power sequence
> > libraries handle kinds of power sequence for devices.
> > 
> > pwrseq_generic is intended for general purpose of power sequence, which
> > handles gpios and clocks currently, and can cover regulator and pinctrl
> > in future. The host driver calls pwrseq_alloc_generic to create
> > an generic pwrseq instance.
> > 
> > Signed-off-by: Peter Chen 
> > Tested-by Joshua Clayton 
> > Reviewed-by: Matthias Kaehlcke 
> > Tested-by: Matthias Kaehlcke 
> 
> Hi Greg, Sebastian, Dmitry, and David
> 
> I find the code under drivers/power have several subsystems.
> Does this power sequence patch set can go 
> git://git.infradead.org/battery-2.6.git?
> Or can go the Greg's tree?

I think this does not really fit into the power-supply tree.
I would expect this to go through Rafael's linux-pm tree.

Note: I moved all the power-supply code into drivers/power/supply/
in linux-next, among other things because of this patchset. To avoid
merge conflicts in drivers/power/Makefile and drivers/power/Kconfig
the tree pulling this patchset should also pull a (yet to be
created) immutable branch containing
https://git.kernel.org/cgit/linux/kernel/git/sre/linux-power-supply.git/commit/drivers/power?h=for-next=8c0984e5a75337df513047ec92a6c09d78e3e5cd

-- Sebastian


signature.asc
Description: PGP signature

Re: [balbi-usb:testing/next 64/67] otg.c:undefined reference to `usb_gadget_vbus_disconnect'

[Sebastian Reichel]

Hi Felipe,

On Mon, Jun 13, 2016 at 09:01:55AM +0300, Felipe Balbi wrote:
> From d45bdfafc3143dc7acc9d71131807d3e30ab7bcd Mon Sep 17 00:00:00 2001
> From: Felipe Balbi <felipe.ba...@linux.intel.com>
> Date: Tue, 31 May 2016 13:07:47 +0300
> Subject: [PATCH] usb: gadget: move gadget API functions to udc-core
> 
> instead of defining all functions as static inlines,
> let's move them to udc-core and export them with
> EXPORT_SYMBOL_GPL, that way we can make sure that
> only GPL drivers will use them.
> 
> As a side effect, it'll be nicer to add tracepoints
> to the gadget API.
> 
> While at that, also fix Kconfig dependencies to
> avoid randconfig build failures.
> 
> Signed-off-by: Felipe Balbi <felipe.ba...@linux.intel.com>
> ---
>  drivers/phy/Kconfig   |   1 +
>  drivers/power/Kconfig |   1 +
>  drivers/usb/gadget/udc/udc-core.c | 573 +
>  drivers/usb/host/Kconfig  |   2 +-
>  drivers/usb/phy/Kconfig   |  11 +-
>  include/linux/usb/gadget.h| 585 
> --
>  6 files changed, 645 insertions(+), 528 deletions(-)

[For drivers/power/Kconfig]
Acked-By: Sebastian Reichel <s...@kernel.org>

-- Sebastian


signature.asc
Description: PGP signature

Re: [RFC 11/15] power: reset: keystone: Add missing MFD_SYSCON dependency on HAS_IOMEM

[Sebastian Reichel]

Hi,

On Thu, Mar 03, 2016 at 12:00:14PM +0100, Arnd Bergmann wrote:
> On Thursday 03 March 2016 17:03:37 Krzysztof Kozlowski wrote:
> > diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
> > index 0a6408a39c66..0f34846ae80d 100644
> > --- a/drivers/power/reset/Kconfig
> > +++ b/drivers/power/reset/Kconfig
> > @@ -141,6 +141,7 @@ config POWER_RESET_XGENE
> >  config POWER_RESET_KEYSTONE
> > bool "Keystone reset driver"
> > depends on ARCH_KEYSTONE
> > +   depends on HAS_IOMEM# For MFD_SYSCON
> > select MFD_SYSCON
> > help
> >   Reboot support for the KEYSTONE SoCs.
> > 
> 
> This is platform specific, but we should probably add || COMPILE_TEST
> along with the HAS_IOMEM dependency.

Sounds sensible. Will you guys send an updated patch?

-- Sebastian


signature.asc
Description: PGP signature

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

[Sebastian Reichel]

Hi,

On Mon, Nov 16, 2015 at 02:33:31PM +0800, Baolin Wang wrote:
> +static ssize_t cur_limit_show(struct device *dev,
> +   struct device_attribute *attr,
> +   char *buf)
> +{
> + struct usb_charger *uchger = dev_to_uchger(dev);
> +
> + return scnprintf(buf, PAGE_SIZE, "%d %d %d %d\n",
> +  uchger->cur_limit.sdp_cur_limit,
> +  uchger->cur_limit.dcp_cur_limit,
> +  uchger->cur_limit.cdp_cur_limit,
> +  uchger->cur_limit.aca_cur_limit);
> +}
> +
> +static ssize_t cur_limit_store(struct device *dev,
> +struct device_attribute *attr,
> +const char *buf, size_t count)
> +{
> + struct usb_charger *uchger = dev_to_uchger(dev);
> + struct usb_charger_cur_limit cur;
> + int ret;
> +
> + ret = sscanf(buf, "%d %d %d %d",
> +  _cur_limit, _cur_limit,
> +  _cur_limit, _cur_limit);
> + if (ret == 0)
> + return -EINVAL;
> +
> + ret = usb_charger_set_cur_limit(uchger, );
> + if (ret < 0)
> + return ret;
> +
> + return count;
> +}
> +static DEVICE_ATTR_RW(cur_limit);

I think this functionality should be provided with one file per
type. This makes it easier to parse the values from userspace
and makes it possible to extend the frameworks functionality
(e.g. when new types are added in a newer revision of the USB
standard).

-- Sebastian


signature.asc
Description: PGP signature

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

[Sebastian Reichel]

Hi,

On Fri, Aug 21, 2015 at 01:34:52PM +0800, Baolin Wang wrote:
> Integrate with the newly added USB charger interface to limit the current
> we draw from the USB input based on the input device configuration
> identified by the USB stack, allowing us to charge more quickly from high
> current inputs 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>
> Acked-by: Lee Jones <lee.jo...@linaro.org>
> Acked-by: Charles Keepax <ckee...@opensource.wolfsonmicro.com>
> Acked-by: Peter Chen <peter.c...@freescale.com>

Acked-by: Sebastian Reichel <s...@kernel.org>

-- Sebastian


signature.asc
Description: Digital signature

Re: [PATCH v4 resend 0/2] power: Add an axp20x-usb-power driver

[Sebastian Reichel]

Hi,

On Sun, Sep 20, 2015 at 08:39:31AM -0400, Hans de Goede wrote:
> This is a resend of v4 of the axp20x-usb-power power-supply driver,
> after v4 there have been no further comments, so I assume that this
> version is ready for merging, yet for some reason it has not been
> merged yet.

My fault. I did not have enough time before my vacation.

> Can we please get this driver merged (preferably into 4.3,

It's obviously too late now.

> but if not at least lets get it into next / 4.4 asap).

I already merged this into my (local) dev branch last week. I
just pushed it out, so it should appear in next tomorrow.

-- Sebastian


signature.asc
Description: Digital signature

Re: [PATCH 2/2] twl4030_charger: find associated phy by more reliable means.

[Sebastian Reichel]

Hi Neil,

On Tue, Feb 24, 2015 at 03:01:29PM +1100, NeilBrown wrote:
 twl4030_charger currently finds the associated phy
 using usb_get_phy() which will return the first USB2 phy.
 If your platform has multiple such phys (as mine does),
 this is not reliable (and reliably fails on the GTA04).
 
 Change to use devm_usb_get_phy_by_node(), having found the
 node by looking for an appropriately named sibling in
 device-tree.
 
 This makes usb-charging dependent on correct device-tree
 configuration.

The patch looks ok to me, but you should update the DT documentation
in Documentation/devicetree/bindings/power/twl-charger.txt regarding
the sibling dependency.

Apart from that DT binding maintainers should be CC'd.

-- Sebastian


signature.asc
Description: Digital signature

Re: [PATCH 2/9] power/reset: brcmstb: Use the DT compatible string to indicate bit positions

[Sebastian Reichel]

Hi,

On Tue, Nov 25, 2014 at 04:49:47PM -0800, Kevin Cernekee wrote:
 Some of the older chips used different bits to arm and trigger the reset.
 Add the infrastructure needed to specify this through the compatible
 string.

Thanks, applied.

-- Sebastian


signature.asc
Description: Digital signature

Re: [PATCH 1/9] power/reset: brcmstb: Make the driver buildable on MIPS

[Sebastian Reichel]

Hi,

On Tue, Nov 25, 2014 at 04:49:46PM -0800, Kevin Cernekee wrote:
 Now that the driver doesn't use any ARM-specific headers, it is safe
 to build on MIPS or with COMPILE_TEST.

Thanks, applied.

-- Sebastian


signature.asc
Description: Digital signature

Re: [PATCH 3/9] power/reset: brcmstb: Add support for old 65nm chips

[Sebastian Reichel]

Hi,

On Tue, Nov 25, 2014 at 04:49:48PM -0800, Kevin Cernekee wrote:
 The register bit fields are a little different, so add an entry and a
 compatible string to accommodate them.

Thanks, applied.

-- Sebastian


signature.asc
Description: Digital signature

Re: [PATCH v4 1/5] mfd: omap-usb-host: Update DT clock binding information

[Sebastian Reichel]

On Wed, Jan 08, 2014 at 11:45:38AM +0530, Roger Quadros wrote:
 diff --git a/Documentation/devicetree/bindings/mfd/omap-usb-host.txt 
 b/Documentation/devicetree/bindings/mfd/omap-usb-host.txt
 index b381fa6..5635202 100644
 --- a/Documentation/devicetree/bindings/mfd/omap-usb-host.txt
 +++ b/Documentation/devicetree/bindings/mfd/omap-usb-host.txt
 @@ -32,6 +32,10 @@ Optional properties:
  - single-ulpi-bypass: Must be present if the controller contains a single
ULPI bypass control bit. e.g. OMAP3 silicon = ES2.1
  
 +- clocks: phandle to 60MHz functional clock to the USB Host module.
 +
 +- clock-names: must be init_60m_fclk
 +
  Required properties if child node exists:
  
  - #address-cells: Must be 1

I have some questions:

What about the other clocks acquired in drivers/mfd/omap-usb-host.c? Shouldn't
all of those be provided by via the DT phandle?

Should the clk_get be changed to of_clk_get()/of_clk_get_by_name() in the
driver? This would potentially remove the need of the init_60m_fclk name.

$ grep clk_get drivers/mfd/omap-usb-host.c
omap-ehci_logic_fck = clk_get(dev, ehci_logic_fck);
omap-utmi_p1_gfclk = clk_get(dev, utmi_p1_gfclk);
omap-utmi_p2_gfclk = clk_get(dev, utmi_p2_gfclk);
omap-xclk60mhsp1_ck = clk_get(dev, xclk60mhsp1_ck);
omap-xclk60mhsp2_ck = clk_get(dev, xclk60mhsp2_ck);
omap-init_60m_fclk = clk_get(dev, init_60m_fclk);
omap-utmi_clk[i] = clk_get(dev, clkname);
omap-hsic480m_clk[i] = clk_get(dev, clkname);
omap-hsic60m_clk[i] = clk_get(dev, clkname);

-- Sebastian


signature.asc
Description: Digital signature

Re: [PATCH v4 1/5] mfd: omap-usb-host: Update DT clock binding information

[Sebastian Reichel]

Hi,

On Wed, Jan 08, 2014 at 03:39:36PM +0530, Roger Quadros wrote:
  What about the other clocks acquired in drivers/mfd/omap-usb-host.c? 
  Shouldn't
  all of those be provided by via the DT phandle?
 
 All those clocks are identically named across the OMAP SoCs and are unique 
 for each
 SoC, so providing DT phandle for all of them is not required.
 
 The init_60m_fclk was renamed to l3init_60m_fclk in OMAP5, and hence the need 
 for
 this binding.

I understand the intention of this patch. I was just wondering if
all the clocks should be referenced from DT even if that is not
strictly needed at the moment. This would make clocks similar to
other resources like regulators, gpios, irqs, ...

Having the clocks referenced from DT looks cleaner to me. It means I
can check the DT file for any resources used by a driver. It also
creates some kind of consistency in the kernel.

  Should the clk_get be changed to of_clk_get()/of_clk_get_by_name() in the
  driver? This would potentially remove the need of the init_60m_fclk name.
 
 If we use of_clk_xxx() then we'll need to update DT nodes for OMAP4 and OMAP3 
 as
 well to explicitly provide the clock phandle.

I'm aware of this.

-- Sebastian


signature.asc
Description: Digital signature

Re: BUG: usb: obex in g_nokia.ko causing kernel panic

[Sebastian Reichel]

On Tue, Nov 26, 2013 at 06:10:22PM +0100, Pali Rohár wrote:
 On Tuesday 19 November 2013 11:51:12 Pali Rohár wrote:
  For a long time (since 3.5 or 3.8? - I do not remember) obex
  subdriver in g_nokia usb gadget module causing kernel panic
  after module is loaded on Nokia N900. I do not know where is
  problem and due to immediatelly kernel crash when loading
  driver I was not able to see any dmesg output. Now I was able
  to store something into mtd log and here is crash backtrace:
  [...]
 
 Hi! can you look at this problem?

So it worked at some time?
Have you tried to git bisect the problem?

-- Sebastian


signature.asc
Description: Digital signature

Re: [PATCH 0/1] Possibly fix USB OTG on GTA04 and N900

[Sebastian Reichel]

Hi,

On Mon, Oct 07, 2013 at 04:28:12PM +0300, Roger Quadros wrote:
 USB OTG on these boards might be broken on Greg's usb-next branch [1]
 after the Generic PHY framework and associated patches were merged.
 
 This is a probable fix but I'm not able to test these boards. Please
 give it a try and your Ack if it works. Thanks.
 
 [1] - git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git

I have tested the Nokia N900 part of the patch. Without this patch
the USB port does not work:

[1.015014] musb-omap2430 480ab000.usb_otg_hs: unable to find phy

With the patch everything seems to work.

Tested-by: Sebastian Reichel s...@debian.org

-- Sebastian


signature.asc
Description: Digital signature

Re: [PATCH 4/4] RX-51: Add platform function and data for bq24150a charger

[Sebastian Reichel]

Hi Pali,

On Sun, Sep 08, 2013 at 10:50:39AM +0200, Pali Rohár wrote:
 This patch will register bq24150a charger in RX-51 board data.
 Patch also adding platform function between isp1704 and bq2415x
 drivers for detecting charger type.
 
 So finally charging battery on Nokia N900 (RX-51) working
 automatically without any proprietary Nokia bits in userspace.

cool :)

 index 9c2dd10..a993ffe 100644
 --- a/arch/arm/mach-omap2/board-rx51-peripherals.c
 +++ b/arch/arm/mach-omap2/board-rx51-peripherals.c

AFAIK platform code for omap3 based boards is supposed to be removed
in the near future [0]. Device Tree does not support the glue layer, so
probably a small rx51 specific driver is needed.

[0] https://lkml.org/lkml/2013/8/12/70

-- Sebastian


signature.asc
Description: Digital signature