Re: [PATCH] bugfix for an underflow condition in usb storage & isd200.c
On Mon, Feb 04 2008 at 22:05 +0200, Alan Stern <[EMAIL PROTECTED]> wrote: > On Sun, 3 Feb 2008, Matthew Dharm wrote: > >> But, the modifications to usb_stor_access_xfer_buf() look good -- no >> request from a sub-driver should be allowed to scribble into memory. The >> current code does make the implicit assumption that there is enough >> storage, and will walk right off the end of the sg list if there isn't. >> >> I'm not sure I like the mods to usb_stor_set_xfer_buf(). Any place we set >> a status that we know is going to be thrown away is an invitation for a >> problem later if someone changes the code to preserve that status. It's a >> jack-in-the-box, waiting to spring open in our face later. The limit check >> (which mirrors the usb_stor_access_xfer_buf modification) and WARN_ON() are >> probably good. >> >> In a strictly technical sense, the change to protocol.c are sufficient. >> That is, they will prevent a serious error. There is a justification tho >> to fix all of the users of usb_stor_access_buf() to not attempt to use more >> SCSI buffer than exists. >> >> My opinion is this: Let's make the protocol.c mods (modulo my comments >> about setting useless status bits) now. Then, let's decide if we're going >> to patch all the other users of the usb_stor_*_xfer_buf() functions as a >> separate discussion. > > I think the correct approach is to modify those routines so that they > will never overrun the s-g buffer (like Boaz has done), and _document_ > this behavior. Then the callers can feel free to try and transfer as > much as they want, knowing that an overrun can't occur. There won't > be any need for a WARN_ON or anything else. > > However the interface to usb_stor_access_xfer_buf() will have to change > slightly. Right now if it sees that *sgptr is NULL, it assumes this > means it should start at the beginning of the s-g buffer. But with > Boaz's change, *sgptr == NULL means the transfer has reached the end of > the buffer. So I'll have to go through and audit all the callers. > > Alan Stern > > - No it does not, this as not changed. Please look again. Note that this patch was tested and working. It is a bug in v2.2.24 and it should be accepted already. One way or the other. Callers of usb_stor_access_xfer_buf() need not change. Matthew Dharm should decide if he wants the WARN_ON in usb_stor_set_xfer_buf() or not and be done with it. I have found and fixed the bug, but it is not a SCSI related bug, and it is not do to any scsi changes. It is a bug from the SG changes of early 2.6.24. Please take it through the USB tree. Feel free to change it the way you like it, and submit it. Boaz - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: mark USB drivers as being GPL only
On Mon, 2008-02-04 at 01:37 +1030, David Newall wrote: [...] > disadvantage Linux with respect to many classes of devices, for example > GSM transceivers when used in those parts of the world^ where regulatory > requirements prohibit modification of power or frequency settings, which > effectively prohibits open-source driver. Are you sure that that is not only (the results of) propaganda of (certain) proprietary companies? Usually the *user* (at home, wherever) sets "illegal" values. So it's the users responsibility and the manufacturer, importer or sellers don't care (if only that can't prevent other "illegal" actions like "beating some to death with $WLAN_ROUTER"). Or do you get a gun manufacturer before court just because someone committed a crime with a its gun? Feel free to use other comparisons like "knifes" or "cars" if you need more harmless examples Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: mark USB drivers as being GPL only
Bernd Petrovitsch writes: On Mon, 2008-02-04 at 01:37 +1030, David Newall wrote: [...] disadvantage Linux with respect to many classes of devices, for example GSM transceivers when used in those parts of the world^ where regulatory requirements prohibit modification of power or frequency settings, which effectively prohibits open-source driver. Are you sure that that is not only (the results of) propaganda of (certain) proprietary companies? well, yes. Usually the *user* (at home, wherever) sets "illegal" values. So it's the users responsibility and the manufacturer, importer or sellers don't care (if only that can't prevent other "illegal" actions like "beating some to death with $WLAN_ROUTER"). Or, as is the case perhaps almost everywhere, governments prohibit devices that can operate outside of local requirements. Or do you get a gun manufacturer before court just because someone committed a crime with a its gun? Let's not confuse the issue. - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: mark USB drivers as being GPL only
Hi David, Marcel Holtmann writes: > > You driver was meant to be running as Linux kernel module and thus it is > > derivative work. On Feb 5, 2008 1:39 PM, David Newall <[EMAIL PROTECTED]> wrote: > It is precisely the fact that it is a loadable module, and does not form > part of the kernel, that removes the requirement to distribute it under GPL. What makes you qualified to make that statement (without giving any evidence)? Are you're an expert on international copyright law? - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: mark USB drivers as being GPL only
Pekka Enberg writes: I think you're missing my point: as long as the license stays the way it is now, you can never distribute proprietary code unless you've consulted a lawyer and even then you run the risk of being sued for infringement if the copyright holder thinks what you have is derived work. Yes I can, if the proprietary code is not linked with GPL code (and the proprietary code is original). Loadable modules are not linked. This is a very clear-cut case. - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: mark USB drivers as being GPL only
Marcel Holtmann writes: if a new drivers is originally written for Linux, then you are breaking the GPL. Completely wrong. However if the driver is distributed as built-in, then it would need to be licensed under GPL. This means that a driver can be written and distributed as a module under any licence, proprietary or otherwise, presumably with the restriction that it may NOT be built-in. You driver was meant to be running as Linux kernel module and thus it is derivative work. It is precisely the fact that it is a loadable module, and does not form part of the kernel, that removes the requirement to distribute it under GPL. What are you arguing here. It makes no difference if it is technical or not. The EXPORT_SYMBOL_GPL gives you a clear hint that when using this symbol, you have to obey to the GPL. And that "hint" is a lie. - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: mark USB drivers as being GPL only
> It is precisely the fact that it is a loadable module, and does not form > part of the kernel, that removes the requirement to distribute it under GPL. That would be your own personal strange opinion. Having actually spent time with lawyers on the subject the question that matters for the GPL is the line between a derivative work and a non-derivative work. The former the GPL covers - the latter it does not. That is totally independent of the technical implementation of the loading and combining of the code. There is even at least one case where the lawyers on both sides of a dispute have concurred that something is derivative because it was closely dependant on a backend that it communicated with by pipes and was useless without that backend and clearly built solely to use it. Mechanism is not important, whether you are doing RPC calls, dynamic linking or static linking isn't part of the creative process. The only exception to the derivative work question is usual system calls. I don't think anyone expects those to create a derivative work anyway but just in case the law gets a bit carried away the COPYING file for the kernel explicitly covers this to ensure there is certainty about running totally seperate proprietary applications on the Linux kernel. Alan - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB device doesn't get address
On Mon, Feb 04, 2008 at 05:18:15PM -0500, Alan Stern wrote:
> On Mon, 4 Feb 2008, Fabio Venturi wrote:
>
> > Here is the output of usbmon with the patched kernel:
>
> Whoops! The patch I sent you was wrong. Evidently the device is using
> a different ProductID from what your lsusb output says. Here's the
> updated patch.
>
> Alan Stern
>
>
> Index: usb-2.6/drivers/usb/core/quirks.c
> ===
> --- usb-2.6.orig/drivers/usb/core/quirks.c
> +++ usb-2.6/drivers/usb/core/quirks.c
> @@ -28,6 +28,9 @@
> * devices is broken...
> */
> static const struct usb_device_id usb_quirk_list[] = {
> + /* Action Semiconductor flash disk */
> + { USB_DEVICE(0x10d6, 0x2200), .driver_info =
> USB_QUIRK_STRING_FETCH_255},
> +
> /* CBM - Flash disk */
> { USB_DEVICE(0x0204, 0x6025), .driver_info = USB_QUIRK_RESET_RESUME },
> /* HP 5300/5370C scanner */
>
> -
I've tried to patch quirks.c with:
+ { USB_DEVICE(0x10d6, 0x2200), .driver_info =
USB_QUIRK_STRING_FETCH_255},
and also with
+ { USB_DEVICE(0xd610, 0x2200), .driver_info =
USB_QUIRK_STRING_FETCH_255},
since i saw this line in the usbmon output:
d0bb4ec0 1770330276 C Ci:1:000:0 0 18 = 12010002 ff40 d6100022
00010102 0301
Anyway the problem persists and
that's the usbmon output with the 2nd patch:
dbc5a1c0 1770123854 C Ii:1:001:1 0:2048 1 = 08
dbc5a1c0 1770123870 S Ii:1:001:1 -115:2048 4 <
d0bb4ec0 1770124005 S Ci:1:001:0 s a3 00 0003 0004 4 <
d0bb4ec0 1770124020 C Ci:1:001:0 0 4 = 01050100
d0bb4ec0 1770124032 S Co:1:001:0 s 23 01 0010 0003 0
d0bb4ec0 1770124045 C Co:1:001:0 0 0
d0bb4ec0 1770124056 S Ci:1:001:0 s a3 00 0003 0004 4 <
d0bb4ec0 1770124067 C Ci:1:001:0 0 4 = 0105
d0bb4ec0 1770149542 S Ci:1:001:0 s a3 00 0003 0004 4 <
d0bb4ec0 1770149578 C Ci:1:001:0 0 4 = 0105
d0bb4ec0 1770175428 S Ci:1:001:0 s a3 00 0003 0004 4 <
d0bb4ec0 1770175459 C Ci:1:001:0 0 4 = 0105
d0bb4ec0 1770201528 S Ci:1:001:0 s a3 00 0003 0004 4 <
d0bb4ec0 1770201560 C Ci:1:001:0 0 4 = 0105
d0bb4ec0 1770227521 S Ci:1:001:0 s a3 00 0003 0004 4 <
d0bb4ec0 1770227551 C Ci:1:001:0 0 4 = 0105
d0bb4ec0 1770227569 S Co:1:001:0 s 23 03 0004 0003 0
d0bb4ec0 1770227582 C Co:1:001:0 0 0
d0bb4ec0 1770278431 S Ci:1:001:0 s a3 00 0003 0004 4 <
d0bb4ec0 1770278786 C Ci:1:001:0 0 4 = 03051000
d0bb4ec0 1770329433 S Co:1:001:0 s 23 01 0014 0003 0
d0bb4ec0 1770329473 C Co:1:001:0 0 0
d0bb4ec0 1770329719 S Ci:1:000:0 s 80 06 0100 0040 64 <
d0bb4ec0 1770330276 C Ci:1:000:0 0 18 = 12010002 ff40 d6100022
00010102 0301
d0bb4ec0 1770330299 S Co:1:001:0 s 23 03 0004 0003 0
d0bb4ec0 1770330312 C Co:1:001:0 0 0
d0bb4ec0 1770380432 S Ci:1:001:0 s a3 00 0003 0004 4 <
d0bb4ec0 1770380754 C Ci:1:001:0 0 4 = 03051000
d0bb4ec0 1770431435 S Co:1:001:0 s 23 01 0014 0003 0
d0bb4ec0 1770431469 C Co:1:001:0 0 0
d0bb4ec0 1770431481 S Co:1:000:0 s 00 05 000e 0
d0bb4ec0 1770431743 C Co:1:000:0 0 0
d0bb4ec0 1770443430 S Ci:1:014:0 s 80 06 0100 0012 18 <
d0bb4ec0 1770443737 C Ci:1:014:0 0 18 = 12010002 ff40 d6100022
00010102 0301
d0bb4ec0 1770443761 S Ci:1:014:0 s 80 06 0200 0009 9 <
d0bb4ec0 1770443862 C Ci:1:014:0 0 9 = 09022700 0101ee80 96
d0bb4ec0 1770443880 S Ci:1:014:0 s 80 06 0200 0027 39 <
d0bb4ec0 1770443986 C Ci:1:014:0 0 39 = 09022700 0101ee80 96090400
00030805 5705 01020002 00070582 02000200
d0bb42c0 1770444199 S Ci:1:014:0 s 80 06 0300 00ff 255 <
d0bb42c0 1770444363 C Ci:1:014:0 0 4 = 04030904
d0bb42c0 1770444381 S Ci:1:014:0 s 80 06 0302 0409 00ff 255 <
d0bb42c0 1770444986 C Ci:1:014:0 0 52 = 34034100 63007400 69006f00
6e007300 20004d00 74007000 20004400 65007600
d0bb42c0 1770445008 S Ci:1:014:0 s 80 06 0301 0409 00ff 255 <
d0bb42c0 1771837181 C Ci:1:014:0 -71 64 = 40034100 63007400 69006f00
6e007300 20005300 65006d00 69006300 6f006e00
dbc5a1c0 1771837197 C Ii:1:001:1 0:2048 1 = 08
dbc5a1c0 1771837203 S Ii:1:001:1 -115:2048 4 <
d0bb42c0 1771837290 S Ci:1:014:0 s 80 06 0301 0409 0002 2 <
d0bb42c0 1771837417 C Ci:1:014:0 -71 0
d0bb42c0 1771837437 S Ci:1:014:0 s 80 06 0303 0409 00ff 255 <
d0bb42c0 1771837665 C Ci:1:014:0 -71 0
d0bb42c0 1771837680 S Ci:1:014:0 s 80 06 0303 0409 0002 2 <
d0bb42c0 1771837914 C Ci:1:014:0 -71 0
d0bb42c0 1771838913 S Co:1:014:0 s 00 09 0001 0
d0bb42c0 1771839042 C Co:1:014:0 -71 0
d0bb42c0 1771839192 S Ci:1:001:0 s a3 00 0003 0004 4 <
d0bb42c0 1771839210 C Ci:1:001:0 0 4 = 00010100
d0bb42c0 1771839222 S Co:1:001:0 s 23 01 0010 0003 0
d0bb42c0 1771839234 C Co:1:001:0 0 0
d0bb4ec0 1771839654 S Ci:1:001:0 s a3 00 0003 0004 4 <
d0bb4ec0 1771839674 C Ci:1:001:0 0 4 = 0001
d0bb4ec0 1771865434 S Ci:1:001:0 s a3 00 0003 0004 4 <
d0bb4ec0 1771865502 C Ci:1:001:0 0 4 = 0001
d0bb4ec0 1771891440 S Ci:1:001:0 s a3 00 0003 0004 4 <
d0bb4ec0 1771891507 C Ci:1:001:0 0 4 = 0001
d0bb4ec0 1771917436 S Ci:1:001:0 s a3 00 00
Re: [PATCH] USB: mark USB drivers as being GPL only
On Die, 2008-02-05 at 21:48 +1030, David Newall wrote: > Bernd Petrovitsch writes: > > On Mon, 2008-02-04 at 01:37 +1030, David Newall wrote: > > [...] > >> disadvantage Linux with respect to many classes of devices, for example > >> GSM transceivers when used in those parts of the world^ where regulatory > >> requirements prohibit modification of power or frequency settings, which > >> effectively prohibits open-source driver. BTW the (trivial?) solution for the hardware manufacturer: People must use/download some signed binary blurb which actually configures the limits of the configurable values. > > Are you sure that that is not only (the results of) propaganda of > > (certain) proprietary companies? > > well, yes. > > > Usually the *user* (at home, wherever) sets "illegal" values. So it's > > the users responsibility and the manufacturer, importer or sellers don't > > care (if only that can't prevent other "illegal" actions like "beating > > some to death with $WLAN_ROUTER"). > > Or, as is the case perhaps almost everywhere, governments prohibit devices There are rumors/stories that even the FCC in .us doesn't go after producers/vendors/sellers of devices which may be operated beyond governmental requirements. With exactly my comparison BTW. Does the FCC forbid the *operating* or the *distribution*? > that can operate outside of local requirements. At least in .at it is not forbidden to import and/or sell devices which *can* be operated outside some local law requirements. If *you* configure it wrong, *you* have violated the law/rules and it is thus in *your* responsibility. The first reason is that there are European Union laws which basically override the local Austrian laws - but we can ignore that as it is a European Union thing. One (non-technical) reason is that even those requirements change over time. Another reason is that e.g. setting the transmit power on some common WLAN devices to the minimal possible values (which the hardware allows) doesn't imply staying within legal bounds: I can have a (common of the shelf!) high-quality antenna and not-so-bad cabling and than I'm beyond the officially allowed maximum transmit power. A third (non-technical) reason is that I (as a pure private person/organization) may have some explicit governmental exception of the governmental limits (for whatever reason). I concur that there might be governments which forbid importing/selling/distributing devices where legal usage is absolutely not possible. But historically at least in .at, these devices were simply marked "for export only". "Problem" solved. > > Or do you get a gun manufacturer before court just because someone > > committed a crime with a its gun? > > Let's not confuse the issue. It's IMHO precisely the issue (at least with my understanding of law stuff): Which action is illegal and who is responsible for it. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] bugfix for an underflow condition in usb storage & isd200.c
On Tue, 5 Feb 2008, Boaz Harrosh wrote:
> > However the interface to usb_stor_access_xfer_buf() will have to change
> > slightly. Right now if it sees that *sgptr is NULL, it assumes this
> > means it should start at the beginning of the s-g buffer. But with
> > Boaz's change, *sgptr == NULL means the transfer has reached the end of
> > the buffer. So I'll have to go through and audit all the callers.
> >
> > Alan Stern
> >
> > -
> No it does not, this as not changed. Please look again.
You look again. Your patched code goes like this:
struct scatterlist *sg = *sgptr;
if (!sg)
sg = (struct scatterlist *) srb->request_buffer;
Hence if *sgptr is NULL upon entry, it is taken to mean that the
transfer should start at the beginning of the s-g buffer.
/* This loop handles a single s-g list entry, which may
* include multiple pages. Find the initial page structure
* and the starting offset within the page, and update
* the *offset and *index values for the next loop. */
cnt = 0;
while (cnt < buflen && sg) {
Hence if sg is NULL, it indicates the end of the buffer has been
reached. And then down near the end of the routine:
*sgptr = sg;
Hence if the end is reached and the caller makes another call to try
transferring more data, the additional data will get stored back at the
beginning of the buffer.
> Note that this patch was tested and working. It is a bug
> in v2.2.24 and it should be accepted already. One way or
> the other.
>
> Callers of usb_stor_access_xfer_buf() need not change.
> Matthew Dharm should decide if he wants the WARN_ON in
> usb_stor_set_xfer_buf() or not and be done with it.
>
> I have found and fixed the bug, but it is not a SCSI
> related bug, and it is not do to any scsi changes. It
> is a bug from the SG changes of early 2.6.24. Please
> take it through the USB tree. Feel free to change it
> the way you like it, and submit it.
I will post a new version of this which handles all these issues.
Expect it in a day or so.
Alan Stern
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 4/7] drivers/usb/storage/sddr55.c: fix uninitialized var warnings
On Mon, 4 Feb 2008 [EMAIL PROTECTED] wrote:
> From: Andrew Morton <[EMAIL PROTECTED]>
>
> drivers/usb/storage/sddr55.c: In function 'sddr55_transport':
> drivers/usb/storage/sddr55.c:526: warning: 'deviceID' may be used
> uninitialized in this function
> drivers/usb/storage/sddr55.c:525: warning: 'manufacturerID' may be used
> uninitialized in this function
Unless your version of this routine is significantly different from
mine, those warnings are totally bogus.
> drivers/usb/storage/sddr55.c |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff -puN
> drivers/usb/storage/sddr55.c~drivers-usb-storage-sddr55c-fix-uninitialized-var-warnings
> drivers/usb/storage/sddr55.c
> ---
> a/drivers/usb/storage/sddr55.c~drivers-usb-storage-sddr55c-fix-uninitialized-var-warnings
> +++ a/drivers/usb/storage/sddr55.c
> @@ -522,8 +522,8 @@ int sddr55_reset(struct us_data *us) {
>
> static unsigned long sddr55_get_capacity(struct us_data *us) {
>
> - unsigned char manufacturerID;
> - unsigned char deviceID;
> + unsigned char uninitialized_var(manufacturerID);
> + unsigned char uninitialized_var(deviceID);
> int result;
> struct sddr55_card_info *info = (struct sddr55_card_info *)us->extra;
Following this I have:
US_DEBUGP("Reading capacity...\n");
result = sddr55_read_deviceID(us,
&manufacturerID,
&deviceID);
The variables are set by sddr55_read_deviceID(). So what's up?
Compiler bug?
Alan Stern
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB device doesn't get address
On Tue, 5 Feb 2008, Fabio Venturi wrote:
> I've tried to patch quirks.c with:
> +{ USB_DEVICE(0x10d6, 0x2200), .driver_info =
> USB_QUIRK_STRING_FETCH_255},
>
> and also with
>
> +{ USB_DEVICE(0xd610, 0x2200), .driver_info =
> USB_QUIRK_STRING_FETCH_255},
>
> since i saw this line in the usbmon output:
> d0bb4ec0 1770330276 C Ci:1:000:0 0 18 = 12010002 ff40 d6100022
> 00010102 0301
The two values in that line are in little-endian format. That means
they represent the numbers 0x10d6 and 0x2200.
> Anyway the problem persists and
> that's the usbmon output with the 2nd patch:
But the second patch is wrong. What's the output with the first patch?
Alan Stern
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB device doesn't get address
On Tue, Feb 05, 2008 at 10:43:46AM -0500, Alan Stern wrote:
> On Tue, 5 Feb 2008, Fabio Venturi wrote:
>
> > I've tried to patch quirks.c with:
> > + { USB_DEVICE(0x10d6, 0x2200), .driver_info =
> > USB_QUIRK_STRING_FETCH_255},
> >
> > and also with
> >
> > + { USB_DEVICE(0xd610, 0x2200), .driver_info =
> > USB_QUIRK_STRING_FETCH_255},
> >
> > since i saw this line in the usbmon output:
> > d0bb4ec0 1770330276 C Ci:1:000:0 0 18 = 12010002 ff40 d6100022
> > 00010102 0301
>
> The two values in that line are in little-endian format. That means
> they represent the numbers 0x10d6 and 0x2200.
> > Anyway the problem persists and
> > that's the usbmon output with the 2nd patch:
>
> But the second patch is wrong. What's the output with the first patch?
>
> Alan Stern
>
> -
OK, that's the output with the first patch:
d14bab40 3335880090 C Ii:1:001:1 0:2048 1 = 08
d14bab40 3335880106 S Ii:1:001:1 -115:2048 4 <
d14ba9c0 3335880239 S Ci:1:001:0 s a3 00 0003 0004 4 <
d14ba9c0 3335880254 C Ci:1:001:0 0 4 = 01050100
d14ba9c0 3335880266 S Co:1:001:0 s 23 01 0010 0003 0
d14ba9c0 3335880278 C Co:1:001:0 0 0
d14ba9c0 3335880288 S Ci:1:001:0 s a3 00 0003 0004 4 <
d14ba9c0 3335880299 C Ci:1:001:0 0 4 = 0105
d14ba9c0 3335905340 S Ci:1:001:0 s a3 00 0003 0004 4 <
d14ba9c0 3335905368 C Ci:1:001:0 0 4 = 0105
d14ba9c0 3335931351 S Ci:1:001:0 s a3 00 0003 0004 4 <
d14ba9c0 3335931368 C Ci:1:001:0 0 4 = 0105
d14ba9c0 3335957338 S Ci:1:001:0 s a3 00 0003 0004 4 <
d14ba9c0 3335957367 C Ci:1:001:0 0 4 = 0105
d14ba9c0 3335983337 S Ci:1:001:0 s a3 00 0003 0004 4 <
d14ba9c0 3335983356 C Ci:1:001:0 0 4 = 0105
d14ba9c0 3335983373 S Co:1:001:0 s 23 03 0004 0003 0
d14ba9c0 3335983385 C Co:1:001:0 0 0
d14ba9c0 3336034502 S Ci:1:001:0 s a3 00 0003 0004 4 <
d14ba9c0 3336034820 C Ci:1:001:0 0 4 = 03051000
d14ba9c0 3336085338 S Co:1:001:0 s 23 01 0014 0003 0
d14ba9c0 3336085374 C Co:1:001:0 0 0
d14ba9c0 3336085622 S Ci:1:000:0 s 80 06 0100 0040 64 <
d14ba9c0 3336086186 C Ci:1:000:0 0 18 = 12010002 ff40 d6100022
00010102 0301
d14ba9c0 3336086206 S Co:1:001:0 s 23 03 0004 0003 0
d14ba9c0 3336086218 C Co:1:001:0 0 0
d14ba9c0 3336136344 S Ci:1:001:0 s a3 00 0003 0004 4 <
d14ba9c0 3336136664 C Ci:1:001:0 0 4 = 03051000
d14ba9c0 3336187335 S Co:1:001:0 s 23 01 0014 0003 0
d14ba9c0 3336187358 C Co:1:001:0 0 0
d14ba9c0 3336187370 S Co:1:000:0 s 00 05 0004 0
d14ba9c0 3336187527 C Co:1:000:0 0 0
d14ba9c0 3336199340 S Ci:1:004:0 s 80 06 0100 0012 18 <
d14ba9c0 3336199648 C Ci:1:004:0 0 18 = 12010002 ff40 d6100022
00010102 0301
d14ba9c0 3336199674 S Ci:1:004:0 s 80 06 0200 0009 9 <
d14ba9c0 3336199772 C Ci:1:004:0 0 9 = 09022700 0101ee80 96
d14ba9c0 3336199790 S Ci:1:004:0 s 80 06 0200 0027 39 <
d14ba9c0 3336199896 C Ci:1:004:0 0 39 = 09022700 0101ee80 96090400
00030805 5705 01020002 00070582 02000200
d14bac40 3336200112 S Ci:1:004:0 s 80 06 0300 00ff 255 <
d14bac40 3336200272 C Ci:1:004:0 0 4 = 04030904
d14bac40 3336200290 S Ci:1:004:0 s 80 06 0302 0409 00ff 255 <
d14bac40 3336200896 C Ci:1:004:0 0 52 = 34034100 63007400 69006f00
6e007300 20004d00 74007000 20004400 65007600
d14bac40 3336200918 S Ci:1:004:0 s 80 06 0301 0409 00ff 255 <
d14bac40 3337593338 C Ci:1:004:0 -71 64 = 40034100 63007400 69006f00
6e007300 20005300 65006d00 69006300 6f006e00
d14bab40 3337593353 C Ii:1:001:1 0:2048 1 = 08
d14bab40 3337593360 S Ii:1:001:1 -115:2048 4 <
d14bac40 3337593452 S Ci:1:004:0 s 80 06 0301 0409 0002 2 <
d14bac40 3337593576 C Ci:1:004:0 -71 0
d14bac40 3337593593 S Ci:1:004:0 s 80 06 0303 0409 00ff 255 <
d14bac40 3337593824 C Ci:1:004:0 -71 0
d14bac40 3337593838 S Ci:1:004:0 s 80 06 0303 0409 0002 2 <
d14bac40 3337594074 C Ci:1:004:0 -71 0
d14bac40 3337595077 S Co:1:004:0 s 00 09 0001 0
d14bac40 3337595202 C Co:1:004:0 -71 0
d14bac40 3337595364 S Ci:1:001:0 s a3 00 0003 0004 4 <
d14bac40 3337595381 C Ci:1:001:0 0 4 = 00010100
d14bac40 3337595393 S Co:1:001:0 s 23 01 0010 0003 0
d14bac40 3337595405 C Co:1:001:0 0 0
d14ba9c0 3337595813 S Ci:1:001:0 s a3 00 0003 0004 4 <
d14ba9c0 3337595832 C Ci:1:001:0 0 4 = 0001
d14ba9c0 3337621340 S Ci:1:001:0 s a3 00 0003 0004 4 <
d14ba9c0 3337621405 C Ci:1:001:0 0 4 = 0001
d14bac40 3337647492 S Ci:1:001:0 s a3 00 0003 0004 4 <
d14bac40 3337647551 C Ci:1:001:0 0 4 = 0001
d14ba9c0 3337673342 S Ci:1:001:0 s a3 00 0003 0004 4 <
d14ba9c0 3337673410 C Ci:1:001:0 0 4 = 0001
d14ba9c0 3337699335 S Ci:1:001:0 s a3 00 0003 0004 4 <
d14ba9c0 3337699391 C Ci:1:001:0 0 4 = 0001
Fabio
___
Messaggio analizzato e protetto da tecnologia antivirus
Servizio erogato dal sistema informativo della
Presidenza del Consiglio dei Ministri
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vg
Re: [PATCH] bugfix for an underflow condition in usb storage & isd200.c
On Tue, Feb 05 2008 at 17:42 +0200, Alan Stern <[EMAIL PROTECTED]> wrote:
> On Tue, 5 Feb 2008, Boaz Harrosh wrote:
>
>>> However the interface to usb_stor_access_xfer_buf() will have to change
>>> slightly. Right now if it sees that *sgptr is NULL, it assumes this
>>> means it should start at the beginning of the s-g buffer. But with
>>> Boaz's change, *sgptr == NULL means the transfer has reached the end of
>>> the buffer. So I'll have to go through and audit all the callers.
>>>
>>> Alan Stern
>>>
>>> -
>> No it does not, this as not changed. Please look again.
>
> You look again. Your patched code goes like this:
>
> struct scatterlist *sg = *sgptr;
>
> if (!sg)
> sg = (struct scatterlist *) srb->request_buffer;
>
> Hence if *sgptr is NULL upon entry, it is taken to mean that the
> transfer should start at the beginning of the s-g buffer.
>
> /* This loop handles a single s-g list entry, which may
>* include multiple pages. Find the initial page structure
>* and the starting offset within the page, and update
>* the *offset and *index values for the next loop. */
> cnt = 0;
> while (cnt < buflen && sg) {
>
> Hence if sg is NULL, it indicates the end of the buffer has been
> reached. And then down near the end of the routine:
>
> *sgptr = sg;
>
> Hence if the end is reached and the caller makes another call to try
> transferring more data, the additional data will get stored back at the
> beginning of the buffer.
>
That behavior did not change. In the likely event of sg-length matching
bufflen the last call to sg_next will return NULL, and will be returned
in *sgptr. The end condition of an outside caller is either sum of
returned counts reaching some target count, or *sgptr return to NULL.
The code before the sg change would have *indexptr >= some_sg_count, but
now we do not have an index we have a pointer and the termination condition
is *sgptr == NULL.
So I guess you are afraid that calling code that was converted from index
to pointer, was done wrong, and where something did *indexptr >= some_sg_count
before, does not do *sgptr == NULL now.
So I guess, yes you are welcome to check. I did not do the conversion so
I can not comment.
>> Note that this patch was tested and working. It is a bug
>> in v2.2.24 and it should be accepted already. One way or
>> the other.
>>
>> Callers of usb_stor_access_xfer_buf() need not change.
>> Matthew Dharm should decide if he wants the WARN_ON in
>> usb_stor_set_xfer_buf() or not and be done with it.
>>
>> I have found and fixed the bug, but it is not a SCSI
>> related bug, and it is not do to any scsi changes. It
>> is a bug from the SG changes of early 2.6.24. Please
>> take it through the USB tree. Feel free to change it
>> the way you like it, and submit it.
>
> I will post a new version of this which handles all these issues.
> Expect it in a day or so.
>
Please do. Thanks, that would be better.
Don't forget to also submit a patch for current head-of-line. It's exactly
the same fix but has diff conflicts with surrounding code.
> Alan Stern
>
Boaz
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] bugfix for an underflow condition in usb storage & isd200.c
On Mon, Feb 04, 2008 at 03:05:58PM -0500, Alan Stern wrote: > On Sun, 3 Feb 2008, Matthew Dharm wrote: > > I think the correct approach is to modify those routines so that they > will never overrun the s-g buffer (like Boaz has done), and _document_ > this behavior. Then the callers can feel free to try and transfer as > much as they want, knowing that an overrun can't occur. There won't > be any need for a WARN_ON or anything else. Six of one and a half-dozen of the other. All we're arguing over is the definition of "correct behavior" here. You want to change the API so that overrun is acceptable and handled; I prefer calling it a Bad Thing(tm). We both agree that the code shouldn't run off the end of the s-g list. Since you've already committed to updating the patch, then we can do it your way. Just make sure it's very very clear in the comments. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver E: You run this ship with Windows?! YOU IDIOT! L: Give me a break, it came bundled with the computer! -- ESR and Lan Solaris User Friendly, 12/8/1998 pgpRWES13MJJo.pgp Description: PGP signature
EHCI shutdown question
Hi Dave, I've been looking at ehci_shutdown() in ehci-hcd.c with increasing puzzlement. Why shut off port power before attempting to stop the host controller from processing the periodic and async schedules? It seems like you want to allow the host to complete whatever transactions it was in the middle of. If ehci_shutdown() is trying to stop attach/detach notifications, that will only work if the host controller supports port power switching. ehci_shutdown() also calls ehci_reset() after shutting down the schedules. However, AFAIK the run/stop bit is never set before ehci_reset() is called. The EHCI specification says that resetting a running HC is "will result in undefined behavior." ehci_quiesce() is only called from ehci_shutdown(), so why not send a halt command there? Some of these answers may be in the bitkeeper history, but that's taking a while to download. :) Sarah Sharp - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB device doesn't get address
On Tue, 5 Feb 2008, Fabio Venturi wrote:
> Opppsss!!!
> Too many outputs to deal with :(
> I'm not sure that was right,
> this is right one for sure:
>
> + { USB_DEVICE(0x10d6, 0x2200), .driver_info = USB_QUIRK_STRING_FETCH_255},
This patch should not have produced the output you posted. Are you
sure the patched module was installed and running? The easiest way to
tell is to have CONFIG_USB_DEBUG enabled and see if the dmesg log says
anything about a USB quirk when you plug in the device.
Alan Stern
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 4/7] drivers/usb/storage/sddr55.c: fix uninitialized var warnings
On Tue, 5 Feb 2008 10:36:16 -0500 (EST) Alan Stern <[EMAIL PROTECTED]> wrote:
> On Mon, 4 Feb 2008 [EMAIL PROTECTED] wrote:
>
> > From: Andrew Morton <[EMAIL PROTECTED]>
> >
> > drivers/usb/storage/sddr55.c: In function 'sddr55_transport':
> > drivers/usb/storage/sddr55.c:526: warning: 'deviceID' may be used
> > uninitialized in this function
> > drivers/usb/storage/sddr55.c:525: warning: 'manufacturerID' may be used
> > uninitialized in this function
>
> Unless your version of this routine is significantly different from
> mine, those warnings are totally bogus.
>
> > drivers/usb/storage/sddr55.c |4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff -puN
> > drivers/usb/storage/sddr55.c~drivers-usb-storage-sddr55c-fix-uninitialized-var-warnings
> > drivers/usb/storage/sddr55.c
> > ---
> > a/drivers/usb/storage/sddr55.c~drivers-usb-storage-sddr55c-fix-uninitialized-var-warnings
> > +++ a/drivers/usb/storage/sddr55.c
> > @@ -522,8 +522,8 @@ int sddr55_reset(struct us_data *us) {
> >
> > static unsigned long sddr55_get_capacity(struct us_data *us) {
> >
> > - unsigned char manufacturerID;
> > - unsigned char deviceID;
> > + unsigned char uninitialized_var(manufacturerID);
> > + unsigned char uninitialized_var(deviceID);
> > int result;
> > struct sddr55_card_info *info = (struct sddr55_card_info *)us->extra;
>
> Following this I have:
>
> US_DEBUGP("Reading capacity...\n");
>
> result = sddr55_read_deviceID(us,
> &manufacturerID,
> &deviceID);
>
> The variables are set by sddr55_read_deviceID(). So what's up?
> Compiler bug?
Yes, some versions of the compiler assume that foo(&bar) might not
initialise bar.
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
usbmon output to trace read/writes
Hi, I am trying to use usbmon to get a trace of low level sector read/writes being issued to a USB flash drive. I followed instructions from Documents/usb/usbmon.txt with the following configuration: - USB mounted as vfat on /mnt/usb - Linux 2.6.19 on ARM - usbmon, debugfs built into the kernel - cat /sys/kernel/debug/usbmon/1t > /tmp/log to log data. The problem is, I see the following in /tmp/log (no data words): c04087dc 57025 C Bo:002:02 0 31 > c000ec14 57209 S Bo:002:02 -115 512 D c000ec14 60023 C Bo:002:02 0 512 > c04087dc 60180 S Bi:002:01 -115 13 < c04087dc 62013 C Bi:002:01 0 13 D c04087dc 676639055 S Bo:002:02 -115 31 D I have done this in the past on a PC and got more detailed messages that had the data words. For example: ca6a349c 3984599108 S Bo:004:02 -115 31 = 55534243 4900 0040 8a28 2020 00 from which I could interpret the SCSI code such as 0x28 for read etc. Now I just get "S Bo:002:02 -115 512 D" instead for example. Is there some kernel configuration that needs to be set to get more detailed messages dumped by usbmon ? I do not have my old PC to compare the kernel configuration files :( Any insights would be appreciated. thanks in advance, -siddharth Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: mark USB drivers as being GPL only
Hi David, > > I think you're missing my point: as long as the license stays the way > > it is now, you can never distribute proprietary code unless you've > > consulted a lawyer and even then you run the risk of being sued for > > infringement if the copyright holder thinks what you have is derived > > work. > > Yes I can, if the proprietary code is not linked with GPL code (and the > proprietary code is original). Loadable modules are not linked. This is a > very clear-cut case. that is not clear-cut case. You link at run-time. Otherwise the module would do nothing. Regards Marcel - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Gadget driver repository?
I was wondering where (or if) there were any non-mainlined gadget drivers that were kept anywhere? According to (2005) http://www.linux-usb.org/gadget/ > Other controller and gadget drivers are in development, but are unreleased > or not published here. Examples that have seen some degree of light > include: > > * HID driver (userspace, with gadgetfs), > * "MTP" (Media Transfer Protocol, PTP++) driver (userspace, >with gadgetfs), * two different printer class drivers (used >in various products), > * audio class driver (very experimental). > * video class driver (very experimental). I'm actually looking for the gadget side of HID and Audio and anyone has any pointers? Thanks - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: mark USB drivers as being GPL only
Hi David, > > if a new drivers is originally written for Linux, then you are breaking > > the GPL. > > Completely wrong. However if the driver is distributed as built-in, then it > would need to be licensed under GPL. This means that a driver can be > written and distributed as a module under any licence, proprietary or > otherwise, presumably with the restriction that it may NOT be built-in. how to do you wanna write a new original Linux driver (modular or built-in) without creating derivative work. This is not possible and due to the fact that it is derivative work the driver becomes automatically licensed under GPL. This is not a gray area. The gray area that exists if you have code that was written for some other operating system and licensed under some proprietary license in the first place. And now that code is used in conjunction with a glue layer to make it loadable as kernel module. > > You driver was meant to be > > running as Linux kernel module and thus it is derivative work. > > It is precisely the fact that it is a loadable module, and does not form > part of the kernel, that removes the requirement to distribute it under GPL. That is such a nonsense. Stop distributing FUD and start talking to a lawyer. You are clearly under some weird impression what the GPL means and what it implies. > > What are you arguing here. It makes no difference if it is technical or > > not. The EXPORT_SYMBOL_GPL gives you a clear hint that when using this > > symbol, you have to obey to the GPL. > > And that "hint" is a lie. If the developers say that this symbol can only be used in GPL code (and with EXPORT_SYMBOL_GPL it is quite clear) then you have to obey to that license or don't use this symbol at all. If you use that symbol inside non-GPL (meaning you link at runtime) then you are in violation of the GPL license. We can't make it much clearer. Regards Marcel - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: mark USB drivers as being GPL only
Marcel Holtmann wrote: If the developers say that this symbol can only be used in GPL code (and with EXPORT_SYMBOL_GPL it is quite clear) then you have to obey to that license or don't use this symbol at all. If you use that symbol inside non-GPL (meaning you link at runtime) then you are in violation of the GPL license. We can't make it much clearer. Not necessarily so. The developers feel that any code using that symbol is necessarily a derivative work, but at the end of the day it would be up to the legal system to decide whether it really is or not. If the courts decided that the symbol could be used and the driver wouldn't be a derivative work, it would be perfectly legal to use a GPL'd shim to "re-export" the symbol, essentially stripping off the GPL-only protection for that symbol. In our group all kernel modules that we write are GPL'd, as it lets us sleep at night, simplifies our lives, and makes the lawyers much happier. Other people may be willing to take more risks. Chris - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: mark USB drivers as being GPL only
On Tue, Feb 05, 2008 at 10:09:07PM +1030, David Newall wrote: > Marcel Holtmann writes: >> if a new drivers is originally written for Linux, then you are breaking >> the GPL. > > Completely wrong. However if the driver is distributed as built-in, then > it would need to be licensed under GPL. This means that a driver can be > written and distributed as a module under any licence, proprietary or > otherwise, presumably with the restriction that it may NOT be built-in. Again, you are wrong, as per the recommendations of every lawyer I have ever talked to (and unfortunatly, that's a lot...) It's fine for you to feel differently, and you yourself can act however you want to, but as you do not hold any copyright on any portions of the Linux kernel code, please do not speak as if your statements hold any weight. In the end, it's up to the copyright holders to enforce the license. And as I have stated in the past, a number of them have made public statements as to what they think about this issue. And it corresponds exactly with what Marcel has stated above. So if you wish to violate the copyright of others, you take the risk that you might be caught and punished, something that you and your legal council needs to take into account. thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usbmon output to trace read/writes
On Tue, 5 Feb 2008 11:17:46 -0800 (PST), Siddharth Choudhuri <[EMAIL PROTECTED]> wrote: > - Linux 2.6.19 on ARM > The problem is, I see the following in /tmp/log (no data words): > c04087dc 57025 C Bo:002:02 0 31 > > c000ec14 57209 S Bo:002:02 -115 512 D The problem stems from the fact that usbmon's hooks may not have access to the virtual address of the data. On cache-coherent architectures, such as x86, usbmon works around it by remapping data temporarily. I think the problem should be transparent if you look at the code in and around usb_hcd_submit_urb(). You can change usb-storage to not pre-map commands and replies easily, but data often comes from the highmem zone and thus kernel does not have its virtual address. So, if you want to see the data, you need to attack the main issue. If you find a way to implement mon_dmapeek() for ARM, I'll be happy to include it. -- Pete - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: EHCI shutdown question
On Wednesday 30 January 2008, Sarah Sharp wrote:
> Hi Dave,
>
> I've been looking at ehci_shutdown() in ehci-hcd.c with increasing puzzlement.
I'm puzzled by your puzzlement. ;)
static void
ehci_shutdown (struct usb_hcd *hcd)
{
struct ehci_hcd *ehci;
ehci = hcd_to_ehci (hcd);
(void) ehci_halt (ehci);
ehci_turn_off_all_ports(ehci);
/* make BIOS/etc use companion controller during reboot */
ehci_writel(ehci, 0, &ehci->regs->configured_flag);
/* unblock posted writes */
ehci_readl(ehci, &ehci->regs->configured_flag);
}
> Why shut off port power before attempting to stop the host controller from
> processing the periodic and async schedules?
Which lines makes you think it does that? The call to ehci_halt() should
stop all processing -- first. The ehci_turn_off_all_ports() will then
clear PORT_POWER, on systems which allow that.
> It seems like you want to allow
> the host to complete whatever transactions it was in the middle of.
Given the system is shutting down, and that every driver with pending
transactions already had its chance to insist they complete ... no.
> If ehci_shutdown() is trying to stop attach/detach notifications,
The ehci_halt() code disables the IRQs. There is a minor oddity
there, in that this code isn't grabbing the spinlock ... which
means that some other CPU could poll the hardware too. And nothing
update the HCD state. Feel free to submit a patchlet to fix those.
> that will only
> work if the host controller supports port power switching.
Actually that's somewhat silicon-specific. I agree that it would make
more sense to expect the root hub to work without the RUN bit set, since
key parts of it can be done with combinatoric logic rather than needing
latches that are clocked by more than a bus write cycle. (And one might
expect multi-MHz clocks to be off until RUN is set, or on power-aware
designs to be gated off until some high speed port activity requires it.)
But that's not how the EHCI spec is written ... and some implementations
of the root hub really _don't_ work unless RUN is set.
The reason to try powering off the ports is that, well, the system is
shutting down. Why waste (potentially battery) power? Whatever runs
next can turn it back on if it wants. And if PPS isn't set, then trying
to clear the per-port power-enabled flag is supposed to be a NOP.
> ehci_shutdown() also calls ehci_reset() after shutting down the schedules.
Ah, not the version I'm looking at (above), from current GIT.
- Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: mark USB drivers as being GPL only
Hi Chris, > > If the developers say that this symbol can only be used in GPL code (and > > with EXPORT_SYMBOL_GPL it is quite clear) then you have to obey to that > > license or don't use this symbol at all. > > > > If you use that symbol inside non-GPL (meaning you link at runtime) then > > you are in violation of the GPL license. We can't make it much clearer. > > Not necessarily so. The developers feel that any code using that symbol > is necessarily a derivative work, but at the end of the day it would be > up to the legal system to decide whether it really is or not. > > If the courts decided that the symbol could be used and the driver > wouldn't be a derivative work, it would be perfectly legal to use a > GPL'd shim to "re-export" the symbol, essentially stripping off the > GPL-only protection for that symbol. I agree with you that a court can decide that the usage of a EXPORT_SYMBOL_GPL symbol is not derivative work, but I see the likelihood of this happening as almost non existent. And even if so then you still have to deal with the fact that the license of this symbol is clearly GPL. No questions asked about that, because it says so and due technical means you can't load a non-GPL kernel module that uses EXPORT_SYMBOL_GPL symbol without tainting the kernel. The same fact is valid in userspace where you can't link (not even runtime) a GPL library into a non-GPL program. However if anyone wants to fight the license, be my guest and do so :) > In our group all kernel modules that we write are GPL'd, as it lets us > sleep at night, simplifies our lives, and makes the lawyers much > happier. Other people may be willing to take more risks. All big companies are going this way. And licenses beside, there are valid technical points in making your driver open source and get it merged upstream. Just a hint for all these binary-only people :) Regards Marcel - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: EHCI shutdown question
On Tue, Feb 05, 2008 at 12:43:49PM -0800, David Brownell wrote:
> On Wednesday 30 January 2008, Sarah Sharp wrote:
> > Hi Dave,
> >
> > I've been looking at ehci_shutdown() in ehci-hcd.c with increasing
> > puzzlement.
>
> I'm puzzled by your puzzlement. ;)
>
> static void
> ehci_shutdown (struct usb_hcd *hcd)
> {
> struct ehci_hcd *ehci;
>
> ehci = hcd_to_ehci (hcd);
> (void) ehci_halt (ehci);
> ehci_turn_off_all_ports(ehci);
>
> /* make BIOS/etc use companion controller during reboot */
> ehci_writel(ehci, 0, &ehci->regs->configured_flag);
>
> /* unblock posted writes */
> ehci_readl(ehci, &ehci->regs->configured_flag);
> }
Whoops, I meant ehci_stop(). Do my questions make more sense now?
> > Why shut off port power before attempting to stop the host controller from
> > processing the periodic and async schedules?
>
> Which lines makes you think it does that? The call to ehci_halt() should
> stop all processing -- first. The ehci_turn_off_all_ports() will then
> clear PORT_POWER, on systems which allow that.
>
>
> > It seems like you want to allow
> > the host to complete whatever transactions it was in the middle of.
>
> Given the system is shutting down, and that every driver with pending
> transactions already had its chance to insist they complete ... no.
>
>
> > If ehci_shutdown() is trying to stop attach/detach notifications,
>
> The ehci_halt() code disables the IRQs. There is a minor oddity
> there, in that this code isn't grabbing the spinlock ... which
> means that some other CPU could poll the hardware too. And nothing
> update the HCD state. Feel free to submit a patchlet to fix those.
>
>
> > that will only
> > work if the host controller supports port power switching.
>
> Actually that's somewhat silicon-specific. I agree that it would make
> more sense to expect the root hub to work without the RUN bit set, since
> key parts of it can be done with combinatoric logic rather than needing
> latches that are clocked by more than a bus write cycle. (And one might
> expect multi-MHz clocks to be off until RUN is set, or on power-aware
> designs to be gated off until some high speed port activity requires it.)
>
> But that's not how the EHCI spec is written ... and some implementations
> of the root hub really _don't_ work unless RUN is set.
>
> The reason to try powering off the ports is that, well, the system is
> shutting down. Why waste (potentially battery) power? Whatever runs
> next can turn it back on if it wants. And if PPS isn't set, then trying
> to clear the per-port power-enabled flag is supposed to be a NOP.
>
>
> > ehci_shutdown() also calls ehci_reset() after shutting down the schedules.
>
> Ah, not the version I'm looking at (above), from current GIT.
>
> - Dave
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: EHCI shutdown question
On Tue, 5 Feb 2008, David Brownell wrote: > The reason to try powering off the ports is that, well, the system is > shutting down. Why waste (potentially battery) power? Whatever runs > next can turn it back on if it wants. And if PPS isn't set, then trying > to clear the per-port power-enabled flag is supposed to be a NOP. There's another reason for powering off the ports during shutdown -- without it, some mahcines would reboot instead of shutting down! Arguably this may have been an ACPI or BIOS bug rather than EHCI, but nevertheless, the fix worked. See http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=8903795a5275e0366acf961190c57074ad27f9bb and http://bugzilla.kernel.org/show_bug.cgi?id=7828 Alan Stern - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usbmon output to trace read/writes
On Tue, 5 Feb 2008, Pete Zaitcev wrote: > The problem stems from the fact that usbmon's hooks may not have > access to the virtual address of the data. On cache-coherent > architectures, such as x86, usbmon works around it by remapping > data temporarily. I think the problem should be transparent if > you look at the code in and around usb_hcd_submit_urb(). > > You can change usb-storage to not pre-map commands and replies > easily, but data often comes from the highmem zone and thus > kernel does not have its virtual address. In such cases the page number is stored in a scatter-gather entry. Should we modify the core to keep a copy of the page number in the URB, for use by mon_dmapeek()? Of course, this could be confusing. If an URB is pre-mapped for DMA, then usbmon wouldn't know whether to look in the transfer_buffer field for the virtual address or in the new page-number field. Sometimes neither might be valid. Alan Stern - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2.6.24 REGRESSION] BUG: Soft lockup - with VFS
On Tue, 5 Feb 2008 22:48:29 +0100 "Oliver Pinter" <[EMAIL PROTECTED]> wrote: > On 2/5/08, Oliver Pinter <[EMAIL PROTECTED]> wrote: > > http://students.zipernowsky.hu/~oliverp/kernel/regression_2624/ > > > > uploaded: > > kernel image > > .config > > new pictures > > lspci > > lsusb > > > > - > > > > when read for /dev/uba then crashed the kernel, the read is egal, thet > > dd or mount is ... Looks like you deadlocked in ub_request_fn(). I assume that you were using ub.c in 2.6.23 and that it worked OK? If so, we broke it, possibly via changes to the core block layer. I think ub.c is basically abandoned in favour of usb-storage. If so, perhaps we should remove or disble ub.c? - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: EHCI shutdown question
On Wednesday 30 January 2008, Sarah Sharp wrote: > Hi Dave, > > I've been looking at ehci_shutdown() in ehci-hcd.c with increasing puzzlement. And you later corrected: you mean ehci_stop() every where you wrote ehci_shutdown. I've corrected that below, for clarity. Ideally that should share more code with ehci_shutdown(). The main difference being that shutdown() can be sloppier since the kernel image is going away ... while stop() can't leave any loose ends around which would affect a later "modprobe ehci-hcd". > Why shut off port power before attempting to stop the host controller from > processing the periodic and async schedules? That should indeed be done later. In fact it should probably do what ehci_shutdown() does ... differences being that stop() probably couldn't avoid the msleep(), if that's even needed, and certainly can't get away with leaving debris in misbehaving I/O queues. Likewise ehci_shutdown() should kill those timers too, so they don't fire before this kernel stops. > It seems like you want to allow > the host to complete whatever transactions it was in the middle of. I think ehci_stop() is committing overkill here, for the reasons I gave before: children already had an opportunity to cleanly shut stuff down. Some of this code predates the usbcore cleanups which ensured that the device tree was sanely managed, and before ehci_shutdown() existed. > If > ehci_stop() is trying to stop attach/detach notifications, that will only > work if the host controller supports port power switching. The root hub will already have been shut down. > ehci_stop() also calls ehci_reset() after shutting down the schedules. > However, AFAIK the run/stop bit is never set before ehci_reset() is called. > The > EHCI specification says that resetting a running HC is "will result in > undefined > behavior." See above ... this should all get cleaned up by having the first part of ehci_stop() just call ehci_shutdown(), with ehci_shutdown() modified by making it grab the spinlock and nuke those timers. > ehci_quiesce() is only called from ehci_stop() so why not send > a halt command there? You're wrong about ehci_quiesce() ... the hub code uses that. - Dave - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: mark USB drivers as being GPL only
Marcel Holtmann wrote: how to do you wanna write a new original Linux driver (modular or built-in) without creating derivative work. This is not possible and due to the fact that it is derivative work the driver becomes automatically licensed under GPL. This is not a gray area. By not using any of the Linux kernel includes or libraries ? If a file was (for instance) pure standard C with no reference to the Linux Kernel, you can't argue that somehow this file (in itself) is a derivative work of the Linux kernel. Make it loadable with a (carefully licensed) shim to let it interact with the rest of the system, and nothing has changed about that particular files copyright or licensable status (but see the discussion below about collective works). The gray area that exists if you have code that was written for some other operating system and licensed under some proprietary license in the first place. And now that code is used in conjunction with a glue layer to make it loadable as kernel module. Why is this gray ? It shouldn't matter what the origin of such a file is, if the file doesn't include anything that is GPL, it (in itself) isn't derivative and doesn't get covered by the GPL. It is precisely the fact that it is a loadable module, and does not form part of the kernel, that removes the requirement to distribute it under GPL. The mechanism of linking is irrelevant. It's a matter of whether a collective work (that may include the non-GPL file talked about previously) includes GPL components. If it does, then the collective work is a derivative work of the GPL components, and the whole work has to be covered by the GPL. So while the non-GPL file could be distributed separately with a non-GPL license, as soon as you package it together with GPL components in such a way that it is not "mere aggregation", (and the fact that it interacts and indirectly depends on GPL components to operate shows clearly that it's not mere aggregation), then it becomes subject to the GPL. So if you don't want this non-GPL component to be subject to the GPL, you must distribute it independently, and get the end user to load it into their system. You can't package or distribute it with the GPL components it interacts with. Graeme Gill. - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2.6.24 REGRESSION] BUG: Soft lockup - with VFS
On Tue, 5 Feb 2008 14:05:06 -0800, Andrew Morton <[EMAIL PROTECTED]> wrote: > Looks like you deadlocked in ub_request_fn(). I assume that you were using > ub.c in 2.6.23 and that it worked OK? If so, we broke it, possibly via > changes to the core block layer. > > I think ub.c is basically abandoned in favour of usb-storage. If so, > perhaps we should remove or disble ub.c? Actually I think it may be an argument for keeping ub, if ub exposes a bug in the __blk_end_request. I'll look at the head of the thread and see if Mr. Pinter has hit anything related to Mr. Ueda's work. -- Pete - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2.6.24 REGRESSION] BUG: Soft lockup - with VFS
i reverted this commit 7d699bafe258ebd8f9b4ec182c554200b369a504 , and now compile ... On 2/5/08, Pete Zaitcev <[EMAIL PROTECTED]> wrote: > On Tue, 5 Feb 2008 14:05:06 -0800, Andrew Morton <[EMAIL PROTECTED]> > wrote: > > > Looks like you deadlocked in ub_request_fn(). I assume that you were > using > > ub.c in 2.6.23 and that it worked OK? If so, we broke it, possibly via > > changes to the core block layer. > > > > I think ub.c is basically abandoned in favour of usb-storage. If so, > > perhaps we should remove or disble ub.c? > > Actually I think it may be an argument for keeping ub, if ub exposes > a bug in the __blk_end_request. I'll look at the head of the thread > and see if Mr. Pinter has hit anything related to Mr. Ueda's work. > > -- Pete > -- Thanks, Oliver - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usbmon output to trace read/writes
On Tue, 5 Feb 2008 17:02:58 -0500 (EST), Alan Stern <[EMAIL PROTECTED]> wrote: > In such cases the page number is stored in a scatter-gather entry. > Should we modify the core to keep a copy of the page number in the URB, > for use by mon_dmapeek()? If you ask me, I'd say that rules of what is mapped and what is not have grown plenty complex already. I don't want to touch it unless we create a cleaned-up URB from scratch. -- Pete - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2.6.24 REGRESSION] BUG: Soft lockup - with VFS
/usr/data/source/git/linux-2.6/drivers/block/ub.c: In function 'ub_end_rq': /usr/data/source/git/linux-2.6/drivers/block/ub.c:819: error: implicit declaration of function 'end_that_request_first' /usr/data/source/git/linux-2.6/drivers/block/ub.c:820: error: implicit declaration of function 'end_that_request_last' make[7]: *** [drivers/block/ub.o] Error 1 make[6]: *** [drivers/block] Error 2 make[5]: *** [drivers] Error 2 make[5]: *** Waiting for unfinished jobs On 2/5/08, Oliver Pinter <[EMAIL PROTECTED]> wrote: > i reverted this commit 7d699bafe258ebd8f9b4ec182c554200b369a504 , and > now compile ... > > On 2/5/08, Pete Zaitcev <[EMAIL PROTECTED]> wrote: > > On Tue, 5 Feb 2008 14:05:06 -0800, Andrew Morton > <[EMAIL PROTECTED]> > > wrote: > > > > > Looks like you deadlocked in ub_request_fn(). I assume that you were > > using > > > ub.c in 2.6.23 and that it worked OK? If so, we broke it, possibly via > > > changes to the core block layer. > > > > > > I think ub.c is basically abandoned in favour of usb-storage. If so, > > > perhaps we should remove or disble ub.c? > > > > Actually I think it may be an argument for keeping ub, if ub exposes > > a bug in the __blk_end_request. I'll look at the head of the thread > > and see if Mr. Pinter has hit anything related to Mr. Ueda's work. > > > > -- Pete > > > > > -- > Thanks, > Oliver > -- Thanks, Oliver - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: mark USB drivers as being GPL only
Greg KH writes: No, it really is not a gray area at all, especially when you are writing a new driver for Linux. Go talk to a lawyer if you want the details. If we're still talking about whether a kernel module is required to be released under GPL, then yes, this is not a gray area. This is something that authors of original works can decide for themselves. They have no obligation to release under GPL, however they must take special care to ensure that the module does not (statically) link with the kernel. Richard Stallman (apparently, according to Pavel Roskin, although he didn't forward Richard's message as requested) said it nicely: According to Pavel Roskin, Richard Stallman said: It is not in general the case that "dynamic linking cannot violate the GPL". It depends on circumstances. Running a non-free program in a process in a GNU/Linux system is not linking of any kind with Linux. The program probably links with GNU libc, but the license of GNU libc permits that. A kernel module is akin to a process. It uses services of the kernel without being part of the kernel. However in order to use the kernel it might very well statically link with kernel support functions, such as copy_from_user(). This, it may not do without garnering a requirement to be released under GPL. That being said, a module can be written such that it only dynamically links with the kernel. Ndiswrapper is an example of how this can be done: None of the drivers that work under ndiswrapper make any direct use of the kernel, not in any way, indeed a wrapper could be written for a different operating system. There is no obligation for ndis drivers to be released under GPL, and even though they are not, they break no licence condition by calling services, even those exported as GPL-only. Bringing this back to the point, the notion that some exported symbols may be accessed by proprietary modules and others can't is wrong. The licence under which Linux is released makes no mention of this possibility, and so no such condition exists. In order to prevent proprietary modules from using a symbol, that symbol must be provided in such a way that a second module can only statically link to it. I think that precludes exporting it via EXPORT_SYMBOL or EXPORT_SYMBOL_GPL. Summarising the point: To claim all USB drivers must be released under GPL is wrong. - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: mark USB drivers as being GPL only
> If we're still talking about whether a kernel module is required to be > released under GPL, then yes, this is not a gray area. This is something Still wrong. > that authors of original works can decide for themselves. They have no Only if they are original works. > obligation to release under GPL, however they must take special care to > ensure that the module does not (statically) link with the kernel. Richard Also wrong. You really should investigate a beginners text on intellectual property law. Alan - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: mark USB drivers as being GPL only
Diego Zuccato writes: David Newall ha scritto: This does, of course, disadvantage Linux with respect to many classes of devices, for example GSM transceivers when used in those parts of the world^ where regulatory requirements prohibit modification of power or frequency settings, which effectively prohibits open-source driver. Why "of course" ? "Of course", because in many parts of the world, a device who's manufacturer fails to take reasonable steps to prevent it from being used outside regulatory limits is illegal. Providing source code not only is a failure to take those reasonable steps, but is quite the opposite. It may even be viewed as encouraging users to use it inappropriately. - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: mark USB drivers as being GPL only
On Wed, Feb 06, 2008 at 09:44:36AM +1030, David Newall wrote: > A kernel module is akin to a process. It uses services of the kernel > without being part of the kernel. No Linux does not work like this at all. Like Alan said, you really need to brush up on your basic IP law, as well as some basic technical issues regarding how the Linux kernel works before trying to make statements like this. Also see the various issues surrounding "loadable modules" and Samba, and how they have successfully enforced the "linking" and other type issues that are being discussed here (shims, "GPL condoms", etc.) with regards to the GPLv2 and derivative works. good luck, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: mark USB drivers as being GPL only
> "Of course", because in many parts of the world, a device who's manufacturer > fails to take reasonable steps to prevent it from being used outside > regulatory limits is illegal. Providing source code not only is a failure > to take those reasonable steps, but is quite the opposite. It may even be > viewed as encouraging users to use it inappropriately. To my knowledge there is no caselaw on this for software, nor is it clearly so simple - many vendors do provide source, many vendors provide windows drivers where any end user can click to specify their country and can lie trivially. Many users retrofit US firmware to non US devices and its trivial to do. Its a hard problem - if I get on the train I can change regulatory domain and wireless regulations mid trip. I'm not even sure at what point the wireless rules are deemed to change between the UK and France either - there isn't any caselaw for that ;) Some (particularly US) companies choose to take a conservative view based on their pessimistic reading of the intent of the US regulator plus the ability of the regulator to do a lot of damage to their business. The notion they are illegal is a real unknown and the market seems split on views of this. Alan - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: mark USB drivers as being GPL only
Hi Graeme, > > how to do you wanna write a new original Linux driver (modular or > > built-in) without creating derivative work. This is not possible and due > > to the fact that it is derivative work the driver becomes automatically > > licensed under GPL. This is not a gray area. > > By not using any of the Linux kernel includes or libraries ? > If a file was (for instance) pure standard C with no reference > to the Linux Kernel, you can't argue that somehow this > file (in itself) is a derivative work of the Linux kernel. > Make it loadable with a (carefully licensed) shim to let it interact > with the rest of the system, and nothing has changed > about that particular files copyright or licensable status > (but see the discussion below about collective works). if the overall intention is to write a Linux kernel module/driver then it counts as derivative work for me. No matter how tricky you are and much you try to circumvent or try to hide this fact. However that is my personal opinion. You don't have to agree with me here. Ask your legal counsel. > > The gray area that exists if you have code that was written for some > > other operating system and licensed under some proprietary license in > > the first place. And now that code is used in conjunction with a glue > > layer to make it loadable as kernel module. > > Why is this gray ? It shouldn't matter what the origin of > such a file is, if the file doesn't include anything that is > GPL, it (in itself) isn't derivative and doesn't get covered > by the GPL. You have to make it GPL if you link it against a GPL shim. And in case the shim uses EXPORT_SYMBOL_GPL, the shim has to be GPL. Again, you don't have to agree with me, but I would advise legal counsel now. > >>It is precisely the fact that it is a loadable module, and does not form > >>part of the kernel, that removes the requirement to distribute it under > >>GPL. > > The mechanism of linking is irrelevant. It's a matter of > whether a collective work (that may include the non-GPL > file talked about previously) includes GPL components. > If it does, then the collective work is a derivative work > of the GPL components, and the whole work has to be covered > by the GPL. So while the non-GPL file could be distributed > separately with a non-GPL license, as soon as you package > it together with GPL components in such a way that it > is not "mere aggregation", (and the fact that it interacts > and indirectly depends on GPL components to operate > shows clearly that it's not mere aggregation), then > it becomes subject to the GPL. > > So if you don't want this non-GPL component to > be subject to the GPL, you must distribute it independently, > and get the end user to load it into their system. You > can't package or distribute it with the GPL components > it interacts with. To put this in clear and understandable words. The end user has to break the GPL license and thus violate the copyright of the kernel developers. Regards Marcel - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: mark USB drivers as being GPL only
David Newall wrote: That being said, a module can be written such that it only dynamically links with the kernel. Ndiswrapper is an example of how this can be done: None of the drivers that work under ndiswrapper make any direct use of the kernel, not in any way, indeed a wrapper could be written for a different operating system. The issue is all about "derivative works" in copyright law. Ndiswrapper is in a good position because the closed-source drivers were originally written for another OS so it's pretty well impossible to argue that they are derived from linux. However, if I were to write a new GPL shim and then a new closed-source module that uses the shim to access kernel symbols, it is entirely possible that a court could rule that my closed-source module is a derivative work of the linux kernel because it was written specifically to run on linux. On the other hand if I were to sit down and write an OS-agnostic proprietary chunk of code, and then write a new GPL shim to use it under linux (and maybe other shim layers for other OS's as well), I _might_ be okay. But I would have to be prepared to prove that the proprietary code was not derived from the Linux kernel. Chris - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: mark USB drivers as being GPL only
> To put this in clear and understandable words. The end user has to break > the GPL license and thus violate the copyright of the kernel developers. Not quite - the GPL deals with distribution. You can put whatever you like in your own kernel if you don't ever distribute it. Shipping code for people to put back into kernels with that as a clear intent gets you back into more murky waters. - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: mark USB drivers as being GPL only
Chris Friesen wrote: On the other hand if I were to sit down and write an OS-agnostic proprietary chunk of code, and then write a new GPL shim to use it under linux (and maybe other shim layers for other OS's as well), I _might_ be okay. But I would have to be prepared to prove that the proprietary code was not derived from the Linux kernel. Sounds extremely unlikely. Copyright doesn't cover "intentions". It covers expression in a tangible form. If you take your logic to an extreme, then merely by thinking "I might just link helloworld.c in the kernel" your saying that it suddenly becomes subject to the GPL, even though nothing about helloworld.c has changed. Now package it up with the kernel and things change, because you've created something tangible, a compilation. Graeme Gill. - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: mark USB drivers as being GPL only
Hi Alan, > > To put this in clear and understandable words. The end user has to break > > the GPL license and thus violate the copyright of the kernel developers. > > Not quite - the GPL deals with distribution. You can put whatever you > like in your own kernel if you don't ever distribute it. Shipping code > for people to put back into kernels with that as a clear intent gets you > back into more murky waters. I know about that, but my comment was more about the fact that the end user receives a 3rd party source+binary distribution and then has to assemble it on their side. Btw. not to mention the fact that the GPL also talks about the tools to actually build the source code :) Regards Marcel - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: mark USB drivers as being GPL only
Hi Graeme, > > if the overall intention is to write a Linux kernel module/driver then > > it counts as derivative work for me. No matter how tricky you are and > > much you try to circumvent or try to hide this fact. However that is my > > personal opinion. You don't have to agree with me here. Ask your legal > > counsel. > > I think you're way of base here. Copyright doesn't cover intentions, > it covers expression in a tangible form. So the intention is irrelevant, > what is expressed in the file is what's relevant. If the file doesn't > contain GPL code, then in itself it isn't subject to the GPL. > > [ If I were the author of such a file, then I would be highly upset >at a bunch of people claiming rights over my independent work, >just because it could possibly be linked with their code. ] nobody said that btw. You can write whatever code you want and put it under whatever license you want. But in the case you wanna write a kernel driver/module you have to use exported kernel symbols from this specific kernel that is released und GPL. This goes for me under derivative work. We are on the topic of kernel modules and not some other code. I am not a lawyer. So feel free to disagree with we :) > > You have to make it GPL if you link it against a GPL shim. And in case > > the shim uses EXPORT_SYMBOL_GPL, the shim has to be GPL. Again, you > > don't have to agree with me, but I would advise legal counsel now. > > It is entirely possible that there is no way of licensing a shim > in such a way that it can be distributed with GPL code. I don't > know, I haven't investigated this issue. But irrespective > of this, the licensing of the shim doesn't affect the > licensing of the non-GPL code in itself. People with lots > of lawyers like NVidia seem to think that it is possible > to create a license compatible shim. Maybe they are wrong. This has been stated so many times. If NVidia's legal counsel think they get away with it. Fine. My personal opinion is that they are violating the copyright of the kernel developers. > > To put this in clear and understandable words. The end user has to break > > the GPL license and thus violate the copyright of the kernel developers. > > Not true. The GPL covers copying, not use. The end user is free to > use the GPL code in almost any way they like, including linking > it to non-GPL code. They just can't copy (ie. distribute) the result. This is true, but the real-world problem here is that they have to keep the created binary to themself. Any kind of distribution would make them responsible to distribute the full source code (including build tools). I don't wanna even get into this area since it opens a total different can of worms :( Regards Marcel - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: mark USB drivers as being GPL only
Marcel Holtmann wrote: if the overall intention is to write a Linux kernel module/driver then it counts as derivative work for me. No matter how tricky you are and much you try to circumvent or try to hide this fact. However that is my personal opinion. You don't have to agree with me here. Ask your legal counsel. I think you're way of base here. Copyright doesn't cover intentions, it covers expression in a tangible form. So the intention is irrelevant, what is expressed in the file is what's relevant. If the file doesn't contain GPL code, then in itself it isn't subject to the GPL. [ If I were the author of such a file, then I would be highly upset at a bunch of people claiming rights over my independent work, just because it could possibly be linked with their code. ] You have to make it GPL if you link it against a GPL shim. And in case the shim uses EXPORT_SYMBOL_GPL, the shim has to be GPL. Again, you don't have to agree with me, but I would advise legal counsel now. It is entirely possible that there is no way of licensing a shim in such a way that it can be distributed with GPL code. I don't know, I haven't investigated this issue. But irrespective of this, the licensing of the shim doesn't affect the licensing of the non-GPL code in itself. People with lots of lawyers like NVidia seem to think that it is possible to create a license compatible shim. Maybe they are wrong. To put this in clear and understandable words. The end user has to break the GPL license and thus violate the copyright of the kernel developers. Not true. The GPL covers copying, not use. The end user is free to use the GPL code in almost any way they like, including linking it to non-GPL code. They just can't copy (ie. distribute) the result. Graeme Gill. - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: mark USB drivers as being GPL only
> I think you're way of base here. Copyright doesn't cover intentions, > it covers expression in a tangible form. So the intention is irrelevant, > what is expressed in the file is what's relevant. If the file doesn't > contain GPL code, then in itself it isn't subject to the GPL. Will all the wannabe lawyers please go and read some basic copyright law then come back. It depends whether your file is a derivative work, not whether it contains GPL code. Alan - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: mark USB drivers as being GPL only
Alan Cox wrote: It depends whether your file is a derivative work, not whether it contains GPL code. Oh, care to explain how a file can be a derived work subject to the GPL unless it contains or is based on something that is GPL ? Graeme Gill. - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to debug EOVERFLOW errors
Alan Nisota wrote:
Pete Zaitcev wrote:
drivers/usb/host/ehci-q.c:
qh_make() {
switch (urb->dev->speed) {
case USB_SPEED_HIGH:/* no TT involved */
info1 |= (2 << 12);/* EPS "high" */
... if (type == PIPE_BULK) {
info1 |= (EHCI_TUNE_RL_HS << 28);
info1 |= 512 << 16;/* usb2 fixed maxpacket */
info2 |= (EHCI_TUNE_MULT_HS << 30);
}
}
}
Try to patch max_packet(maxp) into it and see if that works.
Use the interrupt case for guidance.
Ok, I'll try that and see how it goes.
Thanks to both you and Alan for your help, I have very little experience
doing anything with USB
Well, this hack allows me to read without babble on my newer machines,
but the one I really need it to work on has an older motherboard, and
refuses to accept the 1024 byte packets. I'll need to either work iwth
the vendor or see if I can patch the firmware.
Thanks for the help.searching the archives I saw this isn't that
uncommon of a problem, and there was talk of adding a switch to the
module to allow these out-of-spec devices to work via a similar fix. Is
there anything I could do to move that along?
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to debug EOVERFLOW errors
On Tue, 05 Feb 2008 18:32:35 -0800, Alan Nisota <[EMAIL PROTECTED]> wrote: > Well, this hack allows me to read without babble on my newer machines, > but the one I really need it to work on has an older motherboard, and > refuses to accept the 1024 byte packets. I'll need to either work iwth > the vendor or see if I can patch the firmware. What does "refuses to accept" mean? > Is there anything I could do to move that along? I think a proper patch would be welcome, because this is what Alan wrote: > As far as I can tell, Linux doesn't try to prevent high-speed devices > from using illegal maxpacket sizes. ehci-hcd should accept anything up > to 2047 without complaint. I interpret this as a) he forgot that we hardcoded 512 in qh_make and b) considers it right for us not to mess with whatever the descriptors on the device say (outside of sanity checks). If so, I agree. Someone (like you) needs to post the patch, address the feedback, test on actual hardware (like your set-top box) and otherwise see it through. It's late for 2.6.25, so I'd say 2.6.26. Its merge window is 4 months away, but you need the patch in Greg's tree _before_ that. -- Pete - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to debug EOVERFLOW errors
On Tuesday 05 February 2008, Alan Nisota wrote: > >> Try to patch max_packet(maxp) into it and see if that works. > >> Use the interrupt case for guidance. > ... > > Well, this hack allows me to read without babble on my newer machines, > but the one I really need it to work on has an older motherboard, and > refuses to accept the 1024 byte packets. I'll need to either work iwth > the vendor or see if I can patch the firmware. Try to get the vendor to fix their broken product. I'm fairly sure it can't be certified as USB-compliant that way ... > Thanks for the help.searching the archives I saw this isn't that > uncommon of a problem, Well, it's been reported once before, as I recall. Maybe even for the same vendor's product. > and there was talk of adding a switch to the > module to allow these out-of-spec devices to work via a similar fix. Is > there anything I could do to move that along? Send the patch for that one line hack, that's a start. A module parameter would be pointless. The missing part, other than that one-line hack, would be adding code to the descriptor parsing to detect this specific bogosity and then warning about it. The thing is that in this specific case it's easy to partially work around the vendor bug. Not all the high speed HCDs will necessarily do that, though. - Dave - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to debug EOVERFLOW errors
Pete Zaitcev wrote: On Tue, 05 Feb 2008 18:32:35 -0800, Alan Nisota wrote: Well, this hack allows me to read without babble on my newer machines, but the one I really need it to work on has an older motherboard, and refuses to accept the 1024 byte packets. I'll need to either work iwth the vendor or see if I can patch the firmware. What does "refuses to accept" mean? It means I'm an idiot and forgot to run mkinitramfs so I wasn't getting the updates to the module I built on my normal linux box. I have now corrected that mistake and can read from the R5000 on all of my boxes now. Is there anything I could do to move that along? I think a proper patch would be welcome, because this is what Alan wrote: As far as I can tell, Linux doesn't try to prevent high-speed devices from using illegal maxpacket sizes. ehci-hcd should accept anything up to 2047 without complaint. I interpret this as a) he forgot that we hardcoded 512 in qh_make and b) considers it right for us not to mess with whatever the descriptors on the device say (outside of sanity checks). If so, I agree. Someone (like you) needs to post the patch, address the feedback, test on actual hardware (like your set-top box) and otherwise see it through. It's late for 2.6.25, so I'd say 2.6.26. Its merge window is 4 months away, but you need the patch in Greg's tree _before_ that. I've learned that getting stuff into the kernel takes patience (it won't be my first foray there). I've seen a few different ways to implement this, and am wondering which would be preferred: The most conservative is:info1 |= ((maxp == 1024) ? 1024 : 512) << 16; /* usb2 fixed maxpacket */ But to be maximally flexible this might be better: info1 |= max_packet (maxp) << 16; /* usb2 fixed maxpacket */ I noticed that just enforcing the size to be 1024 made my other USB2 devices very angry which surprised me since I thought it would automatically use the lesser of this value and MaxPacketSize. So I'm concerned that the second case might behave oddly if a device reports its MaxPacketSize to be less than 512 bytes and I have no way to test it. (Also this isn't meant to be a formal patch, I'm just trying to get feedback) And as far as getting the vendor to fix the device, I've asked, but they've been extremely reluctant to support Linux in the past. We'll see what they say. - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
