Re: [PATCH v8 3/4] arm64: dts: imx8m: add NVMEM provider and consumer to read soc unique ID
On Mon, Dec 21, 2020 at 03:10:52AM +, Alice Guo (OSS) wrote: > > > > -Original Message- > > From: Krzysztof Kozlowski > > Sent: 2020年12月19日 20:17 > > To: Alice Guo (OSS) > > Cc: robh...@kernel.org; shawn...@kernel.org; s.ha...@pengutronix.de; > > ker...@pengutronix.de; feste...@gmail.com; devicet...@vger.kernel.org; > > linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org; > > dl-linux-imx > > > > Subject: Re: [PATCH v8 3/4] arm64: dts: imx8m: add NVMEM provider and > > consumer to read soc unique ID > > > > On Fri, Dec 18, 2020 at 04:37:25PM +0800, Alice Guo (OSS) wrote: > > > From: Alice Guo > > > > > > In order to be able to use NVMEM APIs to read soc unique ID, add the > > > nvmem data cell and name for nvmem-cells to the "soc" node, and add a > > > nvmem node which provides soc unique ID to efuse@3035. > > > > > > Signed-off-by: Alice Guo > > > --- > > > Changes for v8: > > > - none > > > Changes for v7: > > > - add Reviewed-by > > > > What happened with my reviewed-by? > > > > Best regards, > > Krzysztof > > Hi, > I forgot to add reviewed-by. ☹ It was there already, so you had to remove it for some reason... but you kept the changelog. Best regards, Krzysztof
Re: [PATCH v3 3/5] ipmi: kcs: aspeed: Adapt to new LPC DTS layout
On 12/21/2020 13:56, Chia-Wei, Wang wrote:
Add check against LPC device v2 compatible string to
ensure that the fixed device tree layout is adopted.
The LPC register offsets are also fixed accordingly.
Signed-off-by: Chia-Wei, Wang
---
drivers/char/ipmi/kcs_bmc_aspeed.c | 35 ++
1 file changed, 21 insertions(+), 14 deletions(-)
diff --git a/drivers/char/ipmi/kcs_bmc_aspeed.c
b/drivers/char/ipmi/kcs_bmc_aspeed.c
index a140203c079b..6283bfef4ea7 100644
--- a/drivers/char/ipmi/kcs_bmc_aspeed.c
+++ b/drivers/char/ipmi/kcs_bmc_aspeed.c
@@ -27,7 +27,6 @@
#define KCS_CHANNEL_MAX 4
-/* mapped to lpc-bmc@0 IO space */
#define LPC_HICR00x000
#define LPC_HICR0_LPC3E BIT(7)
#define LPC_HICR0_LPC2E BIT(6)
@@ -52,15 +51,13 @@
#define LPC_STR1 0x03C
#define LPC_STR2 0x040
#define LPC_STR3 0x044
-
-/* mapped to lpc-host@80 IO space */
-#define LPC_HICRB0x080
+#define LPC_HICRB0x100
#define LPC_HICRB_IBFIF4 BIT(1)
#define LPC_HICRB_LPC4E BIT(0)
-#define LPC_LADR40x090
-#define LPC_IDR4 0x094
-#define LPC_ODR4 0x098
-#define LPC_STR4 0x09C
+#define LPC_LADR40x110
+#define LPC_IDR4 0x114
+#define LPC_ODR4 0x118
+#define LPC_STR4 0x11C
struct aspeed_kcs_bmc {
struct regmap *map;
@@ -345,15 +342,25 @@ static int aspeed_kcs_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
struct kcs_bmc *kcs_bmc;
- struct device_node *np;
+ struct device_node *kcs_np;
+ struct device_node *lpc_np;
int rc;
I think you can just use 'np' to do LPC compatible checking:
np = pdev->dev.of_node->parent;
if (!of_device_is_compatible(lpc_np, "aspeed,ast2400-lpc-v2") &&
!of_device_is_compatible(lpc_np, "aspeed,ast2500-lpc-v2") &&
!of_device_is_compatible(lpc_np, "aspeed,ast2600-lpc-v2")) {
dev_err(dev, "unsupported LPC device binding\n");
return -ENODEV;
}
before:
np = pdev->dev.of_node;
if (of_device_is_compatible(np, "aspeed,ast2400-kcs-bmc") ||
of_device_is_compatible(np, "aspeed,ast2500-kcs-bmc"))
Then the patch is clear. ;-)
- np = pdev->dev.of_node;
- if (of_device_is_compatible(np, "aspeed,ast2400-kcs-bmc") ||
- of_device_is_compatible(np, "aspeed,ast2500-kcs-bmc"))
+ kcs_np = dev->of_node;
+ lpc_np = kcs_np->parent;
+
+ if (!of_device_is_compatible(lpc_np, "aspeed,ast2400-lpc-v2") &&
+ !of_device_is_compatible(lpc_np, "aspeed,ast2500-lpc-v2") &&
+ !of_device_is_compatible(lpc_np, "aspeed,ast2600-lpc-v2")) {
+ dev_err(dev, "unsupported LPC device binding\n");
+ return -ENODEV;
+ }
+
+ if (of_device_is_compatible(kcs_np, "aspeed,ast2400-kcs-bmc") ||
+ of_device_is_compatible(kcs_np,
"aspeed,ast2500-kcs-bmc"))
kcs_bmc = aspeed_kcs_probe_of_v1(pdev);
- else if (of_device_is_compatible(np, "aspeed,ast2400-kcs-bmc-v2") ||
- of_device_is_compatible(np,
"aspeed,ast2500-kcs-bmc-v2"))
+ else if (of_device_is_compatible(kcs_np, "aspeed,ast2400-kcs-bmc-v2") ||
+ of_device_is_compatible(kcs_np,
"aspeed,ast2500-kcs-bmc-v2"))
kcs_bmc = aspeed_kcs_probe_of_v2(pdev);
else
return -EINVAL;
Re: [PATCH 9/9] mfd: sec-irq: Do not enforce (incorrect) interrupt trigger type
On Mon, Dec 21, 2020 at 08:36:02AM +0100, Marek Szyprowski wrote: > Hi Krzysztof, > > On 18.12.2020 15:22, Krzysztof Kozlowski wrote: > > On Fri, Dec 18, 2020 at 02:25:39PM +0100, Marek Szyprowski wrote: > >> On 10.12.2020 22:29, Krzysztof Kozlowski wrote: > >>> Interrupt line can be configured on different hardware in different way, > >>> even inverted. Therefore driver should not enforce specific trigger > >>> type - edge falling - but instead rely on Devicetree to configure it. > >>> > >>> The Samsung PMIC drivers are used only on Devicetree boards. > >>> > >>> Additionally, the PMIC datasheets describe the interrupt line as active > >>> low with a requirement of acknowledge from the CPU therefore the edge > >>> falling is not correct. > >>> > >>> Signed-off-by: Krzysztof Kozlowski > >> Tested-by: Marek Szyprowski > >> > >> It looks that this together with DTS change fixes RTC alarm failure that > >> I've observed from time to time on TM2e board! > > Great! I'll add this to the commit msg. > > > > Thanks for testing. > > BTW, while playing with this, maybe it would make sense to fix the > reported interrupt type for the PMIC sub-interrupts: > > # grep s2mps /proc/interrupts > 120: 0 gpa0 7 Level s2mps13 > 121: 0 s2mps13 10 Edge rtc-alarm0 I also spotted this. It's a virtual interrupt and I am not sure whether we can actually configure it when the hardware does not allow to set the type (the regmap_irq_type requires register offsets). Best regards, Krzysztof
[PATCH] docs: driver-model: bus.rst: Clean up the formatting, expound, modernize
* The reStructuredText had some indentation issues.
* The HTML output was not properly formatted in places.
* Some of the details were lacking or needed clarification (especially
with regard to how a `struct bus_type` object should be defined).
* The sysfs example hierarchy appeared outdated; I've updated it with
output based on what my own system currently displays.
Signed-off-by: Michael Witten
---
Documentation/driver-api/driver-model/bus.rst | 110 +
1 file changed, 67 insertions(+), 43 deletions(-)
diff --git a/Documentation/driver-api/driver-model/bus.rst
b/Documentation/driver-api/driver-model/bus.rst
index 016b15a6e8ea..68a95389b1eb 100644
--- a/Documentation/driver-api/driver-model/bus.rst
+++ b/Documentation/driver-api/driver-model/bus.rst
@@ -4,34 +4,58 @@ Bus Types
Definition
~~
-See the kerneldoc for the struct bus_type.
-
-int bus_register(struct bus_type * bus);
+* ``struct bus_type``;
+* ``int bus_register(struct bus_type *bus);``
Declaration
~~~
-Each bus type in the kernel (PCI, USB, etc) should declare one static
-object of this type. They must initialize the name field, and may
-optionally initialize the match callback::
+For each bus type (PCI, USB, etc), there should be code that defines
+one object of type ``struct bus_type``:
+
+1. The definition should declare a file-scope identifier that has
+ external linkage.
+
+ * There should be a header that provides a declaration of this
+ identifier.
+
+ * The identifier should be explicitly exported.
+
+2. The definition should initialize the ``name`` member. Other
+ members may also be initialized (such as the ``match`` callback
+ member).
+
+For instance, here is the definition for the PCI bus type::
- struct bus_type pci_bus_type = {
- .name= "pci",
- .match = pci_bus_match,
- };
+ struct bus_type pci_bus_type = {
+ .name = "pci", // REQUIRED
+ .match = pci_bus_match,
+ .uevent= pci_uevent,
+ .probe = pci_device_probe,
+ .remove= pci_device_remove,
+ .shutdown = pci_device_shutdown,
+ .dev_groups= pci_dev_groups,
+ .bus_groups= pci_bus_groups,
+ .drv_groups= pci_drv_groups,
+ .pm= PCI_PM_OPS_PTR,
+ .num_vf= pci_bus_num_vf,
+ .dma_configure = pci_dma_configure,
+ };
-The structure should be exported to drivers in a header file:
+ EXPORT_SYMBOL(pci_bus_type);
-extern struct bus_type pci_bus_type;
+The relevant API header should include the following declaration::
+
+ extern struct bus_type pci_bus_type;
Registration
-When a bus driver is initialized, it calls bus_register. This
-initializes the rest of the fields in the bus object and inserts it
-into a global list of bus types. Once the bus object is registered,
+During initialization of a bus driver, ``bus_register()`` is called; this
+initializes the rest of the fields in the bus type object and inserts it
+into a global list of bus types. Once the bus type object is registered,
the fields in it are usable by the bus driver.
@@ -61,22 +85,25 @@ does not have a driver associated with it.
Device and Driver Lists
~~~
-The lists of devices and drivers are intended to replace the local
-lists that many buses keep. They are lists of struct devices and
-struct device_drivers, respectively. Bus drivers are free to use the
-lists as they please, but conversion to the bus-specific type may be
-necessary.
+There are generic facilities for keeping lists of devices and drivers:
+
+* There is a list of ``struct device`` objects.
+* There is a list of ``struct device_driver`` objects.
+
+Bus drivers are free to use the lists as they please, but conversion
+to a bus-specific type may be necessary.
The LDM core provides helper functions for iterating over each list::
- int bus_for_each_dev(struct bus_type * bus, struct device * start,
- void * data,
- int (*fn)(struct device *, void *));
+ int bus_for_each_dev(struct bus_type *bus, struct device *start,
+void *data,
+int (*fn)(struct device *, void *));
- int bus_for_each_drv(struct bus_type * bus, struct device_driver * start,
- void * data, int (*fn)(struct device_driver *, void *));
+ int bus_for_each_drv(struct bus_type *bus, struct device_driver *start,
+void *data,
+int (*fn)(struct device_driver *, void *));
-These helpers iterate over the respective list, and call the callback
+These helpers iterate over the respective list, and call the callback (``fn``)
for each device or driver in the list. All list acces
Re: [PATCH v2] docs/zh_CN: Improve Cinese transolation quality.
在 2020/12/19 上午11:42, Ran Wang 写道: > Hi Jonathan, > > On Tuesday, December 8, 2020 11:00 PM Jonathan Corbet wrote: > >> On Tue, 8 Dec 2020 21:16:04 +0800 >> Ran Wang wrote: >> >>> Signed-off-by: Ran Wang >>> --- >>> Change in v2: >>> - For 'cn_development_coding' part, change back to >'是关于编码过程的' >>> >>> .../translations/zh_CN/process/1.Intro.rst | 61 >++- >>> 1 file changed, 32 insertions(+), 29 deletions(-) >> >> Thank you for working to improve the documentation! >Please, though, >> include a changelog with your patch; what does "improve >translation >> quality" mean here? >> >> Thanks, >> >> jon > > Sorry I missed your mail. > > Actually I feel difficult to list the change log to describe this (after not > I am not a language teacher :) ). > > I would say the original translation looks like a little bit more by machine: > English word to Chinese word directly without considering particular > scenarios (such as software development related terms we used in Chinese, a > little bit different to normal usage maybe). So I tried to re-tell the story > in a way more kind of 'human' to make everything clearer for Chinese reader. Hi Ran, I don't think you describe correctly for your new translation. And you are not 're-tell story' for a standard community co-work process, which we don't need. Also the original translation is not by machine, it's by myself. What you did right is polishing the Chinese words, make it more fluency and fit better for Chinese custom, although it costs a bit verboseness and a bit precision. Thanks Alex > > Anyway, I am willing to provide you such change log if you could provide me > an example for reference (this is my first time to post such patch). > > Thanks & Regards, > Ran >
[PATCH RFC v3 1/1] scsi: ufs: Fix ufs power down/on specs violation
As per specs, e.g, JESD220E chapter 7.2, while powering
off/on the ufs device, RST_N signal and REF_CLK signal
should be between VSS(Ground) and VCCQ/VCCQ2.
To flexibly control device reset line, re-name the function
ufschd_vops_device_reset(sturct ufs_hba *hba) to ufshcd_
vops_toggle_device_reset(sturct ufs_hba *hba, bool down). The
new parameter "bool down" is used to separate device reset
line pulling down from pulling up.
Cc: Kiwoong Kim
Cc: Stanley Chu
Signed-off-by: Ziqi Chen
---
drivers/scsi/ufs/ufs-mediatek.c | 27 +-
drivers/scsi/ufs/ufs-qcom.c | 22 ++---
drivers/scsi/ufs/ufshcd.c | 43 ++---
drivers/scsi/ufs/ufshcd.h | 10 +-
4 files changed, 56 insertions(+), 46 deletions(-)
diff --git a/drivers/scsi/ufs/ufs-mediatek.c b/drivers/scsi/ufs/ufs-mediatek.c
index 80618af..bff2c42 100644
--- a/drivers/scsi/ufs/ufs-mediatek.c
+++ b/drivers/scsi/ufs/ufs-mediatek.c
@@ -841,27 +841,18 @@ static int ufs_mtk_link_startup_notify(struct ufs_hba
*hba,
return ret;
}
-static int ufs_mtk_device_reset(struct ufs_hba *hba)
+static int ufs_mtk_toggle_device_reset(struct ufs_hba *hba, bool down)
{
struct arm_smccc_res res;
- ufs_mtk_device_reset_ctrl(0, res);
-
- /*
-* The reset signal is active low. UFS devices shall detect
-* more than or equal to 1us of positive or negative RST_n
-* pulse width.
-*
-* To be on safe side, keep the reset low for at least 10us.
-*/
- usleep_range(10, 15);
-
- ufs_mtk_device_reset_ctrl(1, res);
-
- /* Some devices may need time to respond to rst_n */
- usleep_range(1, 15000);
+ if (down) {
+ ufs_mtk_device_reset_ctrl(0, res);
+ } else {
+ ufs_mtk_device_reset_ctrl(1, res);
- dev_info(hba->dev, "device reset done\n");
+ /* Some devices may need time to respond to rst_n */
+ usleep_range(1, 15000);
+ }
return 0;
}
@@ -1052,7 +1043,7 @@ static const struct ufs_hba_variant_ops ufs_hba_mtk_vops
= {
.suspend = ufs_mtk_suspend,
.resume = ufs_mtk_resume,
.dbg_register_dump = ufs_mtk_dbg_register_dump,
- .device_reset= ufs_mtk_device_reset,
+ .toggle_device_reset= ufs_mtk_toggle_device_reset,
.event_notify= ufs_mtk_event_notify,
};
diff --git a/drivers/scsi/ufs/ufs-qcom.c b/drivers/scsi/ufs/ufs-qcom.c
index 2206b1e..c2ccaa5 100644
--- a/drivers/scsi/ufs/ufs-qcom.c
+++ b/drivers/scsi/ufs/ufs-qcom.c
@@ -1404,12 +1404,13 @@ static void ufs_qcom_dump_dbg_regs(struct ufs_hba *hba)
}
/**
- * ufs_qcom_device_reset() - toggle the (optional) device reset line
+ * ufs_qcom_toggle_device_reset() - toggle the (optional) device reset line
* @hba: per-adapter instance
+ * @down: pull down or pull up device reset line
*
* Toggles the (optional) reset line to reset the attached device.
*/
-static int ufs_qcom_device_reset(struct ufs_hba *hba)
+static int ufs_qcom_toggle_device_reset(struct ufs_hba *hba, bool down)
{
struct ufs_qcom_host *host = ufshcd_get_variant(hba);
@@ -1417,15 +1418,12 @@ static int ufs_qcom_device_reset(struct ufs_hba *hba)
if (!host->device_reset)
return -EOPNOTSUPP;
- /*
-* The UFS device shall detect reset pulses of 1us, sleep for 10us to
-* be on the safe side.
-*/
- gpiod_set_value_cansleep(host->device_reset, 1);
- usleep_range(10, 15);
-
- gpiod_set_value_cansleep(host->device_reset, 0);
- usleep_range(10, 15);
+ if (down) {
+ gpiod_set_value_cansleep(host->device_reset, 1);
+ } else {
+ gpiod_set_value_cansleep(host->device_reset, 0);
+ usleep_range(10, 15);
+ }
return 0;
}
@@ -1473,7 +1471,7 @@ static const struct ufs_hba_variant_ops ufs_hba_qcom_vops
= {
.suspend= ufs_qcom_suspend,
.resume = ufs_qcom_resume,
.dbg_register_dump = ufs_qcom_dump_dbg_regs,
- .device_reset = ufs_qcom_device_reset,
+ .toggle_device_reset= ufs_qcom_toggle_device_reset,
.config_scaling_param = ufs_qcom_config_scaling_param,
.program_key= ufs_qcom_ice_program_key,
};
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index e221add..2ee905f 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -585,7 +585,20 @@ static void ufshcd_device_reset(struct ufs_hba *hba)
{
int err;
- err = ufshcd_vops_device_reset(hba);
+ err = ufshcd_vops_toggle_device_reset(hba, true);
+ if (err) {
+ dev_err(hba->dev, "device reset pulling down failure: %d\n",
err);
+ return;
+ }
+
+ /*
+* The reset signal is activ
[PATCH RFC v2 1/1] scsi: ufs: Fix ufs power down/on specs violation
As per specs, e.g, JESD220E chapter 7.2, while powering
off/on the ufs device, RST_N signal and REF_CLK signal
should be between VSS(Ground) and VCCQ/VCCQ2.
To flexibly control device reset line, re-name the function
ufschd_vops_device_reset(sturct ufs_hba *hba) to ufshcd_
vops_toggle_device_reset(sturct ufs_hba *hba, bool up). The
new parameter "bool up" is used to separate device reset
line pulling up from pulling down.
Cc: Kiwoong Kim
Cc: Stanley Chu
Signed-off-by: Ziqi Chen
---
drivers/scsi/ufs/ufs-mediatek.c | 27 +-
drivers/scsi/ufs/ufs-qcom.c | 22 ++---
drivers/scsi/ufs/ufshcd.c | 43 ++---
drivers/scsi/ufs/ufshcd.h | 10 +-
4 files changed, 56 insertions(+), 46 deletions(-)
diff --git a/drivers/scsi/ufs/ufs-mediatek.c b/drivers/scsi/ufs/ufs-mediatek.c
index 80618af..bff2c42 100644
--- a/drivers/scsi/ufs/ufs-mediatek.c
+++ b/drivers/scsi/ufs/ufs-mediatek.c
@@ -841,27 +841,18 @@ static int ufs_mtk_link_startup_notify(struct ufs_hba
*hba,
return ret;
}
-static int ufs_mtk_device_reset(struct ufs_hba *hba)
+static int ufs_mtk_toggle_device_reset(struct ufs_hba *hba, bool down)
{
struct arm_smccc_res res;
- ufs_mtk_device_reset_ctrl(0, res);
-
- /*
-* The reset signal is active low. UFS devices shall detect
-* more than or equal to 1us of positive or negative RST_n
-* pulse width.
-*
-* To be on safe side, keep the reset low for at least 10us.
-*/
- usleep_range(10, 15);
-
- ufs_mtk_device_reset_ctrl(1, res);
-
- /* Some devices may need time to respond to rst_n */
- usleep_range(1, 15000);
+ if (down) {
+ ufs_mtk_device_reset_ctrl(0, res);
+ } else {
+ ufs_mtk_device_reset_ctrl(1, res);
- dev_info(hba->dev, "device reset done\n");
+ /* Some devices may need time to respond to rst_n */
+ usleep_range(1, 15000);
+ }
return 0;
}
@@ -1052,7 +1043,7 @@ static const struct ufs_hba_variant_ops ufs_hba_mtk_vops
= {
.suspend = ufs_mtk_suspend,
.resume = ufs_mtk_resume,
.dbg_register_dump = ufs_mtk_dbg_register_dump,
- .device_reset= ufs_mtk_device_reset,
+ .toggle_device_reset= ufs_mtk_toggle_device_reset,
.event_notify= ufs_mtk_event_notify,
};
diff --git a/drivers/scsi/ufs/ufs-qcom.c b/drivers/scsi/ufs/ufs-qcom.c
index 2206b1e..c2ccaa5 100644
--- a/drivers/scsi/ufs/ufs-qcom.c
+++ b/drivers/scsi/ufs/ufs-qcom.c
@@ -1404,12 +1404,13 @@ static void ufs_qcom_dump_dbg_regs(struct ufs_hba *hba)
}
/**
- * ufs_qcom_device_reset() - toggle the (optional) device reset line
+ * ufs_qcom_toggle_device_reset() - toggle the (optional) device reset line
* @hba: per-adapter instance
+ * @down: pull down or pull up device reset line
*
* Toggles the (optional) reset line to reset the attached device.
*/
-static int ufs_qcom_device_reset(struct ufs_hba *hba)
+static int ufs_qcom_toggle_device_reset(struct ufs_hba *hba, bool down)
{
struct ufs_qcom_host *host = ufshcd_get_variant(hba);
@@ -1417,15 +1418,12 @@ static int ufs_qcom_device_reset(struct ufs_hba *hba)
if (!host->device_reset)
return -EOPNOTSUPP;
- /*
-* The UFS device shall detect reset pulses of 1us, sleep for 10us to
-* be on the safe side.
-*/
- gpiod_set_value_cansleep(host->device_reset, 1);
- usleep_range(10, 15);
-
- gpiod_set_value_cansleep(host->device_reset, 0);
- usleep_range(10, 15);
+ if (down) {
+ gpiod_set_value_cansleep(host->device_reset, 1);
+ } else {
+ gpiod_set_value_cansleep(host->device_reset, 0);
+ usleep_range(10, 15);
+ }
return 0;
}
@@ -1473,7 +1471,7 @@ static const struct ufs_hba_variant_ops ufs_hba_qcom_vops
= {
.suspend= ufs_qcom_suspend,
.resume = ufs_qcom_resume,
.dbg_register_dump = ufs_qcom_dump_dbg_regs,
- .device_reset = ufs_qcom_device_reset,
+ .toggle_device_reset= ufs_qcom_toggle_device_reset,
.config_scaling_param = ufs_qcom_config_scaling_param,
.program_key= ufs_qcom_ice_program_key,
};
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index e221add..2ee905f 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -585,7 +585,20 @@ static void ufshcd_device_reset(struct ufs_hba *hba)
{
int err;
- err = ufshcd_vops_device_reset(hba);
+ err = ufshcd_vops_toggle_device_reset(hba, true);
+ if (err) {
+ dev_err(hba->dev, "device reset pulling down failure: %d\n",
err);
+ return;
+ }
+
+ /*
+* The reset signal is active lo
Re: [RFC PATCH 0/5] iio: move 'modes' initialization to core
On Sat, Dec 5, 2020 at 8:42 PM Jonathan Cameron wrote:
>
> On Thu, 3 Dec 2020 12:04:18 +0200
> Alexandru Ardelean wrote:
>
> > I stumbled over this, while trying to implement some changes to the IIO
> > buffer logic.
> > Seems that most drivers have a INDIO_DIRECT_MODE, and some have
> > INDIO_BUFFER_SOFTWARE only as a workaround for not having multiple IIO
> > buffer-support-per-IIO-device (yet).
>
> Examples of that particular corner case would be good from a discussion
> point of view.
>
> It's been a while though and those cases were always 'interesting'
> so I may have misremembered how it works!
>
> It is definitely also used to indicate cases where there is no trigger
> to expose (usually devices doing DMA blocks or using a fifo).
> That was the original intent IIRC.
>
> >
> > Since a lot of drivers seem to only support INDIO_DIRECT_MODE, it begs the
> > question whether this starts to make sense as a default 'modes'
> > initialization.
>
> Hmm. Do we need to set it at all, or can we just make it implicit?
> I'm not sure if that is semantically worse than having it set by default
> or not. Thinking about it I think we do want to set it just for
> consistency purposes.
>
> I'm a bit in two minds about this set. It obviously is a noop from
> functional point of view, but it's kind of nice to see the modes
> explicitly called out. I guess we started walking down this route
> anyway when we set IIO_TRIGGERED_BUFFER inside those setup routines.
>
> The bit that bothers me is that it isn't really a 'default' as such
> it just the most common value. I wonder if we could be more clever
> and set it only if there as a channel with _RAW or _PROCESSED
> though that would involve moving it to the registration rather than
> creation.
I'll try to think about it a bit more as well.
I stumbled over this while trying to organize the modes a bit with
triggered-buffer, kfifo and stuff like that.
And this was a quick draft to start a discussion.
But, maybe after some IIO devices get merged into a single IIO device
[with multiple buffers], this would be a little easier to do.
>
> Jonathan
>
> >
> > It opens up the idea of hiding 'indio_dev->modes' inside IIO core, with
> > functions like '{devm_}iio_triggered_buffer_setup()' being able to extend
> > the setup of these 'modes'.
> > This idea is far from being ready, but I thought I'd try this RFC instead
> > as a discussion starter in that direction.
> >
> > Alexandru Ardelean (5):
> > iio: core: initialize 'modes' to INDIO_DIRECT_MODE by default
> > iio,counter: remove modes init for INDIO_DIRECT_MODE only drivers
> > iio: remove modes init for INDIO_DIRECT_MODE only drivers (manual)
> > iio: adc: ad7768-1: remove explicit modes initialization
> > iio: magnetometer: rm3100: remove explicit modes initialization
> >
> > drivers/counter/104-quad-8.c | 1 -
> > drivers/iio/accel/adis16201.c | 1 -
> > drivers/iio/accel/adis16209.c | 1 -
> > drivers/iio/accel/adxl345_core.c | 1 -
> > drivers/iio/accel/bma180.c| 1 -
> > drivers/iio/accel/bma220_spi.c| 1 -
> > drivers/iio/accel/bma400_core.c | 1 -
> > drivers/iio/accel/bmc150-accel-core.c | 1 -
> > drivers/iio/accel/da280.c | 1 -
> > drivers/iio/accel/da311.c | 1 -
> > drivers/iio/accel/dmard06.c | 1 -
> > drivers/iio/accel/dmard09.c | 1 -
> > drivers/iio/accel/dmard10.c | 1 -
> > drivers/iio/accel/hid-sensor-accel-3d.c | 1 -
> > drivers/iio/accel/kxcjk-1013.c| 1 -
> > drivers/iio/accel/kxsd9.c | 1 -
> > drivers/iio/accel/mc3230.c| 1 -
> > drivers/iio/accel/mma7455_core.c | 1 -
> > drivers/iio/accel/mma7660.c | 1 -
> > drivers/iio/accel/mma8452.c | 1 -
> > drivers/iio/accel/mma9551.c | 1 -
> > drivers/iio/accel/mma9553.c | 1 -
> > drivers/iio/accel/mxc4005.c | 1 -
> > drivers/iio/accel/mxc6255.c | 1 -
> > drivers/iio/accel/sca3000.c | 1 -
> > drivers/iio/accel/st_accel_core.c | 1 -
> > drivers/iio/accel/stk8312.c | 1 -
> > drivers/iio/accel/stk8ba50.c | 1 -
> > drivers/iio/adc/ab8500-gpadc.c| 1 -
> > drivers/iio/adc/ad7091r-base.c| 1 -
> > drivers/iio/adc/ad7124.c | 1 -
> > drivers/iio/adc/ad7192.c | 1 -
> > drivers/iio/adc/ad7266.c | 1 -
> > drivers/iio/adc/ad7291.c | 1 -
> > drivers/iio/adc/ad7292.c | 1 -
> > drivers/iio/adc/ad7298.c
Re: [PATCH] dmaengine: qcom: bam_dma: Add LOCK and UNLOCK flag bit support
On 2020-12-19 09:05, Thara Gopinath wrote:
On 12/17/20 9:37 AM, Md Sadre Alam wrote:
This change will add support for LOCK & UNLOCK flag bit support
on CMD descriptor.
If DMA_PREP_LOCK flag passed in prep_slave_sg then requester of this
transaction wanted to lock the DMA controller for this transaction so
BAM driver should set LOCK bit for the HW descriptor.
If DMA_PREP_UNLOCK flag passed in prep_slave_sg then requester of this
transaction wanted to unlock the DMA controller.so BAM driver should
set
UNLOCK bit for the HW descriptor.
Hi,
This is a generic question. What is the point of LOCK/UNLOCK with
allocating LOCK groups to the individual dma channels? By default
doesn't all channels fall in the same group. This would mean that
a lock does not prevent the dma controller from not executing a
transaction on the other channels.
The Pipe Locking/Unlocking will be only on command-descriptor.
Upon encountering a command descriptor with LOCK bit set, the BAM
will lock all other pipes not related to the current pipe group, and
keep
handling the current pipe only until it sees the UNLOCK set then it will
release all locked pipes.
The actual locking is done on the new descriptor fetching for
publishing,
i.e. locked pipe will not fetch new descriptors even if it got
event/events
adding more descriptors for this pipe (locked pipe).
The bam LOCKING mechanism is needed where different cores needs to share
same hardware block which use bam for their transaction. So if both
cores
wanted to access the hardware block in parallel via bam, then locking
mechanism
is needed for bam pipes.
--
Warm Regards
Thara
Signed-off-by: Md Sadre Alam
---
Documentation/driver-api/dmaengine/provider.rst | 9 +
drivers/dma/qcom/bam_dma.c | 9 +
include/linux/dmaengine.h | 5 +
3 files changed, 23 insertions(+)
diff --git a/Documentation/driver-api/dmaengine/provider.rst
b/Documentation/driver-api/dmaengine/provider.rst
index ddb0a81..d7516e2 100644
--- a/Documentation/driver-api/dmaengine/provider.rst
+++ b/Documentation/driver-api/dmaengine/provider.rst
@@ -599,6 +599,15 @@ DMA_CTRL_REUSE
- This flag is only supported if the channel reports the
DMA_LOAD_EOT
capability.
+- DMA_PREP_LOCK
+
+ - If set , the client driver tells DMA controller I am locking you
for
+this transcation.
+
+- DMA_PREP_UNLOCK
+
+ - If set, the client driver will tells DMA controller I am
releasing the lock
+
General Design Notes
diff --git a/drivers/dma/qcom/bam_dma.c b/drivers/dma/qcom/bam_dma.c
index 4eeb8bb..cdbe395 100644
--- a/drivers/dma/qcom/bam_dma.c
+++ b/drivers/dma/qcom/bam_dma.c
@@ -58,6 +58,8 @@ struct bam_desc_hw {
#define DESC_FLAG_EOB BIT(13)
#define DESC_FLAG_NWD BIT(12)
#define DESC_FLAG_CMD BIT(11)
+#define DESC_FLAG_LOCK BIT(10)
+#define DESC_FLAG_UNLOCK BIT(9)
struct bam_async_desc {
struct virt_dma_desc vd;
@@ -644,6 +646,13 @@ static struct dma_async_tx_descriptor
*bam_prep_slave_sg(struct dma_chan *chan,
/* fill in temporary descriptors */
desc = async_desc->desc;
+ if (flags & DMA_PREP_CMD) {
+ if (flags & DMA_PREP_LOCK)
+ desc->flags |= cpu_to_le16(DESC_FLAG_LOCK);
+ if (flags & DMA_PREP_UNLOCK)
+ desc->flags |= cpu_to_le16(DESC_FLAG_UNLOCK);
+ }
+
for_each_sg(sgl, sg, sg_len, i) {
unsigned int remainder = sg_dma_len(sg);
unsigned int curr_offset = 0;
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index dd357a7..79ccadb4 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -190,6 +190,9 @@ struct dma_interleaved_template {
* transaction is marked with DMA_PREP_REPEAT will cause the new
transaction
* to never be processed and stay in the issued queue forever. The
flag is
* ignored if the previous transaction is not a repeated
transaction.
+ * @DMA_PREP_LOCK: tell the driver that DMA HW engine going to be
locked for this
+ * transaction , until not seen DMA_PREP_UNLOCK flag set.
+ * @DMA_PREP_UNLOCK: tell the driver to unlock the DMA HW engine.
*/
enum dma_ctrl_flags {
DMA_PREP_INTERRUPT = (1 << 0),
@@ -202,6 +205,8 @@ enum dma_ctrl_flags {
DMA_PREP_CMD = (1 << 7),
DMA_PREP_REPEAT = (1 << 8),
DMA_PREP_LOAD_EOT = (1 << 9),
+ DMA_PREP_LOCK = (1 << 10),
+ DMA_PREP_UNLOCK = (1 << 11),
};
/**
Re: [PATCH 9/9] mfd: sec-irq: Do not enforce (incorrect) interrupt trigger type
Hi Krzysztof, On 18.12.2020 15:22, Krzysztof Kozlowski wrote: > On Fri, Dec 18, 2020 at 02:25:39PM +0100, Marek Szyprowski wrote: >> On 10.12.2020 22:29, Krzysztof Kozlowski wrote: >>> Interrupt line can be configured on different hardware in different way, >>> even inverted. Therefore driver should not enforce specific trigger >>> type - edge falling - but instead rely on Devicetree to configure it. >>> >>> The Samsung PMIC drivers are used only on Devicetree boards. >>> >>> Additionally, the PMIC datasheets describe the interrupt line as active >>> low with a requirement of acknowledge from the CPU therefore the edge >>> falling is not correct. >>> >>> Signed-off-by: Krzysztof Kozlowski >> Tested-by: Marek Szyprowski >> >> It looks that this together with DTS change fixes RTC alarm failure that >> I've observed from time to time on TM2e board! > Great! I'll add this to the commit msg. > > Thanks for testing. BTW, while playing with this, maybe it would make sense to fix the reported interrupt type for the PMIC sub-interrupts: # grep s2mps /proc/interrupts 120: 0 gpa0 7 Level s2mps13 121: 0 s2mps13 10 Edge rtc-alarm0 Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland
Re: [PATCH] bcache: Trivial fix to bdput
On 12/21/20 11:17 AM, Yi Li wrote: > Trivial fix to bdput. > > Signed-off-by: Yi Li e Hi Yi, Indeed these two fixes are not that trivial. I suggest to describe more detail about why your fixes are necessary and what problems are fixed by your patches. Thanks. Coly Li > --- > drivers/md/bcache/super.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/md/bcache/super.c b/drivers/md/bcache/super.c > index f7ad1e26b013..1756f6926098 100644 > --- a/drivers/md/bcache/super.c > +++ b/drivers/md/bcache/super.c > @@ -2525,8 +2525,8 @@ static ssize_t register_bcache(struct kobject *k, > struct kobj_attribute *attr, > else > err = "device busy"; > mutex_unlock(&bch_register_lock); > - if (!IS_ERR(bdev)) > - bdput(bdev); > + if (!IS_ERR(dev)) > + bdput(dev); > if (attr == &ksysfs_register_quiet) > goto done; > } >
Re: [PATCH] mm/userfaultfd: fix memory corruption due to writeprotect
On Sun, Dec 20, 2020 at 09:39:06PM -0800, Nadav Amit wrote:
> > On Dec 20, 2020, at 9:25 PM, Nadav Amit wrote:
> >
> >> On Dec 20, 2020, at 9:12 PM, Yu Zhao wrote:
> >>
> >> On Sun, Dec 20, 2020 at 08:36:15PM -0800, Nadav Amit wrote:
> On Dec 19, 2020, at 6:20 PM, Andrea Arcangeli
> wrote:
>
> On Sat, Dec 19, 2020 at 02:06:02PM -0800, Nadav Amit wrote:
> >> On Dec 19, 2020, at 1:34 PM, Nadav Amit wrote:
> >>
> >> [ cc’ing some more people who have experience with similar problems ]
> >>
> >>> On Dec 19, 2020, at 11:15 AM, Andrea Arcangeli
> >>> wrote:
> >>>
> >>> Hello,
> >>>
> >>> On Fri, Dec 18, 2020 at 08:30:06PM -0800, Nadav Amit wrote:
> Analyzing this problem indicates that there is a real bug since
> mmap_lock is only taken for read in mwriteprotect_range(). This might
> >>>
> >>> Never having to take the mmap_sem for writing, and in turn never
> >>> blocking, in order to modify the pagetables is quite an important
> >>> feature in uffd that justifies uffd instead of mprotect. It's not the
> >>> most important reason to use uffd, but it'd be nice if that guarantee
> >>> would remain also for the UFFDIO_WRITEPROTECT API, not only for the
> >>> other pgtable manipulations.
> >>>
> Consider the following scenario with 3 CPUs (cpu2 is not shown):
>
> cpu0 cpu1
>
> userfaultfd_writeprotect()
> [ write-protecting ]
> mwriteprotect_range()
> mmap_read_lock()
> change_protection()
> change_protection_range()
> ...
> change_pte_range()
> [ defer TLB flushes]
> userfaultfd_writeprotect()
> mmap_read_lock()
> change_protection()
> [ write-unprotect ]
> ...
> [ unprotect PTE logically ]
>
> Is the uffd selftest failing with upstream or after your kernel
> modification that removes the tlb flush from unprotect?
> >>>
> >>> Please see my reply to Yu. I was wrong in this analysis, and I sent a
> >>> correction to my analysis. The problem actually happens when
> >>> userfaultfd_writeprotect() unprotects the memory.
> >>>
> } else if (uffd_wp_resolve) {
> /*
> * Leave the write bit to be handled
> * by PF interrupt handler, then
> * things like COW could be properly
> * handled.
> */
> ptent = pte_clear_uffd_wp(ptent);
> }
>
> Upstraem this will still do pages++, there's a tlb flush before
> change_protection can return here, so I'm confused.
> >>>
> >>> You are correct. The problem I encountered with userfaultfd_writeprotect()
> >>> is during unprotecting path.
> >>>
> >>> Having said that, I think that there are additional scenarios that are
> >>> problematic. Consider for instance madvise_dontneed_free() that is racing
> >>> with userfaultfd_writeprotect(). If madvise_dontneed_free() completed
> >>> removing the PTEs, but still did not flush, change_pte_range() will see
> >>> non-present PTEs, say a flush is not needed, and then
> >>> change_protection_range() will not do a flush, and return while
> >>> the memory is still not protected.
> >>>
> I don't share your concern. What matters is the PT lock, so it
> wouldn't be one per pte, but a least an order 9 higher, but let's
> assume one flush per pte.
>
> It's either huge mapping and then it's likely running without other
> tlb flushing in background (postcopy snapshotting), or it's a granular
> protect with distributed shared memory in which case the number of
> changd ptes or huge_pmds tends to be always 1 anyway. So it doesn't
> matter if it's deferred.
>
> I agree it may require a larger tlb flush review not just mprotect
> though, but it didn't sound particularly complex. Note the
> UFFDIO_WRITEPROTECT is still relatively recent so backports won't
> risk to reject so heavy as to require a band-aid.
>
> My second thought is, I don't see exactly the bug and it's not clear
> if it's upstream reproducing this, but assuming this happens on
> upstream, even ignoring everything else happening in the tlb flush
> code, this sounds like purely introduced by userfaultfd_writeprotect()
> vs userfaultfd_writeprotect() (since it's the only place changing
> protection with mmap_sem for reading and note we already unmap and
> flush tlb with mmap_sem for reading in
[PATCH 1/2] tools/power/x86/intel-speed-select: Set scaling_max_freq to base_frequency
When BIOS disables turbo, The scaling_max_freq in cpufreq sysfs will be
limited to config level 0 base frequency. But when user selects a higher
config levels, this will result in higher base frequency. But since
scaling_max_freq is still old base frequency, the performance will still
be limited. So when the turbo is disabled and cpufreq base_frequency is
higher than scaling_max_freq, update the scaling_max_freq to the
base_frequency.
Signed-off-by: Srinivas Pandruvada
---
.../x86/intel-speed-select/isst-config.c | 21 +++
1 file changed, 21 insertions(+)
diff --git a/tools/power/x86/intel-speed-select/isst-config.c
b/tools/power/x86/intel-speed-select/isst-config.c
index 5390158cdb40..9b6f0e6f150d 100644
--- a/tools/power/x86/intel-speed-select/isst-config.c
+++ b/tools/power/x86/intel-speed-select/isst-config.c
@@ -1249,6 +1249,8 @@ static void dump_isst_config(int arg)
isst_ctdp_display_information_end(outf);
}
+static void adjust_scaling_max_from_base_freq(int cpu);
+
static void set_tdp_level_for_cpu(int cpu, void *arg1, void *arg2, void *arg3,
void *arg4)
{
@@ -1267,6 +1269,9 @@ static void set_tdp_level_for_cpu(int cpu, void *arg1,
void *arg2, void *arg3,
int pkg_id = get_physical_package_id(cpu);
int die_id = get_physical_die_id(cpu);
+ /* Wait for updated base frequencies */
+ usleep(2000);
+
fprintf(stderr, "Option is set to online/offline\n");
ctdp_level.core_cpumask_size =
alloc_cpu_set(&ctdp_level.core_cpumask);
@@ -1283,6 +1288,7 @@ static void set_tdp_level_for_cpu(int cpu, void *arg1,
void *arg2, void *arg3,
if (CPU_ISSET_S(i,
ctdp_level.core_cpumask_size, ctdp_level.core_cpumask)) {
fprintf(stderr, "online cpu
%d\n", i);
set_cpu_online_offline(i, 1);
+
adjust_scaling_max_from_base_freq(i);
} else {
fprintf(stderr, "offline cpu
%d\n", i);
set_cpu_online_offline(i, 0);
@@ -1440,6 +1446,21 @@ static int set_cpufreq_scaling_min_max(int cpu, int max,
int freq)
return 0;
}
+static int no_turbo(void)
+{
+ return parse_int_file(0,
"/sys/devices/system/cpu/intel_pstate/no_turbo");
+}
+
+static void adjust_scaling_max_from_base_freq(int cpu)
+{
+ int base_freq, scaling_max_freq;
+
+ scaling_max_freq = parse_int_file(0,
"/sys/devices/system/cpu/cpu%d/cpufreq/scaling_max_freq", cpu);
+ base_freq = get_cpufreq_base_freq(cpu);
+ if (scaling_max_freq < base_freq || no_turbo())
+ set_cpufreq_scaling_min_max(cpu, 1, base_freq);
+}
+
static int set_clx_pbf_cpufreq_scaling_min_max(int cpu)
{
struct isst_pkg_ctdp_level_info *ctdp_level;
--
2.29.2
[PATCH 2/2] tools/power/x86/intel-speed-select: Set higher of cpuinfo_max_freq or base_frequency
In some case when BIOS disabled turbo, cpufreq cpuinfo_max_freq can be
lower than base_frequency at higher config level. So, in that case set
scaling_min_freq to base_frequency.
Signed-off-by: Srinivas Pandruvada
---
tools/power/x86/intel-speed-select/isst-config.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/tools/power/x86/intel-speed-select/isst-config.c
b/tools/power/x86/intel-speed-select/isst-config.c
index 9b6f0e6f150d..09cb3a6672f3 100644
--- a/tools/power/x86/intel-speed-select/isst-config.c
+++ b/tools/power/x86/intel-speed-select/isst-config.c
@@ -1461,6 +1461,16 @@ static void adjust_scaling_max_from_base_freq(int cpu)
set_cpufreq_scaling_min_max(cpu, 1, base_freq);
}
+static void adjust_scaling_min_from_base_freq(int cpu)
+{
+ int base_freq, scaling_min_freq;
+
+ scaling_min_freq = parse_int_file(0,
"/sys/devices/system/cpu/cpu%d/cpufreq/scaling_min_freq", cpu);
+ base_freq = get_cpufreq_base_freq(cpu);
+ if (scaling_min_freq < base_freq)
+ set_cpufreq_scaling_min_max(cpu, 0, base_freq);
+}
+
static int set_clx_pbf_cpufreq_scaling_min_max(int cpu)
{
struct isst_pkg_ctdp_level_info *ctdp_level;
@@ -1558,6 +1568,7 @@ static void set_scaling_min_to_cpuinfo_max(int cpu)
continue;
set_cpufreq_scaling_min_max_from_cpuinfo(i, 1, 0);
+ adjust_scaling_min_from_base_freq(i);
}
}
--
2.29.2
tools/power/x86/intel-speed-select: Fixes for regression
One side-effect of fixing the scaling frequency limits using the
commit eacc9c5a927e ("cpufreq: intel_pstate: Fix intel_pstate_get_hwp_max()
for turbo disabled") causes stale HWP_CAP.GUARANTEED to be used as max.
Without processing HWP interrupts, user space needs to be able to update
a new max while Intel SST is in use. This is not a problem as the
change of guaranteed is caused by user space action, so user space knows
that guarantee will change.
This series causes user space to trigger scaling_max_freq update with
the new base_frequency.
Srinivas Pandruvada (2):
tools/power/x86/intel-speed-select: Set scaling_max_freq to
base_frequency
tools/power/x86/intel-speed-select: Set higher of cpuinfo_max_freq or
base_frequency
.../x86/intel-speed-select/isst-config.c | 32 +++
1 file changed, 32 insertions(+)
--
2.29.2
drivers/block/loop.c:1729:1: warning: the frame size of 1072 bytes is larger than 1024 bytes
Hi Martijn,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 467f8165a2b0e6accf3d0dd9c8089b1dbde29f7f
commit: 3448914e8cc550ba792d4ccc74471d1ca4293aae loop: Add LOOP_CONFIGURE ioctl
date: 7 months ago
config: arm-randconfig-r026-20201221 (attached as .config)
compiler: arm-linux-gnueabi-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://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3448914e8cc550ba792d4ccc74471d1ca4293aae
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 3448914e8cc550ba792d4ccc74471d1ca4293aae
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arm
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
drivers/block/loop.c: In function 'lo_ioctl':
>> drivers/block/loop.c:1729:1: warning: the frame size of 1072 bytes is larger
>> than 1024 bytes [-Wframe-larger-than=]
1729 | }
| ^
vim +1729 drivers/block/loop.c
a13165441d58b21 Jan Kara2018-11-08 1667
a13165441d58b21 Jan Kara2018-11-08 1668 static int
lo_ioctl(struct block_device *bdev, fmode_t mode,
a13165441d58b21 Jan Kara2018-11-08 1669unsigned int cmd,
unsigned long arg)
a13165441d58b21 Jan Kara2018-11-08 1670 {
a13165441d58b21 Jan Kara2018-11-08 1671struct loop_device *lo
= bdev->bd_disk->private_data;
571fae6e290d64a Martijn Coenen 2020-05-13 1672void __user *argp =
(void __user *) arg;
a13165441d58b21 Jan Kara2018-11-08 1673int err;
3148ffbdb9162ba Omar Sandoval 2018-03-26 1674
^1da177e4c3f415 Linus Torvalds 2005-04-16 1675switch (cmd) {
3448914e8cc550b Martijn Coenen 2020-05-13 1676case LOOP_SET_FD: {
3448914e8cc550b Martijn Coenen 2020-05-13 1677/*
3448914e8cc550b Martijn Coenen 2020-05-13 1678 * Legacy case
- pass in a zeroed out struct loop_config with
3448914e8cc550b Martijn Coenen 2020-05-13 1679 * only the
file descriptor set , which corresponds with the
3448914e8cc550b Martijn Coenen 2020-05-13 1680 * default
parameters we'd have used otherwise.
3448914e8cc550b Martijn Coenen 2020-05-13 1681 */
3448914e8cc550b Martijn Coenen 2020-05-13 1682struct
loop_config config;
3448914e8cc550b Martijn Coenen 2020-05-13 1683
3448914e8cc550b Martijn Coenen 2020-05-13 1684memset(&config,
0, sizeof(config));
3448914e8cc550b Martijn Coenen 2020-05-13 1685config.fd = arg;
3448914e8cc550b Martijn Coenen 2020-05-13 1686
3448914e8cc550b Martijn Coenen 2020-05-13 1687return
loop_configure(lo, mode, bdev, &config);
3448914e8cc550b Martijn Coenen 2020-05-13 1688}
3448914e8cc550b Martijn Coenen 2020-05-13 1689case LOOP_CONFIGURE: {
3448914e8cc550b Martijn Coenen 2020-05-13 1690struct
loop_config config;
3448914e8cc550b Martijn Coenen 2020-05-13 1691
3448914e8cc550b Martijn Coenen 2020-05-13 1692if
(copy_from_user(&config, argp, sizeof(config)))
3448914e8cc550b Martijn Coenen 2020-05-13 1693return
-EFAULT;
3448914e8cc550b Martijn Coenen 2020-05-13 1694
3448914e8cc550b Martijn Coenen 2020-05-13 1695return
loop_configure(lo, mode, bdev, &config);
3448914e8cc550b Martijn Coenen 2020-05-13 1696}
^1da177e4c3f415 Linus Torvalds 2005-04-16 1697case LOOP_CHANGE_FD:
c371077000f4138 Jan Kara2018-11-08 1698return
loop_change_fd(lo, bdev, arg);
^1da177e4c3f415 Linus Torvalds 2005-04-16 1699case LOOP_CLR_FD:
7ccd0791d98531d Jan Kara2018-11-08 1700return
loop_clr_fd(lo);
^1da177e4c3f415 Linus Torvalds 2005-04-16 1701case LOOP_SET_STATUS:
7035b5df3c071cc Dmitry Monakhov 2011-11-16 1702err = -EPERM;
a13165441d58b21 Jan Kara2018-11-08 1703if ((mode &
FMODE_WRITE) || capable(CAP_SYS_ADMIN)) {
571fae6e290d64a Martijn Coenen 2020-05-13 1704err =
loop_set_status_old(lo, argp);
a13165441d58b21 Jan Kara2018-11-08 1705}
^1da177e4c3f415 Linus Torvalds 2005-04-16 1706break;
^1da177e4c3f415 Linus Torvalds 2005-04-16 1707case LOOP_GET_STATUS:
571fae6e290d64a Martijn Coenen 2020-05-13 1708return
loop_get_status_old(lo, argp);
^1da177e4c3f415 Linus Torvalds 2005-04-
[PATCH] kconfig: doc: fix $(fileno) to $(filename)
This is a typo. Signed-off-by: Masahiro Yamada --- Documentation/kbuild/kconfig-macro-language.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/kbuild/kconfig-macro-language.rst b/Documentation/kbuild/kconfig-macro-language.rst index 8b413ef9603d..6163467f6ae4 100644 --- a/Documentation/kbuild/kconfig-macro-language.rst +++ b/Documentation/kbuild/kconfig-macro-language.rst @@ -97,7 +97,7 @@ Like Make, Kconfig provides several built-in functions. Every function takes a particular number of arguments. In Make, every built-in function takes at least one argument. Kconfig allows -zero argument for built-in functions, such as $(fileno), $(lineno). You could +zero argument for built-in functions, such as $(filename), $(lineno). You could consider those as "built-in variable", but it is just a matter of how we call it after all. Let's say "built-in function" here to refer to natively supported functionality. -- 2.27.0
[PATCH 1/3] perf tools: Use /proc//task//status for synthesis
To save memory usage, it needs to reduce number of entries in the proc
filesystem. It's using /proc//task directory to traverse threads
in the process and then kernel creates /proc//task/ entries.
After that it checks the thread info using the /proc//status file
rather than /proc//task//status. As far as I can see, they
are the same and contain all the info we need.
Using the latter eliminates the unnecessary /proc/ entry. This
can be useful especially a large number of threads are used in the
system. In my experiment around 1KB of memory on average was saved
for each thread (which is not a thread group leader).
To do this, pass both pid and tid to perf_event_prepare_comm() if it
knows them. In case it doesn't know, passing 0 as pid will do the old
way.
Signed-off-by: Namhyung Kim
---
tools/perf/util/synthetic-events.c | 30 +++---
1 file changed, 19 insertions(+), 11 deletions(-)
diff --git a/tools/perf/util/synthetic-events.c
b/tools/perf/util/synthetic-events.c
index 2947e3f3c6d9..515d145a4303 100644
--- a/tools/perf/util/synthetic-events.c
+++ b/tools/perf/util/synthetic-events.c
@@ -69,7 +69,7 @@ int perf_tool__process_synth_event(struct perf_tool *tool,
* Assumes that the first 4095 bytes of /proc/pid/stat contains
* the comm, tgid and ppid.
*/
-static int perf_event__get_comm_ids(pid_t pid, char *comm, size_t len,
+static int perf_event__get_comm_ids(pid_t pid, pid_t tid, char *comm, size_t
len,
pid_t *tgid, pid_t *ppid)
{
char bf[4096];
@@ -81,7 +81,10 @@ static int perf_event__get_comm_ids(pid_t pid, char *comm,
size_t len,
*tgid = -1;
*ppid = -1;
- snprintf(bf, sizeof(bf), "/proc/%d/status", pid);
+ if (pid)
+ snprintf(bf, sizeof(bf), "/proc/%d/task/%d/status", pid, tid);
+ else
+ snprintf(bf, sizeof(bf), "/proc/%d/status", tid);
fd = open(bf, O_RDONLY);
if (fd < 0) {
@@ -93,7 +96,7 @@ static int perf_event__get_comm_ids(pid_t pid, char *comm,
size_t len,
close(fd);
if (n <= 0) {
pr_warning("Couldn't get COMM, tigd and ppid for pid %d\n",
- pid);
+ tid);
return -1;
}
bf[n] = '\0';
@@ -116,27 +119,32 @@ static int perf_event__get_comm_ids(pid_t pid, char
*comm, size_t len,
memcpy(comm, name, size);
comm[size] = '\0';
} else {
- pr_debug("Name: string not found for pid %d\n", pid);
+ pr_debug("Name: string not found for pid %d\n", tid);
}
if (tgids) {
tgids += 5; /* strlen("Tgid:") */
*tgid = atoi(tgids);
+
+ if (pid && pid != *tgid) {
+ pr_debug("Tgid: not match to given pid: %d vs %d\n",
+pid, *tgid);
+ }
} else {
- pr_debug("Tgid: string not found for pid %d\n", pid);
+ pr_debug("Tgid: string not found for pid %d\n", tid);
}
if (ppids) {
ppids += 5; /* strlen("PPid:") */
*ppid = atoi(ppids);
} else {
- pr_debug("PPid: string not found for pid %d\n", pid);
+ pr_debug("PPid: string not found for pid %d\n", tid);
}
return 0;
}
-static int perf_event__prepare_comm(union perf_event *event, pid_t pid,
+static int perf_event__prepare_comm(union perf_event *event, pid_t pid, pid_t
tid,
struct machine *machine,
pid_t *tgid, pid_t *ppid)
{
@@ -147,7 +155,7 @@ static int perf_event__prepare_comm(union perf_event
*event, pid_t pid,
memset(&event->comm, 0, sizeof(event->comm));
if (machine__is_host(machine)) {
- if (perf_event__get_comm_ids(pid, event->comm.comm,
+ if (perf_event__get_comm_ids(pid, tid, event->comm.comm,
sizeof(event->comm.comm),
tgid, ppid) != 0) {
return -1;
@@ -168,7 +176,7 @@ static int perf_event__prepare_comm(union perf_event
*event, pid_t pid,
event->comm.header.size = (sizeof(event->comm) -
(sizeof(event->comm.comm) - size) +
machine->id_hdr_size);
- event->comm.tid = pid;
+ event->comm.tid = tid;
return 0;
}
@@ -180,7 +188,7 @@ pid_t perf_event__synthesize_comm(struct perf_tool *tool,
{
pid_t tgid, ppid;
- if (perf_event__prepare_comm(event, pid, machine, &tgid, &ppid) != 0)
+ if (perf_event__prepare_comm(event, 0, pid, machine, &tgid, &ppid) != 0)
return -1;
if (perf_tool__process_synth_event(tool, event, machine, process) != 0)
@@ -701,7 +709,7 @@ static int __event__synthesize_thread(un
[PATCH] kconfig: doc: fix $(fileno) to $(filename)
This is a typo. Signed-off-by: Masahiro Yamada --- Documentation/kbuild/kconfig-macro-language.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/kbuild/kconfig-macro-language.rst b/Documentation/kbuild/kconfig-macro-language.rst index 8b413ef9603d..6163467f6ae4 100644 --- a/Documentation/kbuild/kconfig-macro-language.rst +++ b/Documentation/kbuild/kconfig-macro-language.rst @@ -97,7 +97,7 @@ Like Make, Kconfig provides several built-in functions. Every function takes a particular number of arguments. In Make, every built-in function takes at least one argument. Kconfig allows -zero argument for built-in functions, such as $(fileno), $(lineno). You could +zero argument for built-in functions, such as $(filename), $(lineno). You could consider those as "built-in variable", but it is just a matter of how we call it after all. Let's say "built-in function" here to refer to natively supported functionality. -- 2.27.0
[PATCH 3/3] perf tools: Use scandir() to iterate threads
Like in __event__synthesize_thread(), I think it's better to use
scandir() instead of the readdir() loop. In case some malicious task
continues to create new threads, the readdir() loop will run over and
over to collect tids. The scandir() also has the problem but the
window is much smaller since it doesn't do much work during the
iteration.
Also add filter_task() function as we only care the tasks.
Signed-off-by: Namhyung Kim
---
tools/perf/util/synthetic-events.c | 28 +---
1 file changed, 17 insertions(+), 11 deletions(-)
diff --git a/tools/perf/util/synthetic-events.c
b/tools/perf/util/synthetic-events.c
index 153a822f411a..36cda93318a4 100644
--- a/tools/perf/util/synthetic-events.c
+++ b/tools/perf/util/synthetic-events.c
@@ -664,6 +664,11 @@ int perf_event__synthesize_modules(struct perf_tool *tool,
perf_event__handler_t
return rc;
}
+static int filter_task(const struct dirent *dirent)
+{
+ return isdigit(dirent->d_name[0]);
+}
+
static int __event__synthesize_thread(union perf_event *comm_event,
union perf_event *mmap_event,
union perf_event *fork_event,
@@ -672,10 +677,10 @@ static int __event__synthesize_thread(union perf_event
*comm_event,
struct perf_tool *tool, struct machine
*machine, bool mmap_data)
{
char filename[PATH_MAX];
- DIR *tasks;
- struct dirent *dirent;
+ struct dirent **dirent;
pid_t tgid, ppid;
int rc = 0;
+ int i, n;
/* special case: only send one comm event using passed in pid */
if (!full) {
@@ -707,18 +712,16 @@ static int __event__synthesize_thread(union perf_event
*comm_event,
snprintf(filename, sizeof(filename), "%s/proc/%d/task",
machine->root_dir, pid);
- tasks = opendir(filename);
- if (tasks == NULL) {
- pr_debug("couldn't open %s\n", filename);
- return 0;
- }
+ n = scandir(filename, &dirent, filter_task, alphasort);
+ if (n < 0)
+ return n;
- while ((dirent = readdir(tasks)) != NULL) {
+ for (i = 0; i < n; i++) {
char *end;
pid_t _pid;
bool kernel_thread;
- _pid = strtol(dirent->d_name, &end, 10);
+ _pid = strtol(dirent[i]->d_name, &end, 10);
if (*end)
continue;
@@ -751,7 +754,10 @@ static int __event__synthesize_thread(union perf_event
*comm_event,
}
}
- closedir(tasks);
+ for (i = 0; i < n; i++)
+ zfree(&dirent[i]);
+ free(dirent);
+
return rc;
}
@@ -936,7 +942,7 @@ int perf_event__synthesize_threads(struct perf_tool *tool,
return 0;
snprintf(proc_path, sizeof(proc_path), "%s/proc", machine->root_dir);
- n = scandir(proc_path, &dirent, 0, alphasort);
+ n = scandir(proc_path, &dirent, filter_task, alphasort);
if (n < 0)
return err;
--
2.29.2.684.gfbc64c5ab5-goog
[PATCH 2/3] perf tools: Skip MMAP record synthesis for kernel threads
To synthesize information to resolve sample IPs, it needs to scan task
and mmap info from the /proc filesystem. For each process, it
opens (and reads) status and maps file respectively. But as kernel
threads don't have memory maps so we can skip the maps file.
To find kernel threads, check "VmPeak:" line in /proc//status
file. It's about the peak virtual memory usage so only user-level
tasks have that. Also check "Threads:" line (which follows the VmPeak
line whether or not it exists) to be sure it's read enough data - just
in case of deeply nested pid namespaces or large number of
supplementary groups are involved.
This is for user process:
$ head -40 /proc/1/status
Name: systemd
Umask:
State:S (sleeping)
Tgid: 1
Ngid: 0
Pid: 1
PPid: 0
TracerPid:0
Uid: 0 0 0 0
Gid: 0 0 0 0
FDSize: 256
Groups:
NStgid: 1
NSpid:1
NSpgid: 1
NSsid:1
VmPeak: 234192 kB <-- here
VmSize: 169964 kB
VmLck: 0 kB
VmPin: 0 kB
VmHWM: 29528 kB
VmRSS:6104 kB
RssAnon: 2756 kB
RssFile: 3348 kB
RssShmem:0 kB
VmData: 19776 kB
VmStk:1036 kB
VmExe: 784 kB
VmLib:9532 kB
VmPTE: 116 kB
VmSwap: 2400 kB
HugetlbPages:0 kB
CoreDumping: 0
THP_enabled: 1
Threads: 1 <-- and here
SigQ: 1/62808
SigPnd:
ShdPnd:
SigBlk: 7be3c0fe28014a03
SigIgn: 1000
And this is for kernel thread:
$ head -20 /proc/2/status
Name: kthreadd
Umask:
State:S (sleeping)
Tgid: 2
Ngid: 0
Pid: 2
PPid: 0
TracerPid:0
Uid: 0 0 0 0
Gid: 0 0 0 0
FDSize: 64
Groups:
NStgid: 2
NSpid:2
NSpgid: 0
NSsid:0
Threads: 1 <-- here
SigQ: 1/62808
SigPnd:
ShdPnd:
Signed-off-by: Namhyung Kim
---
tools/perf/util/synthetic-events.c | 32 +-
1 file changed, 23 insertions(+), 9 deletions(-)
diff --git a/tools/perf/util/synthetic-events.c
b/tools/perf/util/synthetic-events.c
index 515d145a4303..153a822f411a 100644
--- a/tools/perf/util/synthetic-events.c
+++ b/tools/perf/util/synthetic-events.c
@@ -70,13 +70,13 @@ int perf_tool__process_synth_event(struct perf_tool *tool,
* the comm, tgid and ppid.
*/
static int perf_event__get_comm_ids(pid_t pid, pid_t tid, char *comm, size_t
len,
- pid_t *tgid, pid_t *ppid)
+ pid_t *tgid, pid_t *ppid, bool *kernel)
{
char bf[4096];
int fd;
size_t size = 0;
ssize_t n;
- char *name, *tgids, *ppids;
+ char *name, *tgids, *ppids, *vmpeak, *threads;
*tgid = -1;
*ppid = -1;
@@ -102,8 +102,14 @@ static int perf_event__get_comm_ids(pid_t pid, pid_t tid,
char *comm, size_t len
bf[n] = '\0';
name = strstr(bf, "Name:");
- tgids = strstr(bf, "Tgid:");
- ppids = strstr(bf, "PPid:");
+ tgids = strstr(name ?: bf, "Tgid:");
+ ppids = strstr(tgids ?: bf, "PPid:");
+ vmpeak = strstr(ppids ?: bf, "VmPeak:");
+
+ if (vmpeak)
+ threads = NULL;
+ else
+ threads = strstr(ppids ?: bf, "Threads:");
if (name) {
char *nl;
@@ -141,12 +147,17 @@ static int perf_event__get_comm_ids(pid_t pid, pid_t tid,
char *comm, size_t len
pr_debug("PPid: string not found for pid %d\n", tid);
}
+ if (!vmpeak && threads)
+ *kernel = true;
+ else
+ *kernel = false;
+
return 0;
}
static int perf_event__prepare_comm(union perf_event *event, pid_t pid, pid_t
tid,
struct machine *machine,
- pid_t *tgid, pid_t *ppid)
+ pid_t *tgid, pid_t *ppid, bool *kernel)
{
size_t size;
@@ -157,7 +168,7 @@ static int perf_event__prepare_comm(union perf_event
*event, pid_t pid, pid_t ti
if (machine__is_host(machine)) {
if (perf_event__get_comm_ids(pid, tid, event->comm.comm,
sizeof(event->comm.comm),
-tgid, ppid) != 0) {
+tgid, ppid, kernel) != 0) {
return -1;
}
} else {
@@ -187,8 +198,10 @@ pid_t perf_event__synthesize_comm(struct perf_tool *tool,
struct machine *machine)
{
pid_t tgid, ppid;
+ bool kernel_thread;
- if (perf_event__prepare_co
[PATCH 0/3] perf tools: Minor improvements in event synthesis
Hello, This is to optimize the event synthesis during perf record. The first patch is to reduce memory usage when many threads are used. The second is to avoid unncessary syscalls for kernel threads. And the last one is to reduce the number of threads to iterate when new threads are being created at the same time. Unfortunately there's no dramatic improvement here but I can see ~5% gain in the 'perf bench internals synthesize' on a big machine. (The numbers are not stable though) Before: # perf bench internals synthesize --mt -M1 -I 100 # Running 'internals/synthesize' benchmark: Computing performance of multi threaded perf event synthesis by synthesizing events on CPU 0: Number of synthesis threads: 1 Average synthesis took: 68831.480 usec (+- 101.450 usec) Average num. events: 9982.000 (+- 0.000) Average time per event 6.896 usec After: # perf bench internals synthesize --mt -M1 -I 100 # Running 'internals/synthesize' benchmark: Computing performance of multi threaded perf event synthesis by synthesizing events on CPU 0: Number of synthesis threads: 1 Average synthesis took: 65036.370 usec (+- 158.121 usec) Average num. events: 9982.000 (+- 0.000) Average time per event 6.515 usec Thanks, Namhyung Namhyung Kim (3): perf tools: Use /proc//task//status for synthesis perf tools: Skip MMAP record synthesis for kernel threads perf tools: Use scandir() to iterate threads tools/perf/util/synthetic-events.c | 88 -- 1 file changed, 58 insertions(+), 30 deletions(-) -- 2.29.2.684.gfbc64c5ab5-goog
drivers/gpu/drm/msm/dp/dp_display.c:496:19: warning: variable 'hpd' set but not used
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 467f8165a2b0e6accf3d0dd9c8089b1dbde29f7f
commit: c58eb1b54feefc3a47fab78addd14083bc941c44 drm/msm/dp: fix
connect/disconnect handled at irq_hpd
date: 3 weeks ago
config: arm-randconfig-r035-20201220 (attached as .config)
compiler: arm-linux-gnueabi-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://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c58eb1b54feefc3a47fab78addd14083bc941c44
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout c58eb1b54feefc3a47fab78addd14083bc941c44
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arm
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
drivers/gpu/drm/msm/dp/dp_display.c: In function
'dp_display_usbpd_attention_cb':
>> drivers/gpu/drm/msm/dp/dp_display.c:496:19: warning: variable 'hpd' set but
>> not used [-Wunused-but-set-variable]
496 | struct dp_usbpd *hpd;
| ^~~
vim +/hpd +496 drivers/gpu/drm/msm/dp/dp_display.c
c943b4948b5848f Chandan Uddaraju 2020-08-27 490
c943b4948b5848f Chandan Uddaraju 2020-08-27 491 static int
dp_display_usbpd_attention_cb(struct device *dev)
c943b4948b5848f Chandan Uddaraju 2020-08-27 492 {
c943b4948b5848f Chandan Uddaraju 2020-08-27 493int rc = 0;
26b8d66a399e625 Kuogee Hsieh 2020-11-03 494u32 sink_request;
c943b4948b5848f Chandan Uddaraju 2020-08-27 495struct
dp_display_private *dp;
26b8d66a399e625 Kuogee Hsieh 2020-11-03 @496struct dp_usbpd *hpd;
c943b4948b5848f Chandan Uddaraju 2020-08-27 497
c943b4948b5848f Chandan Uddaraju 2020-08-27 498if (!dev) {
c943b4948b5848f Chandan Uddaraju 2020-08-27 499
DRM_ERROR("invalid dev\n");
c943b4948b5848f Chandan Uddaraju 2020-08-27 500return -EINVAL;
c943b4948b5848f Chandan Uddaraju 2020-08-27 501}
c943b4948b5848f Chandan Uddaraju 2020-08-27 502
061eb621fc2780a Abhinav Kumar2020-09-12 503dp =
container_of(g_dp_display,
061eb621fc2780a Abhinav Kumar2020-09-12 504struct
dp_display_private, dp_display);
c943b4948b5848f Chandan Uddaraju 2020-08-27 505if (!dp) {
c943b4948b5848f Chandan Uddaraju 2020-08-27 506DRM_ERROR("no
driver data found\n");
c943b4948b5848f Chandan Uddaraju 2020-08-27 507return -ENODEV;
c943b4948b5848f Chandan Uddaraju 2020-08-27 508}
c943b4948b5848f Chandan Uddaraju 2020-08-27 509
26b8d66a399e625 Kuogee Hsieh 2020-11-03 510hpd = dp->usbpd;
26b8d66a399e625 Kuogee Hsieh 2020-11-03 511
c943b4948b5848f Chandan Uddaraju 2020-08-27 512/* check for any test
request issued by sink */
8ede2ecc3e5ee32 Kuogee Hsieh 2020-09-11 513rc =
dp_link_process_request(dp->link);
26b8d66a399e625 Kuogee Hsieh 2020-11-03 514if (!rc) {
26b8d66a399e625 Kuogee Hsieh 2020-11-03 515sink_request =
dp->link->sink_request;
c58eb1b54feefc3 Kuogee Hsieh 2020-11-18 516if
(sink_request & DS_PORT_STATUS_CHANGED)
c58eb1b54feefc3 Kuogee Hsieh 2020-11-18 517rc =
dp_display_handle_port_ststus_changed(dp);
c58eb1b54feefc3 Kuogee Hsieh 2020-11-18 518else
26b8d66a399e625 Kuogee Hsieh 2020-11-03 519rc =
dp_display_handle_irq_hpd(dp);
26b8d66a399e625 Kuogee Hsieh 2020-11-03 520}
c943b4948b5848f Chandan Uddaraju 2020-08-27 521
8ede2ecc3e5ee32 Kuogee Hsieh 2020-09-11 522return rc;
c943b4948b5848f Chandan Uddaraju 2020-08-27 523 }
c943b4948b5848f Chandan Uddaraju 2020-08-27 524
:: The code at line 496 was first introduced by commit
:: 26b8d66a399e625f3aa2c02ccbab1bff2e00040c drm/msm/dp: promote irq_hpd
handle to handle link training correctly
:: TO: Kuogee Hsieh
:: CC: Rob Clark
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: [PATCH V2 XRT Alveo 2/6] fpga: xrt: infrastructure support for xmgmt driver
Hi Sonal, Thank you for the patch! Yet something to improve: [auto build test ERROR on linux/master] [also build test ERROR on linus/master v5.10 next-20201218] [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/Sonal-Santan/XRT-Alveo-driver-overview/20201217-160048 base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 09162bc32c880a791c6c0668ce0745cf7958f576 config: x86_64-rhel (attached as .config) compiler: gcc-9 (Debian 9.3.0-15) 9.3.0 reproduce (this is a W=1 build): # https://github.com/0day-ci/linux/commit/40454bdc15831407c2041bec3d4f389816916ed6 git remote add linux-review https://github.com/0day-ci/linux git fetch --no-tags linux-review Sonal-Santan/XRT-Alveo-driver-overview/20201217-160048 git checkout 40454bdc15831407c2041bec3d4f389816916ed6 # save the attached .config to linux build tree make W=1 ARCH=x86_64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): >> error: include/uapi/linux/xrt/xclbin.h: missing "WITH Linux-syscall-note" >> for SPDX-License-Identifier make[2]: *** [scripts/Makefile.headersinst:63: usr/include/linux/xrt/xclbin.h] Error 1 make[2]: Target '__headers' not remade because of errors. make[1]: *** [Makefile:1288: headers] Error 2 make[1]: Target 'headers_install' not remade because of errors. make: *** [Makefile:185: __sub-make] Error 2 make: Target 'headers_install' not remade because of errors. --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip
Re: [PATCH v2 5/5] mm: remove unneeded local variable in free_area_init_core
On Sun, Dec 20, 2020 at 04:27:54PM +0800, Baoquan He wrote:
> Local variable 'zone_start_pfn' is not needed since there's only
> one call site in free_area_init_core(). Let's remove it and pass
> zone->zone_start_pfn directly to init_currently_empty_zone().
>
> Signed-off-by: Baoquan He
Reviewed-by: Mike Rapoport
> ---
> mm/page_alloc.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 7f0a917ab858..189a86253c93 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -6986,7 +6986,6 @@ static void __init free_area_init_core(struct
> pglist_data *pgdat)
> for (j = 0; j < MAX_NR_ZONES; j++) {
> struct zone *zone = pgdat->node_zones + j;
> unsigned long size, freesize, memmap_pages;
> - unsigned long zone_start_pfn = zone->zone_start_pfn;
>
> size = zone->spanned_pages;
> freesize = zone->present_pages;
> @@ -7035,7 +7034,7 @@ static void __init free_area_init_core(struct
> pglist_data *pgdat)
>
> set_pageblock_order();
> setup_usemap(zone);
> - init_currently_empty_zone(zone, zone_start_pfn, size);
> + init_currently_empty_zone(zone, zone->zone_start_pfn, size);
> memmap_init_zone(zone);
> }
> }
> --
> 2.17.2
>
--
Sincerely yours,
Mike.
Re: [PATCH v2 4/5] mm: simplify parameter of setup_usemap()
On Sun, Dec 20, 2020 at 04:27:53PM +0800, Baoquan He wrote:
> Parameter 'zone' has got needed information, let's remove other
> unnecessary parameters.
>
> Signed-off-by: Baoquan He
Reviewed-by: Mike Rapoport
> ---
> mm/page_alloc.c | 17 +++--
> 1 file changed, 7 insertions(+), 10 deletions(-)
>
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 7a6626351ed7..7f0a917ab858 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -6824,25 +6824,22 @@ static unsigned long __init usemap_size(unsigned long
> zone_start_pfn, unsigned l
> return usemapsize / 8;
> }
>
> -static void __ref setup_usemap(struct pglist_data *pgdat,
> - struct zone *zone,
> - unsigned long zone_start_pfn,
> - unsigned long zonesize)
> +static void __ref setup_usemap(struct zone *zone)
> {
> - unsigned long usemapsize = usemap_size(zone_start_pfn, zonesize);
> + unsigned long usemapsize = usemap_size(zone->zone_start_pfn,
> +zone->spanned_pages);
> zone->pageblock_flags = NULL;
> if (usemapsize) {
> zone->pageblock_flags =
> memblock_alloc_node(usemapsize, SMP_CACHE_BYTES,
> - pgdat->node_id);
> + zone_to_nid(zone));
> if (!zone->pageblock_flags)
> panic("Failed to allocate %ld bytes for zone %s
> pageblock flags on node %d\n",
> - usemapsize, zone->name, pgdat->node_id);
> + usemapsize, zone->name, zone_to_nid(zone));
> }
> }
> #else
> -static inline void setup_usemap(struct pglist_data *pgdat, struct zone *zone,
> - unsigned long zone_start_pfn, unsigned long
> zonesize) {}
> +static inline void setup_usemap(struct zone *zone) {}
> #endif /* CONFIG_SPARSEMEM */
>
> #ifdef CONFIG_HUGETLB_PAGE_SIZE_VARIABLE
> @@ -7037,7 +7034,7 @@ static void __init free_area_init_core(struct
> pglist_data *pgdat)
> continue;
>
> set_pageblock_order();
> - setup_usemap(pgdat, zone, zone_start_pfn, size);
> + setup_usemap(zone);
> init_currently_empty_zone(zone, zone_start_pfn, size);
> memmap_init_zone(zone);
> }
> --
> 2.17.2
>
--
Sincerely yours,
Mike.
Re: [PATCH v2 3/5] mm: simplify parater of function memmap_init_zone()
On Sun, Dec 20, 2020 at 04:27:52PM +0800, Baoquan He wrote:
> As David suggested, simply passing 'struct zone *zone' is enough. We can
> get all needed information from 'struct zone*' easily.
>
> Suggested-by: David Hildenbrand
> Signed-off-by: Baoquan He
Reviewed-by: Mike Rapoport
> ---
> arch/ia64/include/asm/pgtable.h | 3 +--
> arch/ia64/mm/init.c | 12 +++-
> mm/page_alloc.c | 20 ++--
> 3 files changed, 18 insertions(+), 17 deletions(-)
>
> diff --git a/arch/ia64/include/asm/pgtable.h b/arch/ia64/include/asm/pgtable.h
> index dce2ff37df65..2c81394a2430 100644
> --- a/arch/ia64/include/asm/pgtable.h
> +++ b/arch/ia64/include/asm/pgtable.h
> @@ -520,8 +520,7 @@ extern struct page *zero_page_memmap_ptr;
>
> # ifdef CONFIG_VIRTUAL_MEM_MAP
>/* arch mem_map init routine is needed due to holes in a virtual mem_map */
> -extern void memmap_init_zone(unsigned long size, int nid, unsigned long
> zone,
> - unsigned long start_pfn);
> +extern void memmap_init_zone(struct zone *zone);
> # endif /* CONFIG_VIRTUAL_MEM_MAP */
> # endif /* !__ASSEMBLY__ */
>
> diff --git a/arch/ia64/mm/init.c b/arch/ia64/mm/init.c
> index c8e68e92beb3..ccbda1a74c95 100644
> --- a/arch/ia64/mm/init.c
> +++ b/arch/ia64/mm/init.c
> @@ -541,12 +541,14 @@ virtual_memmap_init(u64 start, u64 end, void *arg)
> return 0;
> }
>
> -void __meminit
> -memmap_init_zone(unsigned long size, int nid, unsigned long zone,
> - unsigned long start_pfn)
> +void __meminit memmap_init_zone(struct zone *zone)
> {
> + unsigned long size = zone->spanned_pages;
> + int nid = zone_to_nid(zone), zone_id = zone_idx(zone);
> + unsigned long start_pfn = zone->zone_start_pfn;
> +
> if (!vmem_map) {
> - memmap_init_range(size, nid, zone, start_pfn, start_pfn + size,
> + memmap_init_range(size, nid, zone_id, start_pfn, start_pfn +
> size,
>MEMINIT_EARLY, NULL, MIGRATE_MOVABLE);
> } else {
> struct page *start;
> @@ -556,7 +558,7 @@ memmap_init_zone(unsigned long size, int nid, unsigned
> long zone,
> args.start = start;
> args.end = start + size;
> args.nid = nid;
> - args.zone = zone;
> + args.zone = zone_id;
>
> efi_memmap_walk(virtual_memmap_init, &args);
> }
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 4b46326099d9..7a6626351ed7 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -6292,16 +6292,16 @@ static inline u64 init_unavailable_range(unsigned
> long spfn, unsigned long epfn,
> }
> #endif
>
> -void __init __weak memmap_init_zone(unsigned long size, int nid,
> -unsigned long zone,
> -unsigned long zone_start_pfn)
> +void __init __weak memmap_init_zone(struct zone *zone)
> {
> unsigned long start_pfn, end_pfn, hole_start_pfn = 0;
> - unsigned long zone_end_pfn = zone_start_pfn + size;
> + int i, nid = zone_to_nid(zone), zone_id = zone_idx(zone);
> + unsigned long zone_start_pfn = zone->zone_start_pfn;
> + unsigned long zone_end_pfn = zone_start_pfn + zone->spanned_pages;
> u64 pgcnt = 0;
> - int i;
>
> for_each_mem_pfn_range(i, nid, &start_pfn, &end_pfn, NULL) {
> + unsigned long size;
> start_pfn = clamp(start_pfn, zone_start_pfn, zone_end_pfn);
> end_pfn = clamp(end_pfn, zone_start_pfn, zone_end_pfn);
> hole_start_pfn = clamp(hole_start_pfn, zone_start_pfn,
> @@ -6309,13 +6309,13 @@ void __init __weak memmap_init_zone(unsigned long
> size, int nid,
>
> if (end_pfn > start_pfn) {
> size = end_pfn - start_pfn;
> - memmap_init_range(size, nid, zone, start_pfn,
> zone_end_pfn,
> + memmap_init_range(size, nid, zone_id, start_pfn,
> zone_end_pfn,
>MEMINIT_EARLY, NULL, MIGRATE_MOVABLE);
> }
>
> if (hole_start_pfn < start_pfn)
> pgcnt += init_unavailable_range(hole_start_pfn,
> - start_pfn, zone, nid);
> + start_pfn, zone_id,
> nid);
> hole_start_pfn = end_pfn;
> }
>
> @@ -6328,11 +6328,11 @@ void __init __weak memmap_init_zone(unsigned long
> size, int nid,
>*/
> if (hole_start_pfn < zone_end_pfn)
> pgcnt += init_unavailable_range(hole_start_pfn, zone_end_pfn,
> - zone, nid);
> + zone_id, nid);
>
> if (pgcnt)
> pr_info("%s: Zeroed struct page in unavailable ranges: %lld\n",
> - zone_names[zone], pgcnt);
> + zone_names[
Re: [PATCH v2 2/5] mm: rename memmap_init() and memmap_init_zone()
On Sun, Dec 20, 2020 at 04:27:51PM +0800, Baoquan He wrote:
> The current memmap_init_zone() only handles memory region inside one zone,
> actually memmap_init() does the memmap init of one zone. So rename both of
> them accordingly.
>
> And also rename the function parameter 'range_start_pfn' and local variable
> 'range_end_pfn' of memmap_init() to zone_start_pfn/zone_end_pfn.
>
> Signed-off-by: Baoquan He
Reviewed-by: Mike Rapoport
> ---
> arch/ia64/include/asm/pgtable.h | 2 +-
> arch/ia64/mm/init.c | 6 +++---
> include/linux/mm.h | 2 +-
> mm/memory_hotplug.c | 2 +-
> mm/page_alloc.c | 24
> 5 files changed, 18 insertions(+), 18 deletions(-)
>
> diff --git a/arch/ia64/include/asm/pgtable.h b/arch/ia64/include/asm/pgtable.h
> index 779b6972aa84..dce2ff37df65 100644
> --- a/arch/ia64/include/asm/pgtable.h
> +++ b/arch/ia64/include/asm/pgtable.h
> @@ -520,7 +520,7 @@ extern struct page *zero_page_memmap_ptr;
>
> # ifdef CONFIG_VIRTUAL_MEM_MAP
>/* arch mem_map init routine is needed due to holes in a virtual mem_map */
> -extern void memmap_init (unsigned long size, int nid, unsigned long zone,
> +extern void memmap_init_zone(unsigned long size, int nid, unsigned long
> zone,
>unsigned long start_pfn);
> # endif /* CONFIG_VIRTUAL_MEM_MAP */
> # endif /* !__ASSEMBLY__ */
> diff --git a/arch/ia64/mm/init.c b/arch/ia64/mm/init.c
> index e76386a3479e..c8e68e92beb3 100644
> --- a/arch/ia64/mm/init.c
> +++ b/arch/ia64/mm/init.c
> @@ -535,18 +535,18 @@ virtual_memmap_init(u64 start, u64 end, void *arg)
> / sizeof(struct page));
>
> if (map_start < map_end)
> - memmap_init_zone((unsigned long)(map_end - map_start),
> + memmap_init_range((unsigned long)(map_end - map_start),
>args->nid, args->zone, page_to_pfn(map_start),
> page_to_pfn(map_end),
>MEMINIT_EARLY, NULL, MIGRATE_MOVABLE);
> return 0;
> }
>
> void __meminit
> -memmap_init (unsigned long size, int nid, unsigned long zone,
> +memmap_init_zone(unsigned long size, int nid, unsigned long zone,
>unsigned long start_pfn)
> {
> if (!vmem_map) {
> - memmap_init_zone(size, nid, zone, start_pfn, start_pfn + size,
> + memmap_init_range(size, nid, zone, start_pfn, start_pfn + size,
>MEMINIT_EARLY, NULL, MIGRATE_MOVABLE);
> } else {
> struct page *start;
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 92e06ea053f4..f72c138c2272 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -2432,7 +2432,7 @@ extern int __meminit early_pfn_to_nid(unsigned long
> pfn);
> #endif
>
> extern void set_dma_reserve(unsigned long new_dma_reserve);
> -extern void memmap_init_zone(unsigned long, int, unsigned long,
> +extern void memmap_init_range(unsigned long, int, unsigned long,
> unsigned long, unsigned long, enum meminit_context,
> struct vmem_altmap *, int migratetype);
> extern void setup_per_zone_wmarks(void);
> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> index f9d57b9be8c7..ddcb1cd24c60 100644
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -713,7 +713,7 @@ void __ref move_pfn_range_to_zone(struct zone *zone,
> unsigned long start_pfn,
>* expects the zone spans the pfn range. All the pages in the range
>* are reserved so nobody should be touching them so we should be safe
>*/
> - memmap_init_zone(nr_pages, nid, zone_idx(zone), start_pfn, 0,
> + memmap_init_range(nr_pages, nid, zone_idx(zone), start_pfn, 0,
>MEMINIT_HOTPLUG, altmap, migratetype);
>
> set_zone_contiguous(zone);
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 32645f2e7b96..4b46326099d9 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -6117,7 +6117,7 @@ overlap_memmap_init(unsigned long zone, unsigned long
> *pfn)
> * (usually MIGRATE_MOVABLE). Besides setting the migratetype, no related
> * zone stats (e.g., nr_isolate_pageblock) are touched.
> */
> -void __meminit memmap_init_zone(unsigned long size, int nid, unsigned long
> zone,
> +void __meminit memmap_init_range(unsigned long size, int nid, unsigned long
> zone,
> unsigned long start_pfn, unsigned long zone_end_pfn,
> enum meminit_context context,
> struct vmem_altmap *altmap, int migratetype)
> @@ -6292,24 +6292,24 @@ static inline u64 init_unavailable_range(unsigned
> long spfn, unsigned long epfn,
> }
> #endif
>
> -void __init __weak memmap_init(unsigned long size, int nid,
> +void __init __weak memmap_init_zone(unsigned long size, int nid,
> unsigned long zone,
> -unsigned long range_start_pfn)
> +
Re: [PATCH v2] security: apparmor: delete repeated words in comments
On 12/20/20 7:27 PM, Randy Dunlap wrote:
> Drop repeated words in comments.
> {a, then, to}
>
> Signed-off-by: Randy Dunlap
> Cc: John Johansen
> Cc: appar...@lists.ubuntu.com
> Cc: James Morris
> Cc: "Serge E. Hallyn"
> Cc: linux-security-mod...@vger.kernel.org
> Reviewed-By: Seth Arnold
Acked-by: John Johansen
I will pull this into apparmor-next
> ---
> v2: rebase
>
> security/apparmor/include/file.h |2 +-
> security/apparmor/path.c |2 +-
> security/apparmor/policy_unpack.c |2 +-
> 3 files changed, 3 insertions(+), 3 deletions(-)
>
> --- linux-next-20201218.orig/security/apparmor/include/file.h
> +++ linux-next-20201218/security/apparmor/include/file.h
> @@ -167,7 +167,7 @@ int aa_audit_file(struct aa_profile *pro
> * @perms: permission table indexed by the matched state accept entry of @dfa
> * @trans: transition table for indexed by named x transitions
> *
> - * File permission are determined by matching a path against @dfa and then
> + * File permission are determined by matching a path against @dfa and
> * then using the value of the accept entry for the matching state as
> * an index into @perms. If a named exec transition is required it is
> * looked up in the transition table.
> --- linux-next-20201218.orig/security/apparmor/path.c
> +++ linux-next-20201218/security/apparmor/path.c
> @@ -83,7 +83,7 @@ static int disconnect(const struct path
> *
> * Returns: %0 else error code if path lookup fails
> * When no error the path name is returned in @name which points to
> - * to a position in @buf
> + * a position in @buf
> */
> static int d_namespace_path(const struct path *path, char *buf, char **name,
> int flags, const char *disconnected)
> --- linux-next-20201218.orig/security/apparmor/policy_unpack.c
> +++ linux-next-20201218/security/apparmor/policy_unpack.c
> @@ -39,7 +39,7 @@
>
> /*
> * The AppArmor interface treats data as a type byte followed by the
> - * actual data. The interface has the notion of a a named entry
> + * actual data. The interface has the notion of a named entry
> * which has a name (AA_NAME typecode followed by name string) followed by
> * the entries typecode and data. Named types allow for optional
> * elements and extensions to be added and tested for without breaking
>
Re: [PATCH v2 1/5] mm: memmap defer init dosn't work as expected
On Sun, Dec 20, 2020 at 04:27:50PM +0800, Baoquan He wrote:
> VMware observed a performance regression during memmap init on their platform,
> and bisected to commit 73a6e474cb376 ("mm: memmap_init: iterate over memblock
> regions rather that check each PFN") causing it.
>
> Before the commit:
>
> [0.033176] Normal zone: 1445888 pages used for memmap
> [0.033176] Normal zone: 89391104 pages, LIFO batch:63
> [0.035851] ACPI: PM-Timer IO Port: 0x448
>
> With commit
>
> [0.026874] Normal zone: 1445888 pages used for memmap
> [0.026875] Normal zone: 89391104 pages, LIFO batch:63
> [2.028450] ACPI: PM-Timer IO Port: 0x448
>
> The root cause is the current memmap defer init doesn't work as expected.
> Before, memmap_init_zone() was used to do memmap init of one whole zone, to
> initialize all low zones of one numa node, but defer memmap init of the
> last zone in that numa node. However, since commit 73a6e474cb376, function
> memmap_init() is adapted to iterater over memblock regions inside one zone,
> then call memmap_init_zone() to do memmap init for each region.
>
> E.g, on VMware's system, the memory layout is as below, there are two memory
> regions in node 2. The current code will mistakenly initialize the whole 1st
> region [mem 0xab-0xfc], then do memmap defer to iniatialize
> only one memmory section on the 2nd region [mem 0x100-0x1033fff].
> In fact, we only expect to see that there's only one memory section's memmap
> initialized. That's why more time is costed at the time.
>
> [0.008842] ACPI: SRAT: Node 0 PXM 0 [mem 0x-0x0009]
> [0.008842] ACPI: SRAT: Node 0 PXM 0 [mem 0x0010-0xbfff]
> [0.008843] ACPI: SRAT: Node 0 PXM 0 [mem 0x1-0x55]
> [0.008844] ACPI: SRAT: Node 1 PXM 1 [mem 0x56-0xaa]
> [0.008844] ACPI: SRAT: Node 2 PXM 2 [mem 0xab-0xfc]
> [0.008845] ACPI: SRAT: Node 2 PXM 2 [mem 0x100-0x1033fff]
>
> Now, let's add a parameter 'zone_end_pfn' to memmap_init_zone() to pass
> down the real zone end pfn so that defer_init() can use it to judge whether
> defer need be taken in zone wide.
>
> Fixes: commit 73a6e474cb376 ("mm: memmap_init: iterate over memblock regions
> rather that check each PFN")
> Reported-by: Rahul Gopakumar
> Signed-off-by: Baoquan He
> Cc: sta...@vger.kernel.org
Reviewed-by: Mike Rapoport
> ---
> arch/ia64/mm/init.c | 4 ++--
> include/linux/mm.h | 5 +++--
> mm/memory_hotplug.c | 2 +-
> mm/page_alloc.c | 8 +---
> 4 files changed, 11 insertions(+), 8 deletions(-)
>
> diff --git a/arch/ia64/mm/init.c b/arch/ia64/mm/init.c
> index 9b5acf8fb092..e76386a3479e 100644
> --- a/arch/ia64/mm/init.c
> +++ b/arch/ia64/mm/init.c
> @@ -536,7 +536,7 @@ virtual_memmap_init(u64 start, u64 end, void *arg)
>
> if (map_start < map_end)
> memmap_init_zone((unsigned long)(map_end - map_start),
> - args->nid, args->zone, page_to_pfn(map_start),
> + args->nid, args->zone, page_to_pfn(map_start),
> page_to_pfn(map_end),
>MEMINIT_EARLY, NULL, MIGRATE_MOVABLE);
> return 0;
> }
> @@ -546,7 +546,7 @@ memmap_init (unsigned long size, int nid, unsigned long
> zone,
>unsigned long start_pfn)
> {
> if (!vmem_map) {
> - memmap_init_zone(size, nid, zone, start_pfn,
> + memmap_init_zone(size, nid, zone, start_pfn, start_pfn + size,
>MEMINIT_EARLY, NULL, MIGRATE_MOVABLE);
> } else {
> struct page *start;
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index e4e5be20b0c2..92e06ea053f4 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -2432,8 +2432,9 @@ extern int __meminit early_pfn_to_nid(unsigned long
> pfn);
> #endif
>
> extern void set_dma_reserve(unsigned long new_dma_reserve);
> -extern void memmap_init_zone(unsigned long, int, unsigned long, unsigned
> long,
> - enum meminit_context, struct vmem_altmap *, int migratetype);
> +extern void memmap_init_zone(unsigned long, int, unsigned long,
> + unsigned long, unsigned long, enum meminit_context,
> + struct vmem_altmap *, int migratetype);
> extern void setup_per_zone_wmarks(void);
> extern int __meminit init_per_zone_wmark_min(void);
> extern void mem_init(void);
> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> index af41fb990820..f9d57b9be8c7 100644
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -713,7 +713,7 @@ void __ref move_pfn_range_to_zone(struct zone *zone,
> unsigned long start_pfn,
>* expects the zone spans the pfn range. All the pages in the range
>* are reserved so nobody should be touching them so we should be safe
>*/
> - memmap_init_zone(nr_pages, nid, zone_idx(zone), start_pfn,
> + memmap_init_zone(nr_pages, nid, zone_idx(zone), start_pfn,
Re: [PATCH v1] kbuild: enforce -Werror=unused-result
On Tue, Dec 1, 2020 at 7:42 PM Masahiro Yamada wrote: > > On Tue, Nov 17, 2020 at 7:47 PM Olaf Hering wrote: > > > > It is a hard error if a return value is ignored. > > In case the return value has no meaning, remove the attribute. > > > > Signed-off-by: Olaf Hering > > Applied to linux-kbuild. > Thanks. I will postpone this by the next MW. Some instances of __must_check violation are still remaining, which end up with build breakages. > > > --- > > Makefile | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/Makefile b/Makefile > > index e2c3f65c4721..c7f9acffad42 100644 > > --- a/Makefile > > +++ b/Makefile > > @@ -497,7 +497,7 @@ KBUILD_AFLAGS := -D__ASSEMBLY__ -fno-PIE > > KBUILD_CFLAGS := -Wall -Wundef -Werror=strict-prototypes -Wno-trigraphs \ > >-fno-strict-aliasing -fno-common -fshort-wchar -fno-PIE \ > >-Werror=implicit-function-declaration > > -Werror=implicit-int \ > > - -Werror=return-type -Wno-format-security \ > > + -Werror=return-type -Werror=unused-result > > -Wno-format-security \ > >-std=gnu89 > > KBUILD_CPPFLAGS := -D__KERNEL__ > > KBUILD_AFLAGS_KERNEL := > > > > -- > Best Regards > Masahiro Yamada -- Best Regards Masahiro Yamada
Re: [PATCH] ide: pci: Fix memleak in ide_pci_init_two
On Sun, Dec 20, 2020 at 03:05:40PM +0800, Dinghao Liu wrote:
> When do_ide_setup_pci_device() fails, host allocated
> by ide_host_alloc() may not have been freed, which
> leads to memleak.
>
> Signed-off-by: Dinghao Liu
> ---
> drivers/ide/setup-pci.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/ide/setup-pci.c b/drivers/ide/setup-pci.c
> index fdc8e813170c..c7da5368fcd4 100644
> --- a/drivers/ide/setup-pci.c
> +++ b/drivers/ide/setup-pci.c
> @@ -586,7 +586,7 @@ int ide_pci_init_two(struct pci_dev *dev1, struct pci_dev
> *dev2,
>* do_ide_setup_pci_device() on the first device!
>*/
> if (ret < 0)
> - goto out_free_bars;
> + goto out_free_host;
>
> /* fixup IRQ */
> if (ide_pci_is_in_compatibility_mode(pdev[i])) {
> @@ -597,11 +597,11 @@ int ide_pci_init_two(struct pci_dev *dev1, struct
> pci_dev *dev2,
> }
>
> ret = ide_host_register(host, d, hws);
> - if (ret)
> - ide_host_free(host);
> - else
> + if (!ret)
> goto out;
Maybe
if (ret)
goto out_free_host;
return 0;
would be more clear here. But this is just small nit.
>
> +out_free_host:
> + ide_host_free(host);
> out_free_bars:
> i = n_ports / 2;
> while (i--)
[PATCH v2] KVM/x86: Move definition of __ex to x86.h
Merge __kvm_handle_fault_on_reboot with its sole user
and move the definition of __ex to a common include to be
shared between VMX and SVM.
v2: Rebase to latest kvm/queue.
Cc: Paolo Bonzini
Cc: Sean Christopherson
Signed-off-by: Uros Bizjak
Reviewed-by: Krish Sadhukhan
---
arch/x86/include/asm/kvm_host.h | 25 -
arch/x86/kvm/svm/sev.c | 2 --
arch/x86/kvm/svm/svm.c | 2 --
arch/x86/kvm/vmx/vmx_ops.h | 4 +---
arch/x86/kvm/x86.h | 23 +++
5 files changed, 24 insertions(+), 32 deletions(-)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 39707e72b062..a78e4b1a5d77 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -1634,31 +1634,6 @@ enum {
#define kvm_arch_vcpu_memslots_id(vcpu) ((vcpu)->arch.hflags & HF_SMM_MASK ? 1
: 0)
#define kvm_memslots_for_spte_role(kvm, role) __kvm_memslots(kvm, (role).smm)
-asmlinkage void kvm_spurious_fault(void);
-
-/*
- * Hardware virtualization extension instructions may fault if a
- * reboot turns off virtualization while processes are running.
- * Usually after catching the fault we just panic; during reboot
- * instead the instruction is ignored.
- */
-#define __kvm_handle_fault_on_reboot(insn) \
- "666: \n\t" \
- insn "\n\t" \
- "jmp668f \n\t" \
- "667: \n\t" \
- "1: \n\t" \
- ".pushsection .discard.instr_begin \n\t"\
- ".long 1b - . \n\t" \
- ".popsection \n\t" \
- "call kvm_spurious_fault \n\t"\
- "1: \n\t" \
- ".pushsection .discard.instr_end \n\t" \
- ".long 1b - . \n\t" \
- ".popsection \n\t" \
- "668: \n\t" \
- _ASM_EXTABLE(666b, 667b)
-
#define KVM_ARCH_WANT_MMU_NOTIFIER
int kvm_unmap_hva_range(struct kvm *kvm, unsigned long start, unsigned long
end,
unsigned flags);
diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
index e57847ff8bd2..ba492b6d37a0 100644
--- a/arch/x86/kvm/svm/sev.c
+++ b/arch/x86/kvm/svm/sev.c
@@ -25,8 +25,6 @@
#include "cpuid.h"
#include "trace.h"
-#define __ex(x) __kvm_handle_fault_on_reboot(x)
-
static u8 sev_enc_bit;
static int sev_flush_asids(void);
static DECLARE_RWSEM(sev_deactivate_lock);
diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
index 941e5251e13f..733d9f98a121 100644
--- a/arch/x86/kvm/svm/svm.c
+++ b/arch/x86/kvm/svm/svm.c
@@ -42,8 +42,6 @@
#include "svm.h"
-#define __ex(x) __kvm_handle_fault_on_reboot(x)
-
MODULE_AUTHOR("Qumranet");
MODULE_LICENSE("GPL");
diff --git a/arch/x86/kvm/vmx/vmx_ops.h b/arch/x86/kvm/vmx/vmx_ops.h
index 692b0c31c9c8..7e3cb53c413f 100644
--- a/arch/x86/kvm/vmx/vmx_ops.h
+++ b/arch/x86/kvm/vmx/vmx_ops.h
@@ -4,13 +4,11 @@
#include
-#include
#include
#include "evmcs.h"
#include "vmcs.h"
-
-#define __ex(x) __kvm_handle_fault_on_reboot(x)
+#include "x86.h"
asmlinkage void vmread_error(unsigned long field, bool fault);
__attribute__((regparm(0))) void vmread_error_trampoline(unsigned long field,
diff --git a/arch/x86/kvm/x86.h b/arch/x86/kvm/x86.h
index c5ee0f5ce0f1..3cb12788ddc5 100644
--- a/arch/x86/kvm/x86.h
+++ b/arch/x86/kvm/x86.h
@@ -8,6 +8,29 @@
#include "kvm_cache_regs.h"
#include "kvm_emulate.h"
+asmlinkage void kvm_spurious_fault(void);
+
+/*
+ * Hardware virtualization extension instructions may fault if a
+ * reboot turns off virtualization while processes are running.
+ * Usually after catching the fault we just panic; during reboot
+ * instead the instruction is ignored.
+ */
+#define __ex(insn) \
+ "666: " insn "\n" \
+ " jmp 669f\n" \
+ "667:\n"\
+ " .pushsection .discard.instr_begin\n"\
+ " .long 667b - .\n" \
+ " .popsection\n" \
+ " call kvm_spurious_fault\n" \
+ "668:\n"\
+ " .pushsection .discard.instr_end\n" \
+ " .
Re: [PATCH v2] ovl: fix dentry leak in ovl_get_redirect
On Sun, Dec 20, 2020 at 08:09:27PM +0800, Liangyan wrote:
> +++ b/fs/overlayfs/dir.c
> @@ -973,6 +973,7 @@ static char *ovl_get_redirect(struct dentry *dentry, bool
> abs_redirect)
> for (d = dget(dentry); !IS_ROOT(d);) {
> const char *name;
> int thislen;
> + struct dentry *parent = NULL;
>
> spin_lock(&d->d_lock);
> name = ovl_dentry_get_redirect(d);
> @@ -992,7 +993,22 @@ static char *ovl_get_redirect(struct dentry *dentry,
> bool abs_redirect)
>
> buflen -= thislen;
> memcpy(&buf[buflen], name, thislen);
> - tmp = dget_dlock(d->d_parent);
> + parent = d->d_parent;
> + if (unlikely(!spin_trylock(&parent->d_lock))) {
> + rcu_read_lock();
> + spin_unlock(&d->d_lock);
> +again:
> + parent = READ_ONCE(d->d_parent);
> + spin_lock(&parent->d_lock);
> + if (unlikely(parent != d->d_parent)) {
> + spin_unlock(&parent->d_lock);
> + goto again;
> + }
> + rcu_read_unlock();
> + spin_lock_nested(&d->d_lock, DENTRY_D_LOCK_NESTED);
> + }
> + tmp = dget_dlock(parent);
> + spin_unlock(&parent->d_lock);
> spin_unlock(&d->d_lock);
Yecc What's wrong with just doing
spin_unlock(&d->d_lock);
parent = dget_parent(d);
dput(d);
d = parent;
instead of that?
mm/filemap.c:2439:9: warning: stack frame size of 2096 bytes in function 'generic_file_buffered_read'
Hi Kees, First bad commit (maybe != root cause): tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 467f8165a2b0e6accf3d0dd9c8089b1dbde29f7f commit: cdf8a76fda4ae3b53c5a09e5a8c79e27b7b65d68 ubsan: move cc-option tests into Kconfig date: 5 days ago config: powerpc-randconfig-r002-20201220 (attached as .config) compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project cee1e7d14f4628d6174b33640d502bff3b54ae45) 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 # install powerpc cross compiling tool for clang build # apt-get install binutils-powerpc-linux-gnu # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=cdf8a76fda4ae3b53c5a09e5a8c79e27b7b65d68 git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout cdf8a76fda4ae3b53c5a09e5a8c79e27b7b65d68 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=powerpc 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 arch/powerpc/include/asm/io.h:604: arch/powerpc/include/asm/io-defs.h:45:1: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] DEF_PCI_AC_NORET(insw, (unsigned long p, void *b, unsigned long c), ^~~ arch/powerpc/include/asm/io.h:601:3: note: expanded from macro 'DEF_PCI_AC_NORET' __do_##name al; \ ^~ :156:1: note: expanded from here __do_insw ^ arch/powerpc/include/asm/io.h:542:56: note: expanded from macro '__do_insw' #define __do_insw(p, b, n) readsw((PCI_IO_ADDR)_IO_BASE+(p), (b), (n)) ~^ In file included from mm/filemap.c:20: In file included from include/linux/kernel_stat.h:9: In file included from include/linux/interrupt.h:11: In file included from include/linux/hardirq.h:10: In file included from arch/powerpc/include/asm/hardirq.h:6: In file included from include/linux/irq.h:20: In file included from include/linux/io.h:13: In file included from arch/powerpc/include/asm/io.h:604: arch/powerpc/include/asm/io-defs.h:47:1: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] DEF_PCI_AC_NORET(insl, (unsigned long p, void *b, unsigned long c), ^~~ arch/powerpc/include/asm/io.h:601:3: note: expanded from macro 'DEF_PCI_AC_NORET' __do_##name al; \ ^~ :160:1: note: expanded from here __do_insl ^ arch/powerpc/include/asm/io.h:543:56: note: expanded from macro '__do_insl' #define __do_insl(p, b, n) readsl((PCI_IO_ADDR)_IO_BASE+(p), (b), (n)) ~^ In file included from mm/filemap.c:20: In file included from include/linux/kernel_stat.h:9: In file included from include/linux/interrupt.h:11: In file included from include/linux/hardirq.h:10: In file included from arch/powerpc/include/asm/hardirq.h:6: In file included from include/linux/irq.h:20: In file included from include/linux/io.h:13: In file included from arch/powerpc/include/asm/io.h:604: arch/powerpc/include/asm/io-defs.h:49:1: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] DEF_PCI_AC_NORET(outsb, (unsigned long p, const void *b, unsigned long c), ^~ arch/powerpc/include/asm/io.h:601:3: note: expanded from macro 'DEF_PCI_AC_NORET' __do_##name al; \ ^~ :164:1: note: expanded from here __do_outsb ^ arch/powerpc/include/asm/io.h:544:58: note: expanded from macro '__do_outsb' #define __do_outsb(p, b, n) writesb((PCI_IO_ADDR)_IO_BASE+(p),(b),(n)) ~^ In file included from mm/filemap.c:20: In file included from include/linux/kernel_stat.h:9: In file included from include/linux/interrupt.h:11: In file included from include/linux/hardirq.h:10: In file included from arch/powerpc/include/asm/hardirq.h:6: In file included from include/linux/irq.h:20: In file included from include/linux/i
RE: [PATCH v3 2/3] fpga: dfl: add the userspace I/O device support for DFL devices
> Subject: Re: [PATCH v3 2/3] fpga: dfl: add the userspace I/O device support > for DFL devices > > On Fri, Dec 18, 2020 at 05:59:17AM -0800, Tom Rix wrote: > > > > On 12/18/20 12:05 AM, Wu, Hao wrote: > > >> Subject: [PATCH v3 2/3] fpga: dfl: add the userspace I/O device support > for > > >> DFL devices > > >> > > >> This patch supports the DFL drivers be written in userspace. This is > > >> realized by exposing the userspace I/O device interfaces. > > >> > > >> The driver leverages the uio_pdrv_genirq, it adds the uio_pdrv_genirq > > >> platform device with the DFL device's resources, and let the generic UIO > > >> platform device driver provide support to userspace access to kernel > > >> interrupts and memory locations. > > >> > > >> The driver matches DFL devices in a different way. It has no device id > > >> table, instead it matches any DFL device which could not be handled by > > >> other DFL drivers. > > > Looks like we want to build UIO driver as the default/generic driver for > DFL, > > I'm not going to make UIO as the default driver for DFL devs, the driver > module will not be autoloaded. I want to provide a choice to operate on > the unhandled devs in userspace. Insmod it if it helps otherwise leave > it. But once it's loaded, then it will bind with all dfl devices which doesn't have a matched driver yet. > > > > it seems fine but my concern is that UIO has its own limitation, if some > day, > > > dfl device is extended, but UIO has limitation, then we may need to select > > > another one as the default driver.. or we can just match them using > > I think we may not have to select a "default" driver, if we have a > better way for userspace accessing, we could load that module, leave > UIO. It would not be an easy decision, it may impact users who have already built upper layer software on top of UIO, and ask new users to use new one too. Users may not be happy with this. > > > > id_table as we know UIO meets the requirement for those DFL devices? > > As we discussed, the drawback is that we should always change the code to > support a new dfl device for user accessing. But it is OK to me if the > generic UIO match rule is not considered proper. > > > > > When we have multiple defaults, could this be handled in the configury ? > > I think we don't have to select a "default". Actually I am fine with the idea of using a default / generic driver for DFL device, and my only concern is UIO may not be good enough for us per my understanding. Maybe we can have a more extendable one as the generic driver, but if we don't have that yet, then using id table may be able to avoid some problems I think. Hao > > > > > Tom > > > > > > > >> Signed-off-by: Xu Yilun > > >> --- > > >> v2: switch to the new matching algorithem. It matches DFL devices which > > >> could not be handled by other DFL drivers. > > >> refacor the code about device resources filling. > > >> fix some comments. > > >> v3: split the dfl.c changes out of this patch. > > >> some minor fixes > > >> --- > > >> drivers/fpga/Kconfig| 10 > > >> drivers/fpga/Makefile | 1 + > > >> drivers/fpga/dfl-uio-pdev.c | 110 > > >> > > >> 3 files changed, 121 insertions(+) > > >> create mode 100644 drivers/fpga/dfl-uio-pdev.c > > >> > > >> diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig > > >> index 5d7f0ae..7a88af9 100644 > > >> --- a/drivers/fpga/Kconfig > > >> +++ b/drivers/fpga/Kconfig > > >> @@ -202,6 +202,16 @@ config FPGA_DFL_NIOS_INTEL_PAC_N3000 > > >>the card. It also instantiates the SPI master (spi-altera) for > > >>the card's BMC (Board Management Controller). > > >> > > >> +config FPGA_DFL_UIO_PDEV > > >> +tristate "FPGA DFL Driver for Userspace I/O platform devices" > > >> +depends on FPGA_DFL && UIO_PDRV_GENIRQ > > >> +help > > >> + Enable this to allow some DFL drivers be written in > > >> userspace. It > > >> + adds the uio_pdrv_genirq platform device with the DFL > > >> feature's > > >> + resources, and lets the generic UIO platform device driver > > >> provide > > >> + support for userspace access to kernel interrupts and memory > > >> + locations. > > > If we consider this as a default driver for everybody in DFL, then we > > > could > > > consider build it into the core, otherwise it always requires to be loaded > > > manually, right? > > It should be loaded manually. I don't want to make this as default. > > > > > > >> + > > >> config FPGA_DFL_PCI > > >> tristate "FPGA DFL PCIe Device Driver" > > >> depends on PCI && FPGA_DFL > > >> diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile > > >> index 18dc9885..8847fe0 100644 > > >> --- a/drivers/fpga/Makefile > > >> +++ b/drivers/fpga/Makefile > > >> @@ -45,6 +45,7 @@ dfl-afu-objs := dfl-afu-main.o dfl-afu-region.o dfl- > afu- > > >> dma-region.o > > >>
Re: [PATCH v3] Compiler Attributes: remove CONFIG_ENABLE_MUST_CHECK
On Mon, Dec 14, 2020 at 12:27 AM Miguel Ojeda wrote: > > On Sun, Dec 13, 2020 at 4:16 PM Greg KH wrote: > > > > Because if you get a report of something breaking for your change, you > > need to work to resolve it, not argue about it. Otherwise it needs to > > be dropped/reverted. > > Nobody has argued that. In fact, I explicitly said the opposite: "So I > think we can fix them as they come.". > > I am expecting Masahiro to follow up. It has been less than 24 hours > since the report, on a weekend. > > Cheers, > Miguel Sorry for the delay. Now I sent out the fix for lantiq_etop.c https://lore.kernel.org/patchwork/patch/1355595/ The reason of the complication was I was trying to merge the following patch in the same development cycle: https://patchwork.kernel.org/project/linux-kbuild/patch/20201117104736.24997-1-o...@aepfle.de/ -Werror=return-type gives a bigger impact because any instance of __must_check violation results in build breakage. So, I just dropped it from my tree (and, I will aim for 5.12). The removal of CONFIG_ENABLE_MUST_CHECK is less impactive, because we are still able to build with some warnings. Tomorrow's linux-next should be OK and, you can send my patch in this merge window. -- Best Regards Masahiro Yamada
[PATCH] powerpc/32: Fix vmap stack - Properly set r1 before activating MMU on syscall too
We need r1 to be properly set before activating MMU, otherwise any new
exception taken while saving registers into the stack in syscall
prologs will use the user stack, which is wrong and will even lockup
or crash when KUAP is selected.
Do that by switching the meaning of r11 and r1 until we have saved r1
to the stack: copy r1 into r11 and setup the new stack pointer in r1.
To avoid complicating and impacting all generic and specific prolog
code (and more), copy back r1 into r11 once r11 is save onto
the stack.
We could get rid of copying r1 back and forth at the cost of rewriting
everything to use r1 instead of r11 all the way when CONFIG_VMAP_STACK
is set, but the effort is probably not worth it for now.
Fixes: da7bb43ab9da ("powerpc/32: Fix vmap stack - Properly set r1 before
activating MMU")
Cc: sta...@vger.kernel.org
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/head_32.h | 25 -
1 file changed, 16 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/kernel/head_32.h b/arch/powerpc/kernel/head_32.h
index 541664d95702..a2f72c966baf 100644
--- a/arch/powerpc/kernel/head_32.h
+++ b/arch/powerpc/kernel/head_32.h
@@ -121,18 +121,28 @@
#ifdef CONFIG_VMAP_STACK
mfspr r11, SPRN_SRR0
mtctr r11
-#endif
andi. r11, r9, MSR_PR
- lwz r11,TASK_STACK-THREAD(r12)
+ mr r11, r1
+ lwz r1,TASK_STACK-THREAD(r12)
beq-99f
- addir11, r11, THREAD_SIZE - INT_FRAME_SIZE
-#ifdef CONFIG_VMAP_STACK
+ addir1, r1, THREAD_SIZE - INT_FRAME_SIZE
li r10, MSR_KERNEL & ~(MSR_IR | MSR_RI) /* can take DTLB miss */
mtmsr r10
isync
+ tovirt(r12, r12)
+ stw r11,GPR1(r1)
+ stw r11,0(r1)
+ mr r11, r1
+#else
+ andi. r11, r9, MSR_PR
+ lwz r11,TASK_STACK-THREAD(r12)
+ beq-99f
+ addir11, r11, THREAD_SIZE - INT_FRAME_SIZE
+ tophys(r11, r11)
+ stw r1,GPR1(r11)
+ stw r1,0(r11)
+ tovirt(r1, r11) /* set new kernel sp */
#endif
- tovirt_vmstack r12, r12
- tophys_novmstack r11, r11
mflrr10
stw r10, _LINK(r11)
#ifdef CONFIG_VMAP_STACK
@@ -140,9 +150,6 @@
#else
mfspr r10,SPRN_SRR0
#endif
- stw r1,GPR1(r11)
- stw r1,0(r11)
- tovirt_novmstack r1, r11/* set new kernel sp */
stw r10,_NIP(r11)
mfcrr10
rlwinm r10,r10,0,4,2 /* Clear SO bit in CR */
--
2.25.0
Re: [PATCH v2] ovl: fix dentry leak in ovl_get_redirect
Guys, any comments on this patch? This issue should exist in latest
upstream.
On 20/12/20 下午8:09, Liangyan wrote:
We need to lock d_parent->d_lock before dget_dlock, or this may
have d_lockref updated parallelly like calltrace below which will
cause dentry->d_lockref leak and risk a crash.
npm-20576 [028] 5705749.040094:
[28] ovl_set_redirect+0x11c/0x310 //tmp = dget_dlock(d->d_parent);
[28]? ovl_set_redirect+0x5/0x310
[28] ovl_rename+0x4db/0x790 [overlay]
[28] vfs_rename+0x6e8/0x920
[28] do_renameat2+0x4d6/0x560
[28] __x64_sys_rename+0x1c/0x20
[28] do_syscall_64+0x55/0x1a0
[28] entry_SYSCALL_64_after_hwframe+0x44/0xa9
npm-20574 [036] 5705749.040094:
[36] __d_lookup+0x107/0x140 //dentry->d_lockref.count++;
[36] lookup_fast+0xe0/0x2d0
[36] walk_component+0x48/0x350
[36] link_path_walk+0x1bf/0x650
[36]? path_init+0x1f6/0x2f0
[36] path_lookupat+0x82/0x210
[36] filename_lookup+0xb8/0x1a0
[36]? __audit_getname+0xa2/0xb0
[36]? getname_flags+0xb9/0x1e0
[36]? vfs_statx+0x73/0xe0
[36] vfs_statx+0x73/0xe0
[36] __do_sys_statx+0x3b/0x80
[36]? syscall_trace_enter+0x1ae/0x2c0
[36] do_syscall_64+0x55/0x1a0
[36] entry_SYSCALL_64_
[ 49.799059] PGD 80061fed7067 P4D 80061fed7067 PUD 61fec5067 PMD 0
[ 49.799689] Oops: 0002 [#1] SMP PTI
[ 49.800019] CPU: 2 PID: 2332 Comm: node Not tainted 4.19.24-7.20.al7.x86_64
#1
[ 49.800678] Hardware name: Alibaba Cloud Alibaba Cloud ECS, BIOS 8a46cfe
04/01/2014
[ 49.801380] RIP: 0010:_raw_spin_lock+0xc/0x20
[ 49.803470] RSP: 0018:ac6fc5417e98 EFLAGS: 00010246
[ 49.803949] RAX: RBX: 93b8da3446c0 RCX: 000a
[ 49.804600] RDX: 0001 RSI: 000a RDI: 0088
[ 49.805252] RBP: R08: R09: 993cf040
[ 49.805898] R10: 93b92292e580 R11: d27f188a4b80 R12:
[ 49.806548] R13: ff9c R14: fffe R15: 93b8da3446c0
[ 49.807200] FS: 7ffbedffb700() GS:93b92788()
knlGS:
[ 49.807935] CS: 0010 DS: ES: CR0: 80050033
[ 49.808461] CR2: 0088 CR3: 0005e3f74006 CR4: 003606a0
[ 49.809113] DR0: DR1: DR2:
[ 49.809758] DR3: DR6: fffe0ff0 DR7: 0400
[ 49.810410] Call Trace:
[ 49.810653] d_delete+0x2c/0xb0
[ 49.810951] vfs_rmdir+0xfd/0x120
[ 49.811264] do_rmdir+0x14f/0x1a0
[ 49.811573] do_syscall_64+0x5b/0x190
[ 49.811917] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 49.812385] RIP: 0033:0x7ffbf505ffd7
[ 49.814404] RSP: 002b:7ffbedffada8 EFLAGS: 0297 ORIG_RAX:
0054
[ 49.815098] RAX: ffda RBX: 7ffbedffb640 RCX: 7ffbf505ffd7
[ 49.815744] RDX: 04449700 RSI: RDI: 06c8cd50
[ 49.816394] RBP: 7ffbedffaea0 R08: R09: 00017d0b
[ 49.817038] R10: R11: 0297 R12: 0012
[ 49.817687] R13: 072823d8 R14: 7ffbedffb700 R15: 072823d8
[ 49.818338] Modules linked in: pvpanic cirrusfb button qemu_fw_cfg atkbd
libps2 i8042
[ 49.819052] CR2: 0088
[ 49.819368] ---[ end trace 4e652b8aa299aa2d ]---
[ 49.819796] RIP: 0010:_raw_spin_lock+0xc/0x20
[ 49.821880] RSP: 0018:ac6fc5417e98 EFLAGS: 00010246
[ 49.822363] RAX: RBX: 93b8da3446c0 RCX: 000a
[ 49.823008] RDX: 0001 RSI: 000a RDI: 0088
[ 49.823658] RBP: R08: R09: 993cf040
[ 49.825404] R10: 93b92292e580 R11: d27f188a4b80 R12:
[ 49.827147] R13: ff9c R14: fffe R15: 93b8da3446c0
[ 49.828890] FS: 7ffbedffb700() GS:93b92788()
knlGS:
[ 49.830725] CS: 0010 DS: ES: CR0: 80050033
[ 49.832359] CR2: 0088 CR3: 0005e3f74006 CR4: 003606a0
[ 49.834085] DR0: DR1: DR2:
[ 49.835792] DR3: DR6: fffe0ff0 DR7: 0400
Fixes: a6c606551141 ("ovl: redirect on rename-dir")
Signed-off-by: Liangyan
Suggested-by: Joseph Qi
---
fs/overlayfs/dir.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/fs/overlayfs/dir.c b/fs/overlayfs/dir.c
index 28a075b5f5b2..a78d35017371 100644
--- a/fs/overlayfs/dir.c
+++ b/fs/overlayfs/dir.c
@@ -973,6 +973,7 @@ static char *ovl_get_redirect(struct dentry *dentry, bool
abs_redirect)
for (d = dget(dentry); !IS_ROOT(d);) {
const char *name;
int thislen;
+ struct dentry *parent = NULL;
spin_lock(&d->d_lock);
name = ovl_dentry_get_redirect(d);
@@ -992,7 +993,22 @@ static char *ovl_get_redirect(struct dentry *dentry, bool
abs_redirect)
buflen
[PATCH v3 2/2] arm64: dts: mt8192: add eFuse support for MT8192 SoC
From: Ryan Wu
Add eFuse node to read Mediatek eFuse
Signed-off-by: Ryan Wu
---
This patch dependents on "arm64: dts: Add Mediatek SoC MT8192 and evaluation
board dts and Makefile"[1]
mt8192.dtsi file is needed for this patch.
Please also accept this patch together with [1].
[1]http://lists.infradead.org/pipermail/linux-mediatek/2020-November/019378.html
---
arch/arm64/boot/dts/mediatek/mt8192.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8192.dtsi
b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
index 69d45c7b31f1..4a0d941aec30 100644
--- a/arch/arm64/boot/dts/mediatek/mt8192.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
@@ -422,6 +422,11 @@
#clock-cells = <1>;
};
+ efuse: efuse@11c1 {
+ compatible = "mediatek,mt8192-efuse",
+"mediatek,efuse";
+ };
+
i2c3: i2c3@11cb {
compatible = "mediatek,mt8192-i2c";
reg = <0 0x11cb 0 0x1000>,
--
2.18.0
[PATCH v3 1/2] dt-bindings: nvmem: mediatek: add support for MediaTek mt8192 SoC
From: Ryan Wu This updates dt-binding documentation for MediaTek mt8192 Signed-off-by: Ryan Wu --- This patch is based on v5.10-rc7. --- Documentation/devicetree/bindings/nvmem/mtk-efuse.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/nvmem/mtk-efuse.txt b/Documentation/devicetree/bindings/nvmem/mtk-efuse.txt index 0668c45a156d..e2f0c0f34d10 100644 --- a/Documentation/devicetree/bindings/nvmem/mtk-efuse.txt +++ b/Documentation/devicetree/bindings/nvmem/mtk-efuse.txt @@ -7,6 +7,7 @@ Required properties: "mediatek,mt7622-efuse", "mediatek,efuse": for MT7622 "mediatek,mt7623-efuse", "mediatek,efuse": for MT7623 "mediatek,mt8173-efuse" or "mediatek,efuse": for MT8173 + "mediatek,mt8192-efuse" or "mediatek,efuse": for MT8192 - reg: Should contain registers location and length = Data cells = -- 2.18.0
[PATCH v3 0/2] Add Mediatek Efuse Device Node for MT8192 SoC
From: Ryan Wu This patch adds efuse to read via NVMEM. Ryan Wu (2): dt-bindings: nvmem: mediatek: add support for MediaTek mt8192 SoC arm64: dts: mt8192: add eFuse support for MT8192 SoC Documentation/devicetree/bindings/nvmem/mtk-efuse.txt | 1 + arch/arm64/boot/dts/mediatek/mt8192.dtsi | 5 + 2 files changed, 6 insertions(+) -- 2.18.0
Re: [PATCH v2] regulators: bd718x7: Add enable times
On Fri, 2020-12-18 at 19:38 +0100, Guido Günther wrote: > Use the typical startup times from the data sheet so boards get a > reasonable default. Not setting any enable time can lead to board > hangs > when e.g. clocks are enabled too soon afterwards. > > This fixes gpu power domain resume on the Librem 5. > > Signed-off-by: Guido Günther > > --- > v2 > - As per review comment by Matti Vaittinen > > https://lore.kernel.org/lkml/beba25e85db20649aa040fc0ae549895c9265f6f.ca...@fi.rohmeurope.com/ > Use defines instead of plain values > - As per review comment by Mark Brown > https://lore.kernel.org/lkml/20201216130637.gc4...@sirena.org.uk/ > Drop cover letter > --- > drivers/regulator/bd718x7-regulator.c | 27 > include/linux/mfd/rohm-bd718x7.h | 30 Thanks again Guido. I might have preferred having the defines in bd718x7-regulator.c as they are not likely to be used outside this file. That would have strictly limited the change to regulator subsystem. Having them in the header is still fine with me if it works for Mark & others. (I don't think these defines need much of changes in the future). Reviewed-by: Matti Vaittinen Best Regards Matti Vaittinen
[ANNOUNCE] iproute2-5.10
Just in time for the holidays, new iproute2! This update is smaller than usual, not a lot of new features. It does NOT include libbpf, that will be merged in 5.11 (iproute2-next). Download: https://www.kernel.org/pub/linux/utils/net/iproute2/iproute2-5.10.0.tar.gz Repository for upcoming release: git://git.kernel.org/pub/scm/network/iproute2/iproute2.git And future release (net-next): git://git.kernel.org/pub/scm/network/iproute2/iproute2-next.git Thanks for all the contributions. Report problems (or enhancements) to the net...@vger.kernel.org mailing list. --- Andrea Claudi (4): man: tc-flower: fix manpage devlink: fix memory leak in cmd_dev_flash() tc: pedit: fix memory leak in print_pedit ss: mptcp: fix add_addr_accepted stat print Antony Antony (2): ip xfrm: support printing XFRMA_SET_MARK_MASK attribute in states ip xfrm: support setting XFRMA_SET_MARK_MASK attribute in states Ciara Loftus (1): ss: add support for xdp statistics David Ahern (5): Update kernel headers Update kernel headers Update kernel headers Update kernel headers Update kernel headers Guillaume Nault (5): m_vlan: add pop_eth and push_eth actions m_mpls: add mac_push action m_mpls: test the 'mac_push' action after 'modify' tc-vlan: fix help and error message strings tc-mpls: fix manpage example and help message string Hoang Le (1): tipc: support 128bit node identity for peer removing Jacob Keller (2): devlink: support setting the overwrite mask attribute devlink: display elapsed time during flash update Jakub Kicinski (1): ip: promote missed packets to the -s row Jiri Pirko (1): devlink: Add health reporter test command support Johannes Berg (5): libnetlink: add rtattr_for_each_nested() iteration macro libnetlink: add nl_print_policy() helper genl: ctrl: support dumping netlink policy genl: ctrl: print op -> policy idx mapping libnetlink: define __aligned conditionally Luca Boccassi (2): ip/netns: use flock when setting up /run/netns tc/mqprio: json-ify output Nikolay Aleksandrov (6): bridge: mdb: add support for source address bridge: mdb: print fast_leave flag bridge: mdb: show igmpv3/mldv2 flags bridge: mdb: print filter mode when available bridge: mdb: print source list when available bridge: mdb: print protocol when available Parav Pandit (2): devlink: Show external port attribute devlink: Show controller number of a devlink port Roopa Prabhu (1): iplink: add support for protodown reason Stephen Hemminger (15): v5.9.0 uapi: updates from 5.10-rc1 tc/m_gate: fix spelling errors man: fix spelling errors rdma: fix spelling error in comment uapi: update kernel headers from 5.10-rc2 bridge: report correct version devlink: fix uninitialized warning bridge: fix string length warning tc: fix compiler warnings in ip6 pedit misc: fix compiler warning in ifstat and nstat f_u32: fix compiler gcc-10 compiler warning uapi: update devlink.h uapi: update devlink.h uapi: merge in change to bpf.h Tuong Lien (2): tipc: add option to set master key for encryption tipc: add option to set rekeying for encryption Wei Wang (1): iproute2: ss: add support to expose various inet sockopts
Re: [PATCH] [v11] wireless: Initial driver submission for pureLiFi STA devices
Srinivasan Raju writes: >> I see lots of magic numbers in the driver like 2, 0x33 and 0x34 here. >> Please convert the magic numbers to proper defines explaining the >> meaning. And for vendor commands you could even use enum to group >> them better in .h file somewhere. > > Hi Kalle, > > Thanks for reviewing the driver, We will work on the comments. I haven't had time to do a throrough review yet, but I suggest fixing the stuff I commented and submitting v12. I'll then do a new review with v12. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
[PATCH v3 5/5] soc: aspeed: Adapt to new LPC device tree layout
Add check against LPC device v2 compatible string to
ensure that the fixed device tree layout is adopted.
The LPC register offsets are also fixed accordingly.
Signed-off-by: Chia-Wei, Wang
---
drivers/soc/aspeed/aspeed-lpc-ctrl.c | 20 ++--
drivers/soc/aspeed/aspeed-lpc-snoop.c | 23 +++
2 files changed, 29 insertions(+), 14 deletions(-)
diff --git a/drivers/soc/aspeed/aspeed-lpc-ctrl.c
b/drivers/soc/aspeed/aspeed-lpc-ctrl.c
index 439bcd6b8c4a..b04074949240 100644
--- a/drivers/soc/aspeed/aspeed-lpc-ctrl.c
+++ b/drivers/soc/aspeed/aspeed-lpc-ctrl.c
@@ -18,15 +18,15 @@
#define DEVICE_NAME"aspeed-lpc-ctrl"
-#define HICR5 0x0
+#define HICR5 0x80
#define HICR5_ENL2HBIT(8)
#define HICR5_ENFWHBIT(10)
-#define HICR6 0x4
+#define HICR6 0x84
#define SW_FWH2AHB BIT(17)
-#define HICR7 0x8
-#define HICR8 0xc
+#define HICR7 0x88
+#define HICR8 0x8c
struct aspeed_lpc_ctrl {
struct miscdevice miscdev;
@@ -215,6 +215,7 @@ static int aspeed_lpc_ctrl_probe(struct platform_device
*pdev)
struct device_node *node;
struct resource resm;
struct device *dev;
+ struct device_node *lpc_np;
int rc;
dev = &pdev->dev;
@@ -270,8 +271,15 @@ static int aspeed_lpc_ctrl_probe(struct platform_device
*pdev)
}
}
- lpc_ctrl->regmap = syscon_node_to_regmap(
- pdev->dev.parent->of_node);
+ lpc_np = pdev->dev.parent->of_node;
+ if (!of_device_is_compatible(lpc_np, "aspeed,ast2400-lpc-v2") &&
+ !of_device_is_compatible(lpc_np, "aspeed,ast2500-lpc-v2") &&
+ !of_device_is_compatible(lpc_np, "aspeed,ast2600-lpc-v2")) {
+ dev_err(dev, "unsupported LPC device binding\n");
+ return -ENODEV;
+ }
+
+ lpc_ctrl->regmap = syscon_node_to_regmap(lpc_np);
if (IS_ERR(lpc_ctrl->regmap)) {
dev_err(dev, "Couldn't get regmap\n");
return -ENODEV;
diff --git a/drivers/soc/aspeed/aspeed-lpc-snoop.c
b/drivers/soc/aspeed/aspeed-lpc-snoop.c
index 682ba0eb4eba..63c3d9b8ba61 100644
--- a/drivers/soc/aspeed/aspeed-lpc-snoop.c
+++ b/drivers/soc/aspeed/aspeed-lpc-snoop.c
@@ -28,26 +28,25 @@
#define NUM_SNOOP_CHANNELS 2
#define SNOOP_FIFO_SIZE 2048
-#define HICR5 0x0
+#define HICR5 0x80
#define HICR5_EN_SNP0W BIT(0)
#define HICR5_ENINT_SNP0W BIT(1)
#define HICR5_EN_SNP1W BIT(2)
#define HICR5_ENINT_SNP1W BIT(3)
-
-#define HICR6 0x4
+#define HICR6 0x84
#define HICR6_STR_SNP0WBIT(0)
#define HICR6_STR_SNP1WBIT(1)
-#define SNPWADR0x10
+#define SNPWADR0x90
#define SNPWADR_CH0_MASK GENMASK(15, 0)
#define SNPWADR_CH0_SHIFT 0
#define SNPWADR_CH1_MASK GENMASK(31, 16)
#define SNPWADR_CH1_SHIFT 16
-#define SNPWDR 0x14
+#define SNPWDR 0x94
#define SNPWDR_CH0_MASKGENMASK(7, 0)
#define SNPWDR_CH0_SHIFT 0
#define SNPWDR_CH1_MASKGENMASK(15, 8)
#define SNPWDR_CH1_SHIFT 8
-#define HICRB 0x80
+#define HICRB 0x100
#define HICRB_ENSNP0D BIT(14)
#define HICRB_ENSNP1D BIT(15)
@@ -258,6 +257,7 @@ static int aspeed_lpc_snoop_probe(struct platform_device
*pdev)
{
struct aspeed_lpc_snoop *lpc_snoop;
struct device *dev;
+ struct device_node *lpc_np;
u32 port;
int rc;
@@ -267,8 +267,15 @@ static int aspeed_lpc_snoop_probe(struct platform_device
*pdev)
if (!lpc_snoop)
return -ENOMEM;
- lpc_snoop->regmap = syscon_node_to_regmap(
- pdev->dev.parent->of_node);
+ lpc_np = pdev->dev.parent->of_node;
+ if (!of_device_is_compatible(lpc_np, "aspeed,ast2400-lpc-v2") &&
+ !of_device_is_compatible(lpc_np, "aspeed,ast2500-lpc-v2") &&
+ !of_device_is_compatible(lpc_np, "aspeed,ast2600-lpc-v2")) {
+ dev_err(dev, "unsupported LPC device binding\n");
+ return -ENODEV;
+ }
+
+ lpc_snoop->regmap = syscon_node_to_regmap(lpc_np);
if (IS_ERR(lpc_snoop->regmap)) {
dev_err(dev, "Couldn't get regmap\n");
return -ENODEV;
--
2.17.1
Re: [PATCH] block: aoe: replace use of __constant_htons to htons
--- Begin Message ---
On 20/12/20 07:35PM, David Laight wrote:
> From: Amey Narkhede
> > Sent: 20 December 2020 16:46
> >
> > The macro htons expands to __swab16 which has special
> > case for constants in little endian case. In big
> > endian case both __constant_htons and htons macros
> > expand to the same code. So, replace __constant_htons
> > with htons to get rid of the definition of __constant_htons
> > completely.
> >
> ...
> > static struct packet_type aoe_pt __read_mostly = {
> > - .type = __constant_htons(ETH_P_AOE),
> > + .type = htons(ETH_P_AOE),
> > .func = aoenet_rcv,
>
> Does this cause grief if someone is doing a COMPILE_TEST on LE?
>
> David
>
> -
> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1
> 1PT, UK
> Registration No: 1397386 (Wales)
>
I did COMPILE_TEST on my x86_64 machine and it compiled
without any problems.
I assume that was the point or am I missing
something? I'm a beginner contributor so please
let me know if there any mistakes.
Amey
--- End Message ---
[PATCH v3 3/5] ipmi: kcs: aspeed: Adapt to new LPC DTS layout
Add check against LPC device v2 compatible string to
ensure that the fixed device tree layout is adopted.
The LPC register offsets are also fixed accordingly.
Signed-off-by: Chia-Wei, Wang
---
drivers/char/ipmi/kcs_bmc_aspeed.c | 35 ++
1 file changed, 21 insertions(+), 14 deletions(-)
diff --git a/drivers/char/ipmi/kcs_bmc_aspeed.c
b/drivers/char/ipmi/kcs_bmc_aspeed.c
index a140203c079b..6283bfef4ea7 100644
--- a/drivers/char/ipmi/kcs_bmc_aspeed.c
+++ b/drivers/char/ipmi/kcs_bmc_aspeed.c
@@ -27,7 +27,6 @@
#define KCS_CHANNEL_MAX 4
-/* mapped to lpc-bmc@0 IO space */
#define LPC_HICR00x000
#define LPC_HICR0_LPC3E BIT(7)
#define LPC_HICR0_LPC2E BIT(6)
@@ -52,15 +51,13 @@
#define LPC_STR1 0x03C
#define LPC_STR2 0x040
#define LPC_STR3 0x044
-
-/* mapped to lpc-host@80 IO space */
-#define LPC_HICRB0x080
+#define LPC_HICRB0x100
#define LPC_HICRB_IBFIF4 BIT(1)
#define LPC_HICRB_LPC4E BIT(0)
-#define LPC_LADR40x090
-#define LPC_IDR4 0x094
-#define LPC_ODR4 0x098
-#define LPC_STR4 0x09C
+#define LPC_LADR40x110
+#define LPC_IDR4 0x114
+#define LPC_ODR4 0x118
+#define LPC_STR4 0x11C
struct aspeed_kcs_bmc {
struct regmap *map;
@@ -345,15 +342,25 @@ static int aspeed_kcs_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
struct kcs_bmc *kcs_bmc;
- struct device_node *np;
+ struct device_node *kcs_np;
+ struct device_node *lpc_np;
int rc;
- np = pdev->dev.of_node;
- if (of_device_is_compatible(np, "aspeed,ast2400-kcs-bmc") ||
- of_device_is_compatible(np, "aspeed,ast2500-kcs-bmc"))
+ kcs_np = dev->of_node;
+ lpc_np = kcs_np->parent;
+
+ if (!of_device_is_compatible(lpc_np, "aspeed,ast2400-lpc-v2") &&
+ !of_device_is_compatible(lpc_np, "aspeed,ast2500-lpc-v2") &&
+ !of_device_is_compatible(lpc_np, "aspeed,ast2600-lpc-v2")) {
+ dev_err(dev, "unsupported LPC device binding\n");
+ return -ENODEV;
+ }
+
+ if (of_device_is_compatible(kcs_np, "aspeed,ast2400-kcs-bmc") ||
+ of_device_is_compatible(kcs_np,
"aspeed,ast2500-kcs-bmc"))
kcs_bmc = aspeed_kcs_probe_of_v1(pdev);
- else if (of_device_is_compatible(np, "aspeed,ast2400-kcs-bmc-v2") ||
- of_device_is_compatible(np,
"aspeed,ast2500-kcs-bmc-v2"))
+ else if (of_device_is_compatible(kcs_np, "aspeed,ast2400-kcs-bmc-v2") ||
+ of_device_is_compatible(kcs_np,
"aspeed,ast2500-kcs-bmc-v2"))
kcs_bmc = aspeed_kcs_probe_of_v2(pdev);
else
return -EINVAL;
--
2.17.1
[PATCH v3 4/5] pinctrl: aspeed-g5: Adapt to new LPC device tree layout
Add check against LPC device v2 compatible string to
ensure that the fixed device tree layout is adopted.
The LPC register offsets are also fixed accordingly.
Signed-off-by: Chia-Wei, Wang
---
drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c | 19 +--
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c
b/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c
index 0cab4c2576e2..6e0e5b64e677 100644
--- a/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c
+++ b/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c
@@ -60,7 +60,7 @@
#define COND2 { ASPEED_IP_SCU, SCU94, GENMASK(1, 0), 0, 0 }
/* LHCR0 is offset from the end of the H8S/2168-compatible registers */
-#define LHCR0 0x20
+#define LHCR0 0xa0
#define GFX064 0x64
#define B14 0
@@ -2648,14 +2648,21 @@ static struct regmap *aspeed_g5_acquire_regmap(struct
aspeed_pinmux_data *ctx,
}
if (ip == ASPEED_IP_LPC) {
- struct device_node *node;
+ struct device_node *lhc_np;
+ struct device_node *lpc_np;
struct regmap *map;
- node = of_parse_phandle(ctx->dev->of_node,
+ lhc_np = of_parse_phandle(ctx->dev->of_node,
"aspeed,external-nodes", 1);
- if (node) {
- map = syscon_node_to_regmap(node->parent);
- of_node_put(node);
+ if (lhc_np) {
+ lpc_np = lhc_np->parent;
+ if (!of_device_is_compatible(lpc_np,
"aspeed,ast2400-lpc-v2") &&
+ !of_device_is_compatible(lpc_np,
"aspeed,ast2500-lpc-v2") &&
+ !of_device_is_compatible(lpc_np,
"aspeed,ast2600-lpc-v2"))
+ return ERR_PTR(-ENODEV);
+
+ map = syscon_node_to_regmap(lpc_np);
+ of_node_put(lhc_np);
if (IS_ERR(map))
return map;
} else
--
2.17.1
[PATCH v3 1/5] dt-bindings: aspeed-lpc: Remove LPC partitioning
The LPC controller has no concept of the BMC and the Host partitions.
This patch fixes the documentation by removing the description on LPC
partitions. The register offsets illustrated in the DTS node examples
are also fixed to adapt to the LPC DTS change.
Signed-off-by: Chia-Wei, Wang
---
.../devicetree/bindings/mfd/aspeed-lpc.txt| 99 ---
1 file changed, 21 insertions(+), 78 deletions(-)
diff --git a/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
b/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
index d0a38ba8b9ce..90eb0ecc95d1 100644
--- a/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
+++ b/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
@@ -9,13 +9,7 @@ primary use case of the Aspeed LPC controller is as a slave on
the bus
conditions it can also take the role of bus master.
The LPC controller is represented as a multi-function device to account for the
-mix of functionality it provides. The principle split is between the register
-layout at the start of the I/O space which is, to quote the Aspeed datasheet,
-"basically compatible with the [LPC registers from the] popular BMC controller
-H8S/2168[1]", and everything else, where everything else is an eclectic
-collection of functions with a esoteric register layout. "Everything else",
-here labeled the "host" portion of the controller, includes, but is not limited
-to:
+mix of functionality, which includes, but is not limited to:
* An IPMI Block Transfer[2] Controller
@@ -44,80 +38,29 @@ Required properties
===
- compatible: One of:
- "aspeed,ast2400-lpc", "simple-mfd"
- "aspeed,ast2500-lpc", "simple-mfd"
- "aspeed,ast2600-lpc", "simple-mfd"
+ "aspeed,ast2400-lpc-v2", "simple-mfd", "syscon"
+ "aspeed,ast2500-lpc-v2", "simple-mfd", "syscon"
+ "aspeed,ast2600-lpc-v2", "simple-mfd", "syscon"
- reg: contains the physical address and length values of the Aspeed
LPC memory region.
- #address-cells: <1>
- #size-cells: <1>
-- ranges: Maps 0 to the physical address and length of the LPC memory
-region
-
-Required LPC Child nodes
-
-
-BMC Node
-
-
-- compatible: One of:
- "aspeed,ast2400-lpc-bmc"
- "aspeed,ast2500-lpc-bmc"
- "aspeed,ast2600-lpc-bmc"
-
-- reg: contains the physical address and length values of the
-H8S/2168-compatible LPC controller memory region
-
-Host Node
--
-
-- compatible: One of:
- "aspeed,ast2400-lpc-host", "simple-mfd", "syscon"
- "aspeed,ast2500-lpc-host", "simple-mfd", "syscon"
- "aspeed,ast2600-lpc-host", "simple-mfd", "syscon"
-
-- reg: contains the address and length values of the host-related
-register space for the Aspeed LPC controller
-
-- #address-cells: <1>
-- #size-cells: <1>
-- ranges: Maps 0 to the address and length of the host-related LPC memory
+- ranges: Maps 0 to the physical address and length of the LPC memory
region
Example:
lpc: lpc@1e789000 {
- compatible = "aspeed,ast2500-lpc", "simple-mfd";
+ compatible = "aspeed,ast2500-lpc-v2", "simple-mfd", "syscon";
reg = <0x1e789000 0x1000>;
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x1e789000 0x1000>;
-
- lpc_bmc: lpc-bmc@0 {
- compatible = "aspeed,ast2500-lpc-bmc";
- reg = <0x0 0x80>;
- };
-
- lpc_host: lpc-host@80 {
- compatible = "aspeed,ast2500-lpc-host", "simple-mfd", "syscon";
- reg = <0x80 0x1e0>;
- reg-io-width = <4>;
-
- #address-cells = <1>;
- #size-cells = <1>;
- ranges = <0x0 0x80 0x1e0>;
- };
};
-BMC Node Children
-==
-
-
-Host Node Children
-==
LPC Host Interface Controller
---
@@ -149,14 +92,12 @@ Optional properties:
Example:
-lpc-host@80 {
- lpc_ctrl: lpc-ctrl@0 {
- compatible = "aspeed,ast2500-lpc-ctrl";
- reg = <0x0 0x80>;
- clocks = <&syscon ASPEED_CLK_GATE_LCLK>;
- memory-region = <&flash_memory>;
- flash = <&spi>;
- };
+lpc_ctrl: lpc-ctrl@80 {
+ compatible = "aspeed,ast2500-lpc-ctrl";
+ reg = <0x80 0x80>;
+ clocks = <&syscon ASPEED_CLK_GATE_LCLK>;
+ memory-region = <&flash_memory>;
+ flash = <&spi>;
};
LPC Host Controller
@@ -179,9 +120,9 @@ Required properties:
Example:
-lhc: lhc@20 {
+lhc: lhc@a0 {
compatible = "aspeed,ast2500-lhc";
- reg = <0x20 0x24 0x48 0x8>;
+ reg = <0xa0 0x24 0xc8 0x8>;
};
LPC reset control
@@ -192,16 +133,18 @@ state of the LPC bus. Some systems may chose to modify
this configuration.
Required properties:
- - compa
[PATCH v3 2/5] ARM: dts: Remove LPC BMC and Host partitions
The LPC controller has no concept of the BMC and the Host partitions.
A concrete instance is that the HICRB[5:4] are for the I/O port address
configurtaion of KCS channel 1/2. However, the KCS driver cannot access
HICRB for channel 1/2 initialization via syscon regmap interface due to
the parition boundary. (i.e. offset 80h)
In addition, for the HW design backward compatibility, a newly added HW
control bit could be located at any reserved one over the LPC addressing
space. Thereby, this patch removes the lpc-bmc and lpc-host child node
and thus the LPC partitioning.
Note that this change requires the synchronization between device tree
change and the driver change. To prevent the misuse of old devicetrees
with new drivers, or vice versa, the v2 compatible strings are adopted
for the LPC device as listed:
"aspeed,ast2400-lpc-v2"
"aspeed,ast2500-lpc-v2"
"aspeed,ast2600-lpc-v2"
Signed-off-by: Chia-Wei, Wang
---
arch/arm/boot/dts/aspeed-g4.dtsi | 74 +++--
arch/arm/boot/dts/aspeed-g5.dtsi | 135 ++-
arch/arm/boot/dts/aspeed-g6.dtsi | 135 ++-
3 files changed, 148 insertions(+), 196 deletions(-)
diff --git a/arch/arm/boot/dts/aspeed-g4.dtsi b/arch/arm/boot/dts/aspeed-g4.dtsi
index b3dafbc8caca..ee22bc036440 100644
--- a/arch/arm/boot/dts/aspeed-g4.dtsi
+++ b/arch/arm/boot/dts/aspeed-g4.dtsi
@@ -343,58 +343,44 @@
};
lpc: lpc@1e789000 {
- compatible = "aspeed,ast2400-lpc", "simple-mfd";
+ compatible = "aspeed,ast2400-lpc-v2",
"simple-mfd", "syscon";
reg = <0x1e789000 0x1000>;
+ reg-io-width = <4>;
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x1e789000 0x1000>;
- lpc_bmc: lpc-bmc@0 {
- compatible = "aspeed,ast2400-lpc-bmc";
- reg = <0x0 0x80>;
+ lpc_ctrl: lpc-ctrl@80 {
+ compatible = "aspeed,ast2400-lpc-ctrl";
+ reg = <0x80 0x10>;
+ clocks = <&syscon ASPEED_CLK_GATE_LCLK>;
+ status = "disabled";
};
- lpc_host: lpc-host@80 {
- compatible = "aspeed,ast2400-lpc-host",
"simple-mfd", "syscon";
- reg = <0x80 0x1e0>;
- reg-io-width = <4>;
-
- #address-cells = <1>;
- #size-cells = <1>;
- ranges = <0x0 0x80 0x1e0>;
-
- lpc_ctrl: lpc-ctrl@0 {
- compatible =
"aspeed,ast2400-lpc-ctrl";
- reg = <0x0 0x10>;
- clocks = <&syscon
ASPEED_CLK_GATE_LCLK>;
- status = "disabled";
- };
-
- lpc_snoop: lpc-snoop@10 {
- compatible =
"aspeed,ast2400-lpc-snoop";
- reg = <0x10 0x8>;
- interrupts = <8>;
- status = "disabled";
- };
-
- lhc: lhc@20 {
- compatible =
"aspeed,ast2400-lhc";
- reg = <0x20 0x24 0x48 0x8>;
- };
-
- lpc_reset: reset-controller@18 {
- compatible =
"aspeed,ast2400-lpc-reset";
- reg = <0x18 0x4>;
- #reset-cells = <1>;
- };
-
- ibt: ibt@c0 {
- compatible =
"aspeed,ast2400-ibt-bmc";
- reg = <0xc0 0x18>;
- interrupts = <8>;
- status = "disabled";
- };
+ lpc_snoop: lpc-snoop@90 {
+ compatible = "aspeed,ast2400-lpc-snoop";
+ reg
[PATCH v3 0/5] Remove LPC register partitioning
The LPC controller has no concept of the BMC and the Host partitions. The incorrect partitioning can impose unnecessary range restrictions on register access through the syscon regmap interface. For instance, HICRB contains the I/O port address configuration of KCS channel 1/2. However, the KCS#1/#2 drivers cannot access HICRB as it is located at the other LPC partition. In addition, to be backward compatible, the newly added HW control bits could be located at any reserved bits over the LPC addressing space. Thereby, this patch series aims to remove the LPC partitioning for better driver development and maintenance. This requires the change to both the device tree and the driver implementation. To ensure both sides are synchronously updated, a v2 binding check is added. Changes since v2: - Add v2 binding check to ensure the synchronization between the device tree change and the driver register offset fix. Changes since v1: - Add the fix to the aspeed-lpc binding documentation. Chia-Wei, Wang (5): dt-bindings: aspeed-lpc: Remove LPC partitioning ARM: dts: Remove LPC BMC and Host partitions ipmi: kcs: aspeed: Adapt to new LPC DTS layout pinctrl: aspeed-g5: Adapt to new LPC device tree layout soc: aspeed: Adapt to new LPC device tree layout .../devicetree/bindings/mfd/aspeed-lpc.txt| 99 +++-- arch/arm/boot/dts/aspeed-g4.dtsi | 74 -- arch/arm/boot/dts/aspeed-g5.dtsi | 135 -- arch/arm/boot/dts/aspeed-g6.dtsi | 135 -- drivers/char/ipmi/kcs_bmc_aspeed.c| 35 +++-- drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c| 19 ++- drivers/soc/aspeed/aspeed-lpc-ctrl.c | 20 ++- drivers/soc/aspeed/aspeed-lpc-snoop.c | 23 +-- 8 files changed, 232 insertions(+), 308 deletions(-) -- 2.17.1
RE: [PATCH] [v11] wireless: Initial driver submission for pureLiFi STA devices
> I see lots of magic numbers in the driver like 2, 0x33 and 0x34 here. > Please convert the magic numbers to proper defines explaining the meaning. > And for vendor commands you could even use enum to group them better in .h > file somewhere. Hi Kalle, Thanks for reviewing the driver, We will work on the comments. Regards, Srini
[PATCH v2] bcache: Trivial fix to register_bcache
Trivial fix to no need to check the bdev and do bdput.
Fixes: 4e7b5671c6a8("block: remove i_bdev")
Signed-off-by: Yi Li
---
drivers/md/bcache/super.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/md/bcache/super.c b/drivers/md/bcache/super.c
index f7ad1e26b013..4edf666860ad 100644
--- a/drivers/md/bcache/super.c
+++ b/drivers/md/bcache/super.c
@@ -2525,8 +2525,6 @@ static ssize_t register_bcache(struct kobject *k, struct
kobj_attribute *attr,
else
err = "device busy";
mutex_unlock(&bch_register_lock);
- if (!IS_ERR(bdev))
- bdput(bdev);
if (attr == &ksysfs_register_quiet)
goto done;
}
--
2.25.3
[PATCH] net: lantiq_etop: check the result of request_irq()
The declaration of request_irq() in is marked as
__must_check.
Without the return value check, I see the following warnings:
drivers/net/ethernet/lantiq_etop.c: In function 'ltq_etop_hw_init':
drivers/net/ethernet/lantiq_etop.c:273:4: warning: ignoring return value of
'request_irq', declared with attribute warn_unused_result [-Wunused-result]
273 | request_irq(irq, ltq_etop_dma_irq, 0, "etop_tx", priv);
| ^~
drivers/net/ethernet/lantiq_etop.c:281:4: warning: ignoring return value of
'request_irq', declared with attribute warn_unused_result [-Wunused-result]
281 | request_irq(irq, ltq_etop_dma_irq, 0, "etop_rx", priv);
| ^~
Reported-by: Miguel Ojeda
Signed-off-by: Masahiro Yamada
---
drivers/net/ethernet/lantiq_etop.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/lantiq_etop.c
b/drivers/net/ethernet/lantiq_etop.c
index 2d0c52f7106b..960494f9752b 100644
--- a/drivers/net/ethernet/lantiq_etop.c
+++ b/drivers/net/ethernet/lantiq_etop.c
@@ -264,13 +264,18 @@ ltq_etop_hw_init(struct net_device *dev)
for (i = 0; i < MAX_DMA_CHAN; i++) {
int irq = LTQ_DMA_CH0_INT + i;
struct ltq_etop_chan *ch = &priv->ch[i];
+ int ret;
ch->idx = ch->dma.nr = i;
ch->dma.dev = &priv->pdev->dev;
if (IS_TX(i)) {
ltq_dma_alloc_tx(&ch->dma);
- request_irq(irq, ltq_etop_dma_irq, 0, "etop_tx", priv);
+ ret = request_irq(irq, ltq_etop_dma_irq, 0, "etop_tx",
priv);
+ if (ret) {
+ netdev_err(dev, "failed to request irq\n");
+ return ret;
+ }
} else if (IS_RX(i)) {
ltq_dma_alloc_rx(&ch->dma);
for (ch->dma.desc = 0; ch->dma.desc < LTQ_DESC_NUM;
@@ -278,7 +283,11 @@ ltq_etop_hw_init(struct net_device *dev)
if (ltq_etop_alloc_skb(ch))
return -ENOMEM;
ch->dma.desc = 0;
- request_irq(irq, ltq_etop_dma_irq, 0, "etop_rx", priv);
+ ret = request_irq(irq, ltq_etop_dma_irq, 0, "etop_rx",
priv);
+ if (ret) {
+ netdev_err(dev, "failed to request irq\n");
+ return ret;
+ }
}
ch->dma.irq = irq;
}
--
2.27.0
Re: [PATCH 01/23] kernel: irq: irqdescs: warn on spurious IRQ
Andy Shevchenko writes:
> On Fri, Dec 18, 2020 at 4:37 PM Enrico Weigelt, metux IT consult
> wrote:
>
>> + if (printk_ratelimit())
>> + pr_warn("spurious IRQ: irq=%d hwirq=%d nr_irqs=%d\n",
>> + irq, hwirq, nr_irqs);
>
> Perhaps you missed pr_warn_ratelimit() macro which is already in the
> kernel for a long time.
pr_warn_ratelimited() which calls printk_ratelimited().
And see the comment above printk_ratelimit():
/*
* Please don't use printk_ratelimit(), because it shares ratelimiting state
* with all other unrelated printk_ratelimit() callsites. Instead use
* printk_ratelimited() or plain old __ratelimit().
*/
cheers
Re: [PATCH] mm/userfaultfd: fix memory corruption due to writeprotect
> On Dec 20, 2020, at 9:25 PM, Nadav Amit wrote:
>
>> On Dec 20, 2020, at 9:12 PM, Yu Zhao wrote:
>>
>> On Sun, Dec 20, 2020 at 08:36:15PM -0800, Nadav Amit wrote:
On Dec 19, 2020, at 6:20 PM, Andrea Arcangeli wrote:
On Sat, Dec 19, 2020 at 02:06:02PM -0800, Nadav Amit wrote:
>> On Dec 19, 2020, at 1:34 PM, Nadav Amit wrote:
>>
>> [ cc’ing some more people who have experience with similar problems ]
>>
>>> On Dec 19, 2020, at 11:15 AM, Andrea Arcangeli
>>> wrote:
>>>
>>> Hello,
>>>
>>> On Fri, Dec 18, 2020 at 08:30:06PM -0800, Nadav Amit wrote:
Analyzing this problem indicates that there is a real bug since
mmap_lock is only taken for read in mwriteprotect_range(). This might
>>>
>>> Never having to take the mmap_sem for writing, and in turn never
>>> blocking, in order to modify the pagetables is quite an important
>>> feature in uffd that justifies uffd instead of mprotect. It's not the
>>> most important reason to use uffd, but it'd be nice if that guarantee
>>> would remain also for the UFFDIO_WRITEPROTECT API, not only for the
>>> other pgtable manipulations.
>>>
Consider the following scenario with 3 CPUs (cpu2 is not shown):
cpu0 cpu1
userfaultfd_writeprotect()
[ write-protecting ]
mwriteprotect_range()
mmap_read_lock()
change_protection()
change_protection_range()
...
change_pte_range()
[ defer TLB flushes]
userfaultfd_writeprotect()
mmap_read_lock()
change_protection()
[ write-unprotect ]
...
[ unprotect PTE logically ]
Is the uffd selftest failing with upstream or after your kernel
modification that removes the tlb flush from unprotect?
>>>
>>> Please see my reply to Yu. I was wrong in this analysis, and I sent a
>>> correction to my analysis. The problem actually happens when
>>> userfaultfd_writeprotect() unprotects the memory.
>>>
} else if (uffd_wp_resolve) {
/*
* Leave the write bit to be handled
* by PF interrupt handler, then
* things like COW could be properly
* handled.
*/
ptent = pte_clear_uffd_wp(ptent);
}
Upstraem this will still do pages++, there's a tlb flush before
change_protection can return here, so I'm confused.
>>>
>>> You are correct. The problem I encountered with userfaultfd_writeprotect()
>>> is during unprotecting path.
>>>
>>> Having said that, I think that there are additional scenarios that are
>>> problematic. Consider for instance madvise_dontneed_free() that is racing
>>> with userfaultfd_writeprotect(). If madvise_dontneed_free() completed
>>> removing the PTEs, but still did not flush, change_pte_range() will see
>>> non-present PTEs, say a flush is not needed, and then
>>> change_protection_range() will not do a flush, and return while
>>> the memory is still not protected.
>>>
I don't share your concern. What matters is the PT lock, so it
wouldn't be one per pte, but a least an order 9 higher, but let's
assume one flush per pte.
It's either huge mapping and then it's likely running without other
tlb flushing in background (postcopy snapshotting), or it's a granular
protect with distributed shared memory in which case the number of
changd ptes or huge_pmds tends to be always 1 anyway. So it doesn't
matter if it's deferred.
I agree it may require a larger tlb flush review not just mprotect
though, but it didn't sound particularly complex. Note the
UFFDIO_WRITEPROTECT is still relatively recent so backports won't
risk to reject so heavy as to require a band-aid.
My second thought is, I don't see exactly the bug and it's not clear
if it's upstream reproducing this, but assuming this happens on
upstream, even ignoring everything else happening in the tlb flush
code, this sounds like purely introduced by userfaultfd_writeprotect()
vs userfaultfd_writeprotect() (since it's the only place changing
protection with mmap_sem for reading and note we already unmap and
flush tlb with mmap_sem for reading in MADV_DONTNEED/MADV_FREE clears
the dirty bit etc..). Flushing tlbs with mmap_sem for reading is
nothing new, the only new thing is the flush after wrprotect.
So instead of altering any tlb flush code, would it be pos
Fwd: Re: [PATCH] block: aoe: replace use of __constant_htons to htons
--- Begin Message ---
On 20/12/20 07:35PM, David Laight wrote:
> From: Amey Narkhede
> > Sent: 20 December 2020 16:46
> >
> > The macro htons expands to __swab16 which has special
> > case for constants in little endian case. In big
> > endian case both __constant_htons and htons macros
> > expand to the same code. So, replace __constant_htons
> > with htons to get rid of the definition of __constant_htons
> > completely.
> >
> ...
> > static struct packet_type aoe_pt __read_mostly = {
> > - .type = __constant_htons(ETH_P_AOE),
> > + .type = htons(ETH_P_AOE),
> > .func = aoenet_rcv,
>
> Does this cause grief if someone is doing a COMPILE_TEST on LE?
>
> David
>
> -
> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1
> 1PT, UK
> Registration No: 1397386 (Wales)
>
I did COMPILE_TEST on my x86_64 machine and it compiled
without any problems.
I assume that was the point or am I missing
something? I'm a beginner contributor so please
let me know if there any mistakes.
Amey
--- End Message ---
Re: [PATCH] epoll: fix compat syscall wire up of epoll_pwait2
On Sun, Dec 20, 2020 at 10:22 AM Willem de Bruijn wrote: > > Slightly tangential, it's not immediately clear to me why in > arch/x86/entry/syscalls/syscall_32.tbl epoll_pwait does not need a > compat entry, unlike on other architectures and unlike signalfd. Hmm. Good question. That looks like a bug to me. Probably nobody noticed because it's so rarely used. Or maybe I'm missing something too. Adding x86 entry code people to the participants. Linus
Re: [PATCH] epoll: fix compat syscall wire up of epoll_pwait2
On Sun, Dec 20, 2020 at 12:14 PM Arnd Bergmann wrote: > > The sigset_t argument is actually compatible between x86-32 and x86-64 Well, random high bits in size_t or the pointer value aren't. So it still looks a bit iffy to me. But it might end up working almost by accident. Linus
Re: [PATCH] mm/userfaultfd: fix memory corruption due to writeprotect
> On Dec 20, 2020, at 9:12 PM, Yu Zhao wrote:
>
> On Sun, Dec 20, 2020 at 08:36:15PM -0800, Nadav Amit wrote:
>>> On Dec 19, 2020, at 6:20 PM, Andrea Arcangeli wrote:
>>>
>>> On Sat, Dec 19, 2020 at 02:06:02PM -0800, Nadav Amit wrote:
> On Dec 19, 2020, at 1:34 PM, Nadav Amit wrote:
>
> [ cc’ing some more people who have experience with similar problems ]
>
>> On Dec 19, 2020, at 11:15 AM, Andrea Arcangeli
>> wrote:
>>
>> Hello,
>>
>> On Fri, Dec 18, 2020 at 08:30:06PM -0800, Nadav Amit wrote:
>>> Analyzing this problem indicates that there is a real bug since
>>> mmap_lock is only taken for read in mwriteprotect_range(). This might
>>
>> Never having to take the mmap_sem for writing, and in turn never
>> blocking, in order to modify the pagetables is quite an important
>> feature in uffd that justifies uffd instead of mprotect. It's not the
>> most important reason to use uffd, but it'd be nice if that guarantee
>> would remain also for the UFFDIO_WRITEPROTECT API, not only for the
>> other pgtable manipulations.
>>
>>> Consider the following scenario with 3 CPUs (cpu2 is not shown):
>>>
>>> cpu0cpu1
>>>
>>> userfaultfd_writeprotect()
>>> [ write-protecting ]
>>> mwriteprotect_range()
>>> mmap_read_lock()
>>> change_protection()
>>> change_protection_range()
>>> ...
>>> change_pte_range()
>>> [ defer TLB flushes]
>>> userfaultfd_writeprotect()
>>> mmap_read_lock()
>>> change_protection()
>>> [ write-unprotect ]
>>> ...
>>> [ unprotect PTE logically ]
>>>
>>> Is the uffd selftest failing with upstream or after your kernel
>>> modification that removes the tlb flush from unprotect?
>>
>> Please see my reply to Yu. I was wrong in this analysis, and I sent a
>> correction to my analysis. The problem actually happens when
>> userfaultfd_writeprotect() unprotects the memory.
>>
>>> } else if (uffd_wp_resolve) {
>>> /*
>>> * Leave the write bit to be handled
>>> * by PF interrupt handler, then
>>> * things like COW could be properly
>>> * handled.
>>> */
>>> ptent = pte_clear_uffd_wp(ptent);
>>> }
>>>
>>> Upstraem this will still do pages++, there's a tlb flush before
>>> change_protection can return here, so I'm confused.
>>
>> You are correct. The problem I encountered with userfaultfd_writeprotect()
>> is during unprotecting path.
>>
>> Having said that, I think that there are additional scenarios that are
>> problematic. Consider for instance madvise_dontneed_free() that is racing
>> with userfaultfd_writeprotect(). If madvise_dontneed_free() completed
>> removing the PTEs, but still did not flush, change_pte_range() will see
>> non-present PTEs, say a flush is not needed, and then
>> change_protection_range() will not do a flush, and return while
>> the memory is still not protected.
>>
>>> I don't share your concern. What matters is the PT lock, so it
>>> wouldn't be one per pte, but a least an order 9 higher, but let's
>>> assume one flush per pte.
>>>
>>> It's either huge mapping and then it's likely running without other
>>> tlb flushing in background (postcopy snapshotting), or it's a granular
>>> protect with distributed shared memory in which case the number of
>>> changd ptes or huge_pmds tends to be always 1 anyway. So it doesn't
>>> matter if it's deferred.
>>>
>>> I agree it may require a larger tlb flush review not just mprotect
>>> though, but it didn't sound particularly complex. Note the
>>> UFFDIO_WRITEPROTECT is still relatively recent so backports won't
>>> risk to reject so heavy as to require a band-aid.
>>>
>>> My second thought is, I don't see exactly the bug and it's not clear
>>> if it's upstream reproducing this, but assuming this happens on
>>> upstream, even ignoring everything else happening in the tlb flush
>>> code, this sounds like purely introduced by userfaultfd_writeprotect()
>>> vs userfaultfd_writeprotect() (since it's the only place changing
>>> protection with mmap_sem for reading and note we already unmap and
>>> flush tlb with mmap_sem for reading in MADV_DONTNEED/MADV_FREE clears
>>> the dirty bit etc..). Flushing tlbs with mmap_sem for reading is
>>> nothing new, the only new thing is the flush after wrprotect.
>>>
>>> So instead of altering any tlb flush code, would it be possible to
>>> just stick to mmap_lock for reading and then serialize
>>> userfaultfd_writeprotect() against itself with an additional
>>> mm-
Re: [PATCH v6 1/5] counter: Internalize sysfs interface code
On Sun, Dec 13, 2020 at 05:15:00PM -0600, David Lechner wrote:
> On 11/22/20 2:29 PM, William Breathitt Gray wrote:
>
> > 14 files changed, 1806 insertions(+), 2546 deletions(-)
>
> It would be really nice if we could break this down into smaller
> pieces and start getting it merged. It is really tough to keep
> reviewing this much code in one patch over and over again.
Yes, this is a pretty massive patch. I could break this across the
individual files affected to make it simpler to review, but in the end
all those patches would need to end up squashed together before merge
again (for the sake of git bisect), so the effort feels somewhat moot.
Luckily, I don't think there will be much change in the next revision
since it's looking like it'll mainly be a few bug fixes; hopefully this
coming version 7 will be the final revision before merge.
> Here are some initial findings from testing:
>
>
> > +static void counter_device_release(struct device *dev)
> > +{
> > + struct counter_device *const counter = dev_get_drvdata(dev);
> > +
> > + counter_chrdev_remove(counter);
> > + ida_simple_remove(&counter_ida, counter->id);
> > +}
>
>
> I got the following error after `modprobe -r ti-eqep`:
>
> [ 1186.045766] [ cut here ]
> [ 1186.050647] WARNING: CPU: 0 PID: 2625 at lib/refcount.c:28
> counter_device_release+0x10/0x24 [counter]
> [ 1186.059976] refcount_t: underflow; use-after-free.
> [ 1186.064790] Modules linked in: aes_arm_bs(+) crypto_simd cryptd ccm
> usb_f_mass_storage usb_f_acm u_serial usb_f_ecm rfcomm usb_f_rndis u_ether
> libcomposite aes_arm aes_generic cmac bnep wl18xx wlcore mac80211 libarc4
> sha256_generic libsha256 sha256_arm cfg80211 ti_am335x_adc kfifo_buf
> omap_aes_driver omap_crypto omap_sham crypto_engine pm33xx ti_emif_sram
> hci_uart omap_rng btbcm rng_core ti_eqep(-) counter bluetooth c_can_platform
> c_can ecdh_generic bmp280_spi ecc can_dev libaes bmp280_i2c bmp280
> industrialio omap_mailbox musb_dsps wlcore_sdio musb_hdrc udc_core usbcore
> wkup_m3_ipc at24 omap_wdt phy_am335x watchdog phy_am335x_control
> ti_am335x_tscadc phy_generic wkup_m3_rproc usb_common cppi41 rtc_omap
> leds_gpio led_class cpufreq_dt pwm_tiehrpwm autofs4
> [ 1186.132376] CPU: 0 PID: 2625 Comm: modprobe Not tainted
> 5.10.0-rc7bone-counter+ #23
> [ 1186.140070] Hardware name: Generic AM33XX (Flattened Device Tree)
> [ 1186.146225] [] (unwind_backtrace) from []
> (show_stack+0x10/0x14)
> [ 1186.154017] [] (show_stack) from []
> (dump_stack+0xc4/0xe4)
> [ 1186.161285] [] (dump_stack) from [] (__warn+0xd8/0x100)
> [ 1186.168284] [] (__warn) from []
> (warn_slowpath_fmt+0x94/0xbc)
> [ 1186.175814] [] (warn_slowpath_fmt) from []
> (counter_device_release+0x10/0x24 [counter])
> [ 1186.185632] [] (counter_device_release [counter]) from
> [] (device_release+0x30/0xa4)
> [ 1186.195163] [] (device_release) from []
> (kobject_put+0x94/0x104)
> [ 1186.202944] [] (kobject_put) from []
> (kobject_put+0x94/0x104)
> [ 1186.210472] [] (kobject_put) from []
> (ti_eqep_remove+0x10/0x30 [ti_eqep])
> [ 1186.219047] [] (ti_eqep_remove [ti_eqep]) from []
> (platform_drv_remove+0x24/0x3c)
> [ 1186.228313] [] (platform_drv_remove) from []
> (device_release_driver_internal+0xfc/0x1d0)
> [ 1186.238187] [] (device_release_driver_internal) from
> [] (driver_detach+0x58/0xa8)
> [ 1186.247456] [] (driver_detach) from []
> (bus_remove_driver+0x4c/0xa0)
> [ 1186.255594] [] (bus_remove_driver) from []
> (sys_delete_module+0x180/0x264)
> [ 1186.264250] [] (sys_delete_module) from []
> (ret_fast_syscall+0x0/0x54)
> [ 1186.272551] Exception stack(0xd247ffa8 to 0xd247fff0)
> [ 1186.277629] ffa0: 004fb478 004fb478 004fb4b4 0800
> b3bfcf00
> [ 1186.285847] ffc0: 004fb478 004fb478 004fb478 0081 be974900
> be974a55 004fb478
> [ 1186.294062] ffe0: 004f8f5c be97352c 004ddd97 b6d11d68
> [ 1186.299253] ---[ end trace e1c61dea091f1078 ]---
I noticed that I'm calling counter_chrdev_remove() twice: once in
counter_unregister(), and again in counter_device_release(). I suspect
this is what's causing the refcount to underflow. I'll test and verify
that this is the culprit.
In fact, I don't think I need to define a counter_device_release()
callback at all, would I? These cleanup function calls could be moved to
counter_unregister() instead.
> > +static ssize_t counter_comp_u8_store(struct device *dev,
> > +struct device_attribute *attr,
> > +const char *buf, size_t len)
> > +{
> > + const struct counter_attribute *const a = to_counter_attribute(attr);
> > + struct counter_device *const counter = dev_get_drvdata(dev);
> > + struct counter_count *const count = a->parent;
> > + struct counter_synapse *const synapse = a->comp.priv;
> > + const struct counter_available *const avail = a->comp.priv;
> > + int err;
> > + bool bool_data;
> > + int idx;
> > + u8 data;
> > +
> >
[PATCH V2 3/3] phy: phy-brcm-usb: support PHY on the BCM4908
From: Rafał Miłecki
BCM4908 seems to have slightly different registers but works when
programmed just like the STB one.
Signed-off-by: Rafał Miłecki
---
V2: Update Kconfig as well
---
drivers/phy/broadcom/Kconfig| 3 ++-
drivers/phy/broadcom/phy-brcm-usb.c | 4
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/phy/broadcom/Kconfig b/drivers/phy/broadcom/Kconfig
index a1f1a9c90d0d..09256339bd04 100644
--- a/drivers/phy/broadcom/Kconfig
+++ b/drivers/phy/broadcom/Kconfig
@@ -91,10 +91,11 @@ config PHY_BRCM_SATA
config PHY_BRCM_USB
tristate "Broadcom STB USB PHY driver"
- depends on ARCH_BRCMSTB || COMPILE_TEST
+ depends on ARCH_BCM4908 || ARCH_BRCMSTB || COMPILE_TEST
depends on OF
select GENERIC_PHY
select SOC_BRCMSTB
+ default ARCH_BCM4908
default ARCH_BRCMSTB
help
Enable this to support the Broadcom STB USB PHY.
diff --git a/drivers/phy/broadcom/phy-brcm-usb.c
b/drivers/phy/broadcom/phy-brcm-usb.c
index 99fbc7e4138b..63f922a5f29b 100644
--- a/drivers/phy/broadcom/phy-brcm-usb.c
+++ b/drivers/phy/broadcom/phy-brcm-usb.c
@@ -285,6 +285,10 @@ static const struct match_chip_info chip_info_7445 = {
};
static const struct of_device_id brcm_usb_dt_ids[] = {
+ {
+ .compatible = "brcm,bcm4908-usb-phy",
+ .data = &chip_info_7445,
+ },
{
.compatible = "brcm,bcm7216-usb-phy",
.data = &chip_info_7216,
--
2.26.2
[PATCH V2 2/3] dt-bindings: phy: brcm,brcmstb-usb-phy: add BCM4908 binding
From: Rafał Miłecki BCM4908 uses the same PHY and may require just a slightly different programming. Signed-off-by: Rafał Miłecki Acked-by: Florian Fainelli --- .../devicetree/bindings/phy/brcm,brcmstb-usb-phy.yaml| 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.yaml b/Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.yaml index 1dad1e3df1a5..2bdcb649808b 100644 --- a/Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.yaml +++ b/Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.yaml @@ -15,6 +15,7 @@ maintainers: properties: compatible: enum: + - brcm,bcm4908-usb-phy - brcm,bcm7211-usb-phy - brcm,bcm7216-usb-phy - brcm,brcmstb-usb-phy @@ -91,7 +92,9 @@ allOf: properties: compatible: contains: -const: brcm,brcmstb-usb-phy +enum: + - const: brcm,bcm4908-usb-phy + - const: brcm,brcmstb-usb-phy then: properties: reg: -- 2.26.2
[PATCH V2 1/3] dt-bindings: phy: brcm,brcmstb-usb-phy: convert to the json-schema
From: Rafał Miłecki
Changes that require mentioning:
1. interrupt-names
Name "wakeup" was changed to the "wake". It matches example and what
Linux driver looks for in the first place
2. brcm,ipp and brcm,ioc
Both were described as booleans with 0 / 1 values. In examples they
were integers and Linux driver checks for int as well.
I made both uint32 but that probably should be refactored later.
3. Added minimal description
Signed-off-by: Rafał Miłecki
---
V2: Add Al as maintainer
---
.../bindings/phy/brcm,brcmstb-usb-phy.txt | 86
.../bindings/phy/brcm,brcmstb-usb-phy.yaml| 196 ++
2 files changed, 196 insertions(+), 86 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.txt
create mode 100644
Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.yaml
diff --git a/Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.txt
b/Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.txt
deleted file mode 100644
index 698aacbdcfc4..
--- a/Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.txt
+++ /dev/null
@@ -1,86 +0,0 @@
-Broadcom STB USB PHY
-
-Required properties:
-- compatible: should be one of
- "brcm,brcmstb-usb-phy"
- "brcm,bcm7216-usb-phy"
- "brcm,bcm7211-usb-phy"
-
-- reg and reg-names properties requirements are specific to the
- compatible string.
- "brcm,brcmstb-usb-phy":
-- reg: 1 or 2 offset and length pairs. One for the base CTRL registers
- and an optional pair for systems with USB 3.x support
-- reg-names: not specified
- "brcm,bcm7216-usb-phy":
-- reg: 3 offset and length pairs for CTRL, XHCI_EC and XHCI_GBL
- registers
-- reg-names: "ctrl", "xhci_ec", "xhci_gbl"
- "brcm,bcm7211-usb-phy":
-- reg: 5 offset and length pairs for CTRL, XHCI_EC, XHCI_GBL,
- USB_PHY and USB_MDIO registers and an optional pair
- for the BDC registers
-- reg-names: "ctrl", "xhci_ec", "xhci_gbl", "usb_phy", "usb_mdio", "bdc_ec"
-
-- #phy-cells: Shall be 1 as it expects one argument for setting
- the type of the PHY. Possible values are:
- - PHY_TYPE_USB2 for USB1.1/2.0 PHY
- - PHY_TYPE_USB3 for USB3.x PHY
-
-Optional Properties:
-- clocks : clock phandles.
-- clock-names: String, clock name.
-- interrupts: wakeup interrupt
-- interrupt-names: "wakeup"
-- brcm,ipp: Boolean, Invert Port Power.
- Possible values are: 0 (Don't invert), 1 (Invert)
-- brcm,ioc: Boolean, Invert Over Current detection.
- Possible values are: 0 (Don't invert), 1 (Invert)
-- dr_mode: String, PHY Device mode.
- Possible values are: "host", "peripheral ", "drd" or "typec-pd"
- If this property is not defined, the phy will default to "host" mode.
-- brcm,syscon-piarbctl: phandle to syscon for handling config registers
-NOTE: one or both of the following two properties must be set
-- brcm,has-xhci: Boolean indicating the phy has an XHCI phy.
-- brcm,has-eohci: Boolean indicating the phy has an EHCI/OHCI phy.
-
-
-Example:
-
-usbphy_0: usb-phy@f0470200 {
- reg = <0xf0470200 0xb8>,
- <0xf0471940 0x6c0>;
- compatible = "brcm,brcmstb-usb-phy";
- #phy-cells = <1>;
- dr_mode = "host"
- brcm,ioc = <1>;
- brcm,ipp = <1>;
- brcm,has-xhci;
- brcm,has-eohci;
- clocks = <&usb20>, <&usb30>;
- clock-names = "sw_usb", "sw_usb3";
-};
-
-usb-phy@29f0200 {
- reg = <0x29f0200 0x200>,
- <0x29c0880 0x30>,
- <0x29cc100 0x534>,
- <0x2808000 0x24>,
- <0x2980080 0x8>;
- reg-names = "ctrl",
- "xhci_ec",
- "xhci_gbl",
- "usb_phy",
- "usb_mdio";
- brcm,ioc = <0x0>;
- brcm,ipp = <0x0>;
- compatible = "brcm,bcm7211-usb-phy";
- interrupts = <0x30>;
- interrupt-parent = <&vpu_intr1_nosec_intc>;
- interrupt-names = "wake";
- #phy-cells = <0x1>;
- brcm,has-xhci;
- syscon-piarbctl = <&syscon_piarbctl>;
- clocks = <&scmi_clk 256>;
- clock-names = "sw_usb";
-};
diff --git a/Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.yaml
b/Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.yaml
new file mode 100644
index ..1dad1e3df1a5
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.yaml
@@ -0,0 +1,196 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/brcm,brcmstb-usb-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom STB USB PHY
+
+description: Broadcom's PHY that handles EHCI/OHCI and/or XHCI
+
+maintainers:
+ - Al Cooper
+ - Rafał Miłecki
+
+properties:
+ compatible:
+enum:
+ - brcm,bcm7211-usb-phy
+ - brcm,bcm7216-usb-phy
+ - brcm,brcmstb-usb-phy
+
+ clocks:
+minItems: 1
+maxItems: 2
+
+ clo
Re: [PATCH v4 1/5] soc: mediatek: pwrap: use BIT() macro
On Wed, Nov 18, 2020 at 8:08 PM Hsin-Hsiung Wang wrote: > > Use a better BIT() marco for the bit definition. > No functional changes, cleanup only. > > Signed-off-by: Hsin-Hsiung Wang Reviewed-by: Nicolas Boichat > --- > drivers/soc/mediatek/mtk-pmic-wrap.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/soc/mediatek/mtk-pmic-wrap.c > b/drivers/soc/mediatek/mtk-pmic-wrap.c > index 5d34e8b..c897205 100644 > --- a/drivers/soc/mediatek/mtk-pmic-wrap.c > +++ b/drivers/soc/mediatek/mtk-pmic-wrap.c > @@ -27,8 +27,8 @@ > #define PWRAP_GET_WACS_RDATA(x)(((x) >> 0) & 0x) > #define PWRAP_GET_WACS_FSM(x) (((x) >> 16) & 0x0007) > #define PWRAP_GET_WACS_REQ(x) (((x) >> 19) & 0x0001) > -#define PWRAP_STATE_SYNC_IDLE0 (1 << 20) > -#define PWRAP_STATE_INIT_DONE0 (1 << 21) > +#define PWRAP_STATE_SYNC_IDLE0 BIT(20) > +#define PWRAP_STATE_INIT_DONE0 BIT(21) > > /* macro for WACS FSM */ > #define PWRAP_WACS_FSM_IDLE0x00 > -- > 2.6.4 >
[PATCH v2] staging: rtl8192e: fix bool comparison in expressions
There are certain conditional expressions in rtl8192e, where a boolean
variable is compared with true/false, in forms such as (foo == true) or
(false != bar), which does not comply with checkpatch.pl (CHECK:
BOOL_COMPARISON), according to which boolean variables should be
themselves used in the condition, rather than comparing with true/false
E.g. in drivers/staging/rtl8192e/rtl8192e/r8192E_dev.c,
"if (Type == true)" can be replaced with: "if (Type)"
Replace all such expressions with the bool variables appropriately
Signed-off-by: Aditya Srivastava
---
- the changes made are compile tested
- the patch applies perfectly over next-20201218
Changes in v2:
- drivers/staging/rtl8192e/rtl8192e/r8192E_dev.c: Replace "else if (!Type)"
with "else"
- drivers/staging/rtl8192e/rtllib_rx.c: Remove bracket from
"(!ieee->pHTInfo->bCurRxReorderEnable)"
- drivers/staging/rtl8192e/rtllib_rx.c: Put bToOtherSTA on previous line
drivers/staging/rtl8192e/rtl8192e/r8192E_dev.c | 4 ++--
drivers/staging/rtl8192e/rtl8192e/rtl_core.c | 4 ++--
drivers/staging/rtl8192e/rtl8192e/rtl_dm.c | 4 ++--
drivers/staging/rtl8192e/rtllib_rx.c | 5 ++---
drivers/staging/rtl8192e/rtllib_tx.c | 8
5 files changed, 12 insertions(+), 13 deletions(-)
diff --git a/drivers/staging/rtl8192e/rtl8192e/r8192E_dev.c
b/drivers/staging/rtl8192e/rtl8192e/r8192E_dev.c
index 9f869fb3eaa8..ff843d7ec606 100644
--- a/drivers/staging/rtl8192e/rtl8192e/r8192E_dev.c
+++ b/drivers/staging/rtl8192e/rtl8192e/r8192E_dev.c
@@ -129,9 +129,9 @@ void rtl92e_set_reg(struct net_device *dev, u8 variable, u8
*val)
RegRCR = rtl92e_readl(dev, RCR);
priv->ReceiveConfig = RegRCR;
- if (Type == true)
+ if (Type)
RegRCR |= (RCR_CBSSID);
- else if (Type == false)
+ else
RegRCR &= (~RCR_CBSSID);
rtl92e_writel(dev, RCR, RegRCR);
diff --git a/drivers/staging/rtl8192e/rtl8192e/rtl_core.c
b/drivers/staging/rtl8192e/rtl8192e/rtl_core.c
index 663675efcfe4..9078fadd65f9 100644
--- a/drivers/staging/rtl8192e/rtl8192e/rtl_core.c
+++ b/drivers/staging/rtl8192e/rtl8192e/rtl_core.c
@@ -1389,7 +1389,7 @@ static void _rtl92e_watchdog_wq_cb(void *data)
rtl92e_dm_watchdog(dev);
- if (rtllib_act_scanning(priv->rtllib, false) == false) {
+ if (!rtllib_act_scanning(priv->rtllib, false)) {
if ((ieee->iw_mode == IW_MODE_INFRA) && (ieee->state ==
RTLLIB_NOLINK) &&
(ieee->eRFPowerState == eRfOn) && !ieee->is_set_key &&
@@ -2471,7 +2471,7 @@ static int _rtl92e_pci_probe(struct pci_dev *pdev,
priv->ops = ops;
- if (rtl92e_check_adapter(pdev, dev) == false)
+ if (!rtl92e_check_adapter(pdev, dev))
goto err_unmap;
dev->irq = pdev->irq;
diff --git a/drivers/staging/rtl8192e/rtl8192e/rtl_dm.c
b/drivers/staging/rtl8192e/rtl8192e/rtl_dm.c
index 462835684e8b..e340be3ebb97 100644
--- a/drivers/staging/rtl8192e/rtl8192e/rtl_dm.c
+++ b/drivers/staging/rtl8192e/rtl8192e/rtl_dm.c
@@ -1765,7 +1765,7 @@ static void _rtl92e_dm_cts_to_self(struct net_device *dev)
unsigned long curTxOkCnt = 0;
unsigned long curRxOkCnt = 0;
- if (priv->rtllib->bCTSToSelfEnable != true) {
+ if (!priv->rtllib->bCTSToSelfEnable) {
pHTInfo->IOTAction &= ~HT_IOT_ACT_FORCED_CTS2SELF;
return;
}
@@ -2447,7 +2447,7 @@ static void _rtl92e_dm_dynamic_tx_power(struct net_device
*dev)
unsigned int txhipower_threshold = 0;
unsigned int txlowpower_threshold = 0;
- if (priv->rtllib->bdynamic_txpower_enable != true) {
+ if (!priv->rtllib->bdynamic_txpower_enable) {
priv->bDynamicTxHighPower = false;
priv->bDynamicTxLowPower = false;
return;
diff --git a/drivers/staging/rtl8192e/rtllib_rx.c
b/drivers/staging/rtl8192e/rtllib_rx.c
index d31b5e1c8df4..66c135321da4 100644
--- a/drivers/staging/rtl8192e/rtllib_rx.c
+++ b/drivers/staging/rtl8192e/rtllib_rx.c
@@ -924,7 +924,7 @@ static int rtllib_rx_check_duplicate(struct rtllib_device
*ieee,
sc = le16_to_cpu(hdr->seq_ctl);
frag = WLAN_GET_SEQ_FRAG(sc);
- if ((ieee->pHTInfo->bCurRxReorderEnable == false) ||
+ if (!ieee->pHTInfo->bCurRxReorderEnable ||
!ieee->current_network.qos_data.active ||
!IsDataFrame(skb->data) ||
IsLegacyDataFrame(skb->data)) {
@@ -1442,8 +1442,7 @@ static int rtllib_rx_InfraAdhoc(struct rtllib_device
*ieee, struct sk_buff *skb,
}
/* Indicate packets to upper layer or Rx Reorder */
- if (ieee->pHTInfo->bCurRxReorderEnable == false || pTS == NULL ||
- bToOtherSTA)
+ if (!ieee->pHTInfo->bCurRxReorderEnable || pTS == NULL || bToOtherSTA)
rtllib_rx_indicate_pkt_legacy(ieee, rx_stats, rxb, d
linux-next: build failure after merge of the akpm tree
Hi all,
After merging the akpm tree, today's linux-next build (arm64 allmodconfig)
failed like this:
./include/uapi/asm-generic/unistd.h:867:27: error: array index in initializer
exceeds array bounds
Caused by commit
390e5073c473 ("arch, mm: wire up memfd_secret system call where relevant")
d098835811e0 ("arch-mm-wire-up-memfd_secret-system-call-were-relevant-fix")
Reported-by: kernelci.org bot
I will apply the following patch tomorrow:
From: Stephen Rothwell
Date: Mon, 21 Dec 2020 16:10:40 +1100
Subject: [PATCH] arch-mm-wire-up-memfd_secret-system-call-were-relevant-fix-fix
Signed-off-by: Stephen Rothwell
---
include/uapi/asm-generic/unistd.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/uapi/asm-generic/unistd.h
b/include/uapi/asm-generic/unistd.h
index 72b94deb8cf1..26125974a8a2 100644
--- a/include/uapi/asm-generic/unistd.h
+++ b/include/uapi/asm-generic/unistd.h
@@ -869,7 +869,7 @@ __SYSCALL(__NR_memfd_secret, sys_memfd_secret)
#endif
#undef __NR_syscalls
-#define __NR_syscalls 443
+#define __NR_syscalls 444
/*
* 32 bit systems traditionally used different
--
2.29.2
--
Cheers,
Stephen Rothwell
pgpbJ4IgUHZkq.pgp
Description: OpenPGP digital signature
Re: [PATCH] MAINTAINERS: adjust GCC PLUGINS after gcc-plugin.sh removal
On Sun, Dec 20, 2020 at 1:25 AM Lukas Bulwahn wrote:
>
> Commit 1e860048c53e ("gcc-plugins: simplify GCC plugin-dev capability test")
> removed ./scripts/gcc-plugin.sh, but missed to adjust MAINTAINERS.
>
> Hence, ./scripts/get_maintainers.pl --self-test=patterns warns:
>
> warning: no file matchesF:scripts/gcc-plugin.sh
>
> Adjust entries in GGC PLUGINS section after this file removal.
>
> Signed-off-by: Lukas Bulwahn
Applied to linux-kbuild. Thanks.
> ---
> applies cleanly on next-20201218
>
> Masahiro-san, please pick this minor cleanup patch on your -next tree.
>
> MAINTAINERS | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index f5eafee83bc6..fd3b06636c5b 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -7371,7 +7371,6 @@ L:linux-harden...@vger.kernel.org
> S: Maintained
> F: Documentation/kbuild/gcc-plugins.rst
> F: scripts/Makefile.gcc-plugins
> -F: scripts/gcc-plugin.sh
> F: scripts/gcc-plugins/
>
> GCOV BASED KERNEL PROFILING
> --
> 2.17.1
>
--
Best Regards
Masahiro Yamada
[PATCH] cpufreq: intel_pstate: remove obsolete functions
percent_fp() was used in intel_pstate_pid_reset(), which was removed in
commit 9d0ef7af1f2d ("cpufreq: intel_pstate: Do not use PID-based P-state
selection") and hence, percent_fp() is unused since then.
percent_ext_fp() was last used in intel_pstate_update_perf_limits(), which
was refactored in commit 1a4fe38add8b ("cpufreq: intel_pstate: Remove
max/min fractions to limit performance"), and hence, percent_ext_fp() is
unused since then.
make CC=clang W=1 points us those unused functions:
drivers/cpufreq/intel_pstate.c:79:23: warning: unused function 'percent_fp'
[-Wunused-function]
static inline int32_t percent_fp(int percent)
^
drivers/cpufreq/intel_pstate.c:94:23: warning: unused function 'percent_ext_fp'
[-Wunused-function]
static inline int32_t percent_ext_fp(int percent)
^
Remove those obsolete functions.
Signed-off-by: Lukas Bulwahn
---
applies cleanly on current master and next-20201221
Srinivas, Len, Rafael, Viresh, please pick this minor non-urgent cleanup patch.
drivers/cpufreq/intel_pstate.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index 2a4db856222f..0e35dd247986 100644
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -76,11 +76,6 @@ static inline int ceiling_fp(int32_t x)
return ret;
}
-static inline int32_t percent_fp(int percent)
-{
- return div_fp(percent, 100);
-}
-
static inline u64 mul_ext_fp(u64 x, u64 y)
{
return (x * y) >> EXT_FRAC_BITS;
@@ -91,11 +86,6 @@ static inline u64 div_ext_fp(u64 x, u64 y)
return div64_u64(x << EXT_FRAC_BITS, y);
}
-static inline int32_t percent_ext_fp(int percent)
-{
- return div_ext_fp(percent, 100);
-}
-
/**
* struct sample - Store performance sample
* @core_avg_perf: Ratio of APERF/MPERF which is the actual average
--
2.17.1
Re: [PATCH] mm/userfaultfd: fix memory corruption due to writeprotect
On Sun, Dec 20, 2020 at 08:36:15PM -0800, Nadav Amit wrote:
> > On Dec 19, 2020, at 6:20 PM, Andrea Arcangeli wrote:
> >
> > On Sat, Dec 19, 2020 at 02:06:02PM -0800, Nadav Amit wrote:
> >>> On Dec 19, 2020, at 1:34 PM, Nadav Amit wrote:
> >>>
> >>> [ cc’ing some more people who have experience with similar problems ]
> >>>
> On Dec 19, 2020, at 11:15 AM, Andrea Arcangeli
> wrote:
>
> Hello,
>
> On Fri, Dec 18, 2020 at 08:30:06PM -0800, Nadav Amit wrote:
> > Analyzing this problem indicates that there is a real bug since
> > mmap_lock is only taken for read in mwriteprotect_range(). This might
>
> Never having to take the mmap_sem for writing, and in turn never
> blocking, in order to modify the pagetables is quite an important
> feature in uffd that justifies uffd instead of mprotect. It's not the
> most important reason to use uffd, but it'd be nice if that guarantee
> would remain also for the UFFDIO_WRITEPROTECT API, not only for the
> other pgtable manipulations.
>
> > Consider the following scenario with 3 CPUs (cpu2 is not shown):
> >
> > cpu0cpu1
> >
> > userfaultfd_writeprotect()
> > [ write-protecting ]
> > mwriteprotect_range()
> > mmap_read_lock()
> > change_protection()
> > change_protection_range()
> > ...
> > change_pte_range()
> > [ defer TLB flushes]
> > userfaultfd_writeprotect()
> > mmap_read_lock()
> > change_protection()
> > [ write-unprotect ]
> > ...
> > [ unprotect PTE logically ]
> >
> > Is the uffd selftest failing with upstream or after your kernel
> > modification that removes the tlb flush from unprotect?
>
> Please see my reply to Yu. I was wrong in this analysis, and I sent a
> correction to my analysis. The problem actually happens when
> userfaultfd_writeprotect() unprotects the memory.
>
> > } else if (uffd_wp_resolve) {
> > /*
> > * Leave the write bit to be handled
> > * by PF interrupt handler, then
> > * things like COW could be properly
> > * handled.
> > */
> > ptent = pte_clear_uffd_wp(ptent);
> > }
> >
> > Upstraem this will still do pages++, there's a tlb flush before
> > change_protection can return here, so I'm confused.
> >
>
> You are correct. The problem I encountered with userfaultfd_writeprotect()
> is during unprotecting path.
>
> Having said that, I think that there are additional scenarios that are
> problematic. Consider for instance madvise_dontneed_free() that is racing
> with userfaultfd_writeprotect(). If madvise_dontneed_free() completed
> removing the PTEs, but still did not flush, change_pte_range() will see
> non-present PTEs, say a flush is not needed, and then
> change_protection_range() will not do a flush, and return while
> the memory is still not protected.
>
> > I don't share your concern. What matters is the PT lock, so it
> > wouldn't be one per pte, but a least an order 9 higher, but let's
> > assume one flush per pte.
> >
> > It's either huge mapping and then it's likely running without other
> > tlb flushing in background (postcopy snapshotting), or it's a granular
> > protect with distributed shared memory in which case the number of
> > changd ptes or huge_pmds tends to be always 1 anyway. So it doesn't
> > matter if it's deferred.
> >
> > I agree it may require a larger tlb flush review not just mprotect
> > though, but it didn't sound particularly complex. Note the
> > UFFDIO_WRITEPROTECT is still relatively recent so backports won't
> > risk to reject so heavy as to require a band-aid.
> >
> > My second thought is, I don't see exactly the bug and it's not clear
> > if it's upstream reproducing this, but assuming this happens on
> > upstream, even ignoring everything else happening in the tlb flush
> > code, this sounds like purely introduced by userfaultfd_writeprotect()
> > vs userfaultfd_writeprotect() (since it's the only place changing
> > protection with mmap_sem for reading and note we already unmap and
> > flush tlb with mmap_sem for reading in MADV_DONTNEED/MADV_FREE clears
> > the dirty bit etc..). Flushing tlbs with mmap_sem for reading is
> > nothing new, the only new thing is the flush after wrprotect.
> >
> > So instead of altering any tlb flush code, would it be possible to
> > just stick to mmap_lock for reading and then serialize
> > userfaultfd_writeprotect() against itself with an additional
> > mm->mmap_wprotect_lock mutex? That'd be a very
Re: [v5,2/3] PCI: mediatek-gen3: Add MediaTek Gen3 driver for MT8192
On Wed, Dec 2, 2020 at 9:39 PM Jianjun Wang wrote:
>
> MediaTek's PCIe host controller has three generation HWs, the new
> generation HW is an individual bridge, it supports Gen3 speed and
> up to 256 MSI interrupt numbers for multi-function devices.
>
> Add support for new Gen3 controller which can be found on MT8192.
>
> Signed-off-by: Jianjun Wang
> Acked-by: Ryder Lee
FWIW, I looked at Rob and Bjorn's comments on v4, and they seem to
have been addressed (with one small nit highlighted below).
> ---
> This patch dependents on "PCI: Export pci_pio_to_address() for module use"[1]
> to build as a kernel module.
>
> This interface will be used by PCI host drivers for PIO translation,
> export it to support compiling those drivers as kernel modules.
>
> [1]http://lists.infradead.org/pipermail/linux-mediatek/2020-December/019504.html
> ---
> drivers/pci/controller/Kconfig | 13 +
> drivers/pci/controller/Makefile |1 +
> drivers/pci/controller/pcie-mediatek-gen3.c | 1039 +++
> 3 files changed, 1053 insertions(+)
> create mode 100644 drivers/pci/controller/pcie-mediatek-gen3.c
>
> [snip]
> diff --git a/drivers/pci/controller/pcie-mediatek-gen3.c
> b/drivers/pci/controller/pcie-mediatek-gen3.c
> new file mode 100644
> index ..d30ea734ac0a
> --- /dev/null
> +++ b/drivers/pci/controller/pcie-mediatek-gen3.c
> @@ -0,0 +1,1039 @@
> [snip]
> +static int mtk_pcie_set_trans_table(struct mtk_pcie_port *port,
> + resource_size_t cpu_addr,
> + resource_size_t pci_addr,
> + resource_size_t size,
> + unsigned long type, int num)
> +{
> + void __iomem *table;
> + u32 val = 0;
You don't need to init val to 0.
> +
> + if (num >= PCIE_MAX_TRANS_TABLES) {
> + dev_notice(port->dev, "not enough translate table[%d] for
> addr: %#llx, limited to [%d]\n",
> + num, (unsigned long long) cpu_addr,
> + PCIE_MAX_TRANS_TABLES);
> + return -ENODEV;
> + }
> +
> + table = port->base + PCIE_TRANS_TABLE_BASE_REG +
> + num * PCIE_ATR_TLB_SET_OFFSET;
> +
> + writel(lower_32_bits(cpu_addr) | PCIE_ATR_SIZE(fls(size) - 1), table);
> + writel(upper_32_bits(cpu_addr), table + PCIE_ATR_SRC_ADDR_MSB_OFFSET);
> + writel(lower_32_bits(pci_addr), table +
> PCIE_ATR_TRSL_ADDR_LSB_OFFSET);
> + writel(upper_32_bits(pci_addr), table +
> PCIE_ATR_TRSL_ADDR_MSB_OFFSET);
> +
> + if (type == IORESOURCE_IO)
> + val = PCIE_ATR_TYPE_IO | PCIE_ATR_TLP_TYPE_IO;
> + else
> + val = PCIE_ATR_TYPE_MEM | PCIE_ATR_TLP_TYPE_MEM;
> +
> + writel(val, table + PCIE_ATR_TRSL_PARAM_OFFSET);
> +
> + return 0;
> +}
> +
> +static int mtk_pcie_startup_port(struct mtk_pcie_port *port)
> +{
> + struct resource_entry *entry;
> + struct pci_host_bridge *host = pci_host_bridge_from_priv(port);
> + unsigned int table_index = 0;
> + int err;
> + u32 val;
> +
> + /* Set as RC mode */
> + val = readl(port->base + PCIE_SETTING_REG);
> + val |= PCIE_RC_MODE;
> + writel(val, port->base + PCIE_SETTING_REG);
> +
> + /* Set class code */
> + val = readl(port->base + PCIE_PCI_IDS_1);
> + val &= ~GENMASK(31, 8);
> + val |= PCI_CLASS(PCI_CLASS_BRIDGE_PCI << 8);
> + writel(val, port->base + PCIE_PCI_IDS_1);
> +
> + /* Assert all reset signals */
> + val = readl(port->base + PCIE_RST_CTRL_REG);
> + val |= PCIE_MAC_RSTB | PCIE_PHY_RSTB | PCIE_BRG_RSTB | PCIE_PE_RSTB;
> + writel(val, port->base + PCIE_RST_CTRL_REG);
> +
> + /* De-assert reset signals */
> + val &= ~(PCIE_MAC_RSTB | PCIE_PHY_RSTB | PCIE_BRG_RSTB);
> + writel(val, port->base + PCIE_RST_CTRL_REG);
> +
> + /* Delay 100ms to wait the reference clocks become stable */
> + usleep_range(100 * 1000, 120 * 1000);
Any reason not to use msleep(100)?
> +
> + /* De-assert PERST# signal */
> + val &= ~PCIE_PE_RSTB;
> + writel(val, port->base + PCIE_RST_CTRL_REG);
> +
> + /* Check if the link is up or not */
> + err = readl_poll_timeout(port->base + PCIE_LINK_STATUS_REG, val,
> + !!(val & PCIE_PORT_LINKUP), 20,
> + 50 * USEC_PER_MSEC);
> + if (err) {
> + val = readl(port->base + PCIE_LTSSM_STATUS_REG);
> + dev_notice(port->dev, "PCIe link down, ltssm reg val: %#x\n",
> + val);
> + return err;
> + }
> +
> + /* Set PCIe translation windows */
> + resource_list_for_each_entry(entry, &host->windows) {
> + struct resource *res = entry->res;
> + unsigned long type = resource_type(res);
> + resource_size_t cpu_addr;
> +
Re: [PATCH v4 9/9] media: uvcvideo: Implement UVC_QUIRK_PRIVACY_DURING_STREAM
HI
On Sun, Dec 20, 2020 at 6:22 PM Laurent Pinchart
wrote:
>
> Hi Ricardo,
>
> Thank you for the patch.
>
> On Tue, Dec 15, 2020 at 04:44:39PM +0100, Ricardo Ribalda wrote:
> > Some devices, can only read the privacy_pin if the device is
> > streaming.
>
> :-(
:"-(
>
> > This patch implement a quirk for such devices, in order to avoid invalid
> > reads and/or spurious events.
> >
> > Signed-off-by: Ricardo Ribalda
> > ---
> > drivers/media/usb/uvc/uvc_driver.c | 97 ++
> > drivers/media/usb/uvc/uvc_queue.c | 3 +
> > drivers/media/usb/uvc/uvcvideo.h | 6 ++
> > 3 files changed, 94 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/media/usb/uvc/uvc_driver.c
> > b/drivers/media/usb/uvc/uvc_driver.c
> > index e49491250e87..61313019e226 100644
> > --- a/drivers/media/usb/uvc/uvc_driver.c
> > +++ b/drivers/media/usb/uvc/uvc_driver.c
> > @@ -7,6 +7,7 @@
> > */
> >
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -1471,13 +1472,39 @@ static int uvc_parse_control(struct uvc_device *dev)
> > return 0;
> > }
> >
> > +static bool uvc_ext_gpio_is_streaming(struct uvc_device *dev)
> > +{
> > + struct uvc_streaming *streaming;
> > +
> > + list_for_each_entry(streaming, &dev->streams, list) {
> > + if (uvc_queue_streaming(&streaming->queue))
> > + return true;
> > + }
> > +
> > + return false;
> > +}
> > +
> > +/* Update the cached value and return true if it has changed */
> > +static bool uvc_gpio_update_value(struct uvc_entity *unit, u8 *new_val)
> > +{
> > + *new_val = gpiod_get_value(unit->gpio.gpio_privacy);
> > +
> > + return atomic_xchg(&unit->gpio.gpio_privacy_value, *new_val) !=
> > +
> > *new_val;
>
> That's a weird indentation. Also, as the left hand side modifies
> *new_val, does C guarantee the order in which the two operands to != are
> evaluated ? Could the code be written in an easier to read way ?
>
> > +}
> > +
> > static int uvc_gpio_get_cur(struct uvc_device *dev, struct uvc_entity
> > *entity,
> > u8 cs, void *data, u16 size)
> > {
> > if (cs != UVC_CT_PRIVACY_CONTROL || size < 1)
> > return -EINVAL;
> >
> > - *(uint8_t *)data = gpiod_get_value(entity->gpio.gpio_privacy);
> > + if ((dev->quirks & UVC_QUIRK_PRIVACY_DURING_STREAM) &&
> > + !uvc_ext_gpio_is_streaming(dev))
> > + return -EBUSY;
> > +
> > + uvc_gpio_update_value(entity, (uint8_t *)data);
> > +
> > return 0;
> > }
> >
> > @@ -1491,26 +1518,69 @@ static int uvc_gpio_get_info(struct uvc_device
> > *dev, struct uvc_entity *entity,
> > return 0;
> > }
> >
> > -static irqreturn_t uvc_privacy_gpio_irq(int irq, void *data)
> > +static struct uvc_entity *uvc_find_ext_gpio_unit(struct uvc_device *dev)
> > {
> > - struct uvc_device *dev = data;
> > - struct uvc_video_chain *chain;
> > struct uvc_entity *unit;
> > - u8 value;
> >
> > - /* GPIO entities are always on the first chain */
> > - chain = list_first_entry(&dev->chains, struct uvc_video_chain, list);
> > list_for_each_entry(unit, &dev->entities, list) {
> > - if (UVC_ENTITY_TYPE(unit) != UVC_EXT_GPIO_UNIT)
> > - continue;
> > - value = gpiod_get_value(unit->gpio.gpio_privacy);
> > - uvc_ctrl_status_event(NULL, chain, unit->controls, &value);
> > - return IRQ_HANDLED;
> > + if (UVC_ENTITY_TYPE(unit) == UVC_EXT_GPIO_UNIT)
> > + return unit;
> > }
> >
> > + return unit;
> > +}
> > +
> > +void uvc_privacy_gpio_event(struct uvc_device *dev)
> > +{
> > + struct uvc_entity *unit;
> > + struct uvc_video_chain *chain;
> > + u8 new_value;
> > +
> > + unit = uvc_find_ext_gpio_unit(dev);
> > + if (WARN_ONCE(!unit, "Unable to find entity ext_gpio_unit"))
> > + return;
> > +
> > + if (!uvc_gpio_update_value(unit, &new_value))
> > + return;
>
> If VIDIOC_G_CTRL() is called before the IRQ is processed, this
> uvc_gpio_update_value() call will return false, and no event will be
> generated. I don't think that's right, and even should be generated
> every time the control changes.
>
I was almost sure that get_cur had also the events wired but no.
> > +
> > + /* GPIO entities are always on the first chain */
> > + chain = list_first_entry(&dev->chains, struct uvc_video_chain, list);
> > + uvc_ctrl_status_event(NULL, chain, unit->controls, &new_value);
> > +}
> > +
> > +static irqreturn_t uvc_privacy_gpio_irq(int irq, void *data)
> > +{
> > + struct uvc_device *dev = data;
> > +
> > + /* Ignore privacy events during streamoff */
> > + if (dev->quirks & UVC_QUIRK_PRIVACY_DURING_STREAM)
> > + if (!uvc_ext_gpio_is_streaming(dev))
> > + return IRQ_HANDLED;
>
>
Re: [PATCH v4 2/5] soc: mediatek: pwrap: add arbiter capability
On Wed, Nov 18, 2020 at 8:08 PM Hsin-Hsiung Wang
wrote:
>
> Add arbiter capability for pwrap driver.
> The arbiter capability uses new design to judge the priority and latency
> for multi-channel.
> This patch is preparing for adding mt6873/8192 pwrap support.
>
> Signed-off-by: Hsin-Hsiung Wang
> ---
> drivers/soc/mediatek/mtk-pmic-wrap.c | 57
> ++--
> 1 file changed, 48 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/soc/mediatek/mtk-pmic-wrap.c
> b/drivers/soc/mediatek/mtk-pmic-wrap.c
> index c897205..5678f46 100644
> --- a/drivers/soc/mediatek/mtk-pmic-wrap.c
> +++ b/drivers/soc/mediatek/mtk-pmic-wrap.c
> @@ -25,10 +25,12 @@
>
> /* macro for wrapper status */
> #define PWRAP_GET_WACS_RDATA(x)(((x) >> 0) & 0x)
> +#define PWRAP_GET_WACS_ARB_FSM(x) (((x) >> 1) & 0x0007)
> #define PWRAP_GET_WACS_FSM(x) (((x) >> 16) & 0x0007)
> #define PWRAP_GET_WACS_REQ(x) (((x) >> 19) & 0x0001)
> #define PWRAP_STATE_SYNC_IDLE0 BIT(20)
> #define PWRAP_STATE_INIT_DONE0 BIT(21)
> +#define PWRAP_STATE_INIT_DONE1 BIT(15)
>
> /* macro for WACS FSM */
> #define PWRAP_WACS_FSM_IDLE0x00
> @@ -74,6 +76,7 @@
> #define PWRAP_CAP_DCM BIT(2)
> #define PWRAP_CAP_INT1_EN BIT(3)
> #define PWRAP_CAP_WDT_SRC1 BIT(4)
> +#define PWRAP_CAP_ARB BIT(5)
>
> /* defines for slave device wrapper registers */
> enum dew_regs {
> @@ -340,6 +343,8 @@ enum pwrap_regs {
> PWRAP_DCM_DBC_PRD,
> PWRAP_EINT_STA0_ADR,
> PWRAP_EINT_STA1_ADR,
> + PWRAP_SWINF_2_WDATA_31_0,
> + PWRAP_SWINF_2_RDATA_31_0,
>
> /* MT2701 only regs */
> PWRAP_ADC_CMD_ADDR,
> @@ -1108,14 +1113,22 @@ static void pwrap_writel(struct pmic_wrapper *wrp,
> u32 val, enum pwrap_regs reg)
>
> static bool pwrap_is_fsm_idle(struct pmic_wrapper *wrp)
> {
> - u32 val = pwrap_readl(wrp, PWRAP_WACS2_RDATA);
> + u32 val;
> +
> + val = pwrap_readl(wrp, PWRAP_WACS2_RDATA);
> + if (HAS_CAP(wrp->master->caps, PWRAP_CAP_ARB))
> + return PWRAP_GET_WACS_ARB_FSM(val) == PWRAP_WACS_FSM_IDLE;
>
> return PWRAP_GET_WACS_FSM(val) == PWRAP_WACS_FSM_IDLE;
> }
>
> static bool pwrap_is_fsm_vldclr(struct pmic_wrapper *wrp)
> {
> - u32 val = pwrap_readl(wrp, PWRAP_WACS2_RDATA);
> + u32 val;
> +
> + val = pwrap_readl(wrp, PWRAP_WACS2_RDATA);
> + if (HAS_CAP(wrp->master->caps, PWRAP_CAP_ARB))
> + return PWRAP_GET_WACS_ARB_FSM(val) == PWRAP_WACS_FSM_WFVLDCLR;
This code is now copied twice. Do you think it'd be better to create a
new function?
static u32 pwrap_get_fsm_state(struct pmic_wrapper *wrp) {
if (HAS_CAP(wrp->master->caps, PWRAP_CAP_ARB))
return PWRAP_GET_WACS_ARB_FSM(val);
else
return PWRAP_GET_WACS_FSM(val);
}
>
> return PWRAP_GET_WACS_FSM(val) == PWRAP_WACS_FSM_WFVLDCLR;
> }
> @@ -1165,6 +1178,7 @@ static int pwrap_wait_for_state(struct pmic_wrapper
> *wrp,
> static int pwrap_read16(struct pmic_wrapper *wrp, u32 adr, u32 *rdata)
> {
> int ret;
> + u32 val;
>
> ret = pwrap_wait_for_state(wrp, pwrap_is_fsm_idle);
> if (ret) {
> @@ -1172,13 +1186,21 @@ static int pwrap_read16(struct pmic_wrapper *wrp, u32
> adr, u32 *rdata)
> return ret;
> }
>
> - pwrap_writel(wrp, (adr >> 1) << 16, PWRAP_WACS2_CMD);
> + if (HAS_CAP(wrp->master->caps, PWRAP_CAP_ARB))
> + val = adr;
> + else
> + val = (adr >> 1) << 16;
> + pwrap_writel(wrp, val, PWRAP_WACS2_CMD);
>
> ret = pwrap_wait_for_state(wrp, pwrap_is_fsm_vldclr);
> if (ret)
> return ret;
>
> - *rdata = PWRAP_GET_WACS_RDATA(pwrap_readl(wrp, PWRAP_WACS2_RDATA));
> + if (HAS_CAP(wrp->master->caps, PWRAP_CAP_ARB))
> + val = pwrap_readl(wrp, PWRAP_SWINF_2_RDATA_31_0);
> + else
> + val = pwrap_readl(wrp, PWRAP_WACS2_RDATA);
> + *rdata = PWRAP_GET_WACS_RDATA(val);
>
> pwrap_writel(wrp, 1, PWRAP_WACS2_VLDCLR);
>
> @@ -1228,8 +1250,13 @@ static int pwrap_write16(struct pmic_wrapper *wrp, u32
> adr, u32 wdata)
> return ret;
> }
>
> - pwrap_writel(wrp, (1 << 31) | ((adr >> 1) << 16) | wdata,
> -PWRAP_WACS2_CMD);
> + if (HAS_CAP(wrp->master->caps, PWRAP_CAP_ARB)) {
> + pwrap_writel(wrp, wdata, PWRAP_SWINF_2_WDATA_31_0);
> + pwrap_writel(wrp, BIT(29) | adr, PWRAP_WACS2_CMD);
> + } else {
> + pwrap_writel(wrp, BIT(31) | ((adr >> 1) << 16) | wdata,
> +PWRAP_WACS2_CMD);
> + }
>
> return 0;
> }
> @@ -2022,6 +2049,7 @@ MODULE_DEVICE_TABLE(of, of_pwrap_match_tbl);
> static int pwrap_probe(struct platform_device *pdev)
> {
> int ret, irq;
> + u32 mask_done;
> struct pmic_wrapper *wr
Re: [PATCH v5 2/7] media: v4l2: Add extended buffer operations
On Thu, Dec 17, 2020 at 10:20 PM Helen Koike wrote:
>
> Hi Tomasz,
>
> Thanks for your comments, I have a few questions below.
>
> On 12/16/20 12:13 AM, Tomasz Figa wrote:
> > On Tue, Dec 15, 2020 at 11:37 PM Helen Koike
> > wrote:
> >>
> >> Hi Tomasz,
> >>
> >> On 12/14/20 7:46 AM, Tomasz Figa wrote:
> >>> On Fri, Dec 4, 2020 at 4:52 AM Helen Koike
> >>> wrote:
>
> Hi,
>
> Please see my 2 points below (about v4l2_ext_buffer and another about
> timestamp).
>
> On 12/3/20 12:11 PM, Hans Verkuil wrote:
> > On 23/11/2020 18:40, Helen Koike wrote:
> >>
> >>
> >> On 11/23/20 12:46 PM, Tomasz Figa wrote:
> >>> On Tue, Nov 24, 2020 at 12:08 AM Helen Koike
> >>> wrote:
>
> Hi Hans,
>
> Thank you for your review.
>
> On 9/9/20 9:27 AM, Hans Verkuil wrote:
> > Hi Helen,
> >
> > Again I'm just reviewing the uAPI.
> >
> > On 04/08/2020 21:29, Helen Koike wrote:
[snip]
> >
> >>
> >> Output: userspace fills plane information, informing in which memory
> >> buffer each
> >> plane was placed (Or should this be pre-determined by the driver?)
> >>
> >> For MMAP
> >> ---
> >> userspace performs EXT_CREATE_BUF ioctl to reserve a buffer "index" range
> >> in
> >> that mode, to be used in EXT_QBUF and EXT_DQBUF
> >>
> >> Should the API allow userspace to select how many memory buffers it wants?
> >> (maybe not)
> >
> > I think it does allow that - it accepts the v4l2_ext_format struct.
>
> hmmm, I thought v4l2_ext_format would describe color planes, and not memory
> planes.
> Should it describe memory planes instead? Since planes are defined by the
> pixelformat.
> But is this information relevant to ext_{set/get/try} format?
>
Good point. I ended up assuming the current convention, where giving
an M format would imply num_memory_planes == num_color_planes and
non-M format num_memory_planes == 1. Sounds like we might want
something like a flags field and that could have bits defined to
select that. I think it would actually be useful for S_FMT as well,
because that's what REQBUFS would use.
> >
> >>
> >> userspace performs EXT_QUERY_MMAP_BUF to get the mmap offset/cookie and
> >> length
> >> for each memory buffer.
> >>
> >> On EXT_QBUF, userspace doesn't need to fill membuf information. Should the
> >> mmap offset and length be filled by the kernel and returned to userspace
> >> here
> >> as well? I'm leaning towards: no.
> >
> > Yeah, based on my comment above, I think the answer should be no.
> >
> >>
> >> If the answer is no, then here is my proposal:
> >> --
> >>
> >> /* If MMAP, drivers decide how many memory buffers to allocate */
> >> int ioctl( int fd, VIDIOC_EXT_CREATE_BUFS, struct v4l2_ext_buffer *argp )
> >>
> >> /* Returns -EINVAL if not MMAP */
> >> int ioctl( int fd, VIDIOC_EXT_MMAP_QUERYBUF, struct v4l2_ext_mmap_querybuf
> >> *argp )
> >>
> >> /* userspace fills v4l2_ext_buffer.membufs if DMA-fd or Userptr, leave it
> >> zero for MMAP
> >> * Should userspace also fill v4l2_ext_buffer.planes?
> >> */
> >> int ioctl( int fd, VIDIOC_EXT_QBUF, struct v4l2_ext_buffer *argp )
> >>
> >> /* v4l2_ext_buffer.membufs is set to zero by the driver */
> >> int ioctl( int fd, VIDIOC_EXT_DBUF, struct v4l2_ext_buffer *argp )
> >>
> >> (I omitted reserved fields below)
> >>
> >> struct v4l2_ext_create_buffers {
> >> __u32 index;
> >> __u32 count;
> >> __u32 memory;
> >> __u32 capabilities;
> >> struct v4l2_ext_pix_format format;
> >> };
> >>
> >> struct v4l2_ext_mmap_membuf {
> >> __u32 offset;
> >> __u32 length;
> >> }
> >>
> >> struct v4l2_ext_mmap_querybuf {
> >> __u32 index;
> >> struct v4l2_ext_mmap_membuf membufs[VIDEO_MAX_PLANES];
> >> }
> >>
> >> struct v4l2_ext_membuf {
> >> __u32 memory;
> >> union {
> >> __u64 userptr;
> >> __s32 dmabuf_fd;
> >> } m;
> >> // Can't we just remove the union and "memory" field, and the
> >> non-zero
> >> // is the one we should use?
> >
> > I think that would lead to an equivalent result in this case. That
> > said, I'm not sure if there would be any significant enough benefit to
> > justify moving away from the current convention. Having the memory
> > field might also make the structure a bit less error prone, e.g.
> > resilient to missing memset().
> >
> >> };
> >>
> >> struct v4l2_ext_plane {
> >> __u32 membuf_index;
> >> __u32 offset;
> >> __u32 bytesused;
> >> };
> >>
> >> struct v4l2_ext_buffer {
> >> __u32 index;
> >> __u32 type;
> >> __u32 field;
> >> __u32 sequence;
> >> __u64 flags;
> >> __u64 timestamp;
> >>
[PATCH] KVM/SVM: Remove leftover __svm_vcpu_run prototype from svm.c
Commit 16809ecdc1e8a moved __svm_vcpu_run the prototype to svm.h,
but forgot to remove the original from svm.c.
Fixes: 16809ecdc1e8a ("KVM: SVM: Provide an updated VMRUN invocation for SEV-ES
guests")
Cc: Tom Lendacky
Cc: Paolo Bonzini
Signed-off-by: Uros Bizjak
---
arch/x86/kvm/svm/svm.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
index 941e5251e13f..2fa9726564af 100644
--- a/arch/x86/kvm/svm/svm.c
+++ b/arch/x86/kvm/svm/svm.c
@@ -3675,8 +3675,6 @@ static fastpath_t svm_exit_handlers_fastpath(struct
kvm_vcpu *vcpu)
return EXIT_FASTPATH_NONE;
}
-void __svm_vcpu_run(unsigned long vmcb_pa, unsigned long *regs);
-
static noinstr void svm_vcpu_enter_exit(struct kvm_vcpu *vcpu,
struct vcpu_svm *svm)
{
--
2.26.2
Re: [PATCH] dma/qcom/gpi: Fixes a format mismatch
On Fri 18 Dec 02:41 PST 2020, Xiaoming Ni wrote:
> drivers/dma/qcom/gpi.c:1419:3: warning: format '%lu' expects argument of
> type 'long unsigned int', but argument 8 has type 'size_t {aka unsigned
> int}' [-Wformat=]
> drivers/dma/qcom/gpi.c:1427:31: warning: format '%lu' expects argument of
> type 'long unsigned int', but argument 3 has type 'size_t {aka unsigned
> int}' [-Wformat=]
> drivers/dma/qcom/gpi.c:1447:3: warning: format '%llx' expects argument of
> type 'long long unsigned int', but argument 4 has type 'dma_addr_t {aka
> unsigned int}' [-Wformat=]
> drivers/dma/qcom/gpi.c:1447:3: warning: format '%llx' expects argument of
> type 'long long unsigned int', but argument 5 has type 'phys_addr_t {aka
> unsigned int}' [-Wformat=]
>
Reviewed-by: Bjorn Andersson
> Signed-off-by: Xiaoming Ni
> ---
> drivers/dma/qcom/gpi.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/dma/qcom/gpi.c b/drivers/dma/qcom/gpi.c
> index d2334f535de2..556c070a514c 100644
> --- a/drivers/dma/qcom/gpi.c
> +++ b/drivers/dma/qcom/gpi.c
> @@ -1416,7 +1416,7 @@ static int gpi_alloc_ring(struct gpi_ring *ring, u32
> elements,
> len = 1 << bit;
> ring->alloc_size = (len + (len - 1));
> dev_dbg(gpii->gpi_dev->dev,
> - "#el:%u el_size:%u len:%u actual_len:%llu alloc_size:%lu\n",
> + "#el:%u el_size:%u len:%u actual_len:%llu alloc_size:%zu\n",
> elements, el_size, (elements * el_size), len,
> ring->alloc_size);
>
> @@ -1424,7 +1424,7 @@ static int gpi_alloc_ring(struct gpi_ring *ring, u32
> elements,
> ring->alloc_size,
> &ring->dma_handle, GFP_KERNEL);
> if (!ring->pre_aligned) {
> - dev_err(gpii->gpi_dev->dev, "could not alloc size:%lu mem for
> ring\n",
> + dev_err(gpii->gpi_dev->dev, "could not alloc size:%zu mem for
> ring\n",
> ring->alloc_size);
> return -ENOMEM;
> }
> @@ -1444,8 +1444,8 @@ static int gpi_alloc_ring(struct gpi_ring *ring, u32
> elements,
> smp_wmb();
>
> dev_dbg(gpii->gpi_dev->dev,
> - "phy_pre:0x%0llx phy_alig:0x%0llx len:%u el_size:%u
> elements:%u\n",
> - ring->dma_handle, ring->phys_addr, ring->len,
> + "phy_pre:%pad phy_alig:%pa len:%u el_size:%u elements:%u\n",
> + &ring->dma_handle, &ring->phys_addr, ring->len,
> ring->el_size, ring->elements);
>
> return 0;
> --
> 2.27.0
>
Re: [v6,2/4] dt-binding: mediatek: mt8192: update mtk-wdt document
On Mon, Nov 16, 2020 at 8:27 PM Crystal Guo wrote: > > Hi Maintainers, > > Gentle pin for this patch. > > Thanks > > On Wed, 2020-10-14 at 21:19 +0800, Crystal Guo wrote: > > update mtk-wdt document for MT8192 platform Rob: I assume your input is required here? Any chance we could have your ack/review on this trivial patch? It seems like the series is blocked pending on a review of this patch -- and I don't think it has been reviewed before. Thanks, > > > > Signed-off-by: Crystal Guo > > --- > > Documentation/devicetree/bindings/watchdog/mtk-wdt.txt | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt > > b/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt > > index 45eedc2c3141..e36ba60de829 100644 > > --- a/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt > > +++ b/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt > > @@ -12,6 +12,7 @@ Required properties: > > "mediatek,mt7629-wdt", "mediatek,mt6589-wdt": for MT7629 > > "mediatek,mt8183-wdt": for MT8183 > > "mediatek,mt8516-wdt", "mediatek,mt6589-wdt": for MT8516 > > + "mediatek,mt8192-wdt": for MT8192 > > > > - reg : Specifies base physical address and size of the registers. > > > > ___ > Linux-mediatek mailing list > linux-media...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-mediatek
Re: [RFC PATCH v2 0/8] Adding the Sparx5 Switch Driver
On 12/16/2020 11:51 PM, Steen Hegelund wrote: > This series provides the Microchip Sparx5 Switch Driver > > The Sparx5 Carrier Ethernet and Industrial switch family delivers 64 > Ethernet ports and up to 200 Gbps of switching bandwidth. > > It provides a rich set of Ethernet switching features such as hierarchical > QoS, hardware-based OAM and service activation testing, protection > switching, IEEE 1588, and Synchronous Ethernet. > > Using provider bridging (Q-in-Q) and MPLS/MPLS-TP technology, it delivers > MEF CE > 2.0 Ethernet virtual connections (EVCs) and features advanced TCAM > classification in both ingress and egress. > > Per-EVC features include advanced L3-aware classification, a rich set of > statistics, OAM for end-to-end performance monitoring, and dual-rate > policing and shaping. > > Time sensitive networking (TSN) is supported through a comprehensive set of > features including frame preemption, cut-through, frame replication and > elimination for reliability, enhanced scheduling: credit-based shaping, > time-aware shaping, cyclic queuing, and forwarding, and per-stream policing > and filtering. > > Together with IEEE 1588 and IEEE 802.1AS support, this guarantees > low-latency deterministic networking for Fronthaul, Carrier, and Industrial > Ethernet. > > The Sparx5 switch family consists of following SKUs: > > - VSC7546 Sparx5-64 up to 64 Gbps of bandwidth with the following primary > port configurations: > - 6 *10G > - 16 * 2.5G + 2 * 10G > - 24 * 1G + 4 * 10G > > - VSC7549 Sparx5-90 up to 90 Gbps of bandwidth with the following primary > port configurations: > - 9 * 10G > - 16 * 2.5G + 4 * 10G > - 48 * 1G + 4 * 10G > > - VSC7552 Sparx5-128 up to 128 Gbps of bandwidth with the following primary > port configurations: > - 12 * 10G > - 16 * 2.5G + 8 * 10G > - 48 * 1G + 8 * 10G > > - VSC7556 Sparx5-160 up to 160 Gbps of bandwidth with the following primary > port configurations: > - 16 * 10G > - 10 * 10G + 2 * 25G > - 16 * 2.5G + 10 * 10G > - 48 * 1G + 10 * 10G > > - VSC7558 Sparx5-200 up to 200 Gbps of bandwidth with the following primary > port configurations: > - 20 * 10G > - 8 * 25G > > In addition, the device supports one 10/100/1000/2500/5000 Mbps > SGMII/SerDes node processor interface (NPI) Ethernet port. > > The Sparx5 support is developed on the PCB134 and PCB135 evaluation boards. > > - PCB134 main networking features: > - 12x SFP+ front 10G module slots (connected to Sparx5 through SFI). > - 8x SFP28 front 25G module slots (connected to Sparx5 through SFI high > speed). > - Optional, one additional 10/100/1000BASE-T (RJ45) Ethernet port > (on-board VSC8211 PHY connected to Sparx5 through SGMII). > > - PCB135 main networking features: > - 48x1G (10/100/1000M) RJ45 front ports using 12xVSC8514 QuadPHY’s each > connected to VSC7558 through QSGMII. > - 4x10G (1G/2.5G/5G/10G) RJ45 front ports using the AQR407 10G QuadPHY > each port connects to VSC7558 through SFI. > - 4x SFP28 25G module slots on back connected to VSC7558 through SFI high > speed. > - Optional, one additional 1G (10/100/1000M) RJ45 port using an on-board > VSC8211 PHY, which can be connected to VSC7558 NPI port through SGMII > using a loopback add-on PCB) > > This series provides support for: > - SFPs and DAC cables via PHYLINK with a number of 5G, 10G and 25G > devices and media types. > - Port module configuration for 10M to 25G speeds with SGMII, QSGMII, > 1000BASEX, 2500BASEX and 10GBASER as appropriate for these modes. > - SerDes configuration via the Sparx5 SerDes driver (see below). > - Host mode providing register based injection and extraction. > - Switch mode providing MAC/VLAN table learning and Layer2 switching > offloaded to the Sparx5 switch. > - STP state, VLAN support, host/bridge port mode, Forwarding DB, and > configuration and statistics via ethtool. > > More support will be added at a later stage. > > The Sparx5 Switch chip register model can be browsed here: > Link: https://microchip-ung.github.io/sparx-5_reginfo/reginfo_sparx-5.html Out of curiosity, what tool was used to generate the register information page? It looks really neat and well organized. -- Florian
Re: [PATCH v4 9/9] media: uvcvideo: Implement UVC_QUIRK_PRIVACY_DURING_STREAM
Hi Laurent
On Mon, Dec 21, 2020 at 3:08 AM Laurent Pinchart
wrote:
>
> Hi Ricardo,
>
> On Mon, Dec 21, 2020 at 02:10:18AM +0100, Ricardo Ribalda wrote:
> > On Sun, Dec 20, 2020 at 6:22 PM Laurent Pinchart wrote:
> > > On Tue, Dec 15, 2020 at 04:44:39PM +0100, Ricardo Ribalda wrote:
> > > > Some devices, can only read the privacy_pin if the device is
> > > > streaming.
> > >
> > > :-(
> >
> > :"-(
> >
> > > > This patch implement a quirk for such devices, in order to avoid invalid
> > > > reads and/or spurious events.
> > > >
> > > > Signed-off-by: Ricardo Ribalda
> > > > ---
> > > > drivers/media/usb/uvc/uvc_driver.c | 97 ++
> > > > drivers/media/usb/uvc/uvc_queue.c | 3 +
> > > > drivers/media/usb/uvc/uvcvideo.h | 6 ++
> > > > 3 files changed, 94 insertions(+), 12 deletions(-)
> > > >
> > > > diff --git a/drivers/media/usb/uvc/uvc_driver.c
> > > > b/drivers/media/usb/uvc/uvc_driver.c
> > > > index e49491250e87..61313019e226 100644
> > > > --- a/drivers/media/usb/uvc/uvc_driver.c
> > > > +++ b/drivers/media/usb/uvc/uvc_driver.c
> > > > @@ -7,6 +7,7 @@
> > > > */
> > > >
> > > > #include
> > > > +#include
> > > > #include
> > > > #include
> > > > #include
> > > > @@ -1471,13 +1472,39 @@ static int uvc_parse_control(struct uvc_device
> > > > *dev)
> > > > return 0;
> > > > }
> > > >
> > > > +static bool uvc_ext_gpio_is_streaming(struct uvc_device *dev)
> > > > +{
> > > > + struct uvc_streaming *streaming;
> > > > +
> > > > + list_for_each_entry(streaming, &dev->streams, list) {
> > > > + if (uvc_queue_streaming(&streaming->queue))
> > > > + return true;
> > > > + }
> > > > +
> > > > + return false;
> > > > +}
> > > > +
> > > > +/* Update the cached value and return true if it has changed */
> > > > +static bool uvc_gpio_update_value(struct uvc_entity *unit, u8 *new_val)
> > > > +{
> > > > + *new_val = gpiod_get_value(unit->gpio.gpio_privacy);
> > > > +
> > > > + return atomic_xchg(&unit->gpio.gpio_privacy_value, *new_val) !=
> > > > +
> > > > *new_val;
> > >
> > > That's a weird indentation. Also, as the left hand side modifies
> > > *new_val, does C guarantee the order in which the two operands to != are
> > > evaluated ? Could the code be written in an easier to read way ?
> > >
> > > > +}
> > > > +
> > > > static int uvc_gpio_get_cur(struct uvc_device *dev, struct uvc_entity
> > > > *entity,
> > > > u8 cs, void *data, u16 size)
> > > > {
> > > > if (cs != UVC_CT_PRIVACY_CONTROL || size < 1)
> > > > return -EINVAL;
> > > >
> > > > - *(uint8_t *)data = gpiod_get_value(entity->gpio.gpio_privacy);
> > > > + if ((dev->quirks & UVC_QUIRK_PRIVACY_DURING_STREAM) &&
> > > > + !uvc_ext_gpio_is_streaming(dev))
> > > > + return -EBUSY;
> > > > +
> > > > + uvc_gpio_update_value(entity, (uint8_t *)data);
> > > > +
> > > > return 0;
> > > > }
> > > >
> > > > @@ -1491,26 +1518,69 @@ static int uvc_gpio_get_info(struct uvc_device
> > > > *dev, struct uvc_entity *entity,
> > > > return 0;
> > > > }
> > > >
> > > > -static irqreturn_t uvc_privacy_gpio_irq(int irq, void *data)
> > > > +static struct uvc_entity *uvc_find_ext_gpio_unit(struct uvc_device
> > > > *dev)
> > > > {
> > > > - struct uvc_device *dev = data;
> > > > - struct uvc_video_chain *chain;
> > > > struct uvc_entity *unit;
> > > > - u8 value;
> > > >
> > > > - /* GPIO entities are always on the first chain */
> > > > - chain = list_first_entry(&dev->chains, struct uvc_video_chain,
> > > > list);
> > > > list_for_each_entry(unit, &dev->entities, list) {
> > > > - if (UVC_ENTITY_TYPE(unit) != UVC_EXT_GPIO_UNIT)
> > > > - continue;
> > > > - value = gpiod_get_value(unit->gpio.gpio_privacy);
> > > > - uvc_ctrl_status_event(NULL, chain, unit->controls,
> > > > &value);
> > > > - return IRQ_HANDLED;
> > > > + if (UVC_ENTITY_TYPE(unit) == UVC_EXT_GPIO_UNIT)
> > > > + return unit;
> > > > }
> > > >
> > > > + return unit;
> > > > +}
> > > > +
> > > > +void uvc_privacy_gpio_event(struct uvc_device *dev)
> > > > +{
> > > > + struct uvc_entity *unit;
> > > > + struct uvc_video_chain *chain;
> > > > + u8 new_value;
> > > > +
> > > > + unit = uvc_find_ext_gpio_unit(dev);
> > > > + if (WARN_ONCE(!unit, "Unable to find entity ext_gpio_unit"))
> > > > + return;
> > > > +
> > > > + if (!uvc_gpio_update_value(unit, &new_value))
> > > > + return;
> > >
> > > If VIDIOC_G_CTRL() is called before the IRQ is processed, this
> > > uvc_gpio_update_value() call will return false, and no event will be
> > > generated. I don't think that's right, and even should be generated
> > > every time the control changes.
> > >
> > I w
Re: [PATCH 2/3] arm64: dts: qcom: sm8150: Add PSCI idle states
On Sun 20 Dec 16:29 PST 2020, Danny Lin wrote:
> Like other Qualcomm SoCs, sm8150 exposes CPU and cluster idle states
> through PSCI. Define the idle states to save power when the CPU is not
> in active use.
>
> These idle states, latency, and residency values match the downstream
> 4.14 kernel from Qualcomm as of LA.UM.8.1.r1-15600-sm8150.0.
>
> It's worth noting that the CPU has an additional C3 power collapse idle
> state between WFI and rail power collapse (with PSCI mode 0x4003),
> but it is not officially used in downstream kernels due to "thermal
> throttling issues."
>
Thanks Danny for this series, very happy to see this kind of additions.
Just one small question about the cluster param below.
> Signed-off-by: Danny Lin
> ---
> arch/arm64/boot/dts/qcom/sm8150.dtsi | 50
> 1 file changed, 50 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sm8150.dtsi
> b/arch/arm64/boot/dts/qcom/sm8150.dtsi
> index 75ed38ee5d88..edc1fe6d7f1b 100644
> --- a/arch/arm64/boot/dts/qcom/sm8150.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sm8150.dtsi
> @@ -50,6 +50,8 @@ CPU0: cpu@0 {
> compatible = "qcom,kryo485";
> reg = <0x0 0x0>;
> enable-method = "psci";
> + cpu-idle-states = <&LITTLE_CPU_SLEEP_0
> +&CLUSTER_SLEEP_0>;
> next-level-cache = <&L2_0>;
> qcom,freq-domain = <&cpufreq_hw 0>;
> #cooling-cells = <2>;
> @@ -67,6 +69,8 @@ CPU1: cpu@100 {
> compatible = "qcom,kryo485";
> reg = <0x0 0x100>;
> enable-method = "psci";
> + cpu-idle-states = <&LITTLE_CPU_SLEEP_0
> +&CLUSTER_SLEEP_0>;
> next-level-cache = <&L2_100>;
> qcom,freq-domain = <&cpufreq_hw 0>;
> #cooling-cells = <2>;
> @@ -82,6 +86,8 @@ CPU2: cpu@200 {
> compatible = "qcom,kryo485";
> reg = <0x0 0x200>;
> enable-method = "psci";
> + cpu-idle-states = <&LITTLE_CPU_SLEEP_0
> +&CLUSTER_SLEEP_0>;
> next-level-cache = <&L2_200>;
> qcom,freq-domain = <&cpufreq_hw 0>;
> #cooling-cells = <2>;
> @@ -96,6 +102,8 @@ CPU3: cpu@300 {
> compatible = "qcom,kryo485";
> reg = <0x0 0x300>;
> enable-method = "psci";
> + cpu-idle-states = <&LITTLE_CPU_SLEEP_0
> +&CLUSTER_SLEEP_0>;
> next-level-cache = <&L2_300>;
> qcom,freq-domain = <&cpufreq_hw 0>;
> #cooling-cells = <2>;
> @@ -110,6 +118,8 @@ CPU4: cpu@400 {
> compatible = "qcom,kryo485";
> reg = <0x0 0x400>;
> enable-method = "psci";
> + cpu-idle-states = <&BIG_CPU_SLEEP_0
> +&CLUSTER_SLEEP_0>;
> next-level-cache = <&L2_400>;
> qcom,freq-domain = <&cpufreq_hw 1>;
> #cooling-cells = <2>;
> @@ -124,6 +134,8 @@ CPU5: cpu@500 {
> compatible = "qcom,kryo485";
> reg = <0x0 0x500>;
> enable-method = "psci";
> + cpu-idle-states = <&BIG_CPU_SLEEP_0
> +&CLUSTER_SLEEP_0>;
> next-level-cache = <&L2_500>;
> qcom,freq-domain = <&cpufreq_hw 1>;
> #cooling-cells = <2>;
> @@ -138,6 +150,8 @@ CPU6: cpu@600 {
> compatible = "qcom,kryo485";
> reg = <0x0 0x600>;
> enable-method = "psci";
> + cpu-idle-states = <&BIG_CPU_SLEEP_0
> +&CLUSTER_SLEEP_0>;
> next-level-cache = <&L2_600>;
> qcom,freq-domain = <&cpufreq_hw 1>;
> #cooling-cells = <2>;
> @@ -152,6 +166,8 @@ CPU7: cpu@700 {
> compatible = "qcom,kryo485";
> reg = <0x0 0x700>;
> enable-method = "psci";
> + cpu-idle-states = <&BIG_CPU_SLEEP_0
> +&CLUSTER_SLEEP_0>;
> next-level-cache = <&L2_700>;
> qcom,freq-domain = <&cpufreq_hw 2>;
> #cooling-cells = <2>;
> @@ -196,6 +212,40 @@ core7 {
> };
> };
> };
> +
> + idle-states {
> + entry-method = "psci";
>
Re: [PATCH] iio:light:apds9960 add detection for MSHW0184 ACPI device in apds9960 driver
On Sat, Dec 19, 2020 at 5:51 PM Max Leiter wrote:
>
> The device is used in the Microsoft Surface Book 3 and Surface Pro 7
>
> Signed-off-by: Max Leiter
Reviewed-by: Matt Ranostay
> ---
> drivers/iio/light/apds9960.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/iio/light/apds9960.c b/drivers/iio/light/apds9960.c
> index 9afb3fcc74e6..20719141c03a 100644
> --- a/drivers/iio/light/apds9960.c
> +++ b/drivers/iio/light/apds9960.c
> @@ -8,6 +8,7 @@
> * TODO: gesture + proximity calib offsets
> */
>
> +#include
> #include
> #include
> #include
> @@ -1113,6 +1114,12 @@ static const struct i2c_device_id apds9960_id[] = {
> };
> MODULE_DEVICE_TABLE(i2c, apds9960_id);
>
> +static const struct acpi_device_id apds9960_acpi_match[] = {
> + { "MSHW0184" },
> + { }
> +};
> +MODULE_DEVICE_TABLE(acpi, apds9960_acpi_match);
> +
> static const struct of_device_id apds9960_of_match[] = {
> { .compatible = "avago,apds9960" },
> { }
> @@ -1124,6 +1131,7 @@ static struct i2c_driver apds9960_driver = {
> .name = APDS9960_DRV_NAME,
> .of_match_table = apds9960_of_match,
> .pm = &apds9960_pm_ops,
> + .acpi_match_table = apds9960_acpi_match,
> },
> .probe = apds9960_probe,
> .remove = apds9960_remove,
> --
> 2.29.2
>
Re: [PATCH] genirq/msi: Initialize msi_alloc_info to zero for msi_prepare API
Hi Marc,
On 2020/12/19 1:38, Marc Zyngier wrote:
Hi Zenghui,
On Fri, 18 Dec 2020 06:00:39 +,
Zenghui Yu wrote:
Since commit 5fe71d271df8 ("irqchip/gic-v3-its: Tag ITS device as shared if
allocating for a proxy device"), some of the devices are wrongly marked as
"shared" by the ITS driver on systems equipped with the ITS(es). The
problem is that the @info->flags may not be initialized anywhere and we end
up looking at random bits on the stack. That's obviously not good.
The straightforward fix is to properly initialize msi_alloc_info inside the
.prepare callback of affected MSI domains (its-pci-msi, its-platform-msi,
etc). We can also perform the initialization in IRQ core layer for
msi_domain_prepare_irqs() API and it looks much neater to me.
Signed-off-by: Zenghui Yu
---
This was noticed when I was playing with the assigned devices on arm64 and
VFIO failed to enable MSI-X vectors for almost all VFs (CCed kvm list in
case others will hit the same issue). It turned out that these VFs are
marked as "shared" by mistake and have trouble with the following sequence:
pci_alloc_irq_vectors(pdev, 1, 1, flag);
pci_free_irq_vectors(pdev);
pci_alloc_irq_vectors(pdev, 1, 2, flag); --> we can only get
*one* vector
But besides VFIO, I guess there are already some devices get into trouble
at probe time and can't work properly.
kernel/irq/msi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/irq/msi.c b/kernel/irq/msi.c
index 2c0c4d6d0f83..dc0e2d7fbdfd 100644
--- a/kernel/irq/msi.c
+++ b/kernel/irq/msi.c
@@ -402,7 +402,7 @@ int __msi_domain_alloc_irqs(struct irq_domain *domain,
struct device *dev,
struct msi_domain_ops *ops = info->ops;
struct irq_data *irq_data;
struct msi_desc *desc;
- msi_alloc_info_t arg;
+ msi_alloc_info_t arg = { };
int i, ret, virq;
bool can_reserve;
Thanks for having investigated this. I guess my only worry with this
is that msi_alloc_info_t is a pretty large structure on x86, and
zeroing it isn't totally free.
It seems that x86 will zero the whole msi_alloc_info_t structure at the
beginning of its .prepare (pci_msi_prepare()/init_irq_alloc_info()). If
this really affects something, I think we can easily address it with
some cleanup (on top of this patch).
But this definitely looks nicer than
some of the alternatives (.prepare isn't a good option, as we do rely
on the flag being set in __platform_msi_create_device_domain(), which
calls itself .prepare).
Indeed, thanks for fixing the commit message.
I'll queue it, and we can always revisit this later if Thomas (or
anyone else) has a better idea.
Thanks!
Zenghui
Re: [PATCH v4 5/9] media: uvcvideo: Implement UVC_EXT_GPIO_UNIT
HI Laurent
Thanks for your review!
On Sun, Dec 20, 2020 at 5:49 PM Laurent Pinchart
wrote:
>
> Hi Ricardo,
>
> Thank you for the patch.
>
> On Tue, Dec 15, 2020 at 04:44:35PM +0100, Ricardo Ribalda wrote:
> > Some devices can implement a physical switch to disable the input of the
> > camera on demand. Think of it like an elegant privacy sticker.
> >
> > The system can read the status of the privacy switch via a GPIO.
> >
> > It is important to know the status of the switch, e.g. to notify the
> > user when the camera will produce black frames and a videochat
> > application is used.
> >
> > Since the uvc device is not aware of this pin (and it should't), we need
>
> s/should't/shouldn't/
>
> But I don't agree, if this is part of the camera, it should be
> implemented in the camera firmware. I understand that it's not possible
> (or desirable) with the hardware architecture you're dealing with
> though. How about
>
> "In some systems, the GPIO is connected to main SoC instead of the
> camera controller, with the connected reported by the system firmware
> (ACPI or DT). In that case, the UVC device isn't aware of the GPIO. We
> need to implement a virtual entity to handle the GPIO fully on the
> driver side.
>
> For example, for ACPI-based systems, the GPIO is reported in the USB
> device object:"
>
> > to implement a virtual entity that can interact with such pin.
> >
> > The location of the GPIO is specified via acpi or DT. on the usb device Eg:
> >
> > Scope (\_SB.PCI0.XHCI.RHUB.HS07)
> > {
> >
> > /.../
> >
> > Name (_CRS, ResourceTemplate () // _CRS: Current Resource Settings
> > {
> > GpioIo (Exclusive, PullDefault, 0x, 0x,
> > IoRestrictionOutputOnly,
> > "\\_SB.PCI0.GPIO", 0x00, ResourceConsumer, ,
> > )
> > { // Pin list
> > 0x0064
> > }
> > })
> > Name (_DSD, Package (0x02) // _DSD: Device-Specific Data
> > {
> > ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301") /* Device
> > Properties for _DSD */,
> > Package (0x01)
> > {
> > Package (0x02)
> > {
> > "privacy-gpio",
> > Package (0x04)
> > {
> > \_SB.PCI0.XHCI.RHUB.HS07,
> > Zero,
> > Zero,
> > One
> > }
> > }
> > }
> > })
> > }
> >
> > Signed-off-by: Ricardo Ribalda
> > ---
> > drivers/media/usb/uvc/uvc_ctrl.c | 6 ++
> > drivers/media/usb/uvc/uvc_driver.c | 106 +
> > drivers/media/usb/uvc/uvcvideo.h | 12
> > 3 files changed, 124 insertions(+)
> >
> > diff --git a/drivers/media/usb/uvc/uvc_ctrl.c
> > b/drivers/media/usb/uvc/uvc_ctrl.c
> > index 531816762892..53da1d984883 100644
> > --- a/drivers/media/usb/uvc/uvc_ctrl.c
> > +++ b/drivers/media/usb/uvc/uvc_ctrl.c
> > @@ -1302,6 +1302,9 @@ static void uvc_ctrl_status_event_work(struct
> > work_struct *work)
> >
> > mutex_unlock(&chain->ctrl_mutex);
> >
> > + if (!w->urb)
> > + return;
>
> A small comment to explain why would be useful.
>
> > +
> > /* Resubmit the URB. */
> > w->urb->interval = dev->int_ep->desc.bInterval;
> > ret = usb_submit_urb(w->urb, GFP_KERNEL);
> > @@ -2286,6 +2289,9 @@ int uvc_ctrl_init_device(struct uvc_device *dev)
> > } else if (UVC_ENTITY_TYPE(entity) == UVC_ITT_CAMERA) {
> > bmControls = entity->camera.bmControls;
> > bControlSize = entity->camera.bControlSize;
> > + } else if (UVC_ENTITY_TYPE(entity) == UVC_EXT_GPIO_UNIT) {
> > + bmControls = entity->gpio.bmControls;
> > + bControlSize = entity->gpio.bControlSize;
> > }
> >
> > /* Remove bogus/blacklisted controls */
> > diff --git a/drivers/media/usb/uvc/uvc_driver.c
> > b/drivers/media/usb/uvc/uvc_driver.c
> > index 534629ecd60d..498de09da07e 100644
> > --- a/drivers/media/usb/uvc/uvc_driver.c
> > +++ b/drivers/media/usb/uvc/uvc_driver.c
> > @@ -7,6 +7,7 @@
> > */
> >
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -1020,6 +1021,7 @@ static int uvc_parse_streaming(struct uvc_device *dev,
> > }
> >
> > static const u8 uvc_camera_guid[16] = UVC_GUID_UVC_CAMERA;
> > +static const u8 uvc_gpio_guid[16] = UVC_GUID_EXT_GPIO_CONTROLLER;
> > static const u8 uvc_media_transport_input_guid[16] =
> > UVC_GUID_UVC_MEDIA_TRANSPORT_INPUT;
> > static const u8 uvc_processing_guid[16] = UVC_GUID_UVC_PROCESSING;
> > @@ -1053,6 +1055,9 @@ static struct uvc_entity *uvc_alloc_entity(u16 type,
> > u16 id,
> >* is initialized by the caller.
> >*/
> > switch (type) {
> > + case UVC_EXT_GPIO_UNIT:
> > + memcpy(entity->guid, uvc_gpio_guid, 16);
> > + break;
> > case UVC_ITT_CAMERA:
> >
Re: [GIT PULL] CIFS/SMB3 Fixes
The pull request you sent on Sun, 20 Dec 2020 13:47:32 -0600: > git://git.samba.org/sfrench/cifs-2.6.git tags/5.11-rc-smb3-part2 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/582888130702b86daa44ff6bfee585e4d4050ba0 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [PATCH] mm/userfaultfd: fix memory corruption due to writeprotect
On Sun, Dec 20, 2020 at 07:33:09PM -0800, Nadav Amit wrote: > > On Dec 20, 2020, at 1:54 AM, Yu Zhao wrote: > > > > On Sun, Dec 20, 2020 at 12:06:38AM -0800, Nadav Amit wrote: > >>> On Dec 19, 2020, at 10:05 PM, Yu Zhao wrote: > >>> > >>> On Sat, Dec 19, 2020 at 01:34:29PM -0800, Nadav Amit wrote: > [ cc’ing some more people who have experience with similar problems ] > > > On Dec 19, 2020, at 11:15 AM, Andrea Arcangeli > > wrote: > > > > Hello, > > > > On Fri, Dec 18, 2020 at 08:30:06PM -0800, Nadav Amit wrote: > >> Analyzing this problem indicates that there is a real bug since > >> mmap_lock is only taken for read in mwriteprotect_range(). This might > > > > Never having to take the mmap_sem for writing, and in turn never > > blocking, in order to modify the pagetables is quite an important > > feature in uffd that justifies uffd instead of mprotect. It's not the > > most important reason to use uffd, but it'd be nice if that guarantee > > would remain also for the UFFDIO_WRITEPROTECT API, not only for the > > other pgtable manipulations. > > > >> Consider the following scenario with 3 CPUs (cpu2 is not shown): > >> > >> cpu0 cpu1 > >> > >> userfaultfd_writeprotect() > >> [ write-protecting ] > >> mwriteprotect_range() > >> mmap_read_lock() > >> change_protection() > >> change_protection_range() > >> ... > >> change_pte_range() > >> [ defer TLB flushes] > >>userfaultfd_writeprotect() > >> mmap_read_lock() > >> change_protection() > >> [ write-unprotect ] > >> ... > >> [ unprotect PTE logically ] > >>... > >>[ page-fault] > >>... > >>wp_page_copy() > >>[ set new writable page in PTE] > >>> > >>> I don't see any problem in this example -- wp_page_copy() calls > >>> ptep_clear_flush_notify(), which should take care of the stale entry > >>> left by cpu0. > >>> > >>> That being said, I suspect the memory corruption you observed is > >>> related this example, with cpu1 running something else that flushes > >>> conditionally depending on pte_write(). > >>> > >>> Do you know which type of pages were corrupted? file, anon, etc. > >> > >> First, Yu, you are correct. My analysis is incorrect, but let me have > >> another try (below). To answer your (and Andrea’s) question - this happens > >> with upstream without any changes, excluding a small fix to the selftest, > >> since it failed (got stuck) due to missing wake events. [1] > >> > >> We are talking about anon memory. > >> > >> So to correct myself, I think that what I really encountered was actually > >> during MM_CP_UFFD_WP_RESOLVE (i.e., when the protection is removed). The > >> problem was that in this case the “write”-bit was removed during unprotect. > > > > Thanks. You are right about when the problem happens: UFD write- > > UNprotecting. But it's not UFD write-UNprotecting that removes the > > writable bit -- the bit can only be removed during COW or UFD > > write-protecting. So your original example was almost correct, except > > the last line describing cpu1. > > The scenario is a bit confusing, so stay with me. The idea behind uffd > unprotect is indeed only to mark the PTE logically as uffd-unprotected, and > not to *set* the writable bit, allowing the #PF handler to do COW or > whatever correctly upon #PF. Right. > However, the problem that we have is that if a page is already writable, > write-unprotect *clears* the writable bit, making it write-protected (at > least for anonymous pages). This is not good from performance point-of-view, > but also a correctness issue, as I pointed out. > > In some more detail: mwriteprotect_range() uses vm_get_page_prot() to > compute the new protection. For anonymous private memory, at least on x86, > this means the write-bit in the protection is clear. So later, > change_pte_range() *clears* the write-bit during *unprotection*. Agreed. > That’s the reason the second part of my patch - the change to preserve_write > - fixes the problem. Yes, it fixes a part of the problem. But what if there is no writable bit there for you to preserve? If the bit was cleared by COW, e.g., KSM, fork, etc., no problem, because they guarantee the flush. If it was cleared by a priory UFD write-protecting, you still would run into the same problem because of the deterred flush. And you are trying to fix this part of the problem by grabbing mmap_write_lock. I think I understand your patch correctly. Both parts of the problem were intr
[PATCH v2 2/2] platform/chrome: cros_ec_sysfs: Add cold-ap-off to sysfs reboot.
Add cold-ap-off to ChromeOS EC sysfs reboot file option, corresponds to
the EC_REBOOT_COLD_AP_OFF flag, that will reset EC and keep AP off.
Signed-off-by: Pi-Hsun Shih
---
drivers/platform/chrome/cros_ec_sysfs.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/platform/chrome/cros_ec_sysfs.c
b/drivers/platform/chrome/cros_ec_sysfs.c
index f521a5c65091..8210fb10e839 100644
--- a/drivers/platform/chrome/cros_ec_sysfs.c
+++ b/drivers/platform/chrome/cros_ec_sysfs.c
@@ -28,7 +28,7 @@ static ssize_t reboot_show(struct device *dev,
int count = 0;
count += scnprintf(buf + count, PAGE_SIZE - count,
- "ro|rw|cancel|cold|disable-jump|hibernate");
+
"ro|rw|cancel|cold|disable-jump|hibernate|cold-ap-off");
count += scnprintf(buf + count, PAGE_SIZE - count,
" [at-shutdown]\n");
return count;
@@ -46,6 +46,7 @@ static ssize_t reboot_store(struct device *dev,
{"cancel", EC_REBOOT_CANCEL, 0},
{"ro", EC_REBOOT_JUMP_RO, 0},
{"rw", EC_REBOOT_JUMP_RW, 0},
+ {"cold-ap-off", EC_REBOOT_COLD_AP_OFF, 0},
{"cold", EC_REBOOT_COLD, 0},
{"disable-jump", EC_REBOOT_DISABLE_JUMP, 0},
{"hibernate",EC_REBOOT_HIBERNATE, 0},
--
2.29.2.684.gfbc64c5ab5-goog
Re: [PATCH v1] arm64: dts: qcom: sdm845-db845c: Fix reset-pin of ov8856 node
On Thu 17 Dec 07:12 PST 2020, Robert Foss wrote:
> Switch reset pin of ov8856 node from GPIO_ACTIVE_HIGH to GPIO_ACTIVE_LOW,
> this issue prevented the ov8856 from probing properly as it does not respond
> to I2C messages.
>
> Fixes: d4919a44564b ("arm64: dts: qcom: sdm845-db845c: Add ov8856 & ov7251
> camera nodes")
>
> Signed-off-by: Robert Foss
> ---
> arch/arm64/boot/dts/qcom/sdm845-db845c.dts | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/sdm845-db845c.dts
> b/arch/arm64/boot/dts/qcom/sdm845-db845c.dts
> index 7cc236575ee2..a943b3f353ce 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845-db845c.dts
> +++ b/arch/arm64/boot/dts/qcom/sdm845-db845c.dts
> @@ -1112,11 +1112,11 @@ camera@10 {
> reg = <0x10>;
>
> // CAM0_RST_N
> - reset-gpios = <&tlmm 9 0>;
> + reset-gpios = <&tlmm 9 1>;
Please do use GPIO_ACTIVE_LOW as the argument...
Regards,
Bjorn
> pinctrl-names = "default";
> pinctrl-0 = <&cam0_default>;
> gpios = <&tlmm 13 0>,
> - <&tlmm 9 0>;
> + <&tlmm 9 1>;
>
> clocks = <&clock_camcc CAM_CC_MCLK0_CLK>;
> clock-names = "xvclk";
> --
> 2.27.0
>
[PATCH v2] kernel: locking: delete repeated words in comments
Drop repeated words in kernel/locking/.
{it, no, the}
Signed-off-by: Randy Dunlap
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Will Deacon
---
v2: rebase, resend
kernel/locking/rtmutex.c |4 ++--
kernel/locking/rwsem.c |2 +-
kernel/locking/semaphore.c |2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
--- linux-next-20201218.orig/kernel/locking/rtmutex.c
+++ linux-next-20201218/kernel/locking/rtmutex.c
@@ -1438,7 +1438,7 @@ rt_mutex_fasttrylock(struct rt_mutex *lo
}
/*
- * Performs the wakeup of the the top-waiter and re-enables preemption.
+ * Performs the wakeup of the top-waiter and re-enables preemption.
*/
void rt_mutex_postunlock(struct wake_q_head *wake_q)
{
@@ -1833,7 +1833,7 @@ struct task_struct *rt_mutex_next_owner(
* been started.
* @waiter:the pre-initialized rt_mutex_waiter
*
- * Wait for the the lock acquisition started on our behalf by
+ * Wait for the lock acquisition started on our behalf by
* rt_mutex_start_proxy_lock(). Upon failure, the caller must call
* rt_mutex_cleanup_proxy_lock().
*
--- linux-next-20201218.orig/kernel/locking/rwsem.c
+++ linux-next-20201218/kernel/locking/rwsem.c
@@ -1048,7 +1048,7 @@ rwsem_down_write_slowpath(struct rw_sema
/*
* If there were already threads queued before us and:
-* 1) there are no no active locks, wake the front
+* 1) there are no active locks, wake the front
* queued process(es) as the handoff bit might be set.
* 2) there are no active writers and some readers, the lock
* must be read owned; so we try to wake any read lock
--- linux-next-20201218.orig/kernel/locking/semaphore.c
+++ linux-next-20201218/kernel/locking/semaphore.c
@@ -119,7 +119,7 @@ EXPORT_SYMBOL(down_killable);
* @sem: the semaphore to be acquired
*
* Try to acquire the semaphore atomically. Returns 0 if the semaphore has
- * been acquired successfully or 1 if it it cannot be acquired.
+ * been acquired successfully or 1 if it cannot be acquired.
*
* NOTE: This return value is inverted from both spin_trylock and
* mutex_trylock! Be careful about this when converting code.
Re: [PATCH v4 5/9] media: uvcvideo: Implement UVC_EXT_GPIO_UNIT
HI Laurent
On Mon, Dec 21, 2020 at 12:24 AM Laurent Pinchart
wrote:
>
> Hi Ricardo,
>
> On Sun, Dec 20, 2020 at 11:56:12PM +0100, Ricardo Ribalda wrote:
> > On Sun, Dec 20, 2020 at 5:49 PM Laurent Pinchart wrote:
> > > On Tue, Dec 15, 2020 at 04:44:35PM +0100, Ricardo Ribalda wrote:
> > > > Some devices can implement a physical switch to disable the input of the
> > > > camera on demand. Think of it like an elegant privacy sticker.
> > > >
> > > > The system can read the status of the privacy switch via a GPIO.
> > > >
> > > > It is important to know the status of the switch, e.g. to notify the
> > > > user when the camera will produce black frames and a videochat
> > > > application is used.
> > > >
> > > > Since the uvc device is not aware of this pin (and it should't), we need
> > >
> > > s/should't/shouldn't/
> > >
> > > But I don't agree, if this is part of the camera, it should be
> > > implemented in the camera firmware. I understand that it's not possible
> > > (or desirable) with the hardware architecture you're dealing with
> > > though. How about
> > >
> > > "In some systems, the GPIO is connected to main SoC instead of the
> > > camera controller, with the connected reported by the system firmware
> > > (ACPI or DT). In that case, the UVC device isn't aware of the GPIO. We
> > > need to implement a virtual entity to handle the GPIO fully on the
> > > driver side.
> > >
> > > For example, for ACPI-based systems, the GPIO is reported in the USB
> > > device object:"
> > >
> > > > to implement a virtual entity that can interact with such pin.
> > > >
> > > > The location of the GPIO is specified via acpi or DT. on the usb device
> > > > Eg:
> > > >
> > > > Scope (\_SB.PCI0.XHCI.RHUB.HS07)
> > > > {
> > > >
> > > > /.../
> > > >
> > > > Name (_CRS, ResourceTemplate () // _CRS: Current Resource Settings
> > > > {
> > > > GpioIo (Exclusive, PullDefault, 0x, 0x,
> > > > IoRestrictionOutputOnly,
> > > > "\\_SB.PCI0.GPIO", 0x00, ResourceConsumer, ,
> > > > )
> > > > { // Pin list
> > > > 0x0064
> > > > }
> > > > })
> > > > Name (_DSD, Package (0x02) // _DSD: Device-Specific Data
> > > > {
> > > > ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301") /* Device
> > > > Properties for _DSD */,
> > > > Package (0x01)
> > > > {
> > > > Package (0x02)
> > > > {
> > > > "privacy-gpio",
> > > > Package (0x04)
> > > > {
> > > > \_SB.PCI0.XHCI.RHUB.HS07,
> > > > Zero,
> > > > Zero,
> > > > One
> > > > }
> > > > }
> > > > }
> > > > })
> > > > }
> > > >
> > > > Signed-off-by: Ricardo Ribalda
> > > > ---
> > > > drivers/media/usb/uvc/uvc_ctrl.c | 6 ++
> > > > drivers/media/usb/uvc/uvc_driver.c | 106 +
> > > > drivers/media/usb/uvc/uvcvideo.h | 12
> > > > 3 files changed, 124 insertions(+)
> > > >
> > > > diff --git a/drivers/media/usb/uvc/uvc_ctrl.c
> > > > b/drivers/media/usb/uvc/uvc_ctrl.c
> > > > index 531816762892..53da1d984883 100644
> > > > --- a/drivers/media/usb/uvc/uvc_ctrl.c
> > > > +++ b/drivers/media/usb/uvc/uvc_ctrl.c
> > > > @@ -1302,6 +1302,9 @@ static void uvc_ctrl_status_event_work(struct
> > > > work_struct *work)
> > > >
> > > > mutex_unlock(&chain->ctrl_mutex);
> > > >
> > > > + if (!w->urb)
> > > > + return;
> > >
> > > A small comment to explain why would be useful.
> > >
> > > > +
> > > > /* Resubmit the URB. */
> > > > w->urb->interval = dev->int_ep->desc.bInterval;
> > > > ret = usb_submit_urb(w->urb, GFP_KERNEL);
> > > > @@ -2286,6 +2289,9 @@ int uvc_ctrl_init_device(struct uvc_device *dev)
> > > > } else if (UVC_ENTITY_TYPE(entity) == UVC_ITT_CAMERA) {
> > > > bmControls = entity->camera.bmControls;
> > > > bControlSize = entity->camera.bControlSize;
> > > > + } else if (UVC_ENTITY_TYPE(entity) == UVC_EXT_GPIO_UNIT) {
> > > > + bmControls = entity->gpio.bmControls;
> > > > + bControlSize = entity->gpio.bControlSize;
> > > > }
> > > >
> > > > /* Remove bogus/blacklisted controls */
> > > > diff --git a/drivers/media/usb/uvc/uvc_driver.c
> > > > b/drivers/media/usb/uvc/uvc_driver.c
> > > > index 534629ecd60d..498de09da07e 100644
> > > > --- a/drivers/media/usb/uvc/uvc_driver.c
> > > > +++ b/drivers/media/usb/uvc/uvc_driver.c
> > > > @@ -7,6 +7,7 @@
> > > > */
> > > >
> > > > #include
> > > > +#include
> > > > #include
> > > > #include
> > > > #include
> > > > @@ -1020,6 +1021,7 @@ static int uvc_parse_streaming(struct uvc_device
> > > > *dev,
> > > > }
> > > >
> > > > static const u8 uvc_camera_guid[16] = UVC_GUID_UVC_CAMERA;
> >
[PATCH v2] kernel: sched: delete repeated words in comments
Drop repeated words in kernel/sched/.
{in, not}
Signed-off-by: Randy Dunlap
Cc: Mathieu Desnoyers
Cc: "Paul E. McKenney"
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Juri Lelli
Cc: Vincent Guittot
---
v2: rebase, resend
kernel/sched/fair.c |2 +-
kernel/sched/membarrier.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--- linux-next-20201218.orig/kernel/sched/fair.c
+++ linux-next-20201218/kernel/sched/fair.c
@@ -5133,7 +5133,7 @@ static void do_sched_cfs_slack_timer(str
/*
* When a group wakes up we want to make sure that its quota is not already
* expired/exceeded, otherwise it may be allowed to steal additional ticks of
- * runtime as update_curr() throttling can not not trigger until it's on-rq.
+ * runtime as update_curr() throttling can not trigger until it's on-rq.
*/
static void check_enqueue_throttle(struct cfs_rq *cfs_rq)
{
--- linux-next-20201218.orig/kernel/sched/membarrier.c
+++ linux-next-20201218/kernel/sched/membarrier.c
@@ -454,7 +454,7 @@ static int sync_runqueues_membarrier_sta
/*
* For each cpu runqueue, if the task's mm match @mm, ensure that all
-* @mm's membarrier state set bits are also set in in the runqueue's
+* @mm's membarrier state set bits are also set in the runqueue's
* membarrier state. This ensures that a runqueue scheduling
* between threads which are users of @mm has its membarrier state
* updated.
[PATCH v2] kernel: events: delete repeated words in comments
Drop repeated words in kernel/events/.
{if, the, that, with, time}
Signed-off-by: Randy Dunlap
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Arnaldo Carvalho de Melo
---
v2: rebase, resend
kernel/events/core.c|8
kernel/events/uprobes.c |2 +-
2 files changed, 5 insertions(+), 5 deletions(-)
--- linux-next-20201218.orig/kernel/events/core.c
+++ linux-next-20201218/kernel/events/core.c
@@ -268,7 +268,7 @@ static void event_function_call(struct p
if (!event->parent) {
/*
* If this is a !child event, we must hold ctx::mutex to
-* stabilize the the event->ctx relation. See
+* stabilize the event->ctx relation. See
* perf_event_ctx_lock().
*/
lockdep_assert_held(&ctx->mutex);
@@ -1301,7 +1301,7 @@ static void put_ctx(struct perf_event_co
* life-time rules separate them. That is an exiting task cannot fork, and a
* spawning task cannot (yet) exit.
*
- * But remember that that these are parent<->child context relations, and
+ * But remember that these are parent<->child context relations, and
* migration does not affect children, therefore these two orderings should not
* interact.
*
@@ -1440,7 +1440,7 @@ static u64 primary_event_id(struct perf_
/*
* Get the perf_event_context for a task and lock it.
*
- * This has to cope with with the fact that until it is locked,
+ * This has to cope with the fact that until it is locked,
* the context could get moved to another task.
*/
static struct perf_event_context *
@@ -2499,7 +2499,7 @@ static void perf_set_shadow_time(struct
* But this is a bit hairy.
*
* So instead, we have an explicit cgroup call to remain
-* within the time time source all along. We believe it
+* within the time source all along. We believe it
* is cleaner and simpler to understand.
*/
if (is_cgroup_event(event))
--- linux-next-20201218.orig/kernel/events/uprobes.c
+++ linux-next-20201218/kernel/events/uprobes.c
@@ -1735,7 +1735,7 @@ void uprobe_free_utask(struct task_struc
}
/*
- * Allocate a uprobe_task object for the task if if necessary.
+ * Allocate a uprobe_task object for the task if necessary.
* Called when the thread hits a breakpoint.
*
* Returns:
[PATCH v2 1/2] platform/chrome: cros_ec: Add host command to keep AP off after EC reset.
Add command to EC_CMD_REBOOT_EC to reset EC but don't boot AP.
Signed-off-by: Pi-Hsun Shih
---
include/linux/platform_data/cros_ec_commands.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/platform_data/cros_ec_commands.h
b/include/linux/platform_data/cros_ec_commands.h
index a3a9a878415f..b80a4a7038e4 100644
--- a/include/linux/platform_data/cros_ec_commands.h
+++ b/include/linux/platform_data/cros_ec_commands.h
@@ -4729,6 +4729,7 @@ enum ec_reboot_cmd {
EC_REBOOT_DISABLE_JUMP = 5, /* Disable jump until next reboot */
EC_REBOOT_HIBERNATE = 6, /* Hibernate EC */
EC_REBOOT_HIBERNATE_CLEAR_AP_OFF = 7, /* and clears AP_OFF flag */
+ EC_REBOOT_COLD_AP_OFF = 8, /* Cold-reboot and don't boot AP */
};
/* Flags for ec_params_reboot_ec.reboot_flags */
base-commit: accefff5b547a9a1d959c7e76ad539bf2480e78b
--
2.29.2.684.gfbc64c5ab5-goog
Re: [PATCH] mm/userfaultfd: fix memory corruption due to writeprotect
> On Dec 19, 2020, at 6:20 PM, Andrea Arcangeli wrote:
>
> On Sat, Dec 19, 2020 at 02:06:02PM -0800, Nadav Amit wrote:
>>> On Dec 19, 2020, at 1:34 PM, Nadav Amit wrote:
>>>
>>> [ cc’ing some more people who have experience with similar problems ]
>>>
On Dec 19, 2020, at 11:15 AM, Andrea Arcangeli wrote:
Hello,
On Fri, Dec 18, 2020 at 08:30:06PM -0800, Nadav Amit wrote:
> Analyzing this problem indicates that there is a real bug since
> mmap_lock is only taken for read in mwriteprotect_range(). This might
Never having to take the mmap_sem for writing, and in turn never
blocking, in order to modify the pagetables is quite an important
feature in uffd that justifies uffd instead of mprotect. It's not the
most important reason to use uffd, but it'd be nice if that guarantee
would remain also for the UFFDIO_WRITEPROTECT API, not only for the
other pgtable manipulations.
> Consider the following scenario with 3 CPUs (cpu2 is not shown):
>
> cpu0 cpu1
>
> userfaultfd_writeprotect()
> [ write-protecting ]
> mwriteprotect_range()
> mmap_read_lock()
> change_protection()
> change_protection_range()
> ...
> change_pte_range()
> [ defer TLB flushes]
> userfaultfd_writeprotect()
>mmap_read_lock()
>change_protection()
>[ write-unprotect ]
>...
> [ unprotect PTE logically ]
>
> Is the uffd selftest failing with upstream or after your kernel
> modification that removes the tlb flush from unprotect?
Please see my reply to Yu. I was wrong in this analysis, and I sent a
correction to my analysis. The problem actually happens when
userfaultfd_writeprotect() unprotects the memory.
> } else if (uffd_wp_resolve) {
> /*
>* Leave the write bit to be handled
>* by PF interrupt handler, then
>* things like COW could be properly
>* handled.
>*/
> ptent = pte_clear_uffd_wp(ptent);
> }
>
> Upstraem this will still do pages++, there's a tlb flush before
> change_protection can return here, so I'm confused.
>
You are correct. The problem I encountered with userfaultfd_writeprotect()
is during unprotecting path.
Having said that, I think that there are additional scenarios that are
problematic. Consider for instance madvise_dontneed_free() that is racing
with userfaultfd_writeprotect(). If madvise_dontneed_free() completed
removing the PTEs, but still did not flush, change_pte_range() will see
non-present PTEs, say a flush is not needed, and then
change_protection_range() will not do a flush, and return while
the memory is still not protected.
> I don't share your concern. What matters is the PT lock, so it
> wouldn't be one per pte, but a least an order 9 higher, but let's
> assume one flush per pte.
>
> It's either huge mapping and then it's likely running without other
> tlb flushing in background (postcopy snapshotting), or it's a granular
> protect with distributed shared memory in which case the number of
> changd ptes or huge_pmds tends to be always 1 anyway. So it doesn't
> matter if it's deferred.
>
> I agree it may require a larger tlb flush review not just mprotect
> though, but it didn't sound particularly complex. Note the
> UFFDIO_WRITEPROTECT is still relatively recent so backports won't
> risk to reject so heavy as to require a band-aid.
>
> My second thought is, I don't see exactly the bug and it's not clear
> if it's upstream reproducing this, but assuming this happens on
> upstream, even ignoring everything else happening in the tlb flush
> code, this sounds like purely introduced by userfaultfd_writeprotect()
> vs userfaultfd_writeprotect() (since it's the only place changing
> protection with mmap_sem for reading and note we already unmap and
> flush tlb with mmap_sem for reading in MADV_DONTNEED/MADV_FREE clears
> the dirty bit etc..). Flushing tlbs with mmap_sem for reading is
> nothing new, the only new thing is the flush after wrprotect.
>
> So instead of altering any tlb flush code, would it be possible to
> just stick to mmap_lock for reading and then serialize
> userfaultfd_writeprotect() against itself with an additional
> mm->mmap_wprotect_lock mutex? That'd be a very local change to
> userfaultfd too.
>
> Can you look if the rule mmap_sem for reading plus a new
> mm->mmap_wprotect_lock mutex or the mmap_sem for writing, whenever
> wrprotecting ptes, is enough to comply with the current tlb flushing
> code, so not to require any change non local to u
Re: [RFC PATCH v2 1/8] dt-bindings: net: sparx5: Add sparx5-switch bindings
On 12/16/2020 11:51 PM, Steen Hegelund wrote: > Document the Sparx5 switch device driver bindings > > Signed-off-by: Steen Hegelund > Signed-off-by: Lars Povlsen > --- [snip] > + max-speed: > +maxItems: 1 > +description: Bandwidth allocated to this port > + > + phys: > +description: phandle of a Ethernet Serdes PHY > + > + phy-handle: > +description: phandle of a Ethernet PHY > + > + phy-mode: > +description: Interface between the serdes and the phy Can you specify this pertains to the Serdes and Ethernet PHY? -- Florian
Re: [PATCH v6 0/5] Introduce the Counter character device interface
On Sun, Dec 13, 2020 at 05:15:14PM -0600, David Lechner wrote:
> On 11/22/20 2:29 PM, William Breathitt Gray wrote:
> >
> > 1. Should standard Counter component data types be defined as u8 or u32?
> >
> > Many standard Counter component types such COUNTER_COMP_SIGNAL_LEVEL
> > have standard values defined (e.g. COUNTER_SIGNAL_LEVEL_LOW and
> > COUNTER_SIGNAL_LEVEL_HIGH). These values are currently handled by the
> > Counter subsystem code as u8 data types.
> >
> > If u32 is used for these values instead, C enum structures could be
> > used by driver authors to implicitly cast these values via the driver
> > callback parameters.
> >
> > This question is primarily addressed to David Lechner. I'm somewhat
> > confused about how this setup would look in device drivers. I've gone
> > ahead and refactored the code to support u32 enums, and pushed it to
> > a separate branch on my repository called counter_chrdev_v6_u32_enum:
> > https://gitlab.com/vilhelmgray/iio/-/tree/counter_chrdev_v6_u32_enum
> >
> > Please check it out and let me know what you think. Is this the
> > support you had in mind? I'm curious to see an example of how would
> > your driver callback functions would look in this case. If everything
> > works out fine, then I'll submit this branch as v7 of this patchset.
>
> I haven't had time to look at this in depth, but just superficially looking
> at it, it is mostly there. The driver callback would just use the enum type
> in place of u32. For example:
>
> static int ti_eqep_function_write(struct counter_device *counter,
> struct counter_count *count,
> enum counter_function function)
>
> and the COUNTER_FUNCTION_* constants would be defined as:
>
> enum counter_function {
> COUNTER_FUNCTION_INCREASE,
> ...
> };
>
> instead of using #define macros.
>
> One advantage I see to using u8, at least in the user API data structures,
> is that it increases the number of events that fit in the kfifo buffer by
> a significant factor.
>
> And that is not to say that we couldn't do both: have the user API structs
> use u8 for enum values and still use u32/strong enum types internally in
> the callback functions.
I'm including David Laight because he initially opposed enums in favor
of fixed size types when we discussed this in an earlier revision:
https://lkml.org/lkml/2020/5/3/159
However, there have been significant changes to this patchset so the
context now is different than those earlier discussions (i.e. we're no
longer discussing ioctl calls).
I think reimplementing these constants as enums as described could work.
If we do so, should the enum constants be given specific values? For
example:
enum counter_function {
COUNTER_FUNCTION_INCREASE = 0,
COUNTER_FUNCTION_DECREASE = 1,
...
};
>
> >
> > 2. How should we handle "raw" timestamps?
> >
> > Ahmad Fatoum brought up the possibility of returning "raw" timestamps
> > similar to what the network stack offers (see the network stack
> > SOF_TIMESTAMPING_{RAW,SYS}_HARDWARE support).
> >
> > I'm not very familiar with the networking stack code, but if I
> > understand correctly the SOF_TIMESTAMPING_RAW_HARDWARE timestamps are
> > values returned from the device. If so, I suspect we would be able to
> > support these "raw" timestamps by defining them as Counter Extensions
> > and returning them in struct counter_event elements similar to the
> > other Extension values.
>
> Is nanosecond resolution good enough? In the TI eQEP driver I considered
> returning the raw timer value, but quickly realized that it would not be
> very nice to expect the user code to know the clock rate of the timer. It
> was very easy to get the clock rate in the kernel and just convert the
> timer value to nanoseconds before returning it to userspace.
>
> So if there is some specialized case where it can be solved no other way
> besides using raw timestamps, then sure, include it. Otherwise I think we
> should stick with nanoseconds for time values when possible.
Given that the struct counter_event 'timestamp' member serves as the
identification vessel for correlating component values to a single event
(i.e. component values of a given event will share the same unique
timestamp), I believe it's prudent to standardize this timestamp format
on the kernel monotonic time as we have currently done so via our
ktime_get_ns() call.
There are cases where it is understandably better to use a timestamp
provided directly by the hardware (e.g. keeping timestamping close to
data collection). For these cases, we can retrieve these "raw"
timestamps via a Counter Extension: users would get their "raw"
timestamp via the struct counter_event 'value' member, and just treat
the 'timestamp' member as a unique event identification number.
William Breathitt Gray
signature.asc
Descripti
Re: [PATCH] mm/userfaultfd: fix memory corruption due to writeprotect
> On Dec 20, 2020, at 1:54 AM, Yu Zhao wrote: > > On Sun, Dec 20, 2020 at 12:06:38AM -0800, Nadav Amit wrote: >>> On Dec 19, 2020, at 10:05 PM, Yu Zhao wrote: >>> >>> On Sat, Dec 19, 2020 at 01:34:29PM -0800, Nadav Amit wrote: [ cc’ing some more people who have experience with similar problems ] > On Dec 19, 2020, at 11:15 AM, Andrea Arcangeli > wrote: > > Hello, > > On Fri, Dec 18, 2020 at 08:30:06PM -0800, Nadav Amit wrote: >> Analyzing this problem indicates that there is a real bug since >> mmap_lock is only taken for read in mwriteprotect_range(). This might > > Never having to take the mmap_sem for writing, and in turn never > blocking, in order to modify the pagetables is quite an important > feature in uffd that justifies uffd instead of mprotect. It's not the > most important reason to use uffd, but it'd be nice if that guarantee > would remain also for the UFFDIO_WRITEPROTECT API, not only for the > other pgtable manipulations. > >> Consider the following scenario with 3 CPUs (cpu2 is not shown): >> >> cpu0 cpu1 >> >> userfaultfd_writeprotect() >> [ write-protecting ] >> mwriteprotect_range() >> mmap_read_lock() >> change_protection() >> change_protection_range() >> ... >> change_pte_range() >> [ defer TLB flushes] >> userfaultfd_writeprotect() >> mmap_read_lock() >> change_protection() >> [ write-unprotect ] >> ... >>[ unprotect PTE logically ] >> ... >> [ page-fault] >> ... >> wp_page_copy() >> [ set new writable page in PTE] >>> >>> I don't see any problem in this example -- wp_page_copy() calls >>> ptep_clear_flush_notify(), which should take care of the stale entry >>> left by cpu0. >>> >>> That being said, I suspect the memory corruption you observed is >>> related this example, with cpu1 running something else that flushes >>> conditionally depending on pte_write(). >>> >>> Do you know which type of pages were corrupted? file, anon, etc. >> >> First, Yu, you are correct. My analysis is incorrect, but let me have >> another try (below). To answer your (and Andrea’s) question - this happens >> with upstream without any changes, excluding a small fix to the selftest, >> since it failed (got stuck) due to missing wake events. [1] >> >> We are talking about anon memory. >> >> So to correct myself, I think that what I really encountered was actually >> during MM_CP_UFFD_WP_RESOLVE (i.e., when the protection is removed). The >> problem was that in this case the “write”-bit was removed during unprotect. > > Thanks. You are right about when the problem happens: UFD write- > UNprotecting. But it's not UFD write-UNprotecting that removes the > writable bit -- the bit can only be removed during COW or UFD > write-protecting. So your original example was almost correct, except > the last line describing cpu1. The scenario is a bit confusing, so stay with me. The idea behind uffd unprotect is indeed only to mark the PTE logically as uffd-unprotected, and not to *set* the writable bit, allowing the #PF handler to do COW or whatever correctly upon #PF. However, the problem that we have is that if a page is already writable, write-unprotect *clears* the writable bit, making it write-protected (at least for anonymous pages). This is not good from performance point-of-view, but also a correctness issue, as I pointed out. In some more detail: mwriteprotect_range() uses vm_get_page_prot() to compute the new protection. For anonymous private memory, at least on x86, this means the write-bit in the protection is clear. So later, change_pte_range() *clears* the write-bit during *unprotection*. That’s the reason the second part of my patch - the change to preserve_write - fixes the problem. > The problem is how do_wp_page() handles non-COW pages. (For COW pages, > do_wp_page() works correctly by either reusing an existing page or > make a new copy out of it.) In UFD case, the existing page may not > have been properly write-protected. As you pointed out, the tlb flush > may not be done yet. Making a copy can potentially race with the > writer on cpu2. Just to clarify the difference - You regard a scenario of UFFD write-protect, while I am pretty sure the problem I encountered is during write-unprotect. I am not sure we are on the same page (but we may be). The problem I have is with cow_user_page() that is called by do_wp_page() before any TLB flush took place (either by change_protection_range() or by do_wp_page() which does flush, but after the copy). Let me know if you regard
[GIT PULL] CIFS/SMB3 Fixes
Please pull the following changes since commit
e13300bdaa68f5487000e66baed1ff69bcb510bf:
Merge tag '5.11-rc-smb3' of git://git.samba.org/sfrench/cifs-2.6
(2020-12-17 17:41:37 -0800)
are available in the Git repository at:
git://git.samba.org/sfrench/cifs-2.6.git tags/5.11-rc-smb3-part2
for you to fetch changes up to 9541b81322e60120b299222919957becd7a13683:
Add SMB 2 support for getting and setting SACLs (2020-12-18 23:32:04 -0600)
Four small CIFS/SMB3 fixes (witness protocol and reconnect related),
and two that add ability to get and set auditing information in the
security descriptor (SACL), which can be helpful not just for backup
scenarios ("smbinfo secdesc" etc.) but also for improving security.
Testing results:
http://smb3-test-rhel-75.southcentralus.cloudapp.azure.com/#/builders/2/builds/466
Boris Protopopov (2):
SMB3: Add support for getting and setting SACLs
Add SMB 2 support for getting and setting SACLs
Dan Carpenter (3):
cifs: Delete a stray unlock in cifs_swn_reconnect()
cifs: Unlock on errors in cifs_swn_reconnect()
cifs: Re-indent cifs_swn_reconnect()
Samuel Cabrero (1):
cifs: Avoid error pointer dereference
fs/cifs/cifs_swn.c | 73 +++
fs/cifs/cifsacl.c | 15 ++
fs/cifs/cifsglob.h | 4 +--
fs/cifs/cifspdu.h | 2 ++
fs/cifs/cifsproto.h | 4 +--
fs/cifs/connect.c | 1 +
fs/cifs/smb2ops.c | 35 ++-
fs/cifs/smb2pdu.c | 7 +++--
fs/cifs/smb2proto.h | 4 +--
fs/cifs/xattr.c | 81 +++--
10 files changed, 140 insertions(+), 86 deletions(-)
--
Thanks,
Steve
[PATCH] mm: zswap: clean up confusing comment
Correct wording and change one duplicated word (it) to "it is".
Fixes: 0ab0abcf5115 ("mm/zswap: refactor the get/put routines")
Signed-off-by: Randy Dunlap
Cc: Weijie Yang
Cc: Seth Jennings
Cc: Seth Jennings
Cc: Andrew Morton
Cc: Dan Streetman
Cc: Vitaly Wool
Cc: linux...@kvack.org
---
mm/zswap.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- linux-next-20201218.orig/mm/zswap.c
+++ linux-next-20201218/mm/zswap.c
@@ -1022,10 +1022,10 @@ static int zswap_writeback_entry(struct
/*
* if we get here due to ZSWAP_SWAPCACHE_EXIST
- * a load may happening concurrently
- * it is safe and okay to not free the entry
+ * a load may be happening concurrently.
+ * it is safe and okay to not free the entry.
* if we free the entry in the following put
- * it it either okay to return !0
+ * it is also okay to return !0
*/
fail:
spin_lock(&tree->lock);
Re: [PATCH v4 4/5] soc: mediatek: pwrap: add pwrap driver for MT6873/8192 SoCs
On Wed, Nov 18, 2020 at 8:08 PM Hsin-Hsiung Wang
wrote:
>
> MT6873/8192 are highly integrated SoCs and use PMIC_MT6359 for
> power management. This patch adds pwrap master driver to
> access PMIC_MT6359.
>
> Signed-off-by: Hsin-Hsiung Wang
> ---
> drivers/soc/mediatek/mtk-pmic-wrap.c | 29 +
> 1 file changed, 29 insertions(+)
>
> diff --git a/drivers/soc/mediatek/mtk-pmic-wrap.c
> b/drivers/soc/mediatek/mtk-pmic-wrap.c
> index 5678f46..d1cd050 100644
> --- a/drivers/soc/mediatek/mtk-pmic-wrap.c
> +++ b/drivers/soc/mediatek/mtk-pmic-wrap.c
> @@ -632,6 +632,17 @@ static int mt6797_regs[] = {
> [PWRAP_DCM_DBC_PRD] = 0x1D4,
> };
>
> +static int mt6873_regs[] = {
> + [PWRAP_INIT_DONE2] =0x0,
I don't have the datasheet for the PWRAP interface, is this register
at offset 0x0 real?
If so, I'm concerned that mt6873_regs only defines very few registers
offsets, so the init code will do a _lot_ writes at register address
0x0 (e.g. for all the undefined values in this array: PWRAP_WACS0_EN,
PWRAP_WACS1_EN, PWRAP_WACS2_EN, etc, etc.)
> + [PWRAP_TIMER_EN] = 0x3E0,
> + [PWRAP_INT_EN] =0x448,
> + [PWRAP_WACS2_CMD] = 0xC80,
> + [PWRAP_SWINF_2_WDATA_31_0] =0xC84,
> + [PWRAP_SWINF_2_RDATA_31_0] =0xC94,
> + [PWRAP_WACS2_VLDCLR] = 0xCA4,
> + [PWRAP_WACS2_RDATA] = 0xCA8,
> +};
> +
> static int mt7622_regs[] = {
> [PWRAP_MUX_SEL] = 0x0,
> [PWRAP_WRAP_EN] = 0x4,
> @@ -1050,6 +1061,7 @@ enum pwrap_type {
> PWRAP_MT6765,
> PWRAP_MT6779,
> PWRAP_MT6797,
> + PWRAP_MT6873,
> PWRAP_MT7622,
> PWRAP_MT8135,
> PWRAP_MT8173,
> @@ -1512,6 +1524,7 @@ static int pwrap_init_cipher(struct pmic_wrapper *wrp)
> case PWRAP_MT7622:
> pwrap_writel(wrp, 0, PWRAP_CIPHER_EN);
> break;
> + case PWRAP_MT6873:
> case PWRAP_MT8183:
> break;
> }
> @@ -1948,6 +1961,19 @@ static const struct pmic_wrapper_type pwrap_mt6797 = {
> .init_soc_specific = NULL,
> };
>
> +static const struct pmic_wrapper_type pwrap_mt6873 = {
> + .regs = mt6873_regs,
> + .type = PWRAP_MT6873,
> + .arb_en_all = 0x777f,
> + .int_en_all = BIT(4) | BIT(5),
> + .int1_en_all = 0,
> + .spi_w = PWRAP_MAN_CMD_SPI_WRITE,
> + .wdt_src = PWRAP_WDT_SRC_MASK_ALL,
> + .caps = PWRAP_CAP_ARB,
> + .init_reg_clock = pwrap_common_init_reg_clock,
> + .init_soc_specific = NULL,
> +};
> +
> static const struct pmic_wrapper_type pwrap_mt7622 = {
> .regs = mt7622_regs,
> .type = PWRAP_MT7622,
> @@ -2026,6 +2052,9 @@ static const struct of_device_id of_pwrap_match_tbl[] =
> {
> .compatible = "mediatek,mt6797-pwrap",
> .data = &pwrap_mt6797,
> }, {
> + .compatible = "mediatek,mt6873-pwrap",
> + .data = &pwrap_mt6873,
> + }, {
> .compatible = "mediatek,mt7622-pwrap",
> .data = &pwrap_mt7622,
> }, {
> --
> 2.6.4
> ___
> Linux-mediatek mailing list
> linux-media...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
