On 09/06/2012 09:41 PM, Tomas Hlavacek wrote: >> * why are you passing tty_port to the struct device's private data and >> not uart_port proper? Is this for some future use? > > I actually used the uart_port structure in older RFC versions of the > patch. Alan Cox advised to use struct tty_port because of consistency. > More precisely he said (in an e-mail from Aug 12): > > I'd rather however it pointed > to the tty_port that each tty device has (or very soon will be required > to have). Yes, this is already a requirement in tty-next. And every driver has to provide us with the tty_port as you might persuaded yourself of that already ;). > You can still find the uart_foo structs from that but it means > we can do the dev_set_drvdata() in a consistent manner for all tty > devices in the kernel. That in turn means we can make some of the sysfs > valid the same way. Ah, OK, makes sense. >> * cannot be all those attribute structs const? > > It seems that making > > static const struct attribute *tty_dev_attrs[] = ... > > produces warning: > > drivers/tty/serial/serial_core.c:2334:2: warning: initialization from > incompatible pointer type [enabled by default] > drivers/tty/serial/serial_core.c:2334:2: warning: (near initialization > for ‘tty_dev_attr_group.attrs’) [enabled by default] > > But others can. I am going to make them const in following patch. Ok, it was only a suggestion. I did not know either. regards, -- js suse labs -- 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
