* [PATCH v2 15/18] drivers/fsi: Add documentation for GPIO based FSI master
From: christopher.lee.bostic at gmail.com @ 2017-01-12 22:35 UTC (permalink / raw)
To: linux-arm-kernel
From: Chris Bostic <cbostic@us.ibm.com>
Define the device tree bindings for the GPIO master type.
Signed-off-by: Chris Bostic <cbostic@us.ibm.com>
---
V2 - Break out this documentation update from the code implementing
The GPIO master function.
- Move the documentation to an earlier patch than the code
implementing the function.
- Document all 'compatible' strings used in the series.
- Write binding document in terms of hardware, not software.
- Elaborate on what a GPIO based FSI master is versus a non
GPIO based master.
- Give a more detailed description of what each pin in the GPIO
FSI master is to be used for.
- Re-order compatible strings in example so that most specific
comes first.
- Indicate the proper order each pin should be initialized.
- Fix an unmatched '>' bracket in the example for binding.
- Bracket each element of the example list items individually.
---
.../devicetree/bindings/fsi/fsi-master-gpio.txt | 71 ++++++++++++++++++++++
1 file changed, 71 insertions(+)
create mode 100644 Documentation/devicetree/bindings/fsi/fsi-master-gpio.txt
diff --git a/Documentation/devicetree/bindings/fsi/fsi-master-gpio.txt b/Documentation/devicetree/bindings/fsi/fsi-master-gpio.txt
new file mode 100644
index 0000000..5d589bf
--- /dev/null
+++ b/Documentation/devicetree/bindings/fsi/fsi-master-gpio.txt
@@ -0,0 +1,71 @@
+Device-tree bindings for FSI master implemented with GPIO
+---------------------------------------------------------
+
+Typically a FSI master is defined in hardware with output control
+lines designated for Enable, Data, Clock, etc.. In the case of
+a 'GPIO FSI master', however, it may be the case that there is no
+such master defined in hardware and must be implemented in standard
+GPIO to interact with its slaves. In this 'virtual' FSI master
+case the GPIO pins representing clk and data are directly
+connected to the slaves.
+
+The GPIO FSI master node
+-------------------------
+This node describes a FSI master implmented with GPIO.
+Required property:
+ compatible = "ibm,fsi-master-gpio"
+
+The standard FSI master node
+----------------------------
+This node describes a FSI master implmemented fully in hardware
+with dedicated input/output pins required for its function (i.e.
+not using generic GPIO pins).
+Required property:
+ compatible = "ibm,fsi-master"
+
+
+GPIO FSI master property/pin descriptions
+------------------------------------------
+clk - The master controlled clock line that indicates to the
+ slave when to read in or send out new data - required.
+data - The serial data line containing information to be sent or
+ received by the master. This line is bi-directional. During
+ command phase the master controls the line and when a response
+ is required the slave takes control - required.
+enable - Controls power state of data line - optional.
+trans - Voltage translator control. In some applications the data line
+ must have its signal levels altered by a translator. If this is
+ necessary then control of signal direction is managed via this
+ line - optional.
+mux - Multiplexor control. This activates/deactivates the data line
+ in cases where it is one of many possible selections via mux -
+ optional.
+
+Required properties:
+ - compatible = "ibm,fsi-master-gpio";
+ - clk-gpios;
+ - data-gpios;
+
+Optional properties:
+ - enable-gpios;
+ - trans-gpios;
+ - mux-gpios;
+
+Order of property activation:
+1. clk
+2. data
+3. trans
+4. enable
+5. mux
+
+
+Example:
+
+fsi-master {
+ compatible = "ibm,fsi-master-gpio", "ibm,fsi-master";
+ clk-gpios = <&gpio 0>, <&gpio 6>;
+ data-gpios = <&gpio 1>, <&gpio 7>;
+ enable-gpios = <&gpio 2>, <&gpio 8>;
+ trans-gpios = <&gpio 3>, <&gpio 9>;
+ mux-gpios = <&gpio 4>, <&gpio 10>;
+}
--
1.8.2.2
^ permalink raw reply related
* [PATCH v2 16/18] drivers/fsi: Document FSI master sysfs files in ABI
From: christopher.lee.bostic at gmail.com @ 2017-01-12 22:36 UTC (permalink / raw)
To: linux-arm-kernel
From: Chris Bostic <cbostic@us.ibm.com>
Add info for sysfs scan file in Documentaiton ABI/testing
Signed-off-by: Chris Bostic <cbostic@us.ibm.com>
---
Documentation/ABI/testing/sysfs-bus-fsi | 6 ++++++
1 file changed, 6 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-bus-fsi
diff --git a/Documentation/ABI/testing/sysfs-bus-fsi b/Documentation/ABI/testing/sysfs-bus-fsi
new file mode 100644
index 0000000..dfcbc1b
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-fsi
@@ -0,0 +1,6 @@
+What: /sys/bus/platform/devices/fsi-master/scan
+KernelVersion: 4.9
+Contact: cbostic at us.ibm.com
+Description:
+ Initiates a FSI master scan for all connected
+ slave devices on its links.
--
1.8.2.2
^ permalink raw reply related
* [PATCH v2 17/18] drivers/fsi: Add GPIO based FSI master
From: christopher.lee.bostic at gmail.com @ 2017-01-12 22:37 UTC (permalink / raw)
To: linux-arm-kernel
From: Chris Bostic <cbostic@us.ibm.com>
Implement a FSI master using GPIO. Will generate FSI protocol for
read and write commands to particular addresses. Sends master command
and waits for and decodes a slave response.
Includes Jeremy Kerr's original GPIO master base commit.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Chris Bostic <cbostic@us.ibm.com>
---
V2 - Merge fsi_master_gpio_init() into probe.
- Remove scan sysfs file creation since its now created in the
core.
- Set pin initial output values at time of requesting the pins
from the gpio driver.
- Assign value to master->master.dev at probe time.
- Use the get_optional gpio driver interface for all optional
pins.
---
drivers/fsi/Kconfig | 11 +
drivers/fsi/Makefile | 1 +
drivers/fsi/fsi-master-gpio.c | 530 ++++++++++++++++++++++++++++++++++++++++++
3 files changed, 542 insertions(+)
create mode 100644 drivers/fsi/fsi-master-gpio.c
diff --git a/drivers/fsi/Kconfig b/drivers/fsi/Kconfig
index 04c1a0e..9cf8345 100644
--- a/drivers/fsi/Kconfig
+++ b/drivers/fsi/Kconfig
@@ -9,4 +9,15 @@ config FSI
---help---
FSI - the FRU Support Interface - is a simple bus for low-level
access to POWER-based hardware.
+
+if FSI
+
+config FSI_MASTER_GPIO
+ tristate "GPIO-based FSI master"
+ depends on FSI && GPIOLIB
+ ---help---
+ This option enables a FSI master driver using GPIO lines.
+
+endif
+
endmenu
diff --git a/drivers/fsi/Makefile b/drivers/fsi/Makefile
index db0e5e7..ed28ac0 100644
--- a/drivers/fsi/Makefile
+++ b/drivers/fsi/Makefile
@@ -1,2 +1,3 @@
obj-$(CONFIG_FSI) += fsi-core.o
+obj-$(CONFIG_FSI_MASTER_GPIO) += fsi-master-gpio.o
diff --git a/drivers/fsi/fsi-master-gpio.c b/drivers/fsi/fsi-master-gpio.c
new file mode 100644
index 0000000..b549d0b
--- /dev/null
+++ b/drivers/fsi/fsi-master-gpio.c
@@ -0,0 +1,530 @@
+/*
+ * FSI GPIO based master driver
+ *
+ * Copyright (C) IBM Corporation 2016
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ *
+ * A FSI master controller, using a simple GPIO bit-banging interface
+ */
+
+#include <linux/platform_device.h>
+#include <linux/gpio/consumer.h>
+#include <linux/module.h>
+#include <linux/delay.h>
+#include <linux/fsi.h>
+#include <linux/device.h>
+#include <linux/io.h>
+#include <linux/spinlock.h>
+#include <linux/crc-fsi.h>
+
+#include "fsi-master.h"
+
+#define FSI_GPIO_STD_DLY 1 /* Standard pin delay in nS */
+#define FSI_ECHO_DELAY_CLOCKS 16 /* Number clocks for echo delay */
+#define FSI_PRE_BREAK_CLOCKS 50 /* Number clocks to prep for break */
+#define FSI_BREAK_CLOCKS 256 /* Number of clocks to issue break */
+#define FSI_POST_BREAK_CLOCKS 16000 /* Number clocks to set up cfam */
+#define FSI_INIT_CLOCKS 5000 /* Clock out any old data */
+#define FSI_GPIO_STD_DELAY 10 /* Standard GPIO delay in nS */
+ /* todo: adjust down as low as */
+ /* possible or eliminate */
+#define FSI_GPIO_CMD_DPOLL 0x000000000000002AULL
+#define FSI_GPIO_CMD_DPOLL_SIZE 9
+#define FSI_GPIO_DPOLL_CLOCKS 100 /* < 21 will cause slave to hang */
+#define FSI_GPIO_CMD_DEFAULT 0x2000000000000000ULL
+#define FSI_GPIO_CMD_WRITE 0
+#define FSI_GPIO_CMD_READ 0x0400000000000000ULL
+#define FSI_GPIO_CMD_SLAVE_MASK 0xC000000000000000ULL
+#define FSI_GPIO_CMD_ADDR_SHIFT 37
+#define FSI_GPIO_CMD_ADDR_MASK 0x001FFFFF
+#define FSI_GPIO_CMD_SLV_SHIFT 62
+#define FSI_GPIO_CMD_SIZE_16 0x0000001000000000ULL
+#define FSI_GPIO_CMD_SIZE_32 0x0000003000000000ULL
+#define FSI_GPIO_CMD_DT32_SHIFT 4
+#define FSI_GPIO_CMD_DT16_SHIFT 20
+#define FSI_GPIO_CMD_DT8_SHIFT 28
+#define FSI_GPIO_CMD_DFLT_LEN 28
+#define FSI_GPIO_CMD_CRC_SHIFT 60
+
+/* Bus errors */
+#define FSI_GPIO_ERR_BUSY 1 /* Slave stuck in busy state */
+#define FSI_GPIO_RESP_ERRA 2 /* Any (misc) Error */
+#define FSI_GPIO_RESP_ERRC 3 /* Slave reports master CRC error */
+#define FSI_GPIO_MTOE 4 /* Master time out error */
+#define FSI_GPIO_CRC_INVAL 5 /* Master reports slave CRC error */
+
+/* Normal slave responses */
+#define FSI_GPIO_RESP_BUSY 1
+#define FSI_GPIO_RESP_ACK 0
+#define FSI_GPIO_RESP_ACKD 4
+
+#define FSI_GPIO_MAX_BUSY 100
+#define FSI_GPIO_MTOE_COUNT 1000
+#define FSI_GPIO_DRAIN_BITS 20
+#define FSI_GPIO_CRC_SIZE 4
+#define FSI_GPIO_MSG_ID_SIZE 2
+#define FSI_GPIO_MSG_RESPID_SIZE 2
+#define FSI_GPIO_PRIME_SLAVE_CLOCKS 100
+
+static DEFINE_SPINLOCK(fsi_gpio_cmd_lock); /* lock around fsi commands */
+
+struct fsi_master_gpio {
+ struct fsi_master master;
+ struct gpio_desc *gpio_clk;
+ struct gpio_desc *gpio_data;
+ struct gpio_desc *gpio_trans; /* Voltage translator */
+ struct gpio_desc *gpio_enable; /* FSI enable */
+ struct gpio_desc *gpio_mux; /* Mux control */
+};
+
+#define to_fsi_master_gpio(m) container_of(m, struct fsi_master_gpio, master)
+
+struct fsi_gpio_msg {
+ uint64_t msg;
+ uint8_t bits;
+};
+
+static void clock_toggle(struct fsi_master_gpio *master, int count)
+{
+ int i;
+
+ for (i = 0; i < count; i++) {
+ ndelay(FSI_GPIO_STD_DLY);
+ gpiod_set_value(master->gpio_clk, 0);
+ ndelay(FSI_GPIO_STD_DLY);
+ gpiod_set_value(master->gpio_clk, 1);
+ }
+}
+
+static int sda_in(struct fsi_master_gpio *master)
+{
+ int in;
+
+ ndelay(FSI_GPIO_STD_DLY);
+ in = gpiod_get_value(master->gpio_data);
+ return in ? 1 : 0;
+}
+
+static void sda_out(struct fsi_master_gpio *master, int value)
+{
+ gpiod_set_value(master->gpio_data, value);
+}
+
+static void set_sda_input(struct fsi_master_gpio *master)
+{
+ gpiod_direction_input(master->gpio_data);
+ if (master->gpio_trans)
+ gpiod_set_value(master->gpio_trans, 0);
+}
+
+static void set_sda_output(struct fsi_master_gpio *master, int value)
+{
+ if (master->gpio_trans)
+ gpiod_set_value(master->gpio_trans, 1);
+ gpiod_direction_output(master->gpio_data, value);
+}
+
+static void serial_in(struct fsi_master_gpio *master, struct fsi_gpio_msg *cmd,
+ uint8_t num_bits)
+{
+ uint8_t bit;
+ uint64_t msg = 0;
+ uint8_t in_bit = 0;
+
+ set_sda_input(master);
+
+ for (bit = 0; bit < num_bits; bit++) {
+ clock_toggle(master, 1);
+ in_bit = sda_in(master);
+ msg <<= 1;
+ msg |= ~in_bit & 0x1; /* Data is negative active */
+ }
+ cmd->bits = num_bits;
+ cmd->msg = msg;
+}
+
+static void serial_out(struct fsi_master_gpio *master,
+ const struct fsi_gpio_msg *cmd)
+{
+ uint8_t bit;
+ uint64_t msg = ~cmd->msg; /* Data is negative active */
+ uint64_t sda_mask = 0x1ULL << (cmd->bits - 1);
+ uint64_t last_bit = ~0;
+ int next_bit;
+
+ if (!cmd->bits) {
+ dev_warn(master->master.dev, "trying to output 0 bits\n");
+ return;
+ }
+ set_sda_output(master, 0);
+
+ /* Send the start bit */
+ sda_out(master, 0);
+ clock_toggle(master, 1);
+
+ /* Send the message */
+ for (bit = 0; bit < cmd->bits; bit++) {
+ next_bit = (msg & sda_mask) >> (cmd->bits - 1);
+ if (last_bit ^ next_bit) {
+ sda_out(master, next_bit);
+ last_bit = next_bit;
+ }
+ clock_toggle(master, 1);
+ msg <<= 1;
+ }
+}
+
+/*
+ * Clock out some 0's after every message to ride out line reflections
+ */
+static void echo_delay(struct fsi_master_gpio *master)
+{
+ set_sda_output(master, 1);
+ clock_toggle(master, FSI_ECHO_DELAY_CLOCKS);
+}
+
+/*
+ * Used in bus error cases only. Clears out any remaining data the slave
+ * is attempting to send
+ */
+static void drain_response(struct fsi_master_gpio *master)
+{
+ struct fsi_gpio_msg msg;
+
+ serial_in(master, &msg, FSI_GPIO_DRAIN_BITS);
+}
+
+/*
+ * Store information on master errors so handler can detect and clean
+ * up the bus
+ */
+static void fsi_master_gpio_error(struct fsi_master_gpio *master, int error)
+{
+
+}
+
+static int poll_for_response(struct fsi_master_gpio *master, uint8_t expected,
+ uint8_t size, void *data)
+{
+ int busy_count = 0, i;
+ struct fsi_gpio_msg response, cmd;
+ int bits_remaining = 0, bit_count, response_id, id;
+ uint64_t resp = 0;
+ uint8_t bits_received = FSI_GPIO_MSG_ID_SIZE +
+ FSI_GPIO_MSG_RESPID_SIZE;
+ uint8_t crc_in;
+
+ do {
+ for (i = 0; i < FSI_GPIO_MTOE_COUNT; i++) {
+ serial_in(master, &response, 1);
+ if (response.msg)
+ break;
+ }
+ if (i >= FSI_GPIO_MTOE_COUNT) {
+ dev_dbg(master->master.dev,
+ "Master time out waiting for response\n");
+ drain_response(master);
+ fsi_master_gpio_error(master, FSI_GPIO_MTOE);
+ return -EIO;
+ }
+
+ /* Response received */
+ bit_count = FSI_GPIO_MSG_ID_SIZE + FSI_GPIO_MSG_RESPID_SIZE;
+ serial_in(master, &response, bit_count);
+
+ response_id = response.msg & 0x3;
+ id = (response.msg >> FSI_GPIO_MSG_RESPID_SIZE) & 0x3;
+ dev_dbg(master->master.dev, "id:%d resp:%d\n", id, response_id);
+
+ resp = response.msg;
+
+ switch (response_id) {
+ case FSI_GPIO_RESP_ACK:
+ if (expected == FSI_GPIO_RESP_ACKD)
+ bits_remaining = 8 * size;
+ break;
+
+ case FSI_GPIO_RESP_BUSY:
+ /*
+ * Its necessary to clock slave before issuing
+ * d-poll, not indicated in the hardware protocol
+ * spec. < 20 clocks causes slave to hang, 21 ok.
+ */
+ set_sda_output(master, 1);
+ clock_toggle(master, FSI_GPIO_DPOLL_CLOCKS);
+ cmd.msg = FSI_GPIO_CMD_DPOLL;
+ cmd.bits = FSI_GPIO_CMD_DPOLL_SIZE;
+ serial_out(master, &cmd);
+ echo_delay(master);
+ continue;
+
+ case FSI_GPIO_RESP_ERRA:
+ case FSI_GPIO_RESP_ERRC:
+ dev_dbg(master->master.dev, "ERR received: %d\n",
+ (int)response.msg);
+ /*
+ * todo: Verify crc from slave and in general
+ * only act on any response if crc is correct
+ */
+ clock_toggle(master, FSI_GPIO_CRC_SIZE);
+ fsi_master_gpio_error(master, response.msg);
+ return -EIO;
+ }
+
+ /* Read in the data field if applicable */
+ if (bits_remaining) {
+ serial_in(master, &response, bits_remaining);
+ resp <<= bits_remaining;
+ resp |= response.msg;
+ bits_received += bits_remaining;
+ *((uint32_t *)data) = response.msg;
+ }
+
+ crc_in = crc_fsi(0, resp | (0x1ULL << bits_received),
+ bits_received + 1);
+
+ /* Read in the crc and check it */
+ serial_in(master, &response, FSI_GPIO_CRC_SIZE);
+ if (crc_in != response.msg) {
+ dev_dbg(master->master.dev, "ERR response CRC\n");
+ fsi_master_gpio_error(master, FSI_GPIO_CRC_INVAL);
+ return -EIO;
+ }
+ /* Clock the slave enough to be ready for next operation */
+ clock_toggle(master, FSI_GPIO_PRIME_SLAVE_CLOCKS);
+ return 0;
+
+ } while (busy_count++ < FSI_GPIO_MAX_BUSY);
+
+ dev_dbg(master->master.dev, "ERR slave is stuck in busy state\n");
+ fsi_master_gpio_error(master, FSI_GPIO_ERR_BUSY);
+
+ return -EIO;
+}
+
+static void build_abs_ar_command(struct fsi_gpio_msg *cmd, uint64_t mode,
+ uint8_t slave, uint32_t addr, size_t size,
+ const void *data)
+{
+ uint8_t crc;
+
+ cmd->bits = FSI_GPIO_CMD_DFLT_LEN;
+ cmd->msg = FSI_GPIO_CMD_DEFAULT;
+ cmd->msg |= mode;
+ cmd->msg &= ~FSI_GPIO_CMD_SLAVE_MASK;
+ cmd->msg |= (((uint64_t)slave) << FSI_GPIO_CMD_SLV_SHIFT);
+ addr &= FSI_GPIO_CMD_ADDR_MASK;
+ cmd->msg |= (((uint64_t)addr) << FSI_GPIO_CMD_ADDR_SHIFT);
+ if (size == sizeof(uint8_t)) {
+ if (data) {
+ uint8_t cmd_data = *((uint8_t *)data);
+
+ cmd->msg |=
+ ((uint64_t)cmd_data) << FSI_GPIO_CMD_DT8_SHIFT;
+ }
+ } else if (size == sizeof(uint16_t)) {
+ cmd->msg |= FSI_GPIO_CMD_SIZE_16;
+ if (data) {
+ uint16_t cmd_data;
+
+ memcpy(&cmd_data, data, size);
+ cmd->msg |=
+ ((uint64_t)cmd_data) << FSI_GPIO_CMD_DT16_SHIFT;
+ }
+ } else {
+ cmd->msg |= FSI_GPIO_CMD_SIZE_32;
+ if (data) {
+ uint32_t cmd_data;
+
+ memcpy(&cmd_data, data, size);
+ cmd->msg |=
+ ((uint64_t)cmd_data) << FSI_GPIO_CMD_DT32_SHIFT;
+ }
+ }
+
+ if (mode == FSI_GPIO_CMD_WRITE)
+ cmd->bits += (8 * size);
+
+ /* Include start bit */
+ crc = crc_fsi(0,
+ (cmd->msg >> (64 - cmd->bits)) | (0x1ULL << cmd->bits),
+ cmd->bits + 1);
+ cmd->msg |= ((uint64_t)crc) << (FSI_GPIO_CMD_CRC_SHIFT - cmd->bits);
+ cmd->bits += FSI_GPIO_CRC_SIZE;
+
+ /* Right align message */
+ cmd->msg >>= (64 - cmd->bits);
+}
+
+static int fsi_master_gpio_read(struct fsi_master *_master, int link,
+ uint8_t slave, uint32_t addr, void *val, size_t size)
+{
+ struct fsi_master_gpio *master = to_fsi_master_gpio(_master);
+ struct fsi_gpio_msg cmd;
+ int rc;
+ unsigned long flags;
+
+ if (link != 0)
+ return -ENODEV;
+
+ build_abs_ar_command(&cmd, FSI_GPIO_CMD_READ, slave, addr, size, NULL);
+
+ spin_lock_irqsave(&fsi_gpio_cmd_lock, flags);
+ serial_out(master, &cmd);
+ echo_delay(master);
+ rc = poll_for_response(master, FSI_GPIO_RESP_ACKD, size, val);
+ spin_unlock_irqrestore(&fsi_gpio_cmd_lock, flags);
+
+ return rc;
+}
+
+static int fsi_master_gpio_write(struct fsi_master *_master, int link,
+ uint8_t slave, uint32_t addr, const void *val, size_t size)
+{
+ struct fsi_master_gpio *master = to_fsi_master_gpio(_master);
+ struct fsi_gpio_msg cmd;
+ int rc;
+ unsigned long flags;
+
+ if (link != 0)
+ return -ENODEV;
+
+ build_abs_ar_command(&cmd, FSI_GPIO_CMD_WRITE, slave, addr, size, val);
+
+ spin_lock_irqsave(&fsi_gpio_cmd_lock, flags);
+ serial_out(master, &cmd);
+ echo_delay(master);
+ rc = poll_for_response(master, FSI_GPIO_RESP_ACK, size, NULL);
+ spin_unlock_irqrestore(&fsi_gpio_cmd_lock, flags);
+
+ return rc;
+}
+
+/*
+ * Issue a break command on link
+ */
+static int fsi_master_gpio_break(struct fsi_master *_master, int link)
+{
+ struct fsi_master_gpio *master = to_fsi_master_gpio(_master);
+
+ if (link != 0)
+ return -ENODEV;
+
+ set_sda_output(master, 1);
+ clock_toggle(master, FSI_PRE_BREAK_CLOCKS);
+ sda_out(master, 0);
+ clock_toggle(master, FSI_BREAK_CLOCKS);
+ echo_delay(master);
+ sda_out(master, 1);
+ clock_toggle(master, FSI_POST_BREAK_CLOCKS);
+
+ /* Wait for logic reset to take effect */
+ udelay(200);
+
+ return 0;
+}
+
+static int fsi_master_gpio_link_enable(struct fsi_master *_master, int link)
+{
+ struct fsi_master_gpio *master = to_fsi_master_gpio(_master);
+
+ if (link != 0)
+ return -ENODEV;
+ if (master->gpio_enable)
+ gpiod_set_value(master->gpio_enable, 1);
+
+ return 0;
+}
+
+static int fsi_master_gpio_probe(struct platform_device *pdev)
+{
+ struct fsi_master_gpio *master;
+
+ master = devm_kzalloc(&pdev->dev, sizeof(*master), GFP_KERNEL);
+ if (!master)
+ return -ENOMEM;
+
+ master->master.dev = &pdev->dev;
+
+ master->gpio_clk = devm_gpiod_get(&pdev->dev, "clock", GPIOD_OUT_HIGH);
+ if (IS_ERR(master->gpio_clk)) {
+ dev_dbg(&pdev->dev, "probe: failed to get clock pin\n");
+ return PTR_ERR(master->gpio_clk);
+ }
+
+ master->gpio_data = devm_gpiod_get(&pdev->dev, "data", GPIOD_OUT_HIGH);
+ if (IS_ERR(master->gpio_data)) {
+ dev_dbg(&pdev->dev, "probe: failed to get data pin\n");
+ return PTR_ERR(master->gpio_data);
+ }
+
+ /* Optional pins */
+
+ master->gpio_trans = devm_gpiod_get_optional(&pdev->dev, "trans",
+ GPIOD_OUT_HIGH);
+ if (IS_ERR(master->gpio_trans))
+ dev_dbg(&pdev->dev, "probe: failed to get trans pin\n");
+
+ master->gpio_enable = devm_gpiod_get_optional(&pdev->dev, "enable",
+ GPIOD_OUT_HIGH);
+ if (IS_ERR(master->gpio_enable))
+ dev_dbg(&pdev->dev, "probe: failed to get enable pin\n");
+
+ master->gpio_mux = devm_gpiod_get_optional(&pdev->dev, "mux",
+ GPIOD_OUT_HIGH);
+ if (IS_ERR(master->gpio_mux))
+ dev_dbg(&pdev->dev, "probe: failed to get mux pin\n");
+
+ /* todo: evaluate if clocks can be reduced */
+ clock_toggle(master, FSI_INIT_CLOCKS);
+
+ master->master.n_links = 1;
+ master->master.read = fsi_master_gpio_read;
+ master->master.write = fsi_master_gpio_write;
+ master->master.send_break = fsi_master_gpio_break;
+ master->master.link_enable = fsi_master_gpio_link_enable;
+ return fsi_master_register(&master->master);
+}
+
+static int fsi_master_gpio_remove(struct platform_device *pdev)
+{
+ struct fsi_master_gpio *master = platform_get_drvdata(pdev);
+
+ devm_gpiod_put(&pdev->dev, master->gpio_clk);
+ devm_gpiod_put(&pdev->dev, master->gpio_data);
+ if (master->gpio_trans)
+ devm_gpiod_put(&pdev->dev, master->gpio_trans);
+ if (master->gpio_enable)
+ devm_gpiod_put(&pdev->dev, master->gpio_enable);
+ if (master->gpio_mux)
+ devm_gpiod_put(&pdev->dev, master->gpio_mux);
+ fsi_master_unregister(&master->master);
+
+ return 0;
+}
+
+static const struct of_device_id fsi_master_gpio_match[] = {
+ { .compatible = "ibm,fsi-master-gpio" },
+ { },
+};
+
+static struct platform_driver fsi_master_gpio_driver = {
+ .driver = {
+ .name = "fsi-master-gpio",
+ .of_match_table = fsi_master_gpio_match,
+ },
+ .probe = fsi_master_gpio_probe,
+ .remove = fsi_master_gpio_remove,
+};
+
+module_platform_driver(fsi_master_gpio_driver);
+MODULE_LICENSE("GPL");
--
1.8.2.2
^ permalink raw reply related
* [PATCH v2 18/18] insert build break
From: christopher.lee.bostic at gmail.com @ 2017-01-12 22:37 UTC (permalink / raw)
To: linux-arm-kernel
From: Chris Bostic <cbostic@us.ibm.com>
Signed-off-by: Chris Bostic <cbostic@us.ibm.com>
---
drivers/fsi/fsi-core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/fsi/fsi-core.c b/drivers/fsi/fsi-core.c
index 28b82d1..db09836 100644
--- a/drivers/fsi/fsi-core.c
+++ b/drivers/fsi/fsi-core.c
@@ -42,6 +42,7 @@
static DEFINE_IDA(master_ida);
+
struct fsi_slave {
struct device dev;
struct fsi_master *master;
--
1.8.2.2
^ permalink raw reply related
* [PATCH] clk: stm32f4: avoid uninitialized variable access
From: Arnd Bergmann @ 2017-01-12 22:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170112220627.GQ17126@codeaurora.org>
On Thu, Jan 12, 2017 at 11:06 PM, Stephen Boyd <sboyd@codeaurora.org> wrote:
>
> Applied to clk-next. Seems I need to update my compiler to find
> these warnings.
I'm currently playing with gcc-7, which adds a lot of new warnings
(including many false positives). gcc-6 was supposed to have better
warnings than 5, but I didn't find the difference that noticeable. 5
or 6 is probably best at the moment, and if you have at least 4.9
there is no urgent need to upgrade.
Arnd
^ permalink raw reply
* [PATCH v6 23/25] usb: chipidea: Pullup D+ in device mode via phy APIs
From: Stephen Boyd @ 2017-01-12 22:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170112095040.GA15726@b29397-desktop>
Quoting Peter Chen (2017-01-12 01:50:40)
> On Wed, Jan 11, 2017 at 04:19:53PM -0800, Stephen Boyd wrote:
> > Quoting Peter Chen (2017-01-02 22:53:19)
> > > On Wed, Dec 28, 2016 at 02:57:09PM -0800, Stephen Boyd wrote:
> > > > If the phy supports it, call phy_set_mode() to pull up D+ when
> > > > required by setting the mode to PHY_MODE_USB_DEVICE. If we want
> > > > to remove the pullup, set the mode to PHY_MODE_USB_HOST.
> > > >
> > [..]
> > > > diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
> > > > index 0d532a724d48..6d61fa0689b0 100644
> > > > --- a/drivers/usb/chipidea/udc.c
> > > > +++ b/drivers/usb/chipidea/udc.c
> > > > @@ -1609,10 +1610,15 @@ static int ci_udc_pullup(struct usb_gadget *_gadget, int is_on)
> > > > return 0;
> > > >
> > > > pm_runtime_get_sync(&ci->gadget.dev);
> > > > - if (is_on)
> > > > + if (is_on) {
> > > > + if (ci->phy)
> > > > + phy_set_mode(ci->phy, PHY_MODE_USB_DEVICE);
> > > > hw_write(ci, OP_USBCMD, USBCMD_RS, USBCMD_RS);
> > > > - else
> > > > + } else {
> > > > hw_write(ci, OP_USBCMD, USBCMD_RS, 0);
> > > > + if (ci->phy)
> > > > + phy_set_mode(ci->phy, PHY_MODE_USB_HOST);
> > > > + }
> > > > pm_runtime_put_sync(&ci->gadget.dev);
> > > >
> > > > return 0;
> > >
> > > Would you describe the use case for it? Why not adding it at
> > > role switch routine?
> > >
> >
> > This is about pulling up D+. The phy I have requires that we manually
> > pull up D+ by writing a ULPI register before we set the run/stop bit.
>
> Afaik, only controller can pull up dp when it is at device mode by
> setting USBCMD_RS. At host mode, clear USBCMD_RS will only stopping
> sending SoF from controller side.
>
> I am puzzled why you can pull up D+ by writing an ULPI register, perhaps,
> your phy needs DP to change before switching the mode? Would you
> double confirm that?
With the boards I have, vbus is not routed to the phy. Instead, there's
a vbus comparator on the PMIC where the vbus line from the usb
receptacle is sent. The vbus extcon driver probes the comparator on the
PMIC to see if vbus is present or not and then notifies extcon users
when vbus changes.
The ULPI register we write in the phy is a vendor specific register
(called MISC_A) that has two bits. If you look at
qcom_usb_hs_phy_set_mode() in this series you'll see that we set
VBUSVLDEXTSEL and VBUSVLDEXT. VBUSVLDEXTSEL controls a mux in the phy
that chooses between an internal comparator, in the case where vbus goes
to the phy, or an external signal input to the phy, VBUSVLDEXT, to
consider as the "session valid" signal. It looks like the session valid
signal drives the D+ pullup resistor in the phy. These bits in MISC_A
don't matter when the phy is in host mode.
So when the board doesn't route vbus to the phy, we have to toggle the
VBUSVLDEXT bit to signal to the phy that the vbus is there or not. I
also see that we're not supposed to toggle the VBUSVLDEXTSEL bit when in
"normal" operating mode. So perhaps we should do everything in the
qcom_usb_hs_phy_set_mode() routine during the role switch as you
suggest, except toggle the VBUSVLDEXT bit. Toggling the VBUSVLDEXT bit
can be done via some new phy op when the extcon triggers?
^ permalink raw reply
* [PATCH net-next v2 05/10] drivers: base: Add device_find_class()
From: Florian Fainelli @ 2017-01-12 22:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170112.162135.441956368122992032.davem@davemloft.net>
On 01/12/2017 01:21 PM, David Miller wrote:
> From: Florian Fainelli <f.fainelli@gmail.com>
> Date: Wed, 11 Jan 2017 19:41:16 -0800
>
>> Add a helper function to lookup a device reference given a class name.
>> This is a preliminary patch to remove adhoc code from net/dsa/dsa.c and
>> make it more generic.
>>
>> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
>> ---
>> drivers/base/core.c | 19 +++++++++++++++++++
>> include/linux/device.h | 1 +
>> 2 files changed, 20 insertions(+)
>>
>> diff --git a/drivers/base/core.c b/drivers/base/core.c
>> index 020ea7f05520..3dd6047c10d8 100644
>> --- a/drivers/base/core.c
>> +++ b/drivers/base/core.c
>> @@ -2065,6 +2065,25 @@ struct device *device_find_child(struct device *parent, void *data,
>> }
>> EXPORT_SYMBOL_GPL(device_find_child);
>>
>> +static int dev_is_class(struct device *dev, void *class)
>
> I know you are just moving code, but this class argumnet is a string
> and thus should be "char *" or even "const char *".
Well, this is really so that we don't need to cast the arguments passed
to device_find_child(), which takes a void *data as well. If we made
that a const char *class, we'd get warnings that look like these:
drivers/base/core.c: In function 'device_find_class':
drivers/base/core.c:2083:2: warning: passing argument 2 of
'device_find_child' discards 'const' qualifier from pointer target type
[enabled by default]
return device_find_child(parent, class, dev_is_class);
^
drivers/base/core.c:2050:16: note: expected 'void *' but argument is of
type 'const char *'
struct device *device_find_child(struct device *parent, void *data,
^
drivers/base/core.c:2083:2: warning: passing argument 3 of
'device_find_child' from incompatible pointer type [enabled by default]
return device_find_child(parent, class, dev_is_class);
^
drivers/base/core.c:2050:16: note: expected 'int (*)(struct device *,
void *)' but argument is of type 'int (*)(struct device *, const char *)'
struct device *device_find_child(struct device *parent, void *data,
^
--
Florian
^ permalink raw reply
* [PATCH] clk: stm32f4: avoid uninitialized variable access
From: Stephen Boyd @ 2017-01-12 22:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK8P3a3ieV29jgh0jhioN3KjZCfP2drPAQme_+1oMuTTSiA4NQ@mail.gmail.com>
On 01/12/2017 02:42 PM, Arnd Bergmann wrote:
> On Thu, Jan 12, 2017 at 11:06 PM, Stephen Boyd <sboyd@codeaurora.org> wrote:
>> Applied to clk-next. Seems I need to update my compiler to find
>> these warnings.
> I'm currently playing with gcc-7, which adds a lot of new warnings
> (including many false positives). gcc-6 was supposed to have better
> warnings than 5, but I didn't find the difference that noticeable. 5
> or 6 is probably best at the moment, and if you have at least 4.9
> there is no urgent need to upgrade.
Thanks. I'm on gcc-4.7. It's been a long time since I upgraded my cross
compiler.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH] ARM: dts: vf610-zii-dev: add EEPROM entry to Rev C
From: Vivien Didelot @ 2017-01-12 23:06 UTC (permalink / raw)
To: linux-arm-kernel
The ZII Dev Rev C board has EEPROMs hanging the 88E6390 Ethernet switch
chips. Add an "eeprom-length" property to allow access from ethtool.
Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
---
arch/arm/boot/dts/vf610-zii-dev-rev-c.dts | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/vf610-zii-dev-rev-c.dts b/arch/arm/boot/dts/vf610-zii-dev-rev-c.dts
index fbedb7bb3628..6a45bd24ffe6 100644
--- a/arch/arm/boot/dts/vf610-zii-dev-rev-c.dts
+++ b/arch/arm/boot/dts/vf610-zii-dev-rev-c.dts
@@ -71,6 +71,7 @@
#size-cells = <0>;
reg = <0>;
dsa,member = <0 0>;
+ eeprom-length = <512>;
ports {
#address-cells = <1>;
@@ -128,6 +129,7 @@
#size-cells = <0>;
reg = <0>;
dsa,member = <0 1>;
+ eeprom-length = <512>;
ports {
#address-cells = <1>;
--
2.11.0
^ permalink raw reply related
* [PATCH v3 10/24] ARM: dts: imx6-sabreauto: add pinctrl for gpt input capture
From: Steve Longerbeam @ 2017-01-12 23:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJ+vNU1ci=fbeemJcBGCAk40PETdcov7Fm112F5FePL9SR4cFQ@mail.gmail.com>
On 01/12/2017 11:37 AM, Tim Harvey wrote:
> On Fri, Jan 6, 2017 at 6:11 PM, Steve Longerbeam <slongerbeam@gmail.com> wrote:
>> Add pinctrl groups for both GPT input capture channels.
>>
>> Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com>
>> ---
>> arch/arm/boot/dts/imx6qdl-sabreauto.dtsi | 12 ++++++++++++
>> 1 file changed, 12 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
>> index 967c3b8..495709f 100644
>> --- a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
>> +++ b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
>> @@ -457,6 +457,18 @@
>> >;
>> };
>>
>> + pinctrl_gpt_input_capture0: gptinputcapture0grp {
>> + fsl,pins = <
>> + MX6QDL_PAD_SD1_DAT0__GPT_CAPTURE1 0x1b0b0
>> + >;
>> + };
>> +
>> + pinctrl_gpt_input_capture1: gptinputcapture1grp {
>> + fsl,pins = <
>> + MX6QDL_PAD_SD1_DAT1__GPT_CAPTURE2 0x1b0b0
>> + >;
>> + };
>> +
>> pinctrl_spdif: spdifgrp {
>> fsl,pins = <
>> MX6QDL_PAD_KEY_COL3__SPDIF_IN 0x1b0b0
>> --
> Steve,
>
> These are not used anywhere.
Yes, maybe I should just remove this patch for now. I'm only keeping it
because eventually it will be needed to support i.MX6 input capture.
Steve
^ permalink raw reply
* [PATCH] PCI: iproc: fix resource allocation for BCMA PCIe
From: Abylay Ospan @ 2017-01-12 23:58 UTC (permalink / raw)
To: linux-arm-kernel
Resource allocated on stack was saved by 'devm_request_resource' to
global 'iomem_resource' but become invalid after 'iproc_pcie_bcma_probe' exit.
So the global 'iomem_resource' was poisoned. This may cause kernel crash
or second PCIe bridge registration failure.
Tested on Broadcom NorthStar machine ('Edgecore ECW7220-L') with two PCIe wifi
adapters (b43 BCM4331 and ath10k QCA988X).
Signed-off-by: Abylay Ospan <aospan@netup.ru>
---
drivers/pci/host/pcie-iproc-bcma.c | 18 ++++++++----------
drivers/pci/host/pcie-iproc.h | 2 ++
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/pci/host/pcie-iproc-bcma.c b/drivers/pci/host/pcie-iproc-bcma.c
index bd4c9ec..28f9b89 100644
--- a/drivers/pci/host/pcie-iproc-bcma.c
+++ b/drivers/pci/host/pcie-iproc-bcma.c
@@ -44,8 +44,6 @@ static int iproc_pcie_bcma_probe(struct bcma_device *bdev)
{
struct device *dev = &bdev->dev;
struct iproc_pcie *pcie;
- LIST_HEAD(res);
- struct resource res_mem;
int ret;
pcie = devm_kzalloc(dev, sizeof(*pcie), GFP_KERNEL);
@@ -62,21 +60,21 @@ static int iproc_pcie_bcma_probe(struct bcma_device *bdev)
}
pcie->base_addr = bdev->addr;
+ INIT_LIST_HEAD(&pcie->resources);
- res_mem.start = bdev->addr_s[0];
- res_mem.end = bdev->addr_s[0] + SZ_128M - 1;
- res_mem.name = "PCIe MEM space";
- res_mem.flags = IORESOURCE_MEM;
- pci_add_resource(&res, &res_mem);
+ pcie->res_mem.start = bdev->addr_s[0];
+ pcie->res_mem.end = bdev->addr_s[0] + SZ_128M - 1;
+ pcie->res_mem.name = "PCIe MEM space";
+ pcie->res_mem.flags = IORESOURCE_MEM;
+ pcie->res_mem.child = NULL;
+ pci_add_resource(&pcie->resources, &pcie->res_mem);
pcie->map_irq = iproc_pcie_bcma_map_irq;
- ret = iproc_pcie_setup(pcie, &res);
+ ret = iproc_pcie_setup(pcie, &pcie->resources);
if (ret)
dev_err(dev, "PCIe controller setup failed\n");
- pci_free_resource_list(&res);
-
bcma_set_drvdata(bdev, pcie);
return ret;
}
diff --git a/drivers/pci/host/pcie-iproc.h b/drivers/pci/host/pcie-iproc.h
index 04fed8e..866d649 100644
--- a/drivers/pci/host/pcie-iproc.h
+++ b/drivers/pci/host/pcie-iproc.h
@@ -105,6 +105,8 @@ struct iproc_pcie {
bool need_msi_steer;
struct iproc_msi *msi;
+ struct resource res_mem;
+ struct list_head resources;
};
int iproc_pcie_setup(struct iproc_pcie *pcie, struct list_head *res);
--
2.7.4
^ permalink raw reply related
* [PATCH] ARM: dts: NSP: Fix DT ranges error
From: Florian Fainelli @ 2017-01-13 0:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484236210-16067-1-git-send-email-jon.mason@broadcom.com>
On 01/12/2017 07:50 AM, Jon Mason wrote:
> The range size for axi is 0x2 bytes too small, as the QSPI needs
> 0x11c408 + 0x004 (which is 0x0011c40c, not 0x0011c40a). No errors have
> been observed with this shortcoming, but fixing it for correctness.
>
> Signed-off-by: Jon Mason <jon.mason@broadcom.com>
Applied to devicetree/fixes thanks Jon.
--
Florian
^ permalink raw reply
* [PATCH] PCI: iproc: fix kernel crash if dev->of_node not defined
From: Abylay Ospan @ 2017-01-13 0:20 UTC (permalink / raw)
To: linux-arm-kernel
pcie->dev->of_node not always defined (NULL) and can cause crash:
[ 19.053195] Unable to handle kernel NULL pointer dereference at
virtual address 00000020
[<c0b0370c>] (of_n_addr_cells) from [<c06599c4>]
(iproc_pcie_setup+0x30c/0xce0)
this patch adds sanity check to prevent crash.
Signed-off-by: Abylay Ospan <aospan@netup.ru>
---
drivers/pci/host/pcie-iproc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/pci/host/pcie-iproc.c b/drivers/pci/host/pcie-iproc.c
index 3ebc025..f2836a9 100644
--- a/drivers/pci/host/pcie-iproc.c
+++ b/drivers/pci/host/pcie-iproc.c
@@ -952,6 +952,9 @@ static int pci_dma_range_parser_init(struct of_pci_range_parser *parser,
const int na = 3, ns = 2;
int rlen;
+ if (!node)
+ return -ENOENT;
+
parser->node = node;
parser->pna = of_n_addr_cells(node);
parser->np = parser->pna + na + ns;
--
2.7.4
^ permalink raw reply related
* [PATCH] PCI: iproc: fix kernel crash if dev->of_node not defined
From: Florian Fainelli @ 2017-01-13 0:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484266817-6725-1-git-send-email-aospan@netup.ru>
On 01/12/2017 04:20 PM, Abylay Ospan wrote:
> pcie->dev->of_node not always defined (NULL) and can cause crash:
>
> [ 19.053195] Unable to handle kernel NULL pointer dereference at
> virtual address 00000020
> [<c0b0370c>] (of_n_addr_cells) from [<c06599c4>]
> (iproc_pcie_setup+0x30c/0xce0)
>
> this patch adds sanity check to prevent crash.
Humm, how can it not be defined based on your earlier comment that you
are using this on NSP which is Device Tree exclusively? I would agree if
this was seen on e.g: MIPS/BCMA (47xx).
>
> Signed-off-by: Abylay Ospan <aospan@netup.ru>
> ---
> drivers/pci/host/pcie-iproc.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/pci/host/pcie-iproc.c b/drivers/pci/host/pcie-iproc.c
> index 3ebc025..f2836a9 100644
> --- a/drivers/pci/host/pcie-iproc.c
> +++ b/drivers/pci/host/pcie-iproc.c
> @@ -952,6 +952,9 @@ static int pci_dma_range_parser_init(struct of_pci_range_parser *parser,
> const int na = 3, ns = 2;
> int rlen;
>
> + if (!node)
> + return -ENOENT;
> +
> parser->node = node;
> parser->pna = of_n_addr_cells(node);
> parser->np = parser->pna + na + ns;
>
--
Florian
^ permalink raw reply
* [PATCHv5 3/8] rtc: add STM32 RTC driver
From: Alexandre Belloni @ 2017-01-13 0:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484142403-11556-1-git-send-email-amelie.delaunay@st.com>
On 11/01/2017 at 14:46:43 +0100, Amelie Delaunay wrote :
> This patch adds support for the STM32 RTC.
>
> Signed-off-by: Amelie Delaunay <amelie.delaunay@st.com>
> ---
> drivers/rtc/Kconfig | 11 +
> drivers/rtc/Makefile | 1 +
> drivers/rtc/rtc-stm32.c | 727 ++++++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 739 insertions(+)
> create mode 100644 drivers/rtc/rtc-stm32.c
>
This didn't apply cleanly, please check rtc-next. I don't think I made
any mistake as the issue was only in Kconfig. You probably based your
patches on 4.9 instead of 4.10-rc1.
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCHv3 2/8] dt-bindings: document the STM32 RTC bindings
From: Alexandre Belloni @ 2017-01-13 0:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483623809-29937-3-git-send-email-amelie.delaunay@st.com>
On 05/01/2017 at 14:43:23 +0100, Amelie Delaunay wrote :
> This patch adds documentation of device tree bindings for the STM32 RTC.
>
> Signed-off-by: Amelie Delaunay <amelie.delaunay@st.com>
> Acked-by: Rob Herring <robh@kernel.org>
> ---
> .../devicetree/bindings/rtc/st,stm32-rtc.txt | 27 ++++++++++++++++++++++
> 1 file changed, 27 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/rtc/st,stm32-rtc.txt
>
Applied, thanks.
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH] PCI: iproc: fix resource allocation for BCMA PCIe
From: Ray Jui @ 2017-01-13 0:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484265521-13497-1-git-send-email-aospan@netup.ru>
Hi Abylay,
On 1/12/2017 3:58 PM, Abylay Ospan wrote:
> Resource allocated on stack was saved by 'devm_request_resource' to
> global 'iomem_resource' but become invalid after 'iproc_pcie_bcma_probe' exit.
> So the global 'iomem_resource' was poisoned. This may cause kernel crash
> or second PCIe bridge registration failure.
>
> Tested on Broadcom NorthStar machine ('Edgecore ECW7220-L') with two PCIe wifi
> adapters (b43 BCM4331 and ath10k QCA988X).
>
> Signed-off-by: Abylay Ospan <aospan@netup.ru>
I have not yet looked into this in great details. But if what you
claimed is true, do we have the same problem with multiple PCIe host
drivers that all have their resource allocated on the stack and have
'devm_request_resource' called to save it?
Thanks,
Ray
> ---
> drivers/pci/host/pcie-iproc-bcma.c | 18 ++++++++----------
> drivers/pci/host/pcie-iproc.h | 2 ++
> 2 files changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/pci/host/pcie-iproc-bcma.c b/drivers/pci/host/pcie-iproc-bcma.c
> index bd4c9ec..28f9b89 100644
> --- a/drivers/pci/host/pcie-iproc-bcma.c
> +++ b/drivers/pci/host/pcie-iproc-bcma.c
> @@ -44,8 +44,6 @@ static int iproc_pcie_bcma_probe(struct bcma_device *bdev)
> {
> struct device *dev = &bdev->dev;
> struct iproc_pcie *pcie;
> - LIST_HEAD(res);
> - struct resource res_mem;
> int ret;
>
> pcie = devm_kzalloc(dev, sizeof(*pcie), GFP_KERNEL);
> @@ -62,21 +60,21 @@ static int iproc_pcie_bcma_probe(struct bcma_device *bdev)
> }
>
> pcie->base_addr = bdev->addr;
> + INIT_LIST_HEAD(&pcie->resources);
>
> - res_mem.start = bdev->addr_s[0];
> - res_mem.end = bdev->addr_s[0] + SZ_128M - 1;
> - res_mem.name = "PCIe MEM space";
> - res_mem.flags = IORESOURCE_MEM;
> - pci_add_resource(&res, &res_mem);
> + pcie->res_mem.start = bdev->addr_s[0];
> + pcie->res_mem.end = bdev->addr_s[0] + SZ_128M - 1;
> + pcie->res_mem.name = "PCIe MEM space";
> + pcie->res_mem.flags = IORESOURCE_MEM;
> + pcie->res_mem.child = NULL;
> + pci_add_resource(&pcie->resources, &pcie->res_mem);
>
> pcie->map_irq = iproc_pcie_bcma_map_irq;
>
> - ret = iproc_pcie_setup(pcie, &res);
> + ret = iproc_pcie_setup(pcie, &pcie->resources);
> if (ret)
> dev_err(dev, "PCIe controller setup failed\n");
>
> - pci_free_resource_list(&res);
> -
> bcma_set_drvdata(bdev, pcie);
> return ret;
> }
> diff --git a/drivers/pci/host/pcie-iproc.h b/drivers/pci/host/pcie-iproc.h
> index 04fed8e..866d649 100644
> --- a/drivers/pci/host/pcie-iproc.h
> +++ b/drivers/pci/host/pcie-iproc.h
> @@ -105,6 +105,8 @@ struct iproc_pcie {
>
> bool need_msi_steer;
> struct iproc_msi *msi;
> + struct resource res_mem;
> + struct list_head resources;
> };
>
> int iproc_pcie_setup(struct iproc_pcie *pcie, struct list_head *res);
>
^ permalink raw reply
* [PATCH] PCI: iproc: fix kernel crash if dev->of_node not defined
From: Ray Jui @ 2017-01-13 0:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484266817-6725-1-git-send-email-aospan@netup.ru>
On 1/12/2017 4:20 PM, Abylay Ospan wrote:
> pcie->dev->of_node not always defined (NULL) and can cause crash:
Ah I guess this can happen with the BCMA based platforms that do not use
device tree for PCIe?
>
> [ 19.053195] Unable to handle kernel NULL pointer dereference at
> virtual address 00000020
> [<c0b0370c>] (of_n_addr_cells) from [<c06599c4>]
> (iproc_pcie_setup+0x30c/0xce0)
>
> this patch adds sanity check to prevent crash.
>
> Signed-off-by: Abylay Ospan <aospan@netup.ru>
> ---
> drivers/pci/host/pcie-iproc.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/pci/host/pcie-iproc.c b/drivers/pci/host/pcie-iproc.c
> index 3ebc025..f2836a9 100644
> --- a/drivers/pci/host/pcie-iproc.c
> +++ b/drivers/pci/host/pcie-iproc.c
> @@ -952,6 +952,9 @@ static int pci_dma_range_parser_init(struct of_pci_range_parser *parser,
> const int na = 3, ns = 2;
> int rlen;
>
> + if (!node)
> + return -ENOENT;
> +
Looks like a valid check to me.
Acked-by: Ray Jui <ray.jui@broadcom.com>
> parser->node = node;
> parser->pna = of_n_addr_cells(node);
> parser->np = parser->pna + na + ns;
>
^ permalink raw reply
* [PATCH] PCI: iproc: fix kernel crash if dev->of_node not defined
From: Ray Jui @ 2017-01-13 0:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6891f43f-25e7-1411-800e-97e6788f2f27@gmail.com>
Hi Florian,
On 1/12/2017 4:22 PM, Florian Fainelli wrote:
> On 01/12/2017 04:20 PM, Abylay Ospan wrote:
>> pcie->dev->of_node not always defined (NULL) and can cause crash:
>>
>> [ 19.053195] Unable to handle kernel NULL pointer dereference at
>> virtual address 00000020
>> [<c0b0370c>] (of_n_addr_cells) from [<c06599c4>]
>> (iproc_pcie_setup+0x30c/0xce0)
>>
>> this patch adds sanity check to prevent crash.
>
> Humm, how can it not be defined based on your earlier comment that you
> are using this on NSP which is Device Tree exclusively? I would agree if
> this was seen on e.g: MIPS/BCMA (47xx).
I thought Abylay mentioned:
"Tested on Broadcom NorthStar machine ('Edgecore ECW7220-L') with two
PCIe wifi
adapters (b43 BCM4331 and ath10k QCA988X)."
That is a NorthStar device which is BCMA based?
>
>>
>> Signed-off-by: Abylay Ospan <aospan@netup.ru>
>> ---
>> drivers/pci/host/pcie-iproc.c | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/pci/host/pcie-iproc.c b/drivers/pci/host/pcie-iproc.c
>> index 3ebc025..f2836a9 100644
>> --- a/drivers/pci/host/pcie-iproc.c
>> +++ b/drivers/pci/host/pcie-iproc.c
>> @@ -952,6 +952,9 @@ static int pci_dma_range_parser_init(struct of_pci_range_parser *parser,
>> const int na = 3, ns = 2;
>> int rlen;
>>
>> + if (!node)
>> + return -ENOENT;
>> +
>> parser->node = node;
>> parser->pna = of_n_addr_cells(node);
>> parser->np = parser->pna + na + ns;
>>
>
>
^ permalink raw reply
* [PATCH] ARM64: dts: meson-gxbb-odroidc2: fix GbE tx link breakage
From: Kevin Hilman @ 2017-01-13 0:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482319894-656-1-git-send-email-jbrunet@baylibre.com>
Jerome Brunet <jbrunet@baylibre.com> writes:
> OdroidC2 GbE link breaks under heavy tx transfer. This happens even if the
> MAC does not enable Energy Efficient Ethernet (No Low Power state Idle on
> the Tx path). The problem seems to come from the phy Rx path, entering the
> LPI state.
>
> Disabling EEE advertisement on the phy prevent this feature to be
> negociated with the link partner and solve the issue.
>
> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
> ---
>
> This patch is based on Linus recent master branch [0]
> This patch depends on the series [1] which has been merged in this branch.
>
> 0: ba6d973f78eb ("Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net")
> 1: http://lkml.kernel.org/r/1480326409-25419-1-git-send-email-jbrunet at baylibre.com
> Fix integration of eee-broken-modes
>
> arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> index 238fbeacd330..d8933e9e9a5a 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> @@ -147,6 +147,18 @@
> status = "okay";
> pinctrl-0 = <ð_rgmii_pins>;
> pinctrl-names = "default";
> + phy-handle = <ð_phy0>;
> +
> + mdio {
> + compatible = "snps,dwmac-mdio";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + eth_phy0: ethernet-phy at 0 {
> + reg = <0>;
> + eee-broken-1000t;
> + };
> + };
There's already an MDIO node in the meson-gx.dtsi (using the same
compatible), shouldn't you just override that and add the new
properties?
What would make things easier is if the names were like Martin used in
his reset patch, so that when I merge them together it's not a major
conflict.
Thanks,
Kevin
[1] https://patchwork.kernel.org/patch/9459409/
^ permalink raw reply
* [PATCH v2 7/7] uapi: export all headers under uapi directories
From: Jeff Epler @ 2017-01-13 1:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9d68af8a-a609-d7b1-58a9-f1155313b077@6wind.com>
On Thu, Jan 12, 2017 at 05:32:09PM +0100, Nicolas Dichtel wrote:
> What I was trying to say is that I export those directories like other are.
> Removing those files is not related to that series.
Perhaps the correct solution is to only copy files matching "*.h" to
reduce the risk of copying files incidentally created by kbuild but
which shouldn't be installed as uapi headers.
jeff
^ permalink raw reply
* [PATCH] PCI: iproc: fix kernel crash if dev->of_node not defined
From: Florian Fainelli @ 2017-01-13 1:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e5301de6-9a6c-7deb-4ff7-ccd462c4381e@broadcom.com>
On 01/12/2017 04:48 PM, Ray Jui wrote:
> Hi Florian,
>
> On 1/12/2017 4:22 PM, Florian Fainelli wrote:
>> On 01/12/2017 04:20 PM, Abylay Ospan wrote:
>>> pcie->dev->of_node not always defined (NULL) and can cause crash:
>>>
>>> [ 19.053195] Unable to handle kernel NULL pointer dereference at
>>> virtual address 00000020
>>> [<c0b0370c>] (of_n_addr_cells) from [<c06599c4>]
>>> (iproc_pcie_setup+0x30c/0xce0)
>>>
>>> this patch adds sanity check to prevent crash.
>>
>> Humm, how can it not be defined based on your earlier comment that you
>> are using this on NSP which is Device Tree exclusively? I would agree if
>> this was seen on e.g: MIPS/BCMA (47xx).
>
> I thought Abylay mentioned:
>
> "Tested on Broadcom NorthStar machine ('Edgecore ECW7220-L') with two
> PCIe wifi
> adapters (b43 BCM4331 and ath10k QCA988X)."
>
> That is a NorthStar device which is BCMA based?
Still, upstream Linux support for Northstar is Device Tree, and BCMA bus
should fill in of_nodes accordingly, if not, that's a bug that must be
fixed at the BCMA layer.
>
>>
>>>
>>> Signed-off-by: Abylay Ospan <aospan@netup.ru>
>>> ---
>>> drivers/pci/host/pcie-iproc.c | 3 +++
>>> 1 file changed, 3 insertions(+)
>>>
>>> diff --git a/drivers/pci/host/pcie-iproc.c b/drivers/pci/host/pcie-iproc.c
>>> index 3ebc025..f2836a9 100644
>>> --- a/drivers/pci/host/pcie-iproc.c
>>> +++ b/drivers/pci/host/pcie-iproc.c
>>> @@ -952,6 +952,9 @@ static int pci_dma_range_parser_init(struct of_pci_range_parser *parser,
>>> const int na = 3, ns = 2;
>>> int rlen;
>>>
>>> + if (!node)
>>> + return -ENOENT;
>>> +
>>> parser->node = node;
>>> parser->pna = of_n_addr_cells(node);
>>> parser->np = parser->pna + na + ns;
>>>
>>
>>
--
Florian
^ permalink raw reply
* [PATCH v20 0/4] Mediatek MT8173 CMDQ support
From: Horng-Shyang Liao @ 2017-01-13 1:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483499169-16329-1-git-send-email-hs.liao@mediatek.com>
On Wed, 2017-01-04 at 11:06 +0800, HS Liao wrote:
> Hi,
>
> This is Mediatek MT8173 Command Queue(CMDQ) driver. The CMDQ is used
> to help write registers with critical time limitation, such as
> updating display configuration during the vblank. It controls Global
> Command Engine (GCE) hardware to achieve this requirement.
>
> These patches have a build dependency on top of v4.10-rc2.
>
> Changes since v19:
> - rebase to v4.10-rc2
>
> Best regards,
> HS Liao
>
> HS Liao (4):
> dt-bindings: soc: Add documentation for the MediaTek GCE unit
> mailbox: mediatek: Add Mediatek CMDQ driver
> arm64: dts: mt8173: Add GCE node
> soc: mediatek: Add Mediatek CMDQ helper
>
> .../devicetree/bindings/mailbox/mtk-gce.txt | 43 ++
> arch/arm64/boot/dts/mediatek/mt8173.dtsi | 10 +
> drivers/mailbox/Kconfig | 10 +
> drivers/mailbox/Makefile | 2 +
> drivers/mailbox/mtk-cmdq-mailbox.c | 596 +++++++++++++++++++++
> drivers/soc/mediatek/Kconfig | 12 +
> drivers/soc/mediatek/Makefile | 1 +
> drivers/soc/mediatek/mtk-cmdq-helper.c | 310 +++++++++++
> include/linux/mailbox/mtk-cmdq-mailbox.h | 75 +++
> include/linux/soc/mediatek/mtk-cmdq.h | 174 ++++++
> 10 files changed, 1233 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mailbox/mtk-gce.txt
> create mode 100644 drivers/mailbox/mtk-cmdq-mailbox.c
> create mode 100644 drivers/soc/mediatek/mtk-cmdq-helper.c
> create mode 100644 include/linux/mailbox/mtk-cmdq-mailbox.h
> create mode 100644 include/linux/soc/mediatek/mtk-cmdq.h
>
Hi Jassi, Matthias,
Sorry to disturb you.
Do you have any further comments on CMDQ v20?
Thanks.
HS
^ permalink raw reply
* [PATCH] coresight: STM: Balance enable/disable
From: Chunyan Zhang @ 2017-01-13 2:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e2710e1c-471d-2645-5ce0-30e222c85b52@arm.com>
On 11 January 2017 at 21:59, Suzuki K Poulose <Suzuki.Poulose@arm.com> wrote:
> On 11/01/17 11:41, Chunyan Zhang wrote:
>>
>> On 11 January 2017 at 01:36, Mathieu Poirier <mathieu.poirier@linaro.org>
>> wrote:
>>>
>>> On Tue, Jan 10, 2017 at 11:21:55AM +0000, Suzuki K Poulose wrote:
>>>>
>>>> The stm is automatically enabled when an application sets the policy
>>>> via ->link() call back by using coresight_enable(), which keeps the
>>>> refcount of the current users of the STM. However, the unlink() callback
>>>> issues stm_disable() directly, which leaves the STM turned off, without
>>>> the coresight layer knowing about it. This prevents any further uses
>>>> of the STM hardware as the coresight layer still thinks the STM is
>>>> turned on and doesn't issue an stm_enable(). Even manually enabling
>>>> the STM via sysfs can't really enable the hw.
>>>>
>>>> e.g,
>>>>
>>>> $ echo 1 > $CS_DEVS/$ETR/enable_sink
>>>> $ mkdir -p $CONFIG_FS/stp-policy/$source.0/stm_test/
>>>> $ echo 32768 65535 > $CONFIG_FS/stp-policy/$source.0/stm_test/channels
>>>> $ echo 64 > $CS_DEVS/$source/traceid
>>>> $ ./stm_app
>>>> Sending 64000 byte blocks of pattern 0 at 0us intervals
>>>> Success to map channel(32768~32783) to 0xffffa95fa000
>>>> Sending on channel 32768
>>>> $ dd if=/dev/$ETR of=~/trace.bin.1
>>>> 597+1 records in
>>>> 597+1 records out
>>>> 305920 bytes (306 kB) copied, 0.399952 s, 765 kB/s
>>>> $ ./stm_app
>>>> Sending 64000 byte blocks of pattern 0 at 0us intervals
>>>> Success to map channel(32768~32783) to 0xffff7e9e2000
>>>> Sending on channel 32768
>>>> $ dd if=/dev/$ETR of=~/trace.bin.2
>>>> 0+0 records in
>>>> 0+0 records out
>>>> 0 bytes (0 B) copied, 0.0232083 s, 0.0 kB/s
>>>>
>>>> Note that we don't get any data from the ETR for the second session.
>>>>
>>>> Also dmesg shows :
>>>>
>>>> [ 77.520458] coresight-tmc 20800000.etr: TMC-ETR enabled
>>>> [ 77.537097] coresight-replicator etr_replicator at 20890000: REPLICATOR
>>>> enabled
>>>> [ 77.558828] coresight-replicator main_replicator at 208a0000: REPLICATOR
>>>> enabled
>>>> [ 77.581068] coresight-funnel 208c0000.main_funnel: FUNNEL inport 0
>>>> enabled
>>>> [ 77.602217] coresight-tmc 20840000.etf: TMC-ETF enabled
>>>> [ 77.618422] coresight-stm 20860000.stm: STM tracing enabled
>>>> [ 139.554252] coresight-stm 20860000.stm: STM tracing disabled
>>>> # End of first tracing session
>>>> [ 146.351135] coresight-tmc 20800000.etr: TMC read start
>>>> [ 146.514486] coresight-tmc 20800000.etr: TMC read end
>>>> # Note that the STM is not turned on via
>>>> stm_generic_link()->coresight_enable()
>>>> # and hence none of the components are turned on.
>>>> [ 152.479080] coresight-tmc 20800000.etr: TMC read start
>>>> [ 152.542632] coresight-tmc 20800000.etr: TMC read end
>>>>
>>>> This patch balances the unlink operation by using the
>>>> coresight_disable(),
>>>> keeping the coresight layer in sync with the hardware state.
>>>>
>>>> Fixes: commit 237483aa5cf43 ("coresight: stm: adding driver for
>>>> CoreSight STM component")
>>>> Cc: Pratik Patel <pratikp@codeaurora.org>
>>>> Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
>>>> Cc: Chunyan Zhang <zhang.chunyan@linaro.org>
>>>> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>>>> Cc: stable at vger.kernel.org # 4.7+
>>>> Reported-by: Robert Walker <robert.walker@arm.com>
>>>> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
>>>> ---
>>>> drivers/hwtracing/coresight/coresight-stm.c | 2 +-
>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/hwtracing/coresight/coresight-stm.c
>>>> b/drivers/hwtracing/coresight/coresight-stm.c
>>>> index 3524452..57b7330 100644
>>>> --- a/drivers/hwtracing/coresight/coresight-stm.c
>>>> +++ b/drivers/hwtracing/coresight/coresight-stm.c
>>>> @@ -356,7 +356,7 @@ static void stm_generic_unlink(struct stm_data
>>>> *stm_data,
>>>> if (!drvdata || !drvdata->csdev)
>>>> return;
>>>>
>>>> - stm_disable(drvdata->csdev, NULL);
>>>> + coresight_disable(drvdata->csdev);
>>>
>>>
>>> This looks valid to me.
>>>
>>> Chunyan, any reason to use stm_disable() directly rather than calling it
>>> as part
>>> of the device OPS in coresight_disable()?
>>
>>
>> I don't think there's some special reason for this. I simply hadn't
>> noticed that these two operations didn't use two balanced functions.
>
>
> Please can I have an Ack/Reviewed -by on it, so that we can push it
> as a fix.
Sure, I've had a run with this patch, it works well, so,
Reviewed-by: Chunyan Zhang <zhang.chunyan@linaro.org>
Thanks,
Chunyan
>
>
> Suzuki
>
^ permalink raw reply
* [PATCH] arm64: dts: mt8173: Fix cpu_thermal cooling-maps contributions
From: Daniel Kurtz @ 2017-01-13 2:30 UTC (permalink / raw)
To: linux-arm-kernel
According to [0], the contribution field for each cooling-device express
their relative power efficiency. Higher weights express higher power
efficiency. Weighting is relative such that if each cooling device has a
weight of 1 they are considered equal. This is particularly useful in
heterogeneous systems where two cooling devices may perform the same kind
of compute, but with different efficiency.
[0] Documentation/thermal/power_allocator.txt
According to Mediatek IC designer, the power efficiency ratio between the
LITTLE core cluster (cooling-device cpu0) and big core cluster
(cooling-device cpu1) is around 3:1 (3072:1024).
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
---
arch/arm64/boot/dts/mediatek/mt8173.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 12e702771f5c..9a3b0d20f7a8 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -182,12 +182,12 @@
map at 0 {
trip = <&target>;
cooling-device = <&cpu0 0 0>;
- contribution = <1024>;
+ contribution = <3072>;
};
map at 1 {
trip = <&target>;
cooling-device = <&cpu2 0 0>;
- contribution = <2048>;
+ contribution = <1024>;
};
};
};
--
2.11.0.390.gc69c2f50cf-goog
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox