On Wed, 06 Feb 2008 12:21:04 +1100
Graeme Gill <[EMAIL PROTECTED]> wrote:
> 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
Alan Cox wrote:
"is based on" - does not imply using the actual code now does it. As I
said before and you don't seem able to grasp the boundary is the legal
definition of a derivative work, which is why you want to go read a
beginners book on IP law.
Kindly take your insults somewhere else, si
> Kindly take your insults somewhere else, since you seem unable to engage
> in a constructive discussion.
I'm attempting to guide you to getting actual answers. Its unfortunate
you don't seem to understand that.
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the b
Hy
After further tests with the usb gadget serial on the pxa27x (see my previous
postings "USB gadget serial on PXA-270") i think i'm able to address the
problem more precisly.
It seems that the class request SET_LINE_CODING is handled by the gadget driver
_before_ its data OUT stage. That lead
On Tue, Feb 05, 2008 at 01:30:23PM -0500, Alan Stern wrote:
> 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_FE
On Tue, 5 Feb 2008, Pete Zaitcev wrote:
> 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 complai
On Wed, 6 Feb 2008, Fabio Venturi wrote:
> I hope I did it right this time,
> these are the configuration about debug enabled in the kernel
>
> [EMAIL PROTECTED]:linux$ zgrep -i debug /proc/config.gz |grep -i =y
> CONFIG_ACPI_DEBUG=y
> CONFIG_CPU_FREQ_DEBUG=y
> CONFIG_IRDA_DEBUG=y
> CONFIG_SCSI_S
This is an attempt to kill two birds with one stone.
First, we kill one more user of kernel_thread. Second - we kill
one of the last users of kill_proc - the function which is also
to be removed, because it uses a pid_t which is not safe now.
The problem is that I couldn't find the maintainer for
as anyone still time to help me with my joystick problem!
Now i tryed 2.6.24 kernel, and it is still not working
Jochen Kühner schrieb:
You got my logfile?? Was there anything helpful in, or is it too big?
Thanks for helping
Jiri Kosina schrieb:
On Fri, 2 Nov 2007, Jochen Kühner wrote
On Wed, 6 Feb 2008, Jochen Kühner wrote:
> as anyone still time to help me with my joystick problem! Now i tryed
> 2.6.24 kernel, and it is still not working
Yes, sorry, too many other things were pending in my queue.
I have your logs and will look at them hopefully soon, just didn't happen
Hello,
I'm wondering what this option means and in which cases it's needed.
Thanks for any hint.
--
Francis
-
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
On Wed, 6 Feb 2008, Francis Moreau wrote:
> Hello,
>
> I'm wondering what this option means and in which cases it's needed.
>
> Thanks for any hint.
Read the documentation at the top of the source file:
drivers/usb/gadget/file_storage.c.
It's needed in cases where the driver won't work proper
Hi,
> The problem is that I couldn't find the maintainer for the code
> in drivers/usb/atm/.
that would be me (though since I haven't used this modem in years I would
be more than happy to hand it off to someone else).
> Besides, I don't have a proper hardware to test this.
I will try to find
On Wednesday 06 February 2008, Thomi Aurel RUAG A wrote:
> Hy
Hi ... can you fix your mailer so it wraps lines properly? Well
before column 80.
> After further tests with the usb gadget serial on the pxa27x (see my
> previous postings "USB gadget serial on PXA-270") i think i'm able to
> addres
On Wed, 6 Feb 2008, Thomi Aurel RUAG A wrote:
> Hy
>
> After further tests with the usb gadget serial on the pxa27x (see my previous
> postings "USB gadget serial on PXA-270") i think i'm able to address the
> problem more precisly.
> It seems that the class request SET_LINE_CODING is handled b
On Tue, 5 Feb 2008 12:34:18 -0800
Greg KH <[EMAIL PROTECTED]> wrote:
> 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
On Tue, 5 Feb 2008, Matthew Dharm wrote:
> 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 cod
On Wed, Feb 06, 2008 at 09:14:48PM +0100, Christer Weinigel wrote:
> On Tue, 5 Feb 2008 12:34:18 -0800
> Greg KH <[EMAIL PROTECTED]> wrote:
>
> > 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
> > stateme
On Mon, 04 Feb 2008 22:38:11 +0100
Marcel Holtmann <[EMAIL PROTECTED]> wrote:
> Hi Christer,
>
> while the HAL case of Atheros might be still true despite the fact
> that an OpenHAL has been around for a long time now. The Intel
> argument is out of the picture since quite some time. The regulato
There a company that is providing a common API for writting Windows
and Linux drivers. Last time I was using a Macraigor JTAG it was based
on this proprietary dual platform driver.
http://www.macraigor.com/cgi_bin/counters/unicounter.pl?name=counters/ocd_cmdr_linux&deliver=http://www.macraigor.biz
Am Wed, 6 Feb 2008 21:34:49 +0100
schrieb Christer Weinigel <[EMAIL PROTECTED]>:
>
> I also think that my customers, that decided to keep their kernel
> modules binary only, made a big mistake and have told them so. But I
> still think it's better for the Linux community to be a bit soft on
> su
Hi Christer,
> > while the HAL case of Atheros might be still true despite the fact
> > that an OpenHAL has been around for a long time now. The Intel
> > argument is out of the picture since quite some time. The regulatory
> > daemon was an interim solution and has been replaced by a proper
> > f
> I heard this all before and I don't buy it anymore. At some point the
> companies in Asia will understand that the whole picture looks different
> and that not always cheap, cheap, cheap is best for their margins.
The asian companies for the most part don't care about giving
programming info awa
On Wed, 6 Feb 2008 12:28:10 -0800
Greg KH <[EMAIL PROTECTED]> wrote:
> On Wed, Feb 06, 2008 at 09:14:48PM +0100, Christer Weinigel wrote:
> > On Tue, 5 Feb 2008 12:34:18 -0800
> > Greg KH <[EMAIL PROTECTED]> wrote:
> >
> > > In the end, it's up to the copyright holders to enforce the
> > > licens
On Tue, Feb 05, 2008 at 05:34:23PM -0600, Chris Friesen wrote:
> 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
On Wed, Feb 06, 2008 at 03:23:39PM -0500, Alan Stern wrote:
> On Tue, 5 Feb 2008, Matthew Dharm wrote:
>
> > 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
On Tue, 5 Feb 2008 13:46:08 +0200
"Pekka Enberg" <[EMAIL PROTECTED]> wrote:
> 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
On Wed, Feb 06, 2008 at 03:43:26PM -0500, Jon Smirl wrote:
> There a company that is providing a common API for writting Windows
> and Linux drivers. Last time I was using a Macraigor JTAG it was based
> on this proprietary dual platform driver.
>
> http://www.macraigor.com/cgi_bin/counters/unicou
On Wed, 06 Feb 2008 21:55:45 +0100
Marcel Holtmann <[EMAIL PROTECTED]> wrote:
> > So how does that invalidate my point? Intel did jump through a lot
> > of hoops to avoid giving away the code that controls their radio.
> > When the regulatory daemon stuff got too much complaints, they
> > finally
On Wed, 06 Feb 2008 22:12:54 +0100, Christer Weinigel said:
> If I use an in kernel API, but from a piece of code which is external
> to the kernel, is that really a derived work? If you say it is, do you
> realise that you are advocating something which is very close to an API
> copyright, someth
On Wed, 6 Feb 2008, Matthew Dharm wrote:
> Maybe this is a crazy question, but...
>
> Why is this not in the SCSI core?
Or even in the block core?
> It's hardly USB-specific, and I'm
> willing to bet that there are other HCDs (at least spb2) which need to do
> this sort of thing...
James, do
On Wed, 2008-02-06 at 17:18 -0500, Alan Stern wrote:
> On Wed, 6 Feb 2008, Matthew Dharm wrote:
>
> > Maybe this is a crazy question, but...
> >
> > Why is this not in the SCSI core?
>
> Or even in the block core?
>
> > It's hardly USB-specific, and I'm
> > willing to bet that there are other
add missing '|'
Signed-off-by: Roel Kluin <[EMAIL PROTECTED]>
---
diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index 90dcc62..2173561 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -394,7 +394,7 @@ static const char *ftdi_chip_name[]
On Wed, 6 Feb 2008, James Bottomley wrote:
> > What we're talking about is a routine that provides drivers a simple
> > way to access the data in a scatter-gather buffer (which may lie in
> > highmem or otherwise not be easily reachable). The idea is that some
> > commands are emulated by the dr
On Wed, 2008-02-06 at 18:25 -0500, Alan Stern wrote:
> On Wed, 6 Feb 2008, James Bottomley wrote:
>
> > > What we're talking about is a routine that provides drivers a simple
> > > way to access the data in a scatter-gather buffer (which may lie in
> > > highmem or otherwise not be easily reachab
add missing '|'
Signed-off-by: Roel Kluin <[EMAIL PROTECTED]>
---
diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index 90dcc62..2173561 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -394,7 +394,7 @@ static const char *ftdi_chip_name[]
Hi Greg & Bruno,
As you can probably tell the Sierra driver is becoming less and less
generic and more Sierra device specific. I am not sure if we want to
include non-sierra devices in this driver, as I am not sure whether our
vendor-specific messages will negatively impact other devices.
What do
> IANAL, but when looking at the "But when you distribute the same
> sections as part of a whole which is a work based on the Program, the
> distribution of the whole must be on the terms of this License" of the
> GPLv2 I would still consult a lawyer before e.g. selling a laptop with a
> close
Hi Christer,
On Tue, 5 Feb 2008 13:46:08 +0200
"Pekka Enberg" <[EMAIL PROTECTED]> wrote:
> > What makes you qualified to make that statement (without giving any
> > evidence)? Are you're an expert on international copyright law?
On Feb 6, 2008 11:12 PM, Christer Weinigel <[EMAIL PROTECTED]> wrote
David Schwartz wrote:
IANAL, but when looking at the "But when you distribute the same
sections as part of a whole which is a work based on the Program, the
distribution of the whole must be on the terms of this License" of the
GPLv2 I would still consult a lawyer before e.g. selling a laptop
40 matches
Mail list logo
