linux-kernel - Re: [RFC] pinctrl: Pin controller with different types of pins

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: <CACRpkdY2EHiaFTK26hoCwQ_TxgECohR2EAAmQESZYNvnx-mX9A@mail.gmail.com>
Date:	Fri, 26 Apr 2013 12:11:49 +0200
From:	Linus Walleij <linus.walleij@...aro.org>
To:	hanumant <hanumant@...eaurora.org>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Stephen Warren <swarren@...dotorg.org>,
	Laurent Pinchart <laurent.pinchart+renesas@...asonboard.com>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>
Subject: Re: [RFC] pinctrl: Pin controller with different types of pins

On Wed, Apr 24, 2013 at 1:47 AM, hanumant <hanumant@...eaurora.org> wrote:

> 2) After the above, we have config registers for the dedicated pins.
> In this case the config register are per use case. For example
> if SDCC uses dedicated pins as follows 1 clock pin, 8 data pins and 2
> command pins then there will be one config register as follows
> Bits 31-29 = clk pull value (1-7)
> Bits 28-26 = data line pull values (1-7)
> Bits 25-23 = command pull values (1-7)
> Bits 8-6 = clk drive strength values (1-7)
> Bits 5-3 = data drive strength values
> Bits 2-0 = command drive strength values

OK seems normal. I guess you really mean "drive strength" as in
"configurable mA output", because often the voltage (VCCQ) can
be controlled as well.

There is some overlap with regulators here, CC:ing Mark Brown
for a second opinion.

> The only option I see is
>
> 1) to implement this as one pin controller, with total number of pins =
> multi function pins + dedicated pins.

This seems easiest, this is what I would do.

> 2) The pin descriptor registered with the framework would be part of a
> bigger descriptor maintained by the driver that additionally defines the pin
> type and the register manipulation methods for that type.

Yes:

struct foo_desc {
    struct pin_desc desc;
    ...
};

Register &foo->desc to the pinctrl subsystem, to get back to
foo_desc, use container_of() to get to your descriptor from the
&foo_desc->desc.

> 3) The pin number would serve as an index into the driver descriptor.

I do not understandd what this means.

> 4) The register manipulation methods would be part of the of_device_id
> data for the pin controller

Not following. You're saying you register on controller, don't
you rather want a field on struct foo_desc telling how to handle
the particular pin type?

> I have not been able to find any precedence for this kind of pin controller
> design.

We've covered the simple cases and now we get to the
complicated ones :-)

> Is there any value add to having a private data field for the framework pin
> descriptor that can be overloaded for every pin to take care of these kinds
> of problems?

Incidentally I already answered a similar mail earlier today, and the
answer is no.

Encapsulate struct pin_desc inside a custom struct and get used to
using container_of().

Yours,
Linus Walleij
--
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/