> -----Original Message----- > From: Jiri Slaby [mailto:jirislaby@xxxxxxxxx] > Sent: Thursday, October 07, 2010 2:59 AM > To: Savoy, Pavan > Cc: gregkh@xxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; devel@xxxxxxxxxxxxxxxxxxxx; > alan@xxxxxxxxxxxxxxxxxxx > Subject: Re: [PATCH 1/2] drivers:staging:ti-st: move TI_ST from staging > > On 10/07/2010 12:36 AM, Savoy, Pavan wrote: > >>>>> +int st_core_init(struct st_data_s **core_data) > >>>>> +{ > >>>>> + struct st_data_s *st_gdata; > >>>>> + long err; > >>>>> + static struct tty_ldisc_ops *st_ldisc_ops; > >>>>> + > >>>>> + /* populate and register to TTY line discipline */ > >>>>> + st_ldisc_ops = kzalloc(sizeof(*st_ldisc_ops), GFP_KERNEL); > >>>>> + if (!st_ldisc_ops) { > >>>>> + pr_err("no mem to allocate"); > >>>>> + return -ENOMEM; > >>>>> + } > >>>> This can be static structure, you don't need to allocate this on heap. > >>>> It should be a singleton. > >>> > >>> Yes, I got this comment before, but is it just a style issue? > >>> I want to keep this in heap because some day, I hope TTY ldics have their > >> own > >>> private_data, which I can pass around like the tty_struct's data. > >>> and having them in heap, I plan to keep a reference to ops structure, so > >> that I > >>> can pass around and use ops->private_data everywhere .. > >> > >> I doubt ldisc ops will ever have ->private_data. What would you need it > >> for? The ops generally work with ttys which have ->disc_data. > > > > Yes, But in this case, I required something which can be set during > ldisc_register, and can be picked up during tty_open. > > Why? ldiscs are per-system, singletons, not per-device. So you should > not bind to them any device specific info. Per-system? I don't understand this. There can be ldisc for each individual TTY, so doesn't that make it per device? Or to be even more specific, it makes it per-TTY which is mapped to a particular device, UART/a-set of usb-endpoints etc... This driver in fact does just that, it is a driver which allows sharing of the TTY by many other drivers (I call it the protocol drivers). > -- > js _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
