Re: [PATCH 5.10 24/40] f2fs: fix to seek incorrect data offset in inline data file
On Thu, Dec 24, 2020 at 09:11:53AM +0800, Chao Yu wrote: > Hi Greg, > > Thanks a lot for helping to resend and merge the patch. :) Not a problem, glad to help out. In the future, all you need to do is give us the git commit id that needs to be backported if it applies cleanly, no need to send the whole patch! thanks, greg k-h
Re: [PATCH v1] scsi: ufs-mediatek: Enable UFSHCI_QUIRK_SKIP_MANUAL_WB_FLUSH_CTRL
Hi Can, On Thu, 2020-12-24 at 10:21 +0800, Can Guo wrote: > On 2020-12-23 12:41, Can Guo wrote: > > On 2020-12-23 12:19, Stanley Chu wrote: > >> Hi Can, > >> > >> On Tue, 2020-12-22 at 19:34 +0800, Can Guo wrote: > >>> On 2020-12-22 15:29, Stanley Chu wrote: > >>> > Flush during hibern8 is sufficient on MediaTek platforms, thus > >>> > enable UFSHCI_QUIRK_SKIP_MANUAL_WB_FLUSH_CTRL to skip enabling > >>> > fWriteBoosterBufferFlush during WriteBooster initialization. > >>> > > >>> > Signed-off-by: Stanley Chu > >>> > --- > >>> > drivers/scsi/ufs/ufs-mediatek.c | 1 + > >>> > 1 file changed, 1 insertion(+) > >>> > > >>> > diff --git a/drivers/scsi/ufs/ufs-mediatek.c > >>> > b/drivers/scsi/ufs/ufs-mediatek.c > >>> > index 80618af7c872..c55202b92a43 100644 > >>> > --- a/drivers/scsi/ufs/ufs-mediatek.c > >>> > +++ b/drivers/scsi/ufs/ufs-mediatek.c > >>> > @@ -661,6 +661,7 @@ static int ufs_mtk_init(struct ufs_hba *hba) > >>> > > >>> > /* Enable WriteBooster */ > >>> > hba->caps |= UFSHCD_CAP_WB_EN; > >>> > + hba->quirks |= UFSHCI_QUIRK_SKIP_MANUAL_WB_FLUSH_CTRL; > >>> > hba->vps->wb_flush_threshold = UFS_WB_BUF_REMAIN_PERCENT(80); > >>> > > >>> > if (host->caps & UFS_MTK_CAP_DISABLE_AH8) > >>> > >>> I guess we need it too... > >> > >> AHHA, if you decide to add this in your platform too later, maybe we > >> could change the way it does: Keep manual flush disabled by default > >> and > >> remove this quirk. > >> > > > > Yeah... I will get back with an answer later. > > Hi Stanley, > > Do you see any substantial benefit of having fWriteBoosterBufferFlushEn > disabled? 1. The definition of fWriteBoosterBufferFlushEn is that host allows device to do flush in anytime after fWriteBoosterBufferFlushEn is set as on. This is not what we want. Just Like BKOP, We do not want flush happening beyond host's expected timing that device performance may be "randomly" dropped. 2. Another related concern is that currently fWriteBoosterBufferFlushEn may keep on while device is not in Active Power Mode during suspend period. I am not sure if such configuration would confuse the device. Thanks, Stanley Chu > > Thanks, > Can Guo. > > > > > Thanks, > > > > Can Guo. > > > >> Thanks, > >> Stanley Chu > >>> > >>> Change LGTM. > >>> > >>> Regards, > >>> > >>> Can Guo.
[PATCH v3 2/2] power: supply: mt6360_charger: add MT6360 charger support
From: Gene Chen Add basic support for the battery charger for MT6360 PMIC Signed-off-by: Gene Chen --- drivers/power/supply/Kconfig | 10 + drivers/power/supply/Makefile |1 + drivers/power/supply/mt6360_charger.c | 1054 + 3 files changed, 1065 insertions(+) create mode 100644 drivers/power/supply/mt6360_charger.c diff --git a/drivers/power/supply/Kconfig b/drivers/power/supply/Kconfig index eec646c..dd63bed 100644 --- a/drivers/power/supply/Kconfig +++ b/drivers/power/supply/Kconfig @@ -567,6 +567,16 @@ config CHARGER_MP2629 Battery charger. This driver provides Battery charger power management functions on the systems. +config CHARGER_MT6360 + tristate "Mediatek MT6360 Charger Driver" + depends on MFD_MT6360 + depends on REGULATOR + help + Say Y here to enable MT6360 Charger Part. + The device supports High-Accuracy Voltage/Current Regulation, + Average Input Current Regulation, Battery Tempature Sensing, + Over-Temperature Protection, DPDM Detection for BC1.2 + config CHARGER_QCOM_SMBB tristate "Qualcomm Switch-Mode Battery Charger and Boost" depends on MFD_SPMI_PMIC || COMPILE_TEST diff --git a/drivers/power/supply/Makefile b/drivers/power/supply/Makefile index dd4b863..9bd0804 100644 --- a/drivers/power/supply/Makefile +++ b/drivers/power/supply/Makefile @@ -77,6 +77,7 @@ obj-$(CONFIG_CHARGER_MAX77693)+= max77693_charger.o obj-$(CONFIG_CHARGER_MAX8997) += max8997_charger.o obj-$(CONFIG_CHARGER_MAX8998) += max8998_charger.o obj-$(CONFIG_CHARGER_MP2629) += mp2629_charger.o +obj-$(CONFIG_CHARGER_MT6360) += mt6360_charger.o obj-$(CONFIG_CHARGER_QCOM_SMBB)+= qcom_smbb.o obj-$(CONFIG_CHARGER_BQ2415X) += bq2415x_charger.o obj-$(CONFIG_CHARGER_BQ24190) += bq24190_charger.o diff --git a/drivers/power/supply/mt6360_charger.c b/drivers/power/supply/mt6360_charger.c new file mode 100644 index 000..f1dcb97 --- /dev/null +++ b/drivers/power/supply/mt6360_charger.c @@ -0,0 +1,1054 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (c) 2019 MediaTek Inc. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define MT6360_PMU_CHG_CTRL1 0x311 +#define MT6360_PMU_CHG_CTRL2 0x312 +#define MT6360_PMU_CHG_CTRL3 0x313 +#define MT6360_PMU_CHG_CTRL4 0x314 +#define MT6360_PMU_CHG_CTRL5 0x315 +#define MT6360_PMU_CHG_CTRL6 0x316 +#define MT6360_PMU_CHG_CTRL7 0x317 +#define MT6360_PMU_CHG_CTRL8 0x318 +#define MT6360_PMU_CHG_CTRL9 0x319 +#define MT6360_PMU_CHG_CTRL10 0x31A +#define MT6360_PMU_CHG_CTRL11 0x31B +#define MT6360_PMU_CHG_CTRL12 0x31C +#define MT6360_PMU_CHG_CTRL13 0x31D +#define MT6360_PMU_DEVICE_TYPE 0x322 +#define MT6360_PMU_USB_STATUS1 0x327 +#define MT6360_PMU_CHG_CTRL17 0x32B +#define MT6360_PMU_CHG_CTRL18 0x32C +#define MT6360_PMU_CHG_STAT0x34A +#define MT6360_PMU_CHG_CTRL19 0x361 +#define MT6360_PMU_FOD_STAT0x3E7 + +/* MT6360_PMU_CHG_CTRL1 */ +#define MT6360_FSLP_SHFT (3) +#define MT6360_FSLP_MASK BIT(MT6360_FSLP_SHFT) +#define MT6360_HIZ_SHFT(2) +#define MT6360_HIZ_MASKBIT(MT6360_HIZ_SHFT) +#define MT6360_OPA_MODE_SHFT (0) +#define MT6360_OPA_MODE_MASK BIT(MT6360_OPA_MODE_SHFT) +/* MT6360_PMU_CHG_CTRL2 */ +#define MT6360_TE_SHFT (4) +#define MT6360_TE_MASK BIT(MT6360_TE_SHFT) +#define MT6360_IINLMTSEL_SHFT (2) +#define MT6360_IINLMTSEL_MASK GENMASK(3, 2) +#define MT6360_CHG_EN_SHFT (0) +#define MT6360_CHG_EN_MASK BIT(MT6360_CHG_EN_SHFT) +/* MT6360_PMU_CHG_CTRL3 */ +#define MT6360_IAICR_SHFT (2) +#define MT6360_IAICR_MASK GENMASK(7, 2) +#define MT6360_ILIM_EN_MASKBIT(0) +/* MT6360_PMU_CHG_CTRL4 */ +#define MT6360_VOREG_SHFT (1) +#define MT6360_VOREG_MASK GENMASK(7, 1) +/* MT6360_PMU_CHG_CTRL5 */ +#define MT6360_VOBST_MASK GENMASK(7, 2) +/* MT6360_PMU_CHG_CTRL6 */ +#define MT6360_VMIVR_SHFT (1) +#define MT6360_VMIVR_MASK GENMASK(7, 1) +/* MT6360_PMU_CHG_CTRL7 */ +#define MT6360_ICHG_SHFT (2) +#define MT6360_ICHG_MASK GENMASK(7, 2) +/* MT6360_PMU_CHG_CTRL8 */ +#define MT6360_IPREC_SHFT (0) +#define MT6360_IPREC_MASK GENMASK(3, 0) +/* MT6360_PMU_CHG_CTRL9 */ +#define MT6360_IEOC_SHFT (4) +#define MT6360_IEOC_MASK GENMASK(7, 4) +/* MT6360_PMU_CHG_CTRL10 */ +#define MT6360_LBP_SHFT(4) +#define MT6360_LBP_MASKGENMASK(7, 4) +#define MT6360_OTG_OC_SHFT (0) +#define MT6360_OTG_OC_MASK GENMASK(3, 0) +/* MT6360_PMU_CHG_CTRL11 */ +#define MT6360_SYSREG_SHFT (2) +#define MT6360_SYSREG_MASK GENMASK(4, 2) +#define MT6360_VREC_SHFT (0) +#define MT6360_VREC_MASK GENMASK(2, 0) +/* MT6360_PMU_CHG_CTRL12 */ +#define MT6360_WT_FC_SHFT (5) +#define MT6360_WT_FC_MASK GENMASK(7, 5) +/* MT6360_PMU_CHG_CTRL13 */ +#define
[PATCH v3 1/2] dt-bindings: power: Add bindings document for Charger support on MT6360 PMIC
From: Gene Chen
Add bindings document for Charger support on MT6360 PMIC
Signed-off-by: Gene Chen
Reviewed-by: Rob Herring
---
.../bindings/power/supply/mt6360_charger.yaml | 48 ++
1 file changed, 48 insertions(+)
create mode 100644
Documentation/devicetree/bindings/power/supply/mt6360_charger.yaml
diff --git a/Documentation/devicetree/bindings/power/supply/mt6360_charger.yaml
b/Documentation/devicetree/bindings/power/supply/mt6360_charger.yaml
new file mode 100644
index 000..b89b15a
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/supply/mt6360_charger.yaml
@@ -0,0 +1,48 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/power/supply/mt6360_charger.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Battery charger driver for MT6360 PMIC from MediaTek Integrated.
+
+maintainers:
+ - Gene Chen
+
+description: |
+ This module is part of the MT6360 MFD device.
+ Provides Battery Charger, Boost for OTG devices and BC1.2 detection.
+
+properties:
+ compatible:
+const: mediatek,mt6360-chg
+
+ richtek,vinovp-microvolt:
+description: Maximum CHGIN regulation voltage in uV.
+enum: [ 550, 650, 1100, 1450 ]
+
+
+ usb-otg-vbus-regulator:
+type: object
+description: OTG boost regulator.
+$ref: /schemas/regulator/regulator.yaml#
+
+required:
+ - compatible
+
+additionalProperties: false
+
+examples:
+ - |
+mt6360_charger: charger {
+ compatible = "mediatek,mt6360-chg";
+ richtek,vinovp-microvolt = <1450>;
+
+ otg_vbus_regulator: usb-otg-vbus-regulator {
+regulator-compatible = "usb-otg-vbus";
+regulator-name = "usb-otg-vbus";
+regulator-min-microvolt = <4425000>;
+regulator-max-microvolt = <5825000>;
+ };
+};
+...
--
2.7.4
[PATCH v3 0/2] power: supply: mt6360_charger: add MT6360 charger support
This patch series add MT6360 Charger support contains driver and binding document Gene Chen (2) dt-bindings: power: Add bindings document for Charger support on MT6360 PMIC power: supply: mt6360_charger: add MT6360 charger support Documentation/devicetree/bindings/power/supply/mt6360_charger.yaml | 48 drivers/power/supply/Kconfig | 10 drivers/power/supply/Makefile |1 drivers/power/supply/mt6360_charger.c | 1022 ++ 4 files changed, 1081 insertions(+) changelogs between v1 & v2 - Add binding property with unit and custom name prefix - Remove extcon device, redundant brackets and interrupts - Fix power supply prop "charger type" changelogs between v2 & v3 - Add register selector to value mapping
Re: [PATCH] staging: ralink-gdma: Fixed blank line coding style issue
On Wed, Dec 23, 2020 at 09:22:30PM +0100, Ayoub Soussi wrote:
> Fixed coding style issue.
>
> Signed-off-by: Ayoub Soussi
> ---
> drivers/staging/ralink-gdma/ralink-gdma.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/staging/ralink-gdma/ralink-gdma.c
> b/drivers/staging/ralink-gdma/ralink-gdma.c
> index 655df317d0ee..a6181a167814 100644
> --- a/drivers/staging/ralink-gdma/ralink-gdma.c
> +++ b/drivers/staging/ralink-gdma/ralink-gdma.c
> @@ -122,6 +122,7 @@ struct gdma_dma_dev {
> struct gdma_data *data;
> void __iomem *base;
> struct tasklet_struct task;
> +
> volatile unsigned long chan_issued;
> atomic_t cnt;
With your knowledge of C, does this change look correct?
thanks,
greg k-h
[PATCH] proc_sysclt: fix oops caused by incorrect command parameters.
The process_sysctl_arg() does not check whether val is empty before
invoking strlen(val). If the command line parameter () is incorrectly
configured and val is empty, oops is triggered.
For example, "hung_task_panic=1" is incorrectly written as "hung_task_panic".
log:
Kernel command line: hung_task_panic
[000n] user address but active_mm is swapper
Internal error: Oops: 9605 [#1] SMP
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.10.1 #1
Hardware name: linux,dummy-virt (DT)
pstate: 4005 (nZcv daif -PAN -UAO -TCO BTYPE=--)
pc : __pi_strlen+0x10/0x98
lr : process_sysctl_arg+0x1e4/0x2ac
sp : ffc01104bd40
x29: ffc01104bd40 x28:
x27: ff80c0a4691e x26: ffc0102a7c8c
x25: x24: ffc01104be80
x23: ff80c22f0b00 x22: ff80c02e28c0
x21: ffc0109f9000 x20:
x19: ffc0107c08de x18: 0003
x17: ffc01105d000 x16: 0054
x15: x14: 3030253078413830
x13: x12:
x11: 0101010101010101 x10: 0005
x9 : 0003 x8 : ff80c0980c08
x7 : x6 : 0002
x5 : ff80c0235000 x4 : ff810f7c7ee0
x3 : 043a x2 : 00bdcc4ebacf1a54
x1 : x0 :
Call trace:
__pi_strlen+0x10/0x98
parse_args+0x278/0x344
do_sysctl_args+0x8c/0xfc
kernel_init+0x5c/0xf4
ret_from_fork+0x10/0x30
Code: b200c3eb 927cec01 f2400c07 54000301 (a8c10c22)
Fixes: 3db978d480e2843 ("kernel/sysctl: support setting sysctl parameters
from kernel command line")
Signed-off-by: Xiaoming Ni
---
fs/proc/proc_sysctl.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/fs/proc/proc_sysctl.c b/fs/proc/proc_sysctl.c
index 317899222d7f..4516411a2b44 100644
--- a/fs/proc/proc_sysctl.c
+++ b/fs/proc/proc_sysctl.c
@@ -1757,6 +1757,9 @@ static int process_sysctl_arg(char *param, char *val,
loff_t pos = 0;
ssize_t wret;
+ if (!val)
+ return 0;
+
if (strncmp(param, "sysctl", sizeof("sysctl") - 1) == 0) {
param += sizeof("sysctl") - 1;
--
2.27.0
Re: [PATCH v6 11/12] mfd: bd9571mwv: Make the driver more generic
On Thu, 24 Dec 2020, Yoshihiro Shimoda wrote:
> Hi Lee,
>
> > From: Lee Jones, Sent: Thursday, December 24, 2020 12:39 AM
> > On Wed, 23 Dec 2020, Yoshihiro Shimoda wrote:
> > > From: Khiem Nguyen
> > >
> > > Since the driver supports BD9571MWV PMIC only, this patch makes
> > > the functions and data structure become more generic so that
> > > it can support other PMIC variants as well. Also remove printing
> > > part name which Lee Jones suggested.
> > >
> > > Signed-off-by: Khiem Nguyen
> > > Co-developed-by: Yoshihiro Shimoda
> > > Signed-off-by: Yoshihiro Shimoda
> > > Reviewed-by: Matti Vaittinen
> > > ---
> > > drivers/mfd/bd9571mwv.c | 89
> > > +--
> > > include/linux/mfd/bd9571mwv.h | 18 +
> > > 2 files changed, 54 insertions(+), 53 deletions(-)
> >
> > Couple of small points.
> >
> > Remainder looks good.
>
> Thank you for your review!
>
> > > diff --git a/drivers/mfd/bd9571mwv.c b/drivers/mfd/bd9571mwv.c
> > > index 49e968e..c905ab4 100644
> > > --- a/drivers/mfd/bd9571mwv.c
> > > +++ b/drivers/mfd/bd9571mwv.c
> > > @@ -3,6 +3,7 @@
> > > * ROHM BD9571MWV-M MFD driver
> > > *
> > > * Copyright (C) 2017 Marek Vasut
> > > + * Copyright (C) 2020 Renesas Electronics Corporation
> > > *
> > > * Based on the TPS65086 driver
> > > */
> > > @@ -14,6 +15,14 @@
> > >
> > > #include
> > >
> > > +/* Driver data to distinguish bd957x variants */
> > > +struct bd957x_ddata {
> > > + const struct regmap_config *regmap_config;
> > > + const struct regmap_irq_chip *irq_chip;
> >
> > > + const struct mfd_cell *cells;
> > > + int num_cells;
> >
> > Are you using these post-probe?
> >
> > If not, they're not ddata.
>
> I'm not using all these members post-probe.
> So, I'll remove ddata.
>
>
> > > static int bd9571mwv_probe(struct i2c_client *client,
> > > - const struct i2c_device_id *ids)
> > > +const struct i2c_device_id *ids)
> > > {
> > > - struct bd9571mwv *bd;
> > > - int ret;
> > > -
> > > - bd = devm_kzalloc(>dev, sizeof(*bd), GFP_KERNEL);
> > > - if (!bd)
> > > - return -ENOMEM;
> > > -
> > > - i2c_set_clientdata(client, bd);
> > > - bd->dev = >dev;
> > > - bd->irq = client->irq;
> > > + const struct bd957x_ddata *ddata;
> > > + struct device *dev = >dev;
> > > + struct regmap *regmap;
> > > + struct regmap_irq_chip_data *irq_data;
> > > + int ret, irq = client->irq;
> > > +
> > > + /* Read the PMIC product code */
> > > + ret = i2c_smbus_read_byte_data(client, BD9571MWV_PRODUCT_CODE);
> > > + if (ret < 0) {
> > > + dev_err(dev, "Failed to read product code\n");
> > > + return ret;
> > > + }
> >
> > Nit: '\n' here.
>
> I got it. I'll add a blank line here.
>
> > > + switch (ret) {
> > > + case BD9571MWV_PRODUCT_CODE_BD9571MWV:
> > > + ddata = _ddata;
> >
> > Simply declare 'const struct mfd_cell *cells' locally in probe and
> > assign it here instead.
>
> I got it. I'll also add "const struct regmap_config *regmap_config;"
> and "const struct regmap_irq_chip *irq_chip;" locally in probe.
If you only use them there, then yes, that's correct.
--
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH] bpf: fix: address of local auto-variable assigned to a function parameter.
On 12/23/20 11:01 PM, YANG LI wrote:
Assigning local variable txq to the outputting parameter xdp->txq is not
safe, txq will be released after the end of the function call.
Then the result of using xdp is unpredictable.
Fix this error by defining the struct xdp_txq_info in function
dev_map_run_prog() as a static type.
Signed-off-by: YANG LI
Reported-by: Abaci
---
kernel/bpf/devmap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/bpf/devmap.c b/kernel/bpf/devmap.c
index f6e9c68..af6f004 100644
--- a/kernel/bpf/devmap.c
+++ b/kernel/bpf/devmap.c
@@ -454,7 +454,7 @@ static struct xdp_buff *dev_map_run_prog(struct net_device
*dev,
struct xdp_buff *xdp,
struct bpf_prog *xdp_prog)
{
- struct xdp_txq_info txq = { .dev = dev };
+ static struct xdp_txq_info txq = { .dev = dev };
u32 act;
xdp_set_data_meta_invalid(xdp);
exposing txq outside the routine with 'static' definition is not
a good practice. maybe just reset xdp->txq = NULl right before
function return?
diff --git a/kernel/bpf/devmap.c b/kernel/bpf/devmap.c
index f6e9c68afdd4..50f5c20a33a3 100644
--- a/kernel/bpf/devmap.c
+++ b/kernel/bpf/devmap.c
@@ -475,6 +475,7 @@ static struct xdp_buff *dev_map_run_prog(struct
net_device *dev,
}
xdp_return_buff(xdp);
+ xdp->txq = NULL;
return NULL;
}
-bash-4.4$
Re: [PATCH v4 01/11] dt-bindings: usb: convert usb-device.txt to YAML schema
On Mon, 2020-12-21 at 12:09 -0700, Rob Herring wrote:
> On Wed, Dec 16, 2020 at 05:30:02PM +0800, Chunfeng Yun wrote:
> > Convert usb-device.txt to YAML schema usb-device.yaml
> >
> > Signed-off-by: Chunfeng Yun
> > ---
> > v4: no changes, update dependent series:
> > https://patchwork.kernel.org/project/linux-usb/list/?series=399561
> > [v6,00/19] dt-bindings: usb: Add generic USB HCD, xHCI, DWC USB3 DT
> > schema
[...]
> > diff --git a/Documentation/devicetree/bindings/usb/usb-device.yaml
> > b/Documentation/devicetree/bindings/usb/usb-device.yaml
> > new file mode 100644
> > index ..f31d8a85d3e6
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/usb/usb-device.yaml
> > @@ -0,0 +1,125 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/usb/usb-device.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: The device tree bindings for the Generic USB Device
> > +
> > +maintainers:
> > + - Greg Kroah-Hartman
> > +
> > +description: |
> > + Usually, we only use device tree for hard wired USB device.
> > + The reference binding doc is from:
> > + http://www.devicetree.org/open-firmware/bindings/usb/usb-1_0.ps
> > +
> > + Four types of device-tree nodes are defined: "host-controller nodes"
> > + representing USB host controllers, "device nodes" representing USB
> > devices,
> > + "interface nodes" representing USB interfaces and "combined nodes"
> > + representing simple USB devices.
> > +
> > + A combined node shall be used instead of a device node and an interface
> > node
> > + for devices of class 0 or 9 (hub) with a single configuration and a
> > single
> > + interface.
> > +
> > + A "hub node" is a combined node or an interface node that represents a
> > USB
> > + hub.
> > +
> > +properties:
> > + compatible:
> > +pattern: "^usb[0-9a-f]+,[0-9a-f]+$"
>
> You can refine the length allowed a bit: [0-9a-f]{1,4}
>
> Same applies elsewhere.
Ok
>
> > +description: Device nodes or combined nodes.
> > + "usbVID,PID", where VID is the vendor id and PID the product id.
> > + The textual representation of VID and PID shall be in lower case
> > + hexadecimal with leading zeroes suppressed. The other compatible
> > + strings from the above standard binding could also be used,
> > + but a device adhering to this binding may leave out all except
> > + for "usbVID,PID".
> > +
[...]
> > diff --git a/Documentation/devicetree/bindings/usb/usb-hcd.yaml
> > b/Documentation/devicetree/bindings/usb/usb-hcd.yaml
> > index 9881ac10380d..5d0c6b5500d6 100755
> > --- a/Documentation/devicetree/bindings/usb/usb-hcd.yaml
> > +++ b/Documentation/devicetree/bindings/usb/usb-hcd.yaml
> > @@ -23,6 +23,32 @@ properties:
> >targeted hosts (non-PC hosts).
> > type: boolean
> >
> > + "#address-cells":
> > +const: 1
> > +
> > + "#size-cells":
> > +const: 0
> > +
> > +patternProperties:
> > + "@[0-9a-f]+$":
> > +type: object
> > +description: The hard wired USB devices
> > +
> > +properties:
> > + compatible:
> > +pattern: "^usb[0-9a-f]+,[0-9a-f]+$"
> > +$ref: /usb/usb-device.yaml
>
> This is wrong. It should be up a level.
Ok
> And no need to define
> 'compatible' or 'reg' here because those are defined within
> usb-device.yaml.
will drop it
>
> > +description: the string is 'usbVID,PID', where VID is the vendor id
> > + and PID is the product id
> > +
> > + reg:
> > +$ref: /usb/usb-device.yaml
> > +maxItems: 1
> > +
> > +required:
> > + - compatible
> > + - reg
> > +
> > additionalProperties: true
> >
> > examples:
> > @@ -30,4 +56,11 @@ examples:
> > usb {
> > phys = <_phy1>, <_phy1>;
> > phy-names = "usb";
> > +#address-cells = <1>;
> > +#size-cells = <0>;
> > +
> > +hub@1 {
> > +compatible = "usb5e3,610";
> > +reg = <1>;
> > +};
> > };
> > --
> > 2.18.0
> >
Re: [PATCH 2/3] usb: xhci-mtk: fix UAS issue by XHCI_BROKEN_STREAMS quirk
On Wed, 2020-12-16 at 19:43 -0800, Rosen Penev wrote:
> On Wed, Dec 16, 2020 at 6:29 PM Chunfeng Yun
> wrote:
> >
> > On Wed, 2020-12-16 at 20:28 +0800, Nicolas Boichat wrote:
> > > On Wed, Dec 16, 2020 at 7:53 PM Chunfeng Yun
> > > wrote:
> > > >
> > > > The 0.96 xHCI controller on some platforms does not support
> > > > bulk stream even HCCPARAMS says supporting, due to MaxPSASize
> > > > is set a non-zero default value by mistake, here use
> > > > XHCI_BROKEN_STREAMS quirk to fix it.
> > > >
> > > > Fixes: 94a631d91ad3 ("usb: xhci-mtk: check hcc_params after adding
> > > > primary hcd")
> > > > Signed-off-by: Chunfeng Yun
> > > > ---
> > > > drivers/usb/host/xhci-mtk.c | 7 ++-
> > > > drivers/usb/host/xhci-mtk.h | 1 +
> > > > 2 files changed, 7 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c
> > > > index 8f321f39ab96..08dab974d847 100644
> > > > --- a/drivers/usb/host/xhci-mtk.c
> > > > +++ b/drivers/usb/host/xhci-mtk.c
> > > > @@ -395,6 +395,9 @@ static void xhci_mtk_quirks(struct device *dev,
> > > > struct xhci_hcd *xhci)
> > > > xhci->quirks |= XHCI_SPURIOUS_SUCCESS;
> > > > if (mtk->lpm_support)
> > > > xhci->quirks |= XHCI_LPM_SUPPORT;
> > > > +
> > > > + if (mtk->broken_streams)
> > > > + xhci->quirks |= XHCI_BROKEN_STREAMS;
> > > > }
> > > >
> > > > /* called during probe() after chip reset completes */
> > > > @@ -460,6 +463,8 @@ static int xhci_mtk_probe(struct platform_device
> > > > *pdev)
> > > > return ret;
> > > >
> > > > mtk->lpm_support = of_property_read_bool(node,
> > > > "usb3-lpm-capable");
> > > > + mtk->broken_streams =
> > > > + of_property_read_bool(node,
> > > > "mediatek,broken_streams_quirk");
> > >
> > > Would it be better to add a data field to struct of_device_id
> > > mtk_xhci_of_match, and enable this quirk on mediatek,mt8173-xhci only?
> > This is the common issue for all SoCs (before 2016.06) with 0.96 xHCI
> > when the controller don't support bulk stream. If enable this quirk only
> > for mt8173, then for other SoCs, the compatible need include
> > "mediatek,mt8173-xhci" in dts, this may be not flexible for some cases,
> > e.g. a new SoC has the broken stream as mt8173, but also has another
> > different quirk, the way you suggested will not handle it.
> > And I plan to remove "mediatek,mt8173-xhci" in mtk_xhci_of_match after
> > converting the binding to YMAL.
> I'm guessing this also applies to mt7621?
Yes, mt7621 doesn't support bulk stream
> >
> > >
> > > (IMHO usb3-lpm-capable detection should also be done in the same way)
> > I prefer to provide a property for common issues, and use the way you
> > suggested for the issue only happened at a specific SoC.
> >
> > Thank you
> >
> > >
> > > Thanks,
> > >
> > > > /* optional property, ignore the error if it does not exist */
> > > > of_property_read_u32(node, "mediatek,u3p-dis-msk",
> > > > >u3p_dis_msk);
> > > > @@ -546,7 +551,7 @@ static int xhci_mtk_probe(struct platform_device
> > > > *pdev)
> > > > if (ret)
> > > > goto put_usb3_hcd;
> > > >
> > > > - if (HCC_MAX_PSA(xhci->hcc_params) >= 4)
> > > > + if (!mtk->broken_streams && HCC_MAX_PSA(xhci->hcc_params) >= 4)
> > > > xhci->shared_hcd->can_do_streams = 1;
> > > >
> > > > ret = usb_add_hcd(xhci->shared_hcd, irq, IRQF_SHARED);
> > > > diff --git a/drivers/usb/host/xhci-mtk.h b/drivers/usb/host/xhci-mtk.h
> > > > index a93cfe817904..86aa4978915e 100644
> > > > --- a/drivers/usb/host/xhci-mtk.h
> > > > +++ b/drivers/usb/host/xhci-mtk.h
> > > > @@ -147,6 +147,7 @@ struct xhci_hcd_mtk {
> > > > struct phy **phys;
> > > > int num_phys;
> > > > bool lpm_support;
> > > > + bool broken_streams;
> > > > /* usb remote wakeup */
> > > > bool uwk_en;
> > > > struct regmap *uwk;
> > > > --
> > > > 2.18.0
> >
> > ___
> > linux-arm-kernel mailing list
> > linux-arm-ker...@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Re: [PATCH v23 11/15] tools: Introduce a minimal user-space tool for DAMON
On Wed, 23 Dec 2020 14:56:10 -0800 Shakeel Butt wrote: > On Wed, Dec 23, 2020 at 10:38 AM SeongJae Park wrote: > > > [snip] > > > > I will drop this patch from the next version of this patchset, because this > > is > > not the essential part but could only make the code review time consuming. > > I > > will post another DAMON RFC patchset for convenient user space usages > > including > > this and the perf integration. > > You can just add the link to your github repo with commit/tag > containing the usage examples in the cover letter. Thank you for the nice suggestion! I will keep this patch on my development tree at Github and provide a link to it. Thanks, SeongJae Park
Re: [PATCH v23 05/15] mm/damon: Implement primitives for the virtual memory address spaces
On Wed, 23 Dec 2020 14:54:02 -0800 Shakeel Butt wrote:
> On Wed, Dec 23, 2020 at 8:47 AM SeongJae Park wrote:
> >
> [snip]
> > > [snip]
> > > > +
> > > > +static bool damon_va_young(struct mm_struct *mm, unsigned long addr,
> > > > + unsigned long *page_sz)
> > > > +{
> > > > + pte_t *pte = NULL;
> > > > + pmd_t *pmd = NULL;
> > > > + spinlock_t *ptl;
> > > > + bool young = false;
> > > > +
> > > > + if (follow_pte_pmd(mm, addr, NULL, , , ))
> > > > + return false;
> > > > +
> > > > + *page_sz = PAGE_SIZE;
> > > > + if (pte) {
> > > > + young = pte_young(*pte);
> > > > + if (!young)
> > > > + young = !page_is_idle(pte_page(*pte));
> > > > + pte_unmap_unlock(pte, ptl);
> > > > + return young;
> > > > + }
> > > > +
> > > > +#ifdef CONFIG_TRANSPARENT_HUGEPAGE
> > > > + young = pmd_young(*pmd);
> > > > + if (!young)
> > > > + young = !page_is_idle(pmd_page(*pmd));
> > > > + spin_unlock(ptl);
> > > > + *page_sz = ((1UL) << HPAGE_PMD_SHIFT);
> > > > +#endif /* CONFIG_TRANSPARENT_HUGEPAGE */
> > > > +
> > > > + return young;
> > >
> > > You need mmu_notifier_test_young() here. Hmm I remember mentioning
> > > this in some previous version as well.
> >
> > Your question and my answer was as below:
> >
> > > Don't you need mmu_notifier_clear_young() here?
> >
> > I think we don't need it here because we only read the Accessed bit and
> > PG_Idle
> > if Accessed bit was not set.
> >
> > I should notice that you mean 'test_young()' but didn't, sorry. I will add
> > it
> > in the next version.
> >
>
> I should have said mmu_notifier_test_young() instead of
> mmu_notifier_clear_young().
>
> > >
> > > BTW have you tested this on a VM?
> >
> > Yes. Indeed, I'm testing this on a QEMU/KVM environment. You can get more
> > detail at:
> > https://damonitor.github.io/doc/html/latest/vm/damon/eval.html#setup
> >
>
> Hmm without mmu_notifier_test_young() you should be missing the kvm
> mmu access updates. Can you please recheck if your eval is correctly
> seeing the memory accesses from the VM?
Seems I didn't clearly answered, sorry. My test setup installs the
DAMON-enabled kernel in a guest VM and run it for workloads in the guest,
rather than running DAMON in host to monitor accesses of VMs. The MMU notifier
is for latter case, AFAIU, so my test setup didn't see the problem.
If I'm missing something, please let me know.
Thanks,
SeongJae Park
[PATCH v7 01/12] mfd: bd9571mwv: Use devm_mfd_add_devices()
To remove mfd devices when unload this driver, should use
devm_mfd_add_devices() instead.
Fixes: d3ea21272094 ("mfd: Add ROHM BD9571MWV-M MFD PMIC driver")
Signed-off-by: Yoshihiro Shimoda
Acked-for-MFD-by: Lee Jones
Reviewed-by: Geert Uytterhoeven
Reviewed-by: Matti Vaittinen
---
drivers/mfd/bd9571mwv.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/mfd/bd9571mwv.c b/drivers/mfd/bd9571mwv.c
index fab3cdc..19d57a4 100644
--- a/drivers/mfd/bd9571mwv.c
+++ b/drivers/mfd/bd9571mwv.c
@@ -185,9 +185,9 @@ static int bd9571mwv_probe(struct i2c_client *client,
return ret;
}
- ret = mfd_add_devices(bd->dev, PLATFORM_DEVID_AUTO, bd9571mwv_cells,
- ARRAY_SIZE(bd9571mwv_cells), NULL, 0,
- regmap_irq_get_domain(bd->irq_data));
+ ret = devm_mfd_add_devices(bd->dev, PLATFORM_DEVID_AUTO,
+ bd9571mwv_cells, ARRAY_SIZE(bd9571mwv_cells),
+ NULL, 0,
regmap_irq_get_domain(bd->irq_data));
if (ret) {
regmap_del_irq_chip(bd->irq, bd->irq_data);
return ret;
--
2.7.4
[PATCH v7 03/12] mfd: rohm-generic: Add BD9571 and BD9574
Add chip IDs for BD9571MWV and BD9574MWF.
Signed-off-by: Yoshihiro Shimoda
Reviewed-by: Matti Vaittinen
Acked-for-MFD-by: Lee Jones
---
include/linux/mfd/rohm-generic.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/linux/mfd/rohm-generic.h b/include/linux/mfd/rohm-generic.h
index 4283b5b..affacf8 100644
--- a/include/linux/mfd/rohm-generic.h
+++ b/include/linux/mfd/rohm-generic.h
@@ -12,6 +12,8 @@ enum rohm_chip_type {
ROHM_CHIP_TYPE_BD71847,
ROHM_CHIP_TYPE_BD70528,
ROHM_CHIP_TYPE_BD71828,
+ ROHM_CHIP_TYPE_BD9571,
+ ROHM_CHIP_TYPE_BD9574,
ROHM_CHIP_TYPE_AMOUNT
};
--
2.7.4
[PATCH v7 04/12] regulator: bd9571mwv: rid of using struct bd9571mwv
To simplify this driver, use dev_get_regmap() and
rid of using struct bd9571mwv.
Signed-off-by: Yoshihiro Shimoda
Reviewed-by: Matti Vaittinen
---
drivers/regulator/bd9571mwv-regulator.c | 49 +
1 file changed, 26 insertions(+), 23 deletions(-)
diff --git a/drivers/regulator/bd9571mwv-regulator.c
b/drivers/regulator/bd9571mwv-regulator.c
index e690c2c..42b6a70 100644
--- a/drivers/regulator/bd9571mwv-regulator.c
+++ b/drivers/regulator/bd9571mwv-regulator.c
@@ -17,7 +17,7 @@
#include
struct bd9571mwv_reg {
- struct bd9571mwv *bd;
+ struct regmap *regmap;
/* DDR Backup Power */
u8 bkup_mode_cnt_keepon;/* from "rohm,ddr-backup-power" */
@@ -137,26 +137,30 @@ static const struct regulator_desc regulators[] = {
};
#ifdef CONFIG_PM_SLEEP
-static int bd9571mwv_bkup_mode_read(struct bd9571mwv *bd, unsigned int *mode)
+static int bd9571mwv_bkup_mode_read(struct bd9571mwv_reg *bdreg,
+ unsigned int *mode)
{
int ret;
- ret = regmap_read(bd->regmap, BD9571MWV_BKUP_MODE_CNT, mode);
+ ret = regmap_read(bdreg->regmap, BD9571MWV_BKUP_MODE_CNT, mode);
if (ret) {
- dev_err(bd->dev, "failed to read backup mode (%d)\n", ret);
+ dev_err(regmap_get_device(bdreg->regmap),
+ "failed to read backup mode (%d)\n", ret);
return ret;
}
return 0;
}
-static int bd9571mwv_bkup_mode_write(struct bd9571mwv *bd, unsigned int mode)
+static int bd9571mwv_bkup_mode_write(struct bd9571mwv_reg *bdreg,
+unsigned int mode)
{
int ret;
- ret = regmap_write(bd->regmap, BD9571MWV_BKUP_MODE_CNT, mode);
+ ret = regmap_write(bdreg->regmap, BD9571MWV_BKUP_MODE_CNT, mode);
if (ret) {
- dev_err(bd->dev, "failed to configure backup mode 0x%x (%d)\n",
+ dev_err(regmap_get_device(bdreg->regmap),
+ "failed to configure backup mode 0x%x (%d)\n",
mode, ret);
return ret;
}
@@ -194,7 +198,7 @@ static ssize_t backup_mode_store(struct device *dev,
* Configure DDR Backup Mode, to change the role of the accessory power
* switch from a power switch to a wake-up switch, or vice versa
*/
- ret = bd9571mwv_bkup_mode_read(bdreg->bd, );
+ ret = bd9571mwv_bkup_mode_read(bdreg, );
if (ret)
return ret;
@@ -202,7 +206,7 @@ static ssize_t backup_mode_store(struct device *dev,
if (bdreg->bkup_mode_enabled)
mode |= bdreg->bkup_mode_cnt_keepon;
- ret = bd9571mwv_bkup_mode_write(bdreg->bd, mode);
+ ret = bd9571mwv_bkup_mode_write(bdreg, mode);
if (ret)
return ret;
@@ -221,7 +225,7 @@ static int bd9571mwv_suspend(struct device *dev)
return 0;
/* Save DDR Backup Mode */
- ret = bd9571mwv_bkup_mode_read(bdreg->bd, );
+ ret = bd9571mwv_bkup_mode_read(bdreg, );
if (ret)
return ret;
@@ -235,7 +239,7 @@ static int bd9571mwv_suspend(struct device *dev)
mode |= bdreg->bkup_mode_cnt_keepon;
if (mode != bdreg->bkup_mode_cnt_saved)
- return bd9571mwv_bkup_mode_write(bdreg->bd, mode);
+ return bd9571mwv_bkup_mode_write(bdreg, mode);
return 0;
}
@@ -248,7 +252,7 @@ static int bd9571mwv_resume(struct device *dev)
return 0;
/* Restore DDR Backup Mode */
- return bd9571mwv_bkup_mode_write(bdreg->bd, bdreg->bkup_mode_cnt_saved);
+ return bd9571mwv_bkup_mode_write(bdreg, bdreg->bkup_mode_cnt_saved);
}
static const struct dev_pm_ops bd9571mwv_pm = {
@@ -268,7 +272,6 @@ static int bd9571mwv_regulator_remove(struct
platform_device *pdev)
static int bd9571mwv_regulator_probe(struct platform_device *pdev)
{
- struct bd9571mwv *bd = dev_get_drvdata(pdev->dev.parent);
struct regulator_config config = { };
struct bd9571mwv_reg *bdreg;
struct regulator_dev *rdev;
@@ -279,40 +282,40 @@ static int bd9571mwv_regulator_probe(struct
platform_device *pdev)
if (!bdreg)
return -ENOMEM;
- bdreg->bd = bd;
+ bdreg->regmap = dev_get_regmap(pdev->dev.parent, NULL);
platform_set_drvdata(pdev, bdreg);
config.dev = >dev;
- config.dev->of_node = bd->dev->of_node;
- config.driver_data = bd;
- config.regmap = bd->regmap;
+ config.dev->of_node = pdev->dev.parent->of_node;
+ config.driver_data = bdreg;
+ config.regmap = bdreg->regmap;
for (i = 0; i < ARRAY_SIZE(regulators); i++) {
rdev = devm_regulator_register(>dev, [i],
);
if (IS_ERR(rdev)) {
- dev_err(bd->dev, "failed to register %s regulator\n",
+
[PATCH v7 07/12] gpio: bd9571mwv: rid of using struct bd9571mwv
To simplify this driver, use dev_get_regmap() and
rid of using struct bd9571mwv.
Signed-off-by: Yoshihiro Shimoda
Reviewed-by: Matti Vaittinen
---
drivers/gpio/gpio-bd9571mwv.c | 19 +--
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/drivers/gpio/gpio-bd9571mwv.c b/drivers/gpio/gpio-bd9571mwv.c
index abb622c..0e5395f 100644
--- a/drivers/gpio/gpio-bd9571mwv.c
+++ b/drivers/gpio/gpio-bd9571mwv.c
@@ -16,8 +16,8 @@
#include
struct bd9571mwv_gpio {
+ struct regmap *regmap;
struct gpio_chip chip;
- struct bd9571mwv *bd;
};
static int bd9571mwv_gpio_get_direction(struct gpio_chip *chip,
@@ -26,7 +26,7 @@ static int bd9571mwv_gpio_get_direction(struct gpio_chip
*chip,
struct bd9571mwv_gpio *gpio = gpiochip_get_data(chip);
int ret, val;
- ret = regmap_read(gpio->bd->regmap, BD9571MWV_GPIO_DIR, );
+ ret = regmap_read(gpio->regmap, BD9571MWV_GPIO_DIR, );
if (ret < 0)
return ret;
if (val & BIT(offset))
@@ -40,8 +40,7 @@ static int bd9571mwv_gpio_direction_input(struct gpio_chip
*chip,
{
struct bd9571mwv_gpio *gpio = gpiochip_get_data(chip);
- regmap_update_bits(gpio->bd->regmap, BD9571MWV_GPIO_DIR,
- BIT(offset), 0);
+ regmap_update_bits(gpio->regmap, BD9571MWV_GPIO_DIR, BIT(offset), 0);
return 0;
}
@@ -52,9 +51,9 @@ static int bd9571mwv_gpio_direction_output(struct gpio_chip
*chip,
struct bd9571mwv_gpio *gpio = gpiochip_get_data(chip);
/* Set the initial value */
- regmap_update_bits(gpio->bd->regmap, BD9571MWV_GPIO_OUT,
+ regmap_update_bits(gpio->regmap, BD9571MWV_GPIO_OUT,
BIT(offset), value ? BIT(offset) : 0);
- regmap_update_bits(gpio->bd->regmap, BD9571MWV_GPIO_DIR,
+ regmap_update_bits(gpio->regmap, BD9571MWV_GPIO_DIR,
BIT(offset), BIT(offset));
return 0;
@@ -65,7 +64,7 @@ static int bd9571mwv_gpio_get(struct gpio_chip *chip,
unsigned int offset)
struct bd9571mwv_gpio *gpio = gpiochip_get_data(chip);
int ret, val;
- ret = regmap_read(gpio->bd->regmap, BD9571MWV_GPIO_IN, );
+ ret = regmap_read(gpio->regmap, BD9571MWV_GPIO_IN, );
if (ret < 0)
return ret;
@@ -77,7 +76,7 @@ static void bd9571mwv_gpio_set(struct gpio_chip *chip,
unsigned int offset,
{
struct bd9571mwv_gpio *gpio = gpiochip_get_data(chip);
- regmap_update_bits(gpio->bd->regmap, BD9571MWV_GPIO_OUT,
+ regmap_update_bits(gpio->regmap, BD9571MWV_GPIO_OUT,
BIT(offset), value ? BIT(offset) : 0);
}
@@ -105,9 +104,9 @@ static int bd9571mwv_gpio_probe(struct platform_device
*pdev)
platform_set_drvdata(pdev, gpio);
- gpio->bd = dev_get_drvdata(pdev->dev.parent);
+ gpio->regmap = dev_get_regmap(pdev->dev.parent, NULL);
gpio->chip = template_chip;
- gpio->chip.parent = gpio->bd->dev;
+ gpio->chip.parent = pdev->dev.parent;
ret = devm_gpiochip_add_data(>dev, >chip, gpio);
if (ret < 0) {
--
2.7.4
[PATCH v7 08/12] gpio: bd9571mwv: Add BD9574MWF support
Add support for BD9574MWF which is similar chip with BD9571MWV.
Note that BD9574MWF has additional features "RECOV_GPOUT",
"FREQSEL" and "RTC_IN", but supports GPIO function only.
Signed-off-by: Yoshihiro Shimoda
Reviewed-by: Matti Vaittinen
---
drivers/gpio/gpio-bd9571mwv.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpio/gpio-bd9571mwv.c b/drivers/gpio/gpio-bd9571mwv.c
index 0e5395f..df6102b 100644
--- a/drivers/gpio/gpio-bd9571mwv.c
+++ b/drivers/gpio/gpio-bd9571mwv.c
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0-only
/*
- * ROHM BD9571MWV-M GPIO driver
+ * ROHM BD9571MWV-M and BD9574MWF-M GPIO driver
*
* Copyright (C) 2017 Marek Vasut
*
@@ -10,6 +10,7 @@
*/
#include
+#include
#include
#include
@@ -118,7 +119,8 @@ static int bd9571mwv_gpio_probe(struct platform_device
*pdev)
}
static const struct platform_device_id bd9571mwv_gpio_id_table[] = {
- { "bd9571mwv-gpio", },
+ { "bd9571mwv-gpio", ROHM_CHIP_TYPE_BD9571 },
+ { "bd9574mwf-gpio", ROHM_CHIP_TYPE_BD9574 },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(platform, bd9571mwv_gpio_id_table);
--
2.7.4
[PATCH v7 12/12] mfd: bd9571mwv: Add support for BD9574MWF
From: Khiem Nguyen
The new PMIC BD9574MWF inherits features from BD9571MWV.
Add the support of new PMIC to existing bd9571mwv driver.
Signed-off-by: Khiem Nguyen
Co-developed-by: Yoshihiro Shimoda
Signed-off-by: Yoshihiro Shimoda
Reviewed-by: Matti Vaittinen
Acked-for-MFD-by: Lee Jones
---
drivers/mfd/bd9571mwv.c | 76 ++-
include/linux/mfd/bd9571mwv.h | 17 --
2 files changed, 89 insertions(+), 4 deletions(-)
diff --git a/drivers/mfd/bd9571mwv.c b/drivers/mfd/bd9571mwv.c
index 2c1fcbb..e15b1ac 100644
--- a/drivers/mfd/bd9571mwv.c
+++ b/drivers/mfd/bd9571mwv.c
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0-only
/*
- * ROHM BD9571MWV-M MFD driver
+ * ROHM BD9571MWV-M and BD9574MVF-M core driver
*
* Copyright (C) 2017 Marek Vasut
* Copyright (C) 2020 Renesas Electronics Corporation
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include
#include
@@ -103,6 +104,72 @@ static struct regmap_irq_chip bd9571mwv_irq_chip = {
.num_irqs = ARRAY_SIZE(bd9571mwv_irqs),
};
+static const struct mfd_cell bd9574mwf_cells[] = {
+ { .name = "bd9574mwf-regulator", },
+ { .name = "bd9574mwf-gpio", },
+};
+
+static const struct regmap_range bd9574mwf_readable_yes_ranges[] = {
+ regmap_reg_range(BD9571MWV_VENDOR_CODE, BD9571MWV_PRODUCT_REVISION),
+ regmap_reg_range(BD9571MWV_BKUP_MODE_CNT, BD9571MWV_BKUP_MODE_CNT),
+ regmap_reg_range(BD9571MWV_DVFS_VINIT, BD9571MWV_DVFS_SETVMAX),
+ regmap_reg_range(BD9571MWV_DVFS_SETVID, BD9571MWV_DVFS_MONIVDAC),
+ regmap_reg_range(BD9571MWV_GPIO_IN, BD9571MWV_GPIO_IN),
+ regmap_reg_range(BD9571MWV_GPIO_INT, BD9571MWV_GPIO_INTMASK),
+ regmap_reg_range(BD9571MWV_INT_INTREQ, BD9571MWV_INT_INTMASK),
+};
+
+static const struct regmap_access_table bd9574mwf_readable_table = {
+ .yes_ranges = bd9574mwf_readable_yes_ranges,
+ .n_yes_ranges = ARRAY_SIZE(bd9574mwf_readable_yes_ranges),
+};
+
+static const struct regmap_range bd9574mwf_writable_yes_ranges[] = {
+ regmap_reg_range(BD9571MWV_BKUP_MODE_CNT, BD9571MWV_BKUP_MODE_CNT),
+ regmap_reg_range(BD9571MWV_DVFS_SETVID, BD9571MWV_DVFS_SETVID),
+ regmap_reg_range(BD9571MWV_GPIO_DIR, BD9571MWV_GPIO_OUT),
+ regmap_reg_range(BD9571MWV_GPIO_INT_SET, BD9571MWV_GPIO_INTMASK),
+ regmap_reg_range(BD9571MWV_INT_INTREQ, BD9571MWV_INT_INTMASK),
+};
+
+static const struct regmap_access_table bd9574mwf_writable_table = {
+ .yes_ranges = bd9574mwf_writable_yes_ranges,
+ .n_yes_ranges = ARRAY_SIZE(bd9574mwf_writable_yes_ranges),
+};
+
+static const struct regmap_range bd9574mwf_volatile_yes_ranges[] = {
+ regmap_reg_range(BD9571MWV_DVFS_MONIVDAC, BD9571MWV_DVFS_MONIVDAC),
+ regmap_reg_range(BD9571MWV_GPIO_IN, BD9571MWV_GPIO_IN),
+ regmap_reg_range(BD9571MWV_GPIO_INT, BD9571MWV_GPIO_INT),
+ regmap_reg_range(BD9571MWV_INT_INTREQ, BD9571MWV_INT_INTREQ),
+};
+
+static const struct regmap_access_table bd9574mwf_volatile_table = {
+ .yes_ranges = bd9574mwf_volatile_yes_ranges,
+ .n_yes_ranges = ARRAY_SIZE(bd9574mwf_volatile_yes_ranges),
+};
+
+static const struct regmap_config bd9574mwf_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+ .cache_type = REGCACHE_RBTREE,
+ .rd_table = _readable_table,
+ .wr_table = _writable_table,
+ .volatile_table = _volatile_table,
+ .max_register = 0xff,
+};
+
+static struct regmap_irq_chip bd9574mwf_irq_chip = {
+ .name = "bd9574mwf",
+ .status_base= BD9571MWV_INT_INTREQ,
+ .mask_base = BD9571MWV_INT_INTMASK,
+ .ack_base = BD9571MWV_INT_INTREQ,
+ .init_ack_masked = true,
+ .num_regs = 1,
+ .irqs = bd9571mwv_irqs,
+ .num_irqs = ARRAY_SIZE(bd9571mwv_irqs),
+};
+
static int bd957x_identify(struct device *dev, struct regmap *regmap)
{
unsigned int value;
@@ -162,6 +229,12 @@ static int bd9571mwv_probe(struct i2c_client *client,
cells = bd9571mwv_cells;
num_cells = ARRAY_SIZE(bd9571mwv_cells);
break;
+ case BD9571MWV_PRODUCT_CODE_BD9574MWF:
+ regmap_config = _regmap_config;
+ irq_chip = _irq_chip;
+ cells = bd9574mwf_cells;
+ num_cells = ARRAY_SIZE(bd9574mwf_cells);
+ break;
default:
dev_err(dev, "Unsupported device 0x%x\n", ret);
return -ENODEV;
@@ -190,6 +263,7 @@ static int bd9571mwv_probe(struct i2c_client *client,
static const struct of_device_id bd9571mwv_of_match_table[] = {
{ .compatible = "rohm,bd9571mwv", },
+ { .compatible = "rohm,bd9574mwf", },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, bd9571mwv_of_match_table);
diff --git a/include/linux/mfd/bd9571mwv.h b/include/linux/mfd/bd9571mwv.h
index
[PATCH v7 10/12] mfd: bd9571mwv: Use devm_regmap_add_irq_chip()
Use dev_regmap_add_irq_chip() to simplify the code.
Signed-off-by: Yoshihiro Shimoda
Acked-for-MFD-by: Lee Jones
Reviewed-by: Matti Vaittinen
Reviewed-by: Geert Uytterhoeven
---
drivers/mfd/bd9571mwv.c | 27 ++-
1 file changed, 6 insertions(+), 21 deletions(-)
diff --git a/drivers/mfd/bd9571mwv.c b/drivers/mfd/bd9571mwv.c
index e68c3fa..49e968e 100644
--- a/drivers/mfd/bd9571mwv.c
+++ b/drivers/mfd/bd9571mwv.c
@@ -170,31 +170,17 @@ static int bd9571mwv_probe(struct i2c_client *client,
if (ret)
return ret;
- ret = regmap_add_irq_chip(bd->regmap, bd->irq, IRQF_ONESHOT, 0,
- _irq_chip, >irq_data);
+ ret = devm_regmap_add_irq_chip(bd->dev, bd->regmap, bd->irq,
+ IRQF_ONESHOT, 0, _irq_chip,
+ >irq_data);
if (ret) {
dev_err(bd->dev, "Failed to register IRQ chip\n");
return ret;
}
- ret = devm_mfd_add_devices(bd->dev, PLATFORM_DEVID_AUTO,
- bd9571mwv_cells, ARRAY_SIZE(bd9571mwv_cells),
- NULL, 0,
regmap_irq_get_domain(bd->irq_data));
- if (ret) {
- regmap_del_irq_chip(bd->irq, bd->irq_data);
- return ret;
- }
-
- return 0;
-}
-
-static int bd9571mwv_remove(struct i2c_client *client)
-{
- struct bd9571mwv *bd = i2c_get_clientdata(client);
-
- regmap_del_irq_chip(bd->irq, bd->irq_data);
-
- return 0;
+ return devm_mfd_add_devices(bd->dev, PLATFORM_DEVID_AUTO,
+ bd9571mwv_cells,
ARRAY_SIZE(bd9571mwv_cells),
+ NULL, 0,
regmap_irq_get_domain(bd->irq_data));
}
static const struct of_device_id bd9571mwv_of_match_table[] = {
@@ -215,7 +201,6 @@ static struct i2c_driver bd9571mwv_driver = {
.of_match_table = bd9571mwv_of_match_table,
},
.probe = bd9571mwv_probe,
- .remove = bd9571mwv_remove,
.id_table = bd9571mwv_id_table,
};
module_i2c_driver(bd9571mwv_driver);
--
2.7.4
[PATCH v7 11/12] mfd: bd9571mwv: Make the driver more generic
From: Khiem Nguyen
Since the driver supports BD9571MWV PMIC only, this patch makes
the functions and data structure become more generic so that
it can support other PMIC variants as well. Also remove printing
part name which Lee Jones suggested.
Signed-off-by: Khiem Nguyen
Co-developed-by: Yoshihiro Shimoda
Signed-off-by: Yoshihiro Shimoda
Reviewed-by: Matti Vaittinen
---
drivers/mfd/bd9571mwv.c | 77 +++
include/linux/mfd/bd9571mwv.h | 18 ++
2 files changed, 43 insertions(+), 52 deletions(-)
diff --git a/drivers/mfd/bd9571mwv.c b/drivers/mfd/bd9571mwv.c
index 49e968e..2c1fcbb 100644
--- a/drivers/mfd/bd9571mwv.c
+++ b/drivers/mfd/bd9571mwv.c
@@ -3,6 +3,7 @@
* ROHM BD9571MWV-M MFD driver
*
* Copyright (C) 2017 Marek Vasut
+ * Copyright (C) 2020 Renesas Electronics Corporation
*
* Based on the TPS65086 driver
*/
@@ -102,13 +103,12 @@ static struct regmap_irq_chip bd9571mwv_irq_chip = {
.num_irqs = ARRAY_SIZE(bd9571mwv_irqs),
};
-static int bd9571mwv_identify(struct bd9571mwv *bd)
+static int bd957x_identify(struct device *dev, struct regmap *regmap)
{
- struct device *dev = bd->dev;
unsigned int value;
int ret;
- ret = regmap_read(bd->regmap, BD9571MWV_VENDOR_CODE, );
+ ret = regmap_read(regmap, BD9571MWV_VENDOR_CODE, );
if (ret) {
dev_err(dev, "Failed to read vendor code register (ret=%i)\n",
ret);
@@ -121,66 +121,71 @@ static int bd9571mwv_identify(struct bd9571mwv *bd)
return -EINVAL;
}
- ret = regmap_read(bd->regmap, BD9571MWV_PRODUCT_CODE, );
+ ret = regmap_read(regmap, BD9571MWV_PRODUCT_CODE, );
if (ret) {
dev_err(dev, "Failed to read product code register (ret=%i)\n",
ret);
return ret;
}
-
- if (value != BD9571MWV_PRODUCT_CODE_VAL) {
- dev_err(dev, "Invalid product code ID %02x (expected %02x)\n",
- value, BD9571MWV_PRODUCT_CODE_VAL);
- return -EINVAL;
- }
-
- ret = regmap_read(bd->regmap, BD9571MWV_PRODUCT_REVISION, );
+ ret = regmap_read(regmap, BD9571MWV_PRODUCT_REVISION, );
if (ret) {
dev_err(dev, "Failed to read revision register (ret=%i)\n",
ret);
return ret;
}
- dev_info(dev, "Device: BD9571MWV rev. %d\n", value & 0xff);
-
return 0;
}
static int bd9571mwv_probe(struct i2c_client *client,
- const struct i2c_device_id *ids)
+ const struct i2c_device_id *ids)
{
- struct bd9571mwv *bd;
- int ret;
-
- bd = devm_kzalloc(>dev, sizeof(*bd), GFP_KERNEL);
- if (!bd)
- return -ENOMEM;
+ const struct regmap_config *regmap_config;
+ const struct regmap_irq_chip *irq_chip;
+ const struct mfd_cell *cells;
+ struct device *dev = >dev;
+ struct regmap *regmap;
+ struct regmap_irq_chip_data *irq_data;
+ int ret, num_cells, irq = client->irq;
+
+ /* Read the PMIC product code */
+ ret = i2c_smbus_read_byte_data(client, BD9571MWV_PRODUCT_CODE);
+ if (ret < 0) {
+ dev_err(dev, "Failed to read product code\n");
+ return ret;
+ }
- i2c_set_clientdata(client, bd);
- bd->dev = >dev;
- bd->irq = client->irq;
+ switch (ret) {
+ case BD9571MWV_PRODUCT_CODE_BD9571MWV:
+ regmap_config = _regmap_config;
+ irq_chip = _irq_chip;
+ cells = bd9571mwv_cells;
+ num_cells = ARRAY_SIZE(bd9571mwv_cells);
+ break;
+ default:
+ dev_err(dev, "Unsupported device 0x%x\n", ret);
+ return -ENODEV;
+ }
- bd->regmap = devm_regmap_init_i2c(client, _regmap_config);
- if (IS_ERR(bd->regmap)) {
- dev_err(bd->dev, "Failed to initialize register map\n");
- return PTR_ERR(bd->regmap);
+ regmap = devm_regmap_init_i2c(client, regmap_config);
+ if (IS_ERR(regmap)) {
+ dev_err(dev, "Failed to initialize register map\n");
+ return PTR_ERR(regmap);
}
- ret = bd9571mwv_identify(bd);
+ ret = bd957x_identify(dev, regmap);
if (ret)
return ret;
- ret = devm_regmap_add_irq_chip(bd->dev, bd->regmap, bd->irq,
- IRQF_ONESHOT, 0, _irq_chip,
- >irq_data);
+ ret = devm_regmap_add_irq_chip(dev, regmap, irq, IRQF_ONESHOT, 0,
+ irq_chip, _data);
if (ret) {
- dev_err(bd->dev, "Failed to register IRQ chip\n");
+ dev_err(dev, "Failed to register IRQ chip\n");
return ret;
}
- return
[PATCH v7 09/12] mfd: bd9571mwv: Use the SPDX license identifier
Use the SPDX license identifier instead of a local description. Signed-off-by: Yoshihiro Shimoda Reviewed-by: Geert Uytterhoeven Acked-for-MFD-by: Lee Jones --- drivers/mfd/bd9571mwv.c | 10 +- include/linux/mfd/bd9571mwv.h | 10 +- 2 files changed, 2 insertions(+), 18 deletions(-) diff --git a/drivers/mfd/bd9571mwv.c b/drivers/mfd/bd9571mwv.c index 19d57a4..e68c3fa 100644 --- a/drivers/mfd/bd9571mwv.c +++ b/drivers/mfd/bd9571mwv.c @@ -1,17 +1,9 @@ +// SPDX-License-Identifier: GPL-2.0-only /* * ROHM BD9571MWV-M MFD driver * * Copyright (C) 2017 Marek Vasut * - * This program is free software; you can redistribute it and/or - * modify it under the terms of the GNU General Public License version 2 as - * published by the Free Software Foundation. - * - * This program is distributed "as is" WITHOUT ANY WARRANTY of any - * kind, whether expressed or implied; without even the implied warranty - * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License version 2 for more details. - * * Based on the TPS65086 driver */ diff --git a/include/linux/mfd/bd9571mwv.h b/include/linux/mfd/bd9571mwv.h index eb05569..bcc7092 100644 --- a/include/linux/mfd/bd9571mwv.h +++ b/include/linux/mfd/bd9571mwv.h @@ -1,17 +1,9 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ /* * ROHM BD9571MWV-M driver * * Copyright (C) 2017 Marek Vasut * - * This program is free software; you can redistribute it and/or - * modify it under the terms of the GNU General Public License version 2 as - * published by the Free Software Foundation. - * - * This program is distributed "as is" WITHOUT ANY WARRANTY of any - * kind, whether expressed or implied; without even the implied warranty - * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License version 2 for more details. - * * Based on the TPS65086 driver */ -- 2.7.4
[PATCH v7 02/12] dt-bindings: mfd: bd9571mwv: Document BD9574MWF
Document other similar specification chip BD9574MWF. Signed-off-by: Yoshihiro Shimoda --- Documentation/devicetree/bindings/mfd/bd9571mwv.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/mfd/bd9571mwv.txt b/Documentation/devicetree/bindings/mfd/bd9571mwv.txt index 8c46786..1d6413e 100644 --- a/Documentation/devicetree/bindings/mfd/bd9571mwv.txt +++ b/Documentation/devicetree/bindings/mfd/bd9571mwv.txt @@ -1,7 +1,7 @@ -* ROHM BD9571MWV Power Management Integrated Circuit (PMIC) bindings +* ROHM BD9571MWV/BD9574MWF Power Management Integrated Circuit (PMIC) bindings Required properties: - - compatible : Should be "rohm,bd9571mwv". + - compatible : Should be "rohm,bd9571mwv" or "rohm,bd9574mwf". - reg : I2C slave address. - interrupts : The interrupt line the device is connected to. - interrupt-controller: Marks the device node as an interrupt controller. -- 2.7.4
[PATCH v7 06/12] gpio: bd9571mwv: Use the SPDX license identifier
Use the SPDX license identifier instead of a local description. Signed-off-by: Yoshihiro Shimoda Reviewed-by: Geert Uytterhoeven --- drivers/gpio/gpio-bd9571mwv.c | 10 +- 1 file changed, 1 insertion(+), 9 deletions(-) diff --git a/drivers/gpio/gpio-bd9571mwv.c b/drivers/gpio/gpio-bd9571mwv.c index c0abc9c..abb622c 100644 --- a/drivers/gpio/gpio-bd9571mwv.c +++ b/drivers/gpio/gpio-bd9571mwv.c @@ -1,17 +1,9 @@ +// SPDX-License-Identifier: GPL-2.0-only /* * ROHM BD9571MWV-M GPIO driver * * Copyright (C) 2017 Marek Vasut * - * This program is free software; you can redistribute it and/or - * modify it under the terms of the GNU General Public License version 2 as - * published by the Free Software Foundation. - * - * This program is distributed "as is" WITHOUT ANY WARRANTY of any - * kind, whether expressed or implied; without even the implied warranty - * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License version 2 for more details. - * * Based on the TPS65086 driver * * NOTE: Interrupts are not supported yet. -- 2.7.4
[PATCH v7 05/12] regulator: bd9571mwv: Add BD9574MWF support
Add support for BD9574MWF which is similar chip with BD9571MWV.
Note that we don't support voltage rails VD{09,18,25,33} by this
driver on BD9574. The VD09 voltage could be read from PMIC but that
is not supported by this commit.
Signed-off-by: Yoshihiro Shimoda
Reviewed-by: Matti Vaittinen
---
drivers/regulator/bd9571mwv-regulator.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/regulator/bd9571mwv-regulator.c
b/drivers/regulator/bd9571mwv-regulator.c
index 42b6a70..7b0cd08 100644
--- a/drivers/regulator/bd9571mwv-regulator.c
+++ b/drivers/regulator/bd9571mwv-regulator.c
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0
/*
- * ROHM BD9571MWV-M regulator driver
+ * ROHM BD9571MWV-M and BD9574MWF-M regulator driver
*
* Copyright (C) 2017 Marek Vasut
*
@@ -9,6 +9,7 @@
* NOTE: VD09 is missing
*/
+#include
#include
#include
#include
@@ -277,6 +278,7 @@ static int bd9571mwv_regulator_probe(struct platform_device
*pdev)
struct regulator_dev *rdev;
unsigned int val;
int i;
+ enum rohm_chip_type chip = platform_get_device_id(pdev)->driver_data;
bdreg = devm_kzalloc(>dev, sizeof(*bdreg), GFP_KERNEL);
if (!bdreg)
@@ -292,6 +294,9 @@ static int bd9571mwv_regulator_probe(struct platform_device
*pdev)
config.regmap = bdreg->regmap;
for (i = 0; i < ARRAY_SIZE(regulators); i++) {
+ /* BD9574MWF supports DVFS only */
+ if (chip == ROHM_CHIP_TYPE_BD9574 && regulators[i].id != DVFS)
+ continue;
rdev = devm_regulator_register(>dev, [i],
);
if (IS_ERR(rdev)) {
@@ -339,7 +344,8 @@ static int bd9571mwv_regulator_probe(struct platform_device
*pdev)
}
static const struct platform_device_id bd9571mwv_regulator_id_table[] = {
- { "bd9571mwv-regulator", },
+ { "bd9571mwv-regulator", ROHM_CHIP_TYPE_BD9571 },
+ { "bd9574mwf-regulator", ROHM_CHIP_TYPE_BD9574 },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(platform, bd9571mwv_regulator_id_table);
--
2.7.4
[PATCH v7 00/12] treewide: bd9571mwv: Add support for BD9574MWF
Add BD9574MWF support into bd9571mwv gpio, mfd and regulator drivers. Latest Ebisu-4D boards has this chip instead of BD9571MWV so that we need this patch series to detect this chip at runtime. Note that the patch [1/12] is a bug-fix patch for mfd driver. Changes from v6: - Remove "struct bd957x_ddata" because this is not used after probed. - Add "Acked-for-MFD-by" in patch 12. https://patchwork.kernel.org/project/linux-renesas-soc/list/?series=405725 Changes from v5: - Fix typo in the patch 5 and 8. https://patchwork.kernel.org/project/linux-renesas-soc/list/?series=405263 Changes from v4: - Add Reviwed-by in patch 1, 10, 11 and 12. - Keep bd9571mwv_id_table[] as-is because unused in patch 12. https://patchwork.kernel.org/project/linux-renesas-soc/list/?series=404657 Changes from v3: - Add "Acked-for-MFD-by" in patch 1, 3, 9 and 10. - Use "Co-developed-by" instead in patch 11. - In patch 11: -- Remove abusing kernel-doc formatting in patch. -- Rename bd957x_data with bd957x_ddata in patch. -- Remove product name printk. -- Rename bd9571mwv_identify() with bd957x_identify(). -- Remove argument "part_name" from bd957x_identify(). -- Modify dev_err() string. -- Rename BD9571MWV_PRODUCT_CODE_VAL with BD9571MWV_PRODUCT_CODE_BD9571MWV. -- Fix errno from -ENOENT to -ENODEV. - In patch 12: -- Rename "MFD driver" to "core driver". -- Remove unnecessary comments. -- Rename BD9574MWF_PRODUCT_CODE_VAL with BD9571MWV_PRODUCT_CODE_BD9574MWF. https://patchwork.kernel.org/project/linux-renesas-soc/list/?series=402719 Changes from v2: - Use devm_mfd_add_devices() to remove the mfd device in unload. - Update commit descriptions in patch 4 and 8. - Use regmap_get_device() to simplify in patch 4. - Remove "struct bd9571mwv" and bd9571mwv_remove(). - Add Reviewed-by in patch 3 to 9. - Use devm_regmap_add_irq_chip() to simplify in patch 10. https://patchwork.kernel.org/project/linux-renesas-soc/list/?series=400477 Changes from v1: - Document BD9574MWF on the dt-binding. - Add ROHM_CHIP_TYPE_BD957[14] into rohm-generic.h. - To simplify gpio and regulator drivers, using regmap instead of using struct bd9571mwv. - Remove BD9574MWF definitions to make gpio and regulator driver simple to support for BD9574MWF. - Add BD9574MWF support for gpio and regulator drivers. - Add missing regmap ranges for BD9574MWF. - Rename "part_number" with "part_name". https://patchwork.kernel.org/project/linux-renesas-soc/list/?series=398059 Khiem Nguyen (2): mfd: bd9571mwv: Make the driver more generic mfd: bd9571mwv: Add support for BD9574MWF Yoshihiro Shimoda (10): mfd: bd9571mwv: Use devm_mfd_add_devices() dt-bindings: mfd: bd9571mwv: Document BD9574MWF mfd: rohm-generic: Add BD9571 and BD9574 regulator: bd9571mwv: rid of using struct bd9571mwv regulator: bd9571mwv: Add BD9574MWF support gpio: bd9571mwv: Use the SPDX license identifier gpio: bd9571mwv: rid of using struct bd9571mwv gpio: bd9571mwv: Add BD9574MWF support mfd: bd9571mwv: Use the SPDX license identifier mfd: bd9571mwv: Use devm_regmap_add_irq_chip() .../devicetree/bindings/mfd/bd9571mwv.txt | 4 +- drivers/gpio/gpio-bd9571mwv.c | 35 ++-- drivers/mfd/bd9571mwv.c| 178 ++--- drivers/regulator/bd9571mwv-regulator.c| 59 --- include/linux/mfd/bd9571mwv.h | 45 ++ include/linux/mfd/rohm-generic.h | 2 + 6 files changed, 186 insertions(+), 137 deletions(-) -- 2.7.4
Re: [PATCH v23 01/15] mm: Introduce Data Access MONitor (DAMON)
On Wed, 23 Dec 2020 14:49:57 -0800 Shakeel Butt wrote: > On Wed, Dec 23, 2020 at 8:34 AM SeongJae Park wrote: > [snip] > > > Overall the patch looks good to me. Two concerns I have are if we > > > should damon_callback here or with the real user and the regions part > > > of primitive abstraction. For the first one, I don't have any strong > > > opinion but for the second one I do. > > > > I'd like to keep 'damon_callback' part here, to let API users know how the > > monitoring result will be available to them. > > > > For the 'regions' part, I will rename relevant things as below in the next > > version, to reduce any confusion. > > > > init_target_regions() -> init() > > update_target_regions() -> update() > > regions_update_interval -> update_interval > > last_regions_update -> last_update > > > > > > > > More specifically the question is if sampling and adaptive region > > > adjustment are general enough to be part of core monitoring context? > > > Can you give an example of a different primitive/use-case where these > > > would be beneficial. > > > > I think all adress spaces having some spatial locality and monitoring > > requests > > that need to have upper-bound overhead and best-effort accuracy could get > > benefit from it. The primitives targetting 'virtual address spaces' and the > > 'physical address space' clearly showed the benefit. > > I am still not much convinced on the 'physical address space' use-case > or the way you are presenting it. I understand the concern. I also once thought the mechanism might not work well for the physical address space because we cannot expect much spatial locality in the space. However, it turned out that there is some (temporal) spatial locality that enough to make DAMON work reasonably well. The word, 'reasonably well' might be controversial. With the mechanism, DAMON provides only 'best-effort' accuracy, rather than 100% accuracy. Our goal is to make the information accurate enough only for DRAM-centric optimizations. I'd like to also note that there are knobs that you can use to make minimum quality higher (nr_min_regions) while setting the upperbound of the monitoring overhead (nr_max_regions). What I can say for now is that we ran DAMON for physical address space of our production systems (shared detail in the 'Real-workd User Story' section of coverletter[1]) and the result was reasonable enough to convince the owner of the systems. [1] https://lore.kernel.org/linux-mm/20201215115448.25633-1-sjp...@amazon.com/ > Anyways I think we start with what you have and if in future there is a > use-case where regions adjustment does not make sense, we can change it then. 100% agreed, and thank you for understanding my argument. Thanks, SeongJae Park
[PATCH] bpf: fix: address of local auto-variable assigned to a function parameter.
Assigning local variable txq to the outputting parameter xdp->txq is not
safe, txq will be released after the end of the function call.
Then the result of using xdp is unpredictable.
Fix this error by defining the struct xdp_txq_info in function
dev_map_run_prog() as a static type.
Signed-off-by: YANG LI
Reported-by: Abaci
---
kernel/bpf/devmap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/bpf/devmap.c b/kernel/bpf/devmap.c
index f6e9c68..af6f004 100644
--- a/kernel/bpf/devmap.c
+++ b/kernel/bpf/devmap.c
@@ -454,7 +454,7 @@ static struct xdp_buff *dev_map_run_prog(struct net_device
*dev,
struct xdp_buff *xdp,
struct bpf_prog *xdp_prog)
{
- struct xdp_txq_info txq = { .dev = dev };
+ static struct xdp_txq_info txq = { .dev = dev };
u32 act;
xdp_set_data_meta_invalid(xdp);
--
1.8.3.1
Re: [PATCH V4 1/2] mfd: qcom-spmi-pmic: Convert bindings to .yaml format
On 2020-12-20 05:17, Stephen Boyd wrote:
Quoting Kiran Gunda (2020-12-18 00:14:51)
Convert the bindings from .txt to .yaml format.
Signed-off-by: Kiran Gunda
---
.../devicetree/bindings/mfd/qcom,spmi-pmic.txt | 80
-
.../devicetree/bindings/mfd/qcom,spmi-pmic.yaml| 127
+
2 files changed, 127 insertions(+), 80 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.txt
create mode 100644
Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml
diff --git a/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.txt
b/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.txt
deleted file mode 100644
index 79367a4..000
--- a/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.txt
+++ /dev/null
@@ -1,80 +0,0 @@
- Qualcomm SPMI PMICs multi-function device bindings
-
-The Qualcomm SPMI series presently includes PM8941, PM8841 and
PMA8084
-PMICs. These PMICs use a QPNP scheme through SPMI interface.
-QPNP is effectively a partitioning scheme for dividing the SPMI
extended
-register space up into logical pieces, and set of fixed register
-locations/definitions within these regions, with some of these
regions
-specifically used for interrupt handling.
-
-The QPNP PMICs are used with the Qualcomm Snapdragon series SoCs, and
are
-interfaced to the chip via the SPMI (System Power Management
Interface) bus.
-Support for multiple independent functions are implemented by
splitting the
-16-bit SPMI slave address space into 256 smaller fixed-size regions,
256 bytes
-each. A function can consume one or more of these fixed-size register
regions.
-
-Required properties:
-- compatible: Should contain one of:
- "qcom,pm8941",
- "qcom,pm8841",
- "qcom,pma8084",
- "qcom,pm8019",
- "qcom,pm8226",
- "qcom,pm8110",
- "qcom,pma8084",
- "qcom,pmi8962",
- "qcom,pmd9635",
- "qcom,pm8994",
- "qcom,pmi8994",
- "qcom,pm8916",
- "qcom,pm8004",
- "qcom,pm8909",
- "qcom,pm8950",
- "qcom,pmi8950",
- "qcom,pm8998",
- "qcom,pmi8998",
- "qcom,pm8005",
- or generalized "qcom,spmi-pmic".
-- reg: Specifies the SPMI USID slave address for this
device.
- For more information see:
- Documentation/devicetree/bindings/spmi/spmi.yaml
-
-Required properties for peripheral child nodes:
-- compatible: Should contain "qcom,xxx", where "xxx" is a
peripheral name.
-
-Optional properties for peripheral child nodes:
-- interrupts: Interrupts are specified as a 4-tuple. For more
information
- see:
-
Documentation/devicetree/bindings/spmi/qcom,spmi-pmic-arb.txt
-- interrupt-names: Corresponding interrupt name to the interrupts
property
-
-Each child node of SPMI slave id represents a function of the PMIC.
In the
-example below the rtc device node represents a peripheral of pm8941
-SID = 0. The regulator device node represents a peripheral of pm8941
SID = 1.
-
-Example:
-
- spmi {
- compatible = "qcom,spmi-pmic-arb";
-
- pm8941@0 {
- compatible = "qcom,pm8941", "qcom,spmi-pmic";
- reg = <0x0 SPMI_USID>;
-
- rtc {
- compatible = "qcom,rtc";
- interrupts = <0x0 0x61 0x1
IRQ_TYPE_EDGE_RISING>;
- interrupt-names = "alarm";
- };
- };
-
- pm8941@1 {
- compatible = "qcom,pm8941", "qcom,spmi-pmic";
- reg = <0x1 SPMI_USID>;
-
- regulator {
- compatible = "qcom,regulator";
- regulator-name = "8941_boost";
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml
b/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml
new file mode 100644
index 000..e458dd1
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml
@@ -0,0 +1,127 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/qcom,spmi-pmic.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SPMI PMICs multi-function device bindings
+
+maintainers:
+ - Stephen Boyd
Someone at Qualcomm should be the maintainer here. Maybe you?
+
+description: |
+ The Qualcomm SPMI PMICs use a QPNP scheme through SPMI interface.
What is QPNP?
Qualcomm Plug And Play.
+ QPNP is effectively a partitioning scheme for dividing the
Re: [PATCH V4 1/2] mfd: qcom-spmi-pmic: Convert bindings to .yaml format
On 2020-12-21 14:20, Lee Jones wrote: On Fri, 18 Dec 2020, Kiran Gunda wrote: Convert the bindings from .txt to .yaml format. Signed-off-by: Kiran Gunda --- .../devicetree/bindings/mfd/qcom,spmi-pmic.txt | 80 - .../devicetree/bindings/mfd/qcom,spmi-pmic.yaml| 127 + 2 files changed, 127 insertions(+), 80 deletions(-) delete mode 100644 Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.txt create mode 100644 Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml What are the other patches that I was not cc'ed on? Generally it's a bad idea to send only some patches of a set to some maintainers. Best for everyone to have full visibility. I ran the get_maintainer.pl script. Not sure how it is missed. Anyways I will add you in the next post. Also looks like you're missing a cover-letter [PATCH 0/4] which adds to the opaqueness/confusion. I have introduced the cover letter from V3 series. That's why the earlier notes are missing from cover letter. Let me add them in next series.
Re: [PATCH v2 28/48] soc/tegra: Introduce core power domain driver
On 23-12-20, 23:37, Dmitry Osipenko wrote: > 23.12.2020 08:57, Viresh Kumar пишет: > > What's wrong with getting the regulator in the driver as well ? Apart from > > the > > OPP core ? > > The voltage syncing should be done for each consumer regulator > individually [1]. > > Secondly, regulator core doesn't work well today if the same regulator > is requested more than one time for the same device. Hmm... > >> will return the OPP table regulator in order to allow driver to use the > >> regulator directly. But I'm not sure whether this is a much better > >> option than the opp_sync_regulators() and opp_set_voltage() APIs. > > > > set_voltage() is still fine as there is some data that the OPP core has, but > > sync_regulator() has nothing to do with OPP core. > > > > And this may lead to more wrapper helpers in the OPP core, which I am > > afraid of. > > And so even if it is not the best, I would like the OPP core to provide the > > data > > and not get into this. Ofcourse there is an exception to this, opp_set_rate. > > > > The regulator_sync_voltage() should be invoked only if voltage was > changed previously [1]. > > The OPP core already has the info about whether voltage was changed and > it provides the necessary locking for both set_voltage() and > sync_regulator(). Perhaps I'll need to duplicate that functionality in > the PD driver, instead of making it all generic and re-usable by other > drivers. > > [1] > https://elixir.bootlin.com/linux/v5.10.2/source/drivers/regulator/core.c#L4107 Lets do it in the OPP core and see where we go. -- viresh
RE: [PATCH v6 11/12] mfd: bd9571mwv: Make the driver more generic
Hi Lee,
> From: Lee Jones, Sent: Thursday, December 24, 2020 12:39 AM
> On Wed, 23 Dec 2020, Yoshihiro Shimoda wrote:
> > From: Khiem Nguyen
> >
> > Since the driver supports BD9571MWV PMIC only, this patch makes
> > the functions and data structure become more generic so that
> > it can support other PMIC variants as well. Also remove printing
> > part name which Lee Jones suggested.
> >
> > Signed-off-by: Khiem Nguyen
> > Co-developed-by: Yoshihiro Shimoda
> > Signed-off-by: Yoshihiro Shimoda
> > Reviewed-by: Matti Vaittinen
> > ---
> > drivers/mfd/bd9571mwv.c | 89
> > +--
> > include/linux/mfd/bd9571mwv.h | 18 +
> > 2 files changed, 54 insertions(+), 53 deletions(-)
>
> Couple of small points.
>
> Remainder looks good.
Thank you for your review!
> > diff --git a/drivers/mfd/bd9571mwv.c b/drivers/mfd/bd9571mwv.c
> > index 49e968e..c905ab4 100644
> > --- a/drivers/mfd/bd9571mwv.c
> > +++ b/drivers/mfd/bd9571mwv.c
> > @@ -3,6 +3,7 @@
> > * ROHM BD9571MWV-M MFD driver
> > *
> > * Copyright (C) 2017 Marek Vasut
> > + * Copyright (C) 2020 Renesas Electronics Corporation
> > *
> > * Based on the TPS65086 driver
> > */
> > @@ -14,6 +15,14 @@
> >
> > #include
> >
> > +/* Driver data to distinguish bd957x variants */
> > +struct bd957x_ddata {
> > + const struct regmap_config *regmap_config;
> > + const struct regmap_irq_chip *irq_chip;
>
> > + const struct mfd_cell *cells;
> > + int num_cells;
>
> Are you using these post-probe?
>
> If not, they're not ddata.
I'm not using all these members post-probe.
So, I'll remove ddata.
> > static int bd9571mwv_probe(struct i2c_client *client,
> > - const struct i2c_device_id *ids)
> > + const struct i2c_device_id *ids)
> > {
> > - struct bd9571mwv *bd;
> > - int ret;
> > -
> > - bd = devm_kzalloc(>dev, sizeof(*bd), GFP_KERNEL);
> > - if (!bd)
> > - return -ENOMEM;
> > -
> > - i2c_set_clientdata(client, bd);
> > - bd->dev = >dev;
> > - bd->irq = client->irq;
> > + const struct bd957x_ddata *ddata;
> > + struct device *dev = >dev;
> > + struct regmap *regmap;
> > + struct regmap_irq_chip_data *irq_data;
> > + int ret, irq = client->irq;
> > +
> > + /* Read the PMIC product code */
> > + ret = i2c_smbus_read_byte_data(client, BD9571MWV_PRODUCT_CODE);
> > + if (ret < 0) {
> > + dev_err(dev, "Failed to read product code\n");
> > + return ret;
> > + }
>
> Nit: '\n' here.
I got it. I'll add a blank line here.
> > + switch (ret) {
> > + case BD9571MWV_PRODUCT_CODE_BD9571MWV:
> > + ddata = _ddata;
>
> Simply declare 'const struct mfd_cell *cells' locally in probe and
> assign it here instead.
I got it. I'll also add "const struct regmap_config *regmap_config;"
and "const struct regmap_irq_chip *irq_chip;" locally in probe.
Best regards,
Yoshihiro Shimoda
Re: [PATCH v2 11/48] opp: Add dev_pm_opp_find_level_ceil()
On 23-12-20, 23:37, Dmitry Osipenko wrote: > 23.12.2020 07:19, Viresh Kumar пишет: > > On 22-12-20, 22:15, Dmitry Osipenko wrote: > >> 22.12.2020 09:42, Viresh Kumar пишет: > >>> On 17-12-20, 21:06, Dmitry Osipenko wrote: > Add a ceil version of the dev_pm_opp_find_level(). It's handy to have if > levels don't start from 0 in OPP table and zero usually means a minimal > level. > > Signed-off-by: Dmitry Osipenko > >>> > >>> Why doesn't the exact version work for you here ? > >>> > >> > >> The exact version won't find OPP for level=0 if levels don't start with > >> 0, where 0 means that minimal level is desired. > > > > Right, but why do you need to send 0 for your platform ? > > > > To put power domain into the lowest performance state when device is idling. I see. So you really want to set it to the lowest state or just take the vote out ? Which may end up powering off the domain in the worst case ? -- viresh
Re: [PATCH v1 0/6] no-copy bvec
On Wed, Dec 23, 2020 at 08:32:45PM +, Pavel Begunkov wrote: > On 23/12/2020 20:23, Douglas Gilbert wrote: > > On 2020-12-23 11:04 a.m., James Bottomley wrote: > >> On Wed, 2020-12-23 at 15:51 +, Christoph Hellwig wrote: > >>> On Wed, Dec 23, 2020 at 12:52:59PM +, Pavel Begunkov wrote: > Can scatterlist have 0-len entries? Those are directly translated > into bvecs, e.g. in nvme/target/io-cmd-file.c and > target/target_core_file.c. I've audited most of others by this > moment, they're fine. > >>> > >>> For block layer SGLs we should never see them, and for nvme neither. > >>> I think the same is true for the SCSI target code, but please double > >>> check. > >> > >> Right, no-one ever wants to see a 0-len scatter list entry.?? The reason > >> is that every driver uses the sgl to program the device DMA engine in > >> the way NVME does.?? a 0 length sgl would be a dangerous corner case: > >> some DMA engines would ignore it and others would go haywire, so if we > >> ever let a 0 length list down into the driver, they'd have to > >> understand the corner case behaviour of their DMA engine and filter it > >> accordingly, which is why we disallow them in the upper levels, since > >> they're effective nops anyway. > > > > When using scatter gather lists at the far end (i.e. on the storage device) > > the T10 examples (WRITE SCATTERED and POPULATE TOKEN in SBC-4) explicitly > > allow the "number of logical blocks" in their sgl_s to be zero and state > > that it is _not_ to be considered an error. > > It's fine for my case unless it leaks them out of device driver to the > net/block layer/etc. Is it? None of the SCSI Command mentions above are supported by Linux, nevermind mapped to struct scatterlist.
[PATCH] iommu/io-pgtable-arm: Allow non-coherent masters to use system cache
commit ecd7274fb4cd ("iommu: Remove unused IOMMU_SYS_CACHE_ONLY flag")
removed unused IOMMU_SYS_CACHE_ONLY prot flag and along with it went
the memory type setting required for the non-coherent masters to use
system cache. Now that system cache support for GPU is added, we will
need to mark the memory as normal sys-cached for GPU to use system cache.
Without this, the system cache lines are not allocated for GPU. We use
the IO_PGTABLE_QUIRK_ARM_OUTER_WBWA quirk instead of a page protection
flag as the flag cannot be exposed via DMA api because of no in-tree
users.
Signed-off-by: Sai Prakash Ranjan
---
drivers/iommu/io-pgtable-arm.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
index 7c9ea9d7874a..3fb7de8304a2 100644
--- a/drivers/iommu/io-pgtable-arm.c
+++ b/drivers/iommu/io-pgtable-arm.c
@@ -415,6 +415,9 @@ static arm_lpae_iopte arm_lpae_prot_to_pte(struct
arm_lpae_io_pgtable *data,
else if (prot & IOMMU_CACHE)
pte |= (ARM_LPAE_MAIR_ATTR_IDX_CACHE
<< ARM_LPAE_PTE_ATTRINDX_SHIFT);
+ else if (data->iop.cfg.quirks & IO_PGTABLE_QUIRK_ARM_OUTER_WBWA)
+ pte |= (ARM_LPAE_MAIR_ATTR_IDX_INC_OCACHE
+ << ARM_LPAE_PTE_ATTRINDX_SHIFT);
}
if (prot & IOMMU_CACHE)
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
Re: [PATCH] clocksource: clint: Avoid remove __iomem in get_cycles_hi()
On Wed, Dec 23, 2020 at 06:59:34PM -0800, Palmer Dabbelt wrote: > Aren't we OK with lines longer than 80 characters now? Or was that some other > project? checkpatch doesn't complain, which I guess is why I didn't notice, > so > hopefully that means I'm not crazy (though I guess the commit message and > title > don't provide the best argument there... ;)). They are allowed as an exception, not the norm. Take a look at the coding style document. And checkpath has for a while not been doing the right thing unfortunately.
Re: [PATCH v2 19/48] opp: Fix adding OPP entries in a wrong order if rate is unavailable
On 23-12-20, 23:36, Dmitry Osipenko wrote:
> 23.12.2020 07:34, Viresh Kumar пишет:
> > On 22-12-20, 22:19, Dmitry Osipenko wrote:
> >> 22.12.2020 12:12, Viresh Kumar пишет:
> >>> rate will be 0 for both the OPPs here if rate_not_available is true and
> >>> so this
> >>> change shouldn't be required.
> >>
> >> The rate_not_available is negated in the condition. This change is
> >> required because both rates are 0 and then we should proceed to the
> >> levels comparison.
> >
> > Won't that happen without this patch ?
>
> No
This is how the code looks like currently:
int _opp_compare_key(struct dev_pm_opp *opp1, struct dev_pm_opp *opp2)
{
if (opp1->rate != opp2->rate)
return opp1->rate < opp2->rate ? -1 : 1;
if (opp1->bandwidth && opp2->bandwidth &&
opp1->bandwidth[0].peak != opp2->bandwidth[0].peak)
return opp1->bandwidth[0].peak < opp2->bandwidth[0].peak ? -1 :
1;
if (opp1->level != opp2->level)
return opp1->level < opp2->level ? -1 : 1;
return 0;
}
Lets consider the case you are focussing on, where rate is 0 for both the OPPs,
bandwidth isn't there and we want to run the level comparison here.
Since both the rates are 0, (opp1->rate != opp2->rate) will fail and so we will
move to bandwidth check which will fail too. And so we will get to the level
comparison.
What am I missing here ? I am sure there is something for sure as you won't have
missed this..
--
viresh
drivers/clocksource/timer-clint.c:72:24: sparse: sparse: cast removes address space '__iomem' of expression
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 58cf05f597b03a8212d9ecf2c79ee046d3ee8ad9
commit: 2ac6795fcc085e8d03649f1bbd0d70aaff612cad clocksource/drivers: Add CLINT
timer driver
date: 4 months ago
config: riscv-randconfig-s031-20201221 (attached as .config)
compiler: riscv32-linux-gcc (GCC) 9.3.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# apt-get install sparse
# sparse version: v0.6.3-184-g1b896707-dirty
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2ac6795fcc085e8d03649f1bbd0d70aaff612cad
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 2ac6795fcc085e8d03649f1bbd0d70aaff612cad
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1
CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=riscv
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
"sparse warnings: (new ones prefixed by >>)"
>> drivers/clocksource/timer-clint.c:72:24: sparse: sparse: cast removes
>> address space '__iomem' of expression
>> drivers/clocksource/timer-clint.c:72:24: sparse: sparse: incorrect type in
>> argument 1 (different address spaces) @@ expected void const volatile
>> [noderef] __iomem *addr @@ got unsigned int [usertype] * @@
drivers/clocksource/timer-clint.c:72:24: sparse: expected void const
volatile [noderef] __iomem *addr
drivers/clocksource/timer-clint.c:72:24: sparse: got unsigned int
[usertype] *
drivers/clocksource/timer-clint.c:70:22: sparse: sparse: cast removes
address space '__iomem' of expression
drivers/clocksource/timer-clint.c:70:22: sparse: sparse: incorrect type in
argument 1 (different address spaces) @@ expected void const volatile
[noderef] __iomem *addr @@ got unsigned int [usertype] * @@
drivers/clocksource/timer-clint.c:70:22: sparse: expected void const
volatile [noderef] __iomem *addr
drivers/clocksource/timer-clint.c:70:22: sparse: got unsigned int
[usertype] *
drivers/clocksource/timer-clint.c:219:36: sparse: sparse: incorrect type in
argument 2 (different address spaces) @@ expected void * @@ got struct
clock_event_device [noderef] __percpu * @@
drivers/clocksource/timer-clint.c:219:36: sparse: expected void *
drivers/clocksource/timer-clint.c:219:36: sparse: got struct
clock_event_device [noderef] __percpu *
vim +/__iomem +72 drivers/clocksource/timer-clint.c
58
59 #ifdef CONFIG_64BIT
60 static u64 notrace clint_get_cycles64(void)
61 {
62 return clint_get_cycles();
63 }
64 #else /* CONFIG_64BIT */
65 static u64 notrace clint_get_cycles64(void)
66 {
67 u32 hi, lo;
68
69 do {
70 hi = clint_get_cycles_hi();
71 lo = clint_get_cycles();
> 72 } while (hi != clint_get_cycles_hi());
73
74 return ((u64)hi << 32) | lo;
75 }
76 #endif /* CONFIG_64BIT */
77
---
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] net/mlx5e: remove h from printk format specifier
On Wed, Dec 23, 2020 at 11:45:12AM -0800, t...@redhat.com wrote:
> From: Tom Rix
>
> This change fixes the checkpatch warning described in this commit
> commit cbacb5ab0aa0 ("docs: printk-formats: Stop encouraging use of
> unnecessary %h[xudi] and %hh[xudi]")
>
> Standard integer promotion is already done and %hx and %hhx is useless
> so do not encourage the use of %hh[xudi] or %h[xudi].
>
> Signed-off-by: Tom Rix
> ---
> drivers/net/ethernet/mellanox/mlx5/core/en/params.c | 2 +-
> drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 4 ++--
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
Thanks,
Reviewed-by: Leon Romanovsky
Re: [PATCH -next] mlx5: use DEFINE_MUTEX (and mutex_init() had been too late)
On Wed, Dec 23, 2020 at 10:12:23PM +0800, Zheng Yongjun wrote:
> Signed-off-by: Zheng Yongjun
> ---
> drivers/infiniband/hw/mlx5/main.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
It is unclear what you wanted to achieve, because the commit message is
missing and subject doesn't help either.
Anyway, this code was changed in the commit f22c30aa6d27
("RDMA/mlx5: Move xlt_emergency_page_mutex into mr.c")
Thanks
Re: [PATCH] bcache: set pdev_set_uuid before scond loop iteration
On 12/24/20 9:53 AM, Yi Li wrote:
> There is no need to reassign pdev_set_uuid in the second loop iteration,
> so move it to the place before second loop.
>
> Signed-off-by: Yi Li
Added into my for-next directory. Thanks.
Coly Li
> ---
> drivers/md/bcache/super.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/md/bcache/super.c b/drivers/md/bcache/super.c
> index a4752ac410dc..6aa23a6fb394 100644
> --- a/drivers/md/bcache/super.c
> +++ b/drivers/md/bcache/super.c
> @@ -2644,8 +2644,8 @@ static ssize_t bch_pending_bdevs_cleanup(struct kobject
> *k,
> }
>
> list_for_each_entry_safe(pdev, tpdev, _devs, list) {
> + char *pdev_set_uuid = pdev->dc->sb.set_uuid;
> list_for_each_entry_safe(c, tc, _cache_sets, list) {
> - char *pdev_set_uuid = pdev->dc->sb.set_uuid;
> char *set_uuid = c->set_uuid;
>
> if (!memcmp(pdev_set_uuid, set_uuid, 16)) {
>
Re: [ANNOUNCE] Git v2.30.0-rc2
Most of the suggestions below are found by GMail. On Thu, Dec 24, 2020 at 12:08 AM Junio C Hamano wrote: > > A release candidate Git v2.30.0-rc2 is now available for testing > at the usual places. It is comprised of 19 non-merge commits since Maybe: s/is comprised of/comprises/ > v2.30.0-rc1, contributed by 5 people, none of which are new faces. [..] > * Various subcommands of "git config" that takes value_regex s/takes/take/ >learn the "--literal-value" option to take the value_regex option s/learn/learned/ >as a literal string. [...] > * More preliminary tests have been added to document desired outcome s/outcome/outcomes/ > of various "directory rename" situations. [...] > * The code to see if "git stash drop" can safely remove refs/stash >has been made more carerful. s/carerful/careful/ >(merge 4f44c5659b rs/empty-reflog-check-fix later to maint). [...] > * Since jgit does not yet work with SHA-256 repositories, mark the >tests that uses it not to run unless we are testing with ShA-1 s/uses/use/ >repositories. >(merge ea699b4adc sg/t5310-jgit-wants-sha1 later to maint). [...] > * "git apply" adjusted the permission bits of working-tree files and >directories according core.sharedRepository setting by mistake and s/according/according to/ >for a long time, which has been corrected. >(merge eb3c027e17 mt/do-not-use-scld-in-working-tree later to maint). [...] > * "git pack-redandant" when there is only one packfile used to crash, s/pack-redandant/pack-redundant/ >which has been corrected. >(merge 0696232390 jx/pack-redundant-on-single-pack later to maint).
[PATCH v5 4/5] crypto: hisilicon/hpre - add 'ECDH' algorithm
1. Add some new 'ECDH' curve parameter definitions to
'include/crypto/ecc_curve_defs.h', and reorder ECC 'Curves IDs'
in 'include/crypto/ecdh.h';
2. Enable 'ECDH' algorithm in Kunpeng 930.
Signed-off-by: Meng Yu
Reviewed-by: Zaibo Xu
---
crypto/ecc.c| 4 +-
crypto/testmgr.h| 12 +-
drivers/crypto/hisilicon/hpre/hpre.h| 2 +-
drivers/crypto/hisilicon/hpre/hpre_crypto.c | 502 +++-
drivers/crypto/hisilicon/hpre/hpre_main.c | 1 +
include/crypto/ecc_curve_defs.h | 149 +++--
include/crypto/ecdh.h | 5 +-
7 files changed, 638 insertions(+), 37 deletions(-)
diff --git a/crypto/ecc.c b/crypto/ecc.c
index f23efdd..6adcae2 100644
--- a/crypto/ecc.c
+++ b/crypto/ecc.c
@@ -46,9 +46,9 @@ static inline const struct ecc_curve *ecc_get_curve(unsigned
int curve_id)
switch (curve_id) {
/* In FIPS mode only allow P256 and higher */
case ECC_CURVE_NIST_P192:
- return fips_enabled ? NULL : _p192;
+ return fips_enabled ? NULL :
_curve_list[ECC_CURVE_NIST_P192 - 1];
case ECC_CURVE_NIST_P256:
- return _p256;
+ return _curve_list[ECC_CURVE_NIST_P256 - 1];
default:
return NULL;
}
diff --git a/crypto/testmgr.h b/crypto/testmgr.h
index 8c83811..7fe0fb9 100644
--- a/crypto/testmgr.h
+++ b/crypto/testmgr.h
@@ -2307,12 +2307,12 @@ static const struct kpp_testvec ecdh_tv_template[] = {
#ifdef __LITTLE_ENDIAN
"\x02\x00" /* type */
"\x28\x00" /* len */
- "\x02\x00" /* curve_id */
+ "\x03\x00" /* curve_id */
"\x20\x00" /* key_size */
#else
"\x00\x02" /* type */
"\x00\x28" /* len */
- "\x00\x02" /* curve_id */
+ "\x00\x03" /* curve_id */
"\x00\x20" /* key_size */
#endif
"\x24\xd1\x21\xeb\xe5\xcf\x2d\x83"
@@ -2351,24 +2351,24 @@ static const struct kpp_testvec ecdh_tv_template[] = {
#ifdef __LITTLE_ENDIAN
"\x02\x00" /* type */
"\x08\x00" /* len */
- "\x02\x00" /* curve_id */
+ "\x03\x00" /* curve_id */
"\x00\x00", /* key_size */
#else
"\x00\x02" /* type */
"\x00\x08" /* len */
- "\x00\x02" /* curve_id */
+ "\x00\x03" /* curve_id */
"\x00\x00", /* key_size */
#endif
.b_secret =
#ifdef __LITTLE_ENDIAN
"\x02\x00" /* type */
"\x28\x00" /* len */
- "\x02\x00" /* curve_id */
+ "\x03\x00" /* curve_id */
"\x20\x00" /* key_size */
#else
"\x00\x02" /* type */
"\x00\x28" /* len */
- "\x00\x02" /* curve_id */
+ "\x00\x03" /* curve_id */
"\x00\x20" /* key_size */
#endif
"\x24\xd1\x21\xeb\xe5\xcf\x2d\x83"
diff --git a/drivers/crypto/hisilicon/hpre/hpre.h
b/drivers/crypto/hisilicon/hpre/hpre.h
index 02193e1..50e6b2e 100644
--- a/drivers/crypto/hisilicon/hpre/hpre.h
+++ b/drivers/crypto/hisilicon/hpre/hpre.h
@@ -83,6 +83,7 @@ enum hpre_alg_type {
HPRE_ALG_KG_CRT = 0x3,
HPRE_ALG_DH_G2 = 0x4,
HPRE_ALG_DH = 0x5,
+ HPRE_ALG_ECC_MUL = 0xD,
};
struct hpre_sqe {
@@ -104,5 +105,4 @@ struct hisi_qp *hpre_create_qp(u8 type);
int hpre_algs_register(struct hisi_qm *qm);
void hpre_algs_unregister(struct hisi_qm *qm);
-
#endif
diff --git a/drivers/crypto/hisilicon/hpre/hpre_crypto.c
b/drivers/crypto/hisilicon/hpre/hpre_crypto.c
index 712bea9..fe2f5ab 100644
--- a/drivers/crypto/hisilicon/hpre/hpre_crypto.c
+++ b/drivers/crypto/hisilicon/hpre/hpre_crypto.c
@@ -2,6 +2,8 @@
/* Copyright (c) 2019 HiSilicon Limited. */
#include
#include
+#include
+#include
#include
#include
#include
@@ -36,6 +38,20 @@ struct hpre_ctx;
#define HPRE_DFX_SEC_TO_US 100
#define HPRE_DFX_US_TO_NS 1000
+/* size in bytes of the n prime */
+#define HPRE_ECC_NIST_P192_N_SIZE 24
+#define HPRE_ECC_NIST_P224_N_SIZE 28
+#define HPRE_ECC_NIST_P256_N_SIZE 32
+#define HPRE_ECC_NIST_P384_N_SIZE 48
+#define HPRE_ECC_NIST_P521_N_SIZE 66
+
+/* size in bytes */
+#define HPRE_ECC_HW256_KSZ_B 32
+#define HPRE_ECC_HW384_KSZ_B 48
+#define HPRE_ECC_HW576_KSZ_B 72
+
+#define HPRE_ECDH_MAX_SZ HPRE_ECC_HW576_KSZ_B
+
typedef void (*hpre_cb)(struct hpre_ctx *ctx, void *sqe);
struct hpre_rsa_ctx {
@@ -61,14 +77,25 @@ struct hpre_dh_ctx {
* else if base if the counterpart public key we
* compute the shared secret
* ZZ = yb^xa mod p; [RFC2631 sec 2.1.1]
+* low address: d--->n, please refer to Hisilicon HPRE UM
*/
- char *xa_p; /* low address: d--->n, please refer to Hisilicon HPRE UM */
+ char *xa_p;
dma_addr_t dma_xa_p;
char *g; /* m */
dma_addr_t dma_g;
};
+struct hpre_ecdh_ctx {
+ /* low address: p->a->k->b */
+ unsigned char *p;
+ dma_addr_t dma_p;
+
+ /* low address: x->y */
+
[PATCH v5 3/5] crypto: expose elliptic curve parameters as Crypto APIs
Move elliptic curves definition to 'include/crypto/ecc_curve_defs.h',
so all can use it,
Signed-off-by: Meng Yu
Reviewed-by: Zaibo Xu
---
crypto/ecc.c| 1 -
crypto/ecc.h| 37 +
crypto/ecc_curve_defs.h | 57 -
crypto/ecrdsa_defs.h| 2 +-
include/crypto/ecc_curve_defs.h | 92 +
5 files changed, 95 insertions(+), 94 deletions(-)
delete mode 100644 crypto/ecc_curve_defs.h
create mode 100644 include/crypto/ecc_curve_defs.h
diff --git a/crypto/ecc.c b/crypto/ecc.c
index c80aa25..f23efdd 100644
--- a/crypto/ecc.c
+++ b/crypto/ecc.c
@@ -35,7 +35,6 @@
#include
#include "ecc.h"
-#include "ecc_curve_defs.h"
typedef struct {
u64 m_low;
diff --git a/crypto/ecc.h b/crypto/ecc.h
index d4e546b..e5afaf3 100644
--- a/crypto/ecc.h
+++ b/crypto/ecc.h
@@ -26,6 +26,8 @@
#ifndef _CRYPTO_ECC_H
#define _CRYPTO_ECC_H
+#include
+
/* One digit is u64 qword. */
#define ECC_CURVE_NIST_P192_DIGITS 3
#define ECC_CURVE_NIST_P256_DIGITS 4
@@ -33,44 +35,9 @@
#define ECC_DIGITS_TO_BYTES_SHIFT 3
-/**
- * struct ecc_point - elliptic curve point in affine coordinates
- *
- * @x: X coordinate in vli form.
- * @y: Y coordinate in vli form.
- * @ndigits: Length of vlis in u64 qwords.
- */
-struct ecc_point {
- u64 *x;
- u64 *y;
- u8 ndigits;
-};
-
#define ECC_POINT_INIT(x, y, ndigits) (struct ecc_point) { x, y, ndigits }
/**
- * struct ecc_curve - definition of elliptic curve
- *
- * @name: Short name of the curve.
- * @g: Generator point of the curve.
- * @p: Prime number, if Barrett's reduction is used for this curve
- * pre-calculated value 'mu' is appended to the @p after ndigits.
- * Use of Barrett's reduction is heuristically determined in
- * vli_mmod_fast().
- * @n: Order of the curve group.
- * @a: Curve parameter a.
- * @b: Curve parameter b.
- */
-struct ecc_curve {
- char *name;
- struct ecc_point g;
- u64 *p;
- u64 *n;
- u64 *a;
- u64 *b;
-};
-
-/**
* ecc_is_key_valid() - Validate a given ECDH private key
*
* @curve_id: id representing the curve to use
diff --git a/crypto/ecc_curve_defs.h b/crypto/ecc_curve_defs.h
deleted file mode 100644
index 69be6c7..000
--- a/crypto/ecc_curve_defs.h
+++ /dev/null
@@ -1,57 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-#ifndef _CRYTO_ECC_CURVE_DEFS_H
-#define _CRYTO_ECC_CURVE_DEFS_H
-
-/* NIST P-192: a = p - 3 */
-static u64 nist_p192_g_x[] = { 0xF4FF0AFD82FF1012ull, 0x7CBF20EB43A18800ull,
- 0x188DA80EB03090F6ull };
-static u64 nist_p192_g_y[] = { 0x73F977A11E794811ull, 0x631011ED6B24CDD5ull,
- 0x07192B95FFC8DA78ull };
-static u64 nist_p192_p[] = { 0xull, 0xFFFEull,
- 0xull };
-static u64 nist_p192_n[] = { 0x146BC9B1B4D22831ull, 0x99DEF836ull,
- 0xull };
-static u64 nist_p192_a[] = { 0xFFFCull, 0xFFFEull,
- 0xull };
-static u64 nist_p192_b[] = { 0xFEB8DEECC146B9B1ull, 0x0FA7E9AB72243049ull,
- 0x64210519E59C80E7ull };
-static struct ecc_curve nist_p192 = {
- .name = "nist_192",
- .g = {
- .x = nist_p192_g_x,
- .y = nist_p192_g_y,
- .ndigits = 3,
- },
- .p = nist_p192_p,
- .n = nist_p192_n,
- .a = nist_p192_a,
- .b = nist_p192_b
-};
-
-/* NIST P-256: a = p - 3 */
-static u64 nist_p256_g_x[] = { 0xF4A13945D898C296ull, 0x77037D812DEB33A0ull,
- 0xF8BCE6E563A440F2ull, 0x6B17D1F2E12C4247ull };
-static u64 nist_p256_g_y[] = { 0xCBB6406837BF51F5ull, 0x2BCE33576B315ECEull,
- 0x8EE7EB4A7C0F9E16ull, 0x4FE342E2FE1A7F9Bull };
-static u64 nist_p256_p[] = { 0xull, 0xull,
- 0xull, 0x0001ull };
-static u64 nist_p256_n[] = { 0xF3B9CAC2FC632551ull, 0xBCE6FAADA7179E84ull,
- 0xull, 0xull };
-static u64 nist_p256_a[] = { 0xFFFCull, 0xull,
- 0xull, 0x0001ull };
-static u64 nist_p256_b[] = { 0x3BCE3C3E27D2604Bull, 0x651D06B0CC53B0F6ull,
- 0xB3EBBD55769886BCull, 0x5AC635D8AA3A93E7ull };
-static struct ecc_curve nist_p256 = {
- .name = "nist_256",
- .g = {
- .x = nist_p256_g_x,
- .y = nist_p256_g_y,
- .ndigits = 4,
- },
- .p = nist_p256_p,
- .n = nist_p256_n,
- .a = nist_p256_a,
- .b = nist_p256_b
-};
-
[PATCH v5 1/5] crypto: hisilicon/hpre - add some updates to adapt to Kunpeng 930
From: Hui Tang
HPRE of Kunpeng 930 is updated on cluster numbers and configurations
of Kunpeng 920 HPRE, so we try to update this driver to make it running
okay on both chips.
Signed-off-by: Hui Tang
Signed-off-by: Meng Yu
Reviewed-by: Zaibo Xu
---
drivers/crypto/hisilicon/hpre/hpre.h | 8 ++-
drivers/crypto/hisilicon/hpre/hpre_main.c | 93 +--
2 files changed, 68 insertions(+), 33 deletions(-)
diff --git a/drivers/crypto/hisilicon/hpre/hpre.h
b/drivers/crypto/hisilicon/hpre/hpre.h
index e784712..cc50f23 100644
--- a/drivers/crypto/hisilicon/hpre/hpre.h
+++ b/drivers/crypto/hisilicon/hpre/hpre.h
@@ -14,8 +14,7 @@ enum {
HPRE_CLUSTER0,
HPRE_CLUSTER1,
HPRE_CLUSTER2,
- HPRE_CLUSTER3,
- HPRE_CLUSTERS_NUM,
+ HPRE_CLUSTER3
};
enum hpre_ctrl_dbgfs_file {
@@ -36,7 +35,10 @@ enum hpre_dfx_dbgfs_file {
HPRE_DFX_FILE_NUM
};
-#define HPRE_DEBUGFS_FILE_NUM(HPRE_DEBUG_FILE_NUM + HPRE_CLUSTERS_NUM - 1)
+#define HPRE_CLUSTERS_NUM_V2 (HPRE_CLUSTER3 + 1)
+#define HPRE_CLUSTERS_NUM_V3 1
+#define HPRE_CLUSTERS_NUM_MAX HPRE_CLUSTERS_NUM_V2
+#define HPRE_DEBUGFS_FILE_NUM (HPRE_DEBUG_FILE_NUM + HPRE_CLUSTERS_NUM_MAX - 1)
struct hpre_debugfs_file {
int index;
diff --git a/drivers/crypto/hisilicon/hpre/hpre_main.c
b/drivers/crypto/hisilicon/hpre/hpre_main.c
index e5c9919..fc7173a 100644
--- a/drivers/crypto/hisilicon/hpre/hpre_main.c
+++ b/drivers/crypto/hisilicon/hpre/hpre_main.c
@@ -29,6 +29,8 @@
#define HPRE_BD_ARUSR_CFG 0x301030
#define HPRE_BD_AWUSR_CFG 0x301034
#define HPRE_TYPES_ENB 0x301038
+#define HPRE_RSA_ENB BIT(0)
+#define HPRE_ECC_ENB BIT(1)
#define HPRE_DATA_RUSER_CFG0x30103c
#define HPRE_DATA_WUSER_CFG0x301040
#define HPRE_INT_MASK 0x301400
@@ -73,7 +75,8 @@
#define HPRE_QM_AXI_CFG_MASK 0x
#define HPRE_QM_VFG_AX_MASK0xff
#define HPRE_BD_USR_MASK 0x3
-#define HPRE_CLUSTER_CORE_MASK 0xf
+#define HPRE_CLUSTER_CORE_MASK_V2 0xf
+#define HPRE_CLUSTER_CORE_MASK_V3 0xff
#define HPRE_AM_OOO_SHUTDOWN_ENB 0x301044
#define HPRE_AM_OOO_SHUTDOWN_ENABLEBIT(0)
@@ -86,6 +89,11 @@
#define HPRE_QM_PM_FLR BIT(11)
#define HPRE_QM_SRIOV_FLR BIT(12)
+#define HPRE_CLUSTERS_NUM(qm) \
+ (((qm)->ver >= QM_HW_V3) ? HPRE_CLUSTERS_NUM_V3 : HPRE_CLUSTERS_NUM_V2)
+#define HPRE_CLUSTER_CORE_MASK(qm) \
+ (((qm)->ver >= QM_HW_V3) ? HPRE_CLUSTER_CORE_MASK_V3 :\
+ HPRE_CLUSTER_CORE_MASK_V2)
#define HPRE_VIA_MSI_DSM 1
#define HPRE_SQE_MASK_OFFSET 8
#define HPRE_SQE_MASK_LEN 24
@@ -238,8 +246,40 @@ static int hpre_cfg_by_dsm(struct hisi_qm *qm)
return 0;
}
+static int hpre_set_cluster(struct hisi_qm *qm)
+{
+ u32 cluster_core_mask = HPRE_CLUSTER_CORE_MASK(qm);
+ u8 clusters_num = HPRE_CLUSTERS_NUM(qm);
+ struct device *dev = >pdev->dev;
+ unsigned long offset;
+ u32 val = 0;
+ int ret, i;
+
+ for (i = 0; i < clusters_num; i++) {
+ offset = i * HPRE_CLSTR_ADDR_INTRVL;
+
+ /* clusters initiating */
+ writel(cluster_core_mask,
+ HPRE_ADDR(qm, offset + HPRE_CORE_ENB));
+ writel(0x1, HPRE_ADDR(qm, offset + HPRE_CORE_INI_CFG));
+ ret = readl_relaxed_poll_timeout(HPRE_ADDR(qm, offset +
+ HPRE_CORE_INI_STATUS), val,
+ ((val & cluster_core_mask) ==
+ cluster_core_mask),
+ HPRE_REG_RD_INTVRL_US,
+ HPRE_REG_RD_TMOUT_US);
+ if (ret) {
+ dev_err(dev,
+ "cluster %d int st status timeout!\n", i);
+ return -ETIMEDOUT;
+ }
+ }
+
+ return 0;
+}
+
/*
- * For Hi1620, we shoul disable FLR triggered by hardware (BME/PM/SRIOV).
+ * For Kunpeng 920, we shoul disable FLR triggered by hardware (BME/PM/SRIOV).
* Or it may stay in D3 state when we bind and unbind hpre quickly,
* as it does FLR triggered by hardware.
*/
@@ -257,9 +297,8 @@ static void disable_flr_of_bme(struct hisi_qm *qm)
static int hpre_set_user_domain_and_cache(struct hisi_qm *qm)
{
struct device *dev = >pdev->dev;
- unsigned long offset;
- int ret, i;
u32 val;
+ int ret;
writel(HPRE_QM_USR_CFG_MASK, HPRE_ADDR(qm, QM_ARUSER_M_CFG_ENABLE));
writel(HPRE_QM_USR_CFG_MASK, HPRE_ADDR(qm, QM_AWUSER_M_CFG_ENABLE));
@@ -270,7 +309,12 @@ static int hpre_set_user_domain_and_cache(struct hisi_qm
*qm)
val |= BIT(HPRE_TIMEOUT_ABNML_BIT);
writel_relaxed(val,
[PATCH v5 5/5] crypto: hisilicon/hpre - add 'CURVE25519' algorithm
1. Add 'CURVE25519' curve parameter definition to
'include/crypto/ecc_curve_defs.h';
2. Enable 'CURVE25519' algorithm in Kunpeng 930.
Signed-off-by: Meng Yu
Reviewed-by: Zaibo Xu
Reported-by: kernel test robot
---
drivers/crypto/hisilicon/Kconfig| 1 +
drivers/crypto/hisilicon/hpre/hpre.h| 2 +
drivers/crypto/hisilicon/hpre/hpre_crypto.c | 364 +++-
include/crypto/ecc_curve_defs.h | 17 ++
4 files changed, 375 insertions(+), 9 deletions(-)
diff --git a/drivers/crypto/hisilicon/Kconfig b/drivers/crypto/hisilicon/Kconfig
index 8431926..c45adb1 100644
--- a/drivers/crypto/hisilicon/Kconfig
+++ b/drivers/crypto/hisilicon/Kconfig
@@ -65,6 +65,7 @@ config CRYPTO_DEV_HISI_HPRE
depends on UACCE || UACCE=n
depends on ARM64 || (COMPILE_TEST && 64BIT)
depends on ACPI
+ select CRYPTO_LIB_CURVE25519_GENERIC
select CRYPTO_DEV_HISI_QM
select CRYPTO_DH
select CRYPTO_RSA
diff --git a/drivers/crypto/hisilicon/hpre/hpre.h
b/drivers/crypto/hisilicon/hpre/hpre.h
index 50e6b2e..92892e3 100644
--- a/drivers/crypto/hisilicon/hpre/hpre.h
+++ b/drivers/crypto/hisilicon/hpre/hpre.h
@@ -84,6 +84,8 @@ enum hpre_alg_type {
HPRE_ALG_DH_G2 = 0x4,
HPRE_ALG_DH = 0x5,
HPRE_ALG_ECC_MUL = 0xD,
+ /* shared by x25519 and x448, but x448 is not supported now */
+ HPRE_ALG_CURVE25519_MUL = 0x10,
};
struct hpre_sqe {
diff --git a/drivers/crypto/hisilicon/hpre/hpre_crypto.c
b/drivers/crypto/hisilicon/hpre/hpre_crypto.c
index fe2f5ab..34bb4a0 100644
--- a/drivers/crypto/hisilicon/hpre/hpre_crypto.c
+++ b/drivers/crypto/hisilicon/hpre/hpre_crypto.c
@@ -1,6 +1,7 @@
// SPDX-License-Identifier: GPL-2.0
/* Copyright (c) 2019 HiSilicon Limited. */
#include
+#include
#include
#include
#include
@@ -96,6 +97,16 @@ struct hpre_ecdh_ctx {
dma_addr_t dma_g;
};
+struct hpre_curve25519_ctx {
+ /* low address: p->a->k */
+ unsigned char *p;
+ dma_addr_t dma_p;
+
+ /* gx coordinate */
+ unsigned char *g;
+ dma_addr_t dma_g;
+};
+
struct hpre_ctx {
struct hisi_qp *qp;
struct hpre_asym_request **req_list;
@@ -108,6 +119,7 @@ struct hpre_ctx {
struct hpre_rsa_ctx rsa;
struct hpre_dh_ctx dh;
struct hpre_ecdh_ctx ecdh;
+ struct hpre_curve25519_ctx curve25519;
};
/* for ecc algorithms */
unsigned int curve_id;
@@ -122,6 +134,7 @@ struct hpre_asym_request {
struct akcipher_request *rsa;
struct kpp_request *dh;
struct kpp_request *ecdh;
+ struct kpp_request *curve25519;
} areq;
int err;
int req_id;
@@ -444,7 +457,6 @@ static void hpre_alg_cb(struct hisi_qp *qp, void *resp)
struct hpre_sqe *sqe = resp;
struct hpre_asym_request *req = ctx->req_list[le16_to_cpu(sqe->tag)];
-
if (unlikely(!req)) {
atomic64_inc([HPRE_INVALID_REQ_CNT].value);
return;
@@ -1174,6 +1186,12 @@ static void hpre_ecc_clear_ctx(struct hpre_ctx *ctx,
bool is_clear_all,
memzero_explicit(ctx->ecdh.p + shift, sz);
dma_free_coherent(dev, sz << 3, ctx->ecdh.p, ctx->ecdh.dma_p);
ctx->ecdh.p = NULL;
+ } else if (!is_ecdh && ctx->curve25519.p) {
+ /* curve25519: p->a->k */
+ memzero_explicit(ctx->curve25519.p + shift, sz);
+ dma_free_coherent(dev, sz << 2, ctx->curve25519.p,
+ ctx->curve25519.dma_p);
+ ctx->curve25519.p = NULL;
}
ctx->curve_id = 0;
@@ -1577,6 +1595,307 @@ static void hpre_ecdh_exit_tfm(struct crypto_kpp *tfm)
hpre_ecc_clear_ctx(ctx, true, true);
}
+static void hpre_curve25519_fill_curve(struct hpre_ctx *ctx, const void *buf,
+ unsigned int len)
+{
+ u8 secret[CURVE25519_KEY_SIZE] = { 0 };
+ unsigned int sz = ctx->key_sz;
+ unsigned int shift = sz << 1;
+ void *p;
+
+ /**
+* The key from 'buf' is in little-endian, we should preprocess it as
+* the description in rfc7748: "k[0] &= 248, k[31] &= 127, k[31] |= 64",
+* then convert it to big endian. Only in this way, the result can be
+* the same as the software curve-25519 that exists in crypto.
+*/
+ memcpy(secret, buf, len);
+ curve25519_clamp_secret(secret);
+ hpre_key_to_big_end(secret, CURVE25519_KEY_SIZE);
+
+ p = ctx->curve25519.p + sz - len;
+
+ /* fill curve parameters */
+ fill_curve_param(p, ecc_25519.p, len, ecc_25519.g.ndigits);
+ fill_curve_param(p + sz, ecc_25519.a, len, ecc_25519.g.ndigits);
+ memcpy(p + shift, secret, len);
+ fill_curve_param(p + shift + sz, ecc_25519.g.x, len,
ecc_25519.g.ndigits);
+ memzero_explicit(secret,
[PATCH v5 2/5] crypto: hisilicon/hpre - add algorithm type
Algorithm type is brought in to get hardware HPRE queue
to support different algorithms.
Signed-off-by: Meng Yu
Reviewed-by: Zaibo Xu
---
drivers/crypto/hisilicon/hpre/hpre.h| 10 +-
drivers/crypto/hisilicon/hpre/hpre_crypto.c | 12 ++--
drivers/crypto/hisilicon/hpre/hpre_main.c | 11 +--
3 files changed, 24 insertions(+), 9 deletions(-)
diff --git a/drivers/crypto/hisilicon/hpre/hpre.h
b/drivers/crypto/hisilicon/hpre/hpre.h
index cc50f23..02193e1 100644
--- a/drivers/crypto/hisilicon/hpre/hpre.h
+++ b/drivers/crypto/hisilicon/hpre/hpre.h
@@ -10,6 +10,14 @@
#define HPRE_PF_DEF_Q_NUM 64
#define HPRE_PF_DEF_Q_BASE 0
+/*
+ * type used in qm sqc DW6.
+ * 0 - Algorithm which has been supported in V2, like RSA, DH and so on;
+ * 1 - ECC algorithm in V3.
+ */
+#define HPRE_V2_ALG_TYPE 0
+#define HPRE_V3_ECC_ALG_TYPE 1
+
enum {
HPRE_CLUSTER0,
HPRE_CLUSTER1,
@@ -92,7 +100,7 @@ struct hpre_sqe {
__le32 rsvd1[_HPRE_SQE_ALIGN_EXT];
};
-struct hisi_qp *hpre_create_qp(void);
+struct hisi_qp *hpre_create_qp(u8 type);
int hpre_algs_register(struct hisi_qm *qm);
void hpre_algs_unregister(struct hisi_qm *qm);
diff --git a/drivers/crypto/hisilicon/hpre/hpre_crypto.c
b/drivers/crypto/hisilicon/hpre/hpre_crypto.c
index d89b2f5..712bea9 100644
--- a/drivers/crypto/hisilicon/hpre/hpre_crypto.c
+++ b/drivers/crypto/hisilicon/hpre/hpre_crypto.c
@@ -152,12 +152,12 @@ static void hpre_rm_req_from_ctx(struct hpre_asym_request
*hpre_req)
}
}
-static struct hisi_qp *hpre_get_qp_and_start(void)
+static struct hisi_qp *hpre_get_qp_and_start(u8 type)
{
struct hisi_qp *qp;
int ret;
- qp = hpre_create_qp();
+ qp = hpre_create_qp(type);
if (!qp) {
pr_err("Can not create hpre qp!\n");
return ERR_PTR(-ENODEV);
@@ -422,11 +422,11 @@ static void hpre_alg_cb(struct hisi_qp *qp, void *resp)
req->cb(ctx, resp);
}
-static int hpre_ctx_init(struct hpre_ctx *ctx)
+static int hpre_ctx_init(struct hpre_ctx *ctx, u8 type)
{
struct hisi_qp *qp;
- qp = hpre_get_qp_and_start();
+ qp = hpre_get_qp_and_start(type);
if (IS_ERR(qp))
return PTR_ERR(qp);
@@ -674,7 +674,7 @@ static int hpre_dh_init_tfm(struct crypto_kpp *tfm)
{
struct hpre_ctx *ctx = kpp_tfm_ctx(tfm);
- return hpre_ctx_init(ctx);
+ return hpre_ctx_init(ctx, HPRE_V2_ALG_TYPE);
}
static void hpre_dh_exit_tfm(struct crypto_kpp *tfm)
@@ -1100,7 +1100,7 @@ static int hpre_rsa_init_tfm(struct crypto_akcipher *tfm)
return PTR_ERR(ctx->rsa.soft_tfm);
}
- ret = hpre_ctx_init(ctx);
+ ret = hpre_ctx_init(ctx, HPRE_V2_ALG_TYPE);
if (ret)
crypto_free_akcipher(ctx->rsa.soft_tfm);
diff --git a/drivers/crypto/hisilicon/hpre/hpre_main.c
b/drivers/crypto/hisilicon/hpre/hpre_main.c
index fc7173a..1ae8fa1 100644
--- a/drivers/crypto/hisilicon/hpre/hpre_main.c
+++ b/drivers/crypto/hisilicon/hpre/hpre_main.c
@@ -209,13 +209,20 @@ static u32 vfs_num;
module_param_cb(vfs_num, _num_ops, _num, 0444);
MODULE_PARM_DESC(vfs_num, "Number of VFs to enable(1-63), 0(default)");
-struct hisi_qp *hpre_create_qp(void)
+struct hisi_qp *hpre_create_qp(u8 type)
{
int node = cpu_to_node(smp_processor_id());
struct hisi_qp *qp = NULL;
int ret;
- ret = hisi_qm_alloc_qps_node(_devices, 1, 0, node, );
+ if (type != HPRE_V2_ALG_TYPE && type != HPRE_V3_ECC_ALG_TYPE)
+ return NULL;
+
+ /*
+* type: 0 - RSA/DH. algorithm supported in V2,
+* 1 - ECC algorithm in V3.
+*/
+ ret = hisi_qm_alloc_qps_node(_devices, 1, type, node, );
if (!ret)
return qp;
--
2.8.1
[PATCH v5 0/5] add ECDH and CURVE25519 algorithms support for Kunpeng 930
1. Move elliptic curve parameter definitions out to "include/crypto"; 2. Add some new elliptic curve parameters definitions, and reorder ECC 'Curves IDs'; 3. Add ECDH and CURVE25519 algorithms support for Kunpeng 930. These patches depend on: [v2,1/6] crypto: hisilicon/hpre - add version adapt to new algorithms, https://patchwork.kernel.org/project/linux-crypto/patch/1607598607-8728- 2-git-send-email-liulongf...@huawei.com/ v4->v5: - patch #4: delete P-128 and P-320 curve, as the few using case in the kernel v3 -> v4: - patch #3: add new, move ecc_curve params to "include/crypto" v2 -> v3: - patch #5: fix sparse warnings - patch #5: add 'CRYPTO_LIB_CURVE25519_GENERIC' in 'Kconfig' v1 -> v2: - patch #5: delete `curve25519_null_point' Hui Tang (1): crypto: hisilicon/hpre - add some updates to adapt to Kunpeng 930 Meng Yu (4): crypto: hisilicon/hpre - add algorithm type crypto: expose elliptic curve parameters as Crypto APIs crypto: hisilicon/hpre - add 'ECDH' algorithm crypto: hisilicon/hpre - add 'CURVE25519' algorithm crypto/ecc.c| 5 +- crypto/ecc.h| 37 +- crypto/ecc_curve_defs.h | 57 -- crypto/ecrdsa_defs.h| 2 +- crypto/testmgr.h| 12 +- drivers/crypto/hisilicon/Kconfig| 1 + drivers/crypto/hisilicon/hpre/hpre.h| 22 +- drivers/crypto/hisilicon/hpre/hpre_crypto.c | 860 +++- drivers/crypto/hisilicon/hpre/hpre_main.c | 105 ++-- include/crypto/ecc_curve_defs.h | 212 +++ include/crypto/ecdh.h | 5 +- 11 files changed, 1168 insertions(+), 150 deletions(-) delete mode 100644 crypto/ecc_curve_defs.h create mode 100644 include/crypto/ecc_curve_defs.h -- 2.8.1
[PATCH V6 00/13] Add driver for dvfsrc, support for active state of scpsys
This series is based on v5.10-rc1. The patchsets add support for MediaTek hardware module named DVFSRC (dynamic voltage and frequency scaling resource collector). The DVFSRC is a HW module which is used to collect all the requests from both software and hardware and turn into the decision of minimum operating voltage and minimum DRAM frequency to fulfill those requests. So, This series is to implement the dvfsrc driver to collect all the requests of operating voltage or DRAM bandwidth from other device drivers likes GPU/Camera through 3 frameworks basically: 1. interconnect framework: to aggregate the bandwidth requirements from different clients [1] https://patchwork.kernel.org/cover/10766329/ There has a hw module "DRAM scheduler", which used to control the throughput. The DVFSRC will collect forecast data of dram bandwidth from SW consumers(camera/gpu...), and according the forecast to change the DRAM frequency 2. Regualtor framework: to handle the operating voltage requirement from user or cosumer which not belong any power domain Changes in V6: * Remove the performace state support, because the request from consumer can be replaced by using interconnect and regulator framework. * Update the DT patches and convert them to DT schema. (Georgi) * Modify the comment format and coding style. (Mark) Changes in V5: * Support more platform mt6873/mt8192 * Drop the compatible and interconnect provider node and make the parent node an interconnect provider. (Rob/Georgi) * Make modification of interconnect driver from coding suggestion. (Georgi) * Move interconnect diagram into the commit text of patch. (Georgi) * Register the interconnect provider as a platform sub-device. (Georgi) Changes in V4: * Add acked TAG on dt-bindings patches. (Rob) * Declaration of emi_icc_aggregate since the prototype of aggregate function has changed meanwhile. (Georgi) * Used emi_icc_remove instead of icc_provider_del on probe. (Georgi) * Add dvfsrc regulator driver into series. * Bug fixed of mt8183_get_current_level. * Add mutex protection for pstate operation on dvfsrc_set_performance. Changes in V3: * Remove RFC from the subject prefix of the series * Combine dt-binding patch and move interconnect dt-binding document into dvfsrc. (Rob) * Remove unused header, add unit descirption to the bandwidth, rename compatible name on interconnect driver. (Georgi) * Fixed some coding style: check flow, naming, used readx_poll_timeout on dvfsrc driver. (Ryan) * Rename interconnect driver mt8183.c to mtk-emi.c * Rename interconnect header mtk,mt8183.h to mtk,emi.h * mtk-scpsys.c: Add opp table check first to avoid OF runtime parse failed Changes in RFC V2: * Remove the DT property dram_type. (Rob) * Used generic dts property 'opp-level' to get the performace state. (Stephen) * Remove unecessary dependency config on Kconfig. (Stephen) * Remove unused header file, fixed some coding style issue, typo, error handling on dvfsrc driver. (Nicolas/Stephen) * Remove irq handler on dvfsrc driver. (Stephen) * Remove init table on dvfsrc driver, combine hw init on trustzone. * Add interconnect support of mt8183 to aggregate the emi bandwidth. (Georgi) V5: https://patchwork.kernel.org/project/linux-mediatek/list/?series=348065 V4: https://lore.kernel.org/patchwork/cover/1209284/ V3: https://patchwork.kernel.org/cover/8867/ RFC V2: https://lore.kernel.org/patchwork/patch/1068113/ RFC V1: https://lore.kernel.org/patchwork/cover/1028535/
[PATCH V6 04/13] arm64: dts: mt8183: add dvfsrc related nodes
Enable dvfsrc on mt8183 platform.
Signed-off-by: Henry Chen
---
arch/arm64/boot/dts/mediatek/mt8183.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
index 9cfd961..06ef8e0 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
@@ -328,6 +328,11 @@
#clock-cells = <1>;
};
+ ddr_emi: dvfsrc@10012000 {
+ compatible = "mediatek,mt8183-dvfsrc";
+ reg = <0 0x10012000 0 0x1000>;
+ };
+
pwrap: pwrap@1000d000 {
compatible = "mediatek,mt8183-pwrap";
reg = <0 0x1000d000 0 0x1000>;
--
1.9.1
[PATCH V6 12/13] arm64: dts: mt8183: add dvfsrc regulator nodes
Add dvfsrc regulator nodes which is for MT8183-based platforms
Signed-off-by: Henry Chen
---
arch/arm64/boot/dts/mediatek/mt8183.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
index 22b3a68..182b851 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
@@ -333,6 +333,12 @@
compatible = "mediatek,mt8183-dvfsrc";
reg = <0 0x10012000 0 0x1000>;
#interconnect-cells = <1>;
+ dvfsrc_vcore: dvfsrc-vcore {
+ regulator-name = "dvfsrc-vcore";
+ regulator-min-microvolt = <725000>;
+ regulator-max-microvolt = <80>;
+ regulator-always-on;
+ };
};
pwrap: pwrap@1000d000 {
--
1.9.1
[PATCH V6 10/13] arm64: dts: mt8192: add dvfsrc related nodes
Add DDR EMI provider dictating dram interconnect bus performance found on
MT8192-based platforms
Signed-off-by: Henry Chen
---
arch/arm64/boot/dts/mediatek/mt8192.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8192.dtsi
b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
index 1e5d506..14c521d 100644
--- a/arch/arm64/boot/dts/mediatek/mt8192.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
/ {
compatible = "mediatek,mt8192";
@@ -266,6 +267,7 @@
ddr_emi: dvfsrc@10012000 {
compatible = "mediatek,mt8192-dvfsrc";
reg = <0 0x10012000 0 0x1000>;
+ #interconnect-cells = <1>;
};
systimer: timer@10017000 {
--
1.9.1
[PATCH V6 08/13] interconnect: mediatek: Add interconnect provider driver
Introduce Mediatek MT6873/MT8183/MT8192 specific provider driver
using the interconnect framework.
ICC provider ICC Nodes
- |CPU | |--- |VPU |
- | |- |
|DRAM |--|DRAM | |
| |--|scheduler|- |GPU | |--- |DISP|
| |--|(EMI)| |
| |--| | - |
- | |- |MMSYS|--|--- |VDEC|
-- |
/|\|
|change DRAM freq |--- |VENC|
-- |
| DVFSR | |
| | |
-- |--- |IMG |
|
|
|--- |CAM |
Signed-off-by: Henry Chen
---
drivers/interconnect/Kconfig| 1 +
drivers/interconnect/Makefile | 1 +
drivers/interconnect/mediatek/Kconfig | 13 ++
drivers/interconnect/mediatek/Makefile | 3 +
drivers/interconnect/mediatek/mtk-emi.c | 330
5 files changed, 348 insertions(+)
create mode 100644 drivers/interconnect/mediatek/Kconfig
create mode 100644 drivers/interconnect/mediatek/Makefile
create mode 100644 drivers/interconnect/mediatek/mtk-emi.c
diff --git a/drivers/interconnect/Kconfig b/drivers/interconnect/Kconfig
index 5b7204e..e939f5a 100644
--- a/drivers/interconnect/Kconfig
+++ b/drivers/interconnect/Kconfig
@@ -13,5 +13,6 @@ if INTERCONNECT
source "drivers/interconnect/imx/Kconfig"
source "drivers/interconnect/qcom/Kconfig"
+source "drivers/interconnect/mediatek/Kconfig"
endif
diff --git a/drivers/interconnect/Makefile b/drivers/interconnect/Makefile
index d203520..0643a24 100644
--- a/drivers/interconnect/Makefile
+++ b/drivers/interconnect/Makefile
@@ -6,3 +6,4 @@ icc-core-objs := core.o bulk.o
obj-$(CONFIG_INTERCONNECT) += icc-core.o
obj-$(CONFIG_INTERCONNECT_IMX) += imx/
obj-$(CONFIG_INTERCONNECT_QCOM)+= qcom/
+obj-$(CONFIG_INTERCONNECT_MTK) += mediatek/
diff --git a/drivers/interconnect/mediatek/Kconfig
b/drivers/interconnect/mediatek/Kconfig
new file mode 100644
index 000..972d3bb
--- /dev/null
+++ b/drivers/interconnect/mediatek/Kconfig
@@ -0,0 +1,13 @@
+config INTERCONNECT_MTK
+ bool "Mediatek Network-on-Chip interconnect drivers"
+ depends on ARCH_MEDIATEK
+ help
+ Support for Mediatek's Network-on-Chip interconnect hardware.
+
+config INTERCONNECT_MTK_EMI
+ tristate "Mediatek EMI interconnect driver"
+ depends on INTERCONNECT_MTK
+ depends on (MTK_DVFSRC && OF)
+ help
+ This is a driver for the Mediatek Network-on-Chip on DVFSRC-based
+ platforms.
diff --git a/drivers/interconnect/mediatek/Makefile
b/drivers/interconnect/mediatek/Makefile
new file mode 100644
index 000..353842b
--- /dev/null
+++ b/drivers/interconnect/mediatek/Makefile
@@ -0,0 +1,3 @@
+# SPDX-License-Identifier: GPL-2.0
+
+obj-$(CONFIG_INTERCONNECT_MTK_EMI) += mtk-emi.o
\ No newline at end of file
diff --git a/drivers/interconnect/mediatek/mtk-emi.c
b/drivers/interconnect/mediatek/mtk-emi.c
new file mode 100644
index 000..9670077
--- /dev/null
+++ b/drivers/interconnect/mediatek/mtk-emi.c
@@ -0,0 +1,330 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2020, The Linux Foundation. All rights reserved.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+enum mtk_icc_name {
+ SLAVE_DDR_EMI,
+ MASTER_MCUSYS,
+ MASTER_GPUSYS,
+ MASTER_MMSYS,
+ MASTER_MM_VPU,
+ MASTER_MM_DISP,
+ MASTER_MM_VDEC,
+ MASTER_MM_VENC,
+ MASTER_MM_CAM,
+ MASTER_MM_IMG,
+ MASTER_MM_MDP,
+ MASTER_VPUSYS,
+ MASTER_VPU_PORT_0,
+ MASTER_VPU_PORT_1,
+ MASTER_MDLASYS,
+ MASTER_MDLA_PORT_0,
+ MASTER_UFS,
+ MASTER_PCIE,
+ MASTER_USB,
+ MASTER_WIFI,
+ MASTER_BT,
+ MASTER_NETSYS,
+ MASTER_DBGIF,
+
+ SLAVE_HRT_DDR_EMI,
+ MASTER_HRT_MMSYS,
+ MASTER_HRT_MM_DISP,
+ MASTER_HRT_MM_VDEC,
+ MASTER_HRT_MM_VENC,
+ MASTER_HRT_MM_CAM,
+ MASTER_HRT_MM_IMG,
+ MASTER_HRT_MM_MDP,
+ MASTER_HRT_DBGIF,
+};
+
+#define MT8183_MAX_LINKS 1
+
+/**
+ * struct mtk_icc_node - Mediatek specific interconnect nodes
+ * @name: the node name used in debugfs
+ * @ep : the type of this endpoint
+ * @id: a unique node identifier
+ * @links: an array of nodes where we can go next while traversing
+ * @num_links: the total number of @links
+ * @sum_avg: current
[PATCH V6 03/13] soc: mediatek: add driver for dvfsrc support
Add dvfsrc driver for MT6873/MT8183/MT8192
Signed-off-by: Henry Chen
---
drivers/soc/mediatek/Kconfig| 12 +
drivers/soc/mediatek/Makefile | 1 +
drivers/soc/mediatek/mtk-dvfsrc.c | 538
include/linux/soc/mediatek/mtk_dvfsrc.h | 35 +++
4 files changed, 586 insertions(+)
create mode 100644 drivers/soc/mediatek/mtk-dvfsrc.c
create mode 100644 include/linux/soc/mediatek/mtk_dvfsrc.h
diff --git a/drivers/soc/mediatek/Kconfig b/drivers/soc/mediatek/Kconfig
index 59a56cd..0150a6b 100644
--- a/drivers/soc/mediatek/Kconfig
+++ b/drivers/soc/mediatek/Kconfig
@@ -17,6 +17,18 @@ config MTK_CMDQ
time limitation, such as updating display configuration during the
vblank.
+config MTK_DVFSRC
+ tristate "MediaTek DVFSRC Support"
+ depends on ARCH_MEDIATEK
+ depends on MTK_SCPSYS
+ help
+ Say yes here to add support for the MediaTek DVFSRC (dynamic voltage
+ and frequency scaling resource collector) found
+ on different MediaTek SoCs. The DVFSRC is a proprietary
+ hardware which is used to collect all the requests from
+ system and turn into the decision of minimum Vcore voltage
+ and minimum DRAM frequency to fulfill those requests.
+
config MTK_INFRACFG
bool "MediaTek INFRACFG Support"
select REGMAP
diff --git a/drivers/soc/mediatek/Makefile b/drivers/soc/mediatek/Makefile
index 01f9f87..d55b473 100644
--- a/drivers/soc/mediatek/Makefile
+++ b/drivers/soc/mediatek/Makefile
@@ -1,5 +1,6 @@
# SPDX-License-Identifier: GPL-2.0-only
obj-$(CONFIG_MTK_CMDQ) += mtk-cmdq-helper.o
+obj-$(CONFIG_MTK_DVFSRC) += mtk-dvfsrc.o
obj-$(CONFIG_MTK_INFRACFG) += mtk-infracfg.o
obj-$(CONFIG_MTK_PMIC_WRAP) += mtk-pmic-wrap.o
obj-$(CONFIG_MTK_SCPSYS) += mtk-scpsys.o
diff --git a/drivers/soc/mediatek/mtk-dvfsrc.c
b/drivers/soc/mediatek/mtk-dvfsrc.c
new file mode 100644
index 000..536ced7
--- /dev/null
+++ b/drivers/soc/mediatek/mtk-dvfsrc.c
@@ -0,0 +1,538 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2020 MediaTek Inc.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DVFSRC_IDLE 0x00
+#define DVFSRC_GET_TARGET_LEVEL(x) (((x) >> 0) & 0x)
+#define DVFSRC_GET_CURRENT_LEVEL(x) (((x) >> 16) & 0x)
+#define kbps_to_mbps(x) ((x) / 1000)
+
+#define POLL_TIMEOUT1000
+#define STARTUP_TIME1
+
+#define MTK_SIP_DVFSRC_INIT0x00
+
+#define DVFSRC_OPP_DESC(_opp_table)\
+{ \
+ .opps = _opp_table, \
+ .num_opp = ARRAY_SIZE(_opp_table), \
+}
+
+struct dvfsrc_opp {
+ u32 vcore_opp;
+ u32 dram_opp;
+};
+
+struct dvfsrc_opp_desc {
+ const struct dvfsrc_opp *opps;
+ u32 num_opp;
+};
+
+struct mtk_dvfsrc;
+struct dvfsrc_soc_data {
+ const int *regs;
+ const struct dvfsrc_opp_desc *opps_desc;
+ int (*get_target_level)(struct mtk_dvfsrc *dvfsrc);
+ int (*get_current_level)(struct mtk_dvfsrc *dvfsrc);
+ u32 (*get_vcore_level)(struct mtk_dvfsrc *dvfsrc);
+ u32 (*get_vcp_level)(struct mtk_dvfsrc *dvfsrc);
+ void (*set_dram_bw)(struct mtk_dvfsrc *dvfsrc, u64 bw);
+ void (*set_dram_peak_bw)(struct mtk_dvfsrc *dvfsrc, u64 bw);
+ void (*set_dram_hrtbw)(struct mtk_dvfsrc *dvfsrc, u64 bw);
+ void (*set_opp_level)(struct mtk_dvfsrc *dvfsrc, u32 level);
+ void (*set_vcore_level)(struct mtk_dvfsrc *dvfsrc, u32 level);
+ void (*set_vscp_level)(struct mtk_dvfsrc *dvfsrc, u32 level);
+ int (*wait_for_opp_level)(struct mtk_dvfsrc *dvfsrc, u32 level);
+ int (*wait_for_vcore_level)(struct mtk_dvfsrc *dvfsrc, u32 level);
+};
+
+struct mtk_dvfsrc {
+ struct device *dev;
+ struct platform_device *icc;
+ struct platform_device *regulator;
+ const struct dvfsrc_soc_data *dvd;
+ int dram_type;
+ const struct dvfsrc_opp_desc *curr_opps;
+ void __iomem *regs;
+ spinlock_t req_lock;
+ struct mutex pstate_lock;
+ struct notifier_block scpsys_notifier;
+};
+
+static u32 dvfsrc_read(struct mtk_dvfsrc *dvfs, u32 offset)
+{
+ return readl(dvfs->regs + dvfs->dvd->regs[offset]);
+}
+
+static void dvfsrc_write(struct mtk_dvfsrc *dvfs, u32 offset, u32 val)
+{
+ writel(val, dvfs->regs + dvfs->dvd->regs[offset]);
+}
+
+#define dvfsrc_rmw(dvfs, offset, val, mask, shift) \
+ dvfsrc_write(dvfs, offset, \
+ (dvfsrc_read(dvfs, offset) & ~(mask << shift)) | (val << shift))
+
+enum dvfsrc_regs {
+ DVFSRC_SW_REQ,
+ DVFSRC_SW_REQ2,
+ DVFSRC_LEVEL,
+ DVFSRC_TARGET_LEVEL,
+ DVFSRC_SW_BW,
+ DVFSRC_SW_PEAK_BW,
+ DVFSRC_SW_HRT_BW,
+ DVFSRC_VCORE_REQUEST,
+};
+
+static const int mt8183_regs[] = {
+ [DVFSRC_SW_REQ] = 0x4,
+ [DVFSRC_SW_REQ2] = 0x8,
+ [DVFSRC_LEVEL] =0xDC,
+ [DVFSRC_SW_BW] =
[PATCH V6 01/13] dt-bindings: soc: Add dvfsrc driver bindings
Document the binding for enabling dvfsrc on MediaTek SoC.
Signed-off-by: Henry Chen
---
.../devicetree/bindings/soc/mediatek/dvfsrc.yaml | 68 ++
1 file changed, 68 insertions(+)
create mode 100644 Documentation/devicetree/bindings/soc/mediatek/dvfsrc.yaml
diff --git a/Documentation/devicetree/bindings/soc/mediatek/dvfsrc.yaml
b/Documentation/devicetree/bindings/soc/mediatek/dvfsrc.yaml
new file mode 100644
index 000..60e0b7c
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/mediatek/dvfsrc.yaml
@@ -0,0 +1,68 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/soc/mediatek/dvfsrc.yaml#;
+$schema: "http://devicetree.org/meta-schemas/core.yaml#;
+
+title: MediaTek dynamic voltage and frequency scaling resource collector
(DVFSRC)
+
+description: |
+ The Dynamic Voltage and Frequency Scaling Resource Collector (DVFSRC) is a
+ HW module which is used to collect all the requests from both software and
+ hardware and turn into the decision of minimum operating voltage and minimum
+ DRAM frequency to fulfill those requests.
+
+maintainers:
+ - henryc.chen
+
+properties:
+ reg:
+description: DVFSRC common register address and length.
+
+ compatible:
+enum:
+ - mediatek,mt6873-dvfsrc
+ - mediatek,mt8183-dvfsrc
+ - mediatek,mt8192-dvfsrc
+
+ '#interconnect-cells':
+const: 1
+
+patternProperties:
+ dvfsrc-vcore:
+type: object
+description:
+ The DVFSRC regulator is modelled as a subdevice of the DVFSRC.
+ Because DVFSRC can request power directly via register read/write, likes
+ vcore which is a core power of mt8183. As such, the DVFSRC regulator
+ requires that DVFSRC nodes be present.
+$ref: /schemas/regulator/regulator.yaml#
+
+required:
+ - compatible
+ - reg
+ - "#interconnect-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+
+soc {
+#address-cells = <2>;
+#size-cells = <2>;
+
+dvfsrc@10012000 {
+compatible = "mediatek,mt8183-dvfsrc";
+reg = <0 0x10012000 0 0x1000>;
+#interconnect-cells = <1>;
+dvfsrc_vcore: dvfsrc-vcore {
+regulator-name = "dvfsrc-vcore";
+regulator-min-microvolt = <725000>;
+regulator-max-microvolt = <80>;
+regulator-always-on;
+};
+};
+};
--
1.9.1
[PATCH V6 06/13] dt-bindings: interconnect: add MT8183 interconnect dt-bindings
Add interconnect provider dt-bindings for MT8183. Signed-off-by: Henry Chen --- include/dt-bindings/interconnect/mtk,mt8183-emi.h | 21 + 1 file changed, 21 insertions(+) create mode 100644 include/dt-bindings/interconnect/mtk,mt8183-emi.h diff --git a/include/dt-bindings/interconnect/mtk,mt8183-emi.h b/include/dt-bindings/interconnect/mtk,mt8183-emi.h new file mode 100644 index 000..f921961 --- /dev/null +++ b/include/dt-bindings/interconnect/mtk,mt8183-emi.h @@ -0,0 +1,21 @@ +/* SPDX-License-Identifier: GPL-2.0 + * + * Copyright (c) 2020 MediaTek Inc. + */ + +#ifndef __DT_BINDINGS_INTERCONNECT_MTK_MT8183_EMI_H +#define __DT_BINDINGS_INTERCONNECT_MTK_MT8183_EMI_H + +#define MT8183_SLAVE_DDR_EMI 0 +#define MT8183_MASTER_MCUSYS 1 +#define MT8183_MASTER_GPU 2 +#define MT8183_MASTER_MMSYS3 +#define MT8183_MASTER_MM_VPU 4 +#define MT8183_MASTER_MM_DISP 5 +#define MT8183_MASTER_MM_VDEC 6 +#define MT8183_MASTER_MM_VENC 7 +#define MT8183_MASTER_MM_CAM 8 +#define MT8183_MASTER_MM_IMG 9 +#define MT8183_MASTER_MM_MDP 10 + +#endif -- 1.9.1
[PATCH V6 09/13] arm64: dts: mt8183: add dvfsrc related nodes
Add DDR EMI provider dictating dram interconnect bus performance found on
MT8183-based platforms
Signed-off-by: Henry Chen
---
arch/arm64/boot/dts/mediatek/mt8183.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
index 06ef8e0..22b3a68 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
@@ -11,6 +11,7 @@
#include
#include
#include "mt8183-pinfunc.h"
+#include
/ {
compatible = "mediatek,mt8183";
@@ -331,6 +332,7 @@
ddr_emi: dvfsrc@10012000 {
compatible = "mediatek,mt8183-dvfsrc";
reg = <0 0x10012000 0 0x1000>;
+ #interconnect-cells = <1>;
};
pwrap: pwrap@1000d000 {
--
1.9.1
[PATCH V6 02/13] soc: mediatek: add header for mediatek SIP interface
From: Arvin Wang Add a header to collect SIPs and add one SIP call to initialize power management hardware for the SIP interface defined to access the SPM handling vcore voltage and ddr rate changes on mt8183 (and most likely later socs). Signed-off-by: Arvin Wang --- include/linux/soc/mediatek/mtk_sip_svc.h | 4 1 file changed, 4 insertions(+) diff --git a/include/linux/soc/mediatek/mtk_sip_svc.h b/include/linux/soc/mediatek/mtk_sip_svc.h index 082398e..079bbcb 100644 --- a/include/linux/soc/mediatek/mtk_sip_svc.h +++ b/include/linux/soc/mediatek/mtk_sip_svc.h @@ -22,4 +22,8 @@ ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, MTK_SIP_SMC_CONVENTION, \ ARM_SMCCC_OWNER_SIP, fn_id) +/* VCOREFS */ +#define MTK_SIP_VCOREFS_CONTROL \ + MTK_SIP_SMC_CMD(0x506) + #endif -- 1.9.1
RE: [PATCH] PCI: dwc: Change size to u64 for EP outbound iATU
> From: Bjorn Helgaas
> Subject: Re: [PATCH] PCI: dwc: Change size to u64 for EP outbound iATU
>
> On Fri, Dec 18, 2020 at 09:04:08PM +0530, Shradha Todi wrote:
> > Since outbound iATU permits size to be greater than 4GB for which the
> > support is also available, allow EP function to send u64 size instead
> > of truncating to u32.
>
> Please wrap your commit messages so they use more of an 80-column window.
> I use "set textwidth=75" for vim to account for git log indenting by 4
characters.
>
> I know 80 isn't a magic width, but it's the convention in drivers/pci.
>
> This also affects other patches from you, e.g., "PCI: dwc: Add upper limit
> address for outbound iATU".
>
Thanks for the review and suggestion. I will take care of this for all my
patches
in next version.
> > Signed-off-by: Shradha Todi
> > ---
> > drivers/pci/controller/dwc/pcie-designware.c | 2 +-
> > drivers/pci/controller/dwc/pcie-designware.h | 2 +-
> > 2 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/pci/controller/dwc/pcie-designware.c
> > b/drivers/pci/controller/dwc/pcie-designware.c
> > index 7eba3b2..6298212 100644
> > --- a/drivers/pci/controller/dwc/pcie-designware.c
> > +++ b/drivers/pci/controller/dwc/pcie-designware.c
> > @@ -325,7 +325,7 @@ void dw_pcie_prog_outbound_atu(struct dw_pcie
> > *pci, int index, int type,
> >
> > void dw_pcie_prog_ep_outbound_atu(struct dw_pcie *pci, u8 func_no, int
> index,
> > int type, u64 cpu_addr, u64 pci_addr,
> > - u32 size)
> > + u64 size)
> > {
> > __dw_pcie_prog_outbound_atu(pci, func_no, index, type,
> > cpu_addr, pci_addr, size);
> > diff --git a/drivers/pci/controller/dwc/pcie-designware.h
> > b/drivers/pci/controller/dwc/pcie-designware.h
> > index 28b72fb..bb33f28 100644
> > --- a/drivers/pci/controller/dwc/pcie-designware.h
> > +++ b/drivers/pci/controller/dwc/pcie-designware.h
> > @@ -307,7 +307,7 @@ void dw_pcie_prog_outbound_atu(struct dw_pcie *pci,
> int index,
> >u64 size);
> > void dw_pcie_prog_ep_outbound_atu(struct dw_pcie *pci, u8 func_no, int
> index,
> > int type, u64 cpu_addr, u64 pci_addr,
> > - u32 size);
> > + u64 size);
> > int dw_pcie_prog_inbound_atu(struct dw_pcie *pci, u8 func_no, int
index,
> > int bar, u64 cpu_addr,
> > enum dw_pcie_as_type as_type);
> > --
> > 2.7.4
> >
RE: [PATCH v2] PCI: endpoint: Fix NULL pointer dereference for ->get_features()
> From: Bjorn Helgaas
> Subject: Re: [PATCH v2] PCI: endpoint: Fix NULL pointer dereference for -
> >get_features()
>
> On Fri, Dec 18, 2020 at 09:15:16PM +0530, Shradha Todi wrote:
> > get_features ops of pci_epc_ops may return NULL, causing NULL pointer
> > dereference in pci_epf_test_bind function. Let us add a check for
> > pci_epc_feature pointer in pci_epf_test_bind before we access it to
> > avoid any such NULL pointer dereference and return -ENOTSUPP in case
> > pci_epc_feature is not found.
>
> Can you add a Fixes: tag to identify where this broke to help people
decide
> where to backport the fix?
>
Thanks for the review. Sure we will add the Fixes tag and respin this patch.
> > Reviewed-by: Pankaj Dubey
> > Signed-off-by: Sriram Dash
> > Signed-off-by: Shradha Todi
> > ---
> > v2:
> > rebase on v1
> > v1:
> > https://protect2.fireeye.com/v1/url?k=6193fa90-3e08c3dd-619271df-0cc47
> > aa8f5ba-a79111ee2c1d1660=1=a9ee1ef7-2713-4099-8d06-
> 738532d78b26=
> > https%3A%2F%2Flore.kernel.org%2Fpatchwork%2Fpatch%2F1208269%2F
> >
> > drivers/pci/endpoint/functions/pci-epf-test.c | 13 -
> > 1 file changed, 8 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c
> > b/drivers/pci/endpoint/functions/pci-epf-test.c
> > index 66723d5..f1842e6 100644
> > --- a/drivers/pci/endpoint/functions/pci-epf-test.c
> > +++ b/drivers/pci/endpoint/functions/pci-epf-test.c
> > @@ -835,13 +835,16 @@ static int pci_epf_test_bind(struct pci_epf *epf)
> > return -EINVAL;
> >
> > epc_features = pci_epc_get_features(epc, epf->func_no);
> > - if (epc_features) {
> > - linkup_notifier = epc_features->linkup_notifier;
> > - core_init_notifier = epc_features->core_init_notifier;
> > - test_reg_bar = pci_epc_get_first_free_bar(epc_features);
> > - pci_epf_configure_bar(epf, epc_features);
> > + if (!epc_features) {
> > + dev_err(>dev, "epc_features not implemented\n");
> > + return -EOPNOTSUPP;
> > }
> >
> > + linkup_notifier = epc_features->linkup_notifier;
> > + core_init_notifier = epc_features->core_init_notifier;
> > + test_reg_bar = pci_epc_get_first_free_bar(epc_features);
> > + pci_epf_configure_bar(epf, epc_features);
> > +
> > epf_test->test_reg_bar = test_reg_bar;
> > epf_test->epc_features = epc_features;
> >
> > --
> > 2.7.4
> >
Re: [PATCH v2] usb: host: xhci-plat: fix support for XHCI_SKIP_PHY_INIT quirk
On 20-12-23 17:18:47, Pali Rohár wrote:
> Currently init_quirk callbacks for xhci platform drivers are called
> xhci_plat_setup() function which is called after chip reset completes.
> It happens in the middle of the usb_add_hcd() function.
>
> But XHCI_SKIP_PHY_INIT quirk is checked in the xhci_plat_probe() function
> prior calling usb_add_hcd() function. Therefore this XHCI_SKIP_PHY_INIT
> currently does nothing as prior xhci_plat_setup() it is not set.
>
> Quirk XHCI_SKIP_PHY_INIT is only setting hcd->skip_phy_initialization value
> which really needs to be set prior calling usb_add_hcd() as this function
> at its beginning skips PHY init if this member is set.
>
> This patch fixes implementation of the XHCI_SKIP_PHY_INIT quirk by calling
> init_quirk callbacks (via xhci_priv_init_quirk()) prior checking if
> XHCI_SKIP_PHY_INIT is set. Also checking if either xhci->quirks or
> priv->quirks contains this XHCI_SKIP_PHY_INIT quirk.
>
> Signed-off-by: Pali Rohár
>
> ---
> Changes in v2:
> * Check also xhci->quirks as xhci_priv_init_quirk() callbacks are setting
> xhci->quirks
> * Tested with "usb: host: xhci: mvebu: make USB 3.0 PHY optional for Armada
> 3720" patch
> * Removed Fixes: line
> ---
> drivers/usb/host/xhci-plat.c | 16
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
> index 4d34f6005381..0eab7cb5a767 100644
> --- a/drivers/usb/host/xhci-plat.c
> +++ b/drivers/usb/host/xhci-plat.c
> @@ -89,13 +89,6 @@ static void xhci_plat_quirks(struct device *dev, struct
> xhci_hcd *xhci)
> /* called during probe() after chip reset completes */
> static int xhci_plat_setup(struct usb_hcd *hcd)
> {
> - int ret;
> -
> -
> - ret = xhci_priv_init_quirk(hcd);
> - if (ret)
> - return ret;
> -
> return xhci_gen_setup(hcd, xhci_plat_quirks);
> }
>
> @@ -330,7 +323,14 @@ static int xhci_plat_probe(struct platform_device *pdev)
>
> hcd->tpl_support = of_usb_host_tpl_support(sysdev->of_node);
> xhci->shared_hcd->tpl_support = hcd->tpl_support;
> - if (priv && (priv->quirks & XHCI_SKIP_PHY_INIT))
> +
> + if (priv) {
> + ret = xhci_priv_init_quirk(hcd);
> + if (ret)
> + goto disable_usb_phy;
> + }
> +
> + if ((xhci->quirks & XHCI_SKIP_PHY_INIT) || (priv && (priv->quirks &
> XHCI_SKIP_PHY_INIT)))
> hcd->skip_phy_initialization = 1;
I am not sure if others agree with you move the position of
xhci_priv_init_quirk, Let's see Mathias opinion.
--
Thanks,
Peter Chen
Re: [PATCH] usb: host: xhci: mvebu: make USB 3.0 PHY optional for Armada 3720
On 20-12-23 17:24:03, Pali Rohár wrote:
> Older ATF does not provide SMC call for USB 3.0 phy power on functionality
> and therefore initialization of xhci-hcd is failing when older version of
> ATF is used. In this case phy_power_on() function returns -EOPNOTSUPP.
>
> [3.108467] mvebu-a3700-comphy d0018300.phy: unsupported SMC call, try
> updating your firmware
> [3.117250] phy phy-d0018300.phy.0: phy poweron failed --> -95
> [3.123465] xhci-hcd: probe of d0058000.usb failed with error -95
>
> This patch calls phy_power_on() in xhci_mvebu_a3700_init_quirk() function
> and in case it returns -EOPNOTSUPP then XHCI_SKIP_PHY_INIT quirk is set to
> instruct xhci-plat to skip PHY initialization.
>
> This patch fixes above failure by ignoring 'not supported' error in
> aardvark driver. In this case it is expected that phy is already power on.
>
> It fixes initialization of xhci-hcd on Espressobin boards where is older
> Marvell's Arm Trusted Firmware without SMC call for USB 3.0 phy power.
>
> This is regression introduced in commit bd3d25b07342 ("arm64: dts: marvell:
> armada-37xx: link USB hosts with their PHYs") where USB 3.0 phy was defined
> and therefore xhci-hcd on Espressobin with older ATF started failing.
>
> Fixes: bd3d25b07342 ("arm64: dts: marvell: armada-37xx: link USB hosts with
> their PHYs")
> Signed-off-by: Pali Rohár
> Cc: # 5.1+: ea17a0f153af: phy: marvell: comphy:
> Convert internal SMCC firmware return codes to errno
> Cc: # 5.1+: f768e718911e: usb: host: xhci-plat: add
> priv quirk for skip PHY initialization
>
> ---
>
> When applying this patch, please include additional line
>
> Cc: # 5.1+: : usb: host: xhci-plat: fix
> support for XHCI_SKIP_PHY_INIT quirk
>
> with correct COMMIT_ID of mentioned patch which is available in the thread:
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Flkml%2F20201221150903.26630-1-pali%40kernel.org%2FT%2F%23udata=04%7C01%7Cpeter.chen%40nxp.com%7Ccc158fcd30104268b27008d8a75f32e1%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637443374600182963%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=vjuJxi9Kg1C7ZHJLB7rsct0kr93JSo4aYkitFubkLao%3Dreserved=0
>
> As mentioned patch is required for change in this patch to work. Above
> mentioned patch is prerequisite for this patch and therefore needs to be
> reviewed and applied prior this patch.
>
> Note that same issue as in this USB 3.0 PHY patch was already resolved and
> applied also for SATA PHY and PCIe PHY on A3720 SOC in following commits:
>
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Ftorvalds%2Flinux.git%2Fcommit%2F%3Fid%3D45aefe3d2251e4e229d7662052739f96ad1d08d9data=04%7C01%7Cpeter.chen%40nxp.com%7Ccc158fcd30104268b27008d8a75f32e1%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637443374600182963%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=%2FIULc1sakzNVWjbVPA2TRYZAMv72DGOhmYv4NGijrT8%3Dreserved=0
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Ftorvalds%2Flinux.git%2Fcommit%2F%3Fid%3Db0c6ae0f8948a2be6bf4e8b4bbab9ca1343289b6data=04%7C01%7Cpeter.chen%40nxp.com%7Ccc158fcd30104268b27008d8a75f32e1%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637443374600182963%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=2mLHMBc9lgpB4BCrlJYBfO7OJk%2BCi%2Bq3AgpxJxfiCSU%3Dreserved=0
>
> And these commits were also backported to stable kernel versions (where
> were affected commits which broke drivers initialization).
> ---
> drivers/usb/host/xhci-mvebu.c | 35 +++
> 1 file changed, 35 insertions(+)
>
> diff --git a/drivers/usb/host/xhci-mvebu.c b/drivers/usb/host/xhci-mvebu.c
> index 60651a50770f..ec4f6d6e44cf 100644
> --- a/drivers/usb/host/xhci-mvebu.c
> +++ b/drivers/usb/host/xhci-mvebu.c
> @@ -8,6 +8,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -77,9 +78,43 @@ int xhci_mvebu_mbus_init_quirk(struct usb_hcd *hcd)
> int xhci_mvebu_a3700_init_quirk(struct usb_hcd *hcd)
> {
> struct xhci_hcd *xhci = hcd_to_xhci(hcd);
> + struct device *dev = hcd->self.controller;
> + struct phy *phy;
> + int ret;
>
> /* Without reset on resume, the HC won't work at all */
> xhci->quirks |= XHCI_RESET_ON_RESUME;
>
> + /* Old bindings miss the PHY handle */
> + phy = of_phy_get(dev->of_node, "usb3-phy");
> + if (IS_ERR(phy) && PTR_ERR(phy) == -EPROBE_DEFER)
> + return -EPROBE_DEFER;
Doesn't need to judge IS_ERR(phy).
> + else if (IS_ERR(phy))
> + goto phy_out;
> +
> + ret = phy_init(phy);
> + if (ret)
> + goto phy_put;
> +
> + ret = phy_set_mode(phy, PHY_MODE_USB_HOST_SS);
> + if (ret)
>
RE: [PATCH] PCI: dwc: Add upper limit address for outbound iATU
> From: Rob Herring > Subject: Re: [PATCH] PCI: dwc: Add upper limit address for outbound iATU > > On Sun, Dec 20, 2020 at 6:56 PM Shradha Todi > wrote: > > > > The size parameter is unsigned long type which can accept size > 4GB. > > In that case, the upper limit address must be programmed. Add support > > to program the upper limit address and set INCREASE_REGION_SIZE in > > case size > 4GB. > > Not all DWC h/w versions have the upper register and bit. Is it safe to write > to > the non-existent register? Thanks for the review. Surely it exists post 4.80a version of controller but I am not sure in which version of the controller this was introduced. I can figure this out from the SNPS team and update the patch accordingly. > > > > > Signed-off-by: Shradha Todi > > --- > > drivers/pci/controller/dwc/pcie-designware.c | 8 ++-- > > drivers/pci/controller/dwc/pcie-designware.h | 1 + > > 2 files changed, 7 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/pci/controller/dwc/pcie-designware.c > > b/drivers/pci/controller/dwc/pcie-designware.c > > index 28c56a1..7eba3b2 100644 > > --- a/drivers/pci/controller/dwc/pcie-designware.c > > +++ b/drivers/pci/controller/dwc/pcie-designware.c > > @@ -290,12 +290,16 @@ static void __dw_pcie_prog_outbound_atu(struct > dw_pcie *pci, u8 func_no, > >upper_32_bits(cpu_addr)); > > dw_pcie_writel_dbi(pci, PCIE_ATU_LIMIT, > >lower_32_bits(cpu_addr + size - 1)); > > + dw_pcie_writel_dbi(pci, PCIE_ATU_UPPER_LIMIT, > > + upper_32_bits(cpu_addr + size - 1)); > > If not safe, perhaps only write if non-zero. > Writing zero has no side-affect and we have tested this. > > dw_pcie_writel_dbi(pci, PCIE_ATU_LOWER_TARGET, > >lower_32_bits(pci_addr)); > > dw_pcie_writel_dbi(pci, PCIE_ATU_UPPER_TARGET, > >upper_32_bits(pci_addr)); > > - dw_pcie_writel_dbi(pci, PCIE_ATU_CR1, type | > > - PCIE_ATU_FUNC_NUM(func_no)); > > + val = type | PCIE_ATU_FUNC_NUM(func_no); > > + val = upper_32_bits(size - 1) ? > > + val | PCIE_ATU_INCREASE_REGION_SIZE : val; > > + dw_pcie_writel_dbi(pci, PCIE_ATU_CR1, val); > > dw_pcie_writel_dbi(pci, PCIE_ATU_CR2, PCIE_ATU_ENABLE); > > > > /* > > diff --git a/drivers/pci/controller/dwc/pcie-designware.h > > b/drivers/pci/controller/dwc/pcie-designware.h > > index b09329b..28b72fb 100644 > > --- a/drivers/pci/controller/dwc/pcie-designware.h > > +++ b/drivers/pci/controller/dwc/pcie-designware.h > > @@ -106,6 +106,7 @@ > > #define PCIE_ATU_DEV(x)FIELD_PREP(GENMASK(23, 19), > > x) > > #define PCIE_ATU_FUNC(x) FIELD_PREP(GENMASK(18, 16), x) > > #define PCIE_ATU_UPPER_TARGET 0x91C > > +#define PCIE_ATU_UPPER_LIMIT 0x924 > > > > #define PCIE_MISC_CONTROL_1_OFF0x8BC > > #define PCIE_DBI_RO_WR_EN BIT(0) > > -- > > 2.7.4 > >
drivers/clocksource/timer-clint.c:72:24: sparse: sparse: cast removes address space '__iomem' of expression
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 58cf05f597b03a8212d9ecf2c79ee046d3ee8ad9
commit: 2ac6795fcc085e8d03649f1bbd0d70aaff612cad clocksource/drivers: Add CLINT
timer driver
date: 4 months ago
config: riscv-randconfig-s031-20201221 (attached as .config)
compiler: riscv32-linux-gcc (GCC) 9.3.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# apt-get install sparse
# sparse version: v0.6.3-184-g1b896707-dirty
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2ac6795fcc085e8d03649f1bbd0d70aaff612cad
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 2ac6795fcc085e8d03649f1bbd0d70aaff612cad
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1
CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=riscv
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
"sparse warnings: (new ones prefixed by >>)"
>> drivers/clocksource/timer-clint.c:72:24: sparse: sparse: cast removes
>> address space '__iomem' of expression
>> drivers/clocksource/timer-clint.c:72:24: sparse: sparse: incorrect type in
>> argument 1 (different address spaces) @@ expected void const volatile
>> [noderef] __iomem *addr @@ got unsigned int [usertype] * @@
drivers/clocksource/timer-clint.c:72:24: sparse: expected void const
volatile [noderef] __iomem *addr
drivers/clocksource/timer-clint.c:72:24: sparse: got unsigned int
[usertype] *
drivers/clocksource/timer-clint.c:70:22: sparse: sparse: cast removes
address space '__iomem' of expression
drivers/clocksource/timer-clint.c:70:22: sparse: sparse: incorrect type in
argument 1 (different address spaces) @@ expected void const volatile
[noderef] __iomem *addr @@ got unsigned int [usertype] * @@
drivers/clocksource/timer-clint.c:70:22: sparse: expected void const
volatile [noderef] __iomem *addr
drivers/clocksource/timer-clint.c:70:22: sparse: got unsigned int
[usertype] *
drivers/clocksource/timer-clint.c:219:36: sparse: sparse: incorrect type in
argument 2 (different address spaces) @@ expected void * @@ got struct
clock_event_device [noderef] __percpu * @@
drivers/clocksource/timer-clint.c:219:36: sparse: expected void *
drivers/clocksource/timer-clint.c:219:36: sparse: got struct
clock_event_device [noderef] __percpu *
vim +/__iomem +72 drivers/clocksource/timer-clint.c
58
59 #ifdef CONFIG_64BIT
60 static u64 notrace clint_get_cycles64(void)
61 {
62 return clint_get_cycles();
63 }
64 #else /* CONFIG_64BIT */
65 static u64 notrace clint_get_cycles64(void)
66 {
67 u32 hi, lo;
68
69 do {
70 hi = clint_get_cycles_hi();
71 lo = clint_get_cycles();
> 72 } while (hi != clint_get_cycles_hi());
73
74 return ((u64)hi << 32) | lo;
75 }
76 #endif /* CONFIG_64BIT */
77
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
[PATCH] fs: delete repeated words in comments
Delete duplicate words in fs/*.c.
The doubled words that are being dropped are:
that, be, the, in, and, for
Signed-off-by: Randy Dunlap
Cc: Andrew Morton
Cc: Alexander Viro
Cc: linux-fsde...@vger.kernel.org
---
fs/block_dev.c |2 +-
fs/dcache.c|4 ++--
fs/direct-io.c |4 ++--
fs/exec.c |4 ++--
fs/fhandle.c |2 +-
fs/pipe.c |2 +-
6 files changed, 9 insertions(+), 9 deletions(-)
--- linux-next-20201223.orig/fs/block_dev.c
+++ linux-next-20201223/fs/block_dev.c
@@ -1260,7 +1260,7 @@ rescan:
return ret;
}
/*
- * Only exported for for loop and dasd for historic reasons. Don't use in new
+ * Only exported for loop and dasd for historic reasons. Don't use in new
* code!
*/
EXPORT_SYMBOL_GPL(bdev_disk_changed);
--- linux-next-20201223.orig/fs/dcache.c
+++ linux-next-20201223/fs/dcache.c
@@ -2150,8 +2150,8 @@ EXPORT_SYMBOL(d_obtain_root);
* same inode, only the actual correct case is stored in the dcache for
* case-insensitive filesystems.
*
- * For a case-insensitive lookup match and if the the case-exact dentry
- * already exists in in the dcache, use it and return it.
+ * For a case-insensitive lookup match and if the case-exact dentry
+ * already exists in the dcache, use it and return it.
*
* If no entry exists with the exact case name, allocate new dentry with
* the exact case, and return the spliced entry.
--- linux-next-20201223.orig/fs/direct-io.c
+++ linux-next-20201223/fs/direct-io.c
@@ -460,7 +460,7 @@ static inline void dio_cleanup(struct di
* Wait for the next BIO to complete. Remove it and return it. NULL is
* returned once all BIOs have been completed. This must only be called once
* all bios have been issued so that dio->refcount can only decrease. This
- * requires that that the caller hold a reference on the dio.
+ * requires that the caller hold a reference on the dio.
*/
static struct bio *dio_await_one(struct dio *dio)
{
@@ -1277,7 +1277,7 @@ do_blockdev_direct_IO(struct kiocb *iocb
if (retval == -ENOTBLK) {
/*
* The remaining part of the request will be
-* be handled by buffered I/O when we return
+* handled by buffered I/O when we return
*/
retval = 0;
}
--- linux-next-20201223.orig/fs/exec.c
+++ linux-next-20201223/fs/exec.c
@@ -1454,7 +1454,7 @@ EXPORT_SYMBOL(finalize_exec);
/*
* Prepare credentials and lock ->cred_guard_mutex.
* setup_new_exec() commits the new creds and drops the lock.
- * Or, if exec fails before, free_bprm() should release ->cred and
+ * Or, if exec fails before, free_bprm() should release ->cred
* and unlock.
*/
static int prepare_bprm_creds(struct linux_binprm *bprm)
@@ -1837,7 +1837,7 @@ static int bprm_execve(struct linux_binp
out:
/*
-* If past the point of no return ensure the the code never
+* If past the point of no return ensure the code never
* returns to the userspace process. Use an existing fatal
* signal if present otherwise terminate the process with
* SIGSEGV.
--- linux-next-20201223.orig/fs/fhandle.c
+++ linux-next-20201223/fs/fhandle.c
@@ -173,7 +173,7 @@ static int handle_to_path(int mountdirfd
/*
* With handle we don't look at the execute bit on the
-* the directory. Ideally we would like CAP_DAC_SEARCH.
+* directory. Ideally we would like CAP_DAC_SEARCH.
* But we don't have that
*/
if (!capable(CAP_DAC_READ_SEARCH)) {
--- linux-next-20201223.orig/fs/pipe.c
+++ linux-next-20201223/fs/pipe.c
@@ -171,7 +171,7 @@ EXPORT_SYMBOL(generic_pipe_buf_try_steal
*
* Description:
* This function grabs an extra reference to @buf. It's used in
- * in the tee() system call, when we duplicate the buffers in one
+ * the tee() system call, when we duplicate the buffers in one
* pipe into another.
*/
bool generic_pipe_buf_get(struct pipe_inode_info *pipe, struct pipe_buffer
*buf)
Re: [PATCH] mm/userfaultfd: fix memory corruption due to writeprotect
> On Dec 23, 2020, at 8:01 PM, Andrea Arcangeli wrote: > >> On Wed, Dec 23, 2020 at 07:09:10PM -0800, Nadav Amit wrote: >>> Perhaps holding some small bitmap based on part of the deferred flushed >>> pages (e.g., bits 12-17 of the address or some other kind of a single >>> hash-function bloom-filter) would be more performant to avoid (most) > > The concern here aren't only the page faults having to run the bloom > filter, but how to manage the RAM storage pointed by the bloomfilter > or whatever index into the storage, which would slowdown mprotect. > > Granted that mprotect is slow to begin with, but the idea we can't make > it any slower to make MADV_PAGEOUT or uffd-wp or clear_refs run > faster since it's too important and too frequent in comparison. > > Just to restrict the potential false positive IPI caused by page_count > inevitable inaccuracies to uffd-wp and softdirty runtimes, a simple > check on vm_flags should be enough. Andrea, I am not trying to be argumentative, and I did not think through about an alternative solution. It sounds to me that your proposed solution is correct and would probably be eventually (slightly) more efficient than anything that I can propose. Yet, I do want to explain my position. Reasoning on TLB flushes is hard, as this long thread shows. The question is whether it has to be so hard. In theory, we can only think about architectural considerations - whether a PTE permissions are promoted/demoted and whether the PTE was changed/cleared. Obviously, it is more complex than that. Yet, once you add into the equation various parameters such as the VMA flags or whether a page is locked (which Mel told me was once a consideration), things become much more complicated. If all the logic of TLB flushes had been concentrated in a single point and maintenance of this code did not require thought about users and use-cases, I think things would have been much simpler, at least for me. Regards, Nadav
Re: [PATCH v5] s390/vfio-ap: clean up vfio_ap resources when KVM pointer invalidated
On Tue, 22 Dec 2020 20:20:13 -0500
Tony Krowiak wrote:
> The vfio_ap device driver registers a group notifier with VFIO when the
> file descriptor for a VFIO mediated device for a KVM guest is opened to
> receive notification that the KVM pointer is set (VFIO_GROUP_NOTIFY_SET_KVM
> event). When the KVM pointer is set, the vfio_ap driver takes the
> following actions:
> 1. Stashes the KVM pointer in the vfio_ap_mdev struct that holds the state
>of the mediated device.
> 2. Calls the kvm_get_kvm() function to increment its reference counter.
> 3. Sets the function pointer to the function that handles interception of
>the instruction that enables/disables interrupt processing.
> 4. Sets the masks in the KVM guest's CRYCB to pass AP resources through to
>the guest.
>
> In order to avoid memory leaks, when the notifier is called to receive
> notification that the KVM pointer has been set to NULL, the vfio_ap device
> driver should reverse the actions taken when the KVM pointer was set.
>
> Fixes: 258287c994de ("s390: vfio-ap: implement mediated device open callback")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Tony Krowiak
> Reviewed-by: Halil Pasic
> Reviewed-by: Cornelia Huck
LGTM.
Christian, you wanted to pick this yourself directly, or? I think we are
good to go!
Re: [PATCH] x86/entry: use STB_GLOBAL for register restoring thunk
On Wed, Dec 23, 2020 at 03:21:26PM -0800, Nick Desaulniers wrote: > Arnd found a randconfig that produces the warning: > > arch/x86/entry/thunk_64.o: warning: objtool: missing symbol for insn at > offset 0x3e > > when building with LLVM_IAS=1 (use Clang's integrated assembler). Josh > notes: > > With the LLVM assembler stripping the .text section symbol, objtool > has no way to reference this code when it generates ORC unwinder > entries, because this code is outside of any ELF function. > > This behavior was implemented as an optimization in LLVM 5 years ago, > but it's not the first time this has caused issues for objtool. A patch > has been authored against LLVM to revert the behavior, which may or may > not be accepted. Until then use a global symbol for the thunk that way > objtool can generate proper unwind info here with LLVM_IAS=1. As Fangrui pointed out, the section symbol stripping is useful for when there are a ton of sections like '-ffunction-sections' and '-fdata-sections'. Maybe add that justification to the patch description. We can try to support it, though I suspect other tools may also end up getting surprised. > Cc: Fangrui Song > Reported-by: Arnd Bergmann > Suggested-by: Josh Poimboeuf > Link: https://github.com/ClangBuiltLinux/linux/issues/1209 > Link: https://reviews.llvm.org/D93783 > Signed-off-by: Nick Desaulniers Code looks familiar ;-) Acked-by: Josh Poimboeuf -- Josh
drivers/clocksource/timer-clint.c:72:24: sparse: sparse: cast removes address space '__iomem' of expression
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 58cf05f597b03a8212d9ecf2c79ee046d3ee8ad9
commit: 2ac6795fcc085e8d03649f1bbd0d70aaff612cad clocksource/drivers: Add CLINT
timer driver
date: 4 months ago
config: riscv-randconfig-s031-20201221 (attached as .config)
compiler: riscv32-linux-gcc (GCC) 9.3.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# apt-get install sparse
# sparse version: v0.6.3-184-g1b896707-dirty
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2ac6795fcc085e8d03649f1bbd0d70aaff612cad
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 2ac6795fcc085e8d03649f1bbd0d70aaff612cad
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1
CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=riscv
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
"sparse warnings: (new ones prefixed by >>)"
>> drivers/clocksource/timer-clint.c:72:24: sparse: sparse: cast removes
>> address space '__iomem' of expression
>> drivers/clocksource/timer-clint.c:72:24: sparse: sparse: incorrect type in
>> argument 1 (different address spaces) @@ expected void const volatile
>> [noderef] __iomem *addr @@ got unsigned int [usertype] * @@
drivers/clocksource/timer-clint.c:72:24: sparse: expected void const
volatile [noderef] __iomem *addr
drivers/clocksource/timer-clint.c:72:24: sparse: got unsigned int
[usertype] *
drivers/clocksource/timer-clint.c:70:22: sparse: sparse: cast removes
address space '__iomem' of expression
drivers/clocksource/timer-clint.c:70:22: sparse: sparse: incorrect type in
argument 1 (different address spaces) @@ expected void const volatile
[noderef] __iomem *addr @@ got unsigned int [usertype] * @@
drivers/clocksource/timer-clint.c:70:22: sparse: expected void const
volatile [noderef] __iomem *addr
drivers/clocksource/timer-clint.c:70:22: sparse: got unsigned int
[usertype] *
drivers/clocksource/timer-clint.c:219:36: sparse: sparse: incorrect type in
argument 2 (different address spaces) @@ expected void * @@ got struct
clock_event_device [noderef] __percpu * @@
drivers/clocksource/timer-clint.c:219:36: sparse: expected void *
drivers/clocksource/timer-clint.c:219:36: sparse: got struct
clock_event_device [noderef] __percpu *
vim +/__iomem +72 drivers/clocksource/timer-clint.c
58
59 #ifdef CONFIG_64BIT
60 static u64 notrace clint_get_cycles64(void)
61 {
62 return clint_get_cycles();
63 }
64 #else /* CONFIG_64BIT */
65 static u64 notrace clint_get_cycles64(void)
66 {
67 u32 hi, lo;
68
69 do {
70 hi = clint_get_cycles_hi();
71 lo = clint_get_cycles();
> 72 } while (hi != clint_get_cycles_hi());
73
74 return ((u64)hi << 32) | lo;
75 }
76 #endif /* CONFIG_64BIT */
77
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
[PATCH] fs: Fix freeze_bdev()/thaw_bdev() accounting of bd_fsfreeze_sb
freeze/thaw_bdev() currently use bdev->bd_fsfreeze_count to infer
whether or not bdev->bd_fsfreeze_sb is valid (it's valid iff
bd_fsfreeze_count is non-zero). thaw_bdev() doesn't nullify
bd_fsfreeze_sb.
But this means a freeze_bdev() call followed by a thaw_bdev() call can
leave bd_fsfreeze_sb with a non-null value, while bd_fsfreeze_count is
zero. If freeze_bdev() is called again, and this time
get_active_super() returns NULL (e.g. because the FS is unmounted),
we'll end up with bd_fsfreeze_count > 0, but bd_fsfreeze_sb is
*untouched* - it stays the same (now garbage) value. A subsequent
thaw_bdev() will decide that the bd_fsfreeze_sb value is legitimate
(since bd_fsfreeze_count > 0), and attempt to use it.
Fix this by always setting bd_fsfreeze_sb to NULL when
bd_fsfreeze_count is successfully decremented to 0 in thaw_sb().
Alternatively, we could set bd_fsfreeze_sb to whatever
get_active_super() returns in freeze_bdev() whenever bd_fsfreeze_count
is successfully incremented to 1 from 0 (which can be achieved cleanly
by moving the line currently setting bd_fsfreeze_sb to immediately
after the "sync:" label, but it might be a little too subtle/easily
overlooked in future).
This fixes the currently panicking xfstests generic/085.
Fixes: 040f04bd2e82 ("fs: simplify freeze_bdev/thaw_bdev")
Signed-off-by: Satya Tangirala
---
fs/block_dev.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/fs/block_dev.c b/fs/block_dev.c
index 9e56ee1f2652..12a811a9ae4b 100644
--- a/fs/block_dev.c
+++ b/fs/block_dev.c
@@ -606,6 +606,8 @@ int thaw_bdev(struct block_device *bdev)
error = thaw_super(sb);
if (error)
bdev->bd_fsfreeze_count++;
+ else
+ bdev->bd_fsfreeze_sb = NULL;
out:
mutex_unlock(>bd_fsfreeze_mutex);
return error;
--
2.29.2.729.g45daf8777d-goog
Re: update.c:undefined reference to `irq_work_queue'
On Wed, Dec 23, 2020 at 12:06:07PM -0800, Randy Dunlap wrote: > On 12/21/20 9:03 PM, Paul E. McKenney wrote: > > On Tue, Dec 22, 2020 at 11:24:22AM +0800, kernel test robot wrote: > > > tree: > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master > > > head: 8653b778e454a7708847aeafe689bce07aeeb94e > > > commit: b38f57c1fe64276773b124dffb0a139cc32ab3cb rcu-tasks: Allow > > > rcu_read_unlock_trace() under scheduler locks > > > date: 8 months ago > > > config: h8300-randconfig-s032-20201220 (attached as .config) > > > compiler: h8300-linux-gcc (GCC) 9.3.0 > > > reproduce: > > > wget > > > https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross > > > -O ~/bin/make.cross > > > chmod +x ~/bin/make.cross > > > # apt-get install sparse > > > # sparse version: v0.6.3-184-g1b896707-dirty > > > # > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b38f57c1fe64276773b124dffb0a139cc32ab3cb > > > git remote add linus > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > > > git fetch --no-tags linus master > > > git checkout b38f57c1fe64276773b124dffb0a139cc32ab3cb > > > # save the attached .config to linux build tree > > > COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross > > > C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=h8300 > > > > > > If you fix the issue, kindly add following tag as appropriate > > > Reported-by: kernel test robot > > > > > > All errors (new ones prefixed by >>): > > > > > > h8300-linux-ld: section .init.text LMA > > > [0043a160,00452569] overlaps section .rodata LMA > > > [003ff420,0047df2f] > > > h8300-linux-ld: section .data VMA [0040,0043a15f] > > > overlaps section .rodata VMA [003ff420,0047df2f] > > > h8300-linux-ld: section __ksymtab VMA > > > [0047df30,0048611f] overlaps section .bss VMA > > > [0045ebd0,0056a053] > > > h8300-linux-ld: kernel/rcu/update.o: in function > > > `rcu_read_unlock_trace_special': > > > > > update.c:(.text+0x8f9): undefined reference to `irq_work_queue' > > > > Does the patch below help? > > > > Thanx, Paul > > > > > > > > commit cb7220ed05190c9a92df95b52a21525a7e08a449 > > Author: Paul E. McKenney > > Date: Mon Dec 21 21:00:18 2020 -0800 > > > > rcu: Make TASKS_TRACE_RCU select IRQ_WORK > > Tasks Trace RCU uses irq_work_queue() to safely awaken its grace-period > > kthread, so this commit therefore causes the TASKS_TRACE_RCU Kconfig > > option select the IRQ_WORK Kconfig option. > > Reported-by: kernel test robot > > Signed-off-by: Paul E. McKenney > > > > diff --git a/kernel/rcu/Kconfig b/kernel/rcu/Kconfig > > index aa8cc8c9..3128b7c 100644 > > --- a/kernel/rcu/Kconfig > > +++ b/kernel/rcu/Kconfig > > @@ -95,6 +95,7 @@ config TASKS_RUDE_RCU > > config TASKS_TRACE_RCU > > def_bool 0 > > + select IRQ_WORK > > help > > This option enables a task-based RCU implementation that uses > > explicit rcu_read_lock_trace() read-side markers, and allows > > > > WorksForMe. Thanks. > > Acked-by: Randy Dunlap # build-tested Thank you, I will apply on my next rebase. Thanx, Paul
Re: [PATCH] riscv: return -ENOSYS for syscall -1
On Wed, Dec 23, 2020 at 06:54:43PM -0800, Palmer Dabbelt wrote:
> On Wed, 23 Dec 2020 00:24:04 PST (-0800), Christoph Hellwig wrote:
> > On Tue, Dec 22, 2020 at 09:22:19AM -0700, Tycho Andersen wrote:
> > > On Mon, Dec 21, 2020 at 11:52:00PM +0100, Andreas Schwab wrote:
> > > > Properly return -ENOSYS for syscall -1 instead of leaving the return
> > > > value
> > > > uninitialized. This fixes the strace teststuite.
> > > >
> > > > Fixes: 5340627e3fe0 ("riscv: add support for SECCOMP and
> > > > SECCOMP_FILTER")
> > > > Signed-off-by: Andreas Schwab
> > > > ---
> > > > arch/riscv/kernel/entry.S | 9 +
> > > > 1 file changed, 1 insertion(+), 8 deletions(-)
> > > >
> > > > diff --git a/arch/riscv/kernel/entry.S b/arch/riscv/kernel/entry.S
> > > > index 524d918f3601..d07763001eb0 100644
> > > > --- a/arch/riscv/kernel/entry.S
> > > > +++ b/arch/riscv/kernel/entry.S
> > > > @@ -186,14 +186,7 @@ check_syscall_nr:
> > > > * Syscall number held in a7.
> > > > * If syscall number is above allowed value, redirect to
> > > > ni_syscall.
> > > > */
> > > > - bge a7, t0, 1f
> > > > - /*
> > > > -* Check if syscall is rejected by tracer, i.e., a7 == -1.
> > > > -* If yes, we pretend it was executed.
> > > > -*/
> > > > - li t1, -1
> > > > - beq a7, t1, ret_from_syscall_rejected
> > > > - blt a7, t1, 1f
> > > > + bgeu a7, t0, 1f
> > >
> > > IIUC, this is all dead code anyway for the path where seccomp actually
> > > rejects the syscall, since it should do the rejection directly in
> > > handle_syscall_trace_enter(), which is called above this hunk. So it
> > > seems good to me.
> >
> > That change really needs to be documented in the commit log, or even
> > better split into a separate patch (still documented of course!).
>
> Unless I'm missing something, this is already how it works already?
Yes, agreed. My musing was mostly just that this is dead code that
probably should have been in removed in af33d2433b03 ("riscv: fix
seccomp reject syscall code path"), but was overlooked. Maybe this
could use a Fixes: tag for that too.
Tycho
Re: [PATCH] mm/userfaultfd: fix memory corruption due to writeprotect
> On Dec 23, 2020, at 7:34 PM, Yu Zhao wrote:
>
> On Wed, Dec 23, 2020 at 07:09:10PM -0800, Nadav Amit wrote:
>>> On Dec 23, 2020, at 6:00 PM, Andrea Arcangeli wrote:
>>>
>>> On Wed, Dec 23, 2020 at 05:21:43PM -0800, Andy Lutomirski wrote:
I don’t love this as a long term fix. AFAICT we can have
mm_tlb_flush_pending set for quite a while — mprotect seems like it can
wait in IO while splitting a huge page, for example. That gives us a
window in which every write fault turns into a TLB flush.
>>>
>>> mprotect can't run concurrently with a page fault in the first place.
>>>
>>> One other near zero cost improvement easy to add if this would be "if
>>> (vma->vm_flags & (VM_SOFTDIRTY|VM_UFFD_WP))" and it could be made
>>> conditional to the two config options too.
>>>
>>> Still I don't mind doing it in some other way, uffd-wp has much easier
>>> time doing it in another way in fact.
>>>
>>> Whatever performs better is fine, but queuing up pending invalidate
>>> ranges don't look very attractive since it'd be a fixed cost that we'd
>>> always have to pay even when there's no fault (and there can't be any
>>> fault at least for mprotect).
>>
>> I think there are other cases in which Andy’s concern is relevant
>> (MADV_PAGEOUT).
>
> That patch only demonstrate a rough idea and I should have been
> elaborate: if we ever decide to go that direction, we only need to
> worry about "jumping through hoops", because the final patch (set)
> I have in mind would not only have the build time optimization Andrea
> suggested but also include runtime optimizations like skipping
> do_swap_page() path and (!PageAnon() || page_mapcount > 1). Rest
> assured, the performance impact on do_wp_page() from occasionally an
> additional TLB flush on top of a page copy is negligible.
I agree with you to a certain extent, since there is anyhow another TLB
flush in this path when the PTE is set after copying.
Yet, I think that having a combined and efficient central mechanism for
pending TLB flushes is important even for robustness: to prevent the
development of new independent deferred flushing schemes. I specifically do
not like tlb_flush_batched which every time that I look at gets me confused.
For example the following code completely confuses me:
void flush_tlb_batched_pending(struct mm_struct *mm)
{
if (data_race(mm->tlb_flush_batched)) {
flush_tlb_mm(mm);
/*
* Do not allow the compiler to re-order the clearing of
* tlb_flush_batched before the tlb is flushed.
*/
barrier();
mm->tlb_flush_batched = false;
}
}
… and then I ask myself (no answer):
1. What prevents concurrent flush_tlb_batched_pending() which is called by
madvise_free_pte_range(), for instance from madvise_free_pte_range(), from
clearing new deferred flush indication that was just set by
set_tlb_ubc_flush_pending()? Can it cause a missed TLB flush later?
2. Why the write to tlb_flush_batched is not done with WRITE_ONCE()?
3. Should we have smp_wmb() instead of barrier()? (probably the barrier() is
not needed at all since flush_tlb_mm() serializes if a flush is needed).
4. Why do we need 2 deferred TLB flushing mechanisms?
[GIT PULL] RISC-V Fixes for 5.11-rc1 (or rc2, if it's too late)
merged tag 'riscv-for-linus-5.11-mw0' The following changes since commit e2ae634014d3a8839a99f8897b3f6346a133a33b: Merge tag 'riscv-for-linus-5.11-mw0' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux (2020-12-18 10:43:07 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git tags/riscv-for-linus-5.11-rc1 for you to fetch changes up to de043da0b9e71147ca610ed542d34858aadfc61c: RISC-V: Fix usage of memblock_enforce_memory_limit (2020-12-21 21:02:14 -0800) RISC-V Fixes for 5.11-rc1 * A fix that avoids trying to initialize memory regions outside the usable range. --- I know it's an odd time, but I figured it'd be better to just send this out. There's a few other fixes on the list that I was considering including, but there's enough discussion that I didn't want to rush those over the holidays. I don't see any reason to delay this one any longer, though, as it's relevant to the ongoing QEMU work. Atish Patra (1): RISC-V: Fix usage of memblock_enforce_memory_limit arch/riscv/mm/init.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
[PATCH] genirq: Limit irq_calc_affinity_vectors to housekeeping CPUs
Replace the cpumask used in irq_calc_affinity_vectors from all possible
CPUs to only housekeeping CPUs.
When we have isolated CPUs used by real-time tasks, IRQs will be move to
housekeeping CPUs.
If there are too many IRQ vectors, moving the all to housekeeping CPUs may
exceed per-CPU vector limits. For example, when I only have two
housekeeping CPUs, there are dozens of IRQs on two CPUs, but actually one
IRQ per housekeeping CPU is enough.
Signed-off-by: Liu Chao
---
kernel/irq/affinity.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/kernel/irq/affinity.c b/kernel/irq/affinity.c
index 4d89ad4fae3b..3f22e3314e1b 100644
--- a/kernel/irq/affinity.c
+++ b/kernel/irq/affinity.c
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
static void irq_spread_init_one(struct cpumask *irqmsk, struct cpumask *nmsk,
unsigned int cpus_per_vec)
@@ -506,7 +507,8 @@ unsigned int irq_calc_affinity_vectors(unsigned int minvec,
unsigned int maxvec,
set_vecs = maxvec - resv;
} else {
get_online_cpus();
- set_vecs = cpumask_weight(cpu_possible_mask);
+ set_vecs = cpumask_weight(
+ housekeeping_cpumask(HK_FLAG_MANAGED_IRQ));
put_online_cpus();
}
--
2.23.0
Re: [PATCH v2 15/48] opp: Support set_opp() customization without requiring to use regulators
On 23-12-20, 23:38, Dmitry Osipenko wrote: > Well, there is no "same structure", the opp_table->set_opp_data is NULL > there. Right, I saw that yesterday. What I meant was that we need to start allocating the structure for this case now. -- viresh
Re: [PATCH 1/2] mm: Allow architectures to request 'old' entries when prefaulting
On Tue, 22 Dec 2020, Kirill A. Shutemov wrote:
>
> Updated patch is below.
>
> From 0ec1bc1fe95587350ac4f4c866d6482383740b36 Mon Sep 17 00:00:00 2001
> From: "Kirill A. Shutemov"
> Date: Sat, 19 Dec 2020 15:19:23 +0300
> Subject: [PATCH] mm: Cleanup faultaround and finish_fault() codepaths
>
> alloc_set_pte() has two users with different requirements: in the
> faultaround code, it called from an atomic context and PTE page table
> has to be preallocated. finish_fault() can sleep and allocate page table
> as needed.
>
> PTL locking rules are also strange, hard to follow and overkill for
> finish_fault().
>
> Let's untangle the mess. alloc_set_pte() has gone now. All locking is
> explicit.
>
> The price is some code duplication to handle huge pages in faultaround
> path, but it should be fine, having overall improvement in readability.
>
> Signed-off-by: Kirill A. Shutemov
It's not ready yet.
I won't pretend to have reviewed, but I did try applying and running
with it: mostly it seems to work fine, but turned out to be leaking
huge pages (with vmstat's thp_split_page_failed growing bigger and
bigger as page reclaim cannot get rid of them).
Aside from the actual bug, filemap_map_pmd() seems suboptimal at
present: comments below (plus one comment in do_anonymous_page()).
> diff --git a/mm/filemap.c b/mm/filemap.c
> index 0b2067b3c328..f8fdbe079375 100644
> --- a/mm/filemap.c
> +++ b/mm/filemap.c
> @@ -2831,10 +2832,74 @@ vm_fault_t filemap_fault(struct vm_fault *vmf)
> }
> EXPORT_SYMBOL(filemap_fault);
>
> +static bool filemap_map_pmd(struct vm_fault *vmf, struct page *page,
> + struct xa_state *xas)
> +{
> + struct vm_area_struct *vma = vmf->vma;
> + struct address_space *mapping = vma->vm_file->f_mapping;
> +
> + /* Huge page is mapped? No need to proceed. */
> + if (pmd_trans_huge(*vmf->pmd))
> + return true;
> +
> + if (xa_is_value(page))
> + goto nohuge;
I think it would be easier to follow if filemap_map_pages() never
passed this an xa_is_value(page): probably just skip them in its
initial xas_next_entry() loop.
> +
> + if (!pmd_none(*vmf->pmd))
> + goto nohuge;
Then at nohuge it unconditionally takes pmd_lock(), finds !pmd_none,
and unlocks again: unnecessary overhead I believe we did not have before.
> +
> + if (!PageTransHuge(page) || PageLocked(page))
> + goto nohuge;
So if PageTransHuge, but someone else temporarily holds PageLocked,
we insert a page table at nohuge, sadly preventing it from being
mapped here later by huge pmd.
> +
> + if (!page_cache_get_speculative(page))
> + goto nohuge;
> +
> + if (page != xas_reload(xas))
> + goto unref;
> +
> + if (!PageTransHuge(page))
> + goto unref;
> +
> + if (!PageUptodate(page) || PageReadahead(page) || PageHWPoison(page))
> + goto unref;
> +
> + if (!trylock_page(page))
> + goto unref;
> +
> + if (page->mapping != mapping || !PageUptodate(page))
> + goto unlock;
> +
> + if (xas->xa_index >= DIV_ROUND_UP(i_size_read(mapping->host),
> PAGE_SIZE))
> + goto unlock;
> +
> + do_set_pmd(vmf, page);
Here is the source of the huge page leak: do_set_pmd() can fail
(and we would do better to have skipped most of its failure cases long
before getting this far). It worked without leaking once I patched it:
- do_set_pmd(vmf, page);
- unlock_page(page);
- return true;
+ if (do_set_pmd(vmf, page) == 0) {
+ unlock_page(page);
+ return true;
+ }
> + unlock_page(page);
> + return true;
> +unlock:
> + unlock_page(page);
> +unref:
> + put_page(page);
> +nohuge:
> + vmf->ptl = pmd_lock(vma->vm_mm, vmf->pmd);
> + if (likely(pmd_none(*vmf->pmd))) {
> + mm_inc_nr_ptes(vma->vm_mm);
> + pmd_populate(vma->vm_mm, vmf->pmd, vmf->prealloc_pte);
> + vmf->prealloc_pte = NULL;
> + }
> + spin_unlock(vmf->ptl);
I think it's a bit weird to hide this page table insertion inside
filemap_map_pmd() (I guess you're thinking that this function deals
with pmd level, but I'd find it easier to have a filemap_map_huge()
dealing with the huge mapping). Better to do it on return into
filemap_map_pages(); maybe filemap_map_pmd() or filemap_map_huge()
would then need to return vm_fault_t rather than bool, I didn't try.
> +
> + /* See comment in handle_pte_fault() */
> + if (pmd_devmap_trans_unstable(vmf->pmd))
> + return true;
> +
> + return false;
> +}
...
> diff --git a/mm/memory.c b/mm/memory.c
> index c48f8df6e502..96d62774096a 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -3490,7 +3490,7 @@ static vm_fault_t do_anonymous_page(struct vm_fault
> *vmf)
> if (pte_alloc(vma->vm_mm, vmf->pmd))
> return VM_FAULT_OOM;
>
> - /* See the comment in pte_alloc_one_map() */
> +
Re: [PATCH] mm/userfaultfd: fix memory corruption due to writeprotect
> On Wed, Dec 23, 2020 at 07:09:10PM -0800, Nadav Amit wrote: > > I think there are other cases in which Andy’s concern is relevant > > (MADV_PAGEOUT). I didn't try to figure how it would help MADV_PAGEOUT. MADV_PAGEOUT sounds cool feature, but maybe it'd need a way to flush the invalidates out and a take a static key to enable the buildup of those ranges? I wouldn't like to slow down the fast paths even for MADV_PAGEOUT, and the same applies to uffd-wp and softdirty in fact. On Wed, Dec 23, 2020 at 08:34:00PM -0700, Yu Zhao wrote: > That patch only demonstrate a rough idea and I should have been > elaborate: if we ever decide to go that direction, we only need to > worry about "jumping through hoops", because the final patch (set) > I have in mind would not only have the build time optimization Andrea > suggested but also include runtime optimizations like skipping > do_swap_page() path and (!PageAnon() || page_mapcount > 1). Rest > assured, the performance impact on do_wp_page() from occasionally an > additional TLB flush on top of a page copy is negligible. Agreed, I just posted something in that direction. Feel free to refactor it, it's just a tentative implementation to show something that may deliver all the performance we need in all cases involved without slowing down the fast paths of non-uffd and non-softdirty (well 1 branch). > On Wed, Dec 23, 2020 at 07:09:10PM -0800, Nadav Amit wrote: > > Perhaps holding some small bitmap based on part of the deferred flushed > > pages (e.g., bits 12-17 of the address or some other kind of a single > > hash-function bloom-filter) would be more performant to avoid (most) The concern here aren't only the page faults having to run the bloom filter, but how to manage the RAM storage pointed by the bloomfilter or whatever index into the storage, which would slowdown mprotect. Granted that mprotect is slow to begin with, but the idea we can't make it any slower to make MADV_PAGEOUT or uffd-wp or clear_refs run faster since it's too important and too frequent in comparison. Just to restrict the potential false positive IPI caused by page_count inevitable inaccuracies to uffd-wp and softdirty runtimes, a simple check on vm_flags should be enough. Thanks, Andrea
[no subject]
Greetings, We are pleased to inform you that an amount of £500,000.00 (GBP) has been donated and given, gifted to you and your family by Steve & Lenka Thomson, who won the EuroMillions jackpot, lottery of £105,100,701.90 Euro Millions, part of this donation, it is for you and your family. This donation is to help fight against Corona Virus COVID -19 pandemic in the world, and help the poor people off the streets, also to contribute to poverty reduction, public donations, public charity, orphanages, less privileged and help poor individuals in your community please contact her to claim the money via email for more details: slenkathoms...@gmail.com Regards Steve Thomson
[PATCH] HID: google: Get HID report on probe to confirm tablet switch state
This forces reading the base folded status anytime the device is
probed.
Signed-off-by: Nicolas Boichat
---
Instead of all this manual parsing, it'd be easier to just call:
hid_hw_request(hdev, report, HID_REQ_GET_REPORT);
However, that fails silently as hdev->driver_input_lock is held
during probe (or even some callbacks like input_configured.
drivers/hid/hid-google-hammer.c | 85 +
1 file changed, 66 insertions(+), 19 deletions(-)
diff --git a/drivers/hid/hid-google-hammer.c b/drivers/hid/hid-google-hammer.c
index 85a054f1ce38..d9319622da44 100644
--- a/drivers/hid/hid-google-hammer.c
+++ b/drivers/hid/hid-google-hammer.c
@@ -392,30 +392,34 @@ static int hammer_input_mapping(struct hid_device *hdev,
struct hid_input *hi,
return 0;
}
-static int hammer_event(struct hid_device *hid, struct hid_field *field,
- struct hid_usage *usage, __s32 value)
+static void hammer_folded_event(struct hid_device *hdev, bool folded)
{
unsigned long flags;
- if (usage->hid == HID_USAGE_KBD_FOLDED) {
- spin_lock_irqsave(_ec_lock, flags);
+ spin_lock_irqsave(_ec_lock, flags);
- /*
-* If we are getting events from Whiskers that means that it
-* is attached to the lid.
-*/
- cbas_ec.base_present = true;
- cbas_ec.base_folded = value;
- hid_dbg(hid, "%s: base: %d, folded: %d\n", __func__,
- cbas_ec.base_present, cbas_ec.base_folded);
-
- if (cbas_ec.input) {
- input_report_switch(cbas_ec.input,
- SW_TABLET_MODE, value);
- input_sync(cbas_ec.input);
- }
+ /*
+* If we are getting events from Whiskers that means that it
+* is attached to the lid.
+*/
+ cbas_ec.base_present = true;
+ cbas_ec.base_folded = folded;
+ hid_dbg(hdev, "%s: base: %d, folded: %d\n", __func__,
+ cbas_ec.base_present, cbas_ec.base_folded);
- spin_unlock_irqrestore(_ec_lock, flags);
+ if (cbas_ec.input) {
+ input_report_switch(cbas_ec.input, SW_TABLET_MODE, folded);
+ input_sync(cbas_ec.input);
+ }
+
+ spin_unlock_irqrestore(_ec_lock, flags);
+}
+
+static int hammer_event(struct hid_device *hid, struct hid_field *field,
+ struct hid_usage *usage, __s32 value)
+{
+ if (usage->hid == HID_USAGE_KBD_FOLDED) {
+ hammer_folded_event(hid, value);
return 1; /* We handled this event */
}
@@ -457,6 +461,47 @@ static bool hammer_has_backlight_control(struct hid_device
*hdev)
HID_GD_KEYBOARD, HID_AD_BRIGHTNESS);
}
+static void hammer_get_folded_state(struct hid_device *hdev)
+{
+ struct hid_report *report;
+ char *buf;
+ int len, rlen;
+ int a;
+
+ report = hdev->report_enum[HID_INPUT_REPORT].report_id_hash[0x0];
+
+ if (!report || report->maxfield < 1)
+ return;
+
+ len = hid_report_len(report) + 1;
+
+ buf = kmalloc(len, GFP_KERNEL);
+ if (!buf)
+ return;
+
+ rlen = hid_hw_raw_request(hdev, report->id, buf, len, report->type,
HID_REQ_GET_REPORT);
+
+ if (rlen != len) {
+ hid_warn(hdev, "Unable to read base folded state: %d (expected
%d)\n", rlen, len);
+ goto out;
+ }
+
+ for (a = 0; a < report->maxfield; a++) {
+ struct hid_field *field = report->field[a];
+
+ if (field->usage->hid == HID_USAGE_KBD_FOLDED) {
+ u32 value = hid_field_extract(hdev, buf+1,
+ field->report_offset,
field->report_size);
+
+ hammer_folded_event(hdev, value);
+ break;
+ }
+ }
+
+out:
+ kfree(buf);
+}
+
static int hammer_probe(struct hid_device *hdev,
const struct hid_device_id *id)
{
@@ -481,6 +526,8 @@ static int hammer_probe(struct hid_device *hdev,
error = hid_hw_open(hdev);
if (error)
return error;
+
+ hammer_get_folded_state(hdev);
}
if (hammer_has_backlight_control(hdev)) {
--
2.29.2.729.g45daf8777d-goog
Re: [PATCH] mm/userfaultfd: fix memory corruption due to writeprotect
On Wed, Dec 23, 2020 at 07:09:10PM -0800, Nadav Amit wrote: > > On Dec 23, 2020, at 6:00 PM, Andrea Arcangeli wrote: > > > > On Wed, Dec 23, 2020 at 05:21:43PM -0800, Andy Lutomirski wrote: > >> I don’t love this as a long term fix. AFAICT we can have > >> mm_tlb_flush_pending set for quite a while — mprotect seems like it can > >> wait in IO while splitting a huge page, for example. That gives us a > >> window in which every write fault turns into a TLB flush. > > > > mprotect can't run concurrently with a page fault in the first place. > > > > One other near zero cost improvement easy to add if this would be "if > > (vma->vm_flags & (VM_SOFTDIRTY|VM_UFFD_WP))" and it could be made > > conditional to the two config options too. > > > > Still I don't mind doing it in some other way, uffd-wp has much easier > > time doing it in another way in fact. > > > > Whatever performs better is fine, but queuing up pending invalidate > > ranges don't look very attractive since it'd be a fixed cost that we'd > > always have to pay even when there's no fault (and there can't be any > > fault at least for mprotect). > > I think there are other cases in which Andy’s concern is relevant > (MADV_PAGEOUT). That patch only demonstrate a rough idea and I should have been elaborate: if we ever decide to go that direction, we only need to worry about "jumping through hoops", because the final patch (set) I have in mind would not only have the build time optimization Andrea suggested but also include runtime optimizations like skipping do_swap_page() path and (!PageAnon() || page_mapcount > 1). Rest assured, the performance impact on do_wp_page() from occasionally an additional TLB flush on top of a page copy is negligible. > Perhaps holding some small bitmap based on part of the deferred flushed > pages (e.g., bits 12-17 of the address or some other kind of a single > hash-function bloom-filter) would be more performant to avoid (most) > unnecessary TLB flushes. It will be cleared before a TLB flush and set while > holding the PTL. > > Checking if a flush is needed, under the PTL, would require a single memory > access (although potentially cache miss). It will however require one atomic > operation for each page-table whose PTEs’ flushes are deferred - in contrast > to the current scheme which requires two atomic operations for the *entire* > operation. >
Re: [PATCH] mm/userfaultfd: fix memory corruption due to writeprotect
On Wed, Dec 23, 2020 at 09:00:26PM -0500, Andrea Arcangeli wrote:
> One other near zero cost improvement easy to add if this would be "if
> (vma->vm_flags & (VM_SOFTDIRTY|VM_UFFD_WP))" and it could be made
The next worry then is if UFFDIO_WRITEPROTECT is very large then there
would be a flood of wrprotect faults, and they'd end up all issuing a
tlb flush during the UFFDIO_WRITEPROTECT itself which again is a
performance concern for certain uffd-wp use cases.
Those use cases would be for example redis and postcopy live
snapshotting, to use it for async snapshots, unprivileged too in the
case of redis if it temporarily uses bounce buffers for the syscall
I/O for the duration of the snapshot. hypervisors tuned profiles need
to manually lift the unprivileged_userfaultfd to 1 unless their jailer
leaves one capability in the snapshot thread.
Moving the check after userfaultfd_pte_wp would solve
userfaultfd_writeprotect(mode_wp=true), but that still wouldn't avoid
a flood of tlb flushes during userfaultfd_writeprotect(mode_wp=false)
because change_protection doesn't restore the pte_write:
} 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);
}
When the snapshot is complete userfaultfd_writeprotect(mode_wp=false)
would need to run again on the whole range which can be very big
again.
Orthogonally I think we should also look to restore the pte_write
above orthogonally in uffd-wp, so it'll get yet an extra boost if
compared to current redis snapshotting fork(), that cannot restore all
pte_write after the snapshot child quit and forces a flood of spurious
wrprotect faults (uffd-wp can solve that too).
However, even if uffd-wp restored the pte_write, things would remain
suboptimal for a terabyte process under clear_refs, since softdirty
wrprotect faults that start happening while softdirty is still running
on the mm, won't be caught in userfaultfd_pte_wp.
Something like below, if cleaned up, abstracted properly and
documented well in the two places involved, will have a better chance
to perform optimally for softdirty too.
And on a side note the CONFIG_MEM_SOFT_DIRTY compile time check is
compulsory because VM_SOFTDIRTY is defined to zero if softdirty is not
built in. (for VM_UFFD_WP the CONFIG_HAVE_ARCH_USERFAULTFD_WP can be
removed and it won't make any measurable difference even when
USERFAULTFD=n)
RFC untested below, it's supposed to fix the softdirty testcase too,
even without the incremental fix, since it already does tlb_gather_mmu
before walk_page_range and tlb_finish_mmu after it and that appears
enough to define the inc/dec_tlb_flush_pending.
diff --git a/mm/memory.c b/mm/memory.c
index 7d608765932b..66fd6d070c47 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -2844,11 +2844,26 @@ static vm_fault_t wp_page_copy(struct vm_fault *vmf)
if (!new_page)
goto oom;
} else {
+ bool in_uffd_wp, in_softdirty;
new_page = alloc_page_vma(GFP_HIGHUSER_MOVABLE, vma,
vmf->address);
if (!new_page)
goto oom;
+#ifdef CONFIG_HAVE_ARCH_USERFAULTFD_WP
+ in_uffd_wp = !!(vma->vm_flags & VM_UFFD_WP);
+#else
+ in_uffd_wp = false;
+#endif
+#ifdef CONFIG_MEM_SOFT_DIRTY
+ in_softdirty = !(vma->vm_flags & VM_SOFTDIRTY);
+#else
+ in_softdirty = false;
+#endif
+ if ((in_uffd_wp || in_softdirty) &&
+ mm_tlb_flush_pending(mm))
+ flush_tlb_page(vma, vmf->address);
+
if (!cow_user_page(new_page, old_page, vmf)) {
/*
* COW failed, if the fault was solved by other,
Re: [PATCH] mm/userfaultfd: fix memory corruption due to writeprotect
> On Dec 23, 2020, at 7:09 PM, Nadav Amit wrote: > >> On Dec 23, 2020, at 6:00 PM, Andrea Arcangeli wrote: >> >> On Wed, Dec 23, 2020 at 05:21:43PM -0800, Andy Lutomirski wrote: >>> I don’t love this as a long term fix. AFAICT we can have >>> mm_tlb_flush_pending set for quite a while — mprotect seems like it can >>> wait in IO while splitting a huge page, for example. That gives us a window >>> in which every write fault turns into a TLB flush. >> >> mprotect can't run concurrently with a page fault in the first place. >> >> One other near zero cost improvement easy to add if this would be "if >> (vma->vm_flags & (VM_SOFTDIRTY|VM_UFFD_WP))" and it could be made >> conditional to the two config options too. >> >> Still I don't mind doing it in some other way, uffd-wp has much easier >> time doing it in another way in fact. >> >> Whatever performs better is fine, but queuing up pending invalidate >> ranges don't look very attractive since it'd be a fixed cost that we'd >> always have to pay even when there's no fault (and there can't be any >> fault at least for mprotect). > > I think there are other cases in which Andy’s concern is relevant > (MADV_PAGEOUT). > > Perhaps holding some small bitmap based on part of the deferred flushed > pages (e.g., bits 12-17 of the address or some other kind of a single > hash-function bloom-filter) would be more performant to avoid (most) > unnecessary TLB flushes. It will be cleared before a TLB flush and set while > holding the PTL. > > Checking if a flush is needed, under the PTL, would require a single memory > access (although potentially cache miss). It will however require one atomic > operation for each page-table whose PTEs’ flushes are deferred - in contrast > to the current scheme which requires two atomic operations for the *entire* > operation. Just to finish my thought - clearing the bitmap is the tricky part, which I still did not figure out.
[PATCH resend] dt-bindings: mfd: mediatek: Add bindings for MT6360 PMIC
From: Gene Chen
Add bindings for MT6360 PMIC
Signed-off-by: Gene Chen
---
Documentation/devicetree/bindings/mfd/mt6360.yaml | 69 +++
1 file changed, 69 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/mt6360.yaml
diff --git a/Documentation/devicetree/bindings/mfd/mt6360.yaml
b/Documentation/devicetree/bindings/mfd/mt6360.yaml
new file mode 100644
index 000..2781c31
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/mt6360.yaml
@@ -0,0 +1,69 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/mt6360.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MT6360 PMIC from MediaTek Integrated
+
+maintainers:
+ - Gene Chen
+
+description: |
+ MT6360 is a PMIC device with the following sub modules.
+ It is interfaced to host controller using I2C interface.
+
+ This document describes the binding for PMIC device and its sub module.
+
+properties:
+ compatible:
+const: mediatek,mt6360
+
+ reg:
+description:
+ I2C device address.
+maxItems: 1
+
+ wakeup-source: true
+
+ interrupts:
+maxItems: 1
+
+ interrupt-names:
+ enum:
+- IRQB
+
+ interrupt-controller: true
+
+ "#interrupt-cells":
+const: 1
+description:
+ The first cell is the IRQ number.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-controller
+ - "#interrupt-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+i2c {
+#address-cells = <1>;
+#size-cells = <0>;
+
+mt6360@34 {
+compatible = "mediatek,mt6360";
+reg = <0x34>;
+wakeup-source;
+interrupts-extended = < 0 IRQ_TYPE_LEVEL_LOW>;
+interrupt-names = "IRQB";
+interrupt-controller;
+#interrupt-cells = <1>;
+};
+};
--
2.7.4
[RFC PATCH v2 1/1] iio/scmi: Adding support for IIO SCMI Based Sensors
This change provides ARM SCMI Protocol based IIO device.
This driver provides support for Accelerometer and Gyroscope using
new SCMI Sensor Protocol defined by the upcoming SCMIv3.0
ARM specification
Signed-off-by: Jyoti Bhayana
---
MAINTAINERS| 6 +
drivers/iio/common/Kconfig | 1 +
drivers/iio/common/Makefile| 1 +
drivers/iio/common/scmi_sensors/Kconfig| 18 +
drivers/iio/common/scmi_sensors/Makefile | 5 +
drivers/iio/common/scmi_sensors/scmi_iio.c | 696 +
6 files changed, 727 insertions(+)
create mode 100644 drivers/iio/common/scmi_sensors/Kconfig
create mode 100644 drivers/iio/common/scmi_sensors/Makefile
create mode 100644 drivers/iio/common/scmi_sensors/scmi_iio.c
diff --git a/MAINTAINERS b/MAINTAINERS
index b516bb34a8d5..ccf37d43ab41 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8567,6 +8567,12 @@ S: Maintained
F: Documentation/devicetree/bindings/iio/multiplexer/io-channel-mux.txt
F: drivers/iio/multiplexer/iio-mux.c
+IIO SCMI BASED DRIVER
+M: Jyoti Bhayana
+L: linux-...@vger.kernel.org
+S: Maintained
+F: drivers/iio/common/scmi_sensors/scmi_iio.c
+
IIO SUBSYSTEM AND DRIVERS
M: Jonathan Cameron
R: Lars-Peter Clausen
diff --git a/drivers/iio/common/Kconfig b/drivers/iio/common/Kconfig
index 2b9ee9161abd..0334b4954773 100644
--- a/drivers/iio/common/Kconfig
+++ b/drivers/iio/common/Kconfig
@@ -6,5 +6,6 @@
source "drivers/iio/common/cros_ec_sensors/Kconfig"
source "drivers/iio/common/hid-sensors/Kconfig"
source "drivers/iio/common/ms_sensors/Kconfig"
+source "drivers/iio/common/scmi_sensors/Kconfig"
source "drivers/iio/common/ssp_sensors/Kconfig"
source "drivers/iio/common/st_sensors/Kconfig"
diff --git a/drivers/iio/common/Makefile b/drivers/iio/common/Makefile
index 4bc30bb548e2..fad40e1e1718 100644
--- a/drivers/iio/common/Makefile
+++ b/drivers/iio/common/Makefile
@@ -11,5 +11,6 @@
obj-y += cros_ec_sensors/
obj-y += hid-sensors/
obj-y += ms_sensors/
+obj-y += scmi_sensors/
obj-y += ssp_sensors/
obj-y += st_sensors/
diff --git a/drivers/iio/common/scmi_sensors/Kconfig
b/drivers/iio/common/scmi_sensors/Kconfig
new file mode 100644
index ..67e084cbb1ab
--- /dev/null
+++ b/drivers/iio/common/scmi_sensors/Kconfig
@@ -0,0 +1,18 @@
+#
+# IIO over SCMI
+#
+# When adding new entries keep the list in alphabetical order
+
+menu "IIO SCMI Sensors"
+
+config IIO_SCMI
+ tristate "IIO SCMI"
+depends on ARM_SCMI_PROTOCOL
+select IIO_BUFFER
+select IIO_KFIFO_BUF
+ help
+ Say yes here to build support for IIO SCMI Driver.
+ This provides ARM SCMI Protocol based IIO device.
+ This driver provides support for accelerometer and gyroscope
+ sensors available on SCMI based platforms.
+endmenu
diff --git a/drivers/iio/common/scmi_sensors/Makefile
b/drivers/iio/common/scmi_sensors/Makefile
new file mode 100644
index ..f13140a2575a
--- /dev/null
+++ b/drivers/iio/common/scmi_sensors/Makefile
@@ -0,0 +1,5 @@
+# SPDX - License - Identifier : GPL - 2.0 - only
+#
+# Makefile for the IIO over SCMI
+#
+obj-$(CONFIG_IIO_SCMI) += scmi_iio.o
diff --git a/drivers/iio/common/scmi_sensors/scmi_iio.c
b/drivers/iio/common/scmi_sensors/scmi_iio.c
new file mode 100644
index ..2f5c884e22ab
--- /dev/null
+++ b/drivers/iio/common/scmi_sensors/scmi_iio.c
@@ -0,0 +1,696 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/*
+ * System Control and Management Interface(SCMI) based IIO sensor driver
+ *
+ * Copyright (C) 2020 Google LLC
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define NSEC_MULT_POW_10 (const_ilog2(NSEC_PER_SEC) / const_ilog2(10))
+#define UHZ_PER_HZ 100UL
+#define ODR_EXPAND(odr, uodr) (((odr)*100ULL) + (uodr))
+#define MAX_NUM_OF_CHANNELS 4
+
+struct scmi_iio_priv {
+ struct scmi_handle *handle;
+ const struct scmi_sensor_info *sensor_info;
+ struct iio_dev *indio_dev;
+ long long iio_buf[MAX_NUM_OF_CHANNELS];
+ struct notifier_block sensor_update_nb;
+ u32 *freq_avail;
+};
+
+struct sensor_freq {
+ u64 hz;
+ u64 uhz;
+};
+
+static int sensor_update_cb(struct notifier_block *nb, unsigned long event,
+ void *data)
+{
+ struct scmi_sensor_update_report *sensor_update = data;
+ u64 time, time_ns;
+ s64 sensor_value;
+ struct iio_dev *scmi_iio_dev;
+ s8 tstamp_scale_ns;
+ int i;
+ struct scmi_iio_priv *sensor =
+ container_of(nb, struct scmi_iio_priv, sensor_update_nb);
+
+ scmi_iio_dev = sensor->indio_dev;
+
+ for (i = 0; i < sensor_update->readings_count; i++) {
+ sensor_value = sensor_update->readings[i].value;
+ time = sensor_update->readings[i].timestamp;
+
[RFC PATCH v2 0/1] Adding support for IIO SCMI based sensors
Hi,
This series adds support for ARM SCMI Protocol based IIO Device.
This driver provides support for Accelerometer and Gyroscope sensor
using new SCMI Sensor Protocol defined by the upcoming SCMIv3.0 ARM
specification, which is available at
https://developer.arm.com/documentation/den0056/c/
The series is currently based on top of:
commit f83eb664cdb4 ("Merge tag 'scmi-voltage-5.11' of
git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into
for-next/scmi")
in Sudeep for-next/scmi branch:
https://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/\
linux.git/log/?h=for-next/scmi
This version of the patch series has been tested using
version 5.4.21 branch of Android common kernel.
Any feedback welcome,
Thanks,
Jyoti Bhayana
v1 --> v2
- Incorporated the feedback comments from v1 review of the patch
- Regarding the new ABI for sensor_power,sensor_max_range,
and sensor_resolution, these are some of the sensor attributes
which Android passes to the apps. If there is any other way of getting
those values, please let us know
Jyoti Bhayana (1):
iio/scmi: Adding support for IIO SCMI Based Sensors
MAINTAINERS| 6 +
drivers/iio/common/Kconfig | 1 +
drivers/iio/common/Makefile| 1 +
drivers/iio/common/scmi_sensors/Kconfig| 18 +
drivers/iio/common/scmi_sensors/Makefile | 5 +
drivers/iio/common/scmi_sensors/scmi_iio.c | 693 +
6 files changed, 724 insertions(+)
create mode 100644 drivers/iio/common/scmi_sensors/Kconfig
create mode 100644 drivers/iio/common/scmi_sensors/Makefile
create mode 100644 drivers/iio/common/scmi_sensors/scmi_iio.c
--
2.29.2.729.g45daf8777d-goog
Re: [PATCH] powerpc/mm: Limit allocation of SWIOTLB on server machines
On Wed, Dec 23, 2020 at 09:06:01PM -0300, Thiago Jung Bauermann wrote: > > Hi Ram, > > Thanks for reviewing this patch. > > Ram Pai writes: > > > On Fri, Dec 18, 2020 at 03:21:03AM -0300, Thiago Jung Bauermann wrote: > >> On server-class POWER machines, we don't need the SWIOTLB unless we're a > >> secure VM. Nevertheless, if CONFIG_SWIOTLB is enabled we unconditionally > >> allocate it. > >> > >> In most cases this is harmless, but on a few machine configurations (e.g., > >> POWER9 powernv systems with 4 GB area reserved for crashdump kernel) it can > >> happen that memblock can't find a 64 MB chunk of memory for the SWIOTLB and > >> fails with a scary-looking WARN_ONCE: > >> > >> [ cut here ] > >> memblock: bottom-up allocation failed, memory hotremove may be affected > >> WARNING: CPU: 0 PID: 0 at mm/memblock.c:332 > >> memblock_find_in_range_node+0x328/0x340 > >> Modules linked in: > >> CPU: 0 PID: 0 Comm: swapper Not tainted 5.10.0-rc2-orig+ #6 > >> NIP: c0442f38 LR: c0442f34 CTR: c01e0080 > >> REGS: c1def900 TRAP: 0700 Not tainted (5.10.0-rc2-orig+) > >> MSR: 92021033 CR: 2802 XER: > >> 2004 > >> CFAR: c014b7b4 IRQMASK: 1 > >> GPR00: c0442f34 c1defba0 c1deff00 0047 > >> GPR04: 7fff c1def828 c1def820 > >> GPR08: 001ffc3e c1b75478 c1b75478 0001 > >> GPR12: 2000 c203 > >> GPR16: 0203 > >> GPR20: 0001 0001 c1defc10 > >> GPR24: c1defc08 c1c91868 c1defc18 c1c91890 > >> GPR28: 0400 > >> NIP [c0442f38] memblock_find_in_range_node+0x328/0x340 > >> LR [c0442f34] memblock_find_in_range_node+0x324/0x340 > >> Call Trace: > >> [c1defba0] [c0442f34] > >> memblock_find_in_range_node+0x324/0x340 (unreliable) > >> [c1defc90] [c15ac088] memblock_alloc_range_nid+0xec/0x1b0 > >> [c1defd40] [c15ac1f8] memblock_alloc_internal+0xac/0x110 > >> [c1defda0] [c15ac4d0] memblock_alloc_try_nid+0x94/0xcc > >> [c1defe30] [c159c3c8] swiotlb_init+0x78/0x104 > >> [c1defea0] [c158378c] mem_init+0x4c/0x98 > >> [c1defec0] [c157457c] start_kernel+0x714/0xac8 > >> [c1deff90] [c000d244] start_here_common+0x1c/0x58 > >> Instruction dump: > >> 2c23 4182ffd4 ea610088 ea810090 4bfffe84 3921 3d42fff4 3c62ff60 > >> 3863c560 992a8bfc 4bd0881d 6000 <0fe0> ea610088 4bfffd94 6000 > >> random: get_random_bytes called from __warn+0x128/0x184 with crng_init=0 > >> ---[ end trace ]--- > >> software IO TLB: Cannot allocate buffer > >> > >> Unless this is a secure VM the message can actually be ignored, because the > >> SWIOTLB isn't needed. Therefore, let's avoid the SWIOTLB in those cases. > > > > The above warn_on is conveying a genuine warning. Should it be silenced? > > Not sure I understand your point. This patch doesn't silence the > warning, it avoids the problem it is warning about. Sorry, I should have explained it better. My point is... If CONFIG_SWIOTLB is enabled, it means that the kernel is promising the bounce buffering capability. I know, currently we do not have any kernel subsystems that use bounce buffers on non-secure-pseries-kernel or powernv-kernel. But that does not mean, there wont be any. In case there is such a third-party module needing bounce buffering, it wont be able to operate, because of the proposed change in your patch. Is that a good thing or a bad thing, I do not know. I will let the experts opine. RP
Re: [External] Re: mmotm 2020-12-23-16-15 uploaded (mm/vmstat.c)
On Thu, Dec 24, 2020 at 10:57 AM Randy Dunlap wrote:
>
> On 12/23/20 4:16 PM, a...@linux-foundation.org wrote:
> > The mm-of-the-moment snapshot 2020-12-23-16-15 has been uploaded to
> >
> >https://www.ozlabs.org/~akpm/mmotm/
> >
> > mmotm-readme.txt says
> >
> > README for mm-of-the-moment:
> >
> > https://www.ozlabs.org/~akpm/mmotm/
> >
> > This is a snapshot of my -mm patch queue. Uploaded at random hopefully
> > more than once a week.
> >
> > You will need quilt to apply these patches to the latest Linus release (5.x
> > or 5.x-rcY). The series file is in broken-out.tar.gz and is duplicated in
> > https://ozlabs.org/~akpm/mmotm/series
> >
> > The file broken-out.tar.gz contains two datestamp files: .DATE and
> > .DATE--mm-dd-hh-mm-ss. Both contain the string -mm-dd-hh-mm-ss,
> > followed by the base kernel version against which this patch series is to
> > be applied.
>
> on i386 or UML on i386 or x86_64:
> (and probably on x86_64, but my builds haven't got there yet)
>
> when CONFIG_TRANSPARENT_HUGEPAGE is not set/enabled:
Very thanks for your information. I will fix this in the next version. Thanks.
>
> ../mm/vmstat.c: In function ‘zoneinfo_show_print’:
> ./../include/linux/compiler_types.h:320:38: error: call to
> ‘__compiletime_assert_269’ declared with attribute error: BUILD_BUG failed
> _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
> ^
> ./../include/linux/compiler_types.h:301:4: note: in definition of macro
> ‘__compiletime_assert’
> prefix ## suffix();\
> ^~
> ./../include/linux/compiler_types.h:320:2: note: in expansion of macro
> ‘_compiletime_assert’
> _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
> ^~~
> ../include/linux/build_bug.h:39:37: note: in expansion of macro
> ‘compiletime_assert’
> #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
> ^~
> ../include/linux/build_bug.h:59:21: note: in expansion of macro
> ‘BUILD_BUG_ON_MSG’
> #define BUILD_BUG() BUILD_BUG_ON_MSG(1, "BUILD_BUG failed")
> ^~~~
> ../include/linux/huge_mm.h:325:28: note: in expansion of macro ‘BUILD_BUG’
> #define HPAGE_PMD_SHIFT ({ BUILD_BUG(); 0; })
> ^
> ../include/linux/huge_mm.h:106:26: note: in expansion of macro
> ‘HPAGE_PMD_SHIFT’
> #define HPAGE_PMD_ORDER (HPAGE_PMD_SHIFT-PAGE_SHIFT)
> ^~~
> ../include/linux/huge_mm.h:107:26: note: in expansion of macro
> ‘HPAGE_PMD_ORDER’
> #define HPAGE_PMD_NR (1< ^~~
> ../mm/vmstat.c:1630:14: note: in expansion of macro ‘HPAGE_PMD_NR’
> pages /= HPAGE_PMD_NR;
> ^~~~
> ../mm/vmstat.c: In function ‘vmstat_start’:
> ./../include/linux/compiler_types.h:320:38: error: call to
> ‘__compiletime_assert_271’ declared with attribute error: BUILD_BUG failed
> _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
> ^
> ./../include/linux/compiler_types.h:301:4: note: in definition of macro
> ‘__compiletime_assert’
> prefix ## suffix();\
> ^~
> ./../include/linux/compiler_types.h:320:2: note: in expansion of macro
> ‘_compiletime_assert’
> _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
> ^~~
> ../include/linux/build_bug.h:39:37: note: in expansion of macro
> ‘compiletime_assert’
> #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
> ^~
> ../include/linux/build_bug.h:59:21: note: in expansion of macro
> ‘BUILD_BUG_ON_MSG’
> #define BUILD_BUG() BUILD_BUG_ON_MSG(1, "BUILD_BUG failed")
> ^~~~
> ../include/linux/huge_mm.h:325:28: note: in expansion of macro ‘BUILD_BUG’
> #define HPAGE_PMD_SHIFT ({ BUILD_BUG(); 0; })
> ^
> ../include/linux/huge_mm.h:106:26: note: in expansion of macro
> ‘HPAGE_PMD_SHIFT’
> #define HPAGE_PMD_ORDER (HPAGE_PMD_SHIFT-PAGE_SHIFT)
> ^~~
> ../include/linux/huge_mm.h:107:26: note: in expansion of macro
> ‘HPAGE_PMD_ORDER’
> #define HPAGE_PMD_NR (1< ^~~
> ../mm/vmstat.c:1755:12: note: in expansion of macro ‘HPAGE_PMD_NR’
> v[i] /= HPAGE_PMD_NR;
> ^~~~
>
> due to :
>
> #else /* CONFIG_TRANSPARENT_HUGEPAGE */
> #define HPAGE_PMD_SHIFT ({ BUILD_BUG(); 0; })
> #define HPAGE_PMD_MASK ({ BUILD_BUG(); 0; })
> #define HPAGE_PMD_SIZE ({ BUILD_BUG(); 0; })
>
> #define HPAGE_PUD_SHIFT ({ BUILD_BUG(); 0; })
> #define HPAGE_PUD_MASK ({ BUILD_BUG(); 0; })
> #define HPAGE_PUD_SIZE ({ BUILD_BUG(); 0; })
>
>
>
> >> mm-memcontrol-convert-nr_anon_thps-account-to-pages.patch
>
> --
> ~Randy
>
--
Yours,
Muchun
Re: [PATCH] mm/userfaultfd: fix memory corruption due to writeprotect
> On Dec 23, 2020, at 6:00 PM, Andrea Arcangeli wrote: > > On Wed, Dec 23, 2020 at 05:21:43PM -0800, Andy Lutomirski wrote: >> I don’t love this as a long term fix. AFAICT we can have >> mm_tlb_flush_pending set for quite a while — mprotect seems like it can wait >> in IO while splitting a huge page, for example. That gives us a window in >> which every write fault turns into a TLB flush. > > mprotect can't run concurrently with a page fault in the first place. > > One other near zero cost improvement easy to add if this would be "if > (vma->vm_flags & (VM_SOFTDIRTY|VM_UFFD_WP))" and it could be made > conditional to the two config options too. > > Still I don't mind doing it in some other way, uffd-wp has much easier > time doing it in another way in fact. > > Whatever performs better is fine, but queuing up pending invalidate > ranges don't look very attractive since it'd be a fixed cost that we'd > always have to pay even when there's no fault (and there can't be any > fault at least for mprotect). I think there are other cases in which Andy’s concern is relevant (MADV_PAGEOUT). Perhaps holding some small bitmap based on part of the deferred flushed pages (e.g., bits 12-17 of the address or some other kind of a single hash-function bloom-filter) would be more performant to avoid (most) unnecessary TLB flushes. It will be cleared before a TLB flush and set while holding the PTL. Checking if a flush is needed, under the PTL, would require a single memory access (although potentially cache miss). It will however require one atomic operation for each page-table whose PTEs’ flushes are deferred - in contrast to the current scheme which requires two atomic operations for the *entire* operation.
Re: [PATCH v2] docs/zh_CN: Improve Cinese transolation quality.
在 2020/12/21 下午8:34, Ran Wang 写道: > Hi Alex, > > > On Monday, December 21, 2020 3:52 PM, Alex Shi wrote: > >> 在 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. > > Sorry, I didn't mean to offend. You are right. That's all right. I guess, few my translation is easy to be misunderstood, and I own some explantion: like 2 places: 1, 'There are a great many "reasons" why kernel code should be merged into the ...' Here if 'reasons' translated as 'benefits/advantage', that would fits better in Chinese converstion custom. (I don't strong oppose this). but usually we keep 'reasons' original meaning. 2, 'managing patches with git and reviewing patches "posted" by others.' Here the 'posted', I did think a lot on '发布' or '提交', It costed me sometime, But finally I used '发布' not ‘提交’， since the latter is easy to be confused with git 'commit' in Chinese, while patches we hold here were posted by email, not 'git'. > >> 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.> > The word 'polishing' is the perfect word to describe this, thank you. We are not professional translators or interpreters (although my wife is one). :) But there is a standards of the Chinese translation, fidelity, fluency, elegence, let's hang on fidelity, and try best on fluency or elegence. :) Thanks Alex
[PATCH] io_uring: simplify io_remove_personalities()
The function io_remove_personalities() is very similar to
io_unregister_personality(),so implement io_remove_personalities()
calling io_unregister_personality().
Signed-off-by: Yejune Deng
---
fs/io_uring.c | 28 +++-
1 file changed, 11 insertions(+), 17 deletions(-)
diff --git a/fs/io_uring.c b/fs/io_uring.c
index b749578..dc913fa 100644
--- a/fs/io_uring.c
+++ b/fs/io_uring.c
@@ -8608,9 +8608,8 @@ static int io_uring_fasync(int fd, struct file *file, int
on)
return fasync_helper(fd, file, on, >cq_fasync);
}
-static int io_remove_personalities(int id, void *p, void *data)
+static int io_unregister_personality(struct io_ring_ctx *ctx, unsigned id)
{
- struct io_ring_ctx *ctx = data;
struct io_identity *iod;
iod = idr_remove(>personality_idr, id);
@@ -8618,7 +8617,17 @@ static int io_remove_personalities(int id, void *p, void
*data)
put_cred(iod->creds);
if (refcount_dec_and_test(>count))
kfree(iod);
+ return 0;
}
+
+ return -EINVAL;
+}
+
+static int io_remove_personalities(int id, void *p, void *data)
+{
+ struct io_ring_ctx *ctx = data;
+
+ io_unregister_personality(ctx, id);
return 0;
}
@@ -9679,21 +9688,6 @@ static int io_register_personality(struct io_ring_ctx
*ctx)
return ret;
}
-static int io_unregister_personality(struct io_ring_ctx *ctx, unsigned id)
-{
- struct io_identity *iod;
-
- iod = idr_remove(>personality_idr, id);
- if (iod) {
- put_cred(iod->creds);
- if (refcount_dec_and_test(>count))
- kfree(iod);
- return 0;
- }
-
- return -EINVAL;
-}
-
static int io_register_restrictions(struct io_ring_ctx *ctx, void __user *arg,
unsigned int nr_args)
{
--
1.9.1
Re: [PATCH] clocksource: clint: Avoid remove __iomem in get_cycles_hi()
On Wed, 23 Dec 2020 00:23:30 PST (-0800), Christoph Hellwig wrote: On Mon, Dec 21, 2020 at 09:32:30PM -0800, Palmer Dabbelt wrote: From: Palmer Dabbelt This cast loses the __iomem qualifier from clint_timer_val, which triggers an sparse warning. I'm not a native speaker, but the subject line sounds strange to me. Shouldn't this be: "don't cast away the __iommu annotation" or something similar? The title is also nonsense, I was probably trying to do two things at once when I wrote this. I'll send another one. Also this adds an overly long line. Otherwise it looks fine. Aren't we OK with lines longer than 80 characters now? Or was that some other project? checkpatch doesn't complain, which I guess is why I didn't notice, so hopefully that means I'm not crazy (though I guess the commit message and title don't provide the best argument there... ;)).
Re: mmotm 2020-12-23-16-15 uploaded (mm/vmstat.c)
On 12/23/20 4:16 PM, a...@linux-foundation.org wrote:
> The mm-of-the-moment snapshot 2020-12-23-16-15 has been uploaded to
>
>https://www.ozlabs.org/~akpm/mmotm/
>
> mmotm-readme.txt says
>
> README for mm-of-the-moment:
>
> https://www.ozlabs.org/~akpm/mmotm/
>
> This is a snapshot of my -mm patch queue. Uploaded at random hopefully
> more than once a week.
>
> You will need quilt to apply these patches to the latest Linus release (5.x
> or 5.x-rcY). The series file is in broken-out.tar.gz and is duplicated in
> https://ozlabs.org/~akpm/mmotm/series
>
> The file broken-out.tar.gz contains two datestamp files: .DATE and
> .DATE--mm-dd-hh-mm-ss. Both contain the string -mm-dd-hh-mm-ss,
> followed by the base kernel version against which this patch series is to
> be applied.
on i386 or UML on i386 or x86_64:
(and probably on x86_64, but my builds haven't got there yet)
when CONFIG_TRANSPARENT_HUGEPAGE is not set/enabled:
../mm/vmstat.c: In function ‘zoneinfo_show_print’:
./../include/linux/compiler_types.h:320:38: error: call to
‘__compiletime_assert_269’ declared with attribute error: BUILD_BUG failed
_compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
^
./../include/linux/compiler_types.h:301:4: note: in definition of macro
‘__compiletime_assert’
prefix ## suffix();\
^~
./../include/linux/compiler_types.h:320:2: note: in expansion of macro
‘_compiletime_assert’
_compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
^~~
../include/linux/build_bug.h:39:37: note: in expansion of macro
‘compiletime_assert’
#define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
^~
../include/linux/build_bug.h:59:21: note: in expansion of macro
‘BUILD_BUG_ON_MSG’
#define BUILD_BUG() BUILD_BUG_ON_MSG(1, "BUILD_BUG failed")
^~~~
../include/linux/huge_mm.h:325:28: note: in expansion of macro ‘BUILD_BUG’
#define HPAGE_PMD_SHIFT ({ BUILD_BUG(); 0; })
^
../include/linux/huge_mm.h:106:26: note: in expansion of macro ‘HPAGE_PMD_SHIFT’
#define HPAGE_PMD_ORDER (HPAGE_PMD_SHIFT-PAGE_SHIFT)
^~~
../include/linux/huge_mm.h:107:26: note: in expansion of macro ‘HPAGE_PMD_ORDER’
#define HPAGE_PMD_NR (1<:
#else /* CONFIG_TRANSPARENT_HUGEPAGE */
#define HPAGE_PMD_SHIFT ({ BUILD_BUG(); 0; })
#define HPAGE_PMD_MASK ({ BUILD_BUG(); 0; })
#define HPAGE_PMD_SIZE ({ BUILD_BUG(); 0; })
#define HPAGE_PUD_SHIFT ({ BUILD_BUG(); 0; })
#define HPAGE_PUD_MASK ({ BUILD_BUG(); 0; })
#define HPAGE_PUD_SIZE ({ BUILD_BUG(); 0; })
>> mm-memcontrol-convert-nr_anon_thps-account-to-pages.patch
--
~Randy
Re: [PATCH] riscv: return -ENOSYS for syscall -1
On Wed, 23 Dec 2020 00:24:04 PST (-0800), Christoph Hellwig wrote:
On Tue, Dec 22, 2020 at 09:22:19AM -0700, Tycho Andersen wrote:
On Mon, Dec 21, 2020 at 11:52:00PM +0100, Andreas Schwab wrote:
> Properly return -ENOSYS for syscall -1 instead of leaving the return value
> uninitialized. This fixes the strace teststuite.
>
> Fixes: 5340627e3fe0 ("riscv: add support for SECCOMP and SECCOMP_FILTER")
> Signed-off-by: Andreas Schwab
> ---
> arch/riscv/kernel/entry.S | 9 +
> 1 file changed, 1 insertion(+), 8 deletions(-)
>
> diff --git a/arch/riscv/kernel/entry.S b/arch/riscv/kernel/entry.S
> index 524d918f3601..d07763001eb0 100644
> --- a/arch/riscv/kernel/entry.S
> +++ b/arch/riscv/kernel/entry.S
> @@ -186,14 +186,7 @@ check_syscall_nr:
> * Syscall number held in a7.
> * If syscall number is above allowed value, redirect to ni_syscall.
> */
> - bge a7, t0, 1f
> - /*
> - * Check if syscall is rejected by tracer, i.e., a7 == -1.
> - * If yes, we pretend it was executed.
> - */
> - li t1, -1
> - beq a7, t1, ret_from_syscall_rejected
> - blt a7, t1, 1f
> + bgeu a7, t0, 1f
IIUC, this is all dead code anyway for the path where seccomp actually
rejects the syscall, since it should do the rejection directly in
handle_syscall_trace_enter(), which is called above this hunk. So it
seems good to me.
That change really needs to be documented in the commit log, or even
better split into a separate patch (still documented of course!).
Unless I'm missing something, this is already how it works already?
handle_syscall_trace_enter is checking the result of do_syscall_trace_enter(),
which checks secure_computing(). When secure_computing() rejects the syscall
we already ended up rejecting the syscall, so this code wasn't doing anything
for the case it was supposed to handle.
It was, however, intercepting syscall number -1 when we weren't rejecting the
syscall and directly exiting rather than calling sys_ni_syscall. That would,
at a bare minimum, result in an uninitialized return value. It also breaks the
pairing of trace_sys_enter() and trace_sys_exit(), which doesn't smell like a
good idea.
Re: [f2fs-dev] [PATCH] f2fs: handle unallocated section and zone on pinned/atgc
On 2020/12/24 4:02, Jaegeuk Kim wrote: If we have large section/zone, unallocated segment makes them corrupted. E.g., - Pinned file: -1 119304647 119304647 - ATGC data: -1 119304647 119304647 Signed-off-by: Jaegeuk Kim Reviewed-by: Chao Yu Thanks,
Re: [f2fs-dev] [PATCH -next] f2fs: Replace expression with offsetof()
On 2020/12/22 21:34, Zheng Yongjun wrote: Use the existing offsetof() macro instead of duplicating code. Signed-off-by: Zheng Yongjun Reviewed-by: Chao Yu Thanks,
Re: [External] Re: [PATCH v5 2/7] mm: memcontrol: convert NR_ANON_THPS account to pages
On Thu, Dec 24, 2020 at 6:08 AM Shakeel Butt wrote:
>
> On Wed, Dec 16, 2020 at 7:45 PM Muchun Song wrote:
> >
> > Currently we use struct per_cpu_nodestat to cache the vmstat
> > counters, which leads to inaccurate statistics expecially THP
>
> *especially
Thanks.
>
> > vmstat counters. In the systems with hundreads of processors
>
> *hundreds
Thanks.
>
> > it can be GBs of memory. For example, for a 96 CPUs system,
> > the threshold is the maximum number of 125. And the per cpu
> > counters can cache 23.4375 GB in total.
> >
> > The THP page is already a form of batched addition (it will
> > add 512 worth of memory in one go) so skipping the batching
> > seems like sensible. Although every THP stats update overflows
> > the per-cpu counter, resorting to atomic global updates. But
> > it can make the statistics more accuracy for the THP vmstat
> > counters.
> >
> > So we convert the NR_ANON_THPS account to pages. This patch
> > is consistent with 8f182270dfec ("mm/swap.c: flush lru pvecs
> > on compound page arrival"). Doing this also can make the unit
> > of vmstat counters more unified. Finally, the unit of the vmstat
> > counters are pages, kB and bytes. The B/KB suffix can tell us
> > that the unit is bytes or kB. The rest which is without suffix
> > are pages.
> >
> > Signed-off-by: Muchun Song
>
> I agree with the motivation behind this patch but I would like to see
> some performance numbers in the commit message. We might agree to pay
> the price but at least we will know what exactly that cost is.
Do you have any recommendations about benchmarks?
I can do a test. Thanks very much.
--
Yours,
Muchun
[PATCH v2 3/3] dt-bindings: arm: sunxi: document orig PineTab DT as sample
As the original PineTab DT (which uses sun50i-a64-pinetab name) is only
for development samples, document this.
Signed-off-by: Icenowy Zheng
---
Documentation/devicetree/bindings/arm/sunxi.yaml | 2 +-
arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml
b/Documentation/devicetree/bindings/arm/sunxi.yaml
index 8c62a1e2a498..7eec85be7ab9 100644
--- a/Documentation/devicetree/bindings/arm/sunxi.yaml
+++ b/Documentation/devicetree/bindings/arm/sunxi.yaml
@@ -695,7 +695,7 @@ properties:
- const: pine64,pinephone-1.2
- const: allwinner,sun50i-a64
- - description: Pine64 PineTab
+ - description: Pine64 PineTab, Development Sample
items:
- const: pine64,pinetab
- const: allwinner,sun50i-a64
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts
b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts
index 0494bfaf2ffa..422a8507f674 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts
@@ -14,7 +14,7 @@
#include
/ {
- model = "PineTab";
+ model = "PineTab, Development Sample";
compatible = "pine64,pinetab", "allwinner,sun50i-a64";
aliases {
--
2.28.0
Re: [External] Re: [PATCH v5 7/7] mm: memcontrol: make the slab calculation consistent
On Thu, Dec 24, 2020 at 5:21 AM Shakeel Butt wrote:
>
> On Wed, Dec 16, 2020 at 7:46 PM Muchun Song wrote:
> >
> > Although the ratio of the slab is one, we also should read the ratio
> > from the related memory_stats instead of hard-coding. And the local
> > variable of size is already the value of slab_unreclaimable. So we
> > do not need to read again.
> >
> > To do this we need some code like below:
> >
> > if (unlikely(memory_stats[i].idx == NR_SLAB_UNRECLAIMABLE_B)) {
> > - size = memcg_page_state(memcg, NR_SLAB_RECLAIMABLE_B) +
> > - memcg_page_state(memcg, NR_SLAB_UNRECLAIMABLE_B);
> > + size += memcg_page_state(memcg, memory_stats[i - 1].idx) *
> > + memory_stats[i - 1].ratio;
Hi Shakeel,
Here is the [i - 1].
> >
> > It requires a series of BUG_ONs or comments to ensure these two
> > items are actually adjacent and in the right order. So it would
> > probably be easier to implement this using a wrapper that has a
> > big switch() for unit conversion.
> >
> > This would fix the ratio inconsistency and get rid of the order
> > guarantee.
> >
>
> The commit message is really confusing. It is explaining a situation
> which it did not do. I don't see any benefit of mentioning BUG_ONs or
> [i-1]s in the message. The patch makes sure that we use the right
> ratio for slab. Can you rewrite the commit message and motivate in
> just that regard?
Yeah, I need rewrite the commit message to make it more clear.
However, here is a discussion about this. See
https://lore.kernel.org/patchwork/patch/1348611/
Thanks.
>
> > Signed-off-by: Muchun Song
> > ---
> > mm/memcontrol.c | 105
> > +++-
> > 1 file changed, 66 insertions(+), 39 deletions(-)
> >
> > diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> > index a40797a27f87..eec44918d373 100644
> > --- a/mm/memcontrol.c
> > +++ b/mm/memcontrol.c
> > @@ -1511,49 +1511,71 @@ static bool mem_cgroup_wait_acct_move(struct
> > mem_cgroup *memcg)
> >
> > struct memory_stat {
> > const char *name;
> > - unsigned int ratio;
> > unsigned int idx;
> > };
> >
> > static const struct memory_stat memory_stats[] = {
> > - { "anon", PAGE_SIZE, NR_ANON_MAPPED },
> > - { "file", PAGE_SIZE, NR_FILE_PAGES },
> > - { "kernel_stack", 1024, NR_KERNEL_STACK_KB },
> > - { "pagetables", PAGE_SIZE, NR_PAGETABLE },
> > - { "percpu", 1, MEMCG_PERCPU_B },
> > - { "sock", PAGE_SIZE, MEMCG_SOCK },
> > - { "shmem", PAGE_SIZE, NR_SHMEM },
> > - { "file_mapped", PAGE_SIZE, NR_FILE_MAPPED },
> > - { "file_dirty", PAGE_SIZE, NR_FILE_DIRTY },
> > - { "file_writeback", PAGE_SIZE, NR_WRITEBACK },
> > + { "anon", NR_ANON_MAPPED },
> > + { "file", NR_FILE_PAGES },
> > + { "kernel_stack", NR_KERNEL_STACK_KB },
> > + { "pagetables", NR_PAGETABLE},
> > + { "percpu", MEMCG_PERCPU_B },
> > + { "sock", MEMCG_SOCK },
> > + { "shmem", NR_SHMEM},
> > + { "file_mapped",NR_FILE_MAPPED },
> > + { "file_dirty", NR_FILE_DIRTY },
> > + { "file_writeback", NR_WRITEBACK},
> > #ifdef CONFIG_TRANSPARENT_HUGEPAGE
> > - { "anon_thp", PAGE_SIZE, NR_ANON_THPS },
> > - { "file_thp", PAGE_SIZE, NR_FILE_THPS },
> > - { "shmem_thp", PAGE_SIZE, NR_SHMEM_THPS },
> > + { "anon_thp", NR_ANON_THPS},
> > + { "file_thp", NR_FILE_THPS},
> > + { "shmem_thp", NR_SHMEM_THPS },
> > #endif
> > - { "inactive_anon", PAGE_SIZE, NR_INACTIVE_ANON },
> > - { "active_anon", PAGE_SIZE, NR_ACTIVE_ANON },
> > - { "inactive_file", PAGE_SIZE, NR_INACTIVE_FILE },
> > - { "active_file", PAGE_SIZE, NR_ACTIVE_FILE },
> > - { "unevictable", PAGE_SIZE, NR_UNEVICTABLE },
> > -
> > - /*
> > -* Note: The slab_reclaimable and slab_unreclaimable must be
> > -* together and slab_reclaimable must be in front.
> > -*/
> > - { "slab_reclaimable", 1, NR_SLAB_RECLAIMABLE_B },
> > - { "slab_unreclaimable", 1, NR_SLAB_UNRECLAIMABLE_B },
> > + { "inactive_anon", NR_INACTIVE_ANON},
> > + { "active_anon",NR_ACTIVE_ANON },
> > + { "inactive_file", NR_INACTIVE_FILE},
> > + { "active_file",NR_ACTIVE_FILE },
> > + { "unevictable",NR_UNEVICTABLE },
> > + {
[PATCH v2 2/3] arm64: allwinner: dts: a64: add DT for Early Adopter's PineTab
PineTabs since Early Adopter batch will use a new LCD panel.
Add device tree for PineTab with the new panel.
Signed-off-by: Icenowy Zheng
---
arch/arm64/boot/dts/allwinner/Makefile| 1 +
.../sun50i-a64-pinetab-early-adopter.dts | 26 +++
2 files changed, 27 insertions(+)
create mode 100644
arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-early-adopter.dts
diff --git a/arch/arm64/boot/dts/allwinner/Makefile
b/arch/arm64/boot/dts/allwinner/Makefile
index 211d1e9d4701..41ce680e5f8d 100644
--- a/arch/arm64/boot/dts/allwinner/Makefile
+++ b/arch/arm64/boot/dts/allwinner/Makefile
@@ -13,6 +13,7 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinephone-1.0.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinephone-1.1.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinephone-1.2.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinetab.dtb
+dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinetab-early-adopter.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-sopine-baseboard.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-teres-i.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a100-allwinner-perf1.dtb
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-early-adopter.dts
b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-early-adopter.dts
new file mode 100644
index ..652fc0cce304
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-early-adopter.dts
@@ -0,0 +1,26 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2020 Icenowy Zheng
+ *
+ */
+
+/dts-v1/;
+
+#include "sun50i-a64-pinetab.dts"
+
+/ {
+ model = "PineTab, Early Adopter's version";
+ compatible = "pine64,pinetab-early-adopter", "allwinner,sun50i-a64";
+};
+
+ {
+ /delete-node/ panel@0;
+
+ panel@0 {
+ compatible = "feixin,k101-im2byl02";
+ reg = <0>;
+ power-supply = <_dc1sw>;
+ reset-gpios = < 3 24 GPIO_ACTIVE_LOW>; /* PD24 */
+ backlight = <>;
+ };
+};
--
2.28.0
