Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v3 4/7] i2c: bcm2835: Can't support I2C_M_IGNORE_NAK
From: Noralf Trønnes @ 2016-09-28 17:50 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1475085056-5205-1-git-send-email-noralf@tronnes.org>

The controller can't support this flag, so remove it.

Documentation/i2c/i2c-protocol states that all of the message is sent:

I2C_M_IGNORE_NAK:
    Normally message is interrupted immediately if there is [NA] from the
    client. Setting this flag treats any [NA] as [A], and all of
    message is sent.

>From the BCM2835 ARM Peripherals datasheet:

    The ERR field is set when the slave fails to acknowledge either
    its address or a data byte written to it.

So when the controller doesn't receive an ack, it sets ERR and raises
an interrupt. In other words, the whole message is not sent.

Signed-off-by: Noralf Tr?nnes <noralf@tronnes.org>
---
 drivers/i2c/busses/i2c-bcm2835.c | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/drivers/i2c/busses/i2c-bcm2835.c b/drivers/i2c/busses/i2c-bcm2835.c
index 8cdb139..99857f8 100644
--- a/drivers/i2c/busses/i2c-bcm2835.c
+++ b/drivers/i2c/busses/i2c-bcm2835.c
@@ -203,10 +203,6 @@ static int bcm2835_i2c_xfer_msg(struct bcm2835_i2c_dev *i2c_dev,
 	if (likely(!i2c_dev->msg_err))
 		return 0;
 
-	if ((i2c_dev->msg_err & BCM2835_I2C_S_ERR) &&
-	    (msg->flags & I2C_M_IGNORE_NAK))
-		return 0;
-
 	dev_dbg(i2c_dev->dev, "i2c transfer failed: %x\n", i2c_dev->msg_err);
 
 	if (i2c_dev->msg_err & BCM2835_I2C_S_ERR)
-- 
2.8.2

^ permalink raw reply related

* [PATCH v3 3/7] i2c: bcm2835: Use dev_dbg logging on transfer errors
From: Noralf Trønnes @ 2016-09-28 17:50 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1475085056-5205-1-git-send-email-noralf@tronnes.org>

Writing to an AT24C32 generates on average 2x i2c transfer errors per
32-byte page write. Which amounts to a lot for a 4k write. This is due
to the fact that the chip doesn't respond during it's internal write
cycle when the at24 driver tries and retries the next write.
Only a handful drivers use dev_err() on transfer error, so switch to
dev_dbg() instead.

Signed-off-by: Noralf Tr?nnes <noralf@tronnes.org>
---

Changes:
- use dev_dbg instead of dev_err_ratelimited

 drivers/i2c/busses/i2c-bcm2835.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/i2c/busses/i2c-bcm2835.c b/drivers/i2c/busses/i2c-bcm2835.c
index df036ed..8cdb139 100644
--- a/drivers/i2c/busses/i2c-bcm2835.c
+++ b/drivers/i2c/busses/i2c-bcm2835.c
@@ -207,7 +207,7 @@ static int bcm2835_i2c_xfer_msg(struct bcm2835_i2c_dev *i2c_dev,
 	    (msg->flags & I2C_M_IGNORE_NAK))
 		return 0;

-	dev_err(i2c_dev->dev, "i2c transfer failed: %x\n", i2c_dev->msg_err);
+	dev_dbg(i2c_dev->dev, "i2c transfer failed: %x\n", i2c_dev->msg_err);

 	if (i2c_dev->msg_err & BCM2835_I2C_S_ERR)
 		return -EREMOTEIO;
--
2.8.2

^ permalink raw reply related

* [PATCH v3 2/7] i2c: bcm2835: Protect against unexpected TXW/RXR interrupts
From: Noralf Trønnes @ 2016-09-28 17:50 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1475085056-5205-1-git-send-email-noralf@tronnes.org>

If an unexpected TXW or RXR interrupt occurs (msg_buf_remaining == 0),
the driver has no way to fill/drain the FIFO to stop the interrupts.
In this case the controller has to be disabled and the transfer
completed to avoid hang.

(CLKT | ERR) and DONE interrupts are completed in their own paths, and
the controller is disabled in the transfer function after completion.
Unite the code paths and do disabling inside the interrupt routine.

Clear interrupt status bits in the united completion path instead of
trying to do it on every interrupt which isn't necessary.
Only CLKT, ERR and DONE can be cleared that way.

Add the status value to the error value in case of TXW/RXR errors to
distinguish them from the other S_LEN error.

Signed-off-by: Noralf Tr?nnes <noralf@tronnes.org>
---
 drivers/i2c/busses/i2c-bcm2835.c | 31 ++++++++++++++++++++++---------
 1 file changed, 22 insertions(+), 9 deletions(-)

diff --git a/drivers/i2c/busses/i2c-bcm2835.c b/drivers/i2c/busses/i2c-bcm2835.c
index f283b71..df036ed 100644
--- a/drivers/i2c/busses/i2c-bcm2835.c
+++ b/drivers/i2c/busses/i2c-bcm2835.c
@@ -50,8 +50,6 @@
 #define BCM2835_I2C_S_CLKT	BIT(9)
 #define BCM2835_I2C_S_LEN	BIT(10) /* Fake bit for SW error reporting */
 
-#define BCM2835_I2C_BITMSK_S	0x03FF
-
 #define BCM2835_I2C_CDIV_MIN	0x0002
 #define BCM2835_I2C_CDIV_MAX	0xFFFE
 
@@ -117,14 +115,11 @@ static irqreturn_t bcm2835_i2c_isr(int this_irq, void *data)
 	u32 val, err;
 
 	val = bcm2835_i2c_readl(i2c_dev, BCM2835_I2C_S);
-	val &= BCM2835_I2C_BITMSK_S;
-	bcm2835_i2c_writel(i2c_dev, BCM2835_I2C_S, val);
 
 	err = val & (BCM2835_I2C_S_CLKT | BCM2835_I2C_S_ERR);
 	if (err) {
 		i2c_dev->msg_err = err;
-		complete(&i2c_dev->completion);
-		return IRQ_HANDLED;
+		goto complete;
 	}
 
 	if (val & BCM2835_I2C_S_DONE) {
@@ -137,21 +132,38 @@ static irqreturn_t bcm2835_i2c_isr(int this_irq, void *data)
 			i2c_dev->msg_err = BCM2835_I2C_S_LEN;
 		else
 			i2c_dev->msg_err = 0;
-		complete(&i2c_dev->completion);
-		return IRQ_HANDLED;
+		goto complete;
 	}
 
 	if (val & BCM2835_I2C_S_TXW) {
+		if (!i2c_dev->msg_buf_remaining) {
+			i2c_dev->msg_err = val | BCM2835_I2C_S_LEN;
+			goto complete;
+		}
+
 		bcm2835_fill_txfifo(i2c_dev);
 		return IRQ_HANDLED;
 	}
 
 	if (val & BCM2835_I2C_S_RXR) {
+		if (!i2c_dev->msg_buf_remaining) {
+			i2c_dev->msg_err = val | BCM2835_I2C_S_LEN;
+			goto complete;
+		}
+
 		bcm2835_drain_rxfifo(i2c_dev);
 		return IRQ_HANDLED;
 	}
 
 	return IRQ_NONE;
+
+complete:
+	bcm2835_i2c_writel(i2c_dev, BCM2835_I2C_C, BCM2835_I2C_C_CLEAR);
+	bcm2835_i2c_writel(i2c_dev, BCM2835_I2C_S, BCM2835_I2C_S_CLKT |
+			   BCM2835_I2C_S_ERR | BCM2835_I2C_S_DONE);
+	complete(&i2c_dev->completion);
+
+	return IRQ_HANDLED;
 }
 
 static int bcm2835_i2c_xfer_msg(struct bcm2835_i2c_dev *i2c_dev,
@@ -181,8 +193,9 @@ static int bcm2835_i2c_xfer_msg(struct bcm2835_i2c_dev *i2c_dev,
 
 	time_left = wait_for_completion_timeout(&i2c_dev->completion,
 						BCM2835_I2C_TIMEOUT);
-	bcm2835_i2c_writel(i2c_dev, BCM2835_I2C_C, BCM2835_I2C_C_CLEAR);
 	if (!time_left) {
+		bcm2835_i2c_writel(i2c_dev, BCM2835_I2C_C,
+				   BCM2835_I2C_C_CLEAR);
 		dev_err(i2c_dev->dev, "i2c transfer timed out\n");
 		return -ETIMEDOUT;
 	}
-- 
2.8.2

^ permalink raw reply related

* [PATCH v3 1/7] i2c: bcm2835: Fix hang for writing messages larger than 16 bytes
From: Noralf Trønnes @ 2016-09-28 17:50 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1475085056-5205-1-git-send-email-noralf@tronnes.org>

Writing messages larger than the FIFO size results in a hang, rendering
the machine unusable. This is because the RXD status flag is set on the
first interrupt which results in bcm2835_drain_rxfifo() stealing bytes
from the buffer. The controller continues to trigger interrupts waiting
for the missing bytes, but bcm2835_fill_txfifo() has none to give.
In this situation wait_for_completion_timeout() apparently is unable to
stop the madness.

The BCM2835 ARM Peripherals datasheet has this to say about the flags:
  TXD: is set when the FIFO has space for at least one byte of data.
  RXD: is set when the FIFO contains at least one byte of data.
  TXW: is set during a write transfer and the FIFO is less than full.
  RXR: is set during a read transfer and the FIFO is or more full.

Implementing the logic from the downstream i2c-bcm2708 driver solved
the hang problem.

Signed-off-by: Noralf Tr?nnes <noralf@tronnes.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Martin Sperl <kernel@martin.sperl.org>
---
 drivers/i2c/busses/i2c-bcm2835.c | 22 ++++++++++++++--------
 1 file changed, 14 insertions(+), 8 deletions(-)

diff --git a/drivers/i2c/busses/i2c-bcm2835.c b/drivers/i2c/busses/i2c-bcm2835.c
index d4f3239..f283b71 100644
--- a/drivers/i2c/busses/i2c-bcm2835.c
+++ b/drivers/i2c/busses/i2c-bcm2835.c
@@ -64,6 +64,7 @@ struct bcm2835_i2c_dev {
 	int irq;
 	struct i2c_adapter adapter;
 	struct completion completion;
+	struct i2c_msg *curr_msg;
 	u32 msg_err;
 	u8 *msg_buf;
 	size_t msg_buf_remaining;
@@ -126,14 +127,13 @@ static irqreturn_t bcm2835_i2c_isr(int this_irq, void *data)
 		return IRQ_HANDLED;
 	}
 
-	if (val & BCM2835_I2C_S_RXD) {
-		bcm2835_drain_rxfifo(i2c_dev);
-		if (!(val & BCM2835_I2C_S_DONE))
-			return IRQ_HANDLED;
-	}
-
 	if (val & BCM2835_I2C_S_DONE) {
-		if (i2c_dev->msg_buf_remaining)
+		if (i2c_dev->curr_msg->flags & I2C_M_RD) {
+			bcm2835_drain_rxfifo(i2c_dev);
+			val = bcm2835_i2c_readl(i2c_dev, BCM2835_I2C_S);
+		}
+
+		if ((val & BCM2835_I2C_S_RXD) || i2c_dev->msg_buf_remaining)
 			i2c_dev->msg_err = BCM2835_I2C_S_LEN;
 		else
 			i2c_dev->msg_err = 0;
@@ -141,11 +141,16 @@ static irqreturn_t bcm2835_i2c_isr(int this_irq, void *data)
 		return IRQ_HANDLED;
 	}
 
-	if (val & BCM2835_I2C_S_TXD) {
+	if (val & BCM2835_I2C_S_TXW) {
 		bcm2835_fill_txfifo(i2c_dev);
 		return IRQ_HANDLED;
 	}
 
+	if (val & BCM2835_I2C_S_RXR) {
+		bcm2835_drain_rxfifo(i2c_dev);
+		return IRQ_HANDLED;
+	}
+
 	return IRQ_NONE;
 }
 
@@ -155,6 +160,7 @@ static int bcm2835_i2c_xfer_msg(struct bcm2835_i2c_dev *i2c_dev,
 	u32 c;
 	unsigned long time_left;
 
+	i2c_dev->curr_msg = msg;
 	i2c_dev->msg_buf = msg->buf;
 	i2c_dev->msg_buf_remaining = msg->len;
 	reinit_completion(&i2c_dev->completion);
-- 
2.8.2

^ permalink raw reply related

* [PATCH v3 0/7] i2c: bcm2835: Bring in changes from downstream
From: Noralf Trønnes @ 2016-09-28 17:50 UTC (permalink / raw)
  To: linux-arm-kernel

This patchset tries to bring in the lessons learned in the downstream
driver i2c-bcm2708. The downstream clock stretcing timeout patch has
been left out since clock stretching is broken/unreliable on this
controller, so no point in setting it.

Changes since version 2:
- use dev_dbg instead for transfer errors
- drop i2c2 disabling patch, vc4 uses it.


Noralf.


Noralf Tr?nnes (7):
  i2c: bcm2835: Fix hang for writing messages larger than 16 bytes
  i2c: bcm2835: Protect against unexpected TXW/RXR interrupts
  i2c: bcm2835: Use dev_dbg logging on transfer errors
  i2c: bcm2835: Can't support I2C_M_IGNORE_NAK
  i2c: bcm2835: Add support for Repeated Start Condition
  i2c: bcm2835: Support i2c-dev ioctl I2C_TIMEOUT
  i2c: bcm2835: Add support for dynamic clock

 drivers/i2c/busses/i2c-bcm2835.c | 209 ++++++++++++++++++++++++---------------
 1 file changed, 130 insertions(+), 79 deletions(-)

--
2.8.2

^ permalink raw reply

* Crash seen on ARM Juno r1 with 4.8-rc8 when Coresight is enabled
From: Mathieu Poirier @ 2016-09-28 17:41 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CAGhh56EPK0BYbjV_v7cehT+yuB=L3O-AkFR2mLQMDAS66zDgDg@mail.gmail.com>

On 28 September 2016 at 10:35, Venkatesh Vivekanandan
<venkatesh.vivekanandan@broadcom.com> wrote:
> Hi All,
>
> I am trying to boot 4.8-rc8 in ARM Juno r1 board with coresight
> enabled and could see crash. When coresight is disabled at kernel
> config, then it boots to the linux prompt with rootfs in USB.
>
> I am using UEFI binary that came along with Juno-r1 board.
>
> Used following Image and dtb,
>
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> <------ git repo
> arch/arm64/boot/Image   <------ Kernel image
> arch/arm64/boot/dts/arm/juno-r1.dtb   <-------- dtb
>
> Attached both kernel config and complete crash log.
>
> Seen the same issue with arm64 repo also,
> git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git
>
> [    4.513529] atkbd serio1: keyboard reset failed on 1c070000.kmi
> [    5.479353] Unable to handle kernel NULL pointer dereference at
> virtual address 00000000
> [    5.487372] pgd = ffff000008db1000
> [    5.490739] [00000000] *pgd=00000009ffffe003,
> *pud=00000009ffffd003, *pmd=0000000000000000
> [    5.498940] Internal error: Oops: 96000004 [#1] PREEMPT SMP
> [    5.504451] Modules linked in:
> [    5.507474] CPU: 0 PID: 449 Comm: kworker/0:1 Not tainted 4.8.0-rc8-dirty #1
> [    5.514447] Hardware name: ARM Juno development board (r1) (DT)
> [    5.520310] Workqueue: events amba_deferred_retry_func
> [    5.525394] task: ffff800976bfd780 task.stack: ffff8009760bc000
> [    5.531253] PC is at strcmp+0x1c/0x160
> [    5.534962] LR is at coresight_orphan_match+0x78/0xc8
> [    5.539957] pc : [<ffff00000835f14c>] lr : [<ffff00000870231c>]
> pstate: 40000145
> [    5.547272] sp : ffff8009760bfa00
> [    5.550547] x29: ffff8009760bfa00 x28: ffff8009762c7f00
> [    5.555807] x27: ffff000008d66e46 x26: 0000000000000000
> [    5.561066] x25: 0000000000000001 x24: ffff000008702048
> [    5.566325] x23: 0000000000000000 x22: ffff800973ce5000
> [    5.571584] x21: ffff800973ce0800 x20: 0000000000000000
> [    5.576843] x19: ffff800976b08600 x18: 0000000000000000
> [    5.582101] x17: 0000000000000000 x16: ffff000008e52fff
> [    5.587360] x15: ffff000008e52fff x14: ffffffffffffffff
> [    5.592619] x13: ffff000008ca5000 x12: 0000000000000008
> [    5.597878] x11: 0000000000000020 x10: 0101010101010101
> [    5.603137] x9 : 0000000000000000 x8 : 7fff7f7f7f7f7f7f
> [    5.608396] x7 : 0000000000000000 x6 : 000000008008cb22
> [    5.613655] x5 : 22cb080000000000 x4 : ffff800973ce0828
> [    5.618914] x3 : 0000000000000000 x2 : 3030303031303032
> [    5.624173] x1 : 0000000000000000 x0 : ffff8009760f1d08
> [    5.629432]

Thanks you for reporting this Vankatesh,

Sudeep and Suzuki, can you guys help me with this - I don't have an R1
to test with.

Mathieu

>
>
> Thanks,
> Venkatesh.

^ permalink raw reply

* [PATCH 5/5] arm64: Add uprobe support
From: Catalin Marinas @ 2016-09-28 17:12 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <c7675b74-982d-d8b6-935f-a74139820174@redhat.com>

On Tue, Sep 27, 2016 at 08:33:25PM +0530, Pratyush Anand wrote:
> On Tuesday 27 September 2016 07:21 PM, Catalin Marinas wrote:
> >There is also the is_trap_at_addr() function which uses is_trap_insn().
> >I haven't checked the call paths here, are there any implications if
> >is_trap_insn() always returns false?
> 
> I had looked into it and also tested that a tracepoint at an application
> having a same instruction as that of "uprobe break instruction" ie "BRK
> #0x5" is rejected. So, I think a false positive return from is_tarp_insn()
> is still OK.

Looking at handle_swbp(), if we hit a breakpoint for which we don't have
a valid uprobe, this function currently sends a SIGTRAP. But if
is_trap_insn() returns false always, is_trap_at_addr() would return 0 in
this case so the SIGTRAP is never issued.

-- 
Catalin

^ permalink raw reply

* [PATCH] PCI: rockchip: fix uninitialized variable use
From: Bjorn Helgaas @ 2016-09-28 16:59 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20160922094018.2138640-1-arnd@arndb.de>

On Thu, Sep 22, 2016 at 11:39:59AM +0200, Arnd Bergmann wrote:
> The newly added pcie-rockchip driver fails to initialize the
> io_size variable if the DT doesn't provide ranges for the PCI
> I/O space, as found by building it with -Wmaybe-uninitialized:
> 
> drivers/pci/host/pcie-rockchip.c: In function 'rockchip_pcie_probe':
> drivers/pci/host/pcie-rockchip.c:1007:6: warning: 'io_size' may be used uninitialized in this function [-Wmaybe-uninitialized]
> 
> This adds an appropriate initialization immediately in front of
> the loop, so the io_size is zero as expected afterwards for that
> case.
> 
> Fixes: abe17181b16f ("PCI: rockchip: Add Rockchip PCIe controller support")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Thanks, I folded this into the original commit and added a note that it's
from you.

> ---
>  drivers/pci/host/pcie-rockchip.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/pci/host/pcie-rockchip.c b/drivers/pci/host/pcie-rockchip.c
> index c3593e633ccd..8bedc1e1ef80 100644
> --- a/drivers/pci/host/pcie-rockchip.c
> +++ b/drivers/pci/host/pcie-rockchip.c
> @@ -1078,6 +1078,7 @@ static int rockchip_pcie_probe(struct platform_device *pdev)
>  		goto err_vpcie;
>  
>  	/* Get the I/O and memory ranges from DT */
> +	io_size = 0;
>  	resource_list_for_each_entry(win, &res) {
>  		switch (resource_type(win->res)) {
>  		case IORESOURCE_IO:
> -- 
> 2.9.0
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* [PATCH 3/3] [v2] net: qcom/emac: initial ACPI support
From: Timur Tabi @ 2016-09-28 16:58 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1475081924-12362-1-git-send-email-timur@codeaurora.org>

Add support for reading addresses, interrupts, and _DSD properties
from ACPI tables, just like with device tree.  The HID for the
EMAC device itself is QCOM8070.  The internal PHY is represented
by a child node with a HID of QCOM8071.

The EMAC also has some complex clock initialization requirements
that are not represented by this patch.  This will be addressed
in a future patch.

Signed-off-by: Timur Tabi <timur@codeaurora.org>
---
 drivers/net/ethernet/qualcomm/emac/emac-phy.c   | 37 ++++++++++---
 drivers/net/ethernet/qualcomm/emac/emac-sgmii.c | 72 ++++++++++++++++++-------
 drivers/net/ethernet/qualcomm/emac/emac.c       | 12 +++++
 3 files changed, 95 insertions(+), 26 deletions(-)

diff --git a/drivers/net/ethernet/qualcomm/emac/emac-phy.c b/drivers/net/ethernet/qualcomm/emac/emac-phy.c
index c412ba9..da4e90d 100644
--- a/drivers/net/ethernet/qualcomm/emac/emac-phy.c
+++ b/drivers/net/ethernet/qualcomm/emac/emac-phy.c
@@ -19,6 +19,7 @@
 #include <linux/of_mdio.h>
 #include <linux/phy.h>
 #include <linux/iopoll.h>
+#include <linux/acpi.h>
 #include "emac.h"
 #include "emac-mac.h"
 #include "emac-phy.h"
@@ -167,7 +168,6 @@ static int emac_mdio_write(struct mii_bus *bus, int addr, int regnum, u16 val)
 int emac_phy_config(struct platform_device *pdev, struct emac_adapter *adpt)
 {
 	struct device_node *np = pdev->dev.of_node;
-	struct device_node *phy_np;
 	struct mii_bus *mii_bus;
 	int ret;
 
@@ -183,14 +183,37 @@ int emac_phy_config(struct platform_device *pdev, struct emac_adapter *adpt)
 	mii_bus->parent = &pdev->dev;
 	mii_bus->priv = adpt;
 
-	ret = of_mdiobus_register(mii_bus, np);
-	if (ret) {
-		dev_err(&pdev->dev, "could not register mdio bus\n");
-		return ret;
+	if (has_acpi_companion(&pdev->dev)) {
+		u32 phy_addr;
+
+		ret = mdiobus_register(mii_bus);
+		if (ret) {
+			dev_err(&pdev->dev, "could not register mdio bus\n");
+			return ret;
+		}
+		ret = device_property_read_u32(&pdev->dev, "phy-channel",
+					       &phy_addr);
+		if (ret)
+			/* If we can't read a valid phy address, then assume
+			 * that there is only one phy on this mdio bus.
+			 */
+			adpt->phydev = phy_find_first(mii_bus);
+		else
+			adpt->phydev = mdiobus_get_phy(mii_bus, phy_addr);
+
+	} else {
+		struct device_node *phy_np;
+
+		ret = of_mdiobus_register(mii_bus, np);
+		if (ret) {
+			dev_err(&pdev->dev, "could not register mdio bus\n");
+			return ret;
+		}
+
+		phy_np = of_parse_phandle(np, "phy-handle", 0);
+		adpt->phydev = of_phy_find_device(phy_np);
 	}
 
-	phy_np = of_parse_phandle(np, "phy-handle", 0);
-	adpt->phydev = of_phy_find_device(phy_np);
 	if (!adpt->phydev) {
 		dev_err(&pdev->dev, "could not find external phy\n");
 		mdiobus_unregister(mii_bus);
diff --git a/drivers/net/ethernet/qualcomm/emac/emac-sgmii.c b/drivers/net/ethernet/qualcomm/emac/emac-sgmii.c
index ad0e420..3d2c05a 100644
--- a/drivers/net/ethernet/qualcomm/emac/emac-sgmii.c
+++ b/drivers/net/ethernet/qualcomm/emac/emac-sgmii.c
@@ -14,6 +14,7 @@
  */
 
 #include <linux/iopoll.h>
+#include <linux/acpi.h>
 #include <linux/of_device.h>
 #include "emac.h"
 #include "emac-mac.h"
@@ -662,6 +663,24 @@ void emac_sgmii_reset(struct emac_adapter *adpt)
 	clk_set_rate(adpt->clk[EMAC_CLK_HIGH_SPEED], 125000000);
 }
 
+static int emac_sgmii_acpi_match(struct device *dev, void *data)
+{
+	static const struct acpi_device_id match_table[] = {
+		{
+			.id = "QCOM8071",
+			.driver_data = (kernel_ulong_t)emac_sgmii_init_v2,
+		},
+		{}
+	};
+	const struct acpi_device_id *id = acpi_match_device(match_table, dev);
+	emac_sgmii_initialize *initialize = data;
+
+	if (id)
+		*initialize = (emac_sgmii_initialize)id->driver_data;
+
+	return !!id;
+}
+
 static const struct of_device_id emac_sgmii_dt_match[] = {
 	{
 		.compatible = "qcom,fsm9900-emac-sgmii",
@@ -679,30 +698,45 @@ int emac_sgmii_config(struct platform_device *pdev, struct emac_adapter *adpt)
 	struct platform_device *sgmii_pdev = NULL;
 	struct emac_phy *phy = &adpt->phy;
 	struct resource *res;
-	const struct of_device_id *match;
-	struct device_node *np;
 	int ret;
 
-	np = of_parse_phandle(pdev->dev.of_node, "internal-phy", 0);
-	if (!np) {
-		dev_err(&pdev->dev, "missing internal-phy property\n");
-		return -ENODEV;
-	}
+	if (has_acpi_companion(&pdev->dev)) {
+		struct device *dev;
 
-	sgmii_pdev = of_find_device_by_node(np);
-	if (!sgmii_pdev) {
-		dev_err(&pdev->dev, "invalid internal-phy property\n");
-		return -ENODEV;
-	}
+		dev = device_find_child(&pdev->dev, &phy->initialize,
+					emac_sgmii_acpi_match);
 
-	match = of_match_device(emac_sgmii_dt_match, &sgmii_pdev->dev);
-	if (!match) {
-		dev_err(&pdev->dev, "unrecognized internal phy node\n");
-		ret = -ENODEV;
-		goto error_put_device;
-	}
+		if (!dev) {
+			dev_err(&pdev->dev, "cannot find internal phy node\n");
+			return -ENODEV;
+		}
 
-	phy->initialize = (emac_sgmii_initialize)match->data;
+		sgmii_pdev = to_platform_device(dev);
+	} else {
+		const struct of_device_id *match;
+		struct device_node *np;
+
+		np = of_parse_phandle(pdev->dev.of_node, "internal-phy", 0);
+		if (!np) {
+			dev_err(&pdev->dev, "missing internal-phy property\n");
+			return -ENODEV;
+		}
+
+		sgmii_pdev = of_find_device_by_node(np);
+		if (!sgmii_pdev) {
+			dev_err(&pdev->dev, "invalid internal-phy property\n");
+			return -ENODEV;
+		}
+
+		match = of_match_device(emac_sgmii_dt_match, &sgmii_pdev->dev);
+		if (!match) {
+			dev_err(&pdev->dev, "unrecognized internal phy node\n");
+			ret = -ENODEV;
+			goto error_put_device;
+		}
+
+		phy->initialize = (emac_sgmii_initialize)match->data;
+	}
 
 	/* Base address is the first address */
 	res = platform_get_resource(sgmii_pdev, IORESOURCE_MEM, 0);
diff --git a/drivers/net/ethernet/qualcomm/emac/emac.c b/drivers/net/ethernet/qualcomm/emac/emac.c
index 551df1c..9bf3b2b 100644
--- a/drivers/net/ethernet/qualcomm/emac/emac.c
+++ b/drivers/net/ethernet/qualcomm/emac/emac.c
@@ -22,6 +22,7 @@
 #include <linux/of_device.h>
 #include <linux/phy.h>
 #include <linux/platform_device.h>
+#include <linux/acpi.h>
 #include "emac.h"
 #include "emac-mac.h"
 #include "emac-phy.h"
@@ -575,6 +576,16 @@ static const struct of_device_id emac_dt_match[] = {
 	{}
 };
 
+#if IS_ENABLED(CONFIG_ACPI)
+static const struct acpi_device_id emac_acpi_match[] = {
+	{
+		.id = "QCOM8070",
+	},
+	{}
+};
+MODULE_DEVICE_TABLE(acpi, emac_acpi_match);
+#endif
+
 static int emac_probe(struct platform_device *pdev)
 {
 	struct net_device *netdev;
@@ -734,6 +745,7 @@ static struct platform_driver emac_platform_driver = {
 	.driver = {
 		.name		= "qcom-emac",
 		.of_match_table = emac_dt_match,
+		.acpi_match_table = ACPI_PTR(emac_acpi_match),
 	},
 };
 
-- 
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc.  Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.

^ permalink raw reply related

* [PATCH 2/3] [v2] net: qcom/emac: use device_get_mac_address
From: Timur Tabi @ 2016-09-28 16:58 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1475081924-12362-1-git-send-email-timur@codeaurora.org>

Replace the DT-specific of_get_mac_address() function with
device_get_mac_address, which works on both DT and ACPI platforms.  This
change makes it easier to add ACPI support.

Signed-off-by: Timur Tabi <timur@codeaurora.org>
---
 drivers/net/ethernet/qualcomm/emac/emac.c | 10 ++++------
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/net/ethernet/qualcomm/emac/emac.c b/drivers/net/ethernet/qualcomm/emac/emac.c
index 429b4cb..551df1c 100644
--- a/drivers/net/ethernet/qualcomm/emac/emac.c
+++ b/drivers/net/ethernet/qualcomm/emac/emac.c
@@ -531,18 +531,16 @@ static void emac_clks_teardown(struct emac_adapter *adpt)
 static int emac_probe_resources(struct platform_device *pdev,
 				struct emac_adapter *adpt)
 {
-	struct device_node *node = pdev->dev.of_node;
 	struct net_device *netdev = adpt->netdev;
 	struct resource *res;
-	const void *maddr;
+	char maddr[ETH_ALEN];
 	int ret = 0;
 
 	/* get mac address */
-	maddr = of_get_mac_address(node);
-	if (!maddr)
-		eth_hw_addr_random(netdev);
-	else
+	if (device_get_mac_address(&pdev->dev, maddr, ETH_ALEN))
 		ether_addr_copy(netdev->dev_addr, maddr);
+	else
+		eth_hw_addr_random(netdev);
 
 	/* Core 0 interrupt */
 	ret = platform_get_irq(pdev, 0);
-- 
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc.  Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.

^ permalink raw reply related

* [PATCH 1/3] [v2] net: qcom/emac: do not use devm on internal phy pdev
From: Timur Tabi @ 2016-09-28 16:58 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1475081924-12362-1-git-send-email-timur@codeaurora.org>

The platform_device returned by of_find_device_by_node() is not
automatically released when the driver unprobes.  Therefore,
managed calls like devm_ioremap_resource() should not be used.
Instead, we manually allocate the resources and then free them
on driver release.

Signed-off-by: Timur Tabi <timur@codeaurora.org>
---
 drivers/net/ethernet/qualcomm/emac/emac-sgmii.c | 42 +++++++++++++++++++------
 drivers/net/ethernet/qualcomm/emac/emac.c       |  4 +++
 2 files changed, 37 insertions(+), 9 deletions(-)

diff --git a/drivers/net/ethernet/qualcomm/emac/emac-sgmii.c b/drivers/net/ethernet/qualcomm/emac/emac-sgmii.c
index 6ab0a3c..ad0e420 100644
--- a/drivers/net/ethernet/qualcomm/emac/emac-sgmii.c
+++ b/drivers/net/ethernet/qualcomm/emac/emac-sgmii.c
@@ -681,6 +681,7 @@ int emac_sgmii_config(struct platform_device *pdev, struct emac_adapter *adpt)
 	struct resource *res;
 	const struct of_device_id *match;
 	struct device_node *np;
+	int ret;
 
 	np = of_parse_phandle(pdev->dev.of_node, "internal-phy", 0);
 	if (!np) {
@@ -697,25 +698,48 @@ int emac_sgmii_config(struct platform_device *pdev, struct emac_adapter *adpt)
 	match = of_match_device(emac_sgmii_dt_match, &sgmii_pdev->dev);
 	if (!match) {
 		dev_err(&pdev->dev, "unrecognized internal phy node\n");
-		return -ENODEV;
+		ret = -ENODEV;
+		goto error_put_device;
 	}
 
 	phy->initialize = (emac_sgmii_initialize)match->data;
 
 	/* Base address is the first address */
 	res = platform_get_resource(sgmii_pdev, IORESOURCE_MEM, 0);
-	phy->base = devm_ioremap_resource(&sgmii_pdev->dev, res);
-	if (IS_ERR(phy->base))
-		return PTR_ERR(phy->base);
+	phy->base = ioremap(res->start, resource_size(res));
+	if (IS_ERR(phy->base)) {
+		ret = PTR_ERR(phy->base);
+		goto error_put_device;
+	}
 
 	/* v2 SGMII has a per-lane digital digital, so parse it if it exists */
 	res = platform_get_resource(sgmii_pdev, IORESOURCE_MEM, 1);
 	if (res) {
-		phy->digital = devm_ioremap_resource(&sgmii_pdev->dev, res);
-		if (IS_ERR(phy->base))
-			return PTR_ERR(phy->base);
-
+		phy->digital = ioremap(res->start, resource_size(res));
+		if (IS_ERR(phy->digital)) {
+			ret = PTR_ERR(phy->digital);
+			goto error_unmap_base;
+		}
 	}
 
-	return phy->initialize(adpt);
+	ret = phy->initialize(adpt);
+	if (ret)
+		goto error;
+
+	/* We've remapped the addresses, so we don't need the device any
+	 * more.  of_find_device_by_node() says we should release it.
+	 */
+	put_device(&sgmii_pdev->dev);
+
+	return 0;
+
+error:
+	if (phy->digital)
+		iounmap(phy->digital);
+error_unmap_base:
+	iounmap(phy->base);
+error_put_device:
+	put_device(&sgmii_pdev->dev);
+
+	return ret;
 }
diff --git a/drivers/net/ethernet/qualcomm/emac/emac.c b/drivers/net/ethernet/qualcomm/emac/emac.c
index e47d387..429b4cb 100644
--- a/drivers/net/ethernet/qualcomm/emac/emac.c
+++ b/drivers/net/ethernet/qualcomm/emac/emac.c
@@ -723,6 +723,10 @@ static int emac_remove(struct platform_device *pdev)
 	mdiobus_unregister(adpt->mii_bus);
 	free_netdev(netdev);
 
+	if (adpt->phy.digital)
+		iounmap(adpt->phy.digital);
+	iounmap(adpt->phy.base);
+
 	return 0;
 }
 
-- 
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc.  Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.

^ permalink raw reply related

* [PATCH 0/3] [v2] Add basic ACPI support to the Qualcomm Technologies EMAC driver
From: Timur Tabi @ 2016-09-28 16:58 UTC (permalink / raw)
  To: linux-arm-kernel

This patch series adds support to the EMAC driver for extracting addresses,
interrupts, and some _DSDs (properties) from ACPI.  The first two patches
clean up the code, and the third patch adds ACPI-specific functionality.

The first patch fixes a bug with handling the platform_device for the
internal PHY.  This phy is treated as a separate device in both DT and
ACPI, but since the platform is not released automatically when the 
driver unloads, managed functions like devm_ioremap_resource cannot be
used. 

The second patch replaces of_get_mac_address with its platform-independent
equivalent device_get_mac_address.  

The third patch parses the ACPI tables to obtain the platform_device for
the primary EMAC node ("QCOM8070") and the internal phy node ("QCOM8071").

Timur Tabi (3):
  [v2] net: qcom/emac: do not use devm on internal phy pdev
  [v2] net: qcom/emac: use device_get_mac_address
  [v2] net: qcom/emac: initial ACPI support

 drivers/net/ethernet/qualcomm/emac/emac-phy.c   |  37 ++++++--
 drivers/net/ethernet/qualcomm/emac/emac-sgmii.c | 110 ++++++++++++++++++------
 drivers/net/ethernet/qualcomm/emac/emac.c       |  26 ++++--
 3 files changed, 134 insertions(+), 39 deletions(-)

-- 
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc.  Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.

^ permalink raw reply

* [GIT PULL] immutable branch to move HTC EGPIO from MFD to GPIO
From: Linus Walleij @ 2016-09-28 16:36 UTC (permalink / raw)
  To: linux-arm-kernel

Here is an immutable branch for you Lee - may be of interest to ARM SoC
or others touching arch/arm/mach-sa1100 or mach-pxa etc as well:

The following changes since commit 29b4817d4018df78086157ea3a55c1d9424a7cfc:

  Linux 4.8-rc1 (2016-08-07 18:18:00 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git
tags/ib-move-htc-egpio-mfd

for you to fetch changes up to 3c6e8d05d60d8106b5cdc730cf220b2a4b521b66:

  mfd/gpio: Move HTC GPIO driver to GPIO subsystem (2016-09-28 09:28:34 -0700)

----------------------------------------------------------------
Immutable branch to move the HTC EGPIO expande from MFD to GPIO

----------------------------------------------------------------
Linus Walleij (1):
      mfd/gpio: Move HTC GPIO driver to GPIO subsystem

 arch/arm/mach-pxa/hx4700.c                                        | 2 +-
 arch/arm/mach-pxa/magician.c                                      | 2 +-
 arch/arm/mach-sa1100/h3xxx.c                                      | 2 +-
 drivers/gpio/Kconfig                                              | 8 ++++++++
 drivers/gpio/Makefile                                             | 1 +
 drivers/{mfd/htc-egpio.c => gpio/gpio-htc-egpio.c}                | 2 +-
 drivers/mfd/Kconfig                                               | 8 --------
 drivers/mfd/Makefile                                              | 1 -
 include/linux/{mfd/htc-egpio.h => platform_data/gpio-htc-egpio.h} | 0
 9 files changed, 13 insertions(+), 13 deletions(-)
 rename drivers/{mfd/htc-egpio.c => gpio/gpio-htc-egpio.c} (99%)
 rename include/linux/{mfd/htc-egpio.h => platform_data/gpio-htc-egpio.h} (100%)

^ permalink raw reply

* [PATCH v6 0/3] arm64 kexec-tools patches
From: Matthias Brugger @ 2016-09-28 16:05 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <cover.1474481332.git.geoff@infradead.org>



On 21/09/16 20:14, Geoff Levand wrote:
> This series adds the core support for kexec re-boot on ARM64.
>

I also tested on seattle.

Tested-By: Matthias Brugger <mbrugger@suse.com>

> Linux kernel support for ARM64 kexec reboot has been merged in v4.8-rc1 with the
> expectation that it will be included in the v4.8 stable kernel release.
>
> For ARM64 kdump support see Takahiro's latest kdump patches [1].
>
> [1] http://lists.infradead.org/pipermail/kexec
>
> Changes for v6 (Sep , 2016, 2m):
>
>   o Remove the get_memory_ranges_dt() routine.
>   o Rename dtb_[12] to dtb_{proc,sys,user}.
>
> Changes for v5 (Sep 1, 2016, 2m):
>
>   o Add common routine arm64_locate_kernel_segment().
>
> Changes for v4 (Aug 18, 2016, 1m):
>
>   o Fix some error return values and error messages.
>   o Add enum arm64_header_page_size.
>   o Rename page_offset to vp_offset.
>
> Changes for v3 (Aug 10, 2016, 1m):
>
>   o Rebase to 2.0.13.
>   o Add support for flag bits 1-3 to arm64 image-header.h.
>   o Fix OPT_ARCH_MAX value.
>   o Use fdt_pack() in dtb_set_property().
>   o Remove patch ("kexec: (bugfix) calc correct end address of memory ranges in device tree").
>
> Changes for v2 (July 26, 2016, 0m):
>
>   o Inline some small routines.
>   o Reformat some dbgprintf messages.
>   o Remove debug_brk from entry.S
>   o Change arm64_image_header.flags to uint64_t.
>   o Look in iomem then dt for mem info.
>   o Remove check_cpu_nodes.
>   o Remove purgatory printing.
>
> First submission v1 (July 20, 2016).
>
> -Geoff
>
> The following changes since commit 67488beb0a6ee8ad2c0b05f721a9e00041fab93a:
>
>   kexec-tools 2.0.13 (2016-08-08 12:26:44 +0200)
>
> are available in the git repository at:
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/geoff/kexec-tools.git for-merge-arm64-v6
>
> for you to fetch changes up to a9f1fafd7c248d33768177438742b90bc4338202:
>
>   arm64: Add support for binary image files (2016-09-21 11:04:03 -0700)
>
> ----------------------------------------------------------------
> Geoff Levand (2):
>       kexec: Add common device tree routines
>       arm64: Add arm64 kexec support
>
> Pratyush Anand (1):
>       arm64: Add support for binary image files
>
>  configure.ac                            |   3 +
>  kexec/Makefile                          |   5 +
>  kexec/arch/arm64/Makefile               |  40 +++
>  kexec/arch/arm64/crashdump-arm64.c      |  21 ++
>  kexec/arch/arm64/crashdump-arm64.h      |  12 +
>  kexec/arch/arm64/image-header.h         | 146 ++++++++
>  kexec/arch/arm64/include/arch/options.h |  39 ++
>  kexec/arch/arm64/kexec-arm64.c          | 615 ++++++++++++++++++++++++++++++++
>  kexec/arch/arm64/kexec-arm64.h          |  71 ++++
>  kexec/arch/arm64/kexec-elf-arm64.c      | 146 ++++++++
>  kexec/arch/arm64/kexec-image-arm64.c    |  80 +++++
>  kexec/dt-ops.c                          | 145 ++++++++
>  kexec/dt-ops.h                          |  13 +
>  kexec/kexec-syscall.h                   |   8 +-
>  purgatory/Makefile                      |   1 +
>  purgatory/arch/arm64/Makefile           |  18 +
>  purgatory/arch/arm64/entry.S            |  51 +++
>  purgatory/arch/arm64/purgatory-arm64.c  |  19 +
>  18 files changed, 1431 insertions(+), 2 deletions(-)
>  create mode 100644 kexec/arch/arm64/Makefile
>  create mode 100644 kexec/arch/arm64/crashdump-arm64.c
>  create mode 100644 kexec/arch/arm64/crashdump-arm64.h
>  create mode 100644 kexec/arch/arm64/image-header.h
>  create mode 100644 kexec/arch/arm64/include/arch/options.h
>  create mode 100644 kexec/arch/arm64/kexec-arm64.c
>  create mode 100644 kexec/arch/arm64/kexec-arm64.h
>  create mode 100644 kexec/arch/arm64/kexec-elf-arm64.c
>  create mode 100644 kexec/arch/arm64/kexec-image-arm64.c
>  create mode 100644 kexec/dt-ops.c
>  create mode 100644 kexec/dt-ops.h
>  create mode 100644 purgatory/arch/arm64/Makefile
>  create mode 100644 purgatory/arch/arm64/entry.S
>  create mode 100644 purgatory/arch/arm64/purgatory-arm64.c
>

^ permalink raw reply

* [PATCH] MAINTAINERS: update entry for atmel_serial driver
From: Joe Perches @ 2016-09-28 16:04 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20160928154735.25265-1-nicolas.ferre@atmel.com>

On Wed, 2016-09-28 at 17:47 +0200, Nicolas Ferre wrote:
> Change maintainer for the serial driver found on most of the
> Microchip / Atmel MPUs and take advantage of the move to rename
> and reorder the entry.
[]
> diff --git a/MAINTAINERS b/MAINTAINERS
[]
> +MICROCHIP / ATMEL AT91 / AT32 SERIAL DRIVER
> +M:	Richard Genoud <richard.genoud@gmail.com>
> +S:	Maintained
> +F:	drivers/tty/serial/atmel_serial.c
> +F:	include/linux/atmel_serial.h

Thanks Richard.

include/linux is pretty cluttered with random files.

atmel_serial.h is #include exactly once.

Please move it out of include/linux and into
drivers/tty/serial/ one day.

^ permalink raw reply

* [PATCH] MAINTAINERS: update entry for atmel_serial driver
From: Richard Genoud @ 2016-09-28 15:57 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20160928155225.GA18790@kroah.com>

2016-09-28 17:52 GMT+02:00 Greg Kroah-Hartman <gregkh@linuxfoundation.org>:
> On Wed, Sep 28, 2016 at 05:47:35PM +0200, Nicolas Ferre wrote:
>> Change maintainer for the serial driver found on most of the
>> Microchip / Atmel MPUs and take advantage of the move to rename
>> and reorder the entry.
>> I'm happy that Richard is taking over the maintenance of this
>> driver.
>>
>> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
>
> Can I get an ack from Richard that he agrees with this?
absolutely !

Acked-by: Richard Genoud <richard.genoud@gmail.com>

> thanks,
>
> greg k-h

thanks !


-- 
for me, ck means con kolivas and not calvin klein... does it mean I'm a geek ?

^ permalink raw reply

* [PATCH] MAINTAINERS: update entry for atmel_serial driver
From: Greg Kroah-Hartman @ 2016-09-28 15:52 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20160928154735.25265-1-nicolas.ferre@atmel.com>

On Wed, Sep 28, 2016 at 05:47:35PM +0200, Nicolas Ferre wrote:
> Change maintainer for the serial driver found on most of the
> Microchip / Atmel MPUs and take advantage of the move to rename
> and reorder the entry.
> I'm happy that Richard is taking over the maintenance of this
> driver.
> 
> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>

Can I get an ack from Richard that he agrees with this?

thanks,

greg k-h

^ permalink raw reply

* [PATCH] MAINTAINERS: update entry for atmel_serial driver
From: Nicolas Ferre @ 2016-09-28 15:47 UTC (permalink / raw)
  To: linux-arm-kernel

Change maintainer for the serial driver found on most of the
Microchip / Atmel MPUs and take advantage of the move to rename
and reorder the entry.
I'm happy that Richard is taking over the maintenance of this
driver.

Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
---
 MAINTAINERS | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index e39dacd77c0e..06c17717a004 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2140,11 +2140,6 @@ M:	Ludovic Desroches <ludovic.desroches@atmel.com>
 S:	Maintained
 F:	drivers/mmc/host/atmel-mci.c
 
-ATMEL AT91 / AT32 SERIAL DRIVER
-M:	Nicolas Ferre <nicolas.ferre@atmel.com>
-S:	Supported
-F:	drivers/tty/serial/atmel_serial.c
-
 ATMEL AT91 SAMA5D2-Compatible Shutdown Controller
 M:	Nicolas Ferre <nicolas.ferre@atmel.com>
 S:	Supported
@@ -7930,6 +7925,12 @@ T:	git git://git.monstr.eu/linux-2.6-microblaze.git
 S:	Supported
 F:	arch/microblaze/
 
+MICROCHIP / ATMEL AT91 / AT32 SERIAL DRIVER
+M:	Richard Genoud <richard.genoud@gmail.com>
+S:	Maintained
+F:	drivers/tty/serial/atmel_serial.c
+F:	include/linux/atmel_serial.h
+
 MICROCHIP / ATMEL ISC DRIVER
 M:	Songjun Wu <songjun.wu@microchip.com>
 L:	linux-media at vger.kernel.org
-- 
2.9.0

^ permalink raw reply related

* [PATCH v3 1/3] ipmi: add an Aspeed BT IPMI BMC driver
From: Cédric Le Goater @ 2016-09-28 14:08 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <85dc3a75-46e0-87ec-91d5-31e686103ee0@acm.org>

On 09/28/2016 03:53 PM, Corey Minyard wrote:
> On 09/26/2016 01:50 AM, C?dric Le Goater wrote:
>>
>>>>   Changes since v1:
>>>>
>>>>   - replace 'bt_host' by 'bt_bmc' to reflect that the driver is
>>>>     the BMC side of the IPMI BT interface
>>>>   - renamed the device to 'ipmi-bt-host'
>>>>   - introduced a temporary buffer to copy_{to,from}_user
>>>>   - used platform_get_irq()
>>>>   - moved the driver under drivers/char/ipmi/ but kept it as a misc
>>>>     device
>>>>   - changed the compatible cell to "aspeed,ast2400-bt-bmc"
>>>>
>>>>   .../bindings/char/ipmi/aspeed,ast2400-bt-bmc.txt   |  23 +
>>> While similar, this is not the kernel directory structure. Just make
>>> this bindings/ipmi/
>>>
>>> With that,
>>>
>>> Acked-by: Rob Herring <robh@kernel.org>
>> OK. So I suppose we should be moving all IPMI documentation under
>> the same directory.
>>
>>
>> Corey,
>>
>> If the move is okay for you, I can send the patch below.
>>
>> Thanks,
>>
>> C.
> 
> Sorry this took so long, I'm at a conference.  That change is fine, it does
> seem to match the structure better.

It's ok. 

Checkpatch really does not like that patch and I don't know what we can
do about it. You've been warned :) 

Thanks, 

C. 


./scripts/checkpatch.pl --strict  0001-dt-bindings-ipmi-move-all-documentation-under-bindin.patch
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#12: 
 .../devicetree/bindings/{char => }/ipmi/aspeed,ast2400-bt-bmc.txt         | 0

ERROR: Does not appear to be a unified-diff format patch

total: 1 errors, 1 warnings, 0 checks, 0 lines checked

^ permalink raw reply

* [PATCH] dt-bindings: ipmi: move all documentation under bindings/ipmi/
From: Cédric Le Goater @ 2016-09-28 14:07 UTC (permalink / raw)
  To: linux-arm-kernel

Signed-off-by: C?dric Le Goater <clg@kaod.org>
---
 .../devicetree/bindings/{char => }/ipmi/aspeed,ast2400-bt-bmc.txt         | 0
 Documentation/devicetree/bindings/{ipmi.txt => ipmi/ipmi-smic.txt}        | 0
 2 files changed, 0 insertions(+), 0 deletions(-)
 rename Documentation/devicetree/bindings/{char => }/ipmi/aspeed,ast2400-bt-bmc.txt (100%)
 rename Documentation/devicetree/bindings/{ipmi.txt => ipmi/ipmi-smic.txt} (100%)

diff --git a/Documentation/devicetree/bindings/char/ipmi/aspeed,ast2400-bt-bmc.txt b/Documentation/devicetree/bindings/ipmi/aspeed,ast2400-bt-bmc.txt
similarity index 100%
rename from Documentation/devicetree/bindings/char/ipmi/aspeed,ast2400-bt-bmc.txt
rename to Documentation/devicetree/bindings/ipmi/aspeed,ast2400-bt-bmc.txt
diff --git a/Documentation/devicetree/bindings/ipmi.txt b/Documentation/devicetree/bindings/ipmi/ipmi-smic.txt
similarity index 100%
rename from Documentation/devicetree/bindings/ipmi.txt
rename to Documentation/devicetree/bindings/ipmi/ipmi-smic.txt
-- 
2.7.4

^ permalink raw reply

* [PATCH v3 1/3] ipmi: add an Aspeed BT IPMI BMC driver
From: Corey Minyard @ 2016-09-28 13:53 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <c3f084ab-9f77-86ab-7875-cbfe654ea18e@kaod.org>

On 09/26/2016 01:50 AM, C?dric Le Goater wrote:
>
>>>   Changes since v1:
>>>
>>>   - replace 'bt_host' by 'bt_bmc' to reflect that the driver is
>>>     the BMC side of the IPMI BT interface
>>>   - renamed the device to 'ipmi-bt-host'
>>>   - introduced a temporary buffer to copy_{to,from}_user
>>>   - used platform_get_irq()
>>>   - moved the driver under drivers/char/ipmi/ but kept it as a misc
>>>     device
>>>   - changed the compatible cell to "aspeed,ast2400-bt-bmc"
>>>
>>>   .../bindings/char/ipmi/aspeed,ast2400-bt-bmc.txt   |  23 +
>> While similar, this is not the kernel directory structure. Just make
>> this bindings/ipmi/
>>
>> With that,
>>
>> Acked-by: Rob Herring <robh@kernel.org>
> OK. So I suppose we should be moving all IPMI documentation under
> the same directory.
>
>
> Corey,
>
> If the move is okay for you, I can send the patch below.
>
> Thanks,
>
> C.

Sorry this took so long, I'm at a conference.  That change is fine, it does
seem to match the structure better.

-corey
>
>  From ca25f89b25209c260480cda5e5532d6bbe83ed43 Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?C=C3=A9dric=20Le=20Goater?= <clg@kaod.org>
> Date: Mon, 26 Sep 2016 08:45:15 +0200
> Subject: [PATCH] dt-bindings: ipmi: move all documentation under
>   bindings/ipmi/
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> Signed-off-by: C?dric Le Goater <clg@kaod.org>
> ---
>   .../devicetree/bindings/{char => }/ipmi/aspeed,ast2400-bt-bmc.txt         | 0
>   Documentation/devicetree/bindings/{ipmi.txt => ipmi/ipmi-smic.txt}        | 0
>   2 files changed, 0 insertions(+), 0 deletions(-)
>   rename Documentation/devicetree/bindings/{char => }/ipmi/aspeed,ast2400-bt-bmc.txt (100%)
>   rename Documentation/devicetree/bindings/{ipmi.txt => ipmi/ipmi-smic.txt} (100%)
>
> diff --git a/Documentation/devicetree/bindings/char/ipmi/aspeed,ast2400-bt-bmc.txt b/Documentation/devicetree/bindings/ipmi/aspeed,ast2400-bt-bmc.txt
> similarity index 100%
> rename from Documentation/devicetree/bindings/char/ipmi/aspeed,ast2400-bt-bmc.txt
> rename to Documentation/devicetree/bindings/ipmi/aspeed,ast2400-bt-bmc.txt
> diff --git a/Documentation/devicetree/bindings/ipmi.txt b/Documentation/devicetree/bindings/ipmi/ipmi-smic.txt
> similarity index 100%
> rename from Documentation/devicetree/bindings/ipmi.txt
> rename to Documentation/devicetree/bindings/ipmi/ipmi-smic.txt

^ permalink raw reply

* [PATCH 4/7] arm64: tlbflush.h: add __tlbi() macro
From: Will Deacon @ 2016-09-28 12:48 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20160923160710.GF6397@arm.com>

On Fri, Sep 23, 2016 at 05:07:10PM +0100, Will Deacon wrote:
> On Tue, Sep 13, 2016 at 11:16:06AM +0100, Punit Agrawal wrote:
> > From: Mark Rutland <mark.rutland@arm.com>
> > 
> > As with dsb() and isb(), add a __tlbi() helper so that we can avoid
> > distracting asm boilerplate every time we want a TLBI. As some TLBI
> > operations take an argument while others do not, some pre-processor is
> > used to handle these two cases with different assembly blocks.
> > 
> > The existing tlbflush.h code is moved over to use the helper.
> > 
> > Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> > Cc: Catalin Marinas <catalin.marinas@arm.com>
> > Cc: Marc Zyngier <marc.zyngier@arm.com>
> > [ rename helper to __tlbi, update comment and commit log ]
> > Signed-off-by: Punit Agrawal <punit.agrawal@arm.com>
> > Reviewed-by: Will Deacon <will.deacon@arm.com>
> > ---
> >  arch/arm64/include/asm/tlbflush.h | 34 ++++++++++++++++++++++++++--------
> >  1 file changed, 26 insertions(+), 8 deletions(-)
> 
> Given that this series seems to have stalled, I'm inclined to pick this
> patch (and only this patch) up in the arm64 tree. It's a standalone tidy
> up and means one fewer dependency next time round.

Ok, I've picked this one up. Please re-post the rest of the series after
the merge window.

Will

^ permalink raw reply

* [PATCH v1] ARM: decompressor: reset ttbcr fields to use TTBR0 on ARMv7
From: Srinivas Ramana @ 2016-09-28 12:45 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <3441d0c3-c4b6-a795-a841-b61a8866ce17@arm.com>

If the bootloader uses the long descriptor format and jumps to
kernel decompressor code, TTBCR may not be in a right state.
Before enabling the MMU, it is required to clear the TTBCR.PD0
field to use TTBR0 for translation table walks.

The commit dbece45894d3a ("ARM: 7501/1: decompressor:
reset ttbcr for VMSA ARMv7 cores") does the reset of TTBCR.N, but
doesn't consider all the bits for the size of TTBCR.N.

Clear TTBCR.PD0 field and reset all the three bits of TTBCR.N to
indicate the use of TTBR0 and the correct base address width.

Fixes: dbece45894d3 ("ARM: 7501/1: decompressor: reset ttbcr for VMSA ARMv7 cores")
Acked-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Srinivas Ramana <sramana@codeaurora.org>
---
 arch/arm/boot/compressed/head.S | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
index af11c2f8f3b7..fc6d541549a2 100644
--- a/arch/arm/boot/compressed/head.S
+++ b/arch/arm/boot/compressed/head.S
@@ -779,7 +779,7 @@ __armv7_mmu_cache_on:
 		orrne	r0, r0, #1		@ MMU enabled
 		movne	r1, #0xfffffffd		@ domain 0 = client
 		bic     r6, r6, #1 << 31        @ 32-bit translation system
-		bic     r6, r6, #3 << 0         @ use only ttbr0
+		bic     r6, r6, #(7 << 0) | (1 << 4)	@ use only ttbr0
 		mcrne	p15, 0, r3, c2, c0, 0	@ load page table pointer
 		mcrne	p15, 0, r1, c3, c0, 0	@ load domain access control
 		mcrne   p15, 0, r6, c2, c0, 2   @ load ttb control
-- 
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc., 
is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.

^ permalink raw reply related

* [PATCH 4/4] ARM: davinci: dm365: Remove DMA resources for SPI
From: Peter Ujfalusi @ 2016-09-28 10:35 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20160928103530.15291-1-peter.ujfalusi@ti.com>

The driver is converted to not use the DMA resource.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
 arch/arm/mach-davinci/dm365.c | 8 --------
 1 file changed, 8 deletions(-)

diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index ef3add999263..8be04ec95adf 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -660,14 +660,6 @@ static struct resource dm365_spi0_resources[] = {
 		.start = IRQ_DM365_SPIINT0_0,
 		.flags = IORESOURCE_IRQ,
 	},
-	{
-		.start = 17,
-		.flags = IORESOURCE_DMA,
-	},
-	{
-		.start = 16,
-		.flags = IORESOURCE_DMA,
-	},
 };
 
 static struct platform_device dm365_spi0_device = {
-- 
2.10.0

^ permalink raw reply related

* [PATCH 3/4] ARM: davinci: dm355: Remove DMA resources for SPI
From: Peter Ujfalusi @ 2016-09-28 10:35 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20160928103530.15291-1-peter.ujfalusi@ti.com>

The driver is converted to not use the DMA resource.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
 arch/arm/mach-davinci/dm355.c | 8 --------
 1 file changed, 8 deletions(-)

diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index d33322ddedab..bd50367f654e 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -397,14 +397,6 @@ static struct resource dm355_spi0_resources[] = {
 		.start = IRQ_DM355_SPINT0_0,
 		.flags = IORESOURCE_IRQ,
 	},
-	{
-		.start = 17,
-		.flags = IORESOURCE_DMA,
-	},
-	{
-		.start = 16,
-		.flags = IORESOURCE_DMA,
-	},
 };
 
 static struct davinci_spi_platform_data dm355_spi0_pdata = {
-- 
2.10.0

^ 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