Hello, On Fri, May 31, 2019 at 06:23:48PM +0300, Sergey Organov wrote: > Uwe Kleine-König <u.kleine-koenig@xxxxxxxxxxxxxx> writes: > > > Hello Sergey, > > > > On Fri, May 31, 2019 at 09:17:02AM +0300, Sergey Organov wrote: > >> Uwe Kleine-König <u.kleine-koenig@xxxxxxxxxxxxxx> writes: > >> > >> > On Fri, May 31, 2019 at 07:52:51AM +0300, Sergey Organov wrote: > >> >> My best reasoning was that DSR/ DTR is likely implemented the same as > >> >> CTS/ RTS in the metal, and I found other drivers where both RTS and DSR > >> >> are inverted, so I guessed it could be a remnant of old copy-paste. > >> > > >> > This is not a good enough reason to "fix" that. > >> > >> Yeah, I agree. I rather mostly kept it in the series not to forget about > >> the issue. I should have said that in the comments, sorry. > > > > Then also sort this to the end of the series to allow clean application > > of the patches you are sure about and mark the questionable patches as > > RFC or RFT. > > I'm not sure we shouldn't actually fix it. Can we get help from NXP for > clarification on the issue? I'm still 90% sure it's a bug. When the DTR bit is set the (TTL) output is one as the following command sequence on an i.MX25 proves: # set SION bit for MX25_PAD_KPP_ROW0 and mux to UART1_DTR bootloader: mw 0x43fac1a8 0x00000014 # configure GPIO2.29 as input bootloader: gpio_direction_input 61 bootloader: md 0x43f90088+4 43f90088: 00000784 .... # DTR is set ... bootloader: gpio_get_value 61; echo $? 1 # and the output is high # after unsetting DTR ... bootloader: mw 0x43f90088 0x384 bootloader: gpio_get_value 61; echo $? 0 # ... the output is low. Together with TTL-level 0 meaning "active" the driver is right as is. (Well, I'm not entirely sure about 0 == "active", so this is the point you should target when continuing to argue :-) > The rest of the series should apply clearly independent on this one, but > I'll re-check anyway. As author you should make life easy for reviewers and maintainers to understand and apply respectively. To achieve this it's better to sort patches you are unsure about to the end and mark them accordingly. Even in cases where the patches apply irrespective of their order. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ |
