On 9/16/20 3:56 PM, Peng Fan wrote:
> Hi Marek,
Hi,
>> Subject: Re: [PATCH 13/13] usb: ehci-mx6: Improve the bind function
>>
>> On 9/16/20 2:57 PM, peng....@nxp.com wrote:
>> [...]
>>> +++ b/drivers/usb/host/ehci-mx6.c
>>> @@ -735,13 +735,16 @@ static int ehci_usb_bind(struct udevice *dev)
>>> * the driver is fully converted to DT probing.
>>> */
>>> u32 controller_spacing;
>>> - if (IS_ENABLED(CONFIG_MX6))
>>> - controller_spacing = 0x200;
>>> - else
>>> - controller_spacing = 0x10000;
>>> - fdt_addr_t addr = devfdt_get_addr_index(dev, 0);
>>>
>>> - dev->req_seq = (addr - USB_BASE_ADDR) / controller_spacing;
>>> + if (dev->req_seq == -1) {
>>> + if (IS_ENABLED(CONFIG_MX6))
>>> + controller_spacing = 0x200;
>>> + else
>>> + controller_spacing = 0x10000;
>>> + fdt_addr_t addr = devfdt_get_addr_index(dev, 0);
>>
>> Can we get rid of the whole req_seq stuff ?
>
> Could the restructure be done after the patchset? Or you need NXP
> to restructure the driver, then upstream NXP production ready
> patches?
>
> If restructure first, there will be lots conflicts when I pick downstream
> patches, and error prone.
Can you prepare an RFC patchset for the restructuring on top of this
one, so you can bisect breakage caused by the restructuring, and post
those patches ? Then you will get your production-ready patches in
without much changes and also there will be the long-overdue cleanup on
the ML.
I really want NXP to do the cleanup, because the driver is becoming real
bad and it is piling up a lot of unrelated code in it. I don't care
about the order in which the patches go in though.
Does that work ?
