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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Thu, 8 Mar 2012 16:06:22 -0800
From:	Tony Lindgren <tony@...mide.com>
To:	Kevin Hilman <khilman@...com>
Cc:	Russ Dill <Russ.Dill@...com>, balbi@...com,
	Matt Porter <mporter@...com>,
	Russell King <linux@....linux.org.uk>,
	Linux OMAP List <linux-omap@...r.kernel.org>,
	Linux ARM Kernel List <linux-arm-kernel@...ts.infradead.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3] ARM: OMAP2+: gpmc-smsc911x: add required smsc911x
 regulators

* Kevin Hilman <khilman@...com> [120308 12:54]:
> Tony Lindgren <tony@...mide.com> writes:
> 
> > * Kevin Hilman <khilman@...com> [120307 11:05]:
> >> >
> >> > I don't think the second smsc911x on the Overo, "smsc911x.1", would
> >> > find it due to the dev_id.
> >> 
> >> It's not about finding the second regulator.  As stated in the
> >> changelog, it's about the duplicate attempt to register the exact same
> >> platform_device.
> >> 
> >> Duplicate attempts to register the exact same platform_device cause
> >> kobject to panic and give up[1].  So, any platform that calls
> >> gpmc_smsc911x_init() twice (Overo and T35 in mainline) will panic on
> >> boot.
> >> 
> >> This patch fixes those platforms so they can boot.
> >
> > Yeah but I guess the second smsc911x instance still would not work,
> > or am I missing something?
> 
> I don't know since my Overo expansion boards don't have a 2nd NIC, but I
> suspect you're right.
> 
> However, my fix isn't addressing that.  I am fixing a problem where
> mainline today will panic on some boards due to duplicate registration.
> 
> If the 2nd interface doesn't work, then the original patch that added
> the regulators needs a rethink.  My patch to prevent the panic() is
> needed for mainline.

With Kevin's second version of this patch applied we avoid the panic
on boards with more than one smsc911x.

After this patch, board-*.c files can add custom regulators for their
other smsc911x instances.

We should also add a regulator to the struct omap_smsc911x_platform_data,
and then only initialize the fixed regulator automatically
if (!board_data->regulator && !board_data->id).

So I've pushed Kevin's second version of the fix to fix-smsc911x-regulator
branch.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ