Re: [PATCH 64/64] i2c: reword i2c_algorithm in drivers according to newest specification
On Fri, Mar 22, 2024 at 2:27 PM Wolfram Sang wrote: > Match the wording in i2c_algorithm in I2C drivers wrt. the newest I2C > v7, SMBus 3.2, I3C specifications and replace "master/slave" with more > appropriate terms. For some drivers, this means no more conversions are > needed. For the others more work needs to be done but this will be > performed incrementally along with API changes/improvements. All these > changes here are simple search/replace results. > > Signed-off-by: Wolfram Sang Acked-by: Linus Walleij Yours, Linus Walleij
Re: [PATCH 2/9] dma: Convert from tasklet to BH workqueue
Hi Allen, thanks for your patch! On Wed, Mar 27, 2024 at 5:03 PM Allen Pais wrote: > The only generic interface to execute asynchronously in the BH context is > tasklet; however, it's marked deprecated and has some design flaws. To > replace tasklets, BH workqueue support was recently added. A BH workqueue > behaves similarly to regular workqueues except that the queued work items > are executed in the BH context. > > This patch converts drivers/dma/* from tasklet to BH workqueue. > > Based on the work done by Tejun Heo > Branch: git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq.git for-6.10 > > Signed-off-by: Allen Pais (...) > diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c (...) > if (d40c->pending_tx) > - tasklet_schedule(>tasklet); > + queue_work(system_bh_wq, >work); Why is "my" driver not allowed to use system_bh_highpri_wq? I can't see the reasoning between some drivers using system_bh_wq and others being highpri? Given the DMA usecase I would expect them all to be high prio. Yours, Linus Walleij
Re: [PATCH 9/9] mmc: Convert from tasklet to BH workqueue
On Thu, Mar 28, 2024 at 1:54 PM Ulf Hansson wrote: > At this point we have suggested to drivers to switch to use threaded > irq handlers (and regular work queues if needed too). That said, > what's the benefit of using the BH work queue? Context: https://lwn.net/Articles/960041/ "Tasklets, in particular, remain because they offer lower latency than workqueues which, since they must go through the CPU scheduler, can take longer to execute a deferred-work item." The BH WQ is controlled by a software IRQ and quicker than an ordinary work item. I don't know if this little latency could actually affect any MMC device, I doubt it. The other benefit IIUC is that it is easy to mechanically rewrite tasklets to BH workqueues and be sure that it is as fast as the tasklet, if you want to switch to threaded IRQ handlers or proper work, you need to write a lot of elaborate code and test it (preferably on real hardware). Yours, Linus Walleij
Re: [PATCH] powerpc: Split PAGE_SHIFT/SIZE into vdso/page.h
On Thu, Dec 21, 2023 at 1:04 PM Michael Ellerman wrote:
> The VDSO needs PAGE_SHIFT/SIZE defined, so it includes asm/page.h.
>
> However when COMPAT=y the VDSO is built 32-bit, even though the kernel
> is 64-bit. That can lead to odd warnings because some kernel constants
> are 64-bit, but unsigned long is 32-bit, for example:
>
> VDSO32C arch/powerpc/kernel/vdso/vgettimeofday-32.o
> In file included from :4:
> In file included from /home/michael/linux/lib/vdso/gettimeofday.c:5:
> In file included from ../include/vdso/datapage.h:137:
> In file included from ../arch/powerpc/include/asm/vdso/gettimeofday.h:7:
> ../arch/powerpc/include/asm/page.h:230:9: warning: result of comparison of
> constant 13835058055282163712 with expression of type 'unsigned long' is
> always true
> 230 | return __pa(kaddr) >> PAGE_SHIFT;
> |^~~
>
> Fix it by moving the PAGE_SHIFT/SIZE constants into a separate header,
> which can be included by the VDSO, and also by the existing kernel
> headers. That avoids exposing the rest of the header to the non-standard
> build environment of the compat VDSO.
>
> The particular warning above was introduced by commit 58b6fed89ab0
> ("powerpc: Make virt_to_pfn() a static inline"), though it is not at
> fault, it just exposed the fact that the VDSO was including parts of
> page.h that weren't needed or appropriate for the VDSO.
>
> Don't copy the comment about page sizes, it just risks becoming
> outdated, that information is better available in the Kconfig
> dependencies and help text.
>
> Fixes: 58b6fed89ab0 ("powerpc: Make virt_to_pfn() a static inline")
> Reported-by: kernel test robot
> Closes:
> https://lore.kernel.org/oe-kbuild-all/202311061940.4pbrm44u-...@intel.com/
> Signed-off-by: Michael Ellerman
Clearly a working solution!
Acked-by: Linus Walleij
Just a note:
> diff --git a/arch/powerpc/include/asm/page.h b/arch/powerpc/include/asm/page.h
(...)
> +#include
(...)
> +++ b/arch/powerpc/include/asm/vdso/page.h
> @@ -0,0 +1,10 @@
> +/* SPDX-License-Identifier: GPL-2.0-or-later */
> +#ifndef _ASM_POWERPC_VDSO_PAGE_H
> +#define _ASM_POWERPC_VDSO_PAGE_H
> +
> +#include
Now the whole kernel includes , is this necessary?
Yours,
Linus Walleij
Re: [PATCH] powerpc: Fix signature of pfn_to_kaddr()
On Tue, Nov 7, 2023 at 6:57 AM Michael Ellerman wrote: > I'm struggling to connect the removal of const with those bug reports. > It looks like all those warnings are about 0xc000 being > outside the range of unsigned long when building 32-bit. Aha right. I wonder what actually causes that. > Is it the right bug report link? Yeah I'm just bad at understanding these reports. > The current signature of: > > static inline const void *pfn_to_kaddr(unsigned long pfn) ... > > seems OK to me. OK then, drop this patch. Yours, Linus Walleij
[PATCH] powerpc: Fix signature of pfn_to_kaddr()
There is a const in the returned value from pfn_to_kaddr()
but there are consumers that want to modify the result
and the generic function pfn_to_virt() in
does allow this, so let's relax this requirement and do not
make the returned value const.
Reported-by: kernel test robot
Closes:
https://lore.kernel.org/oe-kbuild-all/202311061940.4pbrm44u-...@intel.com/
Fixes: 58b6fed89ab0 ("powerpc: Make virt_to_pfn() a static inline")
Signed-off-by: Linus Walleij
---
The remaining warnings from the test robot appear a bit bogus.
If someone knows what to do about them, please help. The warnings
often properly uncovers problems that have been around forever
due to these functions being disguised as macros.
---
arch/powerpc/include/asm/page.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/page.h b/arch/powerpc/include/asm/page.h
index e5fcc79b5bfb..5243e48dc13a 100644
--- a/arch/powerpc/include/asm/page.h
+++ b/arch/powerpc/include/asm/page.h
@@ -230,7 +230,7 @@ static inline unsigned long virt_to_pfn(const void *kaddr)
return __pa(kaddr) >> PAGE_SHIFT;
}
-static inline const void *pfn_to_kaddr(unsigned long pfn)
+static inline void *pfn_to_kaddr(unsigned long pfn)
{
return __va(pfn << PAGE_SHIFT);
}
---
base-commit: d2f51b3516dade79269ff45eae2a7668ae711b25
change-id: 20231106-virt-to-pfn-fix-ppc-d91de47c6017
Best regards,
--
Linus Walleij
Re: [PATCH v5 28/31] pinctrl: Add support for the Lantic PEF2256 pinmux
On Tue, Sep 12, 2023 at 4:31 PM Mark Brown wrote: > On Tue, Sep 12, 2023 at 01:04:56PM +0200, Linus Walleij wrote: > > On Tue, Sep 12, 2023 at 12:15 PM Herve Codina > > wrote: > > > > +/* SPDX-License-Identifier: GPL-2.0 */ > > > +/* > > > I think SPDX mandates that you start the tag with C99 comments > > > // SPDX-License-Identifier: GPL-2.0-only > > Not for headers, they should use C style since they might be included in > contexts where C++ isn't supported. Oh right. Thanks Mark! Yours, Linus Walleij
Re: [PATCH v5 29/31] MAINTAINERS: Add the Lantiq PEF2256 driver entry
On Tue, Sep 12, 2023 at 12:15 PM Herve Codina wrote: > After contributing the driver, add myself as the maintainer for the > Lantiq PEF2256 driver. > > Signed-off-by: Herve Codina > Reviewed-by: Christophe Leroy > Signed-off-by: Christophe Leroy > --- > MAINTAINERS | 9 + > 1 file changed, 9 insertions(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 8b987f2c8633..dbc5867016bc 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -11876,6 +11876,15 @@ S: Maintained > F: arch/mips/lantiq > F: drivers/soc/lantiq > > +LANTIQ PEF2256 DRIVER > +M: Herve Codina > +S: Maintained > +F: Documentation/devicetree/bindings/net/lantiq,pef2256.yaml > +F: drivers/net/wan/framer/pef2256/ > +F: drivers/pinctrl/pinctrl-pef2256-regs.h > +F: drivers/pinctrl/pinctrl-pef2256.c Just use a glob expression: F: drivers/pinctrl/pinctrl-pef2256-* Yours, Linus Walleij
Re: [PATCH v5 28/31] pinctrl: Add support for the Lantic PEF2256 pinmux
Hi Herve,
thanks for your patch!
On Tue, Sep 12, 2023 at 12:15 PM Herve Codina wrote:
> The Lantiq PEF2256 is a framer and line interface component designed to
> fulfill all required interfacing between an analog E1/T1/J1 line and the
> digital PCM system highway/H.100 bus.
>
> This kind of component can be found in old telecommunication system.
> It was used to digital transmission of many simultaneous telephone calls
> by time-division multiplexing. Also using HDLC protocol, WAN networks
> can be reached through the framer.
>
> This pinmux support handles the pin muxing part (pins RP(A..D) and pins
> XP(A..D)) of the PEF2256.
>
> Signed-off-by: Herve Codina
> Reviewed-by: Christophe Leroy
> Signed-off-by: Christophe Leroy
Nice to see this as a proper pin control driver!
> drivers/pinctrl/pinctrl-pef2256-regs.h | 65 ++
> drivers/pinctrl/pinctrl-pef2256.c | 308 +
Do you really need a separate header just for some registers?
But it's a matter of taste so I'm not gonna complain if you want
it this way.
> +config PINCTRL_PEF2256
> + tristate "Lantiq PEF2256 (FALC56) pin controller driver"
> + depends on OF && FRAMER_PEF2256
> + select PINMUX
select PINCONF
> + select GENERIC_PINCONF
This brings it in implicitly but I prefer that you just select it.
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
I think SPDX mandates that you start the tag with C99 comments
// SPDX-License-Identifier: GPL-2.0-only
> + /* We map 1 group <-> 1 pin */
Also known as "the qualcomm trick", but hey: it's fine.
> +static int pef2256_register_pinctrl(struct pef2256_pinctrl *pef2256)
> +{
> + struct pinctrl_dev *pctrl;
> +
> + pef2256->pctrl_desc.name= dev_name(pef2256->dev);
> + pef2256->pctrl_desc.owner = THIS_MODULE;
> + pef2256->pctrl_desc.pctlops = _pctlops;
> + pef2256->pctrl_desc.pmxops = _pmxops;
> + if (pef2256->version == PEF2256_VERSION_1_2) {
> + pef2256->pctrl_desc.pins = pef2256_v12_pins;
> + pef2256->pctrl_desc.npins = ARRAY_SIZE(pef2256_v12_pins);
> + pef2256->functions = pef2256_v12_functions;
> + pef2256->nfunctions = ARRAY_SIZE(pef2256_v12_functions);
> + } else {
> + pef2256->pctrl_desc.pins = pef2256_v2x_pins;
> + pef2256->pctrl_desc.npins = ARRAY_SIZE(pef2256_v2x_pins);
> + pef2256->functions = pef2256_v2x_functions;
> + pef2256->nfunctions = ARRAY_SIZE(pef2256_v2x_functions);
> + }
> +
> + pctrl = devm_pinctrl_register(pef2256->dev, >pctrl_desc,
> pef2256);
> + if (IS_ERR(pctrl)) {
> + dev_err(pef2256->dev, "pinctrl driver registration failed\n");
> + return PTR_ERR(pctrl);
> + }
> +
> + return 0;
You could use
return dev_err_probe(...);
> + pef2256_reset_pinmux(pef2256_pinctrl);
> + ret = pef2256_register_pinctrl(pef2256_pinctrl);
> + if (ret)
> + return ret;
Or you could use it down here.
With or without these changes (because they are nitpicks)
Reviewed-by: Linus Walleij
Yours,
Linus Walleij
Re: [PATCH v5 27/31] net: wan: framer: Add support for the Lantiq PEF2256 framer
On Tue, Sep 12, 2023 at 12:15 PM Herve Codina wrote: > The Lantiq PEF2256 is a framer and line interface component designed to > fulfill all required interfacing between an analog E1/T1/J1 line and the > digital PCM system highway/H.100 bus. > > Signed-off-by: Herve Codina > Reviewed-by: Christophe Leroy > Signed-off-by: Christophe Leroy Reviewed-by: Linus Walleij Yours, Linus Walleij
Re: [PATCH v4 21/28] net: wan: Add framer framework support
On Mon, Aug 21, 2023 at 7:19 AM Christophe Leroy wrote: > Le 20/08/2023 à 23:06, Linus Walleij a écrit : > > On Fri, Aug 18, 2023 at 6:41 PM Christophe Leroy > > wrote: > > > >> From: Herve Codina > >> > >> A framer is a component in charge of an E1/T1 line interface. > >> Connected usually to a TDM bus, it converts TDM frames to/from E1/T1 > >> frames. It also provides information related to the E1/T1 line. > >> > >> The framer framework provides a set of APIs for the framer drivers > >> (framer provider) to create/destroy a framer and APIs for the framer > >> users (framer consumer) to obtain a reference to the framer, and > >> use the framer. > >> > >> This basic implementation provides a framer abstraction for: > >> - power on/off the framer > >> - get the framer status (line state) > >> - be notified on framer status changes > >> - get/set the framer configuration > >> > >> Signed-off-by: Herve Codina > >> Reviewed-by: Christophe Leroy > >> Signed-off-by: Christophe Leroy > > > > I had these review comments, you must have missed them? > > https://lore.kernel.org/netdev/cacrpkdzq9_f6+9csev1l_wgphhujfpayxmjjfjurzszrako...@mail.gmail.com/ > > > > As I said in the cover letter, this series only fixes critical build > failures that happened when CONFIG_MODULES is set. The purpose was to > allow robots to perform their job up to the end. Other feedback and > comments will be taken into account by Hervé when he is back from holidays. Ah I see. I completely missed this. Yours, Linus Walleij
Re: [PATCH v4 21/28] net: wan: Add framer framework support
On Fri, Aug 18, 2023 at 6:41 PM Christophe Leroy wrote: > From: Herve Codina > > A framer is a component in charge of an E1/T1 line interface. > Connected usually to a TDM bus, it converts TDM frames to/from E1/T1 > frames. It also provides information related to the E1/T1 line. > > The framer framework provides a set of APIs for the framer drivers > (framer provider) to create/destroy a framer and APIs for the framer > users (framer consumer) to obtain a reference to the framer, and > use the framer. > > This basic implementation provides a framer abstraction for: > - power on/off the framer > - get the framer status (line state) > - be notified on framer status changes > - get/set the framer configuration > > Signed-off-by: Herve Codina > Reviewed-by: Christophe Leroy > Signed-off-by: Christophe Leroy I had these review comments, you must have missed them? https://lore.kernel.org/netdev/cacrpkdzq9_f6+9csev1l_wgphhujfpayxmjjfjurzszrako...@mail.gmail.com/ Yours, Linus Walleij
Re: [PATCH] powerpc: Make virt_to_pfn() a static inline
On Tue, Aug 15, 2023 at 9:30 AM Michael Ellerman wrote: > Linus Walleij writes: > > - return ((unsigned long)__va(pmd_val(pmd) & ~PMD_MASKED_BITS)); > > + return (const void *)((unsigned long)__va(pmd_val(pmd) & > > ~PMD_MASKED_BITS)); > > This can also just be: > > return __va(pmd_val(pmd) & ~PMD_MASKED_BITS); > > I've squashed that in. Oh you applied it, then I don't need to send revised versions, thanks Michael! Yours, Linus Walleij
Re: [PATCH] powerpc: Make virt_to_pfn() a static inline
On Mon, Aug 14, 2023 at 2:37 PM Michael Ellerman wrote:
> > +static inline const void *pfn_to_kaddr(unsigned long pfn)
> > +{
> > + return (const void *)(((unsigned long)__va(pfn)) << PAGE_SHIFT);
>
> Any reason to do it this way rather than:
>
> + return __va(pfn << PAGE_SHIFT);
>
> Seems to be equivalent and much cleaner?
I was afraid of changing the semantic in the original macro
which converts to a virtual address before shifting, instead
of shifting first, but you're right, I'm too cautious. I'll propose
the elegant solution from you & Christophe instead!
Yours,
Linus Walleij
Re: [PATCH v3 21/28] net: wan: Add framer framework support
Hi Herve, On Wed, Aug 9, 2023 at 3:28 PM Herve Codina wrote: > A framer is a component in charge of an E1/T1 line interface. > Connected usually to a TDM bus, it converts TDM frames to/from E1/T1 > frames. It also provides information related to the E1/T1 line. > > The framer framework provides a set of APIs for the framer drivers > (framer provider) to create/destroy a framer and APIs for the framer > users (framer consumer) to obtain a reference to the framer, and > use the framer. > > This basic implementation provides a framer abstraction for: > - power on/off the framer > - get the framer status (line state) > - be notified on framer status changes > - get/set the framer configuration > > Signed-off-by: Herve Codina > Reviewed-by: Christophe Leroy I love it, very clear commit message telling us what it is all about. The placement in the WAN subsystem also hints that this has something to do with long distance links (relative to something) so maybe mention that? > +menu "Framer Subsystem" > + > +config GENERIC_FRAMER > + bool "Framer Core" > + help > + Generic Framer support. > + > + This framework is designed to provide a generic interface for framer > + devices present in the kernel. This layer will have the generic > + API by which framer drivers can create framer using the framer > + framework and framer users can obtain reference to the framer. > + All the users of this framework should select this config. But this description just says this is a framing framer that frames frames ;) So please copy some of the nice description from the commit message into this Kconfig helptext. Is "long distance link time division multiplexing (TDM) framer" more to the point for example? Or is the ambition to frame other multiplexing techniques as well with this subsystem? Such as FDM? Then mention that. Yours, Linus Walleij
Re: [PATCH v3 22/28] dt-bindings: net: Add the Lantiq PEF2256 E1/T1/J1 framer
Hi Herve, thanks for your patch! On Wed, Aug 9, 2023 at 3:28 PM Herve Codina wrote: > The Lantiq PEF2256 is a framer and line interface component designed to > fulfill all required interfacing between an analog E1/T1/J1 line and the > digital PCM system highway/H.100 bus. > > Signed-off-by: Herve Codina (...) > +patternProperties: > + '-pins$': > +type: object > +$ref: /schemas/pinctrl/pincfg-node.yaml# Shouldn't that be pinmux-node.yaml? > +additionalProperties: false > + > +properties: > + pins: > +enum: [ RPA, RPB, RPC, RPD, XPA, XPB, XPC, XPD ] > + > + function: > +enum: [ SYPR, RFM, RFMB, RSIGM, RSIG, DLR, FREEZE, RFSP, LOS, > +SYPX, XFMS, XSIG, TCLK, XMFB, XSIGM, DLX, XCLK, XLT, > +GPI, GPOH, GPOL ] > + > +required: > + - pins > + - function Because those are certainly defined in that file. Yours, Linus Walleij
[PATCH] powerpc: Make virt_to_pfn() a static inline
Making virt_to_pfn() a static inline taking a strongly typed
(const void *) makes the contract of a passing a pointer of that
type to the function explicit and exposes any misuse of the
macro virt_to_pfn() acting polymorphic and accepting many types
such as (void *), (unitptr_t) or (unsigned long) as arguments
without warnings.
Move the virt_to_pfn() and related functions below the
declaration of __pa() so it compiles.
For symmetry do the same with pfn_to_kaddr().
As the file is included right into the linker file, we need
to surround the functions with ifndef __ASSEMBLY__ so we
don't cause compilation errors.
The conversion moreover exposes the fact that pmd_page_vaddr()
was returning an unsigned long rather than a const void * as
could be expected, so all the sites defining pmd_page_vaddr()
had to be augmented as well.
Finally the KVM code in book3s_64_mmu_hv.c was passing an
unsigned int to virt_to_phys() so fix that up with a cast so the
result compiles.
Signed-off-by: Linus Walleij
---
arch/powerpc/include/asm/nohash/32/pgtable.h | 2 +-
arch/powerpc/include/asm/nohash/64/pgtable.h | 2 +-
arch/powerpc/include/asm/page.h | 30 ++--
arch/powerpc/include/asm/pgtable.h | 4 ++--
arch/powerpc/kvm/book3s_64_mmu_hv.c | 2 +-
5 files changed, 25 insertions(+), 15 deletions(-)
diff --git a/arch/powerpc/include/asm/nohash/32/pgtable.h
b/arch/powerpc/include/asm/nohash/32/pgtable.h
index fec56d965f00..d6201b5096b8 100644
--- a/arch/powerpc/include/asm/nohash/32/pgtable.h
+++ b/arch/powerpc/include/asm/nohash/32/pgtable.h
@@ -355,7 +355,7 @@ static inline int pte_young(pte_t pte)
#define pmd_pfn(pmd) (pmd_val(pmd) >> PAGE_SHIFT)
#else
#define pmd_page_vaddr(pmd)\
- ((unsigned long)(pmd_val(pmd) & ~(PTE_TABLE_SIZE - 1)))
+ ((const void *)(pmd_val(pmd) & ~(PTE_TABLE_SIZE - 1)))
#define pmd_pfn(pmd) (__pa(pmd_val(pmd)) >> PAGE_SHIFT)
#endif
diff --git a/arch/powerpc/include/asm/nohash/64/pgtable.h
b/arch/powerpc/include/asm/nohash/64/pgtable.h
index 287e25864ffa..81c801880933 100644
--- a/arch/powerpc/include/asm/nohash/64/pgtable.h
+++ b/arch/powerpc/include/asm/nohash/64/pgtable.h
@@ -127,7 +127,7 @@ static inline pte_t pmd_pte(pmd_t pmd)
#definepmd_bad(pmd)(!is_kernel_addr(pmd_val(pmd)) \
|| (pmd_val(pmd) & PMD_BAD_BITS))
#definepmd_present(pmd)(!pmd_none(pmd))
-#define pmd_page_vaddr(pmd)(pmd_val(pmd) & ~PMD_MASKED_BITS)
+#define pmd_page_vaddr(pmd)((const void *)(pmd_val(pmd) &
~PMD_MASKED_BITS))
extern struct page *pmd_page(pmd_t pmd);
#define pmd_pfn(pmd) (page_to_pfn(pmd_page(pmd)))
diff --git a/arch/powerpc/include/asm/page.h b/arch/powerpc/include/asm/page.h
index f2b6bf5687d0..9ee4b6d4a82a 100644
--- a/arch/powerpc/include/asm/page.h
+++ b/arch/powerpc/include/asm/page.h
@@ -9,6 +9,7 @@
#ifndef __ASSEMBLY__
#include
#include
+#include
#else
#include
#endif
@@ -119,16 +120,6 @@ extern long long virt_phys_offset;
#define ARCH_PFN_OFFSET((unsigned long)(MEMORY_START >>
PAGE_SHIFT))
#endif
-#define virt_to_pfn(kaddr) (__pa(kaddr) >> PAGE_SHIFT)
-#define virt_to_page(kaddr)pfn_to_page(virt_to_pfn(kaddr))
-#define pfn_to_kaddr(pfn) __va((pfn) << PAGE_SHIFT)
-
-#define virt_addr_valid(vaddr) ({ \
- unsigned long _addr = (unsigned long)vaddr; \
- _addr >= PAGE_OFFSET && _addr < (unsigned long)high_memory && \
- pfn_valid(virt_to_pfn(_addr)); \
-})
-
/*
* On Book-E parts we need __va to parse the device tree and we can't
* determine MEMORY_START until then. However we can determine PHYSICAL_START
@@ -233,6 +224,25 @@ extern long long virt_phys_offset;
#endif
#endif
+#ifndef __ASSEMBLY__
+static inline unsigned long virt_to_pfn(const void *kaddr)
+{
+ return __pa(kaddr) >> PAGE_SHIFT;
+}
+
+static inline const void *pfn_to_kaddr(unsigned long pfn)
+{
+ return (const void *)(((unsigned long)__va(pfn)) << PAGE_SHIFT);
+}
+#endif
+
+#define virt_to_page(kaddr)pfn_to_page(virt_to_pfn(kaddr))
+#define virt_addr_valid(vaddr) ({ \
+ unsigned long _addr = (unsigned long)vaddr; \
+ _addr >= PAGE_OFFSET && _addr < (unsigned long)high_memory && \
+ pfn_valid(virt_to_pfn((void *)_addr)); \
+})
+
/*
* Unfortunately the PLT is in the BSS in the PPC32 ELF ABI,
* and needs to be executable. This means the whole heap ends
diff --git a/arch/powerpc/include/asm/pgtable.h
b/arch/powerpc/include/asm/pgtable.h
index 6a88bfdaa69b..a9515d3d7831 100644
--- a/arch/powerpc/include/asm/pgtable.h
+++ b/arch/powerpc/include/asm/pgtable.h
@@ -60,9
Re: [PATCH v2 24/28] pinctrl: Add support for the Lantic PEF2256 pinmux
On Mon, Aug 7, 2023 at 3:10 PM Mark Brown wrote: > On Mon, Aug 07, 2023 at 03:05:15PM +0200, Linus Walleij wrote: > > On Wed, Jul 26, 2023 at 5:04 PM Herve Codina > > wrote: > > > > +#include "linux/bitfield.h" > > > Really? I don't think there is such a file there. > > > Do you mean and does this even compile? > > #include "" means "try the local directory first then fall back to > system includes" so it'll work, it picks up extra stuff on top of what > <> does. There's a stylistic issue though. Wow that's a neat trick, I learn something new every day! But we probably wanna be sure to get the system include. Yours, Linus Walleij
Re: [PATCH v2 24/28] pinctrl: Add support for the Lantic PEF2256 pinmux
On Mon, Aug 7, 2023 at 3:05 PM Linus Walleij wrote: > > Signed-off-by: Herve Codina > > So it is a bridge chip? Please use that terminology since Linux > DRM often talks about bridges. Replying to self: no it's not a bridge, it's a WAN thingy. So perhaps write that this is a WAN interface adapter chip. Yours, Linus Walleij
Re: [PATCH v2 24/28] pinctrl: Add support for the Lantic PEF2256 pinmux
Hi Herve,
thanks for your patch!
First: is this patch something we could merge separately? I don't see
any dependency on the other patches.
On Wed, Jul 26, 2023 at 5:04 PM Herve Codina wrote:
> The Lantiq PEF2256 is a framer and line interface component designed to
> fulfill all required interfacing between an analog E1/T1/J1 line and the
> digital PCM system highway/H.100 bus.
>
> This pinmux support handles the pin muxing part (pins RP(A..D) and pins
> XP(A..D)) of the PEF2256.
>
> Signed-off-by: Herve Codina
So it is a bridge chip? Please use that terminology since Linux
DRM often talks about bridges.
> +++ b/drivers/pinctrl/pinctrl-pef2256-regs.h
(...)
> +#include "linux/bitfield.h"
Really? I don't think there is such a file there.
Do you mean and does this even compile?
> diff --git a/drivers/pinctrl/pinctrl-pef2256.c
> b/drivers/pinctrl/pinctrl-pef2256.c
(...)
> +struct pef2256_pinctrl {
> + struct device *dev;
> + struct regmap *regmap;
> + enum pef2256_version version;
> + struct {
> + struct pinctrl_desc pctrl_desc;
> + const struct pef2256_function_desc *functions;
> + unsigned int nfunctions;
> + } pinctrl;
Uh anonymous struct... can't you just define the struct separately
with a name? Or fold it into struct pef2256_pinctrl without the
additional struct? Thanks.
Otherwise it looks neat!
Yours,
Linus Walleij
Re: [PATCH 0/7] Expect immutable pointer in virt_to_phys/isa_virt_to_bus prototypes
On Thu, Apr 27, 2023 at 7:41 PM Stanislav Kinsburskii wrote: > This series is aimed to address compilation warnings when a constant pointer > is passed to virt_to_phys and isa_virt_to_bus functions: > > warning: passing argument 1 of ‘virt_to_phys’ discards ‘const’ qualifier > from pointer target type > warning: passing argument 1 of ‘isa_virt_to_bus’ discards ‘const’ qualifier > from pointer target type > > The change(s) is the same for all architectures, but it's split into a series > on > per-arch basis to simplify applying and testing on the maintainers side. > > The following series implements... This is nice. Reviewed-by: Linus Walleij I am working with an adjacent task, which is to make virt_to_pfn() and pfn_to_virt() into static inlines. I might need to rebase my work on top of this but it should be doable, I am currently stressing the buildbots with this with the idea to propose it to Arnd once v6.4-rc1 is out: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator.git/log/?h=b4/virt-to-pfn-v6-4-rc1 Yours, Linus Walleij
Re: [PATCH 17/21] ARM: dma-mapping: use arch_sync_dma_for_{device,cpu}() internally
On Mon, Mar 27, 2023 at 2:16 PM Arnd Bergmann wrote: > From: Arnd Bergmann > > The arm specific iommu code in dma-mapping.c uses the page+offset based > __dma_page_cpu_to_dev()/__dma_page_dev_to_cpu() helpers in place of the > phys_addr_t based arch_sync_dma_for_device()/arch_sync_dma_for_cpu() > wrappers around the. Broken sentence? > In order to be able to move the latter part set of functions into > common code, change the iommu implementation to use them directly > and remove the internal ones as a separate interface. > > As page+offset and phys_address are equivalent, but are used in > different parts of the code here, this allows removing some of > the conversion but adds them elsewhere. > > Signed-off-by: Arnd Bergmann Looks good to me, took me some time to verify and understand the open-coded version of PFN_UP() and this refactoring alone makes the patch highly valuable. Reviewed-by: Linus Walleij Yours, Linus Walleij
Re: [PATCH 15/21] ARM: dma-mapping: always invalidate WT caches before DMA
On Mon, Mar 27, 2023 at 2:16 PM Arnd Bergmann wrote: > From: Arnd Bergmann > > Most ARM CPUs can have write-back caches and that require > cache management to be done in the dma_sync_*_for_device() > operation. This is typically done in both writeback and > writethrough mode. > > The cache-v4.S (arm720/740/7tdmi/9tdmi) and cache-v4wt.S > (arm920t, arm940t) implementations are the exception here, > and only do the cache management after the DMA is complete, > in the dma_sync_*_for_cpu() operation. > > Change this for consistency with the other platforms. This > should have no user visible effect. > > Signed-off-by: Arnd Bergmann Looks good to me. Reviewed-by: Linus Walleij Yours, Linus Walleij
Re: [PATCH 18/21] ARM: drop SMP support for ARM11MPCore
On Mon, Mar 27, 2023 at 2:16 PM Arnd Bergmann wrote: > From: Arnd Bergmann > > The cache management operations for noncoherent DMA on ARMv6 work > in two different ways: > > * When CONFIG_DMA_CACHE_RWFO is set, speculative prefetches on in-flight >DMA buffers lead to data corruption when the prefetched data is written >back on top of data from the device. > > * When CONFIG_DMA_CACHE_RWFO is disabled, a cache flush on one CPU >is not seen by the other core(s), leading to inconsistent contents >accross the system. > > As a consequence, neither configuration is actually safe to use in a > general-purpose kernel that is used on both MPCore systems and ARM1176 > with prefetching enabled. > > We could add further workarounds to make the behavior more dynamic based > on the system, but realistically, there are close to zero remaining > users on any ARM11MPCore anyway, and nobody seems too interested in it, > compared to the more popular ARM1176 used in BMC2835 and AST2500. > > The Oxnas platform has some minimal support in OpenWRT, but most of the > drivers and dts files never made it into the mainline kernel, while the > Arm Versatile/Realview platform mainly serves as a reference system but > is not necessary to be kept working once all other ARM11MPCore are gone. > > Take the easy way out here and drop support for multiprocessing on > ARMv6, along with the CONFIG_DMA_CACHE_RWFO option and the cache > management implementation for it. This also helps with other ARMv6 > issues, but for the moment leaves the ability to build a kernel that > can run on both ARMv7 SMP and single-processor ARMv6, which we probably > want to stop supporting as well, but not as part of this series. > > Cc: Neil Armstrong > Cc: Daniel Golle > Cc: Linus Walleij > Cc: linux-ox...@groups.io > Signed-off-by: Arnd Bergmann Yeah, we discussed this earlier, let's just drop it. Not worth the effort. Acked-by: Linus Walleij Yours, Linus Walleij
Re: [PATCH v10 03/13] dt-bindings: Convert gpio-mmio to yaml
On Mon, Mar 13, 2023 at 9:53 AM Leonard, Niall wrote: > > Niall are you sending a v3 of this patch soon? > > Include Sean on the reviewer list! > I never got around to working on the V3 patch. The hold up for me was > the changes to the bindings. > I'm now wondering if I should wait on Sean's patch being accepted and > then I could re-submit the driver changes. > What's the consensus ? Sean picked it up for shepherding, it looks very good, as soon as the DT maintainers give it a nod Bartosz can merge it. Yours, Linus Walleij
Re: [PATCH v11 03/13] dt-bindings: Convert gpio-mmio to yaml
On Mon, Mar 13, 2023 at 5:12 PM Sean Anderson wrote: > This is a generic binding for simple MMIO GPIO controllers. Although we > have a single driver for these controllers, they were previously spread > over several files. Consolidate them. The register descriptions are > adapted from the comments in the source. There is no set order for the > registers, so I have not specified one. > > Rename brcm,bcm6345-gpio to brcm,bcm63xx-gpio to reflect that bcm6345 > has moved. > > Signed-off-by: Sean Anderson > Reviewed-by: Linus Walleij > --- > Linus or Bartosz, feel free to pick this up as the rest of this series > may not be merged any time soon. I think Bartosz will pick this as soon as the DT maintainers ACK it. Yours, Linus Walleij
Re: [PATCH v10 03/13] dt-bindings: Convert gpio-mmio to yaml
On Tue, Mar 7, 2023 at 4:35 PM Sean Anderson wrote: > On 3/7/23 03:42, Krzysztof Kozlowski wrote: > > https://lore.kernel.org/all/20230126-gpio-mmio-fix-v2-1-38397aace...@ncr.com/ > > Thanks for linking to that. > > I believe this patch should be applied instead of that one because > > - It documents all the registers, which were previously only documented > in the driver > - It handles the endianness properties. > - It consolidates the various descriptions of this binding into one > schema. Niall are you sending a v3 of this patch soon? Include Sean on the reviewer list! Yours, Linus Walleij
Re: [PATCH v10 03/13] dt-bindings: Convert gpio-mmio to yaml
Hi Sean, thanks for doing this. I never got around to because time. On Mon, Mar 6, 2023 at 8:16 PM Sean Anderson wrote: > This is a generic binding for simple MMIO GPIO controllers. Although we > have a single driver for these controllers, they were previously spread > over several files. Consolidate them. The register descriptions are > adapted from the comments in the source. There is no set order for the > registers, so I have not specified one. > > Signed-off-by: Sean Anderson (...) > + compatible: > +enum: > + - brcm,bcm6345-gpio # Broadcom BCM6345 GPIO controller > + - wd,mbl-gpio # Western Digital MyBook Live memory-mapped GPIO > controller > + - ni,169445-nand-gpio # National Instruments 169445 GPIO NAND > controller I think you can inline description: statements in the enum instead of the # hash comments, however IIRC you have to use oneOf and const: to do it, like I do in Documentation/devicetree/bindings/input/touchscreen/cypress,cy8ctma340.yaml but don't overinvest in this if it is cumbersome. Either way: Reviewed-by: Linus Walleij Yours, Linus Walleij
Re: [PATCH v4 02/18] ARM: s3c24xx: Use the right include
On Wed, Feb 8, 2023 at 6:39 PM Krzysztof Kozlowski wrote: > On 08/02/2023 18:33, Andy Shevchenko wrote: > > From: Linus Walleij > > > > The file s3c64xx.c is including despite using no > > symbols from the file, however it needs it to implicitly bring in > > of_have_populated_dt() so include explicitly instead. > > > > Signed-off-by: Linus Walleij > > Signed-off-by: Andy Shevchenko > > --- > > arch/arm/mach-s3c/s3c64xx.c | 2 +- > > It's not s3c24xx anymore, so subject prefix: > ARM: s3c64xx: My mistake, mea culpa. Yours, Linus Walleij
Re: [PATCH v4 18/18] gpiolib: Clean up headers
On Wed, Feb 8, 2023 at 6:34 PM Andy Shevchenko wrote: > There is a few things done: > - include only the headers we are direct user of > - when pointer is in use, provide a forward declaration > - add missing headers > - group generic headers and subsystem headers > - sort each group alphabetically > > Signed-off-by: Andy Shevchenko Reviewed-by: Linus Walleij Yours, Linus Walleij
Re: [PATCH v4 13/18] gpio: reg: Add missing header(s)
On Wed, Feb 8, 2023 at 6:34 PM Andy Shevchenko wrote: > Do not imply that some of the generic headers may be always included. > Instead, include explicitly what we are direct user of. > > While at it, split out the GPIO group of headers. > > Signed-off-by: Andy Shevchenko Reviewed-by: Linus Walleij Yours, Linus Walleij
Re: [PATCH v4 12/18] gpio: aggregator: Add missing header(s)
On Wed, Feb 8, 2023 at 6:34 PM Andy Shevchenko wrote: > Do not imply that some of the generic headers may be always included. > Instead, include explicitly what we are direct user of. > > While at it, drop unused linux/gpio.h and split out the GPIO group of > headers. > > Signed-off-by: Andy Shevchenko > Reviewed-by: Geert Uytterhoeven Reviewed-by: Linus Walleij Yours, Linus Walleij
Re: [PATCH v4 17/18] gpiolib: Group forward declarations in consumer.h
On Wed, Feb 8, 2023 at 6:34 PM Andy Shevchenko wrote: > For better maintenance group the forward declarations together. > > Signed-off-by: Andy Shevchenko Reviewed-by: Linus Walleij Yours, Linus Walleij
Re: [PATCH v4 16/18] gpiolib: Deduplicate forward declarations in consumer.h
On Wed, Feb 8, 2023 at 6:34 PM Andy Shevchenko wrote: > The struct fwnode_handle pointer is used in both branches of ifdeffery, > no need to have a copy of the same in each of them, just make it global. > > Signed-off-by: Andy Shevchenko Reviewed-by: Linus Walleij Yours, Linus Walleij
Re: [PATCH v4 14/18] gpio: regmap: Add missing header(s)
On Wed, Feb 8, 2023 at 6:34 PM Andy Shevchenko wrote: > Do not imply that some of the generic headers may be always included. > Instead, include explicitly what we are direct user of. > > While at it, split out the GPIO group of headers. > > Signed-off-by: Andy Shevchenko Reviewed-by: Linus Walleij Yours, Linus Walleij
Re: [PATCH v3 06/12] gpiolib: split linux/gpio/driver.h out of linux/gpio.h
On Wed, Feb 8, 2023 at 3:51 PM Andy Shevchenko wrote: > On Wed, Feb 08, 2023 at 12:55:06AM +0200, Andy Shevchenko wrote: > > On Tue, Feb 07, 2023 at 03:55:23PM +0100, Linus Walleij wrote: > > > On Tue, Feb 7, 2023 at 3:29 PM Andy Shevchenko > > > wrote: > > > > > > > From: Arnd Bergmann > > > > > > > > Almost all gpio drivers include linux/gpio/driver.h, and other > > > > files should not rely on includes from this header. > > > > > > > > Remove the indirect include from here and include the correct > > > > headers directly from where they are used. > > > > ... > > > > > Make sure you push this to the kernel.org build servers (zeroday builds), > > > > Of course, that is the purpose of publishing this before the release (so we > > will have some TODO list that eventually this can be applied for v6.4-rc1). > > > > > I think this patch needs to hit some more files, in my tests with a > > > similar > > > patch at least these: > > > > Right. I forgot to also incorporate your stuff into this series. > > Do you have anything that I can take as is? > > I'm going to incorporate the following: > > gpio: Make the legacy consumer-only > ARM: s3c24xx: Use the right include > ARM: orion/gpio: Use the right include > hte: tegra-194: Use proper includes > pcmcia: pxa2xx_viper: Include dependency Excellent, thanks. I don't care about being credited, just want things to go smooth so you run into less snags. Yours, Linus Walleij
Re: [PATCH v3 06/12] gpiolib: split linux/gpio/driver.h out of linux/gpio.h
On Tue, Feb 7, 2023 at 3:29 PM Andy Shevchenko wrote: > From: Arnd Bergmann > > Almost all gpio drivers include linux/gpio/driver.h, and other > files should not rely on includes from this header. > > Remove the indirect include from here and include the correct > headers directly from where they are used. > > Reviewed-by: Andy Shevchenko > Signed-off-by: Arnd Bergmann > Reviewed-by: Linus Walleij > Signed-off-by: Andy Shevchenko Make sure you push this to the kernel.org build servers (zeroday builds), I think this patch needs to hit some more files, in my tests with a similar patch at least these: diff --git a/drivers/hte/hte-tegra194-test.c b/drivers/hte/hte-tegra194-test.c index 5d776a185bd6..79eb866558d3 100644 --- a/drivers/hte/hte-tegra194-test.c +++ b/drivers/hte/hte-tegra194-test.c @@ -6,10 +6,11 @@ */ #include +#include #include #include #include -#include +#include #include #include #include diff --git a/arch/arm/mach-pxa/viper-pcmcia.c b/arch/arm/mach-pxa/viper-pcmcia.c index 26599dcc49b3..2c7af4ed57d5 100644 --- a/arch/arm/mach-pxa/viper-pcmcia.c +++ b/arch/arm/mach-pxa/viper-pcmcia.c @@ -19,6 +19,7 @@ #include #include #include +#include #include #include Yours, Linus Walleij
Re: [PATCH RESEND 0/8] Resend LED patches
On Fri, Jan 20, 2023 at 6:15 PM Lee Jones wrote: > If everyone is convinced that applying these drivers is the correct > thing to do, I'd be happy to (rather) take them via LEDs. Oh you are co-maintainer of the LED subsystem since a month! Sadly this series stalled way before that, so that's why we didn't notice. By all means, pick it up! Yours, Linus Walleij
Re: [PATCH 2/5] arm: dts: remove label = "cpu" from DSA dt-binding
On Wed, Nov 30, 2022 at 3:13 PM Arınç ÜNAL wrote: > This is not used by the DSA dt-binding, so remove it from all devicetrees. > > Signed-off-by: Arınç ÜNAL Acked-by: Linus Walleij Yours, Linus Walleij
Re: [PATCH] soc: fsl: qe: request pins non-exclusively
On Tue, Nov 8, 2022 at 4:16 AM Dmitry Torokhov
wrote:
> Commit 84582f9ed090 ("soc: fsl: qe: Avoid using gpio_to_desc()") changed
> qe_pin_request() to request and hold GPIO corresponding to a given pin.
> Unfortunately this does not work, as fhci-hcd requests these GPIOs
> first, befor calling qe_pin_request() (see
> drivers/usb/host/fhci-hcd.c::of_fhci_probe()).
> To fix it change qe_pin_request() to request GPIOs non-exclusively, and
> free them once the code determines GPIO controller and offset for each
> GPIO/pin.
>
> Also reaching deep into gpiolib implementation is not the best idea. We
> should either export gpio_chip_hwgpio() or keep converting to the global
> gpio numbers space until we fix the driver to implement proper pin
> control.
>
> Fixes: 84582f9ed090 ("soc: fsl: qe: Avoid using gpio_to_desc()")
> Signed-off-by: Dmitry Torokhov
Wow! Thanks for fixing this!
Reviewed-by: Linus Walleij
I just sent that patch into the SoC patch tracker (s...@kernel.org)
with a not to apply it directly, I suggest you do the same (or ask me
to sign it off and send it).
Yours,
Linus Walleij
[PATCH v3] soc: fsl: qe: Avoid using gpio_to_desc()
The qe gpio driver is a custom API combined GPIO and pin control
driver that exist outside of the pin control subsystem for historical
reasons.
We want to get rid of the old GPIO numberspace, so instead of
calling gpio_to_desc() we get the gpio descriptor for the requested
line from the device tree directly without passing through the
GPIO numberspace, and then we get the gpiochip from the descriptor.
Using the reference counting inside the gpio descriptor we can drop
the reference counting code in this driver. A second gpiod_get()
will not succeed.
To obtain the local hardware offset of the GPIO line, the driver
need to include the header from the gpiolib internals. This isn't
pretty but it is the lesser evil compared to keeping the code
as a roadblock to gpiolib refactoring. A proper solution would be
to rewrite the driver as a real pin control driver with a
built-in gpio_chip.
Cc: Bartosz Golaszewski
Cc: linux-g...@vger.kernel.org
Signed-off-by: Linus Walleij
---
SoC folks: please apply this directly for -next if it seems
OK.
ChangeLog v2->v3:
- Realize what the driver is trying to do and make a deeper
refactoring to get at gpiolib internals.
ChangeLog v1->v2:
- Add back the include: we are using the
mm_of_gpio_chip, which should be fixed, but not now.
---
drivers/soc/fsl/qe/gpio.c | 66 ++-
1 file changed, 30 insertions(+), 36 deletions(-)
diff --git a/drivers/soc/fsl/qe/gpio.c b/drivers/soc/fsl/qe/gpio.c
index 99f7de43c3c6..af9193e7e49b 100644
--- a/drivers/soc/fsl/qe/gpio.c
+++ b/drivers/soc/fsl/qe/gpio.c
@@ -14,20 +14,23 @@
#include
#include
#include
+#include
#include
-/* FIXME: needed for gpio_to_chip() get rid of this */
-#include
#include
#include
#include
+/*
+ * FIXME: this is legacy code that is accessing gpiolib internals in order
+ * to implement a custom pin controller. The proper solution is to create
+ * a real combined pin control and GPIO driver in drivers/pinctrl. However
+ * this hack is here for legacy code reasons.
+ */
+#include "../../../gpio/gpiolib.h"
struct qe_gpio_chip {
struct of_mm_gpio_chip mm_gc;
spinlock_t lock;
- unsigned long pin_flags[QE_PIO_PINS];
-#define QE_PIN_REQUESTED 0
-
/* shadowed data register to clear/set bits safely */
u32 cpdata;
@@ -144,6 +147,7 @@ struct qe_pin {
* something like qe_pio_controller. Someday.
*/
struct qe_gpio_chip *controller;
+ struct gpio_desc *gpiod;
int num;
};
@@ -160,9 +164,8 @@ struct qe_pin *qe_pin_request(struct device_node *np, int
index)
{
struct qe_pin *qe_pin;
struct gpio_chip *gc;
- struct qe_gpio_chip *qe_gc;
+ struct gpio_desc *gpiod;
int err;
- unsigned long flags;
qe_pin = kzalloc(sizeof(*qe_pin), GFP_KERNEL);
if (!qe_pin) {
@@ -170,38 +173,36 @@ struct qe_pin *qe_pin_request(struct device_node *np, int
index)
return ERR_PTR(-ENOMEM);
}
- err = of_get_gpio(np, index);
- if (err < 0)
+ gpiod = fwnode_gpiod_get_index(of_fwnode_handle(np), NULL, index,
GPIOD_ASIS, "qe");
+ if (IS_ERR(gpiod)) {
+ err = PTR_ERR(gpiod);
+ goto err0;
+ }
+ if (!gpiod) {
+ err = -EINVAL;
goto err0;
- gc = gpio_to_chip(err);
+ }
+ gc = gpiod_to_chip(gpiod);
if (WARN_ON(!gc)) {
err = -ENODEV;
goto err0;
}
+ qe_pin->gpiod = gpiod;
+ qe_pin->controller = gpiochip_get_data(gc);
+ /*
+* FIXME: this gets the local offset on the gpio_chip so that the driver
+* can manipulate pin control settings through its custom API. The real
+* solution is to create a real pin control driver for this.
+*/
+ qe_pin->num = gpio_chip_hwgpio(gpiod);
if (!of_device_is_compatible(gc->of_node, "fsl,mpc8323-qe-pario-bank"))
{
pr_debug("%s: tried to get a non-qe pin\n", __func__);
+ gpiod_put(gpiod);
err = -EINVAL;
goto err0;
}
-
- qe_gc = gpiochip_get_data(gc);
-
- spin_lock_irqsave(_gc->lock, flags);
-
- err -= gc->base;
- if (test_and_set_bit(QE_PIN_REQUESTED, _gc->pin_flags[err]) == 0) {
- qe_pin->controller = qe_gc;
- qe_pin->num = err;
- err = 0;
- } else {
- err = -EBUSY;
- }
-
- spin_unlock_irqrestore(_gc->lock, flags);
-
- if (!err)
- return qe_pin;
+ return qe_pin;
err0:
kfree(qe_pin);
pr_debug("%s failed with status %d\n", __func__, err);
@@ -219,14 +220,7 @@ EXPORT_SYMBOL(qe_pin_request);
*/
void qe_pin_free(struct qe_pin *qe_pin)
{
- struct qe_gpio_chip *qe_gc = qe_pin->controller;
-
[PATCH v2] soc: fsl: qe: Avoid using gpio_to_desc()
We want to get rid of the old GPIO numberspace, so instead of
calling gpio_to_desc() we get the gpio descriptor for the requested
line from the device tree directly without passing through the
GPIO numberspace, and then we get the gpiochip from the descriptor.
Cc: Bartosz Golaszewski
Cc: linux-g...@vger.kernel.org
Signed-off-by: Linus Walleij
---
ChangeLog v1->v2:
- Add back the include: we are using the
mm_of_gpio_chip, which should be fixed, but not now.
---
drivers/soc/fsl/qe/gpio.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/soc/fsl/qe/gpio.c b/drivers/soc/fsl/qe/gpio.c
index 99f7de43c3c6..68d48430ab33 100644
--- a/drivers/soc/fsl/qe/gpio.c
+++ b/drivers/soc/fsl/qe/gpio.c
@@ -14,9 +14,8 @@
#include
#include
#include
+#include
#include
-/* FIXME: needed for gpio_to_chip() get rid of this */
-#include
#include
#include
#include
@@ -161,6 +160,7 @@ struct qe_pin *qe_pin_request(struct device_node *np, int
index)
struct qe_pin *qe_pin;
struct gpio_chip *gc;
struct qe_gpio_chip *qe_gc;
+ struct gpio_desc *gpiod;
int err;
unsigned long flags;
@@ -170,14 +170,21 @@ struct qe_pin *qe_pin_request(struct device_node *np, int
index)
return ERR_PTR(-ENOMEM);
}
- err = of_get_gpio(np, index);
- if (err < 0)
+ gpiod = fwnode_gpiod_get_index(of_fwnode_handle(np), NULL, index,
GPIOD_ASIS, "qe");
+ if (IS_ERR(gpiod)) {
+ err = PTR_ERR(gpiod);
goto err0;
- gc = gpio_to_chip(err);
+ }
+ if (!gpiod) {
+ err = -EINVAL;
+ goto err0;
+ }
+ gc = gpiod_to_chip(gpiod);
if (WARN_ON(!gc)) {
err = -ENODEV;
goto err0;
}
+ gpiod_put(gpiod);
if (!of_device_is_compatible(gc->of_node, "fsl,mpc8323-qe-pario-bank"))
{
pr_debug("%s: tried to get a non-qe pin\n", __func__);
--
2.34.1
[PATCH] soc: fsl: qe: Avoid using gpio_to_desc()
We want to get rid of the old GPIO numberspace, so instead of
calling gpio_to_desc() we get the gpio descriptor for the requested
line from the device tree directly without passing through the
GPIO numberspace, and then we get the gpiochip from the descriptor.
Cc: Bartosz Golaszewski
Cc: linux-g...@vger.kernel.org
Signed-off-by: Linus Walleij
---
drivers/soc/fsl/qe/gpio.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/drivers/soc/fsl/qe/gpio.c b/drivers/soc/fsl/qe/gpio.c
index 99f7de43c3c6..cc5602b679fe 100644
--- a/drivers/soc/fsl/qe/gpio.c
+++ b/drivers/soc/fsl/qe/gpio.c
@@ -13,10 +13,8 @@
#include
#include
#include
-#include
+#include
#include
-/* FIXME: needed for gpio_to_chip() get rid of this */
-#include
#include
#include
#include
@@ -161,6 +159,7 @@ struct qe_pin *qe_pin_request(struct device_node *np, int
index)
struct qe_pin *qe_pin;
struct gpio_chip *gc;
struct qe_gpio_chip *qe_gc;
+ struct gpio_desc *gpiod;
int err;
unsigned long flags;
@@ -170,14 +169,21 @@ struct qe_pin *qe_pin_request(struct device_node *np, int
index)
return ERR_PTR(-ENOMEM);
}
- err = of_get_gpio(np, index);
- if (err < 0)
+ gpiod = fwnode_gpiod_get_index(of_fwnode_handle(np), NULL, index,
GPIOD_ASIS, "qe");
+ if (IS_ERR(gpiod)) {
+ err = PTR_ERR(gpiod);
goto err0;
- gc = gpio_to_chip(err);
+ }
+ if (!gpiod) {
+ err = -EINVAL;
+ goto err0;
+ }
+ gc = gpiod_to_chip(gpiod);
if (WARN_ON(!gc)) {
err = -ENODEV;
goto err0;
}
+ gpiod_put(gpiod);
if (!of_device_is_compatible(gc->of_node, "fsl,mpc8323-qe-pario-bank"))
{
pr_debug("%s: tried to get a non-qe pin\n", __func__);
--
2.34.1
[PATCH] USB: FHCI: Switch to GPIO descriptors
This driver for the PPC Freescale SoC is using device tree
accessors and imperative GPIO semantics control using the old
GPIO API, switch it over to use GPIO descriptors.
Cc: Li Yang
Cc: linuxppc-dev@lists.ozlabs.org
Cc: Zhao Qiang
Cc: Guilherme Maciel Ferreira
Signed-off-by: Linus Walleij
---
drivers/usb/host/fhci-hcd.c | 63 +++--
drivers/usb/host/fhci-hub.c | 15 +
drivers/usb/host/fhci.h | 4 +--
3 files changed, 27 insertions(+), 55 deletions(-)
diff --git a/drivers/usb/host/fhci-hcd.c b/drivers/usb/host/fhci-hcd.c
index 2ba09c3fbc2f..95a44462bed0 100644
--- a/drivers/usb/host/fhci-hcd.c
+++ b/drivers/usb/host/fhci-hcd.c
@@ -25,8 +25,8 @@
#include
#include
#include
-#include
#include
+#include
#include
#include
#include "fhci.h"
@@ -150,15 +150,15 @@ int fhci_ioports_check_bus_state(struct fhci_hcd *fhci)
u8 bits = 0;
/* check USBOE,if transmitting,exit */
- if (!gpio_get_value(fhci->gpios[GPIO_USBOE]))
+ if (!gpiod_get_value(fhci->gpiods[GPIO_USBOE]))
return -1;
/* check USBRP */
- if (gpio_get_value(fhci->gpios[GPIO_USBRP]))
+ if (gpiod_get_value(fhci->gpiods[GPIO_USBRP]))
bits |= 0x2;
/* check USBRN */
- if (gpio_get_value(fhci->gpios[GPIO_USBRN]))
+ if (gpiod_get_value(fhci->gpiods[GPIO_USBRN]))
bits |= 0x1;
return bits;
@@ -630,40 +630,23 @@ static int of_fhci_probe(struct platform_device *ofdev)
/* GPIOs and pins */
for (i = 0; i < NUM_GPIOS; i++) {
- int gpio;
- enum of_gpio_flags flags;
-
- gpio = of_get_gpio_flags(node, i, );
- fhci->gpios[i] = gpio;
- fhci->alow_gpios[i] = flags & OF_GPIO_ACTIVE_LOW;
-
- if (!gpio_is_valid(gpio)) {
- if (i < GPIO_SPEED) {
- dev_err(dev, "incorrect GPIO%d: %d\n",
- i, gpio);
- goto err_gpios;
- } else {
- dev_info(dev, "assuming board doesn't have "
- "%s gpio\n", i == GPIO_SPEED ?
- "speed" : "power");
- continue;
- }
- }
+ if (i < GPIO_SPEED)
+ fhci->gpiods[i] = devm_gpiod_get_index(dev,
+ NULL, i, GPIOD_IN);
+
+ else
+ fhci->gpiods[i] = devm_gpiod_get_index_optional(dev,
+ NULL, i, GPIOD_OUT_LOW);
- ret = gpio_request(gpio, dev_name(dev));
- if (ret) {
- dev_err(dev, "failed to request gpio %d", i);
+ if (IS_ERR(fhci->gpiods[i])) {
+ dev_err(dev, "incorrect GPIO%d: %ld\n",
+ i, PTR_ERR(fhci->gpiods[i]));
goto err_gpios;
}
-
- if (i >= GPIO_SPEED) {
- ret = gpio_direction_output(gpio, 0);
- if (ret) {
- dev_err(dev, "failed to set gpio %d as "
- "an output\n", i);
- i++;
- goto err_gpios;
- }
+ if (!fhci->gpiods[i]) {
+ dev_info(dev, "assuming board doesn't have "
+"%s gpio\n", i == GPIO_SPEED ?
+"speed" : "power");
}
}
@@ -766,10 +749,6 @@ static int of_fhci_probe(struct platform_device *ofdev)
while (--j >= 0)
qe_pin_free(fhci->pins[j]);
err_gpios:
- while (--i >= 0) {
- if (gpio_is_valid(fhci->gpios[i]))
- gpio_free(fhci->gpios[i]);
- }
cpm_muram_free(pram_addr);
err_pram:
iounmap(hcd->regs);
@@ -782,18 +761,12 @@ static int fhci_remove(struct device *dev)
{
struct usb_hcd *hcd = dev_get_drvdata(dev);
struct fhci_hcd *fhci = hcd_to_fhci(hcd);
- int i;
int j;
usb_remove_hcd(hcd);
free_irq(fhci->timer->irq, hcd);
gtm_put_timer16(fhci->timer);
cpm_muram_free(cpm_muram_offset(fhci->pram));
- for (i = 0; i < NUM_GPIOS; i++) {
- if (!gpio_is_valid(fhci->gpios[i]))
- continue;
- gpio_free(fhci->gpios[i]);
- }
for (j = 0; j < NUM_PINS; j++)
qe_pin_free(fhci
Re: [PATCH v1 1/1] powerpc/83xx/mpc8349emitx: Get rid of of_node assignment
On Wed, Apr 6, 2022 at 3:02 PM Andy Shevchenko wrote: > On Mon, Mar 28, 2022 at 03:16:08PM +0200, Linus Walleij wrote: > > On Wed, Mar 23, 2022 at 6:43 PM Andy Shevchenko > > wrote: > > > > > Let GPIO library to assign of_node from the parent device. > > > This allows to move GPIO library and drivers to use fwnode > > > APIs instead of being stuck with OF-only interfaces. > > > > > > Signed-off-by: Andy Shevchenko > > > > That's a nice patch. > > Reviewed-by: Linus Walleij > > Thanks! > > Can we have this applied now? I think Michael Ellerman could help with this? Michael? Yours, Linus Walleij
Re: [PATCH v1 1/1] powerpc/83xx/mpc8349emitx: Get rid of of_node assignment
On Wed, Mar 23, 2022 at 6:43 PM Andy Shevchenko wrote: > Let GPIO library to assign of_node from the parent device. > This allows to move GPIO library and drivers to use fwnode > APIs instead of being stuck with OF-only interfaces. > > Signed-off-by: Andy Shevchenko That's a nice patch. Reviewed-by: Linus Walleij Yours, Linus Walleij
Re: [PATCH 09/22] gpio-winbond: Use C99 initializers
On Sat, Mar 26, 2022 at 6:00 PM Benjamin Stürz wrote: > This replaces comments with C99's designated > initializers because the kernel supports them now. > > Signed-off-by: Benjamin Stürz Reviewed-by: Linus Walleij Yours, Linus Walleij
[PATCH] RFC: powerpc: wii.dts: Fix up GPIO I2C bus
This portion of the device tree just looks weird to me.
We have a standard way of doing I2C-over-GPIO and it is
a separate device tree node outside of the SoC node, not
inside the GPIO node.
Cc: Emmanuel Gil Peyrot
Cc: Jonathan Neuschäfer
Cc: Albert Herranz
Cc: Michael Ellerman
Cc: Alexandre Belloni
Signed-off-by: Linus Walleij
---
arch/powerpc/boot/dts/wii.dts | 43 ++-
1 file changed, 17 insertions(+), 26 deletions(-)
diff --git a/arch/powerpc/boot/dts/wii.dts b/arch/powerpc/boot/dts/wii.dts
index e46143c32308..2e51100d2dab 100644
--- a/arch/powerpc/boot/dts/wii.dts
+++ b/arch/powerpc/boot/dts/wii.dts
@@ -192,31 +192,6 @@ GPIO: gpio@d8000c0 {
#interrupt-cells = <2>;
interrupts = <10>;
interrupt-parent = <>;
-
- /*
-* This is commented out while a standard binding
-* for i2c over gpio is defined.
-*/
- /*
- i2c-video {
- #address-cells = <1>;
- #size-cells = <0>;
- compatible = "i2c-gpio";
-
- gpios = < 15 0
- 14 0>;
- clock-frequency = <25>;
- no-clock-stretching;
- scl-is-open-drain;
- sda-is-open-drain;
- sda-enforce-dir;
-
- AVE: audio-video-encoder@70 {
- compatible =
"nintendo,wii-audio-video-encoder";
- reg = <0x70>;
- };
- };
- */
};
control@d800100 {
@@ -268,5 +243,21 @@ eject {
linux,code = ;
};
};
-};
+ i2c-video {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "i2c-gpio";
+
+ sda-gpios = < 15 (GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN)>;
+ scl-gpios = < 14 (GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN)>;
+ clock-frequency = <25>;
+ no-clock-stretching;
+ sda-enforce-dir;
+
+ AVE: audio-video-encoder@70 {
+ compatible = "nintendo,wii-audio-video-encoder";
+ reg = <0x70>;
+ };
+ };
+};
--
2.35.1
[PATCH] spi: mpc512x-psc: Fix compile errors
My patch created compilation bugs in the MPC512x-PSC driver.
Fix them up.
Cc: Uwe Kleine-König
Cc: Anatolij Gustschin
Cc: linuxppc-dev@lists.ozlabs.org
Reported-by: kernel test robot
Fixes: 2818824ced4b (" spi: mpc512x-psc: Convert to use GPIO descriptors")
Signed-off-by: Linus Walleij
---
(This is because I don't have a PPC cross compiler.)
---
drivers/spi/spi-mpc512x-psc.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/spi/spi-mpc512x-psc.c b/drivers/spi/spi-mpc512x-psc.c
index 8a488d8e4c1b..03630359ce70 100644
--- a/drivers/spi/spi-mpc512x-psc.c
+++ b/drivers/spi/spi-mpc512x-psc.c
@@ -127,7 +127,7 @@ static void mpc512x_psc_spi_activate_cs(struct spi_device
*spi)
out_be32(psc_addr(mps, ccr), ccr);
mps->bits_per_word = cs->bits_per_word;
- if (cs->gpiod) {
+ if (spi->cs_gpiod) {
if (mps->cs_control)
/* boardfile override */
mps->cs_control(spi, (spi->mode & SPI_CS_HIGH) ? 1 : 0);
@@ -373,7 +373,6 @@ static int mpc512x_psc_spi_unprep_xfer_hw(struct spi_master
*master)
static int mpc512x_psc_spi_setup(struct spi_device *spi)
{
struct mpc512x_psc_spi_cs *cs = spi->controller_state;
- int ret;
if (spi->bits_per_word % 8)
return -EINVAL;
--
2.34.1
[PATCH v2] spi: mpc512x-psc: Convert to use GPIO descriptors
This driver is already relying on the core to provide
valid GPIO numbers in spi->cs_gpio through
of_spi_get_gpio_numbers(), so we can switch to letting
the core use GPIO descriptors instead.
The driver was assigning a local function to the custom
chipselect callback, but I chose to just open code the
gpiod setting instead, this is easier to read.
The only platform that overrides the cs_control callback
is the mpc832x_rdb.
Cc: Uwe Kleine-König
Cc: Anatolij Gustschin
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Linus Walleij
---
ChangeLog v1->v2:
- Stop trying to use the core per-transfer CS handling,
keep the old code intact around this and just deal with
the GPIO descriptors.
I can't really compile any PPC code, I just hope I coded
this right...
---
drivers/spi/spi-mpc512x-psc.c | 46 ++-
1 file changed, 18 insertions(+), 28 deletions(-)
diff --git a/drivers/spi/spi-mpc512x-psc.c b/drivers/spi/spi-mpc512x-psc.c
index 78a9bca8cc68..8a488d8e4c1b 100644
--- a/drivers/spi/spi-mpc512x-psc.c
+++ b/drivers/spi/spi-mpc512x-psc.c
@@ -23,7 +23,6 @@
#include
#include
#include
-#include
#include
enum {
@@ -128,17 +127,28 @@ static void mpc512x_psc_spi_activate_cs(struct spi_device
*spi)
out_be32(psc_addr(mps, ccr), ccr);
mps->bits_per_word = cs->bits_per_word;
- if (mps->cs_control && gpio_is_valid(spi->cs_gpio))
- mps->cs_control(spi, (spi->mode & SPI_CS_HIGH) ? 1 : 0);
+ if (cs->gpiod) {
+ if (mps->cs_control)
+ /* boardfile override */
+ mps->cs_control(spi, (spi->mode & SPI_CS_HIGH) ? 1 : 0);
+ else
+ /* gpiolib will deal with the inversion */
+ gpiod_set_value(spi->cs_gpiod, 1);
+ }
}
static void mpc512x_psc_spi_deactivate_cs(struct spi_device *spi)
{
struct mpc512x_psc_spi *mps = spi_master_get_devdata(spi->master);
- if (mps->cs_control && gpio_is_valid(spi->cs_gpio))
- mps->cs_control(spi, (spi->mode & SPI_CS_HIGH) ? 0 : 1);
-
+ if (spi->cs_gpiod) {
+ if (mps->cs_control)
+ /* boardfile override */
+ mps->cs_control(spi, (spi->mode & SPI_CS_HIGH) ? 0 : 1);
+ else
+ /* gpiolib will deal with the inversion */
+ gpiod_set_value(spi->cs_gpiod, 0);
+ }
}
/* extract and scale size field in txsz or rxsz */
@@ -373,18 +383,6 @@ static int mpc512x_psc_spi_setup(struct spi_device *spi)
if (!cs)
return -ENOMEM;
- if (gpio_is_valid(spi->cs_gpio)) {
- ret = gpio_request(spi->cs_gpio, dev_name(>dev));
- if (ret) {
- dev_err(>dev, "can't get CS gpio: %d\n",
- ret);
- kfree(cs);
- return ret;
- }
- gpio_direction_output(spi->cs_gpio,
- spi->mode & SPI_CS_HIGH ? 0 : 1);
- }
-
spi->controller_state = cs;
}
@@ -396,8 +394,6 @@ static int mpc512x_psc_spi_setup(struct spi_device *spi)
static void mpc512x_psc_spi_cleanup(struct spi_device *spi)
{
- if (gpio_is_valid(spi->cs_gpio))
- gpio_free(spi->cs_gpio);
kfree(spi->controller_state);
}
@@ -476,11 +472,6 @@ static irqreturn_t mpc512x_psc_spi_isr(int irq, void
*dev_id)
return IRQ_NONE;
}
-static void mpc512x_spi_cs_control(struct spi_device *spi, bool onoff)
-{
- gpio_set_value(spi->cs_gpio, onoff);
-}
-
static int mpc512x_psc_spi_do_probe(struct device *dev, u32 regaddr,
u32 size, unsigned int irq)
{
@@ -500,9 +491,7 @@ static int mpc512x_psc_spi_do_probe(struct device *dev, u32
regaddr,
mps->type = (int)of_device_get_match_data(dev);
mps->irq = irq;
- if (pdata == NULL) {
- mps->cs_control = mpc512x_spi_cs_control;
- } else {
+ if (pdata) {
mps->cs_control = pdata->cs_control;
master->bus_num = pdata->bus_num;
master->num_chipselect = pdata->max_chipselect;
@@ -513,6 +502,7 @@ static int mpc512x_psc_spi_do_probe(struct device *dev, u32
regaddr,
master->prepare_transfer_hardware = mpc512x_psc_spi_prep_xfer_hw;
master->transfer_one_message = mpc512x_psc_spi_msg_xfer;
master->unprepare_transfer_hardware = mpc512x_psc_spi_unprep_xfer_hw;
+ master->use_gpio_descriptors = true;
master->cleanup = mpc512x_psc_spi_cleanup;
master->dev.of_node = dev->of_node;
--
2.34.1
Re: [PATCH v5 00/14] PCI: Add support for Apple M1
On Mon, Oct 4, 2021 at 9:52 PM Rob Herring wrote: > FYI, I pushed patches 1-3 to kernelCI and didn't see any regressions. > I am a bit worried about changes to the DT interrupt parsing and > ancient platforms (such as PowerMacs). Most likely there wouldn't be > any report until -rc1 or months later on those old systems. Lets page the PPC lists to see if someone can test on some powermac. Linus Walleij
Re: [PATCH 02/17] rtc: pl031: use RTC_FEATURE_ALARM
On Mon, Jan 11, 2021 at 12:18 AM Alexandre Belloni wrote: > Clear RTC_FEATURE_ALARM instead of setting set_alarm, read_alarm and > alarm_irq_enable to NULL. > > Signed-off-by: Alexandre Belloni Acked-by: Linus Walleij Yours, Linus Walleij
[PATCH 2/2] spi: mpc512x-psc: Convert to use GPIO descriptors
This driver is already relying on the core to provide
valid GPIO numbers in spi->cs_gpio through
of_spi_get_gpio_numbers(), so we can switch to letting
the core use GPIO descriptors instead.
Make sure that the .set_cs() is always called, as some controller
set-up is also needed.
Cc: Uwe Kleine-König
Cc: Anatolij Gustschin
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Linus Walleij
---
drivers/spi/spi-mpc512x-psc.c | 33 +++--
1 file changed, 7 insertions(+), 26 deletions(-)
diff --git a/drivers/spi/spi-mpc512x-psc.c b/drivers/spi/spi-mpc512x-psc.c
index 35313a77f977..dd8bba408301 100644
--- a/drivers/spi/spi-mpc512x-psc.c
+++ b/drivers/spi/spi-mpc512x-psc.c
@@ -23,7 +23,6 @@
#include
#include
#include
-#include
#include
enum {
@@ -99,7 +98,7 @@ static void mpc512x_psc_spi_set_cs(struct spi_device *spi,
bool enable)
u16 bclkdiv;
if (!enable) {
- if (mps->cs_control && gpio_is_valid(spi->cs_gpio))
+ if (mps->cs_control && spi->cs_gpiod)
mps->cs_control(spi, (spi->mode & SPI_CS_HIGH) ? 0 : 1);
return;
}
@@ -134,7 +133,7 @@ static void mpc512x_psc_spi_set_cs(struct spi_device *spi,
bool enable)
out_be32(psc_addr(mps, ccr), ccr);
mps->bits_per_word = cs->bits_per_word;
- if (mps->cs_control && gpio_is_valid(spi->cs_gpio))
+ if (mps->cs_control && spi->cs_gpiod)
mps->cs_control(spi, (spi->mode & SPI_CS_HIGH) ? 1 : 0);
}
@@ -358,18 +357,6 @@ static int mpc512x_psc_spi_setup(struct spi_device *spi)
if (!cs)
return -ENOMEM;
- if (gpio_is_valid(spi->cs_gpio)) {
- ret = gpio_request(spi->cs_gpio, dev_name(>dev));
- if (ret) {
- dev_err(>dev, "can't get CS gpio: %d\n",
- ret);
- kfree(cs);
- return ret;
- }
- gpio_direction_output(spi->cs_gpio,
- spi->mode & SPI_CS_HIGH ? 0 : 1);
- }
-
spi->controller_state = cs;
}
@@ -381,8 +368,6 @@ static int mpc512x_psc_spi_setup(struct spi_device *spi)
static void mpc512x_psc_spi_cleanup(struct spi_device *spi)
{
- if (gpio_is_valid(spi->cs_gpio))
- gpio_free(spi->cs_gpio);
kfree(spi->controller_state);
}
@@ -461,11 +446,6 @@ static irqreturn_t mpc512x_psc_spi_isr(int irq, void
*dev_id)
return IRQ_NONE;
}
-static void mpc512x_spi_cs_control(struct spi_device *spi, bool onoff)
-{
- gpio_set_value(spi->cs_gpio, onoff);
-}
-
static int mpc512x_psc_spi_do_probe(struct device *dev, u32 regaddr,
u32 size, unsigned int irq)
{
@@ -485,10 +465,8 @@ static int mpc512x_psc_spi_do_probe(struct device *dev,
u32 regaddr,
mps->type = (int)of_device_get_match_data(dev);
mps->irq = irq;
- if (pdata == NULL) {
- mps->cs_control = mpc512x_spi_cs_control;
- } else {
- mps->cs_control = pdata->cs_control;
+ if (pdata) {
+ mps->cs_control = pdata->cs_control;x
master->bus_num = pdata->bus_num;
master->num_chipselect = pdata->max_chipselect;
}
@@ -499,6 +477,9 @@ static int mpc512x_psc_spi_do_probe(struct device *dev, u32
regaddr,
master->transfer_one_message = mpc512x_psc_spi_msg_xfer;
master->unprepare_transfer_hardware = mpc512x_psc_spi_unprep_xfer_hw;
master->set_cs = mpc512x_psc_spi_set_cs;
+ /* This makes sure our custom .set_cs() is always called */
+ master->flags = SPI_MASTER_GPIO_SS;
+ master->use_gpio_descriptors = true;
master->cleanup = mpc512x_psc_spi_cleanup;
master->dev.of_node = dev->of_node;
--
2.26.2
[PATCH 1/2] spi: mpc512x-psc: Use the framework .set_cs()
The mpc512x-psc is rolling its own chip select control code,
but the SPI master framework can handle this. It was also
evaluating the CS status for each transfer but the CS change
should be per-message not per-transfer.
Switch to use the core .set_cs() to control the chip select.
Cc: Uwe Kleine-König
Cc: Anatolij Gustschin
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Linus Walleij
---
drivers/spi/spi-mpc512x-psc.c | 30 --
1 file changed, 8 insertions(+), 22 deletions(-)
diff --git a/drivers/spi/spi-mpc512x-psc.c b/drivers/spi/spi-mpc512x-psc.c
index ea1b07953d38..35313a77f977 100644
--- a/drivers/spi/spi-mpc512x-psc.c
+++ b/drivers/spi/spi-mpc512x-psc.c
@@ -89,7 +89,7 @@ static int mpc512x_psc_spi_transfer_setup(struct spi_device
*spi,
return 0;
}
-static void mpc512x_psc_spi_activate_cs(struct spi_device *spi)
+static void mpc512x_psc_spi_set_cs(struct spi_device *spi, bool enable)
{
struct mpc512x_psc_spi_cs *cs = spi->controller_state;
struct mpc512x_psc_spi *mps = spi_master_get_devdata(spi->master);
@@ -98,6 +98,12 @@ static void mpc512x_psc_spi_activate_cs(struct spi_device
*spi)
int speed;
u16 bclkdiv;
+ if (!enable) {
+ if (mps->cs_control && gpio_is_valid(spi->cs_gpio))
+ mps->cs_control(spi, (spi->mode & SPI_CS_HIGH) ? 0 : 1);
+ return;
+ }
+
sicr = in_be32(psc_addr(mps, sicr));
/* Set clock phase and polarity */
@@ -132,15 +138,6 @@ static void mpc512x_psc_spi_activate_cs(struct spi_device
*spi)
mps->cs_control(spi, (spi->mode & SPI_CS_HIGH) ? 1 : 0);
}
-static void mpc512x_psc_spi_deactivate_cs(struct spi_device *spi)
-{
- struct mpc512x_psc_spi *mps = spi_master_get_devdata(spi->master);
-
- if (mps->cs_control && gpio_is_valid(spi->cs_gpio))
- mps->cs_control(spi, (spi->mode & SPI_CS_HIGH) ? 0 : 1);
-
-}
-
/* extract and scale size field in txsz or rxsz */
#define MPC512x_PSC_FIFO_SZ(sz) ((sz & 0x7ff) << 2);
@@ -290,40 +287,28 @@ static int mpc512x_psc_spi_msg_xfer(struct spi_master
*master,
struct spi_message *m)
{
struct spi_device *spi;
- unsigned cs_change;
int status;
struct spi_transfer *t;
spi = m->spi;
- cs_change = 1;
status = 0;
list_for_each_entry(t, >transfers, transfer_list) {
status = mpc512x_psc_spi_transfer_setup(spi, t);
if (status < 0)
break;
- if (cs_change)
- mpc512x_psc_spi_activate_cs(spi);
- cs_change = t->cs_change;
-
status = mpc512x_psc_spi_transfer_rxtx(spi, t);
if (status)
break;
m->actual_length += t->len;
spi_transfer_delay_exec(t);
-
- if (cs_change)
- mpc512x_psc_spi_deactivate_cs(spi);
}
m->status = status;
if (m->complete)
m->complete(m->context);
- if (status || !cs_change)
- mpc512x_psc_spi_deactivate_cs(spi);
-
mpc512x_psc_spi_transfer_setup(spi, NULL);
spi_finalize_current_message(master);
@@ -513,6 +498,7 @@ static int mpc512x_psc_spi_do_probe(struct device *dev, u32
regaddr,
master->prepare_transfer_hardware = mpc512x_psc_spi_prep_xfer_hw;
master->transfer_one_message = mpc512x_psc_spi_msg_xfer;
master->unprepare_transfer_hardware = mpc512x_psc_spi_unprep_xfer_hw;
+ master->set_cs = mpc512x_psc_spi_set_cs;
master->cleanup = mpc512x_psc_spi_cleanup;
master->dev.of_node = dev->of_node;
--
2.26.2
[PATCH] spi: ppc4xx: Convert to use GPIO descriptors
This converts the PPC4xx SPI driver to use GPIO descriptors.
The driver is already just picking some GPIOs from the device
tree so the conversion is pretty straight forward. However
this driver is looking form a pure "gpios" property rather
than the standard binding "cs-gpios" so we need to add a new
exception to the gpiolib OF parser to allow this for this
driver's compatibles.
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Linus Walleij
---
drivers/gpio/gpiolib-of.c | 10 ++--
drivers/spi/spi-ppc4xx.c | 106 --
2 files changed, 17 insertions(+), 99 deletions(-)
diff --git a/drivers/gpio/gpiolib-of.c b/drivers/gpio/gpiolib-of.c
index 219eb0054233..e3e88510aec7 100644
--- a/drivers/gpio/gpiolib-of.c
+++ b/drivers/gpio/gpiolib-of.c
@@ -26,7 +26,7 @@
/**
* of_gpio_spi_cs_get_count() - special GPIO counting for SPI
* Some elder GPIO controllers need special quirks. Currently we handle
- * the Freescale GPIO controller with bindings that doesn't use the
+ * the Freescale and PPC GPIO controller with bindings that doesn't use the
* established "cs-gpios" for chip selects but instead rely on
* "gpios" for the chip select lines. If we detect this, we redirect
* the counting of "cs-gpios" to count "gpios" transparent to the
@@ -41,7 +41,8 @@ static int of_gpio_spi_cs_get_count(struct device *dev, const
char *con_id)
if (!con_id || strcmp(con_id, "cs"))
return 0;
if (!of_device_is_compatible(np, "fsl,spi") &&
- !of_device_is_compatible(np, "aeroflexgaisler,spictrl"))
+ !of_device_is_compatible(np, "aeroflexgaisler,spictrl") &&
+ !of_device_is_compatible(np, "ibm,ppc4xx-spi"))
return 0;
return of_gpio_named_count(np, "gpios");
}
@@ -405,9 +406,10 @@ static struct gpio_desc *of_find_spi_cs_gpio(struct device
*dev,
if (!IS_ENABLED(CONFIG_SPI_MASTER))
return ERR_PTR(-ENOENT);
- /* Allow this specifically for Freescale devices */
+ /* Allow this specifically for Freescale and PPC devices */
if (!of_device_is_compatible(np, "fsl,spi") &&
- !of_device_is_compatible(np, "aeroflexgaisler,spictrl"))
+ !of_device_is_compatible(np, "aeroflexgaisler,spictrl") &&
+ !of_device_is_compatible(np, "ibm,ppc4xx-spi"))
return ERR_PTR(-ENOENT);
/* Allow only if asking for "cs-gpios" */
if (!con_id || strcmp(con_id, "cs"))
diff --git a/drivers/spi/spi-ppc4xx.c b/drivers/spi/spi-ppc4xx.c
index 0ea2d9a369d9..d8ee363fb714 100644
--- a/drivers/spi/spi-ppc4xx.c
+++ b/drivers/spi/spi-ppc4xx.c
@@ -28,11 +28,9 @@
#include
#include
#include
-#include
#include
#include
-#include
#include
#include
@@ -127,8 +125,6 @@ struct ppc4xx_spi {
const unsigned char *tx;
unsigned char *rx;
- int *gpios;
-
struct spi_ppc4xx_regs __iomem *regs; /* pointer to the registers */
struct spi_master *master;
struct device *dev;
@@ -260,27 +256,6 @@ static int spi_ppc4xx_setup(struct spi_device *spi)
return 0;
}
-static void spi_ppc4xx_chipsel(struct spi_device *spi, int value)
-{
- struct ppc4xx_spi *hw = spi_master_get_devdata(spi->master);
- unsigned int cs = spi->chip_select;
- unsigned int cspol;
-
- /*
-* If there are no chip selects at all, or if this is the special
-* case of a non-existent (dummy) chip select, do nothing.
-*/
-
- if (!hw->master->num_chipselect || hw->gpios[cs] == -EEXIST)
- return;
-
- cspol = spi->mode & SPI_CS_HIGH ? 1 : 0;
- if (value == BITBANG_CS_INACTIVE)
- cspol = !cspol;
-
- gpio_set_value(hw->gpios[cs], cspol);
-}
-
static irqreturn_t spi_ppc4xx_int(int irq, void *dev_id)
{
struct ppc4xx_spi *hw;
@@ -359,19 +334,6 @@ static void spi_ppc4xx_enable(struct ppc4xx_spi *hw)
dcri_clrset(SDR0, SDR0_PFC1, 0x8000 >> 14, 0);
}
-static void free_gpios(struct ppc4xx_spi *hw)
-{
- if (hw->master->num_chipselect) {
- int i;
- for (i = 0; i < hw->master->num_chipselect; i++)
- if (gpio_is_valid(hw->gpios[i]))
- gpio_free(hw->gpios[i]);
-
- kfree(hw->gpios);
- hw->gpios = NULL;
- }
-}
-
/*
* platform_device layer stuff...
*/
@@ -385,7 +347,6 @@ static int spi_ppc4xx_of_probe(struct platform_device *op)
struct device *dev = >dev;
struct device_node *opbnp;
int ret;
- int num_gpios;
const unsigned int *clk;
master = spi_alloc_master(dev, sizeof *hw);
@@ -399
Re: [PATCH v2] tty: serial: cpm_uart: Fix behaviour for non existing GPIOs
On Fri, Jun 12, 2020 at 8:26 PM Christophe Leroy
wrote:
> devm_gpiod_get_index() doesn't return NULL but -ENOENT when the
> requested GPIO doesn't exist, leading to the following messages:
>
> [2.742468] gpiod_direction_input: invalid GPIO (errorpointer)
> [2.748147] can't set direction for gpio #2: -2
> [2.753081] gpiod_direction_input: invalid GPIO (errorpointer)
> [2.758724] can't set direction for gpio #3: -2
> [2.763666] gpiod_direction_output: invalid GPIO (errorpointer)
> [2.769394] can't set direction for gpio #4: -2
> [2.774341] gpiod_direction_input: invalid GPIO (errorpointer)
> [2.779981] can't set direction for gpio #5: -2
> [2.784545] ff000a20.serial: ttyCPM1 at MMIO 0xfff00a20 (irq = 39,
> base_baud = 825) is a CPM UART
>
> Use devm_gpiod_get_index_optional() instead.
>
> At the same time, handle the error case and properly exit
> with an error.
>
> Fixes: 97cbaf2c829b ("tty: serial: cpm_uart: Convert to use GPIO descriptors")
> Cc: sta...@vger.kernel.org
> Cc: Linus Walleij
> Signed-off-by: Christophe Leroy
> ---
> v2: Using devm_gpiod_get_index_optional() and exiting if error
Excellent!
Reviewed-by: Linus Walleij
Yours,
Linus Walleij
Re: [PATCH] tty: serial: cpm_uart: Fix behaviour for non existing GPIOs
Hi Christophe!
On Sat, Jun 6, 2020 at 9:30 AM Christophe Leroy
wrote:
> gpiod = devm_gpiod_get_index(dev, NULL, i, GPIOD_ASIS);
>
> - if (gpiod) {
> + if (!IS_ERR_OR_NULL(gpiod)) {
> if (i == GPIO_RTS || i == GPIO_DTR)
> ret = gpiod_direction_output(gpiod, 0);
> else
This code, and the way descriptors are used in the driver leads
me to believe that the right solution is to use the optional
call with a hard error check:
gpiod = devm_gpiod_get_index_optional(...);
if (IS_ERR(gpiod))
return PTR_ERR(gpiod);
if (gpiod) {
... followed by the old code ...
This makes sure that the array member is left NULL if there is no
GPIO on this line, and all other errors, such as -EPROBE_DEFER
which currently absolutely does not work, will lead to us properly
exiting with an error.
Yours,
Linus Walleij
Re: [PATCH] powerpc/devicetrees: Change 'gpios' to 'cs-gpios' on fsl,spi nodes
On Thu, Nov 28, 2019 at 1:16 PM Christophe Leroy
wrote:
> Since commit 0f0581b24bd0 ("spi: fsl: Convert to use CS GPIO
> descriptors"), the prefered way to define chipselect GPIOs is using
> 'cs-gpios' property instead of the legacy 'gpios' property.
>
> Signed-off-by: Christophe Leroy
Reviewed-by: Linus Walleij
Yours,
Linus Walleij
Re: [PATCH] gpio: max7301: fix driver for use with CONFIG_VMAP_STACK
On Fri, Dec 7, 2018 at 2:07 PM Christophe Leroy wrote:
> spi_read() and spi_write() require DMA-safe memory. When
> CONFIG_VMAP_STACK is selected, those functions cannot be used
> with buffers on stack.
>
> This patch replaces calls to spi_read() and spi_write() by
> spi_write_then_read() which doesn't require DMA-safe buffers.
>
> Fixes: 0c36ec314735 ("gpio: gpio driver for max7301 SPI GPIO expander")
> Cc:
> Signed-off-by: Christophe Leroy
Patch applied for fixes.
Yours,
Linus Walleij
Re: [PATCH v1 1/1] misc: IBM Virtual Management Channel Driver
VSCSI server device, What is that acronym now, I get completely confused. > is presented to a designated > +management partition as a virtual device and is only presented when the > +system is not HMC managed. > +This communication device borrows aspects from both VSCSI and ILLAN devices Now there is ILLAN too. > +and is implemented using the CRQ and the RDMA interfaces. CRQ and RDMA. The RDMA I heard about, I wonder what CRQ is. At this point the document is referring to so much external a priori knowledge that I don't have that I don't understand anything at all. So if this document is meant as an introduction to the technology for newcomers, it's not working at all, unfortunately. If some specific domain knowledge is needed to read and understand the document, you need to state these prerequisites at the beginning of the document. Something like: "if you don't know a lot about virtualization already, then don't even bother trying to read this document". Yours, Linus Walleij
Re: [PATCH v3 2/4] gpio: Add GPIO driver for Nintendo Wii
On Fri, Feb 9, 2018 at 1:07 PM, Jonathan Neuschäfer <j.neuschae...@gmx.net> wrote: > The Nintendo Wii's chipset (called "Hollywood") has a GPIO controller > that supports a configurable number of pins (up to 32), interrupts, and > some special mechanisms to share the controller between the system's > security processor (an ARM926) and the PowerPC CPU. Pin multiplexing is > not supported. > > This patch adds a basic driver for this GPIO controller. Interrupt > support will come in a later patch. > > This patch is based on code developed by Albert Herranz and the GameCube > Linux Team, file arch/powerpc/platforms/embedded6xx/hlwd-gpio.c, > available at https://github.com/DeltaResero/GC-Wii-Linux-Kernels, but > has grown quite dissimilar. > > Signed-off-by: Jonathan Neuschäfer <j.neuschae...@gmx.net> > Cc: Albert Herranz <albert_herr...@yahoo.es> > Cc: Segher Boessenkool <seg...@kernel.crashing.org> > <--- > > v3: > - Do some style cleanups, as suggest by Andy Shevchenko Patch applied to the GPIO tree for v4.17 with all the review tags. I just folded the changelog into the commit message, for new drivers it is sometimes useful to keep these around in git actually. If any further changes are needed we can just patch on top of this. It's a very pretty driver, good work! Yours, Linus Walleij
Re: [PATCH v2 3/6] gpio: Add GPIO driver for Nintendo Wii
On Mon, Jan 22, 2018 at 6:04 AM, Jonathan Neuschäfer <j.neuschae...@gmx.net> wrote: > The Nintendo Wii's chipset (called "Hollywood") has a GPIO controller > that supports a configurable number of pins (up to 32), interrupts, and > some special mechanisms to share the controller between the system's > security processor (an ARM926) and the PowerPC CPU. Pin multiplexing is > not supported. > > This patch adds a basic driver for this GPIO controller. Interrupt > support will come in a later patch. > > This patch is based on code developed by Albert Herranz and the GameCube > Linux Team, file arch/powerpc/platforms/embedded6xx/hlwd-gpio.c, > available at https://github.com/DeltaResero/GC-Wii-Linux-Kernels, but > has grown quite dissimilar. > > Signed-off-by: Jonathan Neuschäfer <j.neuschae...@gmx.net> > Cc: Albert Herranz <albert_herr...@yahoo.es> > Cc: Segher Boessenkool <seg...@kernel.crashing.org> > --- > > v2: All looks very good to me, Andy had some additional comments, once addressed in v3 I will apply this. You only need to resend this patch as I already applied the DT bindings. Yours, Linus Walleij
Re: [PATCH v2 4/6] dt-bindings: gpio: Add binding for Wii GPIO controller
On Mon, Jan 22, 2018 at 6:04 AM, Jonathan Neuschäfer <j.neuschae...@gmx.net> wrote: > The Nintendo Wii game console has a GPIO controller, which is used for > the optical disk slot LED, buttons, poweroff, etc. This patch adds a > binding for this GPIO controller. > > Signed-off-by: Jonathan Neuschäfer <j.neuschae...@gmx.net> > Reviewed-by: Rob Herring <r...@kernel.org> > --- > > v2: Patch applied for 4.17. Yours, Linus Walleij
Re: [PATCH 3/6] gpio: Add GPIO driver for Nintendo Wii
On Mon, Jan 15, 2018 at 4:13 AM, Jonathan Neuschäfer
<j.neuschae...@gmx.net> wrote:
> This patch is based on code developed by Albert Herranz and the GameCube
> Linux Team, file arch/powerpc/platforms/embedded6xx/hlwd-gpio.c,
> available at https://github.com/DeltaResero/GC-Wii-Linux-Kernels, but
> has grown quite dissimilar.
I'm impressed by this effort. As with all reverse engineering.
> This driver currently uses __raw_readl and __raw_writel to access the
> GPIO controller's MMIO registers. I wonder if readl/writel plus explicit
> byte-swapping would be more correct, because it could be independent of
> the CPU's endianness. That said, this hardware only exists in two
> big-endian machines (Wii and Wii U).
I don't know about PPC but I think you're supposed to use
ioread32be() and iowrite32be() to do explicit BE access.
But when I look at it, I think you can just use the gpio-mmio library
for this driver and cut down code cosiderably.
> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
Can't you just save a pointer to struct device *dev in the
state container and use dev_info(state->dev, ...) etc instead
of this?
> +#include
This include should not be needed.
> +/*
> + * Update the bit with the given bit offset in the given register to a given
> + * value
> + */
> +static void hlwd_gpio_update_bit(struct gpio_chip *gc, unsigned int reg,
> + int offset, int value)
> +{
> + struct hlwd_gpio *hlwd = gpiochip_get_data(gc);
> + unsigned long flags;
> + u32 bit = 1UL << offset;
#include
u32 bit = BIT(offset);
> + u32 tmp;
> +
> + spin_lock_irqsave(>lock, flags);
> + tmp = __raw_readl(hlwd->regs + reg);
> + if (value)
> + __raw_writel(tmp | bit, hlwd->regs + reg);
> + else
> + __raw_writel(tmp & ~bit, hlwd->regs + reg);
> + spin_unlock_irqrestore(>lock, flags);
> +}
This looks very much like it is reimplementing the stuff we already
have in drivers/gpio/gpio-mmio.h.
There is even a big endian access flag for the library.
And you get so much for free with gpio-mmio.
select GPIO_GENERIC
in Kconfig
the helpers come in from
Look at other drivers for inspiration:
git grep bgpio_init
If you need IRQ support you should probably have your own file
for this driver, but it will be just a few lines of wrapper using
bgpio_init() and BGPIOF_BIG_ENDIAN and/or possibly
BGPIOF_BIG_ENDIAN_BYTE_ORDER.
See the other drivers.
Yours,
Linus Walleij
Re: [PATCH 4/6] dt-bindings: gpio: Add binding for Wii GPIO controller
On Mon, Jan 15, 2018 at 4:13 AM, Jonathan Neuschäfer <j.neuschae...@gmx.net> wrote: maybe some small blurb here? > Signed-off-by: Jonathan Neuschäfer <j.neuschae...@gmx.net> It looks good, very standard bindings. Yours, Linus Walleij
Re: [PATCH] machintosh: select defaults for cooling
On Sat, Jul 15, 2017 at 12:53 AM, Benjamin Herrenschmidt <b...@kernel.crashing.org> wrote: > On Fri, 2017-07-14 at 13:46 +0200, Linus Walleij wrote: >> I have this pretty nasty problem when trying to boot up a fresh >> openSuSE DVD on a PowerMac G5: the kernel by default does not have >> CONFIG_WINDFARM_PM72 enabled, with the effect that the cooling >> is not functioning. >> >> The BIOS on the PowerMac G5 reacts to this by, after a grace >> period when the BIOS has waited for the OS to take over, increasing >> the fan speeds so it sounds like an airplane is in the room, and >> after another grace period simply cutting the power to the >> machine. This is done not beacuse the cooling is not working, but >> because the BIOS is not recieving handover of cooling from the >> OS, so it panics and give up. The problem has been reported by >> Linux users online. > > It's not actually the BIOS but the fan controller HW who does that. OK then :) Are you running this hardware BTW? >> I think this will make install images work in the G5 Macs. > > Why is it not the job of the defconfig ? I was under the impression > that just "selecting" like this was frowned upon ? I don't care much > either way mind you, I'll let Michael decide what he wants to do. I think nobody is happy with Kconfig really. This relates to a recent Kconfig unmanageability discussion at ksummit-discuss I'd say. The situation is not great, it is very hard to make working configs and this patch is meant to help with that using the crude tools we have. I prefer to just think about making it easy to do the right thing. And making Kconfig do the right thing without human intervention, because humans just screw everything up. As is proven by the openSuSE install media situation. They simply have no clue what to enable to create an installable powermac media, even though they obviously know their way around ppc64, it's just too hard to get the Kconfig right. So if I patch arch/arm/configs/g5_defconfig it starts working for me, true. But I would not be surprised if the distros just forget to sync their configs with g5_defconfig so it doesn't help at all but instead I have to go and poke everyone and their dog about it. Debian obviously had this enabled in *their* defconfig, because that installed just fine with their Jessue distro. They have since dropped support for ppc64 yay. An alternative option is to go in and patch drivers/cpufreq/Kconfig.powerpc like that: config CPU_FREQ_PMAC64 bool "Support for some Apple G5s" depends on PPC_PMAC && PPC64 +select WINDFARM +select WINDFARM_PM81 +select WINDFARM_PM72 +select WINDFARM_RM31 +select WINDFARM_PM91 +select WINDFARM_PM112 +select WINDFARM_PM121 If that is preferred? Yours, Linus Walleij
[PATCH] machintosh: select defaults for cooling
I have this pretty nasty problem when trying to boot up a fresh openSuSE DVD on a PowerMac G5: the kernel by default does not have CONFIG_WINDFARM_PM72 enabled, with the effect that the cooling is not functioning. The BIOS on the PowerMac G5 reacts to this by, after a grace period when the BIOS has waited for the OS to take over, increasing the fan speeds so it sounds like an airplane is in the room, and after another grace period simply cutting the power to the machine. This is done not beacuse the cooling is not working, but because the BIOS is not recieving handover of cooling from the OS, so it panics and give up. The problem has been reported by Linux users online. Needless to say, this makes it impossible to install the OS before the machine turns itself off. The g5_defconfig looks like this: CONFIG_PMAC_SMU=y CONFIG_WINDFARM=y CONFIG_WINDFARM_PM81=y CONFIG_WINDFARM_PM91=y CONFIG_WINDFARM_PM112=y CONFIG_WINDFARM_PM121=y Notably PM72 is missing, making the PowerMac G5 fail. The defconfig is not the right place to do this: it should be done by default when selecting Mac support for PPC/PPC64 and especially for the Macs CPUfreq driver. We select SMU by default for PPC_PMAC64, WINDFARM by default on PPC_PMAC and all the WINDFARM thermal managers by default if CPU_FREQ_PMAC64 is selected. I think this will make install images work in the G5 Macs. Cc: sta...@vger.kernel.org Signed-off-by: Linus Walleij <linus.wall...@linaro.org> --- drivers/macintosh/Kconfig | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/macintosh/Kconfig b/drivers/macintosh/Kconfig index 97a420c11eed..d7186d8f30a9 100644 --- a/drivers/macintosh/Kconfig +++ b/drivers/macintosh/Kconfig @@ -101,6 +101,7 @@ config ADB_PMU_LED_DISK config PMAC_SMU bool "Support for SMU based PowerMacs" depends on PPC_PMAC64 + default PPC_PMAC64 help This option adds support for the newer G5 iMacs and PowerMacs based on the "SMU" system control chip which replaces the old PMU. @@ -194,11 +195,13 @@ config THERM_ADT746X config WINDFARM tristate "New PowerMac thermal control infrastructure" depends on PPC + default PPC_PMAC config WINDFARM_PM81 tristate "Support for thermal management on iMac G5" depends on WINDFARM && I2C && CPU_FREQ_PMAC64 && PMAC_SMU select I2C_POWERMAC + default CPU_FREQ_PMAC64 help This driver provides thermal control for the iMacG5 @@ -206,6 +209,7 @@ config WINDFARM_PM72 tristate "Support for thermal management on PowerMac G5 (AGP)" depends on WINDFARM && I2C && CPU_FREQ_PMAC64 && ADB_PMU select I2C_POWERMAC + default CPU_FREQ_PMAC64 help This driver provides thermal control for the PowerMac G5 "AGP" variants (PowerMac 7,2 and 7,3) @@ -214,6 +218,7 @@ config WINDFARM_RM31 tristate "Support for thermal management on Xserve G5" depends on WINDFARM && I2C && CPU_FREQ_PMAC64 && ADB_PMU select I2C_POWERMAC + default CPU_FREQ_PMAC64 help This driver provides thermal control for the Xserve G5 (RackMac3,1) @@ -222,6 +227,7 @@ config WINDFARM_PM91 tristate "Support for thermal management on PowerMac9,1" depends on WINDFARM && I2C && CPU_FREQ_PMAC64 && PMAC_SMU select I2C_POWERMAC + default CPU_FREQ_PMAC64 help This driver provides thermal control for the PowerMac9,1 which is the recent (SMU based) single CPU desktop G5 -- 2.9.4
Re: [PATCH] powerpc: sysdev: simple_gpio: fix Oops in gpio save_regs function
On Wed, May 24, 2017 at 10:01 AM, Christophe Leroy
<christophe.le...@c-s.fr> wrote:
> of_mm_gpiochip_add_data() generates an Oops for NULL pointer dereference.
>
> of_mm_gpiochip_add_data() calls mm_gc->save_regs() before
> setting the data, therefore ->save_regs() cannot use gpiochip_get_data()
>
> Fixes: 937daafca774b ("powerpc: simple-gpio: use gpiochip data pointer")
> Cc: sta...@vger.kernel.org
>
> Signed-off-by: Christophe Leroy <christophe.le...@c-s.fr>
Reviewed-by: Linus Walleij <linus.wall...@linaro.org>
Sorry for any screwups I've caused...
Yours,
Linus Walleij
Re: [PATCH] soc: fsl/qe: fix gpio save_regs functions
On Tue, Sep 6, 2016 at 12:52 AM, Christophe Leroy
<christophe.le...@c-s.fr> wrote:
> of_mm_gpiochip_add_data() calls mm_gc->save_regs() before
> setting the data. Therefore ->save_regs() cannot use
> gpiochip_get_data()
>
> An Oops is encountered without this fix.
>
> fixes: 1e714e54b5ca5 ("powerpc: qe_lib-gpio: use gpiochip data pointer")
> Signed-off-by: Christophe Leroy <christophe.le...@c-s.fr>
> Cc: <sta...@vger.kernel.org>
Aha sorry for my regular screwups. :(
Reviewed-by: Linus Walleij <linus.wall...@linaro.org>
Yours,
Linus Walleij
Re: [PATCH] powerpc: sysdev: cpm: fix gpio save_regs functions
On Thu, Aug 11, 2016 at 10:50 AM, Christophe Leroy
<christophe.le...@c-s.fr> wrote:
> of_mm_gpiochip_add_data() calls mm_gc->save_regs() before
> setting the data. Therefore ->save_regs() cannot use
> gpiochip_get_data()
>
> [0.275940] Unable to handle kernel paging request for data at address
> 0x0130
> [0.283120] Faulting instruction address: 0xc01b44cc
> [0.288175] Oops: Kernel access of bad area, sig: 11 [#1]
> [0.293343] PREEMPT CMPC885
> [0.296141] CPU: 0 PID: 1 Comm: swapper Not tainted 4.7.0-g65124df-dirty
> #68
> [0.304131] task: c6074000 ti: c608 task.ti: c608
> [0.309459] NIP: c01b44cc LR: c0011720 CTR: c0011708
> [0.314372] REGS: c6081d90 TRAP: 0300 Not tainted (4.7.0-g65124df-dirty)
> [0.322267] MSR: 9032 <EE,ME,IR,DR,RI> CR: 2428 XER: 2000
> [0.328813] DAR: 0130 DSISR: c000
> GPR00: c01b6d0c c6081e40 c6074000 c6017000 c9028000 c601d028 c6081dd8
> GPR08: c601d028 0001 2444 c0002790
> GPR16: c05643b0 0083
> GPR24: c04a1a6c c056 c04a8308 c04c6480 c0012498 c6017000 c7ffcc78 c6017000
> [0.360806] NIP [c01b44cc] gpiochip_get_data+0x4/0xc
> [0.365684] LR [c0011720] cpm1_gpio16_save_regs+0x18/0x44
> [0.370972] Call Trace:
> [0.373451] [c6081e50] [c01b6d0c] of_mm_gpiochip_add_data+0x70/0xdc
> [0.379624] [c6081e70] [c00124c0] cpm_init_par_io+0x28/0x118
> [0.385238] [c6081e80] [c04a8ac0] do_one_initcall+0xb0/0x17c
> [0.390819] [c6081ef0] [c04a8cbc] kernel_init_freeable+0x130/0x1dc
> [0.396924] [c6081f30] [c00027a4] kernel_init+0x14/0x110
> [0.402177] [c6081f40] [c000b424] ret_from_kernel_thread+0x5c/0x64
> [0.408233] Instruction dump:
> [0.411168] 4182fafc 3f80c040 48234c6d 3bc0fff0 3b9c5ed0 4bfffaf4 81290020
> 712a0004
> [0.418825] 4182fb34 48234c51 4bfffb2c 81230004 <80690130> 4e800020
> 7c0802a6 9421ffe0
> [0.426763] ---[ end trace fe4113ee21d72ffa ]---
>
> fixes: e65078f1f3490 ("powerpc: sysdev: cpm1: use gpiochip data pointer")
> fixes: a14a2d484b386 ("powerpc: cpm_common: use gpiochip data pointer")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Christophe Leroy <christophe.le...@c-s.fr>
Reviewed-by: Linus Walleij <linus.wall...@linaro.org>
Sorry for screwing stuff up :(
Yours,
Linus Walleij
Re: [PATCH 01/12] gpio: Only descend into gpio directory when CONFIG_GPIOLIB is set
On Mon, Jun 13, 2016 at 10:02 PM, Andrew F. Davis <a...@ti.com> wrote: > When CONFIG_GPIOLIB is not set make will still descend into the gpio > directory but nothing will be built. This produces unneeded build > artifacts and messages in addition to slowing the build. Fix this here. > > Signed-off-by: Andrew F. Davis <a...@ti.com> Patch applied. Strange that this went unnoticed for years. Yours, Linus Walleij ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 5/8] dmaengine: ste_dma40: Only calculate residue if txstate exists.
On Tue, Jun 7, 2016 at 7:38 PM, Peter Griffin <peter.grif...@linaro.org> wrote: > There is no point calculating the residue if there is > no txstate to store the value. > > Signed-off-by: Peter Griffin <peter.grif...@linaro.org> Acked-by: Linus Walleij <linus.wall...@linaro.org> Yours, Linus Walleij ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/8] dmaengine: coh901318: Only calculate residue if txstate exists.
On Tue, Jun 7, 2016 at 7:38 PM, Peter Griffin <peter.grif...@linaro.org> wrote: > There is no point in calculating the residue if there is no > txstate to store the value. > > Signed-off-by: Peter Griffin <peter.grif...@linaro.org> Acked-by: Linus Walleij <linus.wall...@linaro.org> Yours, Linus Walleij ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 8/8] dmaengine: Remove site specific OOM error messages on kzalloc
On Tue, Jun 7, 2016 at 7:38 PM, Peter Griffin <peter.grif...@linaro.org> wrote: > If kzalloc() fails it will issue it's own error message including > a dump_stack(). So remove the site specific error messages. > > Signed-off-by: Peter Griffin <peter.grif...@linaro.org> Acked-by: Linus Walleij <linus.wall...@linaro.org> A few subsystems may use a cleanup like this... I wonder how many unnecessary prints I've introduced myself :P Yours, Linus Walleij ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] gpio: dt-bindings: add ibm,ppc4xx-gpio binding
On Mon, May 16, 2016 at 6:56 PM, Rob Herring <r...@kernel.org> wrote: > On Mon, May 16, 2016 at 10:27:46AM -0500, Rob Herring wrote: >> On Thu, May 12, 2016 at 12:07:48AM +0200, Christian Lamparter wrote: >> > This patch adds binding information for IBM/AMCC/APM GPIO >> > Controllers of the PowerPC 4XX series and compatible SoCs. (...) >> Acked-by: Rob Herring <r...@kernel.org> > > As this is just a binding doc, I've applied it. OK less work on my part :) Acked-by: Linus Walleij <linus.wall...@linaro.org> Yours, Linus Walleij ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 12/23] powerpc: do away with ARCH_[WANT_OPTIONAL|REQUIRE]_GPIOLIB
This replaces: - "select ARCH_REQUIRE_GPIOLIB" with "select GPIOLIB" as this can now be selected directly. - "select ARCH_WANT_OPTIONAL_GPIOLIB" with no dependency: GPIOLIB is now selectable by everyone, so we need not declare our intent to select it. When ordering the symbols the following rationale was used: if the selects were in alphabetical order, I moved select GPIOLIB to be in alphabetical order, but if the selects were not maintained in alphabetical order, I just replaced "select ARCH_REQUIRE_GPIOLIB" with "select GPIOLIB". Cc: Michael Büsch <m...@bues.ch> Cc: Benjamin Herrenschmidt <b...@kernel.crashing.org> Cc: Paul Mackerras <pau...@samba.org> Cc: Michael Ellerman <m...@ellerman.id.au> Cc: linuxppc-dev@lists.ozlabs.org Signed-off-by: Linus Walleij <linus.wall...@linaro.org> --- Various arch maintainers: either ACK this and I will merge it into the GPIO tree for v4.7 anticipating no clashes, or you wait until I have the enabling patch upstream (patch 1 in this series, removing deps on ARCH_[WANTS_OPTIONAL|REQUIRES]_GPIOLIB), and you will be able to merge it to your arch trees yourselves for late v4.7 (post GPIO tree merge) or for v4.8. You can also ask me for an immutable branch if you prefer that, I will put the enabling patch on a branch and the patch for your arch on top and ask you to pull it. Select your option from the menu, silence probably means I will merge it to the GPIO tree. Unless you are X86 or ARM in which case I will be cautious. --- arch/powerpc/Kconfig| 1 - arch/powerpc/platforms/40x/Kconfig | 2 +- arch/powerpc/platforms/44x/Kconfig | 2 +- arch/powerpc/platforms/512x/Kconfig | 1 - arch/powerpc/platforms/83xx/Kconfig | 3 --- arch/powerpc/platforms/85xx/Kconfig | 4 ++-- arch/powerpc/platforms/86xx/Kconfig | 7 +++ arch/powerpc/platforms/8xx/Kconfig | 2 +- arch/powerpc/platforms/Kconfig | 8 9 files changed, 12 insertions(+), 18 deletions(-) diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index 7cd32c038286..6e39dfe096e6 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -98,7 +98,6 @@ config PPC select HAVE_FUNCTION_TRACER select HAVE_FUNCTION_GRAPH_TRACER select SYSCTL_EXCEPTION_TRACE - select ARCH_WANT_OPTIONAL_GPIOLIB select VIRT_TO_BUS if !PPC64 select HAVE_IDE select HAVE_IOREMAP_PROT diff --git a/arch/powerpc/platforms/40x/Kconfig b/arch/powerpc/platforms/40x/Kconfig index 6e287f1294fa..e3257f24a8a1 100644 --- a/arch/powerpc/platforms/40x/Kconfig +++ b/arch/powerpc/platforms/40x/Kconfig @@ -137,7 +137,7 @@ config STB03xxx config PPC4xx_GPIO bool "PPC4xx GPIO support" depends on 40x - select ARCH_REQUIRE_GPIOLIB + select GPIOLIB help Enable gpiolib support for ppc40x based boards diff --git a/arch/powerpc/platforms/44x/Kconfig b/arch/powerpc/platforms/44x/Kconfig index 5538e57c36c1..48fc18041ff6 100644 --- a/arch/powerpc/platforms/44x/Kconfig +++ b/arch/powerpc/platforms/44x/Kconfig @@ -273,7 +273,7 @@ config PPC44x_SIMPLE config PPC4xx_GPIO bool "PPC4xx GPIO support" depends on 44x - select ARCH_REQUIRE_GPIOLIB + select GPIOLIB help Enable gpiolib support for ppc440 based boards diff --git a/arch/powerpc/platforms/512x/Kconfig b/arch/powerpc/platforms/512x/Kconfig index f09016f6b3a6..bf7ae5cbd07a 100644 --- a/arch/powerpc/platforms/512x/Kconfig +++ b/arch/powerpc/platforms/512x/Kconfig @@ -6,7 +6,6 @@ config PPC_MPC512x select IPIC select PPC_PCI_CHOICE select FSL_PCI if PCI - select ARCH_WANT_OPTIONAL_GPIOLIB select USB_EHCI_BIG_ENDIAN_MMIO if USB_EHCI_HCD select USB_EHCI_BIG_ENDIAN_DESC if USB_EHCI_HCD diff --git a/arch/powerpc/platforms/83xx/Kconfig b/arch/powerpc/platforms/83xx/Kconfig index 2bdc8c862c46..4ef7f1cd05b7 100644 --- a/arch/powerpc/platforms/83xx/Kconfig +++ b/arch/powerpc/platforms/83xx/Kconfig @@ -116,7 +116,6 @@ endif # used for usb & gpio config PPC_MPC831x bool - select ARCH_WANT_OPTIONAL_GPIOLIB # used for math-emu config PPC_MPC832x @@ -125,9 +124,7 @@ config PPC_MPC832x # used for usb & gpio config PPC_MPC834x bool - select ARCH_WANT_OPTIONAL_GPIOLIB # used for usb & gpio config PPC_MPC837x bool - select ARCH_WANT_OPTIONAL_GPIOLIB diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig index e626461a63bd..df25a3ed489d 100644 --- a/arch/powerpc/platforms/85xx/Kconfig +++ b/arch/powerpc/platforms/85xx/Kconfig @@ -225,7 +225,7 @@ config GE_IMP3A select DEFAULT_UIMAGE select SWIOTLB select MMIO_NVRAM - select ARCH_REQUIRE_GPIOLIB + select GPIOLIB select GE_FPGA help This option enables support for the GE Intelligen
Re: [PATCH] powerpc: ppc4xx: drop unused variable
On Fri, Apr 1, 2016 at 4:31 AM, Michael Ellerman <m...@ellerman.id.au> wrote: > On Thu, 2016-03-31 at 14:57 +0200, Linus Walleij wrote: >> On Thu, Mar 31, 2016 at 12:09 PM, Michael Ellerman <m...@ellerman.id.au> >> wrote: >> >> > If you feel like cross building powerpc in future it should be as simple >> > as: >> > >> > $ dnf install gcc-powerpc64-linux-gnu || apt-get install >> > gcc-powerpc-linux-gnu >> > $ make ARCH=powerpc CROSS_COMPILE=powerpc-linux-gnu- ... >> >> Ah hm yeah I guess everyone "should", it's just that these days I >> mainly rely on Fenguang's kautobuild to do this job for me and >> get back with the result from a plethora of arches. > > Sure. That makes sense for all the silly little architectures. > > But for powerpc you should really cross compile. I think kautobuild cross compiles? The only thing that happens IIUC is I let somebody else do the job at the Intel server farm. Yours, Linus Walleij ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: ppc4xx: drop unused variable
On Thu, Mar 31, 2016 at 12:09 PM, Michael Ellerman <m...@ellerman.id.au> wrote: > If you feel like cross building powerpc in future it should be as simple as: > > $ dnf install gcc-powerpc64-linux-gnu || apt-get install > gcc-powerpc-linux-gnu > $ make ARCH=powerpc CROSS_COMPILE=powerpc-linux-gnu- ... Ah hm yeah I guess everyone "should", it's just that these days I mainly rely on Fenguang's kautobuild to do this job for me and get back with the result from a plethora of arches. Sometimes a buggy bit slips through the cracks though, sorry about that. Yours, Linus Walleij ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: ppc4xx: drop unused variable
commit 0d36fe65f58391712e11a6621075f373216e5f00
"powerpc: ppc4xx: use gpiochip data pointer"
made the mm_gc local variable in ppc4xx_gpio_set()
redundant, and when GCC treats warnings as errors this
happens:
arch/powerpc/sysdev/ppc4xx_gpio.c: In function 'ppc4xx_gpio_set':
arch/powerpc/sysdev/ppc4xx_gpio.c:93:26: error:
unused variable 'mm_gc' [-Werror=unused-variable]
struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
^
cc1: all warnings being treated as errors
Reported-by: kbuild test robot <fengguang...@intel.com>
Cc: Anatolij Gustschin <ag...@denx.de>
Cc: Benjamin Herrenschmidt <b...@kernel.crashing.org>
Cc: Paul Mackerras <pau...@samba.org>
Cc: Michael Ellerman <m...@ellerman.id.au>
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Linus Walleij <linus.wall...@linaro.org>
---
I've applied this to the GPIO tree where the offending
commit is now merged.
---
arch/powerpc/sysdev/ppc4xx_gpio.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/powerpc/sysdev/ppc4xx_gpio.c
b/arch/powerpc/sysdev/ppc4xx_gpio.c
index 4ab83cd04785..5382d04dd872 100644
--- a/arch/powerpc/sysdev/ppc4xx_gpio.c
+++ b/arch/powerpc/sysdev/ppc4xx_gpio.c
@@ -90,7 +90,6 @@ __ppc4xx_gpio_set(struct gpio_chip *gc, unsigned int gpio,
int val)
static void
ppc4xx_gpio_set(struct gpio_chip *gc, unsigned int gpio, int val)
{
- struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
struct ppc4xx_gpio_chip *chip = gpiochip_get_data(gc);
unsigned long flags;
--
2.4.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH RESENT] powerpc: dts: don't fall back to fsl, pq3-gpio for fsl,mpc8572-gpio devices
On Fri, Jul 31, 2015 at 11:16 AM, Uwe Kleine-König u.kleine-koe...@pengutronix.de wrote: While the handling of fsl,pq3-gpio and fsl,mpc8572-gpio is done in the same driver and the two hardly differ, the latter controller needs a workaround for an erratum in the gpio_get callback. To make this difference more explicit remove fsl,pq3-gpio from the list of compatibles for mpc8572 machines. Signed-off-by: Uwe Kleine-König u.kleine-koe...@pengutronix.de Acked-by: Linus Walleij linus.wall...@linaro.org Yours, Linus Walleij ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 10/15] gpio: kconfig: replace PPC_OF with PPC
On Sat, Jan 31, 2015 at 2:47 PM, Kevin Hao haoke...@gmail.com wrote: The PPC_OF is a ppc specific option which is used to mean that the firmware device tree access functions are available. Since all the ppc platforms have a device tree, it is aways set to 'y' for ppc. So it makes no sense to keep a such option in the current kernel. Replace it with PPC. Signed-off-by: Kevin Hao haoke...@gmail.com Patch applied. Yours, Linus Walleij ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] gpio: ge: Convert to platform driver
On Sat, Apr 12, 2014 at 7:41 AM, Alexander Shiyan shc_w...@mail.ru wrote: This patch converts GE I/O FPGA GPIO driver to platform driver. Signed-off-by: Alexander Shiyan shc_w...@mail.ru No further comments, so this v2 patch is applied. Yours, Linus Walleij ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] gpio: ge: Convert to platform driver
On Sun, Mar 30, 2014 at 7:14 AM, Alexander Shiyan shc_w...@mail.ru wrote: This patch converts GE I/O FPGA GPIO driver to platform driver. Signed-off-by: Alexander Shiyan shc_w...@mail.ru --- Only compile tested. Isn't it necessary to also patch affected platforms to add this device either as platform device or in their device trees? Yours, Linus Walleij ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc/gpio: Fix the wrong GPIO input data on MPC8572/MPC8536
On Fri, Nov 22, 2013 at 9:12 AM, Liu Gang gang@freescale.com wrote: For MPC8572/MPC8536, the status of GPIOs defined as output cannot be determined by reading GPDAT register, so the code use shadow data register instead. But the code may give the wrong status of GPIOs defined as input under some scenarios: 1. If some pins were configured as inputs and were asserted high before booting the kernel, the shadow data has been initialized with those pin values. 2. Some pins have been configured as output first and have been set to the high value, then reconfigured as input. The above cases will make the shadow data for those input pins to be set to high. Then reading the pin status will always return high even if the actual pin status is low. The code should eliminate the effects of the shadow data to the input pins, and the status of those pins should be read directly from GPDAT. Signed-off-by: Liu Gang gang@freescale.com --- changes in v2: - Added more description of the problem. - Reduced one in_be32() call. - Do not modify the shadow data. I'm waiting for the maintainers to ACK this before applying. Anatolij? Yours, Linus Walleij ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc/gpio: Fix the wrong GPIO input data on MPC8572/MPC8536
On Fri, Nov 22, 2013 at 9:12 AM, Liu Gang gang@freescale.com wrote: For MPC8572/MPC8536, the status of GPIOs defined as output cannot be determined by reading GPDAT register, so the code use shadow data register instead. But the code may give the wrong status of GPIOs defined as input under some scenarios: (...) Signed-off-by: Liu Gang gang@freescale.com --- changes in v2: - Added more description of the problem. - Reduced one in_be32() call. - Do not modify the shadow data. Applied this v2 version, added ACKs and tagged for stable. Yours, Linus Walleij ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/gpio: Fix the wrong GPIO input data on MPC8572/MPC8536
On Fri, Nov 15, 2013 at 8:16 AM, Liu Gang gang@freescale.com wrote: For MPC8572/MPC8536, the status of GPIOs defined as output cannot be determined by reading GPDAT register, so the code use shadow data register instead. But if the input pins are asserted high, they will always read high due to the shadow data, even if the pins are set to low. So the input pins should be read directly from GPDAT, not the shadow data. Signed-off-by: Liu Gang gang@freescale.com --- drivers/gpio/gpio-mpc8xxx.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpio/gpio-mpc8xxx.c b/drivers/gpio/gpio-mpc8xxx.c index 9ae29cc..1d4ac75 100644 --- a/drivers/gpio/gpio-mpc8xxx.c +++ b/drivers/gpio/gpio-mpc8xxx.c @@ -71,6 +71,7 @@ static int mpc8572_gpio_get(struct gpio_chip *gc, unsigned int gpio) struct mpc8xxx_gpio_chip *mpc8xxx_gc = to_mpc8xxx_gpio_chip(mm); val = in_be32(mm-regs + GPIO_DAT) ~in_be32(mm-regs + GPIO_DIR); + mpc8xxx_gc-data = in_be32(mm-regs + GPIO_DIR); return (val | mpc8xxx_gc-data) mpc8xxx_gpio2mask(gpio); } Anatolij, Ben: can either of you take a look at this patch and ACK it if OK? Yours, Linus Walleij ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC 10/10] irqchip: Make versatile fpga irq driver a generic chip
On Mon, Jun 10, 2013 at 12:50 PM, Grant Likely grant.lik...@linaro.org wrote: On Mon, Jun 10, 2013 at 8:40 AM, Linus Walleij linus.wall...@linaro.org wrote: On Mon, Jun 10, 2013 at 2:49 AM, Grant Likely grant.lik...@linaro.org wrote: This is an RFC patch to convert the versatile FPGA irq controller driver to use generic irq chip. It builds on the series that extends the generic chip code to allow a linear irq domain to contain one or more generic irq chips so that each interrupt controller doesn't need to hand code the generic chip setup. I've written this as a proof of concept to see if the new generic irq code does what it needs to. I had to extend it slightly to properly handle the valid mask used by the versatile FPGA driver. Tested on QEMU, but not on real hardware. Is this the same as the one I tested previously? If it need re-testing please push a branch and I'll take it for a spin. Yes, it's the same, but if you can test the branch I would appreciate it. I've done some heavy rework on the irqdomain code that makes everything simpler, but also makes it likely that I've broken something. git://git.secretlab.ca/git/linux.git irqdomain/test It still works like a charm on the Integrator/AP. Tested-by: Linus Walleij linus.wall...@linaro.org Yours, Linus Walleij ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC 10/10] irqchip: Make versatile fpga irq driver a generic chip
On Sat, Jun 15, 2013 at 11:19 PM, Linus Walleij linus.wall...@linaro.org wrote: On Mon, Jun 10, 2013 at 12:50 PM, Grant Likely grant.lik...@linaro.org wrote: On Mon, Jun 10, 2013 at 8:40 AM, Linus Walleij linus.wall...@linaro.org wrote: On Mon, Jun 10, 2013 at 2:49 AM, Grant Likely grant.lik...@linaro.org wrote: This is an RFC patch to convert the versatile FPGA irq controller driver to use generic irq chip. It builds on the series that extends the generic chip code to allow a linear irq domain to contain one or more generic irq chips so that each interrupt controller doesn't need to hand code the generic chip setup. I've written this as a proof of concept to see if the new generic irq code does what it needs to. I had to extend it slightly to properly handle the valid mask used by the versatile FPGA driver. Tested on QEMU, but not on real hardware. Is this the same as the one I tested previously? If it need re-testing please push a branch and I'll take it for a spin. Yes, it's the same, but if you can test the branch I would appreciate it. I've done some heavy rework on the irqdomain code that makes everything simpler, but also makes it likely that I've broken something. git://git.secretlab.ca/git/linux.git irqdomain/test It still works like a charm on the Integrator/AP. Tested-by: Linus Walleij linus.wall...@linaro.org BTW here is the new hwirq output in /proc/interrupts and it's really nice: root@integrator:/proc cat interrupts CPU0 17: 1845 pic 1 uart-pl010 22: 13716 pic 6 timer 24: 0 pic 8 rtc-pl030 Err: 0 Yours, Linus Walleij ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC 10/10] irqchip: Make versatile fpga irq driver a generic chip
On Mon, Jun 10, 2013 at 2:49 AM, Grant Likely grant.lik...@linaro.org wrote: This is an RFC patch to convert the versatile FPGA irq controller driver to use generic irq chip. It builds on the series that extends the generic chip code to allow a linear irq domain to contain one or more generic irq chips so that each interrupt controller doesn't need to hand code the generic chip setup. I've written this as a proof of concept to see if the new generic irq code does what it needs to. I had to extend it slightly to properly handle the valid mask used by the versatile FPGA driver. Tested on QEMU, but not on real hardware. Is this the same as the one I tested previously? If it need re-testing please push a branch and I'll take it for a spin. Yours. Linus Walleij ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] net: mv643xx_eth: proper initialization for Kirkwood SoCs
On Fri, May 24, 2013 at 12:40 AM, Sebastian Hesselbarth sebastian.hesselba...@gmail.com wrote: On 05/23/2013 08:40 PM, Jason Cooper wrote: I think marvell,psc1_reset =; gives us the most flexibility in accurately describing the hardware. IMHO using that is just another workaround for a broken driver. We could hack the whole register setup in DT as it would still accurately describe HW. Don't get me wrong, but I don't like it. Haven't checked how happy Linus Walleij is about pinctrl drivers with reg values hacked in lately. One of the things I've been ranting about lately is that Linux subsystem maintainers have become de-facto device tree standard commite chairs. :-( So to the actual question: In general I think we need to draw a line and define what we mean with describing the hardware in a device tree. We have some consensus: - reg properties to describe regsiter BASE offset in physical memory and size. - Resources like IRQ, DMA channel, regulator, GPIO pin control handles, are passed using ampersand notation. And so it goes on. When it comes to defining different registers and their individual bits and the meaning of these and/or default values, I personally think that is making things harder for developers rather than simplifying things. I know that pinctrl-single is anyway doing this and I was talked into accepting it under circumstances where developers are being passed opaque machine-generated data that would otherwise be translated into unreadable header files littering the kernel. For a coder it is definately better if the *driver* know these details, but whether that is possible seems to depend on things like hardware development process. IMO: if you want to go down that road, what you really want is not ever more expressible device trees, but real open firmware, or ACPI or UEFI that can interpret and run bytecode as some bios for you. With DT coming from OF maybe this is a natural progression of things, but one has to realize when we reach the point where what we really want is a bios. Then your time is likely better spent with Tianocore or something than with the kernel. Yours, Linus Walleij ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v7 3/3] of/pci: mips: convert to common of_pci_range_parser
On Tue, Apr 16, 2013 at 12:18 PM, Andrew Murray andrew.mur...@arm.com wrote: This patch converts the pci_load_of_ranges function to use the new common of_pci_range_parser. Signed-off-by: Andrew Murray andrew.mur...@arm.com Signed-off-by: Liviu Dudau liviu.du...@arm.com Reviewed-by: Rob Herring rob.herr...@calxeda.com Tested-by: Linus Walleij linus.wall...@linaro.org Yours, Linus Walleij ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 08/25] gpio/mpc8xxx: add a const qualifier
On Mon, Jul 23, 2012 at 11:13 AM, Uwe Kleine-König u.kleine-koe...@pengutronix.de wrote: This prepares *of_device_id.data becoming const. Without this change the following warning would occur: drivers/gpio/gpio-mpc8xxx.c: In function 'mpc8xxx_add_controller': drivers/gpio/gpio-mpc8xxx.c:360:30: warning: assignment discards 'const' qualifier from pointer target type [enabled by default] Signed-off-by: Uwe Kleine-König u.kleine-koe...@pengutronix.de Acked-by: Linus Walleij linus.wall...@linaro.org Yours, Linus Walleij ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] i2c: let the core register devices from devicetree
On Wed, Jun 13, 2012 at 11:12 PM, Wolfram Sang w.s...@pengutronix.de wrote: Currently, every driver has to do it on its own, but it should be done in the core, like we already do with board_info structs. Signed-off-by: Wolfram Sang w.s...@pengutronix.de Acked-by: Linus Walleij linus.wall...@linaro.org Lee might be able to test this with his DT bindings (and patch them to use the new handling in the core..) Yours, Linus Walleij ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] gpiolib/arches: Centralise bolierplate asm/gpio.h
On Sun, Apr 15, 2012 at 11:52 AM, Mark Brown broo...@opensource.wolfsonmicro.com wrote: Rather than requiring architectures that use gpiolib but don't have any need to define anything custom to copy an asm/gpio.h provide a Kconfig symbol which architectures must select in order to include gpio.h and for other architectures just provide the trivial implementation directly. This makes it much easier to do gpiolib updates and is also a step towards making gpiolib APIs available on every architecture. For architectures with existing boilerplate code leave a stub header in place which warns on direct inclusion of asm/gpio.h and includes linux/gpio.h to catch code that's doing this. Direct inclusion of asm/gpio.h has long been deprecated. Signed-off-by: Mark Brown broo...@opensource.wolfsonmicro.com --- arch/alpha/include/asm/gpio.h | 59 ++ arch/arm/Kconfig | 1 + arch/avr32/Kconfig | 1 + arch/blackfin/Kconfig | 1 + arch/ia64/include/asm/gpio.h | 59 ++ arch/m68k/Kconfig.cpu | 1 + arch/microblaze/include/asm/gpio.h | 57 ++--- arch/mips/Kconfig | 1 + arch/openrisc/include/asm/gpio.h | 69 ++- arch/powerpc/include/asm/gpio.h | 57 ++--- arch/sh/Kconfig | 1 + arch/sparc/include/asm/gpio.h | 40 ++--- arch/unicore32/Kconfig | 1 + arch/x86/include/asm/gpio.h | 57 ++--- arch/xtensa/include/asm/gpio.h | 60 ++- drivers/gpio/Kconfig | 8 include/linux/gpio.h | 34 + 17 files changed, 81 insertions(+), 426 deletions(-) This looks good but I think we need to page the alpha, ia64, m68k, microblaze, openrisc etc subarch maintainers on this patch so they have their say. Yours, Linus Walleij ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] gpiolib/arches: Centralise bolierplate asm/gpio.h
On Mon, Apr 16, 2012 at 10:15 AM, Mark Brown broo...@opensource.wolfsonmicro.com wrote: On Mon, Apr 16, 2012 at 09:21:58AM +0200, Linus Walleij wrote: This looks good but I think we need to page the alpha, ia64, m68k, microblaze, openrisc etc subarch maintainers on this patch so they have their say. That's why I CCed linux-arch, to get all the architecture maintainers included. vger would get upset if I CCed everyone individually. Oh I missed it. I looped in a few maintainers and arch lists anyway. Acked-by: Linus Walleij linus.wall...@linaro.org Thanks! Linus Walleij ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 4/4] powerpc: Board support for GE IMP3A
On Mon, Mar 12, 2012 at 6:13 PM, Martyn Welch martyn.we...@ge.com wrote: Initial board support for the GE IMP3A, a 3U compactPCI card with a p2020 processor. (...) +++ b/arch/powerpc/configs/ge_imp3a_defconfig @@ -0,0 +1,257 @@ +CONFIG_PPC_85xx=y +CONFIG_SMP=y +CONFIG_NR_CPUS=2 +CONFIG_EXPERIMENTAL=y +CONFIG_SYSVIPC=y +CONFIG_POSIX_MQUEUE=y +CONFIG_BSD_PROCESS_ACCT=y +CONFIG_BSD_PROCESS_ACCT_V3=y +CONFIG_SPARSE_IRQ=y This habit of changing a lot of defconfig stuff in a patch dealing with other stuff is alien in the ARM world. Especially when changing a horde of stuff that has nothing to do with the patch subject. But I don't really know how PPC does these things so who am I to speak ... BTW: doesn't the make saveconfig reduce defconfigs on PPC? Paging Uwe on this. Yours, Linus Walleij ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 4/4] powerpc: Board support for GE IMP3A
2012/3/13 Martyn Welch martyn.we...@ge.com: On 13/03/12 11:51, Linus Walleij wrote: This habit of changing a lot of defconfig stuff in a patch dealing with other stuff is alien in the ARM world. Especially when changing a horde of stuff that has nothing to do with the patch subject. This is adding the defconfig, it's support for a new board: Ah I was confused by thinking the patch series was all about GPIO. Sorry... Yours, Linus Walleij ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 0/9] DMA engine cookie handling cleanups
On Tue, Mar 6, 2012 at 11:33 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: This patch series cleans up the handling of cookies in DMA engine drivers. This is done by providing a set of inline library functions for common tasks: I just applied the latest patches right off and tested with some stressy MMC operations on the U300 and Ux500. (I had some minor hell since patch 8/9 and 9/9 were uuencoded but managed to fix it...) It works like a charm! The patches look good too. Tested-by: Linus Walleij linus.wall...@linaro.org Reviewed-by: Linus Walleij linus.wall...@linaro.org Yours, Linus Walleij ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V2 1/2] powerpc: Move GE GPIO and PIC drivers
On Tue, Mar 6, 2012 at 1:19 PM, Kumar Gala ga...@kernel.crashing.org wrote: On Feb 28, 2012, at 4:22 AM, Martyn Welch wrote: Move the GE GPIO and PIC drivers to allow these to be used by non-86xx boards. gpio driver should be in drivers/gpio. Please split that move out as a separate patch for Grant Linus to review as part of the GPIO subsystem Yes please. It will get a good home there, Grant knows everything about PPC... Yours, Linus Walleij ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/9] DMA engine cookie handling cleanups
On Mon, Mar 5, 2012 at 9:14 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: This patch series cleans up the handling of cookies in DMA engine drivers. This is done by providing a set of inline library functions for common tasks: Overall this looks good, but I have a problem: patch [1/9] does not appear in any subscribed accounts (it may be on my @stericsson.com address, will check tomorrow) One I get hold of an ungmangled copy I can test the series on ux500 and U300. Is it just stuck in moderation because of size or something like that? Yours, Linus Walleij ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
