[PATCH]fsl/usb: Workarourd for USB erratum-A005697
As per USB specification, in Suspend state the status bit does
not change until the port is suspended. However, there may be a delay
in suspending a port if there is a transaction currently in progress
on the bus.
In the USBDR controller, the PORTSCx[SUSP] bit changes immediately when
the application sets it and not when the port is actually suspended
Workaround for this issue involves waiting for a minimum of 10ms to
allow the controller to go into SUSPEND state before proceeding ahead
Signed-off-by: Ramneek Mehresh ramneek.mehr...@freescale.com
---
drivers/usb/host/ehci-fsl.c | 2 ++
drivers/usb/host/ehci-hub.c | 2 ++
drivers/usb/host/ehci.h | 11 +
drivers/usb/host/fsl-mph-dr-of.c | 52
include/linux/fsl_devices.h | 1 +
5 files changed, 68 insertions(+)
diff --git a/drivers/usb/host/ehci-fsl.c b/drivers/usb/host/ehci-fsl.c
index 947b009..96e0b2b 100644
--- a/drivers/usb/host/ehci-fsl.c
+++ b/drivers/usb/host/ehci-fsl.c
@@ -306,6 +306,8 @@ static int ehci_fsl_usb_setup(struct ehci_hcd *ehci)
out_be32(non_ehci + FSL_SOC_USB_SNOOP2, 0x8000 |
SNOOP_SIZE_2GB);
}
+ if (pdata-has_fsl_erratum_a005697 == 1)
+ ehci-has_fsl_susp_errata = 1;
if ((pdata-operating_mode == FSL_USB2_DR_HOST) ||
(pdata-operating_mode == FSL_USB2_DR_OTG))
if (ehci_fsl_setup_phy(hcd, pdata-phy_mode, 0))
diff --git a/drivers/usb/host/ehci-hub.c b/drivers/usb/host/ehci-hub.c
index 835fc08..d9cb2c2 100644
--- a/drivers/usb/host/ehci-hub.c
+++ b/drivers/usb/host/ehci-hub.c
@@ -284,6 +284,8 @@ static int ehci_bus_suspend (struct usb_hcd *hcd)
else if ((t1 PORT_PE) !(t1 PORT_SUSPEND)) {
t2 |= PORT_SUSPEND;
set_bit(port, ehci-bus_suspended);
+ if (ehci_has_fsl_susp_errata(ehci))
+ usleep_range(1, 2);
}
/* enable remote wakeup on all ports, if told to do so */
diff --git a/drivers/usb/host/ehci.h b/drivers/usb/host/ehci.h
index 291db7d..43f010c 100644
--- a/drivers/usb/host/ehci.h
+++ b/drivers/usb/host/ehci.h
@@ -193,6 +193,7 @@ struct ehci_hcd { /* one per controller */
/* SILICON QUIRKS */
unsignedno_selective_suspend:1;
unsignedhas_fsl_port_bug:1; /* FreeScale */
+ unsignedhas_fsl_susp_errata:1; /*Freescale SUSP quirk*/
unsignedbig_endian_mmio:1;
unsignedbig_endian_desc:1;
unsignedbig_endian_capbase:1;
@@ -636,6 +637,16 @@ ehci_port_speed(struct ehci_hcd *ehci, unsigned int portsc)
#defineehci_has_fsl_portno_bug(e) (0)
#endif
+#if defined(CONFIG_PPC_85xx)
+/* Some Freescale processors have an erratum (USB A-005697) in which
+ * we need to wait for 10ms for bus to fo into suspend mode after
+ * setting SUSP bit
+ */
+#define ehci_has_fsl_susp_errata(e)((e)-has_fsl_susp_errata)
+#else
+#define ehci_has_fsl_susp_errata(e)(0)
+#endif
+
/*
* While most USB host controllers implement their registers in
* little-endian format, a minority (celleb companion chip) implement
diff --git a/drivers/usb/host/fsl-mph-dr-of.c b/drivers/usb/host/fsl-mph-dr-of.c
index 9e0020d..11258c4 100644
--- a/drivers/usb/host/fsl-mph-dr-of.c
+++ b/drivers/usb/host/fsl-mph-dr-of.c
@@ -17,6 +17,7 @@
#include linux/of_platform.h
#include linux/clk.h
#include linux/module.h
+#include asm/mpc85xx.h
struct fsl_usb2_dev_data {
char *dr_mode; /* controller mode */
@@ -119,6 +120,52 @@ error:
static const struct of_device_id fsl_usb2_mph_dr_of_match[];
+static bool has_erratum_a005697(void)
+{
+ unsigned int svr = mfspr(SPRN_SVR);
+ bool flag = false;
+
+ switch (SVR_SOC_VER(svr)) {
+ case SVR_P1010:
+ case SVR_P1014:
+ case SVR_T1040:
+ if (SVR_REV(svr) == 0x10)
+ flag = true;
+ break;
+ case SVR_9132:
+ if ((SVR_REV(svr) == 0x10) || (SVR_REV(svr) == 0x11))
+ flag = true;
+ break;
+ case SVR_P5040:
+ case SVR_P5021:
+ if ((SVR_REV(svr) == 0x10) || (SVR_REV(svr) == 0x20) ||
+ (SVR_REV(svr) == 0x21))
+ flag = true;
+ break;
+ case SVR_T4240:
+ case SVR_T4160:
+ case SVR_P5020:
+ case SVR_P5010:
+ if ((SVR_REV(svr) == 0x10) || (SVR_REV(svr) == 0x20))
+ flag = true;
+ break;
+ case SVR_P2040:
+ case SVR_P2041:
+ case SVR_P3041:
+ if ((SVR_REV(svr) == 0x10) || (SVR_REV(svr) == 0x11) ||
+ (SVR_REV(svr) == 0x20))
+ flag = true;
+ break;
+ case
Re: [PATCH] USBNET: fix handling padding packet
On Wed, 2013-09-18 at 20:56 +0200, Bjørn Mork wrote: Oliver Neukum oneu...@suse.de wrote: No, USB 3.0 uses no companion controllers, so you can have devices of any speed connected to it. Ah, right. I don't own such modern hardware, but I should have known this anyway. This still doesn't change the fact that the driver is brand new for brand new devices. I believe we should assume such devices will support ZLPs unless we have documentation stating anything else. For such devices we might assume it. But how does that matter for generic code? As any kind of device may be connected to XHCI, the sg code is relevant for every driver. And I certainly don't want trouble for older devices' drivers converted to sg. Regards Oliver -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USBNET: fix handling padding packet
Oliver Neukum oneu...@suse.de writes: On Wed, 2013-09-18 at 20:56 +0200, Bjørn Mork wrote: Oliver Neukum oneu...@suse.de wrote: No, USB 3.0 uses no companion controllers, so you can have devices of any speed connected to it. Ah, right. I don't own such modern hardware, but I should have known this anyway. This still doesn't change the fact that the driver is brand new for brand new devices. I believe we should assume such devices will support ZLPs unless we have documentation stating anything else. For such devices we might assume it. But how does that matter for generic code? The code isn't generic yet. Most of it is placed inside the ax88179_178a minidriver. But I do agree that adding this padding support can be seen as one step towards making the code generic. So if you really anticipate this being enabled for e.g. the ECM class driver, then yes, padding must be supported. I would have had less trouble understanding the value if this patch was part of a generalisation series, though... As any kind of device may be connected to XHCI, the sg code is relevant for every driver. And I certainly don't want trouble for older devices' drivers converted to sg. I wonder what the gain of that really is? Yes, I can see the advantage of making the class drivers more effective. But padding is only relevant for the ECM class, isn't it? And are there any ECM class devices where SG support matters? 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 v3 1/1] usb: gadget: zero: Add flexible auto remote wakeup test method
2013/9/19 Peter Chen: + milliseconds to increase successive wakup delays); there's a typo: s/wakup/wakeup/ -- Daniele Forsi -- 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]fsl/usb: Workarourd for USB erratum-A005697
2013/9/19 Ramneek Mehresh: + * we need to wait for 10ms for bus to fo into suspend mode after there's a typo: s/fo/go/ -- Daniele Forsi -- 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] USBNET: fix handling padding packet
I wonder what the gain of that really is? Yes, I can see the advantage of making the class drivers more effective. But padding is only relevant for the ECM class, isn't it? And are there any ECM class devices where SG support matters? AFAICT the requirement for avoiding ZLP is a property of the slave. Support for scatter-gather is a property of the host. So connect an old slave to a modern host and you may be able to use sg to add the header or padding (and possibly have a fragmented skb). Generating frames that would have a ZLP should just be a matter of sending UDP frames with ever increasing lengths - although a printf in the driver would confirm it. However the is a report (somewhere) that it would work sometimes and not others with certain targets. I've got one of the ASIX USB3 devices here, but the system is running ubuntu 12.04 - which doesn't have the sg changes. I've not looked far enough to see if the sg changes in usbnet.c can be applied to that kernel. David
[PATCH] staging: usbip: Fix build on Debian ppc
From: Tobias Polzer tobias.pol...@fau.de One missing include was added. Signed-off-by: Dominik Paulus dominik.pau...@fau.de Signed-off-by: Tobias Polzer tobias.pol...@fau.de --- drivers/staging/usbip/userspace/src/usbip_network.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/staging/usbip/userspace/src/usbip_network.c b/drivers/staging/usbip/userspace/src/usbip_network.c index f5955c2..799a68f 100644 --- a/drivers/staging/usbip/userspace/src/usbip_network.c +++ b/drivers/staging/usbip/userspace/src/usbip_network.c @@ -31,6 +31,10 @@ #include gnutls/gnutls.h #endif +#ifdef HAVE_LIBWRAP +#include tcpd.h +#endif + #include usbip_common.h #include usbip_network.h -- 1.8.4 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] staging: usbip: Fix build on Debian ppc
On Thu, Sep 19, 2013 at 10:55:18AM +0200, Tobias Polzer wrote:
When testing usbip under powerpc, it (unexpectedly) worked, but only after
removing the following lines from vhch_hcd.c:
1004 /* will be removed */
1005 if (pdev-dev.dma_mask) {
1006 dev_info(pdev-dev, vhci_hcd DMA not supported\n);
1007 return -EINVAL;
1008 }
We encountered no problems without those lines. Is it safe to remove this
check?
Hehe. No.
Also which vhch_hcd.c are you talking about? find -name vhch_hcd.c
doesn't show anything.
What the error message?
regards,
dan carpenter
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/7] USB: gadget: s3c-hsotg: fix protocol stall handling
After normal handling of SetupDone interrupt, XferCompl interrupt occurs, and then we enqueue new setup request. But when ep0 is stalled, there is no XferCompl, so we have to enqueue setup request immediately after stalling ep. Otherwise incoming control requests won't be processed correctly. Signed-off-by: Robert Baldyga r.bald...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- drivers/usb/gadget/s3c-hsotg.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/drivers/usb/gadget/s3c-hsotg.c b/drivers/usb/gadget/s3c-hsotg.c index dd5524c..c00ce27 100644 --- a/drivers/usb/gadget/s3c-hsotg.c +++ b/drivers/usb/gadget/s3c-hsotg.c @@ -1146,6 +1146,8 @@ static int s3c_hsotg_process_req_feature(struct s3c_hsotg *hsotg, return 1; } +static void s3c_hsotg_enqueue_setup(struct s3c_hsotg *hsotg); + /** * s3c_hsotg_process_control - process a control request * @hsotg: The device state @@ -1245,11 +1247,15 @@ static void s3c_hsotg_process_control(struct s3c_hsotg *hsotg, * don't believe we need to anything more to get the EP * to reply with a STALL packet */ + +/* + * complete won't be called, so we enqueue + * setup request here + */ +s3c_hsotg_enqueue_setup(hsotg); } } -static void s3c_hsotg_enqueue_setup(struct s3c_hsotg *hsotg); - /** * s3c_hsotg_complete_setup - completion of a setup transfer * @ep: The endpoint the request was on. -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 6/7] USB: gadget: s3c-hsotg: fix clear feature ENDPOINT_HALT
All requests for endpoint are completed when it was halted and the halt was
cleared by CLEAR_FEATURE, but not when new state is same as previous.
Signed-off-by: Robert Baldyga r.bald...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/usb/gadget/s3c-hsotg.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/s3c-hsotg.c b/drivers/usb/gadget/s3c-hsotg.c
index 23eec8f..5c4c41282 100644
--- a/drivers/usb/gadget/s3c-hsotg.c
+++ b/drivers/usb/gadget/s3c-hsotg.c
@@ -1097,6 +1097,7 @@ static int s3c_hsotg_process_req_feature(struct s3c_hsotg
*hsotg,
bool set = (ctrl-bRequest == USB_REQ_SET_FEATURE);
struct s3c_hsotg_ep *ep;
int ret;
+ bool halted;
dev_dbg(hsotg-dev, %s: %s_FEATURE\n,
__func__, set ? SET : CLEAR);
@@ -,6 +1112,8 @@ static int s3c_hsotg_process_req_feature(struct s3c_hsotg
*hsotg,
switch (le16_to_cpu(ctrl-wValue)) {
case USB_ENDPOINT_HALT:
+ halted = ep-halted;
+
s3c_hsotg_ep_sethalt(ep-ep, set);
ret = s3c_hsotg_send_reply(hsotg, ep0, NULL, 0);
@@ -1120,7 +1123,12 @@ static int s3c_hsotg_process_req_feature(struct
s3c_hsotg *hsotg,
return ret;
}
- if (!set) {
+ /*
+* we have to complete all requests for ep if it was
+* halted, and the halt was cleared by CLEAR_FEATURE
+*/
+
+ if (!set halted) {
/*
* If we have request in progress,
* then complete it
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 5/7] USB: gadget: s3c-hsotg: fix halted property updating
Property halted of s3c_hsotg_ep structure is actually initialised when ep
enabled, and changed when halt is set/cleared.
Signed-off-by: Robert Baldyga r.bald...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/usb/gadget/s3c-hsotg.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/usb/gadget/s3c-hsotg.c b/drivers/usb/gadget/s3c-hsotg.c
index e32f868..23eec8f 100644
--- a/drivers/usb/gadget/s3c-hsotg.c
+++ b/drivers/usb/gadget/s3c-hsotg.c
@@ -2605,6 +2605,7 @@ static int s3c_hsotg_ep_enable(struct usb_ep *ep,
/* default, set to non-periodic */
hs_ep-periodic = 0;
+ hs_ep-halted = 0;
switch (desc-bmAttributes USB_ENDPOINT_XFERTYPE_MASK) {
case USB_ENDPOINT_XFER_ISOC:
@@ -2800,6 +2801,8 @@ static int s3c_hsotg_ep_sethalt(struct usb_ep *ep, int
value)
writel(epctl, hs-regs + epreg);
+ hs_ep-halted = value;
+
return 0;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 7/7] USB: gadget: s3c-hsotg: fix interrupt configuration in dedicated-fifo mode
In dedicated-fifo mode TxFIFOEmpty interrupt should be asserted when TxFIFO for this endpoint is completly empty, so NPTxFEmpLvl and PTxFEmpLvl bits are set in GAHBCFG register. In DIEPMSK register INTknTXFEmpMsk is set, becouse it's needed to indicate FIFO Empty state. Signed-off-by: Robert Baldyga r.bald...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- drivers/usb/gadget/s3c-hsotg.c | 14 +- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/drivers/usb/gadget/s3c-hsotg.c b/drivers/usb/gadget/s3c-hsotg.c index 5c4c41282..d5d951d 100644 --- a/drivers/usb/gadget/s3c-hsotg.c +++ b/drivers/usb/gadget/s3c-hsotg.c @@ -2269,15 +2269,19 @@ static void s3c_hsotg_core_init(struct s3c_hsotg *hsotg) GAHBCFG_HBstLen_Incr4, hsotg-regs + GAHBCFG); else - writel(GAHBCFG_GlblIntrEn, hsotg-regs + GAHBCFG); + writel(((hsotg-dedicated_fifos) ? (GAHBCFG_NPTxFEmpLvl | + GAHBCFG_PTxFEmpLvl) : 0) | + GAHBCFG_GlblIntrEn, + hsotg-regs + GAHBCFG); /* -* Enabling INTknTXFEmpMsk here seems to be a big mistake, we end -* up being flooded with interrupts if the host is polling the -* endpoint to try and read data. +* If INTknTXFEmpMsk is enabled, it's important to disable ep interrupts +* when we have no data to transfer. Otherwise we get being flooded by +* interrupts. */ - writel(((hsotg-dedicated_fifos) ? DIEPMSK_TxFIFOEmpty : 0) | + writel(((hsotg-dedicated_fifos) ? DIEPMSK_TxFIFOEmpty | + DIEPMSK_INTknTXFEmpMsk : 0) | DIEPMSK_EPDisbldMsk | DIEPMSK_XferComplMsk | DIEPMSK_TimeOUTMsk | DIEPMSK_AHBErrMsk | DIEPMSK_INTknEPMisMsk, -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 0/7] usb: s3c-hsotg: fixes for proper functioning
Hello, This is a third version of set of patches fixing s3c-hsotg USB driver functioning. From the previous vesrion there are two changes - fixed one small mistake found in one of patches, and add new patch fixing interrupt configuration for dedicated-fifo mode. These patches add few fixes: - Fix protocol stall handling, by enqueue new ep0 request when stalled - Fix s3c_hsotg_write_fifo function to be usable in dedicated-fifo mode. Actually PTxFEmp/NPTxFEmp interrupts are enabled only in shared-fifo mode. - Fix endpoint interrput handling, by disabling interrupts for endpoints which has no requests enqueued. - Fixed DAINT register usage. Now only masked ep interrupts are handled. - Fix halt property updating. - Fix endpoint halt clearing, when it is not currently halted. - Fix interrupt configuration in dedicated fifo mode. Best regards Robert Baldyga Samsung RD Institute Poland Changelog: v3: - in patch 'fix clear feature ENDPOINT_HALT' fixed mistake in that logic OR were used instead of logic AND - add patch setting correct interrupt configuration for dedicated-fifo mode v2: https://lkml.org/lkml/2013/9/18/99 - splitted patches to get one fix in each patch, as Felipe Balbi suggested - fixed typos v1: https://lkml.org/lkml/2013/9/12/324 - initial proposal Robert Baldyga (7): USB: gadget: s3c-hsotg: fix protocol stall handling USB: gadget: s3c-hsotg: fix s3c_hsotg_write_fifo function for dedicated fifo mode USB: gadget: s3c-hsotg: fix endpoint interrupts handling USB: gadget: s3c-hsotg: add DAINT masking USB: gadget: s3c-hsotg: fix halted property updating USB: gadget: s3c-hsotg: fix clear feature ENDPOINT_HALT USB: gadget: s3c-hsotg: fix interrupt configuration in dedicated-fifo mode drivers/usb/gadget/s3c-hsotg.c | 74 +++- 1 file changed, 57 insertions(+), 17 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/7] USB: gadget: s3c-hsotg: fix s3c_hsotg_write_fifo function for dedicated fifo mode
In s3c_hsotg_write_fifo function PTxFEmp/NPTxFEmp interrupts are enabled
only in shared-fifo mode. In dedicated-fifo mode they should not be used
(when enabled then cause interrupt storm).
Signed-off-by: Robert Baldyga r.bald...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/usb/gadget/s3c-hsotg.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/gadget/s3c-hsotg.c b/drivers/usb/gadget/s3c-hsotg.c
index c00ce27..4fe2f9e 100644
--- a/drivers/usb/gadget/s3c-hsotg.c
+++ b/drivers/usb/gadget/s3c-hsotg.c
@@ -553,9 +553,11 @@ static int s3c_hsotg_write_fifo(struct s3c_hsotg *hsotg,
if (to_write hs_ep-ep.maxpacket) {
to_write = hs_ep-ep.maxpacket;
- s3c_hsotg_en_gsint(hsotg,
- periodic ? GINTSTS_PTxFEmp :
- GINTSTS_NPTxFEmp);
+ /* it's needed only when we do not use dedicated fifos */
+ if (!hsotg-dedicated_fifos)
+ s3c_hsotg_en_gsint(hsotg,
+ periodic ? GINTSTS_PTxFEmp :
+ GINTSTS_NPTxFEmp);
}
/* see if we can write data */
@@ -580,9 +582,11 @@ static int s3c_hsotg_write_fifo(struct s3c_hsotg *hsotg,
* is more room left.
*/
- s3c_hsotg_en_gsint(hsotg,
- periodic ? GINTSTS_PTxFEmp :
- GINTSTS_NPTxFEmp);
+ /* it's needed only when we do not use dedicated fifos */
+ if (!hsotg-dedicated_fifos)
+ s3c_hsotg_en_gsint(hsotg,
+ periodic ? GINTSTS_PTxFEmp :
+ GINTSTS_NPTxFEmp);
}
dev_dbg(hsotg-dev, write %d/%d, can_write %d, done %d\n,
--
1.7.9.5
--
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: [Regression/Bug] Webcam is not working and causes crashes since 3.2
Hi, On 09/18/2013 09:55 PM, Frank Dierich wrote: Hi, I have an ASUS A8JP Notebook with a build in webcam and I am using Ubuntu 12.04. The camera is working nice with Cheese and kernels before 3.2. I have tested the following once 2.6.32.61, 2.6.33.20, 2.6.34.11, 2.6.35.14, 2.6.36.4, 2.6.37.6, 2.6.38.8, 2.6.39.4, 3.0.94, 3.1.10. In all later kernels I have tested (3.2.50, 3.4.60, 3.10.10, 3.11.0, 3.12.0-rc1) Cheese shows for some seconds a green and noisy image and crashes then with a segmentation fault. Hans de Goede supposed that the error is caused by usb sub-system because of the errorlogs The error logs are just a hint in the direction of this being an usb (hcd driver?) problem, my main reason for thinking that this is likely an usb problem is that the webcam driver was not changed between 3.1 and 3.2, which is where the regression occurred. [ 1870.806438] gspca_main: ISOC data error: [2] len=0, status=-71 [ 1870.838439] gspca_main: ISOC data error: [21] len=0, status=-71 [ 1870.870438] gspca_main: ISOC data error: [25] len=0, status=-71 I hope this help to resolve the problem. Regards, Hans -- 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] staging: usbip: Fix build on Debian ppc
On September 19, 2013 at 3:40 PM Dominik Paulus domi...@d-paulus.de wrote:
On Thu, Sep 19, 2013 at 12:12:44PM +0300, Dan Carpenter wrote:
On Thu, Sep 19, 2013 at 10:55:18AM +0200, Tobias Polzer wrote:
When testing usbip under powerpc, it (unexpectedly) worked, but only after
removing the following lines from vhch_hcd.c:
1004 /* will be removed */
1005 if (pdev-dev.dma_mask) {
1006 dev_info(pdev-dev, vhci_hcd DMA not supported\n);
1007 return -EINVAL;
1008 }
We encountered no problems without those lines. Is it safe to remove this
check?
Hehe. No.
Also which vhch_hcd.c are you talking about? find -name vhch_hcd.c
doesn't show anything.
Sorry for the typo, we meant vhci_hcd.c in
drivers/staging/usbip/vhci_hcd.c.
What the error message?
When modprobing vhci_hcd.ko, vhci_hcd_probe() fails and returns -EINVAL,
resulting in this error message:
[ 592.623292] vhci_hcd vhci_hcd: vhci_hcd DMA not supported
[ 592.624031] vhci_hcd: probe of vhci_hcd failed with error -22
This leads to the virtual host controller device (vhci) not being
created, so usbip cannot work.
It works after removing the codeblock mentioned above.
We did some research and discovered that dma_mask is only set on PowerPC
at the moment (in arch/powerpc/kernel/setup-common.c,
arch_setup_pdev_archdata()).
All of our testing was done in QEMU emulating Debian on POWER7.
I have already submitted a patch to remove mentioned code block.
patch link : https://lkml.org/lkml/2013/9/10/26
regards,
--navin-patidar
--
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] staging: usbip: Fix build on Debian ppc
Ah, ok. I had no idea what you were talking about before. I thought you were talking about build errors in a file that didn't exist... (Because the subject says build and there was a typo in the file name). Navin, says you can remove it. regards, dan carpenter -- 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/1] usb: gadget: zero: Add flexible auto remote wakeup test method
On Thu, Sep 19, 2013 at 09:24:15AM +0200, Daniele Forsi wrote: 2013/9/19 Peter Chen: + milliseconds to increase successive wakup delays); there's a typo: s/wakup/wakeup/ Thanks, I think I need check more carefully for typo error -- 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
[PATCH] staging: usbip: Fix build with --with-tcp-wrappers
With --with-tcp-wrappers=no specified, the build system reset LIBS to the empty string and thus fails to link against libsysfs. Signed-off-by: Dominik Paulus dominik.pau...@fau.de Signed-off-by: Tobias Polzer tobias.pol...@fau.de --- drivers/staging/usbip/userspace/configure.ac | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/staging/usbip/userspace/configure.ac b/drivers/staging/usbip/userspace/configure.ac index 0b0e035..a1a1267 100644 --- a/drivers/staging/usbip/userspace/configure.ac +++ b/drivers/staging/usbip/userspace/configure.ac @@ -69,7 +69,6 @@ AC_ARG_WITH([tcp-wrappers], [AC_MSG_RESULT([not found]); exit 1]) else AC_MSG_RESULT([no]); -LIBS=$saved_LIBS fi], dnl [ACTION-IF-NOT-GIVEN] [AC_MSG_RESULT([(default)]) -- 1.8.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 v4 1/1] usb: gadget: zero: Add flexible auto remote wakeup test method
In order to increase test coverage, we can change the interval between
two remote wakeups every time, and the interval can be any user defined
values. This change will no affect current behavior if the user does not
use two introduced module parameters.
Signed-off-by: Peter Chen peter.c...@freescale.com
---
Changes for v4:
- Fix more typo
Changes for v3:
- Change typo: s/paramters/parameters
Changes for v2:
- Change some typo and description
drivers/usb/gadget/zero.c | 25 +++--
1 files changed, 23 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/zero.c b/drivers/usb/gadget/zero.c
index 0deb9d6..0dd07ae 100644
--- a/drivers/usb/gadget/zero.c
+++ b/drivers/usb/gadget/zero.c
@@ -95,6 +95,18 @@ unsigned autoresume = DEFAULT_AUTORESUME;
module_param(autoresume, uint, S_IRUGO);
MODULE_PARM_DESC(autoresume, zero, or seconds before remote wakeup);
+/* Maximum Autoresume time */
+unsigned max_autoresume;
+module_param(max_autoresume, uint, S_IRUGO);
+MODULE_PARM_DESC(max_autoresume, maximum seconds before remote wakeup);
+
+/* Interval between two remote wakeups */
+unsigned autoresume_interval_ms;
+module_param(autoresume_interval_ms, uint, S_IRUGO);
+MODULE_PARM_DESC(autoresume_interval_ms,
+ milliseconds to increase successive wakeup delays);
+
+static unsigned autoresume_step_ms;
/*-*/
static struct usb_device_descriptor device_desc = {
@@ -183,8 +195,16 @@ static void zero_suspend(struct usb_composite_dev *cdev)
return;
if (autoresume) {
- mod_timer(autoresume_timer, jiffies + (HZ * autoresume));
- DBG(cdev, suspend, wakeup in %d seconds\n, autoresume);
+ if (max_autoresume
+ (autoresume_step_ms max_autoresume * 1000))
+ autoresume_step_ms = autoresume * 1000;
+
+ mod_timer(autoresume_timer, jiffies +
+ msecs_to_jiffies(autoresume_step_ms));
+ DBG(cdev, suspend, wakeup in %d milliseconds\n,
+ autoresume_step_ms);
+
+ autoresume_step_ms += autoresume_interval_ms;
} else
DBG(cdev, %s\n, __func__);
}
@@ -316,6 +336,7 @@ static int __init zero_bind(struct usb_composite_dev *cdev)
if (autoresume) {
sourcesink_driver.bmAttributes |= USB_CONFIG_ATT_WAKEUP;
loopback_driver.bmAttributes |= USB_CONFIG_ATT_WAKEUP;
+ autoresume_step_ms = autoresume * 1000;
}
/* support OTG systems */
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USBNET: fix handling padding packet
On Thu, Sep 19, 2013 at 3:18 PM, Bjørn Mork bj...@mork.no wrote: Oliver Neukum oneu...@suse.de writes: On Wed, 2013-09-18 at 20:56 +0200, Bjørn Mork wrote: Oliver Neukum oneu...@suse.de wrote: No, USB 3.0 uses no companion controllers, so you can have devices of any speed connected to it. Ah, right. I don't own such modern hardware, but I should have known this anyway. This still doesn't change the fact that the driver is brand new for brand new devices. I believe we should assume such devices will support ZLPs unless we have documentation stating anything else. For such devices we might assume it. But how does that matter for generic code? The code isn't generic yet. Most of it is placed inside the ax88179_178a minidriver. No, the patch doesn't touch code of ax99179_178a. And it is really generic to fix the padding in case of dma sg. But I do agree that adding this padding support can be seen as one step towards making the code generic. So if you really anticipate this being enabled for e.g. the ECM class driver, then yes, padding must be supported. 1byte padding frame is already supported by usbnet before, isn't it? I would have had less trouble understanding the value if this patch was part of a generalisation series, though... As my below test on ax99179_178a, I believe the patch should fix padding for dma sg, but need a little update, and I will send out v1 later: $ping -s 974 another_machine #from host with ax99179_178a attached If FLAG_SEND_ZLP is set for ax99179_178a, the above ping won't work any more either on USB3.0 or USB 2.0 host controller. So don't assume that these brand new devices can support ZLP well. As any kind of device may be connected to XHCI, the sg code is relevant for every driver. And I certainly don't want trouble for older devices' drivers converted to sg. I wonder what the gain of that really is? Yes, I can see the advantage of making the class drivers more effective. But padding is only relevant for the ECM class, isn't it? And are there any ECM class devices where SG support matters? Why is padding only relevant for the ECM? Of course, other devices need it too, such as asix devices. Thanks, -- Ming Lei -- 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]fsl/usb: Workarourd for USB erratum-A005697
On Thu, 19 Sep 2013, Ramneek Mehresh wrote:
As per USB specification, in Suspend state the status bit does
not change until the port is suspended. However, there may be a delay
in suspending a port if there is a transaction currently in progress
on the bus.
In the USBDR controller, the PORTSCx[SUSP] bit changes immediately when
the application sets it and not when the port is actually suspended
Workaround for this issue involves waiting for a minimum of 10ms to
allow the controller to go into SUSPEND state before proceeding ahead
Why is this workaround needed? Does anything go wrong if it isn't
applied?
--- a/drivers/usb/host/ehci-hub.c
+++ b/drivers/usb/host/ehci-hub.c
@@ -284,6 +284,8 @@ static int ehci_bus_suspend (struct usb_hcd *hcd)
else if ((t1 PORT_PE) !(t1 PORT_SUSPEND)) {
t2 |= PORT_SUSPEND;
set_bit(port, ehci-bus_suspended);
+ if (ehci_has_fsl_susp_errata(ehci))
+ usleep_range(1, 2);
}
Notice that there's no delay here for other controller types. Why does
USBDR need a delay?
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
[PATCH 5/7] staging: usbip: Add encryption support to kernel
This adds code performing the actual encryption and authentication
operations in the usbip kernel code. The whole data stream may now be
encrypted and authenticated with AES-GCM and symmetric 128 bit keys.
Signed-off-by: Dominik Paulus dominik.pau...@fau.de
Signed-off-by: Tobias Polzer tobias.pol...@fau.de
---
drivers/staging/usbip/Kconfig| 2 +-
drivers/staging/usbip/stub.h | 3 +
drivers/staging/usbip/stub_dev.c | 8 +
drivers/staging/usbip/usbip_common.c | 342 ++-
drivers/staging/usbip/usbip_common.h | 22 +++
drivers/staging/usbip/vhci_hcd.c | 4 +-
drivers/staging/usbip/vhci_sysfs.c | 10 +
7 files changed, 387 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/usbip/Kconfig b/drivers/staging/usbip/Kconfig
index 8860009..87220af 100644
--- a/drivers/staging/usbip/Kconfig
+++ b/drivers/staging/usbip/Kconfig
@@ -1,6 +1,6 @@
config USBIP_CORE
tristate USB/IP support
- depends on USB NET
+ depends on USB NET CRYPTO_GCM CRYPTO_AES
default N
---help---
This enables pushing USB packets over IP to allow remote
diff --git a/drivers/staging/usbip/stub.h b/drivers/staging/usbip/stub.h
index cfe75d1..2aaea3a 100644
--- a/drivers/staging/usbip/stub.h
+++ b/drivers/staging/usbip/stub.h
@@ -26,6 +26,9 @@
#include linux/types.h
#include linux/usb.h
#include linux/wait.h
+#include linux/crypto.h
+#include linux/err.h
+#include linux/scatterlist.h
#define STUB_BUSID_OTHER 0
#define STUB_BUSID_REMOV 1
diff --git a/drivers/staging/usbip/stub_dev.c b/drivers/staging/usbip/stub_dev.c
index f7bc6e1..0e61efb 100644
--- a/drivers/staging/usbip/stub_dev.c
+++ b/drivers/staging/usbip/stub_dev.c
@@ -21,6 +21,7 @@
#include linux/file.h
#include linux/kthread.h
#include linux/module.h
+#include linux/kfifo.h
#include usbip_common.h
#include stub.h
@@ -137,6 +138,12 @@ static ssize_t store_sockfd(struct device *dev, struct
device_attribute *attr,
spin_unlock_irq(sdev-ud.lock);
+ if (sdev-ud.use_crypto) {
+ err = usbip_init_crypto(sdev-ud, sendkey, recvkey);
+ if (err 0)
+ goto err;
+ }
+
sdev-ud.tcp_rx = kthread_get_run(stub_rx_loop, sdev-ud,
stub_rx);
sdev-ud.tcp_tx = kthread_get_run(stub_tx_loop, sdev-ud,
@@ -298,6 +305,7 @@ static void stub_shutdown_connection(struct usbip_device
*ud)
}
/* 3. free used data */
+ usbip_deinit_crypto(ud);
stub_device_cleanup_urbs(sdev);
/* 4. free stub_unlink */
diff --git a/drivers/staging/usbip/usbip_common.c
b/drivers/staging/usbip/usbip_common.c
index f46c3d2..0729df6 100644
--- a/drivers/staging/usbip/usbip_common.c
+++ b/drivers/staging/usbip/usbip_common.c
@@ -26,6 +26,8 @@
#include linux/module.h
#include linux/moduleparam.h
#include net/sock.h
+#include linux/scatterlist.h
+#include linux/crypto.h
#include usbip_common.h
@@ -626,17 +628,353 @@ static void usbip_pack_iso(struct
usbip_iso_packet_descriptor *iso,
}
}
+int usbip_init_crypto(struct usbip_device *ud, unsigned char *sendkey, unsigned
+ char *recvkey)
+{
+ int ret;
+
+ ud-use_crypto = 1;
+
+ ud-tfm_recv = crypto_alloc_aead(gcm(aes), 0, 0);
+ if (IS_ERR(ud-tfm_recv))
+ return -PTR_ERR(ud-tfm_recv);
+ ud-tfm_send = crypto_alloc_aead(gcm(aes), 0, 0);
+ if (IS_ERR(ud-tfm_send)) {
+ crypto_free_aead(ud-tfm_recv);
+ return -PTR_ERR(ud-tfm_send);
+ }
+ ret = kfifo_alloc(ud-recv_queue, RECVQ_SIZE, GFP_KERNEL);
+ if (ret) {
+ crypto_free_aead(ud-tfm_recv);
+ crypto_free_aead(ud-tfm_send);
+ return ret;
+ }
+
+ if (crypto_aead_setkey(ud-tfm_send, sendkey, USBIP_KEYSIZE) != 0 ||
+ crypto_aead_setkey(ud-tfm_recv, recvkey,
+ USBIP_KEYSIZE) != 0 ||
+ crypto_aead_setauthsize(ud-tfm_send,
+ USBIP_AUTHSIZE) != 0 ||
+ crypto_aead_setauthsize(ud-tfm_recv,
+ USBIP_AUTHSIZE)) {
+ crypto_free_aead(ud-tfm_recv);
+ crypto_free_aead(ud-tfm_send);
+ kfifo_free(ud-recv_queue);
+ }
+
+ ud-ctr_send = 0;
+ ud-ctr_recv = 0;
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(usbip_init_crypto);
+
+void usbip_deinit_crypto(struct usbip_device *ud)
+{
+ if (ud-use_crypto) {
+ crypto_free_aead(ud-tfm_send);
+ crypto_free_aead(ud-tfm_recv);
+ kfifo_free(ud-recv_queue);
+ ud-use_crypto = 0;
+ }
+}
+EXPORT_SYMBOL_GPL(usbip_deinit_crypto);
+
+struct tcrypt_result {
+ struct completion completion;
+ int err;
+};
+
[PATCH 0/7] staging: usbip: Extend crypto support
Hi, this patch series extends our previous set of patches (see [1]). We extended the crypto support so all of the usbip network traffic can now be completely encrypted and authenticated. We now use GnuTLS not only for password verification, but extend the lifetime of the TLS connection to cover all of the userland communications. Before handing over the connection to the kernel, two randomly generated 128 bit session keys are exchanged between client and server and stored in sysfs together with the sockfd. The kernel uses these keys to encrypt and authenticate all of the traffic using AES-GCM and the linux crypto API. Separate keys are used for both directions of the data channel. To the best of our knowledge, the implemented encryption should provide decent security. However, it still lacks complete review; we also note that in the documentation. As mentioned in the project README, the network protocol needs more discussion. This series increments the protocol version, because the improved crypto support breaks compatibility with the previous patch series[1]. In the long term, the protocol should be extended to support proper feature negotiation. If both patch series are merged as one, the protocol version increment can be omitted - both patch series are compatible with unauthenticated transport, but are incompatible with each other. Regards, Tobias Polzer and Dominik Paulus [1] 1379066161-8278-1-git-send-email-dominik.pau...@fau.de, https://lkml.org/lkml/2013/9/13/104 -- 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/7] staging: usbip: TLS for all userspace communication
This patch extends the TLS support to cover all communication in
userspace. The TLS connection is released shortly before the socket is
passed to the kernel.
This requires for additional connection state to be passed between
functions. We thus replaced the sockfd by a struct containing the TLS
context as well as the fd.
Signed-off-by: Dominik Paulus dominik.pau...@fau.de
Signed-off-by: Tobias Polzer tobias.pol...@fau.de
---
drivers/staging/usbip/userspace/src/usbip_attach.c | 24 +-
drivers/staging/usbip/userspace/src/usbip_list.c | 24 +-
.../staging/usbip/userspace/src/usbip_network.c| 279 +
.../staging/usbip/userspace/src/usbip_network.h| 49 +++-
drivers/staging/usbip/userspace/src/usbipd.c | 244 --
5 files changed, 358 insertions(+), 262 deletions(-)
diff --git a/drivers/staging/usbip/userspace/src/usbip_attach.c
b/drivers/staging/usbip/userspace/src/usbip_attach.c
index 651e93a..9f4a064 100644
--- a/drivers/staging/usbip/userspace/src/usbip_attach.c
+++ b/drivers/staging/usbip/userspace/src/usbip_attach.c
@@ -86,7 +86,8 @@ static int record_connection(char *host, char *port, char
*busid, int rhport)
return 0;
}
-static int import_device(int sockfd, struct usbip_usb_device *udev)
+static int import_device(struct usbip_connection *conn, struct usbip_usb_device
+ *udev)
{
int rc;
int port;
@@ -104,8 +105,10 @@ static int import_device(int sockfd, struct
usbip_usb_device *udev)
return -1;
}
- rc = usbip_vhci_attach_device(port, sockfd, udev-busnum,
+ usbip_net_bye(conn);
+ rc = usbip_vhci_attach_device(port, conn-sockfd, udev-busnum,
udev-devnum, udev-speed);
+
if (rc 0) {
err(import device);
usbip_vhci_driver_close();
@@ -117,7 +120,7 @@ static int import_device(int sockfd, struct
usbip_usb_device *udev)
return port;
}
-static int query_import_device(int sockfd, char *busid)
+static int query_import_device(struct usbip_connection *conn, char *busid)
{
int rc;
struct op_import_request request;
@@ -128,7 +131,7 @@ static int query_import_device(int sockfd, char *busid)
memset(reply, 0, sizeof(reply));
/* send a request */
- rc = usbip_net_send_op_common(sockfd, OP_REQ_IMPORT, 0);
+ rc = usbip_net_send_op_common(conn, OP_REQ_IMPORT, 0);
if (rc 0) {
err(send op_common);
return -1;
@@ -138,20 +141,20 @@ static int query_import_device(int sockfd, char *busid)
PACK_OP_IMPORT_REQUEST(0, request);
- rc = usbip_net_send(sockfd, (void *) request, sizeof(request));
+ rc = usbip_net_send(conn, (void *) request, sizeof(request));
if (rc 0) {
err(send op_import_request);
return -1;
}
/* receive a reply */
- rc = usbip_net_recv_op_common(sockfd, code);
+ rc = usbip_net_recv_op_common(conn, code);
if (rc 0) {
err(recv op_common: %s, usbip_net_strerror(rc));
return -1;
}
- rc = usbip_net_recv(sockfd, (void *) reply, sizeof(reply));
+ rc = usbip_net_recv(conn, (void *) reply, sizeof(reply));
if (rc 0) {
err(recv op_import_reply);
return -1;
@@ -166,7 +169,7 @@ static int query_import_device(int sockfd, char *busid)
}
/* import a device */
- return import_device(sockfd, reply.udev);
+ return import_device(conn, reply.udev);
}
static int attach_device(char *host, char *busid)
@@ -174,14 +177,15 @@ static int attach_device(char *host, char *busid)
int sockfd;
int rc;
int rhport;
+ struct usbip_connection conn;
- sockfd = usbip_net_connect(host);
+ sockfd = usbip_net_connect(host, conn);
if (sockfd 0) {
err(connection attempt failed);
return -1;
}
- rhport = query_import_device(sockfd, busid);
+ rhport = query_import_device(conn, busid);
if (rhport 0) {
err(query);
return -1;
diff --git a/drivers/staging/usbip/userspace/src/usbip_list.c
b/drivers/staging/usbip/userspace/src/usbip_list.c
index ff7acf8..187eb7d 100644
--- a/drivers/staging/usbip/userspace/src/usbip_list.c
+++ b/drivers/staging/usbip/userspace/src/usbip_list.c
@@ -45,7 +45,7 @@ void usbip_list_usage(void)
printf(usage: %s, usbip_list_usage_string);
}
-static int get_exported_devices(char *host, int sockfd)
+static int get_exported_devices(char *host, struct usbip_connection *conn)
{
char product_name[100];
char class_name[100];
@@ -56,13 +56,13 @@ static int get_exported_devices(char *host, int sockfd)
unsigned int i;
int j, rc;
- rc = usbip_net_send_op_common(sockfd, OP_REQ_DEVLIST, 0);
+ rc =
[PATCH 2/7] staging: usbip: Exchange session keys in userspace
In preparation for the kernel crypto support, we exchange two - randomly
generated - session keys between usbip and usbipd to be used for
encrypting all traffic generated in kernelspace. We use two different
128-bit keys, one for sending and one for receiving. Both are generated
by the client (usbip, probably has more entropy available than the
server) and transferred over the already established TLS connection.
As this breaks compatibility with older clients supporting userspace
encryption, the protocol version is increased.
Signed-off-by: Dominik Paulus dominik.pau...@fau.de
Signed-off-by: Tobias Polzer tobias.pol...@fau.de
---
.../staging/usbip/userspace/libsrc/usbip_common.h | 21 ++
.../usbip/userspace/libsrc/usbip_host_driver.c | 5 ++-
.../usbip/userspace/libsrc/usbip_host_driver.h | 3 +-
.../staging/usbip/userspace/libsrc/vhci_driver.c | 19 +++--
.../staging/usbip/userspace/libsrc/vhci_driver.h | 9 ++---
drivers/staging/usbip/userspace/src/usbip_attach.c | 47 +-
.../staging/usbip/userspace/src/usbip_network.h| 2 +-
drivers/staging/usbip/userspace/src/usbipd.c | 32 ---
8 files changed, 106 insertions(+), 32 deletions(-)
diff --git a/drivers/staging/usbip/userspace/libsrc/usbip_common.h
b/drivers/staging/usbip/userspace/libsrc/usbip_common.h
index 938ad1c..f804c04 100644
--- a/drivers/staging/usbip/userspace/libsrc/usbip_common.h
+++ b/drivers/staging/usbip/userspace/libsrc/usbip_common.h
@@ -127,6 +127,27 @@ struct usbip_usb_device {
uint8_t bNumInterfaces;
} __attribute__((packed));
+
+/*
+ * These structs contain the configuration
+ * data to be passed to the kernel
+ */
+struct host_conf {
+ int sockfd;
+ uint8_t use_crypto;
+ uint8_t key1[16];
+ uint8_t key2[16];
+};
+struct vhci_conf {
+ uint8_t port;
+ int sockfd;
+ uint32_t devid;
+ uint32_t speed;
+ uint8_t use_crypto;
+ uint8_t key1[16];
+ uint8_t key2[16];
+};
+
#define to_string(s) #s
void dump_usb_interface(struct usbip_usb_interface *);
diff --git a/drivers/staging/usbip/userspace/libsrc/usbip_host_driver.c
b/drivers/staging/usbip/userspace/libsrc/usbip_host_driver.c
index 71a449c..60247f2 100644
--- a/drivers/staging/usbip/userspace/libsrc/usbip_host_driver.c
+++ b/drivers/staging/usbip/userspace/libsrc/usbip_host_driver.c
@@ -332,7 +332,8 @@ int usbip_host_refresh_device_list(void)
return 0;
}
-int usbip_host_export_device(struct usbip_exported_device *edev, int sockfd)
+int usbip_host_export_device(struct usbip_exported_device *edev,
+ struct host_conf *conf)
{
char attr_name[] = usbip_sockfd;
char attr_path[SYSFS_PATH_MAX];
@@ -366,7 +367,7 @@ int usbip_host_export_device(struct usbip_exported_device
*edev, int sockfd)
return -1;
}
- snprintf(sockfd_buff, sizeof(sockfd_buff), %d\n, sockfd);
+ snprintf(sockfd_buff, sizeof(sockfd_buff), %d\n, conf-sockfd);
dbg(write: %s, sockfd_buff);
ret = sysfs_write_attribute(attr, sockfd_buff, strlen(sockfd_buff));
diff --git a/drivers/staging/usbip/userspace/libsrc/usbip_host_driver.h
b/drivers/staging/usbip/userspace/libsrc/usbip_host_driver.h
index 34fd14c..ceaf7cc 100644
--- a/drivers/staging/usbip/userspace/libsrc/usbip_host_driver.h
+++ b/drivers/staging/usbip/userspace/libsrc/usbip_host_driver.h
@@ -42,7 +42,8 @@ int usbip_host_driver_open(void);
void usbip_host_driver_close(void);
int usbip_host_refresh_device_list(void);
-int usbip_host_export_device(struct usbip_exported_device *edev, int sockfd);
+int usbip_host_export_device(struct usbip_exported_device *edev,
+ struct host_conf *conf);
struct usbip_exported_device *usbip_host_get_device(int num);
#endif /* __USBIP_HOST_DRIVER_H */
diff --git a/drivers/staging/usbip/userspace/libsrc/vhci_driver.c
b/drivers/staging/usbip/userspace/libsrc/vhci_driver.c
index 1091bb2..d1d45bb 100644
--- a/drivers/staging/usbip/userspace/libsrc/vhci_driver.c
+++ b/drivers/staging/usbip/userspace/libsrc/vhci_driver.c
@@ -467,8 +467,8 @@ int usbip_vhci_get_free_port(void)
return -1;
}
-int usbip_vhci_attach_device2(uint8_t port, int sockfd, uint32_t devid,
- uint32_t speed) {
+int usbip_vhci_attach_device(struct vhci_conf *conf)
+{
struct sysfs_attribute *attr_attach;
char buff[200]; /* what size should be ? */
int ret;
@@ -481,7 +481,7 @@ int usbip_vhci_attach_device2(uint8_t port, int sockfd,
uint32_t devid,
}
snprintf(buff, sizeof(buff), %u %u %u %u,
- port, sockfd, devid, speed);
+ conf-port, conf-sockfd, conf-devid, conf-speed);
dbg(writing: %s, buff);
ret = sysfs_write_attribute(attr_attach, buff, strlen(buff));
@@ -490,25 +490,16 @@ int usbip_vhci_attach_device2(uint8_t port, int sockfd,
uint32_t devid,
return -1;
[PATCH 4/7] staging: usbip: Wrap kernel_sendmsg()/recvmsg()
This adds two simple wrappers around kernel_sendmsg() and
kernel_recvmsg() that can be extended to perform additional
cryptographic operations on the data before sending it.
Signed-off-by: Dominik Paulus dominik.pau...@fau.de
Signed-off-by: Tobias Polzer tobias.pol...@fau.de
---
drivers/staging/usbip/stub_rx.c | 2 +-
drivers/staging/usbip/stub_tx.c | 6 ++--
drivers/staging/usbip/usbip_common.c | 66
drivers/staging/usbip/usbip_common.h | 7 +++-
drivers/staging/usbip/vhci_rx.c | 2 +-
drivers/staging/usbip/vhci_tx.c | 4 +--
6 files changed, 48 insertions(+), 39 deletions(-)
diff --git a/drivers/staging/usbip/stub_rx.c b/drivers/staging/usbip/stub_rx.c
index db48a78..6ba9969 100644
--- a/drivers/staging/usbip/stub_rx.c
+++ b/drivers/staging/usbip/stub_rx.c
@@ -553,7 +553,7 @@ static void stub_rx_pdu(struct usbip_device *ud)
memset(pdu, 0, sizeof(pdu));
/* receive a pdu header */
- ret = usbip_recv(ud-tcp_socket, pdu, sizeof(pdu));
+ ret = usbip_recv(ud, pdu, sizeof(pdu));
if (ret != sizeof(pdu)) {
dev_err(dev, recv a header, %d\n, ret);
usbip_event_add(ud, SDEV_EVENT_ERROR_TCP);
diff --git a/drivers/staging/usbip/stub_tx.c b/drivers/staging/usbip/stub_tx.c
index cd5326a..9a9f9e6 100644
--- a/drivers/staging/usbip/stub_tx.c
+++ b/drivers/staging/usbip/stub_tx.c
@@ -257,8 +257,7 @@ static int stub_send_ret_submit(struct stub_device *sdev)
iovnum++;
}
- ret = kernel_sendmsg(sdev-ud.tcp_socket, msg,
- iov, iovnum, txsize);
+ ret = usbip_sendmsg(sdev-ud, msg, iov, iovnum, txsize);
if (ret != txsize) {
dev_err(sdev-interface-dev,
sendmsg failed!, retval %d for %zd\n,
@@ -332,8 +331,7 @@ static int stub_send_ret_unlink(struct stub_device *sdev)
iov[0].iov_len = sizeof(pdu_header);
txsize += sizeof(pdu_header);
- ret = kernel_sendmsg(sdev-ud.tcp_socket, msg, iov,
-1, txsize);
+ ret = usbip_sendmsg(sdev-ud, msg, iov, 1, txsize);
if (ret != txsize) {
dev_err(sdev-interface-dev,
sendmsg failed!, retval %d for %zd\n,
diff --git a/drivers/staging/usbip/usbip_common.c
b/drivers/staging/usbip/usbip_common.c
index e3fc749..f46c3d2 100644
--- a/drivers/staging/usbip/usbip_common.c
+++ b/drivers/staging/usbip/usbip_common.c
@@ -339,7 +339,7 @@ void usbip_dump_header(struct usbip_header *pdu)
EXPORT_SYMBOL_GPL(usbip_dump_header);
/* Receive data over TCP/IP. */
-int usbip_recv(struct socket *sock, void *buf, int size)
+int usbip_recv(struct usbip_device *ud, void *buf, int size)
{
int result;
struct msghdr msg;
@@ -352,34 +352,29 @@ int usbip_recv(struct socket *sock, void *buf, int size)
usbip_dbg_xmit(enter\n);
- if (!sock || !buf || !size) {
- pr_err(invalid arg, sock %p buff %p size %d\n, sock, buf,
+ if (!ud || !buf || !size) {
+ pr_err(invalid arg, ud %p buff %p size %d\n, ud, buf,
size);
return -EINVAL;
}
- do {
- sock-sk-sk_allocation = GFP_NOIO;
- iov.iov_base= buf;
- iov.iov_len = size;
- msg.msg_name= NULL;
- msg.msg_namelen = 0;
- msg.msg_control = NULL;
- msg.msg_controllen = 0;
- msg.msg_namelen= 0;
- msg.msg_flags = MSG_NOSIGNAL;
-
- result = kernel_recvmsg(sock, msg, iov, 1, size, MSG_WAITALL);
- if (result = 0) {
- pr_debug(receive sock %p buf %p size %u ret %d total
%d\n,
-sock, buf, size, result, total);
- goto err;
- }
-
- size -= result;
- buf += result;
- total += result;
- } while (size 0);
+ ud-tcp_socket-sk-sk_allocation = GFP_NOIO;
+ iov.iov_base= buf;
+ iov.iov_len = size;
+ msg.msg_name= NULL;
+ msg.msg_namelen = 0;
+ msg.msg_control = NULL;
+ msg.msg_controllen = 0;
+ msg.msg_namelen= 0;
+ msg.msg_flags = MSG_NOSIGNAL;
+
+ result = usbip_recvmsg(ud, msg, iov, 1, size, MSG_WAITALL);
+
+ if (result 0) {
+ pr_debug(receive sock %p buf %p size %u ret %d total %d\n,
+ud-tcp_socket, buf, size, result, total);
+ return result;
+ }
if (usbip_dbg_flag_xmit) {
if (!in_interrupt())
@@ -393,9 +388,6 @@ int usbip_recv(struct socket *sock, void *buf, int size)
osize, result, size, total);
[PATCH 7/7] staging: usbip: Increment version number to 1.2.1
Also increment the kernel module version number to match the userspace version, as compatibility with old userspace utilities is now at least partially broken. Signed-off-by: Dominik Paulus dominik.pau...@fau.de Signed-off-by: Tobias Polzer tobias.pol...@fau.de --- drivers/staging/usbip/usbip_common.h | 2 +- drivers/staging/usbip/userspace/configure.ac | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/usbip/usbip_common.h b/drivers/staging/usbip/usbip_common.h index 2b71c58..82a3e12 100644 --- a/drivers/staging/usbip/usbip_common.h +++ b/drivers/staging/usbip/usbip_common.h @@ -31,7 +31,7 @@ #include linux/wait.h #include linux/kfifo.h -#define USBIP_VERSION 1.0.0 +#define USBIP_VERSION 1.2.1 /* * Length of the authentication tag associated with each packet, in bytes. Can diff --git a/drivers/staging/usbip/userspace/configure.ac b/drivers/staging/usbip/userspace/configure.ac index a1a1267..26dabe3 100644 --- a/drivers/staging/usbip/userspace/configure.ac +++ b/drivers/staging/usbip/userspace/configure.ac @@ -1,7 +1,7 @@ dnl Process this file with autoconf to produce a configure script. AC_PREREQ(2.59) -AC_INIT([usbip-utils], [1.2.0], [linux-usb@vger.kernel.org]) +AC_INIT([usbip-utils], [1.2.1], [linux-usb@vger.kernel.org]) CURRENT=0 REVISION=1 -- 1.8.4 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/7] staging: usbip: Update documentation
From: Tobias Polzer tobias.pol...@fau.de README was updated and cleaned. It now contains just one example, which was updated to use encryption. Also, the new crypto behaviour is documented. The usbip port command has been removed from the README, as it isn't supported by newer userland versions. One dead link was removed from the checklist section. Signed-off-by: Tobias Polzer tobias.pol...@fau.de Signed-off-by: Dominik Paulus dominik.pau...@fau.de --- drivers/staging/usbip/userspace/README | 72 +++- drivers/staging/usbip/userspace/doc/usbipd.8 | 4 +- 2 files changed, 31 insertions(+), 45 deletions(-) diff --git a/drivers/staging/usbip/userspace/README b/drivers/staging/usbip/userspace/README index 00a1658..01ea616 100644 --- a/drivers/staging/usbip/userspace/README +++ b/drivers/staging/usbip/userspace/README @@ -12,56 +12,53 @@ - sysfsutils = 2.0.0 sysfsutils library -- libwrap0-dev +- libwrap0-dev (optional) tcp wrapper library - gcc = 4.0 - libtool, automake = 1.9, autoconf = 2.5.0, pkg-config +- libgnutls-dev = 3.0 (libgnutls28-dev on debian) (optional) + [Install] 0. Generate configuration scripts. $ ./autogen.sh 1. Compile install the userspace utilities. - $ ./configure [--with-tcp-wrappers=no] [--with-usbids-dir=dir] + $ ./configure [--with-tcp-wrappers=no] [--with-usbids-dir=dir] [--with-gnutls] $ make install 2. Compile install USB/IP drivers. [Usage] -server:# (Physically attach your USB device.) - -server:# insmod usbip-core.ko -server:# insmod usbip-host.ko - -server:# usbipd -D - - Start usbip daemon. - -server:# usbip list -l - - List driver assignments for USB devices. -server:# usbip bind --busid 1-2 - - Bind usbip-host.ko to the device with busid 1-2. - - The USB device 1-2 is now exportable to other hosts! - - Use `usbip unbind --busid 1-2' to stop exporting the device. +See usbip(8) and usbipd(8). -client:# insmod usbip-core.ko -client:# insmod vhci-hcd.ko +[Security considerations] +By default, all of the usbip network traffic is unencrypted and +unauthenticated. As it is mostly parsed in staging quality kernel code, you +should use usbip in this mode only in absolutely trusted environments. -client:# usbip list --remote host - - List exported USB devices on the host. +In addition to the usual methods for secure network tunneling - SSH tunnels, +IPsec, etc. -, usbip version 1.2.1 supports out-of-the-box crypto for all of +the network traffic. This requires usbip to be compiled with GnuTLS enabled +(configure switch: --with-gnutls). Crypto support can be enabled by using +password authentication. If the --auth flag is set, usbip will not only +authenticate client and server using the shared passphrase, but also encrypt +and authenticate all of the following traffic. For the userspace traffic, +GnuTLS is used, the kernel traffic is encrypted and authenticated using AES-GCM +with 128bit keys. The session keys are randomly generated and exchanged for +in userspace for each connection. -client:# usbip attach --remote host --busid 1-2 - - Connect the remote USB device. - -client:# usbip port - - Show virtual port status. - -client:# usbip detach --port port - - Detach the USB device. +The encryption support has been designed to offer perfect forward secrecy and +decent security even if using rather weak passwords. Strong passwords are +mainly needed to provide proper authorization (this is still important, see +above!) and to secure against man-in-the-middle attacks. +However, the crypto code still lacks complete review and code auditing. Do not +rely on it for strong security. [Example] @@ -72,7 +69,7 @@ Physically attach your USB devices to this host. trois:# insmod path/to/usbip-core.ko trois:# insmod path/to/usbip-host.ko -trois:# usbipd -D +trois:# usbipd -sVerySecret -D In another terminal, let's look up what USB devices are physically attached to this host. @@ -135,7 +132,7 @@ exportable on the host. deux:# insmod path/to/usbip-core.ko deux:# insmod path/to/vhci-hcd.ko -deux:# usbip list --remote 10.0.0.3 +deux:# usbip --auth VerySecret list --remote 10.0.0.3 Exportable USB devices == - 10.0.0.3 @@ -163,20 +160,9 @@ exportable on the host. Attach a remote USB device: -deux:# usbip attach --remote 10.0.0.3 --busid 1-1 +deux:# usbip --auth VerySecret attach --remote 10.0.0.3 --busid 1-1 port 0 attached -Show the devices attached to this client: - -deux:# usbip port -Port 00: Port in Use at Full Speed(12Mbps) - Prolific Technology, Inc. : unknown product (067b:3507) - 6-1 - usbip://10.0.0.3:3240/1-1 (remote bus/dev 001/004) - 6-1:1.0 used by usb-storage -
[PATCH 3/7] staging: usbip: Pass session keys to the kernel
This extends the userspace code to write the generated session keys to
sysfs in hexadecimal encoding after establishing the connection.
The kernel code is modified to parse the session keys.
Signed-off-by: Dominik Paulus dominik.pau...@fau.de
Signed-off-by: Tobias Polzer tobias.pol...@fau.de
---
drivers/staging/usbip/stub_dev.c | 26 +++-
drivers/staging/usbip/usbip_common.h | 10
.../staging/usbip/userspace/libsrc/usbip_common.c | 14 +++
.../staging/usbip/userspace/libsrc/usbip_common.h | 2 ++
.../usbip/userspace/libsrc/usbip_host_driver.c | 15
.../staging/usbip/userspace/libsrc/vhci_driver.c | 8 ---
drivers/staging/usbip/vhci_sysfs.c | 28 +-
7 files changed, 94 insertions(+), 9 deletions(-)
diff --git a/drivers/staging/usbip/stub_dev.c b/drivers/staging/usbip/stub_dev.c
index c44d5f2..f7bc6e1 100644
--- a/drivers/staging/usbip/stub_dev.c
+++ b/drivers/staging/usbip/stub_dev.c
@@ -87,13 +87,37 @@ static ssize_t store_sockfd(struct device *dev, struct
device_attribute *attr,
int sockfd = 0;
struct socket *socket;
ssize_t err = -EINVAL;
+ char sendkey[USBIP_KEYSIZE], recvkey[USBIP_KEYSIZE];
+ char sendkey_hex[2 * USBIP_KEYSIZE + 1];
+ char recvkey_hex[2 * USBIP_KEYSIZE + 1];
if (!sdev) {
dev_err(dev, sdev is null\n);
return -ENODEV;
}
- sscanf(buf, %d, sockfd);
+ /*
+* Read symmetric crypto keys. They are randomly
+* generated by userspace and passed to the kernel
+* via sysfs (encoded in hexadecimal)
+*/
+ if (sscanf(buf, %d %d %32s %32s, sockfd, sdev-ud.use_crypto,
+ sendkey_hex, recvkey_hex) 1) {
+ dev_err(dev, Invalid write to sysfs: Invalid sockfd\n);
+ return -EINVAL;
+ }
+ if (sdev-ud.use_crypto) {
+ int i;
+ dev_info(dev, Using encrypted data transport\n);
+ for (i = USBIP_KEYSIZE - 1; i = 0; --i) {
+ sendkey_hex[2 * (i + 1)] = 0;
+ sscanf(sendkey_hex + (2 * i), %2hhX, sendkey[i]);
+ }
+ for (i = USBIP_KEYSIZE - 1; i = 0; --i) {
+ recvkey_hex[2 * (i + 1)] = 0;
+ sscanf(recvkey_hex + (2 * i), %2hhX, recvkey[i]);
+ }
+ }
if (sockfd != -1) {
dev_info(dev, stub up\n);
diff --git a/drivers/staging/usbip/usbip_common.h
b/drivers/staging/usbip/usbip_common.h
index 7e6c543..96c87ee 100644
--- a/drivers/staging/usbip/usbip_common.h
+++ b/drivers/staging/usbip/usbip_common.h
@@ -32,6 +32,13 @@
#define USBIP_VERSION 1.0.0
+/*
+ * Length of symmetric keys. Currently, this should be fixed at 16 bytes.
+ * Will break code if changed, look at userspace and stub_dev.c/vhci_sysfs.c
+ * where this constant is used before changing.
+ */
+#define USBIP_KEYSIZE 16
+
#undef pr_fmt
#ifdef DEBUG
@@ -290,6 +297,9 @@ struct usbip_device {
void (*reset)(struct usbip_device *);
void (*unusable)(struct usbip_device *);
} eh_ops;
+
+ /* Crypto support */
+ int use_crypto;
};
#define kthread_get_run(threadfn, data, namefmt, ...) \
diff --git a/drivers/staging/usbip/userspace/libsrc/usbip_common.c
b/drivers/staging/usbip/userspace/libsrc/usbip_common.c
index 17e08e0..1ec9cc9 100644
--- a/drivers/staging/usbip/userspace/libsrc/usbip_common.c
+++ b/drivers/staging/usbip/userspace/libsrc/usbip_common.c
@@ -290,3 +290,17 @@ void usbip_names_get_class(char *buff, size_t size,
uint8_t class,
snprintf(buff, size, %s / %s / %s (%02x/%02x/%02x), c, s, p, class,
subclass, protocol);
}
+
+/*
+ * Converts a 16-byte key to hexadecimal to be pushed to kernelspace
+ *
+ * Output buffer must be at least 33 bytes long
+ */
+char *keytohex(unsigned char *key, char *out)
+{
+ int i;
+ out[32] = 0;
+ for (i = 0; i != 16; ++i)
+ sprintf(out + (2 * i), %02X, key[i]);
+ return out;
+}
diff --git a/drivers/staging/usbip/userspace/libsrc/usbip_common.h
b/drivers/staging/usbip/userspace/libsrc/usbip_common.h
index f804c04..a5d4d21 100644
--- a/drivers/staging/usbip/userspace/libsrc/usbip_common.h
+++ b/drivers/staging/usbip/userspace/libsrc/usbip_common.h
@@ -168,4 +168,6 @@ void usbip_names_get_product(char *buff, size_t size,
uint16_t vendor,
void usbip_names_get_class(char *buff, size_t size, uint8_t class,
uint8_t subclass, uint8_t protocol);
+char *keytohex(unsigned char *key, char *out);
+
#endif /* __USBIP_COMMON_H */
diff --git a/drivers/staging/usbip/userspace/libsrc/usbip_host_driver.c
b/drivers/staging/usbip/userspace/libsrc/usbip_host_driver.c
index 60247f2..be08ad7 100644
--- a/drivers/staging/usbip/userspace/libsrc/usbip_host_driver.c
Getting udev name from usb_device structure
Hi all! I'm writting a LSM hook in order to allow to mount just only some particular USB Mass Storage devices according to their idVendor, idProduct, and Serial. The hook is executed when a device is going to be mounted, and it has the following prototype: static int sb_mount(const char *dev_name, struct path *path, const char *type, unsigned long flags, void *data) The relevant parameter here is dev_name, which provides the name of the device to be mounted in a udev style (e.g. /dev/sdb1). So, the main idea to perform the mount restriction inside the hook is, firstly, to determine if there is a USB Mass Storage device connected to the system which is identified as dev_name. After that, I will inspect if it's corresponding idVendor, idProduct and serial are considered valid according to a given list of authorized devices, and then allow the mount. Currently, I'm using the usb_for_each_dev function, which gives me access to the idVendor, idProduct and serial of all the USB devices by means of the usb_device structure. However, I don't know how I can determine which is the udev device name associated to each usb_device structure. I have observed that the name of the udev device is present in the sysfs, so I guess that by accesing to the kobject of the usb_device I could obtain such mapping (usb_device - udev name). I also know that the Mass Storage Devices are considered as SCSI devices, so I guess that the name can also be obtained from a structure related with the SCSI subsystem. The problem is that I don't know which is the best way to find the mapping between the usb_device and the dev_name parameter. I have tried to inspect all the related structures without any success :-( Can anyone advise me about how can I obtain the udev device name of a USB by means of the usb_device structure. Any other better idea will be appreciated :-) Sergio -- 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 00/51] DMA mask changes
This started out as a request to look at the DMA mask situation, and how to solve the issues which we have on ARM - notably how the DMA mask should be setup. However, I started off reviewing how the dma_mask and coherent_dma_mask was being used, and what I found was rather messy, and in some cases rather buggy. I tried to get some of the bug fixes in before the last merge window, but it seems that the maintainers preferred to have the full solution rather than a simple -rc suitable bug fix. So, this is an attempt to clean things up. The first point here is that drivers performing DMA should be calling dma_set_mask()/dma_set_coherent_mask() in their probe function to verify that DMA can be performed. Lots of ARM drivers omit this step; please refer to the DMA API documentation on this subject. What this means is that the DMA mask provided by bus code is a default value - nothing more. It doesn't have to accurately reflect what the device is actually capable of. Apart from the storage for dev-dma_mask being initialised for any device which is DMA capable, there is no other initialisation which is strictly necessary at device creation time. Now, these cleanups address two major areas: 1. The setting of DMA masks, particularly when both the coherent and streaming DMA masks are set together. 2. The initialisation of DMA masks by drivers - this seems to be becoming a popular habbit, one which may not be entirely the right solution. Rather than having this scattered throughout the tree, I've pulled that into a central location (and called it coercing the DMA mask - because it really is about forcing the DMA mask to be that value.) 3. Finally, addressing the long held misbelief that DMA masks somehow correspond with physical addresses. We already have established long ago that dma_addr_t values returned from the DMA API are the values which you program into the DMA controller, and so are the bus addresses. It is _only_ sane that DMA masks are also bus related too, and not related to physical address spaces. (3) is a very important point for LPAE systems, which may still have less than 4GB of memory, but this memory is all located above the 4GB physical boundary. This means with the current model, any device using a 32-bit DMA mask fails - even though the DMA controller is still only a 32-bit DMA controller but the 32-bit bus addresses map to system memory. To put it another way, the bus addresses have a 4GB physical offset on them. This email is only being sent to the mailing lists in question, not to anyone personally. The list of individuals is far to great to do that. I'm hoping no mailing lists reject the patches based on the number of recipients. Patches based on v3.12-rc1. Documentation/DMA-API-HOWTO.txt | 37 +-- Documentation/DMA-API.txt |8 +++ arch/arm/include/asm/dma-mapping.h|8 +++ arch/arm/mm/dma-mapping.c | 49 ++-- arch/arm/mm/init.c| 12 +++--- arch/arm/mm/mm.h |2 + arch/powerpc/kernel/vio.c |3 +- block/blk-settings.c |8 ++-- drivers/amba/bus.c|6 +-- drivers/ata/pata_ixp4xx_cf.c |5 ++- drivers/ata/pata_octeon_cf.c |5 +- drivers/block/nvme-core.c | 10 ++--- drivers/crypto/ixp4xx_crypto.c| 48 ++-- drivers/dma/amba-pl08x.c |5 ++ drivers/dma/dw/platform.c |8 +-- drivers/dma/edma.c|6 +-- drivers/dma/pl330.c |4 ++ drivers/firmware/dcdbas.c | 23 +- drivers/firmware/google/gsmi.c| 13 +++-- drivers/gpu/drm/exynos/exynos_drm_drv.c |6 ++- drivers/gpu/drm/omapdrm/omap_dmm_tiler.c |5 +- drivers/media/platform/omap3isp/isp.c |6 +- drivers/media/platform/omap3isp/isp.h |3 - drivers/mmc/card/queue.c |3 +- drivers/mmc/host/sdhci-acpi.c |5 +- drivers/net/ethernet/broadcom/b44.c |3 +- drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c |8 +--- drivers/net/ethernet/brocade/bna/bnad.c | 13 ++ drivers/net/ethernet/emulex/benet/be_main.c | 12 + drivers/net/ethernet/intel/e1000/e1000_main.c |9 +--- drivers/net/ethernet/intel/e1000e/netdev.c| 18 +++- drivers/net/ethernet/intel/igb/igb_main.c | 18 +++- drivers/net/ethernet/intel/igbvf/netdev.c | 18 +++- drivers/net/ethernet/intel/ixgb/ixgb_main.c | 16 ++- drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
Re: [RFC 10/21] xhci: replace xhci_readl() with readl() in xhci-dbg.c
On Fri, Sep 13, 2013 at 03:50:48PM +0530, Pratyush Anand wrote: On Fri, Sep 13, 2013 at 3:40 PM, Xenia Ragiadakou burzalod...@gmail.comwrote: Nope :). There is still Kumar 's patch that keeps the wrappers, so it can be applied instead of mine. But you did not tell me which tool you use currently to log the mmio operations? it is useful to know. Sorry, I did not use any standard tool, rather I made local changes in dwc3_readl and dwc3_writel to log all dwc3 specific read/write operations into a static array, which was dumped to a text file using an ARM debugger (trace32) for further analysis. Would it be helpful to add a trace event for xHCI register reads and writes (but not a debug statement)? That way you wouldn't have to change or recompile the kernel at all, but you could use the trace events infrastructure to enable xHCI register read/write debugging. We wouldn't flood log files with register reads and writes, but a trace event makes sense. AFAIK, trace events work on both x86 and ARM. Sarah Sharp -- 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 02/51] DMA-API: net: brocade/bna/bnad.c: fix 32-bit DMA mask handling
The fallback to 32-bit DMA mask is rather odd:
if (!dma_set_mask(pdev-dev, DMA_BIT_MASK(64))
!dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(64))) {
*using_dac = true;
} else {
err = dma_set_mask(pdev-dev, DMA_BIT_MASK(32));
if (err) {
err = dma_set_coherent_mask(pdev-dev,
DMA_BIT_MASK(32));
if (err)
goto release_regions;
}
This means we only try and set the coherent DMA mask if we failed to
set a 32-bit DMA mask, and only if both fail do we fail the driver.
Adjust this so that if either setting fails, we fail the driver - and
thereby end up properly setting both the DMA mask and the coherent
DMA mask in the fallback case.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/net/ethernet/brocade/bna/bnad.c | 13 -
1 files changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/brocade/bna/bnad.c
b/drivers/net/ethernet/brocade/bna/bnad.c
index b78e69e..45ce6e2 100644
--- a/drivers/net/ethernet/brocade/bna/bnad.c
+++ b/drivers/net/ethernet/brocade/bna/bnad.c
@@ -3300,17 +3300,12 @@ bnad_pci_init(struct bnad *bnad,
err = pci_request_regions(pdev, BNAD_NAME);
if (err)
goto disable_device;
- if (!dma_set_mask(pdev-dev, DMA_BIT_MASK(64))
- !dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(64))) {
+ if (!dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(64))) {
*using_dac = true;
} else {
- err = dma_set_mask(pdev-dev, DMA_BIT_MASK(32));
- if (err) {
- err = dma_set_coherent_mask(pdev-dev,
- DMA_BIT_MASK(32));
- if (err)
- goto release_regions;
- }
+ err = dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(32));
+ if (err)
+ goto release_regions;
*using_dac = false;
}
pci_set_master(pdev);
--
1.7.4.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 03/51] DMA-API: net: intel/e1000e: fix 32-bit DMA mask handling
The fallback to 32-bit DMA mask is rather odd:
err = dma_set_mask(pdev-dev, DMA_BIT_MASK(64));
if (!err) {
err = dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(64));
if (!err)
pci_using_dac = 1;
} else {
err = dma_set_mask(pdev-dev, DMA_BIT_MASK(32));
if (err) {
err = dma_set_coherent_mask(pdev-dev,
DMA_BIT_MASK(32));
if (err) {
dev_err(pdev-dev,
No usable DMA configuration,
aborting\n);
goto err_dma;
}
}
}
This means we only set the coherent DMA mask in the fallback path if
the DMA mask set failed, which is silly. This fixes it to set the
coherent DMA mask only if dma_set_mask() succeeded, and to error out
if either fails.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/net/ethernet/intel/e1000e/netdev.c | 18 ++
1 files changed, 6 insertions(+), 12 deletions(-)
diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c
b/drivers/net/ethernet/intel/e1000e/netdev.c
index e87e9b0..519e293 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -6553,21 +6553,15 @@ static int e1000_probe(struct pci_dev *pdev, const
struct pci_device_id *ent)
return err;
pci_using_dac = 0;
- err = dma_set_mask(pdev-dev, DMA_BIT_MASK(64));
+ err = dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(64));
if (!err) {
- err = dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(64));
- if (!err)
- pci_using_dac = 1;
+ pci_using_dac = 1;
} else {
- err = dma_set_mask(pdev-dev, DMA_BIT_MASK(32));
+ err = dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(32));
if (err) {
- err = dma_set_coherent_mask(pdev-dev,
- DMA_BIT_MASK(32));
- if (err) {
- dev_err(pdev-dev,
- No usable DMA configuration,
aborting\n);
- goto err_dma;
- }
+ dev_err(pdev-dev,
+ No usable DMA configuration, aborting\n);
+ goto err_dma;
}
}
--
1.7.4.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 04/51] DMA-API: net: intel/igb: fix 32-bit DMA mask handling
The fallback to 32-bit DMA mask is rather odd:
err = dma_set_mask(pdev-dev, DMA_BIT_MASK(64));
if (!err) {
err = dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(64));
if (!err)
pci_using_dac = 1;
} else {
err = dma_set_mask(pdev-dev, DMA_BIT_MASK(32));
if (err) {
err = dma_set_coherent_mask(pdev-dev,
DMA_BIT_MASK(32));
if (err) {
dev_err(pdev-dev,
No usable DMA configuration,
aborting\n);
goto err_dma;
}
}
}
This means we only set the coherent DMA mask in the fallback path if
the DMA mask set failed, which is silly. This fixes it to set the
coherent DMA mask only if dma_set_mask() succeeded, and to error out
if either fails.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/net/ethernet/intel/igb/igb_main.c | 18 ++
1 files changed, 6 insertions(+), 12 deletions(-)
diff --git a/drivers/net/ethernet/intel/igb/igb_main.c
b/drivers/net/ethernet/intel/igb/igb_main.c
index 8cf44f2..7579383 100644
--- a/drivers/net/ethernet/intel/igb/igb_main.c
+++ b/drivers/net/ethernet/intel/igb/igb_main.c
@@ -2034,21 +2034,15 @@ static int igb_probe(struct pci_dev *pdev, const struct
pci_device_id *ent)
return err;
pci_using_dac = 0;
- err = dma_set_mask(pdev-dev, DMA_BIT_MASK(64));
+ err = dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(64));
if (!err) {
- err = dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(64));
- if (!err)
- pci_using_dac = 1;
+ pci_using_dac = 1;
} else {
- err = dma_set_mask(pdev-dev, DMA_BIT_MASK(32));
+ err = dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(32));
if (err) {
- err = dma_set_coherent_mask(pdev-dev,
- DMA_BIT_MASK(32));
- if (err) {
- dev_err(pdev-dev,
- No usable DMA configuration,
aborting\n);
- goto err_dma;
- }
+ dev_err(pdev-dev,
+ No usable DMA configuration, aborting\n);
+ goto err_dma;
}
}
--
1.7.4.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 01/51] DMA-API: provide a helper to set both DMA and coherent DMA masks
Provide a helper to set both the DMA and coherent DMA masks to the
same value - this avoids duplicated code in a number of drivers,
sometimes with buggy error handling, and also allows us identify
which drivers do things differently.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
Documentation/DMA-API-HOWTO.txt | 37 ++---
Documentation/DMA-API.txt |8
include/linux/dma-mapping.h | 14 ++
3 files changed, 44 insertions(+), 15 deletions(-)
diff --git a/Documentation/DMA-API-HOWTO.txt b/Documentation/DMA-API-HOWTO.txt
index 14129f1..5e98303 100644
--- a/Documentation/DMA-API-HOWTO.txt
+++ b/Documentation/DMA-API-HOWTO.txt
@@ -101,14 +101,23 @@ style to do this even if your device holds the default
setting,
because this shows that you did think about these issues wrt. your
device.
-The query is performed via a call to dma_set_mask():
+The query is performed via a call to dma_set_mask_and_coherent():
- int dma_set_mask(struct device *dev, u64 mask);
+ int dma_set_mask_and_coherent(struct device *dev, u64 mask);
-The query for consistent allocations is performed via a call to
-dma_set_coherent_mask():
+which will query the mask for both streaming and coherent APIs together.
+If you have some special requirements, then the following two separate
+queries can be used instead:
- int dma_set_coherent_mask(struct device *dev, u64 mask);
+ The query for streaming mappings is performed via a call to
+ dma_set_mask():
+
+ int dma_set_mask(struct device *dev, u64 mask);
+
+ The query for consistent allocations is performed via a call
+ to dma_set_coherent_mask():
+
+ int dma_set_coherent_mask(struct device *dev, u64 mask);
Here, dev is a pointer to the device struct of your device, and mask
is a bit mask describing which bits of an address your device
@@ -137,7 +146,7 @@ exactly why.
The standard 32-bit addressing device would do something like this:
- if (dma_set_mask(dev, DMA_BIT_MASK(32))) {
+ if (dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32))) {
printk(KERN_WARNING
mydev: No suitable DMA available.\n);
goto ignore_this_device;
@@ -171,22 +180,20 @@ If a card is capable of using 64-bit consistent
allocations as well,
int using_dac, consistent_using_dac;
- if (!dma_set_mask(dev, DMA_BIT_MASK(64))) {
+ if (!dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64))) {
using_dac = 1;
consistent_using_dac = 1;
- dma_set_coherent_mask(dev, DMA_BIT_MASK(64));
- } else if (!dma_set_mask(dev, DMA_BIT_MASK(32))) {
+ } else if (!dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32))) {
using_dac = 0;
consistent_using_dac = 0;
- dma_set_coherent_mask(dev, DMA_BIT_MASK(32));
} else {
printk(KERN_WARNING
mydev: No suitable DMA available.\n);
goto ignore_this_device;
}
-dma_set_coherent_mask() will always be able to set the same or a
-smaller mask as dma_set_mask(). However for the rare case that a
+The coherent coherent mask will always be able to set the same or a
+smaller mask as the streaming mask. However for the rare case that a
device driver only uses consistent allocations, one would have to
check the return value from dma_set_coherent_mask().
@@ -199,9 +206,9 @@ Finally, if your device can only drive the low 24-bits of
goto ignore_this_device;
}
-When dma_set_mask() is successful, and returns zero, the kernel saves
-away this mask you have provided. The kernel will use this
-information later when you make DMA mappings.
+When dma_set_mask() or dma_set_mask_and_coherent() is successful, and
+returns zero, the kernel saves away this mask you have provided. The
+kernel will use this information later when you make DMA mappings.
There is a case which we are aware of at this time, which is worth
mentioning in this documentation. If your device supports multiple
diff --git a/Documentation/DMA-API.txt b/Documentation/DMA-API.txt
index 78a6c56..e865279 100644
--- a/Documentation/DMA-API.txt
+++ b/Documentation/DMA-API.txt
@@ -142,6 +142,14 @@ internal API for use by the platform than an external API
for use by
driver writers.
int
+dma_set_mask_and_coherent(struct device *dev, u64 mask)
+
+Checks to see if the mask is possible and updates the device
+streaming and coherent DMA mask parameters if it is.
+
+Returns: 0 if successful and a negative error if not.
+
+int
dma_set_mask(struct device *dev, u64 mask)
Checks to see if the mask is possible and updates the device
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 3a8d0a2..ec951f9 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -97,6 +97,20 @@ static
[PATCH 05/51] DMA-API: net: intel/igbvf: fix 32-bit DMA mask handling
The fallback to 32-bit DMA mask is rather odd:
err = dma_set_mask(pdev-dev, DMA_BIT_MASK(64));
if (!err) {
err = dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(64));
if (!err)
pci_using_dac = 1;
} else {
err = dma_set_mask(pdev-dev, DMA_BIT_MASK(32));
if (err) {
err = dma_set_coherent_mask(pdev-dev,
DMA_BIT_MASK(32));
if (err) {
dev_err(pdev-dev, No usable DMA
configuration, aborting\n);
goto err_dma;
}
}
}
This means we only set the coherent DMA mask in the fallback path if
the DMA mask set failed, which is silly. This fixes it to set the
coherent DMA mask only if dma_set_mask() succeeded, and to error out
if either fails.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/net/ethernet/intel/igbvf/netdev.c | 18 ++
1 files changed, 6 insertions(+), 12 deletions(-)
diff --git a/drivers/net/ethernet/intel/igbvf/netdev.c
b/drivers/net/ethernet/intel/igbvf/netdev.c
index 93eb7ee..4e6b02f 100644
--- a/drivers/net/ethernet/intel/igbvf/netdev.c
+++ b/drivers/net/ethernet/intel/igbvf/netdev.c
@@ -2638,21 +2638,15 @@ static int igbvf_probe(struct pci_dev *pdev, const
struct pci_device_id *ent)
return err;
pci_using_dac = 0;
- err = dma_set_mask(pdev-dev, DMA_BIT_MASK(64));
+ err = dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(64));
if (!err) {
- err = dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(64));
- if (!err)
- pci_using_dac = 1;
+ pci_using_dac = 1;
} else {
- err = dma_set_mask(pdev-dev, DMA_BIT_MASK(32));
+ err = dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(32));
if (err) {
- err = dma_set_coherent_mask(pdev-dev,
- DMA_BIT_MASK(32));
- if (err) {
- dev_err(pdev-dev, No usable DMA
- configuration, aborting\n);
- goto err_dma;
- }
+ dev_err(pdev-dev, No usable DMA
+ configuration, aborting\n);
+ goto err_dma;
}
}
--
1.7.4.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 06/51] DMA-API: net: intel/ixgb: fix 32-bit DMA mask handling
The fallback to 32-bit DMA mask is rather odd:
err = dma_set_mask(pdev-dev, DMA_BIT_MASK(64));
if (!err) {
err = dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(64));
if (!err)
pci_using_dac = 1;
} else {
err = dma_set_mask(pdev-dev, DMA_BIT_MASK(32));
if (err) {
err = dma_set_coherent_mask(pdev-dev,
DMA_BIT_MASK(32));
if (err) {
pr_err(No usable DMA configuration,
aborting\n);
goto err_dma_mask;
}
}
}
This means we only set the coherent DMA mask in the fallback path if
the DMA mask set failed, which is silly. This fixes it to set the
coherent DMA mask only if dma_set_mask() succeeded, and to error out
if either fails.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/net/ethernet/intel/ixgb/ixgb_main.c | 16 +---
1 files changed, 5 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgb/ixgb_main.c
b/drivers/net/ethernet/intel/ixgb/ixgb_main.c
index 9f6b236..57e390c 100644
--- a/drivers/net/ethernet/intel/ixgb/ixgb_main.c
+++ b/drivers/net/ethernet/intel/ixgb/ixgb_main.c
@@ -408,20 +408,14 @@ ixgb_probe(struct pci_dev *pdev, const struct
pci_device_id *ent)
return err;
pci_using_dac = 0;
- err = dma_set_mask(pdev-dev, DMA_BIT_MASK(64));
+ err = dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(64));
if (!err) {
- err = dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(64));
- if (!err)
- pci_using_dac = 1;
+ pci_using_dac = 1;
} else {
- err = dma_set_mask(pdev-dev, DMA_BIT_MASK(32));
+ err = dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(32));
if (err) {
- err = dma_set_coherent_mask(pdev-dev,
- DMA_BIT_MASK(32));
- if (err) {
- pr_err(No usable DMA configuration,
aborting\n);
- goto err_dma_mask;
- }
+ pr_err(No usable DMA configuration, aborting\n);
+ goto err_dma_mask;
}
}
--
1.7.4.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 07/51] DMA-API: net: intel/ixgbe: fix 32-bit DMA mask handling
The fallback to 32-bit DMA mask is rather odd:
if (!dma_set_mask(pdev-dev, DMA_BIT_MASK(64))
!dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(64))) {
pci_using_dac = 1;
} else {
err = dma_set_mask(pdev-dev, DMA_BIT_MASK(32));
if (err) {
err = dma_set_coherent_mask(pdev-dev,
DMA_BIT_MASK(32));
if (err) {
dev_err(pdev-dev,
No usable DMA configuration,
aborting\n);
goto err_dma;
}
}
pci_using_dac = 0;
}
This means we only set the coherent DMA mask in the fallback path if
the DMA mask set failed, which is silly. This fixes it to set the
coherent DMA mask only if dma_set_mask() succeeded, and to error out
if either fails.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 15 +--
1 files changed, 5 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index 7aba452..b1dc844 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -7475,19 +7475,14 @@ static int ixgbe_probe(struct pci_dev *pdev, const
struct pci_device_id *ent)
if (err)
return err;
- if (!dma_set_mask(pdev-dev, DMA_BIT_MASK(64))
- !dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(64))) {
+ if (!dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(64))) {
pci_using_dac = 1;
} else {
- err = dma_set_mask(pdev-dev, DMA_BIT_MASK(32));
+ err = dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(32));
if (err) {
- err = dma_set_coherent_mask(pdev-dev,
- DMA_BIT_MASK(32));
- if (err) {
- dev_err(pdev-dev,
- No usable DMA configuration,
aborting\n);
- goto err_dma;
- }
+ dev_err(pdev-dev,
+ No usable DMA configuration, aborting\n);
+ goto err_dma;
}
pci_using_dac = 0;
}
--
1.7.4.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 08/51] DMA-API: net: intel/ixgbevf: fix 32-bit DMA mask handling
The fallback to 32-bit DMA mask is rather odd:
if (!dma_set_mask(pdev-dev, DMA_BIT_MASK(64))
!dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(64))) {
pci_using_dac = 1;
} else {
err = dma_set_mask(pdev-dev, DMA_BIT_MASK(32));
if (err) {
err = dma_set_coherent_mask(pdev-dev,
DMA_BIT_MASK(32));
if (err) {
dev_err(pdev-dev, No usable DMA
configuration, aborting\n);
goto err_dma;
}
}
pci_using_dac = 0;
}
This means we only set the coherent DMA mask in the fallback path if
the DMA mask set failed, which is silly. This fixes it to set the
coherent DMA mask only if dma_set_mask() succeeded, and to error out
if either fails.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 15 +--
1 files changed, 5 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
index 59a62bb..e34c2da 100644
--- a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
+++ b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
@@ -3326,19 +3326,14 @@ static int ixgbevf_probe(struct pci_dev *pdev, const
struct pci_device_id *ent)
if (err)
return err;
- if (!dma_set_mask(pdev-dev, DMA_BIT_MASK(64))
- !dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(64))) {
+ if (!dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(64))) {
pci_using_dac = 1;
} else {
- err = dma_set_mask(pdev-dev, DMA_BIT_MASK(32));
+ err = dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(32));
if (err) {
- err = dma_set_coherent_mask(pdev-dev,
- DMA_BIT_MASK(32));
- if (err) {
- dev_err(pdev-dev, No usable DMA
- configuration, aborting\n);
- goto err_dma;
- }
+ dev_err(pdev-dev, No usable DMA
+ configuration, aborting\n);
+ goto err_dma;
}
pci_using_dac = 0;
}
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Patch Memory Mapping for USBFS
On Fri, Sep 20, 2013 at 1:57 AM, Markus Rechberger
mrechber...@gmail.com wrote:
This patch adds memory mapping support to USBFS for isochronous and bulk data
transfers, it allows to pre-allocate usb transfer buffers.
I guess some things can be made a little bit nicer here so any feedback is
welcome.
The CPU usage decreases 1-2% on my 1.3ghz U7300 notebook when transferring
20mbyte/sec, it should be more interesting to see those statistics on
embedded systems where copying data is more expensive.
Usage from userspace:
allocation:
rv = ioctl(priv-usbfd, USBDEVFS_ALLOC_MEMORY, mem);
if (rv == 0)
buffer = mmap(NULL, size, PROT_READ|PROT_WRITE, MAP_SHARED,
priv-usbfd, mem.offset);
use the mapped buffer with urb-buffer.
release:
rv = munmap(buffer, size);
memset(mem, 0x0, sizeof(struct usbdevfs_memory));
mem.buffer = buffer;
rv = ioctl(priv-usbfd, USBDEVFS_FREE_MEMORY, mem);
non freed memory buffers are collected and will be released when closing the
node.
I tested this patch with Bulk and Isochronous, with and without memory
mapping (applications which don't use mmap will just fall back to the legacy
mechanism).
http://sundtek.de/support/devio_mmap_v0.1.diff
diff --git a/drivers/usb/core/devio.c b/drivers/usb/core/devio.c
index 737e3c1..d588e2e 100644
--- a/drivers/usb/core/devio.c
+++ b/drivers/usb/core/devio.c
@@ -30,6 +30,7 @@
*04.01.2000 0.2 Turned into its own filesystem
*30.09.2005 0.3 Fix user-triggerable oops in async URB delivery
* (CAN-2005-3055)
+ *19.09.2013 Added memory mapping support for data packets
*/
/*/
@@ -69,6 +70,7 @@ struct dev_state {
spinlock_t lock;/* protects the async urb lists */
struct list_head async_pending;
struct list_head async_completed;
+ struct list_head memory_list;
wait_queue_head_t wait; /* wake up if a request completed */
unsigned int discsignr;
struct pid *disc_pid;
@@ -96,6 +98,16 @@ struct async {
u8 bulk_status;
};
+struct usb_memory {
+ struct list_head memlist;
+ int vma_use_count;
+ int usb_use_count;
+ u32 offset;
+ u32 size;
+ void *mem;
+ unsigned long vm_start;
+};
+
static bool usbfs_snoop;
module_param(usbfs_snoop, bool, S_IRUGO | S_IWUSR);
MODULE_PARM_DESC(usbfs_snoop, true to log all usbfs traffic);
@@ -288,6 +300,9 @@ static struct async *alloc_async(unsigned int
numisoframes)
static void free_async(struct async *as)
{
+ struct usb_memory *usbm = NULL, *usbm_iter;
+ unsigned long flags;
+ struct dev_state *ps = as-ps;
int i;
put_pid(as-pid);
@@ -297,8 +312,22 @@ static void free_async(struct async *as)
if (sg_page(as-urb-sg[i]))
kfree(sg_virt(as-urb-sg[i]));
}
+
+ spin_lock_irqsave(ps-lock, flags);
+ list_for_each_entry(usbm_iter, ps-memory_list, memlist) {
+ if (usbm_iter-mem == as-urb-transfer_buffer) {
+ usbm = usbm_iter;
+ break;
+ }
+ }
+ spin_unlock_irqrestore(ps-lock, flags);
+
kfree(as-urb-sg);
- kfree(as-urb-transfer_buffer);
+ if (usbm == NULL)
+ kfree(as-urb-transfer_buffer);
+ else
+ usbm-usb_use_count--;
+
kfree(as-urb-setup_packet);
usb_free_urb(as-urb);
usbfs_decrease_memory_usage(as-mem_usage);
@@ -811,6 +840,7 @@ static int usbdev_open(struct inode *inode, struct file
*file)
INIT_LIST_HEAD(ps-list);
INIT_LIST_HEAD(ps-async_pending);
INIT_LIST_HEAD(ps-async_completed);
+ INIT_LIST_HEAD(ps-memory_list);
init_waitqueue_head(ps-wait);
ps-discsignr = 0;
ps-disc_pid = get_pid(task_pid(current));
@@ -839,6 +869,8 @@ static int usbdev_release(struct inode *inode, struct
file *file)
struct dev_state *ps = file-private_data;
struct usb_device *dev = ps-dev;
unsigned int ifnum;
+ struct list_head *p, *q;
+ struct usb_memory *tmp;
struct async *as;
usb_lock_device(dev);
@@ -863,6 +895,14 @@ static int usbdev_release(struct inode *inode, struct
file *file)
free_async(as);
as = async_getcompleted(ps);
}
+
+ list_for_each_safe(p, q, ps-memory_list) {
+ tmp = list_entry(p, struct usb_memory, memlist);
+ list_del(p);
+ if (tmp-mem)
+ free_pages_exact(tmp-mem, tmp-size);
+ kfree(tmp);
+ }
kfree(ps);
return 0;
}
@@ -1173,6 +1213,7 @@ static int proc_do_submiturb(struct dev_state *ps,
struct usbdevfs_urb *uurb,
struct usb_host_endpoint *ep;
struct async *as = NULL;
struct usb_ctrlrequest *dr = NULL;
+ struct usb_memory *usbm = NULL, *iter = NULL;
unsigned int u, totlen, isofrmlen;
int i, ret, is_in, num_sgs = 0, ifnum = -1;
void *buf;
@@ -1323,6 +1364,8 @@ static int proc_do_submiturb(struct dev_state *ps,
struct usbdevfs_urb *uurb,
goto error;
}
+ as-ps = ps;
+
u += sizeof(struct async) + sizeof(struct urb) + uurb-buffer_length +
num_sgs * sizeof(struct
Re: [PATCH 01/51] DMA-API: provide a helper to set both DMA and coherent DMA masks
On Thu, 2013-09-19 at 22:25 +0100, Russell King wrote: Provide a helper to set both the DMA and coherent DMA masks to the same value - this avoids duplicated code in a number of drivers, sometimes with buggy error handling, and also allows us identify which drivers do things differently. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk --- Documentation/DMA-API-HOWTO.txt | 37 ++--- Documentation/DMA-API.txt |8 include/linux/dma-mapping.h | 14 ++ 3 files changed, 44 insertions(+), 15 deletions(-) diff --git a/Documentation/DMA-API-HOWTO.txt b/Documentation/DMA-API-HOWTO.txt index 14129f1..5e98303 100644 --- a/Documentation/DMA-API-HOWTO.txt +++ b/Documentation/DMA-API-HOWTO.txt [...] -dma_set_coherent_mask() will always be able to set the same or a -smaller mask as dma_set_mask(). However for the rare case that a +The coherent coherent mask will always be able to set the same or a +smaller mask as the streaming mask. However for the rare case that a [...] The new wording doesn't make sense; a mask doesn't set itself. I would suggest: The coherent mask can always be set to the same or a smaller mask than the streaming mask. Ben. -- Ben Hutchings, Staff Engineer, Solarflare Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Patch Memory Mapping for USBFS
On Fri, 20 Sep 2013, Markus Rechberger wrote: to comment it by myself, memory should be cleared for not exposing uncleared memory to userspace and usbmem should be checked if(!mem), if(!usbmem). It will be in the next version. The next time you post a version of this patch, please make sure that your email client does not destroy the whitespace characters. 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]fsl/usb: Workarourd for USB erratum-A005697
-Original Message-
From: Alan Stern [mailto:st...@rowland.harvard.edu]
Sent: Thursday, September 19, 2013 7:03 PM
To: Mehresh Ramneek-B31383
Cc: linux-usb@vger.kernel.org
Subject: Re: [PATCH]fsl/usb: Workarourd for USB erratum-A005697
On Thu, 19 Sep 2013, Ramneek Mehresh wrote:
As per USB specification, in Suspend state the status bit does not
change until the port is suspended. However, there may be a delay in
suspending a port if there is a transaction currently in progress on
the bus.
In the USBDR controller, the PORTSCx[SUSP] bit changes immediately
when the application sets it and not when the port is actually
suspended
Workaround for this issue involves waiting for a minimum of 10ms to
allow the controller to go into SUSPEND state before proceeding ahead
Why is this workaround needed? Does anything go wrong if it isn't applied?
[Ramneek]: This workaround is needed because we have this issue with the
controller.
In some protocols like HNP, a notification needs to be sent to another OTG
device
as soon as current controller port goes into SUSPEND state. However, this
notification could be false if the port is still transmitting some data and the
controller informs system s/w that the port is already in suspend state.
--- a/drivers/usb/host/ehci-hub.c
+++ b/drivers/usb/host/ehci-hub.c
@@ -284,6 +284,8 @@ static int ehci_bus_suspend (struct usb_hcd *hcd)
else if ((t1 PORT_PE) !(t1 PORT_SUSPEND)) {
t2 |= PORT_SUSPEND;
set_bit(port, ehci-bus_suspended);
+ if (ehci_has_fsl_susp_errata(ehci))
+ usleep_range(1, 2);
}
Notice that there's no delay here for other controller types. Why does USBDR
need a delay?
[Ramneek] USBDR has this issue where it sets SUSPEND status bit even before it
is in SUSPEND state.
It has been guaranteed that the port will definitely go into SUSPEND state in
10ms.
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 v11 0/8] PHY framework
Hi Greg, On Tuesday 17 September 2013 09:11 PM, Felipe Balbi wrote: On Wed, Sep 04, 2013 at 02:27:06PM +0530, Kishon Vijay Abraham I wrote: On Tuesday 03 September 2013 09:20 PM, Greg KH wrote: On Tue, Sep 03, 2013 at 08:55:23PM +0530, Kishon Vijay Abraham I wrote: Hi Greg, On Wednesday 28 August 2013 12:50 AM, Felipe Balbi wrote: Hi, On Mon, Aug 26, 2013 at 01:44:49PM +0530, Kishon Vijay Abraham I wrote: On Wednesday 21 August 2013 11:16 AM, Kishon Vijay Abraham I wrote: Added a generic PHY framework that provides a set of APIs for the PHY drivers to create/destroy a PHY and APIs for the PHY users to obtain a reference to the PHY with or without using phandle. This framework will be of use only to devices that uses external PHY (PHY functionality is not embedded within the controller). The intention of creating this framework is to bring the phy drivers spread all over the Linux kernel to drivers/phy to increase code re-use and to increase code maintainability. Comments to make PHY as bus wasn't done because PHY devices can be part of other bus and making a same device attached to multiple bus leads to bad design. If the PHY driver has to send notification on connect/disconnect, the PHY driver should make use of the extcon framework. Using this susbsystem to use extcon framwork will have to be analysed. You can find this patch series @ git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git testing Looks like there are not further comments on this series. Can you take this in your misc tree? Do you want me to queue these for you ? There are quite a few users for this framework already and I know of at least 2 others which will show up for v3.13. Can you queue this patch series? There are quite a few users already for this framework. It will have to wait for 3.13 as the merge window for new features has been closed for a week or so. Sorry, I'll queue this up after 3.12-rc1 is out. Alright, thanks. Just a gentle ping on this one... Let me know if you want me to rebase this patch series on the latest mainline HEAD. Thanks Kishon -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 10/21] xhci: replace xhci_readl() with readl() in xhci-dbg.c
On Fri, Sep 20, 2013 at 05:37:50AM +0800, Sarah Sharp wrote: On Fri, Sep 13, 2013 at 03:50:48PM +0530, Pratyush Anand wrote: On Fri, Sep 13, 2013 at 3:40 PM, Xenia Ragiadakou burzalod...@gmail.comwrote: Nope :). There is still Kumar 's patch that keeps the wrappers, so it can be applied instead of mine. But you did not tell me which tool you use currently to log the mmio operations? it is useful to know. Sorry, I did not use any standard tool, rather I made local changes in dwc3_readl and dwc3_writel to log all dwc3 specific read/write operations into a static array, which was dumped to a text file using an ARM debugger (trace32) for further analysis. Would it be helpful to add a trace event for xHCI register reads and writes (but not a debug statement)? That way you wouldn't have to change or recompile the kernel at all, but you could use the trace events infrastructure to enable xHCI register read/write debugging. We wouldn't flood log files with register reads and writes, but a trace event makes sense. I have not used tracepoints. So to understand, looked into Documentation/trace/tracepoints.txt: When a tracepoint is on, the function you provide is called each time the tracepoint is executed. So, do you mean to insert tracepoint in xhci_readl/writel? For sure it would be helpful, but... Trace ON will be needed only in very special (and a few) case, so would it be fine to insert a tiny time penalty in readl/writel routine when trace is off? Not Sure... Document says When a tracepoint is off it has no effect, except for adding a tiny time penalty (checking a condition for a branch) For me, you can take these patches. I can go with the way Paul suggested in special cases. Regards Pratyush AFAIK, trace events work on both x86 and ARM. Sarah Sharp -- 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
