* [PATCH v3 2/4] bluetooth: hci_uart: remove unused hci_uart_init_tty
From: Rob Herring @ 2017-04-13 15:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170413150353.7389-1-robh@kernel.org>
There are no users of hci_uart_init_tty, so remove it.
Signed-off-by: Rob Herring <robh@kernel.org>
Cc: Marcel Holtmann <marcel@holtmann.org>
Cc: Gustavo Padovan <gustavo@padovan.org>
Cc: Johan Hedberg <johan.hedberg@gmail.com>
Cc: linux-bluetooth at vger.kernel.org
---
v3:
- rebase on bluetooth-next
drivers/bluetooth/hci_ldisc.c | 19 -------------------
drivers/bluetooth/hci_uart.h | 1 -
2 files changed, 20 deletions(-)
diff --git a/drivers/bluetooth/hci_ldisc.c b/drivers/bluetooth/hci_ldisc.c
index 17bcbc13623f..cec4438ede01 100644
--- a/drivers/bluetooth/hci_ldisc.c
+++ b/drivers/bluetooth/hci_ldisc.c
@@ -319,25 +319,6 @@ void hci_uart_set_speeds(struct hci_uart *hu, unsigned int init_speed,
hu->oper_speed = oper_speed;
}
-void hci_uart_init_tty(struct hci_uart *hu)
-{
- struct tty_struct *tty = hu->tty;
- struct ktermios ktermios;
-
- /* Bring the UART into a known 8 bits no parity hw fc state */
- ktermios = tty->termios;
- ktermios.c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP |
- INLCR | IGNCR | ICRNL | IXON);
- ktermios.c_oflag &= ~OPOST;
- ktermios.c_lflag &= ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN);
- ktermios.c_cflag &= ~(CSIZE | PARENB);
- ktermios.c_cflag |= CS8;
- ktermios.c_cflag |= CRTSCTS;
-
- /* tty_set_termios() return not checked as it is always 0 */
- tty_set_termios(tty, &ktermios);
-}
-
void hci_uart_set_baudrate(struct hci_uart *hu, unsigned int speed)
{
struct tty_struct *tty = hu->tty;
diff --git a/drivers/bluetooth/hci_uart.h b/drivers/bluetooth/hci_uart.h
index 1b41c661bbb8..2b05e557fad0 100644
--- a/drivers/bluetooth/hci_uart.h
+++ b/drivers/bluetooth/hci_uart.h
@@ -114,7 +114,6 @@ int hci_uart_register_device(struct hci_uart *hu, const struct hci_uart_proto *p
int hci_uart_tx_wakeup(struct hci_uart *hu);
int hci_uart_init_ready(struct hci_uart *hu);
-void hci_uart_init_tty(struct hci_uart *hu);
void hci_uart_set_baudrate(struct hci_uart *hu, unsigned int speed);
void hci_uart_set_flow_control(struct hci_uart *hu, bool enable);
void hci_uart_set_speeds(struct hci_uart *hu, unsigned int init_speed,
--
2.11.0
^ permalink raw reply related
* [PATCH v3 3/4] bluetooth: hci_uart: add LL protocol serdev driver support
From: Rob Herring @ 2017-04-13 15:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170413150353.7389-1-robh@kernel.org>
Turns out that the LL protocol and the TI-ST are the same thing AFAICT.
The TI-ST adds firmware loading, GPIO control, and shared access for
NFC, FM radio, etc. For now, we're only implementing what is needed for
BT. This mirrors other drivers like BCM and Intel, but uses the new
serdev bus.
The firmware loading is greatly simplified by using existing
infrastructure to send commands. It may be a bit slower than the
original code using synchronous functions, but the real bottleneck is
likely doing firmware load at 115.2kbps.
Signed-off-by: Rob Herring <robh@kernel.org>
Cc: Marcel Holtmann <marcel@holtmann.org>
Cc: Gustavo Padovan <gustavo@padovan.org>
Cc: Johan Hedberg <johan.hedberg@gmail.com>
Cc: linux-bluetooth at vger.kernel.org
---
v3:
- rebase on bluetooth-next
- Add explicit of.h include
v2:
- Use IS_ENABLED() to fix module build
drivers/bluetooth/hci_ll.c | 262 ++++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 261 insertions(+), 1 deletion(-)
diff --git a/drivers/bluetooth/hci_ll.c b/drivers/bluetooth/hci_ll.c
index 02692fe30279..485e8eb04542 100644
--- a/drivers/bluetooth/hci_ll.c
+++ b/drivers/bluetooth/hci_ll.c
@@ -34,20 +34,24 @@
#include <linux/sched.h>
#include <linux/types.h>
#include <linux/fcntl.h>
+#include <linux/firmware.h>
#include <linux/interrupt.h>
#include <linux/ptrace.h>
#include <linux/poll.h>
#include <linux/slab.h>
-#include <linux/tty.h>
#include <linux/errno.h>
#include <linux/string.h>
#include <linux/signal.h>
#include <linux/ioctl.h>
+#include <linux/of.h>
+#include <linux/serdev.h>
#include <linux/skbuff.h>
+#include <linux/ti_wilink_st.h>
#include <net/bluetooth/bluetooth.h>
#include <net/bluetooth/hci_core.h>
+#include <linux/gpio/consumer.h>
#include "hci_uart.h"
@@ -76,6 +80,12 @@ struct hcill_cmd {
u8 cmd;
} __packed;
+struct ll_device {
+ struct hci_uart hu;
+ struct serdev_device *serdev;
+ struct gpio_desc *enable_gpio;
+};
+
struct ll_struct {
unsigned long rx_state;
unsigned long rx_count;
@@ -136,6 +146,9 @@ static int ll_open(struct hci_uart *hu)
hu->priv = ll;
+ if (hu->serdev)
+ serdev_device_open(hu->serdev);
+
return 0;
}
@@ -164,6 +177,13 @@ static int ll_close(struct hci_uart *hu)
kfree_skb(ll->rx_skb);
+ if (hu->serdev) {
+ struct ll_device *lldev = serdev_device_get_drvdata(hu->serdev);
+ gpiod_set_value_cansleep(lldev->enable_gpio, 0);
+
+ serdev_device_close(hu->serdev);
+ }
+
hu->priv = NULL;
kfree(ll);
@@ -505,9 +525,245 @@ static struct sk_buff *ll_dequeue(struct hci_uart *hu)
return skb_dequeue(&ll->txq);
}
+#if IS_ENABLED(CONFIG_SERIAL_DEV_BUS)
+static int read_local_version(struct hci_dev *hdev)
+{
+ int err = 0;
+ unsigned short version = 0;
+ struct sk_buff *skb;
+ struct hci_rp_read_local_version *ver;
+
+ skb = __hci_cmd_sync(hdev, HCI_OP_READ_LOCAL_VERSION, 0, NULL, HCI_INIT_TIMEOUT);
+ if (IS_ERR(skb)) {
+ bt_dev_err(hdev, "Reading TI version information failed (%ld)",
+ PTR_ERR(skb));
+ err = PTR_ERR(skb);
+ goto out;
+ }
+ if (skb->len != sizeof(*ver)) {
+ err = -EILSEQ;
+ goto out;
+ }
+
+ ver = (struct hci_rp_read_local_version *)skb->data;
+ if (le16_to_cpu(ver->manufacturer) != 13) {
+ err = -ENODEV;
+ goto out;
+ }
+
+ version = le16_to_cpu(ver->lmp_subver);
+
+out:
+ if (err) bt_dev_err(hdev, "Failed to read TI version info: %d", err);
+ kfree_skb(skb);
+ return err ? err : version;
+}
+
+/**
+ * download_firmware -
+ * internal function which parses through the .bts firmware
+ * script file intreprets SEND, DELAY actions only as of now
+ */
+static int download_firmware(struct ll_device *lldev)
+{
+ unsigned short chip, min_ver, maj_ver;
+ int version, err, len;
+ unsigned char *ptr, *action_ptr;
+ unsigned char bts_scr_name[40]; /* 40 char long bts scr name? */
+ const struct firmware *fw;
+ struct sk_buff *skb;
+ struct hci_command *cmd;
+
+ version = read_local_version(lldev->hu.hdev);
+ if (version < 0)
+ return version;
+
+ chip = (version & 0x7C00) >> 10;
+ min_ver = (version & 0x007F);
+ maj_ver = (version & 0x0380) >> 7;
+ if (version & 0x8000)
+ maj_ver |= 0x0008;
+
+ snprintf(bts_scr_name, sizeof(bts_scr_name),
+ "ti-connectivity/TIInit_%d.%d.%d.bts",
+ chip, maj_ver, min_ver);
+
+ err = request_firmware(&fw, bts_scr_name, &lldev->serdev->dev);
+ if (err || !fw->data || !fw->size) {
+ bt_dev_err(lldev->hu.hdev, "request_firmware failed(errno %d) for %s",
+ err, bts_scr_name);
+ return -EINVAL;
+ }
+ ptr = (void *)fw->data;
+ len = fw->size;
+ /* bts_header to remove out magic number and
+ * version
+ */
+ ptr += sizeof(struct bts_header);
+ len -= sizeof(struct bts_header);
+
+ while (len > 0 && ptr) {
+ bt_dev_dbg(lldev->hu.hdev, " action size %d, type %d ",
+ ((struct bts_action *)ptr)->size,
+ ((struct bts_action *)ptr)->type);
+
+ action_ptr = &(((struct bts_action *)ptr)->data[0]);
+
+ switch (((struct bts_action *)ptr)->type) {
+ case ACTION_SEND_COMMAND: /* action send */
+ bt_dev_dbg(lldev->hu.hdev, "S");
+ cmd = (struct hci_command *)action_ptr;
+ if (cmd->opcode == 0xff36) {
+ /* ignore remote change
+ * baud rate HCI VS command */
+ bt_dev_warn(lldev->hu.hdev, "change remote baud rate command in firmware");
+ break;
+ }
+ if (cmd->prefix != 1)
+ bt_dev_dbg(lldev->hu.hdev, "command type %d\n", cmd->prefix);
+
+ skb = __hci_cmd_sync(lldev->hu.hdev, cmd->opcode, cmd->plen, &cmd->speed, HCI_INIT_TIMEOUT);
+ if (IS_ERR(skb)) {
+ bt_dev_err(lldev->hu.hdev, "send command failed\n");
+ goto out_rel_fw;
+ }
+ kfree_skb(skb);
+ break;
+ case ACTION_WAIT_EVENT: /* wait */
+ /* no need to wait as command was synchronous */
+ bt_dev_dbg(lldev->hu.hdev, "W");
+ break;
+ case ACTION_DELAY: /* sleep */
+ bt_dev_info(lldev->hu.hdev, "sleep command in scr");
+ mdelay(((struct bts_action_delay *)action_ptr)->msec);
+ break;
+ }
+ len -= (sizeof(struct bts_action) +
+ ((struct bts_action *)ptr)->size);
+ ptr += sizeof(struct bts_action) +
+ ((struct bts_action *)ptr)->size;
+ }
+
+out_rel_fw:
+ /* fw download complete */
+ release_firmware(fw);
+ return err;
+}
+
+static int ll_setup(struct hci_uart *hu)
+{
+ int err, retry = 3;
+ struct ll_device *lldev;
+ struct serdev_device *serdev = hu->serdev;
+ u32 speed;
+
+ if (!serdev)
+ return 0;
+
+ lldev = serdev_device_get_drvdata(serdev);
+
+ serdev_device_set_flow_control(serdev, true);
+
+ do {
+ /* Configure BT_EN to HIGH state */
+ gpiod_set_value_cansleep(lldev->enable_gpio, 0);
+ msleep(5);
+ gpiod_set_value_cansleep(lldev->enable_gpio, 1);
+ msleep(100);
+
+ err = download_firmware(lldev);
+ if (!err)
+ break;
+
+ /* Toggle BT_EN and retry */
+ bt_dev_err(hu->hdev, "download firmware failed, retrying...");
+ } while (retry--);
+
+ if (err)
+ return err;
+
+ /* Operational speed if any */
+ if (hu->oper_speed)
+ speed = hu->oper_speed;
+ else if (hu->proto->oper_speed)
+ speed = hu->proto->oper_speed;
+ else
+ speed = 0;
+
+ if (speed) {
+ struct sk_buff *skb = __hci_cmd_sync(hu->hdev, 0xff36, sizeof(speed), &speed, HCI_INIT_TIMEOUT);
+ if (!IS_ERR(skb)) {
+ kfree_skb(skb);
+ serdev_device_set_baudrate(serdev, speed);
+ }
+ }
+
+ return 0;
+}
+
+static const struct hci_uart_proto llp;
+
+static int hci_ti_probe(struct serdev_device *serdev)
+{
+ struct hci_uart *hu;
+ struct ll_device *lldev;
+ u32 max_speed = 3000000;
+
+ lldev = devm_kzalloc(&serdev->dev, sizeof(struct ll_device), GFP_KERNEL);
+ if (!lldev)
+ return -ENOMEM;
+ hu = &lldev->hu;
+
+ serdev_device_set_drvdata(serdev, lldev);
+ lldev->serdev = hu->serdev = serdev;
+
+ lldev->enable_gpio = devm_gpiod_get_optional(&serdev->dev, "enable", GPIOD_OUT_LOW);
+ if (IS_ERR(lldev->enable_gpio))
+ return PTR_ERR(lldev->enable_gpio);
+
+ of_property_read_u32(serdev->dev.of_node, "max-speed", &max_speed);
+ hci_uart_set_speeds(hu, 115200, max_speed);
+
+ return hci_uart_register_device(hu, &llp);
+}
+
+static void hci_ti_remove(struct serdev_device *serdev)
+{
+ struct ll_device *lldev = serdev_device_get_drvdata(serdev);
+ struct hci_uart *hu = &lldev->hu;
+ struct hci_dev *hdev = hu->hdev;
+
+ cancel_work_sync(&hu->write_work);
+
+ hci_unregister_dev(hdev);
+ hci_free_dev(hdev);
+ hu->proto->close(hu);
+}
+
+static const struct of_device_id hci_ti_of_match[] = {
+ { .compatible = "ti,wl1831-st" },
+ { .compatible = "ti,wl1835-st" },
+ { .compatible = "ti,wl1837-st" },
+ {},
+};
+MODULE_DEVICE_TABLE(of, hci_ti_of_match);
+
+static struct serdev_device_driver hci_ti_drv = {
+ .driver = {
+ .name = "hci-ti",
+ .of_match_table = of_match_ptr(hci_ti_of_match),
+ },
+ .probe = hci_ti_probe,
+ .remove = hci_ti_remove,
+};
+#else
+#define ll_setup NULL
+#endif
+
static const struct hci_uart_proto llp = {
.id = HCI_UART_LL,
.name = "LL",
+ .setup = ll_setup,
.open = ll_open,
.close = ll_close,
.recv = ll_recv,
@@ -518,10 +774,14 @@ static const struct hci_uart_proto llp = {
int __init ll_init(void)
{
+ serdev_device_driver_register(&hci_ti_drv);
+
return hci_uart_register_proto(&llp);
}
int __exit ll_deinit(void)
{
+ serdev_device_driver_unregister(&hci_ti_drv);
+
return hci_uart_unregister_proto(&llp);
}
--
2.11.0
^ permalink raw reply related
* [PATCH v3 4/4] arm64: dts: hikey: add WL1835 Bluetooth device node
From: Rob Herring @ 2017-04-13 15:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170413150353.7389-1-robh@kernel.org>
This adds the serial slave device for the WL1835 Bluetooth interface.
Signed-off-by: Rob Herring <robh@kernel.org>
Cc: Wei Xu <xuwei5@hisilicon.com>
Cc: Mark Rutland <mark.rutland@arm.com>
---
v3:
- rebase on bluetooth-next
arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
index dba3c131c62c..9b4ba7169210 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
+++ b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
@@ -98,6 +98,11 @@
assigned-clocks = <&sys_ctrl HI6220_UART1_SRC>;
assigned-clock-rates = <150000000>;
status = "ok";
+
+ bluetooth {
+ compatible = "ti,wl1835-st";
+ enable-gpios = <&gpio1 7 GPIO_ACTIVE_HIGH>;
+ };
};
uart2: uart at f7112000 {
--
2.11.0
^ permalink raw reply related
* [PATCHv3 13/14] arm64: pmuv3: handle !PMUv3 when probing
From: Mark Rutland @ 2017-04-13 15:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CA+7sy7AA+SX_YUNAgCL5tyBXGW+rUidaApN7D2g3O0maRNcKSw@mail.gmail.com>
Hi,
On Thu, Apr 13, 2017 at 07:36:45PM +0530, Jayachandran C. wrote:
> On Tue, Apr 11, 2017 at 2:09 PM, Mark Rutland <mark.rutland@arm.com> wrote:
> > When probing via ACPI, we won't know up-front whether a CPU has a PMUv3
> > compatible PMU. Thus we need to consult ID registers during probe time.
> >
> > This patch updates our PMUv3 probing code to test for the presence of
> > PMUv3 functionality before touching an PMUv3-specific registers, and
> > before updating the struct arm_pmu with PMUv3 data.
[..]
> > + dfr0 = read_sysreg(id_aa64dfr0_el1);
> > + pmuver = cpuid_feature_extract_unsigned_field(dfr0,
> > + ID_AA64DFR0_PMUVER_SHIFT);
> > + if (pmuver != 1)
> > + return;
>
> There is a problem here, the 8.1 spec allows PMUver value 4 for PMUv3
> "Performance Monitors extension System registers implemented, PMUv3,
> with a 16-bit evtCount field, and if EL2 is implemented, the addition
> of the MDCR_EL2.HPMD bit"
>
> On Broadcom Vulcan/Cavium ThunderX2 the value of PMUver is 4 and this
> breaks (even the working DT case if I am not mistaken).
Good point; sorry about this.
Annoyingly, ID_AA64DFR0.PMUVer is a bit weird, and doesn't seem to
strictly follow the rules laid out in ARM DDI 0487B.a, D7.1.4,
"Principles of the ID scheme for fields in ID registers".
Since both 0b0000 and 0b1111 mean that PMUv3 isn't implemented, I don't
know if it should be treated as unsigned with 0xf being special-cased,
or if it should be treated as signed with 0b001 being the minimal
version we expect.
i.e. it's not clear to me if we should do:
dfr0 = read_sysreg(id_aa64dfr0_el1);
pmuver = cpuid_feature_extract_unsigned_field(dfr0,
id_aa64dfr0_pmuver_shift);
if (pmuver < 1 || pmuver == 0xf)
return;
... or:
dfr0 = read_sysreg(id_aa64dfr0_el1);
pmuver = cpuid_feature_extract_signed_field(dfr0,
id_aa64dfr0_pmuver_shift);
if (pmuver < 1)
return;
I'll try to get that clarified ASAP.
Thanks,
Mark.
^ permalink raw reply
* kvm/arm64: use-after-free in kvm_unmap_hva_handler/unmap_stage2_pmds
From: Suzuki K. Poulose @ 2017-04-13 15:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <88715300-ef58-e7bd-81f5-95e0b9c9c533@arm.com>
On Thu, Apr 13, 2017 at 10:17:54AM +0100, Suzuki K Poulose wrote:
> On 12/04/17 19:43, Marc Zyngier wrote:
> > On 12/04/17 17:19, Andrey Konovalov wrote:
> >
> > Hi Andrey,
> >
> > > Apparently this wasn't fixed, I've got this report again on
> > > linux-next-c4e7b35a3 (Apr 11), which includes 8b3405e34 "kvm:
> > > arm/arm64: Fix locking for kvm_free_stage2_pgd".
> >
> > This looks like a different bug.
> >
> > >
> > > I now have a way to reproduce it, so I can test proposed patches. I
> > > don't have a simple C reproducer though.
> > >
> > > The bug happens when the following syzkaller program is executed:
> > >
> > > mmap(&(0x7f0000000000/0xc000)=nil, (0xc000), 0x3, 0x32, 0xffffffffffffffff, 0x0)
> > > unshare(0x400)
> > > perf_event_open(&(0x7f000002f000-0x78)={0x1, 0x78, 0x0, 0x0, 0x0, 0x0,
> > > 0x0, 0x6, 0x0, 0x0, 0xd34, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
> > > 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, 0x0, 0xffffffff,
> > > 0xffffffffffffffff, 0x0)
> > > r0 = openat$kvm(0xffffffffffffff9c,
> > > &(0x7f000000c000-0x9)="2f6465762f6b766d00", 0x0, 0x0)
> > > ioctl$TIOCSBRK(0xffffffffffffffff, 0x5427)
> > > r1 = ioctl$KVM_CREATE_VM(r0, 0xae01, 0x0)
> > > syz_kvm_setup_cpu$arm64(r1, 0xffffffffffffffff,
> > > &(0x7f0000dc6000/0x18000)=nil, &(0x7f000000c000)=[{0x0,
> > > &(0x7f000000c000)="5ba3c16f533efbed09f8221253c73763327fadce2371813b45dd7f7982f84a873e4ae89a6c2bd1af83a6024c36a1ff518318",
> > > 0x32}], 0x1, 0x0, &(0x7f000000d000-0x10)=[@featur2={0x1, 0x3}], 0x1)
> >
> > Is that the only thing the program does? Or is there anything running in
> > parallel?
> >
> > > ==================================================================
> > > BUG: KASAN: use-after-free in arch_spin_is_locked
> > > include/linux/compiler.h:254 [inline]
> > > BUG: KASAN: use-after-free in unmap_stage2_range+0x990/0x9a8
> > > arch/arm64/kvm/../../../arch/arm/kvm/mmu.c:295
> > > Read of size 8 at addr ffff800004476730 by task syz-executor/13106
> > >
> > > CPU: 1 PID: 13106 Comm: syz-executor Not tainted
> > > 4.11.0-rc6-next-20170411-xc2-11025-gc4e7b35a33d4-dirty #5
> > > Hardware name: Hardkernel ODROID-C2 (DT)
> > > Call trace:
> > > [<ffff20000808fd08>] dump_backtrace+0x0/0x440 arch/arm64/kernel/traps.c:505
> > > [<ffff2000080903c0>] show_stack+0x20/0x30 arch/arm64/kernel/traps.c:228
> > > [<ffff2000088df030>] __dump_stack lib/dump_stack.c:16 [inline]
> > > [<ffff2000088df030>] dump_stack+0x110/0x168 lib/dump_stack.c:52
> > > [<ffff200008406db8>] print_address_description+0x60/0x248 mm/kasan/report.c:252
> > > [<ffff2000084072c8>] kasan_report_error mm/kasan/report.c:351 [inline]
> > > [<ffff2000084072c8>] kasan_report+0x218/0x300 mm/kasan/report.c:408
> > > [<ffff200008407428>] __asan_report_load8_noabort+0x18/0x20 mm/kasan/report.c:429
> > > [<ffff2000080db1b8>] arch_spin_is_locked include/linux/compiler.h:254 [inline]
> >
> > This is the assert on the spinlock, and the memory is gone.
> >
> > > [<ffff2000080db1b8>] unmap_stage2_range+0x990/0x9a8
> > > arch/arm64/kvm/../../../arch/arm/kvm/mmu.c:295
> > > [<ffff2000080db248>] kvm_free_stage2_pgd.part.16+0x30/0x98
> > > arch/arm64/kvm/../../../arch/arm/kvm/mmu.c:842
> > > [<ffff2000080ddfb8>] kvm_free_stage2_pgd
> > > arch/arm64/kvm/../../../arch/arm/kvm/mmu.c:838 [inline]
> >
> > But we've taken than lock here. There's only a handful of instructions
> > in between, and the memory can only go away if there is something
> > messing with us in parallel.
> >
> > > [<ffff2000080ddfb8>] kvm_arch_flush_shadow_all+0x40/0x58
> > > arch/arm64/kvm/../../../arch/arm/kvm/mmu.c:1895
> > > [<ffff2000080c379c>] kvm_mmu_notifier_release+0x154/0x1d0
> > > arch/arm64/kvm/../../../virt/kvm/kvm_main.c:472
> > > [<ffff2000083f2b60>] __mmu_notifier_release+0x1c0/0x3e0 mm/mmu_notifier.c:75
> > > [<ffff2000083a1fb4>] mmu_notifier_release
> > > include/linux/mmu_notifier.h:235 [inline]
> > > [<ffff2000083a1fb4>] exit_mmap+0x21c/0x288 mm/mmap.c:2941
> > > [<ffff20000810ecd4>] __mmput kernel/fork.c:888 [inline]
> > > [<ffff20000810ecd4>] mmput+0xdc/0x2e0 kernel/fork.c:910
> > > [<ffff20000811fda8>] exit_mm kernel/exit.c:557 [inline]
> > > [<ffff20000811fda8>] do_exit+0x648/0x2020 kernel/exit.c:865
> > > [<ffff2000081218b4>] do_group_exit+0xdc/0x260 kernel/exit.c:982
> > > [<ffff20000813adf0>] get_signal+0x358/0xf58 kernel/signal.c:2318
> > > [<ffff20000808de98>] do_signal+0x170/0xc10 arch/arm64/kernel/signal.c:370
> > > [<ffff20000808edb4>] do_notify_resume+0xe4/0x120 arch/arm64/kernel/signal.c:421
> > > [<ffff200008083e68>] work_pending+0x8/0x14
> >
> > So we're being serviced with a signal. Do you know if this signal is
> > generated by your syzkaller program? We could be racing between do_exit
> > triggered by a fatal signal (this trace) and the closing of the two file
> > descriptors (vcpu and vm).
> >
> > Paolo: does this look possible to you? I can't see what locking we have
> > that could prevent this race.
>
> On a quick look, I see two issues:
>
> 1) It looks like the mmu_notifier->ops.release could be called twice for a notifier,
> from mmu_notifier_unregister() and exit_mmap()->mmu_notifier_release(), which is
> causing the problem as above.
>
> This could possibly be avoided by swapping the order of the following operations
> in themmu_notifier_unregister():
>
> a) Invoke ops->release under src_read_lock()
> b) Delete the notifier from the list.
>
> which can prevent mmu_notifier_release() calling the ops->release() again, before
> we reach (b).
>
>
> 2) The core KVM code does an mmgrab()/mmdrop on the current->mm to pin the mm_struct. But
> this doesn't prevent the "real_address user space" from being destroyed. Since KVM
> actually depends on the user pages and page tables, it should really/also(?) use
> mmget()/mmput() (See Documentation/vm/active_mm.txt). I understand that mmget() shouldn't
> be used for pinning unbounded amount of time. But since we do it from within the same
> process context (like say threads), we should be safe to do so.
Here is a patch which implements (2) above.
----8>-----
kvm: Hold reference to the user address space
The core KVM code, uses mmgrab/mmdrop to pin the mm struct of the user
application. mmgrab only guarantees that the mm struct is available,
while the "real address space" (see Documentation/vm/active_mm.txt) may
be destroyed. Since the KVM depends on the user space page tables for
the Guest pages, we should instead do an mmget/mmput. Even though
mmget/mmput is not encouraged for uses with unbounded time, the KVM
is fine to do so, as we are doing it from the context of the same process.
This also prevents the race condition where mmu_notifier_release() could
be called in parallel and one instance could end up using a free'd kvm
instance.
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Paolo Bonzin <pbonzini@redhat.com>
Cc: Radim Kr?m?? <rkrcmar@redhat.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Christoffer Dall <christoffer.dall@linaro.org>
Cc: andreyknvl at google.com
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
---
virt/kvm/kvm_main.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 88257b3..555712e 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -613,7 +613,7 @@ static struct kvm *kvm_create_vm(unsigned long type)
return ERR_PTR(-ENOMEM);
spin_lock_init(&kvm->mmu_lock);
- mmgrab(current->mm);
+ mmget(current->mm);
kvm->mm = current->mm;
kvm_eventfd_init(kvm);
mutex_init(&kvm->lock);
@@ -685,7 +685,7 @@ static struct kvm *kvm_create_vm(unsigned long type)
for (i = 0; i < KVM_ADDRESS_SPACE_NUM; i++)
kvm_free_memslots(kvm, kvm->memslots[i]);
kvm_arch_free_vm(kvm);
- mmdrop(current->mm);
+ mmput(current->mm);
return ERR_PTR(r);
}
@@ -747,7 +747,7 @@ static void kvm_destroy_vm(struct kvm *kvm)
kvm_arch_free_vm(kvm);
preempt_notifier_dec();
hardware_disable_all();
- mmdrop(mm);
+ mmput(mm);
}
void kvm_get_kvm(struct kvm *kvm)
--
2.7.4
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
^ permalink raw reply related
* kvm/arm64: use-after-free in kvm_unmap_hva_handler/unmap_stage2_pmds
From: Suzuki K Poulose @ 2017-04-13 15:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170413155045.GA8387@e107814-lin.cambridge.arm.com>
On 13/04/17 16:50, Suzuki K. Poulose wrote:
> On Thu, Apr 13, 2017 at 10:17:54AM +0100, Suzuki K Poulose wrote:
>> On 12/04/17 19:43, Marc Zyngier wrote:
>>> On 12/04/17 17:19, Andrey Konovalov wrote:
Please ignore the footer below, that was mistake from my side.
> --
> 2.7.4
> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
>
^ permalink raw reply
* [GIT PULL] ARM: mvebu: defconfig64 for v4.12 (#2)
From: Gregory CLEMENT @ 2017-04-13 16:25 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
Here is the second pull request for defconfig64 for mvebu for v4.12.
There is a trivial merge conflict already solved by Stephen Rothwell
there:
http://lists.infradead.org/pipermail/linux-arm-kernel/2017-April/500998.html
Gregory
The following changes since commit 66e56302842e9971426bd7e504c4db4f88cbb037:
arm64: defconfig: enable MVPP2 (2017-03-23 17:50:13 +0100)
are available in the git repository at:
git://git.infradead.org/linux-mvebu.git tags/mvebu-defconfig64-4.12-2
for you to fetch changes up to 10ebb57ffcbf062ff224585fefa274e703fc363d:
arm64: defconfig: enable the Safexcel crypto engine as a module (2017-04-12 15:35:16 +0200)
----------------------------------------------------------------
mvebu defconfig64 for 4.12 (part 2)
Select two new drivers for ARM64 mvebu SoCs:
- Xenon SDHCI controller on Armada 37xx and Armada 7K/8K
- Safexcel crypto engine on Armada 7K/8K
----------------------------------------------------------------
Antoine Tenart (1):
arm64: defconfig: enable the Safexcel crypto engine as a module
Gregory CLEMENT (1):
arm64: configs: enable SDHCI driver for Xenon
arch/arm64/configs/defconfig | 2 ++
1 file changed, 2 insertions(+)
^ permalink raw reply
* [GIT PULL] ARM: mvebu: dt for v4.12 (#3)
From: Gregory CLEMENT @ 2017-04-13 16:25 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
Here is the third pull request for dt for mvebu for v4.12.
Gregory
The following changes since commit 34240c26d1d7b4365d4d0a8d231b244eb396c8dc:
ARM: dts: armada-385-linksys: disk-activity trigger for all (2017-04-05 17:25:17 +0200)
are available in the git repository at:
git://git.infradead.org/linux-mvebu.git tags/mvebu-dt-4.12-3
for you to fetch changes up to f3d1f7597ec1f91b7ab495cb0914677f84debfe8:
ARM: dts: armada-38x: label USB and SATA nodes (2017-04-12 11:01:29 +0200)
----------------------------------------------------------------
mvebu dt for 4.12 (part 3)
Use label for USB and SATA nodes on Armada 38x
----------------------------------------------------------------
Ralph Sennhauser (1):
ARM: dts: armada-38x: label USB and SATA nodes
arch/arm/boot/dts/armada-38x.dtsi | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
^ permalink raw reply
* [GIT PULL] ARM: mvebu: dt64 for v4.12 (#2)
From: Gregory CLEMENT @ 2017-04-13 16:26 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
Here is the second pull request for dt64 for mvebu for v4.12.
Gregory
The following changes since commit 60894719241e2b3d6d202304de9ad33a8da3685c:
arm64: marvell: dts: add PPv2.2 description to Armada 7K/8K (2017-03-23 17:46:23 +0100)
are available in the git repository at:
git://git.infradead.org/linux-mvebu.git tags/mvebu-dt64-4.12-2
for you to fetch changes up to 7ba2ef7c7200e476ee2cede7bcffcf7749e02f5c:
arm64: marvell: dts: enable the crypto engine on the Armada 8040 DB (2017-04-12 10:36:30 +0200)
----------------------------------------------------------------
mvebu dt64 for 4.12 (part 2)
- crypto engine description for the Armada 7k/8k SoCs and the boards
using it
- SDHCI description for the Armada 37xx and 7k/8k SoCs and the boards
using it
----------------------------------------------------------------
Antoine Tenart (3):
arm64: marvell: dts: add crypto engine description for 7k/8k
arm64: marvell: dts: enable the crypto engine on the Armada 7040 DB
arm64: marvell: dts: enable the crypto engine on the Armada 8040 DB
Gregory CLEMENT (2):
arm64: dts: marvell: add eMMC support for Armada 37xx
arm64: dts: marvell: add sdhci support for Armada 7K/8K
arch/arm64/boot/dts/marvell/armada-3720-db.dts | 9 ++++++++
arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 11 +++++++++
arch/arm64/boot/dts/marvell/armada-7040-db.dts | 18 +++++++++++++++
arch/arm64/boot/dts/marvell/armada-8040-db.dts | 16 +++++++++++++
arch/arm64/boot/dts/marvell/armada-ap806.dtsi | 11 +++++++++
.../boot/dts/marvell/armada-cp110-master.dtsi | 26 ++++++++++++++++++++++
.../arm64/boot/dts/marvell/armada-cp110-slave.dtsi | 16 +++++++++++++
7 files changed, 107 insertions(+)
^ permalink raw reply
* [PATCH v2] arm64: allwinner: h5: add support for Orange Pi Prime board
From: Icenowy Zheng @ 2017-04-13 16:38 UTC (permalink / raw)
To: linux-arm-kernel
Orange Pi Prime is a new Allwinner H5-based SBC by Xunlong.
It's like a Orange Pi Plus 2E with H3 replaced with H5, eMMC replaced
with onboard SPI NOR Flash and wireless card changed to Realtek
RTL8723BS (with Bluetooth functionality).
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
---
Changes since v1:
- Fixed copyright holder.
arch/arm64/boot/dts/allwinner/Makefile | 1 +
.../dts/allwinner/sun50i-h5-orangepi-prime.dts | 205 +++++++++++++++++++++
2 files changed, 206 insertions(+)
create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-prime.dts
diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/allwinner/Makefile
index 244e8b7565f9..92a84eea6b96 100644
--- a/arch/arm64/boot/dts/allwinner/Makefile
+++ b/arch/arm64/boot/dts/allwinner/Makefile
@@ -1,6 +1,7 @@
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-bananapi-m64.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pine64-plus.dtb sun50i-a64-pine64.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-orangepi-pc2.dtb
+dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-orangepi-prime.dtb
always := $(dtb-y)
subdir-y := $(dts-dirs)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-prime.dts b/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-prime.dts
new file mode 100644
index 000000000000..28d92a612329
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-prime.dts
@@ -0,0 +1,205 @@
+/*
+ * Copyright (C) 2017 Icenowy Zheng <icenowy@aosc.xyz>
+ *
+ * Based on sun50i-h5-orangepi-pc2.dts, which is:
+ * Copyright (C) 2016 ARM Ltd.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file 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.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "sun50i-h5.dtsi"
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+
+/ {
+ model = "Xunlong Orange Pi Prime";
+ compatible = "xunlong,orangepi-prime", "allwinner,sun50i-h5";
+
+ reg_vcc3v3: vcc3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc3v3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ aliases {
+ serial0 = &uart0;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ pwr {
+ label = "orangepi:green:pwr";
+ gpios = <&r_pio 0 10 GPIO_ACTIVE_HIGH>;
+ default-state = "on";
+ };
+
+ status {
+ label = "orangepi:red:status";
+ gpios = <&pio 0 20 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ r-gpio-keys {
+ compatible = "gpio-keys";
+
+ sw4 {
+ label = "sw4";
+ linux,code = <BTN_0>;
+ gpios = <&r_pio 0 3 GPIO_ACTIVE_LOW>;
+ };
+ };
+
+ reg_usb0_vbus: usb0-vbus {
+ compatible = "regulator-fixed";
+ regulator-name = "usb0-vbus";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ enable-active-high;
+ gpio = <&r_pio 0 2 GPIO_ACTIVE_HIGH>; /* PL2 */
+ status = "okay";
+ };
+
+ wifi_pwrseq: wifi_pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ reset-gpios = <&pio 2 14 GPIO_ACTIVE_LOW>; /* PC14 */
+ };
+};
+
+&codec {
+ allwinner,audio-routing =
+ "Line Out", "LINEOUT",
+ "MIC1", "Mic",
+ "Mic", "MBIAS";
+ status = "okay";
+};
+
+&ehci0 {
+ status = "okay";
+};
+
+&ehci1 {
+ status = "okay";
+};
+
+&ehci2 {
+ status = "okay";
+};
+
+&ehci3 {
+ status = "okay";
+};
+
+&ir {
+ pinctrl-names = "default";
+ pinctrl-0 = <&ir_pins_a>;
+ status = "okay";
+};
+
+&mmc0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin>;
+ vmmc-supply = <®_vcc3v3>;
+ bus-width = <4>;
+ cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
+ status = "okay";
+};
+
+&mmc1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc1_pins_a>;
+ vmmc-supply = <®_vcc3v3>;
+ mmc-pwrseq = <&wifi_pwrseq>;
+ bus-width = <4>;
+ non-removable;
+ status = "okay";
+};
+
+&ohci0 {
+ status = "okay";
+};
+
+&ohci1 {
+ status = "okay";
+};
+
+&ohci2 {
+ status = "okay";
+};
+
+&ohci3 {
+ status = "okay";
+};
+
+&uart0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0_pins_a>;
+ status = "okay";
+};
+
+&uart1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart1_pins>;
+ status = "disabled";
+};
+
+&uart2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart2_pins>;
+ status = "disabled";
+};
+
+&usb_otg {
+ dr_mode = "otg";
+ status = "okay";
+};
+
+&usbphy {
+ /* USB Type-A ports' VBUS is always on */
+ usb0_id_det-gpios = <&pio 0 21 GPIO_ACTIVE_HIGH>; /* PA21 */
+ usb0_vbus-supply = <®_usb0_vbus>;
+ status = "okay";
+};
--
2.12.2
^ permalink raw reply related
* kvm/arm64: use-after-free in kvm_unmap_hva_handler/unmap_stage2_pmds
From: Andrey Konovalov @ 2017-04-13 17:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170413155045.GA8387@e107814-lin.cambridge.arm.com>
On Thu, Apr 13, 2017 at 5:50 PM, Suzuki K. Poulose
<Suzuki.Poulose@arm.com> wrote:
> On Thu, Apr 13, 2017 at 10:17:54AM +0100, Suzuki K Poulose wrote:
>> On 12/04/17 19:43, Marc Zyngier wrote:
>> > On 12/04/17 17:19, Andrey Konovalov wrote:
>> >
>> > Hi Andrey,
>> >
>> > > Apparently this wasn't fixed, I've got this report again on
>> > > linux-next-c4e7b35a3 (Apr 11), which includes 8b3405e34 "kvm:
>> > > arm/arm64: Fix locking for kvm_free_stage2_pgd".
>> >
>> > This looks like a different bug.
>> >
>> > >
>> > > I now have a way to reproduce it, so I can test proposed patches. I
>> > > don't have a simple C reproducer though.
>> > >
>> > > The bug happens when the following syzkaller program is executed:
>> > >
>> > > mmap(&(0x7f0000000000/0xc000)=nil, (0xc000), 0x3, 0x32, 0xffffffffffffffff, 0x0)
>> > > unshare(0x400)
>> > > perf_event_open(&(0x7f000002f000-0x78)={0x1, 0x78, 0x0, 0x0, 0x0, 0x0,
>> > > 0x0, 0x6, 0x0, 0x0, 0xd34, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
>> > > 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, 0x0, 0xffffffff,
>> > > 0xffffffffffffffff, 0x0)
>> > > r0 = openat$kvm(0xffffffffffffff9c,
>> > > &(0x7f000000c000-0x9)="2f6465762f6b766d00", 0x0, 0x0)
>> > > ioctl$TIOCSBRK(0xffffffffffffffff, 0x5427)
>> > > r1 = ioctl$KVM_CREATE_VM(r0, 0xae01, 0x0)
>> > > syz_kvm_setup_cpu$arm64(r1, 0xffffffffffffffff,
>> > > &(0x7f0000dc6000/0x18000)=nil, &(0x7f000000c000)=[{0x0,
>> > > &(0x7f000000c000)="5ba3c16f533efbed09f8221253c73763327fadce2371813b45dd7f7982f84a873e4ae89a6c2bd1af83a6024c36a1ff518318",
>> > > 0x32}], 0x1, 0x0, &(0x7f000000d000-0x10)=[@featur2={0x1, 0x3}], 0x1)
>> >
>> > Is that the only thing the program does? Or is there anything running in
>> > parallel?
>> >
>> > > ==================================================================
>> > > BUG: KASAN: use-after-free in arch_spin_is_locked
>> > > include/linux/compiler.h:254 [inline]
>> > > BUG: KASAN: use-after-free in unmap_stage2_range+0x990/0x9a8
>> > > arch/arm64/kvm/../../../arch/arm/kvm/mmu.c:295
>> > > Read of size 8 at addr ffff800004476730 by task syz-executor/13106
>> > >
>> > > CPU: 1 PID: 13106 Comm: syz-executor Not tainted
>> > > 4.11.0-rc6-next-20170411-xc2-11025-gc4e7b35a33d4-dirty #5
>> > > Hardware name: Hardkernel ODROID-C2 (DT)
>> > > Call trace:
>> > > [<ffff20000808fd08>] dump_backtrace+0x0/0x440 arch/arm64/kernel/traps.c:505
>> > > [<ffff2000080903c0>] show_stack+0x20/0x30 arch/arm64/kernel/traps.c:228
>> > > [<ffff2000088df030>] __dump_stack lib/dump_stack.c:16 [inline]
>> > > [<ffff2000088df030>] dump_stack+0x110/0x168 lib/dump_stack.c:52
>> > > [<ffff200008406db8>] print_address_description+0x60/0x248 mm/kasan/report.c:252
>> > > [<ffff2000084072c8>] kasan_report_error mm/kasan/report.c:351 [inline]
>> > > [<ffff2000084072c8>] kasan_report+0x218/0x300 mm/kasan/report.c:408
>> > > [<ffff200008407428>] __asan_report_load8_noabort+0x18/0x20 mm/kasan/report.c:429
>> > > [<ffff2000080db1b8>] arch_spin_is_locked include/linux/compiler.h:254 [inline]
>> >
>> > This is the assert on the spinlock, and the memory is gone.
>> >
>> > > [<ffff2000080db1b8>] unmap_stage2_range+0x990/0x9a8
>> > > arch/arm64/kvm/../../../arch/arm/kvm/mmu.c:295
>> > > [<ffff2000080db248>] kvm_free_stage2_pgd.part.16+0x30/0x98
>> > > arch/arm64/kvm/../../../arch/arm/kvm/mmu.c:842
>> > > [<ffff2000080ddfb8>] kvm_free_stage2_pgd
>> > > arch/arm64/kvm/../../../arch/arm/kvm/mmu.c:838 [inline]
>> >
>> > But we've taken than lock here. There's only a handful of instructions
>> > in between, and the memory can only go away if there is something
>> > messing with us in parallel.
>> >
>> > > [<ffff2000080ddfb8>] kvm_arch_flush_shadow_all+0x40/0x58
>> > > arch/arm64/kvm/../../../arch/arm/kvm/mmu.c:1895
>> > > [<ffff2000080c379c>] kvm_mmu_notifier_release+0x154/0x1d0
>> > > arch/arm64/kvm/../../../virt/kvm/kvm_main.c:472
>> > > [<ffff2000083f2b60>] __mmu_notifier_release+0x1c0/0x3e0 mm/mmu_notifier.c:75
>> > > [<ffff2000083a1fb4>] mmu_notifier_release
>> > > include/linux/mmu_notifier.h:235 [inline]
>> > > [<ffff2000083a1fb4>] exit_mmap+0x21c/0x288 mm/mmap.c:2941
>> > > [<ffff20000810ecd4>] __mmput kernel/fork.c:888 [inline]
>> > > [<ffff20000810ecd4>] mmput+0xdc/0x2e0 kernel/fork.c:910
>> > > [<ffff20000811fda8>] exit_mm kernel/exit.c:557 [inline]
>> > > [<ffff20000811fda8>] do_exit+0x648/0x2020 kernel/exit.c:865
>> > > [<ffff2000081218b4>] do_group_exit+0xdc/0x260 kernel/exit.c:982
>> > > [<ffff20000813adf0>] get_signal+0x358/0xf58 kernel/signal.c:2318
>> > > [<ffff20000808de98>] do_signal+0x170/0xc10 arch/arm64/kernel/signal.c:370
>> > > [<ffff20000808edb4>] do_notify_resume+0xe4/0x120 arch/arm64/kernel/signal.c:421
>> > > [<ffff200008083e68>] work_pending+0x8/0x14
>> >
>> > So we're being serviced with a signal. Do you know if this signal is
>> > generated by your syzkaller program? We could be racing between do_exit
>> > triggered by a fatal signal (this trace) and the closing of the two file
>> > descriptors (vcpu and vm).
>> >
>> > Paolo: does this look possible to you? I can't see what locking we have
>> > that could prevent this race.
>>
>> On a quick look, I see two issues:
>>
>> 1) It looks like the mmu_notifier->ops.release could be called twice for a notifier,
>> from mmu_notifier_unregister() and exit_mmap()->mmu_notifier_release(), which is
>> causing the problem as above.
>>
>> This could possibly be avoided by swapping the order of the following operations
>> in themmu_notifier_unregister():
>>
>> a) Invoke ops->release under src_read_lock()
>> b) Delete the notifier from the list.
>>
>> which can prevent mmu_notifier_release() calling the ops->release() again, before
>> we reach (b).
>>
>>
>> 2) The core KVM code does an mmgrab()/mmdrop on the current->mm to pin the mm_struct. But
>> this doesn't prevent the "real_address user space" from being destroyed. Since KVM
>> actually depends on the user pages and page tables, it should really/also(?) use
>> mmget()/mmput() (See Documentation/vm/active_mm.txt). I understand that mmget() shouldn't
>> be used for pinning unbounded amount of time. But since we do it from within the same
>> process context (like say threads), we should be safe to do so.
>
> Here is a patch which implements (2) above.
Hi Suzuki,
Your patch fixes KASAN reports for me.
Thanks!
>
> ----8>-----
>
> kvm: Hold reference to the user address space
>
> The core KVM code, uses mmgrab/mmdrop to pin the mm struct of the user
> application. mmgrab only guarantees that the mm struct is available,
> while the "real address space" (see Documentation/vm/active_mm.txt) may
> be destroyed. Since the KVM depends on the user space page tables for
> the Guest pages, we should instead do an mmget/mmput. Even though
> mmget/mmput is not encouraged for uses with unbounded time, the KVM
> is fine to do so, as we are doing it from the context of the same process.
>
> This also prevents the race condition where mmu_notifier_release() could
> be called in parallel and one instance could end up using a free'd kvm
> instance.
>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Paolo Bonzin <pbonzini@redhat.com>
> Cc: Radim Kr?m?? <rkrcmar@redhat.com>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> Cc: Christoffer Dall <christoffer.dall@linaro.org>
> Cc: andreyknvl at google.com
> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> ---
> virt/kvm/kvm_main.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index 88257b3..555712e 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -613,7 +613,7 @@ static struct kvm *kvm_create_vm(unsigned long type)
> return ERR_PTR(-ENOMEM);
>
> spin_lock_init(&kvm->mmu_lock);
> - mmgrab(current->mm);
> + mmget(current->mm);
> kvm->mm = current->mm;
> kvm_eventfd_init(kvm);
> mutex_init(&kvm->lock);
> @@ -685,7 +685,7 @@ static struct kvm *kvm_create_vm(unsigned long type)
> for (i = 0; i < KVM_ADDRESS_SPACE_NUM; i++)
> kvm_free_memslots(kvm, kvm->memslots[i]);
> kvm_arch_free_vm(kvm);
> - mmdrop(current->mm);
> + mmput(current->mm);
> return ERR_PTR(r);
> }
>
> @@ -747,7 +747,7 @@ static void kvm_destroy_vm(struct kvm *kvm)
> kvm_arch_free_vm(kvm);
> preempt_notifier_dec();
> hardware_disable_all();
> - mmdrop(mm);
> + mmput(mm);
> }
>
> void kvm_get_kvm(struct kvm *kvm)
> --
> 2.7.4
> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
^ permalink raw reply
* [PATCH v3 0/4] TI Bluetooth serdev support
From: Marcel Holtmann @ 2017-04-13 17:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170413150353.7389-1-robh@kernel.org>
Hi Rob,
> This series adds serdev support to the HCI LL protocol used on TI BT
> modules and enables support on HiKey board with with the WL1835 module.
> With this the custom TI UIM daemon and btattach are no longer needed.
>
> The series is available on this git branch[1]. This version is rebased on
> bluetooth-next tree containing its dependencies.
>
> Rob
>
> [1] git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git ti-bluetooth
>
> Rob Herring (4):
> dt-bindings: net: Add TI WiLink shared transport binding
> bluetooth: hci_uart: remove unused hci_uart_init_tty
> bluetooth: hci_uart: add LL protocol serdev driver support
> arm64: dts: hikey: add WL1835 Bluetooth device node
>
> .../devicetree/bindings/net/ti,wilink-st.txt | 35 +++
> arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts | 5 +
> drivers/bluetooth/hci_ldisc.c | 19 --
> drivers/bluetooth/hci_ll.c | 262 ++++++++++++++++++++-
> drivers/bluetooth/hci_uart.h | 1 -
> 5 files changed, 301 insertions(+), 21 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/net/ti,wilink-st.txt
all 4 patches have been applied to bluetooth-next tree.
Regards
Marcel
^ permalink raw reply
* [Bug] VCHIQ functional test broken
From: Stefan Wahren @ 2017-04-13 17:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <331235003.222371.1491934205807@email.1und1.de>
> Stefan Wahren <stefan.wahren@i2se.com> hat am 11. April 2017 um 20:10 geschrieben:
>
>
> Hi,
>
> recently i found that vchiq_test -f doesn't work anymore with current mainline (4.11-rc6) and linux-next (20170404) on my Raspberry Pi Zero. The issue is always reproducible, but the error behavior isn't deterministic. Sometimes vchiq_test hangs and sometimes i get an error message from vchiq_test like this (but never errors from the kernel):
>
> $ vchiq_test -f 10
> Functional test - iters:10
> ======== iteration 1 ========
> vchiq_test: 1502: expected callback reason VCHIQ_MESSAGE_AVAILABLE, got 1
> vchiq_test: 1524: expected callback reason VCHIQ_BULK_TRANSMIT_DONE, got 5
> vchiq_test: 863: func_error != 0
>
> I didn't had the time to bisect, but at least 4.10 is safe.
>
Okay, i've bisected this regression to this commit:
00a19f3e25c0c40e0ec77f52d4841d23ad269169 is the first bad commit
commit 00a19f3e25c0c40e0ec77f52d4841d23ad269169
Author: Rabin Vincent <rabinv@axis.com>
Date: Tue Nov 8 09:21:19 2016 +0100
ARM: 8627/1: avoid cache flushing in flush_dcache_page()
When the data cache is PIPT or VIPT non-aliasing, and cache operations
are broadcast by the hardware, we can always postpone the flush in
flush_dcache_page(). A similar change was done for ARM64 in commit
b5b6c9e9149d ("arm64: Avoid cache flushing in flush_dcache_page()").
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Rabin Vincent <rabinv@axis.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
It seems that staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm relies on the behavior of flush_dcache_page before this patch get applied. Any advices to fix this issues are appreciated.
Regards
Stefan
^ permalink raw reply
* "Consolidate get_dma_ops" breaks Xen on ARM
From: Stefano Stabellini @ 2017-04-13 18:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <47808787-8067-ccc0-0ec6-de5e0d7597c8@arm.com>
On Thu, 13 Apr 2017, Julien Grall wrote:
> Hi Stefano,
>
> Sorry for the late answer.
>
> On 12/04/17 00:39, Stefano Stabellini wrote:
> > On Tue, 11 Apr 2017, Catalin Marinas wrote:
> > > On Tue, Apr 11, 2017 at 01:43:28PM +0100, Julien Grall wrote:
> > > > On 11/04/17 02:14, Bart Van Assche wrote:
> > > > > On 04/10/17 17:31, Stefano Stabellini wrote:
> > > > > > I think the reason is that, as you can see, if (dev &&
> > > > > > dev->dma_ops),
> > > > > > dev->dma_ops is returned, while before this changes, xen_dma_ops was
> > > > > > returned on Xen on ARM.
> > > > > >
> > > > > > Unfortunately DMA cannot work properly without using the appropriate
> > > > > > xen_dma_ops. See drivers/xen/swiotlb-xen.c and arch/arm/xen/mm.c for
> > > > > > more details. (The problem is easy to spot, but I wasn't CC'ed on
> > > > > > the
> > > > > > patch.)
> > > > > >
> > > > > > I don't know how to solve this problem without introducing some sort
> > > > > > of
> > > > > > if (xen()) in include/linux/dma-mapping.h.
> > > > >
> > > > > Sorry but I don't have access to an ARM development system. Does your
> > > > > comment apply to dev == NULL only, dev != NULL only or perhaps to
> > > > > both?
> > > > > If your comment applies to dev != NULL only, can you check whether
> > > > > adding something like set_dma_ops(dev, get_arch_dma_ops(NULL)) to the
> > > > > appropriate ARM arch_setup_dma_ops() function is sufficient?
> > > >
> > > > If I understand correctly, set_dma_ops will replace dev->dma_ops with
> > > > Xen DMA ops.
> > > >
> > > > However, Xen DMA ops will need in some places to call the device
> > > > specific DMA ops (see __generic_dma_ops(...)). So I think replacing
> > > > dev->dma_ops is not a solution here.
> > > >
> > > > The hackish patch below is fixing the problem for both ARM64 and ARM32.
> > > >
> > > > diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
> > > > index 0977317c6835..43a73ddeec7a 100644
> > > > --- a/include/linux/dma-mapping.h
> > > > +++ b/include/linux/dma-mapping.h
> > > > @@ -174,6 +174,8 @@ int dma_mmap_from_coherent(struct device *dev,
> > > > struct vm_area_struct *vma,
> > > > #include <asm/dma-mapping.h>
> > > > static inline const struct dma_map_ops *get_dma_ops(struct device *dev)
> > > > {
> > > > + if (xen_initial_domain())
> > > > + return xen_dma_ops;
> > > > if (dev && dev->dma_ops)
> > > > return dev->dma_ops;
> > > > return get_arch_dma_ops(dev ? dev->bus : NULL);
> > >
> > > If we do this, I guess there is no need to check for
> > > xen_initial_domain() in the get_arch_dma_ops() function. Anyway, this
> > > hunk would break the other architectures since xen_dma_ops is only
> > > defined for arm and arm64.
> > >
> > > > It is not nice as this is common code, but I can't find a better
> > > > solution
> > > > so far. Any opinions?
> > >
> > > A different hack would be to avoid the generic get_dma_ops
> > > implementation on arm with some #ifdef hacks above.
> > >
> > > Yet another way would be for dom0 to always set dev->dma_ops to
> > > xen_dma_ops and preserve the real dma_ops somewhere under dev->archdata.
> > > You could intercept the arch_setup_dma_ops() function for this or use
> > > bus_register_notifier() (though I think the former is easier). The Xen
> > > code making use of the real dma_ops would have to dig them out from
> > > dev->archdata.
> >
> > This is a good suggestion, Catalin. Thank you. See below. Is that what
> > you have in mind? Julien could you test it, please? If it is the right
> > approach, I'll submit the patch properly and rename __generic_dma_ops to
> > xen_generic_dma_ops or something.
>
> This patch is fixing the bug I encountered.
I'll add your tested-by.
^ permalink raw reply
* [PATCH 3/3] arm64/locking: qspinlocks and qrwlocks support
From: Peter Zijlstra @ 2017-04-13 18:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1491860104-4103-4-git-send-email-ynorov@caviumnetworks.com>
On Tue, Apr 11, 2017 at 01:35:04AM +0400, Yury Norov wrote:
> +++ b/arch/arm64/include/asm/qspinlock.h
> @@ -0,0 +1,20 @@
> +#ifndef _ASM_ARM64_QSPINLOCK_H
> +#define _ASM_ARM64_QSPINLOCK_H
> +
> +#include <asm-generic/qspinlock_types.h>
> +
> +#define queued_spin_unlock queued_spin_unlock
> +/**
> + * queued_spin_unlock - release a queued spinlock
> + * @lock : Pointer to queued spinlock structure
> + *
> + * A smp_store_release() on the least-significant byte.
> + */
> +static inline void queued_spin_unlock(struct qspinlock *lock)
> +{
> + smp_store_release((u8 *)lock, 0);
> +}
I'm afraid this isn't enough for arm64. I suspect you want your own
variant of queued_spin_unlock_wait() and queued_spin_is_locked() as
well.
Much memory ordering fun to be had there.
^ permalink raw reply
* [PATCH V8 2/5] PCI/ASPM: split pci_aspm_init() into two
From: Bjorn Helgaas @ 2017-04-13 18:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACK8Z6EfUTDjCM=fmdHfWeu8UV5GN+i6PX9fKkR1H8K90TXozg@mail.gmail.com>
On Wed, Apr 12, 2017 at 2:16 PM, Rajat Jain <rajatja@google.com> wrote:
> On Fri, Apr 7, 2017 at 9:55 PM, Sinan Kaya <okaya@codeaurora.org> wrote:
>> Split pci_aspm_init() body into pci_aspm_init_upstream()
>> and pci_aspm_init_downstream() for bridge and endpoint
>> specific code behavior.
>>
>> Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=194895
>> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
>> ---
>> drivers/pci/pcie/aspm.c | 15 ++++++++++++++-
>> 1 file changed, 14 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/pci/pcie/aspm.c b/drivers/pci/pcie/aspm.c
>> index dc36717..a80d64b 100644
>> --- a/drivers/pci/pcie/aspm.c
>> +++ b/drivers/pci/pcie/aspm.c
>> @@ -826,6 +826,16 @@ static struct pcie_link_state *alloc_pcie_link_state(struct pci_dev *pdev)
>> return link;
>> }
>>
>> +static int pci_aspm_init_downstream(struct pci_dev *pdev)
>> +{
>> + return 0;
>> +}
>> +
>> +static int pci_aspm_init_upstream(struct pci_dev *pdev)
>> +{
>> + return 0;
>> +}
>> +
>> /*
>> * pci_aspm_init: Initiate PCI express link state.
>> * It is called from device_add for every single pci device.
>> @@ -833,7 +843,10 @@ static struct pcie_link_state *alloc_pcie_link_state(struct pci_dev *pdev)
>> */
>> int pci_aspm_init(struct pci_dev *pdev)
>> {
>> - return 0;
>> + if (!pdev->has_secondary_link)
>> + return pci_aspm_init_downstream(pdev);
>> +
>> + return pci_aspm_init_upstream(pdev);
>> }
>
> Nit:
>
> if (x_flag())
> return x();
> return y();
>
> May be better than
>
> if (!x_flag)
> return y();
> return x();
I agree, and I made that change on my branch. I also renamed these to
pci_aspm_init_downstream_port() (for Root Ports and Switch Downstream
Ports) and pci_aspm_init_upstream_port() (for Switch Upstream Ports
and Endpoints) to try to match the terminology in the spec.
FWIW, your email didn't seem to make it to the list, Rajat. Maybe
some gmail weirdness? I don't *see* anything wrong, but ... I'm
responding via gmail, so my response probably won't make it to the
list either.
Bjorn
^ permalink raw reply
* [PATCH v2 00/22] eeprom: at24: Add OF device ID table
From: Javier Martinez Canillas @ 2017-04-13 18:28 UTC (permalink / raw)
To: linux-arm-kernel
Hello Wolfram,
This series is a follow-up to patch [0] that added an OF device ID table
to the at24 EEPROM driver. As you suggested [1], this version instead of
adding entries for every used <vendor,device> tuple, only adds a single
entry for each chip type using the "atmel" vendor as a generic fallback.
The first patch adds the OF device ID table for the at24 driver and the
next patches adds a generic fallback compatible string to each DTS that
defines a compatible I2C EEPROM device node.
Patches can be applied independently since the DTS change without the
driver change is a no-op and the OF device table won't be used without
the DTS changes.
[0]: https://lkml.org/lkml/2017/3/14/589
[1]: https://lkml.org/lkml/2017/3/15/99
Best regards,
Javier
Changes in v2:
- Only add a single OF device ID entry for each device type (Wolfram Sang).
Javier Martinez Canillas (22):
dt-bindings: i2c: eeprom: Document manufacturer used as generic
fallback
eeprom: at24: Add OF device ID table
ARM: dts: omap: Add generic compatible string for I2C EEPROM
ARM: dts: turris-omnia: Add generic compatible string for I2C EEPROM
ARM: dts: at91: Add generic compatible string for I2C EEPROM
ARM: dts: efm32: Add generic compatible string for I2C EEPROM
ARM: dts: imx: Add generic compatible string for I2C EEPROM
ARM: dts: keystone: Add generic compatible string for I2C EEPROM
ARM: dts: lpc18xx: Add generic compatible string for I2C EEPROM
ARM: dts: r7s72100: Add generic compatible string for I2C EEPROM
ARM: dts: koelsch: Add generic compatible string for I2C EEPROM
ARM: dts: socfpga: Add generic compatible string for I2C EEPROM
ARM: dts: uniphier: Add generic compatible string for I2C EEPROM
ARM: dts: zynq: Add generic compatible string for I2C EEPROM
arm64: dts: ls1043a: Add generic compatible string for I2C EEPROM
arm64: zynqmp: Add generic compatible string for I2C EEPROM
powerpc/5200: Add generic compatible string for I2C EEPROM
powerpc/fsl: Add generic compatible string for I2C EEPROM
powerpc/512x: Add generic compatible string for I2C EEPROM
powerpc/83xx: Add generic compatible string for I2C EEPROM
powerpc/5200: Add generic compatible string for I2C EEPROM
powerpc/44x: Add generic compatible string for I2C EEPROM
.../devicetree/bindings/eeprom/eeprom.txt | 3 +-
arch/arm/boot/dts/am335x-baltos.dtsi | 2 +-
arch/arm/boot/dts/am335x-base0033.dts | 2 +-
arch/arm/boot/dts/am335x-bone-common.dtsi | 10 ++--
arch/arm/boot/dts/am335x-nano.dts | 2 +-
arch/arm/boot/dts/am335x-pepper.dts | 2 +-
arch/arm/boot/dts/am335x-shc.dts | 2 +-
arch/arm/boot/dts/am335x-sl50.dts | 2 +-
arch/arm/boot/dts/am437x-idk-evm.dts | 2 +-
arch/arm/boot/dts/am437x-sk-evm.dts | 2 +-
arch/arm/boot/dts/am43x-epos-evm.dts | 2 +-
arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi | 2 +-
arch/arm/boot/dts/armada-385-turris-omnia.dts | 2 +-
arch/arm/boot/dts/at91-linea.dtsi | 2 +-
arch/arm/boot/dts/at91-tse850-3.dts | 2 +-
arch/arm/boot/dts/efm32gg-dk3750.dts | 2 +-
arch/arm/boot/dts/imx27-phytec-phycard-s-som.dtsi | 2 +-
arch/arm/boot/dts/imx27-phytec-phycore-som.dtsi | 2 +-
arch/arm/boot/dts/imx28-evk.dts | 2 +-
arch/arm/boot/dts/imx53-tqma53.dtsi | 2 +-
arch/arm/boot/dts/imx6q-cm-fx6.dts | 2 +-
arch/arm/boot/dts/imx6q-utilite-pro.dts | 2 +-
arch/arm/boot/dts/keystone-k2e-evm.dts | 2 +-
arch/arm/boot/dts/keystone-k2hk-evm.dts | 2 +-
arch/arm/boot/dts/keystone-k2l-evm.dts | 2 +-
arch/arm/boot/dts/lpc4337-ciaa.dts | 6 +-
arch/arm/boot/dts/lpc4350-hitex-eval.dts | 2 +-
arch/arm/boot/dts/lpc4357-ea4357-devkit.dts | 2 +-
arch/arm/boot/dts/omap3-cm-t3x.dtsi | 2 +-
arch/arm/boot/dts/omap3-gta04.dtsi | 2 +-
arch/arm/boot/dts/omap3-sb-t35.dtsi | 2 +-
arch/arm/boot/dts/omap4-var-som-om44.dtsi | 2 +-
arch/arm/boot/dts/omap5-cm-t54.dts | 2 +-
arch/arm/boot/dts/omap5-sbc-t54.dts | 2 +-
arch/arm/boot/dts/r7s72100-genmai.dts | 2 +-
arch/arm/boot/dts/r8a7791-koelsch.dts | 2 +-
arch/arm/boot/dts/socfpga_cyclone5_vining_fpga.dts | 2 +-
arch/arm/boot/dts/uniphier-pro4-ace.dts | 2 +-
arch/arm/boot/dts/uniphier-pro4-sanji.dts | 2 +-
arch/arm/boot/dts/uniphier-pxs2-gentil.dts | 2 +-
arch/arm/boot/dts/zynq-zc702.dts | 2 +-
arch/arm/boot/dts/zynq-zc706.dts | 2 +-
arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts | 4 +-
arch/arm64/boot/dts/xilinx/zynqmp-ep108.dts | 4 +-
arch/powerpc/boot/dts/digsy_mtc.dts | 2 +-
arch/powerpc/boot/dts/fsl/b4qds.dtsi | 8 +--
arch/powerpc/boot/dts/fsl/c293pcie.dts | 2 +-
arch/powerpc/boot/dts/fsl/p1010rdb.dtsi | 2 +-
arch/powerpc/boot/dts/fsl/p1023rdb.dts | 2 +-
arch/powerpc/boot/dts/fsl/p2041rdb.dts | 4 +-
arch/powerpc/boot/dts/fsl/p3041ds.dts | 4 +-
arch/powerpc/boot/dts/fsl/p4080ds.dts | 4 +-
arch/powerpc/boot/dts/fsl/p5020ds.dts | 4 +-
arch/powerpc/boot/dts/fsl/p5040ds.dts | 4 +-
arch/powerpc/boot/dts/fsl/t208xqds.dtsi | 8 +--
arch/powerpc/boot/dts/fsl/t4240qds.dts | 12 ++--
arch/powerpc/boot/dts/fsl/t4240rdb.dts | 6 +-
arch/powerpc/boot/dts/mpc5121ads.dts | 2 +-
arch/powerpc/boot/dts/mpc8308_p1m.dts | 2 +-
arch/powerpc/boot/dts/mpc8349emitx.dts | 2 +-
arch/powerpc/boot/dts/mpc8377_rdb.dts | 2 +-
arch/powerpc/boot/dts/mpc8377_wlan.dts | 2 +-
arch/powerpc/boot/dts/mpc8378_rdb.dts | 2 +-
arch/powerpc/boot/dts/mpc8379_rdb.dts | 2 +-
arch/powerpc/boot/dts/pcm030.dts | 2 +-
arch/powerpc/boot/dts/pcm032.dts | 2 +-
arch/powerpc/boot/dts/warp.dts | 2 +-
drivers/misc/eeprom/at24.c | 69 +++++++++++++++++++++-
68 files changed, 162 insertions(+), 94 deletions(-)
--
2.9.3
^ permalink raw reply
* [PATCH v2 03/22] ARM: dts: omap: Add generic compatible string for I2C EEPROM
From: Javier Martinez Canillas @ 2017-04-13 18:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170413182839.25381-1-javier@osg.samsung.com>
The at24 driver allows to register I2C EEPROM chips using different vendor
and devices, but the I2C subsystem does not take the vendor into account
when matching using the I2C table since it only has device entries.
But when matching using an OF table, both the vendor and device has to be
taken into account so the driver defines only a set of compatible strings
using the "atmel" vendor as a generic fallback for compatible I2C devices.
So add this generic fallback to the device node compatible string to make
the device to match the driver using the OF device ID table.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
---
Changes in v2: None
arch/arm/boot/dts/am335x-baltos.dtsi | 2 +-
arch/arm/boot/dts/am335x-base0033.dts | 2 +-
arch/arm/boot/dts/am335x-bone-common.dtsi | 10 +++++-----
arch/arm/boot/dts/am335x-nano.dts | 2 +-
arch/arm/boot/dts/am335x-pepper.dts | 2 +-
arch/arm/boot/dts/am335x-shc.dts | 2 +-
arch/arm/boot/dts/am335x-sl50.dts | 2 +-
arch/arm/boot/dts/am437x-idk-evm.dts | 2 +-
arch/arm/boot/dts/am437x-sk-evm.dts | 2 +-
arch/arm/boot/dts/am43x-epos-evm.dts | 2 +-
arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi | 2 +-
arch/arm/boot/dts/omap3-cm-t3x.dtsi | 2 +-
arch/arm/boot/dts/omap3-gta04.dtsi | 2 +-
arch/arm/boot/dts/omap3-sb-t35.dtsi | 2 +-
arch/arm/boot/dts/omap4-var-som-om44.dtsi | 2 +-
arch/arm/boot/dts/omap5-cm-t54.dts | 2 +-
arch/arm/boot/dts/omap5-sbc-t54.dts | 2 +-
17 files changed, 21 insertions(+), 21 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-baltos.dtsi b/arch/arm/boot/dts/am335x-baltos.dtsi
index d42b98f15e8b..ed6785d54ca4 100644
--- a/arch/arm/boot/dts/am335x-baltos.dtsi
+++ b/arch/arm/boot/dts/am335x-baltos.dtsi
@@ -255,7 +255,7 @@
};
at24 at 50 {
- compatible = "at24,24c02";
+ compatible = "at24,24c02","atmel,24c02";
pagesize = <8>;
reg = <0x50>;
};
diff --git a/arch/arm/boot/dts/am335x-base0033.dts b/arch/arm/boot/dts/am335x-base0033.dts
index c2bee452dab8..681323937e89 100644
--- a/arch/arm/boot/dts/am335x-base0033.dts
+++ b/arch/arm/boot/dts/am335x-base0033.dts
@@ -89,7 +89,7 @@
&i2c0 {
eeprom: eeprom at 50 {
- compatible = "at,24c256";
+ compatible = "at,24c256","atmel,24c256";
reg = <0x50>;
};
};
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi b/arch/arm/boot/dts/am335x-bone-common.dtsi
index bf6b26abe35b..5e42ab7d3e93 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -232,7 +232,7 @@
};
baseboard_eeprom: baseboard_eeprom at 50 {
- compatible = "at,24c256";
+ compatible = "at,24c256","atmel,24c256";
reg = <0x50>;
#address-cells = <1>;
@@ -251,7 +251,7 @@
clock-frequency = <100000>;
cape_eeprom0: cape_eeprom0 at 54 {
- compatible = "at,24c256";
+ compatible = "at,24c256","atmel,24c256";
reg = <0x54>;
#address-cells = <1>;
#size-cells = <1>;
@@ -261,7 +261,7 @@
};
cape_eeprom1: cape_eeprom1 at 55 {
- compatible = "at,24c256";
+ compatible = "at,24c256","atmel,24c256";
reg = <0x55>;
#address-cells = <1>;
#size-cells = <1>;
@@ -271,7 +271,7 @@
};
cape_eeprom2: cape_eeprom2 at 56 {
- compatible = "at,24c256";
+ compatible = "at,24c256","atmel,24c256";
reg = <0x56>;
#address-cells = <1>;
#size-cells = <1>;
@@ -281,7 +281,7 @@
};
cape_eeprom3: cape_eeprom3 at 57 {
- compatible = "at,24c256";
+ compatible = "at,24c256","atmel,24c256";
reg = <0x57>;
#address-cells = <1>;
#size-cells = <1>;
diff --git a/arch/arm/boot/dts/am335x-nano.dts b/arch/arm/boot/dts/am335x-nano.dts
index 807494bc722b..241f4f1b9be0 100644
--- a/arch/arm/boot/dts/am335x-nano.dts
+++ b/arch/arm/boot/dts/am335x-nano.dts
@@ -224,7 +224,7 @@
};
eeprom at 53 {
- compatible = "microchip,24c02";
+ compatible = "microchip,24c02","atmel,24c02";
reg = <0x53>;
pagesize = <8>;
};
diff --git a/arch/arm/boot/dts/am335x-pepper.dts b/arch/arm/boot/dts/am335x-pepper.dts
index 30e2f8770aaf..d7fbc0e42ac2 100644
--- a/arch/arm/boot/dts/am335x-pepper.dts
+++ b/arch/arm/boot/dts/am335x-pepper.dts
@@ -67,7 +67,7 @@
};
eeprom: eeprom at 50 {
- compatible = "at,24c256";
+ compatible = "at,24c256","atmel,24c256";
reg = <0x50>;
};
diff --git a/arch/arm/boot/dts/am335x-shc.dts b/arch/arm/boot/dts/am335x-shc.dts
index bf8727a19ece..7e8ea8376be5 100644
--- a/arch/arm/boot/dts/am335x-shc.dts
+++ b/arch/arm/boot/dts/am335x-shc.dts
@@ -188,7 +188,7 @@
};
at24 at 50 {
- compatible = "at24,24c32";
+ compatible = "at24,24c32","atmel,24c32";
pagesize = <32>;
reg = <0x50>;
};
diff --git a/arch/arm/boot/dts/am335x-sl50.dts b/arch/arm/boot/dts/am335x-sl50.dts
index c5d2589c55fc..42c941448d24 100644
--- a/arch/arm/boot/dts/am335x-sl50.dts
+++ b/arch/arm/boot/dts/am335x-sl50.dts
@@ -309,7 +309,7 @@
};
eeprom: eeprom at 50 {
- compatible = "at,24c256";
+ compatible = "at,24c256","atmel,24c256";
reg = <0x50>;
};
diff --git a/arch/arm/boot/dts/am437x-idk-evm.dts b/arch/arm/boot/dts/am437x-idk-evm.dts
index c1f7f9336e64..677d3772a5a0 100644
--- a/arch/arm/boot/dts/am437x-idk-evm.dts
+++ b/arch/arm/boot/dts/am437x-idk-evm.dts
@@ -339,7 +339,7 @@
clock-frequency = <400000>;
at24 at 50 {
- compatible = "at24,24c256";
+ compatible = "at24,24c256","atmel,24c256";
pagesize = <64>;
reg = <0x50>;
};
diff --git a/arch/arm/boot/dts/am437x-sk-evm.dts b/arch/arm/boot/dts/am437x-sk-evm.dts
index 4dc54bee2f36..449f93526fce 100644
--- a/arch/arm/boot/dts/am437x-sk-evm.dts
+++ b/arch/arm/boot/dts/am437x-sk-evm.dts
@@ -511,7 +511,7 @@
};
at24 at 50 {
- compatible = "at24,24c256";
+ compatible = "at24,24c256","atmel,24c256";
pagesize = <64>;
reg = <0x50>;
};
diff --git a/arch/arm/boot/dts/am43x-epos-evm.dts b/arch/arm/boot/dts/am43x-epos-evm.dts
index 9acd4ccdec4e..6f4a0a570b9e 100644
--- a/arch/arm/boot/dts/am43x-epos-evm.dts
+++ b/arch/arm/boot/dts/am43x-epos-evm.dts
@@ -477,7 +477,7 @@
};
at24 at 50 {
- compatible = "at24,24c256";
+ compatible = "at24,24c256","atmel,24c256";
pagesize = <64>;
reg = <0x50>;
};
diff --git a/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi b/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi
index 585d792a8fdd..1a8ebc4cc5ae 100644
--- a/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi
+++ b/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi
@@ -388,7 +388,7 @@
};
eeprom: eeprom at 50 {
- compatible = "at,24c32";
+ compatible = "at,24c32","atmel,24c32";
reg = <0x50>;
};
};
diff --git a/arch/arm/boot/dts/omap3-cm-t3x.dtsi b/arch/arm/boot/dts/omap3-cm-t3x.dtsi
index 57b9a028a49a..27965b619bb9 100644
--- a/arch/arm/boot/dts/omap3-cm-t3x.dtsi
+++ b/arch/arm/boot/dts/omap3-cm-t3x.dtsi
@@ -188,7 +188,7 @@
clock-frequency = <400000>;
at24 at 50 {
- compatible = "at24,24c02";
+ compatible = "at24,24c02","atmel,24c02";
pagesize = <16>;
reg = <0x50>;
};
diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi b/arch/arm/boot/dts/omap3-gta04.dtsi
index b3a8b1f24499..9d2661229b8e 100644
--- a/arch/arm/boot/dts/omap3-gta04.dtsi
+++ b/arch/arm/boot/dts/omap3-gta04.dtsi
@@ -418,7 +418,7 @@
/* RFID EEPROM */
m24lr64 at 50 {
- compatible = "at,24c64";
+ compatible = "at,24c64","atmel,24c64";
reg = <0x50>;
};
};
diff --git a/arch/arm/boot/dts/omap3-sb-t35.dtsi b/arch/arm/boot/dts/omap3-sb-t35.dtsi
index 73643fabde5d..aa90d1cce34a 100644
--- a/arch/arm/boot/dts/omap3-sb-t35.dtsi
+++ b/arch/arm/boot/dts/omap3-sb-t35.dtsi
@@ -90,7 +90,7 @@
clock-frequency = <400000>;
at24 at 50 {
- compatible = "at24,24c02";
+ compatible = "at24,24c02","atmel,24c02";
pagesize = <16>;
reg = <0x50>;
};
diff --git a/arch/arm/boot/dts/omap4-var-som-om44.dtsi b/arch/arm/boot/dts/omap4-var-som-om44.dtsi
index 758b6eb7ae43..f360b220f263 100644
--- a/arch/arm/boot/dts/omap4-var-som-om44.dtsi
+++ b/arch/arm/boot/dts/omap4-var-som-om44.dtsi
@@ -241,7 +241,7 @@
};
eeprom at 50 {
- compatible = "microchip,24c32";
+ compatible = "microchip,24c32","atmel,24c32";
reg = <0x50>;
};
};
diff --git a/arch/arm/boot/dts/omap5-cm-t54.dts b/arch/arm/boot/dts/omap5-cm-t54.dts
index b153f604932a..41c030c75d48 100644
--- a/arch/arm/boot/dts/omap5-cm-t54.dts
+++ b/arch/arm/boot/dts/omap5-cm-t54.dts
@@ -404,7 +404,7 @@
clock-frequency = <400000>;
at24 at 50 {
- compatible = "at24,24c02";
+ compatible = "at24,24c02","atmel,24c02";
pagesize = <16>;
reg = <0x50>;
};
diff --git a/arch/arm/boot/dts/omap5-sbc-t54.dts b/arch/arm/boot/dts/omap5-sbc-t54.dts
index 337bbbc01a35..5a63354f174b 100644
--- a/arch/arm/boot/dts/omap5-sbc-t54.dts
+++ b/arch/arm/boot/dts/omap5-sbc-t54.dts
@@ -44,7 +44,7 @@
clock-frequency = <400000>;
at24 at 50 {
- compatible = "at24,24c02";
+ compatible = "at24,24c02","atmel,24c02";
pagesize = <16>;
reg = <0x50>;
};
--
2.9.3
^ permalink raw reply related
* [PATCH v2 04/22] ARM: dts: turris-omnia: Add generic compatible string for I2C EEPROM
From: Javier Martinez Canillas @ 2017-04-13 18:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170413182839.25381-1-javier@osg.samsung.com>
The at24 driver allows to register I2C EEPROM chips using different vendor
and devices, but the I2C subsystem does not take the vendor into account
when matching using the I2C table since it only has device entries.
But when matching using an OF table, both the vendor and device has to be
taken into account so the driver defines only a set of compatible strings
using the "atmel" vendor as a generic fallback for compatible I2C devices.
So add this generic fallback to the device node compatible string to make
the device to match the driver using the OF device ID table.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
---
Changes in v2: None
arch/arm/boot/dts/armada-385-turris-omnia.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/armada-385-turris-omnia.dts b/arch/arm/boot/dts/armada-385-turris-omnia.dts
index 28eede180e4f..4185f6b1ba44 100644
--- a/arch/arm/boot/dts/armada-385-turris-omnia.dts
+++ b/arch/arm/boot/dts/armada-385-turris-omnia.dts
@@ -171,7 +171,7 @@
/* leds device (in STM32F0) at address 0x2b */
eeprom at 54 {
- compatible = "at,24c64";
+ compatible = "at,24c64","atmel,24c64";
reg = <0x54>;
/* The EEPROM contains data for bootloader.
--
2.9.3
^ permalink raw reply related
* [PATCH v2 05/22] ARM: dts: at91: Add generic compatible string for I2C EEPROM
From: Javier Martinez Canillas @ 2017-04-13 18:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170413182839.25381-1-javier@osg.samsung.com>
The at24 driver allows to register I2C EEPROM chips using different vendor
and devices, but the I2C subsystem does not take the vendor into account
when matching using the I2C table since it only has device entries.
But when matching using an OF table, both the vendor and device has to be
taken into account so the driver defines only a set of compatible strings
using the "atmel" vendor as a generic fallback for compatible I2C devices.
So add this generic fallback to the device node compatible string to make
the device to match the driver using the OF device ID table.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
---
Changes in v2: None
arch/arm/boot/dts/at91-linea.dtsi | 2 +-
arch/arm/boot/dts/at91-tse850-3.dts | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/at91-linea.dtsi b/arch/arm/boot/dts/at91-linea.dtsi
index 0721c8472509..9a19080fd3bf 100644
--- a/arch/arm/boot/dts/at91-linea.dtsi
+++ b/arch/arm/boot/dts/at91-linea.dtsi
@@ -31,7 +31,7 @@
status = "okay";
eeprom at 51 {
- compatible = "st,24c64";
+ compatible = "st,24c64","atmel,24c64";
reg = <0x51>;
pagesize = <32>;
};
diff --git a/arch/arm/boot/dts/at91-tse850-3.dts b/arch/arm/boot/dts/at91-tse850-3.dts
index 7a68805a4eb5..6f005c14a6b0 100644
--- a/arch/arm/boot/dts/at91-tse850-3.dts
+++ b/arch/arm/boot/dts/at91-tse850-3.dts
@@ -239,7 +239,7 @@
};
eeprom at 50 {
- compatible = "nxp,24c02";
+ compatible = "nxp,24c02","atmel,24c02";
reg = <0x50>;
pagesize = <16>;
};
--
2.9.3
^ permalink raw reply related
* [PATCH v2 06/22] ARM: dts: efm32: Add generic compatible string for I2C EEPROM
From: Javier Martinez Canillas @ 2017-04-13 18:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170413182839.25381-1-javier@osg.samsung.com>
The at24 driver allows to register I2C EEPROM chips using different vendor
and devices, but the I2C subsystem does not take the vendor into account
when matching using the I2C table since it only has device entries.
But when matching using an OF table, both the vendor and device has to be
taken into account so the driver defines only a set of compatible strings
using the "atmel" vendor as a generic fallback for compatible I2C devices.
So add this generic fallback to the device node compatible string to make
the device to match the driver using the OF device ID table.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
---
Changes in v2: None
arch/arm/boot/dts/efm32gg-dk3750.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/efm32gg-dk3750.dts b/arch/arm/boot/dts/efm32gg-dk3750.dts
index 98fc667d22c7..2f34491881ae 100644
--- a/arch/arm/boot/dts/efm32gg-dk3750.dts
+++ b/arch/arm/boot/dts/efm32gg-dk3750.dts
@@ -36,7 +36,7 @@
};
eeprom at 50 {
- compatible = "microchip,24c02";
+ compatible = "microchip,24c02","atmel,24c02";
reg = <0x50>;
pagesize = <16>;
};
--
2.9.3
^ permalink raw reply related
* [PATCH v2 07/22] ARM: dts: imx: Add generic compatible string for I2C EEPROM
From: Javier Martinez Canillas @ 2017-04-13 18:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170413182839.25381-1-javier@osg.samsung.com>
The at24 driver allows to register I2C EEPROM chips using different vendor
and devices, but the I2C subsystem does not take the vendor into account
when matching using the I2C table since it only has device entries.
But when matching using an OF table, both the vendor and device has to be
taken into account so the driver defines only a set of compatible strings
using the "atmel" vendor as a generic fallback for compatible I2C devices.
So add this generic fallback to the device node compatible string to make
the device to match the driver using the OF device ID table.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
---
Changes in v2: None
arch/arm/boot/dts/imx27-phytec-phycard-s-som.dtsi | 2 +-
arch/arm/boot/dts/imx27-phytec-phycore-som.dtsi | 2 +-
arch/arm/boot/dts/imx28-evk.dts | 2 +-
arch/arm/boot/dts/imx53-tqma53.dtsi | 2 +-
arch/arm/boot/dts/imx6q-cm-fx6.dts | 2 +-
arch/arm/boot/dts/imx6q-utilite-pro.dts | 2 +-
6 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/imx27-phytec-phycard-s-som.dtsi b/arch/arm/boot/dts/imx27-phytec-phycard-s-som.dtsi
index 4f3e0f473581..61e741092efa 100644
--- a/arch/arm/boot/dts/imx27-phytec-phycard-s-som.dtsi
+++ b/arch/arm/boot/dts/imx27-phytec-phycard-s-som.dtsi
@@ -40,7 +40,7 @@
status = "okay";
at24 at 52 {
- compatible = "at,24c32";
+ compatible = "at,24c32","atmel,24c32";
pagesize = <32>;
reg = <0x52>;
};
diff --git a/arch/arm/boot/dts/imx27-phytec-phycore-som.dtsi b/arch/arm/boot/dts/imx27-phytec-phycore-som.dtsi
index 82fec935ce83..5b6b651af18f 100644
--- a/arch/arm/boot/dts/imx27-phytec-phycore-som.dtsi
+++ b/arch/arm/boot/dts/imx27-phytec-phycore-som.dtsi
@@ -193,7 +193,7 @@
status = "okay";
at24 at 52 {
- compatible = "at,24c32";
+ compatible = "at,24c32","atmel,24c32";
pagesize = <32>;
reg = <0x52>;
};
diff --git a/arch/arm/boot/dts/imx28-evk.dts b/arch/arm/boot/dts/imx28-evk.dts
index a5ba669b4eaa..5ab990ac36b4 100644
--- a/arch/arm/boot/dts/imx28-evk.dts
+++ b/arch/arm/boot/dts/imx28-evk.dts
@@ -203,7 +203,7 @@
};
at24 at 51 {
- compatible = "at24,24c32";
+ compatible = "at24,24c32","atmel,24c32";
pagesize = <32>;
reg = <0x51>;
};
diff --git a/arch/arm/boot/dts/imx53-tqma53.dtsi b/arch/arm/boot/dts/imx53-tqma53.dtsi
index 85972f2201c2..c8bc0522a1e9 100644
--- a/arch/arm/boot/dts/imx53-tqma53.dtsi
+++ b/arch/arm/boot/dts/imx53-tqma53.dtsi
@@ -272,7 +272,7 @@
};
eeprom: 24c64 at 50 {
- compatible = "at,24c64";
+ compatible = "at,24c64","atmel,24c64";
pagesize = <32>;
reg = <0x50>;
};
diff --git a/arch/arm/boot/dts/imx6q-cm-fx6.dts b/arch/arm/boot/dts/imx6q-cm-fx6.dts
index 66cac5328b86..8cf478c67f83 100644
--- a/arch/arm/boot/dts/imx6q-cm-fx6.dts
+++ b/arch/arm/boot/dts/imx6q-cm-fx6.dts
@@ -215,7 +215,7 @@
clock-frequency = <100000>;
eeprom at 50 {
- compatible = "at24,24c02";
+ compatible = "at24,24c02","atmel,24c02";
reg = <0x50>;
pagesize = <16>;
};
diff --git a/arch/arm/boot/dts/imx6q-utilite-pro.dts b/arch/arm/boot/dts/imx6q-utilite-pro.dts
index 69bdd82ce21f..644889d813d0 100644
--- a/arch/arm/boot/dts/imx6q-utilite-pro.dts
+++ b/arch/arm/boot/dts/imx6q-utilite-pro.dts
@@ -128,7 +128,7 @@
#size-cells = <0>;
eeprom at 50 {
- compatible = "at24,24c02";
+ compatible = "at24,24c02","atmel,24c02";
reg = <0x50>;
pagesize = <16>;
};
--
2.9.3
^ permalink raw reply related
* [PATCH v2 08/22] ARM: dts: keystone: Add generic compatible string for I2C EEPROM
From: Javier Martinez Canillas @ 2017-04-13 18:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170413182839.25381-1-javier@osg.samsung.com>
The at24 driver allows to register I2C EEPROM chips using different vendor
and devices, but the I2C subsystem does not take the vendor into account
when matching using the I2C table since it only has device entries.
But when matching using an OF table, both the vendor and device has to be
taken into account so the driver defines only a set of compatible strings
using the "atmel" vendor as a generic fallback for compatible I2C devices.
So add this generic fallback to the device node compatible string to make
the device to match the driver using the OF device ID table.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
---
Changes in v2: None
arch/arm/boot/dts/keystone-k2e-evm.dts | 2 +-
arch/arm/boot/dts/keystone-k2hk-evm.dts | 2 +-
arch/arm/boot/dts/keystone-k2l-evm.dts | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/keystone-k2e-evm.dts b/arch/arm/boot/dts/keystone-k2e-evm.dts
index ae1ebe7ee021..0540e49dcece 100644
--- a/arch/arm/boot/dts/keystone-k2e-evm.dts
+++ b/arch/arm/boot/dts/keystone-k2e-evm.dts
@@ -69,7 +69,7 @@
&i2c0 {
dtt at 50 {
- compatible = "at,24c1024";
+ compatible = "at,24c1024","atmel,24c1024";
reg = <0x50>;
};
};
diff --git a/arch/arm/boot/dts/keystone-k2hk-evm.dts b/arch/arm/boot/dts/keystone-k2hk-evm.dts
index 2156ff92d08f..c278d2c10c67 100644
--- a/arch/arm/boot/dts/keystone-k2hk-evm.dts
+++ b/arch/arm/boot/dts/keystone-k2hk-evm.dts
@@ -145,7 +145,7 @@
&i2c0 {
dtt at 50 {
- compatible = "at,24c1024";
+ compatible = "at,24c1024","atmel,24c1024";
reg = <0x50>;
};
};
diff --git a/arch/arm/boot/dts/keystone-k2l-evm.dts b/arch/arm/boot/dts/keystone-k2l-evm.dts
index 056b42f99d7a..d0e62890cd95 100644
--- a/arch/arm/boot/dts/keystone-k2l-evm.dts
+++ b/arch/arm/boot/dts/keystone-k2l-evm.dts
@@ -42,7 +42,7 @@
&i2c0 {
dtt at 50 {
- compatible = "at,24c1024";
+ compatible = "at,24c1024","atmel,24c1024";
reg = <0x50>;
};
};
--
2.9.3
^ permalink raw reply related
* [PATCH v2 09/22] ARM: dts: lpc18xx: Add generic compatible string for I2C EEPROM
From: Javier Martinez Canillas @ 2017-04-13 18:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170413182839.25381-1-javier@osg.samsung.com>
The at24 driver allows to register I2C EEPROM chips using different vendor
and devices, but the I2C subsystem does not take the vendor into account
when matching using the I2C table since it only has device entries.
But when matching using an OF table, both the vendor and device has to be
taken into account so the driver defines only a set of compatible strings
using the "atmel" vendor as a generic fallback for compatible I2C devices.
So add this generic fallback to the device node compatible string to make
the device to match the driver using the OF device ID table.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
---
Changes in v2: None
arch/arm/boot/dts/lpc4337-ciaa.dts | 6 +++---
arch/arm/boot/dts/lpc4350-hitex-eval.dts | 2 +-
arch/arm/boot/dts/lpc4357-ea4357-devkit.dts | 2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/lpc4337-ciaa.dts b/arch/arm/boot/dts/lpc4337-ciaa.dts
index 7c16d639a1b4..8b584b39db7d 100644
--- a/arch/arm/boot/dts/lpc4337-ciaa.dts
+++ b/arch/arm/boot/dts/lpc4337-ciaa.dts
@@ -174,17 +174,17 @@
clock-frequency = <400000>;
eeprom at 50 {
- compatible = "microchip,24c512";
+ compatible = "microchip,24c512","atmel,24c512";
reg = <0x50>;
};
eeprom at 51 {
- compatible = "microchip,24c02";
+ compatible = "microchip,24c02","atmel,24c02";
reg = <0x51>;
};
eeprom at 54 {
- compatible = "microchip,24c512";
+ compatible = "microchip,24c512","atmel,24c512";
reg = <0x54>;
};
};
diff --git a/arch/arm/boot/dts/lpc4350-hitex-eval.dts b/arch/arm/boot/dts/lpc4350-hitex-eval.dts
index 874c75d44013..32a512926a8f 100644
--- a/arch/arm/boot/dts/lpc4350-hitex-eval.dts
+++ b/arch/arm/boot/dts/lpc4350-hitex-eval.dts
@@ -429,7 +429,7 @@
};
eeprom at 50 {
- compatible = "nxp,24c02";
+ compatible = "nxp,24c02","atmel,24c02";
reg = <0x50>;
};
diff --git a/arch/arm/boot/dts/lpc4357-ea4357-devkit.dts b/arch/arm/boot/dts/lpc4357-ea4357-devkit.dts
index 9b5fad622522..7000a565f50b 100644
--- a/arch/arm/boot/dts/lpc4357-ea4357-devkit.dts
+++ b/arch/arm/boot/dts/lpc4357-ea4357-devkit.dts
@@ -490,7 +490,7 @@
};
eeprom at 57 {
- compatible = "microchip,24c64";
+ compatible = "microchip,24c64","atmel,24c64";
reg = <0x57>;
};
};
--
2.9.3
^ permalink raw reply related
* [PATCH v2 10/22] ARM: dts: r7s72100: Add generic compatible string for I2C EEPROM
From: Javier Martinez Canillas @ 2017-04-13 18:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170413182839.25381-1-javier@osg.samsung.com>
The at24 driver allows to register I2C EEPROM chips using different vendor
and devices, but the I2C subsystem does not take the vendor into account
when matching using the I2C table since it only has device entries.
But when matching using an OF table, both the vendor and device has to be
taken into account so the driver defines only a set of compatible strings
using the "atmel" vendor as a generic fallback for compatible I2C devices.
So add this generic fallback to the device node compatible string to make
the device to match the driver using the OF device ID table.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
---
Changes in v2: None
arch/arm/boot/dts/r7s72100-genmai.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/r7s72100-genmai.dts b/arch/arm/boot/dts/r7s72100-genmai.dts
index 52a7b586bac7..46dc6d293cb3 100644
--- a/arch/arm/boot/dts/r7s72100-genmai.dts
+++ b/arch/arm/boot/dts/r7s72100-genmai.dts
@@ -57,7 +57,7 @@
clock-frequency = <400000>;
eeprom at 50 {
- compatible = "renesas,24c128";
+ compatible = "renesas,24c128","atmel,24c128";
reg = <0x50>;
pagesize = <64>;
};
--
2.9.3
^ 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