Re: [PATCH/RFC] gpio: rcar: add gen[123] fallback compatibility strings
On Tue, Jul 11, 2017 at 2:38 PM, Simon Horman <horms+rene...@verge.net.au> wrote: > Add fallback compatibility string for R-Car Gen 1, 2 and 3. > > In the case of Renesas R-Car hardware we know that there are generations of > SoCs, f.e. Gen 1 and 2. But beyond that its not clear what the relationship > between IP blocks might be. For example, I believe that r8a7790 is older > than r8a7791 but that doesn't imply that the latter is a descendant of the > former or vice versa. > > We can, however, by examining the documentation and behaviour of the > hardware at run-time observe that the current driver implementation appears > to be compatible with the IP blocks on SoCs within a given generation. > > For the above reasons and convenience when enabling new SoCs a > per-generation fallback compatibility string scheme being adopted for > drivers for Renesas SoCs. > > Also deprecate renesas,gpio-rcar as its name is more generic than its > implementation. > > Signed-off-by: Simon Horman <horms+rene...@verge.net.au> Totally uncontroversial DT binding changes so patch applied for next with Geert's review tag. Yours, Linus Walleij
Re: [PATCH] pinctrl: Convert to using %pOF instead of full_name
On Tue, Jul 18, 2017 at 11:43 PM, Rob Herring <r...@kernel.org> wrote: > Now that we have a custom printf format specifier, convert users of > full_name to use %pOF instead. This is preparation to remove storing > of the full path string for each node. > > Signed-off-by: Rob Herring <r...@kernel.org> > Cc: Linus Walleij <linus.wall...@linaro.org> > Cc: Lee Jones <l...@kernel.org> > Cc: Eric Anholt <e...@anholt.net> > Cc: Stefan Wahren <stefan.wah...@i2se.com> > Cc: Florian Fainelli <f.faine...@gmail.com> > Cc: Ray Jui <r...@broadcom.com> > Cc: Scott Branden <sbran...@broadcom.com> > Cc: bcm-kernel-feedback-l...@broadcom.com > Cc: Ludovic Desroches <ludovic.desroc...@microchip.com> > Cc: Patrice Chotard <patrice.chot...@st.com> > Cc: Tomasz Figa <tomasz.f...@gmail.com> > Cc: Krzysztof Kozlowski <k...@kernel.org> > Cc: Sylwester Nawrocki <s.nawro...@samsung.com> > Cc: Laurent Pinchart <laurent.pinch...@ideasonboard.com> > Cc: Geert Uytterhoeven <geert+rene...@glider.be> > Cc: Barry Song <bao...@kernel.org> > Cc: linux-g...@vger.kernel.org > Cc: linux-rpi-ker...@lists.infradead.org > Cc: linux-arm-ker...@lists.infradead.org > Cc: ker...@stlinux.com > Cc: linux-samsung-...@vger.kernel.org > Cc: linux-renesas-soc@vger.kernel.org Patch applied with the recieved ACKs. Yours, Linus Walleij
Re: [PATCH v5 01/10] pinctrl: generic: Add bi-directional and output-enable
On Tue, May 9, 2017 at 12:54 PM, Geert Uytterhoeven <ge...@linux-m68k.org> wrote: Oops missed this: > Hence I think we should not use generic pin properties, but consider these > settings to be part of pinmux configuration. > As having large tables in the driver is undesirable, I think storing the > settings in the "pinmux" property (by encoding them as flags passed to the > RZA1_PINMUX() macro) is our best option. I think it is better to have large tables in the driver in this case. It is the lesser evil. Having unintelligible and hard to grasp stuff in the device tree that no user will understand or dare to touch is not good, then it is better to have it with the code, where it is being used, so the developers of the driver can see it when they are dealing with this (quirky) hardware. As you say this is actually fixing hardware bugs, we can expect these quirky tables to be gone in the next hardware generation, right? Then the right place for it is in the quirky driver for the quirky first-generation hardware. Yours, Linus Walleij
Re: [PATCH v5 01/10] pinctrl: generic: Add bi-directional and output-enable
On Tue, May 9, 2017 at 12:54 PM, Geert Uytterhoeven <ge...@linux-m68k.org> wrote: > The question I'm asking myself is: are these settings related to pin > configuration (i.e. depending on the use of the pin, and several settings > are valid, depending on the use case), or are they related to pinmux > (i.e. defined by the function)? If they are intrinsic to the function, i.e. whenever someone wants to use that function they need to do this (nb the Documentation/pinctrl.txt definition of "function", nothing else) then this should IMO not be in the device tree at all, but hard-coded in the driver. E.g. if someone needs to use a function such as "i2c0", on whatever pins, then it should just be set up by the driver, no DT involved. It is a hardware pecularity, drivers drive hardware so... If however it depends on which pins it is used with, then it is pin configuration and should use a DT property. Yours, Linus Walleij
Re: [PATCH v5 10/10] arm: dts: genmai: Add ethernet pin group
On Fri, May 5, 2017 at 2:45 PM, Chris Brandt <chris.bra...@renesas.com> wrote: > On Friday, May 05, 2017, Linus Walleij wrote: >> > This is the part of the whole "DT is for hardware description only" that >> doesn't really make sense to me. >> >> OK yeah we do hardware description AND configuration. >> >> And we never do interpreted languages. >> >> And then there is a bunch of grayzone things. For example we have a >> linux,input binding for connecting keypresses to certain Linux input codes. >> That is really grayzone, but very useful. > > Ah > > compatible = "linux,grayzone"; > > Thanks for the reply. I'll stop ranting now. > Of course, I'll still probably screw it up again on a future patch somehow... For this driver I remarked in some other thread that we may end up with some "renesas,bidirectional" or so. But yeah, it's kinda grayzone too. Yours, Linus Walleij
Re: [PATCH v5 01/10] pinctrl: generic: Add bi-directional and output-enable
On Tue, May 23, 2017 at 8:37 PM, jmondi <jac...@jmondi.org> wrote: >> I did not follow too much. >> But it seems IMX7ULP/Vybrid to be also a fan of generic >> output-enable/input-enable >> property. >> >> See: >> Figure 5-2. GPIO PAD in Page 241 >> http://www.nxp.com/assets/documents/data/en/reference-manuals/VFXXXRM.pdf >> >> It has separate register bits to control input buffer enable and >> output buffer enable >> and we need set it property for GPIO function. > > As it seems we have another user for 'output-enable' here, what if we just > add that one to the generic bindings properties list, and we keep > 'bi-directional' (which seems to be the most debated property we have > added) out of generic properties? > > We can handle 'bi-directional' pins with static tables in our pin > controller driver and not have it anywhere in DT. This sounds like a viable approach. I just want to know if "output-enable" is the right name? "output-buffer-enable"? > I see commit 42d5a11200d0[1] has not been reverted yet as Andy asked > in some previous email. I'm just overloaded. I sent that revert to Torvalds today. > I can send another version of that patch with > only 'output-enable' if you wish. That's what we want. > Once we reach consesus, I can then send v6 of our pin controller driver > based on that. OK sounds like a plan. Sorry for the mess, I'm just trying to get this right :/ Yours, Linus Walleij
Re: [git pull] pinctrl: sh-pfc: Updates for v4.13
On Mon, May 29, 2017 at 1:57 PM, Geert Uytterhoeven <geert+rene...@glider.be> wrote: > Hi Linus, > > The following changes since commit 2ea659a9ef488125eb46da6eb571de5eae5c43f6: > > Linux 4.12-rc1 (2017-05-13 13:19:49 -0700) > > 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.13-tag1 > > for you to fetch changes up to c8bac70f079bb3ecaf9a716f141f3d85cef27231: > > pinctrl: sh-pfc: r8a7794: Add R8A7745 support (2017-05-16 13:53:15 +0200) Awesome, good work as usual. Pulled to my pinctrl devel branch. Yours, Linus Walleij
Re: [PATCH v5 01/10] pinctrl: generic: Add bi-directional and output-enable
On Fri, Jun 9, 2017 at 9:50 AM, jmondi <jac...@jmondi.org> wrote: > On Fri, Jun 09, 2017 at 03:26:57PM +0800, Dong Aisheng wrote: >> > I see three options here: >> > >> > 1) Add "output-buffer-enable" and "input-buffer-enable" >> > we end up with >> > "output-high" >> > "output-low" >> > "input-enable" >> > "output-buffer-enable" >> > "input-buffer-enable" >> > >> > 2) Add "output-buffer-enable" only >> > we end up with >> > "output-high" >> > "output-low" >> > "input-enable" >> > "output-buffer-enable" >> > >> > Binding may be confusing as in one case we use "output-buffer-enable" >> > while in the other "input-enable" >> > >> > 3) Add "output-enable" only >> > "output-high" >> > "output-low" >> > "input-enable" >> > "output-enable" >> > >> > As you, I don't like "output-enable" that much but it pairs better with >> > "input-enable". >> > >> > I'll let you and DT people decide on this, as it's really an ABI definition >> > problem and you have better judgment there. >> > >> >> What's the final decision of this? > > I admit a was buying a bit of time and post-poned the gentle ping for > any final word on this. But since you're asking I'll second your > question :) I suspect it is time to quote Documentation/process/management-style.rst (Torvalds): 1) Decisions Everybody thinks managers make decisions, and that decision-making is important. The bigger and more painful the decision, the bigger the manager must be to make it. That's very deep and obvious, but it's not actually true. The name of the game is to **avoid** having to make a decision. In particular, if somebody tells you "choose (a) or (b), we really need you to decide on this", you're in trouble as a manager. The people you manage had better know the details better than you, so if they come to you for a technical decision, you're screwed. You're clearly not competent to make that decision for them. (It goes on, it's the best part of the entire Documentation/* dir in my opinion, please take the time to read it in full.) So: what do you guys, using this feature, and Andy, who raised serious concerns, think is the right binding? That is what *I* need to know. Yours, Linus Walleij
Re: [PATCH v5 01/10] pinctrl: generic: Add bi-directional and output-enable
On Fri, Apr 28, 2017 at 4:53 PM, Andy Shevchenko <andy.shevche...@gmail.com> wrote: > Linus, for me it looks like better to revert that change, until we > will have clear picture why existing configuration parameters can't > work. Yeah I'll revert the binding for fixes. Yours, Linus Walleij
Re: [PATCH v5 01/10] pinctrl: generic: Add bi-directional and output-enable
On Mon, May 8, 2017 at 7:25 PM, jmondi <jac...@jmondi.org> wrote: > From my perspective these flags are configurations internal to the pin > controller hardware used to enable/disable input buffers when a pin needs to > perform in both direction. > The level of detail I can provide on this is the logical diagram we have > pointed > you to already. > > As I assume you are trying to get this answer from us in order to > avoid duplicating things in pin controller sub-system, and I > understand this, but my question here was "can we have those flags as part > of the pinmux property argument list, as that property description > seems to allow us to do that, instead of making them generic pin > configuration properties and upset other developers?" Pinmux with all it's magic flags baked into one is not any better or any more readable. The solution is already very pretty except for these two flags which I am sure we can agree on a way forward for. What we choose between is not this or another less transparent pin configuration mechanism, the mechanism (whether magic bits to pinmux or reasonable properties) does not matter. There is a strong preference to use the generic bindings. So the discussion is whether to use: bi-directional; output-enable; Or some already defined config flags. If these are too idiomatic to be used by others, they should anyways look similar, like: renesas,bi-directional; renesas,output-enable; Like the Qualcomm weirdness found in drivers/pinctrl/qcom/pinctrl-spmi-gpio.c qcom,pull-up-strength = <..>; Check how they use #define PMIC_GPIO_CONF_PULL_UP (PIN_CONFIG_END + 1) Etc. > Anyway, I still fail to see why those configuration flags, only > affecting the way the pin controller hardware enables/disables > its internal buffers and its internal operations have to be > described in term of their externally visible electrically characteristics. To me internal vs external is not what matters. What matters is if this is likely to pop up in more platforms, and then the property should be generic. The generic pin config definitions are likely to be picked up by other standards and even be inspiration to hardware engineers so that is why it matters so much. > To me, what already exists are pin configuration properties generic to > the whole pin controller subsystem, and I understand you don't want to > see duplication there. > > At the same time, to me, those flags are settings the pin controller > wants to have specified by software to overcome its hw design flaws, > and are intended to configure its internal buffers in a way it cannot > do by itself for some very specific operation modes (they are listed > in the hw reference manual, it's not something you can chose to > configure or not, if you want a pin working in i2c mode, you HAVE to > pass those flags to pin controller). Sounds like a case for renesas,bi-directional; renesas,output-enable; following the Qualcomm pattern in that case. But let's see if something else comes out of this discussion. Yours, Linus Walleij
Re: [PATCH/RFC 1/3] dt-bindings: i2c: i2c-gpio: Add support for named gpios
On Mon, Sep 18, 2017 at 6:52 PM, Rob Herring <r...@kernel.org> wrote: > In theory yes, but reality is pretty much everyone follows it. There's > no other way to specify active high vs. low for example. Furthermore, > if someone wanted to do flags in their own custom way, that would > still work. It is still the controller (or GPIO core) that interprets > the flags, not the client. > > This is a new binding, so only new DT will have it and we can apply > new standards. I'd like to get a picture of any one-cell GPIO DTS:es and/or drivers still around. I would like to deal with them somehow. When we started the big DT migration this was one of the areas we made some screwups in, admittedly, but someone just has to go first, and that was incidentally GPIO controllers. At this time people were even playing around with DT bindings in BNF form, which is why the GPIO binding is a bit .. esoteric at times. I guess I should fix that. Yours, Linus Walleij
Re: [PATCH v2 resend 0/4] sh: sh7722/sh7757i/sh7264/sh7269: Fix pinctrl registration
On Tue, Sep 12, 2017 at 10:40 AM, Geert Uytterhoeven <geert+rene...@glider.be> wrote: > Hi Andrew, > > I'm resending this to you due to unresponsiveness from the SuperH > maintainers (v2 sent before on May 11, pinged on June 30 and August 14). I'm happy to take this into the pinctrl tree if need be. It is pinctrl related so it makes sense to carry it there if SH maintainers are not responding. Just send a separate pull request and indicate if it needs to go in for fixes or devel. Yours, Linus Walleij
Re: [PATCH] MAINTAINERS: Add git repository to Renesas pinctrl driver section
On Wed, Oct 4, 2017 at 1:35 PM, Geert Uytterhoeven <geert+rene...@glider.be> wrote: > Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be> Patch applied with Simon's tag. Yours, Linus Walleij
Re: [PATCH] gpio: rcar: Use of_device_get_match_data() helper
On Wed, Oct 4, 2017 at 2:16 PM, Geert Uytterhoeven <geert+rene...@glider.be> wrote: > Use the of_device_get_match_data() helper instead of open coding. > Note that the gpio-rcar driver is used with DT only, so there's always a > valid match. > > Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be> Patch applied with Simon's tag. Yours, Linus Walleij
Re: mainline 4.14-rc4: renesas_sdhi_internal_dmac ee100000.sd: swiotlb buffer is full?
On Mon, Oct 16, 2017 at 11:02 AM, Geert Uytterhoeven <ge...@linux-m68k.org> wrote: >> IIUC, >> - Since the MMC_BOUNCE disappeared in v4.14-rc1, the MMC core will request a >> command with 64kbyte+ size. >> - So, swiotlb will got request 64kbyte+ size. This is different with >> previous version. Other people reported problems with that. Sorry about this... This problem should be solved by upstream commit de3ee99b097dd51938276e3af388cd4ad0f2750a "mmc: Delete bounce buffer handling" I just killed off the bounce buffers so they can't hurt anyone anymore. Can you check that you have this patch in your tree? Yours, Linus Walleij
Re: mainline 4.14-rc4: renesas_sdhi_internal_dmac ee100000.sd: swiotlb buffer is full?
On Mon, Oct 16, 2017 at 2:07 PM, Geert Uytterhoeven <ge...@linux-m68k.org> wrote: > On Mon, Oct 16, 2017 at 1:41 PM, Linus Walleij <linus.wall...@linaro.org> > wrote: >> On Mon, Oct 16, 2017 at 11:02 AM, Geert Uytterhoeven >> <ge...@linux-m68k.org> wrote: >>>> IIUC, >>>> - Since the MMC_BOUNCE disappeared in v4.14-rc1, the MMC core will request >>>> a command with 64kbyte+ size. >>>> - So, swiotlb will got request 64kbyte+ size. This is different with >>>> previous version. >> >> Other people reported problems with that. Sorry about this... >> >> This problem should be solved by upstream >> commit de3ee99b097dd51938276e3af388cd4ad0f2750a >> "mmc: Delete bounce buffer handling" >> >> I just killed off the bounce buffers so they can't hurt anyone anymore. >> >> Can you check that you have this patch in your tree? > > Given Dirk saw the issue with v4.14-rc4, I'm afraid that patch is already > included :-( So the first issue is definately gone. Then it seems the driver is specifying to high ->max_seg_size since the buffer cannot be mapped? Unless you're using ADMA drivers/mmc/host/sdhci.c sets it as: mmc->max_seg_size = mmc->max_req_size; And: mmc->max_req_size = 524288; >> renesas_sdhi_internal_dmac ee10.sd: swiotlb_tbl_map_single: test: >> size modified to 524288 bytes >> renesas_sdhi_internal_dmac ee10.sd: swiotlb buffer is full (sz: >> 524288 bytes) So if your driver cannot handle 524288 bytes, why is it saying it can handle 524288 bytes? The MMC core will believe the claim is true, I guess maybe something in the current tree (such as coalesced blocks or whatever) is finally making this size of requests hit the driver (which is a good thing...) just that it was never doing that before and now it turns out it can't really handle that because of how the memory architecture or something works. I guess you need to figure out how big requests/segments this hardware can really handle and pass that to mmc->mas_req_size, mmc->max_seg_size. Sorry if my reasoning is dumb... need more coffee. Yours, Linus Walleij
Re: [PATCH ] gpio: rcar: Add r8a7745 (RZ/G1E) support
On Wed, Aug 16, 2017 at 1:12 PM, Biju Das <biju@bp.renesas.com> wrote: > Renesas RZ/G1E (R8A7745) SoC GPIO blocks are identical to the R-Car Gen2 > family. Add support for its GPIO controllers. > > Signed-off-by: Biju Das <biju@bp.renesas.com> Patch applied with the ACKs Yours, Linus Walleij
Re: [git pull] pinctrl: sh-pfc: Updates for v4.14
On Thu, Aug 17, 2017 at 11:30 AM, Geert Uytterhoeven <geert+rene...@glider.be> wrote: > Hi Linus, > > The following changes since commit 5771a8c08880cdca3bfb4a3fc6d309d6bba20877: > > Linux v4.13-rc1 (2017-07-15 15:22:10 -0700) > > 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.14-tag1 > > for you to fetch changes up to 56d57391ab6720c4b7bbc0a0cbc079c7b7d653fb: > > pinctrl: sh-pfc: r8a77995: Add voltage switch operations for MMC > (2017-08-16 14:26:32 +0200) Pulled into my devel branch for v4.14, excellent work as usual! Yours, Linus Walleij
Re: [PATCH] pinctrl: rza1: Remove suffix from gpiochip label
On Thu, Aug 24, 2017 at 10:52 AM, Jacopo Mondi <jacopo+rene...@jmondi.org> wrote: > The OF node name already contains the gpio chip identifier, no need to > append it when creating the label. > > The following debug message clearly shows the suffix is not required > "pinctrl-rza1 fcfe3000.pin-controller: Parsed gpiochip gpio-0-0 with 6 > pins" > > Signed-off-by: Jacopo Mondi <jacopo+rene...@jmondi.org> Patch applied. Yours, Linus Walleij
Re: [git pull] pinctrl: sh-pfc: Updates for v4.15
On Wed, Oct 4, 2017 at 11:44 AM, Geert Uytterhoeven <geert+rene...@glider.be> wrote: > Hi Linus, > > The following changes since commit 2bd6bf03f4c1c59381d62c61d03f6cc3fe71f66e: > > Linux 4.14-rc1 (2017-09-16 15:47:51 -0700) > > 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.15-tag1 > > for you to fetch changes up to 5ec8a41a36715cf543cb7c109097fb3b4cdfb427: > > pinctrl: sh-pfc: r8a7795: Add USB3.0 host support (2017-10-02 13:23:44 > +0200) Pulled into my devel branch, thanks! Yours, Linus Walleij
Re: [PATCH v3 1/2] pinctrl: rza1: add support for RZ/A1L
On Wed, Oct 4, 2017 at 11:07 PM, Chris Brandt <chris.bra...@renesas.com> wrote: > Aspects like the number of ports and the location where peripherals are > brought out differ between the RZ/A1H and RZ/A1L. > > Signed-off-by: Chris Brandt <chris.bra...@renesas.com> > Reviewed-by: Jacopo Mondi <jacopo+rene...@jmondi.org> > --- > v2: > * added Reviewed-by Looks good, I expect Geert to queue this for me with a pull request like with other Renesas stuff. Yours, Linus Walleij
Re: [PATCH] gpio: pca953x: fix vendor prefix for PCA9654
On Thu, Nov 16, 2017 at 9:18 PM, Sergei Shtylyov
<sergei.shtyl...@cogentembedded.com> wrote:
> Despite commit 55020c8056a8 ("of: Add vendor prefix for ON Semiconductor
> Corp.") was made long ago, the latter commit 9f49f6dd0473 ("gpio: pca953x:
> add onsemi,pca9654 id") made use of another, undocumented vendor prefix.
> Since such prefix doesn't seem to be used in any device trees, I think we
> can just fix the "compatible" string in the driver and the bindings and be
> done with that...
>
> Fixes: 9f49f6dd0473 ("gpio: pca953x: add onsemi,pca9654 id")
> Signed-off-by: Sergei Shtylyov <sergei.shtyl...@cogentembedded.com>
Patch applied with Rob's ACK.
Thanks for spotting this in time.
Yours,
Linus Walleij
Re: [PATCH 3/6] i2c: add 'set_sda' to bus_recovery_info
On Mon, Dec 4, 2017 at 1:36 PM, Wolfram Sang <wsa+rene...@sang-engineering.com> wrote: > This will be needed when we want to create STOP conditions, too, later. > Create the needed fields and populate them for the GPIO case if the GPIO > is set to output. > > Cc: Phil Reid <pr...@electromag.com.au> > Cc: Andy Shevchenko <andriy.shevche...@linux.intel.com> > Cc: Jarkko Nikula <jarkko.nik...@linux.intel.com> > Cc: Claudio Foellmi <claudio.foel...@ergon.ch> > Cc: Andrzej Hajda <a.ha...@samsung.com> > Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com> (...) > #include > +#include Please no. > + if (gpiod_get_direction(bri->sda_gpiod) == > GPIOF_DIR_OUT) > + bri->set_sda = set_sda_gpio_value; Just compare it to zero. if (!gpiod_get_direction()) This flag is only for requesting GPIOs in the old API. We didn't add a define in the new API, it seemed overengineered. Yours, Linus Walleij
Re: [PATCH 3/6] i2c: add 'set_sda' to bus_recovery_info
On Tue, Dec 5, 2017 at 10:57 AM, Phil Reid <pr...@electromag.com.au> wrote: > On 5/12/2017 16:39, Linus Walleij wrote: >> Just compare it to zero. if (!gpiod_get_direction()) >> >> This flag is only for requesting GPIOs in the old API. >> We didn't add a define in the new API, it seemed overengineered. >> > > Perhaps the docs need updating? > as of 4.15-rc2 it says > * Return GPIOF_DIR_IN or GPIOF_DIR_OUT, or an error code in case of error. > > I can submit something if you wish. Hit me. Sorry for the incoherent information. Yours, Linus Walleij
Re: [PATCH] gpio: Add helpers to determin direction of gpiods
On Tue, Dec 12, 2017 at 11:42 PM, Wolfram Sang <w...@the-dreams.de> wrote:
>> Documentation/gpio/consumer.txt | 14 +++---
>
> You need to fix the kerneldoc for 'gpiod_get_direction", too. It still
> mentions GPIOF_DIR_*.
More places? I can't find them!
I thought the patch removed that here:
-This function will return either GPIOF_DIR_IN or GPIOF_DIR_OUT.
+This function will return either 1 (input) or 0 (output). There are also
+these convenience helpers:
I can only find it in Documentation/gpio/gpio-legacy.txt which is
fine.
>> +static inline bool gpiod_is_input(struct gpio_desc *desc)
>> +{
>> + int ret = gpiod_get_direction(desc);
>> + if (ret < 0) {
>> + pr_err("GPIO: failed to get direction\n");
>
> Is that really helpful for the user if we don't say which GPIO failed?
I would have to add yet more APIs to do that.
Hm.
Together with Geert's comments I start to lean towards actually
just creating two new #defines in .
It has the upside that we can also check the return value
for errors.
Yours,
Linus Walleij
Re: [git pull] pinctrl: sh-pfc: Updates for v4.16
On Fri, Dec 15, 2017 at 10:38 AM, Geert Uytterhoeven <geert+rene...@glider.be> wrote: > Hi Linus, > > The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323: > > Linux 4.15-rc1 (2017-11-26 16:01:47 -0800) > > 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.16-tag1 > > for you to fetch changes up to 527890f72892b127b67567af6bdbdc5288c211c1: > > pinctrl: sh-pfc: r8a77995: Add CAN FD support (2017-12-05 14:14:56 +0100) Pulled into my devel branch for v4.16. Thanks for your efforts! Great work as usual. Yours, Linus Walleij
Re: [PATCH v2] gpio: rcar: Add r8a77995 (R-Car D3) support
On Thu, Nov 9, 2017 at 11:39 AM, Geert Uytterhoeven
<geert+rene...@glider.be> wrote:
> From: Yoshihiro Shimoda <yoshihiro.shimoda...@renesas.com>
>
> This patch adds binding for r8a77995 (R-Car D3). This SoC can use
> "renesas,rcar-gen3-gpio" fallback compatibility. So, this patch
> doesn't modify the gpio-rcar driver.
>
> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda...@renesas.com>
> Acked-by: Simon Horman <horms+rene...@verge.net.au>
> Acked-by: Rob Herring <r...@kernel.org>
> Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
> ---
> Linus: it seems this one fell through the cracks, as the later
> f76a2d9d7f9524c5 ("gpio-rcar: document R8A77970 bindings") did get
> applied.
>
> Thx!
>
> v2:
> - Add Acked-by, rebased.
Oopsie. Maybe my oversight.
Patch applied!
Yours,
Linus Walleij
Re: [PATCH v2 1/4] ARM: dts: armadillo800eva: Convert to named i2c-gpio bindings
On Thu, Nov 30, 2017 at 1:57 PM, Geert Uytterhoeven
<geert+rene...@glider.be> wrote:
> Commits 7d29f509d2cfd807 ("dt-bindings: i2c: i2c-gpio: Add support for
> named gpios") and 05c74778858d7d99 ("i2c: gpio: Add support for named
> gpios in DT") introduced named i2c-gpio DT bindings, and deprecated the
> more error-prone unnamed variant.
>
> Switch to the new bindings, and add the missing GPIO_OPEN_DRAIN I/O
> flags, which were implicitly assumed before.
>
> The latter gets rid of the message:
>
> gpio-208 (?): enforced open drain please flag it properly in DT/ACPI
> DSDT/board file
> gpio-91 (?): enforced open drain please flag it properly in DT/ACPI
> DSDT/board file
>
> Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
Reviewed-by: Linus Walleij <linus.wall...@linaro.org>
Yours,
Linus Walleij
Re: [PATCH v2 4/4] ARM: dts: alt: Convert to named i2c-gpio bindings
On Thu, Nov 30, 2017 at 1:57 PM, Geert Uytterhoeven
<geert+rene...@glider.be> wrote:
> Commits 7d29f509d2cfd807 ("dt-bindings: i2c: i2c-gpio: Add support for
> named gpios") and 05c74778858d7d99 ("i2c: gpio: Add support for named
> gpios in DT") introduced named i2c-gpio DT bindings, and deprecated the
> more error-prone unnamed variant.
>
> Switch to the new bindings, and add the missing GPIO_OPEN_DRAIN I/O
> flags, which were implicitly assumed before.
>
> Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
Reviewed-by: Linus Walleij <linus.wall...@linaro.org>
Yours,
Linus Walleij
Re: [PATCH v2 3/4] ARM: dts: koelsch: Convert to named i2c-gpio bindings
On Thu, Nov 30, 2017 at 1:57 PM, Geert Uytterhoeven
<geert+rene...@glider.be> wrote:
> Commits 7d29f509d2cfd807 ("dt-bindings: i2c: i2c-gpio: Add support for
> named gpios") and 05c74778858d7d99 ("i2c: gpio: Add support for named
> gpios in DT") introduced named i2c-gpio DT bindings, and deprecated the
> more error-prone unnamed variant.
>
> Switch to the new bindings, and add the missing GPIO_OPEN_DRAIN I/O
> flags, which were implicitly assumed before.
>
> Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
Reviewed-by: Linus Walleij <linus.wall...@linaro.org>
Yours,
Linus Walleij
Re: [PATCH v2 2/4] ARM: dts: lager: Convert to named i2c-gpio bindings
On Thu, Nov 30, 2017 at 1:57 PM, Geert Uytterhoeven
<geert+rene...@glider.be> wrote:
> Commits 7d29f509d2cfd807 ("dt-bindings: i2c: i2c-gpio: Add support for
> named gpios") and 05c74778858d7d99 ("i2c: gpio: Add support for named
> gpios in DT") introduced named i2c-gpio DT bindings, and deprecated the
> more error-prone unnamed variant.
>
> Switch to the new bindings, and add the missing GPIO_OPEN_DRAIN I/O
> flags, which were implicitly assumed before.
>
> Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
Reviewed-by: Linus Walleij <linus.wall...@linaro.org>
Yours,
Linus Walleij
Re: [PATCH 3/6] i2c: add 'set_sda' to bus_recovery_info
On Thu, Dec 7, 2017 at 12:25 PM, Wolfram Sang <w...@the-dreams.de> wrote: > >> > Two statice inlines in >> > named >> > >> > int gpiod_is output() >> > int gpiod_is_input() >> > >> > should conform to Rusty Russell's API hierarchy. >> >> Yes, sounds good! >> >> > Interested in fixing it, or should I? >> >> Please do. I don't want to add magic numbers to the kernel ;) > > OK? Just slow, sorry. Sent a patch now! Yours, Linus Walleij
Re: [PATCH 3/6] i2c: add 'set_sda' to bus_recovery_info
On Tue, Dec 5, 2017 at 2:38 PM, Wolfram Sang <w...@the-dreams.de> wrote: >> Just compare it to zero. if (!gpiod_get_direction()) > > So, this? > > if (!gpiod_get_direction()) > bri->set_sda = set_sda_gpio_value; > > That looks like "if i couldn't the direction, then...", or? > > Comparing to plain numbers feels like magic values? Hehe :) > Maybe this should be named 'gpiod_is_direction_input()'? Two statice inlines in named int gpiod_is output() int gpiod_is_input() should conform to Rusty Russell's API hierarchy. Interested in fixing it, or should I? I can almost ACK it before you write the patch. Yours, Linus Walleij
Re: [PATCH 1/1] gpio-rcar: use devm_ioremap_resource()
On Thu, Oct 12, 2017 at 11:08 PM, Sergei Shtylyov <sergei.shtyl...@cogentembedded.com> wrote: > Using devm_ioremap_resource() has several advantages over devm_ioremap(): > - it checks the passed resource's validity; > - it calls devm_request_mem_region() to check for the resource overlap; > - it prints an error message in case of error. > > We can call devm_ioremap_resource() instead of devm_ioremap_nocache() > as ioremap() and ioremap_nocache() are implemented identically on ARM. > Doing this saves 2 LoCs and 80 bytes (AArch64 gcc 4.8.5). > > Signed-off-by: Sergei Shtylyov <sergei.shtyl...@cogentembedded.com> Patch applied with Geert's review tag. Sorry for delay, too busy as always. Yours, Linus Walleij
Re: [PATCH] dt-bindings: gpio: rcar: Correct SoC family name for R8A7778
On Tue, Dec 19, 2017 at 5:03 PM, Geert Uytterhoeven <geert+rene...@glider.be> wrote: > R8A7778 is R-Car (not R-Mobile) M1. > > Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be> Patch applied with the ACKs. Yours, Linus Walleij
Re: [PATCH 03/61] auxdisplay: simplify getting .drvdata
On Thu, Apr 19, 2018 at 4:05 PM, Wolfram Sang <wsa+rene...@sang-engineering.com> wrote: > We should get drvdata from struct device directly. Going via > platform_device is an unneeded step back and forth. > > Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com> Acked-by: Linus Walleij <linus.wall...@linaro.org> Sorry for slow reply. Yours, Linus Walleij
Re: [PATCH v6] gpio: dwapb: Add support for 1 interrupt per port A GPIO
On Fri, May 11, 2018 at 10:31 AM, Phil Edworthy <phil.edwor...@renesas.com> wrote: > The DesignWare GPIO IP can be configured for either 1 interrupt or 1 > per GPIO in port A, but the driver currently only supports 1 interrupt. > See the DesignWare DW_apb_gpio Databook description of the > 'GPIO_INTR_IO' parameter. > > This change allows the driver to work with up to 32 interrupts, it will > get as many interrupts as specified in the DT 'interrupts' property. > It doesn't do anything clever with the different interrupts, it just calls > the same handler used for single interrupt hardware. > > Signed-off-by: Phil Edworthy <phil.edwor...@renesas.com> > Reviewed-by: Rob Herring <r...@kernel.org> > Acked-by: Lee Jones <lee.jo...@linaro.org> > --- > One point to mention is that I have made it possible for users to have > unconnected interrupts by specifying holes in the list of interrupts. This is > done by supporting the interrupts-extended DT prop. > However, I have no use for this and had to hack some test case for this. > Perhaps the driver should support 1 interrupt or all GPIOa as interrupts? > > v6: > - Treat DT and ACPI the same as much as possible. Note that we can't use >platform_get_irq() to get the DT interrupts as they are in the port >sub-node and hence do not have an associated platform device. I already applied this patch in some version, can you check what is in my devel branch and send incremental patches on top if something needs changing? https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git/commit/?h=devel=e6ca26abd37606ba4864f20c85d3fe4a2173b93f Sorry for not knowing by heart what was applied or when, it's just too much for me sometimes. Yours, Linus Walleij
Re: [PATCH] gpio: dwapb: Rework support for 1 interrupt per port A GPIO
On Wed, May 23, 2018 at 10:52 AM, Phil Edworthy <phil.edwor...@renesas.com> wrote: > Treat DT and ACPI the same as much as possible. Note that we can't use > platform_get_irq() to get the DT interrupts as they are in the port > sub-node and hence do not have an associated platform device. > > This also fixes a problem introduced with error checking when calling > platform_get_irq(). > > Signed-off-by: Phil Edworthy <phil.edwor...@renesas.com> OK this patch applied! Yours, Linus Walleij
Re: [PATCH] dt-bindings: gpio: rcar: Add support for r8a77990
On Fri, May 11, 2018 at 5:13 AM, Yoshihiro Shimoda <yoshihiro.shimoda...@renesas.com> wrote: > Add compatible string for R-Car E3 (r8a77990) in gpio-rcar. > > Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda...@renesas.com> Quite uncontroversial so, patch applied with Simon's ACK. Yours, Linus Walleij
Re: [git pull] pinctrl: sh-pfc: Updates for v4.18 (take two)
On Wed, May 23, 2018 at 2:56 PM, Geert Uytterhoeven <geert+rene...@glider.be> wrote: > Hi Linus, > > The following changes since commit 73dacc3403436fc246258c0933e35b6e809640ac: > > pinctrl: sh-pfc: Add r8a77470 PFC support (2018-05-16 13:32:15 +0200) > > 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.18-tag2 > > for you to fetch changes up to db701f4bea09a0f9925e262753444e848c33af89: > > pinctrl: sh-pfc: rcar-gen3: Fix grammar in static pin comments (2018-05-23 > 14:43:49 +0200) Pulled into my "devel" branch for v4.18, thanks! Yours, Linus Walleij
Re: [PATCH] gpio: dwapb: Fix rework support for 1 interrupt per port A GPIO
On Fri, May 25, 2018 at 5:11 PM, Phil Edworthy
<phil.edwor...@renesas.com> wrote:
> Commit da069d5d2b814d9887989dcdb29fb0202eac8b38 ("gpio: dwapb: Rework
> support for 1 interrupt per port A GPIO"), was an incremental patch that
> was supposed to provide the delta between v5 and v6 patch set for
> adding support for 1 interupt per port A GPIO. v5 was applied, then some
> other feedback came afterwards.
>
> However, in my haste I managed to drop the changes made to dwapb_port_property
> struct. This patch includes those missing changes.
>
> Signed-off-by: Phil Edworthy <phil.edwor...@renesas.com>
Patch applied!
Yours,
Linus Walleij
Re: [PATCH] pci: fix I/O space page leak
On Wed, Jun 20, 2018 at 7:51 PM Sergei Shtylyov
wrote:
> When testing the R-Car PCIe driver on the Condor board, I noticed that iff
> I left the PCIe PHY driver disabled, the kernel crashed with this BUG:
>
> [1.225819] kernel BUG at lib/ioremap.c:72!
> [1.230007] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
> [1.235496] Modules linked in:
> [1.238561] CPU: 0 PID: 39 Comm: kworker/0:1 Not tainted 4.17.0-dirty #1092
> [1.245526] Hardware name: Renesas Condor board based on r8a77980 (DT)
> [1.252075] Workqueue: events deferred_probe_work_func
> [1.257220] pstate: 8005 (Nzcv daif -PAN -UAO)
> [1.262024] pc : ioremap_page_range+0x370/0x3c8
> [1.266558] lr : ioremap_page_range+0x40/0x3c8
> [1.271002] sp : 08da39e0
> [1.274317] x29: 08da39e0 x28: 00e80f07
> [1.279636] x27: 7dfffee0 x26: 0140
> [1.284954] x25: 7dfffef0 x24: 000fe100
> [1.290272] x23: 80007b906000 x22: 08ab8000
> [1.295590] x21: 08bb1d58 x20: 7dfffef0
> [1.300909] x19: 89c30fb8 x18: 0001
> [1.306226] x17: 000152d0 x16: 014012d0
> [1.311544] x15: x14: 0720072007200720
> [1.316862] x13: 0720072007200720 x12: 0720072007200720
> [1.322180] x11: 0720072007300730 x10: 00ae
> [1.327498] x9 : x8 : 7d00
> [1.332816] x7 : x6 : 0100
> [1.338134] x5 : x4 : 7b906000
> [1.343452] x3 : 80007c61a880 x2 : 7dfffeef
> [1.348770] x1 : 4000 x0 : 00e8fe100f07
> [1.354090] Process kworker/0:1 (pid: 39, stack limit = 0x(ptrval))
> [1.361056] Call trace:
> [1.363504] ioremap_page_range+0x370/0x3c8
> [1.367695] pci_remap_iospace+0x7c/0xac
> [1.371624] pci_parse_request_of_pci_ranges+0x13c/0x190
> [1.376945] rcar_pcie_probe+0x4c/0xb04
> [1.380786] platform_drv_probe+0x50/0xbc
> [1.384799] driver_probe_device+0x21c/0x308
> [1.389072] __device_attach_driver+0x98/0xc8
> [1.393431] bus_for_each_drv+0x54/0x94
> [1.397269] __device_attach+0xc4/0x12c
> [1.401107] device_initial_probe+0x10/0x18
> [1.405292] bus_probe_device+0x90/0x98
> [1.409130] deferred_probe_work_func+0xb0/0x150
> [1.413756] process_one_work+0x12c/0x29c
> [1.417768] worker_thread+0x200/0x3fc
> [1.421522] kthread+0x108/0x134
> [1.424755] ret_from_fork+0x10/0x18
> [1.428334] Code: f9004ba2 5480 aa0003fb 1748 (d421)
>
> It turned out that pci_remap_iospace() wasn't undone when the driver's
> probe failed, and since devm_phy_optional_get() returned -EPROBE_DEFER,
> the probe was retried, finally causing the BUG due to trying to remap
> already remapped pages.
>
> The most feasible solution seems to introduce devm_pci_remap_iospace()
> and call it instead of pci_remap_iospace(), so that the pages get unmapped
> automagically on any probe failure.
>
> And while fixing pci_parse_request_of_pci_ranges(), aslo fix the other
> drivers that have probably copied the bad example...
>
> Fixes: 4e64dbe226e7 ("PCI: generic: Expose pci_host_common_probe() for use by
> other drivers")
> Fixes: cbce7900598c ("PCI: designware: Make driver arch-agnostic")
> Fixes: 8c39d710363c ("PCI: aardvark: Add Aardvark PCI host controller driver")
> Fixes: d3c68e0a7e34 ("PCI: faraday: Add Faraday Technology FTPCI100 PCI Host
> Bridge driver")
> Fixes: 68a15eb7bd0c ("PCI: v3-semi: Add V3 Semiconductor PCI host driver")
> Fixes: b7e78170efd4 ("PCI: versatile: Add DT-based ARM Versatile PB PCIe host
> driver")
> Fixes: 5f6b6ccdbe1c ("PCI: xgene: Add APM X-Gene PCIe driver")
> Fixes: 637cfacae96f ("PCI: mediatek: Add MediaTek PCIe host controller
> support")
> Signed-off-by: Sergei Shtylyov
> Cc: sta...@vger.kernel.org
Nice, clean and thorough fix!
Reviewed-by: Linus Walleij
Yours,
Linus Walleij
Re: [RFC PATCH] i2c: gpio: initialize SCL to HIGH again
On Mon, Jun 25, 2018 at 4:30 PM Wolfram Sang wrote:
> On Sat, Jun 16, 2018 at 09:56:36PM +0900, Wolfram Sang wrote:
> > It seems that during the conversion from gpio* to gpiod*, the initial
> > state of SCL was wrongly switched to LOW. Fix it to be HIGH again.
> >
> > Fixes: 7bb75029ef34 ("i2c: gpio: Enforce open drain through gpiolib")
> > Signed-off-by: Wolfram Sang
> > ---
> >
> > Linus: Or was it intentional? But then I am missing something... I found
> > this
> > by trying to fix a regression. I can't scope my use case now because I am on
> > the road. I recall SCL being unexpectedly LOW when using the GPIO fault
> > injector the last time, though. This made me do a fix in the underlying
> > i2c-algo-bit algorithm, but that sadly caused a regression :( So, this may
> > be
> > the proper fix. RFC for now, until I have my scope back. But discussion is
> > welcome.
>
> Linus: any comment?
Looks like a mistake on my part. Mea culpa :(
Luckily it is functionally mostly harmless, but to
conserve power, it is better to initialize this as high (lest
we dissipate power throught the pull-up resistor), so please queue
this as a fix and also tag for stable.
Reviewed-by: Linus Walleij
Yours,
Linus Walleij
Re: [PATCH v5] gpio: dwapb: Add support for 1 interrupt per port A GPIO
On Thu, Apr 26, 2018 at 6:19 PM, Phil Edworthy <phil.edwor...@renesas.com> wrote: > The DesignWare GPIO IP can be configured for either 1 interrupt or 1 > per GPIO in port A, but the driver currently only supports 1 interrupt. > See the DesignWare DW_apb_gpio Databook description of the > 'GPIO_INTR_IO' parameter. > > This change allows the driver to work with up to 32 interrupts, it will > get as many interrupts as specified in the DT 'interrupts' property. > It doesn't do anything clever with the different interrupts, it just calls > the same handler used for single interrupt hardware. > > ACPI companion code provided by Hoan Tran <hot...@apm.com>. This was tested > on X-Gene by Hoan. > > Signed-off-by: Phil Edworthy <phil.edwor...@renesas.com> > Reviewed-by: Rob Herring <r...@kernel.org> > Acked-by: Lee Jones <lee.jo...@linaro.org> Patch applied for v4.18 with Hoan's ACK. Yours, Linus Walleij
Re: [PATCH v2] dt-bindings: gpio: Add support for r8a77965
On Mon, Apr 16, 2018 at 8:55 PM, Jacopo Mondi <jacopo+rene...@jmondi.org> wrote: > Add compatible string for R-Car M3-N (r8a77965) in gpio-rcar. > > Signed-off-by: Jacopo Mondi <jacopo+rene...@jmondi.org> > Reviewed-by: Geert Uytterhoeven <geert+rene...@glider.be> > Reviewed-by: Simon Horman <horms+rene...@verge.net.au> > Reviewed-by: Rob Herring <r...@kernel.org> > --- > > Renesas R-Car M3-N support has been merged for v4.17. > Document the missing device tree bindings. > > v1 -> v2: > - Add Simon and Rob Reviewed-by tags Patch applied. Yours, Linus Walleij
Re: [PATCH] dt-bindings: gpio: rcar: Add r8a77470 (RZ/G1C) support
On Tue, Apr 24, 2018 at 10:27 AM, Biju Das <biju@bp.renesas.com> wrote: > Renesas RZ/G1C (R8A77470) SoC GPIO blocks are identical to the R-Car Gen2 > family. Add support for its GPIO controllers. > > Signed-off-by: Biju Das <biju@bp.renesas.com> > Reviewed-by: Chris Paterson <chris.paters...@renesas.com> Patch applied to the GPIO tree with all the review tags. Yours, Linus Walleij
Re: [PATCH] i2c: busses: remove superfluous ignoring of children for RPM
On Sun, Apr 29, 2018 at 8:41 PM, Wolfram Sang <wsa+rene...@sang-engineering.com> wrote: > These days, the I2C core ensures that the embedded adapter device > ignores the PM states of its children already. Because the adapter > device is an opaque logical device, there is no need for drivers to > repeat that again. > > Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com> Reviewed-by: Linus Walleij <linus.wall...@linaro.org> Yours, Linus Walleij
Re: [PATCH 10/61] gpio: simplify getting .drvdata
On Thu, Apr 19, 2018 at 5:14 PM, Grygorii Strashko <grygorii.stras...@ti.com> wrote: > On 04/19/2018 09:05 AM, Wolfram Sang wrote: >> >> We should get drvdata from struct device directly. Going via >> platform_device is an unneeded step back and forth. >> >> Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com> >> --- >> >> Build tested only. buildbot is happy. Please apply individually. > > > for gpio-omap.c: > Reviewed-by: Grygorii Strashko <grygorii.stras...@ti.com> Hm I only see the responses not the actual patch, I guess I will find it sooner or later. Wolfram: if I don't find it, poke me with something sharp so I get to apply it. Yours, Linus Walleij
Re: [git pull] pinctrl: sh-pfc: Updates for v4.15 (take two)
On Fri, Oct 20, 2017 at 1:25 PM, Geert Uytterhoeven <geert+rene...@glider.be> wrote: > Hi Linus, > > The following changes since commit 5ec8a41a36715cf543cb7c109097fb3b4cdfb427: > > pinctrl: sh-pfc: r8a7795: Add USB3.0 host support (2017-10-02 13:23:44 > +0200) > > 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.15-tag2 Pulled into the pinctrl devel branch. Thanks to all @Renesas, excellent work as usual. Yours, Linus Walleij
Re: [PATCH] pinctrl: sh-pfc: Use seq_puts() in sh_pfc_pin_dbg_show()
On Sat, Jan 6, 2018 at 9:56 PM, SF Markus Elfring <elfr...@users.sourceforge.net> wrote: > From: Markus Elfring <elfr...@users.sourceforge.net> > Date: Sat, 6 Jan 2018 21:50:20 +0100 > > A string which did not contain a data format specification should be put > into a sequence. Thus use the corresponding function "seq_puts". > > This issue was detected by using the Coccinelle software. > > Signed-off-by: Markus Elfring <elfr...@users.sourceforge.net> Leaving to Geert to pick this up. (Looks good.) Yours, Linus Walleij
Re: [PATCH 1/2] gpio: correct docs about return value of gpiod_get_direction
On Tue, Jan 9, 2018 at 12:35 PM, Wolfram Sang <w...@the-dreams.de> wrote: > From: Wolfram Sang <wsa+rene...@sang-engineering.com> > > The use of the GPIOF_* flags is deprecated, so don't advertise them > here. Document the plain numbers for now until we have a better > solution. > > Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com> Patch applied. Yours, Linus Walleij
Re: [PATCH 2/2] Documentation: gpio: correct return value of gpiod_get_direction
On Tue, Jan 9, 2018 at 12:35 PM, Wolfram Sang <w...@the-dreams.de> wrote: > From: Wolfram Sang <wsa+rene...@sang-engineering.com> > > The use of the GPIOF_* flags is deprecated, so don't advertise them > here. Document the plain numbers for now until we have a better > solution. > > Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com> Patch applied. Yours, Linus Walleij
Re: [git pull] pinctrl: sh-pfc: Updates for v4.16 (take two)
On Fri, Jan 5, 2018 at 11:33 AM, Geert Uytterhoeven <geert+rene...@glider.be> wrote: > Hi Linus, > > The following changes since commit 527890f72892b127b67567af6bdbdc5288c211c1: > > pinctrl: sh-pfc: r8a77995: Add CAN FD support (2017-12-05 14:14:56 +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.16-tag2 > > for you to fetch changes up to 297e5b2b7a8398b4b850d6bdb63f3a3544670b9e: > > pinctrl: sh-pfc: r8a7795: Add SATA pins, groups, and functions (2017-12-21 > 10:08:23 +0100) Pulled to my devel branch for v4.16, thanks! Yours, Linus Walleij
Re: [PATCH v2 3/6] i2c: add 'set_sda' to bus_recovery_info
On Tue, Jan 9, 2018 at 2:58 PM, Wolfram Sang <w...@the-dreams.de> wrote: > From: Wolfram Sang <wsa+rene...@sang-engineering.com> > > This will be needed when we want to create STOP conditions, too, later. > Create the needed fields and populate them for the GPIO case if the GPIO > is set to output. > > Tested-by: Phil Reid <pr...@electromag.com.au> > Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com> Reviewed-by: Linus Walleij <linus.wall...@linaro.org> Geert pointed out a bug in *_cansleep() so I have merged his fix for v4.15. Everything "should be smooth". > + /* FIXME: add proper flag instead of '0' once > available */ > + if (gpiod_get_direction(bri->sda_gpiod) == 0) Yeah I should fix ... I suspect I need to do something kernel-wide to shape this up. Yours, Linus Walleij
Re: [PATCH] gpio: Add missing open drain/source handling to gpiod_set_value_cansleep()
On Tue, Jan 9, 2018 at 7:08 PM, Geert Uytterhoeven
<geert+rene...@glider.be> wrote:
> Since commit f11a04464ae57e8d ("i2c: gpio: Enable working over slow
> can_sleep GPIOs"), probing the i2c RTC connected to an i2c-gpio bus on
> r8a7740/armadillo fails with:
>
> rtc-s35390a 0-0030: error resetting chip
> rtc-s35390a: probe of 0-0030 failed with error -5
>
> More debug code reveals:
>
> i2c i2c-0: master_xfer[0] R, addr=0x30, len=1
> i2c i2c-0: NAK from device addr 0x30 msg #0
> s35390a_get_reg: ret = -6
>
> Commit 02e479808b5d62f8 ("gpio: Alter semantics of *raw* operations to
> actually be raw") moved open drain/source handling from
> gpiod_set_raw_value_commit() to gpiod_set_value(), but forgot to take
> into account that gpiod_set_value_cansleep() also needs this handling.
> The i2c protocol mandates that i2c signals are open drain, hence i2c
> communication fails.
>
> Fix this by adding the missing handling to gpiod_set_value_cansleep(),
> using a new common helper __gpiod_set_value_nocheck().
>
> Fixes: 02e479808b5d62f8 ("gpio: Alter semantics of *raw* operations to
> actually be raw")
> Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
> ---
> The bad gpio commit is in v4.15-rc1 and later.
> The i2c commit exposing this is not yet upstream, but in i2c/for-next.
Whoops!
It appears Meltdown and Spectre saves my ass because now I have
time to get this upstream before v4.15...
Applied for fixes with the following tweaks: I removed the __prefix (I don't
like them) and added kerneldoc.
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 1693bb9ab72c..14532d9576e4 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -2892,7 +2892,16 @@ void gpiod_set_raw_value(struct gpio_desc
*desc, int value)
}
EXPORT_SYMBOL_GPL(gpiod_set_raw_value);
-static void __gpiod_set_value_nocheck(struct gpio_desc *desc, int value)
+/**
+ * gpiod_set_value_nocheck() - set a GPIO line value without checking
+ * @desc: the descriptor to set the value on
+ * @value: value to set
+ *
+ * This sets the value of a GPIO line backing a descriptor, applying
+ * different semantic quirks like active low and open drain/source
+ * handling.
+ */
+static void gpiod_set_value_nocheck(struct gpio_desc *desc, int value)
{
if (test_bit(FLAG_ACTIVE_LOW, >flags))
value = !value;
@@ -2919,7 +2928,7 @@ void gpiod_set_value(struct gpio_desc *desc, int value)
{
VALIDATE_DESC_VOID(desc);
WARN_ON(desc->gdev->chip->can_sleep);
- __gpiod_set_value_nocheck(desc, value);
+ gpiod_set_value_nocheck(desc, value);
}
EXPORT_SYMBOL_GPL(gpiod_set_value);
@@ -3247,7 +3256,7 @@ void gpiod_set_value_cansleep(struct gpio_desc
*desc, int value)
{
might_sleep_if(extra_checks);
VALIDATE_DESC_VOID(desc);
- __gpiod_set_value_nocheck(desc, value);
+ gpiod_set_value_nocheck(desc, value);
}
EXPORT_SYMBOL_GPL(gpiod_set_value_cansleep);
Yours,
Linus Walleij
Re: [PATCH/RFT v4] gpio: gpio-rcar: Support S2RAM
On Sun, Feb 4, 2018 at 8:15 PM, Yoshihiro Kaneko <ykaneko0...@gmail.com> wrote: > From: Hien Dang <hien.dang...@renesas.com> > > This patch adds an implementation that saves and restores the state of > GPIO configuration on suspend and resume. > > Signed-off-by: Hien Dang <hien.dang...@renesas.com> > Signed-off-by: Takeshi Kihara <takeshi.kihara...@renesas.com> > [Modify structure of the bank info to simplify a saving registers] > [Remove DEV_PM_OPS macro] > Signed-off-by: Yoshihiro Kaneko <ykaneko0...@gmail.com> This v4 version applied with Tested- and reviewed tags. Yours, Linus Walleij
Re: [PATCH v3 3/3] gpio: rcar: Use wakeup_path i.s.o. explicit clock handling
On Mon, Feb 12, 2018 at 2:55 PM, Geert Uytterhoeven
<geert+rene...@glider.be> wrote:
> Since commit ab82fa7da4dce5c7 ("gpio: rcar: Prevent module clock disable
> when wake-up is enabled"), when a GPIO is used for wakeup, the GPIO
> block's module clock (if exists) is manually kept running during system
> suspend, to make sure the device stays active.
>
> However, this explicit clock handling is merely a workaround for a
> failure to properly communicate wakeup information to the device core.
>
> Instead, set the device's power.wakeup_path field, to indicate this
> device is part of the wakeup path. Depending on the PM Domain's
> active_wakeup configuration, the genpd core code will keep the device
> enabled (and the clock running) during system suspend when needed.
> This allows for the removal of all explicit clock handling code from the
> driver.
>
> Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
Acked-by: Linus Walleij <linus.wall...@linaro.org>
Can I apply this and only this patch to GPIO?
Should it be applied for fixes, next?
Else please funnel this through the irqchip tree with my
ACK.
Yours,
Linus Walleij
Re: [PATCH v2 3/3] gpio: rcar: Use WAKEUP_PATH driver PM flag
On Fri, Dec 29, 2017 at 2:31 PM, Ulf Hansson <ulf.hans...@linaro.org> wrote:
> From: Geert Uytterhoeven <geert+rene...@glider.be>
>
> Since commit ab82fa7da4dce5c7 ("gpio: rcar: Prevent module clock disable
> when wake-up is enabled"), when a GPIO is used for wakeup, the GPIO block's
> module clock (if exists) is manually kept running during system suspend, to
> make sure the device stays active.
>
> However, this explicit clock handling is merely a workaround for a failure
> to properly communicate wakeup information to the PM core. Instead, set the
> WAKEUP_PATH driver PM flag to indicate that the device is part of the
> wakeup path, which further also enables middle-layers and PM domains (like
> genpd) to act on this.
>
> In case the device is attached to genpd and depending on if it has an
> active wakeup configuration, genpd will keep the device active (the clock
> running) during system suspend when needed. This enables us to remove all
> explicit clock handling code from the driver, so let's do that as well.
>
> Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
> [Ulf: Converted to use the WAKEUP_PATH driver PM flag]
> Signed-off-by: Ulf Hansson <ulf.hans...@linaro.org>
Acked-by: Linus Walleij <linus.wall...@linaro.org>
I guess it is dependent on the other patches?
If you want me to just apply it to the GPIO tree, tell me.
Yours,
Linus Walleij
Re: [PATCH] gpiolib: use better errno if get_direction is not available
On Wed, Jul 25, 2018 at 10:20 PM Wolfram Sang wrote: > > That all being said, I think this patch is still useful as is. > > Linus, do you have time to comment on this? This looks like a good solution to me. Reviewed-by: Linus Walleij Yours, Linus Walleij
Re: [PATCH 07/12] i2c: stu300: use core to detect 'no zero length' quirk
On Mon, Jul 23, 2018 at 10:26 PM Wolfram Sang wrote: > And don't reimplement in the driver. > > Signed-off-by: Wolfram Sang Reviewed-by: Linus Walleij Yours, Linus Walleij
Re: [PATCH] gpiolib: Avoid calling chip->request() for unused gpios
On Tue, Aug 7, 2018 at 9:21 AM Biju Das wrote: > Add a check for unused gpios to avoid chip->request() call to client > driver for unused gpios. > > Signed-off-by: Biju Das > Reviewed-by: Fabrizio Castro Patch applied with Geert's ACK. Yours, Linus Walleij
Re: [PATCH 0/2] Add R8A774A1 PFC support
On Mon, Aug 13, 2018 at 3:58 PM Biju Das wrote: > This patch series aims to add PFC support for RZ/G2M SoC. Looks good to me, Geert will queue the patches when he's happy. Yours, Linus Walleij
Re: [PATCH] gpiolib: Fix of_node inconsistency
On Mon, Aug 6, 2018 at 11:53 AM Biju Das wrote: > Some platforms are not setting of_node in the driver. On these platforms > defining gpio-reserved-ranges on device tree leads to kernel crash. > > It is due to some parts of the gpio core relying on the driver to set up > of_node,while other parts do themselves.This inconsistent behaviour leads > to a crash. > > gpiochip_add_data_with_key() calls gpiochip_init_valid_mask() with of_node > as NULL. of_gpiochip_add() fills "of_node" and calls > of_gpiochip_init_valid_mask(). > > The fix is to move the assignment to chip->of_node from of_gpiochip_add() > to gpiochip_add_data_with_key(). > > Signed-off-by: Biju Das After reading through context this seems like the right fix so patch applied! In the long run I want to get rid of this extra of_node in the chip, but it kind of requires every driver in the kernel to pass in a valid parent device representing the OF node. And there are so many hairy corner cases where they don't. Yours, Linus Walleij
Re: [PATCH v2 2/5] dt-bindings: gpio: rcar: Add gpio-reserved-ranges support
Hi Biju! Thanks for the patches and sorry for slow feedback. Luckily you have Geert to help out and I can see this is already getting in nice shape. On Thu, Aug 2, 2018 at 4:17 PM Biju Das wrote: > Update the DT bindings documentation with the optional gpio-reserved-ranges > properties. > > Signed-off-by: Biju Das > Reviewed-by: Fabrizio Castro (...) > + - gpio-reserved-ranges: Set of tuples to specify the unused GPIOs.This > +property indicates the start and size of the GPIOs that can't be used. > + > Please refer to gpio.txt in this directory for details of gpio-ranges > property > and the common GPIO bindings used by client devices. You see it yourself if you look at the context below: just refer to the existing documentation in gpio.txt as this is a standard bindings. The absolutely best (IIUC) is: gpio-ranges: See gpio.txt gpio-reserved-ranges: See gpio.txt Maybe you could add an extra example using the reserved ranges? Yours, Linus Walleij
Re: [PATCH v3 2/5] dt-bindings: gpio: rcar: Add gpio-reserved-ranges support
On Tue, Aug 7, 2018 at 10:03 AM Biju Das wrote: > Update the DT bindings documentation with the optional gpio-reserved-ranges > properties. > > Signed-off-by: Biju Das > Reviewed-by: Fabrizio Castro Patch applied with the ACKs. Yours, Linus Walleij
Re: [PATCH v3 1/5] gpio: rcar: Add GPIO hole support
On Tue, Aug 7, 2018 at 10:03 AM Biju Das wrote: > GPIO hole is present in RZ/G1C SoC. Valid GPIO pins on bank3 are in the > range GP3_0 to GP3_16 and GP3_27 to GP3_29. The GPIO pins between GP3_17 > to GP3_26 are unused. Add support for handling unused GPIO's. > > Signed-off-by: Biju Das Patch applied with Geert's review tag. Yours, Linus Walleij
Re: [git pull] pinctrl: sh-pfc: Updates for v4.20
On Fri, Aug 31, 2018 at 3:07 PM Geert Uytterhoeven wrote: > The following changes since commit 5b394b2ddf0347bef56e50c69a58773c94343ff3: > > Linux 4.19-rc1 (2018-08-26 14:11:59 -0700) > > 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.20-tag1 > > for you to fetch changes up to 2ed03c835d6f4dbe9f0d093187825d1c0e2e9b39: > > pinctrl: sh-pfc: r8a77990: Add DU pins, groups and function (2018-08-30 > 14:17:20 +0200) Pulled into pinctrl "devel" branch, thanks! Yours, Linus Walleij
Re: [PATCH V2 RESEND] gpio: of: make example syntactically correct
On Sun, Jan 21, 2018 at 1:12 PM Wolfram Sang wrote: > The ';' was missing. And cosmetic: there was a space too much. > > Signed-off-by: Wolfram Sang > Reviewed-by: Niklas Söderlund > --- > > No changes since V2, only Niklas' tag added. Patch applied with Geert's ACK. Yours, Linus Walleij
Re: [PATCH] gpio: rcar: Implement .get_direction() callback
On Thu, Jul 12, 2018 at 11:31 AM Geert Uytterhoeven wrote: > Allow gpiolib to read back the current I/O direction configuration by > implementing the .get_direction() callback. > > Signed-off-by: Geert Uytterhoeven Patch applied with the tags! Yours, Linus Walleij
Re: [PATCH v2] pinctrl: sh-pfc: r8a77970: remove SH_PFC_PIN_CFG_DRIVE_STRENGTH flag
On Tue, Jul 3, 2018 at 5:19 PM Niklas Söderlund
wrote:
> The datasheet does not document any registers to control drive strength,
> and no drive strength registers are for this reason described for this
> SoC. The flags indicating that drive strength can be controlled are
> however set for some pins in the driver.
>
> This leads to a NULL pointer dereference when the sh-pfc core tries to
> access the struct describing the drive strength registers, for example
> when reading the sysfs file pinconf-pins.
>
> Fix this by removing the SH_PFC_PIN_CFG_DRIVE_STRENGTH from all pins.
>
> Fixes: b92ac66a1819602b ("pinctrl: sh-pfc: Add R8A77970 PFC support")
> Signed-off-by: Niklas Söderlund
> Reviewed-by: Simon Horman
> Reviewed-by: Sergei Shtylyov
> Reviewed-by: Geert Uytterhoeven
Patch applied directly for fixes per Geert's suggestion.
Yours,
Linus Walleij
Re: [git pull] pinctrl: sh-pfc: Updates for v4.19
On Wed, Jul 4, 2018 at 11:45 AM Geert Uytterhoeven wrote: > The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40: > > Linux 4.18-rc1 (2018-06-17 08:04:49 +0900) > > 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.19-tag1 > > for you to fetch changes up to a742fcf72902ed28f8836b8327cde50bebfb9ff1: > > pinctrl: sh-pfc: r8a77990: Add USB3.0 pins, groups and functions > (2018-07-04 11:05:29 +0200) Pulled into my "devel" branch, thanks for excellent work as usual! Yours, Linus Walleij
Re: [PATCH] pinctrl: sh-pfc: r8a7795: remove duplicate of CLKOUT pin in pinmux_pins[]
On Thu, Feb 22, 2018 at 10:10 AM, Geert Uytterhoeven <ge...@linux-m68k.org> wrote: >> Signed-off-by: Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se> > > Reviewed-and-tested-by: Geert Uytterhoeven <geert+rene...@glider.be> > > Linus: As the offending patch is only in v4.16-rc1 and later, can you please > take it directly as a fix for v4.16? > > https://patchwork.kernel.org/patch/10234351/ OK I pulled this out of patchwork and applied for fixes. Yours, Linus Walleij
Re: [PATCH v3 3/3] gpio: rcar: Use wakeup_path i.s.o. explicit clock handling
On Mon, Feb 12, 2018 at 2:55 PM, Geert Uytterhoeven
<geert+rene...@glider.be> wrote:
> Since commit ab82fa7da4dce5c7 ("gpio: rcar: Prevent module clock disable
> when wake-up is enabled"), when a GPIO is used for wakeup, the GPIO
> block's module clock (if exists) is manually kept running during system
> suspend, to make sure the device stays active.
>
> However, this explicit clock handling is merely a workaround for a
> failure to properly communicate wakeup information to the device core.
>
> Instead, set the device's power.wakeup_path field, to indicate this
> device is part of the wakeup path. Depending on the PM Domain's
> active_wakeup configuration, the genpd core code will keep the device
> enabled (and the clock running) during system suspend when needed.
> This allows for the removal of all explicit clock handling code from the
> driver.
>
> Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
> ---
> v3:
Patch applied for v4.16 fixes.
Yours,
Linus Walleij
Re: [git pull] pinctrl: sh-pfc: Updates for v4.17 (take two)
On Thu, Mar 22, 2018 at 6:09 PM, Geert Uytterhoeven <geert+rene...@glider.be> wrote: > Hi Linus, > > The following changes since commit a8ab4f2bd8a5298679dabe16910322625a0df247: > > pinctrl: sh-pfc: r8a77965: Add support for INTC-EX IRQ pins (2018-02-28 > 09:17:54 +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.17-tag2 > > for you to fetch changes up to a6fff41f410bf030d5cd178154b8397536e714f9: > > pinctrl: sh-pfc: r8a77995: Deduplicate VIN4 pin definitions (2018-03-21 > 18:25:48 +0100) Pulled to the pin control "devel" branch, good work! Yours, Linus Walleij
Re: [RFC][PATCH 04/11] drm: Split the display info into static and dynamic parts
On Tue, Feb 27, 2018 at 1:56 PM, Ville Syrjala <ville.syrj...@linux.intel.com> wrote: > From: Ville Syrjälä <ville.syrj...@linux.intel.com> > > Currently we have a mix of static and dynamic information stored in > the display info structure. That makes it rather difficult to repopulate > the dynamic parts when a new EDID appears. Let's make life easier by > splitting the structure up into static and dynamic parts. > > The static part will consist of subpixel_order, panel_orientation, > and bus_formats. > > Actually I'm not sure where bus_formats & co. fit in all this. For some > drivers those seem to be static, even though they might fill them out > from .get_modes(). For other drivers this stuff even gets frobbed at > runtime, making it more some kind of a bastard encoder/connector state. > I'll just stick it into the static side so that the behaviour doesn't > change when I start clear out the entire dynamic state with memset(). > > Cc: Keith Packard <kei...@keithp.com> > Cc: Daniel Vetter <daniel.vet...@ffwll.ch> > Cc: Hans de Goede <hdego...@redhat.com> > Cc: Shashank Sharma <shashank.sha...@intel.com> > Cc: Stefan Agner <ste...@agner.ch> > Cc: Thierry Reding <thierry.red...@gmail.com> > Cc: Boris Brezillon <boris.brezil...@bootlin.com> > Cc: Philipp Zabel <p.za...@pengutronix.de> > Cc: Laurent Pinchart <laurent.pinch...@ideasonboard.com> > Cc: Manfred Schlaegl <manfred.schla...@gmx.at> > Cc: Marek Vasut <ma...@denx.de> > Cc: Archit Taneja <arch...@codeaurora.org> > Cc: Andrzej Hajda <a.ha...@samsung.com> > Cc: Alison Wang <alison.w...@freescale.com> > Cc: Eric Anholt <e...@anholt.net> > Cc: Linus Walleij <linus.wall...@linaro.org> > Cc: linux-renesas-soc@vger.kernel.org > Cc: Maxime Ripard <maxime.rip...@bootlin.com> > Signed-off-by: Ville Syrjälä <ville.syrj...@linux.intel.com> Acked-by: Linus Walleij <linus.wall...@linaro.org> Yours, Linus Walleij
Re: [PATCH v3 3/3] gpio: rcar: Use wakeup_path i.s.o. explicit clock handling
On Fri, Mar 2, 2018 at 9:20 AM, Geert Uytterhoeven <ge...@linux-m68k.org> wrote:
>
> On Thu, Mar 1, 2018 at 5:06 PM, Linus Walleij <linus.wall...@linaro.org>
> wrote:
>> On Mon, Feb 12, 2018 at 2:55 PM, Geert Uytterhoeven
>> <geert+rene...@glider.be> wrote:
>>
>>> Since commit ab82fa7da4dce5c7 ("gpio: rcar: Prevent module clock disable
>>> when wake-up is enabled"), when a GPIO is used for wakeup, the GPIO
>>> block's module clock (if exists) is manually kept running during system
>>> suspend, to make sure the device stays active.
>>>
>>> However, this explicit clock handling is merely a workaround for a
>>> failure to properly communicate wakeup information to the device core.
>>>
>>> Instead, set the device's power.wakeup_path field, to indicate this
>>> device is part of the wakeup path. Depending on the PM Domain's
>>> active_wakeup configuration, the genpd core code will keep the device
>>> enabled (and the clock running) during system suspend when needed.
>>> This allows for the removal of all explicit clock handling code from the
>>> driver.
>>>
>>> Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
>>> ---
>>> v3:
>>
>> Patch applied for v4.16 fixes.
>
> Are you aware this conflicts with commit 51750fb167a05468 ("gpio: gpio-rcar:
> Support S2RAM") in gpio/for-next?
No but I guess I will become aware.
I have not yet mixed the fixes and devel branches for next.
> You can find the resolution in
> https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git/tree/drivers/gpio/gpio-rcar.c?h=renesas-drivers-2018-02-28-v4.16-rc3
Thanks!
Yours,
Linus Walleij
Re: [git pull] pinctrl: sh-pfc: Updates for v4.17
On Fri, Mar 2, 2018 at 11:18 AM, Geert Uytterhoeven <geert+rene...@glider.be> wrote: > Hi Linus, > > The following changes since commit 7928b2cbe55b2a410a0f5c1f154610059c57b1b2: > > Linux 4.16-rc1 (2018-02-11 15:04:29 -0800) > > 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.17-tag1 > > for you to fetch changes up to a8ab4f2bd8a5298679dabe16910322625a0df247: > > pinctrl: sh-pfc: r8a77965: Add support for INTC-EX IRQ pins (2018-02-28 > 09:17:54 +0100) Pulled into the pinctrl devel branch for v4.17! Excellent job as usual! And I'm amazed that Renesas manage to churn out so many ASICs. Yours, Linus Walleij
Re: [PATCH v3] gpio: dwapb: Add support for 1 interrupt per port A GPIO
On Thu, Apr 19, 2018 at 12:03 PM, Phil Edworthy <phil.edwor...@renesas.com> wrote: > Since I've already got some reviewed-by and acks for v4, I'll leave it to > Linus > to decide if he wants me to roll your changes into this patch or for you to > submit a separate patch. Just - Add the reviewed-by and ACKs - Fold in Hoan's fix - Resend We are always a bit fuzzy around the edges with carrying ACKs etc forward for new revisions. Surely that is fine with this minor revision for ACPI. Yours, Linus Walleij
Re: [RFC] gpio: rcar: Request GPIO before enabling interrupt
On Fri, Oct 26, 2018 at 9:57 PM Fabrizio Castro wrote: > There are cases when the bootloader configures a pin to work > as a function rather than GPIO, and other cases when the pin > is configured as a function at POR. > This commit makes sure the pin is configured as a GPIO the > moment we need it to work as an interrupt. > > Signed-off-by: Fabrizio Castro (...) > + err = gc->request(gc, hwirq); This is done in some drivers when what you want is exactly the work carried out by that callback. But can't you just call gpio_rcar_request() directly in this case so it is clear that the driver is meddling with the internal state of the hardware and not really intending to loop out into the external API or external callbacks? You're not on one of these platforms that prefer setting up the pin as GPIO using a pin control hog in the device tree? Sadly there is sometimes more than one way to do things around here :/ Geert will know what is best. Yours, Linus Walleij
Re: [PATCH] MAINTAINERS: Add Renesas RZ/A and RZ/N files to Renesas pinctrl section
On Tue, Oct 16, 2018 at 3:24 PM Geert Uytterhoeven wrote: > Add paths for the Renesas RZ/A and RZ/N series pin controller drivers, > as they are not under sh-pfc/, but still maintained with the other > Renesas pin controller drivers. > > Signed-off-by: Geert Uytterhoeven Acked-by: Linus Walleij Yours, Linus Walleij
Re: [git pull] pinctrl: sh-pfc: Updates for v4.20 (take three)
On Fri, Oct 5, 2018 at 1:57 PM Geert Uytterhoeven wrote: > The following changes since commit a97f340c0a071bcb32ff68f3d19cf56a76887288: > > pinctrl: sh-pfc: rcar: Rename automotive-only arrays to automotive > (2018-09-28 09:49:15 +0200) > > 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.20-tag3 > > for you to fetch changes up to ef26d96023a4c34b1bcc4294f570df2b63a1b952: Pulled into the pinctrl "devel" branch, thanks! Yours, Linus Walleij
Re: [git pull] pinctrl: sh-pfc: Updates for v4.20 (take two)
On Fri, Sep 28, 2018 at 10:41 AM Geert Uytterhoeven wrote: > The following changes since commit 2ed03c835d6f4dbe9f0d093187825d1c0e2e9b39: > > pinctrl: sh-pfc: r8a77990: Add DU pins, groups and function (2018-08-30 > 14:17:20 +0200) > > 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.20-tag2 > > for you to fetch changes up to a97f340c0a071bcb32ff68f3d19cf56a76887288: > > pinctrl: sh-pfc: rcar: Rename automotive-only arrays to automotive > (2018-09-28 09:49:15 +0200) Pulled into my "devel" branch now, thanks! Yours, Linus Walleij
Re: [RFC v3 1/2] pinctrl: core: Add pinctrl_mux_gpio_request_enable
On Tue, Nov 20, 2018 at 4:19 PM Fabrizio Castro wrote: > Sometimes there is the need to change the muxing of a pin to make it > a GPIO without going through gpiolib. > This patch adds pinctrl_mux_gpio_request_enable to deal with this new > use case from code that has nothing to do with pinctrl. It has a lot to do with pinctrl I think, so I get confused by this commit message. > extern int pinctrl_gpio_request(unsigned gpio); > +extern int pinctrl_mux_gpio_request_enable(unsigned gpio); What's wrong with just using the existing call pinctrl_gpio_request() right above your new one? It's not like we're reference counting or something, it's just a callback. Sprinkle some comments to show what's going on. If you for some reason need a new call for this specific use case, it needs to be named after the use case, like pinctrl_gpio_request_for_irq() so it is obvious what the function is doing. Yours, Linus Walleij
Re: [PATCH] gpio: rcar: reference device instead of platform device
On Thu, Nov 22, 2018 at 9:19 PM Vladimir Zapolskiy wrote: > The change simplifies dereferences to the mediated struct device, also > it allows to limit the scope of the platform device usage to probe and > remove functions only. > > Non-functional change. > > Signed-off-by: Vladimir Zapolskiy Patch applied with Geert's review tag. Yours, Linus Walleij
Re: [git pull] pinctrl: sh-pfc: Updates for v4.21 (take two)
On Fri, Dec 7, 2018 at 1:21 PM Geert Uytterhoeven wrote: > The following changes since commit b59d0e782706785b7042539e820e95df3be4d04c: > > pinctrl: Add RZ/A2 pin and gpio controller (2018-11-23 09:30:27 +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.21-tag2 > > for you to fetch changes up to 3f3327dbc5596076f94695d8d4cc66da3d5027fb: > > pinctrl: rzn1: Fix of_get_child_count() error check (2018-12-04 10:33:49 > +0100) Merged this "take two" version into my devel branch! Thanks! Linus Walleij
Re: [git pull] pinctrl: sh-pfc: Updates for v4.21
On Fri, Nov 23, 2018 at 10:00 AM Geert Uytterhoeven wrote: > The following changes since commit 651022382c7f8da46cb4872a545ee1da6d097d2a: > > Linux 4.20-rc1 (2018-11-04 15:37:52 -0800) > > 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.21-tag1 > > for you to fetch changes up to b59d0e782706785b7042539e820e95df3be4d04c: > > pinctrl: Add RZ/A2 pin and gpio controller (2018-11-23 09:30:27 +0100) Pulled into my devel branch! Excellent work as always, thanks a lot Geert! Yours, Linus Walleij
Re: [PATCH] gpiolib: use better errno if get_direction is not available
On Tue, Sep 11, 2018 at 2:04 PM Geert Uytterhoeven wrote: > On Sun, Jul 29, 2018 at 11:33 PM Linus Walleij > wrote:> > On Wed, Jul 25, 2018 at 10:20 PM Wolfram Sang > wrote: > > > > That all being said, I think this patch is still useful as is. > > > > > > Linus, do you have time to comment on this? > > > > This looks like a good solution to me. > > Reviewed-by: Linus Walleij > > Any plans to apply it? drivers/gpio/gpiolib.c is your territory, I believe ;-) Ooops sorry. Patch applied. Yours, Linus Walleij
