Devicetree
 help / color / mirror / Atom feed
* [PATCH] devicetree: bindings: clk: mvebu: fix description for sata1 on Armada XP
From: Uwe Kleine-König @ 2016-12-20 21:20 UTC (permalink / raw)
  To: Jason Cooper, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth,
	Michael Turquette, Stephen Boyd, Rob Herring, Mark Rutland
  Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	devicetree-u79uwXL29TY76Z2rM5mHXA

SATA Host 0 clock is (as correctly documented) id 15/sata0.

Signed-off-by: Uwe Kleine-König <uwe-rXY34ruvC2xidJT2blvkqNi2O/JbrIOy@public.gmane.org>
---
 Documentation/devicetree/bindings/clock/mvebu-gated-clock.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/clock/mvebu-gated-clock.txt b/Documentation/devicetree/bindings/clock/mvebu-gated-clock.txt
index cb8542d910b3..5142efc8099d 100644
--- a/Documentation/devicetree/bindings/clock/mvebu-gated-clock.txt
+++ b/Documentation/devicetree/bindings/clock/mvebu-gated-clock.txt
@@ -117,7 +117,7 @@ ID	Clock	Peripheral
 25	tdm	Time Division Mplx
 28	xor1	XOR DMA 1
 29	sata1lnk
-30	sata1	SATA Host 0
+30	sata1	SATA Host 1
 
 The following is a list of provided IDs for Dove:
 ID	Clock	Peripheral
-- 
2.10.2

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply related

* Re: [PATCH v6 4/5] fpga manager: Add cyclone-ps-spi driver for Altera FPGAs
From: Uwe Kleine-König @ 2016-12-20 20:44 UTC (permalink / raw)
  To: Joshua Clayton
  Cc: Mark Rutland, Moritz Fischer, devicetree, Alan Tull,
	Catalin Marinas, linux-fpga, Will Deacon, Russell King,
	linux-kernel, Rob Herring, Sascha Hauer, Fabio Estevam,
	Anatolij Gustschin, Shawn Guo, linux-arm-kernel
In-Reply-To: <ba899a9f-3a31-85c5-9da4-dd64a2661e60@gmail.com>

Hello Joshua,

On Tue, Dec 20, 2016 at 11:47:37AM -0800, Joshua Clayton wrote:
> >> + *  Copyright (c) 2017 United Western Technologies, Corporation
> > In which timezone it's already 2017? s/  / /
> >
> LOL. It will be 2017 long before 4.11 was my thinking.
> I guess I've never spent much time on time stamp etiquette for copyright.
> It said "2015" in v5, despite still being revised.

Well, you have to put the date when you worked on the driver.

> >> + *
> >> + *  Joshua Clayton <stillcompiling@gmail.com>
> >> + *
> >> + * Manage Altera FPGA firmware that is loaded over spi using the passive
> >> + * serial configuration method.
> >> + * Firmware must be in binary "rbf" format.
> >> + * Works on Cyclone V. Should work on cyclone series.
> >> + * May work on other Altera FPGAs.
> > I can test this later on an Arria 10. I'm not sure what the connection
> > between "Cyclone" and "Arria" is, but the protocol looks similar.
> My guess was it would be.
> Would be wonderful to have someone to test.

I didn't come around yet.

> >> + *
> >> + */
> >> +
> >> +#include <linux/bitrev.h>
> >> +#include <linux/delay.h>
> >> +#include <linux/fpga/fpga-mgr.h>
> >> +#include <linux/gpio/consumer.h>
> >> +#include <linux/module.h>
> >> +#include <linux/of_gpio.h>
> >> +#include <linux/spi/spi.h>
> >> +#include <linux/sizes.h>
> >> +
> >> +#define FPGA_RESET_TIME		50   /* time in usecs to trigger FPGA config */
> >> +#define FPGA_MIN_DELAY		50   /* min usecs to wait for config status */
> >> +#define FPGA_MAX_DELAY		1000 /* max usecs to wait for config status */
> >> +
> >> +struct cyclonespi_conf {
> >> +	struct gpio_desc *config;
> >> +	struct gpio_desc *status;
> >> +	struct spi_device *spi;
> >> +};
> >> +
> >> +static const struct of_device_id of_ef_match[] = {
> >> +	{ .compatible = "altr,cyclone-ps-spi-fpga-mgr", },
> >> +	{}
> >> +};
> >> +MODULE_DEVICE_TABLE(of, of_ef_match);
> > barebox already has such a driver, the binding is available at
> >
> > 	https://git.pengutronix.de/cgit/barebox/tree/Documentation/devicetree/bindings/firmware/altr,passive-serial.txt
> >
> > (This isn't completely accurate because nstat is optional in the driver.)
> Interesting.
> The binding looks ... like we should synchronize those bindings.

ack.

> >> +	gpiod_set_value(conf->config, 1);
> >> +	usleep_range(FPGA_RESET_TIME, FPGA_RESET_TIME + 20);
> >> +	if (!gpiod_get_value(conf->status)) {
> >> +		dev_err(&mgr->dev, "Status pin should be low.\n");
> > You write this when get_value returns 0. There is something fishy.
> I'll take a look. These gpios are "active low", so a logical 1 is a
> physical low, IIRC. Maybe I should change the wording:
> Something like dev_err(&mgr->dev, "Status pin should be in reset.\n");

maybe "inactive"? Then then you should better use nconfig as dts name
(as done in the barebox binding) and put the active low information into
the flag.

> >> +		return -EIO;
> >> +	}
> >> +
> >> +	gpiod_set_value(conf->config, 0);
> >> +	for (i = 0; i < (FPGA_MAX_DELAY / FPGA_MIN_DELAY); i++) {
> >> +		usleep_range(FPGA_MIN_DELAY, FPGA_MIN_DELAY + 20);
> >> +		if (!gpiod_get_value(conf->status))
> >> +			return 0;
> >> +	}
> >> +
> >> +	dev_err(&mgr->dev, "Status pin not ready.\n");
> >> +	return -EIO;
> > For Arria 10 the documentation has:
> >
> > 	To ensure a successful configuration, send the entire
> > 	configuration data to the device. CONF_DONE is released high
> > 	when the device receives all the configuration data
> > 	successfully. After CONF_DONE goes high, send two additional
> > 	falling edges on DCLK to begin initialization and enter user
> > 	mode.
> >
> > ISTR this is necessary for Arria V, too.
> DCLK is the spi clock, yes?
> Would sending an extra byte after CONF_DONE is released suffice?

The barebox driver sends two bytes.

> >> +}
> >> +
> >> +static int cyclonespi_write(struct fpga_manager *mgr, const char *buf,
> >> +			    size_t count)
> >> +{
> >> +	struct cyclonespi_conf *conf = (struct cyclonespi_conf *)mgr->priv;
> >> +	const char *fw_data = buf;
> >> +	const char *fw_data_end = fw_data + count;
> >> +
> >> +	while (fw_data < fw_data_end) {
> >> +		int ret;
> >> +		size_t stride = min(fw_data_end - fw_data, SZ_4K);
> >> +
> >> +		rev_buf((void *)fw_data, stride);
> > This isn't necessary if the spi controller supports SPI_LSB_FIRST. At
> > least the mvebu spi core can do this for you. (The driver doesn't
> > support it yet, though.)
> This is true, but many of them do not.

And I think it's hard to detect if the adapter driver supports this or
simply ignores it.
 
> Moritz Fischer had  proposal to add things like this with a flag.
> It could then be part of the library, rather than part of the driver
> 
> Speaking of which,
> I made an unsuccessful attempt to hack generic lsb first SPI
> with an extra bounce buffer.
> Sending was fine, but I ran into trouble with LSB first rx
> (I think) because of dma.

Link?

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

^ permalink raw reply

* [PATCH 3/3] ARM: da850: Add ti,da830-uart compatible for serial ports
From: David Lechner @ 2016-12-20 20:23 UTC (permalink / raw)
  To: Greg Kroah-Hartman, Rob Herring, Mark Rutland
  Cc: David Lechner, Sekhar Nori, Kevin Hilman, Axel Haslam,
	Alexandre Bailon, Bartosz Golaszewski, Jiri Slaby, linux-serial,
	devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <1482265384-715-1-git-send-email-david@lechnology.com>

TI DA8xx/OMAPL13x/AM17xx/AM18xx SoCs have extra UART registers beyond
the standard 8250 registers, so we need a new compatible string to
indicate this. Also, at least one of these registers uses the full 32
bits, so we need to specify reg-io-width in addition to reg-shift.

"ns16550a" is left in the compatible specification since it does work
as long as the bootloader configures the SoC UART power management
registers.

Signed-off-by: David Lechner <david@lechnology.com>
---
 arch/arm/boot/dts/da850.dtsi | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 104155d..f6cd212 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -266,22 +266,25 @@
 			interrupt-names = "edm3_tcerrint";
 		};
 		serial0: serial@42000 {
-			compatible = "ns16550a";
+			compatible = "ti,da830-uart", "ns16550a";
 			reg = <0x42000 0x100>;
+			reg-io-width = <4>;
 			reg-shift = <2>;
 			interrupts = <25>;
 			status = "disabled";
 		};
 		serial1: serial@10c000 {
-			compatible = "ns16550a";
+			compatible = "ti,da830-uart", "ns16550a";
 			reg = <0x10c000 0x100>;
+			reg-io-width = <4>;
 			reg-shift = <2>;
 			interrupts = <53>;
 			status = "disabled";
 		};
 		serial2: serial@10d000 {
-			compatible = "ns16550a";
+			compatible = "ti,da830-uart", "ns16550a";
 			reg = <0x10d000 0x100>;
+			reg-io-width = <4>;
 			reg-shift = <2>;
 			interrupts = <61>;
 			status = "disabled";
-- 
2.7.4

^ permalink raw reply related

* [PATCH 2/3] serial: 8250: Add new port type for TI DA8xx/OMAPL13x/AM17xx/AM18xx
From: David Lechner @ 2016-12-20 20:23 UTC (permalink / raw)
  To: Greg Kroah-Hartman, Rob Herring, Mark Rutland
  Cc: David Lechner, Sekhar Nori, Kevin Hilman, Axel Haslam,
	Alexandre Bailon, Bartosz Golaszewski, Jiri Slaby, linux-serial,
	devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <1482265384-715-1-git-send-email-david@lechnology.com>

This adds a new UART port type for TI DA8xx/OMAPL13x/AM17xx/AM18xx. These
SoCs have standard 8250 registers plus some extra non-standard registers.

The UART will not function unless the non-standard Power and Emulation
Management Register (PWREMU_MGMT) is configured correctly. This is
currently handled in arch/arm/mach-davinci/serial.c for non-device-tree
boards. Making this part of the UART driver will allow UART to work on
device-tree boards as well and the mach code can eventually be removed.

Signed-off-by: David Lechner <david@lechnology.com>
---
 drivers/tty/serial/8250/8250_of.c   |  1 +
 drivers/tty/serial/8250/8250_port.c | 22 ++++++++++++++++++++++
 include/uapi/linux/serial_core.h    |  3 ++-
 include/uapi/linux/serial_reg.h     |  8 ++++++++
 4 files changed, 33 insertions(+), 1 deletion(-)

diff --git a/drivers/tty/serial/8250/8250_of.c b/drivers/tty/serial/8250/8250_of.c
index d25ab1c..5281252 100644
--- a/drivers/tty/serial/8250/8250_of.c
+++ b/drivers/tty/serial/8250/8250_of.c
@@ -332,6 +332,7 @@ static const struct of_device_id of_platform_serial_table[] = {
 		.data = (void *)PORT_ALTR_16550_F128, },
 	{ .compatible = "mrvl,mmp-uart",
 		.data = (void *)PORT_XSCALE, },
+	{ .compatible = "ti,da830-uart", .data = (void *)PORT_DA830, },
 	{ /* end of list */ },
 };
 MODULE_DEVICE_TABLE(of, of_platform_serial_table);
diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c
index fe4399b..ea854054 100644
--- a/drivers/tty/serial/8250/8250_port.c
+++ b/drivers/tty/serial/8250/8250_port.c
@@ -273,6 +273,15 @@ static const struct serial8250_config uart_config[] = {
 		.rxtrig_bytes	= {1, 4, 8, 14},
 		.flags		= UART_CAP_FIFO,
 	},
+	[PORT_DA830] = {
+		.name		= "TI DA8xx/OMAPL13x/AM17xx/AM18xx",
+		.fifo_size	= 16,
+		.tx_loadsz	= 16,
+		.fcr		= UART_FCR_DMA_SELECT | UART_FCR_ENABLE_FIFO |
+				  UART_FCR_R_TRIG_10,
+		.rxtrig_bytes	= {1, 4, 8, 14},
+		.flags		= UART_CAP_FIFO | UART_CAP_AFE,
+	},
 };
 
 /* Uart divisor latch read */
@@ -2118,6 +2127,19 @@ int serial8250_do_startup(struct uart_port *port)
 		serial_port_out(port, UART_LCR, 0);
 	}
 
+	if (port->type == PORT_DA830) {
+		/* Reset the port */
+		serial_port_out(port, UART_IER, 0);
+		serial_port_out(port, UART_DA830_PWREMU_MGMT, 0);
+		mdelay(10);
+
+		/* Enable Tx, Rx and free run mode */
+		serial_port_out(port, UART_DA830_PWREMU_MGMT,
+				UART_DA830_PWREMU_MGMT_UTRST |
+				UART_DA830_PWREMU_MGMT_URRST |
+				UART_DA830_PWREMU_MGMT_FREE);
+	}
+
 #ifdef CONFIG_SERIAL_8250_RSA
 	/*
 	 * If this is an RSA port, see if we can kick it up to the
diff --git a/include/uapi/linux/serial_core.h b/include/uapi/linux/serial_core.h
index 99dbed8..a126d05 100644
--- a/include/uapi/linux/serial_core.h
+++ b/include/uapi/linux/serial_core.h
@@ -56,7 +56,8 @@
 #define PORT_ALTR_16550_F128 28 /* Altera 16550 UART with 128 FIFOs */
 #define PORT_RT2880	29	/* Ralink RT2880 internal UART */
 #define PORT_16550A_FSL64 30	/* Freescale 16550 UART with 64 FIFOs */
-#define PORT_MAX_8250	30	/* max port ID */
+#define PORT_DA830	31	/* TI DA8xx/OMAP13x/AM17xx/AM18xx */
+#define PORT_MAX_8250	31	/* max port ID */
 
 /*
  * ARM specific type numbers.  These are not currently guaranteed
diff --git a/include/uapi/linux/serial_reg.h b/include/uapi/linux/serial_reg.h
index b4c0484..0e72eeb 100644
--- a/include/uapi/linux/serial_reg.h
+++ b/include/uapi/linux/serial_reg.h
@@ -327,6 +327,14 @@
 #define SERIAL_RSA_BAUD_BASE (921600)
 #define SERIAL_RSA_BAUD_BASE_LO (SERIAL_RSA_BAUD_BASE / 8)
 
+/* Extra registers for TI DA8xx/OMAP13x/AM17xx/AM18xx */
+#define UART_DA830_PWREMU_MGMT	12
+
+/* PWREMU_MGMT register bits */
+#define UART_DA830_PWREMU_MGMT_FREE	(1 << 0)  /* Free-running mode */
+#define UART_DA830_PWREMU_MGMT_URRST	(1 << 13) /* Receiver reset/enable */
+#define UART_DA830_PWREMU_MGMT_UTRST	(1 << 14) /* Transmitter reset/enable */
+
 /*
  * Extra serial register definitions for the internal UARTs
  * in TI OMAP processors.
-- 
2.7.4

^ permalink raw reply related

* [PATCH 1/3] doc: DT: Add ti,da830-uart to serial/8250 bindings
From: David Lechner @ 2016-12-20 20:23 UTC (permalink / raw)
  To: Greg Kroah-Hartman, Rob Herring, Mark Rutland
  Cc: David Lechner, Sekhar Nori, Kevin Hilman, Axel Haslam,
	Alexandre Bailon, Bartosz Golaszewski, Jiri Slaby,
	linux-serial-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1482265384-715-1-git-send-email-david-nq/r/kbU++upp/zk7JDF2g@public.gmane.org>

This adds the ti,da830-uart compatible string to serial 8250 UART bindings.

Signed-off-by: David Lechner <david-nq/r/kbU++upp/zk7JDF2g@public.gmane.org>
---
 Documentation/devicetree/bindings/serial/8250.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/serial/8250.txt b/Documentation/devicetree/bindings/serial/8250.txt
index f86bb06..10276a4 100644
--- a/Documentation/devicetree/bindings/serial/8250.txt
+++ b/Documentation/devicetree/bindings/serial/8250.txt
@@ -19,6 +19,7 @@ Required properties:
 	- "altr,16550-FIFO128"
 	- "fsl,16550-FIFO64"
 	- "fsl,ns16550"
+	- "ti,da830-uart"
 	- "serial" if the port type is unknown.
 - reg : offset and length of the register set for the device.
 - interrupts : should contain uart interrupt.
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply related

* [PATCH 0/3] TI DA8xx/OMAPL13x/AM17xx/AM18xx UART
From: David Lechner @ 2016-12-20 20:23 UTC (permalink / raw)
  To: Greg Kroah-Hartman, Rob Herring, Mark Rutland
  Cc: David Lechner, Sekhar Nori, Kevin Hilman, Axel Haslam,
	Alexandre Bailon, Bartosz Golaszewski, Jiri Slaby,
	linux-serial-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r

This series adds a new UART port type for TI DA8xx/OMAPL13x/AM17xx/AM18xx UART.
This SoCs have a non-standard register for UART power management that needs
special handling in the UART driver.

David Lechner (3):
  doc: DT: Add ti,da830-uart to serial/8250 bindings
  serial: 8250: Add new port type for TI DA8xx/OMAPL13x/AM17xx/AM18xx
  ARM: da850: Add ti,da830-uart compatible for serial ports

 Documentation/devicetree/bindings/serial/8250.txt |  1 +
 arch/arm/boot/dts/da850.dtsi                      |  9 ++++++---
 drivers/tty/serial/8250/8250_of.c                 |  1 +
 drivers/tty/serial/8250/8250_port.c               | 22 ++++++++++++++++++++++
 include/uapi/linux/serial_core.h                  |  3 ++-
 include/uapi/linux/serial_reg.h                   |  8 ++++++++
 6 files changed, 40 insertions(+), 4 deletions(-)

-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: nfc: trf7970a: Prevent repeated polling from crashing the kernel
From: Mark Greer @ 2016-12-20 19:56 UTC (permalink / raw)
  To: Justin Bronder
  Cc: Geoff Lansberry, linux-wireless-u79uwXL29TY76Z2rM5mHXA,
	lauro.venancio-430g2QfJUUCGglJvpFV4uA,
	aloisio.almeida-430g2QfJUUCGglJvpFV4uA,
	sameo-VuQAYsv1563Yd54FQh9/CA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
	mark.rutland-5wv7dgnIgG8, netdev-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA, Jaret Cantu
In-Reply-To: <20161220191352.GB23496-WrO9gjaJVAZ9BIO3fBtL+FdjMaeQq/Z1QQ4Iyu8u01E@public.gmane.org>

On Tue, Dec 20, 2016 at 02:13:52PM -0500, Justin Bronder wrote:
> On 20/12/16 11:59 -0700, Mark Greer wrote:
> > On Tue, Dec 20, 2016 at 11:16:32AM -0500, Geoff Lansberry wrote:
> > > From: Jaret Cantu <jaret.cantu-jEh4hwF5bVhBDgjK7y7TUQ@public.gmane.org>
> > > 
> > > Repeated polling attempts cause a NULL dereference error to occur.
> > > This is because the state of the trf7970a is currently reading but
> > > another request has been made to send a command before it has finished.
> > 
> > How is this happening?  Was trf7970a_abort_cmd() called and it didn't
> > work right?  Was it not called at all and there is a bug in the digital
> > layer?  More details please.
> > 
> > > The solution is to properly kill the waiting reading (workqueue)
> > > before failing on the send.
> > 
> > If the bug is in the calling code, then that is what should get fixed.
> > This seems to be a hack to work-around a digital layer bug.
> 
> One of our uses of NFC is to begin polling to read a tag and then stop polling
> (in order to save power) until we know via user interaction that we need to poll
> again.  This is typically many minutes later so the power saving is pretty
> significant.  However, it's possible that a user will remove the tag before
> reading has completed.  We also detect this case and stop polling.  I can go
> more into this if necessary but that is what exposed a panic.
> 
> You can reproduce using neard and python, in our testing it was very likely to
> occur in 10-100 iterations of the following.:
> 
>     #!/usr/bin/python
>     import time
> 
>     import dbus
> 
>     bus = dbus.SystemBus()
>     nfc0 = bus.get_object('org.neard', '/org/neard/nfc0')
>     props = dbus.Interface(nfc0, 'org.freedesktop.DBus.Properties')
> 
>     try:
>         props.Set('org.neard.Adapter', 'Powered', dbus.Boolean(1))
>     except:
>         pass
> 
>     adapter = dbus.Interface(nfc0, 'org.neard.Adapter')
> 
>     for i in range(1000):
>         adapter.StartPollLoop('Initiator')
>         time.sleep(0.1)
>         adapter.StopPollLoop()
>         print(i)
> 
> I believe the last time we tested this was around the 4.1 release.

Thanks for the info, Justin, but I was also seeking more information
at the kernel NFC subsystem and trf7970a driver level.  This patch
adds code inside an 'if' in the driver whose condition should never
be evaluate to true but apparently it did.  How?

Thanks,

Mark
--
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH v6 4/5] fpga manager: Add cyclone-ps-spi driver for Altera FPGAs
From: Joshua Clayton @ 2016-12-20 19:47 UTC (permalink / raw)
  To: Uwe Kleine-König
  Cc: Alan Tull, Moritz Fischer, Russell King, Catalin Marinas,
	Will Deacon, Shawn Guo, Sascha Hauer, Fabio Estevam, Mark Rutland,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-fpga-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA, Rob Herring,
	Anatolij Gustschin,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20161219072326.fael3uughtghexl4-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>

Uwe,

Thanks so much for your review.

On 12/18/2016 11:23 PM, Uwe Kleine-König wrote:
> On Fri, Dec 16, 2016 at 03:17:53PM -0800, Joshua Clayton wrote:
>> cyclone-ps-spi loads FPGA firmware over spi, using the "passive serial"
>> interface on Altera Cyclone FPGAS.
>>
>> This is one of the simpler ways to set up an FPGA at runtime.
>> The signal interface is close to unidirectional spi with lsb first.
>>
>> Signed-off-by: Joshua Clayton <stillcompiling-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> ---
>>  drivers/fpga/Kconfig          |   7 ++
>>  drivers/fpga/Makefile         |   1 +
>>  drivers/fpga/cyclone-ps-spi.c | 186 ++++++++++++++++++++++++++++++++++++++++++
>>  3 files changed, 194 insertions(+)
>>  create mode 100644 drivers/fpga/cyclone-ps-spi.c
>>
>> diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
>> index ce861a2..e6c032d 100644
>> --- a/drivers/fpga/Kconfig
>> +++ b/drivers/fpga/Kconfig
>> @@ -20,6 +20,13 @@ config FPGA_REGION
>>  	  FPGA Regions allow loading FPGA images under control of
>>  	  the Device Tree.
>>  
>> +config FPGA_MGR_CYCLONE_PS_SPI
>> +	tristate "Altera Cyclone FPGA Passive Serial over SPI"
>> +	depends on SPI
>> +	help
>> +	  FPGA manager driver support for Altera Cyclone using the
>> +	  passive serial interface over SPI
>> +
>>  config FPGA_MGR_SOCFPGA
>>  	tristate "Altera SOCFPGA FPGA Manager"
>>  	depends on ARCH_SOCFPGA || COMPILE_TEST
>> diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
>> index 8df07bc..a112bef 100644
>> --- a/drivers/fpga/Makefile
>> +++ b/drivers/fpga/Makefile
>> @@ -6,6 +6,7 @@
>>  obj-$(CONFIG_FPGA)			+= fpga-mgr.o
>>  
>>  # FPGA Manager Drivers
>> +obj-$(CONFIG_FPGA_MGR_CYCLONE_PS_SPI)	+= cyclone-ps-spi.o
>>  obj-$(CONFIG_FPGA_MGR_SOCFPGA)		+= socfpga.o
>>  obj-$(CONFIG_FPGA_MGR_SOCFPGA_A10)	+= socfpga-a10.o
>>  obj-$(CONFIG_FPGA_MGR_ZYNQ_FPGA)	+= zynq-fpga.o
>> diff --git a/drivers/fpga/cyclone-ps-spi.c b/drivers/fpga/cyclone-ps-spi.c
>> new file mode 100644
>> index 0000000..f9126f9
>> --- /dev/null
>> +++ b/drivers/fpga/cyclone-ps-spi.c
>> @@ -0,0 +1,186 @@
>> +/**
>> + * Altera Cyclone Passive Serial SPI Driver
>> + *
>> + *  Copyright (c) 2017 United Western Technologies, Corporation
> In which timezone it's already 2017? s/  / /
>
LOL. It will be 2017 long before 4.11 was my thinking.
I guess I've never spent much time on time stamp etiquette for copyright.
It said "2015" in v5, despite still being revised.
>> + *
>> + *  Joshua Clayton <stillcompiling-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> + *
>> + * Manage Altera FPGA firmware that is loaded over spi using the passive
>> + * serial configuration method.
>> + * Firmware must be in binary "rbf" format.
>> + * Works on Cyclone V. Should work on cyclone series.
>> + * May work on other Altera FPGAs.
> I can test this later on an Arria 10. I'm not sure what the connection
> between "Cyclone" and "Arria" is, but the protocol looks similar.
My guess was it would be.
Would be wonderful to have someone to test.
>> + *
>> + */
>> +
>> +#include <linux/bitrev.h>
>> +#include <linux/delay.h>
>> +#include <linux/fpga/fpga-mgr.h>
>> +#include <linux/gpio/consumer.h>
>> +#include <linux/module.h>
>> +#include <linux/of_gpio.h>
>> +#include <linux/spi/spi.h>
>> +#include <linux/sizes.h>
>> +
>> +#define FPGA_RESET_TIME		50   /* time in usecs to trigger FPGA config */
>> +#define FPGA_MIN_DELAY		50   /* min usecs to wait for config status */
>> +#define FPGA_MAX_DELAY		1000 /* max usecs to wait for config status */
>> +
>> +struct cyclonespi_conf {
>> +	struct gpio_desc *config;
>> +	struct gpio_desc *status;
>> +	struct spi_device *spi;
>> +};
>> +
>> +static const struct of_device_id of_ef_match[] = {
>> +	{ .compatible = "altr,cyclone-ps-spi-fpga-mgr", },
>> +	{}
>> +};
>> +MODULE_DEVICE_TABLE(of, of_ef_match);
> barebox already has such a driver, the binding is available at
>
> 	https://git.pengutronix.de/cgit/barebox/tree/Documentation/devicetree/bindings/firmware/altr,passive-serial.txt
>
> (This isn't completely accurate because nstat is optional in the driver.)
Interesting.
The binding looks ... like we should synchronize those bindings.
In the case of my hardware, I don't have access to the confd, but do
have access to nstat. I was thinking that using confd to signal done
would be a nice but optional... Ideally you'd have both.
>> +static enum fpga_mgr_states cyclonespi_state(struct fpga_manager *mgr)
>> +{
>> +	struct cyclonespi_conf *conf = (struct cyclonespi_conf *)mgr->priv;
>> +
>> +	if (gpiod_get_value(conf->status))
>> +		return FPGA_MGR_STATE_RESET;
>> +
>> +	return FPGA_MGR_STATE_UNKNOWN;
>> +}
>> +
>> +static int cyclonespi_write_init(struct fpga_manager *mgr,
>> +				 struct fpga_image_info *info,
>> +				 const char *buf, size_t count)
>> +{
>> +	struct cyclonespi_conf *conf = (struct cyclonespi_conf *)mgr->priv;
>> +	int i;
>> +
>> +	if (info->flags & FPGA_MGR_PARTIAL_RECONFIG) {
>> +		dev_err(&mgr->dev, "Partial reconfiguration not supported.\n");
>> +		return -EINVAL;
>> +	}
>> +
>> +	gpiod_set_value(conf->config, 1);
>> +	usleep_range(FPGA_RESET_TIME, FPGA_RESET_TIME + 20);
>> +	if (!gpiod_get_value(conf->status)) {
>> +		dev_err(&mgr->dev, "Status pin should be low.\n");
> You write this when get_value returns 0. There is something fishy.
I'll take a look. These gpios are "active low", so a logical 1 is a
physical low, IIRC. Maybe I should change the wording:
Something like dev_err(&mgr->dev, "Status pin should be in reset.\n");

Perhaps?


>> +		return -EIO;
>> +	}
>> +
>> +	gpiod_set_value(conf->config, 0);
>> +	for (i = 0; i < (FPGA_MAX_DELAY / FPGA_MIN_DELAY); i++) {
>> +		usleep_range(FPGA_MIN_DELAY, FPGA_MIN_DELAY + 20);
>> +		if (!gpiod_get_value(conf->status))
>> +			return 0;
>> +	}
>> +
>> +	dev_err(&mgr->dev, "Status pin not ready.\n");
>> +	return -EIO;
> For Arria 10 the documentation has:
>
> 	To ensure a successful configuration, send the entire
> 	configuration data to the device. CONF_DONE is released high
> 	when the device receives all the configuration data
> 	successfully. After CONF_DONE goes high, send two additional
> 	falling edges on DCLK to begin initialization and enter user
> 	mode.
>
> ISTR this is necessary for Arria V, too.
DCLK is the spi clock, yes?
Would sending an extra byte after CONF_DONE is released suffice?
>> +}
>> +
>> +static void rev_buf(void *buf, size_t len)
>> +{
>> +	u32 *fw32 = (u32 *)buf;
>> +	const u32 *fw_end = (u32 *)(buf + len);
>> +
>> +	/* set buffer to lsb first */
>> +	while (fw32 < fw_end) {
>> +		*fw32 = bitrev8x4(*fw32);
>> +		fw32++;
>> +	}
> Is the size of the firmware always a multiple of 32 bit? If len isn't a
> multiple of 4 you access data after the end of buf.
The rbf cyclone V bitstream is padded out with extra bytes of FFFFFFFF
and always a multiple of 4 bytes.
I could not find anywhere this is documented.
I guess we should not assume this will always be the case.
I'll add something to handle the tail.
>> +}
>> +
>> +static int cyclonespi_write(struct fpga_manager *mgr, const char *buf,
>> +			    size_t count)
>> +{
>> +	struct cyclonespi_conf *conf = (struct cyclonespi_conf *)mgr->priv;
>> +	const char *fw_data = buf;
>> +	const char *fw_data_end = fw_data + count;
>> +
>> +	while (fw_data < fw_data_end) {
>> +		int ret;
>> +		size_t stride = min(fw_data_end - fw_data, SZ_4K);
>> +
>> +		rev_buf((void *)fw_data, stride);
> This isn't necessary if the spi controller supports SPI_LSB_FIRST. At
> least the mvebu spi core can do this for you. (The driver doesn't
> support it yet, though.)
This is true, but many of them do not.

Moritz Fischer had  proposal to add things like this with a flag.
It could then be part of the library, rather than part of the driver

Speaking of which,
I made an unsuccessful attempt to hack generic lsb first SPI
with an extra bounce buffer.
Sending was fine, but I ran into trouble with LSB first rx
(I think) because of dma.

>> +		ret = spi_write(conf->spi, fw_data, stride);
>> +		if (ret) {
>> +			dev_err(&mgr->dev, "spi error in firmware write: %d\n",
>> +				ret);
>> +			return ret;
>> +		}
>> +		fw_data += stride;
>> +	}
>> +
>> +	return 0;
>> +}
>> [...]
>> +static int cyclonespi_probe(struct spi_device *spi)
>> +{
>> +	struct cyclonespi_conf *conf = devm_kzalloc(&spi->dev, sizeof(*conf),
>> +						GFP_KERNEL);
> please indent to the opening (.
Will fix.
>> +
>> +	if (!conf)
>> +		return -ENOMEM;
>> +
>> +	conf->spi = spi;
>> +	conf->config = devm_gpiod_get(&spi->dev, "config", GPIOD_OUT_HIGH);
>> +	if (IS_ERR(conf->config)) {
>> +		dev_err(&spi->dev, "Failed to get config gpio: %ld\n",
>> +			PTR_ERR(conf->config));
>> +		return PTR_ERR(conf->config);
>> +	}
>> +
>> +	conf->status = devm_gpiod_get(&spi->dev, "status", GPIOD_IN);
>> +	if (IS_ERR(conf->status)) {
>> +		dev_err(&spi->dev, "Failed to get status gpio: %ld\n",
>> +			PTR_ERR(conf->status));
>> +		return PTR_ERR(conf->status);
>> +	}
>> +
>> +	return fpga_mgr_register(&spi->dev,
>> +				 "Altera Cyclone PS SPI FPGA Manager",
>> +				 &cyclonespi_ops, conf);
>> +}
>> +
>> +static int cyclonespi_remove(struct spi_device *spi)
>> +{
>> +	fpga_mgr_unregister(&spi->dev);
>> +
>> +	return 0;
>> +}
>> +
>> +static struct spi_driver cyclonespi_driver = {
>> +	.driver = {
>> +		.name   = "cyclone-ps-spi",
>> +		.owner  = THIS_MODULE,
>> +		.of_match_table = of_match_ptr(of_ef_match),
>> +	},
>> +	.probe  = cyclonespi_probe,
>> +	.remove = cyclonespi_remove,
>> +};
> I'm not a big fan of aligning the assignment operators. This tends to
> get out of sync or results in bigger than necessary changes in follow up
> patches. Note that it's out of sync already now, so I suggest to use a
> single space before =.
Yes, I can see it your way. Will change.
>> +
>> +module_spi_driver(cyclonespi_driver)
>> +
>> +MODULE_LICENSE("GPL");
>> +MODULE_AUTHOR("Joshua Clayton <stillcompiling-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>");
>> +MODULE_DESCRIPTION("Module to load Altera FPGA firmware over spi");
>> -- 
> Best regards
> Uwe
>
Even bester regards,

Joshua
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH v1 07/12] scsi: ufs: add option to change default UFS power management level
From: Subhash Jadavani @ 2016-12-20 19:36 UTC (permalink / raw)
  To: Rob Herring
  Cc: Vinayak Holikatti, jejb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8,
	Martin K. Petersen, linux-scsi-u79uwXL29TY76Z2rM5mHXA,
	Mark Rutland, Hannes Reinecke, Yaniv Gardi, Joao Pinto,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
	open list
In-Reply-To: <CAL_Jsq+mu0R58in7oOq-mho43ERqOQk=jiu5vCWXq5=4eJJSpQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

On 2016-12-19 10:38, Rob Herring wrote:
> On Tue, Dec 13, 2016 at 2:16 PM, Subhash Jadavani
> <subhashj-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> wrote:
>> On 2016-12-13 12:04, Rob Herring wrote:
>>> 
>>> On Mon, Dec 12, 2016 at 04:54:20PM -0800, Subhash Jadavani wrote:
>>>> 
>>>> UFS device and link can be put in multiple different low power modes
>>>> hence
>>>> UFS driver supports multiple different low power modes. By default 
>>>> UFS
>>>> driver selects the default (optimal) low power mode (which gives 
>>>> moderate
>>>> power savings and have relatively less enter and exit latencies) but
>>>> we might have to tune this default power mode for different chipset
>>>> platforms to meet the low power requirements/goals. Hence this patch
>>>> adds option to change default UFS low power mode (level).
>>>> 
>>>> Reviewed-by: Yaniv Gardi <ygardi-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
>>>> Signed-off-by: Subhash Jadavani <subhashj-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
>>>> ---
>>>>  .../devicetree/bindings/ufs/ufshcd-pltfrm.txt      | 10 ++++++
>>>>  drivers/scsi/ufs/ufshcd-pltfrm.c                   | 14 ++++++++
>>>>  drivers/scsi/ufs/ufshcd.c                          | 39
>>>> ++++++++++++++++++++++
>>>>  drivers/scsi/ufs/ufshcd.h                          |  4 +--
>>>>  4 files changed, 65 insertions(+), 2 deletions(-)
>>>> 
>>>> diff --git a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
>>>> b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
>>>> index a99ed55..c3836c5 100644
>>>> --- a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
>>>> +++ b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
>>>> @@ -41,6 +41,14 @@ Optional properties:
>>>>  -lanes-per-direction   : number of lanes available per direction -
>>>> either 1 or 2.
>>>>                           Note that it is assume same number of 
>>>> lanes is
>>>> used both
>>>>                           directions at once. If not specified, 
>>>> default
>>>> is 2 lanes per direction.
>>>> +- rpm-level            : UFS Runtime power management level. 
>>>> Following
>>>> PM levels are supported:
>>>> +                         0 - Both UFS device and Link in active 
>>>> state
>>>> (Highest power consumption)
>>>> +                         1 - UFS device in active state but Link in
>>>> Hibern8 state
>>>> +                         2 - UFS device in Sleep state but Link in
>>>> active state
>>>> +                         3 - UFS device in Sleep state and Link in
>>>> hibern8 state (default PM level)
>>>> +                         4 - UFS device in Power-down state and 
>>>> Link in
>>>> Hibern8 state
>>>> +                         5 - UFS device in Power-down state and 
>>>> Link in
>>>> OFF state (Lowest power consumption)
>>>> +- spm-level            : UFS System power management level. Allowed 
>>>> PM
>>>> levels are same as rpm-level.
>>> 
>>> 
>>> This looks like you are putting policy for Linux into DT.
>>> 
>>> What I would expect to see here is disabling of states that don't 
>>> work
>>> due to some h/w limitation. Otherwise, it is a user decision for what
>>> modes to go into. Also, I think link and device states should be
>>> separate.
>> 
>> 
>> Yes, generally default level (3) is good enough (and recommended) for 
>> all
>> platforms and most likely user is only expected to change this if they 
>> see
>> issues (most H/W) on their platform or they want even more aggressive 
>> power
>> state (level-4 or level-5) and ready to take the performance hit 
>> associated
>> with resume latencies.
> 
> What latencies can be tolerated is going to depend on the application
> and could vary while running, so putting in DT doesn't make sense. I
> would break down settings like this:
> 
> broken h/w -> DT
> user tuning/config -> sysfs
> sensible defaults -> driver

Make sense.
we already have #2 and #3 in place, will rework this patch so we have a 
way to specify what is broken in h/w.

> 
>> Also, I think it is better to keep Link and device states tied, one 
>> reason
>> is that we can't keep device in sleep/active state when Link is in OFF
>> state.
> 
> The driver can tie the states to together if needed. Just document
> what's broken in DT and let the driver make decisions.

Yes, agreed.  will rework this patch so we have a way to specify what is 
broken in h/w and separate the device and link states (something like 
broken-hibern8, broken-sleep etc.)
Thanks for the suggestions.

> 
> Rob

-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH v2] ARM: dts: sun4i: A1000: add axp209 regulator nodes
From: Maxime Ripard @ 2016-12-20 19:17 UTC (permalink / raw)
  To: codekipper-Re5JQEeQqe8AvxtiuMwx3w
  Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20161220155542.22047-1-codekipper-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

[-- Attachment #1: Type: text/plain, Size: 568 bytes --]

On Tue, Dec 20, 2016 at 04:55:42PM +0100, codekipper-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org wrote:
> From: Marcus Cooper <codekipper-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> 
> This patch adds the regulator nodes for the axp209 by including
> the axp209 dtsi.
> 
> DCDC2 is used as the cpu power supply. This patch also references
> it from the cpu node.
> 
> Signed-off-by: Marcus Cooper <codekipper-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

Applied, thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

^ permalink raw reply

* Re: nfc: trf7970a: Prevent repeated polling from crashing the kernel
From: Justin Bronder @ 2016-12-20 19:13 UTC (permalink / raw)
  To: Mark Greer
  Cc: Geoff Lansberry, linux-wireless-u79uwXL29TY76Z2rM5mHXA,
	lauro.venancio-430g2QfJUUCGglJvpFV4uA,
	aloisio.almeida-430g2QfJUUCGglJvpFV4uA,
	sameo-VuQAYsv1563Yd54FQh9/CA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
	mark.rutland-5wv7dgnIgG8, netdev-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA, Jaret Cantu
In-Reply-To: <20161220185905.GA5867-luAo+O/VEmrlveNOaEYElw@public.gmane.org>

On 20/12/16 11:59 -0700, Mark Greer wrote:
> On Tue, Dec 20, 2016 at 11:16:32AM -0500, Geoff Lansberry wrote:
> > From: Jaret Cantu <jaret.cantu-jEh4hwF5bVhBDgjK7y7TUQ@public.gmane.org>
> > 
> > Repeated polling attempts cause a NULL dereference error to occur.
> > This is because the state of the trf7970a is currently reading but
> > another request has been made to send a command before it has finished.
> 
> How is this happening?  Was trf7970a_abort_cmd() called and it didn't
> work right?  Was it not called at all and there is a bug in the digital
> layer?  More details please.
> 
> > The solution is to properly kill the waiting reading (workqueue)
> > before failing on the send.
> 
> If the bug is in the calling code, then that is what should get fixed.
> This seems to be a hack to work-around a digital layer bug.

One of our uses of NFC is to begin polling to read a tag and then stop polling
(in order to save power) until we know via user interaction that we need to poll
again.  This is typically many minutes later so the power saving is pretty
significant.  However, it's possible that a user will remove the tag before
reading has completed.  We also detect this case and stop polling.  I can go
more into this if necessary but that is what exposed a panic.

You can reproduce using neard and python, in our testing it was very likely to
occur in 10-100 iterations of the following.:

    #!/usr/bin/python
    import time

    import dbus

    bus = dbus.SystemBus()
    nfc0 = bus.get_object('org.neard', '/org/neard/nfc0')
    props = dbus.Interface(nfc0, 'org.freedesktop.DBus.Properties')

    try:
        props.Set('org.neard.Adapter', 'Powered', dbus.Boolean(1))
    except:
        pass

    adapter = dbus.Interface(nfc0, 'org.neard.Adapter')

    for i in range(1000):
        adapter.StartPollLoop('Initiator')
        time.sleep(0.1)
        adapter.StopPollLoop()
        print(i)

I believe the last time we tested this was around the 4.1 release.

-- 
Justin Bronder
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH 0/2] net: hix5hd2_gmac: keep the compatible string not changed
From: David Miller @ 2016-12-20 19:13 UTC (permalink / raw)
  To: lidongpo
  Cc: robh+dt, mark.rutland, linux, yisen.zhuang, salil.mehta, arnd,
	andrew, xuejiancheng, benjamin.chenhao, caizhiyong, netdev,
	devicetree, linux-kernel
In-Reply-To: <1482199769-106501-1-git-send-email-lidongpo@hisilicon.com>

From: Dongpo Li <lidongpo@hisilicon.com>
Date: Tue, 20 Dec 2016 10:09:27 +0800

> This patch series fix the patch:
> d0fb6ba75dc0 ("net: hix5hd2_gmac: add generic compatible string")
> 
> The SoC hix5hd2 compatible string has the suffix "-gmac" and
> we should not change its compatible string.
> So we should name all the compatible string with the suffix "-gmac".
> Creating a new name suffix "-gemac" is unnecessary.

Series applied.

^ permalink raw reply

* Re: [PATCH 2/3] ARM: dts: sun6i: Add the SPDIF block to the A31
From: Maxime Ripard @ 2016-12-20 19:11 UTC (permalink / raw)
  To: Code Kipper; +Cc: linux-arm-kernel, devicetree, linux-sunxi
In-Reply-To: <CAEKpxBn4J0sXVx6b0d_v3LivnNS5WENp9DD6fFE9N6u=J=n7ww-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

[-- Attachment #1: Type: text/plain, Size: 2462 bytes --]

On Tue, Dec 20, 2016 at 03:34:10PM +0100, Code Kipper wrote:
> On 20 December 2016 at 15:07, Maxime Ripard
> <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> > Hi,
> >
> > On Tue, Dec 20, 2016 at 11:40:37AM +0100, codekipper-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org wrote:
> >> From: Marcus Cooper <codekipper-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> >>
> >> Add the SPDIF transceiver controller block to the A31 dtsi.
> >>
> >> Signed-off-by: Marcus Cooper <codekipper-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> >> ---
> >>  arch/arm/boot/dts/sun6i-a31.dtsi | 14 ++++++++++++++
> >>  1 file changed, 14 insertions(+)
> >>
> >> diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
> >> index 7370ba6c9993..559c53efa7e6 100644
> >> --- a/arch/arm/boot/dts/sun6i-a31.dtsi
> >> +++ b/arch/arm/boot/dts/sun6i-a31.dtsi
> >> @@ -613,6 +613,20 @@
> >>                       reg = <0x01c20ca0 0x20>;
> >>               };
> >>
> >> +             spdif: spdif@01c21000 {
> >> +                     #sound-dai-cells = <0>;
> >> +                     compatible = "allwinner,sun6i-a31-spdif";
> >> +                     reg = <0x01c21000 0x400>;
> >> +                     interrupts = <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>;
> >> +                     clocks = <&ccu CLK_APB1_SPDIF>, <&ccu CLK_SPDIF>;
> >> +                     resets = <&ccu RST_APB1_SPDIF>;
> >> +                     clock-names = "apb", "spdif";
> >> +                     dmas = <&dma 2>, <&dma 2>;
> >> +                     dma-names = "rx", "tx";
> >> +                     spdif-out = "disabled";
> >
> > That property isn't documented anywhere, and doesn't seem to be used
> > in your driver either.
>
> Ooops....do you want me to respin a new patch or will you do your
> magic with 'dd'?

Sorry, it's C-w for me :)

> It fell through the cracks as it was cherry picked from my dev
> branch where I was at one time playing with spdif-in. This has
> pretty much been relegated to the bottom of my todo/finish list.

I fixed and applied.

> > On a separate topic, is the channel inversion bug also found on the
> > A31?
>
> I have seen this and I'm sure that was also on my A31 hardware but
> I've just fired her up and the speaker test worked as expected. I also
> repeated the test on my A10 device and didn't hear the issue.

Ok.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

^ permalink raw reply

* Re: [PATCH 1/3] ARM: dts: sun6i: Add SPDIF TX pin to the A31
From: Maxime Ripard @ 2016-12-20 19:07 UTC (permalink / raw)
  To: codekipper-Re5JQEeQqe8AvxtiuMwx3w
  Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20161220104038.22532-2-codekipper-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

[-- Attachment #1: Type: text/plain, Size: 428 bytes --]

On Tue, Dec 20, 2016 at 11:40:36AM +0100, codekipper-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org wrote:
> From: Marcus Cooper <codekipper-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> 
> Add the SPDIF TX pin to the A31 dtsi.
> 
> Signed-off-by: Marcus Cooper <codekipper-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

Applied, thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

^ permalink raw reply

* Re: [PATCH] ARM: dts: sun6i: Mele I7: Enable internal audio codec
From: Maxime Ripard @ 2016-12-20 19:06 UTC (permalink / raw)
  To: codekipper-Re5JQEeQqe8AvxtiuMwx3w
  Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20161220102344.2519-1-codekipper-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

[-- Attachment #1: Type: text/plain, Size: 460 bytes --]

1;4600;0c
On Tue, Dec 20, 2016 at 11:23:44AM +0100, codekipper-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org wrote:
> From: Marcus Cooper <codekipper-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> 
> The Mele I7 has an audio jack for the SoC's internal codec.
> 
> Signed-off-by: Marcus Cooper <codekipper-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

Applied, thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

^ permalink raw reply

* [PATCH 4/4 v2] of/overlay: test count and destroy_last
From: Heinrich Schuchardt @ 2016-12-20 19:04 UTC (permalink / raw)
  To: Pantelis Antoniou, Rob Herring, Mark Rutland, Frank Rowand
  Cc: linux-kernel, devicetree, Heinrich Schuchardt
In-Reply-To: <20161220190455.25115-1-xypron.glpk@gmx.de>

In the unit tests check that the functions
of_overlay_destroy_last() and of_overlay_count()
work as expected.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
---

v2:
	Added this patch

 drivers/of/unittest.c | 15 ++++++++++++++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/drivers/of/unittest.c b/drivers/of/unittest.c
index 53c83d6..e3fbf0b 100644
--- a/drivers/of/unittest.c
+++ b/drivers/of/unittest.c
@@ -1466,6 +1466,7 @@ static void of_unittest_overlay_8(void)
 	struct device_node *np;
 	int ret, i, ov_id[2];
 	int overlay_nr = 8, unittest_nr = 8;
+	int count_before = of_overlay_count();
 
 	/* we don't care about device state in this test */
 
@@ -1485,6 +1486,12 @@ static void of_unittest_overlay_8(void)
 					overlay_path(overlay_nr + i));
 			return;
 		}
+
+		if (count_before + i + 1 != of_overlay_count()) {
+			unittest(0, "count does not increment by 1\n");
+			return;
+		}
+
 		ov_id[i] = ret;
 		of_unittest_track_overlay(ov_id[i]);
 	}
@@ -1501,7 +1508,7 @@ static void of_unittest_overlay_8(void)
 
 	/* removing them in order should work */
 	for (i = 1; i >= 0; i--) {
-		ret = of_overlay_destroy(ov_id[i]);
+		ret = of_overlay_destroy_last();
 		if (ret != 0) {
 			unittest(0, "overlay @\"%s\" not destroyed @\"%s\"\n",
 					overlay_path(overlay_nr + i),
@@ -1509,6 +1516,12 @@ static void of_unittest_overlay_8(void)
 						PDEV_OVERLAY));
 			return;
 		}
+
+		if (count_before + i != of_overlay_count()) {
+			unittest(0, "count does not decrement by 1\n");
+			return;
+		}
+
 		of_unittest_untrack_overlay(ov_id[i]);
 	}
 
-- 
2.10.2

^ permalink raw reply related

* [PATCH 3/4 v2] of/overlay: documentation for sysfs ABI
From: Heinrich Schuchardt @ 2016-12-20 19:04 UTC (permalink / raw)
  To: Pantelis Antoniou, Rob Herring, Mark Rutland, Frank Rowand
  Cc: linux-kernel, devicetree, Heinrich Schuchardt
In-Reply-To: <20161220190455.25115-1-xypron.glpk@gmx.de>

The sysfs filesystem ABI to load and unload device tree
overlays is decribed.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
---

v2:
	Change sysfs path to
	/sys/firmware/devicetree/overlays

 .../ABI/testing/sysfs-firmware-devicetree-overlays | 24 ++++++++++++++++++++++
 1 file changed, 24 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-firmware-devicetree-overlays

diff --git a/Documentation/ABI/testing/sysfs-firmware-devicetree-overlays b/Documentation/ABI/testing/sysfs-firmware-devicetree-overlays
new file mode 100644
index 0000000..bda0001
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-firmware-devicetree-overlays
@@ -0,0 +1,24 @@
+What:		/sys/firmware/devicetree/overlays
+Date:		Dec 2016
+KernelVersion:	4.11
+Contact:	Heinrich Schuchardt <xypron.glpk@gmx.de>
+Description:	Devicetree overlays can be used to update the devicetree
+		while the system is running. For details see
+		Documentation/devicetree/overlay-notes.txt.
+
+		The following attributes are provided:
+
+		load:	This is a write only file.
+			A string written to it is interpreted as the path to a
+			flattened device tree overlay file. It is used to create
+			and apply the contained overlays.
+
+		loaded: This is a read only file.
+			It provides the count of loaded overlays as a decimal
+			number.
+
+		unload: This is a write only file.
+		        If a positive number n is wrtten to this file the n
+			most recent overlays are destroyed.
+			If a negative number is written to this file all
+			overlays are destroyed.
-- 
2.10.2

^ permalink raw reply related

* [PATCH 2/4 v2] of/overlay: sysfs based ABI for dt overlays
From: Heinrich Schuchardt @ 2016-12-20 19:04 UTC (permalink / raw)
  To: Pantelis Antoniou, Rob Herring, Mark Rutland, Frank Rowand
  Cc: linux-kernel, devicetree, Heinrich Schuchardt
In-Reply-To: <20161220190455.25115-1-xypron.glpk@gmx.de>

Currently the kernel only supplies an internal API for creating
and destroying device tree overlays.

For some boards vendor specific kernel modules exist for
managing device tree overlays but the have not been
upstreamed.

This patch provides a sysfs based ABI for creation and destruction
of dt overlays in /sys/firmware/devicetree-overlay.

The following files are provided:

load:   This is a write only file.
        A string written to it is interpreted as the path to a
        flattened device tree overlay file. It is used to create
        and apply the contained overlays.

loaded: This is a read only file.
        It provides the count of loaded overlays as a decimal
        number.

unload: This is a write only file.
        If a positive number n is wrtten to this file the n
        most recent overlays are destroyed.
        If a negative number is written to this file all
        overlays are destroyed.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
---

v2:
	Change sysfs path to
	/sys/firmware/devicetree/overlays.
	Add 'select CONFIG_OF_EARLY_FLATTREE' to Kconfig.

 drivers/of/Kconfig    |  15 ++++
 drivers/of/Makefile   |   2 +
 drivers/of/base.c     |   1 +
 drivers/of/ov_sysfs.c | 223 ++++++++++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 241 insertions(+)
 create mode 100644 drivers/of/ov_sysfs.c

diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
index ba7b034..09ff057 100644
--- a/drivers/of/Kconfig
+++ b/drivers/of/Kconfig
@@ -109,6 +109,21 @@ config OF_OVERLAY
 	  While this option is selected automatically when needed, you can
 	  enable it manually to improve device tree unit test coverage.
 
+if OF_OVERLAY
+
+config OF_OVERLAY_SYSFS
+
+	tristate "Sysfs support for device tree overlays"
+	default m
+	depends on SYSFS
+	select OF_EARLY_FLATTREE
+	help
+	  This module provides a sysfs based ABI to manage device tree
+	  overlays. You can use it to create overlays based on flattened
+	  device tree overlay files and to destroy them.
+
+endif # OF_OVERLAY
+
 config OF_NUMA
 	bool
 
diff --git a/drivers/of/Makefile b/drivers/of/Makefile
index d7efd9d..7026de4 100644
--- a/drivers/of/Makefile
+++ b/drivers/of/Makefile
@@ -16,3 +16,5 @@ obj-$(CONFIG_OF_OVERLAY) += overlay.o
 obj-$(CONFIG_OF_NUMA) += of_numa.o
 
 obj-$(CONFIG_OF_UNITTEST) += unittest-data/
+
+obj-$(CONFIG_OF_OVERLAY_SYSFS) += ov_sysfs.o
diff --git a/drivers/of/base.c b/drivers/of/base.c
index d4bea3c..8cffe38 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -43,6 +43,7 @@ struct device_node *of_stdout;
 static const char *of_stdout_options;
 
 struct kset *of_kset;
+EXPORT_SYMBOL(of_kset);
 
 /*
  * Used to protect the of_aliases, to hold off addition of nodes to sysfs.
diff --git a/drivers/of/ov_sysfs.c b/drivers/of/ov_sysfs.c
new file mode 100644
index 0000000..f3fcb70
--- /dev/null
+++ b/drivers/of/ov_sysfs.c
@@ -0,0 +1,223 @@
+/*
+ * Sysfs ABI for device tree overlays
+ *
+ * Copyright (C) 2016  Heinrich Schuchardt <xypron.glpk@gmx.de>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License,
+ * version 2 as published by the Free Software Foundation.
+ */
+
+#include <linux/fcntl.h>
+#include <linux/file.h>
+#include <linux/fs.h>
+#include <linux/kernel.h>
+#include <linux/libfdt.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_fdt.h>
+#include <linux/slab.h>
+#include <linux/vmalloc.h>
+#include <linux/uaccess.h>
+
+#include "of_private.h"
+
+static int of_create_overlay_from_file(const char *path)
+{
+	struct file *filp = NULL;
+	mm_segment_t fs;
+	int ret = 0;
+	loff_t size;
+	char *buffer = NULL;
+	ssize_t bytes_read;
+	loff_t offset = 0;
+	struct device_node *overlay = NULL;
+
+	fs = get_fs();
+	set_fs(get_ds());
+	filp = filp_open(path, O_RDONLY | O_LARGEFILE, 0);
+	if (IS_ERR(filp)) {
+		ret = PTR_ERR(filp);
+		goto err_file_open;
+	}
+
+	if (!S_ISREG(filp->f_inode->i_mode)) {
+		ret = -EISDIR;
+		goto err_file_read;
+	}
+	size = i_size_read(filp->f_inode);
+	buffer = vmalloc(size);
+	if (buffer == NULL) {
+		ret = -ENOMEM;
+		goto err_malloc;
+	}
+	for (; size > 0; ) {
+		bytes_read = vfs_read(filp, buffer, size, &offset);
+		if (bytes_read == 0)
+			break;
+		if (bytes_read < 0) {
+			ret = bytes_read;
+			goto err_file_read;
+		}
+		size -= bytes_read;
+	}
+	if (offset < sizeof(struct fdt_header) ||
+	    offset < fdt_totalsize(buffer)) {
+		pr_err("OF: Size of %s does not match header information\n",
+		       path);
+		ret = -EINVAL;
+		goto err_file_read;
+	}
+	overlay = of_fdt_unflatten_tree((unsigned long *) buffer, NULL, NULL);
+	if (overlay == NULL) {
+		pr_err("OF: Cannot unflatten %s\n", path);
+		ret = -EINVAL;
+		goto err_file_read;
+	}
+	of_node_set_flag(overlay, OF_DETACHED);
+	ret = of_resolve_phandles(overlay);
+	if (ret < 0) {
+		pr_err("OF: Failed to resolve phandles for %s\n", path);
+		goto err_overlay;
+	}
+	ret = of_overlay_create(overlay);
+	if (ret < 0) {
+		pr_err("OF: Cannot create overlay from %s\n", path);
+	} else {
+		pr_info("OF: Overlay %d created from %s\n", ret, path);
+		ret = 0;
+	}
+err_overlay:
+	of_node_put(overlay);
+err_file_read:
+	vfree(buffer);
+err_malloc:
+	fput(filp);
+err_file_open:
+	set_fs(fs);
+	return ret;
+}
+
+static ssize_t attribute_read(struct kobject *kobj,
+			      struct kobj_attribute *attr,
+			      char *buf)
+{
+	int ret;
+
+	if (strcmp(attr->attr.name, "loaded") == 0)
+		ret = sprintf(buf, "%d\n", of_overlay_count());
+	else
+		ret = -ENOENT;
+
+	return ret;
+}
+
+static ssize_t attribute_write(struct kobject *kobj,
+			       struct kobj_attribute *attr,
+			       const char *buf, size_t size)
+{
+	char *parameter;
+	int ret;
+	long count;
+
+	if (size > PATH_MAX)
+		return -ENAMETOOLONG;
+
+	/* The parameter has to be terminated either by LF or \0. */
+
+	switch (buf[size - 1]) {
+	case 0x00:
+	case 0x0a:
+		break;
+	default:
+		return -ENOENT;
+	}
+	parameter = vmalloc(size);
+	if (!parameter)
+		return -ENOMEM;
+	memcpy(parameter, buf, size);
+	parameter[size - 1] = 0x00;
+
+	if (strcmp(attr->attr.name, "load") == 0) {
+		ret = of_create_overlay_from_file(parameter);
+		if (!ret)
+			ret = size;
+	} else if (strcmp(attr->attr.name, "unload") == 0) {
+		ret = kstrtol(parameter, 0, &count);
+		if (ret)
+			goto out;
+		if (count < 0)
+			ret = of_overlay_destroy_all();
+		else
+			for (; count > 0; --count) {
+				ret = of_overlay_destroy_last();
+				if (ret)
+					goto out;
+			}
+		ret = size;
+	} else
+		ret = -ENOENT;
+out:
+	vfree(parameter);
+
+	return ret;
+}
+
+static struct kobject *kobj;
+
+static struct kobj_attribute load_attribute =
+	__ATTR(load, 0200, NULL, attribute_write);
+static struct kobj_attribute loaded_attribute =
+	__ATTR(loaded, 0444, attribute_read, NULL);
+static struct kobj_attribute unload_attribute =
+	__ATTR(unload, 0200, NULL, attribute_write);
+static struct attribute *attrs[] = {
+	&load_attribute.attr,
+	&loaded_attribute.attr,
+	&unload_attribute.attr,
+	NULL
+};
+static struct attribute_group attr_group = {
+	.attrs = attrs,
+};
+
+static int __init ov_sysfs_init(void)
+{
+	int ret;
+
+	if (!of_kset) {
+		pr_err("OF: failed to register overlays\n");
+		return -ENODEV;
+	}
+
+	kobj = kobject_create_and_add("overlays", &of_kset->kobj);
+	if (kobj == 0) {
+		pr_err("OF: failed to register overlays\n");
+		return -ENOMEM;
+	}
+	ret = sysfs_create_group(kobj, &attr_group);
+	if (ret) {
+		kobject_put(kobj);
+		return ret;
+	}
+
+	/*
+	 * It is not possible to ensure that no sysfs io is started while
+	 * module_exit is called. So disable unloading.
+	 */
+	__module_get(THIS_MODULE);
+
+	return 0;
+}
+
+static void __exit ov_sysfs_exit(void)
+{
+	kobject_put(kobj);
+}
+
+module_init(ov_sysfs_init);
+module_exit(ov_sysfs_exit);
+
+MODULE_AUTHOR("Heinrich Schuchardt <xypron.glpk@gmx.de>");
+MODULE_DESCRIPTION("Sysfs ABI for device tree overlays");
+MODULE_LICENSE("GPL v2");
-- 
2.10.2

^ permalink raw reply related

* [PATCH 1/4 v2] of/overlay: add API function to count and pop last
From: Heinrich Schuchardt @ 2016-12-20 19:04 UTC (permalink / raw)
  To: Pantelis Antoniou, Rob Herring, Mark Rutland, Frank Rowand
  Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA, Heinrich Schuchardt
In-Reply-To: <20161220190455.25115-1-xypron.glpk-Mmb7MZpHnFY@public.gmane.org>

To allow building interfaces which are not id based
two new functions are added to the device tree
overlay API:

of_overlay_count        - counts the loaded overlays
of_overlay_destroy_last - removes the last overlay loaded

Signed-off-by: Heinrich Schuchardt <xypron.glpk-Mmb7MZpHnFY@public.gmane.org>
---

v2:
	Add missing inline attribute for ov_overlay_count.

 Documentation/devicetree/overlay-notes.txt |  7 +++--
 drivers/of/overlay.c                       | 50 ++++++++++++++++++++++++++++++
 include/linux/of.h                         | 12 +++++++
 3 files changed, 67 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/overlay-notes.txt b/Documentation/devicetree/overlay-notes.txt
index d418a6c..7c8099c 100644
--- a/Documentation/devicetree/overlay-notes.txt
+++ b/Documentation/devicetree/overlay-notes.txt
@@ -89,17 +89,20 @@ Overlay in-kernel API
 
 The API is quite easy to use.
 
-1. Call of_overlay_create() to create and apply an overlay. The return value
+Call of_overlay_create() to create and apply an overlay. The return value
 is a cookie identifying this overlay.
 
-2. Call of_overlay_destroy() to remove and cleanup the overlay previously
+Call of_overlay_destroy() to remove and cleanup the overlay previously
 created via the call to of_overlay_create(). Removal of an overlay that
 is stacked by another will not be permitted.
+Or call of_overlay_destroy_last() to remove the most recent overlay.
 
 Finally, if you need to remove all overlays in one-go, just call
 of_overlay_destroy_all() which will remove every single one in the correct
 order.
 
+Call of_overlay_count() to determine the number of loaded overlays.
+
 Overlay DTS Format
 ------------------
 
diff --git a/drivers/of/overlay.c b/drivers/of/overlay.c
index 0d4cda7..bd30253 100644
--- a/drivers/of/overlay.c
+++ b/drivers/of/overlay.c
@@ -587,3 +587,53 @@ int of_overlay_destroy_all(void)
 	return 0;
 }
 EXPORT_SYMBOL_GPL(of_overlay_destroy_all);
+
+/**
+ * of_overlay_destroy_last() - Removes the last overlay from the system
+ *
+ * It is allways possible to delete the last overlay.
+ *
+ * Returns 0 on success, or a negative error number
+ */
+int of_overlay_destroy_last(void)
+{
+	struct of_overlay *ov, *ovn;
+	int id;
+
+	mutex_lock(&of_mutex);
+
+	list_for_each_entry_safe_reverse(ov, ovn, &ov_list, node) {
+		id = ov->id;
+		mutex_unlock(&of_mutex);
+		return of_overlay_destroy(id);
+	}
+
+	mutex_unlock(&of_mutex);
+
+	pr_info("destroy: No overlay to destroy");
+
+	return -ENODEV;
+}
+EXPORT_SYMBOL_GPL(of_overlay_destroy_last);
+
+/**
+ * of_overlay_count - Counts number of loaded overlays
+ *
+ * Returns number of loaded overlays
+ */
+int of_overlay_count(void)
+{
+	struct of_overlay *ov, *ovn;
+	int count = 0;
+
+	mutex_lock(&of_mutex);
+
+	list_for_each_entry_safe(ov, ovn, &ov_list, node) {
+		++count;
+	}
+
+	mutex_unlock(&of_mutex);
+
+	return count;
+}
+EXPORT_SYMBOL_GPL(of_overlay_count);
diff --git a/include/linux/of.h b/include/linux/of.h
index d72f010..5ca3523 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -1281,15 +1281,22 @@ struct of_overlay_notify_data {
 #ifdef CONFIG_OF_OVERLAY
 
 /* ID based overlays; the API for external users */
+int of_overlay_count(void);
 int of_overlay_create(struct device_node *tree);
 int of_overlay_destroy(int id);
 int of_overlay_destroy_all(void);
+int of_overlay_destroy_last(void);
 
 int of_overlay_notifier_register(struct notifier_block *nb);
 int of_overlay_notifier_unregister(struct notifier_block *nb);
 
 #else
 
+static inline int of_overlay_count(void)
+{
+	return -ENOTSUPP;
+}
+
 static inline int of_overlay_create(struct device_node *tree)
 {
 	return -ENOTSUPP;
@@ -1305,6 +1312,11 @@ static inline int of_overlay_destroy_all(void)
 	return -ENOTSUPP;
 }
 
+static inline int of_overlay_destroy_last(void)
+{
+	return -ENOTSUPP;
+}
+
 static inline int of_overlay_notifier_register(struct notifier_block *nb)
 {
 	return 0;
-- 
2.10.2

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply related

* [PATCH 0/4 v2] of/overlay: sysfs based ABI for dt overlays
From: Heinrich Schuchardt @ 2016-12-20 19:04 UTC (permalink / raw)
  To: Pantelis Antoniou, Rob Herring, Mark Rutland, Frank Rowand
  Cc: linux-kernel, devicetree, Heinrich Schuchardt

Currently the kernel only supplies an internal API for creating
and destroying device tree overlays.

For some boards vendor specific kernel modules exist for
managing device tree overlays but they have not been
upstreamed or upstreaming stalled.
https://lkml.org/lkml/2015/6/12/624
https://lkml.org/lkml/2013/1/7/366

This patch series provides a sysfs based ABI for creation and
destruction of dt overlays in /sys/firmware/devicetree/overlays.

The following files are provided:

load:   This is a write only file.
        A string written to it is interpreted as the path to a
        flattened device tree overlay file. It is used to create
        and apply the contained overlays.

loaded: This is a read only file.
        It provides the count of loaded overlays as a decimal
        number.

unload: This is a write only file.
        If a positive number n is wrtten to this file the n
        most recent overlays are destroyed.
        If a negative number is written to this file all
        overlays are destroyed.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

version 2:
	change sysfs path to
	/sys/firmware/devicetree/overlays

	Fix errors indicated by kbuild robot:
	Add missing inline attribute to of_overlay_count
	in patch 1.
	Add 'select CONFIG_OF_EARLY_FLATTREE' to Kconfig
	in patch 2.

	Change unit test cases to check new functions
	of_overlay_count and of_overlay_destroy_last.

Heinrich Schuchardt (4):
  of/overlay: add API function to count and pop last
  of/overlay: sysfs based ABI for dt overlays
  of/overlay: documentation for sysfs ABI 
  of/overlay: test count and destroy_last

 .../ABI/testing/sysfs-firmware-devicetree-overlays |  24 +++ 
 Documentation/devicetree/overlay-notes.txt         |   7 +-
 drivers/of/Kconfig                                 |  15 ++
 drivers/of/Makefile                                |   2 + 
 drivers/of/base.c                                  |   1 + 
 drivers/of/ov_sysfs.c                              | 223 +++++++++++++++++++++
 drivers/of/overlay.c                               |  50 +++++
 drivers/of/unittest.c                              |  15 +-
 include/linux/of.h                                 |  12 ++
 9 files changed, 346 insertions(+), 3 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-firmware-devicetree-overlays
 create mode 100644 drivers/of/ov_sysfs.c

-- 
2.11.0

^ permalink raw reply

* Re: [PATCH 3/3] nfc: trf7970a: Prevent repeated polling from crashing the kernel
From: Mark Greer @ 2016-12-20 18:59 UTC (permalink / raw)
  To: Geoff Lansberry
  Cc: linux-wireless, lauro.venancio, aloisio.almeida, sameo, robh+dt,
	mark.rutland, netdev, devicetree, linux-kernel, justin,
	Jaret Cantu
In-Reply-To: <1482250592-4268-3-git-send-email-glansberry@gmail.com>

On Tue, Dec 20, 2016 at 11:16:32AM -0500, Geoff Lansberry wrote:
> From: Jaret Cantu <jaret.cantu@timesys.com>
> 
> Repeated polling attempts cause a NULL dereference error to occur.
> This is because the state of the trf7970a is currently reading but
> another request has been made to send a command before it has finished.

How is this happening?  Was trf7970a_abort_cmd() called and it didn't
work right?  Was it not called at all and there is a bug in the digital
layer?  More details please.

> The solution is to properly kill the waiting reading (workqueue)
> before failing on the send.

If the bug is in the calling code, then that is what should get fixed.
This seems to be a hack to work-around a digital layer bug.

Mark
--

^ permalink raw reply

* Re: [PATCH] ARM: dts: sun8i: add a delay after reset xr819 on Orange Pi Zero
From: Maxime Ripard @ 2016-12-20 18:58 UTC (permalink / raw)
  To: Icenowy Zheng
  Cc: Hans de Goede, Chen-Yu Tsai, linux-kernel, linux-arm-kernel,
	devicetree
In-Reply-To: <20161220055826.30725-1-icenowy@aosc.xyz>


[-- Attachment #1.1: Type: text/plain, Size: 448 bytes --]

On Tue, Dec 20, 2016 at 01:58:26PM +0800, Icenowy Zheng wrote:
> XR819 seems to need a delay after its reset line to be deasserted,
> otherwise it may not respond MMC commands correctly, and fail to
> initialize.
> 
> Add a 200ms delay in the mmc-pwrseq.
> 
> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>

Applied, thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH v3 2/2] iio: adc: hx711: Add IIO driver for AVIA HX711
From: Lars-Peter Clausen @ 2016-12-20 18:55 UTC (permalink / raw)
  To: Andreas Klinger
  Cc: devicetree, linux-iio, linux-kernel, robh+dt, pawel.moll,
	mark.rutland, ijc+devicetree, galak, jic23, knaack.h, pmeerw
In-Reply-To: <20161220103346.GA1318@imap.1und1.de>

On 12/20/2016 11:33 AM, Andreas Klinger wrote:
>>> +static struct attribute *hx711_attributes[] = {
>>> +	&iio_dev_attr_gain.dev_attr.attr,
>>
>> For IIO devices the gain is typically expressed through the scale attribute.
>> Which is kind of the inverse of gain. It would be good if this driver
>> follows this standard notation. The scale is the value of 1LSB in mV. So
>> this includes the resolution of the ADC, the reference voltage and any gain
>> that is applied to the input signal.
>>
>> The possible values can be listed in the scale_available attribute.
>>
> 
> The reference voltage is in the hardware. 
> Should i use a DT entry for the reference voltage? 
> Or is it better to use a buildin scale and make it changeable?

Typically the reference voltage is specified through the devicetree using a
regulator. Have a look at e.g. ad7291.c.

> 
> 
>>> +	NULL,
>>> +};
>>> +
>>> +static struct attribute_group hx711_attribute_group = {
>>> +	.attrs = hx711_attributes,
>>> +};
>>> +
>>> +static const struct iio_info hx711_iio_info = {
>>> +	.driver_module		= THIS_MODULE,
>>> +	.read_raw		= hx711_read_raw,
>>> +	.attrs			= &hx711_attribute_group,
>>> +};
>>> +
>>> +static const struct iio_chan_spec hx711_chan_spec[] = {
>>> +	{ .type = IIO_VOLTAGE,
>>> +		.info_mask_separate =
>>> +			BIT(IIO_CHAN_INFO_RAW),
>>
>> Given that there are two separate physical input channels this should be
>> expressed here and there should be two IIO channels for the device.
>>
> 
> One who is toggling between channel A and B will cause a dummy read
> additional to every normal read. 
> 
> Should i offer a "toggling mode" which means that after reading
> channel A the channel B is selected for the next read and after
> reading channel B channel A is selected? Simply expecting the channel
> is toggled on every read. If it's not toggled there need to be a dummy 
> read, of course. This should be an attribute, right?

I don't think that is necessary. On one hand when doing these kind of single
shot conversions there is often not a predictable pattern on the other hand
such custom device specific attributes are difficult to handle in a generic
framework. We try to establish standard semantics so a generic application
is able to talk to a wide range of devices. When a device implements custom
attributes that becomes more difficult.

And there is also buffered mode. In buffered mode the application can select
the channels which the converter should cycle through and connect a trigger
like a timer to schedule the conversions. If switching between A and B in a
circular way is required I'd recommend to implement this by using buffered mode.

^ permalink raw reply

* Re: [PATCH net 0/3] Fix integration of eee-broken-modes
From: David Miller @ 2016-12-20 18:51 UTC (permalink / raw)
  To: jbrunet
  Cc: netdev, devicetree, f.fainelli, carlo, khilman,
	martin.blumenstingl, neolynx, andrew, narmstrong, linux-amlogic,
	linux-arm-kernel, linux-kernel, julia.lawall, yegorslists,
	afaerber
In-Reply-To: <1482159938-13239-1-git-send-email-jbrunet@baylibre.com>

From: Jerome Brunet <jbrunet@baylibre.com>
Date: Mon, 19 Dec 2016 16:05:35 +0100

> The purpose of this series is to fix the integration of the ethernet phy
> property "eee-broken-modes" [0]
> 
> The v3 of this series has been merged, missing a fix (error reported by
> kbuild robot) available in the v4 [1]
> 
> More importantly, Florian opposed adding a DT property mapping a device
> register this directly [2]. The concern was that the property could be
> abused to implement platform configuration policy. After discussing it,
> I think we agreed that such information about the HW (defect) should appear
> in the platform DT. However, the preferred way is to add a boolean property
> for each EEE broken mode.
> 
> [0]: http://lkml.kernel.org/r/1480326409-25419-1-git-send-email-jbrunet@baylibre.com
> [1]: http://lkml.kernel.org/r/1480348229-25672-1-git-send-email-jbrunet@baylibre.com
> [2]: http://lkml.kernel.org/r/e14a3b0c-dc34-be14-48b3-518a0ad0c080@gmail.com

Series applied, thank you.

^ permalink raw reply

* [PATCH v2 pci/next] PCI: rcar: Add compatible string for r8a7796
From: Yoshihiro Kaneko @ 2016-12-20 18:37 UTC (permalink / raw)
  To: linux-pci
  Cc: Bjorn Helgaas, Simon Horman, Magnus Damm, Geert Uytterhoeven,
	linux-renesas-soc, devicetree

From: Harunobu Kurokawa <harunobu.kurokawa.dn@renesas.com>

This patch adds support for r8a7796.

Signed-off-by: Harunobu Kurokawa <harunobu.kurokawa.dn@renesas.com>
Signed-off-by: Yoshihiro Kaneko <ykaneko0929@gmail.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
---

This patch is based on the next branch of the pci tree.

v2 [Yoshihiro Kaneko]
* As suggested by Geert Uytterhoeven
  Dropped the update of the driver.

 Documentation/devicetree/bindings/pci/rcar-pci.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/pci/rcar-pci.txt b/Documentation/devicetree/bindings/pci/rcar-pci.txt
index eee518d..34712d6 100644
--- a/Documentation/devicetree/bindings/pci/rcar-pci.txt
+++ b/Documentation/devicetree/bindings/pci/rcar-pci.txt
@@ -6,6 +6,7 @@ compatible: "renesas,pcie-r8a7779" for the R8A7779 SoC;
 	    "renesas,pcie-r8a7791" for the R8A7791 SoC;
 	    "renesas,pcie-r8a7793" for the R8A7793 SoC;
 	    "renesas,pcie-r8a7795" for the R8A7795 SoC;
+	    "renesas,pcie-r8a7796" for the R8A7796 SoC;
 	    "renesas,pcie-rcar-gen2" for a generic R-Car Gen2 compatible device.
 	    "renesas,pcie-rcar-gen3" for a generic R-Car Gen3 compatible device.
 
-- 
1.9.1

^ permalink raw reply related


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox