linux-kernel - Re: [PATCH] pinctrl: make the pinmux-pins more helpful

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: <20120224075243.GE25789@shlinux2.ap.freescale.net>
Date:	Fri, 24 Feb 2012 15:52:43 +0800
From:	Dong Aisheng <aisheng.dong@...escale.com>
To:	Linus Walleij <linus.walleij@...ricsson.com>
CC:	<linux-kernel@...r.kernel.org>,
	<linux-arm-kernel@...ts.infradead.org>,
	Stephen Warren <swarren@...dia.com>,
	Grant Likely <grant.likely@...retlab.ca>,
	Barry Song <21cnbao@...il.com>,
	Shawn Guo <shawn.guo@...escale.com>,
	Thomas Abraham <thomas.abraham@...aro.org>,
	Dong Aisheng <dong.aisheng@...aro.org>,
	Rajendra Nayak <rajendra.nayak@...aro.org>,
	Haojian Zhuang <haojian.zhuang@...vell.com>,
	Linus Walleij <linus.walleij@...aro.org>
Subject: Re: [PATCH] pinctrl: make the pinmux-pins more helpful

On Fri, Feb 24, 2012 at 06:56:09AM +0100, Linus Walleij wrote:
> From: Linus Walleij <linus.walleij@...aro.org>
> 
> The debugfs file pinmux-pins used to tell which function was
> enabled but now states simply which device owns the pin. Being
> owned by the pinctrl driver itself means just that it's hogged
> so be a bit more helpful by printing that.
> 
It's useful.

Acked-by: Dong Aisheng <dong.aisheng@...aro.org>

BTW, one question below although it's not relatd to this patch itself.

> Signed-off-by: Linus Walleij <linus.walleij@...aro.org>
> ---
> I somewhat mourn the loss of being able to tell from the debugfs
> which function is using a certain pin, does anyone have ideas on
> how to go about fixing this properly? The root file
> pinctrl-handles does tell it, but requires cross-referencing
> which isn't helpful.
> ---
>  drivers/pinctrl/pinmux.c |   11 +++++++++--
>  1 files changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/pinctrl/pinmux.c b/drivers/pinctrl/pinmux.c
> index 98b89d6..db5ed86 100644
> --- a/drivers/pinctrl/pinmux.c
> +++ b/drivers/pinctrl/pinmux.c
> @@ -626,8 +626,8 @@ static int pinmux_pins_show(struct seq_file *s, void *what)
>  
>  	/* The pin number can be retrived from the pin controller descriptor */
>  	for (i = 0; i < pctldev->desc->npins; i++) {
> -
>  		struct pin_desc *desc;
> +		const char *owner;
>  
>  		pin = pctldev->desc->pins[i].number;
>  		desc = pin_desc_get(pctldev, pin);
> @@ -635,9 +635,16 @@ static int pinmux_pins_show(struct seq_file *s, void *what)
>  		if (desc == NULL)
>  			continue;
>  
> +		if (!desc->owner)
> +			owner = "UNCLAIMED";
> +		else if (!strcmp(desc->owner, pinctrl_dev_get_name(pctldev)))
> +			owner = "HOG";
> +		else
> +			owner = desc->owner;
> +
>  		seq_printf(s, "pin %d (%s): %s\n", pin,
>  			   desc->name ? desc->name : "unnamed",
Is there a little issue?
For this line, i see some code:
static int pinctrl_register_one_pin(struct pinctrl_dev *pctldev,
                                    unsigned number, const char *name)
{
...
        pindesc = kzalloc(sizeof(*pindesc), GFP_KERNEL);
        if (pindesc == NULL)
                return -ENOMEM;
...
        /* Copy basic pin info */
        if (name) {
                pindesc->name = name;
        } else {
                pindesc->name = kasprintf(GFP_KERNEL, "PIN%u", number);
                if (pindesc->name == NULL)
                        return -ENOMEM;
                pindesc->dynamic_name = true;
        }
...
}
So is it possible the desc->name is NULL?

> -			   desc->owner ? desc->owner : "UNCLAIMED");
> +			   owner);
>  	}
>  
>  	return 0;

Regards
Dong Aisheng

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