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
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
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 settin
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
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
wo
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
> 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
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
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 re
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 me
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
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 i
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),
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 th
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 fr
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
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 yo
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
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
-
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 derive
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 l
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
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 vi
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. Th
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
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);
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
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 (str
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
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
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
> >
> > -
>
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 mo
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
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 aban
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
> usi
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
/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_tha
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
> 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
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
effective
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 bas
> "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
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 usi
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 wri
> 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 peo
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 propri
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. S
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. As
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 y
> 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 wan
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 "u
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);
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
>
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 moth
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 v
55 matches
Mail list logo
