Hello Alan
After almost one month with no other comments I am planning to resend
the patchset including the lock patch. May I add your Reviewed or
Acked by to any of the patches?
Thanks :)
On Thu, Oct 9, 2014 at 4:16 PM, Alan Cox wrote:
> On Thu, 2014-10-09 at 10:07 +0200, Ricardo Ribalda
Hello Alan
After almost one month with no other comments I am planning to resend
the patchset including the lock patch. May I add your Reviewed or
Acked by to any of the patches?
Thanks :)
On Thu, Oct 9, 2014 at 4:16 PM, Alan Cox a...@linux.intel.com wrote:
On Thu, 2014-10-09 at 10:07 +0200,
On Thu, 2014-10-09 at 10:07 +0200, Ricardo Ribalda Delgado wrote:
> Hello Alan
>
> >
> > What is the locking between setting/getting/driver use of the config ?
> > This really needs a lock (termios sem I think is perhaps appropriate
> > given when the values are normally referenced).
>
> I tried
Hello Alan
>
> What is the locking between setting/getting/driver use of the config ?
> This really needs a lock (termios sem I think is perhaps appropriate
> given when the values are normally referenced).
I tried implementing it with the sermios sem
Hello Alan
What is the locking between setting/getting/driver use of the config ?
This really needs a lock (termios sem I think is perhaps appropriate
given when the values are normally referenced).
I tried implementing it with the sermios sem
(((uart_port)-state-port.tty-termios_rwsem)),
On Thu, 2014-10-09 at 10:07 +0200, Ricardo Ribalda Delgado wrote:
Hello Alan
What is the locking between setting/getting/driver use of the config ?
This really needs a lock (termios sem I think is perhaps appropriate
given when the values are normally referenced).
I tried
On Wed, 2014-10-08 at 22:43 +0200, Ricardo Ribalda Delgado wrote:
> Hello Alan
>
> This patchset adds no extra locking features, if the drivers did not
> implement a locking mechanism (and none did) there is chance of
> conflict.
>
> I can add a call to lock/unlock around
Hello Alan
This patchset adds no extra locking features, if the drivers did not
implement a locking mechanism (and none did) there is chance of
conflict.
I can add a call to lock/unlock around uart_[gs]et_rs485_config. And
then, inside the drivers, use the lock when the structure is used.
I
On Wed, 2014-10-08 at 21:57 +0200, Ricardo Ribalda Delgado wrote:
> The following drivers: 8250_core, atmel_serial, max310x, mcf, omap-serial
> and sci16is7xx implement code to handle RS485 ioctls.
>
> +static int uart_get_rs485_config(struct uart_port *port,
> + struct
The following drivers: 8250_core, atmel_serial, max310x, mcf, omap-serial
and sci16is7xx implement code to handle RS485 ioctls.
In order to avoid code duplication, we implement a simple ioctl handler
on the serial_core layer.
This handler can be used by all the other drivers instead of
The following drivers: 8250_core, atmel_serial, max310x, mcf, omap-serial
and sci16is7xx implement code to handle RS485 ioctls.
In order to avoid code duplication, we implement a simple ioctl handler
on the serial_core layer.
This handler can be used by all the other drivers instead of
On Wed, 2014-10-08 at 21:57 +0200, Ricardo Ribalda Delgado wrote:
The following drivers: 8250_core, atmel_serial, max310x, mcf, omap-serial
and sci16is7xx implement code to handle RS485 ioctls.
+static int uart_get_rs485_config(struct uart_port *port,
+ struct
Hello Alan
This patchset adds no extra locking features, if the drivers did not
implement a locking mechanism (and none did) there is chance of
conflict.
I can add a call to lock/unlock around uart_[gs]et_rs485_config. And
then, inside the drivers, use the lock when the structure is used.
I
On Wed, 2014-10-08 at 22:43 +0200, Ricardo Ribalda Delgado wrote:
Hello Alan
This patchset adds no extra locking features, if the drivers did not
implement a locking mechanism (and none did) there is chance of
conflict.
I can add a call to lock/unlock around uart_[gs]et_rs485_config. And
14 matches
Mail list logo
