Re: [ 019/150] serial_core: Fix type definition forPORT_BRCM_TRUMANAGE.

[Ben Hutchings]

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