* RE: Linux USB Serial
From: Steven J. Ackerman @ 2012-09-17 22:27 UTC (permalink / raw)
To: 'Greg KH'; +Cc: 'Bjørn Mork', linux-usb, linux-serial
In-Reply-To: <20120917220813.GA7780@kroah.com>
> That's fine, the cdc-acm interface will work for that.
>
> But is your device really a CDC ACM device? Or is it something else?
The device is a 3.5" color LCD display with touchscreen that can act as a
serial
terminal. It just needs to be able to send and receive characters over an
USB
serial port.
> You wouldn't, if you use the ftdi serial chip in your device. Which
> begs me to ask, what type of usb to serial chip is in your device? What
> protocol does it use to talk to the host?
The device is based upon a Renesas RX62N processor which has a USB interface
in it. The protocol is supposedly based upon the CDC - a control endpoint
and
two bulk endpoints. The software was derived from a demo supplied by the
manufacturer - and it does work under Windows. The device enumerates as
a COM port and you can interact with the display using a program or a
terminal
emulator. Unfortunately the chip vendor doesn't have any support for Linux.
> They shouldn't have to do that, once we get it working, they get the
> update automatically from their distro. But if you can't test any
> changes we make to try to get this to work, there's not much we can do
> here, right?
>
I guess that I'm operating under the assumption that there is something
wrong on my end - an incorrectly configured descriptor for example. It
appears
the other USB serial devices work OK under Linux - even without custom
drivers. I'm hoping that I can find an error message somewhere that will
tell me what I'm doing wrong - or that somebody who has been down that
path before can't point to something obvious - like Bjrn did.
> Oh, and fix that descriptor up in your firmware, that might solve
> everything :)
Going through the USB CDC documentation between e-mails. Other than
the incorrect bInterfaceSubClass value - which I have corrected - nothing
else seems wrong.
>
> Hope this helps,
>
> greg k-h
Always appreciate your assistance - thank you!
Steven J. Ackerman, Consultant
ACS, Sarasota, FL
http://www.acscontrol.com
mailto:steve@acscontrol.com
^ permalink raw reply
* Re: Linux USB Serial
From: 'Greg KH' @ 2012-09-17 22:08 UTC (permalink / raw)
To: Steven J. Ackerman
Cc: 'Bjørn Mork', linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-serial-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <00c101cd951f$55626910$00273b30$@acscontrol.com>
A: No.
Q: Should I include quotations after my reply?
http://daringfireball.net/2007/07/on_top
On Mon, Sep 17, 2012 at 05:56:46PM -0400, Steven J. Ackerman wrote:
> Greg-
>
> Thanks for your response.
>
> Not sure if I need the cdc-acm functionality or not.
>
> This is a color lcd display that supports a usb serial interface to
> interact. I really
> just need to be able to send and receive characters and NAK the pipe back
> temporarily when my input buffer is full.
That's fine, the cdc-acm interface will work for that.
> The descriptors were supplied by the chip vendor - Renesas - as part of a
> CDC demo application. The VID/PID is ours. The device works great under
> Windows XP with the descriptors as shown previously - even with the
> Communications bInterfaceSubClass value wrong.
But is your device really a CDC ACM device? Or is it something else?
> Doing the modprobe, etc. was based upon some blog posts that purported
> to show how to add support for an unknown usb serial device.
Yes, but that's a one-off, and your kernel should have told you that you
shouldn't be doing that, if you are using a modern kernel release.
> Looking at the descriptor for a FTDI USB serial to TTL cable it seems a lot
> simpler,
> but it does indicate vendor specific class, subclass and protocol - which
> means
> that it requires a custom driver - ftdi_sio - right ? I don't really want
> to have to
> develop and support that.
You wouldn't, if you use the ftdi serial chip in your device. Which
begs me to ask, what type of usb to serial chip is in your device? What
protocol does it use to talk to the host?
> I don't think that I have enough Linux experience to be able to test a patch
> and rebuild of the kernel, and I don't think that I can ask my customers to
> do that it order to use our product as a simple serial display.
They shouldn't have to do that, once we get it working, they get the
update automatically from their distro. But if you can't test any
changes we make to try to get this to work, there's not much we can do
here, right?
I think you need to figure out the protocol used by your device to talk
to the host. If you get that worked out, we can help to get Linux
working with it.
Oh, and fix that descriptor up in your firmware, that might solve
everything :)
Hope this helps,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: Linux USB Serial
From: Steven J. Ackerman @ 2012-09-17 21:56 UTC (permalink / raw)
To: 'Greg KH'; +Cc: 'Bjørn Mork', linux-usb, linux-serial
In-Reply-To: <20120917214136.GA20773@kroah.com>
Greg-
Thanks for your response.
Not sure if I need the cdc-acm functionality or not.
This is a color lcd display that supports a usb serial interface to
interact. I really
just need to be able to send and receive characters and NAK the pipe back
temporarily when my input buffer is full.
The descriptors were supplied by the chip vendor - Renesas - as part of a
CDC demo application. The VID/PID is ours. The device works great under
Windows XP with the descriptors as shown previously - even with the
Communications bInterfaceSubClass value wrong.
Doing the modprobe, etc. was based upon some blog posts that purported
to show how to add support for an unknown usb serial device.
Looking at the descriptor for a FTDI USB serial to TTL cable it seems a lot
simpler,
but it does indicate vendor specific class, subclass and protocol - which
means
that it requires a custom driver - ftdi_sio - right ? I don't really want
to have to
develop and support that.
I don't think that I have enough Linux experience to be able to test a patch
and rebuild of the kernel, and I don't think that I can ask my customers to
do
that it order to use our product as a simple serial display.
I'm running Ubuntu 10.10.
Any additional pointers and/or ideas would be greatly appreciated.
Thank you again,
Steven J. Ackerman, Consultant
ACS, Sarasota, FL
http://www.acscontrol.com
mailto:steve@acscontrol.com
> -----Original Message-----
> From: Greg KH [mailto:gregkh@linuxfoundation.org]
> Sent: Monday, September 17, 2012 5:42 PM
> To: Steven J. Ackerman
> Cc: 'Bjørn Mork'; linux-usb@vger.kernel.org; linux-serial@vger.kernel.org
> Subject: Re: Linux USB Serial
>
> On Mon, Sep 17, 2012 at 05:07:26PM -0400, Steven J. Ackerman wrote:
> > Bjrn-
> >
> > Thank you for your response.
> >
> > This change gets me closer. I can now successfully execute the modprobe
> > without error, but the device still doesn't show up in /dev/ttyUSB? .
> >
> > sja@UBUNTU-10:~$ sudo modprobe usbserial vendor=0x0c6a
> product=0x0005
>
> Eeek, no, never do that with a device you actually want to use. This
> should be controlled by the cdc-acm driver, not the usbserial driver.
> That driver should be auto-loaded for this device, but it looks like the
> descriptor is wrong, so it's not binding to it.
>
> Are you able to test a patch and rebuild the kernel to see if we can get
> this to work properly?
>
> thanks,
>
> greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Linux USB Serial
From: Greg KH @ 2012-09-17 21:41 UTC (permalink / raw)
To: Steven J. Ackerman; +Cc: 'Bjørn Mork', linux-usb, linux-serial
In-Reply-To: <00b801cd9518$715dd160$54197420$@acscontrol.com>
On Mon, Sep 17, 2012 at 05:07:26PM -0400, Steven J. Ackerman wrote:
> Bjrn-
>
> Thank you for your response.
>
> This change gets me closer. I can now successfully execute the modprobe
> without error, but the device still doesn't show up in /dev/ttyUSB? .
>
> sja@UBUNTU-10:~$ sudo modprobe usbserial vendor=0x0c6a product=0x0005
Eeek, no, never do that with a device you actually want to use. This
should be controlled by the cdc-acm driver, not the usbserial driver.
That driver should be auto-loaded for this device, but it looks like the
descriptor is wrong, so it's not binding to it.
Are you able to test a patch and rebuild the kernel to see if we can get
this to work properly?
thanks,
greg k-h
^ permalink raw reply
* RE: Linux USB Serial
From: Steven J. Ackerman @ 2012-09-17 21:07 UTC (permalink / raw)
To: 'Bjørn Mork'; +Cc: linux-usb, linux-serial
In-Reply-To: <87zk4o1kh4.fsf@nemi.mork.no>
Bjrn-
Thank you for your response.
This change gets me closer. I can now successfully execute the modprobe
without error, but the device still doesn't show up in /dev/ttyUSB? .
sja@UBUNTU-10:~$ sudo modprobe usbserial vendor=0x0c6a product=0x0005
sja@UBUNTU-10:~$ lsusb
Bus 005 Device 004: ID 0c6a:0005
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 003: ID 045e:0048 Microsoft Corp. Office Keyboard 1.0A
Bus 002 Device 002: ID 0557:7000 ATEN International Co., Ltd Hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
I guess it's still not happy about something...
Steven J. Ackerman, Consultant
ACS, Sarasota, FL
http://www.acscontrol.com
mailto:steve@acscontrol.com
> -----Original Message-----
> From: Bjørn Mork [mailto:bjorn@mork.no]
> Sent: Monday, September 17, 2012 4:08 PM
> To: Steven J. Ackerman
> Cc: linux-usb@vger.kernel.org; linux-serial@vger.kernel.org
> Subject: Re: Linux USB Serial
>
> "Steven J. Ackerman" <steve@acscontrol.com> writes:
>
> > Interface Descriptor:
> > bLength 9
> > bDescriptorType 4
> > bInterfaceNumber 0
> > bAlternateSetting 0
> > bNumEndpoints 1
> > bInterfaceClass 2 Communications
> > bInterfaceSubClass 32
>
> Looks like your bInterfaceSubClass is nibble swapped. It should be 0x02
> for ACM, not 0x20.
>
>
> Bjrn
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Linux USB Serial
From: Bjørn Mork @ 2012-09-17 20:07 UTC (permalink / raw)
To: Steven J. Ackerman; +Cc: linux-usb, linux-serial
In-Reply-To: <00a301cd950a$ae9081d0$0bb18570$@acscontrol.com>
"Steven J. Ackerman" <steve@acscontrol.com> writes:
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 0
> bAlternateSetting 0
> bNumEndpoints 1
> bInterfaceClass 2 Communications
> bInterfaceSubClass 32
Looks like your bInterfaceSubClass is nibble swapped. It should be 0x02
for ACM, not 0x20.
Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Linux USB Serial
From: Steven J. Ackerman @ 2012-09-17 19:28 UTC (permalink / raw)
To: linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-serial-u79uwXL29TY76Z2rM5mHXA
Hello-
Looking to provide support under Linux for our device which implements
a USB virtual serial port using the Communications Device Class.
The device enumerates and communicates correctly under Windows XP,
and shows up under lsusb -v command as:
Bus 005 Device 005: ID 0c6a:0005
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 2 Communications
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x0c6a
idProduct 0x0005
bcdDevice 1.00
iManufacturer 1 ACS
iProduct 2 ACS-LCD-Color-320x240
iSerial 3 1.0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 67
bNumInterfaces 2
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xc0
Self Powered
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 2 Communications
bInterfaceSubClass 32
bInterfaceProtocol 0
iInterface 0
CDC Header:
bcdCDC 1.10
CDC ACM:
bmCapabilities 0x02
line coding and serial state
CDC Union:
bMasterInterface 0
bSlaveInterface 1
CDC Call Management:
bmCapabilities 0x00
bDataInterface 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0008 1x 8 bytes
bInterval 255
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 10 CDC Data
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Device Status: 0x0000
(Bus Powered)
However it does not show up without the -verbose option.
Trying to load the usbserial module to activate the device results in the
following error:
FATAL: Module vendor=0x0c6a not found.
Can anyone provide assistance in how to troubleshoot why Linux is
not happy with this USB device ?
Thank you,
Steven J. Ackerman, Consultant
ACS, Sarasota, FL
http://www.acscontrol.com
mailto:steve-I01wfHm1r9xGyKhy+UYuEA@public.gmane.org
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] serial: set correct baud_base for EXSYS EX-41092 Dual 16950
From: Flavio Leitner @ 2012-09-17 18:53 UTC (permalink / raw)
To: linux-serial, linux-kernel; +Cc: Niels de Vos, Alan Cox, Flavio Leitner
Apparently the same card model has two IDs, so this patch
complements the commit 39aced68d664291db3324d0fcf0985ab5626aac2
adding the missing one.
Signed-off-by: Flavio Leitner <fbl@redhat.com>
---
drivers/tty/serial/8250/8250_pci.c | 7 +++++--
include/linux/pci_ids.h | 3 ++-
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_pci.c b/drivers/tty/serial/8250/8250_pci.c
index 28e7c7c..6fe88e6 100644
--- a/drivers/tty/serial/8250/8250_pci.c
+++ b/drivers/tty/serial/8250/8250_pci.c
@@ -3232,8 +3232,11 @@ static struct pci_device_id serial_pci_tbl[] = {
* For now just used the hex ID 0x950a.
*/
{ PCI_VENDOR_ID_OXSEMI, 0x950a,
- PCI_SUBVENDOR_ID_SIIG, PCI_SUBDEVICE_ID_SIIG_DUAL_SERIAL, 0, 0,
- pbn_b0_2_115200 },
+ PCI_SUBVENDOR_ID_SIIG, PCI_SUBDEVICE_ID_SIIG_DUAL_SERIAL_00,
+ 0, 0, pbn_b0_2_115200 },
+ { PCI_VENDOR_ID_OXSEMI, 0x950a,
+ PCI_SUBVENDOR_ID_SIIG, PCI_SUBDEVICE_ID_SIIG_DUAL_SERIAL_30,
+ 0, 0, pbn_b0_2_115200 },
{ PCI_VENDOR_ID_OXSEMI, 0x950a,
PCI_ANY_ID, PCI_ANY_ID, 0, 0,
pbn_b0_2_1130000 },
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index 6b4565c..4242013 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -1847,7 +1847,8 @@
#define PCI_DEVICE_ID_SIIG_8S_20x_650 0x2081
#define PCI_DEVICE_ID_SIIG_8S_20x_850 0x2082
#define PCI_SUBDEVICE_ID_SIIG_QUARTET_SERIAL 0x2050
-#define PCI_SUBDEVICE_ID_SIIG_DUAL_SERIAL 0x2530
+#define PCI_SUBDEVICE_ID_SIIG_DUAL_SERIAL_00 0x2500
+#define PCI_SUBDEVICE_ID_SIIG_DUAL_SERIAL_30 0x2530
#define PCI_VENDOR_ID_RADISYS 0x1331
--
1.7.11.4
^ permalink raw reply related
* Re: [PATCH v7 0/11] KGDB/KDB FIQ (NMI) debugger
From: Greg Kroah-Hartman @ 2012-09-17 15:54 UTC (permalink / raw)
To: Anton Vorontsov
Cc: Jason Wessel, Andrew Morton, Russell King, Alan Cox,
Arve Hjønnevåg, Colin Cross, Brian Swetland,
John Stultz, Thomas Gleixner, linux-kernel, linux-arm-kernel,
linaro-kernel, patches, kernel-team, kgdb-bugreport, linux-serial
In-Reply-To: <20120917153943.GA7510@lizard>
On Mon, Sep 17, 2012 at 08:39:43AM -0700, Anton Vorontsov wrote:
> On Mon, Sep 17, 2012 at 05:54:27AM -0700, Greg Kroah-Hartman wrote:
> [...]
> > > > To make it easier, can I just take the tty driver patches now? Will
> > > > that break anything?
> > >
> > > I have not made my way through the entire series yet, so I am not sure
> > > if you need the kdb header changes or not, but so far it looks like
> > > the tty pieces are separate. If you add your ack Greg, I'll take the
> > > whole series and merge it into kgdb-next, or after I finish the review
> > > we could do it the other way around.
> >
> > Your tree is fine:
> >
> > Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> >
> > Let me know if you have problems merging this due to any tty patches,
> > and if so, I'll be glad to take them through my tree.
>
> Guys, thanks for taking a look into this!
>
> The patch that adds nmi console driver (i.e. tty/serial/kgdb_nmi.c)
> depends on the first KDB patches in these series, and it depends on
> amba-pl1011 and tty_port work, which is in tty-next.
>
> So, the series have to go via tty-next; I believe Jason won't able
> to take it via his tree.
Ok, I'll wait for Jason to review them. Jason, let me know how it
goes...
greg k-h
^ permalink raw reply
* Re: [PATCH v7 0/11] KGDB/KDB FIQ (NMI) debugger
From: Anton Vorontsov @ 2012-09-17 15:39 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Jason Wessel, Andrew Morton, Russell King, Alan Cox,
Arve Hjønnevåg, Colin Cross, Brian Swetland,
John Stultz, Thomas Gleixner, linux-kernel, linux-arm-kernel,
linaro-kernel, patches, kernel-team, kgdb-bugreport, linux-serial
In-Reply-To: <20120917125427.GA23516@kroah.com>
On Mon, Sep 17, 2012 at 05:54:27AM -0700, Greg Kroah-Hartman wrote:
[...]
> > > To make it easier, can I just take the tty driver patches now? Will
> > > that break anything?
> >
> > I have not made my way through the entire series yet, so I am not sure
> > if you need the kdb header changes or not, but so far it looks like
> > the tty pieces are separate. If you add your ack Greg, I'll take the
> > whole series and merge it into kgdb-next, or after I finish the review
> > we could do it the other way around.
>
> Your tree is fine:
>
> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
> Let me know if you have problems merging this due to any tty patches,
> and if so, I'll be glad to take them through my tree.
Guys, thanks for taking a look into this!
The patch that adds nmi console driver (i.e. tty/serial/kgdb_nmi.c)
depends on the first KDB patches in these series, and it depends on
amba-pl1011 and tty_port work, which is in tty-next.
So, the series have to go via tty-next; I believe Jason won't able
to take it via his tree.
Thanks,
Anton.
^ permalink raw reply
* Re: [PATCH v7 0/11] KGDB/KDB FIQ (NMI) debugger
From: Greg Kroah-Hartman @ 2012-09-17 12:54 UTC (permalink / raw)
To: Jason Wessel
Cc: Anton Vorontsov, Andrew Morton, Russell King, Alan Cox,
Arve Hjønnevåg, Colin Cross, Brian Swetland,
John Stultz, Thomas Gleixner, linux-kernel, linux-arm-kernel,
linaro-kernel, patches, kernel-team, kgdb-bugreport, linux-serial
In-Reply-To: <50571ADF.3000406@windriver.com>
On Mon, Sep 17, 2012 at 07:43:11AM -0500, Jason Wessel wrote:
> On 09/17/2012 06:37 AM, Greg Kroah-Hartman wrote:
> > On Thu, Sep 13, 2012 at 08:01:33AM -0700, Anton Vorontsov wrote:
> >> Hi all,
> >>
> >> Here comes the lucky v7:
> >>
> >> - Per Alan Cox's suggestion added hangup method and removed a small
> >> leftover;
> >> - Per Colin Cross' suggestion moved IRQ quiescing logic into
> >> poll_get_char routine. IIUC, Alan is less unhappy about it. As a
> >> result, clear_irq() callback dropped.
> >>
> >> These patches can be found in the following repo (based on tty-next):
> >>
> >> git://git.infradead.org/users/cbou/linux-nmi-kdb.git master
> >>
> >> Old changelogs and rationale for these patches can be found here:
> >>
> >> v1-v5, rationale: http://lkml.org/lkml/2012/9/10/2
> >> v6: http://lkml.org/lkml/2012/9/10/2
> > I have no objection to these patches, and as they are based on my
> > tty-next tree, should I be the ones accepting them? If so, then I need
> > a bunch of acks from others involved in the kdb/kgdb code before I can
> > do so.
> >
> > To make it easier, can I just take the tty driver patches now? Will
> > that break anything?
>
> I have not made my way through the entire series yet, so I am not sure
> if you need the kdb header changes or not, but so far it looks like
> the tty pieces are separate. If you add your ack Greg, I'll take the
> whole series and merge it into kgdb-next, or after I finish the review
> we could do it the other way around.
Your tree is fine:
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Let me know if you have problems merging this due to any tty patches,
and if so, I'll be glad to take them through my tree.
greg k-h
^ permalink raw reply
* Re: [PATCH v7 0/11] KGDB/KDB FIQ (NMI) debugger
From: Jason Wessel @ 2012-09-17 12:43 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Anton Vorontsov, Andrew Morton, Russell King, Alan Cox,
Arve Hjønnevåg, Colin Cross, Brian Swetland,
John Stultz, Thomas Gleixner, linux-kernel, linux-arm-kernel,
linaro-kernel, patches, kernel-team, kgdb-bugreport, linux-serial
In-Reply-To: <20120917113750.GA28838@kroah.com>
On 09/17/2012 06:37 AM, Greg Kroah-Hartman wrote:
> On Thu, Sep 13, 2012 at 08:01:33AM -0700, Anton Vorontsov wrote:
>> Hi all,
>>
>> Here comes the lucky v7:
>>
>> - Per Alan Cox's suggestion added hangup method and removed a small
>> leftover;
>> - Per Colin Cross' suggestion moved IRQ quiescing logic into
>> poll_get_char routine. IIUC, Alan is less unhappy about it. As a
>> result, clear_irq() callback dropped.
>>
>> These patches can be found in the following repo (based on tty-next):
>>
>> git://git.infradead.org/users/cbou/linux-nmi-kdb.git master
>>
>> Old changelogs and rationale for these patches can be found here:
>>
>> v1-v5, rationale: http://lkml.org/lkml/2012/9/10/2
>> v6: http://lkml.org/lkml/2012/9/10/2
> I have no objection to these patches, and as they are based on my
> tty-next tree, should I be the ones accepting them? If so, then I need
> a bunch of acks from others involved in the kdb/kgdb code before I can
> do so.
>
> To make it easier, can I just take the tty driver patches now? Will
> that break anything?
I have not made my way through the entire series yet, so I am not sure if you need the kdb header changes or not, but so far it looks like the tty pieces are separate. If you add your ack Greg, I'll take the whole series and merge it into kgdb-next, or after I finish the review we could do it the other way around.
Cheers,
Jason.
^ permalink raw reply
* Re: [PATCH v7 0/11] KGDB/KDB FIQ (NMI) debugger
From: Greg Kroah-Hartman @ 2012-09-17 11:37 UTC (permalink / raw)
To: Anton Vorontsov
Cc: Andrew Morton, Russell King, Jason Wessel, Alan Cox,
Arve Hjønnevåg, Colin Cross, Brian Swetland,
John Stultz, Thomas Gleixner, linux-kernel, linux-arm-kernel,
linaro-kernel, patches, kernel-team, kgdb-bugreport, linux-serial
In-Reply-To: <20120913150133.GA16238@lizard>
On Thu, Sep 13, 2012 at 08:01:33AM -0700, Anton Vorontsov wrote:
> Hi all,
>
> Here comes the lucky v7:
>
> - Per Alan Cox's suggestion added hangup method and removed a small
> leftover;
> - Per Colin Cross' suggestion moved IRQ quiescing logic into
> poll_get_char routine. IIUC, Alan is less unhappy about it. As a
> result, clear_irq() callback dropped.
>
> These patches can be found in the following repo (based on tty-next):
>
> git://git.infradead.org/users/cbou/linux-nmi-kdb.git master
>
> Old changelogs and rationale for these patches can be found here:
>
> v1-v5, rationale: http://lkml.org/lkml/2012/9/10/2
> v6: http://lkml.org/lkml/2012/9/10/2
I have no objection to these patches, and as they are based on my
tty-next tree, should I be the ones accepting them? If so, then I need
a bunch of acks from others involved in the kdb/kgdb code before I can
do so.
To make it easier, can I just take the tty driver patches now? Will
that break anything?
thanks,
greg k-h
^ permalink raw reply
* [PATCH] tty: Fix hvc return
From: Alan Cox @ 2012-09-17 11:03 UTC (permalink / raw)
To: greg, linux-serial
From: Alan Cox <alan@linux.intel.com>
HVC returns a size of -1 bytes for the write room in some cases.
This is bogus and not handled by the tty layer at all.
Signed-off-by: Alan Cox <alan@linux.intel.com>
---
drivers/tty/hvc/hvc_console.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c
index b57dcbd..a5dec1c 100644
--- a/drivers/tty/hvc/hvc_console.c
+++ b/drivers/tty/hvc/hvc_console.c
@@ -568,7 +568,7 @@ static int hvc_write_room(struct tty_struct *tty)
struct hvc_struct *hp = tty->driver_data;
if (!hp)
- return -1;
+ return 0;
return hp->outbuf_size - hp->n_outbuf;
}
^ permalink raw reply related
* [PATCH] n_gsm: Fix incorrect debug display
From: Alan Cox @ 2012-09-17 11:02 UTC (permalink / raw)
To: greg, linux-serial
From: Alan Cox <alan@linux.intel.com>
In the trace we print the wrong values for N(R) on an I frame.
Correct the mask.
Signed-off-by: Alan Cox <alan@linux.intel.com>
---
drivers/tty/n_gsm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/n_gsm.c b/drivers/tty/n_gsm.c
index 3e210a4..1e8e8ce 100644
--- a/drivers/tty/n_gsm.c
+++ b/drivers/tty/n_gsm.c
@@ -488,7 +488,7 @@ static void gsm_print_packet(const char *hdr, int addr, int cr,
default:
if (!(control & 0x01)) {
pr_cont("I N(S)%d N(R)%d",
- (control & 0x0E) >> 1, (control & 0xE) >> 5);
+ (control & 0x0E) >> 1, (control & 0xE0) >> 5);
} else switch (control & 0x0F) {
case RR:
pr_cont("RR(%d)", (control & 0xE0) >> 5);
^ permalink raw reply related
* [PATCH] ipwireless: check ppp register worked
From: Alan Cox @ 2012-09-17 11:01 UTC (permalink / raw)
To: greg, linux-serial
From: Alan Cox <alan@linux.intel.com>
Otherwise we start trying to use a bogus channel - ungood.
Signed-off-by: Alan Cox <alan@linux.intel.com>
---
drivers/tty/ipwireless/network.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/ipwireless/network.c b/drivers/tty/ipwireless/network.c
index 90ea902..57102e6 100644
--- a/drivers/tty/ipwireless/network.c
+++ b/drivers/tty/ipwireless/network.c
@@ -274,7 +274,12 @@ static void do_go_online(struct work_struct *work_go_online)
network->xaccm[0] = ~0U;
network->xaccm[3] = 0x60000000U;
network->raccm = ~0U;
- ppp_register_channel(channel);
+ if (ppp_register_channel(channel) < 0) {
+ printk(KERN_ERR IPWIRELESS_PCCARD_NAME
+ ": unable to register PPP channel\n");
+ kfree(channel);
+ return;
+ }
spin_lock_irqsave(&network->lock, flags);
network->ppp_channel = channel;
}
^ permalink raw reply related
* [PATCH] max3100: Fix error case
From: Alan Cox @ 2012-09-17 11:00 UTC (permalink / raw)
To: greg, linux-serial
From: Alan Cox <alan@linux.intel.com>
We don't want to free a random address if the entry is wrong, cover
this and WARN if it ever happens.
Signed-off-by: Alan Cox <alan@linux.intel.com>
---
drivers/tty/serial/max3100.c | 14 ++++++++------
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/tty/serial/max3100.c b/drivers/tty/serial/max3100.c
index 46043c2..0f24486 100644
--- a/drivers/tty/serial/max3100.c
+++ b/drivers/tty/serial/max3100.c
@@ -827,14 +827,16 @@ static int __devexit max3100_remove(struct spi_device *spi)
/* find out the index for the chip we are removing */
for (i = 0; i < MAX_MAX3100; i++)
- if (max3100s[i] == s)
+ if (max3100s[i] == s) {
+ dev_dbg(&spi->dev, "%s: removing port %d\n", __func__, i);
+ uart_remove_one_port(&max3100_uart_driver, &max3100s[i]->port);
+ kfree(max3100s[i]);
+ max3100s[i] = NULL;
break;
+ }
- dev_dbg(&spi->dev, "%s: removing port %d\n", __func__, i);
- uart_remove_one_port(&max3100_uart_driver, &max3100s[i]->port);
- kfree(max3100s[i]);
- max3100s[i] = NULL;
-
+ WARN_ON(i == MAX_MAX3100);
+
/* check if this is the last chip we have */
for (i = 0; i < MAX_MAX3100; i++)
if (max3100s[i]) {
^ permalink raw reply related
* Re: [PATCH] serial: Samsung: Fix return value
From: Sachin Kamat @ 2012-09-17 10:39 UTC (permalink / raw)
To: linux-serial; +Cc: alan, gregkh, sachin.kamat, patches, alan
In-Reply-To: <1347431401-3306-1-git-send-email-sachin.kamat@linaro.org>
ping..
On 12 September 2012 12:00, Sachin Kamat <sachin.kamat@linaro.org> wrote:
> Return the value returned by the failing function instead
> of -1 (which does not convey the right error information).
>
> Fixes the following smatch warning:
> drivers/tty/serial/samsung.c:1687 s3c24xx_serial_modinit() info:
> why not propagate 'ret' from uart_register_driver() instead of -1?
>
> Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
> ---
> drivers/tty/serial/samsung.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/tty/serial/samsung.c b/drivers/tty/serial/samsung.c
> index bdaa06f..8eef114 100644
> --- a/drivers/tty/serial/samsung.c
> +++ b/drivers/tty/serial/samsung.c
> @@ -1684,7 +1684,7 @@ static int __init s3c24xx_serial_modinit(void)
> ret = uart_register_driver(&s3c24xx_uart_drv);
> if (ret < 0) {
> pr_err("Failed to register Samsung UART driver\n");
> - return -1;
> + return ret;
> }
>
> return platform_driver_register(&samsung_serial_driver);
> --
> 1.7.4.1
>
--
With warm regards,
Sachin
^ permalink raw reply
* [PATCH updated 07/11] tty/serial: Add kgdb_nmi driver
From: Anton Vorontsov @ 2012-09-17 1:07 UTC (permalink / raw)
To: Francesco Lavra
Cc: Andrew Morton, Russell King, Jason Wessel, Greg Kroah-Hartman,
Alan Cox, linaro-kernel, patches, Brian Swetland, linux-kernel,
Arve Hjønnevåg, linux-serial, Colin Cross,
kgdb-bugreport, kernel-team, linux-arm-kernel
In-Reply-To: <5054A456.80606@gmail.com>
This special driver makes it possible to temporary use NMI debugger port
as a normal console by issuing 'nmi_console' command (assuming that the
port is attached to KGDB).
Unlike KDB's disable_nmi command, with this driver you are always able
to go back to the debugger using KGDB escape sequence ($3#33). This is
because this console driver processes the input in NMI context, and thus
is able to intercept the magic sequence.
Note that since the console interprets input and uses polling
communication methods, for things like PPP it is still better to fully
detach debugger port from the KGDB NMI (i.e. disable_nmi), and use raw
console.
Usually, to enter the debugger one have to type the magic sequence, so
initially the kernel will print the following prompt on the NMI debugger
console:
Type $3#33 to enter the debugger>
For convenience, there is a kgdb_fiq.knock kernel command line option,
when set to 0, this turns the special command to just a return key
press, so the kernel will be printing this:
Hit <return> to enter the debugger>
This is more convenient for long debugging sessions, although it makes
nmi_console feature somewhat useless.
And for the cases when NMI connected to a dedicated button, the knocking
can be disabled altogether by setting kgdb_fiq.knock to -1.
Suggested-by: Colin Cross <ccross@android.com>
Signed-off-by: Anton Vorontsov <anton.vorontsov@linaro.org>
Acked-by: Alan Cox <alan@linux.intel.com>
---
On Sat, Sep 15, 2012 at 05:52:54PM +0200, Francesco Lavra wrote:
[...]
> > + pr_err("%s: can't nstall tty port: %d\n", __func__, ret);
>
> s/nstall/install
[..]
> > + err = kgdb_register_nmi_console();
> > + if (err)
> > + goto noconfig;
>
> If kgdb_register_nmi_console() fails, kgdb_unregister_io_module() must
> be called for proper cleanup
Thanks for catching! Both issues fixed now, the updated patch down blow.
drivers/tty/serial/Kconfig | 19 ++
drivers/tty/serial/Makefile | 1 +
drivers/tty/serial/kgdb_nmi.c | 396 ++++++++++++++++++++++++++++++++++++++++++
drivers/tty/serial/kgdboc.c | 9 +
include/linux/kgdb.h | 10 ++
5 files changed, 435 insertions(+)
create mode 100644 drivers/tty/serial/kgdb_nmi.c
diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index 26907cf..b22e45b 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -141,6 +141,25 @@ config SERIAL_ATMEL_TTYAT
Say Y if you have an external 8250/16C550 UART. If unsure, say N.
+config SERIAL_KGDB_NMI
+ bool "Serial console over KGDB NMI debugger port"
+ depends on KGDB_SERIAL_CONSOLE
+ help
+ This special driver allows you to temporary use NMI debugger port
+ as a normal console (assuming that the port is attached to KGDB).
+
+ Unlike KDB's disable_nmi command, with this driver you are always
+ able to go back to the debugger using KGDB escape sequence ($3#33).
+ This is because this console driver processes the input in NMI
+ context, and thus is able to intercept the magic sequence.
+
+ Note that since the console interprets input and uses polling
+ communication methods, for things like PPP you still must fully
+ detach debugger port from the KGDB NMI (i.e. disable_nmi), and
+ use raw console.
+
+ If unsure, say N.
+
config SERIAL_KS8695
bool "Micrel KS8695 (Centaur) serial port support"
depends on ARCH_KS8695
diff --git a/drivers/tty/serial/Makefile b/drivers/tty/serial/Makefile
index ce88667..4f694da 100644
--- a/drivers/tty/serial/Makefile
+++ b/drivers/tty/serial/Makefile
@@ -61,6 +61,7 @@ obj-$(CONFIG_SERIAL_MSM_HS) += msm_serial_hs.o
obj-$(CONFIG_SERIAL_NETX) += netx-serial.o
obj-$(CONFIG_SERIAL_OF_PLATFORM) += of_serial.o
obj-$(CONFIG_SERIAL_OF_PLATFORM_NWPSERIAL) += nwpserial.o
+obj-$(CONFIG_SERIAL_KGDB_NMI) += kgdb_nmi.o
obj-$(CONFIG_SERIAL_KS8695) += serial_ks8695.o
obj-$(CONFIG_SERIAL_OMAP) += omap-serial.o
obj-$(CONFIG_SERIAL_ALTERA_UART) += altera_uart.o
diff --git a/drivers/tty/serial/kgdb_nmi.c b/drivers/tty/serial/kgdb_nmi.c
new file mode 100644
index 0000000..ccc7437
--- /dev/null
+++ b/drivers/tty/serial/kgdb_nmi.c
@@ -0,0 +1,396 @@
+/*
+ * KGDB NMI serial console
+ *
+ * Copyright 2010 Google, Inc.
+ * Arve Hjønnevåg <arve@android.com>
+ * Colin Cross <ccross@android.com>
+ * Copyright 2012 Linaro Ltd.
+ * Anton Vorontsov <anton.vorontsov@linaro.org>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/compiler.h>
+#include <linux/init.h>
+#include <linux/slab.h>
+#include <linux/errno.h>
+#include <linux/atomic.h>
+#include <linux/console.h>
+#include <linux/tty.h>
+#include <linux/tty_driver.h>
+#include <linux/tty_flip.h>
+#include <linux/interrupt.h>
+#include <linux/hrtimer.h>
+#include <linux/tick.h>
+#include <linux/kfifo.h>
+#include <linux/kgdb.h>
+#include <linux/kdb.h>
+
+static int kgdb_nmi_knock = 1;
+module_param_named(knock, kgdb_nmi_knock, int, 0600);
+MODULE_PARM_DESC(knock, "if set to 1 (default), the special '$3#33' command "
+ "must be used to enter the debugger; when set to 0, "
+ "hitting return key is enough to enter the debugger; "
+ "when set to -1, the debugger is entered immediately "
+ "upon NMI");
+
+static char *kgdb_nmi_magic = "$3#33";
+module_param_named(magic, kgdb_nmi_magic, charp, 0600);
+MODULE_PARM_DESC(magic, "magic sequence to enter NMI debugger (default $3#33)");
+
+static bool kgdb_nmi_tty_enabled;
+
+static void kgdb_nmi_console_write(struct console *co, const char *s, uint c)
+{
+ int i;
+
+ if (!kgdb_nmi_tty_enabled || atomic_read(&kgdb_active) >= 0)
+ return;
+
+ for (i = 0; i < c; i++)
+ dbg_io_ops->write_char(s[i]);
+}
+
+static struct tty_driver *kgdb_nmi_tty_driver;
+
+static struct tty_driver *kgdb_nmi_console_device(struct console *co, int *idx)
+{
+ *idx = co->index;
+ return kgdb_nmi_tty_driver;
+}
+
+static struct console kgdb_nmi_console = {
+ .name = "ttyNMI",
+ .write = kgdb_nmi_console_write,
+ .device = kgdb_nmi_console_device,
+ .flags = CON_PRINTBUFFER | CON_ANYTIME | CON_ENABLED,
+ .index = -1,
+};
+
+/*
+ * This is usually the maximum rate on debug ports. We make fifo large enough
+ * to make copy-pasting to the terminal usable.
+ */
+#define KGDB_NMI_BAUD 115200
+#define KGDB_NMI_FIFO_SIZE roundup_pow_of_two(KGDB_NMI_BAUD / 8 / HZ)
+
+struct kgdb_nmi_tty_priv {
+ struct tty_port port;
+ struct tasklet_struct tlet;
+ STRUCT_KFIFO(char, KGDB_NMI_FIFO_SIZE) fifo;
+};
+
+static struct kgdb_nmi_tty_priv *kgdb_nmi_port_to_priv(struct tty_port *port)
+{
+ return container_of(port, struct kgdb_nmi_tty_priv, port);
+}
+
+/*
+ * Our debugging console is polled in a tasklet, so we'll check for input
+ * every tick. In HZ-less mode, we should program the next tick. We have
+ * to use the lowlevel stuff as no locks should be grabbed.
+ */
+#ifdef CONFIG_HIGH_RES_TIMERS
+static void kgdb_tty_poke(void)
+{
+ tick_program_event(ktime_get(), 0);
+}
+#else
+static inline void kgdb_tty_poke(void) {}
+#endif
+
+static struct tty_port *kgdb_nmi_port;
+
+static void kgdb_tty_recv(int ch)
+{
+ struct kgdb_nmi_tty_priv *priv;
+ char c = ch;
+
+ if (!kgdb_nmi_port || ch < 0)
+ return;
+ /*
+ * Can't use port->tty->driver_data as tty might be not there. Tasklet
+ * will check for tty and will get the ref, but here we don't have to
+ * do that, and actually, we can't: we're in NMI context, no locks are
+ * possible.
+ */
+ priv = kgdb_nmi_port_to_priv(kgdb_nmi_port);
+ kfifo_in(&priv->fifo, &c, 1);
+ kgdb_tty_poke();
+}
+
+static int kgdb_nmi_poll_one_knock(void)
+{
+ static int n;
+ int c = -1;
+ const char *magic = kgdb_nmi_magic;
+ size_t m = strlen(magic);
+ bool printch = 0;
+
+ c = dbg_io_ops->read_char();
+ if (c == NO_POLL_CHAR)
+ return c;
+
+ if (!kgdb_nmi_knock && (c == '\r' || c == '\n')) {
+ return 1;
+ } else if (c == magic[n]) {
+ n = (n + 1) % m;
+ if (!n)
+ return 1;
+ printch = 1;
+ } else {
+ n = 0;
+ }
+
+ if (kgdb_nmi_tty_enabled) {
+ kgdb_tty_recv(c);
+ return 0;
+ }
+
+ if (printch) {
+ kdb_printf("%c", c);
+ return 0;
+ }
+
+ kdb_printf("\r%s %s to enter the debugger> %*s",
+ kgdb_nmi_knock ? "Type" : "Hit",
+ kgdb_nmi_knock ? magic : "<return>", m, "");
+ while (m--)
+ kdb_printf("\b");
+ return 0;
+}
+
+/**
+ * kgdb_nmi_poll_knock - Check if it is time to enter the debugger
+ *
+ * "Serial ports are often noisy, especially when muxed over another port (we
+ * often use serial over the headset connector). Noise on the async command
+ * line just causes characters that are ignored, on a command line that blocked
+ * execution noise would be catastrophic." -- Colin Cross
+ *
+ * So, this function implements KGDB/KDB knocking on the serial line: we won't
+ * enter the debugger until we receive a known magic phrase (which is actually
+ * "$3#33", known as "escape to KDB" command. There is also a relaxed variant
+ * of knocking, i.e. just pressing the return key is enough to enter the
+ * debugger. And if knocking is disabled, the function always returns 1.
+ */
+bool kgdb_nmi_poll_knock(void)
+{
+ if (kgdb_nmi_knock < 0)
+ return 1;
+
+ while (1) {
+ int ret;
+
+ ret = kgdb_nmi_poll_one_knock();
+ if (ret == NO_POLL_CHAR)
+ return 0;
+ else if (ret == 1)
+ break;
+ }
+ return 1;
+}
+
+/*
+ * The tasklet is cheap, it does not cause wakeups when reschedules itself,
+ * instead it waits for the next tick.
+ */
+static void kgdb_nmi_tty_receiver(unsigned long data)
+{
+ struct kgdb_nmi_tty_priv *priv = (void *)data;
+ struct tty_struct *tty;
+ char ch;
+
+ tasklet_schedule(&priv->tlet);
+
+ if (likely(!kgdb_nmi_tty_enabled || !kfifo_len(&priv->fifo)))
+ return;
+
+ /* Port is there, but tty might be hung up, check. */
+ tty = tty_port_tty_get(kgdb_nmi_port);
+ if (!tty)
+ return;
+
+ while (kfifo_out(&priv->fifo, &ch, 1))
+ tty_insert_flip_char(priv->port.tty, ch, TTY_NORMAL);
+ tty_flip_buffer_push(priv->port.tty);
+
+ tty_kref_put(tty);
+}
+
+static int kgdb_nmi_tty_activate(struct tty_port *port, struct tty_struct *tty)
+{
+ struct kgdb_nmi_tty_priv *priv = tty->driver_data;
+
+ kgdb_nmi_port = port;
+ tasklet_schedule(&priv->tlet);
+ return 0;
+}
+
+static void kgdb_nmi_tty_shutdown(struct tty_port *port)
+{
+ struct kgdb_nmi_tty_priv *priv = port->tty->driver_data;
+
+ tasklet_kill(&priv->tlet);
+ kgdb_nmi_port = NULL;
+}
+
+static const struct tty_port_operations kgdb_nmi_tty_port_ops = {
+ .activate = kgdb_nmi_tty_activate,
+ .shutdown = kgdb_nmi_tty_shutdown,
+};
+
+static int kgdb_nmi_tty_install(struct tty_driver *drv, struct tty_struct *tty)
+{
+ struct kgdb_nmi_tty_priv *priv;
+ int ret;
+
+ priv = kzalloc(sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ INIT_KFIFO(priv->fifo);
+ tasklet_init(&priv->tlet, kgdb_nmi_tty_receiver, (unsigned long)priv);
+ tty_port_init(&priv->port);
+ priv->port.ops = &kgdb_nmi_tty_port_ops;
+ tty->driver_data = priv;
+
+ ret = tty_port_install(&priv->port, drv, tty);
+ if (ret) {
+ pr_err("%s: can't install tty port: %d\n", __func__, ret);
+ goto err;
+ }
+ return 0;
+err:
+ kfree(priv);
+ return ret;
+}
+
+static void kgdb_nmi_tty_cleanup(struct tty_struct *tty)
+{
+ struct kgdb_nmi_tty_priv *priv = tty->driver_data;
+
+ tty->driver_data = NULL;
+ kfree(priv);
+}
+
+static int kgdb_nmi_tty_open(struct tty_struct *tty, struct file *file)
+{
+ struct kgdb_nmi_tty_priv *priv = tty->driver_data;
+
+ return tty_port_open(&priv->port, tty, file);
+}
+
+static void kgdb_nmi_tty_close(struct tty_struct *tty, struct file *file)
+{
+ struct kgdb_nmi_tty_priv *priv = tty->driver_data;
+
+ tty_port_close(&priv->port, tty, file);
+}
+
+static void kgdb_nmi_tty_hangup(struct tty_struct *tty)
+{
+ struct kgdb_nmi_tty_priv *priv = tty->driver_data;
+
+ tty_port_hangup(&priv->port);
+}
+
+static int kgdb_nmi_tty_write_room(struct tty_struct *tty)
+{
+ /* Actually, we can handle any amount as we use polled writes. */
+ return 2048;
+}
+
+static int kgdb_nmi_tty_write(struct tty_struct *tty, const unchar *buf, int c)
+{
+ int i;
+
+ for (i = 0; i < c; i++)
+ dbg_io_ops->write_char(buf[i]);
+ return c;
+}
+
+static const struct tty_operations kgdb_nmi_tty_ops = {
+ .open = kgdb_nmi_tty_open,
+ .close = kgdb_nmi_tty_close,
+ .install = kgdb_nmi_tty_install,
+ .cleanup = kgdb_nmi_tty_cleanup,
+ .hangup = kgdb_nmi_tty_hangup,
+ .write_room = kgdb_nmi_tty_write_room,
+ .write = kgdb_nmi_tty_write,
+};
+
+static int kgdb_nmi_enable_console(int argc, const char *argv[])
+{
+ kgdb_nmi_tty_enabled = !(argc == 1 && !strcmp(argv[1], "off"));
+ return 0;
+}
+
+int kgdb_register_nmi_console(void)
+{
+ int ret;
+
+ kgdb_nmi_tty_driver = alloc_tty_driver(1);
+ if (!kgdb_nmi_tty_driver) {
+ pr_err("%s: cannot allocate tty\n", __func__);
+ return -ENOMEM;
+ }
+ kgdb_nmi_tty_driver->driver_name = "ttyNMI";
+ kgdb_nmi_tty_driver->name = "ttyNMI";
+ kgdb_nmi_tty_driver->num = 1;
+ kgdb_nmi_tty_driver->type = TTY_DRIVER_TYPE_SERIAL;
+ kgdb_nmi_tty_driver->subtype = SERIAL_TYPE_NORMAL;
+ kgdb_nmi_tty_driver->flags = TTY_DRIVER_REAL_RAW;
+ kgdb_nmi_tty_driver->init_termios = tty_std_termios;
+ tty_termios_encode_baud_rate(&kgdb_nmi_tty_driver->init_termios,
+ KGDB_NMI_BAUD, KGDB_NMI_BAUD);
+ tty_set_operations(kgdb_nmi_tty_driver, &kgdb_nmi_tty_ops);
+
+ ret = tty_register_driver(kgdb_nmi_tty_driver);
+ if (ret) {
+ pr_err("%s: can't register tty driver: %d\n", __func__, ret);
+ goto err_drv_reg;
+ }
+
+ ret = kdb_register("nmi_console", kgdb_nmi_enable_console, "[off]",
+ "switch to Linux NMI console", 0);
+ if (ret) {
+ pr_err("%s: can't register kdb command: %d\n", __func__, ret);
+ goto err_kdb_reg;
+ }
+
+ register_console(&kgdb_nmi_console);
+ kgdb_enable_nmi(1);
+
+ return 0;
+err_kdb_reg:
+ tty_unregister_driver(kgdb_nmi_tty_driver);
+err_drv_reg:
+ put_tty_driver(kgdb_nmi_tty_driver);
+ return ret;
+}
+EXPORT_SYMBOL_GPL(kgdb_register_nmi_console);
+
+int kgdb_unregister_nmi_console(void)
+{
+ int ret;
+
+ kgdb_enable_nmi(0);
+ kdb_unregister("nmi_console");
+
+ ret = unregister_console(&kgdb_nmi_console);
+ if (ret)
+ return ret;
+
+ ret = tty_unregister_driver(kgdb_nmi_tty_driver);
+ if (ret)
+ return ret;
+ put_tty_driver(kgdb_nmi_tty_driver);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(kgdb_unregister_nmi_console);
diff --git a/drivers/tty/serial/kgdboc.c b/drivers/tty/serial/kgdboc.c
index 2b42a01..3f63d83 100644
--- a/drivers/tty/serial/kgdboc.c
+++ b/drivers/tty/serial/kgdboc.c
@@ -145,6 +145,8 @@ __setup("kgdboc=", kgdboc_option_setup);
static void cleanup_kgdboc(void)
{
+ if (kgdb_unregister_nmi_console())
+ return;
kgdboc_unregister_kbd();
if (configured == 1)
kgdb_unregister_io_module(&kgdboc_io_ops);
@@ -198,11 +200,18 @@ do_register:
if (err)
goto noconfig;
+ err = kgdb_register_nmi_console();
+ if (err)
+ goto nmi_con_failed;
+
configured = 1;
return 0;
+nmi_con_failed:
+ kgdb_unregister_io_module(&kgdboc_io_ops);
noconfig:
+ kgdboc_unregister_kbd();
config[0] = 0;
configured = 0;
cleanup_kgdboc();
diff --git a/include/linux/kgdb.h b/include/linux/kgdb.h
index 3b111a6..9bf888e 100644
--- a/include/linux/kgdb.h
+++ b/include/linux/kgdb.h
@@ -245,6 +245,16 @@ extern void kgdb_arch_enable_nmi(bool on);
*/
extern int kgdb_enable_nmi(bool on);
+#ifdef CONFIG_SERIAL_KGDB_NMI
+extern int kgdb_register_nmi_console(void);
+extern int kgdb_unregister_nmi_console(void);
+extern bool kgdb_nmi_poll_knock(void);
+#else
+static inline int kgdb_register_nmi_console(void) { return 0; }
+static inline int kgdb_unregister_nmi_console(void) { return 0; }
+static inline bool kgdb_nmi_poll_knock(void) { return 1; }
+#endif
+
/**
* struct kgdb_arch - Describe architecture specific values.
* @gdb_bpt_instr: The instruction to trigger a breakpoint.
--
1.7.11.5
^ permalink raw reply related
* Re: [PATCH v4 00/21] OMAP UART Patches
From: Felipe Balbi @ 2012-09-16 18:36 UTC (permalink / raw)
To: Paul Walmsley
Cc: Felipe Balbi, Shubhrajyoti Datta, Greg KH, alan, Tony Lindgren,
Kevin Hilman, Linux OMAP Mailing List,
Linux ARM Kernel Mailing List, linux-serial,
Linux Kernel Mailing List, Santosh Shilimkar, Sourav Poddar
In-Reply-To: <alpine.DEB.2.00.1209160117510.23371@utopia.booyaka.com>
[-- Attachment #1: Type: text/plain, Size: 1673 bytes --]
Hi,
On Sun, Sep 16, 2012 at 01:22:01AM +0000, Paul Walmsley wrote:
> On Wed, 12 Sep 2012, Felipe Balbi wrote:
>
> > On Tue, Sep 11, 2012 at 10:02:48PM +0000, Paul Walmsley wrote:
> >
> > > The bad news is that N800 no longer boots -- or the UART dies during
> > > serial init:
> > >
> > > http://www.pwsan.com/omap/testlogs/test_tty_next_e36851d0/20120910020323/boot/2420n800/2420n800_log.txt
> > >
> > > The problem doesn't seem to affect the 2430SDP.
> > >
> > > Could you put together a patch to fix N800?
>
> Bisected this down. It's this one that causes the problem on N800:
>
> commit 93220dcc3052182e7156c09655ad1316055564b9
> Author: Felipe Balbi <balbi@ti.com>
> Date: Thu Sep 6 15:45:27 2012 +0300
>
> serial: omap: set dev->drvdata before enabling pm_runtime
>
> by the time we call our first pm_runtme_get_sync()
> after enable pm_runtime, our resume method might
> be called. To avoid problems, we must make sure
> that our dev->drvdata is set correctly before
> our resume method gets called.
>
> Tested-by: Shubhrajyoti D <shubhrajyoti@ti.com>
> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Signed-off-by: Felipe Balbi <balbi@ti.com>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Interesting. That simply moves platform_set_drvdata() to a saner
location... The only way for this to cause problems is if we're trying
to restore a context which was never saved.
Is there a way to prevent runtime_resume() to be called during probe()
if I know the HW is already enabled ? Maybe with
pm_runtime_set_active() ?
--
balbi
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH v4 00/21] OMAP UART Patches
From: Paul Walmsley @ 2012-09-16 1:22 UTC (permalink / raw)
To: Felipe Balbi, Shubhrajyoti Datta
Cc: Greg KH, alan, Tony Lindgren, Kevin Hilman,
Linux OMAP Mailing List, Linux ARM Kernel Mailing List,
linux-serial, Linux Kernel Mailing List, Santosh Shilimkar,
Sourav Poddar
In-Reply-To: <20120912062259.GC18563@arwen.pp.htv.fi>
On Wed, 12 Sep 2012, Felipe Balbi wrote:
> On Tue, Sep 11, 2012 at 10:02:48PM +0000, Paul Walmsley wrote:
>
> > The bad news is that N800 no longer boots -- or the UART dies during
> > serial init:
> >
> > http://www.pwsan.com/omap/testlogs/test_tty_next_e36851d0/20120910020323/boot/2420n800/2420n800_log.txt
> >
> > The problem doesn't seem to affect the 2430SDP.
> >
> > Could you put together a patch to fix N800?
Bisected this down. It's this one that causes the problem on N800:
commit 93220dcc3052182e7156c09655ad1316055564b9
Author: Felipe Balbi <balbi@ti.com>
Date: Thu Sep 6 15:45:27 2012 +0300
serial: omap: set dev->drvdata before enabling pm_runtime
by the time we call our first pm_runtme_get_sync()
after enable pm_runtime, our resume method might
be called. To avoid problems, we must make sure
that our dev->drvdata is set correctly before
our resume method gets called.
Tested-by: Shubhrajyoti D <shubhrajyoti@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
- Paul
^ permalink raw reply
* Re: [PATCH 07/11] tty/serial: Add kgdb_nmi driver
From: Francesco Lavra @ 2012-09-15 15:52 UTC (permalink / raw)
To: Anton Vorontsov
Cc: Andrew Morton, Russell King, Jason Wessel, Greg Kroah-Hartman,
Alan Cox, linaro-kernel, patches, Brian Swetland, linux-kernel,
Arve Hjønnevåg, linux-serial, Colin Cross,
kgdb-bugreport, kernel-team, linux-arm-kernel
In-Reply-To: <1347548615-18227-7-git-send-email-anton.vorontsov@linaro.org>
On 09/13/2012 05:03 PM, Anton Vorontsov wrote:
...
> +static int kgdb_nmi_tty_install(struct tty_driver *drv, struct tty_struct *tty)
> +{
> + struct kgdb_nmi_tty_priv *priv;
> + int ret;
> +
> + priv = kzalloc(sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + INIT_KFIFO(priv->fifo);
> + tasklet_init(&priv->tlet, kgdb_nmi_tty_receiver, (unsigned long)priv);
> + tty_port_init(&priv->port);
> + priv->port.ops = &kgdb_nmi_tty_port_ops;
> + tty->driver_data = priv;
> +
> + ret = tty_port_install(&priv->port, drv, tty);
> + if (ret) {
> + pr_err("%s: can't nstall tty port: %d\n", __func__, ret);
s/nstall/install
...
> diff --git a/drivers/tty/serial/kgdboc.c b/drivers/tty/serial/kgdboc.c
> index 2b42a01..ed97cfd 100644
> --- a/drivers/tty/serial/kgdboc.c
> +++ b/drivers/tty/serial/kgdboc.c
> @@ -145,6 +145,8 @@ __setup("kgdboc=", kgdboc_option_setup);
>
> static void cleanup_kgdboc(void)
> {
> + if (kgdb_unregister_nmi_console())
> + return;
> kgdboc_unregister_kbd();
> if (configured == 1)
> kgdb_unregister_io_module(&kgdboc_io_ops);
> @@ -198,6 +200,10 @@ do_register:
> if (err)
> goto noconfig;
>
> + err = kgdb_register_nmi_console();
> + if (err)
> + goto noconfig;
If kgdb_register_nmi_console() fails, kgdb_unregister_io_module() must
be called for proper cleanup
--
Francesco
^ permalink raw reply
* FW: atmel_serial DBGU RX DMA
From: Thomas Walters @ 2012-09-14 18:45 UTC (permalink / raw)
To: linux-serial@vger.kernel.org
Greetings,
While working with an Atmel AT91SAM9G45 microprocessor, I have run into a problem with input overruns during typical console usage of the Debug Unit (DBGU) serial port. The port, being compatible with the standard Atmel USART, uses the Atmel serial driver (drivers/tty/serial/atmel_serial.c). The driver has the option of using DMA transfers (in fact, it does so by default on all ports except the DBGU).
Using DMA for receive with DBGU does not work on the mainline driver. I have determined that this is due to the reliance of the driver on the ATMEL_US_TIMEOUT interrupt to trigger transfers from the RX DMA buffer to the TTY buffer at regular intervals. The DBGU port hardware does not implement the receiver timeout feature.
I have been able to "force" receive DMA to work by adding a timer callback (similar to the method used by the 8250 driver with devices that do not support interrupts). This method has relieved the input overrun errors I was getting.
I am curious if this is an acceptable approach and if there are any better alternatives. I'm still looking into the effect on performance, but so far I haven't seen any significant change from the original driver.
Thanks,
Thomas Walters
Confidentiality Notice
________________________________
This message is intended exclusively for the individual or entity to which it is addressed. This communication may contain information that is PROPRIETARY, TRADE SECRET, PRIVILEGED, CONFIDENTIAL or otherwise legally exempt from disclosure.
If you are not the named addressee, you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this message in error, please notify the sender immediately either by phone (864.843.4343) or reply to this e-mail and delete all copies of this message.
________________________________
^ permalink raw reply
* [GIT PATCH] TTY fixes for 3.6-rc6
From: Greg KH @ 2012-09-13 17:45 UTC (permalink / raw)
To: Linus Torvalds, Alan Cox, Jiri Slaby
Cc: Andrew Morton, linux-kernel, linux-serial
The following changes since commit fea7a08acb13524b47711625eebea40a0ede69a0:
Linux 3.6-rc3 (2012-08-22 13:29:06 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git/ tags/tty-3.6-rc6
for you to fetch changes up to 7be0670f7b9198382938a03ff3db7f47ef6b4780:
tty: serial: imx: don't reinit clock in imx_setup_ufcr() (2012-09-05 12:44:44 -0700)
----------------------------------------------------------------
TTY fixes for 3.6-rc6
Here are 2 tiny patches for a serial driver to resolve issues that
people have reported with the 3.6-rc tree.
Both of these have been in the linux-next tree for a while now.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
----------------------------------------------------------------
Dirk Behme (1):
tty: serial: imx: don't reinit clock in imx_setup_ufcr()
Xinyu Chen (1):
tty: serial: imx: console write routing is unsafe on SMP
drivers/tty/serial/imx.c | 30 +++++++++++++++---------------
1 file changed, 15 insertions(+), 15 deletions(-)
^ permalink raw reply
* Re: [PATCH v7 0/11] KGDB/KDB FIQ (NMI) debugger
From: Anton Vorontsov @ 2012-09-13 16:55 UTC (permalink / raw)
To: Alan Cox
Cc: Andrew Morton, Russell King, Jason Wessel, Greg Kroah-Hartman,
Arve Hjønnevåg, Colin Cross, Brian Swetland,
John Stultz, Thomas Gleixner, linux-kernel, linux-arm-kernel,
linaro-kernel, patches, kernel-team, kgdb-bugreport, linux-serial
In-Reply-To: <20120913180457.1396637b@bob.linux.org.uk>
On Thu, Sep 13, 2012 at 06:04:57PM +0100, Alan Cox wrote:
> On Thu, 13 Sep 2012 08:01:33 -0700
> Anton Vorontsov <anton.vorontsov@linaro.org> wrote:
>
> > Hi all,
> >
> > Here comes the lucky v7:
> >
> > - Per Alan Cox's suggestion added hangup method and removed a small
> > leftover;
> > - Per Colin Cross' suggestion moved IRQ quiescing logic into
> > poll_get_char routine. IIUC, Alan is less unhappy about it. As a
> > result, clear_irq() callback dropped.
>
> Ok that has my ack. Some of it is not pretty but debugger hooks that
> have to run behind the OS while debugging it never are.
>
> Acked-by: Alan Cox <alan@linux.intel.com>
Great! Much thanks for reviews, Alan.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox