Re: [patch 13/26] posix-timers: Rename do_schedule_next_timer
On Thu, Jun 01, 2017 at 10:50:42PM +0200, Thomas Gleixner wrote: > On Wed, 31 May 2017, Christoph Hellwig wrote: > > > On Tue, May 30, 2017 at 11:15:46PM +0200, Thomas Gleixner wrote: > > > That function is a misnomer. Rename it with a proper prefix to > > > posixtimer_rearm(). > > > > Please also move it out of asm-generic/siginfo.h as it's implemented > > and used in generic code only, and there is no arch override at all. > > > > In fact it seems like asm-generic/siginfo.h should probably just move > > to include/linux/signinfo.h. > > That's one convoluted mess. Yes. I tried to give it some love 2 days ago but my first attempt failed badly. Here is what I'm at now, but it's not quite ready for prime time: http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/siginfo
Re: [PATCH RFC 0/2] KVM: s390: avoid having to enable vm.alloc_pgste
On Thu, Jun 01, 2017 at 12:46:51PM +0200, Martin Schwidefsky wrote: > > Unfortunately, converting all page tables to 4k pgste page tables is > > not possible without provoking various race conditions. > > That is one approach we tried and was found to be buggy. The point is that > you are not allowed to reallocate a page table while a VMA exists that is > in the address range of that page table. > > Another approach we tried is to use an ELF flag on the qemu executable. > That does not work either because fs/exec.c allocates and populates the > new mm struct for the argument pages before fs/binfmt_elf.c comes into > play. How about if you would fail the system call within arch_check_elf() if you detect that the binary requires pgstes (as indicated by elf flags) and then restart the system call? That is: arch_check_elf() e.g. would set a thread flag that future mm's should be allocated with pgstes. Then do_execve() would cleanup everything and return to entry.S. Upon return to userspace we detect this condition and simply restart the system call, similar to signals vs -ERESTARTSYS. That would make do_execve() cleanup everything and upon reentering it would allocate an mm with the pgste flag set. Maybe this is a bit over-simplified, but might work. At least I also don't like the next "hack", that is specifically designed to only work with how QEMU is currently implemented. It might break with future QEMU changes or the next user space implementation that drives the kvm interface, but is doing everything differently. Let's look for a "clean" solution that will always work. We had too many hacks for this problem and *all* of them were broken.
Re: single-threaded wq lockdep is broken
On Wed, May 31, 2017 at 4:36 PM, Johannes Berg
wrote:
> Hi,
>
>> > #include
>> > #include
>> > #include
>> > #include
>> > #include
>> >
>> > DEFINE_MUTEX(mtx);
>> > static struct workqueue_struct *wq;
>> > static struct work_struct w1, w2;
>> >
>> > static void w1_wk(struct work_struct *w)
>> > {
>> > mutex_lock(&mtx);
>> > msleep(100);
>> > mutex_unlock(&mtx);
>> > }
>> >
>> > static void w2_wk(struct work_struct *w)
>> > {
>> > }
>> >
>> > /*
>> > * if not defined, then lockdep should warn only,
>>
>> I guess when DEADLOCK not defined, there is no
>> work is queued nor executed, therefore, no lock
>> dependence is recorded, and there is no warn
>> either.
>>
>> > * if defined, the system will really deadlock.
>> > */
>> >
>> > //#define DEADLOCK
>> >
>> > static int init(void)
>> > {
>> > wq = create_singlethread_workqueue("test");
>> > if (!wq)
>> > return -ENOMEM;
>> > INIT_WORK(&w1, w1_wk);
>> > INIT_WORK(&w2, w2_wk);
>> >
>>
>> /* add lock dependence, the lockdep should warn */
>> queue_work(wq, &w1);
>> queue_work(wq, &w2);
>> flush_work(&w1);
>>
>> > #ifdef DEADLOCK
>> > queue_work(wq, &w1);
>> > queue_work(wq, &w2);
>> > #endif
>> > mutex_lock(&mtx);
>> > flush_work(&w2);
>> > mutex_unlock(&mtx);
>> >
>> > #ifndef DEADLOCK
>> > queue_work(wq, &w1);
>> > queue_work(wq, &w2);
>> > #endif
>
> This was "ifndef", so it does in fact run here, just like you
> suggested. It doesn't warn though.
>
> I don't think the order of queue/flush would matter, in fact, if you
> insert it like you did, with the flush outside the mutex, no issue
> exists (until the later flush)
>
the @w2 is not queued before flush_work(&w2), it is expected
that @w2 is not associated with @wq, and the dependence
mtx -> wq will not be recorded. And it is expected no warning.
> Also, even if DEADLOCK *is* defined, lockdep doesn't report anything.
Uhhh. I have no idea about it yet.
[PATCH v2 0/2] Add usb nodes on rk322x SoCs and enable usb on rk3229 evb
This series adds support for usb on rk322x SoCs. William Wu (2): ARM: dts: rockchip: add usb nodes on rk322x ARM: dts: rockchip: enable usb for rk3229 evb board Tested on rk3229 evb board, and depended on the following patches and config. [1] https://patchwork.kernel.org/patch/9761507/ [2] https://patchwork.kernel.org/patch/9761511/ [3] https://patchwork.kernel.org/patch/9761515/ [4] https://patchwork.kernel.org/patch/9761519/ [5] enable CONFIG_PHY_ROCKCHIP_INNO_USB2 arch/arm/boot/dts/rk3229-evb.dts | 74 + arch/arm/boot/dts/rk322x.dtsi| 138 ++- 2 files changed, 211 insertions(+), 1 deletion(-) -- 2.0.0
[PATCH v2 2/2] ARM: dts: rockchip: enable usb for rk3229 evb board
Rockchip's rk3229 evaluation board has one usb otg controller
and three usb host controllers. Each usb controller connect
with one usb2 phy port through UTMI+ interface. And the three
usb host interfaces use the same GPIO VBUS drive. Let's enable
them to support usb on rk3229 evb board.
Signed-off-by: William Wu
---
arch/arm/boot/dts/rk3229-evb.dts | 74
1 file changed, 74 insertions(+)
diff --git a/arch/arm/boot/dts/rk3229-evb.dts b/arch/arm/boot/dts/rk3229-evb.dts
index 275092a..1b55192 100644
--- a/arch/arm/boot/dts/rk3229-evb.dts
+++ b/arch/arm/boot/dts/rk3229-evb.dts
@@ -58,6 +58,17 @@
#clock-cells = <0>;
};
+ vcc_host: vcc-host-regulator {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpio = <&gpio3 RK_PC4 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&host_vbus_drv>;
+ regulator-name = "vcc_host";
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
vcc_phy: vcc-phy-regulator {
compatible = "regulator-fixed";
enable-active-high;
@@ -85,6 +96,69 @@
status = "okay";
};
+&pinctrl {
+ usb {
+ host_vbus_drv: host-vbus-drv {
+ rockchip,pins = <3 RK_PC4 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+};
+
&uart2 {
status = "okay";
};
+
+&u2phy0 {
+ status = "okay";
+
+ u2phy0_otg: otg-port {
+ status = "okay";
+ };
+
+ u2phy0_host: host-port {
+ phy-supply = <&vcc_host>;
+ status = "okay";
+ };
+};
+
+&u2phy1 {
+ status = "okay";
+
+ u2phy1_otg: otg-port {
+ phy-supply = <&vcc_host>;
+ status = "okay";
+ };
+
+ u2phy1_host: host-port {
+ phy-supply = <&vcc_host>;
+ status = "okay";
+ };
+};
+
+&usb_host0_ehci {
+ status = "okay";
+};
+
+&usb_host0_ohci {
+ status = "okay";
+};
+
+&usb_host1_ehci {
+ status = "okay";
+};
+
+&usb_host1_ohci {
+ status = "okay";
+};
+
+&usb_host2_ehci {
+ status = "okay";
+};
+
+&usb_host2_ohci {
+ status = "okay";
+};
+
+&usb_otg {
+ status = "okay";
+};
--
2.0.0
[PATCH v2 1/2] ARM: dts: rockchip: add usb nodes on rk322x
This patch adds usb otg/host controllers and phys nodes on rk322x.
Signed-off-by: William Wu
---
arch/arm/boot/dts/rk322x.dtsi | 138 +-
1 file changed, 137 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/rk322x.dtsi b/arch/arm/boot/dts/rk322x.dtsi
index df57413..1e0ee4a 100644
--- a/arch/arm/boot/dts/rk322x.dtsi
+++ b/arch/arm/boot/dts/rk322x.dtsi
@@ -210,8 +210,61 @@
};
grf: syscon@1100 {
- compatible = "syscon";
+ compatible = "syscon", "simple-mfd";
reg = <0x1100 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ u2phy0: usb2-phy@760 {
+ compatible = "rockchip,rk3228-usb2phy";
+ reg = <0x0760 0x0c>;
+ clocks = <&cru SCLK_OTGPHY0>;
+ clock-names = "phyclk";
+ #clock-cells = <0>;
+ clock-output-names = "usb480m_phy0";
+ status = "disabled";
+
+ u2phy0_otg: otg-port {
+ #phy-cells = <0>;
+ interrupts = ,
+,
+;
+ interrupt-names = "otg-bvalid", "otg-id",
+ "linestate";
+ status = "disabled";
+ };
+
+ u2phy0_host: host-port {
+ #phy-cells = <0>;
+ interrupts = ;
+ interrupt-names = "linestate";
+ status = "disabled";
+ };
+ };
+
+ u2phy1: usb2-phy@800 {
+ compatible = "rockchip,rk3228-usb2phy";
+ reg = <0x0800 0x0c>;
+ clocks = <&cru SCLK_OTGPHY1>;
+ clock-names = "phyclk";
+ #clock-cells = <0>;
+ clock-output-names = "usb480m_phy1";
+ status = "disabled";
+
+ u2phy1_otg: otg-port {
+ #phy-cells = <0>;
+ interrupts = ;
+ interrupt-names = "linestate";
+ status = "disabled";
+ };
+
+ u2phy1_host: host-port {
+ #phy-cells = <0>;
+ interrupts = ;
+ interrupt-names = "linestate";
+ status = "disabled";
+ };
+ };
};
uart0: serial@1101 {
@@ -467,6 +520,89 @@
status = "disabled";
};
+ usb_otg: usb@3004 {
+ compatible = "rockchip,rk3228-usb", "rockchip,rk3066-usb",
+"snps,dwc2";
+ reg = <0x3004 0x4>;
+ interrupts = ;
+ clocks = <&cru HCLK_OTG>;
+ clock-names = "otg";
+ dr_mode = "otg";
+ g-np-tx-fifo-size = <16>;
+ g-rx-fifo-size = <280>;
+ g-tx-fifo-size = <256 128 128 64 32 16>;
+ g-use-dma;
+ phys = <&u2phy0_otg>;
+ phy-names = "usb2-phy";
+ status = "disabled";
+ };
+
+ usb_host0_ehci: usb@3008 {
+ compatible = "generic-ehci";
+ reg = <0x3008 0x2>;
+ interrupts = ;
+ clocks = <&cru HCLK_HOST0>, <&u2phy0>;
+ clock-names = "usbhost", "utmi";
+ phys = <&u2phy0_host>;
+ phy-names = "usb";
+ status = "disabled";
+ };
+
+ usb_host0_ohci: usb@300a {
+ compatible = "generic-ohci";
+ reg = <0x300a 0x2>;
+ interrupts = ;
+ clocks = <&cru HCLK_HOST0>, <&u2phy0>;
+ clock-names = "usbhost", "utmi";
+ phys = <&u2phy0_host>;
+ phy-names = "usb";
+ status = "disabled";
+ };
+
+ usb_host1_ehci: usb@300c {
+ compatible = "generic-ehci";
+ reg = <0x300c 0x2>;
+ interrupts = ;
+ clocks = <&cru HCLK_HOST1>, <&u2phy1>;
+ clock-names = "usbhost", "utmi";
+ phys = <&u2phy1_otg>;
+ phy-names = "usb";
+ status = "disabled";
+ };
+
+ usb_host1_ohci: usb@300e {
+ compatible = "generic-ohci";
+ reg = <0x300e 0x2>;
+ interrupts = ;
+ clocks = <&cru HCLK_HOST1>, <&u2phy1>;
+ clock-names
[PATCH 3/3] power: supply: Add support MAX1721x battery monitor
Add support for battery monitor MAX1721x (power_supply class).
Maxim Semiconductor MAX1721x Standalone Fuel Gauge battery monitor.
MAX17211 used for singlecell, MAX17215 for multicell batteryes.
---
drivers/power/supply/Kconfig| 14 ++
drivers/power/supply/Makefile | 1 +
drivers/power/supply/max1721x_battery.c | 357
3 files changed, 372 insertions(+)
create mode 100644 drivers/power/supply/max1721x_battery.c
diff --git a/drivers/power/supply/Kconfig b/drivers/power/supply/Kconfig
index da54ac88f0..d431d6f8aa 100644
--- a/drivers/power/supply/Kconfig
+++ b/drivers/power/supply/Kconfig
@@ -268,6 +268,20 @@ config BATTERY_MAX17042
with MAX17042. This driver also supports max17047/50 chips which are
improved version of max17042.
+config BATTERY_MAX1721X
+ tristate "MAX17211/MAX17215 standalone gas-gauge"
+ depends on W1
+ select W1_SLAVE_MAX1721X
+ select REGMAP_W1
+ help
+ MAX1721x is fuel-gauge systems for lithium-ion (Li+) batteries
+ in handheld and portable equipment. MAX17211 used with single cell
+ battery. MAX17215 designed for muticell battery. Both them have
+ 1-Wire (W1) host interface.
+
+ Say Y here to enable support for the MAX17211/MAX17215 standalone
+ battery gas-gauge.
+
config BATTERY_Z2
tristate "Z2 battery driver"
depends on I2C && MACH_ZIPIT2
diff --git a/drivers/power/supply/Makefile b/drivers/power/supply/Makefile
index 3789a2c06f..c785d05e02 100644
--- a/drivers/power/supply/Makefile
+++ b/drivers/power/supply/Makefile
@@ -41,6 +41,7 @@ obj-$(CONFIG_CHARGER_DA9150) += da9150-charger.o
obj-$(CONFIG_BATTERY_DA9150) += da9150-fg.o
obj-$(CONFIG_BATTERY_MAX17040) += max17040_battery.o
obj-$(CONFIG_BATTERY_MAX17042) += max17042_battery.o
+obj-$(CONFIG_BATTERY_MAX1721X) += max1721x_battery.o
obj-$(CONFIG_BATTERY_Z2) += z2_battery.o
obj-$(CONFIG_BATTERY_RT5033) += rt5033_battery.o
obj-$(CONFIG_CHARGER_RT9455) += rt9455_charger.o
diff --git a/drivers/power/supply/max1721x_battery.c
b/drivers/power/supply/max1721x_battery.c
new file mode 100644
index 00..aa0effec3d
--- /dev/null
+++ b/drivers/power/supply/max1721x_battery.c
@@ -0,0 +1,357 @@
+/*
+ * 1-wire client/driver for the Maxim Semicondactor
+ * MAX17211/MAX17215 Standalone Fuel Gauge IC
+ *
+ * Copyright (C) 2017 OAO Radioavionica
+ * Author: Alex A. Mihaylov
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "../../w1/w1.h"
+#include "../../w1/slaves/w1_max1721x.h"
+
+#define DEF_DEV_NAME_MAX17211 "MAX17211"
+#define DEF_DEV_NAME_MAX17215 "MAX17215"
+#define DEF_DEV_NAME_UNKNOWN "UNKNOWN"
+#define DEF_MFG_NAME "MAXIM"
+
+struct max17211_device_info {
+ struct device *dev;
+ struct power_supply *bat;
+ struct power_supply_desc bat_desc;
+ struct device *w1_dev;
+ struct regmap *regmap;
+ /* battery design format */
+ unsigned int rsense; /* in tenths uOhm */
+ char DeviceName[2 * MAX1721X_REG_DEV_NUMB + 1];
+ char ManufacturerName[2 * MAX1721X_REG_MFG_NUMB + 1];
+ char SerialNumber[13]; /* see get_sn_str() later for comment */
+};
+
+static inline struct max17211_device_info *
+to_device_info(struct power_supply *psy)
+{
+ return power_supply_get_drvdata(psy);
+}
+
+static int max1721x_battery_get_property(struct power_supply *psy,
+ enum power_supply_property psp,
+ union power_supply_propval *val)
+{
+ struct max17211_device_info *info = to_device_info(psy);
+ unsigned int reg = 0;
+ int ret = 0;
+
+ switch (psp) {
+ case POWER_SUPPLY_PROP_PRESENT:
+ /*
+* POWER_SUPPLY_PROP_PRESENT will always readable via
+* sysfs interface. Value return 0 if battery not
+* present or unaccesable via W1.
+*/
+ val->intval =
+ regmap_read(info->regmap, MAX172XX_REG_STATUS,
+ ®) ? 0 : !(reg & MAX172XX_BAT_PRESENT);
+ break;
+ case POWER_SUPPLY_PROP_CAPACITY:
+ ret = regmap_read(info->regmap, MAX172XX_REG_REPSOC, ®);
+ val->intval = max172xx_percent_to_ps(reg);
+ break;
+ case POWER_SUPPLY_PROP_VOLTAGE_NOW:
+ ret = regmap_read(info->regmap, MAX172XX_REG_BATT, ®);
+ val->intval = max172xx_voltage_to_ps(reg);
+ break;
+ case POWER_SUPPLY_PROP_CHARGE_FULL_DESIGN:
+ ret = regmap_read(info->regmap, MAX172XX_REG_DESIGNCAP, ®);
+ val->intval = max172xx_capacity_to_ps(reg);
+ break;
+ case POWER
[PATCH 0/3] Battery monitor MAX1721x with w1-regmap and w1-slave (resend)
Codding style fix. Maillist message subject fix. Soryy for all. It's hard to be stuppid :-( Alex A. Mihaylov (3): regmap: Add 1-Wire bus support w1: MAX1721x Stanalone Fuel Gauge - add 1-Wire slave drivers power: supply: Add support MAX1721x battery monitor drivers/base/regmap/Kconfig | 6 +- drivers/base/regmap/Makefile| 1 + drivers/base/regmap/regmap-w1.c | 245 ++ drivers/power/supply/Kconfig| 14 ++ drivers/power/supply/Makefile | 1 + drivers/power/supply/max1721x_battery.c | 357 drivers/w1/slaves/Kconfig | 12 ++ drivers/w1/slaves/Makefile | 1 + drivers/w1/slaves/w1_max1721x.c | 73 +++ drivers/w1/slaves/w1_max1721x.h | 102 + drivers/w1/w1_family.h | 1 + include/linux/regmap.h | 34 +++ 12 files changed, 846 insertions(+), 1 deletion(-) create mode 100644 drivers/base/regmap/regmap-w1.c create mode 100644 drivers/power/supply/max1721x_battery.c create mode 100644 drivers/w1/slaves/w1_max1721x.c create mode 100644 drivers/w1/slaves/w1_max1721x.h -- 2.13.0
Re: [PATCH RFC 0/2] KVM: s390: avoid having to enable vm.alloc_pgste
On Thu, Jun 01, 2017 at 01:27:28PM +0200, David Hildenbrand wrote: > An alternative: Have some process that enables PGSTE for all of its > future children. Fork+execv qemu. However, such a process in between > will most likely confuse tooling like libvirt when it comes to process ids. That would be something like sys_personality() vs setarch, e.g. adding a new s390 specific personality flag and then do something like setarch s390x --kvm qemu... However I'm afraid that this is also not acceptable from a usability point of view.
[PATCH v2] acpi: configfs: Unload SSDT on configfs entry removal
Call directly into acpica to load a table to obtain its index on return.
We choose the direct call of acpica internal functions to avoid having
to modify its API which is used outside of Linux as well.
Use that index to unload the table again when the corresponding
directory in configfs gets removed. This allows to change SSDTs without
rebooting the system. It also allows to destroy devices again that a
dynamically loaded SSDT created.
This is widely similar to the DT overlay behavior.
Signed-off-by: Jan Kiszka
---
Changes in v2:
- do not touch acpica
drivers/acpi/acpi_configfs.c | 20 +++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/drivers/acpi/acpi_configfs.c b/drivers/acpi/acpi_configfs.c
index 146a77fb762d..853bc7fc673f 100644
--- a/drivers/acpi/acpi_configfs.c
+++ b/drivers/acpi/acpi_configfs.c
@@ -15,11 +15,15 @@
#include
#include
+#include "acpica/accommon.h"
+#include "acpica/actables.h"
+
static struct config_group *acpi_table_group;
struct acpi_table {
struct config_item cfg;
struct acpi_table_header *header;
+ u32 index;
};
static ssize_t acpi_table_aml_write(struct config_item *cfg,
@@ -52,7 +56,11 @@ static ssize_t acpi_table_aml_write(struct config_item *cfg,
if (!table->header)
return -ENOMEM;
- ret = acpi_load_table(table->header);
+ ACPI_INFO(("Host-directed Dynamic ACPI Table Load:"));
+ ret = acpi_tb_install_and_load_table(
+ ACPI_PTR_TO_PHYSADDR(table->header),
+ ACPI_TABLE_ORIGIN_EXTERNAL_VIRTUAL, FALSE,
+ &table->index);
if (ret) {
kfree(table->header);
table->header = NULL;
@@ -215,8 +223,18 @@ static struct config_item *acpi_table_make_item(struct
config_group *group,
return &table->cfg;
}
+static void acpi_table_drop_item(struct config_group *group,
+struct config_item *cfg)
+{
+ struct acpi_table *table = container_of(cfg, struct acpi_table, cfg);
+
+ ACPI_INFO(("Host-directed Dynamic ACPI Table Unload"));
+ acpi_tb_unload_table(table->index);
+}
+
struct configfs_group_operations acpi_table_group_ops = {
.make_item = acpi_table_make_item,
+ .drop_item = acpi_table_drop_item,
};
static struct config_item_type acpi_tables_type = {
[PATCH 1/3] regmap: Add 1-Wire bus support
Add basic support regmap (register map access) API for 1-Wire bus
---
drivers/base/regmap/Kconfig | 6 +-
drivers/base/regmap/Makefile| 1 +
drivers/base/regmap/regmap-w1.c | 245
include/linux/regmap.h | 34 ++
4 files changed, 285 insertions(+), 1 deletion(-)
create mode 100644 drivers/base/regmap/regmap-w1.c
diff --git a/drivers/base/regmap/Kconfig b/drivers/base/regmap/Kconfig
index db9d00c36a..413af5f940 100644
--- a/drivers/base/regmap/Kconfig
+++ b/drivers/base/regmap/Kconfig
@@ -3,7 +3,7 @@
# subsystems should select the appropriate symbols.
config REGMAP
- default y if (REGMAP_I2C || REGMAP_SPI || REGMAP_SPMI || REGMAP_AC97 ||
REGMAP_MMIO || REGMAP_IRQ)
+ default y if (REGMAP_I2C || REGMAP_SPI || REGMAP_SPMI || REGMAP_W1 ||
REGMAP_AC97 || REGMAP_MMIO || REGMAP_IRQ)
select LZO_COMPRESS
select LZO_DECOMPRESS
select IRQ_DOMAIN if REGMAP_IRQ
@@ -24,6 +24,10 @@ config REGMAP_SPMI
tristate
depends on SPMI
+config REGMAP_W1
+ tristate
+ depends on W1
+
config REGMAP_MMIO
tristate
diff --git a/drivers/base/regmap/Makefile b/drivers/base/regmap/Makefile
index 609e4c84f4..17741ae14e 100644
--- a/drivers/base/regmap/Makefile
+++ b/drivers/base/regmap/Makefile
@@ -10,3 +10,4 @@ obj-$(CONFIG_REGMAP_SPI) += regmap-spi.o
obj-$(CONFIG_REGMAP_SPMI) += regmap-spmi.o
obj-$(CONFIG_REGMAP_MMIO) += regmap-mmio.o
obj-$(CONFIG_REGMAP_IRQ) += regmap-irq.o
+obj-$(CONFIG_REGMAP_W1) += regmap-w1.o
diff --git a/drivers/base/regmap/regmap-w1.c b/drivers/base/regmap/regmap-w1.c
new file mode 100644
index 00..5f04e7bf06
--- /dev/null
+++ b/drivers/base/regmap/regmap-w1.c
@@ -0,0 +1,245 @@
+/*
+ * Register map access API - W1 (1-Wire) support
+ *
+ * Copyright (C) 2017 OAO Radioavionica
+ * Author: Alex A. Mihaylov
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation
+ */
+
+#include
+#include
+#include "../../w1/w1.h"
+
+#include "internal.h"
+
+#define W1_CMD_READ_DATA 0x69
+#define W1_CMD_WRITE_DATA 0x6C
+
+/*
+ * 1-Wire slaves registers with addess 8 bit and data 8 bit
+ */
+
+static int w1_reg_a8_v8_read(void *context, unsigned int reg, unsigned int
*val)
+{
+ struct device *dev = context;
+ struct w1_slave *sl = container_of(dev, struct w1_slave, dev);
+ int ret = 0;
+
+ if (reg > 255)
+ return -EINVAL;
+
+ mutex_lock(&sl->master->bus_mutex);
+ if (!w1_reset_select_slave(sl)) {
+ w1_write_8(sl->master, W1_CMD_READ_DATA);
+ w1_write_8(sl->master, reg);
+ *val = w1_read_8(sl->master);
+ } else {
+ ret = -ENODEV;
+ }
+ mutex_unlock(&sl->master->bus_mutex);
+
+ return ret;
+}
+
+static int w1_reg_a8_v8_write(void *context, unsigned int reg, unsigned int
val)
+{
+ struct device *dev = context;
+ struct w1_slave *sl = container_of(dev, struct w1_slave, dev);
+ int ret = 0;
+
+ if (reg > 255)
+ return -EINVAL;
+
+ mutex_lock(&sl->master->bus_mutex);
+ if (!w1_reset_select_slave(sl)) {
+ w1_write_8(sl->master, W1_CMD_WRITE_DATA);
+ w1_write_8(sl->master, reg);
+ w1_write_8(sl->master, val);
+ } else {
+ ret = -ENODEV;
+ }
+ mutex_unlock(&sl->master->bus_mutex);
+
+ return ret;
+}
+
+/*
+ * 1-Wire slaves registers with addess 8 bit and data 16 bit
+ */
+
+static int w1_reg_a8_v16_read(void *context, unsigned int reg,
+ unsigned int *val)
+{
+ struct device *dev = context;
+ struct w1_slave *sl = container_of(dev, struct w1_slave, dev);
+ int ret = 0;
+
+ if (reg > 255)
+ return -EINVAL;
+
+ mutex_lock(&sl->master->bus_mutex);
+ if (!w1_reset_select_slave(sl)) {
+ w1_write_8(sl->master, W1_CMD_READ_DATA);
+ w1_write_8(sl->master, reg);
+ *val = w1_read_8(sl->master);
+ *val |= w1_read_8(sl->master)<<8;
+ } else {
+ ret = -ENODEV;
+ }
+ mutex_unlock(&sl->master->bus_mutex);
+
+ return ret;
+}
+
+static int w1_reg_a8_v16_write(void *context, unsigned int reg,
+ unsigned int val)
+{
+ struct device *dev = context;
+ struct w1_slave *sl = container_of(dev, struct w1_slave, dev);
+ int ret = 0;
+
+ if (reg > 255)
+ return -EINVAL;
+
+ mutex_lock(&sl->master->bus_mutex);
+ if (!w1_reset_select_slave(sl)) {
+ w1_write_8(sl->master, W1_CMD_WRITE_DATA);
+ w1_write_8(sl->master, reg);
+ w1_write_8(sl->master, val & 0x00FF);
+ w1_write_8(sl->master, val>>8 & 0x00FF);
+
[PATCH 2/3] w1: MAX1721x Stanalone Fuel Gauge - add 1-Wire slave drivers
Add support for Maxim Semiconductor MAX17211/MAX17215
Standlone Fuel Gauge chips (1-Wire family 0x26)
---
drivers/w1/slaves/Kconfig | 12 +
drivers/w1/slaves/Makefile | 1 +
drivers/w1/slaves/w1_max1721x.c | 73
drivers/w1/slaves/w1_max1721x.h | 102
drivers/w1/w1_family.h | 1 +
5 files changed, 189 insertions(+)
create mode 100644 drivers/w1/slaves/w1_max1721x.c
create mode 100644 drivers/w1/slaves/w1_max1721x.h
diff --git a/drivers/w1/slaves/Kconfig b/drivers/w1/slaves/Kconfig
index 0ef9f2663d..06a63a1021 100644
--- a/drivers/w1/slaves/Kconfig
+++ b/drivers/w1/slaves/Kconfig
@@ -86,6 +86,18 @@ config W1_SLAVE_DS2433_CRC
Each block has 30 bytes of data and a two byte CRC16.
Full block writes are only allowed if the CRC is valid.
+config W1_SLAVE_MAX1721X
+ tristate "Maxim MAX17211/MAX17215 battery monitor chip"
+ help
+ If you enable this you will have the MAX17211/MAX17215 battery
+ monitor chip support.
+
+ The battery monitor chip is used in many batteries/devices
+ as the one who is responsible for charging/discharging/monitoring
+ Li+ batteries.
+
+ If you are unsure, say N.
+
config W1_SLAVE_DS2760
tristate "Dallas 2760 battery monitor chip (HP iPAQ & others)"
help
diff --git a/drivers/w1/slaves/Makefile b/drivers/w1/slaves/Makefile
index b4a358955e..967329a4b8 100644
--- a/drivers/w1/slaves/Makefile
+++ b/drivers/w1/slaves/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_W1_SLAVE_DS2406) += w1_ds2406.o
obj-$(CONFIG_W1_SLAVE_DS2423) += w1_ds2423.o
obj-$(CONFIG_W1_SLAVE_DS2431) += w1_ds2431.o
obj-$(CONFIG_W1_SLAVE_DS2433) += w1_ds2433.o
+obj-$(CONFIG_W1_SLAVE_MAX1721X)+= w1_max1721x.o
obj-$(CONFIG_W1_SLAVE_DS2760) += w1_ds2760.o
obj-$(CONFIG_W1_SLAVE_DS2780) += w1_ds2780.o
obj-$(CONFIG_W1_SLAVE_DS2781) += w1_ds2781.o
diff --git a/drivers/w1/slaves/w1_max1721x.c b/drivers/w1/slaves/w1_max1721x.c
new file mode 100644
index 00..017ec3e159
--- /dev/null
+++ b/drivers/w1/slaves/w1_max1721x.c
@@ -0,0 +1,73 @@
+/*
+ * 1-Wire implementation for Maxim Semiconductor
+ * MAX17211/MAX17215 standalone fuel gauge chip
+ *
+ * Copyright (C) 2017 OAO Radioavionica
+ * Author: Alex A. Mihaylov
+ *
+ * Use consistent with the GNU GPL is permitted,
+ * provided that this copyright notice is
+ * preserved in its entirety in all copies and derived works.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "../w1.h"
+#include "../w1_int.h"
+#include "../w1_family.h"
+#include "w1_max1721x.h"
+
+static int w1_max17211_add_device(struct w1_slave *sl)
+{
+ int ret;
+ struct platform_device *pdev;
+
+ pdev = platform_device_alloc("max1721x-battery", PLATFORM_DEVID_AUTO);
+ if (!pdev)
+ return -ENOMEM;
+ pdev->dev.parent = &sl->dev;
+
+ ret = platform_device_add(pdev);
+ if (ret)
+ goto pdev_add_failed;
+
+ dev_set_drvdata(&sl->dev, pdev);
+
+ return 0;
+
+pdev_add_failed:
+ platform_device_put(pdev);
+
+ return ret;
+}
+
+static void w1_max17211_remove_device(struct w1_slave *sl)
+{
+ struct platform_device *pdev = dev_get_drvdata(&sl->dev);
+
+ platform_device_unregister(pdev);
+}
+
+static struct w1_family_ops w1_max17211_fops = {
+ .add_slave= w1_max17211_add_device,
+ .remove_slave = w1_max17211_remove_device,
+};
+
+static struct w1_family w1_max17211_family = {
+ .fid = W1_FAMILY_MAX17211,
+ .fops = &w1_max17211_fops,
+};
+module_w1_family(w1_max17211_family);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Alex A. Mihaylov ");
+MODULE_DESCRIPTION("1-wire Driver for MAX17211/MAX17215 battery monitor");
+MODULE_ALIAS("w1-family-" __stringify(W1_FAMILY_MAX17211));
diff --git a/drivers/w1/slaves/w1_max1721x.h b/drivers/w1/slaves/w1_max1721x.h
new file mode 100644
index 00..47694d91dc
--- /dev/null
+++ b/drivers/w1/slaves/w1_max1721x.h
@@ -0,0 +1,102 @@
+/*
+ * 1-Wire implementation for Maxim Semiconductor
+ * MAX7211/MAX17215 stanalone fuel gauge chip
+ *
+ * Copyright (C) 2017 OAO Radioavionica
+ * Author: Alex A. Mihaylov
+ *
+ * Use consistent with the GNU GPL is permitted,
+ * provided that this copyright notice is
+ * preserved in its entirety in all copies and derived works.
+ *
+ */
+
+#ifndef __w1_max17211_h__
+#define __w1_max17211_h__
+
+/* Known commands to the MAX1721X chip */
+#define W1_MAX1721X_READ_DATA 0x69
+#define W1_MAX1721X_WRITE_DATA 0x6C
+
+/* Factory settings (nonvilatile registers) (W1 specific) */
+
+#define MAX1721X_REG_NRSENSE 0x1CF /* RSense in 10^-5 Ohm */
+/* Strings */
+#define MAX1721X_REG_MFG_STR 0x1CC
+#define MAX1721X_REG_MFG_NUMB 3
+#define MAX1721X_REG_DEV_STR 0x1DB
+#define MAX1721X_REG_DEV_NUMB 5
+/* HEX Strings */
+#define MAX1721X_REG_SER_HEX
Re: [musl] Re: [PATCH resent] uapi libc compat: allow non-glibc to opt out of uapi definitions
On 04/25/2017 02:29 PM, Carlos O'Donell wrote: > In glibc right now we support including linux or glibc header files first, > and this has always been a requirement from the start. This requirement > dictates > that the kernel know which libc it's being used with so it can tailor > coordination. “right now we support” is not a support commitment, but more of an aspiration, right? A lot of combinations are broken, especially when kernel headers are included first. Maybe it's time for us to admit defeat and come up with a simpler scheme which actually works. Thanks, Florian
Re: [PATCH] uapi/linux/a.out.h: don't use deprecated system-specific predefines.
> /* Address of data segment in memory after it is loaded.
> Note that it is up to you to define SEGMENT_SIZE
> on machines not listed here. */
> -#if defined(vax) || defined(hp300) || defined(pyr)
> +#if defined(__vax__) || defined(__hp300__) || defined(__pyr__)
> #define SEGMENT_SIZE page_size
> #endif
> -#ifdef sony
> +#ifdef __sony__
> #define SEGMENT_SIZE0x2000
> #endif /* Sony. */
> -#ifdef is68k
> +#ifdef __is68k__
> #define SEGMENT_SIZE 0x2
> #endif
> -#if defined(m68k) && defined(PORTAR)
> +#if defined(__m68k__) && defined(__PORTAR__)
> #define PAGE_SIZE 0x400
> #define SEGMENT_SIZE PAGE_SIZE
> #endif
Can we please fix these conditionals so that only those
relevant to Linux remain? e.g. something like the patch below:
diff --git a/include/uapi/linux/a.out.h b/include/uapi/linux/a.out.h
index 7caf44c7fa51..295cd3ef6330 100644
--- a/include/uapi/linux/a.out.h
+++ b/include/uapi/linux/a.out.h
@@ -112,24 +112,7 @@ enum machine_type {
#define N_TXTADDR(x) (N_MAGIC(x) == QMAGIC ? PAGE_SIZE : 0)
#endif
-/* Address of data segment in memory after it is loaded.
- Note that it is up to you to define SEGMENT_SIZE
- on machines not listed here. */
-#if defined(vax) || defined(hp300) || defined(pyr)
-#define SEGMENT_SIZE page_size
-#endif
-#ifdef sony
-#defineSEGMENT_SIZE0x2000
-#endif /* Sony. */
-#ifdef is68k
-#define SEGMENT_SIZE 0x2
-#endif
-#if defined(m68k) && defined(PORTAR)
-#define PAGE_SIZE 0x400
-#define SEGMENT_SIZE PAGE_SIZE
-#endif
-
-#ifdef linux
+/* Address of data segment in memory after it is loaded. */
#ifndef __KERNEL__
#include
#endif
@@ -142,7 +125,6 @@ enum machine_type {
#endif
#endif
#endif
-#endif
#define _N_SEGMENT_ROUND(x) ALIGN(x, SEGMENT_SIZE)
@@ -260,13 +242,7 @@ struct relocation_info
unsigned int r_extern:1;
/* Four bits that aren't used, but when writing an object file
it is desirable to clear them. */
-#ifdef NS32K
- unsigned r_bsr:1;
- unsigned r_disp:1;
- unsigned r_pad:2;
-#else
unsigned int r_pad:4;
-#endif
};
#endif /* no N_RELOCATION_INFO_DECLARED. */
Re: [PATCH RFC 1/2] s390x: mm: allow mixed page table types (2k and 4k)
On 06/01/2017 02:59 PM, David Hildenbrand wrote:
>
>> diff --git a/arch/s390/mm/pgtable.c b/arch/s390/mm/pgtable.c
>> index d4d409b..b22c2b6 100644
>> --- a/arch/s390/mm/pgtable.c
>> +++ b/arch/s390/mm/pgtable.c
>> @@ -196,7 +196,7 @@ static inline pgste_t ptep_xchg_start(struct mm_struct
>> *mm,
>> {
>> pgste_t pgste = __pgste(0);
>>
>> -if (mm_has_pgste(mm)) {
>> +if (pgtable_has_pgste(mm, __pa(ptep))) {
>> pgste = pgste_get_lock(ptep);
>> pgste = pgste_pte_notify(mm, addr, ptep, pgste);
>> }
>> @@ -207,7 +207,7 @@ static inline pte_t ptep_xchg_commit(struct mm_struct
>> *mm,
>> unsigned long addr, pte_t *ptep,
>> pgste_t pgste, pte_t old, pte_t new)
>> {
>> -if (mm_has_pgste(mm)) {
>> +if (pgtable_has_pgste(mm, __pa(ptep))) {
>> if (pte_val(old) & _PAGE_INVALID)
>> pgste_set_key(ptep, pgste, new, mm);
>> if (pte_val(new) & _PAGE_INVALID)
>
> I think these two checks are wrong. We really have to test here the
> mapcount bit only (relying on mm_has_pgste(mm) is wrong in case global
> vm.allocate_pgste ist set).
>
> But before I continue working on this, I think it makes sense to clarify
> if something like that would be acceptable at all.
I think that is up to Martin to decide. Given the fact that Fedora, SUSE,
Ubuntu always
enable this sysctl when the qemu package is installed (other distros as well?)
I think
that we should really think about changing things. I see 2 options:
1. dropping 2k page tables completely
pro:- simplifies pagetable code (e.g. look at page_table_alloc code)
- we could get rid of a lock in the pgtable allocation path
(mm->context.pgtable_lock)
- I am not aware of any performance impact due to the 4k page tables
- transparent for old QEMUs
- KVM will work out of the box
con:- higher page table memory usage for non-KVM processes
2. go with your approach
pro:- lower page table memory usage for non-KVM processes
- KVM will work out of the box
- no addtl overhead for non-KVM processes
con:- higher overhead for KVM processes during paging (since we are going
to use IPTE
or friends anyway, the question is: does it matter?)
- needs QEMU change
Christian
Re: [PATCH] drm/vc4: Mark the device as active when enabling runtime PM.
On Mon, 15 May 2017 10:16:15 -0700
Eric Anholt wrote:
> Failing to do so meant that we got a resume() callback on first use of
> the device, so we would leak the bin BO that we allocated during
> probe.
>
> Signed-off-by: Eric Anholt
> Fixes: 553c942f8b2c ("drm/vc4: Allow using more than 256MB of CMA memory.")
Reviewed-by: Boris Brezillon
> ---
> drivers/gpu/drm/vc4/vc4_v3d.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_v3d.c b/drivers/gpu/drm/vc4/vc4_v3d.c
> index e3d5c59dbd4a..825a8462a63b 100644
> --- a/drivers/gpu/drm/vc4/vc4_v3d.c
> +++ b/drivers/gpu/drm/vc4/vc4_v3d.c
> @@ -403,6 +403,7 @@ static int vc4_v3d_bind(struct device *dev, struct device
> *master, void *data)
> return ret;
> }
>
> + pm_runtime_set_active(dev);
> pm_runtime_use_autosuspend(dev);
> pm_runtime_set_autosuspend_delay(dev, 40); /* a little over 2 frames. */
> pm_runtime_enable(dev);
Re: [PATCH V1 12/15] spmi-pmic-arb: fix a possible null pointer dereference
On 2017-05-31 22:59, Stephen Boyd wrote:
On 05/30, Kiran Gunda wrote:
diff --git a/drivers/spmi/spmi-pmic-arb.c
b/drivers/spmi/spmi-pmic-arb.c
index 2afe359..412481d 100644
--- a/drivers/spmi/spmi-pmic-arb.c
+++ b/drivers/spmi/spmi-pmic-arb.c
@@ -1003,6 +1003,12 @@ static int spmi_pmic_arb_probe(struct
platform_device *pdev)
pa->spmic = ctrl;
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "core");
+ if (!res) {
+ dev_err(&pdev->dev, "core resource not specified\n");
+ err = -EINVAL;
+ goto err_put_ctrl;
+ }
+
pa->core_size = resource_size(res);
if (pa->core_size <= 0x800) {
dev_err(&pdev->dev, "core_size is smaller than 0x800. Failing
Probe\n");
I would prefer this patch instead, so that we can piggyback on
the error checking of the devm_ioremap_resource() code. Also, add
a Fixes: tag please so we can backport it as needed.
Sure. We will modify as per your suggestion in the next patch.
diff --git a/drivers/spmi/spmi-pmic-arb.c
b/drivers/spmi/spmi-pmic-arb.c
index 5ec3a595dc7d..0cedbda60707 100644
--- a/drivers/spmi/spmi-pmic-arb.c
+++ b/drivers/spmi/spmi-pmic-arb.c
@@ -878,12 +878,12 @@ static int spmi_pmic_arb_probe(struct
platform_device *pdev)
pa->spmic = ctrl;
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "core");
- pa->core_size = resource_size(res);
core = devm_ioremap_resource(&ctrl->dev, res);
if (IS_ERR(core)) {
err = PTR_ERR(core);
goto err_put_ctrl;
}
+ pa->core_size = resource_size(res);
hw_ver = readl_relaxed(core + PMIC_ARB_VERSION);
is_v1 = (hw_ver < PMIC_ARB_VERSION_V2_MIN);
Re: [PATCH RFC 0/2] KVM: s390: avoid having to enable vm.alloc_pgste
On 06/02/2017 09:02 AM, Heiko Carstens wrote: > On Thu, Jun 01, 2017 at 12:46:51PM +0200, Martin Schwidefsky wrote: >>> Unfortunately, converting all page tables to 4k pgste page tables is >>> not possible without provoking various race conditions. >> >> That is one approach we tried and was found to be buggy. The point is that >> you are not allowed to reallocate a page table while a VMA exists that is >> in the address range of that page table. >> >> Another approach we tried is to use an ELF flag on the qemu executable. >> That does not work either because fs/exec.c allocates and populates the >> new mm struct for the argument pages before fs/binfmt_elf.c comes into >> play. > > How about if you would fail the system call within arch_check_elf() if you > detect that the binary requires pgstes (as indicated by elf flags) and then > restart the system call? > > That is: arch_check_elf() e.g. would set a thread flag that future mm's > should be allocated with pgstes. Then do_execve() would cleanup everything > and return to entry.S. Upon return to userspace we detect this condition > and simply restart the system call, similar to signals vs -ERESTARTSYS. > > That would make do_execve() cleanup everything and upon reentering it would > allocate an mm with the pgste flag set. > > Maybe this is a bit over-simplified, but might work. > > At least I also don't like the next "hack", that is specifically designed > to only work with how QEMU is currently implemented. It might break with > future QEMU changes or the next user space implementation that drives the > kvm interface, but is doing everything differently. > Let's look for a "clean" solution that will always work. We had too many > hacks for this problem and *all* of them were broken. The more I think about it, dropping 2k page tables and always allocate a full page would simplify pgalloc. As far I can see this would also get rid of the &mm->context.pgtable_lock.
Re: [PATCH RFC 0/2] KVM: s390: avoid having to enable vm.alloc_pgste
On Fri, 2 Jun 2017 09:13:03 +0200 Christian Borntraeger wrote: > On 06/02/2017 09:02 AM, Heiko Carstens wrote: > > On Thu, Jun 01, 2017 at 12:46:51PM +0200, Martin Schwidefsky wrote: > >>> Unfortunately, converting all page tables to 4k pgste page tables is > >>> not possible without provoking various race conditions. > >> > >> That is one approach we tried and was found to be buggy. The point is that > >> you are not allowed to reallocate a page table while a VMA exists that is > >> in the address range of that page table. > >> > >> Another approach we tried is to use an ELF flag on the qemu executable. > >> That does not work either because fs/exec.c allocates and populates the > >> new mm struct for the argument pages before fs/binfmt_elf.c comes into > >> play. > > > > How about if you would fail the system call within arch_check_elf() if you > > detect that the binary requires pgstes (as indicated by elf flags) and then > > restart the system call? > > > > That is: arch_check_elf() e.g. would set a thread flag that future mm's > > should be allocated with pgstes. Then do_execve() would cleanup everything > > and return to entry.S. Upon return to userspace we detect this condition > > and simply restart the system call, similar to signals vs -ERESTARTSYS. > > > > That would make do_execve() cleanup everything and upon reentering it would > > allocate an mm with the pgste flag set. > > > > Maybe this is a bit over-simplified, but might work. > > > > At least I also don't like the next "hack", that is specifically designed > > to only work with how QEMU is currently implemented. It might break with > > future QEMU changes or the next user space implementation that drives the > > kvm interface, but is doing everything differently. > > Let's look for a "clean" solution that will always work. We had too many > > hacks for this problem and *all* of them were broken. > > > The more I think about it, dropping 2k page tables and always allocate a full > page would simplify pgalloc. As far I can see this would also get rid of > the &mm->context.pgtable_lock. And it would waste twice the amount of memory for page tables. NAK. -- blue skies, Martin. "Reality continues to ruin my life." - Calvin.
Re: [PATCH 1/9] mm: introduce kv[mz]alloc helpers
On Mon, Mar 06, 2017 at 11:30:24AM +0100, Michal Hocko wrote:
> +void *kvmalloc_node(size_t size, gfp_t flags, int node)
> +{
> + gfp_t kmalloc_flags = flags;
> + void *ret;
> +
> + /*
> + * vmalloc uses GFP_KERNEL for some internal allocations (e.g page
> tables)
> + * so the given set of flags has to be compatible.
> + */
> + WARN_ON_ONCE((flags & GFP_KERNEL) != GFP_KERNEL);
Hm, there are quite a few locations in the kernel that do something like:
__vmalloc(len, GFP_NOFS, PAGE_KERNEL);
According to your patch, vmalloc can't really do GFP_NOFS, right?
--
Thanks,
Sasha
[PATCH 0/3] add mt7622 spi support
This series are based on 4.12-rc1 and provide 4 patches to support mt7622 IC. Change in this series: 1. update document to add mt7622; 2. add adjust register define support; 3. add mt7622_compat. Leilk Liu (3): dt-bindings: spi: mediatek: Add bindings for mediatek MT7622 soc platform spi: mediatek: support adjust register define spi: mediatek: add spi support for mt7622 IC .../devicetree/bindings/spi/spi-mt65xx.txt |1 + drivers/spi/spi-mt65xx.c | 54 ++-- include/linux/platform_data/spi-mt65xx.h |2 + 3 files changed, 52 insertions(+), 5 deletions(-) -- 1.7.9.5
[PATCH 3/3] spi: mediatek: add compatible support for mt7622 IC
this patch add compatible support for mt7622 IC.
Signed-off-by: Leilk Liu
---
drivers/spi/spi-mt65xx.c |9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/spi/spi-mt65xx.c b/drivers/spi/spi-mt65xx.c
index 3d7cd2d..ebc4b1a 100644
--- a/drivers/spi/spi-mt65xx.c
+++ b/drivers/spi/spi-mt65xx.c
@@ -104,6 +104,12 @@ struct mtk_spi {
};
static const struct mtk_spi_compatible mtk_common_compat;
+
+static const struct mtk_spi_compatible mt7622_compat = {
+ .must_tx = true,
+ .adjust_reg = true,
+};
+
static const struct mtk_spi_compatible mt8173_compat = {
.need_pad_sel = true,
.must_tx = true,
@@ -127,6 +133,9 @@ struct mtk_spi {
{ .compatible = "mediatek,mt6589-spi",
.data = (void *)&mtk_common_compat,
},
+ { .compatible = "mediatek,mt7622-spi",
+ .data = (void *)&mt7622_compat,
+ },
{ .compatible = "mediatek,mt8135-spi",
.data = (void *)&mtk_common_compat,
},
--
1.7.9.5
[PATCH 2/3] spi: mediatek: support adjust register define
this patch adds support for adjust register design.
Signed-off-by: Leilk Liu
---
drivers/spi/spi-mt65xx.c | 45 ++
include/linux/platform_data/spi-mt65xx.h |2 ++
2 files changed, 42 insertions(+), 5 deletions(-)
diff --git a/drivers/spi/spi-mt65xx.c b/drivers/spi/spi-mt65xx.c
index 278867a..3d7cd2d 100644
--- a/drivers/spi/spi-mt65xx.c
+++ b/drivers/spi/spi-mt65xx.c
@@ -35,11 +35,15 @@
#define SPI_CMD_REG 0x0018
#define SPI_STATUS0_REG 0x001c
#define SPI_PAD_SEL_REG 0x0024
+#define SPI_CFG2_REG 0x0028
#define SPI_CFG0_SCK_HIGH_OFFSET 0
#define SPI_CFG0_SCK_LOW_OFFSET 8
#define SPI_CFG0_CS_HOLD_OFFSET 16
#define SPI_CFG0_CS_SETUP_OFFSET 24
+#define SPI_ADJUST_CFG0_SCK_LOW_OFFSET16
+#define SPI_ADJUST_CFG0_CS_HOLD_OFFSET0
+#define SPI_ADJUST_CFG0_CS_SETUP_OFFSET 16
#define SPI_CFG1_CS_IDLE_OFFSET 0
#define SPI_CFG1_PACKET_LOOP_OFFSET 8
@@ -55,6 +59,8 @@
#define SPI_CMD_RST BIT(2)
#define SPI_CMD_PAUSE_EN BIT(4)
#define SPI_CMD_DEASSERT BIT(5)
+#define SPI_CMD_SAMPLE_SEL BIT(6)
+#define SPI_CMD_CS_POL BIT(7)
#define SPI_CMD_CPHA BIT(8)
#define SPI_CMD_CPOL BIT(9)
#define SPI_CMD_RX_DMA BIT(10)
@@ -80,6 +86,8 @@ struct mtk_spi_compatible {
bool need_pad_sel;
/* Must explicitly send dummy Tx bytes to do Rx only transfer */
bool must_tx;
+ /* some IC design adjust register define */
+ bool adjust_reg;
};
struct mtk_spi {
@@ -108,6 +116,8 @@ struct mtk_spi {
static const struct mtk_chip_config mtk_default_chip_info = {
.rx_mlsb = 1,
.tx_mlsb = 1,
+ .cs_pol = 0,
+ .sample_sel = 0,
};
static const struct of_device_id mtk_spi_of_match[] = {
@@ -182,6 +192,17 @@ static int mtk_spi_prepare_message(struct spi_master
*master,
reg_val |= SPI_CMD_RX_ENDIAN;
#endif
+ if (mdata->dev_comp->adjust_reg) {
+ if (chip_config->cs_pol)
+ reg_val |= SPI_CMD_CS_POL;
+ else
+ reg_val &= ~SPI_CMD_CS_POL;
+ if (chip_config->sample_sel)
+ reg_val |= SPI_CMD_SAMPLE_SEL;
+ else
+ reg_val &= ~SPI_CMD_SAMPLE_SEL;
+ }
+
/* set finish and pause interrupt always enable */
reg_val |= SPI_CMD_FINISH_IE | SPI_CMD_PAUSE_IE;
@@ -233,11 +254,25 @@ static void mtk_spi_prepare_transfer(struct spi_master
*master,
sck_time = (div + 1) / 2;
cs_time = sck_time * 2;
- reg_val |= (((sck_time - 1) & 0xff) << SPI_CFG0_SCK_HIGH_OFFSET);
- reg_val |= (((sck_time - 1) & 0xff) << SPI_CFG0_SCK_LOW_OFFSET);
- reg_val |= (((cs_time - 1) & 0xff) << SPI_CFG0_CS_HOLD_OFFSET);
- reg_val |= (((cs_time - 1) & 0xff) << SPI_CFG0_CS_SETUP_OFFSET);
- writel(reg_val, mdata->base + SPI_CFG0_REG);
+ if (mdata->dev_comp->adjust_reg) {
+ reg_val |= (((sck_time - 1) & 0x)
+ << SPI_CFG0_SCK_HIGH_OFFSET);
+ reg_val |= (((sck_time - 1) & 0x)
+ << SPI_ADJUST_CFG0_SCK_LOW_OFFSET);
+ writel(reg_val, mdata->base + SPI_CFG2_REG);
+ reg_val |= (((cs_time - 1) & 0x)
+ << SPI_ADJUST_CFG0_CS_HOLD_OFFSET);
+ reg_val |= (((cs_time - 1) & 0x)
+ << SPI_ADJUST_CFG0_CS_SETUP_OFFSET);
+ writel(reg_val, mdata->base + SPI_CFG0_REG);
+ } else {
+ reg_val |= (((sck_time - 1) & 0xff)
+ << SPI_CFG0_SCK_HIGH_OFFSET);
+ reg_val |= (((sck_time - 1) & 0xff) << SPI_CFG0_SCK_LOW_OFFSET);
+ reg_val |= (((cs_time - 1) & 0xff) << SPI_CFG0_CS_HOLD_OFFSET);
+ reg_val |= (((cs_time - 1) & 0xff) << SPI_CFG0_CS_SETUP_OFFSET);
+ writel(reg_val, mdata->base + SPI_CFG0_REG);
+ }
reg_val = readl(mdata->base + SPI_CFG1_REG);
reg_val &= ~SPI_CFG1_CS_IDLE_MASK;
diff --git a/include/linux/platform_data/spi-mt65xx.h
b/include/linux/platform_data/spi-mt65xx.h
index 54b0448..ba4e4bb 100644
--- a/include/linux/platform_data/spi-mt65xx.h
+++ b/include/linux/platform_data/spi-mt65xx.h
@@ -16,5 +16,7 @@
struct mtk_chip_config {
u32 tx_mlsb;
u32 rx_mlsb;
+ u32 cs_pol;
+ u32 sample_sel;
};
#endif
--
1.7.9.5
[PATCH 1/3] dt-bindings: spi: mediatek: Add bindings for mediatek MT7622 soc platform
This patch adds a DT binding documentation for the MT7622 soc. Signed-off-by: Leilk Liu --- .../devicetree/bindings/spi/spi-mt65xx.txt |1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/spi/spi-mt65xx.txt b/Documentation/devicetree/bindings/spi/spi-mt65xx.txt index e43f4cf..c0b1f01 100644 --- a/Documentation/devicetree/bindings/spi/spi-mt65xx.txt +++ b/Documentation/devicetree/bindings/spi/spi-mt65xx.txt @@ -4,6 +4,7 @@ Required properties: - compatible: should be one of the following. - mediatek,mt2701-spi: for mt2701 platforms - mediatek,mt6589-spi: for mt6589 platforms +- mediatek,mt7622-spi: for mt7622 platforms - mediatek,mt8135-spi: for mt8135 platforms - mediatek,mt8173-spi: for mt8173 platforms -- 1.7.9.5
Re: [PATCH RFC 0/2] KVM: s390: avoid having to enable vm.alloc_pgste
On 06/02/2017 09:16 AM, Martin Schwidefsky wrote: > On Fri, 2 Jun 2017 09:13:03 +0200 > Christian Borntraeger wrote: > >> On 06/02/2017 09:02 AM, Heiko Carstens wrote: >>> On Thu, Jun 01, 2017 at 12:46:51PM +0200, Martin Schwidefsky wrote: > Unfortunately, converting all page tables to 4k pgste page tables is > not possible without provoking various race conditions. That is one approach we tried and was found to be buggy. The point is that you are not allowed to reallocate a page table while a VMA exists that is in the address range of that page table. Another approach we tried is to use an ELF flag on the qemu executable. That does not work either because fs/exec.c allocates and populates the new mm struct for the argument pages before fs/binfmt_elf.c comes into play. >>> >>> How about if you would fail the system call within arch_check_elf() if you >>> detect that the binary requires pgstes (as indicated by elf flags) and then >>> restart the system call? >>> >>> That is: arch_check_elf() e.g. would set a thread flag that future mm's >>> should be allocated with pgstes. Then do_execve() would cleanup everything >>> and return to entry.S. Upon return to userspace we detect this condition >>> and simply restart the system call, similar to signals vs -ERESTARTSYS. >>> >>> That would make do_execve() cleanup everything and upon reentering it would >>> allocate an mm with the pgste flag set. >>> >>> Maybe this is a bit over-simplified, but might work. >>> >>> At least I also don't like the next "hack", that is specifically designed >>> to only work with how QEMU is currently implemented. It might break with >>> future QEMU changes or the next user space implementation that drives the >>> kvm interface, but is doing everything differently. >>> Let's look for a "clean" solution that will always work. We had too many >>> hacks for this problem and *all* of them were broken. >> >> >> The more I think about it, dropping 2k page tables and always allocate a full >> page would simplify pgalloc. As far I can see this would also get rid of >> the &mm->context.pgtable_lock. > > And it would waste twice the amount of memory for page tables. NAK. Yes and we spend the same amount of memory TODAY, because every distro on the planet that uses KVM has sysctl.allocate_pgste set.
Re: [WIP PATCH 0/4] Rework the unreliable LID switch exported by ACPI
On Jun 01 2017 or thereabouts, Bastien Nocera wrote: > On Thu, 2017-06-01 at 20:46 +0200, Benjamin Tissoires wrote: > > Hi, > > > > Sending this as a WIP as it still need a few changes, but it mostly > > works as > > expected (still not fully compliant yet). > > > > So this is based on Lennart's comment in [1]: if the LID state is not > > reliable, > > the kernel should not export the LID switch device as long as we are > > not sure > > about its state. > > > > That is the basic idea, and here are some more general comments: > > Lv described the 5 cases in "RFC PATCH v3" regarding the LID switch. > > Let me rewrite them here (they are in patch 2): > > > > 1. Some platforms send "open" ACPI notification to the OS and the > > event > >arrive before the button driver is resumed; > > 2. Some platforms send "open" ACPI notification to the OS, but the > > event > >arrives after the button driver is resumed, ex., Samsung N210+; > > 3. Some platforms never send an "open" ACPI notification to the OS, > > but > >update the cached _LID return value to "open", and this update > > arrives > >before the button driver is resumed; > > 4. Some platforms never send an "open" ACPI notification to the OS, > > but > >update the cached _LID return value to "open", but this update > > arrives > >after the button driver is resumed, ex., Surface Pro 3; > > 5. Some platforms never send an "open" ACPI notification to the OS, > > and > >_LID ACPI method returns a value which stays to "close", ex., > >Surface Pro 1. > > In which case does the Surface 3 lie? I believe we still needed your > "gpiolib-acpi: make sure we trigger the events at least once" patch to > make that one work. Well, the surface 3 is using a different driver for the LID switch (surface3-wmi). From what I can remember, we don't need this patch when using this driver (which is why I did not submitted it further). But I might be wrong... Cheers, Benjamin
Re: [PATCH RFC 0/2] KVM: s390: avoid having to enable vm.alloc_pgste
On 06/02/2017 09:18 AM, Christian Borntraeger wrote: > On 06/02/2017 09:16 AM, Martin Schwidefsky wrote: >> On Fri, 2 Jun 2017 09:13:03 +0200 >> Christian Borntraeger wrote: >> >>> On 06/02/2017 09:02 AM, Heiko Carstens wrote: On Thu, Jun 01, 2017 at 12:46:51PM +0200, Martin Schwidefsky wrote: >> Unfortunately, converting all page tables to 4k pgste page tables is >> not possible without provoking various race conditions. > > That is one approach we tried and was found to be buggy. The point is that > you are not allowed to reallocate a page table while a VMA exists that is > in the address range of that page table. > > Another approach we tried is to use an ELF flag on the qemu executable. > That does not work either because fs/exec.c allocates and populates the > new mm struct for the argument pages before fs/binfmt_elf.c comes into > play. How about if you would fail the system call within arch_check_elf() if you detect that the binary requires pgstes (as indicated by elf flags) and then restart the system call? That is: arch_check_elf() e.g. would set a thread flag that future mm's should be allocated with pgstes. Then do_execve() would cleanup everything and return to entry.S. Upon return to userspace we detect this condition and simply restart the system call, similar to signals vs -ERESTARTSYS. That would make do_execve() cleanup everything and upon reentering it would allocate an mm with the pgste flag set. Maybe this is a bit over-simplified, but might work. At least I also don't like the next "hack", that is specifically designed to only work with how QEMU is currently implemented. It might break with future QEMU changes or the next user space implementation that drives the kvm interface, but is doing everything differently. Let's look for a "clean" solution that will always work. We had too many hacks for this problem and *all* of them were broken. >>> >>> >>> The more I think about it, dropping 2k page tables and always allocate a >>> full >>> page would simplify pgalloc. As far I can see this would also get rid of >>> the &mm->context.pgtable_lock. >> >> And it would waste twice the amount of memory for page tables. NAK. > > Yes and we spend the same amount of memory TODAY, because every distro on the > planet that uses KVM has sysctl.allocate_pgste set. Maybe todays approach might be still the best. (if qemu is installed, its all 4k, if not its all 2k)
Re: [PATCH V1 14/15] spmi: pmic-arb: do not ack and clear peripheral interrupts in cleanup_irq
On 2017-05-31 23:23, Stephen Boyd wrote: On 05/30, Kiran Gunda wrote: From: Subbaraman Narayanamurthy Currently, cleanup_irq() is invoked when a peripheral's interrupt fires and there is no mapping present in the interrupt domain of spmi interrupt controller. The cleanup_irq clears the arbiter bit, clears the pmic interrupt and disables it at the pmic in that order. The last disable in cleanup_irq races with request_irq() in that it stomps over the enable issued by request_irq. Fix this by not writing to the pmic in cleanup_irq. The latched bit will be left set in the pmic, which will not send us more interrupts even if the enable bit stays enabled. When a client wants to request an interrupt, use the activate callback on the irq_domain to clear latched bit. This ensures that the latched, if set due to the above changes in cleanup_irq or when the bootloader leaves it set, gets cleaned up, paving way for upcoming interrupts to trigger. With this, there is a possibility of unwanted triggering of interrupt right after the latched bit is cleared - the interrupt may be left enabled too. To avoid that, clear the enable first followed by clearing the latched bit in the activate callback. Signed-off-by: Subbaraman Narayanamurthy Signed-off-by: Kiran Gunda Please squash this with the patch that adds cleanup_irq() and rewrite the commit text to combine details from both. Sure. Will squash it in the next patch submission.
Re: [PATCH] PCI: rockchip: Handle return value of clk_prepare_enable
Hi, 在 2017/6/1 18:21, Arvind Yadav 写道: clk_prepare_enable() can fail here and we must check its return value. Signed-off-by: Arvind Yadav Acked-by: Shawn Lin --- drivers/pci/host/pcie-rockchip.c | 34 -- 1 file changed, 28 insertions(+), 6 deletions(-) diff --git a/drivers/pci/host/pcie-rockchip.c b/drivers/pci/host/pcie-rockchip.c index 0e020b6..0a248cd 100644 --- a/drivers/pci/host/pcie-rockchip.c +++ b/drivers/pci/host/pcie-rockchip.c @@ -1259,24 +1259,46 @@ static int __maybe_unused rockchip_pcie_resume_noirq(struct device *dev) struct rockchip_pcie *rockchip = dev_get_drvdata(dev); int err; - clk_prepare_enable(rockchip->clk_pcie_pm); - clk_prepare_enable(rockchip->hclk_pcie); - clk_prepare_enable(rockchip->aclk_perf_pcie); - clk_prepare_enable(rockchip->aclk_pcie); + err = clk_prepare_enable(rockchip->clk_pcie_pm); + if (err) + goto err_pcie_pm; + + err = clk_prepare_enable(rockchip->hclk_pcie); + if (err) + goto err_hclk_pcie; + + err = clk_prepare_enable(rockchip->aclk_perf_pcie); + if (err) + goto err_aclk_perf_pcie; + + err = clk_prepare_enable(rockchip->aclk_pcie); + if (err) + goto err_aclk_pcie; err = rockchip_pcie_init_port(rockchip); if (err) - return err; + goto err_pcie_resume; err = rockchip_cfg_atu(rockchip); if (err) - return err; + goto err_pcie_resume; /* Need this to enter L1 again */ rockchip_pcie_update_txcredit_mui(rockchip); rockchip_pcie_enable_interrupts(rockchip); return 0; + +err_pcie_resume: + clk_disable_unprepare(rockchip->aclk_pcie); +err_aclk_pcie: + clk_disable_unprepare(rockchip->aclk_perf_pcie); +err_aclk_perf_pcie: + clk_disable_unprepare(rockchip->hclk_pcie); +err_hclk_pcie: + clk_disable_unprepare(rockchip->clk_pcie_pm); +err_pcie_pm: + return err; } static int rockchip_pcie_probe(struct platform_device *pdev)
Re: [PATCH v4 0/6] ARM: at91: initial samx7 support
Le 01/06/2017 à 22:05, Alexandre Belloni a écrit : > This series adds initial support for Atmel armv7m SoCs. Acked-by: Nicolas Ferre To the whole series. Thanks Szemző and Alexandre for having taken care of this support! Best regards, > Changes in v4: > - rename the family samv7 as the internal name is samv7x and it may conflict >with future SoCs. > > Changes in v3: > - dropped most of the changes in Atmel/README > - rebased on v4.12-rc1 > - removed the dtsi until the tcb series is taken > > Changes in v2: > - fixed checkpatch issues > - Added documentation > - removed Ethernet from the dtsi until the driver change is taken > > > Alexandre Belloni (3): > ARM: at91: Documentation: add armv7m families > ARM: at91: Document armv7m compatibles > ARM: at91: handle CONFIG_PM for armv7m configurations > > Szemző András (3): > ARM: at91: Add armv7m support > ARM: at91: add armv7m SoC detection > ARM: at91: debug: add samv7x support > > Documentation/arm/Atmel/README | 38 > +- > .../devicetree/bindings/arm/atmel-at91.txt | 30 + > arch/arm/Kconfig.debug | 10 ++ > arch/arm/mach-at91/Kconfig | 16 - > arch/arm/mach-at91/Makefile| 4 +-- > arch/arm/mach-at91/Makefile.boot | 3 ++ > arch/arm/mach-at91/samv7.c | 34 +++ > drivers/soc/atmel/soc.c| 24 ++ > drivers/soc/atmel/soc.h| 26 +++ > 9 files changed, 181 insertions(+), 4 deletions(-) > create mode 100644 arch/arm/mach-at91/Makefile.boot > create mode 100644 arch/arm/mach-at91/samv7.c > -- Nicolas Ferre
[PATCH v5 01/11] serial: exar: Leave MPIOs as output for Commtech adapters
Commtech adapters apparently need the original setting as outputs, see
https://marc.info/?l=linux-gpio&m=149557425201323&w=2. Account for that.
Fixes: 7dea8165f1d6 ("serial: exar: Preconfigure xr17v35x MPIOs as output")
Signed-off-by: Jan Kiszka
Reviewed-by: Andy Shevchenko
---
drivers/tty/serial/8250/8250_exar.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_exar.c
b/drivers/tty/serial/8250/8250_exar.c
index b4fa585156c7..8984e8b2d524 100644
--- a/drivers/tty/serial/8250/8250_exar.c
+++ b/drivers/tty/serial/8250/8250_exar.c
@@ -171,19 +171,26 @@ pci_xr17c154_setup(struct exar8250 *priv, struct pci_dev
*pcidev,
return default_setup(priv, pcidev, idx, offset, port);
}
-static void setup_gpio(u8 __iomem *p)
+static void setup_gpio(struct pci_dev *pcidev, u8 __iomem *p)
{
+ /*
+* The Commtech adapters required the MPIOs to be driven low. The Exar
+* devices will export them as GPIOs, so we pre-configure them safely
+* as inputs.
+*/
+ u8 dir = pcidev->vendor == PCI_VENDOR_ID_EXAR ? 0xff : 0x00;
+
writeb(0x00, p + UART_EXAR_MPIOINT_7_0);
writeb(0x00, p + UART_EXAR_MPIOLVL_7_0);
writeb(0x00, p + UART_EXAR_MPIO3T_7_0);
writeb(0x00, p + UART_EXAR_MPIOINV_7_0);
- writeb(0xff, p + UART_EXAR_MPIOSEL_7_0);
+ writeb(dir, p + UART_EXAR_MPIOSEL_7_0);
writeb(0x00, p + UART_EXAR_MPIOOD_7_0);
writeb(0x00, p + UART_EXAR_MPIOINT_15_8);
writeb(0x00, p + UART_EXAR_MPIOLVL_15_8);
writeb(0x00, p + UART_EXAR_MPIO3T_15_8);
writeb(0x00, p + UART_EXAR_MPIOINV_15_8);
- writeb(0xff, p + UART_EXAR_MPIOSEL_15_8);
+ writeb(dir, p + UART_EXAR_MPIOSEL_15_8);
writeb(0x00, p + UART_EXAR_MPIOOD_15_8);
}
@@ -236,7 +243,7 @@ pci_xr17v35x_setup(struct exar8250 *priv, struct pci_dev
*pcidev,
if (idx == 0) {
/* Setup Multipurpose Input/Output pins. */
- setup_gpio(p);
+ setup_gpio(pcidev, p);
port->port.private_data = xr17v35x_register_gpio(pcidev);
}
--
2.12.3
Re: [PATCH 1/9] mm: introduce kv[mz]alloc helpers
On Fri 02-06-17 07:17:22, Sasha Levin wrote:
> On Mon, Mar 06, 2017 at 11:30:24AM +0100, Michal Hocko wrote:
> > +void *kvmalloc_node(size_t size, gfp_t flags, int node)
> > +{
> > + gfp_t kmalloc_flags = flags;
> > + void *ret;
> > +
> > + /*
> > +* vmalloc uses GFP_KERNEL for some internal allocations (e.g page
> > tables)
> > +* so the given set of flags has to be compatible.
> > +*/
> > + WARN_ON_ONCE((flags & GFP_KERNEL) != GFP_KERNEL);
>
> Hm, there are quite a few locations in the kernel that do something like:
>
> __vmalloc(len, GFP_NOFS, PAGE_KERNEL);
>
> According to your patch, vmalloc can't really do GFP_NOFS, right?
Yes. It is quite likely that they will just work because the hardcoded
GFP_KERNEL inside the vmalloc path is in unlikely paths (page table
allocations for example) but yes they are broken. I didn't convert some
places which opencode the kvmalloc with GFP_NOFS because I strongly
_believe_ that the GFP_NOFS should be revisited, checked whether it is
needed, documented if so and then memalloc_nofs__{save,restore} be used
for the scope which is reclaim recursion unsafe. This would turn all
those vmalloc users to the default GFP_KERNEL and still do the right
thing.
--
Michal Hocko
SUSE Labs
Re: [PATCH v3 00/19] Report power supply from hid-logitech-hidpp
On Jun 01 2017 or thereabouts, Bastien Nocera wrote: > On Thu, 2017-06-01 at 11:06 -0700, Dave Hansen wrote: > > On 03/27/2017 07:59 AM, Benjamin Tissoires wrote: > > > this is finally a rework of the series that provides kernel > > > power_supply > > > for hidpp devices. > > > > > > This will allow upower to not handle those devices anymore and to > > > have more > > > immediate reportng of the device to the system. > > > > FWIW, I'm on Ubuntu 14.04, and upower *is* reporting my mouse battery > > as > > if it were a laptop battery. It's mostly garbage, and always reports > > 0%, which makes upower always tell me my laptop is 2/3 charged (I > > have 2 > > real batteries). Well, the exported battery might be sending levels instead of pourcentages. And upower needs to be upgraded to handle those :( > > > > Is this expected? > > You need to either disable the feature for the kernel, or upgrade to > the latest git master of UPower. Mixing both won't work. Use the devkit > mailing-list if you need a release of UPower. > Bastien, is is possible to have a simple udev rule that tells upower to ignore the battery device if builtin_power_supply is there? That way we can tell people running old upower to use this to be sure to ignore the kernel device and just rely on the upower hidpp support? Cheers, Benjamin
[PATCH v5 04/11] gpio: exar: Allocate resources on behalf of the platform device
Do not allocate resources on behalf of the parent device but on our own. Otherwise, cleanup does not properly work if gpio-exar is removed but not the parent device. Signed-off-by: Jan Kiszka Reviewed-by: Andy Shevchenko Acked-by: Linus Walleij --- drivers/gpio/gpio-exar.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpio/gpio-exar.c b/drivers/gpio/gpio-exar.c index da4550bb9939..65126fa1e512 100644 --- a/drivers/gpio/gpio-exar.c +++ b/drivers/gpio/gpio-exar.c @@ -136,7 +136,7 @@ static int gpio_exar_probe(struct platform_device *pdev) if (!p) return -ENOMEM; - exar_gpio = devm_kzalloc(&pcidev->dev, sizeof(*exar_gpio), GFP_KERNEL); + exar_gpio = devm_kzalloc(&pdev->dev, sizeof(*exar_gpio), GFP_KERNEL); if (!exar_gpio) return -ENOMEM; @@ -157,7 +157,7 @@ static int gpio_exar_probe(struct platform_device *pdev) exar_gpio->regs = p; exar_gpio->index = index; - ret = devm_gpiochip_add_data(&pcidev->dev, + ret = devm_gpiochip_add_data(&pdev->dev, &exar_gpio->gpio_chip, exar_gpio); if (ret) goto err_destroy; -- 2.12.3
[PATCH v5 10/11] gpio-exar/8250-exar: Make set of exported GPIOs configurable
On the SIMATIC, IOT2040 only a single pin is exportable as GPIO, the
rest is required to operate the UART. To allow modeling this case,
expand the platform device data structure to specify a (consecutive) pin
subset for exporting by the gpio-exar driver.
Signed-off-by: Jan Kiszka
Reviewed-by: Andy Shevchenko
---
drivers/gpio/gpio-exar.c| 52 +
drivers/tty/serial/8250/8250_exar.c | 15 ---
2 files changed, 41 insertions(+), 26 deletions(-)
diff --git a/drivers/gpio/gpio-exar.c b/drivers/gpio/gpio-exar.c
index 1a629831d45b..220e93ed9111 100644
--- a/drivers/gpio/gpio-exar.c
+++ b/drivers/gpio/gpio-exar.c
@@ -31,6 +31,7 @@ struct exar_gpio_chip {
int index;
void __iomem *regs;
char name[20];
+ unsigned int first_pin;
};
static void exar_update(struct gpio_chip *chip, unsigned int reg, int val,
@@ -51,11 +52,12 @@ static void exar_update(struct gpio_chip *chip, unsigned
int reg, int val,
static int exar_set_direction(struct gpio_chip *chip, int direction,
unsigned int offset)
{
- unsigned int bank = offset / 8;
- unsigned int addr;
+ struct exar_gpio_chip *exar_gpio = gpiochip_get_data(chip);
+ unsigned int addr = (offset + exar_gpio->first_pin) / 8 ?
+ EXAR_OFFSET_MPIOSEL_HI : EXAR_OFFSET_MPIOSEL_LO;
+ unsigned int bit = (offset + exar_gpio->first_pin) % 8;
- addr = bank ? EXAR_OFFSET_MPIOSEL_HI : EXAR_OFFSET_MPIOSEL_LO;
- exar_update(chip, addr, direction, offset % 8);
+ exar_update(chip, addr, direction, bit);
return 0;
}
@@ -73,36 +75,33 @@ static int exar_get(struct gpio_chip *chip, unsigned int
reg)
static int exar_get_direction(struct gpio_chip *chip, unsigned int offset)
{
- unsigned int bank = offset / 8;
- unsigned int addr;
- int val;
-
- addr = bank ? EXAR_OFFSET_MPIOSEL_HI : EXAR_OFFSET_MPIOSEL_LO;
- val = exar_get(chip, addr) & BIT(offset % 8);
+ struct exar_gpio_chip *exar_gpio = gpiochip_get_data(chip);
+ unsigned int addr = (offset + exar_gpio->first_pin) / 8 ?
+ EXAR_OFFSET_MPIOSEL_HI : EXAR_OFFSET_MPIOSEL_LO;
+ unsigned int bit = (offset + exar_gpio->first_pin) % 8;
- return !!val;
+ return !!(exar_get(chip, addr) & BIT(bit));
}
static int exar_get_value(struct gpio_chip *chip, unsigned int offset)
{
- unsigned int bank = offset / 8;
- unsigned int addr;
- int val;
-
- addr = bank ? EXAR_OFFSET_MPIOLVL_HI : EXAR_OFFSET_MPIOLVL_LO;
- val = exar_get(chip, addr) & BIT(offset % 8);
+ struct exar_gpio_chip *exar_gpio = gpiochip_get_data(chip);
+ unsigned int addr = (offset + exar_gpio->first_pin) / 8 ?
+ EXAR_OFFSET_MPIOLVL_HI : EXAR_OFFSET_MPIOLVL_LO;
+ unsigned int bit = (offset + exar_gpio->first_pin) % 8;
- return !!val;
+ return !!(exar_get(chip, addr) & BIT(bit));
}
static void exar_set_value(struct gpio_chip *chip, unsigned int offset,
int value)
{
- unsigned int bank = offset / 8;
- unsigned int addr;
+ struct exar_gpio_chip *exar_gpio = gpiochip_get_data(chip);
+ unsigned int addr = (offset + exar_gpio->first_pin) / 8 ?
+ EXAR_OFFSET_MPIOLVL_HI : EXAR_OFFSET_MPIOLVL_LO;
+ unsigned int bit = (offset + exar_gpio->first_pin) % 8;
- addr = bank ? EXAR_OFFSET_MPIOLVL_HI : EXAR_OFFSET_MPIOLVL_LO;
- exar_update(chip, addr, value, offset % 8);
+ exar_update(chip, addr, value, bit);
}
static int exar_direction_output(struct gpio_chip *chip, unsigned int offset,
@@ -121,6 +120,7 @@ static int gpio_exar_probe(struct platform_device *pdev)
{
struct pci_dev *pcidev = to_pci_dev(pdev->dev.parent);
struct exar_gpio_chip *exar_gpio;
+ u32 first_pin, ngpios;
void __iomem *p;
int index, ret;
@@ -132,6 +132,11 @@ static int gpio_exar_probe(struct platform_device *pdev)
if (!p)
return -ENOMEM;
+ if (device_property_read_u32(&pdev->dev, "gpio-exar,first-pin",
+&first_pin) < 0 ||
+ device_property_read_u32(&pdev->dev, "ngpios", &ngpios) < 0)
+ return -EINVAL;
+
exar_gpio = devm_kzalloc(&pdev->dev, sizeof(*exar_gpio), GFP_KERNEL);
if (!exar_gpio)
return -ENOMEM;
@@ -149,9 +154,10 @@ static int gpio_exar_probe(struct platform_device *pdev)
exar_gpio->gpio_chip.get = exar_get_value;
exar_gpio->gpio_chip.set = exar_set_value;
exar_gpio->gpio_chip.base = -1;
- exar_gpio->gpio_chip.ngpio = 16;
+ exar_gpio->gpio_chip.ngpio = ngpios;
exar_gpio->regs = p;
exar_gpio->index = index;
+ exar_gpio->first_pin = first_pin;
ret = devm_gpiochip_add_data(&pdev->dev,
&exar_gpio->gpio_chip, exar_gpio);
di
[PATCH v5 00/11] serial/gpio: exar: Fixes and support for IOT2000
This makes the gpio-exar driver usable, which was prevented by a number of fatal bugs, and adds support for the SIMATIC IOT2040 to the 8250-exar driver and, indirectly, to gpio-exar as well. It's a cross-subsystem series, so I'm also cross-posting to the serial and gpio lists. Changes in v5: - factor out exar8250_platform hook setup as separate patch - pass properties to __xr17v35x_register_gpio - constant property support for platform_device_add_properties Jan Jan Kiszka (11): serial: exar: Leave MPIOs as output for Commtech adapters gpio-exar/8250-exar: Do not even instantiate a GPIO device for Commtech cards gpio-exar/8250-exar: Fix passing in of parent PCI device gpio: exar: Allocate resources on behalf of the platform device gpio: exar: Fix iomap request gpio: exar: Fix reading of directions and values gpio-exar/8250-exar: Rearrange gpiochip parenthood serial: exar: Factor out platform hooks platform: Accept const properties gpio-exar/8250-exar: Make set of exported GPIOs configurable serial: exar: Add support for IOT2040 device drivers/base/platform.c | 2 +- drivers/gpio/gpio-exar.c| 75 +++--- drivers/tty/serial/8250/8250_exar.c | 188 ++-- include/linux/platform_device.h | 2 +- 4 files changed, 218 insertions(+), 49 deletions(-) -- 2.12.3
[PATCH v5 02/11] gpio-exar/8250-exar: Do not even instantiate a GPIO device for Commtech cards
Commtech adapters need the MPIOs for internal purposes, and the gpio-exar driver already refused to pick them up. But there is actually no point in even creating the underlying platform device. Signed-off-by: Jan Kiszka Reviewed-by: Andy Shevchenko Acked-by: Linus Walleij --- drivers/gpio/gpio-exar.c| 3 --- drivers/tty/serial/8250/8250_exar.c | 4 +++- 2 files changed, 3 insertions(+), 4 deletions(-) diff --git a/drivers/gpio/gpio-exar.c b/drivers/gpio/gpio-exar.c index 081076771217..006a9a67c2a4 100644 --- a/drivers/gpio/gpio-exar.c +++ b/drivers/gpio/gpio-exar.c @@ -124,9 +124,6 @@ static int gpio_exar_probe(struct platform_device *pdev) void __iomem *p; int index, ret; - if (pcidev->vendor != PCI_VENDOR_ID_EXAR) - return -ENODEV; - /* * Map the pci device to get the register addresses. * We will need to read and write those registers to control diff --git a/drivers/tty/serial/8250/8250_exar.c b/drivers/tty/serial/8250/8250_exar.c index 8984e8b2d524..c29c7e675890 100644 --- a/drivers/tty/serial/8250/8250_exar.c +++ b/drivers/tty/serial/8250/8250_exar.c @@ -245,7 +245,9 @@ pci_xr17v35x_setup(struct exar8250 *priv, struct pci_dev *pcidev, /* Setup Multipurpose Input/Output pins. */ setup_gpio(pcidev, p); - port->port.private_data = xr17v35x_register_gpio(pcidev); + if (pcidev->vendor == PCI_VENDOR_ID_EXAR) + port->port.private_data = + xr17v35x_register_gpio(pcidev); } return 0; -- 2.12.3
[PATCH v5 05/11] gpio: exar: Fix iomap request
The UART driver already maps the resource for us. Trying to do this here only fails and leaves us with a non-working device. Signed-off-by: Jan Kiszka Reviewed-by: Andy Shevchenko Acked-by: Linus Walleij --- drivers/gpio/gpio-exar.c | 10 +++--- 1 file changed, 3 insertions(+), 7 deletions(-) diff --git a/drivers/gpio/gpio-exar.c b/drivers/gpio/gpio-exar.c index 65126fa1e512..b29890b143ce 100644 --- a/drivers/gpio/gpio-exar.c +++ b/drivers/gpio/gpio-exar.c @@ -125,14 +125,10 @@ static int gpio_exar_probe(struct platform_device *pdev) int index, ret; /* -* Map the pci device to get the register addresses. -* We will need to read and write those registers to control -* the GPIO pins. -* Using managed functions will save us from unmaping on exit. -* As the device is enabled using managed functions by the -* UART driver we can also use managed functions here. +* The UART driver must have mapped region 0 prior to registering this +* device - use it. */ - p = pcim_iomap(pcidev, 0, 0); + p = pcim_iomap_table(pcidev)[0]; if (!p) return -ENOMEM; -- 2.12.3
[PATCH v5 07/11] gpio-exar/8250-exar: Rearrange gpiochip parenthood
Set the parent of the exar gpiochip to its platform device, like other
gpiochips are doing it. In order to keep the relationship discoverable
for ACPI systems, set the platform device companion to the PCI device.
Signed-off-by: Jan Kiszka
Reviewed-by: Andy Shevchenko
Acked-by: Linus Walleij
---
drivers/gpio/gpio-exar.c| 2 +-
drivers/tty/serial/8250/8250_exar.c | 2 ++
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpio/gpio-exar.c b/drivers/gpio/gpio-exar.c
index f3585a184f39..1a629831d45b 100644
--- a/drivers/gpio/gpio-exar.c
+++ b/drivers/gpio/gpio-exar.c
@@ -142,7 +142,7 @@ static int gpio_exar_probe(struct platform_device *pdev)
sprintf(exar_gpio->name, "exar_gpio%d", index);
exar_gpio->gpio_chip.label = exar_gpio->name;
- exar_gpio->gpio_chip.parent = &pcidev->dev;
+ exar_gpio->gpio_chip.parent = &pdev->dev;
exar_gpio->gpio_chip.direction_output = exar_direction_output;
exar_gpio->gpio_chip.direction_input = exar_direction_input;
exar_gpio->gpio_chip.get_direction = exar_get_direction;
diff --git a/drivers/tty/serial/8250/8250_exar.c
b/drivers/tty/serial/8250/8250_exar.c
index 0f4b236d7e68..ee4b142f3ed0 100644
--- a/drivers/tty/serial/8250/8250_exar.c
+++ b/drivers/tty/serial/8250/8250_exar.c
@@ -9,6 +9,7 @@
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License.
*/
+#include
#include
#include
#include
@@ -204,6 +205,7 @@ xr17v35x_register_gpio(struct pci_dev *pcidev)
return NULL;
pdev->dev.parent = &pcidev->dev;
+ ACPI_COMPANION_SET(&pdev->dev, ACPI_COMPANION(&pcidev->dev));
if (platform_device_add(pdev) < 0) {
platform_device_put(pdev);
--
2.12.3
[PATCH v5 09/11] platform: Accept const properties
Aligns us with device_add_properties, the function we call.
Signed-off-by: Jan Kiszka
---
drivers/base/platform.c | 2 +-
include/linux/platform_device.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index a102152301c8..71ea6f4d33c2 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -344,7 +344,7 @@ EXPORT_SYMBOL_GPL(platform_device_add_data);
* platform device is released.
*/
int platform_device_add_properties(struct platform_device *pdev,
- struct property_entry *properties)
+ const struct property_entry *properties)
{
return device_add_properties(&pdev->dev, properties);
}
diff --git a/include/linux/platform_device.h b/include/linux/platform_device.h
index 98c2a7c7108e..49f634d96118 100644
--- a/include/linux/platform_device.h
+++ b/include/linux/platform_device.h
@@ -172,7 +172,7 @@ extern int platform_device_add_resources(struct
platform_device *pdev,
extern int platform_device_add_data(struct platform_device *pdev,
const void *data, size_t size);
extern int platform_device_add_properties(struct platform_device *pdev,
- struct property_entry *properties);
+ const struct property_entry *properties);
extern int platform_device_add(struct platform_device *pdev);
extern void platform_device_del(struct platform_device *pdev);
extern void platform_device_put(struct platform_device *pdev);
--
2.12.3
Re: [PATCH 10/12] apparmorfs: Replace CURRENT_TIME with current_time()
On 04/07/2017 05:57 PM, Deepa Dinamani wrote: > CURRENT_TIME macro is not y2038 safe on 32 bit systems. > > The patch replaces all the uses of CURRENT_TIME by > current_time(). > > This is also in preparation for the patch that transitions > vfs timestamps to use 64 bit time and hence make them > y2038 safe. current_time() is also planned to be transitioned > to y2038 safe behavior along with this change. > > CURRENT_TIME macro will be deleted before merging the > aforementioned change. > > Signed-off-by: Deepa Dinamani This is all good, and I have no objections to it being merged for 4.12. If it isn't this change is already queued up for the apparmor 4.13 merge Acked-by: John Johansen > --- > security/apparmor/apparmorfs.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/security/apparmor/apparmorfs.c b/security/apparmor/apparmorfs.c > index be0b498..4f6ac9d 100644 > --- a/security/apparmor/apparmorfs.c > +++ b/security/apparmor/apparmorfs.c > @@ -1357,7 +1357,7 @@ static int aa_mk_null_file(struct dentry *parent) > > inode->i_ino = get_next_ino(); > inode->i_mode = S_IFCHR | S_IRUGO | S_IWUGO; > - inode->i_atime = inode->i_mtime = inode->i_ctime = CURRENT_TIME; > + inode->i_atime = inode->i_mtime = inode->i_ctime = current_time(inode); > init_special_inode(inode, S_IFCHR | S_IRUGO | S_IWUGO, > MKDEV(MEM_MAJOR, 3)); > d_instantiate(dentry, inode); >
[PATCH v5 08/11] serial: exar: Factor out platform hooks
This prepares the addition of IOT2040 platform support by preparing the
needed setup and rs485_config hooks.
Signed-off-by: Jan Kiszka
Reviewed-by: Andy Shevchenko
---
drivers/tty/serial/8250/8250_exar.c | 32 +++-
1 file changed, 27 insertions(+), 5 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_exar.c
b/drivers/tty/serial/8250/8250_exar.c
index ee4b142f3ed0..1106f1f58c77 100644
--- a/drivers/tty/serial/8250/8250_exar.c
+++ b/drivers/tty/serial/8250/8250_exar.c
@@ -63,6 +63,11 @@
struct exar8250;
+struct exar8250_platform {
+ int (*rs485_config)(struct uart_port *, struct serial_rs485 *);
+ int (*register_gpio)(struct pci_dev *, struct uart_8250_port *);
+};
+
/**
* struct exar8250_board - board information
* @num_ports: number of serial ports
@@ -196,7 +201,7 @@ static void setup_gpio(struct pci_dev *pcidev, u8 __iomem
*p)
}
static void *
-xr17v35x_register_gpio(struct pci_dev *pcidev)
+__xr17v35x_register_gpio(struct pci_dev *pcidev)
{
struct platform_device *pdev;
@@ -215,17 +220,36 @@ xr17v35x_register_gpio(struct pci_dev *pcidev)
return pdev;
}
+static int xr17v35x_register_gpio(struct pci_dev *pcidev,
+ struct uart_8250_port *port)
+{
+ if (pcidev->vendor == PCI_VENDOR_ID_EXAR)
+ port->port.private_data =
+ __xr17v35x_register_gpio(pcidev);
+
+ return 0;
+}
+
+static const struct exar8250_platform exar8250_default_platform = {
+ .register_gpio = xr17v35x_register_gpio,
+};
+
static int
pci_xr17v35x_setup(struct exar8250 *priv, struct pci_dev *pcidev,
struct uart_8250_port *port, int idx)
{
const struct exar8250_board *board = priv->board;
+ const struct exar8250_platform *platform;
unsigned int offset = idx * 0x400;
unsigned int baud = 7812500;
u8 __iomem *p;
int ret;
+ platform = &exar8250_default_platform;
+
port->port.uartclk = baud * 16;
+ port->port.rs485_config = platform->rs485_config;
+
/*
* Setup the uart clock for the devices on expansion slot to
* half the clock speed of the main chip (which is 125MHz)
@@ -248,12 +272,10 @@ pci_xr17v35x_setup(struct exar8250 *priv, struct pci_dev
*pcidev,
/* Setup Multipurpose Input/Output pins. */
setup_gpio(pcidev, p);
- if (pcidev->vendor == PCI_VENDOR_ID_EXAR)
- port->port.private_data =
- xr17v35x_register_gpio(pcidev);
+ ret = platform->register_gpio(pcidev, port);
}
- return 0;
+ return ret;
}
static void pci_xr17v35x_exit(struct pci_dev *pcidev)
--
2.12.3
[PATCH 1/2] sched/deadline: Add cpudl_maximum_dl()
Current code uses cpudl_maximum() to get the root node's cpu, while it
directly accesses the root node using 'cp->elements[0].dl' to get the
root node's dl. It would be better and more readible if a function to
get the dl is added. So add it.
Signed-off-by: Byungchul Park
---
kernel/sched/cpudeadline.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/kernel/sched/cpudeadline.c b/kernel/sched/cpudeadline.c
index fba235c..d4a6963 100644
--- a/kernel/sched/cpudeadline.c
+++ b/kernel/sched/cpudeadline.c
@@ -108,11 +108,16 @@ static void cpudl_heapify(struct cpudl *cp, int idx)
cpudl_heapify_down(cp, idx);
}
-static inline int cpudl_maximum(struct cpudl *cp)
+static inline int cpudl_maximum_cpu(struct cpudl *cp)
{
return cp->elements[0].cpu;
}
+static inline u64 cpudl_maximum_dl(struct cpudl *cp)
+{
+ return cp->elements[0].dl;
+}
+
/*
* cpudl_find - find the best (later-dl) CPU in the system
* @cp: the cpudl max-heap context
@@ -131,9 +136,9 @@ int cpudl_find(struct cpudl *cp, struct task_struct *p,
cpumask_and(later_mask, cp->free_cpus, &p->cpus_allowed)) {
best_cpu = cpumask_any(later_mask);
goto out;
- } else if (cpumask_test_cpu(cpudl_maximum(cp), &p->cpus_allowed) &&
- dl_time_before(dl_se->deadline, cp->elements[0].dl)) {
- best_cpu = cpudl_maximum(cp);
+ } else if (cpumask_test_cpu(cpudl_maximum_cpu(cp), &p->cpus_allowed) &&
+ dl_time_before(dl_se->deadline, cpudl_maximum_dl(cp))) {
+ best_cpu = cpudl_maximum_cpu(cp);
if (later_mask)
cpumask_set_cpu(best_cpu, later_mask);
}
--
1.9.1
Re: [PATCH] HID: asus: Stop underlying hardware on remove
On May 30 2017 or thereabouts, Carlo Caione wrote: > From: Carlo Caione > > We are missing a call to hid_hw_stop() on the remove hook. > Among other things this is causing an Oops when (re-)starting GNOME / > upowerd / ... after the module has been already rmmod-ed. Good catch: Reviewed-by: Benjamin Tissoires Cheers, Benjamin > > Signed-off-by: Carlo Caione > --- > drivers/hid/hid-asus.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c > index 16df6cc..2e9642d 100644 > --- a/drivers/hid/hid-asus.c > +++ b/drivers/hid/hid-asus.c > @@ -536,6 +536,8 @@ static void asus_remove(struct hid_device *hdev) > drvdata->kbd_backlight->removed = true; > cancel_work_sync(&drvdata->kbd_backlight->work); > } > + > + hid_hw_stop(hdev); > } > > static __u8 *asus_report_fixup(struct hid_device *hdev, __u8 *rdesc, > -- > 2.9.3 >
[PATCH 2/2] sched/deadline: Don't return invalid cpu in cpudl_maximum_cpu()
When the heap tree is empty, cp->elements[0].cpu has meaningless value.
We need to consider the case.
Signed-off-by: Byungchul Park
---
kernel/sched/cpudeadline.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/kernel/sched/cpudeadline.c b/kernel/sched/cpudeadline.c
index d4a6963..9b314a9 100644
--- a/kernel/sched/cpudeadline.c
+++ b/kernel/sched/cpudeadline.c
@@ -110,7 +110,8 @@ static void cpudl_heapify(struct cpudl *cp, int idx)
static inline int cpudl_maximum_cpu(struct cpudl *cp)
{
- return cp->elements[0].cpu;
+ int cpu = cp->elements[0].cpu;
+ return cp->elements[cpu].idx == IDX_INVALID ? -1 : cpu;
}
static inline u64 cpudl_maximum_dl(struct cpudl *cp)
--
1.9.1
[PATCH v5 03/11] gpio-exar/8250-exar: Fix passing in of parent PCI device
This fixes reloading of the GPIO driver for the same platform device
instance as created by the exar UART driver: First of all, the driver
sets drvdata to its own value during probing and does not restore the
original value on exit. But this won't help anyway as the core clears
drvdata after the driver left.
Set the platform device parent instead.
Signed-off-by: Jan Kiszka
Reviewed-by: Andy Shevchenko
Acked-by: Linus Walleij
---
drivers/gpio/gpio-exar.c| 2 +-
drivers/tty/serial/8250/8250_exar.c | 3 ++-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpio/gpio-exar.c b/drivers/gpio/gpio-exar.c
index 006a9a67c2a4..da4550bb9939 100644
--- a/drivers/gpio/gpio-exar.c
+++ b/drivers/gpio/gpio-exar.c
@@ -119,7 +119,7 @@ static int exar_direction_input(struct gpio_chip *chip,
unsigned int offset)
static int gpio_exar_probe(struct platform_device *pdev)
{
- struct pci_dev *pcidev = platform_get_drvdata(pdev);
+ struct pci_dev *pcidev = to_pci_dev(pdev->dev.parent);
struct exar_gpio_chip *exar_gpio;
void __iomem *p;
int index, ret;
diff --git a/drivers/tty/serial/8250/8250_exar.c
b/drivers/tty/serial/8250/8250_exar.c
index c29c7e675890..0f4b236d7e68 100644
--- a/drivers/tty/serial/8250/8250_exar.c
+++ b/drivers/tty/serial/8250/8250_exar.c
@@ -203,7 +203,8 @@ xr17v35x_register_gpio(struct pci_dev *pcidev)
if (!pdev)
return NULL;
- platform_set_drvdata(pdev, pcidev);
+ pdev->dev.parent = &pcidev->dev;
+
if (platform_device_add(pdev) < 0) {
platform_device_put(pdev);
return NULL;
--
2.12.3
[PATCH v5 06/11] gpio: exar: Fix reading of directions and values
First, the logic for translating a register bit to the return code of exar_get_direction and exar_get_value were wrong. And second, there was a flip regarding the register bank in exar_get_direction. Signed-off-by: Jan Kiszka Reviewed-by: Andy Shevchenko Acked-by: Linus Walleij --- drivers/gpio/gpio-exar.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpio/gpio-exar.c b/drivers/gpio/gpio-exar.c index b29890b143ce..f3585a184f39 100644 --- a/drivers/gpio/gpio-exar.c +++ b/drivers/gpio/gpio-exar.c @@ -68,7 +68,7 @@ static int exar_get(struct gpio_chip *chip, unsigned int reg) value = readb(exar_gpio->regs + reg); mutex_unlock(&exar_gpio->lock); - return !!value; + return value; } static int exar_get_direction(struct gpio_chip *chip, unsigned int offset) @@ -78,7 +78,7 @@ static int exar_get_direction(struct gpio_chip *chip, unsigned int offset) int val; addr = bank ? EXAR_OFFSET_MPIOSEL_HI : EXAR_OFFSET_MPIOSEL_LO; - val = exar_get(chip, addr) >> (offset % 8); + val = exar_get(chip, addr) & BIT(offset % 8); return !!val; } @@ -89,8 +89,8 @@ static int exar_get_value(struct gpio_chip *chip, unsigned int offset) unsigned int addr; int val; - addr = bank ? EXAR_OFFSET_MPIOLVL_LO : EXAR_OFFSET_MPIOLVL_HI; - val = exar_get(chip, addr) >> (offset % 8); + addr = bank ? EXAR_OFFSET_MPIOLVL_HI : EXAR_OFFSET_MPIOLVL_LO; + val = exar_get(chip, addr) & BIT(offset % 8); return !!val; } -- 2.12.3
Re: [PATCH] memcg: refactor mem_cgroup_resize_limit()
On 2.06.2017 02:02, Yu Zhao wrote:
> mem_cgroup_resize_limit() and mem_cgroup_resize_memsw_limit() have
> identical logics. Refactor code so we don't need to keep two pieces
> of code that does same thing.
>
> Signed-off-by: Yu Zhao
> ---
> mm/memcontrol.c | 71
> +
> 1 file changed, 11 insertions(+), 60 deletions(-)
>
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index 94172089f52f..a4f0daaff704 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -2422,13 +2422,14 @@ static inline int
> mem_cgroup_move_swap_account(swp_entry_t entry,
> static DEFINE_MUTEX(memcg_limit_mutex);
>
> static int mem_cgroup_resize_limit(struct mem_cgroup *memcg,
> -unsigned long limit)
> +unsigned long limit, bool memsw)
> {
> unsigned long curusage;
> unsigned long oldusage;
> bool enlarge = false;
> int retry_count;
> int ret;
> + struct page_counter *counter = memsw ? &memcg->memsw : &memcg->memory;
>
> /*
>* For keeping hierarchical_reclaim simple, how long we should retry
> @@ -2438,58 +2439,7 @@ static int mem_cgroup_resize_limit(struct mem_cgroup
> *memcg,
> retry_count = MEM_CGROUP_RECLAIM_RETRIES *
> mem_cgroup_count_children(memcg);
>
> - oldusage = page_counter_read(&memcg->memory);
> -
> - do {
> - if (signal_pending(current)) {
> - ret = -EINTR;
> - break;
> - }
> -
> - mutex_lock(&memcg_limit_mutex);
> - if (limit > memcg->memsw.limit) {
> - mutex_unlock(&memcg_limit_mutex);
> - ret = -EINVAL;
> - break;
> - }
> - if (limit > memcg->memory.limit)
> - enlarge = true;
> - ret = page_counter_limit(&memcg->memory, limit);
> - mutex_unlock(&memcg_limit_mutex);
> -
> - if (!ret)
> - break;
> -
> - try_to_free_mem_cgroup_pages(memcg, 1, GFP_KERNEL, true);
> -
> - curusage = page_counter_read(&memcg->memory);
> - /* Usage is reduced ? */
> - if (curusage >= oldusage)
> - retry_count--;
> - else
> - oldusage = curusage;
> - } while (retry_count);
> -
> - if (!ret && enlarge)
> - memcg_oom_recover(memcg);
> -
> - return ret;
> -}
> -
> -static int mem_cgroup_resize_memsw_limit(struct mem_cgroup *memcg,
> - unsigned long limit)
> -{
> - unsigned long curusage;
> - unsigned long oldusage;
> - bool enlarge = false;
> - int retry_count;
> - int ret;
> -
> - /* see mem_cgroup_resize_res_limit */
> - retry_count = MEM_CGROUP_RECLAIM_RETRIES *
> - mem_cgroup_count_children(memcg);
> -
> - oldusage = page_counter_read(&memcg->memsw);
> + oldusage = page_counter_read(counter);
>
> do {
> if (signal_pending(current)) {
> @@ -2498,22 +2448,23 @@ static int mem_cgroup_resize_memsw_limit(struct
> mem_cgroup *memcg,
> }
>
> mutex_lock(&memcg_limit_mutex);
> - if (limit < memcg->memory.limit) {
> + if (memsw ? limit < memcg->memory.limit :
> + limit > memcg->memsw.limit) {
No, just no. Please createa a local variable and use that. Using the
ternary operator in an 'if' statement is just ugly!
> mutex_unlock(&memcg_limit_mutex);
> ret = -EINVAL;
> break;
> }
> - if (limit > memcg->memsw.limit)
> + if (limit > counter->limit)
> enlarge = true;
> - ret = page_counter_limit(&memcg->memsw, limit);
> + ret = page_counter_limit(counter, limit);
> mutex_unlock(&memcg_limit_mutex);
>
> if (!ret)
> break;
>
> - try_to_free_mem_cgroup_pages(memcg, 1, GFP_KERNEL, false);
> + try_to_free_mem_cgroup_pages(memcg, 1, GFP_KERNEL, !memsw);
>
> - curusage = page_counter_read(&memcg->memsw);
> + curusage = page_counter_read(counter);
> /* Usage is reduced ? */
> if (curusage >= oldusage)
> retry_count--;
> @@ -2975,10 +2926,10 @@ static ssize_t mem_cgroup_write(struct
> kernfs_open_file *of,
> }
> switch (MEMFILE_TYPE(of_cft(of)->private)) {
> case _MEM:
> - ret = mem_cgroup_resize_limit(memcg, nr_pages);
> + ret = mem_cgroup_resize_limit(memcg, nr_pages, false);
> break;
> case _MEMSWAP:
> - ret = mem_cgroup_resize_memsw_limit(memcg, nr_pag
[PATCH v5 11/11] serial: exar: Add support for IOT2040 device
This implements the setup of RS232 and the switch-over to RS485 or RS422
for the Siemens IOT2040. That uses an EXAR XR17V352 with external logic
to switch between the different modes. The external logic is controlled
via MPIO pins of the EXAR controller.
Only pin 10 can be exported as GPIO on the IOT2040. It is connected to
an LED.
As the XR17V352 used on the IOT2040 is not equipped with an external
EEPROM, it cannot present itself as IOT2040-variant via subvendor/
subdevice IDs. Thus, we have to check via DMI for the target platform.
Co-developed with Sascha Weisenberger.
Signed-off-by: Sascha Weisenberger
Signed-off-by: Jan Kiszka
Reviewed-by: Andy Shevchenko
---
drivers/tty/serial/8250/8250_exar.c | 129 +++-
1 file changed, 128 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/serial/8250/8250_exar.c
b/drivers/tty/serial/8250/8250_exar.c
index bd0e40e869b8..4154601b1d03 100644
--- a/drivers/tty/serial/8250/8250_exar.c
+++ b/drivers/tty/serial/8250/8250_exar.c
@@ -10,6 +10,7 @@
* the Free Software Foundation; either version 2 of the License.
*/
#include
+#include
#include
#include
#include
@@ -62,6 +63,43 @@
#define UART_EXAR_MPIOSEL_15_8 0x99/* MPIOSEL[15:8] */
#define UART_EXAR_MPIOOD_15_8 0x9a/* MPIOOD[15:8] */
+#define UART_EXAR_RS485_DLY(x) ((x) << 4)
+
+/*
+ * IOT2040 MPIO wiring semantics:
+ *
+ * MPIOPortFunction
+ *
+ * 0 2 Mode bit 0
+ * 1 2 Mode bit 1
+ * 2 2 Terminate bus
+ * 3 -
+ * 4 3 Mode bit 0
+ * 5 3 Mode bit 1
+ * 6 3 Terminate bus
+ * 7 -
+ * 8 2 Enable
+ * 9 3 Enable
+ * 10 - Red LED
+ * 11..15 -
+ */
+
+/* IOT2040 MPIOs 0..7 */
+#define IOT2040_UART_MODE_RS2320x01
+#define IOT2040_UART_MODE_RS4850x02
+#define IOT2040_UART_MODE_RS4220x03
+#define IOT2040_UART_TERMINATE_BUS 0x04
+
+#define IOT2040_UART1_MASK 0x0f
+#define IOT2040_UART2_SHIFT4
+
+#define IOT2040_UARTS_DEFAULT_MODE 0x11/* both RS232 */
+#define IOT2040_UARTS_GPIO_LO_MODE 0x88/* reserved pins as input */
+
+/* IOT2040 MPIOs 8..15 */
+#define IOT2040_UARTS_ENABLE 0x03
+#define IOT2040_UARTS_GPIO_HI_MODE 0xF8/* enable & LED as outputs */
+
struct exar8250;
struct exar8250_platform {
@@ -243,18 +281,107 @@ static const struct exar8250_platform
exar8250_default_platform = {
.register_gpio = xr17v35x_register_gpio,
};
+static int iot2040_rs485_config(struct uart_port *port,
+ struct serial_rs485 *rs485)
+{
+ bool is_rs485 = !!(rs485->flags & SER_RS485_ENABLED);
+ u8 __iomem *p = port->membase;
+ u8 mask = IOT2040_UART1_MASK;
+ u8 mode, value;
+
+ if (is_rs485) {
+ if (rs485->flags & SER_RS485_RX_DURING_TX)
+ mode = IOT2040_UART_MODE_RS422;
+ else
+ mode = IOT2040_UART_MODE_RS485;
+
+ if (rs485->flags & SER_RS485_TERMINATE_BUS)
+ mode |= IOT2040_UART_TERMINATE_BUS;
+ } else {
+ mode = IOT2040_UART_MODE_RS232;
+ }
+
+ if (port->line == 3) {
+ mask <<= IOT2040_UART2_SHIFT;
+ mode <<= IOT2040_UART2_SHIFT;
+ }
+
+ value = readb(p + UART_EXAR_MPIOLVL_7_0);
+ value &= ~mask;
+ value |= mode;
+ writeb(value, p + UART_EXAR_MPIOLVL_7_0);
+
+ value = readb(p + UART_EXAR_FCTR);
+ if (is_rs485)
+ value |= UART_FCTR_EXAR_485;
+ else
+ value &= ~UART_FCTR_EXAR_485;
+ writeb(value, p + UART_EXAR_FCTR);
+
+ if (is_rs485)
+ writeb(UART_EXAR_RS485_DLY(4), p + UART_MSR);
+
+ port->rs485 = *rs485;
+
+ return 0;
+}
+
+static const struct property_entry iot2040_gpio_properties[] = {
+ PROPERTY_ENTRY_U32("gpio-exar,first-pin", 10),
+ PROPERTY_ENTRY_U32("ngpios", 1),
+ { }
+};
+
+static int iot2040_register_gpio(struct pci_dev *pcidev,
+ struct uart_8250_port *port)
+{
+ u8 __iomem *p = port->port.membase;
+
+ writeb(IOT2040_UARTS_DEFAULT_MODE, p + UART_EXAR_MPIOLVL_7_0);
+ writeb(IOT2040_UARTS_GPIO_LO_MODE, p + UART_EXAR_MPIOSEL_7_0);
+ writeb(IOT2040_UARTS_ENABLE, p + UART_EXAR_MPIOLVL_15_8);
+ writeb(IOT2040_UARTS_GPIO_HI_MODE, p + UART_EXAR_MPIOSEL_15_8);
+
+ port->port.private_data =
+ __xr17v35x_register_gpio(pcidev, iot2040_gpio_properties);
+
+ return 0;
+}
+
+static const struct exar8250_platform iot2040_platform = {
+ .rs485_config = iot2040_rs485_config,
+ .register_gpio = iot2040_register_gpio,
+};
+
+static const struct dmi_system_id exar_platforms[] = {
[PATCH v4 1/6] stmmac: pci: Make stmmac_pci_info structure constant
By removing the PCI device reference from the structure and passing it
as parameters to the interested functions, we can make quark_pci_info
const.
Signed-off-by: Jan Kiszka
Reviewed-by: Andy Shevchenko
---
drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 23 +++
1 file changed, 11 insertions(+), 12 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
index 22f910795be4..0efe42659a37 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
@@ -38,17 +38,17 @@ struct stmmac_pci_dmi_data {
};
struct stmmac_pci_info {
- struct pci_dev *pdev;
- int (*setup)(struct plat_stmmacenet_data *plat,
-struct stmmac_pci_info *info);
+ int (*setup)(struct pci_dev *pdev, struct plat_stmmacenet_data *plat,
+const struct stmmac_pci_info *info);
struct stmmac_pci_dmi_data *dmi;
};
-static int stmmac_pci_find_phy_addr(struct stmmac_pci_info *info)
+static int stmmac_pci_find_phy_addr(struct pci_dev *pdev,
+ const struct stmmac_pci_info *info)
{
const char *name = dmi_get_system_info(DMI_BOARD_NAME);
const char *asset_tag = dmi_get_system_info(DMI_BOARD_ASSET_TAG);
- unsigned int func = PCI_FUNC(info->pdev->devfn);
+ unsigned int func = PCI_FUNC(pdev->devfn);
struct stmmac_pci_dmi_data *dmi;
/*
@@ -114,10 +114,10 @@ static void stmmac_default_data(struct
plat_stmmacenet_data *plat)
/* TODO: AXI */
}
-static int quark_default_data(struct plat_stmmacenet_data *plat,
- struct stmmac_pci_info *info)
+static int quark_default_data(struct pci_dev *pdev,
+ struct plat_stmmacenet_data *plat,
+ const struct stmmac_pci_info *info)
{
- struct pci_dev *pdev = info->pdev;
int ret;
/* Set common default data first */
@@ -127,7 +127,7 @@ static int quark_default_data(struct plat_stmmacenet_data
*plat,
* Refuse to load the driver and register net device if MAC controller
* does not connect to any PHY interface.
*/
- ret = stmmac_pci_find_phy_addr(info);
+ ret = stmmac_pci_find_phy_addr(pdev, info);
if (ret < 0)
return ret;
@@ -175,7 +175,7 @@ static struct stmmac_pci_dmi_data quark_pci_dmi_data[] = {
{}
};
-static struct stmmac_pci_info quark_pci_info = {
+static const struct stmmac_pci_info quark_pci_info = {
.setup = quark_default_data,
.dmi = quark_pci_dmi_data,
};
@@ -237,9 +237,8 @@ static int stmmac_pci_probe(struct pci_dev *pdev,
pci_set_master(pdev);
if (info) {
- info->pdev = pdev;
if (info->setup) {
- ret = info->setup(plat, info);
+ ret = info->setup(pdev, plat, info);
if (ret)
return ret;
}
--
2.12.3
[PATCH v4 3/6] stmmac: pci: Make stmmac_pci_find_phy_addr truly generic
Move the special case for the early Galileo firmware into
quark_default_setup. This allows to use stmmac_pci_find_phy_addr for
non-quark cases.
Signed-off-by: Jan Kiszka
Reviewed-by: Andy Shevchenko
---
drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 20 +---
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
index d3d74e526e17..f44ae49eb11c 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
@@ -51,12 +51,8 @@ static int stmmac_pci_find_phy_addr(struct pci_dev *pdev,
unsigned int func = PCI_FUNC(pdev->devfn);
struct stmmac_pci_dmi_data *dmi;
- /*
-* Galileo boards with old firmware don't support DMI. We always return
-* 1 here, so at least first found MAC controller would be probed.
-*/
if (!name)
- return 1;
+ return -ENODEV;
for (dmi = info->dmi; dmi->name && *dmi->name; dmi++) {
if (!strcmp(dmi->name, name) && dmi->func == func) {
@@ -136,8 +132,18 @@ static int quark_default_data(struct pci_dev *pdev,
* does not connect to any PHY interface.
*/
ret = stmmac_pci_find_phy_addr(pdev, info);
- if (ret < 0)
- return ret;
+ if (ret < 0) {
+ /* Return error to the caller on DMI enabled boards. */
+ if (dmi_get_system_info(DMI_BOARD_NAME))
+ return ret;
+
+ /*
+* Galileo boards with old firmware don't support DMI. We always
+* use 1 here as PHY address, so at least the first found MAC
+* controller would be probed.
+*/
+ ret = 1;
+ }
plat->bus_id = PCI_DEVID(pdev->bus->number, pdev->devfn);
plat->phy_addr = ret;
--
2.12.3
[PATCH v4 6/6] stmmac: pci: Remove setup handler indirection via stmmac_pci_info
By now, stmmac_pci_info only contains a single entry. Register this
directly with the PCI device table, removing one indirection.
Signed-off-by: Jan Kiszka
---
drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 34 +---
1 file changed, 12 insertions(+), 22 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
index 2be15a8a9c40..393710815e4b 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
@@ -40,9 +40,7 @@ struct stmmac_pci_dmi_data {
size_t nfuncs;
};
-struct stmmac_pci_info {
- int (*setup)(struct pci_dev *pdev, struct plat_stmmacenet_data *plat);
-};
+typedef int (*stmmac_setup)(struct pci_dev *, struct plat_stmmacenet_data *);
static int stmmac_pci_find_phy_addr(struct pci_dev *pdev,
const struct dmi_system_id *dmi_list)
@@ -97,8 +95,8 @@ static void common_default_data(struct plat_stmmacenet_data
*plat)
plat->rx_queues_cfg[0].pkt_route = 0x0;
}
-static int stmmac_default_data(struct pci_dev *pdev,
- struct plat_stmmacenet_data *plat)
+static int stmmac_default_setup(struct pci_dev *pdev,
+ struct plat_stmmacenet_data *plat)
{
/* Set common default data first */
common_default_data(plat);
@@ -114,10 +112,6 @@ static int stmmac_default_data(struct pci_dev *pdev,
return 0;
}
-static const struct stmmac_pci_info stmmac_pci_info = {
- .setup = stmmac_default_data,
-};
-
static const struct stmmac_pci_func_data galileo_stmmac_func_data[] = {
{
.func = 6,
@@ -180,8 +174,8 @@ static const struct dmi_system_id quark_pci_dmi[] = {
{}
};
-static int quark_default_data(struct pci_dev *pdev,
- struct plat_stmmacenet_data *plat)
+static int quark_default_setup(struct pci_dev *pdev,
+ struct plat_stmmacenet_data *plat)
{
int ret;
@@ -218,10 +212,6 @@ static int quark_default_data(struct pci_dev *pdev,
return 0;
}
-static const struct stmmac_pci_info quark_pci_info = {
- .setup = quark_default_data,
-};
-
/**
* stmmac_pci_probe
*
@@ -237,7 +227,7 @@ static const struct stmmac_pci_info quark_pci_info = {
static int stmmac_pci_probe(struct pci_dev *pdev,
const struct pci_device_id *id)
{
- struct stmmac_pci_info *info = (struct stmmac_pci_info
*)id->driver_data;
+ stmmac_setup setup = (stmmac_setup)id->driver_data;
struct plat_stmmacenet_data *plat;
struct stmmac_resources res;
int i;
@@ -278,7 +268,7 @@ static int stmmac_pci_probe(struct pci_dev *pdev,
pci_set_master(pdev);
- ret = info->setup(pdev, plat);
+ ret = setup(pdev, plat);
if (ret)
return ret;
@@ -312,15 +302,15 @@ static SIMPLE_DEV_PM_OPS(stmmac_pm_ops, stmmac_suspend,
stmmac_resume);
#define STMMAC_QUARK_ID 0x0937
#define STMMAC_DEVICE_ID 0x1108
-#define STMMAC_DEVICE(vendor_id, dev_id, info) { \
+#define STMMAC_DEVICE(vendor_id, dev_id, setup){ \
PCI_VDEVICE(vendor_id, dev_id), \
- .driver_data = (kernel_ulong_t)&info\
+ .driver_data = (kernel_ulong_t)&setup \
}
static const struct pci_device_id stmmac_id_table[] = {
- STMMAC_DEVICE(STMMAC, STMMAC_DEVICE_ID, stmmac_pci_info),
- STMMAC_DEVICE(STMICRO, PCI_DEVICE_ID_STMICRO_MAC, stmmac_pci_info),
- STMMAC_DEVICE(INTEL, STMMAC_QUARK_ID, quark_pci_info),
+ STMMAC_DEVICE(STMMAC, STMMAC_DEVICE_ID, stmmac_default_setup),
+ STMMAC_DEVICE(STMICRO, PCI_DEVICE_ID_STMICRO_MAC, stmmac_default_setup),
+ STMMAC_DEVICE(INTEL, STMMAC_QUARK_ID, quark_default_setup),
{}
};
--
2.12.3
[PATCH v4 0/6] stmmac: pci: Refactor DMI probing
Some cleanups of the way we probe DMI platforms in the driver. Reduces a bit of open-coding and makes the logic easier reusable for any potential DMI platform != Quark. Tested on IOT2000 and Galileo Gen2. Changes in v4: - Refactor patch 5 according to feedback Jan Jan Kiszka (6): stmmac: pci: Make stmmac_pci_info structure constant stmmac: pci: Use stmmac_pci_info for all devices stmmac: pci: Make stmmac_pci_find_phy_addr truly generic stmmac: pci: Select quark_pci_dmi_data from quark_default_data stmmac: pci: Use dmi_system_id table for retrieving PHY addresses stmmac: pci: Remove setup handler indirection via stmmac_pci_info drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 205 +-- 1 file changed, 119 insertions(+), 86 deletions(-) -- 2.12.3
[PATCH v4 2/6] stmmac: pci: Use stmmac_pci_info for all devices
Make stmmac_default_data compatible with stmmac_pci_info.setup and use
an info structure for all devices. This allows to make the probing more
regular.
Signed-off-by: Jan Kiszka
Reviewed-by: Andy Shevchenko
---
drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 36 +++-
1 file changed, 23 insertions(+), 13 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
index 0efe42659a37..d3d74e526e17 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
@@ -100,7 +100,9 @@ static void common_default_data(struct plat_stmmacenet_data
*plat)
plat->rx_queues_cfg[0].pkt_route = 0x0;
}
-static void stmmac_default_data(struct plat_stmmacenet_data *plat)
+static int stmmac_default_data(struct pci_dev *pdev,
+ struct plat_stmmacenet_data *plat,
+ const struct stmmac_pci_info *info)
{
/* Set common default data first */
common_default_data(plat);
@@ -112,8 +114,14 @@ static void stmmac_default_data(struct
plat_stmmacenet_data *plat)
plat->dma_cfg->pbl = 32;
plat->dma_cfg->pblx8 = true;
/* TODO: AXI */
+
+ return 0;
}
+static const struct stmmac_pci_info stmmac_pci_info = {
+ .setup = stmmac_default_data,
+};
+
static int quark_default_data(struct pci_dev *pdev,
struct plat_stmmacenet_data *plat,
const struct stmmac_pci_info *info)
@@ -236,14 +244,9 @@ static int stmmac_pci_probe(struct pci_dev *pdev,
pci_set_master(pdev);
- if (info) {
- if (info->setup) {
- ret = info->setup(pdev, plat, info);
- if (ret)
- return ret;
- }
- } else
- stmmac_default_data(plat);
+ ret = info->setup(pdev, plat, info);
+ if (ret)
+ return ret;
pci_enable_msi(pdev);
@@ -269,14 +272,21 @@ static void stmmac_pci_remove(struct pci_dev *pdev)
static SIMPLE_DEV_PM_OPS(stmmac_pm_ops, stmmac_suspend, stmmac_resume);
-#define STMMAC_VENDOR_ID 0x700
+/* synthetic ID, no official vendor */
+#define PCI_VENDOR_ID_STMMAC 0x700
+
#define STMMAC_QUARK_ID 0x0937
#define STMMAC_DEVICE_ID 0x1108
+#define STMMAC_DEVICE(vendor_id, dev_id, info) { \
+ PCI_VDEVICE(vendor_id, dev_id), \
+ .driver_data = (kernel_ulong_t)&info\
+ }
+
static const struct pci_device_id stmmac_id_table[] = {
- {PCI_DEVICE(STMMAC_VENDOR_ID, STMMAC_DEVICE_ID)},
- {PCI_DEVICE(PCI_VENDOR_ID_STMICRO, PCI_DEVICE_ID_STMICRO_MAC)},
- {PCI_VDEVICE(INTEL, STMMAC_QUARK_ID), (kernel_ulong_t)&quark_pci_info},
+ STMMAC_DEVICE(STMMAC, STMMAC_DEVICE_ID, stmmac_pci_info),
+ STMMAC_DEVICE(STMICRO, PCI_DEVICE_ID_STMICRO_MAC, stmmac_pci_info),
+ STMMAC_DEVICE(INTEL, STMMAC_QUARK_ID, quark_pci_info),
{}
};
--
2.12.3
[PATCH v4 5/6] stmmac: pci: Use dmi_system_id table for retrieving PHY addresses
Avoids reimplementation of DMI matching in stmmac_pci_find_phy_addr.
Signed-off-by: Jan Kiszka
---
drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 99
1 file changed, 66 insertions(+), 33 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
index a6e10d3ced5c..2be15a8a9c40 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
@@ -30,36 +30,39 @@
* negative value of the address means that MAC controller is not connected
* with PHY.
*/
-struct stmmac_pci_dmi_data {
- const char *name;
- const char *asset_tag;
+struct stmmac_pci_func_data {
unsigned int func;
int phy_addr;
};
+struct stmmac_pci_dmi_data {
+ const struct stmmac_pci_func_data *func;
+ size_t nfuncs;
+};
+
struct stmmac_pci_info {
int (*setup)(struct pci_dev *pdev, struct plat_stmmacenet_data *plat);
};
static int stmmac_pci_find_phy_addr(struct pci_dev *pdev,
- struct stmmac_pci_dmi_data *dmi_data)
+ const struct dmi_system_id *dmi_list)
{
- const char *name = dmi_get_system_info(DMI_BOARD_NAME);
- const char *asset_tag = dmi_get_system_info(DMI_BOARD_ASSET_TAG);
- unsigned int func = PCI_FUNC(pdev->devfn);
- struct stmmac_pci_dmi_data *dmi;
-
- if (!name)
+ const struct stmmac_pci_func_data *func_data;
+ const struct stmmac_pci_dmi_data *dmi_data;
+ const struct dmi_system_id *dmi_id;
+ int func = PCI_FUNC(pdev->devfn);
+ size_t n;
+
+ dmi_id = dmi_first_match(dmi_list);
+ if (!dmi_id)
return -ENODEV;
- for (dmi = dmi_data; dmi->name && *dmi->name; dmi++) {
- if (!strcmp(dmi->name, name) && dmi->func == func) {
- /* If asset tag is provided, match on it as well. */
- if (dmi->asset_tag && strcmp(dmi->asset_tag, asset_tag))
- continue;
- return dmi->phy_addr;
- }
- }
+ dmi_data = dmi_id->driver_data;
+ func_data = dmi_data->func;
+
+ for (n = 0; n < dmi_data->nfuncs; n++, func_data++)
+ if (func_data->func == func)
+ return func_data->phy_addr;
return -ENODEV;
}
@@ -115,34 +118,64 @@ static const struct stmmac_pci_info stmmac_pci_info = {
.setup = stmmac_default_data,
};
-static struct stmmac_pci_dmi_data quark_pci_dmi_data[] = {
+static const struct stmmac_pci_func_data galileo_stmmac_func_data[] = {
{
- .name = "Galileo",
.func = 6,
.phy_addr = 1,
},
+ { },
+};
+
+static const struct stmmac_pci_dmi_data galileo_stmmac_dmi_data = {
+ .func = galileo_stmmac_func_data,
+ .nfuncs = ARRAY_SIZE(galileo_stmmac_func_data),
+};
+
+static const struct stmmac_pci_func_data iot2040_stmmac_func_data[] = {
{
- .name = "GalileoGen2",
.func = 6,
.phy_addr = 1,
},
{
- .name = "SIMATIC IOT2000",
- .asset_tag = "6ES7647-0AA00-0YA2",
- .func = 6,
+ .func = 7,
.phy_addr = 1,
},
+ { },
+};
+
+static const struct stmmac_pci_dmi_data iot2040_stmmac_dmi_data = {
+ .func = iot2040_stmmac_func_data,
+ .nfuncs = ARRAY_SIZE(iot2040_stmmac_func_data),
+};
+
+static const struct dmi_system_id quark_pci_dmi[] = {
{
- .name = "SIMATIC IOT2000",
- .asset_tag = "6ES7647-0AA00-1YA2",
- .func = 6,
- .phy_addr = 1,
+ .matches = {
+ DMI_EXACT_MATCH(DMI_BOARD_NAME, "Galileo"),
+ },
+ .driver_data = (void *)&galileo_stmmac_dmi_data,
},
{
- .name = "SIMATIC IOT2000",
- .asset_tag = "6ES7647-0AA00-1YA2",
- .func = 7,
- .phy_addr = 1,
+ .matches = {
+ DMI_EXACT_MATCH(DMI_BOARD_NAME, "GalileoGen2"),
+ },
+ .driver_data = (void *)&galileo_stmmac_dmi_data,
+ },
+ {
+ .matches = {
+ DMI_EXACT_MATCH(DMI_BOARD_NAME, "SIMATIC IOT2000"),
+ DMI_EXACT_MATCH(DMI_BOARD_ASSET_TAG,
+ "6ES7647-0AA00-0YA2"),
+ },
+ .driver_data = (void *)&galileo_stmmac_dmi_data,
+ },
+ {
+ .matches = {
+ DMI_EXACT_MATCH(DMI_BOARD_NAME, "SIMATIC IOT2000"),
+ DMI_EXACT_MATCH(DMI_BOARD_ASSET_TAG,
+ "6ES7647-0AA00-1YA2"),
+ },
+ .driver_data = (void *)&iot2040_s
[PATCH v4 4/6] stmmac: pci: Select quark_pci_dmi_data from quark_default_data
No need to carry this reference in stmmac_pci_info - the Quark-specific
setup handler knows that it needs to use the Quark-specific DMI table.
This also allows to drop the stmmac_pci_info reference from the setup
handler parameter list.
Signed-off-by: Jan Kiszka
Reviewed-by: Andy Shevchenko
---
drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 83 +++-
1 file changed, 39 insertions(+), 44 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
index f44ae49eb11c..a6e10d3ced5c 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
@@ -38,13 +38,11 @@ struct stmmac_pci_dmi_data {
};
struct stmmac_pci_info {
- int (*setup)(struct pci_dev *pdev, struct plat_stmmacenet_data *plat,
-const struct stmmac_pci_info *info);
- struct stmmac_pci_dmi_data *dmi;
+ int (*setup)(struct pci_dev *pdev, struct plat_stmmacenet_data *plat);
};
static int stmmac_pci_find_phy_addr(struct pci_dev *pdev,
- const struct stmmac_pci_info *info)
+ struct stmmac_pci_dmi_data *dmi_data)
{
const char *name = dmi_get_system_info(DMI_BOARD_NAME);
const char *asset_tag = dmi_get_system_info(DMI_BOARD_ASSET_TAG);
@@ -54,7 +52,7 @@ static int stmmac_pci_find_phy_addr(struct pci_dev *pdev,
if (!name)
return -ENODEV;
- for (dmi = info->dmi; dmi->name && *dmi->name; dmi++) {
+ for (dmi = dmi_data; dmi->name && *dmi->name; dmi++) {
if (!strcmp(dmi->name, name) && dmi->func == func) {
/* If asset tag is provided, match on it as well. */
if (dmi->asset_tag && strcmp(dmi->asset_tag, asset_tag))
@@ -97,8 +95,7 @@ static void common_default_data(struct plat_stmmacenet_data
*plat)
}
static int stmmac_default_data(struct pci_dev *pdev,
- struct plat_stmmacenet_data *plat,
- const struct stmmac_pci_info *info)
+ struct plat_stmmacenet_data *plat)
{
/* Set common default data first */
common_default_data(plat);
@@ -118,9 +115,40 @@ static const struct stmmac_pci_info stmmac_pci_info = {
.setup = stmmac_default_data,
};
+static struct stmmac_pci_dmi_data quark_pci_dmi_data[] = {
+ {
+ .name = "Galileo",
+ .func = 6,
+ .phy_addr = 1,
+ },
+ {
+ .name = "GalileoGen2",
+ .func = 6,
+ .phy_addr = 1,
+ },
+ {
+ .name = "SIMATIC IOT2000",
+ .asset_tag = "6ES7647-0AA00-0YA2",
+ .func = 6,
+ .phy_addr = 1,
+ },
+ {
+ .name = "SIMATIC IOT2000",
+ .asset_tag = "6ES7647-0AA00-1YA2",
+ .func = 6,
+ .phy_addr = 1,
+ },
+ {
+ .name = "SIMATIC IOT2000",
+ .asset_tag = "6ES7647-0AA00-1YA2",
+ .func = 7,
+ .phy_addr = 1,
+ },
+ {}
+};
+
static int quark_default_data(struct pci_dev *pdev,
- struct plat_stmmacenet_data *plat,
- const struct stmmac_pci_info *info)
+ struct plat_stmmacenet_data *plat)
{
int ret;
@@ -131,7 +159,7 @@ static int quark_default_data(struct pci_dev *pdev,
* Refuse to load the driver and register net device if MAC controller
* does not connect to any PHY interface.
*/
- ret = stmmac_pci_find_phy_addr(pdev, info);
+ ret = stmmac_pci_find_phy_addr(pdev, quark_pci_dmi_data);
if (ret < 0) {
/* Return error to the caller on DMI enabled boards. */
if (dmi_get_system_info(DMI_BOARD_NAME))
@@ -157,41 +185,8 @@ static int quark_default_data(struct pci_dev *pdev,
return 0;
}
-static struct stmmac_pci_dmi_data quark_pci_dmi_data[] = {
- {
- .name = "Galileo",
- .func = 6,
- .phy_addr = 1,
- },
- {
- .name = "GalileoGen2",
- .func = 6,
- .phy_addr = 1,
- },
- {
- .name = "SIMATIC IOT2000",
- .asset_tag = "6ES7647-0AA00-0YA2",
- .func = 6,
- .phy_addr = 1,
- },
- {
- .name = "SIMATIC IOT2000",
- .asset_tag = "6ES7647-0AA00-1YA2",
- .func = 6,
- .phy_addr = 1,
- },
- {
- .name = "SIMATIC IOT2000",
- .asset_tag = "6ES7647-0AA00-1YA2",
- .func = 7,
- .phy_addr = 1,
- },
- {}
-};
-
static const struct stmmac_pci_info quark_pci_info = {
.setup = quark_
[PATCH] ahci: qoriq: add ls1088a platforms support
Ls1088a is new introduced arm-based soc with sata support with
following features:
* Complies with the serial ATA 3.0 specification
and the AHCI 1.3.1 specification
* Contains a high-speed descriptor-based DMA controller
* Supports the following:
* Speeds of 1.5 Gb/s (first-generation SATA),
3 Gb/s (second-generation SATA), and 6 Gb/s (third-generation SATA)
* FIS-based switching
* Native command queuing (NCQ) commands
* Port multiplier operation
* Asynchronous notification
* SATA Vendor BIST mode
Signed-off-by: Tang Yuantian
---
drivers/ata/ahci_qoriq.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/ata/ahci_qoriq.c b/drivers/ata/ahci_qoriq.c
index 4c96f3a..b6b0bf7 100644
--- a/drivers/ata/ahci_qoriq.c
+++ b/drivers/ata/ahci_qoriq.c
@@ -47,12 +47,14 @@
#define SATA_ECC_DISABLE 0x0002
#define ECC_DIS_ARMV8_CH2 0x8000
+#define ECC_DIS_LS1088A0x4000
enum ahci_qoriq_type {
AHCI_LS1021A,
AHCI_LS1043A,
AHCI_LS2080A,
AHCI_LS1046A,
+ AHCI_LS1088A,
AHCI_LS2088A,
};
@@ -68,6 +70,7 @@ static const struct of_device_id ahci_qoriq_of_match[] = {
{ .compatible = "fsl,ls1043a-ahci", .data = (void *)AHCI_LS1043A},
{ .compatible = "fsl,ls2080a-ahci", .data = (void *)AHCI_LS2080A},
{ .compatible = "fsl,ls1046a-ahci", .data = (void *)AHCI_LS1046A},
+ { .compatible = "fsl,ls1088a-ahci", .data = (void *)AHCI_LS1088A},
{ .compatible = "fsl,ls2088a-ahci", .data = (void *)AHCI_LS2088A},
{},
};
@@ -203,6 +206,17 @@ static int ahci_qoriq_phy_init(struct ahci_host_priv
*hpriv)
writel(AHCI_PORT_AXICC_CFG, reg_base + PORT_AXICC);
break;
+ case AHCI_LS1088A:
+ if (!qpriv->ecc_addr)
+ return -EINVAL;
+ writel(readl(qpriv->ecc_addr) | ECC_DIS_LS1088A,
+ qpriv->ecc_addr);
+ writel(AHCI_PORT_PHY_1_CFG, reg_base + PORT_PHY1);
+ writel(AHCI_PORT_TRANS_CFG, reg_base + PORT_TRANS);
+ if (qpriv->is_dmacoherent)
+ writel(AHCI_PORT_AXICC_CFG, reg_base + PORT_AXICC);
+ break;
+
case AHCI_LS2088A:
writel(AHCI_PORT_PHY_1_CFG, reg_base + PORT_PHY1);
writel(AHCI_PORT_TRANS_CFG, reg_base + PORT_TRANS);
--
2.1.0.27.g96db324
Re: [PATCH v2] um: Avoid longjmp/setjmp symbol clashes with libpthread.a
Thomas, Am 02.06.2017 um 07:49 schrieb Florian Fainelli: >> the put_fp_registers fails with errno 4 if I recall correctly. >> >> I didn't investigate yet further, why the the xstate ptrace call fails. > > Which of the branches is put_fp_registers() taking? The > restore_fpx_registers() or restore_fp_registers()? 4 would be EINTR... > What kernel version is used on your host running the UML binary? Another question, is this x86_64 UML on a x86_64 host? Or i386 on x86_64, i386 on i386? Thanks, //richard
Re: [PATCH 1/9] mm: introduce kv[mz]alloc helpers
On Fri, Jun 02, 2017 at 09:28:56AM +0200, Michal Hocko wrote:
> On Fri 02-06-17 07:17:22, Sasha Levin wrote:
> > On Mon, Mar 06, 2017 at 11:30:24AM +0100, Michal Hocko wrote:
> > > +void *kvmalloc_node(size_t size, gfp_t flags, int node)
> > > +{
> > > + gfp_t kmalloc_flags = flags;
> > > + void *ret;
> > > +
> > > + /*
> > > + * vmalloc uses GFP_KERNEL for some internal allocations (e.g page
> > > tables)
> > > + * so the given set of flags has to be compatible.
> > > + */
> > > + WARN_ON_ONCE((flags & GFP_KERNEL) != GFP_KERNEL);
> >
> > Hm, there are quite a few locations in the kernel that do something like:
> >
> > __vmalloc(len, GFP_NOFS, PAGE_KERNEL);
> >
> > According to your patch, vmalloc can't really do GFP_NOFS, right?
>
> Yes. It is quite likely that they will just work because the hardcoded
> GFP_KERNEL inside the vmalloc path is in unlikely paths (page table
> allocations for example) but yes they are broken. I didn't convert some
> places which opencode the kvmalloc with GFP_NOFS because I strongly
> _believe_ that the GFP_NOFS should be revisited, checked whether it is
> needed, documented if so and then memalloc_nofs__{save,restore} be used
> for the scope which is reclaim recursion unsafe. This would turn all
> those vmalloc users to the default GFP_KERNEL and still do the right
> thing.
While you haven't converted those paths, other folks have picked up
on that:
commit beeeccca9bebcec386cc31c250cff8a06cf27034
Author: Vinnie Magro
Date: Thu May 25 12:18:02 2017 -0700
btrfs: Use kvzalloc instead of kzalloc/vmalloc in alloc_bitmap
[...]
Maybe we should make kvmalloc_node() fail non-GFP_KERNEL allocations
rather than just warn on them to make this error more evident? I'm not
sure how these warnings were missed during testing.
--
Thanks,
Sasha
Re: [PATCH 1/9] mm: introduce kv[mz]alloc helpers
On Fri 02-06-17 07:40:12, Sasha Levin wrote:
> On Fri, Jun 02, 2017 at 09:28:56AM +0200, Michal Hocko wrote:
> > On Fri 02-06-17 07:17:22, Sasha Levin wrote:
> > > On Mon, Mar 06, 2017 at 11:30:24AM +0100, Michal Hocko wrote:
> > > > +void *kvmalloc_node(size_t size, gfp_t flags, int node)
> > > > +{
> > > > + gfp_t kmalloc_flags = flags;
> > > > + void *ret;
> > > > +
> > > > + /*
> > > > +* vmalloc uses GFP_KERNEL for some internal allocations (e.g
> > > > page tables)
> > > > +* so the given set of flags has to be compatible.
> > > > +*/
> > > > + WARN_ON_ONCE((flags & GFP_KERNEL) != GFP_KERNEL);
> > >
> > > Hm, there are quite a few locations in the kernel that do something like:
> > >
> > > __vmalloc(len, GFP_NOFS, PAGE_KERNEL);
> > >
> > > According to your patch, vmalloc can't really do GFP_NOFS, right?
> >
> > Yes. It is quite likely that they will just work because the hardcoded
> > GFP_KERNEL inside the vmalloc path is in unlikely paths (page table
> > allocations for example) but yes they are broken. I didn't convert some
> > places which opencode the kvmalloc with GFP_NOFS because I strongly
> > _believe_ that the GFP_NOFS should be revisited, checked whether it is
> > needed, documented if so and then memalloc_nofs__{save,restore} be used
> > for the scope which is reclaim recursion unsafe. This would turn all
> > those vmalloc users to the default GFP_KERNEL and still do the right
> > thing.
>
> While you haven't converted those paths, other folks have picked up
> on that:
>
> commit beeeccca9bebcec386cc31c250cff8a06cf27034
> Author: Vinnie Magro
> Date: Thu May 25 12:18:02 2017 -0700
>
> btrfs: Use kvzalloc instead of kzalloc/vmalloc in alloc_bitmap
> [...]
>
> Maybe we should make kvmalloc_node() fail non-GFP_KERNEL allocations
> rather than just warn on them to make this error more evident?
The above has been already discussed [1] and will be dropped with a more
appropriate alternative. I do not think we should be failing those,
though. Supported flags are documented and the warn on will tell that
something is clearly wrong.
> I'm not sure how these warnings were missed during testing.
I suspect this conversion just hasn't been tested because it is an
"obvious cleanup"
[1] http://lkml.kernel.org/r/20170531063033.GC1795@yexl-desktop
--
Michal Hocko
SUSE Labs
Re: [PATCH v6 0/7] perf report: Show branch type
Hi maintainers,
Is this patch series (v6) OK for merging?
Thanks
Jin Yao
On 4/20/2017 5:36 PM, Jiri Olsa wrote:
On Thu, Apr 20, 2017 at 08:07:48PM +0800, Jin Yao wrote:
v6:
Update according to the review comments from
Jiri Olsa . Major modifications are:
1. Move that multiline conditional code inside {} brackets.
2. Move branch_type_stat_display() from builtin-report.c to
branch.c. Move branch_type_str() from callchain.c to
branch.c.
3. Keep the original branch info display order, that is:
predicted, abort, cycles, iterations
for the tools part
Acked-by: Jiri Olsa
thanks,
jirka
Re: [PATCH v2] um: Avoid longjmp/setjmp symbol clashes with libpthread.a
Am Donnerstag, den 01.06.2017, 22:49 -0700 schrieb Florian Fainelli:
>
> On 06/01/2017 02:25 PM, Thomas Meyer wrote:
> > Am Donnerstag, den 01.06.2017, 22:58 +0200 schrieb Richard
> > Weinberger:
> > >
> > > Sorry, I thought you are CC'ed.
> > > Thomas please speak up. AFAIR UML fails to boot on one of your
> > > new
> > > Laptops.
> >
> > Hi,
> >
> > yes, the first userspace process failes here:
> >
> > void userspace(struct uml_pt_regs *regs)
> > {
> > int err, status, op, pid = userspace_pid[0];
> > /* To prevent races if using_sysemu changes under us.*/
> > int local_using_sysemu;
> > siginfo_t si;
> >
> > /* Handle any immediate reschedules or signals */
> > interrupt_end();
> >
> > while (1) {
> >
> > /*
> > * This can legitimately fail if the process loads
> > a
> > * bogus value into a segment register. It will
> > * segfault and PTRACE_GETREGS will read that value
> > * out of the process. However, PTRACE_SETREGS
> > will
> > * fail. In this case, there is nothing to do but
> > * just kill the process.
> > */
> > if (ptrace(PTRACE_SETREGS, pid, 0, regs->gp))
> > fatal_sigsegv();
> >
> > if (put_fp_registers(pid, regs->fp))
> > ->fatal_sigsegv();
> >
> > the put_fp_registers fails with errno 4 if I recall correctly.
> >
> > I didn't investigate yet further, why the the xstate ptrace call
> > fails.
>
> Which of the branches is put_fp_registers() taking?
#0 restore_fp_registers (pid=2226, fp_regs=0xafcbf738) at
arch/x86/um/os-Linux/registers.c:57
#1 0x60084c80 in put_fp_registers (pid=,
regs=) at arch/x86/um/os-Linux/registers.c:124
#2 0x600814e1 in userspace (regs=0xafcbf660) at
arch/um/os-Linux/skas/process.c:329
#3 0x60070fc1 in new_thread_handler () at arch/um/kernel/process.c:134
#4 0x in ?? ()
> The restore_fpx_registers() or restore_fp_registers()?
> 4 would be EINTR...
Yes, strange, indeed.
> What kernel version is used on your host running the UML binary?
It's a VirtualBox with Fedora 25 and "Linux localhost.localdomain
4.10.15-200.fc25.x86_64 #1 SMP Mon May 8 18:46:06 UTC 2017 x86_64 x86_64 x86_64
GNU/Linux"
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 142
model name : Intel(R) Core(TM) i7-7500U CPU @ 2.70GHz
stepping: 9
cpu MHz : 2904.002
cache size : 4096 KB
physical id : 0
siblings: 2
core id : 0
cpu cores : 2
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 22
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr
pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx rdtscp
lm constant_tsc rep_good nopl xtopology nonstop_tsc pni pclmulqdq ssse3
cx16 sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx rdrand hypervisor
lahf_lm abm 3dnowprefetch rdseed clflushopt
bugs:
bogomips: 5808.00
clflush size: 64
cache_alignment : 64
address sizes : 39 bits physical, 48 bits virtual
power management:
I see this in the kernel log:
[0.00] [ cut here ]
[0.00] WARNING: CPU: 0 PID: 0 at arch/x86/kernel/fpu/xstate.c:595
fpu__init_system_xstate+0x4d0/0x877
[0.00] XSAVE consistency problem, dumping leaves
[0.00] Modules linked in:
[0.00] CPU: 0 PID: 0 Comm: swapper Not tainted 4.10.15-200.fc25.x86_64
#1
[0.00] Call Trace:
[0.00] dump_stack+0x63/0x86
[0.00] __warn+0xcb/0xf0
[0.00] warn_slowpath_fmt+0x5f/0x80
[0.00] ? xfeature_size+0x5a/0x78
[0.00] fpu__init_system_xstate+0x4d0/0x877
[0.00] ? msr_clear_bit+0x3a/0xa0
[0.00] ? 0xa300
[0.00] fpu__init_system+0x194/0x1be
[0.00] early_cpu_init+0xf7/0xf9
[0.00] setup_arch+0xba/0xcf0
[0.00] ? printk+0x57/0x73
[0.00] ? early_idt_handler_array+0x120/0x120
[0.00] start_kernel+0xb2/0x48a
[0.00] ? early_idt_handler_array+0x120/0x120
[0.00] x86_64_start_reservations+0x24/0x26
[0.00] x86_64_start_kernel+0x14d/0x170
[0.00] start_cpu+0x14/0x14
[0.00] ---[ end trace d5213d72358dda94 ]---
[0.00] CPUID[0d, 00]: eax=0007 ebx=0440 ecx=0440
edx=
[...]
[0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point
registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
[0.00] x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256
[0.00] x86/fpu: Enabled xstate features 0x7, context size is 1088
bytes, using 'standard' format.
UML
Re: [PATCH v3 net-next 1/3] perf, bpf: Add BPF support to all perf_event types
On Thu, Jun 01, 2017 at 07:03:34PM -0700, Alexei Starovoitov wrote:
> diff --git a/kernel/bpf/arraymap.c b/kernel/bpf/arraymap.c
> index 172dc8ee0e3b..ab93490d1a00 100644
> --- a/kernel/bpf/arraymap.c
> +++ b/kernel/bpf/arraymap.c
> @@ -452,39 +452,18 @@ static void bpf_event_entry_free_rcu(struct
> bpf_event_entry *ee)
> static void *perf_event_fd_array_get_ptr(struct bpf_map *map,
>struct file *map_file, int fd)
> {
> - const struct perf_event_attr *attr;
> struct bpf_event_entry *ee;
> - struct perf_event *event;
> struct file *perf_file;
>
> perf_file = perf_event_get(fd);
> if (IS_ERR(perf_file))
> return perf_file;
>
> - event = perf_file->private_data;
> - ee = ERR_PTR(-EINVAL);
> -
> - attr = perf_event_attrs(event);
> - if (IS_ERR(attr) || attr->inherit)
> - goto err_out;
> -
> - switch (attr->type) {
> - case PERF_TYPE_SOFTWARE:
> - if (attr->config != PERF_COUNT_SW_BPF_OUTPUT)
> - goto err_out;
> - /* fall-through */
> - case PERF_TYPE_RAW:
> - case PERF_TYPE_HARDWARE:
> - ee = bpf_event_entry_gen(perf_file, map_file);
> - if (ee)
> - return ee;
> - ee = ERR_PTR(-ENOMEM);
> - /* fall-through */
> - default:
> - break;
> - }
Would it make sense to call perf_event_read_local() on the events here
in order to weed out the -EOPNOTSUPP ones?
> + ee = bpf_event_entry_gen(perf_file, map_file);
> + if (ee)
> + return ee;
>
> -err_out:
> + ee = ERR_PTR(-ENOMEM);
> fput(perf_file);
> return ee;
> }
Re: [PATCH RFC 0/2] KVM: s390: avoid having to enable vm.alloc_pgste
On Fri, 2 Jun 2017 09:25:54 +0200 Christian Borntraeger wrote: > On 06/02/2017 09:18 AM, Christian Borntraeger wrote: > > On 06/02/2017 09:16 AM, Martin Schwidefsky wrote: > >> On Fri, 2 Jun 2017 09:13:03 +0200 > >> Christian Borntraeger wrote: > >> > >>> On 06/02/2017 09:02 AM, Heiko Carstens wrote: > On Thu, Jun 01, 2017 at 12:46:51PM +0200, Martin Schwidefsky wrote: > >> Unfortunately, converting all page tables to 4k pgste page tables is > >> not possible without provoking various race conditions. > > > > That is one approach we tried and was found to be buggy. The point is > > that > > you are not allowed to reallocate a page table while a VMA exists that > > is > > in the address range of that page table. > > > > Another approach we tried is to use an ELF flag on the qemu executable. > > That does not work either because fs/exec.c allocates and populates the > > new mm struct for the argument pages before fs/binfmt_elf.c comes into > > play. > > How about if you would fail the system call within arch_check_elf() if > you > detect that the binary requires pgstes (as indicated by elf flags) and > then > restart the system call? > > That is: arch_check_elf() e.g. would set a thread flag that future mm's > should be allocated with pgstes. Then do_execve() would cleanup > everything > and return to entry.S. Upon return to userspace we detect this condition > and simply restart the system call, similar to signals vs -ERESTARTSYS. > > That would make do_execve() cleanup everything and upon reentering it > would > allocate an mm with the pgste flag set. > > Maybe this is a bit over-simplified, but might work. > > At least I also don't like the next "hack", that is specifically designed > to only work with how QEMU is currently implemented. It might break with > future QEMU changes or the next user space implementation that drives the > kvm interface, but is doing everything differently. > Let's look for a "clean" solution that will always work. We had too many > hacks for this problem and *all* of them were broken. > >>> > >>> > >>> The more I think about it, dropping 2k page tables and always allocate a > >>> full > >>> page would simplify pgalloc. As far I can see this would also get rid of > >>> the &mm->context.pgtable_lock. > >> > >> And it would waste twice the amount of memory for page tables. NAK. > > > > Yes and we spend the same amount of memory TODAY, because every distro on > > the > > planet that uses KVM has sysctl.allocate_pgste set. > > Maybe todays approach might be still the best. (if qemu is installed, its all > 4k, if not its all 2k) Exactly- -- blue skies, Martin. "Reality continues to ruin my life." - Calvin.
Re: [PATCH v2] mm,oom: add tracepoints for oom reaper-related events
On Thu 01-06-17 19:41:13, Roman Gushchin wrote: > On Wed, May 31, 2017 at 06:39:29PM +0200, Michal Hocko wrote: > > On Tue 30-05-17 19:52:31, Roman Gushchin wrote: > > > >From c57e3674efc609f8364f5e228a2c1309cfe99901 Mon Sep 17 00:00:00 2001 > > > From: Roman Gushchin > > > Date: Tue, 23 May 2017 17:37:55 +0100 > > > Subject: [PATCH v2] mm,oom: add tracepoints for oom reaper-related events > > > > > > During the debugging of the problem described in > > > https://lkml.org/lkml/2017/5/17/542 and fixed by Tetsuo Handa > > > in https://lkml.org/lkml/2017/5/19/383 , I've found that > > > the existing debug output is not really useful to understand > > > issues related to the oom reaper. > > > > > > So, I assume, that adding some tracepoints might help with > > > debugging of similar issues. > > > > > > Trace the following events: > > > 1) a process is marked as an oom victim, > > > 2) a process is added to the oom reaper list, > > > 3) the oom reaper starts reaping process's mm, > > > 4) the oom reaper finished reaping, > > > 5) the oom reaper skips reaping. > > > > > > How it works in practice? Below is an example which show > > > how the problem mentioned above can be found: one process is added > > > twice to the oom_reaper list: > > > > > > $ cd /sys/kernel/debug/tracing > > > $ echo "oom:mark_victim" > set_event > > > $ echo "oom:wake_reaper" >> set_event > > > $ echo "oom:skip_task_reaping" >> set_event > > > $ echo "oom:start_task_reaping" >> set_event > > > $ echo "oom:finish_task_reaping" >> set_event > > > $ cat trace_pipe > > > allocate-502 [001] 91.836405: mark_victim: pid=502 > > > allocate-502 [001] .N..91.837356: wake_reaper: pid=502 > > > allocate-502 [000] .N..91.871149: wake_reaper: pid=502 > > > oom_reaper-23[000] 91.871177: start_task_reaping: > > > pid=502 > > > oom_reaper-23[000] .N..91.879511: finish_task_reaping: > > > pid=502 > > > oom_reaper-23[000] 91.879580: skip_task_reaping: pid=502 > > > > OK, this is much better! The clue here would be that we got 2 > > wakeups for the same task, right? > > Do you think it would make sense to put more context to those > > tracepoints? E.g. skip_task_reaping can be due to lock contention or the > > mm gone. wake_reaper is similar. > > I agree, that some context might be useful under some circumstances, > but I don't think we should add any additional fields until we will have some > examples > of where this data is actually useful. If we will need it, we can easily add > it later. OK, fair enough. Acked-by: Michal Hocko -- Michal Hocko SUSE Labs
Re: [PATCH] swap: cond_resched in swap_cgroup_prepare()
On Thu 01-06-17 12:56:35, Yu Zhao wrote: > Saw need_resched() warnings when swapping on large swapfile (TBs) > because page allocation in swap_cgroup_prepare() took too long. Hmm, but the page allocator makes sure to cond_resched for sleeping allocations. I guess what you mean is something different. It is not the allocation which took too look but there are too many of them and none of them sleeps because there is enough memory and the allocator doesn't sleep in that case. Right? > We already cond_resched when freeing page in swap_cgroup_swapoff(). > Do the same for the page allocation. > > Signed-off-by: Yu Zhao The patch itself makes sense to me, the changelog could see some clarification but other than that Acked-by: Michal Hocko > --- > mm/swap_cgroup.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/mm/swap_cgroup.c b/mm/swap_cgroup.c > index ac6318a064d3..3405b4ee1757 100644 > --- a/mm/swap_cgroup.c > +++ b/mm/swap_cgroup.c > @@ -48,6 +48,9 @@ static int swap_cgroup_prepare(int type) > if (!page) > goto not_enough_page; > ctrl->map[idx] = page; > + > + if (!(idx % SWAP_CLUSTER_MAX)) > + cond_resched(); > } > return 0; > not_enough_page: > -- > 2.13.0.219.gdb65acc882-goog -- Michal Hocko SUSE Labs
[PATCH 3/7] irqchip/irq-imx-gpcv2: constify irq_domain_ops
struct irq_domain_ops is not modified, so it can be made const.
Signed-off-by: Tobias Klauser
---
drivers/irqchip/irq-imx-gpcv2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/irqchip/irq-imx-gpcv2.c b/drivers/irqchip/irq-imx-gpcv2.c
index 9463f3557e82..bb36f572e322 100644
--- a/drivers/irqchip/irq-imx-gpcv2.c
+++ b/drivers/irqchip/irq-imx-gpcv2.c
@@ -200,7 +200,7 @@ static int imx_gpcv2_domain_alloc(struct irq_domain *domain,
&parent_fwspec);
}
-static struct irq_domain_ops gpcv2_irqchip_data_domain_ops = {
+static const struct irq_domain_ops gpcv2_irqchip_data_domain_ops = {
.translate = imx_gpcv2_domain_translate,
.alloc = imx_gpcv2_domain_alloc,
.free = irq_domain_free_irqs_common,
--
2.13.0
[PATCH 5/7] irqchip/irq-mips-gic: constify irq_domain_ops
struct irq_domain_ops is not modified, so it can be made const.
Signed-off-by: Tobias Klauser
---
drivers/irqchip/irq-mips-gic.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/irqchip/irq-mips-gic.c b/drivers/irqchip/irq-mips-gic.c
index eb7fbe159963..65642a78b8a3 100644
--- a/drivers/irqchip/irq-mips-gic.c
+++ b/drivers/irqchip/irq-mips-gic.c
@@ -874,7 +874,7 @@ int gic_ipi_domain_match(struct irq_domain *d, struct
device_node *node,
}
}
-static struct irq_domain_ops gic_ipi_domain_ops = {
+static const struct irq_domain_ops gic_ipi_domain_ops = {
.xlate = gic_ipi_domain_xlate,
.alloc = gic_ipi_domain_alloc,
.free = gic_ipi_domain_free,
--
2.13.0
[PATCH 6/7] irqchip/irq-renesas-h8300h: constify irq_domain_ops
struct irq_domain_ops is not modified, so it can be made const.
Cc: Yoshinori Sato
Cc: uclinux-h8-de...@lists.sourceforge.jp
Signed-off-by: Tobias Klauser
---
drivers/irqchip/irq-renesas-h8300h.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/irqchip/irq-renesas-h8300h.c
b/drivers/irqchip/irq-renesas-h8300h.c
index c378768d75b3..b8327590ae52 100644
--- a/drivers/irqchip/irq-renesas-h8300h.c
+++ b/drivers/irqchip/irq-renesas-h8300h.c
@@ -67,7 +67,7 @@ static int irq_map(struct irq_domain *h, unsigned int virq,
return 0;
}
-static struct irq_domain_ops irq_ops = {
+static const struct irq_domain_ops irq_ops = {
.map= irq_map,
.xlate = irq_domain_xlate_onecell,
};
--
2.13.0
Re: [PATCH 9/9] [HSLPM] usb: dwc2: Enable LPM
Greg Kroah-Hartman writes: > On Fri, Apr 28, 2017 at 12:56:42PM +0400, Sevak Arakelyan wrote: >> From: John Youn >> >> Set 'lpm_capable' flag in the gadget structure so >> indicating that LPM is supported. >> >> Signed-off-by: Sevak Arakelyan > > No signed-off-by from John? right, I only took two patches from this series. Without John's acked-by, I can't take any dwc2 patches. -- balbi signature.asc Description: PGP signature
[PATCH 0/7] irqchip: constify irq_domain_ops
Constify all remaining non-const instances of irq_domain_ops in the irqchip drivers. These can be made const as they are never modified. Tobias Klauser (7): irqchip/aspeed-vic: constify irq_domain_ops irqchip/i8259: constify irq_domain_ops irqchip/irq-imx-gpcv2: constify irq_domain_ops irqchip/irq-mbigen: constify irq_domain_ops irqchip/irq-mips-gic: constify irq_domain_ops irqchip/irq-renesas-h8300h: constify irq_domain_ops irqchip/irq-renesas-h8s: constify irq_domain_ops drivers/irqchip/irq-aspeed-vic.c | 2 +- drivers/irqchip/irq-i8259.c | 2 +- drivers/irqchip/irq-imx-gpcv2.c | 2 +- drivers/irqchip/irq-mbigen.c | 2 +- drivers/irqchip/irq-mips-gic.c | 2 +- drivers/irqchip/irq-renesas-h8300h.c | 2 +- drivers/irqchip/irq-renesas-h8s.c| 2 +- 7 files changed, 7 insertions(+), 7 deletions(-) -- 2.13.0
[PATCH 7/7] irqchip/irq-renesas-h8s: constify irq_domain_ops
struct irq_domain_ops is not modified, so it can be made const.
Cc: Yoshinori Sato
Cc: uclinux-h8-de...@lists.sourceforge.jp
Signed-off-by: Tobias Klauser
---
drivers/irqchip/irq-renesas-h8s.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/irqchip/irq-renesas-h8s.c
b/drivers/irqchip/irq-renesas-h8s.c
index af8c6c61c824..71d8139be26c 100644
--- a/drivers/irqchip/irq-renesas-h8s.c
+++ b/drivers/irqchip/irq-renesas-h8s.c
@@ -73,7 +73,7 @@ static __init int irq_map(struct irq_domain *h, unsigned int
virq,
return 0;
}
-static struct irq_domain_ops irq_ops = {
+static const struct irq_domain_ops irq_ops = {
.map= irq_map,
.xlate = irq_domain_xlate_onecell,
};
--
2.13.0
[PATCH 2/7] irqchip/i8259: constify irq_domain_ops
struct irq_domain_ops is not modified, so it can be made const.
Signed-off-by: Tobias Klauser
---
drivers/irqchip/irq-i8259.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/irqchip/irq-i8259.c b/drivers/irqchip/irq-i8259.c
index 1aec12c6d9ac..7aafbb091b67 100644
--- a/drivers/irqchip/irq-i8259.c
+++ b/drivers/irqchip/irq-i8259.c
@@ -307,7 +307,7 @@ static int i8259A_irq_domain_map(struct irq_domain *d,
unsigned int virq,
return 0;
}
-static struct irq_domain_ops i8259A_ops = {
+static const struct irq_domain_ops i8259A_ops = {
.map = i8259A_irq_domain_map,
.xlate = irq_domain_xlate_onecell,
};
--
2.13.0
[PATCH 4/7] irqchip/irq-mbigen: constify irq_domain_ops
struct irq_domain_ops is not modified, so it can be made const.
Signed-off-by: Tobias Klauser
---
drivers/irqchip/irq-mbigen.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/irqchip/irq-mbigen.c b/drivers/irqchip/irq-mbigen.c
index 31d6b5a582d2..567b29c47608 100644
--- a/drivers/irqchip/irq-mbigen.c
+++ b/drivers/irqchip/irq-mbigen.c
@@ -228,7 +228,7 @@ static int mbigen_irq_domain_alloc(struct irq_domain
*domain,
return 0;
}
-static struct irq_domain_ops mbigen_domain_ops = {
+static const struct irq_domain_ops mbigen_domain_ops = {
.translate = mbigen_domain_translate,
.alloc = mbigen_irq_domain_alloc,
.free = irq_domain_free_irqs_common,
--
2.13.0
[PATCH 1/7] irqchip/aspeed-vic: constify irq_domain_ops
struct irq_domain_ops is not modified, so it can be made const.
Cc: Joel Stanley
Signed-off-by: Tobias Klauser
---
drivers/irqchip/irq-aspeed-vic.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/irqchip/irq-aspeed-vic.c b/drivers/irqchip/irq-aspeed-vic.c
index d24451d5bf8a..88e139e4c1f9 100644
--- a/drivers/irqchip/irq-aspeed-vic.c
+++ b/drivers/irqchip/irq-aspeed-vic.c
@@ -186,7 +186,7 @@ static int avic_map(struct irq_domain *d, unsigned int irq,
return 0;
}
-static struct irq_domain_ops avic_dom_ops = {
+static const struct irq_domain_ops avic_dom_ops = {
.map = avic_map,
.xlate = irq_domain_xlate_onetwocell,
};
--
2.13.0
Re: [PATCH 1/2] fs: configfs: make qw_sign attribute symmetric
Hi,
Stefan Agner writes:
> Hi Felipe,
>
> On 2017-04-19 01:53, Krzysztof Opasiak wrote:
>> On 04/15/2017 03:35 AM, Stefan Agner wrote:
>>> Currently qw_sign requires UTF-8 character to set, but returns UTF-16
>>> when read. This isn't obvious when simply using cat since the null
>>> characters are not visible, but hexdump unveils the true string:
>>>
>>> # echo MSFT100 > os_desc/qw_sign
>>> # hexdump -C os_desc/qw_sign
>>> 4d 00 53 00 46 00 54 00 31 00 30 00 30 00
>>> |M.S.F.T.1.0.0.|
>>>
>>> Make qw_sign symmetric by returning an UTF-8 string too. Also follow
>>> common convention and add a new line at the end.
>>>
>>> Signed-off-by: Stefan Agner
>>> ---
>>> Resend as discussed here:
>>> https://patchwork.kernel.org/patch/9548869/
>>>
>>> Sorry, a bit later than we discussed... Hope still not too late?
>>>
>>> --
>>> Stefan
>>>
>>> drivers/usb/gadget/configfs.c | 8 ++--
>>> 1 file changed, 6 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/usb/gadget/configfs.c b/drivers/usb/gadget/configfs.c
>>> index cbff3b02840d..863ca4ded1be 100644
>>> --- a/drivers/usb/gadget/configfs.c
>>> +++ b/drivers/usb/gadget/configfs.c
>>> @@ -787,9 +787,13 @@ static ssize_t os_desc_b_vendor_code_store(struct
>>> config_item *item,
>>> static ssize_t os_desc_qw_sign_show(struct config_item *item, char *page)
>>> {
>>> struct gadget_info *gi = os_desc_item_to_gadget_info(item);
>>> + int res;
>>>
>>> - memcpy(page, gi->qw_sign, OS_STRING_QW_SIGN_LEN);
>>> - return OS_STRING_QW_SIGN_LEN;
>>> + res = utf16s_to_utf8s((wchar_t *) gi->qw_sign, OS_STRING_QW_SIGN_LEN,
>>> + UTF16_LITTLE_ENDIAN, page, PAGE_SIZE - 1);
>>> + page[res++] = '\n';
>>> +
>>> + return res;
>>> }
>>>
>>> static ssize_t os_desc_qw_sign_store(struct config_item *item, const char
>>> *page,
>>>
>>
>> Code itself looks good to me and from libusbgx perspective it's also
>> fine to add this new line as we can just drop it like we do with other
>> newlines in case of gadget/config strings.
>>
>> Reviewed-by: Krzysztof Opasiak
>>
>
> Any chance we get this in this merge window?
>
> This still applies fine on v4.12-rc2.
I wouldn't consider this a fix. I'll get this into v4.13 merge window.
--
balbi
signature.asc
Description: PGP signature
Re: [PATCH v2] um: Avoid longjmp/setjmp symbol clashes with libpthread.a
Thomas, Am 02.06.2017 um 10:04 schrieb Thomas Meyer: > Am Donnerstag, den 01.06.2017, 22:49 -0700 schrieb Florian Fainelli: > I see this in the kernel log: > > [0.00] [ cut here ] > [0.00] WARNING: CPU: 0 PID: 0 at arch/x86/kernel/fpu/xstate.c:595 > fpu__init_system_xstate+0x4d0/0x877 > [0.00] XSAVE consistency problem, dumping leaves > [0.00] Modules linked in: > [0.00] CPU: 0 PID: 0 Comm: swapper Not tainted > 4.10.15-200.fc25.x86_64 #1 > [0.00] Call Trace: > [0.00] dump_stack+0x63/0x86 > [0.00] __warn+0xcb/0xf0 > [0.00] warn_slowpath_fmt+0x5f/0x80 > [0.00] ? xfeature_size+0x5a/0x78 > [0.00] fpu__init_system_xstate+0x4d0/0x877 > [0.00] ? msr_clear_bit+0x3a/0xa0 > [0.00] ? 0xa300 > [0.00] fpu__init_system+0x194/0x1be > [0.00] early_cpu_init+0xf7/0xf9 > [0.00] setup_arch+0xba/0xcf0 > [0.00] ? printk+0x57/0x73 > [0.00] ? early_idt_handler_array+0x120/0x120 > [0.00] start_kernel+0xb2/0x48a > [0.00] ? early_idt_handler_array+0x120/0x120 > [0.00] x86_64_start_reservations+0x24/0x26 > [0.00] x86_64_start_kernel+0x14d/0x170 > [0.00] start_cpu+0x14/0x14 > [0.00] ---[ end trace d5213d72358dda94 ]--- > [0.00] CPUID[0d, 00]: eax=0007 ebx=0440 ecx=0440 > edx= Does this also happen with a mainline kernel? Also on KVM or bare metal? Not that UML fails because of this and we're hunting a ghost... Thanks, //richard
Re: [RFC PATCH 00/10] x86: undwarf unwinder
On 06/01/2017, 03:58 PM, Jiri Slaby wrote: > On 06/01/2017, 03:50 PM, Ingo Molnar wrote: >> That's not what I meant! The speedup comes from (hopefully) being able to >> disable >> CONFIG_FRAME_POINTER, which: > > BTW when you are mentioning this -- my measurements were with FP disabled. > > Is there any reasonably simple-to-use benchmark I could run with FP=y > and FP=n quickly? Nevermind, I tried 1000 stack unwindings several times and ran netperf too. Both on the same virtual machine. On these microbenchmarks, the former performs ~ 1.03 times better, the latter ~ 1.3 times. When Mel measured the difference, it was around 10 % overall using more sophisticated benchmarks. With FP=n: # time echo 1000 > /dev/test_dwarf real0m6.659s user0m0.000s sys 0m6.655s # for aa in 1 0 0 0 0; do netperf -P $aa ; done MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to localhost () port 0 AF_INET Recv SendSend Socket Socket Message Elapsed Size SizeSize Time Throughput bytes bytes bytessecs.10^6bits/sec 87380 16384 1638410.0047819.30 87380 16384 1638410.0041991.01 87380 16384 1638410.0043607.82 87380 16384 1638410.0042208.44 87380 16384 1638410.0044383.92 With FP=y: # time echo 1000 > /dev/test_dwarf real0m6.869s user0m0.000s sys 0m6.868s # for aa in 1 0 0 0 0; do netperf -P $aa ; done MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to localhost () port 0 AF_INET Recv SendSend Socket Socket Message Elapsed Size SizeSize Time Throughput bytes bytes bytessecs.10^6bits/sec 87380 16384 1638410.0037807.90 87380 16384 1638410.0032246.67 87380 16384 1638410.0031358.76 87380 16384 1638410.0032450.00 87380 16384 1638410.0031326.70 thanks, -- js suse labs
Re: [PATCH v5 0/3] drm/mali-dp: Add support for memory writeback engine
On Mon, 15 May 2017 18:23:59 +0100 Liviu Dudau wrote: > Hi, > > This series introduces support for Mali DP's memory writeback engine > using the generic writeback connector support introduced in the > "[PATCH v5 0/2] drm: Introduce writeback connectors" series [1] > > This version updates the Mali DP code to remove the bespoke encoder used > with the drm_writeback_connector and instead rely on the builtin one from > the v5 series. > > v4 series can be found here [2]. Whole series is Reviewed-by: Boris Brezillon > > Best regards, > Liviu > > [1] https://lists.freedesktop.org/archives/dri-devel/2017-May/141796.html > [2] https://lists.freedesktop.org/archives/dri-devel/2017-May/140850.html > > Brian Starkey (2): > drm: mali-dp: Add RGB writeback formats for DP550/DP650 > drm: mali-dp: Add writeback connector > > Liviu Dudau (1): > drm: mali-dp: Add support for writeback on DP550/DP650 > > drivers/gpu/drm/arm/Makefile | 1 + > drivers/gpu/drm/arm/malidp_crtc.c | 9 ++ > drivers/gpu/drm/arm/malidp_drv.c | 19 ++- > drivers/gpu/drm/arm/malidp_drv.h | 3 + > drivers/gpu/drm/arm/malidp_hw.c | 88 ++--- > drivers/gpu/drm/arm/malidp_hw.h | 18 +++ > drivers/gpu/drm/arm/malidp_mw.c | 252 > ++ > drivers/gpu/drm/arm/malidp_mw.h | 18 +++ > drivers/gpu/drm/arm/malidp_regs.h | 15 +++ > 9 files changed, 402 insertions(+), 21 deletions(-) > create mode 100644 drivers/gpu/drm/arm/malidp_mw.c > create mode 100644 drivers/gpu/drm/arm/malidp_mw.h >
Re: [PATCH] PCI: rockchip: Handle return value of clk_prepare_enable
Am Donnerstag, 1. Juni 2017, 15:51:45 CEST schrieb Arvind Yadav: > clk_prepare_enable() can fail here and we must check its return value. > > Signed-off-by: Arvind Yadav looks good, but you may want to include Bjorn Helgaas who is the maintainer of the pci subsystem and would be the one to apply your patch. Aynway, the patch itself looks good to me Reviewed-by: Heiko Stuebner Cheers Heiko > --- > drivers/pci/host/pcie-rockchip.c | 34 -- > 1 file changed, 28 insertions(+), 6 deletions(-) > > diff --git a/drivers/pci/host/pcie-rockchip.c > b/drivers/pci/host/pcie-rockchip.c > index 0e020b6..0a248cd 100644 > --- a/drivers/pci/host/pcie-rockchip.c > +++ b/drivers/pci/host/pcie-rockchip.c > @@ -1259,24 +1259,46 @@ static int __maybe_unused > rockchip_pcie_resume_noirq(struct device *dev) > struct rockchip_pcie *rockchip = dev_get_drvdata(dev); > int err; > > - clk_prepare_enable(rockchip->clk_pcie_pm); > - clk_prepare_enable(rockchip->hclk_pcie); > - clk_prepare_enable(rockchip->aclk_perf_pcie); > - clk_prepare_enable(rockchip->aclk_pcie); > + err = clk_prepare_enable(rockchip->clk_pcie_pm); > + if (err) > + goto err_pcie_pm; > + > + err = clk_prepare_enable(rockchip->hclk_pcie); > + if (err) > + goto err_hclk_pcie; > + > + err = clk_prepare_enable(rockchip->aclk_perf_pcie); > + if (err) > + goto err_aclk_perf_pcie; > + > + err = clk_prepare_enable(rockchip->aclk_pcie); > + if (err) > + goto err_aclk_pcie; > > err = rockchip_pcie_init_port(rockchip); > if (err) > - return err; > + goto err_pcie_resume; > > err = rockchip_cfg_atu(rockchip); > if (err) > - return err; > + goto err_pcie_resume; > > /* Need this to enter L1 again */ > rockchip_pcie_update_txcredit_mui(rockchip); > rockchip_pcie_enable_interrupts(rockchip); > > return 0; > + > +err_pcie_resume: > + clk_disable_unprepare(rockchip->aclk_pcie); > +err_aclk_pcie: > + clk_disable_unprepare(rockchip->aclk_perf_pcie); > +err_aclk_perf_pcie: > + clk_disable_unprepare(rockchip->hclk_pcie); > +err_hclk_pcie: > + clk_disable_unprepare(rockchip->clk_pcie_pm); > +err_pcie_pm: > + return err; > } > > static int rockchip_pcie_probe(struct platform_device *pdev) >
Re: [PATCH v6 4/6] vfio: Define vfio based vgpu's dma-buf operations
> struct vfio_vgpu_surface_info {
> __u64 start;
> __u32 width;
> __u32 height;
> __u32 stride;
> __u32 size;
> __u32 x_pos;
> __u32 y_pos;
> __u32 padding;
> /* Only used when VFIO_VGPU_SURFACE_DMABUF_* flags set */
> __u64 drm_format_mod;
> __u32 drm_format;
Why for dmabufs only? Shouldn't the region specify the format too?
Even in case you are using a fixed one (say DRM_FORMAT_XRGB) you
can explicitly say so in drm_format (and set drm_format_mod to zero).
cheers,
Gerd
Re: [PATCH 05/10] VFIO: pci: Introduce direct EOI INTx interrupt handler
On 01/06/17 21:40, Auger Eric wrote:
> Hi Alex,
>
> On 31/05/2017 20:24, Alex Williamson wrote:
>> On Wed, 24 May 2017 22:13:18 +0200
>> Eric Auger wrote:
>>
>>> We add two new fields in vfio_pci_irq_ctx struct: deoi and handler.
>>> If deoi is set, this means the physical IRQ attached to the virtual
>>> IRQ is directly deactivated by the guest and the VFIO driver does
>>> not need to disable the physical IRQ and mask it at VFIO level.
>>>
>>> The handler pointer is set accordingly and a wrapper handler is
>>> introduced that calls the chosen handler function.
>>>
>>> Signed-off-by: Eric Auger
>>>
>>> ---
>>> ---
>>> drivers/vfio/pci/vfio_pci_intrs.c | 32 ++--
>>> drivers/vfio/pci/vfio_pci_private.h | 2 ++
>>> 2 files changed, 28 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/drivers/vfio/pci/vfio_pci_intrs.c
>>> b/drivers/vfio/pci/vfio_pci_intrs.c
>>> index d4d377b..06aa713 100644
>>> --- a/drivers/vfio/pci/vfio_pci_intrs.c
>>> +++ b/drivers/vfio/pci/vfio_pci_intrs.c
>>> @@ -121,11 +121,8 @@ void vfio_pci_intx_unmask(struct vfio_pci_device *vdev)
>>> static irqreturn_t vfio_intx_handler(int irq, void *dev_id)
>>> {
>>> struct vfio_pci_device *vdev = dev_id;
>>> - unsigned long flags;
>>> int ret = IRQ_NONE;
>>>
>>> - spin_lock_irqsave(&vdev->irqlock, flags);
>>> -
>>> if (!vdev->pci_2_3) {
>>> disable_irq_nosync(vdev->pdev->irq);
>>> vdev->ctx[0].automasked = true;
>>> @@ -137,14 +134,33 @@ static irqreturn_t vfio_intx_handler(int irq, void
>>> *dev_id)
>>> ret = IRQ_HANDLED;
>>> }
>>>
>>> - spin_unlock_irqrestore(&vdev->irqlock, flags);
>>> -
>>> if (ret == IRQ_HANDLED)
>>> vfio_send_intx_eventfd(vdev, NULL);
>>>
>>> return ret;
>>> }
>>>
>>> +static irqreturn_t vfio_intx_handler_deoi(int irq, void *dev_id)
>>> +{
>>> + struct vfio_pci_device *vdev = dev_id;
>>> +
>>> + vfio_send_intx_eventfd(vdev, NULL);
>>> + return IRQ_HANDLED;
>>> +}
>>> +
>>> +static irqreturn_t vfio_intx_wrapper_handler(int irq, void *dev_id)
>>> +{
>>> + struct vfio_pci_device *vdev = dev_id;
>>> + unsigned long flags;
>>> + irqreturn_t ret;
>>> +
>>> + spin_lock_irqsave(&vdev->irqlock, flags);
>>> + ret = vdev->ctx[0].handler(irq, dev_id);
>>> + spin_unlock_irqrestore(&vdev->irqlock, flags);
>>> +
>>> + return ret;
>>> +}
>>> +
>>> static int vfio_intx_enable(struct vfio_pci_device *vdev)
>>> {
>>> if (!is_irq_none(vdev))
>>> @@ -208,7 +224,11 @@ static int vfio_intx_set_signal(struct vfio_pci_device
>>> *vdev, int fd)
>>> if (!vdev->pci_2_3)
>>> irqflags = 0;
>>>
>>> - ret = request_irq(pdev->irq, vfio_intx_handler,
>>> + if (vdev->ctx[0].deoi)
>>> + vdev->ctx[0].handler = vfio_intx_handler_deoi;
>>> + else
>>> + vdev->ctx[0].handler = vfio_intx_handler;
>>> + ret = request_irq(pdev->irq, vfio_intx_wrapper_handler,
>>> irqflags, vdev->ctx[0].name, vdev);
>>
>>
>> Here's where I think we don't account for irqflags properly. If we get
>> a shared interrupt here, then enabling direct EOI needs to be disabled
>> or else we'll starve other devices sharing the interrupt. In practice,
>> I wonder if this makes PCI direct EOI a useful feature. We could try
>> to get an exclusive interrupt and fallback to shared, but any time we
>> get an exclusive interrupt we're more prone to conflicts with other
>> devices. I might have two VMs that share an interrupt and now it's a
>> race that only the first to setup an IRQ can work. Worse, one of those
>> VMs might be fully booted and switched to MSI and now it's just a
>> matter of time until they reboot in the right way to generate a
>> conflict. I might also have two devices in the same VM that share an
>> IRQ and now I can't start the VM at all because the second device can
>> no longer get an interrupt. This is the same problem we have with the
>> nointxmask flag, it's a useful debugging feature but since the masking
>> is done at the APIC/GIC rather than the device, much like here, it's not
>> very practical for more than debugging and isolating specific devices
>> as requiring APIC/GIC level masking. I'm not sure how to proceed on the
>> PCI side here. Thanks,
>
> Thanks for the review.
>
> I share you concerns about shared interrupts. I need to spend some
> additional time reading the VFIO code related to those and that part of
> the PCIe spec too.
>
> Maybe we shall introduce the IRQ bypass based DEOI setup only for
> platform devices. I know those are not much used at the moment but this
> at least prepares for GICv4 direct injection.
I think that'd be good enough, unless we can ensure that we only engage
the Direct EOI feature when PCI legacy interrupts are not shared. The
system I have here (AMD Seattle) seem to have one set of INTx per PCIe
port, so the above would definitely work on it. But I understand that
there is not a guarantee at all.
Maybe th
Re: [RFC PATCH] mm, oom: cgroup-aware OOM-killer
On Wed 31-05-17 14:01:45, Johannes Weiner wrote:
> On Wed, May 31, 2017 at 06:25:04PM +0200, Michal Hocko wrote:
> > On Thu 25-05-17 13:08:05, Johannes Weiner wrote:
> > > Everything the user would want to dynamically program in the kernel,
> > > say with bpf, they could do in userspace and then update the scores
> > > for each group and task periodically.
> >
> > I am rather skeptical about dynamic scores. oom_{score_}adj has turned
> > to mere oom disable/enable knobs from my experience.
>
> That doesn't necessarily have to be a deficiency with the scoring
> system. I suspect that most people simply don't care as long as the
> the picks for OOM victims aren't entirely stupid.
>
> For example, we have a lot of machines that run one class of job. If
> we run OOM there isn't much preference we'd need to express; just kill
> one job - the biggest, whatever - and move on. (The biggest makes
> sense because if all jobs are basically equal it's as good as any
> other victim, but if one has a runaway bug it goes for that.)
>
> Where we have more than one job class, it actually is mostly one hipri
> and one lopri, in which case setting a hard limit on the lopri or the
> -1000 OOM score trick is enough.
>
> How many systems run more than two clearly distinguishable classes of
> workloads concurrently?
What about those which run different containers on a large physical
machine?
> I'm sure they exist. I'm just saying it doesn't surprise me that
> elaborate OOM scoring isn't all that wide-spread.
>
> > > The only limitation is that you have to recalculate and update the
> > > scoring tree every once in a while, whereas a bpf program could
> > > evaluate things just-in-time. But for that to matter in practice, OOM
> > > kills would have to be a fairly hot path.
> >
> > I am not really sure how to reliably implement "kill the memcg with the
> > largest process" strategy. And who knows how many others strategies will
> > pop out.
>
> That seems fairly contrived.
>
> What does it mean to divide memory into subdomains, but when you run
> out of physical memory you kill based on biggest task?
Well, the biggest task might be the runaway one and so killing it first
before you kill other innocent ones makes some sense to me.
> Sure, it frees memory and gets the system going again, so it's as good
> as any answer to overcommit gone wrong, I guess. But is that something
> you'd intentionally want to express from a userspace perspective?
>
[...]
> > > > Maybe. But that requires somebody to tweak the scoring which can be hard
> > > > from trivial.
> > >
> > > Why is sorting and picking in userspace harder than sorting and
> > > picking in the kernel?
> >
> > Because the userspace score based approach would be much more racy
> > especially in the busy system. This could lead to unexpected behavior
> > when OOM killer would kill a different than a run-away memcgs.
>
> How would it be easier to weigh priority against runaway detection
> inside the kernel?
You have better chances to catch such a process at the time of the OOM
because you do the check at the time of the OOM rather than sometimes
back in time when your monitor was able to run and check all the
existing processes (which alone can be rather time consuming so you do
not want to do that very often).
> > > > + /*
> > > > * If current has a pending SIGKILL or is exiting, then
> > > > automatically
> > > > * select it. The goal is to allow it to allocate so that it
> > > > may
> > > > * quickly exit and free its memory.
> > > >
> > > > Please note that I haven't explored how much of the infrastructure
> > > > needed for the OOM decision making is available to modules. But we can
> > > > export a lot of what we currently have in oom_kill.c. I admit it might
> > > > turn out that this is simply not feasible but I would like this to be at
> > > > least explored before we go and implement yet another hardcoded way to
> > > > handle (see how I didn't use policy ;)) OOM situation.
> > >
> > > ;)
> > >
> > > My doubt here is mainly that we'll see many (or any) real-life cases
> > > materialize that cannot be handled with cgroups and scoring. These are
> > > powerful building blocks on which userspace can implement all kinds of
> > > policy and sorting algorithms.
> > >
> > > So this seems like a lot of churn and complicated code to handle one
> > > extension. An extension that implements basic functionality.
> >
> > Well, as I've said I didn't get to explore this path so I have only a
> > very vague idea what we would have to export to implement e.g. the
> > proposed oom killing strategy suggested in this thread. Unfortunatelly I
> > do not have much time for that. I do not want to block a useful work
> > which you have a usecase for but I would be really happy if we could
> > consider longer term plans before diving into a "hardcoded"
> > implementation. We didn't do that previously and we are left with
> > oom_kill_alloca
[PATCH v9 0/5] i2c: aspeed: added driver for Aspeed I2C
Addressed comments from: - Ben in: http://www.spinics.net/lists/devicetree/msg179006.html Changes since previous update: - Fairly minimal changes in master support patch, all else is the same As before, tested on Aspeed 2500 evaluation board and a real platform with an Aspeed 2520.
[PATCH v9 3/5] i2c: aspeed: added documentation for Aspeed I2C driver
Added device tree binding documentation for Aspeed I2C busses.
Signed-off-by: Brendan Higgins
Acked-by: Rob Herring
---
Changes for v2:
- None
Changes for v3:
- Removed reference to "bus" device tree param
Changes for v4:
- None
Changes for v5:
- None
Changes for v6:
- Replaced the controller property with and interrupt controller, leaving only
the busses in the I2C documentation.
Changes for v7:
- Changed clock-frequency to bus-frequency in device tree
Changes for v8:
- Added multi-master property to device tree
Changes for v9:
- None
---
.../devicetree/bindings/i2c/i2c-aspeed.txt | 48 ++
1 file changed, 48 insertions(+)
create mode 100644 Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
diff --git a/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
b/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
new file mode 100644
index ..bd6480b19535
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
@@ -0,0 +1,48 @@
+Device tree configuration for the I2C busses on the AST24XX and AST25XX SoCs.
+
+Required Properties:
+- #address-cells : should be 1
+- #size-cells : should be 0
+- reg : address offset and range of bus
+- compatible : should be "aspeed,ast2400-i2c-bus"
+ or "aspeed,ast2500-i2c-bus"
+- clocks : root clock of bus, should reference the APB
+ clock
+- interrupts : interrupt number
+- interrupt-parent : interrupt controller for bus, should reference a
+ aspeed,ast2400-i2c-ic or aspeed,ast2500-i2c-ic
+ interrupt controller
+
+Optional Properties:
+- bus-frequency: frequency of the bus clock in Hz defaults to 100 kHz
when not
+ specified
+- multi-master : states that there is another master active on this bus.
+
+Example:
+
+i2c {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x1e78a000 0x1000>;
+
+ i2c_ic: interrupt-controller@0 {
+ #interrupt-cells = <1>;
+ compatible = "aspeed,ast2400-i2c-ic";
+ reg = <0x0 0x40>;
+ interrupts = <12>;
+ interrupt-controller;
+ };
+
+ i2c0: i2c-bus@40 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #interrupt-cells = <1>;
+ reg = <0x40 0x40>;
+ compatible = "aspeed,ast2400-i2c-bus";
+ clocks = <&clk_apb>;
+ bus-frequency = <10>;
+ interrupts = <0>;
+ interrupt-parent = <&i2c_ic>;
+ };
+};
--
2.13.0.506.g27d5fe0cd-goog
[PATCH v9 5/5] i2c: aspeed: added slave support for Aspeed I2C driver
Added slave support for Aspeed I2C controller. Supports fourteen busses
present in AST24XX and AST25XX BMC SoCs by Aspeed.
Signed-off-by: Brendan Higgins
---
Added in v6:
- Pulled slave support out of initial driver commit into its own commit.
- No longer arbitrarily restrict bus to be slave xor master.
Changes for v7:
- Added hardware reset function
- Marked functions that need to be called with the lock held as "unlocked"
- Did some cleanup
Changes for v8:
- None
Changes for v9:
- None
---
drivers/i2c/busses/i2c-aspeed.c | 202
1 file changed, 202 insertions(+)
diff --git a/drivers/i2c/busses/i2c-aspeed.c b/drivers/i2c/busses/i2c-aspeed.c
index a80f89fa0ed5..40671a60ddf0 100644
--- a/drivers/i2c/busses/i2c-aspeed.c
+++ b/drivers/i2c/busses/i2c-aspeed.c
@@ -49,6 +49,7 @@
#define ASPEED_I2CD_SDA_DRIVE_1T_ENBIT(8)
#define ASPEED_I2CD_M_SDA_DRIVE_1T_EN BIT(7)
#define ASPEED_I2CD_M_HIGH_SPEED_ENBIT(6)
+#define ASPEED_I2CD_SLAVE_EN BIT(1)
#define ASPEED_I2CD_MASTER_EN BIT(0)
/* 0x04 : I2CD Clock and AC Timing Control Register #1 */
@@ -69,6 +70,7 @@
*/
#define ASPEED_I2CD_INTR_SDA_DL_TIMEOUTBIT(14)
#define ASPEED_I2CD_INTR_BUS_RECOVER_DONE BIT(13)
+#define ASPEED_I2CD_INTR_SLAVE_MATCH BIT(7)
#define ASPEED_I2CD_INTR_SCL_TIMEOUT BIT(6)
#define ASPEED_I2CD_INTR_ABNORMAL BIT(5)
#define ASPEED_I2CD_INTR_NORMAL_STOP BIT(4)
@@ -106,6 +108,9 @@
#define ASPEED_I2CD_M_TX_CMD BIT(1)
#define ASPEED_I2CD_M_START_CMDBIT(0)
+/* 0x18 : I2CD Slave Device Address Register */
+#define ASPEED_I2CD_DEV_ADDR_MASK GENMASK(6, 0)
+
enum aspeed_i2c_master_state {
ASPEED_I2C_MASTER_START,
ASPEED_I2C_MASTER_TX_FIRST,
@@ -116,6 +121,15 @@ enum aspeed_i2c_master_state {
ASPEED_I2C_MASTER_INACTIVE,
};
+enum aspeed_i2c_slave_state {
+ ASPEED_I2C_SLAVE_START,
+ ASPEED_I2C_SLAVE_READ_REQUESTED,
+ ASPEED_I2C_SLAVE_READ_PROCESSED,
+ ASPEED_I2C_SLAVE_WRITE_REQUESTED,
+ ASPEED_I2C_SLAVE_WRITE_RECEIVED,
+ ASPEED_I2C_SLAVE_STOP,
+};
+
struct aspeed_i2c_bus {
struct i2c_adapter adap;
struct device *dev;
@@ -134,6 +148,10 @@ struct aspeed_i2c_bus {
size_t msgs_count;
boolsend_stop;
int cmd_err;
+#if IS_ENABLED(CONFIG_I2C_SLAVE)
+ struct i2c_client *slave;
+ enum aspeed_i2c_slave_state slave_state;
+#endif /* CONFIG_I2C_SLAVE */
};
static int aspeed_i2c_reset(struct aspeed_i2c_bus *bus);
@@ -205,6 +223,110 @@ static int aspeed_i2c_recover_bus(struct aspeed_i2c_bus
*bus)
return aspeed_i2c_reset(bus);
}
+#if IS_ENABLED(CONFIG_I2C_SLAVE)
+static bool aspeed_i2c_slave_irq(struct aspeed_i2c_bus *bus)
+{
+ u32 command, irq_status, status_ack = 0;
+ struct i2c_client *slave = bus->slave;
+ bool irq_handled = true;
+ u8 value;
+
+ spin_lock(&bus->lock);
+ if (!slave) {
+ irq_handled = false;
+ goto out;
+ }
+
+ command = readl(bus->base + ASPEED_I2C_CMD_REG);
+ irq_status = readl(bus->base + ASPEED_I2C_INTR_STS_REG);
+
+ /* Slave was requested, restart state machine. */
+ if (irq_status & ASPEED_I2CD_INTR_SLAVE_MATCH) {
+ status_ack |= ASPEED_I2CD_INTR_SLAVE_MATCH;
+ bus->slave_state = ASPEED_I2C_SLAVE_START;
+ }
+
+ /* Slave is not currently active, irq was for someone else. */
+ if (bus->slave_state == ASPEED_I2C_SLAVE_STOP) {
+ irq_handled = false;
+ goto out;
+ }
+
+ dev_dbg(bus->dev, "slave irq status 0x%08x, cmd 0x%08x\n",
+ irq_status, command);
+
+ /* Slave was sent something. */
+ if (irq_status & ASPEED_I2CD_INTR_RX_DONE) {
+ value = readl(bus->base + ASPEED_I2C_BYTE_BUF_REG) >> 8;
+ /* Handle address frame. */
+ if (bus->slave_state == ASPEED_I2C_SLAVE_START) {
+ if (value & 0x1)
+ bus->slave_state =
+ ASPEED_I2C_SLAVE_READ_REQUESTED;
+ else
+ bus->slave_state =
+
ASPEED_I2C_SLAVE_WRITE_REQUESTED;
+ }
+ status_ack |= ASPEED_I2CD_INTR_RX_DONE;
+ }
+
+ /* Slave was asked to stop. */
+ if (irq_status & ASPEED_I2CD_INTR_NORMAL_STOP) {
+ status_ack |= ASPEED_I2CD_INTR_NORMAL_STOP;
+ bus->slave_state = ASPEED_I2C_SLA
[PATCH v9 1/5] irqchip/aspeed-i2c-ic: binding docs for Aspeed I2C Interrupt Controller
Added device tree binding documentation for Aspeed I2C Interrupt
Controller.
Signed-off-by: Brendan Higgins
Acked-by: Rob Herring
---
Added in v6:
- Pulled "aspeed_i2c_controller" out into a interrupt controller since that is
what it actually does.
Changes for v7:
- None
Changes for v8:
- None
Changes for v9:
- None
---
.../interrupt-controller/aspeed,ast2400-i2c-ic.txt | 25 ++
1 file changed, 25 insertions(+)
create mode 100644
Documentation/devicetree/bindings/interrupt-controller/aspeed,ast2400-i2c-ic.txt
diff --git
a/Documentation/devicetree/bindings/interrupt-controller/aspeed,ast2400-i2c-ic.txt
b/Documentation/devicetree/bindings/interrupt-controller/aspeed,ast2400-i2c-ic.txt
new file mode 100644
index ..033cc82e5684
--- /dev/null
+++
b/Documentation/devicetree/bindings/interrupt-controller/aspeed,ast2400-i2c-ic.txt
@@ -0,0 +1,25 @@
+Device tree configuration for the I2C Interrupt Controller on the AST24XX and
+AST25XX SoCs.
+
+Required Properties:
+- #address-cells : should be 1
+- #size-cells : should be 1
+- #interrupt-cells : should be 1
+- compatible : should be "aspeed,ast2400-i2c-ic"
+ or "aspeed,ast2500-i2c-ic"
+- reg : address start and range of controller
+- interrupts : interrupt number
+- interrupt-controller : denotes that the controller receives and fires
+ new interrupts for child busses
+
+Example:
+
+i2c_ic: interrupt-controller@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ #interrupt-cells = <1>;
+ compatible = "aspeed,ast2400-i2c-ic";
+ reg = <0x0 0x40>;
+ interrupts = <12>;
+ interrupt-controller;
+};
--
2.13.0.506.g27d5fe0cd-goog
[PATCH v9 4/5] i2c: aspeed: added driver for Aspeed I2C
Added initial master support for Aspeed I2C controller. Supports fourteen busses present in AST24XX and AST25XX BMC SoCs by Aspeed. Signed-off-by: Brendan Higgins --- Changes for v2: - Added single module_init (multiple was breaking some builds). Changes for v3: - Removed "bus" device tree param; now extracted from bus address offset Changes for v4: - I2C adapter number is now generated dynamically unless specified in alias. Changes for v5: - Removed irq_chip used to multiplex IRQ and replaced it with dummy_irq_chip along with some other IRQ cleanup. - Addressed comments from Cedric, and Vladimir, mostly stylistic things and using devm managed resources. - Increased max clock frequency before the bus is put in HighSpeed mode, as per Kachalov's comment. Changes for v6: - No longer arbitrarily restrict bus to be slave xor master. - Pulled out "struct aspeed_i2c_controller" as a interrupt controller. - Pulled out slave support into its own commit. - Rewrote code that sets clock divider register because the original version set it incorrectly. - Rewrote the aspeed_i2c_master_irq handler because the old method of completing a completion in between restarts was too slow causing devices to misbehave. - Added support for I2C_M_RECV_LEN which I had incorrectly said was supported before. - Addressed other comments from Vladimir. Changes for v7: - Changed clock-frequency to bus-frequency - Made some fixes to clock divider code - Added hardware reset function - Marked functions that need to be called with the lock held as "unlocked" - Did a bunch of clean up Changes for v8: - ACK IRQ status bits before doing anything else - Added multi-master device tree property - Do not send STOP commands after interrupt errors - Fix SMBUS_QUICK emulation handling - Removed highspeed clock code (I will do it in a later patch set) - Use the platform_device name for the adapter name - Reset for all failed recoveries - Removed the "__" prefix from all of the non-thread safe functions Changes for v9: - No longer debug log after every address NACK - Clear errors after reset - No longer access clock while holding lock - Ack all interrupts durring bus reset and initialization --- drivers/i2c/busses/Kconfig | 10 + drivers/i2c/busses/Makefile | 1 + drivers/i2c/busses/i2c-aspeed.c | 683 3 files changed, 694 insertions(+) create mode 100644 drivers/i2c/busses/i2c-aspeed.c diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig index 144cbadc7c72..280f84a0d7d1 100644 --- a/drivers/i2c/busses/Kconfig +++ b/drivers/i2c/busses/Kconfig @@ -326,6 +326,16 @@ config I2C_POWERMAC comment "I2C system bus drivers (mostly embedded / system-on-chip)" +config I2C_ASPEED + tristate "Aspeed I2C Controller" + depends on ARCH_ASPEED + help + If you say yes to this option, support will be included for the + Aspeed I2C controller. + + This driver can also be built as a module. If so, the module + will be called i2c-aspeed. + config I2C_AT91 tristate "Atmel AT91 I2C Two-Wire interface (TWI)" depends on ARCH_AT91 diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile index 30b60855fbcd..e84604b9bf3b 100644 --- a/drivers/i2c/busses/Makefile +++ b/drivers/i2c/busses/Makefile @@ -29,6 +29,7 @@ obj-$(CONFIG_I2C_HYDRA) += i2c-hydra.o obj-$(CONFIG_I2C_POWERMAC) += i2c-powermac.o # Embedded system I2C/SMBus host controller drivers +obj-$(CONFIG_I2C_ASPEED) += i2c-aspeed.o obj-$(CONFIG_I2C_AT91) += i2c-at91.o obj-$(CONFIG_I2C_AU1550) += i2c-au1550.o obj-$(CONFIG_I2C_AXXIA)+= i2c-axxia.o diff --git a/drivers/i2c/busses/i2c-aspeed.c b/drivers/i2c/busses/i2c-aspeed.c new file mode 100644 index ..a80f89fa0ed5 --- /dev/null +++ b/drivers/i2c/busses/i2c-aspeed.c @@ -0,0 +1,683 @@ +/* + * Aspeed 24XX/25XX I2C Controller. + * + * Copyright (C) 2012-2017 ASPEED Technology Inc. + * Copyright 2017 IBM Corporation + * Copyright 2017 Google, Inc. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +/* I2C Register */ +#define ASPEED_I2C_FUN_CTRL_REG0x00 +#define ASPEED_I2C_AC_TIMING_REG1 0x04 +#define ASPEED_I2C_AC_TIMING_REG2 0x08 +#define ASPEED_I2C_INTR_CTRL_REG 0x0c +#define ASPEED_I2C_INTR_STS_REG0x10 +#define ASPEED_I2C_CMD_REG 0x14 +#define ASPEED_I2C_DEV_ADD
[PATCH v9 2/5] irqchip/aspeed-i2c-ic: Add I2C IRQ controller for Aspeed
The Aspeed 24XX/25XX chips share a single hardware interrupt across 14
separate I2C busses. This adds a dummy irqchip which maps the single
hardware interrupt to software interrupts for each of the busses.
Signed-off-by: Brendan Higgins
---
Added in v6:
- Pulled "aspeed_i2c_controller" out into a interrupt controller since that is
what it actually does.
Changes for v7:
- Renamed irq domain for consistency
Changes for v8:
- None
Changes for v9:
- None
---
drivers/irqchip/Makefile| 2 +-
drivers/irqchip/irq-aspeed-i2c-ic.c | 102
2 files changed, 103 insertions(+), 1 deletion(-)
create mode 100644 drivers/irqchip/irq-aspeed-i2c-ic.c
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index b64c59b838a0..e067f9839b33 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -73,6 +73,6 @@ obj-$(CONFIG_MVEBU_ODMI) += irq-mvebu-odmi.o
obj-$(CONFIG_MVEBU_PIC)+= irq-mvebu-pic.o
obj-$(CONFIG_LS_SCFG_MSI) += irq-ls-scfg-msi.o
obj-$(CONFIG_EZNPS_GIC)+= irq-eznps.o
-obj-$(CONFIG_ARCH_ASPEED) += irq-aspeed-vic.o
+obj-$(CONFIG_ARCH_ASPEED) += irq-aspeed-vic.o irq-aspeed-i2c-ic.o
obj-$(CONFIG_STM32_EXTI) += irq-stm32-exti.o
obj-$(CONFIG_QCOM_IRQ_COMBINER)+= qcom-irq-combiner.o
diff --git a/drivers/irqchip/irq-aspeed-i2c-ic.c
b/drivers/irqchip/irq-aspeed-i2c-ic.c
new file mode 100644
index ..a36fb09c10c2
--- /dev/null
+++ b/drivers/irqchip/irq-aspeed-i2c-ic.c
@@ -0,0 +1,102 @@
+/*
+ * Aspeed 24XX/25XX I2C Interrupt Controller.
+ *
+ * Copyright (C) 2012-2017 ASPEED Technology Inc.
+ * Copyright 2017 IBM Corporation
+ * Copyright 2017 Google, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+
+#define ASPEED_I2C_IC_NUM_BUS 14
+
+struct aspeed_i2c_ic {
+ void __iomem*base;
+ int parent_irq;
+ struct irq_domain *irq_domain;
+};
+
+/*
+ * The aspeed chip provides a single hardware interrupt for all of the I2C
+ * busses, so we use a dummy interrupt chip to translate this single interrupt
+ * into multiple interrupts, each associated with a single I2C bus.
+ */
+static void aspeed_i2c_ic_irq_handler(struct irq_desc *desc)
+{
+ struct aspeed_i2c_ic *i2c_ic = irq_desc_get_handler_data(desc);
+ struct irq_chip *chip = irq_desc_get_chip(desc);
+ unsigned long bit, status;
+ unsigned int bus_irq;
+
+ chained_irq_enter(chip, desc);
+ status = readl(i2c_ic->base);
+ for_each_set_bit(bit, &status, ASPEED_I2C_IC_NUM_BUS) {
+ bus_irq = irq_find_mapping(i2c_ic->irq_domain, bit);
+ generic_handle_irq(bus_irq);
+ }
+ chained_irq_exit(chip, desc);
+}
+
+/*
+ * Set simple handler and mark IRQ as valid. Nothing interesting to do here
+ * since we are using a dummy interrupt chip.
+ */
+static int aspeed_i2c_ic_map_irq_domain(struct irq_domain *domain,
+ unsigned int irq, irq_hw_number_t hwirq)
+{
+ irq_set_chip_and_handler(irq, &dummy_irq_chip, handle_simple_irq);
+ irq_set_chip_data(irq, domain->host_data);
+
+ return 0;
+}
+
+static const struct irq_domain_ops aspeed_i2c_ic_irq_domain_ops = {
+ .map = aspeed_i2c_ic_map_irq_domain,
+};
+
+static int __init aspeed_i2c_ic_of_init(struct device_node *node,
+ struct device_node *parent)
+{
+ struct aspeed_i2c_ic *i2c_ic;
+
+ i2c_ic = kzalloc(sizeof(*i2c_ic), GFP_KERNEL);
+ if (!i2c_ic)
+ return -ENOMEM;
+
+ i2c_ic->base = of_iomap(node, 0);
+ if (IS_ERR(i2c_ic->base))
+ return PTR_ERR(i2c_ic->base);
+
+ i2c_ic->parent_irq = irq_of_parse_and_map(node, 0);
+ if (i2c_ic->parent_irq < 0)
+ return i2c_ic->parent_irq;
+
+ i2c_ic->irq_domain = irq_domain_add_linear(
+ node, ASPEED_I2C_IC_NUM_BUS,
+ &aspeed_i2c_ic_irq_domain_ops, NULL);
+ if (!i2c_ic->irq_domain)
+ return -ENOMEM;
+
+ i2c_ic->irq_domain->name = "aspeed-i2c-domain";
+
+ irq_set_chained_handler_and_data(i2c_ic->parent_irq,
+aspeed_i2c_ic_irq_handler, i2c_ic);
+
+ pr_info("i2c controller registered, irq %d\n", i2c_ic->parent_irq);
+
+ return 0;
+}
+
+IRQCHIP_DECLARE(ast2400_i2c_ic, "aspeed,ast2400-i2c-ic",
aspeed_i2c_ic_of_init);
+IRQCHIP_DECLARE(ast2500_i2c_ic, "aspeed,ast2500-i2c-ic",
aspeed_i2c_ic_of_init);
--
2.13.0.506.g27d5fe0cd-goog
Re: [RFC 08/55] KVM: arm64: Set virtual EL2 context depending on the guest exception level
On 01/06/17 21:22, Bandan Das wrote:
> Jintack Lim writes:
>
>> From: Christoffer Dall
>>
>> Set up virutal EL2 context to hardware if the guest exception level is
>> EL2.
>>
>> Signed-off-by: Christoffer Dall
>> Signed-off-by: Jintack Lim
>> ---
>> arch/arm64/kvm/context.c | 32 ++--
>> 1 file changed, 26 insertions(+), 6 deletions(-)
>>
>> diff --git a/arch/arm64/kvm/context.c b/arch/arm64/kvm/context.c
>> index 320afc6..acb4b1e 100644
>> --- a/arch/arm64/kvm/context.c
>> +++ b/arch/arm64/kvm/context.c
>> @@ -25,10 +25,25 @@
>> void kvm_arm_setup_shadow_state(struct kvm_vcpu *vcpu)
>> {
>> struct kvm_cpu_context *ctxt = &vcpu->arch.ctxt;
>> +if (unlikely(vcpu_mode_el2(vcpu))) {
>> +ctxt->hw_pstate = *vcpu_cpsr(vcpu) & ~PSR_MODE_MASK;
>>
>> -ctxt->hw_pstate = *vcpu_cpsr(vcpu);
>> -ctxt->hw_sys_regs = ctxt->sys_regs;
>> -ctxt->hw_sp_el1 = ctxt->gp_regs.sp_el1;
>> +/*
>> + * We emulate virtual EL2 mode in hardware EL1 mode using the
>> + * same stack pointer mode as the guest expects.
>> + */
>> +if ((*vcpu_cpsr(vcpu) & PSR_MODE_MASK) == PSR_MODE_EL2h)
>> +ctxt->hw_pstate |= PSR_MODE_EL1h;
>> +else
>> +ctxt->hw_pstate |= PSR_MODE_EL1t;
>> +
>
> I see vcpu_mode(el2) does
> return mode == PSR_MODE_EL2h || mode == PSR_MODE_EL2t;
>
> I can't seem to find this, what's the difference between
> the modes: PSR_MODE_EL2h/EL2t ?
The difference is the stack pointer that is getting used. When the CPU
is at ELxh, it uses SPx at ELx. When at ELxt, it uses SP0 (the userspace
stack pointer). See the definition of SPSR_EL2 in the ARMv8 ARM.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
[PATCH v2 1/1] tty: add TIOCGPTPEER ioctl
When opening the slave end of a PTY, it is not possible for userspace to
safely ensure that /dev/pts/$num is actually a slave (in cases where the
mount namespace in which devpts was mounted is controlled by an
untrusted process). In addition, there are several unresolvable
race conditions if userspace were to attempt to detect attacks through
stat(2) and other similar methods [in addition it is not clear how
userspace could detect attacks involving FUSE].
Resolve this by providing an interface for userpace to safely open the
"peer" end of a PTY file descriptor by using the dentry cached by
devpts. Since it is not possible to have an open master PTY without
having its slave exposed in /dev/pts this interface is safe. This
interface currently does not provide a way to get the master pty (since
it is not clear whether such an interface is safe or even useful).
Cc: Christian Brauner
Cc: Valentin Rothberg
Signed-off-by: Aleksa Sarai
---
arch/alpha/include/uapi/asm/ioctls.h | 1 +
arch/mips/include/uapi/asm/ioctls.h| 1 +
arch/parisc/include/uapi/asm/ioctls.h | 1 +
arch/powerpc/include/uapi/asm/ioctls.h | 1 +
arch/sh/include/uapi/asm/ioctls.h | 1 +
arch/sparc/include/uapi/asm/ioctls.h | 3 +-
arch/xtensa/include/uapi/asm/ioctls.h | 1 +
drivers/tty/pty.c | 71 --
include/uapi/asm-generic/ioctls.h | 1 +
9 files changed, 76 insertions(+), 5 deletions(-)
diff --git a/arch/alpha/include/uapi/asm/ioctls.h
b/arch/alpha/include/uapi/asm/ioctls.h
index f30c94ae1bdb..ff67b8373bf7 100644
--- a/arch/alpha/include/uapi/asm/ioctls.h
+++ b/arch/alpha/include/uapi/asm/ioctls.h
@@ -100,6 +100,7 @@
#define TIOCGPKT _IOR('T', 0x38, int) /* Get packet mode state */
#define TIOCGPTLCK _IOR('T', 0x39, int) /* Get Pty lock state */
#define TIOCGEXCL _IOR('T', 0x40, int) /* Get exclusive mode state */
+#define TIOCGPTPEER_IOR('T', 0x41, int) /* Safely open the slave */
#define TIOCSERCONFIG 0x5453
#define TIOCSERGWILD 0x5454
diff --git a/arch/mips/include/uapi/asm/ioctls.h
b/arch/mips/include/uapi/asm/ioctls.h
index 740219c2c894..68e19b689a00 100644
--- a/arch/mips/include/uapi/asm/ioctls.h
+++ b/arch/mips/include/uapi/asm/ioctls.h
@@ -91,6 +91,7 @@
#define TIOCGPKT _IOR('T', 0x38, int) /* Get packet mode state */
#define TIOCGPTLCK _IOR('T', 0x39, int) /* Get Pty lock state */
#define TIOCGEXCL _IOR('T', 0x40, int) /* Get exclusive mode state */
+#define TIOCGPTPEER_IOR('T', 0x41, int) /* Safely open the slave */
/* I hope the range from 0x5480 on is free ... */
#define TIOCSCTTY 0x5480 /* become controlling tty */
diff --git a/arch/parisc/include/uapi/asm/ioctls.h
b/arch/parisc/include/uapi/asm/ioctls.h
index b6572f051b67..674c68a5bbd0 100644
--- a/arch/parisc/include/uapi/asm/ioctls.h
+++ b/arch/parisc/include/uapi/asm/ioctls.h
@@ -60,6 +60,7 @@
#define TIOCGPKT _IOR('T', 0x38, int) /* Get packet mode state */
#define TIOCGPTLCK _IOR('T', 0x39, int) /* Get Pty lock state */
#define TIOCGEXCL _IOR('T', 0x40, int) /* Get exclusive mode state */
+#define TIOCGPTPEER_IOR('T', 0x41, int) /* Safely open the slave */
#define FIONCLEX 0x5450 /* these numbers need to be adjusted. */
#define FIOCLEX0x5451
diff --git a/arch/powerpc/include/uapi/asm/ioctls.h
b/arch/powerpc/include/uapi/asm/ioctls.h
index 49a25796a61a..bfd609a3e928 100644
--- a/arch/powerpc/include/uapi/asm/ioctls.h
+++ b/arch/powerpc/include/uapi/asm/ioctls.h
@@ -100,6 +100,7 @@
#define TIOCGPKT _IOR('T', 0x38, int) /* Get packet mode state */
#define TIOCGPTLCK _IOR('T', 0x39, int) /* Get Pty lock state */
#define TIOCGEXCL _IOR('T', 0x40, int) /* Get exclusive mode state */
+#define TIOCGPTPEER_IOR('T', 0x41, int) /* Safely open the slave */
#define TIOCSERCONFIG 0x5453
#define TIOCSERGWILD 0x5454
diff --git a/arch/sh/include/uapi/asm/ioctls.h
b/arch/sh/include/uapi/asm/ioctls.h
index c9903e56ccf4..eec7901e9e65 100644
--- a/arch/sh/include/uapi/asm/ioctls.h
+++ b/arch/sh/include/uapi/asm/ioctls.h
@@ -93,6 +93,7 @@
#define TIOCGPKT _IOR('T', 0x38, int) /* Get packet mode state */
#define TIOCGPTLCK _IOR('T', 0x39, int) /* Get Pty lock state */
#define TIOCGEXCL _IOR('T', 0x40, int) /* Get exclusive mode state */
+#define TIOCGPTPEER_IOR('T', 0x41, int) /* Safely open the slave */
#define TIOCSERCONFIG _IO('T', 83) /* 0x5453 */
#define TIOCSERGWILD _IOR('T', 84, int) /* 0x5454 */
diff --git a/arch/sparc/include/uapi/asm/ioctls.h
b/arch/sparc/include/uapi/asm/ioctls.h
index 06b3f6c3bb9a..6d27398632ea 100644
--- a/arch/sparc/include/uapi/asm/ioctls.h
+++ b/arch/sparc/include/uapi/asm/ioctls.h
@@ -27,7 +27,7 @@
#define TIOCGRS485 _IOR('T', 0x41, struct serial_rs485)
#define TIOCSRS485 _IOWR('T', 0x42, struct serial_rs485)
-/* Note that all the ioctls that are not available in Linux have a
+/* Note
[PATCH v2 0/1] tty: add TIOCGPTPEER ioctl
Changes in v2: * Reordered addition to ioctls.h to follow correct hex ordering. Aleksa Sarai (1): tty: add TIOCGPTPEER ioctl arch/alpha/include/uapi/asm/ioctls.h | 1 + arch/mips/include/uapi/asm/ioctls.h| 1 + arch/parisc/include/uapi/asm/ioctls.h | 1 + arch/powerpc/include/uapi/asm/ioctls.h | 1 + arch/sh/include/uapi/asm/ioctls.h | 1 + arch/sparc/include/uapi/asm/ioctls.h | 3 +- arch/xtensa/include/uapi/asm/ioctls.h | 1 + drivers/tty/pty.c | 71 -- include/uapi/asm-generic/ioctls.h | 1 + 9 files changed, 76 insertions(+), 5 deletions(-) -- 2.13.0
Re: single-threaded wq lockdep is broken
On Fri, 2017-06-02 at 15:03 +0800, Lai Jiangshan wrote: > > the @w2 is not queued before flush_work(&w2), it is expected > that @w2 is not associated with @wq, and the dependence > mtx -> wq will not be recorded. And it is expected no warning. Lockdep is symmetric. So then maybe it won't warn when executing flush_work(), but should later when executing @w2. No real difference? johannes
[PATCH v2 1/6] dt-bindings: mfd: hi6421: Add hi6421v530 compatible string
Add compatible string for HiSilicon Hi6421v530 PMIC. Signed-off-by: Guodong Xu --- Documentation/devicetree/bindings/mfd/hi6421.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/mfd/hi6421.txt b/Documentation/devicetree/bindings/mfd/hi6421.txt index 0d5a446..22da96d 100644 --- a/Documentation/devicetree/bindings/mfd/hi6421.txt +++ b/Documentation/devicetree/bindings/mfd/hi6421.txt @@ -1,7 +1,9 @@ * HI6421 Multi-Functional Device (MFD), by HiSilicon Ltd. Required parent device properties: -- compatible : contains "hisilicon,hi6421-pmic"; +- compatible: One of the following chip-specific strings: + "hisilicon,hi6421-pmic"; + "hisilicon,hi6421v530-pmic"; - reg : register range space of hi6421; Supported Hi6421 sub-devices include: -- 2.10.2
[PATCH v2 0/6] MFD: add driver for HiSilicon Hi6421v530 PMIC
This patchset adds driver for HiSilicon Hi6421v530 PMIC. Mainline kernel already has driver support to a similar chip, Hi6421. Hi6421 and Hi6421v530 are both from the same vendor, HiSilicon, but they are at different revisions. They both use the same Memory-mapped I/O method to communicate with Main SoC. However, they differ quite a lot in their regulator designs. Eg. they have completely different LDO voltage points. Patch 1 and 2 extends hi6421-pmic-core.c to support Hi6421v530 revision. Patch 3 add hi6421v530-regulator.c driver for LDO regulators. Patch 4 fixes an issue for hi6421 regulator, which is not related to v530 but it's found in this review. Patch 5 is dts change, it depends and can be applied on hi3660/hikey960 patchset [1]. Patch 6 enables the relevant config items. [1], http://www.spinics.net/lists/devicetree/msg178303.html Major changes in v2: - instead of writing a new driver, extend hi6421-pmic-core.c to support its v530 revision - update hi6421v530-regulator.c to use modern regulator driver design logics. Guodong Xu (4): dt-bindings: mfd: hi6421: Add hi6421v530 compatible string mfd: hi6421-pmic: add support for HiSilicon Hi6421v530 regulator: hi6421: Describe consumed platform device arm64: defconfig: enable support hi6421v530 PMIC Wang Xiaoyin (2): regulator: hi6421v530: add driver for hi6421v530 voltage regulator arm64: dts: hikey960: add device node for pmic and regulators Documentation/devicetree/bindings/mfd/hi6421.txt | 4 +- arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts | 46 + arch/arm64/configs/defconfig | 2 + drivers/mfd/hi6421-pmic-core.c| 56 -- drivers/regulator/Kconfig | 10 ++ drivers/regulator/Makefile| 1 + drivers/regulator/hi6421-regulator.c | 7 + drivers/regulator/hi6421v530-regulator.c | 209 ++ include/linux/mfd/hi6421-pmic.h | 5 + 9 files changed, 326 insertions(+), 14 deletions(-) create mode 100644 drivers/regulator/hi6421v530-regulator.c -- 2.10.2
[PATCH v2 3/6] regulator: hi6421v530: add driver for hi6421v530 voltage regulator
From: Wang Xiaoyin
add the driver for hi6421v530 voltage regulator
Signed-off-by: Wang Xiaoyin
Signed-off-by: Guodong Xu
---
drivers/regulator/Kconfig| 10 ++
drivers/regulator/Makefile | 1 +
drivers/regulator/hi6421v530-regulator.c | 209 +++
3 files changed, 220 insertions(+)
create mode 100644 drivers/regulator/hi6421v530-regulator.c
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 48db87d..78cd8d8 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -296,6 +296,16 @@ config REGULATOR_HI6421
21 general purpose LDOs, 3 dedicated LDOs, and 5 BUCKs. All
of them come with support to either ECO (idle) or sleep mode.
+config REGULATOR_HI6421V530
+ tristate "HiSilicon Hi6421v530 PMIC voltage regulator support"
+ depends on MFD_HI6421_PMIC && OF
+ help
+ This driver provides support for the voltage regulators on
+ HiSilicon Hi6421v530 PMU / Codec IC.
+ Hi6421v530 is a multi-function device which, on regulator part,
+ provides 5 general purpose LDOs, and all of them come with support
+ to either ECO (idle) or sleep mode.
+
config REGULATOR_HI655X
tristate "Hisilicon HI655X PMIC regulators support"
depends on ARCH_HISI || COMPILE_TEST
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index dc3503f..36e2b75 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -38,6 +38,7 @@ obj-$(CONFIG_REGULATOR_DB8500_PRCMU) += db8500-prcmu.o
obj-$(CONFIG_REGULATOR_FAN53555) += fan53555.o
obj-$(CONFIG_REGULATOR_GPIO) += gpio-regulator.o
obj-$(CONFIG_REGULATOR_HI6421) += hi6421-regulator.o
+obj-$(CONFIG_REGULATOR_HI6421V530) += hi6421v530-regulator.o
obj-$(CONFIG_REGULATOR_HI655X) += hi655x-regulator.o
obj-$(CONFIG_REGULATOR_ISL6271A) += isl6271a-regulator.o
obj-$(CONFIG_REGULATOR_ISL9305) += isl9305.o
diff --git a/drivers/regulator/hi6421v530-regulator.c
b/drivers/regulator/hi6421v530-regulator.c
new file mode 100644
index 000..b341484
--- /dev/null
+++ b/drivers/regulator/hi6421v530-regulator.c
@@ -0,0 +1,209 @@
+/*
+ * Device driver for regulators in Hi6421V530 IC
+ *
+ * Copyright (c) <2017> HiSilicon Technologies Co., Ltd.
+ * http://www.hisilicon.com
+ * Copyright (c) <2017> Linaro Ltd.
+ * http://www.linaro.org
+ *
+ * Author: Wang Xiaoyin
+ * Guodong Xu
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/*
+ * struct hi6421v530_regulator_info - hi6421v530 regulator information
+ * @desc: regulator description
+ * @mode_mask: ECO mode bitmask of LDOs; for BUCKs, this masks sleep
+ * @eco_microamp: eco mode load upper limit (in uA), valid for LDOs only
+ */
+struct hi6421v530_regulator_info {
+ struct regulator_desc rdesc;
+ u8 mode_mask;
+ u32 eco_microamp;
+};
+
+/* HI6421v530 regulators */
+enum hi6421v530_regulator_id {
+ HI6421V530_LDO3,
+ HI6421V530_LDO9,
+ HI6421V530_LDO11,
+ HI6421V530_LDO15,
+ HI6421V530_LDO16,
+};
+
+static const unsigned int ldo_3_voltages[] = {
+ 180, 1825000, 185, 1875000,
+ 190, 1925000, 195, 1975000,
+ 200, 2025000, 205, 2075000,
+ 210, 2125000, 215, 220,
+};
+
+static const unsigned int ldo_9_11_voltages[] = {
+ 175, 180, 1825000, 280,
+ 285, 295, 300, 330,
+};
+
+static const unsigned int ldo_15_16_voltages[] = {
+ 175, 180, 240, 260,
+ 270, 285, 295, 300,
+};
+
+static const struct regulator_ops hi6421v530_ldo_ops;
+
+#define HI6421V530_LDO_ENABLE_TIME (350)
+
+/*
+ * _id - LDO id name string
+ * v_table - voltage table
+ * vreg - voltage select register
+ * vmask - voltage select mask
+ * ereg - enable register
+ * emask - enable mask
+ * odelay - off/on delay time in uS
+ * ecomask - eco mode mask
+ * ecoamp - eco mode load uppler limit in uA
+ */
+#define HI6421V530_LDO(_ID, v_table, vreg, vmask, ereg, emask, \
+ odelay, ecomask, ecoamp) { \
+ .rdesc = { \
+ .name= #_ID,\
+ .of_match= of_match_ptr(#_ID), \
+ .regulators_node = of_match_ptr("regulators"), \
+ .ops = &hi6421v530_ldo_ops, \
+ .type= REGULATOR_VOLTAGE, \
+ .id = HI6421V530_##_ID,\
+ .owner = THIS_MODULE,
[GIT PULL]: dmaengine fixes for 4.12-rc4
Hi Linus, Here is the dmaengine fixes request for 4.12. Fixes bunch of issues in the driver, npthing exciting though.. The following changes since commit 2ea659a9ef488125eb46da6eb571de5eae5c43f6: Linux 4.12-rc1 (2017-05-13 13:19:49 -0700) are available in the git repository at: git://git.infradead.org/users/vkoul/slave-dma.git tags/dmaengine-fix-4.12-rc4 for you to fetch changes up to ebcdaee4cebb3a8d0d702ab5e9392373672ec1de: dmaengine: pl330: fix warning in pl330_remove (2017-06-02 11:49:44 +0530) dmaengine fixes for 4.12-rc4 A bit largish fixes for dmaengine driver's fixing - mv_xor_v2 driver for handling descriptors, tx_submit implementation, removing interrupt coalescing and setting DMA mask properly - usb-dmac DMAOR AE bit definition - ep93xx start buffer from BASE0 and not drain the transfers in terminate_all - rcar-dmac use right descriptor pointer for residue calculation - pl330 fix warn for irq freeup Alexander Sverdlin (2): dmaengine: ep93xx: Always start from BASE0 dmaengine: ep93xx: Don't drain the transfers in terminate_all() Hanna Hawa (1): dmaengine: mv_xor_v2: enable XOR engine after its configuration Hiroyuki Yokoyama (1): dmaengine: usb-dmac: Fix DMAOR AE bit definition Jean-Philippe Brucker (1): dmaengine: pl330: fix warning in pl330_remove Kuninori Morimoto (1): rcar-dmac: fixup descriptor pointer for descriptor mode Thomas Petazzoni (6): dmaengine: mv_xor_v2: handle mv_xor_v2_prep_sw_desc() error properly dmaengine: mv_xor_v2: properly handle wrapping in the array of HW descriptors dmaengine: mv_xor_v2: do not use descriptors not acked by async_tx dmaengine: mv_xor_v2: fix tx_submit() implementation dmaengine: mv_xor_v2: remove interrupt coalescing dmaengine: mv_xor_v2: set DMA mask to 40 bits drivers/dma/ep93xx_dma.c | 39 ++-- drivers/dma/mv_xor_v2.c| 109 ++--- drivers/dma/pl330.c| 3 +- drivers/dma/sh/rcar-dmac.c | 3 ++ drivers/dma/sh/usb-dmac.c | 2 +- 5 files changed, 85 insertions(+), 71 deletions(-) Thanks -- ~Vinod signature.asc Description: PGP signature
[PATCH v2 5/6] arm64: dts: hikey960: add device node for pmic and regulators
From: Wang Xiaoyin
add device node for hi6421 pmic core and hi6421v530
voltage regulator,include LDO(1,3,9,11,15,16)
Signed-off-by: Wang Xiaoyin
Signed-off-by: Guodong Xu
---
arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts | 46 +++
1 file changed, 46 insertions(+)
diff --git a/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
b/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
index ca448f0..9da8375 100644
--- a/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
+++ b/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
@@ -97,6 +97,52 @@
default-state = "off";
};
};
+
+ pmic: pmic@fff34000 {
+ compatible = "hisilicon,hi6421v530-pmic";
+ reg = <0x0 0xfff34000 0x0 0x1000>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+
+ regulators {
+ ldo3: LDO3 { /* HDMI */
+ regulator-name = "VOUT3_1V85";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <220>;
+ regulator-enable-ramp-delay = <120>;
+ };
+
+ ldo9: LDO9 { /* SDCARD I/O */
+ regulator-name = "VOUT9_1V8/2V95";
+ regulator-min-microvolt = <175>;
+ regulator-max-microvolt = <330>;
+ regulator-enable-ramp-delay = <240>;
+ };
+
+ ldo11: LDO11 { /* Low Speed Connector */
+ regulator-name = "VOUT11_1V8/2V95";
+ regulator-min-microvolt = <175>;
+ regulator-max-microvolt = <330>;
+ regulator-enable-ramp-delay = <240>;
+ };
+
+ ldo15: LDO15 { /* UFS VCC */
+ regulator-name = "VOUT15_3V0";
+ regulator-min-microvolt = <175>;
+ regulator-max-microvolt = <300>;
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-enable-ramp-delay = <120>;
+ };
+
+ ldo16: LDO16 { /* SD VDD */
+ regulator-name = "VOUT16_2V95";
+ regulator-min-microvolt = <175>;
+ regulator-max-microvolt = <300>;
+ regulator-enable-ramp-delay = <360>;
+ };
+ };
+ };
};
&i2c0 {
--
2.10.2
[PATCH v2 6/6] arm64: defconfig: enable support hi6421v530 PMIC
Enable configs for hi6421v530 mfd and regulator driver + CONFIG_MFD_HI6421_PMIC=y + CONFIG_REGULATOR_HI6421V530=y Signed-off-by: Guodong Xu --- arch/arm64/configs/defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index ce07285..867d68c 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -305,6 +305,7 @@ CONFIG_S3C2410_WATCHDOG=y CONFIG_MESON_GXBB_WATCHDOG=m CONFIG_MESON_WATCHDOG=m CONFIG_MFD_EXYNOS_LPASS=m +CONFIG_MFD_HI6421_PMIC=y CONFIG_MFD_MAX77620=y CONFIG_MFD_RK808=y CONFIG_MFD_SPMI_PMIC=y @@ -315,6 +316,7 @@ CONFIG_MFD_CROS_EC=y CONFIG_MFD_CROS_EC_I2C=y CONFIG_REGULATOR_FIXED_VOLTAGE=y CONFIG_REGULATOR_GPIO=y +CONFIG_REGULATOR_HI6421V530=y CONFIG_REGULATOR_HI655X=y CONFIG_REGULATOR_MAX77620=y CONFIG_REGULATOR_PWM=y -- 2.10.2
[PATCH v2 2/6] mfd: hi6421-pmic: add support for HiSilicon Hi6421v530
Add support for HiSilicon Hi6421v530 PMIC. Hi6421v530 communicates with
main SoC via memory-mapped I/O.
Hi6421v530 and Hi6421 are PMIC chips from the same vendor, HiSilicon,
but at different revisions. They share the same memory-mapped I/O
design. They differ in integrated devices, such as regulator details,
LDO voltage points.
Signed-off-by: Wang Xiaoyin
Signed-off-by: Guodong Xu
---
drivers/mfd/hi6421-pmic-core.c | 56 +++--
include/linux/mfd/hi6421-pmic.h | 5
2 files changed, 48 insertions(+), 13 deletions(-)
diff --git a/drivers/mfd/hi6421-pmic-core.c b/drivers/mfd/hi6421-pmic-core.c
index 3fd703f..6d40485 100644
--- a/drivers/mfd/hi6421-pmic-core.c
+++ b/drivers/mfd/hi6421-pmic-core.c
@@ -26,7 +26,7 @@
#include
#include
#include
-#include
+#include
#include
#include
#include
@@ -35,6 +35,10 @@ static const struct mfd_cell hi6421_devs[] = {
{ .name = "hi6421-regulator", },
};
+static const struct mfd_cell hi6421v530_devs[] = {
+ { .name = "hi6421v530-regulator", },
+};
+
static const struct regmap_config hi6421_regmap_config = {
.reg_bits = 32,
.reg_stride = 4,
@@ -42,12 +46,30 @@ static const struct regmap_config hi6421_regmap_config = {
.max_register = HI6421_REG_TO_BUS_ADDR(HI6421_REG_MAX),
};
+static const struct of_device_id of_hi6421_pmic_match_tbl[] = {
+ { .compatible = "hisilicon,hi6421-pmic",
+ .data = (void *)HI6421 },
+ { .compatible = "hisilicon,hi6421v530-pmic",
+ .data = (void *)HI6421_V530 },
+ { },
+};
+MODULE_DEVICE_TABLE(of, of_hi6421_pmic_match_tbl);
+
static int hi6421_pmic_probe(struct platform_device *pdev)
{
struct hi6421_pmic *pmic;
struct resource *res;
void __iomem *base;
- int ret;
+ const struct of_device_id *id;
+ unsigned long type;
+ const struct mfd_cell *subdevs = NULL;
+ int n_subdevs, ret;
+
+ id = of_match_device(of_hi6421_pmic_match_tbl, &pdev->dev);
+ if (id)
+ type = (unsigned long)id->data;
+ else
+ return -EINVAL;
pmic = devm_kzalloc(&pdev->dev, sizeof(*pmic), GFP_KERNEL);
if (!pmic)
@@ -66,18 +88,32 @@ static int hi6421_pmic_probe(struct platform_device *pdev)
return PTR_ERR(pmic->regmap);
}
- /* set over-current protection debounce 8ms */
- regmap_update_bits(pmic->regmap, HI6421_OCP_DEB_CTRL_REG,
+ platform_set_drvdata(pdev, pmic);
+
+ switch (type) {
+ case HI6421:
+ /* set over-current protection debounce 8ms */
+ regmap_update_bits(pmic->regmap, HI6421_OCP_DEB_CTRL_REG,
(HI6421_OCP_DEB_SEL_MASK
| HI6421_OCP_EN_DEBOUNCE_MASK
| HI6421_OCP_AUTO_STOP_MASK),
(HI6421_OCP_DEB_SEL_8MS
| HI6421_OCP_EN_DEBOUNCE_ENABLE));
- platform_set_drvdata(pdev, pmic);
+ subdevs = hi6421_devs;
+ n_subdevs = ARRAY_SIZE(hi6421_devs);
+ break;
+ case HI6421_V530:
+ subdevs = hi6421v530_devs;
+ n_subdevs = ARRAY_SIZE(hi6421v530_devs);
+ break;
+ default:
+ dev_err(&pdev->dev, "Unknown device type %ld\n", type);
+ return -EINVAL;
+ }
- ret = devm_mfd_add_devices(&pdev->dev, 0, hi6421_devs,
- ARRAY_SIZE(hi6421_devs), NULL, 0, NULL);
+ ret = devm_mfd_add_devices(&pdev->dev, 0, subdevs,
+ n_subdevs, NULL, 0, NULL);
if (ret) {
dev_err(&pdev->dev, "add mfd devices failed: %d\n", ret);
return ret;
@@ -86,12 +122,6 @@ static int hi6421_pmic_probe(struct platform_device *pdev)
return 0;
}
-static const struct of_device_id of_hi6421_pmic_match_tbl[] = {
- { .compatible = "hisilicon,hi6421-pmic", },
- { },
-};
-MODULE_DEVICE_TABLE(of, of_hi6421_pmic_match_tbl);
-
static struct platform_driver hi6421_pmic_driver = {
.driver = {
.name = "hi6421_pmic",
diff --git a/include/linux/mfd/hi6421-pmic.h b/include/linux/mfd/hi6421-pmic.h
index 587273e..2457438 100644
--- a/include/linux/mfd/hi6421-pmic.h
+++ b/include/linux/mfd/hi6421-pmic.h
@@ -38,4 +38,9 @@ struct hi6421_pmic {
struct regmap *regmap;
};
+enum hi6421_type {
+ HI6421 = 1,
+ HI6421_V530 = 2,
+};
+
#endif /* __HI6421_PMIC_H */
--
2.10.2
