Re: 8250.c::autoconfig() fails loopback test on MPC824[15]

So, like, the other day Arnd Bergmann mumbled:

On Sunday 05 August 2007, Guennadi Liakhovetski wrote:

quoted

That would be a possibility, but that would mean all 8241/8245 have to 
adjust their .dts. Ok, there are not so many of them in the mainline now 
(in fact, hardly any apart from linkstation:-)), still. Cannot we use 

Heck, I'm slowly working on the StorCenter too.. :-)

I supect it will have the same issue in the end, right?

jdl

On Sun, 5 Aug 2007, Jon Loeliger wrote:

So, like, the other day Arnd Bergmann mumbled:

quoted

On Sunday 05 August 2007, Guennadi Liakhovetski wrote:

quoted

That would be a possibility, but that would mean all 8241/8245 have to 
adjust their .dts. Ok, there are not so many of them in the mainline now 
(in fact, hardly any apart from linkstation:-)), still. Cannot we use 

Heck, I'm slowly working on the StorCenter too.. :-)

I supect it will have the same issue in the end, right?

...if you choose to use of_serial.c, yes, if you don't use it and just use 
legacy_serial.c, then you're fine.

BTW, my offer still holds to see if we can build a single kernel for both 
with just specific device-trees, but that's a separate matter:-)

Thanks
Guennadi
---
Guennadi Liakhovetski

On Sunday 05 August 2007, Guennadi Liakhovetski wrote:

quoted

I supect it will have the same issue in the end, right?

...if you choose to use of_serial.c, yes, if you don't use it and just use 
legacy_serial.c, then you're fine.

But of_serial can be a loadable module, which means you still get into
trouble if you load it, even if the port was originally initialized
by legacy_serial.

Maybe the best solution would be for 824[15] to not claim compatibility
with 8250 at all then. If the device tree contains an entry that matches
what the generic driver looks for, it better be something that can
be handled by that driver.

	Arnd <><

Maybe the best solution would be for 824[15] to not claim compatibility
with 8250 at all then.

Or at least it should have a more specific entry for this
"special" 16x50 UART, and that one should be probed first.

If the device tree contains an entry that matches
what the generic driver looks for, it better be something that can
be handled by that driver.

Pretty much; you can't make this rule too strict though,
if a device mostly works with the generic driver, you can
claim compatibility with it -- keep in mind that that can
come back to bite you though, like in this case.  The
advantages do outweigh the disadvantages sometimes, it's
all a tradeoff; avoid it if possible.


Segher

On Mon, 6 Aug 2007, Segher Boessenkool wrote:

quoted

Maybe the best solution would be for 824[15] to not claim compatibility
with 8250 at all then.

Or at least it should have a more specific entry for this
"special" 16x50 UART, and that one should be probed first.

quoted

If the device tree contains an entry that matches
what the generic driver looks for, it better be something that can
be handled by that driver.

Pretty much; you can't make this rule too strict though,
if a device mostly works with the generic driver, you can
claim compatibility with it -- keep in mind that that can
come back to bite you though, like in this case.  The
advantages do outweigh the disadvantages sometimes, it's
all a tradeoff; avoid it if possible.

Well, the 8250 driver DOES already support devices without the loopback 
test support, that's what that bit there is for, isn't it? So, we just 
have to use it, as well as others do (grep -r UPF_SKIP_TEST 
drivers/serial/). I'll go for the extra compatible property, as suggested, 
seems like the most commonly accepted wa to handle this (and the easiest 
to implement).

Thanks
Guennadi
---
Guennadi Liakhovetski