Re: [PATCH 0/2] *** SUBJECT HERE ***
On Fri, Apr 16, 2021 at 04:07:54PM +0800, Tao Zhang wrote: > *** BLURB HERE *** Where is the blurb? And your subject is not ok :(
[PATCH 0/2] *** SUBJECT HERE ***
*** BLURB HERE *** Tao Zhang (2): coresight: Add support for device names dt-bindings: arm: add property for coresight component name Documentation/devicetree/bindings/arm/coresight.txt | 2 ++ drivers/hwtracing/coresight/coresight-core.c| 6 ++ 2 files changed, 8 insertions(+) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH 0/2] *** SUBJECT HERE ***
*** BLURB HERE *** Andrew Pinski (2): ARM64:VDSO: Improve gettimeofday, don't use udiv ARM64:VDSO: Improve __do_get_tspec, don't use udiv arch/arm64/kernel/vdso/gettimeofday.S | 47 1 files changed, 35 insertions(+), 12 deletions(-) -- 1.7.2.5
[PATCH 0/2] *** SUBJECT HERE ***
*** BLURB HERE *** Andrew Pinski (2): ARM64:VDSO: Improve gettimeofday, don't use udiv ARM64:VDSO: Improve __do_get_tspec, don't use udiv arch/arm64/kernel/vdso/gettimeofday.S | 47 1 files changed, 35 insertions(+), 12 deletions(-) -- 1.7.2.5
Re: [PATCH 0/2] *** SUBJECT HERE ***
On Tue, Jul 02, 2013 at 01:22:01AM +0200, Anders Hammarquist wrote: > In a message of Fri, 28 Jun 2013 12:23:33 +0200, Johan Hovold writes: > >> I did a quick check of adding the device id though sysfs, and although > >> it partly works, it doesn't find the correct firmware (it ends up trying > >> to load 5052 firmware for a 3410 device. Looking at the code it seems > >> (struct ti_device) td_is_3410 isn't set properly.) > > > >Turns out that the drivers device-type detection has never worked with > >the dynamic id interface (all devices were detected as 2-port devices). > > > >I'm responding to this mail with a fix. Care to give it a try? > > Yes, this works fine. Thanks for testing. Johan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] *** SUBJECT HERE ***
On Tue, Jul 02, 2013 at 01:22:01AM +0200, Anders Hammarquist wrote: In a message of Fri, 28 Jun 2013 12:23:33 +0200, Johan Hovold writes: I did a quick check of adding the device id though sysfs, and although it partly works, it doesn't find the correct firmware (it ends up trying to load 5052 firmware for a 3410 device. Looking at the code it seems (struct ti_device) td_is_3410 isn't set properly.) Turns out that the drivers device-type detection has never worked with the dynamic id interface (all devices were detected as 2-port devices). I'm responding to this mail with a fix. Care to give it a try? Yes, this works fine. Thanks for testing. Johan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] *** SUBJECT HERE ***
In a message of Fri, 28 Jun 2013 12:23:33 +0200, Johan Hovold writes: >> I did a quick check of adding the device id though sysfs, and although >> it partly works, it doesn't find the correct firmware (it ends up trying >> to load 5052 firmware for a 3410 device. Looking at the code it seems >> (struct ti_device) td_is_3410 isn't set properly.) > >Turns out that the drivers device-type detection has never worked with >the dynamic id interface (all devices were detected as 2-port devices). > >I'm responding to this mail with a fix. Care to give it a try? Yes, this works fine. /Anders -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] *** SUBJECT HERE ***
In a message of Fri, 28 Jun 2013 12:23:33 +0200, Johan Hovold writes: I did a quick check of adding the device id though sysfs, and although it partly works, it doesn't find the correct firmware (it ends up trying to load 5052 firmware for a 3410 device. Looking at the code it seems (struct ti_device) td_is_3410 isn't set properly.) Turns out that the drivers device-type detection has never worked with the dynamic id interface (all devices were detected as 2-port devices). I'm responding to this mail with a fix. Care to give it a try? Yes, this works fine. /Anders -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] *** SUBJECT HERE ***
On Thu, Jun 27, 2013 at 11:50:52PM +0200, Anders Hammarquist wrote: > In a message of Wed, 26 Jun 2013 12:39:24 +0200, Johan Hovold writes: > >On Wed, Jun 26, 2013 at 10:29:59AM +0200, Anders Hammarquist wrote: > >> In a message of Tue, 25 Jun 2013 16:39:11 -0700, Greg KH writes: > >> >> Indeed. I'd already had some (failed) thoughts about how to handle it > >> >> nicely. Now I've had another think through, and I have something which > >> >> deals with it and at least complains if TI_EXTRA_VID_PID_COUNT is > >> >> changed > >> >> without changing the initializer. Patch 2/2 > >> > > >> >Why don't we just drop the extra id thing entirely? The usb-serial > >> >subsystem handles new device ids being added dynamically from sysfs for > >> >a long time now. Removing this module option would clean up the code a > >> >lot, and prevent these errors from ever happening again. > >> > >> Aha, yes, I'm all for that (had I only known I'd have done that to start > >> with). I'll look in to it. > > > >I already have a few patches here (part of a larger 3.11 clean-up series) > >which removes the vid/pid module parameters from all usb-serial modules > >including ti_usb_3410_5052. > > > >I hope to be able to submit the whole series a later tonight, but here's > >the ti_usb_3410_5052 part if anyone's interested. > > I did a quick check of adding the device id though sysfs, and although > it partly works, it doesn't find the correct firmware (it ends up trying > to load 5052 firmware for a 3410 device. Looking at the code it seems > (struct ti_device) td_is_3410 isn't set properly.) Turns out that the drivers device-type detection has never worked with the dynamic id interface (all devices were detected as 2-port devices). I'm responding to this mail with a fix. Care to give it a try? Thanks, Johan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] *** SUBJECT HERE ***
On Thu, Jun 27, 2013 at 11:50:52PM +0200, Anders Hammarquist wrote: In a message of Wed, 26 Jun 2013 12:39:24 +0200, Johan Hovold writes: On Wed, Jun 26, 2013 at 10:29:59AM +0200, Anders Hammarquist wrote: In a message of Tue, 25 Jun 2013 16:39:11 -0700, Greg KH writes: Indeed. I'd already had some (failed) thoughts about how to handle it nicely. Now I've had another think through, and I have something which deals with it and at least complains if TI_EXTRA_VID_PID_COUNT is changed without changing the initializer. Patch 2/2 Why don't we just drop the extra id thing entirely? The usb-serial subsystem handles new device ids being added dynamically from sysfs for a long time now. Removing this module option would clean up the code a lot, and prevent these errors from ever happening again. Aha, yes, I'm all for that (had I only known I'd have done that to start with). I'll look in to it. I already have a few patches here (part of a larger 3.11 clean-up series) which removes the vid/pid module parameters from all usb-serial modules including ti_usb_3410_5052. I hope to be able to submit the whole series a later tonight, but here's the ti_usb_3410_5052 part if anyone's interested. I did a quick check of adding the device id though sysfs, and although it partly works, it doesn't find the correct firmware (it ends up trying to load 5052 firmware for a 3410 device. Looking at the code it seems (struct ti_device) td_is_3410 isn't set properly.) Turns out that the drivers device-type detection has never worked with the dynamic id interface (all devices were detected as 2-port devices). I'm responding to this mail with a fix. Care to give it a try? Thanks, Johan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] *** SUBJECT HERE ***
In a message of Wed, 26 Jun 2013 12:39:24 +0200, Johan Hovold writes: >On Wed, Jun 26, 2013 at 10:29:59AM +0200, Anders Hammarquist wrote: >> In a message of Tue, 25 Jun 2013 16:39:11 -0700, Greg KH writes: >> >> Indeed. I'd already had some (failed) thoughts about how to handle it >> >> nicely. Now I've had another think through, and I have something which >> >> deals with it and at least complains if TI_EXTRA_VID_PID_COUNT is changed >> >> without changing the initializer. Patch 2/2 >> > >> >Why don't we just drop the extra id thing entirely? The usb-serial >> >subsystem handles new device ids being added dynamically from sysfs for >> >a long time now. Removing this module option would clean up the code a >> >lot, and prevent these errors from ever happening again. >> >> Aha, yes, I'm all for that (had I only known I'd have done that to start >> with). I'll look in to it. > >I already have a few patches here (part of a larger 3.11 clean-up series) >which removes the vid/pid module parameters from all usb-serial modules >including ti_usb_3410_5052. > >I hope to be able to submit the whole series a later tonight, but here's >the ti_usb_3410_5052 part if anyone's interested. I did a quick check of adding the device id though sysfs, and although it partly works, it doesn't find the correct firmware (it ends up trying to load 5052 firmware for a 3410 device. Looking at the code it seems (struct ti_device) td_is_3410 isn't set properly.) I can take a stab at fixing it in the next few days. /Anders -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] *** SUBJECT HERE ***
In a message of Wed, 26 Jun 2013 12:39:24 +0200, Johan Hovold writes: On Wed, Jun 26, 2013 at 10:29:59AM +0200, Anders Hammarquist wrote: In a message of Tue, 25 Jun 2013 16:39:11 -0700, Greg KH writes: Indeed. I'd already had some (failed) thoughts about how to handle it nicely. Now I've had another think through, and I have something which deals with it and at least complains if TI_EXTRA_VID_PID_COUNT is changed without changing the initializer. Patch 2/2 Why don't we just drop the extra id thing entirely? The usb-serial subsystem handles new device ids being added dynamically from sysfs for a long time now. Removing this module option would clean up the code a lot, and prevent these errors from ever happening again. Aha, yes, I'm all for that (had I only known I'd have done that to start with). I'll look in to it. I already have a few patches here (part of a larger 3.11 clean-up series) which removes the vid/pid module parameters from all usb-serial modules including ti_usb_3410_5052. I hope to be able to submit the whole series a later tonight, but here's the ti_usb_3410_5052 part if anyone's interested. I did a quick check of adding the device id though sysfs, and although it partly works, it doesn't find the correct firmware (it ends up trying to load 5052 firmware for a 3410 device. Looking at the code it seems (struct ti_device) td_is_3410 isn't set properly.) I can take a stab at fixing it in the next few days. /Anders -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] *** SUBJECT HERE ***
On Wed, Jun 26, 2013 at 10:29:59AM +0200, Anders Hammarquist wrote:
> In a message of Tue, 25 Jun 2013 16:39:11 -0700, Greg KH writes:
> >> Indeed. I'd already had some (failed) thoughts about how to handle it
> >> nicely. Now I've had another think through, and I have something which
> >> deals with it and at least complains if TI_EXTRA_VID_PID_COUNT is changed
> >> without changing the initializer. Patch 2/2
> >
> >Why don't we just drop the extra id thing entirely? The usb-serial
> >subsystem handles new device ids being added dynamically from sysfs for
> >a long time now. Removing this module option would clean up the code a
> >lot, and prevent these errors from ever happening again.
>
> Aha, yes, I'm all for that (had I only known I'd have done that to start
> with). I'll look in to it.
I already have a few patches here (part of a larger 3.11 clean-up series)
which removes the vid/pid module parameters from all usb-serial modules
including ti_usb_3410_5052.
I hope to be able to submit the whole series a later tonight, but here's
the ti_usb_3410_5052 part if anyone's interested.
Thanks,
Johan
From: Johan Hovold
Subject: [PATCH] USB: ti_usb_3410_5052: remove vendor/product module parameters
Remove the vendor and product module parameters which were added a long
time ago when we did not have the dynamic sysfs interface to add
new device ids (and which isn't limited to five new vid/pid pair).
A vid/pid pair can be added dynamically using sysfs, for example:
echo 0451 1234 >/sys/bus/usb-serial/drivers/ti_usb_3410_5052_1/new_id
for 1-port adapters, or
echo 0451 1234 >/sys/bus/usb-serial/drivers/ti_usb_3410_5052_2/new_id
for 2-port adapters.
Signed-off-by: Johan Hovold
---
drivers/usb/serial/ti_usb_3410_5052.c | 72 ---
1 file changed, 7 insertions(+), 65 deletions(-)
diff --git a/drivers/usb/serial/ti_usb_3410_5052.c
b/drivers/usb/serial/ti_usb_3410_5052.c
index f3e21f5..5585b20 100644
--- a/drivers/usb/serial/ti_usb_3410_5052.c
+++ b/drivers/usb/serial/ti_usb_3410_5052.c
@@ -141,20 +141,9 @@ static int ti_download_firmware(struct ti_device *tdev);
/* module parameters */
static int closing_wait = TI_DEFAULT_CLOSING_WAIT;
-static ushort vendor_3410[TI_EXTRA_VID_PID_COUNT];
-static unsigned int vendor_3410_count;
-static ushort product_3410[TI_EXTRA_VID_PID_COUNT];
-static unsigned int product_3410_count;
-static ushort vendor_5052[TI_EXTRA_VID_PID_COUNT];
-static unsigned int vendor_5052_count;
-static ushort product_5052[TI_EXTRA_VID_PID_COUNT];
-static unsigned int product_5052_count;
/* supported devices */
-/* the array dimension is the number of default entries plus */
-/* TI_EXTRA_VID_PID_COUNT user defined entries plus 1 terminating */
-/* null entry */
-static struct usb_device_id ti_id_table_3410[15+TI_EXTRA_VID_PID_COUNT+1] = {
+static struct usb_device_id ti_id_table_3410[] = {
{ USB_DEVICE(TI_VENDOR_ID, TI_3410_PRODUCT_ID) },
{ USB_DEVICE(TI_VENDOR_ID, TI_3410_EZ430_ID) },
{ USB_DEVICE(MTS_VENDOR_ID, MTS_GSM_NO_FW_PRODUCT_ID) },
@@ -171,16 +160,18 @@ static struct usb_device_id
ti_id_table_3410[15+TI_EXTRA_VID_PID_COUNT+1] = {
{ USB_DEVICE(ABBOTT_VENDOR_ID, ABBOTT_STEREO_PLUG_ID) },
{ USB_DEVICE(ABBOTT_VENDOR_ID, ABBOTT_STRIP_PORT_ID) },
{ USB_DEVICE(TI_VENDOR_ID, FRI2_PRODUCT_ID) },
+ { } /* terminator */
};
-static struct usb_device_id ti_id_table_5052[5+TI_EXTRA_VID_PID_COUNT+1] = {
+static struct usb_device_id ti_id_table_5052[] = {
{ USB_DEVICE(TI_VENDOR_ID, TI_5052_BOOT_PRODUCT_ID) },
{ USB_DEVICE(TI_VENDOR_ID, TI_5152_BOOT_PRODUCT_ID) },
{ USB_DEVICE(TI_VENDOR_ID, TI_5052_EEPROM_PRODUCT_ID) },
{ USB_DEVICE(TI_VENDOR_ID, TI_5052_FIRMWARE_PRODUCT_ID) },
+ { } /* terminator */
};
-static struct usb_device_id
ti_id_table_combined[19+2*TI_EXTRA_VID_PID_COUNT+1] = {
+static struct usb_device_id ti_id_table_combined[] = {
{ USB_DEVICE(TI_VENDOR_ID, TI_3410_PRODUCT_ID) },
{ USB_DEVICE(TI_VENDOR_ID, TI_3410_EZ430_ID) },
{ USB_DEVICE(MTS_VENDOR_ID, MTS_GSM_NO_FW_PRODUCT_ID) },
@@ -200,7 +191,7 @@ static struct usb_device_id
ti_id_table_combined[19+2*TI_EXTRA_VID_PID_COUNT+1]
{ USB_DEVICE(IBM_VENDOR_ID, IBM_454C_PRODUCT_ID) },
{ USB_DEVICE(ABBOTT_VENDOR_ID, ABBOTT_PRODUCT_ID) },
{ USB_DEVICE(TI_VENDOR_ID, FRI2_PRODUCT_ID) },
- { }
+ { } /* terminator */
};
static struct usb_serial_driver ti_1port_device = {
@@ -289,61 +280,12 @@ module_param(closing_wait, int, S_IRUGO | S_IWUSR);
MODULE_PARM_DESC(closing_wait,
"Maximum wait for data to drain in close, in .01 secs, default is 4000");
-module_param_array(vendor_3410, ushort, _3410_count, S_IRUGO);
-MODULE_PARM_DESC(vendor_3410,
- "Vendor ids for 3410 based devices, 1-5 short integers");
-module_param_array(product_3410, ushort, _3410_count, S_IRUGO);
-MODULE_PARM_DESC(product_3410,
-
Re: [PATCH 0/2] *** SUBJECT HERE ***
In a message of Tue, 25 Jun 2013 16:39:11 -0700, Greg KH writes: >> Indeed. I'd already had some (failed) thoughts about how to handle it >> nicely. Now I've had another think through, and I have something which >> deals with it and at least complains if TI_EXTRA_VID_PID_COUNT is changed >> without changing the initializer. Patch 2/2 > >Why don't we just drop the extra id thing entirely? The usb-serial >subsystem handles new device ids being added dynamically from sysfs for >a long time now. Removing this module option would clean up the code a >lot, and prevent these errors from ever happening again. Aha, yes, I'm all for that (had I only known I'd have done that to start with). I'll look in to it. /Anders -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] *** SUBJECT HERE ***
In a message of Tue, 25 Jun 2013 16:39:11 -0700, Greg KH writes: Indeed. I'd already had some (failed) thoughts about how to handle it nicely. Now I've had another think through, and I have something which deals with it and at least complains if TI_EXTRA_VID_PID_COUNT is changed without changing the initializer. Patch 2/2 Why don't we just drop the extra id thing entirely? The usb-serial subsystem handles new device ids being added dynamically from sysfs for a long time now. Removing this module option would clean up the code a lot, and prevent these errors from ever happening again. Aha, yes, I'm all for that (had I only known I'd have done that to start with). I'll look in to it. /Anders -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] *** SUBJECT HERE ***
On Wed, Jun 26, 2013 at 10:29:59AM +0200, Anders Hammarquist wrote:
In a message of Tue, 25 Jun 2013 16:39:11 -0700, Greg KH writes:
Indeed. I'd already had some (failed) thoughts about how to handle it
nicely. Now I've had another think through, and I have something which
deals with it and at least complains if TI_EXTRA_VID_PID_COUNT is changed
without changing the initializer. Patch 2/2
Why don't we just drop the extra id thing entirely? The usb-serial
subsystem handles new device ids being added dynamically from sysfs for
a long time now. Removing this module option would clean up the code a
lot, and prevent these errors from ever happening again.
Aha, yes, I'm all for that (had I only known I'd have done that to start
with). I'll look in to it.
I already have a few patches here (part of a larger 3.11 clean-up series)
which removes the vid/pid module parameters from all usb-serial modules
including ti_usb_3410_5052.
I hope to be able to submit the whole series a later tonight, but here's
the ti_usb_3410_5052 part if anyone's interested.
Thanks,
Johan
From: Johan Hovold jhov...@gmail.com
Subject: [PATCH] USB: ti_usb_3410_5052: remove vendor/product module parameters
Remove the vendor and product module parameters which were added a long
time ago when we did not have the dynamic sysfs interface to add
new device ids (and which isn't limited to five new vid/pid pair).
A vid/pid pair can be added dynamically using sysfs, for example:
echo 0451 1234 /sys/bus/usb-serial/drivers/ti_usb_3410_5052_1/new_id
for 1-port adapters, or
echo 0451 1234 /sys/bus/usb-serial/drivers/ti_usb_3410_5052_2/new_id
for 2-port adapters.
Signed-off-by: Johan Hovold jhov...@gmail.com
---
drivers/usb/serial/ti_usb_3410_5052.c | 72 ---
1 file changed, 7 insertions(+), 65 deletions(-)
diff --git a/drivers/usb/serial/ti_usb_3410_5052.c
b/drivers/usb/serial/ti_usb_3410_5052.c
index f3e21f5..5585b20 100644
--- a/drivers/usb/serial/ti_usb_3410_5052.c
+++ b/drivers/usb/serial/ti_usb_3410_5052.c
@@ -141,20 +141,9 @@ static int ti_download_firmware(struct ti_device *tdev);
/* module parameters */
static int closing_wait = TI_DEFAULT_CLOSING_WAIT;
-static ushort vendor_3410[TI_EXTRA_VID_PID_COUNT];
-static unsigned int vendor_3410_count;
-static ushort product_3410[TI_EXTRA_VID_PID_COUNT];
-static unsigned int product_3410_count;
-static ushort vendor_5052[TI_EXTRA_VID_PID_COUNT];
-static unsigned int vendor_5052_count;
-static ushort product_5052[TI_EXTRA_VID_PID_COUNT];
-static unsigned int product_5052_count;
/* supported devices */
-/* the array dimension is the number of default entries plus */
-/* TI_EXTRA_VID_PID_COUNT user defined entries plus 1 terminating */
-/* null entry */
-static struct usb_device_id ti_id_table_3410[15+TI_EXTRA_VID_PID_COUNT+1] = {
+static struct usb_device_id ti_id_table_3410[] = {
{ USB_DEVICE(TI_VENDOR_ID, TI_3410_PRODUCT_ID) },
{ USB_DEVICE(TI_VENDOR_ID, TI_3410_EZ430_ID) },
{ USB_DEVICE(MTS_VENDOR_ID, MTS_GSM_NO_FW_PRODUCT_ID) },
@@ -171,16 +160,18 @@ static struct usb_device_id
ti_id_table_3410[15+TI_EXTRA_VID_PID_COUNT+1] = {
{ USB_DEVICE(ABBOTT_VENDOR_ID, ABBOTT_STEREO_PLUG_ID) },
{ USB_DEVICE(ABBOTT_VENDOR_ID, ABBOTT_STRIP_PORT_ID) },
{ USB_DEVICE(TI_VENDOR_ID, FRI2_PRODUCT_ID) },
+ { } /* terminator */
};
-static struct usb_device_id ti_id_table_5052[5+TI_EXTRA_VID_PID_COUNT+1] = {
+static struct usb_device_id ti_id_table_5052[] = {
{ USB_DEVICE(TI_VENDOR_ID, TI_5052_BOOT_PRODUCT_ID) },
{ USB_DEVICE(TI_VENDOR_ID, TI_5152_BOOT_PRODUCT_ID) },
{ USB_DEVICE(TI_VENDOR_ID, TI_5052_EEPROM_PRODUCT_ID) },
{ USB_DEVICE(TI_VENDOR_ID, TI_5052_FIRMWARE_PRODUCT_ID) },
+ { } /* terminator */
};
-static struct usb_device_id
ti_id_table_combined[19+2*TI_EXTRA_VID_PID_COUNT+1] = {
+static struct usb_device_id ti_id_table_combined[] = {
{ USB_DEVICE(TI_VENDOR_ID, TI_3410_PRODUCT_ID) },
{ USB_DEVICE(TI_VENDOR_ID, TI_3410_EZ430_ID) },
{ USB_DEVICE(MTS_VENDOR_ID, MTS_GSM_NO_FW_PRODUCT_ID) },
@@ -200,7 +191,7 @@ static struct usb_device_id
ti_id_table_combined[19+2*TI_EXTRA_VID_PID_COUNT+1]
{ USB_DEVICE(IBM_VENDOR_ID, IBM_454C_PRODUCT_ID) },
{ USB_DEVICE(ABBOTT_VENDOR_ID, ABBOTT_PRODUCT_ID) },
{ USB_DEVICE(TI_VENDOR_ID, FRI2_PRODUCT_ID) },
- { }
+ { } /* terminator */
};
static struct usb_serial_driver ti_1port_device = {
@@ -289,61 +280,12 @@ module_param(closing_wait, int, S_IRUGO | S_IWUSR);
MODULE_PARM_DESC(closing_wait,
Maximum wait for data to drain in close, in .01 secs, default is 4000);
-module_param_array(vendor_3410, ushort, vendor_3410_count, S_IRUGO);
-MODULE_PARM_DESC(vendor_3410,
- Vendor ids for 3410 based devices, 1-5 short integers);
-module_param_array(product_3410, ushort, product_3410_count, S_IRUGO);
Re: [PATCH 0/2] *** SUBJECT HERE ***
On Sat, Jun 22, 2013 at 08:54:43PM +0200, Anders Hammarquist wrote:
> In a message of Fri, 21 Jun 2013 16:56:03 -0700, Greg KH writes:
> >Please resend this in a format that I can apply it in (i.e. one that
> >does not require me to edit it by hand...)
>
> After more fighting with git, I belive I now made it spit out what I
> wanted. Patch 1/2 ahead.
>
> >> -static struct usb_device_id ti_id_table_3410[15+TI_EXTRA_VID_PID_COUNT+1]
> >> = {
> >> +static struct usb_device_id ti_id_table_3410[16+TI_EXTRA_VID_PID_COUNT+1]
> >> = {
> >
> >That's a mess, why have it be a static array at all? Just include an
> >empty one at the end.
>
> Indeed. I'd already had some (failed) thoughts about how to handle it
> nicely. Now I've had another think through, and I have something which
> deals with it and at least complains if TI_EXTRA_VID_PID_COUNT is changed
> without changing the initializer. Patch 2/2
Why don't we just drop the extra id thing entirely? The usb-serial
subsystem handles new device ids being added dynamically from sysfs for
a long time now. Removing this module option would clean up the code a
lot, and prevent these errors from ever happening again.
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] *** SUBJECT HERE ***
On Sat, Jun 22, 2013 at 08:54:43PM +0200, Anders Hammarquist wrote:
In a message of Fri, 21 Jun 2013 16:56:03 -0700, Greg KH writes:
Please resend this in a format that I can apply it in (i.e. one that
does not require me to edit it by hand...)
After more fighting with git, I belive I now made it spit out what I
wanted. Patch 1/2 ahead.
-static struct usb_device_id ti_id_table_3410[15+TI_EXTRA_VID_PID_COUNT+1]
= {
+static struct usb_device_id ti_id_table_3410[16+TI_EXTRA_VID_PID_COUNT+1]
= {
That's a mess, why have it be a static array at all? Just include an
empty one at the end.
Indeed. I'd already had some (failed) thoughts about how to handle it
nicely. Now I've had another think through, and I have something which
deals with it and at least complains if TI_EXTRA_VID_PID_COUNT is changed
without changing the initializer. Patch 2/2
Why don't we just drop the extra id thing entirely? The usb-serial
subsystem handles new device ids being added dynamically from sysfs for
a long time now. Removing this module option would clean up the code a
lot, and prevent these errors from ever happening again.
thanks,
greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] *** SUBJECT HERE ***
In a message of Fri, 21 Jun 2013 16:56:03 -0700, Greg KH writes:
>Please resend this in a format that I can apply it in (i.e. one that
>does not require me to edit it by hand...)
After more fighting with git, I belive I now made it spit out what I
wanted. Patch 1/2 ahead.
>> -static struct usb_device_id ti_id_table_3410[15+TI_EXTRA_VID_PID_COUNT+1] =
>> {
>> +static struct usb_device_id ti_id_table_3410[16+TI_EXTRA_VID_PID_COUNT+1] =
>> {
>
>That's a mess, why have it be a static array at all? Just include an
>empty one at the end.
Indeed. I'd already had some (failed) thoughts about how to handle it
nicely. Now I've had another think through, and I have something which
deals with it and at least complains if TI_EXTRA_VID_PID_COUNT is changed
without changing the initializer. Patch 2/2
/Anders
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] *** SUBJECT HERE ***
In a message of Fri, 21 Jun 2013 16:56:03 -0700, Greg KH writes:
Please resend this in a format that I can apply it in (i.e. one that
does not require me to edit it by hand...)
After more fighting with git, I belive I now made it spit out what I
wanted. Patch 1/2 ahead.
-static struct usb_device_id ti_id_table_3410[15+TI_EXTRA_VID_PID_COUNT+1] =
{
+static struct usb_device_id ti_id_table_3410[16+TI_EXTRA_VID_PID_COUNT+1] =
{
That's a mess, why have it be a static array at all? Just include an
empty one at the end.
Indeed. I'd already had some (failed) thoughts about how to handle it
nicely. Now I've had another think through, and I have something which
deals with it and at least complains if TI_EXTRA_VID_PID_COUNT is changed
without changing the initializer. Patch 2/2
/Anders
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] *** SUBJECT HERE ***
On Sat, Jun 22, 2013 at 01:08:12AM +0200, Anders Hammarquist wrote:
> In a message of Wed, 19 Jun 2013 15:53:15 -0700, Greg KH writes:
> >I think you forgot a Subject :)
>
> Indeed. I blame it on my first fight with git format-patch ;-)
>
> >On Wed, Jun 19, 2013 at 02:05:07AM +0200, Anders Hammarquist wrote:
> >> This patch set adds the product id to the driver, and makes the
> >> product type more explicit. Arguably, the ABBOTT_PRODUCT_ID
> >> define could be removed, but I left it on the off chance that
> >> someone other that the TI 3410 driver uses it.
> >
> >No, it doesn't, please fix up that last patch and resend it.
>
> Right, and in removing it I actually found that it was used in
> two places in the driver. I lost my second fight with format-patch
> so I'll just enclose the fixed patch below.
>
> /Anders
>
> ---8<---
> ti_usb_3410_5052:
> * Remove unspecific ABBOTT_PRODUCT_ID
> * Fix size of statically sized arrays
>
> Signed-off-by: Anders Hammarquist
Please resend this in a format that I can apply it in (i.e. one that
does not require me to edit it by hand...)
Also, please cc: the linux-...@vger.kernel.org mailing list for usb
patches.
> diff --git a/drivers/usb/serial/ti_usb_3410_5052.c
> b/drivers/usb/serial/ti_usb_3410_5052.c
> index e581c25..26c1161 100644
> --- a/drivers/usb/serial/ti_usb_3410_5052.c
> +++ b/drivers/usb/serial/ti_usb_3410_5052.c
> @@ -158,7 +158,7 @@ static unsigned int product_5052_count;
> /* the array dimension is the number of default entries plus */
> /* TI_EXTRA_VID_PID_COUNT user defined entries plus 1 terminating */
> /* null entry */
> -static struct usb_device_id ti_id_table_3410[15+TI_EXTRA_VID_PID_COUNT+1] = {
> +static struct usb_device_id ti_id_table_3410[16+TI_EXTRA_VID_PID_COUNT+1] = {
That's a mess, why have it be a static array at all? Just include an
empty one at the end.
> { USB_DEVICE(TI_VENDOR_ID, TI_3410_PRODUCT_ID) },
> { USB_DEVICE(TI_VENDOR_ID, TI_3410_EZ430_ID) },
> { USB_DEVICE(MTS_VENDOR_ID, MTS_GSM_NO_FW_PRODUCT_ID) },
> @@ -172,8 +172,8 @@ static struct usb_device_id
> ti_id_table_3410[15+TI_EXTRA_VID_PID_COUNT+1] = {
> { USB_DEVICE(IBM_VENDOR_ID, IBM_4543_PRODUCT_ID) },
> { USB_DEVICE(IBM_VENDOR_ID, IBM_454B_PRODUCT_ID) },
> { USB_DEVICE(IBM_VENDOR_ID, IBM_454C_PRODUCT_ID) },
> - { USB_DEVICE(ABBOTT_VENDOR_ID, ABBOTT_STEREO_PLUG_ID) },
> - { USB_DEVICE(ABBOTT_VENDOR_ID, ABBOTT_STRIP_PORT_ID) },
> + { USB_DEVICE(ABBOTT_VENDOR_ID, ABBOTT_STEREO_PLUG_PRODUCT_ID) },
> + { USB_DEVICE(ABBOTT_VENDOR_ID, ABBOTT_STRIP_PORT_PRODUCT_ID) },
> { USB_DEVICE(TI_VENDOR_ID, FRI2_PRODUCT_ID) },
> };
>
> @@ -184,7 +184,7 @@ static struct usb_device_id
> ti_id_table_5052[5+TI_EXTRA_VID_PID_COUNT+1] = {
> { USB_DEVICE(TI_VENDOR_ID, TI_5052_FIRMWARE_PRODUCT_ID) },
> };
>
> -static struct usb_device_id
> ti_id_table_combined[19+2*TI_EXTRA_VID_PID_COUNT+1] = {
> +static struct usb_device_id
> ti_id_table_combined[20+2*TI_EXTRA_VID_PID_COUNT+1] = {
Same here. Although that might take another patch, to handle it all
correctly, separate from this "change the device id names" patch.
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] *** SUBJECT HERE ***
In a message of Wed, 19 Jun 2013 15:53:15 -0700, Greg KH writes:
>I think you forgot a Subject :)
Indeed. I blame it on my first fight with git format-patch ;-)
>On Wed, Jun 19, 2013 at 02:05:07AM +0200, Anders Hammarquist wrote:
>> This patch set adds the product id to the driver, and makes the
>> product type more explicit. Arguably, the ABBOTT_PRODUCT_ID
>> define could be removed, but I left it on the off chance that
>> someone other that the TI 3410 driver uses it.
>
>No, it doesn't, please fix up that last patch and resend it.
Right, and in removing it I actually found that it was used in
two places in the driver. I lost my second fight with format-patch
so I'll just enclose the fixed patch below.
/Anders
---8<---
ti_usb_3410_5052:
* Remove unspecific ABBOTT_PRODUCT_ID
* Fix size of statically sized arrays
Signed-off-by: Anders Hammarquist
diff --git a/drivers/usb/serial/ti_usb_3410_5052.c
b/drivers/usb/serial/ti_usb_3410_5052.c
index e581c25..26c1161 100644
--- a/drivers/usb/serial/ti_usb_3410_5052.c
+++ b/drivers/usb/serial/ti_usb_3410_5052.c
@@ -158,7 +158,7 @@ static unsigned int product_5052_count;
/* the array dimension is the number of default entries plus */
/* TI_EXTRA_VID_PID_COUNT user defined entries plus 1 terminating */
/* null entry */
-static struct usb_device_id ti_id_table_3410[15+TI_EXTRA_VID_PID_COUNT+1] = {
+static struct usb_device_id ti_id_table_3410[16+TI_EXTRA_VID_PID_COUNT+1] = {
{ USB_DEVICE(TI_VENDOR_ID, TI_3410_PRODUCT_ID) },
{ USB_DEVICE(TI_VENDOR_ID, TI_3410_EZ430_ID) },
{ USB_DEVICE(MTS_VENDOR_ID, MTS_GSM_NO_FW_PRODUCT_ID) },
@@ -172,8 +172,8 @@ static struct usb_device_id
ti_id_table_3410[15+TI_EXTRA_VID_PID_COUNT+1] = {
{ USB_DEVICE(IBM_VENDOR_ID, IBM_4543_PRODUCT_ID) },
{ USB_DEVICE(IBM_VENDOR_ID, IBM_454B_PRODUCT_ID) },
{ USB_DEVICE(IBM_VENDOR_ID, IBM_454C_PRODUCT_ID) },
- { USB_DEVICE(ABBOTT_VENDOR_ID, ABBOTT_STEREO_PLUG_ID) },
- { USB_DEVICE(ABBOTT_VENDOR_ID, ABBOTT_STRIP_PORT_ID) },
+ { USB_DEVICE(ABBOTT_VENDOR_ID, ABBOTT_STEREO_PLUG_PRODUCT_ID) },
+ { USB_DEVICE(ABBOTT_VENDOR_ID, ABBOTT_STRIP_PORT_PRODUCT_ID) },
{ USB_DEVICE(TI_VENDOR_ID, FRI2_PRODUCT_ID) },
};
@@ -184,7 +184,7 @@ static struct usb_device_id
ti_id_table_5052[5+TI_EXTRA_VID_PID_COUNT+1] = {
{ USB_DEVICE(TI_VENDOR_ID, TI_5052_FIRMWARE_PRODUCT_ID) },
};
-static struct usb_device_id
ti_id_table_combined[19+2*TI_EXTRA_VID_PID_COUNT+1] = {
+static struct usb_device_id
ti_id_table_combined[20+2*TI_EXTRA_VID_PID_COUNT+1] = {
{ USB_DEVICE(TI_VENDOR_ID, TI_3410_PRODUCT_ID) },
{ USB_DEVICE(TI_VENDOR_ID, TI_3410_EZ430_ID) },
{ USB_DEVICE(MTS_VENDOR_ID, MTS_GSM_NO_FW_PRODUCT_ID) },
@@ -202,7 +202,8 @@ static struct usb_device_id
ti_id_table_combined[19+2*TI_EXTRA_VID_PID_COUNT+1]
{ USB_DEVICE(IBM_VENDOR_ID, IBM_4543_PRODUCT_ID) },
{ USB_DEVICE(IBM_VENDOR_ID, IBM_454B_PRODUCT_ID) },
{ USB_DEVICE(IBM_VENDOR_ID, IBM_454C_PRODUCT_ID) },
- { USB_DEVICE(ABBOTT_VENDOR_ID, ABBOTT_PRODUCT_ID) },
+ { USB_DEVICE(ABBOTT_VENDOR_ID, ABBOTT_STEREO_PLUG_PRODUCT_ID) },
+ { USB_DEVICE(ABBOTT_VENDOR_ID, ABBOTT_STRIP_PORT_PRODUCT_ID) },
{ USB_DEVICE(TI_VENDOR_ID, FRI2_PRODUCT_ID) },
{ }
};
diff --git a/drivers/usb/serial/ti_usb_3410_5052.h
b/drivers/usb/serial/ti_usb_3410_5052.h
index 4a2423e..d3ff470 100644
--- a/drivers/usb/serial/ti_usb_3410_5052.h
+++ b/drivers/usb/serial/ti_usb_3410_5052.h
@@ -52,9 +52,8 @@
/* Abbott Diabetics vendor and product ids */
#define ABBOTT_VENDOR_ID 0x1a61
-#define ABBOTT_STEREO_PLUG_ID 0x3410
-#define ABBOTT_PRODUCT_ID ABBOTT_STEREO_PLUG_ID
-#define ABBOTT_STRIP_PORT_ID 0x3420
+#define ABBOTT_STEREO_PLUG_PRODUCT_ID 0x3410
+#define ABBOTT_STRIP_PORT_PRODUCT_ID 0x3420
/* Commands */
#define TI_GET_VERSION 0x01
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] *** SUBJECT HERE ***
In a message of Wed, 19 Jun 2013 15:53:15 -0700, Greg KH writes:
I think you forgot a Subject :)
Indeed. I blame it on my first fight with git format-patch ;-)
On Wed, Jun 19, 2013 at 02:05:07AM +0200, Anders Hammarquist wrote:
This patch set adds the product id to the driver, and makes the
product type more explicit. Arguably, the ABBOTT_PRODUCT_ID
define could be removed, but I left it on the off chance that
someone other that the TI 3410 driver uses it.
No, it doesn't, please fix up that last patch and resend it.
Right, and in removing it I actually found that it was used in
two places in the driver. I lost my second fight with format-patch
so I'll just enclose the fixed patch below.
/Anders
---8---
ti_usb_3410_5052:
* Remove unspecific ABBOTT_PRODUCT_ID
* Fix size of statically sized arrays
Signed-off-by: Anders Hammarquist i...@iko.pp.se
diff --git a/drivers/usb/serial/ti_usb_3410_5052.c
b/drivers/usb/serial/ti_usb_3410_5052.c
index e581c25..26c1161 100644
--- a/drivers/usb/serial/ti_usb_3410_5052.c
+++ b/drivers/usb/serial/ti_usb_3410_5052.c
@@ -158,7 +158,7 @@ static unsigned int product_5052_count;
/* the array dimension is the number of default entries plus */
/* TI_EXTRA_VID_PID_COUNT user defined entries plus 1 terminating */
/* null entry */
-static struct usb_device_id ti_id_table_3410[15+TI_EXTRA_VID_PID_COUNT+1] = {
+static struct usb_device_id ti_id_table_3410[16+TI_EXTRA_VID_PID_COUNT+1] = {
{ USB_DEVICE(TI_VENDOR_ID, TI_3410_PRODUCT_ID) },
{ USB_DEVICE(TI_VENDOR_ID, TI_3410_EZ430_ID) },
{ USB_DEVICE(MTS_VENDOR_ID, MTS_GSM_NO_FW_PRODUCT_ID) },
@@ -172,8 +172,8 @@ static struct usb_device_id
ti_id_table_3410[15+TI_EXTRA_VID_PID_COUNT+1] = {
{ USB_DEVICE(IBM_VENDOR_ID, IBM_4543_PRODUCT_ID) },
{ USB_DEVICE(IBM_VENDOR_ID, IBM_454B_PRODUCT_ID) },
{ USB_DEVICE(IBM_VENDOR_ID, IBM_454C_PRODUCT_ID) },
- { USB_DEVICE(ABBOTT_VENDOR_ID, ABBOTT_STEREO_PLUG_ID) },
- { USB_DEVICE(ABBOTT_VENDOR_ID, ABBOTT_STRIP_PORT_ID) },
+ { USB_DEVICE(ABBOTT_VENDOR_ID, ABBOTT_STEREO_PLUG_PRODUCT_ID) },
+ { USB_DEVICE(ABBOTT_VENDOR_ID, ABBOTT_STRIP_PORT_PRODUCT_ID) },
{ USB_DEVICE(TI_VENDOR_ID, FRI2_PRODUCT_ID) },
};
@@ -184,7 +184,7 @@ static struct usb_device_id
ti_id_table_5052[5+TI_EXTRA_VID_PID_COUNT+1] = {
{ USB_DEVICE(TI_VENDOR_ID, TI_5052_FIRMWARE_PRODUCT_ID) },
};
-static struct usb_device_id
ti_id_table_combined[19+2*TI_EXTRA_VID_PID_COUNT+1] = {
+static struct usb_device_id
ti_id_table_combined[20+2*TI_EXTRA_VID_PID_COUNT+1] = {
{ USB_DEVICE(TI_VENDOR_ID, TI_3410_PRODUCT_ID) },
{ USB_DEVICE(TI_VENDOR_ID, TI_3410_EZ430_ID) },
{ USB_DEVICE(MTS_VENDOR_ID, MTS_GSM_NO_FW_PRODUCT_ID) },
@@ -202,7 +202,8 @@ static struct usb_device_id
ti_id_table_combined[19+2*TI_EXTRA_VID_PID_COUNT+1]
{ USB_DEVICE(IBM_VENDOR_ID, IBM_4543_PRODUCT_ID) },
{ USB_DEVICE(IBM_VENDOR_ID, IBM_454B_PRODUCT_ID) },
{ USB_DEVICE(IBM_VENDOR_ID, IBM_454C_PRODUCT_ID) },
- { USB_DEVICE(ABBOTT_VENDOR_ID, ABBOTT_PRODUCT_ID) },
+ { USB_DEVICE(ABBOTT_VENDOR_ID, ABBOTT_STEREO_PLUG_PRODUCT_ID) },
+ { USB_DEVICE(ABBOTT_VENDOR_ID, ABBOTT_STRIP_PORT_PRODUCT_ID) },
{ USB_DEVICE(TI_VENDOR_ID, FRI2_PRODUCT_ID) },
{ }
};
diff --git a/drivers/usb/serial/ti_usb_3410_5052.h
b/drivers/usb/serial/ti_usb_3410_5052.h
index 4a2423e..d3ff470 100644
--- a/drivers/usb/serial/ti_usb_3410_5052.h
+++ b/drivers/usb/serial/ti_usb_3410_5052.h
@@ -52,9 +52,8 @@
/* Abbott Diabetics vendor and product ids */
#define ABBOTT_VENDOR_ID 0x1a61
-#define ABBOTT_STEREO_PLUG_ID 0x3410
-#define ABBOTT_PRODUCT_ID ABBOTT_STEREO_PLUG_ID
-#define ABBOTT_STRIP_PORT_ID 0x3420
+#define ABBOTT_STEREO_PLUG_PRODUCT_ID 0x3410
+#define ABBOTT_STRIP_PORT_PRODUCT_ID 0x3420
/* Commands */
#define TI_GET_VERSION 0x01
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] *** SUBJECT HERE ***
On Sat, Jun 22, 2013 at 01:08:12AM +0200, Anders Hammarquist wrote:
In a message of Wed, 19 Jun 2013 15:53:15 -0700, Greg KH writes:
I think you forgot a Subject :)
Indeed. I blame it on my first fight with git format-patch ;-)
On Wed, Jun 19, 2013 at 02:05:07AM +0200, Anders Hammarquist wrote:
This patch set adds the product id to the driver, and makes the
product type more explicit. Arguably, the ABBOTT_PRODUCT_ID
define could be removed, but I left it on the off chance that
someone other that the TI 3410 driver uses it.
No, it doesn't, please fix up that last patch and resend it.
Right, and in removing it I actually found that it was used in
two places in the driver. I lost my second fight with format-patch
so I'll just enclose the fixed patch below.
/Anders
---8---
ti_usb_3410_5052:
* Remove unspecific ABBOTT_PRODUCT_ID
* Fix size of statically sized arrays
Signed-off-by: Anders Hammarquist i...@iko.pp.se
Please resend this in a format that I can apply it in (i.e. one that
does not require me to edit it by hand...)
Also, please cc: the linux-...@vger.kernel.org mailing list for usb
patches.
diff --git a/drivers/usb/serial/ti_usb_3410_5052.c
b/drivers/usb/serial/ti_usb_3410_5052.c
index e581c25..26c1161 100644
--- a/drivers/usb/serial/ti_usb_3410_5052.c
+++ b/drivers/usb/serial/ti_usb_3410_5052.c
@@ -158,7 +158,7 @@ static unsigned int product_5052_count;
/* the array dimension is the number of default entries plus */
/* TI_EXTRA_VID_PID_COUNT user defined entries plus 1 terminating */
/* null entry */
-static struct usb_device_id ti_id_table_3410[15+TI_EXTRA_VID_PID_COUNT+1] = {
+static struct usb_device_id ti_id_table_3410[16+TI_EXTRA_VID_PID_COUNT+1] = {
That's a mess, why have it be a static array at all? Just include an
empty one at the end.
{ USB_DEVICE(TI_VENDOR_ID, TI_3410_PRODUCT_ID) },
{ USB_DEVICE(TI_VENDOR_ID, TI_3410_EZ430_ID) },
{ USB_DEVICE(MTS_VENDOR_ID, MTS_GSM_NO_FW_PRODUCT_ID) },
@@ -172,8 +172,8 @@ static struct usb_device_id
ti_id_table_3410[15+TI_EXTRA_VID_PID_COUNT+1] = {
{ USB_DEVICE(IBM_VENDOR_ID, IBM_4543_PRODUCT_ID) },
{ USB_DEVICE(IBM_VENDOR_ID, IBM_454B_PRODUCT_ID) },
{ USB_DEVICE(IBM_VENDOR_ID, IBM_454C_PRODUCT_ID) },
- { USB_DEVICE(ABBOTT_VENDOR_ID, ABBOTT_STEREO_PLUG_ID) },
- { USB_DEVICE(ABBOTT_VENDOR_ID, ABBOTT_STRIP_PORT_ID) },
+ { USB_DEVICE(ABBOTT_VENDOR_ID, ABBOTT_STEREO_PLUG_PRODUCT_ID) },
+ { USB_DEVICE(ABBOTT_VENDOR_ID, ABBOTT_STRIP_PORT_PRODUCT_ID) },
{ USB_DEVICE(TI_VENDOR_ID, FRI2_PRODUCT_ID) },
};
@@ -184,7 +184,7 @@ static struct usb_device_id
ti_id_table_5052[5+TI_EXTRA_VID_PID_COUNT+1] = {
{ USB_DEVICE(TI_VENDOR_ID, TI_5052_FIRMWARE_PRODUCT_ID) },
};
-static struct usb_device_id
ti_id_table_combined[19+2*TI_EXTRA_VID_PID_COUNT+1] = {
+static struct usb_device_id
ti_id_table_combined[20+2*TI_EXTRA_VID_PID_COUNT+1] = {
Same here. Although that might take another patch, to handle it all
correctly, separate from this change the device id names patch.
thanks,
greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] *** SUBJECT HERE ***
I think you forgot a Subject :) On Wed, Jun 19, 2013 at 02:05:07AM +0200, Anders Hammarquist wrote: > The USB cable to read out data from the Abbott FreeStyle Precision > meters, known as the Abbott stip port cable, uses the TI 3410 chip, > just as the already added stereo port cable. They are essestially > the same cable, just with different connectors at the end. > > This patch set adds the product id to the driver, and makes the > product type more explicit. Arguably, the ABBOTT_PRODUCT_ID > define could be removed, but I left it on the off chance that > someone other that the TI 3410 driver uses it. No, it doesn't, please fix up that last patch and resend it. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] *** SUBJECT HERE ***
I think you forgot a Subject :) On Wed, Jun 19, 2013 at 02:05:07AM +0200, Anders Hammarquist wrote: The USB cable to read out data from the Abbott FreeStyle Precision meters, known as the Abbott stip port cable, uses the TI 3410 chip, just as the already added stereo port cable. They are essestially the same cable, just with different connectors at the end. This patch set adds the product id to the driver, and makes the product type more explicit. Arguably, the ABBOTT_PRODUCT_ID define could be removed, but I left it on the off chance that someone other that the TI 3410 driver uses it. No, it doesn't, please fix up that last patch and resend it. thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/2] *** SUBJECT HERE ***
The USB cable to read out data from the Abbott FreeStyle Precision meters, known as the Abbott stip port cable, uses the TI 3410 chip, just as the already added stereo port cable. They are essestially the same cable, just with different connectors at the end. This patch set adds the product id to the driver, and makes the product type more explicit. Arguably, the ABBOTT_PRODUCT_ID define could be removed, but I left it on the off chance that someone other that the TI 3410 driver uses it. /Anders Anders Hammarquist (2): Add product id for Abbott strip port cable for Precision meter which uses the TI 3410 chip. Be explicit about the Abbott product ids being product ids. drivers/usb/serial/ti_usb_3410_5052.c |3 ++- drivers/usb/serial/ti_usb_3410_5052.h |4 +++- 2 files changed, 5 insertions(+), 2 deletions(-) -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/2] *** SUBJECT HERE ***
The USB cable to read out data from the Abbott FreeStyle Precision meters, known as the Abbott stip port cable, uses the TI 3410 chip, just as the already added stereo port cable. They are essestially the same cable, just with different connectors at the end. This patch set adds the product id to the driver, and makes the product type more explicit. Arguably, the ABBOTT_PRODUCT_ID define could be removed, but I left it on the off chance that someone other that the TI 3410 driver uses it. /Anders Anders Hammarquist (2): Add product id for Abbott strip port cable for Precision meter which uses the TI 3410 chip. Be explicit about the Abbott product ids being product ids. drivers/usb/serial/ti_usb_3410_5052.c |3 ++- drivers/usb/serial/ti_usb_3410_5052.h |4 +++- 2 files changed, 5 insertions(+), 2 deletions(-) -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
