On Wed, 2013-02-27 at 16:39 -0800, Greg Kroah-Hartman wrote:
> On Thu, Feb 28, 2013 at 12:05:59AM +0000, Ben Hutchings wrote:
> > On Tue, 2013-02-26 at 15:54 -0800, Greg Kroah-Hartman wrote:
[...]
> > > --- a/include/uapi/linux/serial_core.h
> > > +++ b/include/uapi/linux/serial_core.h
> > > @@ -50,7 +50,7 @@
> > > #define PORT_LPC3220 22 /* NXP LPC32xx SoC "Standard" UART */
> > > #define PORT_8250_CIR 23 /* CIR infrared port, has its own driver */
> > > #define PORT_XR17V35X 24 /* Exar XR17V35x UARTs */
> > > -#define PORT_BRCM_TRUMANAGE 24
> > > +#define PORT_BRCM_TRUMANAGE 25
> > > #define PORT_MAX_8250 25 /* max port ID */
> > >
> > > /*
> >
> > Hang on, this is a uapi header - are these numbers actually used by
> > userland or are they really internal to the 8250 drivers?
>
> Interesting, I think they are internal to the 8250 drivers, as I don't
> see how the number can be exported to userspace. So they should
> probably be moved into 8250.c somewhere.
>
> But I could be wrong, this code is so old it's scary, hopefully no one
> really is using this number in userspace.
>
> Only one way to find out, care to make up a patch for me to apply and
> queue up for 3.10?
It looks like they appear in serial_struct::type when the
TIOC{G,S}SERIAL ioctls are used. Some of the values are also defined in
<linux/serial.h>, which is fine as long as the definitions are
token-wise identical.
For backported versions I had better not renumber them... oops, I'll go
and fix that now. (Only reason I did so was because it looked like 8250
wouldn't cope with discontiguous numbering.)
Ben.
--
Ben Hutchings
Time is nature's way of making sure that everything doesn't happen at once.
Attachment:
signature.asc
Description: This is a digitally signed message part