[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAEo2pzs7mTUFpUGvsyrzt5cYPXsWLiBLaoQ==SypBm5fKjkFjA@mail.gmail.com>
Date: Thu, 11 Feb 2016 23:19:52 +0300
From: Ильяс Гасанов
<torso.nafi@...il.com>
To: "Matwey V. Kornilov" <matwey@....msu.ru>
Cc: Greg KH <gregkh@...uxfoundation.org>, Jiri Slaby <jslaby@...e.com>,
Peter Hurley <peter@...leysoftware.com>,
Andy Shevchenko <andy.shevchenko@...il.com>,
One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
linux-kernel <linux-kernel@...r.kernel.org>,
linux-serial@...r.kernel.org
Subject: Re: [PATCH v8 3/3] tty: 8250_omap: Use software emulated RS485
direction control
2016-02-11 22:08 GMT+03:00 Matwey V. Kornilov <matwey@....msu.ru>:
> Thanks for pointing out. serial8250_unregister_port should set
> serial8250_ports[line].em485 to NULL in order to prevent unneeded
> activation when this struct is reused.
Then the allocated/initialized resources should be freed/released as well.
> You would be able to use serial8250_em485_register in omap8250_probe
> on &up before serial8250_register_8250_port(&up) if
> serial8250_register_8250_port could replicate em485 member state.
> But there are alternatives in implementation.
I'm considering adding the relevant code to the omap8250_startup and
omap8250_shutdown callback functions. However the serial driver
documentation claims that these don't have port->lock taken when
invoked, only port_sem.
> serial8250_register_8250_port may either copy pointer up->em485 to
> uart->em485 or perform deep copy.
Actually, "up" here in omap8250_probe is not a pointer but a struct
variable on stack, so copying the pointer to it is out of question.
Regards,
Ilyas G.
Powered by blists - more mailing lists