On Sat, 2016-06-25 at 13:49 -0700, Greg Kroah-Hartman wrote:
> On Mon, May 23, 2016 at 04:44:01PM +0300, Andy Shevchenko wrote:
> >
> > The commit 3f960dbb9dfe ("Serial: Avoid unbalanced IRQ wake disable
> > during
> > resume") adds a new unsigned char field to the struct uart_port. At
> > the same
> > time we have to reduce amount of bytes in unused array, which wasn't
> > done.
>
> Why do we "have to" do this?
Wrong wording. Of course we don't, but wasn't that the initial idea,
looking to the patches that replaced other unused fields?
> Hence the change hits an alignment of the struct and breaks 4 bytes
> > boundary.
>
> Shouldn't the structure just be padded then?
> Is this some micro optimization that is being attempted here? Why not
> just drop the "unused" variable completely?
We may leave this as is. It's indeed a micro optimization.
>
> >
> > Do remove one unused byte in the struct uart_port.
>
> I don't understand this line.
Sorry, I meant that we reduce unused2 array from 2 bytes to 1.
>
> >
> > Signed-off-by: Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx>
> > ---
> > include/linux/serial_core.h | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/include/linux/serial_core.h
> > b/include/linux/serial_core.h
> > index e9811c4..38f6f81 100644
> > --- a/include/linux/serial_core.h
> > +++ b/include/linux/serial_core.h
> > @@ -248,7 +248,7 @@ struct uart_port {
> > unsigned char hub6; /
> > * this should be in the 8250 driver */
> > unsigned char suspended;
> > unsigned char irq_wake;
> > - unsigned char unused[2];
> > + unsigned char unused2;
> > struct attribute_group *attr_group; /
> > * port specific attributes */
> > const struct attribute_group **tty_groups; /* all
> > attributes (serial core use only) */
> > struct serial_rs485 rs485;
> > --
> > 2.8.1
>
> as-is, I can't take this, sorry.
No problem.
--
Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx>
Intel Finland Oy
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
