Re: [RFC PATCH 3/5] documention: leds: Add multicolor class documentation
On Mon, 1 Apr 2019 23:27:10 +0200 Pavel Machek wrote: > One was discussed before -- have single file which contains > coefficients for r/g/b channels. That would somehow break the rule one file/one value. Although you could consider the whole color one value, that way it would not be broken...
[PATCH v4] arm/mach-at91/pm : fix possible object reference leak
of_find_device_by_node() takes a reference to the struct device
when it finds a match via get_device. When returning error we should
call put_device.
Reviewed-by: Mukesh Ojha
Signed-off-by: Peng Hao
---
arch/arm/mach-at91/pm.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
index 51e808a..38511a5 100644
--- a/arch/arm/mach-at91/pm.c
+++ b/arch/arm/mach-at91/pm.c
@@ -591,13 +591,13 @@ static int __init at91_pm_backup_init(void)
np = of_find_compatible_node(NULL, NULL, "atmel,sama5d2-securam");
if (!np)
- goto securam_fail;
+ goto securam_fail_no_ref_dev;
pdev = of_find_device_by_node(np);
of_node_put(np);
if (!pdev) {
pr_warn("%s: failed to find securam device!\n", __func__);
- goto securam_fail;
+ goto securam_fail_no_ref_dev;
}
sram_pool = gen_pool_get(>dev, NULL);
@@ -620,6 +620,8 @@ static int __init at91_pm_backup_init(void)
return 0;
securam_fail:
+ put_device(>dev);
+securam_fail_no_ref_dev:
iounmap(pm_data.sfrbu);
pm_data.sfrbu = NULL;
return ret;
--
1.8.3.1
[PATCH v5] HID: intel-ish-hid: ISH firmware loader client driver
This driver adds support for loading Intel Integrated Sensor Hub (ISH) firmware from host file system to ISH SRAM and start execution. At power-on, the ISH subsystem shall boot to an interim Shim loader-firmware, which shall expose an ISHTP loader device. The driver implements an ISHTP client that communicates with the Shim ISHTP loader device over the intel-ish-hid stack, to download the main ISH firmware. Signed-off-by: Rushikesh S Kadam Acked-by: Srinivas Pandruvada Acked-by: Nick Crews Tested-by: Jett Rink --- The patches are baselined to hid git tree, branch for-5.2/ish https://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git/log/?h=for-5.2/ish v5 - Added the Acked-by & Tested-by to commit message. No other change. v4 - Changed process_recv() to wake the caller in case of error as well. Earlier caller would wait until timeout on an error. - Change sequence of few checks in process_recv(). v3 - Moved a couple of sanity checks from loader_cl_send() to process_recv(). - Several minor changes to address review comments. v2 - Change loader_cl_send() so that the calling function shall allocate and pass the buffer to be used for receiving firwmare response data. Corresponding changes in calling function and process_recv(). - Introduced struct response_info to encapsulate and pass data between from the process_recv() callback to calling function loader_cl_send(). - Keep count of host firmware load retries, and fail after 3 unsuccessful attempts. - Dropped report_bad_packets() function previously used for keeping count of bad packets. - Inlined loader_ish_hw_reset()'s functionality v1 - Initial version. drivers/hid/Makefile|1 + drivers/hid/intel-ish-hid/Kconfig | 15 + drivers/hid/intel-ish-hid/Makefile |3 + drivers/hid/intel-ish-hid/ishtp-fw-loader.c | 1085 +++ 4 files changed, 1104 insertions(+) create mode 100644 drivers/hid/intel-ish-hid/ishtp-fw-loader.c diff --git a/drivers/hid/Makefile b/drivers/hid/Makefile index 170163b..d8d393e 100644 --- a/drivers/hid/Makefile +++ b/drivers/hid/Makefile @@ -134,3 +134,4 @@ obj-$(CONFIG_USB_KBD) += usbhid/ obj-$(CONFIG_I2C_HID) += i2c-hid/ obj-$(CONFIG_INTEL_ISH_HID)+= intel-ish-hid/ +obj-$(INTEL_ISH_FIRMWARE_DOWNLOADER) += intel-ish-hid/ diff --git a/drivers/hid/intel-ish-hid/Kconfig b/drivers/hid/intel-ish-hid/Kconfig index 519e4c8..786adbc 100644 --- a/drivers/hid/intel-ish-hid/Kconfig +++ b/drivers/hid/intel-ish-hid/Kconfig @@ -14,4 +14,19 @@ config INTEL_ISH_HID Broxton and Kaby Lake. Say Y here if you want to support Intel ISH. If unsure, say N. + +config INTEL_ISH_FIRMWARE_DOWNLOADER + tristate "Host Firmware Load feature for Intel ISH" + depends on INTEL_ISH_HID + depends on X86 + help + The Integrated Sensor Hub (ISH) enables the kernel to offload + sensor polling and algorithm processing to a dedicated low power + processor in the chipset. + + The Host Firmware Load feature adds support to load the ISH + firmware from host file system at boot. + + Say M here if you want to support Host Firmware Loading feature + for Intel ISH. If unsure, say N. endmenu diff --git a/drivers/hid/intel-ish-hid/Makefile b/drivers/hid/intel-ish-hid/Makefile index 825b70a..2de97e4 100644 --- a/drivers/hid/intel-ish-hid/Makefile +++ b/drivers/hid/intel-ish-hid/Makefile @@ -20,4 +20,7 @@ obj-$(CONFIG_INTEL_ISH_HID) += intel-ishtp-hid.o intel-ishtp-hid-objs := ishtp-hid.o intel-ishtp-hid-objs += ishtp-hid-client.o +obj-$(CONFIG_INTEL_ISH_FIRMWARE_DOWNLOADER) += intel-ishtp-loader.o +intel-ishtp-loader-objs += ishtp-fw-loader.o + ccflags-y += -Idrivers/hid/intel-ish-hid/ishtp diff --git a/drivers/hid/intel-ish-hid/ishtp-fw-loader.c b/drivers/hid/intel-ish-hid/ishtp-fw-loader.c new file mode 100644 index 000..e770e22 --- /dev/null +++ b/drivers/hid/intel-ish-hid/ishtp-fw-loader.c @@ -0,0 +1,1085 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * ISH-TP client driver for ISH firmware loading + * + * Copyright (c) 2019, Intel Corporation. + */ + +#include +#include +#include +#include +#include +#include + +/* Number of times we attempt to load the firmware before giving up */ +#define MAX_LOAD_ATTEMPTS 3 + +/* ISH TX/RX ring buffer pool size */ +#define LOADER_CL_RX_RING_SIZE 1 +#define LOADER_CL_TX_RING_SIZE 1 + +/* + * ISH Shim firmware loader reserves 4 Kb buffer in SRAM. The buffer is + * used to temporarily hold the data transferred from host to Shim + * firmware loader. Reason for the odd size of 3968 bytes? Each IPC + * transfer is 128 bytes (= 4 bytes header + 124 bytes payload). So the + * 4 Kb buffer can hold maximum of 32 IPC transfers, which means we can + * have a max payload of 3968 bytes (= 32 x 124 payload). + */ +#define
Applied "ASoC: dpcm: skip missing substream while applying symmetry" to the asoc tree
The patch
ASoC: dpcm: skip missing substream while applying symmetry
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 6246f283d5e02ac757bd8d9bacde8fdc54c4582d Mon Sep 17 00:00:00 2001
From: Jerome Brunet
Date: Mon, 1 Apr 2019 15:03:54 +0200
Subject: [PATCH] ASoC: dpcm: skip missing substream while applying symmetry
If for any reason, the backend does not have the requested substream
(like capture on a playback only backend), the BE will be skipped in
dpcm_be_dai_startup().
However, dpcm_apply_symmetry() does not skip those BE and will
dereference the be_substream (NULL) pointer anyway.
Like in dpcm_be_dai_startup(), just skip those BE.
Fixes: 906c7d690c3b ("ASoC: dpcm: Apply symmetry for DPCM")
Signed-off-by: Jerome Brunet
Signed-off-by: Mark Brown
---
sound/soc/soc-pcm.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/sound/soc/soc-pcm.c b/sound/soc/soc-pcm.c
index 7fe5321000e8..2d5d5cac4ba6 100644
--- a/sound/soc/soc-pcm.c
+++ b/sound/soc/soc-pcm.c
@@ -1911,10 +1911,15 @@ static int dpcm_apply_symmetry(struct snd_pcm_substream
*fe_substream,
struct snd_soc_pcm_runtime *be = dpcm->be;
struct snd_pcm_substream *be_substream =
snd_soc_dpcm_get_substream(be, stream);
- struct snd_soc_pcm_runtime *rtd = be_substream->private_data;
+ struct snd_soc_pcm_runtime *rtd;
struct snd_soc_dai *codec_dai;
int i;
+ /* A backend may not have the requested substream */
+ if (!be_substream)
+ continue;
+
+ rtd = be_substream->private_data;
if (rtd->dai_link->be_hw_params_fixup)
continue;
--
2.20.1
Applied "regulator: bcm590xx: Convert to use simplified DT parsing" to the regulator tree
The patch
regulator: bcm590xx: Convert to use simplified DT parsing
has been applied to the regulator tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From a4e73625cb12f662b2a72d292f34232c61cca47f Mon Sep 17 00:00:00 2001
From: Axel Lin
Date: Mon, 1 Apr 2019 22:42:36 +0800
Subject: [PATCH] regulator: bcm590xx: Convert to use simplified DT parsing
Use regulator core's simplified DT parsing code to simply the driver
implementation.
Signed-off-by: Axel Lin
Signed-off-by: Mark Brown
---
drivers/regulator/bcm590xx-regulator.c | 105 +
1 file changed, 2 insertions(+), 103 deletions(-)
diff --git a/drivers/regulator/bcm590xx-regulator.c
b/drivers/regulator/bcm590xx-regulator.c
index e49c0a7d5dd5..85ccc93b2bb6 100644
--- a/drivers/regulator/bcm590xx-regulator.c
+++ b/drivers/regulator/bcm590xx-regulator.c
@@ -103,10 +103,6 @@
((n > BCM590XX_REG_VSR) && (n < BCM590XX_REG_VBUS))
#define BCM590XX_REG_IS_VBUS(n)(n == BCM590XX_REG_VBUS)
-struct bcm590xx_board {
- struct regulator_init_data *bcm590xx_pmu_init_data[BCM590XX_NUM_REGS];
-};
-
/* LDO group A: supported voltages in microvolts */
static const unsigned int ldo_a_table[] = {
120, 180, 250, 270, 280,
@@ -280,105 +276,15 @@ static const struct regulator_ops bcm590xx_ops_vbus = {
.disable= regulator_disable_regmap,
};
-#define BCM590XX_MATCH(_name, _id) \
- { \
- .name = #_name, \
- .driver_data = (void *)_regs[BCM590XX_REG_##_id], \
- }
-
-static struct of_regulator_match bcm590xx_matches[] = {
- BCM590XX_MATCH(rfldo, RFLDO),
- BCM590XX_MATCH(camldo1, CAMLDO1),
- BCM590XX_MATCH(camldo2, CAMLDO2),
- BCM590XX_MATCH(simldo1, SIMLDO1),
- BCM590XX_MATCH(simldo2, SIMLDO2),
- BCM590XX_MATCH(sdldo, SDLDO),
- BCM590XX_MATCH(sdxldo, SDXLDO),
- BCM590XX_MATCH(mmcldo1, MMCLDO1),
- BCM590XX_MATCH(mmcldo2, MMCLDO2),
- BCM590XX_MATCH(audldo, AUDLDO),
- BCM590XX_MATCH(micldo, MICLDO),
- BCM590XX_MATCH(usbldo, USBLDO),
- BCM590XX_MATCH(vibldo, VIBLDO),
- BCM590XX_MATCH(csr, CSR),
- BCM590XX_MATCH(iosr1, IOSR1),
- BCM590XX_MATCH(iosr2, IOSR2),
- BCM590XX_MATCH(msr, MSR),
- BCM590XX_MATCH(sdsr1, SDSR1),
- BCM590XX_MATCH(sdsr2, SDSR2),
- BCM590XX_MATCH(vsr, VSR),
- BCM590XX_MATCH(gpldo1, GPLDO1),
- BCM590XX_MATCH(gpldo2, GPLDO2),
- BCM590XX_MATCH(gpldo3, GPLDO3),
- BCM590XX_MATCH(gpldo4, GPLDO4),
- BCM590XX_MATCH(gpldo5, GPLDO5),
- BCM590XX_MATCH(gpldo6, GPLDO6),
- BCM590XX_MATCH(vbus, VBUS),
-};
-
-static struct bcm590xx_board *bcm590xx_parse_dt_reg_data(
- struct platform_device *pdev,
- struct of_regulator_match **bcm590xx_reg_matches)
-{
- struct bcm590xx_board *data;
- struct device_node *np = pdev->dev.parent->of_node;
- struct device_node *regulators;
- struct of_regulator_match *matches = bcm590xx_matches;
- int count = ARRAY_SIZE(bcm590xx_matches);
- int idx = 0;
- int ret;
-
- if (!np) {
- dev_err(>dev, "of node not found\n");
- return NULL;
- }
-
- data = devm_kzalloc(>dev, sizeof(*data), GFP_KERNEL);
- if (!data)
- return NULL;
-
- np = of_node_get(np);
- regulators = of_get_child_by_name(np, "regulators");
- if (!regulators) {
- dev_warn(>dev, "regulator node not found\n");
- return NULL;
- }
-
- ret = of_regulator_match(>dev, regulators, matches, count);
- of_node_put(regulators);
- if (ret < 0) {
- dev_err(>dev, "Error parsing regulator init data: %d\n",
- ret);
- return NULL;
- }
-
- *bcm590xx_reg_matches = matches;
-
- for (idx = 0; idx < count; idx++) {
- if (!matches[idx].init_data || !matches[idx].of_node)
- continue;
-
- data->bcm590xx_pmu_init_data[idx] = matches[idx].init_data;
- }
-
- return data;
-}
-
static int
Re: [RFC PATCH 5/5] leds: multicolor: Introduce a multicolor class definition
Hi Dan,
On Mon, 1 Apr 2019 12:34:00 -0500
Dan Murphy wrote:
> +static ssize_t sync_store(struct device *dev,
> + struct device_attribute *sync_attr,
> + const char *buf, size_t size)
> +{
> + struct led_classdev_mc_data *data = container_of(sync_attr,
> + struct
> led_classdev_mc_data,
> + sync_attr);
> + struct led_classdev_mc *mcled_cdev = data->mcled_cdev;
> + struct led_classdev *led_cdev = _cdev->led_cdev;
> + const struct led_multicolor_ops *ops = mcled_cdev->ops;
> + struct led_classdev_mc_priv *priv;
> + unsigned long sync_value;
> + ssize_t ret = -EINVAL;
> +
> + mutex_lock(_cdev->led_access);
> +
> + if (!mcled_cdev->sync_enabled)
> + goto unlock;
This lock is redundant, you could just put
if (mcled_cdev->sync_enabled)
return ret;
before the lock.
Re: [BUG] gpiolib: spi chip select legacy support breaks modern chip select and whitens the GTA04 LCD panel
On Tue, Apr 02, 2019 at 07:05:35AM +0200, H. Nikolaus Schaller wrote: > > Am 02.04.2019 um 06:02 schrieb Linus Walleij : Please delete unneeded context from mails when replying. Doing this makes it much easier to find your reply in the message, helping ensure it won't be missed by people scrolling through the irrelevant quoted material. > >>> This does not work because there are devices that requires spi-cs-high to > >>> be > >>> respected and the DTS second cell GPIO flag to be ignored. > >> Then, those should be fixed... > > This can't be done because some old systems (mostly powerpc) > > added between 2008-2013 do not know about GPIO flags and > > have DTBs deployed in firmware that need to keep working. > > They cannot be fixed. > The question is if it is even possible to deploy a new kernel > for such devices and if anyone wants to do... It's relatively common, especially with older devices, for people to be perfectly happy to update the kernel and do so frequently but unwilling to update the bootloader as the procedure for recovering a broken bootloader is difficult or perhaps not even possible. > This also gives another idea: make it depend on "powerpc". That won't fly, the code has always been architecture neutral. > > Dunno about this, it looks fragile, I would prefer to keep all working. > > But I will listen to reason. > Reason why I propose a CONFIG option is: > if someone is able to compile and deploy a v5.1 kernel for some device which > has (old) and problematic DTB in ROM he/she must have access to the .config. > So it is easy to modify it to enable legacy handling of spi-cs-high. And keep > it disabled for all others. This assumes people aren't able to run a distro kernel... signature.asc Description: PGP signature
Re: [PATCH 2/2] iio: counter: Add support for Milbeaut Updown Counter
Hi Jonathan,
Thank you for your review.
On 2019/03/31 3:43, Jonathan Cameron wrote:
On Tue, 26 Mar 2019 15:33:32 +0900
Shinji Kanematsu wrote:
Add support for Milbeaut Updown Counter, that can be used as counter
or quadrature encoder.
Signed-off-by: Shinji Kanematsu
A few minor comments inline. The counter subsystem will provide a cleaner
way of describing this. Please look to that for v2.
Hopefully William will give some feedback as well.
OK, I understand.
Jonathan
---
drivers/iio/counter/Kconfig | 12 +
drivers/iio/counter/Makefile | 1 +
drivers/iio/counter/milbeaut-updown.h | 38 +++
drivers/iio/counter/milbeaut-updown_cnt.c | 385 ++
4 files changed, 436 insertions(+)
create mode 100644 drivers/iio/counter/milbeaut-updown.h
create mode 100644 drivers/iio/counter/milbeaut-updown_cnt.c
diff --git a/drivers/iio/counter/Kconfig b/drivers/iio/counter/Kconfig
index bf1e559..a665f61 100644
--- a/drivers/iio/counter/Kconfig
+++ b/drivers/iio/counter/Kconfig
@@ -31,4 +31,16 @@ config STM32_LPTIMER_CNT
To compile this driver as a module, choose M here: the
module will be called stm32-lptimer-cnt.
+
+config MILBEAUT_UPDOWN_CNT
+ tristate "Milbeaut Updown Counter driver"
+ depends on OF
+ depends on ARCH_MILBEAUT || COMPILE_TEST
+ help
+ Select this option to enable Milbeaut Updown Counter quadrature
encoder
+ and counter driver.
+
+ To compile this driver as a module, choose M here: the
+ module will be called milbeaut-updown-cnt.
+
endmenu
diff --git a/drivers/iio/counter/Makefile b/drivers/iio/counter/Makefile
index 1b9a896..0cb708b 100644
--- a/drivers/iio/counter/Makefile
+++ b/drivers/iio/counter/Makefile
@@ -6,3 +6,4 @@
obj-$(CONFIG_104_QUAD_8) += 104-quad-8.o
obj-$(CONFIG_STM32_LPTIMER_CNT) += stm32-lptimer-cnt.o
+obj-$(CONFIG_MILBEAUT_UPDOWN_CNT) += milbeaut-updown_cnt.o
diff --git a/drivers/iio/counter/milbeaut-updown.h
b/drivers/iio/counter/milbeaut-updown.h
new file mode 100644
index 000..9a038ad
--- /dev/null
+++ b/drivers/iio/counter/milbeaut-updown.h
@@ -0,0 +1,38 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Milbeaut Updown parent driver
+ * Copyright (C) 2019 Socionext Inc.
+ */
+
+#ifndef _LINUX_MILBEAUT_UPDOWN_H_
+#define _LINUX_MILBEAUT_UPDOWN_H_
+
+#define MLB_UPDOWN_UDCR0x0 /* Updown Count Reg
*/
+#define MLB_UPDOWN_RCR 0x4 /* Reload Compare Reg */
+#define MLB_UPDOWN_CSR 0xC /* Counter Status Reg */
+#define MLB_UPDOWN_CCR 0x14/* Counter Control Reg */
+
+/* MLB_UPDOWN_CSR - bit fields */
+#define MLB_UPDOWN_CSTRBIT(7)
+#define MLB_UPDOWN_UDIEBIT(5)
+#define MLB_UPDOWN_CMPFBIT(4)
+#define MLB_UPDOWN_OVFFBIT(3)
+#define MLB_UPDOWN_UDFFBIT(2)
+
+/* MLB_UPDOWN_CCR - bit fields */
+#define MLB_UPDOWN_FIXED BIT(15)
+#define MLB_UPDOWN_CMS GENMASK(11, 10)
+#define MLB_UPDOWN_CES GENMASK(9, 8)
+#define MLB_UPDOWN_CTUTBIT(6)
+#define MLB_UPDOWN_RLDEBIT(4)
+
+/* MLB_UPDOWN max count value */
+#define MLB_UPDOWN_MAX_COUNT 0x
+
+/* MLB_UPDOWN rising edge detection */
+#define MLB_UPDOWN_RISING_EDGE BIT(9)
+
+/* MLB_UPDOWN mode */
+#define MLB_UPDOWN_MODE1
+
+#endif
diff --git a/drivers/iio/counter/milbeaut-updown_cnt.c
b/drivers/iio/counter/milbeaut-updown_cnt.c
new file mode 100644
index 000..a58709a
--- /dev/null
+++ b/drivers/iio/counter/milbeaut-updown_cnt.c
@@ -0,0 +1,385 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Milbeaut Updown counter driver
+ *
+ * Copyright (C) 2019 Socionext Inc.
I'm fussy about pointless lines. The one below doesn't add anything ;)
That's right, correct it.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "milbeaut-updown.h"
+
+#define MILBEAUT_UPDOWN_IRQ_NAME "milbeaut_updown_event"
+#define MILBEAUT_UPDOWN_MAX_REGISTER 0x1f
+
+static const struct regmap_config milbeaut_updown_regmap_cfg = {
+ .reg_bits = 32,
+ .val_bits = 32,
+ .reg_stride = sizeof(u32),
+ .max_register = MILBEAUT_UPDOWN_MAX_REGISTER,
+};
+struct milbeaut_updown_cnt {
+ struct device *dev;
+ struct regmap *regmap;
+ struct clk *clk;
+ u32 preset;
+ u32 polarity;
+ u32 quadrature_mode;
+};
+
+static int milbeaut_updown_is_enabled(struct milbeaut_updown_cnt *priv)
+{
+ u32 val;
+ int ret;
+
+ ret = regmap_read(priv->regmap, MLB_UPDOWN_CSR, );
+ if (ret)
+ return ret;
+
+ return FIELD_GET(MLB_UPDOWN_CSTR, val);
+}
+
+static int milbeaut_updown_setup(struct milbeaut_updown_cnt *priv,
+ int
[PATCH V1] mmc: tegra: add sdhci tegra suspend and resume
This patch adds suspend and resume PM ops for tegra SDHCI.
Signed-off-by: Sowjanya Komatineni
---
drivers/mmc/host/sdhci-tegra.c | 45 +-
1 file changed, 44 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/sdhci-tegra.c b/drivers/mmc/host/sdhci-tegra.c
index eafaaefab4a6..68263ea4a93e 100644
--- a/drivers/mmc/host/sdhci-tegra.c
+++ b/drivers/mmc/host/sdhci-tegra.c
@@ -1611,11 +1611,54 @@ static int sdhci_tegra_remove(struct platform_device
*pdev)
return 0;
}
+#ifdef CONFIG_PM_SLEEP
+static int sdhci_tegra_suspend(struct device *dev)
+{
+ struct sdhci_host *host = dev_get_drvdata(dev);
+ struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+ int ret;
+
+ if (host->mmc->caps2 & MMC_CAP2_CQE) {
+ ret = cqhci_suspend(host->mmc);
+ if (ret)
+ return ret;
+ }
+
+ ret = sdhci_suspend_host(host);
+ if (ret)
+ return ret;
+
+ clk_disable_unprepare(pltfm_host->clk);
+ return 0;
+}
+
+static int sdhci_tegra_resume(struct device *dev)
+{
+ struct sdhci_host *host = dev_get_drvdata(dev);
+ struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+ int ret;
+
+ clk_prepare_enable(pltfm_host->clk);
+
+ ret = sdhci_resume_host(host);
+ if (ret)
+ return ret;
+
+ if (host->mmc->caps2 & MMC_CAP2_CQE)
+ return cqhci_resume(host->mmc);
+
+ return 0;
+}
+#endif
+
+static SIMPLE_DEV_PM_OPS(sdhci_tegra_dev_pm_ops, sdhci_tegra_suspend,
+sdhci_tegra_resume);
+
static struct platform_driver sdhci_tegra_driver = {
.driver = {
.name = "sdhci-tegra",
.of_match_table = sdhci_tegra_dt_match,
- .pm = _pltfm_pmops,
+ .pm = _tegra_dev_pm_ops,
},
.probe = sdhci_tegra_probe,
.remove = sdhci_tegra_remove,
--
2.7.4
Re: [PATCH] lib: Fix possible incorrect result from rational fractions helper
On Sat, 30 Mar 2019 13:58:55 -0700 Trent Piepho wrote: > In some cases the previous algorithm would not return the closest > approximation. This would happen when a semi-convergent was the > closest, as the previous algorithm would only consider convergents. > > As an example, consider an initial value of 5/4, and trying to find the > closest approximation with a maximum of 4 for numerator and denominator. > The previous algorithm would return 1/1 as the closest approximation, > while this version will return the correct answer of 4/3. > > To do this, the main loop performs effectively the same operations as it > did before. It must now keep track of the last three approximations, > n2/d2 .. n0/d0, while before it only needed the last two. > > If an exact answer is not found, the algorithm will now calculate the > best semi-convergent term, t, which is a single expression with two > divisions: > min((max_numerator - n0) / n1, (max_denominator - d0) / d1) > > This will be used if it is better than previous convergent. The test > for this is generally a simple comparison, 2*t > a. But in an edge > case, where the convergent's final term is even and the best allowable > semi-convergent has a final term of exactly half the convergent's final > term, the more complex comparison (d0*dp > d1*d) is used. > > I also wrote some comments explaining the code. While one still needs > to look up the math elsewhere, they should help a lot to follow how the > code relates to that math. What are the userspace-visible runtime effects of this change?
Re: [PATCHv3] x86/boot/KASLR: skip the specified crashkernel region
On Tue, Apr 02, 2019 at 12:10:46PM +0800, Pingfan Liu wrote:
>crashkernel=x@y or or =range1:size1[,range2:size2,...]@offset option may
or or?
>fail to reserve the required memory region if KASLR puts kernel into the
>region. To avoid this uncertainty, asking KASLR to skip the required
>region.
>
>Signed-off-by: Pingfan Liu
>Cc: Thomas Gleixner
>Cc: Ingo Molnar
>Cc: Borislav Petkov
>Cc: "H. Peter Anvin"
>Cc: Baoquan He
>Cc: Will Deacon
>Cc: Nicolas Pitre
>Cc: Pingfan Liu
>Cc: Chao Fan
>Cc: "Kirill A. Shutemov"
>Cc: Ard Biesheuvel
>Cc: linux-kernel@vger.kernel.org
>---
[...]
>+
>+/* handle crashkernel=x@y or =range1:size1[,range2:size2,...]@offset options
>*/
Before review, I want to say more about the background.
It's very hard to review the code for someone who is not so familiar
with kdump, so could you please explain more ahout
the uasge of crashkernel=range1:size1[,range2:size2,...]@offset.
And also there are so many jobs who are parsing string. So I really
need your help to understand the PATCH.
>+static void mem_avoid_specified_crashkernel_region(char *option)
>+{
>+ unsigned long long crash_size, crash_base = 0;
>+ char*first_colon, *first_space, *cur = option;
Is there a tab after char?
>+
>+ first_colon = strchr(option, ':');
>+ first_space = strchr(option, ' ');
>+ /* if contain ":" */
>+ if (first_colon && (!first_space || first_colon < first_space)) {
>+ int i;
>+ u64 total_sz = 0;
>+ struct boot_e820_entry *entry;
>+
>+ for (i = 0; i < boot_params->e820_entries; i++) {
>+ entry = _params->e820_table[i];
>+ /* Skip non-RAM entries. */
>+ if (entry->type != E820_TYPE_RAM)
>+ continue;
>+ total_sz += entry->size;
I wonder whether it's needed to consider the memory ranges here.
I think it's OK to only record the regions should to be avoid.
I remeber I ever talked with Baoquan about the similiar problems.
@Baoquan, I am not sure if I misunderstand something.
Thanks,
Chao Fan
>+ }
>+ handle_crashkernel_mem(option, total_sz, _size,
>+ _base);
>+ } else {
>+ crash_size = memparse(option, );
>+ if (option == cur)
>+ return;
>+ while (*cur && *cur != ' ' && *cur != '@')
>+ cur++;
>+ if (*cur == '@') {
>+ option = cur + 1;
>+ crash_base = memparse(option, );
>+ }
>+ }
>+ if (crash_base) {
>+ mem_avoid[MEM_AVOID_CRASHKERNEL].start = crash_base;
>+ mem_avoid[MEM_AVOID_CRASHKERNEL].size = crash_size;
>+ } else {
>+ /*
>+ * Clearing mem_avoid if no offset is given. This is consistent
>+ * with kernel, which uses the last crashkernel= option.
>+ */
>+ mem_avoid[MEM_AVOID_CRASHKERNEL].start = 0;
>+ mem_avoid[MEM_AVOID_CRASHKERNEL].size = 0;
>+ }
>+}
>
> static void handle_mem_options(void)
> {
>@@ -248,7 +358,7 @@ static void handle_mem_options(void)
> u64 mem_size;
>
> if (!strstr(args, "memmap=") && !strstr(args, "mem=") &&
>- !strstr(args, "hugepages"))
>+ !strstr(args, "hugepages") && !strstr(args, "crashkernel="))
> return;
>
> tmp_cmdline = malloc(len + 1);
>@@ -284,6 +394,8 @@ static void handle_mem_options(void)
> goto out;
>
> mem_limit = mem_size;
>+ } else if (strstr(param, "crashkernel")) {
>+ mem_avoid_specified_crashkernel_region(val);
> }
> }
>
>@@ -412,7 +524,7 @@ static void mem_avoid_init(unsigned long input, unsigned
>long input_size,
>
> /* We don't need to set a mapping for setup_data. */
>
>- /* Mark the memmap regions we need to avoid */
>+ /* Mark the regions we need to avoid */
> handle_mem_options();
>
> /* Enumerate the immovable memory regions */
>--
>2.7.4
>
>
>
Re: [PATCH] vfio/type1: Limit DMA mappings per container
On Mon, Apr 01, 2019 at 10:34:13PM -0600, Alex Williamson wrote:
> On Tue, 2 Apr 2019 10:41:15 +0800
> Peter Xu wrote:
>
> > On Mon, Apr 01, 2019 at 02:16:52PM -0600, Alex Williamson wrote:
> >
> > [...]
> >
> > > @@ -1081,8 +1088,14 @@ static int vfio_dma_do_map(struct vfio_iommu
> > > *iommu,
> > > goto out_unlock;
> > > }
> > >
> > > + if (!atomic_add_unless(>dma_avail, -1, 0)) {
> > > + ret = -ENOSPC;
> > > + goto out_unlock;
> > > + }
> > > +
> > > dma = kzalloc(sizeof(*dma), GFP_KERNEL);
> > > if (!dma) {
> > > + atomic_inc(>dma_avail);
> >
> > This should be the only special path to revert the change. Not sure
> > whether this can be avoided by simply using atomic_read() or even
> > READ_ONCE() (I feel like we don't need atomic ops with dma_avail
> > because we've had the mutex but it of course it doesn't hurt...) to
> > replace atomic_add_unless() above to check against zero then we do
> > +1/-1 in vfio_[un]link_dma() only. But AFAICT this patch is correct.
>
> Thanks for the review, you're right, we're only twiddling this atomic
> while holding the iommu->lock mutex, so it appears unnecessary. Since
> we're within the mutex, I think we don't even need a READ_ONCE. We can
> simple test it before alloc and decrement after. Am I missing something
> that would specifically require READ_ONCE within our mutex critical
> section? Thanks,
I don't know very clear on this and I'd be glad to learn about that.
My understanding is that [READ|WRITE]_ONCE() is the same as volatile
mem operation and will make sure we don't keep variables in the
registers. So if the mutex semantics can support that (say, a "*addr
= val" following with a mutex_unlock will make sure "val" will
definitely land into memory of "") then I do think it's fine even
without it (which corresponds to WRITE_ONCE(, val) in this case).
Thanks,
--
Peter Xu
Re: linux-next: build failure after merge of the sound-asoc tree
On Mon, Apr 01, 2019 at 10:11:44PM +1100, Michael Ellerman wrote: > Anyway I think what you've done in next, make the code depend on > COMMON_CLOCK, is the best option. If anyone cares about that driver on > powerpc platforms that don't support COMMON_CLOCK they should speak up. It's probably fine for now for this one driver but it's going to cause issues going forwards since we're trying to make the framework's clock handling more standard. signature.asc Description: PGP signature
Re: [PATCH v3] mfd: cros_ec: instantiate properly CrOS ISH MCU device
On Fri, 01 Mar 2019, Rushikesh S Kadam wrote: > Integrated Sensor Hub (ISH) is also a MCU running EC > having feature bit EC_FEATURE_ISH. Instantiate it as > a special CrOS EC device with device name 'cros_ish'. > > Signed-off-by: Rushikesh S Kadam > --- > v3 > - Dropped "Intel" in commments in cros_ec header file. CrOS EC ISH > device is a generic ISH. This was missed earlier. > v2 > - Addressed review comments to term the CrOS EC device as a generic > Integrated Sensor Hub. > v1 > - Initial version. > > drivers/mfd/cros_ec_dev.c| 13 + > include/linux/mfd/cros_ec.h | 1 + > include/linux/mfd/cros_ec_commands.h | 2 ++ > 3 files changed, 16 insertions(+) Applied, thanks. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH v1] mfd: Add support for Merrifield Basin Cove PMIC
On Mon, 18 Mar 2019, Andy Shevchenko wrote:
> Add an mfd driver for Intel Merrifield Basin Cove PMIC.
Nit: s/mfd/MFD/
> Signed-off-by: Andy Shevchenko
> ---
> drivers/mfd/Kconfig | 11 ++
> drivers/mfd/Makefile | 1 +
> drivers/mfd/intel_soc_pmic_mrfld.c | 157 +++
> include/linux/mfd/intel_soc_pmic_mrfld.h | 81
> 4 files changed, 250 insertions(+)
> create mode 100644 drivers/mfd/intel_soc_pmic_mrfld.c
> create mode 100644 include/linux/mfd/intel_soc_pmic_mrfld.h
>
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index 0ce2d8dfc5f1..2adf9d393029 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -572,6 +572,17 @@ config INTEL_SOC_PMIC_CHTDC_TI
> Select this option for supporting Dollar Cove (TI version) PMIC
> device that is found on some Intel Cherry Trail systems.
>
> +config INTEL_SOC_PMIC_MRFLD
> + tristate "Support for Intel Merrifield Basin Cove PMIC"
> + depends on GPIOLIB
> + depends on ACPI
> + depends on INTEL_SCU_IPC
> + select MFD_CORE
> + select REGMAP_IRQ
> + help
> + Select this option for supporting Basin Cove PMIC device
> + that is found on Intel Merrifield systems.
> +
> config MFD_INTEL_LPSS
> tristate
> select COMMON_CLK
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index b4569ed7f3f3..1b746bd01ac5 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -234,6 +234,7 @@ obj-$(CONFIG_INTEL_SOC_PMIC) += intel-soc-pmic.o
> obj-$(CONFIG_INTEL_SOC_PMIC_BXTWC) += intel_soc_pmic_bxtwc.o
> obj-$(CONFIG_INTEL_SOC_PMIC_CHTWC) += intel_soc_pmic_chtwc.o
> obj-$(CONFIG_INTEL_SOC_PMIC_CHTDC_TI)+= intel_soc_pmic_chtdc_ti.o
> +obj-$(CONFIG_INTEL_SOC_PMIC_MRFLD) += intel_soc_pmic_mrfld.o
> obj-$(CONFIG_MFD_MT6397) += mt6397-core.o
>
> obj-$(CONFIG_MFD_ALTERA_A10SR) += altera-a10sr.o
> diff --git a/drivers/mfd/intel_soc_pmic_mrfld.c
> b/drivers/mfd/intel_soc_pmic_mrfld.c
> new file mode 100644
> index ..bbee89c0c25b
> --- /dev/null
> +++ b/drivers/mfd/intel_soc_pmic_mrfld.c
> @@ -0,0 +1,157 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Device access for Basin Cove PMIC
> + *
> + * Copyright (c) 2018, Intel Corporation.
> + * Author: Andy Shevchenko
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +/*
> + * Level 2 IRQs
> + *
> + * Firmware on the systems with Basin Cove PMIC services Level 1 IRQs
> + * without an assistance. Thus, each of the Level 1 IRQ is represented
> + * as a separate RTE in IOAPIC.
> + */
> +static struct resource irq_level2_resources[] = {
> + DEFINE_RES_IRQ(0), /* power button */
> + DEFINE_RES_IRQ(0), /* TMU */
> + DEFINE_RES_IRQ(0), /* thermal */
> + DEFINE_RES_IRQ(0), /* BCU */
> + DEFINE_RES_IRQ(0), /* ADC */
> + DEFINE_RES_IRQ(0), /* charger */
> + DEFINE_RES_IRQ(0), /* GPIO */
> +};
> +
> +static const struct mfd_cell bcove_dev[] = {
> + {
> + .name = "mrfld_bcove_pwrbtn",
> + .num_resources = 1,
> + .resources = _level2_resources[0],
> + }, {
> + .name = "mrfld_bcove_tmu",
> + .num_resources = 1,
> + .resources = _level2_resources[1],
> + }, {
> + .name = "mrfld_bcove_thermal",
> + .num_resources = 1,
> + .resources = _level2_resources[2],
> + }, {
> + .name = "mrfld_bcove_bcu",
> + .num_resources = 1,
> + .resources = _level2_resources[3],
> + }, {
> + .name = "mrfld_bcove_adc",
> + .num_resources = 1,
> + .resources = _level2_resources[4],
> + }, {
> + .name = "mrfld_bcove_charger",
> + .num_resources = 1,
> + .resources = _level2_resources[5],
> + }, {
> + .name = "mrfld_bcove_extcon",
> + .num_resources = 1,
> + .resources = _level2_resources[5],
> + }, {
> + .name = "mrfld_bcove_gpio",
> + .num_resources = 1,
> + .resources = _level2_resources[6],
> + },
> + { .name = "mrfld_bcove_region", },
> +};
> +
> +static int regmap_ipc_byte_reg_read(void *context, unsigned int reg,
Prefixing these with regmap is pretty confusing, since this it not
part of the Regmap API. Better to provide them with local names
instead.
bcove_ipc_byte_reg_read()
> + unsigned int *val)
> +{
> + u8 ipc_out;
> + int ret;
> +
> + ret = intel_scu_ipc_ioread8(reg, _out);
> + if (ret)
> + return ret;
> +
> + *val = ipc_out;
> + return 0;
> +}
> +
> +static int regmap_ipc_byte_reg_write(void *context, unsigned int reg,
> + unsigned int val)
> +{
> + u8 ipc_in = val;
> +
Re: [PATCH 2/2] ASoC: rt5677: make ACPI property names match _DSD
On Mon, Apr 01, 2019 at 02:55:19PM -0600, Fletcher Woodruff wrote: > The rt5677 driver is using the wrong property names to read from ACPI. > Update the property names to match those from _DSD, so that the correct > GPIO pin numbers are read and that plug-detection works. > With this patch, plugging and unplugging the headphone jack switches > between headphones and speakers automatically. What makes you say that these properties are wrong? Are you sure that this isn't just some other systems using different ACPI properties given the poor standardization for ACPI? Your new ones look like they're DT properties pulled into ACPI while the existing ones look more idiomatic for ACPI. It'd be fine to add your new DT style properties but this might break existing systems. signature.asc Description: PGP signature
Re: [BUG] gpiolib: spi chip select legacy support breaks modern chip select and whitens the GTA04 LCD panel
Hi Linus, > Am 02.04.2019 um 06:02 schrieb Linus Walleij : > > (CC Kumar and Wolfgang who came up with spi-active-low, I think.) > > On Sun, Mar 24, 2019 at 1:56 PM H. Nikolaus Schaller > wrote: >>> Am 24.03.2019 um 05:15 schrieb Linus Walleij : > >>> But I fixed it in that case by introducing a spi-cs-high into the DTS file: >>> https://marc.info/?l=linux-arm-kernel=155292310015309=2 >> >> Yes, that of course works and is our temporary solution. >> >> And I see that you also have it on the controller node and not the slave >> node. > > Yes I git it wrong, the slave should have it and another bug of mine > made it look at the controller not (some days I should not write > code in paths that do not get executed). > >>> I'm sorry about that, however if you look at the DT binding document: >>> Documentation/devicetree/bindings/spi/spi-bus.txt >> >> Shouldn't it be a property of the slave node and not the controller node? > > Indeed. > >>> You will see that spi-cs-high is mandatory. So these DTS files are >>> incorrect. >> >> How do you read that it is mandatory from >> >> "All slave nodes can contain the following optional properties: >> - spi-cs-high - Empty property indicating device requires chip select >>active high." >> >> I read it as optional and indicative. Equal priority to cs-gpios. > > The basic problem is that spi-cs-high is defined negatively, > so by default a CS GPIO is active low. This clashes with the > default GPIO flag, as GPIO_ACTIVE_HIGH is zero, no flag, > and thus the default if nothing is specified, so if the GPIO flag is > zero it should be active high, but if "spi-active-high" is not on the > slave node it should be active low, so one of them have > to win, they can't both win. > > I'd say that spi-cs-high existed before we standardized the GPIO > flags in the DT bindings. So people were relying on it for years before > we came up with the ACTIVE_HIGH/LOW flags. > > commit f618ebfcbf9616a0fa9a78f5ecb69762f0fa3c59 > Author: Wolfgang Ocker > Date: Wed Oct 15 15:00:47 2008 +0200 > >of/spi: Support specifying chip select as active high via device tree > >The patch allows to specify that an SPI device needs an active high chip >select. > >Signed-off-by: Wolfgang Ocker >Signed-off-by: Kumar Gala > > While the GPIO binding turns up 5 years later: > > commit 71fab21fee07fd6d5f1a984db387cc5e4596f3fa > Author: Stephen Warren > Date: Tue Feb 12 17:22:36 2013 -0700 > >ARM: dt: add header to define GPIO flags > >Many GPIO device tree bindings use the same flags. Create a header to >define those. > >Signed-off-by: Stephen Warren >Acked-by: Rob Herring > > And then this guy think it is a good idea to standardize this for > all GPIO phandles two years later: > > commit 69d301fdd19635a39cb2b78e53fdd625b7a27924 > Author: Linus Walleij > Date: Thu Sep 24 15:05:45 2015 -0700 > >gpio: add DT bindings for existing consumer flags > >It is customary for GPIO controllers to support open drain/collector >and open source/emitter configurations. Add standard GPIO line flags >to account for this and augment the documentation to say that these >are the most generic bindings. > >Several people approached me to add new flags to the lines, and this >makes sense, but let's first bind up the most common cases before we >start to add exotic stuff. > >Thanks to H. Nikolaus Schaller for ideas on how to encode single-ended >wiring such as open drain/source and open collector/emitter. > >Cc: Tony Lindgren >Cc: Grygorii Strashko >Cc: H. Nikolaus Schaller Yes, I remember to help with the open drain/collector definition :) >Signed-off-by: Linus Walleij > >>> This does not work because there are devices that requires spi-cs-high to be >>> respected and the DTS second cell GPIO flag to be ignored. >> >> Then, those should be fixed... > > This can't be done because some old systems (mostly powerpc) > added between 2008-2013 do not know about GPIO flags and > have DTBs deployed in firmware that need to keep working. > They cannot be fixed. The question is if it is even possible to deploy a new kernel for such devices and if anyone wants to do... This also gives another idea: make it depend on "powerpc". > >>> They might have deployed DTB binaries that need to keep working, >> >> Well, that is a weak argument. What if the GTA04 would have the DTB in FLASH >> and would need it working (fortunately we always reflash kernel + dtbs)? > > Usually the definition I use for "deployed DTB" is not > "deployed on my desk" but "deployed by a factory" i.e. someone > producing millions of TV sets or something. For example my monitor > is using a PowerPC CPU and has one of these DTBs in flash, > and expect it to keep working if I upgrade the kernel separately. Ok, I see. We basically have the same (devices deployed to unknown users), but we can and do flash
Re: [PATCH 1/2] ASoC: rt5677: allow multiple interrupt sources
On Mon, Apr 01, 2019 at 02:55:18PM -0600, Fletcher Woodruff wrote:
> From: Ben Zhang
>
> This patch allows headphone plug detect and mic present
> detect to be enabled at the same time. This patch implements
> an irq_chip with irq_domain directly instead of using
> regmap_irq, so that interrupt source line polarities can
> be flipped to support irq sharing.
regmap-irq should support active high/low, and if it doesn't it can't be
a unique thing that only this device wants to implement so the common
code should be improved.
> + mutex_lock(>irq_lock);
> + /*
> + * Loop to handle interrupts until the last i2c read shows no pending
> + * irqs. The interrupt line is shared by multiple interrupt sources.
> + * After the regmap_read() below, a new interrupt source line may
> + * become high before the regmap_write() finishes, so there isn't a
> + * rising edge on the shared interrupt line for the new interrupt. Thus,
> + * the loop is needed to avoid missing irqs.
> + *
> + * A safeguard of 20 loops is used to avoid hanging in the irq handler
> + * if there is something wrong with the interrupt status update. The
> + * interrupt sources here are audio jack plug/unplug events which
> + * shouldn't happen at a high frequency for a long period of time.
> + * Empirically, more than 3 loops have never been seen.
> + */
> + for (loop = 0; loop < 20; loop++) {
This looks unrelated to the polarity of the interupt?
signature.asc
Description: PGP signature
Re: MSI number limit for PCI hotplug under PCI bridge on ARM platform
On Mon, 01 Apr 2019 14:55:52 +0100, Heyi Guo wrote: > > Hi folks, > > In current kernel implementation for ARM platform, all devices under > one PCI bridge share a same device ID and the total number of MSI > interrupts is fixed at the first time any child device is allocating > MSI. However, this may cause failure of allocating MSI if the system > supports device hot-plug under the PCI bridge, which is possible for > ARM virtual machine with generic pcie-to-pci-bridge and kernel > config HOTPLUG_PCI_SHPC enabled. > > Does it make sense to add support for the above scenario? If it > does, any suggestion for how to do that? I don't think it makes much sense. You have the flexibility not to add such a broken setup to your guests, and instead have enough pcie ports so that you can always have an exact allocation and no DevID aliasing. The alternative is to dynamically grow the ITT for a given DevID, which cannot be done without unmapping it first. This in turn will result in interrupts being lost while the DevID was unmapped, and they'd need to be pessimistically reinjected. This also involves a substantial amount of data structure repainting, as you're pretty much guaranteed not to be able to reuse the same LPI range. Given that this is arbitrarily self-inflicted, I'm not overly keen on even trying to support this. Thanks, M. -- Jazz is not dead, it just smell funny.
Re: [RESEND PATCH] mfd: sc27xx: Use SoC compatible string for PMIC devices
On Mon, 18 Mar 2019, Baolin Wang wrote:
> We should use SoC compatible string in stead of wildcard string for
> PMIC child devices.
>
> Signed-off-by: Baolin Wang
> ---
> Hi Lee,
>
> Could you merge this patch into v5.1-rc if no objection from you?
> Since our DTS patches had been merged into v5.1, our PMIC can not
> work without this patch. Thanks.
Oh dear, what a pickle. Really you should have pushed these change
though one tree, in either a single patch or at the very least a
single patch-set. I will see what I can do, so that this doesn't
break for an entire kernel version (but I make no promises).
> ---
> drivers/mfd/sprd-sc27xx-spi.c | 42
> -
> 1 file changed, 21 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/mfd/sprd-sc27xx-spi.c b/drivers/mfd/sprd-sc27xx-spi.c
> index 69df277..43ac716 100644
> --- a/drivers/mfd/sprd-sc27xx-spi.c
> +++ b/drivers/mfd/sprd-sc27xx-spi.c
> @@ -53,67 +53,67 @@ struct sprd_pmic_data {
> static const struct mfd_cell sprd_pmic_devs[] = {
> {
> .name = "sc27xx-wdt",
> - .of_compatible = "sprd,sc27xx-wdt",
> + .of_compatible = "sprd,sc2731-wdt",
> }, {
> .name = "sc27xx-rtc",
> - .of_compatible = "sprd,sc27xx-rtc",
> + .of_compatible = "sprd,sc2731-rtc",
> }, {
> .name = "sc27xx-charger",
> - .of_compatible = "sprd,sc27xx-charger",
> + .of_compatible = "sprd,sc2731-charger",
> }, {
> .name = "sc27xx-chg-timer",
> - .of_compatible = "sprd,sc27xx-chg-timer",
> + .of_compatible = "sprd,sc2731-chg-timer",
> }, {
> .name = "sc27xx-fast-chg",
> - .of_compatible = "sprd,sc27xx-fast-chg",
> + .of_compatible = "sprd,sc2731-fast-chg",
> }, {
> .name = "sc27xx-chg-wdt",
> - .of_compatible = "sprd,sc27xx-chg-wdt",
> + .of_compatible = "sprd,sc2731-chg-wdt",
> }, {
> .name = "sc27xx-typec",
> - .of_compatible = "sprd,sc27xx-typec",
> + .of_compatible = "sprd,sc2731-typec",
> }, {
> .name = "sc27xx-flash",
> - .of_compatible = "sprd,sc27xx-flash",
> + .of_compatible = "sprd,sc2731-flash",
> }, {
> .name = "sc27xx-eic",
> - .of_compatible = "sprd,sc27xx-eic",
> + .of_compatible = "sprd,sc2731-eic",
> }, {
> .name = "sc27xx-efuse",
> - .of_compatible = "sprd,sc27xx-efuse",
> + .of_compatible = "sprd,sc2731-efuse",
> }, {
> .name = "sc27xx-thermal",
> - .of_compatible = "sprd,sc27xx-thermal",
> + .of_compatible = "sprd,sc2731-thermal",
> }, {
> .name = "sc27xx-adc",
> - .of_compatible = "sprd,sc27xx-adc",
> + .of_compatible = "sprd,sc2731-adc",
> }, {
> .name = "sc27xx-audio-codec",
> - .of_compatible = "sprd,sc27xx-audio-codec",
> + .of_compatible = "sprd,sc2731-audio-codec",
> }, {
> .name = "sc27xx-regulator",
> - .of_compatible = "sprd,sc27xx-regulator",
> + .of_compatible = "sprd,sc2731-regulator",
> }, {
> .name = "sc27xx-vibrator",
> - .of_compatible = "sprd,sc27xx-vibrator",
> + .of_compatible = "sprd,sc2731-vibrator",
> }, {
> .name = "sc27xx-keypad-led",
> - .of_compatible = "sprd,sc27xx-keypad-led",
> + .of_compatible = "sprd,sc2731-keypad-led",
> }, {
> .name = "sc27xx-bltc",
> - .of_compatible = "sprd,sc27xx-bltc",
> + .of_compatible = "sprd,sc2731-bltc",
> }, {
> .name = "sc27xx-fgu",
> - .of_compatible = "sprd,sc27xx-fgu",
> + .of_compatible = "sprd,sc2731-fgu",
> }, {
> .name = "sc27xx-7sreset",
> - .of_compatible = "sprd,sc27xx-7sreset",
> + .of_compatible = "sprd,sc2731-7sreset",
> }, {
> .name = "sc27xx-poweroff",
> - .of_compatible = "sprd,sc27xx-poweroff",
> + .of_compatible = "sprd,sc2731-poweroff",
> }, {
> .name = "sc27xx-syscon",
> - .of_compatible = "sprd,sc27xx-syscon",
> + .of_compatible = "sprd,sc2731-syscon",
> },
> };
>
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
Re: [LKP] [btrfs] 70d28b0e4f: BUG:kernel_reboot-without-warning_in_early-boot_stage, last_printk:Probing_EDD(edd=off_to_disable)...ok
On 2019/4/2 上午11:14, Rong Chen wrote:
>
> On 4/1/19 11:40 PM, David Sterba wrote:
>> On Mon, Apr 01, 2019 at 11:02:37PM +0800, Chen, Rong A wrote:
>>> On 4/1/2019 10:29 PM, Qu Wenruo wrote:
On 2019/4/1 下午10:02, Chen, Rong A wrote:
> On 4/1/2019 9:28 PM, Nikolay Borisov wrote:
>> On 1.04.19 г. 16:24 ч., kernel test robot wrote:
>>> FYI, we noticed the following commit (built with gcc-7):
>>>
>>> commit: 70d28b0e4f8ed2d38571e7b1f9bec7f321a53102 ("btrfs:
>>> tree-checker: Verify dev item")
>>> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git
>>> master
>>>
>>> in testcase: trinity
>>> with following parameters:
>>>
>>> runtime: 300s
>>>
>>> test-description: Trinity is a linux system call fuzz tester.
>>> test-url: http://codemonkey.org.uk/projects/trinity/
>>>
>>>
>>> on test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge
>>> -smp
>>> 2 -m 2G
>>>
>>> caused below changes (please refer to attached dmesg/kmsg for entire
>>> log/backtrace):
>>>
>>>
>>> ++++
>>>
>>>
>>> |
>>> | 36b9d2bc69 | 70d28b0e4f |
>>> ++++
>>>
>>>
>>> |
>>> boot_successes
>>> | 14 | 0 |
>>> |
>>> boot_failures
>>> | 2 | 14 |
>>> |
>>> IP-Config:Auto-configuration_of_network_failed
>>> | 2 | |
>>> |
>>> BUG:kernel_reboot-without-warning_in_early-boot_stage,last_printk:Probing_EDD(edd=off_to_disable)...ok
>>>
>>> | 0 | 14 |
>>> ++++
>>>
>>>
>>>
>>>
>>>
>>> early console in setup code
>>> Probing EDD (edd=off to disable)... ok
>>> BUG: kernel reboot-without-warning in early-boot stage, last printk:
>>> Probing EDD (edd=off to disable)... ok
>>> Linux version 5.0.0-rc8-00196-g70d28b0 #1
>>> Command line: ip=vm-snb-quantal-x86_64-1415::dhcp root=/dev/ram0
>>> user=lkp
>>> job=/lkp/jobs/scheduled/vm-snb-quantal-x86_64-1415/trinity-300s-quantal-core-x86_64-2018-11-09.cgz-70d28b0-20190330-29362-1y6g0qb-2.yaml
>>>
>>> ARCH=x86_64 kconfig=x86_64-randconfig-s5-03231928
>>> branch=linux-devel/devel-hourly-2019032317
>>> commit=70d28b0e4f8ed2d38571e7b1f9bec7f321a53102
>>> BOOT_IMAGE=/pkg/linux/x86_64-randconfig-s5-03231928/gcc-7/70d28b0e4f8ed2d38571e7b1f9bec7f321a53102/vmlinuz-5.0.0-rc8-00196-g70d28b0
>>>
>>> max_uptime=1500
>>> RESULT_ROOT=/result/trinity/300s/vm-snb-quantal-x86_64/quantal-core-x86_64-2018-11-09.cgz/x86_64-randconfig-s5-03231928/gcc-7/70d28b0e4f8ed2d38571e7b1f9bec7f321a53102/8
>>>
>>> LKP_SERVER=inn debug apic=debug sysrq_always_enabled
>>> rcupdate.rcu_cpu_stall_timeout=100 net.ifnames=0 printk.devkmsg=on
>>> panic=-1 softlockup_panic=1 nmi_watchdog=panic oops=panic
>>> load_ramdisk=2 prompt_ramdisk=0 drbd.minor_count=8
>>> systemd.log_level=err ignore_loglevel console=tty0
>>> earlyprintk=ttyS0,115200 console=ttyS0,115200 vga=normal rw
>>> rcuperf.shutdown=0
>>>
>> Can this report be made useful by actually including output from
>> serial
>> console? For example possible bug-ons or whatnot? dmesg.xz just
>> contains
>> qemu's command line + some metadata about the test and :
>>
>> "BUG: kernel reboot-without-warning in early-boot stage, last printk:
>> Probing EDD (edd=off to disable)... ok"
>>
>> At least a stack trace would have been useful.
>>
>>
> Hi,
>
> We usually use the tool ("bin/lkp qemu -k job-script") to
> reproduce it. It seems no stack trace in the result:
So there is no regression at that commit right?
Just some false alert?
>>>
>>> Hi,
>>>
>>> I think there's a regression, it stopped in the early-boot stage .
>> Can you please provide any logs that would point at btrfs? If the module
>> is loaded or built-in started, there's a line about that. Besides that
>> it's preceded by messages from other subsystems' initialization.
>
>
> Hi,
>
> CONFIG_BTRFS_FS and CONFIG_BTRFS_FS_REF_VERIFY is enabled in the kconfig.
> I disabled them for the experiment, and the new kernel is bootable. I
> don't have more logs to prove it.
>
> $ grep BTRFS config-5.0.0-rc8-00196-g70d28b0
> CONFIG_BTRFS_FS=y
> # CONFIG_BTRFS_FS_POSIX_ACL is not set
> # CONFIG_BTRFS_FS_CHECK_INTEGRITY is not set
> # CONFIG_BTRFS_FS_RUN_SANITY_TESTS is not set
> # CONFIG_BTRFS_DEBUG is not set
> # CONFIG_BTRFS_ASSERT is not set
> CONFIG_BTRFS_FS_REF_VERIFY=y
With the same
Re: Applied "ASoC: es8316: Add support for inverted jack detect" to the asoc tree
On Mon, Apr 01, 2019 at 07:57:19PM +0200, Paul Cercueil wrote: Please don't top post, reply in line with needed context. This allows readers to readily follow the flow of conversation and understand what you are talking about and also helps ensure that everything in the discussion is being addressed. > What about the other two patches? Should I make a new patchset with these? They're Intel board patches so the Intel people will hopefully review. signature.asc Description: PGP signature
Re: [PATCH 01/17] fpga: dfl-fme-mgr: fix FME_PR_INTFC_ID register address.
On Mon, Apr 01, 2019 at 12:54:47PM -0700, Moritz Fischer wrote: > Hi Wu, > > On Mon, Mar 25, 2019 at 11:07:28AM +0800, Wu Hao wrote: > > FME_PR_INTFC_ID is used as compat_id for fpga manager and region, > > but high 64 bits and low 64 bits of the compat_id are swapped by > > mistake. This patch fixes this problem by fixing register address. > > > > Signed-off-by: Wu Hao > > --- > > drivers/fpga/dfl-fme-mgr.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/fpga/dfl-fme-mgr.c b/drivers/fpga/dfl-fme-mgr.c > > index 76f3770..b3f7eee 100644 > > --- a/drivers/fpga/dfl-fme-mgr.c > > +++ b/drivers/fpga/dfl-fme-mgr.c > > @@ -30,8 +30,8 @@ > > #define FME_PR_STS 0x10 > > #define FME_PR_DATA0x18 > > #define FME_PR_ERR 0x20 > > -#define FME_PR_INTFC_ID_H 0xA8 > > -#define FME_PR_INTFC_ID_L 0xB0 > > +#define FME_PR_INTFC_ID_L 0xA8 > > +#define FME_PR_INTFC_ID_H 0xB0 > > Does this handle endianess correct? Hi Moritz, This is just a bug fixing for wrong offsets given to these 2 registers according to spec. I think this is not endianess related, and per my understanding we don't need more code on endianess handling as that should be done inside the readq function already. :) Thanks Hao
Re: [PATCH V1 24/26] spi: tegra114: de-assert CS before SPI mode is reset to its default
On Mon, Apr 01, 2019 at 06:07:45PM +, Sowjanya Komatineni wrote: > I see you have applied some patches in V1 series so should I re-send > again those as well along with feedback changes in next version or > just only the patches that are not applied. Please don't resend already applied patches. signature.asc Description: PGP signature
Re: [PATCH V1 19/26] DT bindings: spi: add spi client device properties
On Mon, Apr 01, 2019 at 05:59:57PM +, Sowjanya Komatineni wrote: Please fix your mail client to word wrap within paragraphs at something substantially less than 80 columns. Doing this makes your messages much easier to read and reply to. > > > +spi-client device controller properties: > > > +- nvidia,cs-setup-clk-count: CS setup timing parameter. > > > +- nvidia,cs-hold-clk-count: CS hold timing parameter. > > > +- nvidia,cs-inactive-cycles: CS inactive delay in terms of clock > > > +between > > > + transfers. > > Why are these being done as nVidia specific properties rather than > > generic ones and why are these being configured in DT rather than by > > the client driver? If the devices have particular timing > > requirements for chip select presumably that's going to apply no > > matter what controller or system they're used with so it seems best > > to configure this in the client driver and have an API that any > > controller can implement. > These are implemented thru DT as Tegra SPI is master and master controls the > timing. > Some SPI slaves have specific requirements of certain CS setup/hold time and > inactive cycles which SPI master should meet when driving during transfer and > Tegra SPI controller supports tuning these parameters. This doesn't address the issue at all, obviously the timings for the SPI bus are going to be impelemented by the controller but that's not the issue. signature.asc Description: PGP signature
Re: [PATCH v2 3/4] Makefile: lld: tell clang to use lld
Hi Nick, On Tue, Apr 2, 2019 at 12:54 PM Nick Desaulniers wrote: > > On Sat, Feb 16, 2019 at 10:09 AM Masahiro Yamada > wrote: > > > > On Thu, Feb 14, 2019 at 8:08 AM Nick Desaulniers > > wrote: > > > > > > On Wed, Feb 13, 2019 at 6:59 AM Masahiro Yamada > > > wrote: > > > > > > > > On Tue, Feb 12, 2019 at 5:42 AM wrote: > > > > > > > > > > This is needed because clang doesn't select which linker to use based > > > > > on > > > > > $LD but rather -fuse-ld=lld. This is problematic especially for > > > > > cc-ldoption, which checks for linker flag support via invoking the > > > > > compiler, rather than the linker. > > > > > > > > > > > > Sorry, please explain what kind of problem > > > > this patch solves. > > > > > > > > > > > > > > > > [1] $(LD) is used to link vmlinux, modules, etc. > > > > > > > > [2] $(CC) is used to link vdso, etc. > > > > and -fuse-ld= selects which linker is invoked from $(CC) > > > > > > It solves case 2. > > > > > > > > > > > > > > > Is it a problem to use a different > > > > type of linker for [1] and [2] ? > > > > > > Ideally, no, but I can think of at least one case where it might be > > > problematic to mix linkers like that: > > > You might be mixing linker flags added via ld-option from one linker > > > that aren't actually supported by the other linker. > > > > You can do this only when you are sure > > that the _exactly_ same linker is used. > > > > In my understanding, -fuse-ld=lld does not guarantee it. > > I really don't think we should be mixing and matching linkers during a > kernel build. When we compile with clang, we don't have escape > hatches that allow for some object files to be compiled with GCC > (mixing clang and GCC compiled object files into one build). > Following the same logic, I think mixing linkers during kernel build > should similarly be dissuaded. This patch AVOIDS clang using a > different linker than what was specified via $LD, which is CRITICAL > for cc-ldoption kbuild macro. Masahiro, I hope this patch can be > re-evaluated, or if I'm not understanding your point, that you can > provide additional clarification. > You can pass an absolute pass to LD, like make LD=/path/to/my/llvm/install/dir/bin/ld.lld This clarifies which linker is being used even when multiple versions of llvm are installed on the machine. However, -fuse-ld=lld is ambiguous. Will it use the first ld.lld found in PATH? So, you cannot avoid mixing linkers by this means. If we could do -fuse=$(LD), I would agree with it. Clang accepts -fuse=, GCC does not. Is there a way to control the linker search path? -- Best Regards Masahiro Yamada
Re: [PATCH v3] gcov: fix when CONFIG_MODULES is not set
On 4/1/19 8:09 PM, tr...@android.com wrote:
> From: Tri Vo
>
> Fixes: 8c3d220cb6b5 ("gcov: clang support")
>
> Cc: Greg Hackmann
> Cc: Peter Oberparleiter
> Cc: linux...@kvack.org
> Cc: kbuild-...@01.org
> Reported-by: Randy Dunlap
> Reported-by: kbuild test robot
> Link: https://marc.info/?l=linux-mm=155384681109231=2
> Signed-off-by: Nick Desaulniers
> Signed-off-by: Tri Vo
Acked-by: Randy Dunlap # build-tested
Thanks.
> ---
> kernel/gcov/clang.c | 4
> kernel/gcov/gcc_3_4.c | 4
> kernel/gcov/gcc_4_7.c | 4
> 3 files changed, 12 insertions(+)
>
> diff --git a/kernel/gcov/clang.c b/kernel/gcov/clang.c
> index 125c50397ba2..cfb9ce5e0fed 100644
> --- a/kernel/gcov/clang.c
> +++ b/kernel/gcov/clang.c
> @@ -223,7 +223,11 @@ void gcov_info_unlink(struct gcov_info *prev, struct
> gcov_info *info)
> */
> bool gcov_info_within_module(struct gcov_info *info, struct module *mod)
> {
> +#ifdef CONFIG_MODULES
> return within_module((unsigned long)info->filename, mod);
> +#else
> + return false;
> +#endif
> }
>
> /* Symbolic links to be created for each profiling data file. */
> diff --git a/kernel/gcov/gcc_3_4.c b/kernel/gcov/gcc_3_4.c
> index 801ee4b0b969..8fc30f178351 100644
> --- a/kernel/gcov/gcc_3_4.c
> +++ b/kernel/gcov/gcc_3_4.c
> @@ -146,7 +146,11 @@ void gcov_info_unlink(struct gcov_info *prev, struct
> gcov_info *info)
> */
> bool gcov_info_within_module(struct gcov_info *info, struct module *mod)
> {
> +#ifdef CONFIG_MODULES
> return within_module((unsigned long)info, mod);
> +#else
> + return false;
> +#endif
> }
>
> /* Symbolic links to be created for each profiling data file. */
> diff --git a/kernel/gcov/gcc_4_7.c b/kernel/gcov/gcc_4_7.c
> index ec37563674d6..0b6886d4a4dd 100644
> --- a/kernel/gcov/gcc_4_7.c
> +++ b/kernel/gcov/gcc_4_7.c
> @@ -159,7 +159,11 @@ void gcov_info_unlink(struct gcov_info *prev, struct
> gcov_info *info)
> */
> bool gcov_info_within_module(struct gcov_info *info, struct module *mod)
> {
> +#ifdef CONFIG_MODULES
> return within_module((unsigned long)info, mod);
> +#else
> + return false;
> +#endif
> }
>
> /* Symbolic links to be created for each profiling data file. */
>
--
~Randy
Re: Nested events with zero deltas, can use absolute timestamps instead?
On Mon, Apr 1, 2019 at 7:21 PM Steven Rostedt wrote: > > On Mon, 1 Apr 2019 15:54:20 -0700 > Jason Behmer wrote: > > > The concurrency model is still a little bit unclear to me as I'm new > > to this codebase. So I'm having some trouble reasoning about what > > operations are safe at one point on the ring buffer.It seems like > > we can't be preempted in general, just interrupts? And the events for > > the events emitted by interrupts will be fully processed before > > getting back to the event pointed at by the commit pointer? If this > > is true I think the approach below (and prototyped in the attached > > patch against head) might work and would love feedback. If not, this > > problem is way harder. > > > > We detect nested events by checking our event pointer against the > > commit pointer. This is safe because we reserve our event space > > atomically in the buffer, leading to an ordering of events we can > > depend on. But to add a TIME_STAMP event we need to reserve more > > space before we even have an event pointer, so we need to know > > something about the ordering of events before we've actually > > atomically reserved ours. We could check if the write pointer is set > > to the commit pointer, and if it isn't we know we're a nested event. > > But, someone could update the write pointer and/or commit pointer > > between the time we check it and the time we atomically reserve our > > space in the buffer. However, I think maybe this is ok. > > > > If we see that the write pointer is not equal to the commit pointer, > > then we're in an interrupt, and the only thing that could update the > > commit pointer is the original event emitting code that was > > interrupted, which can't run again until we're finished. And the only > > thing that can update the write pointer is further interrupts of us, > > which will advance the write pointer further away from commit, leaving > > our decision to allocate a TIME_STAMP event as valid. > > > > If we see that the write pointer is equal to the commit pointer, then > > anything that interrupts us before we move the write pointer will see > > that same state and will need to, before returning to us, commit their > > event and set commit to their new write pointer, which will make our > > decision valid once again. > > > > There's a lot of assumptions in there that I'd love to be checked on > > as I'm new to this code base. For example I haven't read the read > > path at all and have no idea if it interacts with this at all. > > I think you pretty much got the idea correct. The issue is what to put > into the extra timestamp value. As the time we record the timestamp > compared to the time we allocate the space for the timestamp is not > atomic. And we can't have time go backwards :-( > > | | > commit --->+--+ > | TS offset from previous event| (A) > +--+ > | outer event data | > +--+ > | extended TS | (B) > +--+ > | interrupt event data | > +--+ > head --->| | > > > TS = rdstc(); > A = reserve_ring_buffer > *A = TS > > interrupt: > TS = rdtsc(); > B = reserve_ring_buffer > *B = TS > > > What's important is what we store in A and B > > TS = rdtsc(); > ---> > TS = rdstc() > (this is first commit!) > A = reserver_ring_buffer > *A = TS > (finish commit) > < > A = reserver_ring_buffer > *A = TS > > You can see how the recording of the timestamp and writing it gets > complex. Also it gets more complex when we use deltas and not direct writes. > > Now we may be able to handle this if we take the timestamp before doing > anything, and if it's nested, take it again (which should guarantee > that it's after the previous timestamp) > > Now of course the question is, how do we update the write stamp that we > will use to compute new "deltas"? Or we just use absolute timestamps to > the end of the page, and start over again, when we start a new page > that isn't nested. > > But see where the complexity comes from? > > -- Steve Ah, yes, I was too focused on the first problem of if we could even reserve the space due to concurrency restrictions. First, I had assumed there weren't restrictions on timestamps needing to not go backwards between consecutive events in the buffers, as it seems the current implementation of absolute timestamps
Re: [PATCH v2 0/2] arm64: meson-gxm: Add support for the Mali T820 GPU
Neil Armstrong writes: > On 15/03/2019 14:56, Neil Armstrong wrote: >> This patchset adds : >> - Optional reset properties in the midgard bindings >> - Mali T820 Node in Amlogic Meson GXM DTSI >> >> Changes since v1: >> - Updated midgard DT wording following the recently submitted >> bifrost bindings >> >> Christian Hewitt (1): >> arm64: dts: meson-gxm: Add Mali-T820 node >> >> Neil Armstrong (1): >> dt-bindings: gpu: mali-midgard: Add resets property >> >> .../bindings/gpu/arm,mali-midgard.txt | 14 ++ >> arch/arm64/boot/dts/amlogic/meson-gxm.dtsi| 27 +++ >> 2 files changed, 41 insertions(+) >> > > Kevin, can you take both in your tree now the bindings are reviewed ? Yes. Queud for v5.2 (branch: v5.2/dt64) Thanks, Kevin
Re: [PATCH 2/6] kbuild: allow Kbuild to start from any directory
Hi Yamada-san,
Thank you for the patches,
I like the direction this series is taking.
Small spelling error spotted below...
But as I've now gone through all of it I'll offer
Reviewed-by: Kieran Bingham
On 30/03/2019 12:04, Masahiro Yamada wrote:
> Kbuild always runs in the top of the output directory.
>
> If Make starts in the source directory with O=, it relocates the
> working directory to the location specified by O=.
>
> Also, users can start build from the output directory by using the
> Makefile generated by scripts/mkmakefile.
>
> With a little more effort, Kbuild will be able to start from any
> directory path.
>
> This commit allows to specify the source directory by using
> the -f option.
>
> For example, you can do:
>
> $ cd path/to/output/dir
> $ make -f path/to/source/dir/Makefile
>
> Or, for the equivalent behavior, you can do:
>
> $ make O=path/to/output/dir -f path/to/source/dir/Makefile
>
> KBUILD_SRC is now deprecated.
>
> Signed-off-by: Masahiro Yamada
> ---
>
> Makefile | 87
> +---
> 1 file changed, 50 insertions(+), 37 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index 9cbd367..1b2a70e 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -96,56 +96,65 @@ endif
>
> export quiet Q KBUILD_VERBOSE
>
> -# kbuild supports saving output files in a separate directory.
> -# To locate output files in a separate directory two syntaxes are supported.
> -# In both cases the working directory must be the root of the kernel src.
> +# Kbuild will save output files in the current working directory.
> +# This does not need to match to the root of the kernel source tree.
> +#
> +# For example, you can do this:
> +#
> +# cd /dir/to/store/output/files; make -f /dir/to/kernel/source/Makefile
> +#
> +# If you want to save output files in a different location, there are
> +# two syntaxes to specify it.
> +#
> # 1) O=
> # Use "make O=dir/to/store/output/files/"
> #
> # 2) Set KBUILD_OUTPUT
> -# Set the environment variable KBUILD_OUTPUT to point to the directory
> -# where the output files shall be placed.
> -# export KBUILD_OUTPUT=dir/to/store/output/files/
> -# make
> +# Set the environment variable KBUILD_OUTPUT to point to the output
> directory.
> +# export KBUILD_OUTPUT=dir/to/store/output/files/; make
> #
> # The O= assignment takes precedence over the KBUILD_OUTPUT environment
> # variable.
>
> -# KBUILD_SRC is not intended to be used by the regular user (for now),
> -# it is set on invocation of make with KBUILD_OUTPUT or O= specified.
> -
> -# OK, Make called in directory where kernel src resides
> -# Do we want to locate output files in a separate directory?
> +# Do we want to change the working directory?
> ifeq ("$(origin O)", "command line")
>KBUILD_OUTPUT := $(O)
> endif
>
> -ifneq ($(words $(subst :, ,$(CURDIR))), 1)
> - $(error main directory cannot contain spaces nor colons)
> +ifneq ($(KBUILD_OUTPUT),)
> +# Make's built-in functions such as $(abspath ...), $(realpath ...) cannot
> +# expand a shell special character '~'. We use a bit tredious way to handle
> it.
very minor, but I noticed while looking through the series ^^
s/bit tredious/somewhat tedious/
> +abs_objtree := $(shell mkdir -p $(KBUILD_OUTPUT) && cd $(KBUILD_OUTPUT) &&
> pwd)
> +$(if $(abs_objtree),, \
> + $(error failed to create output directory "$(KBUILD_OUTPUT)"))
> +
> +# $(realpath ...) resolves symlinks
> +abs_objtree := $(realpath $(abs_objtree))
> +else
> +abs_objtree := $(CURDIR)
> +endif # ifneq ($(KBUILD_OUTPUT),)
> +
> +ifeq ($(abs_objtree),$(CURDIR))
> +# Suppress "Entering directory ..." unless we are changing the work
> directory.
> +MAKEFLAGS += --no-print-directory
> +else
> +need-sub-make := 1
> endif
>
> -ifneq ($(KBUILD_OUTPUT),)
> -# check that the output directory actually exists
> -saved-output := $(KBUILD_OUTPUT)
> -KBUILD_OUTPUT := $(shell mkdir -p $(KBUILD_OUTPUT) && cd $(KBUILD_OUTPUT) \
> - && pwd)
> -$(if $(KBUILD_OUTPUT),, \
> - $(error failed to create output directory "$(saved-output)"))
> +abs_srctree := $(realpath $(dir $(lastword $(MAKEFILE_LIST
> +
> +ifneq ($(words $(subst :, ,$(abs_srctree))), 1)
> +$(error source directory cannot contain spaces or colons)
> +endif
>
> +ifneq ($(abs_srctree),$(abs_objtree))
> # Look for make include files relative to root of kernel src
> #
> # This does not become effective immediately because MAKEFLAGS is re-parsed
> -# once after the Makefile is read. It is OK since we are going to invoke
> -# 'sub-make' below.
> -MAKEFLAGS += --include-dir=$(CURDIR)
> -
> +# once after the Makefile is read. We need to invoke sub-make.
> +MAKEFLAGS += --include-dir=$(abs_srctree)
> need-sub-make := 1
> -else
> -
> -# Do not print "Entering directory ..." at all for in-tree build.
> -MAKEFLAGS += --no-print-directory
> -
> -endif # ifneq ($(KBUILD_OUTPUT),)
> +endif
>
>
Re: [PATCH 1/1] slob: Only use list functions when safe to do so
On Tue, 2 Apr 2019 14:29:57 +1100 "Tobin C. Harding" wrote:
> Currently we call (indirectly) list_del() then we manually try to combat
> the fact that the list may be in an undefined state by getting 'prev'
> and 'next' pointers in a somewhat contrived manner. It is hard to
> verify that this works for all initial states of the list. Clearly the
> author (me) got it wrong the first time because the 0day kernel testing
> robot managed to crash the kernel thanks to this code.
>
> All this is done in order to do an optimisation aimed at preventing
> fragmentation at the start of a slab. We can just skip this
> optimisation any time the list is put into an undefined state since this
> only occurs when an allocation completely fills the slab and in this
> case the optimisation is unnecessary since we have not fragmented the slab
> by this allocation.
>
> Change the page pointer passed to slob_alloc_page() to be a double
> pointer so that we can set it to NULL to indicate that the page was
> removed from the list. Skip the optimisation if the page was removed.
>
> Found thanks to the kernel test robot, email subject:
>
> 340d3d6178 ("mm/slob.c: respect list_head abstraction layer"): kernel
> BUG at lib/list_debug.c:31!
>
It's regrettable that this fixes
slob-respect-list_head-abstraction-layer.patch but doesn't apply to
that patch - slob-use-slab_list-instead-of-lru.patch gets in the way.
So we end up with a patch series which introduces a bug and later
fixes it.
I guess we can live with that but if the need comes to respin this
series, please do simply fix
slob-respect-list_head-abstraction-layer.patch so we get a clean
series.
Re: [PATCH] drivers: gpio: Kconfig: pedantic formatting cleanups
On Tue, Mar 5, 2019 at 7:35 AM Enrico Weigelt, metux IT consult wrote: > Align the Kconfig formatting with the vast majority of the Kconfig > files, to make it a bit easier / more pleasant to read ;-) > > Signed-off-by: Enrico Weigelt, metux IT consult Patch applied. Yours, Linus Walleij
Re: [PATCH] ASoC: soc-core: Fix probe deferral following prelink failure
On Mon, Apr 01, 2019 at 01:22:09PM +0100, Jon Hunter wrote: > FYI, I am seeing that the deferral of soundcards failing with v5.1-rc3 > because the above has not been merged yet. Just wanted to let you know > in case this one was not marked for v5.1. I don't have this patch at all AFAICT. signature.asc Description: PGP signature
Re: [PATCH] vfio/type1: Limit DMA mappings per container
On Tue, 2 Apr 2019 10:41:15 +0800
Peter Xu wrote:
> On Mon, Apr 01, 2019 at 02:16:52PM -0600, Alex Williamson wrote:
>
> [...]
>
> > @@ -1081,8 +1088,14 @@ static int vfio_dma_do_map(struct vfio_iommu *iommu,
> > goto out_unlock;
> > }
> >
> > + if (!atomic_add_unless(>dma_avail, -1, 0)) {
> > + ret = -ENOSPC;
> > + goto out_unlock;
> > + }
> > +
> > dma = kzalloc(sizeof(*dma), GFP_KERNEL);
> > if (!dma) {
> > + atomic_inc(>dma_avail);
>
> This should be the only special path to revert the change. Not sure
> whether this can be avoided by simply using atomic_read() or even
> READ_ONCE() (I feel like we don't need atomic ops with dma_avail
> because we've had the mutex but it of course it doesn't hurt...) to
> replace atomic_add_unless() above to check against zero then we do
> +1/-1 in vfio_[un]link_dma() only. But AFAICT this patch is correct.
Thanks for the review, you're right, we're only twiddling this atomic
while holding the iommu->lock mutex, so it appears unnecessary. Since
we're within the mutex, I think we don't even need a READ_ONCE. We can
simple test it before alloc and decrement after. Am I missing something
that would specifically require READ_ONCE within our mutex critical
section? Thanks,
Alex
Re: [PATCH v2] spi: tegra20-slink: change chip select action order
On Fri, Mar 29, 2019 at 06:44:11PM +0100, Randolph Maaßen wrote: > To transfer via SPI the tegra20-slink driver first sets the command > register, which contains the chip select value, and after that the > command2 register, which contains the chip select line. This leads to a > small spike in the chip selct 0 line between the set of the value and > the selection of the chip select line. Please do not submit new versions of already applied patches, please submit incremental updates to the existing code. Modifying existing commits creates problems for other users building on top of those commits so it's best practice to only change pubished git commits if absolutely essential. signature.asc Description: PGP signature
Re: [PATCH v3] HID: intel-ish-hid: ISH firmware loader client driver
Hi Nick, Joe
thanks for your comments
Regards
Rushikesh
On Mon, Apr 01, 2019 at 03:17:13PM -0600, Nick Crews wrote:
> I tried to send the last message from my phone, and surprise it wasn't
> formatted correctly, so it may have been marked as spam. repeating
> myself again...
>
> Ah, I guess I was wrong about logging OOM. I hadn’t hear about the
> recommendations against it, but they make sense. Thanks for the
> clarifications!
>
> On Sat, Mar 30, 2019 at 10:27 AM Joe Perches wrote:
> >
> > On Sat, 2019-03-30 at 15:52 +0530, Rushikesh S Kadam wrote:
> > > On Fri, Mar 29, 2019 at 04:30:18PM -0700, Nick Crews wrote:
> > > > On Fri, Mar 29, 2019 at 1:03 PM Rushikesh S Kadam
> > > > wrote:
> > > > > + ldr_xfer_ipc_frag = kzalloc(LOADER_SHIM_IPC_BUF_SIZE,
> > > > > GFP_KERNEL);
> > > > > + if (!ldr_xfer_ipc_frag) {
> > > > Log error here.
> > > The error code is logged in calling function
> > > load_fw_from_host(). Is that good enough?
> > >
> > > I believe the checkpatch script too, would
> > > recommend against adding debug print for ENOMEM
> > > error.
> >
> > The generic kernel allocation functions already do
> > a dump_stack() on OOM conditions when called without
> > __GFP_NOWARN so any additional OOM message isn't
> > particularly useful.
> >
> > > Again, I thought it was against practise to log
> > > "out of memory" debug prints in probe()
> >
> > Or anywhere else given the generic OOM stack dump.
> >
> > > But will add if you tell me this is the right way.
> > >
> > > > > + return -ENOMEM;
> > > > > +
> > > > > + loader_ishtp_cl = ishtp_cl_allocate(cl_device);
> > > > > + if (!loader_ishtp_cl)
> > > >
> > > > log error here
> >
> > The ishtp_cl_allocate function just calls kmalloc then
> > initializes the struct so an additional OOM message
> > isn't useful here either.
> >
> >
--
Re: [Letux-kernel] [BUG] gpiolib: spi chip select legacy support breaks modern chip select and whitens the GTA04 LCD panel
On Sun, Mar 31, 2019 at 1:33 AM Andreas Kemnade wrote: > > > But I fixed it in that case by introducing a spi-cs-high into the DTS > > > file: > > > https://marc.info/?l=linux-arm-kernel=155292310015309=2 > > > > Yes, that of course works and is our temporary solution. > > > > And I see that you also have it on the controller node and not the slave > > node. > > > So if I get it right is a check added for undocumented properties > (nothing about spi-cs-high in controller node in the bindings > documentation, only in the slave node) in the two patches mentioned. > > And then you add that undocumented property to a dts file in your "fix". > > That all sounds strange to me. Yeah it sounds strange because it is strange :) I was simply confused and wrong. Sometimes we all do very uniformed things, today it was me. The flag should of course be on the slave node. So now I have to fix my fix. Yours, Linus Walleij
Re: [PATCH] ELAN touchpad i2c_hid bugs fix
On Apr 2, 2019, at 5:37 AM,
wrote:
-Original Message-
From: Andy Shevchenko
Sent: Thursday, March 21, 2019 4:48 AM
To: Kai-Heng Feng; Limonciello, Mario
Cc: Hans de Goede; Benjamin Tissoires; hotwater...@tutanota.com; Jiri
Kosina;
Stephen Boyd; Sebastian Andrzej Siewior; Dmitry Torokhov; open list:HID
CORE
LAYER; lkml
Subject: Re: [PATCH] ELAN touchpad i2c_hid bugs fix
[EXTERNAL EMAIL]
+Cc: Mario
Mario, do you have any insights about the issue with touchpad on Dell
system described below?
My apologies, this got lost while I was on vacation.
On Thu, Mar 21, 2019 at 6:08 AM Kai-Heng Feng
wrote:
at 01:18, Andy Shevchenko wrote:
On Wed, Mar 20, 2019 at 6:55 PM Kai-Heng Feng
wrote:
at 23:39, Hans de Goede wrote:
On 3/20/19 3:37 PM, Benjamin Tissoires wrote:
Benjamin, what I find interesting here is that the BOGUS_IRQ quirk
is also used on Elan devices, I suspect that these Elan devices
likely also need the I2C_HID_QUIRK_FORCE_TRIGGER_FALLING quirk
and then they probably will no longer need the bogus IRQ flag,
if you know about bugreports with an acpidump for any of the devices
needing the bogus IRQ quirk, then I (or you) can check how the IRQ is
declared there, I suspect it will be declared as level-low, just like
with the laptop this patch was written for. And it probably need to
be edge-falling instead of level-low just like this case.
First, I’ve already tried using IRQF_TRIGGER_FALLING, unfortunately it
doesn’t solve the issue for me.
I talked to Elan once, and they confirm the correct IRQ trigger is
level
low. So forcing falling trigger may break other platforms.
As far as I understood Vladislav the quirk he got from Elan as well.
Ok, then this is really weird.
Recently we found that Elan touchpad doesn’t like GpioInt() from its
_CRS.
Once the Interrupt() is used instead, the issue goes away.
IIRC i2c core tries to get interrupt from Interrupt() resource and
then falls back to GpioInt().
See i2c_acpi_get_info() and i2c_device_probe().
Here’s its ASL:
Scope (\_SB.PCI0.I2C4)
{
Device (TPD0)
{
Name (_ADR, One) // _ADR: Address
Name (_HID, "DELL08AE") // _HID: Hardware ID
Name (_CID, "PNP0C50" /* HID Protocol Device (I2C bus) */) // _CID:
Compatible ID
Name (_UID, One) // _UID: Unique ID
Name (_S0W, 0x04) // _S0W: S0 Device Wake State
Name (SBFB, ResourceTemplate ()
{
I2cSerialBusV2 (0x002C, ControllerInitiated, 0x00061A80,
AddressingMode7Bit, "\\_SB.PCI0.I2C4",
0x00, ResourceConsumer, , Exclusive,
)
})
Name (SBFG, ResourceTemplate ()
{
GpioInt (Level, ActiveLow, ExclusiveAndWake, PullUp, 0x,
"\\_SB.GPO1", 0x00, ResourceConsumer, ,
)
{ // Pin list
0x0012
}
})
Name (SBFI, ResourceTemplate ()
{
Interrupt (ResourceConsumer, Level, ActiveLow,
ExclusiveAndWake, ,, )
{
0x003C,
}
})
Method (_INI, 0, NotSerialized) // _INI: Initialize
{
}
Method (_STA, 0, NotSerialized) // _STA: Status
{
If ((TCPD == One))
{
Return (0x0F)
}
Return (Zero)
}
Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings
{
If ((OSYS < 0x07DC))
{
Return (SBFI) /* \_SB_.PCI0.I2C4.TPD0.SBFI */
}
Return (ConcatenateResTemplate (SBFB, SBFG))
}
Method (_DSM, 4, NotSerialized) // _DSM: Device-Specific Method
{
If ((Arg0 == ToUUID ("3cdff6f7-4267-4555-ad05-b30a3d8938de") /*
HID
I2C Device */))
{
If ((Arg2 == Zero))
{
If ((Arg1 == One))
{
Return (Buffer (One)
{
0x03
// .
})
}
Else
{
Return (Buffer (One)
{
0x00
// .
})
}
}
ElseIf ((Arg2 == One))
{
Return (0x20)
}
Else
{
Return (Buffer (One)
linux-next: Tree for Apr 2
Hi all, Changes since 20190401: New tree: nand-fixes The nand tree gained a build failure so I used the version from next-20190401. The drm-misc tree gained a build failure due to an interaction with a change in Linus' tree for which I applied a merge fix patch. Non-merge commits (relative to Linus' tree): 3998 3646 files changed, 123258 insertions(+), 54404 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 300 trees (counting Linus' and 71 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (5e7a8ca31926 Merge branch 'work.aio' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs) Merging fixes/master (b352face4ca9 adfs: mark expected switch fall-throughs) Merging kspp-gustavo/for-next/kspp (2d212a1bac7e NFC: st21nfca: Fix fall-through warnings) Merging kbuild-current/fixes (79a3aaa7b82e Linux 5.1-rc3) Merging arc-current/for-curr (831e90bd606e ARC: PAE40: don't panic and instead turn off hw ioc) Merging arm-current/fixes (d410a8a49e3e ARM: 8849/1: NOMMU: Fix encodings for PMSAv8's PRBAR4/PRLAR4) Merging arm64-fixes/for-next/fixes (9e0a17db517d arm64: replace memblock_alloc_low with memblock_alloc) Merging m68k-current/for-linus (28713169d879 m68k: Add -ffreestanding to CFLAGS) Merging powerpc-fixes/fixes (6f845ebec270 powerpc/pseries/mce: Fix misleading print for TLB mutlihit) Merging sparc/master (7d762d69145a afs: Fix manually set volume location server list) Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2) Merging net/master (8c1074f690bc MAINTAINERS: net: update Solarflare maintainers) Merging bpf/master (d3de85a51a4b Merge branch 'net-stmmac-fix-handling-of-oversized-frames') Merging ipsec/master (025c65e119bf xfrm: Honor original L3 slave device in xfrmi policy lookup) Merging netfilter/master (5f543a54eec0 net: hns3: fix for not calculating tx bd num correctly) Merging ipvs/master (b2e3d68d1251 netfilter: nft_compat: destroy function must not have side effects) Merging wireless-drivers/master (4837696f6b54 Merge tag 'iwlwifi-for-kalle-2019-03-22' of git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes) Merging mac80211/master (53bf5811ca37 cfg80211: add ratelimited variants of err and warn) Merging rdma-fixes/for-rc (1abe186ed8a6 IB/mlx5: Reset access mask when looping inside page fault handler) Merging sound-current/for-linus (e2a829b3da01 ALSA: hda/realtek - Fix speakers on Acer Predator Helios 500 Ryzen laptops) Merging sound-asoc-fixes/for-linus (4259c21f8f7e Merge branch 'asoc-5.1' into asoc-linus) Merging regmap-fixes/for-linus (76da4321eac8 Merge branch 'regmap-5.1' into regmap-linus) Merging regulator-fixes/for-linus (ce84eca9761e Merge branch 'regulator-5.1' into regulator-linus) Merging spi-fixes/for-linus (02b45338db7c Merge branch 'spi-5.1' into spi-linus) Merging pci-current/for-linus (0fa635aec9ab PCI/LINK: Deduplicate bandwidth reports for multi-function devices) Merging driver-core.current/driver-core-linus (79a3aaa7b82e Linux 5.1-rc3) Merging tty.current/tty-linus (79a3aaa7b82e Linux 5.1-rc3) Merging usb.current/usb-linus (79a3aaa7b82e Linux 5.1-rc3) Merging usb-gadget-fixes/fixes (072684e8c58d USB: gadget: f_hid: fix deadlock in f_hidg_write()) Merging usb-serial-fixes/usb-linus (79a3aaa7b82e Linux
[PATCHv3] x86/boot/KASLR: skip the specified crashkernel region
crashkernel=x@y or or =range1:size1[,range2:size2,...]@offset option may
fail to reserve the required memory region if KASLR puts kernel into the
region. To avoid this uncertainty, asking KASLR to skip the required
region.
Signed-off-by: Pingfan Liu
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: "H. Peter Anvin"
Cc: Baoquan He
Cc: Will Deacon
Cc: Nicolas Pitre
Cc: Pingfan Liu
Cc: Chao Fan
Cc: "Kirill A. Shutemov"
Cc: Ard Biesheuvel
Cc: linux-kernel@vger.kernel.org
---
v2 -> v3: adding parsing of crashkernel=range1:size1[,range2:size2,...]@offset
arch/x86/boot/compressed/kaslr.c | 116 ++-
1 file changed, 114 insertions(+), 2 deletions(-)
diff --git a/arch/x86/boot/compressed/kaslr.c b/arch/x86/boot/compressed/kaslr.c
index 2e53c05..7f698f4 100644
--- a/arch/x86/boot/compressed/kaslr.c
+++ b/arch/x86/boot/compressed/kaslr.c
@@ -107,6 +107,7 @@ enum mem_avoid_index {
MEM_AVOID_BOOTPARAMS,
MEM_AVOID_MEMMAP_BEGIN,
MEM_AVOID_MEMMAP_END = MEM_AVOID_MEMMAP_BEGIN + MAX_MEMMAP_REGIONS - 1,
+ MEM_AVOID_CRASHKERNEL,
MEM_AVOID_MAX,
};
@@ -238,6 +239,115 @@ static void parse_gb_huge_pages(char *param, char *val)
}
}
+/* code heavily copied from parse_crashkernel_mem() */
+static void handle_crashkernel_mem(char *cmdline,
+ unsigned long long system_ram,
+ unsigned long long *crash_size,
+ unsigned long long *crash_base)
+{
+ char *tmp, *cur = cmdline;
+
+ /* for each entry of the comma-separated list */
+ do {
+ unsigned long long start, end = ULLONG_MAX, size;
+
+ /* get the start of the range */
+ start = memparse(cur, );
+ /* no value given */
+ if (cur == tmp)
+ return;
+ cur = tmp;
+ if (*cur != '-')
+ return;
+ cur++;
+
+ /* if no ':' is here, than we read the end */
+ if (*cur != ':') {
+ end = memparse(cur, );
+ /* no value given */
+ if (cur == tmp)
+ return;
+ cur = tmp;
+ /* invalid if crashkernel end <= start */
+ if (end <= start)
+ return;
+ }
+ /* expect ":" after range */
+ if (*cur != ':')
+ return;
+ cur++;
+
+ size = memparse(cur, );
+ /* no size value given */
+ if (cur == tmp)
+ return;
+ cur = tmp;
+ if (size >= system_ram)
+ return;
+
+ /* match ? */
+ if (system_ram >= start && system_ram < end) {
+ *crash_size = size;
+ break;
+ }
+ } while (*cur++ == ',');
+
+ if (*crash_size > 0) {
+ while (*cur && *cur != ' ' && *cur != '@')
+ cur++;
+ if (*cur == '@') {
+ cur++;
+ *crash_base = memparse(cur, );
+ }
+ }
+}
+
+/* handle crashkernel=x@y or =range1:size1[,range2:size2,...]@offset options */
+static void mem_avoid_specified_crashkernel_region(char *option)
+{
+ unsigned long long crash_size, crash_base = 0;
+ char*first_colon, *first_space, *cur = option;
+
+ first_colon = strchr(option, ':');
+ first_space = strchr(option, ' ');
+ /* if contain ":" */
+ if (first_colon && (!first_space || first_colon < first_space)) {
+ int i;
+ u64 total_sz = 0;
+ struct boot_e820_entry *entry;
+
+ for (i = 0; i < boot_params->e820_entries; i++) {
+ entry = _params->e820_table[i];
+ /* Skip non-RAM entries. */
+ if (entry->type != E820_TYPE_RAM)
+ continue;
+ total_sz += entry->size;
+ }
+ handle_crashkernel_mem(option, total_sz, _size,
+ _base);
+ } else {
+ crash_size = memparse(option, );
+ if (option == cur)
+ return;
+ while (*cur && *cur != ' ' && *cur != '@')
+ cur++;
+ if (*cur == '@') {
+ option = cur + 1;
+ crash_base = memparse(option, );
+ }
+ }
+ if (crash_base) {
+ mem_avoid[MEM_AVOID_CRASHKERNEL].start = crash_base;
+ mem_avoid[MEM_AVOID_CRASHKERNEL].size = crash_size;
+ } else {
+ /*
+*
Re: [PATCH 068/114] drivers: mfd: Kconfig: pedantic formatting
On Mon, 11 Mar 2019, Enrico Weigelt, metux IT consult wrote: > Formatting of Kconfig files doesn't look so pretty, so let the > Great White Handkerchief come around and clean it up. > > Signed-off-by: Enrico Weigelt, metux IT consult > --- > drivers/mfd/Kconfig | 62 > ++--- > 1 file changed, 31 insertions(+), 31 deletions(-) Applied, thanks. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH] mfd: cros_ec_dev: Add a poll handler to receive MKBP events
On Fri, 08 Mar 2019, Enric Balletbo i Serra wrote: > From: Vincent Palatin > > Allow to poll on the cros_ec device to receive the MKBP events. > > The /dev/cros_[ec|fp|..] file operations now implements the poll > operation. The userspace can now receive specific MKBP events by doing the > following: > - Open the /dev/cros_XX file. > - Call the CROS_EC_DEV_IOCEVENTMASK ioctl with the bitmap of the MKBP > events it wishes to receive as argument. > - Poll on the file descriptor. > - When it gets POLLIN, do a read on the file descriptor, the first > queued event will be returned (using the struct > ec_response_get_next_event format: one byte of event type, then > the payload). > > The read() operation returns at most one event even if there are several > queued, and it might be truncated if the buffer is smaller than the > event (but the caller should know the maximum size of the events it is > reading). > > read() used to return the EC version string, it still does it when no > event mask or an empty event is set for backward compatibility (despite > nobody really using this feature). > > This will be used, for example, by the userspace daemon to receive and > treat the EC_MKBP_EVENT_FINGERPRINT sent by the FP MCU. MFD does not seem like the correct place for this. Maybe this is a good candidate for drivers/platform/chrome/* where the rest of your platform empire now resides. > Signed-off-by: Vincent Palatin > Signed-off-by: Enric Balletbo i Serra > --- > > drivers/mfd/cros_ec_dev.c | 163 +- > drivers/mfd/cros_ec_dev.h | 1 + > 2 files changed, 160 insertions(+), 4 deletions(-) -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
[PATCH v5 6/9] mtd: rawnand: denali_pci: rename goto labels
As Documentation/process/coding-style.rst says, choose label names
which say what the goto does. The out_ label style is already
used in denali_dt.c. Rename likewise for denali_pci.c
Signed-off-by: Masahiro Yamada
---
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None
drivers/mtd/nand/raw/denali_pci.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/mtd/nand/raw/denali_pci.c
b/drivers/mtd/nand/raw/denali_pci.c
index 48e9ac5..02eb599 100644
--- a/drivers/mtd/nand/raw/denali_pci.c
+++ b/drivers/mtd/nand/raw/denali_pci.c
@@ -84,20 +84,20 @@ static int denali_pci_probe(struct pci_dev *dev, const
struct pci_device_id *id)
if (!denali->host) {
dev_err(>dev, "Spectra: ioremap_nocache failed!");
ret = -ENOMEM;
- goto failed_remap_reg;
+ goto out_unmap_reg;
}
ret = denali_init(denali);
if (ret)
- goto failed_remap_mem;
+ goto out_unmap_host;
pci_set_drvdata(dev, denali);
return 0;
-failed_remap_mem:
+out_unmap_host:
iounmap(denali->host);
-failed_remap_reg:
+out_unmap_reg:
iounmap(denali->reg);
return ret;
}
--
2.7.4
[PATCH v5 8/9] mtd: rawnand: denali: remove DENALI_NR_BANKS macro
Use the runtime-detected denali->nbanks instead of hard-coded
DENALI_NR_BANKS (=4).
The actual number of banks depends on the IP configuration, and
can be less than DENALI_NR_BANKS. It is pointless to touch
registers of unsupported banks.
Signed-off-by: Masahiro Yamada
---
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None
drivers/mtd/nand/raw/denali.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/mtd/nand/raw/denali.c b/drivers/mtd/nand/raw/denali.c
index 8722762..e918c3d 100644
--- a/drivers/mtd/nand/raw/denali.c
+++ b/drivers/mtd/nand/raw/denali.c
@@ -40,7 +40,6 @@
#define DENALI_BANK(denali)((denali)->active_bank << 24)
#define DENALI_INVALID_BANK-1
-#define DENALI_NR_BANKS4
static struct denali_chip *to_denali_chip(struct nand_chip *chip)
{
@@ -92,7 +91,7 @@ static void denali_enable_irq(struct denali_controller
*denali)
{
int i;
- for (i = 0; i < DENALI_NR_BANKS; i++)
+ for (i = 0; i < denali->nbanks; i++)
iowrite32(U32_MAX, denali->reg + INTR_EN(i));
iowrite32(GLOBAL_INT_EN_FLAG, denali->reg + GLOBAL_INT_ENABLE);
}
@@ -101,7 +100,7 @@ static void denali_disable_irq(struct denali_controller
*denali)
{
int i;
- for (i = 0; i < DENALI_NR_BANKS; i++)
+ for (i = 0; i < denali->nbanks; i++)
iowrite32(0, denali->reg + INTR_EN(i));
iowrite32(0, denali->reg + GLOBAL_INT_ENABLE);
}
@@ -117,7 +116,7 @@ static void denali_clear_irq_all(struct denali_controller
*denali)
{
int i;
- for (i = 0; i < DENALI_NR_BANKS; i++)
+ for (i = 0; i < denali->nbanks; i++)
denali_clear_irq(denali, i, U32_MAX);
}
@@ -130,7 +129,7 @@ static irqreturn_t denali_isr(int irq, void *dev_id)
spin_lock(>irq_lock);
- for (i = 0; i < DENALI_NR_BANKS; i++) {
+ for (i = 0; i < denali->nbanks; i++) {
irq_status = ioread32(denali->reg + INTR_STATUS(i));
if (irq_status)
ret = IRQ_HANDLED;
--
2.7.4
[PATCH v5 2/9] mtd: rawnand: denali: refactor raw page accessors
The Denali IP adopts the syndrome page layout (payload and ECC are
interleaved). The *_page_raw() and *_oob() callbacks are complicated
because they must hide the underlying layout used by the hardware,
and always return contiguous in-band and out-of-band data.
The Denali IP cannot reuse nand_{read,write}_page_raw_syndrome()
in nand_base.c because its hardware ECC engine skips some of first
bytes in OOB. That is why this driver implements specially-crafted
*_page_raw() and *_oob() hooks.
Currently, similar code is duplicated to reorganize the data layout.
For example, denali_read_page_raw() and denali_write_page_raw() look
almost the same. The complexity is partly due to the DMA transfer
used for better performance of *_page_raw() accessors.
On second thought, we do not need to care about their performance
because MTD_OPS_RAW is rarely used.
Let's focus on code cleanups rather than the performance. This commit
removes the internal buffer for DMA, and factors out as much code as
possible.
Signed-off-by: Masahiro Yamada
---
Changes in v5: None
Changes in v4:
- Do not pass function pointers
- The code simplicity wins over the performance
since the raw accessors are rarely used.
Changes in v3:
- Add comments to denali_raw_payload_op() and denali_oob_payload_op()
Changes in v2: None
drivers/mtd/nand/raw/denali.c | 446 +-
drivers/mtd/nand/raw/denali.h | 1 -
2 files changed, 182 insertions(+), 265 deletions(-)
diff --git a/drivers/mtd/nand/raw/denali.c b/drivers/mtd/nand/raw/denali.c
index 83156f4..6a3520f 100644
--- a/drivers/mtd/nand/raw/denali.c
+++ b/drivers/mtd/nand/raw/denali.c
@@ -287,6 +287,182 @@ static void denali_cmd_ctrl(struct nand_chip *chip, int
dat, unsigned int ctrl)
denali->host_write(denali, DENALI_BANK(denali) | type, dat);
}
+static int denali_change_column(struct nand_chip *chip, unsigned int offset,
+ void *buf, unsigned int len, bool write)
+{
+ if (write)
+ return nand_change_write_column_op(chip, offset, buf, len,
+ false);
+ else
+ return nand_change_read_column_op(chip, offset, buf, len,
+ false);
+}
+
+static int denali_payload_xfer(struct nand_chip *chip, void *buf, bool write)
+{
+ struct denali_nand_info *denali = to_denali(chip);
+ struct mtd_info *mtd = nand_to_mtd(chip);
+ struct nand_ecc_ctrl *ecc = >ecc;
+ int writesize = mtd->writesize;
+ int oob_skip = denali->oob_skip_bytes;
+ int ret, i, pos, len;
+
+ for (i = 0; i < ecc->steps; i++) {
+ pos = i * (ecc->size + ecc->bytes);
+ len = ecc->size;
+
+ if (pos >= writesize) {
+ pos += oob_skip;
+ } else if (pos + len > writesize) {
+ /* This chunk overwraps the BBM area. Must be split */
+ ret = denali_change_column(chip, pos, buf,
+ writesize - pos, write);
+ if (ret)
+ return ret;
+
+ buf += writesize - pos;
+ len -= writesize - pos;
+ pos = writesize + oob_skip;
+ }
+
+ ret = denali_change_column(chip, pos, buf, len, write);
+ if (ret)
+ return ret;
+
+ buf += len;
+ }
+
+ return 0;
+}
+
+static int denali_oob_xfer(struct nand_chip *chip, void *buf, bool write)
+{
+ struct denali_nand_info *denali = to_denali(chip);
+ struct mtd_info *mtd = nand_to_mtd(chip);
+ struct nand_ecc_ctrl *ecc = >ecc;
+ int writesize = mtd->writesize;
+ int oobsize = mtd->oobsize;
+ int oob_skip = denali->oob_skip_bytes;
+ int ret, i, pos, len;
+
+ /* BBM at the beginning of the OOB area */
+ ret = denali_change_column(chip, writesize, buf, oob_skip, write);
+ if (ret)
+ return ret;
+
+ buf += oob_skip;
+
+ for (i = 0; i < ecc->steps; i++) {
+ pos = ecc->size + i * (ecc->size + ecc->bytes);
+
+ if (i == ecc->steps - 1)
+ /* The last chunk includes OOB free */
+ len = writesize + oobsize - pos - oob_skip;
+ else
+ len = ecc->bytes;
+
+ if (pos >= writesize) {
+ pos += oob_skip;
+ } else if (pos + len > writesize) {
+ /* This chunk overwraps the BBM area. Must be split */
+ ret = denali_change_column(chip, pos, buf,
+ writesize - pos, write);
+ if (ret)
+ return ret;
+
+ buf += writesize - pos;
[PATCH v5 1/9] mtd: rawnand: denali: use more nand_chip pointers for internal functions
With the recent refactoring, the NAND driver hooks now take a pointer
to nand_chip. Add to_denali() in order to convert (struct nand_chip *)
to (struct denali_nand_info *) directly. It is more useful than the
current mtd_to_denali().
I changed some helper functions to take (struct nand_chip *). This will
avoid pointer conversion back and forth, and ease further development.
Signed-off-by: Masahiro Yamada
---
Changes in v5:
- pass nand_chip to denali_check_erased_page(),
denali_hw_ecc_fixup(), and denali_hw_ecc_fixup()
instead of passing them both nand_chip and denali_nand_info.
Changes in v4: None
Changes in v3: None
Changes in v2: None
drivers/mtd/nand/raw/denali.c | 61 ---
1 file changed, 34 insertions(+), 27 deletions(-)
diff --git a/drivers/mtd/nand/raw/denali.c b/drivers/mtd/nand/raw/denali.c
index 24aeafc..83156f4 100644
--- a/drivers/mtd/nand/raw/denali.c
+++ b/drivers/mtd/nand/raw/denali.c
@@ -47,6 +47,11 @@ static inline struct denali_nand_info *mtd_to_denali(struct
mtd_info *mtd)
return container_of(mtd_to_nand(mtd), struct denali_nand_info, nand);
}
+static struct denali_nand_info *to_denali(struct nand_chip *chip)
+{
+ return container_of(chip, struct denali_nand_info, nand);
+}
+
/*
* Direct Addressing - the slave address forms the control information (command
* type, bank, block, and page address). The slave data is the actual data to
@@ -282,12 +287,12 @@ static void denali_cmd_ctrl(struct nand_chip *chip, int
dat, unsigned int ctrl)
denali->host_write(denali, DENALI_BANK(denali) | type, dat);
}
-static int denali_check_erased_page(struct mtd_info *mtd,
- struct nand_chip *chip, uint8_t *buf,
+static int denali_check_erased_page(struct nand_chip *chip, u8 *buf,
unsigned long uncor_ecc_flags,
unsigned int max_bitflips)
{
- struct denali_nand_info *denali = mtd_to_denali(mtd);
+ struct denali_nand_info *denali = to_denali(chip);
+ struct mtd_ecc_stats *ecc_stats = _to_mtd(chip)->ecc_stats;
uint8_t *ecc_code = chip->oob_poi + denali->oob_skip_bytes;
int ecc_steps = chip->ecc.steps;
int ecc_size = chip->ecc.size;
@@ -303,9 +308,9 @@ static int denali_check_erased_page(struct mtd_info *mtd,
NULL, 0,
chip->ecc.strength);
if (stat < 0) {
- mtd->ecc_stats.failed++;
+ ecc_stats->failed++;
} else {
- mtd->ecc_stats.corrected += stat;
+ ecc_stats->corrected += stat;
max_bitflips = max_t(unsigned int, max_bitflips, stat);
}
@@ -316,11 +321,11 @@ static int denali_check_erased_page(struct mtd_info *mtd,
return max_bitflips;
}
-static int denali_hw_ecc_fixup(struct mtd_info *mtd,
- struct denali_nand_info *denali,
+static int denali_hw_ecc_fixup(struct nand_chip *chip,
unsigned long *uncor_ecc_flags)
{
- struct nand_chip *chip = mtd_to_nand(mtd);
+ struct denali_nand_info *denali = to_denali(chip);
+ struct mtd_ecc_stats *ecc_stats = _to_mtd(chip)->ecc_stats;
int bank = denali->active_bank;
uint32_t ecc_cor;
unsigned int max_bitflips;
@@ -346,16 +351,17 @@ static int denali_hw_ecc_fixup(struct mtd_info *mtd,
* Unfortunately, we can not know the total number of corrected bits in
* the page. Increase the stats by max_bitflips. (compromised solution)
*/
- mtd->ecc_stats.corrected += max_bitflips;
+ ecc_stats->corrected += max_bitflips;
return max_bitflips;
}
-static int denali_sw_ecc_fixup(struct mtd_info *mtd,
- struct denali_nand_info *denali,
+static int denali_sw_ecc_fixup(struct nand_chip *chip,
unsigned long *uncor_ecc_flags, uint8_t *buf)
{
- unsigned int ecc_size = denali->nand.ecc.size;
+ struct denali_nand_info *denali = to_denali(chip);
+ struct mtd_ecc_stats *ecc_stats = _to_mtd(chip)->ecc_stats;
+ unsigned int ecc_size = chip->ecc.size;
unsigned int bitflips = 0;
unsigned int max_bitflips = 0;
uint32_t err_addr, err_cor_info;
@@ -404,7 +410,7 @@ static int denali_sw_ecc_fixup(struct mtd_info *mtd,
/* correct the ECC error */
flips_in_byte = hweight8(buf[offset] ^ err_cor_value);
buf[offset] ^= err_cor_value;
- mtd->ecc_stats.corrected += flips_in_byte;
+ ecc_stats->corrected += flips_in_byte;
bitflips += flips_in_byte;
max_bitflips = max(max_bitflips, bitflips);
@@
[PATCH v5 5/9] mtd: rawnand: denali: use bool type instead of int where appropriate
Use 'bool' type for the following boolean parameters.
- write (write or read?)
- dma_avail (DMA engine available or not?)
Signed-off-by: Masahiro Yamada
---
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2:
- Use bool for dma_avail as well
drivers/mtd/nand/raw/denali.c | 23 ---
drivers/mtd/nand/raw/denali.h | 4 ++--
2 files changed, 14 insertions(+), 13 deletions(-)
diff --git a/drivers/mtd/nand/raw/denali.c b/drivers/mtd/nand/raw/denali.c
index b9bc406..a501d9e 100644
--- a/drivers/mtd/nand/raw/denali.c
+++ b/drivers/mtd/nand/raw/denali.c
@@ -533,7 +533,7 @@ static int denali_sw_ecc_fixup(struct nand_chip *chip,
}
static void denali_setup_dma64(struct denali_nand_info *denali,
- dma_addr_t dma_addr, int page, int write)
+ dma_addr_t dma_addr, int page, bool write)
{
uint32_t mode;
const int page_count = 1;
@@ -547,7 +547,8 @@ static void denali_setup_dma64(struct denali_nand_info
*denali,
*burst len = 64 bytes, the number of pages
*/
denali->host_write(denali, mode,
- 0x01002000 | (64 << 16) | (write << 8) | page_count);
+ 0x01002000 | (64 << 16) |
+ (write ? BIT(8) : 0) | page_count);
/* 2. set memory low address */
denali->host_write(denali, mode, lower_32_bits(dma_addr));
@@ -557,7 +558,7 @@ static void denali_setup_dma64(struct denali_nand_info
*denali,
}
static void denali_setup_dma32(struct denali_nand_info *denali,
- dma_addr_t dma_addr, int page, int write)
+ dma_addr_t dma_addr, int page, bool write)
{
uint32_t mode;
const int page_count = 1;
@@ -568,7 +569,7 @@ static void denali_setup_dma32(struct denali_nand_info
*denali,
/* 1. setup transfer type and # of pages */
denali->host_write(denali, mode | page,
- 0x2000 | (write << 8) | page_count);
+ 0x2000 | (write ? BIT(8) : 0) | page_count);
/* 2. set memory high address bits 23:8 */
denali->host_write(denali, mode | ((dma_addr >> 16) << 8), 0x2200);
@@ -628,7 +629,7 @@ static int denali_pio_write(struct denali_nand_info
*denali, const u32 *buf,
}
static int denali_pio_xfer(struct denali_nand_info *denali, void *buf,
- size_t size, int page, int write)
+ size_t size, int page, bool write)
{
if (write)
return denali_pio_write(denali, buf, size, page);
@@ -637,7 +638,7 @@ static int denali_pio_xfer(struct denali_nand_info *denali,
void *buf,
}
static int denali_dma_xfer(struct denali_nand_info *denali, void *buf,
- size_t size, int page, int write)
+ size_t size, int page, bool write)
{
dma_addr_t dma_addr;
uint32_t irq_mask, irq_status, ecc_err_mask;
@@ -694,7 +695,7 @@ static int denali_dma_xfer(struct denali_nand_info *denali,
void *buf,
}
static int denali_page_xfer(struct nand_chip *chip, void *buf, size_t size,
- int page, int write)
+ int page, bool write)
{
struct denali_nand_info *denali = to_denali(chip);
@@ -715,7 +716,7 @@ static int denali_read_page(struct nand_chip *chip, uint8_t
*buf,
int stat = 0;
int ret;
- ret = denali_page_xfer(chip, buf, mtd->writesize, page, 0);
+ ret = denali_page_xfer(chip, buf, mtd->writesize, page, false);
if (ret && ret != -EBADMSG)
return ret;
@@ -744,7 +745,7 @@ static int denali_write_page(struct nand_chip *chip, const
uint8_t *buf,
{
struct mtd_info *mtd = nand_to_mtd(chip);
- return denali_page_xfer(chip, (void *)buf, mtd->writesize, page, 1);
+ return denali_page_xfer(chip, (void *)buf, mtd->writesize, page, true);
}
static int denali_setup_data_interface(struct nand_chip *chip, int chipnr,
@@ -1001,7 +1002,7 @@ static int denali_attach_chip(struct nand_chip *chip)
int ret;
if (ioread32(denali->reg + FEATURES) & FEATURES__DMA)
- denali->dma_avail = 1;
+ denali->dma_avail = true;
if (denali->dma_avail) {
int dma_bit = denali->caps & DENALI_CAP_DMA_64BIT ? 64 : 32;
@@ -1010,7 +1011,7 @@ static int denali_attach_chip(struct nand_chip *chip)
if (ret) {
dev_info(denali->dev,
"Failed to set DMA mask. Disabling DMA.\n");
- denali->dma_avail = 0;
+ denali->dma_avail = false;
}
}
diff --git a/drivers/mtd/nand/raw/denali.h b/drivers/mtd/nand/raw/denali.h
index 4447184..d2603c6 100644
--- a/drivers/mtd/nand/raw/denali.h
+++ b/drivers/mtd/nand/raw/denali.h
@@ -303,7 +303,7 @@
[PATCH v5 7/9] mtd: rawnand: denali: decouple controller and NAND chips
Currently, this driver sticks to the legacy NAND model because it was
upstreamed before commit 2d472aba15ff ("mtd: nand: document the NAND
controller/NAND chip DT representation"). However, relying on the
dummy_controller is already deprecated.
Switch over to the new controller/chip representation.
The struct denali_nand_info has been split into denali_controller
and denali_chip, to contain the controller data, per-chip data,
respectively.
One problem is, this commit changes the DT binding. So, as always,
the backward compatibility must be taken into consideration.
In the new binding, the controller node expects
#address-cells = <1>;
#size-cells = <0>;
... since the child nodes represent NAND chips.
In the old binding, the controller node may have subnodes, but they
are MTD partitions.
The denali_dt_is_legacy_binding() exploits it to distinguish old/new
platforms.
Going forward, the old binding is only allowed for existing DT files.
I updated the binding document.
Signed-off-by: Masahiro Yamada
Acked-by: Rob Herring
---
Changes in v5: None
Changes in v4: None
Changes in v3:
- simplify mtd->name fallback
- Add Rob's Ack
Changes in v2: None
.../devicetree/bindings/mtd/denali-nand.txt| 40 +-
drivers/mtd/nand/raw/denali.c | 430 -
drivers/mtd/nand/raw/denali.h | 114 +-
drivers/mtd/nand/raw/denali_dt.c | 98 -
drivers/mtd/nand/raw/denali_pci.c | 30 +-
5 files changed, 482 insertions(+), 230 deletions(-)
diff --git a/Documentation/devicetree/bindings/mtd/denali-nand.txt
b/Documentation/devicetree/bindings/mtd/denali-nand.txt
index f33da87..b14b675 100644
--- a/Documentation/devicetree/bindings/mtd/denali-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/denali-nand.txt
@@ -7,34 +7,48 @@ Required properties:
"socionext,uniphier-denali-nand-v5b" - for Socionext UniPhier (v5b)
- reg : should contain registers location and length for data and reg.
- reg-names: Should contain the reg names "nand_data" and "denali_reg"
+ - #address-cells: should be 1. The cell encodes the chip select connection.
+ - #size-cells : should be 0.
- interrupts : The interrupt number.
- clocks: should contain phandle of the controller core clock, the bus
interface clock, and the ECC circuit clock.
- clock-names: should contain "nand", "nand_x", "ecc"
-Optional properties:
- - nand-ecc-step-size: see nand.txt for details. If present, the value must
be
- 512for "altr,socfpga-denali-nand"
- 1024 for "socionext,uniphier-denali-nand-v5a"
- 1024 for "socionext,uniphier-denali-nand-v5b"
- - nand-ecc-strength: see nand.txt for details. Valid values are:
- 8, 15 for "altr,socfpga-denali-nand"
- 8, 16, 24 for "socionext,uniphier-denali-nand-v5a"
- 8, 16 for "socionext,uniphier-denali-nand-v5b"
- - nand-ecc-maximize: see nand.txt for details
-
-The device tree may optionally contain sub-nodes describing partitions of the
+Sub-nodes:
+ Sub-nodes represent available NAND chips.
+
+ Required properties:
+- reg: should contain the bank ID of the controller to which each chip
+ select is connected.
+
+ Optional properties:
+- nand-ecc-step-size: see nand.txt for details.
+ If present, the value must be
+512for "altr,socfpga-denali-nand"
+1024 for "socionext,uniphier-denali-nand-v5a"
+1024 for "socionext,uniphier-denali-nand-v5b"
+- nand-ecc-strength: see nand.txt for details. Valid values are:
+8, 15 for "altr,socfpga-denali-nand"
+8, 16, 24 for "socionext,uniphier-denali-nand-v5a"
+8, 16 for "socionext,uniphier-denali-nand-v5b"
+- nand-ecc-maximize: see nand.txt for details
+
+The chip nodes may optionally contain sub-nodes describing partitions of the
address space. See partition.txt for more detail.
Examples:
nand: nand@ff90 {
#address-cells = <1>;
- #size-cells = <1>;
+ #size-cells = <0>;
compatible = "altr,socfpga-denali-nand";
reg = <0xff90 0x20>, <0xffb8 0x1000>;
reg-names = "nand_data", "denali_reg";
clocks = <_clk>, <_x_clk>, <_ecc_clk>;
clock-names = "nand", "nand_x", "ecc";
interrupts = <0 144 4>;
+
+ nand@0 {
+ reg = <0>;
+ }
};
diff --git a/drivers/mtd/nand/raw/denali.c b/drivers/mtd/nand/raw/denali.c
index a501d9e..8722762 100644
--- a/drivers/mtd/nand/raw/denali.c
+++ b/drivers/mtd/nand/raw/denali.c
@@ -3,7 +3,7 @@
* NAND Flash Controller Device Driver
* Copyright © 2009-2010, Intel Corporation and its suppliers.
*
- * Copyright (c) 2017 Socionext Inc.
+ * Copyright (c) 2017-2019 Socionext Inc.
* Reworked by Masahiro Yamada
*/
@@ -42,14 +42,15 @@
#define DENALI_INVALID_BANK-1
#define DENALI_NR_BANKS4
-static inline struct denali_nand_info
[PATCH v5 3/9] mtd: rawnand: denali: remove unneeded casts in denali_{read,write}_pio
Since (u32 *) can accept an opaque pointer, the explicit casting
from (void *) to (u32 *) is redundant. Change the function argument type
to remove the casts.
Signed-off-by: Masahiro Yamada
---
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None
drivers/mtd/nand/raw/denali.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/mtd/nand/raw/denali.c b/drivers/mtd/nand/raw/denali.c
index 6a3520f..1422015 100644
--- a/drivers/mtd/nand/raw/denali.c
+++ b/drivers/mtd/nand/raw/denali.c
@@ -654,11 +654,10 @@ static void denali_setup_dma32(struct denali_nand_info
*denali,
denali->host_write(denali, mode | 0x14000, 0x2400);
}
-static int denali_pio_read(struct denali_nand_info *denali, void *buf,
+static int denali_pio_read(struct denali_nand_info *denali, u32 *buf,
size_t size, int page)
{
u32 addr = DENALI_MAP01 | DENALI_BANK(denali) | page;
- uint32_t *buf32 = (uint32_t *)buf;
uint32_t irq_status, ecc_err_mask;
int i;
@@ -670,7 +669,7 @@ static int denali_pio_read(struct denali_nand_info *denali,
void *buf,
denali_reset_irq(denali);
for (i = 0; i < size / 4; i++)
- *buf32++ = denali->host_read(denali, addr);
+ buf[i] = denali->host_read(denali, addr);
irq_status = denali_wait_for_irq(denali, INTR__PAGE_XFER_INC);
if (!(irq_status & INTR__PAGE_XFER_INC))
@@ -682,18 +681,17 @@ static int denali_pio_read(struct denali_nand_info
*denali, void *buf,
return irq_status & ecc_err_mask ? -EBADMSG : 0;
}
-static int denali_pio_write(struct denali_nand_info *denali,
- const void *buf, size_t size, int page)
+static int denali_pio_write(struct denali_nand_info *denali, const u32 *buf,
+ size_t size, int page)
{
u32 addr = DENALI_MAP01 | DENALI_BANK(denali) | page;
- const uint32_t *buf32 = (uint32_t *)buf;
uint32_t irq_status;
int i;
denali_reset_irq(denali);
for (i = 0; i < size / 4; i++)
- denali->host_write(denali, addr, *buf32++);
+ denali->host_write(denali, addr, buf[i]);
irq_status = denali_wait_for_irq(denali,
INTR__PROGRAM_COMP | INTR__PROGRAM_FAIL);
--
2.7.4
[PATCH v5 0/9] mtd: rawnand: denali: exec_op(), controller/chip separation, and cleanups
I took time for the Denali driver to catch up with the latest framework.
- switch over to exec_op() and remove legacy hooks
- separate controller/chips
- various cleanups
Major changes in v5:
- Passing both nand_chip and denali is redundant.
Pass only nand_chip to local helpers.
Major changes in v4:
- Add denali_exec_out() and denali_exec_in()
in order to make denali_exec_instr() readable
- Make .read_page_raw() and .write_page_raw() even simpler
by giving up the performance
Major changes in v3:
- Drop "mtd: rawnand: denali: use more precise timeout for
NAND_OP_WAITRDT_INSTR"
entirely according to the review comments in v2
- Add comments to helpers in 2/9
Masahiro Yamada (9):
mtd: rawnand: denali: use more nand_chip pointers for internal
functions
mtd: rawnand: denali: refactor raw page accessors
mtd: rawnand: denali: remove unneeded casts in denali_{read,write}_pio
mtd: rawnand: denali: switch over to ->exec_op() from legacy hooks
mtd: rawnand: denali: use bool type instead of int where appropriate
mtd: rawnand: denali_pci: rename goto labels
mtd: rawnand: denali: decouple controller and NAND chips
mtd: rawnand: denali: remove DENALI_NR_BANKS macro
mtd: rawnand: denali: clean up coding style
.../devicetree/bindings/mtd/denali-nand.txt| 40 +-
drivers/mtd/nand/raw/denali.c | 1146 ++--
drivers/mtd/nand/raw/denali.h | 117 +-
drivers/mtd/nand/raw/denali_dt.c | 98 +-
drivers/mtd/nand/raw/denali_pci.c | 38 +-
5 files changed, 823 insertions(+), 616 deletions(-)
--
2.7.4
[PATCH v5 9/9] mtd: rawnand: denali: clean up coding style
Eliminate the following reports from 'scripts/checkpatch.pl --strict'.
CHECK: Prefer kernel type 'u8' over 'uint8_t'
CHECK: Prefer kernel type 'u32' over 'uint32_t'
CHECK: Alignment should match open parenthesis
I slightly changed denali_check_erased_page() to shorten it.
Signed-off-by: Masahiro Yamada
---
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None
drivers/mtd/nand/raw/denali.c | 54 +--
1 file changed, 26 insertions(+), 28 deletions(-)
diff --git a/drivers/mtd/nand/raw/denali.c b/drivers/mtd/nand/raw/denali.c
index e918c3d..132956d 100644
--- a/drivers/mtd/nand/raw/denali.c
+++ b/drivers/mtd/nand/raw/denali.c
@@ -106,7 +106,7 @@ static void denali_disable_irq(struct denali_controller
*denali)
}
static void denali_clear_irq(struct denali_controller *denali,
-int bank, uint32_t irq_status)
+int bank, u32 irq_status)
{
/* write one to clear bits */
iowrite32(irq_status, denali->reg + INTR_STATUS(bank));
@@ -124,7 +124,7 @@ static irqreturn_t denali_isr(int irq, void *dev_id)
{
struct denali_controller *denali = dev_id;
irqreturn_t ret = IRQ_NONE;
- uint32_t irq_status;
+ u32 irq_status;
int i;
spin_lock(>irq_lock);
@@ -163,7 +163,7 @@ static void denali_reset_irq(struct denali_controller
*denali)
static u32 denali_wait_for_irq(struct denali_controller *denali, u32 irq_mask)
{
unsigned long time_left, flags;
- uint32_t irq_status;
+ u32 irq_status;
spin_lock_irqsave(>irq_lock, flags);
@@ -411,20 +411,17 @@ static int denali_check_erased_page(struct nand_chip
*chip, u8 *buf,
{
struct denali_controller *denali = to_denali_controller(chip);
struct mtd_ecc_stats *ecc_stats = _to_mtd(chip)->ecc_stats;
- uint8_t *ecc_code = chip->oob_poi + denali->oob_skip_bytes;
- int ecc_steps = chip->ecc.steps;
- int ecc_size = chip->ecc.size;
- int ecc_bytes = chip->ecc.bytes;
+ struct nand_ecc_ctrl *ecc = >ecc;
+ u8 *ecc_code = chip->oob_poi + denali->oob_skip_bytes;
int i, stat;
- for (i = 0; i < ecc_steps; i++) {
+ for (i = 0; i < ecc->steps; i++) {
if (!(uncor_ecc_flags & BIT(i)))
continue;
- stat = nand_check_erased_ecc_chunk(buf, ecc_size,
- ecc_code, ecc_bytes,
- NULL, 0,
- chip->ecc.strength);
+ stat = nand_check_erased_ecc_chunk(buf, ecc->size, ecc_code,
+ ecc->bytes, NULL, 0,
+ ecc->strength);
if (stat < 0) {
ecc_stats->failed++;
} else {
@@ -432,8 +429,8 @@ static int denali_check_erased_page(struct nand_chip *chip,
u8 *buf,
max_bitflips = max_t(unsigned int, max_bitflips, stat);
}
- buf += ecc_size;
- ecc_code += ecc_bytes;
+ buf += ecc->size;
+ ecc_code += ecc->bytes;
}
return max_bitflips;
@@ -445,7 +442,7 @@ static int denali_hw_ecc_fixup(struct nand_chip *chip,
struct denali_controller *denali = to_denali_controller(chip);
struct mtd_ecc_stats *ecc_stats = _to_mtd(chip)->ecc_stats;
int bank = denali->active_bank;
- uint32_t ecc_cor;
+ u32 ecc_cor;
unsigned int max_bitflips;
ecc_cor = ioread32(denali->reg + ECC_COR_INFO(bank));
@@ -475,18 +472,18 @@ static int denali_hw_ecc_fixup(struct nand_chip *chip,
}
static int denali_sw_ecc_fixup(struct nand_chip *chip,
- unsigned long *uncor_ecc_flags, uint8_t *buf)
+ unsigned long *uncor_ecc_flags, u8 *buf)
{
struct denali_controller *denali = to_denali_controller(chip);
struct mtd_ecc_stats *ecc_stats = _to_mtd(chip)->ecc_stats;
unsigned int ecc_size = chip->ecc.size;
unsigned int bitflips = 0;
unsigned int max_bitflips = 0;
- uint32_t err_addr, err_cor_info;
+ u32 err_addr, err_cor_info;
unsigned int err_byte, err_sector, err_device;
- uint8_t err_cor_value;
+ u8 err_cor_value;
unsigned int prev_sector = 0;
- uint32_t irq_status;
+ u32 irq_status;
denali_reset_irq(denali);
@@ -551,7 +548,7 @@ static int denali_sw_ecc_fixup(struct nand_chip *chip,
static void denali_setup_dma64(struct denali_controller *denali,
dma_addr_t dma_addr, int page, bool write)
{
- uint32_t mode;
+ u32 mode;
const int page_count = 1;
mode = DENALI_MAP10 | DENALI_BANK(denali) | page;
@@ -576,7 +573,7 @@ static void
[PATCH v5 4/9] mtd: rawnand: denali: switch over to ->exec_op() from legacy hooks
Implement ->exec_op(), and remove the deprecated hooks.
Signed-off-by: Masahiro Yamada
---
Changes in v5: None
Changes in v4:
- add denali_exec_in() and denali_exec_out()
- avoid ternary operator to select function
Changes in v3:
- Fix byte-swap in denali_exec_in16()
Changes in v2: None
drivers/mtd/nand/raw/denali.c | 251 --
1 file changed, 143 insertions(+), 108 deletions(-)
diff --git a/drivers/mtd/nand/raw/denali.c b/drivers/mtd/nand/raw/denali.c
index 1422015..b9bc406 100644
--- a/drivers/mtd/nand/raw/denali.c
+++ b/drivers/mtd/nand/raw/denali.c
@@ -206,85 +206,11 @@ static uint32_t denali_wait_for_irq(struct
denali_nand_info *denali,
return denali->irq_status;
}
-static void denali_read_buf(struct nand_chip *chip, uint8_t *buf, int len)
+static void denali_select_target(struct nand_chip *chip, int cs)
{
- struct mtd_info *mtd = nand_to_mtd(chip);
- struct denali_nand_info *denali = mtd_to_denali(mtd);
- u32 addr = DENALI_MAP11_DATA | DENALI_BANK(denali);
- int i;
-
- for (i = 0; i < len; i++)
- buf[i] = denali->host_read(denali, addr);
-}
-
-static void denali_write_buf(struct nand_chip *chip, const uint8_t *buf,
-int len)
-{
- struct denali_nand_info *denali = mtd_to_denali(nand_to_mtd(chip));
- u32 addr = DENALI_MAP11_DATA | DENALI_BANK(denali);
- int i;
-
- for (i = 0; i < len; i++)
- denali->host_write(denali, addr, buf[i]);
-}
-
-static void denali_read_buf16(struct nand_chip *chip, uint8_t *buf, int len)
-{
- struct denali_nand_info *denali = mtd_to_denali(nand_to_mtd(chip));
- u32 addr = DENALI_MAP11_DATA | DENALI_BANK(denali);
- uint16_t *buf16 = (uint16_t *)buf;
- int i;
-
- for (i = 0; i < len / 2; i++)
- buf16[i] = denali->host_read(denali, addr);
-}
-
-static void denali_write_buf16(struct nand_chip *chip, const uint8_t *buf,
- int len)
-{
- struct denali_nand_info *denali = mtd_to_denali(nand_to_mtd(chip));
- u32 addr = DENALI_MAP11_DATA | DENALI_BANK(denali);
- const uint16_t *buf16 = (const uint16_t *)buf;
- int i;
-
- for (i = 0; i < len / 2; i++)
- denali->host_write(denali, addr, buf16[i]);
-}
-
-static uint8_t denali_read_byte(struct nand_chip *chip)
-{
- uint8_t byte;
-
- denali_read_buf(chip, , 1);
-
- return byte;
-}
-
-static void denali_write_byte(struct nand_chip *chip, uint8_t byte)
-{
- denali_write_buf(chip, , 1);
-}
-
-static void denali_cmd_ctrl(struct nand_chip *chip, int dat, unsigned int ctrl)
-{
- struct denali_nand_info *denali = mtd_to_denali(nand_to_mtd(chip));
- uint32_t type;
-
- if (ctrl & NAND_CLE)
- type = DENALI_MAP11_CMD;
- else if (ctrl & NAND_ALE)
- type = DENALI_MAP11_ADDR;
- else
- return;
-
- /*
-* Some commands are followed by chip->legacy.waitfunc.
-* irq_status must be cleared here to catch the R/B# interrupt later.
-*/
- if (ctrl & NAND_CTRL_CHANGE)
- denali_reset_irq(denali);
+ struct denali_nand_info *denali = to_denali(chip);
- denali->host_write(denali, DENALI_BANK(denali) | type, dat);
+ denali->active_bank = cs;
}
static int denali_change_column(struct nand_chip *chip, unsigned int offset,
@@ -772,6 +698,8 @@ static int denali_page_xfer(struct nand_chip *chip, void
*buf, size_t size,
{
struct denali_nand_info *denali = to_denali(chip);
+ denali_select_target(chip, chip->cur_cs);
+
if (denali->dma_avail)
return denali_dma_xfer(denali, buf, size, page, write);
else
@@ -819,24 +747,6 @@ static int denali_write_page(struct nand_chip *chip, const
uint8_t *buf,
return denali_page_xfer(chip, (void *)buf, mtd->writesize, page, 1);
}
-static void denali_select_chip(struct nand_chip *chip, int cs)
-{
- struct denali_nand_info *denali = mtd_to_denali(nand_to_mtd(chip));
-
- denali->active_bank = cs;
-}
-
-static int denali_waitfunc(struct nand_chip *chip)
-{
- struct denali_nand_info *denali = mtd_to_denali(nand_to_mtd(chip));
- uint32_t irq_status;
-
- /* R/B# pin transitioned from low to high? */
- irq_status = denali_wait_for_irq(denali, INTR__INT_ACT);
-
- return irq_status & INTR__INT_ACT ? 0 : NAND_STATUS_FAIL;
-}
-
static int denali_setup_data_interface(struct nand_chip *chip, int chipnr,
const struct nand_data_interface *conf)
{
@@ -1149,13 +1059,6 @@ static int denali_attach_chip(struct nand_chip *chip)
mtd_set_ooblayout(mtd, _ooblayout_ops);
- if (chip->options & NAND_BUSWIDTH_16) {
- chip->legacy.read_buf = denali_read_buf16;
- chip->legacy.write_buf = denali_write_buf16;
- } else {
-
Re: [BUG] gpiolib: spi chip select legacy support breaks modern chip select and whitens the GTA04 LCD panel
(CC Kumar and Wolfgang who came up with spi-active-low, I think.) On Sun, Mar 24, 2019 at 1:56 PM H. Nikolaus Schaller wrote: > > Am 24.03.2019 um 05:15 schrieb Linus Walleij : > > But I fixed it in that case by introducing a spi-cs-high into the DTS file: > > https://marc.info/?l=linux-arm-kernel=155292310015309=2 > > Yes, that of course works and is our temporary solution. > > And I see that you also have it on the controller node and not the slave node. Yes I git it wrong, the slave should have it and another bug of mine made it look at the controller not (some days I should not write code in paths that do not get executed). > > I'm sorry about that, however if you look at the DT binding document: > > Documentation/devicetree/bindings/spi/spi-bus.txt > > Shouldn't it be a property of the slave node and not the controller node? Indeed. > > You will see that spi-cs-high is mandatory. So these DTS files are > > incorrect. > > How do you read that it is mandatory from > > "All slave nodes can contain the following optional properties: > - spi-cs-high - Empty property indicating device requires chip select > active high." > > I read it as optional and indicative. Equal priority to cs-gpios. The basic problem is that spi-cs-high is defined negatively, so by default a CS GPIO is active low. This clashes with the default GPIO flag, as GPIO_ACTIVE_HIGH is zero, no flag, and thus the default if nothing is specified, so if the GPIO flag is zero it should be active high, but if "spi-active-high" is not on the slave node it should be active low, so one of them have to win, they can't both win. I'd say that spi-cs-high existed before we standardized the GPIO flags in the DT bindings. So people were relying on it for years before we came up with the ACTIVE_HIGH/LOW flags. commit f618ebfcbf9616a0fa9a78f5ecb69762f0fa3c59 Author: Wolfgang Ocker Date: Wed Oct 15 15:00:47 2008 +0200 of/spi: Support specifying chip select as active high via device tree The patch allows to specify that an SPI device needs an active high chip select. Signed-off-by: Wolfgang Ocker Signed-off-by: Kumar Gala While the GPIO binding turns up 5 years later: commit 71fab21fee07fd6d5f1a984db387cc5e4596f3fa Author: Stephen Warren Date: Tue Feb 12 17:22:36 2013 -0700 ARM: dt: add header to define GPIO flags Many GPIO device tree bindings use the same flags. Create a header to define those. Signed-off-by: Stephen Warren Acked-by: Rob Herring And then this guy think it is a good idea to standardize this for all GPIO phandles two years later: commit 69d301fdd19635a39cb2b78e53fdd625b7a27924 Author: Linus Walleij Date: Thu Sep 24 15:05:45 2015 -0700 gpio: add DT bindings for existing consumer flags It is customary for GPIO controllers to support open drain/collector and open source/emitter configurations. Add standard GPIO line flags to account for this and augment the documentation to say that these are the most generic bindings. Several people approached me to add new flags to the lines, and this makes sense, but let's first bind up the most common cases before we start to add exotic stuff. Thanks to H. Nikolaus Schaller for ideas on how to encode single-ended wiring such as open drain/source and open collector/emitter. Cc: Tony Lindgren Cc: Grygorii Strashko Cc: H. Nikolaus Schaller Signed-off-by: Linus Walleij > > This does not work because there are devices that requires spi-cs-high to be > > respected and the DTS second cell GPIO flag to be ignored. > > Then, those should be fixed... This can't be done because some old systems (mostly powerpc) added between 2008-2013 do not know about GPIO flags and have DTBs deployed in firmware that need to keep working. They cannot be fixed. > > They might have deployed DTB binaries that need to keep working, > > Well, that is a weak argument. What if the GTA04 would have the DTB in FLASH > and would need it working (fortunately we always reflash kernel + dtbs)? Usually the definition I use for "deployed DTB" is not "deployed on my desk" but "deployed by a factory" i.e. someone producing millions of TV sets or something. For example my monitor is using a PowerPC CPU and has one of these DTBs in flash, and expect it to keep working if I upgrade the kernel separately. > BTW, on which node do these invariable DTBs have the spi-cs-high flag? > In the controller node (IMHO wrong) or the slave node (according to bindings > doc)? Slave node I hope, the controller thing was just one of my stupid mistakes. > I have checked with randomly picked imx51-babbage.dts and it has it in the > slave node (pmic: mc13892@0). It also seems to be an example where different > CS lines want different settings. I'm afraid the consumers of the old powerpc DTS files are not even maintained inside the Linux kernel, as we sometimes assume. Those were created and dispersed by
Re: [PATCH 2/2] mfd: cros_ec: instantiate properly CrOS Touchpad MCU device
On Thu, 07 Mar 2019, Enric Balletbo i Serra wrote: > From: Wei-Ning Huang > > Support Touchpad MCU as a special of CrOS EC devices. The current > Touchpad MCU is used on Eve Chromebook and used the same protocol as > other CrOS EC devices. > > When a MCU has touchpad support (aka EC_FEATURE_TOUCHPAD), it is > instantiated as a special CrOS EC device with device name 'cros_tp'. So > regardless of the probing order between the actual cros_ec and cros_tp, > the userspace and other kernel drivers should not confuse them. > > Signed-off-by: Wei-Ning Huang > Signed-off-by: Enric Balletbo i Serra > --- > > drivers/mfd/cros_ec_dev.c | 10 ++ > include/linux/mfd/cros_ec.h | 1 + > 2 files changed, 11 insertions(+) Applied, thanks. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH 1/2] mfd: cros_ec: instantiate properly CrOS FP MCU device
On Thu, 07 Mar 2019, Enric Balletbo i Serra wrote: > From: Vincent Palatin > > Support Fingerprint MCU as a special of CrOS EC devices. The current FP > MCU uses the same EC SPI protocol v3 as other CrOS EC devices on a SPI > bus. > > When a MCU has fingerprint support (aka EC_FEATURE_FINGERPRINT), it is > instantiated as a special CrOS EC device with device name 'cros_fp'. So > regardless of the probing order between the actual cros_ec and cros_fp, > the userspace and other kernel drivers should not confuse them. > > Signed-off-by: Vincent Palatin > Signed-off-by: Enric Balletbo i Serra > --- > > drivers/mfd/cros_ec_dev.c | 10 ++ > include/linux/mfd/cros_ec.h | 1 + > 2 files changed, 11 insertions(+) Applied, thanks. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH v2 3/4] Makefile: lld: tell clang to use lld
On Sat, Feb 16, 2019 at 10:09 AM Masahiro Yamada wrote: > > On Thu, Feb 14, 2019 at 8:08 AM Nick Desaulniers > wrote: > > > > On Wed, Feb 13, 2019 at 6:59 AM Masahiro Yamada > > wrote: > > > > > > On Tue, Feb 12, 2019 at 5:42 AM wrote: > > > > > > > > This is needed because clang doesn't select which linker to use based on > > > > $LD but rather -fuse-ld=lld. This is problematic especially for > > > > cc-ldoption, which checks for linker flag support via invoking the > > > > compiler, rather than the linker. > > > > > > > > > Sorry, please explain what kind of problem > > > this patch solves. > > > > > > > > > > > > [1] $(LD) is used to link vmlinux, modules, etc. > > > > > > [2] $(CC) is used to link vdso, etc. > > > and -fuse-ld= selects which linker is invoked from $(CC) > > > > It solves case 2. > > > > > > > > > > > Is it a problem to use a different > > > type of linker for [1] and [2] ? > > > > Ideally, no, but I can think of at least one case where it might be > > problematic to mix linkers like that: > > You might be mixing linker flags added via ld-option from one linker > > that aren't actually supported by the other linker. > > You can do this only when you are sure > that the _exactly_ same linker is used. > > In my understanding, -fuse-ld=lld does not guarantee it. I really don't think we should be mixing and matching linkers during a kernel build. When we compile with clang, we don't have escape hatches that allow for some object files to be compiled with GCC (mixing clang and GCC compiled object files into one build). Following the same logic, I think mixing linkers during kernel build should similarly be dissuaded. This patch AVOIDS clang using a different linker than what was specified via $LD, which is CRITICAL for cc-ldoption kbuild macro. Masahiro, I hope this patch can be re-evaluated, or if I'm not understanding your point, that you can provide additional clarification. -- Thanks, ~Nick Desaulniers
Re: [PATCH] mfd: sm501: Fix potential NULL pointer dereference
On Sat, 02 Mar 2019, Aditya Pakki wrote: > lookup variable on failure of allocating memory via devm_kzalloc > can cause a NULL pointer dereference. This patch avoids such a scenario. > > Signed-off-by: Aditya Pakki > --- > drivers/mfd/sm501.c | 3 +++ > 1 file changed, 3 insertions(+) Applied, thanks. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH] mfd: twl-core: disable irq while suspended
On Sat, 23 Feb 2019, Andreas Kemnade wrote:
> Since commit
> 6e2bd956936 ("i2c: omap: Use noirq system sleep pm ops to idle device for
> suspend")
> on gta04 we have handle_twl4030_pih() called in situations where
> pm_runtime_get()
> in i2c-omap.c returns -EACCES.
> [ 86.474365] Freezing remaining freezable tasks ... (elapsed 0.002 seconds)
> done.
> [ 86.485473] printk: Suspending console(s) (use no_console_suspend to debug)
> [ 86.72] Disabling non-boot CPUs ...
> [ 86.555664] Successfully put all powerdomains to target state
> [ 86.563720] twl: Read failed (mod 1, reg 0x01 count 1)
> [ 86.563751] twl4030: I2C error -13 reading PIH ISR
> [ 86.563812] twl: Read failed (mod 1, reg 0x01 count 1)
> [ 86.563812] twl4030: I2C error -13 reading PIH ISR
> [ 86.563873] twl: Read failed (mod 1, reg 0x01 count 1)
> [ 86.563903] twl4030: I2C error -13 reading PIH ISR
>
> This happens when we wakeup via something behing twl4030
> (powerbutton or rtc alarm).
> This goes on for minutes until the system is finally resumed.
> Disable the irq on suspend and enable it on resume to avoid
> having i2c access problems when the irq registers are checked.
>
> Signed-off-by: Andreas Kemnade
> ---
> drivers/mfd/twl-core.c | 23 +++
> 1 file changed, 23 insertions(+)
Applied, thanks.
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH v4 1/9] mtd: rawnand: denali: use nand_chip pointer more for internal functions
On Tue, Apr 2, 2019 at 2:14 AM Miquel Raynal wrote:
>
> Hi Masahiro,
>
> Boris Brezillon wrote on Sat, 30 Mar
> 2019 15:23:23 +0100:
>
> > On Fri, 29 Mar 2019 16:28:13 +0900
> > Masahiro Yamada wrote:
> >
> > > With the recent refactoring, the NAND driver hooks now take a pointer
> > > to nand_chip. Add to_denali() in order to convert (struct nand_chip *)
> > > to (struct denali_nand_info *) directly. It is more useful than the
> > > current mtd_to_denali().
> > >
> > > I changed some helper functions to take (struct nand_chip *). This will
> > > avoid pointer conversion back and forth, and ease further development.
> > >
> > > Signed-off-by: Masahiro Yamada
> > > ---
> > >
> > > Changes in v4: None
> > > Changes in v3: None
> > > Changes in v2: None
> > >
> > > drivers/mtd/nand/raw/denali.c | 57
> > > ---
> > > 1 file changed, 32 insertions(+), 25 deletions(-)
> > >
> > > diff --git a/drivers/mtd/nand/raw/denali.c b/drivers/mtd/nand/raw/denali.c
> > > index 24aeafc..4ac1314 100644
> > > --- a/drivers/mtd/nand/raw/denali.c
> > > +++ b/drivers/mtd/nand/raw/denali.c
> > > @@ -47,6 +47,11 @@ static inline struct denali_nand_info
> > > *mtd_to_denali(struct mtd_info *mtd)
> > > return container_of(mtd_to_nand(mtd), struct denali_nand_info, nand);
> > > }
> > >
> > > +static struct denali_nand_info *to_denali(struct nand_chip *chip)
> > > +{
> > > + return container_of(chip, struct denali_nand_info, nand);
> > > +}
> > > +
> > > /*
> > > * Direct Addressing - the slave address forms the control information
> > > (command
> > > * type, bank, block, and page address). The slave data is the actual
> > > data to
> > > @@ -282,12 +287,12 @@ static void denali_cmd_ctrl(struct nand_chip *chip,
> > > int dat, unsigned int ctrl)
> > > denali->host_write(denali, DENALI_BANK(denali) | type, dat);
> > > }
> > >
> > > -static int denali_check_erased_page(struct mtd_info *mtd,
> > > - struct nand_chip *chip, uint8_t *buf,
> > > +static int denali_check_erased_page(struct nand_chip *chip,
> > > + struct denali_nand_info *denali, u8 *buf,
> >
> > You don't need to pass both chip and denali, as one can be extracted
> > from the other.
> >
> > > unsigned long uncor_ecc_flags,
> > > unsigned int max_bitflips)
> > > {
> > > - struct denali_nand_info *denali = mtd_to_denali(mtd);
> > > + struct mtd_ecc_stats *ecc_stats = _to_mtd(chip)->ecc_stats;
> > > uint8_t *ecc_code = chip->oob_poi + denali->oob_skip_bytes;
> > > int ecc_steps = chip->ecc.steps;
> > > int ecc_size = chip->ecc.size;
> > > @@ -303,9 +308,9 @@ static int denali_check_erased_page(struct mtd_info
> > > *mtd,
> > > NULL, 0,
> > > chip->ecc.strength);
> > > if (stat < 0) {
> > > - mtd->ecc_stats.failed++;
> > > + ecc_stats->failed++;
> > > } else {
> > > - mtd->ecc_stats.corrected += stat;
> > > + ecc_stats->corrected += stat;
> > > max_bitflips = max_t(unsigned int, max_bitflips,
> > > stat);
> > > }
> > >
> > > @@ -316,11 +321,11 @@ static int denali_check_erased_page(struct mtd_info
> > > *mtd,
> > > return max_bitflips;
> > > }
> > >
> > > -static int denali_hw_ecc_fixup(struct mtd_info *mtd,
> > > +static int denali_hw_ecc_fixup(struct nand_chip *chip,
> > >struct denali_nand_info *denali,
> >
> > Ditto.
> >
>
> I am fine with the series in its current state, please submit a v5
> with Boris comment's addressed and I'll queue it right away to next.
>
OK, I will submit v5 shortly.
--
Best Regards
Masahiro Yamada
Re: [PATCH] regulator: wm8400: Get rid of wm8400_block_read/wm8400_set_bits functions
On Wed, 27 Feb 2019, Axel Lin wrote: > The only user of wm8400_block_read/wm8400_set_bits functions is the > wm8400 regulator driver. At the context of all the callers, we can > use regmap_bulk_read/regmap_update_bits directly. > Thus remove wm8400_block_read/wm8400_set_bits functions. > > Signed-off-by: Axel Lin > --- > drivers/mfd/wm8400-core.c| 6 -- Acked-by: Lee Jones Mark, can you take this? -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH] io_uring: introduce inline reqs for IORING_SETUP_IOPOLL & direct_io
On 4/1/19 9:10 PM, Jianchao Wang wrote:
> For the IORING_SETUP_IOPOLL & direct_io case, all of the submission
> and completion are handled under ctx->uring_lock or in SQ poll thread
> context, so io_get_req and io_put_req has been serialized well.
>
> Based on this, we introduce the preallocated reqs ring per ctx and
> needn't to provide any lock to serialize the updating of the head
> and tail. The performacne benefits from this. The test result of
> following fio command
>
> fio --name=io_uring_test --ioengine=io_uring --hipri --fixedbufs
> --iodepth=16 --direct=1 --numjobs=1 --filename=/dev/nvme0n1 --bs=4k
> --group_reporting --runtime=10
>
> shows IOPS upgrade from 197K to 206K.
I like this idea, but not a fan of the execution of it. See below.
> diff --git a/fs/io_uring.c b/fs/io_uring.c
> index 6aaa3058..40837e4 100644
> --- a/fs/io_uring.c
> +++ b/fs/io_uring.c
> @@ -104,11 +104,17 @@ struct async_list {
> size_t io_pages;
> };
>
> +#define INLINE_REQS_TOTAL 128
> +
> struct io_ring_ctx {
> struct {
> struct percpu_ref refs;
> } cacheline_aligned_in_smp;
>
> + struct io_kiocb *inline_reqs[INLINE_REQS_TOTAL];
> + struct io_kiocb *inline_req_array;
> + unsigned long inline_reqs_h, inline_reqs_t;
Why not just use a list? The req has a list member anyway. Then you don't
need a huge array, just a count.
> +
> struct {
> unsigned intflags;
> boolcompat;
> @@ -183,7 +189,9 @@ struct io_ring_ctx {
>
> struct sqe_submit {
> const struct io_uring_sqe *sqe;
> + struct file *file;
> unsigned short index;
> + boolis_fixed;
> boolhas_user;
> boolneeds_lock;
> boolneeds_fixed_file;
Not sure why you're moving these to the sqe_submit?
> @@ -228,7 +236,7 @@ struct io_kiocb {
> #define REQ_F_PREPPED16 /* prep already done */
> u64 user_data;
> u64 error;
> -
> + boolctx_inline;
> struct work_struct work;
> };
ctx_inline should just be a req flag.
>
> @@ -397,7 +405,8 @@ static void io_ring_drop_ctx_refs(struct io_ring_ctx
> *ctx, unsigned refs)
> }
>
> static struct io_kiocb *io_get_req(struct io_ring_ctx *ctx,
> -struct io_submit_state *state)
> +struct io_submit_state *state,
> +bool direct_io)
> {
> gfp_t gfp = GFP_KERNEL | __GFP_NOWARN;
> struct io_kiocb *req;
> @@ -405,10 +414,19 @@ static struct io_kiocb *io_get_req(struct io_ring_ctx
> *ctx,
> if (!percpu_ref_tryget(>refs))
> return NULL;
>
> - if (!state) {
> + /*
> + * Avoid race with workqueue context that handle buffered IO.
> + */
> + if (direct_io &&
> + ctx->inline_reqs_h - ctx->inline_reqs_t < INLINE_REQS_TOTAL) {
> + req = ctx->inline_reqs[ctx->inline_reqs_h % INLINE_REQS_TOTAL];
> + ctx->inline_reqs_h++;
> + req->ctx_inline = true;
> + } else if (!state) {
What happens for O_DIRECT that ends up being punted to async context?
We need a clearer indication of whether or not we're under the lock or
not, and then get rid of the direct_io "limitation" for this. Arguably,
cached buffered IO needs this even more than O_DIRECT does, since that
is much faster.
--
Jens Axboe
Re: [PATCH v5] mfd: cros_ec_dev: Register cros_ec_accel_legacy driver as a subdevice
On Wed, 27 Feb 2019, Gwendal Grignou wrote:
> From: Enric Balletbo i Serra
>
> With this patch, the cros_ec_ctl driver will register the legacy
> accelerometer driver (named cros_ec_accel_legacy) if it fails to
> register sensors through the usual path cros_ec_sensors_register().
> This legacy device is present on Chromebook devices with older EC
> firmware only supporting deprecated EC commands (Glimmer based devices).
>
> Tested-by: Gwendal Grignou
> Signed-off-by: Enric Balletbo i Serra
> Reviewed-by: Gwendal Grignou
> Reviewed-by: Andy Shevchenko
> ---
> Changes in v5:
> - Remove unnecessary white lines.
>
> Changes in v4:
> - [5/8] Nit: EC -> ECs (Lee Jones)
> - [5/8] Statically define cros_ec_accel_legacy_cells (Lee Jones)
>
> Changes in v3:
> - [5/8] Add the Reviewed-by Andy Shevchenko.
>
> Changes in v2:
> - [5/8] Add the Reviewed-by Gwendal.
>
> drivers/mfd/cros_ec_dev.c | 66 +++
> 1 file changed, 66 insertions(+)
>
> diff --git a/drivers/mfd/cros_ec_dev.c b/drivers/mfd/cros_ec_dev.c
> index d275deaecb12..64567bd0a081 100644
> --- a/drivers/mfd/cros_ec_dev.c
> +++ b/drivers/mfd/cros_ec_dev.c
> @@ -376,6 +376,69 @@ static void cros_ec_sensors_register(struct cros_ec_dev
> *ec)
> kfree(msg);
> }
>
> +static struct cros_ec_sensor_platform sensor_platforms[] = {
> + { .sensor_num = 0 },
> + { .sensor_num = 1 }
> +};
I'm still very uncomfortable with this struct.
Other than these indices, the sensors have no other distinguishing
features, thus there should be no need to identify or distinguish
between them in this way.
> +static const struct mfd_cell cros_ec_accel_legacy_cells[] = {
> + {
> + .name = "cros-ec-accel-legacy",
> + .id = 0,
> + .platform_data = _platforms[0],
> + .pdata_size = sizeof(struct cros_ec_sensor_platform),
> + },
> + {
> + .name = "cros-ec-accel-legacy",
> + .id = 1,
> + .platform_data = _platforms[1],
> + .pdata_size = sizeof(struct cros_ec_sensor_platform),
> + }
> +};
> +
> +static void cros_ec_accel_legacy_register(struct cros_ec_dev *ec)
> +{
> + struct cros_ec_device *ec_dev = ec->ec_dev;
> + u8 status;
> + int ret;
> +
> + /*
> + * ECs that need legacy support are the main EC, directly connected to
> + * the AP.
> + */
> + if (ec->cmd_offset != 0)
> + return;
> +
> + /*
> + * Check if EC supports direct memory reads and if EC has
> + * accelerometers.
> + */
> + if (!ec_dev->cmd_readmem)
> + return;
> +
> + ret = ec_dev->cmd_readmem(ec_dev, EC_MEMMAP_ACC_STATUS, 1, );
> + if (ret < 0) {
> + dev_warn(ec->dev, "EC does not support direct reads.\n");
> + return;
> + }
> +
> + /* Check if EC has accelerometers. */
> + if (!(status & EC_MEMMAP_ACC_STATUS_PRESENCE_BIT)) {
> + dev_info(ec->dev, "EC does not have accelerometers.\n");
> + return;
> + }
> +
> + /*
> + * Register 2 accelerometers
> + */
> + ret = mfd_add_devices(ec->dev, PLATFORM_DEVID_AUTO,
Using PLATFORM_DEVID_AUTO whilst providing the MFD cells with IDs
doesn't make any sense. Please remove the IDs from the cells.
> + cros_ec_accel_legacy_cells,
> + ARRAY_SIZE(cros_ec_accel_legacy_cells),
> + NULL, 0, NULL);
> + if (ret)
> + dev_err(ec_dev->dev, "failed to add EC sensors\n");
> +}
> +
> static const struct mfd_cell cros_ec_cec_cells[] = {
> { .name = "cros-ec-cec" }
> };
> @@ -437,6 +500,9 @@ static int ec_device_probe(struct platform_device *pdev)
> /* check whether this EC is a sensor hub. */
> if (cros_ec_check_features(ec, EC_FEATURE_MOTION_SENSE))
> cros_ec_sensors_register(ec);
> + else
> + /* Workaroud for older EC firmware */
> + cros_ec_accel_legacy_register(ec);
>
> /* Check whether this EC instance has CEC host command support */
> if (cros_ec_check_features(ec, EC_FEATURE_CEC)) {
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH v8 1/2] dt-bindings: misc: aspeed-p2a-ctrl: add support
Hi Patrick,
I held off on reviewing this until we'd hashed out what we needed in the driver.
I have some comments below.
On Sat, 30 Mar 2019, at 01:40, Patrick Venture wrote:
> Document the ast2400, ast2500 PCI-to-AHB bridge control driver bindings.
>
> Signed-off-by: Patrick Venture
> Reviewed-by: Rob Herring
> ---
> Changes for v8:
> - None
> Changes for v7:
> - Moved node under the syscon node it requires
> Changes for v6:
> - None
> Changes for v5:
> - None
> Changes for v4:
> - None
> Changes for v3:
> - None
> Changes for v2:
> - Added comment about syscon required parameter.
> ---
> .../bindings/misc/aspeed-p2a-ctrl.txt | 48 +++
> 1 file changed, 48 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/misc/aspeed-p2a-ctrl.txt
>
> diff --git a/Documentation/devicetree/bindings/misc/aspeed-p2a-ctrl.txt
> b/Documentation/devicetree/bindings/misc/aspeed-p2a-ctrl.txt
> new file mode 100644
> index 0..088cc4e3dc54b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/misc/aspeed-p2a-ctrl.txt
> @@ -0,0 +1,48 @@
> +==
> +Device tree bindings for Aspeed AST2400/AST2500 PCI-to-AHB Bridge
> Control Driver
> +==
> +
> +The bridge is available on platforms with the VGA enabled on the
> Aspeed device.
> +In this case, the host has access to a 64KiB window into all of the
> BMC's
> +memory. The BMC can disable this bridge. If the bridge is enabled,
> the host
> +has read access to all the regions of memory, however the host only
> has read
> +and write access depending on a register controlled by the BMC.
> +
> +Required properties:
> +===
> +
> + - compatible: must be one of:
> + - "aspeed,ast2400-p2a-ctrl"
> + - "aspeed,ast2500-p2a-ctrl"
> +
> + - syscon: handle to syscon device node controlling PCI.
The p2a-ctrl node is meant to be a child of the syscon. I noted this in my
review
of the associated driver - you need to remove the description of the syscon
property.
> +
> +Optional properties:
> +===
> +
> +- memory-region: A phandle to a reserved_memory region to be used for
> the PCI
> + to AHB mapping
> +
> +The p2a-control node should be the child of a syscon node with the
> required
> +property:
> +
> +- compatible : Should be one of the following:
> + "aspeed,ast2400-scu", "syscon", "simple-mfd"
> + "aspeed,g4-scu", "syscon", "simple-mfd"
> + "aspeed,ast2500-scu", "syscon", "simple-mfd"
> + "aspeed,g5-scu", "syscon", "simple-mfd"
The note above should go where you've described the syscon property above.
Cheers,
Andrew
> +
> +Example:
> +
> +g4 Example
> +--
> +
> +syscon: scu@1e6e2000 {
> + compatible = "aspeed,ast2400-scu", "syscon", "simple-mfd";
> + reg = <0x1e6e2000 0x1a8>;
> +
> + p2a: p2a-control {
> + compatible = "aspeed,ast2400-p2a-ctrl";
> + memory-region = <_memory>;
> + };
> +};
> --
> 2.21.0.392.gf8f6787159e-goog
>
>
Re: [PATCH v8 2/2] drivers/misc: Add Aspeed P2A control driver
On Thu, 28 Mar 2019, at 07:52, Patrick Venture wrote: > The ASPEED AST2400, and AST2500 in some configurations include a > PCI-to-AHB MMIO bridge. This bridge allows a server to read and write > in the BMC's physical address space. This feature is especially useful > when using this bridge to send large files to the BMC. > > The host may use this to send down a firmware image by staging data at a > specific memory address, and in a coordinated effort with the BMC's > software stack and kernel, transmit the bytes. > > This driver enables the BMC to unlock the PCI bridge on demand, and > configure it via ioctl to allow the host to write bytes to an agreed > upon location. In the primary use-case, the region to use is known > apriori on the BMC, and the host requests this information. Once this > request is received, the BMC's software stack will enable the bridge and > the region and then using some software flow control (possibly via IPMI > packets), copy the bytes down. Once the process is complete, the BMC > will disable the bridge and unset any region involved. > > The default behavior of this bridge when present is: enabled and all > regions marked read-write. This driver will fix the regions to be > read-only and then disable the bridge entirely. > > The memory regions protected are: > * BMC flash MMIO window > * System flash MMIO windows > * SOC IO (peripheral MMIO) > * DRAM > > The DRAM region itself is all of DRAM and cannot be further specified. > Once the PCI bridge is enabled, the host can read all of DRAM, and if > the DRAM section is write-enabled, then it can write to all of it. > > Signed-off-by: Patrick Venture > --- > Changes for v8: > - Promoted u32 address values to u64 to be compatible with either. > Changes for v7: > - Moved node under the syscon node and changed therefore how it grabs > the phandle for the regmap. > Changes for v6: > - Cleaned up documentation > - Added missing machine-readable copyright lines. > - Fixed over 80 chars instances. > - Changed error from invalid memory-region node to ENODEV. > Changes for v5: > - Fixup missing exit condition and remove extra jump. > Changes for v4: > - Added ioctl for reading back the memory-region configuration. > - Cleaned up some unused variables. > Changes for v3: > - Deleted unused read and write methods. > Changes for v2: > - Dropped unused reads. > - Moved call to disable bridge to before registering device. > - Switch from using regs to using a syscon regmap. <<< IN PROGRESS > - Updated the commit message. <<< TODO > - Updated the bit flipped for SCU180_ENP2A > - Dropped boolean region_specified variable. > - Renamed p2a_ctrl in _probe to misc_ctrl per suggestion. > - Renamed aspeed_p2a_region_search to aspeed_p2a_region_acquire > - Updated commit message. > --- > drivers/misc/Kconfig | 8 + > drivers/misc/Makefile| 1 + > drivers/misc/aspeed-p2a-ctrl.c | 448 +++ > include/uapi/linux/aspeed-p2a-ctrl.h | 62 > 4 files changed, 519 insertions(+) > create mode 100644 drivers/misc/aspeed-p2a-ctrl.c > create mode 100644 include/uapi/linux/aspeed-p2a-ctrl.h > > diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig > index 42ab8ec92a046..3209ee020b153 100644 > --- a/drivers/misc/Kconfig > +++ b/drivers/misc/Kconfig > @@ -496,6 +496,14 @@ config VEXPRESS_SYSCFG > bus. System Configuration interface is one of the possible means > of generating transactions on this bus. > > +config ASPEED_P2A_CTRL > + depends on (ARCH_ASPEED || COMPILE_TEST) && REGMAP && MFD_SYSCON > + tristate "Aspeed ast2400/2500 HOST P2A VGA MMIO to BMC bridge control" > + help > + Control Aspeed ast2400/2500 HOST P2A VGA MMIO to BMC mappings > through > + ioctl()s, the driver also provides an interface for userspace > mappings to > + a pre-defined region. > + > config ASPEED_LPC_CTRL > depends on (ARCH_ASPEED || COMPILE_TEST) && REGMAP && MFD_SYSCON > tristate "Aspeed ast2400/2500 HOST LPC to BMC bridge control" > diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile > index d5b7d3404dc78..c36239573a5ca 100644 > --- a/drivers/misc/Makefile > +++ b/drivers/misc/Makefile > @@ -56,6 +56,7 @@ obj-$(CONFIG_VEXPRESS_SYSCFG) += vexpress-syscfg.o > obj-$(CONFIG_CXL_BASE) += cxl/ > obj-$(CONFIG_ASPEED_LPC_CTRL)+= aspeed-lpc-ctrl.o > obj-$(CONFIG_ASPEED_LPC_SNOOP) += aspeed-lpc-snoop.o > +obj-$(CONFIG_ASPEED_P2A_CTRL)+= aspeed-p2a-ctrl.o > obj-$(CONFIG_PCI_ENDPOINT_TEST) += pci_endpoint_test.o > obj-$(CONFIG_OCXL) += ocxl/ > obj-y+= cardreader/ > diff --git a/drivers/misc/aspeed-p2a-ctrl.c > b/drivers/misc/aspeed-p2a-ctrl.c > new file mode 100644 > index 0..06afbfe51a279 > --- /dev/null > +++ b/drivers/misc/aspeed-p2a-ctrl.c > @@ -0,0 +1,448 @@ > +// SPDX-License-Identifier: GPL-2.0+ > +/* > + * Copyright
[PATCH 0/1] slob: Fix list_head bug during allocation
Hi Andrew,
This patch is in response to an email from the 0day kernel test robot
subject:
340d3d6178 ("mm/slob.c: respect list_head abstraction layer"): kernel BUG at
lib/list_debug.c:31!
This patch applies on top of linux-next tag: next-20190401
It fixes a patch that was merged recently into mm:
The patch titled
Subject: mm/slob.c: respect list_head abstraction layer
has been added to the -mm tree. Its filename is
slob-respect-list_head-abstraction-layer.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/slob-respect-list_head-abstraction-layer.patch
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/slob-respect-list_head-abstraction-layer.patch
If reverting is easier than patching I can re-work this into another
version of the original (buggy) patch set which was the series:
[PATCH 0/4] mm: Use slab_list list_head instead of lru
Please don't be afraid to give a firm response. I'm new to mm and I'd
like to not be a nuisance if I can manage it ;) I'd also like to fix
this in a way that makes your day as easy as possible.
The 0day kernel test robot found a bug in the slob allocator caused by a
patch from me recently merged into the mm tree. This is the first time
the 0day has found a bug in already merged code of mine so I do not know
the exact protocol in regards to linking the fix with the report,
patching, reverting etc.
I was unable to reproduce the crash, I tried building with the config
attached to the email above but the kernel booted fine for me in Qemu.
So I re-worked the module originally used for testing, it can be found
here:
https://github.com/tcharding/ktest/tree/master/list_head
>From this I think the list.h code added prior to the buggy patch is
ok.
Next I tried to find the bug just using my eyes. This patch is the
result. Unfortunately I can not understand why this bug was not
triggered _before_ I originally patched it. Perhaps I'm not juggling
all the state perfectly in my head. Anyways, this patch stops and code
calling list manipulation functions if the slab_list page member has
been modified during allocation.
The code in question revolves around an optimisation aimed at preventing
fragmentation at the start of a slab due to the first fit nature of the
allocation algorithm.
Full explanation is in the commit log for the patch, the short version
is; skip optimisation if page list is modified, this only occurs when an
allocation completely fills the slab and in this case the optimisation
is unnecessary since we have not fragmented the slab by this allocation.
This is more than just a bug fix, it significantly reduces the
complexity of the function while still fixing the reason for originally
touching this code (violation of list_head abstraction).
The only testing I've done is to build and boot a kernel in Qemu (with
CONFIG_LIST_DEBUG and CONFIG_SLOB) enabled). However, as mentioned,
this method of testing did _not_ reproduce the 0day crash so if there
are better suggestions on how I should test these I'm happy to do so.
thanks,
Tobin.
Tobin C. Harding (1):
slob: Only use list functions when safe to do so
mm/slob.c | 50 ++
1 file changed, 30 insertions(+), 20 deletions(-)
--
2.21.0
Re: [LKP] [btrfs] 70d28b0e4f: BUG:kernel_reboot-without-warning_in_early-boot_stage, last_printk:Probing_EDD(edd=off_to_disable)...ok
On 2019/4/2 上午11:14, Rong Chen wrote:
>
> On 4/1/19 11:40 PM, David Sterba wrote:
>> On Mon, Apr 01, 2019 at 11:02:37PM +0800, Chen, Rong A wrote:
>>> On 4/1/2019 10:29 PM, Qu Wenruo wrote:
On 2019/4/1 下午10:02, Chen, Rong A wrote:
> On 4/1/2019 9:28 PM, Nikolay Borisov wrote:
>> On 1.04.19 г. 16:24 ч., kernel test robot wrote:
>>> FYI, we noticed the following commit (built with gcc-7):
>>>
>>> commit: 70d28b0e4f8ed2d38571e7b1f9bec7f321a53102 ("btrfs:
>>> tree-checker: Verify dev item")
>>> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git
>>> master
>>>
>>> in testcase: trinity
>>> with following parameters:
>>>
>>> runtime: 300s
>>>
>>> test-description: Trinity is a linux system call fuzz tester.
>>> test-url: http://codemonkey.org.uk/projects/trinity/
>>>
>>>
>>> on test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge
>>> -smp
>>> 2 -m 2G
>>>
>>> caused below changes (please refer to attached dmesg/kmsg for entire
>>> log/backtrace):
>>>
>>>
>>> ++++
>>>
>>>
>>> |
>>> | 36b9d2bc69 | 70d28b0e4f |
>>> ++++
>>>
>>>
>>> |
>>> boot_successes
>>> | 14 | 0 |
>>> |
>>> boot_failures
>>> | 2 | 14 |
>>> |
>>> IP-Config:Auto-configuration_of_network_failed
>>> | 2 | |
>>> |
>>> BUG:kernel_reboot-without-warning_in_early-boot_stage,last_printk:Probing_EDD(edd=off_to_disable)...ok
>>>
>>> | 0 | 14 |
>>> ++++
>>>
>>>
>>>
>>>
>>>
>>> early console in setup code
>>> Probing EDD (edd=off to disable)... ok
>>> BUG: kernel reboot-without-warning in early-boot stage, last printk:
>>> Probing EDD (edd=off to disable)... ok
>>> Linux version 5.0.0-rc8-00196-g70d28b0 #1
>>> Command line: ip=vm-snb-quantal-x86_64-1415::dhcp root=/dev/ram0
>>> user=lkp
>>> job=/lkp/jobs/scheduled/vm-snb-quantal-x86_64-1415/trinity-300s-quantal-core-x86_64-2018-11-09.cgz-70d28b0-20190330-29362-1y6g0qb-2.yaml
>>>
>>> ARCH=x86_64 kconfig=x86_64-randconfig-s5-03231928
>>> branch=linux-devel/devel-hourly-2019032317
>>> commit=70d28b0e4f8ed2d38571e7b1f9bec7f321a53102
>>> BOOT_IMAGE=/pkg/linux/x86_64-randconfig-s5-03231928/gcc-7/70d28b0e4f8ed2d38571e7b1f9bec7f321a53102/vmlinuz-5.0.0-rc8-00196-g70d28b0
>>>
>>> max_uptime=1500
>>> RESULT_ROOT=/result/trinity/300s/vm-snb-quantal-x86_64/quantal-core-x86_64-2018-11-09.cgz/x86_64-randconfig-s5-03231928/gcc-7/70d28b0e4f8ed2d38571e7b1f9bec7f321a53102/8
>>>
>>> LKP_SERVER=inn debug apic=debug sysrq_always_enabled
>>> rcupdate.rcu_cpu_stall_timeout=100 net.ifnames=0 printk.devkmsg=on
>>> panic=-1 softlockup_panic=1 nmi_watchdog=panic oops=panic
>>> load_ramdisk=2 prompt_ramdisk=0 drbd.minor_count=8
>>> systemd.log_level=err ignore_loglevel console=tty0
>>> earlyprintk=ttyS0,115200 console=ttyS0,115200 vga=normal rw
>>> rcuperf.shutdown=0
>>>
>> Can this report be made useful by actually including output from
>> serial
>> console? For example possible bug-ons or whatnot? dmesg.xz just
>> contains
>> qemu's command line + some metadata about the test and :
>>
>> "BUG: kernel reboot-without-warning in early-boot stage, last printk:
>> Probing EDD (edd=off to disable)... ok"
>>
>> At least a stack trace would have been useful.
>>
>>
> Hi,
>
> We usually use the tool ("bin/lkp qemu -k job-script") to
> reproduce it. It seems no stack trace in the result:
So there is no regression at that commit right?
Just some false alert?
>>>
>>> Hi,
>>>
>>> I think there's a regression, it stopped in the early-boot stage .
>> Can you please provide any logs that would point at btrfs? If the module
>> is loaded or built-in started, there's a line about that. Besides that
>> it's preceded by messages from other subsystems' initialization.
>
>
> Hi,
>
> CONFIG_BTRFS_FS and CONFIG_BTRFS_FS_REF_VERIFY is enabled in the kconfig.
> I disabled them for the experiment, and the new kernel is bootable. I
> don't have more logs to prove it.
>
> $ grep BTRFS config-5.0.0-rc8-00196-g70d28b0
> CONFIG_BTRFS_FS=y
> # CONFIG_BTRFS_FS_POSIX_ACL is not set
> # CONFIG_BTRFS_FS_CHECK_INTEGRITY is not set
> # CONFIG_BTRFS_FS_RUN_SANITY_TESTS is not set
> # CONFIG_BTRFS_DEBUG is not set
> # CONFIG_BTRFS_ASSERT is not set
> CONFIG_BTRFS_FS_REF_VERIFY=y
That's strange,
[PATCH 1/1] slob: Only use list functions when safe to do so
Currently we call (indirectly) list_del() then we manually try to combat
the fact that the list may be in an undefined state by getting 'prev'
and 'next' pointers in a somewhat contrived manner. It is hard to
verify that this works for all initial states of the list. Clearly the
author (me) got it wrong the first time because the 0day kernel testing
robot managed to crash the kernel thanks to this code.
All this is done in order to do an optimisation aimed at preventing
fragmentation at the start of a slab. We can just skip this
optimisation any time the list is put into an undefined state since this
only occurs when an allocation completely fills the slab and in this
case the optimisation is unnecessary since we have not fragmented the slab
by this allocation.
Change the page pointer passed to slob_alloc_page() to be a double
pointer so that we can set it to NULL to indicate that the page was
removed from the list. Skip the optimisation if the page was removed.
Found thanks to the kernel test robot, email subject:
340d3d6178 ("mm/slob.c: respect list_head abstraction layer"): kernel
BUG at lib/list_debug.c:31!
Reported-by: kernel test robot
Signed-off-by: Tobin C. Harding
---
mm/slob.c | 50 ++
1 file changed, 30 insertions(+), 20 deletions(-)
diff --git a/mm/slob.c b/mm/slob.c
index 21af3fdb457a..c543da10df45 100644
--- a/mm/slob.c
+++ b/mm/slob.c
@@ -213,10 +213,18 @@ static void slob_free_pages(void *b, int order)
}
/*
- * Allocate a slob block within a given slob_page sp.
+ * slob_page_alloc() - Allocate a slob block within a given slob_page sp.
+ * @spp: Page to look in, return parameter.
+ * @size: Size of the allocation.
+ * @align: Allocation alignment.
+ *
+ * Tries to find a chunk of memory at least @size within page. If the
+ * allocation fills up page then page is removed from list, in this case
+ * *spp will be set to %NULL to signal that list removal occurred.
*/
-static void *slob_page_alloc(struct page *sp, size_t size, int align)
+static void *slob_page_alloc(struct page **spp, size_t size, int align)
{
+ struct page *sp = *spp;
slob_t *prev, *cur, *aligned = NULL;
int delta = 0, units = SLOB_UNITS(size);
@@ -254,8 +262,11 @@ static void *slob_page_alloc(struct page *sp, size_t size,
int align)
}
sp->units -= units;
- if (!sp->units)
+ if (!sp->units) {
clear_slob_page_free(sp);
+ /* Signal that page was removed from list. */
+ *spp = NULL;
+ }
return cur;
}
if (slob_last(cur))
@@ -268,7 +279,7 @@ static void *slob_page_alloc(struct page *sp, size_t size,
int align)
*/
static void *slob_alloc(size_t size, gfp_t gfp, int align, int node)
{
- struct page *sp, *prev, *next;
+ struct page *sp;
struct list_head *slob_list;
slob_t *b = NULL;
unsigned long flags;
@@ -283,6 +294,7 @@ static void *slob_alloc(size_t size, gfp_t gfp, int align,
int node)
spin_lock_irqsave(_lock, flags);
/* Iterate through each partially free page, try to find room */
list_for_each_entry(sp, slob_list, slab_list) {
+ struct page **spp =
#ifdef CONFIG_NUMA
/*
* If there's a node specification, search for a partial
@@ -295,27 +307,25 @@ static void *slob_alloc(size_t size, gfp_t gfp, int
align, int node)
if (sp->units < SLOB_UNITS(size))
continue;
- /*
-* Cache previous entry because slob_page_alloc() may
-* remove sp from slob_list.
-*/
- prev = list_prev_entry(sp, slab_list);
-
/* Attempt to alloc */
- b = slob_page_alloc(sp, size, align);
+ b = slob_page_alloc(spp, size, align);
if (!b)
continue;
- next = list_next_entry(prev, slab_list); /* This may or may not
be sp */
-
/*
-* Improve fragment distribution and reduce our average
-* search time by starting our next search here. (see
-* Knuth vol 1, sec 2.5, pg 449)
+* If slob_page_alloc() removed sp from the list then we
+* cannot call list functions on sp. Just bail, don't
+* worry about the optimisation below.
*/
- if (!list_is_first(>slab_list, slob_list))
- list_rotate_to_front(>slab_list, slob_list);
-
+ if (*spp) {
+ /*
+* Improve fragment distribution and reduce our average
+* search time by starting our next search here.
Re: [mt76] c1e0d2be0a: BUG:pagefault_on_kernel_address#in_non-whitelisted_uaccess
On Tue, Apr 2, 2019 at 5:10 AM kernel test robot wrote:
> FYI, we noticed the following commit (built with gcc-7):
>
> commit: c1e0d2be0acff5e99a59ddcc5af415e48abc6c5e ("mt76: mmio: introduce
> mt76x02_check_tx_hang watchdog")
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
[...]
> [ 10.383586] BUG: pagefault on kernel address 0x93d4b5cd8000 in
> non-whitelisted uaccess
> [ 10.390934] BUG: unable to handle kernel paging request at 93d4b5cd8000
> [ 10.390934] #PF error: [normal kernel read fault]
> [ 10.390934] PGD 21e00067 P4D 21e00067 PUD 21e04067 PMD 78b57067 PTE
> 800f8a327060
> [ 10.390934] Oops: [#1] PREEMPT SMP DEBUG_PAGEALLOC
> [ 10.390934] CPU: 1 PID: 1 Comm: swapper/0 Tainted: GT
> 5.0.0-rc1-00033-gc1e0d2b #1
> [ 10.390934] RIP: 0010:strncpy_from_user+0x87/0x10c
> [ 10.390934] Code: 00 00 66 66 90 4c 39 c2 48 bb ff fe fe fe fe fe fe fe 49
> ba 80 80 80 80 80 80 80 80 4c 0f 46 c2 31 c0 45 31 db eb 4c 44 89 d9 <4c> 8b
> 0c 06 85 c9 74 05 45 31 d2 eb 61 49 8d 0c 19 4c 89 0c 07 49
> [ 10.390934] RSP: :bd8c00323bc0 EFLAGS: 00010206
> [ 10.390934] RAX: 0028 RBX: fefefefefefefeff RCX:
>
> [ 10.390934] RDX: 0fe0 RSI: 93d4b5cd7fd6 RDI:
> 93d4af5e3020
> [ 10.390934] RBP: ff9c R08: 0fe0 R09:
> 8c93909d92868cd1
> [ 10.390934] R10: 8080808080808080 R11: R12:
> 93d4b5cd7fd6
> [ 10.390934] R13: 93d4b5cd7fd6 R14: R15:
>
> [ 10.390934] FS: () GS:93d4b640()
> knlGS:
> [ 10.390934] CS: 0010 DS: ES: CR0: 80050033
> [ 10.390934] CR2: 93d4b5cd8000 CR3: 20c15000 CR4:
> 06e0
> [ 10.390934] Call Trace:
> [ 10.390934] ? getname_flags+0x6f/0x199
> [ 10.390934] ? user_path_at_empty+0x18/0x2f
> [ 10.390934] ? vfs_statx+0x6d/0xb3
> [ 10.390934] ? clean_path+0x5c/0x102
> [ 10.390934] ? do_name+0xf4/0x40e
> [ 10.390934] ? write_buffer+0x52/0x8a
> [ 10.390934] ? flush_buffer+0xe7/0x140
> [ 10.390934] ? initrd_load+0xa8/0xa8
> [ 10.390934] ? __gunzip+0x53a/0x6b7
> [ 10.390934] ? bunzip2+0x76a/0x76a
> [ 10.390934] ? write_buffer+0x8a/0x8a
> [ 10.390934] ? gunzip+0x39/0x3d
> [ 10.390934] ? initrd_load+0xa8/0xa8
> [ 10.390934] ? unpack_to_rootfs+0x1c6/0x3c6
> [ 10.390934] ? initrd_load+0xa8/0xa8
> [ 10.390934] ? populate_rootfs+0x94/0x213
> [ 10.390934] ? clean_rootfs+0x23b/0x23b
> [ 10.390934] ? do_one_initcall+0x61/0x12a
> [ 10.390934] ? kernel_init_freeable+0x1a8/0x305
> [ 10.390934] ? rest_init+0x13a/0x13a
> [ 10.390934] ? kernel_init+0x5/0xeb
> [ 10.390934] ? ret_from_fork+0x35/0x40
> [ 10.390934] Modules linked in:
> [ 10.390934] CR2: 93d4b5cd8000
> [ 10.390934] ---[ end trace 81b307b1a0dd06e6 ]---
This was dealt with in commit 53a41cb7ed381edee91029cdcabe9b3250f43f4d
('Revert "x86/fault: BUG() when uaccess helpers fault on kernel
addresses"').
Re: [BUG/PATCH 0/4] gpiolib: fix issues with legacy spi-cs-high handling
On Mon, Apr 1, 2019 at 11:59 PM H. Nikolaus Schaller wrote: > I learned just some minutes ago that a new patch for gpiolib > came through 5.1-rc3 which does fix this in almost the same way > as I proposed. I am sorry for not being very attentive, I have been travelling. I collected the most urgent fixes and this was fixed as part of that quick patchup. > Except that it seems to check for "cs-gpios" and then disable the > legacy handling. Yups. > So we do not need to add a config option for this legacy > handling (although I'd prefer to have it anyways to remove > some dead code). > > Summary: this series can now be ignored. OK please verify that we are doing things right now, the big worry I have is some interrim DTBs that use the GPIO flag GPIO_ACTIVE_HIGH, which is zero and therefore often the default, and expect it to actually work, while the SPI bindings by definition will ignore that and make the line active low. I'm not very happy about this but it is a result of how we quickly implemented some bindings in the past while the GPIO flags were not yet standardized. Yours, Linus Walleij
Re: [LKP] [btrfs] 70d28b0e4f: BUG:kernel_reboot-without-warning_in_early-boot_stage, last_printk:Probing_EDD(edd=off_to_disable)...ok
On 4/1/19 11:40 PM, David Sterba wrote:
On Mon, Apr 01, 2019 at 11:02:37PM +0800, Chen, Rong A wrote:
On 4/1/2019 10:29 PM, Qu Wenruo wrote:
On 2019/4/1 下午10:02, Chen, Rong A wrote:
On 4/1/2019 9:28 PM, Nikolay Borisov wrote:
On 1.04.19 г. 16:24 ч., kernel test robot wrote:
FYI, we noticed the following commit (built with gcc-7):
commit: 70d28b0e4f8ed2d38571e7b1f9bec7f321a53102 ("btrfs:
tree-checker: Verify dev item")
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master
in testcase: trinity
with following parameters:
runtime: 300s
test-description: Trinity is a linux system call fuzz tester.
test-url: http://codemonkey.org.uk/projects/trinity/
on test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp
2 -m 2G
caused below changes (please refer to attached dmesg/kmsg for entire
log/backtrace):
++++
|
| 36b9d2bc69 | 70d28b0e4f |
++++
|
boot_successes
| 14 | 0 |
|
boot_failures
| 2 | 14 |
|
IP-Config:Auto-configuration_of_network_failed
| 2 | |
|
BUG:kernel_reboot-without-warning_in_early-boot_stage,last_printk:Probing_EDD(edd=off_to_disable)...ok
| 0 | 14 |
++++
early console in setup code
Probing EDD (edd=off to disable)... ok
BUG: kernel reboot-without-warning in early-boot stage, last printk:
Probing EDD (edd=off to disable)... ok
Linux version 5.0.0-rc8-00196-g70d28b0 #1
Command line: ip=vm-snb-quantal-x86_64-1415::dhcp root=/dev/ram0
user=lkp
job=/lkp/jobs/scheduled/vm-snb-quantal-x86_64-1415/trinity-300s-quantal-core-x86_64-2018-11-09.cgz-70d28b0-20190330-29362-1y6g0qb-2.yaml
ARCH=x86_64 kconfig=x86_64-randconfig-s5-03231928
branch=linux-devel/devel-hourly-2019032317
commit=70d28b0e4f8ed2d38571e7b1f9bec7f321a53102
BOOT_IMAGE=/pkg/linux/x86_64-randconfig-s5-03231928/gcc-7/70d28b0e4f8ed2d38571e7b1f9bec7f321a53102/vmlinuz-5.0.0-rc8-00196-g70d28b0
max_uptime=1500
RESULT_ROOT=/result/trinity/300s/vm-snb-quantal-x86_64/quantal-core-x86_64-2018-11-09.cgz/x86_64-randconfig-s5-03231928/gcc-7/70d28b0e4f8ed2d38571e7b1f9bec7f321a53102/8
LKP_SERVER=inn debug apic=debug sysrq_always_enabled
rcupdate.rcu_cpu_stall_timeout=100 net.ifnames=0 printk.devkmsg=on
panic=-1 softlockup_panic=1 nmi_watchdog=panic oops=panic
load_ramdisk=2 prompt_ramdisk=0 drbd.minor_count=8
systemd.log_level=err ignore_loglevel console=tty0
earlyprintk=ttyS0,115200 console=ttyS0,115200 vga=normal rw
rcuperf.shutdown=0
Can this report be made useful by actually including output from serial
console? For example possible bug-ons or whatnot? dmesg.xz just contains
qemu's command line + some metadata about the test and :
"BUG: kernel reboot-without-warning in early-boot stage, last printk:
Probing EDD (edd=off to disable)... ok"
At least a stack trace would have been useful.
Hi,
We usually use the tool ("bin/lkp qemu -k job-script") to
reproduce it. It seems no stack trace in the result:
So there is no regression at that commit right?
Just some false alert?
Hi,
I think there's a regression, it stopped in the early-boot stage .
Can you please provide any logs that would point at btrfs? If the module
is loaded or built-in started, there's a line about that. Besides that
it's preceded by messages from other subsystems' initialization.
Hi,
CONFIG_BTRFS_FS and CONFIG_BTRFS_FS_REF_VERIFY is enabled in the kconfig.
I disabled them for the experiment, and the new kernel is bootable. I
don't have more logs to prove it.
$ grep BTRFS config-5.0.0-rc8-00196-g70d28b0
CONFIG_BTRFS_FS=y
# CONFIG_BTRFS_FS_POSIX_ACL is not set
# CONFIG_BTRFS_FS_CHECK_INTEGRITY is not set
# CONFIG_BTRFS_FS_RUN_SANITY_TESTS is not set
# CONFIG_BTRFS_DEBUG is not set
# CONFIG_BTRFS_ASSERT is not set
CONFIG_BTRFS_FS_REF_VERIFY=y
Best Regards,
Rong Chen
___
LKP mailing list
l...@lists.01.org
https://lists.01.org/mailman/listinfo/lkp
[PATCH v3] gcov: fix when CONFIG_MODULES is not set
From: Tri Vo
Fixes: 8c3d220cb6b5 ("gcov: clang support")
Cc: Greg Hackmann
Cc: Peter Oberparleiter
Cc: linux...@kvack.org
Cc: kbuild-...@01.org
Reported-by: Randy Dunlap
Reported-by: kbuild test robot
Link: https://marc.info/?l=linux-mm=155384681109231=2
Signed-off-by: Nick Desaulniers
Signed-off-by: Tri Vo
---
kernel/gcov/clang.c | 4
kernel/gcov/gcc_3_4.c | 4
kernel/gcov/gcc_4_7.c | 4
3 files changed, 12 insertions(+)
diff --git a/kernel/gcov/clang.c b/kernel/gcov/clang.c
index 125c50397ba2..cfb9ce5e0fed 100644
--- a/kernel/gcov/clang.c
+++ b/kernel/gcov/clang.c
@@ -223,7 +223,11 @@ void gcov_info_unlink(struct gcov_info *prev, struct
gcov_info *info)
*/
bool gcov_info_within_module(struct gcov_info *info, struct module *mod)
{
+#ifdef CONFIG_MODULES
return within_module((unsigned long)info->filename, mod);
+#else
+ return false;
+#endif
}
/* Symbolic links to be created for each profiling data file. */
diff --git a/kernel/gcov/gcc_3_4.c b/kernel/gcov/gcc_3_4.c
index 801ee4b0b969..8fc30f178351 100644
--- a/kernel/gcov/gcc_3_4.c
+++ b/kernel/gcov/gcc_3_4.c
@@ -146,7 +146,11 @@ void gcov_info_unlink(struct gcov_info *prev, struct
gcov_info *info)
*/
bool gcov_info_within_module(struct gcov_info *info, struct module *mod)
{
+#ifdef CONFIG_MODULES
return within_module((unsigned long)info, mod);
+#else
+ return false;
+#endif
}
/* Symbolic links to be created for each profiling data file. */
diff --git a/kernel/gcov/gcc_4_7.c b/kernel/gcov/gcc_4_7.c
index ec37563674d6..0b6886d4a4dd 100644
--- a/kernel/gcov/gcc_4_7.c
+++ b/kernel/gcov/gcc_4_7.c
@@ -159,7 +159,11 @@ void gcov_info_unlink(struct gcov_info *prev, struct
gcov_info *info)
*/
bool gcov_info_within_module(struct gcov_info *info, struct module *mod)
{
+#ifdef CONFIG_MODULES
return within_module((unsigned long)info, mod);
+#else
+ return false;
+#endif
}
/* Symbolic links to be created for each profiling data file. */
--
2.21.0.392.gf8f6787159e-goog
[PATCH] clocksource/drivers/tegra: rework for compensation of suspend time
Since the clocksource framework has the support for suspend time
compensation. Re-work the driver to use that, so we can reduce the
duplicate code.
Suggested-by: Daniel Lezcano
Signed-off-by: Joseph Lo
---
drivers/clocksource/timer-tegra20.c | 63 +
1 file changed, 20 insertions(+), 43 deletions(-)
diff --git a/drivers/clocksource/timer-tegra20.c
b/drivers/clocksource/timer-tegra20.c
index fdb3d795a409..919b3568c495 100644
--- a/drivers/clocksource/timer-tegra20.c
+++ b/drivers/clocksource/timer-tegra20.c
@@ -60,9 +60,6 @@
static u32 usec_config;
static void __iomem *timer_reg_base;
#ifdef CONFIG_ARM
-static void __iomem *rtc_base;
-static struct timespec64 persistent_ts;
-static u64 persistent_ms, last_persistent_ms;
static struct delay_timer tegra_delay_timer;
#endif
@@ -199,40 +196,30 @@ static unsigned long
tegra_delay_timer_read_counter_long(void)
return readl(timer_reg_base + TIMERUS_CNTR_1US);
}
+static struct timer_of suspend_rtc_to = {
+ .flags = TIMER_OF_BASE | TIMER_OF_CLOCK,
+};
+
/*
* tegra_rtc_read - Reads the Tegra RTC registers
* Care must be taken that this funciton is not called while the
* tegra_rtc driver could be executing to avoid race conditions
* on the RTC shadow register
*/
-static u64 tegra_rtc_read_ms(void)
+static u64 tegra_rtc_read_ms(struct clocksource *cs)
{
- u32 ms = readl(rtc_base + RTC_MILLISECONDS);
- u32 s = readl(rtc_base + RTC_SHADOW_SECONDS);
+ u32 ms = readl(timer_of_base(_rtc_to) + RTC_MILLISECONDS);
+ u32 s = readl(timer_of_base(_rtc_to) + RTC_SHADOW_SECONDS);
return (u64)s * MSEC_PER_SEC + ms;
}
-/*
- * tegra_read_persistent_clock64 - Return time from a persistent clock.
- *
- * Reads the time from a source which isn't disabled during PM, the
- * 32k sync timer. Convert the cycles elapsed since last read into
- * nsecs and adds to a monotonically increasing timespec64.
- * Care must be taken that this funciton is not called while the
- * tegra_rtc driver could be executing to avoid race conditions
- * on the RTC shadow register
- */
-static void tegra_read_persistent_clock64(struct timespec64 *ts)
-{
- u64 delta;
-
- last_persistent_ms = persistent_ms;
- persistent_ms = tegra_rtc_read_ms();
- delta = persistent_ms - last_persistent_ms;
-
- timespec64_add_ns(_ts, delta * NSEC_PER_MSEC);
- *ts = persistent_ts;
-}
+static struct clocksource suspend_rtc_clocksource = {
+ .name = "tegra_suspend_timer",
+ .rating = 200,
+ .read = tegra_rtc_read_ms,
+ .mask = CLOCKSOURCE_MASK(32),
+ .flags = CLOCK_SOURCE_IS_CONTINUOUS | CLOCK_SOURCE_SUSPEND_NONSTOP,
+};
#endif
static int tegra_timer_common_init(struct device_node *np, struct timer_of *to)
@@ -385,25 +372,15 @@ static int __init tegra_init_timer(struct device_node *np)
static int __init tegra20_init_rtc(struct device_node *np)
{
- struct clk *clk;
+ int ret;
- rtc_base = of_iomap(np, 0);
- if (!rtc_base) {
- pr_err("Can't map RTC registers\n");
- return -ENXIO;
- }
+ ret = timer_of_init(np, _rtc_to);
+ if (ret)
+ return ret;
- /*
-* rtc registers are used by read_persistent_clock, keep the rtc clock
-* enabled
-*/
- clk = of_clk_get(np, 0);
- if (IS_ERR(clk))
- pr_warn("Unable to get rtc-tegra clock\n");
- else
- clk_prepare_enable(clk);
+ clocksource_register_hz(_rtc_clocksource, 1000);
- return register_persistent_clock(tegra_read_persistent_clock64);
+ return 0;
}
TIMER_OF_DECLARE(tegra20_rtc, "nvidia,tegra20-rtc", tegra20_init_rtc);
#endif
--
2.21.0
Re: [PATCH 4.9 00/56] 4.9.167-stable review
On Mon, 1 Apr 2019 at 22:58, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.9.167 release. > There are 56 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Wed Apr 3 17:00:20 UTC 2019. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.167-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.9.y > and the diffstat can be found below. > > thanks, > > greg k-h Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386. Summary kernel: 4.9.167-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.9.y git commit: ddec8bf2f297c9844b75e4fdf2620e39c230dd93 git describe: v4.9.166-57-gddec8bf2f297 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.166-57-gddec8bf2f297 No regressions (compared to build v4.9.166) No fixes (compared to build v4.9.166) Ran 22599 total tests in the following environments and test suites. Environments -- - dragonboard-410c - arm64 - hi6220-hikey - arm64 - i386 - juno-r2 - arm64 - qemu_arm - qemu_arm64 - qemu_i386 - qemu_x86_64 - x15 - arm - x86_64 Test Suites --- * boot * install-android-platform-tools-r2600 * kselftest * libhugetlbfs * ltp-cap_bounds-tests * ltp-commands-tests * ltp-containers-tests * ltp-cpuhotplug-tests * ltp-cve-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-ipc-tests * ltp-math-tests * ltp-mm-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * ltp-timers-tests * perf * spectre-meltdown-checker-test * ltp-dio-tests * ltp-open-posix-tests * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-none -- Linaro LKFT https://lkft.linaro.org
Re: [PATCH 4.4 000/131] 4.4.178-stable review
On Mon, 1 Apr 2019 at 22:59, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.4.178 release. > There are 131 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Wed Apr 3 16:59:39 UTC 2019. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.178-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.4.y > and the diffstat can be found below. > > thanks, > > greg k-h > Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386. Summary kernel: 4.4.178-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.4.y git commit: d83f26e3dc56e1998cf85b7d35bf5c5819f03215 git describe: v4.4.177-132-gd83f26e3dc56 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.177-132-gd83f26e3dc56 No regressions (compared to build v4.4.177) No fixes (compared to build v4.4.177) Ran 17065 total tests in the following environments and test suites. Environments -- - i386 - juno-r2 - arm64 - qemu_arm - qemu_i386 - qemu_x86_64 - x15 - arm - x86_64 Test Suites --- * boot * kselftest * libhugetlbfs * ltp-cap_bounds-tests * ltp-commands-tests * ltp-containers-tests * ltp-cpuhotplug-tests * ltp-cve-tests * ltp-dio-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-ipc-tests * ltp-math-tests * ltp-mm-tests * ltp-nptl-tests * ltp-open-posix-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-timers-tests * perf * spectre-meltdown-checker-test * v4l2-compliance * ltp-syscalls-tests * install-android-platform-tools-r2600 * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-none Summary kernel: 4.4.178-rc1 git repo: https://git.linaro.org/lkft/arm64-stable-rc.git git branch: 4.4.178-rc1-hikey-20190401-414 git commit: 2d75babf7185cfb2ecd3c49eb62339fbf6e01ae1 git describe: 4.4.178-rc1-hikey-20190401-414 Test details: https://qa-reports.linaro.org/lkft/linaro-hikey-stable-rc-4.4-oe/build/4.4.178-rc1-hikey-20190401-414 No regressions (compared to build 4.4.178-rc1-hikey-20190401-413) No fixes (compared to build 4.4.178-rc1-hikey-20190401-413) Ran 3008 total tests in the following environments and test suites. Environments -- - hi6220-hikey - arm64 - qemu_arm64 Test Suites --- * boot * install-android-platform-tools-r2600 * kselftest * libhugetlbfs * ltp-cap_bounds-tests * ltp-commands-tests * ltp-containers-tests * ltp-cpuhotplug-tests * ltp-cve-tests * ltp-dio-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-ipc-tests * ltp-math-tests * ltp-mm-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * ltp-timers-tests * perf * spectre-meltdown-checker-test * v4l2-compliance -- Linaro LKFT https://lkft.linaro.org
Re: [PATCH v2] gcov: fix when CONFIG_MODULES is not set
On Sun, Mar 31, 2019 at 6:57 AM Tri Vo wrote:
>
> On Fri, Mar 29, 2019 at 1:53 PM Randy Dunlap wrote:
> >
> > On 3/29/19 11:18 AM, Nick Desaulniers wrote:
> > > Fixes commit 8c3d220cb6b5 ("gcov: clang support")
> >
> > There is a certain format for Fixes: and that's not quite it. :(
Looks like the format is:
Fixes: ("")
so:
Fixes: 8c3d220cb6b5 ("gcov: clang support")
We should update:
https://www.kernel.org/doc/html/v5.0/process/stable-kernel-rules.html
to include this information.
> Thanks for taking a look at this Nick! I believe same fix should be
> applied to kernel/gcov/clang.c. I'll send out an updated version later
> today.
All yours, happy to review.
--
Thanks,
~Nick Desaulniers
[PATCH v2 8/8] livepatch: Replace klp_ktype_patch's default_attrs with groups
The kobj_type default_attrs field is being replaced by the
default_groups field. Replace klp_ktype_patch's default_attrs field
with default_groups and use the ATTRIBUTE_GROUPS macro to create
klp_patch_groups.
This patch was tested by loading the livepatch-sample module and
verifying that the sysfs files for the attributes in the default groups
were created.
Signed-off-by: Kimberly Brown
---
kernel/livepatch/core.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
index eb0ee10a1981..34a8338657d2 100644
--- a/kernel/livepatch/core.c
+++ b/kernel/livepatch/core.c
@@ -419,6 +419,7 @@ static struct attribute *klp_patch_attrs[] = {
_kobj_attr.attr,
NULL
};
+ATTRIBUTE_GROUPS(klp_patch);
static void klp_free_object_dynamic(struct klp_object *obj)
{
@@ -546,7 +547,7 @@ static void klp_kobj_release_patch(struct kobject *kobj)
static struct kobj_type klp_ktype_patch = {
.release = klp_kobj_release_patch,
.sysfs_ops = _sysfs_ops,
- .default_attrs = klp_patch_attrs,
+ .default_groups = klp_patch_groups,
};
static void klp_kobj_release_object(struct kobject *kobj)
--
2.17.1
[PATCH v2 5/8] irqdesc: Replace irq_kobj_type's default_attrs field with groups
The kobj_type default_attrs field is being replaced by the
default_groups field. Replace irq_kobj_type's default_attrs field with
default_groups and use the ATTRIBUTE_GROUPS macro to create irq_groups.
This patch was tested by verifying that the sysfs files for the
attributes in the default groups were created.
Signed-off-by: Kimberly Brown
---
kernel/irq/irqdesc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/kernel/irq/irqdesc.c b/kernel/irq/irqdesc.c
index 13539e12cd80..bbec57bda666 100644
--- a/kernel/irq/irqdesc.c
+++ b/kernel/irq/irqdesc.c
@@ -275,11 +275,12 @@ static struct attribute *irq_attrs[] = {
_attr.attr,
NULL
};
+ATTRIBUTE_GROUPS(irq);
static struct kobj_type irq_kobj_type = {
.release= irq_kobj_release,
.sysfs_ops = _sysfs_ops,
- .default_attrs = irq_attrs,
+ .default_groups = irq_groups,
};
static void irq_sysfs_add(int irq, struct irq_desc *desc)
--
2.17.1
[PATCH v2 7/8] cpufreq: schedutil: Replace default_attrs field with groups
The kobj_type default_attrs field is being replaced by the
default_groups field. Replace sugov_tunables_ktype's default_attrs field
with default groups. Change "sugov_attributes" to "sugov_attrs" and use
the ATTRIBUTE_GROUPS macro to create sugov_groups.
This patch was tested by setting the scaling governor to schedutil and
verifying that the sysfs files for the attributes in the default groups
were created.
Signed-off-by: Kimberly Brown
---
kernel/sched/cpufreq_schedutil.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c
index 5c41ea367422..148b60c8993d 100644
--- a/kernel/sched/cpufreq_schedutil.c
+++ b/kernel/sched/cpufreq_schedutil.c
@@ -598,13 +598,14 @@ rate_limit_us_store(struct gov_attr_set *attr_set, const
char *buf, size_t count
static struct governor_attr rate_limit_us = __ATTR_RW(rate_limit_us);
-static struct attribute *sugov_attributes[] = {
+static struct attribute *sugov_attrs[] = {
_limit_us.attr,
NULL
};
+ATTRIBUTE_GROUPS(sugov);
static struct kobj_type sugov_tunables_ktype = {
- .default_attrs = sugov_attributes,
+ .default_groups = sugov_groups,
.sysfs_ops = _sysfs_ops,
};
--
2.17.1
[PATCH v2 2/8] samples/kobject: Replace foo_ktype's default_attrs field with groups
The kobj_type default_attrs field is being replaced by the
default_groups field. Replace foo_ktype's default_attrs field with
default_groups and use the ATTRIBUTE_GROUPS macro to create
foo_default_groups.
This patch was tested by loading the kset-example module and verifying
that the sysfs files for the attributes in the default group were
created.
Signed-off-by: Kimberly Brown
---
samples/kobject/kset-example.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/samples/kobject/kset-example.c b/samples/kobject/kset-example.c
index 401328fd687d..c8010f126808 100644
--- a/samples/kobject/kset-example.c
+++ b/samples/kobject/kset-example.c
@@ -178,6 +178,7 @@ static struct attribute *foo_default_attrs[] = {
_attribute.attr,
NULL, /* need to NULL terminate the list of attributes */
};
+ATTRIBUTE_GROUPS(foo_default);
/*
* Our own ktype for our kobjects. Here we specify our sysfs ops, the
@@ -187,7 +188,7 @@ static struct attribute *foo_default_attrs[] = {
static struct kobj_type foo_ktype = {
.sysfs_ops = _sysfs_ops,
.release = foo_release,
- .default_attrs = foo_default_attrs,
+ .default_groups = foo_default_groups,
};
static struct kset *example_kset;
--
2.17.1
[PATCH v2 1/8] kobject: Add support for default attribute groups to kobj_type
kobj_type currently uses a list of individual attributes to store
default attributes. Attribute groups are more flexible than a list of
attributes because groups provide support for attribute visibility. So,
add support for default attribute groups to kobj_type.
In future patches, the existing uses of kobj_type’s attribute list will
be converted to attribute groups. When that is complete, kobj_type’s
attribute list, “default_attrs”, will be removed.
Signed-off-by: Kimberly Brown
---
include/linux/kobject.h | 3 ++-
lib/kobject.c | 14 ++
2 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/include/linux/kobject.h b/include/linux/kobject.h
index 1ab0d624fb36..e2ca0a292e21 100644
--- a/include/linux/kobject.h
+++ b/include/linux/kobject.h
@@ -139,7 +139,8 @@ static inline bool kobject_has_children(struct kobject
*kobj)
struct kobj_type {
void (*release)(struct kobject *kobj);
const struct sysfs_ops *sysfs_ops;
- struct attribute **default_attrs;
+ struct attribute **default_attrs; /* use default_groups instead */
+ const struct attribute_group **default_groups;
const struct kobj_ns_type_operations *(*child_ns_type)(struct kobject
*kobj);
const void *(*namespace)(struct kobject *kobj);
void (*get_ownership)(struct kobject *kobj, kuid_t *uid, kgid_t *gid);
diff --git a/lib/kobject.c b/lib/kobject.c
index aa89edcd2b63..ede40005db28 100644
--- a/lib/kobject.c
+++ b/lib/kobject.c
@@ -82,6 +82,7 @@ static int populate_dir(struct kobject *kobj)
static int create_dir(struct kobject *kobj)
{
+ const struct kobj_type *ktype = get_ktype(kobj);
const struct kobj_ns_type_operations *ops;
int error;
@@ -95,6 +96,14 @@ static int create_dir(struct kobject *kobj)
return error;
}
+ if (ktype) {
+ error = sysfs_create_groups(kobj, ktype->default_groups);
+ if (error) {
+ sysfs_remove_dir(kobj);
+ return error;
+ }
+ }
+
/*
* @kobj->sd may be deleted by an ancestor going away. Hold an
* extra reference so that it stays until @kobj is gone.
@@ -584,11 +593,16 @@ EXPORT_SYMBOL_GPL(kobject_move);
void kobject_del(struct kobject *kobj)
{
struct kernfs_node *sd;
+ const struct kobj_type *ktype = get_ktype(kobj);
if (!kobj)
return;
sd = kobj->sd;
+
+ if (ktype)
+ sysfs_remove_groups(kobj, ktype->default_groups);
+
sysfs_remove_dir(kobj);
sysfs_put(sd);
--
2.17.1
Re: [PATCH v3 3/4] driver core: add dev_print_hex_dump() logging function.
On Thu, Mar 28, 2019 at 12:29:52PM +0100, Greg Kroah-Hartman wrote: > On Thu, Mar 28, 2019 at 03:27:55AM -0700, Life is hard, and then you die > wrote: > > > > On Thu, Mar 28, 2019 at 06:29:17AM +0100, Greg Kroah-Hartman wrote: > > > On Wed, Mar 27, 2019 at 05:28:17PM -0700, Life is hard, and then you die > > > wrote: > > > > > > > > On Wed, Mar 27, 2019 at 11:37:57AM +0900, Greg Kroah-Hartman wrote: > > > > > On Tue, Mar 26, 2019 at 06:48:06PM -0700, Ronald Tschalär wrote: > > > > > > This is the dev_xxx() analog to print_hex_dump(), using dev_printk() > > > > > > instead of straight printk() to match other dev_xxx() logging > > > > > > functions. > > > > > > --- > > > > > > drivers/base/core.c| 43 > > > > > > ++ > > > > > > include/linux/device.h | 15 +++ > > > > > > 2 files changed, 58 insertions(+) [snip] > > > > > Anyway, no, please do not do this. Please do not dump large hex > > > > > values > > > > > like this to the kernel log, it does not help anyone. > > > > > > > > > > You can do this while debugging, sure, but not for "real" kernel code. > > > > > > > > As used by this driver, it is definitely called for debugging only and > > > > must be explicitly enabled via a module param. But having the ability > > > > for folks to easily generate and print out debugging info has proven > > > > quite valuable. > > > > > > We have dynamic debugging, no need for module parameters at all. This > > > isn't the 1990's anymore :) > > > > I am aware of dynamic debugging, but there are several issues with it > > from the perspective of the logging I'm doing here (I mentioned these > > in response to an earlier review already): > > > > 1. Dynamic debugging can't be enabled at a function or line level on > > the kernel command line, so this means that to debug issues > > during boot you have to enable everything, which can be way too > > verbose > > You can, and should enable it at a function or line level by writing to > the proper kernel file in debugfs. > > You have read Documentation/admin-guide/dynamic-debug-howto.rst, right? Yes, and I've played with the parameters quite a bit. > No need to do anything on the command line, that's so old-school :) Sorry if I'm being unduly dense, but then how to enable debugging during early boot? The only other alternative I see is modifying the initrd, and asking folks to do that is noticeably more complicated than having them add something to the command line in grub. So from my perspective I find kernel params far from old-school :-) > > 2. The expressions to enable the individual logging statements are > > quite brittle (in particular the line-based ones) since they > > (may) change any time the code is changed - having stable > > commands to give to users and put in documentation (e.g. > > "echo 0x200 > /sys/module/applespi/parameters/debug") is > > quite valuable. > > > > One way to work around this would be to put every single logging > > statement in a function of its own, thereby ensuring a stable > > name is associated with each one. > > Again, read the documentation, this works today as-is. I have read it (we're talking about the dynamic debug docs here), but I just don't see how it addresses this in any way. > > 3. In at least two places we log different types of packets in the > > same lines of code (protected by a "if (log_mask & PKT_TYPE)") - > > dynamic-debug would only allow enabling or disabling logging of > > all packets. This could be worked around by creating a separate > > (but essentially duplicate) logging function for each packet type > > and some lookup table to call the appropriate one. Not very > > pretty IMO, though. > > True, but you can use tracepoints as well, that would probably be much > easier when you are logging data streams. You can also use an ebpf > program with the tracepoints to log just what you need/want to when you > want to as well. Thanks for the hint, I hadn't paid much attention to tracepoints till now. They do solve most of these issues I've mentioned here, though. So I've actually gone and implemented the tracing as tracepoints now. Two issues I noticed though: 1. since filters can't be enabled on the command line (and yes, we seem to disagree on the usefulness of the command line) it means I had to essentially create tracepoints for every trace+filter combo I may want to enable (in my case it's just one field, so I ended up with 8 tracepoints instead of 1). Not a big deal in my case, but could get ugly. 2. in cases where there is relevant log output too, folks have to be told to provide both trace and dmesg output, the outputs have to merged back together again. Though I note that with the use of the tp_printk kernel param this inconvenience goes away again (but we're back to logging the traces in the kernel
Re: [PATCH 1/2] printk: Add an option to flush all messages on panic
Hi Mukesh,
On Mon, Apr 01, 2019 at 05:20:33PM +0530, Mukesh Ojha wrote:
>
> On 4/1/2019 4:18 PM, Feng Tang wrote:
> > Current console_flush_on_panic() will only dump the new messages
> > in buffer, and users may need an opportunity to check all the
> > messages on panic which could help debugging, as user may haven't
> > seen the log before panic due to loglevel settings.
> >
> > Add a flag for console_flush_on_panic() to chose whether to
> > dump all messages.
> >
> > Signed-off-by: Feng Tang
>
>
> Looks good to me.
Thanks for the review.
>
>
> But, Will it not be good if put it under a config and not change the
> prototype, as it is a debug feature?
My understanding is the console_flush_on_panic() is also a debug
feature too :), and my 2/2 patch will has a bitmask (either controlled
by kernel cmdline or sysctl) to turn on this.
Thanks,
Feng
>
> Thanks,
> Mukesh
>
> > ---
> > arch/powerpc/kernel/traps.c | 2 +-
> > include/linux/console.h | 2 +-
> > kernel/panic.c | 2 +-
> > kernel/printk/printk.c | 9 -
> > 4 files changed, 11 insertions(+), 4 deletions(-)
> >
> > diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
> > index 1fd45a8..58d9580 100644
> > --- a/arch/powerpc/kernel/traps.c
> > +++ b/arch/powerpc/kernel/traps.c
> > @@ -179,7 +179,7 @@ extern void panic_flush_kmsg_end(void)
> > kmsg_dump(KMSG_DUMP_PANIC);
> > bust_spinlocks(0);
> > debug_locks_off();
> > - console_flush_on_panic();
> > + console_flush_on_panic(false);
> > }
> > static unsigned long oops_begin(struct pt_regs *regs)
> > diff --git a/include/linux/console.h b/include/linux/console.h
> > index ec9bdb3..825ecf5 100644
> > --- a/include/linux/console.h
> > +++ b/include/linux/console.h
> > @@ -175,7 +175,7 @@ extern int console_trylock(void);
> > extern void console_unlock(void);
> > extern void console_conditional_schedule(void);
> > extern void console_unblank(void);
> > -extern void console_flush_on_panic(void);
> > +extern void console_flush_on_panic(bool flush_all);
> > extern struct tty_driver *console_device(int *);
> > extern void console_stop(struct console *);
> > extern void console_start(struct console *);
> > diff --git a/kernel/panic.c b/kernel/panic.c
> > index 0ae0d73..fb77e01 100644
> > --- a/kernel/panic.c
> > +++ b/kernel/panic.c
> > @@ -277,7 +277,7 @@ void panic(const char *fmt, ...)
> > * panic() is not being callled from OOPS.
> > */
> > debug_locks_off();
> > - console_flush_on_panic();
> > + console_flush_on_panic(false);
> > panic_print_sys_info();
> > diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> > index 02ca827..8ff099b 100644
> > --- a/kernel/printk/printk.c
> > +++ b/kernel/printk/printk.c
> > @@ -2525,10 +2525,11 @@ void console_unblank(void)
> > /**
> >* console_flush_on_panic - flush console content on panic
> > + * @flush_all: whether to print all messages in buffer
> >*
> >* Immediately output all pending messages no matter what.
> >*/
> > -void console_flush_on_panic(void)
> > +void console_flush_on_panic(bool flush_all)
> > {
> > /*
> > * If someone else is holding the console lock, trylock will fail
> > @@ -2539,6 +2540,12 @@ void console_flush_on_panic(void)
> > */
> > console_trylock();
> > console_may_schedule = 0;
> > +
> > + /* User may want to see all the printk messages on panic */
> > + if (flush_all) {
> > + console_seq = log_first_seq;
> > + console_idx = log_first_idx;
> > + }
> > console_unlock();
> > }
Re: [PATCH] vfio/type1: Limit DMA mappings per container
On Mon, Apr 01, 2019 at 02:16:52PM -0600, Alex Williamson wrote:
[...]
> @@ -1081,8 +1088,14 @@ static int vfio_dma_do_map(struct vfio_iommu *iommu,
> goto out_unlock;
> }
>
> + if (!atomic_add_unless(>dma_avail, -1, 0)) {
> + ret = -ENOSPC;
> + goto out_unlock;
> + }
> +
> dma = kzalloc(sizeof(*dma), GFP_KERNEL);
> if (!dma) {
> + atomic_inc(>dma_avail);
This should be the only special path to revert the change. Not sure
whether this can be avoided by simply using atomic_read() or even
READ_ONCE() (I feel like we don't need atomic ops with dma_avail
because we've had the mutex but it of course it doesn't hurt...) to
replace atomic_add_unless() above to check against zero then we do
+1/-1 in vfio_[un]link_dma() only. But AFAICT this patch is correct.
Reviewed-by: Peter Xu
Thanks,
--
Peter Xu
[mt76] c1e0d2be0a: BUG:pagefault_on_kernel_address#in_non-whitelisted_uaccess
FYI, we noticed the following commit (built with gcc-7):
commit: c1e0d2be0acff5e99a59ddcc5af415e48abc6c5e ("mt76: mmio: introduce
mt76x02_check_tx_hang watchdog")
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
in testcase: trinity
with following parameters:
runtime: 300s
test-description: Trinity is a linux system call fuzz tester.
test-url: http://codemonkey.org.uk/projects/trinity/
on test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp 2 -m 2G
caused below changes (please refer to attached dmesg/kmsg for entire
log/backtrace):
++++
|| 87e86f9019 |
c1e0d2be0a |
++++
| boot_successes | 167| 140
|
| boot_failures | 0 | 23
|
| BUG:pagefault_on_kernel_address#in_non-whitelisted_uaccess | 0 | 23
|
| BUG:unable_to_handle_kernel| 0 | 23
|
| Oops:#[##] | 0 | 23
|
| RIP:strncpy_from_user | 0 | 23
|
| Kernel_panic-not_syncing:Fatal_exception | 0 | 23
|
++++
[ 10.383586] BUG: pagefault on kernel address 0x93d4b5cd8000 in
non-whitelisted uaccess
[ 10.390934] BUG: unable to handle kernel paging request at 93d4b5cd8000
[ 10.390934] #PF error: [normal kernel read fault]
[ 10.390934] PGD 21e00067 P4D 21e00067 PUD 21e04067 PMD 78b57067 PTE
800f8a327060
[ 10.390934] Oops: [#1] PREEMPT SMP DEBUG_PAGEALLOC
[ 10.390934] CPU: 1 PID: 1 Comm: swapper/0 Tainted: GT
5.0.0-rc1-00033-gc1e0d2b #1
[ 10.390934] RIP: 0010:strncpy_from_user+0x87/0x10c
[ 10.390934] Code: 00 00 66 66 90 4c 39 c2 48 bb ff fe fe fe fe fe fe fe 49
ba 80 80 80 80 80 80 80 80 4c 0f 46 c2 31 c0 45 31 db eb 4c 44 89 d9 <4c> 8b 0c
06 85 c9 74 05 45 31 d2 eb 61 49 8d 0c 19 4c 89 0c 07 49
[ 10.390934] RSP: :bd8c00323bc0 EFLAGS: 00010206
[ 10.390934] RAX: 0028 RBX: fefefefefefefeff RCX:
[ 10.390934] RDX: 0fe0 RSI: 93d4b5cd7fd6 RDI: 93d4af5e3020
[ 10.390934] RBP: ff9c R08: 0fe0 R09: 8c93909d92868cd1
[ 10.390934] R10: 8080808080808080 R11: R12: 93d4b5cd7fd6
[ 10.390934] R13: 93d4b5cd7fd6 R14: R15:
[ 10.390934] FS: () GS:93d4b640()
knlGS:
[ 10.390934] CS: 0010 DS: ES: CR0: 80050033
[ 10.390934] CR2: 93d4b5cd8000 CR3: 20c15000 CR4: 06e0
[ 10.390934] Call Trace:
[ 10.390934] ? getname_flags+0x6f/0x199
[ 10.390934] ? user_path_at_empty+0x18/0x2f
[ 10.390934] ? vfs_statx+0x6d/0xb3
[ 10.390934] ? clean_path+0x5c/0x102
[ 10.390934] ? do_name+0xf4/0x40e
[ 10.390934] ? write_buffer+0x52/0x8a
[ 10.390934] ? flush_buffer+0xe7/0x140
[ 10.390934] ? initrd_load+0xa8/0xa8
[ 10.390934] ? __gunzip+0x53a/0x6b7
[ 10.390934] ? bunzip2+0x76a/0x76a
[ 10.390934] ? write_buffer+0x8a/0x8a
[ 10.390934] ? gunzip+0x39/0x3d
[ 10.390934] ? initrd_load+0xa8/0xa8
[ 10.390934] ? unpack_to_rootfs+0x1c6/0x3c6
[ 10.390934] ? initrd_load+0xa8/0xa8
[ 10.390934] ? populate_rootfs+0x94/0x213
[ 10.390934] ? clean_rootfs+0x23b/0x23b
[ 10.390934] ? do_one_initcall+0x61/0x12a
[ 10.390934] ? kernel_init_freeable+0x1a8/0x305
[ 10.390934] ? rest_init+0x13a/0x13a
[ 10.390934] ? kernel_init+0x5/0xeb
[ 10.390934] ? ret_from_fork+0x35/0x40
[ 10.390934] Modules linked in:
[ 10.390934] CR2: 93d4b5cd8000
[ 10.390934] ---[ end trace 81b307b1a0dd06e6 ]---
To reproduce:
# build kernel
cd linux
cp config-5.0.0-rc1-00033-gc1e0d2b .config
make HOSTCC=gcc-7 CC=gcc-7 ARCH=x86_64 olddefconfig
make HOSTCC=gcc-7 CC=gcc-7 ARCH=x86_64 prepare
make HOSTCC=gcc-7 CC=gcc-7 ARCH=x86_64 modules_prepare
make HOSTCC=gcc-7 CC=gcc-7 ARCH=x86_64 SHELL=/bin/bash
make HOSTCC=gcc-7 CC=gcc-7 ARCH=x86_64 bzImage
git clone https://github.com/intel/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k job-script # job-script is attached in this
email
Thanks,
Rong Chen
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 5.0.0-rc1 Kernel Configuration
#
#
# Compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
#
CONFIG_CC_IS_GCC=y
CONFIG_GCC_VERSION=70300
CONFIG_CLANG_VERSION=0
CONFIG_CC_HAS_ASM_GOTO=y
CONFIG_CONSTRUCTORS=y
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
Re: [PATCH 1/2] printk: Add an option to flush all messages on panic
On (04/02/19 10:28), Feng Tang wrote:
> > So my first thought was - let's not add a `bool flag', but instead add
> > an `enum' with clear flag names, e.g. DUMP_ALL/DUMP_PENDING, etc. Something
> > similar to what ftrace_dump(DUMP_ALL) does. And we already have panic_print
> > bit-mask and panic_print_sys_info(), which controls what we print when in
> > panic. So we can move console_flush_on_panic() to panic_print_sys_info()
> > and handle different types of console_flush_on_panic() there:
> >
> > ---
> >
> > diff --git a/kernel/panic.c b/kernel/panic.c
> > index 0ae0d7332f12..e142faaebbcd 100644
> > --- a/kernel/panic.c
> > +++ b/kernel/panic.c
> > @@ -134,6 +134,11 @@ EXPORT_SYMBOL(nmi_panic);
> >
> > static void panic_print_sys_info(void)
> > {
> > + if (panic_print & PANIC_PRINT_REPLAY_LOGBUF)
> > + console_flush_on_panic(DUMP_ALL);
> > + else
> > + console_flush_on_panic(DUMP_PENDING);
> > +
> > if (panic_print & PANIC_PRINT_TASK_INFO)
> > show_state();
> >
> > @@ -277,7 +282,6 @@ void panic(const char *fmt, ...)
> > * panic() is not being callled from OOPS.
> > */
> > debug_locks_off();
> > - console_flush_on_panic();
> >
> > panic_print_sys_info();
> >
>
> I guess this is what my 2/2 patch exactly does :)
Oh, indeed... I didn't check 2/2.
-ss
Re: [PATCH 1/2] printk: Add an option to flush all messages on panic
Hi Sergey,
Thanks for the review.
On Tue, Apr 02, 2019 at 11:14:19AM +0900, Sergey Senozhatsky wrote:
> On (04/01/19 18:48), Feng Tang wrote:
> > diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
> > index 1fd45a8..58d9580 100644
> > --- a/arch/powerpc/kernel/traps.c
> > +++ b/arch/powerpc/kernel/traps.c
> > @@ -179,7 +179,7 @@ extern void panic_flush_kmsg_end(void)
> > kmsg_dump(KMSG_DUMP_PANIC);
> > bust_spinlocks(0);
> > debug_locks_off();
> > - console_flush_on_panic();
> > + console_flush_on_panic(false);
> > }
> [..]
> > @@ -277,7 +277,7 @@ void panic(const char *fmt, ...)
> > * panic() is not being callled from OOPS.
> > */
> > debug_locks_off();
> > - console_flush_on_panic();
> > + console_flush_on_panic(false);
> [..]
> > -void console_flush_on_panic(void)
> > +void console_flush_on_panic(bool flush_all)
> > {
> > /*
> > * If someone else is holding the console lock, trylock will fail
> > @@ -2539,6 +2540,12 @@ void console_flush_on_panic(void)
> > */
> > console_trylock();
> > console_may_schedule = 0;
> > +
> > + /* User may want to see all the printk messages on panic */
> > + if (flush_all) {
> > + console_seq = log_first_seq;
> > + console_idx = log_first_idx;
> > + }
> > console_unlock();
>
> So my first thought was - let's not add a `bool flag', but instead add
> an `enum' with clear flag names, e.g. DUMP_ALL/DUMP_PENDING, etc. Something
> similar to what ftrace_dump(DUMP_ALL) does. And we already have panic_print
> bit-mask and panic_print_sys_info(), which controls what we print when in
> panic. So we can move console_flush_on_panic() to panic_print_sys_info()
> and handle different types of console_flush_on_panic() there:
>
> ---
>
> diff --git a/kernel/panic.c b/kernel/panic.c
> index 0ae0d7332f12..e142faaebbcd 100644
> --- a/kernel/panic.c
> +++ b/kernel/panic.c
> @@ -134,6 +134,11 @@ EXPORT_SYMBOL(nmi_panic);
>
> static void panic_print_sys_info(void)
> {
> + if (panic_print & PANIC_PRINT_REPLAY_LOGBUF)
> + console_flush_on_panic(DUMP_ALL);
> + else
> + console_flush_on_panic(DUMP_PENDING);
> +
> if (panic_print & PANIC_PRINT_TASK_INFO)
> show_state();
>
> @@ -277,7 +282,6 @@ void panic(const char *fmt, ...)
>* panic() is not being callled from OOPS.
>*/
> debug_locks_off();
> - console_flush_on_panic();
>
> panic_print_sys_info();
>
I guess this is what my 2/2 patch exactly does :)
> ---
>
> After looking at this more - DUMP_ALL/DUMP_PENDING clearly depend
> on panic_print. So... May be we can move panic_print_sys_info() to
> printk.c, and for PANIC_PRINT_REPLAY_LOGBUF case just reset console
> seq/idx (console seq/idx are internal to printk) before we
> flush_on_panic. This way we would not need to modify
> console_flush_on_panic() prototype at all.
My thought is panic_print_sys_info() may be more related to panic, but
I'm fine with either way.
Thanks,
Feng
>
> Let's hear from people.
>
> -ss
Re: Nested events with zero deltas, can use absolute timestamps instead?
On Mon, 1 Apr 2019 15:54:20 -0700 Jason Behmer wrote: > The concurrency model is still a little bit unclear to me as I'm new > to this codebase. So I'm having some trouble reasoning about what > operations are safe at one point on the ring buffer.It seems like > we can't be preempted in general, just interrupts? And the events for > the events emitted by interrupts will be fully processed before > getting back to the event pointed at by the commit pointer? If this > is true I think the approach below (and prototyped in the attached > patch against head) might work and would love feedback. If not, this > problem is way harder. > > We detect nested events by checking our event pointer against the > commit pointer. This is safe because we reserve our event space > atomically in the buffer, leading to an ordering of events we can > depend on. But to add a TIME_STAMP event we need to reserve more > space before we even have an event pointer, so we need to know > something about the ordering of events before we've actually > atomically reserved ours. We could check if the write pointer is set > to the commit pointer, and if it isn't we know we're a nested event. > But, someone could update the write pointer and/or commit pointer > between the time we check it and the time we atomically reserve our > space in the buffer. However, I think maybe this is ok. > > If we see that the write pointer is not equal to the commit pointer, > then we're in an interrupt, and the only thing that could update the > commit pointer is the original event emitting code that was > interrupted, which can't run again until we're finished. And the only > thing that can update the write pointer is further interrupts of us, > which will advance the write pointer further away from commit, leaving > our decision to allocate a TIME_STAMP event as valid. > > If we see that the write pointer is equal to the commit pointer, then > anything that interrupts us before we move the write pointer will see > that same state and will need to, before returning to us, commit their > event and set commit to their new write pointer, which will make our > decision valid once again. > > There's a lot of assumptions in there that I'd love to be checked on > as I'm new to this code base. For example I haven't read the read > path at all and have no idea if it interacts with this at all. I think you pretty much got the idea correct. The issue is what to put into the extra timestamp value. As the time we record the timestamp compared to the time we allocate the space for the timestamp is not atomic. And we can't have time go backwards :-( | | commit --->+--+ | TS offset from previous event| (A) +--+ | outer event data | +--+ | extended TS | (B) +--+ | interrupt event data | +--+ head --->| | TS = rdstc(); A = reserve_ring_buffer *A = TS interrupt: TS = rdtsc(); B = reserve_ring_buffer *B = TS What's important is what we store in A and B TS = rdtsc(); ---> TS = rdstc() (this is first commit!) A = reserver_ring_buffer *A = TS (finish commit) < A = reserver_ring_buffer *A = TS You can see how the recording of the timestamp and writing it gets complex. Also it gets more complex when we use deltas and not direct writes. Now we may be able to handle this if we take the timestamp before doing anything, and if it's nested, take it again (which should guarantee that it's after the previous timestamp) Now of course the question is, how do we update the write stamp that we will use to compute new "deltas"? Or we just use absolute timestamps to the end of the page, and start over again, when we start a new page that isn't nested. But see where the complexity comes from? -- Steve
Re: [PATCH 1/2] printk: Add an option to flush all messages on panic
On (04/01/19 18:48), Feng Tang wrote:
> diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
> index 1fd45a8..58d9580 100644
> --- a/arch/powerpc/kernel/traps.c
> +++ b/arch/powerpc/kernel/traps.c
> @@ -179,7 +179,7 @@ extern void panic_flush_kmsg_end(void)
> kmsg_dump(KMSG_DUMP_PANIC);
> bust_spinlocks(0);
> debug_locks_off();
> - console_flush_on_panic();
> + console_flush_on_panic(false);
> }
[..]
> @@ -277,7 +277,7 @@ void panic(const char *fmt, ...)
>* panic() is not being callled from OOPS.
>*/
> debug_locks_off();
> - console_flush_on_panic();
> + console_flush_on_panic(false);
[..]
> -void console_flush_on_panic(void)
> +void console_flush_on_panic(bool flush_all)
> {
> /*
>* If someone else is holding the console lock, trylock will fail
> @@ -2539,6 +2540,12 @@ void console_flush_on_panic(void)
>*/
> console_trylock();
> console_may_schedule = 0;
> +
> + /* User may want to see all the printk messages on panic */
> + if (flush_all) {
> + console_seq = log_first_seq;
> + console_idx = log_first_idx;
> + }
> console_unlock();
So my first thought was - let's not add a `bool flag', but instead add
an `enum' with clear flag names, e.g. DUMP_ALL/DUMP_PENDING, etc. Something
similar to what ftrace_dump(DUMP_ALL) does. And we already have panic_print
bit-mask and panic_print_sys_info(), which controls what we print when in
panic. So we can move console_flush_on_panic() to panic_print_sys_info()
and handle different types of console_flush_on_panic() there:
---
diff --git a/kernel/panic.c b/kernel/panic.c
index 0ae0d7332f12..e142faaebbcd 100644
--- a/kernel/panic.c
+++ b/kernel/panic.c
@@ -134,6 +134,11 @@ EXPORT_SYMBOL(nmi_panic);
static void panic_print_sys_info(void)
{
+ if (panic_print & PANIC_PRINT_REPLAY_LOGBUF)
+ console_flush_on_panic(DUMP_ALL);
+ else
+ console_flush_on_panic(DUMP_PENDING);
+
if (panic_print & PANIC_PRINT_TASK_INFO)
show_state();
@@ -277,7 +282,6 @@ void panic(const char *fmt, ...)
* panic() is not being callled from OOPS.
*/
debug_locks_off();
- console_flush_on_panic();
panic_print_sys_info();
---
After looking at this more - DUMP_ALL/DUMP_PENDING clearly depend
on panic_print. So... May be we can move panic_print_sys_info() to
printk.c, and for PANIC_PRINT_REPLAY_LOGBUF case just reset console
seq/idx (console seq/idx are internal to printk) before we
flush_on_panic. This way we would not need to modify
console_flush_on_panic() prototype at all.
Let's hear from people.
-ss
Re: [PATCH 0/2] Add Updown Counter support for Milbeaut M10V SoC
Hi Jonathan, On 2019/03/31 3:36, Jonathan Cameron wrote: On Tue, 26 Mar 2019 15:32:34 +0900 Shinji Kanematsu wrote: This is a series of patch which adds Updown Counter support on Milbeaut M10V SoC. The Updown Counter counts input pulse signal from external quadrature encoder. It also has input pulse signal counter function. Hi Shinji, Are you aware of the counter subsystem that has been proposed (and as far as I am concerned is ready to be merged)? https://patchwork.kernel.org/project/linux-iio/list/?series=147 (I think that's the latest version posted).. William, perhaps you could give an update? (bad luck, you are getting popular ;) I'll take a quick review as it stands, as some issues may carry over. I appreciate that it's always unfortunate to try to upstream stuff at the same time as a new framework is being developed / upstreamed, but I don't intend to take any additional counter drivers into IIO. We just end up having to maintain old interfaces in more and more drivers. Thank you for your reply. I just learned that upstream requires the counter subsystem. Detailed information was given by William. Thank you, Kanematsu Thanks, Jonathan Shinji Kanematsu (2): dt-bindings: iio: counter: Add Milbeaut Updown Counter iio: counter: Add support for Milbeaut Updown Counter .../bindings/iio/counter/milbeaut-updown_cnt.txt | 22 ++ drivers/iio/counter/Kconfig| 12 + drivers/iio/counter/Makefile | 1 + drivers/iio/counter/milbeaut-updown.h | 38 ++ drivers/iio/counter/milbeaut-updown_cnt.c | 385 + 5 files changed, 458 insertions(+) create mode 100644 Documentation/devicetree/bindings/iio/counter/milbeaut-updown_cnt.txt create mode 100644 drivers/iio/counter/milbeaut-updown.h create mode 100644 drivers/iio/counter/milbeaut-updown_cnt.c
Re: [PATCH v1 1/2] dt-bindings: mmc: sdhci-fujitsu.txt: add miilbeaut driver
Hi
> On Tue, Mar 26, 2019 at 02:53:37PM +0900, Takao Orito wrote:
> > Add new compatible description for Milbeaut SoC. Socionext
> > inherits F_SDH30 IP from Fujitsu. Then new Soc series "Milbeaut"
> > has F_SDH30 controller specified by "socionext,milbeaut-m10v-sdhci-3.0".
>
> Subject is wrong, you're not adding a driver.
OK, I will change "dt-bindings: mmc: sdhci-fujitsu.txt: add milbeaut support"
>
> >
> > Signed-off-by: Takao Orito
> > ---
> > .../devicetree/bindings/mmc/sdhci-fujitsu.txt | 22
> > +++---
> > 1 file changed, 19 insertions(+), 3 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/mmc/sdhci-fujitsu.txt
> > b/Documentation/devicetree/bindings/mmc/sdhci-fujitsu.txt
> > index 3ee9263..405811f 100644
> > --- a/Documentation/devicetree/bindings/mmc/sdhci-fujitsu.txt
> > +++ b/Documentation/devicetree/bindings/mmc/sdhci-fujitsu.txt
> > @@ -1,10 +1,10 @@
> > -* Fujitsu SDHCI controller
> > +* Fujitsu/Socionext SDHCI controller
> >
> > This file documents differences between the core properties in mmc.txt
> > -and the properties used by the sdhci_f_sdh30 driver.
> > +and the properties used by the sdhci_f_sdh30.
> >
> > Required properties:
> > -- compatible: "fujitsu,mb86s70-sdhci-3.0"
> > +- compatible: "fujitsu,mb86s70-sdhci-3.0",
> > "socionext,milbeaut-m10v-sdhci-3.0"
>
> One per line please.
I see, I will fix.
>
> > - clocks: Must contain an entry for each entry in clock-names. It is a
> >list of phandles and clock-specifier pairs.
> >See ../clocks/clock-bindings.txt for details.
> > @@ -17,6 +17,8 @@ Optional properties:
> >as the VCCQ/VDD_IO supply in the eMMC/SD specs.
> > - fujitsu,cmd-dat-delay-select: boolean property indicating that this host
> >requires the CMD_DAT_DELAY control to be enabled.
> > +- sni,mmc-power-gpio: set property indicating that power on or off needs
> > + control of gpio. This is for only "socionext,milbeaut-m10v-sdhci-3.0".
>
> s/-gpio/-gpios/
I will fix.
>
> >
> > Example:
> >
> > @@ -30,3 +32,17 @@ Example:
> > clocks = < 2 2 0>, < 2 3 0>;
> > clock-names = "iface", "core";
> > };
> > +
> > +Exsample2:
> > + sdhci3: mmc@1b01 {
> > + compatible = "socionext,milbeaut-m10v-sdhci-3.0";
> > + reg = <0x1b01 0x1>;
> > + interrupts = <0 265 0x4>;
> > + voltage-ranges = <3300 3300>;
> > + bus-width = <4>;
> > + clocks = <>, <_clk>;
> > + clock-names = "core", "iface";
> > + cap-sdio-irq;
> > + sni,mmc-power-gpio = < 53 GPIO_ACTIVE_HIGH>;
> > + fujitsu,cmd-dat-delay-select;
>
> Indentation problem.
Sorry, I will fix.
Thank you
Orito
>
> > + };
> > --
> > 1.9.1
> >
> >
--
Takao Orito
Re: [PATCH v2] avia-hx711.yaml: transform DT binding to YAML
On Mon, Apr 1, 2019 at 12:34 PM Andreas Klinger wrote: > > replace avia-hx711.txt by avia-hx711.yaml as yaml devicetree > documentation for avia hx711 iio adc sensor > > Signed-off-by: Andreas Klinger > --- > .../devicetree/bindings/iio/adc/avia-hx711.txt | 24 > .../devicetree/bindings/iio/adc/avia-hx711.yaml| 66 > ++ > 2 files changed, 66 insertions(+), 24 deletions(-) > delete mode 100644 Documentation/devicetree/bindings/iio/adc/avia-hx711.txt > create mode 100644 Documentation/devicetree/bindings/iio/adc/avia-hx711.yaml Reviewed-by: Rob Herring
Re: [PATCH v2] bmp085.yaml: transform DT documentation of iio sensor into YAML
On Mon, Apr 1, 2019 at 12:32 PM Andreas Klinger wrote: > > use bmp085.txt and change it into yaml format > > fix links to datasheets in replaced documentation > > Signed-off-by: Andreas Klinger > --- > .../devicetree/bindings/iio/pressure/bmp085.txt| 27 - > .../devicetree/bindings/iio/pressure/bmp085.yaml | 70 > ++ > 2 files changed, 70 insertions(+), 27 deletions(-) > delete mode 100644 Documentation/devicetree/bindings/iio/pressure/bmp085.txt > create mode 100644 Documentation/devicetree/bindings/iio/pressure/bmp085.yaml Reviewed-by: Rob Herring
Re: [PATCH v4] HID: intel-ish-hid: ISH firmware loader client driver
On Sat, 2019-03-30 at 16:53 +0530, Rushikesh S Kadam wrote: > This driver adds support for loading Intel Integrated > Sensor Hub (ISH) firmware from host file system to ISH > SRAM and start execution. > > At power-on, the ISH subsystem shall boot to an interim > Shim loader-firmware, which shall expose an ISHTP loader > device. > > The driver implements an ISHTP client that communicates > with the Shim ISHTP loader device over the intel-ish-hid > stack, to download the main ISH firmware. > > Signed-off-by: Rushikesh S Kadam Rushikesh, You have one reviewed by and one Tested-by from Chrome developers. Please add those. Also you can also add Acked-by: Srinivas Pandruvada > --- > The patches are baselined to hid git tree, branch for-5.2/ish > https://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git/log/?h=for-5.2/ish > > v4 > - Changed process_recv() to wake the caller in case of >error as well. Earlier caller would wait until timeout on >an error. > - Change sequence of few checks in process_recv(). > > v3 > - Moved a couple of sanity checks from loader_cl_send() to >process_recv(). > - Several minor changes to address review comments. > > v2 > - Change loader_cl_send() so that the calling function >shall allocate and pass the buffer to be used for >receiving firwmare response data. Corresponding changes >in calling function and process_recv(). > - Introduced struct response_info to encapsulate and pass >data between from the process_recv() callback to >calling function loader_cl_send(). > - Keep count of host firmware load retries, and fail after >3 unsuccessful attempts. > - Dropped report_bad_packets() function previously used for >keeping count of bad packets. > - Inlined loader_ish_hw_reset()'s functionality > > v1 > - Initial version. > > drivers/hid/Makefile|1 + > drivers/hid/intel-ish-hid/Kconfig | 15 + > drivers/hid/intel-ish-hid/Makefile |3 + > drivers/hid/intel-ish-hid/ishtp-fw-loader.c | 1085 > +++ > 4 files changed, 1104 insertions(+) > create mode 100644 drivers/hid/intel-ish-hid/ishtp-fw-loader.c > > diff --git a/drivers/hid/Makefile b/drivers/hid/Makefile > index 170163b..d8d393e 100644 > --- a/drivers/hid/Makefile > +++ b/drivers/hid/Makefile > @@ -134,3 +134,4 @@ obj-$(CONFIG_USB_KBD) += usbhid/ > obj-$(CONFIG_I2C_HID)+= i2c-hid/ > > obj-$(CONFIG_INTEL_ISH_HID) += intel-ish-hid/ > +obj-$(INTEL_ISH_FIRMWARE_DOWNLOADER) += intel-ish-hid/ > diff --git a/drivers/hid/intel-ish-hid/Kconfig b/drivers/hid/intel- > ish-hid/Kconfig > index 519e4c8..786adbc 100644 > --- a/drivers/hid/intel-ish-hid/Kconfig > +++ b/drivers/hid/intel-ish-hid/Kconfig > @@ -14,4 +14,19 @@ config INTEL_ISH_HID > Broxton and Kaby Lake. > > Say Y here if you want to support Intel ISH. If unsure, say > N. > + > +config INTEL_ISH_FIRMWARE_DOWNLOADER > + tristate "Host Firmware Load feature for Intel ISH" > + depends on INTEL_ISH_HID > + depends on X86 > + help > + The Integrated Sensor Hub (ISH) enables the kernel to offload > + sensor polling and algorithm processing to a dedicated low > power > + processor in the chipset. > + > + The Host Firmware Load feature adds support to load the ISH > + firmware from host file system at boot. > + > + Say M here if you want to support Host Firmware Loading > feature > + for Intel ISH. If unsure, say N. > endmenu > diff --git a/drivers/hid/intel-ish-hid/Makefile b/drivers/hid/intel- > ish-hid/Makefile > index 825b70a..2de97e4 100644 > --- a/drivers/hid/intel-ish-hid/Makefile > +++ b/drivers/hid/intel-ish-hid/Makefile > @@ -20,4 +20,7 @@ obj-$(CONFIG_INTEL_ISH_HID) += intel-ishtp-hid.o > intel-ishtp-hid-objs := ishtp-hid.o > intel-ishtp-hid-objs += ishtp-hid-client.o > > +obj-$(CONFIG_INTEL_ISH_FIRMWARE_DOWNLOADER) += intel-ishtp-loader.o > +intel-ishtp-loader-objs += ishtp-fw-loader.o > + > ccflags-y += -Idrivers/hid/intel-ish-hid/ishtp > diff --git a/drivers/hid/intel-ish-hid/ishtp-fw-loader.c > b/drivers/hid/intel-ish-hid/ishtp-fw-loader.c > new file mode 100644 > index 000..e770e22 > --- /dev/null > +++ b/drivers/hid/intel-ish-hid/ishtp-fw-loader.c > @@ -0,0 +1,1085 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * ISH-TP client driver for ISH firmware loading > + * > + * Copyright (c) 2019, Intel Corporation. > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > + > +/* Number of times we attempt to load the firmware before giving up > */ > +#define MAX_LOAD_ATTEMPTS3 > + > +/* ISH TX/RX ring buffer pool size */ > +#define LOADER_CL_RX_RING_SIZE 1 > +#define LOADER_CL_TX_RING_SIZE 1 > + > +/* > + * ISH Shim firmware loader reserves 4 Kb buffer in SRAM. The buffer > is > + * used to temporarily hold the data
[PATCH] au0828: Fix NULL pointer dereference in au0828_analog_stream_enable()
Fix au0828_analog_stream_enable() to check if device is in the right
state first. When unbind happens while bind is in progress, usbdev
pointer could be invalid in au0828_analog_stream_enable() and a call
to usb_ifnum_to_if() will result in the null pointer dereference.
This problem is found with the new media_dev_allocator.sh test.
kernel: [ 590.359623] BUG: unable to handle kernel NULL pointer dereference at
04e8
kernel: [ 590.359627] #PF error: [normal kernel read fault]
kernel: [ 590.359629] PGD 0 P4D 0
kernel: [ 590.359632] Oops: [#1] SMP PTI
kernel: [ 590.359634] CPU: 3 PID: 1458 Comm: v4l_id Not tainted 5.1.0-rc2+ #30
kernel: [ 590.359636] Hardware name: Dell Inc. OptiPlex 7 90/0HY9JP, BIOS A18
09/24/2013
kernel: [ 590.359641] RIP: 0010:usb_ifnum_to_if+0x6/0x60
kernel: [ 590.359643] Code: 5d 41 5e 41 5f 5d c3 48 83 c4
10 b8 fa ff ff ff 5b 41 5c 41 5d 41 5e 41 5f 5d c3 b8 fa ff ff ff c3 0f 1f 00 6
6 66 66 66 90 55 <48> 8b 97 e8 04 00 00 48 89 e5 48 85 d2 74 41 0f b6 4a 04 84 c
9 74
kernel: [ 590.359645] RSP: 0018:ad3cc3c1fc00 EFLAGS: 00010246
kernel: [ 590.359646] RAX: RBX: 8ded b1f3c000 RCX:
1f377e45
kernel: [ 590.359648] RDX: 8dedfa3a6b50 RSI: RDI:
kernel: [ 590.359649] RBP: ad3cc3c1fc28 R08: 8574acc2 R09:
8dedfa3a6b50
kernel: [ 590.359650] R10: 0001 R11: R12:
kernel: [ 590.359652] R13: 8dedb1f3f0f0 R14: adcf7ec0 R15:
kernel: [ 590.359654] FS: 7f7917198540() GS: 8dee258c()
knlGS:
kernel: [ 590.359655] CS: 0010 DS: ES: CR0: 00 0080050033
kernel: [ 590.359657] CR2: 04e8 CR3: 0001 a388e002 CR4:
000606e0
kernel: [ 590.359658] Call Trace:
kernel: [ 590.359664] ? au0828_analog_stream_enable+0x2c/0x180
kernel: [ 590.359666] au0828_v4l2_open+0xa4/0x110
kernel: [ 590.359670] v4l2_open+0x8b/0x120
kernel: [ 590.359674] chrdev_open+0xa6/0x1c0
kernel: [ 590.359676] ? cdev_put.part.3+0x20/0x20
kernel: [ 590.359678] do_dentry_open+0x1f6/0x360
kernel: [ 590.359681] vfs_open+0x2f/0x40
kernel: [ 590.359684] path_openat+0x299/0xc20
kernel: [ 590.359688] do_filp_open+0x9b/0x110
kernel: [ 590.359695] ? _raw_spin_unlock+0x27/0x40
kernel: [ 590.359697] ? __alloc_fd+0xb2/0x160
kernel: [ 590.359700] do_sys_open+0x1ba/0x260
kernel: [ 590.359702] ? do_sys_open+0x1ba/0x260
kernel: [ 590.359712] __x64_sys_openat+0x20/0x30
kernel: [ 590.359715] do_syscall_64+0x5a/0x120
kernel: [ 590.359718] entry_SYSCALL_64_after_hwframe+0x44/0xa9
Signed-off-by: Shuah Khan
---
drivers/media/usb/au0828/au0828-video.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/media/usb/au0828/au0828-video.c
b/drivers/media/usb/au0828/au0828-video.c
index 7876c897cc1d..106a49da39f9 100644
--- a/drivers/media/usb/au0828/au0828-video.c
+++ b/drivers/media/usb/au0828/au0828-video.c
@@ -758,6 +758,9 @@ static int au0828_analog_stream_enable(struct au0828_dev *d)
dprintk(1, "au0828_analog_stream_enable called\n");
+ if (test_bit(DEV_DISCONNECTED, >dev_state))
+ return -ENODEV;
+
iface = usb_ifnum_to_if(d->usbdev, 0);
if (iface && iface->cur_altsetting->desc.bAlternateSetting != 5) {
dprintk(1, "Changing intf#0 to alt 5\n");
--
2.17.1
Re: [PATCH v4] HID: intel-ish-hid: ISH firmware loader client driver
On Mon, 2019-04-01 at 17:13 -0600, Nick Crews wrote: > Looks good to me! Thanks for the work! > So I assume, Rushikesh can add your Reviewed-by. Thanks, Srinivas > On Sat, Mar 30, 2019 at 5:23 AM Rushikesh S Kadam > wrote: > > > > This driver adds support for loading Intel Integrated > > Sensor Hub (ISH) firmware from host file system to ISH > > SRAM and start execution. > > > > At power-on, the ISH subsystem shall boot to an interim > > Shim loader-firmware, which shall expose an ISHTP loader > > device. > > > > The driver implements an ISHTP client that communicates > > with the Shim ISHTP loader device over the intel-ish-hid > > stack, to download the main ISH firmware. > > > > Signed-off-by: Rushikesh S Kadam > > --- > > The patches are baselined to hid git tree, branch for-5.2/ish > > https://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git/log/?h=for-5.2/ish > > > > v4 > > - Changed process_recv() to wake the caller in case of > >error as well. Earlier caller would wait until timeout on > >an error. > > - Change sequence of few checks in process_recv(). > > > > v3 > > - Moved a couple of sanity checks from loader_cl_send() to > >process_recv(). > > - Several minor changes to address review comments. > > > > v2 > > - Change loader_cl_send() so that the calling function > >shall allocate and pass the buffer to be used for > >receiving firwmare response data. Corresponding changes > >in calling function and process_recv(). > > - Introduced struct response_info to encapsulate and pass > >data between from the process_recv() callback to > >calling function loader_cl_send(). > > - Keep count of host firmware load retries, and fail after > >3 unsuccessful attempts. > > - Dropped report_bad_packets() function previously used for > >keeping count of bad packets. > > - Inlined loader_ish_hw_reset()'s functionality > > > > v1 > > - Initial version. > > > > drivers/hid/Makefile|1 + > > drivers/hid/intel-ish-hid/Kconfig | 15 + > > drivers/hid/intel-ish-hid/Makefile |3 + > > drivers/hid/intel-ish-hid/ishtp-fw-loader.c | 1085 > > +++ > > 4 files changed, 1104 insertions(+) > > create mode 100644 drivers/hid/intel-ish-hid/ishtp-fw-loader.c > > > > diff --git a/drivers/hid/Makefile b/drivers/hid/Makefile > > index 170163b..d8d393e 100644 > > --- a/drivers/hid/Makefile > > +++ b/drivers/hid/Makefile > > @@ -134,3 +134,4 @@ obj-$(CONFIG_USB_KBD) += usbhid/ > > obj-$(CONFIG_I2C_HID) += i2c-hid/ > > > > obj-$(CONFIG_INTEL_ISH_HID)+= intel-ish-hid/ > > +obj-$(INTEL_ISH_FIRMWARE_DOWNLOADER) += intel-ish-hid/ > > diff --git a/drivers/hid/intel-ish-hid/Kconfig b/drivers/hid/intel- > > ish-hid/Kconfig > > index 519e4c8..786adbc 100644 > > --- a/drivers/hid/intel-ish-hid/Kconfig > > +++ b/drivers/hid/intel-ish-hid/Kconfig > > @@ -14,4 +14,19 @@ config INTEL_ISH_HID > > Broxton and Kaby Lake. > > > > Say Y here if you want to support Intel ISH. If unsure, > > say N. > > + > > +config INTEL_ISH_FIRMWARE_DOWNLOADER > > + tristate "Host Firmware Load feature for Intel ISH" > > + depends on INTEL_ISH_HID > > + depends on X86 > > + help > > + The Integrated Sensor Hub (ISH) enables the kernel to > > offload > > + sensor polling and algorithm processing to a dedicated > > low power > > + processor in the chipset. > > + > > + The Host Firmware Load feature adds support to load the > > ISH > > + firmware from host file system at boot. > > + > > + Say M here if you want to support Host Firmware Loading > > feature > > + for Intel ISH. If unsure, say N. > > endmenu > > diff --git a/drivers/hid/intel-ish-hid/Makefile > > b/drivers/hid/intel-ish-hid/Makefile > > index 825b70a..2de97e4 100644 > > --- a/drivers/hid/intel-ish-hid/Makefile > > +++ b/drivers/hid/intel-ish-hid/Makefile > > @@ -20,4 +20,7 @@ obj-$(CONFIG_INTEL_ISH_HID) += intel-ishtp-hid.o > > intel-ishtp-hid-objs := ishtp-hid.o > > intel-ishtp-hid-objs += ishtp-hid-client.o > > > > +obj-$(CONFIG_INTEL_ISH_FIRMWARE_DOWNLOADER) += intel-ishtp- > > loader.o > > +intel-ishtp-loader-objs += ishtp-fw-loader.o > > + > > ccflags-y += -Idrivers/hid/intel-ish-hid/ishtp > > diff --git a/drivers/hid/intel-ish-hid/ishtp-fw-loader.c > > b/drivers/hid/intel-ish-hid/ishtp-fw-loader.c > > new file mode 100644 > > index 000..e770e22 > > --- /dev/null > > +++ b/drivers/hid/intel-ish-hid/ishtp-fw-loader.c > > @@ -0,0 +1,1085 @@ > > +// SPDX-License-Identifier: GPL-2.0 > > +/* > > + * ISH-TP client driver for ISH firmware loading > > + * > > + * Copyright (c) 2019, Intel Corporation. > > + */ > > + > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > + > > +/* Number of times we attempt to load the firmware before giving > > up */ > > +#define MAX_LOAD_ATTEMPTS
Re: [rcu:dev.2019.03.20b 54/83] drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_process.c:50:1: error: type defaults to 'int' in declaration of 'DEFINE_SRCU'
On 3/28/19 3:57 AM, Paul E. McKenney wrote:
On Mon, Mar 25, 2019 at 02:34:27AM +0800, kbuild test robot wrote:
tree: https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
dev.2019.03.20b
head: 6d4434b4b4df791620743178e1419de882b44c7b
commit: eb89abcb30733e3a2343dda23cb6d81cc17c60b3 [54/83] rcu: Forbid
DEFINE{,_STATIC}_SRCU() from modules
config: x86_64-randconfig-b0-03250021 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
git checkout eb89abcb30733e3a2343dda23cb6d81cc17c60b3
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_process.c:50:1: warning: data
definition has no type or storage class
DEFINE_SRCU(kfd_processes_srcu);
^~~
drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_process.c:50:1: error: type defaults
to 'int' in declaration of 'DEFINE_SRCU' [-Werror=implicit-int]
drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_process.c:50:1: warning: parameter
names (without types) in function declaration
cc1: some warnings being treated as errors
I don't have that hardware, but does the following help? (It at least
builds for me, but your mileage may vary.)
Thanx, Paul
Yes, the patch works for kbuild robot.
Thanks,
Rong Chen
commit b30be5a76070402912437fa23b43de11cb1973f4
Author: Paul E. McKenney
Date: Wed Mar 27 12:53:36 2019 -0700
drivers/gpu/drm/amd: Dynamically allocate kfd_processes_srcu
Having DEFINE_SRCU() or DEFINE_STATIC_SRCU() in a loadable module
requires that the size of the reserved region be increased, which is
not something we really want to be doing. This commit therefore removes
the DEFINE_STATIC_SRCU() from drivers/gpu/drm/amd/amdkfd/kfd_process.c in
favor of defining kfd_processes_srcu as a simple srcu_struct, initializing
it in amdgpu_amdkfd_init(), and cleaning it up in amdgpu_amdkfd_fini().
Reported-by: kbuild test robot
Signed-off-by: Paul E. McKenney
Cc: Oded Gabbay
Cc: Alex Deucher
Cc: "Christian König"
Cc: David Airlie
Cc: Daniel Vetter
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
index fe1d7368c1e6..eadb20dee867 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
@@ -28,6 +28,8 @@
#include
#include
+extern struct srcu_struct kfd_processes_srcu;
+
static const unsigned int compute_vmid_bitmap = 0xFF00;
/* Total memory size in system memory and all GPU VRAM. Used to
@@ -40,6 +42,8 @@ int amdgpu_amdkfd_init(void)
struct sysinfo si;
int ret;
+ ret = init_srcu_struct(_processes_srcu);
+ WARN_ON(ret);
si_meminfo();
amdgpu_amdkfd_total_mem_size = si.totalram - si.totalhigh;
amdgpu_amdkfd_total_mem_size *= si.mem_unit;
@@ -57,6 +61,7 @@ int amdgpu_amdkfd_init(void)
void amdgpu_amdkfd_fini(void)
{
kgd2kfd_exit();
+ cleanup_srcu_struct(_processes_srcu);
}
void amdgpu_amdkfd_device_probe(struct amdgpu_device *adev)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
index 4bdae78bab8e..98b694068b8a 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
@@ -47,7 +47,7 @@ struct mm_struct;
DEFINE_HASHTABLE(kfd_processes_table, KFD_PROCESS_TABLE_SIZE);
static DEFINE_MUTEX(kfd_processes_mutex);
-DEFINE_SRCU(kfd_processes_srcu);
+struct srcu_struct kfd_processes_srcu;
/* For process termination handling */
static struct workqueue_struct *kfd_process_wq;
Re: [PATCH v5 00/11] tracing: common error_log for ftrace
On Mon, 01 Apr 2019 08:31:08 -0500 Tom Zanussi wrote: > > > BTW, could you also add a testcase which tests all (or most of) > > error cases of hist_err() ? > > That will be good to find regressions in future changes. > > > > I was going to, but there are a lot of error cases and a lot of them > aren't simple one-liners and require some more involved setup to > trigger. I'll submit a follow-on patch to add them as soon as I get > the chance. Agreed, I look forward your testcase :) Thank you, -- Masami Hiramatsu
Re: [RFCv2] string: Use faster alternatives when constant arguments are used
On Mon, Apr 01, 2019 at 10:43:13PM +0200, Rasmus Villemoes wrote: > Consider your patch replacing !strcmp(buf, "123") by !memcmp(buf, "123", > 4). buf is known to point to a nul-terminated string. But it may point > at, say, the second-last byte in a page, with the last byte in that page > being a nul byte, and the following page being MMIO or unmapped or all > kinds of bad things. On e.g. x86 where unaligned accesses are cheap, and > seeing that you're only comparing for equality, gcc is likely to compile > the memcmp version into > > *(u32*)buf == 0x00333231 > > because you've told the compiler that there's no problem accessing four > bytes starting at buf. Boom. Even without unaligned access being cheap > this can happen; suppose the length is 8 instead, and gcc somehow knows > that buf is four-byte aligned (and in this case it happens to point four > bytes before a page boundary), so it could compile the memcmp(,,8) into > > *(u32*)(buf+4) == secondword && *(u32*)buf == firstword > > (or do the comparisons in the "natural" order, but it might still do > both loads first). Ok, this is the first solid counter I've seen against my patch. I hadn't considered unaligned word-sized accesses. Thanks. > > And if there are concerns for some arches but not others, then couldn't > > this be > > a feasible optimization for those which would work well with it? > > No. First, these are concerns for all arches. Second, if you can find > some particular place where string parsing/matching is in any way > performance relevant and not just done once during driver init or > whatnot, maybe the maintainers of that file would take a patch > hand-optimizing some strcmps to memcmps, or, depending on what the code > does, perhaps replacing the whole *cmp logic with a custom hash table. FWIW, I didn't have a specific place in the kernel in mind that heavily relied on str* operations and needed optimization. I just thought it could be a "free" optimization, but apparently not. > But a patch implicitly and silently touching thousands of lines of code, > without an analysis of why none of the above is a problem for any of > those lines, for any .config, arch, compiler version? No. Well, I thought it could be proven to be correct regardless of the context, which would imply that making such a global change touching thousands lof lines of code would be safe. But sadly it isn't. This does bring into question a greater problem though: usage of memcmp throughout the kernel where the size provided is not the size of the smaller container being compared. This usage of memcmp (which is quite easy to find all across the kernel) could run into the unaligned memory access across a page boundary that you gave as an example, no? Sultan
Re: [PATCH v3] tpm: Actually fail on TPM errors during "get random"
On Mon, Apr 01, 2019 at 12:06:07PM -0700, Kees Cook wrote:
> A "get random" may fail with a TPM error, but those codes were returned
> as-is to the caller, which assumed the result was the number of bytes
> that had been written to the target buffer, which could lead to a kernel
> heap memory exposure and over-read.
>
> This fixes tpm1_get_random() to mask positive TPM errors into -EIO, as
> before.
>
> [ 18.092103] tpm tpm0: A TPM error (379) occurred attempting get random
> [ 18.092106] usercopy: Kernel memory exposure attempt detected from SLUB
> object 'kmalloc-64' (offset 0, size 379)!
>
> Link: https://bugzilla.redhat.com/show_bug.cgi?id=1650989
> Reported-by: Phil Baker
> Reported-by: Craig Robson
> Fixes: 7aee9c52d7ac ("tpm: tpm1: rewrite tpm1_get_random() using tpm_buf
> structure")
> Cc: Laura Abbott
> Cc: Tomas Winkler
> Cc: Jarkko Sakkinen
> Cc: sta...@vger.kernel.org
> Signed-off-by: Kees Cook
> ---
> v3: fix never-succeed, limit checks to tpm cmd return (James, Jason)
> v2: also fix tpm2 implementation (Jason Gunthorpe)
> ---
> drivers/char/tpm/tpm1-cmd.c | 7 +--
> drivers/char/tpm/tpm2-cmd.c | 7 +--
> 2 files changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/char/tpm/tpm1-cmd.c b/drivers/char/tpm/tpm1-cmd.c
> index 85dcf2654d11..faacbe1ffa1a 100644
> --- a/drivers/char/tpm/tpm1-cmd.c
> +++ b/drivers/char/tpm/tpm1-cmd.c
> @@ -510,7 +510,7 @@ struct tpm1_get_random_out {
> *
> * Return:
> * * number of bytes read
> - * * -errno or a TPM return code otherwise
> + * * -errno (positive TPM return codes are masked to -EIO)
> */
> int tpm1_get_random(struct tpm_chip *chip, u8 *dest, size_t max)
> {
> @@ -531,8 +531,11 @@ int tpm1_get_random(struct tpm_chip *chip, u8 *dest,
> size_t max)
>
> rc = tpm_transmit_cmd(chip, , sizeof(out->rng_data_len),
> "attempting get random");
> - if (rc)
> + if (rc) {
> + if (rc > 0)
> + rc = -EIO;
> goto out;
> + }
>
> out = (struct tpm1_get_random_out *)[TPM_HEADER_SIZE];
>
> diff --git a/drivers/char/tpm/tpm2-cmd.c b/drivers/char/tpm/tpm2-cmd.c
> index e74c5b7b64bf..8ffa6af61580 100644
> --- a/drivers/char/tpm/tpm2-cmd.c
> +++ b/drivers/char/tpm/tpm2-cmd.c
> @@ -301,7 +301,7 @@ struct tpm2_get_random_out {
> *
> * Return:
> * size of the buffer on success,
> - * -errno otherwise
> + * -errno otherwise ((positive TPM return codes are masked to -EIO)
> */
> int tpm2_get_random(struct tpm_chip *chip, u8 *dest, size_t max)
> {
> @@ -328,8 +328,11 @@ int tpm2_get_random(struct tpm_chip *chip, u8 *dest,
> size_t max)
> offsetof(struct tpm2_get_random_out,
> buffer),
> "attempting get random");
> - if (err)
> + if (err) {
> + if (err > 0)
> + err = -EIO;
> goto out;
> + }
>
> out = (struct tpm2_get_random_out *)
> [TPM_HEADER_SIZE];
> --
> 2.17.1
>
>
> --
> Kees Cook
Reviewed-by: Jarkko Sakkinen
/Jarkko
Re: linux-next: build failure after merge of the nand tree
Hi Stephen,
Le mar. 2 avril 2019 à 1:14, Stephen Rothwell a
écrit :
Hi all,
After merging the nand tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/mtd/nand/raw/ingenic/ingenic_ecc.c:26:5: error: redefinition
of 'ingenic_ecc_calculate'
int ingenic_ecc_calculate(struct ingenic_ecc *ecc,
^
In file included from drivers/mtd/nand/raw/ingenic/ingenic_ecc.c:14:
drivers/mtd/nand/raw/ingenic/ingenic_ecc.h:39:5: note: previous
definition of 'ingenic_ecc_calculate' was here
int ingenic_ecc_calculate(struct ingenic_ecc *ecc,
^
drivers/mtd/nand/raw/ingenic/ingenic_ecc.c:47:5: error: redefinition
of 'ingenic_ecc_correct'
int ingenic_ecc_correct(struct ingenic_ecc *ecc,
^~~
In file included from drivers/mtd/nand/raw/ingenic/ingenic_ecc.c:14:
drivers/mtd/nand/raw/ingenic/ingenic_ecc.h:46:5: note: previous
definition of 'ingenic_ecc_correct' was here
int ingenic_ecc_correct(struct ingenic_ecc *ecc,
^~~
drivers/mtd/nand/raw/ingenic/ingenic_ecc.c:93:21: error: redefinition
of 'of_ingenic_ecc_get'
struct ingenic_ecc *of_ingenic_ecc_get(struct device_node *of_node)
^~
In file included from drivers/mtd/nand/raw/ingenic/ingenic_ecc.c:14:
drivers/mtd/nand/raw/ingenic/ingenic_ecc.h:57:21: note: previous
definition of 'of_ingenic_ecc_get' was here
struct ingenic_ecc *of_ingenic_ecc_get(struct device_node *np)
^~
drivers/mtd/nand/raw/ingenic/ingenic_ecc.c:119:6: error: redefinition
of 'ingenic_ecc_release'
void ingenic_ecc_release(struct ingenic_ecc *ecc)
^~~
In file included from drivers/mtd/nand/raw/ingenic/ingenic_ecc.c:14:
drivers/mtd/nand/raw/ingenic/ingenic_ecc.h:53:6: note: previous
definition of 'ingenic_ecc_release' was here
void ingenic_ecc_release(struct ingenic_ecc *ecc)
^~~
Caused by commit
8278ad0d709a ("mtd: rawnand: ingenic: Separate top-level and SoC
specific code")
I have used the nand tree from next-20190401 for today.
That makes no sense to me; from the offsets of the errors in the
ingenic_ecc.h
file, it seems that CONFIG_MTD_NAND_INGENIC_ECC is not set, and in this
case
ingenic_ecc.c should not be compiled at all.
-Paul
