Re: [PATCH v2] hid: migrate Riso Kagaku LED driver from USB misc to HID

[Heiner Kallweit]

Am 15.06.2016 um 22:59 schrieb Heiner Kallweit:
> Am 15.06.2016 um 09:31 schrieb Benjamin Tissoires:
>> On Jun 15 2016 or thereabouts, Heiner Kallweit wrote:
>>> Am 14.06.2016 um 23:49 schrieb Benjamin Tissoires:
 On Jun 12 2016 or thereabouts, Heiner Kallweit wrote:
> The Riso Kagaku Webmail Notifier (and its clones) is supported as part of
> usb/misc/usbled driver currently. This patch migrates the driver for this
> device to the HID subsystem.
>
> Benefits:
> - Avoid using USB low-level calls and use the HID subsystem instead
>   (as this device provides a USB HID interface)
> - Use standard LED subsystem instead of proprietary sysfs entries,
>   this allows e.g. to use the device with features like triggers
>
> I know at least one cheap clone coming with green and blue LED switched.
> There's a module paramater to deal with this.
>
> There might be users of the current module, therefore so far allow
> compilation of the new driver only if the old one is disabled.
>
> Signed-off-by: Heiner Kallweit 
> ---
> v2:
> - change config symbol from HID_RIKA to HID_RISO_KAGAKU
> - use full name Riso Kagaku instead of rika in several places
> - don't remove device from ignore list if CONFIG_USB_LED is defined
> - fix module parameter permissions

 Thanks for the respin. This version (and the other for hid-rika) looks
 fine. Though I wonder if you should not call hid_hw_open() at the end of
 probe (and hid_hw_close() during remove) to keep the device opened.
 Otherwise I am unsure whether your usb commands will get treated (I
 might be wrong).

>>> When looking at other hid device drivers hid_hw_open seems to be needed
>>> only if the device needs special treatment.
>>
>> Not exactly. hid_hw_open is called whenever someone opens the hidraw or
>> input node (or any other resource attached to the HID device). This
>> starts the input reading, but also calls usb_autopm_get_interface()
>> which will prevent the device to be autosuspended. The drivers that call
>> hid_hw_open() in their probe are the ones where we know no one will open
>> the hidraw or input node but we need to poll for events.
>>
>>> My Riso Kagaku and Dream Cheeky devices work fine with the new drivers
>>> w/o calling hid_hw_open.
>>
>> Let's keep it that way then.
>>
>>>
 There is also one high level comment I would like to do:
 even if your driver is better than usbled.c, people won't use it because
 distributions won't enable it as there is 2 issues:
 - one is you are breaking kernel ABI (we already discussed it)
 - the other one is that if people want to use your new hid drivers, they
   have to disable CONFIG_USB_LED, which removes support of the
   DELCOM_VISUAL_SIGNAL_INDICATOR

>>> Yes, I think you're right.
>>> With regard to the Delcom Visual Signal Indicator:
>>> The old USB LED driver supports only generation 1 of these devices which
>>> have a not fully HID compliant interface.
>>> In 2008 they were replace with generation 2 which has fully a HID
>>> compliant interface. Generation 2 is not yet supported by the kernel.
>>> (Currently I'm trying to get hold of such a device.)
>>>
>>> Therefore it might be better to leave support for the Gen 1 Delcom device
>>> at USB misc. However this would mean that we have to change the config
>>> symbol for this driver so that it doesn't conflict with the other part
>>> we're moving to hid.
>>> Would changing the config symbol be an issue? For now we could select
>>> the new config symbol automatically if CONFIG_USB_LED is set.
>>
>> Why would you change the old config symbol for the existing devices. If
>> (and I don't think that's the best option) you were to add a new symbol,
>> you could use this to select between HID and USB for the new drivers:
>> CONFIG_USB_LED_LEGACY_SUPPORT would depend on CONFIG_USB_LED, and you
>> choose to enable the HID driver based on CONFIG_USB_LED_LEGACY_SUPPORT.
>>
>>>
 I really think it would not cost too much to do the whole change in 2
 passes:
 - move the entire usbled to hid, keeping the old sysfs API in place, and
   eventually add a symlink from the old place (under the usb device) to
   the HID device to keep path stable
>>>
>>> I guess you don't mean symlink literally but adding a comment in Kconfig
>>> that the driver was moved?
>>
>> No. I'd rather not having the files moved around when they are KABI. So
>> either you add the old sysfs files directly at the same level, or you
>> symlink to them. Some HID driver already take a pointer to the
>> underlying USB device, so you can do the same.
>>
> OK, thanks for the further explanations. So, what I would do:
> - merge new LED HID drivers to a "new USB LED" driver
> - remove Riso Kagaku and Dream Cheeky support from old USB LED driver
>   (the old driver then just supports the non-HID Gen 1 Delcom device)
> - let 

[PATCH net 1/3] r8152: disable MAC clock speed down

[Hayes Wang]

Disable MAC clock speed down. It may casue the first control
transfer to contain the wrong data, when the power state change
from U1 to U0.

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

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 3f9f6ed..89dc752 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -3382,15 +3382,11 @@ static void r8153_init(struct r8152 *tp)
r8153_power_cut_en(tp, false);
r8153_u1u2en(tp, true);
 
-   ocp_write_word(tp, MCU_TYPE_PLA, PLA_MAC_PWR_CTRL, ALDPS_SPDWN_RATIO);
-   ocp_write_word(tp, MCU_TYPE_PLA, PLA_MAC_PWR_CTRL2, EEE_SPDWN_RATIO);
-   ocp_write_word(tp, MCU_TYPE_PLA, PLA_MAC_PWR_CTRL3,
-  PKT_AVAIL_SPDWN_EN | SUSPEND_SPDWN_EN |
-  U1U2_SPDWN_EN | L1_SPDWN_EN);
-   ocp_write_word(tp, MCU_TYPE_PLA, PLA_MAC_PWR_CTRL4,
-  PWRSAVE_SPDWN_EN | RXDV_SPDWN_EN | TX10MIDLE_EN |
-  TP100_SPDWN_EN | TP500_SPDWN_EN | TP1000_SPDWN_EN |
-  EEE_SPDWN_EN);
+   /* MAC clock speed down */
+   ocp_write_word(tp, MCU_TYPE_PLA, PLA_MAC_PWR_CTRL, 0);
+   ocp_write_word(tp, MCU_TYPE_PLA, PLA_MAC_PWR_CTRL2, 0);
+   ocp_write_word(tp, MCU_TYPE_PLA, PLA_MAC_PWR_CTRL3, 0);
+   ocp_write_word(tp, MCU_TYPE_PLA, PLA_MAC_PWR_CTRL4, 0);
 
r8153_enable_eee(tp);
r8153_aldps_en(tp, true);
-- 
2.4.11

--
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 3/3] r8152: correct the rx early size

[Hayes Wang]

The rx early size should be

(agg_buf_sz - packet size) / 8

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

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index f5bc351..4e257b8 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -31,7 +31,7 @@
 #define NETNEXT_VERSION"08"
 
 /* Information for net */
-#define NET_VERSION"3"
+#define NET_VERSION"4"
 
 #define DRIVER_VERSION "v1." NETNEXT_VERSION "." NET_VERSION
 #define DRIVER_AUTHOR "Realtek linux nic maintainers "
@@ -2174,7 +2174,7 @@ static void r8153_set_rx_early_timeout(struct r8152 *tp)
 static void r8153_set_rx_early_size(struct r8152 *tp)
 {
u32 mtu = tp->netdev->mtu;
-   u32 ocp_data = (agg_buf_sz - mtu - VLAN_ETH_HLEN - VLAN_HLEN) / 4;
+   u32 ocp_data = (agg_buf_sz - mtu - VLAN_ETH_HLEN - VLAN_HLEN) / 8;
 
ocp_write_word(tp, MCU_TYPE_USB, USB_RX_EARLY_SIZE, ocp_data);
 }
-- 
2.4.11

--
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 2/3] r8152: reset the bmu

[Hayes Wang]

Reset the BMU to clear the rx/tx fifo. This avoids that the unexpected
data remains in the hw.

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

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 89dc752..f5bc351 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -116,6 +116,7 @@
 #define USB_TX_DMA 0xd434
 #define USB_TOLERANCE  0xd490
 #define USB_LPM_CTRL   0xd41a
+#define USB_BMU_RESET  0xd4b0
 #define USB_UPS_CTRL   0xd800
 #define USB_MISC_0 0xd81a
 #define USB_POWER_CUT  0xd80a
@@ -338,6 +339,10 @@
 #define TEST_MODE_DISABLE  0x0001
 #define TX_SIZE_ADJUST10x0100
 
+/* USB_BMU_RESET */
+#define BMU_RESET_EP_IN0x01
+#define BMU_RESET_EP_OUT   0x02
+
 /* USB_UPS_CTRL */
 #define POWER_CUT  0x0100
 
@@ -2456,6 +2461,17 @@ static void r8153_teredo_off(struct r8152 *tp)
ocp_write_dword(tp, MCU_TYPE_PLA, PLA_TEREDO_TIMER, 0);
 }
 
+static void rtl_reset_bmu(struct r8152 *tp)
+{
+   u32 ocp_data;
+
+   ocp_data = ocp_read_byte(tp, MCU_TYPE_USB, USB_BMU_RESET);
+   ocp_data &= ~(BMU_RESET_EP_IN | BMU_RESET_EP_OUT);
+   ocp_write_byte(tp, MCU_TYPE_USB, USB_BMU_RESET, ocp_data);
+   ocp_data |= BMU_RESET_EP_IN | BMU_RESET_EP_OUT;
+   ocp_write_byte(tp, MCU_TYPE_USB, USB_BMU_RESET, ocp_data);
+}
+
 static void r8152_aldps_en(struct r8152 *tp, bool enable)
 {
if (enable) {
@@ -2681,6 +2697,7 @@ static void r8153_first_init(struct r8152 *tp)
r8153_hw_phy_cfg(tp);
 
rtl8152_nic_reset(tp);
+   rtl_reset_bmu(tp);
 
ocp_data = ocp_read_byte(tp, MCU_TYPE_PLA, PLA_OOB_CTRL);
ocp_data &= ~NOW_IS_OOB;
@@ -2742,6 +2759,7 @@ static void r8153_enter_oob(struct r8152 *tp)
ocp_write_byte(tp, MCU_TYPE_PLA, PLA_OOB_CTRL, ocp_data);
 
rtl_disable(tp);
+   rtl_reset_bmu(tp);
 
for (i = 0; i < 1000; i++) {
ocp_data = ocp_read_byte(tp, MCU_TYPE_PLA, PLA_OOB_CTRL);
@@ -2803,6 +2821,7 @@ static void rtl8153_disable(struct r8152 *tp)
 {
r8153_aldps_en(tp, false);
rtl_disable(tp);
+   rtl_reset_bmu(tp);
r8153_aldps_en(tp, true);
usb_enable_lpm(tp->udev);
 }
-- 
2.4.11

--
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 0/3] r8152: fix known issues

[Hayes Wang]

These patches fix some known issues.

Hayes Wang (3):
  r8152: disable MAC clock speed down
  r8152: reset the bmu
  r8152: correct the rx early size

 drivers/net/usb/r8152.c | 37 ++---
 1 file changed, 26 insertions(+), 11 deletions(-)

-- 
2.4.11

--
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: xhci usb serial open/close issue

[Greg KH]

On Wed, Jun 15, 2016 at 07:19:07PM +0530, shishir tiwari wrote:
> Hi Greg,
> 
> To debug i have put some printk inside this xhci_handle_event() function
> 
> for example:
> xhci_handle_event(){
>  .
> 
>case TRB_TYPE(TRB_COMPLETION):
>   +  printk(KERN_EMERG "TRB_COMPLETION info
> :%d",le32_to_cpu(event->event_cmd.flags) & TRB_TYPE_BITMASK);
> handle_cmd_completion(xhci, >event_cmd);
> break;
> case TRB_TYPE(TRB_TRANSFER):
>+ printk(KERN_EMERG "TRB_TRANSFER info
> :%d",le32_to_cpu(event->event_cmd.flags) & TRB_TYPE_BITMASK);
> ret = handle_tx_event(xhci, >trans_event);
> if (ret < 0)
> xhci->error_bitmask |= 1 << 9;
> else
> update_ptrs = 0;
> break;
> 
> }
> 
> Now i am not getting any error with the same script .but i need to
> give some clarification on this.
> 
> What may be the reason that error is not coming now??

Again, no idea, you are on your own with such an old and obsolete kernel
version, sorry.  Please get support for it from the vendor that is
forcing you to use it.

best of 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 v5 2/2] phy: rockchip-inno-usb2: add a new driver for Rockchip usb2phy

[Frank Wang]

Hi Guenter & Heiko,

On 2016/6/15 23:47, Guenter Roeck wrote:

On Tue, Jun 14, 2016 at 6:14 PM, Frank Wang  wrote:

Hi Heiko & Guenter,


On 2016/6/14 22:00, Heiko Stübner wrote:

Am Dienstag, 14. Juni 2016, 06:50:31 schrieb Guenter Roeck:

On Tue, Jun 14, 2016 at 6:27 AM, Heiko Stübner  wrote:

Am Montag, 13. Juni 2016, 10:10:10 schrieb Frank Wang:

The newer SoCs (rk3366, rk3399) take a different usb-phy IP block
than rk3288 and before, and most of phy-related registers are also
different from the past, so a new phy driver is required necessarily.

Signed-off-by: Frank Wang 
---

[...]


+static int rockchip_usb2phy_init(struct phy *phy)
+{
+ struct rockchip_usb2phy_port *rport = phy_get_drvdata(phy);
+ struct rockchip_usb2phy *rphy = dev_get_drvdata(phy->dev.parent);
+ int ret;
+


  if (!rport->port_cfg)
   return 0;

Otherwise the currently empty otg-port will cause null-pointer
dereferences
when it gets assigned in the devicetree already.

Not really, at least not here - that port should not have port_id set
to USB2PHY_PORT_HOST.

Does it even make sense to instantiate the otg port ? Is it going to
do anything without port configuration ?

Ok, that would be the other option - not creating the phy in the driver.


Well, I will put this conditional inside *_host_port_init(), if it is an
empty, the phy-device should not be created.
Something like the following:

--- a/drivers/phy/phy-rockchip-inno-usb2.c
+++ b/drivers/phy/phy-rockchip-inno-usb2.c
@@ -483,9 +483,13 @@ static int rockchip_usb2phy_host_port_init(struct
rockchip_usb2phy *rphy,
  {
 int ret;

-   rport->port_id = USB2PHY_PORT_HOST;
 rport->port_cfg = >phy_cfg->port_cfgs[USB2PHY_PORT_HOST];
+   if (!rport->port_cfg) {
+   dev_err(rphy->dev, "no host port-config provided.\n");
+   return -EINVAL;
+   }

This would never be NULL. At issue is that you don't assign port_cfg
if the port is _not_ a host port.


Sorry, I made a mistake. How about something like the following:

@@ -574,6 +579,15 @@ static int rockchip_usb2phy_probe(struct 
platform_device *pdev)

struct rockchip_usb2phy_port *rport = >ports[index];
struct phy *phy;

+   /*
+* This driver aim to support both otg-port and host-port,
+* but unfortunately, the otg part is not ready in current,
+* so this comments and below codes are interim, which 
should

+* be removed after otg-port is supplied soon.
+*/
+   if (of_node_cmp(child_np->name, "host-port"))
+   goto next_child;
+
phy = devm_phy_create(dev, child_np, 
_usb2phy_ops);

if (IS_ERR(phy)) {
dev_err(dev, "failed to create phy\n");
@@ -582,17 +596,13 @@ static int rockchip_usb2phy_probe(struct 
platform_device *pdev)

}

rport->phy = phy;
-
-   /* initialize otg/host port separately */
-   if (!of_node_cmp(child_np->name, "host-port")) {
-   ret = rockchip_usb2phy_host_port_init(rphy, rport,
- child_np);
-   if (ret)
-   goto put_child;
-   }
-
phy_set_drvdata(rport->phy, rport);

+   ret = rockchip_usb2phy_host_port_init(rphy, rport, 
child_np);

+   if (ret)
+   goto put_child;
+
+next_child:
/* to prevent out of boundary */
if (++index >= rphy->phy_cfg->num_ports)
break;


BR.
Frank

--
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: [RESENDING] dwc2: Using internal phy (fs mode) for STM32F4x9 platform

[Bruno Herrera]

On Wed, Jun 15, 2016 at 2:04 AM, John Youn  wrote:
> On 6/13/2016 8:21 AM, Bruno Herrera wrote:
>> Hi
>>
>> On Mon, Jun 13, 2016 at 9:19 AM, Maxime Coquelin
>>  wrote:
>>> Hi,
>>>
>>> 2016-06-10 8:56 GMT+02:00 Felipe Balbi :

 Hi,

 John Youn  writes:
> On 6/9/2016 10:18 AM, Bruno Herrera wrote:
>> Hello all,
>> I'm bringing the linux kernel for the STM32F4 MCU (mmu-less). This MCU
>> has two DWC2 cores on it:one for USB OTG HS and one for USB OTG FS.
>> I was able to make the DWC2 driver to work in FS mode using a internal
>> phy in both cores (HS and FS), but I had to patch it (in a bad way,
>> see bellow).
>> Basically STM32 uses a GGPIO register to control the POWER state of
>> the internal phy as it describes in the reference manual:
>>
>> OTG general core configuration register (OTG_GCCFG)
>> Address offset: 0x038
>> Reset value: 0x 
>>
>> Powerdown -> BIT(16)
>> Used to activate the transceiver in transmission/reception
>> 0: Power down active
>> 1: Power down deactivated (“Transceiver active”)
>>
>> So far what I did was in the dwc2_core_init
>>
>> +   /* Program the GGPIO register */
>> +   usbgpio = dwc2_readl(hsotg->regs + GGPIO);
>> +   usbgpio |= GGPIO_PWRDWN;
>> +   dwc2_writel(usbgpio, hsotg->regs + GGPIO);
>>
>> So I would like to check what would be you recommendation to implement
>> in it in the right way.
>> As it is a internal USB core register I could not find a way to
>> implement a phy that access it.
>> Syscon is also not the case (I guess) for the same reason.
>>
>> One way I thought would be to create a new property like:
>>
>> - snps,ggpio-reg: the value of GGPIO register for specific SoC/Vendor
>>
>> in my STM32 case could be something like that:
>>
>> snps,ggpio-reg = <0x10>
>>
>> The problem with this approach is that it could not be toggled
>> "logicaly" from let say some phy on/off code.
>>
>> please share you thoughts on this.
>>
>
> Hi Bruno,
>
> Unfortunately I'm not familiar enough with devicetree or the PHY
> framework to think of a good solution.
>
> Felipe,
>
> Do you have any advice on the best way to handle this?
>
> Looks like soc-specific PHY controls are mapped to the controller
> GPIO. We can add SOC specific code directly in the driver, but is
> there a better way?

 the best scenario would be to runtime detection of this based on some
 register. If that's not possible, then a DT flag would be nice, but I
 would call the flag by something more human readable such as
 "snps,activate-transceiver" or something like that.
>>>
>>> In case auto-detection is not possible, shouldn't be better to have a
>>> stm32 compatible,
>>> and associate it with dedicated params as done for other platforms?
>>> See drivers/usb/dwc2/platform.c
>>>
>>> Regards,
>>> Maxime
>>
>> looking into the documentation I could not find a way to auto detect
>> the core is running on STM32.
>> And the register used by ST is GGPIO, so it could be used for
>> different purposes according to the SoC vendor.
>> We will need to have a stm32 complatible dwc2_core_params because the
>> parameters for the FS core are not the hw detected ones.
>>
>> So in this case I see 2 options:
>> 1 - We create a param in the dwc2_core_params that is only for ST:
>> int stm_activate_transceiver;
>>
>> 2 - We create a ST specific DT option for that:
>>  - stm32, activate-transceiver:
>>
>
> Hi Bruno,
>
> For now, let's not create a DT and stick to the params based on
> compatible string. It sounds like you need to implement that
> anyways.
>
> We have some changes in the works redoing some of the parameter stuff
> to make it more consistent. We can always change around that params
> struct. But DT might be harder.
>
> Thanks,
> John

Hi John,
Thanks for the feedback, I'll implement that way!

Br,
Bruno
--
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 v10 6/7] usb: pci-quirks: add Intel USB drcfg mux device

[Lu Baolu]

Hi Greg,

On 06/09/2016 10:39 AM, Lu Baolu wrote:
> Hi Greg,
>
> On 06/08/2016 11:45 PM, Greg Kroah-Hartman wrote:
>> On Wed, Jun 08, 2016 at 03:56:04PM +0800, Lu Baolu wrote:
>>> Hi Greg,
>>>
>>> On 06/08/2016 12:45 PM, Greg Kroah-Hartman wrote:
 On Thu, Jun 02, 2016 at 09:37:28AM +0800, Lu Baolu wrote:
> In some Intel platforms, a single usb port is shared between USB host
> and device controllers. The shared port is under control of a switch
> which is defined in the Intel vendor defined extended capability for
> xHCI.
>
> This patch adds the support to detect and create the platform device
> for the port mux switch.
 Why do you need a platform device for this?  You do nothing with this
 device, why create it at all?
>>> In this patch series, I have a generic framework for port mux devices
>>> and two port mux drivers sitting on top the generic code.
>>>
>>> In this patch, I create a platform device for the real mux device in
>>> Intel Cherry Trail or Broxton SOCs. In it's driver, I registered a mux
>>> into the generic framework and handle the power management
>>> things in driver's pm entries (otherwise, the system can't be waken
>>> up from system suspend).:)
>>>
 And why is it a platform device, isn't is really a PCI device?  Why
 would you ever find a "platform" device below a PCI device?  Don't abuse
 platform devices for things that aren't.  It makes me want to delete
 that whole interface more and more...
>>> Port mux devices are physical devices in Intel Cherry Trail and Broxton
>>> SOCs. It doesn't sit on any PCIe bus. But it maps its registers in xHCI
>>> space. OS kernel can enumerate it by looking up the xhci extended
>>> capability list with a vendor specific capability ID.
>> A physical device that maps registers into PCI space seems like a PCI
>> device of some type to me :)
>>
>> Again, I hate platform devices for obvious reasons like this...
>>
> It's not PCI configure space, but xhci's io memory. XHCI spec reserves
> a range in its extended capability list for vendor specific things. Intel's
> platform leverages this for the port mux device register mapping.
> It looks odd though. :)

A gentle ping. :)

This port mux is not a PCI device. It only leverages the vendor
specific capability defined in xhci specification for enumeration.

Best regards,
Lu Baolu
--
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: uac2: diagnosing uac2 audio gadget problems

[Caleb Crome]

> On Mon, Jun 13, 2016 at 11:56 PM, Peter Chen  wrote:
>>
>> On Tue, Jun 14, 2016 at 02:00:23PM +0800, Peter Chen wrote:
>> > On Mon, Jun 13, 2016 at 04:49:50PM -0700, Caleb Crome wrote:
>> > > On Mon, Jun 13, 2016 at 4:04 PM, Caleb Crome  wrote:
>> > > > On Mon, Jun 13, 2016 at 2:53 AM, Peter Chen  
>> > > > wrote:
>> > > >> On Wed, Jun 08, 2016 at 04:11:11PM -0700, Caleb Crome wrote:
>> > > >>>
>> > > >>> Here is the script I use for starting the gadget interface:
>> > > >>>
>> > > >>> cd /sys/kernel/config/usb_gadget
>> > > >>> mkdir g1
>> > > >>> cd g1
>> > > >>> echo "0x1d6b" > idVendor
>> > > >>> echo "0x0104" > idProduct
>> > > >>> mkdir strings/0x409
>> > > >>> echo "0123456789" > strings/0x409/serialnumber
>> > > >>> echo "Foo Inc." > strings/0x409/manufacturer
>> > > >>> echo "Bar Gadget" > strings/0x409/product
>> > > >>> mkdir functions/uac2.aud0
>> > > >>> mkdir functions/ecm.usb0
>> > > >>> #echo 64000 > functions/uac2.aud0/c_srate
>> > > >>> #echo 64000 > functions/uac2.aud0/p_srate
>> > > >>> mkdir configs/c.1
>> > > >>> mkdir configs/c.1/strings/0x409
>> > > >>> echo "CDC ECM + audio" > configs/c.1/strings/0x409/configuration
>> > > >>> ln -s functions/uac2.aud0 configs/c.1
>> > > >>> ln -s functions/ecm.usb0 configs/c.1
>> > > >>> echo `ls /sys/class/udc/` > /sys/kernel/config/usb_gadget/g1/UDC
>> > > >>>
>> > > >>
>> > > >> Try to use below command to see if it works, it works at my i.mx6 
>> > > >> board.
>> > > >>
>> > > >> 1.  List of PLAYBACK Hardware Devices 
>> > > >> root@imx6sxsabresd:~# aplay -l
>> > > >>  List of PLAYBACK Hardware Devices 
>> > > >> card 0: wm8962audio [wm8962-audio], device 0: HiFi wm8962-0 []
>> > > >>   Subdevices: 1/1
>> > > >>   Subdevice #0: subdevice #0
>> > > >> card 1: imxspdif [imx-spdif], device 0: S/PDIF PCM Playback 
>> > > >> dit-hifi-0 []
>> > > >>   Subdevices: 1/1
>> > > >>   Subdevice #0: subdevice #0
>> > > >> card 2: UAC2Gadget [UAC2_Gadget], device 0: UAC2 PCM [UAC2 PCM]
>> > > >>   Subdevices: 1/1
>> > > >>   Subdevice #0: subdevice #0
>> > > >> 2.  List of CAPTURE Hardware Devices 
>> > > >> root@imx6sxsabresd:~# arecord -l
>> > > >>  List of CAPTURE Hardware Devices 
>> > > >> card 0: wm8962audio [wm8962-audio], device 0: HiFi wm8962-0 []
>> > > >>   Subdevices: 1/1
>> > > >>   Subdevice #0: subdevice #0
>> > > >> card 2: UAC2Gadget [UAC2_Gadget], device 0: UAC2 PCM [UAC2 PCM]
>> > > >>   Subdevices: 1/1
>> > > >>   Subdevice #0: subdevice #0
>> > > >> 3. Using below command to play (it is playback, the audio file is from
>> > > >> PC)
>> > > >> root@imx6sxsabresd:~# arecord -f dat -t wav -D hw:2,0 | aplay -D 
>> > > >> hw:0,0 &
>> > > >>
>> > > >> NOTE: arecord uses uac2_gadget to record, aplay uses real codec to 
>> > > >> play
>> > > >>
>> > > >
>> > > > Great to hear that it works on your board, that gives me hope :-)
>> > > >
>> > > > 2 questions:
>> > > > 1) What kernel version do you use?
>> > > > 2) What are the commands you send to configfs to get it working?  Does
>> > > > it look like mine?
>> > > >
>> >
>> > I tried your commands, it can't work indeed. It seems the two interfaces
>> > can't be work together, the host side can't find the USB audio device.
>> > My test branch:
>> > https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git
>> > branch: testing/next
>> >
>> > Works command:
>> > modprobe libcomposite
>> > mount none /sys/kernel/config/ -t configfs
>> > cd /sys/kernel/config/usb_gadget
>> > mkdir g1
>> > cd g1
>> > echo "0x1d6b" > idVendor
>> > echo "0x0104" > idProduct
>> > mkdir strings/0x409
>> > echo "0123456789" > strings/0x409/serialnumber
>> > echo "Foo Inc." > strings/0x409/manufacturer
>> > echo "Bar Gadget" > strings/0x409/product
>> > mkdir functions/uac2.aud0
>> > # mkdir functions/ecm.usb0
>> >
>> > mkdir configs/c.1
>> > mkdir configs/c.1/strings/0x409
>> > # echo "CDC ECM + audio" > configs/c.1/strings/0x409/configuration
>> >
>> >
>> > echo 2 > functions/uac2.aud0/p_ssize
>> > echo 48000 > functions/uac2.aud0/p_srate
>> > echo 3 > functions/uac2.aud0/p_chmask
>> >
>> > echo 2 > functions/uac2.aud0/c_ssize
>> > echo 48000 > functions/uac2.aud0/c_srate
>> > echo 3 > functions/uac2.aud0/c_chmask
>> >
>> > ln -s functions/uac2.aud0 configs/c.1
>> > # ln -s functions/ecm.usb0 configs/c.1
>> >
>> > echo `ls /sys/class/udc/` > /sys/kernel/config/usb_gadget/g1/UDC
>> >
>> > At host side:
>> > aplay -Dhw:1 sine48k16s-5min.wav
>> > card 1: Gadget [Bar Gadget], device 0: USB Audio [USB Audio]
>> >   Subdevices: 1/1
>> > Subdevice #0: subdevice #0
>> >
>> > At device side:
>> > arecord -f dat -t wav -D hw:2,0 | aplay -D hw:0,0 &
>> >
>> > I can hear the wav from my codec
>> >
>>
>> When I try to fix that issue, I find this issue is gone. Both
>> ncm and usb audio works properly. Below is my commands:
>>
>> modprobe libcomposite
>> # echo "file drivers/usb/* +p" > /sys/kernel/debug/dynamic_debug/control
>>
>> 

[PATCH] usb: early/ehci-dbgp: make it explicitly non-modular

[Paul Gortmaker]

The Kconfig currently controlling compilation of this code is:

arch/x86/Kconfig.debug:config EARLY_PRINTK_DBGP
arch/x86/Kconfig.debug: bool "Early printk via EHCI debug port"

...meaning that it currently is not being built as a module by anyone.

Lets remove the couple traces of modularity so that when reading the
driver there is no doubt it is builtin-only.

Since module_init translates to device_initcall in the non-modular
case, the init ordering remains unchanged with this commit.

Cc: Greg Kroah-Hartman 
Cc: linux-usb@vger.kernel.org
Signed-off-by: Paul Gortmaker 
---
 drivers/usb/early/ehci-dbgp.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/early/ehci-dbgp.c b/drivers/usb/early/ehci-dbgp.c
index 8cfc3191be50..74bc2507a5bc 100644
--- a/drivers/usb/early/ehci-dbgp.c
+++ b/drivers/usb/early/ehci-dbgp.c
@@ -13,7 +13,7 @@
 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
@@ -1093,5 +1094,5 @@ static int __init kgdbdbgp_start_thread(void)
 
return 0;
 }
-module_init(kgdbdbgp_start_thread);
+device_initcall(kgdbdbgp_start_thread);
 #endif /* CONFIG_KGDB */
-- 
2.5.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] hid: migrate Riso Kagaku LED driver from USB misc to HID

[Heiner Kallweit]

Am 15.06.2016 um 09:31 schrieb Benjamin Tissoires:
> On Jun 15 2016 or thereabouts, Heiner Kallweit wrote:
>> Am 14.06.2016 um 23:49 schrieb Benjamin Tissoires:
>>> On Jun 12 2016 or thereabouts, Heiner Kallweit wrote:
 The Riso Kagaku Webmail Notifier (and its clones) is supported as part of
 usb/misc/usbled driver currently. This patch migrates the driver for this
 device to the HID subsystem.

 Benefits:
 - Avoid using USB low-level calls and use the HID subsystem instead
   (as this device provides a USB HID interface)
 - Use standard LED subsystem instead of proprietary sysfs entries,
   this allows e.g. to use the device with features like triggers

 I know at least one cheap clone coming with green and blue LED switched.
 There's a module paramater to deal with this.

 There might be users of the current module, therefore so far allow
 compilation of the new driver only if the old one is disabled.

 Signed-off-by: Heiner Kallweit 
 ---
 v2:
 - change config symbol from HID_RIKA to HID_RISO_KAGAKU
 - use full name Riso Kagaku instead of rika in several places
 - don't remove device from ignore list if CONFIG_USB_LED is defined
 - fix module parameter permissions
>>>
>>> Thanks for the respin. This version (and the other for hid-rika) looks
>>> fine. Though I wonder if you should not call hid_hw_open() at the end of
>>> probe (and hid_hw_close() during remove) to keep the device opened.
>>> Otherwise I am unsure whether your usb commands will get treated (I
>>> might be wrong).
>>>
>> When looking at other hid device drivers hid_hw_open seems to be needed
>> only if the device needs special treatment.
> 
> Not exactly. hid_hw_open is called whenever someone opens the hidraw or
> input node (or any other resource attached to the HID device). This
> starts the input reading, but also calls usb_autopm_get_interface()
> which will prevent the device to be autosuspended. The drivers that call
> hid_hw_open() in their probe are the ones where we know no one will open
> the hidraw or input node but we need to poll for events.
> 
>> My Riso Kagaku and Dream Cheeky devices work fine with the new drivers
>> w/o calling hid_hw_open.
> 
> Let's keep it that way then.
> 
>>
>>> There is also one high level comment I would like to do:
>>> even if your driver is better than usbled.c, people won't use it because
>>> distributions won't enable it as there is 2 issues:
>>> - one is you are breaking kernel ABI (we already discussed it)
>>> - the other one is that if people want to use your new hid drivers, they
>>>   have to disable CONFIG_USB_LED, which removes support of the
>>>   DELCOM_VISUAL_SIGNAL_INDICATOR
>>>
>> Yes, I think you're right.
>> With regard to the Delcom Visual Signal Indicator:
>> The old USB LED driver supports only generation 1 of these devices which
>> have a not fully HID compliant interface.
>> In 2008 they were replace with generation 2 which has fully a HID
>> compliant interface. Generation 2 is not yet supported by the kernel.
>> (Currently I'm trying to get hold of such a device.)
>>
>> Therefore it might be better to leave support for the Gen 1 Delcom device
>> at USB misc. However this would mean that we have to change the config
>> symbol for this driver so that it doesn't conflict with the other part
>> we're moving to hid.
>> Would changing the config symbol be an issue? For now we could select
>> the new config symbol automatically if CONFIG_USB_LED is set.
> 
> Why would you change the old config symbol for the existing devices. If
> (and I don't think that's the best option) you were to add a new symbol,
> you could use this to select between HID and USB for the new drivers:
> CONFIG_USB_LED_LEGACY_SUPPORT would depend on CONFIG_USB_LED, and you
> choose to enable the HID driver based on CONFIG_USB_LED_LEGACY_SUPPORT.
> 
>>
>>> I really think it would not cost too much to do the whole change in 2
>>> passes:
>>> - move the entire usbled to hid, keeping the old sysfs API in place, and
>>>   eventually add a symlink from the old place (under the usb device) to
>>>   the HID device to keep path stable
>>
>> I guess you don't mean symlink literally but adding a comment in Kconfig
>> that the driver was moved?
> 
> No. I'd rather not having the files moved around when they are KABI. So
> either you add the old sysfs files directly at the same level, or you
> symlink to them. Some HID driver already take a pointer to the
> underlying USB device, so you can do the same.
> 
OK, thanks for the further explanations. So, what I would do:
- merge new LED HID drivers to a "new USB LED" driver
- remove Riso Kagaku and Dream Cheeky support from old USB LED driver
  (the old driver then just supports the non-HID Gen 1 Delcom device)
- let new USB LED driver create sysmlinks in sysfs to not break the old ABI

The latter can be achieved easier than expected as the old sysfs
attributes 

Re: [PATCH v3 4/4] musb: sunxi: Simplify dr_mode handling

[Maxime Ripard]

Hi,

On Wed, Jun 08, 2016 at 12:30:20PM +0200, Hans de Goede wrote:
> Hi,
> 
> On 08-06-16 12:23, Maxime Ripard wrote:
> >Hi,
> >
> >On Sun, Jun 05, 2016 at 04:59:36PM +0200, Hans de Goede wrote:
> >>phy-sun4i-usb now has proper dr_mode handling, it always registers an
> >>extcon, and sends a notify with the mode (even when in peripheral- /
> >>host-only mode) at least once.
> >>
> >>So we can simply the sunxi musb glue by always registering its extcon
> >>notifier and relying on sunxi_musb_work() to enable vbus when in
> >>host-only mode.
> >>
> >>This also enables host- and peripheral-only mode with vbus monitoring.
> >>
> >>Signed-off-by: Hans de Goede 
> >
> >It's been a bit painful to track all the patches needed so that it
> >applies properly, but I've finally been able to test it on a Sinlinx
> >SinA33 with peripheral-only mUSB, and it works like a charm.
> >
> >You can add my Tested-by.
> 
> Great, thanks for testing.
> 
> This is the board which has an otg connector with vbus not connected,
> right? Yet it does have a functional id-pin, right ?

It's that one, yes.

> In that case you should be able to put it in dual-role mode (only
> specify the id-pin in the phy dts node, no vbus / vbus-monitoring)
> and then it _should_ work in host mode if you use a powered hub.
> 
> I'm fine with putting in peripheral-only mode, but as said
> dual-role might work with a powered hub.

Good point, I'll test that.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


signature.asc
Description: PGP signature

Re: [PATCH v5 2/2] phy: rockchip-inno-usb2: add a new driver for Rockchip usb2phy

[Heiko Stübner]

Hi Frank,

Am Mittwoch, 15. Juni 2016, 18:58:43 schrieb Frank Wang:
> On 2016/6/15 17:04, Heiko Stübner wrote:
> > Am Mittwoch, 15. Juni 2016, 11:23:26 schrieb Frank Wang:
> >> On 2016/6/14 21:27, Heiko Stübner wrote:
> >>> Am Montag, 13. Juni 2016, 10:10:10 schrieb Frank Wang:
>  The newer SoCs (rk3366, rk3399) take a different usb-phy IP block
>  than rk3288 and before, and most of phy-related registers are also
>  different from the past, so a new phy driver is required necessarily.
>  
>  Signed-off-by: Frank Wang 
>  ---
>  
>  Changes in v5:
> - Added 'reg' in the data block to match the different phy-blocks in
> dt.
>  
>  Changes in v4:
> - Removed some processes related to 'vbus_host-supply'.
>  
>  Changes in v3:
> - Resolved the mapping defect between fixed value in driver and the
>  
>  property in devicetree.
>  
> - Optimized 480m output clock register function.
> - Code cleanup.
>  
>  Changes in v2:
> - Changed vbus_host operation from gpio to regulator in *_probe.
> - Improved the fault treatment relate to 480m clock register.
> - Cleaned up some meaningless codes in *_clk480m_disable.
> - made more clear the comment of *_sm_work.
> 
> drivers/phy/Kconfig  |7 +
> drivers/phy/Makefile |1 +
> drivers/phy/phy-rockchip-inno-usb2.c |  645
>  
>  ++ 3 files changed, 653 insertions(+)
>  
>  [...]
>  
>  +
>  +static int rockchip_usb2phy_exit(struct phy *phy)
>  +{
>  +struct rockchip_usb2phy_port *rport = phy_get_drvdata(phy);
>  +
>  
> >>>   if (!rport->port_cfg)
> >>>   
> >>>   return 0;
>  
>  +if (rport->port_id == USB2PHY_PORT_HOST)
>  +cancel_delayed_work_sync(>sm_work);
>  +
> >>> 
> >>> you will also need to resume the port here, if it is suspended at this
> >>> point, as phy_power_off gets called after phy_exit and would probably
> >>> produce clk enable/disable mismatches otherwise.
> >> 
> >> Hmm, from my personal point of view, when canceling sm_work here, it may
> >> not cause the port goes to suspend, isn't it? besides, clk only prepared
> >> in *_usb2phy_resume(), and unprepared in *_usb2phy_suspend(), so if we
> >> resume port here,  the prepare_count of clk will be increased again, I
> >> am afraid this is not correct, and am I wrong? would you like to tell me
> >> more details?
> > 
> > usb2phy_resume gets called both initially through phy_power_on as well.
> > So it's on but through the first scheduled work call, might get suspended
> > when nothing is connected. (clk_enable and clk_disable will run).
> > If nothing is connected on unload phy_power_off will get called while the
> > clock actually is still disabled.
> > 
> > So I think it's either resuming on exit, or at least making sure to do
> > nothing in that case in the phy_power_off callback of the driver.
> 
> Well, I got what you mean. I saw phy_power_on() gets called  twice at
> ehci/ohci driver probe time, one is at pdata->power_on(); another is at
> usb_add_hcd(), so after that, the power_count of phy increases to two.
> however, when ehci/ohci driver goes to suspend, there is only once to
> call phy_power_off(), and the power_count of phy decreases to 1, so our
> usb2phy_resume() could not be invoked :-) .
>
> If so, is it still need to care it?

You should never have to rely on oddities in other drivers :-)

> How about use suspended member of
> rockchip_usb2phy_port as a conditional to check in *_usb2phy_suspend(),
> if necessary.

That looks also sane and should work.


Heiko
--
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: [TESTPATCH] xhci: usb2 hw lpm extra debug

[Christian M . Amsüss]

On Wed, Jun 15, 2016 at 05:43:56PM +0200, chrysn wrote:
> Reviewing the patches, that was because the invalid port_num is used in
> `readl(pm_addr)` already, too early for your `portnum %d >
> num_usb2_ports` debug line. I'm shoving the line up to make it out
> before the segfault, and will report back when I've found the time to
> reboot.

The attached dmesg at least contains the line I was looking for (moved
that chunk up to the earliest meaningful position).

Best regards
chrysn
[0.00] Linux version 4.7.0-rc3-plus-xhcidebug+ (chrysn@hephaistos) (gcc 
version 5.4.0 20160609 (Debian 5.4.0-4) ) #26 SMP Wed Jun 15 17:48:21 CEST 2016
[0.00] Command line: BOOT_IMAGE=/vmlinuz-4.7.0-rc3-plus-xhcidebug+ 
root=/dev/mapper/root ro rootflags=subvol=default verbose init=/bin/bash
[0.00] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
[0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point 
registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
[0.00] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, 
using 'standard' format.
[0.00] x86/fpu: Using 'eager' FPU context switches.
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x00057fff] usable
[0.00] BIOS-e820: [mem 0x00058000-0x00058fff] reserved
[0.00] BIOS-e820: [mem 0x00059000-0x0009bfff] usable
[0.00] BIOS-e820: [mem 0x0009c000-0x0009cfff] reserved
[0.00] BIOS-e820: [mem 0x0009d000-0x0009dfff] usable
[0.00] BIOS-e820: [mem 0x0009e000-0x000b] reserved
[0.00] BIOS-e820: [mem 0x0010-0xcc965fff] usable
[0.00] BIOS-e820: [mem 0xcc966000-0xccb67fff] reserved
[0.00] BIOS-e820: [mem 0xccb68000-0xdb86cfff] usable
[0.00] BIOS-e820: [mem 0xdb86d000-0xdba6cfff] type 20
[0.00] BIOS-e820: [mem 0xdba6d000-0xdcdc5fff] reserved
[0.00] BIOS-e820: [mem 0xdcdc6000-0xdce15fff] ACPI NVS
[0.00] BIOS-e820: [mem 0xdce16000-0xdce7efff] reserved
[0.00] BIOS-e820: [mem 0xdce7f000-0xdcf7efff] ACPI NVS
[0.00] BIOS-e820: [mem 0xdcf7f000-0xdcffefff] ACPI data
[0.00] BIOS-e820: [mem 0xdcfff000-0xdcff] usable
[0.00] BIOS-e820: [mem 0xdd00-0xdf9f] reserved
[0.00] BIOS-e820: [mem 0xf80f8000-0xf80f8fff] reserved
[0.00] BIOS-e820: [mem 0xfe101000-0xfe112fff] reserved
[0.00] BIOS-e820: [mem 0xfed1c000-0xfed1] reserved
[0.00] BIOS-e820: [mem 0x0001-0x00021f5f] usable
[0.00] NX (Execute Disable) protection: active
[0.00] efi: EFI v2.31 by Lenovo
[0.00] efi:  ACPI=0xdcffe000  ACPI 2.0=0xdcffe014  SMBIOS=0xdce17000 
[0.00] SMBIOS 2.7 present.
[0.00] DMI: LENOVO 20CD0035GE/20CD0035GE, BIOS GQET49WW (1.29 ) 
04/29/2016
[0.00] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.00] e820: remove [mem 0x000a-0x000f] usable
[0.00] e820: last_pfn = 0x21f600 max_arch_pfn = 0x4
[0.00] MTRR default type: write-back
[0.00] MTRR fixed ranges enabled:
[0.00]   0-9 write-back
[0.00]   A-B uncachable
[0.00]   C-F write-protect
[0.00] MTRR variable ranges enabled:
[0.00]   0 base 00E000 mask 7FE000 uncachable
[0.00]   1 base 00DE00 mask 7FFE00 uncachable
[0.00]   2 base 00DD00 mask 7FFF00 uncachable
[0.00]   3 disabled
[0.00]   4 disabled
[0.00]   5 disabled
[0.00]   6 disabled
[0.00]   7 disabled
[0.00]   8 disabled
[0.00]   9 disabled
[0.00] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WC  UC- WT  
[0.00] e820: last_pfn = 0xdd000 max_arch_pfn = 0x4
[0.00] Base memory trampoline at [88096000] 96000 size 24576
[0.00] Using GB pages for direct mapping
[0.00] BRK [0x01b39000, 0x01b39fff] PGTABLE
[0.00] BRK [0x01b3a000, 0x01b3afff] PGTABLE
[0.00] BRK [0x01b3b000, 0x01b3bfff] PGTABLE
[0.00] BRK [0x01b3c000, 0x01b3cfff] PGTABLE
[0.00] BRK [0x01b3d000, 0x01b3dfff] PGTABLE
[0.00] BRK [0x01b3e000, 0x01b3efff] PGTABLE
[0.00] RAMDISK: [mem 0x3580a000-0x36bfcfff]
[0.00] ACPI: Early table checksum verification disabled
[0.00] ACPI: RSDP 0xDCFFE014 24 (v02 LENOVO)
[0.00] ACPI: XSDT 0xDCFFE170 B4 (v01 LENOVO TP-GQ
1290 PTEC 0002)
[0.00] ACPI: FACP 

Re: [PATCH v3 1/2] mfd: ti-smusbdig: Add support for the TI SM-USB-DIG

[Andrew F. Davis]

On 06/15/2016 10:43 AM, Lee Jones wrote:
> This requires a USB Ack.
> 
>> The TI SM-USB-DIG is a USB to SPI/I2C/1Wire/GPIO adapter.
>> Add MFD core support.
>>
>> Signed-off-by: Andrew F. Davis 
>> ---
> 
> Where is the change log from v1 => v2?
> 

Looking at a diff of the two it looks like all the changes are related
to your v1 feedback:

 - Rename sm-usb-dig -> ti-smusbdig
 - Inline helper functions in header
 - Alphabetize includes

>> Changes from v2:
>>  - Add missing dependency on USB, thanks kbuild test robot
>>
>>  drivers/mfd/Kconfig |   9 +++
>>  drivers/mfd/Makefile|   2 +
>>  drivers/mfd/ti-smusbdig.c   | 138 
>> 
>>  include/linux/mfd/ti-smusbdig.h |  75 ++
>>  4 files changed, 224 insertions(+)
>>  create mode 100644 drivers/mfd/ti-smusbdig.c
>>  create mode 100644 include/linux/mfd/ti-smusbdig.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: Reset hanging Huawei USB-2.0 Internet stick

[Alan Stern]

On Wed, 15 Jun 2016, Sedat Dilek wrote:

> Hi Alan,
> 
> I updated my usb-ids on my Ubuntu 12.04 LTS (AMD64).
> Background was my ASMedia ASM-104x USB-3.0 controller/hub shows no
> human-readable vendor-string etc.
> 
> While checking parallelelly a new usbutils release, I saw your
> "usbreset" example program in the corresponding GitHub repo [1].
> 
> Sometimes my Internet connection does not get established and I do not
> want to plug-off it from my hardware (usb-2 port).
> I hope your usbrest program can do the trick software-technically.
> 
> So how do I reset my Internet stick?
> 
> $ lsusb | grep -i huawei
> Bus 001 Device 005: ID 12d1:1436 Huawei Technologies Co., Ltd. Broadband stick
> 
> [ Excerpts from my dmesg-outputs ]
> 
> [   22.352232] cdc_ether 1-1.2:1.1 wwan0: register 'cdc_ether' at
> usb-:00:1a.0-1.2, Mobile Broadband Network Device,
> 02:50:f3:00:00:00
> [   22.395891] option 1-1.2:1.0: GSM modem (1-port) converter detected
> [   22.399676] usb 1-1.2: GSM modem (1-port) converter now attached to ttyUSB0
> [   22.37] option 1-1.2:1.3: GSM modem (1-port) converter detected
> [   22.400557] usb 1-1.2: GSM modem (1-port) converter now attached to ttyUSB1
> [   22.400639] option 1-1.2:1.4: GSM modem (1-port) converter detected
> [   22.401041] usb 1-1.2: GSM modem (1-port) converter now attached to ttyUSB2
> 
> Not sure how to usbreset - all three /dev/ttyUSB[0-2] ?
> 
> $ sudo ./usbreset $DEVFN
> Usage: usbreset device-filename
> 
> If you need more informations if my attached linux-config,
> dmesg-output and 'lsusb -vvv' outputs don't help, please let me know.

sudo ./usbreset /dev/bus/usb/001/005

001 and 005 are the Bus and Device numbers from the lsusb output.

Alan Stern

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

Re: [PATCH v5 2/2] phy: rockchip-inno-usb2: add a new driver for Rockchip usb2phy

[Guenter Roeck]

On Tue, Jun 14, 2016 at 6:14 PM, Frank Wang  wrote:
> Hi Heiko & Guenter,
>
>
> On 2016/6/14 22:00, Heiko Stübner wrote:
>>
>> Am Dienstag, 14. Juni 2016, 06:50:31 schrieb Guenter Roeck:
>>>
>>> On Tue, Jun 14, 2016 at 6:27 AM, Heiko Stübner  wrote:

 Am Montag, 13. Juni 2016, 10:10:10 schrieb Frank Wang:
>
> The newer SoCs (rk3366, rk3399) take a different usb-phy IP block
> than rk3288 and before, and most of phy-related registers are also
> different from the past, so a new phy driver is required necessarily.
>
> Signed-off-by: Frank Wang 
> ---
>>
>> [...]
>>
> +static int rockchip_usb2phy_init(struct phy *phy)
> +{
> + struct rockchip_usb2phy_port *rport = phy_get_drvdata(phy);
> + struct rockchip_usb2phy *rphy = dev_get_drvdata(phy->dev.parent);
> + int ret;
> +
>
  if (!rport->port_cfg)
   return 0;

 Otherwise the currently empty otg-port will cause null-pointer
 dereferences
 when it gets assigned in the devicetree already.
>>>
>>> Not really, at least not here - that port should not have port_id set
>>> to USB2PHY_PORT_HOST.
>>>
>>> Does it even make sense to instantiate the otg port ? Is it going to
>>> do anything without port configuration ?
>>
>> Ok, that would be the other option - not creating the phy in the driver.
>
>
> Well, I will put this conditional inside *_host_port_init(), if it is an
> empty, the phy-device should not be created.
> Something like the following:
>
> --- a/drivers/phy/phy-rockchip-inno-usb2.c
> +++ b/drivers/phy/phy-rockchip-inno-usb2.c
> @@ -483,9 +483,13 @@ static int rockchip_usb2phy_host_port_init(struct
> rockchip_usb2phy *rphy,
>  {
> int ret;
>
> -   rport->port_id = USB2PHY_PORT_HOST;
> rport->port_cfg = >phy_cfg->port_cfgs[USB2PHY_PORT_HOST];
> +   if (!rport->port_cfg) {
> +   dev_err(rphy->dev, "no host port-config provided.\n");
> +   return -EINVAL;
> +   }

This would never be NULL. At issue is that you don't assign port_cfg
if the port is _not_ a host port.

Guenter

>
> +   rport->port_id = USB2PHY_PORT_HOST;
>
>> Or from what I've seen, handling it as similar to the host-port should
>> work
>> initially as well most likely, supplying the additional otg-parts later
>> on.
>
>
> @Guenter, just as Heiko said, the otg-parts is not ready now, it will be
> supplied later.
>
>
> BR.
> Frank
>
--
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: [TESTPATCH] xhci: usb2 hw lpm extra debug

[Christian M . Amsüss]

On Wed, Jun 15, 2016 at 05:32:11PM +0200, chrysn wrote:
> I've only spotted one of your debug statements in the resulting dmesg
> ("USB2 LPM capable set, port 4 speed 2"), which confuses me, given that
> at least the `portnum %d > num_usb2_ports` line should have shown up
> (the equivalent debug statement from my original patch does show up when
> rmmod'ing there) -- can you make heads or tails of it?

Reviewing the patches, that was because the invalid port_num is used in
`readl(pm_addr)` already, too early for your `portnum %d >
num_usb2_ports` debug line. I'm shoving the line up to make it out
before the segfault, and will report back when I've found the time to
reboot.

Best regards
chrysn

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom


signature.asc
Description: PGP signature

Re: [PATCH v3 1/2] mfd: ti-smusbdig: Add support for the TI SM-USB-DIG

[Lee Jones]

This requires a USB Ack.

> The TI SM-USB-DIG is a USB to SPI/I2C/1Wire/GPIO adapter.
> Add MFD core support.
> 
> Signed-off-by: Andrew F. Davis 
> ---

Where is the change log from v1 => v2?

> Changes from v2:
>  - Add missing dependency on USB, thanks kbuild test robot
> 
>  drivers/mfd/Kconfig |   9 +++
>  drivers/mfd/Makefile|   2 +
>  drivers/mfd/ti-smusbdig.c   | 138 
> 
>  include/linux/mfd/ti-smusbdig.h |  75 ++
>  4 files changed, 224 insertions(+)
>  create mode 100644 drivers/mfd/ti-smusbdig.c
>  create mode 100644 include/linux/mfd/ti-smusbdig.h

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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: [TESTPATCH] xhci: usb2 hw lpm extra debug

[Christian M . Amsüss]

Hi,

On Wed, Jun 15, 2016 at 01:56:57PM +0300, Mathias Nyman wrote:
> custom testpatch to show more info about touching usb2 hw lpm
> setting for usb3 devices

Applied, built, booted and hit the oops; most interestingly, the crashes
these days don't get me into the kdump kernel anymore (might be a faulty
setup on my part), but most of the crashes are even survived by the
system (probably because something around the null address is accessed).

I've only spotted one of your debug statements in the resulting dmesg
("USB2 LPM capable set, port 4 speed 2"), which confuses me, given that
at least the `portnum %d > num_usb2_ports` line should have shown up
(the equivalent debug statement from my original patch does show up when
rmmod'ing there) -- can you make heads or tails of it?

Thank you
chrysn

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom


signature.asc
Description: PGP signature

[PATCH] usb: devio, do not warn when allocation fails

[Jiri Slaby]

usbdev_mmap allocates a buffer. The size of the buffer is determined
by a user. So with this code (no need to be root):

int fd = open("/dev/bus/usb/001/001", O_RDONLY);
mmap(NULL, 0x80, PROT_READ, MAP_SHARED, fd, 0);

we can see a warning:

WARNING: CPU: 0 PID: 21771 at ../mm/page_alloc.c:3563 
__alloc_pages_slowpath+0x1036/0x16e0()
...
Call Trace:
 [] ? warn_slowpath_null+0x2e/0x40
 [] ? __alloc_pages_slowpath+0x1036/0x16e0
 [] ? warn_alloc_failed+0x250/0x250
 [] ? get_page_from_freelist+0x75b/0x28b0
 [] ? __alloc_pages_nodemask+0x583/0x6b0
 [] ? __alloc_pages_slowpath+0x16e0/0x16e0
 [] ? dma_generic_alloc_coherent+0x104/0x220
 [] ? hcd_buffer_alloc+0x1d6/0x3e0 [usbcore]
 [] ? hcd_buffer_destroy+0xa0/0xa0 [usbcore]
 [] ? usb_alloc_coherent+0x65/0x90 [usbcore]
 [] ? usbdev_mmap+0x1a5/0x770 [usbcore]
...

Allocations like this one should be marked as __GFP_NOWARN. So do so.

The size could be also clipped by something like:
if (size >= (1 << (MAX_ORDER + PAGE_SHIFT - 1)))
return -ENOMEM;
But I think the overall limit of 16M (by usbfs_increase_memory_usage)
is enough, so that we only silence the warning here.

Signed-off-by: Jiri Slaby 
Cc: Greg Kroah-Hartman 
Cc: Alan Stern 
Cc: Steinar H. Gunderson 
Cc: Markus Rechberger 
Fixes: f7d34b445a (USB: Add support for usbfs zerocopy.)
Cc: 4.6+ 
---
 drivers/usb/core/devio.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/core/devio.c b/drivers/usb/core/devio.c
index e9f5043a2167..472cbcdf7456 100644
--- a/drivers/usb/core/devio.c
+++ b/drivers/usb/core/devio.c
@@ -241,7 +241,8 @@ static int usbdev_mmap(struct file *file, struct 
vm_area_struct *vma)
goto error_decrease_mem;
}
 
-   mem = usb_alloc_coherent(ps->dev, size, GFP_USER, _handle);
+   mem = usb_alloc_coherent(ps->dev, size, GFP_USER | __GFP_NOWARN,
+   _handle);
if (!mem) {
ret = -ENOMEM;
goto error_free_usbm;
-- 
2.9.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: xhci usb serial open/close issue

[shishir tiwari]

Hi Greg,

To debug i have put some printk inside this xhci_handle_event() function

for example:
xhci_handle_event(){
 .

   case TRB_TYPE(TRB_COMPLETION):
  +  printk(KERN_EMERG "TRB_COMPLETION info
:%d",le32_to_cpu(event->event_cmd.flags) & TRB_TYPE_BITMASK);
handle_cmd_completion(xhci, >event_cmd);
break;
case TRB_TYPE(TRB_TRANSFER):
   + printk(KERN_EMERG "TRB_TRANSFER info
:%d",le32_to_cpu(event->event_cmd.flags) & TRB_TYPE_BITMASK);
ret = handle_tx_event(xhci, >trans_event);
if (ret < 0)
xhci->error_bitmask |= 1 << 9;
else
update_ptrs = 0;
break;

}

Now i am not getting any error with the same script .but i need to
give some clarification on this.

What may be the reason that error is not coming now??


Thanks
Shishir




On Wed, Jun 15, 2016 at 5:18 PM, Greg KH  wrote:
> On Wed, Jun 15, 2016 at 11:45:36AM +0530, shishir tiwari wrote:
>> Hi Greg,
>>
>> What kernel version is this?
>> >>>kernel - 3..4.14 ported on ARM custom board.
>
> Ouch that is old and obsolete, can you please try 4.6 and see if the
> same error happens there?  Lots and lots of xhci and other kernel
> changes have happened in the many years since 3.4 was released.  Not
> much we can do about such an old kernel here, sorry.
>
> 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 v9] input: tablet: add Pegasus Notetaker tablet driver

[Martin Kepplinger]

This adds a driver for the Pegasus Notetaker Pen. When connected,
this uses the Pen as an input tablet.

This device was sold in various different brandings, for example
 "Pegasus Mobile Notetaker M210",
 "Genie e-note The Notetaker",
 "Staedtler Digital ballpoint pen 990 01",
 "IRISnotes Express" or
 "NEWLink Digital Note Taker".

Here's an example, so that you know what we are talking about:
http://www.genie-online.de/genie-e-note-2/

https://pegatech.blogspot.com/ seems to be a remaining official resource.

This device can also transfer saved (offline recorded handwritten) data and
there are userspace programs that do this, see https://launchpad.net/m210
(Well, alternatively there are really fast scanners out there :)

It's *really* fun to use as an input tablet though! So let's support this
for everybody.

Signed-off-by: Martin Kepplinger 
---
Hi Dmitry. I append this just in case you want to replace the driver you
took.

revision history

v9 USB PM fixes: https://www.spinics.net/lists/linux-input/msg45058.html
v8 set device mode in open(), not probe()
v7 add usb_driver power management
v6 minor cleanup (thanks Dmitry)
v5 fix various bugs (thanks Oliver and Dmitry)
v4 use normal work queue instead of a kernel thread (thanks to Oliver Neukum)
v3 fix reporting low pen battery and add USB list to CC
v2 minor cleanup (remove unnecessary variables)
v1 initial release


 drivers/input/tablet/Kconfig |  15 ++
 drivers/input/tablet/Makefile|   1 +
 drivers/input/tablet/pegasus_notetaker.c | 413 +++
 3 files changed, 429 insertions(+)
 create mode 100644 drivers/input/tablet/pegasus_notetaker.c

diff --git a/drivers/input/tablet/Kconfig b/drivers/input/tablet/Kconfig
index 623bb9e..a2b9f97 100644
--- a/drivers/input/tablet/Kconfig
+++ b/drivers/input/tablet/Kconfig
@@ -73,6 +73,21 @@ config TABLET_USB_KBTAB
  To compile this driver as a module, choose M here: the
  module will be called kbtab.
 
+config TABLET_USB_PEGASUS
+   tristate "Pegasus Mobile Notetaker Pen input tablet support"
+   depends on USB_ARCH_HAS_HCD
+   select USB
+   help
+ Say Y here if you want to use the Pegasus Mobile Notetaker,
+ also known as:
+ Genie e-note The Notetaker,
+ Staedtler Digital ballpoint pen 990 01,
+ IRISnotes Express or
+ NEWLink Digital Note Taker.
+
+ To compile this driver as a module, choose M here: the
+ module will be called pegasus_notetaker.
+
 config TABLET_SERIAL_WACOM4
tristate "Wacom protocol 4 serial tablet support"
select SERIO
diff --git a/drivers/input/tablet/Makefile b/drivers/input/tablet/Makefile
index 2e13010..200fc4e 100644
--- a/drivers/input/tablet/Makefile
+++ b/drivers/input/tablet/Makefile
@@ -8,4 +8,5 @@ obj-$(CONFIG_TABLET_USB_AIPTEK) += aiptek.o
 obj-$(CONFIG_TABLET_USB_GTCO)  += gtco.o
 obj-$(CONFIG_TABLET_USB_HANWANG) += hanwang.o
 obj-$(CONFIG_TABLET_USB_KBTAB) += kbtab.o
+obj-$(CONFIG_TABLET_USB_PEGASUS) += pegasus_notetaker.o
 obj-$(CONFIG_TABLET_SERIAL_WACOM4) += wacom_serial4.o
diff --git a/drivers/input/tablet/pegasus_notetaker.c 
b/drivers/input/tablet/pegasus_notetaker.c
new file mode 100644
index 000..0c000d8
--- /dev/null
+++ b/drivers/input/tablet/pegasus_notetaker.c
@@ -0,0 +1,413 @@
+/*
+ * Pegasus Mobile Notetaker Pen input tablet driver
+ *
+ * Copyright (c) 2016 Martin Kepplinger 
+ */
+
+/*
+ * request packet (control endpoint):
+ * |-|
+ * | Report ID | Nr of bytes | command   |
+ * | (1 byte)  | (1 byte)| (n bytes) |
+ * |-|
+ * | 0x02  | n   |   |
+ * |-|
+ *
+ * data packet after set xy mode command, 0x80 0xb5 0x02 0x01
+ * and pen is in range:
+ *
+ * bytebyte name   value (bits)
+ * 
+ * 0   status  0 1 0 0 0 0 X X
+ * 1   color   0 0 0 0 H 0 S T
+ * 2   X low
+ * 3   X high
+ * 4   Y low
+ * 5   Y high
+ *
+ * X X battery state:
+ * no state reported   0x00
+ * battery low 0x01
+ * battery good0x02
+ *
+ * H   Hovering
+ * S   Switch 1 (pen button)
+ * T   Tip
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+/* USB HID defines */
+#define USB_REQ_GET_REPORT 0x01
+#define USB_REQ_SET_REPORT 0x09
+
+#define USB_VENDOR_ID_PEGASUSTECH  0x0e20
+#define USB_DEVICE_ID_PEGASUS_NOTETAKER_EN100  0x0101
+
+/* device specific defines */
+#define NOTETAKER_REPORT_ID0x02
+#define NOTETAKER_SET_CMD  0x80
+#define NOTETAKER_SET_MODE 0xb5
+
+#define NOTETAKER_LED_MOUSE 0x02
+#define PEN_MODE_XY 0x01
+
+#define SPECIAL_COMMAND0x80
+#define BUTTON_PRESSED 0xb5

Re: Reset hanging Huawei USB-2.0 Internet stick

[Sedat Dilek]

On Wed, Jun 15, 2016 at 1:53 PM, Greg Kroah-Hartman
 wrote:
> On Wed, Jun 15, 2016 at 08:22:44AM +0200, Sedat Dilek wrote:
>> Hi Alan,
>>
>> I updated my usb-ids on my Ubuntu 12.04 LTS (AMD64).
>> Background was my ASMedia ASM-104x USB-3.0 controller/hub shows no
>> human-readable vendor-string etc.
>>
>> While checking parallelelly a new usbutils release, I saw your
>> "usbreset" example program in the corresponding GitHub repo [1].
>>
>> Sometimes my Internet connection does not get established and I do not
>> want to plug-off it from my hardware (usb-2 port).
>> I hope your usbrest program can do the trick software-technically.
>>
>> So how do I reset my Internet stick?
>>
>> $ lsusb | grep -i huawei
>> Bus 001 Device 005: ID 12d1:1436 Huawei Technologies Co., Ltd. Broadband 
>> stick
>>
>> [ Excerpts from my dmesg-outputs ]
>>
>> [   22.352232] cdc_ether 1-1.2:1.1 wwan0: register 'cdc_ether' at
>> usb-:00:1a.0-1.2, Mobile Broadband Network Device,
>> 02:50:f3:00:00:00
>> [   22.395891] option 1-1.2:1.0: GSM modem (1-port) converter detected
>> [   22.399676] usb 1-1.2: GSM modem (1-port) converter now attached to 
>> ttyUSB0
>> [   22.37] option 1-1.2:1.3: GSM modem (1-port) converter detected
>> [   22.400557] usb 1-1.2: GSM modem (1-port) converter now attached to 
>> ttyUSB1
>> [   22.400639] option 1-1.2:1.4: GSM modem (1-port) converter detected
>> [   22.401041] usb 1-1.2: GSM modem (1-port) converter now attached to 
>> ttyUSB2
>>
>> Not sure how to usbreset - all three /dev/ttyUSB[0-2] ?
>
> Nope, you need to point it at your hub.
>
> But be aware that usbreset does not always work, at all, as not all
> hardware hubs support this additional feature.
>
> good luck!
>

Thanks for the feedback.

How do I identify the usb-hub where my Internet stick is plugged in?
IOW, what concrete "device-filename" do I have to pass to usbreset?

- Sedat -
--
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: Reset hanging Huawei USB-2.0 Internet stick

[Greg Kroah-Hartman]

On Wed, Jun 15, 2016 at 08:22:44AM +0200, Sedat Dilek wrote:
> Hi Alan,
> 
> I updated my usb-ids on my Ubuntu 12.04 LTS (AMD64).
> Background was my ASMedia ASM-104x USB-3.0 controller/hub shows no
> human-readable vendor-string etc.
> 
> While checking parallelelly a new usbutils release, I saw your
> "usbreset" example program in the corresponding GitHub repo [1].
> 
> Sometimes my Internet connection does not get established and I do not
> want to plug-off it from my hardware (usb-2 port).
> I hope your usbrest program can do the trick software-technically.
> 
> So how do I reset my Internet stick?
> 
> $ lsusb | grep -i huawei
> Bus 001 Device 005: ID 12d1:1436 Huawei Technologies Co., Ltd. Broadband stick
> 
> [ Excerpts from my dmesg-outputs ]
> 
> [   22.352232] cdc_ether 1-1.2:1.1 wwan0: register 'cdc_ether' at
> usb-:00:1a.0-1.2, Mobile Broadband Network Device,
> 02:50:f3:00:00:00
> [   22.395891] option 1-1.2:1.0: GSM modem (1-port) converter detected
> [   22.399676] usb 1-1.2: GSM modem (1-port) converter now attached to ttyUSB0
> [   22.37] option 1-1.2:1.3: GSM modem (1-port) converter detected
> [   22.400557] usb 1-1.2: GSM modem (1-port) converter now attached to ttyUSB1
> [   22.400639] option 1-1.2:1.4: GSM modem (1-port) converter detected
> [   22.401041] usb 1-1.2: GSM modem (1-port) converter now attached to ttyUSB2
> 
> Not sure how to usbreset - all three /dev/ttyUSB[0-2] ?

Nope, you need to point it at your hub.

But be aware that usbreset does not always work, at all, as not all
hardware hubs support this additional feature.

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: xhci usb serial open/close issue

[Greg KH]

On Wed, Jun 15, 2016 at 11:45:36AM +0530, shishir tiwari wrote:
> Hi Greg,
> 
> What kernel version is this?
> >>>kernel - 3..4.14 ported on ARM custom board.

Ouch that is old and obsolete, can you please try 4.6 and see if the
same error happens there?  Lots and lots of xhci and other kernel
changes have happened in the many years since 3.4 was released.  Not
much we can do about such an old kernel here, sorry.

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 v5 2/2] phy: rockchip-inno-usb2: add a new driver for Rockchip usb2phy

[Frank Wang]

Hi Heiko,

On 2016/6/15 17:04, Heiko Stübner wrote:

Hi Frank,

Am Mittwoch, 15. Juni 2016, 11:23:26 schrieb Frank Wang:

On 2016/6/14 21:27, Heiko Stübner wrote:

Am Montag, 13. Juni 2016, 10:10:10 schrieb Frank Wang:

The newer SoCs (rk3366, rk3399) take a different usb-phy IP block
than rk3288 and before, and most of phy-related registers are also
different from the past, so a new phy driver is required necessarily.

Signed-off-by: Frank Wang 
---

Changes in v5:
   - Added 'reg' in the data block to match the different phy-blocks in
   dt.

Changes in v4:
   - Removed some processes related to 'vbus_host-supply'.

Changes in v3:
   - Resolved the mapping defect between fixed value in driver and the

property in devicetree.

   - Optimized 480m output clock register function.
   - Code cleanup.

Changes in v2:
   - Changed vbus_host operation from gpio to regulator in *_probe.
   - Improved the fault treatment relate to 480m clock register.
   - Cleaned up some meaningless codes in *_clk480m_disable.
   - made more clear the comment of *_sm_work.
   
   drivers/phy/Kconfig  |7 +

   drivers/phy/Makefile |1 +
   drivers/phy/phy-rockchip-inno-usb2.c |  645

++ 3 files changed, 653 insertions(+)

[...]

+
+static int rockchip_usb2phy_exit(struct phy *phy)
+{
+   struct rockchip_usb2phy_port *rport = phy_get_drvdata(phy);
+


if (!rport->port_cfg)

return 0;

+   if (rport->port_id == USB2PHY_PORT_HOST)
+   cancel_delayed_work_sync(>sm_work);
+

you will also need to resume the port here, if it is suspended at this
point, as phy_power_off gets called after phy_exit and would probably
produce clk enable/disable mismatches otherwise.

Hmm, from my personal point of view, when canceling sm_work here, it may
not cause the port goes to suspend, isn't it? besides, clk only prepared
in *_usb2phy_resume(), and unprepared in *_usb2phy_suspend(), so if we
resume port here,  the prepare_count of clk will be increased again, I
am afraid this is not correct, and am I wrong? would you like to tell me
more details?

usb2phy_resume gets called both initially through phy_power_on as well.
So it's on but through the first scheduled work call, might get suspended when
nothing is connected. (clk_enable and clk_disable will run).
If nothing is connected on unload phy_power_off will get called while the
clock actually is still disabled.

So I think it's either resuming on exit, or at least making sure to do nothing
in that case in the phy_power_off callback of the driver.




Well, I got what you mean. I saw phy_power_on() gets called  twice at 
ehci/ohci driver probe time, one is at pdata->power_on(); another is at 
usb_add_hcd(), so after that, the power_count of phy increases to two. 
however, when ehci/ohci driver goes to suspend, there is only once to 
call phy_power_off(), and the power_count of phy decreases to 1, so our 
usb2phy_resume() could not be invoked :-) .


If so, is it still need to care it? How about use suspended member of 
rockchip_usb2phy_port as a conditional to check in *_usb2phy_suspend(), 
if necessary.


BR.
Frank

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

[TESTPATCH] xhci: usb2 hw lpm extra debug

[Mathias Nyman]

custom testpatch to show more info about touching usb2 hw lpm
setting for usb3 devices

not for upstream, just testing

Signed-off-by: Mathias Nyman 
---
 drivers/usb/core/hub.c  | 32 +---
 drivers/usb/host/xhci.c | 11 +++
 2 files changed, 36 insertions(+), 7 deletions(-)

diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index bee1351..14fcd87 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -3201,9 +3201,11 @@ int usb_port_suspend(struct usb_device *udev, 
pm_message_t msg)
}
 
/* disable USB2 hardware LPM */
-   if (udev->usb2_hw_lpm_enabled == 1)
+   if (udev->usb2_hw_lpm_enabled == 1) {
+   if (!udev->usb2_hw_lpm_capable)
+   dev_err(>dev, "USB2 LPM disabling for non-capable 
dev\n");
usb_set_usb2_hardware_lpm(udev, 0);
-
+   }
if (usb_disable_ltm(udev)) {
dev_err(>dev, "Failed to disable LTM before suspend\n.");
status = -ENOMEM;
@@ -4306,6 +4308,9 @@ static void hub_set_initial_usb2_lpm_policy(struct 
usb_device *udev)
if (!udev->usb2_hw_lpm_capable)
return;
 
+   if (udev->speed >= USB_SPEED_SUPER)
+   dev_err(>dev, "USB2 LPM: set initial for SS devic\n");
+
if (hub)
connect_type = hub->ports[udev->portnum - 1]->connect_type;
 
@@ -4648,7 +4653,12 @@ hub_port_init(struct usb_hub *hub, struct usb_device 
*udev, int port1,
hcd->driver->update_device(hcd, udev);
hub_set_initial_usb2_lpm_policy(udev);
 fail:
+
+
if (retval) {
+   if (udev->usb2_hw_lpm_capable)
+   dev_err(>dev, "USB2 LPM %s fails but capable is 
set, speed %d\n",
+   __func__, udev->speed);
hub_port_disable(hub, port1, 0);
update_devnum(udev, devnum);/* for disconnect processing */
}
@@ -4814,11 +4824,13 @@ static void hub_port_connect(struct usb_hub *hub, int 
port1, u16 portstatus,
udev->wusb = hub_is_wusb(hub);
 
/* Devices connected to SuperSpeed hubs are USB 3.0 or later */
-   if (hub_is_superspeed(hub->hdev))
+   if (hub_is_superspeed(hub->hdev)) {
udev->speed = USB_SPEED_SUPER;
-   else
+   if (udev->usb2_hw_lpm_capable)
+   dev_err(>dev, "USB2 LPM capable set for 
fresh SS device\n");
+   } else {
udev->speed = USB_SPEED_UNKNOWN;
-
+   }
choose_devnum(udev);
if (udev->devnum <= 0) {
status = -ENOTCONN; /* Don't retry */
@@ -5444,9 +5456,15 @@ static int usb_reset_and_verify_device(struct usb_device 
*udev)
/* Disable USB2 hardware LPM.
 * It will be re-enabled by the enumeration process.
 */
-   if (udev->usb2_hw_lpm_enabled == 1)
+   if (udev->usb2_hw_lpm_enabled == 1) {
+   if (udev->speed >= USB_SPEED_SUPER)
+   dev_err(>dev, " USB2 LPM %s for SS device\n",
+   __func__);
+   if (!udev->usb2_hw_lpm_capable)
+   dev_err(>dev, " USB2 LPM %s for uncapable 
device\n",
+   __func__);
usb_set_usb2_hardware_lpm(udev, 0);
-
+   }
/* Disable LPM and LTM while we reset the device and reinstall the alt
 * settings.  Device-initiated LPM settings, and system exit latency
 * settings are cleared when the device is reset, so we have to set
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index fa7e1ef..fdda854 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -4137,6 +4137,13 @@ int xhci_set_usb2_hardware_lpm(struct usb_hcd *hcd,
hlpm_addr = port_array[port_num] + PORTHLPMC;
field = le32_to_cpu(udev->bos->ext_cap->bmAttributes);
 
+   if (port_num >= xhci->num_usb2_ports)
+   dev_warn(>dev, "USB2 LPM portnum %d > num_usb2_ports 
%d\n",
+port_num, xhci->num_usb2_ports);
+
+   if (udev->speed >= USB_SPEED_SUPER)
+   dev_warn(>dev, "USB2 LPM for SS device!!\n");
+
xhci_dbg(xhci, "%s port %d USB2 hardware LPM\n",
enable ? "enable" : "disable", port_num + 1);
 
@@ -4247,6 +4254,10 @@ int xhci_update_device(struct usb_hcd *hcd, struct 
usb_device *udev)
xhci_check_usb2_port_capability(
xhci, portnum, XHCI_HLC)) {
udev->usb2_hw_lpm_capable = 1;
+   dev_err(>dev, "USB2 LPM capable set, port %d speed %d\n",
+   portnum, udev->speed);
+   dev_err(>dev, "max usb2 ports %d\n",
+   xhci->num_usb2_ports);

Re: [RESEND PATCH v11 4/4] power: wm831x_power: Support USB charger current limit management

[Lee Jones]

On Mon, 13 Jun 2016, Baolin Wang wrote:

> Integrate with the newly added USB charger interface to limit the current
> we draw from the USB input based on the input device configuration
> identified by the USB stack, allowing us to charge more quickly from high
> current inputs without drawing more current than specified from others.
> 
> Signed-off-by: Mark Brown 
> Signed-off-by: Baolin Wang 
> Acked-by: Lee Jones 
> Acked-by: Charles Keepax 
> Acked-by: Peter Chen 
> Acked-by: Sebastian Reichel 
> ---
>  drivers/power/wm831x_power.c |   69 
> ++
>  include/linux/mfd/wm831x/pdata.h |3 ++

For the MFD change:
  Acked-by: Lee Jones 
  
>  2 files changed, 72 insertions(+)
> 
> diff --git a/drivers/power/wm831x_power.c b/drivers/power/wm831x_power.c
> index 7082301..cef1812 100644
> --- a/drivers/power/wm831x_power.c
> +++ b/drivers/power/wm831x_power.c
> @@ -13,6 +13,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -31,6 +32,8 @@ struct wm831x_power {
>   char usb_name[20];
>   char battery_name[20];
>   bool have_battery;
> + struct usb_charger *usb_charger;
> + struct notifier_block usb_notify;
>  };
>  
>  static int wm831x_power_check_online(struct wm831x *wm831x, int supply,
> @@ -125,6 +128,43 @@ static enum power_supply_property wm831x_usb_props[] = {
>   POWER_SUPPLY_PROP_VOLTAGE_NOW,
>  };
>  
> +/* In milliamps */
> +static const unsigned int wm831x_usb_limits[] = {
> + 0,
> + 2,
> + 100,
> + 500,
> + 900,
> + 1500,
> + 1800,
> + 550,
> +};
> +
> +static int wm831x_usb_limit_change(struct notifier_block *nb,
> +unsigned long limit, void *data)
> +{
> + struct wm831x_power *wm831x_power = container_of(nb,
> +  struct wm831x_power,
> +  usb_notify);
> + unsigned int i, best;
> +
> + /* Find the highest supported limit */
> + best = 0;
> + for (i = 0; i < ARRAY_SIZE(wm831x_usb_limits); i++) {
> + if (limit >= wm831x_usb_limits[i] &&
> + wm831x_usb_limits[best] < wm831x_usb_limits[i])
> + best = i;
> + }
> +
> + dev_dbg(wm831x_power->wm831x->dev,
> + "Limiting USB current to %umA", wm831x_usb_limits[best]);
> +
> + wm831x_set_bits(wm831x_power->wm831x, WM831X_POWER_STATE,
> + WM831X_USB_ILIM_MASK, best);
> +
> + return 0;
> +}
> +
>  /*
>   *   Battery properties
>   */
> @@ -607,8 +647,31 @@ static int wm831x_power_probe(struct platform_device 
> *pdev)
>   }
>   }
>  
> + if (wm831x_pdata && wm831x_pdata->usb_gadget) {
> + power->usb_charger =
> + usb_charger_find_by_name(wm831x_pdata->usb_gadget);
> + if (IS_ERR(power->usb_charger)) {
> + ret = PTR_ERR(power->usb_charger);
> + dev_err(>dev,
> + "Failed to find USB gadget: %d\n", ret);
> + goto err_bat_irq;
> + }
> +
> + power->usb_notify.notifier_call = wm831x_usb_limit_change;
> +
> + ret = usb_charger_register_notify(power->usb_charger,
> +   >usb_notify);
> + if (ret != 0) {
> + dev_err(>dev,
> + "Failed to register notifier: %d\n", ret);
> + goto err_usb_charger;
> + }
> + }
> +
>   return ret;
>  
> +err_usb_charger:
> + /* put_device on charger */
>  err_bat_irq:
>   --i;
>   for (; i >= 0; i--) {
> @@ -637,6 +700,12 @@ static int wm831x_power_remove(struct platform_device 
> *pdev)
>   struct wm831x *wm831x = wm831x_power->wm831x;
>   int irq, i;
>  
> + if (wm831x_power->usb_charger) {
> + usb_charger_unregister_notify(wm831x_power->usb_charger,
> +   _power->usb_notify);
> + /* Free charger */
> + }
> +
>   for (i = 0; i < ARRAY_SIZE(wm831x_bat_irqs); i++) {
>   irq = wm831x_irq(wm831x, 
>platform_get_irq_byname(pdev,
> diff --git a/include/linux/mfd/wm831x/pdata.h 
> b/include/linux/mfd/wm831x/pdata.h
> index dcc9631..5af8399 100644
> --- a/include/linux/mfd/wm831x/pdata.h
> +++ b/include/linux/mfd/wm831x/pdata.h
> @@ -126,6 +126,9 @@ struct wm831x_pdata {
>   /** The driver should initiate a power off sequence during shutdown */
>   bool soft_shutdown;
>  
> + /** 

Re: [PATCH v5 2/2] phy: rockchip-inno-usb2: add a new driver for Rockchip usb2phy

[Heiko Stübner]

Hi Frank,

Am Mittwoch, 15. Juni 2016, 11:23:26 schrieb Frank Wang:
> On 2016/6/14 21:27, Heiko Stübner wrote:
> > Am Montag, 13. Juni 2016, 10:10:10 schrieb Frank Wang:
> >> The newer SoCs (rk3366, rk3399) take a different usb-phy IP block
> >> than rk3288 and before, and most of phy-related registers are also
> >> different from the past, so a new phy driver is required necessarily.
> >> 
> >> Signed-off-by: Frank Wang 
> >> ---
> >> 
> >> Changes in v5:
> >>   - Added 'reg' in the data block to match the different phy-blocks in
> >>   dt.
> >> 
> >> Changes in v4:
> >>   - Removed some processes related to 'vbus_host-supply'.
> >> 
> >> Changes in v3:
> >>   - Resolved the mapping defect between fixed value in driver and the
> >> 
> >> property in devicetree.
> >> 
> >>   - Optimized 480m output clock register function.
> >>   - Code cleanup.
> >> 
> >> Changes in v2:
> >>   - Changed vbus_host operation from gpio to regulator in *_probe.
> >>   - Improved the fault treatment relate to 480m clock register.
> >>   - Cleaned up some meaningless codes in *_clk480m_disable.
> >>   - made more clear the comment of *_sm_work.
> >>   
> >>   drivers/phy/Kconfig  |7 +
> >>   drivers/phy/Makefile |1 +
> >>   drivers/phy/phy-rockchip-inno-usb2.c |  645
> >> 
> >> ++ 3 files changed, 653 insertions(+)
> >> 
> >> [...]
> >> 
> >> +
> >> +static int rockchip_usb2phy_exit(struct phy *phy)
> >> +{
> >> +  struct rockchip_usb2phy_port *rport = phy_get_drvdata(phy);
> >> +
> >> 
> > if (!rport->port_cfg)
> > 
> > return 0;
> >> 
> >> +  if (rport->port_id == USB2PHY_PORT_HOST)
> >> +  cancel_delayed_work_sync(>sm_work);
> >> +
> > 
> > you will also need to resume the port here, if it is suspended at this
> > point, as phy_power_off gets called after phy_exit and would probably
> > produce clk enable/disable mismatches otherwise.
> 
> Hmm, from my personal point of view, when canceling sm_work here, it may
> not cause the port goes to suspend, isn't it? besides, clk only prepared
> in *_usb2phy_resume(), and unprepared in *_usb2phy_suspend(), so if we
> resume port here,  the prepare_count of clk will be increased again, I
> am afraid this is not correct, and am I wrong? would you like to tell me
> more details?

usb2phy_resume gets called both initially through phy_power_on as well.
So it's on but through the first scheduled work call, might get suspended when 
nothing is connected. (clk_enable and clk_disable will run).
If nothing is connected on unload phy_power_off will get called while the 
clock actually is still disabled.

So I think it's either resuming on exit, or at least making sure to do nothing 
in that case in the phy_power_off callback of the driver.


--
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] hid: migrate Riso Kagaku LED driver from USB misc to HID

[Benjamin Tissoires]

On Jun 15 2016 or thereabouts, Heiner Kallweit wrote:
> Am 14.06.2016 um 23:49 schrieb Benjamin Tissoires:
> > On Jun 12 2016 or thereabouts, Heiner Kallweit wrote:
> >> The Riso Kagaku Webmail Notifier (and its clones) is supported as part of
> >> usb/misc/usbled driver currently. This patch migrates the driver for this
> >> device to the HID subsystem.
> >>
> >> Benefits:
> >> - Avoid using USB low-level calls and use the HID subsystem instead
> >>   (as this device provides a USB HID interface)
> >> - Use standard LED subsystem instead of proprietary sysfs entries,
> >>   this allows e.g. to use the device with features like triggers
> >>
> >> I know at least one cheap clone coming with green and blue LED switched.
> >> There's a module paramater to deal with this.
> >>
> >> There might be users of the current module, therefore so far allow
> >> compilation of the new driver only if the old one is disabled.
> >>
> >> Signed-off-by: Heiner Kallweit 
> >> ---
> >> v2:
> >> - change config symbol from HID_RIKA to HID_RISO_KAGAKU
> >> - use full name Riso Kagaku instead of rika in several places
> >> - don't remove device from ignore list if CONFIG_USB_LED is defined
> >> - fix module parameter permissions
> > 
> > Thanks for the respin. This version (and the other for hid-rika) looks
> > fine. Though I wonder if you should not call hid_hw_open() at the end of
> > probe (and hid_hw_close() during remove) to keep the device opened.
> > Otherwise I am unsure whether your usb commands will get treated (I
> > might be wrong).
> > 
> When looking at other hid device drivers hid_hw_open seems to be needed
> only if the device needs special treatment.

Not exactly. hid_hw_open is called whenever someone opens the hidraw or
input node (or any other resource attached to the HID device). This
starts the input reading, but also calls usb_autopm_get_interface()
which will prevent the device to be autosuspended. The drivers that call
hid_hw_open() in their probe are the ones where we know no one will open
the hidraw or input node but we need to poll for events.

> My Riso Kagaku and Dream Cheeky devices work fine with the new drivers
> w/o calling hid_hw_open.

Let's keep it that way then.

> 
> > There is also one high level comment I would like to do:
> > even if your driver is better than usbled.c, people won't use it because
> > distributions won't enable it as there is 2 issues:
> > - one is you are breaking kernel ABI (we already discussed it)
> > - the other one is that if people want to use your new hid drivers, they
> >   have to disable CONFIG_USB_LED, which removes support of the
> >   DELCOM_VISUAL_SIGNAL_INDICATOR
> > 
> Yes, I think you're right.
> With regard to the Delcom Visual Signal Indicator:
> The old USB LED driver supports only generation 1 of these devices which
> have a not fully HID compliant interface.
> In 2008 they were replace with generation 2 which has fully a HID
> compliant interface. Generation 2 is not yet supported by the kernel.
> (Currently I'm trying to get hold of such a device.)
> 
> Therefore it might be better to leave support for the Gen 1 Delcom device
> at USB misc. However this would mean that we have to change the config
> symbol for this driver so that it doesn't conflict with the other part
> we're moving to hid.
> Would changing the config symbol be an issue? For now we could select
> the new config symbol automatically if CONFIG_USB_LED is set.

Why would you change the old config symbol for the existing devices. If
(and I don't think that's the best option) you were to add a new symbol,
you could use this to select between HID and USB for the new drivers:
CONFIG_USB_LED_LEGACY_SUPPORT would depend on CONFIG_USB_LED, and you
choose to enable the HID driver based on CONFIG_USB_LED_LEGACY_SUPPORT.

> 
> > I really think it would not cost too much to do the whole change in 2
> > passes:
> > - move the entire usbled to hid, keeping the old sysfs API in place, and
> >   eventually add a symlink from the old place (under the usb device) to
> >   the HID device to keep path stable
> 
> I guess you don't mean symlink literally but adding a comment in Kconfig
> that the driver was moved?

No. I'd rather not having the files moved around when they are KABI. So
either you add the old sysfs files directly at the same level, or you
symlink to them. Some HID driver already take a pointer to the
underlying USB device, so you can do the same.

> 
> > - then add support for the classdev for the whole 3 types of devices
> > 
> > Plus that would means only one driver to maintain instead of 3 that are
> > close enough.
> > 
> > Cheers,
> > Benjamin
> > 
> Regards, Heiner
> 

Cheers,
Benjamin
--
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 v10 03/14] usb: hcd.h: Add OTG to HCD interface

[Roger Quadros]

On 14/06/16 17:21, Alan Stern wrote:
> On Tue, 14 Jun 2016, Roger Quadros wrote:
> 
>> +Alan
>>
>> On 10/06/16 16:07, Roger Quadros wrote:
>>> The OTG core will use struct otg_hcd_ops to interface
>>> with the HCD (Host Controller Driver).
>>>
>>> The main purpose of this interface is to avoid directly
>>> calling HCD APIs from the OTG core as they
>>> wouldn't be defined in the built-in symbol table if
>>> CONFIG_USB is m.
>>>
>>> Signed-off-by: Roger Quadros 
>>> Acked-by: Peter Chen 
>>> ---
>>>  include/linux/usb/hcd.h | 24 
>>>  1 file changed, 24 insertions(+)
>>>
>>> diff --git a/include/linux/usb/hcd.h b/include/linux/usb/hcd.h
>>> index 66fc137..7729c1f 100644
>>> --- a/include/linux/usb/hcd.h
>>> +++ b/include/linux/usb/hcd.h
>>> @@ -400,6 +400,30 @@ struct hc_driver {
>>>  
>>>  };
>>>  
>>> +/**
>>> + * struct otg_hcd_ops - Interface between OTG core and HCD
>>> + *
>>> + * Provided by the HCD core to allow the OTG core to interface with the HCD
> 
> Add:  * in case the OTG core is built-in and the HCD core is built as a 
> module.

OK.

> 
> Otherwise, for patches 1, 3, and 12:
> 
> Acked-by: Alan Stern 
> 

Thanks.

cheers,
-roger
--
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: xhci usb serial open/close issue

[shishir tiwari]

Hi Greg,

What kernel version is this?
>>>kernel - 3..4.14 ported on ARM custom board.

Are there any kernel logs showing any errors?
>> no error log showing
>> we are just waiting for  '#' prompt using chat command and comparing the 
>> result and printing "OK" in success case and "ERROR" in failure
>> Command :
  # usb-serial test sub-shell
  (
stty -F /dev/ttyUSB0 115200 -echo -echoe -echok -onlcr -icrnl
exec >/dev/ttyUSB0
exec >> no flow control is used

Thanks
Shishir


On Tue, Jun 14, 2016 at 9:17 PM, Greg KH  wrote:
> On Tue, Jun 14, 2016 at 08:27:30PM +0530, shishir tiwari wrote:
>> Hi ,
>>
>> We are trying to open and close ttyUSB0 port and using 'chat' command
>> to communicate in while loop using shell script.but after 30-40 times
>> '#' reply is not coming for 'ls' command.
>>
>> shell script::
>> while
>> (
>> stty -F /dev/ttyUSB0 115200 -echo
>> exec > /dev/ttyUSB0
>> exec < /dev/ttyUSB0
>> chat '' ls '#'
>> )
>> result =$?
>>
>> platform : custom
>> serial driver : pl2303
>> host controller :xhci
>
> What kernel version is this?  Are there any kernel logs showing any
> errors?  What flow control have you set for this serial port?
>
> 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 v2] hid: migrate Riso Kagaku LED driver from USB misc to HID

[Heiner Kallweit]

Am 14.06.2016 um 23:49 schrieb Benjamin Tissoires:
> On Jun 12 2016 or thereabouts, Heiner Kallweit wrote:
>> The Riso Kagaku Webmail Notifier (and its clones) is supported as part of
>> usb/misc/usbled driver currently. This patch migrates the driver for this
>> device to the HID subsystem.
>>
>> Benefits:
>> - Avoid using USB low-level calls and use the HID subsystem instead
>>   (as this device provides a USB HID interface)
>> - Use standard LED subsystem instead of proprietary sysfs entries,
>>   this allows e.g. to use the device with features like triggers
>>
>> I know at least one cheap clone coming with green and blue LED switched.
>> There's a module paramater to deal with this.
>>
>> There might be users of the current module, therefore so far allow
>> compilation of the new driver only if the old one is disabled.
>>
>> Signed-off-by: Heiner Kallweit 
>> ---
>> v2:
>> - change config symbol from HID_RIKA to HID_RISO_KAGAKU
>> - use full name Riso Kagaku instead of rika in several places
>> - don't remove device from ignore list if CONFIG_USB_LED is defined
>> - fix module parameter permissions
> 
> Thanks for the respin. This version (and the other for hid-rika) looks
> fine. Though I wonder if you should not call hid_hw_open() at the end of
> probe (and hid_hw_close() during remove) to keep the device opened.
> Otherwise I am unsure whether your usb commands will get treated (I
> might be wrong).
> 
When looking at other hid device drivers hid_hw_open seems to be needed
only if the device needs special treatment.
My Riso Kagaku and Dream Cheeky devices work fine with the new drivers
w/o calling hid_hw_open.

> There is also one high level comment I would like to do:
> even if your driver is better than usbled.c, people won't use it because
> distributions won't enable it as there is 2 issues:
> - one is you are breaking kernel ABI (we already discussed it)
> - the other one is that if people want to use your new hid drivers, they
>   have to disable CONFIG_USB_LED, which removes support of the
>   DELCOM_VISUAL_SIGNAL_INDICATOR
> 
Yes, I think you're right.
With regard to the Delcom Visual Signal Indicator:
The old USB LED driver supports only generation 1 of these devices which
have a not fully HID compliant interface.
In 2008 they were replace with generation 2 which has fully a HID
compliant interface. Generation 2 is not yet supported by the kernel.
(Currently I'm trying to get hold of such a device.)

Therefore it might be better to leave support for the Gen 1 Delcom device
at USB misc. However this would mean that we have to change the config
symbol for this driver so that it doesn't conflict with the other part
we're moving to hid.
Would changing the config symbol be an issue? For now we could select
the new config symbol automatically if CONFIG_USB_LED is set.

> I really think it would not cost too much to do the whole change in 2
> passes:
> - move the entire usbled to hid, keeping the old sysfs API in place, and
>   eventually add a symlink from the old place (under the usb device) to
>   the HID device to keep path stable

I guess you don't mean symlink literally but adding a comment in Kconfig
that the driver was moved?

> - then add support for the classdev for the whole 3 types of devices
> 
> Plus that would means only one driver to maintain instead of 3 that are
> close enough.
> 
> Cheers,
> Benjamin
> 
Regards, Heiner

>> ---
>>  drivers/hid/Kconfig   |   9 +++
>>  drivers/hid/Makefile  |   1 +
>>  drivers/hid/hid-core.c|   3 +
>>  drivers/hid/hid-riso-kagaku.c | 171 
>> ++
>>  4 files changed, 184 insertions(+)
>>  create mode 100644 drivers/hid/hid-riso-kagaku.c
>>
>> diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
>> index 5646ca4..16fe27d 100644
>> --- a/drivers/hid/Kconfig
>> +++ b/drivers/hid/Kconfig
>> @@ -784,6 +784,15 @@ config HID_HYPERV_MOUSE
>>  ---help---
>>  Select this option to enable the Hyper-V mouse driver.
>>  
>> +config HID_RISO_KAGAKU
>> +tristate "Riso Kagaku Webmail Notifier USB LED"
>> +depends on HID
>> +depends on LEDS_CLASS
>> +depends on USB_LED = 'n'
>> +---help---
>> +Support for the Riso Kagaku Webmail Notifier. This driver registers
>> +a LED class instance for red, green, and blue color component.
>> +
>>  config HID_SMARTJOYPLUS
>>  tristate "SmartJoy PLUS PS2/USB adapter support"
>>  depends on HID
>> diff --git a/drivers/hid/Makefile b/drivers/hid/Makefile
>> index a2fb562..90300f3 100644
>> --- a/drivers/hid/Makefile
>> +++ b/drivers/hid/Makefile
>> @@ -91,6 +91,7 @@ obj-$(CONFIG_HID_STEELSERIES)  += hid-steelseries.o
>>  obj-$(CONFIG_HID_SUNPLUS)   += hid-sunplus.o
>>  obj-$(CONFIG_HID_GREENASIA) += hid-gaff.o
>>  obj-$(CONFIG_HID_THINGM)+= hid-thingm.o
>> +obj-$(CONFIG_HID_RISO_KAGAKU)   += hid-riso-kagaku.o
>>  obj-$(CONFIG_HID_THRUSTMASTER)  += hid-tmff.o
>>  obj-$(CONFIG_HID_TIVO)