[PATCH v3] xhci: Bad Ethernet performance plugged in ASM1042A host
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.
The register we modify is change the behavior
Signed-off-by: Jiahau Chang
---
v3: add define value of setting ASMT write Reg
modify dev_dbg message
use usleep
v2: fix coding format
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..bdf50bf 100644
--- a/drivers/usb/host/pci-quirks.c
+++ b/drivers/usb/host/pci-quirks.c
@@ -77,6 +77,16 @@
#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
+#define ASMT_WRITEREG_CMD 0x10423
+#define ASMT_FLOWCTL_ADDR 0xFA30
+#define ASMT_FLOWCTL_DATA 0xBA
+#define ASMT_PSEUDO_DATA 0
+
/*
* amd_chipset_gen values represent AMD different chipset generations
*/
@@ -412,6 +422,58 @@ void usb_amd_quirk_pll_disable(void)
}
EXPORT_SYMBOL_GPL(usb_amd_quirk_pll_disable);
+void usb_asmedia_modifyflowcontrol(struct pci_dev *pdev)
+{
+ unsigned char value;
+ unsigned long wait_time_count;
+
+ /*check device can accept command*/
+ 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: check_ready ERROR", __func__);
+ goto err_exit;
+ }
+ if ((value & ASMT_CONTROL_WRITE_BIT) == 0)
+ break;
+ wait_time_count--;
+ usleep(50);
+ }
+ if (wait_time_count == 0) {
+ dev_dbg(&pdev->dev, "%s: check_write_ready timeout", __func__);
+ goto err_exit;
+ }
+ /* send command and address to device */
+ pci_write_config_dword(pdev, ASMT_DATA_WRITE0_REG, ASMT_WRITEREG_CMD);
+ pci_write_config_dword(pdev, ASMT_DATA_WRITE1_REG, ASMT_FLOWCTL_ADDR);
+ pci_write_config_byte(pdev, ASMT_CONTROL_REG, ASMT_CONTROL_WRITE_BIT);
+ wait_time_count = 1000;
+ /* wait device receive the data */
+ while (wait_time_count) {
+ pci_read_config_byte(pdev, ASMT_CONTROL_REG, &value);
+ if (value == 0xff) {
+ dev_dbg(&pdev->dev, "%s: wait_ready ERROR", __func__);
+ goto err_exit;
+ }
+ if ((value & ASMT_CONTROL_WRITE_BIT) == 0)
+ break;
+ wait_time_count--;
+ usleep(50);
+ }
+ if (wait_time_count == 0) {
+ dev_dbg(&pdev->dev, "%s: wait_write_ready timeout", __func__);
+ goto err_exit;
+ }
+ /* send data to device */
+ pci_write_config_dword(pdev, ASMT_DATA_WRITE0_REG, ASMT_FLOWCTL_DATA);
+ pci_write_config_dword(pdev, ASMT_DATA_WRITE1_REG, ASMT_PSEUDO_DATA);
+ pci_write_config_byte(pdev, ASMT_CONTROL_REG, ASMT_CONTROL_WRITE_BIT);
+err_exit:
+ return;
+}
+EXPORT_SYMBOL_GPL(usb_asmedia_modifyflowcontrol);
+
void usb_amd_quirk_pll_enable(void)
{
usb_amd_quirk_pll(0);
diff --git a/drivers/usb/host/pci-quirks.h b/drivers/usb/host/pci-quirks.h
index 0222195..6ce1df1 100644
--- a/drivers/usb/host/pci-quirks.h
+++ b/drivers/usb/host/pci-quirks.h
@@ -11,6 +11,7 @@ bool usb_amd_prefetch_quirk(void);
void usb_amd_dev_put(void);
void usb_amd_quirk_pll_disable(void);
void usb_amd_quirk_pll_enable(void);
+void usb_asmedia_modifyflowcontrol(struct pci_dev *pdev);
void usb_enable_intel_xhci_ports(struct pci_dev *xhci_pdev);
void usb_disable_xhci_ports(struct pci_dev *xhci_pdev);
void sb800_prefetch(struct device *dev, int on);
diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index fcf1f3f..fba52f0 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -53,6 +53,7 @@
#define PCI_DEVICE_ID_INTEL_BROXTON_B_XHCI 0x1aa8
#define PCI_DEVICE_ID_INTEL_APL_XHCI 0x5aa8
#define PCI_DEVICE_ID_INTEL_DNV_XHCI 0x19d0
+#define PCI_DEVICE_ID_ASMEDIA_1042A_XHCI 0x1142
static const char hcd_name[] = "xhci_hcd";
@@ -202,6 +203,10 @@ static void xhci_pci_quirks(struct device *dev, struct
xhci_hcd *xhci)
pdev->device == 0x1042)
xhci->quirks |= XHCI_BROKEN_STREAMS;
+ if (p
Re: [PATCH] usb: host: ehci: workaround PME bug on AMD EHCI controller
On Wed, Jun 14, 2017 at 1:28 AM, Bjorn Helgaas wrote: > > The lspci output [1] shows: > > 00:12.0 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB EHCI > Controller (rev 39) (prog-if 20 [EHCI]) > Capabilities: [c0] Power Management version 2 > Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA > PME(D0+,D1+,D2+,D3hot+,D3cold+) > Status: D3 NoSoftRst- PME-Enable+ DSel=0 DScale=0 PME- > Bridge: PM- B3+ > > The device claims it can assert PME# from D3hot. If it can't, that > sounds like a hardware defect that should be addressed with a quirk. > Ideally we would also have a pointer to the AMD hardware erratum. Looks like it's pretty similar to "23 USB Wake on Connect/Disconnect with Low Speed Devices" in [1]. It points to a workaround in appendix A2 from [2]. However it says this bug only effects Low Speed devices, but it actually also happens on High Speed devices. [1] https://support.amd.com/TechDocs/46837.pdf [2] https://support.amd.com/TechDocs/42413.pdf > > Is the following path involved here? > > pci_finish_runtime_suspend > target_state = pci_target_state() > if (device_may_wakup()) > if (dev->pme_support) > ... > pci_set_power_state(..., target_state) Yes, it's involved. > > If so, I would naively expect that a quirk could clear the > PCI_PM_CAP_PME_D3 and PCI_PM_CAP_PME_D3cold bits in dev->pme_support, > and pci_target_state() would then avoid selecting D3 or D3cold. But > I'm not an expert in power management. Clearing those two bits does the trick, thanks for the tip. > > Bjorn > > [1] http://marc.info/?l=linux-usb&m=149570231732519&w=2 -- 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/3] r8152: support new chips
These patches are used to support new chips. Hayes Wang (3): r8152: support new chip 8050 r8152: support RTL8153B r8152: add byte_enable for ocp_read_word function drivers/net/usb/r8152.c | 687 ++-- 1 file changed, 671 insertions(+), 16 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
[PATCH net-next 1/3] r8152: support new chip 8050
The settings of the new chip are the same with RTL8152, except that
its product ID is 0x8050.
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 5a02053..2744405 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -659,6 +659,7 @@ enum rtl_version {
RTL_VER_04,
RTL_VER_05,
RTL_VER_06,
+ RTL_VER_07,
RTL_VER_MAX
};
@@ -4183,6 +4184,7 @@ static int rtl8152_get_coalesce(struct net_device *netdev,
switch (tp->version) {
case RTL_VER_01:
case RTL_VER_02:
+ case RTL_VER_07:
return -EOPNOTSUPP;
default:
break;
@@ -4202,6 +4204,7 @@ static int rtl8152_set_coalesce(struct net_device *netdev,
switch (tp->version) {
case RTL_VER_01:
case RTL_VER_02:
+ case RTL_VER_07:
return -EOPNOTSUPP;
default:
break;
@@ -4301,6 +4304,7 @@ static int rtl8152_change_mtu(struct net_device *dev, int
new_mtu)
switch (tp->version) {
case RTL_VER_01:
case RTL_VER_02:
+ case RTL_VER_07:
dev->mtu = new_mtu;
return 0;
default:
@@ -4370,6 +4374,7 @@ static int rtl_ops_init(struct r8152 *tp)
switch (tp->version) {
case RTL_VER_01:
case RTL_VER_02:
+ case RTL_VER_07:
ops->init = r8152b_init;
ops->enable = rtl8152_enable;
ops->disable= rtl8152_disable;
@@ -4448,6 +4453,9 @@ static u8 rtl_get_version(struct usb_interface *intf)
case 0x5c30:
version = RTL_VER_06;
break;
+ case 0x4800:
+ version = RTL_VER_07;
+ break;
default:
version = RTL_VER_UNKNOWN;
dev_info(&intf->dev, "Unknown version 0x%04x\n", ocp_data);
@@ -4493,6 +4501,7 @@ static int rtl8152_probe(struct usb_interface *intf,
switch (version) {
case RTL_VER_01:
case RTL_VER_02:
+ case RTL_VER_07:
tp->mii.supports_gmii = 0;
break;
default:
@@ -4627,6 +4636,7 @@ static void rtl8152_disconnect(struct usb_interface *intf)
/* table of devices that work with this driver */
static struct usb_device_id rtl8152_table[] = {
+ {REALTEK_USB_DEVICE(VENDOR_ID_REALTEK, 0x8050)},
{REALTEK_USB_DEVICE(VENDOR_ID_REALTEK, 0x8152)},
{REALTEK_USB_DEVICE(VENDOR_ID_REALTEK, 0x8153)},
{REALTEK_USB_DEVICE(VENDOR_ID_MICROSOFT, 0x07ab)},
--
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 3/3] r8152: add byte_enable for ocp_read_word function
Add byte_enable for ocp_read_word() to replace reading 4
bytes data with reading the desired 2 bytes data.
This is used to avoid the issue which is described in
commit b4d99def0938 ("r8152: remove sram_read"). The
original method always reads 4 bytes data, and it may
have problem when reading the PHY registers.
The new method is supported since RTL8153B, but it
doesn't influence the previous chips. The bits of the
byte_enable for the previous chips are the reserved
bits, and the hw would ignore them.
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 4c197da..184b680 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -962,11 +962,13 @@ static u16 ocp_read_word(struct r8152 *tp, u16 type, u16
index)
{
u32 data;
__le32 tmp;
+ u16 byen = BYTE_EN_WORD;
u8 shift = index & 2;
index &= ~3;
+ byen <<= shift;
- generic_ocp_read(tp, index, sizeof(tmp), &tmp, type);
+ generic_ocp_read(tp, index, sizeof(tmp), &tmp, type | byen);
data = __le32_to_cpu(tmp);
data >>= (shift * 8);
--
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/3] r8152: support RTL8153B
This patch supports two new chips for RTL8153B. Signed-off-by: Hayes Wang --- drivers/net/usb/r8152.c | 673 ++-- 1 file changed, 658 insertions(+), 15 deletions(-) diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c index 2744405..4c197da 100644 --- a/drivers/net/usb/r8152.c +++ b/drivers/net/usb/r8152.c @@ -29,7 +29,7 @@ #include /* Information for net-next */ -#define NETNEXT_VERSION"08" +#define NETNEXT_VERSION"09" /* Information for net */ #define NET_VERSION"9" @@ -51,11 +51,14 @@ #define PLA_FMC0xc0b4 #define PLA_CFG_WOL0xc0b6 #define PLA_TEREDO_CFG 0xc0bc +#define PLA_TEREDO_WAKE_BASE 0xc0c4 #define PLA_MAR0xcd00 #define PLA_BACKUP 0xd000 #define PAL_BDC_CR 0xd1a0 #define PLA_TEREDO_TIMER 0xd2cc #define PLA_REALWOW_TIMER 0xd2e8 +#define PLA_EFUSE_DATA 0xdd00 +#define PLA_EFUSE_CMD 0xdd02 #define PLA_LEDSEL 0xdd90 #define PLA_LED_FEATURE0xdd92 #define PLA_PHYAR 0xde00 @@ -105,7 +108,9 @@ #define USB_CSR_DUMMY2 0xb466 #define USB_DEV_STAT 0xb808 #define USB_CONNECT_TIMER 0xcbf8 +#define USB_MSC_TIMER 0xcbfc #define USB_BURST_SIZE 0xcfc0 +#define USB_LPM_CONFIG 0xcfd8 #define USB_USB_CTRL 0xd406 #define USB_PHY_CTRL 0xd408 #define USB_TX_AGG 0xd40a @@ -113,15 +118,20 @@ #define USB_USB_TIMER 0xd428 #define USB_RX_EARLY_TIMEOUT 0xd42c #define USB_RX_EARLY_SIZE 0xd42e -#define USB_PM_CTRL_STATUS 0xd432 +#define USB_PM_CTRL_STATUS 0xd432 /* RTL8153A */ +#define USB_RX_EXTRA_AGGR_TMR 0xd432 /* RTL8153B */ #define USB_TX_DMA 0xd434 +#define USB_UPT_RXDMA_OWN 0xd437 #define USB_TOLERANCE 0xd490 #define USB_LPM_CTRL 0xd41a #define USB_BMU_RESET 0xd4b0 +#define USB_U1U2_TIMER 0xd4da #define USB_UPS_CTRL 0xd800 -#define USB_MISC_0 0xd81a #define USB_POWER_CUT 0xd80a +#define USB_MISC_0 0xd81a #define USB_AFE_CTRL2 0xd824 +#define USB_UPS_CFG0xd842 +#define USB_UPS_FLAGS 0xd848 #define USB_WDT11_CTRL 0xe43c #define USB_BP_BA 0xfc26 #define USB_BP_0 0xfc28 @@ -133,6 +143,15 @@ #define USB_BP_6 0xfc34 #define USB_BP_7 0xfc36 #define USB_BP_EN 0xfc38 +#define USB_BP_8 0xfc38 +#define USB_BP_9 0xfc3a +#define USB_BP_10 0xfc3c +#define USB_BP_11 0xfc3e +#define USB_BP_12 0xfc40 +#define USB_BP_13 0xfc42 +#define USB_BP_14 0xfc44 +#define USB_BP_15 0xfc46 +#define USB_BP2_EN 0xfc48 /* OCP Registers */ #define OCP_ALDPS_CONFIG 0x2010 @@ -143,6 +162,7 @@ #define OCP_EEE_AR 0xa41a #define OCP_EEE_DATA 0xa41c #define OCP_PHY_STATUS 0xa420 +#define OCP_NCTL_CFG 0xa42c #define OCP_POWER_CFG 0xa430 #define OCP_EEE_CFG0xa432 #define OCP_SRAM_ADDR 0xa436 @@ -152,9 +172,14 @@ #define OCP_EEE_ADV0xa5d0 #define OCP_EEE_LPABLE 0xa5d2 #define OCP_PHY_STATE 0xa708 /* nway state for 8153 */ +#define OCP_PHY_PATCH_STAT 0xb800 +#define OCP_PHY_PATCH_CMD 0xb820 +#define OCP_ADC_IOFFSET0xbcfc #define OCP_ADC_CFG0xbc06 +#define OCP_SYSCLK_CFG 0xc416 /* SRAM Register */ +#define SRAM_GREEN_CFG 0x8011 #define SRAM_LPF_CFG 0x8012 #define SRAM_10M_AMP1 0x8080 #define SRAM_10M_AMP2 0x8082 @@ -252,6 +277,10 @@ /* PAL_BDC_CR */ #define ALDPS_PROXY_MODE 0x0001 +/* PLA_EFUSE_CMD */ +#define EFUSE_READ_CMD BIT(15) +#define EFUSE_DATA_BIT16 BIT(7) + /* PLA_CONFIG34 */ #define LINK_ON_WAKE_EN0x0010 #define LINK_OFF_WAKE_EN 0x0008 @@ -277,6 +306,7 @@ /* PLA_MAC_PWR_CTRL2 */ #define EEE_SPDWN_RATIO0x8007 +#define MAC_CLK_SPDWN_EN BIT(15) /* PLA_MAC_PWR_CTRL3 */ #define PKT_AVAIL_SPDWN_EN 0x0100 @@ -328,6 +358,9 @@ #define STAT_SPEED_HIGH0x #define STAT_SPEED_FULL0x0002 +/* USB_LPM_CONFIG */ +#define LPM_U1U2_ENBIT(0) + /* USB_TX_AGG */ #define TX_AGG_MAX_THRESHOLD 0x03 @@ -335,6 +368,7 @@ #define RX_THR_SUPPER 0x0c350180 #define RX_THR_HIGH0x7a120180 #define RX_THR_SLOW0x0180 +#define RX_THR_B 0x00010001 /* USB_TX_DMA */ #define TEST_MODE_DISABLE 0x0001 @@ -344,6 +378,10 @@ #define BMU_RESET_EP_IN0x01 #define BMU_RESET_EP_OUT 0x02 +/* USB_UPT_RXDMA_OWN */ +#define OWN_UPDATE BI
[PATCH v2] usb: host: ohci-pxa27x: Handle return value of clk_prepare_enable
clk_prepare_enable() can fail here and we must check its return value.
Signed-off-by: Arvind Yadav
Changes in v2:
Remove useless initialization of retval.
---
drivers/usb/host/ohci-pxa27x.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/host/ohci-pxa27x.c b/drivers/usb/host/ohci-pxa27x.c
index 79efde8f..21c010f 100644
--- a/drivers/usb/host/ohci-pxa27x.c
+++ b/drivers/usb/host/ohci-pxa27x.c
@@ -274,14 +274,16 @@ static inline void pxa27x_reset_hc(struct pxa27x_ohci
*pxa_ohci)
static int pxa27x_start_hc(struct pxa27x_ohci *pxa_ohci, struct device *dev)
{
- int retval = 0;
+ int retval;
struct pxaohci_platform_data *inf;
uint32_t uhchr;
struct usb_hcd *hcd = dev_get_drvdata(dev);
inf = dev_get_platdata(dev);
- clk_prepare_enable(pxa_ohci->clk);
+ retval = clk_prepare_enable(pxa_ohci->clk);
+ if (retval)
+ return retval;
pxa27x_reset_hc(pxa_ohci);
@@ -296,8 +298,10 @@ static int pxa27x_start_hc(struct pxa27x_ohci *pxa_ohci,
struct device *dev)
if (inf->init)
retval = inf->init(dev);
- if (retval < 0)
+ if (retval < 0) {
+ clk_disable_unprepare(pxa_ohci->clk);
return retval;
+ }
if (cpu_is_pxa3xx())
pxa3xx_u2d_start_hc(&hcd->self);
--
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: Gadget driver ->disconnect callback during unbinding
On Wed, Jun 14, 2017 at 10:26:29AM -0400, Alan Stern wrote:
> On Wed, 14 Jun 2017, Peter Chen wrote:
>
> > On Tue, Jun 13, 2017 at 10:22:26AM -0400, Alan Stern wrote:
> > > On Tue, 13 Jun 2017, Felipe Balbi wrote:
> > >
> > > >
> > > > Hi Alan,
> > > >
> > > > Alan Stern writes:
> > > > > 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().
> > > >
> > > > usb_gadget_disconnect() only calls UDC's ->pullup(), not gadget driver's
> > > > ->disconnect()
> > > >
> > > > int usb_gadget_disconnect(struct usb_gadget *gadget)
> > > > {
> > > > int ret = 0;
> > > >
> > > > if (!gadget->ops->pullup) {
> > > > ret = -EOPNOTSUPP;
> > > > goto out;
> > > > }
> > > >
> > > > if (gadget->deactivated) {
> > > > /*
> > > > * If gadget is deactivated we only save new state.
> > > > * Gadget will stay disconnected after activation.
> > > > */
> > > > gadget->connected = false;
> > > > goto out;
> > > > }
> > > >
> > > > ret = gadget->ops->pullup(gadget, 0);
> > > > if (!ret)
> > > > gadget->connected = 0;
> > > >
> > > > out:
> > > > trace_usb_gadget_disconnect(gadget, ret);
> > > >
> > > > return ret;
> > > > }
> > > > EXPORT_SYMBOL_GPL(usb_gadget_disconnect);
> > >
> > > Yes, but as I mentioned above, the pullup routine calls the gadget
> > > driver's disconnect method.
> > >
> > > > > 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?
> > > >
> > > > Unless I'm missing something, that call is necessary :-) Have you faced
> > > > any issues with it? Are there any UDCs calling gadget driver's
> > > > ->disconnect() from ->pullup() ?
> > >
> > > I haven't faced any issues because gadget drivers don't seem to mind
> > > ->disconnect getting called twice in a row. :-) (And note that the
> > > API doesn't have a corresponding ->connect callback... Although to
> > > tell the truth, it's not clear what a gadget driver needs to do in
> > > either callback. Can we simply remove ->disconnect altogether?)
> > >
> > > Both dummy-hcd and net2280 call ->disconnect from ->pullup. I haven't
> > > checked other UDC drivers, but it seems like something they should all
> > > do. Except perhaps in the case where the UDC driver doesn't have a
> > > pullup method.
> > >
> >
> > No, ->pullup is expected to be called from UDC core, and the UDC core
> > makes sure the coming ->disconnect at kinds of situations.
>
> I think you are wrong. The UDC core calls ->pullup from the
> usb_gadget_disconnect() routine, but it does not call ->disconnect from
> that routine.
>
You may misunderstand my point, I mean there are always ->disconnect
call after ->pullup at UDC core, eg, usb_gadget_remove_driver and
usb_udc_softconn_store. So individual UDC driver does not need
->disconnect at its ->pullup implementation.
> Furthermore, there is an advantage to having the UDC driver call
> ->disconnect from within its ->pullup method: It can retain its private
> spinlock across the ->disconnect call. This will help prevent races.
> For example, what would happen if ->disconnect was called while a
> ->setup callback was in progress? Or vice versa?
>
You mean the private UDC driver spinlock can help prevent races well for
->setup and ->pullup in UDC driver? Yes, it is the good point. I am
wondering why composite_disconnect has spinlock and without for
composite_setup.
--
Best Regards,
Peter Chen
--
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
June 14, 2017
Attn, My name is Johnson King, the principal attorney of my law firm., Johnson King & Co. A deceased client Mr. Henry died in 2010 and left a sum little above US$ 28 million in his account here in Unity Bank Plc. Normally banking procedures requires that the bank declares the account forfeitable and transfer the proceeds to the Registry of Unclaimed Property for government use after 8 years from the time of the death of the deceased client. The present situation made me to contact you given that you and my deceased client share the same last name and nationality which made it favorably disposed towards this proposals to present you as the Cestui Que trust and administrator of the account. It may also interest you to know that the transaction will be executed within the ambit of law and nothing shall be done outside of it.If you are not familiar with estate and probate measures, I shall send further information to you concerning these once i get a positive response. Whereas We will discuss the ratios succinctly and promote them in written signed agreement before commencement. I wish to submit that I would expect nothing less but honesty and transparency. I will uncover to you further information on the matter in our following communications. If this business interests you kindly revert with your direct phone number for further exhaustive phone talk. I look forward to having a good business relationship with you. Yours sincerely, Johnson King & Co -- 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: cdc_mbim problems with Fibocom L831-EAU
> But for the above stuff, note that MBIM modems often (always?) do *not* > support DHCP on the net interface. You'll get best results by reading > the IP configuration using the MBIM protocol and assigning those > details to the device. ModemManager will retrieve those for you, but > it does not do IP configuration, instead leaving that up to something > like NetworkManager or custom scripts. > > mbim-network also does not set the IP configuration for you, since a > lot more is involved than just assigning the IP address to the > interface. (eg, should the DNS servers be written to resolv.conf? > what if something else is managing resolv.conf? Should a default route > be added through the interface? what if something else is managing the > default route or you don't want that to happen?) When I tried it, I disabled everything network-related and set the IP address, net mask, default route and resolv.conf manually based on data from mbimcli. When I tried to ping google.com afterwards it failed due to "System error". -- 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/8] ACPI / PM: Run wakeup notify handlers synchronously
On Wed, Jun 14, 2017 at 8:09 PM, Bjorn Helgaas wrote: > On Mon, Jun 12, 2017 at 10:48:41PM +0200, Rafael J. Wysocki wrote: >> 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 > > Acked-by: Bjorn Helgaas Thanks! -- 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: cdc_mbim problems with Fibocom L831-EAU
Dan Williams writes:
>> The problems seem to be accompanied by `cdc_mbim 1-6:1.0: nonzero urb
>> status received: -EPIPE` in dmesg.
>
> I'll let Bjorn address this specific EPIPE issue.
Thanks, but I'm a bit lost here. I guess it means that we try to read
from the device without any data being available. But I don't see how
that can happen in v4.11.4 since it has the revert of 833415a3e781
("cdc-wdm: fix "out-of-sync" due to missing notifications")
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: host: ehci: workaround PME bug on AMD EHCI controller
On Tue, 13 Jun 2017, Bjorn Helgaas wrote: > [+cc Rafael, linux-pm] > > On Tue, Jun 13, 2017 at 12:21:15PM +0800, Kai-Heng Feng wrote: > > On Mon, Jun 12, 2017 at 10:18 PM, Alan Stern > > wrote: > > > 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. > The lspci output [1] shows: > > 00:12.0 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB EHCI > Controller (rev 39) (prog-if 20 [EHCI]) > Capabilities: [c0] Power Management version 2 > Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA > PME(D0+,D1+,D2+,D3hot+,D3cold+) > Status: D3 NoSoftRst- PME-Enable+ DSel=0 DScale=0 PME- > Bridge: PM- B3+ > > The device claims it can assert PME# from D3hot. If it can't, that > sounds like a hardware defect that should be addressed with a quirk. > Ideally we would also have a pointer to the AMD hardware erratum. > > Is the following path involved here? > > pci_finish_runtime_suspend > target_state = pci_target_state() > if (device_may_wakup()) > if (dev->pme_support) > ... > pci_set_power_state(..., target_state) > > If so, I would naively expect that a quirk could clear the > PCI_PM_CAP_PME_D3 and PCI_PM_CAP_PME_D3cold bits in dev->pme_support, > and pci_target_state() would then avoid selecting D3 or D3cold. But > I'm not an expert in power management. That's a good idea. However, we should apply the quirk only when it is needed. Which means we need to know the numeric values for the PCI IDs. Also, this will help searching for published errata. Kai-Heng, what does "lspci -nvs 00:12.0" show? 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 6/8] PCI / PM: Restore PME Enable if skipping wakeup setup
On Mon, Jun 12, 2017 at 10:53:36PM +0200, Rafael J. Wysocki wrote:
> 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
Acked-by: Bjorn Helgaas
> ---
> 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
Re: [PATCH v2 1/8] ACPI / PM: Run wakeup notify handlers synchronously
On Mon, Jun 12, 2017 at 10:48:41PM +0200, Rafael J. Wysocki wrote:
> 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
Acked-by: Bjorn Helgaas
> ---
> 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_sta
Re: possible xhci bug on linux-next
Hi, (Carlos, please Cc linux-omap on things related to OMAP :-) Mathias Nyman writes: > Adding Felipe, > > First warning is when dwc3_omap requests threaded irq > > On 14.06.2017 16:03, Carlos Hernandez wrote: >> linux-next fails to boot due to what appears to be a xhci bug. Problem >> observed at least on am57xx-evm, dra72x-evm and dra7xx-evm. According to >> Tony Lindgren the issue is marking a shared interrupt disabled on start-up. >> >> [0.00] Booting Linux on physical CPU 0x0 >> [0.00] Linux version 4.12.0-rc5-next-20170613 >> (lcpd...@dflsdit-build06.dal.design.ti.com) (gcc version 6.2.1 20161016 >> (Linaro GCC 6.2-2016.11) ) #2 SMP Tue Jun 13 13:52:56 CDT 2017 >> [0.00] CPU: ARMv7 Processor [412fc0f2] revision 2 (ARMv7), >> cr=10c5387d >> [0.00] CPU: div instructions available: patching division code >> [0.00] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction >> cache >> [0.00] OF: fdt: Machine model: TI AM5728 BeagleBoard-X15 >> [0.00] Memory policy: Data cache writealloc >> [0.00] cma: Reserved 24 MiB at 0xfe00 >> [0.00] OMAP4: Map 0xffd0 to fe60 for dram barrier >> [0.00] DRA752 ES1.1 >> [0.00] percpu: Embedded 17 pages/cpu @eed82000 s40936 r8192 d20504 >> u69632 >> [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total >> pages: 522047 >> [0.00] Kernel command line: console=ttyO2,115200n8 >> earlyprintk=serial,ttyO2,115200n8 rootwait sysrq_always_enabled >> ip=:eth0:dhcp root=/dev/nfs rw >> nfsroot=192.168.0.1:/home/tigtfarm03/NFS_exports/am57xx-evm1//autofs/d3fd317ecf18e621cf951fd5ef72179d,nolock,v3,tcp,rsize=4096,wsize=4096 >> [0.00] sysrq: sysrq always enabled. >> [0.00] PID hash table entries: 4096 (order: 2, 16384 bytes) >> [0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 >> bytes) >> [0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) >> [0.00] Memory: 2025704K/2095100K available (9216K kernel code, 892K >> rwdata, 3176K rodata, 2048K init, 8710K bss, 44820K reserved, 24576K >> cma-reserved, 1284092K highmem) >> [0.00] Virtual kernel memory layout: >> [0.00] vector : 0x - 0x1000 ( 4 kB) >> [0.00] fixmap : 0xffc0 - 0xfff0 (3072 kB) >> [0.00] vmalloc : 0xf080 - 0xff80 ( 240 MB) >> [0.00] lowmem : 0xc000 - 0xf000 ( 768 MB) >> [0.00] pkmap : 0xbfe0 - 0xc000 ( 2 MB) >> [0.00] modules : 0xbf00 - 0xbfe0 ( 14 MB) >> [0.00] .text : 0xc0008000 - 0xc0a0 (10208 kB) >> [0.00] .init : 0xc0e0 - 0xc100 (2048 kB) >> [0.00] .data : 0xc100 - 0xc10df398 ( 893 kB) >> [0.00].bss : 0xc10e90d0 - 0xc196aa80 (8711 kB) >> [0.00] Running RCU self tests >> [0.00] Hierarchical RCU implementation. >> [0.00] RCU event tracing is enabled. >> [0.00] RCU lockdep checking is enabled. >> [0.00] RCU callback double-/use-after-free debug enabled. >> [0.00] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16 >> [0.00] GIC: Using split EOI/Deactivate mode >> [0.00] kmemleak: Kernel memory leak detector disabled >> [0.00] OMAP clockevent source: timer1 at 32786 Hz >> [0.00] arch_timer: cp15 timer(s) running at 6.14MHz (phys). >> [0.00] clocksource: arch_sys_counter: mask: 0xff >> max_cycles: 0x16af5adb9, max_idle_ns: 440795202250 ns >> [0.06] sched_clock: 56 bits at 6MHz, resolution 162ns, wraps every >> 4398046511023ns >> [0.25] Switching to timer-based delay loop, resolution 162ns >> [0.000458] clocksource: 32k_counter: mask: 0x max_cycles: >> 0x, max_idle_ns: 58327039986419 ns >> [0.000474] OMAP clocksource: 32k_counter at 32768 Hz >> [0.001737] Console: colour dummy device 80x30 >> [0.001770] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., >> Ingo Molnar >> [0.001785] ... MAX_LOCKDEP_SUBCLASSES: 8 >> [0.001799] ... MAX_LOCK_DEPTH: 48 >> [0.001813] ... MAX_LOCKDEP_KEYS:8191 >> [0.001826] ... CLASSHASH_SIZE: 4096 >> [0.001840] ... MAX_LOCKDEP_ENTRIES: 32768 >> [0.001854] ... MAX_LOCKDEP_CHAINS: 65536 >> [0.001867] ... CHAINHASH_SIZE: 32768 >> [0.001880] memory used by lock dependency info: 5167 kB >> [0.001894] per task-struct memory footprint: 1536 bytes >> [0.003715] kmemleak: Early log buffer exceeded (9401), please increase >> DEBUG_KMEMLEAK_EARLY_LOG_SIZE >> [0.003751] Calibrating delay loop (skipped), value calculated using >> timer frequency.. 12.29 BogoMIPS (lpj=61475) >> [0.003779] pid_max: default: 32768 minimum: 301 >> [0.004258] Security Framework initialized >> [0.004448]
Re: [PATCH V5 1/2] dt-bindings: leds: document new trigger-sources property
On Thu, Jun 08, 2017 at 06:08:31PM +0200, Rafał Miłecki wrote: > From: Rafał Miłecki > > Some LEDs can be related to a specific device(s) described in the DT. > This property allows specifying such relations. E.g. USB LED should > usually be used to indicate some USB port(s) state. > > Please note this binding is designed to be generic and not influenced by > any operating system design. Linux developers may find "trigger" part a > bit confusing since in Linux triggers are separated drivers. It > shouldn't define the binding though (we shouldn't add an extra level of > indirection). > > Signed-off-by: Rafał Miłecki > --- > V2: Replace "usb-ports" with "led-triggers" property which is more generic and > allows specifying other devices as well. > V3: Use "trigger-sources" which is even more accurate as devices aren't > precisely triggers. > V4: Update example to use the correct property > V5: Document #trigger-source-cells > --- > Documentation/devicetree/bindings/leds/common.txt | 35 > +-- > 1 file changed, 33 insertions(+), 2 deletions(-) Reviewed-by: Rob Herring -- 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: Oddity with EP configuration
On Thu, 15 Jun 2017, Benjamin Herrenschmidt wrote: > On Wed, 2017-06-14 at 10:19 -0400, Alan Stern wrote: > > I think the problem is that you misunderstand how epautoconf is > > intended to work. > > > > I'm not the expert on this stuff -- Felipe is. Still, as best I > > understand, the idea is that a gadget driver or the composite core will > > attempt to allocate all the endpoints for a particular configuration at > > one time, during the gadget's startup. It will then release those > > allocations and move on to allocate the endpoints for the next > > configuration, and so on. At the end, all the allocations have been > > released. > > Yes, you are right and part of the confusion comes from the comment > next to the release call saying that set_alt or a future bind will set > "claimed" again since that's not going to happen. > > My latest message clears that up and proposed various options to handle > this for me. I've also sent an RFC patch adding a hook that I've tested > with simple configs and works. I'll do more testing tomorrow with more > complex setups. I don't have a clear idea of the best approach for this problem. Perhaps Felipe will suggest something. 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] usb: host: ohci-pxa27x: Handle return value of clk_prepare_enable
On Wed, 14 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/ohci-pxa27x.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/host/ohci-pxa27x.c b/drivers/usb/host/ohci-pxa27x.c
> index 79efde8f..c5afdb2 100644
> --- a/drivers/usb/host/ohci-pxa27x.c
> +++ b/drivers/usb/host/ohci-pxa27x.c
> @@ -281,7 +281,9 @@ static int pxa27x_start_hc(struct pxa27x_ohci *pxa_ohci,
> struct device *dev)
>
> inf = dev_get_platdata(dev);
>
> - clk_prepare_enable(pxa_ohci->clk);
> + retval = clk_prepare_enable(pxa_ohci->clk);
> + if (retval)
> + return retval;
You might as well remove the initializer for retval ("int retval = 0;")
because the initial value will always be overwritten here.
>
> pxa27x_reset_hc(pxa_ohci);
>
> @@ -296,8 +298,10 @@ static int pxa27x_start_hc(struct pxa27x_ohci *pxa_ohci,
> struct device *dev)
> if (inf->init)
> retval = inf->init(dev);
>
> - if (retval < 0)
> + if (retval < 0) {
> + clk_disable_unprepare(pxa_ohci->clk);
> return retval;
> + }
>
> if (cpu_is_pxa3xx())
> pxa3xx_u2d_start_hc(&hcd->self);
Aside from that one issue,
Acked-by: Alan Stern
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: Oddity with EP configuration
On Wed, 2017-06-14 at 10:19 -0400, Alan Stern wrote: > I think the problem is that you misunderstand how epautoconf is > intended to work. > > I'm not the expert on this stuff -- Felipe is. Still, as best I > understand, the idea is that a gadget driver or the composite core will > attempt to allocate all the endpoints for a particular configuration at > one time, during the gadget's startup. It will then release those > allocations and move on to allocate the endpoints for the next > configuration, and so on. At the end, all the allocations have been > released. Yes, you are right and part of the confusion comes from the comment next to the release call saying that set_alt or a future bind will set "claimed" again since that's not going to happen. My latest message clears that up and proposed various options to handle this for me. I've also sent an RFC patch adding a hook that I've tested with simple configs and works. I'll do more testing tomorrow with more complex setups. Cheers, Ben. -- 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: Gadget driver ->disconnect callback during unbinding
On Wed, 14 Jun 2017, Peter Chen wrote:
> On Tue, Jun 13, 2017 at 10:22:26AM -0400, Alan Stern wrote:
> > On Tue, 13 Jun 2017, Felipe Balbi wrote:
> >
> > >
> > > Hi Alan,
> > >
> > > Alan Stern writes:
> > > > 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().
> > >
> > > usb_gadget_disconnect() only calls UDC's ->pullup(), not gadget driver's
> > > ->disconnect()
> > >
> > > int usb_gadget_disconnect(struct usb_gadget *gadget)
> > > {
> > > int ret = 0;
> > >
> > > if (!gadget->ops->pullup) {
> > > ret = -EOPNOTSUPP;
> > > goto out;
> > > }
> > >
> > > if (gadget->deactivated) {
> > > /*
> > >* If gadget is deactivated we only save new state.
> > >* Gadget will stay disconnected after activation.
> > >*/
> > > gadget->connected = false;
> > > goto out;
> > > }
> > >
> > > ret = gadget->ops->pullup(gadget, 0);
> > > if (!ret)
> > > gadget->connected = 0;
> > >
> > > out:
> > > trace_usb_gadget_disconnect(gadget, ret);
> > >
> > > return ret;
> > > }
> > > EXPORT_SYMBOL_GPL(usb_gadget_disconnect);
> >
> > Yes, but as I mentioned above, the pullup routine calls the gadget
> > driver's disconnect method.
> >
> > > > 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?
> > >
> > > Unless I'm missing something, that call is necessary :-) Have you faced
> > > any issues with it? Are there any UDCs calling gadget driver's
> > > ->disconnect() from ->pullup() ?
> >
> > I haven't faced any issues because gadget drivers don't seem to mind
> > ->disconnect getting called twice in a row. :-) (And note that the
> > API doesn't have a corresponding ->connect callback... Although to
> > tell the truth, it's not clear what a gadget driver needs to do in
> > either callback. Can we simply remove ->disconnect altogether?)
> >
> > Both dummy-hcd and net2280 call ->disconnect from ->pullup. I haven't
> > checked other UDC drivers, but it seems like something they should all
> > do. Except perhaps in the case where the UDC driver doesn't have a
> > pullup method.
> >
>
> No, ->pullup is expected to be called from UDC core, and the UDC core
> makes sure the coming ->disconnect at kinds of situations.
I think you are wrong. The UDC core calls ->pullup from the
usb_gadget_disconnect() routine, but it does not call ->disconnect from
that routine.
Furthermore, there is an advantage to having the UDC driver call
->disconnect from within its ->pullup method: It can retain its private
spinlock across the ->disconnect call. This will help prevent races.
For example, what would happen if ->disconnect was called while a
->setup callback was in progress? Or vice versa?
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: possible xhci bug on linux-next
Adding Felipe, First warning is when dwc3_omap requests threaded irq On 14.06.2017 16:03, Carlos Hernandez wrote: linux-next fails to boot due to what appears to be a xhci bug. Problem observed at least on am57xx-evm, dra72x-evm and dra7xx-evm. According to Tony Lindgren the issue is marking a shared interrupt disabled on start-up. [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 4.12.0-rc5-next-20170613 (lcpd...@dflsdit-build06.dal.design.ti.com) (gcc version 6.2.1 20161016 (Linaro GCC 6.2-2016.11) ) #2 SMP Tue Jun 13 13:52:56 CDT 2017 [0.00] CPU: ARMv7 Processor [412fc0f2] revision 2 (ARMv7), cr=10c5387d [0.00] CPU: div instructions available: patching division code [0.00] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache [0.00] OF: fdt: Machine model: TI AM5728 BeagleBoard-X15 [0.00] Memory policy: Data cache writealloc [0.00] cma: Reserved 24 MiB at 0xfe00 [0.00] OMAP4: Map 0xffd0 to fe60 for dram barrier [0.00] DRA752 ES1.1 [0.00] percpu: Embedded 17 pages/cpu @eed82000 s40936 r8192 d20504 u69632 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 522047 [0.00] Kernel command line: console=ttyO2,115200n8 earlyprintk=serial,ttyO2,115200n8 rootwait sysrq_always_enabled ip=:eth0:dhcp root=/dev/nfs rw nfsroot=192.168.0.1:/home/tigtfarm03/NFS_exports/am57xx-evm1//autofs/d3fd317ecf18e621cf951fd5ef72179d,nolock,v3,tcp,rsize=4096,wsize=4096 [0.00] sysrq: sysrq always enabled. [0.00] PID hash table entries: 4096 (order: 2, 16384 bytes) [0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) [0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) [0.00] Memory: 2025704K/2095100K available (9216K kernel code, 892K rwdata, 3176K rodata, 2048K init, 8710K bss, 44820K reserved, 24576K cma-reserved, 1284092K highmem) [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xffc0 - 0xfff0 (3072 kB) [0.00] vmalloc : 0xf080 - 0xff80 ( 240 MB) [0.00] lowmem : 0xc000 - 0xf000 ( 768 MB) [0.00] pkmap : 0xbfe0 - 0xc000 ( 2 MB) [0.00] modules : 0xbf00 - 0xbfe0 ( 14 MB) [0.00] .text : 0xc0008000 - 0xc0a0 (10208 kB) [0.00] .init : 0xc0e0 - 0xc100 (2048 kB) [0.00] .data : 0xc100 - 0xc10df398 ( 893 kB) [0.00].bss : 0xc10e90d0 - 0xc196aa80 (8711 kB) [0.00] Running RCU self tests [0.00] Hierarchical RCU implementation. [0.00] RCU event tracing is enabled. [0.00] RCU lockdep checking is enabled. [0.00] RCU callback double-/use-after-free debug enabled. [0.00] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16 [0.00] GIC: Using split EOI/Deactivate mode [0.00] kmemleak: Kernel memory leak detector disabled [0.00] OMAP clockevent source: timer1 at 32786 Hz [0.00] arch_timer: cp15 timer(s) running at 6.14MHz (phys). [0.00] clocksource: arch_sys_counter: mask: 0xff max_cycles: 0x16af5adb9, max_idle_ns: 440795202250 ns [0.06] sched_clock: 56 bits at 6MHz, resolution 162ns, wraps every 4398046511023ns [0.25] Switching to timer-based delay loop, resolution 162ns [0.000458] clocksource: 32k_counter: mask: 0x max_cycles: 0x, max_idle_ns: 58327039986419 ns [0.000474] OMAP clocksource: 32k_counter at 32768 Hz [0.001737] Console: colour dummy device 80x30 [0.001770] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar [0.001785] ... MAX_LOCKDEP_SUBCLASSES: 8 [0.001799] ... MAX_LOCK_DEPTH: 48 [0.001813] ... MAX_LOCKDEP_KEYS:8191 [0.001826] ... CLASSHASH_SIZE: 4096 [0.001840] ... MAX_LOCKDEP_ENTRIES: 32768 [0.001854] ... MAX_LOCKDEP_CHAINS: 65536 [0.001867] ... CHAINHASH_SIZE: 32768 [0.001880] memory used by lock dependency info: 5167 kB [0.001894] per task-struct memory footprint: 1536 bytes [0.003715] kmemleak: Early log buffer exceeded (9401), please increase DEBUG_KMEMLEAK_EARLY_LOG_SIZE [0.003751] Calibrating delay loop (skipped), value calculated using timer frequency.. 12.29 BogoMIPS (lpj=61475) [0.003779] pid_max: default: 32768 minimum: 301 [0.004258] Security Framework initialized [0.004448] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes) [0.004469] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes) [0.007060] CPU: Testing write buffer coherency: ok [0.008191] /cpus/cpu@0 missing clock-frequency property [0.008222] /cpus/cpu@1 missing clock-frequency property [0.008241] CPU0: thread -1, cpu 0, socket
possible xhci bug on linux-next
linux-next fails to boot due to what appears to be a xhci bug. Problem observed at least on am57xx-evm, dra72x-evm and dra7xx-evm. According to Tony Lindgren the issue is marking a shared interrupt disabled on start-up. [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 4.12.0-rc5-next-20170613 (lcpd...@dflsdit-build06.dal.design.ti.com) (gcc version 6.2.1 20161016 (Linaro GCC 6.2-2016.11) ) #2 SMP Tue Jun 13 13:52:56 CDT 2017 [0.00] CPU: ARMv7 Processor [412fc0f2] revision 2 (ARMv7), cr=10c5387d [0.00] CPU: div instructions available: patching division code [0.00] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache [0.00] OF: fdt: Machine model: TI AM5728 BeagleBoard-X15 [0.00] Memory policy: Data cache writealloc [0.00] cma: Reserved 24 MiB at 0xfe00 [0.00] OMAP4: Map 0xffd0 to fe60 for dram barrier [0.00] DRA752 ES1.1 [0.00] percpu: Embedded 17 pages/cpu @eed82000 s40936 r8192 d20504 u69632 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 522047 [0.00] Kernel command line: console=ttyO2,115200n8 earlyprintk=serial,ttyO2,115200n8 rootwait sysrq_always_enabled ip=:eth0:dhcp root=/dev/nfs rw nfsroot=192.168.0.1:/home/tigtfarm03/NFS_exports/am57xx-evm1//autofs/d3fd317ecf18e621cf951fd5ef72179d,nolock,v3,tcp,rsize=4096,wsize=4096 [0.00] sysrq: sysrq always enabled. [0.00] PID hash table entries: 4096 (order: 2, 16384 bytes) [0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) [0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) [0.00] Memory: 2025704K/2095100K available (9216K kernel code, 892K rwdata, 3176K rodata, 2048K init, 8710K bss, 44820K reserved, 24576K cma-reserved, 1284092K highmem) [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xffc0 - 0xfff0 (3072 kB) [0.00] vmalloc : 0xf080 - 0xff80 ( 240 MB) [0.00] lowmem : 0xc000 - 0xf000 ( 768 MB) [0.00] pkmap : 0xbfe0 - 0xc000 ( 2 MB) [0.00] modules : 0xbf00 - 0xbfe0 ( 14 MB) [0.00] .text : 0xc0008000 - 0xc0a0 (10208 kB) [0.00] .init : 0xc0e0 - 0xc100 (2048 kB) [0.00] .data : 0xc100 - 0xc10df398 ( 893 kB) [0.00].bss : 0xc10e90d0 - 0xc196aa80 (8711 kB) [0.00] Running RCU self tests [0.00] Hierarchical RCU implementation. [0.00] RCU event tracing is enabled. [0.00] RCU lockdep checking is enabled. [0.00] RCU callback double-/use-after-free debug enabled. [0.00] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16 [0.00] GIC: Using split EOI/Deactivate mode [0.00] kmemleak: Kernel memory leak detector disabled [0.00] OMAP clockevent source: timer1 at 32786 Hz [0.00] arch_timer: cp15 timer(s) running at 6.14MHz (phys). [0.00] clocksource: arch_sys_counter: mask: 0xff max_cycles: 0x16af5adb9, max_idle_ns: 440795202250 ns [0.06] sched_clock: 56 bits at 6MHz, resolution 162ns, wraps every 4398046511023ns [0.25] Switching to timer-based delay loop, resolution 162ns [0.000458] clocksource: 32k_counter: mask: 0x max_cycles: 0x, max_idle_ns: 58327039986419 ns [0.000474] OMAP clocksource: 32k_counter at 32768 Hz [0.001737] Console: colour dummy device 80x30 [0.001770] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar [0.001785] ... MAX_LOCKDEP_SUBCLASSES: 8 [0.001799] ... MAX_LOCK_DEPTH: 48 [0.001813] ... MAX_LOCKDEP_KEYS:8191 [0.001826] ... CLASSHASH_SIZE: 4096 [0.001840] ... MAX_LOCKDEP_ENTRIES: 32768 [0.001854] ... MAX_LOCKDEP_CHAINS: 65536 [0.001867] ... CHAINHASH_SIZE: 32768 [0.001880] memory used by lock dependency info: 5167 kB [0.001894] per task-struct memory footprint: 1536 bytes [0.003715] kmemleak: Early log buffer exceeded (9401), please increase DEBUG_KMEMLEAK_EARLY_LOG_SIZE [0.003751] Calibrating delay loop (skipped), value calculated using timer frequency.. 12.29 BogoMIPS (lpj=61475) [0.003779] pid_max: default: 32768 minimum: 301 [0.004258] Security Framework initialized [0.004448] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes) [0.004469] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes) [0.007060] CPU: Testing write buffer coherency: ok [0.008191] /cpus/cpu@0 missing clock-frequency property [0.008222] /cpus/cpu@1 missing clock-frequency property [0.008241] CPU0: thread -1, cpu 0, socket 0, mpidr 8000 [0.009506] Setting up static identity map for 0x8010 - 0x80100078 [0.010150] Hierarchi
Re: Oddity with EP configuration
On Wed, 14 Jun 2017, Benjamin Herrenschmidt wrote: > On Wed, 2017-06-14 at 10:33 +1000, Benjamin Herrenschmidt wrote: > > On Tue, 2017-06-13 at 15:08 +1000, Benjamin Herrenschmidt wrote: > > > Now, what I observe is that when the mass storage gets bound to the > > > UDC driver: > > > > > > - First the endpoints are properly allocated by my match callback, > > > ie, epautoconf is called to allocate EPs to the function. > > > > > > - But right away, composite.c calls usb_ep_autoconfig_release() > > > effectively releasing those 2 endpoints. > > > > I confirmed this by reverting to my old "single UDC" driver (so a more > > standard setup without all my hooks) and putting a WARN_ON(!ep- > > > claimed) in usb_ep_enable(). > > Ok, this is a global issue. Creating functions via configfs leads > to the same problem. I've added traces to epautoconf and to EP release > and reset and you can see what happens here (I also have the > WARN_ON(!ep->claimed) in usb_ep_enable): I think the problem is that you misunderstand how epautoconf is intended to work. I'm not the expert on this stuff -- Felipe is. Still, as best I understand, the idea is that a gadget driver or the composite core will attempt to allocate all the endpoints for a particular configuration at one time, during the gadget's startup. It will then release those allocations and move on to allocate the endpoints for the next configuration, and so on. At the end, all the allocations have been released. When the time comes to actually enable the endpoints (that is, when the gadget receives a Set-Config or Set-Interface request), there's no need to allocate anything again. The driver remembers which endpoints had been allocated originally for that config/altsetting combination and uses them. Obviously this arrangement was not designed with multiple devices below a virtual hub in mind. Perhaps you can figure out how to adapt it to your needs. 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
cdc_mbim problems with Fibocom L831-EAU
I've bought a ThinkPad T470 with a Fibocom L831-EAU WWAN module, which appears to be an MBIM device. It works fine on Windows, but if I try it on Linux, it doesn't work. I've tried it on NixOS (kernel 4.11.4, libmbim 1.14.0) and Ubuntu 16.04. * NetworkManager can't connect. * If I do `rmmod cdc_mbim; modprobe cdc_mbim`, then `mbimcli --connect` occasionally completes, but dhcpcd can't get an IP afterwards. I also tried to manually set the IP/gateway from mibmcli on the interface, but I can't connect to anything due to "System error". `mbim-network` always seems to fail. * It's probably unrelated, but I was also unable to get pppd to work. I get a "Modem hangup" seemingly after receiving DNS server information. The problems seem to be accompanied by `cdc_mbim 1-6:1.0: nonzero urb status received: -EPIPE` in dmesg. This is the device: http://www.fibocom.com/product/2-1-5-2.html Please let me know if there's anything I can do to help. lsusb: Bus 002 Device 002: ID 0bda:0316 Realtek Semiconductor Corp. Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 3.00 bDeviceClass0 bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 9 idVendor 0x0bda Realtek Semiconductor Corp. idProduct 0x0316 bcdDevice2.04 iManufacturer 1 iProduct2 iSerial 3 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 44 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 4 bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 200mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 8 Mass Storage bInterfaceSubClass 6 SCSI bInterfaceProtocol 80 Bulk-Only iInterface 5 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 3 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 3 Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 3.00 bDeviceClass9 Hub bDeviceSubClass 0 bDeviceProtocol 3 bMaxPacketSize0 9 idVendor 0x1d6b Linux Foundation idProduct 0x0003 3.0 root hub bcdDevice4.11 iManufacturer 3 iProduct2 iSerial 1 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 31 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 9 Hub bInterfaceSubClass 0 bInterfaceProtocol 0 Full speed (or root) hub iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0004 1x 4 bytes bInterval 12 bMaxBurst 0 Bus 001 Device 006: ID 138a:0097 Validity Sensors, Inc. Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 255 Vendor Specific Class bDeviceSubClass16 bDeviceProtocol 255 bMaxPacketSize0 8 idVendor 0x138a Validity Sensors, Inc. idProduct 0x0097 bcdDevice1.64 iManufacturer 0 iProduct0 iSerial 1 bNumConfi
Re: [PATCH v2 1/8] tty: add a poll() callback in struct tty_operations
> That would cut it, but TIOCPKT is too coupled with having a linked tty. > I could make acm behave like a pty (accept TIOCPKT and issue the > ctrl_status bits), but for that I need n_tty to know that packet does > not always mean a linked tty is present, and that in case it isn't we > take our own ctrl_status bits instead of the link's. I could write a > small (inline?) function to fetch the correct ctrl_status bits and put > that in n_tty. Does that make sense? I think that makes sense, and I would do the job properly rather than do a hack with tty->link. Those hacks in the long term never work out the best approach. Alan -- 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: [v2 1/1] usb:host:xhci support option to disable xHCI 1.0 USB2 HW LPM
On Tue, Jun 13, 2017 at 8:12 PM, Mathias Nyman wrote: > On 06.06.2017 09:33, Thang Q. Nguyen wrote: >> >> On Mon, Jun 5, 2017 at 9:33 PM, Mathias Nyman >> wrote: >>> >>> On 05.06.2017 15:57, Thang Q. Nguyen wrote: On Mon, Jun 5, 2017 at 6:14 PM, Mathias Nyman wrote: > > > On 20.05.2017 10:24, Thang Q. Nguyen wrote: >> >> >> >> XHCI specification 1.1 does not require xHCI 1.0 compliant controllers >> to always enable hardware USB2 LPM. >> However, the current xHCI driver always enable it by setting HLE=1 >> when >> seeing HLC=1. This makes certain xHCI controllers that have broken >> USB2 >> HW LPM fail to work as there is no way to disable this feature. >> This patch adds support to control disabling USB2 Hardware LPM via >> DT/ACPI attribute. >> > >Wouldn't it be better to just keep xhci->hw_lpm_support = 0 if the > host > doesn't support Hardware LPM Capability, (HLC)? > > This should prevent all those extra steps getting here just to do > nothing. No, HLC = 0 means the host doesn't support Hardware LPM. The problem here is the host support Hardware LPM but there is a bug in host controller that make the LPM fail to work. >>> >>> So the host support hw LPM, and has its HLC capability bit set, >>> but in the end it just doesn't work at all, and should be prevented. >>> When debugging the host controller, we detect there are some holes in the current usb specifications which can can result in inter-operating problems between USB Host Controller and USB PHY. To be more specific, the specs have not clarified the resume recovery timing after the port has just waken up from L1. This can lead to different interpretations of the specs by Host Controller and PHY. What happened in our case is that a Host controller cannot work with a PHY right after resuming from L1 because these two Vendors have different views of the specs regarding LPM timing after L1. These views are contradictory and cannot work together. If Host Controller and PHY are from the same vendor, they might have some "internal handshake mechanisms" to avoid these holes of the USB specs. However, these mechanisms are not standardized in USB specs; and not all vendors follow these mechanisms. In fact, we have observed this kind of "internal handshake mechanism" in HOST Controller and PHY from SYNOPSYS DWC. So, we can say that if users use Host Controller and PHY from different Vendors, the inteopering problems after waking up from L1 are more likely to occur. >>> >>> >>> >>> Can you explain the reason why you prefer preventing hw lpm inside the >>> xhci_set_usb2_hardware_lpm() function instead of preventing hw lpm usage >>> all together for this platform -i.e. by not setting xhci->hw_lpm_support >> >> The reason I don't change in the xhci_add_in_port() function inside >> xhci-mem.c is because of the description for xhci->hw_lpm_support in >> the drivers/usb/host/xhci.h header file: support xHCI 1.0 spec USB2 >> hardware LPM. Per my understanding, this attribute is used to indicate >> if the host supports HW LPM and this can be checked via HLC. >> My intension is to support an option for user to disable the HW LPM >> because of some reasons (in my case because HW LPM is broken). > > > I think we should keep supporting new options separate from workarounds > for broken HW. So, I will continue to use usb2-lpm-disable to let kernel know that we want to disable USB2 HW LPM. > >>> >>> >>> Again, something like: >>> if (temp & XHCI_HLC && !(xhci->quirks & XHCI_HW_LPM_BROKEN)) >>> xhci->hw_lpm_support = 1; >> >> This should work too. But the DT/ACPI attribute should change to >> "usb2-lpm-broken". > > > This would be more clear for future developers and prevent them from > enabling hw lpm for this host to gain some powersaving. > > A new feature allowing optional host hw lpm disabling can then be written > separately, > preferable without using the quirk bits. How's about adding a new attribute such as sw_lpm_disable to the xhci_hcd struct to indicate that we will disable USB2 HW LPM by software? > > -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
[PATCH Resent 1/3] HID: core: move the dynamic quirks handling in core
usbhid has a list of dynamic quirks in addition to a list of static quirks.
There is not much USB specific in that, so move this part of the module
in core so we can have one central place for quirks.
Signed-off-by: Benjamin Tissoires
---
Resent with -M1 -C1 in format-patch to detect the rename.
I need to be that aggressive because the list hid_blacklist in
drivers/hid/usbhid/hid-quirks.c was neither alphabetically sorted, nor sorted
by quirks as mentioned at hte beginning of the file.
drivers/hid/Makefile | 2 +-
drivers/hid/hid-core.c| 7 +-
drivers/hid/{usbhid => }/hid-quirks.c | 481 +-
drivers/hid/usbhid/Makefile | 2 +-
drivers/hid/usbhid/hid-core.c | 10 +-
include/linux/hid.h | 8 +-
6 files changed, 255 insertions(+), 255 deletions(-)
rename drivers/hid/{usbhid => }/hid-quirks.c (12%)
diff --git a/drivers/hid/Makefile b/drivers/hid/Makefile
index 8ceaa6c..6a5dbae 100644
--- a/drivers/hid/Makefile
+++ b/drivers/hid/Makefile
@@ -1,7 +1,7 @@
#
# Makefile for the HID driver
#
-hid-y := hid-core.o hid-input.o
+hid-y := hid-core.o hid-input.o hid-quirks.o
hid-$(CONFIG_DEBUG_FS) += hid-debug.o
obj-$(CONFIG_HID) += hid.o
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 984ef2f..953dc41 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1597,8 +1597,8 @@ int hid_input_report(struct hid_device *hid, int type, u8
*data, int size, int i
}
EXPORT_SYMBOL_GPL(hid_input_report);
-static bool hid_match_one_id(struct hid_device *hdev,
- const struct hid_device_id *id)
+bool hid_match_one_id(const struct hid_device *hdev,
+ const struct hid_device_id *id)
{
return (id->bus == HID_BUS_ANY || id->bus == hdev->bus) &&
(id->group == HID_GROUP_ANY || id->group == hdev->group) &&
@@ -2919,6 +2919,8 @@ int hid_add_device(struct hid_device *hdev)
if (WARN_ON(hdev->status & HID_STAT_ADDED))
return -EBUSY;
+ hdev->quirks = hid_lookup_quirk(hdev);
+
/* we need to kill them here, otherwise they will stay allocated to
* wait for coming driver */
if (hid_ignore(hdev))
@@ -3117,6 +3119,7 @@ static void __exit hid_exit(void)
hid_debug_exit();
hidraw_exit();
bus_unregister(&hid_bus_type);
+ hid_quirks_exit(HID_BUS_ANY);
}
module_init(hid_init);
diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/hid-quirks.c
similarity index 12%
rename from drivers/hid/usbhid/hid-quirks.c
rename to drivers/hid/hid-quirks.c
index a88e7c7..06f94ec 100644
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/hid-quirks.c
@@ -18,244 +18,235 @@
#include
#include
#include
+#include
-#include "../hid-ids.h"
+#include "hid-ids.h"
/*
- * Alphabetically sorted blacklist by quirk type.
+ * Alphabetically sorted by vendor then product.
*/
-static const struct hid_blacklist {
- __u16 idVendor;
- __u16 idProduct;
- __u32 quirks;
-} hid_blacklist[] = {
- { USB_VENDOR_ID_AASHIMA, USB_DEVICE_ID_AASHIMA_GAMEPAD,
HID_QUIRK_BADPAD },
- { USB_VENDOR_ID_AASHIMA, USB_DEVICE_ID_AASHIMA_PREDATOR,
HID_QUIRK_BADPAD },
- { USB_VENDOR_ID_ALPS, USB_DEVICE_ID_IBM_GAMEPAD, HID_QUIRK_BADPAD },
- { USB_VENDOR_ID_CHIC, USB_DEVICE_ID_CHIC_GAMEPAD, HID_QUIRK_BADPAD },
- { USB_VENDOR_ID_DWAV, USB_DEVICE_ID_EGALAX_TOUCHCONTROLLER,
HID_QUIRK_MULTI_INPUT | HID_QUIRK_NOGET },
- { USB_VENDOR_ID_MOJO, USB_DEVICE_ID_RETRO_ADAPTER,
HID_QUIRK_MULTI_INPUT },
- { USB_VENDOR_ID_HAPP, USB_DEVICE_ID_UGCI_DRIVING, HID_QUIRK_BADPAD |
HID_QUIRK_MULTI_INPUT },
- { USB_VENDOR_ID_HAPP, USB_DEVICE_ID_UGCI_FLYING, HID_QUIRK_BADPAD |
HID_QUIRK_MULTI_INPUT },
- { USB_VENDOR_ID_HAPP, USB_DEVICE_ID_UGCI_FIGHTING, HID_QUIRK_BADPAD |
HID_QUIRK_MULTI_INPUT },
- { USB_VENDOR_ID_NATSU, USB_DEVICE_ID_NATSU_GAMEPAD, HID_QUIRK_BADPAD },
- { USB_VENDOR_ID_NEC, USB_DEVICE_ID_NEC_USB_GAME_PAD, HID_QUIRK_BADPAD },
- { USB_VENDOR_ID_NEXTWINDOW, USB_DEVICE_ID_NEXTWINDOW_TOUCHSCREEN,
HID_QUIRK_MULTI_INPUT},
- { USB_VENDOR_ID_SAITEK, USB_DEVICE_ID_SAITEK_RUMBLEPAD,
HID_QUIRK_BADPAD },
- { USB_VENDOR_ID_TOPMAX, USB_DEVICE_ID_TOPMAX_COBRAPAD, HID_QUIRK_BADPAD
},
-
- { USB_VENDOR_ID_AFATECH, USB_DEVICE_ID_AFATECH_AF9016,
HID_QUIRK_FULLSPEED_INTERVAL },
-
- { USB_VENDOR_ID_EMS, USB_DEVICE_ID_EMS_TRIO_LINKER_PLUS_II,
HID_QUIRK_MULTI_INPUT },
- { USB_VENDOR_ID_ETURBOTOUCH, USB_DEVICE_ID_ETURBOTOUCH,
HID_QUIRK_MULTI_INPUT },
- { USB_VENDOR_ID_ETURBOTOUCH, USB_DEVICE_ID_ETURBOTOUCH_2968,
HID_QUIRK_MULTI_INPUT },
- { USB_VENDOR_ID_GREENASIA, USB_DEVICE_ID_GREENASIA_DUAL_USB_JOYPAD,
HID_QUIRK_MULTI_INPUT },
- { USB_VENDOR_ID_PANTHERLORD,
USB_DEVICE_ID_PANTHERLORD_TWIN_USB_JOYSTICK, HID_QUIRK_MULTI_
Re: [PATCH 1/3] HID: core: move the dynamic quirks handling in core
On Jun 14 2017 or thereabouts, Andy Shevchenko wrote: > On Wed, Jun 14, 2017 at 11:24 AM, Benjamin Tissoires > wrote: > > usbhid has a list of dynamic quirks in addition to a list of static quirks. > > There is not much USB specific in that, so move this part of the module > > in core so we can have one central place for quirks. > > > Wouldn't be better to resend with -M -C applied? Good point. Actually, I need to use 10% of tolerance (-M1) to get git detect the rename :/ Patch following shortly. 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 0/3] Proposal for making hid_have_special_driver obsolete
On Jun 14 2017 or thereabouts, Bastien Nocera wrote: > > > > On 14 Jun 2017, at 10:24, Benjamin Tissoires > > wrote: > > > > Hi, > > > > As mentioned by Jiri, I found a way to have this horrible list a thing from > > the past (to some extends). > > > > The basic observation is that now, since v4.12, hid-generic should not be an > > issue for any device, given that all it does is parsing the report > > descriptor > > and starting the IRQs/URBs. > > > > So it should not be an issue to have hid-generic handling all incoming > > devices > > until the specialized driver comes in and replace it. > > > > For users, that means that they will see an input node appearing and > > disappearing as soon as hid-XXX.ko gets loaded. > > That's way ugly, and slower, when a "multi" quirk is used. Well, if you add a multi quirk on the boot command line, you can also add a have_special_driver one which will be honored by hid-generic. Note that the current list is still there and for those devices registered in (now) hid-quirks.c, hid-generic will not bind to them (unless the special driver is not configured in). The hid-generic transient state will only affect devices not in hid_have_special_driver, so then it's up to the driver maintainers to decide whether or not they need it or not. Cheers, Benjamin > > > I have tested this on the Logitech Unifying Receiver and some Wacom devices, > > and all seem happy with the situation. > > > > Patches 1 and 2 are HID cleanup and something I wanted to put in from a long > > time. > > > > Patch 3 is the one that does the magic and where I need input from the > > drivers > > specialists. > > > > To make things easier to handle, I deported the logic of unbinding > > hid-generic > > into hid-generic itself. I would think a bus_notifier would be better than > > instrumenting struct hid_driver for drivers (un)registering on the bus, but > > we are missing those events in bus_notifiers. > > Would such events (BUS_NOTIFY_ADD_DRIVER, BUS_NOTIFY_REMOVED_DRIVER) make > > sense > > outside of this particular case? > > > > The second question I have is whether or not I need locks around the > > unbinding > > magic in hid-generic. After a lot of thinking I believe I don't, but I'd > > prefer > > having a second pair of eyes on this. > > > > Jiri, this series is on top of a merge of your for-next and your other > > for-4.12/driver-matching-fix branch. I'll resubmit a proper patch that will > > apply properly to for-next as soon as for-4.12/driver-matching-fix gets > > merged. > > > > Cheers, > > Benjamin > > > > Benjamin Tissoires (3): > > HID: core: move the dynamic quirks handling in core > > HID: quirks: move the list of special devices into a quirk > > HID: core: remove the absolute need of hid_have_special_driver[] > > > > drivers/hid/Makefile|2 +- > > drivers/hid/hid-core.c | 918 ++--- > > drivers/hid/hid-generic.c | 68 ++- > > drivers/hid/hid-quirks.c| 1236 > > +++ > > drivers/hid/usbhid/Makefile |2 +- > > drivers/hid/usbhid/hid-core.c | 10 +- > > drivers/hid/usbhid/hid-quirks.c | 399 - > > include/linux/hid.h | 19 +- > > net/bluetooth/hidp/core.c |2 +- > > 9 files changed, 1380 insertions(+), 1276 deletions(-) > > create mode 100644 drivers/hid/hid-quirks.c > > delete mode 100644 drivers/hid/usbhid/hid-quirks.c > > > > -- > > 2.9.4 > > > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-input" in > > the body of a message to majord...@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- 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 v3 1/2] usb: typec: Add support for UCSI interface
On Wed, Jun 14, 2017 at 12:50:38PM +0200, Greg Kroah-Hartman wrote: > On Wed, Jun 14, 2017 at 09:45:46AM +0300, Heikki Krogerus wrote: > > Hi Guenter, > > > > Gentle ping. > > After less than 2 days? Relax please... OK, Sorry for the noise. -- 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: gadgetfs, dummy-hcd, net2280: fix locking for callbacks
Hi, Greg KH writes: > On Tue, Jun 13, 2017 at 03:23:42PM -0400, Alan Stern wrote: >> Using the syzkaller kernel fuzzer, Andrey Konovalov generated the >> following error in gadgetfs: >> >> > 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
Re: [PATCH] USB: gadgetfs, dummy-hcd, net2280: fix locking for callbacks
On Tue, Jun 13, 2017 at 03:23:42PM -0400, Alan Stern wrote: > Using the syzkaller kernel fuzzer, Andrey Konovalov generated the > following error in gadgetfs: > > > 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 2
Re: [PATCH v3 1/2] usb: typec: Add support for UCSI interface
On Wed, Jun 14, 2017 at 09:45:46AM +0300, Heikki Krogerus wrote: > Hi Guenter, > > Gentle ping. After less than 2 days? Relax please... -- 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 0/3] Proposal for making hid_have_special_driver obsolete
> On 14 Jun 2017, at 10:24, Benjamin Tissoires > wrote: > > Hi, > > As mentioned by Jiri, I found a way to have this horrible list a thing from > the past (to some extends). > > The basic observation is that now, since v4.12, hid-generic should not be an > issue for any device, given that all it does is parsing the report descriptor > and starting the IRQs/URBs. > > So it should not be an issue to have hid-generic handling all incoming devices > until the specialized driver comes in and replace it. > > For users, that means that they will see an input node appearing and > disappearing as soon as hid-XXX.ko gets loaded. That's way ugly, and slower, when a "multi" quirk is used. > I have tested this on the Logitech Unifying Receiver and some Wacom devices, > and all seem happy with the situation. > > Patches 1 and 2 are HID cleanup and something I wanted to put in from a long > time. > > Patch 3 is the one that does the magic and where I need input from the drivers > specialists. > > To make things easier to handle, I deported the logic of unbinding hid-generic > into hid-generic itself. I would think a bus_notifier would be better than > instrumenting struct hid_driver for drivers (un)registering on the bus, but > we are missing those events in bus_notifiers. > Would such events (BUS_NOTIFY_ADD_DRIVER, BUS_NOTIFY_REMOVED_DRIVER) make > sense > outside of this particular case? > > The second question I have is whether or not I need locks around the unbinding > magic in hid-generic. After a lot of thinking I believe I don't, but I'd > prefer > having a second pair of eyes on this. > > Jiri, this series is on top of a merge of your for-next and your other > for-4.12/driver-matching-fix branch. I'll resubmit a proper patch that will > apply properly to for-next as soon as for-4.12/driver-matching-fix gets > merged. > > Cheers, > Benjamin > > Benjamin Tissoires (3): > HID: core: move the dynamic quirks handling in core > HID: quirks: move the list of special devices into a quirk > HID: core: remove the absolute need of hid_have_special_driver[] > > drivers/hid/Makefile|2 +- > drivers/hid/hid-core.c | 918 ++--- > drivers/hid/hid-generic.c | 68 ++- > drivers/hid/hid-quirks.c| 1236 +++ > drivers/hid/usbhid/Makefile |2 +- > drivers/hid/usbhid/hid-core.c | 10 +- > drivers/hid/usbhid/hid-quirks.c | 399 - > include/linux/hid.h | 19 +- > net/bluetooth/hidp/core.c |2 +- > 9 files changed, 1380 insertions(+), 1276 deletions(-) > create mode 100644 drivers/hid/hid-quirks.c > delete mode 100644 drivers/hid/usbhid/hid-quirks.c > > -- > 2.9.4 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-input" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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 1/3] HID: core: move the dynamic quirks handling in core
On Wed, Jun 14, 2017 at 11:24 AM, Benjamin Tissoires
wrote:
> usbhid has a list of dynamic quirks in addition to a list of static quirks.
> There is not much USB specific in that, so move this part of the module
> in core so we can have one central place for quirks.
Wouldn't be better to resend with -M -C applied?
>
> Signed-off-by: Benjamin Tissoires
> ---
> drivers/hid/Makefile| 2 +-
> drivers/hid/hid-core.c | 7 +-
> drivers/hid/hid-quirks.c| 396 +++
> drivers/hid/usbhid/Makefile | 2 +-
> drivers/hid/usbhid/hid-core.c | 10 +-
> drivers/hid/usbhid/hid-quirks.c | 399
>
> include/linux/hid.h | 8 +-
> 7 files changed, 412 insertions(+), 412 deletions(-)
> create mode 100644 drivers/hid/hid-quirks.c
> delete mode 100644 drivers/hid/usbhid/hid-quirks.c
>
> diff --git a/drivers/hid/Makefile b/drivers/hid/Makefile
> index 8ceaa6c..6a5dbae 100644
> --- a/drivers/hid/Makefile
> +++ b/drivers/hid/Makefile
> @@ -1,7 +1,7 @@
> #
> # Makefile for the HID driver
> #
> -hid-y := hid-core.o hid-input.o
> +hid-y := hid-core.o hid-input.o hid-quirks.o
> hid-$(CONFIG_DEBUG_FS) += hid-debug.o
>
> obj-$(CONFIG_HID) += hid.o
> diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
> index 984ef2f..953dc41 100644
> --- a/drivers/hid/hid-core.c
> +++ b/drivers/hid/hid-core.c
> @@ -1597,8 +1597,8 @@ int hid_input_report(struct hid_device *hid, int type,
> u8 *data, int size, int i
> }
> EXPORT_SYMBOL_GPL(hid_input_report);
>
> -static bool hid_match_one_id(struct hid_device *hdev,
> - const struct hid_device_id *id)
> +bool hid_match_one_id(const struct hid_device *hdev,
> + const struct hid_device_id *id)
> {
> return (id->bus == HID_BUS_ANY || id->bus == hdev->bus) &&
> (id->group == HID_GROUP_ANY || id->group == hdev->group) &&
> @@ -2919,6 +2919,8 @@ int hid_add_device(struct hid_device *hdev)
> if (WARN_ON(hdev->status & HID_STAT_ADDED))
> return -EBUSY;
>
> + hdev->quirks = hid_lookup_quirk(hdev);
> +
> /* we need to kill them here, otherwise they will stay allocated to
> * wait for coming driver */
> if (hid_ignore(hdev))
> @@ -3117,6 +3119,7 @@ static void __exit hid_exit(void)
> hid_debug_exit();
> hidraw_exit();
> bus_unregister(&hid_bus_type);
> + hid_quirks_exit(HID_BUS_ANY);
> }
>
> module_init(hid_init);
> diff --git a/drivers/hid/hid-quirks.c b/drivers/hid/hid-quirks.c
> new file mode 100644
> index 000..06f94ec
> --- /dev/null
> +++ b/drivers/hid/hid-quirks.c
> @@ -0,0 +1,396 @@
> +/*
> + * USB HID quirks support for Linux
> + *
> + * Copyright (c) 1999 Andreas Gal
> + * Copyright (c) 2000-2005 Vojtech Pavlik
> + * Copyright (c) 2005 Michael Haboustak for Concept2,
> Inc
> + * Copyright (c) 2006-2007 Jiri Kosina
> + * Copyright (c) 2007 Paul Walmsley
> + */
> +
> +/*
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published by the Free
> + * Software Foundation; either version 2 of the License, or (at your option)
> + * any later version.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +
> +#include "hid-ids.h"
> +
> +/*
> + * Alphabetically sorted by vendor then product.
> + */
> +
> +struct hid_device_id hid_quirks[] = {
> + { HID_USB_DEVICE(USB_VENDOR_ID_AASHIMA,
> USB_DEVICE_ID_AASHIMA_GAMEPAD), HID_QUIRK_BADPAD },
> + { HID_USB_DEVICE(USB_VENDOR_ID_AASHIMA,
> USB_DEVICE_ID_AASHIMA_PREDATOR), HID_QUIRK_BADPAD },
> + { HID_USB_DEVICE(USB_VENDOR_ID_AFATECH,
> USB_DEVICE_ID_AFATECH_AF9016), HID_QUIRK_FULLSPEED_INTERVAL },
> + { HID_USB_DEVICE(USB_VENDOR_ID_AIREN, USB_DEVICE_ID_AIREN_SLIMPLUS),
> HID_QUIRK_NOGET },
> + { HID_USB_DEVICE(USB_VENDOR_ID_AKAI_09E8,
> USB_DEVICE_ID_AKAI_09E8_MIDIMIX), HID_QUIRK_NO_INIT_REPORTS },
> + { HID_USB_DEVICE(USB_VENDOR_ID_AKAI, USB_DEVICE_ID_AKAI_MPKMINI2),
> HID_QUIRK_NO_INIT_REPORTS },
> + { HID_USB_DEVICE(USB_VENDOR_ID_ALPS, USB_DEVICE_ID_IBM_GAMEPAD),
> HID_QUIRK_BADPAD },
> + { HID_USB_DEVICE(USB_VENDOR_ID_AMI,
> USB_DEVICE_ID_AMI_VIRT_KEYBOARD_AND_MOUSE), HID_QUIRK_ALWAYS_POLL },
> + { HID_USB_DEVICE(USB_VENDOR_ID_ATEN, USB_DEVICE_ID_ATEN_2PORTKVM),
> HID_QUIRK_NOGET },
> + { HID_USB_DEVICE(USB_VENDOR_ID_ATEN, USB_DEVICE_ID_ATEN_4PORTKVMC),
> HID_QUIRK_NOGET },
> + { HID_USB_DEVICE(USB_VENDOR_ID_ATEN, USB_DEVICE_ID_ATEN_4PORTKVM),
> HID_QUIRK_NOGET },
> + { HID_USB_DEVICE(USB_VENDOR_ID_ATEN, USB_DEVICE_ID_ATEN_CS124U),
> HID_QUIRK_NOGET },
> + { HID_USB_DEVICE(USB_VENDOR_ID_ATEN, USB_DEVICE_ID_ATEN_CS1758),
> HID_QUIRK_NOGET },
> + { HID_USB_DEVICE(USB_VENDOR_ID_ATEN, USB_DEVICE_ID_ATEN_CS682),
> HID_Q
[PATCH 0/3] Proposal for making hid_have_special_driver obsolete
Hi, As mentioned by Jiri, I found a way to have this horrible list a thing from the past (to some extends). The basic observation is that now, since v4.12, hid-generic should not be an issue for any device, given that all it does is parsing the report descriptor and starting the IRQs/URBs. So it should not be an issue to have hid-generic handling all incoming devices until the specialized driver comes in and replace it. For users, that means that they will see an input node appearing and disappearing as soon as hid-XXX.ko gets loaded. I have tested this on the Logitech Unifying Receiver and some Wacom devices, and all seem happy with the situation. Patches 1 and 2 are HID cleanup and something I wanted to put in from a long time. Patch 3 is the one that does the magic and where I need input from the drivers specialists. To make things easier to handle, I deported the logic of unbinding hid-generic into hid-generic itself. I would think a bus_notifier would be better than instrumenting struct hid_driver for drivers (un)registering on the bus, but we are missing those events in bus_notifiers. Would such events (BUS_NOTIFY_ADD_DRIVER, BUS_NOTIFY_REMOVED_DRIVER) make sense outside of this particular case? The second question I have is whether or not I need locks around the unbinding magic in hid-generic. After a lot of thinking I believe I don't, but I'd prefer having a second pair of eyes on this. Jiri, this series is on top of a merge of your for-next and your other for-4.12/driver-matching-fix branch. I'll resubmit a proper patch that will apply properly to for-next as soon as for-4.12/driver-matching-fix gets merged. Cheers, Benjamin Benjamin Tissoires (3): HID: core: move the dynamic quirks handling in core HID: quirks: move the list of special devices into a quirk HID: core: remove the absolute need of hid_have_special_driver[] drivers/hid/Makefile|2 +- drivers/hid/hid-core.c | 918 ++--- drivers/hid/hid-generic.c | 68 ++- drivers/hid/hid-quirks.c| 1236 +++ drivers/hid/usbhid/Makefile |2 +- drivers/hid/usbhid/hid-core.c | 10 +- drivers/hid/usbhid/hid-quirks.c | 399 - include/linux/hid.h | 19 +- net/bluetooth/hidp/core.c |2 +- 9 files changed, 1380 insertions(+), 1276 deletions(-) create mode 100644 drivers/hid/hid-quirks.c delete mode 100644 drivers/hid/usbhid/hid-quirks.c -- 2.9.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/3] HID: core: move the dynamic quirks handling in core
usbhid has a list of dynamic quirks in addition to a list of static quirks.
There is not much USB specific in that, so move this part of the module
in core so we can have one central place for quirks.
Signed-off-by: Benjamin Tissoires
---
drivers/hid/Makefile| 2 +-
drivers/hid/hid-core.c | 7 +-
drivers/hid/hid-quirks.c| 396 +++
drivers/hid/usbhid/Makefile | 2 +-
drivers/hid/usbhid/hid-core.c | 10 +-
drivers/hid/usbhid/hid-quirks.c | 399
include/linux/hid.h | 8 +-
7 files changed, 412 insertions(+), 412 deletions(-)
create mode 100644 drivers/hid/hid-quirks.c
delete mode 100644 drivers/hid/usbhid/hid-quirks.c
diff --git a/drivers/hid/Makefile b/drivers/hid/Makefile
index 8ceaa6c..6a5dbae 100644
--- a/drivers/hid/Makefile
+++ b/drivers/hid/Makefile
@@ -1,7 +1,7 @@
#
# Makefile for the HID driver
#
-hid-y := hid-core.o hid-input.o
+hid-y := hid-core.o hid-input.o hid-quirks.o
hid-$(CONFIG_DEBUG_FS) += hid-debug.o
obj-$(CONFIG_HID) += hid.o
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 984ef2f..953dc41 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1597,8 +1597,8 @@ int hid_input_report(struct hid_device *hid, int type, u8
*data, int size, int i
}
EXPORT_SYMBOL_GPL(hid_input_report);
-static bool hid_match_one_id(struct hid_device *hdev,
- const struct hid_device_id *id)
+bool hid_match_one_id(const struct hid_device *hdev,
+ const struct hid_device_id *id)
{
return (id->bus == HID_BUS_ANY || id->bus == hdev->bus) &&
(id->group == HID_GROUP_ANY || id->group == hdev->group) &&
@@ -2919,6 +2919,8 @@ int hid_add_device(struct hid_device *hdev)
if (WARN_ON(hdev->status & HID_STAT_ADDED))
return -EBUSY;
+ hdev->quirks = hid_lookup_quirk(hdev);
+
/* we need to kill them here, otherwise they will stay allocated to
* wait for coming driver */
if (hid_ignore(hdev))
@@ -3117,6 +3119,7 @@ static void __exit hid_exit(void)
hid_debug_exit();
hidraw_exit();
bus_unregister(&hid_bus_type);
+ hid_quirks_exit(HID_BUS_ANY);
}
module_init(hid_init);
diff --git a/drivers/hid/hid-quirks.c b/drivers/hid/hid-quirks.c
new file mode 100644
index 000..06f94ec
--- /dev/null
+++ b/drivers/hid/hid-quirks.c
@@ -0,0 +1,396 @@
+/*
+ * USB HID quirks support for Linux
+ *
+ * Copyright (c) 1999 Andreas Gal
+ * Copyright (c) 2000-2005 Vojtech Pavlik
+ * Copyright (c) 2005 Michael Haboustak for Concept2, Inc
+ * Copyright (c) 2006-2007 Jiri Kosina
+ * Copyright (c) 2007 Paul Walmsley
+ */
+
+/*
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option)
+ * any later version.
+ */
+
+#include
+#include
+#include
+#include
+
+#include "hid-ids.h"
+
+/*
+ * Alphabetically sorted by vendor then product.
+ */
+
+struct hid_device_id hid_quirks[] = {
+ { HID_USB_DEVICE(USB_VENDOR_ID_AASHIMA, USB_DEVICE_ID_AASHIMA_GAMEPAD),
HID_QUIRK_BADPAD },
+ { HID_USB_DEVICE(USB_VENDOR_ID_AASHIMA,
USB_DEVICE_ID_AASHIMA_PREDATOR), HID_QUIRK_BADPAD },
+ { HID_USB_DEVICE(USB_VENDOR_ID_AFATECH, USB_DEVICE_ID_AFATECH_AF9016),
HID_QUIRK_FULLSPEED_INTERVAL },
+ { HID_USB_DEVICE(USB_VENDOR_ID_AIREN, USB_DEVICE_ID_AIREN_SLIMPLUS),
HID_QUIRK_NOGET },
+ { HID_USB_DEVICE(USB_VENDOR_ID_AKAI_09E8,
USB_DEVICE_ID_AKAI_09E8_MIDIMIX), HID_QUIRK_NO_INIT_REPORTS },
+ { HID_USB_DEVICE(USB_VENDOR_ID_AKAI, USB_DEVICE_ID_AKAI_MPKMINI2),
HID_QUIRK_NO_INIT_REPORTS },
+ { HID_USB_DEVICE(USB_VENDOR_ID_ALPS, USB_DEVICE_ID_IBM_GAMEPAD),
HID_QUIRK_BADPAD },
+ { HID_USB_DEVICE(USB_VENDOR_ID_AMI,
USB_DEVICE_ID_AMI_VIRT_KEYBOARD_AND_MOUSE), HID_QUIRK_ALWAYS_POLL },
+ { HID_USB_DEVICE(USB_VENDOR_ID_ATEN, USB_DEVICE_ID_ATEN_2PORTKVM),
HID_QUIRK_NOGET },
+ { HID_USB_DEVICE(USB_VENDOR_ID_ATEN, USB_DEVICE_ID_ATEN_4PORTKVMC),
HID_QUIRK_NOGET },
+ { HID_USB_DEVICE(USB_VENDOR_ID_ATEN, USB_DEVICE_ID_ATEN_4PORTKVM),
HID_QUIRK_NOGET },
+ { HID_USB_DEVICE(USB_VENDOR_ID_ATEN, USB_DEVICE_ID_ATEN_CS124U),
HID_QUIRK_NOGET },
+ { HID_USB_DEVICE(USB_VENDOR_ID_ATEN, USB_DEVICE_ID_ATEN_CS1758),
HID_QUIRK_NOGET },
+ { HID_USB_DEVICE(USB_VENDOR_ID_ATEN, USB_DEVICE_ID_ATEN_CS682),
HID_QUIRK_NOGET },
+ { HID_USB_DEVICE(USB_VENDOR_ID_ATEN, USB_DEVICE_ID_ATEN_CS692),
HID_QUIRK_NOGET },
+ { HID_USB_DEVICE(USB_VENDOR_ID_ATEN, USB_DEVICE_ID_ATEN_UC100KM),
HID_QUIRK_NOGET },
+ { HID_USB_DEVICE(USB_VENDOR_ID_CHICONY,
USB_DEVICE_ID_CHICONY_MULTI_TOUCH), HID_QUIRK_MULTI_INPUT },
+ { HID_USB_DEVICE(USB_VENDOR_ID_CHICONY,
US
[PATCH] usb: gadget: mv_udc: Handle return value of clk_prepare_enable.
clk_prepare_enable() can fail here and we must check its return value.
Signed-off-by: Arvind Yadav
---
drivers/usb/gadget/udc/mv_udc_core.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/gadget/udc/mv_udc_core.c
b/drivers/usb/gadget/udc/mv_udc_core.c
index 76f56c5..8a708d0 100644
--- a/drivers/usb/gadget/udc/mv_udc_core.c
+++ b/drivers/usb/gadget/udc/mv_udc_core.c
@@ -960,9 +960,9 @@ static int mv_ep_set_wedge(struct usb_ep *_ep)
.fifo_flush = mv_ep_fifo_flush, /* flush fifo */
};
-static void udc_clock_enable(struct mv_udc *udc)
+static int udc_clock_enable(struct mv_udc *udc)
{
- clk_prepare_enable(udc->clk);
+ return clk_prepare_enable(udc->clk);
}
static void udc_clock_disable(struct mv_udc *udc)
@@ -1070,7 +1070,10 @@ static int mv_udc_enable_internal(struct mv_udc *udc)
return 0;
dev_dbg(&udc->dev->dev, "enable udc\n");
- udc_clock_enable(udc);
+ retval = udc_clock_enable(udc);
+ if (retval)
+ return retval;
+
if (udc->pdata->phy_init) {
retval = udc->pdata->phy_init(udc->phy_regs);
if (retval) {
--
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
[RFC/PATCH] usb/gadget: Add an EP dispose() callback for EP lifetime tracking
Some UDC may want to allocate endpoints dynamically, either because
the HW supports an arbitrary large number or because (like the Aspeed
BMC SoCs), the pool of HW endpoints is shared between multiple gadgets.
The allocation side can be done rather easily using the existing
match_ep() UDC hook.
However we have no good place to "free" them.
This implements a "simple" variant of this, which calls an EP dispose
callback on all EPs associated with a gadget when the composite device
gets unbound.
A more complex approach would track which configuration uses which EPs
but that's overkill at this stage.
Signed-off-by: Benjamin Herrenschmidt
---
drivers/usb/gadget/composite.c | 10 +-
drivers/usb/gadget/epautoconf.c | 8 ++--
include/linux/usb/gadget.h | 1 +
3 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c
index 49d685a..caed089 100644
--- a/drivers/usb/gadget/composite.c
+++ b/drivers/usb/gadget/composite.c
@@ -899,7 +899,7 @@ int usb_add_config(struct usb_composite_dev *cdev,
status = bind(config);
if (status < 0) {
while (!list_empty(&config->functions)) {
- struct usb_function *f;
+ struct usb_function *f;
f = list_first_entry(&config->functions,
struct usb_function, list);
@@ -2159,6 +2159,7 @@ int composite_os_desc_req_prepare(struct
usb_composite_dev *cdev,
void composite_dev_cleanup(struct usb_composite_dev *cdev)
{
struct usb_gadget_string_container *uc, *tmp;
+ struct usb_ep *ep, *tmp_ep;
list_for_each_entry_safe(uc, tmp, &cdev->gstrings, list) {
list_del(&uc->list);
@@ -2180,6 +2181,13 @@ void composite_dev_cleanup(struct usb_composite_dev
*cdev)
}
cdev->next_string_id = 0;
device_remove_file(&cdev->gadget->dev, &dev_attr_suspended);
+
+ /* Dispose EPs if the UDC driver tracks lifetime */
+ list_for_each_entry_safe(ep, tmp_ep,
+&cdev->gadget->ep_list, ep_list) {
+ if (ep->ops->dispose)
+ ep->ops->dispose(ep);
+ }
}
static int composite_bind(struct usb_gadget *gadget,
diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index e4516e9..b9299a0 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -126,6 +126,7 @@ struct usb_ep_ops {
int (*enable) (struct usb_ep *ep,
const struct usb_endpoint_descriptor *desc);
int (*disable) (struct usb_ep *ep);
+ void (*dispose) (struct usb_ep *ep);
struct usb_request *(*alloc_request) (struct usb_ep *ep,
gfp_t gfp_flags);
--
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 v15 2/7] power: add power sequence library
On 14 June 2017 at 03:53, Peter Chen wrote:
> On Tue, Jun 13, 2017 at 12:24:42PM +0200, Ulf Hansson wrote:
>> [...]
>>
>> > +
>> > +/**
>> > + * of_pwrseq_on - Carry out power sequence on for device node
>> > + *
>> > + * @np: the device node would like to power on
>> > + *
>> > + * Carry out a single device power on. If multiple devices
>> > + * need to be handled, use of_pwrseq_on_list() instead.
>> > + *
>> > + * Return a pointer to the power sequence instance on success,
>> > + * or an error code otherwise.
>> > + */
>> > +struct pwrseq *of_pwrseq_on(struct device_node *np)
>> > +{
>> > + struct pwrseq *pwrseq;
>> > + int ret;
>> > +
>> > + pwrseq = pwrseq_find_available_instance(np);
>> > + if (!pwrseq)
>> > + return ERR_PTR(-ENOENT);
>>
>> In case the pwrseq instance hasn't been registered yet, then there is
>> no way to deal with -EPROBE_DEFER properly here.
>>
>> I haven't been following the discussions in-depth during all
>> iterations, so perhaps you have already discussed why doing it like
>> this.
>
> Yes, it has been discussed. In order to compare with compatible string
> at dts, we need to have one registered pwrseq instance for each
> pwrseq library, this pre-registered one is allocated using
> postcore_initcall, and the new (eg, second) instance is registered
> after pwrseq_get has succeeded.
I understand you need one compatible per pwrseq library, but how does
that have anything to do with -EPROBE_DEFER?
My point is that, if a driver calls of_pwrseq_on() (which calls
pwrseq_find_available_instance()), but the corresponding pwrseq
library and instance has not yet been registered for that device. Then
how will you handle -EPROBE_DEFER? I guess you simply can't, which is
why *all* pwrseq libraries needs to be registered in early boot phase,
like at postcore_initcall(). Right?
If that is the case, I really don't like it.
Moreover, I have found yet another severe problem but reviewing the code:
In the struct pwrseq, you have a "bool used", which you are setting to
"true" once the pwrseq has been hooked up with the device, when a
driver calls of_pwrseq_on(). Setting that variable to true, will also
prevent another driver from using the same instance of the pwrseq for
its device. So, to cope with multiple users, you register a new
instance of the same pwrseq library that got hooked up, once the
->get() callback is about to complete.
The problem the occurs, when there is another driver calling
of_pwrseq_on() in between, meaning that the new instance has not yet
been registered. This will simply fail, won't it?
Sorry for jumping in late, however to me it seems like there is still
some pieces missing to make this work.
[...]
Kind regards
Uffe
--
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/3] HID: core: remove the absolute need of hid_have_special_driver[]
Most HID devices behave properly when they are used with hid-generic.
Since kernel v4.12, we do not poll for input reports at plug in, so
hid-generic should behave properly with all HID devices.
There has been a long standing list of HID devices that have a special
driver. It used to be just a few, but with time, this list went too big,
and we can not ask users to know which HID special driver will pick up
their device.
We can teach hid-generic to be nice with others. If a device is not
explicitly marked with HID_QUIRK_HAVE_SPECIAL_DRIVER, we can allow
hid-generic to pick up the device as long as no other loaded HID driver
will match the device.
When the special driver appears, hid-generic can step back and let
the special driver handling the device. In case this special driver
is removed, this good old pal of hid-generic will rebind to the device.
This basically makes the list hid_have_special_driver[] useless. It
still allows to not see a hid-generic driver bound and removed during
boot, so we can keep it around.
This will also help other people to have a special HID driver without
the need of recompiling hid-core.
Signed-off-by: Benjamin Tissoires
---
drivers/hid/hid-core.c| 76 ++-
drivers/hid/hid-generic.c | 68 +-
include/linux/hid.h | 10 +++
3 files changed, 125 insertions(+), 29 deletions(-)
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index e6ec9f6..5b84a4f 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -830,31 +830,6 @@ static int hid_scan_report(struct hid_device *hid)
break;
}
- /* fall back to generic driver in case specific driver doesn't exist */
- switch (hid->group) {
- case HID_GROUP_MULTITOUCH_WIN_8:
- /* fall-through */
- case HID_GROUP_MULTITOUCH:
- if (!IS_ENABLED(CONFIG_HID_MULTITOUCH))
- hid->group = HID_GROUP_GENERIC;
- break;
- case HID_GROUP_SENSOR_HUB:
- if (!IS_ENABLED(CONFIG_HID_SENSOR_HUB))
- hid->group = HID_GROUP_GENERIC;
- break;
- case HID_GROUP_RMI:
- if (!IS_ENABLED(CONFIG_HID_RMI))
- hid->group = HID_GROUP_GENERIC;
- break;
- case HID_GROUP_WACOM:
- if (!IS_ENABLED(CONFIG_HID_WACOM))
- hid->group = HID_GROUP_GENERIC;
- break;
- case HID_GROUP_LOGITECH_DJ_DEVICE:
- if (!IS_ENABLED(CONFIG_HID_LOGITECH_DJ))
- hid->group = HID_GROUP_GENERIC;
- break;
- }
vfree(parser);
return 0;
}
@@ -1922,8 +1897,8 @@ static void hid_free_dynids(struct hid_driver *hdrv)
spin_unlock(&hdrv->dyn_lock);
}
-static const struct hid_device_id *hid_match_device(struct hid_device *hdev,
- struct hid_driver *hdrv)
+const struct hid_device_id *hid_match_device(struct hid_device *hdev,
+struct hid_driver *hdrv)
{
struct hid_dynid *dynid;
@@ -1938,6 +1913,7 @@ static const struct hid_device_id
*hid_match_device(struct hid_device *hdev,
return hid_match_id(hdev, hdrv->id_table);
}
+EXPORT_SYMBOL_GPL(hid_match_device);
static int hid_bus_match(struct device *dev, struct device_driver *drv)
{
@@ -1969,6 +1945,23 @@ static int hid_device_probe(struct device *dev)
goto unlock;
}
+ if (hdrv->match) {
+ if (!hdrv->match(hdev, hid_ignore_special_drivers)) {
+ ret = -ENODEV;
+ goto unlock;
+ }
+ } else {
+ /*
+* hid-generic implements .match(), so if
+* hid_ignore_special_drivers is set, we can safely
+* return.
+*/
+ if (hid_ignore_special_drivers) {
+ ret = -ENODEV;
+ goto unlock;
+ }
+ }
+
hdev->driver = hdrv;
if (hdrv->probe) {
ret = hdrv->probe(hdev, id);
@@ -2069,7 +2062,7 @@ static int hid_uevent(struct device *dev, struct
kobj_uevent_env *env)
return 0;
}
-static struct bus_type hid_bus_type = {
+struct bus_type hid_bus_type = {
.name = "hid",
.dev_groups = hid_dev_groups,
.match = hid_bus_match,
@@ -2202,6 +2195,29 @@ void hid_destroy_device(struct hid_device *hdev)
}
EXPORT_SYMBOL_GPL(hid_destroy_device);
+
+static int __bus_add_driver(struct device_driver *drv, void *data)
+{
+ struct hid_driver *added_hdrv = data;
+ struct hid_driver *hdrv = to_hid_driver(drv);
+
+ if (hd
Re: [PATCH v2 1/8] tty: add a poll() callback in struct tty_operations
On Wed, Jun 14, 2017 at 11:20 AM, Tal Shorer wrote: > On Wed, Jun 14, 2017 at 4:15 AM, Alan Cox wrote: >> On Tue, 13 Jun 2017 09:52:07 +0300 >> Tal Shorer wrote: >> >>> 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 >> >> You might be in any line discipline so you need to support that for each >> ldisc that supports poll(). Also what do I do when I get an exception >> event - what does it mean, how do I understand that, are you proposing a >> standardized meaning ? Have you checked whether that conflicts with SuS >> v3 or POSIX ? What will it do with existing code. >> >> At the very least it probably has to be something you turn on, and you >> might then want to model it on the pty/tty interface logic and extend >> TIOCPKT a shade. > That would cut it, but TIOCPKT is too coupled with having a linked tty. > I could make acm behave like a pty (accept TIOCPKT and issue the > ctrl_status bits), but for that I need n_tty to know that packet does > not always mean a linked tty is present, and that in case it isn't we > take our own ctrl_status bits instead of the link's. I could write a > small (inline?) function to fetch the correct ctrl_status bits and put > that in n_tty. Does that make sense? Or (maybe) better yet, I can do a hack and have the acm tty point to itself as the link, which means n_tty doesn't have to change at all. Any thoughts? -- 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/3] HID: quirks: move the list of special devices into a quirk
It is better to centralize the information of special devices in one
single file. Instead of manually parsing the list of devices that
have a special driver or those that need to be ignored, introduce
HID_QUIRK_HAVE_SPECIAL_DRIVER and set the correct quirks while fetching
those quirks.
Signed-off-by: Benjamin Tissoires
---
drivers/hid/hid-core.c| 835 +---
drivers/hid/hid-quirks.c | 866 +-
include/linux/hid.h | 1 +
net/bluetooth/hidp/core.c | 2 +-
4 files changed, 856 insertions(+), 848 deletions(-)
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 953dc41..e6ec9f6 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1862,530 +1862,6 @@ void hid_hw_close(struct hid_device *hdev)
}
EXPORT_SYMBOL_GPL(hid_hw_close);
-/*
- * A list of devices for which there is a specialized driver on HID bus.
- *
- * Please note that for multitouch devices (driven by hid-multitouch driver),
- * there is a proper autodetection and autoloading in place (based on presence
- * of HID_DG_CONTACTID), so those devices don't need to be added to this list,
- * as we are doing the right thing in hid_scan_usage().
- *
- * Autodetection for (USB) HID sensor hubs exists too. If a collection of type
- * physical is found inside a usage page of type sensor, hid-sensor-hub will be
- * used as a driver. See hid_scan_report().
- */
-static const struct hid_device_id hid_have_special_driver[] = {
-#if IS_ENABLED(CONFIG_HID_A4TECH)
- { HID_USB_DEVICE(USB_VENDOR_ID_A4TECH, USB_DEVICE_ID_A4TECH_WCP32PU) },
- { HID_USB_DEVICE(USB_VENDOR_ID_A4TECH, USB_DEVICE_ID_A4TECH_X5_005D) },
- { HID_USB_DEVICE(USB_VENDOR_ID_A4TECH, USB_DEVICE_ID_A4TECH_RP_649) },
-#endif
-#if IS_ENABLED(CONFIG_HID_ACCUTOUCH)
- { HID_USB_DEVICE(USB_VENDOR_ID_ELO, USB_DEVICE_ID_ELO_ACCUTOUCH_2216) },
-#endif
-#if IS_ENABLED(CONFIG_HID_ACRUX)
- { HID_USB_DEVICE(USB_VENDOR_ID_ACRUX, 0x0802) },
- { HID_USB_DEVICE(USB_VENDOR_ID_ACRUX, 0xf705) },
-#endif
-#if IS_ENABLED(CONFIG_HID_ALPS)
- { HID_DEVICE(HID_BUS_ANY, HID_GROUP_ANY, USB_VENDOR_ID_ALPS_JP,
HID_DEVICE_ID_ALPS_U1_DUAL) },
-#endif
-#if IS_ENABLED(CONFIG_HID_APPLE)
- { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_MIGHTYMOUSE)
},
- { HID_USB_DEVICE(USB_VENDOR_ID_APPLE,
USB_DEVICE_ID_APPLE_FOUNTAIN_ANSI) },
- { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_FOUNTAIN_ISO)
},
- { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER_ANSI)
},
- { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER_ISO) },
- { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER_JIS) },
- { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER3_ANSI)
},
- { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER3_ISO)
},
- { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER3_JIS)
},
- { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER4_ANSI)
},
- { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER4_ISO)
},
- { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER4_JIS)
},
- { HID_USB_DEVICE(USB_VENDOR_ID_APPLE,
USB_DEVICE_ID_APPLE_ALU_MINI_ANSI) },
- { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_MINI_ISO)
},
- { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_MINI_JIS)
},
- { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_ANSI) },
- { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_ISO) },
- { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_JIS) },
- { HID_USB_DEVICE(USB_VENDOR_ID_APPLE,
USB_DEVICE_ID_APPLE_GEYSER4_HF_ANSI) },
- { HID_USB_DEVICE(USB_VENDOR_ID_APPLE,
USB_DEVICE_ID_APPLE_GEYSER4_HF_ISO) },
- { HID_USB_DEVICE(USB_VENDOR_ID_APPLE,
USB_DEVICE_ID_APPLE_GEYSER4_HF_JIS) },
- { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE,
USB_DEVICE_ID_APPLE_ALU_WIRELESS_ANSI) },
- { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE,
USB_DEVICE_ID_APPLE_ALU_WIRELESS_ISO) },
- { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE,
USB_DEVICE_ID_APPLE_ALU_WIRELESS_JIS) },
- { HID_USB_DEVICE(USB_VENDOR_ID_APPLE,
USB_DEVICE_ID_APPLE_WELLSPRING_ANSI) },
- { HID_USB_DEVICE(USB_VENDOR_ID_APPLE,
USB_DEVICE_ID_APPLE_WELLSPRING_ISO) },
- { HID_USB_DEVICE(USB_VENDOR_ID_APPLE,
USB_DEVICE_ID_APPLE_WELLSPRING_JIS) },
- { HID_USB_DEVICE(USB_VENDOR_ID_APPLE,
USB_DEVICE_ID_APPLE_WELLSPRING2_ANSI) },
- { HID_USB_DEVICE(USB_VENDOR_ID_APPLE,
USB_DEVICE_ID_APPLE_WELLSPRING2_ISO) },
- { HID_USB_DEVICE(USB_VENDOR_ID_APPLE,
USB_DEVICE_ID_APPLE_WELLSPRING2_JIS) },
- { HID_USB_DEVICE(USB_VENDOR_ID_APPLE,
USB_DEVICE_ID_APPLE_WELLSPRING3_ANSI) },
- { HID_USB_DEVICE(USB_VENDOR_ID_APPLE,
USB_DEVICE_ID_APPLE_WELLSPRING3_ISO) },
-
Re: [PATCH v2 1/8] tty: add a poll() callback in struct tty_operations
On Wed, Jun 14, 2017 at 4:15 AM, Alan Cox wrote: > On Tue, 13 Jun 2017 09:52:07 +0300 > Tal Shorer wrote: > >> 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 > > You might be in any line discipline so you need to support that for each > ldisc that supports poll(). Also what do I do when I get an exception > event - what does it mean, how do I understand that, are you proposing a > standardized meaning ? Have you checked whether that conflicts with SuS > v3 or POSIX ? What will it do with existing code. > > At the very least it probably has to be something you turn on, and you > might then want to model it on the pty/tty interface logic and extend > TIOCPKT a shade. That would cut it, but TIOCPKT is too coupled with having a linked tty. I could make acm behave like a pty (accept TIOCPKT and issue the ctrl_status bits), but for that I need n_tty to know that packet does not always mean a linked tty is present, and that in case it isn't we take our own ctrl_status bits instead of the link's. I could write a small (inline?) function to fetch the correct ctrl_status bits and put that in n_tty. Does that make sense? -- 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: qcserial: new Sierra Wireless EM7305 device ID
On Tue, Jun 13, 2017 at 07:11:42PM +0200, Bjørn Mork wrote: > A new Sierra Wireless EM7305 device ID used in a Toshiba laptop. > > Reported-by: Petr Kloc > Cc: > Signed-off-by: Bjørn Mork Now applied, 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 v4] xhci: AMD Promontory USB disable port support
2017-06-13 20:33 GMT+08:00 Mathias Nyman : > On 13.06.2017 14:26, Jiahau Chang wrote: >> >> 2017-06-07 16:02 GMT+08:00 Mathias Nyman : >>> >>> On 06.06.2017 13:13, Jiahau Chang wrote: v4: Remove the patch code in case USB_PORT_FEAT_REMOTE_WAKE_MASK For AMD Promontory xHCI host, although you can disable USB 2.0 ports in BIOS settings, those ports will be enabled anyway after you remove a device on that port and re-plug it in again. It's a known limitation of the chip. As a workaround we can clear the PORT_WAKE_BITS. Signed-off-by: Jiahau Chang --- drivers/usb/host/xhci-hub.c | 2 ++ drivers/usb/host/xhci-pci.c | 13 + drivers/usb/host/xhci.h | 2 ++ 3 files changed, 17 insertions(+) diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c index 0dde49c..8994676 100644 --- a/drivers/usb/host/xhci-hub.c +++ b/drivers/usb/host/xhci-hub.c @@ -1461,6 +1461,8 @@ int xhci_bus_suspend(struct usb_hcd *hcd) t2 |= PORT_WKOC_E | PORT_WKCONN_E; t2 &= ~PORT_WKDISC_E; } + if ((xhci->quirks & XHCI_U2_DISABLE_WAKE) && (hcd->speed < HCD_USB3)) + t2 &= ~PORT_WAKE_BITS; >>> >>> >>> >>> This will disable connect/disconnect/overcurrent wake for all usb2 ports >>> on >>> AMD Promontory host. >>> I don't think that is what you want. >>> >>> Is there a way for the driver to see which ports are disabled in bios? >>> If yes, then it would be better to just disable wake for those ports >>> >> Sorry for reply late. Our customers always request remote wake-up >> feature only, they don’t want to support >> connect/disconnect/overcurrent wake according to experience on other >> OS. Due to support disable port feature, WOE and WCE bit should be >> disabled. >> > > I'm still a bit uncomfortable with this. > > This change will make a hardcoded policy decision to never support Wake on > Connect/Disconnect/Overcurrent on USB2 ports for any AMD Promontory based > product > now or in the future. > > Is there really no way the driver can know if a port is disabled in BIOS? > Something in ACPI DSDT under xhci or port devices, or some bits in the > PORTSC register? > Thanks for your efforts and your helpful comments in reviewing our patch codes.Your suggestion regarding of disable Wake on Connect/Disconnect/Overcurrent on USB2 ports by BIOS setting, we are going to further research this method. When the port is disabled, we can't get any information from ACPI DSDT or PORTSC register. So far, AMD and customers have verified and confirmed this patch we provided for AMD Promontory on Linux OS. This patch is only for this generation of AMD Promontory. AMD Promontory's customer has struggled the USB port disable problems for a long time and is urgently waiting for this patch can be approved by Linux kernel team. We would be grateful if you could help us to upstream the patch in Linux kernel. > -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] USB: serial: option: add two Longcheer device ids
On Mon, Jun 12, 2017 at 06:14:59PM +0300, Teemu Likonen wrote: > 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! Thank you for testing. I've applied this one now and added the missing Reported-by tags for Bjørn and Lars. Thanks everyone! 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
