y: Ben Dooks <ben.do...@codethink.co.uk>
Geert/Laurent:
- take a look at this patch
- shall I apply this directly?
Yours,
Linus Walleij
On Fri, Jun 10, 2016 at 5:11 PM, Wolfram Sang <w...@the-dreams.de> wrote:
> From: Wolfram Sang <wsa+rene...@sang-engineering.com>
>
> It must be "drive-strength", with a hyphen.
>
> Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com>
Ge
On Fri, Jun 10, 2016 at 12:05 PM, Geert Uytterhoeven
<geert+rene...@glider.be> wrote:
> This series contains various cleanups for the Renesas Pin Function
> Controller driver subsystem.
Acked-by: Linus Walleij <linus.wall...@linaro.org>
I guess I will get them by pull reques
Morimoto <kuninori.morimoto...@renesas.com>
> Reviewed-by: Geert Uytterhoeven <geert+rene...@glider.be>
Acked-by: Linus Walleij <linus.wall...@linaro.org>
Geert, are you queuing this?
Yours,
Linus Walleij
unters
Solves the issue.
Can you verify?
Yours,
Linus Walleij
795: Add DRIF support (2016-06-23 11:01:21 +0200)
>
>
> pinctrl: sh-pfc: Updates for v4.8
Pulled into the pin control devel branch for v4.8.
Thanks for your efforts to keep the PFC development together!
Yours,
Linus Walleij
, or configuring the
> interrupt type.
>
> Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
Patch applied with Marc's ACK.
Yours,
Linus Walleij
seems to be a more
> appropriate name than SHMOBILE for the majority of Renesas ARM based SoCs.
>
> Signed-off-by: Simon Horman <horms+rene...@verge.net.au>
Acked-by: Linus Walleij <linus.wall...@linaro.org>
Expecting Geert to queue this for me.
Yours,
Linus Walleij
seems to be a more
> appropriate name than SHMOBILE for the majority of Renesas ARM based SoCs.
>
> Signed-off-by: Simon Horman <horms+rene...@verge.net.au>
OK sounds like a good cause, patch applied.
Yours,
Linus Walleij
= gpiochip_get_data(gc);
> +
> + pm_runtime_put(>pdev->dev);
> +}
> +
> static irqreturn_t gpio_rcar_irq_handler(int irq, void *dev_id)
> {
> struct gpio_rcar_priv *p = dev_id;
> @@ -450,6 +490,8 @@ static int gpio_rcar_probe(struct platform_device *pdev)
> irq_chip->irq_unmask = gpio_rcar_irq_enable;
> irq_chip->irq_set_type = gpio_rcar_irq_set_type;
> irq_chip->irq_set_wake = gpio_rcar_irq_set_wake;
> + irq_chip->irq_request_resources = gpio_rcar_irq_request_resources;
> + irq_chip->irq_release_resources = gpio_rcar_irq_release_resources;
> irq_chip->flags = IRQCHIP_SET_TYPE_MASKED | IRQCHIP_MASK_ON_SUSPEND;
>
> ret = gpiochip_add_data(gpio_chip, p);
> --
> 1.9.1
>
Yours,
Linus Walleij
;
> Signed-off-by: Sergei Shtylyov <sergei.shtyl...@cogentembedded.com>
These look fine to me, Acked-by for both.
Geert, will you & Laurent review and queue this please.
Yours,
Linus Walleij
d on the patches by Mitsuhiro Kimura <mitsuhiro.kimura...@renesas.com>.
>
> Thank you for your patch!
>
>> Signed-off-by: Sergei Shtylyov <sergei.shtyl...@cogentembedded.com>
>
> Reviewed-by: Geert Uytterhoeven <geert+rene...@glider.be>
I guess this means you're queueing it too?
Yours,
Linus Walleij
> causing a crash:
Ooops got two patches to this independently and applied the other one,
I tagged your name onto the Reported-by now. Thanks!
Yours,
Linus Walleij
it repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git
> sh-pfc-for-v4.6
>
> for you to fetch changes up to 4c96cb027be5ceb2c7c0d4dc086d35fd0cfaf14b:
Pulled to my devel branch.
Pushing to the build servers soon.
Thanks for your excellent comaintenance efforts!
Yours,
Linus Walleij
ound here so keep me, Ulf and tglx in the loop!
Yours,
Linus Walleij
; + pinctrl_provide_dummies();
So remind we: what Renesas platforms are still not using DT?
arch/sh?
Yours,
Linus Walleij
de.
>
> We also delete the MODULE_LICENSE tag etc. since all that information
> was (or is now) contained at the top of the file in the comments.
>
> Cc: Laurent Pinchart <laurent.pinch...@ideasonboard.com>
> Cc: Geert Uytterhoeven <geert+rene...@glider.be>
> Cc: L
er function
> to tighten the code and make it more readable.
>
> Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com>
Patch applied with Geert's ACK.
Yours,
Linus Walleij
gt;> Perhaps the of_have_populated_dt() check should be moved inside
>> pinctrl_provide_dummies()?
>
> I suggest we pick up this patch now even with stable tag (the irq storm
> fixup doesn't work correctly because of this) and consider the
> refactoring as a second step?
Sergei, Geert, do you ACK this?
Yours,
Linus Walleij
iver has to call pinctrl_request_gpio() etc,
it needs something to hold on to if there is no backing pin
controller for one of them.
Yours,
Linus Walleij
> Signed-off-by: Sergei Shtylyov <sergei.shtyl...@cogentembedded.com>
> CC: sta...@vger.kernel.org
Putting this on hold because another patch is being discussed as a
more proper fix.
Yours,
Linus Walleij
On Thu, Mar 31, 2016 at 10:41 AM, Geert Uytterhoeven
<ge...@linux-m68k.org> wrote:
> On Thu, Mar 31, 2016 at 10:34 AM, Linus Walleij
>> Geert, are you queuing a pull request to me or do you think
>> Renesas activity is down to a level where I can return to applying
>>
ch applied.
Maybe we should move the ACPI specs into the kernel
as well as that stuff is taking my time as well now, apart
from DT :/
Yours,
Linus Walleij
ake-up should be doable.
I think this actually implies OPEN_DRAIN and if you flag it as such
the core should be happy using it as input and output at the same
time.
If the hardware has a problem with reading the value from a line
that is set to output, it needs a workaround hack in the driver to
support reading and output line, *NOT* changes to gpiolib,
because the lib assumes this is always possible, i.e. it will
call the driver .get() callback no matter what.
Yours,
Linus Walleij
Geert to either queue this for his first v4.7 pull request
or tell me to apply it for fixes. Is it a regression?
Yours,
Linus Walleij
On Tue, Mar 22, 2016 at 2:59 PM, Vaibhav Hiremath
<vaibhav.hirem...@linaro.org> wrote:
> On Thursday 17 March 2016 03:48 PM, Linus Walleij wrote:
> but recently I came across another usecase of shared gpio,
>
> Say, for example, we have multiple external I2C peripheral which
58c9d039d3e4f7bd:
>
> pinctrl: sh-pfc: r8a7795: Add CAN FD support (2016-02-26 13:59:41 +0100)
Pulled to my devel branch and pushed to the autobuilders.
Yours,
Linus Walleij
On Wed, Apr 13, 2016 at 10:11 AM, Geert Uytterhoeven
<ge...@linux-m68k.org> wrote:
> On Wed, Apr 13, 2016 at 9:23 AM, Linus Walleij <linus.wall...@linaro.org>
> wrote:
>> On Tue, Apr 12, 2016 at 5:57 PM, Wolfram Sang <w...@the-dreams.de> wrote:
>>
>
On Mon, Apr 25, 2016 at 11:32 AM, Cao Minh Hiep <cm-h...@jinso.co.jp> wrote:
> Hello Linus Walleij-san
>
> We have tested Linux upstream v4.6-rc2 on Renesas's Lager board.
> When we tried to unbind the e6051000.gpio, the following warning messages
> occurs:
>
> "ro
gpio_init().
> Hence I think it's best to take this through the GPIO tree, after the
> above has been applied.
>
> v2:
> - Return zero instead of -ENXIO.
Patch applied.
Yours,
Linus Walleij
create_mapping(), or
> irq_create_fwspec_mapping() return zero! This also applies to the
> core helper gpiochip_to_irq().
Zero means NO_IRQ.
Reminder:
http://lwn.net/Articles/470820/
What we should do is patch all drivers to return 0 on failure, and
patch any consumers like mctrl_gpio_init() to handle that correctly.
Yours,
Linus Walleij
a negative to deal with the error.
+*/
+ if (!ret)
+ ret = -ENOSYS;
return ERR_PTR(ret);
}
gpios->irq[i] = ret;
Yours,
Linus Walleij
On Mon, May 2, 2016 at 10:03 AM, Geert Uytterhoeven
<ge...@linux-m68k.org> wrote:
> On Sun, May 1, 2016 at 10:48 AM, Linus Walleij <linus.wall...@linaro.org>
> wrote:
>>> - Drivers that call irq_find_mapping(), irq_create_mapping(), or
>>> irq
e...@sang-engineering.com>
I saw this the other day too I agree.
Sebastian: are you OK that I move this by committing the patch to the GPIO tree?
DT maintainers: OK?
Yours,
Linus Walleij
it repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git
> sh-pfc-for-v4.7
Pulled into the devel branch for v4.7.
Thanks Geert!
Yours,
Linus Walleij
On Fri, Apr 15, 2016 at 6:53 PM, Rob Herring <r...@kernel.org> wrote:
> On Fri, Apr 15, 2016 at 2:48 AM, Linus Walleij <linus.wall...@linaro.org>
> wrote:
>> On Tue, Apr 12, 2016 at 6:00 PM, Wolfram Sang <w...@the-dreams.de> wrote:
>>
>>> From: W
ued up in sh-pfc-for-v4.9.
OK! Acked-by.
Yours,
Linus Walleij
On Tue, Jul 12, 2016 at 11:40 PM, Sergei Shtylyov
<sergei.shtyl...@cogentembedded.com> wrote:
> Add SDHI0 pin groups to the R8A7792 PFC driver.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtyl...@cogentembedded.com>
Acked-by: Linus Walleij <linus.wall...@linaro.org&g
lyov <sergei.shtyl...@cogentembedded.com>
This looks like a fix that should go in ASAP?
Geert, do you want me to apply this directly for fixes with
your ACK?
Yours,
Linus Walleij
On Thu, Jul 7, 2016 at 4:11 PM, Sergei Shtylyov
<sergei.shtyl...@cogentembedded.com> wrote:
> Renesas R8A7792 SoC is a member of the R-Car gen2 family, add support for
> its GPIO controllers.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtyl...@cogentembedded.com>
Patc
rent's ACK.
(Not expecting Geert to collect patches for me this late in the merge
cycle.)
Yours,
Linus Walleij
the comment
will be satisfied when the GPIO is first requested, but if we're just
using the interrupt, we still will be able to set the direction right.
Yours,
Linus Walleij
On Tue, Jul 5, 2016 at 5:46 PM, Geert Uytterhoeven <ge...@linux-m68k.org> wrote:
> On Tue, Jul 5, 2016 at 4:54 PM, Linus Walleij <linus.wall...@linaro.org>
> wrote:
>> On Tue, Jul 5, 2016 at 8:57 AM, Geert Uytterhoeven <ge...@linux-m68k.org>
>> wrote:
>&g
On Fri, Jul 1, 2016 at 11:41 AM, Peter Chen <peter.c...@nxp.com> wrote:
> of_node_put needs to be called when the device node which is got
> from of_parse_phandle has finished using.
>
> Cc: Linus Walleij <linus.wall...@linaro.org>
> Signed-off-by: Peter Chen <peter.
ups into the device tree in a nice
way, which makes it relevant for him to have a look as well, if he has
time.
Yours,
Linus Walleij
upport (2017-01-20 14:23:40
> +0100)
Pulled into the pinctrl devel branch for v4.11.
Yours,
Linus Walleij
On Thu, Jan 19, 2017 at 10:36 AM, Geert Uytterhoeven
<ge...@linux-m68k.org> wrote:
> On Thu, Jan 19, 2017 at 10:27 AM, Linus Walleij
> <linus.wall...@linaro.org> wrote:
>> On Wed, Jan 18, 2017 at 3:06 PM, Geert Uytterhoeven
>> <ge...@linux-m68k.org> wrote:
On Wed, Jan 18, 2017 at 3:06 PM, Geert Uytterhoeven
<ge...@linux-m68k.org> wrote:
> Hi Linus,
>
> On Wed, Jan 18, 2017 at 2:58 PM, Linus Walleij <linus.wall...@linaro.org>
> wrote:
>>> + gpio_chip->request = rz_gpio_request;
>>> + gpio_chi
_P], NULL,
NULL, p->io[REG_PM], 0);
if (ret)
return ret;
This might need some flags or I screwed something up, but I'm
convinced you can use GENERIC_GPIO like this.
The generic accessors also sets the value before switching
direction.
If you're uncertain about the sematics, read drivers/gpio/gpio-mmio.c.
> + gpio_chip->request = rz_gpio_request;
> + gpio_chip->free = rz_gpio_free;
> + gpio_chip->label = dev_name(>dev);
> + gpio_chip->parent = >dev;
> + gpio_chip->owner = THIS_MODULE;
> + gpio_chip->base = -1;
> + gpio_chip->ngpio = ret == 0 ? args.args[2] : RZ_GPIOS_PER_PORT;
bgpio_init() will have already set this up to 16 (RZ_GPIOS_PER_PORT)
as we pass width 2 bytes.
Yours,
Linus Walleij
On Mon, Aug 22, 2016 at 2:23 PM, Geert Uytterhoeven
<ge...@linux-m68k.org> wrote:
> On Mon, Aug 22, 2016 at 2:10 PM, Linus Walleij <linus.wall...@linaro.org>
> wrote:
>> Geert, I assume you will queue this?
>
> Sure, it's part of the pull request I sent last week ;-
>
> pinctrl: sh-pfc: r8a7796: Add SDHI pins, groups and functions (2016-08-19
> 09:37:20 +0200)
Pulled into the pinctrl development branch, thanks!
Yours,
Linus Walleij
Sergei Shtylyov <sergei.shtyl...@cogentembedded.com>
Acked-by: Linus Walleij <linus.wall...@linaro.org>
Expecting Geert to queue it.
Yours,
Linus Walleij
t; Signed-off-by: Simon Horman <horms+rene...@verge.net.au>
> Reviewed-by: Geert Uytterhoeven <geert+rene...@glider.be>
> Reviewed-by: Laurent Pinchart <laurent.pinch...@ideasonboard.com>
> Tested-by: Laurent Pinchart <laurent.pinch...@ideasonboard.com>
Patch applied.
Yours,
Linus Walleij
ly supported using the
> same mechanism as r8a7791. I intend to provide a follow-up patch
> once testing is completed.
Acked-by: Linus Walleij <linus.wall...@linaro.org>
I expect these to be merged by Geert who send the patches to me.
Yours,
Linus Walleij
4: Implement voltage switching for SDHI (2016-09-14
> 09:26:54 +0200)
Thanks, pulled in and pushed to the autobuilders for test.
Yours,
Linus Walleij
it repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git
> tags/sh-pfc-for-v4.10-tag1
Pulled to my devel branch.
Thanks!
Yours,
Linus Walleij
erH SoCs.
>
> However, ARCH_EMEV2 is even more suitable here.
I fixed the patch in-tree to use ARCH_EMEV2 instead.
Thanks!
Yours,
Linus Walleij
-07
> 10:39:11 +0100)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git
> tags/sh-pfc-for-v4.10-tag2
Pulled into the pin control tree, thanks a lot!
Yours,
Linus Walleij
ooks like hell.
Apart from that, we generally need a way to access LEDs as resources with
foo-leds = <_foo>; in the device tree just like we can get GPIOs and I
hope someone is working on that for this thing... triggers is such a hack.
Yours,
Linus Walleij
n the future.
>
> No, this is fine. I'm a bit dubious about [1] given that it consumes more CPU
> cycles without any benefit as far as I can see. Maybe I can't see far enough
> though, Linus Walleij could prove me wrong :-)
This was changed mainly for maintainability and code readab
= -1;
> + gpio_chip->ngpio = ret == 0 ? args.args[2] : RZ_GPIOS_PER_PORT;
> +
> + ret = gpiochip_add(gpio_chip);
Use devm_gpiochip_add_data() providing struct rz_gpio_priv * as
data.
> +static int rz_gpio_remove(struct platform_device *pdev)
> +{
> + struct rz_gpio_priv *p = platform_get_drvdata(pdev);
> +
> + gpiochip_remove(>gpio_chip);
> + return 0;
> +}
And with the devm_gpiochip_add_data() you don't even need
this remove().
Yours,
Linus Walleij
-by: Jacopo Mondi <jacopo+rene...@jmondi.org>
A new version appeared while I was reviewing the old version.
Oh well. The comments still apply.
Yours,
Linus Walleij
t need any special flags.
> Or do you guys have any better ideas?
Not really. So you mean revert the previous patch and apply something
like this instead?
Yours,
Linus Walleij
it repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git
> tags/sh-pfc-for-v4.11-tag1
>
> for you to fetch changes up to 0e4e4999aac16641f47699e8929693b83a7a4d64:
Pulled this in and pushed the branch to the build servers,
thanks!
Yours,
Linus Walleij
normal use (gpio2 is used for LEDs and regulators, gpio5 for keys, gpio6
> for SD-Card CD & WP, gpio7 for keys and regulators).
>
> Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
> [Niklas: s/gpio_to_priv(chip)/gpiochip_get_data(chip)/]
> Signed-off-by: Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se>
Patch applied.
Yours,
Linus Walleij
ed.
>
> Signed-off-by: Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se>
Patch applied with the ACKs.
Yours,
Linus Walleij
ts bindings and say "ah I know this".
The fact that historically all the early adopters of pinctrl in device tree
have these funky custom bindings is unfortunate but just something
that we need to live with.
Yours,
Linus Walleij
cumulate such writes in the driver and apply it all when you have
it all available no matter if pin multiplexing or pin config happens first?
Surely this is just a hardware pecularity, then it warrants some special
driver code.
If you definately feel you must get a call from the pin control core setting
up muxing and config at the same time we need to think of a way to
augment the pin control core if necessary?
The fact that Linux pin control subsystem semantics you don't
like does not affect the relevant device tree bindings.
Yours,
Linus Walleij
l applicability, by the end
of the day they are *still* pin config, not magic flags we can choose to
toss in with the muxing, so you can do what the Qualcomm driver
does and add custom pin configurations extending the generic
pin config, see drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
qcom,pull-up-strength etc.
Yours,
Linus Walleij
On Wed, Mar 29, 2017 at 4:55 PM, Chris Brandt <chris.bra...@renesas.com> wrote:
> On Wednesday, March 29, 2017, Linus Walleij wrote:
>> On Fri, Mar 24, 2017 at 4:22 PM, Jacopo Mondi <jacopo+rene...@jmondi.org>
>> wrote:
>>
>> > Add dt-bindings for R
s" since the trees go through the C preprocessor
so you can use macros and bit | OR to build them?
Yours,
Linus Walleij
(in my
> opinion).
The flags I don't like at all, and think they should be converted to generic
pin config because they have nothing to do with muxing.
But I will point that out in the specific patch adding them.
Yours,
Linus Walleij
boot/dts/mt2701-pinfunc.h
arch/arm/boot/dts/mt2701-evb.dts
The docs are here:
Documentation/devicetree/bindings/pinctrl/pinctrl-mt65xx.txt
I'm sorry that "pinmux" is not part of the generic documentation, it'd be
great if you would like to add it with a patch.
Yours,
Linus Walleij
no big deal to move it into a new subdir if many
new drivers start popping in anyway.
Right now I see the use of renesas,pins as the only big blocker,
I would much like it to use just pins = <>;
Yours,
Linus Walleij
On Wed, Mar 29, 2017 at 9:30 AM, Geert Uytterhoeven
<ge...@linux-m68k.org> wrote:
> On Fri, Mar 24, 2017 at 4:42 PM, Linus Walleij <linus.wall...@linaro.org>
> wrote:
>> On Fri, Mar 24, 2017 at 4:22 PM, Jacopo Mondi <jacopo+rene...@jmondi.org>
>> wr
So this allows for a combine pin+function number but pull ups,
bias etc are not baked into the thing, they have to be added on
separately with the generic bindings, which is nice and very readable.
Yours,
Linus Walleij
on for sure.
> +static int rza1_pinmux_set(struct pinctrl_dev *pctldev, unsigned int
> selector,
> + unsigned int group)
Please name it rza1_set_mux() to correspond with the ops field.
Yours,
Linus Walleij
> 11:21:55 +0100)
Pulled into my devel branch in the pinctrl tree.
Thanks!
Linus Walleij
intaining
subdirs in pinctrl...
Yours,
Linus Walleij
3-30 13:43:55 +0200)
Pulled into the pinctrl devel branch, thanks!
Yours,
Linus Walleij
of_property_read_u32_index(node, "pinmux",
> i, );
> ...
It makes sense. Just make sure to move users over to use the helpers.
Yours,
Linus Walleij
mal with DT bindings. The GPIO bindings are just over the top
with BNF notation in its formalism. Dunno what is best here :/
Yours,
Linus Walleij
igned-off-by: Jacopo Mondi <jacopo+rene...@jmondi.org>
Patch applied with Rob's ACK.
Yours,
Linus Walleij
late) else the requirements are there for a merge in the early
v4.12 kernel cycle.
Yours,
Linus Walleij
nks, pulled into my devel branch for v4.12.
Yours,
Linus Walleij
I plan to queue these up in sh-pfc-for-v4.14.
All look good to me.
Yours,
Linus Walleij
>>
>> Fixes: d10bbd156926 ("gpio: rcar: add gen[123] fallback compatibility
>> strings")
>> Signed-off-by: Simon Horman <horms+rene...@verge.net.au>
>
> Hi Linus,
>
> I believe Geert is on holidays at the moment (maybe you are to‽).
Nah neither of us are as it seems :)
I wait for the two of you to figure this out before applying anything.
Yours,
Linus Walleij
umi...@gmail.com>
Patch applied.
Yours,
Linus Walleij
ixes: 5a49b644b3075f88 ("pinctrl: Renesas RZ/A1 pin and gpio controller")
> Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
Patch applied.
Yours,
Linus Walleij
buffers irrespective of the mode of the line as a whole.
We might need even more documentation because this is really
confusing.
But for now it lets drivers work, which is nice.
Rough consensus and running code should be our guide.
Yours,
Linus Walleij
(2017-06-26 10:21:38 +0200)
Pulled in for devel.
It's late, but you all worked hard to make this happen so we should
be liberal, also it is a new driver.
Yours,
Linus Walleij
hris Paterson <chris.paters...@renesas.com>
> ---
> v1->v2
> * Modified the text "RZ-G1M" to "RZ/G1M"
Patch applied with the ACKs.
Yours,
Linus Walleij
>
> Signed-off-by: Marek Vasut <marek.vasut+rene...@gmail.com>
> Cc: linux-g...@vger.kernel.org
> Cc: Geert Uytterhoeven <geert+rene...@glider.be>
> Cc: Linus Walleij <linus.wall...@linaro.org>
(...)
> +#include
Only use
#include
It should be enough.
With that:
R
hat happens
electrically?
Isn't this bias-high-impedance / High-Z?
Hopefully you can find the answer from Renesas hardware dept.
You can certainly call it whatever the datasheet calls it
in your driver #defines but for the DT bindings we would
ideally have the physical world things.
Yours,
Linus Walleij
just means open drain.
It is dangerous to merge things we don't understand.
Surely someone inside Renesas can answer this question.
Yours,
Linus Walleij
>
> Signed-off-by: Marek Vasut <marek.vasut+rene...@gmail.com>
> Cc: linux-g...@vger.kernel.org
> Cc: Geert Uytterhoeven <geert+rene...@glider.be>
> Cc: Linus Walleij <linus.wall...@linaro.org>
> Reviewed-by: Linus Walleij <linus.wall...@linaro.org>
> ---
>
arse_dt_config();
>> + * we simply discard pinconf argument here
>> + */
>> +#define PIN_CONF_UNPACK(pinconf) ((pinconf) & 0xffUL)
>
> Perhaps this should be moved to pinconf-generic.h, to make sure it stays
> up-to-date?
I agree. Use the generic macros.
If further processing is needed, make a static inline to discard config flags
etc.
Yours,
Linus Walleij
_param(unsigned
long config)
{
return (enum pin_config_param) (config & 0xffUL);
}
static inline u32 pinconf_to_config_argument(unsigned long config)
{
return (u32) ((config >> 8) & 0xffUL);
}
Why can't you use this in your code instead of macros?
We generally prefer static inlines over macros because they are easier
to read.
Yours,
Linus Walleij
>
> Signed-off-by: Marek Vasut <marek.vasut+rene...@gmail.com>
> Cc: linux-g...@vger.kernel.org
> Cc: Geert Uytterhoeven <geert+rene...@glider.be>
> Cc: Linus Walleij <linus.wall...@linaro.org>
> Reviewed-by: Linus Walleij <linus.wall...@linaro.org>
> ---
>
forward them to me when he's happy with them.
Yours,
Linus Walleij
1 - 100 of 187 matches
Mail list logo
