linux-kernel - Re: [PATCH] spmi-pmic-arb: support configurable number of peripherals

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: <20150915182728.GA11715@codeaurora.org>
Date:	Tue, 15 Sep 2015 11:27:28 -0700
From:	Stephen Boyd <sboyd@...eaurora.org>
To:	"Ivan T. Ivanov" <iivanov@...sol.com>
Cc:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	linux-kernel@...r.kernel.org, linux-arm-msm@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org,
	Gilad Avidov <gavidov@...eaurora.org>,
	Sagar Dharia <sdharia@...eaurora.org>
Subject: Re: [PATCH] spmi-pmic-arb: support configurable number of peripherals

On 09/15, Ivan T. Ivanov wrote:
> 
> On Mon, 2015-09-14 at 18:28 -0700, Stephen Boyd wrote:
> > On 09/14/2015 02:54 PM, Stephen Boyd wrote:
> > > The current driver implementation supports only 128 peripherals.
> > > Add support for more than 128 peripherals by taking a lazy
> > > caching approach to the mapping tables. Instead of reading the
> > > tables at boot given some fixed size, read them on an as needed
> > > basis and cache the results. We still assume a max number of 512
> > > peripherals, trading off some space for simplicity.
> > > 
> > > Based on a patch by Gilad Avidov <gavidov@...eaurora.org> and
> > > Sagar Dharia <sdharia@...eaurora.org>.
> > > 
> > > Signed-off-by: Stephen Boyd <sboyd@...eaurora.org>
> > > ---
> > 
> > Hi Ivan,
> > 
> > This patch causes 8916 to crash, because there isn't a mapping for ppid
> > 257 in the ppid to channel table. It seems that we're reading the revid
> > from the slave id 1 pmic by going through channel 0, which seems to be
> > setup for ppid 9 (slave id 0 and the peripheral starting at 0x900). Can
> > we stop reading the revid registers from non-zero slave id pmic devices?
> > That would be one solution to fix this problem. Or maybe we need to
> > special case this in the pmic arbiter code to fold ppid 0xN01 (slave id
> > N and address 0x100) onto channel 0 all the time?
> > 
> 
> Yes, we can. We are not using this information at the moment.
> Right now, revision read is more or less for debug purposes.
> 
> Would following patch work for you? Of course it will be difficult

Yes the patch works fine. Feel free to add a

Tested-by: Stephen Boyd <sboyd@...eaurora.org>

> to guaranties that some other driver misbehave and touch non-existing
> register, right?

Yeah some driver could misbehave and try to read/write something
that doesn't exist. As in this case, the device will reset. Given
that all this stuff is in the kernel though, it seems fine to
blow up instead of add a bunch of checks that aren't ever going
to matter in practice.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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/