Re: [PATCH] usb: gadget: uvc: Missing files for configfs interface
Hi Petr,
Thank you for the patch.
On Tuesday 07 Mar 2017 00:57:20 Petr Cvek wrote:
> Commit 76e0da34c7ce ("usb-gadget/uvc: use per-attribute show and store
> methods") caused a stringification of an undefined macro argument "aname",
> so three UVC parameters (streaming_interval, streaming_maxpacket and
> streaming_maxburst) were named "aname".
>
> Add the definition of "aname" to the main macro and name the filenames as
> originaly intended.
Why don't you just
- UVC_ATTR(f_uvc_opts_, cname, aname)
+ UVC_ATTR(f_uvc_opts_, cname, cname)
in the definition of the UVCG_OPTS_ATTR() macro ?
> Signed-off-by: Petr Cvek
> ---
> drivers/usb/gadget/function/uvc_configfs.c | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/usb/gadget/function/uvc_configfs.c
> b/drivers/usb/gadget/function/uvc_configfs.c index
> 4e037d2a7a60..3a36b2e85788 100644
> --- a/drivers/usb/gadget/function/uvc_configfs.c
> +++ b/drivers/usb/gadget/function/uvc_configfs.c
> @@ -2125,7 +2125,7 @@ static struct configfs_item_operations uvc_item_ops =
> { .release= uvc_attr_release,
> };
>
> -#define UVCG_OPTS_ATTR(cname, conv, str2u, uxx, vnoc, limit) \
> +#define UVCG_OPTS_ATTR(cname, aname, conv, str2u, uxx, vnoc, limit) \
> static ssize_t f_uvc_opts_##cname##_show(\
> struct config_item *item, char *page) \
> {\
> @@ -2172,12 +2172,12 @@ UVC_ATTR(f_uvc_opts_, cname, aname)
>
> #define identity_conv(x) (x)
>
> -UVCG_OPTS_ATTR(streaming_interval, identity_conv, kstrtou8, u8,
> identity_conv, - 16);
> -UVCG_OPTS_ATTR(streaming_maxpacket, le16_to_cpu, kstrtou16, u16,
> le16_to_cpu, - 3072);
> -UVCG_OPTS_ATTR(streaming_maxburst, identity_conv, kstrtou8, u8,
> identity_conv, - 15);
> +UVCG_OPTS_ATTR(streaming_interval, streaming_interval, identity_conv,
> +kstrtou8, u8, identity_conv, 16);
> +UVCG_OPTS_ATTR(streaming_maxpacket, streaming_maxpacket, le16_to_cpu,
> +kstrtou16, u16, le16_to_cpu, 3072);
> +UVCG_OPTS_ATTR(streaming_maxburst, streaming_maxburst, identity_conv,
> +kstrtou8, u8, identity_conv, 15);
>
> #undef identity_conv
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] usb: xhci-mtk: fix checkpatch warning and erorr
there are two warnings and a erorr when checked by checkpatch.pl
as following:
WARNING:BLOCK_COMMENT_STYLE: Block comments should align
the * on each line
ERROR:COMPLEX_MACRO: Macros with complex values should be
enclosed in parentheses
Signed-off-by: Chunfeng Yun
---
drivers/usb/host/xhci-mtk.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c
index 9636884..22c94fe 100644
--- a/drivers/usb/host/xhci-mtk.c
+++ b/drivers/usb/host/xhci-mtk.c
@@ -287,9 +287,9 @@ static void usb_wakeup_ip_sleep_dis(struct xhci_hcd_mtk
*mtk)
}
/*
-* for line-state wakeup mode, phy's power should not power-down
-* and only support cable plug in/out
-*/
+ * for line-state wakeup mode, phy's power should not power-down
+ * and only support cable plug in/out
+ */
static void usb_wakeup_line_state_en(struct xhci_hcd_mtk *mtk)
{
u32 tmp;
@@ -350,10 +350,10 @@ static int usb_wakeup_of_property_parse(struct
xhci_hcd_mtk *mtk,
struct device *dev = mtk->dev;
/*
- * wakeup function is optional, so it is not an error if this property
- * does not exist, and in such case, no need to get relative
- * properties anymore.
- */
+* wakeup function is optional, so it is not an error if this property
+* does not exist, and in such case, no need to get relative
+* properties anymore.
+*/
of_property_read_u32(dn, "mediatek,wakeup-src", &mtk->wakeup_src);
if (!mtk->wakeup_src)
return 0;
@@ -796,7 +796,7 @@ static int __maybe_unused xhci_mtk_resume(struct device
*dev)
static const struct dev_pm_ops xhci_mtk_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(xhci_mtk_suspend, xhci_mtk_resume)
};
-#define DEV_PM_OPS IS_ENABLED(CONFIG_PM) ? &xhci_mtk_pm_ops : NULL
+#define DEV_PM_OPS (IS_ENABLED(CONFIG_PM) ? &xhci_mtk_pm_ops : NULL)
#ifdef CONFIG_OF
static const struct of_device_id mtk_xhci_of_match[] = {
--
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 1/2] usb: xhci-mtk: rebuild xhci_mtk_setup()
simplify xhci_mtk_setup() and add xhci_mtk_start() for
xhci_driver_overrides struct
Signed-off-by: Chunfeng Yun
---
drivers/usb/host/xhci-mtk.c | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c
index 67d5dc7..9636884 100644
--- a/drivers/usb/host/xhci-mtk.c
+++ b/drivers/usb/host/xhci-mtk.c
@@ -381,8 +381,10 @@ static int usb_wakeup_of_property_parse(struct
xhci_hcd_mtk *mtk,
}
static int xhci_mtk_setup(struct usb_hcd *hcd);
+static int xhci_mtk_start(struct usb_hcd *hcd);
static const struct xhci_driver_overrides xhci_mtk_overrides __initconst = {
.reset = xhci_mtk_setup,
+ .start = xhci_mtk_start,
};
static struct hc_driver __read_mostly xhci_mtk_hc_driver;
@@ -492,7 +494,6 @@ static void xhci_mtk_quirks(struct device *dev, struct
xhci_hcd *xhci)
/* called during probe() after chip reset completes */
static int xhci_mtk_setup(struct usb_hcd *hcd)
{
- struct xhci_hcd *xhci = hcd_to_xhci(hcd);
struct xhci_hcd_mtk *mtk = hcd_to_mtk(hcd);
int ret;
@@ -502,9 +503,14 @@ static int xhci_mtk_setup(struct usb_hcd *hcd)
return ret;
}
- ret = xhci_gen_setup(hcd, xhci_mtk_quirks);
- if (ret)
- return ret;
+ return xhci_gen_setup(hcd, xhci_mtk_quirks);
+}
+
+static int xhci_mtk_start(struct usb_hcd *hcd)
+{
+ struct xhci_hcd *xhci = hcd_to_xhci(hcd);
+ struct xhci_hcd_mtk *mtk = hcd_to_mtk(hcd);
+ int ret;
if (usb_hcd_is_primary_hcd(hcd)) {
mtk->num_u3_ports = xhci->num_usb3_ports;
@@ -514,7 +520,7 @@ static int xhci_mtk_setup(struct usb_hcd *hcd)
return ret;
}
- return ret;
+ return xhci_run(hcd);
}
static int xhci_mtk_probe(struct platform_device *pdev)
--
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: [PATCH] usb: gadget: uvc: Missing files for configfs interface
Dne 7.3.2017 v 06:58 Laurent Pinchart napsal(a):
> Hi Petr,
>
> Thank you for the patch.
>
> On Tuesday 07 Mar 2017 00:57:20 Petr Cvek wrote:
>> Commit 76e0da34c7ce ("usb-gadget/uvc: use per-attribute show and store
>> methods") caused a stringification of an undefined macro argument "aname",
>> so three UVC parameters (streaming_interval, streaming_maxpacket and
>> streaming_maxburst) were named "aname".
>>
>> Add the definition of "aname" to the main macro and name the filenames as
>> originaly intended.
>
> Why don't you just
>
> - UVC_ATTR(f_uvc_opts_, cname, aname)
> + UVC_ATTR(f_uvc_opts_, cname, cname)
>
> in the definition of the UVCG_OPTS_ATTR() macro ?
Hi,
In a fact I did it for my first testing version. But then I realized two
things. First one is that someone may want to rename these three files (now or
in the future). The second one is that this bug was caused by original author,
who probably assumed the UVCG_OPTS_ATTR macro had "aname" argument as others
UVCG_* macros and didn't check. I assumed that too and only after I saw three
"aname" files with the same path I realized where is the problem.
So it's more like a human error prone type of a code. But if you think "cname"
is enough I can send PATCH v2.
Petr
--
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: Subject: [PATCH v4] USB:Core: BugFix: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously
> On Fri, 3 Mar 2017, Ajay Kaher wrote:
>
> > > usb_class->kref is not accessible outside the file.c
> > > as usb_class is _static_ inside the file.c and
> > > pointer of usb_class->kref is not passed anywhere.
> > >
> > > Hence as you wanted, there are no references of usb_class->kref
> > > other than taken by init_usb_class() and released by destroy_usb_class().
> >
> > Verified the code again, I hope my last comments clarifed the things
> > which came in your mind and helps you to accept the patch :)
>
> Your main point is that usb_class->kref is accessed from only two
> points, both of which are protected by the new mutex. This means there
> is no reason for the value to be a struct kref at all. You should
> change it to an int (and change its name). Leaving it as a kref will
> make readers wonder why it needs to be updated atomically.
At many places in Linux kernel, instances of Kref have been used within
Mutex, SpinLock and don’t have any side effect.
Making to int and handle (i.e. get/put) it within file.c seems
not good as we have Kref. Instead, we can have non_atomic version of kref.
We can discuss about non_atomic kref in another thread, if you are interested.
> Also, why does destroy_usb_class() have that "if (usb_class) "test?
> Isn't it true that usb_class can never be NULL there?
Removed in Patch v4.
thanks,
ajay kaher
Signed-off-by: Ajay Kaher
---
drivers/usb/core/file.c |9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/core/file.c b/drivers/usb/core/file.c
index 822ced9..422ce7b 100644
--- a/drivers/usb/core/file.c
+++ b/drivers/usb/core/file.c
@@ -27,6 +27,7 @@
#define MAX_USB_MINORS 256
static const struct file_operations *usb_minors[MAX_USB_MINORS];
static DECLARE_RWSEM(minor_rwsem);
+static DEFINE_MUTEX(init_usb_class_mutex);
static int usb_open(struct inode *inode, struct file *file)
{
@@ -109,8 +110,9 @@ static void release_usb_class(struct kref *kref)
static void destroy_usb_class(void)
{
- if (usb_class)
- kref_put(&usb_class->kref, release_usb_class);
+ mutex_lock(&init_usb_class_mutex);
+ kref_put(&usb_class->kref, release_usb_class);
+ mutex_unlock(&init_usb_class_mutex);
}
int usb_major_init(void)
@@ -171,7 +173,10 @@ int usb_register_dev(struct usb_interface *intf,
if (intf->minor >= 0)
return -EADDRINUSE;
+ mutex_lock(&init_usb_class_mutex);
retval = init_usb_class();
+ mutex_unlock(&init_usb_class_mutex);
+
if (retval)
return retval;
[PATCH] usb: chipidea: udc: update gadget state after bus resume
Gadget state is set to be suspended when bus suspened, but not updated
after resume, this patch saves the gadget state before suspend and
restores it after resume.
Signed-off-by: Li Jun
---
drivers/usb/chipidea/ci.h | 2 ++
drivers/usb/chipidea/udc.c | 21 +
2 files changed, 15 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/chipidea/ci.h b/drivers/usb/chipidea/ci.h
index 59e2238..6743f85 100644
--- a/drivers/usb/chipidea/ci.h
+++ b/drivers/usb/chipidea/ci.h
@@ -177,6 +177,7 @@ struct hw_bank {
* @td_pool: allocation pool for transfer descriptors
* @gadget: device side representation for peripheral controller
* @driver: gadget driver
+ * @resume_state: save the state of gadget suspend from
* @hw_ep_max: total number of endpoints supported by hardware
* @ci_hw_ep: array of endpoints
* @ep0_dir: ep0 direction
@@ -227,6 +228,7 @@ struct ci_hdrc {
struct usb_gadget gadget;
struct usb_gadget_driver*driver;
+ enum usb_device_state resume_state;
unsignedhw_ep_max;
struct ci_hw_ep ci_hw_ep[ENDPT_MAX];
u32 ep0_dir;
diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index f88e915..be166c6 100644
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
@@ -1845,27 +1845,32 @@ static irqreturn_t udc_irq(struct ci_hdrc *ci)
if (USBi_PCI & intr) {
ci->gadget.speed = hw_port_is_high_speed(ci) ?
USB_SPEED_HIGH : USB_SPEED_FULL;
- if (ci->suspended && ci->driver->resume) {
- spin_unlock(&ci->lock);
- ci->driver->resume(&ci->gadget);
- spin_lock(&ci->lock);
+ if (ci->suspended) {
+ if (ci->driver->resume) {
+ spin_unlock(&ci->lock);
+ ci->driver->resume(&ci->gadget);
+ spin_lock(&ci->lock);
+ }
ci->suspended = 0;
+ usb_gadget_set_state(&ci->gadget,
+ ci->resume_state);
}
}
if (USBi_UI & intr)
isr_tr_complete_handler(ci);
- if (USBi_SLI & intr) {
+ if ((USBi_SLI & intr) && !(ci->suspended)) {
+ ci->suspended = 1;
+ ci->resume_state = ci->gadget.state;
if (ci->gadget.speed != USB_SPEED_UNKNOWN &&
ci->driver->suspend) {
- ci->suspended = 1;
spin_unlock(&ci->lock);
ci->driver->suspend(&ci->gadget);
- usb_gadget_set_state(&ci->gadget,
- USB_STATE_SUSPENDED);
spin_lock(&ci->lock);
}
+ usb_gadget_set_state(&ci->gadget,
+ USB_STATE_SUSPENDED);
}
retval = IRQ_HANDLED;
} else {
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v17 2/3] usb: USB Type-C connector class
> >On Mon, Mar 06, 2017 at 09:15:51AM +0800, Peter Chen wrote: >> > > What interface you use when you receive this event to handle >> > > dual-role switch? I am wonder if a common dual-role class is >> > > needed, then we can have a common user utility. >> > > >> > > Eg, if "data_role" has changed, the udev can echo "data_role" to >> > > /sys/class/usb-dual-role/role >> > >> > No. If the partner executes successfully for example DR_Swap >> > message, the kernel has to take care everything that is needed for >> > the role to be what ever was negotiated on its own. User space can't >> > be involved with that. >> > >> >> Would you give me an example how kernel handle this? How type-C event >> triggers role switch? > >On our boards, the firmware or EC (or ACPI) configures the hardware as needed >and also notifies the components using ACPI if needed. It's often not even >possible to >directly configure the components/hardware for a particular role. > You mean type-C trigger an ACPI event, and this ACPI event can notify related USB controller driver doing role switch? If it is correct, there is a notifier between type-C and USB controller driver, how to define this notifier for non-ACPI platform? >I'm not commenting on Roger's dual role patch series, but I don't really think >it should >be mixed with Type-C. USB Type-C and USB Power Delivery define their own ways >of handling the roles, and they are not limited to the data role only. Things >like OTG >for example will, and actually can not be supported. With Type-C we will have >competing state machines compared to OTG. The dual-role framework may be >useful on systems that provide more traditional connectors, which possibly >have the >ID-pin like micro-AB, and possibly also support OTG. It can also be something >that >exist in parallel with the Type-C class, but there just can not be any >dependencies >between the two. > Yes, there are two independent things. But if the kernel doesn't have a notifier between type-C message sender (type-c class) and message receiver (like USB controller driver for role switch or other drivers for alternate mode message), we had to find some ways at userspace. Peter -- 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/2] usb: xhci-mtk: check hcc_params after adding primary hcd
hcc_params is set in xhci_gen_setup() called from usb_add_hcd(), so checks the Maximum Primary Stream Array Size in the hcc_params register after adding primary hcd. Signed-off-by: Chunfeng Yun --- drivers/usb/host/xhci-mtk.c |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c index 9066ec9..6ac73a6 100644 --- a/drivers/usb/host/xhci-mtk.c +++ b/drivers/usb/host/xhci-mtk.c @@ -678,13 +678,13 @@ static int xhci_mtk_probe(struct platform_device *pdev) goto power_off_phys; } - if (HCC_MAX_PSA(xhci->hcc_params) >= 4) - xhci->shared_hcd->can_do_streams = 1; - ret = usb_add_hcd(hcd, irq, IRQF_SHARED); if (ret) goto put_usb3_hcd; + if (HCC_MAX_PSA(xhci->hcc_params) >= 4) + xhci->shared_hcd->can_do_streams = 1; + ret = usb_add_hcd(xhci->shared_hcd, irq, IRQF_SHARED); if (ret) goto dealloc_usb2_hcd; -- 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 2/2] usb: xhci: remove dummy extra_priv_size for size of xhci_hcd struct
because hcd_priv_size is already size of xhci_hcd struct,
extra_priv_size is not needed anymore for MTK and tegra drivers.
Signed-off-by: Chunfeng Yun
---
drivers/usb/host/xhci-mtk.c |1 -
drivers/usb/host/xhci-tegra.c |1 -
2 files changed, 2 deletions(-)
diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c
index 6ac73a6..67d5dc7 100644
--- a/drivers/usb/host/xhci-mtk.c
+++ b/drivers/usb/host/xhci-mtk.c
@@ -382,7 +382,6 @@ static int usb_wakeup_of_property_parse(struct xhci_hcd_mtk
*mtk,
static int xhci_mtk_setup(struct usb_hcd *hcd);
static const struct xhci_driver_overrides xhci_mtk_overrides __initconst = {
- .extra_priv_size = sizeof(struct xhci_hcd),
.reset = xhci_mtk_setup,
};
diff --git a/drivers/usb/host/xhci-tegra.c b/drivers/usb/host/xhci-tegra.c
index a59fafb..74436f8 100644
--- a/drivers/usb/host/xhci-tegra.c
+++ b/drivers/usb/host/xhci-tegra.c
@@ -1308,7 +1308,6 @@ static int tegra_xhci_setup(struct usb_hcd *hcd)
}
static const struct xhci_driver_overrides tegra_xhci_overrides __initconst = {
- .extra_priv_size = sizeof(struct xhci_hcd),
.reset = tegra_xhci_setup,
};
--
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 1/1] usb: host: xhci-dbg: HCIVERSION should be a binary number
According to xHCI spec, HCIVERSION containing a BCD encoding
of the xHCI specification revision number, 0100h corresponds
to xHCI version 1.0. Change "100" as "0x100".
Cc: Lu Baolu
Cc: stable
Fixes: 04abb6de2825 ("xhci: Read and parse new xhci
1.1 capability register")
Signed-off-by: Peter Chen
---
drivers/usb/host/xhci-dbg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci-dbg.c b/drivers/usb/host/xhci-dbg.c
index 363d125..2b4a00f 100644
--- a/drivers/usb/host/xhci-dbg.c
+++ b/drivers/usb/host/xhci-dbg.c
@@ -109,7 +109,7 @@ static void xhci_print_cap_regs(struct xhci_hcd *xhci)
xhci_dbg(xhci, "RTSOFF 0x%x:\n", temp & RTSOFF_MASK);
/* xhci 1.1 controllers have the HCCPARAMS2 register */
- if (hci_version > 100) {
+ if (hci_version > 0x100) {
temp = readl(&xhci->cap_regs->hcc_params2);
xhci_dbg(xhci, "HCC PARAMS2 0x%x:\n", (unsigned int) temp);
xhci_dbg(xhci, " HC %s Force save context capability",
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usb: gadget: webcam broken?
Dne 2.3.2017 v 09:19 Roger Quadros napsal(a): > Petr, > > On 02/03/17 06:57, Petr Cvek wrote: >> Dne 2.3.2017 v 00:22 Laurent Pinchart napsal(a): >>> Hi Roger, >>> >>> On Wednesday 01 Mar 2017 17:09:51 Roger Quadros wrote: Hi, I'm no longer able to use g_webcam with uvc-gadget [1] since v4.9. Logs at the end. It looks like we're goofing up on the control endpoint. If I revert the following commit everything works fine. commit 4fbac5206afd01b717d4bdc58793d471f3391b4b Author: Petr Cvek Date: Wed Aug 17 12:36:57 2016 +0200 usb: gadget: uvc: Add missing call for additional setup data Am I missing something on uvc-gadget side or is the commit really bad? From what I understand, uvc-gadget is responsible for sending response to UVC class specific requests on control endpoint in uvc_send_response() in uvc_v4l2.c. So the reported commit is sending a duplicate response with probably improper data. >>> >>> Yes, this looks very dubious to me. I think it should be reverted. My >>> apologies for not having caught the patch during review. >> >> Hi, >> >> Now I've watched all codepaths again and yeah it is probably wrong patch, >> sorry. >> >> But if the code path is really: >> >> uvc_function_setup() -> userspace setup -> ioctl UVCIOC_SEND_RESPONSE -> >> uvc_send_response() -> usb_ep_queue() -> uvc_function_ep0_complete() -> >> userspace data >> >> it seems the USB timeouts with my hardware (PXA27x UDC) but with my patch it >> gets response immediately. >> > > I hope you were running uvc-gadget application on the PXA27x. > > Just sending a response is not sufficient. It must send a response with > proper data. > f_uvc itself doesn't know how to handle UVC class specific requests and has to > depend on the user space application to populate the data in the response. > Hi, Yeah it was on the PXA27x, but that callback is not working there, so I was mistaken the bug is in UVC and not in PXA27x UDC itself. Anyway I was using a newer (unofficial [1]) version of uvc-gadget, which already implements the most of the UVC requests. BTW Did you try to use a configfs method for your usb webcam application? There was a discussion [2] about removing legacy UDC stuff (g_webcam and others g_*) in the future. If you used it, does it create these files for you? streaming_interval streaming_maxpacket streaming_maxburst P.S. Are you planning to use some generic linux friendly USB VID/PID? ;-) [1] https://github.com/madscientist42/uvc-gadget/commit/e127ec3a3022e1090b3b741b48f661670f5dade2 [2] http://www.spinics.net/lists/linux-usb/msg152678.html -- cheers, Petr -- 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] usb: gadget: uvc: webcam gadget USB PID is using value from a different gadget
Dne 24.1.2017 v 19:20 Felipe Balbi napsal(a): > > Hi, > > Petr Cvek writes: >>> Greg KH writes: >>> fine by me. Just lsusb will look funky ;-) >> >> Heh, true, but I thought lsusb would use a string if the device provided >> it. Haven't looked at that portion of the code in a very long time... >> > > My lsusb shows separate strings (using usbutils from slackware64-current): > > Bus 004 Device 003: ID 1d6b:0102 Linux Foundation EEM Gadget > ... > idVendor 0x1d6b Linux Foundation > idProduct 0x0102 EEM Gadget > bcdDevice4.07 > iManufacturer 1 Linux Foundation > iProduct2 Webcam gadget > ... Ah, I guess it doesn't, but who knows how old that version of usbutils is, considering the last release I did was well over a year ago. I should do a new one one of these days... Anyway, I'd like to not assign a product id to a chunk of code that is going to be eventually deleted. Felipe, what's the plan for the "legacy" gadget code. Is it ever going away? >>> >>> Well, I wasn't really planning on deleting them just stopped accepting >>> any new one. I wanted to avoid angry mobs complaining about not having a >>> g_mass_storage.ko anymore. >>> >>> Personally, I don't feel strongly about the legacy gadget >>> drivers. They're not really needed anymore as everything they do can be >>> done with configfs already. Perhaps we could schedule their removal for >>> v5.0? >>> >> >> If you want to remove legacy g_webcam then there should be a way to >> set its module parameters from somewhere (it seems I can't find it >> anywhere). For PXA27x especially "opts->streaming_maxpacket" from >> f_uvc.c is critical. Default max packet size in PXA27x UDC (but >> lowering the limit to 256 by g_webcam parameter works). > > it should be part of the function's configfs interface. If it's not, > please send a patch. Have a look at > Documentation/usb/gadget_configfs.txt for more info. > Hi sorry for a late answer (it took so much time to get my machine to the stage with working UVC :-/ ). It is really not working and I think I found why. Will send a patch soon. Petr -- 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] uvc-gadget: Fix Set Interface (alternate setting) response behaviour
Hi Roger, Thank you for the patch. On Friday 03 Mar 2017 13:17:15 Roger Quadros wrote: > On alternate setting change, webcam gadget sends us a UVC_EVENT_STREAMON > or UVC_EVENT_STREAMOFF event. It expects delayed status response on > STREAMON event only but doesn't expect us to send that response over USB. > It sends the delayed response when we issue the VIDIOC_STREAMON ioctl. > > So we must not send UVCIOC_SEND_RESPONSE ioctl in these cases that too > with invalid response length. The commit message only explains why we should not call UVCIOC_SEND_RESPONSE in response to a STREAMON event, but not why we shouldn't either in response to a STREAMOFF event. The patch is correct changing both, but I propose wording the above two paragraphs as follows. "uvc-gadget: Do not send Set Interface (alternate setting) response twice On alternate setting change, the webcam gadget sends us a UVC_EVENT_STREAMON or UVC_EVENT_STREAMOFF event. In the first case, the driver will issue a delayed status response automatically when we call the VIDIOC_STREAMON ioctl. In the second case, the driver sends the status response immediately. We must thus not send the status response manually with UVCIOC_SEND_RESPONSE in any of those cases." If you're fine with that I'll change the message when applying, there's no need to resend the patch. > Without this, the ISO streaming doesn't work if host application > (e.g. luvcview) is closed and restarted. > On dwc3 gadget controller it was resulting in Buffer Expiry error on > the ISO endpoint. > > Signed-off-by: Roger Quadros > --- > uvc-gadget.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/uvc-gadget.c b/uvc-gadget.c > index 9ef315c..4d59ab8 100644 > --- a/uvc-gadget.c > +++ b/uvc-gadget.c > @@ -597,12 +597,12 @@ uvc_events_process(struct uvc_device *dev) > case UVC_EVENT_STREAMON: > uvc_video_reqbufs(dev, 4); > uvc_video_stream(dev, 1); > - break; > + return; > > case UVC_EVENT_STREAMOFF: > uvc_video_stream(dev, 0); > uvc_video_reqbufs(dev, 0); > - break; > + return; > } > > ioctl(dev->fd, UVCIOC_SEND_RESPONSE, &resp); -- Regards, Laurent Pinchart -- 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 21/29] drivers, s390: convert fc_fcp_pkt.ref_cnt from atomic_t to refcount_t
On Mon, Mar 06, 2017 at 04:27:11PM +0100, Johannes Thumshirn wrote: > On 03/06/2017 03:21 PM, Elena Reshetova wrote: > > refcount_t type and corresponding API should be > > used instead of atomic_t when the variable is used as > > a reference counter. This allows to avoid accidental > > refcounter overflows that might lead to use-after-free > > situations. > > The subject is wrong, should be something like "scsi: libfc convert > fc_fcp_pkt.ref_cnt from atomic_t to refcount_t" but not s390. > Yes please, I was extremely confused for a moment here. Beste Grüße / Best regards, - Benjamin Block -- Linux on z Systems Development / IBM Systems & Technology Group IBM Deutschland Research & Development GmbH Vorsitz. AufsR.: Martina Koederitz /Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen / Registergericht: AmtsG Stuttgart, HRB 243294 -- 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: query on UCSI
Hi Heikki , Thanks for the prompt reply. If i understood correctly the current driver(drivers/usb/misc/ucsi.c) supports the OPM and rest all is taken care by EC FW with BIOS . In ucsi.c file i did not find any mailbox related code. Am I missing something here? Thanks Nehal On 3/6/2017 8:01 PM, Heikki Krogerus wrote: > Hi, > > On Mon, Mar 06, 2017 at 02:41:17PM +0530, Shah, Nehal-bakulchandra wrote: >> Hi Greg and Heikki, >> >> >> I can see that ucsi acpi interface driver is available in kernel tree. I have >> following queries on the same. Kindly pardon my ignorance as i am a novice to >> this. >> >> - Is there any implementation of USB-C system policy manager (OPM) in Linux? > > I think the question here is do we have an implementation for OPM (OS > Policy Manager) which would be in practice the driver we have for UCSI > in Linux kernel. > > System policy manager is implemented in BIOS and/or EC FW with UCSI (check > Figure 2-1 in bios-implementation-of-ucsi.pdf). > >> - If yes to USB-C system policy, are there any requirements that differ from >> the published Intel White paper on UCSI support through ACPI Mailbox method? >> (Link: >> http://www.intel.com/content/dam/www/public/us/en/documents/white-papers/bios-implementation-of-ucsi.pdf >> ) > > No other requirements. > > > Br, > -- 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: [Xen-devel] [PATCH 29/29] drivers, xen: convert grant_map.users from atomic_t to refcount_t
On 03/06/2017 09:21 AM, Elena Reshetova wrote: > refcount_t type and corresponding API should be > used instead of atomic_t when the variable is used as > a reference counter. This allows to avoid accidental > refcounter overflows that might lead to use-after-free > situations. > > Signed-off-by: Elena Reshetova > Signed-off-by: Hans Liljestrand > Signed-off-by: Kees Cook > Signed-off-by: David Windsor > --- > drivers/xen/gntdev.c | 11 ++- > 1 file changed, 6 insertions(+), 5 deletions(-) Reviewed-by: Boris Ostrovsky -- 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 0/5] USB: serial: fix missing sanity checks and refleak
These patches fix a NULL-deref and a couple of information leaks due to missing sanity checks in completion handlers. Included is also a tty-reference leak fix. Johan Johan Hovold (5): USB: serial: io_ti: fix NULL-deref in interrupt callback USB: serial: omninet: fix reference leaks at open USB: serial: omninet: drop open callback USB: serial: io_ti: fix information leak in completion handler USB: serial: safe_serial: fix information leak in completion handler drivers/usb/serial/io_ti.c | 8 +++- drivers/usb/serial/omninet.c | 13 - drivers/usb/serial/safe_serial.c | 5 + 3 files changed, 12 insertions(+), 14 deletions(-) -- 2.12.0 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/5] USB: serial: io_ti: fix NULL-deref in interrupt callback
Fix a NULL-pointer dereference in the interrupt callback should a
malicious device send data containing a bad port number by adding the
missing sanity check.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: stable
Signed-off-by: Johan Hovold
---
drivers/usb/serial/io_ti.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/usb/serial/io_ti.c b/drivers/usb/serial/io_ti.c
index ceaeebaa6f90..4561dd4cde8b 100644
--- a/drivers/usb/serial/io_ti.c
+++ b/drivers/usb/serial/io_ti.c
@@ -1674,6 +1674,12 @@ static void edge_interrupt_callback(struct urb *urb)
function= TIUMP_GET_FUNC_FROM_CODE(data[0]);
dev_dbg(dev, "%s - port_number %d, function %d, info 0x%x\n", __func__,
port_number, function, data[1]);
+
+ if (port_number >= edge_serial->serial->num_ports) {
+ dev_err(dev, "bad port number %d\n", port_number);
+ goto exit;
+ }
+
port = edge_serial->serial->port[port_number];
edge_port = usb_get_serial_port_data(port);
if (!edge_port) {
--
2.12.0
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/5] USB: serial: omninet: fix reference leaks at open
This driver needlessly took another reference to the tty on open, a
reference which was then never released on close. This lead to not just
a leak of the tty, but also a driver reference leak that prevented the
driver from being unloaded after a port had once been opened.
Fixes: 4a90f09b20f4 ("tty: usb-serial krefs")
Cc: stable # 2.6.28
Signed-off-by: Johan Hovold
---
drivers/usb/serial/omninet.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/usb/serial/omninet.c b/drivers/usb/serial/omninet.c
index a180b17d2432..76564b3bebb9 100644
--- a/drivers/usb/serial/omninet.c
+++ b/drivers/usb/serial/omninet.c
@@ -142,12 +142,6 @@ static int omninet_port_remove(struct usb_serial_port
*port)
static int omninet_open(struct tty_struct *tty, struct usb_serial_port *port)
{
- struct usb_serial *serial = port->serial;
- struct usb_serial_port *wport;
-
- wport = serial->port[1];
- tty_port_tty_set(&wport->port, tty);
-
return usb_serial_generic_open(tty, port);
}
--
2.12.0
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/5] USB: serial: io_ti: fix information leak in completion handler
Add missing sanity check to the bulk-in completion handler to avoid an
integer underflow that can be triggered by a malicious device.
This avoids leaking 128 kB of memory content from after the URB transfer
buffer to user space.
Fixes: 8c209e6782ca ("USB: make actual_length in struct urb field u32")
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: stable # 2.6.30
Signed-off-by: Johan Hovold
---
drivers/usb/serial/io_ti.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/serial/io_ti.c b/drivers/usb/serial/io_ti.c
index 4561dd4cde8b..a76b95d32157 100644
--- a/drivers/usb/serial/io_ti.c
+++ b/drivers/usb/serial/io_ti.c
@@ -1761,7 +1761,7 @@ static void edge_bulk_in_callback(struct urb *urb)
port_number = edge_port->port->port_number;
- if (edge_port->lsr_event) {
+ if (urb->actual_length > 0 && edge_port->lsr_event) {
edge_port->lsr_event = 0;
dev_dbg(dev, "%s = Port %u LSR Status = %02x, Data = %02x
==\n",
__func__, port_number, edge_port->lsr_mask, *data);
--
2.12.0
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/5] USB: serial: omninet: drop open callback
Remove the now redundant open callback and let core call the generic
handler for us instead.
Signed-off-by: Johan Hovold
---
drivers/usb/serial/omninet.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/usb/serial/omninet.c b/drivers/usb/serial/omninet.c
index 76564b3bebb9..dd706953b466 100644
--- a/drivers/usb/serial/omninet.c
+++ b/drivers/usb/serial/omninet.c
@@ -31,7 +31,6 @@
#define BT_IGNITIONPRO_ID 0x2000
/* function prototypes */
-static int omninet_open(struct tty_struct *tty, struct usb_serial_port *port);
static void omninet_process_read_urb(struct urb *urb);
static void omninet_write_bulk_callback(struct urb *urb);
static int omninet_write(struct tty_struct *tty, struct usb_serial_port *port,
@@ -60,7 +59,6 @@ static struct usb_serial_driver zyxel_omninet_device = {
.attach = omninet_attach,
.port_probe = omninet_port_probe,
.port_remove = omninet_port_remove,
- .open = omninet_open,
.write =omninet_write,
.write_room = omninet_write_room,
.write_bulk_callback = omninet_write_bulk_callback,
@@ -140,11 +138,6 @@ static int omninet_port_remove(struct usb_serial_port
*port)
return 0;
}
-static int omninet_open(struct tty_struct *tty, struct usb_serial_port *port)
-{
- return usb_serial_generic_open(tty, port);
-}
-
#define OMNINET_HEADERLEN 4
#define OMNINET_BULKOUTSIZE64
#define OMNINET_PAYLOADSIZE(OMNINET_BULKOUTSIZE - OMNINET_HEADERLEN)
--
2.12.0
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/5] USB: serial: safe_serial: fix information leak in completion handler
Add missing sanity check to the bulk-in completion handler to avoid an
integer underflow that could be triggered by a malicious device.
This avoids leaking up to 56 bytes from after the URB transfer buffer to
user space.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: stable
Signed-off-by: Johan Hovold
---
drivers/usb/serial/safe_serial.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/usb/serial/safe_serial.c b/drivers/usb/serial/safe_serial.c
index 93c6c9b08daa..8a069aa154ed 100644
--- a/drivers/usb/serial/safe_serial.c
+++ b/drivers/usb/serial/safe_serial.c
@@ -200,6 +200,11 @@ static void safe_process_read_urb(struct urb *urb)
if (!safe)
goto out;
+ if (length < 2) {
+ dev_err(&port->dev, "malformed packet\n");
+ return;
+ }
+
fcs = fcs_compute10(data, length, CRC10_INITFCS);
if (fcs) {
dev_err(&port->dev, "%s - bad CRC %x\n", __func__, fcs);
--
2.12.0
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/29] drivers, media: convert cx88_core.refcount from atomic_t to refcount_t
Hello.
On 03/06/2017 05:20 PM, Elena Reshetova wrote:
refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.
Signed-off-by: Elena Reshetova
Signed-off-by: Hans Liljestrand
Signed-off-by: Kees Cook
Signed-off-by: David Windsor
[...]
diff --git a/drivers/media/pci/cx88/cx88.h b/drivers/media/pci/cx88/cx88.h
index 115414c..16c1313 100644
--- a/drivers/media/pci/cx88/cx88.h
+++ b/drivers/media/pci/cx88/cx88.h
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include
#include
@@ -339,7 +340,7 @@ struct cx8802_dev;
struct cx88_core {
struct list_head devlist;
- atomic_t refcount;
+ refcount_t refcount;
Could you please keep the name aligned with above and below?
/* board name */
intnr;
MBR, Sergei
--
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
usb bus resets when harddisk wakes up after spindown
Hi!
I have an external 2 disk hd enclosure with a UASP capable JMicron USB 3 bridge:
[1.271826] usb 4-1: New USB device found, idVendor=152d, idProduct=9561
[1.271952] usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=5
[1.272075] usb 4-1: Product: JMS56x Series
[1.272180] usb 4-1: Manufacturer: JMicron
As the disks are only used for backup, I stop them after some idle time using
"sg_start -readonly --stop".
Normally, the drive automatically spins up in about 5 seconds at the first IO
and everything works fine.
Unfortunately, every now and then, though the drive spins up as usually, IO
hangs, followed by an IO error and a USB bus reset:
Feb 28 09:15:42 apu kernel: [130773.500866] sd 2:0:0:1: [sdc] tag#0
uas_eh_abort_handler 0 uas-tag 1 inflight: CMD IN
Feb 28 09:15:42 apu kernel: [130773.500869] sd 2:0:0:1: [sdc] tag#0 CDB:
Read(16) 88 00 00 00 00 00 08 00 10 02 00 00 00 01 00 00
Feb 28 09:15:42 apu kernel: [130773.500992] scsi host2:
uas_eh_bus_reset_handler start
Feb 28 09:15:42 apu kernel: [130773.606321] usb 4-1: reset SuperSpeed USB
device number 2 using xhci_hcd
Feb 28 09:15:42 apu kernel: [130773.624511] scsi host2:
uas_eh_bus_reset_handler success
Feb 28 09:15:46 apu kernel: [130777.867050] xhci_hcd :03:00.0: Cannot set
link state.
Feb 28 09:15:46 apu kernel: [130777.867056] usb usb4-port1: cannot disable (err
= -32)
Feb 28 09:15:46 apu kernel: [130777.867061] usb 4-1: USB disconnect, device
number 2
Feb 28 09:15:46 apu kernel: [130777.867174] xhci_hcd :03:00.0: ERROR
Transfer event for disabled endpoint or incorrect stream ring
Feb 28 09:15:46 apu kernel: [130777.867178] xhci_hcd :03:00.0:
@00045852e810 1a00 01058001
Feb 28 09:15:46 apu kernel: [130777.867218] sd 2:0:0:1: [sdc] tag#0
uas_zap_pending 0 uas-tag 1 inflight: CMD
Feb 28 09:15:46 apu kernel: [130777.867221] sd 2:0:0:1: [sdc] tag#0 CDB: Test
Unit Ready 00 00 00 00 00 00
Feb 28 09:15:46 apu kernel: [130777.867240] sd 2:0:0:1: Device offlined - not
ready after error recovery
Feb 28 09:15:46 apu kernel: [130777.867246] sd 2:0:0:1: [sdc] tag#0 FAILED
Result: hostbyte=DID_OK driverbyte=DRIVER_TIMEOUT
Feb 28 09:15:46 apu kernel: [130777.867248] sd 2:0:0:1: [sdc] tag#0 CDB:
Read(16) 88 00 00 00 00 00 08 00 10 02 00 00 00 01 00 00
Feb 28 09:15:46 apu kernel: [130777.867250] blk_update_request: I/O error, dev
sdc, sector 134221826
Feb 28 09:15:46 apu kernel: [130777.868007] XFS (dm-4): metadata I/O error:
block 0x802 ("xfs_trans_read_buf_map") error 5 numblks 1
Feb 28 09:15:46 apu kernel: [130777.868038] sd 2:0:0:1: rejecting I/O to
offline device
[...]
Feb 28 09:15:46 apu kernel: [130777.994342] sd 2:0:0:0: [sdb] Synchronize
Cache(10) failed: Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK
Feb 28 09:15:46 apu kernel: [130778.031714] sd 2:0:0:1: [sdc] Synchronizing
SCSI cache
Feb 28 09:15:46 apu kernel: [130778.155155] sd 2:0:0:1: [sdc] Synchronize
Cache(10) failed: Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK
Feb 28 09:15:54 apu kernel: [130785.962545] usb 4-1: new SuperSpeed USB device
number 3 using xhci_hcd
Feb 28 09:15:54 apu kernel: [130785.979595] usb 4-1: New USB device found,
idVendor=152d, idProduct=9561
Feb 28 09:15:54 apu kernel: [130785.979598] usb 4-1: New USB device strings:
Mfr=1, Product=2, SerialNumber=5
Feb 28 09:15:54 apu kernel: [130785.979599] usb 4-1: Product: JMS56x Series
Feb 28 09:15:54 apu kernel: [130785.979601] usb 4-1: Manufacturer: JMicron
Feb 28 09:15:54 apu kernel: [130785.979602] usb 4-1: SerialNumber:
Feb 28 09:15:54 apu kernel: [130785.984579] scsi host4: uas
Feb 28 09:15:54 apu kernel: [130785.985113] scsi 4:0:0:0: Direct-Access WDC
WD30 PURX-64P6ZY0 0106 PQ: 0 ANSI: 6
Feb 28 09:15:54 apu kernel: [130786.025035] scsi 4:0:0:1: Direct-Access WDC
WD30 PURX-64P6ZY0 0106 PQ: 0 ANSI: 6
Feb 28 09:15:54 apu kernel: [130786.071679] sd 4:0:0:0: Attached scsi generic
sg1 type 0
Feb 28 09:15:54 apu kernel: [130786.072295] sd 4:0:0:0: [sde] 5860533168
512-byte logical blocks: (3.00 TB/2.73 TiB)
Feb 28 09:15:54 apu kernel: [130786.072548] sd 4:0:0:1: Attached scsi generic
sg2 type 0
Feb 28 09:15:54 apu kernel: [130786.079545] sd 4:0:0:1: [sdf] 5860533168
512-byte logical blocks: (3.00 TB/2.73 TiB)
Feb 28 09:15:54 apu kernel: [130786.080979] sd 4:0:0:0: [sde] Write Protect is
off
Feb 28 09:15:54 apu kernel: [130786.080982] sd 4:0:0:0: [sde] Mode Sense: 67 00
10 08
Feb 28 09:15:54 apu kernel: [130786.081748] sd 4:0:0:0: [sde] Write cache:
enabled, read cache: enabled, supports DPO and FUA
Feb 28 09:15:54 apu kernel: [130786.082351] sd 4:0:0:1: [sdf] Write Protect is
off
Feb 28 09:15:54 apu kernel: [130786.082354] sd 4:0:0:1: [sdf] Mode Sense: 67 00
10 08
Feb 28 09:15:54 apu kernel: [130786.083100] sd 4:0:0:1: [sdf] Write cache:
enabled, read cache: enabled, supports DPO and FUA
Feb 28 09:15:54 apu kernel: [130786.159798] sde: sde1
Feb 28 09:15:54 apu kernel: [130786.20
RE: Panic in quirk_usb_early_handoff
> From: Mason
> Sent: 06 March 2017 15:46
...
> >> The issue was that, on this platform, the PCI configuration space
> >> and memory space are multiplexed; in other words they reside at
> >> the same physical address, with a bit in MMIO to choose one or
> >> the other.
> >
> > Time to shoot another hardware engineer.
>
> He's in CC :-)
>
> > Hopefully it isn't an SMP system - but I wouldn't put it past them.
>
> This is a dual- and quad- Cortex A9 MP platform :-(
So to do a config space access you have to use a pair of IPIs
to stop the other cpus doing any PCIe data accesses while the
MMIO bit makes the accesses all point to config space.
(After taking a lock to get access to the MMIO register.)
Or has someone a better idea?
David
N�r��yb�X��ǧv�^�){.n�+{��^n�r���z���h�&�� �G���h�(�階�ݢj"���m��z�ޖ���f���h���~�m�
Re: [PATCH 00/21] USB: serial: refactor endpoint sanity checks
On Mon, Mar 06, 2017 at 04:01:36PM +0100, Johan Hovold wrote: > On Mon, Mar 06, 2017 at 02:14:51PM +0100, Oliver Neukum wrote: > > Am Montag, den 06.03.2017, 12:27 +0100 schrieb Johan Hovold: > > > On Mon, Mar 06, 2017 at 10:54:44AM +0100, Oliver Neukum wrote: > > > > True, but again not specific to serial drivers. DVB-T will face > > > > the same issues. > > > > > > Certainly, and I should have elaborated a bit more on the > > > differences here. For USB-serial endpoint-resources are allocated > > > only after subdriver probe returns, while for most (all) other USB > > > driver this would need to be done in the USB probe callback > > > directly. In that case, checking before probe might be too soon (fw > > > download, altsetting) and checking after would be too late (endpoint > > > resources would already need to have been setup). > > > > Now that argues for usbserial to trigger the check itself, but not for > > the code doing the check living in usbserial. In other words put > > > > struct usb_serial_endpoints and find_endpoints into usbcore and > > call it from usbserial. Add a flag to tell usbcore to not check > > this by itself and you are done. (With some generic name changes) > > > > That way everybody can use it almost for free. > > An idea would be to always construct the endpoint-data struct (as a > member of usb_interface) when setting an alternate setting (or always > keep it around in usb_host_interface), and provide minimal constraints > per usb_driver which core verified before probe unless a flag is set. > > Would the overhead for this be acceptable? I guess some more memory > would be required for control and isochronous endpoints too. A variant would be to always store the endpoint-type counts in struct usb_host_interface. That's often all that's needed to do the sanity checks (including the cdc-acm case) and only adds 7 bytes per altsetting. Then a find_endpoints helper can be added to partition the endpoints of a given altsetting. Johan -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Panic in quirk_usb_early_handoff
On 06/03/2017 16:27, David Laight wrote: > Mason wrote: >> >>> So the kernel panics in xhci_find_next_ext_cap() >>> ( drivers/usb/host/xhci-ext-caps.h:122 ) >>> http://lxr.free-electrons.com/source/drivers/usb/host/xhci-ext-caps.h?v=4.9#L122 >>> >>> Any idea how this can happen? >>> >>> base = ioremap_nocache(pci_resource_start(pdev, 0), len); >>> >>> Could I be passing garbage to ioremap_nocache? >> >> Oh... >> >> I have just now understood what Ard wrote a few days ago. >> >> The issue was that, on this platform, the PCI configuration space >> and memory space are multiplexed; in other words they reside at >> the same physical address, with a bit in MMIO to choose one or >> the other. > > Time to shoot another hardware engineer. He's in CC :-) > Hopefully it isn't an SMP system - but I wouldn't put it past them. This is a dual- and quad- Cortex A9 MP platform :-( Regards. -- 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 21/29] drivers, s390: convert fc_fcp_pkt.ref_cnt from atomic_t to refcount_t
On 03/06/2017 03:21 PM, Elena Reshetova wrote: > refcount_t type and corresponding API should be > used instead of atomic_t when the variable is used as > a reference counter. This allows to avoid accidental > refcounter overflows that might lead to use-after-free > situations. The subject is wrong, should be something like "scsi: libfc convert fc_fcp_pkt.ref_cnt from atomic_t to refcount_t" but not s390. Other than that Acked-by: Johannes Thumshirn -- Johannes Thumshirn Storage jthumsh...@suse.de+49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850 -- 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: Panic in quirk_usb_early_handoff
From: Mason
> Sent: 06 March 2017 13:50
> On 06/03/2017 13:42, Mason wrote:
>
> > So the kernel panics in xhci_find_next_ext_cap()
> > ( drivers/usb/host/xhci-ext-caps.h:122 )
> > http://lxr.free-electrons.com/source/drivers/usb/host/xhci-ext-caps.h?v=4.9#L122
> >
> > Any idea how this can happen?
> >
> > base = ioremap_nocache(pci_resource_start(pdev, 0), len);
> >
> > Could I be passing garbage to ioremap_nocache?
>
> Oh...
>
> I have just now understood what Ard wrote a few days ago.
>
> The issue was that, on this platform, the PCI configuration space
> and memory space are multiplexed; in other words they reside at
> the same physical address, with a bit in MMIO to choose one or
> the other.
Time to shoot another hardware engineer.
Hopefully it isn't an SMP system - but I wouldn't put it past them.
David
N�r��yb�X��ǧv�^�){.n�+{��^n�r���z���h�&�� �G���h�(�階�ݢj"���m��z�ޖ���f���h���~�m�
[PATCH 03/29] drivers, char: convert vma_data.refcnt from atomic_t to refcount_t
refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.
Signed-off-by: Elena Reshetova
Signed-off-by: Hans Liljestrand
Signed-off-by: Kees Cook
Signed-off-by: David Windsor
---
drivers/char/mspec.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/char/mspec.c b/drivers/char/mspec.c
index a9c2fa3..7b75669 100644
--- a/drivers/char/mspec.c
+++ b/drivers/char/mspec.c
@@ -43,6 +43,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -89,7 +90,7 @@ static int is_sn2;
* protect in fork case where multiple tasks share the vma_data.
*/
struct vma_data {
- atomic_t refcnt;/* Number of vmas sharing the data. */
+ refcount_t refcnt; /* Number of vmas sharing the data. */
spinlock_t lock;/* Serialize access to this structure. */
int count; /* Number of pages allocated. */
enum mspec_page_type type; /* Type of pages allocated. */
@@ -144,7 +145,7 @@ mspec_open(struct vm_area_struct *vma)
struct vma_data *vdata;
vdata = vma->vm_private_data;
- atomic_inc(&vdata->refcnt);
+ refcount_inc(&vdata->refcnt);
}
/*
@@ -162,7 +163,7 @@ mspec_close(struct vm_area_struct *vma)
vdata = vma->vm_private_data;
- if (!atomic_dec_and_test(&vdata->refcnt))
+ if (!refcount_dec_and_test(&vdata->refcnt))
return;
last_index = (vdata->vm_end - vdata->vm_start) >> PAGE_SHIFT;
@@ -274,7 +275,7 @@ mspec_mmap(struct file *file, struct vm_area_struct *vma,
vdata->vm_end = vma->vm_end;
vdata->type = type;
spin_lock_init(&vdata->lock);
- atomic_set(&vdata->refcnt, 1);
+ refcount_set(&vdata->refcnt, 1);
vma->vm_private_data = vdata;
vma->vm_flags |= VM_IO | VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP;
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] uvc-gadget: Fix Set Interface (alternate setting) response behaviour
On Mon, Mar 06, 2017 at 04:29:33PM +0200, Felipe Balbi wrote: > > Hi, > > Roger Quadros writes: > > <<< No Message Collected >>> > > You need to resend this. See also [1] Not sure what is wrong. This happens to me too, see [2]. And I sent the patch v2 an hour ago, but the patch is still not on the mailing list yet, normally it doesn't take that long... > > [1] https://marc.info/?l=linux-usb&m=148854335620717&w=2 [2] http://www.spinics.net/lists/linux-usb/msg154158.html Regards, -Bin. -- 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] usb: add CONFIG_USB_PCI for system have both PCI HW and non-PCI based USB HW
On Mon, Mar 06, 2017 at 04:48:50PM +0200, Felipe Balbi wrote: > > Hi, > > yuan linyu writes: > > From: yuan linyu > > > > a lot of embeded system SOC (e.g. freescale T2080) have both > > PCI and USB modules. But USB module is controlled by registers directly, > > it have no relationship with PCI module. > > > > when say N here it will not build PCI related code in USB driver. > > > > Signed-off-by: yuan linyu > > I have no problems with this, just worried about how we should merge > it. Greg, will you take this directly? If so: > > Acked-by: Felipe Balbi I'll take it, thanks. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/21] USB: serial: refactor endpoint sanity checks
On Mon, Mar 06, 2017 at 02:14:51PM +0100, Oliver Neukum wrote:
> Am Montag, den 06.03.2017, 12:27 +0100 schrieb Johan Hovold:
> > On Mon, Mar 06, 2017 at 10:54:44AM +0100, Oliver Neukum wrote:
> > > Yes, it would be wrong to see this as an attribute per driver.
> > > It needs to apply when you match. AFAICS every serial subdriver
> > > has a device table. Requirements need to go there.
> >
> > Every USB-serial-bus driver has a device table, but devices are
> > matched against these tables by USB-serial core and not USB core.
> > And then
>
> Are you refering to
>
> static struct usb_serial_driver * const serial_drivers[] = {
> &whiteheat_fake_device, &whiteheat_device, NULL
> };
>
> versus
>
> static const struct usb_device_id id_table_combined[] = {
> { USB_DEVICE(CONNECT_TECH_VENDOR_ID,
> CONNECT_TECH_WHITE_HEAT_ID) },
> { USB_DEVICE(CONNECT_TECH_VENDOR_ID,
> CONNECT_TECH_FAKE_WHITE_HEAT_ID) },
> { } /* Terminating
> entry */
> };
>
> I was taking about the latter. As far as I can tell it goes to usbcore.
Yes, but since the latter combines the two classes of devices, each
which may have different endpoint requirements, you'd instead have to
encode the requirements in each and every USB_DEVICE entry rather than
once in every struct usb_serial_driver.
> > there's also a "combined" device table, for all USB-serial bus
> > drivers implemented by the same USB interface driver.
> >
> > Are you suggesting the requirements should be specified per device,
> > rather than per driver (device table)? That does not seem right to
> > me, as it is really the driver which needs to verify the resources
> > it needs for its implementation (e.g. before allocating a read urb).
> > This means that all devices in a table would have the same (minimum)
> > constraints anyway.
>
> No. A driver may be fine with 2 input and 2 output bulk endpoints
> or 4 of both kinds but nothing in between.
> The core can do that match if you have matching entries for
> both device types (and IDs).
So this would be represented by two struct usb_serial_driver in my
scheme, but you instead suggest doing this on a device-id level, and also
put multiple entries in for every device-id when more than one endpoint
configuration is supported (with the same id).
This seems like a lot of work, especially when all devices handled by a
driver have the same constraints, or if the (constraint) classes instead
can, as in the USB serial case, be represented by a subdriver type (e.g.
struct usb_serial_driver) and looked-up from the device id.
> > So I do think this should be a driver attribute, but in the USB-
> > serial case, several classes of devices can be handled by the same
> > USB driver, so the constraints then needs to be specified at the
> > USB-serial-bus driver level instead.
>
> And that driver would save even more logic if the core already told it
> for which pattern it matches.
True, but my aim here is primarily to make it easier to add the
too-often forgotten but still required sanity checks. In the USB-serial
case, matching on device id is basically sufficient to be able to
identify the device classes.
It also seems what you're proposing would require exact rather than
minimum constraints to identify the classes. I fear there are just too
many variants of devices out there for this too be practical, and
I suspect neither is the exact configuration of the 7.5k USB device-id
entries we already have today known. Minimum constraints could be
derived from the code and specified per struct usb_driver though.
Core providing the endpoint type counts and descriptors per type would
still allow for much logic to be removed also in your 2+2 or 4+4 bulk
endpoints with same device-id case.
> > > Yes, but could you explain how this is connected to filtering at
> > > probe time other than happening at probe time?
> >
> > Only in that this functionality will still be needed in USB-serial
> > to implement the port-endpoint remap functionality even if USB core
> > were to gain something similar.
>
> But why do remap and filtering need to go to the same place?
They don't, USB core could do a basic sanity check, and USB-serial allow
for the remapping. The point is that USB-serial requires larger arrays
(MAX_NUM_PORTS = 16) for the remapping, than what a generic
implementation does (15), so we'd still need to construct the arrays in
USB serial.
But that is just to cover two drivers that could be dealt with
differently if needed to enable a generic implementation of this.
> > > True, but again not specific to serial drivers. DVB-T will face
> > > the same issues.
> >
> > Certainly, and I should have elaborated a bit more on the
> > differences here. For USB-serial endpoint-resources are allocated
> > only after subdriver probe returns, while for most (all) other USB
> > driver this would need to be done in the USB probe callback
> > directly. In that case, checking befo
Re: [PATCH 1/4 linux-next] usb: gadget: udc: atmel: Check fifo configuration values against device tree
cristian.bir...@microchip.com writes:
> From: Cristian Birsan
>
> Check fifo configuration values against device tree values for endpoint
> fifo in auto configuration mode (fifo_mode=0).
>
> Signed-off-by: Cristian Birsan
> ---
> drivers/usb/gadget/udc/atmel_usba_udc.c | 26 +++---
> 1 file changed, 23 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.c
> b/drivers/usb/gadget/udc/atmel_usba_udc.c
> index 11bbce2..ce8bf8b 100644
> --- a/drivers/usb/gadget/udc/atmel_usba_udc.c
> +++ b/drivers/usb/gadget/udc/atmel_usba_udc.c
> @@ -371,7 +371,7 @@ static struct usba_fifo_cfg mode_4_cfg[] = {
> };
> /* Add additional configurations here */
>
> -int usba_config_fifo_table(struct usba_udc *udc)
> +static int usba_config_fifo_table(struct usba_udc *udc)
this is not part of $subject. Should be a separate patch. Please fix.
--
balbi
signature.asc
Description: PGP signature
Re: [PATCH 00/21] USB: serial: refactor endpoint sanity checks
Am Montag, den 06.03.2017, 12:27 +0100 schrieb Johan Hovold:
> On Mon, Mar 06, 2017 at 10:54:44AM +0100, Oliver Neukum wrote:
> >
> >
> > Yes, it would be wrong to see this as an attribute per driver.
> > It needs to apply when you match. AFAICS every serial subdriver
> > has a device table. Requirements need to go there.
>
> Every USB-serial-bus driver has a device table, but devices are
> matched
> against these tables by USB-serial core and not USB core. And then
Are you refering to
static struct usb_serial_driver * const serial_drivers[] = {
&whiteheat_fake_device, &whiteheat_device, NULL
};
versus
static const struct usb_device_id id_table_combined[] = {
{ USB_DEVICE(CONNECT_TECH_VENDOR_ID,
CONNECT_TECH_WHITE_HEAT_ID) },
{ USB_DEVICE(CONNECT_TECH_VENDOR_ID,
CONNECT_TECH_FAKE_WHITE_HEAT_ID) },
{ } /* Terminating
entry */
};
I was taking about the latter. As far as I can tell it goes to usbcore.
> there's also a "combined" device table, for all USB-serial bus
> drivers
> implemented by the same USB interface driver.
>
> Are you suggesting the requirements should be specified per device,
> rather than per driver (device table)? That does not seem right to
> me,
> as it is really the driver which needs to verify the resources it
> needs
> for its implementation (e.g. before allocating a read urb). This
> means
> that all devices in a table would have the same (minimum) constraints
> anyway.
No. A driver may be fine with 2 input and 2 output bulk endpoints
or 4 of both kinds but nothing in between.
The core can do that match if you have matching entries for
both device types (and IDs).
> So I do think this should be a driver attribute, but in the USB-
> serial
> case, several classes of devices can be handled by the same USB
> driver,
> so the constraints then needs to be specified at the USB-serial-bus
> driver level instead.
And that driver would save even more logic if the core already told it
for which pattern it matches.
> > Yes, but could you explain how this is connected to filtering at
> > probe
> > time other than happening at probe time?
>
> Only in that this functionality will still be needed in USB-serial to
> implement the port-endpoint remap functionality even if USB core were
> to
> gain something similar.
But why do remap and filtering need to go to the same place?
> > True, but again not specific to serial drivers. DVB-T will face
> > the same issues.
>
> Certainly, and I should have elaborated a bit more on the differences
> here. For USB-serial endpoint-resources are allocated only after
> subdriver probe returns, while for most (all) other USB driver this
> would need to be done in the USB probe callback directly. In that
> case,
> checking before probe might be too soon (fw download, altsetting) and
> checking after would be too late (endpoint resources would already
> need
> to have been setup).
Now that argues for usbserial to trigger the check itself, but not for
the code doing the check living in usbserial. In other words put
struct usb_serial_endpoints and find_endpoints into usbcore and
call it from usbserial. Add a flag to tell usbcore to not check
this by itself and you are done. (With some generic name changes)
That way everybody can use it almost for free.
> I realise that it may look like a duplicated effort, but I really
> don't
> think it is for the reasons given in this thread.
IMHO the reasons are valid but they can be overcome resulting in more
code being shared.
Regards
Oliver
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] usb: dwc2: pci: Fix error handling in dwc2_pci_probe
Hi, Vardan Mikayelyan writes: > Move usb_phy_generic_register() function call to the top, to simplify > error handling. > > Replace kzalloc() with devm_kzalloc(). > > After platform_device_add(), if we error out, we must do > platform_device_unregister(), which also does the put. So lets move > devm_kzalloc() to simplify error handling and avoid > calling of platform_device_unregister(). > > Reviewed-by: Wei Yongjun > Signed-off-by: Vardan Mikayelyan this patch does more than one thing. I can't apply like that, sorry. I can see three unrelated changes going on here, please split the patch and resend. -- balbi signature.asc Description: PGP signature
Re: Panic in quirk_usb_early_handoff
On 06/03/2017 15:30, Robin Murphy wrote:
> On 06/03/17 12:42, Mason wrote:
>
>> $ arm-linux-gnueabihf-addr2line -i -e vmlinux c039fe44
>> arch/arm/include/asm/io.h:119
>>
>> In other words, readl()
>> Not as helpful as expected...
>
> I guess your toolchain isn't generating whatever debug info that -i uses
> to show where it was actually inlined, shame.
I used gcc-linaro-5.3.1-2016.05-x86_64_arm-linux-gnueabihf
Is that too old?
Might the issue come from my kernel config?
#
# Compile-time checks and compiler options
#
CONFIG_DEBUG_INFO=y
CONFIG_DEBUG_INFO_REDUCED=y
CONFIG_DEBUG_INFO_SPLIT=y
# CONFIG_DEBUG_INFO_DWARF4 is not set
# CONFIG_GDB_SCRIPTS is not set
CONFIG_ENABLE_WARN_DEPRECATED=y
CONFIG_ENABLE_MUST_CHECK=y
CONFIG_FRAME_WARN=1024
# CONFIG_STRIP_ASM_SYMS is not set
# CONFIG_READABLE_ASM is not set
# CONFIG_UNUSED_SYMBOLS is not set
# CONFIG_PAGE_OWNER is not set
# CONFIG_DEBUG_FS is not set
# CONFIG_HEADERS_CHECK is not set
# CONFIG_DEBUG_SECTION_MISMATCH is not set
CONFIG_SECTION_MISMATCH_WARN_ONLY=y
# CONFIG_DEBUG_FORCE_WEAK_PER_CPU is not set
# CONFIG_MAGIC_SYSRQ is not set
CONFIG_DEBUG_KERNEL=y
> Put together, if I'm skimming unfamiliar XHCI code and docs correctly,
> this would imply that a supposed read of the HCC Parameters register
> claimed that the extended capabilities register was at offset 0x29f8
> into a 0x2000-long BAR. That does suggest that whatever's being accessed
> through that ioremap() isn't actually the contents of BAR 0 at all (said
> field should apparently read as 0x140 representing an offset of 0x500).
> You're not still trying have your PCI host controller place its
> MEM-space window over the top of system RAM, are you? Otherwise, I'd be
> inclined to double check that your config space accesses and resource
> assignment are producing sane values.
It looks like the current PCI framework doesn't expect platforms to
multiplex config space and MEM space :-(
[0.994011] OF: PCI: host bridge /soc/pcie@5000 ranges:
[0.999721] OF: PCI: Parsing ranges property...
[1.004386] OF: PCI: MEM 0x5000..0x5fff -> 0x
[1.010471] pci-host-generic 5000.pcie:
can't claim ECAM area [mem 0x5000-0x5fff]:
address conflict with /soc/pcie@5000 [mem
0x5000-0x5fff]
[1.025265] pci-host-generic: probe of 5000.pcie failed with error -16
pcie@5000 {
compatible = "pci-host-ecam-generic";
reg = <0x5000 0x1000>;
device_type = "pci";
#size-cells = <2>;
#address-cells = <3>;
#interrupt-cells = <1>;
ranges = <0x0200 0x0 0x0 0x5000 0x0
0x1000>;
};
Regards.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 00/14] usb: dwc2: Add hibernation feature support.
Hi, Vardan Mikayelyan writes: > The functions with name hibernation are misnamed originally. They were only > responsible for partial power down and not for hibernation. > > This patch set adds the real hibernation support for dwc2 driver and renames > existing functions to power_down.xisting functions to power_down. just as a note, make sure to send your patch series as a thread (see git help send-email for details) -- balbi signature.asc Description: PGP signature
[PATCH v2] usb: musb: cppi41: don't check early-TX-interrupt for Isoch transfer
The CPPI 4.1 driver polls register to workaround the premature TX
interrupt issue, but it causes audio playback underrun when triggered in
Isoch transfers.
Isoch doesn't do back-to-back transfers, the TX should be done by the
time the next transfer is scheduled. So skip this polling workaround for
Isoch transfer.
Fixes: a655f481d83d6 ("usb: musb: musb_cppi41: handle pre-mature TX complete
interrupt")
Cc: #4.1+
Reported-by: Alexandre Bailon
Acked-by: Sebastian Andrzej Siewior
Tested-by: Alexandre Bailon
Signed-off-by: Bin Liu
---
v2: fix typo in commit comments.
drivers/usb/musb/musb_cppi41.c | 23 +--
1 file changed, 21 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/musb/musb_cppi41.c b/drivers/usb/musb/musb_cppi41.c
index 00e272bfee39..355655f8a3fb 100644
--- a/drivers/usb/musb/musb_cppi41.c
+++ b/drivers/usb/musb/musb_cppi41.c
@@ -238,8 +238,27 @@ static void cppi41_dma_callback(void *private_data,
transferred < cppi41_channel->packet_sz)
cppi41_channel->prog_len = 0;
- if (cppi41_channel->is_tx)
- empty = musb_is_tx_fifo_empty(hw_ep);
+ if (cppi41_channel->is_tx) {
+ u8 type;
+
+ if (is_host_active(musb))
+ type = hw_ep->out_qh->type;
+ else
+ type = hw_ep->ep_in.type;
+
+ if (type == USB_ENDPOINT_XFER_ISOC)
+ /*
+* Don't use the early-TX-interrupt workaround below
+* for Isoch transfter. Since Isoch are periodic
+* transfer, by the time the next transfer is
+* scheduled, the current one should be done already.
+*
+* This avoids audio playback underrun issue.
+*/
+ empty = true;
+ else
+ empty = musb_is_tx_fifo_empty(hw_ep);
+ }
if (!cppi41_channel->is_tx || empty) {
cppi41_trans_done(cppi41_channel);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3] usb: add CONFIG_USB_PCI for system have both PCI HW and non-PCI based USB HW
Hi, yuan linyu writes: > From: yuan linyu > > a lot of embeded system SOC (e.g. freescale T2080) have both > PCI and USB modules. But USB module is controlled by registers directly, > it have no relationship with PCI module. > > when say N here it will not build PCI related code in USB driver. > > Signed-off-by: yuan linyu I have no problems with this, just worried about how we should merge it. Greg, will you take this directly? If so: Acked-by: Felipe Balbi -- balbi signature.asc Description: PGP signature
Re: [PATCH v3 17/20] usb: gadget: pch_udc: Replace PCI pool old API
Peter Senna Tschudin writes: > On Sun, Feb 26, 2017 at 08:24:22PM +0100, Romain Perier wrote: >> The PCI pool API is deprecated. This commits replaces the PCI pool old >> API by the appropriated function with the DMA pool API. >> > Reviewed-by: Peter Senna Tschudin Fine by me: Acked-by: Felipe Balbi -- balbi signature.asc Description: PGP signature
[PATCH 20/29] drivers, s390: convert qeth_reply.refcnt from atomic_t to refcount_t
refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.
Signed-off-by: Elena Reshetova
Signed-off-by: Hans Liljestrand
Signed-off-by: Kees Cook
Signed-off-by: David Windsor
---
drivers/s390/net/qeth_core.h | 3 ++-
drivers/s390/net/qeth_core_main.c | 8 +++-
2 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/s390/net/qeth_core.h b/drivers/s390/net/qeth_core.h
index e7addea..e2c81d21 100644
--- a/drivers/s390/net/qeth_core.h
+++ b/drivers/s390/net/qeth_core.h
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
#include
@@ -641,7 +642,7 @@ struct qeth_reply {
int rc;
void *param;
struct qeth_card *card;
- atomic_t refcnt;
+ refcount_t refcnt;
};
diff --git a/drivers/s390/net/qeth_core_main.c
b/drivers/s390/net/qeth_core_main.c
index 315d8a2..a2bf13f 100644
--- a/drivers/s390/net/qeth_core_main.c
+++ b/drivers/s390/net/qeth_core_main.c
@@ -555,7 +555,7 @@ static struct qeth_reply *qeth_alloc_reply(struct qeth_card
*card)
reply = kzalloc(sizeof(struct qeth_reply), GFP_ATOMIC);
if (reply) {
- atomic_set(&reply->refcnt, 1);
+ refcount_set(&reply->refcnt, 1);
atomic_set(&reply->received, 0);
reply->card = card;
}
@@ -564,14 +564,12 @@ static struct qeth_reply *qeth_alloc_reply(struct
qeth_card *card)
static void qeth_get_reply(struct qeth_reply *reply)
{
- WARN_ON(atomic_read(&reply->refcnt) <= 0);
- atomic_inc(&reply->refcnt);
+ refcount_inc(&reply->refcnt);
}
static void qeth_put_reply(struct qeth_reply *reply)
{
- WARN_ON(atomic_read(&reply->refcnt) <= 0);
- if (atomic_dec_and_test(&reply->refcnt))
+ if (refcount_dec_and_test(&reply->refcnt))
kfree(reply);
}
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 18/29] drivers, s390: convert urdev.ref_count from atomic_t to refcount_t
refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.
Signed-off-by: Elena Reshetova
Signed-off-by: Hans Liljestrand
Signed-off-by: Kees Cook
Signed-off-by: David Windsor
---
drivers/s390/char/vmur.c | 8
drivers/s390/char/vmur.h | 4 +++-
2 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/s390/char/vmur.c b/drivers/s390/char/vmur.c
index 04aceb6..ced8151 100644
--- a/drivers/s390/char/vmur.c
+++ b/drivers/s390/char/vmur.c
@@ -110,7 +110,7 @@ static struct urdev *urdev_alloc(struct ccw_device *cdev)
mutex_init(&urd->io_mutex);
init_waitqueue_head(&urd->wait);
spin_lock_init(&urd->open_lock);
- atomic_set(&urd->ref_count, 1);
+ refcount_set(&urd->ref_count, 1);
urd->cdev = cdev;
get_device(&cdev->dev);
return urd;
@@ -126,7 +126,7 @@ static void urdev_free(struct urdev *urd)
static void urdev_get(struct urdev *urd)
{
- atomic_inc(&urd->ref_count);
+ refcount_inc(&urd->ref_count);
}
static struct urdev *urdev_get_from_cdev(struct ccw_device *cdev)
@@ -159,7 +159,7 @@ static struct urdev *urdev_get_from_devno(u16 devno)
static void urdev_put(struct urdev *urd)
{
- if (atomic_dec_and_test(&urd->ref_count))
+ if (refcount_dec_and_test(&urd->ref_count))
urdev_free(urd);
}
@@ -946,7 +946,7 @@ static int ur_set_offline_force(struct ccw_device *cdev,
int force)
rc = -EBUSY;
goto fail_urdev_put;
}
- if (!force && (atomic_read(&urd->ref_count) > 2)) {
+ if (!force && (refcount_read(&urd->ref_count) > 2)) {
/* There is still a user of urd (e.g. ur_open) */
TRACE("ur_set_offline: BUSY\n");
rc = -EBUSY;
diff --git a/drivers/s390/char/vmur.h b/drivers/s390/char/vmur.h
index fa320ad..35ea9d1 100644
--- a/drivers/s390/char/vmur.h
+++ b/drivers/s390/char/vmur.h
@@ -11,6 +11,8 @@
#ifndef _VMUR_H_
#define _VMUR_H_
+#include
+
#define DEV_CLASS_UR_I 0x20 /* diag210 unit record input device class */
#define DEV_CLASS_UR_O 0x10 /* diag210 unit record output device class */
/*
@@ -69,7 +71,7 @@ struct urdev {
size_t reclen; /* Record length for *write* CCWs */
int class; /* VM device class */
int io_request_rc; /* return code from I/O request */
- atomic_t ref_count; /* reference counter */
+ refcount_t ref_count; /* reference counter */
wait_queue_head_t wait; /* wait queue to serialize open */
int open_flag; /* "urdev is open" flag */
spinlock_t open_lock; /* serialize critical sections */
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: query on UCSI
Hi, On Mon, Mar 06, 2017 at 02:41:17PM +0530, Shah, Nehal-bakulchandra wrote: > Hi Greg and Heikki, > > > I can see that ucsi acpi interface driver is available in kernel tree. I have > following queries on the same. Kindly pardon my ignorance as i am a novice to > this. > > - Is there any implementation of USB-C system policy manager (OPM) in Linux? I think the question here is do we have an implementation for OPM (OS Policy Manager) which would be in practice the driver we have for UCSI in Linux kernel. System policy manager is implemented in BIOS and/or EC FW with UCSI (check Figure 2-1 in bios-implementation-of-ucsi.pdf). > - If yes to USB-C system policy, are there any requirements that differ from > the published Intel White paper on UCSI support through ACPI Mailbox method? > (Link: > http://www.intel.com/content/dam/www/public/us/en/documents/white-papers/bios-implementation-of-ucsi.pdf > ) No other requirements. Br, -- heikki -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 25/29] drivers, usb: convert ffs_data.ref from atomic_t to refcount_t
refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.
Signed-off-by: Elena Reshetova
Signed-off-by: Hans Liljestrand
Signed-off-by: Kees Cook
Signed-off-by: David Windsor
---
drivers/usb/gadget/function/f_fs.c | 8
drivers/usb/gadget/function/u_fs.h | 3 ++-
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/gadget/function/f_fs.c
b/drivers/usb/gadget/function/f_fs.c
index 87fccf6..3cdeb91 100644
--- a/drivers/usb/gadget/function/f_fs.c
+++ b/drivers/usb/gadget/function/f_fs.c
@@ -1570,14 +1570,14 @@ static void ffs_data_get(struct ffs_data *ffs)
{
ENTER();
- atomic_inc(&ffs->ref);
+ refcount_inc(&ffs->ref);
}
static void ffs_data_opened(struct ffs_data *ffs)
{
ENTER();
- atomic_inc(&ffs->ref);
+ refcount_inc(&ffs->ref);
if (atomic_add_return(1, &ffs->opened) == 1 &&
ffs->state == FFS_DEACTIVATED) {
ffs->state = FFS_CLOSING;
@@ -1589,7 +1589,7 @@ static void ffs_data_put(struct ffs_data *ffs)
{
ENTER();
- if (unlikely(atomic_dec_and_test(&ffs->ref))) {
+ if (unlikely(refcount_dec_and_test(&ffs->ref))) {
pr_info("%s(): freeing\n", __func__);
ffs_data_clear(ffs);
BUG_ON(waitqueue_active(&ffs->ev.waitq) ||
@@ -1634,7 +1634,7 @@ static struct ffs_data *ffs_data_new(void)
ENTER();
- atomic_set(&ffs->ref, 1);
+ refcount_set(&ffs->ref, 1);
atomic_set(&ffs->opened, 0);
ffs->state = FFS_READ_DESCRIPTORS;
mutex_init(&ffs->mutex);
diff --git a/drivers/usb/gadget/function/u_fs.h
b/drivers/usb/gadget/function/u_fs.h
index 4b69694..abfca48 100644
--- a/drivers/usb/gadget/function/u_fs.h
+++ b/drivers/usb/gadget/function/u_fs.h
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#ifdef VERBOSE_DEBUG
#ifndef pr_vdebug
@@ -177,7 +178,7 @@ struct ffs_data {
struct completion ep0req_completion; /* P: mutex */
/* reference counter */
- atomic_tref;
+ refcount_t ref;
/* how many files are opened (EP0 and others) */
atomic_topened;
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 09/29] drivers, md: convert table_device.count from atomic_t to refcount_t
refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.
Signed-off-by: Elena Reshetova
Signed-off-by: Hans Liljestrand
Signed-off-by: Kees Cook
Signed-off-by: David Windsor
---
drivers/md/dm.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/md/dm.c b/drivers/md/dm.c
index 9f37d7f..cba91c3 100644
--- a/drivers/md/dm.c
+++ b/drivers/md/dm.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#define DM_MSG_PREFIX "core"
@@ -96,7 +97,7 @@ struct dm_md_mempools {
struct table_device {
struct list_head list;
- atomic_t count;
+ refcount_t count;
struct dm_dev dm_dev;
};
@@ -680,10 +681,11 @@ int dm_get_table_device(struct mapped_device *md, dev_t
dev, fmode_t mode,
format_dev_t(td->dm_dev.name, dev);
- atomic_set(&td->count, 0);
+ refcount_set(&td->count, 1);
list_add(&td->list, &md->table_devices);
+ } else {
+ refcount_inc(&td->count);
}
- atomic_inc(&td->count);
mutex_unlock(&md->table_devices_lock);
*result = &td->dm_dev;
@@ -696,7 +698,7 @@ void dm_put_table_device(struct mapped_device *md, struct
dm_dev *d)
struct table_device *td = container_of(d, struct table_device, dm_dev);
mutex_lock(&md->table_devices_lock);
- if (atomic_dec_and_test(&td->count)) {
+ if (refcount_dec_and_test(&td->count)) {
close_table_device(td, md);
list_del(&td->list);
kfree(td);
@@ -713,7 +715,7 @@ static void free_table_devices(struct list_head *devices)
struct table_device *td = list_entry(tmp, struct table_device,
list);
DMWARN("dm_destroy: %s still exists with %d references",
- td->dm_dev.name, atomic_read(&td->count));
+ td->dm_dev.name, refcount_read(&td->count));
kfree(td);
}
}
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/29] drivers, block: convert xen_blkif.refcnt from atomic_t to refcount_t
refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.
Signed-off-by: Elena Reshetova
Signed-off-by: Hans Liljestrand
Signed-off-by: Kees Cook
Signed-off-by: David Windsor
---
drivers/block/xen-blkback/common.h | 7 ---
drivers/block/xen-blkback/xenbus.c | 2 +-
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/block/xen-blkback/common.h
b/drivers/block/xen-blkback/common.h
index dea61f6..2ccfd62 100644
--- a/drivers/block/xen-blkback/common.h
+++ b/drivers/block/xen-blkback/common.h
@@ -35,6 +35,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -333,7 +334,7 @@ struct xen_blkif {
struct xen_vbd vbd;
/* Back pointer to the backend_info. */
struct backend_info *be;
- atomic_trefcnt;
+ refcount_t refcnt;
/* for barrier (drain) requests */
struct completion drain_complete;
atomic_tdrain;
@@ -386,10 +387,10 @@ struct pending_req {
(_v)->bdev->bd_part->nr_sects : \
get_capacity((_v)->bdev->bd_disk))
-#define xen_blkif_get(_b) (atomic_inc(&(_b)->refcnt))
+#define xen_blkif_get(_b) (refcount_inc(&(_b)->refcnt))
#define xen_blkif_put(_b) \
do {\
- if (atomic_dec_and_test(&(_b)->refcnt)) \
+ if (refcount_dec_and_test(&(_b)->refcnt)) \
schedule_work(&(_b)->free_work);\
} while (0)
diff --git a/drivers/block/xen-blkback/xenbus.c
b/drivers/block/xen-blkback/xenbus.c
index 8fe61b5..9f89be3 100644
--- a/drivers/block/xen-blkback/xenbus.c
+++ b/drivers/block/xen-blkback/xenbus.c
@@ -176,7 +176,7 @@ static struct xen_blkif *xen_blkif_alloc(domid_t domid)
return ERR_PTR(-ENOMEM);
blkif->domid = domid;
- atomic_set(&blkif->refcnt, 1);
+ refcount_set(&blkif->refcnt, 1);
init_completion(&blkif->drain_complete);
INIT_WORK(&blkif->free_work, xen_blkif_deferred_free);
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 21/29] drivers, s390: convert fc_fcp_pkt.ref_cnt from atomic_t to refcount_t
refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.
Signed-off-by: Elena Reshetova
Signed-off-by: Hans Liljestrand
Signed-off-by: Kees Cook
Signed-off-by: David Windsor
---
drivers/scsi/libfc/fc_fcp.c | 6 +++---
include/scsi/libfc.h| 3 ++-
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/scsi/libfc/fc_fcp.c b/drivers/scsi/libfc/fc_fcp.c
index 0e67621..a808e8e 100644
--- a/drivers/scsi/libfc/fc_fcp.c
+++ b/drivers/scsi/libfc/fc_fcp.c
@@ -154,7 +154,7 @@ static struct fc_fcp_pkt *fc_fcp_pkt_alloc(struct fc_lport
*lport, gfp_t gfp)
memset(fsp, 0, sizeof(*fsp));
fsp->lp = lport;
fsp->xfer_ddp = FC_XID_UNKNOWN;
- atomic_set(&fsp->ref_cnt, 1);
+ refcount_set(&fsp->ref_cnt, 1);
init_timer(&fsp->timer);
fsp->timer.data = (unsigned long)fsp;
INIT_LIST_HEAD(&fsp->list);
@@ -175,7 +175,7 @@ static struct fc_fcp_pkt *fc_fcp_pkt_alloc(struct fc_lport
*lport, gfp_t gfp)
*/
static void fc_fcp_pkt_release(struct fc_fcp_pkt *fsp)
{
- if (atomic_dec_and_test(&fsp->ref_cnt)) {
+ if (refcount_dec_and_test(&fsp->ref_cnt)) {
struct fc_fcp_internal *si = fc_get_scsi_internal(fsp->lp);
mempool_free(fsp, si->scsi_pkt_pool);
@@ -188,7 +188,7 @@ static void fc_fcp_pkt_release(struct fc_fcp_pkt *fsp)
*/
static void fc_fcp_pkt_hold(struct fc_fcp_pkt *fsp)
{
- atomic_inc(&fsp->ref_cnt);
+ refcount_inc(&fsp->ref_cnt);
}
/**
diff --git a/include/scsi/libfc.h b/include/scsi/libfc.h
index da5033d..2109844 100644
--- a/include/scsi/libfc.h
+++ b/include/scsi/libfc.h
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include
#include
@@ -321,7 +322,7 @@ struct fc_seq_els_data {
*/
struct fc_fcp_pkt {
spinlock_tscsi_pkt_lock;
- atomic_t ref_cnt;
+ refcount_tref_cnt;
/* SCSI command and data transfer information */
u32 data_len;
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 19/29] drivers, s390: convert lcs_reply.refcnt from atomic_t to refcount_t
refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.
Signed-off-by: Elena Reshetova
Signed-off-by: Hans Liljestrand
Signed-off-by: Kees Cook
Signed-off-by: David Windsor
---
drivers/s390/net/lcs.c | 8 +++-
drivers/s390/net/lcs.h | 3 ++-
2 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/s390/net/lcs.c b/drivers/s390/net/lcs.c
index 211b31d..18dc787 100644
--- a/drivers/s390/net/lcs.c
+++ b/drivers/s390/net/lcs.c
@@ -774,15 +774,13 @@ lcs_get_lancmd(struct lcs_card *card, int count)
static void
lcs_get_reply(struct lcs_reply *reply)
{
- WARN_ON(atomic_read(&reply->refcnt) <= 0);
- atomic_inc(&reply->refcnt);
+ refcount_inc(&reply->refcnt);
}
static void
lcs_put_reply(struct lcs_reply *reply)
{
-WARN_ON(atomic_read(&reply->refcnt) <= 0);
-if (atomic_dec_and_test(&reply->refcnt)) {
+if (refcount_dec_and_test(&reply->refcnt)) {
kfree(reply);
}
@@ -798,7 +796,7 @@ lcs_alloc_reply(struct lcs_cmd *cmd)
reply = kzalloc(sizeof(struct lcs_reply), GFP_ATOMIC);
if (!reply)
return NULL;
- atomic_set(&reply->refcnt,1);
+ refcount_set(&reply->refcnt,1);
reply->sequence_no = cmd->sequence_no;
reply->received = 0;
reply->rc = 0;
diff --git a/drivers/s390/net/lcs.h b/drivers/s390/net/lcs.h
index 150fcb4..3802f4f 100644
--- a/drivers/s390/net/lcs.h
+++ b/drivers/s390/net/lcs.h
@@ -4,6 +4,7 @@
#include
#include
#include
+#include
#include
#define LCS_DBF_TEXT(level, name, text) \
@@ -270,7 +271,7 @@ struct lcs_buffer {
struct lcs_reply {
struct list_head list;
__u16 sequence_no;
- atomic_t refcnt;
+ refcount_t refcnt;
/* Callback for completion notification. */
void (*callback)(struct lcs_card *, struct lcs_cmd *);
wait_queue_head_t wait_q;
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 15/29] drivers, media: convert vb2_dma_sg_buf.refcount from atomic_t to refcount_t
refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.
Signed-off-by: Elena Reshetova
Signed-off-by: Hans Liljestrand
Signed-off-by: Kees Cook
Signed-off-by: David Windsor
---
drivers/media/v4l2-core/videobuf2-dma-sg.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf2-dma-sg.c
b/drivers/media/v4l2-core/videobuf2-dma-sg.c
index ecff8f4..29fde1a 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-sg.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-sg.c
@@ -12,6 +12,7 @@
#include
#include
+#include
#include
#include
#include
@@ -46,7 +47,7 @@ struct vb2_dma_sg_buf {
struct sg_table *dma_sgt;
size_t size;
unsigned intnum_pages;
- atomic_trefcount;
+ refcount_t refcount;
struct vb2_vmarea_handler handler;
struct dma_buf_attachment *db_attach;
@@ -150,7 +151,7 @@ static void *vb2_dma_sg_alloc(struct device *dev, unsigned
long dma_attrs,
buf->handler.put = vb2_dma_sg_put;
buf->handler.arg = buf;
- atomic_inc(&buf->refcount);
+ refcount_set(&buf->refcount, 1);
dprintk(1, "%s: Allocated buffer of %d pages\n",
__func__, buf->num_pages);
@@ -176,7 +177,7 @@ static void vb2_dma_sg_put(void *buf_priv)
struct sg_table *sgt = &buf->sg_table;
int i = buf->num_pages;
- if (atomic_dec_and_test(&buf->refcount)) {
+ if (refcount_dec_and_test(&buf->refcount)) {
dprintk(1, "%s: Freeing buffer of %d pages\n", __func__,
buf->num_pages);
dma_unmap_sg_attrs(buf->dev, sgt->sgl, sgt->orig_nents,
@@ -320,7 +321,7 @@ static unsigned int vb2_dma_sg_num_users(void *buf_priv)
{
struct vb2_dma_sg_buf *buf = buf_priv;
- return atomic_read(&buf->refcount);
+ return refcount_read(&buf->refcount);
}
static int vb2_dma_sg_mmap(void *buf_priv, struct vm_area_struct *vma)
@@ -530,7 +531,7 @@ static struct dma_buf *vb2_dma_sg_get_dmabuf(void
*buf_priv, unsigned long flags
return NULL;
/* dmabuf keeps reference to vb2 buffer */
- atomic_inc(&buf->refcount);
+ refcount_inc(&buf->refcount);
return dbuf;
}
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 17/29] drivers, pci: convert hv_pci_dev.refs from atomic_t to refcount_t
refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.
Signed-off-by: Elena Reshetova
Signed-off-by: Hans Liljestrand
Signed-off-by: Kees Cook
Signed-off-by: David Windsor
---
drivers/pci/host/pci-hyperv.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/pci/host/pci-hyperv.c b/drivers/pci/host/pci-hyperv.c
index cd114c6..870deed 100644
--- a/drivers/pci/host/pci-hyperv.c
+++ b/drivers/pci/host/pci-hyperv.c
@@ -56,6 +56,7 @@
#include
#include
#include
+#include
#include
/*
@@ -421,7 +422,7 @@ enum hv_pcidev_ref_reason {
struct hv_pci_dev {
/* List protected by pci_rescan_remove_lock */
struct list_head list_entry;
- atomic_t refs;
+ refcount_t refs;
enum hv_pcichild_state state;
struct pci_function_description desc;
bool reported_missing;
@@ -1254,13 +1255,13 @@ static void q_resource_requirements(void *context,
struct pci_response *resp,
static void get_pcichild(struct hv_pci_dev *hpdev,
enum hv_pcidev_ref_reason reason)
{
- atomic_inc(&hpdev->refs);
+ refcount_inc(&hpdev->refs);
}
static void put_pcichild(struct hv_pci_dev *hpdev,
enum hv_pcidev_ref_reason reason)
{
- if (atomic_dec_and_test(&hpdev->refs))
+ if (refcount_dec_and_test(&hpdev->refs))
kfree(hpdev);
}
@@ -1314,7 +1315,7 @@ static struct hv_pci_dev *new_pcichild_device(struct
hv_pcibus_device *hbus,
wait_for_completion(&comp_pkt.host_event);
hpdev->desc = *desc;
- get_pcichild(hpdev, hv_pcidev_ref_initial);
+ refcount_set(&hpdev->refs, 1);
get_pcichild(hpdev, hv_pcidev_ref_childlist);
spin_lock_irqsave(&hbus->device_list_lock, flags);
list_add_tail(&hpdev->list_entry, &hbus->children);
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 27/29] drivers, usb: convert ep_data.count from atomic_t to refcount_t
refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.
Signed-off-by: Elena Reshetova
Signed-off-by: Hans Liljestrand
Signed-off-by: Kees Cook
Signed-off-by: David Windsor
---
drivers/usb/gadget/legacy/inode.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/gadget/legacy/inode.c
b/drivers/usb/gadget/legacy/inode.c
index 81d76f3..d21a5f8 100644
--- a/drivers/usb/gadget/legacy/inode.c
+++ b/drivers/usb/gadget/legacy/inode.c
@@ -191,7 +191,7 @@ enum ep_state {
struct ep_data {
struct mutexlock;
enum ep_state state;
- atomic_tcount;
+ refcount_t count;
struct dev_data *dev;
/* must hold dev->lock before accessing ep or req */
struct usb_ep *ep;
@@ -206,12 +206,12 @@ struct ep_data {
static inline void get_ep (struct ep_data *data)
{
- atomic_inc (&data->count);
+ refcount_inc (&data->count);
}
static void put_ep (struct ep_data *data)
{
- if (likely (!atomic_dec_and_test (&data->count)))
+ if (likely (!refcount_dec_and_test (&data->count)))
return;
put_dev (data->dev);
/* needs no more cleanup */
@@ -1562,7 +1562,7 @@ static int activate_ep_files (struct dev_data *dev)
init_waitqueue_head (&data->wait);
strncpy (data->name, ep->name, sizeof (data->name) - 1);
- atomic_set (&data->count, 1);
+ refcount_set (&data->count, 1);
data->dev = dev;
get_dev (dev);
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 23/29] drivers: convert vme_user_vma_priv.refcnt from atomic_t to refcount_t
refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.
Signed-off-by: Elena Reshetova
Signed-off-by: Hans Liljestrand
Signed-off-by: Kees Cook
Signed-off-by: David Windsor
---
drivers/staging/vme/devices/vme_user.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/vme/devices/vme_user.c
b/drivers/staging/vme/devices/vme_user.c
index 69e9a770..a3d4610 100644
--- a/drivers/staging/vme/devices/vme_user.c
+++ b/drivers/staging/vme/devices/vme_user.c
@@ -17,7 +17,7 @@
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
-#include
+#include
#include
#include
#include
@@ -118,7 +118,7 @@ static const int type[VME_DEVS] = { MASTER_MINOR,
MASTER_MINOR,
struct vme_user_vma_priv {
unsigned int minor;
- atomic_t refcnt;
+ refcount_t refcnt;
};
static ssize_t resource_to_user(int minor, char __user *buf, size_t count,
@@ -430,7 +430,7 @@ static void vme_user_vm_open(struct vm_area_struct *vma)
{
struct vme_user_vma_priv *vma_priv = vma->vm_private_data;
- atomic_inc(&vma_priv->refcnt);
+ refcount_inc(&vma_priv->refcnt);
}
static void vme_user_vm_close(struct vm_area_struct *vma)
@@ -438,7 +438,7 @@ static void vme_user_vm_close(struct vm_area_struct *vma)
struct vme_user_vma_priv *vma_priv = vma->vm_private_data;
unsigned int minor = vma_priv->minor;
- if (!atomic_dec_and_test(&vma_priv->refcnt))
+ if (!refcount_dec_and_test(&vma_priv->refcnt))
return;
mutex_lock(&image[minor].mutex);
@@ -473,7 +473,7 @@ static int vme_user_master_mmap(unsigned int minor, struct
vm_area_struct *vma)
}
vma_priv->minor = minor;
- atomic_set(&vma_priv->refcnt, 1);
+ refcount_set(&vma_priv->refcnt, 1);
vma->vm_ops = &vme_user_vm_ops;
vma->vm_private_data = vma_priv;
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 07/29] drivers, md: convert dm_dev_internal.count from atomic_t to refcount_t
refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.
Signed-off-by: Elena Reshetova
Signed-off-by: Hans Liljestrand
Signed-off-by: Kees Cook
Signed-off-by: David Windsor
---
drivers/md/dm-table.c | 6 +++---
drivers/md/dm.h | 3 ++-
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/md/dm-table.c b/drivers/md/dm-table.c
index 3ad16d9..d2e2741 100644
--- a/drivers/md/dm-table.c
+++ b/drivers/md/dm-table.c
@@ -416,15 +416,15 @@ int dm_get_device(struct dm_target *ti, const char *path,
fmode_t mode,
return r;
}
- atomic_set(&dd->count, 0);
+ refcount_set(&dd->count, 1);
list_add(&dd->list, &t->devices);
} else if (dd->dm_dev->mode != (mode | dd->dm_dev->mode)) {
r = upgrade_mode(dd, mode, t->md);
if (r)
return r;
+ refcount_inc(&dd->count);
}
- atomic_inc(&dd->count);
*result = dd->dm_dev;
return 0;
@@ -478,7 +478,7 @@ void dm_put_device(struct dm_target *ti, struct dm_dev *d)
dm_device_name(ti->table->md), d->name);
return;
}
- if (atomic_dec_and_test(&dd->count)) {
+ if (refcount_dec_and_test(&dd->count)) {
dm_put_table_device(ti->table->md, d);
list_del(&dd->list);
kfree(dd);
diff --git a/drivers/md/dm.h b/drivers/md/dm.h
index f298b01..63b8142 100644
--- a/drivers/md/dm.h
+++ b/drivers/md/dm.h
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include "dm-stats.h"
@@ -38,7 +39,7 @@
*/
struct dm_dev_internal {
struct list_head list;
- atomic_t count;
+ refcount_t count;
struct dm_dev *dm_dev;
};
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 29/29] drivers, xen: convert grant_map.users from atomic_t to refcount_t
refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.
Signed-off-by: Elena Reshetova
Signed-off-by: Hans Liljestrand
Signed-off-by: Kees Cook
Signed-off-by: David Windsor
---
drivers/xen/gntdev.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
index 2ef2b61..b183cb2 100644
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -35,6 +35,7 @@
#include
#include
#include
+#include
#include
#include
@@ -85,7 +86,7 @@ struct grant_map {
int index;
int count;
int flags;
- atomic_t users;
+ refcount_t users;
struct unmap_notify notify;
struct ioctl_gntdev_grant_ref *grants;
struct gnttab_map_grant_ref *map_ops;
@@ -165,7 +166,7 @@ static struct grant_map *gntdev_alloc_map(struct
gntdev_priv *priv, int count)
add->index = 0;
add->count = count;
- atomic_set(&add->users, 1);
+ refcount_set(&add->users, 1);
return add;
@@ -211,7 +212,7 @@ static void gntdev_put_map(struct gntdev_priv *priv, struct
grant_map *map)
if (!map)
return;
- if (!atomic_dec_and_test(&map->users))
+ if (!refcount_dec_and_test(&map->users))
return;
atomic_sub(map->count, &pages_mapped);
@@ -399,7 +400,7 @@ static void gntdev_vma_open(struct vm_area_struct *vma)
struct grant_map *map = vma->vm_private_data;
pr_debug("gntdev_vma_open %p\n", vma);
- atomic_inc(&map->users);
+ refcount_inc(&map->users);
}
static void gntdev_vma_close(struct vm_area_struct *vma)
@@ -1003,7 +1004,7 @@ static int gntdev_mmap(struct file *flip, struct
vm_area_struct *vma)
goto unlock_out;
}
- atomic_inc(&map->users);
+ refcount_inc(&map->users);
vma->vm_ops = &gntdev_vmops;
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 13/29] drivers, media: convert vb2_vmarea_handler.refcount from atomic_t to refcount_t
refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.
Signed-off-by: Elena Reshetova
Signed-off-by: Hans Liljestrand
Signed-off-by: Kees Cook
Signed-off-by: David Windsor
---
drivers/media/v4l2-core/videobuf2-memops.c | 6 +++---
include/media/videobuf2-memops.h | 3 ++-
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf2-memops.c
b/drivers/media/v4l2-core/videobuf2-memops.c
index 1cd322e..4bb8424 100644
--- a/drivers/media/v4l2-core/videobuf2-memops.c
+++ b/drivers/media/v4l2-core/videobuf2-memops.c
@@ -96,10 +96,10 @@ static void vb2_common_vm_open(struct vm_area_struct *vma)
struct vb2_vmarea_handler *h = vma->vm_private_data;
pr_debug("%s: %p, refcount: %d, vma: %08lx-%08lx\n",
- __func__, h, atomic_read(h->refcount), vma->vm_start,
+ __func__, h, refcount_read(h->refcount), vma->vm_start,
vma->vm_end);
- atomic_inc(h->refcount);
+ refcount_inc(h->refcount);
}
/**
@@ -114,7 +114,7 @@ static void vb2_common_vm_close(struct vm_area_struct *vma)
struct vb2_vmarea_handler *h = vma->vm_private_data;
pr_debug("%s: %p, refcount: %d, vma: %08lx-%08lx\n",
- __func__, h, atomic_read(h->refcount), vma->vm_start,
+ __func__, h, refcount_read(h->refcount), vma->vm_start,
vma->vm_end);
h->put(h->arg);
diff --git a/include/media/videobuf2-memops.h b/include/media/videobuf2-memops.h
index 36565c7a..a6ed091 100644
--- a/include/media/videobuf2-memops.h
+++ b/include/media/videobuf2-memops.h
@@ -16,6 +16,7 @@
#include
#include
+#include
/**
* struct vb2_vmarea_handler - common vma refcount tracking handler
@@ -25,7 +26,7 @@
* @arg: argument for @put callback
*/
struct vb2_vmarea_handler {
- atomic_t*refcount;
+ refcount_t *refcount;
void(*put)(void *arg);
void*arg;
};
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 16/29] drivers, media: convert vb2_vmalloc_buf.refcount from atomic_t to refcount_t
refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.
Signed-off-by: Elena Reshetova
Signed-off-by: Hans Liljestrand
Signed-off-by: Kees Cook
Signed-off-by: David Windsor
---
drivers/media/v4l2-core/videobuf2-vmalloc.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf2-vmalloc.c
b/drivers/media/v4l2-core/videobuf2-vmalloc.c
index 3f77814..f83253a 100644
--- a/drivers/media/v4l2-core/videobuf2-vmalloc.c
+++ b/drivers/media/v4l2-core/videobuf2-vmalloc.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -26,7 +27,7 @@ struct vb2_vmalloc_buf {
struct frame_vector *vec;
enum dma_data_direction dma_dir;
unsigned long size;
- atomic_trefcount;
+ refcount_t refcount;
struct vb2_vmarea_handler handler;
struct dma_buf *dbuf;
};
@@ -56,7 +57,7 @@ static void *vb2_vmalloc_alloc(struct device *dev, unsigned
long attrs,
return ERR_PTR(-ENOMEM);
}
- atomic_inc(&buf->refcount);
+ refcount_set(&buf->refcount, 1);
return buf;
}
@@ -64,7 +65,7 @@ static void vb2_vmalloc_put(void *buf_priv)
{
struct vb2_vmalloc_buf *buf = buf_priv;
- if (atomic_dec_and_test(&buf->refcount)) {
+ if (refcount_dec_and_test(&buf->refcount)) {
vfree(buf->vaddr);
kfree(buf);
}
@@ -161,7 +162,7 @@ static void *vb2_vmalloc_vaddr(void *buf_priv)
static unsigned int vb2_vmalloc_num_users(void *buf_priv)
{
struct vb2_vmalloc_buf *buf = buf_priv;
- return atomic_read(&buf->refcount);
+ return refcount_read(&buf->refcount);
}
static int vb2_vmalloc_mmap(void *buf_priv, struct vm_area_struct *vma)
@@ -368,7 +369,7 @@ static struct dma_buf *vb2_vmalloc_get_dmabuf(void
*buf_priv, unsigned long flag
return NULL;
/* dmabuf keeps reference to vb2 buffer */
- atomic_inc(&buf->refcount);
+ refcount_inc(&buf->refcount);
return dbuf;
}
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 14/29] drivers, media: convert vb2_dc_buf.refcount from atomic_t to refcount_t
refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.
Signed-off-by: Elena Reshetova
Signed-off-by: Hans Liljestrand
Signed-off-by: Kees Cook
Signed-off-by: David Windsor
---
drivers/media/v4l2-core/videobuf2-dma-contig.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c
b/drivers/media/v4l2-core/videobuf2-dma-contig.c
index fb6a177..d29a07f 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
@@ -12,6 +12,7 @@
#include
#include
+#include
#include
#include
#include
@@ -34,7 +35,7 @@ struct vb2_dc_buf {
/* MMAP related */
struct vb2_vmarea_handler handler;
- atomic_trefcount;
+ refcount_t refcount;
struct sg_table *sgt_base;
/* DMABUF related */
@@ -86,7 +87,7 @@ static unsigned int vb2_dc_num_users(void *buf_priv)
{
struct vb2_dc_buf *buf = buf_priv;
- return atomic_read(&buf->refcount);
+ return refcount_read(&buf->refcount);
}
static void vb2_dc_prepare(void *buf_priv)
@@ -122,7 +123,7 @@ static void vb2_dc_put(void *buf_priv)
{
struct vb2_dc_buf *buf = buf_priv;
- if (!atomic_dec_and_test(&buf->refcount))
+ if (!refcount_dec_and_test(&buf->refcount))
return;
if (buf->sgt_base) {
@@ -170,7 +171,7 @@ static void *vb2_dc_alloc(struct device *dev, unsigned long
attrs,
buf->handler.put = vb2_dc_put;
buf->handler.arg = buf;
- atomic_inc(&buf->refcount);
+ refcount_set(&buf->refcount, 1);
return buf;
}
@@ -407,7 +408,7 @@ static struct dma_buf *vb2_dc_get_dmabuf(void *buf_priv,
unsigned long flags)
return NULL;
/* dmabuf keeps reference to vb2 buffer */
- atomic_inc(&buf->refcount);
+ refcount_inc(&buf->refcount);
return dbuf;
}
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 04/29] drivers, connector: convert cn_callback_entry.refcnt from atomic_t to refcount_t
refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.
Signed-off-by: Elena Reshetova
Signed-off-by: Hans Liljestrand
Signed-off-by: Kees Cook
Signed-off-by: David Windsor
---
drivers/connector/cn_queue.c | 4 ++--
drivers/connector/connector.c | 2 +-
include/linux/connector.h | 4 ++--
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/connector/cn_queue.c b/drivers/connector/cn_queue.c
index 1f8bf05..9c54fdf 100644
--- a/drivers/connector/cn_queue.c
+++ b/drivers/connector/cn_queue.c
@@ -45,7 +45,7 @@ cn_queue_alloc_callback_entry(struct cn_queue_dev *dev, const
char *name,
return NULL;
}
- atomic_set(&cbq->refcnt, 1);
+ refcount_set(&cbq->refcnt, 1);
atomic_inc(&dev->refcnt);
cbq->pdev = dev;
@@ -58,7 +58,7 @@ cn_queue_alloc_callback_entry(struct cn_queue_dev *dev, const
char *name,
void cn_queue_release_callback(struct cn_callback_entry *cbq)
{
- if (!atomic_dec_and_test(&cbq->refcnt))
+ if (!refcount_dec_and_test(&cbq->refcnt))
return;
atomic_dec(&cbq->pdev->refcnt);
diff --git a/drivers/connector/connector.c b/drivers/connector/connector.c
index 25693b0..8615594b 100644
--- a/drivers/connector/connector.c
+++ b/drivers/connector/connector.c
@@ -157,7 +157,7 @@ static int cn_call_callback(struct sk_buff *skb)
spin_lock_bh(&dev->cbdev->queue_lock);
list_for_each_entry(i, &dev->cbdev->queue_list, callback_entry) {
if (cn_cb_equal(&i->id.id, &msg->id)) {
- atomic_inc(&i->refcnt);
+ refcount_inc(&i->refcnt);
cbq = i;
break;
}
diff --git a/include/linux/connector.h b/include/linux/connector.h
index f8fe863..032102b 100644
--- a/include/linux/connector.h
+++ b/include/linux/connector.h
@@ -22,7 +22,7 @@
#define __CONNECTOR_H
-#include
+#include
#include
#include
@@ -49,7 +49,7 @@ struct cn_callback_id {
struct cn_callback_entry {
struct list_head callback_entry;
- atomic_t refcnt;
+ refcount_t refcnt;
struct cn_queue_dev *pdev;
struct cn_callback_id id;
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Panic in quirk_usb_early_handoff
[+linux-pci, just in case] On 06/03/17 12:42, Mason wrote: > On 03/03/2017 20:02, Robin Murphy wrote: > >> On 03/03/17 17:15, Mason wrote: >> > [1.264893] Unable to handle kernel paging request at virtual address > d08664f4 >> >> Note that that's a reasonable approximation of a vmalloc address... >> > [1.272248] pgd = c0004000 > [1.275060] [d08664f4] *pgd=8f804811, *pte=, *ppte= > [1.281476] Internal error: Oops: 7 [#1] PREEMPT SMP ARM > [1.286897] Modules linked in: > [1.290053] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.9.7-1-rc2 #151 > [1.296696] Hardware name: Sigma Tango DT > [1.300808] task: cf82c9c0 task.stack: cf838000 > [1.305446] PC is at quirk_usb_early_handoff+0x3e8/0x790 > [1.310873] LR is at ioremap_page_range+0xf8/0x1a8 > [1.315771] pc : []lr : []psr: 000e0013 > [1.315771] sp : cf839d78 ip : fp : cf839e38 > [1.327482] r10: c10248a0 r9 : r8 : d08664f4 > [1.332816] r7 : d084e000 r6 : 2000 r5 : 000c0300 r4 : cfb5f800 > [1.339460] r3 : 000184f4 r2 : r1 : 91001e13 r0 : d084e000 >> >> ...and that specifically it's r0 + r3... >> [1.258926] Unable to handle kernel paging request at virtual address d0863f70 [1.266284] pgd = c0004000 [1.269097] [d0863f70] *pgd=8f804811, *pte=, *ppte= [1.275512] Internal error: Oops: 7 [#1] PREEMPT SMP ARM [1.280933] Modules linked in: [1.284089] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.9.7-1-rc2 #157 [1.290732] Hardware name: Sigma Tango DT [1.294843] task: cf82c9c0 task.stack: cf838000 [1.299482] PC is at quirk_usb_early_handoff+0x3e8/0x790 [1.304907] LR is at ioremap_page_range+0xf8/0x1a8 [1.309806] pc : []lr : []psr: 000e0013 [1.309806] sp : cf839d78 ip : fp : cf839e38 [1.321517] r10: c10248a0 r9 : r8 : d0863f70 [1.326851] r7 : d084e000 r6 : 2000 r5 : 000c0300 r4 : cfb52800 [1.333495] r3 : 00015f70 r2 : r1 : 91001e13 r0 : d084e000 >> >> ...and again... >> >>> [1.261813] Unable to handle kernel paging request at virtual address >>> d08611e4 >>> [1.269167] pgd = c0004000 >>> [1.271979] [d08611e4] *pgd=8f804811, *pte=, *ppte= >>> [1.278394] Internal error: Oops: 7 [#1] PREEMPT SMP ARM >>> [1.283815] Modules linked in: >>> [1.286970] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.9.7-1-rc2 #157 >>> [1.293614] Hardware name: Sigma Tango DT >>> [1.297726] task: cf82c9c0 task.stack: cf838000 >>> [1.302364] PC is at quirk_usb_early_handoff+0x3e8/0x790 >>> [1.307790] LR is at ioremap_page_range+0xf8/0x1a8 >>> [1.312688] pc : []lr : []psr: 000e0013 >>> [1.312688] sp : cf839d78 ip : fp : cf839e38 >>> [1.324399] r10: c10248a0 r9 : r8 : d08611e4 >>> [1.329733] r7 : d084e000 r6 : 2000 r5 : 000c0300 r4 : cfb4e800 >>> [1.336377] r3 : 000131e4 r2 : r1 : 91001e13 r0 : d084e000 >> >> ...and again. And always at the same PC, too. Looking at >> quirk_usb_early_handoff(), it mostly seems to go off poking bridge >> resources, so I'd hazard a guess that it's down to your host driver, >> with something uninitialised (or already freed) being used as an offset >> into some ioremapped resource (which given the consistency of r0 is >> probably allocated pretty early on). >> >> "addr2line -i -e vmlinux c039fe44", and work backwards from there ;) >> In particular I'd follow the provenance of r3. > > Starting from a fresh panic: > > [1.236243] pcieport :00:00.0: enabling device (0140 -> 0142) > [1.242474] pcieport :00:00.0: enabling bus mastering > [1.248147] pci :01:00.0: calling quirk_usb_early_handoff+0x0/0x790 > [1.254904] pci :01:00.0: enabling device (0140 -> 0142) > [1.260719] Unable to handle kernel paging request at virtual address > d08509f8 > [1.268073] pgd = c0004000 > [1.270874] [d08509f8] *pgd=8f804811, *pte=, *ppte= > [1.277282] Internal error: Oops: 7 [#1] PREEMPT SMP ARM > [1.282702] Modules linked in: > [1.285858] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.9.7-1-rc2 #2 > [1.292327] Hardware name: Sigma Tango DT > [1.296438] task: cf82c9c0 task.stack: cf838000 > [1.301076] PC is at quirk_usb_early_handoff+0x3e8/0x790 > [1.306501] LR is at ioremap_page_range+0xf8/0x1a8 > [1.311400] pc : []lr : []psr: 000e0013 > [1.311400] sp : cf839d78 ip : fp : cf839e38 > [1.323110] r10: c10248a0 r9 : r8 : d08509f8 > [1.328444] r7 : d084e000 r6 : 2000 r5 : 000c0300 r4 : cfb5f800 > [1.335087] r3 : 29f8 r2 : r1 : 91001e13 r0 : d084e000 > [1.341732] Flags: nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment > none >
[PATCH 22/29] drivers, scsi: convert iscsi_task.refcount from atomic_t to refcount_t
refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.
Signed-off-by: Elena Reshetova
Signed-off-by: Hans Liljestrand
Signed-off-by: Kees Cook
Signed-off-by: David Windsor
---
drivers/scsi/libiscsi.c| 8
drivers/scsi/qedi/qedi_iscsi.c | 2 +-
include/scsi/libiscsi.h| 3 ++-
3 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/scsi/libiscsi.c b/drivers/scsi/libiscsi.c
index 834d121..7eb1d2c 100644
--- a/drivers/scsi/libiscsi.c
+++ b/drivers/scsi/libiscsi.c
@@ -516,13 +516,13 @@ static void iscsi_free_task(struct iscsi_task *task)
void __iscsi_get_task(struct iscsi_task *task)
{
- atomic_inc(&task->refcount);
+ refcount_inc(&task->refcount);
}
EXPORT_SYMBOL_GPL(__iscsi_get_task);
void __iscsi_put_task(struct iscsi_task *task)
{
- if (atomic_dec_and_test(&task->refcount))
+ if (refcount_dec_and_test(&task->refcount))
iscsi_free_task(task);
}
EXPORT_SYMBOL_GPL(__iscsi_put_task);
@@ -744,7 +744,7 @@ __iscsi_conn_send_pdu(struct iscsi_conn *conn, struct
iscsi_hdr *hdr,
* released by the lld when it has transmitted the task for
* pdus we do not expect a response for.
*/
- atomic_set(&task->refcount, 1);
+ refcount_set(&task->refcount, 1);
task->conn = conn;
task->sc = NULL;
INIT_LIST_HEAD(&task->running);
@@ -1616,7 +1616,7 @@ static inline struct iscsi_task *iscsi_alloc_task(struct
iscsi_conn *conn,
sc->SCp.phase = conn->session->age;
sc->SCp.ptr = (char *) task;
- atomic_set(&task->refcount, 1);
+ refcount_set(&task->refcount, 1);
task->state = ISCSI_TASK_PENDING;
task->conn = conn;
task->sc = sc;
diff --git a/drivers/scsi/qedi/qedi_iscsi.c b/drivers/scsi/qedi/qedi_iscsi.c
index b9f79d3..3895bd5 100644
--- a/drivers/scsi/qedi/qedi_iscsi.c
+++ b/drivers/scsi/qedi/qedi_iscsi.c
@@ -1372,7 +1372,7 @@ static void qedi_cleanup_task(struct iscsi_task *task)
{
if (!task->sc || task->state == ISCSI_TASK_PENDING) {
QEDI_INFO(NULL, QEDI_LOG_IO, "Returning ref_cnt=%d\n",
- atomic_read(&task->refcount));
+ refcount_read(&task->refcount));
return;
}
diff --git a/include/scsi/libiscsi.h b/include/scsi/libiscsi.h
index b0e275d..24d74b5 100644
--- a/include/scsi/libiscsi.h
+++ b/include/scsi/libiscsi.h
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -139,7 +140,7 @@ struct iscsi_task {
/* state set/tested under session->lock */
int state;
- atomic_trefcount;
+ refcount_t refcount;
struct list_headrunning;/* running cmd list */
void*dd_data; /* driver/transport data */
};
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] uvc-gadget: Fix Set Interface (alternate setting) response behaviour
Hi, Roger Quadros writes: > <<< No Message Collected >>> You need to resend this. See also [1] [1] https://marc.info/?l=linux-usb&m=148854335620717&w=2 -- balbi signature.asc Description: PGP signature
[PATCH 28/29] drivers: convert sbd_duart.map_guard from atomic_t to refcount_t
refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.
Signed-off-by: Elena Reshetova
Signed-off-by: Hans Liljestrand
Signed-off-by: Kees Cook
Signed-off-by: David Windsor
---
drivers/tty/serial/sb1250-duart.c | 18 +++---
1 file changed, 7 insertions(+), 11 deletions(-)
diff --git a/drivers/tty/serial/sb1250-duart.c
b/drivers/tty/serial/sb1250-duart.c
index 771f361..041625c 100644
--- a/drivers/tty/serial/sb1250-duart.c
+++ b/drivers/tty/serial/sb1250-duart.c
@@ -41,7 +41,7 @@
#include
#include
-#include
+#include
#include
#include
@@ -103,7 +103,7 @@ struct sbd_port {
struct sbd_duart {
struct sbd_port sport[2];
unsigned long mapctrl;
- atomic_tmap_guard;
+ refcount_t map_guard;
};
#define to_sport(uport) container_of(uport, struct sbd_port, port)
@@ -654,15 +654,13 @@ static void sbd_release_port(struct uart_port *uport)
{
struct sbd_port *sport = to_sport(uport);
struct sbd_duart *duart = sport->duart;
- int map_guard;
iounmap(sport->memctrl);
sport->memctrl = NULL;
iounmap(uport->membase);
uport->membase = NULL;
- map_guard = atomic_add_return(-1, &duart->map_guard);
- if (!map_guard)
+ if(refcount_dec_and_test(&duart->map_guard))
release_mem_region(duart->mapctrl, DUART_CHANREG_SPACING);
release_mem_region(uport->mapbase, DUART_CHANREG_SPACING);
}
@@ -698,7 +696,6 @@ static int sbd_request_port(struct uart_port *uport)
{
const char *err = KERN_ERR "sbd: Unable to reserve MMIO resource\n";
struct sbd_duart *duart = to_sport(uport)->duart;
- int map_guard;
int ret = 0;
if (!request_mem_region(uport->mapbase, DUART_CHANREG_SPACING,
@@ -706,11 +703,11 @@ static int sbd_request_port(struct uart_port *uport)
printk(err);
return -EBUSY;
}
- map_guard = atomic_add_return(1, &duart->map_guard);
- if (map_guard == 1) {
+ refcount_inc(&duart->map_guard);
+ if (refcount_read(&duart->map_guard) == 1) {
if (!request_mem_region(duart->mapctrl, DUART_CHANREG_SPACING,
"sb1250-duart")) {
- atomic_add(-1, &duart->map_guard);
+ refcount_dec(&duart->map_guard);
printk(err);
ret = -EBUSY;
}
@@ -718,8 +715,7 @@ static int sbd_request_port(struct uart_port *uport)
if (!ret) {
ret = sbd_map_port(uport);
if (ret) {
- map_guard = atomic_add_return(-1, &duart->map_guard);
- if (!map_guard)
+ if (refcount_dec_and_test(&duart->map_guard))
release_mem_region(duart->mapctrl,
DUART_CHANREG_SPACING);
}
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 05/29] drivers, md, bcache: convert cached_dev.count from atomic_t to refcount_t
refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.
Signed-off-by: Elena Reshetova
Signed-off-by: Hans Liljestrand
Signed-off-by: Kees Cook
Signed-off-by: David Windsor
---
drivers/md/bcache/bcache.h| 7 ---
drivers/md/bcache/super.c | 6 +++---
drivers/md/bcache/writeback.h | 2 +-
3 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/md/bcache/bcache.h b/drivers/md/bcache/bcache.h
index c3ea03c..de2be28 100644
--- a/drivers/md/bcache/bcache.h
+++ b/drivers/md/bcache/bcache.h
@@ -184,6 +184,7 @@
#include
#include
#include
+#include
#include
#include
@@ -299,7 +300,7 @@ struct cached_dev {
struct semaphoresb_write_mutex;
/* Refcount on the cache set. Always nonzero when we're caching. */
- atomic_tcount;
+ refcount_t count;
struct work_struct detach;
/*
@@ -805,13 +806,13 @@ do {
\
static inline void cached_dev_put(struct cached_dev *dc)
{
- if (atomic_dec_and_test(&dc->count))
+ if (refcount_dec_and_test(&dc->count))
schedule_work(&dc->detach);
}
static inline bool cached_dev_get(struct cached_dev *dc)
{
- if (!atomic_inc_not_zero(&dc->count))
+ if (!refcount_inc_not_zero(&dc->count))
return false;
/* Paired with the mb in cached_dev_attach */
diff --git a/drivers/md/bcache/super.c b/drivers/md/bcache/super.c
index 85e3f21..cc36ce4 100644
--- a/drivers/md/bcache/super.c
+++ b/drivers/md/bcache/super.c
@@ -891,7 +891,7 @@ static void cached_dev_detach_finish(struct work_struct *w)
closure_init_stack(&cl);
BUG_ON(!test_bit(BCACHE_DEV_DETACHING, &dc->disk.flags));
- BUG_ON(atomic_read(&dc->count));
+ BUG_ON(refcount_read(&dc->count));
mutex_lock(&bch_register_lock);
@@ -1018,7 +1018,7 @@ int bch_cached_dev_attach(struct cached_dev *dc, struct
cache_set *c)
* dc->c must be set before dc->count != 0 - paired with the mb in
* cached_dev_get()
*/
- atomic_set(&dc->count, 1);
+ refcount_set(&dc->count, 1);
/* Block writeback thread, but spawn it */
down_write(&dc->writeback_lock);
@@ -1030,7 +1030,7 @@ int bch_cached_dev_attach(struct cached_dev *dc, struct
cache_set *c)
if (BDEV_STATE(&dc->sb) == BDEV_STATE_DIRTY) {
bch_sectors_dirty_init(dc);
atomic_set(&dc->has_dirty, 1);
- atomic_inc(&dc->count);
+ refcount_inc(&dc->count);
bch_writeback_queue(dc);
}
diff --git a/drivers/md/bcache/writeback.h b/drivers/md/bcache/writeback.h
index 629bd1a..5bac1b0 100644
--- a/drivers/md/bcache/writeback.h
+++ b/drivers/md/bcache/writeback.h
@@ -70,7 +70,7 @@ static inline void bch_writeback_add(struct cached_dev *dc)
{
if (!atomic_read(&dc->has_dirty) &&
!atomic_xchg(&dc->has_dirty, 1)) {
- atomic_inc(&dc->count);
+ refcount_inc(&dc->count);
if (BDEV_STATE(&dc->sb) != BDEV_STATE_DIRTY) {
SET_BDEV_STATE(&dc->sb, BDEV_STATE_DIRTY);
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 06/29] drivers, md: convert dm_cache_metadata.ref_count from atomic_t to refcount_t
refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.
Signed-off-by: Elena Reshetova
Signed-off-by: Hans Liljestrand
Signed-off-by: Kees Cook
Signed-off-by: David Windsor
---
drivers/md/dm-cache-metadata.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/md/dm-cache-metadata.c b/drivers/md/dm-cache-metadata.c
index e4c2c1a..6d26e71 100644
--- a/drivers/md/dm-cache-metadata.c
+++ b/drivers/md/dm-cache-metadata.c
@@ -13,6 +13,7 @@
#include "persistent-data/dm-transaction-manager.h"
#include
+#include
/**/
@@ -102,7 +103,7 @@ struct cache_disk_superblock {
} __packed;
struct dm_cache_metadata {
- atomic_t ref_count;
+ refcount_t ref_count;
struct list_head list;
unsigned version;
@@ -756,7 +757,7 @@ static struct dm_cache_metadata *metadata_open(struct
block_device *bdev,
}
cmd->version = metadata_version;
- atomic_set(&cmd->ref_count, 1);
+ refcount_set(&cmd->ref_count, 1);
init_rwsem(&cmd->root_lock);
cmd->bdev = bdev;
cmd->data_block_size = data_block_size;
@@ -794,7 +795,7 @@ static struct dm_cache_metadata *lookup(struct block_device
*bdev)
list_for_each_entry(cmd, &table, list)
if (cmd->bdev == bdev) {
- atomic_inc(&cmd->ref_count);
+ refcount_inc(&cmd->ref_count);
return cmd;
}
@@ -865,7 +866,7 @@ struct dm_cache_metadata *dm_cache_metadata_open(struct
block_device *bdev,
void dm_cache_metadata_close(struct dm_cache_metadata *cmd)
{
- if (atomic_dec_and_test(&cmd->ref_count)) {
+ if (refcount_dec_and_test(&cmd->ref_count)) {
mutex_lock(&table_lock);
list_del(&cmd->list);
mutex_unlock(&table_lock);
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 26/29] drivers, usb: convert dev_data.count from atomic_t to refcount_t
refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.
Signed-off-by: Elena Reshetova
Signed-off-by: Hans Liljestrand
Signed-off-by: Kees Cook
Signed-off-by: David Windsor
---
drivers/usb/gadget/legacy/inode.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/gadget/legacy/inode.c
b/drivers/usb/gadget/legacy/inode.c
index 79a2d8f..81d76f3 100644
--- a/drivers/usb/gadget/legacy/inode.c
+++ b/drivers/usb/gadget/legacy/inode.c
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
#include
#include
@@ -114,7 +115,7 @@ enum ep0_state {
struct dev_data {
spinlock_t lock;
- atomic_tcount;
+ refcount_t count;
enum ep0_state state; /* P: lock */
struct usb_gadgetfs_event event [N_EVENT];
unsignedev_next;
@@ -150,12 +151,12 @@ struct dev_data {
static inline void get_dev (struct dev_data *data)
{
- atomic_inc (&data->count);
+ refcount_inc (&data->count);
}
static void put_dev (struct dev_data *data)
{
- if (likely (!atomic_dec_and_test (&data->count)))
+ if (likely (!refcount_dec_and_test (&data->count)))
return;
/* needs no more cleanup */
BUG_ON (waitqueue_active (&data->wait));
@@ -170,7 +171,7 @@ static struct dev_data *dev_new (void)
if (!dev)
return NULL;
dev->state = STATE_DEV_DISABLED;
- atomic_set (&dev->count, 1);
+ refcount_set (&dev->count, 1);
spin_lock_init (&dev->lock);
INIT_LIST_HEAD (&dev->epfiles);
init_waitqueue_head (&dev->wait);
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 02/29] drivers, firewire: convert fw_node.ref_count from atomic_t to refcount_t
refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.
Signed-off-by: Elena Reshetova
Signed-off-by: Hans Liljestrand
Signed-off-by: Kees Cook
Signed-off-by: David Windsor
---
drivers/firewire/core-topology.c | 2 +-
drivers/firewire/core.h | 8
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/firewire/core-topology.c b/drivers/firewire/core-topology.c
index 0de8350..939d259 100644
--- a/drivers/firewire/core-topology.c
+++ b/drivers/firewire/core-topology.c
@@ -124,7 +124,7 @@ static struct fw_node *fw_node_create(u32 sid, int
port_count, int color)
node->initiated_reset = SELF_ID_PHY_INITIATOR(sid);
node->port_count = port_count;
- atomic_set(&node->ref_count, 1);
+ refcount_set(&node->ref_count, 1);
INIT_LIST_HEAD(&node->link);
return node;
diff --git a/drivers/firewire/core.h b/drivers/firewire/core.h
index e1480ff6..c07962e 100644
--- a/drivers/firewire/core.h
+++ b/drivers/firewire/core.h
@@ -12,7 +12,7 @@
#include
#include
-#include
+#include
struct device;
struct fw_card;
@@ -184,7 +184,7 @@ struct fw_node {
* local node to this node. */
u8 max_depth:4; /* Maximum depth to any leaf node */
u8 max_hops:4; /* Max hops in this sub tree */
- atomic_t ref_count;
+ refcount_t ref_count;
/* For serializing node topology into a list. */
struct list_head link;
@@ -197,14 +197,14 @@ struct fw_node {
static inline struct fw_node *fw_node_get(struct fw_node *node)
{
- atomic_inc(&node->ref_count);
+ refcount_inc(&node->ref_count);
return node;
}
static inline void fw_node_put(struct fw_node *node)
{
- if (atomic_dec_and_test(&node->ref_count))
+ if (refcount_dec_and_test(&node->ref_count))
kfree(node);
}
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 12/29] drivers, media: convert s2255_dev.num_channels from atomic_t to refcount_t
refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.
Signed-off-by: Elena Reshetova
Signed-off-by: Hans Liljestrand
Signed-off-by: Kees Cook
Signed-off-by: David Windsor
---
drivers/media/usb/s2255/s2255drv.c | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/media/usb/s2255/s2255drv.c
b/drivers/media/usb/s2255/s2255drv.c
index a9d4484..2b4b009 100644
--- a/drivers/media/usb/s2255/s2255drv.c
+++ b/drivers/media/usb/s2255/s2255drv.c
@@ -36,6 +36,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -256,7 +257,7 @@ struct s2255_vc {
struct s2255_dev {
struct s2255_vc vc[MAX_CHANNELS];
struct v4l2_device v4l2_dev;
- atomic_tnum_channels;
+ refcount_tnum_channels;
int frames;
struct mutexlock; /* channels[].vdev.lock */
struct mutexcmdlock; /* protects cmdbuf */
@@ -1581,11 +1582,11 @@ static void s2255_video_device_release(struct
video_device *vdev)
container_of(vdev, struct s2255_vc, vdev);
dprintk(dev, 4, "%s, chnls: %d\n", __func__,
- atomic_read(&dev->num_channels));
+ refcount_read(&dev->num_channels));
v4l2_ctrl_handler_free(&vc->hdl);
- if (atomic_dec_and_test(&dev->num_channels))
+ if (refcount_dec_and_test(&dev->num_channels))
s2255_destroy(dev);
return;
}
@@ -1688,7 +1689,7 @@ static int s2255_probe_v4l(struct s2255_dev *dev)
"failed to register video device!\n");
break;
}
- atomic_inc(&dev->num_channels);
+ refcount_set(&dev->num_channels, 1);
v4l2_info(&dev->v4l2_dev, "V4L2 device registered as %s\n",
video_device_node_name(&vc->vdev));
@@ -1696,11 +1697,11 @@ static int s2255_probe_v4l(struct s2255_dev *dev)
pr_info("Sensoray 2255 V4L driver Revision: %s\n",
S2255_VERSION);
/* if no channels registered, return error and probe will fail*/
- if (atomic_read(&dev->num_channels) == 0) {
+ if (refcount_read(&dev->num_channels) == 0) {
v4l2_device_unregister(&dev->v4l2_dev);
return ret;
}
- if (atomic_read(&dev->num_channels) != MAX_CHANNELS)
+ if (refcount_read(&dev->num_channels) != MAX_CHANNELS)
pr_warn("s2255: Not all channels available.\n");
return 0;
}
@@ -2248,7 +2249,7 @@ static int s2255_probe(struct usb_interface *interface,
goto errorFWDATA1;
}
- atomic_set(&dev->num_channels, 0);
+ refcount_set(&dev->num_channels, 0);
dev->pid = id->idProduct;
dev->fw_data = kzalloc(sizeof(struct s2255_fw), GFP_KERNEL);
if (!dev->fw_data)
@@ -2368,12 +2369,12 @@ static void s2255_disconnect(struct usb_interface
*interface)
{
struct s2255_dev *dev = to_s2255_dev(usb_get_intfdata(interface));
int i;
- int channels = atomic_read(&dev->num_channels);
+ int channels = refcount_read(&dev->num_channels);
mutex_lock(&dev->lock);
v4l2_device_disconnect(&dev->v4l2_dev);
mutex_unlock(&dev->lock);
/*see comments in the uvc_driver.c usb disconnect function */
- atomic_inc(&dev->num_channels);
+ refcount_inc(&dev->num_channels);
/* unregister each video device. */
for (i = 0; i < channels; i++)
video_unregister_device(&dev->vc[i].vdev);
@@ -2386,7 +2387,7 @@ static void s2255_disconnect(struct usb_interface
*interface)
dev->vc[i].vidstatus_ready = 1;
wake_up(&dev->vc[i].wait_vidstatus);
}
- if (atomic_dec_and_test(&dev->num_channels))
+ if (refcount_dec_and_test(&dev->num_channels))
s2255_destroy(dev);
dev_info(&interface->dev, "%s\n", __func__);
}
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 11/29] drivers, media: convert cx88_core.refcount from atomic_t to refcount_t
refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.
Signed-off-by: Elena Reshetova
Signed-off-by: Hans Liljestrand
Signed-off-by: Kees Cook
Signed-off-by: David Windsor
---
drivers/media/pci/cx88/cx88-cards.c | 2 +-
drivers/media/pci/cx88/cx88-core.c | 4 ++--
drivers/media/pci/cx88/cx88.h | 3 ++-
3 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/media/pci/cx88/cx88-cards.c
b/drivers/media/pci/cx88/cx88-cards.c
index cdfbde2..7fc5f5f 100644
--- a/drivers/media/pci/cx88/cx88-cards.c
+++ b/drivers/media/pci/cx88/cx88-cards.c
@@ -3670,7 +3670,7 @@ struct cx88_core *cx88_core_create(struct pci_dev *pci,
int nr)
if (!core)
return NULL;
- atomic_inc(&core->refcount);
+ refcount_set(&core->refcount, 1);
core->pci_bus = pci->bus->number;
core->pci_slot = PCI_SLOT(pci->devfn);
core->pci_irqmask = PCI_INT_RISC_RD_BERRINT | PCI_INT_RISC_WR_BERRINT |
diff --git a/drivers/media/pci/cx88/cx88-core.c
b/drivers/media/pci/cx88/cx88-core.c
index 973a9cd4..8bfa5b7 100644
--- a/drivers/media/pci/cx88/cx88-core.c
+++ b/drivers/media/pci/cx88/cx88-core.c
@@ -1052,7 +1052,7 @@ struct cx88_core *cx88_core_get(struct pci_dev *pci)
mutex_unlock(&devlist);
return NULL;
}
- atomic_inc(&core->refcount);
+ refcount_inc(&core->refcount);
mutex_unlock(&devlist);
return core;
}
@@ -1073,7 +1073,7 @@ void cx88_core_put(struct cx88_core *core, struct pci_dev
*pci)
release_mem_region(pci_resource_start(pci, 0),
pci_resource_len(pci, 0));
- if (!atomic_dec_and_test(&core->refcount))
+ if (!refcount_dec_and_test(&core->refcount))
return;
mutex_lock(&devlist);
diff --git a/drivers/media/pci/cx88/cx88.h b/drivers/media/pci/cx88/cx88.h
index 115414c..16c1313 100644
--- a/drivers/media/pci/cx88/cx88.h
+++ b/drivers/media/pci/cx88/cx88.h
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include
#include
@@ -339,7 +340,7 @@ struct cx8802_dev;
struct cx88_core {
struct list_head devlist;
- atomic_t refcount;
+ refcount_t refcount;
/* board name */
intnr;
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/29] drivers, mics refcount conversions
This series, for various different drivers, replaces atomic_t reference counters with the new refcount_t type and API (see include/linux/refcount.h). By doing this we prevent intentional or accidental underflows or overflows that can led to use-after-free vulnerabilities. The below patches are fully independent and can be cherry-picked separately*. Since we convert all kernel subsystems in the same fashion, resulting in about 300 patches, we have to group them for sending at least in some fashion to be manageable. Please excuse the long cc list. *with the exception of the media/vb2-related patches that depend on vb2_vmarea_handler.refcount conversions. Not run-time tested beyond booting and using kernel with refcount conversions for my daily work. If there are no objections to these patches, I think they can go via Greg's drivers tree, as he suggested before. Elena Reshetova (29): drivers, block: convert xen_blkif.refcnt from atomic_t to refcount_t drivers, firewire: convert fw_node.ref_count from atomic_t to refcount_t drivers, char: convert vma_data.refcnt from atomic_t to refcount_t drivers, connector: convert cn_callback_entry.refcnt from atomic_t to refcount_t drivers, md, bcache: convert cached_dev.count from atomic_t to refcount_t drivers, md: convert dm_cache_metadata.ref_count from atomic_t to refcount_t drivers, md: convert dm_dev_internal.count from atomic_t to refcount_t drivers, md: convert mddev.active from atomic_t to refcount_t drivers, md: convert table_device.count from atomic_t to refcount_t drivers, md: convert stripe_head.count from atomic_t to refcount_t drivers, media: convert cx88_core.refcount from atomic_t to refcount_t drivers, media: convert s2255_dev.num_channels from atomic_t to refcount_t drivers, media: convert vb2_vmarea_handler.refcount from atomic_t to refcount_t drivers, media: convert vb2_dc_buf.refcount from atomic_t to refcount_t drivers, media: convert vb2_dma_sg_buf.refcount from atomic_t to refcount_t drivers, media: convert vb2_vmalloc_buf.refcount from atomic_t to refcount_t drivers, pci: convert hv_pci_dev.refs from atomic_t to refcount_t drivers, s390: convert urdev.ref_count from atomic_t to refcount_t drivers, s390: convert lcs_reply.refcnt from atomic_t to refcount_t drivers, s390: convert qeth_reply.refcnt from atomic_t to refcount_t drivers, s390: convert fc_fcp_pkt.ref_cnt from atomic_t to refcount_t drivers, scsi: convert iscsi_task.refcount from atomic_t to refcount_t drivers: convert vme_user_vma_priv.refcnt from atomic_t to refcount_t drivers: convert iblock_req.pending from atomic_t to refcount_t drivers, usb: convert ffs_data.ref from atomic_t to refcount_t drivers, usb: convert dev_data.count from atomic_t to refcount_t drivers, usb: convert ep_data.count from atomic_t to refcount_t drivers: convert sbd_duart.map_guard from atomic_t to refcount_t drivers, xen: convert grant_map.users from atomic_t to refcount_t drivers/block/xen-blkback/common.h | 7 +-- drivers/block/xen-blkback/xenbus.c | 2 +- drivers/char/mspec.c | 9 ++-- drivers/connector/cn_queue.c | 4 +- drivers/connector/connector.c | 2 +- drivers/firewire/core-topology.c | 2 +- drivers/firewire/core.h| 8 ++-- drivers/md/bcache/bcache.h | 7 +-- drivers/md/bcache/super.c | 6 +-- drivers/md/bcache/writeback.h | 2 +- drivers/md/dm-cache-metadata.c | 9 ++-- drivers/md/dm-table.c | 6 +-- drivers/md/dm.c| 12 +++-- drivers/md/dm.h| 3 +- drivers/md/md.c| 6 +-- drivers/md/md.h| 3 +- drivers/md/raid5-cache.c | 8 ++-- drivers/md/raid5.c | 66 +- drivers/md/raid5.h | 3 +- drivers/media/pci/cx88/cx88-cards.c| 2 +- drivers/media/pci/cx88/cx88-core.c | 4 +- drivers/media/pci/cx88/cx88.h | 3 +- drivers/media/usb/s2255/s2255drv.c | 21 drivers/media/v4l2-core/videobuf2-dma-contig.c | 11 +++-- drivers/media/v4l2-core/videobuf2-dma-sg.c | 11 +++-- drivers/media/v4l2-core/videobuf2-memops.c | 6 +-- drivers/media/v4l2-core/videobuf2-vmalloc.c| 11 +++-- drivers/pci/host/pci-hyperv.c | 9 ++-- drivers/s390/char/vmur.c | 8 ++-- drivers/s390/char/vmur.h | 4 +- drivers/s390/net/lcs.c | 8 ++-- drivers/s390/net/lcs.h | 3 +- drivers/s390/net/qeth_core.h | 3 +- drivers/s390/net/qeth_core_main.c | 8 ++-- drivers/
[PATCH 08/29] drivers, md: convert mddev.active from atomic_t to refcount_t
refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.
Signed-off-by: Elena Reshetova
Signed-off-by: Hans Liljestrand
Signed-off-by: Kees Cook
Signed-off-by: David Windsor
---
drivers/md/md.c | 6 +++---
drivers/md/md.h | 3 ++-
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/md/md.c b/drivers/md/md.c
index 985374f..94c8ebf 100644
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -449,7 +449,7 @@ EXPORT_SYMBOL(md_unplug);
static inline struct mddev *mddev_get(struct mddev *mddev)
{
- atomic_inc(&mddev->active);
+ refcount_inc(&mddev->active);
return mddev;
}
@@ -459,7 +459,7 @@ static void mddev_put(struct mddev *mddev)
{
struct bio_set *bs = NULL;
- if (!atomic_dec_and_lock(&mddev->active, &all_mddevs_lock))
+ if (!refcount_dec_and_lock(&mddev->active, &all_mddevs_lock))
return;
if (!mddev->raid_disks && list_empty(&mddev->disks) &&
mddev->ctime == 0 && !mddev->hold_active) {
@@ -495,7 +495,7 @@ void mddev_init(struct mddev *mddev)
INIT_LIST_HEAD(&mddev->all_mddevs);
setup_timer(&mddev->safemode_timer, md_safemode_timeout,
(unsigned long) mddev);
- atomic_set(&mddev->active, 1);
+ refcount_set(&mddev->active, 1);
atomic_set(&mddev->openers, 0);
atomic_set(&mddev->active_io, 0);
spin_lock_init(&mddev->lock);
diff --git a/drivers/md/md.h b/drivers/md/md.h
index b8859cb..4811663 100644
--- a/drivers/md/md.h
+++ b/drivers/md/md.h
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -360,7 +361,7 @@ struct mddev {
*/
struct mutexopen_mutex;
struct mutexreconfig_mutex;
- atomic_tactive; /* general refcount */
+ refcount_t active; /* general refcount */
atomic_topeners;/* number of active
opens */
int changed;/* True if we might
need to
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 10/29] drivers, md: convert stripe_head.count from atomic_t to refcount_t
refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.
Signed-off-by: Elena Reshetova
Signed-off-by: Hans Liljestrand
Signed-off-by: Kees Cook
Signed-off-by: David Windsor
---
drivers/md/raid5-cache.c | 8 +++---
drivers/md/raid5.c | 66
drivers/md/raid5.h | 3 ++-
3 files changed, 39 insertions(+), 38 deletions(-)
diff --git a/drivers/md/raid5-cache.c b/drivers/md/raid5-cache.c
index 3f307be..6c05e12 100644
--- a/drivers/md/raid5-cache.c
+++ b/drivers/md/raid5-cache.c
@@ -979,7 +979,7 @@ int r5l_write_stripe(struct r5l_log *log, struct
stripe_head *sh)
* don't delay.
*/
clear_bit(STRIPE_DELAYED, &sh->state);
- atomic_inc(&sh->count);
+ refcount_inc(&sh->count);
mutex_lock(&log->io_mutex);
/* meta + data */
@@ -1321,7 +1321,7 @@ static void r5c_flush_stripe(struct r5conf *conf, struct
stripe_head *sh)
assert_spin_locked(&conf->device_lock);
list_del_init(&sh->lru);
- atomic_inc(&sh->count);
+ refcount_inc(&sh->count);
set_bit(STRIPE_HANDLE, &sh->state);
atomic_inc(&conf->active_stripes);
@@ -1424,7 +1424,7 @@ static void r5c_do_reclaim(struct r5conf *conf)
*/
if (!list_empty(&sh->lru) &&
!test_bit(STRIPE_HANDLE, &sh->state) &&
- atomic_read(&sh->count) == 0) {
+ refcount_read(&sh->count) == 0) {
r5c_flush_stripe(conf, sh);
if (count++ >= R5C_RECLAIM_STRIPE_GROUP)
break;
@@ -2650,7 +2650,7 @@ r5c_cache_data(struct r5l_log *log, struct stripe_head
*sh,
* don't delay.
*/
clear_bit(STRIPE_DELAYED, &sh->state);
- atomic_inc(&sh->count);
+ refcount_inc(&sh->count);
mutex_lock(&log->io_mutex);
/* meta + data */
diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
index 2ce23b0..30c96a8 100644
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -296,7 +296,7 @@ static void do_release_stripe(struct r5conf *conf, struct
stripe_head *sh,
static void __release_stripe(struct r5conf *conf, struct stripe_head *sh,
struct list_head *temp_inactive_list)
{
- if (atomic_dec_and_test(&sh->count))
+ if (refcount_dec_and_test(&sh->count))
do_release_stripe(conf, sh, temp_inactive_list);
}
@@ -388,7 +388,7 @@ void raid5_release_stripe(struct stripe_head *sh)
/* Avoid release_list until the last reference.
*/
- if (atomic_add_unless(&sh->count, -1, 1))
+ if (refcount_dec_not_one(&sh->count))
return;
if (unlikely(!conf->mddev->thread) ||
@@ -401,7 +401,7 @@ void raid5_release_stripe(struct stripe_head *sh)
slow_path:
local_irq_save(flags);
/* we are ok here if STRIPE_ON_RELEASE_LIST is set or not */
- if (atomic_dec_and_lock(&sh->count, &conf->device_lock)) {
+ if (refcount_dec_and_lock(&sh->count, &conf->device_lock)) {
INIT_LIST_HEAD(&list);
hash = sh->hash_lock_index;
do_release_stripe(conf, sh, &list);
@@ -491,7 +491,7 @@ static void init_stripe(struct stripe_head *sh, sector_t
sector, int previous)
struct r5conf *conf = sh->raid_conf;
int i, seq;
- BUG_ON(atomic_read(&sh->count) != 0);
+ BUG_ON(refcount_read(&sh->count) != 0);
BUG_ON(test_bit(STRIPE_HANDLE, &sh->state));
BUG_ON(stripe_operations_active(sh));
BUG_ON(sh->batch_head);
@@ -668,11 +668,11 @@ raid5_get_active_stripe(struct r5conf *conf, sector_t
sector,
&conf->cache_state);
} else {
init_stripe(sh, sector, previous);
- atomic_inc(&sh->count);
+ refcount_inc(&sh->count);
}
- } else if (!atomic_inc_not_zero(&sh->count)) {
+ } else if (!refcount_inc_not_zero(&sh->count)) {
spin_lock(&conf->device_lock);
- if (!atomic_read(&sh->count)) {
+ if (!refcount_read(&sh->count)) {
if (!test_bit(STRIPE_HANDLE, &sh->state))
atomic_inc(&conf->active_stripes);
BUG_ON(list_empty(&sh->lru) &&
@@ -688,7 +688,7 @@ raid5_get_active_stripe(struct r5conf *conf, sector_t
sector,
sh->group = NULL;
}
}
- atomic_inc(&sh->count);
+
[PATCH 24/29] drivers: convert iblock_req.pending from atomic_t to refcount_t
refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.
Signed-off-by: Elena Reshetova
Signed-off-by: Hans Liljestrand
Signed-off-by: Kees Cook
Signed-off-by: David Windsor
---
drivers/target/target_core_iblock.c | 12 ++--
drivers/target/target_core_iblock.h | 3 ++-
2 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/target/target_core_iblock.c
b/drivers/target/target_core_iblock.c
index d316ed5..bb069eb 100644
--- a/drivers/target/target_core_iblock.c
+++ b/drivers/target/target_core_iblock.c
@@ -279,7 +279,7 @@ static void iblock_complete_cmd(struct se_cmd *cmd)
struct iblock_req *ibr = cmd->priv;
u8 status;
- if (!atomic_dec_and_test(&ibr->pending))
+ if (!refcount_dec_and_test(&ibr->pending))
return;
if (atomic_read(&ibr->ib_bio_err_cnt))
@@ -487,7 +487,7 @@ iblock_execute_write_same(struct se_cmd *cmd)
bio_list_init(&list);
bio_list_add(&list, bio);
- atomic_set(&ibr->pending, 1);
+ refcount_set(&ibr->pending, 1);
while (sectors) {
while (bio_add_page(bio, sg_page(sg), sg->length, sg->offset)
@@ -498,7 +498,7 @@ iblock_execute_write_same(struct se_cmd *cmd)
if (!bio)
goto fail_put_bios;
- atomic_inc(&ibr->pending);
+ refcount_inc(&ibr->pending);
bio_list_add(&list, bio);
}
@@ -706,7 +706,7 @@ iblock_execute_rw(struct se_cmd *cmd, struct scatterlist
*sgl, u32 sgl_nents,
cmd->priv = ibr;
if (!sgl_nents) {
- atomic_set(&ibr->pending, 1);
+ refcount_set(&ibr->pending, 1);
iblock_complete_cmd(cmd);
return 0;
}
@@ -719,7 +719,7 @@ iblock_execute_rw(struct se_cmd *cmd, struct scatterlist
*sgl, u32 sgl_nents,
bio_list_init(&list);
bio_list_add(&list, bio);
- atomic_set(&ibr->pending, 2);
+ refcount_set(&ibr->pending, 2);
bio_cnt = 1;
for_each_sg(sgl, sg, sgl_nents, i) {
@@ -740,7 +740,7 @@ iblock_execute_rw(struct se_cmd *cmd, struct scatterlist
*sgl, u32 sgl_nents,
if (!bio)
goto fail_put_bios;
- atomic_inc(&ibr->pending);
+ refcount_inc(&ibr->pending);
bio_list_add(&list, bio);
bio_cnt++;
}
diff --git a/drivers/target/target_core_iblock.h
b/drivers/target/target_core_iblock.h
index 718d3fc..f2a5797 100644
--- a/drivers/target/target_core_iblock.h
+++ b/drivers/target/target_core_iblock.h
@@ -2,6 +2,7 @@
#define TARGET_CORE_IBLOCK_H
#include
+#include
#include
#define IBLOCK_VERSION "4.0"
@@ -10,7 +11,7 @@
#define IBLOCK_LBA_SHIFT 9
struct iblock_req {
- atomic_t pending;
+ refcount_t pending;
atomic_t ib_bio_err_cnt;
} cacheline_aligned;
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] HID: usbhid: extend polling interval configuration to joysticks
On Sat, 25 Feb 2017, Tobias Jakobi wrote: > For mouse devices we can currently change the polling interval > via usbhid.mousepoll. Implement the same thing for joysticks, so > users can reduce input latency this way. > > This has been tested with a Logitech RumblePad 2 with jspoll=2, > resulting in a polling rate of 500Hz (verified with evhz). > > Signed-off-by: Tobias Jakobi Applied to for-4.12/upstream. Thanks, -- Jiri Kosina SUSE Labs -- 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
[RESEND PATCH v3 5/8] phy: phy-mt65xx-usb3: add support for new version phy
There are some variations from mt2701 to mt2712: 1. banks shared by multiple ports are put back into each port, such as SPLLC and U2FREQ; 2. add a new bank MISC for u2port, and CHIP for u3port; 3. bank's offset in each port are also rearranged; Signed-off-by: Chunfeng Yun --- drivers/phy/phy-mt65xx-usb3.c | 344 ++--- 1 file changed, 217 insertions(+), 127 deletions(-) diff --git a/drivers/phy/phy-mt65xx-usb3.c b/drivers/phy/phy-mt65xx-usb3.c index f4a3505..eb33499 100644 --- a/drivers/phy/phy-mt65xx-usb3.c +++ b/drivers/phy/phy-mt65xx-usb3.c @@ -23,46 +23,54 @@ #include #include -/* - * for sifslv2 register, but exclude port's; - * relative to USB3_SIF2_BASE base address - */ -#define SSUSB_SIFSLV_SPLLC 0x -#define SSUSB_SIFSLV_U2FREQ0x0100 - -/* offsets of banks in each u2phy registers */ -#define SSUSB_SIFSLV_U2PHY_COM_BASE0x -/* offsets of banks in each u3phy registers */ -#define SSUSB_SIFSLV_U3PHYD_BASE 0x -#define SSUSB_SIFSLV_U3PHYA_BASE 0x0200 - -#define U3P_USBPHYACR0 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x) +/* version V1 sub-banks offset base address */ +/* banks shared by multiple phys */ +#define SSUSB_SIFSLV_V1_SPLLC 0x000 /* shared by u3 phys */ +#define SSUSB_SIFSLV_V1_U2FREQ 0x100 /* shared by u2 phys */ +/* u2 phy bank */ +#define SSUSB_SIFSLV_V1_U2PHY_COM 0x000 +/* u3 phy banks */ +#define SSUSB_SIFSLV_V1_U3PHYD 0x000 +#define SSUSB_SIFSLV_V1_U3PHYA 0x200 + +/* version V2 sub-banks offset base address */ +/* u2 phy banks */ +#define SSUSB_SIFSLV_V2_MISC 0x000 +#define SSUSB_SIFSLV_V2_U2FREQ 0x100 +#define SSUSB_SIFSLV_V2_U2PHY_COM 0x300 +/* u3 phy banks */ +#define SSUSB_SIFSLV_V2_SPLLC 0x000 +#define SSUSB_SIFSLV_V2_CHIP 0x100 +#define SSUSB_SIFSLV_V2_U3PHYD 0x200 +#define SSUSB_SIFSLV_V2_U3PHYA 0x400 + +#define U3P_USBPHYACR0 0x000 #define PA0_RG_U2PLL_FORCE_ON BIT(15) -#define U3P_USBPHYACR2 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0008) +#define U3P_USBPHYACR2 0x008 #define PA2_RG_SIF_U2PLL_FORCE_EN BIT(18) -#define U3P_USBPHYACR5 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0014) +#define U3P_USBPHYACR5 0x014 #define PA5_RG_U2_HSTX_SRCAL_ENBIT(15) #define PA5_RG_U2_HSTX_SRCTRL GENMASK(14, 12) #define PA5_RG_U2_HSTX_SRCTRL_VAL(x) ((0x7 & (x)) << 12) #define PA5_RG_U2_HS_100U_U3_ENBIT(11) -#define U3P_USBPHYACR6 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0018) +#define U3P_USBPHYACR6 0x018 #define PA6_RG_U2_BC11_SW_EN BIT(23) #define PA6_RG_U2_OTG_VBUSCMP_EN BIT(20) #define PA6_RG_U2_SQTH GENMASK(3, 0) #define PA6_RG_U2_SQTH_VAL(x) (0xf & (x)) -#define U3P_U2PHYACR4 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0020) +#define U3P_U2PHYACR4 0x020 #define P2C_RG_USB20_GPIO_CTL BIT(9) #define P2C_USB20_GPIO_MODEBIT(8) #define P2C_U2_GPIO_CTR_MSK(P2C_RG_USB20_GPIO_CTL | P2C_USB20_GPIO_MODE) -#define U3D_U2PHYDCR0 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0060) +#define U3D_U2PHYDCR0 0x060 #define P2C_RG_SIF_U2PLL_FORCE_ON BIT(24) -#define U3P_U2PHYDTM0 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0068) +#define U3P_U2PHYDTM0 0x068 #define P2C_FORCE_UART_EN BIT(26) #define P2C_FORCE_DATAIN BIT(23) #define P2C_FORCE_DM_PULLDOWN BIT(21) @@ -84,59 +92,56 @@ P2C_FORCE_TERMSEL | P2C_RG_DMPULLDOWN | \ P2C_RG_DPPULLDOWN | P2C_RG_TERMSEL) -#define U3P_U2PHYDTM1 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x006C) +#define U3P_U2PHYDTM1 0x06C #define P2C_RG_UART_EN BIT(16) #define P2C_RG_VBUSVALID BIT(5) #define P2C_RG_SESSEND BIT(4) #define P2C_RG_AVALID BIT(2) -#define U3P_U3_PHYA_REG0 (SSUSB_SIFSLV_U3PHYA_BASE + 0x) -#define P3A_RG_U3_VUSB10_ONBIT(5) - -#define U3P_U3_PHYA_REG6 (SSUSB_SIFSLV_U3PHYA_BASE + 0x0018) +#define U3P_U3_PHYA_REG6 0x018 #define P3A_RG_TX_EIDLE_CM GENMASK(31, 28) #define P3A_RG_TX_EIDLE_CM_VAL(x) ((0xf & (x)) << 28) -#define U3P_U3_PHYA_REG9 (SSUSB_SIFSLV_U3PHYA_BASE + 0x0024) +#define U3P_U3_PHYA_REG9 0x024 #define P3A_RG_RX_DAC_MUX GENMASK(5, 1) #define P3A_RG_RX_DAC_MUX_VAL(x) ((0x1f & (x)) << 1) -#define U3P_U3PHYA_DA_REG0 (SSUSB_SIFSLV_U3PHYA_BASE + 0x0100) +#define U3P_U3_PHYA_DA_REG00x100 #define P3A_RG_XTAL_EXT_EN_U3 GENMASK(11, 10) #define P3A_RG_XTAL_EXT_EN_U3_VAL(x) ((0x3 & (x)) << 10) -#define U3P_U3_PHYD_LFPS1 (SSUSB_SIFSLV_U3PHYD_BASE + 0x000c) +#define U3P_U3_PHYD_LFPS1 0x00c #define P3D_RG_FWAKE_THGENMASK(21, 16) #define P3D_RG_FWAKE_TH_VAL(x) ((0x3f & (x)) << 16) -#define U3P_PHYD_CDR1
Re: [PATCH] HID: usbhid: extend polling interval configuration to joysticks
Jiri Kosina wrote: > On Sat, 25 Feb 2017, Tobias Jakobi wrote: > >> For mouse devices we can currently change the polling interval >> via usbhid.mousepoll. Implement the same thing for joysticks, so >> users can reduce input latency this way. >> >> This has been tested with a Logitech RumblePad 2 with jspoll=2, >> resulting in a polling rate of 500Hz (verified with evhz). >> >> Signed-off-by: Tobias Jakobi > > Applied to for-4.12/upstream. Thanks, Thank you as well! :) - Tobias -- 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
[RESEND PATCH v3 3/8] phy: phy-mt65xx-usb3: split SuperSpeed port into two ones
Currently usb3 port in fact includes two sub-ports, but it is not
flexible for some cases, such as following one:
usb3 port0 includes u2port0 and u3port0;
usb2 port0 includes u2port1;
If wants to support only HS, we can use u2port0 or u2port1, when
select u2port0, u3port0 is not needed;
If wants to support SS, we can compound u2port0 and u3port0,
or u2port1 and u3port0, if select latter one, u2port0 is not needed.
So it's more flexible to split usb3 port into two ones and also try
best to save power by disabling unnecessary ports.
Signed-off-by: Chunfeng Yun
---
drivers/phy/phy-mt65xx-usb3.c | 149 +
1 file changed, 75 insertions(+), 74 deletions(-)
diff --git a/drivers/phy/phy-mt65xx-usb3.c b/drivers/phy/phy-mt65xx-usb3.c
index 4fd47d0..7fff482 100644
--- a/drivers/phy/phy-mt65xx-usb3.c
+++ b/drivers/phy/phy-mt65xx-usb3.c
@@ -30,11 +30,11 @@
#define SSUSB_SIFSLV_SPLLC 0x
#define SSUSB_SIFSLV_U2FREQ0x0100
-/* offsets of sub-segment in each port registers */
+/* offsets of banks in each u2phy registers */
#define SSUSB_SIFSLV_U2PHY_COM_BASE0x
-#define SSUSB_SIFSLV_U3PHYD_BASE 0x0100
-#define SSUSB_USB30_PHYA_SIV_B_BASE0x0300
-#define SSUSB_SIFSLV_U3PHYA_DA_BASE0x0400
+/* offsets of banks in each u3phy registers */
+#define SSUSB_SIFSLV_U3PHYD_BASE 0x
+#define SSUSB_SIFSLV_U3PHYA_BASE 0x0200
#define U3P_USBPHYACR0 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x)
#define PA0_RG_U2PLL_FORCE_ON BIT(15)
@@ -49,7 +49,6 @@
#define PA5_RG_U2_HS_100U_U3_ENBIT(11)
#define U3P_USBPHYACR6 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0018)
-#define PA6_RG_U2_ISO_EN BIT(31)
#define PA6_RG_U2_BC11_SW_EN BIT(23)
#define PA6_RG_U2_OTG_VBUSCMP_EN BIT(20)
#define PA6_RG_U2_SQTH GENMASK(3, 0)
@@ -91,18 +90,18 @@
#define P2C_RG_SESSEND BIT(4)
#define P2C_RG_AVALID BIT(2)
-#define U3P_U3_PHYA_REG0 (SSUSB_USB30_PHYA_SIV_B_BASE + 0x)
+#define U3P_U3_PHYA_REG0 (SSUSB_SIFSLV_U3PHYA_BASE + 0x)
#define P3A_RG_U3_VUSB10_ONBIT(5)
-#define U3P_U3_PHYA_REG6 (SSUSB_USB30_PHYA_SIV_B_BASE + 0x0018)
+#define U3P_U3_PHYA_REG6 (SSUSB_SIFSLV_U3PHYA_BASE + 0x0018)
#define P3A_RG_TX_EIDLE_CM GENMASK(31, 28)
#define P3A_RG_TX_EIDLE_CM_VAL(x) ((0xf & (x)) << 28)
-#define U3P_U3_PHYA_REG9 (SSUSB_USB30_PHYA_SIV_B_BASE + 0x0024)
+#define U3P_U3_PHYA_REG9 (SSUSB_SIFSLV_U3PHYA_BASE + 0x0024)
#define P3A_RG_RX_DAC_MUX GENMASK(5, 1)
#define P3A_RG_RX_DAC_MUX_VAL(x) ((0x1f & (x)) << 1)
-#define U3P_U3PHYA_DA_REG0 (SSUSB_SIFSLV_U3PHYA_DA_BASE + 0x)
+#define U3P_U3PHYA_DA_REG0 (SSUSB_SIFSLV_U3PHYA_BASE + 0x0100)
#define P3A_RG_XTAL_EXT_EN_U3 GENMASK(11, 10)
#define P3A_RG_XTAL_EXT_EN_U3_VAL(x) ((0x3 & (x)) << 10)
@@ -160,7 +159,7 @@ struct mt65xx_phy_instance {
struct mt65xx_u3phy {
struct device *dev;
- void __iomem *sif_base; /* include sif2, but exclude port's */
+ void __iomem *sif_base; /* only shared sif */
struct clk *u3phya_ref; /* reference clock of usb3 anolog phy */
const struct mt65xx_phy_pdata *pdata;
struct mt65xx_phy_instance **phys;
@@ -190,7 +189,7 @@ static void hs_slew_rate_calibrate(struct mt65xx_u3phy
*u3phy,
tmp = readl(sif_base + U3P_U2FREQ_FMCR0);
tmp &= ~(P2F_RG_CYCLECNT | P2F_RG_MONCLK_SEL);
tmp |= P2F_RG_CYCLECNT_VAL(U3P_FM_DET_CYCLE_CNT);
- tmp |= P2F_RG_MONCLK_SEL_VAL(instance->index);
+ tmp |= P2F_RG_MONCLK_SEL_VAL(instance->index >> 1);
writel(tmp, sif_base + U3P_U2FREQ_FMCR0);
/* enable frequency meter */
@@ -238,6 +237,56 @@ static void hs_slew_rate_calibrate(struct mt65xx_u3phy
*u3phy,
writel(tmp, instance->port_base + U3P_USBPHYACR5);
}
+static void u3_phy_instance_init(struct mt65xx_u3phy *u3phy,
+ struct mt65xx_phy_instance *instance)
+{
+ void __iomem *port_base = instance->port_base;
+ u32 tmp;
+
+ /* gating PCIe Analog XTAL clock */
+ tmp = readl(u3phy->sif_base + U3P_XTALCTL3);
+ tmp |= XC3_RG_U3_XTAL_RX_PWD | XC3_RG_U3_FRC_XTAL_RX_PWD;
+ writel(tmp, u3phy->sif_base + U3P_XTALCTL3);
+
+ /* gating XSQ */
+ tmp = readl(port_base + U3P_U3PHYA_DA_REG0);
+ tmp &= ~P3A_RG_XTAL_EXT_EN_U3;
+ tmp |= P3A_RG_XTAL_EXT_EN_U3_VAL(2);
+ writel(tmp, port_base + U3P_U3PHYA_DA_REG0);
+
+ tmp = readl(port_base + U3P_U3_PHYA_REG9);
+ tmp &= ~P3A_RG_RX_DAC_MUX;
+ tmp |= P3A_RG_RX_DAC_MUX_VAL(4);
+ writel(tmp, port_base + U3P_U3_PHYA_REG9);
+
+ tmp = readl(port_base + U3P_U3_PHYA_REG6);
+ tmp &= ~P3A_RG_TX_EIDLE_CM;
+ tmp |= P3A_RG_TX_EIDLE_CM_VAL(0xe);
+ writel(tmp, port_base + U3P_U3_PHYA_REG6);
+
+ tmp = readl(port_base + U3P_PHYD_CDR1);
+ tmp &= ~(P3
[RESEND PATCH v3 1/8] phy: phy-mt65xx-usb3: improve RX detection stable time
The default value of RX detection stable time is 10us, and this margin is too big for some critical cases which cause U3 link fail and link to U2(probability is about 1%). So change it to 5us. Signed-off-by: Chunfeng Yun --- drivers/phy/phy-mt65xx-usb3.c | 18 ++ 1 file changed, 18 insertions(+) diff --git a/drivers/phy/phy-mt65xx-usb3.c b/drivers/phy/phy-mt65xx-usb3.c index d972067..fe2392a 100644 --- a/drivers/phy/phy-mt65xx-usb3.c +++ b/drivers/phy/phy-mt65xx-usb3.c @@ -112,6 +112,14 @@ #define P3D_RG_CDR_BIR_LTD0GENMASK(12, 8) #define P3D_RG_CDR_BIR_LTD0_VAL(x) ((0x1f & (x)) << 8) +#define U3P_U3_PHYD_RXDET1 (SSUSB_SIFSLV_U3PHYD_BASE + 0x128) +#define P3D_RG_RXDET_STB2_SET GENMASK(17, 9) +#define P3D_RG_RXDET_STB2_SET_VAL(x) ((0x1ff & (x)) << 9) + +#define U3P_U3_PHYD_RXDET2 (SSUSB_SIFSLV_U3PHYD_BASE + 0x12c) +#define P3D_RG_RXDET_STB2_SET_P3 GENMASK(8, 0) +#define P3D_RG_RXDET_STB2_SET_P3_VAL(x)(0x1ff & (x)) + #define U3P_XTALCTL3 (SSUSB_SIFSLV_SPLLC + 0x0018) #define XC3_RG_U3_XTAL_RX_PWD BIT(9) #define XC3_RG_U3_FRC_XTAL_RX_PWD BIT(8) @@ -295,6 +303,16 @@ static void phy_instance_init(struct mt65xx_u3phy *u3phy, tmp |= P3D_RG_CDR_BIR_LTD0_VAL(0xc) | P3D_RG_CDR_BIR_LTD1_VAL(0x3); writel(tmp, port_base + U3P_PHYD_CDR1); + tmp = readl(port_base + U3P_U3_PHYD_RXDET1); + tmp &= ~P3D_RG_RXDET_STB2_SET; + tmp |= P3D_RG_RXDET_STB2_SET_VAL(0x10); + writel(tmp, port_base + U3P_U3_PHYD_RXDET1); + + tmp = readl(port_base + U3P_U3_PHYD_RXDET2); + tmp &= ~P3D_RG_RXDET_STB2_SET_P3; + tmp |= P3D_RG_RXDET_STB2_SET_P3_VAL(0x10); + writel(tmp, port_base + U3P_U3_PHYD_RXDET2); + dev_dbg(u3phy->dev, "%s(%d)\n", __func__, index); } -- 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
[RESEND PATCH v3 6/8] arm64: dts: mt8173: split usb SuperSpeed port into two ports
split the old SuperSpeed port node into a HighSpeed one and a new
SuperSpeed one.
Signed-off-by: Chunfeng Yun
---
arch/arm64/boot/dts/mediatek/mt8173.dtsi | 19 +--
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 6922252..1dc4629 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -731,8 +731,9 @@
<0 0x11280700 0 0x0100>;
reg-names = "mac", "ippc";
interrupts = ;
- phys = <&phy_port0 PHY_TYPE_USB3>,
- <&phy_port1 PHY_TYPE_USB2>;
+ phys = <&u2port0 PHY_TYPE_USB2>,
+ <&u3port0 PHY_TYPE_USB3>,
+ <&u2port1 PHY_TYPE_USB2>;
power-domains = <&scpsys MT8173_POWER_DOMAIN_USB>;
clocks = <&topckgen CLK_TOP_USB30_SEL>,
<&clk26m>,
@@ -770,14 +771,20 @@
ranges;
status = "okay";
- phy_port0: port@11290800 {
- reg = <0 0x11290800 0 0x800>;
+ u2port0: usb-phy@11290800 {
+ reg = <0 0x11290800 0 0x100>;
#phy-cells = <1>;
status = "okay";
};
- phy_port1: port@11291000 {
- reg = <0 0x11291000 0 0x800>;
+ u3port0: usb-phy@11290900 {
+ reg = <0 0x11290900 0 0x700>;
+ #phy-cells = <1>;
+ status = "okay";
+ };
+
+ u2port1: usb-phy@11291000 {
+ reg = <0 0x11291000 0 0x100>;
#phy-cells = <1>;
status = "okay";
};
--
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
[RESEND PATCH v3 2/8] phy: phy-mt65xx-usb3: increase LFPS filter threshold
Increase LFPS filter threshold to avoid some fake remote wakeup signal which cause U3 link fail and link to U2 only at about 0.01% probability. Signed-off-by: Chunfeng Yun --- drivers/phy/phy-mt65xx-usb3.c |9 + 1 file changed, 9 insertions(+) diff --git a/drivers/phy/phy-mt65xx-usb3.c b/drivers/phy/phy-mt65xx-usb3.c index fe2392a..4fd47d0 100644 --- a/drivers/phy/phy-mt65xx-usb3.c +++ b/drivers/phy/phy-mt65xx-usb3.c @@ -106,6 +106,10 @@ #define P3A_RG_XTAL_EXT_EN_U3 GENMASK(11, 10) #define P3A_RG_XTAL_EXT_EN_U3_VAL(x) ((0x3 & (x)) << 10) +#define U3P_U3_PHYD_LFPS1 (SSUSB_SIFSLV_U3PHYD_BASE + 0x000c) +#define P3D_RG_FWAKE_THGENMASK(21, 16) +#define P3D_RG_FWAKE_TH_VAL(x) ((0x3f & (x)) << 16) + #define U3P_PHYD_CDR1 (SSUSB_SIFSLV_U3PHYD_BASE + 0x005c) #define P3D_RG_CDR_BIR_LTD1GENMASK(28, 24) #define P3D_RG_CDR_BIR_LTD1_VAL(x) ((0x1f & (x)) << 24) @@ -303,6 +307,11 @@ static void phy_instance_init(struct mt65xx_u3phy *u3phy, tmp |= P3D_RG_CDR_BIR_LTD0_VAL(0xc) | P3D_RG_CDR_BIR_LTD1_VAL(0x3); writel(tmp, port_base + U3P_PHYD_CDR1); + tmp = readl(port_base + U3P_U3_PHYD_LFPS1); + tmp &= ~P3D_RG_FWAKE_TH; + tmp |= P3D_RG_FWAKE_TH_VAL(0x34); + writel(tmp, port_base + U3P_U3_PHYD_LFPS1); + tmp = readl(port_base + U3P_U3_PHYD_RXDET1); tmp &= ~P3D_RG_RXDET_STB2_SET; tmp |= P3D_RG_RXDET_STB2_SET_VAL(0x10); -- 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
[RESEND PATCH v3 7/8] arm64: dts: mt8173: move clock from phy node into port nodes
there is a reference clock for each port, HighSpeed port is 48M,
and SuperSpeed port is 26M which usually comes from 26M oscillator
directly, but some SoCs is not. it is flexible to move it into port
node.
Signed-off-by: Chunfeng Yun
---
arch/arm64/boot/dts/mediatek/mt8173.dtsi |8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 1dc4629..1c9e0d5 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -764,8 +764,6 @@
u3phy: usb-phy@1129 {
compatible = "mediatek,mt8173-u3phy";
reg = <0 0x1129 0 0x800>;
- clocks = <&apmixedsys CLK_APMIXED_REF2USB_TX>;
- clock-names = "u3phya_ref";
#address-cells = <2>;
#size-cells = <2>;
ranges;
@@ -773,18 +771,24 @@
u2port0: usb-phy@11290800 {
reg = <0 0x11290800 0 0x100>;
+ clocks = <&apmixedsys CLK_APMIXED_REF2USB_TX>;
+ clock-names = "ref";
#phy-cells = <1>;
status = "okay";
};
u3port0: usb-phy@11290900 {
reg = <0 0x11290900 0 0x700>;
+ clocks = <&clk26m>;
+ clock-names = "ref";
#phy-cells = <1>;
status = "okay";
};
u2port1: usb-phy@11291000 {
reg = <0 0x11291000 0 0x100>;
+ clocks = <&apmixedsys CLK_APMIXED_REF2USB_TX>;
+ clock-names = "ref";
#phy-cells = <1>;
status = "okay";
};
--
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
[RESEND PATCH v3 8/8] dt-bindings: phy-mt65xx-usb: add support for new version phy
add a new compatible string for "mt2712", and move reference clock
into each port node;
Signed-off-by: Chunfeng Yun
Acked-by: Rob Herring
---
.../devicetree/bindings/phy/phy-mt65xx-usb.txt | 93 +---
1 file changed, 80 insertions(+), 13 deletions(-)
diff --git a/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
b/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
index 33a2b1e..0acc5a9 100644
--- a/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
+++ b/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
@@ -6,12 +6,11 @@ This binding describes a usb3.0 phy for mt65xx platforms of
Medaitek SoC.
Required properties (controller (parent) node):
- compatible : should be one of
"mediatek,mt2701-u3phy"
+ "mediatek,mt2712-u3phy"
"mediatek,mt8173-u3phy"
- - reg : offset and length of register for phy, exclude port's
- register.
- - clocks : a list of phandle + clock-specifier pairs, one for each
- entry in clock-names
- - clock-names : must contain
+ - clocks : (deprecated, use port's clocks instead) a list of phandle +
+ clock-specifier pairs, one for each entry in clock-names
+ - clock-names : (deprecated, use port's one instead) must contain
"u3phya_ref": for reference clock of usb3.0 analog phy.
Required nodes : a sub-node is required for each port the controller
@@ -19,8 +18,19 @@ Required nodes : a sub-node is required for each port
the controller
'reg' property is used inside these nodes to describe
the controller's topology.
+Optional properties (controller (parent) node):
+ - reg : offset and length of register shared by multiple ports,
+ exclude port's private register. It is needed on mt2701
+ and mt8173, but not on mt2712.
+
Required properties (port (child) node):
- reg : address and length of the register set for the port.
+- clocks : a list of phandle + clock-specifier pairs, one for each
+ entry in clock-names
+- clock-names : must contain
+ "ref": 48M reference clock for HighSpeed analog phy; and 26M
+ reference clock for SuperSpeed analog phy, sometimes is
+ 24M, 25M or 27M, depended on platform.
- #phy-cells : should be 1 (See second example)
cell after port phandle is phy type from:
- PHY_TYPE_USB2
@@ -31,21 +41,31 @@ Example:
u3phy: usb-phy@1129 {
compatible = "mediatek,mt8173-u3phy";
reg = <0 0x1129 0 0x800>;
- clocks = <&apmixedsys CLK_APMIXED_REF2USB_TX>;
- clock-names = "u3phya_ref";
#address-cells = <2>;
#size-cells = <2>;
ranges;
status = "okay";
- phy_port0: port@11290800 {
- reg = <0 0x11290800 0 0x800>;
+ u2port0: usb-phy@11290800 {
+ reg = <0 0x11290800 0 0x100>;
+ clocks = <&apmixedsys CLK_APMIXED_REF2USB_TX>;
+ clock-names = "ref";
#phy-cells = <1>;
status = "okay";
};
- phy_port1: port@11291000 {
- reg = <0 0x11291000 0 0x800>;
+ u3port0: usb-phy@11290900 {
+ reg = <0 0x11290800 0 0x700>;
+ clocks = <&clk26m>;
+ clock-names = "ref";
+ #phy-cells = <1>;
+ status = "okay";
+ };
+
+ u2port1: usb-phy@11291000 {
+ reg = <0 0x11291000 0 0x100>;
+ clocks = <&apmixedsys CLK_APMIXED_REF2USB_TX>;
+ clock-names = "ref";
#phy-cells = <1>;
status = "okay";
};
@@ -64,7 +84,54 @@ Example:
usb30: usb@1127 {
...
- phys = <&phy_port0 PHY_TYPE_USB3>;
- phy-names = "usb3-0";
+ phys = <&u2port0 PHY_TYPE_USB2>, <&u3port0 PHY_TYPE_USB3>;
+ phy-names = "usb2-0", "usb3-0";
...
};
+
+
+Layout differences of banks between mt8173/mt2701 and mt2712
+-
+mt8173 and mt2701:
+portoffsetbank
+shared 0xSPLLC
+0x0100FMREG
+u2 port00x0800U2PHY_COM
+u3 port00x0900U3PHYD
+0x0a00U3PHYD_BANK2
+0x0b00U3PHYA
+0x0c00U3PHYA_DA
+u2 port10x1000U2PHY_COM
+u3 port10x1100U3PHYD
+0x1200U3PHYD_BANK2
+0x1300U3PHYA
+0x1400U3PHYA_DA
+u2 port20x1800U2PHY_COM
+...
+
+mt2712:
+portoffsetbank
+u2 port00xMISC
+0x0100FMREG
+0x0300U2PHY_COM
+u3 port00x0700SPLLC
+0x0800CHIP
+0x0900U3PHYD
+0x0a00U3PHYD_BANK2
+0x0b00U3PHYA
+0x0c00U3PHY
[RESEND PATCH v3 4/8] phy: phy-mt65xx-usb3: move clock from phy node into port nodes
the reference clock of HighSpeed port is 48M which comes from PLL;
the reference clock of SuperSpeed port is 26M which usually comes
from 26M oscillator directly, but some SoCs are not, add it for
compatibility, and put them into port node for flexibility.
Signed-off-by: Chunfeng Yun
---
drivers/phy/phy-mt65xx-usb3.c | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/phy/phy-mt65xx-usb3.c b/drivers/phy/phy-mt65xx-usb3.c
index 7fff482..f4a3505 100644
--- a/drivers/phy/phy-mt65xx-usb3.c
+++ b/drivers/phy/phy-mt65xx-usb3.c
@@ -153,6 +153,7 @@ struct mt65xx_phy_pdata {
struct mt65xx_phy_instance {
struct phy *phy;
void __iomem *port_base;
+ struct clk *ref_clk;/* reference clock of anolog phy */
u32 index;
u8 type;
};
@@ -160,7 +161,6 @@ struct mt65xx_phy_instance {
struct mt65xx_u3phy {
struct device *dev;
void __iomem *sif_base; /* only shared sif */
- struct clk *u3phya_ref; /* reference clock of usb3 anolog phy */
const struct mt65xx_phy_pdata *pdata;
struct mt65xx_phy_instance **phys;
int nphys;
@@ -449,9 +449,9 @@ static int mt65xx_phy_init(struct phy *phy)
struct mt65xx_u3phy *u3phy = dev_get_drvdata(phy->dev.parent);
int ret;
- ret = clk_prepare_enable(u3phy->u3phya_ref);
+ ret = clk_prepare_enable(instance->ref_clk);
if (ret) {
- dev_err(u3phy->dev, "failed to enable u3phya_ref\n");
+ dev_err(u3phy->dev, "failed to enable ref_clk\n");
return ret;
}
@@ -494,7 +494,7 @@ static int mt65xx_phy_exit(struct phy *phy)
if (instance->type == PHY_TYPE_USB2)
phy_instance_exit(u3phy, instance);
- clk_disable_unprepare(u3phy->u3phya_ref);
+ clk_disable_unprepare(instance->ref_clk);
return 0;
}
@@ -594,12 +594,6 @@ static int mt65xx_u3phy_probe(struct platform_device *pdev)
return PTR_ERR(u3phy->sif_base);
}
- u3phy->u3phya_ref = devm_clk_get(dev, "u3phya_ref");
- if (IS_ERR(u3phy->u3phya_ref)) {
- dev_err(dev, "error to get u3phya_ref\n");
- return PTR_ERR(u3phy->u3phya_ref);
- }
-
port = 0;
for_each_child_of_node(np, child_np) {
struct mt65xx_phy_instance *instance;
@@ -634,6 +628,13 @@ static int mt65xx_u3phy_probe(struct platform_device *pdev)
goto put_child;
}
+ instance->ref_clk = devm_clk_get(&phy->dev, "ref");
+ if (IS_ERR(instance->ref_clk)) {
+ dev_err(dev, "failed to get ref_clk(id-%d)\n", port);
+ retval = PTR_ERR(instance->ref_clk);
+ goto put_child;
+ }
+
instance->phy = phy;
instance->index = port;
phy_set_drvdata(phy, instance);
--
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: Panic in quirk_usb_early_handoff
On 06/03/2017 13:42, Mason wrote: > So the kernel panics in xhci_find_next_ext_cap() > ( drivers/usb/host/xhci-ext-caps.h:122 ) > http://lxr.free-electrons.com/source/drivers/usb/host/xhci-ext-caps.h?v=4.9#L122 > > Any idea how this can happen? > > base = ioremap_nocache(pci_resource_start(pdev, 0), len); > > Could I be passing garbage to ioremap_nocache? Oh... I have just now understood what Ard wrote a few days ago. The issue was that, on this platform, the PCI configuration space and memory space are multiplexed; in other words they reside at the same physical address, with a bit in MMIO to choose one or the other. I was specifying an arbitrary address for the memory space, which doesn't make any sense, as Ard pointed out. So quirk_usb_handoff_xhci would ioremap(0x9100, 8192) which is the size of the USB device's memory region, but 0x9100 is an address in system RAM. Thus, the readl was actually picking up random garbage in RAM, which makes xhci_find_next_ext_cap blow up pretty fast. [1.265224] xhci_find_next_ext_cap: offset=0xec44 I'm off to fix my blunder. Regards. -- 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] HID: get rid of HID_QUIRK_NO_INIT_REPORTS
On Mar 06 2017 or thereabouts, Jiri Kosina wrote: > On Thu, 5 Jan 2017, Benjamin Tissoires wrote: > > > For case 1, the hiddev documentation provides an ioctl to do the > > init manually. A solution could be to retrieve the requested report > > when EVIOCGUSAGE is called, in the same way hidraw does. I would be > > tempted to not change the behavior and hope that we won't break any > > userspace tool. > > I'd like to be applying the HID_QUIRK_NO_INIT_REPORTS removal as soon as > possible so that it gets exposure in linux-next over the whole development > cycle. > > I am however too conservative to ignore the potential hiddev breakage, I > am afraid. This has a real potential of breaking systems, and > administrators having hard time figuring out of happened; essentialy, this > is userspace-visible behavior change (regression) for which we haven't > done any long-term depreciation (such as printing a warning "please talk > to your hiddev driver vendor" in case the driver seems to assume > initialized reports) at least for a few years. > > I think that either doing it at a connect time, or during first > EVIOCGUSAGE ioctl() call is a must. Yes, that's what I was thinking to do too. Also, I think we need to keep around the list of currently "quirked" devices for hiddev to work properly. I am still wondering whether we should simply keep the list of quirked devices in hid-core, but disable the effects, or move the full list of quirked devices in hiddev. Initially I thought it was better to remove the quirk from core and move the list in hiddev, but on the other hand, that means that we will remove the ability to introduce it from the kernel boot command, so maybe keeping the list in its current state is better, and only have the effects in hiddev. Am I clear enough?) > > Otherwise, I'd be super-happy to finally get rid of this giant PITA. > Me too! Cheers, Benjamin > Thanks! > > -- > Jiri Kosina > SUSE Labs > -- 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] HID: usbhid: Use pr_ and remove unnecessary OOM messages
On Wed, 1 Mar 2017, Joe Perches wrote: > Use a more common logging style and remove the unnecessary > OOM messages as there is default dump_stack when OOM. > > Miscellanea: > > o Hoist an assignment in an if > o Realign arguments > o Realign a deeply indented if descendent above a printk > > Signed-off-by: Joe Perches Applied to for-4.12/upstream. Thanks, -- Jiri Kosina SUSE Labs -- 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 v17 2/3] usb: USB Type-C connector class
Hi Peter, On Mon, Mar 06, 2017 at 09:15:51AM +0800, Peter Chen wrote: > > > What interface you use when you receive this event to handle > > > dual-role switch? I am wonder if a common dual-role class is > > > needed, then we can have a common user utility. > > > > > > Eg, if "data_role" has changed, the udev can echo "data_role" to > > > /sys/class/usb-dual-role/role > > > > No. If the partner executes successfully for example DR_Swap message, > > the kernel has to take care everything that is needed for the role to > > be what ever was negotiated on its own. User space can't be involved > > with that. > > > > Would you give me an example how kernel handle this? How type-C event > triggers role switch? On our boards, the firmware or EC (or ACPI) configures the hardware as needed and also notifies the components using ACPI if needed. It's often not even possible to directly configure the components/hardware for a particular role. I'm not commenting on Roger's dual role patch series, but I don't really think it should be mixed with Type-C. USB Type-C and USB Power Delivery define their own ways of handling the roles, and they are not limited to the data role only. Things like OTG for example will, and actually can not be supported. With Type-C we will have competing state machines compared to OTG. The dual-role framework may be useful on systems that provide more traditional connectors, which possibly have the ID-pin like micro-AB, and possibly also support OTG. It can also be something that exist in parallel with the Type-C class, but there just can not be any dependencies between the two. Thanks, -- heikki -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v17 2/3] usb: USB Type-C connector class
Hi Mats, On Fri, Mar 03, 2017 at 08:27:08PM +0100, Mats Karrman wrote: > On 2017-03-03 13:59, Heikki Krogerus wrote: > > > On Fri, Mar 03, 2017 at 08:29:18AM +0100, Mats Karrman wrote: > > > > > How would something like that sound to you guys? > > Complicated... Need to marinate on that for a while ;) Sorry about the bad explanation :-). Let me try again.. I'm simply looking for a method that is as scalable as possible to handle the alternate modes, basically how to couple the different components involved. Bus would feel like the best approach at the moment. > > > My system is a bit different. It's an i.MX6 SoC with the typec phy and DP > > > controller connected > > > directly to the SoC and it's using DTB/OF. > > Is this "DP controller" a controller that is capable of taking care of > > the USB Power Delivery communication with the partner regarding > > DisplayPort alternate mode? > > No, the "DP controller" just talks DP and knows nothing about Type-C or USB > PD. > It takes a video stream from the SoC and turns it into a DP link, set up and > orchestrated > by the corresponding driver. And all the driver needs from Type-C is the > plugged in / interrupt / > plugged out events. Got it. > The analog switching between USB / safe / DP signal levels in the Type-C > connector is, I think, > best handled by the software doing the USB PD negotiation / Altmode handling > (using some GPIOs). > > > > Do we need to further standardize attributes under (each) specific > > > alternate mode to > > > include things such as HPD for the DP mode? > > I'm not completely sure what kind of system you have, but I would > > imagine that if we had the bus, your DP controller driver would be the > > port (and partner) alternate mode driver. The bus would bind you to > > the typec phy. > > So, both the DP controller and the USB PD phy are I2C devices, and now I have > to make them both > attach to the AM bus as well? The DP controller would provide the driver and the USB PD phy (actually, the typec class) the device. Would it be a problem to register these I2C devices with some other subsystem, was it extcon or something like AM bus? It really would not be that uncommon. Or have I misunderstood your question? Thanks, -- heikki -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Panic in quirk_usb_early_handoff
On 03/03/2017 20:02, Robin Murphy wrote: > On 03/03/17 17:15, Mason wrote: > [1.264893] Unable to handle kernel paging request at virtual address d08664f4 > > Note that that's a reasonable approximation of a vmalloc address... > [1.272248] pgd = c0004000 [1.275060] [d08664f4] *pgd=8f804811, *pte=, *ppte= [1.281476] Internal error: Oops: 7 [#1] PREEMPT SMP ARM [1.286897] Modules linked in: [1.290053] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.9.7-1-rc2 #151 [1.296696] Hardware name: Sigma Tango DT [1.300808] task: cf82c9c0 task.stack: cf838000 [1.305446] PC is at quirk_usb_early_handoff+0x3e8/0x790 [1.310873] LR is at ioremap_page_range+0xf8/0x1a8 [1.315771] pc : []lr : []psr: 000e0013 [1.315771] sp : cf839d78 ip : fp : cf839e38 [1.327482] r10: c10248a0 r9 : r8 : d08664f4 [1.332816] r7 : d084e000 r6 : 2000 r5 : 000c0300 r4 : cfb5f800 [1.339460] r3 : 000184f4 r2 : r1 : 91001e13 r0 : d084e000 > > ...and that specifically it's r0 + r3... > >>> [1.258926] Unable to handle kernel paging request at virtual address >>> d0863f70 >>> [1.266284] pgd = c0004000 >>> [1.269097] [d0863f70] *pgd=8f804811, *pte=, *ppte= >>> [1.275512] Internal error: Oops: 7 [#1] PREEMPT SMP ARM >>> [1.280933] Modules linked in: >>> [1.284089] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.9.7-1-rc2 #157 >>> [1.290732] Hardware name: Sigma Tango DT >>> [1.294843] task: cf82c9c0 task.stack: cf838000 >>> [1.299482] PC is at quirk_usb_early_handoff+0x3e8/0x790 >>> [1.304907] LR is at ioremap_page_range+0xf8/0x1a8 >>> [1.309806] pc : []lr : []psr: 000e0013 >>> [1.309806] sp : cf839d78 ip : fp : cf839e38 >>> [1.321517] r10: c10248a0 r9 : r8 : d0863f70 >>> [1.326851] r7 : d084e000 r6 : 2000 r5 : 000c0300 r4 : cfb52800 >>> [1.333495] r3 : 00015f70 r2 : r1 : 91001e13 r0 : d084e000 > > ...and again... > >> [1.261813] Unable to handle kernel paging request at virtual address >> d08611e4 >> [1.269167] pgd = c0004000 >> [1.271979] [d08611e4] *pgd=8f804811, *pte=, *ppte= >> [1.278394] Internal error: Oops: 7 [#1] PREEMPT SMP ARM >> [1.283815] Modules linked in: >> [1.286970] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.9.7-1-rc2 #157 >> [1.293614] Hardware name: Sigma Tango DT >> [1.297726] task: cf82c9c0 task.stack: cf838000 >> [1.302364] PC is at quirk_usb_early_handoff+0x3e8/0x790 >> [1.307790] LR is at ioremap_page_range+0xf8/0x1a8 >> [1.312688] pc : []lr : []psr: 000e0013 >> [1.312688] sp : cf839d78 ip : fp : cf839e38 >> [1.324399] r10: c10248a0 r9 : r8 : d08611e4 >> [1.329733] r7 : d084e000 r6 : 2000 r5 : 000c0300 r4 : cfb4e800 >> [1.336377] r3 : 000131e4 r2 : r1 : 91001e13 r0 : d084e000 > > ...and again. And always at the same PC, too. Looking at > quirk_usb_early_handoff(), it mostly seems to go off poking bridge > resources, so I'd hazard a guess that it's down to your host driver, > with something uninitialised (or already freed) being used as an offset > into some ioremapped resource (which given the consistency of r0 is > probably allocated pretty early on). > > "addr2line -i -e vmlinux c039fe44", and work backwards from there ;) > In particular I'd follow the provenance of r3. Starting from a fresh panic: [1.236243] pcieport :00:00.0: enabling device (0140 -> 0142) [1.242474] pcieport :00:00.0: enabling bus mastering [1.248147] pci :01:00.0: calling quirk_usb_early_handoff+0x0/0x790 [1.254904] pci :01:00.0: enabling device (0140 -> 0142) [1.260719] Unable to handle kernel paging request at virtual address d08509f8 [1.268073] pgd = c0004000 [1.270874] [d08509f8] *pgd=8f804811, *pte=, *ppte= [1.277282] Internal error: Oops: 7 [#1] PREEMPT SMP ARM [1.282702] Modules linked in: [1.285858] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.9.7-1-rc2 #2 [1.292327] Hardware name: Sigma Tango DT [1.296438] task: cf82c9c0 task.stack: cf838000 [1.301076] PC is at quirk_usb_early_handoff+0x3e8/0x790 [1.306501] LR is at ioremap_page_range+0xf8/0x1a8 [1.311400] pc : []lr : []psr: 000e0013 [1.311400] sp : cf839d78 ip : fp : cf839e38 [1.323110] r10: c10248a0 r9 : r8 : d08509f8 [1.328444] r7 : d084e000 r6 : 2000 r5 : 000c0300 r4 : cfb5f800 [1.335087] r3 : 29f8 r2 : r1 : 91001e13 r0 : d084e000 [1.341732] Flags: nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none [1.348987] Control: 10c5387d Table: 8faa004a DAC: 0051 [1.354844] Process swapper/0 (pid: 1, stack limit = 0xcf838210) [1.360963] Stack: (0xcf839d78 to 0xcf83
Re: [PATCH] HID: get rid of HID_QUIRK_NO_INIT_REPORTS
On Thu, 5 Jan 2017, Benjamin Tissoires wrote: > For case 1, the hiddev documentation provides an ioctl to do the > init manually. A solution could be to retrieve the requested report > when EVIOCGUSAGE is called, in the same way hidraw does. I would be > tempted to not change the behavior and hope that we won't break any > userspace tool. I'd like to be applying the HID_QUIRK_NO_INIT_REPORTS removal as soon as possible so that it gets exposure in linux-next over the whole development cycle. I am however too conservative to ignore the potential hiddev breakage, I am afraid. This has a real potential of breaking systems, and administrators having hard time figuring out of happened; essentialy, this is userspace-visible behavior change (regression) for which we haven't done any long-term depreciation (such as printing a warning "please talk to your hiddev driver vendor" in case the driver seems to assume initialized reports) at least for a few years. I think that either doing it at a connect time, or during first EVIOCGUSAGE ioctl() call is a must. Otherwise, I'd be super-happy to finally get rid of this giant PITA. Thanks! -- Jiri Kosina SUSE Labs -- 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: VL805 USB 3.0 does not see connected devices (only on x86_64) (x86 is ok)
Am Freitag, den 24.02.2017, 16:41 +0300 schrieb c400: > when i disable IOMMU -> "Enable Intel DMA Remapping Device by > default" > the USB flash drive becomes completely invisible. > Same stuff when i completely disable recompile kernel without IOMMU The DMA map for the device seems to be incorrect. Try limiting mem to 2GB on the kernel command line. 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 00/21] USB: serial: refactor endpoint sanity checks
On Mon, Mar 06, 2017 at 10:54:44AM +0100, Oliver Neukum wrote: > Am Montag, den 06.03.2017, 10:23 +0100 schrieb Johan Hovold: > > [ +CC: Greg ] > > > > On Fri, Mar 03, 2017 at 07:29:02PM +0100, Oliver Neukum wrote: > > > > > > Am Donnerstag, den 02.03.2017, 12:51 +0100 schrieb Johan Hovold: > > > > > > > > This series refactors the endpoint sanity checks by allowing > > > > subdrivers > > > > to specify a minimum number of endpoints required per type and > > > > letting > > > > core verify this during probe. > > > > > > Hi, > > > > > > this is very good, but is it at the right place? I see nothing > > > specific to serial drivers here. > > > > There are some usb-serial specifics here, most notably that the > > constraints are specified per usb-serial type (driver) of which there > > can be several per usb driver, and all with different ports counts > > and varying endpoint requirements. > > Yes, it would be wrong to see this as an attribute per driver. > It needs to apply when you match. AFAICS every serial subdriver > has a device table. Requirements need to go there. Every USB-serial-bus driver has a device table, but devices are matched against these tables by USB-serial core and not USB core. And then there's also a "combined" device table, for all USB-serial bus drivers implemented by the same USB interface driver. Are you suggesting the requirements should be specified per device, rather than per driver (device table)? That does not seem right to me, as it is really the driver which needs to verify the resources it needs for its implementation (e.g. before allocating a read urb). This means that all devices in a table would have the same (minimum) constraints anyway. So I do think this should be a driver attribute, but in the USB-serial case, several classes of devices can be handled by the same USB driver, so the constraints then needs to be specified at the USB-serial-bus driver level instead. > > As mentioned in the cover letter, a follow-on series will also use > > the descriptor arrays to allow subdrivers to manipulate the > > port-endpoint mapping. We have a couple of driver for which a single > > endpoint pair is shared, but bulk-out resources are allocated per > > port anyway. To be able to get rid of some related hacks, the array > > sizes are therefore large enough to express such mappings rather > > than having 15 elements each (i.e. the maximum number of in or out > > endpoints). > > Yes, but could you explain how this is connected to filtering at probe > time other than happening at probe time? Only in that this functionality will still be needed in USB-serial to implement the port-endpoint remap functionality even if USB core were to gain something similar. > > Also note that the constraints are verified only after the subdriver > > probe callback returns (but before calc_num_ports and attach) > > allowing the drivers to change altsettings, download firmware, etc, > > before verifying that the endpoints required for normal operation > > are present. > > True, but again not specific to serial drivers. DVB-T will face > the same issues. Certainly, and I should have elaborated a bit more on the differences here. For USB-serial endpoint-resources are allocated only after subdriver probe returns, while for most (all) other USB driver this would need to be done in the USB probe callback directly. In that case, checking before probe might be too soon (fw download, altsetting) and checking after would be too late (endpoint resources would already need to have been setup). > > Now, something similar to this could be added to USB core as well, > > and I believe Greg have been looking into that lately (as time > > permitted). But given the varying subdriver constraints, and the > > need for port- endpoint remapping, we'd still need these checks and > > features in USB serial. > > It looks like a duplicated effort to me and your code can already do > most of the job. Just add a flag to check the requirements after > probe() I realise that it may look like a duplicated effort, but I really don't think it is for the reasons given in this thread. This does not mean that for some USB-serial drivers, some of these checks could be taken care of by USB core later (e.g. when the endpoint constraints are the same for all device classes managed by a USB-serial driver). Johan -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Cannot dump USB report descriptors, not even after unbinding the device
Hi, On 03/03/2017 09:48 PM, Alan Stern wrote: On Fri, 3 Mar 2017, László Monda wrote: Hi Krzysztof, and thank you for the help! Oh now I see. I missed this when I was reading this email for the first time. root@spark ~ # echo -n 2-10.3 > /sys/bus/usb/drivers/usb/unbind You are trying to unbind here wrong driver I think. Try to unbound driver for interface instead of for whole device: # echo -n 2-10.3:1.0 > /sys/bus/usb/drivers/usb/unbind I've tried to unbind 2-10.3:[0-4].[0-4] but bash always tells me that there's no such device. Krzysztof told you the wrong driver. You should do: echo 2-10.3:1.0 >/sys/bus/usb/drivers/usbhid/unbind (the -n doesn't matter). Thank you Alan for catching this! I've copy-pasted the path from above and forgot to fix driver name. Unfortunately I did the same mistake in my second response. Please excuse me Laszlo for this oversight. Cheers, -- Krzysztof Opasiak Samsung R&D Institute Poland Samsung Electronics -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/21] USB: serial: refactor endpoint sanity checks
Am Montag, den 06.03.2017, 10:23 +0100 schrieb Johan Hovold: > [ +CC: Greg ] > > On Fri, Mar 03, 2017 at 07:29:02PM +0100, Oliver Neukum wrote: > > > > Am Donnerstag, den 02.03.2017, 12:51 +0100 schrieb Johan Hovold: > > > > > > This series refactors the endpoint sanity checks by allowing > > > subdrivers > > > to specify a minimum number of endpoints required per type and > > > letting > > > core verify this during probe. > > > > Hi, > > > > this is very good, but is it at the right place? I see nothing > > specific to serial drivers here. > > There are some usb-serial specifics here, most notably that the > constraints are specified per usb-serial type (driver) of which there > can be several per usb driver, and all with different ports counts > and > varying endpoint requirements. Yes, it would be wrong to see this as an attribute per driver. It needs to apply when you match. AFAICS every serial subdriver has a device table. Requirements need to go there. > As mentioned in the cover letter, a follow-on series will also use > the > descriptor arrays to allow subdrivers to manipulate the port-endpoint > mapping. We have a couple of driver for which a single endpoint pair > is > shared, but bulk-out resources are allocated per port anyway. To be > able > to get rid of some related hacks, the array sizes are therefore large > enough to express such mappings rather than having 15 elements each > (i.e. the maximum number of in or out endpoints). Yes, but could you explain how this is connected to filtering at probe time other than happening at probe time? > Also note that the constraints are verified only after the subdriver > probe > callback returns (but before calc_num_ports and attach) allowing the > drivers to change altsettings, download firmware, etc, before > verifying > that the endpoints required for normal operation are present. True, but again not specific to serial drivers. DVB-T will face the same issues. > Now, something similar to this could be added to USB core as well, > and I > believe Greg have been looking into that lately (as time permitted). > But > given the varying subdriver constraints, and the need for port- > endpoint > remapping, we'd still need these checks and features in USB serial. It looks like a duplicated effort to me and your code can already do most of the job. Just add a flag to check the requirements after probe() 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: query on UCSI
On Mon, Mar 06, 2017 at 02:41:17PM +0530, Shah, Nehal-bakulchandra wrote: > Hi Greg and Heikki, > > > I can see that ucsi acpi interface driver is available in kernel tree. I have > following queries on the same. Kindly pardon my ignorance as i am a novice to > this. > > - Is there any implementation of USB-C system policy manager (OPM) in > Linux? Merged into the kernel.org tree? Not yet, see the patches on this mailing list for the latest implementation that should get merged into 4.12. > - If yes to USB-C system policy, are there any requirements that > differ from the published Intel White paper on UCSI support through > ACPI Mailbox method? (Link: > http://www.intel.com/content/dam/www/public/us/en/documents/white-papers/bios-implementation-of-ucsi.pdf > ) See the patches for the details on this. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/21] USB: serial: refactor endpoint sanity checks
[ +CC: Greg ] On Fri, Mar 03, 2017 at 07:29:02PM +0100, Oliver Neukum wrote: > Am Donnerstag, den 02.03.2017, 12:51 +0100 schrieb Johan Hovold: > > This series refactors the endpoint sanity checks by allowing > > subdrivers > > to specify a minimum number of endpoints required per type and > > letting > > core verify this during probe. > > Hi, > > this is very good, but is it at the right place? I see nothing > specific to serial drivers here. There are some usb-serial specifics here, most notably that the constraints are specified per usb-serial type (driver) of which there can be several per usb driver, and all with different ports counts and varying endpoint requirements. As mentioned in the cover letter, a follow-on series will also use the descriptor arrays to allow subdrivers to manipulate the port-endpoint mapping. We have a couple of driver for which a single endpoint pair is shared, but bulk-out resources are allocated per port anyway. To be able to get rid of some related hacks, the array sizes are therefore large enough to express such mappings rather than having 15 elements each (i.e. the maximum number of in or out endpoints). Also note that the constraints are verified only after the subdriver probe callback returns (but before calc_num_ports and attach) allowing the drivers to change altsettings, download firmware, etc, before verifying that the endpoints required for normal operation are present. Now, something similar to this could be added to USB core as well, and I believe Greg have been looking into that lately (as time permitted). But given the varying subdriver constraints, and the need for port-endpoint remapping, we'd still need these checks and features in USB serial. Thanks, Johan -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v17 2/3] usb: USB Type-C connector class
Am Freitag, den 03.03.2017, 20:27 +0100 schrieb Mats Karrman: > On 2017-03-03 13:59, Heikki Krogerus wrote: > > > > > On Fri, Mar 03, 2017 at 08:29:18AM +0100, Mats Karrman wrote: > > > > > > > How would something like that sound to you guys? > > Complicated... Need to marinate on that for a while ;) The thing is that a type C plug has operations that affect every device on it and need to be synchronized. Reset and power requirements would be the obvious examples. It seems to me that the natural way to represent this is a bus. Like SCSI where you have a bus reset operation. 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 03/21] USB: serial: refactor and clean up endpoint handling
On Mon, Mar 06, 2017 at 10:27:09AM +0100, Johan Hovold wrote:
> On Sat, Mar 04, 2017 at 02:21:28AM +0800, kbuild test robot wrote:
> > Hi Johan,
> >
> > [auto build test WARNING on usb/usb-testing]
> > [also build test WARNING on v4.10 next-20170303]
> > [if your patch is applied to the wrong git tree, please drop us a note to
> > help improve the system]
> >
> > url:
> > https://github.com/0day-ci/linux/commits/Johan-Hovold/USB-serial-refactor-endpoint-sanity-checks/20170303-232312
> > base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
> > usb-testing
> > config: x86_64-randconfig-s0-03040020 (attached as .config)
> > compiler: gcc-4.4 (Debian 4.4.7-8) 4.4.7
> > reproduce:
> > # save the attached .config to linux build tree
> > make ARCH=x86_64
> >
> > All warnings (new ones prefixed by >>):
> >
> >drivers/usb/serial/usb-serial.c: In function 'usb_serial_probe':
> >drivers/usb/serial/usb-serial.c:1088: warning: label 'err_free_epds'
> > defined but not used
> > >> drivers/usb/serial/usb-serial.c:767: warning: unused variable
> > >> 'iface_desc'
>
> Ah, both of these warning only show up when neither
> CONFIG_USB_SERIAL_PL2303 or CONFIG_USB_SERIAL_GENERIC is selected. Both
> of these conditionally compile sections will be removed by a follow-on
> series, but I'll respin this one to get rid of the warning in this
> configuration nonetheless.
So I've fixed this up by moving the descriptor pointer to the
conditionally compiled section, and by not adding the new error label
until a later patch in this series that needs it unconditionally.
The resulting diff of this change is below, but I don't think I need to
repost the whole series unless further changes are needed.
Johan
diff --git a/drivers/usb/serial/usb-serial.c b/drivers/usb/serial/usb-serial.c
index 68af8054..09eb639298c8 100644
--- a/drivers/usb/serial/usb-serial.c
+++ b/drivers/usb/serial/usb-serial.c
@@ -764,7 +764,6 @@ static int usb_serial_probe(struct usb_interface *interface,
struct usb_device *dev = interface_to_usbdev(interface);
struct usb_serial *serial = NULL;
struct usb_serial_port *port;
- struct usb_host_interface *iface_desc;
struct usb_endpoint_descriptor *endpoint;
struct usb_serial_endpoints *epds;
struct usb_serial_driver *type = NULL;
@@ -830,6 +829,8 @@ static int usb_serial_probe(struct usb_interface *interface,
((le16_to_cpu(dev->descriptor.idVendor) == SIEMENS_VENDOR_ID) &&
(le16_to_cpu(dev->descriptor.idProduct) ==
SIEMENS_PRODUCT_ID_EF81))) {
if (interface != dev->actconfig->interface[0]) {
+ struct usb_host_interface *iface_desc;
+
/* check out the endpoints of the other interface*/
iface_desc =
dev->actconfig->interface[0]->cur_altsetting;
for (i = 0; i < iface_desc->desc.bNumEndpoints; ++i) {
@@ -850,7 +851,8 @@ static int usb_serial_probe(struct usb_interface *interface,
if (epds->num_bulk_in == 0 || epds->num_bulk_out == 0) {
dev_info(ddev, "PL-2303 hack: descriptors matched but
endpoints did not\n");
retval = -ENODEV;
- goto err_free_epds;
+ kfree(epds);
+ goto err_put_serial;
}
}
/* END HORRIBLE HACK FOR PL2303 */
@@ -862,7 +864,8 @@ static int usb_serial_probe(struct usb_interface *interface,
if (num_ports == 0) {
dev_err(ddev, "Generic device with no bulk out, not
allowed.\n");
retval = -EIO;
- goto err_free_epds;
+ kfree(epds);
+ goto err_put_serial;
}
dev_info(ddev, "The \"generic\" usb-serial driver is only for
testing and one-off prototypes.\n");
dev_info(ddev, "Tell linux-usb@vger.kernel.org to add your
device to a proper driver.\n");
@@ -1085,8 +1088,6 @@ static int usb_serial_probe(struct usb_interface
*interface,
probe_error:
retval = -EIO;
-err_free_epds:
- kfree(epds);
err_put_serial:
usb_serial_put(serial);
err_put_module:
--
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: Question: Does usbip support USB 3.0?
On Mon, Mar 06, 2017 at 09:02:11AM +0800, Yuyang Du wrote: > Hi Greg, > > On Thu, Feb 23, 2017 at 08:51:03AM +0100, Greg KH wrote: > > And again, what specifically are you referring to, and again, have you > > tried the code out yourself? What is preventing you from testing this > > in your environment to determine if it works properly for you or not? > > I did the experiment. Our device "requires" that the SUPER_SPPED be used. > So, we are attempting to add SUPER_SPEED support to usbip. To assess the > effort, could you please give us some pointers on how to do it? And what > are the difficulties? As others have pointed out, you will have to change the code to do this, and it will be easier if you only need a speed change, and not streams. But why do you really need a speed indicator? What happens if you just report that the device is "high speed" to the host instead? It should not affect the transmit speeds, right? Also, there is code within Intel for the USB-over-IP standard implementation that should work for this type of device. I thought people were working on cleaning it up for submission to the kernel tree, but I haven't seen it in months. You should dig in the archives for it, and work with those developers to get it merged properly, as it should resolve your issues. Hope this helps, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] HID: usbhid: Use pr_ and remove unnecessary OOM messages
On Mar 01 2017 or thereabouts, Joe Perches wrote:
> Use a more common logging style and remove the unnecessary
> OOM messages as there is default dump_stack when OOM.
>
> Miscellanea:
>
> o Hoist an assignment in an if
> o Realign arguments
> o Realign a deeply indented if descendent above a printk
>
> Signed-off-by: Joe Perches
Looks good to me:
Reviewed-by: Benjamin Tissoires
Cheers,
Benjamin
> ---
> drivers/hid/usbhid/hid-core.c | 16 +++-
> drivers/hid/usbhid/hid-quirks.c | 11 ---
> 2 files changed, 11 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c
> index 961bc6fdd2d9..cd98db6cf94f 100644
> --- a/drivers/hid/usbhid/hid-core.c
> +++ b/drivers/hid/usbhid/hid-core.c
> @@ -1004,10 +1004,9 @@ static int usbhid_parse(struct hid_device *hid)
> return -EINVAL;
> }
>
> - if (!(rdesc = kmalloc(rsize, GFP_KERNEL))) {
> - dbg_hid("couldn't allocate rdesc memory\n");
> + rdesc = kmalloc(rsize, GFP_KERNEL);
> + if (!rdesc)
> return -ENOMEM;
> - }
>
> hid_set_idle(dev, interface->desc.bInterfaceNumber, 0, 0);
>
> @@ -1077,8 +1076,8 @@ static int usbhid_start(struct hid_device *hid)
> if (hid->quirks & HID_QUIRK_FULLSPEED_INTERVAL &&
> dev->speed == USB_SPEED_HIGH) {
> interval = fls(endpoint->bInterval*8);
> - printk(KERN_INFO "%s: Fixing fullspeed to highspeed
> interval: %d -> %d\n",
> -hid->name, endpoint->bInterval, interval);
> + pr_info("%s: Fixing fullspeed to highspeed interval: %d
> -> %d\n",
> + hid->name, endpoint->bInterval, interval);
> }
>
> /* Change the polling interval of mice. */
> @@ -1456,10 +1455,9 @@ static int hid_post_reset(struct usb_interface *intf)
>* the size of the HID report descriptor has not changed.
>*/
> rdesc = kmalloc(hid->dev_rsize, GFP_KERNEL);
> - if (!rdesc) {
> - dbg_hid("couldn't allocate rdesc memory (post_reset)\n");
> + if (!rdesc)
> return -ENOMEM;
> - }
> +
> status = hid_get_class_descriptor(dev,
> interface->desc.bInterfaceNumber,
> HID_DT_REPORT, rdesc, hid->dev_rsize);
> @@ -1637,7 +1635,7 @@ static int __init hid_init(void)
> retval = usb_register(&hid_driver);
> if (retval)
> goto usb_register_fail;
> - printk(KERN_INFO KBUILD_MODNAME ": " DRIVER_DESC "\n");
> + pr_info(KBUILD_MODNAME ": " DRIVER_DESC "\n");
>
> return 0;
> usb_register_fail:
> diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/usbhid/hid-quirks.c
> index d6847a664446..9287ab03e117 100644
> --- a/drivers/hid/usbhid/hid-quirks.c
> +++ b/drivers/hid/usbhid/hid-quirks.c
> @@ -237,10 +237,8 @@ static int usbhid_modify_dquirk(const u16 idVendor,
> const u16 idProduct,
> }
>
> q_new = kmalloc(sizeof(struct quirks_list_struct), GFP_KERNEL);
> - if (!q_new) {
> - dbg_hid("Could not allocate quirks_list_struct\n");
> + if (!q_new)
> return -ENOMEM;
> - }
>
> q_new->hid_bl_item.idVendor = idVendor;
> q_new->hid_bl_item.idProduct = idProduct;
> @@ -306,10 +304,9 @@ int usbhid_quirks_init(char **quirks_param)
> &idVendor, &idProduct, &quirks);
>
> if (m != 3 ||
> - usbhid_modify_dquirk(idVendor, idProduct,
> quirks) != 0) {
> - printk(KERN_WARNING
> - "Could not parse HID quirk module param
> %s\n",
> - quirks_param[n]);
> + usbhid_modify_dquirk(idVendor, idProduct, quirks) != 0) {
> + pr_warn("Could not parse HID quirk module param %s\n",
> + quirks_param[n]);
> }
> }
>
> --
> 2.10.0.rc2.1.g053435c
>
--
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
