[PATCH v6] net: sh_eth: Add support of device tree probe

[Nobuhiro Iwamatsu]

Hi,

(2013/04/15 5:06), Sergei Shtylyov wrote:
> Hello.
>
> On 21-03-2013 11:03, Nobuhiro Iwamatsu wrote:
>
> Sorry, I have noticed your reply only last Friday. I probably should do something with my mail filters, so that they leave the personal mail in my inbox and not toss it to the list folders where I may ignore it...
>
>>>> This adds support of device tree probe for Renesas sh-ether driver.
>
>>>> Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj at renesas.com>
>
>>>> V6: - Add renesas,sh-eth-gigabit, renesas,sh-eth-sh4 and
>>>> renesas,sh-eth-sh3-sh2 to compatible string.
>>>> - Remove sh-eth,register-type. This is supplemented by the
>>>> compatible string.
>>>> - Use the of_property_read_bool instead of of_find_property.
>>>> - Add sanity chheck for of_property_read_u32.
>>>> - Update document.
>>>> V5: - Rewrite sh_eth_parse_dt().
>>>> Remove of_device_is_available() and CONFIG_OF from support OF
>>>> checking function and re-add empty sh_eth_parse_dt().
>>>> - Add CONFIG_PM to definition of dev_pm_ops.
>>>> - Add CONFIG_OF to definition of of_device_id.
>>>> V4: - Remove empty sh_eth_parse_dt().
>>>> V3: - Remove empty sh_eth_parse_dt().
>>>> V3: - Removed sentnece of "needs-init" from document.
>>>> V2: - Removed ether_setup().
>>>> - Fixed typo from "sh-etn" to "sh-eth".
>>>> - Removed "needs-init" and sh-eth,endian from definition of DT.
>>>> - Changed "sh-eth,edmac-endian" instead of "sh-eth,edmac-big-endain"
>>>> in definition of DT.
>>>> ---
> [...]
>
>>>> @@ -2391,12 +2451,33 @@ static int sh_eth_drv_probe(struct platform_device
>>>> *pdev)
>>>> goto out_release;
>>>> }
>>>>
>>>> + if (np) {
>>>> + pd = sh_eth_parse_dt(&pdev->dev, ndev, np);
>>>> + if (pdev->dev.platform_data && pd) {
>>>> + struct sh_eth_plat_data *tmp =
>>>> + pdev->dev.platform_data;
>>>> + pd->set_mdio_gate = tmp->set_mdio_gate;
>>>> + pd->needs_init = tmp->needs_init;
>
>>> OK, so we can't fully convert this driver to the device tree due to
>>> procedural platform data.
>
>> > I then would advice just using OF_DEV_AUXDATA() in the platform data
>
> /sdata/code/.
>
>> instead of trying to convert the driver to device tree.
>
> Convert the platfrom data, I meant. But I already wrote about that I think.
>
>> Yes, I knew about this.
>
> But still attempted to document and use the data-only device tree properties (which was pointless in the light of procediral platfrom data)?
>

Yes, I added this information to next patch.

>>>> +
>>>> +#ifdef CONFIG_OF
>>>> +static const struct of_device_id sh_eth_match[] = {
>>>> + { .compatible = "renesas,sh-eth-gigabit", },
>>>> + { .compatible = "renesas,sh-eth-sh4", },
>>>> + { .compatible = "renesas,sh-eth-sh3-sh2", },
>
>>> Biut this is not really enough: the driver supports much more variations of
>>> the SH and ARM SoCs
>>> all of which have difference not only in register layout but also in the
>>> registers bits or even
>>> presence of the whole register blocks. All this IMO should be reflected in
>>> the different values
>>> of the compatible "property". BTW, it seems another register layout and
>>> instance needs to be added
>>> for the R-Car SoCs (instead of the current ugly hack).
>
> I've already added it now, it's in the 'net-next' tree.
>

Yes, I know. Thank you for this work.

>> I see.
>> Latest source code was defined compatible as renesas,sh-eth-gigabit,
>> sh-eth-sh4 and sh-eth-sh3-sh2. I will change ito renesas,<CPU>-sh-eth.
>
> Yes, this is the step in the right direction. Though I'd drop the '-sh' infix -- the driver is usable not only on SH platforms.
>

OK, I will drop "-sh" from SH platform too.

>> And I think that we should define the sh7757-sh-eth-gitabit and
>> sh7757-sh-eth-fast for this. Becauase sh7757 is special device.
>> There is a device that supports only devices that support fast
>> ether and gigabit ether on single CPU.
>
> Yes, I saw that.
>
>> Therefore, the compatible property of this device becomes <CPU>-sh-eth
>> or <CPU>-sh-eth-<ETHER TYPE>.
>
>> How about this?
>
> Sounds better. I think however that the conversion of this driver to device tree shouldn't be done without getting rid of the current #ifdef mess in it (which is still on my agenda). I think that the 'register_type' field should move from the platform data to the 'struct sh_eth_cpu_data' in the process.
>

I see. this problem will fix next step, I think.

> WBR, Sergei
>
>

Best regards,
   Nobuhiro