Re: [PATCH] USB: add usbfs ioctl to retrieve the connection speed

[Alan Stern]

On Sat, 3 Jun 2017, Greg KH wrote:

> We already export the USB_SPEED values to userspace, why not just use
> those already, so we don't have to define yet-another-value?
> 
> That would make this function much simple :)

By golly, you're right!  Good call -- that simply had not occurred to 
me.  I will rewrite the patch.

Alan Stern

--
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: [PATCH v5 3/8] thermal: intel_bxt_pmic_thermal: Use first level PMIC thermal irq

[Andy Shevchenko]

On Sat, Jun 3, 2017 at 8:53 PM, Sathyanarayanan Kuppuswamy Natarajan
 wrote:
> On Sat, Jun 3, 2017 at 10:32 AM, Andy Shevchenko
>  wrote:
>> On Sat, Jun 3, 2017 at 8:28 PM, Sathyanarayanan Kuppuswamy Natarajan
>>  wrote:

>> Let's assume we applied patches 1 and 2, does it mean the regression
>> to the existing behaviour?
>
> Yes, Just applying patch 1 & 2 and not apply patch 3 will create
> regression in thermal driver.
>
> Since there is no compilation dependency between patch 2 & 3 and they
> are from two different domains, I submitted them separately to make it
> easier for review.

And this is exactly bisectability (level 2 :-) ) issue.
Basically you confirmed you need to squash them like I said.

>> (For example, device worked improperly in some cases -> stopped
>> working completely)

-- 
With Best Regards,
Andy Shevchenko
--
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: [PATCH v5 3/8] thermal: intel_bxt_pmic_thermal: Use first level PMIC thermal irq

[Sathyanarayanan Kuppuswamy Natarajan]

Hi,

On Sat, Jun 3, 2017 at 10:32 AM, Andy Shevchenko
 wrote:
> On Sat, Jun 3, 2017 at 8:28 PM, Sathyanarayanan Kuppuswamy Natarajan
>  wrote:
>> Hi,
>>
>> On Sat, Jun 3, 2017 at 6:00 AM, Andy Shevchenko
>>  wrote:
>>> On Thu, Jun 1, 2017 at 1:37 AM,
>>>  wrote:
 From: Kuppuswamy Sathyanarayanan 
 

 PMIC mfd driver only exports first level irq for thermal device.
 But currently we are reading the irqs from the second level irq
 chip, So this patch fixes this issue by adding support to use
 first level PMIC thermal irq.

>>>
>>> Shouldn't be this squashed to patch 2?
>>
>> There is no compilation dependency between patch 2 and 3. But they are
>> functionally dependent.
>>
>> Should we squash functionally dependent patches too ?
>
> Let's assume we applied patches 1 and 2, does it mean the regression
> to the existing behaviour?

Yes, Just applying patch 1 & 2 and not apply patch 3 will create
regression in thermal driver.

Since there is no compilation dependency between patch 2 & 3 and they
are from two different domains, I submitted them separately to make it
easier for review.



>
> (For example, device worked improperly in some cases -> stopped
> working completely)
>
> --
> With Best Regards,
> Andy Shevchenko



-- 
Sathya
--
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: [PATCH v5 3/8] thermal: intel_bxt_pmic_thermal: Use first level PMIC thermal irq

[Andy Shevchenko]

On Sat, Jun 3, 2017 at 8:28 PM, Sathyanarayanan Kuppuswamy Natarajan
 wrote:
> Hi,
>
> On Sat, Jun 3, 2017 at 6:00 AM, Andy Shevchenko
>  wrote:
>> On Thu, Jun 1, 2017 at 1:37 AM,
>>  wrote:
>>> From: Kuppuswamy Sathyanarayanan 
>>> 
>>>
>>> PMIC mfd driver only exports first level irq for thermal device.
>>> But currently we are reading the irqs from the second level irq
>>> chip, So this patch fixes this issue by adding support to use
>>> first level PMIC thermal irq.
>>>
>>
>> Shouldn't be this squashed to patch 2?
>
> There is no compilation dependency between patch 2 and 3. But they are
> functionally dependent.
>
> Should we squash functionally dependent patches too ?

Let's assume we applied patches 1 and 2, does it mean the regression
to the existing behaviour?

(For example, device worked improperly in some cases -> stopped
working completely)

-- 
With Best Regards,
Andy Shevchenko
--
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: [PATCH v5 3/8] thermal: intel_bxt_pmic_thermal: Use first level PMIC thermal irq

[Sathyanarayanan Kuppuswamy Natarajan]

Hi,

On Sat, Jun 3, 2017 at 6:00 AM, Andy Shevchenko
 wrote:
> On Thu, Jun 1, 2017 at 1:37 AM,
>  wrote:
>> From: Kuppuswamy Sathyanarayanan 
>>
>> PMIC mfd driver only exports first level irq for thermal device.
>> But currently we are reading the irqs from the second level irq
>> chip, So this patch fixes this issue by adding support to use
>> first level PMIC thermal irq.
>>
>
> Shouldn't be this squashed to patch 2?

There is no compilation dependency between patch 2 and 3. But they are
functionally dependent.

Should we squash functionally dependent patches too ?

>
>> Signed-off-by: Kuppuswamy Sathyanarayanan 
>> 
>> Acked-by: Zhang Rui 
>> ---
>>  drivers/thermal/intel_bxt_pmic_thermal.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> Changes since v1:
>>  * None
>>
>> Changes since v2:
>>  * Rebased on top of latest release.
>>
>> Changes since v3:
>>  * Rebased on top of latest release.
>>
>> diff --git a/drivers/thermal/intel_bxt_pmic_thermal.c 
>> b/drivers/thermal/intel_bxt_pmic_thermal.c
>> index 0f19a39..ef6b322 100644
>> --- a/drivers/thermal/intel_bxt_pmic_thermal.c
>> +++ b/drivers/thermal/intel_bxt_pmic_thermal.c
>> @@ -241,7 +241,7 @@ static int pmic_thermal_probe(struct platform_device 
>> *pdev)
>> }
>>
>> regmap = pmic->regmap;
>> -   regmap_irq_chip = pmic->irq_chip_data_level2;
>> +   regmap_irq_chip = pmic->irq_chip_data;
>>
>> pmic_irq_count = 0;
>> while ((irq = platform_get_irq(pdev, pmic_irq_count)) != -ENXIO) {
>> --
>> 2.7.4
>>
>
>
>
> --
> With Best Regards,
> Andy Shevchenko



-- 
Sathya
--
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: [PATCH 2/3] usb: typec: Add support for UCSI interface

[Greg KH]

On Thu, May 25, 2017 at 06:20:16AM -0700, Guenter Roeck wrote:
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> 
> Any preference in usb about alphabetic order of include files ?

Nope, whatever order the author wants to put them in is fine with me.
I'm not _that_ pedantic :)

--
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: [PATCH v5 0/8] mfd: intel_soc_pmic_bxtwc: Add chained IRQ support

[Andy Shevchenko]

On Thu, Jun 1, 2017 at 1:37 AM,
 wrote:
> From: Kuppuswamy Sathyanarayanan 
>
> Following patch set adds chained IRQ support to WCOVE PMIC driver.

I commented some patches, the rest looks okay.
Please, address and send new version.

-- 
With Best Regards,
Andy Shevchenko
--
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: [PATCH v5 7/8] mfd: intel_soc_pmic_bxtwc: Use chained irqs for second level irq chips

[Andy Shevchenko]

On Thu, Jun 1, 2017 at 1:37 AM,
 wrote:
> From: Kuppuswamy Sathyanarayanan 
>
> Whishkey cove PMIC has support to mask/unmask interrupts at two levels.
> At first level we can mask/unmask interrupt domains like TMU, GPIO, ADC,
> CHGR, BCU THERMAL and PWRBTN and at second level, it provides facility
> to mask/unmask individual interrupts belong each of this domain. For
> example, in case of TMU, at first level we have TMU interrupt domain,
> and at second level we have two interrupts, wake alarm, system alarm that
> belong to the TMU interrupt domain.
>
> Currently, in this driver all first level irqs are registered as part of
> irq chip(bxtwc_regmap_irq_chip). By default, after you register the irq
> chip from your driver, all irqs in that chip will masked and can only be
> enabled if that irq is requested using request_irq call. This is the
> default Linux irq behavior model. And whenever a dependent device that
> belongs to PMIC requests only the second level irq and not explicitly
> unmask the first level irq, then in essence the second level irq will
> still be disabled. For example, if TMU device driver request wake_alarm
> irq and not explicitly unmask TMU level 1 irq then according to the default
> Linux irq model,  wake_alarm irq will still be disabled. So the proper
> solution to fix this issue is to use the chained irq chip concept. We
> should chain all the second level chip irqs to the corresponding first
> level irq. To do this, we need to create separate irq chips for every
> group of second level irqs.
>
> In case of TMU, when adding second level irq chip, instead of using pmic
> irq we should use the corresponding first level irq. So the following
> code will change from

pmic -> PMIC
irq -> IRQ
irqs -> IRQs

These do apply to entire commit message.

>
> ret = regmap_add_irq_chip(pmic->regmap, pmic->irq, ...)
>
> to,
>
> virq = regmap_irq_get_virq(>irq_chip_data, BXTWC_TMU_LVL1_IRQ);
>
> ret = regmap_add_irq_chip(pmic->regmap, virq, ...)
>
> In case of typec wcove driver, Since USBC IRQ is moved under charger level2
> irq chip. We should use charger irq chip(irq_chip_data_chgr) to get the USBC
> virtual IRQ number.

typec wcove -> Whiskey Cove Type-C

> +enum bxtwc_irqs_tmu {
> +   BXTWC_TMU_IRQ = 0,
> +};

> -enum bxtwc_irqs_tmu {
> -   BXTWC_TMU_IRQ = 0,

Leave it on the same place it will make patch a bit more cleaner.

> +static const struct regmap_irq bxtwc_regmap_irqs_tmu[] = {
> +   REGMAP_IRQ_REG(BXTWC_TMU_IRQ, 0, 0x06),
> +};

> -static const struct regmap_irq bxtwc_regmap_irqs_tmu[] = {
> -   REGMAP_IRQ_REG(BXTWC_TMU_IRQ, 0, 0x06),

Ditto.

> +static int bxtwc_add_chained_irq_chip(struct intel_soc_pmic *pmic,
> +   struct regmap_irq_chip_data *pdata,
> +   int pirq, int irq_flags,
> +   const struct regmap_irq_chip *chip,
> +   struct regmap_irq_chip_data **data)
> +{
> +   int irq;
> +
> +   irq = regmap_irq_get_virq(pdata, pirq);
> +   if (irq < 0) {
> +   dev_err(pmic->dev, "failed to get virtual interrupt:%d\n", 
> irq);

Follow below pattern, i.e. "Failed to ..."

Moreover, it would be useful to see for which interrupt we are trying
to get a virtual one.
chip->name + pirq I guess would give us a thing.

> +   return irq;
> +   }
> +
> +   return devm_regmap_add_irq_chip(pmic->dev, pmic->regmap, irq, 
> irq_flags,
> +   0, chip, data);
> +}

-- 
With Best Regards,
Andy Shevchenko
--
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: [PATCH v5 6/8] mfd: intel_soc_pmic_bxtwc: Utilize devm_* functions in driver probe

[Andy Shevchenko]

On Thu, Jun 1, 2017 at 1:37 AM,
 wrote:
> Cleanup the resource allocation/free code in probe function by using
> devm_* calls.

This change is okay.

Reviewed-by: Andy Shevchenko 

> Signed-off-by: Kuppuswamy Sathyanarayanan 
> 
> Acked-for-MFD-by: Lee Jones 
> ---
>  drivers/mfd/intel_soc_pmic_bxtwc.c | 54 
> +-
>  1 file changed, 18 insertions(+), 36 deletions(-)
>
> Changes since v1:
>  * None
>
> Changes since v2:
>  * Rebased on top of latest release.
>
> Changes since v3:
>  * None
>
> diff --git a/drivers/mfd/intel_soc_pmic_bxtwc.c 
> b/drivers/mfd/intel_soc_pmic_bxtwc.c
> index af11c43..feeda6e 100644
> --- a/drivers/mfd/intel_soc_pmic_bxtwc.c
> +++ b/drivers/mfd/intel_soc_pmic_bxtwc.c
> @@ -399,45 +399,44 @@ static int bxtwc_probe(struct platform_device *pdev)
> return ret;
> }
>
> -   ret = regmap_add_irq_chip(pmic->regmap, pmic->irq,
> - IRQF_ONESHOT | IRQF_SHARED,
> - 0, _regmap_irq_chip,
> - >irq_chip_data);
> +   ret = devm_regmap_add_irq_chip(>dev, pmic->regmap, pmic->irq,
> +  IRQF_ONESHOT | IRQF_SHARED,
> +  0, _regmap_irq_chip,
> +  >irq_chip_data);
> if (ret) {
> dev_err(>dev, "Failed to add IRQ chip\n");
> return ret;
> }
>
> -   ret = regmap_add_irq_chip(pmic->regmap, pmic->irq,
> - IRQF_ONESHOT | IRQF_SHARED,
> - 0, _regmap_irq_chip_level2,
> - >irq_chip_data_level2);
> +   ret = devm_regmap_add_irq_chip(>dev, pmic->regmap, pmic->irq,
> +  IRQF_ONESHOT | IRQF_SHARED,
> +  0, _regmap_irq_chip_level2,
> +  >irq_chip_data_level2);
> if (ret) {
> dev_err(>dev, "Failed to add secondary IRQ chip\n");
> -   goto err_irq_chip_level2;
> +   return ret;
> }
>
> -   ret = regmap_add_irq_chip(pmic->regmap, pmic->irq,
> - IRQF_ONESHOT | IRQF_SHARED,
> - 0, _regmap_irq_chip_tmu,
> - >irq_chip_data_tmu);
> +   ret = devm_regmap_add_irq_chip(>dev, pmic->regmap, pmic->irq,
> +  IRQF_ONESHOT | IRQF_SHARED,
> +  0, _regmap_irq_chip_tmu,
> +  >irq_chip_data_tmu);
> if (ret) {
> dev_err(>dev, "Failed to add TMU IRQ chip\n");
> -   goto err_irq_chip_tmu;
> +   return ret;
> }
>
> -   ret = mfd_add_devices(>dev, PLATFORM_DEVID_NONE, bxt_wc_dev,
> - ARRAY_SIZE(bxt_wc_dev), NULL, 0,
> - NULL);
> +   ret = devm_mfd_add_devices(>dev, PLATFORM_DEVID_NONE, 
> bxt_wc_dev,
> +  ARRAY_SIZE(bxt_wc_dev), NULL, 0, NULL);
> if (ret) {
> dev_err(>dev, "Failed to add devices\n");
> -   goto err_mfd;
> +   return ret;
> }
>
> ret = sysfs_create_group(>dev.kobj, _group);
> if (ret) {
> dev_err(>dev, "Failed to create sysfs group %d\n", ret);
> -   goto err_sysfs;
> +   return ret;
> }
>
> /*
> @@ -451,28 +450,11 @@ static int bxtwc_probe(struct platform_device *pdev)
> BXTWC_MIRQLVL1_MCHGR, 0);
>
> return 0;
> -
> -err_sysfs:
> -   mfd_remove_devices(>dev);
> -err_mfd:
> -   regmap_del_irq_chip(pmic->irq, pmic->irq_chip_data_tmu);
> -err_irq_chip_tmu:
> -   regmap_del_irq_chip(pmic->irq, pmic->irq_chip_data_level2);
> -err_irq_chip_level2:
> -   regmap_del_irq_chip(pmic->irq, pmic->irq_chip_data);
> -
> -   return ret;
>  }
>
>  static int bxtwc_remove(struct platform_device *pdev)
>  {
> -   struct intel_soc_pmic *pmic = dev_get_drvdata(>dev);
> -
> sysfs_remove_group(>dev.kobj, _group);
> -   mfd_remove_devices(>dev);
> -   regmap_del_irq_chip(pmic->irq, pmic->irq_chip_data);
> -   regmap_del_irq_chip(pmic->irq, pmic->irq_chip_data_level2);
> -   regmap_del_irq_chip(pmic->irq, pmic->irq_chip_data_tmu);
>
> return 0;
>  }
> --
> 2.7.4
>



-- 
With Best Regards,
Andy Shevchenko
--
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: [PATCH v5 5/8] gpio: gpio-wcove: Use first level PMIC GPIO irq

[Andy Shevchenko]

On Thu, Jun 1, 2017 at 1:37 AM,
 wrote:
> From: Kuppuswamy Sathyanarayanan 
>
> PMIC mfd driver only exports first level irq for GPIO device.
> But currently we are reading the irqs from the second level irq
> chip, So this patch fixes this issue by adding support to use
> first level PMIC GPIO irq.
>

Shouldn't be this squashed to patch 4?

> Signed-off-by: Kuppuswamy Sathyanarayanan 
> 
> Acked-by: Linus Walleij 
> ---
>  drivers/gpio/gpio-wcove.c | 14 +-
>  1 file changed, 13 insertions(+), 1 deletion(-)
>
> Changes since v1:
>  * used correct mask for GPIO0 and GPIO1 interrupts
>
> Changes since v2:
>  * Rebased on top of latest release.
>  * Removed IRQ0 and IRQ1 mask defines.
>
> Changes since v3:
>  * None
>
> diff --git a/drivers/gpio/gpio-wcove.c b/drivers/gpio/gpio-wcove.c
> index 7b1bc20..bba7704 100644
> --- a/drivers/gpio/gpio-wcove.c
> +++ b/drivers/gpio/gpio-wcove.c
> @@ -401,7 +401,7 @@ static int wcove_gpio_probe(struct platform_device *pdev)
> if (!wg)
> return -ENOMEM;
>
> -   wg->regmap_irq_chip = pmic->irq_chip_data_level2;
> +   wg->regmap_irq_chip = pmic->irq_chip_data;
>
> platform_set_drvdata(pdev, wg);
>
> @@ -449,6 +449,18 @@ static int wcove_gpio_probe(struct platform_device *pdev)
>
> gpiochip_set_nested_irqchip(>chip, _irqchip, virq);
>
> +   /* Enable GPIO0 interrupts */
> +   ret = regmap_update_bits(wg->regmap, IRQ_MASK_BASE, GPIO_IRQ0_MASK,
> +0x00);
> +   if (ret)
> +   return ret;
> +
> +   /* Enable GPIO1 interrupts */
> +   ret = regmap_update_bits(wg->regmap, IRQ_MASK_BASE + 1, 
> GPIO_IRQ1_MASK,
> +0x00);
> +   if (ret)
> +   return ret;
> +
> return 0;
>  }
>
> --
> 2.7.4
>



-- 
With Best Regards,
Andy Shevchenko
--
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: [PATCH v5 3/8] thermal: intel_bxt_pmic_thermal: Use first level PMIC thermal irq

[Andy Shevchenko]

On Thu, Jun 1, 2017 at 1:37 AM,
 wrote:
> From: Kuppuswamy Sathyanarayanan 
>
> PMIC mfd driver only exports first level irq for thermal device.
> But currently we are reading the irqs from the second level irq
> chip, So this patch fixes this issue by adding support to use
> first level PMIC thermal irq.
>

Shouldn't be this squashed to patch 2?

> Signed-off-by: Kuppuswamy Sathyanarayanan 
> 
> Acked-by: Zhang Rui 
> ---
>  drivers/thermal/intel_bxt_pmic_thermal.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> Changes since v1:
>  * None
>
> Changes since v2:
>  * Rebased on top of latest release.
>
> Changes since v3:
>  * Rebased on top of latest release.
>
> diff --git a/drivers/thermal/intel_bxt_pmic_thermal.c 
> b/drivers/thermal/intel_bxt_pmic_thermal.c
> index 0f19a39..ef6b322 100644
> --- a/drivers/thermal/intel_bxt_pmic_thermal.c
> +++ b/drivers/thermal/intel_bxt_pmic_thermal.c
> @@ -241,7 +241,7 @@ static int pmic_thermal_probe(struct platform_device 
> *pdev)
> }
>
> regmap = pmic->regmap;
> -   regmap_irq_chip = pmic->irq_chip_data_level2;
> +   regmap_irq_chip = pmic->irq_chip_data;
>
> pmic_irq_count = 0;
> while ((irq = platform_get_irq(pdev, pmic_irq_count)) != -ENXIO) {
> --
> 2.7.4
>



-- 
With Best Regards,
Andy Shevchenko
--
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 1/1] usb/early: Remove trace_printk() callers in xhci-dbc

[Lu Baolu]

Trace_printk() was used to log debug messages in xhci-dbc.c where
printk() isn't feasible. As there should not be a single caller to
trace_printk() in normal kernels, replace them with empty functions.

Cc: Vlastimil Babka 
Cc: Steven Rostedt 
Cc: Peter Zijlstra 
Cc: Greg Kroah-Hartman 
Signed-off-by: Lu Baolu 
---
 drivers/usb/early/xhci-dbc.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/usb/early/xhci-dbc.c b/drivers/usb/early/xhci-dbc.c
index 1268818..12fe70b 100644
--- a/drivers/usb/early/xhci-dbc.c
+++ b/drivers/usb/early/xhci-dbc.c
@@ -32,7 +32,6 @@
 static struct xdbc_state xdbc;
 static bool early_console_keep;
 
-#define XDBC_TRACE
 #ifdef XDBC_TRACE
 #definexdbc_trace  trace_printk
 #else
-- 
2.7.4

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