[PATCH v2 0/1] ARM: dts: mmp2-olpc-xo-1-75: clear the warnings when make dtbs
v1 --> v2:
Update the patch description and subject.
I'm going to describe the detailed analysis here, because I don't want the
patch description to be too long.
0) make ARCH=arm CROSS_COMPILE=arm-linux-gnu- dtbs -j24 2>err.txt
vim err.txt
arch/arm/boot/dts/mmp2.dtsi:472.23-480.6: Warning (spi_bus_bridge):
/soc/apb@d400/spi@d4037000: incorrect #address-cells for SPI bus
also defined at arch/arm/boot/dts/mmp2-olpc-xo-1-75.dts:225.7-237.3
arch/arm/boot/dts/mmp2.dtsi:472.23-480.6: Warning (spi_bus_bridge):
/soc/apb@d400/spi@d4037000: incorrect #size-cells for SPI bus
also defined at arch/arm/boot/dts/mmp2-olpc-xo-1-75.dts:225.7-237.3
arch/arm/boot/dts/mmp2-olpc-xo-1-75.dtb: Warning (spi_bus_reg): Failed
prerequisite 'spi_bus_bridge'
1) mmp2.dtsi is included by mmp2-olpc-xo-1-75.dts, and the content of ssp3
node is:
arch/arm/boot/dts/mmp2.dtsi:472
ssp3: spi@d4037000 {
compatible = "marvell,mmp2-ssp";
reg = <0xd4037000 0x1000>;
clocks = <&soc_clocks MMP2_CLK_SSP2>;
interrupts = <20>;
#address-cells = <1>;
#size-cells = <0>;< #size-cells = <0>
status = "disabled";
};
arch/arm/boot/dts/mmp2-olpc-xo-1-75.dts:225
&ssp3 {
/delete-property/ #address-cells; < #address-cells is
deleted here
/delete-property/ #size-cells;< #size-cells is
deleted here
spi-slave;
status = "okay";
ready-gpios = <&gpio 125 GPIO_ACTIVE_HIGH>;
slave {
compatible = "olpc,xo1.75-ec";
spi-cpha;
cmd-gpios = <&gpio 155 GPIO_ACTIVE_HIGH>;
};
};
2) scripts/dtc/checks.c: check_spi_bus_bridge() requires that the values of both
#address-cells and #size-cells must be zero, when the node have "spi-slave"
property.
if (get_property(node, "spi-slave"))
spi_addr_cells = 0;
if (node_addr_cells(node) != spi_addr_cells)
FAIL(c, dti, node, "incorrect #address-cells for SPI bus");
if (node_size_cells(node) != 0)
FAIL(c, dti, node, "incorrect #size-cells for SPI bus");
3) But both #address-cells and #size-cells properties are deleted. So the
return value
of node_addr_cells(node) is 2, and the return value of node_size_cells(node) is
1.
#define node_addr_cells(n) \
(((n)->addr_cells == -1) ? 2 : (n)->addr_cells)
#define node_size_cells(n) \
(((n)->size_cells == -1) ? 1 : (n)->size_cells)
4) The checks in 2) failed, so the above 0) warnings is displayed.
v1:
Patch 5/6.
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg2341407.html
Zhen Lei (1):
ARM: dts: mmp2-olpc-xo-1-75: clear the warnings when make dtbs
arch/arm/boot/dts/mmp2-olpc-xo-1-75.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--
1.8.3
Re: [PATCH v2 0/9] Add support for Microsoft Surface System Aggregator Module
Hi,
On 12/6/20 4:58 PM, Maximilian Luz wrote:
> On 12/6/20 8:07 AM, Leon Romanovsky wrote:
>> On Thu, Dec 03, 2020 at 10:26:31PM +0100, Maximilian Luz wrote:
>>> Hello,
>>>
>>> Here is version two of the Surface System Aggregator Module (SAM/SSAM)
>>> driver series, adding initial support for the embedded controller on 5th
>>> and later generation Microsoft Surface devices. Initial support includes
>>> the ACPI interface to the controller, via which battery and thermal
>>> information is provided on some of these devices.
>>>
>>> The previous version and cover letter detailing what this series is
>>> about can be found at
>>>
>>>
>>> https://lore.kernel.org/platform-driver-x86/20201115192143.21571-1-luzmaximil...@gmail.com/
>>>
>>> This patch-set can also be found at the following repository and
>>> reference, if you prefer to look at a kernel tree instead of these
>>> emails:
>>>
>>> https://github.com/linux-surface/kernel tags/s/surface-aggregator/v2
>>>
>>> Thank you all for the feedback to v1, I hope I have addressed all
>>> comments.
>>
>>
>> I think that it is too far fetched to attempt and expose UAPI headers
>> for some obscure char device that we are all know won't be around in
>> a couple of years from now due to the nature of how this embedded world
>> works.
>>
>> More on that, the whole purpose of proposed interface is to debug and
>> not intended to be used by any user space code.
>
> I believe this has already been extensively discussed. I want to focus
> more on the part below in this response:
>
>> Also the idea that you are creating new bus just for this device doesn't
>> really sound right. I recommend you to take a look on auxiliary bus and
>> use it or come with very strong justifications why it is not fit yet.
>
> I tend to agree that this is a valid concern to bring up, and adding a
> new bus is not something that should be done lightly.
>
> Let's ignore that this has been merged into -next after I've submitted
> this (and that I only recently became aware of this) for the time being.
> If I would see a clear benefit, I would not hesitate to switch the
> driver and subsystem over to this.
>
> What does concern me most, is the device/driver matching by string.
> Right now, this subsystem matches those via a device UID. This UID is
> directly tied to the EC functionality provided by the device. A bit of
> background to this:
>
> Requests sent to the EC contain an address, so to say. This consists of
>
> - Target category (TC): Broad group of functionality, e.g. battery/AC,
> thermal, HID input, ..., i.e. a subsystem of sorts.
>
> - Target ID (TID): Some major device, e.g. the dual batteries on the
> Surface Book 3 are addressed by target ID 1 and 2, some functionality
> is only available at 2 and some only at 1. May be related to physical
> parts of/locations on the device.
>
> - Instance ID (IID): A device instance, e.g. for thermal sensors each
> sensor is at TC=0x03 (thermal) and has a different instance ID.
>
> Those can be used to pretty much uniquely identify a sub-device on the
> EC.
Thank you for this explanation, that is going to be useful to know
when I get around to reviewing this set (although I guess that you
probably also have written this down in one of the commit msgs /
docs I did not check).
>
> Note the "pretty much". To truly make them unique we can add a function
> ID (FN). With that, we can for example match for TC=0x03, TID=*, IID=*,
> FN=0x00 to load a driver against all thermal sensors. And this is
> basically the device UID that the subsystem uses for matching (modulo
> domain for virtual devices, i.e. device hubs). Sure, we can use some
> string, but that then leads to having to come up with creative names
> once we need some driver specific data, e.g. in the battery driver [1]:
>
> const struct auxiliary_device_id my_auxiliary_id_table[] = {
> { .name = "surface_aggregator_registry.battery", .driver_data = x },
> { .name = "surface_aggregator_registry.battery_sb3", .driver_data = y
> },
> { },
> }
>
> Arguably, not _that_ big of a deal.
>
> What worries me more is that this will block any path of auto-detecting
> devices on a more general/global level. Right now, we hard-code devices
> because we haven't found any way to detect them via some EC query yet
> [2] (FYI the node groups contain all devices that will eventually be
> added to the bus, which are already 11 devices on the Surface Book 3
> without taking missing thermal sensors into account; also they are
> spread across a bunch of subsystems, so not just platform). That's of
> course not an ideal solution and one that I hope we can eventually fix.
> If we can auto-detect devices, it's very likely that we know or can
> easily get to the device UID. A meaningful string is somewhat more
> difficult.
>
> This registry, which is loaded against a platform device that, from what
> we can tell differentiates the models for some driver
[PATCH 2/2] Input: elantech - Some module tp of tracpoint report has a smbus protocol error.
1. Add the conditional expression to distinguish different patterns regarding
0, 1, 2.
2. Add the function to get or set more bytes from register
3. Get and correct the device informations including ic_type, module id from
different pattern.
4. Add the function to change the report id 0x5F of trackpoint.
5. Some module has a bug which makes default SMBUS trackpoint report 0x5E has a
smbus protocol error.
---
drivers/input/mouse/elantech.c | 128 -
drivers/input/mouse/elantech.h | 4 ++
2 files changed, 131 insertions(+), 1 deletion(-)
diff --git a/drivers/input/mouse/elantech.c b/drivers/input/mouse/elantech.c
index 90f8765f9efc..b3240775ceca 100644
--- a/drivers/input/mouse/elantech.c
+++ b/drivers/input/mouse/elantech.c
@@ -89,6 +89,57 @@ static int elantech_ps2_command(struct psmouse *psmouse,
return rc;
}
+/*
+ * Send an Elantech style special command to read 3 bytes from a register
+ */
+static int elantech_read_reg_params(struct psmouse *psmouse, unsigned char reg,
+unsigned char *param)
+{
+ int rc = 0;
+
+ if (elantech_ps2_command(psmouse, NULL, ETP_PS2_CUSTOM_COMMAND) ||
+ elantech_ps2_command(psmouse, NULL, ETP_REGISTER_READWRITE) ||
+ elantech_ps2_command(psmouse, NULL, ETP_PS2_CUSTOM_COMMAND) ||
+ elantech_ps2_command(psmouse, NULL, reg) ||
+ elantech_ps2_command(psmouse, param, PSMOUSE_CMD_GETINFO)) {
+ rc = -1;
+ }
+
+ if (rc)
+ psmouse_err(psmouse,
+ "failed to read register 0x%02x.\n", reg);
+ return rc;
+}
+
+/*
+ * Send an Elantech style special command to write a register with a parameter
+ */
+static int elantech_write_reg_params(struct psmouse *psmouse, unsigned char
reg,
+ unsigned char *param)
+{
+
+ int rc = 0;
+
+ if (elantech_ps2_command(psmouse, NULL, ETP_PS2_CUSTOM_COMMAND) ||
+ elantech_ps2_command(psmouse, NULL, ETP_REGISTER_READWRITE)
||
+ elantech_ps2_command(psmouse, NULL, ETP_PS2_CUSTOM_COMMAND)
||
+ elantech_ps2_command(psmouse, NULL, reg) ||
+ elantech_ps2_command(psmouse, NULL, ETP_PS2_CUSTOM_COMMAND)
||
+ elantech_ps2_command(psmouse, NULL, param[0]) ||
+ elantech_ps2_command(psmouse, NULL, ETP_PS2_CUSTOM_COMMAND)
||
+ elantech_ps2_command(psmouse, NULL, param[1]) ||
+ elantech_ps2_command(psmouse, NULL,
PSMOUSE_CMD_SETSCALE11)) {
+ rc = -1;
+ }
+
+ if (rc)
+ psmouse_err(psmouse,
+ "failed to write register 0x%02x with value
0x%02x0x%02x.\n",
+ reg, param[0], param[1]);
+ return rc;
+
+}
+
/*
* Send an Elantech style special command to read a value from a register
*/
@@ -1529,6 +1580,27 @@ static const struct dmi_system_id no_hw_res_dmi_table[]
= {
{ }
};
+/*
+ * Change Report id 0x5E to 0x5F.
+ */
+static int elantech_change_report_id(struct psmouse *psmouse)
+{
+ unsigned char param[2] = { 0x10, 0x03 };
+
+ if (elantech_write_reg_params(psmouse, 0x7, param) == 0) {
+ if (elantech_read_reg_params(psmouse, 0x7, param) == 0) {
+ if ((param[0] == 0x10) && (param[1] == 0x03)) {
+ return 0;
+ }
+ psmouse_err(psmouse,
+ "Elantech change report id Fail. (0x%02x, 0x%02x)\n",
+ param[0], param[1]);
+ }
+ }
+ psmouse_err(psmouse,
+ "Elantech change report id Fail.\n");
+ return -1;
+}
/*
* determine hardware version and set some properties according to it.
*/
@@ -1556,6 +1628,18 @@ static int elantech_set_properties(struct
elantech_device_info *info)
return -1;
}
}
+
+
+ /* Get information pattern for hw_version 4 */
+ if (ver == 15) {
+ if ((info->fw_version & 0xff) == 0x01)
+ info->pattern = 0x01;
+ else if ((info->fw_version & 0xff) == 0x02)
+ info->pattern = 0x02;
+ else
+ info->pattern = 0x00;
+ } else
+ info->pattern = 0x00;
/* decide which send_cmd we're gonna use early */
info->send_cmd = info->hw_version >= 3 ? elantech_send_cmd :
@@ -1598,7 +1682,8 @@ static int elantech_query_info(struct psmouse *psmouse,
{
unsigned char param[3];
unsigned char traces;
-
+ unsigned char ic_body[3];
+
memset(info, 0, sizeof(*info));
/*
@@ -1628,6 +1713,21 @@ static int elantech_query_info(struct p
[PATCH 1/2] Input: elan_i2c - Add new trackpoint report type 0x5F.
The 0x5F is new trackpoint report type of some module.
Signed-off-by: Jingle Wu
---
drivers/input/mouse/elan_i2c_core.c | 2 ++
drivers/input/mouse/elan_i2c_smbus.c | 3 ++-
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/input/mouse/elan_i2c_core.c
b/drivers/input/mouse/elan_i2c_core.c
index 61ed3f5ca219..8f0c4663167c 100644
--- a/drivers/input/mouse/elan_i2c_core.c
+++ b/drivers/input/mouse/elan_i2c_core.c
@@ -52,6 +52,7 @@
#define ETP_REPORT_ID 0x5D
#define ETP_REPORT_ID2 0x60/* High precision report */
#define ETP_TP_REPORT_ID 0x5E
+#define ETP_TP_REPORT_ID2 0x5F
#define ETP_REPORT_ID_OFFSET 2
#define ETP_TOUCH_INFO_OFFSET 3
#define ETP_FINGER_DATA_OFFSET 4
@@ -1076,6 +1077,7 @@ static irqreturn_t elan_isr(int irq, void *dev_id)
elan_report_absolute(data, report, true);
break;
case ETP_TP_REPORT_ID:
+ case ETP_TP_REPORT_ID2:
elan_report_trackpoint(data, report);
break;
default:
diff --git a/drivers/input/mouse/elan_i2c_smbus.c
b/drivers/input/mouse/elan_i2c_smbus.c
index 1820f1cfc1dc..1226d47ec3cf 100644
--- a/drivers/input/mouse/elan_i2c_smbus.c
+++ b/drivers/input/mouse/elan_i2c_smbus.c
@@ -45,6 +45,7 @@
#define ETP_SMBUS_CALIBRATE_QUERY 0xC5
#define ETP_SMBUS_REPORT_LEN 32
+#define ETP_SMBUS_REPORT_LEN2 7
#define ETP_SMBUS_REPORT_OFFSET2
#define ETP_SMBUS_HELLOPACKET_LEN 5
#define ETP_SMBUS_IAP_PASSWORD 0x1234
@@ -497,7 +498,7 @@ static int elan_smbus_get_report(struct i2c_client *client,
return len;
}
- if (len != ETP_SMBUS_REPORT_LEN) {
+ if ((len != ETP_SMBUS_REPORT_LEN) && (len != ETP_SMBUS_REPORT_LEN2)) {
dev_err(&client->dev,
"wrong report length (%d vs %d expected)\n",
len, ETP_SMBUS_REPORT_LEN);
--
2.17.1
[PATCH v3] phram: Allow the user to set the erase page size.
From: Patrick O'Grady
Permit the user to specify the erase page size as a parameter.
This solves two problems:
- phram can access images made by mkfs.jffs2. mkfs.jffs2 won't
create images with erase sizes less than 8KiB; many architectures
define PAGE_SIZE as 4KiB.
- Allows more effective use of small capacity devices. JFFS2
needs somewhere between 2 and 5 empty pages for garbage collection;
and for an NVRAM part with only 32KiB of space, a smaller erase page
allows much better utilization in applications where garbage collection
is important.
Signed-off-by: Patrick O'Grady
Reviewed-by: Joern Engel
Link:
https://lore.kernel.org/lkml/CAJ7m5OqYv_=JB9NhHsqBsa8YU0DFRoP7C+W10PY22wonAGJK=a...@mail.gmail.com/
[Guohua Zhong: fix token array index out of bounds and update patch for kernel
master branch]
Signed-off-by: Guohua Zhong
v3:
update authorship for Patrick O'Grady and remove the reported-by tag for
kernel test robot
v2: https://lore.kernel.org/lkml/20201204080821.46868-1-zhongguoh...@huawei.com/
fix build error which is reported by kernel test robot
v1: https://lore.kernel.org/lkml/20201124061053.10812-1-zhongguoh...@huawei.com/
1.fix token array index out of bounds
2.update patch for kernel master branch
---
drivers/mtd/devices/phram.c | 52 +
1 file changed, 34 insertions(+), 18 deletions(-)
diff --git a/drivers/mtd/devices/phram.c b/drivers/mtd/devices/phram.c
index 087b5e86d1bf..1729b94b2abf 100644
--- a/drivers/mtd/devices/phram.c
+++ b/drivers/mtd/devices/phram.c
@@ -6,14 +6,14 @@
* Usage:
*
* one commend line parameter per device, each in the form:
- * phram=,,
+ * phram=,,[,]
* may be up to 63 characters.
- * and can be octal, decimal or hexadecimal. If followed
+ * , , and can be octal, decimal or hexadecimal. If
followed
* by "ki", "Mi" or "Gi", the numbers will be interpreted as kilo, mega or
- * gigabytes.
+ * gigabytes. is optional and defaults to PAGE_SIZE.
*
* Example:
- * phram=swap,64Mi,128Mi phram=test,900Mi,1Mi
+ * phram=swap,64Mi,128Mi phram=test,900Mi,1Mi,64Ki
*/
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
struct phram_mtd_list {
struct mtd_info mtd;
@@ -88,7 +89,7 @@ static void unregister_devices(void)
}
}
-static int register_device(char *name, phys_addr_t start, size_t len)
+static int register_device(char *name, phys_addr_t start, size_t len, uint32_t
erasesize)
{
struct phram_mtd_list *new;
int ret = -ENOMEM;
@@ -115,7 +116,7 @@ static int register_device(char *name, phys_addr_t start,
size_t len)
new->mtd._write = phram_write;
new->mtd.owner = THIS_MODULE;
new->mtd.type = MTD_RAM;
- new->mtd.erasesize = PAGE_SIZE;
+ new->mtd.erasesize = erasesize;
new->mtd.writesize = 1;
ret = -EAGAIN;
@@ -204,22 +205,23 @@ static inline void kill_final_newline(char *str)
static int phram_init_called;
/*
* This shall contain the module parameter if any. It is of the form:
- * - phram=,, for module case
- * - phram.phram=,, for built-in case
- * We leave 64 bytes for the device name, 20 for the address and 20 for the
- * size.
- * Example: phram.phram=rootfs,0xa000,512Mi
+ * - phram=,,[,] for module case
+ * - phram.phram=,,[,] for built-in case
+ * We leave 64 bytes for the device name, 20 for the address , 20 for the
+ * size and 20 for the erasesize.
+ * Example: phram.phram=rootfs,0xa000,512Mi,65536
*/
-static char phram_paramline[64 + 20 + 20];
+static char phram_paramline[64 + 20 + 20 + 20];
#endif
static int phram_setup(const char *val)
{
- char buf[64 + 20 + 20], *str = buf;
- char *token[3];
+ char buf[64 + 20 + 20 + 20], *str = buf;
+ char *token[4];
char *name;
uint64_t start;
uint64_t len;
+ uint64_t erasesize = PAGE_SIZE;
int i, ret;
if (strnlen(val, sizeof(buf)) >= sizeof(buf))
@@ -228,7 +230,7 @@ static int phram_setup(const char *val)
strcpy(str, val);
kill_final_newline(str);
- for (i = 0; i < 3; i++)
+ for (i = 0; i < 4; i++)
token[i] = strsep(&str, ",");
if (str)
@@ -253,11 +255,25 @@ static int phram_setup(const char *val)
goto error;
}
- ret = register_device(name, start, len);
+ if (token[3]) {
+ ret = parse_num64(&erasesize, token[3]);
+ if (ret) {
+ parse_err("illegal erasesize\n");
+ goto error;
+ }
+ }
+
+ if (len == 0 || erasesize == 0 || erasesize > len
+ || erasesize > UINT_MAX || do_div(len, (uint32_t)erasesize) != 0) {
+ parse_err("illegal erasesize or len\n");
+ goto error;
+ }
+
+ ret = register_device(name, start, len, (uint32_t)erasesize);
if (ret)
goto er
[PATCH] docs: nios2: add missing ReST file
changeset ed13a92d0fde ("docs: archis: add a per-architecture features list")
besides having a typo on its title, it was missing the feature file.
Add it.
Reported-by: Stephen Rothwell
Fixes: ed13a92d0fde ("docs: archis: add a per-architecture features list")
Signed-off-by: Mauro Carvalho Chehab
---
Jon/Stephen,
I ended forgetting to add this one to the patch I sent. Sorry for that!
If not too late, feel free to fold this patch with the past one.
Documentation/nios2/features.rst | 3 +++
1 file changed, 3 insertions(+)
create mode 100644 Documentation/nios2/features.rst
diff --git a/Documentation/nios2/features.rst b/Documentation/nios2/features.rst
new file mode 100644
index ..8449e63f69b2
--- /dev/null
+++ b/Documentation/nios2/features.rst
@@ -0,0 +1,3 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. kernel-feat:: $srctree/Documentation/features nios2
--
2.28.0
Re: [PATCH v3] phram: Allow the user to set the erase page size.
Hi Guohua,
Guohua Zhong wrote on Mon, 7 Dec 2020
16:53:42 +0800:
> From: Patrick O'Grady
>
> Permit the user to specify the erase page size as a parameter.
> This solves two problems:
>
> - phram can access images made by mkfs.jffs2. mkfs.jffs2 won't
> create images with erase sizes less than 8KiB; many architectures
> define PAGE_SIZE as 4KiB.
>
> - Allows more effective use of small capacity devices. JFFS2
> needs somewhere between 2 and 5 empty pages for garbage collection;
> and for an NVRAM part with only 32KiB of space, a smaller erase page
> allows much better utilization in applications where garbage collection
> is important.
>
> Signed-off-by: Patrick O'Grady
> Reviewed-by: Joern Engel
> Link:
> https://lore.kernel.org/lkml/CAJ7m5OqYv_=JB9NhHsqBsa8YU0DFRoP7C+W10PY22wonAGJK=a...@mail.gmail.com/
> [Guohua Zhong: fix token array index out of bounds and update patch for
> kernel master branch]
> Signed-off-by: Guohua Zhong
>
> v3:
> update authorship for Patrick O'Grady and remove the reported-by tag for
> kernel test robot
>
> v2:
> https://lore.kernel.org/lkml/20201204080821.46868-1-zhongguoh...@huawei.com/
> fix build error which is reported by kernel test robot
>
> v1:
> https://lore.kernel.org/lkml/20201124061053.10812-1-zhongguoh...@huawei.com/
> 1.fix token array index out of bounds
> 2.update patch for kernel master branch
I cannot apply your patch as-is: the changelog (v1, v2, etc) should be
below the three dashes...
> ---
...here!
Otherwise it would be part of the final commit message, which is not
something we want.
> drivers/mtd/devices/phram.c | 52
> +
> 1 file changed, 34 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/mtd/devices/phram.c b/drivers/mtd/devices/phram.c
> index 087b5e86d1bf..1729b94b2abf 100644
> --- a/drivers/mtd/devices/phram.c
> +++ b/drivers/mtd/devices/phram.c
> @@ -6,14 +6,14 @@
> * Usage:
> *
> * one commend line parameter per device, each in the form:
> - * phram=,,
> + * phram=,,[,]
> * may be up to 63 characters.
> - * and can be octal, decimal or hexadecimal. If followed
> + * , , and can be octal, decimal or hexadecimal. If
> followed
> * by "ki", "Mi" or "Gi", the numbers will be interpreted as kilo, mega or
> - * gigabytes.
> + * gigabytes. is optional and defaults to PAGE_SIZE.
> *
> * Example:
> - * phram=swap,64Mi,128Mi phram=test,900Mi,1Mi
> + * phram=swap,64Mi,128Mi phram=test,900Mi,1Mi,64Ki
> */
>
> #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> @@ -26,6 +26,7 @@
> #include
> #include
> #include
> +#include
>
> struct phram_mtd_list {
> struct mtd_info mtd;
> @@ -88,7 +89,7 @@ static void unregister_devices(void)
> }
> }
>
> -static int register_device(char *name, phys_addr_t start, size_t len)
> +static int register_device(char *name, phys_addr_t start, size_t len,
> uint32_t erasesize)
> {
> struct phram_mtd_list *new;
> int ret = -ENOMEM;
> @@ -115,7 +116,7 @@ static int register_device(char *name, phys_addr_t start,
> size_t len)
> new->mtd._write = phram_write;
> new->mtd.owner = THIS_MODULE;
> new->mtd.type = MTD_RAM;
> - new->mtd.erasesize = PAGE_SIZE;
> + new->mtd.erasesize = erasesize;
> new->mtd.writesize = 1;
>
> ret = -EAGAIN;
> @@ -204,22 +205,23 @@ static inline void kill_final_newline(char *str)
> static int phram_init_called;
> /*
> * This shall contain the module parameter if any. It is of the form:
> - * - phram=,, for module case
> - * - phram.phram=,, for built-in case
> - * We leave 64 bytes for the device name, 20 for the address and 20 for the
> - * size.
> - * Example: phram.phram=rootfs,0xa000,512Mi
> + * - phram=,,[,] for module case
> + * - phram.phram=,,[,] for built-in case
> + * We leave 64 bytes for the device name, 20 for the address , 20 for the
> + * size and 20 for the erasesize.
> + * Example: phram.phram=rootfs,0xa000,512Mi,65536
> */
> -static char phram_paramline[64 + 20 + 20];
> +static char phram_paramline[64 + 20 + 20 + 20];
> #endif
>
> static int phram_setup(const char *val)
> {
> - char buf[64 + 20 + 20], *str = buf;
> - char *token[3];
> + char buf[64 + 20 + 20 + 20], *str = buf;
> + char *token[4];
> char *name;
> uint64_t start;
> uint64_t len;
> + uint64_t erasesize = PAGE_SIZE;
> int i, ret;
>
> if (strnlen(val, sizeof(buf)) >= sizeof(buf))
> @@ -228,7 +230,7 @@ static int phram_setup(const char *val)
> strcpy(str, val);
> kill_final_newline(str);
>
> - for (i = 0; i < 3; i++)
> + for (i = 0; i < 4; i++)
> token[i] = strsep(&str, ",");
>
> if (str)
> @@ -253,11 +255,25 @@ static int phram_setup(const char *val)
> goto error;
> }
>
> - ret = register_device(name, start, len);
> + if (token[3]) {
> + ret = parse_num64(&erasesize, token[3]);
> +
Re: [PATCH] kbuild: avoid static_assert for genksyms
On Sun, 6 Dec 2020 at 03:49, Masahiro Yamada wrote: > > On Fri, Dec 4, 2020 at 8:10 AM Arnd Bergmann wrote: > > > > From: Arnd Bergmann > > > > genksyms does not know or care about the _Static_assert() built-in, > > and sometimes falls back to ignoring the later symbols, which causes > > undefined behavior such as > > > > WARNING: modpost: EXPORT symbol "ethtool_set_ethtool_phy_ops" [vmlinux] > > version generation failed, symbol will not be versioned. > > ld: net/ethtool/common.o: relocation R_AARCH64_ABS32 against > > `__crc_ethtool_set_ethtool_phy_ops' can not be used when making a shared > > object > > net/ethtool/common.o:(_ftrace_annotated_branch+0x0): dangerous relocation: > > unsupported relocation > > > > Redefine static_assert for genksyms to avoid that. > > > Please tell the CONFIG options needed to reproduce this. > I do not see it. > https://people.linaro.org/~ard.biesheuvel/randconfig-modversions-error
Re: [PATCH 3/3] edac: Supporting AST2400 and AST2600 edac driver
Hello Troy, > Hi Stefan, > > The driver was ported from latest ASPEED BSP, so I only test with ECC-on/off > from u-boot and check if driver runs correctly. I noticed now most changes are these "exports". As you removed them a later revision, the patch looks now lean and clean. I'll give you my Reviewed-by tag after you addressed Andrew's last comment. > The test doc you provided is very nice and detailed, I'll try to reproduce > the > injection test in v2 patch. It does not harm to redo the testing. That is time-consuming and with your current, now trivial changes, it's not really necessary. Stefan
Re: [PATCH 1/3] ALSA: hda/ca0132 - Fix AE-5 rear headphone pincfg.
On Mon, 07 Dec 2020 09:46:13 +0100, Connor McAdams wrote: > > The Windows driver sets the pincfg for the AE-5's rear-headphone to > report as a microphone. This causes issues with Pulseaudio mistakenly > believing there is no headphone plugged in. In Linux, we should instead > set it to be a headphone. > > Signed-off-by: Connor McAdams Those patches are relevant with your previous patches, right? If it's a fix for a specific commit, it'd be appreciated to have a "Fixes:" tag with the commit id and "Cc:" tag to stable in the patch. thanks, Takashi
Re: linux-next: build failure after merge of the rcu tree
Hi Paul, On Sun, 6 Dec 2020 20:48:41 -0800 "Paul E. McKenney" wrote: > > On Mon, Dec 07, 2020 at 08:39:20AM +1100, Stephen Rothwell wrote: > > Hi Paul, > > > > On Fri, 4 Dec 2020 11:20:32 -0800 "Paul E. McKenney" > > wrote: > > > > > > Does the following patch fix things? (Sigh. It won't apply on the > > > rcu/next that you used. Or even on this moment's dev branch. I will > > > fold it in with attribution and update. But just to show you what my > > > thought is.) > > > > Sorry I didn't get the chance to test your patch, but it seems to make > > sense. I notice that you have added this to the rcu tree for today, so > > I guess we will see :-) > > Fair enough! ;-) And it built fine, thanks. -- Cheers, Stephen Rothwell pgpubXUoCu19Q.pgp Description: OpenPGP digital signature
Re: [PATCH 1/1] ice: fix array overflow on receiving too many fragments for a packet
Hi Xiaohui,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on tnguy-next-queue/dev-queue]
[also build test WARNING on v5.10-rc7 next-20201204]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Xiaohui-Zhang/ice-fix-array-overflow-on-receiving-too-many-fragments-for-a-packet/20201207-141033
base: https://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue.git
dev-queue
config: riscv-allyesconfig (attached as .config)
compiler: riscv64-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/0day-ci/linux/commit/b3906f69dcad641195cbf1ce9af3e9105a6f72e1
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Xiaohui-Zhang/ice-fix-array-overflow-on-receiving-too-many-fragments-for-a-packet/20201207-141033
git checkout b3906f69dcad641195cbf1ce9af3e9105a6f72e1
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=riscv
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
In file included from include/vdso/processor.h:10,
from arch/riscv/include/asm/processor.h:11,
from include/linux/prefetch.h:15,
from drivers/net/ethernet/intel/ice/ice_txrx.c:6:
arch/riscv/include/asm/vdso/processor.h: In function 'cpu_relax':
arch/riscv/include/asm/vdso/processor.h:14:2: error: implicit declaration of
function 'barrier' [-Werror=implicit-function-declaration]
14 | barrier();
| ^~~
drivers/net/ethernet/intel/ice/ice_txrx.c: In function 'ice_add_rx_frag':
>> drivers/net/ethernet/intel/ice/ice_txrx.c:828:2: warning: ISO C90 forbids
>> mixed declarations and code [-Wdeclaration-after-statement]
828 | struct skb_shared_info *shinfo = skb_shinfo(skb);
| ^~
>> drivers/net/ethernet/intel/ice/ice_txrx.c:831:24: warning: passing argument
>> 2 of 'skb_add_rx_frag' makes integer from pointer without a cast
>> [-Wint-conversion]
831 | skb_add_rx_frag(skb, shinfo, rx_buf->page,
|^~
||
|struct skb_shared_info *
In file included from include/net/net_namespace.h:39,
from include/linux/netdevice.h:37,
from include/trace/events/xdp.h:8,
from include/linux/bpf_trace.h:5,
from drivers/net/ethernet/intel/ice/ice_txrx.c:8:
include/linux/skbuff.h:2187:47: note: expected 'int' but argument is of type
'struct skb_shared_info *'
2187 | void skb_add_rx_frag(struct sk_buff *skb, int i, struct page *page,
int off,
| ^
cc1: some warnings being treated as errors
vim +828 drivers/net/ethernet/intel/ice/ice_txrx.c
825
826 if (!size)
827 return;
> 828 struct skb_shared_info *shinfo = skb_shinfo(skb);
829
830 if (shinfo->nr_frags < ARRAY_SIZE(shinfo->frags)) {
> 831 skb_add_rx_frag(skb, shinfo, rx_buf->page,
832 rx_buf->page_offset, size, truesize);
833 }
834
835 /* page is being used so we must update the page offset */
836 ice_rx_buf_adjust_pg_offset(rx_buf, truesize);
837 }
838
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: [RFC PATCH v2 0/2] add simple copy support
On 2020/12/07 17:16, javier.g...@samsung.com wrote:
> On 07.12.2020 08:06, Damien Le Moal wrote:
>> On 2020/12/07 16:46, javier.g...@samsung.com wrote:
>>> On 04.12.2020 23:40, Keith Busch wrote:
On Fri, Dec 04, 2020 at 11:25:12AM +, Damien Le Moal wrote:
> On 2020/12/04 20:02, SelvaKumar S wrote:
>> This patchset tries to add support for TP4065a ("Simple Copy Command"),
>> v2020.05.04 ("Ratified")
>>
>> The Specification can be found in following link.
>> https://nvmexpress.org/wp-content/uploads/NVM-Express-1.4-Ratified-TPs-1.zip
>>
>> This is an RFC. Looking forward for any feedbacks or other alternate
>> designs for plumbing simple copy to IO stack.
>>
>> Simple copy command is a copy offloading operation and is used to copy
>> multiple contiguous ranges (source_ranges) of LBA's to a single
>> destination
>> LBA within the device reducing traffic between host and device.
>>
>> This implementation accepts destination, no of sources and arrays of
>> source ranges from application and attach it as payload to the bio and
>> submits to the device.
>>
>> Following limits are added to queue limits and are exposed in sysfs
>> to userspace
>> - *max_copy_sectors* limits the sum of all source_range length
>> - *max_copy_nr_ranges* limits the number of source ranges
>> - *max_copy_range_sectors* limit the maximum number of sectors
>> that can constitute a single source range.
>
> Same comment as before. I think this is a good start, but for this to be
> really
> useful to users and kernel components alike, this really needs copy
> emulation
> for drives that do not have a native copy feature, similarly to what
> write zeros
> handling for instance: if the drive does not have a copy command (simple
> copy
> for NVMe or XCOPY for scsi), then the block layer should issue read/write
> commands to seamlessly execute the copy. Otherwise, this will only serve
> a small
> niche for users and will not be optimal for FS and DM drivers that could
> be
> simplified with a generic block layer copy functionality.
>
> This is my 10 cents though, others may differ about this.
Yes, I agree that copy emulation support should be included with the
hardware enabled solution.
>>>
>>> Keith, Damien,
>>>
>>> Can we do the block layer emulation with this patchset and then work in
>>> follow-up patchses on (i) the FS interface with F2FS as a first user and
>>> (ii) other HW accelerations such as XCOPY?
>>
>> The initial patchset supporting NVMe simple copy and emulation copy, all
>> under
>> an API that probably will be similar that of dm-kcopyd will cover all block
>> devices. Other hardware native support for copy functions such as scsi
>> extended
>> copy can be added later under the hood without any API changes (or minimal
>> changes).
>
> Sounds good. That we can do. We will add a new patch for this.
>
>>
>> I am not sure what you mean by "FS interface for F2FS": the block layer API
>> for
>> this copy functionality will be what F2FS (and other FSes) will call. That is
>> the interface, no ?
>
> Essentially yes.. I mean adding the F2FS logic and potentially some
> helpers to the block layer to aid GC.
GC is very much special to each FS. SO I do not think adding helpers to the
block layer will have value. We should stick to a pure block copy API for that
layer.
>
>>
>>> For XCOPY, I believe we need to have a separate discussion as much works
>>> is already done that we should align to.
>>
>> I think Martin (added to this thread) and others have looked into it but I do
>> not think that anything made it into the kernel yet.
>
> Exactly. Looking at some of the code posted through time and recalling
> the discussions at LSF/MM, seems like there are a number of things we
> are not addressing here that could be incorporated down the road, such
> as dedicated syscalls / extensions, multi namespace / device support,
> etc.
dm-kcopyd interface supports copy between multiple devices. That of course would
not enable NVMe simple copy use, but that makes the interface generic enough so
that we should not have any problem with other hardware copy functions.
>>
>
--
Damien Le Moal
Western Digital Research
[PATCH v4 2/3] ARM: dts: aspeed: Add AST2600 edac into common devicetree
Adding Aspeed AST2600 edac node into common devicetree.
Signed-off-by: Troy Lee
Reviewed-by: Joel Stanley
---
arch/arm/boot/dts/aspeed-g6.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/aspeed-g6.dtsi b/arch/arm/boot/dts/aspeed-g6.dtsi
index b58220a49cbd..74367ee96f20 100644
--- a/arch/arm/boot/dts/aspeed-g6.dtsi
+++ b/arch/arm/boot/dts/aspeed-g6.dtsi
@@ -69,6 +69,12 @@
always-on;
};
+ edac: sdram@1e6e {
+ compatible = "aspeed,ast2600-sdram-edac", "syscon";
+ reg = <0x1e6e 0x174>;
+ interrupts = ;
+ };
+
ahb {
compatible = "simple-bus";
#address-cells = <1>;
--
2.17.1
[PATCH v4 1/3] dt-bindings: edac: aspeed-sdram-edac: Add ast2400/ast2600 support
Adding Aspeed AST2400 and AST2600 binding for edac driver. Signed-off-by: Troy Lee Acked-by: Joel Stanley --- .../devicetree/bindings/edac/aspeed-sdram-edac.txt | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/Documentation/devicetree/bindings/edac/aspeed-sdram-edac.txt b/Documentation/devicetree/bindings/edac/aspeed-sdram-edac.txt index 6a0f3d90d682..8ca9e0a049d8 100644 --- a/Documentation/devicetree/bindings/edac/aspeed-sdram-edac.txt +++ b/Documentation/devicetree/bindings/edac/aspeed-sdram-edac.txt @@ -1,6 +1,6 @@ -Aspeed AST2500 SoC EDAC node +Aspeed BMC SoC EDAC node -The Aspeed AST2500 SoC supports DDR3 and DDR4 memory with and without ECC (error +The Aspeed BMC SoC supports DDR3 and DDR4 memory with and without ECC (error correction check). The memory controller supports SECDED (single bit error correction, double bit @@ -11,7 +11,10 @@ Note, the bootloader must configure ECC mode in the memory controller. Required properties: -- compatible: should be "aspeed,ast2500-sdram-edac" +- compatible: should be one of + - "aspeed,ast2400-sdram-edac" + - "aspeed,ast2500-sdram-edac" + - "aspeed,ast2600-sdram-edac" - reg:sdram controller register set should be <0x1e6e 0x174> - interrupts: should be AVIC interrupt #0 -- 2.17.1
[PATCH v4 3/3] edac: Supporting AST2400 and AST2600 edac driver
Adding AST2400 and AST2600 edac driver support.
Signed-off-by: Troy Lee
---
drivers/edac/Kconfig | 6 +++---
drivers/edac/aspeed_edac.c | 7 +--
2 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig
index 7a47680d6f07..c410331e8ee8 100644
--- a/drivers/edac/Kconfig
+++ b/drivers/edac/Kconfig
@@ -515,10 +515,10 @@ config EDAC_QCOM
health, you should probably say 'Y' here.
config EDAC_ASPEED
- tristate "Aspeed AST 2500 SoC"
- depends on MACH_ASPEED_G5
+ tristate "Aspeed AST BMC SoC"
+ depends on ARCH_ASPEED
help
- Support for error detection and correction on the Aspeed AST 2500 SoC.
+ Support for error detection and correction on the Aspeed AST BMC SoC.
First, ECC must be configured in the bootloader. Then, this driver
will expose error counters via the EDAC kernel framework.
diff --git a/drivers/edac/aspeed_edac.c b/drivers/edac/aspeed_edac.c
index fde809efc520..a46da56d6d54 100644
--- a/drivers/edac/aspeed_edac.c
+++ b/drivers/edac/aspeed_edac.c
@@ -239,7 +239,7 @@ static int init_csrows(struct mem_ctl_info *mci)
int rc;
/* retrieve info about physical memory from device tree */
- np = of_find_node_by_path("/memory");
+ np = of_find_node_by_name(NULL, "memory");
if (!np) {
dev_err(mci->pdev, "dt: missing /memory node\n");
return -ENODEV;
@@ -375,10 +375,13 @@ static int aspeed_remove(struct platform_device *pdev)
static const struct of_device_id aspeed_of_match[] = {
+ { .compatible = "aspeed,ast2400-sdram-edac" },
{ .compatible = "aspeed,ast2500-sdram-edac" },
+ { .compatible = "aspeed,ast2600-sdram-edac" },
{},
};
+MODULE_DEVICE_TABLE(of, aspeed_of_match);
static struct platform_driver aspeed_driver = {
.driver = {
@@ -392,5 +395,5 @@ module_platform_driver(aspeed_driver);
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Stefan Schaeckeler ");
-MODULE_DESCRIPTION("Aspeed AST2500 EDAC driver");
+MODULE_DESCRIPTION("Aspeed BMC SoC EDAC driver");
MODULE_VERSION("1.0");
--
2.17.1
Re: [PATCH sl-b 1/6] mm: Add kmem_last_alloc() to return last allocation for memory block
Hello, Paul. On Fri, Dec 04, 2020 at 04:40:52PM -0800, paul...@kernel.org wrote: > From: "Paul E. McKenney" > > There are kernel facilities such as per-CPU reference counts that give > error messages in generic handlers or callbacks, whose messages are > unenlightening. In the case of per-CPU reference-count underflow, this > is not a problem when creating a new use of this facility because in that > case the bug is almost certainly in the code implementing that new use. > However, trouble arises when deploying across many systems, which might > exercise corner cases that were not seen during development and testing. > Here, it would be really nice to get some kind of hint as to which of > several uses the underflow was caused by. > > This commit therefore exposes a new kmem_last_alloc() function that > takes a pointer to dynamically allocated memory and returns the return > address of the call that allocated it. This pointer can reference the > middle of the block as well as the beginning of the block, as needed > by things like RCU callback functions and timer handlers that might not > know where the beginning of the memory block is. These functions and > handlers can use the return value from kmem_last_alloc() to give the > kernel hacker a better hint as to where the problem might lie. I agree with exposing allocation caller information to the other subsystem to help the debugging. Some suggestions... 1. It's better to separate a slab object check (validity check) and retrieving the allocation caller. Someone else would want to check only a validity. And, it doesn't depend on the debug configuration so it's not good to bind it to the debug function. kmem_cache_valid_(obj|ptr) kmalloc_valid_(obj|ptr) 2. rename kmem_last_alloc to ... int kmem_cache_debug_alloc_caller(cache, obj, &ret_addr) int kmalloc_debug_alloc_caller(obj, &ret_addr) or debug_kmem_cache_alloc_caller() I think that function name need to include the keyword 'debug' to show itself as a debugging facility (enabled at the debugging). And, return errno and get caller address by pointer argument. 3. If concrete error message is needed, please introduce more functions. void *kmalloc_debug_error(errno) Thanks.
Re: [PATCH 2/3] rwsem: Implement down_read_interruptible
On Thu, Dec 03, 2020 at 08:59:13PM -0500, Waiman Long wrote:
> On 12/3/20 3:11 PM, Eric W. Biederman wrote:
> > +static inline int __down_read_interruptible(struct rw_semaphore *sem)
> > +{
> > + if (!rwsem_read_trylock(sem)) {
> > + if (IS_ERR(rwsem_down_read_slowpath(sem, TASK_INTERRUPTIBLE)))
> > + return -EINTR;
> > + DEBUG_RWSEMS_WARN_ON(!is_rwsem_reader_owned(sem), sem);
> > + } else {
> > + rwsem_set_reader_owned(sem);
> > + }
> > + return 0;
> > +}
> > +
> > static inline int __down_read_killable(struct rw_semaphore *sem)
> > {
> > if (!rwsem_read_trylock(sem)) {
> > @@ -1495,6 +1507,20 @@ void __sched down_read(struct rw_semaphore *sem)
> > }
> > EXPORT_SYMBOL(down_read);
> > +int __sched down_read_interruptible(struct rw_semaphore *sem)
> > +{
> > + might_sleep();
> > + rwsem_acquire_read(&sem->dep_map, 0, 0, _RET_IP_);
> > +
> > + if (LOCK_CONTENDED_RETURN(sem, __down_read_trylock,
> > __down_read_interruptible)) {
> > + rwsem_release(&sem->dep_map, _RET_IP_);
> > + return -EINTR;
> > + }
> > +
> > + return 0;
> > +}
> > +EXPORT_SYMBOL(down_read_interruptible);
> > +
> > int __sched down_read_killable(struct rw_semaphore *sem)
> > {
> > might_sleep();
>
> Acked-by: Waiman Long
Yeah, that seems correct.. There's an unfortunate amount of copy-paste
there though.
Do we want to follow that up with something like this?
---
--- a/kernel/locking/rwsem.c
+++ b/kernel/locking/rwsem.c
@@ -275,7 +275,25 @@ static inline bool rwsem_read_trylock(st
long cnt = atomic_long_add_return_acquire(RWSEM_READER_BIAS,
&sem->count);
if (WARN_ON_ONCE(cnt < 0))
rwsem_set_nonspinnable(sem);
- return !(cnt & RWSEM_READ_FAILED_MASK);
+
+ if (!(cnt & RWSEM_READ_FAILED_MASK)) {
+ rwsem_set_reader_owned(sem);
+ return true;
+ }
+
+ return false;
+}
+
+static inline bool rwsem_write_trylock(struct rw_semaphore *sem)
+{
+ long tmp = RWSEM_UNLOCKED_VALUE;
+
+ if (atomic_long_try_cmpxchg_acquire(&sem->count, &tmp,
RWSEM_WRITER_LOCKED)) {
+ rwsem_set_owner(sem);
+ return true;
+ }
+
+ return false;
}
/*
@@ -1335,38 +1353,29 @@ static struct rw_semaphore *rwsem_downgr
/*
* lock for reading
*/
-static inline void __down_read(struct rw_semaphore *sem)
+static inline int __down_read_common(struct rw_semaphore *sem, int state)
{
if (!rwsem_read_trylock(sem)) {
- rwsem_down_read_slowpath(sem, TASK_UNINTERRUPTIBLE);
+ if (IS_ERR(rwsem_down_read_slowpath(sem, state)))
+ return -EINTR;
DEBUG_RWSEMS_WARN_ON(!is_rwsem_reader_owned(sem), sem);
- } else {
- rwsem_set_reader_owned(sem);
}
+ return 0;
}
-static inline int __down_read_interruptible(struct rw_semaphore *sem)
+static __always_inline void __down_read(struct rw_semaphore *sem)
{
- if (!rwsem_read_trylock(sem)) {
- if (IS_ERR(rwsem_down_read_slowpath(sem, TASK_INTERRUPTIBLE)))
- return -EINTR;
- DEBUG_RWSEMS_WARN_ON(!is_rwsem_reader_owned(sem), sem);
- } else {
- rwsem_set_reader_owned(sem);
- }
- return 0;
+ __down_read_common(sem, TASK_UNINTERRUPTIBLE);
}
-static inline int __down_read_killable(struct rw_semaphore *sem)
+static __always_inline int __down_read_interruptible(struct rw_semaphore *sem)
{
- if (!rwsem_read_trylock(sem)) {
- if (IS_ERR(rwsem_down_read_slowpath(sem, TASK_KILLABLE)))
- return -EINTR;
- DEBUG_RWSEMS_WARN_ON(!is_rwsem_reader_owned(sem), sem);
- } else {
- rwsem_set_reader_owned(sem);
- }
- return 0;
+ return __down_read_common(sem, TASK_INTERRUPTIBLE);
+}
+
+static __always_inline int __down_read_killable(struct rw_semaphore *sem)
+{
+ return __down_read_common(sem, TASK_KILLABLE);
}
static inline int __down_read_trylock(struct rw_semaphore *sem)
@@ -1392,44 +1401,29 @@ static inline int __down_read_trylock(st
/*
* lock for writing
*/
-static inline void __down_write(struct rw_semaphore *sem)
+static inline int __down_write_common(struct rw_semaphore *sem, int state)
{
- long tmp = RWSEM_UNLOCKED_VALUE;
-
- if (unlikely(!atomic_long_try_cmpxchg_acquire(&sem->count, &tmp,
- RWSEM_WRITER_LOCKED)))
- rwsem_down_write_slowpath(sem, TASK_UNINTERRUPTIBLE);
- else
- rwsem_set_owner(sem);
+ if (unlikely(!rwsem_write_trylock(sem))) {
+ if (IS_ERR(rwsem_down_write_slowpath(sem, state)))
+ return -EINTR;
+ }
+ return 0;
}
-static inline int __down_write_killable(struct rw_semaphore *sem)
+static __always_inline void __down_write(struct rw_semaphore
Re: [RFC V2 3/3] s390/mm: Define arch_get_mappable_range()
On 07.12.20 05:38, Anshuman Khandual wrote:
>
>
> On 12/3/20 5:31 PM, David Hildenbrand wrote:
>> On 03.12.20 12:51, Heiko Carstens wrote:
>>> On Thu, Dec 03, 2020 at 06:03:00AM +0530, Anshuman Khandual wrote:
>> diff --git a/arch/s390/mm/extmem.c b/arch/s390/mm/extmem.c
>> index 5060956b8e7d..cc055a78f7b6 100644
>> --- a/arch/s390/mm/extmem.c
>> +++ b/arch/s390/mm/extmem.c
>> @@ -337,6 +337,11 @@ __segment_load (char *name, int do_nonshared,
>> unsigned long *addr, unsigned long
>> goto out_free_resource;
>> }
>>
>> +if (seg->end + 1 > VMEM_MAX_PHYS || seg->end + 1 <
>> seg->start_addr) {
>> +rc = -ERANGE;
>> +goto out_resource;
>> +}
>> +
>> rc = vmem_add_mapping(seg->start_addr, seg->end -
>> seg->start_addr + 1);
>> if (rc)
>> goto out_resource;
>> diff --git a/arch/s390/mm/vmem.c b/arch/s390/mm/vmem.c
>> index b239f2ba93b0..06dddcc0ce06 100644
>> --- a/arch/s390/mm/vmem.c
>> +++ b/arch/s390/mm/vmem.c
>> @@ -532,14 +532,19 @@ void vmem_remove_mapping(unsigned long start,
>> unsigned long size)
>> mutex_unlock(&vmem_mutex);
>> }
>>
>> +struct range arch_get_mappable_range(void)
>> +{
>> +struct range memhp_range;
>> +
>> +memhp_range.start = 0;
>> +memhp_range.end = VMEM_MAX_PHYS;
>> +return memhp_range;
>> +}
>> +
>> int vmem_add_mapping(unsigned long start, unsigned long size)
>> {
>> int ret;
>>
>> -if (start + size > VMEM_MAX_PHYS ||
>> -start + size < start)
>> -return -ERANGE;
>> -
>
> I really fail to see how this could be considered an improvement for
> s390. Especially I do not like that the (central) range check is now
> moved to the caller (__segment_load). Which would mean potential
> additional future callers would have to duplicate that code as well.
The physical range check is being moved to the generic hotplug code
via arch_get_mappable_range() instead, making the existing check in
vmem_add_mapping() redundant. Dropping the check there necessitates
adding back a similar check in __segment_load(). Otherwise there
will be a loss of functionality in terms of range check.
May be we could just keep this existing check in vmem_add_mapping()
as well in order avoid this movement but then it would be redundant
check in every hotplug path.
So I guess the choice is to either have redundant range checks in
all hotplug paths or future internal callers of vmem_add_mapping()
take care of the range check.
>>>
>>> The problem I have with this current approach from an architecture
>>> perspective: we end up having two completely different methods which
>>> are doing the same and must be kept in sync. This might be obvious
>>> looking at this patch, but I'm sure this will go out-of-sync (aka
>>> broken) sooner or later.
>>
>> Exactly, there should be one function only that was the whole idea of
>> arch_get_mappable_range().
>>
>>>
>>> Therefore I would really like to see a single method to do the range
>>> checking. Maybe you could add a callback into architecture code, so
>>> that such an architecture specific function could also be used
>>> elsewhere. Dunno.
>>>
>>
>> I think we can just switch to using "memhp_range_allowed()" here then
>> after implementing arch_get_mappable_range().
>>
>> Doesn't hurt to double check in vmem_add_mapping() - especially to keep
>> extmem working without changes. At least for callers of memory hotplug
>> it's then clear which values actually won't fail deep down in arch code.
>
> But there is a small problem here. memhp_range_allowed() is now defined
> and available with CONFIG_MEMORY_HOTPLUG where as vmem_add_mapping() and
> __segment_load() are generally available without any config dependency.
> So if CONFIG_MEMORY_HOTPLUG is not enabled there will be a build failure
> in vmem_add_mapping() for memhp_range_allowed() symbol.
>
> We could just move VM_BUG_ON(!memhp_range_allowed(start, size, 1)) check
> from vmem_add_mapping() to arch_add_memory() like on arm64 platform. But
> then __segment_load() would need that additional new check to compensate
> as proposed earlier.
>
> Also leaving vmem_add_mapping() and __segment_load() unchanged will cause
> the address range check to be called three times on the hotplug path i.e
>
> 1. register_memory_resource()
> 2. arch_add_memory()
> 3. vmem_add_mapping()
>
> Moving memhp_range_allowed() check inside arch_add_memory() seems better
> and consistent with arm64. Also in the future, any platform which choose
> to override arch_get_mappable() will have this additional VM_BUG_ON() in
> their arch_add_memory().
Yeah, it might not make sense to add these c
[PATCH drm/hisilicon v2 0/2] Code refactoring
patch #1 is used drmm_mode_config_init() to do code refactoring. patch #2 is deleted unused variable ‘priv’ to avoid warning. Changes since v1: Remove the unused structure member variable mode_config_initialized. Tian Tao (2): drm/hisilicon: Use managed mode-config init drm/hisilicon: Delete unused local parameters drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 19 --- drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h | 1 - 2 files changed, 4 insertions(+), 16 deletions(-) -- 2.7.4
[PATCH drm/hisilicon v2 1/2] drm/hisilicon: Use managed mode-config init
Using drmm_mode_config_init() sets up managed release of modesetting
resources.
Signed-off-by: Tian Tao
---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 14 +++---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h | 1 -
2 files changed, 3 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
index 3687753..7f01213 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
@@ -96,8 +96,9 @@ static int hibmc_kms_init(struct hibmc_drm_private *priv)
struct drm_device *dev = &priv->dev;
int ret;
- drm_mode_config_init(dev);
- priv->mode_config_initialized = true;
+ ret = drmm_mode_config_init(dev);
+ if (ret)
+ return ret;
dev->mode_config.min_width = 0;
dev->mode_config.min_height = 0;
@@ -125,14 +126,6 @@ static int hibmc_kms_init(struct hibmc_drm_private *priv)
return 0;
}
-static void hibmc_kms_fini(struct hibmc_drm_private *priv)
-{
- if (priv->mode_config_initialized) {
- drm_mode_config_cleanup(&priv->dev);
- priv->mode_config_initialized = false;
- }
-}
-
/*
* It can operate in one of three modes: 0, 1 or Sleep.
*/
@@ -262,7 +255,6 @@ static int hibmc_unload(struct drm_device *dev)
drm_atomic_helper_shutdown(dev);
pci_disable_msi(dev->pdev);
- hibmc_kms_fini(priv);
dev->dev_private = NULL;
return 0;
}
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
index a49c10e..7d263f4 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
@@ -42,7 +42,6 @@ struct hibmc_drm_private {
struct drm_crtc crtc;
struct drm_encoder encoder;
struct hibmc_connector connector;
- bool mode_config_initialized;
};
static inline struct hibmc_connector *to_hibmc_connector(struct drm_connector
*connector)
--
2.7.4
[PATCH drm/hisilicon v2 2/2] drm/hisilicon: Delete unused local parameters
delete unused variable ‘priv’ to avoid warning.
Signed-off-by: Tian Tao
Reviewed-by: Thomas Zimmermann
---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
index 7f01213..7e91ef1 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
@@ -250,12 +250,9 @@ static int hibmc_hw_init(struct hibmc_drm_private *priv)
static int hibmc_unload(struct drm_device *dev)
{
- struct hibmc_drm_private *priv = to_hibmc_drm_private(dev);
-
drm_atomic_helper_shutdown(dev);
-
pci_disable_msi(dev->pdev);
- dev->dev_private = NULL;
+
return 0;
}
--
2.7.4
[PATCH] NFSv4.1: use BITS_PER_LONG macro in nfs4session.h
Use the existing BITS_PER_LONG macro instead of calculating the value.
Signed-off-by: Geliang Tang
---
fs/nfs/nfs4session.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/nfs/nfs4session.h b/fs/nfs/nfs4session.h
index b996ee23f1ba..3de425f59b3a 100644
--- a/fs/nfs/nfs4session.h
+++ b/fs/nfs/nfs4session.h
@@ -34,7 +34,7 @@ enum nfs4_slot_tbl_state {
NFS4_SLOT_TBL_DRAINING,
};
-#define SLOT_TABLE_SZ DIV_ROUND_UP(NFS4_MAX_SLOT_TABLE, 8*sizeof(long))
+#define SLOT_TABLE_SZ DIV_ROUND_UP(NFS4_MAX_SLOT_TABLE, BITS_PER_LONG)
struct nfs4_slot_table {
struct nfs4_session *session; /* Parent session */
struct nfs4_slot *slots;/* seqid per slot */
--
2.26.2
Re: [PATCH v2 1/3] v4l: Add HDR10 static metadata controls
On 12/2/20 1:12 PM, Hans Verkuil wrote:
> On 24/11/2020 00:02, Stanimir Varbanov wrote:
>> Add Content light level and Mastering display colour volume v4l2
>> compounf controls, relevant payload structures and validation.
>
> compounf -> compound
>
>>
>> Signed-off-by: Stanimir Varbanov
>> ---
>> drivers/media/v4l2-core/v4l2-ctrls.c | 62
>> include/media/hdr10-ctrls.h | 55
>> include/media/v4l2-ctrls.h | 3 ++
>> 3 files changed, 120 insertions(+)
>> create mode 100644 include/media/hdr10-ctrls.h
>>
>> diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
>> b/drivers/media/v4l2-core/v4l2-ctrls.c
>> index ad47d00e28d6..028630576401 100644
>> --- a/drivers/media/v4l2-core/v4l2-ctrls.c
>> +++ b/drivers/media/v4l2-core/v4l2-ctrls.c
>> @@ -1024,6 +1024,9 @@ const char *v4l2_ctrl_get_name(u32 id)
>> case V4L2_CID_MPEG_VIDEO_HEVC_DECODE_MODE: return "HEVC
>> Decode Mode";
>> case V4L2_CID_MPEG_VIDEO_HEVC_START_CODE: return "HEVC
>> Start Code";
>>
>> +case V4L2_CID_MPEG_VIDEO_HDR10_CLL_INFO:return "HDR10
>> Content Light Info";
>> +case V4L2_CID_MPEG_VIDEO_HDR10_MASTERING_DISPLAY: return "HDR10
>> Mastering Display";
>> +
>> /* CAMERA controls */
>> /* Keep the order of the 'case's the same as in v4l2-controls.h! */
>> case V4L2_CID_CAMERA_CLASS: return "Camera Controls";
>> @@ -1461,6 +1464,12 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
>> v4l2_ctrl_type *type,
>> case V4L2_CID_MPEG_VIDEO_HEVC_SLICE_PARAMS:
>> *type = V4L2_CTRL_TYPE_HEVC_SLICE_PARAMS;
>> break;
>> +case V4L2_CID_MPEG_VIDEO_HDR10_CLL_INFO:
>> +*type = V4L2_CTRL_TYPE_HDR10_CLL_INFO;
>> +break;
>> +case V4L2_CID_MPEG_VIDEO_HDR10_MASTERING_DISPLAY:
>> +*type = V4L2_CTRL_TYPE_HDR10_MASTERING_DISPLAY;
>> +break;
>> case V4L2_CID_UNIT_CELL_SIZE:
>> *type = V4L2_CTRL_TYPE_AREA;
>> *flags |= V4L2_CTRL_FLAG_READ_ONLY;
>> @@ -1775,6 +1784,7 @@ static int std_validate_compound(const struct
>> v4l2_ctrl *ctrl, u32 idx,
>> struct v4l2_ctrl_hevc_sps *p_hevc_sps;
>> struct v4l2_ctrl_hevc_pps *p_hevc_pps;
>> struct v4l2_ctrl_hevc_slice_params *p_hevc_slice_params;
>> +struct v4l2_ctrl_hdr10_mastering_display *p_hdr10_mastering;
>> struct v4l2_area *area;
>> void *p = ptr.p + idx * ctrl->elem_size;
>> unsigned int i;
>> @@ -1934,6 +1944,52 @@ static int std_validate_compound(const struct
>> v4l2_ctrl *ctrl, u32 idx,
>> zero_padding(*p_hevc_slice_params);
>> break;
>>
>> +case V4L2_CTRL_TYPE_HDR10_CLL_INFO:
>> +break;
>> +
>> +case V4L2_CTRL_TYPE_HDR10_MASTERING_DISPLAY:
>> +p_hdr10_mastering = p;
>> +
>> +for (i = 0; i < 3; ++i) {
>> +if (p_hdr10_mastering->display_primaries_x[i] <
>> +V4L2_HDR10_MASTERING_PRIMARIES_X_LOW ||
>> +p_hdr10_mastering->display_primaries_x[i] >
>> +V4L2_HDR10_MASTERING_PRIMARIES_X_HIGH ||
>> +p_hdr10_mastering->display_primaries_y[i] <
>> +V4L2_HDR10_MASTERING_PRIMARIES_Y_LOW ||
>> +p_hdr10_mastering->display_primaries_y[i] >
>> +V4L2_HDR10_MASTERING_PRIMARIES_Y_HIGH)
>> +return -EINVAL;
>> +}
>> +
>> +if (p_hdr10_mastering->white_point_x <
>> +V4L2_HDR10_MASTERING_WHITE_POINT_X_LOW ||
>> +p_hdr10_mastering->white_point_x >
>> +V4L2_HDR10_MASTERING_WHITE_POINT_X_HIGH ||
>> +p_hdr10_mastering->white_point_y <
>> +V4L2_HDR10_MASTERING_WHITE_POINT_Y_LOW ||
>> +p_hdr10_mastering->white_point_y >
>> +V4L2_HDR10_MASTERING_WHITE_POINT_Y_HIGH)
>> +return -EINVAL;
>> +
>> +if (p_hdr10_mastering->max_luminance <
>> +V4L2_HDR10_MASTERING_MAX_LUMA_LOW ||
>> +p_hdr10_mastering->max_luminance >
>> +V4L2_HDR10_MASTERING_MAX_LUMA_HIGH ||
>> +p_hdr10_mastering->min_luminance <
>> +V4L2_HDR10_MASTERING_MIN_LUMA_LOW ||
>> +p_hdr10_mastering->min_luminance >
>> +V4L2_HDR10_MASTERING_MIN_LUMA_HIGH)
>> +return -EINVAL;
>> +
>> +if (p_hdr10_mastering->max_luminance ==
>> +V4L2_HDR10_MASTERING_MAX_LUMA_LOW &&
>> +p_hdr10_mastering->min_luminance ==
>> +V4L2_HDR10_MASTERING_MIN_LUMA_HIGH)
>> +return -EINVAL;
>> +
>> +break;
>> +
>> case V4L2_CTRL_TYPE_AREA:
>> area = p;
>>
Re: [PATCH 0/4] dt-bindings: media: eliminate yamllint warnings
Hi Zhen, On Mon, Dec 07, 2020 at 12:23:56PM +0800, Zhen Lei wrote: > These patches are based on the latest linux-next code. > > Zhen Lei (4): > dt-bindings: media: adv7604: eliminate yamllint warnings > dt-bindings: media: nokia,smia: eliminate yamllint warnings > dt-bindings: media: ov772x: eliminate yamllint warnings > dt-bindings: media: imx214: eliminate yamllint warnings The adv7604, ov772x and imx214 bits have been addressed by: https://www.spinics.net/lists/linux-media/msg181093.html Thanks j > > Documentation/devicetree/bindings/media/i2c/adv7604.yaml | 4 ++-- > Documentation/devicetree/bindings/media/i2c/mipi-ccs.yaml| 11 ++- > Documentation/devicetree/bindings/media/i2c/ovti,ov772x.yaml | 12 > ++-- > Documentation/devicetree/bindings/media/i2c/sony,imx214.yaml | 12 > ++-- > 4 files changed, 20 insertions(+), 19 deletions(-) > > -- > 1.8.3 > >
Re: [PATCH] arm64: mm: decrease the section size to reduce the memory reserved for the page map
(+ Marc) On Fri, 4 Dec 2020 at 12:14, Will Deacon wrote: > > On Fri, Dec 04, 2020 at 09:44:43AM +0800, Wei Li wrote: > > For the memory hole, sparse memory model that define SPARSEMEM_VMEMMAP > > do not free the reserved memory for the page map, decrease the section > > size can reduce the waste of reserved memory. > > > > Signed-off-by: Wei Li > > Signed-off-by: Baopeng Feng > > Signed-off-by: Xia Qing > > --- > > arch/arm64/include/asm/sparsemem.h | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/arch/arm64/include/asm/sparsemem.h > > b/arch/arm64/include/asm/sparsemem.h > > index 1f43fcc79738..8963bd3def28 100644 > > --- a/arch/arm64/include/asm/sparsemem.h > > +++ b/arch/arm64/include/asm/sparsemem.h > > @@ -7,7 +7,7 @@ > > > > #ifdef CONFIG_SPARSEMEM > > #define MAX_PHYSMEM_BITS CONFIG_ARM64_PA_BITS > > -#define SECTION_SIZE_BITS30 > > +#define SECTION_SIZE_BITS27 > > We chose '30' to avoid running out of bits in the page flags. What changed? > > With this patch, I can trigger: > > ./include/linux/mmzone.h:1170:2: error: Allocator MAX_ORDER exceeds > SECTION_SIZE > #error Allocator MAX_ORDER exceeds SECTION_SIZE > > if I bump up NR_CPUS and NODES_SHIFT. > Does this mean we will run into problems with the GICv3 ITS LPI tables again if we are forced to reduce MAX_ORDER to fit inside SECTION_SIZE_BITS?
Re: [PATCH 3/3] exec: Transform exec_update_mutex into a rw_semaphore
On Fri, Dec 04, 2020 at 12:48:18PM -0800, Linus Torvalds wrote: > On Fri, Dec 4, 2020 at 12:30 PM Bernd Edlinger > wrote: > >> > > >perf_event_open (exec_update_mutex -> ovl_i_mutex) > > Side note: this one looks like it should be easy to fix. > PeterZ, is there something I'm missing? Like this? https://lkml.kernel.org/r/20200828123720.gz1362...@hirez.programming.kicks-ass.net
Re: [PATCH 3/3] Serial: Separate out earlycon support
On Mon, Dec 07, 2020 at 02:17:27PM +0530, Akash Asthana wrote: > Separate out earlycon support from serial driver and remove it's > dependency on QUP wrapper driver. > > This enable us to manage earlycon independently and we can re-use the > same earlycon driver for android project which currently uses > downstream version of QUP drivers. What do you mean by "downstream" here? > > Signed-off-by: Akash Asthana > --- > drivers/tty/serial/Kconfig | 9 + > drivers/tty/serial/Makefile | 1 + > drivers/tty/serial/qcom_geni_earlycon.c | 649 > > drivers/tty/serial/qcom_geni_serial.c | 97 - So you are replacing 97 lines of code with 649 lines? How is this benefiting anyone? confused, greg k-h
[PATCH 1/2] Input: elan_i2c - Add new trackpoint report type 0x5F.
The 0x5F is new trackpoint report type of some module.
Signed-off-by: Jingle Wu
---
drivers/input/mouse/elan_i2c_core.c | 2 ++
drivers/input/mouse/elan_i2c_smbus.c | 3 ++-
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/input/mouse/elan_i2c_core.c
b/drivers/input/mouse/elan_i2c_core.c
index 61ed3f5ca219..8f0c4663167c 100644
--- a/drivers/input/mouse/elan_i2c_core.c
+++ b/drivers/input/mouse/elan_i2c_core.c
@@ -52,6 +52,7 @@
#define ETP_REPORT_ID 0x5D
#define ETP_REPORT_ID2 0x60/* High precision report */
#define ETP_TP_REPORT_ID 0x5E
+#define ETP_TP_REPORT_ID2 0x5F
#define ETP_REPORT_ID_OFFSET 2
#define ETP_TOUCH_INFO_OFFSET 3
#define ETP_FINGER_DATA_OFFSET 4
@@ -1076,6 +1077,7 @@ static irqreturn_t elan_isr(int irq, void *dev_id)
elan_report_absolute(data, report, true);
break;
case ETP_TP_REPORT_ID:
+ case ETP_TP_REPORT_ID2:
elan_report_trackpoint(data, report);
break;
default:
diff --git a/drivers/input/mouse/elan_i2c_smbus.c
b/drivers/input/mouse/elan_i2c_smbus.c
index 1820f1cfc1dc..1226d47ec3cf 100644
--- a/drivers/input/mouse/elan_i2c_smbus.c
+++ b/drivers/input/mouse/elan_i2c_smbus.c
@@ -45,6 +45,7 @@
#define ETP_SMBUS_CALIBRATE_QUERY 0xC5
#define ETP_SMBUS_REPORT_LEN 32
+#define ETP_SMBUS_REPORT_LEN2 7
#define ETP_SMBUS_REPORT_OFFSET2
#define ETP_SMBUS_HELLOPACKET_LEN 5
#define ETP_SMBUS_IAP_PASSWORD 0x1234
@@ -497,7 +498,7 @@ static int elan_smbus_get_report(struct i2c_client *client,
return len;
}
- if (len != ETP_SMBUS_REPORT_LEN) {
+ if ((len != ETP_SMBUS_REPORT_LEN) && (len != ETP_SMBUS_REPORT_LEN2)) {
dev_err(&client->dev,
"wrong report length (%d vs %d expected)\n",
len, ETP_SMBUS_REPORT_LEN);
--
2.17.1
Re: [PATCH v4 3/3] edac: Supporting AST2400 and AST2600 edac driver
> Adding AST2400 and AST2600 edac driver support.
>
> Signed-off-by: Troy Lee
Reviewed-by: Stefan Schaeckeler
> ---
drivers/edac/Kconfig | 6 +++---
> drivers/edac/aspeed_edac.c | 7 +--
> 2 files changed, 8 insertions(+), 5 deletions(-)
> diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig
> index 7a47680d6f07..c410331e8ee8 100644
> --- a/drivers/edac/Kconfig
> +++ b/drivers/edac/Kconfig
> @@ -515,10 +515,10 @@ config EDAC_QCOM
> health, you should probably say 'Y' here.
>
> config EDAC_ASPEED
> - tristate "Aspeed AST 2500 SoC"
> - depends on MACH_ASPEED_G5
> + tristate "Aspeed AST BMC SoC"
> + depends on ARCH_ASPEED
> help
> - Support for error detection and correction on the Aspeed AST 2500 SoC.
> + Support for error detection and correction on the Aspeed AST BMC SoC.
>
> First, ECC must be configured in the bootloader. Then, this driver
> will expose error counters via the EDAC kernel framework.
> diff --git a/drivers/edac/aspeed_edac.c b/drivers/edac/aspeed_edac.c
> index fde809efc520..a46da56d6d54 100644
> --- a/drivers/edac/aspeed_edac.c
> +++ b/drivers/edac/aspeed_edac.c
> @@ -239,7 +239,7 @@ static int init_csrows(struct mem_ctl_info *mci)
> int rc;
>
> /* retrieve info about physical memory from device tree */
> - np = of_find_node_by_path("/memory");
> + np = of_find_node_by_name(NULL, "memory");
> if (!np) {
> dev_err(mci->pdev, "dt: missing /memory node\n");
> return -ENODEV;
> @@ -375,10 +375,13 @@ static int aspeed_remove(struct platform_device *pdev)
>
>
> static const struct of_device_id aspeed_of_match[] = {
> + { .compatible = "aspeed,ast2400-sdram-edac" },
> { .compatible = "aspeed,ast2500-sdram-edac" },
> + { .compatible = "aspeed,ast2600-sdram-edac" },
> {},
> };
>
> +MODULE_DEVICE_TABLE(of, aspeed_of_match);
>
> static struct platform_driver aspeed_driver = {
> .driver = {
> @@ -392,5 +395,5 @@ module_platform_driver(aspeed_driver);
>
> MODULE_LICENSE("GPL");
> MODULE_AUTHOR("Stefan Schaeckeler ");
> -MODULE_DESCRIPTION("Aspeed AST2500 EDAC driver");
> +MODULE_DESCRIPTION("Aspeed BMC SoC EDAC driver");
> MODULE_VERSION("1.0");
> --
> 2.17.1
[PATCH 2/2] Input: elantech - Some module tp of tracpoint report has a smbus protocol error.
1. Add the conditional expression to distinguish different patterns regarding
0, 1, 2.
2. Add the function to get or set more bytes from register
3. Get and correct the device informations including ic_type, module id from
different pattern.
4. Add the function to change the report id 0x5F of trackpoint.
5. Some module has a bug which makes default SMBUS trackpoint report 0x5E has a
smbus protocol error.
---
drivers/input/mouse/elantech.c | 128 -
drivers/input/mouse/elantech.h | 4 ++
2 files changed, 131 insertions(+), 1 deletion(-)
diff --git a/drivers/input/mouse/elantech.c b/drivers/input/mouse/elantech.c
index 90f8765f9efc..b3240775ceca 100644
--- a/drivers/input/mouse/elantech.c
+++ b/drivers/input/mouse/elantech.c
@@ -89,6 +89,57 @@ static int elantech_ps2_command(struct psmouse *psmouse,
return rc;
}
+/*
+ * Send an Elantech style special command to read 3 bytes from a register
+ */
+static int elantech_read_reg_params(struct psmouse *psmouse, unsigned char reg,
+unsigned char *param)
+{
+ int rc = 0;
+
+ if (elantech_ps2_command(psmouse, NULL, ETP_PS2_CUSTOM_COMMAND) ||
+ elantech_ps2_command(psmouse, NULL, ETP_REGISTER_READWRITE) ||
+ elantech_ps2_command(psmouse, NULL, ETP_PS2_CUSTOM_COMMAND) ||
+ elantech_ps2_command(psmouse, NULL, reg) ||
+ elantech_ps2_command(psmouse, param, PSMOUSE_CMD_GETINFO)) {
+ rc = -1;
+ }
+
+ if (rc)
+ psmouse_err(psmouse,
+ "failed to read register 0x%02x.\n", reg);
+ return rc;
+}
+
+/*
+ * Send an Elantech style special command to write a register with a parameter
+ */
+static int elantech_write_reg_params(struct psmouse *psmouse, unsigned char
reg,
+ unsigned char *param)
+{
+
+ int rc = 0;
+
+ if (elantech_ps2_command(psmouse, NULL, ETP_PS2_CUSTOM_COMMAND) ||
+ elantech_ps2_command(psmouse, NULL, ETP_REGISTER_READWRITE)
||
+ elantech_ps2_command(psmouse, NULL, ETP_PS2_CUSTOM_COMMAND)
||
+ elantech_ps2_command(psmouse, NULL, reg) ||
+ elantech_ps2_command(psmouse, NULL, ETP_PS2_CUSTOM_COMMAND)
||
+ elantech_ps2_command(psmouse, NULL, param[0]) ||
+ elantech_ps2_command(psmouse, NULL, ETP_PS2_CUSTOM_COMMAND)
||
+ elantech_ps2_command(psmouse, NULL, param[1]) ||
+ elantech_ps2_command(psmouse, NULL,
PSMOUSE_CMD_SETSCALE11)) {
+ rc = -1;
+ }
+
+ if (rc)
+ psmouse_err(psmouse,
+ "failed to write register 0x%02x with value
0x%02x0x%02x.\n",
+ reg, param[0], param[1]);
+ return rc;
+
+}
+
/*
* Send an Elantech style special command to read a value from a register
*/
@@ -1529,6 +1580,27 @@ static const struct dmi_system_id no_hw_res_dmi_table[]
= {
{ }
};
+/*
+ * Change Report id 0x5E to 0x5F.
+ */
+static int elantech_change_report_id(struct psmouse *psmouse)
+{
+ unsigned char param[2] = { 0x10, 0x03 };
+
+ if (elantech_write_reg_params(psmouse, 0x7, param) == 0) {
+ if (elantech_read_reg_params(psmouse, 0x7, param) == 0) {
+ if ((param[0] == 0x10) && (param[1] == 0x03)) {
+ return 0;
+ }
+ psmouse_err(psmouse,
+ "Elantech change report id Fail. (0x%02x, 0x%02x)\n",
+ param[0], param[1]);
+ }
+ }
+ psmouse_err(psmouse,
+ "Elantech change report id Fail.\n");
+ return -1;
+}
/*
* determine hardware version and set some properties according to it.
*/
@@ -1556,6 +1628,18 @@ static int elantech_set_properties(struct
elantech_device_info *info)
return -1;
}
}
+
+
+ /* Get information pattern for hw_version 4 */
+ if (ver == 15) {
+ if ((info->fw_version & 0xff) == 0x01)
+ info->pattern = 0x01;
+ else if ((info->fw_version & 0xff) == 0x02)
+ info->pattern = 0x02;
+ else
+ info->pattern = 0x00;
+ } else
+ info->pattern = 0x00;
/* decide which send_cmd we're gonna use early */
info->send_cmd = info->hw_version >= 3 ? elantech_send_cmd :
@@ -1598,7 +1682,8 @@ static int elantech_query_info(struct psmouse *psmouse,
{
unsigned char param[3];
unsigned char traces;
-
+ unsigned char ic_body[3];
+
memset(info, 0, sizeof(*info));
/*
@@ -1628,6 +1713,21 @@ static int elantech_query_info(struct p
Re: [PATCH v2 0/9] Add support for Microsoft Surface System Aggregator Module
On Mon, Dec 07, 2020 at 09:49:03AM +0100, Hans de Goede wrote: > Note if in the future you do see benefit in switching the auxiliary bus > I have no problems with that. But atm I don't really see any benefits of > doing so, so then we would just be switching over for the sake of switching > over which does not seem productive. I too do not see the benefit at this time to switch either. thanks, greg k-h
[PATCH] module: drop semicolon from version macro
Drop the trailing semicolon from the MODULE_VERSION() macro definition which was left when removing the array-of-pointer indirection. Signed-off-by: Johan Hovold --- include/linux/module.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/module.h b/include/linux/module.h index ebe2641d7b0b..b63db970fd26 100644 --- a/include/linux/module.h +++ b/include/linux/module.h @@ -279,7 +279,7 @@ extern typeof(name) __mod_##type##__##name##_device_table \ }, \ .module_name= KBUILD_MODNAME, \ .version= _version, \ - }; + } #endif /* Optional firmware file (or files) needed by the module -- 2.26.2
Re: [PATCH V3 2/2] thermal: cpufreq_cooling: Reuse sched_cpu_util() for SMP platforms
Hi Valentin, On 01-12-20, 17:25, Valentin Schneider wrote: > PELT time-scaling can make the util signals behave strangely from an > external PoV. For instance, on a big.LITTLE system, the rq util of a LITTLE > CPU may suddenly drop if it was stuck on a too-low OPP for some time and > eventually reached the "right" OPP (i.e. got idle time). > > Also, as Peter pointed out in [1], task migrations can easily confuse an > external observer that considers util to be "an image of the recent past". I agree with what you wrote and such issues may happen here as they can in case of schedutil as well. The idea behind this patchset was to get the allocator (IPA) and consumer (schedutil) in sync with respect to frequency and power. It is better to allocate the power that schedutil is going to request, then to allocate something based on different metrics. If there is a problem with PELT signal then I will let both the entities suffer with that. -- viresh
Re: [PATCH 3/3] exec: Transform exec_update_mutex into a rw_semaphore
On Sat, Dec 05, 2020 at 12:05:32PM -0600, Eric W. Biederman wrote: > I am trying to understand why the permission check is there. It's about observability, is task A allowed to observe state of task B? By installing a perf event on another task, we can very accurately tell what it's doing, and isn't fundamentally different from attaching a debugger (ie. ptrace). Therefore we chose to use the same security checks. As is good custom, one does security checks early. Then Jann came and observed that race against execve mucking with privs, and we got to hold that mutex across lots. That patch I proposed earlier should solve that all.
[RFC PATCH 0/4] Reduce worst-case scanning of runqueues in select_idle_sibling
This is a minimal series to reduce the amount of runqueue scanning in select_idle_sibling in the worst case. Patch 1 removes SIS_AVG_CPU because it's unused. Patch 2 improves the hit rate of p->recent_used_cpu to reduce the amount of scanning. It should be relatively uncontroversial Patch 3-4 scans the runqueues in a single pass for select_idle_core() and select_idle_cpu() so runqueues are not scanned twice. It's a tradeoff because it benefits deep scans but introduces overhead for shallow scans. Even if patch 3-4 is rejected to allow more time for Aubrey's idle cpu mask approach to stand on its own, patches 1-2 should be fine. The main decision with patch 4 is whether select_idle_core() should do a full scan when searching for an idle core, whether it should be throttled in some other fashion or whether it should be just left alone. -- 2.26.2
[PATCH 2/4] sched/fair: Do not replace recent_used_cpu with the new target
After select_idle_sibling, p->recent_used_cpu is set to the
new target. However on the next wakeup, prev will be the same as
recent_used_cpu unless the load balancer has moved the task since the last
wakeup. It still works, but is less efficient than it can be after all
the changes that went in since that reduce unnecessary migrations, load
balancer changes etc. This patch preserves recent_used_cpu for longer.
With tbench on a 2-socket CascadeLake machine, 80 logical CPUs, HT enabled
5.10.0-rc6 5.10.0-rc6
baseline-v2 altrecent-v2
Hmean 1508.39 ( 0.00%) 502.05 * -1.25%*
Hmean 2986.70 ( 0.00%) 983.65 * -0.31%*
Hmean 4 1914.55 ( 0.00%) 1920.24 * 0.30%*
Hmean 8 3702.37 ( 0.00%) 3663.96 * -1.04%*
Hmean 16 6573.11 ( 0.00%) 6545.58 * -0.42%*
Hmean 32 10142.57 ( 0.00%)10253.73 * 1.10%*
Hmean 64 14348.40 ( 0.00%)12506.31 * -12.84%*
Hmean 12821842.59 ( 0.00%)21967.13 * 0.57%*
Hmean 25620813.75 ( 0.00%)21534.52 * 3.46%*
Hmean 32020684.33 ( 0.00%)21070.14 * 1.87%*
The different was marginal except for 64 threads which showed in the
baseline that the result was very unstable where as the patch was much
more stable. This is somewhat machine specific as on a separate 80-cpu
Broadwell machine the same test reported.
5.10.0-rc6 5.10.0-rc6
baseline-v2 altrecent-v2
Hmean 1310.36 ( 0.00%) 291.81 * -5.98%*
Hmean 2340.86 ( 0.00%) 547.22 * 60.54%*
Hmean 4912.29 ( 0.00%) 1063.21 * 16.54%*
Hmean 8 2116.40 ( 0.00%) 2103.60 * -0.60%*
Hmean 16 4232.90 ( 0.00%) 4362.92 * 3.07%*
Hmean 32 8442.03 ( 0.00%) 8642.10 * 2.37%*
Hmean 64 11733.91 ( 0.00%)11473.66 * -2.22%*
Hmean 12817727.24 ( 0.00%)16784.23 * -5.32%*
Hmean 25616089.23 ( 0.00%)16110.79 * 0.13%*
Hmean 32015992.60 ( 0.00%)16071.64 * 0.49%*
schedstats were not used in this series but from an earlier debugging
effort, the schedstats after the test run were as follows;
Ops SIS Search 5653107942.00 5726545742.00
Ops SIS Domain Search3365067916.00 3319768543.00
Ops SIS Scanned112173512543.00 99194352541.00
Ops SIS Domain Scanned 109885472517.00 96787575342.00
Ops SIS Failures 2923185114.00 2950166441.00
Ops SIS Recent Used Hit 56547.00 118064916.00
Ops SIS Recent Used Miss 1590899250.00 354942791.00
Ops SIS Recent Attempts 1590955797.00 473007707.00
Ops SIS Search Efficiency 5.04 5.77
Ops SIS Domain Search Eff 3.06 3.43
Ops SIS Fast Success Rate40.47 42.03
Ops SIS Success Rate 48.29 48.48
Ops SIS Recent Success Rate 0.00 24.96
First interesting point is the ridiculous number of times runqueues are
enabled -- almost 97 billion times over the course of 40 minutes
With the patch, "Recent Used Hit" is over 2000 times more likely to
succeed. The failure rate also increases by quite a lot but the cost is
marginal even if the "Fast Success Rate" only increases by 2% overall. What
cannot be observed from these stats is where the biggest impact as these
stats cover low utilisation to over saturation.
If graphed over time, the graphs show that the sched domain is only
scanned at negligible rates until the machine is fully busy. With
low utilisation, the "Fast Success Rate" is almost 100% until the
machine is fully busy. For 320 clients, the success rate is close to
0% which is unsurprising.
Signed-off-by: Mel Gorman
---
kernel/sched/fair.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 23934dbac635..01b38fc17bca 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -6274,6 +6274,7 @@ static int select_idle_sibling(struct task_struct *p, int
prev, int target)
/* Check a recently used CPU as a potential idle candidate: */
recent_used_cpu = p->recent_used_cpu;
+ p->recent_used_cpu = prev;
if (recent_used_cpu != prev &&
recent_used_cpu != target &&
cpus_share_cache(recent_used_cpu, target) &&
@@ -6765,9 +6766,6 @@ select_task_rq_fair(struct task_struct *p, int prev_cpu,
int wake_flags)
} else if (wake_flags & WF_TTWU) { /* XXX always ? */
/* Fast path */
new_cpu = select_idle_sibling(p, prev_cpu, new_cpu);
-
- if (want_affine)
- current->recent_used_cpu = cpu;
}
rcu_read_unlock();
--
2.26.2
[PATCH] earlycon: drop semicolon from earlycon macro
Drop the trailing semicolon from the OF_EARLYCON_DECLARE() macro
definition which was left when removing the array-of-pointer
indirection.
Signed-off-by: Johan Hovold
---
include/linux/serial_core.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h
index 3e32b788c28d..e1b684e33841 100644
--- a/include/linux/serial_core.h
+++ b/include/linux/serial_core.h
@@ -372,7 +372,7 @@ extern const struct earlycon_id __earlycon_table_end[];
__aligned(__alignof__(struct earlycon_id)) \
= { .name = __stringify(_name), \
.compatible = compat, \
- .setup = fn };
+ .setup = fn }
#define EARLYCON_DECLARE(_name, fn)OF_EARLYCON_DECLARE(_name, "", fn)
--
2.26.2
[PATCH 1/4] sched/fair: Remove SIS_AVG_CPU
SIS_AVG_CPU was introduced as a means of avoiding a search when the
average search cost indicated that the search would likely fail. It
was a blunt instrument and disabled by 4c77b18cf8b7 ("sched/fair: Make
select_idle_cpu() more aggressive") and later replaced with a proportional
search depth by 1ad3aaf3fcd2 ("sched/core: Implement new approach to
scale select_idle_cpu()").
While there are corner cases where SIS_AVG_CPU is better, it has now been
disabled for almost three years. As the intent of SIS_PROP is to reduce
the time complexity of select_idle_cpu(), lets drop SIS_AVG_CPU and focus
on SIS_PROP as a throttling mechanism.
Signed-off-by: Mel Gorman
---
kernel/sched/fair.c | 3 ---
kernel/sched/features.h | 1 -
2 files changed, 4 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 98075f9ea9a8..23934dbac635 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -6161,9 +6161,6 @@ static int select_idle_cpu(struct task_struct *p, struct
sched_domain *sd, int t
avg_idle = this_rq()->avg_idle / 512;
avg_cost = this_sd->avg_scan_cost + 1;
- if (sched_feat(SIS_AVG_CPU) && avg_idle < avg_cost)
- return -1;
-
if (sched_feat(SIS_PROP)) {
u64 span_avg = sd->span_weight * avg_idle;
if (span_avg > 4*avg_cost)
diff --git a/kernel/sched/features.h b/kernel/sched/features.h
index 68d369cba9e4..e875eabb6600 100644
--- a/kernel/sched/features.h
+++ b/kernel/sched/features.h
@@ -54,7 +54,6 @@ SCHED_FEAT(TTWU_QUEUE, true)
/*
* When doing wakeups, attempt to limit superfluous scans of the LLC domain.
*/
-SCHED_FEAT(SIS_AVG_CPU, false)
SCHED_FEAT(SIS_PROP, true)
/*
--
2.26.2
[PATCH 4/4] sched/fair: Avoid revisiting CPUs multiple times during select_idle_sibling
select_idle_core() potentially searches a number of CPUs for idle candidates
before select_idle_cpu() clears the mask and revisits the same CPUs. This
patch moves the initialisation of select_idle_mask to the top-level and
reuses the same mask across both select_idle_core and select_idle_cpu.
select_idle_smt() is left alone as the cost of checking one SMT sibling
is marginal relative to calling __clear_cpumask_cpu() for every CPU
visited by select_idle_core().
With tbench on a 2-socket CascadeLake machine, 80 logical CPUs, HT enabled
5.10.0-rc6 5.10.0-rc6
altrecent-v2 singlepass-v2
Hmean 1502.05 ( 0.00%) 498.53 * -0.70%*
Hmean 2983.65 ( 0.00%) 982.33 * -0.13%*
Hmean 4 1920.24 ( 0.00%) 1929.34 * 0.47%*
Hmean 8 3663.96 ( 0.00%) 3536.94 * -3.47%*
Hmean 16 6545.58 ( 0.00%) 6560.21 * 0.22%*
Hmean 32 10253.73 ( 0.00%)10374.30 * 1.18%*
Hmean 64 12506.31 ( 0.00%)11692.26 * -6.51%*
Hmean 12821967.13 ( 0.00%)21705.80 * -1.19%*
Hmean 25621534.52 ( 0.00%)21223.50 * -1.44%*
Hmean 32021070.14 ( 0.00%)21023.31 * -0.22%*
As before, results are somewhat workload and machine-specific with a mix
of good and bad. For example, netperf UDP_STREAM on an 80-cpu Broadwell
machine shows;
5.10.0-rc6 5.10.0-rc6
altrecent-v2 singlepass-v2
Hmean send-64 232.78 ( 0.00%) 258.02 * 10.85%*
Hmean send-128464.69 ( 0.00%) 511.53 * 10.08%*
Hmean send-256904.72 ( 0.00%) 999.40 * 10.46%*
Hmean send-1024 3512.08 ( 0.00%) 3868.86 * 10.16%*
Hmean send-2048 6777.61 ( 0.00%) 7435.05 * 9.70%*
Hmean send-3312 10352.45 ( 0.00%)11321.43 * 9.36%*
Hmean send-4096 12660.58 ( 0.00%)13577.08 * 7.24%*
Hmean send-8192 19240.36 ( 0.00%)21321.34 * 10.82%*
Hmean send-1638429691.27 ( 0.00%)31296.47 * 5.41%*
The real question is -- is it better to scan CPU runqueues just once
where possible or scan multiple times? This patch scans once but it must
do additional work to track that scanning so for shallow scans it's a
loss and or deep scans, it's a win.
The main downside to this patch is that cpumask manipulations are
more complex because two cpumasks are involved. The alternative is that
select_idle_core() would scan the full domain and always return a CPU which
was previously considered. Alternatively, the depth of select_idle_core()
could be limited. Similarly, select_idle_core() often scans when no idle
core is available as test_idle_cores is very race-prone and maybe there
is a better approach to determining if select_idle_core() is likely to
succeed or not.
Signed-off-by: Mel Gorman
---
kernel/sched/fair.c | 40 +---
1 file changed, 29 insertions(+), 11 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 00c3b526a5bd..3b1736dc5bde 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -6064,10 +6064,11 @@ void __update_idle_core(struct rq *rq)
* there are no idle cores left in the system; tracked through
* sd_llc->shared->has_idle_cores and enabled through update_idle_core() above.
*/
-static int select_idle_core(struct task_struct *p, struct sched_domain *sd,
int target)
+static int select_idle_core(struct task_struct *p, struct sched_domain *sd,
+ int target, struct cpumask *cpus_scan)
{
int idle_candidate = -1;
- struct cpumask *cpus = this_cpu_cpumask_var_ptr(select_idle_mask);
+ struct cpumask *cpus;
int core, cpu;
if (!static_branch_likely(&sched_smt_present))
@@ -6076,12 +6077,21 @@ static int select_idle_core(struct task_struct *p,
struct sched_domain *sd, int
if (!test_idle_cores(target, false))
return -1;
- cpumask_and(cpus, sched_domain_span(sd), p->cpus_ptr);
+ /*
+* Repurpose load_balance_mask to avoid rescanning cores while
+* cpus_scan tracks the cpu if select_idle_cpu() is necessary.
+* In this context, it should be impossible to enter LB and
+* clobber load_balance_mask.
+*/
+ cpus = this_cpu_cpumask_var_ptr(load_balance_mask);
+ cpumask_copy(cpus, cpus_scan);
for_each_cpu_wrap(core, cpus, target) {
bool idle = true;
for_each_cpu(cpu, cpu_smt_mask(core)) {
+ __cpumask_clear_cpu(cpu, cpus_scan);
+
if (!available_idle_cpu(cpu)) {
idle = false;
break;
@@ -6130,7 +6140,8 @@ static int select_idle_smt(struct task_struct *p, struct
sched_domain *sd, int t
#else /* CONFIG_SCHED_SMT
Re: [PATCH v3 3/3] iio:Documentation: Add documentation for hinge sensor channels
Hi Jonathan Thanks for review and comments. On Sat, Dec 05, 2020 at 04:05:40PM +, Jonathan Cameron wrote: > On Thu, 3 Dec 2020 11:53:52 +0800 > Ye Xiang wrote: > > > Add channel description for hinge sensor, including channel label > > attribute and raw data description. > > > > Signed-off-by: Ye Xiang > > --- > > Documentation/ABI/testing/sysfs-bus-iio | 17 + > > 1 file changed, 17 insertions(+) > > > > diff --git a/Documentation/ABI/testing/sysfs-bus-iio > > b/Documentation/ABI/testing/sysfs-bus-iio > > index df42bed09f25..82303b1bdff0 100644 > > --- a/Documentation/ABI/testing/sysfs-bus-iio > > +++ b/Documentation/ABI/testing/sysfs-bus-iio > > @@ -1802,3 +1802,20 @@ Contact: linux-...@vger.kernel.org > > Description: > > Unscaled light intensity according to CIE 1931/DIN 5033 color > > space. > > Units after application of scale are nano nanowatts per square > > meter. > > + > > +What: /sys/bus/iio/devices/iio:deviceX/in_anglY_raw > > +KernelVersion: 5.12 > > +Contact: linux-...@vger.kernel.org > > +Description: > > + Angle of rotation for channel Y. Units after application of > > scale > > + and offset are radians. > > This entry is already mostly in the doc around line 200, just without the > index. > Please just add the What: line to that block to reduce repetition. > If you want to add... "Where present, Y indexes the channel." or something > like > that feel free. When adding in_anglY_raw to in_angl_raw block, Should I update the KernelVersion form 4.17 to 5.12? Like blow: What: /sys/bus/iio/devices/iio:deviceX/in_angl_raw What: /sys/bus/iio/devices/iio:deviceX/in_anglY_raw KernelVersion: 5.12 Contact:linux-...@vger.kernel.org Description: Angle of rotation. Units after application of scale and offset are radians. Where present, Y indexes the channel. > > > > + > > +What: /sys/bus/iio/devices/iio:deviceX/in_anglY_label > > +KernelVersion: 5.12 > > +Contact: linux-...@vger.kernel.org > > +Description: > > + Optional symbolic label for channel Y. > > + For Intel hid hinge sensor, the label values are: > > + hinge, keyboard, screen. It means the three channels > > + each correspond respectively to hinge angle, keyboard angle, > > + and screen angle. > > Makes sense to keep this block separate given the additional info provided. > Alternative would be to add it to the one with in_voltageY_label which would > be odd given what follows! Ok, Then I will keep the in_anglY_label block here. BTW, I didnot see in_voltageY_label in sysfs-bus-iio in current kernel master branch. > > Thanks, > > Jonathan > Thanks Ye, Xiang >
Re: [PATCH 0/4] dt-bindings: media: eliminate yamllint warnings
On 2020/12/7 17:08, Jacopo Mondi wrote: > Hi Zhen, > > On Mon, Dec 07, 2020 at 12:23:56PM +0800, Zhen Lei wrote: >> These patches are based on the latest linux-next code. >> >> Zhen Lei (4): >> dt-bindings: media: adv7604: eliminate yamllint warnings >> dt-bindings: media: nokia,smia: eliminate yamllint warnings >> dt-bindings: media: ov772x: eliminate yamllint warnings >> dt-bindings: media: imx214: eliminate yamllint warnings > > The adv7604, ov772x and imx214 bits have been addressed by: > https://www.spinics.net/lists/linux-media/msg181093.html OK > > Thanks > j > >> >> Documentation/devicetree/bindings/media/i2c/adv7604.yaml | 4 ++-- >> Documentation/devicetree/bindings/media/i2c/mipi-ccs.yaml| 11 >> ++- >> Documentation/devicetree/bindings/media/i2c/ovti,ov772x.yaml | 12 >> ++-- >> Documentation/devicetree/bindings/media/i2c/sony,imx214.yaml | 12 >> ++-- >> 4 files changed, 20 insertions(+), 19 deletions(-) >> >> -- >> 1.8.3 >> >> > > . >
[PATCH V2 1/3] cpufreq: sun50i: add efuse_xlate to get efuse version.
It's better to use efuse_xlate to extract the differentiated part
regarding different SoC.
Signed-off-by: Shuosheng Huang
---
drivers/cpufreq/sun50i-cpufreq-nvmem.c | 72 +-
1 file changed, 48 insertions(+), 24 deletions(-)
diff --git a/drivers/cpufreq/sun50i-cpufreq-nvmem.c
b/drivers/cpufreq/sun50i-cpufreq-nvmem.c
index 9907a165135b..da23d581a4b4 100644
--- a/drivers/cpufreq/sun50i-cpufreq-nvmem.c
+++ b/drivers/cpufreq/sun50i-cpufreq-nvmem.c
@@ -22,21 +22,52 @@
#define NVMEM_MASK 0x7
#define NVMEM_SHIFT5
+#define SUN50I_H6_NVMEM_MASK 0x7
+#define SUN50I_H6_NVMEM_SHIFT 5
+
+struct sunxi_cpufreq_soc_data {
+ u32 (*efuse_xlate)(void *efuse);
+};
+
static struct platform_device *cpufreq_dt_pdev, *sun50i_cpufreq_pdev;
+static u32 sun50i_h6_efuse_xlate(struct nvmem_cell *speedbin_nvmem)
+{
+ size_t len;
+ u32 *speedbin;
+ u32 efuse_value;
+
+ speedbin = nvmem_cell_read(speedbin_nvmem, &len);
+ if (IS_ERR(speedbin))
+ return PTR_ERR(speedbin);
+
+ efuse_value = (*(u32 *)speedbin >> SUN50I_H6_NVMEM_SHIFT) &
+ SUN50I_H6_NVMEM_MASK;
+ kfree(speedbin);
+ /*
+* We treat unexpected efuse values as if the SoC was from
+* the slowest bin. Expected efuse values are 1-3, slowest
+* to fastest.
+*/
+ if (efuse_value >= 1 && efuse_value <= 3)
+ return efuse_value - 1;
+ else
+ return 0;
+}
+
/**
* sun50i_cpufreq_get_efuse() - Determine speed grade from efuse value
+ * @soc_data: pointer to sunxi_cpufreq_soc_data context
* @versions: Set to the value parsed from efuse
*
* Returns 0 if success.
*/
-static int sun50i_cpufreq_get_efuse(u32 *versions)
+static int sun50i_cpufreq_get_efuse(const struct sunxi_cpufreq_soc_data
*soc_data,
+ u32 *versions)
{
struct nvmem_cell *speedbin_nvmem;
struct device_node *np;
struct device *cpu_dev;
- u32 *speedbin, efuse_value;
- size_t len;
int ret;
cpu_dev = get_cpu_device(0);
@@ -63,41 +94,31 @@ static int sun50i_cpufreq_get_efuse(u32 *versions)
return PTR_ERR(speedbin_nvmem);
}
- speedbin = nvmem_cell_read(speedbin_nvmem, &len);
+ *versions = soc_data->efuse_xlate(speedbin_nvmem);
nvmem_cell_put(speedbin_nvmem);
- if (IS_ERR(speedbin))
- return PTR_ERR(speedbin);
-
- efuse_value = (*speedbin >> NVMEM_SHIFT) & NVMEM_MASK;
-
- /*
-* We treat unexpected efuse values as if the SoC was from
-* the slowest bin. Expected efuse values are 1-3, slowest
-* to fastest.
-*/
- if (efuse_value >= 1 && efuse_value <= 3)
- *versions = efuse_value - 1;
- else
- *versions = 0;
- kfree(speedbin);
return 0;
};
static int sun50i_cpufreq_nvmem_probe(struct platform_device *pdev)
{
+ const struct of_device_id *match;
struct opp_table **opp_tables;
char name[MAX_NAME_LEN];
unsigned int cpu;
u32 speed = 0;
int ret;
+ match = dev_get_platdata(&pdev->dev);
+ if (!match)
+ return -EINVAL;
+
opp_tables = kcalloc(num_possible_cpus(), sizeof(*opp_tables),
GFP_KERNEL);
if (!opp_tables)
return -ENOMEM;
- ret = sun50i_cpufreq_get_efuse(&speed);
+ ret = sun50i_cpufreq_get_efuse(match->data, &speed);
if (ret)
return ret;
@@ -163,8 +184,12 @@ static struct platform_driver sun50i_cpufreq_driver = {
},
};
+static const struct sunxi_cpufreq_soc_data sun50i_h6_data = {
+ .efuse_xlate = sun50i_h6_efuse_xlate,
+};
+
static const struct of_device_id sun50i_cpufreq_match_list[] = {
- { .compatible = "allwinner,sun50i-h6" },
+ { .compatible = "allwinner,sun50i-h6", .data = &sun50i_h6_data },
{}
};
@@ -198,9 +223,8 @@ static int __init sun50i_cpufreq_init(void)
if (unlikely(ret < 0))
return ret;
- sun50i_cpufreq_pdev =
- platform_device_register_simple("sun50i-cpufreq-nvmem",
- -1, NULL, 0);
+ sun50i_cpufreq_pdev = platform_device_register_data(NULL,
+ "sun50i-cpufreq-nvmem", -1, match, sizeof(*match));
ret = PTR_ERR_OR_ZERO(sun50i_cpufreq_pdev);
if (ret == 0)
return 0;
--
2.28.0
[PATCH 3/4] sched/fair: Return an idle cpu if one is found after a failed search for an idle core
select_idle_core is called when SMT is active and there is likely a free
core available. It may find idle CPUs but this information is simply
discarded and the scan starts over again with select_idle_cpu.
This patch caches information on idle CPUs found during the search for
a core and uses one if no core is found. This is a tradeoff. There may
be a slight impact when utilisation is low and an idle core can be
found quickly. It provides improvements as the number of busy CPUs
approaches 50% of the domain size when SMT is enabled.
With tbench on a 2-socket CascadeLake machine, 80 logical CPUs, HT enabled
5.10.0-rc6 5.10.0-rc6
schedstat idlecandidate
Hmean 1500.06 ( 0.00%) 505.67 * 1.12%*
Hmean 2975.90 ( 0.00%) 974.06 * -0.19%*
Hmean 4 1902.95 ( 0.00%) 1904.43 * 0.08%*
Hmean 8 3761.73 ( 0.00%) 3721.02 * -1.08%*
Hmean 16 6713.93 ( 0.00%) 6769.17 * 0.82%*
Hmean 32 10435.31 ( 0.00%)10312.58 * -1.18%*
Hmean 64 12325.51 ( 0.00%)13792.01 * 11.90%*
Hmean 12821225.21 ( 0.00%)20963.44 * -1.23%*
Hmean 25620532.83 ( 0.00%)20335.62 * -0.96%*
Hmean 32020334.81 ( 0.00%)20147.25 * -0.92%*
Note that there is a significant corner case. As the SMT scan may be
terminated early, not all CPUs have been visited and select_idle_cpu()
is still called for a full scan. This case is handled in the next
patch.
Signed-off-by: Mel Gorman
---
kernel/sched/fair.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 01b38fc17bca..00c3b526a5bd 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -6066,6 +6066,7 @@ void __update_idle_core(struct rq *rq)
*/
static int select_idle_core(struct task_struct *p, struct sched_domain *sd,
int target)
{
+ int idle_candidate = -1;
struct cpumask *cpus = this_cpu_cpumask_var_ptr(select_idle_mask);
int core, cpu;
@@ -6085,6 +6086,11 @@ static int select_idle_core(struct task_struct *p,
struct sched_domain *sd, int
idle = false;
break;
}
+
+ if (idle_candidate == -1 &&
+ cpumask_test_cpu(cpu, p->cpus_ptr)) {
+ idle_candidate = cpu;
+ }
}
if (idle)
@@ -6098,7 +6104,7 @@ static int select_idle_core(struct task_struct *p, struct
sched_domain *sd, int
*/
set_idle_cores(target, 0);
- return -1;
+ return idle_candidate;
}
/*
--
2.26.2
[PATCH] iommu/amd: Set DTE[IntTabLen] to represent 512 IRTEs
According to the AMD IOMMU spec, the commit 73db2fc595f3
("iommu/amd: Increase interrupt remapping table limit to 512 entries")
also requires the interrupt table length (IntTabLen) to be set to 9
(power of 2) in the device table mapping entry (DTE).
Fixes: 73db2fc595f3 ("iommu/amd: Increase interrupt remapping table limit to
512 entries")
Reported-by: Jerry Snitselaar
Signed-off-by: Suravee Suthikulpanit
---
drivers/iommu/amd/amd_iommu_types.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/amd/amd_iommu_types.h
b/drivers/iommu/amd/amd_iommu_types.h
index 89647700bab2..494b42a31b7a 100644
--- a/drivers/iommu/amd/amd_iommu_types.h
+++ b/drivers/iommu/amd/amd_iommu_types.h
@@ -257,7 +257,7 @@
#define DTE_IRQ_REMAP_INTCTL_MASK (0x3ULL << 60)
#define DTE_IRQ_TABLE_LEN_MASK (0xfULL << 1)
#define DTE_IRQ_REMAP_INTCTL(2ULL << 60)
-#define DTE_IRQ_TABLE_LEN (8ULL << 1)
+#define DTE_IRQ_TABLE_LEN (9ULL << 1)
#define DTE_IRQ_REMAP_ENABLE1ULL
#define PAGE_MODE_NONE0x00
--
2.17.1
[PATCH V2 3/3] arm64: dts: allwinner: a100: Add CPU Operating Performance Points table
Add an Operating Performance Points table for the CPU cores to
enable Dynamic Voltage & Frequency Scaling on the A100.
Signed-off-by: Shuosheng Huang
---
.../allwinner/sun50i-a100-allwinner-perf1.dts | 5 ++
.../dts/allwinner/sun50i-a100-cpu-opp.dtsi| 90 +++
.../arm64/boot/dts/allwinner/sun50i-a100.dtsi | 8 ++
3 files changed, 103 insertions(+)
create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a100-cpu-opp.dtsi
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a100-allwinner-perf1.dts
b/arch/arm64/boot/dts/allwinner/sun50i-a100-allwinner-perf1.dts
index d34c2bb1079f..7c579923f973 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a100-allwinner-perf1.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a100-allwinner-perf1.dts
@@ -6,6 +6,7 @@
/dts-v1/;
#include "sun50i-a100.dtsi"
+#include "sun50i-a100-cpu-opp.dtsi"
/{
model = "Allwinner A100 Perf1";
@@ -20,6 +21,10 @@ chosen {
};
};
+&cpu0 {
+ cpu-supply = <®_dcdc2>;
+};
+
&pio {
vcc-pb-supply = <®_dcdc1>;
vcc-pc-supply = <®_eldo1>;
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a100-cpu-opp.dtsi
b/arch/arm64/boot/dts/allwinner/sun50i-a100-cpu-opp.dtsi
new file mode 100644
index ..e245823d70e8
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a100-cpu-opp.dtsi
@@ -0,0 +1,90 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+// Copyright (c) 2020 Yangtao Li
+// Copyright (c) 2020 ShuoSheng Huang
+
+/ {
+ cpu_opp_table: cpu-opp-table {
+ compatible = "allwinner,sun50i-h6-operating-points";
+ nvmem-cells = <&cpu_speed_grade>;
+ opp-shared;
+
+ opp@40800 {
+ clock-latency-ns = <244144>; /* 8 32k periods */
+ opp-hz = /bits/ 64 <40800>;
+
+ opp-microvolt-speed0 = <90 90 120>;
+ opp-microvolt-speed1 = <90 90 120>;
+ opp-microvolt-speed2 = <90 90 120>;
+ };
+
+ opp@6 {
+ clock-latency-ns = <244144>; /* 8 32k periods */
+ opp-hz = /bits/ 64 <6>;
+
+ opp-microvolt-speed0 = <90 90 120>;
+ opp-microvolt-speed1 = <90 90 120>;
+ opp-microvolt-speed2 = <90 90 120>;
+ };
+
+ opp@81600 {
+ clock-latency-ns = <244144>; /* 8 32k periods */
+ opp-hz = /bits/ 64 <81600>;
+
+ opp-microvolt-speed0 = <94 94 120>;
+ opp-microvolt-speed1 = <90 90 120>;
+ opp-microvolt-speed2 = <90 90 120>;
+ };
+
+ opp@108000 {
+ clock-latency-ns = <244144>; /* 8 32k periods */
+ opp-hz = /bits/ 64 <108000>;
+
+ opp-microvolt-speed0 = <102 102 120>;
+ opp-microvolt-speed1 = <98 98 120>;
+ opp-microvolt-speed2 = <95 95 120>;
+ };
+
+ opp@12 {
+ clock-latency-ns = <244144>; /* 8 32k periods */
+ opp-hz = /bits/ 64 <12>;
+
+ opp-microvolt-speed0 = <110 110 120>;
+ opp-microvolt-speed1 = <102 102 120>;
+ opp-microvolt-speed2 = <100 100 120>;
+ };
+
+ opp@132000 {
+ clock-latency-ns = <244144>; /* 8 32k periods */
+ opp-hz = /bits/ 64 <132000>;
+
+ opp-microvolt-speed0 = <116 116 120>;
+ opp-microvolt-speed1 = <106 106 120>;
+ opp-microvolt-speed2 = <103 103 120>;
+ };
+
+ opp@146400 {
+ clock-latency-ns = <244144>; /* 8 32k periods */
+ opp-hz = /bits/ 64 <146400>;
+
+ opp-microvolt-speed0 = <118 118 120>;
+ opp-microvolt-speed1 = <118 118 120>;
+ opp-microvolt-speed2 = <113 113 120>;
+ };
+ };
+};
+
+&cpu0 {
+ operating-points-v2 = <&cpu_opp_table>;
+};
+
+&cpu1 {
+ operating-points-v2 = <&cpu_opp_table>;
+};
+
+&cpu2 {
+ operating-points-v2 = <&cpu_opp_table>;
+};
+
+&cpu3 {
+ operating-points-v2 = <&cpu_opp_table>;
+};
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi
b/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi
index cc321c04f121..8f370a175ce6 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi
+++ b/arch/arm64/boot/dts/allwinner/s
[PATCH V2 2/3] cpufreq: sun50i: add a100 cpufreq support
Add cpufreq nvmem based for allwinner a100 SoC, it's similar to h6.
Signed-off-by: Shuosheng Huang
---
drivers/cpufreq/cpufreq-dt-platdev.c | 1 +
drivers/cpufreq/sun50i-cpufreq-nvmem.c | 32 ++
2 files changed, 33 insertions(+)
diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c
b/drivers/cpufreq/cpufreq-dt-platdev.c
index 3776d960f405..2ebf5d9cb616 100644
--- a/drivers/cpufreq/cpufreq-dt-platdev.c
+++ b/drivers/cpufreq/cpufreq-dt-platdev.c
@@ -102,6 +102,7 @@ static const struct of_device_id whitelist[] __initconst = {
*/
static const struct of_device_id blacklist[] __initconst = {
{ .compatible = "allwinner,sun50i-h6", },
+ { .compatible = "allwinner,sun50i-a100", },
{ .compatible = "calxeda,highbank", },
{ .compatible = "calxeda,ecx-2000", },
diff --git a/drivers/cpufreq/sun50i-cpufreq-nvmem.c
b/drivers/cpufreq/sun50i-cpufreq-nvmem.c
index da23d581a4b4..def4a19abe16 100644
--- a/drivers/cpufreq/sun50i-cpufreq-nvmem.c
+++ b/drivers/cpufreq/sun50i-cpufreq-nvmem.c
@@ -25,6 +25,9 @@
#define SUN50I_H6_NVMEM_MASK 0x7
#define SUN50I_H6_NVMEM_SHIFT 5
+#define SUN50I_A100_NVMEM_MASK 0xf
+#define SUN50I_A100_NVMEM_SHIFT12
+
struct sunxi_cpufreq_soc_data {
u32 (*efuse_xlate)(void *efuse);
};
@@ -55,6 +58,30 @@ static u32 sun50i_h6_efuse_xlate(struct nvmem_cell
*speedbin_nvmem)
return 0;
}
+static u32 sun50i_a100_efuse_xlate(struct nvmem_cell *speedbin_nvmem)
+{
+ size_t len;
+ u32 *speedbin;
+ u32 efuse_value;
+
+ speedbin = nvmem_cell_read(speedbin_nvmem, &len);
+ if (IS_ERR(speedbin))
+ return PTR_ERR(speedbin);
+
+ efuse_value = (*(u16 *)efuse >> SUN50I_A100_NVMEM_SHIFT) &
+ SUN50I_A100_NVMEM_MASK;
+ kfree(speedbin);
+
+ switch (efuse_value) {
+ case 0b100:
+ return 2;
+ case 0b010:
+ return 1;
+ default:
+ return 0;
+ }
+}
+
/**
* sun50i_cpufreq_get_efuse() - Determine speed grade from efuse value
* @soc_data: pointer to sunxi_cpufreq_soc_data context
@@ -188,8 +215,13 @@ static const struct sunxi_cpufreq_soc_data sun50i_h6_data
= {
.efuse_xlate = sun50i_h6_efuse_xlate,
};
+static const struct sunxi_cpufreq_soc_data sun50i_a100_data = {
+ .efuse_xlate = sun50i_a100_efuse_xlate,
+};
+
static const struct of_device_id sun50i_cpufreq_match_list[] = {
{ .compatible = "allwinner,sun50i-h6", .data = &sun50i_h6_data },
+ { .compatible = "allwinner,sun50i-a100", .data = &sun50i_a100_data },
{}
};
--
2.28.0
[PATCH 0/3] Add sound card support for imx8mn-evk board
Support wm8524 and spdif sound card. Shengjiu Wang (3): arm64: dts: imx8mn: Configure clock rate for audio plls arm64: dts: imx8mn-evk: Add sound-wm8524 card nodes arm64: dts: imx8mn-evk: Add sound-spdif card nodes arch/arm64/boot/dts/freescale/imx8mn-evk.dtsi | 75 +++ arch/arm64/boot/dts/freescale/imx8mn.dtsi | 8 +- 2 files changed, 81 insertions(+), 2 deletions(-) -- 2.27.0
[PATCH 2/3] arm64: dts: imx8mn-evk: Add sound-wm8524 card nodes
Add sound-wm8524 card nodes which are supported on imx8mn-evk board.
Signed-off-by: Shengjiu Wang
---
arch/arm64/boot/dts/freescale/imx8mn-evk.dtsi | 51 +++
1 file changed, 51 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mn-evk.dtsi
b/arch/arm64/boot/dts/freescale/imx8mn-evk.dtsi
index 76d042a4cf09..1d2c399eabea 100644
--- a/arch/arm64/boot/dts/freescale/imx8mn-evk.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mn-evk.dtsi
@@ -46,6 +46,32 @@ ir-receiver {
pinctrl-0 = <&pinctrl_ir>;
linux,autosuspend-period = <125>;
};
+
+ wm8524: audio-codec {
+ #sound-dai-cells = <0>;
+ compatible = "wlf,wm8524";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpio_wlf>;
+ wlf,mute-gpios = <&gpio5 21 GPIO_ACTIVE_LOW>;
+ clocks = <&clk IMX8MN_CLK_SAI3_ROOT>;
+ clock-names = "mclk";
+ };
+
+ sound-wm8524 {
+ compatible = "fsl,imx-audio-wm8524";
+ model = "wm8524-audio";
+ audio-cpu = <&sai3>;
+ audio-codec = <&wm8524>;
+ audio-asrc = <&easrc>;
+ audio-routing =
+ "Line Out Jack", "LINEVOUTL",
+ "Line Out Jack", "LINEVOUTR";
+ };
+};
+
+&easrc {
+ fsl,asrc-rate = <48000>;
+ status = "okay";
};
&fec1 {
@@ -124,6 +150,16 @@ pca6416: gpio@20 {
};
};
+&sai3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_sai3>;
+ assigned-clocks = <&clk IMX8MN_CLK_SAI3>;
+ assigned-clock-parents = <&clk IMX8MN_AUDIO_PLL1_OUT>;
+ assigned-clock-rates = <24576000>;
+ fsl,sai-mclk-direction-output;
+ status = "okay";
+};
+
&snvs_pwrkey {
status = "okay";
};
@@ -210,6 +246,12 @@ MX8MN_IOMUXC_NAND_READY_B_GPIO3_IO16 0x19
>;
};
+ pinctrl_gpio_wlf: gpiowlfgrp {
+ fsl,pins = <
+ MX8MN_IOMUXC_I2C4_SDA_GPIO5_IO210xd6
+ >;
+ };
+
pinctrl_ir: irgrp {
fsl,pins = <
MX8MN_IOMUXC_GPIO1_IO13_GPIO1_IO13 0x4f
@@ -249,6 +291,15 @@ MX8MN_IOMUXC_SD2_RESET_B_GPIO2_IO190x41
>;
};
+ pinctrl_sai3: sai3grp {
+ fsl,pins = <
+ MX8MN_IOMUXC_SAI3_TXFS_SAI3_TX_SYNC 0xd6
+ MX8MN_IOMUXC_SAI3_TXC_SAI3_TX_BCLK 0xd6
+ MX8MN_IOMUXC_SAI3_MCLK_SAI3_MCLK0xd6
+ MX8MN_IOMUXC_SAI3_TXD_SAI3_TX_DATA0 0xd6
+ >;
+ };
+
pinctrl_typec1: typec1grp {
fsl,pins = <
MX8MN_IOMUXC_SD1_STROBE_GPIO2_IO11 0x159
--
2.27.0
[PATCH 1/3] arm64: dts: imx8mn: Configure clock rate for audio plls
Configure clock rate for audio plls. audio pll1 is used
as parent clock for clocks that is multiple of 8kHz.
audio pll2 is used as parent clock for clocks that is
multiple of 11kHz.
Signed-off-by: Shengjiu Wang
---
arch/arm64/boot/dts/freescale/imx8mn.dtsi | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mn.dtsi
b/arch/arm64/boot/dts/freescale/imx8mn.dtsi
index e35182ff6f59..439cf6ca3114 100644
--- a/arch/arm64/boot/dts/freescale/imx8mn.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mn.dtsi
@@ -581,7 +581,9 @@ clk: clock-controller@3038 {
<&clk IMX8MN_CLK_NOC>,
<&clk IMX8MN_CLK_AUDIO_AHB>,
<&clk
IMX8MN_CLK_IPG_AUDIO_ROOT>,
- <&clk IMX8MN_SYS_PLL3>;
+ <&clk IMX8MN_SYS_PLL3>,
+ <&clk IMX8MN_AUDIO_PLL1>,
+ <&clk IMX8MN_AUDIO_PLL2>;
assigned-clock-parents = <&clk
IMX8MN_SYS_PLL1_800M>,
<&clk
IMX8MN_ARM_PLL_OUT>,
<&clk
IMX8MN_SYS_PLL3_OUT>,
@@ -589,7 +591,9 @@ clk: clock-controller@3038 {
assigned-clock-rates = <0>, <0>, <0>,
<4>,
<4>,
- <6>;
+ <6>,
+ <393216000>,
+ <361267200>;
};
src: reset-controller@3039 {
--
2.27.0
[PATCH 3/3] arm64: dts: imx8mn-evk: Add sound-spdif card nodes
Add sound-spdif card nodes which are supported on imx8mn-evk board.
Signed-off-by: Shengjiu Wang
---
arch/arm64/boot/dts/freescale/imx8mn-evk.dtsi | 24 +++
1 file changed, 24 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mn-evk.dtsi
b/arch/arm64/boot/dts/freescale/imx8mn-evk.dtsi
index 1d2c399eabea..a0dddba2e561 100644
--- a/arch/arm64/boot/dts/freescale/imx8mn-evk.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mn-evk.dtsi
@@ -67,6 +67,14 @@ sound-wm8524 {
"Line Out Jack", "LINEVOUTL",
"Line Out Jack", "LINEVOUTR";
};
+
+ sound-spdif {
+ compatible = "fsl,imx-audio-spdif";
+ model = "imx-spdif";
+ spdif-controller = <&spdif1>;
+ spdif-out;
+ spdif-in;
+ };
};
&easrc {
@@ -164,6 +172,15 @@ &snvs_pwrkey {
status = "okay";
};
+&spdif1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_spdif1>;
+ assigned-clocks = <&clk IMX8MN_CLK_SPDIF1>;
+ assigned-clock-parents = <&clk IMX8MN_AUDIO_PLL1_OUT>;
+ assigned-clock-rates = <24576000>;
+ status = "okay";
+};
+
&uart2 { /* console */
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_uart2>;
@@ -300,6 +317,13 @@ MX8MN_IOMUXC_SAI3_TXD_SAI3_TX_DATA0 0xd6
>;
};
+ pinctrl_spdif1: spdif1grp {
+ fsl,pins = <
+ MX8MN_IOMUXC_SPDIF_TX_SPDIF1_OUT0xd6
+ MX8MN_IOMUXC_SPDIF_RX_SPDIF1_IN 0xd6
+ >;
+ };
+
pinctrl_typec1: typec1grp {
fsl,pins = <
MX8MN_IOMUXC_SD1_STROBE_GPIO2_IO11 0x159
--
2.27.0
Re: Fair Pay: Some interesting observations of symboldevelopment, Uni / I-T
I'm sorry, SINU it may be. Having disassociated the christian god, we can clearly see it is mad, and in the way of correct commerciality. It is a parasite, who is never pleased, who never stops craving perfection, yet is never happy. I-T Clan X, answers this, and takes the logical conclusion on 30 years, being a finalized concept of all that fits. Den 06.12.2020 16:23, skrev Ywe Cærlyn: I also suggest the singular form La Dyas, for related languages. https://youtu.be/V4HVLWoUnl4 Den 03.12.2020 21:37, skrev Ywe Cærlyn: For people interested in subconscious interaction and symboldevelopment (which is a great part of business and related psychology), one should know that Uni is a minimal state zén symbol, compatible with Islam and science, and is idolaterous culture, corrected as school. Basically stating there is no christian god, and that is what being educated means. The later symbol I-T, is also a minimal state zén symbol, compatible with Islam, and science, and is idolaterous culture rejected. And the christian god, almost conquered, stating it should be corrected to a general term, such as one Guad. And that again needs to point to the correct one. Zén is a general teaching stating that egolessness is to be obtained. One has discussed egocults, and if "Linux" is an undesired cultic symbol. The best here might ofcourse be I-T Clan X, referring all developers instead. Which also is a symbol stating a full philosophy is needed. Not just the Batin (subconscious / deep zén), but also the Zahir (conscious), and thus Islam. And also that the left-to-right "Allah" symbol in arabic script, may be SINO in latin script. Indeed an interesting development, and hope for fair pay political unity in east and west. Serenity! Ywe Cærlyn Fair Pay Initiativetaker. https://www.youtube.com/channel/UCR3gmLVjHS5A702wo4bol_Q
Re: [PATCH v2 1/3] v4l: Add HDR10 static metadata controls
On 07/12/2020 10:06, Stanimir Varbanov wrote:
>
>
> On 12/2/20 1:12 PM, Hans Verkuil wrote:
>> On 24/11/2020 00:02, Stanimir Varbanov wrote:
>>> Add Content light level and Mastering display colour volume v4l2
>>> compounf controls, relevant payload structures and validation.
>>
>> compounf -> compound
>>
>>>
>>> Signed-off-by: Stanimir Varbanov
>>> ---
>>> drivers/media/v4l2-core/v4l2-ctrls.c | 62
>>> include/media/hdr10-ctrls.h | 55
>>> include/media/v4l2-ctrls.h | 3 ++
>>> 3 files changed, 120 insertions(+)
>>> create mode 100644 include/media/hdr10-ctrls.h
>>>
>>> diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
>>> b/drivers/media/v4l2-core/v4l2-ctrls.c
>>> index ad47d00e28d6..028630576401 100644
>>> --- a/drivers/media/v4l2-core/v4l2-ctrls.c
>>> +++ b/drivers/media/v4l2-core/v4l2-ctrls.c
>>> @@ -1024,6 +1024,9 @@ const char *v4l2_ctrl_get_name(u32 id)
>>> case V4L2_CID_MPEG_VIDEO_HEVC_DECODE_MODE: return "HEVC
>>> Decode Mode";
>>> case V4L2_CID_MPEG_VIDEO_HEVC_START_CODE: return "HEVC
>>> Start Code";
>>>
>>> + case V4L2_CID_MPEG_VIDEO_HDR10_CLL_INFO:return "HDR10
>>> Content Light Info";
>>> + case V4L2_CID_MPEG_VIDEO_HDR10_MASTERING_DISPLAY: return "HDR10
>>> Mastering Display";
>>> +
>>> /* CAMERA controls */
>>> /* Keep the order of the 'case's the same as in v4l2-controls.h! */
>>> case V4L2_CID_CAMERA_CLASS: return "Camera Controls";
>>> @@ -1461,6 +1464,12 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
>>> v4l2_ctrl_type *type,
>>> case V4L2_CID_MPEG_VIDEO_HEVC_SLICE_PARAMS:
>>> *type = V4L2_CTRL_TYPE_HEVC_SLICE_PARAMS;
>>> break;
>>> + case V4L2_CID_MPEG_VIDEO_HDR10_CLL_INFO:
>>> + *type = V4L2_CTRL_TYPE_HDR10_CLL_INFO;
>>> + break;
>>> + case V4L2_CID_MPEG_VIDEO_HDR10_MASTERING_DISPLAY:
>>> + *type = V4L2_CTRL_TYPE_HDR10_MASTERING_DISPLAY;
>>> + break;
>>> case V4L2_CID_UNIT_CELL_SIZE:
>>> *type = V4L2_CTRL_TYPE_AREA;
>>> *flags |= V4L2_CTRL_FLAG_READ_ONLY;
>>> @@ -1775,6 +1784,7 @@ static int std_validate_compound(const struct
>>> v4l2_ctrl *ctrl, u32 idx,
>>> struct v4l2_ctrl_hevc_sps *p_hevc_sps;
>>> struct v4l2_ctrl_hevc_pps *p_hevc_pps;
>>> struct v4l2_ctrl_hevc_slice_params *p_hevc_slice_params;
>>> + struct v4l2_ctrl_hdr10_mastering_display *p_hdr10_mastering;
>>> struct v4l2_area *area;
>>> void *p = ptr.p + idx * ctrl->elem_size;
>>> unsigned int i;
>>> @@ -1934,6 +1944,52 @@ static int std_validate_compound(const struct
>>> v4l2_ctrl *ctrl, u32 idx,
>>> zero_padding(*p_hevc_slice_params);
>>> break;
>>>
>>> + case V4L2_CTRL_TYPE_HDR10_CLL_INFO:
>>> + break;
>>> +
>>> + case V4L2_CTRL_TYPE_HDR10_MASTERING_DISPLAY:
>>> + p_hdr10_mastering = p;
>>> +
>>> + for (i = 0; i < 3; ++i) {
>>> + if (p_hdr10_mastering->display_primaries_x[i] <
>>> + V4L2_HDR10_MASTERING_PRIMARIES_X_LOW ||
>>> + p_hdr10_mastering->display_primaries_x[i] >
>>> + V4L2_HDR10_MASTERING_PRIMARIES_X_HIGH ||
>>> + p_hdr10_mastering->display_primaries_y[i] <
>>> + V4L2_HDR10_MASTERING_PRIMARIES_Y_LOW ||
>>> + p_hdr10_mastering->display_primaries_y[i] >
>>> + V4L2_HDR10_MASTERING_PRIMARIES_Y_HIGH)
>>> + return -EINVAL;
>>> + }
>>> +
>>> + if (p_hdr10_mastering->white_point_x <
>>> + V4L2_HDR10_MASTERING_WHITE_POINT_X_LOW ||
>>> + p_hdr10_mastering->white_point_x >
>>> + V4L2_HDR10_MASTERING_WHITE_POINT_X_HIGH ||
>>> + p_hdr10_mastering->white_point_y <
>>> + V4L2_HDR10_MASTERING_WHITE_POINT_Y_LOW ||
>>> + p_hdr10_mastering->white_point_y >
>>> + V4L2_HDR10_MASTERING_WHITE_POINT_Y_HIGH)
>>> + return -EINVAL;
>>> +
>>> + if (p_hdr10_mastering->max_luminance <
>>> + V4L2_HDR10_MASTERING_MAX_LUMA_LOW ||
>>> + p_hdr10_mastering->max_luminance >
>>> + V4L2_HDR10_MASTERING_MAX_LUMA_HIGH ||
>>> + p_hdr10_mastering->min_luminance <
>>> + V4L2_HDR10_MASTERING_MIN_LUMA_LOW ||
>>> + p_hdr10_mastering->min_luminance >
>>> + V4L2_HDR10_MASTERING_MIN_LUMA_HIGH)
>>> + return -EINVAL;
>>> +
>>> + if (p_hdr10_mastering->max_luminance ==
>>> + V4L2_HDR10_MASTERING_MAX_LUMA_LOW &&
>>> + p_hdr10_mastering->min_luminance ==
>>> + V4L2_HDR10_MASTERING_MIN_LUMA_HIGH)
>>> + return -EINVAL;
>>> +
>>> +
Re: [GIT PULL]: soundwire updates for v5.11-rc1
On Mon, Dec 07, 2020 at 10:32:47AM +0530, Vinod Koul wrote: > Hello Greg, > > Please pull to receive updates for v5.11 as detailed below: > > The following changes since commit 3650b228f83adda7e5ee532e2b90429c03f7b9ec: > > Linux 5.10-rc1 (2020-10-25 15:14:11 -0700) > > are available in the Git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/soundwire.git > tags/soundwire-5.11-rc1 Pulled and pushed out, thnaks. greg k-h
Re: [PATCH drm/hisilicon v2 1/2] drm/hisilicon: Use managed mode-config init
Hi
Am 07.12.20 um 10:05 schrieb Tian Tao:
Using drmm_mode_config_init() sets up managed release of modesetting
resources.
Individual patches usually contain a changelog to highlight the
difference to previous versions. Please add one before committing the
patch. Your cover letter for the series already does this correctly.
Signed-off-by: Tian Tao
Reviewed-by: Thomas Zimmermann
Thanks for all these updates.
---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 14 +++---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h | 1 -
2 files changed, 3 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
index 3687753..7f01213 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
@@ -96,8 +96,9 @@ static int hibmc_kms_init(struct hibmc_drm_private *priv)
struct drm_device *dev = &priv->dev;
int ret;
- drm_mode_config_init(dev);
- priv->mode_config_initialized = true;
+ ret = drmm_mode_config_init(dev);
+ if (ret)
+ return ret;
dev->mode_config.min_width = 0;
dev->mode_config.min_height = 0;
@@ -125,14 +126,6 @@ static int hibmc_kms_init(struct hibmc_drm_private *priv)
return 0;
}
-static void hibmc_kms_fini(struct hibmc_drm_private *priv)
-{
- if (priv->mode_config_initialized) {
- drm_mode_config_cleanup(&priv->dev);
- priv->mode_config_initialized = false;
- }
-}
-
/*
* It can operate in one of three modes: 0, 1 or Sleep.
*/
@@ -262,7 +255,6 @@ static int hibmc_unload(struct drm_device *dev)
drm_atomic_helper_shutdown(dev);
pci_disable_msi(dev->pdev);
- hibmc_kms_fini(priv);
dev->dev_private = NULL;
return 0;
}
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
index a49c10e..7d263f4 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
@@ -42,7 +42,6 @@ struct hibmc_drm_private {
struct drm_crtc crtc;
struct drm_encoder encoder;
struct hibmc_connector connector;
- bool mode_config_initialized;
};
static inline struct hibmc_connector *to_hibmc_connector(struct drm_connector *connector)
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
Re: linux-next: build failure after merge of the staging tree
On Mon, Dec 07, 2020 at 04:46:01PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> After merging the staging tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/iio/trigger/iio-trig-sysfs.c: In function 'iio_sysfs_trigger_probe':
> drivers/iio/trigger/iio-trig-sysfs.c:164:21: error: 'struct irq_work' has no
> member named 'flags'
> 164 | atomic_set(&t->work.flags, IRQ_WORK_HARD_IRQ);
> | ^
>
> Caused by commit
>
> 0449fc4eead7 ("iio: sysfs-trigger: Mark irq_work to expire in hardirq
> context")
>
> interacting with commit
>
> 7a9f50a05843 ("irq_work: Cleanup")
>
> from the tip tree.
>
> I applied the following merge fix patch:
>
> From: Stephen Rothwell
> Date: Mon, 7 Dec 2020 16:42:18 +1100
> Subject: [PATCH] fixup for "irq_work: Cleanup"
>
> Signed-off-by: Stephen Rothwell
> ---
> drivers/iio/trigger/iio-trig-sysfs.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/iio/trigger/iio-trig-sysfs.c
> b/drivers/iio/trigger/iio-trig-sysfs.c
> index 10a3fd29362b..0f6b512a5c37 100644
> --- a/drivers/iio/trigger/iio-trig-sysfs.c
> +++ b/drivers/iio/trigger/iio-trig-sysfs.c
> @@ -160,8 +160,7 @@ static int iio_sysfs_trigger_probe(int id)
> t->trig->dev.parent = &iio_sysfs_trig_dev;
> iio_trigger_set_drvdata(t->trig, t);
>
> - init_irq_work(&t->work, iio_sysfs_trigger_work);
> - atomic_set(&t->work.flags, IRQ_WORK_HARD_IRQ);
> + t->work = IRQ_WORK_INIT_HARD(iio_sysfs_trigger_work);
>
> ret = iio_trigger_register(t->trig);
> if (ret)
> --
> 2.29.2
Is this patch "safe" to take now, if the tip tree isn't part of my tree?
thanks,
greg k-h
linux-next: Tree for Dec 7
Hi all, Changes since 20201204: The nfs-anna tree gained a conflict against the nfs tree. The block tree gained a conflict against the btrfs tree and a semantic conflict against the bpf-next tree. The rcu tree lost its build failure. The kvm-arm tree gained a difficult conflict against the arm64 tree so I used the version from next-20201203. The staging tree gained a semantic conflict against the tip tree. Non-merge commits (relative to Linus' tree): 10267 9437 files changed, 716509 insertions(+), 173023 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 htmldocs. 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 327 trees (counting Linus' and 85 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 (ab91292cb3e9 Merge tag 'char-misc-5.10-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc) Merging fixes/fixes (4e33a343ac74 powerpc: fix the allyesconfig build) Merging kbuild-current/fixes (7d32358be8ac kbuild: avoid split lines in .mod files) Merging arc-current/for-curr (3a71e423133a ARC: build: use $(READELF) instead of hard-coded readelf) Merging arm-current/fixes (9fa2e7af3d53 ARM: 9019/1: kprobes: Avoid fortify_panic() when copying optprobe template) Merging arm64-fixes/for-next/fixes (929c1f3384d7 arm64: mte: fix prctl(PR_GET_TAGGED_ADDR_CTRL) if TCF0=NONE) Merging arm-soc-fixes/arm/fixes (ae597565d13f Merge tag 'optee-valid-memory-type-for-v5.11' of git://git.linaro.org/people/jens.wiklander/linux-tee into arm/fixes) Merging drivers-memory-fixes/fixes (3650b228f83a Linux 5.10-rc1) Merging m68k-current/for-linus (50c5feeea0af ide/macide: Convert Mac IDE driver to platform driver) Merging powerpc-fixes/fixes (a1ee28117077 powerpc/64s/powernv: Fix memory corruption when saving SLB entries on MCE) Merging s390-fixes/fixes (b1cae1f84a0f s390: fix irq state tracing) Merging sparc/master (0a95a6d1a4cd sparc: use for_each_child_of_node() macro) Merging fscrypt-current/for-stable (d19d8d345eec fscrypt: fix inline encryption not used on new files) Merging net/master (edd2410b165e net: mscc: ocelot: fix dropping of unknown IPv4 multicast on Seville) Merging bpf/master (12c8a8ca117f xsk: Return error code if force_zc is set) Merging ipsec/master (48f486e13ffd net: xfrm: fix memory leak in xfrm_user_policy()) Merging netfilter/master (bbe2ba04c5a9 Merge tag 'net-5.10-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net) Merging ipvs/master (bbe2ba04c5a9 Merge tag 'net-5.10-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net) Merging wireless-drivers/master (74a8c816fa8f rtw88: debug: Fix uninitialized memory in debugfs code) Merging mac80211/master (bdeca45a0cc5 mac80211: set SDATA_STATE_RUNNING for monitor interfaces) Merging rdma-fixes/for-rc (b65054597872 Linux 5.10-rc6) Merging sound-current/for-linus (c72b9bfe0f91 ALSA: hda/realtek: make bass spk volume adjustable on a yoga laptop) Merging sound-asoc-fixes/for-linus (7dd105ff02c8 Merge remote-tracking branch 'asoc/for-5.10' into asoc-linus) Merging regmap-fixes/for-linus (e6e9354b5830 regmap: Remove duplicate `type` field from regmap `regcache_sync` trace event) Merging regulator-fixes/for-linus (291de1d102fa regulator: axp20x: Fix DLDO2 voltage control register mask for AXP22x) Merging spi-fixes/for-linus (9a1cddca6c95 Merge remote-tracking br
Re: [PATCH 3/7] net: macb: unprepare clocks in case of failure
Hi Andrew, On 05.12.2020 16:30, Andrew Lunn wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the > content is safe > > On Fri, Dec 04, 2020 at 02:34:17PM +0200, Claudiu Beznea wrote: >> Unprepare clocks in case of any failure in fu540_c000_clk_init(). > > Hi Claudiu > > Nice patchset. Simple to understand. >> > >> +err_disable_clocks: >> + clk_disable_unprepare(*tx_clk); > >> + clk_disable_unprepare(*hclk); >> + clk_disable_unprepare(*pclk); >> + clk_disable_unprepare(*rx_clk); >> + clk_disable_unprepare(*tsu_clk); > > This looks correct, but it would be more symmetrical to add a > > macb_clk_uninit() > > function for the four main clocks. I'm surprised it does not already > exist. I was in balance b/w added and not added it taking into account that the disable unprepares are not taking care of all the clocks, in all the places, in the same way. Anyway, I will add one function for the main clocks, as you proposed, in the next version. Thank you for your review, Claudiu > > Andrew >
Re: [PATCH v2 2/2] hwspinlock: add sunxi hardware spinlock support
On Fri, Dec 04, 2020 at 06:07:25PM +0100, Wilken Gottwalt wrote: > On Fri, 4 Dec 2020 17:21:17 +0100 > Maxime Ripard wrote: > > > On Fri, Dec 04, 2020 at 04:35:12PM +0100, Wilken Gottwalt wrote: > > > Adds the sunxi_hwspinlock driver for the hardware spinlock unit found in > > > most of the sun8i and sun50i based SoCs. > > > > > > This unit provides at least 32 spinlocks in hardware. The implementation > > > supports 32, 64, 128 or 256 32bit registers, where one lock can be taken > > > by reading a register and released by writing a 0 to it. This driver > > > supports all 4 spinlock setups, but for now only the first setup (32 > > > locks) seem to exist in available devices. This spinlock unit is shared > > > between all ARM cores and the embedded OpenRisc AR100 core, all of them > > > can take/release a lock with a single cycle operation. It can be used to > > > sync access to devices shared by the ARM cores and the OpenRisc core. > > > > > > There are two ways to check if a lock is taken. The first way is to read > > > a lock. If a 0 is returned, the lock was free and is taken now. If an 1 > > > is returned, the caller has to try again, which means the lock is > > > currently taken. The second way is to read a 32bit wide status register > > > where every bit represents one of the 32 first locks. According to the > > > datasheets this status register supports the 32 first locks only. For > > > this reason the lock read/write approach is used in this driver which > > > can cover all 256 locks in the biggest setup. > > > > > > Being able to use the status register to get knowledge about the locks > > > makes it suitable to extended testing. It also can be used to bypass > > > the Linux hwspinlock ABI completely and is not able to set locks. This > > > is used in one of the tests to show that the driver works correctly. > > > > > > To run all tests it is necessary to take locks on the OpenRisc core and > > > show on the Linux side that the locks were taken by an external event. > > > This can be achived by using the crust firmware. For this the crust > > > firmware needs to be changed to take and release spinlocks (a simple > > > MMIO operation on the hwlock registers), which is currently not > > > supported by the current crust firmware. The necessary crust fork can > > > be found here https://github.com/wgottwalt/crust (hwspinlock branch). > > > It is also necessary to build u-boot with support for this crust/SCP > > > firmware. This u-boot fork can be found here > > > https://github.com/crust-firmware/u-boot (crust branch). For testing > > > this driver it is also necessary to pick a device that is fully > > > supported by crust. In this case a H5 based device works very well. In > > > this test a Friendlyarm NanoPi NEO2 was used, which is fully supported > > > by u-boot (also the fork) and current Linux kernels. In the crust fork > > > it is necessary to go into debug menu of "make nconfig" and select the > > > hwspinlock test loop, which uses the timeout functions of the crust > > > firmware. It loops through the first 32 spinlocks and takes/releases a > > > lock one after another using a timeout which can be set in the debug > > > menu. > > > > > > Test 1: > > > This test was done with a mainline u-boot and a crust enabled u-boot. > > > For this a simple second kernel module was used, found here > > > https://github.com/wgottwalt/sunxi_hwspinlock/tree/main/test_module. > > > > > > If run with mainline u-boot it shows that the Linux side correctly > > > takes a lock, tries to recursively take a lock again (which does not > > > happen) and releases a lock. Done for all 32 locks several times. > > > > > > [ 122.518435] [init]--- SUNXI HWSPINLOCK DRIVER TEST --- > > > [ 122.523810] [run ]--- testing locks 0 to 31 --- > > > [ 122.528370] [test] testing lock 0 > > > [ 122.531686] [test]+++ attempt #0 succeded > > > [ 122.535709] [test]+++ attempt #1 succeded > > > [ 122.539729] [test]+++ attempt #2 succeded > > > [ 122.543752] [test] testing lock 1 > > > [ 122.547072] [test]+++ attempt #0 succeded > > > [ 122.551093] [test]+++ attempt #1 succeded > > > [ 122.555113] [test]+++ attempt #2 succeded > > > [ 122.559129] [test] testing lock 2 > > > ... > > > [ 123.004812] [test] testing lock 31 > > > [ 123.008208] [test]+++ attempt #0 succeded > > > [ 123.012228] [test]+++ attempt #1 succeded > > > [ 123.016250] [test]+++ attempt #2 succeded > > > > > > Same test run with the hwspinlock test loop enabled in crust. Here the > > > test module hits two locks exactly in the moment crust switches from > > > lock 7 to 8. The test module code path is slower because of more code > > > that needs to be executed which makes this rare scenario possible. > > > > > > [ 122.620656] [test] testing lock 6 > > > [ 122.623966] [test]+++ attempt #0 succeded > > > [ 122.627988] [test]+++ attempt #1 succeded > > > [ 122.632008] [test]+++ attempt #2 succeded > > > [ 122.636044] [test] testing lock 7 > > >
Re: [PATCH] iommu/amd: Set DTE[IntTabLen] to represent 512 IRTEs
Suravee Suthikulpanit @ 2020-12-07 02:19 MST:
> According to the AMD IOMMU spec, the commit 73db2fc595f3
> ("iommu/amd: Increase interrupt remapping table limit to 512 entries")
> also requires the interrupt table length (IntTabLen) to be set to 9
> (power of 2) in the device table mapping entry (DTE).
>
> Fixes: 73db2fc595f3 ("iommu/amd: Increase interrupt remapping table limit to
> 512 entries")
> Reported-by: Jerry Snitselaar
> Signed-off-by: Suravee Suthikulpanit
> ---
> drivers/iommu/amd/amd_iommu_types.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/amd/amd_iommu_types.h
> b/drivers/iommu/amd/amd_iommu_types.h
> index 89647700bab2..494b42a31b7a 100644
> --- a/drivers/iommu/amd/amd_iommu_types.h
> +++ b/drivers/iommu/amd/amd_iommu_types.h
> @@ -257,7 +257,7 @@
> #define DTE_IRQ_REMAP_INTCTL_MASK(0x3ULL << 60)
> #define DTE_IRQ_TABLE_LEN_MASK (0xfULL << 1)
> #define DTE_IRQ_REMAP_INTCTL(2ULL << 60)
> -#define DTE_IRQ_TABLE_LEN (8ULL << 1)
> +#define DTE_IRQ_TABLE_LEN (9ULL << 1)
> #define DTE_IRQ_REMAP_ENABLE1ULL
>
> #define PAGE_MODE_NONE0x00
Reviewed-by: Jerry Snitselaar
Re: [PATCH] ARM: dts: sun6i-a31s-sinovoip-bpi-m2: add gpio-line-names
On Wed, Dec 02, 2020 at 08:51:47PM +0100, Michael Klein wrote: > Add gpio-line-names as documented on gitbooks [1] and in the > schematics [2]. > > [1]: https://bananapi.gitbook.io/bpi-m2/en/bpi-m2_gpio_pin_define > [2]: https://drive.google.com/file/d/0B4PAo2nW2KfnRERWNnJGSGxJbmM/view > > Signed-off-by: Michael Klein QUeued for 5.12, thanks Maxime signature.asc Description: PGP signature
Re: 5.10 RC 7: grub2 out of memory
Resending grub config since that appeared to be mangled by my mail client: On Mon, Dec 7, 2020 at 1:16 AM Elias Carter wrote: > > I just compiled and installed 5.10 RC 7 and got a message from grub2: > "out of memory, press any key to continue" shortly followed by a > kernel panic (see attached screenshot). > > The 5.4.0-56-generic kernel from Ubuntu works on my machine fine. > > Things I have tried so far: > - setting grub video mode to "console" > - setting grub video resolution to 800x600 > - regenerating the initramfs for 5.10 RC 7 > - verifying that /boot has free space > - changing boot mode from UEFI to legacy BIOS > > I have attached the following: > 1.) dmesg ran from using the 5.4 kernel (since I cant boot into 5.10 RC 7) > 2.) my 5.10 RC 7 kernel .config > 3.) screenshot of kernel panic after "out of memory" grub2 message > 4.) my /etc/default/grub > > Please let me know if you would like any more information or testing of > patches. > > Thanks, > Elias # If you change this file, run 'update-grub' afterwards to update # /boot/grub/grub.cfg. # For full documentation of the options in this file, see: # info -f grub -n 'Simple configuration' GRUB_DEFAULT=0 GRUB_TIMEOUT_STYLE=hidden GRUB_TIMEOUT=0 GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian` GRUB_CMDLINE_LINUX_DEFAULT="quiet splash" GRUB_CMDLINE_LINUX="" # Uncomment to enable BadRAM filtering, modify to suit your needs # This works with Linux (no patch required) and with any kernel that obtains # the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...) #GRUB_BADRAM="0x01234567,0xfefefefe,0x89abcdef,0xefefefef" # Uncomment to disable graphical terminal (grub-pc only) GRUB_TERMINAL=console # The resolution used on graphical terminal # note that you can use only modes which your graphic card supports via VBE # you can see them in real GRUB with the command `vbeinfo' GRUB_GFXMODE=800x600 GRUB_GFXPAYLOAD_LINUX=keep # Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux #GRUB_DISABLE_LINUX_UUID=true # Uncomment to disable generation of recovery mode menu entries #GRUB_DISABLE_RECOVERY="true" # Uncomment to get a beep at grub start #GRUB_INIT_TUNE="480 440 1"
Re: [PATCH drm/hisilicon v2 1/2] drm/hisilicon: Use managed mode-config init
在 2020/12/7 17:22, Thomas Zimmermann 写道:
Hi
Am 07.12.20 um 10:05 schrieb Tian Tao:
Using drmm_mode_config_init() sets up managed release of modesetting
resources.
Individual patches usually contain a changelog to highlight the
difference to previous versions. Please add one before committing the
Just to be sure: I don't need to add a changlog to this individual
patch, right?
patch. Your cover letter for the series already does this correctly.
Signed-off-by: Tian Tao
Reviewed-by: Thomas Zimmermann
Thanks for all these updates.
Thank you for your constant help with the review code and your careful
guidance!
---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 14 +++---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h | 1 -
2 files changed, 3 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
index 3687753..7f01213 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
@@ -96,8 +96,9 @@ static int hibmc_kms_init(struct hibmc_drm_private
*priv)
struct drm_device *dev = &priv->dev;
int ret;
- drm_mode_config_init(dev);
- priv->mode_config_initialized = true;
+ ret = drmm_mode_config_init(dev);
+ if (ret)
+ return ret;
dev->mode_config.min_width = 0;
dev->mode_config.min_height = 0;
@@ -125,14 +126,6 @@ static int hibmc_kms_init(struct
hibmc_drm_private *priv)
return 0;
}
-static void hibmc_kms_fini(struct hibmc_drm_private *priv)
-{
- if (priv->mode_config_initialized) {
- drm_mode_config_cleanup(&priv->dev);
- priv->mode_config_initialized = false;
- }
-}
-
/*
* It can operate in one of three modes: 0, 1 or Sleep.
*/
@@ -262,7 +255,6 @@ static int hibmc_unload(struct drm_device *dev)
drm_atomic_helper_shutdown(dev);
pci_disable_msi(dev->pdev);
- hibmc_kms_fini(priv);
dev->dev_private = NULL;
return 0;
}
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
index a49c10e..7d263f4 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
@@ -42,7 +42,6 @@ struct hibmc_drm_private {
struct drm_crtc crtc;
struct drm_encoder encoder;
struct hibmc_connector connector;
- bool mode_config_initialized;
};
static inline struct hibmc_connector *to_hibmc_connector(struct
drm_connector *connector)
Re: [PATCH 04/12] arm64: dts: zynqmp: Enable and wire reset controller
On 06. 12. 20 23:38, Laurent Pinchart wrote:
> Hi Michal,
>
> Thank you for the patch.
>
> On Wed, Dec 02, 2020 at 03:06:03PM +0100, Michal Simek wrote:
>> Enable reset controller for several IPs.
>>
>> Signed-off-by: Michal Simek
>> ---
>>
>> arch/arm64/boot/dts/xilinx/zynqmp.dtsi | 29 ++
>> 1 file changed, 29 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
>> b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
>> index 68923fbd0e89..4fa820f78d76 100644
>> --- a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
>> @@ -187,6 +187,11 @@ zynqmp_pcap: pcap {
>> xlnx_aes: zynqmp-aes {
>> compatible = "xlnx,zynqmp-aes";
>> };
>> +
>> +zynqmp_reset: reset-controller {
>> +compatible = "xlnx,zynqmp-reset";
>> +#reset-cells = <1>;
>> +};
>> };
>> };
>>
>> @@ -466,6 +471,8 @@ gem0: ethernet@ff0b {
>> #address-cells = <1>;
>> #size-cells = <0>;
>> power-domains = <&zynqmp_firmware PD_ETH_0>;
>> +resets = <&zynqmp_reset ZYNQMP_RESET_GEM0>;
>> +reset-names = "gem0_rst";
>
> I don't see any of the reset-names used in this patch defined in DT
> bindings (or used in drivers). For all devices but the USB controllers
> it seems they can be dropped. For the USB controllers, the bindings need
> to be updated first.
Let me double check it. IIRC if there is just one there is likely no
need to list the name but if there are more then one names should be
also there. But you are right it should be the part of dt binding.
Thanks,
Michal
Re: [PATCH] net: stmmac: dwmac-meson8b: fix mask definition of the m250_sel mux
On Sat 05 Dec 2020 at 22:32, Martin Blumenstingl
wrote:
> The m250_sel mux clock uses bit 4 in the PRG_ETH0 register. Fix this by
> shifting the PRG_ETH0_CLK_M250_SEL_MASK accordingly as the "mask" in
> struct clk_mux expects the mask relative to the "shift" field in the
> same struct.
>
> While here, get rid of the PRG_ETH0_CLK_M250_SEL_SHIFT macro and use
> __ffs() to determine it from the existing PRG_ETH0_CLK_M250_SEL_MASK
> macro.
>
> Fixes: 566e8251625304 ("net: stmmac: add a glue driver for the Amlogic Meson
> 8b / GXBB DWMAC")
> Signed-off-by: Martin Blumenstingl
Reviewed-by: Jerome Brunet
> ---
> drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
> b/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
> index dc0b8b6d180d..459ae715b33d 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
> @@ -30,7 +30,6 @@
> #define PRG_ETH0_EXT_RMII_MODE 4
>
> /* mux to choose between fclk_div2 (bit unset) and mpll2 (bit set) */
> -#define PRG_ETH0_CLK_M250_SEL_SHIFT 4
> #define PRG_ETH0_CLK_M250_SEL_MASK GENMASK(4, 4)
>
> /* TX clock delay in ns = "8ns / 4 * tx_dly_val" (where 8ns are exactly one
> @@ -155,8 +154,9 @@ static int meson8b_init_rgmii_tx_clk(struct meson8b_dwmac
> *dwmac)
> return -ENOMEM;
>
> clk_configs->m250_mux.reg = dwmac->regs + PRG_ETH0;
> - clk_configs->m250_mux.shift = PRG_ETH0_CLK_M250_SEL_SHIFT;
> - clk_configs->m250_mux.mask = PRG_ETH0_CLK_M250_SEL_MASK;
> + clk_configs->m250_mux.shift = __ffs(PRG_ETH0_CLK_M250_SEL_MASK);
> + clk_configs->m250_mux.mask = PRG_ETH0_CLK_M250_SEL_MASK >>
> + clk_configs->m250_mux.shift;
> clk = meson8b_dwmac_register_clk(dwmac, "m250_sel", mux_parents,
>ARRAY_SIZE(mux_parents), &clk_mux_ops,
>&clk_configs->m250_mux.hw);
KASAN: use-after-free Read in reiserfs_fill_super
Hello, syzbot found the following issue on: HEAD commit:b3298500 Merge tag 'for-5.10/dm-fixes' of git://git.kernel.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=11e6434550 kernel config: https://syzkaller.appspot.com/x/.config?x=e49433cfed49b7d9 dashboard link: https://syzkaller.appspot.com/bug?extid=2b5c012223e37b7c2a88 compiler: gcc (GCC) 10.1.0-syz 20200507 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=12ad719b50 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1119311750 IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+2b5c012223e37b7c2...@syzkaller.appspotmail.com REISERFS (device loop0): journal params: device loop0, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 REISERFS (device loop0): checking transaction log (loop0) == BUG: KASAN: use-after-free in init_inode fs/reiserfs/inode.c:1325 [inline] BUG: KASAN: use-after-free in reiserfs_read_locked_inode+0x1f2d/0x2230 fs/reiserfs/inode.c:1574 Read of size 4 at addr 888035a26000 by task syz-executor059/8481 CPU: 0 PID: 8481 Comm: syz-executor059 Not tainted 5.10.0-rc6-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x107/0x163 lib/dump_stack.c:118 print_address_description.constprop.0.cold+0xae/0x4c8 mm/kasan/report.c:385 __kasan_report mm/kasan/report.c:545 [inline] kasan_report.cold+0x1f/0x37 mm/kasan/report.c:562 init_inode fs/reiserfs/inode.c:1325 [inline] reiserfs_read_locked_inode+0x1f2d/0x2230 fs/reiserfs/inode.c:1574 reiserfs_fill_super+0x18eb/0x2e00 fs/reiserfs/super.c:2081 mount_bdev+0x32e/0x3f0 fs/super.c:1419 legacy_get_tree+0x105/0x220 fs/fs_context.c:592 vfs_get_tree+0x89/0x2f0 fs/super.c:1549 do_new_mount fs/namespace.c:2875 [inline] path_mount+0x13ad/0x20c0 fs/namespace.c:3205 do_mount fs/namespace.c:3218 [inline] __do_sys_mount fs/namespace.c:3426 [inline] __se_sys_mount fs/namespace.c:3403 [inline] __x64_sys_mount+0x27f/0x300 fs/namespace.c:3403 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x447d7a Code: b8 08 00 00 00 0f 05 48 3d 01 f0 ff ff 0f 83 7d a3 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 0f 83 5a a3 fb ff c3 66 0f 1f 84 00 00 00 00 00 RSP: 002b:7ffcf7e76348 EFLAGS: 0297 ORIG_RAX: 00a5 RAX: ffda RBX: 7ffcf7e763a0 RCX: 00447d7a RDX: 2000 RSI: 2100 RDI: 7ffcf7e76360 RBP: 7ffcf7e76360 R08: 7ffcf7e763a0 R09: R10: R11: 0297 R12: 0006 R13: 0004 R14: 0003 R15: 0003 The buggy address belongs to the page: page:50546bce refcount:0 mapcount:0 mapping: index:0x1 pfn:0x35a26 flags: 0xfff000() raw: 00fff000 ead689c8 8880b9e39d48 raw: 0001 page dumped because: kasan: bad access detected Memory state around the buggy address: 888035a25f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 888035a25f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >888035a26000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ^ 888035a26080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 888035a26100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff == --- This report is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this issue. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. syzbot can test patches for this issue, for details see: https://goo.gl/tpsmEJ#testing-patches
Re: [PATCH v4 0/3] improve get_feat.pl output when all features are displayed
Em Sat, 5 Dec 2020 17:03:50 +0100
Mauro Carvalho Chehab escreveu:
> Em Fri, 4 Dec 2020 14:48:43 -0700
> Jonathan Corbet escreveu:
>
> > On Fri, 4 Dec 2020 16:32:27 +0100
> > Mauro Carvalho Chehab wrote:
> >
> > > As requested, those patches improve the output of the script, when all
> > > features
> > > are displayed.
> > >
> > > The first patch was already posted as-is at v3.
> > >
> > > Patch 2 is optional. IMO, it makes more sense for the admin guide to show
> > > the architectures where the features are OK, then TODO, and finally the
> > > ones that are incompatible with the features. I already sent it together
> > > with a comment.
> > >
> > > Patch 3 is new: it tries to reduce the width of the table, in order for it
> > > to better fit on a terminal. With the patch, the number of columns were
> > > reduced, in order to better fit at console output. Before the patch, the
> > > output takes 281 lines with 158 columns (total size: 38.9 kB).
> > > After the patch, displaying all features require 439 lines and 92 columns
> > > (total size: 37.6 kB).
> >
> > OK, this is much improved, thanks; applied.
>
> Anytime.
>
> >
> > The one last thing I would do is stick "valign=top" on all the table
> > entries, but we can leave the shed a different color for now :)
>
> I actually prefer myself valign=center on tables ;-)
>
> In any case, a change like that should be simple to do.
>
> either adjust:
>
> Documentation/sphinx-static/theme_overrides.css
>
> to change it globally for all tables or create a "table_valign_top" CSS
> class on it, changing the script to add:
>
> .. cssclass:: table_valign_top
>
> Before each table.
Btw, if you want to play with changing the table alignment, the
enclosed patch changes the alignment to use valign=top for all
tables (and not only for the feature ones).
Don't forget to remove the old theme before testing the
patch with:
$ rm $(find Documentation/output/ -name theme_overrides.css)
As sphinx (at least version 2.4.4) only writes it if the file
doesn't exist.
Thanks,
Mauro
[PATCH] docs: use top-alignment for table cells
Change the table's default in order to align cells on the top,
overriding the defaults found on Read the Docs Sphinx Theme.
Signed-off-by: Mauro Carvalho Chehab
diff --git a/Documentation/sphinx-static/theme_overrides.css
b/Documentation/sphinx-static/theme_overrides.css
index 459ec5b29d68..e850859e35a0 100644
--- a/Documentation/sphinx-static/theme_overrides.css
+++ b/Documentation/sphinx-static/theme_overrides.css
@@ -42,6 +42,11 @@ p {
font-size: 100%;
}
+/* use vertical alignment on tables */
+.rst-content table.docutils td, .rst-content table.field-list td, .wy-table td
{
+vertical-align: top;
+}
+
/* Interim: Code-blocks with line nos - lines and line numbers don't line up.
* see: https://github.com/rtfd/sphinx_rtd_theme/issues/419
*/
Re: [PATCH next v2 2/3] printk: change @clear_seq to atomic64_t
On Sun, Dec 06, 2020 at 09:29:59PM +0106, John Ogness wrote:
> Yes, and it is read-only access. Perhaps atomic64_t is the wrong thing
> to use here. We could use a seqcount_latch and a shadow variable so that
> if a writer has been preempted, we can use the previous value. (Only
> kmsg_dump would need to use the lockless variant to read the value.)
>
> void clear_seq_set(u64 val)
> {
> spin_lock_irq(&clear_lock);
> raw_write_seqcount_latch(&clear_latch);
> clear_seq[0] = val;
> raw_write_seqcount_latch(&clear_latch);
> clear_seq[1] = val;
> spin_unlock_irq(&clear_lock);
> }
>
> u64 clear_seq_get_nolock(void)
> {
> unsigned int seq, idx;
> u64 val;
>
> do {
> seq = raw_read_seqcount_latch(&clear_latch);
> idx = seq & 0x1;
> val = clear_seq[idx];
> } while (read_seqcount_latch_retry(&clear_latch, seq));
>
> return val;
> }
That's overly complicated.
If you're going to double the storage you can simply do:
seq = val
smp_wmb();
seq_copy = val;
vs
do {
tmp = seq_copy;
smp_rmb();
val = seq;
} while (val != tmp);
Also look for CONFIG_64_BIT in kernel/sched/fair.c.
Re: KASAN: slab-out-of-bounds Read in btrfs_scan_one_device
syzbot suspects this issue was fixed by commit: commit 0697d9a610998b8bdee6b2390836cb2391d8fd1a Author: Johannes Thumshirn Date: Wed Nov 18 09:03:26 2020 + btrfs: don't access possibly stale fs_info data for printing duplicate device bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=10fb0d9b50 start commit: 521b619a Merge tag 'linux-kselftest-kunit-fixes-5.10-rc3' .. git tree: upstream kernel config: https://syzkaller.appspot.com/x/.config?x=e791ddf0875adf65 dashboard link: https://syzkaller.appspot.com/bug?extid=c4b1e5278d93269fd69c syz repro: https://syzkaller.appspot.com/x/repro.syz?x=16296f5c50 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1614e74650 If the result looks correct, please mark the issue as fixed by replying with: #syz fix: btrfs: don't access possibly stale fs_info data for printing duplicate device For information about bisection process see: https://goo.gl/tpsmEJ#bisection
Re: [PATCH] arm64: mm: decrease the section size to reduce the memory reserved for the page map
On 2020-12-07 09:09, Ard Biesheuvel wrote: (+ Marc) On Fri, 4 Dec 2020 at 12:14, Will Deacon wrote: On Fri, Dec 04, 2020 at 09:44:43AM +0800, Wei Li wrote: > For the memory hole, sparse memory model that define SPARSEMEM_VMEMMAP > do not free the reserved memory for the page map, decrease the section > size can reduce the waste of reserved memory. > > Signed-off-by: Wei Li > Signed-off-by: Baopeng Feng > Signed-off-by: Xia Qing > --- > arch/arm64/include/asm/sparsemem.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm64/include/asm/sparsemem.h b/arch/arm64/include/asm/sparsemem.h > index 1f43fcc79738..8963bd3def28 100644 > --- a/arch/arm64/include/asm/sparsemem.h > +++ b/arch/arm64/include/asm/sparsemem.h > @@ -7,7 +7,7 @@ > > #ifdef CONFIG_SPARSEMEM > #define MAX_PHYSMEM_BITS CONFIG_ARM64_PA_BITS > -#define SECTION_SIZE_BITS30 > +#define SECTION_SIZE_BITS27 We chose '30' to avoid running out of bits in the page flags. What changed? With this patch, I can trigger: ./include/linux/mmzone.h:1170:2: error: Allocator MAX_ORDER exceeds SECTION_SIZE #error Allocator MAX_ORDER exceeds SECTION_SIZE if I bump up NR_CPUS and NODES_SHIFT. Does this mean we will run into problems with the GICv3 ITS LPI tables again if we are forced to reduce MAX_ORDER to fit inside SECTION_SIZE_BITS? Most probably. We are already massively constraint on platforms such as TX1, and dividing the max allocatable range by 8 isn't going to make it work any better... M. -- Jazz is not dead. It just smells funny...
Re: [PATCH v5 10/19] dt-bindings: usb: Convert DWC USB3 bindings to DT schema
On Sat, 2020-12-05 at 18:24 +0300, Serge Semin wrote: > DWC USB3 DT node is supposed to be compliant with the Generic xHCI > Controller schema, but with additional vendor-specific properties, the > controller-specific reference clocks and PHYs. So let's convert the > currently available legacy text-based DWC USB3 bindings to the DT schema > and make sure the DWC USB3 nodes are also validated against the > usb-xhci.yaml schema. > > Note 1. we have to discard the nodename restriction of being prefixed with > "dwc3@" string, since in accordance with the usb-hcd.yaml schema USB nodes > are supposed to be named as "^usb(@.*)". > > Note 2. The clock-related properties are marked as optional to match the > DWC USB3 driver expectation and to improve the bindings mainainability > so in case if there is a glue-node it would the responsible for the > clocks initialization. > > Signed-off-by: Serge Semin > > --- > > Changelog v2: > - Discard '|' from the descriptions, since we don't need to preserve > the text formatting in any of them. > - Drop quotes from around the string constants. > - Fix the "clock-names" prop description to be referring the enumerated > clock-names instead of the ones from the Databook. > > Changelog v3: > - Apply usb-xhci.yaml# schema only if the controller is supposed to work > as either host or otg. > > Changelog v4: > - Apply usb-drd.yaml schema first. If the controller is configured > to work in a gadget mode only, then apply the usb.yaml schema too, > otherwise apply the usb-xhci.yaml schema. > - Discard the Rob'es Reviewed-by tag. Please review the patch one more > time. > > Changelog v5: > - Add "snps,dis-split-quirk" property to the DWC USB3 DT schema. > - Add a commit log text about the clock-related property changes. > - Make sure dr_mode exist to apply the USB-gadget-only schema. > --- > .../devicetree/bindings/usb/dwc3.txt | 128 --- > .../devicetree/bindings/usb/snps,dwc3.yaml| 312 ++ > 2 files changed, 312 insertions(+), 128 deletions(-) > delete mode 100644 Documentation/devicetree/bindings/usb/dwc3.txt > create mode 100644 Documentation/devicetree/bindings/usb/snps,dwc3.yaml > > diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt > b/Documentation/devicetree/bindings/usb/dwc3.txt > deleted file mode 100644 > index 1aae2b6160c1.. > --- a/Documentation/devicetree/bindings/usb/dwc3.txt > +++ /dev/null > @@ -1,128 +0,0 @@ > -synopsys DWC3 CORE > - [...] > + > + clock-names: > +contains: > + anyOf: > +- enum: [bus_early, ref, suspend] > +- true > + > + usb-phy: > + minItems: 1 indentation: expected 4 > + items: > + - description: USB2/HS PHY > + - description: USB3/SS PHY > + > + phys: > +minItems: 1 > +items: > + - description: USB2/HS PHY > + - description: USB3/SS PHY > + > + phy-names: > +minItems: 1 > +items: > + - const: usb2-phy > + - const: usb3-phy [...]
Re: [PATCH 1/2] regulator: ab8500: Remove unused platform data
On Fri, 04 Dec 2020, Linus Walleij wrote: > The struct ab8500_regulator_platform_data was a leftover > since the days before we probed all regulators from the > device tree. The ab8500-ext regulator was the only used, > defining platform data and register intialization that > was never used for anything, a copy of a boardfile no > longer in use. > > Delete the ab8500_regulator_platform_data and make the > ab8500-ext regulator reference the regulator init data > in the local file directly. We are 100% device tree > these days. > > Cc: Lee Jones > Signed-off-by: Linus Walleij > --- > Lee: would be nice if you could ACK this, I do not plan > any other changes to the AB8500 headers for this kernel > cycle so there should not be any conflicts. > --- > drivers/regulator/ab8500-ext.c| 417 +- > include/linux/mfd/abx500/ab8500.h | 3 - > include/linux/regulator/ab8500.h | 10 - > 3 files changed, 2 insertions(+), 428 deletions(-) Look at all those '-'s! Fine by me. Acked-by: Lee Jones -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog
[PATCH v2] iommu: Improve the performance for direct_mapping
Currently direct_mapping always use the smallest pgsize which is SZ_4K
normally to mapping. This is unnecessary. we could gather the size, and
call iommu_map then, iommu_map could decide how to map better with the
just right pgsize.
>From the original comment, we should take care overlap, otherwise,
iommu_map may return -EEXIST. In this overlap case, we should map the
previous region before overlap firstly. then map the left part.
Each a iommu device will call this direct_mapping when its iommu
initialize, This patch is effective to improve the boot/initialization
time especially while it only needs level 1 mapping.
Signed-off-by: Anan Sun
Signed-off-by: Yong Wu
---
change notes:
v2: Refine the code flow.
v1:
https://lore.kernel.org/linux-iommu/20201120090628.6566-1-yong...@mediatek.com/
base on v5.10-rc1.
---
drivers/iommu/iommu.c | 22 +-
1 file changed, 17 insertions(+), 5 deletions(-)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 8c470f451a32..1a91decb95fa 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -737,6 +737,7 @@ static int iommu_create_device_direct_mappings(struct
iommu_group *group,
/* We need to consider overlapping regions for different devices */
list_for_each_entry(entry, &mappings, list) {
dma_addr_t start, end, addr;
+ size_t map_size = 0;
if (domain->ops->apply_resv_region)
domain->ops->apply_resv_region(dev, domain, entry);
@@ -748,16 +749,27 @@ static int iommu_create_device_direct_mappings(struct
iommu_group *group,
entry->type != IOMMU_RESV_DIRECT_RELAXABLE)
continue;
- for (addr = start; addr < end; addr += pg_size) {
+ for (addr = start; addr <= end; addr += pg_size) {
phys_addr_t phys_addr;
+ if (addr == end)
+ goto map_end;
+
phys_addr = iommu_iova_to_phys(domain, addr);
- if (phys_addr)
+ if (!phys_addr) {
+ map_size += pg_size;
continue;
+ }
- ret = iommu_map(domain, addr, addr, pg_size,
entry->prot);
- if (ret)
- goto out;
+map_end:
+ if (map_size) {
+ ret = iommu_map(domain, addr - map_size,
+ addr - map_size, map_size,
+ entry->prot);
+ if (ret)
+ goto out;
+ map_size = 0;
+ }
}
}
--
2.18.0
Re: [PATCH v2 2/2] drivers: gpio: add virtio-gpio guest driver
On 07.12.20 04:48, Jason Wang wrote: Hi, >>> Not a native speaker but event sounds like something driver read from >>> device. Looking at the below lists, most of them except for >>> VIRTIO_GPIO_EV_HOST_LEVEL looks more like a command. >> okay, shall I name it "message" ? > > > It might be better. Okay, renamed to messages in v3. >>> #define VIRTIO_NET_OK 0 >>> #define VIRTIO_NET_ERR 1 >> hmm, so I'd need to define all the error codes that possibly could >> happen ? > > > Yes, I think you need. Okay, going to do it in the next version. >>> If I read the code correctly, this expects there will be at most a >>> single type of event that can be processed at the same time. E.g can >>> upper layer want to read from different lines in parallel? If yes, we >>> need to deal with that. >> @Linus @Bartosz: can that happen or does gpio subsys already serialize >> requests ? >> >> Initially, I tried to protect it by spinlock (so, only one request may >> run at a time, other calls just wait until the first is finished), but >> it crashed when gpio cdev registration calls into the driver (fetches >> the status) while still in bootup. >> >> Don't recall the exact error anymore, but something like an >> inconsistency in the spinlock calls. >> >> Did I just use the wrong type of lock ? > > I'm not sure since I am not familiar with GPIO. But a question is, if at > most one request is allowed, I'm not sure virtio is the best choice here > since we don't even need a queue(virtqueue) here. I guess, I should add locks to the gpio callback functions (where gpio subsys calls in). That way, requests are requests are strictly ordered. The locks didn't work in my previous attempts, but probably because I've missed to set the can_sleep flag (now fixed in v3). The gpio ops are already waiting for reply of the corresponding type, so the only bad thing that could happen is the same operation being called twice (when coming from different threads) and replies mixed up between first and second one. OTOH I don't see much problem w/ that. This can be fixed by adding a global lock. > I think it's still about whether or not we need allow a batch of > requests via a queue. Consider you've submitted two request A and B, and > if B is done first, current code won't work. This is because, the reply > is transported via rxq buffers not just reuse the txq buffer if I read > the code correctly. Meanwhile I've changed it to allocate a new rx buffer for the reply (done right before the request is sent), so everything should be processed in the order it had been sent. Assuming virtio keeps the order of the buffers in the queues. >> Could you please give an example how bi-directional transmission within >> the same queue could look like ? > > You can check how virtio-blk did this in: > > https://docs.oasis-open.org/virtio/virtio/v1.1/csprd01/virtio-v1.1-csprd01.html#x1-256 hmm, still don't see how the code would actually look like. (in qemu as well as kernel). Just add the fetched inbuf as an outbuf (within the same queue) ? >> Maybe add one new buffer per request and one new per received async >> signal ? > > It would be safe to fill the whole rxq and do the refill e.g when half > of the queue is used. Okay, doing that now in v3: there's always at least one rx buffer, and requests as well as the intr receiver always add a new one. (they get removed on fetching, IMHO). --mtx -- --- Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren GPG/PGP-Schlüssel zu. --- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering i...@metux.net -- +49-151-27565287
[PATCH v3] exfat: Avoid allocating upcase table using kcalloc()
The table for Unicode upcase conversion requires an order-5 allocation,
which may fail on a highly-fragmented system:
pool-udisksd: page allocation failure: order:5,
mode:0x40dc0(GFP_KERNEL|__GFP_COMP|__GFP_ZERO),
nodemask=(null),cpuset=/,mems_allowed=0
CPU: 4 PID: 3756880 Comm: pool-udisksd Tainted: G U
5.8.10-200.fc32.x86_64 #1
Hardware name: Dell Inc. XPS 13 9360/0PVG6D, BIOS 2.13.0 11/14/2019
Call Trace:
dump_stack+0x6b/0x88
warn_alloc.cold+0x75/0xd9
? _cond_resched+0x16/0x40
? __alloc_pages_direct_compact+0x144/0x150
__alloc_pages_slowpath.constprop.0+0xcfa/0xd30
? __schedule+0x28a/0x840
? __wait_on_bit_lock+0x92/0xa0
__alloc_pages_nodemask+0x2df/0x320
kmalloc_order+0x1b/0x80
kmalloc_order_trace+0x1d/0xa0
exfat_create_upcase_table+0x115/0x390 [exfat]
exfat_fill_super+0x3ef/0x7f0 [exfat]
? sget_fc+0x1d0/0x240
? exfat_init_fs_context+0x120/0x120 [exfat]
get_tree_bdev+0x15c/0x250
vfs_get_tree+0x25/0xb0
do_mount+0x7c3/0xaf0
? copy_mount_options+0xab/0x180
__x64_sys_mount+0x8e/0xd0
do_syscall_64+0x4d/0x90
entry_SYSCALL_64_after_hwframe+0x44/0xa9
Convert kcalloc/kfree to their kv* variants to eliminate the issue.
Cc: sta...@vger.kernel.org # v5.7+
Signed-off-by: Artem Labazov <123321art...@gmail.com>
---
v2: replace vmalloc with vzalloc to avoid uninitialized memory access
v3: use kv* functions to attempt kmalloc first
fs/exfat/nls.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/fs/exfat/nls.c b/fs/exfat/nls.c
index 675d0e7058c5..314d5407a1be 100644
--- a/fs/exfat/nls.c
+++ b/fs/exfat/nls.c
@@ -659,7 +659,7 @@ static int exfat_load_upcase_table(struct super_block *sb,
unsigned char skip = false;
unsigned short *upcase_table;
- upcase_table = kcalloc(UTBL_COUNT, sizeof(unsigned short), GFP_KERNEL);
+ upcase_table = kvcalloc(UTBL_COUNT, sizeof(unsigned short), GFP_KERNEL);
if (!upcase_table)
return -ENOMEM;
@@ -715,7 +715,7 @@ static int exfat_load_default_upcase_table(struct
super_block *sb)
unsigned short uni = 0, *upcase_table;
unsigned int index = 0;
- upcase_table = kcalloc(UTBL_COUNT, sizeof(unsigned short), GFP_KERNEL);
+ upcase_table = kvcalloc(UTBL_COUNT, sizeof(unsigned short), GFP_KERNEL);
if (!upcase_table)
return -ENOMEM;
@@ -803,5 +803,5 @@ int exfat_create_upcase_table(struct super_block *sb)
void exfat_free_upcase_table(struct exfat_sb_info *sbi)
{
- kfree(sbi->vol_utbl);
+ kvfree(sbi->vol_utbl);
}
--
2.26.2
Re: [RESEND PATCH v6 2/2] pinctrl: qcom: Add sm8250 lpass lpi pinctrl driver
On 05/12/2020 22:36, Linus Walleij wrote: On Wed, Dec 2, 2020 at 5:35 PM Srinivas Kandagatla wrote: Add initial pinctrl driver to support pin configuration for LPASS (Low Power Audio SubSystem) LPI (Low Power Island) pinctrl on SM8250. Patch applied! +config PINCTRL_LPASS_LPI + tristate "Qualcomm Technologies Inc LPASS LPI pin controller driver" + depends on GPIOLIB I added: select PINMUX select PINCONF select GENERIC_PINCONF When applying. You need these I think, your code is working because other drivers are selecting these for you, right? The build robot would hack this to pieces though. Many thanks for doing this! --srini Yours, Linus Walleij
Re: 5.10 RC 7: grub2 out of memory
On 07.12.20 10:16, Elias Carter wrote: > I just compiled and installed 5.10 RC 7 and got a message from grub2: > "out of memory, press any key to continue" shortly followed by a > kernel panic (see attached screenshot). > > The 5.4.0-56-generic kernel from Ubuntu works on my machine fine. > > Things I have tried so far: > - setting grub video mode to "console" > - setting grub video resolution to 800x600 > - regenerating the initramfs for 5.10 RC 7 > - verifying that /boot has free space > - changing boot mode from UEFI to legacy BIOS > > I have attached the following: > 1.) dmesg ran from using the 5.4 kernel (since I cant boot into 5.10 RC 7) > 2.) my 5.10 RC 7 kernel .config > 3.) screenshot of kernel panic after "out of memory" grub2 message > 4.) my /etc/default/grub > > Please let me know if you would like any more information or testing of > patches. The kernel crashes because it's unable to mount root - I suspect the initrd is not loaded, because I would have expected systemd messages before trying to mount root (after loading additional drivers from the initrd). I assume grub2 fails to load the (now too big?) initrd - you could try compiling out debug symbols and give it a try. What's the size difference between old vs. new kernel and old vs. new initrd? Similar report for aarch64 was at https://bugzilla.redhat.com/show_bug.cgi?id=1615969 which turned out to be a grub2 issue. Which distro/grub2 version etc are you running? -- Thanks, David / dhildenb
[PATCH] dt-bindings: vendor-prefixes: correct the spelling of TQ-Systems GmbH
From: Max Merchel "TQ-Systems" is written with a dash, as can be seen on https://www.tq-group.com/en/imprint/ Signed-off-by: Max Merchel Signed-off-by: Matthias Schiffer --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 3a76c226771b..5b7ee0e059a2 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -1125,7 +1125,7 @@ patternProperties: "^tpo,.*": description: TPO "^tq,.*": -description: TQ Systems GmbH +description: TQ-Systems GmbH "^tronfy,.*": description: Tronfy "^tronsmart,.*": -- 2.17.1
Re: [PATCH 06/12] arm64: dts: zynqmp: Add label for zynqmp_ipi
Hi, On 06. 12. 20 23:46, Laurent Pinchart wrote: > Hi Michal, > > Thank you for the patch. > > On Wed, Dec 02, 2020 at 03:06:05PM +0100, Michal Simek wrote: >> Add label which is used by bootloader for adding bootloader specific flag. >> >> Signed-off-by: Michal Simek >> --- >> >> U-Boot needs to add u-boot,dm-pre-reloc; property > > I'm not entirely sure what best practice rules are in this area, but > shouldn't U-Boot locate the node by name instead of label ? Labels are not listed in dt binding and there are two approaches how to reference nodes. Via full path with node name or via labels. I do normally use labels which are much simple. And also if you take a look how dtb looks like (convert back to dts) you can see that for example aliases are using full path (just &label) but clocks/gic which is the part of <> is handled via phandles as numbers. And labels names can vary and shouldn't be the part of binding doc as far as I know. But I can be wrong of course. Thanks, Michal
Re: [PATCH 3/3] Serial: Separate out earlycon support
On Mon, Dec 07, 2020 at 02:17:27PM +0530, Akash Asthana wrote: > Separate out earlycon support from serial driver and remove it's > dependency on QUP wrapper driver. > > This enable us to manage earlycon independently and we can re-use the > same earlycon driver for android project which currently uses > downstream version of QUP drivers. > > Signed-off-by: Akash Asthana > --- > drivers/tty/serial/Kconfig | 9 + > drivers/tty/serial/Makefile | 1 + > drivers/tty/serial/qcom_geni_earlycon.c | 649 > > drivers/tty/serial/qcom_geni_serial.c | 97 - > 4 files changed, 659 insertions(+), 97 deletions(-) > create mode 100644 drivers/tty/serial/qcom_geni_earlycon.c Nit, your subject line shoudl say somewhere that this is the qcom earlycon driver/support, not "earlycon in general". thanks, greg k-h
Re: [PATCH] arm64: mm: decrease the section size to reduce the memory reserved for the page map
On Mon, Dec 07, 2020 at 09:35:06AM +, Marc Zyngier wrote: > On 2020-12-07 09:09, Ard Biesheuvel wrote: > > (+ Marc) > > > > On Fri, 4 Dec 2020 at 12:14, Will Deacon wrote: > > > > > > On Fri, Dec 04, 2020 at 09:44:43AM +0800, Wei Li wrote: > > > > For the memory hole, sparse memory model that define SPARSEMEM_VMEMMAP > > > > do not free the reserved memory for the page map, decrease the section > > > > size can reduce the waste of reserved memory. > > > > > > > > Signed-off-by: Wei Li > > > > Signed-off-by: Baopeng Feng > > > > Signed-off-by: Xia Qing > > > > --- > > > > arch/arm64/include/asm/sparsemem.h | 2 +- > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > diff --git a/arch/arm64/include/asm/sparsemem.h > > > > b/arch/arm64/include/asm/sparsemem.h > > > > index 1f43fcc79738..8963bd3def28 100644 > > > > --- a/arch/arm64/include/asm/sparsemem.h > > > > +++ b/arch/arm64/include/asm/sparsemem.h > > > > @@ -7,7 +7,7 @@ > > > > > > > > #ifdef CONFIG_SPARSEMEM > > > > #define MAX_PHYSMEM_BITS CONFIG_ARM64_PA_BITS > > > > -#define SECTION_SIZE_BITS30 > > > > +#define SECTION_SIZE_BITS27 > > > > > > We chose '30' to avoid running out of bits in the page flags. What > > > changed? > > > > > > With this patch, I can trigger: > > > > > > ./include/linux/mmzone.h:1170:2: error: Allocator MAX_ORDER exceeds > > > SECTION_SIZE > > > #error Allocator MAX_ORDER exceeds SECTION_SIZE > > > > > > if I bump up NR_CPUS and NODES_SHIFT. > > > > > > > Does this mean we will run into problems with the GICv3 ITS LPI tables > > again if we are forced to reduce MAX_ORDER to fit inside > > SECTION_SIZE_BITS? > > Most probably. We are already massively constraint on platforms > such as TX1, and dividing the max allocatable range by 8 isn't > going to make it work any better... I don't think MAX_ORDER should shrink. Even if SECTION_SIZE_BITS is reduced it should accomodate the existing MAX_ORDER. My two pennies. > M. > -- > Jazz is not dead. It just smells funny... -- Sincerely yours, Mike.
Re: [PATCH V2 3/3] arm64: dts: allwinner: a100: Add CPU Operating Performance Points table
On Mon, Dec 7, 2020 at 5:20 PM Shuosheng Huang
wrote:
>
> Add an Operating Performance Points table for the CPU cores to
> enable Dynamic Voltage & Frequency Scaling on the A100.
>
> Signed-off-by: Shuosheng Huang
> ---
> .../allwinner/sun50i-a100-allwinner-perf1.dts | 5 ++
> .../dts/allwinner/sun50i-a100-cpu-opp.dtsi| 90 +++
> .../arm64/boot/dts/allwinner/sun50i-a100.dtsi | 8 ++
> 3 files changed, 103 insertions(+)
> create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a100-cpu-opp.dtsi
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a100-allwinner-perf1.dts
> b/arch/arm64/boot/dts/allwinner/sun50i-a100-allwinner-perf1.dts
> index d34c2bb1079f..7c579923f973 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a100-allwinner-perf1.dts
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a100-allwinner-perf1.dts
> @@ -6,6 +6,7 @@
> /dts-v1/;
>
> #include "sun50i-a100.dtsi"
> +#include "sun50i-a100-cpu-opp.dtsi"
>
> /{
> model = "Allwinner A100 Perf1";
> @@ -20,6 +21,10 @@ chosen {
> };
> };
>
> +&cpu0 {
> + cpu-supply = <®_dcdc2>;
> +};
> +
Please add this for all CPU cores.
IIRC people (I don't remember exactly who) have reported that if the first
CPU core is offline, i.e. having Linux booting off one of the other CPU
cores, then cpufreq sort of breaks as the CPU no longer has a regulator tied
to it.
Also, please separate the changes in sun50i-a100-allwinner-perf1.dts to
one patch titled "Enable cpufreq for ".
> &pio {
> vcc-pb-supply = <®_dcdc1>;
> vcc-pc-supply = <®_eldo1>;
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a100-cpu-opp.dtsi
> b/arch/arm64/boot/dts/allwinner/sun50i-a100-cpu-opp.dtsi
> new file mode 100644
> index ..e245823d70e8
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a100-cpu-opp.dtsi
> @@ -0,0 +1,90 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +// Copyright (c) 2020 Yangtao Li
> +// Copyright (c) 2020 ShuoSheng Huang
> +
> +/ {
> + cpu_opp_table: cpu-opp-table {
> + compatible = "allwinner,sun50i-h6-operating-points";
> + nvmem-cells = <&cpu_speed_grade>;
> + opp-shared;
> +
> + opp@40800 {
> + clock-latency-ns = <244144>; /* 8 32k periods */
> + opp-hz = /bits/ 64 <40800>;
> +
> + opp-microvolt-speed0 = <90 90 120>;
> + opp-microvolt-speed1 = <90 90 120>;
> + opp-microvolt-speed2 = <90 90 120>;
> + };
> +
> + opp@6 {
> + clock-latency-ns = <244144>; /* 8 32k periods */
> + opp-hz = /bits/ 64 <6>;
> +
> + opp-microvolt-speed0 = <90 90 120>;
> + opp-microvolt-speed1 = <90 90 120>;
> + opp-microvolt-speed2 = <90 90 120>;
> + };
> +
> + opp@81600 {
> + clock-latency-ns = <244144>; /* 8 32k periods */
> + opp-hz = /bits/ 64 <81600>;
> +
> + opp-microvolt-speed0 = <94 94 120>;
> + opp-microvolt-speed1 = <90 90 120>;
> + opp-microvolt-speed2 = <90 90 120>;
> + };
> +
> + opp@108000 {
> + clock-latency-ns = <244144>; /* 8 32k periods */
> + opp-hz = /bits/ 64 <108000>;
> +
> + opp-microvolt-speed0 = <102 102 120>;
> + opp-microvolt-speed1 = <98 98 120>;
> + opp-microvolt-speed2 = <95 95 120>;
> + };
> +
> + opp@12 {
> + clock-latency-ns = <244144>; /* 8 32k periods */
> + opp-hz = /bits/ 64 <12>;
> +
> + opp-microvolt-speed0 = <110 110 120>;
> + opp-microvolt-speed1 = <102 102 120>;
> + opp-microvolt-speed2 = <100 100 120>;
> + };
> +
> + opp@132000 {
> + clock-latency-ns = <244144>; /* 8 32k periods */
> + opp-hz = /bits/ 64 <132000>;
> +
> + opp-microvolt-speed0 = <116 116 120>;
> + opp-microvolt-speed1 = <106 106 120>;
> + opp-microvolt-speed2 = <103 103 120>;
> + };
> +
> + opp@146400 {
> + clock-latency-ns = <244144>; /* 8 32k periods */
> + opp-hz = /bits/ 64 <146400>;
> +
> + opp-microvolt-speed0 = <118 118 120>;
> +
Re: [PATCH 06/12] arm64: dts: zynqmp: Add label for zynqmp_ipi
On 06. 12. 20 23:48, Laurent Pinchart wrote: > On Mon, Dec 07, 2020 at 12:46:56AM +0200, Laurent Pinchart wrote: >> Hi Michal, >> >> Thank you for the patch. >> >> On Wed, Dec 02, 2020 at 03:06:05PM +0100, Michal Simek wrote: >>> Add label which is used by bootloader for adding bootloader specific flag. >>> >>> Signed-off-by: Michal Simek >>> --- >>> >>> U-Boot needs to add u-boot,dm-pre-reloc; property >> >> I'm not entirely sure what best practice rules are in this area, but >> shouldn't U-Boot locate the node by name instead of label ? > > And regardless of what mechanism is used, it should be documented in the > bindings. I don't think we should be documenting labels because names can be whatever. DT binding spec is just talking about name rules. 6.2 chapter. A label shall be between - 1 to 31 characters in length, be composed only of the characters in the set Table 6.1, and must not start with a number. - Table 6.1: Valid characters for DTS labels Character Description 0-9 digit a-z lowercase letter A-Z uppercase letter _ underscore Thanks, Michal
Re: [PATCH v2] pwm: bcm2835: Support apply function for atomic configuration
Hello Uwe, Thank you for taking the time to explain your thinking. On Mon, Dec 07, 2020 at 09:16:28AM +0100, Uwe Kleine-König wrote: > On Sun, Dec 06, 2020 at 02:19:41PM +, Sean Young wrote: > > On Sat, Dec 05, 2020 at 08:25:10PM +0100, Uwe Kleine-König wrote: > > > On Sat, Dec 05, 2020 at 05:34:44PM +, Sean Young wrote: > > > > What real life uses-cases are there for round down? If you want to round > > > > down, is there any need for round up? > > > > > > The scenario I have in mind is for driving a motor. I have to admit > > > however that usually the period doesn't matter much and it's the > > > duty_cycle that defines the motor's speed. So for this case the > > > conservative behaviour is round-down to not make the motor run faster > > > than expected. > > > > I am reading here that for driving motors, only the duty cycle matters, > > not the period. > > There is an upper limit (usually around 1 ms) for the period, but if you > choose 0.1 ms or 0.001 ms doesn't matter much AFAICT. > > @Thierry: Do you have further use cases in mind? > > > > For other usecases (fan, backlight, LED) exactness typically doesn't > > > matter that much. > > > > So, the use-cases you have are driving motor, fan, backlight, and led. > > And in all these cases the exact Hz does not matter. > > > > The only uses case where the exact Hz does matter is pwm-ir-tx. > > > > So, I gather there are no use-cases for round-down. Yes, should round-down > > be needed, then this is more difficult to implement if the driver always > > does a round-closest. But, since there is no reason to have round-down, > > this is all academic. > > > > Your policy of forcing new pwm drivers to use round-down is breaking > > pwm-ir-tx. > > So you're indeed suggesting that the "right" rounding strategy for > lowlevel drivers should be: > > - Use the period length closest to the requested period (in doubt round >down?) > - With the chosen period length use the biggest duty_cycle not bigger >than the requested duty_cycle. > > While this seems technically fine I think for maintenance this is a > nightmare. > > My preference would be to stick to the rounding strategy we used so far > (i.e.: > > - Use the biggest period length not bigger than the requested period > - With the chosen period length use the biggest duty_cycle not bigger >than the requested duty_cycle. > > ) and for pwm-ir-tx add support to the PWM API to still make it possible > (and easy) to select the best setting. > > The reasons why I think that this rounding-down strategy is the best > are (in order of importance): > > - It is easier to implement correctly [1] Yes, you are right. You have given a great example where a simple DIV_ROUND_CLOSEST() does not give the result you want. > - Same rounding method for period and duty cycle > - most drivers already do this (I think) > > The (IMHO nice) result would then mean: > > - All consumers can get the setting they want; and Once there is a nice pwm api for selecting round-nearest, then yes. For the uses cases you've given, fan, backlight, and led a round-nearest is the rounding they would want, I would expect. > - Code in lowlevel drivers is simple and the complexity is in common >code and so a single place. > > And it would also allow the pwm-ir-tx driver to notice if the PWM to be > used can for example only support frequencies under 400 kHz. I doubt pwm-ir-tx cares about this, however it is a nice-to-have. It would also be nice if the rounding could be used with atomic configuration as well. Please let me know when/if this new API exists for pwm so that pwm-ir-tx can select the right rounding. > [1] Consider a PWM with a parent frequency of 66 MHz, to select the > period you can pick an integer divider "div" resulting in the period > 4096 / (pclk * d). So the obvious implementation for round-nearest > would be: > > pclk = clk_get_rate(myclk); > div = DIV_ROUND_CLOSEST(NSEC_PER_SEC * 4096, targetperiod * pclk); Note NSEC_PER_SEC * 4096 >> 2^32 so this would need to be DIV_ROUND_CLOSEST_ULL. > , right? > > With targetperiod = 2641 ns this picks div = 23 and so a period of > 2698.2872200263505 ns (delta = 57.2872200263505 ns). > The optimal divider however is div = 24. (implemented period = > 2585.8585858585857 ns, delta = 55.14141414141448 ns) > > For round-down the correct implementation is: > > pclk = clk_get_rate(myclk); > div = DIV_ROUND_UP(NSEC_PER_SEC * 4096, targetperiod * pclk); > > Exercise for the reader: Come up with a correct implementation for > "round-nearest" and compare its complexity to the round-down code. To be fair, I haven't been been able to come up with a solution without control flow. Thank you for an interesting conversation about this. Sean
Re: linux-next: build failure after merge of the staging tree
Hi Greg, On Mon, 7 Dec 2020 10:26:06 +0100 Greg KH wrote: > > > diff --git a/drivers/iio/trigger/iio-trig-sysfs.c > > b/drivers/iio/trigger/iio-trig-sysfs.c > > index 10a3fd29362b..0f6b512a5c37 100644 > > --- a/drivers/iio/trigger/iio-trig-sysfs.c > > +++ b/drivers/iio/trigger/iio-trig-sysfs.c > > @@ -160,8 +160,7 @@ static int iio_sysfs_trigger_probe(int id) > > t->trig->dev.parent = &iio_sysfs_trig_dev; > > iio_trigger_set_drvdata(t->trig, t); > > > > - init_irq_work(&t->work, iio_sysfs_trigger_work); > > - atomic_set(&t->work.flags, IRQ_WORK_HARD_IRQ); > > + t->work = IRQ_WORK_INIT_HARD(iio_sysfs_trigger_work); > > > > ret = iio_trigger_register(t->trig); > > if (ret) > > -- > > 2.29.2 > > Is this patch "safe" to take now, if the tip tree isn't part of my tree? Unfortunately not, as IRQ_WORK_INIT_HARD() is introduced by the tip tree commit. -- Cheers, Stephen Rothwell pgpxzGHdoZGH2.pgp Description: OpenPGP digital signature
Re: [PATCH v3] mm/page_alloc: speeding up the iteration of max_order
On 04.12.20 16:51, Muchun Song wrote:
> When we free a page whose order is very close to MAX_ORDER and greater
> than pageblock_order, it wastes some CPU cycles to increase max_order
> to MAX_ORDER one by one and check the pageblock migratetype of that page
> repeatedly especially when MAX_ORDER is much larger than pageblock_order.
>
> We also should not be checking migratetype of buddy when "order ==
> MAX_ORDER - 1" as the buddy pfn may be invalid, so adjust the condition.
> With the new check, we don't need the max_order check anymore, so we
> replace it.
>
> Also adjust max_order initialization so that it's lower by one than
> previously, which makes the code hopefully more clear.
>
> Fixes: d9dddbf55667 ("mm/page_alloc: prevent merging between isolated and
> other pageblocks")
> Signed-off-by: Muchun Song
> Acked-by: Vlastimil Babka
> ---
> Changes in v3:
> - Update commit log.
>
> Changes in v2:
> - Rework the code suggested by Vlastimil. Thanks.
>
> mm/page_alloc.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index f91df593bf71..56e603eea1dd 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -1002,7 +1002,7 @@ static inline void __free_one_page(struct page *page,
> struct page *buddy;
> bool to_tail;
>
> - max_order = min_t(unsigned int, MAX_ORDER, pageblock_order + 1);
> + max_order = min_t(unsigned int, MAX_ORDER - 1, pageblock_order);
>
> VM_BUG_ON(!zone_is_initialized(zone));
> VM_BUG_ON_PAGE(page->flags & PAGE_FLAGS_CHECK_AT_PREP, page);
> @@ -1015,7 +1015,7 @@ static inline void __free_one_page(struct page *page,
> VM_BUG_ON_PAGE(bad_range(zone, page), page);
>
> continue_merging:
> - while (order < max_order - 1) {
> + while (order < max_order) {
> if (compaction_capture(capc, page, order, migratetype)) {
> __mod_zone_freepage_state(zone, -(1 << order),
> migratetype);
> @@ -1041,7 +1041,7 @@ static inline void __free_one_page(struct page *page,
> pfn = combined_pfn;
> order++;
> }
> - if (max_order < MAX_ORDER) {
> + if (order < MAX_ORDER - 1) {
> /* If we are here, it means order is >= pageblock_order.
>* We want to prevent merge between freepages on isolate
>* pageblock and normal pageblock. Without this, pageblock
> @@ -1062,7 +1062,7 @@ static inline void __free_one_page(struct page *page,
> is_migrate_isolate(buddy_mt)))
> goto done_merging;
> }
> - max_order++;
> + max_order = order + 1;
> goto continue_merging;
> }
>
>
LGTM
Reviewed-by: David Hildenbrand
--
Thanks,
David / dhildenb
Re: 5.10 RC 7: grub2 out of memory
>What's the size difference between old vs. new kernel and old vs. new initrd? The new initrd is over twice as large as the old one, the kernels appear to be similar sizes: elias@elias-5600X:~$ ll -h /boot/ total 435M drwxr-xr-x 4 root root 4.0K Dec 7 01:31 ./ drwxr-xr-x 23 root root 4.0K Dec 6 23:15 ../ -rw-r--r-- 1 root root 160K Dec 7 01:31 config-5.10.0-rc7 -rw-r--r-- 1 root root 243K Dec 7 00:11 config-5.10.0-rc7.old -rw-r--r-- 1 root root 233K Apr 20 2020 config-5.4.0-26-generic -rw-r--r-- 1 root root 233K Nov 23 10:06 config-5.4.0-56-generic drwx-- 3 root root 4.0K Dec 31 1969 efi/ drwxr-xr-x 4 root root 4.0K Dec 7 01:31 grub/ lrwxrwxrwx 1 root root 27 Dec 7 00:01 initrd.img -> initrd.img-5.4.0-56-generic -rw-r--r-- 1 root root 206M Dec 7 01:31 initrd.img-5.10.0-rc7 -rw-r--r-- 1 root root 82M Dec 6 23:23 initrd.img-5.4.0-26-generic -rw-r--r-- 1 root root 82M Dec 7 00:01 initrd.img-5.4.0-56-generic lrwxrwxrwx 1 root root 21 Dec 7 00:01 initrd.img.old -> initrd.img-5.10.0-rc7 -rw-r--r-- 1 root root 5.3M Dec 7 01:31 System.map-5.10.0-rc7 -rw-r--r-- 1 root root 5.5M Dec 7 00:11 System.map-5.10.0-rc7.old -rw--- 1 root root 4.6M Apr 20 2020 System.map-5.4.0-26-generic -rw--- 1 root root 4.6M Nov 23 10:06 System.map-5.4.0-56-generic lrwxrwxrwx 1 root root 18 Dec 7 01:31 vmlinuz -> vmlinuz-5.10.0-rc7 -rw-r--r-- 1 root root 12M Dec 7 01:31 vmlinuz-5.10.0-rc7 -rw-r--r-- 1 root root 12M Dec 7 00:11 vmlinuz-5.10.0-rc7.old -rw-r--r-- 1 root root 12M Jun 24 11:59 vmlinuz-5.4.0-26-generic -rw--- 1 root root 12M Nov 23 10:10 vmlinuz-5.4.0-56-generic lrwxrwxrwx 1 root root 22 Dec 7 01:31 vmlinuz.old -> vmlinuz-5.10.0-rc7.old > Which distro/grub2 version etc are you running? Linux Mint 20 Cinnamon. elias@elias-5600X:~$ grub-install --version grub-install (GRUB) 2.04-1ubuntu26.7 Thanks, Elias On Mon, Dec 7, 2020 at 1:38 AM David Hildenbrand wrote: > > On 07.12.20 10:16, Elias Carter wrote: > > I just compiled and installed 5.10 RC 7 and got a message from grub2: > > "out of memory, press any key to continue" shortly followed by a > > kernel panic (see attached screenshot). > > > > The 5.4.0-56-generic kernel from Ubuntu works on my machine fine. > > > > Things I have tried so far: > > - setting grub video mode to "console" > > - setting grub video resolution to 800x600 > > - regenerating the initramfs for 5.10 RC 7 > > - verifying that /boot has free space > > - changing boot mode from UEFI to legacy BIOS > > > > I have attached the following: > > 1.) dmesg ran from using the 5.4 kernel (since I cant boot into 5.10 RC 7) > > 2.) my 5.10 RC 7 kernel .config > > 3.) screenshot of kernel panic after "out of memory" grub2 message > > 4.) my /etc/default/grub > > > > Please let me know if you would like any more information or testing of > > patches. > > The kernel crashes because it's unable to mount root - I suspect the > initrd is not loaded, because I would have expected systemd messages > before trying to mount root (after loading additional drivers from the > initrd). I assume grub2 fails to load the (now too big?) initrd - you > could try compiling out debug symbols and give it a try. > > What's the size difference between old vs. new kernel and old vs. new > initrd? > > > Similar report for aarch64 was at > > https://bugzilla.redhat.com/show_bug.cgi?id=1615969 > > which turned out to be a grub2 issue. Which distro/grub2 version etc are > you running? > > -- > Thanks, > > David / dhildenb >
Re: [PATCH v2 3/5] thermal: devfreq_cooling: add new registration functions with Energy Model
On 12/3/20 3:40 PM, Daniel Lezcano wrote:
On 18/11/2020 13:03, Lukasz Luba wrote:
The Energy Model (EM) framework supports devices such as Devfreq. Create
new registration functions which automatically register EM for the thermal
devfreq_cooling devices. This patch prepares the code for coming changes
which are going to replace old power model with the new EM.
Signed-off-by: Lukasz Luba
---
drivers/thermal/devfreq_cooling.c | 99 ++-
include/linux/devfreq_cooling.h | 22 +++
2 files changed, 120 insertions(+), 1 deletion(-)
diff --git a/drivers/thermal/devfreq_cooling.c
b/drivers/thermal/devfreq_cooling.c
index 925523694462..b354271742c5 100644
--- a/drivers/thermal/devfreq_cooling.c
+++ b/drivers/thermal/devfreq_cooling.c
@@ -50,6 +50,8 @@ static DEFINE_IDA(devfreq_ida);
* @capped_state: index to cooling state with in dynamic power budget
* @req_max_freq: PM QoS request for limiting the maximum frequency
*of the devfreq device.
+ * @em:Energy Model for the associated Devfreq device
+ * @em_registered: Devfreq cooling registered the EM and should free it.
*/
struct devfreq_cooling_device {
int id;
@@ -63,6 +65,8 @@ struct devfreq_cooling_device {
u32 res_util;
int capped_state;
struct dev_pm_qos_request req_max_freq;
+ struct em_perf_domain *em;
This pointer is not needed, it is in the struct device.
It is just a helper pointer, to make the code simpler and avoid nested
pointers:
struct device *dev = dfc->devfreq->dev.parent
and then using dev->em
The code is cleaner with dfc->em, but let me have a look if I can
remove it and still have a clean code.
+ bool em_registered;
The boolean em_registered is not needed because of the test in the
function em_dev_unregister_perf_domain():
if (IS_ERR_OR_NULL(dev) || !dev->em_pd)
return;
Logically if the 'em' was not initialized, it must be NULL, the
corresponding struct device was zero-allocated.
It was needed for devfreq cooling to know who registered the EM.
If there is 2 frameworks and driver and all could register EM,
this code cannot blindly unregister EM in it's code. The EM might
be used still by PowerCap DTM, so the unregister might be called
explicitly by the driver.
But I will rewrite the register function and make it way simpler,
just registration of EM (stopping when it failed) and then cooling
device. Also unregister will be simpler.
Driver will have to keep the order of unregister functions for two
frameworks and call unregister devfreq cooling device as last one,
because it will remove the EM.
};
static int devfreq_cooling_get_max_state(struct thermal_cooling_device *cdev,
@@ -583,22 +587,115 @@ struct thermal_cooling_device
*devfreq_cooling_register(struct devfreq *df)
}
EXPORT_SYMBOL_GPL(devfreq_cooling_register);
+/**
+ * devfreq_cooling_em_register_power() - Register devfreq cooling device with
+ * power information and attempt to register Energy Model (EM)
+ * @df:Pointer to devfreq device.
+ * @dfc_power: Pointer to devfreq_cooling_power.
+ * @em_cb: Callback functions providing the data of the EM
+ *
+ * Register a devfreq cooling device and attempt to register Energy Model. The
+ * available OPPs must be registered for the device.
+ *
+ * If @dfc_power is provided, the cooling device is registered with the
+ * power extensions. If @em_cb is provided it will be called for each OPP to
+ * calculate power value and cost. If @em_cb is not provided then simple Energy
+ * Model is going to be used, which requires "dynamic-power-coefficient" a
+ * devicetree property.
+ */
+struct thermal_cooling_device *
+devfreq_cooling_em_register_power(struct devfreq *df,
+ struct devfreq_cooling_power *dfc_power,
+ struct em_data_callback *em_cb)
+{
+ struct thermal_cooling_device *cdev;
+ struct devfreq_cooling_device *dfc;
+ struct device_node *np = NULL;
+ struct device *dev;
+ int nr_opp, ret;
+
+ if (IS_ERR_OR_NULL(df))
+ return ERR_PTR(-EINVAL);
+
+ dev = df->dev.parent;
Why the parent ?
The parent has OPPs and we are calling em_perf_domain_register() or
dev_pm_opp_of_register_em() (which in addition needs DT node) for that
device.
The old devfreq cooling code also had dev parent, to enable/disenable
OPPs.
+
+ if (em_cb) {
+ nr_opp = dev_pm_opp_get_opp_count(dev);
+ if (nr_opp <= 0) {
+ dev_err(dev, "No valid OPPs found\n");
+ return ERR_PTR(-EINVAL);
+ }
+
+ ret = em_dev_register_perf_domain(dev, nr_opp, em_cb, NULL,
false);
+ } else {
+ ret = dev_pm_opp_of_register_em(dev, NULL);
+ }
+
+ if (ret)
+ dev_warn(dev, "Unable to register EM for d
Re: [PATCH 4.19 00/32] 4.19.162-rc1 review
On Sun, 6 Dec 2020 at 17:10, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.19.162 release. > There are 32 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 Tue, 08 Dec 2020 11:15:42 +. > 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.19.162-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.19.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. Tested-by: Linux Kernel Functional Testing Summary kernel: 4.19.162-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.19.y git commit: 35a4debf26a46be2487f7401acf73ae8b7a4a3f1 git describe: v4.19.161-33-g35a4debf26a4 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-4.19.y/build/v4.19.161-33-g35a4debf26a4 No regressions (compared to build v4.19.161) No fixes (compared to build v4.19.161) Ran 42661 total tests in the following environments and test suites. Environments -- - arm - arm64 - dragonboard-410c - arm64 - hi6220-hikey - arm64 - i386 - juno-r2 - arm64 - juno-r2-compat - juno-r2-kasan - mips - nxp-ls2088 - qemu-arm64-clang - qemu-arm64-kasan - qemu-x86_64-clang - qemu-x86_64-kasan - qemu_arm - qemu_arm64 - qemu_arm64-compat - qemu_i386 - qemu_x86_64 - qemu_x86_64-compat - s390 - sparc - x15 - arm - x86_64 - x86-kasan Test Suites --- * build * linux-log-parser * ltp-cap_bounds-tests * ltp-cpuhotplug-tests * ltp-crypto-tests * ltp-dio-tests * ltp-io-tests * ltp-nptl-tests * ltp-pty-tests * ltp-securebits-tests * ltp-syscalls-tests * v4l2-compliance * install-android-platform-tools-r2600 * libhugetlbfs * ltp-commands-tests * ltp-containers-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-ipc-tests * ltp-math-tests * ltp-mm-tests * ltp-sched-tests * ltp-tracing-tests * network-basic-tests * perf * kselftest * ltp-controllers-tests * ltp-cve-tests * ltp-fs-tests * ltp-open-posix-tests * kvm-unit-tests * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-none -- Linaro LKFT https://lkft.linaro.org
[PATCH] mm,memory_failure: Always pin the page in madvise_inject_error
madvise_inject_error() uses get_user_pages_fast to translate the
address we specified to a page.
After [1], we drop the extra reference count for memory_failure() path.
That commit says that memory_failure wanted to keep the pin in order
to take the page out of circulation.
The truth is that we need to keep the page pinned, otherwise the
page might be re-used after the put_page() and we can end up messing
with someone else's memory.
E.g:
CPU0
process X CPU1
madvise_inject_error
get_user_pages
put_page
page gets reclaimed
process Y allocates the page
memory_failure
// We mess with process Y memory
madvise() is meant to operate on a self address space, so messing with
pages that do not belong to us seems the wrong thing to do.
To avoid that, let us keep the page pinned for memory_failure as well.
Pages for DAX mappings will release this extra refcount in
memory_failure_dev_pagemap.
[1] ("23e7b5c2e271: mm, madvise_inject_error:
Let memory_failure() optionally take a page reference")
Signed-off-by: Oscar Salvador
Suggested-by: Vlastimil Babka
Fixes: 23e7b5c2e271 ("mm, madvise_inject_error: Let memory_failure() optionally
take a page reference")
---
mm/madvise.c| 9 +
mm/memory-failure.c | 6 ++
2 files changed, 7 insertions(+), 8 deletions(-)
diff --git a/mm/madvise.c b/mm/madvise.c
index c6b5524add58..19edddba196d 100644
--- a/mm/madvise.c
+++ b/mm/madvise.c
@@ -907,14 +907,7 @@ static int madvise_inject_error(int behavior,
} else {
pr_info("Injecting memory failure for pfn %#lx at
process virtual address %#lx\n",
pfn, start);
- /*
-* Drop the page reference taken by
get_user_pages_fast(). In
-* the absence of MF_COUNT_INCREASED the
memory_failure()
-* routine is responsible for pinning the page to
prevent it
-* from being released back to the page allocator.
-*/
- put_page(page);
- ret = memory_failure(pfn, 0);
+ ret = memory_failure(pfn, MF_COUNT_INCREASED);
}
if (ret)
diff --git a/mm/memory-failure.c b/mm/memory-failure.c
index 869ece2a1de2..064d605cc416 100644
--- a/mm/memory-failure.c
+++ b/mm/memory-failure.c
@@ -1258,6 +1258,12 @@ static int memory_failure_dev_pagemap(unsigned long pfn,
int flags,
loff_t start;
dax_entry_t cookie;
+ if (flags & MF_COUNT_INCREASED)
+ /*
+* Drop the extra refcount in case we come from madvise().
+*/
+ put_page(page);
+
/*
* Prevent the inode from being freed while we are interrogating
* the address_space, typically this would be handled by
--
2.26.2
Re: [PATCH] arm64: mm: decrease the section size to reduce the memory reserved for the page map
On Mon, 7 Dec 2020 at 10:42, Mike Rapoport wrote: > > On Mon, Dec 07, 2020 at 09:35:06AM +, Marc Zyngier wrote: > > On 2020-12-07 09:09, Ard Biesheuvel wrote: > > > (+ Marc) > > > > > > On Fri, 4 Dec 2020 at 12:14, Will Deacon wrote: > > > > > > > > On Fri, Dec 04, 2020 at 09:44:43AM +0800, Wei Li wrote: > > > > > For the memory hole, sparse memory model that define SPARSEMEM_VMEMMAP > > > > > do not free the reserved memory for the page map, decrease the section > > > > > size can reduce the waste of reserved memory. > > > > > > > > > > Signed-off-by: Wei Li > > > > > Signed-off-by: Baopeng Feng > > > > > Signed-off-by: Xia Qing > > > > > --- > > > > > arch/arm64/include/asm/sparsemem.h | 2 +- > > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > > > diff --git a/arch/arm64/include/asm/sparsemem.h > > > > > b/arch/arm64/include/asm/sparsemem.h > > > > > index 1f43fcc79738..8963bd3def28 100644 > > > > > --- a/arch/arm64/include/asm/sparsemem.h > > > > > +++ b/arch/arm64/include/asm/sparsemem.h > > > > > @@ -7,7 +7,7 @@ > > > > > > > > > > #ifdef CONFIG_SPARSEMEM > > > > > #define MAX_PHYSMEM_BITS CONFIG_ARM64_PA_BITS > > > > > -#define SECTION_SIZE_BITS30 > > > > > +#define SECTION_SIZE_BITS27 > > > > > > > > We chose '30' to avoid running out of bits in the page flags. What > > > > changed? > > > > > > > > With this patch, I can trigger: > > > > > > > > ./include/linux/mmzone.h:1170:2: error: Allocator MAX_ORDER exceeds > > > > SECTION_SIZE > > > > #error Allocator MAX_ORDER exceeds SECTION_SIZE > > > > > > > > if I bump up NR_CPUS and NODES_SHIFT. > > > > > > > > > > Does this mean we will run into problems with the GICv3 ITS LPI tables > > > again if we are forced to reduce MAX_ORDER to fit inside > > > SECTION_SIZE_BITS? > > > > Most probably. We are already massively constraint on platforms > > such as TX1, and dividing the max allocatable range by 8 isn't > > going to make it work any better... > > I don't think MAX_ORDER should shrink. Even if SECTION_SIZE_BITS is > reduced it should accomodate the existing MAX_ORDER. > > My two pennies. > But include/linux/mmzone.h:1170 has this: #if (MAX_ORDER - 1 + PAGE_SHIFT) > SECTION_SIZE_BITS #error Allocator MAX_ORDER exceeds SECTION_SIZE #endif and Will managed to trigger it after applying this patch.
Re: consoles: was: [PATCH next v2 3/3] printk: remove logbuf_lock, add syslog_lock
On Sat 2020-12-05 13:39:53, Sergey Senozhatsky wrote: > On (20/12/04 17:19), Petr Mladek wrote: > [..] > > > --- a/kernel/printk/printk.c > > > +++ b/kernel/printk/printk.c > > > @@ -2432,7 +2490,6 @@ void console_unlock(void) > > > size_t len; > > > > > > printk_safe_enter_irqsave(flags); > > > > Why do we actually need to use the printk_safe context here? > > There is not longer a risk of deadlock caused by logbuf_lock. > > All other recursions should be prevented by console_trylock() > > in printk(). > > All semaphore functions, including down_trylock(), acquire > semaphore spin_lock; This has a very easy solution. The patch adds a code that counts recursion level. We just must not call console_trylock() when being inside a recursive printk. printk_safe() has two functions: 1. It allows to store messages a lockless way. This is obsoleted by the lockless ringbuffer. 2. It prevents calling consoles. We could move this check into vprintk_store(). We already have there similar check for printk_deferred(). > and then some call into the scheduler > (or other kernel core functions) under semaphore's spin_lock. > For instance > > up() >raw_spin_lock_irqsave(&sem->lock) > __up() >wake_up_process() > try_to_wake_up() This problem is partly solved by printk_deferred(). In each case, printk_safe() does not help here. I still do _not_ see a reason to keep printk_safe()! Best Regards, Petr
Re: [PATCH 1/2] dt-bindings: phy: add Amlogic G12A Analog MIPI D-PHY bindings
Hi,
On 05/12/2020 09:04, Vinod Koul wrote:
> On 23-11-20, 15:51, Neil Armstrong wrote:
>> The Amlogic G12A SoCs embeds an Analog MIPI D-PHY to communicate with DSI
>> panels, this adds the bindings.
>>
>> This Analog D-PHY works with a separate Digital MIPI D-PHY.
>
> Pls cc Rob on dt binding patches (hint get_maintainer.pl would tell you
> do so)
It's the case.
Neil
>
>>
>> Signed-off-by: Neil Armstrong
>> ---
>> .../phy/amlogic,g12a-mipi-dphy-analog.yaml| 40 +++
>> 1 file changed, 40 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/phy/amlogic,g12a-mipi-dphy-analog.yaml
>>
>> diff --git
>> a/Documentation/devicetree/bindings/phy/amlogic,g12a-mipi-dphy-analog.yaml
>> b/Documentation/devicetree/bindings/phy/amlogic,g12a-mipi-dphy-analog.yaml
>> new file mode 100644
>> index ..28663552f05b
>> --- /dev/null
>> +++
>> b/Documentation/devicetree/bindings/phy/amlogic,g12a-mipi-dphy-analog.yaml
>> @@ -0,0 +1,40 @@
>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: "http://devicetree.org/schemas/phy/amlogic,g12a-mipi-dphy-analog.yaml#";
>> +$schema: "http://devicetree.org/meta-schemas/core.yaml#";
>> +
>> +title: Amlogic G12A MIPI analog PHY
>> +
>> +maintainers:
>> + - Neil Armstrong
>> +
>> +description: |+
>> + The Everything-Else Power Domains node should be the child of a syscon
>> + node with the required property:
>> +
>> + - compatible: Should be the following:
>> +"amlogic,meson-gx-hhi-sysctrl", "simple-mfd", "syscon"
>> +
>> + Refer to the the bindings described in
>> + Documentation/devicetree/bindings/mfd/syscon.yaml
>> +
>> +properties:
>> + compatible:
>> +const: amlogic,g12a-mipi-dphy-analog
>> +
>> + "#phy-cells":
>> +const: 0
>> +
>> +required:
>> + - compatible
>> + - "#phy-cells"
>> +
>> +additionalProperties: false
>> +
>> +examples:
>> + - |
>> +mpphy: phy {
>> + compatible = "amlogic,g12a-mipi-dphy-analog";
>> + #phy-cells = <0>;
>> +};
>> --
>> 2.25.1
>
Re: KASAN: slab-out-of-bounds Read in btrfs_scan_one_device
On Mon, Dec 7, 2020 at 10:34 AM syzbot wrote: > > syzbot suspects this issue was fixed by commit: > > commit 0697d9a610998b8bdee6b2390836cb2391d8fd1a > Author: Johannes Thumshirn > Date: Wed Nov 18 09:03:26 2020 + > > btrfs: don't access possibly stale fs_info data for printing duplicate > device > > bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=10fb0d9b50 > start commit: 521b619a Merge tag 'linux-kselftest-kunit-fixes-5.10-rc3' .. > git tree: upstream > kernel config: https://syzkaller.appspot.com/x/.config?x=e791ddf0875adf65 > dashboard link: https://syzkaller.appspot.com/bug?extid=c4b1e5278d93269fd69c > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=16296f5c50 > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1614e74650 > > If the result looks correct, please mark the issue as fixed by replying with: > > #syz fix: btrfs: don't access possibly stale fs_info data for printing > duplicate device > > For information about bisection process see: https://goo.gl/tpsmEJ#bisection #syz fix: btrfs: don't access possibly stale fs_info data for printing duplicate device
Re: [PATCH] rtc: fix RTC removal
On Sun, Dec 6, 2020 at 12:14 AM Alexandre Belloni
wrote:
>
> Since the rtc_register_device, removing an RTC device will end with a
> refcount_t: underflow; use-after-free warning since put_device is called
> twice in the device tear down path.
>
> Fixes: fdcfd854333b ("rtc: rework rtc_register_device() resource management")
> Signed-off-by: Alexandre Belloni
> ---
> drivers/rtc/class.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/rtc/class.c b/drivers/rtc/class.c
> index e6b44b7c4ad3..5c6748dfa55d 100644
> --- a/drivers/rtc/class.c
> +++ b/drivers/rtc/class.c
> @@ -335,7 +335,6 @@ static void devm_rtc_unregister_device(void *data)
> cdev_device_del(&rtc->char_dev, &rtc->dev);
> rtc->ops = NULL;
> mutex_unlock(&rtc->ops_lock);
> - put_device(&rtc->dev);
> }
>
> static void devm_rtc_release_device(void *res)
> --
> 2.28.0
>
Eek! Thanks for fixing that.
Reviewed-by: Bartosz Golaszewski
[PATCH v8] f2fs: compress: support compress level
Expand 'compress_algorithm' mount option to accept parameter as format of
:, by this way, it gives a way to allow user to do more
specified config on lz4 and zstd compression level, then f2fs compression
can provide higher compress ratio.
In order to set compress level for lz4 algorithm, it needs to set
CONFIG_LZ4HC_COMPRESS and CONFIG_F2FS_FS_LZ4HC config to enable lz4hc
compress algorithm.
CR and performance number on lz4/lz4hc algorithm:
dd if=enwik9 of=compressed_file conv=fsync
Original blocks:244382
lz4 lz4hc-9
compressed blocks 170647 163270
compress ratio 69.8% 66.8%
speed 16.4207 s, 60.9 MB/s26.7299 s, 37.4 MB/s
compress ratio = after / before
Signed-off-by: Chao Yu
---
v8:
- rebase on dev branch.
- cover LZ4HC_MEM_COMPRESS with CONFIG_F2FS_FS_LZ4HC
Documentation/filesystems/f2fs.rst | 5 +++
fs/f2fs/Kconfig| 10 +
fs/f2fs/compress.c | 41 +++--
fs/f2fs/f2fs.h | 9
fs/f2fs/super.c| 71 +-
include/linux/f2fs_fs.h| 3 ++
6 files changed, 134 insertions(+), 5 deletions(-)
diff --git a/Documentation/filesystems/f2fs.rst
b/Documentation/filesystems/f2fs.rst
index fd413d319e93..73ab31bbf694 100644
--- a/Documentation/filesystems/f2fs.rst
+++ b/Documentation/filesystems/f2fs.rst
@@ -249,6 +249,11 @@ checkpoint=%s[:%u[%]] Set to "disable" to turn off
checkpointing. Set to "enabl
This space is reclaimed once checkpoint=enable.
compress_algorithm=%s Control compress algorithm, currently f2fs supports
"lzo",
"lz4", "zstd" and "lzo-rle" algorithm.
+compress_algorithm=%s:%d Control compress algorithm and its compress level,
now, only
+"lz4" and "zstd" support compress level config.
+algorithm level range
+lz43 - 16
+zstd 1 - 22
compress_log_size=%uSupport configuring compress cluster size, the size
will
be 4KB * (1 << %u), 16KB is minimum size, also it's
default size.
diff --git a/fs/f2fs/Kconfig b/fs/f2fs/Kconfig
index d13c5c6a9787..63c1fc1a0e3b 100644
--- a/fs/f2fs/Kconfig
+++ b/fs/f2fs/Kconfig
@@ -119,6 +119,16 @@ config F2FS_FS_LZ4
help
Support LZ4 compress algorithm, if unsure, say Y.
+config F2FS_FS_LZ4HC
+ bool "LZ4HC compression support"
+ depends on F2FS_FS_COMPRESSION
+ depends on F2FS_FS_LZ4
+ select LZ4HC_COMPRESS
+ default y
+ help
+ Support LZ4HC compress algorithm, LZ4HC has compatible on-disk
+ layout with LZ4, if unsure, say Y.
+
config F2FS_FS_ZSTD
bool "ZSTD compression support"
depends on F2FS_FS_COMPRESSION
diff --git a/fs/f2fs/compress.c b/fs/f2fs/compress.c
index 191f93711f25..fa646c94ddec 100644
--- a/fs/f2fs/compress.c
+++ b/fs/f2fs/compress.c
@@ -254,8 +254,14 @@ static const struct f2fs_compress_ops f2fs_lzo_ops = {
#ifdef CONFIG_F2FS_FS_LZ4
static int lz4_init_compress_ctx(struct compress_ctx *cc)
{
- cc->private = f2fs_kvmalloc(F2FS_I_SB(cc->inode),
- LZ4_MEM_COMPRESS, GFP_NOFS);
+ unsigned int size = LZ4_MEM_COMPRESS;
+
+#ifdef CONFIG_F2FS_FS_LZ4HC
+ if (F2FS_I(cc->inode)->i_compress_flag >> COMPRESS_LEVEL_OFFSET)
+ size = LZ4HC_MEM_COMPRESS;
+#endif
+
+ cc->private = f2fs_kvmalloc(F2FS_I_SB(cc->inode), size, GFP_NOFS);
if (!cc->private)
return -ENOMEM;
@@ -274,10 +280,34 @@ static void lz4_destroy_compress_ctx(struct compress_ctx
*cc)
cc->private = NULL;
}
+#ifdef CONFIG_F2FS_FS_LZ4HC
+static int lz4hc_compress_pages(struct compress_ctx *cc)
+{
+ unsigned char level = F2FS_I(cc->inode)->i_compress_flag >>
+ COMPRESS_LEVEL_OFFSET;
+ int len;
+
+ if (level)
+ len = LZ4_compress_HC(cc->rbuf, cc->cbuf->cdata, cc->rlen,
+ cc->clen, level, cc->private);
+ else
+ len = LZ4_compress_default(cc->rbuf, cc->cbuf->cdata, cc->rlen,
+ cc->clen, cc->private);
+ if (!len)
+ return -EAGAIN;
+
+ cc->clen = len;
+ return 0;
+}
+#endif
+
static int lz4_compress_pages(struct compress_ctx *cc)
{
int len;
+#ifdef CONFIG_F2FS_FS_LZ4HC
+ return lz4hc_compress_pages(cc);
+#endif
len = LZ4_compress_default(cc->rbuf, cc->cbuf->cdata, cc->rlen,
cc->clen, cc->private);
if (!len)
@@ -327,8 +357,13 @@ static int zstd_init_compress_ctx(struct compress_ctx *cc)
ZSTD_CStream *stream;
void *workspace;
Re: Re: [PATCH v2] PCI: Fix Oops caused by uninitialized slot->list in pci_slot_release()
>On Wed, Dec 02, 2020 at 10:33:42AM +0800, Jubin Zhong wrote:
>> Once kobject_init_and_add() failed, pci_slot_release() is called to
>> delete slot->list from parent->slots. But slot->list is intialized
>> afterwards, so we ran into the following crash:
>>
>> Unable to handle kernel NULL pointer dereference at virtual address
>>
>> ...
>> CPU: 10 PID: 1 Comm: swapper/0 Not tainted 4.4.240 #197
>> task: eb398a45ef10 task.stack: eb398a47
>> PC is at __list_del_entry_valid+0x5c/0xb0
>> LR is at pci_slot_release+0x84/0xe4
>> ...
>> __list_del_entry_valid+0x5c/0xb0
>> pci_slot_release+0x84/0xe4
>> kobject_put+0x184/0x1c4
>> pci_create_slot+0x17c/0x1b4
>> __pci_hp_initialize+0x68/0xa4
>> pciehp_probe+0x1a4/0x2fc
>> pcie_port_probe_service+0x58/0x84
>> driver_probe_device+0x320/0x470
>> __driver_attach+0x54/0xb8
>> bus_for_each_dev+0xc8/0xf0
>> driver_attach+0x30/0x3c
>> bus_add_driver+0x1b0/0x24c
>> driver_register+0x9c/0xe0
>> pcie_port_service_register+0x64/0x7c
>> pcied_init+0x44/0xa4
>> do_one_initcall+0x1d0/0x1f0
>> kernel_init_freeable+0x24c/0x254
>> kernel_init+0x18/0xe8
>> ret_from_fork+0x10/0x20
>>
>> Fixes: 8a94644b440e ("PCI: Fix pci_create_slot() reference count
>> leak")
>> Signed-off-by: Jubin Zhong
>> Cc: sta...@vger.kernel.org #v4.4.235
>I'm curious how you noticed this. Did kobject_init_and_add() fail for some
>reason? Is there a bug there that we need to fix also?
Actually not.
In the very beginning, Coverity reported a RESOURCE_LEAK warning of slot
memory. It should be a false alarm because pci_slot_release() is already called
to free slot memory as a function hook (which Coverity could not recognize).
After code review I prepared to cancel the warning, that's when I noticed the
unintialized slot list is also deleted by pci_slot_release().
>And why did you mention v4.4.235 in the stable tag? 8a94644b440e wasn't
>merged until v5.9. If 8a94644b440e was backported to older kernels, we can't
>know that in general, so I think whoever backported it is responsible for
>watching for Fixes tags that mention it.
The Coverity warning was reported on v4.4.240. I also did a little test on
v4.4.240 by forcing kobject_init_and_add() to fail, that's how I got the above
call stack. Since 8a94644b440e was backported to v4.4.235, I thought it should
be necessary to fix it on v4.4 too.
>>I updated the stable tag to "v5.9+" and applied this to pci/hotplug for
>>v5.11, thanks!
>>
>> v2:
>> Since both slot memory and slot->list would be handled by
>> pci_slot_release(), we need to make sure slot->list is properly
>> initialized beforehand.
>>
>> v1:
>> https://lore.kernel.org/lkml/1606288971-47927-1-git-send-email-zhongju...@huawei.com/
>> Two things need to be cleaned up on pci_create_slot's error path:
>> 1. free slot memory
>> 2. remove slot->list from its parent->slots
>> This patch mistakenly took slot memory as unfreed (which is not),
>> and would introduce double free problem.
>> ---
>> drivers/pci/slot.c | 6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/pci/slot.c b/drivers/pci/slot.c index
>> 3861505..ed2077e 100644
>> --- a/drivers/pci/slot.c
>> +++ b/drivers/pci/slot.c
>> @@ -272,6 +272,9 @@ struct pci_slot *pci_create_slot(struct pci_bus *parent,
>> int slot_nr,
>> goto err;
>> }
>>
>> +INIT_LIST_HEAD(&slot->list);
>> +list_add(&slot->list, &parent->slots);
>> +
>> err = kobject_init_and_add(&slot->kobj, &pci_slot_ktype, NULL,
>> "%s", slot_name);
>> if (err) {
>> @@ -279,9 +282,6 @@ struct pci_slot *pci_create_slot(struct pci_bus *parent,
>> int slot_nr,
>> goto err;
>> }
>>
>> -INIT_LIST_HEAD(&slot->list);
>> -list_add(&slot->list, &parent->slots);
>> -
>> down_read(&pci_bus_sem);
>> list_for_each_entry(dev, &parent->devices, bus_list)
>> if (PCI_SLOT(dev->devfn) == slot_nr)
>> --
>> 1.8.5.6
>>
[PATCH 1/2] arm64: dts: meson: vim3: whitespace fixups
Spaces have been used to indent 2 nodes.
Replace those with tabs and remove one extra newline
Signed-off-by: Jerome Brunet
---
.../boot/dts/amlogic/meson-khadas-vim3.dtsi | 19 +--
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-khadas-vim3.dtsi
b/arch/arm64/boot/dts/amlogic/meson-khadas-vim3.dtsi
index 7b46555ac55a..12465c4becc7 100644
--- a/arch/arm64/boot/dts/amlogic/meson-khadas-vim3.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-khadas-vim3.dtsi
@@ -278,12 +278,12 @@ external_phy: ethernet-phy@0 {
};
ðmac {
-pinctrl-0 = <ð_pins>, <ð_rgmii_pins>;
-pinctrl-names = "default";
-status = "okay";
-phy-mode = "rgmii";
-phy-handle = <&external_phy>;
-amlogic,tx-delay-ns = <2>;
+ pinctrl-0 = <ð_pins>, <ð_rgmii_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+ phy-mode = "rgmii";
+ phy-handle = <&external_phy>;
+ amlogic,tx-delay-ns = <2>;
};
&frddr_a {
@@ -349,9 +349,9 @@ &pcie {
};
&pwm_ef {
-status = "okay";
-pinctrl-0 = <&pwm_e_pins>;
-pinctrl-names = "default";
+ status = "okay";
+ pinctrl-0 = <&pwm_e_pins>;
+ pinctrl-names = "default";
};
&saradc {
@@ -445,7 +445,6 @@ w25q128: spi-flash@0 {
};
};
-
&tdmif_a {
status = "okay";
};
--
2.28.0
[PATCH 0/2] arm64: dts: meson: vim3: enable hdmi audio loopback
This patchset enable the hdmi audio loopback on the vim3 and vim3l. I found a few whitespace errors while doing it. This is sent along to avoid annoying conflicts. Jerome Brunet (2): arm64: dts: meson: vim3: whitespace fixups arm64: dts: meson: vim3: enable hdmi audio loopback .../boot/dts/amlogic/meson-khadas-vim3.dtsi | 60 ++- 1 file changed, 46 insertions(+), 14 deletions(-) -- 2.28.0
[PATCH v5 RESEND] f2fs: compress: add compress_inode to cache compressed blocks
Support to use address space of inner inode to cache compressed block,
in order to improve cache hit ratio of random read.
Signed-off-by: Chao Yu
---
v5:
- rebase to dev branch.
Documentation/filesystems/f2fs.rst | 3 +
fs/f2fs/compress.c | 198 +++--
fs/f2fs/data.c | 29 -
fs/f2fs/debug.c| 13 ++
fs/f2fs/f2fs.h | 34 -
fs/f2fs/gc.c | 1 +
fs/f2fs/inode.c| 21 ++-
fs/f2fs/segment.c | 6 +-
fs/f2fs/super.c| 19 ++-
include/linux/f2fs_fs.h| 1 +
10 files changed, 305 insertions(+), 20 deletions(-)
diff --git a/Documentation/filesystems/f2fs.rst
b/Documentation/filesystems/f2fs.rst
index dae15c96e659..fd413d319e93 100644
--- a/Documentation/filesystems/f2fs.rst
+++ b/Documentation/filesystems/f2fs.rst
@@ -268,6 +268,9 @@ compress_mode=%s Control file compression mode. This
supports "fs" and "user"
choosing the target file and the timing. The user can
do manual
compression/decompression on the compression enabled
files using
ioctls.
+compress_cache Support to use address space of inner inode to cache
+compressed block, in order to improve cache hit ratio
of
+random read.
inlinecrypt When possible, encrypt/decrypt the contents of
encrypted
files using the blk-crypto framework rather than
filesystem-layer encryption. This allows the use of
diff --git a/fs/f2fs/compress.c b/fs/f2fs/compress.c
index 247f4705e897..191f93711f25 100644
--- a/fs/f2fs/compress.c
+++ b/fs/f2fs/compress.c
@@ -12,9 +12,11 @@
#include
#include
#include
+#include
#include "f2fs.h"
#include "node.h"
+#include "segment.h"
#include
static struct kmem_cache *cic_entry_slab;
@@ -721,25 +723,14 @@ static int f2fs_compress_pages(struct compress_ctx *cc)
return ret;
}
-void f2fs_decompress_pages(struct bio *bio, struct page *page, bool verity)
+void f2fs_do_decompress_pages(struct decompress_io_ctx *dic, bool verity)
{
- struct decompress_io_ctx *dic =
- (struct decompress_io_ctx *)page_private(page);
- struct f2fs_sb_info *sbi = F2FS_I_SB(dic->inode);
struct f2fs_inode_info *fi= F2FS_I(dic->inode);
const struct f2fs_compress_ops *cops =
f2fs_cops[fi->i_compress_algorithm];
int ret;
int i;
- dec_page_count(sbi, F2FS_RD_DATA);
-
- if (bio->bi_status || PageError(page))
- dic->failed = true;
-
- if (atomic_dec_return(&dic->pending_pages))
- return;
-
trace_f2fs_decompress_pages_start(dic->inode, dic->cluster_idx,
dic->cluster_size, fi->i_compress_algorithm);
@@ -797,6 +788,7 @@ void f2fs_decompress_pages(struct bio *bio, struct page
*page, bool verity)
ret = cops->decompress_pages(dic);
if (!ret && fi->i_compress_flag & 1 << COMPRESS_CHKSUM) {
+ struct f2fs_sb_info *sbi = F2FS_I_SB(dic->inode);
u32 provided = le32_to_cpu(dic->cbuf->chksum);
u32 calculated = f2fs_crc32(sbi, dic->cbuf->cdata, dic->clen);
@@ -831,6 +823,30 @@ void f2fs_decompress_pages(struct bio *bio, struct page
*page, bool verity)
f2fs_free_dic(dic);
}
+void f2fs_cache_compressed_page(struct f2fs_sb_info *sbi, struct page *page,
+ nid_t ino, block_t blkaddr);
+void f2fs_decompress_pages(struct bio *bio, struct page *page,
+ bool verity, unsigned int ofs)
+{
+ struct decompress_io_ctx *dic =
+ (struct decompress_io_ctx *)page_private(page);
+ struct f2fs_sb_info *sbi = F2FS_I_SB(dic->inode);
+ block_t blkaddr;
+
+ dec_page_count(sbi, F2FS_RD_DATA);
+
+ if (bio->bi_status || PageError(page))
+ dic->failed = true;
+
+ blkaddr = SECTOR_TO_BLOCK(bio->bi_iter.bi_sector) + ofs;
+ f2fs_cache_compressed_page(sbi, page, dic->inode->i_ino, blkaddr);
+
+ if (atomic_dec_return(&dic->pending_pages))
+ return;
+
+ f2fs_do_decompress_pages(dic, verity);
+}
+
static bool is_page_in_cluster(struct compress_ctx *cc, pgoff_t index)
{
if (cc->cluster_idx == NULL_CLUSTER)
@@ -1603,6 +1619,164 @@ void f2fs_decompress_end_io(struct page **rpages,
}
}
+const struct address_space_operations f2fs_compress_aops = {
+ .releasepage = f2fs_release_page,
+ .invalidatepage = f2fs_invalidate_page,
+};
+
+struct address_space *COMPRESS_MAPPING(struct f2fs_sb_info *sbi)
+{
+ return sbi->compress_inode->i_mapping;
+}
+
+void invalidate_compress_page(struct f2fs_sb_info *sbi, block_t blka
