linux-kernel - RE: [PATCH 2/2 v7] pinmux: add a driver for the U300 pinmux

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: <74CDBE0F657A3D45AFBB94109FB122FF17395556DC@HQMAIL01.nvidia.com>
Date:	Tue, 27 Sep 2011 17:15:33 -0700
From:	Stephen Warren <swarren@...dia.com>
To:	Linus Walleij <linus.walleij@...aro.org>
CC:	Linus Walleij <linus.walleij@...ricsson.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Grant Likely <grant.likely@...retlab.ca>,
	Barry Song <21cnbao@...il.com>,
	Lee Jones <lee.jones@...aro.org>,
	Joe Perches <joe@...ches.com>,
	Russell King <linux@....linux.org.uk>,
	Linaro Dev <linaro-dev@...ts.linaro.org>,
	Sascha Hauer <s.hauer@...gutronix.de>,
	David Brown <davidb@...eaurora.org>
Subject: RE: [PATCH 2/2 v7] pinmux: add a driver for the U300 pinmux

Linus Walleij wrote at Tuesday, September 27, 2011 2:01 AM:
> On Wed, Sep 21, 2011 at 9:39 PM, Stephen Warren <swarren@...dia.com> wrote:
> > Linus Walleij wrote at Wednesday, September 21, 2011 2:25 AM:
> >> On Wed, Sep 21, 2011 at 12:15 AM, Stephen Warren <swarren@...dia.com> wrote:
> >> > Linus Walleij wrote at Friday, September 16, 2011 6:14 AM:
> >> >> +     for (i = 0; i < ARRAY_SIZE(u300_mux_hogs); i++) {
> >> >> +             struct pinmux *pmx;
> >> >> +             int ret;
> >> >> +
> >> >> +             pmx = pinmux_get(u300_mux_hogs[i].dev, NULL);
> >> >> +             if (IS_ERR(pmx)) {
> >> >> +                     pr_err("u300: could not get pinmux hog %s\n",
> >> >> +                            u300_mux_hogs[i].name);
> >> >> +                     continue;
> >> >> +             }
> >> >> +             ret = pinmux_enable(pmx);
> >> >> +             if (ret) {
> >> >> +                     pr_err("u300: could enable pinmux hog %s\n",
> >> >> +                            u300_mux_hogs[i].name);
> >> >> +                     continue;
> >> >> +             }
> >> >> +             u300_mux_hogs[i].pmx = pmx;
> >> >> +     }
> >> >> +     return 0;
> >> >> +}
> >> >> +subsys_initcall(u300_pinmux_fetch);
> >> >
> >> > Why not just have the pinmux core support hogging on non-"system" mapping
> >> > entries; then everything I quoted above except u300_pinmux_map[] could
> >> > be deleted, and the "hog" flag set on the last 3 u300_pinmux_map[] entries.
> >>
> >> Very good question, luckily I have a good answer.
> >>
> >> There is no way for the pinmux core to traverse the system and look
> >> up the apropriate struct device * pointers.
> >
> > It's unclear to me why that would be needed.
> >
> > For non-system mappings, either the device-driver in question will be
> > get'ing and enabling them (this case isn't relevant to this discussion),
> > or they'll be hogged. In the hog case, I doubt anything would ever want
> > to disable them and switch the device to a different mapping entry; if
> > that were the case, the entries shouldn't be hogged, but get/enabled by
> > the device anyway. Hence, I don't see the need for an activation of a
> > hog'd non-system mapping entry to care about the device fields that are
> > in the mapping table at all; they could just be ignored couldn't they?
> 
> I don't think so, atleast not in this case. I think it is helpful for the system
> to know which device is related to the specific hog, so it turns up in
> debugfs etc "aha, it is hogged for that device" etc. Not doing that
> makes the subsystem loose relevant information.
> 
> So for that reason I prefer to pass in the relevant struct device *
> pointers, atleast when they're readily available as in this boardfile.
> 
> If they are not available, or hard to get at, we could just redefine
> them as system mappings and remove the device fields, but
> in this case I'd say let's keep it around.

Yes, it makes perfect sense to show this in debugfs.

But can't debugfs just get its information from the device name field in
the mapping table? I'm not sure why the need to use that information for
debugfs prevents the having entries with both the hog flag set and a
device name set?

-- 
nvpublic

--
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/