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] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160115160219.GB3904@atomide.com>
Date:	Fri, 15 Jan 2016 08:02:19 -0800
From:	Tony Lindgren <tony@...mide.com>
To:	Russell King - ARM Linux <linux@....linux.org.uk>
Cc:	Sebastian Reichel <sre@...nel.org>,
	Kishon Vijay Abraham I <kishon@...com>,
	Ulf Hansson <ulf.hansson@...aro.org>,
	ivo.g.dimitrov.75@...il.com, aaro.koskinen@....fi, nsekhar@...com,
	khilman@...nel.org, linux-mmc@...r.kernel.org,
	linux-kernel@...r.kernel.org, NeilBrown <neilb@...e.de>,
	pavel@....cz, pali.rohar@...il.com, linux-omap@...r.kernel.org,
	patrikbachan@...il.com, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH] mmc: host: omap_hsmmc: add a verbose print to enable
 CONFIG_REGULATOR_PBIAS

* Russell King - ARM Linux <linux@....linux.org.uk> [160115 01:15]:
> On Thu, Jan 14, 2016 at 11:40:25PM +0100, Sebastian Reichel wrote:
> > On Thu, Jan 14, 2016 at 05:25:49PM +0000, Russell King - ARM Linux wrote:
> > > There are very good reasons not to do this: that will result in
> > > configurations where MMC_OMAP_HS was set but without REGULATOR_PBIAS
> > > ending up with MMC_OMAP_HS being disabled.  That doesn't help the
> > > root problem, which is "why has the kernel boot regressed for my
> > > previous working configuration?"
> > > 
> > > The solution proposed here adds a message to the boot which points
> > > out fair and square what needs to be done to rectify the boot
> > > failure.  Adding a dependency just brings up the question "where
> > > has my MMC driver gone?"
> > 
> > The best thing would be to have no regression. Just printing a
> > message means I have to build another kernel. But more importantly
> > the message may not be visible by the user - e.g. if the display has
> > not yet been initialized.
> 
> I agree in principle, but that's not possible here (see Tony's mails
> on why the PBIAS stuff needs to be optional.)  I'd agree with changing
> the Kconfig if PBIAS were a hard and fast requirement, but it isn't.

Yeah. Probably the best solution for cases like this is to boot with
a small initrd. That way you can get usb console and networking going
before mounting the real root and you will see kernel messages with
only minimal things built in. You can build a small initramfs with
CONFIG_INITRAMFS_SOURCE that is appended to the kernel so you can
also boot the legacy user space too with that if needed.

Regards,

Tony

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ