Stephen Boyd [off-list ref] writes:

On 11/13/2014 04:46 PM, Frank Rowand wrote:

quoted

On 11/13/2014 11:31 AM, Stephen Boyd wrote:

quoted

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