Re: [PATCH] usb: host: ehci: workaround PME bug on AMD EHCI controller

[Kai-Heng Feng]

On Fri, Jun 9, 2017 at 10:43 PM, Alan Stern  wrote:
> On Fri, 9 Jun 2017, Kai-Heng Feng wrote:
>
>> As Alan Stern points out [1], the PME signal is not enabled when
>> controller is in D3, therefore it's not being woken up when new deivces
>> get plugged in.
>>
>> Workaround this bug by preventing the controller enters D3 power state.
>>
>> [1] https://www.spinics.net/lists/linux-usb/msg157462.html
>>
>> Signed-off-by: Kai-Heng Feng 
>> ---
>>  drivers/usb/host/ehci-pci.c | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/usb/host/ehci-pci.c b/drivers/usb/host/ehci-pci.c
>> index 93326974ff4b..616685f83954 100644
>> --- a/drivers/usb/host/ehci-pci.c
>> +++ b/drivers/usb/host/ehci-pci.c
>> @@ -181,6 +181,8 @@ static int ehci_pci_setup(struct usb_hcd *hcd)
>>   if (pdev->device == 0x7808) {
>>   ehci->use_dummy_qh = 1;
>>   ehci_info(ehci, "applying AMD SB700/SB800/Hudson-2/3 
>> EHCI dummy qh workaround\n");
>> +
>> + pdev->dev_flags |= PCI_DEV_FLAGS_NO_D3;
>>   }
>>   break;
>>   case PCI_VENDOR_ID_VIA:
>
> Is this really the right solution?  Maybe it would be better to allow
> the controller to go into D3 provided no wakeup signal is needed.  You
> could do:
>
> device_set_wakeup_capable(&pdev->dev, 0);

This doesn't work.
After applying this function, still nothing happens when devices get plugged in.
IIUC this function disable the wakeup function, but what I want to do
here is to have PME signal works even when runtime PM is enabled.

I also saw some legacy PCI PM stuff, so I also tried:
device_set_wakeup_capable(&pdev->dev, 1);
...doesn't work either.

>
> Another alternative is to put the controller into D2 instead of D3, but
> (1) I don't know how to do that, and (2) we don't know if wakeup
> signalling works any better in D2 than it does in D3.

I'll try if D2 works.

Thanks for the review.

>
> 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: Piping f_acm to real hardware

[Greg KH]

On Sun, Jun 11, 2017 at 11:41:02PM +0300, Tal Shorer wrote:
> I'm currently working on a project where I'd like to have an omap board
> running linux be a usb-to-uart converter (using f_acm). I have an
> application that holds both the ttyGS* and the ttyO* port (the physical
> uart port) open, polls for readable data, and writes any incoming data
> to the other side.
> 
> I'd also like the host to be able to configure baudrate, parity, etc.
> My thought on how to achieve this is to modify how the ttyGS* ports
> behave by adding a POLLPRI event when set_line_coding is received. In
> order to do that several steps will have to be taken:
> - one of:
> 1. add a poll() callback to struct tty_operations and call it in
> n_tty_poll(). u_serial and f_acm will implement required
> callbacks to allow returning POLLPRI when necessary.
> 2. add a flag to struct tty_struct that indicates an exceptional
> condition and make n_tty_poll() return POLLPRI if that flag is
> set. this will also require a new wait queue to allow us to wait
> for such an event.
> - after receiving SET_LINE_CODING (and verifying it), set whatever flag
> is necessary to wake the user with POLLPRI.
> - implement the ioctl() callback in u_serial and f_acm to allow the
> user to get the line coding set by the host, with which it can
> configure the hardware port accordingly.
> 
> Does my approach make sense? Assuming I do that, which tree should such
> a series be sent to? usb-gadget? tty?

Why not just do it all in userspace, a simple "loopback" program should
be able to handle this.  If not, look into the 'serdev' interface now in
the kernel, that might help out a lot with what you want to do here.

And I really doubt you need to touch the tty core or ldisc for this,
that seems a bit extreme.

good luck!

greg k-h
--
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 v1] net/phy: Make phy_ethtool_ksettings_get return void

[Yuval Shaia]

Make return value void since function never return meaningfull value

Signed-off-by: Yuval Shaia 
Acked-by: Sergei Shtylyov 
---
Re-sending since last time forgot to add netdev-list
v0 ->v1:
* These files were missing in v0
* drivers/net/ethernet/renesas/ravb_main.c
* drivers/net/ethernet/renesas/sh_eth.c
* drivers/net/ethernet/ti/netcp_ethss.c
* Add Acked-by: Sergei Shtylyov
---
 drivers/net/ethernet/broadcom/b44.c|  3 ++-
 drivers/net/ethernet/broadcom/bcm63xx_enet.c   |  3 ++-
 drivers/net/ethernet/broadcom/genet/bcmgenet.c |  4 +++-
 drivers/net/ethernet/broadcom/tg3.c|  4 +++-
 drivers/net/ethernet/freescale/dpaa/dpaa_ethtool.c |  6 ++
 drivers/net/ethernet/freescale/ucc_geth_ethtool.c  |  4 +++-
 drivers/net/ethernet/marvell/mv643xx_eth.c |  5 ++---
 drivers/net/ethernet/renesas/ravb_main.c   | 14 +++---
 drivers/net/ethernet/renesas/sh_eth.c  |  5 ++---
 drivers/net/ethernet/ti/cpsw.c |  9 +
 drivers/net/ethernet/ti/netcp_ethss.c  |  8 +++-
 drivers/net/phy/phy.c  | 10 +-
 drivers/net/usb/lan78xx.c  |  2 +-
 include/linux/phy.h|  4 ++--
 net/dsa/slave.c|  9 +
 15 files changed, 47 insertions(+), 43 deletions(-)

diff --git a/drivers/net/ethernet/broadcom/b44.c 
b/drivers/net/ethernet/broadcom/b44.c
index 5b95bb4..9873d2d 100644
--- a/drivers/net/ethernet/broadcom/b44.c
+++ b/drivers/net/ethernet/broadcom/b44.c
@@ -1836,7 +1836,8 @@ static int b44_get_link_ksettings(struct net_device *dev,
 
if (bp->flags & B44_FLAG_EXTERNAL_PHY) {
BUG_ON(!dev->phydev);
-   return phy_ethtool_ksettings_get(dev->phydev, cmd);
+   phy_ethtool_ksettings_get(dev->phydev, cmd);
+   return 0;
}
 
supported = (SUPPORTED_Autoneg);
diff --git a/drivers/net/ethernet/broadcom/bcm63xx_enet.c 
b/drivers/net/ethernet/broadcom/bcm63xx_enet.c
index 50d88d3..34ebb40 100644
--- a/drivers/net/ethernet/broadcom/bcm63xx_enet.c
+++ b/drivers/net/ethernet/broadcom/bcm63xx_enet.c
@@ -1453,7 +1453,8 @@ static int bcm_enet_get_link_ksettings(struct net_device 
*dev,
if (priv->has_phy) {
if (!dev->phydev)
return -ENODEV;
-   return phy_ethtool_ksettings_get(dev->phydev, cmd);
+   phy_ethtool_ksettings_get(dev->phydev, cmd);
+   return 0;
} else {
cmd->base.autoneg = 0;
cmd->base.speed = (priv->force_speed_100) ?
diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.c 
b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
index a205a9f..daca1c9 100644
--- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
+++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
@@ -477,7 +477,9 @@ static int bcmgenet_get_link_ksettings(struct net_device 
*dev,
if (!priv->phydev)
return -ENODEV;
 
-   return phy_ethtool_ksettings_get(priv->phydev, cmd);
+   phy_ethtool_ksettings_get(priv->phydev, cmd);
+
+   return 0;
 }
 
 static int bcmgenet_set_link_ksettings(struct net_device *dev,
diff --git a/drivers/net/ethernet/broadcom/tg3.c 
b/drivers/net/ethernet/broadcom/tg3.c
index 537d571..d600c41 100644
--- a/drivers/net/ethernet/broadcom/tg3.c
+++ b/drivers/net/ethernet/broadcom/tg3.c
@@ -12097,7 +12097,9 @@ static int tg3_get_link_ksettings(struct net_device 
*dev,
if (!(tp->phy_flags & TG3_PHYFLG_IS_CONNECTED))
return -EAGAIN;
phydev = mdiobus_get_phy(tp->mdio_bus, tp->phy_addr);
-   return phy_ethtool_ksettings_get(phydev, cmd);
+   phy_ethtool_ksettings_get(phydev, cmd);
+
+   return 0;
}
 
supported = (SUPPORTED_Autoneg);
diff --git a/drivers/net/ethernet/freescale/dpaa/dpaa_ethtool.c 
b/drivers/net/ethernet/freescale/dpaa/dpaa_ethtool.c
index 15571e2..aad825088 100644
--- a/drivers/net/ethernet/freescale/dpaa/dpaa_ethtool.c
+++ b/drivers/net/ethernet/freescale/dpaa/dpaa_ethtool.c
@@ -75,16 +75,14 @@ static char dpaa_stats_global[][ETH_GSTRING_LEN] = {
 static int dpaa_get_link_ksettings(struct net_device *net_dev,
   struct ethtool_link_ksettings *cmd)
 {
-   int err;
-
if (!net_dev->phydev) {
netdev_dbg(net_dev, "phy device not initialized\n");
return 0;
}
 
-   err = phy_ethtool_ksettings_get(net_dev->phydev, cmd);
+   phy_ethtool_ksettings_get(net_dev->phydev, cmd);
 
-   return err;
+   return 0;
 }
 
 static int dpaa_set_link_ksettings(struct net_device *net_dev,
diff --git a/drivers/net/ethernet/freescale/ucc_geth_ethtool.c 
b/drivers/net/ethernet/freescale/ucc_geth_ethtool.c
index b642990..4df282e 100644

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

[Tony Lindgren]

Commit 8ae904e3c236 ("phy: cpcap-usb: Add CPCAP PMIC USB support")
is missing return statement as noted by Colin Ian King
. 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 
Signed-off-by: Tony Lindgren 
---
 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-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 v2] USB: qcserial: expose methods for modem control

[Johan Hovold]

On Sun, Jun 11, 2017 at 11:32:43PM -0700, mag...@gmail.com wrote:

Thanks for resending. The eaten-tabs issue is gone, but there are still
a few minor issues you should fix up.

> This is v2, attempting to correct formatting problems with the patch.

This type of meta information should not go in the commit message
itself and should therefore be placed below the cut-off-line (a "---"
line, below your Signed-off-by).

> The qcserial driver fails to expose the .tiocmget and .tiocmset methods 
> available from usb_wwan. These methods are required by ioctl commands dealing 
> with the modem control signals DTR, RTS, etc.

You need to wrap your commit-message lines at 72 cols or so.

> With these methods not set ioctl calls intended to control the DTR state will 
> fail. For example, pppd drops and raises DTR in preparation to dialing the 
> modem, which handles the case of the modem already being connected by making 
> it hang up and return to command mode. DTR control being unavailable will 
> lead to a protracted failure to connect as the modem will be stuck in a state 
> not responsive to command.
> 
> I have tested that with this patch the described case is handled 
> successfully. There is an analogous method for .ioctl available from usb_wwan 
> (as used in option.c) but I conservatively omitted that for lack of 
> familiarity.
> 
> Signed-off-by: Magnus Lynch 

And finally, your mail From field should match your Signed-off-by and is
currently lacking your name (this will be used for the author info in git).

Care to fix this up in a v3?

Thanks,
Johan
--
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 net-next 1/2] r8152: split rtl8152_resume function

[Hayes Wang]

Split rtl8152_resume() into rtl8152_runtime_resume() and
rtl8152_system_resume().

Signed-off-by: Hayes Wang 
---
 drivers/net/usb/r8152.c | 99 ++---
 1 file changed, 61 insertions(+), 38 deletions(-)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 5a02053..3257955 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -3686,6 +3686,61 @@ static bool delay_autosuspend(struct r8152 *tp)
return false;
 }
 
+static int rtl8152_runtime_resume(struct r8152 *tp)
+{
+   struct net_device *netdev = tp->netdev;
+
+   if (netif_running(netdev) && netdev->flags & IFF_UP) {
+   struct napi_struct *napi = &tp->napi;
+
+   tp->rtl_ops.autosuspend_en(tp, false);
+   napi_disable(napi);
+   set_bit(WORK_ENABLE, &tp->flags);
+
+   if (netif_carrier_ok(netdev)) {
+   if (rtl8152_get_speed(tp) & LINK_STATUS) {
+   rtl_start_rx(tp);
+   } else {
+   netif_carrier_off(netdev);
+   tp->rtl_ops.disable(tp);
+   netif_info(tp, link, netdev, "linking down\n");
+   }
+   }
+
+   napi_enable(napi);
+   clear_bit(SELECTIVE_SUSPEND, &tp->flags);
+   smp_mb__after_atomic();
+
+   if (!list_empty(&tp->rx_done))
+   napi_schedule(&tp->napi);
+
+   usb_submit_urb(tp->intr_urb, GFP_KERNEL);
+   } else {
+   if (netdev->flags & IFF_UP)
+   tp->rtl_ops.autosuspend_en(tp, false);
+
+   clear_bit(SELECTIVE_SUSPEND, &tp->flags);
+   }
+
+   return 0;
+}
+
+static int rtl8152_system_resume(struct r8152 *tp)
+{
+   struct net_device *netdev = tp->netdev;
+
+   netif_device_attach(netdev);
+
+   if (netif_running(netdev) && netdev->flags & IFF_UP) {
+   tp->rtl_ops.up(tp);
+   netif_carrier_off(netdev);
+   set_bit(WORK_ENABLE, &tp->flags);
+   usb_submit_urb(tp->intr_urb, GFP_KERNEL);
+   }
+
+   return 0;
+}
+
 static int rtl8152_runtime_suspend(struct r8152 *tp)
 {
struct net_device *netdev = tp->netdev;
@@ -3784,50 +3839,18 @@ static int rtl8152_suspend(struct usb_interface *intf, 
pm_message_t message)
 static int rtl8152_resume(struct usb_interface *intf)
 {
struct r8152 *tp = usb_get_intfdata(intf);
-   struct net_device *netdev = tp->netdev;
+   int ret;
 
mutex_lock(&tp->control);
 
-   if (!test_bit(SELECTIVE_SUSPEND, &tp->flags))
-   netif_device_attach(netdev);
-
-   if (netif_running(netdev) && netdev->flags & IFF_UP) {
-   if (test_bit(SELECTIVE_SUSPEND, &tp->flags)) {
-   struct napi_struct *napi = &tp->napi;
-
-   tp->rtl_ops.autosuspend_en(tp, false);
-   napi_disable(napi);
-   set_bit(WORK_ENABLE, &tp->flags);
-   if (netif_carrier_ok(netdev)) {
-   if (rtl8152_get_speed(tp) & LINK_STATUS) {
-   rtl_start_rx(tp);
-   } else {
-   netif_carrier_off(netdev);
-   tp->rtl_ops.disable(tp);
-   netif_info(tp, link, netdev,
-  "linking down\n");
-   }
-   }
-   napi_enable(napi);
-   clear_bit(SELECTIVE_SUSPEND, &tp->flags);
-   smp_mb__after_atomic();
-   if (!list_empty(&tp->rx_done))
-   napi_schedule(&tp->napi);
-   } else {
-   tp->rtl_ops.up(tp);
-   netif_carrier_off(netdev);
-   set_bit(WORK_ENABLE, &tp->flags);
-   }
-   usb_submit_urb(tp->intr_urb, GFP_KERNEL);
-   } else if (test_bit(SELECTIVE_SUSPEND, &tp->flags)) {
-   if (netdev->flags & IFF_UP)
-   tp->rtl_ops.autosuspend_en(tp, false);
-   clear_bit(SELECTIVE_SUSPEND, &tp->flags);
-   }
+   if (test_bit(SELECTIVE_SUSPEND, &tp->flags))
+   ret = rtl8152_runtime_resume(tp);
+   else
+   ret = rtl8152_system_resume(tp);
 
mutex_unlock(&tp->control);
 
-   return 0;
+   return ret;
 }
 
 static int rtl8152_reset_resume(struct usb_interface *intf)
-- 
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

[PATCH net-next 2/2] r8152: move calling delay_autosuspend function

[Hayes Wang]

Move calling delay_autosuspend() in rtl8152_runtime_suspend(). Calling
delay_autosuspend() as late as possible.

The original flows are
   1. check if the driver/device is busy now.
   2. set wake events.
   3. enter runtime suspend.

If the wake event occurs between (1) and (2), the device may miss it. Besides,
to avoid the runtime resume occurs after runtime suspend immediately, move the
checking to the end of rtl8152_runtime_suspend().

Signed-off-by: Hayes Wang 
---
 drivers/net/usb/r8152.c | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 3257955..fb6fa6e 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -3752,13 +3752,6 @@ static int rtl8152_runtime_suspend(struct r8152 *tp)
if (netif_running(netdev) && test_bit(WORK_ENABLE, &tp->flags)) {
u32 rcr = 0;
 
-   if (delay_autosuspend(tp)) {
-   clear_bit(SELECTIVE_SUSPEND, &tp->flags);
-   smp_mb__after_atomic();
-   ret = -EBUSY;
-   goto out1;
-   }
-
if (netif_carrier_ok(netdev)) {
u32 ocp_data;
 
@@ -3792,6 +3785,11 @@ static int rtl8152_runtime_suspend(struct r8152 *tp)
ocp_write_dword(tp, MCU_TYPE_PLA, PLA_RCR, rcr);
napi_enable(napi);
}
+
+   if (delay_autosuspend(tp)) {
+   rtl8152_runtime_resume(tp);
+   ret = -EBUSY;
+   }
}
 
 out1:
-- 
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

[PATCH net-next 0/2] r8152: adjust runtime suspend/resume

[Hayes Wang]

Improve the flow about runtime suspend/resume and make the code
easy to read.

Hayes Wang (2):
  r8152: split rtl8152_resume function
  r8152: move calling delay_autosuspend function

 drivers/net/usb/r8152.c | 107 
 1 file changed, 62 insertions(+), 45 deletions(-)

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

Re: usb/serial/option.c: Please add new vendor and product id 1c9e:9801

[Johan Hovold]

On Sun, Jun 11, 2017 at 07:50:46PM +0300, Teemu Likonen wrote:
> Hello USB maintainers!
> 
> I have a Telewell TW-3G HSPA+ USB modem which works with driver
> usb/serial/option.c. However, the device is not automatically detected.

Thanks for reporting this.

> I'm a newbie in these driver things but got a suggestion that I should
> report the device's vendor and product IDs here so you could perhaps
> include the info in the driver. So, here it is:
> 
> 1c9e:9801

What is the output of "lsusb -v" for this device?

Thanks,
Johan
--
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: usb/serial/option.c: Please add new vendor and product id 1c9e:9801

[Teemu Likonen]

Johan Hovold [2017-06-12 10:24:11+02] wrote:

> What is the output of "lsusb -v" for this device?

Thanks and here it comes:


Bus 001 Device 009: ID 1c9e:9801 OMEGA TECHNOLOGY 
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass0 (Defined at Interface level)
  bDeviceSubClass 0 
  bDeviceProtocol 0 
  bMaxPacketSize064
  idVendor   0x1c9e OMEGA TECHNOLOGY
  idProduct  0x9801 
  bcdDevice0.00
  iManufacturer   3 USB Modem
  iProduct2 USB Modem
  iSerial 4 1234567890ABCDEF
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength  161
bNumInterfaces  6
bConfigurationValue 1
iConfiguration  1 Modem Configuration
bmAttributes 0xe0
  Self Powered
  Remote Wakeup
MaxPower  500mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   2
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass255 Vendor Specific Subclass
  bInterfaceProtocol255 Vendor Specific Protocol
  iInterface  0 
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval  32
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01  EP 1 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval  32
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber1
  bAlternateSetting   0
  bNumEndpoints   3
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass255 Vendor Specific Subclass
  bInterfaceProtocol255 Vendor Specific Protocol
  iInterface  0 
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82  EP 2 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0040  1x 64 bytes
bInterval   5
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83  EP 3 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval  32
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02  EP 2 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval  32
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber2
  bAlternateSetting   0
  bNumEndpoints   2
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass255 Vendor Specific Subclass
  bInterfaceProtocol255 Vendor Specific Protocol
  iInterface  0 
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x84  EP 4 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval  32
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03  EP 3 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval  32
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber3
  bAlternateSetting   0
  bNumEndpoints   3
  bInterfaceClass  

[PATCH] USB: serial: option: add Telewell TW-3G HSPA+ device id

[Johan Hovold]

Add device-id entry for the Telewell TW-3G HSPA+ modem, which uses the
Longcheer vendor id.

Reported-by: Teemu Likonen 
Cc: stable 
Signed-off-by: Johan Hovold 
---
 drivers/usb/serial/option.c | 4 
 1 file changed, 4 insertions(+)

Teemu, would you be able to test this patch?

Thanks,
Johan


diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index 3bf61acfc26b..b48f3557b2e4 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -388,6 +388,9 @@ static void option_instat_callback(struct urb *urb);
 /* SpeedUp SU9800 usb 3g modem */
 #define SPEEDUP_PRODUCT_SU9800 0x9800
 
+/* Telewell */
+#define TELEWELL_PRODUCT_TW_3G_HSPAP   0x9801
+
 /* Haier products */
 #define HAIER_VENDOR_ID0x201e
 #define HAIER_PRODUCT_CE81B0x10f8
@@ -1877,6 +1880,7 @@ static const struct usb_device_id option_ids[] = {
  .driver_info = (kernel_ulong_t)&four_g_w100_blacklist
},
{ USB_DEVICE_INTERFACE_CLASS(LONGCHEER_VENDOR_ID, 
SPEEDUP_PRODUCT_SU9800, 0xff) },
+   { USB_DEVICE_INTERFACE_CLASS(LONGCHEER_VENDOR_ID, 
TELEWELL_PRODUCT_TW_3G_HSPAP, 0xff) },
{ USB_DEVICE(LONGCHEER_VENDOR_ID, ZOOM_PRODUCT_4597) },
{ USB_DEVICE(LONGCHEER_VENDOR_ID, IBALL_3_5G_CONNECT) },
{ USB_DEVICE(HAIER_VENDOR_ID, HAIER_PRODUCT_CE100) },
-- 
2.13.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: usb/serial/option.c: Please add new vendor and product id 1c9e:9801

[Lars Melin]

On 2017-06-12 15:46, Teemu Likonen wrote:

Johan Hovold [2017-06-12 10:24:11+02] wrote:


What is the output of "lsusb -v" for this device?




Interface usage:

MI_00 Wireless Diagnostics
MI_01 Wireless Modem
MI_02 Wireless Application
MI_03 Wireless Data Device Ethernet Adapter (qmi_wwan)
MI_04 USB Mass Storage Device
MI_05 USB Mass Storage Device


/Lars


--
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] 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
> . 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 
> Signed-off-by: Tony Lindgren 

Reviewed-by: Sebastian Reichel 

-- 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] USB: serial: option: add Telewell TW-3G HSPA+ device id

[Bjørn Mork]

Johan Hovold  writes:

> Add device-id entry for the Telewell TW-3G HSPA+ modem, which uses the
> Longcheer vendor id.
>
> Reported-by: Teemu Likonen 
> Cc: stable 
> Signed-off-by: Johan Hovold 
> ---
>  drivers/usb/serial/option.c | 4 
>  1 file changed, 4 insertions(+)
>
> Teemu, would you be able to test this patch?
>
> Thanks,
> Johan
>
>
> diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
> index 3bf61acfc26b..b48f3557b2e4 100644
> --- a/drivers/usb/serial/option.c
> +++ b/drivers/usb/serial/option.c
> @@ -388,6 +388,9 @@ static void option_instat_callback(struct urb *urb);
>  /* SpeedUp SU9800 usb 3g modem */
>  #define SPEEDUP_PRODUCT_SU9800   0x9800
>  
> +/* Telewell */
> +#define TELEWELL_PRODUCT_TW_3G_HSPAP 0x9801
> +
>  /* Haier products */
>  #define HAIER_VENDOR_ID  0x201e
>  #define HAIER_PRODUCT_CE81B  0x10f8
> @@ -1877,6 +1880,7 @@ static const struct usb_device_id option_ids[] = {
> .driver_info = (kernel_ulong_t)&four_g_w100_blacklist
>   },
>   { USB_DEVICE_INTERFACE_CLASS(LONGCHEER_VENDOR_ID, 
> SPEEDUP_PRODUCT_SU9800, 0xff) },
> + { USB_DEVICE_INTERFACE_CLASS(LONGCHEER_VENDOR_ID, 
> TELEWELL_PRODUCT_TW_3G_HSPAP, 0xff) },
>   { USB_DEVICE(LONGCHEER_VENDOR_ID, ZOOM_PRODUCT_4597) },
>   { USB_DEVICE(LONGCHEER_VENDOR_ID, IBALL_3_5G_CONNECT) },
>   { USB_DEVICE(HAIER_VENDOR_ID, HAIER_PRODUCT_CE100) },


I was looking at the Windows drivers on
https://www.telewell.fi/files/tw-3g_hspa_ajuri.zip
whiche have this among the serial stuff:

[QCOM]
%qcwwan.DeviceDesc%= qcwwan.ndi, USB\VID_1C9E&PID_9801&MI_03
%qcwwan.DeviceDesc%= qcwwan.ndi, USB\VID_1C9E&PID_9803&MI_04
%qcwwan.DeviceDesc%= qcwwan.ndi, USB\VID_1C9E&PID_9806&MI_05
%qcwwan.DeviceDesc%= qcwwan.ndi, USB\VID_1C9E&PID_9808&MI_06

%qcwwan.DeviceDesc%= qcwwan.ndi, USB\VID_1C9E&PID_9866&MI_03
%qcwwan.DeviceDesc%= qcwwan.ndi, USB\VID_1C9E&PID_9868&MI_04
%qcwwan.DeviceDesc%= qcwwan.ndi, USB\VID_1C9E&PID_9869&MI_05


It's not clear what type of driver the 'cmntnet.sys' installed by this
is, but I wonder if it maybe is QMI based on the 'qc' prefix?


And maybe we should add the remaining device IDs too?



Bjørn
--
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: usb/serial/option.c: Please add new vendor and product id 1c9e:9801

[Johan Hovold]

On Mon, Jun 12, 2017 at 04:34:56PM +0700, Lars Melin wrote:
> On 2017-06-12 15:46, Teemu Likonen wrote:
> > Johan Hovold [2017-06-12 10:24:11+02] wrote:
> > 
> >> What is the output of "lsusb -v" for this device?
> > 
> 
> Interface usage:
> 
> MI_00 Wireless Diagnostics
> MI_01 Wireless Modem
> MI_02 Wireless Application
> MI_03 Wireless Data Device Ethernet Adapter (qmi_wwan)
> MI_04 USB Mass Storage Device
> MI_05 USB Mass Storage Device

Ah, ok, thanks. So we need to blacklist interface 3 and update qmi_wwan.
I'll respin the patch.

Thanks,
Johan
--
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] USB: serial: option: add Telewell TW-3G HSPA+ device id

[Teemu Likonen]

Johan Hovold [2017-06-12 11:16:12+02] wrote:

> Add device-id entry for the Telewell TW-3G HSPA+ modem, which uses the
> Longcheer vendor id.
>
> Reported-by: Teemu Likonen 
> Cc: stable 
> Signed-off-by: Johan Hovold 
> ---
>  drivers/usb/serial/option.c | 4 
>  1 file changed, 4 insertions(+)
>
> Teemu, would you be able to test this patch?

It seems that you will do another patch but I'll confirm anyway that
this works. I compiled the mainline kernel v4.12-rc5 with this patch.

> diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
> index 3bf61acfc26b..b48f3557b2e4 100644
> --- a/drivers/usb/serial/option.c
> +++ b/drivers/usb/serial/option.c
> @@ -388,6 +388,9 @@ static void option_instat_callback(struct urb *urb);
>  /* SpeedUp SU9800 usb 3g modem */
>  #define SPEEDUP_PRODUCT_SU9800   0x9800
>  
> +/* Telewell */
> +#define TELEWELL_PRODUCT_TW_3G_HSPAP 0x9801
> +
>  /* Haier products */
>  #define HAIER_VENDOR_ID  0x201e
>  #define HAIER_PRODUCT_CE81B  0x10f8
> @@ -1877,6 +1880,7 @@ static const struct usb_device_id option_ids[] = {
> .driver_info = (kernel_ulong_t)&four_g_w100_blacklist
>   },
>   { USB_DEVICE_INTERFACE_CLASS(LONGCHEER_VENDOR_ID, 
> SPEEDUP_PRODUCT_SU9800, 0xff) },
> + { USB_DEVICE_INTERFACE_CLASS(LONGCHEER_VENDOR_ID, 
> TELEWELL_PRODUCT_TW_3G_HSPAP, 0xff) },
>   { USB_DEVICE(LONGCHEER_VENDOR_ID, ZOOM_PRODUCT_4597) },
>   { USB_DEVICE(LONGCHEER_VENDOR_ID, IBALL_3_5G_CONNECT) },
>   { USB_DEVICE(HAIER_VENDOR_ID, HAIER_PRODUCT_CE100) },


signature.asc
Description: PGP signature

Re: [PATCH] USB: serial: option: add Telewell TW-3G HSPA+ device id

[Oliver Neukum]

Am Montag, den 12.06.2017, 11:50 +0200 schrieb Bjørn Mork:
> It's not clear what type of driver the 'cmntnet.sys' installed by this
> is, but I wonder if it maybe is QMI based on the 'qc' prefix?

QualCom

I am afraid it says nothing about the protocol.

Regards
Oliver

--
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] usb: host: ehci: workaround PME bug on AMD EHCI controller

[Kai-Heng Feng]

On Mon, Jun 12, 2017 at 3:04 PM, Kai-Heng Feng
 wrote:
> On Fri, Jun 9, 2017 at 10:43 PM, Alan Stern  wrote:
>> On Fri, 9 Jun 2017, Kai-Heng Feng wrote:
>>
>> Is this really the right solution?  Maybe it would be better to allow
>> the controller to go into D3 provided no wakeup signal is needed.  You
>> could do:
>>
>> device_set_wakeup_capable(&pdev->dev, 0);
>
> This doesn't work.
> After applying this function, still nothing happens when devices get plugged 
> in.
> IIUC this function disable the wakeup function, but what I want to do
> here is to have PME signal works even when runtime PM is enabled.
>
> I also saw some legacy PCI PM stuff, so I also tried:
> device_set_wakeup_capable(&pdev->dev, 1);
> ...doesn't work either.
>
>>
>> Another alternative is to put the controller into D2 instead of D3, but
>> (1) I don't know how to do that, and (2) we don't know if wakeup
>> signalling works any better in D2 than it does in D3.
>
> I'll try if D2 works.

Put the device into D2 instead of D3 can make the wakeup signaling
work, i.e. USB devices can be correctly detected after plugged into
EHCI port.

Do you think this alternative an acceptable workaround?

>
> Thanks for the review.
>
--
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] USB: serial: option: add Telewell TW-3G HSPA+ device id

[Johan Hovold]

[ +CC: Lars ]

On Mon, Jun 12, 2017 at 11:50:13AM +0200, Bjørn Mork wrote:
> Johan Hovold  writes:
> 
> > Add device-id entry for the Telewell TW-3G HSPA+ modem, which uses the
> > Longcheer vendor id.
> >
> > Reported-by: Teemu Likonen 
> > Cc: stable 
> > Signed-off-by: Johan Hovold 
> > ---
> >  drivers/usb/serial/option.c | 4 
> >  1 file changed, 4 insertions(+)
> >
> > Teemu, would you be able to test this patch?
> >
> > Thanks,
> > Johan
> >
> >
> > diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
> > index 3bf61acfc26b..b48f3557b2e4 100644
> > --- a/drivers/usb/serial/option.c
> > +++ b/drivers/usb/serial/option.c
> > @@ -388,6 +388,9 @@ static void option_instat_callback(struct urb *urb);
> >  /* SpeedUp SU9800 usb 3g modem */
> >  #define SPEEDUP_PRODUCT_SU9800 0x9800
> >  
> > +/* Telewell */
> > +#define TELEWELL_PRODUCT_TW_3G_HSPAP   0x9801
> > +
> >  /* Haier products */
> >  #define HAIER_VENDOR_ID0x201e
> >  #define HAIER_PRODUCT_CE81B0x10f8
> > @@ -1877,6 +1880,7 @@ static const struct usb_device_id option_ids[] = {
> >   .driver_info = (kernel_ulong_t)&four_g_w100_blacklist
> > },
> > { USB_DEVICE_INTERFACE_CLASS(LONGCHEER_VENDOR_ID, 
> > SPEEDUP_PRODUCT_SU9800, 0xff) },
> > +   { USB_DEVICE_INTERFACE_CLASS(LONGCHEER_VENDOR_ID, 
> > TELEWELL_PRODUCT_TW_3G_HSPAP, 0xff) },
> > { USB_DEVICE(LONGCHEER_VENDOR_ID, ZOOM_PRODUCT_4597) },
> > { USB_DEVICE(LONGCHEER_VENDOR_ID, IBALL_3_5G_CONNECT) },
> > { USB_DEVICE(HAIER_VENDOR_ID, HAIER_PRODUCT_CE100) },
> 
> 
> I was looking at the Windows drivers on
> https://www.telewell.fi/files/tw-3g_hspa_ajuri.zip
> whiche have this among the serial stuff:
> 
> [QCOM]
> %qcwwan.DeviceDesc%= qcwwan.ndi, USB\VID_1C9E&PID_9801&MI_03
> %qcwwan.DeviceDesc%= qcwwan.ndi, USB\VID_1C9E&PID_9803&MI_04
> %qcwwan.DeviceDesc%= qcwwan.ndi, USB\VID_1C9E&PID_9806&MI_05
> %qcwwan.DeviceDesc%= qcwwan.ndi, USB\VID_1C9E&PID_9808&MI_06
> 
> %qcwwan.DeviceDesc%= qcwwan.ndi, USB\VID_1C9E&PID_9866&MI_03
> %qcwwan.DeviceDesc%= qcwwan.ndi, USB\VID_1C9E&PID_9868&MI_04
> %qcwwan.DeviceDesc%= qcwwan.ndi, USB\VID_1C9E&PID_9869&MI_05
> 
> 
> It's not clear what type of driver the 'cmntnet.sys' installed by this
> is, but I wonder if it maybe is QMI based on the 'qc' prefix?

I think Lars just suggested that.

> And maybe we should add the remaining device IDs too?

Good idea, I'll respin.

Thanks,
Johan
--
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: ASIX AX88772 USB 2.0 Ethernet stops working after kernel 4.8

[Oliver Neukum]

Am Montag, den 15.05.2017, 18:26 +0300 schrieb Andrey Aleksandrovich:
> > 
> > Please try to revert
> > 535baf8588d04b177cb33700f81499f2b5203c2d
> 
> Sorry, not understood what to try?
> I've checked today snapshot of 4.11.1 and 4.12
> Both have the bug.
> --
> 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
> 

Hi,

sorry, this fell through the cracks. I was suggesting that you
compile a test kernel with the change made in

commit 535baf8588d04b177cb33700f81499f2b5203c2d
Author: Robert Foss 
Date:   Mon Aug 29 09:32:19 2016 -0400

net: asix: autoneg will set WRITE_MEDIUM reg

undo, to check whether that patch has caused a regression.

Regards
Oliver

--
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] USB: serial: option: add Telewell TW-3G HSPA+ device id

[Johan Hovold]

[ +CC: Lars, resend with Lars actually on CC ]

On Mon, Jun 12, 2017 at 11:50:13AM +0200, Bjørn Mork wrote:
> Johan Hovold  writes:
> 
> > Add device-id entry for the Telewell TW-3G HSPA+ modem, which uses the
> > Longcheer vendor id.
> >
> > Reported-by: Teemu Likonen 
> > Cc: stable 
> > Signed-off-by: Johan Hovold 
> > ---
> >  drivers/usb/serial/option.c | 4 
> >  1 file changed, 4 insertions(+)
> >
> > Teemu, would you be able to test this patch?
> >
> > Thanks,
> > Johan
> >
> >
> > diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
> > index 3bf61acfc26b..b48f3557b2e4 100644
> > --- a/drivers/usb/serial/option.c
> > +++ b/drivers/usb/serial/option.c
> > @@ -388,6 +388,9 @@ static void option_instat_callback(struct urb *urb);
> >  /* SpeedUp SU9800 usb 3g modem */
> >  #define SPEEDUP_PRODUCT_SU9800 0x9800
> >  
> > +/* Telewell */
> > +#define TELEWELL_PRODUCT_TW_3G_HSPAP   0x9801
> > +
> >  /* Haier products */
> >  #define HAIER_VENDOR_ID0x201e
> >  #define HAIER_PRODUCT_CE81B0x10f8
> > @@ -1877,6 +1880,7 @@ static const struct usb_device_id option_ids[] = {
> >   .driver_info = (kernel_ulong_t)&four_g_w100_blacklist
> > },
> > { USB_DEVICE_INTERFACE_CLASS(LONGCHEER_VENDOR_ID, 
> > SPEEDUP_PRODUCT_SU9800, 0xff) },
> > +   { USB_DEVICE_INTERFACE_CLASS(LONGCHEER_VENDOR_ID, 
> > TELEWELL_PRODUCT_TW_3G_HSPAP, 0xff) },
> > { USB_DEVICE(LONGCHEER_VENDOR_ID, ZOOM_PRODUCT_4597) },
> > { USB_DEVICE(LONGCHEER_VENDOR_ID, IBALL_3_5G_CONNECT) },
> > { USB_DEVICE(HAIER_VENDOR_ID, HAIER_PRODUCT_CE100) },
> 
> 
> I was looking at the Windows drivers on
> https://www.telewell.fi/files/tw-3g_hspa_ajuri.zip
> whiche have this among the serial stuff:
> 
> [QCOM]
> %qcwwan.DeviceDesc%= qcwwan.ndi, USB\VID_1C9E&PID_9801&MI_03
> %qcwwan.DeviceDesc%= qcwwan.ndi, USB\VID_1C9E&PID_9803&MI_04
> %qcwwan.DeviceDesc%= qcwwan.ndi, USB\VID_1C9E&PID_9806&MI_05
> %qcwwan.DeviceDesc%= qcwwan.ndi, USB\VID_1C9E&PID_9808&MI_06
> 
> %qcwwan.DeviceDesc%= qcwwan.ndi, USB\VID_1C9E&PID_9866&MI_03
> %qcwwan.DeviceDesc%= qcwwan.ndi, USB\VID_1C9E&PID_9868&MI_04
> %qcwwan.DeviceDesc%= qcwwan.ndi, USB\VID_1C9E&PID_9869&MI_05
> 
> 
> It's not clear what type of driver the 'cmntnet.sys' installed by this
> is, but I wonder if it maybe is QMI based on the 'qc' prefix?

I think Lars just suggested that.

> And maybe we should add the remaining device IDs too?

Good idea, I'll respin.

Thanks,
Johan
--
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] USB: serial: option: add Telewell TW-3G HSPA+ device id

[Johan Hovold]

On Mon, Jun 12, 2017 at 01:11:18PM +0300, Teemu Likonen wrote:
> Johan Hovold [2017-06-12 11:16:12+02] wrote:
> 
> > Add device-id entry for the Telewell TW-3G HSPA+ modem, which uses the
> > Longcheer vendor id.
> >
> > Reported-by: Teemu Likonen 
> > Cc: stable 
> > Signed-off-by: Johan Hovold 
> > ---
> >  drivers/usb/serial/option.c | 4 
> >  1 file changed, 4 insertions(+)
> >
> > Teemu, would you be able to test this patch?
> 
> It seems that you will do another patch but I'll confirm anyway that
> this works. I compiled the mainline kernel v4.12-rc5 with this patch.

Great, thanks for testing. It may be you are able to use the QMI driver
for this one as well and we should at least blacklist interface 3.

Thanks,
Johan
--
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: Piping f_acm to real hardware

[Tal Shorer]

On Mon, Jun 12, 2017 at 9:48 AM, Greg KH  wrote:
> On Sun, Jun 11, 2017 at 11:41:02PM +0300, Tal Shorer wrote:
>> I'm currently working on a project where I'd like to have an omap board
>> running linux be a usb-to-uart converter (using f_acm). I have an
>> application that holds both the ttyGS* and the ttyO* port (the physical
>> uart port) open, polls for readable data, and writes any incoming data
>> to the other side.
>>
>> I'd also like the host to be able to configure baudrate, parity, etc.
>> My thought on how to achieve this is to modify how the ttyGS* ports
>> behave by adding a POLLPRI event when set_line_coding is received. In
>> order to do that several steps will have to be taken:
>> - one of:
>> 1. add a poll() callback to struct tty_operations and call it in
>> n_tty_poll(). u_serial and f_acm will implement required
>> callbacks to allow returning POLLPRI when necessary.
>> 2. add a flag to struct tty_struct that indicates an exceptional
>> condition and make n_tty_poll() return POLLPRI if that flag is
>> set. this will also require a new wait queue to allow us to wait
>> for such an event.
>> - after receiving SET_LINE_CODING (and verifying it), set whatever flag
>> is necessary to wake the user with POLLPRI.
>> - implement the ioctl() callback in u_serial and f_acm to allow the
>> user to get the line coding set by the host, with which it can
>> configure the hardware port accordingly.
>>
>> Does my approach make sense? Assuming I do that, which tree should such
>> a series be sent to? usb-gadget? tty?
>
> Why not just do it all in userspace, a simple "loopback" program should
> be able to handle this.  If not, look into the 'serdev' interface now in
> the kernel, that might help out a lot with what you want to do here.
>
> And I really doubt you need to touch the tty core or ldisc for this,
> that seems a bit extreme.
>
> good luck!
>
> greg k-h

I'm not sure what you mean by "loopback", but if you mean an
application that poll()s the two sides, reads from one side and writes
to the other, I'm already doing that. My issue is that:
1. f_acm doesn't do anything with set_line_coding.
2. even if it did, the tty core has no easy way to notify the user of that.

As to serdev, I looked into it and it really could do the job if we
redesigned u_serial to be a serdev driver. I don't think we want that
since sometimes the user might not want to use real hardware (obex
comes to mind easily but it could be any of them really).

I think this choice should be left to the user, but then the user
needs a way to know they should update the hardware's line coding
--
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] USB: serial: option: add Telewell TW-3G HSPA+ device id

[Lars Melin]

On 2017-06-12 16:50, Bjørn Mork wrote:

Johan Hovold  writes:


Add device-id entry for the Telewell TW-3G HSPA+ modem, which uses the
Longcheer vendor id.

Reported-by: Teemu Likonen 
Cc: stable 
Signed-off-by: Johan Hovold 
---
  drivers/usb/serial/option.c | 4 
  1 file changed, 4 insertions(+)

Teemu, would you be able to test this patch?

Thanks,
Johan


diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index 3bf61acfc26b..b48f3557b2e4 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -388,6 +388,9 @@ static void option_instat_callback(struct urb *urb);
  /* SpeedUp SU9800 usb 3g modem */
  #define SPEEDUP_PRODUCT_SU98000x9800
  
+/* Telewell */

+#define TELEWELL_PRODUCT_TW_3G_HSPAP   0x9801
+
  /* Haier products */
  #define HAIER_VENDOR_ID   0x201e
  #define HAIER_PRODUCT_CE81B   0x10f8
@@ -1877,6 +1880,7 @@ static const struct usb_device_id option_ids[] = {
  .driver_info = (kernel_ulong_t)&four_g_w100_blacklist
},
{ USB_DEVICE_INTERFACE_CLASS(LONGCHEER_VENDOR_ID, 
SPEEDUP_PRODUCT_SU9800, 0xff) },
+   { USB_DEVICE_INTERFACE_CLASS(LONGCHEER_VENDOR_ID, 
TELEWELL_PRODUCT_TW_3G_HSPAP, 0xff) },
{ USB_DEVICE(LONGCHEER_VENDOR_ID, ZOOM_PRODUCT_4597) },
{ USB_DEVICE(LONGCHEER_VENDOR_ID, IBALL_3_5G_CONNECT) },
{ USB_DEVICE(HAIER_VENDOR_ID, HAIER_PRODUCT_CE100) },



I was looking at the Windows drivers on
https://www.telewell.fi/files/tw-3g_hspa_ajuri.zip
whiche have this among the serial stuff:

[QCOM]
%qcwwan.DeviceDesc%= qcwwan.ndi, USB\VID_1C9E&PID_9801&MI_03
%qcwwan.DeviceDesc%= qcwwan.ndi, USB\VID_1C9E&PID_9803&MI_04
%qcwwan.DeviceDesc%= qcwwan.ndi, USB\VID_1C9E&PID_9806&MI_05
%qcwwan.DeviceDesc%= qcwwan.ndi, USB\VID_1C9E&PID_9808&MI_06

%qcwwan.DeviceDesc%= qcwwan.ndi, USB\VID_1C9E&PID_9866&MI_03
%qcwwan.DeviceDesc%= qcwwan.ndi, USB\VID_1C9E&PID_9868&MI_04
%qcwwan.DeviceDesc%= qcwwan.ndi, USB\VID_1C9E&PID_9869&MI_05


It's not clear what type of driver the 'cmntnet.sys' installed by this
is, but I wonder if it maybe is QMI based on the 'qc' prefix?


And maybe we should add the remaining device IDs too?



Bjørn



1c9e:9803 can be added, the other ones may be reserved id's for
products that never reached the market.

/Lars

--
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 v2 0/3] New driver for UCSI (USB Type-C)

[Heikki Krogerus]

On Fri, Jun 09, 2017 at 06:30:30AM -0700, Guenter Roeck wrote:
> On 06/09/2017 04:03 AM, Heikki Krogerus wrote:
> > Hi Guenter,
> > 
> > On Mon, Jun 05, 2017 at 05:30:22PM +0300, Heikki Krogerus wrote:
> > > Hi,
> > > 
> > > This moves the current ucsi driver from drivers/usb/misc/ucsi.c to the
> > > new USB Type-C class (drivers/usb/typec/). That allows us to finally do
> > > role swapping.
> > > 
> > > The driver is now split into core library part, and ACPI driver. That
> > > should make it easy to add support for other interface methods (first
> > > most likely being I2C) later if needed.
> > > 
> > > Changes since v1:
> > > - Added separate flag from pending ACK. Some new platforms generate 
> > > "command
> > >complete" event on top of the normal "ACK complete" event with ACK 
> > > commands.
> > >In such cases the driver has to be able to basically ignore the command
> > >completion in case of ACK and only finish acknowledge routine when the 
> > > actual
> > >ACK complete event is received. Otherwise a new command may be queued 
> > > to the
> > >PPM before the previous has fully completed.
> > > - Added an explanation why we are handling the PPM initialization in a 
> > > work as
> > >suggested by Guenter.
> > > - Fixed ucsi_reset_ppm() by removing possibility of returning -ETIMEDOUT 
> > > in case
> > >of success right before the time expires. Suggested by Guenter.
> > > - Replaced useless "goto err;" with "break;" in ucsi_run_command() as 
> > > suggested
> > >by Guenter.
> > > - Removed traceback in case of failure from ucsi_run_command() which is 
> > > not
> > >necessary as suggested by Guenter.
> > > - Highlighting the fact that the timeouts are in milliseconds by using _MS
> > >ending with the definition (UCSI_TIMEOUT_MS and UCSI_SWAP_TIMEOUT_MS) 
> > > as
> > >suggested by Guenter.
> > > - Including also  in ucsi.h as suggested by Guenter.
> > > - In ucsi_acpi.c, explicitly pointing out in the comment that we can not 
> > > use
> > >devm_ioremap_resource() as suggested by Guenter.
> > > 
> > > 
> > > Heikki Krogerus (2):
> > >usb: typec: Add support for UCSI interface
> > >usb: typec: ucsi: Add ACPI driver
> > 
> > Gentle ping.
> > Are these OK now?
> > 
> 
> I am far behind, sorry :-(. I'll try to get to it today or during the weekend.

Thanks a lot Guenter! I really appreciate it.

-- 
heikki
--
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 v1] usb: dwc3: gadget: increase readability of dwc3_gadget_init_endpoints()

[Felipe Balbi]

Hi,

Andy Shevchenko  writes:
> The commit 47d3946ea220
>   usb: dwc3: refactor gadget endpoint count calculation
> refactored dwc3_gadget_init_endpoints() and in particular changed in our
> out endpoint numbering to be through. It's not always convenient and
> makes code a slightly harder to read.
>
> Introduce temporary variable to make it easier to understand what is
> going on inside function.
>
> Replace implicit direction check via epnum with explicit use of direction
> variable.
>
> While here, replace %d to %u when compounding endpoint name since we are
> using unsigned type.
>
> Signed-off-by: Andy Shevchenko 
> ---
>  drivers/usb/dwc3/gadget.c | 11 ++-
>  1 file changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
> index aea9a5b948b4..9b5ce474f641 100644
> --- a/drivers/usb/dwc3/gadget.c
> +++ b/drivers/usb/dwc3/gadget.c
> @@ -1992,6 +1992,7 @@ static int dwc3_gadget_init_endpoints(struct dwc3 *dwc, 
> u8 num)
>  
>   for (epnum = 0; epnum < num; epnum++) {
>   booldirection = epnum & 1;
> + u8  inout = epnum >> 1;

inout is not really intuitive at all. I would rather rename u8 num to u8
total and rename inout to num. Care to do that and resend?

Thanks

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH] USB: serial: option: add Telewell TW-3G HSPA+ device id

[Bjørn Mork]

Lars Melin  writes:

> 1c9e:9803 can be added, the other ones may be reserved id's for
> products that never reached the market.

Out of curiosity: How do you know these things?

Thanks for very valuable information.  Our lists of supported devices
are long enough without lots of dead entries...


Bjørn
--
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] usb: gadget: functions: add ftrace export over USB

[Felipe Balbi]

Hi,

kbuild test robot  writes:
> Hi Felipe,
>
> [auto build test ERROR on balbi-usb/next]
> [also build test ERROR on v4.12-rc4 next-20170609]
> [if your patch is applied to the wrong git tree, please drop us a note to 
> help improve the system]

this patch depends on another patch [1] in order to compile properly :-)

[1] https://marc.info/?i=20170602102025.5140-1-felipe.ba...@linux.intel.com

-- 
balbi


signature.asc
Description: PGP signature

[PATCH] usb: dwc3: exynos: Handle return value of clk_prepare_enable

[Arvind Yadav]

clk_prepare_enable() can fail here and we must check its return value.

Signed-off-by: Arvind Yadav 
---
 drivers/usb/dwc3/dwc3-exynos.c | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
index 98f74ff..e089df7 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -125,12 +125,16 @@ static int dwc3_exynos_probe(struct platform_device *pdev)
dev_err(dev, "couldn't get clock\n");
return -EINVAL;
}
-   clk_prepare_enable(exynos->clk);
+   ret = clk_prepare_enable(exynos->clk);
+   if (ret)
+   return ret;
 
exynos->susp_clk = devm_clk_get(dev, "usbdrd30_susp_clk");
if (IS_ERR(exynos->susp_clk))
exynos->susp_clk = NULL;
-   clk_prepare_enable(exynos->susp_clk);
+   ret = clk_prepare_enable(exynos->susp_clk);
+   if (ret)
+   goto susp_clk_err;
 
if (of_device_is_compatible(node, "samsung,exynos7-dwusb3")) {
exynos->axius_clk = devm_clk_get(dev, "usbdrd30_axius_clk");
@@ -139,7 +143,9 @@ static int dwc3_exynos_probe(struct platform_device *pdev)
ret = -ENODEV;
goto axius_clk_err;
}
-   clk_prepare_enable(exynos->axius_clk);
+   ret = clk_prepare_enable(exynos->axius_clk);
+   if (ret)
+   goto axius_clk_err;
} else {
exynos->axius_clk = NULL;
}
@@ -197,6 +203,7 @@ static int dwc3_exynos_probe(struct platform_device *pdev)
clk_disable_unprepare(exynos->axius_clk);
 axius_clk_err:
clk_disable_unprepare(exynos->susp_clk);
+susp_clk_err:
clk_disable_unprepare(exynos->clk);
return ret;
 }
-- 
1.9.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: [PATCH] USB: serial: option: add Telewell TW-3G HSPA+ device id

[Lars Melin]

On 2017-06-12 17:37, Bjørn Mork wrote:

Lars Melin  writes:


1c9e:9803 can be added, the other ones may be reserved id's for
products that never reached the market.


Out of curiosity: How do you know these things?

Thanks for very valuable information.  Our lists of supported devices
are long enough without lots of dead entries...


Bjørn



The driver is almost 6 years old and only the first two id's has 
surfaced on the net or in all the GPL code I have from some of the major 
Chinese 3G router manufacturers.

1c9e:9801 is btw included in a mfgr specific qmi_wwan driver together
with some other id's which may interest you.
Tell me if you want to get that driver and I'll mail it to you.

The driver is written by Qualcomm for Longcheer and Qualcomm is known 
for including device id's that either never become used or (even worser) 
will be used for a product with an interface layout not matching what 
was listed in the big Qualcomm driver .inf file


I have never seen qcwwan.ndi used for anything else than rmnet/qmiwwan 
and a single interface without altsetting and with 3 interfaces whereof 
one is of interrupt type and with interface attributes ff/ff/ff can't 
possibly be for any other net type protocol.


/Lars
--
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] usb: host: ehci-exynos: Handle return value of clk_prepare_enable

[Arvind Yadav]

clk_prepare_enable() can fail here and we must check its return value.

Signed-off-by: Arvind Yadav 
---
 drivers/usb/host/ehci-exynos.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
index 7a603f6..26b6411 100644
--- a/drivers/usb/host/ehci-exynos.c
+++ b/drivers/usb/host/ehci-exynos.c
@@ -279,7 +279,9 @@ static int exynos_ehci_resume(struct device *dev)
struct exynos_ehci_hcd *exynos_ehci = to_exynos_ehci(hcd);
int ret;
 
-   clk_prepare_enable(exynos_ehci->clk);
+   ret = clk_prepare_enable(exynos_ehci->clk);
+   if (ret)
+   return ret;
 
ret = exynos_ehci_phy_enable(dev);
if (ret) {
-- 
1.9.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: Continuous, infinite warm reset attempts in Chipidea HDRC on multiple connect-disconects

[lingareddy praneethreddy]

On Fri, Jun 9, 2017 at 8:01 PM, Alan Stern  wrote:
> On Fri, 9 Jun 2017, lingareddy praneethreddy wrote:
>
>> Thanks Alan. I understand and agree.
>>
>> It is a legacy platform that we are supporting and I needed to address
>> this issue on 3.10.17. We are in the process of migrating to 4.1.x
>> this coming week to check on this behavior. Until then can you help us
>> with the one thing i.e. can you point me to where in the latest kernel
>> code is the warm reset initiated? Thanks again.
>
> You might try looking at check_port_resume_type() in hub.c, together
> with the routines that it calls and the routines that call it.
>
> Alan Stern
>

 Thanks Alan.

 I will look into it and once I migrate to 4.1.15 kernel and i will
come back to you, if I face the same issue.
 Thanks once again.

-- 
BestRegards
Praneeth Reddy L
--
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: Piping f_acm to real hardware

[Greg KH]

On Mon, Jun 12, 2017 at 01:17:18PM +0300, Tal Shorer wrote:
> On Mon, Jun 12, 2017 at 9:48 AM, Greg KH  wrote:
> > On Sun, Jun 11, 2017 at 11:41:02PM +0300, Tal Shorer wrote:
> >> I'm currently working on a project where I'd like to have an omap board
> >> running linux be a usb-to-uart converter (using f_acm). I have an
> >> application that holds both the ttyGS* and the ttyO* port (the physical
> >> uart port) open, polls for readable data, and writes any incoming data
> >> to the other side.
> >>
> >> I'd also like the host to be able to configure baudrate, parity, etc.
> >> My thought on how to achieve this is to modify how the ttyGS* ports
> >> behave by adding a POLLPRI event when set_line_coding is received. In
> >> order to do that several steps will have to be taken:
> >> - one of:
> >> 1. add a poll() callback to struct tty_operations and call it in
> >> n_tty_poll(). u_serial and f_acm will implement required
> >> callbacks to allow returning POLLPRI when necessary.
> >> 2. add a flag to struct tty_struct that indicates an exceptional
> >> condition and make n_tty_poll() return POLLPRI if that flag is
> >> set. this will also require a new wait queue to allow us to wait
> >> for such an event.
> >> - after receiving SET_LINE_CODING (and verifying it), set whatever flag
> >> is necessary to wake the user with POLLPRI.
> >> - implement the ioctl() callback in u_serial and f_acm to allow the
> >> user to get the line coding set by the host, with which it can
> >> configure the hardware port accordingly.
> >>
> >> Does my approach make sense? Assuming I do that, which tree should such
> >> a series be sent to? usb-gadget? tty?
> >
> > Why not just do it all in userspace, a simple "loopback" program should
> > be able to handle this.  If not, look into the 'serdev' interface now in
> > the kernel, that might help out a lot with what you want to do here.
> >
> > And I really doubt you need to touch the tty core or ldisc for this,
> > that seems a bit extreme.
> >
> > good luck!
> >
> > greg k-h
> 
> I'm not sure what you mean by "loopback", but if you mean an
> application that poll()s the two sides, reads from one side and writes
> to the other, I'm already doing that. My issue is that:
> 1. f_acm doesn't do anything with set_line_coding.
> 2. even if it did, the tty core has no easy way to notify the user of that.

Ah, I understand now, thanks.  Yeah, that's a problem :)

Good luck!

greg k-h
--
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 v2 1/2] usb: typec: Add support for UCSI interface

[Heikki Krogerus]

Hi,

On Fri, Jun 09, 2017 at 07:52:56PM -0700, Guenter Roeck wrote:
> > diff --git a/drivers/usb/typec/ucsi/debug.h b/drivers/usb/typec/ucsi/debug.h
> > new file mode 100644
> > index ..87d0cd20597a
> > --- /dev/null
> > +++ b/drivers/usb/typec/ucsi/debug.h
> > @@ -0,0 +1,64 @@
> > +#ifndef __UCSI_DEBUG_H
> > +#define __UCSI_DEBUG_H
> > +
> > +#include "ucsi.h"
> > +
> > +static const char * const ucsi_cmd_strs[] = {
> > +   [0] = "Unknown command",
> > +   [UCSI_PPM_RESET]= "PPM_RESET",
> > +   [UCSI_CANCEL]   = "CANCEL",
> > +   [UCSI_CONNECTOR_RESET]  = "CONNECTOR_RESET",
> > +   [UCSI_ACK_CC_CI]= "ACK_CC_CI",
> > +   [UCSI_SET_NOTIFICATION_ENABLE]  = "SET_NOTIFICATION_ENABLE",
> > +   [UCSI_GET_CAPABILITY]   = "GET_CAPABILITY",
> > +   [UCSI_GET_CONNECTOR_CAPABILITY] = "GET_CONNECTOR_CAPABILITY",
> > +   [UCSI_SET_UOM]  = "SET_UOM",
> > +   [UCSI_SET_UOR]  = "SET_UOR",
> > +   [UCSI_SET_PDM]  = "SET_PDM",
> > +   [UCSI_SET_PDR]  = "SET_PDR",
> > +   [UCSI_GET_ALTERNATE_MODES]  = "GET_ALTERNATE_MODES",
> > +   [UCSI_GET_CAM_SUPPORTED]= "GET_CAM_SUPPORTED",
> > +   [UCSI_GET_CURRENT_CAM]  = "GET_CURRENT_CAM",
> > +   [UCSI_SET_NEW_CAM]  = "SET_NEW_CAM",
> > +   [UCSI_GET_PDOS] = "GET_PDOS",
> > +   [UCSI_GET_CABLE_PROPERTY]   = "GET_CABLE_PROPERTY",
> > +   [UCSI_GET_CONNECTOR_STATUS] = "GET_CONNECTOR_STATUS",
> > +   [UCSI_GET_ERROR_STATUS] = "GET_ERROR_STATUS",
> > +};
> > +
> > +static inline const char *ucsi_cmd_str(u64 raw_cmd)
> > +{
> > +   u8 cmd = raw_cmd & GENMASK(7, 0);
> > +
> > +   return ucsi_cmd_strs[(cmd > ARRAY_SIZE(ucsi_cmd_strs)) ? 0 : cmd];
> 
> I thought I mentioned this before. What if cmd == ARRAY_SIZE(ucsi_cmd_strs) ?
> I may be missing something, but I am quite sure that would point beyond
> the end of the array.

I failed to notice your previous comment about this, sorry. I'll fix
these.

> > +}
> > +
> > +static const char * const ucsi_ack_strs[] = {
> > +   [0] = "",
> > +   [UCSI_ACK_EVENT]= "event",
> > +   [UCSI_ACK_CMD]  = "command",
> > +};
> > +
> > +static inline const char *ucsi_ack_str(u8 ack)
> > +{
> > +   return ucsi_ack_strs[(ack > ARRAY_SIZE(ucsi_ack_strs)) ? 0 : ack];
> 
> Same here.



> > +/* Command Status and Connector Change Indication (CCI) data structure */
> > +struct ucsi_cci {
> > +   u8:1; /* reserved */
> > +   u8 connector_change:7;
> > +   u8 data_length;
> > +   u16:9; /* reserved */
> > +   u16 not_supported:1;
> > +   u16 cancel_complete:1;
> > +   u16 reset_complete:1;
> > +   u16 busy:1;
> > +   u16 ack_complete:1;
> > +   u16 error:1;
> > +   u16 cmd_complete:1;
> 
> Wondering: Is this endianness clean ?
> Same whereever you use bit fields. Or is the driver
> only expected to work on little-endian systems ?

The idea was to support only support little endian with the driver
initially, but I'll try to improve the structures and by using
something like __BIG/LITTLE_ENDIAN_BITFIELD.

> > +} __packed;
> > +
> > +/* Default fields in CONTROL data structure */
> > +struct ucsi_command {
> > +   u8 cmd;
> > +   u8 length;
> > +   u64 data:48;
> > +} __packed;
> 
> Is ucsi_command supppose to be 64 bit long ? If so, does __packed
> truncate the u64 to 48 bit ?

That was the idea, but now that you mentioned it, __packed does not
seem to be needed for it. I'll drop the __packed from this structure.



> > +struct ucsi;
> > +
> > +struct ucsi_data {
> > +   u16 version;
> > +   u16:16; /* reserved */
> 
> The :16 seems unnecessary.

OK. I'll fix it and make it "u16 reserved;"


Thanks,

-- 
heikki
--
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] usb: host: ehci-exynos: Handle return value of clk_prepare_enable

[Krzysztof Kozlowski]

On Mon, Jun 12, 2017 at 04:45:14PM +0530, Arvind Yadav wrote:
> clk_prepare_enable() can fail here and we must check its return value.
> 
> Signed-off-by: Arvind Yadav 
> ---
>  drivers/usb/host/ehci-exynos.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 

Reviewed-by: Krzysztof Kozlowski 

Best regards,
Krzysztof

--
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] usb: dwc3: exynos: Handle return value of clk_prepare_enable

[Krzysztof Kozlowski]

On Mon, Jun 12, 2017 at 04:23:31PM +0530, Arvind Yadav wrote:
> clk_prepare_enable() can fail here and we must check its return value.
> 
> Signed-off-by: Arvind Yadav 
> ---
>  drivers/usb/dwc3/dwc3-exynos.c | 13 ++---
>  1 file changed, 10 insertions(+), 3 deletions(-)
> 

Reviewed-by: Krzysztof Kozlowski 

Best regards,
Krzysztof

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

[GIT PULL] USB fixes for v4.12-rc5

[Felipe Balbi]

Hi Greg,

here's what I hope to be my last pull request for the current -rc
cycle.

Let me know if you want anything to be changed.

cheers

The following changes since commit afbbc7913a288c29616bd31ae612548f6475151a:

  usb: gadget: udc: renesas_usb3: Fix PN_INT_ENA disabling timing (2017-06-02 
12:45:02 +0300)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git 
tags/fixes-for-v4.12-rc5

for you to fetch changes up to f50b878fed33e360d01dcdc31a8eeb1815d033d5:

  USB: gadget: fix GPF in gadgetfs (2017-06-09 16:02:20 +0300)


usb: fixes for v4.12-rc5

Alan Stern fixed a GPF in gadgetfs found by the kernel fuzzying project

composite.c learned that if it deactivates a function during bind, it
must reactivate it during unbind.


Alan Stern (1):
  USB: gadget: fix GPF in gadgetfs

Felipe Balbi (1):
  usb: gadget: composite: make sure to reactivate function on unbind

 drivers/usb/gadget/composite.c| 11 +--
 drivers/usb/gadget/legacy/inode.c |  4 +++-
 2 files changed, 8 insertions(+), 7 deletions(-)

-- 
balbi


signature.asc
Description: PGP signature

Re: resolving issue by: USB_AUTOSUSPEND=0

[Oliver Neukum]

Am Dienstag, den 23.05.2017, 11:23 +0200 schrieb Daniel Duris:
> Sorry about that, -v output here:
> 

Hi,

sorry about the delay. Could you apply the attached debugging patch,
raise logging level and report the result?

Regards
Oliver
From 96ab31dc4870f9104b77a40e26052d062b923a73 Mon Sep 17 00:00:00 2001
From: Oliver Neukum 
Date: Mon, 12 Jun 2017 13:52:15 +0200
Subject: [PATCH] r8152: give the device version

Getting the device version out of the driver really aids debugging.

Signed-off-by: Oliver Neukum 
---
 drivers/net/usb/r8152.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index ddc62cb69be8..1a419a45e2a2 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -4368,6 +4368,8 @@ static u8 rtl_get_version(struct usb_interface *intf)
 		break;
 	}
 
+	dev_dbg(&intf->dev, "Detected version 0x%04x\n", version);
+
 	return version;
 }
 
-- 
2.12.3

[PATCH v2] usb: dwc3: gadget: increase readability of dwc3_gadget_init_endpoints()

[Andy Shevchenko]

The commit 47d3946ea220

usb: dwc3: refactor gadget endpoint count calculation

refactored dwc3_gadget_init_endpoints() and in particular changed in or
out endpoint numbering to be through. It's not always convenient and
makes code a slightly harder to read.

Introduce a new temporary variable to make it easier to understand what
is going on inside the function.

While doing that, rename local variables as follows:
u8 num  -> u8 total
int num -> int kbytes

Replace implicit direction check via epnum with explicit use of
direction variable.

While here, replace %d to %u when compounding endpoint name since we are
using unsigned type.

Signed-off-by: Andy Shevchenko 
---
- rename local variables as well (Felipe)
 drivers/usb/dwc3/gadget.c | 29 +++--
 1 file changed, 15 insertions(+), 14 deletions(-)

diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index aea9a5b948b4..d1d6cf95bf2d 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1983,15 +1983,16 @@ static const struct usb_gadget_ops dwc3_gadget_ops = {
 
 /* -- 
*/
 
-static int dwc3_gadget_init_endpoints(struct dwc3 *dwc, u8 num)
+static int dwc3_gadget_init_endpoints(struct dwc3 *dwc, u8 total)
 {
struct dwc3_ep  *dep;
u8  epnum;
 
INIT_LIST_HEAD(&dwc->gadget.ep_list);
 
-   for (epnum = 0; epnum < num; epnum++) {
+   for (epnum = 0; epnum < total; epnum++) {
booldirection = epnum & 1;
+   u8  num = epnum >> 1;
 
dep = kzalloc(sizeof(*dep), GFP_KERNEL);
if (!dep)
@@ -2003,7 +2004,7 @@ static int dwc3_gadget_init_endpoints(struct dwc3 *dwc, 
u8 num)
dep->regs = dwc->regs + DWC3_DEP_BASE(epnum);
dwc->eps[epnum] = dep;
 
-   snprintf(dep->name, sizeof(dep->name), "ep%d%s", epnum >> 1,
+   snprintf(dep->name, sizeof(dep->name), "ep%u%s", num,
direction ? "in" : "out");
 
dep->endpoint.name = dep->name;
@@ -2015,39 +2016,39 @@ static int dwc3_gadget_init_endpoints(struct dwc3 *dwc, 
u8 num)
 
spin_lock_init(&dep->lock);
 
-   if (epnum == 0 || epnum == 1) {
+   if (num == 0) {
usb_ep_set_maxpacket_limit(&dep->endpoint, 512);
dep->endpoint.maxburst = 1;
dep->endpoint.ops = &dwc3_gadget_ep0_ops;
-   if (!epnum)
+   if (!direction)
dwc->gadget.ep0 = &dep->endpoint;
} else if (direction) {
int mdwidth;
+   int kbytes;
int size;
int ret;
-   int num;
 
mdwidth = DWC3_MDWIDTH(dwc->hwparams.hwparams0);
/* MDWIDTH is represented in bits, we need it in bytes 
*/
mdwidth /= 8;
 
-   size = dwc3_readl(dwc->regs, DWC3_GTXFIFOSIZ(epnum >> 
1));
+   size = dwc3_readl(dwc->regs, DWC3_GTXFIFOSIZ(num));
size = DWC3_GTXFIFOSIZ_TXFDEF(size);
 
/* FIFO Depth is in MDWDITH bytes. Multiply */
size *= mdwidth;
 
-   num = size / 1024;
-   if (num == 0)
-   num = 1;
+   kbytes = size / 1024;
+   if (kbytes == 0)
+   kbytes = 1;
 
/*
-* FIFO sizes account an extra MDWIDTH * (num + 1) 
bytes for
+* FIFO sizes account an extra MDWIDTH * (kbytes + 1) 
bytes for
 * internal overhead. We don't really know how these 
are used,
 * but documentation say it exists.
 */
-   size -= mdwidth * (num + 1);
-   size /= num;
+   size -= mdwidth * (kbytes + 1);
+   size /= kbytes;
 
usb_ep_set_maxpacket_limit(&dep->endpoint, size);
 
@@ -2073,7 +2074,7 @@ static int dwc3_gadget_init_endpoints(struct dwc3 *dwc, 
u8 num)
return ret;
}
 
-   if (epnum == 0 || epnum == 1) {
+   if (num == 0) {
dep->endpoint.caps.type_control = true;
} else {
dep->endpoint.caps.type_iso = true;
-- 
2.11.0

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

Re: resolving issue by: USB_AUTOSUSPEND=0

[Daniel Duris]

Hi,

If you please provide a way how to do it, then yes of course. Thanks,

D.

On 12.06.2017 14:06, Oliver Neukum wrote:
> Am Dienstag, den 23.05.2017, 11:23 +0200 schrieb Daniel Duris:
>> Sorry about that, -v output here:
>>
> Hi,
>
> sorry about the delay. Could you apply the attached debugging patch,
> raise logging level and report the result?
>
>   Regards
>   Oliver

--
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 v2] usb: dwc3: gadget: increase readability of dwc3_gadget_init_endpoints()

[Felipe Balbi]

Hi,

Andy Shevchenko  writes:
> The commit 47d3946ea220
>
>   usb: dwc3: refactor gadget endpoint count calculation
>
> refactored dwc3_gadget_init_endpoints() and in particular changed in or
> out endpoint numbering to be through. It's not always convenient and
> makes code a slightly harder to read.
>
> Introduce a new temporary variable to make it easier to understand what
> is going on inside the function.
>
> While doing that, rename local variables as follows:
>   u8 num  -> u8 total
>   int num -> int kbytes

this one is actually in bytes. I'll fix wen applying.

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH v2] usb: dwc3: gadget: increase readability of dwc3_gadget_init_endpoints()

[Felipe Balbi]

Hi,

Felipe Balbi  writes:
>> The commit 47d3946ea220
>>
>>  usb: dwc3: refactor gadget endpoint count calculation
>>
>> refactored dwc3_gadget_init_endpoints() and in particular changed in or
>> out endpoint numbering to be through. It's not always convenient and
>> makes code a slightly harder to read.
>>
>> Introduce a new temporary variable to make it easier to understand what
>> is going on inside the function.
>>
>> While doing that, rename local variables as follows:
>>  u8 num  -> u8 total
>>  int num -> int kbytes
>
> this one is actually in bytes. I'll fix wen applying.

nevermind, I forgot that I converted to kbytes ;-)

sorry

-- 
balbi


signature.asc
Description: PGP signature

Re: [RFC V1 1/1] net: cdc_ncm: Reduce memory use when kernel memory low

[Baxter, Jim]

From: Oliver Neukum (oneu...@suse.com) Sent: Mon, 12 Jun 2017 12:24:07 +0200

> Am Dienstag, den 23.05.2017, 20:06 +0100 schrieb Jim Baxter:
>> From: David S. Miller (da...@davemloft.net)
>> Sent: Tue, 23 May 2017 11:26:25 -0400 
>>>
>>> From: Oliver Neukum 
>>> Date: Tue, 23 May 2017 10:42:48 +0200
>>>


 We could use a counter. After the first failure, do it once, after the
 second twice and so on. And reset the counter as a higher order
 allocation works. (just bound it somewhere)
>>>
>>> So an exponential backoff, that might work.
>>>
>>
>> As an idea I have created this patch as an addition to the original patch
>> in this series.
>>
>> Would this be acceptable?
>>
>> At the moment I have capped the value at 10, does anyone think it needs to
>> be much higher then that?
> 
> Hi,
> 
> I am working through mail backlog. If I may ask, has this patch proposal
> had a result or does something need to be done still?
> 
>   Regards
>   Oliver
> 
Hi,

I have not received any response to my additional patch yet.

Do you think I should submit it as a second RFC patchset?

Regards,
Jim
--
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 net-next 1/2] r8152: split rtl8152_resume function

[Oliver Neukum]

Am Montag, den 12.06.2017, 16:21 +0800 schrieb Hayes Wang:
> Split rtl8152_resume() into rtl8152_runtime_resume() and
> rtl8152_system_resume().
> 
> Signed-off-by: Hayes Wang 
> ---
>  drivers/net/usb/r8152.c | 99 
> ++---
>  1 file changed, 61 insertions(+), 38 deletions(-)
> 
> diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
> index 5a02053..3257955 100644
> --- a/drivers/net/usb/r8152.c
> +++ b/drivers/net/usb/r8152.c
> @@ -3686,6 +3686,61 @@ static bool delay_autosuspend(struct r8152 *tp)
> return false;
>  }
>  
> +static int rtl8152_runtime_resume(struct r8152 *tp)
> +{
> +   struct net_device *netdev = tp->netdev;
> +
> +   if (netif_running(netdev) && netdev->flags & IFF_UP) {
> +   struct napi_struct *napi = &tp->napi;
> +
> +   tp->rtl_ops.autosuspend_en(tp, false);
> +   napi_disable(napi);
> +   set_bit(WORK_ENABLE, &tp->flags);
> +
> +   if (netif_carrier_ok(netdev)) {
> +   if (rtl8152_get_speed(tp) & LINK_STATUS) {
> +   rtl_start_rx(tp);
> +   } else {
> +   netif_carrier_off(netdev);
> +   tp->rtl_ops.disable(tp);
> +   netif_info(tp, link, netdev, "linking 
> down\n");
> +   }
> +   }
> +
> +   napi_enable(napi);
> +   clear_bit(SELECTIVE_SUSPEND, &tp->flags);
> +   smp_mb__after_atomic();
> +
> +   if (!list_empty(&tp->rx_done))
> +   napi_schedule(&tp->napi);
> +
> +   usb_submit_urb(tp->intr_urb, GFP_KERNEL);

If you ever built a device with included storage, this can deadlock,
as you may want to wake up a device for memory that is needed to wake
up a device. Use GFP_NOIO in resume() and reset_resume(), always.

Regards
Oliver


--
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 v2 1/2] usb: typec: Add support for UCSI interface

[Heikki Krogerus]

Hi Guenter,

On Mon, Jun 12, 2017 at 02:55:49PM +0300, Heikki Krogerus wrote:
> > > +/* Command Status and Connector Change Indication (CCI) data structure */
> > > +struct ucsi_cci {
> > > + u8:1; /* reserved */
> > > + u8 connector_change:7;
> > > + u8 data_length;
> > > + u16:9; /* reserved */
> > > + u16 not_supported:1;
> > > + u16 cancel_complete:1;
> > > + u16 reset_complete:1;
> > > + u16 busy:1;
> > > + u16 ack_complete:1;
> > > + u16 error:1;
> > > + u16 cmd_complete:1;
> > 
> > Wondering: Is this endianness clean ?
> > Same whereever you use bit fields. Or is the driver
> > only expected to work on little-endian systems ?
> 
> The idea was to support only support little endian with the driver
> initially, but I'll try to improve the structures and by using
> something like __BIG/LITTLE_ENDIAN_BITFIELD.

Just a clarification for this. I'll just add a proper dependency on
little-endian if that is OK. There were some concerns internally
regarding how to deal with big endian support in this driver, so I'll
keep it little endian for now. Let me know if that is not OK.


Thanks,

-- 
heikki
--
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: FW: Unable to perform remote wakeup of host with USB HID Composite Device

[Oliver Neukum]

Am Dienstag, den 06.06.2017, 12:30 + schrieb Abdulhadi Mohamed:
> Hi 
> 
> I apologize in advance for this is my first email using this mailing list but 
> I could really use some help. I have connected a composite USB device running 
> the 4.0 Linux kernel to a PC running Ubuntu. One of its functions is to act 
> as a HID device for mouse and keyboard to control the host. However, an issue 
> that I am currently encountering is that if the host (running Ubuntu 14.10) 
> is suspended, the composite USB device cannot wake it up however a normal 
> connected  USB mouse or keyboard on the same USB port can wake it up. 
> Detailed lsusb information for my device is provided below. Any assistance is 
> greatly appreciated in solving this issue.  
> 
> 

Hi,

that is quite old a kernel. Could you retest with the newest upstream?
I'd look at choose_wakeup() and instrument that a little to see what
is going on.

Reagrds
Oliver

--
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: Piping f_acm to real hardware

[Tal Shorer]

On Mon, Jun 12, 2017 at 2:42 PM, Greg KH  wrote:
> On Mon, Jun 12, 2017 at 01:17:18PM +0300, Tal Shorer wrote:
>> On Mon, Jun 12, 2017 at 9:48 AM, Greg KH  wrote:
>> > On Sun, Jun 11, 2017 at 11:41:02PM +0300, Tal Shorer wrote:
>> >> I'm currently working on a project where I'd like to have an omap board
>> >> running linux be a usb-to-uart converter (using f_acm). I have an
>> >> application that holds both the ttyGS* and the ttyO* port (the physical
>> >> uart port) open, polls for readable data, and writes any incoming data
>> >> to the other side.
>> >>
>> >> I'd also like the host to be able to configure baudrate, parity, etc.
>> >> My thought on how to achieve this is to modify how the ttyGS* ports
>> >> behave by adding a POLLPRI event when set_line_coding is received. In
>> >> order to do that several steps will have to be taken:
>> >> - one of:
>> >> 1. add a poll() callback to struct tty_operations and call it in
>> >> n_tty_poll(). u_serial and f_acm will implement required
>> >> callbacks to allow returning POLLPRI when necessary.
>> >> 2. add a flag to struct tty_struct that indicates an exceptional
>> >> condition and make n_tty_poll() return POLLPRI if that flag is
>> >> set. this will also require a new wait queue to allow us to wait
>> >> for such an event.
>> >> - after receiving SET_LINE_CODING (and verifying it), set whatever flag
>> >> is necessary to wake the user with POLLPRI.
>> >> - implement the ioctl() callback in u_serial and f_acm to allow the
>> >> user to get the line coding set by the host, with which it can
>> >> configure the hardware port accordingly.
>> >>
>> >> Does my approach make sense? Assuming I do that, which tree should such
>> >> a series be sent to? usb-gadget? tty?
>> >
>> > Why not just do it all in userspace, a simple "loopback" program should
>> > be able to handle this.  If not, look into the 'serdev' interface now in
>> > the kernel, that might help out a lot with what you want to do here.
>> >
>> > And I really doubt you need to touch the tty core or ldisc for this,
>> > that seems a bit extreme.
>> >
>> > good luck!
>> >
>> > greg k-h
>>
>> I'm not sure what you mean by "loopback", but if you mean an
>> application that poll()s the two sides, reads from one side and writes
>> to the other, I'm already doing that. My issue is that:
>> 1. f_acm doesn't do anything with set_line_coding.
>> 2. even if it did, the tty core has no easy way to notify the user of that.
>
> Ah, I understand now, thanks.  Yeah, that's a problem :)
>
> Good luck!
>
> greg k-h
Which of the two approaches do you think is cleaner? I tend to favour
the first. Should this be split into two series, one for tty core and
one for the gadget stuff or should this be one long series? If one
series, which tree should I submit this to?
--
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 v2 1/2] usb: typec: Add support for UCSI interface

[Guenter Roeck]

On 06/12/2017 05:41 AM, Heikki Krogerus wrote:

Hi Guenter,

On Mon, Jun 12, 2017 at 02:55:49PM +0300, Heikki Krogerus wrote:

+/* Command Status and Connector Change Indication (CCI) data structure */
+struct ucsi_cci {
+   u8:1; /* reserved */
+   u8 connector_change:7;
+   u8 data_length;
+   u16:9; /* reserved */
+   u16 not_supported:1;
+   u16 cancel_complete:1;
+   u16 reset_complete:1;
+   u16 busy:1;
+   u16 ack_complete:1;
+   u16 error:1;
+   u16 cmd_complete:1;


Wondering: Is this endianness clean ?
Same whereever you use bit fields. Or is the driver
only expected to work on little-endian systems ?


The idea was to support only support little endian with the driver
initially, but I'll try to improve the structures and by using
something like __BIG/LITTLE_ENDIAN_BITFIELD.


Just a clarification for this. I'll just add a proper dependency on
little-endian if that is OK. There were some concerns internally
regarding how to deal with big endian support in this driver, so I'll
keep it little endian for now. Let me know if that is not OK.


ok with me.

Guenter

--
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: Piping f_acm to real hardware

[Greg KH]

On Mon, Jun 12, 2017 at 04:00:56PM +0300, Tal Shorer wrote:
> On Mon, Jun 12, 2017 at 2:42 PM, Greg KH  wrote:
> > On Mon, Jun 12, 2017 at 01:17:18PM +0300, Tal Shorer wrote:
> >> On Mon, Jun 12, 2017 at 9:48 AM, Greg KH  
> >> wrote:
> >> > On Sun, Jun 11, 2017 at 11:41:02PM +0300, Tal Shorer wrote:
> >> >> I'm currently working on a project where I'd like to have an omap board
> >> >> running linux be a usb-to-uart converter (using f_acm). I have an
> >> >> application that holds both the ttyGS* and the ttyO* port (the physical
> >> >> uart port) open, polls for readable data, and writes any incoming data
> >> >> to the other side.
> >> >>
> >> >> I'd also like the host to be able to configure baudrate, parity, etc.
> >> >> My thought on how to achieve this is to modify how the ttyGS* ports
> >> >> behave by adding a POLLPRI event when set_line_coding is received. In
> >> >> order to do that several steps will have to be taken:
> >> >> - one of:
> >> >> 1. add a poll() callback to struct tty_operations and call it in
> >> >> n_tty_poll(). u_serial and f_acm will implement required
> >> >> callbacks to allow returning POLLPRI when necessary.
> >> >> 2. add a flag to struct tty_struct that indicates an exceptional
> >> >> condition and make n_tty_poll() return POLLPRI if that flag is
> >> >> set. this will also require a new wait queue to allow us to wait
> >> >> for such an event.
> >> >> - after receiving SET_LINE_CODING (and verifying it), set whatever flag
> >> >> is necessary to wake the user with POLLPRI.
> >> >> - implement the ioctl() callback in u_serial and f_acm to allow the
> >> >> user to get the line coding set by the host, with which it can
> >> >> configure the hardware port accordingly.
> >> >>
> >> >> Does my approach make sense? Assuming I do that, which tree should such
> >> >> a series be sent to? usb-gadget? tty?
> >> >
> >> > Why not just do it all in userspace, a simple "loopback" program should
> >> > be able to handle this.  If not, look into the 'serdev' interface now in
> >> > the kernel, that might help out a lot with what you want to do here.
> >> >
> >> > And I really doubt you need to touch the tty core or ldisc for this,
> >> > that seems a bit extreme.
> >> >
> >> > good luck!
> >> >
> >> > greg k-h
> >>
> >> I'm not sure what you mean by "loopback", but if you mean an
> >> application that poll()s the two sides, reads from one side and writes
> >> to the other, I'm already doing that. My issue is that:
> >> 1. f_acm doesn't do anything with set_line_coding.
> >> 2. even if it did, the tty core has no easy way to notify the user of that.
> >
> > Ah, I understand now, thanks.  Yeah, that's a problem :)
> >
> > Good luck!
> >
> > greg k-h
> Which of the two approaches do you think is cleaner? I tend to favour
> the first. Should this be split into two series, one for tty core and
> one for the gadget stuff or should this be one long series? If one
> series, which tree should I submit this to?

One long series is fine, post to both lists and let's see how it works
out...

greg k-h
--
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 v2] xhci: Bad Ethernet performance plugged in ASM1042A host

[Mario.Limonciello]

> -Original Message-
> From: Lars Chang(張家豪) [mailto:lars_ch...@asmedia.com.tw]
> Sent: Friday, June 9, 2017 1:34 AM
> To: 'Felipe Balbi' ; Jiahau Chang
> ; linux-usb@vger.kernel.org; mathias.ny...@intel.com
> Cc: Brain Lee(李魁中) ; Limonciello, Mario
> ; Justin_CY Chen(陳志勇)
> ; Wang, Keith ; Yd
> Tseng(曾裕達) ; Jiahau Chang 
> Subject: RE: [PATCH v2] xhci: Bad Ethernet performance plugged in ASM1042A 
> host
> 
> 
> 
> > -Original Message-
> > From: Felipe Balbi [mailto:felipe.ba...@linux.intel.com]
> > Sent: Friday, June 09, 2017 2:04 PM
> > To: Jiahau Chang; linux-usb@vger.kernel.org; mathias.ny...@intel.com
> > Cc: Brain Lee(李魁中); mario.limoncie...@dell.com; Justin_CY Chen(陳志勇);
> > keith_w...@dell.com; Yd Tseng(曾裕達); Jiahau Chang; Lars Chang(張家豪)
> > Subject: Re: [PATCH v2] xhci: Bad Ethernet performance plugged in ASM1042A
> > host
> >
> >
> > Hi,
> >
> > Jiahau Chang  writes:
> > > v2 : fix coding format
> >
> > this doesn't need to be in the commit log. You should place such notes
> > after the tearline (---) below
> 
> I will move it after the tearline. Should I need to resend the patch?
> >
> > > When USB Ethernet is plugged in ASMEDIA ASM1042A xHCI host, bad
> > > performance was manifesting in Web browser use (like download
> > > large file such as ISO image). It is known limitation of
> > > ASM1042A that is not compatible with driver scheduling,
> > > As a workaround we can modify flow control handling of ASM1042A.
> > >
> > > Signed-off-by: Jiahau Chang 
> > > ---
> > >  drivers/usb/host/pci-quirks.c | 62
> > +++
> > >  drivers/usb/host/pci-quirks.h |  1 +
> > >  drivers/usb/host/xhci-pci.c   |  5 
> > >  drivers/usb/host/xhci.c   |  3 +++
> > >  drivers/usb/host/xhci.h   |  1 +
> > >  5 files changed, 72 insertions(+)
> > >
> > > diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
> > > index a9a1e4c..bdeaf75 100644
> > > --- a/drivers/usb/host/pci-quirks.c
> > > +++ b/drivers/usb/host/pci-quirks.c
> > > @@ -77,6 +77,12 @@
> > >  #define USB_INTEL_USB3_PSSEN   0xD8
> > >  #define USB_INTEL_USB3PRM  0xDC
> > >
> > > +/*ASMEDIA quirk use*/
> > > +#define ASMT_DATA_WRITE0_REG 0xF8
> > > +#define ASMT_DATA_WRITE1_REG 0xFC
> > > +#define ASMT_CONTROL_REG 0xE0
> > > +#define ASMT_CONTROL_WRITE_BIT   0x02
> > > +
> > >  /*
> > >   * amd_chipset_gen values represent AMD different chipset generations
> > >   */
> > > @@ -412,6 +418,62 @@ void usb_amd_quirk_pll_disable(void)
> > >  }
> > >  EXPORT_SYMBOL_GPL(usb_amd_quirk_pll_disable);
> > >
> > > +void usb_asmedia_modifyflowcontrol(struct pci_dev *pdev)
> > > +{
> > > + u32 value_low, value_high;
> > > + unsigned char value;
> > > + unsigned long wait_time_count;
> > > +
> > > + wait_time_count = 1000;
> > > + while (wait_time_count) {
> > > + pci_read_config_byte(pdev, ASMT_CONTROL_REG, &value);
> > > + if (value == 0xff) {
> > > + dev_dbg(&pdev->dev, "%s: wait_write_ready IO_ERROR,
> > value=%x\n",
> > > + __func__, value);
> > > + goto err_exit;
> > > + } else if ((value & ASMT_CONTROL_WRITE_BIT) == 0) {
> > > + break;
> > > + }
> > > + wait_time_count--;
> > > + udelay(50);
> > > + }
> > > + if (wait_time_count == 0) {
> > > + dev_dbg(&pdev->dev, "%s: wait_write_ready timeout\n",
> > > + __func__);
> > > + goto err_exit;
> > > + }
> > > + value_low = 0x00010423;
> > > + value_high = 0xFA30;
> >
> > sorry, no magic constants
> >
> > > + pci_write_config_dword(pdev, ASMT_DATA_WRITE0_REG, value_low);
> > > + pci_write_config_dword(pdev, ASMT_DATA_WRITE1_REG, value_high);
> > > + pci_write_config_byte(pdev, ASMT_CONTROL_REG,
> > ASMT_CONTROL_WRITE_BIT);
> > > + wait_time_count = 1000;
> > > + while (wait_time_count) {
> > > + pci_read_config_byte(pdev, ASMT_CONTROL_REG, &value);
> > > + if (value == 0xff) {
> > > + dev_dbg(&pdev->dev, "%s: wait_write_ready IO_ERROR,
> > value=%x\n",
> > > + __func__, value);
> > > + goto err_exit;
> >
> > indentation
> >
> > > + } else if ((value & ASMT_CONTROL_WRITE_BIT) == 0) {
> > > + break;
> > > + }
> > > + wait_time_count--;
> > > + udelay(50);
> > > + }
> > > + if (wait_time_count == 0) {
> > > + dev_dbg(&pdev->dev, "%s: wait_write_ready timeout\n",
> > > + __func__);
> > > + goto err_exit;
> > > + }
> > > + pci_write_config_dword(pdev, ASMT_DATA_WRITE0_REG, 0xBA);
> > > + pci_write_config_dword(pdev, ASMT_DATA_WRITE1_REG, 0);
> >
> > likewise
> >
> > > diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
> > > index 73a28a9..ed58f87 100644
> > > --- a/drivers/usb/host/xhci.h
> > > +++ b/drivers/usb/host/xhci.h
> > > @@ -1819,6 +1819,7 @@ struct xhci_hcd {
> > >  /* For controller with a broken Port Disable imple

Re: [PATCH v2] xhci: Bad Ethernet performance plugged in ASM1042A host

[Greg KH]

On Mon, Jun 12, 2017 at 01:28:57PM +, mario.limoncie...@dell.com wrote:
> > -Original Message-
> > From: Lars Chang(張家豪) [mailto:lars_ch...@asmedia.com.tw]
> > Sent: Friday, June 9, 2017 1:34 AM
> > To: 'Felipe Balbi' ; Jiahau Chang
> > ; linux-usb@vger.kernel.org; mathias.ny...@intel.com
> > Cc: Brain Lee(李魁中) ; Limonciello, Mario
> > ; Justin_CY Chen(陳志勇)
> > ; Wang, Keith ; Yd
> > Tseng(曾裕達) ; Jiahau Chang 
> > Subject: RE: [PATCH v2] xhci: Bad Ethernet performance plugged in ASM1042A 
> > host
> > 
> > 
> > 
> > > -Original Message-
> > > From: Felipe Balbi [mailto:felipe.ba...@linux.intel.com]
> > > Sent: Friday, June 09, 2017 2:04 PM
> > > To: Jiahau Chang; linux-usb@vger.kernel.org; mathias.ny...@intel.com
> > > Cc: Brain Lee(李魁中); mario.limoncie...@dell.com; Justin_CY Chen(陳志勇);
> > > keith_w...@dell.com; Yd Tseng(曾裕達); Jiahau Chang; Lars Chang(張家豪)
> > > Subject: Re: [PATCH v2] xhci: Bad Ethernet performance plugged in ASM1042A
> > > host
> > >
> > >
> > > Hi,
> > >
> > > Jiahau Chang  writes:
> > > > v2 : fix coding format
> > >
> > > this doesn't need to be in the commit log. You should place such notes
> > > after the tearline (---) below
> > 
> > I will move it after the tearline. Should I need to resend the patch?
> > >
> > > > When USB Ethernet is plugged in ASMEDIA ASM1042A xHCI host, bad
> > > > performance was manifesting in Web browser use (like download
> > > > large file such as ISO image). It is known limitation of
> > > > ASM1042A that is not compatible with driver scheduling,
> > > > As a workaround we can modify flow control handling of ASM1042A.
> > > >
> > > > Signed-off-by: Jiahau Chang 
> > > > ---
> > > >  drivers/usb/host/pci-quirks.c | 62
> > > +++
> > > >  drivers/usb/host/pci-quirks.h |  1 +
> > > >  drivers/usb/host/xhci-pci.c   |  5 
> > > >  drivers/usb/host/xhci.c   |  3 +++
> > > >  drivers/usb/host/xhci.h   |  1 +
> > > >  5 files changed, 72 insertions(+)
> > > >
> > > > diff --git a/drivers/usb/host/pci-quirks.c 
> > > > b/drivers/usb/host/pci-quirks.c
> > > > index a9a1e4c..bdeaf75 100644
> > > > --- a/drivers/usb/host/pci-quirks.c
> > > > +++ b/drivers/usb/host/pci-quirks.c
> > > > @@ -77,6 +77,12 @@
> > > >  #define USB_INTEL_USB3_PSSEN   0xD8
> > > >  #define USB_INTEL_USB3PRM  0xDC
> > > >
> > > > +/*ASMEDIA quirk use*/
> > > > +#define ASMT_DATA_WRITE0_REG   0xF8
> > > > +#define ASMT_DATA_WRITE1_REG   0xFC
> > > > +#define ASMT_CONTROL_REG   0xE0
> > > > +#define ASMT_CONTROL_WRITE_BIT 0x02
> > > > +
> > > >  /*
> > > >   * amd_chipset_gen values represent AMD different chipset generations
> > > >   */
> > > > @@ -412,6 +418,62 @@ void usb_amd_quirk_pll_disable(void)
> > > >  }
> > > >  EXPORT_SYMBOL_GPL(usb_amd_quirk_pll_disable);
> > > >
> > > > +void usb_asmedia_modifyflowcontrol(struct pci_dev *pdev)
> > > > +{
> > > > +   u32 value_low, value_high;
> > > > +   unsigned char value;
> > > > +   unsigned long wait_time_count;
> > > > +
> > > > +   wait_time_count = 1000;
> > > > +   while (wait_time_count) {
> > > > +   pci_read_config_byte(pdev, ASMT_CONTROL_REG, &value);
> > > > +   if (value == 0xff) {
> > > > +   dev_dbg(&pdev->dev, "%s: wait_write_ready 
> > > > IO_ERROR,
> > > value=%x\n",
> > > > +   __func__, value);
> > > > +   goto err_exit;
> > > > +   } else if ((value & ASMT_CONTROL_WRITE_BIT) == 0) {
> > > > +   break;
> > > > +   }
> > > > +   wait_time_count--;
> > > > +   udelay(50);
> > > > +   }
> > > > +   if (wait_time_count == 0) {
> > > > +   dev_dbg(&pdev->dev, "%s: wait_write_ready timeout\n",
> > > > +   __func__);
> > > > +   goto err_exit;
> > > > +   }
> > > > +   value_low = 0x00010423;
> > > > +   value_high = 0xFA30;
> > >
> > > sorry, no magic constants
> > >
> > > > +   pci_write_config_dword(pdev, ASMT_DATA_WRITE0_REG, value_low);
> > > > +   pci_write_config_dword(pdev, ASMT_DATA_WRITE1_REG, value_high);
> > > > +   pci_write_config_byte(pdev, ASMT_CONTROL_REG,
> > > ASMT_CONTROL_WRITE_BIT);
> > > > +   wait_time_count = 1000;
> > > > +   while (wait_time_count) {
> > > > +   pci_read_config_byte(pdev, ASMT_CONTROL_REG, &value);
> > > > +   if (value == 0xff) {
> > > > +   dev_dbg(&pdev->dev, "%s: wait_write_ready 
> > > > IO_ERROR,
> > > value=%x\n",
> > > > +   __func__, value);
> > > > +   goto err_exit;
> > >
> > > indentation
> > >
> > > > +   } else if ((value & ASMT_CONTROL_WRITE_BIT) == 0) {
> > > > +   break;
> > > > +   }
> > > > +   wait_time_count--;
> > > > +   udelay(50);
> > > > +   }
> > > > +   if (wait_time_c

Re: [PATCH v1] net/phy: Make phy_ethtool_ksettings_get return void

[David Miller]

From: Yuval Shaia 
Date: Mon, 12 Jun 2017 10:42:33 +0300

> Make return value void since function never return meaningfull value
> 
> Signed-off-by: Yuval Shaia 
> Acked-by: Sergei Shtylyov 
> ---
> Re-sending since last time forgot to add netdev-list
> v0 ->v1:
>   * These files were missing in v0
>   * drivers/net/ethernet/renesas/ravb_main.c
>   * drivers/net/ethernet/renesas/sh_eth.c
>   * drivers/net/ethernet/ti/netcp_ethss.c
>   * Add Acked-by: Sergei Shtylyov

This doesn't apply cleanly to net-next at all.

Please respin against an uptodate net-next tree, thank you.
--
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 v2] xhci: Bad Ethernet performance plugged in ASM1042A host

[Mario.Limonciello]

> -Original Message-
> From: Greg KH [mailto:gre...@linuxfoundation.org]
> Sent: Monday, June 12, 2017 8:42 AM
> To: Limonciello, Mario 
> Cc: lars_ch...@asmedia.com.tw; felipe.ba...@linux.intel.com;
> jia...@gmail.com; linux-usb@vger.kernel.org; mathias.ny...@intel.com;
> brain_...@asmedia.com.tw; justin_cy_c...@asmedia.com.tw; Wang, Keith
> ; yd_ts...@asmedia.com.tw
> Subject: Re: [PATCH v2] xhci: Bad Ethernet performance plugged in ASM1042A 
> host
> 
> On Mon, Jun 12, 2017 at 01:28:57PM +, mario.limoncie...@dell.com wrote:
> > > -Original Message-
> > > From: Lars Chang(張家豪) [mailto:lars_ch...@asmedia.com.tw]
> > > Sent: Friday, June 9, 2017 1:34 AM
> > > To: 'Felipe Balbi' ; Jiahau Chang
> > > ; linux-usb@vger.kernel.org; mathias.ny...@intel.com
> > > Cc: Brain Lee(李魁中) ; Limonciello, Mario
> > > ; Justin_CY Chen(陳志勇)
> > > ; Wang, Keith ;
> Yd
> > > Tseng(曾裕達) ; Jiahau Chang
> 
> > > Subject: RE: [PATCH v2] xhci: Bad Ethernet performance plugged in ASM1042A
> host
> > >
> > >
> > >
> > > > -Original Message-
> > > > From: Felipe Balbi [mailto:felipe.ba...@linux.intel.com]
> > > > Sent: Friday, June 09, 2017 2:04 PM
> > > > To: Jiahau Chang; linux-usb@vger.kernel.org; mathias.ny...@intel.com
> > > > Cc: Brain Lee(李魁中); mario.limoncie...@dell.com; Justin_CY Chen(陳志勇);
> > > > keith_w...@dell.com; Yd Tseng(曾裕達); Jiahau Chang; Lars Chang(張家豪)
> > > > Subject: Re: [PATCH v2] xhci: Bad Ethernet performance plugged in 
> > > > ASM1042A
> > > > host
> > > >
> > > >
> > > > Hi,
> > > >
> > > > Jiahau Chang  writes:
> > > > > v2 : fix coding format
> > > >
> > > > this doesn't need to be in the commit log. You should place such notes
> > > > after the tearline (---) below
> > >
> > > I will move it after the tearline. Should I need to resend the patch?
> > > >
> > > > > When USB Ethernet is plugged in ASMEDIA ASM1042A xHCI host, bad
> > > > > performance was manifesting in Web browser use (like download
> > > > > large file such as ISO image). It is known limitation of
> > > > > ASM1042A that is not compatible with driver scheduling,
> > > > > As a workaround we can modify flow control handling of ASM1042A.
> > > > >
> > > > > Signed-off-by: Jiahau Chang 
> > > > > ---
> > > > >  drivers/usb/host/pci-quirks.c | 62
> > > > +++
> > > > >  drivers/usb/host/pci-quirks.h |  1 +
> > > > >  drivers/usb/host/xhci-pci.c   |  5 
> > > > >  drivers/usb/host/xhci.c   |  3 +++
> > > > >  drivers/usb/host/xhci.h   |  1 +
> > > > >  5 files changed, 72 insertions(+)
> > > > >
> > > > > diff --git a/drivers/usb/host/pci-quirks.c 
> > > > > b/drivers/usb/host/pci-quirks.c
> > > > > index a9a1e4c..bdeaf75 100644
> > > > > --- a/drivers/usb/host/pci-quirks.c
> > > > > +++ b/drivers/usb/host/pci-quirks.c
> > > > > @@ -77,6 +77,12 @@
> > > > >  #define USB_INTEL_USB3_PSSEN   0xD8
> > > > >  #define USB_INTEL_USB3PRM  0xDC
> > > > >
> > > > > +/*ASMEDIA quirk use*/
> > > > > +#define ASMT_DATA_WRITE0_REG 0xF8
> > > > > +#define ASMT_DATA_WRITE1_REG 0xFC
> > > > > +#define ASMT_CONTROL_REG 0xE0
> > > > > +#define ASMT_CONTROL_WRITE_BIT   0x02
> > > > > +
> > > > >  /*
> > > > >   * amd_chipset_gen values represent AMD different chipset generations
> > > > >   */
> > > > > @@ -412,6 +418,62 @@ void usb_amd_quirk_pll_disable(void)
> > > > >  }
> > > > >  EXPORT_SYMBOL_GPL(usb_amd_quirk_pll_disable);
> > > > >
> > > > > +void usb_asmedia_modifyflowcontrol(struct pci_dev *pdev)
> > > > > +{
> > > > > + u32 value_low, value_high;
> > > > > + unsigned char value;
> > > > > + unsigned long wait_time_count;
> > > > > +
> > > > > + wait_time_count = 1000;
> > > > > + while (wait_time_count) {
> > > > > + pci_read_config_byte(pdev, ASMT_CONTROL_REG,
> &value);
> > > > > + if (value == 0xff) {
> > > > > + dev_dbg(&pdev->dev, "%s: wait_write_ready
> IO_ERROR,
> > > > value=%x\n",
> > > > > + __func__, value);
> > > > > + goto err_exit;
> > > > > + } else if ((value & ASMT_CONTROL_WRITE_BIT) == 0) {
> > > > > + break;
> > > > > + }
> > > > > + wait_time_count--;
> > > > > + udelay(50);
> > > > > + }
> > > > > + if (wait_time_count == 0) {
> > > > > + dev_dbg(&pdev->dev, "%s: wait_write_ready timeout\n",
> > > > > + __func__);
> > > > > + goto err_exit;
> > > > > + }
> > > > > + value_low = 0x00010423;
> > > > > + value_high = 0xFA30;
> > > >
> > > > sorry, no magic constants
> > > >
> > > > > + pci_write_config_dword(pdev, ASMT_DATA_WRITE0_REG,
> value_low);
> > > > > + pci_write_config_dword(pdev, ASMT_DATA_WRITE1_REG,
> value_high);
> > > > > + pci_write_config_byte(pdev, ASMT_CONTROL_REG,
> > > > ASMT_CONTROL_WRITE_BIT);
> > > > > + wait_time_count = 1000;
> > > > > + while (wait_time_count) {

Re: [PATCH v2] xhci: Bad Ethernet performance plugged in ASM1042A host

[Greg KH]

On Mon, Jun 12, 2017 at 01:52:36PM +, mario.limoncie...@dell.com wrote:
> > -Original Message-
> > From: Greg KH [mailto:gre...@linuxfoundation.org]
> > Sent: Monday, June 12, 2017 8:42 AM
> > To: Limonciello, Mario 
> > Cc: lars_ch...@asmedia.com.tw; felipe.ba...@linux.intel.com;
> > jia...@gmail.com; linux-usb@vger.kernel.org; mathias.ny...@intel.com;
> > brain_...@asmedia.com.tw; justin_cy_c...@asmedia.com.tw; Wang, Keith
> > ; yd_ts...@asmedia.com.tw
> > Subject: Re: [PATCH v2] xhci: Bad Ethernet performance plugged in ASM1042A 
> > host
> > 
> > On Mon, Jun 12, 2017 at 01:28:57PM +, mario.limoncie...@dell.com wrote:
> > > > -Original Message-
> > > > From: Lars Chang(張家豪) [mailto:lars_ch...@asmedia.com.tw]
> > > > Sent: Friday, June 9, 2017 1:34 AM
> > > > To: 'Felipe Balbi' ; Jiahau Chang
> > > > ; linux-usb@vger.kernel.org; mathias.ny...@intel.com
> > > > Cc: Brain Lee(李魁中) ; Limonciello, Mario
> > > > ; Justin_CY Chen(陳志勇)
> > > > ; Wang, Keith ;
> > Yd
> > > > Tseng(曾裕達) ; Jiahau Chang
> > 
> > > > Subject: RE: [PATCH v2] xhci: Bad Ethernet performance plugged in 
> > > > ASM1042A
> > host
> > > >
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: Felipe Balbi [mailto:felipe.ba...@linux.intel.com]
> > > > > Sent: Friday, June 09, 2017 2:04 PM
> > > > > To: Jiahau Chang; linux-usb@vger.kernel.org; mathias.ny...@intel.com
> > > > > Cc: Brain Lee(李魁中); mario.limoncie...@dell.com; Justin_CY Chen(陳志勇);
> > > > > keith_w...@dell.com; Yd Tseng(曾裕達); Jiahau Chang; Lars Chang(張家豪)
> > > > > Subject: Re: [PATCH v2] xhci: Bad Ethernet performance plugged in 
> > > > > ASM1042A
> > > > > host
> > > > >
> > > > >
> > > > > Hi,
> > > > >
> > > > > Jiahau Chang  writes:
> > > > > > v2 : fix coding format
> > > > >
> > > > > this doesn't need to be in the commit log. You should place such notes
> > > > > after the tearline (---) below
> > > >
> > > > I will move it after the tearline. Should I need to resend the patch?
> > > > >
> > > > > > When USB Ethernet is plugged in ASMEDIA ASM1042A xHCI host, bad
> > > > > > performance was manifesting in Web browser use (like download
> > > > > > large file such as ISO image). It is known limitation of
> > > > > > ASM1042A that is not compatible with driver scheduling,
> > > > > > As a workaround we can modify flow control handling of ASM1042A.
> > > > > >
> > > > > > Signed-off-by: Jiahau Chang 
> > > > > > ---
> > > > > >  drivers/usb/host/pci-quirks.c | 62
> > > > > +++
> > > > > >  drivers/usb/host/pci-quirks.h |  1 +
> > > > > >  drivers/usb/host/xhci-pci.c   |  5 
> > > > > >  drivers/usb/host/xhci.c   |  3 +++
> > > > > >  drivers/usb/host/xhci.h   |  1 +
> > > > > >  5 files changed, 72 insertions(+)
> > > > > >
> > > > > > diff --git a/drivers/usb/host/pci-quirks.c 
> > > > > > b/drivers/usb/host/pci-quirks.c
> > > > > > index a9a1e4c..bdeaf75 100644
> > > > > > --- a/drivers/usb/host/pci-quirks.c
> > > > > > +++ b/drivers/usb/host/pci-quirks.c
> > > > > > @@ -77,6 +77,12 @@
> > > > > >  #define USB_INTEL_USB3_PSSEN   0xD8
> > > > > >  #define USB_INTEL_USB3PRM  0xDC
> > > > > >
> > > > > > +/*ASMEDIA quirk use*/
> > > > > > +#define ASMT_DATA_WRITE0_REG   0xF8
> > > > > > +#define ASMT_DATA_WRITE1_REG   0xFC
> > > > > > +#define ASMT_CONTROL_REG   0xE0
> > > > > > +#define ASMT_CONTROL_WRITE_BIT 0x02
> > > > > > +
> > > > > >  /*
> > > > > >   * amd_chipset_gen values represent AMD different chipset 
> > > > > > generations
> > > > > >   */
> > > > > > @@ -412,6 +418,62 @@ void usb_amd_quirk_pll_disable(void)
> > > > > >  }
> > > > > >  EXPORT_SYMBOL_GPL(usb_amd_quirk_pll_disable);
> > > > > >
> > > > > > +void usb_asmedia_modifyflowcontrol(struct pci_dev *pdev)
> > > > > > +{
> > > > > > +   u32 value_low, value_high;
> > > > > > +   unsigned char value;
> > > > > > +   unsigned long wait_time_count;
> > > > > > +
> > > > > > +   wait_time_count = 1000;
> > > > > > +   while (wait_time_count) {
> > > > > > +   pci_read_config_byte(pdev, ASMT_CONTROL_REG,
> > &value);
> > > > > > +   if (value == 0xff) {
> > > > > > +   dev_dbg(&pdev->dev, "%s: wait_write_ready
> > IO_ERROR,
> > > > > value=%x\n",
> > > > > > +   __func__, value);
> > > > > > +   goto err_exit;
> > > > > > +   } else if ((value & ASMT_CONTROL_WRITE_BIT) == 0) {
> > > > > > +   break;
> > > > > > +   }
> > > > > > +   wait_time_count--;
> > > > > > +   udelay(50);
> > > > > > +   }
> > > > > > +   if (wait_time_count == 0) {
> > > > > > +   dev_dbg(&pdev->dev, "%s: wait_write_ready timeout\n",
> > > > > > +   __func__);
> > > > > > +   goto err_exit;
> > > > > > +   }
> > > > > > +   value_low = 0x00010423;
> > > > > > +   value_high = 0xFA30;
> > > > >
> > > > > sorry, no magic constants
> > > > >
> > > > > > +   pci_write_config_dword(pd

Re: [GIT PULL] USB fixes for v4.12-rc5

[Greg KH]

On Mon, Jun 12, 2017 at 03:06:37PM +0300, Felipe Balbi wrote:
> 
> Hi Greg,
> 
> here's what I hope to be my last pull request for the current -rc
> cycle.
> 
> Let me know if you want anything to be changed.
> 
> cheers
> 
> The following changes since commit afbbc7913a288c29616bd31ae612548f6475151a:
> 
>   usb: gadget: udc: renesas_usb3: Fix PN_INT_ENA disabling timing (2017-06-02 
> 12:45:02 +0300)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git 
> tags/fixes-for-v4.12-rc5
> 
> for you to fetch changes up to f50b878fed33e360d01dcdc31a8eeb1815d033d5:
> 
>   USB: gadget: fix GPF in gadgetfs (2017-06-09 16:02:20 +0300)
> 
> 
> usb: fixes for v4.12-rc5
> 
> Alan Stern fixed a GPF in gadgetfs found by the kernel fuzzying project
> 
> composite.c learned that if it deactivates a function during bind, it
> must reactivate it during unbind.
> 
> 
> Alan Stern (1):
>   USB: gadget: fix GPF in gadgetfs
> 
> Felipe Balbi (1):
>   usb: gadget: composite: make sure to reactivate function on unbind
> 
>  drivers/usb/gadget/composite.c| 11 +--
>  drivers/usb/gadget/legacy/inode.c |  4 +++-
>  2 files changed, 8 insertions(+), 7 deletions(-)

Pulled and pushed out, thanks.

greg k-h
--
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] usb: host: ehci-exynos: Handle return value of clk_prepare_enable

[Alan Stern]

On Mon, 12 Jun 2017, Arvind Yadav wrote:

> clk_prepare_enable() can fail here and we must check its return value.
> 
> Signed-off-by: Arvind Yadav 
> ---
>  drivers/usb/host/ehci-exynos.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
> index 7a603f6..26b6411 100644
> --- a/drivers/usb/host/ehci-exynos.c
> +++ b/drivers/usb/host/ehci-exynos.c
> @@ -279,7 +279,9 @@ static int exynos_ehci_resume(struct device *dev)
>   struct exynos_ehci_hcd *exynos_ehci = to_exynos_ehci(hcd);
>   int ret;
>  
> - clk_prepare_enable(exynos_ehci->clk);
> + ret = clk_prepare_enable(exynos_ehci->clk);
> + if (ret)
> + return ret;
>  
>   ret = exynos_ehci_phy_enable(dev);
>   if (ret) {

Acked-by: 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 v2] xhci: Bad Ethernet performance plugged in ASM1042A host

[Mario.Limonciello]

> -Original Message-
> From: Greg KH [mailto:gre...@linuxfoundation.org]
> Sent: Monday, June 12, 2017 9:02 AM
> To: Limonciello, Mario 
> Cc: lars_ch...@asmedia.com.tw; felipe.ba...@linux.intel.com;
> jia...@gmail.com; linux-usb@vger.kernel.org; mathias.ny...@intel.com;
> brain_...@asmedia.com.tw; justin_cy_c...@asmedia.com.tw; Wang, Keith
> ; yd_ts...@asmedia.com.tw
> Subject: Re: [PATCH v2] xhci: Bad Ethernet performance plugged in ASM1042A 
> host
> 
> On Mon, Jun 12, 2017 at 01:52:36PM +, mario.limoncie...@dell.com wrote:
> > > -Original Message-
> > > From: Greg KH [mailto:gre...@linuxfoundation.org]
> > > Sent: Monday, June 12, 2017 8:42 AM
> > > To: Limonciello, Mario 
> > > Cc: lars_ch...@asmedia.com.tw; felipe.ba...@linux.intel.com;
> > > jia...@gmail.com; linux-usb@vger.kernel.org; mathias.ny...@intel.com;
> > > brain_...@asmedia.com.tw; justin_cy_c...@asmedia.com.tw; Wang, Keith
> > > ; yd_ts...@asmedia.com.tw
> > > Subject: Re: [PATCH v2] xhci: Bad Ethernet performance plugged in ASM1042A
> host
> > >
> > > On Mon, Jun 12, 2017 at 01:28:57PM +, mario.limoncie...@dell.com
> wrote:
> > > > > -Original Message-
> > > > > From: Lars Chang(張家豪) [mailto:lars_ch...@asmedia.com.tw]
> > > > > Sent: Friday, June 9, 2017 1:34 AM
> > > > > To: 'Felipe Balbi' ; Jiahau Chang
> > > > > ; linux-usb@vger.kernel.org;
> mathias.ny...@intel.com
> > > > > Cc: Brain Lee(李魁中) ; Limonciello, Mario
> > > > > ; Justin_CY Chen(陳志勇)
> > > > > ; Wang, Keith
> ;
> > > Yd
> > > > > Tseng(曾裕達) ; Jiahau Chang
> > > 
> > > > > Subject: RE: [PATCH v2] xhci: Bad Ethernet performance plugged in
> ASM1042A
> > > host
> > > > >
> > > > >
> > > > >
> > > > > > -Original Message-
> > > > > > From: Felipe Balbi [mailto:felipe.ba...@linux.intel.com]
> > > > > > Sent: Friday, June 09, 2017 2:04 PM
> > > > > > To: Jiahau Chang; linux-usb@vger.kernel.org; mathias.ny...@intel.com
> > > > > > Cc: Brain Lee(李魁中); mario.limoncie...@dell.com; Justin_CY Chen(陳志
> 勇);
> > > > > > keith_w...@dell.com; Yd Tseng(曾裕達); Jiahau Chang; Lars Chang(張家
> 豪)
> > > > > > Subject: Re: [PATCH v2] xhci: Bad Ethernet performance plugged in
> ASM1042A
> > > > > > host
> > > > > >
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > Jiahau Chang  writes:
> > > > > > > v2 : fix coding format
> > > > > >
> > > > > > this doesn't need to be in the commit log. You should place such 
> > > > > > notes
> > > > > > after the tearline (---) below
> > > > >
> > > > > I will move it after the tearline. Should I need to resend the patch?
> > > > > >
> > > > > > > When USB Ethernet is plugged in ASMEDIA ASM1042A xHCI host, bad
> > > > > > > performance was manifesting in Web browser use (like download
> > > > > > > large file such as ISO image). It is known limitation of
> > > > > > > ASM1042A that is not compatible with driver scheduling,
> > > > > > > As a workaround we can modify flow control handling of ASM1042A.
> > > > > > >
> > > > > > > Signed-off-by: Jiahau Chang 
> > > > > > > ---
> > > > > > >  drivers/usb/host/pci-quirks.c | 62
> > > > > > +++
> > > > > > >  drivers/usb/host/pci-quirks.h |  1 +
> > > > > > >  drivers/usb/host/xhci-pci.c   |  5 
> > > > > > >  drivers/usb/host/xhci.c   |  3 +++
> > > > > > >  drivers/usb/host/xhci.h   |  1 +
> > > > > > >  5 files changed, 72 insertions(+)
> > > > > > >
> > > > > > > diff --git a/drivers/usb/host/pci-quirks.c 
> > > > > > > b/drivers/usb/host/pci-quirks.c
> > > > > > > index a9a1e4c..bdeaf75 100644
> > > > > > > --- a/drivers/usb/host/pci-quirks.c
> > > > > > > +++ b/drivers/usb/host/pci-quirks.c
> > > > > > > @@ -77,6 +77,12 @@
> > > > > > >  #define USB_INTEL_USB3_PSSEN   0xD8
> > > > > > >  #define USB_INTEL_USB3PRM  0xDC
> > > > > > >
> > > > > > > +/*ASMEDIA quirk use*/
> > > > > > > +#define ASMT_DATA_WRITE0_REG 0xF8
> > > > > > > +#define ASMT_DATA_WRITE1_REG 0xFC
> > > > > > > +#define ASMT_CONTROL_REG 0xE0
> > > > > > > +#define ASMT_CONTROL_WRITE_BIT   0x02
> > > > > > > +
> > > > > > >  /*
> > > > > > >   * amd_chipset_gen values represent AMD different chipset 
> > > > > > > generations
> > > > > > >   */
> > > > > > > @@ -412,6 +418,62 @@ void usb_amd_quirk_pll_disable(void)
> > > > > > >  }
> > > > > > >  EXPORT_SYMBOL_GPL(usb_amd_quirk_pll_disable);
> > > > > > >
> > > > > > > +void usb_asmedia_modifyflowcontrol(struct pci_dev *pdev)
> > > > > > > +{
> > > > > > > + u32 value_low, value_high;
> > > > > > > + unsigned char value;
> > > > > > > + unsigned long wait_time_count;
> > > > > > > +
> > > > > > > + wait_time_count = 1000;
> > > > > > > + while (wait_time_count) {
> > > > > > > + pci_read_config_byte(pdev, ASMT_CONTROL_REG,
> > > &value);
> > > > > > > + if (value == 0xff) {
> > > > > > > + dev_dbg(&pdev->dev, "%s: wait_write_ready
> > > IO_ERROR,
> > > > > > value=%x\n",
> > > > > > > + __func__, value);
> > > > > > > +

patch "USB: usbip: convert to use DRIVER_ATTR_RW" added to driver-core-testing

[gregkh]

This is a note to let you know that I've just added the patch titled

USB: usbip: convert to use DRIVER_ATTR_RW

to my driver-core git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git
in the driver-core-testing branch.

The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)

The patch will be merged to the driver-core-next branch sometime soon,
after it passes testing, and the merge window is open.

If you have any questions about this process, please let me know.


>From cc3d53def83a99636e16ceb70a79eedc61fddc23 Mon Sep 17 00:00:00 2001
From: Greg Kroah-Hartman 
Date: Fri, 9 Jun 2017 11:03:14 +0200
Subject: USB: usbip: convert to use DRIVER_ATTR_RW

We are trying to get rid of DRIVER_ATTR(), and the usbip driver
attribute can be trivially changed to use DRIVER_ATTR_RW().

Cc: Valentina Manea 
Cc: 
Acked-by: Shuah Khan 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/usb/usbip/stub_main.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/usbip/stub_main.c b/drivers/usb/usbip/stub_main.c
index 44ab43fc4fcc..e74fbb7f4a32 100644
--- a/drivers/usb/usbip/stub_main.c
+++ b/drivers/usb/usbip/stub_main.c
@@ -134,7 +134,7 @@ int del_match_busid(char *busid)
return ret;
 }
 
-static ssize_t show_match_busid(struct device_driver *drv, char *buf)
+static ssize_t match_busid_show(struct device_driver *drv, char *buf)
 {
int i;
char *out = buf;
@@ -149,7 +149,7 @@ static ssize_t show_match_busid(struct device_driver *drv, 
char *buf)
return out - buf;
 }
 
-static ssize_t store_match_busid(struct device_driver *dev, const char *buf,
+static ssize_t match_busid_store(struct device_driver *dev, const char *buf,
 size_t count)
 {
int len;
@@ -181,8 +181,7 @@ static ssize_t store_match_busid(struct device_driver *dev, 
const char *buf,
 
return -EINVAL;
 }
-static DRIVER_ATTR(match_busid, S_IRUSR | S_IWUSR, show_match_busid,
-  store_match_busid);
+static DRIVER_ATTR_RW(match_busid);
 
 static ssize_t rebind_store(struct device_driver *dev, const char *buf,
 size_t count)
-- 
2.13.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 v2] net: phy: Make phy_ethtool_ksettings_get return void

[Yuval Shaia]

Make return value void since function never return meaningfull value

Signed-off-by: Yuval Shaia 
Acked-by: Sergei Shtylyov 
---
v0 ->v1:
* These files were missing in v0
* drivers/net/ethernet/renesas/ravb_main.c
* drivers/net/ethernet/renesas/sh_eth.c
* drivers/net/ethernet/ti/netcp_ethss.c
* Add Acked-by: Sergei Shtylyov
v1 -> v2:
* Adjust to net-next tree
---
 drivers/net/ethernet/broadcom/b44.c|  3 ++-
 drivers/net/ethernet/broadcom/bcm63xx_enet.c   |  3 ++-
 drivers/net/ethernet/broadcom/genet/bcmgenet.c |  4 +++-
 drivers/net/ethernet/broadcom/tg3.c|  4 +++-
 drivers/net/ethernet/freescale/dpaa/dpaa_ethtool.c |  6 ++
 drivers/net/ethernet/freescale/ucc_geth_ethtool.c  |  4 +++-
 drivers/net/ethernet/marvell/mv643xx_eth.c |  5 ++---
 drivers/net/ethernet/renesas/ravb_main.c   | 14 +++---
 drivers/net/ethernet/renesas/sh_eth.c  |  5 ++---
 drivers/net/ethernet/ti/cpsw.c |  9 +
 drivers/net/ethernet/ti/netcp_ethss.c  |  8 +++-
 drivers/net/phy/phy.c  | 10 +-
 drivers/net/usb/lan78xx.c  |  2 +-
 include/linux/phy.h|  4 ++--
 net/dsa/slave.c|  9 +
 15 files changed, 47 insertions(+), 43 deletions(-)

diff --git a/drivers/net/ethernet/broadcom/b44.c 
b/drivers/net/ethernet/broadcom/b44.c
index 5b95bb4..9873d2d 100644
--- a/drivers/net/ethernet/broadcom/b44.c
+++ b/drivers/net/ethernet/broadcom/b44.c
@@ -1836,7 +1836,8 @@ static int b44_get_link_ksettings(struct net_device *dev,
 
if (bp->flags & B44_FLAG_EXTERNAL_PHY) {
BUG_ON(!dev->phydev);
-   return phy_ethtool_ksettings_get(dev->phydev, cmd);
+   phy_ethtool_ksettings_get(dev->phydev, cmd);
+   return 0;
}
 
supported = (SUPPORTED_Autoneg);
diff --git a/drivers/net/ethernet/broadcom/bcm63xx_enet.c 
b/drivers/net/ethernet/broadcom/bcm63xx_enet.c
index 50d88d3..34ebb40 100644
--- a/drivers/net/ethernet/broadcom/bcm63xx_enet.c
+++ b/drivers/net/ethernet/broadcom/bcm63xx_enet.c
@@ -1453,7 +1453,8 @@ static int bcm_enet_get_link_ksettings(struct net_device 
*dev,
if (priv->has_phy) {
if (!dev->phydev)
return -ENODEV;
-   return phy_ethtool_ksettings_get(dev->phydev, cmd);
+   phy_ethtool_ksettings_get(dev->phydev, cmd);
+   return 0;
} else {
cmd->base.autoneg = 0;
cmd->base.speed = (priv->force_speed_100) ?
diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.c 
b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
index a205a9f..daca1c9 100644
--- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
+++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
@@ -477,7 +477,9 @@ static int bcmgenet_get_link_ksettings(struct net_device 
*dev,
if (!priv->phydev)
return -ENODEV;
 
-   return phy_ethtool_ksettings_get(priv->phydev, cmd);
+   phy_ethtool_ksettings_get(priv->phydev, cmd);
+
+   return 0;
 }
 
 static int bcmgenet_set_link_ksettings(struct net_device *dev,
diff --git a/drivers/net/ethernet/broadcom/tg3.c 
b/drivers/net/ethernet/broadcom/tg3.c
index 537d571..d600c41 100644
--- a/drivers/net/ethernet/broadcom/tg3.c
+++ b/drivers/net/ethernet/broadcom/tg3.c
@@ -12097,7 +12097,9 @@ static int tg3_get_link_ksettings(struct net_device 
*dev,
if (!(tp->phy_flags & TG3_PHYFLG_IS_CONNECTED))
return -EAGAIN;
phydev = mdiobus_get_phy(tp->mdio_bus, tp->phy_addr);
-   return phy_ethtool_ksettings_get(phydev, cmd);
+   phy_ethtool_ksettings_get(phydev, cmd);
+
+   return 0;
}
 
supported = (SUPPORTED_Autoneg);
diff --git a/drivers/net/ethernet/freescale/dpaa/dpaa_ethtool.c 
b/drivers/net/ethernet/freescale/dpaa/dpaa_ethtool.c
index 15571e2..aad825088 100644
--- a/drivers/net/ethernet/freescale/dpaa/dpaa_ethtool.c
+++ b/drivers/net/ethernet/freescale/dpaa/dpaa_ethtool.c
@@ -75,16 +75,14 @@ static char dpaa_stats_global[][ETH_GSTRING_LEN] = {
 static int dpaa_get_link_ksettings(struct net_device *net_dev,
   struct ethtool_link_ksettings *cmd)
 {
-   int err;
-
if (!net_dev->phydev) {
netdev_dbg(net_dev, "phy device not initialized\n");
return 0;
}
 
-   err = phy_ethtool_ksettings_get(net_dev->phydev, cmd);
+   phy_ethtool_ksettings_get(net_dev->phydev, cmd);
 
-   return err;
+   return 0;
 }
 
 static int dpaa_set_link_ksettings(struct net_device *net_dev,
diff --git a/drivers/net/ethernet/freescale/ucc_geth_ethtool.c 
b/drivers/net/ethernet/freescale/ucc_geth_ethtool.c
index b642990..4df282e 100644
--- a/dr

Re: [PATCH] usb: host: ehci: workaround PME bug on AMD EHCI controller

[Alan Stern]

Let's get some help from people who understand PCI well.

Here's the general problem: Kai-Heng has a PCI-based USB host 
controller that advertises wakeup capability from D3, but it doesn't 
assert PME# from D3 when it should.  For "lspci -vv" output, see

http://marc.info/?l=linux-usb&m=149570231732519&w=2

On Mon, 12 Jun 2017, Kai-Heng Feng wrote:

> On Mon, Jun 12, 2017 at 3:04 PM, Kai-Heng Feng
>  wrote:
> > On Fri, Jun 9, 2017 at 10:43 PM, Alan Stern  
> > wrote:
> >> On Fri, 9 Jun 2017, Kai-Heng Feng wrote:
> >>
> >> Is this really the right solution?  Maybe it would be better to allow
> >> the controller to go into D3 provided no wakeup signal is needed.  You
> >> could do:
> >>
> >> device_set_wakeup_capable(&pdev->dev, 0);
> >
> > This doesn't work.
> > After applying this function, still nothing happens when devices get 
> > plugged in.
> > IIUC this function disable the wakeup function, but what I want to do
> > here is to have PME signal works even when runtime PM is enabled.

This may indicate a bug in either the PCI or USB stacks (or both!).  If 
a driver requires wakeup capability from runtime suspend but the device 
does not provide it, the PCI core should not allow the device to go 
into runtime suspend.  Or is that the driver's responsibility?

> > I also saw some legacy PCI PM stuff, so I also tried:
> > device_set_wakeup_capable(&pdev->dev, 1);
> > ...doesn't work either.
> >
> >>
> >> Another alternative is to put the controller into D2 instead of D3, but
> >> (1) I don't know how to do that, and (2) we don't know if wakeup
> >> signalling works any better in D2 than it does in D3.
> >
> > I'll try if D2 works.
> 
> Put the device into D2 instead of D3 can make the wakeup signaling
> work, i.e. USB devices can be correctly detected after plugged into
> EHCI port.
> 
> Do you think this alternative an acceptable workaround?

Yes, it is.  The difficulty is that I don't know how to tell the PCI 
core that the device should go in D2 during runtime suspend instead of 
D3.  Some sort of quirk may be needed -- perhaps Bjorn can help.

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 v2] net: phy: Make phy_ethtool_ksettings_get return void

[David Miller]

From: Yuval Shaia 
Date: Mon, 12 Jun 2017 17:15:08 +0300

> Make return value void since function never return meaningfull value
> 
> Signed-off-by: Yuval Shaia 
> Acked-by: Sergei Shtylyov 
> ---
> v0 ->v1:
>   * These files were missing in v0
>   * drivers/net/ethernet/renesas/ravb_main.c
>   * drivers/net/ethernet/renesas/sh_eth.c
>   * drivers/net/ethernet/ti/netcp_ethss.c
>   * Add Acked-by: Sergei Shtylyov
> v1 -> v2:
>   * Adjust to net-next tree

Applied, thank you.
--
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] USB: serial: option: add Telewell TW-3G HSPA+ device id

[Johan Hovold]

On Mon, Jun 12, 2017 at 06:02:16PM +0700, Lars Melin wrote:
> On 2017-06-12 17:37, Bjørn Mork wrote:
> > Lars Melin  writes:
> > 
> >> 1c9e:9803 can be added, the other ones may be reserved id's for
> >> products that never reached the market.
> > 
> > Out of curiosity: How do you know these things?
> > 
> > Thanks for very valuable information.  Our lists of supported devices
> > are long enough without lots of dead entries...

> The driver is almost 6 years old and only the first two id's has 
> surfaced on the net or in all the GPL code I have from some of the major 
> Chinese 3G router manufacturers.
> 1c9e:9801 is btw included in a mfgr specific qmi_wwan driver together
> with some other id's which may interest you.
> Tell me if you want to get that driver and I'll mail it to you.
> 
> The driver is written by Qualcomm for Longcheer and Qualcomm is known 
> for including device id's that either never become used or (even worser) 
> will be used for a product with an interface layout not matching what 
> was listed in the big Qualcomm driver .inf file
> 
> I have never seen qcwwan.ndi used for anything else than rmnet/qmiwwan 
> and a single interface without altsetting and with 3 interfaces whereof 
> one is of interrupt type and with interface attributes ff/ff/ff can't 
> possibly be for any other net type protocol.

Thanks for the details.

So I'll only add these two ids while blacklisting interface 3 and 4
respectively.

Thanks,
Johan
--
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 v2] USB: serial: option: add two Longcheer device ids

[Johan Hovold]

Add two Longcheer device-id entries which specifically enables the
Telewell TW-3G HSPA+ branded modem.

Reported-by: Teemu Likonen 
Cc: stable 
Signed-off-by: Johan Hovold 
---
 drivers/usb/serial/option.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index 3bf61acfc26b..ebe51f11105d 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -1877,6 +1877,10 @@ static const struct usb_device_id option_ids[] = {
  .driver_info = (kernel_ulong_t)&four_g_w100_blacklist
},
{ USB_DEVICE_INTERFACE_CLASS(LONGCHEER_VENDOR_ID, 
SPEEDUP_PRODUCT_SU9800, 0xff) },
+   { USB_DEVICE_INTERFACE_CLASS(LONGCHEER_VENDOR_ID, 0x9801, 0xff),
+ .driver_info = (kernel_ulong_t)&net_intf3_blacklist },
+   { USB_DEVICE_INTERFACE_CLASS(LONGCHEER_VENDOR_ID, 0x9803, 0xff),
+ .driver_info = (kernel_ulong_t)&net_intf4_blacklist },
{ USB_DEVICE(LONGCHEER_VENDOR_ID, ZOOM_PRODUCT_4597) },
{ USB_DEVICE(LONGCHEER_VENDOR_ID, IBALL_3_5G_CONNECT) },
{ USB_DEVICE(HAIER_VENDOR_ID, HAIER_PRODUCT_CE100) },
-- 
2.13.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 v3 1/2] usb: typec: Add support for UCSI interface

[Heikki Krogerus]

UCSI - USB Type-C Connector System Software Interface - is a
specification that defines set of registers and data
structures for controlling the USB Type-C ports. It's
designed for systems where an embedded controller (EC) is in
charge of the USB Type-C PHY or USB Power Delivery
controller. It is designed for systems with EC, but it is
not limited to them, and for example some USB Power Delivery
controllers will use it as their direct control interface.

With UCSI the EC (or USB PD controller) acts as the port
manager, implementing all USB Type-C and Power Delivery state
machines. The OS can use the interfaces for reading the
status of the ports and controlling basic operations like
role swapping.

The UCSI specification highlights the fact that it does not
define the interface method (PCI/I2C/ACPI/etc.).
Therefore the driver is implemented as library and every
supported interface method needs its own driver. Driver for
ACPI is provided in separate patch following this one.

The initial driver includes support for all required
features from UCSI specification version 1.0 (getting
connector capabilities and status, and support for power and
data role swapping), but none of the optional UCSI features
(alternate modes, power source capabilities, and cable
capabilities).

Signed-off-by: Heikki Krogerus 
---
 drivers/usb/typec/Kconfig   |   2 +
 drivers/usb/typec/Makefile  |   1 +
 drivers/usb/typec/ucsi/Kconfig  |  23 ++
 drivers/usb/typec/ucsi/Makefile |   7 +
 drivers/usb/typec/ucsi/debug.h  |  64 
 drivers/usb/typec/ucsi/trace.c  |   2 +
 drivers/usb/typec/ucsi/trace.h  | 143 
 drivers/usb/typec/ucsi/ucsi.c   | 790 
 drivers/usb/typec/ucsi/ucsi.h   | 330 +
 9 files changed, 1362 insertions(+)
 create mode 100644 drivers/usb/typec/ucsi/Kconfig
 create mode 100644 drivers/usb/typec/ucsi/Makefile
 create mode 100644 drivers/usb/typec/ucsi/debug.h
 create mode 100644 drivers/usb/typec/ucsi/trace.c
 create mode 100644 drivers/usb/typec/ucsi/trace.h
 create mode 100644 drivers/usb/typec/ucsi/ucsi.c
 create mode 100644 drivers/usb/typec/ucsi/ucsi.h

diff --git a/drivers/usb/typec/Kconfig b/drivers/usb/typec/Kconfig
index dfcfe459b7cf..bc1b7745f1d4 100644
--- a/drivers/usb/typec/Kconfig
+++ b/drivers/usb/typec/Kconfig
@@ -19,4 +19,6 @@ config TYPEC_WCOVE
  To compile this driver as module, choose M here: the module will be
  called typec_wcove
 
+source "drivers/usb/typec/ucsi/Kconfig"
+
 endmenu
diff --git a/drivers/usb/typec/Makefile b/drivers/usb/typec/Makefile
index b9cb862221af..bc214f15f1b5 100644
--- a/drivers/usb/typec/Makefile
+++ b/drivers/usb/typec/Makefile
@@ -1,2 +1,3 @@
 obj-$(CONFIG_TYPEC)+= typec.o
 obj-$(CONFIG_TYPEC_WCOVE)  += typec_wcove.o
+obj-$(CONFIG_TYPEC_UCSI)   += ucsi/
diff --git a/drivers/usb/typec/ucsi/Kconfig b/drivers/usb/typec/ucsi/Kconfig
new file mode 100644
index ..da4c5c3d8870
--- /dev/null
+++ b/drivers/usb/typec/ucsi/Kconfig
@@ -0,0 +1,23 @@
+config TYPEC_UCSI
+   tristate "USB Type-C Connector System Software Interface driver"
+   depends on !CPU_BIG_ENDIAN
+   select TYPEC
+   help
+ USB Type-C Connector System Software Interface (UCSI) is a
+ specification for an interface that allows the operating system to
+ control the USB Type-C ports. On UCSI system the USB Type-C ports
+ function autonomously by default, but in order to get the status of
+ the ports and support basic operations like role swapping, the driver
+ is required. UCSI is available on most of the new Intel based systems
+ that are equipped with Embedded Controller and USB Type-C ports.
+
+ UCSI specification does not define the interface method, so depending
+ on the platform, ACPI, PCI, I2C, etc. may be used. Therefore this
+ driver only provides the core part, and separate drivers are needed
+ for every supported interface method.
+
+ The UCSI specification can be downloaded from:
+ 
http://www.intel.com/content/www/us/en/io/universal-serial-bus/usb-type-c-ucsi-spec.html
+
+ To compile the driver as a module, choose M here: the module will be
+ called typec_ucsi.
diff --git a/drivers/usb/typec/ucsi/Makefile b/drivers/usb/typec/ucsi/Makefile
new file mode 100644
index ..87dd6ee6c9f3
--- /dev/null
+++ b/drivers/usb/typec/ucsi/Makefile
@@ -0,0 +1,7 @@
+CFLAGS_trace.o := -I$(src)
+
+obj-$(CONFIG_TYPEC_UCSI)   += typec_ucsi.o
+
+typec_ucsi-y   := ucsi.o
+
+typec_ucsi-$(CONFIG_FTRACE)+= trace.o
diff --git a/drivers/usb/typec/ucsi/debug.h b/drivers/usb/typec/ucsi/debug.h
new file mode 100644
index ..e4d8fc763e6c
--- /dev/null
+++ b/drivers/usb/typec/ucsi/debug.h
@@ -0,0 +1,64 @@
+#ifndef __UCSI_DEBUG_H
+#define __UCSI_DEBUG_H
+
+#include "ucsi.h"
+
+static const char * const ucsi_cmd_strs[] = {
+  

[PATCH v3 0/2] New driver for UCSI (USB Type-C)

[Heikki Krogerus]

Hi,

This moves the current ucsi driver from drivers/usb/misc/ucsi.c to the
new USB Type-C class (drivers/usb/typec/). That allows us to finally do
role swapping.

The driver is now split into core library part, and ACPI driver. That
should make it easy to add support for other interface methods (first
most likely being I2C) later if needed.

Changes since v2:
- Fixed ucsi_cmd_str() and ucsi_ack_str() so they don't exceed the size of the
  array as suggested by Guenter.
- Add dependency on !CPU_BIG_ENDIAN

Changes since v1:
- Added separate flag from pending ACK. Some new platforms generate "command
  complete" event on top of the normal "ACK complete" event with ACK commands.
  In such cases the driver has to be able to basically ignore the command
  completion in case of ACK and only finish acknowledge routine when the actual
  ACK complete event is received. Otherwise a new command may be queued to the
  PPM before the previous has fully completed.
- Added an explanation why we are handling the PPM initialization in a work as
  suggested by Guenter.
- Fixed ucsi_reset_ppm() by removing possibility of returning -ETIMEDOUT in case
  of success right before the time expires. Suggested by Guenter.
- Replaced useless "goto err;" with "break;" in ucsi_run_command() as suggested
  by Guenter.
- Removed traceback in case of failure from ucsi_run_command() which is not
  necessary as suggested by Guenter.
- Highlighting the fact that the timeouts are in milliseconds by using _MS
  ending with the definition (UCSI_TIMEOUT_MS and UCSI_SWAP_TIMEOUT_MS) as
  suggested by Guenter.
- Including also  in ucsi.h as suggested by Guenter.
- In ucsi_acpi.c, explicitly pointing out in the comment that we can not use
  devm_ioremap_resource() as suggested by Guenter. 


Heikki Krogerus (2):
  usb: typec: Add support for UCSI interface
  usb: typec: ucsi: Add ACPI driver

 drivers/usb/misc/Kconfig|  26 --
 drivers/usb/misc/Makefile   |   1 -
 drivers/usb/misc/ucsi.c | 478 ---
 drivers/usb/typec/Kconfig   |   2 +
 drivers/usb/typec/Makefile  |   1 +
 drivers/usb/typec/ucsi/Kconfig  |  39 ++
 drivers/usb/typec/ucsi/Makefile |   9 +
 drivers/usb/typec/ucsi/debug.h  |  64 +++
 drivers/usb/typec/ucsi/trace.c  |   2 +
 drivers/usb/typec/ucsi/trace.h  | 143 ++
 drivers/usb/typec/ucsi/ucsi.c   | 790 
 drivers/usb/{misc => typec/ucsi}/ucsi.h | 187 ++--
 drivers/usb/typec/ucsi/ucsi_acpi.c  | 158 +++
 13 files changed, 1359 insertions(+), 541 deletions(-)
 delete mode 100644 drivers/usb/misc/ucsi.c
 create mode 100644 drivers/usb/typec/ucsi/Kconfig
 create mode 100644 drivers/usb/typec/ucsi/Makefile
 create mode 100644 drivers/usb/typec/ucsi/debug.h
 create mode 100644 drivers/usb/typec/ucsi/trace.c
 create mode 100644 drivers/usb/typec/ucsi/trace.h
 create mode 100644 drivers/usb/typec/ucsi/ucsi.c
 rename drivers/usb/{misc => typec/ucsi}/ucsi.h (60%)
 create mode 100644 drivers/usb/typec/ucsi/ucsi_acpi.c

-- 
2.11.0

--
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 v3 2/2] usb: typec: ucsi: Add ACPI driver

[Heikki Krogerus]

Driver for ACPI UCSI interface method. This driver replaces
the previous UCSI driver drivers/usb/misc/ucsi.c.

Signed-off-by: Heikki Krogerus 
Reviewed-by: Guenter Roeck 
---
 drivers/usb/misc/Kconfig   |  26 --
 drivers/usb/misc/Makefile  |   1 -
 drivers/usb/misc/ucsi.c| 478 -
 drivers/usb/misc/ucsi.h| 215 -
 drivers/usb/typec/ucsi/Kconfig |  16 ++
 drivers/usb/typec/ucsi/Makefile|   2 +
 drivers/usb/typec/ucsi/ucsi_acpi.c | 158 
 7 files changed, 176 insertions(+), 720 deletions(-)
 delete mode 100644 drivers/usb/misc/ucsi.c
 delete mode 100644 drivers/usb/misc/ucsi.h
 create mode 100644 drivers/usb/typec/ucsi/ucsi_acpi.c

diff --git a/drivers/usb/misc/Kconfig b/drivers/usb/misc/Kconfig
index 1d1d70d62a19..0f9f25db9163 100644
--- a/drivers/usb/misc/Kconfig
+++ b/drivers/usb/misc/Kconfig
@@ -275,29 +275,3 @@ config USB_CHAOSKEY
 
  To compile this driver as a module, choose M here: the
  module will be called chaoskey.
-
-config UCSI
-   tristate "USB Type-C Connector System Software Interface driver"
-   depends on ACPI
-   help
- UCSI driver is meant to be used as a convenience tool for desktop and
- server systems that are not equipped to handle USB in device mode. It
- will always select USB host role for the USB Type-C ports on systems
- that provide UCSI interface.
-
- USB Type-C Connector System Software Interface (UCSI) is a
- specification for an interface that allows the Operating System to
- control the USB Type-C ports on a system. Things the need controlling
- include the USB Data Role (host or device), and when USB Power
- Delivery is supported, the Power Role (source or sink). With USB
- Type-C connectors, when two dual role capable devices are attached
- together, the data role is selected randomly. Therefore it is
- important to give the OS a way to select the role. Otherwise the user
- would have to unplug and replug in order in order to attempt to swap
- the data and power roles.
-
- The UCSI specification can be downloaded from:
- 
http://www.intel.com/content/www/us/en/io/universal-serial-bus/usb-type-c-ucsi-spec.html
-
- To compile the driver as a module, choose M here: the module will be
- called ucsi.
diff --git a/drivers/usb/misc/Makefile b/drivers/usb/misc/Makefile
index f6ac6c99a6e6..7fdb45fc976f 100644
--- a/drivers/usb/misc/Makefile
+++ b/drivers/usb/misc/Makefile
@@ -27,7 +27,6 @@ obj-$(CONFIG_USB_HUB_USB251XB)+= usb251xb.o
 obj-$(CONFIG_USB_HSIC_USB3503) += usb3503.o
 obj-$(CONFIG_USB_HSIC_USB4604) += usb4604.o
 obj-$(CONFIG_USB_CHAOSKEY) += chaoskey.o
-obj-$(CONFIG_UCSI) += ucsi.o
 
 obj-$(CONFIG_USB_SISUSBVGA)+= sisusbvga/
 obj-$(CONFIG_USB_LINK_LAYER_TEST)  += lvstest.o
diff --git a/drivers/usb/misc/ucsi.c b/drivers/usb/misc/ucsi.c
deleted file mode 100644
index 07397bddefa3..
--- a/drivers/usb/misc/ucsi.c
+++ /dev/null
@@ -1,478 +0,0 @@
-/*
- * USB Type-C Connector System Software Interface driver
- *
- * Copyright (C) 2016, Intel Corporation
- * Author: Heikki Krogerus 
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-#include 
-#include 
-#include 
-#include 
-
-#include "ucsi.h"
-
-/* Double the time defined by MIN_TIME_TO_RESPOND_WITH_BUSY */
-#define UCSI_TIMEOUT_MS 20
-
-enum ucsi_status {
-   UCSI_IDLE = 0,
-   UCSI_BUSY,
-   UCSI_ERROR,
-};
-
-struct ucsi_connector {
-   int num;
-   struct ucsi *ucsi;
-   struct work_struct work;
-   struct ucsi_connector_capability cap;
-};
-
-struct ucsi {
-   struct device *dev;
-   struct ucsi_data __iomem *data;
-
-   enum ucsi_status status;
-   struct completion complete;
-   struct ucsi_capability cap;
-   struct ucsi_connector *connector;
-
-   /* device lock */
-   spinlock_t dev_lock;
-
-   /* PPM Communication lock */
-   struct mutex ppm_lock;
-
-   /* PPM communication flags */
-   unsigned long flags;
-#define EVENT_PENDING  0
-#define COMMAND_PENDING1
-};
-
-static int ucsi_acpi_cmd(struct ucsi *ucsi, struct ucsi_control *ctrl)
-{
-   uuid_le uuid = UUID_LE(0x6f8398c2, 0x7ca4, 0x11e4,
-  0xad, 0x36, 0x63, 0x10, 0x42, 0xb5, 0x00, 0x8f);
-   union acpi_object *obj;
-
-   ucsi->data->ctrl.raw_cmd = ctrl->raw_cmd;
-
-   obj = acpi_evaluate_dsm(ACPI_HANDLE(ucsi->dev), uuid.b, 1, 1, NULL);
-   if (!obj) {
-   dev_err(ucsi->dev, "%s: failed to evaluate _DSM\n", __func__);
-   return -EIO;
-   }
-
-   ACPI_FREE(obj);
-   return 0;
-}
-

Re: [PATCH v2] xhci: Bad Ethernet performance plugged in ASM1042A host

[Mathias Nyman]

Hi

In addition to Felipes comments I have a few ones myself.

On 09.06.2017 05:33, Jiahau Chang wrote:

v2 : fix coding format

When USB Ethernet is plugged in ASMEDIA ASM1042A xHCI host, bad
performance was manifesting in Web browser use (like download
large file such as ISO image). It is known limitation of
ASM1042A that is not compatible with driver scheduling,
As a workaround we can modify flow control handling of ASM1042A.

Signed-off-by: Jiahau Chang 
---
  drivers/usb/host/pci-quirks.c | 62 +++
  drivers/usb/host/pci-quirks.h |  1 +
  drivers/usb/host/xhci-pci.c   |  5 
  drivers/usb/host/xhci.c   |  3 +++
  drivers/usb/host/xhci.h   |  1 +
  5 files changed, 72 insertions(+)

diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
index a9a1e4c..bdeaf75 100644
--- a/drivers/usb/host/pci-quirks.c
+++ b/drivers/usb/host/pci-quirks.c
@@ -77,6 +77,12 @@
  #define USB_INTEL_USB3_PSSEN   0xD8
  #define USB_INTEL_USB3PRM  0xDC

+/*ASMEDIA quirk use*/
+#define ASMT_DATA_WRITE0_REG   0xF8
+#define ASMT_DATA_WRITE1_REG   0xFC
+#define ASMT_CONTROL_REG   0xE0
+#define ASMT_CONTROL_WRITE_BIT 0x02
+
  /*
   * amd_chipset_gen values represent AMD different chipset generations
   */
@@ -412,6 +418,62 @@ void usb_amd_quirk_pll_disable(void)
  }
  EXPORT_SYMBOL_GPL(usb_amd_quirk_pll_disable);

+void usb_asmedia_modifyflowcontrol(struct pci_dev *pdev)
+{
+   u32 value_low, value_high;
+   unsigned char value;
+   unsigned long wait_time_count;
+
+   wait_time_count = 1000;
+   while (wait_time_count) {
+   pci_read_config_byte(pdev, ASMT_CONTROL_REG, &value);
+   if (value == 0xff) {
+   dev_dbg(&pdev->dev, "%s: wait_write_ready IO_ERROR, 
value=%x\n",
+   __func__, value);


Printing value=%x isn't very useful here. We know it's 0xff.


+   goto err_exit;
+   } else if ((value & ASMT_CONTROL_WRITE_BIT) == 0) {
+   break;
+   }
+   wait_time_count--;
+   udelay(50);


1000 * 50us = 50ms delay
plus another 50ms later on equals 100ms worst case.

If that is what it takes then it can't be helped.


+   }
+   if (wait_time_count == 0) {
+   dev_dbg(&pdev->dev, "%s: wait_write_ready timeout\n",
+   __func__);
+   goto err_exit;
+   }
+   value_low = 0x00010423;
+   value_high = 0xFA30;
+   pci_write_config_dword(pdev, ASMT_DATA_WRITE0_REG, value_low);
+   pci_write_config_dword(pdev, ASMT_DATA_WRITE1_REG, value_high);
+   pci_write_config_byte(pdev, ASMT_CONTROL_REG, ASMT_CONTROL_WRITE_BIT);


From here onwards:


+   wait_time_count = 1000;
+   while (wait_time_count) {
+   pci_read_config_byte(pdev, ASMT_CONTROL_REG, &value);
+   if (value == 0xff) {
+   dev_dbg(&pdev->dev, "%s: wait_write_ready IO_ERROR, 
value=%x\n",
+   __func__, value);
+   goto err_exit;
+   } else if ((value & ASMT_CONTROL_WRITE_BIT) == 0) {
+   break;
+   }
+   wait_time_count--;
+   udelay(50);
+   }
+   if (wait_time_count == 0) {
+   dev_dbg(&pdev->dev, "%s: wait_write_ready timeout\n",
+   __func__);
+   goto err_exit;


To here, we have the exact same code duplicated as the first loop.
Maybe restructure the code it a bit to avoid that.

Even the debug messages are exactly the same, easier to debug if they were a bit
different.

-Mathias

--
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 v2] net: phy: Make phy_ethtool_ksettings_get return void

[David Miller]

From: David Miller 
Date: Mon, 12 Jun 2017 10:25:25 -0400 (EDT)

> From: Yuval Shaia 
> Date: Mon, 12 Jun 2017 17:15:08 +0300
> 
>> Make return value void since function never return meaningfull value
>> 
>> Signed-off-by: Yuval Shaia 
>> Acked-by: Sergei Shtylyov 
>> ---
>> v0 ->v1:
>>  * These files were missing in v0
>>  * drivers/net/ethernet/renesas/ravb_main.c
>>  * drivers/net/ethernet/renesas/sh_eth.c
>>  * drivers/net/ethernet/ti/netcp_ethss.c
>>  * Add Acked-by: Sergei Shtylyov
>> v1 -> v2:
>>  * Adjust to net-next tree
> 
> Applied, thank you.

Reverted, please test your build properly:

drivers/net/ethernet/apm/xgene/xgene_enet_ethtool.c: In function 
‘xgene_get_link_ksettings’:
drivers/net/ethernet/apm/xgene/xgene_enet_ethtool.c:134:10: error: void value 
not ignored as it ought to be
   return phy_ethtool_ksettings_get(phydev, cmd);
  ^
drivers/net/ethernet/apm/xgene/xgene_enet_ethtool.c:140:11: error: void value 
not ignored as it ought to be
return phy_ethtool_ksettings_get(phydev, cmd);
   ^
scripts/Makefile.build:302: recipe for target 
'drivers/net/ethernet/apm/xgene/xgene_enet_ethtool.o' failed

Re: Piping f_acm to real hardware

[Tal Shorer]

On Mon, Jun 12, 2017 at 4:34 PM, Greg KH  wrote:
> On Mon, Jun 12, 2017 at 04:00:56PM +0300, Tal Shorer wrote:
>> On Mon, Jun 12, 2017 at 2:42 PM, Greg KH  wrote:
>> > On Mon, Jun 12, 2017 at 01:17:18PM +0300, Tal Shorer wrote:
>> >> On Mon, Jun 12, 2017 at 9:48 AM, Greg KH  
>> >> wrote:
>> >> > On Sun, Jun 11, 2017 at 11:41:02PM +0300, Tal Shorer wrote:
>> >> >> I'm currently working on a project where I'd like to have an omap board
>> >> >> running linux be a usb-to-uart converter (using f_acm). I have an
>> >> >> application that holds both the ttyGS* and the ttyO* port (the physical
>> >> >> uart port) open, polls for readable data, and writes any incoming data
>> >> >> to the other side.
>> >> >>
>> >> >> I'd also like the host to be able to configure baudrate, parity, etc.
>> >> >> My thought on how to achieve this is to modify how the ttyGS* ports
>> >> >> behave by adding a POLLPRI event when set_line_coding is received. In
>> >> >> order to do that several steps will have to be taken:
>> >> >> - one of:
>> >> >> 1. add a poll() callback to struct tty_operations and call it in
>> >> >> n_tty_poll(). u_serial and f_acm will implement required
>> >> >> callbacks to allow returning POLLPRI when necessary.
>> >> >> 2. add a flag to struct tty_struct that indicates an exceptional
>> >> >> condition and make n_tty_poll() return POLLPRI if that flag is
>> >> >> set. this will also require a new wait queue to allow us to 
>> >> >> wait
>> >> >> for such an event.
>> >> >> - after receiving SET_LINE_CODING (and verifying it), set whatever flag
>> >> >> is necessary to wake the user with POLLPRI.
>> >> >> - implement the ioctl() callback in u_serial and f_acm to allow the
>> >> >> user to get the line coding set by the host, with which it can
>> >> >> configure the hardware port accordingly.
>> >> >>
>> >> >> Does my approach make sense? Assuming I do that, which tree should such
>> >> >> a series be sent to? usb-gadget? tty?
>> >> >
>> >> > Why not just do it all in userspace, a simple "loopback" program should
>> >> > be able to handle this.  If not, look into the 'serdev' interface now in
>> >> > the kernel, that might help out a lot with what you want to do here.
>> >> >
>> >> > And I really doubt you need to touch the tty core or ldisc for this,
>> >> > that seems a bit extreme.
>> >> >
>> >> > good luck!
>> >> >
>> >> > greg k-h
>> >>
>> >> I'm not sure what you mean by "loopback", but if you mean an
>> >> application that poll()s the two sides, reads from one side and writes
>> >> to the other, I'm already doing that. My issue is that:
>> >> 1. f_acm doesn't do anything with set_line_coding.
>> >> 2. even if it did, the tty core has no easy way to notify the user of 
>> >> that.
>> >
>> > Ah, I understand now, thanks.  Yeah, that's a problem :)
>> >
>> > Good luck!
>> >
>> > greg k-h
>> Which of the two approaches do you think is cleaner? I tend to favour
>> the first. Should this be split into two series, one for tty core and
>> one for the gadget stuff or should this be one long series? If one
>> series, which tree should I submit this to?
>
> One long series is fine, post to both lists and let's see how it works
> out...
>
> greg k-h
Alright, so I'm about to add a new ioctl for ttyGS* devices when used
with acm, which means I should it to a uapi header file somewhere.
include/uapi/linux/usb/cdc.h makes the most sense from the existing
ones, but it's currently only definitions and I see the value in
keeping it that way. Should I create a new uapi file, maybe called
include/uapi/linux/usb/f_acm.h or use the existing one?
--
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 v2] xhci: Bad Ethernet performance plugged in ASM1042A host

[David Laight]

From: Mathias Nyman
> Sent: 12 June 2017 15:49

Commenting on this copy because it is handy...
> On 09.06.2017 05:33, Jiahau Chang wrote:
> > v2 : fix coding format
> >
> > When USB Ethernet is plugged in ASMEDIA ASM1042A xHCI host, bad
> > performance was manifesting in Web browser use (like download
> > large file such as ISO image). It is known limitation of
> > ASM1042A that is not compatible with driver scheduling,
> > As a workaround we can modify flow control handling of ASM1042A.

I think you need to be more explicit both in the commit message
and in the code about what the actual problem is, and what the
actual effect of the control register writes is.

> >
> > Signed-off-by: Jiahau Chang 
> > ---
> >   drivers/usb/host/pci-quirks.c | 62 
> > +++
> >   drivers/usb/host/pci-quirks.h |  1 +
> >   drivers/usb/host/xhci-pci.c   |  5 
> >   drivers/usb/host/xhci.c   |  3 +++
> >   drivers/usb/host/xhci.h   |  1 +
> >   5 files changed, 72 insertions(+)
> >
> > diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
> > index a9a1e4c..bdeaf75 100644
> > --- a/drivers/usb/host/pci-quirks.c
> > +++ b/drivers/usb/host/pci-quirks.c
> > @@ -77,6 +77,12 @@
> >   #define USB_INTEL_USB3_PSSEN   0xD8
> >   #define USB_INTEL_USB3PRM  0xDC
> >
> > +/*ASMEDIA quirk use*/
> > +#define ASMT_DATA_WRITE0_REG   0xF8
> > +#define ASMT_DATA_WRITE1_REG   0xFC
> > +#define ASMT_CONTROL_REG   0xE0
> > +#define ASMT_CONTROL_WRITE_BIT 0x02
> > +
> >   /*
> >* amd_chipset_gen values represent AMD different chipset generations
> >*/
> > @@ -412,6 +418,62 @@ void usb_amd_quirk_pll_disable(void)
> >   }
> >   EXPORT_SYMBOL_GPL(usb_amd_quirk_pll_disable);
> >
> > +void usb_asmedia_modifyflowcontrol(struct pci_dev *pdev)
> > +{
> > +   u32 value_low, value_high;
> > +   unsigned char value;
> > +   unsigned long wait_time_count;
> > +
> > +   wait_time_count = 1000;
> > +   while (wait_time_count) {
> > +   pci_read_config_byte(pdev, ASMT_CONTROL_REG, &value);
> > +   if (value == 0xff) {
> > +   dev_dbg(&pdev->dev, "%s: wait_write_ready IO_ERROR, 
> > value=%x\n",
> > +   __func__, value);
> 
> Printing value=%x isn't very useful here. We know it's 0xff.
> 
> > +   goto err_exit;

No need for else after goto.

> > +   } else if ((value & ASMT_CONTROL_WRITE_BIT) == 0) {
> > +   break;
> > +   }
> > +   wait_time_count--;
> > +   udelay(50);
> 
> 1000 * 50us = 50ms delay
> plus another 50ms later on equals 100ms worst case.
> 
> If that is what it takes then it can't be helped.

If this is a probe function, can it at least be arranged to sleep?

> 
> > +   }
> > +   if (wait_time_count == 0) {
> > +   dev_dbg(&pdev->dev, "%s: wait_write_ready timeout\n",
> > +   __func__);
> > +   goto err_exit;
> > +   }
> > +   value_low = 0x00010423;
> > +   value_high = 0xFA30;
> > +   pci_write_config_dword(pdev, ASMT_DATA_WRITE0_REG, value_low);
> > +   pci_write_config_dword(pdev, ASMT_DATA_WRITE1_REG, value_high);
> > +   pci_write_config_byte(pdev, ASMT_CONTROL_REG, ASMT_CONTROL_WRITE_BIT);
> 
>  From here onwards:
> 
> > +   wait_time_count = 1000;
> > +   while (wait_time_count) {
> > +   pci_read_config_byte(pdev, ASMT_CONTROL_REG, &value);
> > +   if (value == 0xff) {
> > +   dev_dbg(&pdev->dev, "%s: wait_write_ready IO_ERROR, 
> > value=%x\n",
> > +   __func__, value);
> > +   goto err_exit;
> > +   } else if ((value & ASMT_CONTROL_WRITE_BIT) == 0) {
> > +   break;
> > +   }
> > +   wait_time_count--;
> > +   udelay(50);
> > +   }
> > +   if (wait_time_count == 0) {
> > +   dev_dbg(&pdev->dev, "%s: wait_write_ready timeout\n",
> > +   __func__);
> > +   goto err_exit;
> 
> To here, we have the exact same code duplicated as the first loop.
> Maybe restructure the code it a bit to avoid that.
> 
> Even the debug messages are exactly the same, easier to debug if they were a 
> bit
> different.

 David
--
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 v2] USB: serial: option: add two Longcheer device ids

[Teemu Likonen]

Johan Hovold [2017-06-12 16:30:16+02] wrote:

> Add two Longcheer device-id entries which specifically enables the
> Telewell TW-3G HSPA+ branded modem.
>
> Reported-by: Teemu Likonen 
> Cc: stable 
> Signed-off-by: Johan Hovold 
> ---
>  drivers/usb/serial/option.c | 4 
>  1 file changed, 4 insertions(+)

Tested on the mainline kernel v4.12-rc5 and works nicely. Thank you very
much!

> diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
> index 3bf61acfc26b..ebe51f11105d 100644
> --- a/drivers/usb/serial/option.c
> +++ b/drivers/usb/serial/option.c
> @@ -1877,6 +1877,10 @@ static const struct usb_device_id option_ids[] = {
> .driver_info = (kernel_ulong_t)&four_g_w100_blacklist
>   },
>   { USB_DEVICE_INTERFACE_CLASS(LONGCHEER_VENDOR_ID, 
> SPEEDUP_PRODUCT_SU9800, 0xff) },
> + { USB_DEVICE_INTERFACE_CLASS(LONGCHEER_VENDOR_ID, 0x9801, 0xff),
> +   .driver_info = (kernel_ulong_t)&net_intf3_blacklist },
> + { USB_DEVICE_INTERFACE_CLASS(LONGCHEER_VENDOR_ID, 0x9803, 0xff),
> +   .driver_info = (kernel_ulong_t)&net_intf4_blacklist },
>   { USB_DEVICE(LONGCHEER_VENDOR_ID, ZOOM_PRODUCT_4597) },
>   { USB_DEVICE(LONGCHEER_VENDOR_ID, IBALL_3_5G_CONNECT) },
>   { USB_DEVICE(HAIER_VENDOR_ID, HAIER_PRODUCT_CE100) },


signature.asc
Description: PGP signature

Re: usb/gadget: potential deadlock in gadgetfs_suspend

[Andrey Konovalov]

On Fri, Jun 9, 2017 at 9:14 PM, Alan Stern  wrote:
> On Fri, 9 Jun 2017, Andrey Konovalov wrote:
>
>> On Fri, Jun 9, 2017 at 2:41 PM, Andrey Konovalov  
>> wrote:
>> > Hi,
>> >
>> > I'm getting some hangs while fuzzing the kernel with syzkaller.
>> >
>> > Possibly it happens during the execution of the following syzkaller 
>> > program:
>> >
>> > mmap(&(0x7f00/0xb9)=nil, (0xb9), 0x3, 0x32,
>> > 0x, 0x0)
>> > r0 = 
>> > open$usb(&(0x7f001000)="2f6465762f6761646765742f64756d6d795f75646300",
>> > 0xc002, 0x0)
>> > r1 = 
>> > open$usb(&(0x7f002000)="2f6465762f6761646765742f64756d6d795f75646300",
>> > 0x1, 0x102)
>> > write$usb(r1, &(0x7f003000)={0x0, {0x9, 0x2, 0x1b, 0x0, 0x5, 0x0,
>> > 0x80, 0x8, 0x9, 0x4, 0x1000, 0xfef9, 0x1, 0xff, 0x0,
>
> I don't understand these large constants.  They're supposed to be __u8
> values.  Do they get truncated to the least significant byte?

This program doesn't lead to crashes, it was a bug in syzkaller. The
format keeps changing, I'll explain it if I send another program.

>
>> > 0x8, 0x80, [{0x9, 0x5, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}]}, {0x12, 0x1,
>> > 0x0, 0x0, 0x4b5, 0x7c, 0x0, 0x3, 0x4, 0x0, 0x8, 0xd686, 0x0, 0x1}},
>> > 0x31)
>> >
>> > I haven't managed to get the exact same stack trace (or any at all
>> > actually) while trying to reproduce the bug with this program, but the
>> > kernel definitely hangs.

It seems that I get the stall reports quite rarely and I can't
reproduce them. However I get the "bad spinlock magic" crashes quite
often and able to reproduce them. So I can apply debug patches.

Reproducing sometimes requires quite some time (~10 minutes), so this
seems to be some kind of race. I noticed, that often I unmount
gadgetfs before the USB device has enough time to properly initialize,
so this might be a race of unmount vs device initialization or
something similar.

>
> Can you get a usbmon trace for the test?

I wasn't able to reproduce the crash with usbmon tracing enabled.
Maybe usbmon tracing affects timings somehow and the race is quite
less likely to be triggered. I'll keep trying though.

> And can you enable debugging for the usbcore module?
>
> echo "module usbcore =p" >/sys/kernel/debug/dynamic_debug/control
>

I was able to reproduce the crash with debugging for usbcore enabled:

https://gist.github.com/xairy/52bfb302d824eb55d39776eb156812cc

>> > On commit b29794ec95c6856b316c2295904208bf11ffddd9 (4.12-rc4+) with
>> > Alan's patch applied.
>> >
>> > gadgetfs: bound to dummy_udc driver
>> > gadgetfs: suspended from state 2
>> > INFO: rcu_sched detected stalls on CPUs/tasks:
>> > 1-...: (0 ticks this GP) idle=966/140/0 softirq=37706/37706 
>> > fqs=5250
>> > (detected by 2, t=21002 jiffies, g=26575, c=26574, q=183)
>> > Sending NMI from CPU 2 to CPUs 1:
>> > NMI backtrace for cpu 1
>> > CPU: 1 PID: 1394 Comm: kworker/1:2 Not tainted 4.12.0-rc4+ #24
>> > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 
>> > 01/01/2011
>> > Workqueue: usb_hub_wq hub_event
>> > task: 88003ebfb640 task.stack: c900024fc000
>> > RIP: 0010:rep_nop arch/x86/include/asm/processor.h:619 [inline]
>> > RIP: 0010:cpu_relax arch/x86/include/asm/processor.h:624 [inline]
>> > RIP: 0010:virt_spin_lock arch/x86/include/asm/qspinlock.h:63 [inline]
>> > RIP: 0010:queued_spin_lock_slowpath+0x20/0x1a0 
>> > kernel/locking/qspinlock.c:421
>> > RSP: 0018:c900024ff9f0 EFLAGS: 0002
>> > RAX: 7d72e420 RBX: 88007d72e768 RCX: 0001
>> > RDX: 0001 RSI: 7d72e420 RDI: 88007d72e768
>> > RBP: c900024ff9f0 R08: 0006 R09: 0020
>> > R10: c900024ffa50 R11: 00d52301 R12: 88007da9c298
>> > R13:  R14:  R15: 82cfc5a0
>> > FS:  () GS:88003ed0() 
>> > knlGS:
>> > CS:  0010 DS:  ES:  CR0: 80050033
>> > CR2: 7f728a487000 CR3: 371e6000 CR4: 06e0
>> > Call Trace:
>> >  __raw_spin_lock include/asm-generic/qspinlock.h:103 [inline]
>> >  _raw_spin_lock+0x1c/0x20 kernel/locking/spinlock.c:151
>> >  spin_lock include/linux/spinlock.h:299 [inline]
>> >  gadgetfs_suspend+0x32/0x90 drivers/usb/gadget/legacy/inode.c:1684
>
> Looks like it's waiting for the spinlock in gadgetfs_suspend.  Nothing
> else should be holding that lock.
>
> Were any other tasks stalled?

It seems that I get these stalls quite rarely and I can't reproduce them.

>
>> >  set_link_state+0x39c/0x440 drivers/usb/gadget/udc/dummy_hcd.c:455
>> >  dummy_hub_control+0x3e7/0x650 drivers/usb/gadget/udc/dummy_hcd.c:2074
>> >  rh_call_control drivers/usb/core/hcd.c:689 [inline]
>> >  rh_urb_enqueue drivers/usb/core/hcd.c:846 [inline]
>> >  usb_hcd_submit_urb+0x327/0xcf0 drivers/usb/core/hcd.c:1650
>> >  usb_submit_urb+0x355/0x6f0 drivers/usb/core/urb.c:542
>> >  usb_start_wait_urb+0x5f/0x110 drivers/usb/core/message.c:56
>> >  u

[PATCH 03/11] Creation of "usb_device_auth" LSM hook

[Salvatore Mesoraca]

Creation of a new LSM hook that can be used to authorize or deauthorize
new USB devices via the usb authorization interface.
The same hook can also prevent the authorization of a USB device via
"/sys/bus/usb/devices/DEVICE/authorized".
Using this hook an LSM could provide an higher level of granularity
than the current authorization interface.

Signed-off-by: Salvatore Mesoraca 
Cc: linux-usb@vger.kernel.org
Cc: Greg Kroah-Hartman 
---
 drivers/usb/core/hub.c| 4 
 drivers/usb/core/sysfs.c  | 6 +-
 include/linux/lsm_hooks.h | 6 ++
 include/linux/security.h  | 7 +++
 security/security.c   | 5 +
 5 files changed, 27 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index b8bb20d..58be4f0 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -4831,6 +4832,9 @@ static void hub_port_connect(struct usb_hub *hub, int 
port1, u16 portstatus,
if (udev->quirks & USB_QUIRK_DELAY_INIT)
msleep(1000);
 
+   if (security_usb_device_auth(udev))
+   usb_deauthorize_device(udev);
+
/* consecutive bus-powered hubs aren't reliable; they can
 * violate the voltage drop budget.  if the new child has
 * a "powered" LED, users should notice we didn't enable it
diff --git a/drivers/usb/core/sysfs.c b/drivers/usb/core/sysfs.c
index dfc68ed..fce9d39 100644
--- a/drivers/usb/core/sysfs.c
+++ b/drivers/usb/core/sysfs.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "usb.h"
 
 /* Active configuration fields */
@@ -742,8 +743,11 @@ static ssize_t authorized_store(struct device *dev,
result = -EINVAL;
else if (val == 0)
result = usb_deauthorize_device(usb_dev);
-   else
+   else {
+   if (security_usb_device_auth(usb_dev))
+   return -EPERM;
result = usb_authorize_device(usb_dev);
+   }
return result < 0 ? result : size;
 }
 static DEVICE_ATTR_IGNORE_LOCKDEP(authorized, S_IRUGO | S_IWUSR,
diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
index bd274db..cc0937e 100644
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h
@@ -1189,6 +1189,10 @@
  * to the @parent process for tracing.
  * @parent contains the task_struct structure for debugger process.
  * Return 0 if permission is granted.
+ * @usb_device_auth:
+ * Check if @udev device should be authorized or not.
+ * @udev contains the usb_device structure for the USB device.
+ * Return 0 if the device is allowed.
  * @capget:
  * Get the @effective, @inheritable, and @permitted capability sets for
  * the @target process.  The hook may also perform permission checking to
@@ -1352,6 +1356,7 @@
int (*ptrace_access_check)(struct task_struct *child,
unsigned int mode);
int (*ptrace_traceme)(struct task_struct *parent);
+   int (*usb_device_auth)(const struct usb_device *udev);
int (*capget)(struct task_struct *target, kernel_cap_t *effective,
kernel_cap_t *inheritable, kernel_cap_t *permitted);
int (*capset)(struct cred *new, const struct cred *old,
@@ -1670,6 +1675,7 @@ struct security_hook_heads {
struct list_head binder_transfer_file;
struct list_head ptrace_access_check;
struct list_head ptrace_traceme;
+   struct list_head usb_device_auth;
struct list_head capget;
struct list_head capset;
struct list_head capable;
diff --git a/include/linux/security.h b/include/linux/security.h
index af675b5..19bc364 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 
 struct linux_binprm;
 struct cred;
@@ -196,6 +197,7 @@ int security_binder_transfer_file(struct task_struct *from,
  struct task_struct *to, struct file *file);
 int security_ptrace_access_check(struct task_struct *child, unsigned int mode);
 int security_ptrace_traceme(struct task_struct *parent);
+int security_usb_device_auth(const struct usb_device *udev);
 int security_capget(struct task_struct *target,
kernel_cap_t *effective,
kernel_cap_t *inheritable,
@@ -434,6 +436,11 @@ static inline int security_ptrace_traceme(struct 
task_struct *parent)
return cap_ptrace_traceme(parent);
 }
 
+static inline int security_usb_device_auth(const struct usb_device *udev)
+{
+   return 0;
+}
+
 static inline int security_capget(struct task_struct *target,
   kernel_cap_t *effective,
   kernel_cap_t *inheritable,
diff --git a/security/security.c b/security/security.c
index 42c8028..e390f99 100644
--- a/se

[PATCH 4.11 078/150] usb: chipidea: imx: Do not access CLKONOFF on i.MX51

[Greg Kroah-Hartman]

4.11-stable review patch.  If anyone has any objections, please let me know.

--

From: Andrey Smirnov 

commit 62b97d502bb76c6e8d589e42e02bfcb7bdff0453 upstream.

Unlike i.MX53, i.MX51's USBOH3 register file does not implemenent
registers past offset 0x018, which includes
MX53_USB_CLKONOFF_CTRL_OFFSET and trying to access that register on
said platform results in external abort.

Fix it by enabling CLKONOFF accessing codepath only for i.MX53.

Fixes 3be3251db088 ("usb: chipidea: imx: Disable internal 60Mhz clock with ULPI 
PHY")
Cc: cphe...@gmail.com
Cc: Greg Kroah-Hartman 
Cc: linux-usb@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Andrey Smirnov 
Signed-off-by: Peter Chen 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/usb/chipidea/usbmisc_imx.c |   41 -
 1 file changed, 32 insertions(+), 9 deletions(-)

--- a/drivers/usb/chipidea/usbmisc_imx.c
+++ b/drivers/usb/chipidea/usbmisc_imx.c
@@ -108,6 +108,8 @@ struct imx_usbmisc {
const struct usbmisc_ops *ops;
 };
 
+static inline bool is_imx53_usbmisc(struct imx_usbmisc_data *data);
+
 static int usbmisc_imx25_init(struct imx_usbmisc_data *data)
 {
struct imx_usbmisc *usbmisc = dev_get_drvdata(data->dev);
@@ -242,10 +244,15 @@ static int usbmisc_imx53_init(struct imx
val = readl(reg) | MX53_USB_UHx_CTRL_WAKE_UP_EN
| MX53_USB_UHx_CTRL_ULPI_INT_EN;
writel(val, reg);
-   /* Disable internal 60Mhz clock */
-   reg = usbmisc->base + MX53_USB_CLKONOFF_CTRL_OFFSET;
-   val = readl(reg) | MX53_USB_CLKONOFF_CTRL_H2_INT60CKOFF;
-   writel(val, reg);
+   if (is_imx53_usbmisc(data)) {
+   /* Disable internal 60Mhz clock */
+   reg = usbmisc->base +
+   MX53_USB_CLKONOFF_CTRL_OFFSET;
+   val = readl(reg) |
+   MX53_USB_CLKONOFF_CTRL_H2_INT60CKOFF;
+   writel(val, reg);
+   }
+
}
if (data->disable_oc) {
reg = usbmisc->base + MX53_USB_UH2_CTRL_OFFSET;
@@ -267,10 +274,15 @@ static int usbmisc_imx53_init(struct imx
val = readl(reg) | MX53_USB_UHx_CTRL_WAKE_UP_EN
| MX53_USB_UHx_CTRL_ULPI_INT_EN;
writel(val, reg);
-   /* Disable internal 60Mhz clock */
-   reg = usbmisc->base + MX53_USB_CLKONOFF_CTRL_OFFSET;
-   val = readl(reg) | MX53_USB_CLKONOFF_CTRL_H3_INT60CKOFF;
-   writel(val, reg);
+
+   if (is_imx53_usbmisc(data)) {
+   /* Disable internal 60Mhz clock */
+   reg = usbmisc->base +
+   MX53_USB_CLKONOFF_CTRL_OFFSET;
+   val = readl(reg) |
+   MX53_USB_CLKONOFF_CTRL_H3_INT60CKOFF;
+   writel(val, reg);
+   }
}
if (data->disable_oc) {
reg = usbmisc->base + MX53_USB_UH3_CTRL_OFFSET;
@@ -456,6 +468,10 @@ static const struct usbmisc_ops imx27_us
.init = usbmisc_imx27_init,
 };
 
+static const struct usbmisc_ops imx51_usbmisc_ops = {
+   .init = usbmisc_imx53_init,
+};
+
 static const struct usbmisc_ops imx53_usbmisc_ops = {
.init = usbmisc_imx53_init,
 };
@@ -479,6 +495,13 @@ static const struct usbmisc_ops imx7d_us
.set_wakeup = usbmisc_imx7d_set_wakeup,
 };
 
+static inline bool is_imx53_usbmisc(struct imx_usbmisc_data *data)
+{
+   struct imx_usbmisc *usbmisc = dev_get_drvdata(data->dev);
+
+   return usbmisc->ops == &imx53_usbmisc_ops;
+}
+
 int imx_usbmisc_init(struct imx_usbmisc_data *data)
 {
struct imx_usbmisc *usbmisc;
@@ -536,7 +559,7 @@ static const struct of_device_id usbmisc
},
{
.compatible = "fsl,imx51-usbmisc",
-   .data = &imx53_usbmisc_ops,
+   .data = &imx51_usbmisc_ops,
},
{
.compatible = "fsl,imx53-usbmisc",


--
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: usb/gadget: potential deadlock in gadgetfs_suspend

[Andrey Konovalov]

On Mon, Jun 12, 2017 at 6:11 PM, Andrey Konovalov  wrote:
> On Fri, Jun 9, 2017 at 9:14 PM, Alan Stern  wrote:
>> On Fri, 9 Jun 2017, Andrey Konovalov wrote:
>>
>>> On Fri, Jun 9, 2017 at 2:41 PM, Andrey Konovalov  
>>> wrote:
>>> > Hi,
>>> >
>>> > I'm getting some hangs while fuzzing the kernel with syzkaller.
>>> >
>>> > Possibly it happens during the execution of the following syzkaller 
>>> > program:
>>> >
>>> > mmap(&(0x7f00/0xb9)=nil, (0xb9), 0x3, 0x32,
>>> > 0x, 0x0)
>>> > r0 = 
>>> > open$usb(&(0x7f001000)="2f6465762f6761646765742f64756d6d795f75646300",
>>> > 0xc002, 0x0)
>>> > r1 = 
>>> > open$usb(&(0x7f002000)="2f6465762f6761646765742f64756d6d795f75646300",
>>> > 0x1, 0x102)
>>> > write$usb(r1, &(0x7f003000)={0x0, {0x9, 0x2, 0x1b, 0x0, 0x5, 0x0,
>>> > 0x80, 0x8, 0x9, 0x4, 0x1000, 0xfef9, 0x1, 0xff, 0x0,
>>
>> I don't understand these large constants.  They're supposed to be __u8
>> values.  Do they get truncated to the least significant byte?
>
> This program doesn't lead to crashes, it was a bug in syzkaller. The
> format keeps changing, I'll explain it if I send another program.
>
>>
>>> > 0x8, 0x80, [{0x9, 0x5, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}]}, {0x12, 0x1,
>>> > 0x0, 0x0, 0x4b5, 0x7c, 0x0, 0x3, 0x4, 0x0, 0x8, 0xd686, 0x0, 0x1}},
>>> > 0x31)
>>> >
>>> > I haven't managed to get the exact same stack trace (or any at all
>>> > actually) while trying to reproduce the bug with this program, but the
>>> > kernel definitely hangs.
>
> It seems that I get the stall reports quite rarely and I can't
> reproduce them. However I get the "bad spinlock magic" crashes quite
> often and able to reproduce them. So I can apply debug patches.
>
> Reproducing sometimes requires quite some time (~10 minutes), so this
> seems to be some kind of race. I noticed, that often I unmount
> gadgetfs before the USB device has enough time to properly initialize,
> so this might be a race of unmount vs device initialization or
> something similar.

Aha, got KASAN report:

==
BUG: KASAN: use-after-free in __lock_acquire+0x3069/0x3690
kernel/locking/lockdep.c:3246
Read of size 8 at addr 88003a2bdaf8 by task kworker/3:1/903

CPU: 3 PID: 903 Comm: kworker/3:1 Not tainted 4.12.0-rc4+ #35
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Workqueue: usb_hub_wq hub_event
Call Trace:
 __dump_stack lib/dump_stack.c:16 [inline]
 dump_stack+0x292/0x395 lib/dump_stack.c:52
 print_address_description+0x78/0x280 mm/kasan/report.c:252
 kasan_report_error mm/kasan/report.c:351 [inline]
 kasan_report+0x230/0x340 mm/kasan/report.c:408
 __asan_report_load8_noabort+0x19/0x20 mm/kasan/report.c:429
 __lock_acquire+0x3069/0x3690 kernel/locking/lockdep.c:3246
 lock_acquire+0x22d/0x560 kernel/locking/lockdep.c:3855
 __raw_spin_lock include/linux/spinlock_api_smp.h:142 [inline]
 _raw_spin_lock+0x2f/0x40 kernel/locking/spinlock.c:151
 spin_lock include/linux/spinlock.h:299 [inline]
 gadgetfs_suspend+0x89/0x130 drivers/usb/gadget/legacy/inode.c:1682
 set_link_state+0x88e/0xae0 drivers/usb/gadget/udc/dummy_hcd.c:455
 dummy_hub_control+0xd7e/0x1fb0 drivers/usb/gadget/udc/dummy_hcd.c:2074
 rh_call_control drivers/usb/core/hcd.c:689 [inline]
 rh_urb_enqueue drivers/usb/core/hcd.c:846 [inline]
 usb_hcd_submit_urb+0x92f/0x20b0 drivers/usb/core/hcd.c:1650
 usb_submit_urb+0x8b2/0x12c0 drivers/usb/core/urb.c:542
 usb_start_wait_urb+0x148/0x5b0 drivers/usb/core/message.c:56
 usb_internal_control_msg drivers/usb/core/message.c:100 [inline]
 usb_control_msg+0x341/0x4d0 drivers/usb/core/message.c:151
 usb_clear_port_feature+0x74/0xa0 drivers/usb/core/hub.c:412
 hub_port_disable+0x123/0x510 drivers/usb/core/hub.c:4177
 hub_port_init+0x1ed/0x2940 drivers/usb/core/hub.c:4648
 hub_port_connect drivers/usb/core/hub.c:4826 [inline]
 hub_port_connect_change drivers/usb/core/hub.c:4999 [inline]
 port_event drivers/usb/core/hub.c:5105 [inline]
 hub_event+0x1ae1/0x3d40 drivers/usb/core/hub.c:5185
 process_one_work+0xc08/0x1bd0 kernel/workqueue.c:2097
 process_scheduled_works kernel/workqueue.c:2157 [inline]
 worker_thread+0xb2b/0x1860 kernel/workqueue.c:2233
 kthread+0x363/0x440 kernel/kthread.c:231
 ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:424

Allocated by task 9958:
 save_stack_trace+0x1b/0x20 arch/x86/kernel/stacktrace.c:59
 save_stack+0x43/0xd0 mm/kasan/kasan.c:513
 set_track mm/kasan/kasan.c:525 [inline]
 kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:617
 kmem_cache_alloc_trace+0x87/0x280 mm/slub.c:2745
 kmalloc include/linux/slab.h:492 [inline]
 kzalloc include/linux/slab.h:665 [inline]
 dev_new drivers/usb/gadget/legacy/inode.c:170 [inline]
 gadgetfs_fill_super+0x24f/0x540 drivers/usb/gadget/legacy/inode.c:1993
 mount_single+0xf6/0x160 fs/super.c:1192
 gadgetfs_mount+0x31/0x40 drivers/usb/gadget/legacy/inode.c:2019
 mount_fs+0x9c/0x2d0 fs/super.c:1223
 vfs_kern_mount.part.25+0xcb/0x490 fs/namespace.c:976
 vfs_ke

[PATCH 0/8] Allow f_acm gadgets to notify the user about SetLineCoding requests

[Tal Shorer]

I'm currently working on a project where I'd like to have an omap board
running linux be a usb-to-uart converter (using f_acm), and I've ran
into an issue: there's no way for the application to know if the host
has issued a SetLineCoding requests (after which parity/baudrate should
be changed to match the host's request).

This series adds the support necessary to achieve that:
- Allowing tty drivers to supply a poll() function to notify the user of
driver-specific events.
- Propagating poll() and ioctl() from u_serial to the next layer (f_acm)
in this case.
- Let the user read the current line coding set by the host (via an
ioctl() call).
- Notify the user when there's a pending SetLineCoding request they
haven't read yet

The last patch also removes up the port_line_config field from
struct gserial. It made no sense to have there (and had a REVISIT
comment at every turn), it was never used and it was initialized with
invalid values.

Tal Shorer (8):
  tty: add a poll() callback in struct tty_operations
  usb: gadget: u_serial: propagate poll() to the next layer
  usb: gadget: f_acm: validate set_line_coding requests
  usb: gadget: u_serial: propagate ioctl() to the next layer
  usb: gadget: f_acm: initialize port_line_coding when creating an
instance
  usb: gadget: f_acm: add an ioctl to get the current line coding
  usb: gadget: f_acm: notify the user on SetLineCoding
  usb: gadget: u_serial: remove port_line_config from struct gserial

 Documentation/ioctl/ioctl-number.txt   |  1 +
 drivers/tty/n_tty.c|  2 ++
 drivers/usb/gadget/function/f_acm.c| 66 +-
 drivers/usb/gadget/function/u_serial.c | 53 ---
 drivers/usb/gadget/function/u_serial.h |  7 ++--
 include/linux/tty_driver.h |  3 ++
 include/uapi/linux/usb/f_acm.h | 12 +++
 7 files changed, 113 insertions(+), 31 deletions(-)
 create mode 100644 include/uapi/linux/usb/f_acm.h

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

[PATCH 8/8] usb: gadget: u_serial: remove port_line_config from struct gserial

[Tal Shorer]

GetLineCoding and SetLineCoding are a cdc-acm thing. It doesn't make
sense to have that in the generic u_serial layer. Moreso, f_acm has its
own port_line_coding in its own struct and it uses that, while the one
in struct gserial is set once upon initialization and then never used.
Also, the initialized never-used values were invalid, with bDataBits
and bCharFormat having each other's value.

Signed-off-by: Tal Shorer 
---
 drivers/usb/gadget/function/u_serial.c | 22 ++
 drivers/usb/gadget/function/u_serial.h |  3 ---
 2 files changed, 2 insertions(+), 23 deletions(-)

diff --git a/drivers/usb/gadget/function/u_serial.c 
b/drivers/usb/gadget/function/u_serial.c
index 8d9abf1..654d4a6 100644
--- a/drivers/usb/gadget/function/u_serial.c
+++ b/drivers/usb/gadget/function/u_serial.c
@@ -129,9 +129,6 @@ struct gs_port {
wait_queue_head_t   drain_wait; /* wait while writes drain */
boolwrite_busy;
wait_queue_head_t   close_wait;
-
-   /* REVISIT this state ... */
-   struct usb_cdc_line_coding port_line_coding;/* 8-N-1 etc */
 };
 
 static struct portmaster {
@@ -1314,7 +1311,7 @@ static void gserial_console_exit(void)
 #endif
 
 static int
-gs_port_alloc(unsigned port_num, struct usb_cdc_line_coding *coding)
+gs_port_alloc(unsigned port_num)
 {
struct gs_port  *port;
int ret = 0;
@@ -1343,7 +1340,6 @@ gs_port_alloc(unsigned port_num, struct 
usb_cdc_line_coding *coding)
INIT_LIST_HEAD(&port->write_pool);
 
port->port_num = port_num;
-   port->port_line_coding = *coding;
 
ports[port_num].port = port;
 out:
@@ -1392,18 +1388,12 @@ EXPORT_SYMBOL_GPL(gserial_free_line);
 
 int gserial_alloc_line(unsigned char *line_num)
 {
-   struct usb_cdc_line_coding  coding;
struct device   *tty_dev;
int ret;
int port_num;
 
-   coding.dwDTERate = cpu_to_le32(9600);
-   coding.bCharFormat = 8;
-   coding.bParityType = USB_CDC_NO_PARITY;
-   coding.bDataBits = USB_CDC_1_STOP_BITS;
-
for (port_num = 0; port_num < MAX_U_SERIAL_PORTS; port_num++) {
-   ret = gs_port_alloc(port_num, &coding);
+   ret = gs_port_alloc(port_num);
if (ret == -EBUSY)
continue;
if (ret)
@@ -1491,11 +1481,6 @@ int gserial_connect(struct gserial *gser, u8 port_num)
gser->ioport = port;
port->port_usb = gser;
 
-   /* REVISIT unclear how best to handle this state...
-* we don't really couple it with the Linux TTY.
-*/
-   gser->port_line_coding = port->port_line_coding;
-
/* REVISIT if waiting on "carrier detect", signal. */
 
/* if it's already open, start I/O ... and notify the serial
@@ -1543,9 +1528,6 @@ void gserial_disconnect(struct gserial *gser)
/* tell the TTY glue not to do I/O here any more */
spin_lock_irqsave(&port->port_lock, flags);
 
-   /* REVISIT as above: how best to track this? */
-   port->port_line_coding = gser->port_line_coding;
-
port->port_usb = NULL;
gser->ioport = NULL;
if (port->port.count > 0 || port->openclose) {
diff --git a/drivers/usb/gadget/function/u_serial.h 
b/drivers/usb/gadget/function/u_serial.h
index 8d0901e..0549efe 100644
--- a/drivers/usb/gadget/function/u_serial.h
+++ b/drivers/usb/gadget/function/u_serial.h
@@ -44,9 +44,6 @@ struct gserial {
struct usb_ep   *in;
struct usb_ep   *out;
 
-   /* REVISIT avoid this CDC-ACM support harder ... */
-   struct usb_cdc_line_coding port_line_coding;/* 9600-8-N-1 etc */
-
/* notification callbacks */
void (*connect)(struct gserial *p);
void (*disconnect)(struct gserial *p);
-- 
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

[PATCH 4/8] usb: gadget: u_serial: propagate ioctl() to the next layer

[Tal Shorer]

In order for a serial function to implement its own ioctl() calls,
propagate the ioctl() callback to the next layer so it can handle it if
it sees fit to do so.

Signed-off-by: Tal Shorer 
---
 drivers/usb/gadget/function/u_serial.c | 15 +++
 drivers/usb/gadget/function/u_serial.h |  1 +
 2 files changed, 16 insertions(+)

diff --git a/drivers/usb/gadget/function/u_serial.c 
b/drivers/usb/gadget/function/u_serial.c
index d466f58..8d9abf1 100644
--- a/drivers/usb/gadget/function/u_serial.c
+++ b/drivers/usb/gadget/function/u_serial.c
@@ -1040,6 +1040,20 @@ static unsigned int gs_poll(struct tty_struct *tty, 
struct file *file,
return mask;
 }
 
+static int gs_ioctl(struct tty_struct *tty, unsigned int cmd, unsigned long 
arg)
+{
+   struct gs_port *port = tty->driver_data;
+   struct gserial *gser;
+   int ret = -ENOIOCTLCMD;
+
+   spin_lock_irq(&port->port_lock);
+   gser = port->port_usb;
+   if (gser && gser->ioctl)
+   ret = gser->ioctl(gser, cmd, arg);
+   spin_unlock_irq(&port->port_lock);
+   return ret;
+}
+
 static const struct tty_operations gs_tty_ops = {
.open = gs_open,
.close =gs_close,
@@ -1051,6 +1065,7 @@ static const struct tty_operations gs_tty_ops = {
.unthrottle =   gs_unthrottle,
.break_ctl =gs_break_ctl,
.poll = gs_poll,
+   .ioctl =gs_ioctl,
 };
 
 /*-*/
diff --git a/drivers/usb/gadget/function/u_serial.h 
b/drivers/usb/gadget/function/u_serial.h
index ce00840..8d0901e 100644
--- a/drivers/usb/gadget/function/u_serial.h
+++ b/drivers/usb/gadget/function/u_serial.h
@@ -53,6 +53,7 @@ struct gserial {
int (*send_break)(struct gserial *p, int duration);
unsigned int (*poll)(struct gserial *p, struct file *file,
poll_table *wait);
+   int (*ioctl)(struct gserial *p, unsigned int cmd, unsigned long arg);
 };
 
 /* utilities to allocate/free request and buffer */
-- 
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

[PATCH 6/8] usb: gadget: f_acm: add an ioctl to get the current line coding

[Tal Shorer]

The user can issue USB_F_GET_LINE_CODING to get the current line coding
as set by the host (or the default if unset yet).

Signed-off-by: Tal Shorer 
---
 Documentation/ioctl/ioctl-number.txt |  1 +
 drivers/usb/gadget/function/f_acm.c  | 27 +++
 include/uapi/linux/usb/f_acm.h   | 12 
 3 files changed, 36 insertions(+), 4 deletions(-)
 create mode 100644 include/uapi/linux/usb/f_acm.h

diff --git a/Documentation/ioctl/ioctl-number.txt 
b/Documentation/ioctl/ioctl-number.txt
index 1e9fcb4..3d70680 100644
--- a/Documentation/ioctl/ioctl-number.txt
+++ b/Documentation/ioctl/ioctl-number.txt
@@ -329,6 +329,7 @@ Code  Seq#(hex) Include FileComments
 0xCA   80-8F   uapi/scsi/cxlflash_ioctl.h
 0xCB   00-1F   CBM serial IEC bus  in development:


+0xCD   10-1F   linux/usb/f_acm.h
 0xCD   01  linux/reiserfs_fs.h
 0xCF   02  fs/cifs/ioctl.c
 0xDB   00-0F   drivers/char/mwave/mwavepub.h
diff --git a/drivers/usb/gadget/function/f_acm.c 
b/drivers/usb/gadget/function/f_acm.c
index b7a1466..5feea7c 100644
--- a/drivers/usb/gadget/function/f_acm.c
+++ b/drivers/usb/gadget/function/f_acm.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "u_serial.h"
 
@@ -611,6 +612,23 @@ static int acm_send_break(struct gserial *port, int 
duration)
return acm_notify_serial_state(acm);
 }
 
+static int acm_ioctl(struct gserial *port, unsigned int cmd, unsigned long arg)
+{
+   struct f_acm*acm = port_to_acm(port);
+   int ret = -ENOIOCTLCMD;
+
+   switch (cmd) {
+   case USB_F_ACM_GET_LINE_CODING:
+   if (copy_to_user((__user void *)arg, &acm->port_line_coding,
+   sizeof(acm->port_line_coding)))
+   ret = -EFAULT;
+   else
+   ret = 0;
+   break;
+   }
+   return ret;
+}
+
 /*-*/
 
 /* ACM function driver setup/binding */
@@ -749,6 +767,7 @@ static struct usb_function *acm_alloc_func(struct 
usb_function_instance *fi)
acm->port.connect = acm_connect;
acm->port.disconnect = acm_disconnect;
acm->port.send_break = acm_send_break;
+   acm->port.ioctl = acm_ioctl;
 
acm->port.func.name = "acm";
acm->port.func.strings = acm_strings;
@@ -764,10 +783,10 @@ static struct usb_function *acm_alloc_func(struct 
usb_function_instance *fi)
acm->port.func.free_func = acm_free_func;
 
/* initialize port_line_coding with something that makes sense */
-   coding.dwDTERate = cpu_to_le32(9600);
-   coding.bCharFormat = USB_CDC_1_STOP_BITS;
-   coding.bParityType = USB_CDC_NO_PARITY;
-   coding.bDataBits = 8;
+   acm->port_line_coding.dwDTERate = cpu_to_le32(9600);
+   acm->port_line_coding.bCharFormat = USB_CDC_1_STOP_BITS;
+   acm->port_line_coding.bParityType = USB_CDC_NO_PARITY;
+   acm->port_line_coding.bDataBits = 8;
 
return &acm->port.func;
 }
diff --git a/include/uapi/linux/usb/f_acm.h b/include/uapi/linux/usb/f_acm.h
new file mode 100644
index 000..51f96f0
--- /dev/null
+++ b/include/uapi/linux/usb/f_acm.h
@@ -0,0 +1,12 @@
+/* f_acm.h -- Header file for USB CDC-ACM gadget function */
+
+#ifndef __UAPI_LINUX_USB_F_ACM_H
+#define __UAPI_LINUX_USB_F_ACM_H
+
+#include 
+#include 
+
+/* The 0xCD code is also used by reiserfs. we use 0x10-0x1F range */
+#define USB_F_ACM_GET_LINE_CODING _IOR(0xCD, 0x10, struct usb_cdc_line_coding)
+
+#endif /* __UAPI_LINUX_USB_F_ACM_H */
-- 
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

[PATCH 3/8] usb: gadget: f_acm: validate set_line_coding requests

[Tal Shorer]

We shouldn't accept malformed set_line_coding requests.
All values were taken from table 17 (section 6.3.11) of the cdc1.2 spec
available at http://www.usb.org/developers/docs/devclass_docs/
The table is in the file PTSN120.pdf.

Signed-off-by: Tal Shorer 
---
 drivers/usb/gadget/function/f_acm.c | 23 ---
 1 file changed, 16 insertions(+), 7 deletions(-)

diff --git a/drivers/usb/gadget/function/f_acm.c 
b/drivers/usb/gadget/function/f_acm.c
index 5e3828d..e023313 100644
--- a/drivers/usb/gadget/function/f_acm.c
+++ b/drivers/usb/gadget/function/f_acm.c
@@ -326,13 +326,22 @@ static void acm_complete_set_line_coding(struct usb_ep 
*ep,
struct usb_cdc_line_coding  *value = req->buf;
 
/* REVISIT:  we currently just remember this data.
-* If we change that, (a) validate it first, then
-* (b) update whatever hardware needs updating,
-* (c) worry about locking.  This is information on
-* the order of 9600-8-N-1 ... most of which means
-* nothing unless we control a real RS232 line.
-*/
-   acm->port_line_coding = *value;
+   * If we change that,
+   * (a) update whatever hardware needs updating,
+   * (b) worry about locking.  This is information on
+   * the order of 9600-8-N-1 ... most of which means
+   * nothing unless we control a real RS232 line.
+   */
+   dev_dbg(&cdev->gadget->dev,
+   "acm ttyGS%d set_line_coding: %d %d %d %d\n",
+   acm->port_num, le32_to_cpu(value->dwDTERate),
+   value->bCharFormat, value->bParityType,
+   value->bDataBits);
+   if (value->bCharFormat > 2 || value->bParityType > 4 ||
+   value->bDataBits < 5 || value->bDataBits > 8)
+   usb_ep_set_halt(ep);
+   else
+   acm->port_line_coding = *value;
}
 }
 
-- 
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

[PATCH 5/8] usb: gadget: f_acm: initialize port_line_coding when creating an instance

[Tal Shorer]

Initialize acm->port_line_coding with something that makes sense so
that we can return a valid line coding if the host requests
GetLineCoding before requesting SetLineCoding

Signed-off-by: Tal Shorer 
---
 drivers/usb/gadget/function/f_acm.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/usb/gadget/function/f_acm.c 
b/drivers/usb/gadget/function/f_acm.c
index e023313..b7a1466 100644
--- a/drivers/usb/gadget/function/f_acm.c
+++ b/drivers/usb/gadget/function/f_acm.c
@@ -763,6 +763,12 @@ static struct usb_function *acm_alloc_func(struct 
usb_function_instance *fi)
acm->port.func.unbind = acm_unbind;
acm->port.func.free_func = acm_free_func;
 
+   /* initialize port_line_coding with something that makes sense */
+   coding.dwDTERate = cpu_to_le32(9600);
+   coding.bCharFormat = USB_CDC_1_STOP_BITS;
+   coding.bParityType = USB_CDC_NO_PARITY;
+   coding.bDataBits = 8;
+
return &acm->port.func;
 }
 
-- 
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

[PATCH 7/8] usb: gadget: f_acm: notify the user on SetLineCoding

[Tal Shorer]

Notify the user with a POLLPRI event when the host issues a
SetLineCoding request so that they can act upon it, for example by
configuring the line coding on a real serial port.

The event is cleared when the user reads the line coding using
USB_F_ACM_GET_LINE_CODING ioctl()

Signed-off-by: Tal Shorer 
---
 drivers/usb/gadget/function/f_acm.c | 38 ++---
 1 file changed, 27 insertions(+), 11 deletions(-)

diff --git a/drivers/usb/gadget/function/f_acm.c 
b/drivers/usb/gadget/function/f_acm.c
index 5feea7c..0983999 100644
--- a/drivers/usb/gadget/function/f_acm.c
+++ b/drivers/usb/gadget/function/f_acm.c
@@ -58,6 +58,9 @@ struct f_acm {
struct usb_request  *notify_req;
 
struct usb_cdc_line_coding  port_line_coding;   /* 8-N-1 etc */
+   /* we have a SetLineCoding request that the user haven't read yet */
+   bool set_line_coding_pending;
+   wait_queue_head_t set_line_coding_waitq;
 
/* SetControlLineState request -- CDC 1.1 section 6.2.14 (INPUT) */
u16 port_handshake_bits;
@@ -326,23 +329,19 @@ static void acm_complete_set_line_coding(struct usb_ep 
*ep,
} else {
struct usb_cdc_line_coding  *value = req->buf;
 
-   /* REVISIT:  we currently just remember this data.
-   * If we change that,
-   * (a) update whatever hardware needs updating,
-   * (b) worry about locking.  This is information on
-   * the order of 9600-8-N-1 ... most of which means
-   * nothing unless we control a real RS232 line.
-   */
dev_dbg(&cdev->gadget->dev,
"acm ttyGS%d set_line_coding: %d %d %d %d\n",
acm->port_num, le32_to_cpu(value->dwDTERate),
value->bCharFormat, value->bParityType,
value->bDataBits);
if (value->bCharFormat > 2 || value->bParityType > 4 ||
-   value->bDataBits < 5 || value->bDataBits > 8)
+   value->bDataBits < 5 || value->bDataBits > 8) {
usb_ep_set_halt(ep);
-   else
+   } else {
acm->port_line_coding = *value;
+   acm->set_line_coding_pending = true;
+   wake_up_interruptible(&acm->set_line_coding_waitq);
+   }
}
 }
 
@@ -598,6 +597,19 @@ static void acm_disconnect(struct gserial *port)
acm_notify_serial_state(acm);
 }
 
+static unsigned int acm_poll(struct gserial *port, struct file *file,
+   poll_table *wait)
+{
+   unsigned int mask = 0;
+   struct f_acm *acm = port_to_acm(port);
+
+   poll_wait(file, &acm->set_line_coding_waitq, wait);
+   if (acm->set_line_coding_pending)
+   mask |= POLLPRI;
+   return mask;
+}
+
+
 static int acm_send_break(struct gserial *port, int duration)
 {
struct f_acm*acm = port_to_acm(port);
@@ -620,10 +632,12 @@ static int acm_ioctl(struct gserial *port, unsigned int 
cmd, unsigned long arg)
switch (cmd) {
case USB_F_ACM_GET_LINE_CODING:
if (copy_to_user((__user void *)arg, &acm->port_line_coding,
-   sizeof(acm->port_line_coding)))
+   sizeof(acm->port_line_coding))) {
ret = -EFAULT;
-   else
+   } else {
ret = 0;
+   acm->set_line_coding_pending = false;
+   }
break;
}
return ret;
@@ -763,11 +777,13 @@ static struct usb_function *acm_alloc_func(struct 
usb_function_instance *fi)
return ERR_PTR(-ENOMEM);
 
spin_lock_init(&acm->lock);
+   init_waitqueue_head(&acm->set_line_coding_waitq);
 
acm->port.connect = acm_connect;
acm->port.disconnect = acm_disconnect;
acm->port.send_break = acm_send_break;
acm->port.ioctl = acm_ioctl;
+   acm->port.poll = acm_poll;
 
acm->port.func.name = "acm";
acm->port.func.strings = acm_strings;
-- 
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

[PATCH 2/8] usb: gadget: u_serial: propagate poll() to the next layer

[Tal Shorer]

In order for a serial function to add flags to the poll() mask of their
tty files, propagate the poll() callback to the next layer so it can
return a mask if it sees fit to do so.

Signed-off-by: Tal Shorer 
---
 drivers/usb/gadget/function/u_serial.c | 16 
 drivers/usb/gadget/function/u_serial.h |  3 +++
 2 files changed, 19 insertions(+)

diff --git a/drivers/usb/gadget/function/u_serial.c 
b/drivers/usb/gadget/function/u_serial.c
index 9b0805f..d466f58 100644
--- a/drivers/usb/gadget/function/u_serial.c
+++ b/drivers/usb/gadget/function/u_serial.c
@@ -1025,6 +1025,21 @@ static int gs_break_ctl(struct tty_struct *tty, int 
duration)
return status;
 }
 
+static unsigned int gs_poll(struct tty_struct *tty, struct file *file,
+   poll_table *wait)
+{
+   struct gs_port *port = tty->driver_data;
+   struct gserial *gser;
+   unsigned int mask = 0;
+
+   spin_lock_irq(&port->port_lock);
+   gser = port->port_usb;
+   if (gser && gser->poll)
+   mask |= gser->poll(gser, file, wait);
+   spin_unlock_irq(&port->port_lock);
+   return mask;
+}
+
 static const struct tty_operations gs_tty_ops = {
.open = gs_open,
.close =gs_close,
@@ -1035,6 +1050,7 @@ static const struct tty_operations gs_tty_ops = {
.chars_in_buffer =  gs_chars_in_buffer,
.unthrottle =   gs_unthrottle,
.break_ctl =gs_break_ctl,
+   .poll = gs_poll,
 };
 
 /*-*/
diff --git a/drivers/usb/gadget/function/u_serial.h 
b/drivers/usb/gadget/function/u_serial.h
index c20210c..ce00840 100644
--- a/drivers/usb/gadget/function/u_serial.h
+++ b/drivers/usb/gadget/function/u_serial.h
@@ -12,6 +12,7 @@
 #ifndef __U_SERIAL_H
 #define __U_SERIAL_H
 
+#include 
 #include 
 #include 
 
@@ -50,6 +51,8 @@ struct gserial {
void (*connect)(struct gserial *p);
void (*disconnect)(struct gserial *p);
int (*send_break)(struct gserial *p, int duration);
+   unsigned int (*poll)(struct gserial *p, struct file *file,
+   poll_table *wait);
 };
 
 /* utilities to allocate/free request and buffer */
-- 
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

[PATCH 1/8] tty: add a poll() callback in struct tty_operations

[Tal Shorer]

If a tty driver wants to notify the user of some exceptional event,
such as a usb cdc acm device set_line_coding event, it needs a way to
modify the mask returned by poll() and possible also add wait queues.
In order to do that, we allow the driver to supply a poll() callback
of its own, which will be called in n_tty_poll().

Signed-off-by: Tal Shorer 
---
 drivers/tty/n_tty.c| 2 ++
 include/linux/tty_driver.h | 3 +++
 2 files changed, 5 insertions(+)

diff --git a/drivers/tty/n_tty.c b/drivers/tty/n_tty.c
index bdf0e6e..7af8c29 100644
--- a/drivers/tty/n_tty.c
+++ b/drivers/tty/n_tty.c
@@ -2394,6 +2394,8 @@ static unsigned int n_tty_poll(struct tty_struct *tty, 
struct file *file,
tty_chars_in_buffer(tty) < WAKEUP_CHARS &&
tty_write_room(tty) > 0)
mask |= POLLOUT | POLLWRNORM;
+   if (tty->ops->poll)
+   mask |= tty->ops->poll(tty, file, wait);
return mask;
 }
 
diff --git a/include/linux/tty_driver.h b/include/linux/tty_driver.h
index b742b5e..630ef03 100644
--- a/include/linux/tty_driver.h
+++ b/include/linux/tty_driver.h
@@ -243,6 +243,7 @@
 #include 
 #include 
 #include 
+#include 
 
 struct tty_struct;
 struct tty_driver;
@@ -285,6 +286,8 @@ struct tty_operations {
int (*set_termiox)(struct tty_struct *tty, struct termiox *tnew);
int (*get_icount)(struct tty_struct *tty,
struct serial_icounter_struct *icount);
+   unsigned int (*poll)(struct tty_struct *tty, struct file *file,
+   poll_table *wait);
 #ifdef CONFIG_CONSOLE_POLL
int (*poll_init)(struct tty_driver *driver, int line, char *options);
int (*poll_get_char)(struct tty_driver *driver, int line);
-- 
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

Re: [PATCH 03/11] Creation of "usb_device_auth" LSM hook

[Krzysztof Opasiak]

Hi,

On 06/12/2017 06:56 PM, Salvatore Mesoraca wrote:

Creation of a new LSM hook that can be used to authorize or deauthorize
new USB devices via the usb authorization interface.
The same hook can also prevent the authorization of a USB device via
"/sys/bus/usb/devices/DEVICE/authorized".
Using this hook an LSM could provide an higher level of granularity
than the current authorization interface.



Could you please explain me why we need LSM for this?

There are tools like usbguard[1] and as far as I can tell it looks like 
they can do everything for you...

Without kernel modification...
without matching and storing rules inside kernel..
just pure userspace which uses device/interface authorization

Footnote:
1 - https://dkopecek.github.io/usbguard/

Best regards,
--
Krzysztof Opasiak
Samsung R&D Institute Poland
Samsung Electronics
--
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 6/8] usb: gadget: f_acm: add an ioctl to get the current line coding

[Tal Shorer]

On Mon, Jun 12, 2017 at 8:26 PM, Tal Shorer  wrote:
> The user can issue USB_F_GET_LINE_CODING to get the current line coding
> as set by the host (or the default if unset yet).
>
> Signed-off-by: Tal Shorer 
> ---

> @@ -764,10 +783,10 @@ static struct usb_function *acm_alloc_func(struct 
> usb_function_instance *fi)
> acm->port.func.free_func = acm_free_func;
>
> /* initialize port_line_coding with something that makes sense */
> -   coding.dwDTERate = cpu_to_le32(9600);
> -   coding.bCharFormat = USB_CDC_1_STOP_BITS;
> -   coding.bParityType = USB_CDC_NO_PARITY;
> -   coding.bDataBits = 8;
> +   acm->port_line_coding.dwDTERate = cpu_to_le32(9600);
> +   acm->port_line_coding.bCharFormat = USB_CDC_1_STOP_BITS;
> +   acm->port_line_coding.bParityType = USB_CDC_NO_PARITY;
> +   acm->port_line_coding.bDataBits = 8;
>
> return &acm->port.func;
>  }
This hunk was messed up somehow and will not apply. I can resend a v2 if 
necessary, but the correct patch is as follows:

From: Tal Shorer 
Subject: [PATCH 6/8] usb: gadget: f_acm: add an ioctl to get the current line
 coding

The user can issue USB_F_GET_LINE_CODING to get the current line coding
as set by the host (or the default if unset yet).

Signed-off-by: Tal Shorer 
---
 Documentation/ioctl/ioctl-number.txt |  1 +
 drivers/usb/gadget/function/f_acm.c  | 27 +++
 include/uapi/linux/usb/f_acm.h   | 12 
 3 files changed, 36 insertions(+), 4 deletions(-)
 create mode 100644 include/uapi/linux/usb/f_acm.h

diff --git a/Documentation/ioctl/ioctl-number.txt 
b/Documentation/ioctl/ioctl-number.txt
index 1e9fcb4..3d70680 100644
--- a/Documentation/ioctl/ioctl-number.txt
+++ b/Documentation/ioctl/ioctl-number.txt
@@ -329,6 +329,7 @@ Code  Seq#(hex) Include FileComments
 0xCA   80-8F   uapi/scsi/cxlflash_ioctl.h
 0xCB   00-1F   CBM serial IEC bus  in development:


+0xCD   10-1F   linux/usb/f_acm.h
 0xCD   01  linux/reiserfs_fs.h
 0xCF   02  fs/cifs/ioctl.c
 0xDB   00-0F   drivers/char/mwave/mwavepub.h
diff --git a/drivers/usb/gadget/function/f_acm.c 
b/drivers/usb/gadget/function/f_acm.c
index b7a1466..5feea7c 100644
--- a/drivers/usb/gadget/function/f_acm.c
+++ b/drivers/usb/gadget/function/f_acm.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 

 #include "u_serial.h"

@@ -611,6 +612,23 @@ static int acm_send_break(struct gserial *port, int 
duration)
return acm_notify_serial_state(acm);
 }

+static int acm_ioctl(struct gserial *port, unsigned int cmd, unsigned long arg)
+{
+   struct f_acm*acm = port_to_acm(port);
+   int ret = -ENOIOCTLCMD;
+
+   switch (cmd) {
+   case USB_F_ACM_GET_LINE_CODING:
+   if (copy_to_user((__user void *)arg, &acm->port_line_coding,
+   sizeof(acm->port_line_coding)))
+   ret = -EFAULT;
+   else
+   ret = 0;
+   break;
+   }
+   return ret;
+}
+
 /*-*/

 /* ACM function driver setup/binding */
@@ -749,6 +767,7 @@ static struct usb_function *acm_alloc_func(struct 
usb_function_instance *fi)
acm->port.connect = acm_connect;
acm->port.disconnect = acm_disconnect;
acm->port.send_break = acm_send_break;
+   acm->port.ioctl = acm_ioctl;

acm->port.func.name = "acm";
acm->port.func.strings = acm_strings;
@@ -763,6 +763,12 @@ static struct usb_function *acm_alloc_func(struct 
usb_function_instance *fi)
acm->port.func.unbind = acm_unbind;
acm->port.func.free_func = acm_free_func;

+   /* initialize port_line_coding with something that makes sense */
+   coding.dwDTERate = cpu_to_le32(9600);
+   coding.bCharFormat = USB_CDC_1_STOP_BITS;
+   coding.bParityType = USB_CDC_NO_PARITY;
+   coding.bDataBits = 8;
+
return &acm->port.func;
 }

diff --git a/include/uapi/linux/usb/f_acm.h b/include/uapi/linux/usb/f_acm.h
new file mode 100644
index 000..51f96f0
--- /dev/null
+++ b/include/uapi/linux/usb/f_acm.h
@@ -0,0 +1,12 @@
+/* f_acm.h -- Header file for USB CDC-ACM gadget function */
+
+#ifndef __UAPI_LINUX_USB_F_ACM_H
+#define __UAPI_LINUX_USB_F_ACM_H
+
+#include 
+#include 
+
+/* The 0xCD code is also used by reiserfs. we use 0x10-0x1F range */
+#define USB_F_ACM_GET_LINE_CODING _IOR(0xCD, 0x10, struct usb_cdc_line_coding)
+
+#endif /* __UAPI_LINUX_USB_F_ACM_H */
--
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

Re: [PATCH v2] net: phy: Make phy_ethtool_ksettings_get return void

[kbuild test robot]

Hi Yuval,

[auto build test ERROR on net-next/master]
[also build test ERROR on next-20170609]
[cannot apply to v4.12-rc5]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Yuval-Shaia/net-phy-Make-phy_ethtool_ksettings_get-return-void/20170613-005407
config: ia64-allmodconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 6.2.0
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=ia64 

All errors (new ones prefixed by >>):

   drivers/net/ethernet/apm/xgene/xgene_enet_ethtool.c: In function 
'xgene_get_link_ksettings':
>> drivers/net/ethernet/apm/xgene/xgene_enet_ethtool.c:134:10: error: void 
>> value not ignored as it ought to be
  return phy_ethtool_ksettings_get(phydev, cmd);
 ^~
   drivers/net/ethernet/apm/xgene/xgene_enet_ethtool.c:140:11: error: void 
value not ignored as it ought to be
   return phy_ethtool_ksettings_get(phydev, cmd);
  ^~
--
   drivers/net/ethernet/apm/xgene-v2/ethtool.c: In function 
'xge_get_link_ksettings':
>> drivers/net/ethernet/apm/xgene-v2/ethtool.c:160:9: error: void value not 
>> ignored as it ought to be
 return phy_ethtool_ksettings_get(phydev, cmd);
^~
   drivers/net/ethernet/apm/xgene-v2/ethtool.c:161:1: warning: control reaches 
end of non-void function [-Wreturn-type]
}
^

vim +134 drivers/net/ethernet/apm/xgene/xgene_enet_ethtool.c

e6ad7673 Iyappan Subramanian 2014-08-07  118strcpy(info->version, 
XGENE_DRV_VERSION);
e6ad7673 Iyappan Subramanian 2014-08-07  119snprintf(info->fw_version, 
ETHTOOL_FWVERS_LEN, "N/A");
e6ad7673 Iyappan Subramanian 2014-08-07  120sprintf(info->bus_info, "%s", 
pdev->name);
e6ad7673 Iyappan Subramanian 2014-08-07  121  }
e6ad7673 Iyappan Subramanian 2014-08-07  122  
36a19b29 Philippe Reynes 2016-09-11  123  static int 
xgene_get_link_ksettings(struct net_device *ndev,
36a19b29 Philippe Reynes 2016-09-11  124
struct ethtool_link_ksettings *cmd)
e6ad7673 Iyappan Subramanian 2014-08-07  125  {
e6ad7673 Iyappan Subramanian 2014-08-07  126struct xgene_enet_pdata *pdata 
= netdev_priv(ndev);
971d3a44 Philippe Reynes 2016-09-11  127struct phy_device *phydev = 
ndev->phydev;
36a19b29 Philippe Reynes 2016-09-11  128u32 supported;
e6ad7673 Iyappan Subramanian 2014-08-07  129  
326dde3e Iyappan Subramanian 2017-05-18  130if 
(phy_interface_mode_is_rgmii(pdata->phy_mode)) {
e6ad7673 Iyappan Subramanian 2014-08-07  131if (phydev == NULL)
e6ad7673 Iyappan Subramanian 2014-08-07  132return -ENODEV;
e6ad7673 Iyappan Subramanian 2014-08-07  133  
36a19b29 Philippe Reynes 2016-09-11 @134return 
phy_ethtool_ksettings_get(phydev, cmd);
5e6a024b Iyappan Subramanian 2014-10-13  135} else if (pdata->phy_mode == 
PHY_INTERFACE_MODE_SGMII) {
52d1fd99 Iyappan Subramanian 2016-07-25  136if (pdata->mdio_driver) 
{
52d1fd99 Iyappan Subramanian 2016-07-25  137if (!phydev)
52d1fd99 Iyappan Subramanian 2016-07-25  138return 
-ENODEV;
52d1fd99 Iyappan Subramanian 2016-07-25  139  
36a19b29 Philippe Reynes 2016-09-11  140return 
phy_ethtool_ksettings_get(phydev, cmd);
52d1fd99 Iyappan Subramanian 2016-07-25  141}
52d1fd99 Iyappan Subramanian 2016-07-25  142  

:: The code at line 134 was first introduced by commit
:: 36a19b299536746f5c01d7716dac962f831e4d38 net: ethernet: apm: xgene: use 
new api ethtool_{get|set}_link_ksettings

:: TO: Philippe Reynes 
:: CC: David S. Miller 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH 6/8] usb: gadget: f_acm: add an ioctl to get the current line coding

[Tal Shorer]

On Mon, Jun 12, 2017 at 9:02 PM, Tal Shorer  wrote:
> On Mon, Jun 12, 2017 at 8:26 PM, Tal Shorer  wrote:
>> The user can issue USB_F_GET_LINE_CODING to get the current line coding
>> as set by the host (or the default if unset yet).
>>
>> Signed-off-by: Tal Shorer 
>> ---
>
>> @@ -764,10 +783,10 @@ static struct usb_function *acm_alloc_func(struct 
>> usb_function_instance *fi)
>> acm->port.func.free_func = acm_free_func;
>>
>> /* initialize port_line_coding with something that makes sense */
>> -   coding.dwDTERate = cpu_to_le32(9600);
>> -   coding.bCharFormat = USB_CDC_1_STOP_BITS;
>> -   coding.bParityType = USB_CDC_NO_PARITY;
>> -   coding.bDataBits = 8;
>> +   acm->port_line_coding.dwDTERate = cpu_to_le32(9600);
>> +   acm->port_line_coding.bCharFormat = USB_CDC_1_STOP_BITS;
>> +   acm->port_line_coding.bParityType = USB_CDC_NO_PARITY;
>> +   acm->port_line_coding.bDataBits = 8;
>>
>> return &acm->port.func;
>>  }
> This hunk was messed up somehow and will not apply. I can resend a v2 if 
> necessary, but the correct patch is as follows:
Actually, it shouldn't even be in this patch. I somehow meshed 5 and 6 together.
The correct PATCH 6/8 is as follows:

>From d7d56ceb8020f10623a04b4634f93e4cc678454d Mon Sep 17 00:00:00 2001
From: Tal Shorer 
Date: Mon, 12 Jun 2017 19:40:56 +0300
Subject: [PATCH 6/8] usb: gadget: f_acm: add an ioctl to get the current line
 coding

The user can issue USB_F_GET_LINE_CODING to get the current line coding
as set by the host (or the default if unset yet).

Signed-off-by: Tal Shorer 
---
 Documentation/ioctl/ioctl-number.txt |  1 +
 drivers/usb/gadget/function/f_acm.c  | 27 +++
 include/uapi/linux/usb/f_acm.h   | 12 
 3 files changed, 36 insertions(+), 4 deletions(-)
 create mode 100644 include/uapi/linux/usb/f_acm.h

diff --git a/Documentation/ioctl/ioctl-number.txt 
b/Documentation/ioctl/ioctl-number.txt
index 1e9fcb4..3d70680 100644
--- a/Documentation/ioctl/ioctl-number.txt
+++ b/Documentation/ioctl/ioctl-number.txt
@@ -329,6 +329,7 @@ Code  Seq#(hex) Include FileComments
 0xCA   80-8F   uapi/scsi/cxlflash_ioctl.h
 0xCB   00-1F   CBM serial IEC bus  in development:


+0xCD   10-1F   linux/usb/f_acm.h
 0xCD   01  linux/reiserfs_fs.h
 0xCF   02  fs/cifs/ioctl.c
 0xDB   00-0F   drivers/char/mwave/mwavepub.h
diff --git a/drivers/usb/gadget/function/f_acm.c 
b/drivers/usb/gadget/function/f_acm.c
index b7a1466..5feea7c 100644
--- a/drivers/usb/gadget/function/f_acm.c
+++ b/drivers/usb/gadget/function/f_acm.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 

 #include "u_serial.h"

@@ -611,6 +612,23 @@ static int acm_send_break(struct gserial *port, int 
duration)
return acm_notify_serial_state(acm);
 }

+static int acm_ioctl(struct gserial *port, unsigned int cmd, unsigned long arg)
+{
+   struct f_acm*acm = port_to_acm(port);
+   int ret = -ENOIOCTLCMD;
+
+   switch (cmd) {
+   case USB_F_ACM_GET_LINE_CODING:
+   if (copy_to_user((__user void *)arg, &acm->port_line_coding,
+   sizeof(acm->port_line_coding)))
+   ret = -EFAULT;
+   else
+   ret = 0;
+   break;
+   }
+   return ret;
+}
+
 /*-*/

 /* ACM function driver setup/binding */
@@ -749,6 +767,7 @@ static struct usb_function *acm_alloc_func(struct 
usb_function_instance *fi)
acm->port.connect = acm_connect;
acm->port.disconnect = acm_disconnect;
acm->port.send_break = acm_send_break;
+   acm->port.ioctl = acm_ioctl;

acm->port.func.name = "acm";
acm->port.func.strings = acm_strings;
diff --git a/include/uapi/linux/usb/f_acm.h b/include/uapi/linux/usb/f_acm.h
new file mode 100644
index 000..51f96f0
--- /dev/null
+++ b/include/uapi/linux/usb/f_acm.h
@@ -0,0 +1,12 @@
+/* f_acm.h -- Header file for USB CDC-ACM gadget function */
+
+#ifndef __UAPI_LINUX_USB_F_ACM_H
+#define __UAPI_LINUX_USB_F_ACM_H
+
+#include 
+#include 
+
+/* The 0xCD code is also used by reiserfs. we use 0x10-0x1F range */
+#define USB_F_ACM_GET_LINE_CODING _IOR(0xCD, 0x10, struct usb_cdc_line_coding)
+
+#endif /* __UAPI_LINUX_USB_F_ACM_H */
--
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

[PATCH v3] USB: qcserial: expose methods for modem control

[Magnus Lynch]

The qcserial driver fails to expose the .tiocmget and .tiocmset methods
available from usb_wwan. These methods are required by ioctl commands
dealing with the modem control signals DTR, RTS, etc.

With these methods not set ioctl calls intended to control the DTR state
will fail. For example, pppd drops and raises DTR in preparation to
dialing the modem, which handles the case of the modem already being
connected by making it hang up and return to command mode. DTR control
being unavailable will lead to a protracted failure to connect as the
modem will be stuck in a state not responsive to command.

I have tested that with this patch the described case is handled
successfully. There is an analogous method for .ioctl available from
usb_wwan (as used in option.c) but I conservatively omitted that for
lack of familiarity.

Signed-off-by: Magnus Lynch 

---
Apologies for bad formatting. Further attempting to resolve that.

diff --git a/drivers/usb/serial/qcserial.c b/drivers/usb/serial/qcserial.c
index fd509ed6c..4ac137d 100644
--- a/drivers/usb/serial/qcserial.c
+++ b/drivers/usb/serial/qcserial.c
@@ -454,6 +454,8 @@ static void qc_release(struct usb_serial *serial)
.write   = usb_wwan_write,
.write_room  = usb_wwan_write_room,
.chars_in_buffer = usb_wwan_chars_in_buffer,
+   .tiocmget= usb_wwan_tiocmget,
+   .tiocmset= usb_wwan_tiocmset,
.attach  = qc_attach,
.release = qc_release,
.port_probe  = usb_wwan_port_probe,


--
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: dwc3: gadget: Fix early exit in set/clear ep halt

[Thinh Nguyen]

Hi Felipe,

On 6/6/2017 11:52 AM, Thinh Nguyen wrote:
> On 6/4/2017 11:08 PM, Felipe Balbi wrote:
>> Paul Zimmerman  writes:
>>> Forgot to CC linux-usb, doing that now
>>>
>>> On Fri, 2 Jun 2017 16:27:56 -0700, Paul Zimmerman  
>>> wrote:
>>>
 Felipe Balbi  writes:
> Thinh Nguyen  writes:
>> this could be, I don't remember if I checked this or not :-)
>>
>> Really, the best way here, IMHO, would be to re-verify what's going 
>> on
>> with macOS and revert my orignal patch since it's, rather clearly,
>> wrong.
>>
>
> Sure. Are you going to make a revert patch or I am?

 Well, after we really know what's going on with macOS and have a better
 fix, then who makes the revert is less important as long as problems 
 get
 sorted out :-) Either way is fine for me.

>>>
>>> Do you have any update on this issue?
>>>
>>
>> The patch ffb80fc672c3 ("usb: dwc3: gadget: skip Set/Clear Halt when
>> invalid") still causes a regression for us. As there hasn't any update
>> for the macOS issue, can I submit a revert patch for this?
>
> I just came back from vacations ;-) I'll get back to this. Reverting
> that commit won't do any good as we'd be exchanging one regression for
> another. We really need to understand what's going on.

 Hi Felipe,

 I think we worked around this same issue in the Synopsys vendor driver
 after a customer reported a problem with CLEAR_FEATURE(ENDPOINT_HALT).
 I no longer have access to either the databook or the codebase, so I
 can't be sure about what the workaround was, but if either John or Thinh
 can have a look at the Clear Stall code in the vendor driver they should
 be able to figure it out.
>>
>> Thanks a lot Paul :-) Good to see you still have a look here every once
>> in a while :-)
>>
>> John, Thinh could either of you check what Paul mentions here?
>>
>> cheers
>>
> 
> Can you provide more detail on the issue you see on MAC OS? and how to
> reproduce the issue?
> 

This issue has been a regression for us for a few months now, do you 
have any update on this?

Thanks,
Thinh

--
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 03/11] Creation of "usb_device_auth" LSM hook

[Greg Kroah-Hartman]

On Mon, Jun 12, 2017 at 06:56:52PM +0200, Salvatore Mesoraca wrote:
> Creation of a new LSM hook that can be used to authorize or deauthorize
> new USB devices via the usb authorization interface.
> The same hook can also prevent the authorization of a USB device via
> "/sys/bus/usb/devices/DEVICE/authorized".
> Using this hook an LSM could provide an higher level of granularity
> than the current authorization interface.
> 
> Signed-off-by: Salvatore Mesoraca 
> Cc: linux-usb@vger.kernel.org
> Cc: Greg Kroah-Hartman 

No, like Krzysztof said, you can already do this today, just fine, from
userspace.  I think that support has been there for over a decade now,
why are you not taking advantage of this already?

No need to add extra stuff to the kernel at all to do this, sorry you
implemented all of this for no reason :(

greg k-h
--
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

Gadget driver ->disconnect callback during unbinding

[Alan Stern]

Felipe:

A UDC driver will invoke the gadget driver's ->disconnect callback
whenever the D+ pullup is turned off.  During gadget driver unbinding,
this happens automatically when usb_gadget_remove_driver() calls
usb_gadget_disconnect().

But immediately thereafter, usb_gadget_remove_driver() calls the gadget 
driver's ->disconnect callback directly!  Do we have any reason for 
doing this?  I don't see point to it.  Should that call be removed?

Of possible relevance: commit 0abd06969825 ("usb: gadget: udc-core: 
call ->disconnect() when soft disconnecting").

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: usb/gadget: potential deadlock in gadgetfs_suspend

[Alan Stern]

On Mon, 12 Jun 2017, Andrey Konovalov wrote:

> Aha, got KASAN report:
> 
> ==
> BUG: KASAN: use-after-free in __lock_acquire+0x3069/0x3690
> kernel/locking/lockdep.c:3246
> Read of size 8 at addr 88003a2bdaf8 by task kworker/3:1/903
> 
> CPU: 3 PID: 903 Comm: kworker/3:1 Not tainted 4.12.0-rc4+ #35
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> Workqueue: usb_hub_wq hub_event
> Call Trace:
>  __dump_stack lib/dump_stack.c:16 [inline]
>  dump_stack+0x292/0x395 lib/dump_stack.c:52
>  print_address_description+0x78/0x280 mm/kasan/report.c:252
>  kasan_report_error mm/kasan/report.c:351 [inline]
>  kasan_report+0x230/0x340 mm/kasan/report.c:408
>  __asan_report_load8_noabort+0x19/0x20 mm/kasan/report.c:429
>  __lock_acquire+0x3069/0x3690 kernel/locking/lockdep.c:3246
>  lock_acquire+0x22d/0x560 kernel/locking/lockdep.c:3855
>  __raw_spin_lock include/linux/spinlock_api_smp.h:142 [inline]
>  _raw_spin_lock+0x2f/0x40 kernel/locking/spinlock.c:151
>  spin_lock include/linux/spinlock.h:299 [inline]
>  gadgetfs_suspend+0x89/0x130 drivers/usb/gadget/legacy/inode.c:1682
>  set_link_state+0x88e/0xae0 drivers/usb/gadget/udc/dummy_hcd.c:455
>  dummy_hub_control+0xd7e/0x1fb0 drivers/usb/gadget/udc/dummy_hcd.c:2074
>  rh_call_control drivers/usb/core/hcd.c:689 [inline]
>  rh_urb_enqueue drivers/usb/core/hcd.c:846 [inline]
>  usb_hcd_submit_urb+0x92f/0x20b0 drivers/usb/core/hcd.c:1650
>  usb_submit_urb+0x8b2/0x12c0 drivers/usb/core/urb.c:542
>  usb_start_wait_urb+0x148/0x5b0 drivers/usb/core/message.c:56
>  usb_internal_control_msg drivers/usb/core/message.c:100 [inline]
>  usb_control_msg+0x341/0x4d0 drivers/usb/core/message.c:151
>  usb_clear_port_feature+0x74/0xa0 drivers/usb/core/hub.c:412
>  hub_port_disable+0x123/0x510 drivers/usb/core/hub.c:4177
>  hub_port_init+0x1ed/0x2940 drivers/usb/core/hub.c:4648
>  hub_port_connect drivers/usb/core/hub.c:4826 [inline]
>  hub_port_connect_change drivers/usb/core/hub.c:4999 [inline]
>  port_event drivers/usb/core/hub.c:5105 [inline]
>  hub_event+0x1ae1/0x3d40 drivers/usb/core/hub.c:5185
>  process_one_work+0xc08/0x1bd0 kernel/workqueue.c:2097
>  process_scheduled_works kernel/workqueue.c:2157 [inline]
>  worker_thread+0xb2b/0x1860 kernel/workqueue.c:2233
>  kthread+0x363/0x440 kernel/kthread.c:231
>  ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:424
> 
> Allocated by task 9958:
>  save_stack_trace+0x1b/0x20 arch/x86/kernel/stacktrace.c:59
>  save_stack+0x43/0xd0 mm/kasan/kasan.c:513
>  set_track mm/kasan/kasan.c:525 [inline]
>  kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:617
>  kmem_cache_alloc_trace+0x87/0x280 mm/slub.c:2745
>  kmalloc include/linux/slab.h:492 [inline]
>  kzalloc include/linux/slab.h:665 [inline]
>  dev_new drivers/usb/gadget/legacy/inode.c:170 [inline]
>  gadgetfs_fill_super+0x24f/0x540 drivers/usb/gadget/legacy/inode.c:1993
>  mount_single+0xf6/0x160 fs/super.c:1192
>  gadgetfs_mount+0x31/0x40 drivers/usb/gadget/legacy/inode.c:2019
>  mount_fs+0x9c/0x2d0 fs/super.c:1223
>  vfs_kern_mount.part.25+0xcb/0x490 fs/namespace.c:976
>  vfs_kern_mount fs/namespace.c:2509 [inline]
>  do_new_mount fs/namespace.c:2512 [inline]
>  do_mount+0x41b/0x2d90 fs/namespace.c:2834
>  SYSC_mount fs/namespace.c:3050 [inline]
>  SyS_mount+0xb0/0x120 fs/namespace.c:3027
>  entry_SYSCALL_64_fastpath+0x1f/0xbe
> 
> Freed by task 9960:
>  save_stack_trace+0x1b/0x20 arch/x86/kernel/stacktrace.c:59
>  save_stack+0x43/0xd0 mm/kasan/kasan.c:513
>  set_track mm/kasan/kasan.c:525 [inline]
>  kasan_slab_free+0x72/0xc0 mm/kasan/kasan.c:590
>  slab_free_hook mm/slub.c:1357 [inline]
>  slab_free_freelist_hook mm/slub.c:1379 [inline]
>  slab_free mm/slub.c:2961 [inline]
>  kfree+0xed/0x2b0 mm/slub.c:3882
>  put_dev+0x124/0x160 drivers/usb/gadget/legacy/inode.c:163
>  gadgetfs_kill_sb+0x33/0x60 drivers/usb/gadget/legacy/inode.c:2027
>  deactivate_locked_super+0x8d/0xd0 fs/super.c:309
>  deactivate_super+0x21e/0x310 fs/super.c:340
>  cleanup_mnt+0xb7/0x150 fs/namespace.c:1112
>  __cleanup_mnt+0x1b/0x20 fs/namespace.c:1119
>  task_work_run+0x1a0/0x280 kernel/task_work.c:116
>  exit_task_work include/linux/task_work.h:21 [inline]
>  do_exit+0x18a8/0x2820 kernel/exit.c:878
>  do_group_exit+0x14e/0x420 kernel/exit.c:982
>  get_signal+0x784/0x1780 kernel/signal.c:2318
>  do_signal+0xd7/0x2130 arch/x86/kernel/signal.c:808
>  exit_to_usermode_loop+0x1ac/0x240 arch/x86/entry/common.c:157
>  prepare_exit_to_usermode arch/x86/entry/common.c:194 [inline]
>  syscall_return_slowpath+0x3ba/0x410 arch/x86/entry/common.c:263
>  entry_SYSCALL_64_fastpath+0xbc/0xbe
> 
> The buggy address belongs to the object at 88003a2bdae0
>  which belongs to the cache kmalloc-1024 of size 1024
> The buggy address is located 24 bytes inside of
>  1024-byte region [88003a2bdae0, 88003a2bdee0)
> The buggy address belongs to the page:
> page:eae8ae00 count:1 mapcount:0 mapping:  (null)
> index:0x0 compoun

[PATCH v2 1/8] ACPI / PM: Run wakeup notify handlers synchronously

[Rafael J. Wysocki]

From: Rafael J. Wysocki 

The work functions provided by the users of acpi_add_pm_notifier()
should be run synchronously before re-enabling the wakeup GPE in
case they are used to clear the status and/or disable the wakeup
signaling at the source.  Otherwise, which is the case currently in
the PCI bus type code, the same wakeup event may be signaled for
multiple times while the execution of the work function in response
to it has already been queued up.

Fortunately, acpi_add_pm_notifier() is only used by PCI and by
ACPI device PM code internally, so the change is relatively
straightforward to make.

Signed-off-by: Rafael J. Wysocki 
---
 drivers/acpi/device_pm.c |   27 +++
 drivers/pci/pci-acpi.c   |   17 +++--
 include/acpi/acpi_bus.h  |4 ++--
 3 files changed, 20 insertions(+), 28 deletions(-)

Index: linux-pm/drivers/acpi/device_pm.c
===
--- linux-pm.orig/drivers/acpi/device_pm.c
+++ linux-pm/drivers/acpi/device_pm.c
@@ -400,8 +400,8 @@ static void acpi_pm_notify_handler(acpi_
 
if (adev->wakeup.flags.notifier_present) {
__pm_wakeup_event(adev->wakeup.ws, 0);
-   if (adev->wakeup.context.work.func)
-   queue_pm_work(&adev->wakeup.context.work);
+   if (adev->wakeup.context.func)
+   adev->wakeup.context.func(&adev->wakeup.context);
}
 
mutex_unlock(&acpi_pm_notifier_lock);
@@ -413,7 +413,7 @@ static void acpi_pm_notify_handler(acpi_
  * acpi_add_pm_notifier - Register PM notify handler for given ACPI device.
  * @adev: ACPI device to add the notify handler for.
  * @dev: Device to generate a wakeup event for while handling the notification.
- * @work_func: Work function to execute when handling the notification.
+ * @func: Work function to execute when handling the notification.
  *
  * NOTE: @adev need not be a run-wake or wakeup device to be a valid source of
  * PM wakeup events.  For example, wakeup events may be generated for bridges
@@ -421,11 +421,11 @@ static void acpi_pm_notify_handler(acpi_
  * bridge itself doesn't have a wakeup GPE associated with it.
  */
 acpi_status acpi_add_pm_notifier(struct acpi_device *adev, struct device *dev,
-void (*work_func)(struct work_struct *work))
+   void (*func)(struct acpi_device_wakeup_context 
*context))
 {
acpi_status status = AE_ALREADY_EXISTS;
 
-   if (!dev && !work_func)
+   if (!dev && !func)
return AE_BAD_PARAMETER;
 
mutex_lock(&acpi_pm_notifier_lock);
@@ -435,8 +435,7 @@ acpi_status acpi_add_pm_notifier(struct
 
adev->wakeup.ws = wakeup_source_register(dev_name(&adev->dev));
adev->wakeup.context.dev = dev;
-   if (work_func)
-   INIT_WORK(&adev->wakeup.context.work, work_func);
+   adev->wakeup.context.func = func;
 
status = acpi_install_notify_handler(adev->handle, ACPI_SYSTEM_NOTIFY,
 acpi_pm_notify_handler, NULL);
@@ -469,10 +468,7 @@ acpi_status acpi_remove_pm_notifier(stru
if (ACPI_FAILURE(status))
goto out;
 
-   if (adev->wakeup.context.work.func) {
-   cancel_work_sync(&adev->wakeup.context.work);
-   adev->wakeup.context.work.func = NULL;
-   }
+   adev->wakeup.context.func = NULL;
adev->wakeup.context.dev = NULL;
wakeup_source_unregister(adev->wakeup.ws);
 
@@ -658,16 +654,15 @@ EXPORT_SYMBOL(acpi_pm_device_sleep_state
 
 /**
  * acpi_pm_notify_work_func - ACPI devices wakeup notification work function.
- * @work: Work item to handle.
+ * @context: Device wakeup context.
  */
-static void acpi_pm_notify_work_func(struct work_struct *work)
+static void acpi_pm_notify_work_func(struct acpi_device_wakeup_context 
*context)
 {
-   struct device *dev;
+   struct device *dev = context->dev;
 
-   dev = container_of(work, struct acpi_device_wakeup_context, work)->dev;
if (dev) {
pm_wakeup_event(dev, 0);
-   pm_runtime_resume(dev);
+   pm_request_resume(dev);
}
 }
 
Index: linux-pm/include/acpi/acpi_bus.h
===
--- linux-pm.orig/include/acpi/acpi_bus.h
+++ linux-pm/include/acpi/acpi_bus.h
@@ -319,7 +319,7 @@ struct acpi_device_wakeup_flags {
 };
 
 struct acpi_device_wakeup_context {
-   struct work_struct work;
+   void (*func)(struct acpi_device_wakeup_context *context);
struct device *dev;
 };
 
@@ -599,7 +599,7 @@ static inline bool acpi_device_always_pr
 
 #ifdef CONFIG_PM
 acpi_status acpi_add_pm_notifier(struct acpi_device *adev, struct device *dev,
-void (*work_func)(struct work_struct *work));
+   void (*func)(struct acpi_device_wakeup_context 
*context));
 acpi_status acpi_remove_pm

[PATCH v2 5/8] PM / sleep: Print timing information if debug is enabled

[Rafael J. Wysocki]

From: Rafael J. Wysocki 

Avoid printing the device suspend/resume timing information if
CONFIG_PM_DEBUG is not set to reduce the log noise level.

Signed-off-by: Rafael J. Wysocki 
---
 drivers/base/power/main.c |4 
 1 file changed, 4 insertions(+)

Index: linux-pm/drivers/base/power/main.c
===
--- linux-pm.orig/drivers/base/power/main.c
+++ linux-pm/drivers/base/power/main.c
@@ -417,6 +417,7 @@ static void pm_dev_err(struct device *de
dev_name(dev), pm_verb(state.event), info, error);
 }
 
+#ifdef CONFIG_PM_DEBUG
 static void dpm_show_time(ktime_t starttime, pm_message_t state, char *info)
 {
ktime_t calltime;
@@ -433,6 +434,9 @@ static void dpm_show_time(ktime_t startt
info ?: "", info ? " " : "", pm_verb(state.event),
usecs / USEC_PER_MSEC, usecs % USEC_PER_MSEC);
 }
+#else
+static inline void dpm_show_time(ktime_t starttime, pm_message_t state, char 
*info) {}
+#endif /* CONFIG_PM_DEBUG */
 
 static int dpm_run_callback(pm_callback_t cb, struct device *dev,
pm_message_t state, char *info)

--
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 v2 0/8] ACPI / PM: Suspend-to-idle rework to deal with spurious ACPI wakeups

[Rafael J. Wysocki]

Hi All,

On Thursday, June 08, 2017 02:00:40 AM Rafael J. Wysocki wrote:
> Hi All,
> 
> This series is a replacement for commit eed4d47efe95 (ACPI / sleep: Ignore
> spurious SCI wakeups from suspend-to-idle) which is still there in 4.12-rc4 
> but
> will be reverted shortly, because it triggered issues on quite a few systems.
> 
> The last patch in the series is a counterpart of the above commit with a few
> modifications, mostly to avoid affecting suspend-to-RAM and to reorder 
> messages
> printed to kernel logs to make them somewhat less confusing.

Here's a v2 which is very similar to the previous one, except for 3 things:
- There are few build fixes in the last patch.
- The patch from Hans mentioned previously is included now (as [7/8]).
- There is an additional PCI change related to config space saving/restoring
  and PME.

If anyone has any objections or concerns regarding this, please speak up now,
as I'm going to put it into linux-next shortly to allow it to receive some more
testing than commit eed4d47efe95 had had before it went it.

Thanks,
Rafael

--
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 v2 7/8] platform/x86: Add driver for ACPI INT0002 Virtual GPIO device

[Rafael J. Wysocki]

From: Hans de Goede 

Some peripherals on Bay Trail and Cherry Trail platforms signal a
Power Management Event (PME) to the Power Management Controller (PMC)
to wakeup the system. When this happens software needs to explicitly
clear the PME bus 0 status bit in the GPE0a_STS register to avoid an
IRQ storm on IRQ 9.

This is modelled in ACPI through the INT0002 ACPI device, which is
called a "Virtual GPIO controller" in ACPI because it defines the
event handler to call when the PME triggers through _AEI and _L02
methods as would be done for a real GPIO interrupt in ACPI.

This commit adds a driver which registers the Virtual GPIOs expected
by the DSDT on these devices, letting gpiolib-acpi claim the
virtual GPIO and install a GPIO-interrupt handler which call the _L02
handler as it would for a real GPIO controller.

Signed-off-by: Hans de Goede 
Reviewed-by: Andy Shevchenko 
Reviewed-by: Linus Walleij 
Signed-off-by: Rafael J. Wysocki 
---
 drivers/platform/x86/Kconfig   |  19 +++
 drivers/platform/x86/Makefile  |   1 +
 drivers/platform/x86/intel_int0002_vgpio.c | 219 +
 3 files changed, 239 insertions(+)
 create mode 100644 drivers/platform/x86/intel_int0002_vgpio.c

diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 8489020ecf44..a3ccc3c795a5 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -794,6 +794,25 @@ config INTEL_CHT_INT33FE
  This driver instantiates i2c-clients for these, so that standard
  i2c drivers for these chips can bind to the them.
 
+config INTEL_INT0002_VGPIO
+   tristate "Intel ACPI INT0002 Virtual GPIO driver"
+   depends on GPIOLIB && ACPI
+   select GPIOLIB_IRQCHIP
+   ---help---
+ Some peripherals on Bay Trail and Cherry Trail platforms signal a
+ Power Management Event (PME) to the Power Management Controller (PMC)
+ to wakeup the system. When this happens software needs to explicitly
+ clear the PME bus 0 status bit in the GPE0a_STS register to avoid an
+ IRQ storm on IRQ 9.
+
+ This is modelled in ACPI through the INT0002 ACPI device, which is
+ called a "Virtual GPIO controller" in ACPI because it defines the
+ event handler to call when the PME triggers through _AEI and _L02
+ methods as would be done for a real GPIO interrupt in ACPI.
+
+ To compile this driver as a module, choose M here: the module will
+ be called intel_int0002_vgpio.
+
 config INTEL_HID_EVENT
tristate "INTEL HID Event"
depends on ACPI
diff --git a/drivers/platform/x86/Makefile b/drivers/platform/x86/Makefile
index 182a3ed6605a..ab22ce77fb66 100644
--- a/drivers/platform/x86/Makefile
+++ b/drivers/platform/x86/Makefile
@@ -46,6 +46,7 @@ obj-$(CONFIG_TOSHIBA_BT_RFKILL)   += toshiba_bluetooth.o
 obj-$(CONFIG_TOSHIBA_HAPS) += toshiba_haps.o
 obj-$(CONFIG_TOSHIBA_WMI)  += toshiba-wmi.o
 obj-$(CONFIG_INTEL_CHT_INT33FE)+= intel_cht_int33fe.o
+obj-$(CONFIG_INTEL_INT0002_VGPIO) += intel_int0002_vgpio.o
 obj-$(CONFIG_INTEL_HID_EVENT)  += intel-hid.o
 obj-$(CONFIG_INTEL_VBTN)   += intel-vbtn.o
 obj-$(CONFIG_INTEL_SCU_IPC)+= intel_scu_ipc.o
diff --git a/drivers/platform/x86/intel_int0002_vgpio.c 
b/drivers/platform/x86/intel_int0002_vgpio.c
new file mode 100644
index ..92dc230ef5b2
--- /dev/null
+++ b/drivers/platform/x86/intel_int0002_vgpio.c
@@ -0,0 +1,219 @@
+/*
+ * Intel INT0002 "Virtual GPIO" driver
+ *
+ * Copyright (C) 2017 Hans de Goede 
+ *
+ * Loosely based on android x86 kernel code which is:
+ *
+ * Copyright (c) 2014, Intel Corporation.
+ *
+ * Author: Dyut Kumar Sil 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * Some peripherals on Bay Trail and Cherry Trail platforms signal a Power
+ * Management Event (PME) to the Power Management Controller (PMC) to wakeup
+ * the system. When this happens software needs to clear the PME bus 0 status
+ * bit in the GPE0a_STS register to avoid an IRQ storm on IRQ 9.
+ *
+ * This is modelled in ACPI through the INT0002 ACPI device, which is
+ * called a "Virtual GPIO controller" in ACPI because it defines the event
+ * handler to call when the PME triggers through _AEI and _L02 / _E02
+ * methods as would be done for a real GPIO interrupt in ACPI. Note this
+ * is a hack to define an AML event handler for the PME while using existing
+ * ACPI mechanisms, this is not a real GPIO at all.
+ *
+ * This driver will bind to the INT0002 device, and register as a GPIO
+ * controller, letting gpiolib-acpi.c call the _L02 handler as it would
+ * for a real GPIO controller.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#define DRV_NAME  

[PATCH v2 6/8] PCI / PM: Restore PME Enable if skipping wakeup setup

[Rafael J. Wysocki]

From: Rafael J. Wysocki 

The wakeup_prepared PCI device flag is used for preventing subsequent
changes of PCI device wakeup settings in the same way (e.g. enabling
device wakeup twice in a row).

However, in some cases PME Enable may be updated by things like PCI
configuration space restoration in the meantime and it may need to be
set again even though the rest of the settings need not change, so
modify __pci_enable_wake() to do that when it is about to return
early.

Also, it is reasonable to expect that __pci_enable_wake() will always
clear PME Status when invoked to disable device wakeup, so make it do
so even if it is going to return early then.

Signed-off-by: Rafael J. Wysocki 
---
 drivers/pci/pci.c |   26 --
 1 file changed, 24 insertions(+), 2 deletions(-)

Index: linux-pm/drivers/pci/pci.c
===
--- linux-pm.orig/drivers/pci/pci.c
+++ linux-pm/drivers/pci/pci.c
@@ -1805,6 +1805,23 @@ static void __pci_pme_active(struct pci_
pci_write_config_word(dev, dev->pm_cap + PCI_PM_CTRL, pmcsr);
 }
 
+static void pci_pme_restore(struct pci_dev *dev)
+{
+   u16 pmcsr;
+
+   if (!dev->pme_support)
+   return;
+
+   pci_read_config_word(dev, dev->pm_cap + PCI_PM_CTRL, &pmcsr);
+   if (dev->wakeup_prepared) {
+   pmcsr |= PCI_PM_CTRL_PME_ENABLE;
+   } else {
+   pmcsr &= ~PCI_PM_CTRL_PME_ENABLE;
+   pmcsr |= PCI_PM_CTRL_PME_STATUS;
+   }
+   pci_write_config_word(dev, dev->pm_cap + PCI_PM_CTRL, pmcsr);
+}
+
 /**
  * pci_pme_active - enable or disable PCI device's PME# function
  * @dev: PCI device to handle.
@@ -1899,9 +1916,14 @@ int __pci_enable_wake(struct pci_dev *de
if (enable && !runtime && !device_may_wakeup(&dev->dev))
return -EINVAL;
 
-   /* Don't do the same thing twice in a row for one device. */
-   if (!!enable == !!dev->wakeup_prepared)
+   /*
+* Don't do the same thing twice in a row for one device, but restore
+* PME Enable in case it has been updated by config space restoration.
+*/
+   if (!!enable == !!dev->wakeup_prepared) {
+   pci_pme_restore(dev);
return 0;
+   }
 
/*
 * According to "PCI System Architecture" 4th ed. by Tom Shanley & Don

--
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 v2 8/8] ACPI / PM: Ignore spurious SCI wakeups from suspend-to-idle

[Rafael J. Wysocki]

From: Rafael J. Wysocki 

The ACPI SCI (System Control Interrupt) is set up as a wakeup IRQ
during suspend-to-idle transitions and, consequently, any events
signaled through it wake up the system from that state.  However,
on some systems some of the events signaled via the ACPI SCI while
suspended to idle should not cause the system to wake up.  In fact,
quite often they should just be discarded.

Arguably, systems should not resume entirely on such events, but in
order to decide which events really should cause the system to resume
and which are spurious, it is necessary to resume up to the point
when ACPI SCIs are actually handled and processed, which is after
executing dpm_resume_noirq() in the system resume path.

For this reasons, add a loop around freeze_enter() in which the
platforms can process events signaled via multiplexed IRQ lines
like the ACPI SCI and add suspend-to-idle hooks that can be
used for this purpose to struct platform_freeze_ops.

In the ACPI case, the ->wake hook is used for checking if the SCI
has triggered while suspended and deferring the interrupt-induced
system wakeup until the events signaled through it are actually
processed sufficiently to decide whether or not the system should
resume.  In turn, the ->sync hook allows all of the relevant event
queues to be flushed so as to prevent events from being missed due
to race conditions.

In addition to that, some ACPI code processing wakeup events needs
to be modified to use the "hard" version of wakeup triggers, so that
it will cause a system resume to happen on device-induced wakeup
events even if the "soft" mechanism to prevent the system from
suspending is not enabled.  However, to preserve the existing
behavior with respect to suspend-to-RAM, this only is done in
the suspend-to-idle case and only if an SCI has occurred while
suspended.

Signed-off-by: Rafael J. Wysocki 
---
 drivers/acpi/battery.c  |2 +-
 drivers/acpi/button.c   |5 +++--
 drivers/acpi/device_pm.c|9 -
 drivers/acpi/internal.h |2 ++
 drivers/acpi/sleep.c|   37 +
 drivers/base/power/main.c   |5 -
 drivers/base/power/wakeup.c |   18 --
 include/acpi/acpi_bus.h |6 +-
 include/linux/suspend.h |7 +--
 kernel/power/process.c  |2 +-
 kernel/power/suspend.c  |   35 +--
 11 files changed, 103 insertions(+), 25 deletions(-)

Index: linux-pm/include/linux/suspend.h
===
--- linux-pm.orig/include/linux/suspend.h
+++ linux-pm/include/linux/suspend.h
@@ -189,6 +189,8 @@ struct platform_suspend_ops {
 struct platform_freeze_ops {
int (*begin)(void);
int (*prepare)(void);
+   void (*wake)(void);
+   void (*sync)(void);
void (*restore)(void);
void (*end)(void);
 };
@@ -428,7 +430,8 @@ extern unsigned int pm_wakeup_irq;
 
 extern bool pm_wakeup_pending(void);
 extern void pm_system_wakeup(void);
-extern void pm_wakeup_clear(void);
+extern void pm_system_cancel_wakeup(void);
+extern void pm_wakeup_clear(bool reset);
 extern void pm_system_irq_wakeup(unsigned int irq_number);
 extern bool pm_get_wakeup_count(unsigned int *count, bool block);
 extern bool pm_save_wakeup_count(unsigned int count);
@@ -478,7 +481,7 @@ static inline int unregister_pm_notifier
 
 static inline bool pm_wakeup_pending(void) { return false; }
 static inline void pm_system_wakeup(void) {}
-static inline void pm_wakeup_clear(void) {}
+static inline void pm_wakeup_clear(bool reset) {}
 static inline void pm_system_irq_wakeup(unsigned int irq_number) {}
 
 static inline void lock_system_sleep(void) {}
Index: linux-pm/kernel/power/suspend.c
===
--- linux-pm.orig/kernel/power/suspend.c
+++ linux-pm/kernel/power/suspend.c
@@ -72,6 +72,8 @@ static void freeze_begin(void)
 
 static void freeze_enter(void)
 {
+   trace_suspend_resume(TPS("machine_suspend"), PM_SUSPEND_FREEZE, true);
+
spin_lock_irq(&suspend_freeze_lock);
if (pm_wakeup_pending())
goto out;
@@ -84,11 +86,9 @@ static void freeze_enter(void)
 
/* Push all the CPUs into the idle loop. */
wake_up_all_idle_cpus();
-   pr_debug("PM: suspend-to-idle\n");
/* Make the current CPU wait so it can enter the idle loop too. */
wait_event(suspend_freeze_wait_head,
   suspend_freeze_state == FREEZE_STATE_WAKE);
-   pr_debug("PM: resume from suspend-to-idle\n");
 
cpuidle_pause();
put_online_cpus();
@@ -98,6 +98,31 @@ static void freeze_enter(void)
  out:
suspend_freeze_state = FREEZE_STATE_NONE;
spin_unlock_irq(&suspend_freeze_lock);
+
+   trace_suspend_resume(TPS("machine_suspend"), PM_SUSPEND_FREEZE, false);
+}
+
+static void s2idle_loop(void)
+{
+   pr_debug("PM: suspend-to-idle\n");
+
+   d

[PATCH v2 2/8] USB / PCI / PM: Allow the PCI core to do the resume cleanup

[Rafael J. Wysocki]

From: Rafael J. Wysocki 

hcd_pci_resume_noirq() used as a universal _resume_noirq handler for
PCI USB controllers calls pci_back_from_sleep() which is unnecessary
and may become problematic.

It is unnecessary, because the PCI bus type carries out post-suspend
cleanup of all PCI devices during resume and that covers all things
done by the pci_back_from_sleep().  There is no reason why USB cannot
follow all of the other PCI devices in that respect.

It will become problematic after subsequent changes that make it
possible to go back to sleep again after executing dpm_resume_noirq()
if no valid system wakeup events have been detected at that point.
Namely, calling pci_back_from_sleep() at the _resume_noirq stage
will cause the wakeup status of the devices in question to be cleared
and if any of them has triggered system wakeup, that event may be
missed then.

For the above reasons, drop the pci_back_from_sleep() invocation
from hcd_pci_resume_noirq().

Signed-off-by: Rafael J. Wysocki 
Acked-by: Alan Stern 
---
 drivers/usb/core/hcd-pci.c |7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

Index: linux-pm/drivers/usb/core/hcd-pci.c
===
--- linux-pm.orig/drivers/usb/core/hcd-pci.c
+++ linux-pm/drivers/usb/core/hcd-pci.c
@@ -584,12 +584,7 @@ static int hcd_pci_suspend_noirq(struct
 
 static int hcd_pci_resume_noirq(struct device *dev)
 {
-   struct pci_dev  *pci_dev = to_pci_dev(dev);
-
-   powermac_set_asic(pci_dev, 1);
-
-   /* Go back to D0 and disable remote wakeup */
-   pci_back_from_sleep(pci_dev);
+   powermac_set_asic(to_pci_dev(dev), 1);
return 0;
 }
 

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