abx80x: RV-1805 initialization order correct?

abx80x: RV-1805 initialization order correct?

[Kevin P. Fleming]

The driver has a block of RV-1805-specific code (under the comment
'Configure RV1805 specifics'), which is executed before the part
autodetection code (under the comment 'part autodetection').

If the driver is loaded with the 'generic' device data for abx80x, and
the actual part in use is an RV-1805, the part-specific code won't be
executed. I'm using this driver in a dynamic Device Tree environment,
and at the moment I can't specify the part as the driver is loaded
(although I could modify the overlay to support that if required).

So the question is: does the RV-1805 specific code *have* to be
executed before part autodetection in order to avoid the lockup
situation mentioned in the comments, or could it be moved immediately
after the autodetection so that it will be always be executed for an
RV-1805 part?

Re: abx80x: RV-1805 initialization order correct?

[Alexandre Belloni]

Hi,

On 29/05/2020 07:13:00-0400, Kevin P. Fleming wrote:
> The driver has a block of RV-1805-specific code (under the comment
> 'Configure RV1805 specifics'), which is executed before the part
> autodetection code (under the comment 'part autodetection').
> 
> If the driver is loaded with the 'generic' device data for abx80x, and
> the actual part in use is an RV-1805, the part-specific code won't be
> executed. I'm using this driver in a dynamic Device Tree environment,
> and at the moment I can't specify the part as the driver is loaded
> (although I could modify the overlay to support that if required).
> 
> So the question is: does the RV-1805 specific code *have* to be
> executed before part autodetection in order to avoid the lockup
> situation mentioned in the comments, or could it be moved immediately
> after the autodetection so that it will be always be executed for an
> RV-1805 part?

You can't detect the difference between the rv1805 and the ab1805 with
the id registers as both have 0x1805 so you will always have to use the
correct compatible string for it. The position of the code doesn't
matter.

Basically, the autodetection should never be used as the device tree
must describe the actual hardware. My point of view is that this was a
mistake to have it in the driver in the first place.

-- 
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: abx80x: RV-1805 initialization order correct?

[Kevin P. Fleming]

OK, thanks, I'll update my system to explicitly indicate that the
rv1805 is being used in the device tree.

On Sat, May 30, 2020 at 4:25 PM Alexandre Belloni
<alexandre.belloni@bootlin.com> wrote:
>
> Hi,
>
> On 29/05/2020 07:13:00-0400, Kevin P. Fleming wrote:
> > The driver has a block of RV-1805-specific code (under the comment
> > 'Configure RV1805 specifics'), which is executed before the part
> > autodetection code (under the comment 'part autodetection').
> >
> > If the driver is loaded with the 'generic' device data for abx80x, and
> > the actual part in use is an RV-1805, the part-specific code won't be
> > executed. I'm using this driver in a dynamic Device Tree environment,
> > and at the moment I can't specify the part as the driver is loaded
> > (although I could modify the overlay to support that if required).
> >
> > So the question is: does the RV-1805 specific code *have* to be
> > executed before part autodetection in order to avoid the lockup
> > situation mentioned in the comments, or could it be moved immediately
> > after the autodetection so that it will be always be executed for an
> > RV-1805 part?
>
> You can't detect the difference between the rv1805 and the ab1805 with
> the id registers as both have 0x1805 so you will always have to use the
> correct compatible string for it. The position of the code doesn't
> matter.
>
> Basically, the autodetection should never be used as the device tree
> must describe the actual hardware. My point of view is that this was a
> mistake to have it in the driver in the first place.
>
> --
> Alexandre Belloni, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com