Re: how to look for source code in kernel
On Fri, Dec 28, 2012 at 11:49:53AM -0800, Eric W. Biederman wrote: > Al Viro writes: > > > On Thu, Dec 27, 2012 at 11:36:13PM -0800, Eric W. Biederman wrote: > >> But then I am probably peculiar keeping an index of the source code in > >> my head. When I need to look for something and I don't know where to > >> find it I do. > >> > >> git-ls-files | xargs fgrep 'struct f2fs_inode' > > > > What's wrong with git grep? > > I haven't learned it yet. git-ls-files is a lot better than find > speed wise so is very much worth doing.I haven't a clue if > there is an advantage to git-grep, over just knowing find, xargs, and > grep. Brevity. Jonathan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/6] resource: Extend the PPC32 reserved memory hack
On Tue, Jan 23, 2018 at 11:58:06PM +1100, Michael Ellerman wrote:
> Jonathan Neuschäfer writes:
>
> > On the Nintendo Wii, there are two ranges of physical memory, and MMIO
> > in between, but Linux on ppc32 doesn't support discontiguous memory.
> > Therefore a hack was introduced in commit c5df7f775148 ("powerpc: allow
> > ioremap within reserved memory regions") and commit de32400dd26e ("wii:
> > use both mem1 and mem2 as ram"):
> >
> > - Treat the area from the start of the first memory area (MEM1) to the
> >end of the second (MEM2) as one big memory area, but mark the part
> >that doesn't belong to MEM1 or MEM2 as reserved.
> > - Only on the Wii, allow ioremap to be used on reserved memory.
> >
> > This hack, however, doesn't account for the "resource"-based API in
> > kernel/resource.c, because __request_region performs its own checks.
> >
> > Extend the hack to kernel/resource.c, to allow more drivers to allocate
> > their MMIO regions on the Wii.
>
> Hi Jonathan,
>
> Sorry but I can't merge a hack like this in generic code.
Makes sense.
> Has anyone looked at adding proper discontig mem support to PPC32?
I'm not aware of any such effort.
Do you have any pointer on how to implement discontiguous memory
support? CONFIG_ARCH_SPARSEMEM_ENABLE seems relevant.
> Or can we punch a hole in the resource in the right place? Maybe from
> add_system_ram_resources() ?
Not sure. add_system_ram_resources would need the original memblock
table, which is overwritten in wii_memory_fixups, if I read the code
correctly.
If a proper solution doesn't take an overwhelming amount of work, I'd
prefer a proper solution.
Thanks,
Jonathan Neuschäfer
signature.asc
Description: PGP signature
[PATCH 2/6] Documentation: kernel-docs: Move vfs.txt under "Docs at the Linux Kernel tree"
It's unneccessary to point to an external mirror of the Documentation
directory. Also, drop the date field, because in-kernel documentation is
continually updated.
Signed-off-by: Jonathan Neuschäfer
---
Documentation/process/kernel-docs.rst | 23 +++
1 file changed, 11 insertions(+), 12 deletions(-)
diff --git a/Documentation/process/kernel-docs.rst
b/Documentation/process/kernel-docs.rst
index 05a7857a4a83..6ff8291194ee 100644
--- a/Documentation/process/kernel-docs.rst
+++ b/Documentation/process/kernel-docs.rst
@@ -84,6 +84,17 @@ The Sphinx books should be built with ``make {htmldocs |
pdfdocs | epubdocs}``.
different". Freely redistributable under the conditions of the GNU
General Public License.
+* Title: **Overview of the Virtual File System**
+
+ :Author: Richard Gooch.
+ :Location: Documentation/filesystems/vfs.txt
+ :Keywords: VFS, File System, mounting filesystems, opening files,
+dentries, dcache.
+ :Description: Brief introduction to the Linux Virtual File System.
+What is it, how it works, operations taken when opening a file or
+mounting a file system and description of important data
+structures explaining the purpose of each of their entries.
+
On-line docs
@@ -127,18 +138,6 @@ On-line docs
[...]. This paper examines some common problems for
submitting larger changes and some strategies to avoid problems.
-* Title: **Overview of the Virtual File System**
-
- :Author: Richard Gooch.
- :URL: http://www.mjmwired.net/kernel/Documentation/filesystems/vfs.txt
- :Date: 2007
- :Keywords: VFS, File System, mounting filesystems, opening files,
-dentries, dcache.
- :Description: Brief introduction to the Linux Virtual File System.
-What is it, how it works, operations taken when opening a file or
-mounting a file system and description of important data
-structures explaining the purpose of each of their entries.
-
* Title: **Linux Device Drivers, Third Edition**
:Author: Jonathan Corbet, Alessandro Rubini, Greg Kroah-Hartman
--
2.11.0
[PATCH 1/6] Documentation: coding-style: Escape \n\t to fix HTML rendering
Without this patch, Sphinx renders the sentence as follows, thus hiding the backslashes: [...] end each string except the last with nt to properly indent the next instruction [...] Signed-off-by: Jonathan Neuschäfer --- Documentation/process/coding-style.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/process/coding-style.rst b/Documentation/process/coding-style.rst index d20d52a4d812..7710c7e0240c 100644 --- a/Documentation/process/coding-style.rst +++ b/Documentation/process/coding-style.rst @@ -980,7 +980,7 @@ do so, though, and doing so unnecessarily can limit optimization. When writing a single inline assembly statement containing multiple instructions, put each instruction on a separate line in a separate quoted -string, and end each string except the last with \n\t to properly indent the +string, and end each string except the last with ``\n\t`` to properly indent the next instruction in the assembly output: .. code-block:: c -- 2.11.0
[PATCH 3/6] Documentation: kernel-docs: Remove "Here is its" at the end of lines
Before commit 9e03ea7f683e ("Documentation/kernel-docs.txt: convert it to
ReST markup"), it read:
Description: Linux Journal Kernel Korner article. Here is its
abstract: "..."
In Sphinx' HTML formatting, however, the "Here is its" doesn't make
sense anymore, because the "Abstract:" is clearly separated.
Signed-off-by: Jonathan Neuschäfer
---
Documentation/process/kernel-docs.rst | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/Documentation/process/kernel-docs.rst
b/Documentation/process/kernel-docs.rst
index 6ff8291194ee..a9aad381c3a4 100644
--- a/Documentation/process/kernel-docs.rst
+++ b/Documentation/process/kernel-docs.rst
@@ -356,7 +356,7 @@ On-line docs
:URL: http://www.linuxjournal.com/article.php?sid=2391
:Date: 1997
:Keywords: RAID, MD driver.
- :Description: Linux Journal Kernel Korner article. Here is its
+ :Description: Linux Journal Kernel Korner article.
:Abstract: *A description of the implementation of the RAID-1,
RAID-4 and RAID-5 personalities of the MD device driver in the
Linux kernel, providing users with high performance and reliable,
@@ -381,7 +381,7 @@ On-line docs
:Date: 1996
:Keywords: device driver, module, loading/unloading modules,
allocating resources.
- :Description: Linux Journal Kernel Korner article. Here is its
+ :Description: Linux Journal Kernel Korner article.
:Abstract: *This is the first of a series of four articles
co-authored by Alessandro Rubini and Georg Zezchwitz which present
a practical approach to writing Linux device drivers as kernel
@@ -397,7 +397,7 @@ On-line docs
:Keywords: character driver, init_module, clean_up module,
autodetection, mayor number, minor number, file operations,
open(), close().
- :Description: Linux Journal Kernel Korner article. Here is its
+ :Description: Linux Journal Kernel Korner article.
:Abstract: *This article, the second of four, introduces part of
the actual code to create custom module implementing a character
device driver. It describes the code for module initialization and
@@ -410,7 +410,7 @@ On-line docs
:Date: 1996
:Keywords: read(), write(), select(), ioctl(), blocking/non
blocking mode, interrupt handler.
- :Description: Linux Journal Kernel Korner article. Here is its
+ :Description: Linux Journal Kernel Korner article.
:Abstract: *This article, the third of four on writing character
device drivers, introduces concepts of reading, writing, and using
ioctl-calls*.
@@ -421,7 +421,7 @@ On-line docs
:URL: http://www.linuxjournal.com/article.php?sid=1222
:Date: 1996
:Keywords: interrupts, irqs, DMA, bottom halves, task queues.
- :Description: Linux Journal Kernel Korner article. Here is its
+ :Description: Linux Journal Kernel Korner article.
:Abstract: *This is the fourth in a series of articles about
writing character device drivers as loadable kernel modules. This
month, we further investigate the field of interrupt handling.
--
2.11.0
[PATCH 6/6] Documentation: mono: Update links and s/CVS/Git/
The old URLs redirect to the new ones, so just update them in mono.rst. Signed-off-by: Jonathan Neuschäfer --- Documentation/admin-guide/mono.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Documentation/admin-guide/mono.rst b/Documentation/admin-guide/mono.rst index cdddc099af64..77045ce548a0 100644 --- a/Documentation/admin-guide/mono.rst +++ b/Documentation/admin-guide/mono.rst @@ -9,14 +9,14 @@ This will allow you to execute Mono-based .NET binaries just like any other program after you have done the following: 1) You MUST FIRST install the Mono CLR support, either by downloading - a binary package, a source tarball or by installing from CVS. Binary + a binary package, a source tarball or by installing from Git. Binary packages for several distributions can be found at: - http://go-mono.com/download.html + http://www.mono-project.com/download/ Instructions for compiling Mono can be found at: - http://www.go-mono.com/compiling.html + http://www.mono-project.com/docs/compiling-mono/ Once the Mono CLR support has been installed, just check that ``/usr/bin/mono`` (which could be located elsewhere, for example -- 2.11.0
[PATCH 5/6] Documentation: howto: Remove outdated info about bugzilla mailing lists
The mailing list archives[1,2] show no activity since September 2011. [1]: https://lists.linuxfoundation.org/pipermail/bugme-new/ [2]: https://lists.linuxfoundation.org/pipermail/bugme-janitors/ Signed-off-by: Jonathan Neuschäfer --- Documentation/process/howto.rst | 8 1 file changed, 8 deletions(-) diff --git a/Documentation/process/howto.rst b/Documentation/process/howto.rst index 340fa18ff341..b696a51a832c 100644 --- a/Documentation/process/howto.rst +++ b/Documentation/process/howto.rst @@ -380,14 +380,6 @@ bugs is one of the best ways to get merits among other developers, because not many people like wasting time fixing other people's bugs. To work in the already reported bug reports, go to https://bugzilla.kernel.org. -If you want to be advised of the future bug reports, you can subscribe to the -bugme-new mailing list (only new bug reports are mailed here) or to the -bugme-janitor mailing list (every change in the bugzilla is mailed here) - - https://lists.linux-foundation.org/mailman/listinfo/bugme-new - - https://lists.linux-foundation.org/mailman/listinfo/bugme-janitors - Mailing lists -- 2.11.0
[PATCH 4/6] Documentation: Remove outdated info about -git patches
Since the 3.2 cycle, there were no -git patches/tarballs on kernel.org. Signed-off-by: Jonathan Neuschäfer --- Documentation/process/applying-patches.rst | 40 +- Documentation/process/howto.rst| 9 --- 2 files changed, 1 insertion(+), 48 deletions(-) diff --git a/Documentation/process/applying-patches.rst b/Documentation/process/applying-patches.rst index a0d058cc6d25..eaf3e0296d6d 100644 --- a/Documentation/process/applying-patches.rst +++ b/Documentation/process/applying-patches.rst @@ -344,7 +344,7 @@ possible. This is a good branch to run for people who want to help out testing development kernels but do not want to run some of the really experimental -stuff (such people should see the sections about -git and -mm kernels below). +stuff (such people should see the sections about -mm kernels below). The -rc patches are not incremental, they apply to a base 4.x kernel, just like the 4.x.y patches described above. The kernel version before the -rcN @@ -380,44 +380,6 @@ Here are 3 examples of how to apply these patches:: $ mv linux-4.7.3 linux-4.8-rc5 # rename the kernel source dir -The -git kernels - - -These are daily snapshots of Linus' kernel tree (managed in a git -repository, hence the name). - -These patches are usually released daily and represent the current state of -Linus's tree. They are more experimental than -rc kernels since they are -generated automatically without even a cursory glance to see if they are -sane. - --git patches are not incremental and apply either to a base 4.x kernel or -a base 4.x-rc kernel -- you can see which from their name. -A patch named 4.7-git1 applies to the 4.7 kernel source and a patch -named 4.8-rc3-git2 applies to the source of the 4.8-rc3 kernel. - -Here are some examples of how to apply these patches:: - - # moving from 4.7 to 4.7-git1 - - $ cd ~/linux-4.7# change to the kernel source dir - $ patch -p1 < ../patch-4.7-git1 # apply the 4.7-git1 patch - $ cd .. - $ mv linux-4.7 linux-4.7-git1 # rename the kernel source dir - - # moving from 4.7-git1 to 4.8-rc2-git3 - - $ cd ~/linux-4.7-git1 # change to the kernel source dir - $ patch -p1 -R < ../patch-4.7-git1 # revert the 4.7-git1 patch - # we now have a 4.7 kernel - $ patch -p1 < ../patch-4.8-rc2 # apply the 4.8-rc2 patch - # the kernel is now 4.8-rc2 - $ patch -p1 < ../patch-4.8-rc2-git3 # apply the 4.8-rc2-git3 patch - # the kernel is now 4.8-rc2-git3 - $ cd .. - $ mv linux-4.7-git1 linux-4.8-rc2-git3 # rename source dir - - The -mm patches and the linux-next tree === diff --git a/Documentation/process/howto.rst b/Documentation/process/howto.rst index 1260f60d4cb9..340fa18ff341 100644 --- a/Documentation/process/howto.rst +++ b/Documentation/process/howto.rst @@ -314,15 +314,6 @@ The file Documentation/process/stable-kernel-rules.rst in the kernel tree documents what kinds of changes are acceptable for the -stable tree, and how the release process works. -4.x -git patches - - -These are daily snapshots of Linus' kernel tree which are managed in a -git repository (hence the name.) These patches are usually released -daily and represent the current state of Linus' tree. They are more -experimental than -rc kernels since they are generated automatically -without even a cursory glance to see if they are sane. - Subsystem Specific kernel trees and patches ~~~ -- 2.11.0
Re: [PATCH v2 3/6] gpio: Add GPIO driver for Nintendo Wii
Hi,
On Sun, Jan 28, 2018 at 07:31:58PM +0200, Andy Shevchenko wrote:
> On Mon, Jan 22, 2018 at 7:04 AM, Jonathan Neuschäfer
> wrote:
>
> Style issues below.
>
> > +#define HW_GPIO_OWNER 0x3c
> > +
> > +
> > +struct hlwd_gpio {
>
> No need extra empty line in between.
Ok.
> > + struct gpio_chip gpioc;
> > + void __iomem *regs;
> > + struct device *dev;
> > +};
> > +
> > +static int hlwd_gpio_probe(struct platform_device *pdev)
> > +{
> > + struct hlwd_gpio *hlwd;
> > + struct resource *regs_resource;
> > + u32 ngpios;
> > + int res;
> > +
> > + hlwd = devm_kzalloc(&pdev->dev, sizeof(*hlwd), GFP_KERNEL);
> > + if (!hlwd)
> > + return -ENOMEM;
> > +
>
> > + /* Save the struct device pointer so dev_info, etc. can be used. */
>
> Useless.
Ok
> > + hlwd->dev = &pdev->dev;
> > +
>
> > + regs_resource = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>
> > + if (IS_ERR(regs_resource))
> > + return PTR_ERR(regs_resource);
> > +
>
> This is redundant. Below does it for ya.
devm_ioremap_resource does not check if the resource argument is a
negative error (which is what I'm trying to catch in the above code).
But it seems that platform_get_resource can't return a negative error,
so you're right. Thanks.
>
> > + hlwd->regs = devm_ioremap_resource(&pdev->dev, regs_resource);
> > + if (IS_ERR(hlwd->regs))
> > + return PTR_ERR(hlwd->regs);
>
>
> > + res = bgpio_init(&hlwd->gpioc, &pdev->dev, 4,
> > + hlwd->regs + HW_GPIOB_IN, hlwd->regs + HW_GPIOB_OUT,
> > + NULL, hlwd->regs + HW_GPIOB_DIR, NULL,
> > + BGPIOF_BIG_ENDIAN_BYTE_ORDER);
>
> > +
>
> Remove this extra line.
Ok.
>
> > + if (res < 0) {
> > + dev_warn(hlwd->dev, "bgpio_init failed: %d\n", res);
> > + return res;
> > + }
>
> > + if (of_property_read_u32(pdev->dev.of_node, "ngpios", &ngpios))
> > + ngpios = 32;
>
> A nit: I would rather go with
> res = of_property_read(...);
> if (res)
> ngpios = 32;
Ok, I have no strong opinion on this, so I'll do what you suggest.
Thanks,
Jonathan Neuschäfer
signature.asc
Description: PGP signature
Re: [PATCH 4/6] dt-bindings: gpio: Add binding for Wii GPIO controller
On Fri, Jan 19, 2018 at 05:05:21PM -0600, Rob Herring wrote:
> On Mon, Jan 15, 2018 at 04:13:59AM +0100, Jonathan Neuschäfer wrote:
> > Signed-off-by: Jonathan Neuschäfer
> > ---
> > .../bindings/gpio/nintendo,hollywood-gpio.txt | 27
> > ++
> > .../devicetree/bindings/powerpc/nintendo/wii.txt | 9 +---
> > 2 files changed, 28 insertions(+), 8 deletions(-)
> > create mode 100644
> > Documentation/devicetree/bindings/gpio/nintendo,hollywood-gpio.txt
[...]
> > +Example:
> > +
> > + GPIO: gpio@0d8000c0 {
>
> Drop the leading 0.
Ok, will do.
> With that,
>
> Reviewed-by: Rob Herring
Thanks.
Jonathan Neuschäfer
signature.asc
Description: PGP signature
[PATCH v2 2/6] powerpc: wii: Explicitly configure GPIO owner for poweroff pin
The Hollywood chipset's GPIO controller has two sets of registers: One
for access by the PowerPC CPU, and one for access by the ARM coprocessor
(but both are accessible from the PPC because the memory firewall
(AHBPROT) is usually disabled when booting Linux, today).
The wii_power_off function currently assumes that the poweroff GPIO pin
is configured for use via the ARM side, but the upcoming GPIO driver
configures all pins for use via the PPC side, breaking poweroff.
Configure the owner register explicitly in wii_power_off to make
wii_power_off work with and without the new GPIO driver.
I think the Wii can be switched to the generic gpio-poweroff driver,
after the GPIO driver is merged.
Signed-off-by: Jonathan Neuschäfer
---
v2:
- no change
---
arch/powerpc/platforms/embedded6xx/wii.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/powerpc/platforms/embedded6xx/wii.c
b/arch/powerpc/platforms/embedded6xx/wii.c
index 79a1fe54ebc9..6e6db1e16d71 100644
--- a/arch/powerpc/platforms/embedded6xx/wii.c
+++ b/arch/powerpc/platforms/embedded6xx/wii.c
@@ -45,6 +45,7 @@
#define HW_GPIO_BASE(idx) (idx * 0x20)
#define HW_GPIO_OUT(idx) (HW_GPIO_BASE(idx) + 0)
#define HW_GPIO_DIR(idx) (HW_GPIO_BASE(idx) + 4)
+#define HW_GPIO_OWNER (HW_GPIO_BASE(1) + 0x1c)
#define HW_GPIO_SHUTDOWN (1<<1)
#define HW_GPIO_SLOT_LED (1<<5)
@@ -177,6 +178,12 @@ static void wii_power_off(void)
local_irq_disable();
if (hw_gpio) {
+ /*
+* set the owner of the shutdown pin to ARM, because it is
+* accessed through the registers for the ARM, below
+*/
+ clrbits32(hw_gpio + HW_GPIO_OWNER, HW_GPIO_SHUTDOWN);
+
/* make sure that the poweroff GPIO is configured as output */
setbits32(hw_gpio + HW_GPIO_DIR(1), HW_GPIO_SHUTDOWN);
--
2.15.1
[PATCH v2 0/6] Nintendo Wii GPIO driver
This series adds a driver for the GPIO controller used in the Nintendo Wii game console. The driver itself, and the related devicetree work should be pretty uncontroversial, but due to the system architecture of the Wii, I also had to extend an old resource allocation hack to kernel/resource.c: On the Wii, there are two separate RAM ranges, with MMIO right in the middle, but AFAIK, Linux on PPC32 doesn't support discontiguous memory properly. So the hack is to allocate one big RAM range with a hole (marked as reserved memory) for MMIO in the middle. Because this series touches different subsystems (GPIO, DT, core resource management), I guess it should be picked up patch-by-patch by the different maintainers. The main difference between v2 and the previous version is that I rewrote the driver on top of the GPIO_GENERIC library, saving 60 lines of code. Jonathan Neuschäfer (6): resource: Extend the PPC32 reserved memory hack powerpc: wii: Explicitly configure GPIO owner for poweroff pin gpio: Add GPIO driver for Nintendo Wii dt-bindings: gpio: Add binding for Wii GPIO controller powerpc: wii.dts: Add ngpios property powerpc: wii.dts: Add GPIO line names .../bindings/gpio/nintendo,hollywood-gpio.txt | 27 + .../devicetree/bindings/powerpc/nintendo/wii.txt | 9 +- arch/powerpc/boot/dts/wii.dts | 9 ++ arch/powerpc/platforms/embedded6xx/wii.c | 7 ++ drivers/gpio/Kconfig | 9 ++ drivers/gpio/Makefile | 1 + drivers/gpio/gpio-hlwd.c | 123 + kernel/resource.c | 21 +++- 8 files changed, 197 insertions(+), 9 deletions(-) create mode 100644 Documentation/devicetree/bindings/gpio/nintendo,hollywood-gpio.txt create mode 100644 drivers/gpio/gpio-hlwd.c -- 2.15.1
[PATCH v2 4/6] dt-bindings: gpio: Add binding for Wii GPIO controller
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
Reviewed-by: Rob Herring
---
v2:
- Drop the leading zero in the example, as suggested by Rob Herring
- Add some text to the commit message, as suggested by Linus Walleij
---
.../bindings/gpio/nintendo,hollywood-gpio.txt | 27 ++
.../devicetree/bindings/powerpc/nintendo/wii.txt | 9 +---
2 files changed, 28 insertions(+), 8 deletions(-)
create mode 100644
Documentation/devicetree/bindings/gpio/nintendo,hollywood-gpio.txt
diff --git a/Documentation/devicetree/bindings/gpio/nintendo,hollywood-gpio.txt
b/Documentation/devicetree/bindings/gpio/nintendo,hollywood-gpio.txt
new file mode 100644
index ..20fc72d9e61e
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/nintendo,hollywood-gpio.txt
@@ -0,0 +1,27 @@
+Nintendo Wii (Hollywood) GPIO controller
+
+Required properties:
+- compatible: "nintendo,hollywood-gpio
+- reg: Physical base address and length of the controller's registers.
+- gpio-controller: Marks the device node as a GPIO controller.
+- #gpio-cells: Should be <2>. The first cell is the pin number and the
+ second cell is used to specify optional parameters:
+ - bit 0 specifies polarity (0 for normal, 1 for inverted).
+
+Optional properties:
+- ngpios: see Documentation/devicetree/bindings/gpio/gpio.txt
+- interrupt-controller: Marks the device node as an interrupt controller.
+- #interrupt-cells: Should be two.
+- interrupts: Interrupt specifier for the controller's Broadway (PowerPC)
+ interrupt.
+- interrupt-parent: phandle of the parent interrupt controller.
+
+Example:
+
+ GPIO: gpio@d8000c0 {
+ #gpio-cells = <2>;
+ compatible = "nintendo,hollywood-gpio";
+ reg = <0x0d8000c0 0x40>;
+ gpio-controller;
+ ngpios = <24>;
+ }
diff --git a/Documentation/devicetree/bindings/powerpc/nintendo/wii.txt
b/Documentation/devicetree/bindings/powerpc/nintendo/wii.txt
index 36afa322b04b..a3dc4b9fa11a 100644
--- a/Documentation/devicetree/bindings/powerpc/nintendo/wii.txt
+++ b/Documentation/devicetree/bindings/powerpc/nintendo/wii.txt
@@ -152,14 +152,7 @@ Nintendo Wii device tree
1.l) The General Purpose I/O (GPIO) controller node
- Represents the dual access 32 GPIO controller interface.
-
- Required properties:
-
- - #gpio-cells : <2>
- - compatible : should be "nintendo,hollywood-gpio"
- - reg : should contain the IPC registers location and length
- - gpio-controller
+ see Documentation/devicetree/bindings/gpio/nintendo,hollywood-gpio.txt
1.m) The control node
--
2.15.1
[PATCH v2 3/6] gpio: Add GPIO driver for Nintendo Wii
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
Cc: Albert Herranz
Cc: Segher Boessenkool
---
v2:
- Change hlwd_gpio_driver.driver.name to "gpio-hlwd" to match the
filename (was "hlwd_gpio")
- Remove unnecessary include of linux/of_gpio.h, as suggested by Linus
Walleij.
- Add struct device pointer to context struct to make it possible to use
dev_info(hlwd->dev, "..."), as suggested by Linus Walleij
- Use the GPIO_GENERIC library to reduce code size, as suggested by
Linus Walleij
- Use iowrite32be instead of __raw_writel for big-endian MMIO access, as
suggested by Linus Walleij
- Remove commit message paragraph suggesting to diff against the
original driver, because it's so different now
---
drivers/gpio/Kconfig | 9
drivers/gpio/Makefile| 1 +
drivers/gpio/gpio-hlwd.c | 123 +++
3 files changed, 133 insertions(+)
create mode 100644 drivers/gpio/gpio-hlwd.c
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index d6a8e851ad13..47606dfe06cc 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -229,6 +229,15 @@ config GPIO_GRGPIO
Select this to support Aeroflex Gaisler GRGPIO cores from the GRLIB
VHDL IP core library.
+config GPIO_HLWD
+ tristate "Nintendo Wii (Hollywood) GPIO"
+ depends on OF_GPIO
+ select GPIO_GENERIC
+ help
+ Select this to support the GPIO controller of the Nintendo Wii.
+
+ If unsure, say N.
+
config GPIO_ICH
tristate "Intel ICH GPIO"
depends on PCI && X86
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 4bc24febb889..492f62d0eb59 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -54,6 +54,7 @@ obj-$(CONFIG_GPIO_FTGPIO010) += gpio-ftgpio010.o
obj-$(CONFIG_GPIO_GE_FPGA) += gpio-ge.o
obj-$(CONFIG_GPIO_GPIO_MM) += gpio-gpio-mm.o
obj-$(CONFIG_GPIO_GRGPIO) += gpio-grgpio.o
+obj-$(CONFIG_GPIO_HLWD)+= gpio-hlwd.o
obj-$(CONFIG_HTC_EGPIO)+= gpio-htc-egpio.o
obj-$(CONFIG_GPIO_ICH) += gpio-ich.o
obj-$(CONFIG_GPIO_INGENIC) += gpio-ingenic.o
diff --git a/drivers/gpio/gpio-hlwd.c b/drivers/gpio/gpio-hlwd.c
new file mode 100644
index ..cf3f05a1621c
--- /dev/null
+++ b/drivers/gpio/gpio-hlwd.c
@@ -0,0 +1,123 @@
+// SPDX-License-Identifier: GPL-2.0+
+// Copyright (C) 2008-2009 The GameCube Linux Team
+// Copyright (C) 2008,2009 Albert Herranz
+// Copyright (C) 2017-2018 Jonathan Neuschäfer
+//
+// Nintendo Wii (Hollywood) GPIO driver
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/*
+ * Register names and offsets courtesy of WiiBrew:
+ * https://wiibrew.org/wiki/Hardware/Hollywood_GPIOs
+ *
+ * Note that for most registers, there are two versions:
+ * - HW_GPIOB_* Is always accessible by the Broadway PowerPC core, but does
+ * always give access to all GPIO lines
+ * - HW_GPIO_* Is only accessible by the Broadway PowerPC code if the memory
+ * firewall (AHBPROT) in the Hollywood chipset has been configured to allow
+ * such access.
+ *
+ * The ownership of each GPIO line can be configured in the HW_GPIO_OWNER
+ * register: A one bit configures the line for access via the HW_GPIOB_*
+ * registers, a zero bit indicates access via HW_GPIO_*. This driver uses
+ * HW_GPIOB_*.
+ */
+#define HW_GPIOB_OUT 0x00
+#define HW_GPIOB_DIR 0x04
+#define HW_GPIOB_IN0x08
+#define HW_GPIOB_INTLVL0x0c
+#define HW_GPIOB_INTFLAG 0x10
+#define HW_GPIOB_INTMASK 0x14
+#define HW_GPIOB_INMIR 0x18
+#define HW_GPIO_ENABLE 0x1c
+#define HW_GPIO_OUT0x20
+#define HW_GPIO_DIR0x24
+#define HW_GPIO_IN 0x28
+#define HW_GPIO_INTLVL 0x2c
+#define HW_GPIO_INTFLAG0x30
+#define HW_GPIO_INTMASK0x34
+#define HW_GPIO_INMIR 0x38
+#define HW_GPIO_OWNER 0x3c
+
+
+struct hlwd_gpio {
+ struct gpio_chip gpioc;
+ void __iomem *regs;
+ struct device *dev;
+};
+
+static int hlwd_gpio_probe(struct platform_device *pdev)
+{
+ struct hlwd_gpio *hlwd;
+ struct resource *regs_resource;
+ u32 ngpios;
+ int res;
+
[PATCH v2 1/6] resource: Extend the PPC32 reserved memory hack
On the Nintendo Wii, there are two ranges of physical memory, and MMIO
in between, but Linux on ppc32 doesn't support discontiguous memory.
Therefore a hack was introduced in commit c5df7f775148 ("powerpc: allow
ioremap within reserved memory regions") and commit de32400dd26e ("wii:
use both mem1 and mem2 as ram"):
- Treat the area from the start of the first memory area (MEM1) to the
end of the second (MEM2) as one big memory area, but mark the part
that doesn't belong to MEM1 or MEM2 as reserved.
- Only on the Wii, allow ioremap to be used on reserved memory.
This hack, however, doesn't account for the "resource"-based API in
kernel/resource.c, because __request_region performs its own checks.
Extend the hack to kernel/resource.c, to allow more drivers to allocate
their MMIO regions on the Wii.
Signed-off-by: Jonathan Neuschäfer
Cc: Albert Herranz
---
v2:
- CC Albert Herranz, who introduced this hack in 2009.
---
kernel/resource.c | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/kernel/resource.c b/kernel/resource.c
index 54ba6de3757c..bb3d329329da 100644
--- a/kernel/resource.c
+++ b/kernel/resource.c
@@ -1134,6 +1134,24 @@ resource_size_t resource_alignment(struct resource *res)
static DECLARE_WAIT_QUEUE_HEAD(muxed_resource_wait);
+/*
+ * On some ppc32 platforms (Nintendo Wii), reserved memory is used to work
+ * around the fact that Linux doesn't support discontiguous memory (all memory
+ * is treated as one large area with holes punched in it), and reserved memory
+ * is allowed to be allocated.
+ */
+#ifdef CONFIG_PPC32
+static bool conflict_ignored(struct resource *conflict)
+{
+ extern int __allow_ioremap_reserved;
+
+ return __allow_ioremap_reserved &&
+ (conflict->flags & IORESOURCE_SYSRAM);
+}
+#else
+static bool conflict_ignored(struct resource *conflict) { return false; }
+#endif
+
/**
* __request_region - create a new busy resource region
* @parent: parent resource descriptor
@@ -1166,8 +1184,9 @@ struct resource * __request_region(struct resource
*parent,
res->desc = parent->desc;
conflict = __request_resource(parent, res);
- if (!conflict)
+ if (!conflict || conflict_ignored(conflict))
break;
+
if (conflict != parent) {
if (!(conflict->flags & IORESOURCE_BUSY)) {
parent = conflict;
--
2.15.1
[PATCH v2 5/6] powerpc: wii.dts: Add ngpios property
The Hollywood GPIO controller supports 32 GPIOs, but on the Wii, only 24 are used. Signed-off-by: Jonathan Neuschäfer --- v2: - no change --- arch/powerpc/boot/dts/wii.dts | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/powerpc/boot/dts/wii.dts b/arch/powerpc/boot/dts/wii.dts index 40b324b6391e..7235e375919c 100644 --- a/arch/powerpc/boot/dts/wii.dts +++ b/arch/powerpc/boot/dts/wii.dts @@ -176,6 +176,7 @@ compatible = "nintendo,hollywood-gpio"; reg = <0x0d8000c0 0x40>; gpio-controller; + ngpios = <24>; /* * This is commented out while a standard binding -- 2.15.1
[PATCH v2 6/6] powerpc: wii.dts: Add GPIO line names
These are the GPIO line names on a Nintendo Wii, as documented in: https://wiibrew.org/wiki/Hardware/Hollywood_GPIOs Signed-off-by: Jonathan Neuschäfer --- v2: - no change --- arch/powerpc/boot/dts/wii.dts | 8 1 file changed, 8 insertions(+) diff --git a/arch/powerpc/boot/dts/wii.dts b/arch/powerpc/boot/dts/wii.dts index 7235e375919c..07d5e84e98b1 100644 --- a/arch/powerpc/boot/dts/wii.dts +++ b/arch/powerpc/boot/dts/wii.dts @@ -178,6 +178,14 @@ gpio-controller; ngpios = <24>; + gpio-line-names = + "POWER", "SHUTDOWN", "FAN", "DC_DC", + "DI_SPIN", "SLOT_LED", "EJECT_BTN", "SLOT_IN", + "SENSOR_BAR", "DO_EJECT", "EEP_CS", "EEP_CLK", + "EEP_MOSI", "EEP_MISO", "AVE_SCL", "AVE_SDA", + "DEBUG0", "DEBUG1", "DEBUG2", "DEBUG3", + "DEBUG4", "DEBUG5", "DEBUG6", "DEBUG7"; + /* * This is commented out while a standard binding * for i2c over gpio is defined. -- 2.15.1
Re: [PATCH v2 1/6] resource: Extend the PPC32 reserved memory hack
On Wed, Jan 24, 2018 at 12:23:05PM +1100, Michael Ellerman wrote:
> Jonathan Neuschäfer writes:
[...]
> > Do you have any pointer on how to implement discontiguous memory
> > support? CONFIG_ARCH_SPARSEMEM_ENABLE seems relevant.
>
> I'm not really sure what the key impediment to it working is.
>
> You don't need to go all the way to SPARSEMEM, there is DISCONTIGMEM
> which IIUI is quite a bit simpler.
>
> I'd actually be interested to know what happens (ie. breaks) if you just
> add the two memblocks and leave the hole in between. Is it the generic
> code that breaks or is it something in the powerpc code? If it's the
> later maybe we can do a small fix/hack to work around that.
Ok, I did some experimentation.
First, I made wii_memory_fixups return early, before actually doing
anything[1].
[0.00] __ioremap(): phys addr 0xc003000 is RAM lr flipper_pic_init
[0.00] flipper-pic: controller at 0x0c003000 mapped to 0x (null)
[0.00] Unable to handle kernel paging request for data at address
0x0004
* __ioremap_caller detects overlap with RAM like this: p <
virt_to_phys(high_memory)
* flipper_pic_init gets NULL from ioremap, but doesn't check for NULL
Then I hacked up __ioremap_caller to use memblock_is_map_memory[2],
because it considers memblocks correctly. The result was that the system
boots further, but then enters the sleep mode where the power LED shines
yellow. In this mode the ARM runs but the PPC doesn't. The same thing
would happen if GPIO 3 ("DC_DC"[3]) was pulled low. These are the last few
lines:
[0.770324] io scheduler mq-deadline registered
[0.772472] io scheduler kyber registered
I don't know what exactly is triggering this effect.
Thanks for your help,
Jonathan Neuschäfer
[1]: diff --git a/arch/powerpc/platforms/embedded6xx/wii.c
b/arch/powerpc/platforms/embedded6xx/wii.c
index 6e6db1e16d71..cddd5606a63d 100644
--- a/arch/powerpc/platforms/embedded6xx/wii.c
+++ b/arch/powerpc/platforms/embedded6xx/wii.c
@@ -81,6 +81,9 @@ void __init wii_memory_fixups(void)
BUG_ON(memblock.memory.cnt != 2);
BUG_ON(!page_aligned(p[0].base) || !page_aligned(p[1].base));
+ /* don't fix the memory map */
+ return;
+
/* trim unaligned tail */
memblock_remove(ALIGN(p[1].base + p[1].size, PAGE_SIZE),
(phys_addr_t)ULLONG_MAX);
[2]: diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c
index f6c7f54c0515..bff581003c50 100644
--- a/arch/powerpc/mm/pgtable_32.c
+++ b/arch/powerpc/mm/pgtable_32.c
@@ -154,8 +154,7 @@ __ioremap_caller(phys_addr_t addr, unsigned long size,
unsigned long flags,
* Don't allow anybody to remap normal RAM that we're using.
* mem_init() sets high_memory so only do the check after that.
*/
- if (slab_is_available() && (p < virt_to_phys(high_memory)) &&
- !(__allow_ioremap_reserved && memblock_is_region_reserved(p,
size))) {
+ if (slab_is_available() && memblock_is_map_memory(p)) {
printk("__ioremap(): phys addr 0x%llx is RAM lr %ps\n",
(unsigned long long)p, __builtin_return_address(0));
return NULL;
[3]: http://wiibrew.org/wiki/Hardware/Hollywood_GPIOs
signature.asc
Description: PGP signature
Re: [PATCH 3/6] gpio: Add GPIO driver for Nintendo Wii
On Tue, Jan 16, 2018 at 10:42:54AM +0100, Linus Walleij wrote:
> On Mon, Jan 15, 2018 at 4:13 AM, Jonathan Neuschäfer
> 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.
Ah, that's the name! I didn't find ioread32*/iowrite32* in the
documentation or source code.
> But when I look at it, I think you can just use the gpio-mmio library
> for this driver and cut down code cosiderably.
I'll look into it. So far it looks good (drivers/gpio/gpio-iop.c has
just 60 lines).
> > +#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?
Makes sense. I'll try this out.
> > +#include
>
> This include should not be needed.
Okay.
> > +/*
> > + * 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(&hlwd->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(&hlwd->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.
Yes, I plan to add IRQ support in a later patch.
>
> See the other drivers.
Yep, gpio-mmio looks like a good option, thanks for the pointer!
Thanks,
Jonathan Neuschäfer
signature.asc
Description: PGP signature
[PATCH 0/6] Nintendo Wii GPIO driver
This series adds a driver for the GPIO controller used in the Nintendo Wii game console. The driver itself, and the related devicetree work should be pretty uncontroversial, but due to the system architecture of the Wii, I also had to extend an old resource allocation hack to kernel/resource.c: On the Wii, there are two separate RAM ranges, with MMIO right in the middle, but AFAIK, Linux on PPC32 doesn't support discontiguous memory properly. So the hack is to allocate one big RAM range with a hole (marked as reserved memory) for MMIO in the middle. Because this series touches different subsystems (GPIO, DT, core resource management), I guess it should be picked up patch-by-patch by the different maintainers. Jonathan Neuschäfer (6): resource: Extend the PPC32 reserved memory hack powerpc: wii: Explicitly configure GPIO owner for poweroff pin gpio: Add GPIO driver for Nintendo Wii dt-bindings: gpio: Add binding for Wii GPIO controller powerpc: wii.dts: Add ngpios property powerpc: wii.dts: Add GPIO line names .../bindings/gpio/nintendo,hollywood-gpio.txt | 27 +++ .../devicetree/bindings/powerpc/nintendo/wii.txt | 9 +- arch/powerpc/boot/dts/wii.dts | 9 + arch/powerpc/platforms/embedded6xx/wii.c | 7 + drivers/gpio/Kconfig | 8 + drivers/gpio/Makefile | 1 + drivers/gpio/gpio-hlwd.c | 183 + kernel/resource.c | 21 ++- 8 files changed, 256 insertions(+), 9 deletions(-) create mode 100644 Documentation/devicetree/bindings/gpio/nintendo,hollywood-gpio.txt create mode 100644 drivers/gpio/gpio-hlwd.c -- 2.15.1
[PATCH 6/6] powerpc: wii.dts: Add GPIO line names
These are the GPIO line names on a Nintendo Wii, as documented in: https://wiibrew.org/wiki/Hardware/Hollywood_GPIOs Signed-off-by: Jonathan Neuschäfer --- arch/powerpc/boot/dts/wii.dts | 8 1 file changed, 8 insertions(+) diff --git a/arch/powerpc/boot/dts/wii.dts b/arch/powerpc/boot/dts/wii.dts index 7235e375919c..07d5e84e98b1 100644 --- a/arch/powerpc/boot/dts/wii.dts +++ b/arch/powerpc/boot/dts/wii.dts @@ -178,6 +178,14 @@ gpio-controller; ngpios = <24>; + gpio-line-names = + "POWER", "SHUTDOWN", "FAN", "DC_DC", + "DI_SPIN", "SLOT_LED", "EJECT_BTN", "SLOT_IN", + "SENSOR_BAR", "DO_EJECT", "EEP_CS", "EEP_CLK", + "EEP_MOSI", "EEP_MISO", "AVE_SCL", "AVE_SDA", + "DEBUG0", "DEBUG1", "DEBUG2", "DEBUG3", + "DEBUG4", "DEBUG5", "DEBUG6", "DEBUG7"; + /* * This is commented out while a standard binding * for i2c over gpio is defined. -- 2.15.1
[PATCH 2/6] powerpc: wii: Explicitly configure GPIO owner for poweroff pin
The Hollywood chipset's GPIO controller has two sets of registers: One
for access by the PowerPC CPU, and one for access by the ARM coprocessor
(but both are accessible from the PPC because the memory firewall
(AHBPROT) is usually disabled when booting Linux, today).
The wii_power_off function currently assumes that the poweroff GPIO pin
is configured for use via the ARM side, but the upcoming GPIO driver
configures all pins for use via the PPC side, breaking poweroff.
Configure the owner register explicitly in wii_power_off to make
wii_power_off work with and without the new GPIO driver.
I think the Wii can be switched to the generic gpio-poweroff driver,
after the GPIO driver is merged.
Signed-off-by: Jonathan Neuschäfer
---
arch/powerpc/platforms/embedded6xx/wii.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/powerpc/platforms/embedded6xx/wii.c
b/arch/powerpc/platforms/embedded6xx/wii.c
index 79a1fe54ebc9..6e6db1e16d71 100644
--- a/arch/powerpc/platforms/embedded6xx/wii.c
+++ b/arch/powerpc/platforms/embedded6xx/wii.c
@@ -45,6 +45,7 @@
#define HW_GPIO_BASE(idx) (idx * 0x20)
#define HW_GPIO_OUT(idx) (HW_GPIO_BASE(idx) + 0)
#define HW_GPIO_DIR(idx) (HW_GPIO_BASE(idx) + 4)
+#define HW_GPIO_OWNER (HW_GPIO_BASE(1) + 0x1c)
#define HW_GPIO_SHUTDOWN (1<<1)
#define HW_GPIO_SLOT_LED (1<<5)
@@ -177,6 +178,12 @@ static void wii_power_off(void)
local_irq_disable();
if (hw_gpio) {
+ /*
+* set the owner of the shutdown pin to ARM, because it is
+* accessed through the registers for the ARM, below
+*/
+ clrbits32(hw_gpio + HW_GPIO_OWNER, HW_GPIO_SHUTDOWN);
+
/* make sure that the poweroff GPIO is configured as output */
setbits32(hw_gpio + HW_GPIO_DIR(1), HW_GPIO_SHUTDOWN);
--
2.15.1
[PATCH 4/6] dt-bindings: gpio: Add binding for Wii GPIO controller
Signed-off-by: Jonathan Neuschäfer
---
.../bindings/gpio/nintendo,hollywood-gpio.txt | 27 ++
.../devicetree/bindings/powerpc/nintendo/wii.txt | 9 +---
2 files changed, 28 insertions(+), 8 deletions(-)
create mode 100644
Documentation/devicetree/bindings/gpio/nintendo,hollywood-gpio.txt
diff --git a/Documentation/devicetree/bindings/gpio/nintendo,hollywood-gpio.txt
b/Documentation/devicetree/bindings/gpio/nintendo,hollywood-gpio.txt
new file mode 100644
index ..a97ce6b5b724
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/nintendo,hollywood-gpio.txt
@@ -0,0 +1,27 @@
+Nintendo Wii (Hollywood) GPIO controller
+
+Required properties:
+- compatible: "nintendo,hollywood-gpio
+- reg: Physical base address and length of the controller's registers.
+- gpio-controller: Marks the device node as a GPIO controller.
+- #gpio-cells: Should be <2>. The first cell is the pin number and the
+ second cell is used to specify optional parameters:
+ - bit 0 specifies polarity (0 for normal, 1 for inverted).
+
+Optional properties:
+- ngpios: see Documentation/devicetree/bindings/gpio/gpio.txt
+- interrupt-controller: Marks the device node as an interrupt controller.
+- #interrupt-cells: Should be two.
+- interrupts: Interrupt specifier for the controller's Broadway (PowerPC)
+ interrupt.
+- interrupt-parent: phandle of the parent interrupt controller.
+
+Example:
+
+ GPIO: gpio@0d8000c0 {
+ #gpio-cells = <2>;
+ compatible = "nintendo,hollywood-gpio";
+ reg = <0x0d8000c0 0x40>;
+ gpio-controller;
+ ngpios = <24>;
+ }
diff --git a/Documentation/devicetree/bindings/powerpc/nintendo/wii.txt
b/Documentation/devicetree/bindings/powerpc/nintendo/wii.txt
index 36afa322b04b..a3dc4b9fa11a 100644
--- a/Documentation/devicetree/bindings/powerpc/nintendo/wii.txt
+++ b/Documentation/devicetree/bindings/powerpc/nintendo/wii.txt
@@ -152,14 +152,7 @@ Nintendo Wii device tree
1.l) The General Purpose I/O (GPIO) controller node
- Represents the dual access 32 GPIO controller interface.
-
- Required properties:
-
- - #gpio-cells : <2>
- - compatible : should be "nintendo,hollywood-gpio"
- - reg : should contain the IPC registers location and length
- - gpio-controller
+ see Documentation/devicetree/bindings/gpio/nintendo,hollywood-gpio.txt
1.m) The control node
--
2.15.1
[PATCH 3/6] gpio: Add GPIO driver for Nintendo Wii
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.
To compare this version of the driver against the original code:
$ git fetch https://github.com/DeltaResero/GC-Wii-Linux-Kernels
$ git co FETCH_HEAD -- arch/powerpc/platforms/embedded6xx/hlwd-gpio.c
$ diff -u arch/powerpc/platforms/embedded6xx/hlwd-gpio.c \
drivers/gpio/gpio-hlwd.c
Cc: Albert Herranz
Cc: Segher Boessenkool
Signed-off-by: Jonathan Neuschäfer
---
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).
---
drivers/gpio/Kconfig | 8 +++
drivers/gpio/Makefile| 1 +
drivers/gpio/gpio-hlwd.c | 183 +++
3 files changed, 192 insertions(+)
create mode 100644 drivers/gpio/gpio-hlwd.c
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index d6a8e851ad13..4f85c2053f7d 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -229,6 +229,14 @@ config GPIO_GRGPIO
Select this to support Aeroflex Gaisler GRGPIO cores from the GRLIB
VHDL IP core library.
+config GPIO_HLWD
+ tristate "Nintendo Wii (Hollywood) GPIO"
+ depends on OF_GPIO
+ help
+ Select this to support the GPIO controller of the Nintendo Wii.
+
+ If unsure, say N.
+
config GPIO_ICH
tristate "Intel ICH GPIO"
depends on PCI && X86
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 4bc24febb889..492f62d0eb59 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -54,6 +54,7 @@ obj-$(CONFIG_GPIO_FTGPIO010) += gpio-ftgpio010.o
obj-$(CONFIG_GPIO_GE_FPGA) += gpio-ge.o
obj-$(CONFIG_GPIO_GPIO_MM) += gpio-gpio-mm.o
obj-$(CONFIG_GPIO_GRGPIO) += gpio-grgpio.o
+obj-$(CONFIG_GPIO_HLWD)+= gpio-hlwd.o
obj-$(CONFIG_HTC_EGPIO)+= gpio-htc-egpio.o
obj-$(CONFIG_GPIO_ICH) += gpio-ich.o
obj-$(CONFIG_GPIO_INGENIC) += gpio-ingenic.o
diff --git a/drivers/gpio/gpio-hlwd.c b/drivers/gpio/gpio-hlwd.c
new file mode 100644
index ..0f8942ea6ed6
--- /dev/null
+++ b/drivers/gpio/gpio-hlwd.c
@@ -0,0 +1,183 @@
+// SPDX-License-Identifier: GPL-2.0+
+// Copyright (C) 2008-2009 The GameCube Linux Team
+// Copyright (C) 2008,2009 Albert Herranz
+// Copyright (C) 2017-2018 Jonathan Neuschäfer
+//
+// Nintendo Wii (Hollywood) GPIO driver
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/*
+ * Register names and offsets courtesy of WiiBrew:
+ * https://wiibrew.org/wiki/Hardware/Hollywood_GPIOs
+ *
+ * Note that for most registers, there are two versions:
+ * - HW_GPIOB_* Is always accessible by the Broadway PowerPC core, but does
+ * always give access to all GPIO lines
+ * - HW_GPIO_* Is only accessible by the Broadway PowerPC code if the memory
+ * firewall (AHBPROT) in the Hollywood chipset has been configured to allow
+ * such access.
+ *
+ * The ownership of each GPIO line can be configured in the HW_GPIO_OWNER
+ * register: A one bit configures the line for access via the HW_GPIOB_*
+ * registers, a zero bit indicates access via HW_GPIO_*. This driver uses
+ * HW_GPIOB_*.
+ */
+#define HW_GPIOB_OUT 0x00
+#define HW_GPIOB_DIR 0x04
+#define HW_GPIOB_IN0x08
+#define HW_GPIOB_INTLVL0x0c
+#define HW_GPIOB_INTFLAG 0x10
+#define HW_GPIOB_INTMASK 0x14
+#define HW_GPIOB_INMIR 0x18
+#define HW_GPIO_ENABLE 0x1c
+#define HW_GPIO_OUT0x20
+#define HW_GPIO_DIR0x24
+#define HW_GPIO_IN 0x28
+#define HW_GPIO_INTLVL 0x2c
+#define HW_GPIO_INTFLAG0x30
+#define HW_GPIO_INTMASK0x34
+#define HW_GPIO_INMIR 0x38
+#define HW_GPIO_OWNER 0x3c
+
+
+struct hlwd_gpio {
+ struct gpio_chip gpioc;
+ void __iomem *regs;
+ spinlock_t lock;
+};
+
+/*
+ * 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,
+
[PATCH 5/6] powerpc: wii.dts: Add ngpios property
The Hollywood GPIO controller supports 32 GPIOs, but on the Wii, only 24 are used. Signed-off-by: Jonathan Neuschäfer --- arch/powerpc/boot/dts/wii.dts | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/powerpc/boot/dts/wii.dts b/arch/powerpc/boot/dts/wii.dts index 40b324b6391e..7235e375919c 100644 --- a/arch/powerpc/boot/dts/wii.dts +++ b/arch/powerpc/boot/dts/wii.dts @@ -176,6 +176,7 @@ compatible = "nintendo,hollywood-gpio"; reg = <0x0d8000c0 0x40>; gpio-controller; + ngpios = <24>; /* * This is commented out while a standard binding -- 2.15.1
[PATCH 1/6] resource: Extend the PPC32 reserved memory hack
On the Nintendo Wii, there are two ranges of physical memory, and MMIO
in between, but Linux on ppc32 doesn't support discontiguous memory.
Therefore a hack was introduced in commit c5df7f775148 ("powerpc: allow
ioremap within reserved memory regions") and commit de32400dd26e ("wii:
use both mem1 and mem2 as ram"):
- Treat the area from the start of the first memory area (MEM1) to the
end of the second (MEM2) as one big memory area, but mark the part
that doesn't belong to MEM1 or MEM2 as reserved.
- Only on the Wii, allow ioremap to be used on reserved memory.
This hack, however, doesn't account for the "resource"-based API in
kernel/resource.c, because __request_region performs its own checks.
Extend the hack to kernel/resource.c, to allow more drivers to allocate
their MMIO regions on the Wii.
Signed-off-by: Jonathan Neuschäfer
---
kernel/resource.c | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/kernel/resource.c b/kernel/resource.c
index 54ba6de3757c..bb3d329329da 100644
--- a/kernel/resource.c
+++ b/kernel/resource.c
@@ -1134,6 +1134,24 @@ resource_size_t resource_alignment(struct resource *res)
static DECLARE_WAIT_QUEUE_HEAD(muxed_resource_wait);
+/*
+ * On some ppc32 platforms (Nintendo Wii), reserved memory is used to work
+ * around the fact that Linux doesn't support discontiguous memory (all memory
+ * is treated as one large area with holes punched in it), and reserved memory
+ * is allowed to be allocated.
+ */
+#ifdef CONFIG_PPC32
+static bool conflict_ignored(struct resource *conflict)
+{
+ extern int __allow_ioremap_reserved;
+
+ return __allow_ioremap_reserved &&
+ (conflict->flags & IORESOURCE_SYSRAM);
+}
+#else
+static bool conflict_ignored(struct resource *conflict) { return false; }
+#endif
+
/**
* __request_region - create a new busy resource region
* @parent: parent resource descriptor
@@ -1166,8 +1184,9 @@ struct resource * __request_region(struct resource
*parent,
res->desc = parent->desc;
conflict = __request_resource(parent, res);
- if (!conflict)
+ if (!conflict || conflict_ignored(conflict))
break;
+
if (conflict != parent) {
if (!(conflict->flags & IORESOURCE_BUSY)) {
parent = conflict;
--
2.15.1
Re: [PATCH 0/8] Move most GPIO documentation to driver-api/gpio/ and ReST
On Fri, Mar 09, 2018 at 10:41:20AM -0700, Jonathan Corbet wrote: > On Fri, 9 Mar 2018 00:40:16 +0100 > Jonathan Neuschäfer wrote: > > > The aim of this patchset is to move the GPIO subsystem's documentation > > under Documentation/driver-api/gpio/ such that it is picked up by Sphinx > > and compiled into HTML. I moved everything except for sysfs.txt, because > > this file describes the legacy sysfs ABI, and doesn't seem to serve much > > (non-historical) purpose anymore. > > > > There are still some rough edges: > > > > * I think the API documentation (kernel-doc) should be moved out of > > index.rst into more appropriate files. > > * The headings are arguably wrong, because driver.rst, consumer.rst, > > etc. use the "document title" style, even though they are part of the > > GPIO chapter. But the resulting TOC tree is consistent, and I did not > > want to change almost all headings. > > * Some of the files could use more :c:func:`...` references and general > > ReST polish. > > > > But I don't want to make this patchset too large. > > [For future reference, if you're going to CC me on most of a patch series, > I'd really rather get the whole thing so I don't have to go looking for > it.] Noted. > From a quick look, it seems like a reasonable RST conversion to me. I do > wonder if sysfs.txt should just be removed, since it documents something > we don't want people to use at this point? Historical purposes are well > served by the repository history. > > I'd say changing the headings is worthwhile if it produces a better > result. I just tried this on one file (driver.rst) and it made no difference in the output (neither in the TOC in index.html nor in driver.html). Thanks, Jonathan Neuschäfer > OTOH I'd be wary of adding too much "polish"; we really want to > retain the readability of the plain-text files. > > Anyway, I'm happy to take these through the docs tree or see them go via > GPIO; Linus, what's your preference? > > Thanks, > > jon diff --git a/Documentation/driver-api/gpio/driver.rst b/Documentation/driver-api/gpio/driver.rst index 505ee906d7d9..8eb08005be55 100644 --- a/Documentation/driver-api/gpio/driver.rst +++ b/Documentation/driver-api/gpio/driver.rst @@ -1,4 +1,3 @@ - GPIO Descriptor Driver Interface @@ -13,7 +12,7 @@ the structures used to define a GPIO driver: Internal Representation of GPIOs - + Inside a GPIO driver, individual GPIOs are identified by their hardware number, which is a unique number between 0 and n, n being the number of GPIOs managed by @@ -36,7 +35,7 @@ identify GPIOs in a bank of I2C GPIO expanders. Controller Drivers: gpio_chip -= +- In the gpiolib framework each GPIO controller is packaged as a "struct gpio_chip" (see linux/gpio/driver.h for its complete definition) with members @@ -74,7 +73,7 @@ not be required. GPIO electrical configuration -- +~ GPIOs can be configured for several electrical modes of operation by using the .set_config() callback. Currently this API supports setting debouncing and @@ -95,7 +94,7 @@ numbers on the pin controller so they can properly cross-reference each other. GPIOs with debounce support +~~~ Debouncing is a configuration set to a pin indicating that it is connected to a mechanical switch or button, or similar that may bounce. Bouncing means the @@ -112,7 +111,7 @@ is not configurable. GPIOs with open drain/source support - + Open drain (CMOS) or open collector (TTL) means the line is not actively driven high: instead you provide the drain/collector as output, so when the transistor @@ -209,7 +208,7 @@ of actively driving the line low, it is set to input. GPIO drivers providing IRQs +~~~ It is custom that GPIO drivers (GPIO chips) are also providing interrupts, most often cascaded off a parent interrupt controller, and in some special cases the GPIO logic is melded with a SoC's primary interrupt controller. @@ -359,7 +358,7 @@ below exists. Locking IRQ usage -- +~ Input GPIOs can be used as IRQ signals. When this happens, a driver is requested to mark the GPIO as being used as an IRQ:: @@ -378,7 +377,7 @@ When using the gpiolib irqchip helpers, these callback are automatically assigned. Real-Time compliance fo
Re: [PATCH 0/8] Move most GPIO documentation to driver-api/gpio/ and ReST
On Sat, Mar 10, 2018 at 12:50:46PM +0100, Linus Walleij wrote:
> On Fri, Mar 9, 2018 at 12:40 AM, Jonathan Neuschäfer
> wrote:
>
> > The aim of this patchset is to move the GPIO subsystem's documentation
> > under Documentation/driver-api/gpio/ such that it is picked up by Sphinx
> > and compiled into HTML.
>
> Awesome!
>
> > I moved everything except for sysfs.txt, because
> > this file describes the legacy sysfs ABI, and doesn't seem to serve much
> > (non-historical) purpose anymore.
> >
> > There are still some rough edges:
> >
> > * I think the API documentation (kernel-doc) should be moved out of
> > index.rst into more appropriate files.
> > * The headings are arguably wrong, because driver.rst, consumer.rst,
> > etc. use the "document title" style, even though they are part of the
> > GPIO chapter. But the resulting TOC tree is consistent, and I did not
> > want to change almost all headings.
> > * Some of the files could use more :c:func:`...` references and general
> > ReST polish.
> >
> > But I don't want to make this patchset too large.
>
> It's fine, we take it one step at a time.
>
> On Fri, Mar 09, 2018 at 10:41:20AM -0700, Jonathan Corbet wrote:
>
> > Anyway, I'm happy to take these through the docs tree or see them go via
> > GPIO; Linus, what's your preference?
>
> I might have some doc patches that could collide so I can take them.
>
> I take it there will be a v2?
Not necessarily, but if I need to rebase on a different branch, or on
future linux-next, I'll do that. (Or if some other issue is found.)
I thought that patch 8/8 currently requires commit 93db446a424c ("mtd:
nand: move raw NAND related code to the raw/ subdir"), which is in next
through Boris Brezillon's nand tree, but this isn't true. The patchset
(currently) applies to both v4.16-rc4 and next, AFAICS.
Thanks,
Jonathan Neuschäfer
signature.asc
Description: PGP signature
Re: [PATCH 0/8] Move most GPIO documentation to driver-api/gpio/ and ReST
On Fri, Mar 23, 2018 at 04:23:21AM +0100, Linus Walleij wrote: > On Fri, Mar 9, 2018 at 12:40 AM, Jonathan Neuschäfer > wrote: > > > Jonathan Neuschäfer (8): > > MAINTAINERS: GPIO: Add Documentation/driver-api/gpio/ > > Documentation: driver-api: Move gpio.rst to gpio/index.rst > > Documentation: gpio: Move introduction to driver-api > > Documentation: gpio: Move driver documentation to driver-api > > Documentation: gpio: Move legacy documentation to driver-api > > Documentation: gpio: Move gpiod_* consumer documentation to driver-api > > Documentation: gpio: Move GPIO mapping documentation to driver-api > > Documentation: gpio: Move drivers-on-gpio.txt to driver-api > > I applied all 8 patches to devel for v4.17. Thanks! Jonathan Neuschäfer signature.asc Description: PGP signature
[PATCH 0/8] Move most GPIO documentation to driver-api/gpio/ and ReST
The aim of this patchset is to move the GPIO subsystem's documentation
under Documentation/driver-api/gpio/ such that it is picked up by Sphinx
and compiled into HTML. I moved everything except for sysfs.txt, because
this file describes the legacy sysfs ABI, and doesn't seem to serve much
(non-historical) purpose anymore.
There are still some rough edges:
* I think the API documentation (kernel-doc) should be moved out of
index.rst into more appropriate files.
* The headings are arguably wrong, because driver.rst, consumer.rst,
etc. use the "document title" style, even though they are part of the
GPIO chapter. But the resulting TOC tree is consistent, and I did not
want to change almost all headings.
* Some of the files could use more :c:func:`...` references and general
ReST polish.
But I don't want to make this patchset too large.
Jonathan Neuschäfer (8):
MAINTAINERS: GPIO: Add Documentation/driver-api/gpio/
Documentation: driver-api: Move gpio.rst to gpio/index.rst
Documentation: gpio: Move introduction to driver-api
Documentation: gpio: Move driver documentation to driver-api
Documentation: gpio: Move legacy documentation to driver-api
Documentation: gpio: Move gpiod_* consumer documentation to driver-api
Documentation: gpio: Move GPIO mapping documentation to driver-api
Documentation: gpio: Move drivers-on-gpio.txt to driver-api
.../{gpio/board.txt => driver-api/gpio/board.rst} | 39 +-
.../consumer.txt => driver-api/gpio/consumer.rst} | 85 +++---
.../driver.txt => driver-api/gpio/driver.rst} | 80 ++--
.../gpio/drivers-on-gpio.rst} | 1 +
.../driver-api/{gpio.rst => gpio/index.rst}| 21 +++---
.../{gpio/gpio.txt => driver-api/gpio/intro.rst} | 9 ++-
.../gpio-legacy.txt => driver-api/gpio/legacy.rst} | 68 ++---
Documentation/driver-api/index.rst | 2 +-
Documentation/gpio/00-INDEX| 13
Documentation/gpio/sysfs.txt | 5 +-
MAINTAINERS| 1 +
11 files changed, 169 insertions(+), 155 deletions(-)
rename Documentation/{gpio/board.txt => driver-api/gpio/board.rst} (88%)
rename Documentation/{gpio/consumer.txt => driver-api/gpio/consumer.rst} (89%)
rename Documentation/{gpio/driver.txt => driver-api/gpio/driver.rst} (93%)
rename Documentation/{gpio/drivers-on-gpio.txt =>
driver-api/gpio/drivers-on-gpio.rst} (99%)
rename Documentation/driver-api/{gpio.rst => gpio/index.rst} (74%)
rename Documentation/{gpio/gpio.txt => driver-api/gpio/intro.rst} (96%)
rename Documentation/{gpio/gpio-legacy.txt => driver-api/gpio/legacy.rst} (96%)
--
2.16.1
[PATCH 5/8] Documentation: gpio: Move legacy documentation to driver-api
Move gpio/gpio-legacy.txt to driver-api/gpio/legacy.rst and make sure it
builds cleanly as ReST.
Also move the legacy API reference from index.rst to legacy.rst.
Signed-off-by: Jonathan Neuschäfer
---
Documentation/driver-api/gpio/index.rst| 10 +---
.../gpio-legacy.txt => driver-api/gpio/legacy.rst} | 68 +-
Documentation/gpio/00-INDEX| 2 -
3 files changed, 41 insertions(+), 39 deletions(-)
rename Documentation/{gpio/gpio-legacy.txt => driver-api/gpio/legacy.rst} (96%)
diff --git a/Documentation/driver-api/gpio/index.rst
b/Documentation/driver-api/gpio/index.rst
index e1fbc5408cf6..fd22c0d1419e 100644
--- a/Documentation/driver-api/gpio/index.rst
+++ b/Documentation/driver-api/gpio/index.rst
@@ -9,6 +9,7 @@ Contents:
intro
driver
+ legacy
Core
@@ -19,15 +20,6 @@ Core
.. kernel-doc:: drivers/gpio/gpiolib.c
:export:
-Legacy API
-==
-
-The functions listed in this section are deprecated. The GPIO descriptor based
-API described above should be used in new code.
-
-.. kernel-doc:: drivers/gpio/gpiolib-legacy.c
- :export:
-
ACPI support
diff --git a/Documentation/gpio/gpio-legacy.txt
b/Documentation/driver-api/gpio/legacy.rst
similarity index 96%
rename from Documentation/gpio/gpio-legacy.txt
rename to Documentation/driver-api/gpio/legacy.rst
index 8356d0e78f67..5e9421e05f1d 100644
--- a/Documentation/gpio/gpio-legacy.txt
+++ b/Documentation/driver-api/gpio/legacy.rst
@@ -1,4 +1,6 @@
-GPIO Interfaces
+==
+Legacy GPIO Interfaces
+==
This provides an overview of GPIO access conventions on Linux.
@@ -129,7 +131,7 @@ The first thing a system should do with a GPIO is allocate
it, using
the gpio_request() call; see later.
One of the next things to do with a GPIO, often in board setup code when
-setting up a platform_device using the GPIO, is mark its direction:
+setting up a platform_device using the GPIO, is mark its direction::
/* set as input or output, returning 0 or negative errno */
int gpio_direction_input(unsigned gpio);
@@ -164,7 +166,7 @@ Those don't need to sleep, and can safely be done from
inside hard
(nonthreaded) IRQ handlers and similar contexts.
Use the following calls to access such GPIOs,
-for which gpio_cansleep() will always return false (see below):
+for which gpio_cansleep() will always return false (see below)::
/* GPIO INPUT: return zero or nonzero */
int gpio_get_value(unsigned gpio);
@@ -201,11 +203,11 @@ This requires sleeping, which can't be done from inside
IRQ handlers.
Platforms that support this type of GPIO distinguish them from other GPIOs
by returning nonzero from this call (which requires a valid GPIO number,
-which should have been previously allocated with gpio_request):
+which should have been previously allocated with gpio_request)::
int gpio_cansleep(unsigned gpio);
-To access such GPIOs, a different set of accessors is defined:
+To access such GPIOs, a different set of accessors is defined::
/* GPIO INPUT: return zero or nonzero, might sleep */
int gpio_get_value_cansleep(unsigned gpio);
@@ -222,27 +224,27 @@ Other than the fact that these accessors might sleep, and
will work
on GPIOs that can't be accessed from hardIRQ handlers, these calls act
the same as the spinlock-safe calls.
- ** IN ADDITION ** calls to setup and configure such GPIOs must be made
+**IN ADDITION** calls to setup and configure such GPIOs must be made
from contexts which may sleep, since they may need to access the GPIO
-controller chip too: (These setup calls are usually made from board
-setup or driver probe/teardown code, so this is an easy constraint.)
+controller chip too (These setup calls are usually made from board
+setup or driver probe/teardown code, so this is an easy constraint.)::
- gpio_direction_input()
- gpio_direction_output()
- gpio_request()
+gpio_direction_input()
+gpio_direction_output()
+gpio_request()
-## gpio_request_one()
-## gpio_request_array()
-## gpio_free_array()
+## gpio_request_one()
+## gpio_request_array()
+## gpio_free_array()
- gpio_free()
- gpio_set_debounce()
+gpio_free()
+gpio_set_debounce()
Claiming and Releasing GPIOs
-To help catch system configuration errors, two calls are defined.
+To help catch system configuration errors, two calls are defined::
/* request GPIO, returning 0 or negative errno.
* non-null labels may be useful for diagnostics.
@@ -296,7 +298,7 @@ Also note that it's your responsibility to have stopped
using a GPIO
before you free it.
Considering in most cases GPIOs are actually configured right after they
-are claimed, three additional calls
[PATCH 1/8] MAINTAINERS: GPIO: Add Documentation/driver-api/gpio/
Steer patches to Documentation/driver-api/gpio/ into the right direction. Signed-off-by: Jonathan Neuschäfer --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index d6a89d31e4a4..313c0907020c 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -6029,6 +6029,7 @@ L:linux-g...@vger.kernel.org T: git git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git S: Maintained F: Documentation/devicetree/bindings/gpio/ +F: Documentation/driver-api/gpio/ F: Documentation/gpio/ F: Documentation/ABI/testing/gpio-cdev F: Documentation/ABI/obsolete/sysfs-gpio -- 2.16.1
[PATCH 2/8] Documentation: driver-api: Move gpio.rst to gpio/index.rst
To make space for more files in the GPIO section, create a
Documentation/driver-api/gpio/ directory.
Signed-off-by: Jonathan Neuschäfer
---
Documentation/driver-api/{gpio.rst => gpio/index.rst} | 0
Documentation/driver-api/index.rst| 2 +-
2 files changed, 1 insertion(+), 1 deletion(-)
rename Documentation/driver-api/{gpio.rst => gpio/index.rst} (100%)
diff --git a/Documentation/driver-api/gpio.rst
b/Documentation/driver-api/gpio/index.rst
similarity index 100%
rename from Documentation/driver-api/gpio.rst
rename to Documentation/driver-api/gpio/index.rst
diff --git a/Documentation/driver-api/index.rst
b/Documentation/driver-api/index.rst
index 62d056471c0d..9b54fb99d9ca 100644
--- a/Documentation/driver-api/index.rst
+++ b/Documentation/driver-api/index.rst
@@ -45,7 +45,7 @@ available subsections can be seen below.
uio-howto
firmware/index
pinctl
- gpio
+ gpio/index
misc_devices
dmaengine/index
slimbus
--
2.16.1
[PATCH 8/8] Documentation: gpio: Move drivers-on-gpio.txt to driver-api
Move gpio/drivers-on-gpio.txt to driver-api/gpio/drivers-on-gpio.rst and
make sure it builds cleanly as ReST.
Signed-off-by: Jonathan Neuschäfer
---
This patch applies cleanly on top of 93db446a424c ("mtd: nand: move raw
NAND related code to the raw/ subdir")
---
.../drivers-on-gpio.txt => driver-api/gpio/drivers-on-gpio.rst} | 1 +
Documentation/driver-api/gpio/index.rst | 1 +
Documentation/gpio/00-INDEX | 3 ---
Documentation/gpio/sysfs.txt | 5 ++---
4 files changed, 4 insertions(+), 6 deletions(-)
rename Documentation/{gpio/drivers-on-gpio.txt =>
driver-api/gpio/drivers-on-gpio.rst} (99%)
diff --git a/Documentation/gpio/drivers-on-gpio.txt
b/Documentation/driver-api/gpio/drivers-on-gpio.rst
similarity index 99%
rename from Documentation/gpio/drivers-on-gpio.txt
rename to Documentation/driver-api/gpio/drivers-on-gpio.rst
index a3e612f55bc7..7da0c1dd1f7a 100644
--- a/Documentation/gpio/drivers-on-gpio.txt
+++ b/Documentation/driver-api/gpio/drivers-on-gpio.rst
@@ -1,3 +1,4 @@
+
Subsystem drivers using GPIO
diff --git a/Documentation/driver-api/gpio/index.rst
b/Documentation/driver-api/gpio/index.rst
index 2b73ea5a1fbb..6a374ded1287 100644
--- a/Documentation/driver-api/gpio/index.rst
+++ b/Documentation/driver-api/gpio/index.rst
@@ -11,6 +11,7 @@ Contents:
driver
consumer
board
+ drivers-on-gpio
legacy
Core
diff --git a/Documentation/gpio/00-INDEX b/Documentation/gpio/00-INDEX
index 650cb0696211..17e19a68058f 100644
--- a/Documentation/gpio/00-INDEX
+++ b/Documentation/gpio/00-INDEX
@@ -1,7 +1,4 @@
00-INDEX
- This file
-drivers-on-gpio.txt:
- - Drivers in other subsystems that can use GPIO to provide more
- complex functionality.
sysfs.txt
- Information about the GPIO sysfs interface
diff --git a/Documentation/gpio/sysfs.txt b/Documentation/gpio/sysfs.txt
index 6cdeab8650cd..58eeab81f349 100644
--- a/Documentation/gpio/sysfs.txt
+++ b/Documentation/gpio/sysfs.txt
@@ -32,9 +32,8 @@ standard kernels won't know about. And for some tasks, simple
userspace
GPIO drivers could be all that the system really needs.
DO NOT ABUSE SYSFS TO CONTROL HARDWARE THAT HAS PROPER KERNEL DRIVERS.
-PLEASE READ THE DOCUMENT NAMED "drivers-on-gpio.txt" IN THIS DOCUMENTATION
-DIRECTORY TO AVOID REINVENTING KERNEL WHEELS IN USERSPACE. I MEAN IT.
-REALLY.
+PLEASE READ THE DOCUMENT AT Documentation/driver-api/gpio/drivers-on-gpio.rst
+TO AVOID REINVENTING KERNEL WHEELS IN USERSPACE. I MEAN IT. REALLY.
Paths in Sysfs
--
--
2.16.1
[PATCH 7/8] Documentation: gpio: Move GPIO mapping documentation to driver-api
Move gpio/board.txt to driver-api/gpio/board.rst and make sure it builds
cleanly as ReST.
Signed-off-by: Jonathan Neuschäfer
---
.../{gpio/board.txt => driver-api/gpio/board.rst} | 39 --
Documentation/driver-api/gpio/index.rst| 1 +
Documentation/gpio/00-INDEX| 2 --
3 files changed, 22 insertions(+), 20 deletions(-)
rename Documentation/{gpio/board.txt => driver-api/gpio/board.rst} (88%)
diff --git a/Documentation/gpio/board.txt
b/Documentation/driver-api/gpio/board.rst
similarity index 88%
rename from Documentation/gpio/board.txt
rename to Documentation/driver-api/gpio/board.rst
index 659bb19f5b3c..25d62b2e9fd0 100644
--- a/Documentation/gpio/board.txt
+++ b/Documentation/driver-api/gpio/board.rst
@@ -1,3 +1,4 @@
+=
GPIO Mappings
=
@@ -23,7 +24,7 @@ device tree bindings for your controller.
GPIOs mappings are defined in the consumer device's node, in a property named
-gpios, where is the function the driver will request
-through gpiod_get(). For example:
+through gpiod_get(). For example::
foo_device {
compatible = "acme,foo";
@@ -40,7 +41,7 @@ it but are only supported for compatibility reasons and
should not be used for
newer bindings since it has been deprecated.
This property will make GPIOs 15, 16 and 17 available to the driver under the
-"led" function, and GPIO 1 as the "power" GPIO:
+"led" function, and GPIO 1 as the "power" GPIO::
struct gpio_desc *red, *green, *blue, *power;
@@ -60,13 +61,13 @@ looked up by the gpiod functions internally) used in the
device tree. With above
Internally, the GPIO subsystem prefixes the GPIO suffix ("gpios" or "gpio")
with the string passed in con_id to get the resulting string
-(snprintf(... "%s-%s", con_id, gpio_suffixes[]).
+(``snprintf(... "%s-%s", con_id, gpio_suffixes[]``).
ACPI
ACPI also supports function names for GPIOs in a similar fashion to DT.
The above DT example can be converted to an equivalent ACPI description
-with the help of _DSD (Device Specific Data), introduced in ACPI 5.1:
+with the help of _DSD (Device Specific Data), introduced in ACPI 5.1::
Device (FOO) {
Name (_CRS, ResourceTemplate () {
@@ -105,12 +106,12 @@ Documentation/acpi/gpio-properties.txt.
Platform Data
-
Finally, GPIOs can be bound to devices and functions using platform data. Board
-files that desire to do so need to include the following header:
+files that desire to do so need to include the following header::
#include
GPIOs are mapped by the means of tables of lookups, containing instances of the
-gpiod_lookup structure. Two macros are defined to help declaring such mappings:
+gpiod_lookup structure. Two macros are defined to help declaring such
mappings::
GPIO_LOOKUP(chip_label, chip_hwnum, con_id, flags)
GPIO_LOOKUP_IDX(chip_label, chip_hwnum, con_id, idx, flags)
@@ -141,22 +142,24 @@ end. The 'dev_id' field of the table is the identifier of
the device that will
make use of these GPIOs. It can be NULL, in which case it will be matched for
calls to gpiod_get() with a NULL device.
-struct gpiod_lookup_table gpios_table = {
- .dev_id = "foo.0",
- .table = {
- GPIO_LOOKUP_IDX("gpio.0", 15, "led", 0, GPIO_ACTIVE_HIGH),
- GPIO_LOOKUP_IDX("gpio.0", 16, "led", 1, GPIO_ACTIVE_HIGH),
- GPIO_LOOKUP_IDX("gpio.0", 17, "led", 2, GPIO_ACTIVE_HIGH),
- GPIO_LOOKUP("gpio.0", 1, "power", GPIO_ACTIVE_LOW),
- { },
- },
-};
+.. code-block:: c
+
+struct gpiod_lookup_table gpios_table = {
+.dev_id = "foo.0",
+.table = {
+GPIO_LOOKUP_IDX("gpio.0", 15, "led", 0,
GPIO_ACTIVE_HIGH),
+GPIO_LOOKUP_IDX("gpio.0", 16, "led", 1,
GPIO_ACTIVE_HIGH),
+GPIO_LOOKUP_IDX("gpio.0", 17, "led", 2,
GPIO_ACTIVE_HIGH),
+GPIO_LOOKUP("gpio.0", 1, "power", GPIO_ACTIVE_LOW),
+{ },
+},
+};
-And the table can be added by the board code as follows:
+And the table can be added by the board code as follows::
gpiod_add_lookup_table(&gpios_table);
-The driver controlling "foo.0" will then be able to obtain its GPIOs as
follows:
+The driver controlling "foo.0" will then be able to obtain its GPIOs as
follows::
struct gpio_desc *red, *green, *blue, *power;
diff --git a/Documentation/driver-api/gpio/index.rst
b/Documentation/driver-api/gpio/index.rst
index 6ba9e0043310..2b73ea5a1fbb 10064
[PATCH 3/8] Documentation: gpio: Move introduction to driver-api
Move gpio/intro.txt to driver-api/gpio/intro.rst and make sure it builds
cleanly as ReST.
Signed-off-by: Jonathan Neuschäfer
---
Documentation/driver-api/gpio/index.rst| 7 +++
Documentation/{gpio/gpio.txt => driver-api/gpio/intro.rst} | 9 +++--
Documentation/gpio/00-INDEX| 2 --
3 files changed, 14 insertions(+), 4 deletions(-)
rename Documentation/{gpio/gpio.txt => driver-api/gpio/intro.rst} (96%)
diff --git a/Documentation/driver-api/gpio/index.rst
b/Documentation/driver-api/gpio/index.rst
index 6dd4aa647f27..db47d845f473 100644
--- a/Documentation/driver-api/gpio/index.rst
+++ b/Documentation/driver-api/gpio/index.rst
@@ -2,6 +2,13 @@
General Purpose Input/Output (GPIO)
===
+Contents:
+
+.. toctree::
+ :maxdepth: 2
+
+ intro
+
Core
diff --git a/Documentation/gpio/gpio.txt
b/Documentation/driver-api/gpio/intro.rst
similarity index 96%
rename from Documentation/gpio/gpio.txt
rename to Documentation/driver-api/gpio/intro.rst
index cd9b356e88cd..74591489d0b5 100644
--- a/Documentation/gpio/gpio.txt
+++ b/Documentation/driver-api/gpio/intro.rst
@@ -1,3 +1,8 @@
+
+Introduction
+
+
+
GPIO Interfaces
===
@@ -9,9 +14,9 @@ Due to the history of GPIO interfaces in the kernel, there are
two different
ways to obtain and use GPIOs:
- The descriptor-based interface is the preferred way to manipulate GPIOs,
-and is described by all the files in this directory excepted gpio-legacy.txt.
+and is described by all the files in this directory excepted
gpio-legacy.txt.
- The legacy integer-based interface which is considered deprecated (but
still
-usable for compatibility reasons) is documented in gpio-legacy.txt.
+usable for compatibility reasons) is documented in gpio-legacy.txt.
The remainder of this document applies to the new descriptor-based interface.
gpio-legacy.txt contains the same information applied to the legacy
diff --git a/Documentation/gpio/00-INDEX b/Documentation/gpio/00-INDEX
index 179beb234f98..52fe0fa6c964 100644
--- a/Documentation/gpio/00-INDEX
+++ b/Documentation/gpio/00-INDEX
@@ -1,7 +1,5 @@
00-INDEX
- This file
-gpio.txt
- - Introduction to GPIOs and their kernel interfaces
consumer.txt
- How to obtain and use GPIOs in a driver
driver.txt
--
2.16.1
[PATCH 6/8] Documentation: gpio: Move gpiod_* consumer documentation to driver-api
Move gpio/consumer.txt to driver-api/gpio/consumer.rst and make sure it
builds cleanly as ReST.
Signed-off-by: Jonathan Neuschäfer
---
.../consumer.txt => driver-api/gpio/consumer.rst} | 85 +++---
Documentation/driver-api/gpio/index.rst| 1 +
Documentation/gpio/00-INDEX| 2 -
3 files changed, 44 insertions(+), 44 deletions(-)
rename Documentation/{gpio/consumer.txt => driver-api/gpio/consumer.rst} (89%)
diff --git a/Documentation/gpio/consumer.txt
b/Documentation/driver-api/gpio/consumer.rst
similarity index 89%
rename from Documentation/gpio/consumer.txt
rename to Documentation/driver-api/gpio/consumer.rst
index d53e5b5cfc9c..c71a50d85b50 100644
--- a/Documentation/gpio/consumer.txt
+++ b/Documentation/driver-api/gpio/consumer.rst
@@ -1,3 +1,4 @@
+==
GPIO Descriptor Consumer Interface
==
@@ -30,10 +31,10 @@ warnings. These stubs are used for two use cases:
be met with console warnings that may be perceived as intimidating.
All the functions that work with the descriptor-based GPIO interface are
-prefixed with gpiod_. The gpio_ prefix is used for the legacy interface. No
-other function in the kernel should use these prefixes. The use of the legacy
-functions is strongly discouraged, new code should use
-and descriptors exclusively.
+prefixed with ``gpiod_``. The ``gpio_`` prefix is used for the legacy
+interface. No other function in the kernel should use these prefixes. The use
+of the legacy functions is strongly discouraged, new code should use
+ and descriptors exclusively.
Obtaining and Disposing GPIOs
@@ -43,13 +44,13 @@ With the descriptor-based interface, GPIOs are identified
with an opaque,
non-forgeable handler that must be obtained through a call to one of the
gpiod_get() functions. Like many other kernel subsystems, gpiod_get() takes the
device that will use the GPIO and the function the requested GPIO is supposed
to
-fulfill:
+fulfill::
struct gpio_desc *gpiod_get(struct device *dev, const char *con_id,
enum gpiod_flags flags)
If a function is implemented by using several GPIOs together (e.g. a simple LED
-device that displays digits), an additional index argument can be specified:
+device that displays digits), an additional index argument can be specified::
struct gpio_desc *gpiod_get_index(struct device *dev,
const char *con_id, unsigned int idx,
@@ -84,7 +85,7 @@ occurred while trying to acquire it. This is useful to
discriminate between mere
errors and an absence of GPIO for optional GPIO parameters. For the common
pattern where a GPIO is optional, the gpiod_get_optional() and
gpiod_get_index_optional() functions can be used. These functions return NULL
-instead of -ENOENT if no GPIO has been assigned to the requested function:
+instead of -ENOENT if no GPIO has been assigned to the requested function::
struct gpio_desc *gpiod_get_optional(struct device *dev,
const char *con_id,
@@ -101,14 +102,14 @@ This is helpful to driver authors, since they do not need
to special case
-ENOSYS return codes. System integrators should however be careful to enable
gpiolib on systems that need it.
-For a function using multiple GPIOs all of those can be obtained with one call:
+For a function using multiple GPIOs all of those can be obtained with one
call::
struct gpio_descs *gpiod_get_array(struct device *dev,
const char *con_id,
enum gpiod_flags flags)
This function returns a struct gpio_descs which contains an array of
-descriptors:
+descriptors::
struct gpio_descs {
unsigned int ndescs;
@@ -116,13 +117,13 @@ descriptors:
}
The following function returns NULL instead of -ENOENT if no GPIOs have been
-assigned to the requested function:
+assigned to the requested function::
struct gpio_descs *gpiod_get_array_optional(struct device *dev,
const char *con_id,
enum gpiod_flags flags)
-Device-managed variants of these functions are also defined:
+Device-managed variants of these functions are also defined::
struct gpio_desc *devm_gpiod_get(struct device *dev, const char *con_id,
enum gpiod_flags flags)
@@ -149,11 +150,11 @@ Device-managed variants of these functions are also
defined:
const char *con_id,
enum gpiod_flags flags)
-A GPIO descriptor can be disposed of using the gpiod_put() function:
+A GPIO descriptor can be disposed of using the gpiod_put() function::
[PATCH 4/8] Documentation: gpio: Move driver documentation to driver-api
Move gpio/driver.txt to driver-api/gpio/driver.rst and make sure it
builds cleanly as ReST.
Signed-off-by: Jonathan Neuschäfer
---
.../driver.txt => driver-api/gpio/driver.rst} | 80 +++---
Documentation/driver-api/gpio/index.rst| 1 +
Documentation/gpio/00-INDEX| 2 -
3 files changed, 42 insertions(+), 41 deletions(-)
rename Documentation/{gpio/driver.txt => driver-api/gpio/driver.rst} (93%)
diff --git a/Documentation/gpio/driver.txt
b/Documentation/driver-api/gpio/driver.rst
similarity index 93%
rename from Documentation/gpio/driver.txt
rename to Documentation/driver-api/gpio/driver.rst
index 3392a0fd4c23..505ee906d7d9 100644
--- a/Documentation/gpio/driver.txt
+++ b/Documentation/driver-api/gpio/driver.rst
@@ -1,3 +1,4 @@
+
GPIO Descriptor Driver Interface
@@ -53,9 +54,9 @@ common to each controller of that type:
The code implementing a gpio_chip should support multiple instances of the
controller, possibly using the driver model. That code will configure each
-gpio_chip and issue gpiochip_add[_data]() or devm_gpiochip_add_data().
-Removing a GPIO controller should be rare; use [devm_]gpiochip_remove() when
-it is unavoidable.
+gpio_chip and issue ``gpiochip_add[_data]()`` or ``devm_gpiochip_add_data()``.
+Removing a GPIO controller should be rare; use ``[devm_]gpiochip_remove()``
+when it is unavoidable.
Often a gpio_chip is part of an instance-specific structure with states not
exposed by the GPIO interfaces, such as addressing, power management, and more.
@@ -115,7 +116,7 @@ GPIOs with open drain/source support
Open drain (CMOS) or open collector (TTL) means the line is not actively driven
high: instead you provide the drain/collector as output, so when the transistor
-is not open, it will present a high-impedance (tristate) to the external rail.
+is not open, it will present a high-impedance (tristate) to the external rail::
CMOS CONFIGURATION TTL CONFIGURATION
@@ -148,19 +149,19 @@ level-shift to the higher VDD.
Integrated electronics often have an output driver stage in the form of a CMOS
"totem-pole" with one N-MOS and one P-MOS transistor where one of them drives
the line high and one of them drives the line low. This is called a push-pull
-output. The "totem-pole" looks like so:
-
- VDD
- |
-OD||--+
- +--/ ---o|| P-MOS-FET
- |||--+
-IN --++- out
- |||--+
- +--/ || N-MOS-FET
-OS||--+
- |
- GND
+output. The "totem-pole" looks like so::
+
+ VDD
+ |
+OD||--+
+ +--/ ---o|| P-MOS-FET
+ |||--+
+IN --++- out
+ |||--+
+ +--/ || N-MOS-FET
+OS||--+
+ |
+ GND
The desired output signal (e.g. coming directly from some GPIO output register)
arrives at IN. The switches named "OD" and "OS" are normally closed, creating
@@ -219,8 +220,9 @@ systems simultaneously: gpio and irq.
RT_FULL: a realtime compliant GPIO driver should not use spinlock_t or any
sleepable APIs (like PM runtime) as part of its irq_chip implementation.
-- spinlock_t should be replaced with raw_spinlock_t [1].
-- If sleepable APIs have to be used, these can be done from the .irq_bus_lock()
+
+* spinlock_t should be replaced with raw_spinlock_t [1].
+* If sleepable APIs have to be used, these can be done from the .irq_bus_lock()
and .irq_bus_unlock() callbacks, as these are the only slowpath callbacks
on an irqchip. Create the callbacks if needed [2].
@@ -232,12 +234,12 @@ GPIO irqchips usually fall in one of two categories:
system interrupt controller. This means that the GPIO irqchip handler will
be called immediately from the parent irqchip, while holding the IRQs
disabled. The GPIO irqchip will then end up calling something like this
- sequence in its interrupt handler:
+ sequence in its interrupt handler::
- static irqreturn_t foo_gpio_irq(int irq, void *data)
- chained_irq_enter(...);
- generic_handle_irq(...);
- chained_irq_exit(...);
+static irqreturn_t foo_gpio_irq(int irq, void *data)
+chained_irq_enter(...);
+generic_handle_irq(...);
+chained_irq_exit(...);
Chained GPIO irqchips typically can NOT set the .can_sleep flag on
struct gpio_chip, as everything happens directly in the callbacks: no
@@ -252,7 +254,7 @@ GPIO irqchips usually fall in one of two categories:
(for example, see [3]).
Know W/A: The generic_handle_irq() is expected to be called with IRQ
disabled,
so the IRQ core will complain if it is called from an IRQ handler which is
- forced to a thread. The "fake?" raw lock
[PATCH] genirq: Fix editing error in a comment
When the comment was reflowed to a wider format, the "*" snuck in.
Fixes: ae88a23b32fa ("irq: refactor and clean up the free_irq() code flow")
Signed-off-by: Jonathan Neuschäfer
---
kernel/irq/manage.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
index daeabd791d58..591cfe901162 100644
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -1638,7 +1638,7 @@ static struct irqaction *__free_irq(struct irq_desc
*desc, void *dev_id)
* is so by doing an extra call to the handler
*
* ( We do this after actually deregistering it, to make sure that a
-* 'real' IRQ doesn't run in * parallel with our fake. )
+* 'real' IRQ doesn't run in parallel with our fake. )
*/
if (action->flags & IRQF_SHARED) {
local_irq_save(flags);
--
2.17.1
Re: [PATCH v1 03/13] powerpc/mm/32s: rework mmu_mapin_ram()
On Mon, Dec 17, 2018 at 10:29:18AM +0100, Christophe Leroy wrote: > > With patches 1-3: > > [0.00] setbat(0, c000, , 0100, 311) > > [0.00] setbat(2, c100, 0100, 0080, 311) > > [0.00] setbat(4, d000, 1000, 0200, 791) > > What we see is that BAT0 is not used in the origin. I have always wondered > the reason, maybe there is something odd behind and BAT0 shall no ne used. > > Could you try and modify find_free_bat() so that it starts at b = 1 instead > of b = 0 ? In this case, setbat is called with index 2, 3, and 4, but the Wii still doesn't boot. > > According to arch/powerpc/include/asm/book3s/32/hash.h, > > - 0x591 = _PAGE_RW | _PAGE_ACCESSED | _PAGE_DIRTY | _PAGE_COHERENT | > > _PAGE_PRESENT > > - 0x311 = _PAGE_EXEC | _PAGE_ACCESSED | _PAGE_COHERENT | _PAGE_PRESENT > > - 0x791 = _PAGE_RW | _PAGE_EXEC | _PAGE_ACCESSED | _PAGE_DIRTY | > > _PAGE_COHERENT | _PAGE_PRESENT > > > > Yes, patch 1 added _PAGE_EXEC which explains this 0x200. > Do you confirm it still works well with only patch 1 ? Patch 1 alone boots to userspace. Jonathan signature.asc Description: PGP signature
Re: [PATCH v1 03/13] powerpc/mm/32s: rework mmu_mapin_ram()
On Tue, Dec 18, 2018 at 09:18:42AM +, Christophe Leroy wrote: > The only difference I see then are the flags. Everything else is seems > identical. > > I know you tried already, but would you mind trying once more with the > following change ? > [...] > - setbat(idx, PAGE_OFFSET + base, base, size, PAGE_KERNEL_TEXT); > + setbat(idx, PAGE_OFFSET + base, base, size, PAGE_KERNEL_X); Good call, with this workaround on top of patches 1-3, it boots again: # mount -t debugfs d /sys/kernel/debug # cat /sys/kernel/debug/powerpc/block_address_translation ---[ Instruction Block Address Translation ]--- 0: 0xc000-0xc0ff 0x Kernel EXEC 1: - 2: 0xc100-0xc17f 0x0100 Kernel EXEC 3: - 4: 0xd000-0xd1ff 0x1000 Kernel EXEC 5: - 6: - 7: - ---[ Data Block Address Translation ]--- 0: 0xc000-0xc0ff 0x Kernel RW 1: 0xfffe-0x 0x0d00 Kernel RW no cache guarded 2: 0xc100-0xc17f 0x0100 Kernel RW 3: - 4: 0xd000-0xd1ff 0x1000 Kernel RW 5: - 6: - 7: - > I think we may have some code trying to modify the kernel text without using > code patching functions. Is there any faster way than to sprinkle some printks in setup_kernel and try to find the guilty piece of code this way? Jonathan signature.asc Description: PGP signature
Re: [PATCH v1 03/13] powerpc/mm/32s: rework mmu_mapin_ram()
On Tue, Dec 18, 2018 at 04:04:42PM +0100, Christophe Leroy wrote: > Stupid of me. In fact at the time being, BATS cover both RO and RW data > areas, so it can definitly not be mapped with PAGE_KERNEL_ROX. > > In fact, as I have CONFIG_BDI_SWITCH in my setup, PAGE_KERNEL_TEXT is > PAGE_KERNEL_X on my side. That's the reason why I missed it. > > With this change being done to patch 3, does the overall serie works for you ? Yes, with the PAGE_KERNEL_X change, the whole series boots on the Wii. Jonathan signature.asc Description: PGP signature
Re: [PATCH v1 03/13] powerpc/mm/32s: rework mmu_mapin_ram()
_mmu_32.c
+++ b/arch/powerpc/mm/ppc_mmu_32.c
@@ -120,6 +120,9 @@ void __init setbat(int index, unsigned long virt,
phys_addr_t phys,
struct ppc_bat *bat = BATS[index];
unsigned long flags = pgprot_val(prot);
+ pr_info("setbat(%u, %px, %px, %px, %lx)\n",
+ index, (void *)virt, (void *)phys, (void *)size, flags);
+
if ((flags & _PAGE_NO_CACHE) ||
(cpu_has_feature(CPU_FTR_NEED_COHERENT) == 0))
flags &= ~_PAGE_COHERENT;
And here's what I got:
Before your patches (circa v4.20-rc5):
[0.00] setbat(2, c000, , 0100, 591)
[0.00] setbat(3, c100, 0100, 0080, 591)
[0.00] setbat(4, d000, 1000, 0200, 591)
With patches 1-3:
[0.00] setbat(0, c000, , 0100, 311)
[0.00] setbat(2, c100, 0100, 0080, 311)
[0.00] setbat(4, d000, 1000, 0200, 791)
According to arch/powerpc/include/asm/book3s/32/hash.h,
- 0x591 = _PAGE_RW | _PAGE_ACCESSED | _PAGE_DIRTY | _PAGE_COHERENT |
_PAGE_PRESENT
- 0x311 = _PAGE_EXEC | _PAGE_ACCESSED | _PAGE_COHERENT | _PAGE_PRESENT
- 0x791 = _PAGE_RW | _PAGE_EXEC | _PAGE_ACCESSED | _PAGE_DIRTY |
_PAGE_COHERENT | _PAGE_PRESENT
Changing the flags back to 0x591 in setbat doesn't result in a booting
system.
> > > I've tested at patch 1, 2, 3, 4, and 13, so I don't know if it works
> > > somewhere in the middle, but probably not.
(I get the same results if I also merge powerpc/next, btw)
I hope this helps somewhat,
Jonathan Neuschäfer
[0.00] printk: bootconsole [udbg0] enabled
[0.00] Total memory = 319MB; using 1024kB for hash table (at (ptrval))
[0.00] Linux version 4.20.0-rc5-wii-00021-g15eb67569a3d (jn@longitude)
(gcc version 8.2.0 (Debian 8.2.0-9)) #1337 PREEMPT Sun Dec 16 02:37:19 CET 2018
[0.00] Using wii machine description
[0.00] -
[0.00] Hash_size = 0x10
[0.00] phys_mem_size = 0x570
[0.00] dcache_bsize = 0x20
[0.00] icache_bsize = 0x20
[0.00] cpu_features = 0x0401a008
[0.00] possible= 0x2f7ff049
[0.00] always = 0x
[0.00] cpu_user_features = 0x8c01 0x
[0.00] mmu_features = 0x00010001
[0.00] Hash = 0x(ptrval)
[0.00] Hash_mask = 0x3fff
[0.00] -
[0.00] wii: hw_ctrl at 0x0d800100 mapped to 0x(ptrval)
[0.00] wii: hw_gpio at 0x0d8000c0 mapped to 0x(ptrval)
[0.00] Top of RAM: 0x13f0, Total RAM: 0x570
[0.00] Memory hole size: 232MB
[0.00] Zone ranges:
[0.00] DMA [mem 0x-0x13ef]
[0.00] Normal empty
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00] node 0: [mem 0x-0x017f]
[0.00] node 0: [mem 0x1000-0x13ef]
[0.00] Initmem setup node 0 [mem 0x-0x13ef]
[0.00] On node 0 totalpages: 22272
[0.00] DMA zone: 638 pages used for memmap
[0.00] DMA zone: 0 pages reserved
[0.00] DMA zone: 22272 pages, LIFO batch:3
[0.00] random: get_random_u32 called from start_kernel+0x84/0x438 with
crng_init=0
[0.00] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
[0.00] pcpu-alloc: [0] 0
[0.00] Built 1 zonelists, mobility grouping on. Total pages: 21634
[0.00] Kernel command line: root=/dev/mmcblk0p2 rootwait
console=usbgecko1
[0.00] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
[0.00] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
[0.00] Memory: 73016K/89088K available (7084K kernel code, 512K rwdata,
1796K rodata, 2724K init, 158K bss, 16072K reserved, 0K cma-reserved)
[0.00] Kernel virtual memory layout:
[0.00] * 0xfffdf000..0xf000 : fixmap
[0.00] * 0xfde0..0xfe00 : consistent mem
[0.00] * 0xfddfe000..0xfde0 : early ioremap
[0.00] * 0xd400..0xfddfe000 : vmalloc & ioremap
[0.00] rcu: Preemptible hierarchical RCU implementation.
[0.00] Tasks RCU enabled.
[0.00] rcu: RCU calculated value of scheduler-enlistment delay is 25
jiffies.
[0.00] NR_IRQS: 512, nr_irqs: 512, preallocated irqs: 16
[0.00] flipper-pic: controller at 0x0c003000 mapped to 0x(ptrval)
[0.00] hlwd-pic: controller at 0x0d800030 mapped to 0x(ptrval)
[0.00] time_init: decrementer frequency = 60.75 MHz
[0.00] time_init: processor frequency = 729.00 MHz
[0.12] clocksource: timebase: mask: 0x m
[PATCH] kernel/sys.c: Fix UNAME26 for 5.0
UNAME26 is a mechanism to report Linux's version as 2.6.x, for
compatibility with old/broken software. Because of the way it is
implemented, it needs to be adjusted to handle version 5.0.
Signed-off-by: Jonathan Neuschäfer
---
kernel/sys.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/kernel/sys.c b/kernel/sys.c
index a48cbf1414b8..479f4ecdb405 100644
--- a/kernel/sys.c
+++ b/kernel/sys.c
@@ -1208,6 +1208,7 @@ DECLARE_RWSEM(uts_sem);
* Work around broken programs that cannot handle "Linux 3.0".
* Instead we map 3.x to 2.6.40+x, so e.g. 3.0 would be 2.6.40
* And we map 4.x to 2.6.60+x, so 4.0 would be 2.6.60.
+ * We map 5.x to 2.6.81+x, so 5.0 would be 2.6.81.
*/
static int override_release(char __user *release, size_t len)
{
@@ -1227,7 +1228,7 @@ static int override_release(char __user *release, size_t
len)
break;
rest++;
}
- v = ((LINUX_VERSION_CODE >> 8) & 0xff) + 60;
+ v = ((LINUX_VERSION_CODE >> 8) & 0xff) + 81;
copy = clamp_t(size_t, len, 1, sizeof(buf));
copy = scnprintf(buf, copy, "2.6.%u%s", v, rest);
ret = copy_to_user(release, buf, copy + 1);
--
2.20.1
Re: [PATCH] kernel/sys.c: Fix UNAME26 for 5.0
On Mon, Jan 07, 2019 at 10:10:31AM -0800, Linus Torvalds wrote: > On Mon, Jan 7, 2019 at 10:03 AM Jonathan Neuschäfer > wrote: > > > > UNAME26 is a mechanism to report Linux's version as 2.6.x, for > > compatibility with old/broken software. Because of the way it is > > implemented, it needs to be adjusted to handle version 5.0. > > Do we actually need this? I don't run any such old software, so I don't have a strong opinion here; I just sent this patch because I knew UNAME26 version strings would jump back without it. > I'd rather let it bitrot, and just let it return random versions. It > will just start again at 2.4.60, won't it? Correct. (Well, it's 2.6, not 2.4, but yes) > Anybody who uses UNAME26 for a 5.x kernel might as well think it's > still 4.x. The user space is so old that it can't possibly care about > differences between 4.x and 5.x, can it? > > The only thing that matters is that it shows "2.4.", > which it will do regardless. Good point, I guess that's a valid appraoch. Jonathan Neuschäfer signature.asc Description: PGP signature
Re: linux-next: build failure after merge of the irqchip tree
On Thu, Apr 08, 2021 at 08:56:18AM +0100, Marc Zyngier wrote:
> Hi Stephen,
>
> On 2021-04-08 07:35, Stephen Rothwell wrote:
> > Hi all,
> >
> > After merging the irqchip tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> >
> > drivers/irqchip/irq-wpcm450-aic.c:9:10: fatal error: asm/exception.h:
> > No such file or directory
> > 9 | #include
> > | ^
> >
> > Caused by commit
> >
> > fead4dd49663 ("irqchip: Add driver for WPCM450 interrupt controller")
> >
> > I have used the irqchip tree from next-20210407 for today.
>
> Thanks for the heads up. I guess that's the effect of COMPILE_TEST
> which was apparently not very well tested... I'll drop it from Kconfig.
Right, sorry about that.
> Jonathan, feel free to submit something re-enabling COMPILE_TEST once
> you've worked out the missing dependencies.
I used __exception_irq_entry from asm/exception.h, like other irqchip
drivers for ARM. This macro is only defined in arch/arm and arch/arm64.
So, AFAICS, there is no right set of dependencies for COMPILE_TEST.
Jonathan
signature.asc
Description: PGP signature
Re: [PATCH v2 00/10] Initial support for Nuvoton WPCM450 BMC SoC
On Fri, Apr 09, 2021 at 04:37:34AM +, Joel Stanley wrote: > On Tue, 6 Apr 2021 at 21:59, Jonathan Neuschäfer > wrote: > > > > On Tue, Apr 06, 2021 at 05:15:01PM +0200, Arnd Bergmann wrote: > > > On Tue, Apr 6, 2021 at 2:09 PM Jonathan Neuschäfer > > > wrote: > > > > > > > > This series adds basic support for the Nuvoton WPCM450 BMC SoC. It's an > > > > older > > > > SoC but still commonly found on eBay, mostly in Supermicro X9 server > > > > boards. > > > > > > > > Third-party documentation is available at: > > > > https://github.com/neuschaefer/wpcm450/wiki > > > > > > > > Patches 1-4 add devicetree bindings for the WPCM450 SoC and its various > > > > parts. > > > > Patches 5-7 add arch and driver support. Patches 8 and 9 add a > > > > devicetree for > > > > the SoC and a board based on it. Patch 10 finally updates the > > > > MAINTAINERS file. > > > > > > > > Patch 2 requires "dt-bindings: arm: Convert nuvoton,npcm750 binding to > > > > YAML" > > > > (https://lore.kernel.org/lkml/20210320164023.614059-1-j.neuschae...@gmx.net/) > > > > > > Hi Jonathan, > > > > > > It appears these patches are doing roughly the right thing, and we may > > > still > > > be able to get them into v5.13, but I'm not sure what your plan for > > > maintaining > > > them is. The two options are that you either send your patches to be > > > picked up > > > by Joel, or you send everything directly to s...@kernel.org once it's > > > fully > > > reviewed. > > > > The route via Joel sounds alright with me. I've Cc'd him on this version > > of the series. > > I've had a look at the series and it looks good to me: > > Reviewed-by: Joel Stanley > > Nice work Jonathan. > > I'll put this in it's own branch along with the bindings change it > depends on and send a pull request to Arnd for v5.13. Thanks a bunch! A few patches are going through other branches (IRQ bindings+driver; watchdog bindings+driver probably, I guess). That leaves the following patches to go into your branch, AFAIUI: [PATCH v2 01/10] dt-bindings: vendor-prefixes: Add Supermicro [PATCH v2 02/10] dt-bindings: arm: npcm: Add nuvoton,wpcm450 compatible string [PATCH v2 05/10] ARM: npcm: Introduce Nuvoton WPCM450 SoC [PATCH v2 08/10] ARM: dts: Add devicetree for Nuvoton WPCM450 BMC chip [PATCH v2 09/10] ARM: dts: Add devicetree for Supermicro X9SCi-LN4F based on WPCM450 [PATCH v2 10/10] MAINTAINERS: Add entry for Nuvoton WPCM450 Jonathan signature.asc Description: PGP signature
Re: [PATCH 3/5] powerpc/mm/32: Use page_is_ram to check for RAM
Hi,
On Mon, Mar 19, 2018 at 10:19:32PM +1100, Michael Ellerman wrote:
> Michael Ellerman writes:
> > Jonathan Neuschäfer writes:
[...]
> >> - if (slab_is_available() && (p < virt_to_phys(high_memory)) &&
> >> + if (page_is_ram(__phys_to_pfn(p)) &&
> >>!(__allow_ioremap_reserved && memblock_is_region_reserved(p,
> >> size))) {
> >>printk("__ioremap(): phys addr 0x%llx is RAM lr %ps\n",
> >> (unsigned long long)p, __builtin_return_address(0));
> >
> >
> > This is killing my p5020ds (Freescale e5500) unfortunately:
>
> Duh, I should actually read the patch :)
>
> This is a 32-bit system with 4G of RAM, so not all of RAM is mapped,
> some of it is highem which is why removing the test against high_memory
> above breaks it.
>
> So I need the high_memory test on this system.
This is an oversight on my part. I thought I wouldn't need this test
because the memblock-based test is more accurate, but I didn't think
through how high memory actually works.
> I'm not clear why it was a problem for you on the Wii, do you even build
> the Wii kernel with HIGHMEM enabled?
No. The Wii works fine with the p < virt_to_phys(high_memory) test, and
doesn't use CONFIG_HIGHMEM. I'll send a version two of this patchset.
Thanks for testing,
Jonathan Neuschäfer
signature.asc
Description: PGP signature
[PATCH v2 0/5] PPC32/ioremap: Use memblock API to check for RAM
v1: https://www.spinics.net/lists/linux-mm/msg145939.html This patchset makes it possible to allocate MMIO ranges that are between the two RAM chunks on the Wii, MEM1 and MEM2, not only with ioremap (which previously worked through a hack) but also with kernel/resource.c. Changes in v2: - I added back the p < virt_to_phys(high_memory) check in __ioremap_caller because high memory should be allocatable through ioremap - I expanded the commit messages a bit Jonathan Neuschäfer (5): powerpc: mm: Simplify page_is_ram by using memblock_is_memory powerpc: mm: Use memblock API for PPC32 page_is_ram powerpc/mm/32: Use page_is_ram to check for RAM powerpc: wii: Don't rely on the reserved memory hack powerpc/mm/32: Remove the reserved memory hack arch/powerpc/mm/init_32.c| 5 - arch/powerpc/mm/mem.c| 12 +--- arch/powerpc/mm/mmu_decl.h | 1 - arch/powerpc/mm/pgtable_32.c | 2 +- arch/powerpc/platforms/embedded6xx/wii.c | 14 +- 5 files changed, 3 insertions(+), 31 deletions(-) -- 2.16.2
[PATCH v2 2/5] powerpc: mm: Use memblock API for PPC32 page_is_ram
To support accurate checking for different blocks of memory on PPC32,
use the same memblock-based approach that's already used on PPC64 also
on PPC32.
Signed-off-by: Jonathan Neuschäfer
---
v2: no changes
---
arch/powerpc/mm/mem.c | 4
1 file changed, 4 deletions(-)
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index da4e1555d61d..a42b86e2a34c 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -82,11 +82,7 @@ static inline pte_t *virt_to_kpte(unsigned long vaddr)
int page_is_ram(unsigned long pfn)
{
-#ifndef CONFIG_PPC64 /* XXX for now */
- return pfn < max_pfn;
-#else
return memblock_is_memory(__pfn_to_phys(pfn));
-#endif
}
pgprot_t phys_mem_access_prot(struct file *file, unsigned long pfn,
--
2.16.2
[PATCH v2 4/5] powerpc: wii: Don't rely on the reserved memory hack
Because the two memory blocks (usually called MEM1 and MEM2) are not merged anymore, __request_region in kernel/resource.c will correctly allow reserving regions in the physical address space between MEM1 and MEM2, where many important peripherals are (GPIO, MMC, USB, ...). A previous change to __ioremap_caller in arch/powerpc/mm/pgtable_32.c ensures that multiple memblocks are properly considered in ioremap; this makes it unnecessary to set __allow_ioremap_reserved. Signed-off-by: Jonathan Neuschäfer --- v2: Add some text to the commit message. --- arch/powerpc/platforms/embedded6xx/wii.c | 14 +- 1 file changed, 1 insertion(+), 13 deletions(-) diff --git a/arch/powerpc/platforms/embedded6xx/wii.c b/arch/powerpc/platforms/embedded6xx/wii.c index 4682327f76a9..fc00d82691e1 100644 --- a/arch/powerpc/platforms/embedded6xx/wii.c +++ b/arch/powerpc/platforms/embedded6xx/wii.c @@ -81,21 +81,9 @@ void __init wii_memory_fixups(void) BUG_ON(memblock.memory.cnt != 2); BUG_ON(!page_aligned(p[0].base) || !page_aligned(p[1].base)); - /* trim unaligned tail */ - memblock_remove(ALIGN(p[1].base + p[1].size, PAGE_SIZE), - (phys_addr_t)ULLONG_MAX); - - /* determine hole, add & reserve them */ + /* determine hole */ wii_hole_start = ALIGN(p[0].base + p[0].size, PAGE_SIZE); wii_hole_size = p[1].base - wii_hole_start; - memblock_add(wii_hole_start, wii_hole_size); - memblock_reserve(wii_hole_start, wii_hole_size); - - BUG_ON(memblock.memory.cnt != 1); - __memblock_dump_all(); - - /* allow ioremapping the address space in the hole */ - __allow_ioremap_reserved = 1; } unsigned long __init wii_mmu_mapin_mem2(unsigned long top) -- 2.16.2
[PATCH v2 1/5] powerpc: mm: Simplify page_is_ram by using memblock_is_memory
Instead of open-coding the search in page_is_ram, call memblock_is_memory. Signed-off-by: Jonathan Neuschäfer --- v2: no changes --- arch/powerpc/mm/mem.c | 8 +--- 1 file changed, 1 insertion(+), 7 deletions(-) diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c index fe8c61149fb8..da4e1555d61d 100644 --- a/arch/powerpc/mm/mem.c +++ b/arch/powerpc/mm/mem.c @@ -85,13 +85,7 @@ int page_is_ram(unsigned long pfn) #ifndef CONFIG_PPC64 /* XXX for now */ return pfn < max_pfn; #else - unsigned long paddr = (pfn << PAGE_SHIFT); - struct memblock_region *reg; - - for_each_memblock(memory, reg) - if (paddr >= reg->base && paddr < (reg->base + reg->size)) - return 1; - return 0; + return memblock_is_memory(__pfn_to_phys(pfn)); #endif } -- 2.16.2
[PATCH v2 5/5] powerpc/mm/32: Remove the reserved memory hack
This hack, introduced in commit c5df7f775148 ("powerpc: allow ioremap
within reserved memory regions") is now unnecessary.
Signed-off-by: Jonathan Neuschäfer
---
v2: no changes
---
arch/powerpc/mm/init_32.c| 5 -
arch/powerpc/mm/mmu_decl.h | 1 -
arch/powerpc/mm/pgtable_32.c | 3 +--
3 files changed, 1 insertion(+), 8 deletions(-)
diff --git a/arch/powerpc/mm/init_32.c b/arch/powerpc/mm/init_32.c
index a2bf6965d04f..3e59e5d64b01 100644
--- a/arch/powerpc/mm/init_32.c
+++ b/arch/powerpc/mm/init_32.c
@@ -88,11 +88,6 @@ void MMU_init(void);
int __map_without_bats;
int __map_without_ltlbs;
-/*
- * This tells the system to allow ioremapping memory marked as reserved.
- */
-int __allow_ioremap_reserved;
-
/* max amount of low RAM to map in */
unsigned long __max_low_memory = MAX_LOW_MEM;
diff --git a/arch/powerpc/mm/mmu_decl.h b/arch/powerpc/mm/mmu_decl.h
index 57fbc554c785..c4c0a09a7775 100644
--- a/arch/powerpc/mm/mmu_decl.h
+++ b/arch/powerpc/mm/mmu_decl.h
@@ -98,7 +98,6 @@ extern void setbat(int index, unsigned long virt, phys_addr_t
phys,
unsigned int size, pgprot_t prot);
extern int __map_without_bats;
-extern int __allow_ioremap_reserved;
extern unsigned int rtas_data, rtas_size;
struct hash_pte;
diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c
index 6668ecc041ad..120a49bfb9c6 100644
--- a/arch/powerpc/mm/pgtable_32.c
+++ b/arch/powerpc/mm/pgtable_32.c
@@ -148,8 +148,7 @@ __ioremap_caller(phys_addr_t addr, unsigned long size,
unsigned long flags,
* mem_init() sets high_memory so only do the check after that.
*/
if (slab_is_available() && (p < virt_to_phys(high_memory)) &&
- page_is_ram(__phys_to_pfn(p)) &&
- !(__allow_ioremap_reserved && memblock_is_region_reserved(p,
size))) {
+ page_is_ram(__phys_to_pfn(p))) {
printk("__ioremap(): phys addr 0x%llx is RAM lr %ps\n",
(unsigned long long)p, __builtin_return_address(0));
return NULL;
--
2.16.2
[PATCH v2 3/5] powerpc/mm/32: Use page_is_ram to check for RAM
On systems where there is MMIO space between different blocks of RAM in
the physical address space, __ioremap_caller did not allow mapping these
MMIO areas, because they were below the end RAM and thus considered RAM
as well. Use the memblock-based page_is_ram function, which returns
false for such MMIO holes.
v2:
Keep the check for p < virt_to_phys(high_memory). On 32-bit systems
with high memory (memory above physical address 4GiB), the high memory
is expected to be available though ioremap. The high_memory variable
marks the end of low memory; comparing against it means that only
ioremap requests for low RAM will be denied.
Reported by Michael Ellerman.
Signed-off-by: Jonathan Neuschäfer
---
arch/powerpc/mm/pgtable_32.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c
index d35d9ad3c1cd..6668ecc041ad 100644
--- a/arch/powerpc/mm/pgtable_32.c
+++ b/arch/powerpc/mm/pgtable_32.c
@@ -148,6 +148,7 @@ __ioremap_caller(phys_addr_t addr, unsigned long size,
unsigned long flags,
* mem_init() sets high_memory so only do the check after that.
*/
if (slab_is_available() && (p < virt_to_phys(high_memory)) &&
+ page_is_ram(__phys_to_pfn(p)) &&
!(__allow_ioremap_reserved && memblock_is_region_reserved(p,
size))) {
printk("__ioremap(): phys addr 0x%llx is RAM lr %ps\n",
(unsigned long long)p, __builtin_return_address(0));
--
2.16.2
[PATCH 2/2] powerpc: wii_defconfig: Enable GPIO-related options
Now that there's a GPIO driver for the Wii, let's enable the following drivers: - the GPIO driver itself - gpio-keys - gpio-poweroff - gpio-leds and a few LED triggers Signed-off-by: Jonathan Neuschäfer --- arch/powerpc/configs/wii_defconfig | 8 1 file changed, 8 insertions(+) diff --git a/arch/powerpc/configs/wii_defconfig b/arch/powerpc/configs/wii_defconfig index 3167b9d7f3e5..40a3b5c09765 100644 --- a/arch/powerpc/configs/wii_defconfig +++ b/arch/powerpc/configs/wii_defconfig @@ -58,6 +58,7 @@ CONFIG_INPUT_FF_MEMLESS=m CONFIG_INPUT_JOYDEV=y CONFIG_INPUT_EVDEV=y # CONFIG_KEYBOARD_ATKBD is not set +CONFIG_KEYBOARD_GPIO=y # CONFIG_MOUSE_PS2 is not set CONFIG_INPUT_JOYSTICK=y CONFIG_INPUT_MISC=y @@ -72,6 +73,9 @@ CONFIG_I2C_CHARDEV=y CONFIG_I2C_GPIO=y CONFIG_GPIOLIB=y CONFIG_GPIO_SYSFS=y +CONFIG_GPIO_HLWD=y +CONFIG_POWER_RESET=y +CONFIG_POWER_RESET_GPIO=y # CONFIG_HWMON is not set CONFIG_SSB_DEBUG=y CONFIG_FB=y @@ -89,6 +93,10 @@ CONFIG_HID_APPLE=m CONFIG_HID_WACOM=m CONFIG_MMC=y CONFIG_MMC_SDHCI=y +CONFIG_LEDS_CLASS=y +CONFIG_LEDS_GPIO=y +CONFIG_LEDS_TRIGGER_HEARTBEAT=y +CONFIG_LEDS_TRIGGER_PANIC=y CONFIG_RTC_CLASS=y CONFIG_RTC_DRV_GENERIC=y CONFIG_EXT2_FS=y -- 2.17.0
[PATCH 1/2] powerpc: wii_defconfig: Disable Ethernet driver support code
The Wii doesn't have built-in Ethernet and USB Ethernet adapters are in a different menu. Disable CONFIG_ETHERNET to save some space in support code for Ethernet drivers. add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-367 (-367) Function old new delta kernel_config_data 13691 13324-367 Total: Before=8341718, After=8341351, chg -0.00% Signed-off-by: Jonathan Neuschäfer --- arch/powerpc/configs/wii_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/powerpc/configs/wii_defconfig b/arch/powerpc/configs/wii_defconfig index 0b0f78823a1b..3167b9d7f3e5 100644 --- a/arch/powerpc/configs/wii_defconfig +++ b/arch/powerpc/configs/wii_defconfig @@ -49,6 +49,7 @@ CONFIG_BLK_DEV_RAM_COUNT=2 CONFIG_SCSI=y CONFIG_BLK_DEV_SD=y CONFIG_NETDEVICES=y +# CONFIG_ETHERNET is not set CONFIG_B43=y CONFIG_B43_SDIO=y # CONFIG_B43_PHY_LP is not set -- 2.17.0
[PATCH] Documentation: gpio: driver: Fix a typo and some odd grammar
Signed-off-by: Jonathan Neuschäfer --- Documentation/driver-api/gpio/driver.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Documentation/driver-api/gpio/driver.rst b/Documentation/driver-api/gpio/driver.rst index 505ee906d7d9..cbe0242842d1 100644 --- a/Documentation/driver-api/gpio/driver.rst +++ b/Documentation/driver-api/gpio/driver.rst @@ -44,7 +44,7 @@ common to each controller of that type: - methods to establish GPIO line direction - methods used to access GPIO line values - - method to set electrical configuration to a a given GPIO line + - method to set electrical configuration for a given GPIO line - method to return the IRQ number associated to a given GPIO line - flag saying whether calls to its methods may sleep - optional line names array to identify lines @@ -143,7 +143,7 @@ resistor will make the line tend to high level unless one of the transistors on the rail actively pulls it down. The level on the line will go as high as the VDD on the pull-up resistor, which -may be higher than the level supported by the transistor, achieveing a +may be higher than the level supported by the transistor, achieving a level-shift to the higher VDD. Integrated electronics often have an output driver stage in the form of a CMOS @@ -382,7 +382,7 @@ Real-Time compliance for GPIO IRQ chips Any provider of irqchips needs to be carefully tailored to support Real Time preemption. It is desirable that all irqchips in the GPIO subsystem keep this -in mind and does the proper testing to assure they are real time-enabled. +in mind and do the proper testing to assure they are real time-enabled. So, pay attention on above " RT_FULL:" notes, please. The following is a checklist to follow when preparing a driver for real time-compliance: -- 2.17.0
[PATCH] PM: docs: sleep-states: Fix a typo ("includig")
Signed-off-by: Jonathan Neuschäfer --- Documentation/admin-guide/pm/sleep-states.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/admin-guide/pm/sleep-states.rst b/Documentation/admin-guide/pm/sleep-states.rst index 1e5c0f00cb2f..dbf5acd49f35 100644 --- a/Documentation/admin-guide/pm/sleep-states.rst +++ b/Documentation/admin-guide/pm/sleep-states.rst @@ -15,7 +15,7 @@ Sleep States That Can Be Supported == Depending on its configuration and the capabilities of the platform it runs on, -the Linux kernel can support up to four system sleep states, includig +the Linux kernel can support up to four system sleep states, including hibernation and up to three variants of system suspend. The sleep states that can be supported by the kernel are listed below. -- 2.17.0
Re: [PATCH 2/5] ARM: dts: imx50: Add Kobo Aura DTS
Hi, thanks for your comments. I'll address them in v2.
On Fri, Mar 22, 2019 at 09:31:53AM +0800, Shawn Guo wrote:
> On Tue, Mar 19, 2019 at 04:24:17PM +0100, Jonathan Neuschäfer wrote:
> > The Kobo Aura is an e-book reader released in 2013.
[...]
> > + sd2_pwrseq: pwrseq {
> > + compatible = "mmc-pwrseq-simple";
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_sd2_reset>;
> > +
>
> Please do not have random newlines.
Does that apply to all empty lines between properties?
>
> > + reset-gpios = <&gpio4 17 GPIO_ACTIVE_LOW>;
> > + };
> > +
[...]
> > +&iomuxc {
> > + pinctrl_uart2: uart2 {
> > + fsl,pins = <
> > + MX50_PAD_UART2_TXD__UART2_TXD_MUX 0x1e4
> > + MX50_PAD_UART2_RXD__UART2_RXD_MUX 0x1e4
> > + >;
> > + };
> > +
> > + pinctrl_i2c1: i2c1 {
>
> Please sort these pinctrl nodes alphabetically.
It doesn't make a difference here, but should I generally sort by name
or by label in cases like this one?
Jonathan Neuschäfer
signature.asc
Description: PGP signature
[PATCH v2 2/2] clk: imx5: Fix i.MX50 ESDHC clock registers
The MUX bits for esdhc_{a,c,d}_sel are shifted by one bit within CSCMR1,
because esdhc_b_sel (ESDHC3_CLK_SEL in the Reference Manual) is extended
by one bit.
Signed-off-by: Jonathan Neuschäfer
---
v2:
- Split into two patches, as suggested by Aisheng Dong
- Extended the commit message slightly
v1:
https://lore.kernel.org/lkml/20190318231737.8459-1-j.neuschae...@gmx.net/
---
drivers/clk/imx/clk-imx51-imx53.c | 40 +++
1 file changed, 30 insertions(+), 10 deletions(-)
diff --git a/drivers/clk/imx/clk-imx51-imx53.c
b/drivers/clk/imx/clk-imx51-imx53.c
index 3c188aa37cd7..c85ebd74a8a5 100644
--- a/drivers/clk/imx/clk-imx51-imx53.c
+++ b/drivers/clk/imx/clk-imx51-imx53.c
@@ -187,16 +187,10 @@ static void __init mx5_clocks_common_init(void __iomem
*ccm_base)
clk[IMX5_CLK_UART_PRED] = imx_clk_divider("uart_pred",
"uart_sel", MXC_CCM_CSCDR1, 3, 3);
clk[IMX5_CLK_UART_ROOT] = imx_clk_divider("uart_root",
"uart_pred", MXC_CCM_CSCDR1, 0, 3);
- clk[IMX5_CLK_ESDHC_A_SEL] = imx_clk_mux("esdhc_a_sel",
MXC_CCM_CSCMR1, 20, 2,
- standard_pll_sel,
ARRAY_SIZE(standard_pll_sel));
- clk[IMX5_CLK_ESDHC_B_SEL] = imx_clk_mux("esdhc_b_sel",
MXC_CCM_CSCMR1, 16, 2,
- standard_pll_sel,
ARRAY_SIZE(standard_pll_sel));
clk[IMX5_CLK_ESDHC_A_PRED] = imx_clk_divider("esdhc_a_pred",
"esdhc_a_sel", MXC_CCM_CSCDR1, 16, 3);
clk[IMX5_CLK_ESDHC_A_PODF] = imx_clk_divider("esdhc_a_podf",
"esdhc_a_pred", MXC_CCM_CSCDR1, 11, 3);
clk[IMX5_CLK_ESDHC_B_PRED] = imx_clk_divider("esdhc_b_pred",
"esdhc_b_sel", MXC_CCM_CSCDR1, 22, 3);
clk[IMX5_CLK_ESDHC_B_PODF] = imx_clk_divider("esdhc_b_podf",
"esdhc_b_pred", MXC_CCM_CSCDR1, 19, 3);
- clk[IMX5_CLK_ESDHC_C_SEL] = imx_clk_mux("esdhc_c_sel",
MXC_CCM_CSCMR1, 19, 1, esdhc_c_sel, ARRAY_SIZE(esdhc_c_sel));
- clk[IMX5_CLK_ESDHC_D_SEL] = imx_clk_mux("esdhc_d_sel",
MXC_CCM_CSCMR1, 18, 1, esdhc_d_sel, ARRAY_SIZE(esdhc_d_sel));
clk[IMX5_CLK_EMI_SEL] = imx_clk_mux("emi_sel", MXC_CCM_CBCDR,
26, 1,
emi_slow_sel,
ARRAY_SIZE(emi_slow_sel));
@@ -307,10 +301,6 @@ static void __init mx5_clocks_common_init(void __iomem
*ccm_base)
clk_register_clkdev(clk[IMX5_CLK_CPU_PODF], NULL, "cpu0");
clk_register_clkdev(clk[IMX5_CLK_GPC_DVFS], "gpc_dvfs", NULL);
- /* Set SDHC parents to be PLL2 */
- clk_set_parent(clk[IMX5_CLK_ESDHC_A_SEL], clk[IMX5_CLK_PLL2_SW]);
- clk_set_parent(clk[IMX5_CLK_ESDHC_B_SEL], clk[IMX5_CLK_PLL2_SW]);
-
/* move usb phy clk to 24MHz */
clk_set_parent(clk[IMX5_CLK_USB_PHY_SEL], clk[IMX5_CLK_OSC]);
}
@@ -347,6 +337,12 @@ static void __init mx50_clocks_init(struct device_node *np)
clk[IMX5_CLK_LP_APM]= imx_clk_mux("lp_apm", MXC_CCM_CCSR,
10, 1,
lp_apm_sel,
ARRAY_SIZE(lp_apm_sel));
+ clk[IMX5_CLK_ESDHC_A_SEL] = imx_clk_mux("esdhc_a_sel",
MXC_CCM_CSCMR1, 21, 2,
+ standard_pll_sel,
ARRAY_SIZE(standard_pll_sel));
+ clk[IMX5_CLK_ESDHC_B_SEL] = imx_clk_mux("esdhc_b_sel",
MXC_CCM_CSCMR1, 16, 2,
+ standard_pll_sel,
ARRAY_SIZE(standard_pll_sel));
+ clk[IMX5_CLK_ESDHC_C_SEL] = imx_clk_mux("esdhc_c_sel",
MXC_CCM_CSCMR1, 20, 1, esdhc_c_sel, ARRAY_SIZE(esdhc_c_sel));
+ clk[IMX5_CLK_ESDHC_D_SEL] = imx_clk_mux("esdhc_d_sel",
MXC_CCM_CSCMR1, 19, 1, esdhc_d_sel, ARRAY_SIZE(esdhc_d_sel));
clk[IMX5_CLK_ESDHC1_PER_GATE] = imx_clk_gate2("esdhc1_per_gate",
"esdhc_a_podf", MXC_CCM_CCGR3, 2);
clk[IMX5_CLK_ESDHC2_PER_GATE] = imx_clk_gate2("esdhc2_per_gate",
"esdhc_c_sel", MXC_CCM_CCGR3, 6);
clk[IMX5_CLK_ESDHC3_PER_GATE] = imx_clk_gate2("esdhc3_per_gate",
"esdhc_b_podf", MXC_CCM_CCGR3, 10);
@@ -375,6 +371,10 @@ static void __init mx50_clocks_init(struct device_node *np)
clk_data.clk_num = ARRAY_SIZE(clk);
of_clk_add_provider(np, of_clk_src_onecell_get, &clk_data);
+ /* Set SDHC parents to be PLL2 */
+ clk_set_parent(clk[IMX5_CLK_ESDHC_A_SEL], clk[IMX5_CLK_PLL2_SW]);
+ clk_set_parent(clk[IMX5_CLK_ESDHC_B_SEL], clk[IMX5_CLK_PLL2_SW]);
+
/* set SDHC root clock to 200MHZ*/
clk_set_rate(clk[IMX5_CLK_ESDHC_A_PODF], 2);
clk_set_rate(clk[IMX5_CLK_ESDHC_B_PODF], 2);
@@ -429,6 +429,12 @@ static void __init mx51_clocks_init(struct devic
[PATCH v2 1/2] clk: imx5: Fix i.MX50 mainbus clock registers
i.MX50 does not have a periph_apm clock. Instead, the main bus clock
(a.k.a. periph_clk) comes directly from a MUX between pll1_sw, pll2_sw,
pll3_sw, and lp_apm.
Signed-off-by: Jonathan Neuschäfer
---
v2:
- Split into two patches, as suggested by Aisheng Dong
v1:
https://lore.kernel.org/lkml/20190318231737.8459-1-j.neuschae...@gmx.net/
drivers/clk/imx/clk-imx51-imx53.c | 19 +++
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/drivers/clk/imx/clk-imx51-imx53.c
b/drivers/clk/imx/clk-imx51-imx53.c
index e91c826bce70..3c188aa37cd7 100644
--- a/drivers/clk/imx/clk-imx51-imx53.c
+++ b/drivers/clk/imx/clk-imx51-imx53.c
@@ -164,10 +164,6 @@ static void __init mx5_clocks_common_init(void __iomem
*ccm_base)
clk[IMX5_CLK_CKIH1] = imx_obtain_fixed_clock("ckih1", 0);
clk[IMX5_CLK_CKIH2] = imx_obtain_fixed_clock("ckih2", 0);
- clk[IMX5_CLK_PERIPH_APM]= imx_clk_mux("periph_apm",
MXC_CCM_CBCMR, 12, 2,
- periph_apm_sel,
ARRAY_SIZE(periph_apm_sel));
- clk[IMX5_CLK_MAIN_BUS] = imx_clk_mux("main_bus",
MXC_CCM_CBCDR, 25, 1,
- main_bus_sel,
ARRAY_SIZE(main_bus_sel));
clk[IMX5_CLK_PER_LP_APM]= imx_clk_mux("per_lp_apm",
MXC_CCM_CBCMR, 1, 1,
per_lp_apm_sel,
ARRAY_SIZE(per_lp_apm_sel));
clk[IMX5_CLK_PER_PRED1] = imx_clk_divider("per_pred1",
"per_lp_apm", MXC_CCM_CBCDR, 6, 2);
@@ -342,6 +338,13 @@ static void __init mx50_clocks_init(struct device_node *np)
mx5_clocks_common_init(ccm_base);
+ /*
+* This clock is called periph_clk in the i.MX50 Reference Manual, but
+* it comes closest in scope to the main_bus_clk of i.MX51 and i.MX53
+*/
+ clk[IMX5_CLK_MAIN_BUS] = imx_clk_mux("main_bus",
MXC_CCM_CBCDR, 25, 2,
+ standard_pll_sel,
ARRAY_SIZE(standard_pll_sel));
+
clk[IMX5_CLK_LP_APM]= imx_clk_mux("lp_apm", MXC_CCM_CCSR,
10, 1,
lp_apm_sel,
ARRAY_SIZE(lp_apm_sel));
clk[IMX5_CLK_ESDHC1_PER_GATE] = imx_clk_gate2("esdhc1_per_gate",
"esdhc_a_podf", MXC_CCM_CCGR3, 2);
@@ -410,6 +413,10 @@ static void __init mx51_clocks_init(struct device_node *np)
mx5_clocks_common_init(ccm_base);
+ clk[IMX5_CLK_PERIPH_APM]= imx_clk_mux("periph_apm",
MXC_CCM_CBCMR, 12, 2,
+ periph_apm_sel,
ARRAY_SIZE(periph_apm_sel));
+ clk[IMX5_CLK_MAIN_BUS] = imx_clk_mux("main_bus",
MXC_CCM_CBCDR, 25, 1,
+ main_bus_sel,
ARRAY_SIZE(main_bus_sel));
clk[IMX5_CLK_LP_APM]= imx_clk_mux("lp_apm", MXC_CCM_CCSR,
9, 1,
lp_apm_sel,
ARRAY_SIZE(lp_apm_sel));
clk[IMX5_CLK_IPU_DI0_SEL] = imx_clk_mux_flags("ipu_di0_sel",
MXC_CCM_CSCMR2, 26, 3,
@@ -506,6 +513,10 @@ static void __init mx53_clocks_init(struct device_node *np)
mx5_clocks_common_init(ccm_base);
+ clk[IMX5_CLK_PERIPH_APM]= imx_clk_mux("periph_apm",
MXC_CCM_CBCMR, 12, 2,
+ periph_apm_sel,
ARRAY_SIZE(periph_apm_sel));
+ clk[IMX5_CLK_MAIN_BUS] = imx_clk_mux("main_bus",
MXC_CCM_CBCDR, 25, 1,
+ main_bus_sel,
ARRAY_SIZE(main_bus_sel));
clk[IMX5_CLK_LP_APM]= imx_clk_mux("lp_apm", MXC_CCM_CCSR,
10, 1,
lp_apm_sel,
ARRAY_SIZE(lp_apm_sel));
clk[IMX5_CLK_LDB_DI1_DIV_3_5] =
imx_clk_fixed_factor("ldb_di1_div_3_5", "ldb_di1_sel", 2, 7);
--
2.20.1
[PATCH v2 0/2] clk: imx5: Fix i.MX50 clock registers
There are a few differences between the i.MX50 clock tree and those of i.MX51 and i.MX53 that are not yet handled in clk-imx51-imx53.c. This series handles two of them. Jonathan Neuschäfer (2): clk: imx5: Fix i.MX50 mainbus clock registers clk: imx5: Fix i.MX50 ESDHC clock registers v2: - Split into two patches, as suggested by Aisheng Dong v1: https://lore.kernel.org/lkml/20190318231737.8459-1-j.neuschae...@gmx.net/ drivers/clk/imx/clk-imx51-imx53.c | 59 +++ 1 file changed, 45 insertions(+), 14 deletions(-) -- 2.20.1
Re: [PATCH 21/21] docs: hwmon: Add an index file and rename docs to *.rst
Hello, On Wed, Apr 10, 2019 at 08:12:11AM -0300, Mauro Carvalho Chehab wrote: > Now that all files were converted to ReST format, rename them > and add an index. > > Signed-off-by: Mauro Carvalho Chehab > --- [...] > diff --git a/Documentation/hwmon/submitting-patches > b/Documentation/hwmon/submitting-patches.rst > similarity index 99% > rename from Documentation/hwmon/submitting-patches > rename to Documentation/hwmon/submitting-patches.rst > index 12540b7d9b50..6120db7556aa 100644 > --- a/Documentation/hwmon/submitting-patches > +++ b/Documentation/hwmon/submitting-patches.rst I'd additionally suggest: diff --git a/Documentation/hwmon/submitting-patches b/Documentation/hwmon/submitting-patches.rst index f88221b46153..a86be4b9 100644 --- a/Documentation/hwmon/submitting-patches +++ b/Documentation/hwmon/submitting-patches.rst @@ -38,7 +38,7 @@ increase the chances of your change being accepted. 2. Adding functionality to existing drivers --- -* Make sure the documentation in Documentation/hwmon/ is up to +* Make sure the documentation in Documentation/hwmon/.rst is up to date. * Make sure the information in Kconfig is up to date. @@ -60,7 +60,7 @@ increase the chances of your change being accepted. * Consider adding yourself to MAINTAINERS. -* Document the driver in Documentation/hwmon/. +* Document the driver in Documentation/hwmon/.rst. * Add the driver to Kconfig and Makefile in alphabetical order. Thanks, Jonathan Neuschäfer signature.asc Description: PGP signature
[PATCH] div64.h: Fix description of do_div parameter
Contrary to the description, the first parameter (n) should not be passed as a pointer, but directly as an lvalue. This is possible because do_div is a macro. Signed-off-by: Jonathan Neuschäfer --- include/asm-generic/div64.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/include/asm-generic/div64.h b/include/asm-generic/div64.h index dc9726fdac8f..b2a9c74efa55 100644 --- a/include/asm-generic/div64.h +++ b/include/asm-generic/div64.h @@ -28,12 +28,12 @@ /** * do_div - returns 2 values: calculate remainder and update new dividend - * @n: pointer to uint64_t dividend (will be updated) + * @n: uint64_t dividend (will be updated) * @base: uint32_t divisor * * Summary: - * ``uint32_t remainder = *n % base;`` - * ``*n = *n / base;`` + * ``uint32_t remainder = n % base;`` + * ``n = n / base;`` * * Return: (uint32_t)remainder * -- 2.20.1
Re: [PATCH] div64.h: Fix description of do_div parameter
On Mon, Feb 25, 2019 at 04:19:02PM +0100, Geert Uytterhoeven wrote:
> Hi Jonathan,
>
> On Mon, Feb 25, 2019 at 3:05 PM Jonathan Neuschäfer
> wrote:
> > Contrary to the description, the first parameter (n) should not be
> > passed as a pointer, but directly as an lvalue. This is possible because
> > do_div is a macro.
> >
> > Signed-off-by: Jonathan Neuschäfer
>
> Thanks for your patch!
>
> Reviewed-by: Geert Uytterhoeven
>
> Shouldn't the "semantics" at the top of include/asm-generic/div64.h be
> updated, too?
Arguably, it's semantically close enough. I'm not sure.
> As this can't be expressed in a C function, perhaps that should be done
> using C++ syntax, like
>
> uint32_t do_div(uint64_t &n, uint32_t base)
> {
> ...
> }
That might confuse some people who aren't expecting C++ syntax.
I'll leave this as is, because I can't decide wether this is an
improvement.
Thanks,
Jonathan Neuschäfer
signature.asc
Description: PGP signature
Re: [PATCH] mmc: spi: Fix card detection during probe
On Tue, Feb 26, 2019 at 09:18:06AM +0100, Ulf Hansson wrote: > On Sun, 10 Feb 2019 at 18:31, Jonathan Neuschäfer > wrote: > > > > When using the mmc_spi driver with a card-detect pin, I noticed that the > > card was not detected immediately after probe, but only after it was > > unplugged and plugged back in (and the CD IRQ fired). > > > > The call tree looks something like this: > > > > mmc_spi_probe > > mmc_add_host > > mmc_start_host > > _mmc_detect_change > > mmc_schedule_delayed_work(&host->detect, 0) > > mmc_rescan > > host->bus_ops->detect(host) > > mmc_detect > > _mmc_detect_card_removed > > host->ops->get_cd(host) > > mmc_gpio_get_cd -> -ENOSYS (ctx->cd_gpio not set) > > mmc_gpiod_request_cd > > ctx->cd_gpio = desc > > > > To fix this issue, call mmc_detect_change after the card-detect GPIO/IRQ > > is registered. > > > > Signed-off-by: Jonathan Neuschäfer > > This works well as fix and for stable! However, we should probably > clean up the code in ->probe() to avoid this thing altogether. I figured that calling mmc_gpiod_request_cd before mmc_add_host *should* avoid the 'return -ENOSYS' in mmc_gpio_get_cd. However it turned out to be not as simple as swapping around a few lines in mmc_spi_probe, when I wrote/tested this patch. > Anyway, I send a patch for that - on top. Thanks! > Applied for fixes and added a stable tag, thanks! Great. Thanks, Jonathan Neuschäfer signature.asc Description: PGP signature
[PATCH] pinctrl: nuvoton: npcm7xx: Fix alignment of table header comment
Make it so that each column label is in the column that it is supposed
to refer to.
Signed-off-by: Jonathan Neuschäfer
---
drivers/pinctrl/nuvoton/pinctrl-npcm7xx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pinctrl/nuvoton/pinctrl-npcm7xx.c
b/drivers/pinctrl/nuvoton/pinctrl-npcm7xx.c
index 6de31b5ee358c..2535ca720668e 100644
--- a/drivers/pinctrl/nuvoton/pinctrl-npcm7xx.c
+++ b/drivers/pinctrl/nuvoton/pinctrl-npcm7xx.c
@@ -923,7 +923,7 @@ struct npcm7xx_pincfg {
};
static const struct npcm7xx_pincfg pincfg[] = {
- /* PIN FUNCTION 1 FUNCTION 2
FUNCTION 3FLAGS */
+ /* PIN FUNCTION 1 FUNCTION 2
FUNCTION 3FLAGS */
NPCM7XX_PINCFG(0,iox1, MFSEL1, 30,none, NONE, 0,
none, NONE, 0, 0),
NPCM7XX_PINCFG(1,iox1, MFSEL1, 30,none, NONE, 0,
none, NONE, 0, DS(8, 12)),
NPCM7XX_PINCFG(2,iox1, MFSEL1, 30,none, NONE, 0,
none, NONE, 0, DS(8, 12)),
--
2.29.2
Re: [PATCH v1] mtd: spi-nor: core: fix/remove references to spi-nor.c
On Tue, Jan 26, 2021 at 10:25:16AM +0100, Flavio Suligoi wrote:
> The old file:
>
> drivers/mtd/spi-nor/spi-nor.c
>
> is not more present and now some of its code is
> contained in:
>
> drivers/mtd/spi-nor/core.c
>
> This patch fix/remove the references to the old
> spi-nor.c file.
>
> Signed-off-by: Flavio Suligoi
> ---
Reviewed-by: Jonathan Neuschäfer
Thanks.
> Documentation/driver-api/mtd/spi-nor.rst | 2 +-
> drivers/mtd/spi-nor/core.c | 4 ++--
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/driver-api/mtd/spi-nor.rst
> b/Documentation/driver-api/mtd/spi-nor.rst
> index 4a3adca417fd..bf2db371d3fb 100644
> --- a/Documentation/driver-api/mtd/spi-nor.rst
> +++ b/Documentation/driver-api/mtd/spi-nor.rst
> @@ -61,7 +61,7 @@ Part III - How can drivers use the framework?
>
> The main API is spi_nor_scan(). Before you call the hook, a driver should
> initialize the necessary fields for spi_nor{}. Please see
> -drivers/mtd/spi-nor/spi-nor.c for detail. Please also refer to spi-fsl-qspi.c
> +drivers/mtd/spi-nor/core.c for detail. Please also refer to spi-fsl-qspi.c
> when you want to write a new driver for a SPI NOR controller.
> Another API is spi_nor_restore(), this is used to restore the status of SPI
> flash chip such as addressing mode. Call it whenever detach the driver from
> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
> index 20df44b753da..6ae7d4c2d2b6 100644
> --- a/drivers/mtd/spi-nor/core.c
> +++ b/drivers/mtd/spi-nor/core.c
> @@ -3701,8 +3701,8 @@ static void spi_nor_shutdown(struct spi_mem *spimem)
> * encourage new users to add support to the spi-nor library, and simply bind
> * against a generic string here (e.g., "jedec,spi-nor").
> *
> - * Many flash names are kept here in this list (as well as in spi-nor.c) to
> - * keep them available as module aliases for existing platforms.
> + * Many flash names are kept here in this list to keep them available
> + * as module aliases for existing platforms.
> */
> static const struct spi_device_id spi_nor_dev_ids[] = {
> /*
> --
> 2.25.1
>
signature.asc
Description: PGP signature
Re: [PATCH 1/2] dt-bindings: arm: Convert nuvoton, npcm750 binding to YAML
On Sun, Jan 10, 2021 at 11:18:46AM -0600, Rob Herring wrote: [...] > My bot found errors running 'make dt_binding_check' on your patch: > > yamllint warnings/errors: > ./Documentation/devicetree/bindings/arm/npcm/npcm.yaml:20:13: [warning] wrong > indentation: expected 14 but found 12 (indentation) > > dtschema/dtc warnings/errors: > ./Documentation/devicetree/bindings/arm/npcm/npcm.yaml: $id: relative > path/filename doesn't match actual path or filename > expected: http://devicetree.org/schemas/arm/npcm/npcm.yaml# Sorry for missing those. I'll fix them in version 2. Best regards, Jonathan Neuschäfer signature.asc Description: PGP signature
[PATCH v6 0/7] Netronix embedded controller driver for Kobo and Tolino ebook readers
This patchset adds basic support for the embedded controller found on older ebook reader boards designed by/with the ODM Netronix Inc.[1] and sold by Kobo or Tolino, for example the Kobo Aura and the Tolino Shine. These drivers are based on information contained in the vendor kernel sources, but in order to all information in a single place, I documented the register interface of the EC on GitHub[2]. [1]: http://www.netronixinc.com/products.aspx?ID=1 [2]: https://github.com/neuschaefer/linux/wiki/Netronix-MSP430-embedded-controller v6: - Additional cleanups in the PWM driver - Added Lee Jones' ACK to the MFD driver patch v5: - https://lore.kernel.org/lkml/20201201011513.1627028-1-j.neuschae...@gmx.net/ - Avoid truncation of PWM period and duty cycle to 32 bits - A few cleanups and additional comments in the PWM driver - Use regmap_multi_reg_write v4: - https://lore.kernel.org/lkml/2020112739.1455132-1-j.neuschae...@gmx.net/ - Spell out ODM (original design manufacturer) - Solve corner cases in the RTC driver - Clean up use of log levels vs. error codes - Add more comments explaining some peculiarities - Add missing MODULE_ALIAS lines - Various other cleanups v3: - https://lore.kernel.org/lkml/20200924192455.2484005-1-j.neuschae...@gmx.net/ - A few code cleanups - A few devicetree related cleanups - PWM and RTC functionality were moved from subnodes in the devicetree to the main node. This also means that the subdrivers no longer need DT compatible strings, but are instead loaded via the mfd_cell mechanism. - The drivers are now published under GPLv2-or-later rather than GPLv2-only. v2: - https://lore.kernel.org/lkml/20200905133230.1014581-1-j.neuschae...@gmx.net/ - Moved txt DT bindings to patch descriptions and removed patch 1/10 "DT bindings in plain text format" - New patch 7/10 "rtc: Introduce RTC_TIMESTAMP_END_2255" - Rebased on 5.9-rc3 - Various other changes which are documented in each patch v1: - https://lore.kernel.org/lkml/20200620223915.1311485-1-j.neuschae...@gmx.net/ Jonathan Neuschäfer (7): dt-bindings: Add vendor prefix for Netronix, Inc. dt-bindings: mfd: Add binding for Netronix embedded controller mfd: Add base driver for Netronix embedded controller pwm: ntxec: Add driver for PWM function in Netronix EC rtc: New driver for RTC in Netronix embedded controller MAINTAINERS: Add entry for Netronix embedded controller ARM: dts: imx50-kobo-aura: Add Netronix embedded controller .../bindings/mfd/netronix,ntxec.yaml | 76 ++ .../devicetree/bindings/vendor-prefixes.yaml | 2 + MAINTAINERS | 9 + arch/arm/boot/dts/imx50-kobo-aura.dts | 16 +- drivers/mfd/Kconfig | 11 + drivers/mfd/Makefile | 1 + drivers/mfd/ntxec.c | 216 ++ drivers/pwm/Kconfig | 8 + drivers/pwm/Makefile | 1 + drivers/pwm/pwm-ntxec.c | 182 +++ drivers/rtc/Kconfig | 8 + drivers/rtc/Makefile | 1 + drivers/rtc/rtc-ntxec.c | 143 include/linux/mfd/ntxec.h | 34 +++ 14 files changed, 707 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/mfd/netronix,ntxec.yaml create mode 100644 drivers/mfd/ntxec.c create mode 100644 drivers/pwm/pwm-ntxec.c create mode 100644 drivers/rtc/rtc-ntxec.c create mode 100644 include/linux/mfd/ntxec.h -- 2.29.2
[PATCH v6 3/7] mfd: Add base driver for Netronix embedded controller
The Netronix embedded controller is a microcontroller found in some
e-book readers designed by the original design manufacturer Netronix,
Inc. It contains RTC, battery monitoring, system power management, and
PWM functionality.
This driver implements register access and version detection.
Third-party hardware documentation is available at:
https://github.com/neuschaefer/linux/wiki/Netronix-MSP430-embedded-controller
The EC supports interrupts, but the driver doesn't make use of them so
far.
Signed-off-by: Jonathan Neuschäfer
Acked-for-MFD-by: Lee Jones
---
v6:
- Add Lee Jones' ACK
v5:
- no changes
v4:
- https://lore.kernel.org/lkml/2020112739.1455132-4-j.neuschae...@gmx.net/
- include asm/unaligned.h after linux/*
- Use put_unaligned_be16 instead of open-coded big-endian packing
- Clarify that 0x90=0xff00 causes an error in downstream kernel too
- Add commas after non-sentinel positions
- ntxec.h: declare structs device and regmap
- Replace WARN_ON usage and add comments to explain errors
- Replace dev_alert with dev_warn when the result isn't handled
- Change subdevice registration error message to dev_err
- Declare ntxec_reg8 as returning __be16
- Restructure version detection code
- Spell out ODM
v3:
- https://lore.kernel.org/lkml/20200924192455.2484005-4-j.neuschae...@gmx.net/
- Add (EC) to CONFIG_MFD_NTXEC prompt
- Relicense as GPLv2 or later
- Add email address to copyright line
- remove empty lines in ntxec_poweroff and ntxec_restart functions
- Split long lines
- Remove 'Install ... handler' comments
- Make naming of struct i2c_client parameter consistent
- Remove struct ntxec_info
- Rework 'depends on' lines in Kconfig, hard-depend on I2C, select REGMAP_I2C
and
MFD_CORE
- Register subdevices via mfd_cells
- Move 8-bit register conversion to ntxec.h
v2:
- https://lore.kernel.org/lkml/20200905133230.1014581-4-j.neuschae...@gmx.net/
- Add a description of the device to the patch text
- Unify spelling as 'Netronix embedded controller'.
'Netronix' is the proper name of the manufacturer, but 'embedded controller'
is just a label that I have assigned to the device.
- Switch to regmap, avoid regmap use in poweroff and reboot handlers.
Inspired by cf84dc0bb40f4 ("mfd: rn5t618: Make restart handler atomic safe")
- Use a list of known-working firmware versions instead of checking for a
known-incompatible version
- Prefix registers with NTXEC_REG_
- Define register values as constants
- Various style cleanups as suggested by Lee Jones
- Don't align = signs in struct initializers [Uwe Kleine-König]
- Don't use dev_dbg for an error message
- Explain sleep in poweroff handler
- Remove (struct ntxec).client
- Switch to .probe_new in i2c driver
- Add .remove callback
- Make CONFIG_MFD_NTXEC a tristate option
---
drivers/mfd/Kconfig | 11 ++
drivers/mfd/Makefile | 1 +
drivers/mfd/ntxec.c | 216 ++
include/linux/mfd/ntxec.h | 34 ++
4 files changed, 262 insertions(+)
create mode 100644 drivers/mfd/ntxec.c
create mode 100644 include/linux/mfd/ntxec.h
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 8b99a13669bfc..d96751f884dc6 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -990,6 +990,17 @@ config MFD_VIPERBOARD
You need to select the mfd cell drivers separately.
The drivers do not support all features the board exposes.
+config MFD_NTXEC
+ tristate "Netronix embedded controller (EC)"
+ depends on OF || COMPILE_TEST
+ depends on I2C
+ select REGMAP_I2C
+ select MFD_CORE
+ help
+ Say yes here if you want to support the embedded controller found in
+ certain e-book readers designed by the original design manufacturer
+ Netronix.
+
config MFD_RETU
tristate "Nokia Retu and Tahvo multi-function device"
select MFD_CORE
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 1780019d24748..815c99b84019e 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -218,6 +218,7 @@ obj-$(CONFIG_MFD_INTEL_MSIC)+= intel_msic.o
obj-$(CONFIG_MFD_INTEL_PMC_BXT)+= intel_pmc_bxt.o
obj-$(CONFIG_MFD_PALMAS) += palmas.o
obj-$(CONFIG_MFD_VIPERBOARD)+= viperboard.o
+obj-$(CONFIG_MFD_NTXEC)+= ntxec.o
obj-$(CONFIG_MFD_RC5T583) += rc5t583.o rc5t583-irq.o
obj-$(CONFIG_MFD_RK808)+= rk808.o
obj-$(CONFIG_MFD_RN5T618) += rn5t618.o
diff --git a/drivers/mfd/ntxec.c b/drivers/mfd/ntxec.c
new file mode 100644
index 0..c1510711d7363
--- /dev/null
+++ b/drivers/mfd/ntxec.c
@@ -0,0 +1,216 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * The Netronix embedded controller is a microcontroller found in some
+ * e-book readers designed by the original design manufacturer Netronix, Inc.
+ * It contains RTC, battery monitoring, sy
[PATCH v6 1/7] dt-bindings: Add vendor prefix for Netronix, Inc.
Netronix, Inc. (http://www.netronixinc.com/) makes ebook reader board designs, which are for example used in Kobo and Tolino devices. An alternative prefix for Netronix would be "ntx", which is already used in code released by Netronix. It is shorter, but perhaps less clear. Signed-off-by: Jonathan Neuschäfer Acked-by: Rob Herring --- v4-v6: - No changes v3: - https://lore.kernel.org/lkml/20200924192455.2484005-2-j.neuschae...@gmx.net/ - Add Acked-by tag v2: - No changes --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 2735be1a84709..cbf28f992b71e 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -726,6 +726,8 @@ patternProperties: description: Broadcom Corporation (formerly NetLogic Microsystems) "^netron-dy,.*": description: Netron DY + "^netronix,.*": +description: Netronix, Inc. "^netxeon,.*": description: Shenzhen Netxeon Technology CO., LTD "^neweast,.*": -- 2.29.2
[PATCH v6 2/7] dt-bindings: mfd: Add binding for Netronix embedded controller
This EC is found in e-book readers of multiple brands (e.g. Kobo,
Tolino), and is typically implemented as a TI MSP430 microcontroller.
It controls different functions of the system, such as power on/off,
RTC, PWM for the backlight. The exact functionality provided can vary
between boards.
Signed-off-by: Jonathan Neuschäfer
Reviewed-by: Rob Herring
---
v5, v6:
- no changes
v4:
- Add R-b tag
v3:
- https://lore.kernel.org/lkml/20200924192455.2484005-3-j.neuschae...@gmx.net/
- Remove binding in text form patch description again
- Add additionalProperties: false
- Remove interrupt-controller property from example
- Merge pwm/rtc nodes into main node
v2:
- https://lore.kernel.org/lkml/20200905133230.1014581-3-j.neuschae...@gmx.net/
- Add the plaintext DT binding for comparison
---
.../bindings/mfd/netronix,ntxec.yaml | 76 +++
1 file changed, 76 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/netronix,ntxec.yaml
diff --git a/Documentation/devicetree/bindings/mfd/netronix,ntxec.yaml
b/Documentation/devicetree/bindings/mfd/netronix,ntxec.yaml
new file mode 100644
index 0..59a630025f52f
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/netronix,ntxec.yaml
@@ -0,0 +1,76 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/netronix,ntxec.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Netronix Embedded Controller
+
+maintainers:
+ - Jonathan Neuschäfer
+
+description: |
+ This EC is found in e-book readers of multiple brands (e.g. Kobo, Tolino),
and
+ is typically implemented as a TI MSP430 microcontroller.
+
+properties:
+ compatible:
+const: netronix,ntxec
+
+ reg:
+items:
+ - description: The I2C address of the EC
+
+ system-power-controller:
+type: boolean
+description: See
Documentation/devicetree/bindings/power/power-controller.txt
+
+ interrupts:
+minItems: 1
+description:
+ The EC can signal interrupts via a GPIO line
+
+ "#pwm-cells":
+const: 2
+description: |
+ Number of cells in a PWM specifier.
+
+ The following PWM channels are supported:
+- 0: The PWM channel controlled by registers 0xa1-0xa7
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+i2c {
+#address-cells = <1>;
+#size-cells = <0>;
+
+ec: embedded-controller@43 {
+pinctrl-names = "default";
+pinctrl-0 = <&pinctrl_ntxec>;
+
+compatible = "netronix,ntxec";
+reg = <0x43>;
+system-power-controller;
+interrupt-parent = <&gpio4>;
+interrupts = <11 IRQ_TYPE_EDGE_FALLING>;
+#pwm-cells = <2>;
+};
+};
+
+backlight {
+compatible = "pwm-backlight";
+pwms = <&ec 0 5>;
+power-supply = <&backlight_regulator>;
+};
+
+backlight_regulator: regulator-dummy {
+compatible = "regulator-fixed";
+regulator-name = "backlight";
+};
--
2.29.2
[PATCH v6 6/7] MAINTAINERS: Add entry for Netronix embedded controller
Let's make sure I'll notice when there are patches for the NTXEC drivers. Signed-off-by: Jonathan Neuschäfer --- v4-v6: - no changes v3: - https://lore.kernel.org/lkml/20200924192455.2484005-7-j.neuschae...@gmx.net/ - Remove pwm and rtc bindings v2: - https://lore.kernel.org/lkml/20200905144503.1067124-2-j.neuschae...@gmx.net/ - No changes --- MAINTAINERS | 9 + 1 file changed, 9 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 2daa6ee673f7f..9eedf3c1e1e09 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -12087,6 +12087,15 @@ F: include/net/netrom.h F: include/uapi/linux/netrom.h F: net/netrom/ +NETRONIX EMBEDDED CONTROLLER +M: Jonathan Neuschäfer +S: Maintained +F: Documentation/devicetree/bindings/mfd/netronix,ntxec.yaml +F: drivers/mfd/ntxec.c +F: drivers/pwm/pwm-ntxec.c +F: drivers/rtc/rtc-ntxec.c +F: include/linux/mfd/ntxec.h + NETRONOME ETHERNET DRIVERS M: Simon Horman R: Jakub Kicinski -- 2.29.2
[PATCH v6 5/7] rtc: New driver for RTC in Netronix embedded controller
With this driver, mainline Linux can keep its time and date in sync with
the vendor kernel.
Advanced functionality like alarm and automatic power-on is not yet
supported.
Signed-off-by: Jonathan Neuschäfer
Acked-by: Alexandre Belloni
---
v6:
- no changes
v5:
- Add Alexandre Belloni's A-b
- Use regmap_multi_reg_write
v4:
- https://lore.kernel.org/lkml/2020112739.1455132-6-j.neuschae...@gmx.net/
- Remove "driver" from Kconfig entry for consistency with most other entries
- Add missing MODULE_ALIAS line
- Give NTXEC_REG_READ_ macros longer names
- Solve the read tearing issue using Alexandre Belloni's algorithm
- Solve the write tearing issue using Uwe Kleine-König's algorithm
- Spell out ODM
v3:
- https://lore.kernel.org/lkml/20200924192455.2484005-6-j.neuschae...@gmx.net/
- Add email address to copyright line
- Remove OF compatible string and don't include linux/of_device.h
- Don't use a comma after sentinels
- Avoid ret |= ... pattern
- Move 8-bit register conversion to ntxec.h
- Relicense as GPLv2 or later
v2:
- https://lore.kernel.org/lkml/20200905133230.1014581-7-j.neuschae...@gmx.net/
- Rework top-of-file comment [Lee Jones]
- Sort the #include lines [Alexandre Belloni]
- don't align = signs in struct initializers [Uwe Kleine-König]
- Switch to regmap
- Fix register number used to read minutes and seconds
- Prefix registers with NTXEC_REG_
- Add help text to the Kconfig option
- Use devm_rtc_allocate_device and rtc_register_device, set ->range_min and
->range_max
---
drivers/rtc/Kconfig | 8 +++
drivers/rtc/Makefile| 1 +
drivers/rtc/rtc-ntxec.c | 143
3 files changed, 152 insertions(+)
create mode 100644 drivers/rtc/rtc-ntxec.c
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 65ad9d0b47ab1..fe009949728b3 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -1311,6 +1311,14 @@ config RTC_DRV_CROS_EC
This driver can also be built as a module. If so, the module
will be called rtc-cros-ec.
+config RTC_DRV_NTXEC
+ tristate "Netronix embedded controller RTC"
+ depends on MFD_NTXEC
+ help
+ Say yes here if you want to support the RTC functionality of the
+ embedded controller found in certain e-book readers designed by the
+ original design manufacturer Netronix.
+
comment "on-CPU RTC drivers"
config RTC_DRV_ASM9260
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index bfb57464118d0..5f2a7582b2780 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -111,6 +111,7 @@ obj-$(CONFIG_RTC_DRV_MT7622)+= rtc-mt7622.o
obj-$(CONFIG_RTC_DRV_MV) += rtc-mv.o
obj-$(CONFIG_RTC_DRV_MXC) += rtc-mxc.o
obj-$(CONFIG_RTC_DRV_MXC_V2) += rtc-mxc_v2.o
+obj-$(CONFIG_RTC_DRV_NTXEC)+= rtc-ntxec.o
obj-$(CONFIG_RTC_DRV_OMAP) += rtc-omap.o
obj-$(CONFIG_RTC_DRV_OPAL) += rtc-opal.o
obj-$(CONFIG_RTC_DRV_PALMAS) += rtc-palmas.o
diff --git a/drivers/rtc/rtc-ntxec.c b/drivers/rtc/rtc-ntxec.c
new file mode 100644
index 0..c7cff7802895b
--- /dev/null
+++ b/drivers/rtc/rtc-ntxec.c
@@ -0,0 +1,143 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * The Netronix embedded controller is a microcontroller found in some
+ * e-book readers designed by the original design manufacturer Netronix, Inc.
+ * It contains RTC, battery monitoring, system power management, and PWM
+ * functionality.
+ *
+ * This driver implements access to the RTC time and date.
+ *
+ * Copyright 2020 Jonathan Neuschäfer
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct ntxec_rtc {
+ struct device *dev;
+ struct ntxec *ec;
+};
+
+#define NTXEC_REG_WRITE_YEAR 0x10
+#define NTXEC_REG_WRITE_MONTH 0x11
+#define NTXEC_REG_WRITE_DAY0x12
+#define NTXEC_REG_WRITE_HOUR 0x13
+#define NTXEC_REG_WRITE_MINUTE 0x14
+#define NTXEC_REG_WRITE_SECOND 0x15
+
+#define NTXEC_REG_READ_YEAR_MONTH 0x20
+#define NTXEC_REG_READ_MDAY_HOUR 0x21
+#define NTXEC_REG_READ_MINUTE_SECOND 0x23
+
+static int ntxec_read_time(struct device *dev, struct rtc_time *tm)
+{
+ struct ntxec_rtc *rtc = dev_get_drvdata(dev);
+ unsigned int value;
+ int res;
+
+retry:
+ res = regmap_read(rtc->ec->regmap, NTXEC_REG_READ_MINUTE_SECOND,
&value);
+ if (res < 0)
+ return res;
+
+ tm->tm_min = value >> 8;
+ tm->tm_sec = value & 0xff;
+
+ res = regmap_read(rtc->ec->regmap, NTXEC_REG_READ_MDAY_HOUR, &value);
+ if (res < 0)
+ return res;
+
+ tm->tm_mday = value >> 8;
+ tm->tm_hour = value & 0xff;
+
+ res = regmap_read(rtc->ec->regmap, NTXEC_REG_READ_YEAR_MONTH, &value);
+ if (res < 0)
+ return res;
+
+ tm->tm_year = (value >> 8) + 100;
+ tm->tm_mon = (value &
[PATCH v6 7/7] ARM: dts: imx50-kobo-aura: Add Netronix embedded controller
Enable the Netronix EC on the Kobo Aura ebook reader.
Several features are still missing:
- Frontlight/backlight. The vendor kernel drives the frontlight LED
using the PWM output of the EC and an additional boost pin that
increases the brightness.
- Battery monitoring
- Interrupts for RTC alarm and low-battery events
Signed-off-by: Jonathan Neuschäfer
---
v5, v6:
- no changes
v4:
- Add 'grp' suffix to pinctrl node
v3:
- https://lore.kernel.org/lkml/20200925050818.2512375-1-j.neuschae...@gmx.net/
- Remove interrupt-controller property from embedded-controller node
- subnodes of embedded-controller node in to the main node
v2:
- https://lore.kernel.org/lkml/20200905144503.1067124-3-j.neuschae...@gmx.net/
- Fix pwm-cells property (should be 2, not 1)
---
arch/arm/boot/dts/imx50-kobo-aura.dts | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx50-kobo-aura.dts
b/arch/arm/boot/dts/imx50-kobo-aura.dts
index 97cfd970fe742..82ce8c43be867 100644
--- a/arch/arm/boot/dts/imx50-kobo-aura.dts
+++ b/arch/arm/boot/dts/imx50-kobo-aura.dts
@@ -143,10 +143,24 @@ &i2c3 {
pinctrl-0 = <&pinctrl_i2c3>;
status = "okay";
- /* TODO: embedded controller at 0x43 */
+ embedded-controller@43 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ec>;
+ compatible = "netronix,ntxec";
+ reg = <0x43>;
+ system-power-controller;
+ interrupts-extended = <&gpio4 11 IRQ_TYPE_EDGE_FALLING>;
+ #pwm-cells = <2>;
+ };
};
&iomuxc {
+ pinctrl_ec: ecgrp {
+ fsl,pins = <
+ MX50_PAD_CSPI_SS0__GPIO4_11 0x0 /* INT
*/
+ >;
+ };
+
pinctrl_gpiokeys: gpiokeysgrp {
fsl,pins = <
MX50_PAD_CSPI_MISO__GPIO4_100x0
--
2.29.2
[PATCH v6 4/7] pwm: ntxec: Add driver for PWM function in Netronix EC
The Netronix EC provides a PWM output which is used for the backlight
on some ebook readers. This patches adds a driver for the PWM output.
The .get_state callback is not implemented, because the PWM state can't
be read back from the hardware.
Signed-off-by: Jonathan Neuschäfer
---
v6:
- Move period / duty cycle setting code to a function
- Rename pwmchip_to_priv to ntxec_pwm_from_chip
- Set period and duty cycle only before enabling the output
- Mention that duty=0, enable=1 is assumed not to happen
- Interleave writes to the period and duty cycle registers, to minimize the
window of time that an inconsistent state is configured
v5:
- https://lore.kernel.org/lkml/20201201011513.1627028-5-j.neuschae...@gmx.net/
- Avoid truncation of period and duty cycle to 32 bits
- Make ntxec_pwm_ops const
- Use regmap_multi_reg_write
- Add comment about get_state to ntxec_pwm_ops
- Add comments about non-atomicity of (period, duty cycle) update
v4:
- https://lore.kernel.org/lkml/2020112739.1455132-5-j.neuschae...@gmx.net/
- Document hardware/driver limitations
- Only accept normal polarity
- Fix a typo ("zone" -> "zero")
- change MAX_PERIOD_NS to 0x * 125
- Clamp period to the maximum rather than returning an error
- Rename private struct pointer to priv
- Rearrage control flow in _probe to save a few lines and a temporary variable
- Add missing MODULE_ALIAS line
- Spell out ODM
v3:
- https://lore.kernel.org/lkml/20200924192455.2484005-5-j.neuschae...@gmx.net/
- Relicense as GPLv2 or later
- Add email address to copyright line
- Remove OF compatible string and don't include linux/of_device.h
- Fix bogus ?: in return line
- Don't use a comma after sentinels
- Avoid ret |= ... pattern
- Move 8-bit register conversion to ntxec.h
v2:
- https://lore.kernel.org/lkml/20200905133230.1014581-6-j.neuschae...@gmx.net/
- Various grammar and style improvements, as suggested by Uwe Kleine-König,
Lee Jones, and Alexandre Belloni
- Switch to regmap
- Prefix registers with NTXEC_REG_
- Add help text to the Kconfig option
- Use the .apply callback instead of the old API
- Add a #define for the time base (125ns)
- Don't change device state in .probe; this avoids multiple problems
- Rework division and overflow check logic to perform divisions in 32 bits
- Avoid setting duty cycle to zero, to work around a hardware quirk
---
drivers/pwm/Kconfig | 8 ++
drivers/pwm/Makefile| 1 +
drivers/pwm/pwm-ntxec.c | 182
3 files changed, 191 insertions(+)
create mode 100644 drivers/pwm/pwm-ntxec.c
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 63be5362fd3a5..815f329ed5b46 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -350,6 +350,14 @@ config PWM_MXS
To compile this driver as a module, choose M here: the module
will be called pwm-mxs.
+config PWM_NTXEC
+ tristate "Netronix embedded controller PWM support"
+ depends on MFD_NTXEC
+ help
+ Say yes here if you want to support the PWM output of the embedded
+ controller found in certain e-book readers designed by the original
+ design manufacturer Netronix.
+
config PWM_OMAP_DMTIMER
tristate "OMAP Dual-Mode Timer PWM support"
depends on OF
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index cbdcd55d69eef..1deb29e6ae8e5 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -32,6 +32,7 @@ obj-$(CONFIG_PWM_MESON) += pwm-meson.o
obj-$(CONFIG_PWM_MEDIATEK) += pwm-mediatek.o
obj-$(CONFIG_PWM_MTK_DISP) += pwm-mtk-disp.o
obj-$(CONFIG_PWM_MXS) += pwm-mxs.o
+obj-$(CONFIG_PWM_NTXEC)+= pwm-ntxec.o
obj-$(CONFIG_PWM_OMAP_DMTIMER) += pwm-omap-dmtimer.o
obj-$(CONFIG_PWM_PCA9685) += pwm-pca9685.o
obj-$(CONFIG_PWM_PXA) += pwm-pxa.o
diff --git a/drivers/pwm/pwm-ntxec.c b/drivers/pwm/pwm-ntxec.c
new file mode 100644
index 0..1db30a6caa3ad
--- /dev/null
+++ b/drivers/pwm/pwm-ntxec.c
@@ -0,0 +1,182 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * The Netronix embedded controller is a microcontroller found in some
+ * e-book readers designed by the original design manufacturer Netronix, Inc.
+ * It contains RTC, battery monitoring, system power management, and PWM
+ * functionality.
+ *
+ * This driver implements PWM output.
+ *
+ * Copyright 2020 Jonathan Neuschäfer
+ *
+ * Limitations:
+ * - The get_state callback is not implemented, because the current state of
+ * the PWM output can't be read back from the hardware.
+ * - The hardware can only generate normal polarity output.
+ * - The period and duty cycle can't be changed together in one atomic action.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct ntxec_pwm {
+ struct device *dev;
+ struct ntxec *ec;
+ struct pwm_chip chip;
+};
+
+static struct ntxec_pwm *
Re: [PATCH v6 5/7] rtc: New driver for RTC in Netronix embedded controller
On Tue, Dec 08, 2020 at 02:09:58AM +0100, Jonathan Neuschäfer wrote: > With this driver, mainline Linux can keep its time and date in sync with > the vendor kernel. > > Advanced functionality like alarm and automatic power-on is not yet > supported. > > Signed-off-by: Jonathan Neuschäfer > Acked-by: Alexandre Belloni > --- [...] > + return rtc_register_device(dev); This needs a respin due to the RTC API change (devm_ prefixed was added). Unless someone objects, I'll respin the whole series in a few days. Best regards, Jonathan Neuschäfer signature.asc Description: PGP signature
[PATCH] dt-bindings: timer: nuvoton: Clarify that interrupt of timer 0 should be specified
The NPCM750 Timer/Watchdoc Controller has multiple interrupt lines, connected to multiple timers. The driver uses timer 0 for timer interrupts, so the interrupt line corresponding to timer 0 should be specified in DT. I removed the mention of "flags for falling edge", because the timer controller uses high-level interrupts rather than falling-edge interrupts, and whether flags should be specified is up the interrupt controller's DT binding. Signed-off-by: Jonathan Neuschäfer --- .../devicetree/bindings/timer/nuvoton,npcm7xx-timer.txt| 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/timer/nuvoton,npcm7xx-timer.txt b/Documentation/devicetree/bindings/timer/nuvoton,npcm7xx-timer.txt index ea22dfe485bee..97258f1a1505b 100644 --- a/Documentation/devicetree/bindings/timer/nuvoton,npcm7xx-timer.txt +++ b/Documentation/devicetree/bindings/timer/nuvoton,npcm7xx-timer.txt @@ -6,8 +6,7 @@ timer counters. Required properties: - compatible : "nuvoton,npcm750-timer" for Poleg NPCM750. - reg : Offset and length of the register set for the device. -- interrupts : Contain the timer interrupt with flags for -falling edge. +- interrupts : Contain the timer interrupt of timer 0. - clocks : phandle of timer reference clock (usually a 25 MHz clock). Example: -- 2.29.2
Re: [PATCH] dt-bindings: timer: nuvoton: Clarify that interrupt of timer 0 should be specified
On Fri, Jan 08, 2021 at 01:28:03PM +0100, Jonathan Neuschäfer wrote: > The NPCM750 Timer/Watchdoc Controller has multiple interrupt lines, oops, that's a typo. > connected to multiple timers. The driver uses timer 0 for timer > interrupts, so the interrupt line corresponding to timer 0 should be > specified in DT. > > I removed the mention of "flags for falling edge", because the timer > controller uses high-level interrupts rather than falling-edge > interrupts, and whether flags should be specified is up the interrupt > controller's DT binding. > > Signed-off-by: Jonathan Neuschäfer > --- > .../devicetree/bindings/timer/nuvoton,npcm7xx-timer.txt| 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git > a/Documentation/devicetree/bindings/timer/nuvoton,npcm7xx-timer.txt > b/Documentation/devicetree/bindings/timer/nuvoton,npcm7xx-timer.txt > index ea22dfe485bee..97258f1a1505b 100644 > --- a/Documentation/devicetree/bindings/timer/nuvoton,npcm7xx-timer.txt > +++ b/Documentation/devicetree/bindings/timer/nuvoton,npcm7xx-timer.txt > @@ -6,8 +6,7 @@ timer counters. > Required properties: > - compatible : "nuvoton,npcm750-timer" for Poleg NPCM750. > - reg : Offset and length of the register set for the device. > -- interrupts : Contain the timer interrupt with flags for > -falling edge. > +- interrupts : Contain the timer interrupt of timer 0. > - clocks : phandle of timer reference clock (usually a 25 MHz > clock). > > Example: > -- > 2.29.2 > signature.asc Description: PGP signature
[PATCH v2] dt-bindings: timer: nuvoton: Clarify that interrupt of timer 0 should be specified
The NPCM750 Timer/Watchdog Controller has multiple interrupt lines, connected to multiple timers. The driver uses timer 0 for timer interrupts, so the interrupt line corresponding to timer 0 should be specified in DT. I removed the mention of "flags for falling edge", because the timer controller uses high-level interrupts rather than falling-edge interrupts, and whether flags should be specified is up the interrupt controller's DT binding. Signed-off-by: Jonathan Neuschäfer --- v2: - Fix a typo in the word "watchdog" --- .../devicetree/bindings/timer/nuvoton,npcm7xx-timer.txt| 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/timer/nuvoton,npcm7xx-timer.txt b/Documentation/devicetree/bindings/timer/nuvoton,npcm7xx-timer.txt index ea22dfe485bee..97258f1a1505b 100644 --- a/Documentation/devicetree/bindings/timer/nuvoton,npcm7xx-timer.txt +++ b/Documentation/devicetree/bindings/timer/nuvoton,npcm7xx-timer.txt @@ -6,8 +6,7 @@ timer counters. Required properties: - compatible : "nuvoton,npcm750-timer" for Poleg NPCM750. - reg : Offset and length of the register set for the device. -- interrupts : Contain the timer interrupt with flags for -falling edge. +- interrupts : Contain the timer interrupt of timer 0. - clocks : phandle of timer reference clock (usually a 25 MHz clock). Example: -- 2.29.2
[PATCH 1/2] dt-bindings: arm: Convert nuvoton,npcm750 binding to YAML
The general trend is to have devicetree bindings in YAML format, to allow automatic validation of bindings and devicetrees. Convert the NPCM SoC family's binding to YAML before it accumulates more entries. The nuvoton,npcm750-evb compatible string is introduced to keep the structure of the binding a little simpler. Signed-off-by: Jonathan Neuschäfer --- If someone else wants to be listed as the maintainer, please let me know. --- .../devicetree/bindings/arm/npcm/npcm.txt | 6 - .../devicetree/bindings/arm/npcm/npcm.yaml| 23 +++ 2 files changed, 23 insertions(+), 6 deletions(-) delete mode 100644 Documentation/devicetree/bindings/arm/npcm/npcm.txt create mode 100644 Documentation/devicetree/bindings/arm/npcm/npcm.yaml diff --git a/Documentation/devicetree/bindings/arm/npcm/npcm.txt b/Documentation/devicetree/bindings/arm/npcm/npcm.txt deleted file mode 100644 index 2d87d9ecea85b..0 --- a/Documentation/devicetree/bindings/arm/npcm/npcm.txt +++ /dev/null @@ -1,6 +0,0 @@ -NPCM Platforms Device Tree Bindings -NPCM750 SoC -Required root node properties: - - compatible = "nuvoton,npcm750"; - diff --git a/Documentation/devicetree/bindings/arm/npcm/npcm.yaml b/Documentation/devicetree/bindings/arm/npcm/npcm.yaml new file mode 100644 index 0..e2cf790a2c63e --- /dev/null +++ b/Documentation/devicetree/bindings/arm/npcm/npcm.yaml @@ -0,0 +1,23 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/npcm.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NPCM Platforms Device Tree Bindings + +maintainers: + - Jonathan Neuschäfer + +properties: + $nodename: +const: '/' + compatible: +oneOf: + - description: NPCM750 based boards +items: + - enum: +- nuvoton,npcm750-evb # NPCM750 evaluation board + - const: nuvoton,npcm750 + +additionalProperties: true -- 2.29.2
[PATCH 2/2] ARM: dts: Add board-specific compatible string to npcm750-evb devicetree
According to the revised binding, the devicetree needs a board-specific
compatible string.
Signed-off-by: Jonathan Neuschäfer
---
arch/arm/boot/dts/nuvoton-npcm750-evb.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/nuvoton-npcm750-evb.dts
b/arch/arm/boot/dts/nuvoton-npcm750-evb.dts
index 9f13d08f5804e..dea3dbc4a6a52 100644
--- a/arch/arm/boot/dts/nuvoton-npcm750-evb.dts
+++ b/arch/arm/boot/dts/nuvoton-npcm750-evb.dts
@@ -9,7 +9,7 @@
/ {
model = "Nuvoton npcm750 Development Board (Device Tree)";
- compatible = "nuvoton,npcm750";
+ compatible = "nuvoton,npcm750-evb", "nuvoton,npcm750";
aliases {
ethernet2 = &gmac0;
--
2.29.2
[PATCH v7 0/7] Netronix embedded controller driver for Kobo and Tolino ebook readers
This patchset adds basic support for the embedded controller found on older ebook reader boards designed by/with the ODM Netronix Inc.[1] and sold by Kobo or Tolino, for example the Kobo Aura and the Tolino Shine. These drivers are based on information contained in the vendor kernel sources, but in order to all information in a single place, I documented the register interface of the EC on GitHub[2]. [1]: http://www.netronixinc.com/products.aspx?ID=1 [2]: https://github.com/neuschaefer/linux/wiki/Netronix-MSP430-embedded-controller v7: - Adjust the RTC patch to a change in the RTC API: rtc_register_device is now devm_rtc_register_device. - Add a #define for the known firmware version (0xd726). Lee Jones suggested doing this in a follow-up patch, but since I'm respinning the series anyway, I'm doing it here. v6: - Additional cleanups in the PWM driver - Added Lee Jones' ACK to the MFD driver patch v5: - https://lore.kernel.org/lkml/20201201011513.1627028-1-j.neuschae...@gmx.net/ - Avoid truncation of PWM period and duty cycle to 32 bits - A few cleanups and additional comments in the PWM driver - Use regmap_multi_reg_write v4: - https://lore.kernel.org/lkml/2020112739.1455132-1-j.neuschae...@gmx.net/ - Spell out ODM (original design manufacturer) - Solve corner cases in the RTC driver - Clean up use of log levels vs. error codes - Add more comments explaining some peculiarities - Add missing MODULE_ALIAS lines - Various other cleanups v3: - https://lore.kernel.org/lkml/20200924192455.2484005-1-j.neuschae...@gmx.net/ - A few code cleanups - A few devicetree related cleanups - PWM and RTC functionality were moved from subnodes in the devicetree to the main node. This also means that the subdrivers no longer need DT compatible strings, but are instead loaded via the mfd_cell mechanism. - The drivers are now published under GPLv2-or-later rather than GPLv2-only. v2: - https://lore.kernel.org/lkml/20200905133230.1014581-1-j.neuschae...@gmx.net/ - Moved txt DT bindings to patch descriptions and removed patch 1/10 "DT bindings in plain text format" - New patch 7/10 "rtc: Introduce RTC_TIMESTAMP_END_2255" - Rebased on 5.9-rc3 - Various other changes which are documented in each patch v1: - https://lore.kernel.org/lkml/20200620223915.1311485-1-j.neuschae...@gmx.net/ Jonathan Neuschäfer (7): dt-bindings: Add vendor prefix for Netronix, Inc. dt-bindings: mfd: Add binding for Netronix embedded controller mfd: Add base driver for Netronix embedded controller pwm: ntxec: Add driver for PWM function in Netronix EC rtc: New driver for RTC in Netronix embedded controller MAINTAINERS: Add entry for Netronix embedded controller ARM: dts: imx50-kobo-aura: Add Netronix embedded controller .../bindings/mfd/netronix,ntxec.yaml | 76 ++ .../devicetree/bindings/vendor-prefixes.yaml | 2 + MAINTAINERS | 9 + arch/arm/boot/dts/imx50-kobo-aura.dts | 16 +- drivers/mfd/Kconfig | 11 + drivers/mfd/Makefile | 1 + drivers/mfd/ntxec.c | 216 ++ drivers/pwm/Kconfig | 8 + drivers/pwm/Makefile | 1 + drivers/pwm/pwm-ntxec.c | 182 +++ drivers/rtc/Kconfig | 8 + drivers/rtc/Makefile | 1 + drivers/rtc/rtc-ntxec.c | 143 include/linux/mfd/ntxec.h | 37 +++ 14 files changed, 710 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/mfd/netronix,ntxec.yaml create mode 100644 drivers/mfd/ntxec.c create mode 100644 drivers/pwm/pwm-ntxec.c create mode 100644 drivers/rtc/rtc-ntxec.c create mode 100644 include/linux/mfd/ntxec.h -- 2.29.2
[PATCH v7 3/7] mfd: Add base driver for Netronix embedded controller
The Netronix embedded controller is a microcontroller found in some
e-book readers designed by the original design manufacturer Netronix,
Inc. It contains RTC, battery monitoring, system power management, and
PWM functionality.
This driver implements register access and version detection.
Third-party hardware documentation is available at:
https://github.com/neuschaefer/linux/wiki/Netronix-MSP430-embedded-controller
The EC supports interrupts, but the driver doesn't make use of them so
far.
Signed-off-by: Jonathan Neuschäfer
Acked-for-MFD-by: Lee Jones
---
v7:
- Add #define for version number (suggested by Lee Jones).
v6:
- https://lore.kernel.org/lkml/20201208011000.3060239-4-j.neuschae...@gmx.net/
- Add Lee Jones' ACK
v5:
- no changes
v4:
- https://lore.kernel.org/lkml/2020112739.1455132-4-j.neuschae...@gmx.net/
- include asm/unaligned.h after linux/*
- Use put_unaligned_be16 instead of open-coded big-endian packing
- Clarify that 0x90=0xff00 causes an error in downstream kernel too
- Add commas after non-sentinel positions
- ntxec.h: declare structs device and regmap
- Replace WARN_ON usage and add comments to explain errors
- Replace dev_alert with dev_warn when the result isn't handled
- Change subdevice registration error message to dev_err
- Declare ntxec_reg8 as returning __be16
- Restructure version detection code
- Spell out ODM
v3:
- https://lore.kernel.org/lkml/20200924192455.2484005-4-j.neuschae...@gmx.net/
- Add (EC) to CONFIG_MFD_NTXEC prompt
- Relicense as GPLv2 or later
- Add email address to copyright line
- remove empty lines in ntxec_poweroff and ntxec_restart functions
- Split long lines
- Remove 'Install ... handler' comments
- Make naming of struct i2c_client parameter consistent
- Remove struct ntxec_info
- Rework 'depends on' lines in Kconfig, hard-depend on I2C, select REGMAP_I2C
and
MFD_CORE
- Register subdevices via mfd_cells
- Move 8-bit register conversion to ntxec.h
v2:
- https://lore.kernel.org/lkml/20200905133230.1014581-4-j.neuschae...@gmx.net/
- Add a description of the device to the patch text
- Unify spelling as 'Netronix embedded controller'.
'Netronix' is the proper name of the manufacturer, but 'embedded controller'
is just a label that I have assigned to the device.
- Switch to regmap, avoid regmap use in poweroff and reboot handlers.
Inspired by cf84dc0bb40f4 ("mfd: rn5t618: Make restart handler atomic safe")
- Use a list of known-working firmware versions instead of checking for a
known-incompatible version
- Prefix registers with NTXEC_REG_
- Define register values as constants
- Various style cleanups as suggested by Lee Jones
- Don't align = signs in struct initializers [Uwe Kleine-König]
- Don't use dev_dbg for an error message
- Explain sleep in poweroff handler
- Remove (struct ntxec).client
- Switch to .probe_new in i2c driver
- Add .remove callback
- Make CONFIG_MFD_NTXEC a tristate option
---
drivers/mfd/Kconfig | 11 ++
drivers/mfd/Makefile | 1 +
drivers/mfd/ntxec.c | 216 ++
include/linux/mfd/ntxec.h | 37 +++
4 files changed, 265 insertions(+)
create mode 100644 drivers/mfd/ntxec.c
create mode 100644 include/linux/mfd/ntxec.h
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index bdfce7b156216..4280bcd47ec7d 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -976,6 +976,17 @@ config MFD_VIPERBOARD
You need to select the mfd cell drivers separately.
The drivers do not support all features the board exposes.
+config MFD_NTXEC
+ tristate "Netronix embedded controller (EC)"
+ depends on OF || COMPILE_TEST
+ depends on I2C
+ select REGMAP_I2C
+ select MFD_CORE
+ help
+ Say yes here if you want to support the embedded controller found in
+ certain e-book readers designed by the original design manufacturer
+ Netronix.
+
config MFD_RETU
tristate "Nokia Retu and Tahvo multi-function device"
select MFD_CORE
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 14fdb188af022..948a3bf8e3e57 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -219,6 +219,7 @@ obj-$(CONFIG_MFD_INTEL_PMC_BXT) += intel_pmc_bxt.o
obj-$(CONFIG_MFD_INTEL_PMT)+= intel_pmt.o
obj-$(CONFIG_MFD_PALMAS) += palmas.o
obj-$(CONFIG_MFD_VIPERBOARD)+= viperboard.o
+obj-$(CONFIG_MFD_NTXEC)+= ntxec.o
obj-$(CONFIG_MFD_RC5T583) += rc5t583.o rc5t583-irq.o
obj-$(CONFIG_MFD_RK808)+= rk808.o
obj-$(CONFIG_MFD_RN5T618) += rn5t618.o
diff --git a/drivers/mfd/ntxec.c b/drivers/mfd/ntxec.c
new file mode 100644
index 0..22ed2ef0669cb
--- /dev/null
+++ b/drivers/mfd/ntxec.c
@@ -0,0 +1,216 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * The Netronix embedded controller is a microcontroller found i
[PATCH v7 1/7] dt-bindings: Add vendor prefix for Netronix, Inc.
Netronix, Inc. (http://www.netronixinc.com/) makes ebook reader board designs, which are for example used in Kobo and Tolino devices. An alternative prefix for Netronix would be "ntx", which is already used in code released by Netronix. It is shorter, but perhaps less clear. Signed-off-by: Jonathan Neuschäfer Acked-by: Rob Herring --- v4-v7: - No changes v3: - https://lore.kernel.org/lkml/20200924192455.2484005-2-j.neuschae...@gmx.net/ - Add Acked-by tag v2: - No changes --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 041ae90b0d8fd..4d36b8173b568 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -756,6 +756,8 @@ patternProperties: description: Broadcom Corporation (formerly NetLogic Microsystems) "^netron-dy,.*": description: Netron DY + "^netronix,.*": +description: Netronix, Inc. "^netxeon,.*": description: Shenzhen Netxeon Technology CO., LTD "^neweast,.*": -- 2.29.2
[PATCH v7 2/7] dt-bindings: mfd: Add binding for Netronix embedded controller
This EC is found in e-book readers of multiple brands (e.g. Kobo,
Tolino), and is typically implemented as a TI MSP430 microcontroller.
It controls different functions of the system, such as power on/off,
RTC, PWM for the backlight. The exact functionality provided can vary
between boards.
Signed-off-by: Jonathan Neuschäfer
Reviewed-by: Rob Herring
---
v5-v7:
- no changes
v4:
- Add R-b tag
v3:
- https://lore.kernel.org/lkml/20200924192455.2484005-3-j.neuschae...@gmx.net/
- Remove binding in text form patch description again
- Add additionalProperties: false
- Remove interrupt-controller property from example
- Merge pwm/rtc nodes into main node
v2:
- https://lore.kernel.org/lkml/20200905133230.1014581-3-j.neuschae...@gmx.net/
- Add the plaintext DT binding for comparison
---
.../bindings/mfd/netronix,ntxec.yaml | 76 +++
1 file changed, 76 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/netronix,ntxec.yaml
diff --git a/Documentation/devicetree/bindings/mfd/netronix,ntxec.yaml
b/Documentation/devicetree/bindings/mfd/netronix,ntxec.yaml
new file mode 100644
index 0..59a630025f52f
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/netronix,ntxec.yaml
@@ -0,0 +1,76 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/netronix,ntxec.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Netronix Embedded Controller
+
+maintainers:
+ - Jonathan Neuschäfer
+
+description: |
+ This EC is found in e-book readers of multiple brands (e.g. Kobo, Tolino),
and
+ is typically implemented as a TI MSP430 microcontroller.
+
+properties:
+ compatible:
+const: netronix,ntxec
+
+ reg:
+items:
+ - description: The I2C address of the EC
+
+ system-power-controller:
+type: boolean
+description: See
Documentation/devicetree/bindings/power/power-controller.txt
+
+ interrupts:
+minItems: 1
+description:
+ The EC can signal interrupts via a GPIO line
+
+ "#pwm-cells":
+const: 2
+description: |
+ Number of cells in a PWM specifier.
+
+ The following PWM channels are supported:
+- 0: The PWM channel controlled by registers 0xa1-0xa7
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+i2c {
+#address-cells = <1>;
+#size-cells = <0>;
+
+ec: embedded-controller@43 {
+pinctrl-names = "default";
+pinctrl-0 = <&pinctrl_ntxec>;
+
+compatible = "netronix,ntxec";
+reg = <0x43>;
+system-power-controller;
+interrupt-parent = <&gpio4>;
+interrupts = <11 IRQ_TYPE_EDGE_FALLING>;
+#pwm-cells = <2>;
+};
+};
+
+backlight {
+compatible = "pwm-backlight";
+pwms = <&ec 0 5>;
+power-supply = <&backlight_regulator>;
+};
+
+backlight_regulator: regulator-dummy {
+compatible = "regulator-fixed";
+regulator-name = "backlight";
+};
--
2.29.2
[PATCH v7 6/7] MAINTAINERS: Add entry for Netronix embedded controller
Let's make sure I'll notice when there are patches for the NTXEC drivers. Signed-off-by: Jonathan Neuschäfer --- v4-v7: - no changes v3: - https://lore.kernel.org/lkml/20200924192455.2484005-7-j.neuschae...@gmx.net/ - Remove pwm and rtc bindings v2: - https://lore.kernel.org/lkml/20200905144503.1067124-2-j.neuschae...@gmx.net/ - No changes --- MAINTAINERS | 9 + 1 file changed, 9 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 546aa66428c9f..0c6e739e3afb7 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -12298,6 +12298,15 @@ F: include/net/netrom.h F: include/uapi/linux/netrom.h F: net/netrom/ +NETRONIX EMBEDDED CONTROLLER +M: Jonathan Neuschäfer +S: Maintained +F: Documentation/devicetree/bindings/mfd/netronix,ntxec.yaml +F: drivers/mfd/ntxec.c +F: drivers/pwm/pwm-ntxec.c +F: drivers/rtc/rtc-ntxec.c +F: include/linux/mfd/ntxec.h + NETRONOME ETHERNET DRIVERS M: Simon Horman R: Jakub Kicinski -- 2.29.2
[PATCH v7 4/7] pwm: ntxec: Add driver for PWM function in Netronix EC
The Netronix EC provides a PWM output which is used for the backlight
on some ebook readers. This patches adds a driver for the PWM output.
The .get_state callback is not implemented, because the PWM state can't
be read back from the hardware.
Signed-off-by: Jonathan Neuschäfer
---
v7:
- no changes
v6:
- https://lore.kernel.org/lkml/20201208011000.3060239-5-j.neuschae...@gmx.net/
- Move period / duty cycle setting code to a function
- Rename pwmchip_to_priv to ntxec_pwm_from_chip
- Set period and duty cycle only before enabling the output
- Mention that duty=0, enable=1 is assumed not to happen
- Interleave writes to the period and duty cycle registers, to minimize the
window of time that an inconsistent state is configured
v5:
- https://lore.kernel.org/lkml/20201201011513.1627028-5-j.neuschae...@gmx.net/
- Avoid truncation of period and duty cycle to 32 bits
- Make ntxec_pwm_ops const
- Use regmap_multi_reg_write
- Add comment about get_state to ntxec_pwm_ops
- Add comments about non-atomicity of (period, duty cycle) update
v4:
- https://lore.kernel.org/lkml/2020112739.1455132-5-j.neuschae...@gmx.net/
- Document hardware/driver limitations
- Only accept normal polarity
- Fix a typo ("zone" -> "zero")
- change MAX_PERIOD_NS to 0x * 125
- Clamp period to the maximum rather than returning an error
- Rename private struct pointer to priv
- Rearrage control flow in _probe to save a few lines and a temporary variable
- Add missing MODULE_ALIAS line
- Spell out ODM
v3:
- https://lore.kernel.org/lkml/20200924192455.2484005-5-j.neuschae...@gmx.net/
- Relicense as GPLv2 or later
- Add email address to copyright line
- Remove OF compatible string and don't include linux/of_device.h
- Fix bogus ?: in return line
- Don't use a comma after sentinels
- Avoid ret |= ... pattern
- Move 8-bit register conversion to ntxec.h
v2:
- https://lore.kernel.org/lkml/20200905133230.1014581-6-j.neuschae...@gmx.net/
- Various grammar and style improvements, as suggested by Uwe Kleine-König,
Lee Jones, and Alexandre Belloni
- Switch to regmap
- Prefix registers with NTXEC_REG_
- Add help text to the Kconfig option
- Use the .apply callback instead of the old API
- Add a #define for the time base (125ns)
- Don't change device state in .probe; this avoids multiple problems
- Rework division and overflow check logic to perform divisions in 32 bits
- Avoid setting duty cycle to zero, to work around a hardware quirk
---
drivers/pwm/Kconfig | 8 ++
drivers/pwm/Makefile| 1 +
drivers/pwm/pwm-ntxec.c | 182
3 files changed, 191 insertions(+)
create mode 100644 drivers/pwm/pwm-ntxec.c
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 0937e1c047acb..a2830b8832b97 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -393,6 +393,14 @@ config PWM_MXS
To compile this driver as a module, choose M here: the module
will be called pwm-mxs.
+config PWM_NTXEC
+ tristate "Netronix embedded controller PWM support"
+ depends on MFD_NTXEC
+ help
+ Say yes here if you want to support the PWM output of the embedded
+ controller found in certain e-book readers designed by the original
+ design manufacturer Netronix.
+
config PWM_OMAP_DMTIMER
tristate "OMAP Dual-Mode Timer PWM support"
depends on OF
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index 18b89d7fd092a..7d97eb595bbef 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -35,6 +35,7 @@ obj-$(CONFIG_PWM_MESON) += pwm-meson.o
obj-$(CONFIG_PWM_MEDIATEK) += pwm-mediatek.o
obj-$(CONFIG_PWM_MTK_DISP) += pwm-mtk-disp.o
obj-$(CONFIG_PWM_MXS) += pwm-mxs.o
+obj-$(CONFIG_PWM_NTXEC)+= pwm-ntxec.o
obj-$(CONFIG_PWM_OMAP_DMTIMER) += pwm-omap-dmtimer.o
obj-$(CONFIG_PWM_PCA9685) += pwm-pca9685.o
obj-$(CONFIG_PWM_PXA) += pwm-pxa.o
diff --git a/drivers/pwm/pwm-ntxec.c b/drivers/pwm/pwm-ntxec.c
new file mode 100644
index 0..1db30a6caa3ad
--- /dev/null
+++ b/drivers/pwm/pwm-ntxec.c
@@ -0,0 +1,182 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * The Netronix embedded controller is a microcontroller found in some
+ * e-book readers designed by the original design manufacturer Netronix, Inc.
+ * It contains RTC, battery monitoring, system power management, and PWM
+ * functionality.
+ *
+ * This driver implements PWM output.
+ *
+ * Copyright 2020 Jonathan Neuschäfer
+ *
+ * Limitations:
+ * - The get_state callback is not implemented, because the current state of
+ * the PWM output can't be read back from the hardware.
+ * - The hardware can only generate normal polarity output.
+ * - The period and duty cycle can't be changed together in one atomic action.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct ntxec_pwm {
+ s
[PATCH v7 5/7] rtc: New driver for RTC in Netronix embedded controller
With this driver, mainline Linux can keep its time and date in sync with
the vendor kernel.
Advanced functionality like alarm and automatic power-on is not yet
supported.
Signed-off-by: Jonathan Neuschäfer
Acked-by: Alexandre Belloni
---
v7:
- Adjust to recent RTC API change (rtc_register_device ->
devm_rtc_register_device)
v6:
- no changes
v5:
- https://lore.kernel.org/lkml/20201201011513.1627028-6-j.neuschae...@gmx.net/
- Add Alexandre Belloni's A-b
- Use regmap_multi_reg_write
v4:
- https://lore.kernel.org/lkml/2020112739.1455132-6-j.neuschae...@gmx.net/
- Remove "driver" from Kconfig entry for consistency with most other entries
- Add missing MODULE_ALIAS line
- Give NTXEC_REG_READ_ macros longer names
- Solve the read tearing issue using Alexandre Belloni's algorithm
- Solve the write tearing issue using Uwe Kleine-König's algorithm
- Spell out ODM
v3:
- https://lore.kernel.org/lkml/20200924192455.2484005-6-j.neuschae...@gmx.net/
- Add email address to copyright line
- Remove OF compatible string and don't include linux/of_device.h
- Don't use a comma after sentinels
- Avoid ret |= ... pattern
- Move 8-bit register conversion to ntxec.h
- Relicense as GPLv2 or later
v2:
- https://lore.kernel.org/lkml/20200905133230.1014581-7-j.neuschae...@gmx.net/
- Rework top-of-file comment [Lee Jones]
- Sort the #include lines [Alexandre Belloni]
- don't align = signs in struct initializers [Uwe Kleine-König]
- Switch to regmap
- Fix register number used to read minutes and seconds
- Prefix registers with NTXEC_REG_
- Add help text to the Kconfig option
- Use devm_rtc_allocate_device and rtc_register_device, set ->range_min and
->range_max
---
drivers/rtc/Kconfig | 8 +++
drivers/rtc/Makefile| 1 +
drivers/rtc/rtc-ntxec.c | 143
3 files changed, 152 insertions(+)
create mode 100644 drivers/rtc/rtc-ntxec.c
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 6123f9f4fbc90..d49cf387add14 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -1315,6 +1315,14 @@ config RTC_DRV_CROS_EC
This driver can also be built as a module. If so, the module
will be called rtc-cros-ec.
+config RTC_DRV_NTXEC
+ tristate "Netronix embedded controller RTC"
+ depends on MFD_NTXEC
+ help
+ Say yes here if you want to support the RTC functionality of the
+ embedded controller found in certain e-book readers designed by the
+ original design manufacturer Netronix.
+
comment "on-CPU RTC drivers"
config RTC_DRV_ASM9260
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index bb8f319b09fbf..92c26eafe70ce 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -110,6 +110,7 @@ obj-$(CONFIG_RTC_DRV_MT7622)+= rtc-mt7622.o
obj-$(CONFIG_RTC_DRV_MV) += rtc-mv.o
obj-$(CONFIG_RTC_DRV_MXC) += rtc-mxc.o
obj-$(CONFIG_RTC_DRV_MXC_V2) += rtc-mxc_v2.o
+obj-$(CONFIG_RTC_DRV_NTXEC)+= rtc-ntxec.o
obj-$(CONFIG_RTC_DRV_OMAP) += rtc-omap.o
obj-$(CONFIG_RTC_DRV_OPAL) += rtc-opal.o
obj-$(CONFIG_RTC_DRV_PALMAS) += rtc-palmas.o
diff --git a/drivers/rtc/rtc-ntxec.c b/drivers/rtc/rtc-ntxec.c
new file mode 100644
index 0..09cdbcab8eff9
--- /dev/null
+++ b/drivers/rtc/rtc-ntxec.c
@@ -0,0 +1,143 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * The Netronix embedded controller is a microcontroller found in some
+ * e-book readers designed by the original design manufacturer Netronix, Inc.
+ * It contains RTC, battery monitoring, system power management, and PWM
+ * functionality.
+ *
+ * This driver implements access to the RTC time and date.
+ *
+ * Copyright 2020 Jonathan Neuschäfer
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct ntxec_rtc {
+ struct device *dev;
+ struct ntxec *ec;
+};
+
+#define NTXEC_REG_WRITE_YEAR 0x10
+#define NTXEC_REG_WRITE_MONTH 0x11
+#define NTXEC_REG_WRITE_DAY0x12
+#define NTXEC_REG_WRITE_HOUR 0x13
+#define NTXEC_REG_WRITE_MINUTE 0x14
+#define NTXEC_REG_WRITE_SECOND 0x15
+
+#define NTXEC_REG_READ_YEAR_MONTH 0x20
+#define NTXEC_REG_READ_MDAY_HOUR 0x21
+#define NTXEC_REG_READ_MINUTE_SECOND 0x23
+
+static int ntxec_read_time(struct device *dev, struct rtc_time *tm)
+{
+ struct ntxec_rtc *rtc = dev_get_drvdata(dev);
+ unsigned int value;
+ int res;
+
+retry:
+ res = regmap_read(rtc->ec->regmap, NTXEC_REG_READ_MINUTE_SECOND,
&value);
+ if (res < 0)
+ return res;
+
+ tm->tm_min = value >> 8;
+ tm->tm_sec = value & 0xff;
+
+ res = regmap_read(rtc->ec->regmap, NTXEC_REG_READ_MDAY_HOUR, &value);
+ if (res < 0)
+ return res;
+
+ tm->tm_mday = value >> 8;
+ tm->tm_hour = value & 0xff;
+
+ res = regmap_read(rtc->ec->regmap, NTXEC_
[PATCH v7 7/7] ARM: dts: imx50-kobo-aura: Add Netronix embedded controller
Enable the Netronix EC on the Kobo Aura ebook reader.
Several features are still missing:
- Frontlight/backlight. The vendor kernel drives the frontlight LED
using the PWM output of the EC and an additional boost pin that
increases the brightness.
- Battery monitoring
- Interrupts for RTC alarm and low-battery events
Signed-off-by: Jonathan Neuschäfer
---
v5-v7:
- no changes
v4:
- https://lore.kernel.org/lkml/20201123000913.1506944-1-j.neuschae...@gmx.net/
- Add 'grp' suffix to pinctrl node
v3:
- https://lore.kernel.org/lkml/20200925050818.2512375-1-j.neuschae...@gmx.net/
- Remove interrupt-controller property from embedded-controller node
- subnodes of embedded-controller node in to the main node
v2:
- https://lore.kernel.org/lkml/20200905144503.1067124-3-j.neuschae...@gmx.net/
- Fix pwm-cells property (should be 2, not 1)
---
arch/arm/boot/dts/imx50-kobo-aura.dts | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx50-kobo-aura.dts
b/arch/arm/boot/dts/imx50-kobo-aura.dts
index 97cfd970fe742..82ce8c43be867 100644
--- a/arch/arm/boot/dts/imx50-kobo-aura.dts
+++ b/arch/arm/boot/dts/imx50-kobo-aura.dts
@@ -143,10 +143,24 @@ &i2c3 {
pinctrl-0 = <&pinctrl_i2c3>;
status = "okay";
- /* TODO: embedded controller at 0x43 */
+ embedded-controller@43 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ec>;
+ compatible = "netronix,ntxec";
+ reg = <0x43>;
+ system-power-controller;
+ interrupts-extended = <&gpio4 11 IRQ_TYPE_EDGE_FALLING>;
+ #pwm-cells = <2>;
+ };
};
&iomuxc {
+ pinctrl_ec: ecgrp {
+ fsl,pins = <
+ MX50_PAD_CSPI_SS0__GPIO4_11 0x0 /* INT
*/
+ >;
+ };
+
pinctrl_gpiokeys: gpiokeysgrp {
fsl,pins = <
MX50_PAD_CSPI_MISO__GPIO4_100x0
--
2.29.2
Re: [PATCH v7 3/7] mfd: Add base driver for Netronix embedded controller
On Tue, Jan 12, 2021 at 08:36:49PM +0100, Andreas Kemnade wrote:
> On Sat, 9 Jan 2021 19:02:16 +0100
> Jonathan Neuschäfer wrote:
[...]
> > +static const struct of_device_id of_ntxec_match_table[] = {
> > + { .compatible = "netronix,ntxec", },
> > + {}
> > +};
> > +
> MODULE_DEVICE_TABLE?
Yes, good idea.
> > +static struct i2c_driver ntxec_driver = {
> > + .driver = {
> > + .name = "ntxec",
> > + .of_match_table = of_ntxec_match_table,
> > + },
> > + .probe_new = ntxec_probe,
> > + .remove = ntxec_remove,
> > +};
> > +module_i2c_driver(ntxec_driver);
>
> MODULE_LICENSE()?
>
> modpost moans about that here.
I forgot those. Thanks for noticing.
I'll add the MODULE_ lines in v8.
Thanks,
Jonathan
signature.asc
Description: PGP signature
Re: [PATCH v7 4/7] pwm: ntxec: Add driver for PWM function in Netronix EC
On Wed, Jan 13, 2021 at 11:46:45PM +0100, Andreas Kemnade wrote: > On Tue, 12 Jan 2021 20:39:02 +0100 > Andreas Kemnade wrote: > > [...] > > > +static int ntxec_pwm_probe(struct platform_device *pdev) [...] > > Hmm, I needed > > chip->dev = &pdev->dev.parent to use the backlight example > > in patch 2/7. > > Not sure what the correct solution is. Maybe the pwm deserves its own > > devicetree node. > > > probably just assigning the node from the parent. > >pdev->dev.of_node = pdev->dev.parent->of_node; Ah, good catch, thanks. This works, I'll add it to the next version. Jonathan signature.asc Description: PGP signature
checkpatch.pl: Bogus case of DT_SPLIT_BINDING_PATCH
Hi, I've encountered a case where the DT_SPLIT_BINDING_PATCH warning was emitted even though I didn't change anything outside of Documentation/ devicetree/bindings. I just converted a binding from plain text to YAML. Here's a transcript of checkpatch (from Linux 5.11-rc1)'s output: $ scripts/checkpatch.pl --strict patches-wpcm/0001-dt-bindings-arm-Convert-nuvoton-npcm750-binding-to-Y.patch WARNING: added, moved or deleted file(s), does MAINTAINERS need updating? #31: deleted file mode 100644 WARNING: DT binding docs and includes should be a separate patch. See: Documentation/devicetree/bindings/submitting-patches.rst WARNING: DT binding docs and includes should be a separate patch. See: Documentation/devicetree/bindings/submitting-patches.rst total: 0 errors, 3 warnings, 0 checks, 21 lines checked NOTE: For some of the reported defects, checkpatch may be able to mechanically convert to the typical style using --fix or --fix-inplace. patches-wpcm/0001-dt-bindings-arm-Convert-nuvoton-npcm750-binding-to-Y.patch has style problems, please review. NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. I attached the patch, for reference. Best regards, Jonathan Neuschäfer From 3aaf23345633070909e23a05a9f92748e445b3b3 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jonathan=20Neusch=C3=A4fer?= Date: Mon, 28 Dec 2020 01:09:31 +0100 Subject: [PATCH 01/11] dt-bindings: arm: Convert nuvoton,npcm750 binding to YAML MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The general trend is to have devicetree bindings in YAML format, to allow automatic validation of bindings and devicetrees. Convert the NPCM SoC family's binding to YAML before extending it. The nuvoton,npcm750-evb compatible string is introduced to keep the structure of the binding a little simpler. Signed-off-by: Jonathan Neuschäfer --- If someone else (e.g. Brendan Higgins) wants to be listed as the maintainer, please let me know. --- .../devicetree/bindings/arm/npcm/npcm.txt | 6 -- .../devicetree/bindings/arm/npcm/npcm.yaml| 21 +++ 2 files changed, 21 insertions(+), 6 deletions(-) delete mode 100644 Documentation/devicetree/bindings/arm/npcm/npcm.txt create mode 100644 Documentation/devicetree/bindings/arm/npcm/npcm.yaml diff --git a/Documentation/devicetree/bindings/arm/npcm/npcm.txt b/Documentation/devicetree/bindings/arm/npcm/npcm.txt deleted file mode 100644 index 2d87d9ecea85b..0 --- a/Documentation/devicetree/bindings/arm/npcm/npcm.txt +++ /dev/null @@ -1,6 +0,0 @@ -NPCM Platforms Device Tree Bindings -NPCM750 SoC -Required root node properties: - - compatible = "nuvoton,npcm750"; - diff --git a/Documentation/devicetree/bindings/arm/npcm/npcm.yaml b/Documentation/devicetree/bindings/arm/npcm/npcm.yaml new file mode 100644 index 0..3ecd00803c003 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/npcm/npcm.yaml @@ -0,0 +1,21 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/npcm.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NPCM Platforms Device Tree Bindings + +maintainers: + - Jonathan Neuschäfer + +properties: + $nodename: +const: '/' + compatible: +oneOf: + - description: NPCM750 based boards +items: + - enum: +- nuvoton,npcm750-evb # NPCM750 evaluation board + - const: nuvoton,npcm750 -- 2.29.2 signature.asc Description: PGP signature
Re: [PATCH v2 RESEND 2/2] ARM: dts: Add board-specific compatible string to npcm750-evb devicetree
On Thu, Mar 04, 2021 at 05:21:36PM +0200, Tomer Maimon wrote:
> Hi Jonathan,
>
> Thanks a lot for sending the patch,
>
> I think that when it related to the SoC EVB it can stay with the
> genral compatible name nuvoton,npcm750
>
> you can see it also in,
> https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/aspeed-ast2500-evb.dts#L8
To make the single compatible string match the DT binding, I'll have to
write the binding a little differently. I wrote it like this:
compatible:
oneOf:
- description: NPCM750 based boards
items:
- enum:
- nuvoton,npcm750-evb # NPCM750 evaluation board
- const: nuvoton,npcm750
I guess I could do something like this:
compatible:
oneOf:
- description: NPCM750 development board
const: nuvoton,npcm750
And later add this part, when needed:
- description: NPCM750 based boards
items:
- enum:
- vendor,foo-bar-bmc
- const: nuvoton,npcm750
What do you think?
Thanks,
Jonathan Neuschäfer
> On Wed, 3 Mar 2021 at 17:47, Jonathan Neuschäfer
> wrote:
[...]
> > / {
> > model = "Nuvoton npcm750 Development Board (Device Tree)";
> > - compatible = "nuvoton,npcm750";
> > + compatible = "nuvoton,npcm750-evb", "nuvoton,npcm750";
signature.asc
Description: PGP signature
Re: [PATCH 1/3] dt-bindings: Add Hycon Technology vendor prefix
Hello, On Fri, Mar 05, 2021 at 05:38:32PM +0100, Giulio Benetti wrote: > From: Giulio Benetti > > Update Documentation/devicetree/bindings/vendor-prefixes.yaml to > include "hycon" as a vendor prefix for "Hycon Technology". > Company website: http://www.hycontek.com/ As far as I can see, https would be possible here. > Signed-off-by: Giulio Benetti > --- > Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml > b/Documentation/devicetree/bindings/vendor-prefixes.yaml > index a1312637d6ff..51b00aa96dff 100644 > --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml > +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml > @@ -488,6 +488,8 @@ patternProperties: >"^hugsun,.*": > description: Shenzhen Hugsun Technology Co. Ltd. >"^hwacom,.*": > +description: Hycon Technology Corp. > + "^hycon,.*": > description: HwaCom Systems Inc. This is the wrong way around. You declared "hwacom," to mean "Hycon Technology Corp.", and "hycon," to mean "HwaCom Systems Inc.". Best regards, Jonathan Neuschäfer signature.asc Description: PGP signature
[PATCH v2 RESEND 2/2] ARM: dts: Add board-specific compatible string to npcm750-evb devicetree
According to the revised binding, the devicetree needs a board-specific
compatible string.
Signed-off-by: Jonathan Neuschäfer
---
v2:
- no changes
---
arch/arm/boot/dts/nuvoton-npcm750-evb.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/nuvoton-npcm750-evb.dts
b/arch/arm/boot/dts/nuvoton-npcm750-evb.dts
index 9f13d08f5804e..dea3dbc4a6a52 100644
--- a/arch/arm/boot/dts/nuvoton-npcm750-evb.dts
+++ b/arch/arm/boot/dts/nuvoton-npcm750-evb.dts
@@ -9,7 +9,7 @@
/ {
model = "Nuvoton npcm750 Development Board (Device Tree)";
- compatible = "nuvoton,npcm750";
+ compatible = "nuvoton,npcm750-evb", "nuvoton,npcm750";
aliases {
ethernet2 = &gmac0;
--
2.29.2
[PATCH v2 RESEND 1/2] dt-bindings: arm: Convert nuvoton,npcm750 binding to YAML
The general trend is to have devicetree bindings in YAML format, to allow automatic validation of bindings and devicetrees. Convert the NPCM SoC family's binding to YAML before it accumulates more entries. The nuvoton,npcm750-evb compatible string is introduced to keep the structure of the binding a little simpler. Signed-off-by: Jonathan Neuschäfer Reviewed-by: Rob Herring --- If someone else wants to be listed as the maintainer, please let me know. v2: - Fix indentation to satisfy yamllint - Fix $schema line v1: - https://lore.kernel.org/lkml/20210108224008.705687-1-j.neuschae...@gmx.net/ --- .../devicetree/bindings/arm/npcm/npcm.txt | 6 - .../devicetree/bindings/arm/npcm/npcm.yaml| 23 +++ 2 files changed, 23 insertions(+), 6 deletions(-) delete mode 100644 Documentation/devicetree/bindings/arm/npcm/npcm.txt create mode 100644 Documentation/devicetree/bindings/arm/npcm/npcm.yaml diff --git a/Documentation/devicetree/bindings/arm/npcm/npcm.txt b/Documentation/devicetree/bindings/arm/npcm/npcm.txt deleted file mode 100644 index 2d87d9ecea85b..0 --- a/Documentation/devicetree/bindings/arm/npcm/npcm.txt +++ /dev/null @@ -1,6 +0,0 @@ -NPCM Platforms Device Tree Bindings -NPCM750 SoC -Required root node properties: - - compatible = "nuvoton,npcm750"; - diff --git a/Documentation/devicetree/bindings/arm/npcm/npcm.yaml b/Documentation/devicetree/bindings/arm/npcm/npcm.yaml new file mode 100644 index 0..894aefb70652a --- /dev/null +++ b/Documentation/devicetree/bindings/arm/npcm/npcm.yaml @@ -0,0 +1,23 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/npcm/npcm.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NPCM Platforms Device Tree Bindings + +maintainers: + - Jonathan Neuschäfer + +properties: + $nodename: +const: '/' + compatible: +oneOf: + - description: NPCM750 based boards +items: + - enum: + - nuvoton,npcm750-evb # NPCM750 evaluation board + - const: nuvoton,npcm750 + +additionalProperties: true -- 2.29.2
[PATCH] workqueue: Switch to new kerneldoc syntax for named variable macro argument
The syntax without dots is available since commit 43756e347f21
("scripts/kernel-doc: Add support for named variable macro arguments").
The same HTML output is produced with and without this patch.
Signed-off-by: Jonathan Neuschäfer
---
include/linux/workqueue.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/workqueue.h b/include/linux/workqueue.h
index d15a7730ee18b..83a51c5100e68 100644
--- a/include/linux/workqueue.h
+++ b/include/linux/workqueue.h
@@ -412,7 +412,7 @@ struct workqueue_struct *alloc_workqueue(const char *fmt,
* alloc_ordered_workqueue - allocate an ordered workqueue
* @fmt: printf format for the name of the workqueue
* @flags: WQ_* flags (only WQ_FREEZABLE and WQ_MEM_RECLAIM are meaningful)
- * @args...: args for @fmt
+ * @args: args for @fmt
*
* Allocate an ordered workqueue. An ordered workqueue executes at
* most one work item at any given time in the queued order. They are
--
2.30.1
[PATCH] kthread: Switch to new kerneldoc syntax for named variable macro argument
The syntax without dots is available since commit 43756e347f21
("scripts/kernel-doc: Add support for named variable macro arguments").
The same HTML output is produced with and without this patch.
Signed-off-by: Jonathan Neuschäfer
---
include/linux/kthread.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/kthread.h b/include/linux/kthread.h
index 2484ed97e72f5..db3eafea168ff 100644
--- a/include/linux/kthread.h
+++ b/include/linux/kthread.h
@@ -18,7 +18,7 @@ struct task_struct *kthread_create_on_node(int
(*threadfn)(void *data),
* @threadfn: the function to run in the thread
* @data: data pointer for @threadfn()
* @namefmt: printf-style format string for the thread name
- * @arg...: arguments for @namefmt.
+ * @arg: arguments for @namefmt.
*
* This macro will create a kthread on the current node, leaving it in
* the stopped state. This is just a helper for kthread_create_on_node();
--
2.30.1
