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: > > 3.8-stable review patch. If anyone has any objections, please let me know. > > > > ------------------ > > > > From: Michael Chan <mchan@xxxxxxxxxxxx> > > > > commit 85f024401bf80746ae08b7fd5809a9b16accf0b1 upstream. > > > > It was mistakenly defined to be 24 instead of the next higher number 25. > > > > Reported-by: Alexander Shishkin <alexander.shishkin@xxxxxxxxxxxxxxx> > > Cc: Stephen Hurd <shurd@xxxxxxxxxxxx> > > Signed-off-by: Michael Chan <mchan@xxxxxxxxxxxx> > > Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> > > > > --- > > include/uapi/linux/serial_core.h | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > --- 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? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html