[PATCH v6 1/3] tty/serial: Add GPIOLIB helpers for controlling modem lines

Richard Genoud richard.genoud at gmail.com
Thu Apr 3 02:35:01 PDT 2014


2014-04-03 1:13 GMT+02:00 Greg Kroah-Hartman <gregkh at linuxfoundation.org>:
> On Wed, Apr 02, 2014 at 05:09:03PM +0200, Richard Genoud wrote:
>> On 18/03/2014 00:23, Greg Kroah-Hartman wrote:
>> > On Mon, Mar 10, 2014 at 05:45:49PM +0100, Richard Genoud wrote:
>> >> This patch add some helpers to control modem lines (CTS/RTS/DSR...) via
>> >> GPIO.
>> >> This will be useful for many boards which have a serial controller that
>> >> only handle CTS/RTS pins (or even just RX/TX).
>> >>
>> >> Signed-off-by: Richard Genoud <richard.genoud at gmail.com>
>> >
>> > Acked-by: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
>> >
>> > I can't take this series through my tty tree as the non-tty patches
>> > don't apply, so feel free to take them through whatever tree is needed.
>> >
>> > greg k-h
>> >
>>
>> I guess this series won't make it for 3.15, as it doesn't apply on any tree.
>> However, I'd like to know if I did something wrong, or if there's no
>> solution when a series depends on several patches that are in different
>> trees ?
>
> That's a hard problem, either wait a release cycle for everything to get
> merged properly (like should be done in time for 3.15-rc1 now) and then
> submit the code, or ask for different maintainers to either allow other
> trees to take the patches, put the patches in different trees at the
> same time, or have "topic branches" that different maintainers can pull
> from.
>
> Care to send me the patches after 3.15-rc1 is out, as there should not
> be any dependancy issues then, right?
>
> greg k-h

Ok, I'll do that.
Thanks for the explanation !

I will just send a little patch for 3.15rc1 or rc2 to prevent a DTS
ABI change in 3.16.
Something like this in Documentation/devicetree/bindings/serial/atmel-usart.txt
-rts-gpios = <&pioD 15 0>;
+rts-gpios = <&pioD 15 GPIO_ACTIVE_LOW>;
I guess it could go in AT91 tree
I'll send it soon.

Thanks !


Richard.



More information about the linux-arm-kernel mailing list