Re: [PATCH] USB: add SPDX identifiers to all files in drivers/usb/

> But all that matters is the tag is there for tools to be able to extract > it properly. And if we have that, it doesn't matter what the comment > "style" would be, so might as well make it look "nicer". > > And, to take it to the next conclusion, if we have the SPDX identifier, > we can get

Re: Moxa UPort 1150 and RS-422/485… what's the "proper" way to switch modes

So IMHO there are two cases 1. The configuration is fixed in the hardware - in which case we should automatically set it in kernel, or from device tree. 2. The configuration is soft - in which case you need an ioctl you can use on the port to change it - irrespective of whether sysfs also

Re: [PATCH v2 1/8] tty: add a poll() callback in struct tty_operations

> That would cut it, but TIOCPKT is too coupled with having a linked tty. > I could make acm behave like a pty (accept TIOCPKT and issue the > ctrl_status bits), but for that I need n_tty to know that packet does > not always mean a linked tty is present, and that in case it isn't we > take our

Re: [PATCH v2 1/8] tty: add a poll() callback in struct tty_operations

On Tue, 13 Jun 2017 09:52:07 +0300 Tal Shorer wrote: > If a tty driver wants to notify the user of some exceptional event, > such as a usb cdc acm device set_line_coding event, it needs a way to > modify the mask returned by poll() and possible also add wait queues. > In

Re: [PATCH 6/8] usb: gadget: f_acm: add an ioctl to get the current line coding

On Mon, 12 Jun 2017 20:26:13 +0300 Tal Shorer wrote: > The user can issue USB_F_GET_LINE_CODING to get the current line coding > as set by the host (or the default if unset yet). No this is not how to do it. We don't want weirdass ioctls for each different tty device type.

Re: Two regressions on BYT/T ASUS T100TA 4.12-rc: #2 Keyboard no longer works

> Normally in this situation I'd recommend bisection. However, this case > may be simple enough for a usbmon trace to provide the answer. With a shared file system between the T100TA and a big machine it's not too hard to do some builds: commit 76dd1fbebbaebab294dc09230960238746b883b1 is the

Re: Two regressions on BYT/T ASUS T100TA 4.12-rc: #2 Keyboard no longer works

On Wed, 7 Jun 2017 18:07:44 +0200 Greg KH <g...@kroah.com> wrote: > On Wed, Jun 07, 2017 at 04:27:30PM +0100, Alan Cox wrote: > > Booting 4.12-rc gives you a machine where neither the keyboard or the > > mouse of the base-station work. > > > > Other USB

Two regressions on BYT/T ASUS T100TA 4.12-rc: #2 Keyboard no longer works

Booting 4.12-rc gives you a machine where neither the keyboard or the mouse of the base-station work. Other USB devices work - including plugging in an external USB keyboard and mouse. Removing the basestation and replugging it has no effect. The base station is seen in lsusb. Bus 001 Device

Re: [PATCH 0/9] tty: drop broken alt-speed handling

t warn about setting > speed via SPD_*") without anyone noticing (for four years). We have the ability to set the speed directly via termios so I doubt anyone is using the remaining hacks either but I guess someone may. All looks good to me. Reviewed-by: Alan Cox <a...@linux.intel.co

Re: [PATCH 8/9] tty: ircomm: remove dead and broken ioctl code

On Tue, 6 Jun 2017 12:54:40 +0200 Johan Hovold wrote: > Remove three ifdefed and broken implementations of TIOCSSERIAL and > TIOCGICOUNT, and parity handling in set_termios which had suffered > severe bit rot. I would be amazed if the IRDA code still works. It's not been

Re: [RFC 0/4] tty: port hangup and close issues

[ Note that this closing of an uninitialised port seems to be a bug in itself, which these patches aim to fix. ] You don't want to be cc'ing me on these - not my problem any more. (but you might want to fix the fact you reference port-tty without the lock or refcounts 8)) Alan -- To

Re: [PATCH 1/1]linux-usb: optimize to match the Huawei USB storage devices and support new switch command

On Fri, 14 Dec 2012 03:01:24 + Fangxiaozhi (Franko) fangxiao...@huawei.com wrote: Dear Alan: This prevents people getting access to the storage device if they want. In our device, after its switching, it will keep the cdrom port together with other ports (such as modem

Re: [PATCH 1/1]linux-usb: optimize to match the Huawei USB storage devices and support new switch command

On Wed, 12 Dec 2012 18:20:33 +0800 fangxiaozhi 00110321 fangxiao...@huawei.com wrote: From: fangxiaozhi huana...@huawei.com 1. To optimize the match rules for the Huawei USB storage devices. Avoid to load USB storage driver for modem interface with Huawei devices. 2. Add to support new

Re: [PATCH RESEND] tty: don't dead lock while flushing workqueue

On Wed, 05 Dec 2012 17:15:40 +0100 Sebastian Andrzej Siewior bige...@linutronix.de wrote: On 12/03/2012 06:41 PM, Peter Hurley wrote: The lock logic for tty_set_ldisc() is wrong. Despite existing code in tty_set_ldisc() and tty_ldisc_hangup(), the ldisc_mutex does **not** (and should not)

[PATCH] hid: put the case in the right switch statement

From: Alan Cox a...@linux.intel.com Signed-off-by: Alan Cox a...@linux.intel.com --- drivers/hid/hid-multitouch.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c index 3eb02b9..c97011c 100644 --- a/drivers/hid

[PATCH] kaweth: print correct debug ptr

From: Alan Cox a...@linux.intel.com We nowdays copy the buffer and free fw-data, so make the debug printk use the right thing. Signed-off-by: Alan Cox a...@linux.intel.com --- drivers/net/usb/kaweth.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/usb

Re: [PATCH v3.6.1] usb: serial: ftdi_sio: Add missing chars_in_buffer function

on the hw buffer can not be done for the original SIO device. Signed-off-by: Jarkko Huijts jarkko.hui...@gmail.com Acked-by: Alan Cox a...@linux.intel.com -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info

[PATCH] sierra_ms: don't keep unused variable

From: Alan Cox a...@linux.intel.com We need to call scsi_get_host_dev(sh) but we never use the return nor do we have any reason to check it. Signed-off-by: Alan Cox a...@linux.intel.com --- drivers/usb/storage/sierra_ms.c |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git

Re: [PATCHv4 3/9] serial: vt8500: Add devicetree support for vt8500-serial

On Thu, 23 Aug 2012 19:35:39 +1200 Tony Prisk li...@prisktech.co.nz wrote: Increase vt8500_max_ports to 6 as the WM8505 as 6 available uarts. Use devicetree port id as primary addressing for ports but allow auto-allocation if id not specified. Acked-by: Alan Cox a...@linux.intel.com

Re: [PATCHv3 3/9] serial: vt8500: Add devicetree support for vt8500-serial

On Wed, 22 Aug 2012 08:47:32 +1200 Tony Prisk li...@prisktech.co.nz wrote: Signed-off-by: Tony Prisk li...@prisktech.co.nz --- drivers/tty/serial/vt8500_serial.c | 37 1 file changed, 33 insertions(+), 4 deletions(-) Can we have a comment attached to

Re: [PATCH] Intel xhci: Only switch the switchable ports

This patch adds the checking code for the two register so that only the switchable ports are altered. And since when has trusting BIOS provided data beena good idea ? Absent a lot of precise examples of where it causes actual failures I don't believe we should change our behaviour here. --

Re: [PATCH] From 2.6.39-rc1 onward, the Logitech Quickcam Fusion webcam (046d:08c1) stops

On Fri, 6 Jul 2012 10:37:30 -0400 (EDT) Alan Stern st...@rowland.harvard.edu wrote: On Fri, 6 Jul 2012, Laurent Pinchart wrote: Hi Alan, On Friday 06 July 2012 09:50:30 Alan Stern wrote: On Fri, 6 Jul 2012, Alan Cox wrote: From: Eric Ding ericd...@alum.mit.edu working

Re: usb/serial/io_ti.c: inconsequent NULL checking

Either the test of port-tty here is unneeded: if (port-tty) port-tty-low_latency = low_latency; ...or the lack of test of port-tty here is a mistake: edge_set_termios (port, port-tty-termios); Interesting - so coverity doesn't understand the BKL. It's producing

Re: Handshaking on USB serial devices

developing is entirely wrong. Oh well. Mind you, providing a write_room function is NOT a real solution; it merely reduces the condition to a usually-winnable race. (Ironically, when I back-ported the 2.6 driver, I excluded its new write_room function. Mistake.) What race do you see left

[PATCH] usb serial: Note mos7480 and option don't lock modem status

Signed-off-by: Alan Cox [EMAIL PROTECTED] diff -u --new-file --recursive --exclude-from /usr/src/exclude linux.vanilla-2.6.25-rc2-mm1/drivers/usb/serial/mos7840.c linux-2.6.25-rc2-mm1/drivers/usb/serial/mos7840.c --- linux.vanilla-2.6.25-rc2-mm1/drivers/usb/serial/mos7840.c 2008-02-19 11:03

[PATCH] io_ti: lock mcr and msr shadows properly

Signed-off-by: Alan Cox [EMAIL PROTECTED] diff -u --new-file --recursive --exclude-from /usr/src/exclude linux.vanilla-2.6.25-rc2-mm1/drivers/usb/serial/io_ti.c linux-2.6.25-rc2-mm1/drivers/usb/serial/io_ti.c --- linux.vanilla-2.6.25-rc2-mm1/drivers/usb/serial/io_ti.c 2008-02-19 11:03

[PATCH] iuu_phoenix: lock priv-tiostatus properly

Signed-off-by: Alan Cox [EMAIL PROTECTED] diff -u --new-file --recursive --exclude-from /usr/src/exclude linux.vanilla-2.6.25-rc2-mm1/drivers/usb/serial/iuu_phoenix.c linux-2.6.25-rc2-mm1/drivers/usb/serial/iuu_phoenix.c --- linux.vanilla-2.6.25-rc2-mm1/drivers/usb/serial/iuu_phoenix.c

[PATCH] kobil_sct: Get rid of unneeded priv-line_state

Signed-off-by: Alan Cox [EMAIL PROTECTED] diff -u --new-file --recursive --exclude-from /usr/src/exclude linux.vanilla-2.6.25-rc2-mm1/drivers/usb/serial/kobil_sct.c linux-2.6.25-rc2-mm1/drivers/usb/serial/kobil_sct.c --- linux.vanilla-2.6.25-rc2-mm1/drivers/usb/serial/kobil_sct.c 2008-02-19 11

Re: [PATCH] Hangup tty on g_serial disconnect

On Sat, 16 Feb 2008 13:22:25 -0800 David Brownell [EMAIL PROTECTED] wrote: On Saturday 16 February 2008, David Brownell wrote: On USB cable disconnect g_serial doesn't hangup the port tty, which results in an endless read on the tty device. With the following patch the read and select

Re: Handshaking on USB serial devices

To make it clear: Even aside from the buffer in 2.6's pl2303.c, there's a race: An in-flight write URB can fill all hardware buffers, making unsafe what previously appeared to be a safe write. I think it's essential to delay submission of the URB on a stop-transmit condition. Hardware flow

Re: Handshaking on USB serial devices

O believe at several second intervals. I can cut those messages to about weekly by using an FDTI adaptor in its place, or I can stop them entirely if Sorry don't see the connection between the two stories ? Alan - To unsubscribe from this list: send the line unsubscribe linux-usb in the body

Re: Handshaking on USB serial devices

byte of a packet is being thrown away about .1% of the time for the pl2303, but I'm not sure if the FTDI driver still suffers from a similar rash. I A 20 byte low speed message is too small for flow control to account for it. - To unsubscribe from this list: send the line unsubscribe

Re: Handshaking on USB serial devices

That's a very good point. Even so: on the 2.4 driver, write_room isn't implemented (refer to a previous message by Alan); and in 2.6, a 1k buffer is built into the driver, with nothing to prevent it being sent when the hardware buffer fills. These could be bugs in the two versions Which

Re: [PATCH] USB: mark USB drivers as being GPL only

What happens if I ship a binary-only program that uses *either* a GPL library or a custom library with the same API? If you don't have the Frobozz-Foo library, you'll have to supply your own work-alike It depends whether it is a derived work. It doesn't matter if you paint it green, hang

Re: [PATCH] USB: mark USB drivers as being GPL only

Why? Because the pre-processor is what is including any GPL'd code in my application and expanding any macros. That is a purely mechanical process and And its not pirating Windows because Norton Ghost put Microsoft copyright material in your hard disk either - thats a mechanical process too.

Re: [PATCH] USB: mark USB drivers as being GPL only

Well, winmodem case is the only I could *almost* understand closed-source drivers: the algorithms used *are* the modem. It's not a simple firmware upload. Winmodem is all about patents, the modem standards come from ISO so are created by all out corporate warfare with the winner getting the

Re: [PATCH] USB: mark USB drivers as being GPL only

On Fri, 08 Feb 2008 13:25:33 +1030 David Newall [EMAIL PROTECTED] wrote: Alan Cox wrote: It would not be improper to say that such and such a lawyer said this and that. I'm not proposing that you breach their copyright in their It would be highly improper given these were

Re: [PATCH] USB: mark USB drivers as being GPL only

previous statements which seemed to say, you've spoken to numerous Please don't use seemed to say and then quote words I've never said. That's misleading, rude and also awful language style. I've not said anything is definite because as I said before there is no caselaw. We know the GPL is

Re: [PATCH] USB: mark USB drivers as being GPL only

It would not be improper to say that such and such a lawyer said this and that. I'm not proposing that you breach their copyright in their It would be highly improper given these were business discussions involving companies using Linux. - To unsubscribe from this list: send the line

Re: [PATCH] USB: mark USB drivers as being GPL only

No, I'm right. The word proof is appropriate in context. (I write in plain English, not Legalese.) I certainly didn't intend proof to mean mathematically certain. Anybody who pretends that proof in court means that must be ignorant or trying to deceive. I'm afraid you are wrong despite

Re: [PATCH] USB: mark USB drivers as being GPL only

That's what you claim it says, but has any court, anywhere, agreed with you? You claim the authority of others (i.e. numerous lawyers), but I don't believe you have that authority. You're just starting hearsay. You've never said what lawyers and you've never told us what they actually

Re: [PATCH] USB: mark USB drivers as being GPL only

It's nonsense, it's a reasonable reading of the GPL. What I am doing is telling you what the GPL says, not what you wish it said. In which case for each statement please give the case at appeal or higher level which is the precedent for the interpretation. If the developers say that this

Re: [PATCH] USB: mark USB drivers as being GPL only

doesn't mean it's derived from Linux. In the case of user-space code it's widely understood that no licence restrictions are conferred. The Actually that is also questionable. The only reason it is fairly certain in Linux is Linus went to the trouble of stating that interpretation was

Re: [PATCH] USB: mark USB drivers as being GPL only

Perhaps you might read up on unfair trade practices and contract law. I'm familiar with them to some extent because I have run companies in the past and continue to do so as a sideline to my Red Hat work. I also spend more time than I'd like talking to lawyers about licencing. The contract

Re: [PATCH] USB: mark USB drivers as being GPL only

Again, I missed who wrote the above. I'm reminded of Apple computer, who explaining some engineering decisions in the Apple ][ pointed out that an additional 10c in components adds $10 to the retail price (or something rather like that.) Cheap, cheap, cheap helps market share far more than

Re: [PATCH] USB: mark USB drivers as being GPL only

In Australia, devices require approval from a regulatory body. Such approval is withheld if appropriate safeguards are not applied. We were talking about the USA. I am not aware of any Australian answers to the specific question of software as an appropriate safeguard. The US requires

Re: [PATCH] USB: mark USB drivers as being GPL only

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 away

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

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

[PATCH] oti6858: cleanup

- Rename the copied buffer functions from pl2303 to oti6858 to avodi confusion - Initialise speeds properly - Use modern baud rate handling - Remove GSERIAL/SSERIAL ioctl hacks that reference termios unlocked Signed-off-by: Alan Cox [EMAIL PROTECTED] diff -u --new-file --recursive --exclude-from

Re: [pl2303 regression] Linux 2.6.23 breaks gpsbabel's DG-100 support

applied in reverse (a partial revert to 2.6.22) makes the corruption go away, but is likely just papering over the root cause. Cc'ed the gpsbabel developer mailing list, in case we have to fix this in userspace. Please try the following diff -u --new-file --recursive --exclude-from

Re: [pl2303 regression] Linux 2.6.23 breaks gpsbabel's DG-100 support

The appended patch applied in reverse (a partial revert to 2.6.22) makes the corruption go away, but is likely just papering over the root cause. Cc'ed the gpsbabel developer mailing list, in case we have to fix this in userspace. Reverting it breaks the speed handling. Can you apply just

Re: [pl2303 regression] Linux 2.6.23 breaks gpsbabel's DG-100 support

On Fri, 4 Jan 2008 23:16:44 +0100 first two segments applied, last segment reverted - breaks first two segments reverted, last segment applied - works OK Can you see which of the first two ? Alan - To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to

Re: [pl2303 regression] Linux 2.6.23 breaks gpsbabel's DG-100 support

The thing that's a little non-standard in the way we talk to the device is that we frequently reset VMIN/VTIME (but _not_ cflags) while the device may be streaming data at us. On Mac, at least, it looks like he PL2303 driver reprograms the device resulting in a brief interrupt of data that's

[PATCH] ti_usb: termios cleanups

Remove internal NULL passing in termios code Remove all the if checks it causes Encode the baud rate back properly Clear CMSPAR as it is not supported Signed-off-by: Alan Cox [EMAIL PROTECTED] diff -u --new-file --recursive --exclude-from /usr/src/exclude linux.vanilla-2.6.24-rc6-mm1/drivers

[PATCH] mos7720: clean up termios

Remove lots of NULL checks that can no longer occur Encode the baud rate back into the termios (again someone with docs see FIXME to improve this further) Signed-off-by: Alan Cox [EMAIL PROTECTED] diff -u --new-file --recursive --exclude-from /usr/src/exclude linux.vanilla-2.6.24-rc6-mm1

[PATCH] keyspan: Fix oops

If we get a data URB back from the hardware after we have put the tty to bed we go kaboom. Fortunately all we need to do is process the URB without trying to ram its contents down the throat of an ex-tty. Signed-off-by: Alan Cox [EMAIL PROTECTED] diff -u --new-file --recursive --exclude-from

[PATCH] io_ti: clean up termios handling

Don't pass NULL into termios functions when calling them internally Remove all the crap which then checks for NULL which can't occur now Clear CMSPAR as it is not supported Report the baud rate back to the caller properly (See FIXME someone with the docs) Signed-off-by: Alan Cox [EMAIL PROTECTED