Re: [PATCH] tty: serial: msm_serial: Use DT aliases

[Kevin Hilman]

Stephen Boyd <sboyd@xxxxxxxxxxxxxx> writes:

> On 11/13/2014 04:46 PM, Frank Rowand wrote:
>> On 11/13/2014 11:31 AM, Stephen Boyd wrote:
>>> Sorry, I'm sort of lost. If there are serial aliases in the dts file,
>>> then we should alias all of the serial ports. If there aren't aliases
>>> then we're backwards compatible with the dts we have now and we'll do
>>> dynamic generation. Putting code into the driver to validate that
>>> this is true is not the job of the driver. If anything, it should
>>> validated when the dts file is created. If one day we screw up and
>>> have a dts file with such a bad configuration we'll have to work
>>> around it, but until that day comes I'd rather not think about it. 
>> Maybe I did not understand when you said "Perhaps we should use an ida".
>> That sentence led me to think the driver should check for misconfiguration.
>> The case I was trying to handle was if there was at least one serialN
>> alias and at least one UART without an alias.  For example, if there
>> are three UARTs (serial_a, serial_b, serial_c, probed in that order)
>> and one alias (serial0 = &serial_c;) then the result would be:
>>
>>    serial_a  line 0 (from msm_uart_next_id)
>>    serial_b  line 1 (from msm_uart_next_id)
>>    serial_c  line 0 (from the alias)
>>
>>    Two UARTs probed with line == 0.  This is an error.
>>
>> Most of the serial drivers don't check for this type of bad configuration.
>> Some drivers keep a bit map of which lines have been used.  I'm not sure
>> what they do in case of a conflict (I did not read to that level of detail).
>>
>> I thought you were suggesting the driver check for the bad configuration,
>> so I was proposing a somewhat simple way of forcing a boot error for the
>> bad configuration.
>>
>> Since you are not suggesting the driver check for the bad configuration,
>> you can ignore my proposal.  I agree that it is ok for the driver to
>> expect the board dts to be correct.  The problem should be detected by
>> the dts author on first boot as part of normal bring up testing, and
>> then corrected.
>>
>
> Ah ok. I was just saying we could use an ida instead of an atomic
> increment so that this driver works properly with driver
> binding/unbinding, otherwise the line number keeps increasing and
> quickly goes beyond the static array of ports (which I still don't
> understand why we have at all btw).

Due to the length of the thread, I haven't followed all the details, and
I suspect Greg hasn't either, so I'm not sure if you're discssuing what
the right fix is for what's in -next (still broken[1], or what should be done
with the device board files.

If the fix from earlier in this thread is still the right one for fixing
-next, could you repost it separately for Greg to queue/squash and for
me to re-test (if needed.)

Thanks,

Kevin

[1] http://lists.linaro.org/pipermail/kernel-build-reports/2014-November/006298.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/