Re: [PATCH v4 20/25] coresight: etm4x: Detect system instructions support
Hi Suzuki,
On Fri, Nov 20, 2020 at 12:45:42AM +0800, Suzuki K Poulose wrote:
> ETM v4.4 onwards adds support for system instruction access
> to the ETM. Detect the support on an ETM and switch to using the
> mode when available.
>
> Cc: Mike Leach
> Reviewed-by: Mathieu Poirier
> Signed-off-by: Suzuki K Poulose
> ---
> .../coresight/coresight-etm4x-core.c | 39 +++
> 1 file changed, 39 insertions(+)
>
> diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c
> b/drivers/hwtracing/coresight/coresight-etm4x-core.c
> index 7ac0a185c146..5cbea9c27f58 100644
> --- a/drivers/hwtracing/coresight/coresight-etm4x-core.c
> +++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c
> @@ -684,6 +684,37 @@ static const struct coresight_ops etm4_cs_ops = {
> .source_ops = _source_ops,
> };
>
> +static inline bool cpu_supports_sysreg_trace(void)
> +{
> + u64 dfr0 = read_sysreg_s(SYS_ID_AA64DFR0_EL1);
> +
> + return ((dfr0 >> ID_AA64DFR0_TRACEVER_SHIFT) & 0xfUL) > 0;
> +}
> +
> +static bool etm4_init_sysreg_access(struct etmv4_drvdata *drvdata,
> + struct csdev_access *csa)
> +{
> + u32 devarch;
> +
> + if (!cpu_supports_sysreg_trace())
> + return false;
> +
> + /*
> + * ETMs implementing sysreg access must implement TRCDEVARCH.
> + */
> + devarch = read_etm4x_sysreg_const_offset(TRCDEVARCH);
> + if ((devarch & ETM_DEVARCH_ID_MASK) != ETM_DEVARCH_ETMv4x_ARCH)
Is this driver suppose to work on ETM 5.0/ETE trace unit before ETE driver
is ready?
Thanks,
Tingwei
> + return false;
> + *csa = (struct csdev_access) {
> + .io_mem = false,
> + .read = etm4x_sysreg_read,
> + .write = etm4x_sysreg_write,
> + };
> +
> + drvdata->arch = etm_devarch_to_arch(devarch);
> + return true;
> +}
> +
> static bool etm4_init_iomem_access(struct etmv4_drvdata *drvdata,
> struct csdev_access *csa)
> {
> @@ -714,9 +745,17 @@ static bool etm4_init_iomem_access(struct etmv4_drvdata
> *drvdata,
> static bool etm4_init_csdev_access(struct etmv4_drvdata *drvdata,
> struct csdev_access *csa)
> {
> + /*
> + * Always choose the memory mapped io, if there is
> + * a memory map to prevent sysreg access on broken
> + * systems.
> + */
> if (drvdata->base)
> return etm4_init_iomem_access(drvdata, csa);
>
> + if (etm4_init_sysreg_access(drvdata, csa))
> + return true;
> +
> return false;
> }
>
> --
> 2.24.1
>
> ___
> CoreSight mailing list
> coresi...@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/coresight
[PATCH net-next 1/2] dt-bindings: net: nfc: s3fwrn5: Support a UART interface
Since S3FWRN82 NFC Chip, The UART interface can be used.
S3FWRN82 supports I2C and UART interface.
Signed-off-by: Bongsu Jeon
---
.../bindings/net/nfc/samsung,s3fwrn5.yaml | 28 +--
1 file changed, 26 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/nfc/samsung,s3fwrn5.yaml
b/Documentation/devicetree/bindings/net/nfc/samsung,s3fwrn5.yaml
index cb0b8a560282..37b3e5ae5681 100644
--- a/Documentation/devicetree/bindings/net/nfc/samsung,s3fwrn5.yaml
+++ b/Documentation/devicetree/bindings/net/nfc/samsung,s3fwrn5.yaml
@@ -13,6 +13,7 @@ maintainers:
properties:
compatible:
const: samsung,s3fwrn5-i2c
+const: samsung,s3fwrn82-uart
en-gpios:
maxItems: 1
@@ -47,10 +48,19 @@ additionalProperties: false
required:
- compatible
- en-gpios
- - interrupts
- - reg
- wake-gpios
+allOf:
+ - if:
+ properties:
+compatible:
+ contains:
+const: samsung,s3fwrn5-i2c
+then:
+ required:
+- interrupts
+- reg
+
examples:
- |
#include
@@ -71,3 +81,17 @@ examples:
wake-gpios = < 2 GPIO_ACTIVE_HIGH>;
};
};
+ # UART example on Raspberry Pi
+ - |
+ {
+status = "okay";
+
+s3fwrn82_uart {
+compatible = "samsung,s3fwrn82-uart";
+
+en-gpios = < 20 0>;
+wake-gpios = < 16 0>;
+
+status = "okay";
+};
+};
--
2.17.1
[PATCH net-next 2/2] net: nfc: s3fwrn5: Support a UART interface
Since S3FWRN82 NFC Chip, The UART interface can be used.
S3FWRN82 uses NCI protocol and supports I2C and UART interface.
Signed-off-by: Bongsu Jeon
---
drivers/nfc/s3fwrn5/Kconfig | 12 ++
drivers/nfc/s3fwrn5/Makefile | 2 +
drivers/nfc/s3fwrn5/uart.c | 250 +++
3 files changed, 264 insertions(+)
create mode 100644 drivers/nfc/s3fwrn5/uart.c
diff --git a/drivers/nfc/s3fwrn5/Kconfig b/drivers/nfc/s3fwrn5/Kconfig
index 3f8b6da58280..6f88737769e1 100644
--- a/drivers/nfc/s3fwrn5/Kconfig
+++ b/drivers/nfc/s3fwrn5/Kconfig
@@ -20,3 +20,15 @@ config NFC_S3FWRN5_I2C
To compile this driver as a module, choose m here. The module will
be called s3fwrn5_i2c.ko.
Say N if unsure.
+
+config NFC_S3FWRN82_UART
+ tristate "Samsung S3FWRN82 UART support"
+ depends on NFC_NCI && SERIAL_DEV_BUS
+ select NFC_S3FWRN5
+ help
+ This module adds support for a UART interface to the S3FWRN82 chip.
+ Select this if your platform is using the UART bus.
+
+ To compile this driver as a module, choose m here. The module will
+ be called s3fwrn82_uart.ko.
+ Say N if unsure.
diff --git a/drivers/nfc/s3fwrn5/Makefile b/drivers/nfc/s3fwrn5/Makefile
index d0ffa35f50e8..d1902102060b 100644
--- a/drivers/nfc/s3fwrn5/Makefile
+++ b/drivers/nfc/s3fwrn5/Makefile
@@ -5,6 +5,8 @@
s3fwrn5-objs = core.o firmware.o nci.o
s3fwrn5_i2c-objs = i2c.o
+s3fwrn82_uart-objs = uart.o
obj-$(CONFIG_NFC_S3FWRN5) += s3fwrn5.o
obj-$(CONFIG_NFC_S3FWRN5_I2C) += s3fwrn5_i2c.o
+obj-$(CONFIG_NFC_S3FWRN82_UART) += s3fwrn82_uart.o
diff --git a/drivers/nfc/s3fwrn5/uart.c b/drivers/nfc/s3fwrn5/uart.c
new file mode 100644
index ..b3c36a5b28d3
--- /dev/null
+++ b/drivers/nfc/s3fwrn5/uart.c
@@ -0,0 +1,250 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * UART Link Layer for S3FWRN82 NCI based Driver
+ *
+ * Copyright (C) 2020 Samsung Electronics
+ * Author: Bongsu Jeon
+ * All rights reserved.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "s3fwrn5.h"
+
+#define S3FWRN82_UART_DRIVER_NAME "s3fwrn82_uart"
+#define S3FWRN82_NCI_HEADER 3
+#define S3FWRN82_NCI_IDX 2
+#define S3FWRN82_EN_WAIT_TIME 20
+#define NCI_SKB_BUFF_LEN 258
+
+struct s3fwrn82_uart_phy {
+ struct serdev_device *ser_dev;
+ struct nci_dev *ndev;
+ struct sk_buff *recv_skb;
+
+ unsigned int gpio_en;
+ unsigned int gpio_fw_wake;
+
+ /* mutex is used to synchronize */
+ struct mutex mutex;
+ enum s3fwrn5_mode mode;
+};
+
+static void s3fwrn82_uart_set_wake(void *phy_id, bool wake)
+{
+ struct s3fwrn82_uart_phy *phy = phy_id;
+
+ mutex_lock(>mutex);
+ gpio_set_value(phy->gpio_fw_wake, wake);
+ msleep(S3FWRN82_EN_WAIT_TIME);
+ mutex_unlock(>mutex);
+}
+
+static void s3fwrn82_uart_set_mode(void *phy_id, enum s3fwrn5_mode mode)
+{
+ struct s3fwrn82_uart_phy *phy = phy_id;
+
+ mutex_lock(>mutex);
+ if (phy->mode == mode)
+ goto out;
+ phy->mode = mode;
+ gpio_set_value(phy->gpio_en, 1);
+ gpio_set_value(phy->gpio_fw_wake, 0);
+ if (mode == S3FWRN5_MODE_FW)
+ gpio_set_value(phy->gpio_fw_wake, 1);
+ if (mode != S3FWRN5_MODE_COLD) {
+ msleep(S3FWRN82_EN_WAIT_TIME);
+ gpio_set_value(phy->gpio_en, 0);
+ msleep(S3FWRN82_EN_WAIT_TIME);
+ }
+out:
+ mutex_unlock(>mutex);
+}
+
+static enum s3fwrn5_mode s3fwrn82_uart_get_mode(void *phy_id)
+{
+ struct s3fwrn82_uart_phy *phy = phy_id;
+ enum s3fwrn5_mode mode;
+
+ mutex_lock(>mutex);
+ mode = phy->mode;
+ mutex_unlock(>mutex);
+ return mode;
+}
+
+static int s3fwrn82_uart_write(void *phy_id, struct sk_buff *out)
+{
+ struct s3fwrn82_uart_phy *phy = phy_id;
+ int err;
+
+ err = serdev_device_write(phy->ser_dev,
+ out->data, out->len,
+ MAX_SCHEDULE_TIMEOUT);
+ if (err < 0)
+ return err;
+
+ return 0;
+}
+
+static const struct s3fwrn5_phy_ops uart_phy_ops = {
+ .set_wake = s3fwrn82_uart_set_wake,
+ .set_mode = s3fwrn82_uart_set_mode,
+ .get_mode = s3fwrn82_uart_get_mode,
+ .write = s3fwrn82_uart_write,
+};
+
+static int s3fwrn82_uart_read(struct serdev_device *serdev,
+ const unsigned char *data,
+ size_t count)
+{
+ struct s3fwrn82_uart_phy *phy = serdev_device_get_drvdata(serdev);
+ size_t i;
+
+ for (i = 0; i < count; i++) {
+ skb_put_u8(phy->recv_skb, *data++);
+
+ if (phy->recv_skb->len < S3FWRN82_NCI_HEADER)
+ continue;
+
+ if ((phy->recv_skb->len - S3FWRN82_NCI_HEADER)
+ < phy->recv_skb->data[S3FWRN82_NCI_IDX])
+
Re: [PATCH v3 1/2] hwmon: (max127) Add Maxim MAX127 hardware monitoring driver
On Sun, Nov 22, 2020 at 10:33:42AM -0800, Guenter Roeck wrote:
> On Thu, Nov 19, 2020 at 09:53:23AM -0800, rentao.b...@gmail.com wrote:
> > From: Tao Ren
> >
> > Add hardware monitoring driver for the Maxim MAX127 chip.
> >
> > MAX127 min/max range handling code is inspired by the max197 driver.
> >
> > Signed-off-by: Tao Ren
>
> Nice cleanup. Couple of minor comments.
>
> Thanks,
> Guenter
>
> > ---
> > Changes in v3:
> >- no code change. xdp maintainers were removed from to/cc list.
> > Changes in v2:
> >- replace devm_hwmon_device_register_with_groups() with
> > devm_hwmon_device_register_with_info() API.
> >- divide min/max read and write methods to separate functions.
> >- fix raw-to-vin conversion logic.
> >- refine ctrl_byte handling so mutex is not needed to protect the
> > byte.
> >- improve i2c_transfer() error handling.
> >- a few other improvements (comments, variable naming, and etc.).
> >
> > drivers/hwmon/Kconfig | 9 ++
> > drivers/hwmon/Makefile | 1 +
> > drivers/hwmon/max127.c | 346 +
> > 3 files changed, 356 insertions(+)
> > create mode 100644 drivers/hwmon/max127.c
> >
> > diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
> > index 9d600e0c5584..716df51edc87 100644
> > --- a/drivers/hwmon/Kconfig
> > +++ b/drivers/hwmon/Kconfig
> > @@ -950,6 +950,15 @@ config SENSORS_MAX
> > This driver can also be built as a module. If so, the module
> > will be called max.
> >
> > +config SENSORS_MAX127
> > + tristate "Maxim MAX127 12-bit 8-channel Data Acquisition System"
> > + depends on I2C
> > + help
> > + Say y here to support Maxim's MAX127 DAS chips.
> > +
> > + This driver can also be built as a module. If so, the module
> > + will be called max127.
> > +
> > config SENSORS_MAX16065
> > tristate "Maxim MAX16065 System Manager and compatibles"
> > depends on I2C
> > diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
> > index 1083bbfac779..01ca5d3fbad4 100644
> > --- a/drivers/hwmon/Makefile
> > +++ b/drivers/hwmon/Makefile
> > @@ -127,6 +127,7 @@ obj-$(CONFIG_SENSORS_LTC4260) += ltc4260.o
> > obj-$(CONFIG_SENSORS_LTC4261) += ltc4261.o
> > obj-$(CONFIG_SENSORS_LTQ_CPUTEMP) += ltq-cputemp.o
> > obj-$(CONFIG_SENSORS_MAX) += max.o
> > +obj-$(CONFIG_SENSORS_MAX127) += max127.o
> > obj-$(CONFIG_SENSORS_MAX16065) += max16065.o
> > obj-$(CONFIG_SENSORS_MAX1619) += max1619.o
> > obj-$(CONFIG_SENSORS_MAX1668) += max1668.o
> > diff --git a/drivers/hwmon/max127.c b/drivers/hwmon/max127.c
> > new file mode 100644
> > index ..3df4c225a6a2
> > --- /dev/null
> > +++ b/drivers/hwmon/max127.c
> > @@ -0,0 +1,346 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Hardware monitoring driver for MAX127.
> > + *
> > + * Copyright (c) 2020 Facebook Inc.
> > + */
> > +
> > +#include
> > +#include
> > +#include
>
> Not needed.
>
> > +#include
> > +#include
> > +#include
> > +#include
>
> Not needed.
Thanks for pointing it out. Both includes are deleted in v4.
>
> > +
> > +/*
> > + * MAX127 Control Byte. Refer to MAX127 datasheet, Table 1 "Control-Byte
> > + * Format" for details.
> > + */
> > +#define MAX127_CTRL_START BIT(7)
> > +#define MAX127_CTRL_SEL_SHIFT 4
> > +#define MAX127_CTRL_RNGBIT(3)
> > +#define MAX127_CTRL_BIPBIT(2)
> > +#define MAX127_CTRL_PD1BIT(1)
> > +#define MAX127_CTRL_PD0BIT(0)
> > +
> > +#define MAX127_NUM_CHANNELS8
> > +#define MAX127_SET_CHANNEL(ch) (((ch) & 7) << MAX127_CTRL_SEL_SHIFT)
> > +
> > +/*
> > + * MAX127 channel input ranges. Refer to MAX127 datasheet, Table 3 "Range
> > + * and Polarity Selection" for details.
> > + */
> > +#define MAX127_FULL_RANGE 1 /* 10V */
> > +#define MAX127_HALF_RANGE 5000/* 5V */
> > +
> > +/*
> > + * MAX127 returns 2 bytes at read:
> > + * - the first byte contains data[11:4].
> > + * - the second byte contains data[3:0] (MSB) and 4 dummy 0s (LSB).
> > + * Refer to MAX127 datasheet, "Read a Conversion (Read Cycle)" section
> > + * for details.
> > + */
> > +#define MAX127_DATA_LEN2
> > +#define MAX127_DATA_SHIFT 4
> > +
> > +#define MAX127_SIGN_BITBIT(11)
> > +
> > +struct max127_data {
> > + struct mutex lock;
> > + struct i2c_client *client;
> > + u8 ctrl_byte[MAX127_NUM_CHANNELS];
> > +};
> > +
> > +static int max127_select_channel(struct i2c_client *client, u8 ctrl_byte)
> > +{
> > + int status;
> > + struct i2c_msg msg = {
> > + .addr = client->addr,
> > + .flags = 0,
> > + .len = sizeof(ctrl_byte),
> > + .buf = _byte,
> > + };
> > +
> > + status = i2c_transfer(client->adapter, , 1);
> > + if (status < 0)
> > + return status;
> > + else if (status != 1)
>
> else after return is not needed.
>
> > + return -EIO;
> > +
> > +
Re: [PATCH 3/4] arm64: dts: meson-axg: add PCIe nodes
On 22/11/2020 23:14, Martin Blumenstingl wrote:
> Hi Neil,
>
> (I have to admit that for me the PCI(e) bindings are very complex, so
> I may be mixing up things. I am still sending this review mail because
> "you're doing it different than in meson-g12-common.dtsi")
>
> On Fri, Nov 20, 2020 at 4:33 PM Neil Armstrong
> wrote:
> [...]
>> + pcieA: pcie@f980 {
>> + compatible = "amlogic,axg-pcie", "snps,dw-pcie";
>> + reg = <0x0 0xf980 0x0 0x40>,
>> + <0x0 0xff646000 0x0 0x2000>,
>> + <0x0 0xf9f0 0x0 0x10>;
>> + reg-names = "elbi", "cfg", "config";
>> + interrupts = ;
>> + #interrupt-cells = <1>;
>> + interrupt-map-mask = <0 0 0 0>;
>> + interrupt-map = <0 0 0 0 GIC_SPI 179
>> IRQ_TYPE_EDGE_RISING>;
>> + bus-range = <0x0 0xff>;
>> + #address-cells = <3>;
>> + #size-cells = <2>;
>> + device_type = "pci";
>> + ranges = <0x8200 0 0xf9c0 0x0 0xf9c0 0
>> 0x0030>;
> only PCI IO space here, no PCI MEM space?
I know, I tried to add IO & MEM space like g12, but it doesn't work.
>
> [...]
>> + pcieB: pcie@fa00 {
>> + compatible = "amlogic,axg-pcie", "snps,dw-pcie";
>> + reg = <0x0 0xfa00 0x0 0x40>,
>> + <0x0 0xff648000 0x0 0x2000>,
>> + <0x0 0xfa40 0x0 0x10>;
>> + reg-names = "elbi", "cfg", "config";
>> + interrupts = ;
>> + #interrupt-cells = <1>;
>> + interrupt-map-mask = <0 0 0 0>;
>> + interrupt-map = <0 0 0 0 GIC_SPI 169
>> IRQ_TYPE_EDGE_RISING>;
>> + bus-range = <0x0 0xff>;
>> + #address-cells = <3>;
>> + #size-cells = <2>;
>> + device_type = "pci";
>> + ranges = <0x8200 0 0xfa50 0x0 0xfa50 0
>> 0x0030>;
> same as above: only PCI IO space here, no PCI MEM space?
Same,
I suspect they configured the two instance differently.
Anyway I managed to used an NVMe and a PCIe XHCI controller on each port
successfully.
Since I'm a PCIe nOOb, I don't know...
Neil
>
>
> Best regards,
> Martin
>
Re: [PATCH 0/4] arm64: dts: meson-axg-s400: add support for USB and PCIe
On 20/11/2020 20:45, Kevin Hilman wrote: > Kevin Hilman writes: > >> On Fri, 20 Nov 2020 16:32:25 +0100, Neil Armstrong wrote: >>> This adds the USB and PCIe to AXG, and enables USB & the two M.2 PCIe ports >>> on the S400 board. >>> >>> Dependencies: >>> - Patch 1, 2, 4: None >>> - Patch 3: [1] arm64: dts: meson-axg-s400: add support for Power Controller >>> & MIPI-DSI PHY >>> >>> [1] >>> https://lore.kernel.org/r/20201120152131.3918814-1-narmstr...@baylibre.com >>> >>> [...] >> >> Applied, thanks! >> >> [1/4] arm64: dts: meson-axg: add USB nodes >> commit: ca91acde9a9858a20522abbb2c79c6883ef9bc73 >> [2/4] arm64: dts: meson-axg-s400: enable USB OTG >> commit: 160f1630878e11668336fded29eeb0fe82fb3faf >> [3/4] arm64: dts: meson-axg: add PCIe nodes >> commit: 9bfc5abed67ae7dcc837dd8f6d61396d1cc9ac2b >> [4/4] arm64: dts: meson-axg-s400: enable PCIe M.2 Key E slots >> commit: eee685ef92d8cbabb2a61c45fe7d976c3ebc9b1e > > FYI... these commit IDs are no longer accurate. I relized that the USB > patches were already in my fixes branch, so needed a rebase. I fixed > everything up locally, but the commit IDs are no longer the same as > above. Oops it's my fault, i forgot they were merged on -rc2. thx, Neil > > Kevin >
[PATCH v4 1/2] hwmon: (max127) Add Maxim MAX127 hardware monitoring driver
From: Tao Ren
Add hardware monitoring driver for the Maxim MAX127 chip.
MAX127 min/max range handling code is inspired by the max197 driver.
Signed-off-by: Tao Ren
---
Changes in v4:
- delete unnecessary "#include" lines.
- simplify i2c_transfer() error handling.
- add mutex to protect ctrl_byte in write_min|max() functions.
Changes in v3:
- no code change. xdp maintainers were removed from to/cc list.
Changes in v2:
- replace devm_hwmon_device_register_with_groups() with
devm_hwmon_device_register_with_info() API.
- divide min/max read and write methods to separate functions.
- fix raw-to-vin conversion logic.
- refine ctrl_byte handling so mutex is not needed to protect the
byte.
- improve i2c_transfer() error handling.
- a few other improvements (comments, variable naming, and etc.).
drivers/hwmon/Kconfig | 9 ++
drivers/hwmon/Makefile | 1 +
drivers/hwmon/max127.c | 346 +
3 files changed, 356 insertions(+)
create mode 100644 drivers/hwmon/max127.c
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 9d600e0c5584..716df51edc87 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -950,6 +950,15 @@ config SENSORS_MAX
This driver can also be built as a module. If so, the module
will be called max.
+config SENSORS_MAX127
+ tristate "Maxim MAX127 12-bit 8-channel Data Acquisition System"
+ depends on I2C
+ help
+ Say y here to support Maxim's MAX127 DAS chips.
+
+ This driver can also be built as a module. If so, the module
+ will be called max127.
+
config SENSORS_MAX16065
tristate "Maxim MAX16065 System Manager and compatibles"
depends on I2C
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index 1083bbfac779..01ca5d3fbad4 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -127,6 +127,7 @@ obj-$(CONFIG_SENSORS_LTC4260) += ltc4260.o
obj-$(CONFIG_SENSORS_LTC4261) += ltc4261.o
obj-$(CONFIG_SENSORS_LTQ_CPUTEMP) += ltq-cputemp.o
obj-$(CONFIG_SENSORS_MAX) += max.o
+obj-$(CONFIG_SENSORS_MAX127) += max127.o
obj-$(CONFIG_SENSORS_MAX16065) += max16065.o
obj-$(CONFIG_SENSORS_MAX1619) += max1619.o
obj-$(CONFIG_SENSORS_MAX1668) += max1668.o
diff --git a/drivers/hwmon/max127.c b/drivers/hwmon/max127.c
new file mode 100644
index ..1c54146b6086
--- /dev/null
+++ b/drivers/hwmon/max127.c
@@ -0,0 +1,346 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Hardware monitoring driver for MAX127.
+ *
+ * Copyright (c) 2020 Facebook Inc.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+/*
+ * MAX127 Control Byte. Refer to MAX127 datasheet, Table 1 "Control-Byte
+ * Format" for details.
+ */
+#define MAX127_CTRL_START BIT(7)
+#define MAX127_CTRL_SEL_SHIFT 4
+#define MAX127_CTRL_RNGBIT(3)
+#define MAX127_CTRL_BIPBIT(2)
+#define MAX127_CTRL_PD1BIT(1)
+#define MAX127_CTRL_PD0BIT(0)
+
+#define MAX127_NUM_CHANNELS8
+#define MAX127_SET_CHANNEL(ch) (((ch) & 7) << MAX127_CTRL_SEL_SHIFT)
+
+/*
+ * MAX127 channel input ranges. Refer to MAX127 datasheet, Table 3 "Range
+ * and Polarity Selection" for details.
+ */
+#define MAX127_FULL_RANGE 1 /* 10V */
+#define MAX127_HALF_RANGE 5000/* 5V */
+
+/*
+ * MAX127 returns 2 bytes at read:
+ * - the first byte contains data[11:4].
+ * - the second byte contains data[3:0] (MSB) and 4 dummy 0s (LSB).
+ * Refer to MAX127 datasheet, "Read a Conversion (Read Cycle)" section
+ * for details.
+ */
+#define MAX127_DATA_LEN2
+#define MAX127_DATA_SHIFT 4
+
+#define MAX127_SIGN_BITBIT(11)
+
+struct max127_data {
+ struct mutex lock;
+ struct i2c_client *client;
+ u8 ctrl_byte[MAX127_NUM_CHANNELS];
+};
+
+static int max127_select_channel(struct i2c_client *client, u8 ctrl_byte)
+{
+ int status;
+ struct i2c_msg msg = {
+ .addr = client->addr,
+ .flags = 0,
+ .len = sizeof(ctrl_byte),
+ .buf = _byte,
+ };
+
+ status = i2c_transfer(client->adapter, , 1);
+
+ return (status == 1) ? 0 : -EIO;
+}
+
+static int max127_read_channel(struct i2c_client *client, long *val)
+{
+ int status;
+ u8 i2c_data[MAX127_DATA_LEN];
+ struct i2c_msg msg = {
+ .addr = client->addr,
+ .flags = I2C_M_RD,
+ .len = sizeof(i2c_data),
+ .buf = i2c_data,
+ };
+
+ status = i2c_transfer(client->adapter, , 1);
+ if (status != 1)
+ return -EIO;
+
+ *val = (i2c_data[1] >> MAX127_DATA_SHIFT) |
+ ((u16)i2c_data[0] << MAX127_DATA_SHIFT);
+ return 0;
+}
+
+static long max127_process_raw(u8 ctrl_byte, long raw)
+{
+ long scale, weight;
+
+ /*
+* MAX127's data coding is binary in
Hello dear,
Hello dear, Attn Sir/Madam I apologize for the intrusion but this is the only way I can contact you. I have something I wanna talk to you about, it's really important and I wish and hope you'd respond. I'll wait for your response. Thank you! Regards. Mrs. Lia Ahil
[PATCH v4 2/2] docs: hwmon: Document max127 driver
From: Tao Ren
Add documentation for the max127 hardware monitoring driver.
Signed-off-by: Tao Ren
Reviewed-by: Guenter Roeck
---
Changes in v4:
- None.
Changes in v3:
- no code change. xdp maintainers were removed from to/cc list.
Changes in v2:
- add more description for min/max sysfs nodes.
- convert values from volt to millivolt in the document.
Documentation/hwmon/index.rst | 1 +
Documentation/hwmon/max127.rst | 45 ++
2 files changed, 46 insertions(+)
create mode 100644 Documentation/hwmon/max127.rst
diff --git a/Documentation/hwmon/index.rst b/Documentation/hwmon/index.rst
index 408760d13813..0a07b6000c20 100644
--- a/Documentation/hwmon/index.rst
+++ b/Documentation/hwmon/index.rst
@@ -111,6 +111,7 @@ Hardware Monitoring Kernel Drivers
ltc4245
ltc4260
ltc4261
+ max127
max16064
max16065
max1619
diff --git a/Documentation/hwmon/max127.rst b/Documentation/hwmon/max127.rst
new file mode 100644
index ..dc192dd9c37c
--- /dev/null
+++ b/Documentation/hwmon/max127.rst
@@ -0,0 +1,45 @@
+.. SPDX-License-Identifier: GPL-2.0-or-later
+
+Kernel driver max127
+
+
+Author:
+
+ * Tao Ren
+
+Supported chips:
+
+ * Maxim MAX127
+
+Prefix: 'max127'
+
+Datasheet: https://datasheets.maximintegrated.com/en/ds/MAX127-MAX128.pdf
+
+Description
+---
+
+The MAX127 is a multirange, 12-bit data acquisition system (DAS) providing
+8 analog input channels that are independently software programmable for
+a variety of ranges. The available ranges are {0,5V}, {0,10V}, {-5,5V}
+and {-10,10V}.
+
+The MAX127 features a 2-wire, I2C-compatible serial interface that allows
+communication among multiple devices using SDA and SCL lines.
+
+Sysfs interface
+---
+
+ == ==
+ in[0-7]_input The input voltage (in mV) of the corresponding channel.
+RO
+
+ in[0-7]_minThe lower input limit (in mV) for the corresponding channel.
+ADC range and LSB will be updated when the limit is changed.
+For the MAX127, it will be adjusted to -1, -5000, or 0.
+RW
+
+ in[0-7]_maxThe higher input limit (in mV) for the corresponding channel.
+ADC range and LSB will be updated when the limit is changed.
+For the MAX127, it will be adjusted to 0, 5000, or 1.
+RW
+ == ==
--
2.17.1
Re: [External] Re: [PATCH v5 13/21] mm/hugetlb: Use PG_slab to indicate split pmd
On Fri 20-11-20 17:30:27, Muchun Song wrote: > On Fri, Nov 20, 2020 at 4:16 PM Michal Hocko wrote: > > > > On Fri 20-11-20 14:43:17, Muchun Song wrote: > > > When we allocate hugetlb page from buddy, we may need split huge pmd > > > to pte. When we free the hugetlb page, we can merge pte to pmd. So > > > we need to distinguish whether the previous pmd has been split. The > > > page table is not allocated from slab. So we can reuse the PG_slab > > > to indicate that the pmd has been split. > > > > PageSlab is used outside of the slab allocator proper and that code > > might get confused by this AFAICS. > > I got your concerns. Maybe we can use PG_private instead of the > PG_slab. Reusing a page flag arbitrarily is not that easy. Hugetlb pages have a lot of spare room in struct page so I would rather use something else. -- Michal Hocko SUSE Labs
[PATCH v4 0/2] hwmon: (max127) Add Maxim MAX127 hardware monitoring
From: Tao Ren The patch series adds hardware monitoring driver for the Maxim MAX127 chip. Patch #1 adds the max127 hardware monitoring driver, and patch #2 adds documentation for the driver. Tao Ren (2): hwmon: (max127) Add Maxim MAX127 hardware monitoring driver docs: hwmon: Document max127 driver Documentation/hwmon/index.rst | 1 + Documentation/hwmon/max127.rst | 45 + drivers/hwmon/Kconfig | 9 + drivers/hwmon/Makefile | 1 + drivers/hwmon/max127.c | 346 + 5 files changed, 402 insertions(+) create mode 100644 Documentation/hwmon/max127.rst create mode 100644 drivers/hwmon/max127.c -- 2.17.1
Re: [PATCH v2] m68k: Fix WARNING splat in pmac_zilog driver
On Sun, Nov 22, 2020 at 12:40 AM Finn Thain wrote:
> Don't add platform resources that won't be used. This avoids a
> recently-added warning from the driver core, that can show up on a
> multi-platform kernel when !MACH_IS_MAC.
>
> [ cut here ]
> WARNING: CPU: 0 PID: 0 at drivers/base/platform.c:224
> platform_get_irq_optional+0x8e/0xce
> 0 is an invalid IRQ number
> Modules linked in:
> CPU: 0 PID: 0 Comm: swapper Not tainted 5.9.0-multi #1
> Stack from 004b3f04:
> 004b3f04 00462c2f 00462c2f 004b3f20 0002e128 004754db 004b6ad4
> 004b3f4c
> 0002e19c 004754f7 00e0 00285ba0 0009 004b3f44
>
> 004754db 004b3f64 004b3f74 00285ba0 004754f7 00e0 0009
> 004754db
> 004fdf0c 005269e2 004fdf0c 004b3f88 00285cae 004b6964
>
> 004fdf0c 004b3fac 0051cc68 004b6964 004b6964 0200
>
> 0051cc3e 0023c18a 004b3fc0 0051cd8a 004fdf0c 0002 0052b43c
> 004b3fc8
> Call Trace: [<0002e128>] __warn+0xa6/0xd6
> [<0002e19c>] warn_slowpath_fmt+0x44/0x76
> [<00285ba0>] platform_get_irq_optional+0x8e/0xce
> [<00285ba0>] platform_get_irq_optional+0x8e/0xce
> [<00285cae>] platform_get_irq+0x12/0x4c
> [<0051cc68>] pmz_init_port+0x2a/0xa6
> [<0051cc3e>] pmz_init_port+0x0/0xa6
> [<0023c18a>] strlen+0x0/0x22
> [<0051cd8a>] pmz_probe+0x34/0x88
> [<0051cde6>] pmz_console_init+0x8/0x28
> [<00511776>] console_init+0x1e/0x28
> [<0005a3bc>] printk+0x0/0x16
> [<0050a8a6>] start_kernel+0x368/0x4ce
> [<005094f8>] _sinittext+0x4f8/0xc48
> random: get_random_bytes called from print_oops_end_marker+0x56/0x80 with
> crng_init=0
> ---[ end trace 392d8e82eed68d6c ]---
>
> Commit a85a6c86c25b ("driver core: platform: Clarify that IRQ 0 is invalid"),
> which introduced the WARNING, suggests that testing for irq == 0 is
> undesirable. Instead of that comparison, just test for resource existence.
>
> Cc: Michael Ellerman
> Cc: Benjamin Herrenschmidt
> Cc: Paul Mackerras
> Cc: Joshua Thompson
> Cc: Greg Kroah-Hartman
> Cc: Jiri Slaby
> Cc: sta...@vger.kernel.org # v5.8+
> References: commit a85a6c86c25b ("driver core: platform: Clarify that IRQ 0
> is invalid")
> Reported-by: Laurent Vivier
> Signed-off-by: Finn Thain
Reviewed-by: Geert Uytterhoeven
i.e. will queue in the m68k for-v5.11 branch.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
linux-next: build failure in Linus' tree
Hi all,
After merging most of the trees, today's linux-next build (powerpc64
allnoconfig) failed like this:
In file included from arch/powerpc/include/asm/kup.h:18,
from arch/powerpc/include/asm/uaccess.h:9,
from include/linux/uaccess.h:11,
from include/linux/sched/task.h:11,
from include/linux/sched/signal.h:9,
from include/linux/rcuwait.h:6,
from include/linux/percpu-rwsem.h:7,
from include/linux/fs.h:33,
from include/linux/compat.h:17,
from arch/powerpc/kernel/asm-offsets.c:14:
arch/powerpc/include/asm/book3s/64/kup-radix.h:66:1: warning: data definition
has no type or storage class
66 | DECLARE_STATIC_KEY_FALSE(uaccess_flush_key);
| ^~~~
arch/powerpc/include/asm/book3s/64/kup-radix.h:66:1: error: type defaults to
'int' in declaration of 'DECLARE_STATIC_KEY_FALSE' [-Werror=implicit-int]
arch/powerpc/include/asm/book3s/64/kup-radix.h:66:1: warning: parameter names
(without types) in function declaration
arch/powerpc/include/asm/book3s/64/kup-radix.h: In function
'prevent_user_access':
arch/powerpc/include/asm/book3s/64/kup-radix.h:180:6: error: implicit
declaration of function 'static_branch_unlikely'
[-Werror=implicit-function-declaration]
180 | if (static_branch_unlikely(_flush_key))
| ^~
arch/powerpc/include/asm/book3s/64/kup-radix.h:180:30: error:
'uaccess_flush_key' undeclared (first use in this function)
180 | if (static_branch_unlikely(_flush_key))
| ^
arch/powerpc/include/asm/book3s/64/kup-radix.h:180:30: note: each undeclared
identifier is reported only once for each function it appears in
arch/powerpc/include/asm/book3s/64/kup-radix.h: In function
'prevent_user_access_return':
arch/powerpc/include/asm/book3s/64/kup-radix.h:189:30: error:
'uaccess_flush_key' undeclared (first use in this function)
189 | if (static_branch_unlikely(_flush_key))
| ^
arch/powerpc/include/asm/book3s/64/kup-radix.h: In function
'restore_user_access':
arch/powerpc/include/asm/book3s/64/kup-radix.h:198:30: error:
'uaccess_flush_key' undeclared (first use in this function)
198 | if (static_branch_unlikely(_flush_key) && flags ==
AMR_KUAP_BLOCKED)
| ^
Caused by commit
9a32a7e78bd0 ("powerpc/64s: flush L1D after user accesses")
I have applied the following patch for today:
From: Stephen Rothwell
Date: Mon, 23 Nov 2020 18:35:02 +1100
Subject: [PATCH] powerpc/64s: using DECLARE_STATIC_KEY_FALSE needs
linux/jump_table.h
Fixes: 9a32a7e78bd0 ("powerpc/64s: flush L1D after user accesses")
Signed-off-by: Stephen Rothwell
---
arch/powerpc/include/asm/book3s/64/kup-radix.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/powerpc/include/asm/book3s/64/kup-radix.h
b/arch/powerpc/include/asm/book3s/64/kup-radix.h
index 28716e2f13e3..a39e2d193fdc 100644
--- a/arch/powerpc/include/asm/book3s/64/kup-radix.h
+++ b/arch/powerpc/include/asm/book3s/64/kup-radix.h
@@ -63,6 +63,8 @@
#else /* !__ASSEMBLY__ */
+#include
+
DECLARE_STATIC_KEY_FALSE(uaccess_flush_key);
#ifdef CONFIG_PPC_KUAP
--
2.29.2
--
Cheers,
Stephen Rothwell
pgpkxysaKVgJn.pgp
Description: OpenPGP digital signature
Re: [External] Re: [PATCH v5 00/21] Free some vmemmap pages of hugetlb page
On Fri 20-11-20 23:44:26, Muchun Song wrote: > On Fri, Nov 20, 2020 at 9:11 PM Michal Hocko wrote: > > > > On Fri 20-11-20 20:40:46, Muchun Song wrote: > > > On Fri, Nov 20, 2020 at 4:42 PM Michal Hocko wrote: > > > > > > > > On Fri 20-11-20 14:43:04, Muchun Song wrote: > > > > [...] > > > > > > > > Thanks for improving the cover letter and providing some numbers. I have > > > > only glanced through the patchset because I didn't really have more time > > > > to dive depply into them. > > > > > > > > Overall it looks promissing. To summarize. I would prefer to not have > > > > the feature enablement controlled by compile time option and the kernel > > > > command line option should be opt-in. I also do not like that freeing > > > > the pool can trigger the oom killer or even shut the system down if no > > > > oom victim is eligible. > > > > > > Hi Michal, > > > > > > I have replied to you about those questions on the other mail thread. > > > > > > Thanks. > > > > > > > > > > > One thing that I didn't really get to think hard about is what is the > > > > effect of vmemmap manipulation wrt pfn walkers. pfn_to_page can be > > > > invalid when racing with the split. How do we enforce that this won't > > > > blow up? > > > > > > This feature depends on the CONFIG_SPARSEMEM_VMEMMAP, > > > in this case, the pfn_to_page can work. The return value of the > > > pfn_to_page is actually the address of it's struct page struct. > > > I can not figure out where the problem is. Can you describe the > > > problem in detail please? Thanks. > > > > struct page returned by pfn_to_page might get invalid right when it is > > returned because vmemmap could get freed up and the respective memory > > released to the page allocator and reused for something else. See? > > If the HugeTLB page is already allocated from the buddy allocator, > the struct page of the HugeTLB can be freed? Does this exist? Nope, struct pages only ever get deallocated when the respective memory (they describe) is hotremoved via hotplug. > If yes, how to free the HugeTLB page to the buddy allocator > (cannot access the struct page)? But I do not follow how that relates to my concern above. -- Michal Hocko SUSE Labs
Re: [PATCH v5 00/21] Free some vmemmap pages of hugetlb page
On Fri 20-11-20 09:45:12, Mike Kravetz wrote: > On 11/20/20 1:43 AM, David Hildenbrand wrote: [...] > >>> To keep things easy, maybe simply never allow to free these hugetlb pages > >>> again for now? If they were reserved during boot and the vmemmap > >>> condensed, > >>> then just let them stick around for all eternity. > >> > >> Not sure I understand. Do you propose to only free those vmemmap pages > >> when the pool is initialized during boot time and never allow to free > >> them up? That would certainly make it safer and maybe even simpler wrt > >> implementation. > > > > Exactly, let's keep it simple for now. I guess most use cases of this > > (virtualization, databases, ...) will allocate hugepages during boot and > > never free them. > > Not sure if I agree with that last statement. Database and virtualization > use cases from my employer allocate allocate hugetlb pages after boot. It > is shortly after boot, but still not from boot/kernel command line. Is there any strong reason for that? > Somewhat related, but not exactly addressing this issue ... > > One idea discussed in a previous patch set was to disable PMD/huge page > mapping of vmemmap if this feature was enabled. This would eliminate a bunch > of the complex code doing page table manipulation. It does not address > the issue of struct page pages going away which is being discussed here, > but it could be a way to simply the first version of this code. If this > is going to be an 'opt in' feature as previously suggested, then eliminating > the PMD/huge page vmemmap mapping may be acceptable. My guess is that > sysadmins would only 'opt in' if they expect most of system memory to be used > by hugetlb pages. We certainly have database and virtualization use cases > where this is true. Would this simplify the code considerably? I mean, the vmemmap page tables will need to be updated anyway. So that code has to stay. PMD entry split shouldn't be the most complex part of that operation. On the other hand dropping large pages for all vmemmaps will likely have a performance. -- Michal Hocko SUSE Labs
[RESEND,PATCH] ARM: fix __div64_32() error when compiling with clang
__do_div64 clobbers the input register r0 in little endian system.
According to the inline assembly document, if an input operand is
modified, it should be tied to a output operand. This patch can
prevent compilers from reusing r0 register after asm statements.
Signed-off-by: Antony Yu
---
arch/arm/include/asm/div64.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/div64.h b/arch/arm/include/asm/div64.h
index 898e9c78a7e7..809efc51e90f 100644
--- a/arch/arm/include/asm/div64.h
+++ b/arch/arm/include/asm/div64.h
@@ -39,9 +39,10 @@ static inline uint32_t __div64_32(uint64_t *n, uint32_t base)
asm(__asmeq("%0", __xh)
__asmeq("%1", "r2")
__asmeq("%2", "r0")
- __asmeq("%3", "r4")
+ __asmeq("%3", "r0")
+ __asmeq("%4", "r4")
"bl __do_div64"
- : "=r" (__rem), "=r" (__res)
+ : "=r" (__rem), "=r" (__res), "=r" (__n)
: "r" (__n), "r" (__base)
: "ip", "lr", "cc");
*n = __res;
--
2.23.0
[RFC PATCH v4 2/2] ACPI: Advertise Interrupt ResourceSource support
As mentioned in ACPI v6.3, Table 6-200, the platform will indicate
to the OS whether or not it supports usage of ResourceSource. If
not set, the OS may choose to ignore the ResourceSource parameter
in the extended interrupt descriptor. Since we support parsing
ResoureSource field of interrupts both for platform devices and
PCI Interrupt Link devices now, this patch sets the relevant OSC
bit and checks the capability as described in ACPI specification.
Signed-off-by: Chen Baozi
Cc: Jonathan Cameron
---
drivers/acpi/bus.c | 5 +
drivers/acpi/irq.c | 3 ++-
include/linux/acpi.h | 4 +++-
3 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index 1682f8b454a2..a6af1270bea6 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -281,6 +281,8 @@ bool osc_sb_apei_support_acked;
bool osc_pc_lpi_support_confirmed;
EXPORT_SYMBOL_GPL(osc_pc_lpi_support_confirmed);
+bool osc_sb_intr_ressrc_support_confirmed;
+
static u8 sb_uuid_str[] = "0811B06E-4A27-44F9-8D60-3CBBC22E7B48";
static void acpi_bus_osc_support(void)
{
@@ -303,6 +305,7 @@ static void acpi_bus_osc_support(void)
capbuf[OSC_SUPPORT_DWORD] |= OSC_SB_HOTPLUG_OST_SUPPORT;
capbuf[OSC_SUPPORT_DWORD] |= OSC_SB_PCLPI_SUPPORT;
+ capbuf[OSC_SUPPORT_DWORD] |= OSC_SB_INTR_RESSRC_SUPPORT;
#ifdef CONFIG_ARM64
capbuf[OSC_SUPPORT_DWORD] |= OSC_SB_GENERIC_INITIATOR_SUPPORT;
#endif
@@ -328,6 +331,8 @@ static void acpi_bus_osc_support(void)
capbuf_ret[OSC_SUPPORT_DWORD] &
OSC_SB_APEI_SUPPORT;
osc_pc_lpi_support_confirmed =
capbuf_ret[OSC_SUPPORT_DWORD] &
OSC_SB_PCLPI_SUPPORT;
+ osc_sb_intr_ressrc_support_confirmed =
+ capbuf_ret[OSC_SUPPORT_DWORD] &
OSC_SB_INTR_RESSRC_SUPPORT;
}
kfree(context.ret.pointer);
}
diff --git a/drivers/acpi/irq.c b/drivers/acpi/irq.c
index 86336a89f73e..8f4d2dff5538 100644
--- a/drivers/acpi/irq.c
+++ b/drivers/acpi/irq.c
@@ -108,7 +108,8 @@ acpi_get_irq_source_fwhandle(const struct
acpi_resource_source *source)
acpi_handle handle;
acpi_status status;
- if (!source->string_length)
+ if (!osc_sb_intr_ressrc_support_confirmed ||
+ !source->string_length)
return acpi_gsi_domain_id;
status = acpi_get_handle(NULL, source->string_ptr, );
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index b182a267fe66..f9ca8e117f31 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -555,10 +555,12 @@ acpi_status acpi_run_osc(acpi_handle handle, struct
acpi_osc_context *context);
#define OSC_SB_PCLPI_SUPPORT 0x0080
#define OSC_SB_OSLPI_SUPPORT 0x0100
#define OSC_SB_CPC_DIVERSE_HIGH_SUPPORT0x1000
-#define OSC_SB_GENERIC_INITIATOR_SUPPORT 0x2000
+#define OSC_SB_INTR_RESSRC_SUPPORT 0x2000
+#define OSC_SB_GENERIC_INITIATOR_SUPPORT 0x0002
extern bool osc_sb_apei_support_acked;
extern bool osc_pc_lpi_support_confirmed;
+extern bool osc_sb_intr_ressrc_support_confirmed;
/* PCI Host Bridge _OSC: Capabilities DWORD 2: Support Field */
#define OSC_PCI_EXT_CONFIG_SUPPORT 0x0001
--
2.28.0
[RFC PATCH v4 1/2] PCI/ACPI: Add stacked IRQ domain support to PCI Interrupt Link
The ResourceSource field of an Extended Interrupt Descriptor was ignored
when the driver is parsing _PRS method of PNP0C0F PCI Interrupt Link
devices, which means PCI INTx would be always registered under the GSI
domain. This patch introduces stacked IRQ domain support to PCI Interrupt
Link devices for ACPI.
With this support, we can populate the ResourceSource field in _PRS method
of PCI Interrupt Link devices to refer to a device object that describes
an interrupt controller as the following examples:
Device (IXIU) {
...
}
Device(LINKA) {
Name(_HID, EISAID("PNP0C0F"))
Name(_PRS, ResourceTemplate(){
Interrupt(ResourceProducer, Level, ActiveHigh, Exclusive,
0, "\\SB.IXIU") { 60 }
})
...
}
Signed-off-by: Chen Baozi
---
v3->v4:
Include "internal.h" in drivers/acpi/irq.c to avoid the warning because
of lacking prototype for 'acpi_register_irq'
drivers/acpi/internal.h | 12
drivers/acpi/irq.c | 36 ++--
drivers/acpi/pci_irq.c | 8 ++--
drivers/acpi/pci_link.c | 17 +++--
include/acpi/acpi_drivers.h | 2 +-
include/linux/acpi.h| 10 ++
6 files changed, 66 insertions(+), 19 deletions(-)
diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
index e3638bafb941..38ebe24bce3b 100644
--- a/drivers/acpi/internal.h
+++ b/drivers/acpi/internal.h
@@ -88,6 +88,18 @@ bool acpi_scan_is_offline(struct acpi_device *adev, bool
uevent);
acpi_status acpi_sysfs_table_handler(u32 event, void *table, void *context);
void acpi_scan_table_handler(u32 event, void *table, void *context);
+#ifdef CONFIG_ACPI_GENERIC_GSI
+int acpi_register_irq(struct device *dev, u32 hwirq, int trigger,
+ int polarity, struct fwnode_handle *fwnode);
+#else
+static inline
+int acpi_register_irq(struct device *dev, u32 hwirq, int trigger,
+ int polarity, struct fwnode_handle *fwnode)
+{
+ return acpi_register_gsi(dev, hwirq, trigger, polarity);
+}
+#endif
+
/* --
Device Node Initialization / Removal
--
*/
diff --git a/drivers/acpi/irq.c b/drivers/acpi/irq.c
index e209081d644b..86336a89f73e 100644
--- a/drivers/acpi/irq.c
+++ b/drivers/acpi/irq.c
@@ -10,6 +10,8 @@
#include
#include
+#include "internal.h"
+
enum acpi_irq_model_id acpi_irq_model;
static struct fwnode_handle *acpi_gsi_domain_id;
@@ -38,6 +40,24 @@ int acpi_gsi_to_irq(u32 gsi, unsigned int *irq)
}
EXPORT_SYMBOL_GPL(acpi_gsi_to_irq);
+int acpi_register_irq(struct device *dev, u32 hwirq, int trigger,
+ int polarity, struct fwnode_handle *fwnode)
+{
+ struct irq_fwspec fwspec;
+
+ if (!fwnode) {
+ dev_warn(dev, "No registered irqchip for hwirq %d\n", hwirq);
+ return -EINVAL;
+ }
+
+ fwspec.fwnode = fwnode;
+ fwspec.param[0] = hwirq;
+ fwspec.param[1] = acpi_dev_get_irq_type(trigger, polarity);
+ fwspec.param_count = 2;
+
+ return irq_create_fwspec_mapping();
+}
+
/**
* acpi_register_gsi() - Map a GSI to a linux IRQ number
* @dev: device for which IRQ has to be mapped
@@ -51,19 +71,7 @@ EXPORT_SYMBOL_GPL(acpi_gsi_to_irq);
int acpi_register_gsi(struct device *dev, u32 gsi, int trigger,
int polarity)
{
- struct irq_fwspec fwspec;
-
- if (WARN_ON(!acpi_gsi_domain_id)) {
- pr_warn("GSI: No registered irqchip, giving up\n");
- return -EINVAL;
- }
-
- fwspec.fwnode = acpi_gsi_domain_id;
- fwspec.param[0] = gsi;
- fwspec.param[1] = acpi_dev_get_irq_type(trigger, polarity);
- fwspec.param_count = 2;
-
- return irq_create_fwspec_mapping();
+ return acpi_register_irq(dev, gsi, trigger, polarity,
acpi_gsi_domain_id);
}
EXPORT_SYMBOL_GPL(acpi_register_gsi);
@@ -92,7 +100,7 @@ EXPORT_SYMBOL_GPL(acpi_unregister_gsi);
* Return:
* The referenced device fwhandle or NULL on failure
*/
-static struct fwnode_handle *
+struct fwnode_handle *
acpi_get_irq_source_fwhandle(const struct acpi_resource_source *source)
{
struct fwnode_handle *result;
diff --git a/drivers/acpi/pci_irq.c b/drivers/acpi/pci_irq.c
index 14ee631cb7cf..50f70781 100644
--- a/drivers/acpi/pci_irq.c
+++ b/drivers/acpi/pci_irq.c
@@ -22,6 +22,8 @@
#include
#include
+#include "internal.h"
+
#define PREFIX "ACPI: "
#define _COMPONENT ACPI_PCI_COMPONENT
@@ -410,6 +412,7 @@ int acpi_pci_irq_enable(struct pci_dev *dev)
char *link = NULL;
char link_desc[16];
int rc;
+ struct fwnode_handle *rs_fwnode;
pin = dev->pin;
if (!pin) {
@@ -438,7 +441,8 @@ int acpi_pci_irq_enable(struct pci_dev *dev)
gsi = acpi_pci_link_allocate_irq(entry->link,
Re: [PATCH v4 3/4] clk: sifive: Add a driver for the SiFive FU740 PRCI IP block
On Sat, Nov 21, 2020 at 9:29 AM Palmer Dabbelt wrote:
>
> On Wed, 11 Nov 2020 02:06:07 PST (-0800), zong...@sifive.com wrote:
> > Add driver code for the SiFive FU740 PRCI IP block. This IP block
> > handles reset and clock control for the SiFive FU740 device and
> > implements SoC-level clock tree controls and dividers.
> >
> > This driver contains bug fixes and contributions from
> > Henry Styles
> > Erik Danie
> > Pragnesh Patel
> >
> > Signed-off-by: Zong Li
> > Reviewed-by: Pragnesh Patel
> > Cc: Henry Styles
> > Cc: Erik Danie
> > Cc: Pragnesh Patel
> > ---
> > drivers/clk/sifive/Kconfig| 4 +-
> > drivers/clk/sifive/Makefile | 1 +
> > drivers/clk/sifive/fu740-prci.c | 122 ++
> > drivers/clk/sifive/fu740-prci.h | 21 +++
> > drivers/clk/sifive/sifive-prci.c | 120 +
> > drivers/clk/sifive/sifive-prci.h | 88 +
> > include/dt-bindings/clock/sifive-fu740-prci.h | 23
>
> I don't see the bindings in Documentation, but assuming they're in flight
Yash is working on some DT bindings, but he suggests that I could
integrate PRCI's binding in this patch set, and rename the prci
binding file, so I would add the binding in the next version.
>
> Acked-by: Palmer Dabbelt
>
> Thanks!
>
> > 7 files changed, 377 insertions(+), 2 deletions(-)
> > create mode 100644 drivers/clk/sifive/fu740-prci.c
> > create mode 100644 drivers/clk/sifive/fu740-prci.h
> > create mode 100644 include/dt-bindings/clock/sifive-fu740-prci.h
> >
> > diff --git a/drivers/clk/sifive/Kconfig b/drivers/clk/sifive/Kconfig
> > index ab48cf7e0105..1c14eb20c066 100644
> > --- a/drivers/clk/sifive/Kconfig
> > +++ b/drivers/clk/sifive/Kconfig
> > @@ -13,7 +13,7 @@ config CLK_SIFIVE_PRCI
> > select CLK_ANALOGBITS_WRPLL_CLN28HPC
> > help
> > Supports the Power Reset Clock interface (PRCI) IP block found in
> > - FU540 SoCs. If this kernel is meant to run on a SiFive FU540 SoC,
> > - enable this driver.
> > + FU540/FU740 SoCs. If this kernel is meant to run on a SiFive FU540/
> > + FU740 SoCs, enable this driver.
> >
> > endif
> > diff --git a/drivers/clk/sifive/Makefile b/drivers/clk/sifive/Makefile
> > index fe3e2cb4c4d8..2c05798e4ba4 100644
> > --- a/drivers/clk/sifive/Makefile
> > +++ b/drivers/clk/sifive/Makefile
> > @@ -2,3 +2,4 @@
> > obj-y += sifive-prci.o
> >
> > obj-$(CONFIG_CLK_SIFIVE_PRCI)+= fu540-prci.o
> > +obj-$(CONFIG_CLK_SIFIVE_PRCI)+= fu740-prci.o
> > diff --git a/drivers/clk/sifive/fu740-prci.c
> > b/drivers/clk/sifive/fu740-prci.c
> > new file mode 100644
> > index ..3b87e273c3eb
> > --- /dev/null
> > +++ b/drivers/clk/sifive/fu740-prci.c
> > @@ -0,0 +1,122 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (C) 2018-2019 SiFive, Inc.
> > + * Wesley Terpstra
> > + * Paul Walmsley
> > + * Zong Li
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > + * GNU General Public License for more details.
> > + */
> > +
> > +#include
> > +#include
> > +#include "sifive-prci.h"
> > +
> > +/* PRCI integration data for each WRPLL instance */
> > +
> > +static struct __prci_wrpll_data __prci_corepll_data = {
> > + .cfg0_offs = PRCI_COREPLLCFG0_OFFSET,
> > + .enable_bypass = sifive_prci_coreclksel_use_hfclk,
> > + .disable_bypass = sifive_prci_coreclksel_use_final_corepll,
> > +};
> > +
> > +static struct __prci_wrpll_data __prci_ddrpll_data = {
> > + .cfg0_offs = PRCI_DDRPLLCFG0_OFFSET,
> > +};
> > +
> > +static struct __prci_wrpll_data __prci_gemgxlpll_data = {
> > + .cfg0_offs = PRCI_GEMGXLPLLCFG0_OFFSET,
> > +};
> > +
> > +static struct __prci_wrpll_data __prci_dvfscorepll_data = {
> > + .cfg0_offs = PRCI_DVFSCOREPLLCFG0_OFFSET,
> > + .enable_bypass = sifive_prci_corepllsel_use_corepll,
> > + .disable_bypass = sifive_prci_corepllsel_use_dvfscorepll,
> > +};
> > +
> > +static struct __prci_wrpll_data __prci_hfpclkpll_data = {
> > + .cfg0_offs = PRCI_HFPCLKPLLCFG0_OFFSET,
> > + .enable_bypass = sifive_prci_hfpclkpllsel_use_hfclk,
> > + .disable_bypass = sifive_prci_hfpclkpllsel_use_hfpclkpll,
> > +};
> > +
> > +static struct __prci_wrpll_data __prci_cltxpll_data = {
> > + .cfg0_offs = PRCI_CLTXPLLCFG0_OFFSET,
> > +};
> > +
> > +/* Linux clock framework integration */
> > +
> > +static const struct clk_ops sifive_fu740_prci_wrpll_clk_ops = {
> > + .set_rate = sifive_prci_wrpll_set_rate,
> > + .round_rate = sifive_prci_wrpll_round_rate,
> > + .recalc_rate
Re: [PATCH] Documentation: Chinese translation of Documentation/arm64/elf_hwcaps.rst
在 2020/11/21 下午6:23, Bailu Lin 写道:
> This is a Chinese translated version of
> Documentation/arm64/elf_hwcaps.rst
>
> Signed-off-by: Bailu Lin
> ---
> Documentation/arm64/elf_hwcaps.rst| 2 +
> .../translations/zh_CN/arm64/elf_hwcaps.rst | 240 ++
> .../translations/zh_CN/arm64/index.rst| 1 +
> 3 files changed, 243 insertions(+)
> create mode 100644 Documentation/translations/zh_CN/arm64/elf_hwcaps.rst
>
> diff --git a/Documentation/arm64/elf_hwcaps.rst
> b/Documentation/arm64/elf_hwcaps.rst
> index bbd9cf54db6c..87821662eeb2 100644
> --- a/Documentation/arm64/elf_hwcaps.rst
> +++ b/Documentation/arm64/elf_hwcaps.rst
> @@ -1,3 +1,5 @@
> +.. _elf_hwcaps_index:
> +
>
> ARM64 ELF hwcaps
>
> diff --git a/Documentation/translations/zh_CN/arm64/elf_hwcaps.rst
> b/Documentation/translations/zh_CN/arm64/elf_hwcaps.rst
> new file mode 100644
> index ..c7e4385ee63f
> --- /dev/null
> +++ b/Documentation/translations/zh_CN/arm64/elf_hwcaps.rst
> @@ -0,0 +1,240 @@
> +.. include:: ../disclaimer-zh_CN.rst
> +
> +:Original: :ref:`Documentation/arm64/elf_hwcaps.rst `
> +
> +Translator: Bailu Lin
> +
> +
> +ARM64 ELF hwcaps
> +
> +
> +这篇文档描述了 arm64 ELF hwcaps 的使用方法和规范。
is it better to use 语义 for "semantics'? and 用法 is enough for usages.
> +
> +
> +1. 简介
> +---
> +
> +有些硬件或软件功能仅在某些 CPU 实现上和/或在具体某个内核配置上可用，但
> +对于处于 EL0 的用户空间代码没有可用的架构发现机制。内核通过在辅助向量表
> +公开一组称为 hwcaps 的标志而把这些功能开放给用户空间。
expose, means 暴露 or 揭示， not '开放'，
> +
> +用户空间软件可以通过获取辅助向量的 AT_HWCAP 或 AT_HWCAP2 条目来测试功能，
> +并测试是否设置了相关标志，例如::
> +
> + bool floating_point_is_present(void)
> + {
> + unsigned long hwcaps = getauxval(AT_HWCAP);
> + if (hwcaps & HWCAP_FP)
> + return true;
> +
> + return false;
> + }
> +
> +如果软件依赖于 hwcap 描述的功能，在尝试使用该功能前则应检查相关的 hwcap
> +标志以验证该功能是否存在。
> +
> +不能通过其他方式探查这些功能。当一个功能不可用时，尝试使用它可能导致不可
> +预测的行为，并且无法保证能确切的知道该功能不可用，例如 SIGILL。
> +
> +
> +2. Hwcaps 的说明
> +
> +
> +大多数 hwcaps 旨在说明通过架构 ID 寄存器(处于 EL0 的用户空间代码无法访问)
> +描述的功能的存在。这些 hwcap 通过 ID 寄存器字段定义，并且应根据 ARM 体系
> +结构参考手册（ARM ARM）中定义的字段来解释说明。
> +
> +这些 hwcaps 以下面的形式描述::
> +
> +Functionality implied by idreg.field == val.
Why this line isn't aligned with next section all detailed explanation?
Do we need to translate or keep Enghlish version for all of them?
> +
> +当 idreg.field 中有 val 时，hwcaps 表示 ARM ARM 定义的功能是有效的，但是
> +并不是说要完全和 val 相等，也不是说 idreg.field 描述的其他功能就是缺失的。
> +
> +其他 hwcaps 可能表明无法仅由 ID 寄存器描述的功能的存在。这些 hwcaps 可能
> +没有被 ID 寄存器描述，需要参考其他文档。
> +
> +
> +3. AT_HWCAP 中公开的 hwcaps
it should be 揭示 not 公开
> +---
> +
> +HWCAP_FP
> +ID_AA64PFR0_EL1.FP == 0b 表示的功能。
ID_AA64PFR0_EL1.FP == 0b 表示有此功能。Is this better?
Thanks
Alex
> +
> +HWCAP_ASIMD
> +ID_AA64PFR0_EL1.AdvSIMD == 0b 表示的功能。
> +
> +HWCAP_EVTSTRM
> +通用计时器频率配置为大约100KHz以生成事件。
> +
> +HWCAP_AES
> +ID_AA64ISAR0_EL1.AES == 0b0001 表示的功能。
> +
> +HWCAP_PMULL
> +ID_AA64ISAR0_EL1.AES == 0b0010 表示的功能。
> +
> +HWCAP_SHA1
> +ID_AA64ISAR0_EL1.SHA1 == 0b0001 表示的功能。
> +
> +HWCAP_SHA2
> +ID_AA64ISAR0_EL1.SHA2 == 0b0001 表示的功能。
> +
> +HWCAP_CRC32
> +ID_AA64ISAR0_EL1.CRC32 == 0b0001 表示的功能。
> +
> +HWCAP_ATOMICS
> +ID_AA64ISAR0_EL1.Atomic == 0b0010 表示的功能。
> +
> +HWCAP_FPHP
> +ID_AA64PFR0_EL1.FP == 0b0001 表示的功能。
> +
> +HWCAP_ASIMDHP
> +ID_AA64PFR0_EL1.AdvSIMD == 0b0001 表示的功能。
> +
> +HWCAP_CPUID
> +根据 Documentation/arm64/cpu-feature-registers.rst 描述，EL0 可以访问
> +某些 ID 寄存器。
> +
> +这些 ID 寄存器可能表示功能的可用性。
> +
> +HWCAP_ASIMDRDM
> +ID_AA64ISAR0_EL1.RDM == 0b0001 表示的功能。
> +
> +HWCAP_JSCVT
> +ID_AA64ISAR1_EL1.JSCVT == 0b0001 表示的功能。
> +
> +HWCAP_FCMA
> +ID_AA64ISAR1_EL1.FCMA == 0b0001 表示的功能。
> +
> +HWCAP_LRCPC
> +ID_AA64ISAR1_EL1.LRCPC == 0b0001 表示的功能。
> +
> +HWCAP_DCPOP
> +ID_AA64ISAR1_EL1.DPB == 0b0001 表示的功能。
> +
> +HWCAP_SHA3
> +ID_AA64ISAR0_EL1.SHA3 == 0b0001 表示的功能。
> +
> +HWCAP_SM3
> +ID_AA64ISAR0_EL1.SM3 == 0b0001 表示的功能。
> +
> +HWCAP_SM4
> +ID_AA64ISAR0_EL1.SM4 == 0b0001 表示的功能。
> +
> +HWCAP_ASIMDDP
> +ID_AA64ISAR0_EL1.DP == 0b0001 表示的功能。
> +
> +HWCAP_SHA512
> +ID_AA64ISAR0_EL1.SHA2 == 0b0010 表示的功能。
> +
> +HWCAP_SVE
> +ID_AA64PFR0_EL1.SVE == 0b0001 表示的功能。
> +
> +HWCAP_ASIMDFHM
> +ID_AA64ISAR0_EL1.FHM == 0b0001 表示的功能。
> +
> +HWCAP_DIT
> +ID_AA64PFR0_EL1.DIT == 0b0001 表示的功能。
> +
> +HWCAP_USCAT
> +ID_AA64MMFR2_EL1.AT == 0b0001 表示的功能。
> +
> +HWCAP_ILRCPC
> +ID_AA64ISAR1_EL1.LRCPC == 0b0010 表示的功能。
> +
> +HWCAP_FLAGM
> +ID_AA64ISAR0_EL1.TS == 0b0001 表示的功能。
> +
> +HWCAP_SSBS
> +ID_AA64PFR1_EL1.SSBS == 0b0010 表示的功能。
> +
> +HWCAP_SB
> +ID_AA64ISAR1_EL1.SB == 0b0001 表示的功能。
> +
> +HWCAP_PACA
> +如 Documentation/arm64/pointer-authentication.rst 所描述，
> +ID_AA64ISAR1_EL1.APA == 0b0001 或 ID_AA64ISAR1_EL1.API == 0b0001
> +表示的功能。
> +
> +HWCAP_PACG
> +如
Re: [PATCH v4 3/4] clk: sifive: Add a driver for the SiFive FU740 PRCI IP block
On Sat, Nov 21, 2020 at 9:29 AM Palmer Dabbelt wrote:
>
> On Wed, 11 Nov 2020 02:06:07 PST (-0800), zong...@sifive.com wrote:
> > Add driver code for the SiFive FU740 PRCI IP block. This IP block
> > handles reset and clock control for the SiFive FU740 device and
> > implements SoC-level clock tree controls and dividers.
> >
> > This driver contains bug fixes and contributions from
> > Henry Styles
> > Erik Danie
> > Pragnesh Patel
>
> Is there a datasheet for this chip? It's geneally best to link to one, in
> case
> someone needs to sort out issues in the future.
>
We have a product brief as follow in public now, I would add the link
of it in the next version patch. Thanks.
https://sifive.cdn.prismic.io/sifive/c05b8ddd-e043-45a6-8a29-2a137090236f_HiFive+Unmatched+Product+Brief+%28released%29.pdf
> >
> > Signed-off-by: Zong Li
> > Reviewed-by: Pragnesh Patel
> > Cc: Henry Styles
> > Cc: Erik Danie
> > Cc: Pragnesh Patel
> > ---
> > drivers/clk/sifive/Kconfig| 4 +-
> > drivers/clk/sifive/Makefile | 1 +
> > drivers/clk/sifive/fu740-prci.c | 122 ++
> > drivers/clk/sifive/fu740-prci.h | 21 +++
> > drivers/clk/sifive/sifive-prci.c | 120 +
> > drivers/clk/sifive/sifive-prci.h | 88 +
> > include/dt-bindings/clock/sifive-fu740-prci.h | 23
> > 7 files changed, 377 insertions(+), 2 deletions(-)
> > create mode 100644 drivers/clk/sifive/fu740-prci.c
> > create mode 100644 drivers/clk/sifive/fu740-prci.h
> > create mode 100644 include/dt-bindings/clock/sifive-fu740-prci.h
> >
> > diff --git a/drivers/clk/sifive/Kconfig b/drivers/clk/sifive/Kconfig
> > index ab48cf7e0105..1c14eb20c066 100644
> > --- a/drivers/clk/sifive/Kconfig
> > +++ b/drivers/clk/sifive/Kconfig
> > @@ -13,7 +13,7 @@ config CLK_SIFIVE_PRCI
> > select CLK_ANALOGBITS_WRPLL_CLN28HPC
> > help
> > Supports the Power Reset Clock interface (PRCI) IP block found in
> > - FU540 SoCs. If this kernel is meant to run on a SiFive FU540 SoC,
> > - enable this driver.
> > + FU540/FU740 SoCs. If this kernel is meant to run on a SiFive FU540/
> > + FU740 SoCs, enable this driver.
> >
> > endif
> > diff --git a/drivers/clk/sifive/Makefile b/drivers/clk/sifive/Makefile
> > index fe3e2cb4c4d8..2c05798e4ba4 100644
> > --- a/drivers/clk/sifive/Makefile
> > +++ b/drivers/clk/sifive/Makefile
> > @@ -2,3 +2,4 @@
> > obj-y += sifive-prci.o
> >
> > obj-$(CONFIG_CLK_SIFIVE_PRCI)+= fu540-prci.o
> > +obj-$(CONFIG_CLK_SIFIVE_PRCI)+= fu740-prci.o
> > diff --git a/drivers/clk/sifive/fu740-prci.c
> > b/drivers/clk/sifive/fu740-prci.c
> > new file mode 100644
> > index ..3b87e273c3eb
> > --- /dev/null
> > +++ b/drivers/clk/sifive/fu740-prci.c
> > @@ -0,0 +1,122 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (C) 2018-2019 SiFive, Inc.
> > + * Wesley Terpstra
> > + * Paul Walmsley
> > + * Zong Li
>
> Presumably it's copyright 2020 as well, as that's the current year? Also,
> IIUC
> the copyright lines should be independent from each other. In other words,
> rather than
>
>
>C ... 2020 SiFive
>Zong
>
> this should be
>
>C ... 2020 SiFive
>C ... 2020 Zong
>
> and the rest of this should be dropped in favor of the SPDX.
Ok, many thanks for correcting that, I would modify it in the next
version patch.
>
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > + * GNU General Public License for more details.
> > + */
> > +
> > +#include
> > +#include
> > +#include "sifive-prci.h"
> > +
> > +/* PRCI integration data for each WRPLL instance */
> > +
> > +static struct __prci_wrpll_data __prci_corepll_data = {
> > + .cfg0_offs = PRCI_COREPLLCFG0_OFFSET,
> > + .enable_bypass = sifive_prci_coreclksel_use_hfclk,
> > + .disable_bypass = sifive_prci_coreclksel_use_final_corepll,
> > +};
> > +
> > +static struct __prci_wrpll_data __prci_ddrpll_data = {
> > + .cfg0_offs = PRCI_DDRPLLCFG0_OFFSET,
> > +};
> > +
> > +static struct __prci_wrpll_data __prci_gemgxlpll_data = {
> > + .cfg0_offs = PRCI_GEMGXLPLLCFG0_OFFSET,
> > +};
> > +
> > +static struct __prci_wrpll_data __prci_dvfscorepll_data = {
> > + .cfg0_offs = PRCI_DVFSCOREPLLCFG0_OFFSET,
> > + .enable_bypass = sifive_prci_corepllsel_use_corepll,
> > + .disable_bypass = sifive_prci_corepllsel_use_dvfscorepll,
> > +};
> > +
> > +static struct __prci_wrpll_data __prci_hfpclkpll_data = {
> > + .cfg0_offs = PRCI_HFPCLKPLLCFG0_OFFSET,
> > + .enable_bypass =
Re: linux-next: build warning after merge of the tip tree
Hi Balbir, On Tue, 17 Nov 2020 16:21:31 +1100 Balbir Singh wrote: > > I am testing a fix by pointing the ref to a label, will send it out > (hopefully soon), seems to work at my end. Fixes the warning here as well, thanks. -- Cheers, Stephen Rothwell pgpDlpETEsg3r.pgp Description: OpenPGP digital signature
Re: [PATCH v3 2/3] media: rockchip: Introduce driver for Rockhip's camera interface
Hi Ezequiel, and thanks a lot for the review !
On Fri, 2 Oct 2020 14:35:28 -0300
Ezequiel Garcia wrote:
> Hi Maxime,
>
>Thanks to Dafna, I found the patch ^_^
>
>The driver looks real good. Just a few comments below.
>
>Is the driver passing latest v4l2-compliance tests?
I'll post them along with the next iteration of the series.
>> +config VIDEO_ROCKCHIP_VIP
>> + tristate "Rockchip VIP (Video InPut) Camera Interface"
>> + depends on VIDEO_DEV && VIDEO_V4L2
>> + depends on ARCH_ROCKCHIP || COMPILE_TEST
>> + select VIDEOBUF2_DMA_SG
>> + select VIDEOBUF2_DMA_CONTIG
>> + select V4L2_FWNODE
>> + select V4L2_MEM2MEM_DEV
>> + help
>> + This is a v4l2 driver for Rockchip SOC Camera interface.
>> +
>> + To compile this driver as a module choose m here.
>> +
>
>Please add ... "the module will be called {the name}".
Sure, I will do !
[...]
>> +#define VIP_REQ_BUFS_MIN 1
>
>I think you might want to have more than 1 buffer
>as minimum. How about 3? Two for the ping and pong,
>and one more in the queue.
Yes you're correct, 3 should be the strict minimum required buffers
here, I didn't update that after adding the dual-buffering mode.
>> +#define VIP_MIN_WIDTH 64
>> +#define VIP_MIN_HEIGHT 64
>> +#define VIP_MAX_WIDTH 8192
>> +#define VIP_MAX_HEIGHT 8192
>> +
>> +#define RK_VIP_PLANE_Y 0
>> +#define RK_VIP_PLANE_CBCR 1
>> +
>> +#define VIP_FETCH_Y_LAST_LINE(VAL) ((VAL) & 0x1fff)
>> +/* Check if swap y and c in bt1120 mode */
>> +#define VIP_FETCH_IS_Y_FIRST(VAL) ((VAL) & 0xf)
>> +
>> +/* Get xsubs and ysubs for fourcc formats
>> + *
>> + * @xsubs: horizontal color samples in a 4*4 matrix, for yuv
>> + * @ysubs: vertical color samples in a 4*4 matrix, for yuv
>> + */
>> +static int fcc_xysubs(u32 fcc, u32 *xsubs, u32 *ysubs)
>
>See below, you should be using v4l2_fill_pixfmt_mp.
>
>> +{
>> + switch (fcc) {
>> + case V4L2_PIX_FMT_NV16:
>> + case V4L2_PIX_FMT_NV61:
>> + *xsubs = 2;
>> + *ysubs = 1;
>> + break;
>> + case V4L2_PIX_FMT_NV21:
>> + case V4L2_PIX_FMT_NV12:
>> + *xsubs = 2;
>> + *ysubs = 2;
>> + break;
>> + default:
>> + return -EINVAL;
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +static const struct vip_output_fmt out_fmts[] = {
>> + {
>> + .fourcc = V4L2_PIX_FMT_NV16,
>> + .cplanes = 2,
>
>From what I can see, you are only using this
>information to calculate bytesperline and sizeimage,
>so you should be using the v4l2_fill_pixfmt_mp() helper.
You're correct, it indeed makes things much easier and allowed to
removed a lot of redundant info here !
>> +static void rk_vip_set_fmt(struct rk_vip_stream *stream,
>> + struct v4l2_pix_format_mplane *pixm,
>> + bool try)
>> +{
>> + struct rk_vip_device *dev = stream->vipdev;
>> + struct v4l2_subdev_format sd_fmt;
>> + const struct vip_output_fmt *fmt;
>> + struct v4l2_rect input_rect;
>> + unsigned int planes, imagesize = 0;
>> + u32 xsubs = 1, ysubs = 1;
>> + int i;
>> +
>
>I was expecting to see some is_busy or is_streaming check
>here, have you tested what happens if you change the format
>while streaming, or after buffers are queued?
Yes correct. I used the stream->state private flag here, but I it was
also brought to my attention that there also exists a vb2_is_busy()
helper, but I'm unsure if it would be correct to use it here.
>> +
>> +static int rk_vip_g_input(struct file *file, void *fh, unsigned int *i)
>> +{
>> + *i = 0;
>> + return 0;
>> +}
>> +
>> +static int rk_vip_s_input(struct file *file, void *fh, unsigned int i)
>> +{
>
>Only one input, why do you need to support this ioctl at all?
I actually saw a fair amount of existing drivers implementing these
callbacks even for only one input, so I don't really know if I should
remove it or not ?
[...]
>> +
>> +static void rk_vip_vb_done(struct rk_vip_stream *stream,
>> + struct vb2_v4l2_buffer *vb_done)
>> +{
>> + vb2_set_plane_payload(_done->vb2_buf, 0,
>> + stream->pixm.plane_fmt[0].sizeimage);
>> + vb_done->vb2_buf.timestamp = ktime_get_ns();
>
>vb_done->vb2_buf.sequence = stream->frame_idx; ?
Good catch, thanks !
>> + vb2_buffer_done(_done->vb2_buf, VB2_BUF_STATE_DONE);
>> +}
>> +
[...]
>> diff --git a/drivers/media/platform/rockchip/vip/dev.c
>> b/drivers/media/platform/rockchip/vip/dev.c
>> new file mode 100644
>> index ..d9b64f088c37
>> --- /dev/null
>> +++ b/drivers/media/platform/rockchip/vip/dev.c
>> @@ -0,0 +1,408 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Rockchip VIP Camera Interface Driver
>> + *
>> + * Copyright (C) 2018 Rockchip Electronics Co., Ltd.
>> +
linux-next: build warnings after merge of the tip tree
Hi all,
After merging the tip tree, today's linux-next build (htmldocs) produced
these warnings:
arch/x86/kernel/cpu/sgx/ioctl.c:666: warning: Function parameter or member
'encl' not described in 'sgx_ioc_enclave_provision'
arch/x86/kernel/cpu/sgx/ioctl.c:666: warning: Excess function parameter
'enclave' description in 'sgx_ioc_enclave_provision'
Introduced by commit
c82c61865024 ("x86/sgx: Add SGX_IOC_ENCLAVE_PROVISION")
--
Cheers,
Stephen Rothwell
pgpbmtLeaIMFh.pgp
Description: OpenPGP digital signature
Re: [PATCH v4 4/4] clk: sifive: Fix the wrong bit field shift
On Sat, Nov 21, 2020 at 9:29 AM Palmer Dabbelt wrote: > > On Wed, 11 Nov 2020 02:06:08 PST (-0800), zong...@sifive.com wrote: > > The clk enable bit should be 31 instead of 24. > > > > Signed-off-by: Zong Li > > Reported-by: Pragnesh Patel > > --- > > drivers/clk/sifive/sifive-prci.h | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/clk/sifive/sifive-prci.h > > b/drivers/clk/sifive/sifive-prci.h > > index 802fc8fb9c09..da7be9103d4d 100644 > > --- a/drivers/clk/sifive/sifive-prci.h > > +++ b/drivers/clk/sifive/sifive-prci.h > > @@ -59,7 +59,7 @@ > > > > /* DDRPLLCFG1 */ > > #define PRCI_DDRPLLCFG1_OFFSET 0x10 > > -#define PRCI_DDRPLLCFG1_CKE_SHIFT24 > > +#define PRCI_DDRPLLCFG1_CKE_SHIFT31 > > #define PRCI_DDRPLLCFG1_CKE_MASK (0x1 << PRCI_DDRPLLCFG1_CKE_SHIFT) > > > > /* GEMGXLPLLCFG0 */ > > @@ -81,7 +81,7 @@ > > > > /* GEMGXLPLLCFG1 */ > > #define PRCI_GEMGXLPLLCFG1_OFFSET0x20 > > -#define RCI_GEMGXLPLLCFG1_CKE_SHIFT 24 > > +#define RCI_GEMGXLPLLCFG1_CKE_SHIFT 31 > > #define PRCI_GEMGXLPLLCFG1_CKE_MASK (0x1 << PRCI_GEMGXLPLLCFG1_CKE_SHIFT) > > > > /* CORECLKSEL */ > > Section 7.3 of v1.0 of the FU540 manual says that bit 24 contains the PLL > clock > enable for both of these. I don't know if that's accurate, but if it is then > I > believe this would break the FU540. Don't have one to test on, though. Yes, the manual seems to be wrong and should be corrected. It doesn't break the FU540 yet because we don't use these fields in s-mode Linux driver, we set them in m-mode FSBL/U-boot-SPL bootloader during boot time, and the implementation of FSBL and U-boot-SPL both are correct. The following link is the U-boot SPL source: https://github.com/u-boot/u-boot/blob/da09b99ea572cec9a114872e480b798db11f9c6e/drivers/clk/sifive/fu540-prci.c#L128
Re: [PATCH v4 2/4] clk: sifive: Use common name for prci configuration
On Sat, Nov 21, 2020 at 9:29 AM Palmer Dabbelt wrote: > > On Wed, 11 Nov 2020 02:06:06 PST (-0800), zong...@sifive.com wrote: > > Use generic name CLK_SIFIVE_PRCI instead of CLK_SIFIVE_FU540_PRCI. This > > patch is prepared for fu740 support. > > > > Signed-off-by: Zong Li > > Reviewed-by: Palmer Dabbelt > > Acked-by: Palmer Dabbelt > > Reviewed-by: Pragnesh Patel > > --- > > arch/riscv/Kconfig.socs | 2 +- > > drivers/clk/sifive/Kconfig | 6 +++--- > > drivers/clk/sifive/Makefile | 2 +- > > 3 files changed, 5 insertions(+), 5 deletions(-) > > > > diff --git a/arch/riscv/Kconfig.socs b/arch/riscv/Kconfig.socs > > index 8a55f6156661..3284d5c291be 100644 > > --- a/arch/riscv/Kconfig.socs > > +++ b/arch/riscv/Kconfig.socs > > @@ -5,7 +5,7 @@ config SOC_SIFIVE > > select SERIAL_SIFIVE if TTY > > select SERIAL_SIFIVE_CONSOLE if TTY > > select CLK_SIFIVE > > - select CLK_SIFIVE_FU540_PRCI > > + select CLK_SIFIVE_PRCI > > select SIFIVE_PLIC > > help > > This enables support for SiFive SoC platform hardware. > > diff --git a/drivers/clk/sifive/Kconfig b/drivers/clk/sifive/Kconfig > > index f3b4eb9cb0f5..ab48cf7e0105 100644 > > --- a/drivers/clk/sifive/Kconfig > > +++ b/drivers/clk/sifive/Kconfig > > @@ -8,12 +8,12 @@ menuconfig CLK_SIFIVE > > > > if CLK_SIFIVE > > > > -config CLK_SIFIVE_FU540_PRCI > > - bool "PRCI driver for SiFive FU540 SoCs" > > +config CLK_SIFIVE_PRCI > > + bool "PRCI driver for SiFive SoCs" > > select CLK_ANALOGBITS_WRPLL_CLN28HPC > > help > > Supports the Power Reset Clock interface (PRCI) IP block found in > > - FU540 SoCs. If this kernel is meant to run on a SiFive FU540 SoC, > > + FU540 SoCs. If this kernel is meant to run on a SiFive FU540 SoC, > > This just removes the double-space. Presumably in should also remove the > "FU540", as this clock driver will now function for multiple SiFive SOCs? > I'd like to list the support SoCs here, so in the third patch, I list the FU740 in the description as well. I would remove the SoC names if it is better by using a generic term. What do you think about that? > > enable this driver. > > > > endif > > diff --git a/drivers/clk/sifive/Makefile b/drivers/clk/sifive/Makefile > > index 627effe2ece1..fe3e2cb4c4d8 100644 > > --- a/drivers/clk/sifive/Makefile > > +++ b/drivers/clk/sifive/Makefile > > @@ -1,4 +1,4 @@ > > # SPDX-License-Identifier: GPL-2.0-only > > obj-y += sifive-prci.o > > > > -obj-$(CONFIG_CLK_SIFIVE_FU540_PRCI) += fu540-prci.o > > +obj-$(CONFIG_CLK_SIFIVE_PRCI)+= fu540-prci.o > > Probably best to rename the source file as well. I added fu740-prci.c in the third patch, these two files fu740-prci.c and fu540-prci.c hold the soc-dependent code, and sifive-prci.c is the core of this driver.
[PATCH] spi: dw: fixed missing resource_size
fixed the coccicheck:
drivers/spi/spi-dw-bt1.c:220:27-30: ERROR: Missing
resource_size with mem.
Signed-off-by: Tian Tao
---
drivers/spi/spi-dw-bt1.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/spi/spi-dw-bt1.c b/drivers/spi/spi-dw-bt1.c
index f382dfad..da4f4d8 100644
--- a/drivers/spi/spi-dw-bt1.c
+++ b/drivers/spi/spi-dw-bt1.c
@@ -217,7 +217,7 @@ static int dw_spi_bt1_sys_init(struct platform_device *pdev,
if (mem) {
dwsbt1->map = devm_ioremap_resource(>dev, mem);
if (!IS_ERR(dwsbt1->map)) {
- dwsbt1->map_len = (mem->end - mem->start + 1);
+ dwsbt1->map_len = resource_size(mem);
dws->mem_ops.dirmap_create = dw_spi_bt1_dirmap_create;
dws->mem_ops.dirmap_read = dw_spi_bt1_dirmap_read;
} else {
--
2.7.4
Re: [PATCH 098/141] mmc: sdhci-of-arasan: Fix fall-through warnings for Clang
On 20. 11. 20 19:37, Gustavo A. R. Silva wrote: > In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple > warnings by explicitly adding multiple break statements instead of > letting the code fall through to the next case. > > Link: https://github.com/KSPP/linux/issues/115 > Signed-off-by: Gustavo A. R. Silva > --- > drivers/mmc/host/sdhci-of-arasan.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/drivers/mmc/host/sdhci-of-arasan.c > b/drivers/mmc/host/sdhci-of-arasan.c > index 829ccef87426..1f7e42b6ced5 100644 > --- a/drivers/mmc/host/sdhci-of-arasan.c > +++ b/drivers/mmc/host/sdhci-of-arasan.c > @@ -627,6 +627,7 @@ static int sdhci_zynqmp_sdcardclk_set_phase(struct clk_hw > *hw, int degrees) > case MMC_TIMING_MMC_HS200: > /* For 200MHz clock, 8 Taps are available */ > tap_max = 8; > + break; > default: > break; > } > @@ -695,6 +696,7 @@ static int sdhci_zynqmp_sampleclk_set_phase(struct clk_hw > *hw, int degrees) > case MMC_TIMING_MMC_HS200: > /* For 200MHz clock, 30 Taps are available */ > tap_max = 30; > + break; > default: > break; > } > @@ -760,6 +762,7 @@ static int sdhci_versal_sdcardclk_set_phase(struct clk_hw > *hw, int degrees) > case MMC_TIMING_MMC_HS200: > /* For 200MHz clock, 8 Taps are available */ > tap_max = 8; > + break; > default: > break; > } > @@ -831,6 +834,7 @@ static int sdhci_versal_sampleclk_set_phase(struct clk_hw > *hw, int degrees) > case MMC_TIMING_MMC_HS200: > /* For 200MHz clock, 30 Taps are available */ > tap_max = 30; > + break; > default: > break; > } > No problem with it. Acked-by: Michal Simek Thanks, Michal
Re: [PATCH net-next 2/3] mlxsw: spectrum_ptp: use PTP wide message type definitions
On Sun, Nov 22, 2020 at 04:35:58PM +0200, Ido Schimmel wrote: > Anyway, I added all six patches to our regression as we have some PTP > tests. Will let you know tomorrow. Looks good
Re: [PATCH] firmware: xlnx-zynqmp: fix compilation warning
On 21. 11. 20 8:09, Wendy Liang wrote: > On Fri, Nov 20, 2020 at 10:14:52AM +0100, Michal Simek wrote: >> >> >> On 18. 11. 20 23:31, Wendy Liang wrote: >>> Fix compilation warning when ZYNQMP_FIRMWARE is not defined. >>> >>> include/linux/firmware/xlnx-zynqmp.h: In function >>> 'zynqmp_pm_get_eemi_ops': >>> include/linux/firmware/xlnx-zynqmp.h:363:9: error: implicit >>> declaration of function 'ERR_PTR' >>> [-Werror=implicit-function-declaration] >>> 363 | return ERR_PTR(-ENODEV); >>> >>> include/linux/firmware/xlnx-zynqmp.h:363:18: note: each undeclared >>> identifier is reported only once for each function it appears in >>>include/linux/firmware/xlnx-zynqmp.h: In function >>> 'zynqmp_pm_get_api_version': >>>include/linux/firmware/xlnx-zynqmp.h:367:10: error: 'ENODEV' >>> undeclared (first use in this function) >>> 367 | return -ENODEV; >>> | ^~ >> >> Are these issues caused by your AI driver? >> If not, can you please point me to .config which reports this issue? > It is from testbot, the ZYNQMP_FIMRWARE is not set. > The AI engine driver c file includes the firmware/xlnx-zynqmp.h. The file > doesn't include linux/err.h before including this xlnx-zynqmp.h file. > However, the AI engine driver includes other header which includes > linux/err.h. > > It is good to include the linux/err.h explicitly too in the AI engine > file. But for the firmware/xlnx-zynqmp.h it will be better to include > linux/err.h as it is using it. > >> >>> >>> Signed-off-by: Wendy Liang >>> --- >>> include/linux/firmware/xlnx-zynqmp.h | 4 >>> 1 file changed, 4 insertions(+) >>> >>> diff --git a/include/linux/firmware/xlnx-zynqmp.h >>> b/include/linux/firmware/xlnx-zynqmp.h >>> index 5968df8..7b6f9fc 100644 >>> --- a/include/linux/firmware/xlnx-zynqmp.h >>> +++ b/include/linux/firmware/xlnx-zynqmp.h >>> @@ -13,6 +13,10 @@ >>> #ifndef __FIRMWARE_ZYNQMP_H__ >>> #define __FIRMWARE_ZYNQMP_H__ >>> >>> +#if !IS_REACHABLE(CONFIG_ZYNQMP_FIRMWARE) >> >> I don't think there is a real need to have this ifdef around. >> You can just ignore it and keep just below line. > [Wendy] if ZYNQMP_FIRMWARE is defined, this header doesn't need > linux/err.h shall we only include linux/err.h when it is required? Again I have no problem to include it but please remove that #if/#endif and include it all the time. Thanks, Michal
Re: [PATCH v4 3/4] Input: atmel_mxt_ts - add option to disable firmware loading
Hi Andrej, On Tue, Nov 10, 2020 at 07:15:49PM +0100, Andrej Valek wrote: > Firmware file loadind for mXT336U controller takes too much time (~60s). > There is no check that configuration is the same which is already present. > This happens always during boot, which makes touchscreen unusable. > > Add there an option to prevent firmware file loading, but keep it enabled > by default. Automatically updating firmware and config on driver probe was a mistake, and I am planning on removing the code altogether and expect userspace to determine if flashing is needed and request it explicitly, so this option is not really needed. Thanks. -- Dmitry
Re: [PATCH net-next v4 2/5] net/lapb: support netdev events
On 2020-11-21 00:50, Xie He wrote: On Fri, Nov 20, 2020 at 3:11 PM Xie He wrote: Should we also handle the NETDEV_UP event here? In previous versions of this patch series you seemed to want to establish the L2 connection on device-up. But in this patch, you didn't handle NETDEV_UP. Maybe on device-up, we need to check if the carrier is up, and if it is, we do the same thing as we do on carrier-up. Are the device up/down status and the carrier up/down status independent of each other? If they are, on device-up or carrier-up, we only need to try establishing the L2 connection if we see both are up. No, they aren't independent. The carrier can only be up if the device / interface is UP. And as far as I can see a NETDEV_CHANGE event will also only be generated on interfaces that are UP. So you can be sure, that if there is a NETDEV_CHANGE event then the device is UP. I removed the NETDEV_UP handling because I don't think it makes sense to implicitly try to establish layer2 (LAPB) if there is no carrier. And with the first X.25 connection request on that interface, it will be established anyway by x25_transmit_link(). I've tested it here with an HDLC WAN Adapter and it works as expected. These are also the ideal conditions for the already mentioned "on demand" scenario. The only necessary change would be to call x25_terminate_link() on an interface after clearing the last X.25 session. On NETDEV_GOING_DOWN, we can also check the carrier status first and if it is down, we don't need to call lapb_disconnect_request. This is not necessary because lapb_disconnect_request() checks the current state. And if the carrier is DOWN then the state should also be LAPB_STATE_0 and so lapb_disconnect_request() does nothing.
[RFC PATCH v1 3/4] KVM: arm64: GICv4.1: Restore VLPI's pending state to physical side
From: Zenghui Yu When setting the forwarding path of a VLPI, it is more consistent to also transfer the pending state from irq->pending_latch to VPT (especially in migration, the pending states of VLPIs are restored into kvm’s vgic first). And we currently send "INT+VSYNC" to trigger a VLPI to pending. Signed-off-by: Zenghui Yu Signed-off-by: Shenming Lu --- arch/arm64/kvm/vgic/vgic-v4.c | 12 1 file changed, 12 insertions(+) diff --git a/arch/arm64/kvm/vgic/vgic-v4.c b/arch/arm64/kvm/vgic/vgic-v4.c index b5fa73c9fd35..cc3ab9cea182 100644 --- a/arch/arm64/kvm/vgic/vgic-v4.c +++ b/arch/arm64/kvm/vgic/vgic-v4.c @@ -418,6 +418,18 @@ int kvm_vgic_v4_set_forwarding(struct kvm *kvm, int virq, irq->host_irq = virq; atomic_inc(>vlpi_count); + /* Transfer pending state */ + ret = irq_set_irqchip_state(irq->host_irq, + IRQCHIP_STATE_PENDING, + irq->pending_latch); + WARN_RATELIMIT(ret, "IRQ %d", irq->host_irq); + + /* +* Let it be pruned from ap_list later and don't bother +* the List Register. +*/ + irq->pending_latch = false; + out: mutex_unlock(>its_lock); return ret; -- 2.23.0
[RFC PATCH v1 0/4] KVM: arm64: Add VLPI migration support on GICv4.1
In GICv4.1, migration has been supported except for (directly-injected) VLPI. And GICv4.1 spec explicitly gives a way to get the VLPI's pending state (which was crucially missing in GICv4.0). So we make VLPI migration capable on GICv4.1 in this patch set. In order to support VLPI migration, we need to save and restore all required configuration information and pending states of VLPIs. But in fact, the configuration information of VLPIs has already been saved (or will be reallocated on the dst host...) in vgic(kvm) migration. So we only have to migrate the pending states of VLPIs specially. Below is the related workflow in migration. On the save path: In migration completion: pause all vCPUs | call each VM state change handler: pause other devices (just keep from sending interrupts, and such as VFIO migration protocol has already realized it [1]) | flush ITS tables into guest RAM | flush RDIST pending tables (also flush VLPI state here) | ... On the resume path: load each device's state: restore ITS tables (include pending tables) from guest RAM | for other (PCI) devices (paused), if configured to have VLPIs, establish the forwarding paths of their VLPIs (and transfer the pending states from kvm's vgic to VPT here) Yet TODO: - For some reason, such as for VFIO PCI devices, there may be repeated resettings of HW VLPI configuration in load_state, resulting in the loss of pending state. A very intuitive solution is to retrieve the pending state in unset_forwarding (and this should be so regardless of migration). But at normal run time, this function may be called when all devices are running, in which case the unmapping of VPE is not allowed. It seems to be an almost insoluble bug... There are other possible solutions as follows: 1) avoid unset_forwarding being called from QEMU in resuming (simply allocate all needed vectors first), which is more reasonable and efficient. 2) add a new dedicated interface to transfer these pending states to HW in GIC VM state change handler corresponding to save_pending_tables. ... Any comments and suggestions are very welcome. Besides, we have tested this series in VFIO migration, and nothing else goes wrong (with two issues committed [2][3]). Links: [1] vfio: UAPI for migration interface for device state: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/ commit/?id=a8a24f3f6e38103b77cf399c38eb54e1219d00d6 [2] vfio: Move the saving of the config space to the right place in VFIO migration: https://patchwork.ozlabs.org/patch/1400246/ [3] vfio: Set the priority of VFIO VM state change handler explicitly: https://patchwork.ozlabs.org/patch/1401280/ Shenming Lu (2): KVM: arm64: GICv4.1: Try to save hw pending state in save_pending_tables KVM: arm64: GICv4.1: Give a chance to save VLPI's pending state Zenghui Yu (2): irqchip/gic-v4.1: Plumb get_irqchip_state VLPI callback KVM: arm64: GICv4.1: Restore VLPI's pending state to physical side .../virt/kvm/devices/arm-vgic-its.rst | 2 +- arch/arm64/kvm/vgic/vgic-its.c| 6 +- arch/arm64/kvm/vgic/vgic-v3.c | 62 +-- arch/arm64/kvm/vgic/vgic-v4.c | 12 drivers/irqchip/irq-gic-v3-its.c | 38 5 files changed, 110 insertions(+), 10 deletions(-) -- 2.23.0
[RFC PATCH v1 2/4] KVM: arm64: GICv4.1: Try to save hw pending state in save_pending_tables
After pausing all vCPUs and devices capable of interrupting, in order
to save the information of all interrupts, besides flushing the pending
states in kvm’s vgic, we also try to flush the states of VLPIs in the
virtual pending tables into guest RAM, but we need to have GICv4.1 and
safely unmap the vPEs first.
Signed-off-by: Shenming Lu
---
arch/arm64/kvm/vgic/vgic-v3.c | 62 +++
1 file changed, 56 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/kvm/vgic/vgic-v3.c b/arch/arm64/kvm/vgic/vgic-v3.c
index 9cdf39a94a63..e1b3aa4b2b12 100644
--- a/arch/arm64/kvm/vgic/vgic-v3.c
+++ b/arch/arm64/kvm/vgic/vgic-v3.c
@@ -1,6 +1,8 @@
// SPDX-License-Identifier: GPL-2.0-only
#include
+#include
+#include
#include
#include
#include
@@ -356,6 +358,39 @@ int vgic_v3_lpi_sync_pending_status(struct kvm *kvm,
struct vgic_irq *irq)
return 0;
}
+/*
+ * With GICv4.1, we can get the VLPI's pending state after unmapping
+ * the vPE. The deactivation of the doorbell interrupt will trigger
+ * the unmapping of the associated vPE.
+ */
+static void get_vlpi_state_pre(struct vgic_dist *dist)
+{
+ struct irq_desc *desc;
+ int i;
+
+ if (!kvm_vgic_global_state.has_gicv4_1)
+ return;
+
+ for (i = 0; i < dist->its_vm.nr_vpes; i++) {
+ desc = irq_to_desc(dist->its_vm.vpes[i]->irq);
+ irq_domain_deactivate_irq(irq_desc_get_irq_data(desc));
+ }
+}
+
+static void get_vlpi_state_post(struct vgic_dist *dist)
+{
+ struct irq_desc *desc;
+ int i;
+
+ if (!kvm_vgic_global_state.has_gicv4_1)
+ return;
+
+ for (i = 0; i < dist->its_vm.nr_vpes; i++) {
+ desc = irq_to_desc(dist->its_vm.vpes[i]->irq);
+ irq_domain_activate_irq(irq_desc_get_irq_data(desc), false);
+ }
+}
+
/**
* vgic_v3_save_pending_tables - Save the pending tables into guest RAM
* kvm lock and all vcpu lock must be held
@@ -365,14 +400,17 @@ int vgic_v3_save_pending_tables(struct kvm *kvm)
struct vgic_dist *dist = >arch.vgic;
struct vgic_irq *irq;
gpa_t last_ptr = ~(gpa_t)0;
- int ret;
+ int ret = 0;
u8 val;
+ get_vlpi_state_pre(dist);
+
list_for_each_entry(irq, >lpi_list_head, lpi_list) {
int byte_offset, bit_nr;
struct kvm_vcpu *vcpu;
gpa_t pendbase, ptr;
bool stored;
+ bool is_pending = irq->pending_latch;
vcpu = irq->target_vcpu;
if (!vcpu)
@@ -387,24 +425,36 @@ int vgic_v3_save_pending_tables(struct kvm *kvm)
if (ptr != last_ptr) {
ret = kvm_read_guest_lock(kvm, ptr, , 1);
if (ret)
- return ret;
+ goto out;
last_ptr = ptr;
}
stored = val & (1U << bit_nr);
- if (stored == irq->pending_latch)
+
+ /* also flush hw pending state */
+ if (irq->hw) {
+ WARN_RATELIMIT(irq_get_irqchip_state(irq->host_irq,
+ IRQCHIP_STATE_PENDING,
_pending),
+ "IRQ %d", irq->host_irq);
+ }
+
+ if (stored == is_pending)
continue;
- if (irq->pending_latch)
+ if (is_pending)
val |= 1 << bit_nr;
else
val &= ~(1 << bit_nr);
ret = kvm_write_guest_lock(kvm, ptr, , 1);
if (ret)
- return ret;
+ goto out;
}
- return 0;
+
+out:
+ get_vlpi_state_post(dist);
+
+ return ret;
}
/**
--
2.23.0
[RFC PATCH v1 4/4] KVM: arm64: GICv4.1: Give a chance to save VLPI's pending state
Before GICv4.1, we do not have direct access to the VLPI's pending state. So we simply let it fail early when encountering any VLPI. But now we don't have to return -EACCES directly if on GICv4.1. So let’s change the hard code and give a chance to save the VLPI's pending state (and preserve the interfaces). Signed-off-by: Shenming Lu --- Documentation/virt/kvm/devices/arm-vgic-its.rst | 2 +- arch/arm64/kvm/vgic/vgic-its.c | 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/Documentation/virt/kvm/devices/arm-vgic-its.rst b/Documentation/virt/kvm/devices/arm-vgic-its.rst index 6c304fd2b1b4..d257eddbae29 100644 --- a/Documentation/virt/kvm/devices/arm-vgic-its.rst +++ b/Documentation/virt/kvm/devices/arm-vgic-its.rst @@ -80,7 +80,7 @@ KVM_DEV_ARM_VGIC_GRP_CTRL -EFAULT Invalid guest ram access -EBUSY One or more VCPUS are running -EACCES The virtual ITS is backed by a physical GICv4 ITS, and the -state is not available +state is not available without GICv4.1 === == KVM_DEV_ARM_VGIC_GRP_ITS_REGS diff --git a/arch/arm64/kvm/vgic/vgic-its.c b/arch/arm64/kvm/vgic/vgic-its.c index 40cbaca81333..ec7543a9617c 100644 --- a/arch/arm64/kvm/vgic/vgic-its.c +++ b/arch/arm64/kvm/vgic/vgic-its.c @@ -2218,10 +2218,10 @@ static int vgic_its_save_itt(struct vgic_its *its, struct its_device *device) /* * If an LPI carries the HW bit, this means that this * interrupt is controlled by GICv4, and we do not -* have direct access to that state. Let's simply fail -* the save operation... +* have direct access to that state without GICv4.1. +* Let's simply fail the save operation... */ - if (ite->irq->hw) + if (ite->irq->hw && !kvm_vgic_global_state.has_gicv4_1) return -EACCES; ret = vgic_its_save_ite(its, device, ite, gpa, ite_esz); -- 2.23.0
[RFC PATCH v1 1/4] irqchip/gic-v4.1: Plumb get_irqchip_state VLPI callback
From: Zenghui Yu
Up to now, the irq_get_irqchip_state() callback of its_irq_chip
leaves unimplemented since there is no architectural way to get
the VLPI's pending state before GICv4.1. Yeah, there has one in
v4.1 for VLPIs.
With GICv4.1, after unmapping the vPE, which cleans and invalidates
any caching of the VPT, we can get the VLPI's pending state by
peeking at the VPT. So we implement the irq_get_irqchip_state()
callback of its_irq_chip to do it.
Signed-off-by: Zenghui Yu
Signed-off-by: Shenming Lu
---
drivers/irqchip/irq-gic-v3-its.c | 38
1 file changed, 38 insertions(+)
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 0fec31931e11..287003cacac7 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -1695,6 +1695,43 @@ static void its_irq_compose_msi_msg(struct irq_data *d,
struct msi_msg *msg)
iommu_dma_compose_msi_msg(irq_data_get_msi_desc(d), msg);
}
+static bool its_peek_vpt(struct its_vpe *vpe, irq_hw_number_t hwirq)
+{
+ int mask = hwirq % BITS_PER_BYTE;
+ void *va;
+ u8 *pt;
+
+ va = page_address(vpe->vpt_page);
+ pt = va + hwirq / BITS_PER_BYTE;
+
+ return !!(*pt & (1U << mask));
+}
+
+static int its_irq_get_irqchip_state(struct irq_data *d,
+enum irqchip_irq_state which, bool *val)
+{
+ struct its_device *its_dev = irq_data_get_irq_chip_data(d);
+ struct its_vlpi_map *map = get_vlpi_map(d);
+
+ if (which != IRQCHIP_STATE_PENDING)
+ return -EINVAL;
+
+ /* not intended for physical LPI's pending state */
+ if (!map)
+ return -EINVAL;
+
+ /*
+* In GICv4.1, a VMAPP with {V,Alloc}=={0,1} cleans and invalidates
+* any caching of the VPT associated with the vPEID held in the GIC.
+*/
+ if (!is_v4_1(its_dev->its) || atomic_read(>vpe->vmapp_count))
+ return -EACCES;
+
+ *val = its_peek_vpt(map->vpe, map->vintid);
+
+ return 0;
+}
+
static int its_irq_set_irqchip_state(struct irq_data *d,
enum irqchip_irq_state which,
bool state)
@@ -1975,6 +2012,7 @@ static struct irq_chip its_irq_chip = {
.irq_eoi= irq_chip_eoi_parent,
.irq_set_affinity = its_set_affinity,
.irq_compose_msi_msg= its_irq_compose_msi_msg,
+ .irq_get_irqchip_state = its_irq_get_irqchip_state,
.irq_set_irqchip_state = its_irq_set_irqchip_state,
.irq_retrigger = its_irq_retrigger,
.irq_set_vcpu_affinity = its_irq_set_vcpu_affinity,
--
2.23.0
Re: [PATCH 1/3] Input: goodix - add option to disable firmware loading
On Fri, Oct 30, 2020 at 10:56:20AM +0100, Hans de Goede wrote: > Hi, > > On 10/29/20 9:36 PM, Dmitry Torokhov wrote: > > Hi Andrej, > > > > On Thu, Oct 29, 2020 at 06:03:11PM +0100, Andrej Valek wrote: > >> Firmware file loadind for GT911 controller takes too much time (~60s). > >> There is no check that configuration is the same which is already present. > >> This happens always during boot, which makes touchscreen unusable. > >> > >> Add there an option to prevent firmware file loading, but keep it enabled > >> by default. > > > > I thought that Goodix was losing firmware loading at poweroff. Is this > > not the case with this model? > > So first of all there are 2 sorts of firmware involved with the > Goodix touchscreen controllers, the actual firmware and a block > of config data for that firmware which I presume adjusts it for > the specific (model of) the digitizer which is attached. > > ATM the mainline Linux driver does not support models where > the actual firmware itself needs to be loaded (because they > only have RAM, so they come up without firmware). > > I do have one model tablet with a ROM-less goodix touchpad > controller, so if I ever find the time I might add support > for loading the actual firmware. > > So what we are talking about here is just loading the config > data and I'm a bit surprised that this take so long. So I am still confused about this: is the config stored in RAM or NVRAM? I.e. do we actually need to re-load it every time on boot, or it supposed to be flashed only when it is changed (or lost)? Thanks. -- Dmitry
Re: [PATCH V5 2/2] mailbox: arm_mhuv2: Add driver
On 20-11-20, 13:06, Jassi Brar wrote:
> On Tue, Nov 17, 2020 at 4:02 AM Viresh Kumar wrote:
>
> > +
> > +/**
> > + * struct mhuv2 - MHUv2 mailbox controller data
> > + *
> > + * @mbox: Mailbox controller belonging to the MHU frame.
> > + * @send/recv: Base address of the register mapping region.
> > + * @frame: Frame type: RECEIVER_FRAME or SENDER_FRAME.
> > + * @irq: Interrupt.
> > + * @windows: Channel windows implemented by the platform.
> > + * @minor: Minor version of the controller.
> > + * @length:Length of the protocols array in bytes.
> > + * @protocols: Raw protocol information, derived from device tree.
> > + * @doorbell_pending_lock: spinlock required for correct operation of Tx
> > + * interrupt for doorbells.
> > + */
> > +struct mhuv2 {
> > + struct mbox_controller mbox;
> > + union {
> > + struct mhu2_send_frame_reg __iomem *send;
> > + struct mhu2_recv_frame_reg __iomem *recv;
> > + };
> > + enum mhuv2_frame frame;
> > + unsigned int irq;
> > + unsigned int windows;
> > + unsigned int minor;
> > + unsigned int length;
> > + u32 *protocols;
> > +
> > + spinlock_t doorbell_pending_lock;
> >
> Can you please explain the need of this lock? Some usecase?
> It should be unnecessary if the controller natively supports doorbell mode.
Yes, the controller does have native doorbell support, it provides bit
wise access of the registers and interrupt gets generated for every
bit of the register.
This lock is needed only in the case where an interrupt is provided in
the tx case as well (since minor version 1). This is how hardware
works in this case:
- Sender (Linux) writes to a bit of 'stat_set' register to do a
doorbell operation.
- The receiver receives an interrupt for it and sets the same bit in
'stat_clear' register in order to clear the interrupt.
- With this the sender gets an interrupt and needs to check which bit
of 'stat' register went from 1 to 0 to know which doorbell's
operation got finished. The sender clears the interrupt for the
entire window by writing 1 to int_clr register of the corresponding
window.
Now another doorbell transfer can start right after we read the 'stat'
register in the tx interrupt handler and we will see that a bit went
from 1 to 0 and think that the transfer has completed, while it may
not have as the bit may still be 1. And so we need to make sure to not
start a new transfer for the same window while interrupt handler is
processing the doorbell tx interrupt.
Another way of doing this lockless would be to not use the tx
interrupt and rather poll the bit, but that would be less efficient.
--
viresh
Re: [PATCH v10 11/19] PM / devfreq: tegra20: Deprecate in a favor of emc-stat based driver
On 11/23/20 9:27 AM, Dmitry Osipenko wrote:
> Remove tegra20-devfreq in order to replace it with a EMC_STAT based
> devfreq driver. Previously we were going to use MC_STAT based
> tegra20-devfreq driver because EMC_STAT wasn't working properly, but
> now that problem is resolved. This resolves complications imposed by
> the removed driver since it was depending on both EMC and MC drivers
> simultaneously.
>
> Acked-by: Chanwoo Choi
> Signed-off-by: Dmitry Osipenko
> ---
> MAINTAINERS | 1 -
> drivers/devfreq/Kconfig | 10 --
> drivers/devfreq/Makefile | 1 -
> drivers/devfreq/tegra20-devfreq.c | 210 --
> 4 files changed, 222 deletions(-)
> delete mode 100644 drivers/devfreq/tegra20-devfreq.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 5f10105cac6f..56c560320f00 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -11370,7 +11370,6 @@ L:linux...@vger.kernel.org
> L: linux-te...@vger.kernel.org
> T: git git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux.git
> S: Maintained
> -F: drivers/devfreq/tegra20-devfreq.c
> F: drivers/devfreq/tegra30-devfreq.c
>
> MEMORY MANAGEMENT
> diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
> index 0ee36ae2fa79..00704efe6398 100644
> --- a/drivers/devfreq/Kconfig
> +++ b/drivers/devfreq/Kconfig
> @@ -121,16 +121,6 @@ config ARM_TEGRA_DEVFREQ
> It reads ACTMON counters of memory controllers and adjusts the
> operating frequencies and voltages with OPP support.
>
> -config ARM_TEGRA20_DEVFREQ
> - tristate "NVIDIA Tegra20 DEVFREQ Driver"
> - depends on ARCH_TEGRA_2x_SOC || COMPILE_TEST
> - depends on COMMON_CLK
> - select DEVFREQ_GOV_SIMPLE_ONDEMAND
> - help
> - This adds the DEVFREQ driver for the Tegra20 family of SoCs.
> - It reads Memory Controller counters and adjusts the operating
> - frequencies and voltages with OPP support.
> -
> config ARM_RK3399_DMC_DEVFREQ
> tristate "ARM RK3399 DMC DEVFREQ Driver"
> depends on (ARCH_ROCKCHIP && HAVE_ARM_SMCCC) || \
> diff --git a/drivers/devfreq/Makefile b/drivers/devfreq/Makefile
> index 3ca1ad0ecb97..a16333ea7034 100644
> --- a/drivers/devfreq/Makefile
> +++ b/drivers/devfreq/Makefile
> @@ -13,7 +13,6 @@ obj-$(CONFIG_ARM_IMX_BUS_DEVFREQ) += imx-bus.o
> obj-$(CONFIG_ARM_IMX8M_DDRC_DEVFREQ) += imx8m-ddrc.o
> obj-$(CONFIG_ARM_RK3399_DMC_DEVFREQ) += rk3399_dmc.o
> obj-$(CONFIG_ARM_TEGRA_DEVFREQ) += tegra30-devfreq.o
> -obj-$(CONFIG_ARM_TEGRA20_DEVFREQ)+= tegra20-devfreq.o
>
> # DEVFREQ Event Drivers
> obj-$(CONFIG_PM_DEVFREQ_EVENT) += event/
> diff --git a/drivers/devfreq/tegra20-devfreq.c
> b/drivers/devfreq/tegra20-devfreq.c
> deleted file mode 100644
> index fd801534771d..
> --- a/drivers/devfreq/tegra20-devfreq.c
> +++ /dev/null
> @@ -1,210 +0,0 @@
> -// SPDX-License-Identifier: GPL-2.0
> -/*
> - * NVIDIA Tegra20 devfreq driver
> - *
> - * Copyright (C) 2019 GRATE-DRIVER project
> - */
> -
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -
> -#include
> -
> -#include "governor.h"
> -
> -#define MC_STAT_CONTROL 0x90
> -#define MC_STAT_EMC_CLOCK_LIMIT 0xa0
> -#define MC_STAT_EMC_CLOCKS 0xa4
> -#define MC_STAT_EMC_CONTROL 0xa8
> -#define MC_STAT_EMC_COUNT0xb8
> -
> -#define EMC_GATHER_CLEAR (1 << 8)
> -#define EMC_GATHER_ENABLE(3 << 8)
> -
> -struct tegra_devfreq {
> - struct devfreq *devfreq;
> - struct clk *emc_clock;
> - void __iomem *regs;
> -};
> -
> -static int tegra_devfreq_target(struct device *dev, unsigned long *freq,
> - u32 flags)
> -{
> - struct tegra_devfreq *tegra = dev_get_drvdata(dev);
> - struct devfreq *devfreq = tegra->devfreq;
> - struct dev_pm_opp *opp;
> - unsigned long rate;
> - int err;
> -
> - opp = devfreq_recommended_opp(dev, freq, flags);
> - if (IS_ERR(opp))
> - return PTR_ERR(opp);
> -
> - rate = dev_pm_opp_get_freq(opp);
> - dev_pm_opp_put(opp);
> -
> - err = clk_set_min_rate(tegra->emc_clock, rate);
> - if (err)
> - return err;
> -
> - err = clk_set_rate(tegra->emc_clock, 0);
> - if (err)
> - goto restore_min_rate;
> -
> - return 0;
> -
> -restore_min_rate:
> - clk_set_min_rate(tegra->emc_clock, devfreq->previous_freq);
> -
> - return err;
> -}
> -
> -static int tegra_devfreq_get_dev_status(struct device *dev,
> - struct devfreq_dev_status *stat)
> -{
> - struct tegra_devfreq *tegra = dev_get_drvdata(dev);
> -
> - /*
> - * EMC_COUNT returns number of memory events, that number is lower
> - * than the number of clocks. Conversion ratio of 1/8 results
Re: [PATCH v10 09/19] PM / devfreq: tegra30: Support interconnect and OPPs from device-tree
Hi Dmitry, On 11/23/20 9:27 AM, Dmitry Osipenko wrote: > This patch moves ACTMON driver away from generating OPP table by itself, > transitioning it to use the table which comes from device-tree. This > change breaks compatibility with older device-trees and brings support > for the interconnect framework to the driver. This is a mandatory change > which needs to be done in order to implement interconnect-based memory > DVFS, i.e. device-trees need to be updated. Now ACTMON issues a memory > bandwidth requests using dev_pm_opp_set_bw() instead of driving EMC clock > rate directly. > > Tested-by: Peter Geis > Tested-by: Nicolas Chauvet > Acked-by: Chanwoo Choi > Signed-off-by: Dmitry Osipenko > --- > drivers/devfreq/tegra30-devfreq.c | 79 +++ > 1 file changed, 37 insertions(+), 42 deletions(-) > (snip) When the patches related to icc are merged, I'll merge patch9/10. Thanks for your work. -- Best Regards, Chanwoo Choi Samsung Electronics
Re: About regression caused by commit aea6cb99703e ("regulator: resolve supply after creating regulator")
On 22.11.20 17:35, Michał Mirosław wrote:
> On Sun, Nov 22, 2020 at 03:43:33PM +0100, Jan Kiszka wrote:
>> On 09.11.20 00:28, Qu Wenruo wrote:
>>> On 2020/11/9 上午1:18, Michał Mirosław wrote:
On Sun, Nov 08, 2020 at 03:35:33PM +0800, Qu Wenruo wrote:
> [...]
> It turns out that, commit aea6cb99703e ("regulator: resolve supply after
> creating regulator") seems to be the cause.
> [...]
>> We are still missing some magic fix for stable trees: On the STM32MP15x,
>> things are broken since 5.4.73 now. And 5.9.y is not booting as well on
>> that board. Reverting the original commit make it boot again.
>>
>> Linus master is fine, though, but I'm tired of bisecting. Any
>> suggestions? Or is there something queued up already?
>
> You might want to look at `git log --grep=aea6cb99703e` if you can't
> wait for a stable backport.
>
Good. Is that flagged and tested for 5.9/5.4 (and whatever is also
affected) already?
Jan
--
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux
Re: [PATCH v9 0/5] Exynos: Simple QoS for exynos-bus using interconnect
Hi Sylwester, On 11/12/20 11:09 PM, Sylwester Nawrocki wrote: > > This patchset adds interconnect API support for the Exynos SoC "samsung, > exynos-bus" compatible devices, which already have their corresponding > exynos-bus driver in the devfreq subsystem. Complementing the devfreq > driver with an interconnect functionality allows to ensure the QoS > requirements of devices accessing the system memory (e.g. video processing > devices) are fulfilled and allows to avoid issues like the one discussed > in thread [1]. > > This patch series adds implementation of the interconnect provider per each > "samsung,exynos-bus" compatible DT node, with one interconnect node per > provider. The interconnect code which was previously added as a part of > the devfreq driver has been converted to a separate platform driver. > In the devfreq a corresponding virtual child platform device is registered. > Integration of devfreq and interconnect frameworks is achieved through > the PM QoS API. > > A sample interconnect consumer for exynos-mixer is added in patch 5/5, > it is currently added only for exynos4412 and allows to address the > mixer DMA underrun error issues [1]. > > Changes since v8: > - excluded from the series already applied dts patches, > - Co-developed-by/Signed-off-by tag corrections, Ack tags added, > - the maintainers entry corrections adressing review comments, > - Kconfig/Makefile improvements/corrections, > - whitespace/indentation cleanup. > > The series has been tested on Odroid U3 board. It is based on v5.10-rc1. > > -- > Regards, > Sylwester > > Changes since v7: > - drivers/interconnect/exynos renamed to drivers/interconnect/samsung, > - added INTERCONNECT_SAMSUNG Kconfig symbol, > - added missing driver sync_state callback, > - improved the DT binding description, > - added a patch adding maintainers entry, > - updated comment in patch 7/7, typo fix (patch 1/7). > > Changes since v6: > - the interconnect consumer DT bindings are now used to describe dependencies >of the interconnects (samsung,exynos-bus nodes), > - bus-width property replaced with samsung,data-clk-ratio, > - adaptation to recent changes in the interconnect code >(of_icc_get_from_provider(), icc_node_add()). > > Changes since v5: > - addition of "bus-width: DT property, which specifies data width >of the interconnect bus (patches 1...2/6), > - addition of synchronization of the interconnect bandwidth setting >with VSYNC (patch 6/6). > > Changes since v3 [4] (v4 skipped to align with patchset [1]), detailed > changes are listed in patches: > - conversion to a separate interconnect (platform) driver, > - an update of the DT binding documenting new optional properties: >#interconnect-cells, samsung,interconnect-parent in "samsung,exynos-bus" >nodes, > - new DT properties added to the SoC, rather than to the board specific >files. > > Changes since v2 [5]: > - Use icc_std_aggregate(). > - Implement a different modification of apply_constraints() in >drivers/interconnect/core.c (patch 03). > - Use 'exynos,interconnect-parent-node' in the DT instead of >'devfreq'/'parent', depending on the bus. > - Rebase on DT patches that deprecate the 'devfreq' DT property. > - Improve error handling, including freeing generated IDs on failure. > - Remove exynos_bus_icc_connect() and add exynos_bus_icc_get_parent(). > > Changes since v1 [6]: > - Rebase on coupled regulators patches. > - Use dev_pm_qos_*() API instead of overriding frequency in >exynos_bus_target(). > - Use IDR for node ID allocation. > - Reverse order of multiplication and division in >mixer_set_memory_bandwidth() (patch 07) to avoid integer overflow. > > > References: > [1] https://patchwork.kernel.org/patch/10861757/ (original issue) > [2] > https://protect2.fireeye.com/v1/url?k=0c5b42ec-53c07bee-0c5ac9a3-0cc47a31381a-25eb9fb6f0f852e5=1=3074012f-8e28-49a9-9773-669dbeefe1a6=https%3A%2F%2Fwww.spinics.net%2Flists%2Flinux-samsung-soc%2Fmsg70014.html > [3] > https://protect2.fireeye.com/v1/url?k=f3fdf673-ac66cf71-f3fc7d3c-0cc47a31381a-8ab39522e9fe68a8=1=3074012f-8e28-49a9-9773-669dbeefe1a6=https%3A%2F%2Fwww.spinics.net%2Flists%2Farm-kernel%2Fmsg810722.html > [4] > https://lore.kernel.org/linux-pm/20191220115653.6487-1-a.swi...@samsung.com > [5] https://patchwork.kernel.org/cover/11054417/ (v1 of this RFC) > [6] https://patchwork.kernel.org/cover/11152595/ (v2 of this RFC) > > > Sylwester Nawrocki (5): > dt-bindings: devfreq: Add documentation for the interconnect > properties > interconnect: Add generic interconnect driver for Exynos SoCs > MAINTAINERS: Add entry for Samsung interconnect drivers > PM / devfreq: exynos-bus: Add registration of interconnect child > device > drm: exynos: mixer: Add interconnect support > > .../devicetree/bindings/devfreq/exynos-bus.txt | 71 +++- > MAINTAINERS| 8 + >
Re: [v4,2/3] PCI: mediatek: Add new generation controller support
On Thu, 2020-11-19 at 14:28 -0600, Bjorn Helgaas wrote: > "Add new generation" really contains no information. And "mediatek" > is already used for the pcie-mediatek.c driver, so we should have a > new tag for this new driver. Include useful information in the > subject, e.g., > > PCI: mediatek-gen3: Add MediaTek Gen3 driver for MT8192 > > On Wed, Nov 18, 2020 at 04:29:34PM +0800, Jianjun Wang wrote: > > MediaTek's PCIe host controller has three generation HWs, the new > > generation HW is an individual bridge, it supoorts Gen3 speed and > > up to 256 MSI interrupt numbers for multi-function devices. > > s/supoorts/supports/ > > > Add support for new Gen3 controller which can be found on MT8192. > > > > Signed-off-by: Jianjun Wang > > Acked-by: Ryder Lee > > --- > > drivers/pci/controller/Kconfig | 14 + > > drivers/pci/controller/Makefile |1 + > > drivers/pci/controller/pcie-mediatek-gen3.c | 1031 +++ > > 3 files changed, 1046 insertions(+) > > create mode 100644 drivers/pci/controller/pcie-mediatek-gen3.c > > > > diff --git a/drivers/pci/controller/Kconfig b/drivers/pci/controller/Kconfig > > index f18c3725ef80..83daa772595b 100644 > > --- a/drivers/pci/controller/Kconfig > > +++ b/drivers/pci/controller/Kconfig > > @@ -239,6 +239,20 @@ config PCIE_MEDIATEK > > Say Y here if you want to enable PCIe controller support on > > MediaTek SoCs. > > > > +config PCIE_MEDIATEK_GEN3 > > + tristate "MediaTek GEN3 PCIe controller" > > s/GEN3/Gen3/ > > > + depends on ARCH_MEDIATEK || COMPILE_TEST > > + depends on OF > > Do you really need "depends on OF"? There are stubs to cover most > interfaces even when CONFIG_OF is not set. Depending on OF reduces > compile-test coverage. > > > + depends on PCI_MSI_IRQ_DOMAIN > > + help > > + Adds support for PCIe Gen3 MAC controller for MediaTek SoCs. > > + This PCIe controller provides the capable of Gen3, Gen2 and > > "provides the capable of" doesn't parse. > > > + Gen1 speed, and support up to 256 MSI interrupt numbers for > > + multi-function devices. > > + > > + Say Y here if you want to enable Gen3 PCIe controller support on > > + MediaTek SoCs. > > + > > config PCIE_TANGO_SMP8759 > > bool "Tango SMP8759 PCIe controller (DANGEROUS)" > > depends on ARCH_TANGO && PCI_MSI && OF > > diff --git a/drivers/pci/controller/Makefile > > b/drivers/pci/controller/Makefile > > index bcdbf49ab1e4..9c1b96777597 100644 > > --- a/drivers/pci/controller/Makefile > > +++ b/drivers/pci/controller/Makefile > > @@ -27,6 +27,7 @@ obj-$(CONFIG_PCIE_ROCKCHIP) += pcie-rockchip.o > > obj-$(CONFIG_PCIE_ROCKCHIP_EP) += pcie-rockchip-ep.o > > obj-$(CONFIG_PCIE_ROCKCHIP_HOST) += pcie-rockchip-host.o > > obj-$(CONFIG_PCIE_MEDIATEK) += pcie-mediatek.o > > +obj-$(CONFIG_PCIE_MEDIATEK_GEN3) += pcie-mediatek-gen3.o > > obj-$(CONFIG_PCIE_TANGO_SMP8759) += pcie-tango.o > > obj-$(CONFIG_VMD) += vmd.o > > obj-$(CONFIG_PCIE_BRCMSTB) += pcie-brcmstb.o > > diff --git a/drivers/pci/controller/pcie-mediatek-gen3.c > > b/drivers/pci/controller/pcie-mediatek-gen3.c > > new file mode 100644 > > index ..dd454cfee373 > > --- /dev/null > > +++ b/drivers/pci/controller/pcie-mediatek-gen3.c > > @@ -0,0 +1,1031 @@ > > +// SPDX-License-Identifier: GPL-2.0 > > +/* > > + * MediaTek PCIe host controller driver. > > + * > > + * Copyright (c) 2020 MediaTek Inc. > > + * Author: Jianjun Wang > > + */ > > + > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > + > > +#include "../pci.h" > > + > > +#define PCIE_SETTING_REG 0x80 > > +#define PCIE_PCI_IDS_1 0x9c > > +#define PCI_CLASS(class) (class << 8) > > +#define PCIE_RC_MODE BIT(0) > > + > > +#define PCIE_CFGNUM_REG0x140 > > +#define PCIE_CFG_DEVFN(devfn) ((devfn) & GENMASK(7, 0)) > > +#define PCIE_CFG_BUS(bus) (((bus) << 8) & GENMASK(15, 8)) > > +#define PCIE_CFG_BYTE_EN(bytes)(((bytes) << 16) & GENMASK(19, > > 16)) > > +#define PCIE_CFG_FORCE_BYTE_EN BIT(20) > > +#define PCIE_CFG_OFFSET_ADDR 0x1000 > > +#define PCIE_CFG_HEADER(devfn, bus) \ > > + (PCIE_CFG_DEVFN(devfn) | PCIE_CFG_BUS(bus)) > > This should be: > > (PCIE_CFG_BUS(bus) | PCIE_CFG_DEVFN(devfn)) > > to match the order of the bits in the address you're constructing. > > > +#define PCIE_CFG_HEADER_FORCE_BE(devfn, bus, bytes) \ > > + (PCIE_CFG_HEADER(devfn, bus) | PCIE_CFG_BYTE_EN(bytes) \ > > +| PCIE_CFG_FORCE_BYTE_EN) > > Reorder similarly. > > > +#define PCIE_RST_CTRL_REG 0x148 > > +#define PCIE_MAC_RSTB BIT(0) > > +#define PCIE_PHY_RSTB
[PATCH] Input: omap4-keypad - set up interrupt as wakeup source
Marking main interrupt as wakeup interrupt in probe allows us to drop
custom suspend/resume methods whose only purpose was to configure interrupt
for waking up the system.
Signed-off-by: Dmitry Torokhov
---
drivers/input/keyboard/omap4-keypad.c | 43 +--
1 file changed, 8 insertions(+), 35 deletions(-)
diff --git a/drivers/input/keyboard/omap4-keypad.c
b/drivers/input/keyboard/omap4-keypad.c
index dd16f7b3c7ef..b17ac2a295b9 100644
--- a/drivers/input/keyboard/omap4-keypad.c
+++ b/drivers/input/keyboard/omap4-keypad.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
/* OMAP4 registers */
#define OMAP4_KBD_REVISION 0x00
@@ -69,7 +70,6 @@ struct omap4_keypad {
struct input_dev *input;
void __iomem *base;
- bool irq_wake_enabled;
unsigned int irq;
unsigned int rows;
@@ -376,6 +376,11 @@ static int omap4_keypad_probe(struct platform_device *pdev)
}
device_init_wakeup(>dev, true);
+ error = dev_pm_set_wake_irq(>dev, keypad_data->irq);
+ if (error)
+ dev_warn(>dev,
+"failed to set up wakeup irq: %d\n", error);
+
platform_set_drvdata(pdev, keypad_data);
return 0;
@@ -401,6 +406,8 @@ static int omap4_keypad_remove(struct platform_device *pdev)
struct omap4_keypad *keypad_data = platform_get_drvdata(pdev);
struct resource *res;
+ dev_pm_clear_wake_irq(>dev);
+
free_irq(keypad_data->irq, keypad_data);
pm_runtime_disable(>dev);
@@ -424,45 +431,11 @@ static const struct of_device_id omap_keypad_dt_match[] =
{
};
MODULE_DEVICE_TABLE(of, omap_keypad_dt_match);
-#ifdef CONFIG_PM_SLEEP
-static int omap4_keypad_suspend(struct device *dev)
-{
- struct platform_device *pdev = to_platform_device(dev);
- struct omap4_keypad *keypad_data = platform_get_drvdata(pdev);
- int error;
-
- if (device_may_wakeup(>dev)) {
- error = enable_irq_wake(keypad_data->irq);
- if (!error)
- keypad_data->irq_wake_enabled = true;
- }
-
- return 0;
-}
-
-static int omap4_keypad_resume(struct device *dev)
-{
- struct platform_device *pdev = to_platform_device(dev);
- struct omap4_keypad *keypad_data = platform_get_drvdata(pdev);
-
- if (device_may_wakeup(>dev) && keypad_data->irq_wake_enabled) {
- disable_irq_wake(keypad_data->irq);
- keypad_data->irq_wake_enabled = false;
- }
-
- return 0;
-}
-#endif
-
-static SIMPLE_DEV_PM_OPS(omap4_keypad_pm_ops,
-omap4_keypad_suspend, omap4_keypad_resume);
-
static struct platform_driver omap4_keypad_driver = {
.probe = omap4_keypad_probe,
.remove = omap4_keypad_remove,
.driver = {
.name = "omap4-keypad",
- .pm = _keypad_pm_ops,
.of_match_table = omap_keypad_dt_match,
},
};
--
2.29.2.454.gaff20da3a2-goog
--
Dmitry
[RESEND PATCH v1] proc: use untagged_addr() for pagemap_read addresses
When we try to visit the pagemap of a tagged userspace pointer, we find
that the start_vaddr is not correct because of the tag.
To fix it, we should untag the usespace pointers in pagemap_read().
I tested with 5.10-rc4 and the issue remains.
My test code is baed on [1]:
A userspace pointer which has been tagged by 0xb4: 0xb47662f541c8
=== userspace program ===
uint64 OsLayer::VirtualToPhysical(void *vaddr) {
uint64 frame, paddr, pfnmask, pagemask;
int pagesize = sysconf(_SC_PAGESIZE);
off64_t off = ((uintptr_t)vaddr) / pagesize * 8; // off =
0xb47662f541c8 / pagesize * 8 = 0x5a3b317aa0
int fd = open(kPagemapPath, O_RDONLY);
...
if (lseek64(fd, off, SEEK_SET) != off || read(fd, , 8) != 8) {
int err = errno;
string errtxt = ErrorString(err);
if (fd >= 0)
close(fd);
return 0;
}
...
}
=== kernel fs/proc/task_mmu.c ===
static ssize_t pagemap_read(struct file *file, char __user *buf,
size_t count, loff_t *ppos)
{
...
src = *ppos;
svpfn = src / PM_ENTRY_BYTES; // svpfn == 0xb47662f54
start_vaddr = svpfn << PAGE_SHIFT; // start_vaddr == 0xb47662f54000
end_vaddr = mm->task_size;
/* watch out for wraparound */
// svpfn == 0xb47662f54
// (mm->task_size >> PAGE) == 0x800
if (svpfn > mm->task_size >> PAGE_SHIFT) // the condition is true
because of the tag 0xb4
start_vaddr = end_vaddr;
ret = 0;
while (count && (start_vaddr < end_vaddr)) { // we cannot visit correct
entry because start_vaddr is set to end_vaddr
int len;
unsigned long end;
...
}
...
}
[1] https://github.com/stressapptest/stressapptest/blob/master/src/os.cc#L158
Signed-off-by: Miles Chen
---
fs/proc/task_mmu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index 217aa2705d5d..e9a70f7ee515 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -1599,11 +1599,11 @@ static ssize_t pagemap_read(struct file *file, char
__user *buf,
src = *ppos;
svpfn = src / PM_ENTRY_BYTES;
- start_vaddr = svpfn << PAGE_SHIFT;
+ start_vaddr = untagged_addr(svpfn << PAGE_SHIFT);
end_vaddr = mm->task_size;
/* watch out for wraparound */
- if (svpfn > mm->task_size >> PAGE_SHIFT)
+ if (start_vaddr > mm->task_size)
start_vaddr = end_vaddr;
/*
--
2.18.0
[PATCH] Input: synaptics-rmi4 - remove the useless unsigned variable compared with zero
From: Kaixu Xia It is always true that the value of unsigned variable size_presence_reg greater than or equal to zero, so compared with zero is unnecessary. Remove it. Reported-by: Tosk Robot Signed-off-by: Kaixu Xia --- drivers/input/rmi4/rmi_driver.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/input/rmi4/rmi_driver.c b/drivers/input/rmi4/rmi_driver.c index 258d5fe3d395..e7c9300417e3 100644 --- a/drivers/input/rmi4/rmi_driver.c +++ b/drivers/input/rmi4/rmi_driver.c @@ -580,7 +580,7 @@ int rmi_read_register_desc(struct rmi_device *d, u16 addr, return ret; ++addr; - if (size_presence_reg < 0 || size_presence_reg > 35) + if (size_presence_reg > 35) return -EIO; memset(buf, 0, sizeof(buf)); -- 2.20.0
Re: [PATCH v10 06/19] memory: tegra124: Support interconnect framework
On 23.11.20 2:27, Dmitry Osipenko wrote: Now Internal and External memory controllers are memory interconnection providers. This allows us to use interconnect API for tuning of memory configuration. EMC driver now supports OPPs and DVFS. Tested-by: Nicolas Chauvet Signed-off-by: Dmitry Osipenko Acked-by: Georgi Djakov Thanks, Georgi --- drivers/memory/tegra/Kconfig| 1 + drivers/memory/tegra/tegra124-emc.c | 320 +++- drivers/memory/tegra/tegra124.c | 82 ++- 3 files changed, 391 insertions(+), 12 deletions(-)
Re: [PATCH v10 03/19] memory: tegra30: Support interconnect framework
Hi Dmitry, On 23.11.20 2:27, Dmitry Osipenko wrote: Now Internal and External memory controllers are memory interconnection providers. This allows us to use interconnect API for tuning of memory configuration. EMC driver now supports OPPs and DVFS. MC driver now supports tuning of memory arbitration latency, which needs to be done for ISO memory clients, like a Display client for example. Tested-by: Peter Geis Signed-off-by: Dmitry Osipenko Acked-by: Georgi Djakov Thank you for the continuous work on this patchset! BR, Georgi --- drivers/memory/tegra/Kconfig | 1 + drivers/memory/tegra/tegra30-emc.c | 344 +++-- drivers/memory/tegra/tegra30.c | 173 ++- 3 files changed, 496 insertions(+), 22 deletions(-)
[PATCH v3 3/3] ARM: dts: rainier: Add eMMC clock phase compensation
Determined by scope measurements at speed.
Signed-off-by: Andrew Jeffery
---
arch/arm/boot/dts/aspeed-bmc-ibm-rainier.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/aspeed-bmc-ibm-rainier.dts
b/arch/arm/boot/dts/aspeed-bmc-ibm-rainier.dts
index 21ae880c7530..ab8d37d49f30 100644
--- a/arch/arm/boot/dts/aspeed-bmc-ibm-rainier.dts
+++ b/arch/arm/boot/dts/aspeed-bmc-ibm-rainier.dts
@@ -186,6 +186,7 @@ _emmc_default {
{
status = "okay";
+ clk-phase-mmc-hs200 = <180>, <180>;
};
{
--
2.27.0
[PATCH v3 0/3] mmc: sdhci-of-aspeed: Expose phase delay tuning
Hello, This series implements support for the MMC core clk-phase-* devicetree bindings in the Aspeed SD/eMMC driver. The relevant register was introduced on the AST2600 and is present for both the SD/MMC controller and the dedicated eMMC controller. Previously, v1 and v2 of the series implemented custom bindings. Thanks to Ulf for pointing out that this functionality already existed in the core bindings. For historical reference, v2 can be found here: https://lore.kernel.org/linux-arm-kernel/20200911074452.3148259-1-and...@aj.id.au/ The series has had light testing on an AST2600-based platform which requires 180deg of input and output clock phase correction at HS200, as well as some synthetic testing under qemu. Please review! Cheers, Andrew Andrew Jeffery (3): mmc: sdhci-of-aspeed: Expose phase delay tuning mmc: sdhci-of-aspeed: Add AST2600 bus clock support ARM: dts: rainier: Add eMMC clock phase compensation arch/arm/boot/dts/aspeed-bmc-ibm-rainier.dts | 1 + drivers/mmc/host/sdhci-of-aspeed.c | 310 ++- 2 files changed, 300 insertions(+), 11 deletions(-) -- 2.27.0
[PATCH v3 2/3] mmc: sdhci-of-aspeed: Add AST2600 bus clock support
The AST2600 can achieve HS200 speeds with a change to the bus clock
divisor behaviour. The divisor can also be more accurate with respect
to the requested clock rate, but keep the one-hot behaviour for
backwards compatibility with the AST2400 and AST2500.
Signed-off-by: Andrew Jeffery
---
drivers/mmc/host/sdhci-of-aspeed.c | 37 ++
1 file changed, 33 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/host/sdhci-of-aspeed.c
b/drivers/mmc/host/sdhci-of-aspeed.c
index 9fda2e7c1d78..52179b800e6c 100644
--- a/drivers/mmc/host/sdhci-of-aspeed.c
+++ b/drivers/mmc/host/sdhci-of-aspeed.c
@@ -65,6 +65,7 @@ struct aspeed_sdhci_phase_param {
};
struct aspeed_sdhci_pdata {
+ unsigned int clk_div_start;
const struct aspeed_sdhci_phase_desc *phase_desc;
size_t nr_phase_descs;
};
@@ -207,10 +208,13 @@ static void aspeed_sdhci_set_clock(struct sdhci_host
*host, unsigned int clock)
{
struct sdhci_pltfm_host *pltfm_host;
unsigned long parent, bus;
+ struct aspeed_sdhci *sdhci;
int div;
u16 clk;
pltfm_host = sdhci_priv(host);
+ sdhci = sdhci_pltfm_priv(pltfm_host);
+
parent = clk_get_rate(pltfm_host->clk);
sdhci_writew(host, 0, SDHCI_CLOCK_CONTROL);
@@ -221,7 +225,23 @@ static void aspeed_sdhci_set_clock(struct sdhci_host
*host, unsigned int clock)
if (WARN_ON(clock > host->max_clk))
clock = host->max_clk;
- for (div = 2; div < 256; div *= 2) {
+ /*
+* Regarding the AST2600:
+*
+* If (EMMC12C[7:6], EMMC12C[15:8] == 0) then
+* period of SDCLK = period of SDMCLK.
+*
+* If (EMMC12C[7:6], EMMC12C[15:8] != 0) then
+* period of SDCLK = period of SDMCLK * 2 * (EMMC12C[7:6], EMMC[15:8])
+*
+* If you keep EMMC12C[7:6] = 0 and EMMC12C[15:8] as one-hot,
+* 0x1/0x2/0x4/etc, you will find it is compatible to AST2400 or AST2500
+*
+* Keep the one-hot behaviour for backwards compatibility except for
+* supporting the value 0 in (EMMC12C[7:6], EMMC12C[15:8]), and capture
+* the 0-value capability in clk_div_start.
+*/
+ for (div = sdhci->pdata->clk_div_start; div < 256; div *= 2) {
bus = parent / div;
if (bus <= clock)
break;
@@ -374,6 +394,10 @@ static int aspeed_sdhci_probe(struct platform_device *pdev)
int ret;
aspeed_pdata = of_device_get_match_data(>dev);
+ if (!aspeed_pdata) {
+ dev_err(>dev, "Missing platform configuration data\n");
+ return -EINVAL;
+ }
host = sdhci_pltfm_init(pdev, _sdhci_pdata, sizeof(*dev));
if (IS_ERR(host))
@@ -392,7 +416,7 @@ static int aspeed_sdhci_probe(struct platform_device *pdev)
else if (slot >= 2)
return -EINVAL;
- if (dev->pdata && slot < dev->pdata->nr_phase_descs) {
+ if (slot < dev->pdata->nr_phase_descs) {
dev->phase_desc = >pdata->phase_desc[slot];
} else {
dev_info(>dev,
@@ -455,6 +479,10 @@ static int aspeed_sdhci_remove(struct platform_device
*pdev)
return 0;
}
+static const struct aspeed_sdhci_pdata ast2400_sdhci_pdata = {
+ .clk_div_start = 2,
+};
+
static const struct aspeed_sdhci_phase_desc ast2600_sdhci_phase[] = {
/* SDHCI/Slot 0 */
[0] = {
@@ -485,13 +513,14 @@ static const struct aspeed_sdhci_phase_desc
ast2600_sdhci_phase[] = {
};
static const struct aspeed_sdhci_pdata ast2600_sdhci_pdata = {
+ .clk_div_start = 1,
.phase_desc = ast2600_sdhci_phase,
.nr_phase_descs = ARRAY_SIZE(ast2600_sdhci_phase),
};
static const struct of_device_id aspeed_sdhci_of_match[] = {
- { .compatible = "aspeed,ast2400-sdhci", },
- { .compatible = "aspeed,ast2500-sdhci", },
+ { .compatible = "aspeed,ast2400-sdhci", .data = _sdhci_pdata, },
+ { .compatible = "aspeed,ast2500-sdhci", .data = _sdhci_pdata, },
{ .compatible = "aspeed,ast2600-sdhci", .data = _sdhci_pdata, },
{ }
};
--
2.27.0
[PATCH v3 1/3] mmc: sdhci-of-aspeed: Expose phase delay tuning
The Aspeed SD/eMMC controllers feature up to two SDHCIs alongside a
a set of "global" configuration registers. The global configuration
registers house controller-specific settings that aren't exposed by the
SDHCI, one example being a register for phase tuning.
The phase tuning feature is new in the AST2600 design. It's exposed as a
single register in the global register set and controls both the input
and output phase adjustment for each slot. As the settings are
slot-specific, the values to program are extracted from properties in
the SDHCI devicetree nodes.
Signed-off-by: Andrew Jeffery
---
drivers/mmc/host/sdhci-of-aspeed.c | 275 -
1 file changed, 267 insertions(+), 8 deletions(-)
diff --git a/drivers/mmc/host/sdhci-of-aspeed.c
b/drivers/mmc/host/sdhci-of-aspeed.c
index 4f008ba3280e..9fda2e7c1d78 100644
--- a/drivers/mmc/host/sdhci-of-aspeed.c
+++ b/drivers/mmc/host/sdhci-of-aspeed.c
@@ -6,6 +6,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -16,9 +17,19 @@
#include "sdhci-pltfm.h"
-#define ASPEED_SDC_INFO0x00
-#define ASPEED_SDC_S1MMC8BIT(25)
-#define ASPEED_SDC_S0MMC8BIT(24)
+#define ASPEED_SDC_INFO0x00
+#define ASPEED_SDC_S1_MMC8 BIT(25)
+#define ASPEED_SDC_S0_MMC8 BIT(24)
+#define ASPEED_SDC_PHASE 0xf4
+#define ASPEED_SDC_S1_PHASE_IN GENMASK(25, 21)
+#define ASPEED_SDC_S0_PHASE_IN GENMASK(20, 16)
+#define ASPEED_SDC_S1_PHASE_OUT GENMASK(15, 11)
+#define ASPEED_SDC_S1_PHASE_IN_ENBIT(10)
+#define ASPEED_SDC_S1_PHASE_OUT_EN GENMASK(9, 8)
+#define ASPEED_SDC_S0_PHASE_OUT GENMASK(7, 3)
+#define ASPEED_SDC_S0_PHASE_IN_ENBIT(2)
+#define ASPEED_SDC_S0_PHASE_OUT_EN GENMASK(1, 0)
+#define ASPEED_SDC_PHASE_MAX 31
struct aspeed_sdc {
struct clk *clk;
@@ -28,9 +39,42 @@ struct aspeed_sdc {
void __iomem *regs;
};
+struct aspeed_sdhci_tap_param {
+ bool set;
+
+#define ASPEED_SDHCI_TAP_PARAM_INVERT_CLK BIT(4)
+ u8 in;
+ u8 out;
+};
+
+struct aspeed_sdhci_phase_tap_desc {
+ u32 tap_mask;
+ u32 enable_mask;
+ u8 enable_value;
+};
+
+struct aspeed_sdhci_phase_desc {
+ struct aspeed_sdhci_phase_tap_desc in;
+ struct aspeed_sdhci_phase_tap_desc out;
+};
+
+struct aspeed_sdhci_phase_param {
+ bool set;
+ u8 in_deg;
+ u8 out_deg;
+};
+
+struct aspeed_sdhci_pdata {
+ const struct aspeed_sdhci_phase_desc *phase_desc;
+ size_t nr_phase_descs;
+};
+
struct aspeed_sdhci {
+ const struct aspeed_sdhci_pdata *pdata;
struct aspeed_sdc *parent;
u32 width_mask;
+ const struct aspeed_sdhci_phase_desc *phase_desc;
+ struct aspeed_sdhci_phase_param phase_param[MMC_TIMING_MMC_HS200 + 1];
};
static void aspeed_sdc_configure_8bit_mode(struct aspeed_sdc *sdc,
@@ -50,10 +94,119 @@ static void aspeed_sdc_configure_8bit_mode(struct
aspeed_sdc *sdc,
spin_unlock(>lock);
}
+static u32
+aspeed_sdc_set_phase_tap(const struct aspeed_sdhci_phase_tap_desc *desc,
+u8 tap, bool enable, u32 reg)
+{
+ reg &= ~(desc->enable_mask | desc->tap_mask);
+ if (enable) {
+ reg |= tap << __ffs(desc->tap_mask);
+ reg |= desc->enable_value << __ffs(desc->enable_mask);
+ }
+
+ return reg;
+}
+
+static void
+aspeed_sdc_set_phase_taps(struct aspeed_sdc *sdc,
+ const struct aspeed_sdhci_phase_desc *desc,
+ const struct aspeed_sdhci_tap_param *taps)
+{
+ u32 reg;
+
+ spin_lock(>lock);
+ reg = readl(sdc->regs + ASPEED_SDC_PHASE);
+
+ reg = aspeed_sdc_set_phase_tap(>in, taps->in, taps->set, reg);
+ reg = aspeed_sdc_set_phase_tap(>out, taps->out, taps->set, reg);
+
+ writel(reg, sdc->regs + ASPEED_SDC_PHASE);
+ spin_unlock(>lock);
+}
+
+#define PICOSECONDS_PER_SECOND 1ULL
+#define ASPEED_SDHCI_NR_TAPS 15
+/* Measured value with *handwave* environmentals and static loading */
+#define ASPEED_SDHCI_MAX_TAP_DELAY_PS 1253
+static int aspeed_sdhci_phase_to_tap(struct sdhci_host *host,
+unsigned long rate_hz, int phase_deg)
+{
+ u64 phase_period_ps;
+ struct device *dev;
+ u64 prop_delay_ps;
+ u64 clk_period_ps;
+ unsigned int taps;
+ u8 inverted;
+
+ dev = host->mmc->parent;
+
+ phase_deg %= 360;
+
+ if (phase_deg >= 180) {
+ inverted = ASPEED_SDHCI_TAP_PARAM_INVERT_CLK;
+ phase_deg -= 180;
+ dev_dbg(dev,
+ "Inverting clock to reduce phase correction from %d to
%d degrees\n",
+ phase_deg + 180, phase_deg);
+ } else {
+ inverted = 0;
+ }
+
+ prop_delay_ps = ASPEED_SDHCI_MAX_TAP_DELAY_PS /
[PATCH RESEND v6 4/4] MAINTAINERS: Add ROHM BD9576MUF and BD9573MUF drivers
Add maintainer entries for ROHM BD9576MUF and ROHM BD9573MUF drivers. MFD, regulator and watchdog drivers were introduced for these PMICs. Signed-off-by: Matti Vaittinen --- MAINTAINERS | 4 1 file changed, 4 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index b516bb34a8d5..0bd788a94376 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -15088,16 +15088,20 @@ F:drivers/gpio/gpio-bd71828.c F: drivers/mfd/rohm-bd70528.c F: drivers/mfd/rohm-bd71828.c F: drivers/mfd/rohm-bd718x7.c +F: drivers/mfd/rohm-bd9576.c F: drivers/power/supply/bd70528-charger.c F: drivers/regulator/bd70528-regulator.c F: drivers/regulator/bd71828-regulator.c F: drivers/regulator/bd718x7-regulator.c +F: drivers/regulator/bd9576-regulator.c F: drivers/regulator/rohm-regulator.c F: drivers/rtc/rtc-bd70528.c F: drivers/watchdog/bd70528_wdt.c +F: drivers/watchdog/bd9576_wdt.c F: include/linux/mfd/rohm-bd70528.h F: include/linux/mfd/rohm-bd71828.h F: include/linux/mfd/rohm-bd718x7.h +F: include/linux/mfd/rohm-bd957x.h F: include/linux/mfd/rohm-generic.h F: include/linux/mfd/rohm-shared.h -- 2.25.4 -- Matti Vaittinen, Linux device drivers ROHM Semiconductors, Finland SWDC Kiviharjunlenkki 1E 90220 OULU FINLAND ~~~ "I don't think so," said Rene Descartes. Just then he vanished ~~~ Simon says - in Latin please. ~~~ "non cogito me" dixit Rene Descarte, deinde evanescavit ~~~ Thanks to Simon Glass for the translation =]
[PATCH RESEND v6 3/4] wdt: Support wdt on ROHM BD9576MUF and BD9573MUF
Add Watchdog support for ROHM BD9576MUF and BD9573MUF PMICs which are
mainly used to power the R-Car series processors. The watchdog is
pinged using a GPIO and enabled using another GPIO. Additionally
watchdog time-out can be configured to HW prior starting the watchdog.
Watchdog timeout can be configured to detect only delayed ping or in
a window mode where also too fast pings are detected.
Signed-off-by: Matti Vaittinen
Reviewed-by: Guenter Roeck
---
drivers/watchdog/Kconfig | 13 ++
drivers/watchdog/Makefile | 1 +
drivers/watchdog/bd9576_wdt.c | 291 ++
3 files changed, 305 insertions(+)
create mode 100644 drivers/watchdog/bd9576_wdt.c
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index fd7968635e6d..d5fec1bdf23e 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -172,6 +172,19 @@ config BD70528_WATCHDOG
Alternatively say M to compile the driver as a module,
which will be called bd70528_wdt.
+config BD957XMUF_WATCHDOG
+ tristate "ROHM BD9576MUF and BD9573MUF PMIC Watchdog"
+ depends on MFD_ROHM_BD957XMUF
+ select WATCHDOG_CORE
+ help
+ Support for the watchdog in the ROHM BD9576 and BD9573 PMICs.
+ These PMIC ICs contain watchdog block which can be configured
+ to toggle reset line if SoC fails to ping watchdog via GPIO.
+
+ Say Y here to include support for the ROHM BD9576 or BD9573
+ watchdog. Alternatively say M to compile the driver as a module,
+ which will be called bd9576_wdt.
+
config DA9052_WATCHDOG
tristate "Dialog DA9052 Watchdog"
depends on PMIC_DA9052 || COMPILE_TEST
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 071a2e50be98..54f39883f3ac 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -209,6 +209,7 @@ obj-$(CONFIG_XEN_WDT) += xen_wdt.o
# Architecture Independent
obj-$(CONFIG_BD70528_WATCHDOG) += bd70528_wdt.o
+obj-$(CONFIG_BD957XMUF_WATCHDOG) += bd9576_wdt.o
obj-$(CONFIG_DA9052_WATCHDOG) += da9052_wdt.o
obj-$(CONFIG_DA9055_WATCHDOG) += da9055_wdt.o
obj-$(CONFIG_DA9062_WATCHDOG) += da9062_wdt.o
diff --git a/drivers/watchdog/bd9576_wdt.c b/drivers/watchdog/bd9576_wdt.c
new file mode 100644
index ..0b6999f3b6e8
--- /dev/null
+++ b/drivers/watchdog/bd9576_wdt.c
@@ -0,0 +1,291 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (C) 2020 ROHM Semiconductors
+ *
+ * ROHM BD9576MUF and BD9573MUF Watchdog driver
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static bool nowayout;
+module_param(nowayout, bool, 0);
+MODULE_PARM_DESC(nowayout,
+ "Watchdog cannot be stopped once started (default=\"false\")");
+
+#define HW_MARGIN_MIN 2
+#define HW_MARGIN_MAX 4416
+#define BD957X_WDT_DEFAULT_MARGIN 4416
+#define WATCHDOG_TIMEOUT 30
+
+struct bd9576_wdt_priv {
+ struct gpio_desc*gpiod_ping;
+ struct gpio_desc*gpiod_en;
+ struct device *dev;
+ struct regmap *regmap;
+ boolalways_running;
+ struct watchdog_device wdd;
+};
+
+static void bd9576_wdt_disable(struct bd9576_wdt_priv *priv)
+{
+ gpiod_set_value_cansleep(priv->gpiod_en, 0);
+}
+
+static int bd9576_wdt_ping(struct watchdog_device *wdd)
+{
+ struct bd9576_wdt_priv *priv = watchdog_get_drvdata(wdd);
+
+ /* Pulse */
+ gpiod_set_value_cansleep(priv->gpiod_ping, 1);
+ gpiod_set_value_cansleep(priv->gpiod_ping, 0);
+
+ return 0;
+}
+
+static int bd9576_wdt_start(struct watchdog_device *wdd)
+{
+ struct bd9576_wdt_priv *priv = watchdog_get_drvdata(wdd);
+
+ gpiod_set_value_cansleep(priv->gpiod_en, 1);
+
+ return bd9576_wdt_ping(wdd);
+}
+
+static int bd9576_wdt_stop(struct watchdog_device *wdd)
+{
+ struct bd9576_wdt_priv *priv = watchdog_get_drvdata(wdd);
+
+ if (!priv->always_running)
+ bd9576_wdt_disable(priv);
+ else
+ set_bit(WDOG_HW_RUNNING, >status);
+
+ return 0;
+}
+
+static const struct watchdog_info bd957x_wdt_ident = {
+ .options= WDIOF_MAGICCLOSE | WDIOF_KEEPALIVEPING |
+ WDIOF_SETTIMEOUT,
+ .identity = "BD957x Watchdog",
+};
+
+static const struct watchdog_ops bd957x_wdt_ops = {
+ .owner = THIS_MODULE,
+ .start = bd9576_wdt_start,
+ .stop = bd9576_wdt_stop,
+ .ping = bd9576_wdt_ping,
+};
+
+/* Unit is hundreds of uS */
+#define FASTNG_MIN 23
+
+static int find_closest_fast(int target, int *sel, int *val)
+{
+ int i;
+ int window = FASTNG_MIN;
+
+ for (i = 0; i < 8 && window < target; i++)
+ window <<= 1;
+
+ *val = window;
+ *sel = i;
+
+ if (i == 8)
+ return -EINVAL;
+
+ return 0;
+
+}
+
+static int
[PATCH RESEND v6 1/4] dt_bindings: mfd: Add ROHM BD9576MUF and BD9573MUF PMICs
Add bindings for ROHM BD9576MUF and BD9573MUF PMICs. These
PMICs are primarily intended to be used to power the R-Car series
processors. They provide 6 power outputs, safety features and a
watchdog with two functional modes.
Signed-off-by: Matti Vaittinen
Reviewed-by: Rob Herring
---
.../bindings/mfd/rohm,bd9576-pmic.yaml| 123 ++
1 file changed, 123 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/rohm,bd9576-pmic.yaml
diff --git a/Documentation/devicetree/bindings/mfd/rohm,bd9576-pmic.yaml
b/Documentation/devicetree/bindings/mfd/rohm,bd9576-pmic.yaml
new file mode 100644
index ..6483860da955
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/rohm,bd9576-pmic.yaml
@@ -0,0 +1,123 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/rohm,bd9576-pmic.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ROHM BD9576MUF and BD9573MUF Power Management Integrated Circuit
bindings
+
+maintainers:
+ - Matti Vaittinen
+
+description: |
+ BD9576MUF and BD9573MUF are power management ICs primarily intended for
+ powering the R-Car series processors.
+ The IC provides 6 power outputs with configurable sequencing and safety
+ monitoring. A watchdog logic with slow ping/windowed modes is also included.
+
+properties:
+ compatible:
+enum:
+ - rohm,bd9576
+ - rohm,bd9573
+
+ reg:
+description:
+ I2C slave address.
+maxItems: 1
+
+ interrupts:
+maxItems: 1
+
+ rohm,vout1-en-low:
+description:
+ BD9576 and BD9573 VOUT1 regulator enable state can be individually
+ controlled by a GPIO. This is dictated by state of vout1-en pin during
+ the PMIC startup. If vout1-en is LOW during PMIC startup then the VOUT1
+ enable sate is controlled via this pin. Set this property if vout1-en
+ is wired to be down at PMIC start-up.
+type: boolean
+
+ rohm,vout1-en-gpios:
+description:
+ GPIO specifier to specify the GPIO connected to vout1-en for vout1 ON/OFF
+ state control.
+maxItems: 1
+
+ rohm,ddr-sel-low:
+description:
+ The BD9576 and BD9573 output voltage for DDR can be selected by setting
+ the ddr-sel pin low or high. Set this property if ddr-sel is grounded.
+type: boolean
+
+ rohm,watchdog-enable-gpios:
+description: The GPIO line used to enable the watchdog.
+maxItems: 1
+
+ rohm,watchdog-ping-gpios:
+description: The GPIO line used to ping the watchdog.
+maxItems: 1
+
+ rohm,hw-timeout-ms:
+maxItems: 2
+description:
+ Watchog timeout in milliseconds. If single value is given it is
+ the maximum timeout. Eg. if pinging watchdog is not done within this time
+ limit the watchdog will be triggered. If two values are given watchdog
+ is configured in "window mode". Then first value is limit for short-ping
+ Eg. if watchdog is pinged sooner than that the watchdog will trigger.
+ When two values is given the second value is the maximum timeout.
+ # (HW) minimum for short timeout is 2ms, maximum 220 ms.
+ # (HW) minimum for max timeout is 4ms, maximum 4416 ms.
+
+ regulators:
+$ref: ../regulator/rohm,bd9576-regulator.yaml
+description:
+ List of child nodes that specify the regulators.
+
+required:
+ - compatible
+ - reg
+ - regulators
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+i2c {
+#address-cells = <1>;
+#size-cells = <0>;
+pmic: pmic@30 {
+compatible = "rohm,bd9576";
+reg = <0x30>;
+rohm,vout1-en-low;
+rohm,vout1-en-gpios = < 6 GPIO_ACTIVE_HIGH>;
+rohm,ddr-sel-low;
+rohm,watchdog-enable-gpios = < 6 GPIO_ACTIVE_HIGH>;
+rohm,watchdog-ping-gpios = < 7 GPIO_ACTIVE_HIGH>;
+rohm,hw-timeout-ms = <150>, <2300>;
+
+regulators {
+boost1: regulator-vd50 {
+regulator-name = "VD50";
+};
+buck1: regulator-vd18 {
+regulator-name = "VD18";
+};
+buck2: regulator-vdddr {
+regulator-name = "VDDDR";
+};
+buck3: regulator-vd10 {
+regulator-name = "VD10";
+};
+ldo: regulator-voutl1 {
+regulator-name = "VOUTL1";
+};
+sw: regulator-vouts1 {
+regulator-name = "VOUTS1";
+};
+};
+};
+};
--
2.25.4
--
Matti Vaittinen, Linux device drivers
ROHM Semiconductors, Finland SWDC
Kiviharjunlenkki 1E
90220 OULU
FINLAND
~~~ "I don't think so," said Rene Descartes. Just then he vanished ~~~
Simon says - in Latin please.
~~~ "non cogito me" dixit Rene Descarte, deinde evanescavit ~~~
Thanks to Simon Glass for the
[PATCH RESEND v6 0/4] Support ROHM BD9576MUF and BD9573MUF PMICs
Initial support for ROHM BD9576MUF and BD9573MUF PMICs. Resending in case it fell through the cracks :) Lee, any chance getting this in MFD? (Also, this still lacks of your ack). These PMICs are primarily intended to be used to power the R-Car family processors. BD9576MUF includes some additional safety features the BD9573MUF does not have. This initial version of drivers does not utilize these features and for now the SW behaviour is identical. This patch series includes MFD and watchdog drivers. Regulator part was already applied. - Enabling and pinging the watchdog - configuring watchog timeout / window from device-tree This patch series does not bring interrupt support. BD9576MUF and BD9573MUF are designed to keep the IRQ line low for whole duration of error condition. IRQ can't be 'acked'. So proper IRQ support would require some IRQ limiter implementation (delayed unmask?) in order to not hog the CPU. Changelog v6: - Fixed watchdog timeout Changelog v5: - rebased on top of v5.10-rc2 - few styling fixes in MFD as suggested by Lee Changelog v4: - rebased on top of 5.10-rc1 - Fix typo (repeated word maximum) from the DT binding doc Changelog v3: - use only one binding to specify watchdog time-out window. Changelog v2: - dropped already applied regulator part - dt_bindings: Fix case for regulator-names in the example - watchdod: unify probe error check and revise includes --- Matti Vaittinen (4): dt_bindings: mfd: Add ROHM BD9576MUF and BD9573MUF PMICs mfd: Support ROHM BD9576MUF and BD9573MUF wdt: Support wdt on ROHM BD9576MUF and BD9573MUF MAINTAINERS: Add ROHM BD9576MUF and BD9573MUF drivers .../bindings/mfd/rohm,bd9576-pmic.yaml| 123 MAINTAINERS | 4 + drivers/mfd/Kconfig | 11 + drivers/mfd/Makefile | 1 + drivers/mfd/rohm-bd9576.c | 108 +++ drivers/watchdog/Kconfig | 13 + drivers/watchdog/Makefile | 1 + drivers/watchdog/bd9576_wdt.c | 291 ++ include/linux/mfd/rohm-bd957x.h | 59 include/linux/mfd/rohm-generic.h | 2 + 10 files changed, 613 insertions(+) create mode 100644 Documentation/devicetree/bindings/mfd/rohm,bd9576-pmic.yaml create mode 100644 drivers/mfd/rohm-bd9576.c create mode 100644 drivers/watchdog/bd9576_wdt.c create mode 100644 include/linux/mfd/rohm-bd957x.h base-commit: 3cea11cd5e3b00d91caf0b4730194039b45c5891 -- 2.25.4 -- Matti Vaittinen, Linux device drivers ROHM Semiconductors, Finland SWDC Kiviharjunlenkki 1E 90220 OULU FINLAND ~~~ "I don't think so," said Rene Descartes. Just then he vanished ~~~ Simon says - in Latin please. ~~~ "non cogito me" dixit Rene Descarte, deinde evanescavit ~~~ Thanks to Simon Glass for the translation =]
[PATCH RESEND v6 2/4] mfd: Support ROHM BD9576MUF and BD9573MUF
Add core support for ROHM BD9576MUF and BD9573MUF PMICs which are
mainly used to power the R-Car series processors.
Signed-off-by: Matti Vaittinen
---
drivers/mfd/Kconfig | 11
drivers/mfd/Makefile | 1 +
drivers/mfd/rohm-bd9576.c| 108 +++
include/linux/mfd/rohm-bd957x.h | 59 +
include/linux/mfd/rohm-generic.h | 2 +
5 files changed, 181 insertions(+)
create mode 100644 drivers/mfd/rohm-bd9576.c
create mode 100644 include/linux/mfd/rohm-bd957x.h
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 8b99a13669bf..dcb2b14a570e 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -2010,6 +2010,17 @@ config MFD_ROHM_BD71828
Also included is a Coulomb counter, a real-time clock (RTC), and
a 32.768 kHz clock gate.
+config MFD_ROHM_BD957XMUF
+ tristate "ROHM BD9576MUF and BD9573MUF Power Management ICs"
+ depends on I2C=y
+ depends on OF
+ select REGMAP_I2C
+ select MFD_CORE
+ help
+ Select this option to get support for the ROHM BD9576MUF and
+ BD9573MUF Power Management ICs. BD9576 and BD9573 are primarily
+ designed to be used to power R-Car series processors.
+
config MFD_STM32_LPTIMER
tristate "Support for STM32 Low-Power Timer"
depends on (ARCH_STM32 && OF) || COMPILE_TEST
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 1780019d2474..837f68c9f336 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -261,6 +261,7 @@ obj-$(CONFIG_RAVE_SP_CORE) += rave-sp.o
obj-$(CONFIG_MFD_ROHM_BD70528) += rohm-bd70528.o
obj-$(CONFIG_MFD_ROHM_BD71828) += rohm-bd71828.o
obj-$(CONFIG_MFD_ROHM_BD718XX) += rohm-bd718x7.o
+obj-$(CONFIG_MFD_ROHM_BD957XMUF) += rohm-bd9576.o
obj-$(CONFIG_MFD_STMFX)+= stmfx.o
obj-$(CONFIG_MFD_KHADAS_MCU) += khadas-mcu.o
diff --git a/drivers/mfd/rohm-bd9576.c b/drivers/mfd/rohm-bd9576.c
new file mode 100644
index ..f4dd9e438427
--- /dev/null
+++ b/drivers/mfd/rohm-bd9576.c
@@ -0,0 +1,108 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+//
+// Copyright (C) 2020 ROHM Semiconductors
+//
+// ROHM BD9576MUF and BD9573MUF PMIC driver
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static struct mfd_cell bd9573_mfd_cells[] = {
+ { .name = "bd9573-pmic", },
+ { .name = "bd9576-wdt", },
+};
+
+static struct mfd_cell bd9576_mfd_cells[] = {
+ { .name = "bd9576-pmic", },
+ { .name = "bd9576-wdt", },
+};
+
+static const struct regmap_range volatile_ranges[] = {
+ regmap_reg_range(BD957X_REG_SMRB_ASSERT, BD957X_REG_SMRB_ASSERT),
+ regmap_reg_range(BD957X_REG_PMIC_INTERNAL_STAT,
+BD957X_REG_PMIC_INTERNAL_STAT),
+ regmap_reg_range(BD957X_REG_INT_THERM_STAT, BD957X_REG_INT_THERM_STAT),
+ regmap_reg_range(BD957X_REG_INT_OVP_STAT, BD957X_REG_INT_SYS_STAT),
+ regmap_reg_range(BD957X_REG_INT_MAIN_STAT, BD957X_REG_INT_MAIN_STAT),
+};
+
+static const struct regmap_access_table volatile_regs = {
+ .yes_ranges = _ranges[0],
+ .n_yes_ranges = ARRAY_SIZE(volatile_ranges),
+};
+
+static struct regmap_config bd957x_regmap = {
+ .reg_bits = 8,
+ .val_bits = 8,
+ .volatile_table = _regs,
+ .max_register = BD957X_MAX_REGISTER,
+ .cache_type = REGCACHE_RBTREE,
+};
+
+static int bd957x_i2c_probe(struct i2c_client *i2c,
+const struct i2c_device_id *id)
+{
+ int ret;
+ struct regmap *regmap;
+ struct mfd_cell *mfd;
+ int cells;
+ unsigned long chip_type;
+
+ chip_type = (unsigned long)of_device_get_match_data(>dev);
+
+ switch (chip_type) {
+ case ROHM_CHIP_TYPE_BD9576:
+ mfd = bd9576_mfd_cells;
+ cells = ARRAY_SIZE(bd9576_mfd_cells);
+ break;
+ case ROHM_CHIP_TYPE_BD9573:
+ mfd = bd9573_mfd_cells;
+ cells = ARRAY_SIZE(bd9573_mfd_cells);
+ break;
+ default:
+ dev_err(>dev, "Unknown device type");
+ return -EINVAL;
+ }
+
+ regmap = devm_regmap_init_i2c(i2c, _regmap);
+ if (IS_ERR(regmap)) {
+ dev_err(>dev, "Failed to initialize Regmap\n");
+ return PTR_ERR(regmap);
+ }
+
+ ret = devm_mfd_add_devices(>dev, PLATFORM_DEVID_AUTO, mfd, cells,
+ NULL, 0, NULL);
+ if (ret)
+ dev_err(>dev, "Failed to create subdevices\n");
+
+ return ret;
+}
+
+static const struct of_device_id bd957x_of_match[] = {
+ { .compatible = "rohm,bd9576", .data = (void *)ROHM_CHIP_TYPE_BD9576, },
+ { .compatible = "rohm,bd9573", .data = (void *)ROHM_CHIP_TYPE_BD9573, },
+ { },
+};
+MODULE_DEVICE_TABLE(of, bd957x_of_match);
+
+static struct i2c_driver bd957x_drv = {
+
Re: [PATCH net-next v5] net/tun: Call netdev notifiers
On 2020-11-20 19:28, Jakub Kicinski wrote: On Wed, 18 Nov 2020 07:39:19 +0100 Martin Schiller wrote: Call netdev notifiers before and after changing the device type. Signed-off-by: Martin Schiller This is a fix, right? Can you give an example of something that goes wrong without this patch? This change is related to my latest patches to the X.25 Subsystem: https://patchwork.kernel.org/project/netdevbpf/list/?series=388087 I use a tun interface in a XoT (X.25 over TCP) application and use the TUNSETLINK ioctl to change the device type to ARPHRD_X25. As the default device type is ARPHRD_NONE the initial NETDEV_REGISTER event won't be catched by the X.25 Stack. Therefore I have to use the NETDEV_POST_TYPE_CHANGE to make sure that the corresponding neighbour structure is created. I could imagine that other protocols have similar requirements. Whether this is a fix or a functional extension is hard to say. Some time ago there was also a corresponding patch for the WAN/HDLC subsystem: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=2f8364a291e8
Re: [PATCH v10 00/19] Introduce memory interconnect for NVIDIA Tegra SoCs
On 23-11-20, 03:27, Dmitry Osipenko wrote: > This series brings initial support for memory interconnect to Tegra20, > Tegra30 and Tegra124 SoCs. > > For the starter only display controllers and devfreq devices are getting > interconnect API support, others could be supported later on. The display > controllers have the biggest demand for interconnect API right now because > dynamic memory frequency scaling can't be done safely without taking into > account bandwidth requirement from the displays. In particular this series > fixes distorted display output on T30 Ouya and T124 TK1 devices. > > Changelog: > > v10 - In a longer run it will be much nicer if we could support EMC > hardware versioning on Tegra20 and it's not late to support it now. > Hence I added these new patches: > > dt-bindings: memory: tegra20: emc: Document opp-supported-hw property > memory: tegra20: Support hardware versioning and clean up OPP table > initialization > > - Removed error message from tegra30-devfreq driver about missing OPP > properties in a device-tree because EMC driver already prints that > message and it uses OPP API error code instead of checking DT directly, > which is a more correct way of doing that. Looks good to me (from OPP APIs usage perspective). Thanks for continuing with this and fixing all the issues Dmitry. -- viresh
Re: [PATCH 037/141] Input: pcspkr - Fix fall-through warnings for Clang
On Fri, Nov 20, 2020 at 12:30:02PM -0600, Gustavo A. R. Silva wrote: > In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning > by explicitly adding a break statement instead of just letting the code > fall through to the next case. > > Link: https://github.com/KSPP/linux/issues/115 > Signed-off-by: Gustavo A. R. Silva Applied, thank you. -- Dmitry
Re: [PATCH 141/141] Input: libps2 - Fix fall-through warnings for Clang
On Fri, Nov 20, 2020 at 12:41:12PM -0600, Gustavo A. R. Silva wrote: > In preparation to enable -Wimplicit-fallthrough for Clang, fix a > warning by replacing a /* Fall through */ comment with the new > pseudo-keyword macro fallthrough. > > Notice that Clang doesn't recognize /* Fall through */ comments as > implicit fall-through markings. > > Link: https://github.com/KSPP/linux/issues/115 > Signed-off-by: Gustavo A. R. Silva Applied, thank you. -- Dmitry
[PATCH] Input: soc_button_array - add missing include
This fixes the following build errors:
CC [M] drivers/input/misc/soc_button_array.o
drivers/input/misc/soc_button_array.c:156:4: error: implicit declaration of
function 'irq_set_irq_type' [-Werror,-Wimplicit-function-declaration]
irq_set_irq_type(irq, IRQ_TYPE_LEVEL_LOW);
^
drivers/input/misc/soc_button_array.c:156:26: error: use of undeclared
identifier 'IRQ_TYPE_LEVEL_LOW'
irq_set_irq_type(irq, IRQ_TYPE_LEVEL_LOW);
^
2 errors generated.
Fixes: 78a5b53e9fb4 ("Input: soc_button_array - work around DSDTs which modify
the irqflags")
Reported-by: kernel test robot
Signed-off-by: Dmitry Torokhov
---
drivers/input/misc/soc_button_array.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/input/misc/soc_button_array.c
b/drivers/input/misc/soc_button_array.c
index cae1a3fae83a..d14a65683c5e 100644
--- a/drivers/input/misc/soc_button_array.c
+++ b/drivers/input/misc/soc_button_array.c
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#include
#include
#include
--
2.29.2.454.gaff20da3a2-goog
--
Dmitry
Re: [RFC 09/11] coresight: etm-perf: Disable the path before capturing the trace data
On 11/12/20 2:57 PM, Suzuki K Poulose wrote: > On 11/10/20 12:45 PM, Anshuman Khandual wrote: >> perf handle structure needs to be shared with the TRBE IRQ handler for >> capturing trace data and restarting the handle. There is a probability >> of an undefined reference based crash when etm event is being stopped >> while a TRBE IRQ also getting processed. This happens due the release >> of perf handle via perf_aux_output_end(). This stops the sinks via the >> link before releasing the handle, which will ensure that a simultaneous >> TRBE IRQ could not happen. >> >> Signed-off-by: Anshuman Khandual >> --- >> This might cause problem with traditional sink devices which can be >> operated in both sysfs and perf mode. This needs to be addressed >> correctly. One option would be to move the update_buffer callback >> into the respective sink devices. e.g, disable(). >> >> drivers/hwtracing/coresight/coresight-etm-perf.c | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.c >> b/drivers/hwtracing/coresight/coresight-etm-perf.c >> index 534e205..1a37991 100644 >> --- a/drivers/hwtracing/coresight/coresight-etm-perf.c >> +++ b/drivers/hwtracing/coresight/coresight-etm-perf.c >> @@ -429,7 +429,9 @@ static void etm_event_stop(struct perf_event *event, int >> mode) >> size = sink_ops(sink)->update_buffer(sink, handle, >> event_data->snk_config); >> + coresight_disable_path(path); >> perf_aux_output_end(handle, size); >> + return; >> } > > As you mentioned, this is not ideal where another session could be triggered > on > the sink from a different ETM (not for per-CPU sink) in a different mode > before > you collect the buffer. I believe the best option is to leave the > update_buffer() to disable_hw. This would need to pass on the "handle" to the > disable_path. Passing 'handle' into coresight_ops_sink->disable() would enable pushing updated trace data into perf aux buffer. But do you propose to drop the update_buffer() call back completely or just move it into disable() call back (along with PERF_EF_UPDATE mode check) for all individual sinks for now. May be, later it can be dropped off completely. > > That way the races can be handled inside the sinks. Also, this aligns the > perf mode of the sinks with that of the sysfs mode. Did not get that, could you please elaborate ?
Re: [v4,2/3] PCI: mediatek: Add new generation controller support
On Thu, 2020-11-19 at 09:22 -0600, Rob Herring wrote: > On Wed, Nov 18, 2020 at 04:29:34PM +0800, Jianjun Wang wrote: > > MediaTek's PCIe host controller has three generation HWs, the new > > generation HW is an individual bridge, it supoorts Gen3 speed and > > up to 256 MSI interrupt numbers for multi-function devices. > > > > Add support for new Gen3 controller which can be found on MT8192. > > > > Signed-off-by: Jianjun Wang > > Acked-by: Ryder Lee > > --- > > drivers/pci/controller/Kconfig | 14 + > > drivers/pci/controller/Makefile |1 + > > drivers/pci/controller/pcie-mediatek-gen3.c | 1031 +++ > > 3 files changed, 1046 insertions(+) > > create mode 100644 drivers/pci/controller/pcie-mediatek-gen3.c > > > > diff --git a/drivers/pci/controller/Kconfig b/drivers/pci/controller/Kconfig > > index f18c3725ef80..83daa772595b 100644 > > --- a/drivers/pci/controller/Kconfig > > +++ b/drivers/pci/controller/Kconfig > > @@ -239,6 +239,20 @@ config PCIE_MEDIATEK > > Say Y here if you want to enable PCIe controller support on > > MediaTek SoCs. > > > > +config PCIE_MEDIATEK_GEN3 > > + tristate "MediaTek GEN3 PCIe controller" > > + depends on ARCH_MEDIATEK || COMPILE_TEST > > + depends on OF > > + depends on PCI_MSI_IRQ_DOMAIN > > + help > > + Adds support for PCIe Gen3 MAC controller for MediaTek SoCs. > > + This PCIe controller provides the capable of Gen3, Gen2 and > > + Gen1 speed, and support up to 256 MSI interrupt numbers for > > + multi-function devices. > > + > > + Say Y here if you want to enable Gen3 PCIe controller support on > > + MediaTek SoCs. > > + > > config PCIE_TANGO_SMP8759 > > bool "Tango SMP8759 PCIe controller (DANGEROUS)" > > depends on ARCH_TANGO && PCI_MSI && OF > > diff --git a/drivers/pci/controller/Makefile > > b/drivers/pci/controller/Makefile > > index bcdbf49ab1e4..9c1b96777597 100644 > > --- a/drivers/pci/controller/Makefile > > +++ b/drivers/pci/controller/Makefile > > @@ -27,6 +27,7 @@ obj-$(CONFIG_PCIE_ROCKCHIP) += pcie-rockchip.o > > obj-$(CONFIG_PCIE_ROCKCHIP_EP) += pcie-rockchip-ep.o > > obj-$(CONFIG_PCIE_ROCKCHIP_HOST) += pcie-rockchip-host.o > > obj-$(CONFIG_PCIE_MEDIATEK) += pcie-mediatek.o > > +obj-$(CONFIG_PCIE_MEDIATEK_GEN3) += pcie-mediatek-gen3.o > > obj-$(CONFIG_PCIE_TANGO_SMP8759) += pcie-tango.o > > obj-$(CONFIG_VMD) += vmd.o > > obj-$(CONFIG_PCIE_BRCMSTB) += pcie-brcmstb.o > > diff --git a/drivers/pci/controller/pcie-mediatek-gen3.c > > b/drivers/pci/controller/pcie-mediatek-gen3.c > > new file mode 100644 > > index ..dd454cfee373 > > --- /dev/null > > +++ b/drivers/pci/controller/pcie-mediatek-gen3.c > > @@ -0,0 +1,1031 @@ > > +// SPDX-License-Identifier: GPL-2.0 > > +/* > > + * MediaTek PCIe host controller driver. > > + * > > + * Copyright (c) 2020 MediaTek Inc. > > + * Author: Jianjun Wang > > + */ > > + > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > + > > +#include "../pci.h" > > + > > +#define PCIE_SETTING_REG 0x80 > > +#define PCIE_PCI_IDS_1 0x9c > > +#define PCI_CLASS(class) (class << 8) > > +#define PCIE_RC_MODE BIT(0) > > + > > +#define PCIE_CFGNUM_REG0x140 > > +#define PCIE_CFG_DEVFN(devfn) ((devfn) & GENMASK(7, 0)) > > +#define PCIE_CFG_BUS(bus) (((bus) << 8) & GENMASK(15, 8)) > > +#define PCIE_CFG_BYTE_EN(bytes)(((bytes) << 16) & GENMASK(19, > > 16)) > > +#define PCIE_CFG_FORCE_BYTE_EN BIT(20) > > +#define PCIE_CFG_OFFSET_ADDR 0x1000 > > +#define PCIE_CFG_HEADER(devfn, bus) \ > > + (PCIE_CFG_DEVFN(devfn) | PCIE_CFG_BUS(bus)) > > + > > +#define PCIE_CFG_HEADER_FORCE_BE(devfn, bus, bytes) \ > > + (PCIE_CFG_HEADER(devfn, bus) | PCIE_CFG_BYTE_EN(bytes) \ > > +| PCIE_CFG_FORCE_BYTE_EN) > > + > > +#define PCIE_RST_CTRL_REG 0x148 > > +#define PCIE_MAC_RSTB BIT(0) > > +#define PCIE_PHY_RSTB BIT(1) > > +#define PCIE_BRG_RSTB BIT(2) > > +#define PCIE_PE_RSTB BIT(3) > > + > > +#define PCIE_MISC_STATUS_REG 0x14C > > +#define PCIE_LTR_MSG_RECEIVED BIT(0) > > +#define PCIE_PCIE_MSG_RECEIVED BIT(1) > > + > > +#define PCIE_LTSSM_STATUS_REG 0x150 > > +#define PCIE_LTSSM_STATE_MASK GENMASK(28, 24) > > +#define PCIE_LTSSM_STATE(val) ((val & PCIE_LTSSM_STATE_MASK) > > >> 24) > > +#define PCIE_LTSSM_STATE_L00x10 > > +#define PCIE_LTSSM_STATE_L1_IDLE 0x13 > > +#define PCIE_LTSSM_STATE_L2_IDLE 0x14 > > + > > +#define PCIE_LINK_STATUS_REG 0x154 > >
Re: [PATCH] kconfig: qconf: show Qt version in the About dialog
On Mon, Nov 2, 2020 at 12:40 PM Masahiro Yamada wrote:
>
> You can get the Qt version by running "pkg-config --modversion Qt5Core"
> or something, but this might be useful to get the runtime Qt version
> more easily. Go to the menu "Help" -> "About", then you can see it.
>
> Signed-off-by: Masahiro Yamada
> ---
Applied to linux-kbuild.
> scripts/kconfig/qconf.cc | 9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/scripts/kconfig/qconf.cc b/scripts/kconfig/qconf.cc
> index cbe749b44b1a..d000869b787c 100644
> --- a/scripts/kconfig/qconf.cc
> +++ b/scripts/kconfig/qconf.cc
> @@ -1799,10 +1799,13 @@ void ConfigMainWindow::showIntro(void)
> void ConfigMainWindow::showAbout(void)
> {
> static const QString str = "qconf is Copyright (C) 2002 Roman Zippel
> .\n"
> - "Copyright (C) 2015 Boris Barbulovski
> .\n\n"
> - "Bug reports and feature request can also be entered at
> http://bugzilla.kernel.org/\n;;
> + "Copyright (C) 2015 Boris Barbulovski
> .\n"
> + "\n"
> + "Bug reports and feature request can also be entered at
> http://bugzilla.kernel.org/\n;
> + "\n"
> + "Qt Version: ";
>
> - QMessageBox::information(this, "qconf", str);
> + QMessageBox::information(this, "qconf", str + qVersion());
> }
>
> void ConfigMainWindow::saveSettings(void)
> --
> 2.25.1
>
--
Best Regards
Masahiro Yamada
Re: [PATCH 2/2] scsi: pm8001: Make implicit use of pm8001_ha in pm8001_printk explicit
On Sat, Nov 21, 2020 at 12:16 AM Joe Perches wrote:
>
> Make the pm8001_printk macro take an explicit HBA instead of
> assuming the existence of an unspecified pm8001_ha argument
>
> Miscellanea:
>
> o Add pm8001_ha to the few uses of pm8001_printk
> o Add HBA to the pm8001_dbg macro call to pm8001_printk
>
> Signed-off-by: Joe Perches
Looks good!
Thanks!
Acked-by: Jack Wang
> ---
> drivers/scsi/pm8001/pm8001_init.c | 11 +--
> drivers/scsi/pm8001/pm8001_sas.c | 4 ++--
> drivers/scsi/pm8001/pm8001_sas.h | 6 +++---
> 3 files changed, 10 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/scsi/pm8001/pm8001_init.c
> b/drivers/scsi/pm8001/pm8001_init.c
> index 96b7281b2fca..13530d7fb8a6 100644
> --- a/drivers/scsi/pm8001/pm8001_init.c
> +++ b/drivers/scsi/pm8001/pm8001_init.c
> @@ -1293,9 +1293,8 @@ static int pm8001_pci_suspend(struct pci_dev *pdev,
> pm_message_t state)
> tasklet_kill(_ha->tasklet[j]);
> #endif
> device_state = pci_choose_state(pdev, state);
> - pm8001_printk("pdev=0x%p, slot=%s, entering "
> - "operating state [D%d]\n", pdev,
> - pm8001_ha->name, device_state);
> + pm8001_printk(pm8001_ha, "pdev=0x%p, slot=%s, entering operating
> state [D%d]\n",
> + pdev, pm8001_ha->name, device_state);
> pci_save_state(pdev);
> pci_disable_device(pdev);
> pci_set_power_state(pdev, device_state);
> @@ -1319,15 +1318,15 @@ static int pm8001_pci_resume(struct pci_dev *pdev)
> pm8001_ha = sha->lldd_ha;
> device_state = pdev->current_state;
>
> - pm8001_printk("pdev=0x%p, slot=%s, resuming from previous "
> - "operating state [D%d]\n", pdev, pm8001_ha->name,
> device_state);
> + pm8001_printk(pm8001_ha, "pdev=0x%p, slot=%s, resuming from previous
> operating state [D%d]\n",
> + pdev, pm8001_ha->name, device_state);
>
> pci_set_power_state(pdev, PCI_D0);
> pci_enable_wake(pdev, PCI_D0, 0);
> pci_restore_state(pdev);
> rc = pci_enable_device(pdev);
> if (rc) {
> - pm8001_printk("slot=%s Enable device failed during resume\n",
> + pm8001_printk(pm8001_ha, "slot=%s Enable device failed during
> resume\n",
> pm8001_ha->name);
> goto err_out_enable;
> }
> diff --git a/drivers/scsi/pm8001/pm8001_sas.c
> b/drivers/scsi/pm8001/pm8001_sas.c
> index 505a885b4c77..4562b0a5062a 100644
> --- a/drivers/scsi/pm8001/pm8001_sas.c
> +++ b/drivers/scsi/pm8001/pm8001_sas.c
> @@ -1191,7 +1191,7 @@ int pm8001_abort_task(struct sas_task *task)
> phy_id = pm8001_dev->attached_phy;
> ret = pm8001_find_tag(task, );
> if (ret == 0) {
> - pm8001_printk("no tag for task:%p\n", task);
> + pm8001_printk(pm8001_ha, "no tag for task:%p\n", task);
> return TMF_RESP_FUNC_FAILED;
> }
> spin_lock_irqsave(>task_state_lock, flags);
> @@ -1313,7 +1313,7 @@ int pm8001_abort_task(struct sas_task *task)
> task->slow_task = NULL;
> spin_unlock_irqrestore(>task_state_lock, flags);
> if (rc != TMF_RESP_FUNC_COMPLETE)
> - pm8001_printk("rc= %d\n", rc);
> + pm8001_printk(pm8001_ha, "rc= %d\n", rc);
> return rc;
> }
>
> diff --git a/drivers/scsi/pm8001/pm8001_sas.h
> b/drivers/scsi/pm8001/pm8001_sas.h
> index 5cd6fe6a7d2d..5266756a268b 100644
> --- a/drivers/scsi/pm8001/pm8001_sas.h
> +++ b/drivers/scsi/pm8001/pm8001_sas.h
> @@ -70,14 +70,14 @@
> #define PM8001_DEVIO_LOGGING 0x100 /* development io message logging */
> #define PM8001_IOERR_LOGGING 0x200 /* development io err message logging */
>
> -#define pm8001_printk(fmt, ...)
> \
> +#define pm8001_printk(HBA, fmt, ...) \
> pr_info("%s:: %s %d:" fmt, \
> - pm8001_ha->name, __func__, __LINE__, ##__VA_ARGS__)
> + (HBA)->name, __func__, __LINE__, ##__VA_ARGS__)
>
> #define pm8001_dbg(HBA, level, fmt, ...) \
> do { \
> if (unlikely((HBA)->logging_level & PM8001_##level##_LOGGING)) \
> - pm8001_printk(fmt, ##__VA_ARGS__); \
> + pm8001_printk(HBA, fmt, ##__VA_ARGS__); \
> } while (0)
>
> #define PM8001_USE_TASKLET
> --
> 2.26.0
>
Re: [PATCH v6] checkpatch: add fix option for LOGICAL_CONTINUATIONS
On Sun, 2020-11-22 at 18:29 +0530, Aditya Srivastava wrote:
> Currently, checkpatch warns if logical continuations are placed at the
> start of a line and not at the end of previous line.
>
> E.g., running checkpatch on commit 3485507fc272 ("staging:
> bcm2835-camera: Reduce length of enum names") reports:
>
> CHECK:LOGICAL_CONTINUATIONS: Logical continuations should be on the
> previous line
> + if (!ret
> + && camera_port ==
>
> Provide a simple fix by inserting logical operator at the last
> non-comment, non-whitespace char of the previous line and removing from
> current line, if both the lines are additions(ie start with '+')
>
> Signed-off-by: Aditya Srivastava
[]
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
[]
> @@ -3553,8 +3553,16 @@ sub process {
>
>
> # check for && or || at the start of a line
> if ($rawline =~ /^\+\s*(&&|\|\|)/) {
> - CHK("LOGICAL_CONTINUATIONS",
> - "Logical continuations should be on the previous
> line\n" . $hereprev);
> + my $operator = $1;
> + if (CHK("LOGICAL_CONTINUATIONS",
> + "Logical continuations should be on the
> previous line\n" . $hereprev) &&
> + $fix && $prevrawline =~ /^\+/) {
> + # insert logical operator at last non-comment,
> non-whitepsace char on previous line
> + $prevline =~ /[\s$;]*$/;
> + my $line_end = substr($prevrawline, $-[0]);
> + $fixed[$fixlinenr - 1] =~ s/\Q$line_end\E/
> $operator$line_end/;
This doesn't work when the same leading whitespace and trailing whitespace
characters exist.
You need to use something like:
$fixed[$fixlinenr - 1] =~ s/\Q$line_end\E$/
$operator$line_end/;
(note the $ after \E to use EOL)
Re: [PATCH v3 5/5] perf metric: Don't compute unused events.
> +| expr '|' expr
> +{
> + if (!compute_ids || (isfinite($1.val) && isfinite($3.val))) {
> + assert($1.ids == NULL);
> + assert($3.ids == NULL);
> + $$.val = (long)$1.val | (long)$3.val;
> + $$.ids = NULL;
> + } else {
> + /*
> + * LHS or RHS needs to be computed from event IDs, consequently
> + * so does this expression. Set val to NAN to show that the set
> + * of all values is possible, the events are the union of those
> + * on the LHS and RHS.
> + */
> + $$.val = NAN;
> + $$.ids = ids__union($1.ids, $3.ids);
> + }
Sorry, still not a fan of the having this nan code all over. It's just ugly.
If you don't want to do the syntax change to still do it in one pass,
and given building an AST would be a little complicated.
The original parser I based this code on actually had a byte code version too
(see attachment). With that one the lazy evaluation could be done on the byte
code
level. Originally I didn't include it because it wasn't really
needed for perf, but presumably if we want to do more complicated
things it might be useful.
In theory it could speed up performance slightly when an expression needs
to be computed multiple times in interval mode.
-Andi
#include
#include
#include
#include
#include "code.h"
#include "sym.h"
#include "error.h"
static unsigned char *bufs;
static unsigned bufl;
static unsigned char *bufp;
static void overflow(void)
{
yyerror("expression exceeds execution buffer");
}
void put_op(enum ops op)
{
if (bufp >= bufs + bufl)
overflow();
*bufp++ = op;
}
void put_long(enum ops op, long arg)
{
if (bufp + sizeof(long) + 1 >= bufs + bufl)
overflow();
*bufp++ = op;
memcpy(bufp, , sizeof(long));
bufp += sizeof(long);
}
void put_ptr(enum ops op, void * arg)
{
if (bufp + sizeof(void *) + 1 >= bufs + bufl)
overflow();
*bufp++ = op;
memcpy(bufp, , sizeof(void *));
bufp += sizeof(void *);
}
void start_def(struct symbol *s)
{
if (!s->undef)
yyerror("symbol %s redefined", s->name);
}
void end_def(struct symbol *s)
{
int len;
put_op(OP_RET);
len = bufp - bufs;
s->code = malloc(len);
memcpy(s->code, bufs, len);
bufp = bufs;
s->undef = 0;
}
static void execerror(char const *msg)
{
fprintf(stderr, "expression execution error: %s\n", msg);
exit(1);
}
#define STACKSIZE 16
#define CSTACKSIZE 16
long execute(unsigned char *bufp)
{
static void *target[] = {
[OP_END]= &,
[OP_EVENT] = NULL,
[OP_NUMBER] = &,
[OP_PLUS] = &,
[OP_MINUS] = &,
[OP_MUL]= &,
[OP_DIV]= &,
[OP_MOD]= &,
[OP_NEGATE] = &,
[OP_CALL] = &,
[OP_RET]= &,
[OP_XOR]= &,
[OP_OR] = &,
[OP_NOT]= &,
[OP_AND]= &,
[OP_SHL]= &,
[OP_SHR]= &,
};
long a, b;
long stack[STACKSIZE];
int stackp = 0;
unsigned char *callstack[CSTACKSIZE];
int callstackp = 0;
#define getop(x) memcpy(&(x), bufp, sizeof(x)); bufp += sizeof(x)
#define push(x) stack[stackp++] = (x)
#define pop()stack[--stackp]
#define next() goto *target[(int)*bufp++]
next();
number:
if (stackp == STACKSIZE)
execerror("expression stack overflow");
getop(a);
push(a);
next();
#define OP(op) \
b = pop(); \
a = pop(); \
push(a op b); \
next()
plus: OP(+);
minus: OP(-);
mul:OP(*);
div:
b = pop();
if (b == 0)
execerror("division by 0");
a = pop();
push(a / b);
next();
mod:
b = pop();
if (b == 0)
execerror("modulo by 0");
a = pop();
push(a % b);
next();
negate:
a = pop();
push(-a);
next();
and:OP(&);
or: OP(|);
xor:OP(^);
shl:OP(<<);
shr:OP(>>);
not:
a = pop();
push(~a);
next();
call: {
struct symbol *s;
getop(s);
if (callstackp == CSTACKSIZE)
execerror("call stack overflow");
callstack[callstackp++] = bufp;
bufp = s->code;
next();
}
ret:
bufp = callstack[--callstackp];
next();
end:
assert(bufp == bufs || stackp == 1);
assert(callstackp == 0);
return stack[0];
}
#undef next
#undef push
#undef pop
#undef getop
void code_init(unsigned char *buf, unsigned
RE: [EXT] Re: [PATCH v1 1/2] mmc: Support kmsg dumper based on pstore/blk
Big thanks Uffe, my answers in line to yours.
>-Original Message-
>From: Ulf Hansson
>Sent: Friday, November 20, 2020 6:51 PM
>To: Bhaskara Budiredla
>Cc: Kees Cook ; Colin Cross
>; Tony Luck ; Sunil Kovvuri
>Goutham ; linux-...@vger.kernel.org; Linux
>Kernel Mailing List
>Subject: [EXT] Re: [PATCH v1 1/2] mmc: Support kmsg dumper based on
>pstore/blk
>
>External Email
>
>--
>On Thu, 12 Nov 2020 at 07:24, Bhaskara Budiredla
> wrote:
>>
>> This patch introduces to mmcpstore. The functioning of mmcpstore is is
>> similar to mtdpstore. mmcpstore works on FTL based flash devices
>> whereas mtdpstore works on raw flash devices. When the system crashes,
>> mmcpstore stores the kmsg panic and oops logs to a user specified MMC
>> device.
>>
>> It collects the details about the host MMC device through pstore/blk
>> "blkdev" parameter. The user can specify the MMC device in many ways
>> by checking in Documentation/admin-guide/pstore-blk.rst.
>>
>> The individual mmc host drivers have to define suitable polling
>> subroutines to write kmsg panic/oops logs through mmcpstore.
>
>I don't like that changes to host drivers are needed to support this, but
>perhaps there is no other good way!?
Yes, I couldn't think of a better way as polling functionality is host specific.
>
>>
>> Signed-off-by: Bhaskara Budiredla
>> ---
>> drivers/mmc/core/Kconfig | 7 +
>> drivers/mmc/core/Makefile| 1 +
>> drivers/mmc/core/block.c | 20 +++
>> drivers/mmc/core/block.h | 3 +
>> drivers/mmc/core/core.c | 24 +++
>> drivers/mmc/core/mmcpstore.c | 318
>+++
>> include/linux/mmc/card.h | 4 +
>> include/linux/mmc/core.h | 4 +
>> include/linux/mmc/host.h | 6 +
>> 9 files changed, 387 insertions(+)
>> create mode 100644 drivers/mmc/core/mmcpstore.c
>>
>> diff --git a/drivers/mmc/core/Kconfig b/drivers/mmc/core/Kconfig index
>> c12fe13e4b14..cafb367c482d 100644
>> --- a/drivers/mmc/core/Kconfig
>> +++ b/drivers/mmc/core/Kconfig
>> @@ -81,3 +81,10 @@ config MMC_TEST
>> This driver is only of interest to those developing or
>> testing a host driver. Most people should say N here.
>>
>> +config MMC_PSTORE
>> + bool "Log panic/oops to a MMC buffer"
>> + depends on PSTORE
>> + depends on PSTORE_BLK
>> + help
>> + Backend driver to store the kmsg crash dumps to a user specified
>MMC
>> + device. The driver is based on pstore/blk.
>> diff --git a/drivers/mmc/core/Makefile b/drivers/mmc/core/Makefile
>> index 95ffe008ebdf..5f4230b79ac6 100644
>> --- a/drivers/mmc/core/Makefile
>> +++ b/drivers/mmc/core/Makefile
>> @@ -17,4 +17,5 @@ mmc_core-$(CONFIG_DEBUG_FS) += debugfs.o
>> obj-$(CONFIG_MMC_BLOCK)+= mmc_block.o
>> mmc_block-objs := block.o queue.o
>> obj-$(CONFIG_MMC_TEST) += mmc_test.o
>> +obj-$(CONFIG_MMC_PSTORE) += mmcpstore.o
>> obj-$(CONFIG_SDIO_UART)+= sdio_uart.o
>> diff --git a/drivers/mmc/core/block.c b/drivers/mmc/core/block.c index
>> 8d3df0be0355..f11c21d60b67 100644
>> --- a/drivers/mmc/core/block.c
>> +++ b/drivers/mmc/core/block.c
>> @@ -2870,6 +2870,21 @@ static void mmc_blk_remove_debugfs(struct
>> mmc_card *card,
>>
>> #endif /* CONFIG_DEBUG_FS */
>>
>> +#ifdef CONFIG_MMC_PSTORE
>> +sector_t mmc_blk_get_part(struct mmc_card *card, int part_num,
>> +sector_t *size) {
>> + struct mmc_blk_data *md = dev_get_drvdata(>dev);
>> + struct gendisk *disk = md->disk;
>> + struct disk_part_tbl *part_tbl = disk->part_tbl;
>> +
>> + if (part_num < 0 || part_num >= part_tbl->len)
>> + return 0;
>> +
>> + *size = part_tbl->part[part_num]->nr_sects << SECTOR_SHIFT;
>> + return part_tbl->part[part_num]->start_sect;
>> +}
>> +#endif
>> +
>> static int mmc_blk_probe(struct mmc_card *card) {
>> struct mmc_blk_data *md, *part_md; @@ -2913,6 +2928,11 @@
>> static int mmc_blk_probe(struct mmc_card *card)
>> goto out;
>> }
>>
>> +#ifdef CONFIG_MMC_PSTORE
>
>Avoid using ifdefs in common functions like these, please. I think it's more
>clean to add a stub function and then just call it unconditionally here.
Sure, will do this.
>
>> + if (mmc_card_mmc(card) || mmc_card_sd(card))
>> + mmcpstore_card_set(card, md->disk->disk_name); #endif
>> +
>> /* Add two debugfs entries */
>> mmc_blk_add_debugfs(card, md);
>>
>> diff --git a/drivers/mmc/core/block.h b/drivers/mmc/core/block.h index
>> 31153f656f41..2a2b81635508 100644
>> --- a/drivers/mmc/core/block.h
>> +++ b/drivers/mmc/core/block.h
>> @@ -16,5 +16,8 @@ void mmc_blk_mq_recovery(struct mmc_queue *mq);
>> struct work_struct;
>>
>> void mmc_blk_mq_complete_work(struct work_struct *work);
>> +#ifdef CONFIG_MMC_PSTORE
>> +sector_t mmc_blk_get_part(struct mmc_card *card, int part_num,
>>
[PATCH 1/2] events/core: introduce perf_pmu_disable_all() to turn off all PMU
In crash context, NMI should be suppressed before jump to a new kernel.
Naturally as the source of NMI on some arches, PMU should be turned off at
that time.
Introduce perf_pmu_disable_all() to achieve the goal.
Signed-off-by: Pingfan Liu
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Arnaldo Carvalho de Melo
Cc: Mark Rutland
Cc: Alexander Shishkin
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Thomas Gleixner
Cc: Borislav Petkov
Cc: "H. Peter Anvin"
Cc: Omar Sandoval
Cc: Andrew Morton
Cc: Mike Rapoport
Cc: x...@kernel.org
To: linux-kernel@vger.kernel.org
---
include/linux/perf_event.h | 1 +
kernel/events/core.c | 10 ++
2 files changed, 11 insertions(+)
diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index 96450f6..f4baa87 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -965,6 +965,7 @@ extern const struct perf_event_attr
*perf_event_attrs(struct perf_event *event);
extern void perf_event_print_debug(void);
extern void perf_pmu_disable(struct pmu *pmu);
extern void perf_pmu_enable(struct pmu *pmu);
+extern void perf_pmu_disable_all(void);
extern void perf_sched_cb_dec(struct pmu *pmu);
extern void perf_sched_cb_inc(struct pmu *pmu);
extern int perf_event_task_disable(void);
diff --git a/kernel/events/core.c b/kernel/events/core.c
index dc568ca..c8e04a5 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -1205,6 +1205,16 @@ void perf_pmu_enable(struct pmu *pmu)
pmu->pmu_enable(pmu);
}
+/* When crashed, other cpus hang in idle loop, so here do an emergency job
under no lock */
+void perf_pmu_disable_all(void)
+{
+ struct pmu *pmu;
+
+ list_for_each_entry(pmu, , entry)
+ if (pmu->pmu_disable)
+ pmu->pmu_disable(pmu);
+}
+
static DEFINE_PER_CPU(struct list_head, active_ctx_list);
/*
--
2.7.5
[PATCH 2/2] x86/machine_kexec: disable PMU before jumping to new kernel
During jumping to the new kernel, on the crashed cpu, the memory mapping
switches from an old one to an identity one. It had better disable PMU to
suppress NMI, which can be delivered using the old mapping.
Also on x86_64, idt_invalidate() to clear idt as on 32 bits.
Signed-off-by: Pingfan Liu
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Arnaldo Carvalho de Melo
Cc: Mark Rutland
Cc: Alexander Shishkin
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Thomas Gleixner
Cc: Borislav Petkov
Cc: "H. Peter Anvin"
Cc: Omar Sandoval
Cc: Andrew Morton
Cc: Mike Rapoport
To: x...@kernel.org
Cc: linux-kernel@vger.kernel.org
---
arch/x86/kernel/machine_kexec_32.c | 1 +
arch/x86/kernel/machine_kexec_64.c | 3 +++
2 files changed, 4 insertions(+)
diff --git a/arch/x86/kernel/machine_kexec_32.c
b/arch/x86/kernel/machine_kexec_32.c
index 64b00b0..72c6100 100644
--- a/arch/x86/kernel/machine_kexec_32.c
+++ b/arch/x86/kernel/machine_kexec_32.c
@@ -191,6 +191,7 @@ void machine_kexec(struct kimage *image)
/* Interrupts aren't acceptable while we reboot */
local_irq_disable();
hw_breakpoint_disable();
+ perf_pmu_disable_all();
if (image->preserve_context) {
#ifdef CONFIG_X86_IO_APIC
diff --git a/arch/x86/kernel/machine_kexec_64.c
b/arch/x86/kernel/machine_kexec_64.c
index a29a44a..238893e 100644
--- a/arch/x86/kernel/machine_kexec_64.c
+++ b/arch/x86/kernel/machine_kexec_64.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
@@ -338,6 +339,8 @@ void machine_kexec(struct kimage *image)
/* Interrupts aren't acceptable while we reboot */
local_irq_disable();
hw_breakpoint_disable();
+ perf_pmu_disable_all();
+ idt_invalidate(phys_to_virt(0));
if (image->preserve_context) {
#ifdef CONFIG_X86_IO_APIC
--
2.7.5
[PATCH] mmc: sdhci-pci-gli: Reduce power consumption for GL9755
From: Ben Chuang
For GL9755, reduce power consumption by lowering the LFCLK and disabling
the DMACLK on low-power.
Signed-off-by: Ben Chuang
---
drivers/mmc/host/sdhci-pci-gli.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/mmc/host/sdhci-pci-gli.c b/drivers/mmc/host/sdhci-pci-gli.c
index 9887485a4134..f10bdfbfce36 100644
--- a/drivers/mmc/host/sdhci-pci-gli.c
+++ b/drivers/mmc/host/sdhci-pci-gli.c
@@ -97,6 +97,10 @@
#define GLI_9755_WT_EN_ON 0x1
#define GLI_9755_WT_EN_OFF0x0
+#define PCI_GLI_9755_PECONF 0x44
+#define PCI_GLI_9755_LFCLKGENMASK(14, 12)
+#define PCI_GLI_9755_DMACLK BIT(29)
+
#define PCI_GLI_9755_PLL0x64
#define PCI_GLI_9755_PLL_LDIV GENMASK(9, 0)
#define PCI_GLI_9755_PLL_PDIV GENMASK(14, 12)
@@ -519,6 +523,21 @@ static void sdhci_gl9755_set_clock(struct sdhci_host
*host, unsigned int clock)
sdhci_enable_clk(host, clk);
}
+static void gl9755_hw_setting(struct sdhci_pci_slot *slot)
+{
+ struct pci_dev *pdev = slot->chip->pdev;
+ u32 value;
+
+ gl9755_wt_on(pdev);
+
+ pci_read_config_dword(pdev, PCI_GLI_9755_PECONF, );
+ value &= ~PCI_GLI_9755_LFCLK;
+ value &= ~PCI_GLI_9755_DMACLK;
+ pci_write_config_dword(pdev, PCI_GLI_9755_PECONF, value);
+
+ gl9755_wt_off(pdev);
+}
+
static int gli_probe_slot_gl9750(struct sdhci_pci_slot *slot)
{
struct sdhci_host *host = slot->host;
@@ -534,6 +553,7 @@ static int gli_probe_slot_gl9755(struct sdhci_pci_slot
*slot)
{
struct sdhci_host *host = slot->host;
+ gl9755_hw_setting(slot);
gli_pcie_enable_msi(slot);
slot->host->mmc->caps2 |= MMC_CAP2_NO_SDIO;
sdhci_enable_v4_mode(host);
--
2.29.2
Re: [RFC 10/11] coresgith: etm-perf: Connect TRBE sink with ETE source
On 11/12/20 3:01 PM, Suzuki K Poulose wrote: > Hi Anshuman, > On 11/10/20 12:45 PM, Anshuman Khandual wrote: >> Unlike traditional sink devices, individual TRBE instances are not detected >> via DT or ACPI nodes. Instead TRBE instances are detected during CPU online >> process. Hence a path connecting ETE and TRBE on a given CPU would not have >> been established until then. This adds two coresight helpers that will help >> modify outward connections from a source device to establish and terminate >> path to a given sink device. But this method might not be optimal and would >> be reworked later. >> >> Signed-off-by: Anshuman Khandual > > Instead of this, could we come up something like a percpu_sink concept ? That > way, the TRBE driver could register the percpu_sink for the corresponding CPU > and we don't have to worry about the order in which the ETE will be probed > on a hotplugged CPU. (i.e, if the TRBE is probed before the ETE, the following > approach would fail to register the sink). Right, it wont work. We already have a per cpu csdev sink. The current mechanism expects all ETEs to have been established and the TRBEs just get plugged in during their init while probing each individual cpus. During cpu hotplug in or out, a TRBE-ETE link either gets created and destroyed. But it assumes that an ETE is always present for TRBE to get plugged into or teared down from. csdev for TRBE sink too gets released during cpu hot remove path. Are you suggesting that there should be a percpu static csdev array defined for potential all TRBEs so that the ETE-TRBE links be permanently established given that the ETEs are permanent and never really go away with cpu hot remove event (my assumption). TRBE csdevs should just get enabled or disabled without really being destroyed during cpu hotplug, so that the corresponding TRBE-ETE connection remains in place. > > And the default sink can be initialized when the ETE instance first starts > looking for it. IIUC def_sink is the sink which will be selected by default for a source device while creating a path, in case there is no clear preference from the user. ETE's default sink should be fixed (TRBE) to be on the easy side and hence assigning that during connection expansion procedure, does make sense. But then it can be more complex where the 'default' sink for an ETE can be scenario specific and may not be always be its TRBE. The expanding connections fits into a scenario where the ETE is present with all it's other traditional sinks and TRBE is the one which comes in or goes out with the cpu. If ETE also comes in and goes out with individual cpu hotplug which is preferred ideally, we would need to also 1. Co-ordinate with TRBE bring up and connection creation to avoid race 2. Rediscover traditional sinks which were attached to the ETE before - go back, rescan the DT/ACPI entries for sinks with whom a path can be established etc. Basically there are three choices we have here 1. ETE is permanent, TRBE and ETE-TRBE path gets created or destroyed with hotplug (current proposal) 2. ETE/TRBE/ETE-TRBE path are all permanent, ETE and TRBE get enabled or disabled with hotplug 3. ETE, TRBE and ETE-TRBE path, all get created, enabled and destroyed with hotplug in sync - Anshuman
Re: [PATCH 1/2] mmc: sdhci-sprd: drop of_match_ptr from of_device_id table
On Sat, 21 Nov 2020 at 00:23, Krzysztof Kozlowski wrote:
>
> The driver can match only via the DT table so the table should be always
> used and the of_match_ptr does not have any sense (this also allows ACPI
> matching via PRP0001, even though it is not relevant here). This fixes
> compile warning (!CONFIG_OF on x86_64):
>
> drivers/mmc/host/sdhci-sprd.c:723:34: warning:
> ‘sdhci_sprd_of_match’ defined but not used [-Wunused-const-variable=]
>
> Reported-by: kernel test robot
> Signed-off-by: Krzysztof Kozlowski
Acked-by: Chunyan Zhang
> ---
> drivers/mmc/host/sdhci-sprd.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/host/sdhci-sprd.c b/drivers/mmc/host/sdhci-sprd.c
> index 58109c5b53e2..f85171edabeb 100644
> --- a/drivers/mmc/host/sdhci-sprd.c
> +++ b/drivers/mmc/host/sdhci-sprd.c
> @@ -788,7 +788,7 @@ static struct platform_driver sdhci_sprd_driver = {
> .driver = {
> .name = "sdhci_sprd_r11",
> .probe_type = PROBE_PREFER_ASYNCHRONOUS,
> - .of_match_table = of_match_ptr(sdhci_sprd_of_match),
> + .of_match_table = sdhci_sprd_of_match,
> .pm = _sprd_pm_ops,
> },
> };
> --
> 2.25.1
>
[PATCH net v2] devlink: Fix reload stats structure
Fix reload stats structure exposed to the user. Change stats structure
hierarchy to have the reload action as a parent of the stat entry and
then stat entry includes value per limit. This will also help to avoid
string concatenation on iproute2 output.
Reload stats structure before this fix:
"stats": {
"reload": {
"driver_reinit": 2,
"fw_activate": 1,
"fw_activate_no_reset": 0
}
}
After this fix:
"stats": {
"reload": {
"driver_reinit": {
"unspecified": 2
},
"fw_activate": {
"unspecified": 1,
"no_reset": 0
}
}
Fixes: a254c264267e ("devlink: Add reload stats")
Signed-off-by: Moshe Shemesh
Reviewed-by: Jiri Pirko
---
v1 -> v2:
- Fold comment at 80 characters.
---
include/uapi/linux/devlink.h | 2 ++
net/core/devlink.c | 49 +++-
2 files changed, 34 insertions(+), 17 deletions(-)
diff --git a/include/uapi/linux/devlink.h b/include/uapi/linux/devlink.h
index 0113bc4db9f5..5203f54a2be1 100644
--- a/include/uapi/linux/devlink.h
+++ b/include/uapi/linux/devlink.h
@@ -526,6 +526,8 @@ enum devlink_attr {
DEVLINK_ATTR_RELOAD_STATS_LIMIT,/* u8 */
DEVLINK_ATTR_RELOAD_STATS_VALUE,/* u32 */
DEVLINK_ATTR_REMOTE_RELOAD_STATS, /* nested */
+ DEVLINK_ATTR_RELOAD_ACTION_INFO,/* nested */
+ DEVLINK_ATTR_RELOAD_ACTION_STATS, /* nested */
/* add new attributes above here, update the policy in devlink.c */
diff --git a/net/core/devlink.c b/net/core/devlink.c
index e6fb1fdedded..bf79d018990c 100644
--- a/net/core/devlink.c
+++ b/net/core/devlink.c
@@ -517,8 +517,7 @@ devlink_reload_limit_is_supported(struct devlink *devlink,
enum devlink_reload_l
return test_bit(limit, >ops->reload_limits);
}
-static int devlink_reload_stat_put(struct sk_buff *msg, enum
devlink_reload_action action,
- enum devlink_reload_limit limit, u32 value)
+static int devlink_reload_stat_put(struct sk_buff *msg, enum
devlink_reload_limit limit, u32 value)
{
struct nlattr *reload_stats_entry;
@@ -526,8 +525,7 @@ static int devlink_reload_stat_put(struct sk_buff *msg,
enum devlink_reload_acti
if (!reload_stats_entry)
return -EMSGSIZE;
- if (nla_put_u8(msg, DEVLINK_ATTR_RELOAD_ACTION, action) ||
- nla_put_u8(msg, DEVLINK_ATTR_RELOAD_STATS_LIMIT, limit) ||
+ if (nla_put_u8(msg, DEVLINK_ATTR_RELOAD_STATS_LIMIT, limit) ||
nla_put_u32(msg, DEVLINK_ATTR_RELOAD_STATS_VALUE, value))
goto nla_put_failure;
nla_nest_end(msg, reload_stats_entry);
@@ -540,7 +538,7 @@ static int devlink_reload_stat_put(struct sk_buff *msg,
enum devlink_reload_acti
static int devlink_reload_stats_put(struct sk_buff *msg, struct devlink
*devlink, bool is_remote)
{
- struct nlattr *reload_stats_attr;
+ struct nlattr *reload_stats_attr, *action_info_attr, *action_stats_attr;
int i, j, stat_idx;
u32 value;
@@ -552,17 +550,28 @@ static int devlink_reload_stats_put(struct sk_buff *msg,
struct devlink *devlink
if (!reload_stats_attr)
return -EMSGSIZE;
- for (j = 0; j <= DEVLINK_RELOAD_LIMIT_MAX; j++) {
- /* Remote stats are shown even if not locally supported. Stats
-* of actions with unspecified limit are shown though drivers
-* don't need to register unspecified limit.
-*/
- if (!is_remote && j != DEVLINK_RELOAD_LIMIT_UNSPEC &&
- !devlink_reload_limit_is_supported(devlink, j))
+ for (i = 0; i <= DEVLINK_RELOAD_ACTION_MAX; i++) {
+ if ((!is_remote && !devlink_reload_action_is_supported(devlink,
i)) ||
+ i == DEVLINK_RELOAD_ACTION_UNSPEC)
continue;
- for (i = 0; i <= DEVLINK_RELOAD_ACTION_MAX; i++) {
- if ((!is_remote &&
!devlink_reload_action_is_supported(devlink, i)) ||
- i == DEVLINK_RELOAD_ACTION_UNSPEC ||
+ action_info_attr = nla_nest_start(msg,
DEVLINK_ATTR_RELOAD_ACTION_INFO);
+ if (!action_info_attr)
+ goto nla_put_failure;
+
+ if (nla_put_u8(msg, DEVLINK_ATTR_RELOAD_ACTION, i))
+ goto action_info_nest_cancel;
+ action_stats_attr = nla_nest_start(msg,
DEVLINK_ATTR_RELOAD_ACTION_STATS);
+ if (!action_stats_attr)
+ goto action_info_nest_cancel;
+
+ for (j = 0; j <= DEVLINK_RELOAD_LIMIT_MAX; j++) {
+ /* Remote stats are shown even if not locally supported.
+* Stats of actions with unspecified limit are shown
+* though drivers don't need to register unspecified
+* limit.
+
[PATCH] f2fs: change to use rwsem for cp_mutex
Use rwsem to ensure serialization of the callers and to avoid
starvation of high priority tasks, when the system is under
heavy IO workload.
Signed-off-by: Sahitya Tummala
---
fs/f2fs/checkpoint.c | 8
fs/f2fs/f2fs.h | 2 +-
fs/f2fs/gc.c | 4 ++--
fs/f2fs/recovery.c | 4 ++--
fs/f2fs/super.c | 2 +-
5 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
index 023462e..7fb8c80 100644
--- a/fs/f2fs/checkpoint.c
+++ b/fs/f2fs/checkpoint.c
@@ -348,13 +348,13 @@ static int f2fs_write_meta_pages(struct address_space
*mapping,
goto skip_write;
/* if locked failed, cp will flush dirty pages instead */
- if (!mutex_trylock(>cp_mutex))
+ if (!down_write_trylock(>cp_global_sem))
goto skip_write;
trace_f2fs_writepages(mapping->host, wbc, META);
diff = nr_pages_to_write(sbi, META, wbc);
written = f2fs_sync_meta_pages(sbi, META, wbc->nr_to_write, FS_META_IO);
- mutex_unlock(>cp_mutex);
+ up_write(>cp_global_sem);
wbc->nr_to_write = max((long)0, wbc->nr_to_write - written - diff);
return 0;
@@ -1572,7 +1572,7 @@ int f2fs_write_checkpoint(struct f2fs_sb_info *sbi,
struct cp_control *cpc)
f2fs_warn(sbi, "Start checkpoint disabled!");
}
if (cpc->reason != CP_RESIZE)
- mutex_lock(>cp_mutex);
+ down_write(>cp_global_sem);
if (!is_sbi_flag_set(sbi, SBI_IS_DIRTY) &&
((cpc->reason & CP_FASTBOOT) || (cpc->reason & CP_SYNC) ||
@@ -1647,7 +1647,7 @@ int f2fs_write_checkpoint(struct f2fs_sb_info *sbi,
struct cp_control *cpc)
trace_f2fs_write_checkpoint(sbi->sb, cpc->reason, "finish checkpoint");
out:
if (cpc->reason != CP_RESIZE)
- mutex_unlock(>cp_mutex);
+ up_write(>cp_global_sem);
return err;
}
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index e082677..842c2ca 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -1369,7 +1369,7 @@ struct f2fs_sb_info {
int cur_cp_pack;/* remain current cp pack */
spinlock_t cp_lock; /* for flag in ckpt */
struct inode *meta_inode; /* cache meta blocks */
- struct mutex cp_mutex; /* checkpoint procedure lock */
+ struct rw_semaphore cp_global_sem; /* checkpoint procedure lock */
struct rw_semaphore cp_rwsem; /* blocking FS operations */
struct rw_semaphore node_write; /* locking node writes */
struct rw_semaphore node_change;/* locking node change */
diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
index 05641a1..3ef84e6 100644
--- a/fs/f2fs/gc.c
+++ b/fs/f2fs/gc.c
@@ -1986,7 +1986,7 @@ int f2fs_resize_fs(struct f2fs_sb_info *sbi, __u64
block_count)
freeze_super(sbi->sb);
down_write(>gc_lock);
- mutex_lock(>cp_mutex);
+ down_write(>cp_global_sem);
spin_lock(>stat_lock);
if (shrunk_blocks + valid_user_blocks(sbi) +
@@ -2031,7 +2031,7 @@ int f2fs_resize_fs(struct f2fs_sb_info *sbi, __u64
block_count)
spin_unlock(>stat_lock);
}
out_err:
- mutex_unlock(>cp_mutex);
+ up_write(>cp_global_sem);
up_write(>gc_lock);
thaw_super(sbi->sb);
clear_sbi_flag(sbi, SBI_IS_RESIZEFS);
diff --git a/fs/f2fs/recovery.c b/fs/f2fs/recovery.c
index 0947d36..da75d5d 100644
--- a/fs/f2fs/recovery.c
+++ b/fs/f2fs/recovery.c
@@ -799,7 +799,7 @@ int f2fs_recover_fsync_data(struct f2fs_sb_info *sbi, bool
check_only)
INIT_LIST_HEAD(_list);
/* prevent checkpoint */
- mutex_lock(>cp_mutex);
+ down_write(>cp_global_sem);
/* step #1: find fsynced inode numbers */
err = find_fsync_dnodes(sbi, _list, check_only);
@@ -850,7 +850,7 @@ int f2fs_recover_fsync_data(struct f2fs_sb_info *sbi, bool
check_only)
if (!err)
clear_sbi_flag(sbi, SBI_POR_DOING);
- mutex_unlock(>cp_mutex);
+ up_write(>cp_global_sem);
/* let's drop all the directory inodes for clean checkpoint */
destroy_fsync_dnodes(_list, err);
diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
index 87f7a6e..e33b0da 100644
--- a/fs/f2fs/super.c
+++ b/fs/f2fs/super.c
@@ -3552,7 +3552,7 @@ static int f2fs_fill_super(struct super_block *sb, void
*data, int silent)
sbi->valid_super_block = valid_super_block;
init_rwsem(>gc_lock);
mutex_init(>writepages);
- mutex_init(>cp_mutex);
+ init_rwsem(>cp_global_sem);
init_rwsem(>node_write);
init_rwsem(>node_change);
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project.
Re: [PATCH] kbuild: add extra-y to targets-for-modules
On Tue, Nov 3, 2020 at 3:23 PM WANG Chao wrote:
>
> extra-y target doesn't build for 'make M=...' since commit 6212804f2d78
> ("kbuild: do not create built-in objects for external module builds").
>
> This especially breaks kpatch, which is using 'extra-y := kpatch.lds'
> and 'make M=...' to build livepatch patch module.
>
> Add extra-y to targets-for-modules so that such kind of build works
> properly.
>
> Signed-off-by: WANG Chao
> ---
> scripts/Makefile.build | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/scripts/Makefile.build b/scripts/Makefile.build
> index ae647379b579..0113a042d643 100644
> --- a/scripts/Makefile.build
> +++ b/scripts/Makefile.build
> @@ -86,7 +86,7 @@ ifdef need-builtin
> targets-for-builtin += $(obj)/built-in.a
> endif
>
> -targets-for-modules := $(patsubst %.o, %.mod, $(filter %.o, $(obj-m)))
> +targets-for-modules := $(extra-y) $(patsubst %.o, %.mod, $(filter %.o,
> $(obj-m)))
>
> ifdef need-modorder
> targets-for-modules += $(obj)/modules.order
> --
> 2.29.1
>
NACK.
Please fix your Makefile.
Hint:
https://patchwork.kernel.org/project/linux-kbuild/patch/20201123045403.63402-6-masahi...@kernel.org/
Probably what you should use is 'targets'.
--
Best Regards
Masahiro Yamada
Re: [PATCH v2 05/12] x86: rework arch_local_irq_restore() to not use popf
On 22.11.20 22:44, Andy Lutomirski wrote:
On Sat, Nov 21, 2020 at 10:55 PM Jürgen Groß wrote:
On 20.11.20 12:59, Peter Zijlstra wrote:
On Fri, Nov 20, 2020 at 12:46:23PM +0100, Juergen Gross wrote:
+static __always_inline void arch_local_irq_restore(unsigned long flags)
+{
+if (!arch_irqs_disabled_flags(flags))
+arch_local_irq_enable();
+}
If someone were to write horrible code like:
local_irq_disable();
local_irq_save(flags);
local_irq_enable();
local_irq_restore(flags);
we'd be up some creek without a paddle... now I don't _think_ we have
genius code like that, but I'd feel saver if we can haz an assertion in
there somewhere...
Maybe something like:
#ifdef CONFIG_DEBUG_ENTRY // for lack of something saner
WARN_ON_ONCE((arch_local_save_flags() ^ flags) & X86_EFLAGS_IF);
#endif
At the end?
I'd like to, but using WARN_ON_ONCE() in include/asm/irqflags.h sounds
like a perfect receipt for include dependency hell.
We could use a plain asm("ud2") instead.
How about out-of-lining it:
#ifdef CONFIG_DEBUG_ENTRY
extern void warn_bogus_irqrestore();
#endif
static __always_inline void arch_local_irq_restore(unsigned long flags)
{
if (!arch_irqs_disabled_flags(flags)) {
arch_local_irq_enable();
} else {
#ifdef CONFIG_DEBUG_ENTRY
if (unlikely(arch_local_irq_save() & X86_EFLAGS_IF))
warn_bogus_irqrestore();
#endif
}
This couldn't be a WARN_ON_ONCE() then (or it would be a catch all).
Another approach might be to open-code the WARN_ON_ONCE(), like:
#ifdef CONFIG_DEBUG_ENTRY
extern void warn_bogus_irqrestore(bool *once);
#endif
static __always_inline void arch_local_irq_restore(unsigned long flags)
{
if (!arch_irqs_disabled_flags(flags))
arch_local_irq_enable();
#ifdef CONFIG_DEBUG_ENTRY
{
static bool once;
if (unlikely(arch_local_irq_save() & X86_EFLAGS_IF))
warn_bogus_irqrestore();
}
#endif
}
Juergen
OpenPGP_0xB0DE9DD628BF132F.asc
Description: application/pgp-keys
OpenPGP_signature
Description: OpenPGP digital signature
[PATCH] arm64: dts: qcom: sdm845: Limit ipa iommu streams
The Android and Windows firmware does not accept the use of 3 as a mask
to cover the IPA streams. But with 0x721 being related to WiFi and 0x723
being unsed the mapping can be reduced to just cover 0x720 and 0x722,
which is accepted.
Fixes: e9e89c45bfeb ("arm64: dts: sdm845: add IPA iommus property")
Signed-off-by: Bjorn Andersson
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index 0da27b065761..a6147bd54cdf 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -2136,7 +2136,8 @@ ufs_mem_phy_lanes: lanes@1d87400 {
ipa: ipa@1e4 {
compatible = "qcom,sdm845-ipa";
- iommus = <_smmu 0x720 0x3>;
+ iommus = <_smmu 0x720 0x0>,
+<_smmu 0x722 0x0>;
reg = <0 0x1e4 0 0x7000>,
<0 0x1e47000 0 0x2000>,
<0 0x1e04000 0 0x2c000>;
--
2.29.2
[PATCH] soc: qcom: Introduce debugfs interface to smem
Every now and then it's convenient to be able to inspect the content of
SMEM items. Rather than carrying some hack locally let's upstream a
driver that when inserted exposes a debugfs interface for dumping
available items.
Signed-off-by: Bjorn Andersson
---
drivers/soc/qcom/Kconfig| 7 +++
drivers/soc/qcom/Makefile | 1 +
drivers/soc/qcom/smem_debugfs.c | 102
3 files changed, 110 insertions(+)
create mode 100644 drivers/soc/qcom/smem_debugfs.c
diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
index 3dc3e3d61ea3..7e1dd6b3f33a 100644
--- a/drivers/soc/qcom/Kconfig
+++ b/drivers/soc/qcom/Kconfig
@@ -128,6 +128,13 @@ config QCOM_SMEM
The driver provides an interface to items in a heap shared among all
processors in a Qualcomm platform.
+config QCOM_SMEM_DEBUGFS
+ tristate "Qualcomm Shared Memory Manager (SMEM) DebugFS interface"
+ depends on QCOM_SMEM
+ depends on DEBUG_FS
+ help
+ Provides a debugfs interface for inspecting SMEM.
+
config QCOM_SMD_RPM
tristate "Qualcomm Resource Power Manager (RPM) over SMD"
depends on ARCH_QCOM || COMPILE_TEST
diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
index 93392d9dc7f7..632eefc5a897 100644
--- a/drivers/soc/qcom/Makefile
+++ b/drivers/soc/qcom/Makefile
@@ -15,6 +15,7 @@ qcom_rpmh-y += rpmh-rsc.o
qcom_rpmh-y+= rpmh.o
obj-$(CONFIG_QCOM_SMD_RPM) += smd-rpm.o
obj-$(CONFIG_QCOM_SMEM) += smem.o
+obj-$(CONFIG_QCOM_SMEM_DEBUGFS) += smem_debugfs.o
obj-$(CONFIG_QCOM_SMEM_STATE) += smem_state.o
obj-$(CONFIG_QCOM_SMP2P) += smp2p.o
obj-$(CONFIG_QCOM_SMSM)+= smsm.o
diff --git a/drivers/soc/qcom/smem_debugfs.c b/drivers/soc/qcom/smem_debugfs.c
new file mode 100644
index ..11ef29a0cada
--- /dev/null
+++ b/drivers/soc/qcom/smem_debugfs.c
@@ -0,0 +1,102 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2020, Linaro Ltd.
+ */
+
+#include
+#include
+#include
+#include
+
+struct smem_debugfs {
+ struct dentry *root;
+};
+
+static int smem_debugfs_item_show(struct seq_file *seq, void *p)
+{
+ unsigned long data = (unsigned long)seq->private;
+ unsigned long item = data & 0x;
+ unsigned long host = data >> 16;
+ size_t len;
+ void *ptr;
+
+ ptr = qcom_smem_get(host, item, );
+ if (IS_ERR(ptr))
+ return PTR_ERR(ptr);
+
+ seq_hex_dump(seq, "", DUMP_PREFIX_OFFSET, 16, 1, ptr, len, true);
+
+ return 0;
+}
+
+static int smem_debugfs_item_open(struct inode *inode, struct file *file)
+{
+ return single_open(file, smem_debugfs_item_show, inode->i_private);
+}
+
+static const struct file_operations smem_debugfs_item_ops = {
+ .open = smem_debugfs_item_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release = single_release,
+};
+
+static int smem_debugfs_rescan(struct seq_file *seq, void *p)
+{
+ struct dentry *root = seq->private;
+ unsigned long item;
+ unsigned long host;
+ unsigned long data;
+ char name[10];
+ char *ptr;
+
+ for (host = 0; host < 10; host++) {
+ for (item = 0; item < 512; item++) {
+ ptr = qcom_smem_get(host, item, NULL);
+ if (IS_ERR(ptr))
+ continue;
+
+ sprintf(name, "%ld-%ld", host, item);
+
+ data = host << 16 | item;
+ debugfs_create_file(name, 0400, root,
+ (void *)data,
_debugfs_item_ops);
+ }
+ }
+
+ return 0;
+}
+
+static int smem_debugfs_rescan_open(struct inode *inode, struct file *file)
+{
+ return single_open(file, smem_debugfs_rescan, inode->i_private);
+}
+
+static const struct file_operations smem_debugfs_rescan_ops = {
+ .open = smem_debugfs_rescan_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release = single_release,
+};
+
+static struct dentry *smem_debugfs_root;
+
+static int __init qcom_smem_debugfs_init(void)
+{
+ smem_debugfs_root = debugfs_create_dir("qcom_smem", NULL);
+ debugfs_create_file("rescan", 0400, smem_debugfs_root,
+ smem_debugfs_root, _debugfs_rescan_ops);
+
+ return 0;
+}
+
+static void __exit qcom_smem_debugfs_exit(void)
+{
+ debugfs_remove_recursive(smem_debugfs_root);
+}
+
+module_init(qcom_smem_debugfs_init);
+module_exit(qcom_smem_debugfs_exit);
+
+MODULE_DESCRIPTION("Qualcomm SMEM debugfs driver");
+MODULE_LICENSE("GPL v2");
--
2.29.2
Re: [RFC] MAINTAINERS tag for cleanup robot
(removing almost all the cc: lists and leaving scsi and lkml) On Sat, 2020-11-21 at 10:02 -0800, Joe Perches wrote: > On Sat, 2020-11-21 at 09:18 -0800, James Bottomley wrote: > > On Sat, 2020-11-21 at 08:50 -0800, t...@redhat.com wrote: > > > A difficult part of automating commits is composing the subsystem > > > preamble in the commit log. For the ongoing effort of a fixer > > > producing one or two fixes a release the use of 'treewide:' does > > > not seem appropriate. > > > > > > It would be better if the normal prefix was used. Unfortunately > > > normal is not consistent across the tree. > > > > > > D: Commit subsystem prefix > > > > > > ex/ for FPGA DFL DRIVERS > > > > > > D: fpga: dfl: > > > > I've got to bet this is going to cause more issues than it solves. > > SCSI uses scsi: : for drivers but not every driver has a > > MAINTAINERS entry. We use either scsi: or scsi: core: for mid layer > > things, but we're not consistent. Block uses blk-: for all > > of it's stuff but almost no s have a MAINTAINERS entry. So > > the next thing you're going to cause is an explosion of suggested > > MAINTAINERs entries. > > As well as some changes require simultaneous changes across > multiple subsystems. Perhaps a start of this would be something like the below for a new MAINTAINERS entry just for SCSI CORE. This adds an "E:" patch prefix entry as well as a specific file list for what seem to be "scsi core" files so that the generic SCSI SUBSYSTEM F:drivers/scsi/ entry does not have to be used. The SCSI SUBSYSTEM could have an E: entry of "scsi:" so that driver specific content could be automatically prefixed with "scsi: : --- MAINTAINERS | 18 ++ 1 file changed, 18 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 5f10105cac6f..68521abd1bd8 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -15631,6 +15631,24 @@ S: Maintained W: http://www.kernel.dk F: drivers/scsi/sr* +SCSI CORE +M: "James E.J. Bottomley" +M: "Martin K. Petersen" +L: linux-s...@vger.kernel.org +S: Maintained +Q: https://patchwork.kernel.org/project/linux-scsi/list/ +T: git git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git +T: git git://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git +E: "scsi: core:" +F: include/linux/scsi* +F: drivers/scsi/constants.c +F: drivers/scsi/hosts.c +F: drivers/scsi/scsi.* +F: drivers/scsi/scsi_* +F: drivers/scsi/sd.c +F: drivers/scsi/sense_codes.h +F: drivers/scsi/sr.c + SCSI RDMA PROTOCOL (SRP) INITIATOR M: Bart Van Assche L: linux-r...@vger.kernel.org
Re: [PATCH net] devlink: Fix reload stats structure
On 11/22/2020 12:53 AM, Jakub Kicinski wrote:
External email: Use caution opening links or attachments
On Fri, 20 Nov 2020 15:40:37 +0200 Moshe Shemesh wrote:
Fix reload stats structure exposed to the user. Change stats structure
hierarchy to have the reload action as a parent of the stat entry and
then stat entry includes value per limit. This will also help to avoid
string concatenation on iproute2 output.
Reload stats structure before this fix:
"stats": {
"reload": {
"driver_reinit": 2,
"fw_activate": 1,
"fw_activate_no_reset": 0
}
}
After this fix:
"stats": {
"reload": {
"driver_reinit": {
"unspecified": 2
},
"fw_activate": {
"unspecified": 1,
"no_reset": 0
}
}
Fixes: a254c264267e ("devlink: Add reload stats")
Signed-off-by: Moshe Shemesh
Reviewed-by: Jiri Pirko
At least try to fold the core networking code at 80 characters *please*.
You folded the comments at 86 chars, neither 100 nor 80.
Oh, I missed that comment folding while replacing it in this patch. I
will fix, thanks.
Re: [PATCH -tip 17/32] arch/x86: Add a new TIF flag for untrusted tasks
On Tue, Nov 17, 2020 at 06:19:47PM -0500, Joel Fernandes (Google) wrote: > Add a new TIF flag to indicate whether the kernel needs to be careful > and take additional steps to mitigate micro-architectural issues during > entry into user or guest mode. > > This new flag will be used by the series to determine if waiting is > needed or not, during exit to user or guest mode. > > Tested-by: Julien Desfossez > Reviewed-by: Aubrey Li > Signed-off-by: Joel Fernandes (Google) > --- Acked-by: Balbir Singh
Re: [PATCH v2] arm64: dts: sdm845: Add iommus property to qup
On 2020-11-22 03:41, Bjorn Andersson wrote:
> From: Stephen Boyd
>
> The SMMU that sits in front of the QUP needs to be programmed properly
> so that the i2c geni driver can allocate DMA descriptors. Failure to do
> this leads to faults when using devices such as an i2c touchscreen where
> the transaction is larger than 32 bytes and we use a DMA buffer.
>
> arm-smmu 1500.iommu: Unexpected global fault, this could be serious
> arm-smmu 1500.iommu: GFSR 0x0002, GFSYNR0 0x0002, GFSYNR1
> 0x06c0, GFSYNR2 0x
>
> Add the right SID and mask so this works.
>
> Signed-off-by: Stephen Boyd
> [bjorn: Define for second QUP as well, be more specific in sdm845.dtsi]
> Signed-off-by: Bjorn Andersson
> ---
> arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi | 2 ++
> arch/arm64/boot/dts/qcom/sdm845.dtsi | 2 ++
> 2 files changed, 4 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi
> b/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi
> index 39f23cdcbd02..216a74f0057c 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi
> @@ -653,10 +653,12 @@ _pwrkey {
>
> _id_0 {
> status = "okay";
> + iommus = <_smmu 0x0 0x3>;
> };
>
> _id_1 {
> status = "okay";
> + iommus = <_smmu 0x6c0 0x3>;
> };
>
> _2 {
> diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> index 6465a6653ad9..d6b7b1bfa202 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> @@ -1120,6 +1120,7 @@ qupv3_id_0: geniqup@8c {
> clock-names = "m-ahb", "s-ahb";
> clocks = < GCC_QUPV3_WRAP_0_M_AHB_CLK>,
>< GCC_QUPV3_WRAP_0_S_AHB_CLK>;
> + iommus = <_smmu 0x3 0x0>;
> #address-cells = <2>;
> #size-cells = <2>;
> ranges;
> @@ -1460,6 +1461,7 @@ qupv3_id_1: geniqup@ac {
> clock-names = "m-ahb", "s-ahb";
> clocks = < GCC_QUPV3_WRAP_1_M_AHB_CLK>,
>< GCC_QUPV3_WRAP_1_S_AHB_CLK>;
> + iommus = <_smmu 0x6c3 0x0>;
> #address-cells = <2>;
> #size-cells = <2>;
> ranges;
Tested-By: Caleb Connolly
Works on the OnePlus 6.
Re: [PATCH 3/7] kbuild: doc: fix 'List directories to visit when descending' section
On Mon, Nov 23, 2020 at 1:54 PM Masahiro Yamada wrote:
>
> Fix state information:
I mean "Fix stale information"
>
> - Fix the section number in the reference from 6.4 to 7.4.
>
> - Remove init-y and net-y. They were removed by commit 23febe375d94
>("kbuild: merge init-y into core-y") and commit 95fb6317b3ab
>("kbuild: merge net-y and virt-y into drivers-y"), respectively.
>
> - Update the example because arch/sparc64/Makefile does not exit.
>
> Signed-off-by: Masahiro Yamada
> ---
--
Best Regards
Masahiro Yamada
Re: [PATCH 09/16] mfd: max77686: drop of_match_ptr from of_device_id table
Hi Krzysztof,
On 11/21/20 1:21 AM, Krzysztof Kozlowski wrote:
> The driver can match only via the DT table so the table should be always
> used and the of_match_ptr does not have any sense (this also allows ACPI
> matching via PRP0001, even though it is not relevant here). This fixes
> compile warning (!CONFIG_OF on x86_64):
>
> drivers/mfd/max77686.c:148:34: warning: ‘max77686_pmic_dt_match’ defined
> but not used [-Wunused-const-variable=]
>
> Signed-off-by: Krzysztof Kozlowski
> ---
> drivers/mfd/max77686.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mfd/max77686.c b/drivers/mfd/max77686.c
> index 71faf503844b..2ad554b921d9 100644
> --- a/drivers/mfd/max77686.c
> +++ b/drivers/mfd/max77686.c
> @@ -270,7 +270,7 @@ static struct i2c_driver max77686_i2c_driver = {
> .driver = {
> .name = "max77686",
> .pm = _pm,
> -.of_match_table = of_match_ptr(max77686_pmic_dt_match),
> +.of_match_table = max77686_pmic_dt_match,
> },
> .probe_new = max77686_i2c_probe,
> };
>
Acked-by: Chanwoo Choi
--
Best Regards,
Chanwoo Choi
Samsung Electronics
[PATCH 2/7] kbuild: doc: replace arch/$(ARCH)/ with arch/$(SRCARCH)/
Precisely speaking, the arch directory is specified by $(SRCARCH),
not $(ARCH).
In old days, $(ARCH) actually matched to the arch directory because
32-bit and 64-bit were supported as separate architectures.
Most architectures (except arm/arm64) were unified like follows:
arch/i386, arch/x86_64-> arch/x86
arch/sh, arch/sh64-> arch/sh
arch/sparc, arch/sparc64 -> arch/sparc
To not break the user interface, commit 6752ed90da03 ("Kbuild: allow
arch/xxx to use a different source path") introduced SRCARCH to point
to the arch directory, still allowing to pass in the former ARCH=i386
or ARCH=x86_64.
Update the documents for preciseness, and add the explanation of SRCARCH.
Signed-off-by: Masahiro Yamada
---
Documentation/kbuild/makefiles.rst | 61 +-
Documentation/kbuild/modules.rst | 2 +-
2 files changed, 35 insertions(+), 28 deletions(-)
diff --git a/Documentation/kbuild/makefiles.rst
b/Documentation/kbuild/makefiles.rst
index a7b874097a91..2a5232b321af 100644
--- a/Documentation/kbuild/makefiles.rst
+++ b/Documentation/kbuild/makefiles.rst
@@ -67,11 +67,11 @@ This document describes the Linux kernel Makefiles.
The Makefiles have five parts::
- Makefilethe top Makefile.
- .config the kernel configuration file.
- arch/$(ARCH)/Makefile the arch Makefile.
- scripts/Makefile.* common rules etc. for all kbuild Makefiles.
- kbuild Makefilesexist in every subdirectory
+ Makefilethe top Makefile.
+ .config the kernel configuration file.
+ arch/$(SRCARCH)/Makefilethe arch Makefile.
+ scripts/Makefile.* common rules etc. for all kbuild Makefiles.
+ kbuild Makefilesexist in every subdirectory
The top Makefile reads the .config file, which comes from the kernel
configuration process.
@@ -82,7 +82,7 @@ It builds these goals by recursively descending into the
subdirectories of
the kernel source tree.
The list of subdirectories which are visited depends upon the kernel
configuration. The top Makefile textually includes an arch Makefile
-with the name arch/$(ARCH)/Makefile. The arch Makefile supplies
+with the name arch/$(SRCARCH)/Makefile. The arch Makefile supplies
architecture-specific information to the top Makefile.
Each subdirectory has a kbuild Makefile which carries out the commands
@@ -933,7 +933,7 @@ When "make clean" is executed, make will descend down in
arch/x86/boot,
and clean as usual. The Makefile located in arch/x86/boot/ may use
the subdir- trick to descend further down.
-Note 1: arch/$(ARCH)/Makefile cannot use "subdir-", because that file is
+Note 1: arch/$(SRCARCH)/Makefile cannot use "subdir-", because that file is
included in the top level makefile, and the kbuild infrastructure
is not operational at that point.
@@ -946,9 +946,9 @@ be visited during "make clean".
The top level Makefile sets up the environment and does the preparation,
before starting to descend down in the individual directories.
The top level makefile contains the generic part, whereas
-arch/$(ARCH)/Makefile contains what is required to set up kbuild
+arch/$(SRCARCH)/Makefile contains what is required to set up kbuild
for said architecture.
-To do so, arch/$(ARCH)/Makefile sets up a number of variables and defines
+To do so, arch/$(SRCARCH)/Makefile sets up a number of variables and defines
a few targets.
When kbuild executes, the following steps are followed (roughly):
@@ -956,14 +956,14 @@ When kbuild executes, the following steps are followed
(roughly):
1) Configuration of the kernel => produce .config
2) Store kernel version in include/linux/version.h
3) Updating all other prerequisites to the target prepare:
- - Additional prerequisites are specified in arch/$(ARCH)/Makefile
+ - Additional prerequisites are specified in arch/$(SRCARCH)/Makefile
4) Recursively descend down in all directories listed in
init-* core* drivers-* net-* libs-* and build all targets.
- - The values of the above variables are expanded in arch/$(ARCH)/Makefile.
+ - The values of the above variables are expanded in
arch/$(SRCARCH)/Makefile.
5) All object files are then linked and the resulting file vmlinux is
located at the root of the obj tree.
The very first objects linked are listed in head-y, assigned by
- arch/$(ARCH)/Makefile.
+ arch/$(SRCARCH)/Makefile.
6) Finally, the architecture-specific part does any required post processing
and builds the final bootimage.
- This includes building boot records
@@ -1169,7 +1169,7 @@ When kbuild executes, the following steps are followed
(roughly):
$(core-y), $(libs-y), $(drivers-y) and $(net-y).
The top level Makefile defines values for all generic directories,
- and arch/$(ARCH)/Makefile only adds architecture-specific
+ and arch/$(SRCARCH)/Makefile only
[PATCH 3/7] kbuild: doc: fix 'List directories to visit when descending' section
Fix state information:
- Fix the section number in the reference from 6.4 to 7.4.
- Remove init-y and net-y. They were removed by commit 23febe375d94
("kbuild: merge init-y into core-y") and commit 95fb6317b3ab
("kbuild: merge net-y and virt-y into drivers-y"), respectively.
- Update the example because arch/sparc64/Makefile does not exit.
Signed-off-by: Masahiro Yamada
---
Documentation/kbuild/makefiles.rst | 19 ++-
1 file changed, 10 insertions(+), 9 deletions(-)
diff --git a/Documentation/kbuild/makefiles.rst
b/Documentation/kbuild/makefiles.rst
index 2a5232b321af..e1aac82ddb9c 100644
--- a/Documentation/kbuild/makefiles.rst
+++ b/Documentation/kbuild/makefiles.rst
@@ -278,7 +278,7 @@ more details, with real examples.
actually recognize that there is a lib.a being built, the directory
shall be listed in libs-y.
- See also "6.4 List directories to visit when descending".
+ See also "7.4 List directories to visit when descending".
Use of lib-y is normally restricted to `lib/` and `arch/*/lib`.
@@ -1154,7 +1154,7 @@ When kbuild executes, the following steps are followed
(roughly):
machinery is all architecture-independent.
- head-y, init-y, core-y, libs-y, drivers-y, net-y
+ head-y, core-y, libs-y, drivers-y
$(head-y) lists objects to be linked first in vmlinux.
$(libs-y) lists directories where a lib.a archive can be located.
@@ -1162,11 +1162,9 @@ When kbuild executes, the following steps are followed
(roughly):
The rest list directories where a built-in.a object file can be
located.
- $(init-y) objects will be located after $(head-y).
-
Then the rest follows in this order:
- $(core-y), $(libs-y), $(drivers-y) and $(net-y).
+ $(core-y), $(libs-y), $(drivers-y)
The top level Makefile defines values for all generic directories,
and arch/$(SRCARCH)/Makefile only adds architecture-specific
@@ -1174,11 +1172,14 @@ When kbuild executes, the following steps are followed
(roughly):
Example::
- #arch/sparc64/Makefile
- core-y += arch/sparc64/kernel/
- libs-y += arch/sparc64/prom/ arch/sparc64/lib/
- drivers-$(CONFIG_OPROFILE) += arch/sparc64/oprofile/
+ # arch/sparc/Makefile
+ core-y += arch/sparc/
+
+ libs-y += arch/sparc/prom/
+ libs-y += arch/sparc/lib/
+ drivers-$(CONFIG_PM) += arch/sparc/power/
+ drivers-$(CONFIG_OPROFILE) += arch/sparc/oprofile/
7.5 Architecture-specific boot images
-
--
2.25.1
[PATCH 7/7] kbuild: doc: document subdir-y syntax
There is no explanation about subdir-y. Let's document it. Signed-off-by: Masahiro Yamada --- Documentation/kbuild/makefiles.rst | 14 ++ 1 file changed, 14 insertions(+) diff --git a/Documentation/kbuild/makefiles.rst b/Documentation/kbuild/makefiles.rst index 159e470f2616..6332b9ca7942 100644 --- a/Documentation/kbuild/makefiles.rst +++ b/Documentation/kbuild/makefiles.rst @@ -319,6 +319,20 @@ more details, with real examples. that directory specifies obj-y, those objects will be left orphan. It is very likely a bug of the Makefile or of dependencies in Kconfig. + Kbuild also supports dedicated syntax, subdir-y and subdir-m, for + descending into subdirectories. It is a good fit when you know they + do not contain kernel-space objects at all. A typical usage is to let + Kbuild descend into subdirectories to build tools. + + Examples:: + + subdir-$(CONFIG_GCC_PLUGINS) += gcc-plugins + subdir-$(CONFIG_MODVERSIONS) += genksyms + subdir-$(CONFIG_SECURITY_SELINUX) += selinux + + Unlike obj-y/m, subdir-y/m does not need the trailing slash since this + syntax is always used for directories. + It is good practice to use a `CONFIG_` variable when assigning directory names. This allows kbuild to totally skip the directory if the corresponding `CONFIG_` option is neither 'y' nor 'm'. -- 2.25.1
[PATCH 5/7] kbuild: doc: split if_changed explanation to a separate section
The if_changed macro is currently explained in the section "Commands useful for building a boot image", but the use of if_changed is not limited to the boot image. It is often used together with custom rules. Let's split it as a separate section, and insert it after the "Custom Rules" section. I slightly reworded the explanation, re-numbered to fill the section, and also fixed the broken indentation of the Note: part. Signed-off-by: Masahiro Yamada --- Documentation/kbuild/makefiles.rst | 94 +- 1 file changed, 52 insertions(+), 42 deletions(-) diff --git a/Documentation/kbuild/makefiles.rst b/Documentation/kbuild/makefiles.rst index f5a983709df7..49afcb1d3695 100644 --- a/Documentation/kbuild/makefiles.rst +++ b/Documentation/kbuild/makefiles.rst @@ -16,9 +16,9 @@ This document describes the Linux kernel Makefiles. --- 3.5 Library file goals - lib-y --- 3.6 Descending down in directories --- 3.7 Compilation flags - --- 3.8 - --- 3.9 Dependency tracking - --- 3.10 Custom Rules + --- 3.8 Dependency tracking + --- 3.9 Custom Rules + --- 3.10 Command change detection --- 3.11 $(CC) support functions --- 3.12 $(LD) support functions --- 3.13 Script Invocation @@ -410,7 +410,7 @@ more details, with real examples. AFLAGS_iwmmxt.o := -Wa,-mcpu=iwmmxt -3.9 Dependency tracking +3.8 Dependency tracking --- Kbuild tracks dependencies on the following: @@ -422,8 +422,8 @@ more details, with real examples. Thus, if you change an option to $(CC) all affected files will be re-compiled. -3.10 Custom Rules --- +3.9 Custom Rules + Custom rules are used when the kbuild infrastructure does not provide the required support. A typical example is @@ -499,6 +499,52 @@ more details, with real examples. will be displayed with "make KBUILD_VERBOSE=0". +3.10 Command change detection +- + + When the rule is evaluated, timestamps are compared between the target + and its prerequisite files. GNU Make updates the target when any of the + prerequisites is newer than that. + + The target should be rebuilt also when the command line has changed + since the last invocation. This is not supported by Make itself, so + Kbuild achieves this by a kind of meta-programming. + + if_changed is the macro used for this purpose, in the following form:: + + quiet_cmt_ = ... + cmd_ = ... + + : FORCE + $(call if_changed,) + + Any target that utilizes if_changed must be listed in $(targets), + otherwise the command line check will fail, and the target will + always be built. + + If the target is already listed in the recognized syntax such as + obj-y/m, lib-y/m, extra-y/m, hostprogs, userprogs, Kbuild automatically + add it to $(targets). Otherwise, the target must be explicitly added + to $(targets). + + Assignments to $(targets) are without $(obj)/ prefix. if_changed may be + used in conjunction with custom rules as defined in "3.9 Custom Rules". + + Note: It is a typical mistake to forget the FORCE prerequisite. + Another common pitfall is that whitespace is sometimes significant; for + instance, the below will fail (note the extra space after the comma):: + + target: source(s) FORCE + + **WRONG!** $(call if_changed, objcopy) + + Note: + if_changed should not be used more than once per target. + It stores the executed command in a corresponding .cmd + file and multiple calls would result in overwrites and + unwanted results when the target is up to date and only the + tests on changed commands trigger execution of commands. + 3.11 $(CC) support functions @@ -1287,42 +1333,6 @@ When kbuild executes, the following steps are followed (roughly): Kbuild provides a few macros that are useful when building a boot image. -if_changed - if_changed is the infrastructure used for the following commands. - - Usage:: - - target: source(s) FORCE - $(call if_changed,ld/objcopy/gzip/...) - - When the rule is evaluated, it is checked to see if any files - need an update, or the command line has changed since the last - invocation. The latter will force a rebuild if any options - to the executable have changed. - Any target that utilises if_changed must be listed in $(targets), - otherwise the command line check will fail, and the target will - always be built. - Assignments to $(targets) are without $(obj)/ prefix. -
[PATCH 1/7] kbuild: doc: update the description about kbuild Makefiles
This line was written in 2003. Now we have much more Makefiles. The number of Makefiles is not important. The point is we have a Makefile in (almost) every directory. Signed-off-by: Masahiro Yamada --- Documentation/kbuild/makefiles.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/kbuild/makefiles.rst b/Documentation/kbuild/makefiles.rst index 0d5dd5413af0..a7b874097a91 100644 --- a/Documentation/kbuild/makefiles.rst +++ b/Documentation/kbuild/makefiles.rst @@ -71,7 +71,7 @@ The Makefiles have five parts:: .config the kernel configuration file. arch/$(ARCH)/Makefile the arch Makefile. scripts/Makefile.* common rules etc. for all kbuild Makefiles. - kbuild Makefilesthere are about 500 of these. + kbuild Makefilesexist in every subdirectory The top Makefile reads the .config file, which comes from the kernel configuration process. -- 2.25.1
[PATCH 6/7] kbuild: doc: clarify the difference between extra-y and always-y
The difference between extra-y and always-y is obscure. Basically, Kbuild builds targets listed in extra-y and always-y in visited Makefiles without relying on any dependency. The difference is that extra-y is used to list the targets needed for vmlinux whereas always-y is used to list the targets that must be always built irrespective of final targets. Kbuild skips extra-y when it is building only modules (i.e. 'make modules'). This is the long-standing behavior since extra-y was introduced in 2003, and it is explained in that commit log [1]. For clarification, this is the extra-y vs always-y table: extra-yalways-y 'make' o o 'make vmlinux' o o 'make modules' x o Kbuild skips extra-y also when building external modules since obviously it never builds vmlinux. Unfortunately, extra-y is wrongly used in many places of upstream code, and even in external modules. Using extra-y in external module Makefiles is wrong. What you should use is probably always-y or 'targets'. The current documentation for extra-y is misleading. I rewrote it, and moved it to the section 3.7. always-y is not documented anywhere. I added. [1]: https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/commit/?id=f94e5fd7e5d09a56a60670a9bb211a791654bba8 Signed-off-by: Masahiro Yamada --- Documentation/kbuild/makefiles.rst | 110 +++-- 1 file changed, 71 insertions(+), 39 deletions(-) diff --git a/Documentation/kbuild/makefiles.rst b/Documentation/kbuild/makefiles.rst index 49afcb1d3695..159e470f2616 100644 --- a/Documentation/kbuild/makefiles.rst +++ b/Documentation/kbuild/makefiles.rst @@ -15,13 +15,15 @@ This document describes the Linux kernel Makefiles. --- 3.4 Objects which export symbols --- 3.5 Library file goals - lib-y --- 3.6 Descending down in directories - --- 3.7 Compilation flags - --- 3.8 Dependency tracking - --- 3.9 Custom Rules - --- 3.10 Command change detection - --- 3.11 $(CC) support functions - --- 3.12 $(LD) support functions - --- 3.13 Script Invocation + --- 3.7 Non-builtin vmlinux targets - extra-y + --- 3.8 Always built goals - always- + --- 3.9 Compilation flags + --- 3.10 Dependency tracking + --- 3.11 Custom Rules + --- 3.12 Command change detection + --- 3.13 $(CC) support functions + --- 3.14 $(LD) support functions + --- 3.15 Script Invocation === 4 Host Program support --- 4.1 Simple Host Program @@ -321,7 +323,60 @@ more details, with real examples. names. This allows kbuild to totally skip the directory if the corresponding `CONFIG_` option is neither 'y' nor 'm'. -3.7 Compilation flags +3.7 Non-builtin vmlinux targets - extra-y +- + + extra-y specifies targets which are needed for building vmlinux, + but not combined into built-in.a. + + Examples are: + + 1) head objects + + Some objects must be placed at the head of vmlinux. They are + directly linked to vmlinux without going through built-in.a + A typical use-case is an object that contains the entry point. + + arch/$(SRCARCH)/Makefile should specify such objects as head-y. + + Discussion: + Given that we can control the section order in our linker script, + why do we need head-y? + + 2) vmlinux linker script + + The linker script for vmlinux is located at + arch/$(SRCARCH)/kernel/vmlinux.lds + + Example:: + + # arch/x86/kernel/Makefile + extra-y := head_$(BITS).o + extra-y += head$(BITS).o + extra-y += ebda.o + extra-y += platform-quirks.o + extra-y += vmlinux.lds + + $(extra-y) should only contain targets needed for vmlinux. + + Kbuild skips extra-y when vmlinux is apparently not a final goal. + (e.g. 'make modules', or building external modules) + + If you intend to build targets unconditionally, always-y (explained + in the next section) is the correct syntax to use. + +3.8 Always built goals - always-y +- + + always-y specifies targets which are literally always built when + Kbuild visited the Makefile. + + Example:: + # ./Kbuild + offsets-file := include/generated/asm-offsets.h + always-y += $(offsets-file) + +3.9 Compilation flags - ccflags-y, asflags-y and ldflags-y @@ -410,8 +465,8 @@ more details, with real examples. AFLAGS_iwmmxt.o := -Wa,-mcpu=iwmmxt -3.8 Dependency tracking +3.10 Dependency tracking + Kbuild tracks dependencies on the
[PATCH 4/7] kbuild: doc: merge 'Special Rules' and 'Custom kbuild commands' sections
The two sections "3.10 Special Rules" and "7.8 Custom kbuild commands" are related because you must understand both of them when you write custom rules. Actually I do not understand the policy about what to go into "3 The kbuild files" and what into "7 Architecture Makefile". This commit reworks the custom rule explanation as follows: - Merged "7.8 Custom kbuild commands" into "3.10 Special Rules". - Reword "Special Rules" to "Custom Rules" for consistency. - Update the example for kecho because the blackfin Makefile does not exist any more. - Replace the example for cmd_ with a simpler one. Signed-off-by: Masahiro Yamada --- Documentation/kbuild/makefiles.rst | 88 ++ 1 file changed, 40 insertions(+), 48 deletions(-) diff --git a/Documentation/kbuild/makefiles.rst b/Documentation/kbuild/makefiles.rst index e1aac82ddb9c..f5a983709df7 100644 --- a/Documentation/kbuild/makefiles.rst +++ b/Documentation/kbuild/makefiles.rst @@ -18,7 +18,7 @@ This document describes the Linux kernel Makefiles. --- 3.7 Compilation flags --- 3.8 --- 3.9 Dependency tracking - --- 3.10 Special Rules + --- 3.10 Custom Rules --- 3.11 $(CC) support functions --- 3.12 $(LD) support functions --- 3.13 Script Invocation @@ -46,7 +46,7 @@ This document describes the Linux kernel Makefiles. --- 7.5 Architecture-specific boot images --- 7.6 Building non-kbuild targets --- 7.7 Commands useful for building a boot image - --- 7.8 Custom kbuild commands + --- 7.8 --- 7.9 Preprocessing linker scripts --- 7.10 Generic header files --- 7.11 Post-link pass @@ -422,21 +422,21 @@ more details, with real examples. Thus, if you change an option to $(CC) all affected files will be re-compiled. -3.10 Special Rules +3.10 Custom Rules -- - Special rules are used when the kbuild infrastructure does + Custom rules are used when the kbuild infrastructure does not provide the required support. A typical example is header files generated during the build process. Another example are the architecture-specific Makefiles which - need special rules to prepare boot images etc. + need custom rules to prepare boot images etc. - Special rules are written as normal Make rules. + Custom rules are written as normal Make rules. Kbuild is not executing in the directory where the Makefile is - located, so all special rules shall provide a relative + located, so all custom rules shall use a relative path to prerequisite files and target files. - Two variables are used when defining special rules: + Two variables are used when defining custom rules: $(src) $(src) is a relative path which points to the directory @@ -454,7 +454,7 @@ more details, with real examples. $(obj)/53c8xx_d.h: $(src)/53c7,8xx.scr $(src)/script_asm.pl $(CPP) -DCHIP=810 - < $< | ... $(src)/script_asm.pl - This is a special rule, following the normal syntax + This is a custom rule, following the normal syntax required by make. The target file depends on two prerequisite files. References @@ -471,11 +471,33 @@ more details, with real examples. Example:: - #arch/blackfin/boot/Makefile - $(obj)/vmImage: $(obj)/vmlinux.gz - $(call if_changed,uimage) - @$(kecho) 'Kernel: $@ is ready' + # arch/arm/Makefile + $(BOOT_TARGETS): vmlinux + $(Q)$(MAKE) $(build)=$(boot) MACHINE=$(MACHINE) $(boot)/$@ + @$(kecho) ' Kernel: $(boot)/$@ is ready' + When kbuild is executing with KBUILD_VERBOSE=0, then only a shorthand + of a command is normally displayed. + To enable this behaviour for custom commands kbuild requires + two variables to be set:: + + quiet_cmd_ - what shall be echoed + cmd_ - the command to execute + + Example:: + + # lib/Makefile + quiet_cmd_crc32 = GEN $@ + cmd_crc32 = $< > $@ + + $(obj)/crc32table.h: $(obj)/gen_crc32table + $(call cmd,crc32) + + When updating the $(obj)/crc32table.h target, the line: + + GEN lib/crc32table.h + + will be displayed with "make KBUILD_VERBOSE=0". 3.11 $(CC) support functions @@ -744,7 +766,7 @@ Both possibilities are described in the following. as a prerequisite. This is possible in two ways: - (1) List the prerequisite explicitly in a special rule. + (1) List the prerequisite explicitly in a custom rule.
Re: [PATCH next] mm/swap.c: reduce lock contention in lru_cache_add
在 2020/11/21 上午7:19, Andrew Morton 写道: > On Fri, 20 Nov 2020 16:27:27 +0800 Alex Shi > wrote: > >> The current relock logical will change lru_lock when found a new >> lruvec, so if 2 memcgs are reading file or alloc page at same time, >> they could hold the lru_lock alternately, and wait for each other for >> fairness attribute of ticket spin lock. >> >> This patch will sort that all lru_locks and only hold them once in >> above scenario. That could reduce fairness waiting for lock reget. >> Than, vm-scalability/case-lru-file-readtwice could get ~5% performance >> gain on my 2P*20core*HT machine. > > But what happens when all or most of the pages belong to the same > lruvec? This sounds like the common case - won't it suffer? > Hi Andrew, My testing show no regression on this situation, like original centos7, The most spending time is on lru_lock for lru sensitive case. Thanks Alex
Re: [PATCH v3 6/6] ARM: dts: sun8i: v3s: Add video engine node
On Mon, Nov 16, 2020 at 8:58 PM Martin Cerveny wrote: > > Allwinner V3S SoC has a video engine. > Add a node for it. > > Signed-off-by: Martin Cerveny Acked-by: Chen-Yu Tsai
Re: [PATCH v3 5/6] dt-bindings: media: cedrus: Add V3s compatible
On Mon, Nov 16, 2020 at 8:58 PM Martin Cerveny wrote: > > Allwinner V3s SoC contains video engine. Add compatible for it. > > Signed-off-by: Martin Cerveny Acked-by: Chen-Yu Tsai
RE: [EXT] Re: [PATCH v4 1/4] dt-bindings: soc: imx8m: add DT Binding doc for soc unique ID
> -Original Message- > From: Krzysztof Kozlowski > Sent: 2020年11月20日 18:51 > To: Alice Guo > Cc: robh...@kernel.org; shawn...@kernel.org; s.ha...@pengutronix.de; > dl-linux-imx ; Peng Fan ; > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; > linux-arm-ker...@lists.infradead.org > Subject: [EXT] Re: [PATCH v4 1/4] dt-bindings: soc: imx8m: add DT Binding doc > for soc unique ID > > Caution: EXT Email > > On Fri, Nov 20, 2020 at 06:11:09PM +0800, Alice Guo wrote: > > Add DT Binding doc for the Unique ID of i.MX 8M series. > > > > v2: remove the subject prefix "LF-2571-1" > > v3: put it into Documentation/devicetree/bindings/arm/fsl.yaml > > modify the description of nvmem-cells > > use "make ARCH=arm64 dtbs_check" to test it and fix errors > > v4: use allOf to limit new version DTS files for i.MX8M to include > > "fsl,imx8mm/n/p/q-soc", nvmem-cells and nvmem-cells-names > > > > Signed-off-by: Alice Guo > > --- > > .../devicetree/bindings/arm/fsl.yaml | 51 > +++ > > 1 file changed, 51 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml > > b/Documentation/devicetree/bindings/arm/fsl.yaml > > index 67980dcef66d..d8048323a290 100644 > > --- a/Documentation/devicetree/bindings/arm/fsl.yaml > > +++ b/Documentation/devicetree/bindings/arm/fsl.yaml > > @@ -918,6 +918,57 @@ properties: > >- fsl,s32v234-evb # S32V234-EVB2 Customer > Evaluation Board > >- const: fsl,s32v234 > > > > + soc: > > +type: object > > +properties: > > + compatible: > > +oneOf: > > + - description: new version compatible for i.MX8M SoCs > > +items: > > + - enum: > > + - fsl,imx8mm-soc > > + - fsl,imx8mn-soc > > + - fsl,imx8mp-soc > > + - fsl,imx8mq-soc > > + - const: simple-bus > > + > > + - description: old version compatible for i.MX8M SoCs > > +items: > > + - const: simple-bus > > + > > + nvmem-cells: > > +maxItems: 1 > > +description: Phandle to the SOC Unique ID provided by a nvmem > > + node > > + > > + nvmem-cells-names: > > +const: soc_unique_id > > + > > +allOf: > > Nothing changed here comparing to previous version. Still does not work. > > The allOf should not be part of soc node because the "if" below won't match. > Instead, it should be against root node. > > Best regards, > Krzysztof I'm sorry to disturb you. I don't very clear about the grammar rules of yaml, so don't know how to make allOf be part of root node. If allof is part of root node, how does it specify the soc node? The following is my change which is definitely wrong. soc: properties: compatible: - description: new version compatible for i.MX8M SoCs items: - enum: - fsl,imx8mm-soc - fsl,imx8mn-soc - fsl,imx8mp-soc - fsl,imx8mq-soc - const: simple-bus nvmem-cells: maxItems: 1 description: Phandle to the SOC Unique ID provided by a nvmem node nvmem-cells-names: const: soc_unique_id allOf: - if: properties: compatible: contains: enum: - fsl,imx8mm - fsl,imx8mn - fsl,imx8mp - fsl,imx8mq then: required: - soc Please give me suggestion. Thank you. Best regards, Alice Guo > > + - if: > > + properties: > > +compatible: > > + contains: > > +enum: > > + - fsl,imx8mm > > + - fsl,imx8mn > > + - fsl,imx8mp > > + - fsl,imx8mq > > + > > +then: > > + properties: > > +compatible: > > + items: > > +- enum: > > +- fsl,imx8mm-soc > > +- fsl,imx8mn-soc > > +- fsl,imx8mp-soc > > +- fsl,imx8mq-soc > > +- const: simple-bus > > + > > + required: > > +- nvmem-cells > > +- nvmem-cells-names > > + > > additionalProperties: true > > > > ... > > -- > > 2.17.1 > >
Re: [PATCH] ARM: dts: mvebu: Add device tree for RD-AC3X-48G4X2XL board
Hi Aryan,
On 23/11/20 4:52 pm, Aryan Srivastava wrote:
> Add device tree for RD-AC3X-48G4X2XL board. This has a Armada 382 SoC on
> a interposer board connected to a baseboard with a Prestera AC3X ASIC
> connected via PCI.
>
> Signed-off-by: Aryan Srivastava
Reviewed-by: Chris Packham
> ---
> arch/arm/boot/dts/Makefile| 1 +
> .../boot/dts/armada-382-rd-ac3x-48g4x2xl.dts | 114 ++
> 2 files changed, 115 insertions(+)
> create mode 100644 arch/arm/boot/dts/armada-382-rd-ac3x-48g4x2xl.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index ce66ffd5a1bb..a60407ad7347 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -1319,6 +1319,7 @@ dtb-$(CONFIG_MACH_ARMADA_370) += \
> dtb-$(CONFIG_MACH_ARMADA_375) += \
> armada-375-db.dtb
> dtb-$(CONFIG_MACH_ARMADA_38X) += \
> + armada-382-rd-ac3x-48g4x2xl.dtb \
> armada-385-clearfog-gtr-s4.dtb \
> armada-385-clearfog-gtr-l8.dtb \
> armada-385-db-88f6820-amc.dtb \
> diff --git a/arch/arm/boot/dts/armada-382-rd-ac3x-48g4x2xl.dts
> b/arch/arm/boot/dts/armada-382-rd-ac3x-48g4x2xl.dts
> new file mode 100644
> index ..b08d662a8519
> --- /dev/null
> +++ b/arch/arm/boot/dts/armada-382-rd-ac3x-48g4x2xl.dts
> @@ -0,0 +1,114 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> +/*
> + * Device Tree file for Marvell Armada 382 reference board
> + * (RD-AC3X-48G4X2XL)
> + *
> + * Copyright (C) 2020 Allied Telesis Labs
> + */
> +
> +/dts-v1/;
> +#include "armada-385.dtsi"
> +
> +#include
> +
> +/ {
> + model = "Marvell Armada 382 RD-AC3X";
> + compatible = "marvell,rd-ac3x-48g4x2xl", "marvell,rd-ac3x",
> + "marvell,armada385", "marvell,armada380";
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +
> + aliases {
> + ethernet0 =
> + };
> +
> + memory {
> + device_type = "memory";
> + reg = <0x 0x2000>; /* 512MB */
> + };
> +
> + soc {
> + ranges = + MBUS_ID(0x01, 0x1d) 0 0xfff0 0x10>;
> + };
> +};
> +
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins>;
> + status = "okay";
> +
> + eeprom@53{
> + compatible = "atmel,24c64";
> + reg = <0x53>;
> + };
> +// cpld@3c{
> +// compatible = "marvell,ac3x-cpld";
> +// reg = <0x3c>;
> +// };
> +};
Question for the mvebu maintainers: We know there is a cpld with that
can be interfaced with over i2c. Other than detecting that it shows up
on the i2c bus we haven't done anything with it. We believe it
interfaces with some discrete IO and might mux the i2c interface towards
the SFP/QSFP cages.
Obviously there isn't a "marvell,ac3x-cpld" driver (yet) so I suggested
to Aryan that we put it in the dts to document its existence but leave
it commented out for now. Is this OK?
> +
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins>;
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> + phy = <>;
> + phy-mode = "rgmii-id";
> +};
> +
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins>;
> +
> + phy0: ethernet-phy@0 {
> + reg = <0>;
> + };
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + /* Port 0, Lane 0 */
> + status = "okay";
> +};
> +
> +_controller {
> + status = "okay";
> +
> + nand@0 {
> + reg = <0>;
> + label = "pxa3xx_nand-0";
> + nand-rb = <0>;
> + nand-on-flash-bbt;
> +
> + partitions {
> + compatible = "fixed-partitions";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + partition@0 {
> + reg = <0x 0x0050>;
> + label = "u-boot";
> + };
> + partition@50{
> + reg = <0x0050 0x0040>;
> + label = "u-boot env";
> + };
> + partition@90{
> + reg = <0x0090 0x3F70>;
> + label = "user";
> + };
> + };
> + };
> +};
> +
> + {
> + clock-frequency = <2>;
> +};
[PATCH] arm64/fpsimd: add to to fix fpsimd build
Adding brought in which uses
, which uses 'pstate_check_t' so the latter needs to
#include for this typedef.
Fixes this build error:
In file included from arch/arm64/include/asm/kprobes.h:24,
from arch/arm64/include/asm/exception.h:11,
from arch/arm64/kernel/fpsimd.c:35:
arch/arm64/include/asm/probes.h:16:2: error: unknown type name
'pstate_check_t'
16 | pstate_check_t *pstate_cc;
Fixes: c6b90d5cf637 ("arm64/fpsimd: Fix missing-prototypes in fpsimd.c")
Signed-off-by: Randy Dunlap
Reported-by: kernel test robot
Cc: Will Deacon
Cc: Tian Tao
---
arch/arm64/include/asm/probes.h |2 ++
1 file changed, 2 insertions(+)
--- linux-next-20201120.orig/arch/arm64/include/asm/probes.h
+++ linux-next-20201120/arch/arm64/include/asm/probes.h
@@ -7,6 +7,8 @@
#ifndef _ARM_PROBES_H
#define _ARM_PROBES_H
+#include
+
typedef u32 probe_opcode_t;
typedef void (probes_handler_t) (u32 opcode, long addr, struct pt_regs *);
