linux-kernel - Re: [RESEND PATCH] spmi: prefix spmi bus device names with "spmi"

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: <20201002180430.GG5527@sirena.org.uk>
Date:   Fri, 2 Oct 2020 19:04:30 +0100
From:   Mark Brown <broonie@...nel.org>
To:     Stephen Boyd <sboyd@...nel.org>
Cc:     David Collins <collinsd@...eaurora.org>,
        linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RESEND PATCH] spmi: prefix spmi bus device names with "spmi"

On Fri, Oct 02, 2020 at 10:48:32AM -0700, Stephen Boyd wrote:
> Quoting Mark Brown (2020-10-02 09:03:24)

> > ...and doing this in the dev_name() should help other diagnostic users
> > (like dev_printk() for example).

> Don't thinks like dev_printk() prefix the bus name? See
> dev_driver_string()? So I agree that having the bus name is useful, but
> confused why there are testing scripts and things on top of regmap
> debugfs

Not that I've ever noticed, eg on the console.

> Put another way, why not introduce something similar to i2c-dev where
> userspace can read/write registers for devices on the SPMI bus?
> Otherwise I presume the test scripts inside Qualcomm are just reading
> registers out of regmap?

I know some other vendors use the regmap debugfs for their diagnostic
tools (obviously not with SPMI).  It's generally so they can get the
benefit of the cache, it's a combination of allowing the state to be
inspected while the driver has the device powered down and for devices
on slower buses being much more performant.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)