netdev - Re: [PATCH 6/7 v2] fs_enet: Be an of_platform device when CONFIG_PPC_CPM_NEW

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Wed, 22 Aug 2007 16:16:13 -0500
From:	Scott Wood <scottwood@...escale.com>
To:	Vitaly Bordug <vitb@...nel.crashing.org>
CC:	jgarzik@...ox.com, netdev@...r.kernel.org, linuxppc-dev@...abs.org
Subject: Re: [PATCH 6/7 v2] fs_enet: Be an of_platform device when CONFIG_PPC_CPM_NEW_BINDING
 is set.

Vitaly Bordug wrote:
> yes, wrong snippet what about
> 
> 
>> #ifdef CONFIG_CPM2 +	r = fs_enet_mdio_bb_init(); +	if (r != 0) +
>> goto out_mdio_bb; +#endif +#ifdef CONFIG_8xx +	r =
>> fs_enet_mdio_fec_init(); +	if (r != 0) +		goto out_mdio_fec; 
>> +#endif
> 
> 
> We had to pray and hope that 8xx would only have fec, and cpm2 has
> some bitbanged stuff. now we can inquire dts and know for sure, at
> least it seems so.

Yeah, that sucks.  We should add kconfig options for each mii type, and
let them have their own init functions.

That only affects the initcalls (and kernel size), though; it still uses 
the phy-handle to decide what mdio controller to actually talk to.

>> How is that different from the old code, where you're hosed without
>>  fep->fpi->bus_id?
>> 
> 
> 
> I wasn't defending old code, and consider "old code is POS, new one
> is just great" game meaningless. I am just stating the problem, that
> we'll have to address later. On 8xx even reference boards may be 
> without phy at all.

OK -- would it suffice to just never call any phylib functions and
always assume the link is up if the phy-handle property is undefined?

> ok, agreed, size is most serious judge here. we'll definitely have to
> revisit pin problem later too (because custom designs sometimes
> switch contradictory devices on-the-fly, disable soc parts for
> alternative function, etc.)

If it's really on-the-fly (and not jumpered/once-per-boot), then board 
code should expose some kind of API to switch the functions, acting like 
a hotplug bus.  Associating it with open/close of the device won't work 
if one of the devices is something like USB which needs to start working 
without any internal open()-like action.

-Scott
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html