Hi Michael,
On Wed, 29 Jan 2020 at 19:16, Simon Glass <s...@chromium.org> wrote:
>
> Hi Michael,
>
> On Fri, 20 Dec 2019 at 06:29, Michael Walle <mich...@walle.cc> wrote:
> >
> > If there are aliases for an uclass, set the base for the "dynamically"
> > allocated numbers next to the highest alias.
> >
> > Please note, that this might lead to holes in the sequences, depending
> > on the device tree. For example if there is only an alias "ethernet1",
> > the next device seq number would be 2.
> >
> > In particular this fixes a problem with boards which are using ethernet
> > aliases but also might have network add-in cards like the E1000. If the
> > board is started with the add-in card and depending on the order of the
> > drivers, the E1000 might occupy the first ethernet device and mess up
> > all the hardware addresses, because the devices are now shifted by one.
> >
> > Cc: Thomas Fitzsimmons <fitz...@fitzsim.org>
> > Cc: Michal Simek <michal.si...@xilinx.com>
> > Signed-off-by: Michael Walle <mich...@walle.cc>
> > Reviewed-by: Alex Marginean <alexandru.margin...@nxp.com>
> > Tested-by: Alex Marginean <alexandru.margin...@nxp.com>
> > Acked-by: Vladimir Oltean <olte...@gmail.com>
> > ---
> >
> > As a side effect, this should also make the following commits
> > superfluous:
> > - 7f3289bf6d ("dm: device: Request next sequence number")
> > - 61607225d1 ("i2c: Fill req_seq in i2c_post_bind()")
> > Although I don't understand the root cause of the said problem.
> >
> > Thomas, Michal, could you please test this and then I'd add a second
> > patch removing the old code.
>
> I think this is reasonable. We have discussed a possible rework of the
> logic to merge seq and req_seq, but I don't think we have any patches
> yet.
>
> Please can you add a test to your patch? You can put it in test-fdt.c
> for example.
>
> If you are reverting the other patches, could you please send patches for
> those?
One more thing...this actually breaks existing tests so please fix those also.
Thanks,
SImon
