[PATCH] kvm/eventfd:do wildcard calculation before list_for_each_entry_safe
There is no need to calculate wildcard in each loop
since wildcard is not changed.
Signed-off-by: Yi Li
---
virt/kvm/eventfd.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/virt/kvm/eventfd.c b/virt/kvm/eventfd.c
index d6408bb497dc..c2323c27a28b 100644
--- a/virt/kvm/eventfd.c
+++ b/virt/kvm/eventfd.c
@@ -853,15 +853,17 @@ kvm_deassign_ioeventfd_idx(struct kvm *kvm, enum kvm_bus
bus_idx,
struct eventfd_ctx *eventfd;
struct kvm_io_bus*bus;
int ret = -ENOENT;
+ bool wildcard;
eventfd = eventfd_ctx_fdget(args->fd);
if (IS_ERR(eventfd))
return PTR_ERR(eventfd);
+ wildcard = !(args->flags & KVM_IOEVENTFD_FLAG_DATAMATCH);
+
mutex_lock(>slots_lock);
list_for_each_entry_safe(p, tmp, >ioeventfds, list) {
- bool wildcard = !(args->flags & KVM_IOEVENTFD_FLAG_DATAMATCH);
if (p->bus_idx != bus_idx ||
p->eventfd != eventfd ||
--
2.25.3
Re: [PATCH 0/8] drivers: net: convert tasklets to use new tasklet_setup()
David,
>
> Commit 12cc923f1ccc ("tasklet: Introduce new initialization API")'
> introduced a new tasklet initialization API. This series converts
> all the net/* drivers to use the new tasklet_setup() API
>
> Allen Pais (8):
> net: dccp: convert tasklets to use new tasklet_setup() API
> net: ipv4: convert tasklets to use new tasklet_setup() API
> net: mac80211: convert tasklets to use new tasklet_setup() API
> net: mac802154: convert tasklets to use new tasklet_setup() API
> net: rds: convert tasklets to use new tasklet_setup() API
> net: sched: convert tasklets to use new tasklet_setup() API
> net: smc: convert tasklets to use new tasklet_setup() API
> net: xfrm: convert tasklets to use new tasklet_setup() API
>
> net/dccp/timer.c | 10 +-
> net/ipv4/tcp_output.c | 8 +++-
> net/mac80211/ieee80211_i.h | 4 ++--
> net/mac80211/main.c| 14 +-
> net/mac80211/tx.c | 5 +++--
> net/mac80211/util.c| 5 +++--
> net/mac802154/main.c | 8 +++-
> net/rds/ib_cm.c| 14 ++
> net/sched/sch_atm.c| 9 +
> net/smc/smc_cdc.c | 6 +++---
> net/smc/smc_wr.c | 14 ++
> net/xfrm/xfrm_input.c | 7 +++
> 12 files changed, 47 insertions(+), 57 deletions(-)
>
> --
> 2.17.1
>
Will you pick these up or should I send these out again when I
have fixed the two patches on the other thread.
Thanks,
--
- Allen
Re: [PATCH 00/30] docs: fix documentation build parsing errors
Em Thu, 10 Sep 2020 10:42:50 -0600 Jonathan Corbet escreveu: > On Wed, 9 Sep 2020 16:10:31 +0200 > Mauro Carvalho Chehab wrote: > > > Currently, there are several warnings/errors produced when building > > the documentation with "make htmldocs". > > > > This series fixes almost all such errors. It is produced against > > linux-next, branch next-20200909. > > > > Some of the patches here were already sent individually, but nobody > > picked them. So, I'm re-sending the full series. > > I'd sure love to just apply the whole series and clean up a lot of this > stuff, but (1) I'm not entirely comfortable taking a few through > docs-next, and (2) some of them don't apply even if I catch up to -rc4. > So I'm going to pass through them individually and snag as many as I can... Yeah. As I commented on the other series, as warnings reach upstream from different trees, the only sane way to fix them is by using linux-next. I'll keep rebase those. This way, if something ends being lost, we could submit upstream by the end of the merge window. Btw, as Andrii gently submitted a fix for the two remaining litmus doc warnings, once everything gets merged, htmldocs should now produce zero doc warnings. I'll keep track on this. Hopefully, we can make 5.10 free of doc warnings, and build robots can start warning about newly introduced ones. Thanks, Mauro
Re: [PATCH] soundwire: bus: add enumerated slave to device list
On 10-09-20, 09:02, Pierre-Louis Bossart wrote: > > > > > May be we could make the enumerated devices discovery bit more verbose! > > > > > > Maybe adding a device number sysfs entry would help, e.g. reporting > > > NotAttched or a value in [0,11] would tell you if the device is actually > > > present. > > > > Agreed, I cooked this patch to report verbose device status, let me know > > if you are okay with this. I think this would be useful regardless of > > current discussion. > > > > On Db845c I see: > > > > root@linaro-alip:/sys/bus/soundwire/devices# cat sdw:0:217:2010:0:1/status > > Attached > > root@linaro-alip:/sys/bus/soundwire/devices# cat sdw:0:217:2010:0:2/status > > Attached > > looks like we are all aligned on the idea, I have a similar patch to at > https://github.com/thesofproject/linux/pull/2426 > > The difference is that the sysfs status and device_number is added even > without a driver probe and when there's no firmware description. sysfs is > currently only added after the driver probe, which wouldn't work for the > case Srinivas was trying to deal with. Okay sound fine > but the way you dealt the status below is better than the switch case I > used, so will merge this into my code. Why merge? That patch can remain independent and you can add device_number patch on top and another one for moving sysfs creation without a driver probe, these three sound like three different patches to me. > Srinivas' patch needs a fix for ACPI platforms, won't probe otherwise since > we don't have an of_node. If that's alright with everyone I can submit a > patchset that gathers the 3 contributions. Yes one series should be good, but lets keep one change in a patch please -- ~Vinod
Re: [PATCH 1/2] extcon: ptn5150: Use defines for registers
On Fri, Sep 11, 2020 at 12:14:19PM +0900, Chanwoo Choi wrote:
> On 9/10/20 12:01 AM, Krzysztof Kozlowski wrote:
> > The register addresses are not continuous, so use simple defines for
> > them. This also makes it easier to find the address for register.
> >
> > No functional change.
> >
> > Signed-off-by: Krzysztof Kozlowski
> > ---
> > drivers/extcon/extcon-ptn5150.c | 22 ++
> > 1 file changed, 10 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/extcon/extcon-ptn5150.c
> > b/drivers/extcon/extcon-ptn5150.c
> > index dda5b3a3a908..1b68f56d8372 100644
> > --- a/drivers/extcon/extcon-ptn5150.c
> > +++ b/drivers/extcon/extcon-ptn5150.c
> > @@ -19,18 +19,16 @@
> > #include
> >
> > /* PTN5150 registers */
> > -enum ptn5150_reg {
> > - PTN5150_REG_DEVICE_ID = 0x01,
> > - PTN5150_REG_CONTROL,
> > - PTN5150_REG_INT_STATUS,
> > - PTN5150_REG_CC_STATUS,
> > - PTN5150_REG_CON_DET = 0x09,
> > - PTN5150_REG_VCONN_STATUS,
> > - PTN5150_REG_RESET,
> > - PTN5150_REG_INT_MASK = 0x18,
> > - PTN5150_REG_INT_REG_STATUS,
> > - PTN5150_REG_END,
> > -};
> > +#define PTN5150_REG_DEVICE_ID 0x01
> > +#define PTN5150_REG_CONTROL0x02
> > +#define PTN5150_REG_INT_STATUS 0x03
> > +#define PTN5150_REG_CC_STATUS 0x04
> > +#define PTN5150_REG_CON_DET0x09
> > +#define PTN5150_REG_VCONN_STATUS 0x0a
> > +#define PTN5150_REG_RESET 0x0b
> > +#define PTN5150_REG_INT_MASK 0x18
> > +#define PTN5150_REG_INT_REG_STATUS 0x19
> > +#define PTN5150_REG_END
> > PTN5150_REG_INT_REG_STATUS
>
> PTN5150_REG_END should be (PTN5150_REG_INT_REG_STATUS + 1)
> for regmap operation of PTN5150_REG_INT_REG_STATUS.
Why? This goes to regmap's max_register which is the last register
allowed to read:
drivers/base/regmap/regmap-debugfs.c: for (i = 0; i <= map->max_register; i
+= map->reg_stride) {
drivers/base/regmap/regmap.c: if (map->max_register && reg >
map->max_register)
regmap_get_max_register() - Report the max register value
Best regards,
Krzysztof
Re: [PATCH v2 5/9] iomap: Support arbitrarily many blocks per page
On Fri, Sep 11, 2020 at 12:47:03AM +0100, Matthew Wilcox (Oracle) wrote: > Size the uptodate array dynamically to support larger pages in the > page cache. With a 64kB page, we're only saving 8 bytes per page today, > but with a 2MB maximum page size, we'd have to allocate more than 4kB > per page. Add a few debugging assertions. > > Signed-off-by: Matthew Wilcox (Oracle) > Reviewed-by: Dave Chinner Looks good, Reviewed-by: Christoph Hellwig
Re: [PATCH v2 6/9] iomap: Convert read_count to read_bytes_pending
On Fri, Sep 11, 2020 at 12:47:04AM +0100, Matthew Wilcox (Oracle) wrote: > Instead of counting bio segments, count the number of bytes submitted. > This insulates us from the block layer's definition of what a 'same page' > is, which is not necessarily clear once THPs are involved. > > Signed-off-by: Matthew Wilcox (Oracle) Looks good, Reviewed-by: Christoph Hellwig
Re: [PATCH v1] ARM: dts: aspeed: Add Mowgli BMC platform
On Wed, 9 Sep 2020 at 09:09, Ben Pai wrote:
>
> The Mowgli BMC is an ASPEED ast2500 based BMC that is part of an
> OpenPower Power9 server.
>
> Signed-off-by: Ben Pai
This looks good to me. I assume you have all the hardware correctly described.
I notice you don't have any gpio-line-names. If you're using recent
openbmc you will need those descriptions, but I will leave that to
you.
Reviewed-by: Joel Stanley
Cheers,
Joel
> ---
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/aspeed-bmc-opp-mowgli.dts | 663
> 2 files changed, 664 insertions(+)
> create mode 100644 arch/arm/boot/dts/aspeed-bmc-opp-mowgli.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 4572db3fa5ae..92edb2e12823 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -1381,6 +1381,7 @@ dtb-$(CONFIG_ARCH_ASPEED) += \
> aspeed-bmc-microsoft-olympus.dtb \
> aspeed-bmc-opp-lanyang.dtb \
> aspeed-bmc-opp-mihawk.dtb \
> + aspeed-bmc-opp-mowgli.dtb \
> aspeed-bmc-opp-nicole.dtb \
> aspeed-bmc-opp-palmetto.dtb \
> aspeed-bmc-opp-romulus.dtb \
> diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-mowgli.dts
> b/arch/arm/boot/dts/aspeed-bmc-opp-mowgli.dts
> new file mode 100644
> index ..11fd86980162
> --- /dev/null
> +++ b/arch/arm/boot/dts/aspeed-bmc-opp-mowgli.dts
> @@ -0,0 +1,663 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/dts-v1/;
> +#include "aspeed-g5.dtsi"
> +#include
> +#include
> +
> +/ {
> + model = "Mowgli BMC";
> + compatible = "ibm,mowgli-bmc", "aspeed,ast2500";
> +
> +
> + chosen {
> + stdout-path =
> + bootargs = "console=ttyS4,115200 earlyprintk";
> + };
> +
> + memory@8000 {
> + reg = <0x8000 0x2000>;
> + };
> +
> + reserved-memory {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + flash_memory: region@9800 {
> + no-map;
> + reg = <0x9800 0x0400>; /* 64M */
> + };
> +
> + gfx_memory: framebuffer {
> + size = <0x0100>;
> + alignment = <0x0100>;
> + compatible = "shared-dma-pool";
> + reusable;
> + };
> +
> + video_engine_memory: jpegbuffer {
> + size = <0x0200>;
> + alignment = <0x0100>;
> + compatible = "shared-dma-pool";
> + reusable;
> + };
> + };
> +
> + gpio-keys {
> + compatible = "gpio-keys";
> +
> + air-water {
> + label = "air-water";
> + gpios = < ASPEED_GPIO(F, 6) GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + };
> +
> + checkstop {
> + label = "checkstop";
> + gpios = < ASPEED_GPIO(J, 2) GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + };
> +
> + ps0-presence {
> + label = "ps0-presence";
> + gpios = < ASPEED_GPIO(Z, 2) GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + };
> +
> + ps1-presence {
> + label = "ps1-presence";
> + gpios = < ASPEED_GPIO(Z, 0) GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + };
> +
> + id-button {
> + label = "id-button";
> + gpios = < ASPEED_GPIO(F, 1) GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + };
> + };
> +
> + gpio-keys-polled {
> + compatible = "gpio-keys-polled";
> + poll-interval = <1000>;
> +
> + fan0-presence {
> + label = "fan0-presence";
> + gpios = < 9 GPIO_ACTIVE_LOW>;
> + linux,code = <9>;
> + };
> +
> + fan1-presence {
> + label = "fan1-presence";
> + gpios = < 10 GPIO_ACTIVE_LOW>;
> + linux,code = <10>;
> + };
> +
> + fan2-presence {
> + label = "fan2-presence";
> + gpios = < 11 GPIO_ACTIVE_LOW>;
> + linux,code = <11>;
> + };
> +
> + fan3-presence {
> + label = "fan3-presence";
> + gpios = < 12 GPIO_ACTIVE_LOW>;
> + linux,code = <12>;
> + };
> +
> + fan4-presence {
> + label = "fan4-presence";
> +
Re: [PATCH 2/2] watchdog: sp5100_tco: Enable watchdog on Family 17h devices if disabled
On 10.09.20 18:55, Jan Kiszka wrote:
> On 10.09.20 18:53, Guenter Roeck wrote:
>> Hi Jan,
>>
>> On 9/10/20 9:34 AM, Jan Kiszka wrote:
>>> On 10.09.20 18:31, Guenter Roeck wrote:
On Family 17h (Ryzen) devices, the WatchdogTmrEn bit of PmDecodeEn not only
enables watchdog memory decoding at 0xfeb0, it also enables the
watchdog hardware itself. Use this information to enable the watchdog if
it is not already enabled.
Cc: Jan Kiszka
Signed-off-by: Guenter Roeck
---
drivers/watchdog/sp5100_tco.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/watchdog/sp5100_tco.c b/drivers/watchdog/sp5100_tco.c
index 85e9664318c9..a730ecbf78cd 100644
--- a/drivers/watchdog/sp5100_tco.c
+++ b/drivers/watchdog/sp5100_tco.c
@@ -17,6 +17,12 @@
*AMD Publication 51192 "AMD Bolton FCH Register Reference
Guide"
*AMD Publication 52740 "BIOS and Kernel Developer’s Guide
(BKDG)
*for AMD Family 16h Models 30h-3Fh
Processors"
+ *AMD Publication 55570-B1-PUB "Processor Programming
Reference (PPR)
+ *for AMD Family 17h Model 18h, Revision
B1
+ *Processors (PUB)
+ *AMD Publication 55772-A1-PUB "Processor Programming
Reference (PPR)
+ *for AMD Family 17h Model 20h, Revision
A1
+ *Processors (PUB)
*/
/*
@@ -241,6 +247,18 @@ static int sp5100_tco_setupdevice(struct device *dev,
break;
case efch:
dev_name = SB800_DEVNAME;
+ /*
+ * On Family 17h devices, the EFCH_PM_DECODEEN_WDT_TMREN bit of
+ * EFCH_PM_DECODEEN not only enables the EFCH_PM_WDT_ADDR memory
+ * region, it also enables the watchdog itself.
+ */
+ if (boot_cpu_data.x86 == 0x17) {
+ val = sp5100_tco_read_pm_reg8(EFCH_PM_DECODEEN);
+ if (!(val & EFCH_PM_DECODEEN_WDT_TMREN)) {
+ sp5100_tco_update_pm_reg8(EFCH_PM_DECODEEN,
0xff,
+
EFCH_PM_DECODEEN_WDT_TMREN);
+ }
+ }
val = sp5100_tco_read_pm_reg8(EFCH_PM_DECODEEN);
if (val & EFCH_PM_DECODEEN_WDT_TMREN)
mmio_addr = EFCH_PM_WDT_ADDR;
>>>
>>> Won't that bring us EFCH_PM_WDT_ADDR as address, rather than
>>> EFCH_PM_ACPI_MMIO_ADDR which worked in my case? Or is one an alias of
>>> the other.
>>>
>>
>> Yes, it does use EFCH_PM_WDT_ADDR. EFCH_PM_ACPI_MMIO_ADDR works as well,
>> but is meant to be a fallback. Both point to the watchdog memory space.
>>
>
> OK, will test, possibly only on the weekend, and confirm this also on my
> board.
>
> Jan
>
Both patches now
Tested-by: Jan Kiszka
Thanks,
Jan
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
[tip:x86/fpu] BUILD SUCCESS 0a4bb5e5507a585532cc413125b921c8546fc39f
alldefconfig mips cobalt_defconfig mips rt305x_defconfig sh kfr2r09_defconfig arcnsim_700_defconfig armmvebu_v7_defconfig arm h3600_defconfig powerpc rainier_defconfig shapsh4ad0a_defconfig armmulti_v5_defconfig ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68k allyesconfig nios2 defconfig arc allyesconfig nds32 allnoconfig c6x allyesconfig nds32 defconfig nios2allyesconfig cskydefconfig alpha defconfig alphaallyesconfig h8300allyesconfig arc defconfig parisc defconfig s390 allyesconfig parisc allyesconfig s390defconfig i386 allyesconfig sparcallyesconfig i386defconfig mips allyesconfig mips allmodconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig powerpc defconfig x86_64 randconfig-a004-20200910 x86_64 randconfig-a006-20200910 x86_64 randconfig-a003-20200910 x86_64 randconfig-a002-20200910 x86_64 randconfig-a005-20200910 x86_64 randconfig-a001-20200910 i386 randconfig-a004-20200909 i386 randconfig-a005-20200909 i386 randconfig-a006-20200909 i386 randconfig-a002-20200909 i386 randconfig-a001-20200909 i386 randconfig-a003-20200909 i386 randconfig-a004-20200911 i386 randconfig-a006-20200911 i386 randconfig-a001-20200911 i386 randconfig-a003-20200911 i386 randconfig-a002-20200911 i386 randconfig-a005-20200911 i386 randconfig-a004-20200910 i386 randconfig-a006-20200910 i386 randconfig-a001-20200910 i386 randconfig-a003-20200910 i386 randconfig-a002-20200910 i386 randconfig-a005-20200910 x86_64 randconfig-a014-20200911 x86_64 randconfig-a011-20200911 x86_64 randconfig-a012-20200911 x86_64 randconfig-a016-20200911 x86_64 randconfig-a015-20200911 x86_64 randconfig-a013-20200911 i386 randconfig-a015-20200911 i386 randconfig-a014-20200911 i386 randconfig-a011-20200911 i386 randconfig-a013-20200911 i386 randconfig-a016-20200911 i386 randconfig-a012-20200911 i386 randconfig-a016-20200909 i386 randconfig-a015-20200909 i386 randconfig-a011-20200909 i386 randconfig-a013-20200909 i386 randconfig-a014-20200909 i386 randconfig-a012-20200909 riscvallyesconfig riscv allnoconfig riscv defconfig riscvallmodconfig x86_64 rhel x86_64 allyesconfig x86_64rhel-7.6-kselftests x86_64 defconfig x86_64 rhel-8.3 x86_64 kexec clang tested configs: x86_64 randconfig-a004-20200911 x86_64 randconfig-a006-20200911 x86_64 randconfig-a003-20200911 x86_64 randconfig-a002-20200911 x86_64 randconfig-a005-20200911 x86_64 randconfig-a001-20200911 x86_64 randconfig-a013-20200909 x86_64 randconfig-a016-20200909 x86_64 randconfig-a011-20200909 x86_64 randconfig-a012-20200909 x86_64 randconfig-a015-20200909 x86_64 randconfig-a014-20200909 --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
[PATCH v7 07/10] dt-bindings: reset: s700: Add binding constants for mmc
This commit adds device tree binding reset constants for mmc controller present on Actions S700 Soc. Reviewed-by: Manivannan Sadhasivam Acked-by: Rob Herring Signed-off-by: Amit Singh Tomar --- Changes since v6: * No change. Changes since v5: * Added Mani's Reviewed-by: tag. Changes since v4: * No change. Changes since v3: * No change. Changes since v2: * No change. Changes since v1: * No change. Changes since RFC: * added Rob's acked-by tag --- include/dt-bindings/reset/actions,s700-reset.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/dt-bindings/reset/actions,s700-reset.h b/include/dt-bindings/reset/actions,s700-reset.h index 5e3b16b8ef53..a3118de6d7aa 100644 --- a/include/dt-bindings/reset/actions,s700-reset.h +++ b/include/dt-bindings/reset/actions,s700-reset.h @@ -30,5 +30,8 @@ #define RESET_UART420 #define RESET_UART521 #define RESET_UART622 +#define RESET_SD0 23 +#define RESET_SD1 24 +#define RESET_SD2 25 #endif /* __DT_BINDINGS_ACTIONS_S700_RESET_H */ -- 2.7.4
[PATCH v7 08/10] dt-bindings: mmc: owl: add compatible string actions,s700-mmc
The commit adds a new SoC specific compatible string "actions,s700-mmc" in combination with more generic string "actions,owl-mmc". Placement order of these strings should abide by the principle of "from most specific to most general". Reviewed-by: Manivannan Sadhasivam Reviewed-by: Rob Herring Signed-off-by: Amit Singh Tomar --- Changes since v6: * No change. Changes since v5: * Added Mani's Reviewed-by: tag. Changes since v4: * No change. Changes since v3: * No change. Changes since v2: * Added Rob's Reviewed-by tag --- Documentation/devicetree/bindings/mmc/owl-mmc.yaml | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/mmc/owl-mmc.yaml b/Documentation/devicetree/bindings/mmc/owl-mmc.yaml index 1380501fb8f0..5eab25ccf7ae 100644 --- a/Documentation/devicetree/bindings/mmc/owl-mmc.yaml +++ b/Documentation/devicetree/bindings/mmc/owl-mmc.yaml @@ -14,7 +14,11 @@ maintainers: properties: compatible: -const: actions,owl-mmc +oneOf: + - const: actions,owl-mmc + - items: + - const: actions,s700-mmc + - const: actions,owl-mmc reg: maxItems: 1 -- 2.7.4
[PATCH] mailbox: sti: fix struct description warnings
Fix formating of struct description to avoid warning highlighted
by W=1 compilation.
warning: cannot understand function prototype: 'struct sti_mbox_device '
warning: cannot understand function prototype: 'struct sti_mbox_pdata '
warning: cannot understand function prototype: 'struct sti_channel '
Signed-off-by: Alain Volmat
Reviewed-by: Lee Jones
---
drivers/mailbox/mailbox-sti.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/mailbox/mailbox-sti.c b/drivers/mailbox/mailbox-sti.c
index 2baf69a0b81c..0f2bc09c364d 100644
--- a/drivers/mailbox/mailbox-sti.c
+++ b/drivers/mailbox/mailbox-sti.c
@@ -36,7 +36,7 @@
#define MBOX_BASE(mdev, inst) ((mdev)->base + ((inst) * 4))
/**
- * STi Mailbox device data
+ * struct sti_mbox_device - STi Mailbox device data
*
* An IP Mailbox is currently composed of 4 instances
* Each instance is currently composed of 32 channels
@@ -60,7 +60,7 @@ struct sti_mbox_device {
};
/**
- * STi Mailbox platform specific configuration
+ * struct sti_mbox_pdata - STi Mailbox platform specific configuration
*
* @num_inst: Maximum number of instances in one HW Mailbox
* @num_chan: Maximum number of channel per instance
@@ -71,7 +71,7 @@ struct sti_mbox_pdata {
};
/**
- * STi Mailbox allocated channel information
+ * struct sti_channel - STi Mailbox allocated channel information
*
* @mdev: Pointer to parent Mailbox device
* @instance: Instance number channel resides in
--
2.17.1
[GIT PULL] FSI changes for 5.10
Hi Greg, Here are some FSI changes for the 5.10 merge window. The following changes since commit 4a851d714eadeabd65c7e321a2e7830f77d945c4: fsi: aspeed: Support CFAM reset GPIO (2020-09-10 12:26:43 +0930) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/joel/fsi.git tags/fsi-for-5.10 for you to fetch changes up to 4a851d714eadeabd65c7e321a2e7830f77d945c4: fsi: aspeed: Support CFAM reset GPIO (2020-09-10 12:26:43 +0930) FSI changes for 5.10 - Misc code cleanups. Thanks to Colin, Xu and Rikard - Features for the ASPEED FSI master * Detect connection type and routing for Tacoma * Run at full speed (200MHz) by default * Set bus speed with a parameter * CFAM reset GPIO * 23 bit addressing - Core features * Disable unused links * Set LBUS ownership Colin Ian King (1): fsi: master-ast-cf: fix spelling mistake "firwmare" -> "firmware" Eddie James (5): fsi: aspeed: Enable 23-bit addressing fsi: master: Add boolean parameter to link_enable function fsi: core: Disable link when slave init fails fsi: core: Set slave local bus ownership during init fsi: master: Remove link enable read-back Joel Stanley (5): dt-bindings: fsi: Document gpios fsi: aspeed: Support cabled FSI fsi: aspeed: Run the bus at maximum speed fsi: aspeed: Add module param for bus divisor fsi: aspeed: Support CFAM reset GPIO Rikard Falkeborn (3): fsi: master: Constify hub_master_ids fsi: sbefifo: Constify sbefifo_ids fsi: scom: Constify scom_ids Xu Wang (1): fsi: fsi-occ: fix return value check in occ_probe() Documentation/ABI/testing/sysfs-bus-fsi | 8 + Documentation/devicetree/bindings/fsi/fsi-master-aspeed.txt | 12 +++ drivers/fsi/fsi-core.c | 31 +++-- drivers/fsi/fsi-master-aspeed.c | 134 - drivers/fsi/fsi-master-ast-cf.c | 7 ++-- drivers/fsi/fsi-master-gpio.c | 5 +-- drivers/fsi/fsi-master-hub.c| 15 ++--- drivers/fsi/fsi-master.h| 3 +- drivers/fsi/fsi-occ.c | 2 +- drivers/fsi/fsi-sbefifo.c | 2 +- drivers/fsi/fsi-scom.c | 2 +- 11 files changed, 188 insertions(+), 33 deletions(-)
[PATCH v2 0/3] mainline Plymovent M2M board
changes v2: - fsl.yaml: reorder ply,plym2m - imx6dl-plym2m.dts: use hyphen instead of underscore in phy-clock Oleksij Rempel (3): dt-bindings: vendor-prefixes: Add an entry for Plymovent dt-bindings: arm: fsl: add Plymovent M2M board ARM: dts: add Plymovent M2M board .../devicetree/bindings/arm/fsl.yaml | 1 + .../devicetree/bindings/vendor-prefixes.yaml | 2 + arch/arm/boot/dts/Makefile| 1 + arch/arm/boot/dts/imx6dl-plym2m.dts | 394 ++ 4 files changed, 398 insertions(+) create mode 100644 arch/arm/boot/dts/imx6dl-plym2m.dts -- 2.28.0
[PATCH v2 3/3] ARM: dts: add Plymovent M2M board
Plymovent M2M is a control interface produced for the Plymovent filter
systems.
Signed-off-by: David Jander
Signed-off-by: Oleksij Rempel
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/imx6dl-plym2m.dts | 394
2 files changed, 395 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6dl-plym2m.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 4572db3fa5ae..3c3811fd8613 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -455,6 +455,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6dl-pico-hobbit.dtb \
imx6dl-pico-nymph.dtb \
imx6dl-pico-pi.dtb \
+ imx6dl-plym2m.dtb \
imx6dl-prtrvt.dtb \
imx6dl-prtvt7.dtb \
imx6dl-rex-basic.dtb \
diff --git a/arch/arm/boot/dts/imx6dl-plym2m.dts
b/arch/arm/boot/dts/imx6dl-plym2m.dts
new file mode 100644
index ..4f96e05aa03f
--- /dev/null
+++ b/arch/arm/boot/dts/imx6dl-plym2m.dts
@@ -0,0 +1,394 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+// SPDX-FileCopyrightText: 2014 Protonic Holland
+// SPDX-FileCopyrightText: 2020 Oleksij Rempel ,
Pengutronix
+
+/dts-v1/;
+#include
+#include
+#include "imx6dl.dtsi"
+
+/ {
+ model = "Plymovent M2M board";
+ compatible = "ply,plym2m", "fsl,imx6dl";
+
+ chosen {
+ stdout-path =
+ };
+
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ pwms = < 0 50 0>;
+ brightness-levels = <0 1000>;
+ num-interpolated-steps = <20>;
+ default-brightness-level = <19>;
+ power-supply = <_12v0>;
+ };
+
+ display {
+ compatible = "fsl,imx-parallel-display";
+ pinctrl-0 = <_ipu1_disp>;
+ pinctrl-names = "default";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ display_in: endpoint {
+ remote-endpoint = <_di0_disp0>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ display_out: endpoint {
+ remote-endpoint = <_in>;
+ };
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <_leds>;
+
+ led-debug {
+ function = LED_FUNCTION_STATUS;
+ gpios = < 8 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "heartbeat";
+ };
+ };
+
+ panel {
+ compatible = "edt,etm0700g0bdh6";
+ backlight = <>;
+ power-supply = <_3v3>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <_out>;
+ };
+ };
+ };
+
+ clk50m_phy: phy-clock {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <5000>;
+ };
+
+ reg_3v3: regulator-3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "3v3";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ };
+
+ reg_5v0: regulator-5v0 {
+ compatible = "regulator-fixed";
+ regulator-name = "5v0";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ };
+
+ reg_12v0: regulator-12v0 {
+ compatible = "regulator-fixed";
+ regulator-name = "12v0";
+ regulator-min-microvolt = <1200>;
+ regulator-max-microvolt = <1200>;
+ };
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_can1>;
+ xceiver-supply = <_5v0>;
+ status = "okay";
+};
+
+ {
+ cs-gpios = < 19 GPIO_ACTIVE_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_ecspi1>;
+ status = "okay";
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <2000>;
+ };
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_enet>;
+ phy-mode = "rmii";
+ clocks = < IMX6QDL_CLK_ENET>,
+< IMX6QDL_CLK_ENET>,
+<_phy>;
+ clock-names = "ipg", "ahb", "ptp";
+ status = "okay";
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* Microchip KSZ8081RNA PHY */
+ rgmii_phy: ethernet-phy@0 {
+ reg = <0>;
+ interrupts-extended = < 23 IRQ_TYPE_LEVEL_LOW>;
+ reset-gpios = < 22
[PATCH v2 2/3] dt-bindings: arm: fsl: add Plymovent M2M board
Add Plymovent Group BV M2M iMX6dl based board Signed-off-by: Oleksij Rempel --- Documentation/devicetree/bindings/arm/fsl.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml index 6da9d734cdb7..e94a455eeab9 100644 --- a/Documentation/devicetree/bindings/arm/fsl.yaml +++ b/Documentation/devicetree/bindings/arm/fsl.yaml @@ -174,6 +174,7 @@ properties: - fsl,imx6dl-sabreauto # i.MX6 DualLite/Solo SABRE Automotive Board - fsl,imx6dl-sabresd# i.MX6 DualLite SABRE Smart Device Board - kontron,imx6dl-samx6i # Kontron i.MX6 Solo SMARC Module + - ply,plym2m# Plymovent M2M board - prt,prtrvt# Protonic RVT board - prt,prtvt7# Protonic VT7 board - technexion,imx6dl-pico-dwarf # TechNexion i.MX6DL Pico-Dwarf -- 2.28.0
[PATCH v2 1/3] dt-bindings: vendor-prefixes: Add an entry for Plymovent
Add "ply" entry for Plymovent Group BV: https://www.plymovent.com/ Signed-off-by: Oleksij Rempel --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 2baee2c817c1..60b59ca04066 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -818,6 +818,8 @@ patternProperties: description: PLDA "^plx,.*": description: Broadcom Corporation (formerly PLX Technology) + "^ply,.*": +description: Plymovent Group BV "^pni,.*": description: PNI Sensor Corporation "^pocketbook,.*": -- 2.28.0
Re: [PATCH kernel] srcu: Fix static initialization
On 11/09/2020 04:53, Paul E. McKenney wrote:
> On Wed, Sep 09, 2020 at 10:31:03PM +1000, Alexey Kardashevskiy wrote:
>>
>>
>> On 09/09/2020 21:50, Paul E. McKenney wrote:
>>> On Wed, Sep 09, 2020 at 07:24:11PM +1000, Alexey Kardashevskiy wrote:
On 09/09/2020 00:43, Alexey Kardashevskiy wrote:
> init_srcu_struct_nodes() is called with is_static==true only internally
> and when this happens, the srcu->sda is not initialized in
> init_srcu_struct_fields() and we crash on dereferencing @sdp.
>
> This fixes the crash by moving "if (is_static)" out of the loop which
> only does useful work for is_static=false case anyway.
>
> Found by syzkaller.
>
> Signed-off-by: Alexey Kardashevskiy
> ---
> kernel/rcu/srcutree.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/rcu/srcutree.c b/kernel/rcu/srcutree.c
> index c100acf332ed..49b54a50bde8 100644
> --- a/kernel/rcu/srcutree.c
> +++ b/kernel/rcu/srcutree.c
> @@ -135,6 +135,9 @@ static void init_srcu_struct_nodes(struct srcu_struct
> *ssp, bool is_static)
> levelspread[level - 1];
> }
>
> + if (is_static)
> + return;
Actually, this is needed here too:
if (!ssp->sda)
return;
as
ssp->sda = alloc_percpu(struct srcu_data)
can fail if the process is killed too soon - it is quite easy to get
this situation with syzkaller (syscalls fuzzer)
Makes sense?
>>>
>>> Just to make sure that I understand, these failures occur when the task
>>> running init_srcu_struct_nodes() is killed, correct?
>>
>> There are multiple user tasks (8) which open /dev/kvm, do 1 ioctl -
>> KVM_CREATE_VM - and terminate, running on 8 vcpus, 8 VMs, crashes every
>> 20min or so, less tasks or vcpus - and the problem does not appear.
>>
>>
>>>
>>> Or has someone managed to invoke (say) synchronize_srcu() on a
>>> dynamically allocated srcu_struct before invoking init_srcu_struct() on
>>> that srcu_struct?
>>
>> Nah, none of that :)
>>
>> init_srcu_struct_nodes() assumes ssp->sda!=NULL but alloc_percpu() fails
>> here:
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/mm/percpu.c#n1734
>> ===
>> } else if (mutex_lock_killable(_alloc_mutex)) {
>> pcpu_memcg_post_alloc_hook(objcg, NULL, 0, size);
>> return NULL;
>> ===
>>
>> I am still up to reading that osr-rcuusage.pdf to provide better
>> analysis :) Thanks,
>
> Ah, got it! Does the following patch help?
>
> There will likely also need to be changes to cleanup_srcu_struct(),
> but first let's see if I understand the problem. ;-)
>
> Thanx, Paul
>
>
>
> diff --git a/kernel/rcu/srcutree.c b/kernel/rcu/srcutree.c
> index c13348e..6f7880a 100644
> --- a/kernel/rcu/srcutree.c
> +++ b/kernel/rcu/srcutree.c
> @@ -177,11 +177,13 @@ static int init_srcu_struct_fields(struct srcu_struct
> *ssp, bool is_static)
> INIT_DELAYED_WORK(>work, process_srcu);
> if (!is_static)
> ssp->sda = alloc_percpu(struct srcu_data);
> + if (!ssp->sda)
> + return -ENOMEM;
> init_srcu_struct_nodes(ssp, is_static);
> ssp->srcu_gp_seq_needed_exp = 0;
> ssp->srcu_last_gp_end = ktime_get_mono_fast_ns();
> smp_store_release(>srcu_gp_seq_needed, 0); /* Init done. */
The line above confuses me a bit. What you propose returns without
smp_store_release() called which should not matter I suppose.
Otherwise it should work, although I cannot verify right now as my box
went down and since it is across Pacific - it may take time to power
cycle it :) Thanks,
> - return ssp->sda ? 0 : -ENOMEM;
> + return 0;
> }
>
> #ifdef CONFIG_DEBUG_LOCK_ALLOC
>
--
Alexey
[PATCH] powerpc/kasan: Fix CONFIG_KASAN_VMALLOC for 8xx
Before the commit identified below, pages tables allocation was
performed after the allocation of final shadow area for linear memory.
But that commit switched the order, leading to page tables being
already allocated at the time 8xx kasan_init_shadow_8M() is called.
Due to this, kasan_init_shadow_8M() doesn't map the needed
shadow entries because there are already page tables.
kasan_init_shadow_8M() installs huge PMD entries instead of page
tables. We could at that time free the page tables, but there is no
point in creating page tables that get freed before being used.
Only book3s/32 hash needs early allocation of page tables. For other
variants, we can keep the initial order and create remaining page
tables after the allocation of final shadow memory for linear mem.
Move back the allocation of shadow page tables for
CONFIG_KASAN_VMALLOC into kasan_init() after the loop which creates
final shadow memory for linear mem.
Fixes: 41ea93cf7ba4 ("powerpc/kasan: Fix shadow pages allocation failure")
Signed-off-by: Christophe Leroy
---
arch/powerpc/mm/kasan/kasan_init_32.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/mm/kasan/kasan_init_32.c
b/arch/powerpc/mm/kasan/kasan_init_32.c
index fb294046e00e..929716ea21e9 100644
--- a/arch/powerpc/mm/kasan/kasan_init_32.c
+++ b/arch/powerpc/mm/kasan/kasan_init_32.c
@@ -127,8 +127,7 @@ void __init kasan_mmu_init(void)
{
int ret;
- if (early_mmu_has_feature(MMU_FTR_HPTE_TABLE) ||
- IS_ENABLED(CONFIG_KASAN_VMALLOC)) {
+ if (early_mmu_has_feature(MMU_FTR_HPTE_TABLE)) {
ret = kasan_init_shadow_page_tables(KASAN_SHADOW_START,
KASAN_SHADOW_END);
if (ret)
@@ -139,11 +138,11 @@ void __init kasan_mmu_init(void)
void __init kasan_init(void)
{
struct memblock_region *reg;
+ int ret;
for_each_memblock(memory, reg) {
phys_addr_t base = reg->base;
phys_addr_t top = min(base + reg->size, total_lowmem);
- int ret;
if (base >= top)
continue;
@@ -153,6 +152,13 @@ void __init kasan_init(void)
panic("kasan: kasan_init_region() failed");
}
+ if (IS_ENABLED(CONFIG_KASAN_VMALLOC)) {
+ ret = kasan_init_shadow_page_tables(KASAN_SHADOW_START,
KASAN_SHADOW_END);
+
+ if (ret)
+ panic("kasan: kasan_init_shadow_page_tables() failed");
+ }
+
kasan_remap_early_shadow_ro();
clear_page(kasan_early_shadow_page);
--
2.25.0
[PATCH net-next] net/packet: Fix a comment about hard_header_len and add a warning for it
This patch tries to clarify the difference between hard_header_len and
needed_headroom by fixing an outdated comment and adding a WARN_ON_ONCE
warning for hard_header_len.
The difference between hard_header_len and needed_headroom as understood
by this patch is based on the following reasons:
1.
In af_packet.c, the function packet_snd first reserves a headroom of
length (dev->hard_header_len + dev->needed_headroom).
Then if the socket is a SOCK_DGRAM socket, it calls dev_hard_header,
which calls dev->header_ops->create, to create the link layer header.
If the socket is a SOCK_RAW socket, it "un-reserves" a headroom of
length (dev->hard_header_len), and checks if the user has provided a
header sized between (dev->min_header_len) and (dev->hard_header_len)
(in dev_validate_header).
This shows the developers of af_packet.c expect hard_header_len to
be consistent with header_ops.
2.
In af_packet.c, the function packet_sendmsg_spkt has a FIXME comment.
That comment states that prepending an LL header internally in a driver
is considered a bug. I believe this bug can be fixed by setting
hard_header_len to 0, making the internal header completely invisible
to af_packet.c (and requesting the headroom in needed_headroom instead).
3.
There is a commit for a WiFi driver:
commit 9454f7a895b8 ("mwifiex: set needed_headroom, not hard_header_len")
According to the discussion about it at:
https://patchwork.kernel.org/patch/11407493/
The author tried to set the WiFi driver's hard_header_len to the Ethernet
header length, and request additional header space internally needed by
setting needed_headroom.
This means this usage is already adopted by driver developers.
Cc: Willem de Bruijn
Cc: Eric Dumazet
Cc: Brian Norris
Cc: Cong Wang
Signed-off-by: Xie He
---
net/packet/af_packet.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index af6c93ed9fa0..93c89d3b2511 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -93,12 +93,15 @@
/*
Assumptions:
- - if device has no dev->hard_header routine, it adds and removes ll header
- inside itself. In this case ll header is invisible outside of device,
- but higher levels still should reserve dev->hard_header_len.
- Some devices are enough clever to reallocate skb, when header
- will not fit to reserved space (tunnel), another ones are silly
- (PPP).
+ - If the device has no dev->header_ops, there is no LL header visible
+ above the device. In this case, its hard_header_len should be 0.
+ The device may prepend its own header internally. In this case, its
+ needed_headroom should be set to the space needed for it to add its
+ internal header.
+ For example, a WiFi driver pretending to be an Ethernet driver should
+ set its hard_header_len to be the Ethernet header length, and set its
+ needed_headroom to be (the real WiFi header length - the fake Ethernet
+ header length).
- packet socket receives packets with pulled ll header,
so that SOCK_RAW should push it back.
@@ -2936,6 +2939,8 @@ static int packet_snd(struct socket *sock, struct msghdr
*msg, size_t len)
skb_reset_network_header(skb);
err = -EINVAL;
+ if (!dev->header_ops)
+ WARN_ON_ONCE(dev->hard_header_len != 0);
if (sock->type == SOCK_DGRAM) {
offset = dev_hard_header(skb, dev, ntohs(proto), addr, NULL,
len);
if (unlikely(offset < 0))
--
2.25.1
RE: [PATCH RESEND v3 04/11] usb: xhci-rcar: convert to readl_poll_timeout_atomic()
Hi Chunfeng,
> From: Chunfeng Yun, Sent: Friday, September 11, 2020 1:13 PM
>
> On Fri, 2020-09-11 at 03:13 +, Yoshihiro Shimoda wrote:
> > Hi Daniel, Chunfeng,
> >
> > > From: Chunfeng Yun, Sent: Friday, September 11, 2020 11:33 AM
> > >
> > > On Thu, 2020-09-10 at 14:12 +0100, Daniel Thompson wrote:
> > > > On Thu, Sep 10, 2020 at 04:21:45PM +0800, Chunfeng Yun wrote:
> > > > > Use readl_poll_timeout_atomic() to simplify code
> > > > >
> > > > > Cc: Mathias Nyman
> > > > > Cc: Yoshihiro Shimoda
> > > > > Signed-off-by: Chunfeng Yun
> > > > > ---
> > > > > v2~v3: no changes
> > > > > ---
> > > > > drivers/usb/host/xhci-rcar.c | 43
> > > > > ---
> > > > > 1 file changed, 12 insertions(+), 31 deletions(-)
> > > > >
> > > > > diff --git a/drivers/usb/host/xhci-rcar.c
> > > > > b/drivers/usb/host/xhci-rcar.c
> > > > > index c1025d3..74f836f 100644
> > > > > --- a/drivers/usb/host/xhci-rcar.c
> > > > > +++ b/drivers/usb/host/xhci-rcar.c
> > > > > @@ -6,6 +6,7 @@
> > > > > */
> > > > >
> > > > > #include
> > > > > +#include
> > > > > #include
> > > > > #include
> > > > > #include
> > > > > @@ -127,8 +128,7 @@ static int xhci_rcar_download_firmware(struct
> > > > > usb_hcd *hcd)
> > > > > void __iomem *regs = hcd->regs;
> > > > > struct xhci_plat_priv *priv = hcd_to_xhci_priv(hcd);
> > > > > const struct firmware *fw;
> > > > > - int retval, index, j, time;
> > > > > - int timeout = 1;
> > > > > + int retval, index, j;
> > > > > u32 data, val, temp;
> > > > > u32 quirks = 0;
> > > > > const struct soc_device_attribute *attr;
> > > > > @@ -166,32 +166,19 @@ static int xhci_rcar_download_firmware(struct
> > > > > usb_hcd *hcd)
> > > > > temp |= RCAR_USB3_DL_CTRL_FW_SET_DATA0;
> > > > > writel(temp, regs + RCAR_USB3_DL_CTRL);
> > > > >
> > > > > - for (time = 0; time < timeout; time++) {
> > > > > - val = readl(regs + RCAR_USB3_DL_CTRL);
> > > > > - if ((val & RCAR_USB3_DL_CTRL_FW_SET_DATA0) == 0)
> > > > > - break;
> > > > > - udelay(1);
> > > > > - }
> > > > > - if (time == timeout) {
> > > > > - retval = -ETIMEDOUT;
> > > > > + retval = readl_poll_timeout_atomic(regs +
> > > > > RCAR_USB3_DL_CTRL,
> > > > > + val, !(val &
> > > > > RCAR_USB3_DL_CTRL_FW_SET_DATA0),
> > > > > + 1, 1);
> > > > > + if (retval < 0)
> How about free firmware and return error number here ? instead of break
I think clearing CTRL_ENABLE code below is needed.
And, I think this patch should not change a lot of things...
> > > > > break;
> > > > > - }
> > > > > }
> > > > >
> > > > > temp = readl(regs + RCAR_USB3_DL_CTRL);
> > > > > temp &= ~RCAR_USB3_DL_CTRL_ENABLE;
> > > > > writel(temp, regs + RCAR_USB3_DL_CTRL);
> > > > >
> > > > > - for (time = 0; time < timeout; time++) {
> > > > > - val = readl(regs + RCAR_USB3_DL_CTRL);
> > > > > - if (val & RCAR_USB3_DL_CTRL_FW_SUCCESS) {
> > > > > - retval = 0;
> > > > > - break;
> > > > > - }
> > > > > - udelay(1);
> > > > > - }
> > > > > - if (time == timeout)
> > > > > - retval = -ETIMEDOUT;
> > > > > + retval = readl_poll_timeout_atomic((regs + RCAR_USB3_DL_CTRL),
> > > > > + val, (val & RCAR_USB3_DL_CTRL_FW_SUCCESS), 1,
> > > > > 1);
> > > >
> > > > Directly assigning to retval at this point will clobber a previous
> > > > -ETIMEDOUT error.
> > > >
> > > > In other words if there is a timeout waiting for FW_SET_DATA0, but not
> > > > for
> > > > DW_SUCCESS, then we will return the wrong return value.
> >
> > Thank you for your comment! I didn't realized this.
> >
> > > Yes, agree with you, but seems I keep its original logic unchanged.
> > > Hi Yoshihiro,
> > >
> > > What do think about Daniel's suggestion? should I fix it up?
> >
> > I think you should fix it up like below:
> >
> > if (readl_poll_timeout_atomic(regs + RCAR_USB3_DL_CTRL,
> > val, val & RCAR_USB3_DL_CTRL_FW_SUCCESS, 1, 1) < 0)
> > retval = -ETIMEOUT; /* Overwrite retval if timeout occurred */
>
> readl_poll_timeout_atomic() only return -ETIMEOUT error number, so this
> likes what I did, doesn't fix it.
readl_poll_timeout_atomic() returns 0 if timeout doesn't happen.
So, when my suggestion code runs, the retval is not overwritten if
the readl_poll_timeout_atomic(regs + RCAR_USB3_DL_CTRL...) returns 0.
Best regards,
Yoshihiro Shimoda
Re: [PATCH 0/4] Remove LPC register partitioning
On Fri, 11 Sep 2020, at 13:33, Joel Stanley wrote: > Hello, > > On Fri, 11 Sep 2020 at 03:46, Chia-Wei, Wang > wrote: > > > > The LPC controller has no concept of the BMC and the Host partitions. > > The incorrect partitioning can impose unnecessary range restrictions > > on register access through the syscon regmap interface. > > > > For instance, HICRB contains the I/O port address configuration > > of KCS channel 1/2. However, the KCS#1/#2 drivers cannot access > > HICRB as it is located at the other LPC partition. Thanks for addressing this, I've regretted that choice for a while now. The split was rooted in trying to support pinmux while not being across every detail of the LPC controller, and so I made some poor decisions. > > > > In addition, to be backward compatible, the newly added HW control > > bits could be added at any reserved bits over the LPC addressing space. > > > > Thereby, this patch series aims to remove the LPC partitioning for > > better driver development and maintenance. > > I support this cleanup. The only consideration is to be careful with > breaking the driver/device-tree relationship. We either need to ensure > the drivers remain compatible with both device trees. > > Another solution is to get agreement from all parties that for the LPC > device the device tree is always the one shipped with the kernel, so > it is okay to make incompatible changes. > > While we are doing a cleanup, Andrew suggested we remove the detailed > description of LPC out of the device tree. We would have the one LPC > node, and create a LPC driver that creates all of the sub devices > (snoop, FW cycles, kcs, bt, vuart). Andrew, can you elaborate on this > plan? I dug up the conversation I had with Rob over a year ago about being unhappy with what I'd cooked up. https://lore.kernel.org/linux-arm-kernel/cal_jsqj+sfdg8ekbv3gvmqvhx+otwbki4dy213apzxgfhbx...@mail.gmail.com/ But I think you covered most of the idea there: We have the LPC driver create the subdevices and that moves the details out of the devicetree. However, I haven't thought about it more than that, and I think there are still problems with that idea. For instance, how we manage configuration of those devices, and how to enable only the devices a given platform actually cares about (i.e. the problems that devicetree solves for us). It may be that the only way to do that is with platform code, and that's not really a direction we should be going either. Andrew
Re: [PATCH -next] media: marvell-ccic: Fix -Wunused-function warnings
On 2020/9/10 22:57, Lubomir Rintel wrote:
> On Thu, Sep 10, 2020 at 05:18:15PM +0800, Yuehaibing wrote:
>> On 2020/9/10 16:22, Lubomir Rintel wrote:
>>> On Thu, Sep 10, 2020 at 04:09:33PM +0800, YueHaibing wrote:
If CONFIG_PM is n, gcc warns:
drivers/media/platform/marvell-ccic/mmp-driver.c:347:12: warning:
‘mmpcam_resume’ defined but not used [-Wunused-function]
static int mmpcam_resume(struct device *dev)
^
drivers/media/platform/marvell-ccic/mmp-driver.c:338:12: warning:
‘mmpcam_suspend’ defined but not used [-Wunused-function]
static int mmpcam_suspend(struct device *dev)
^~
drivers/media/platform/marvell-ccic/mmp-driver.c:324:12: warning:
‘mmpcam_runtime_suspend’ defined but not used [-Wunused-function]
static int mmpcam_runtime_suspend(struct device *dev)
^~
drivers/media/platform/marvell-ccic/mmp-driver.c:310:12: warning:
‘mmpcam_runtime_resume’ defined but not used [-Wunused-function]
static int mmpcam_runtime_resume(struct device *dev)
^
Mark them as __maybe_unused to fix this.
Reported-by: Hulk Robot
Signed-off-by: YueHaibing
>>>
>>> Your colleague seems to sent out an equivalent patch:
>>> https://lore.kernel.org/lkml/20200910080933.40684-1-yuehaib...@huawei.com/
>>
>> This is my patch, paste an wrong link?
>
> Indeed, sorry for the confusion.
>
> The original mail only went to linux-media, not lkml, which is why I
> picked the wrong one from the archive. Here's the patch:
>
> https://lore.kernel.org/linux-media/20200909112921.5116-1-weiyongj...@huawei.com/
mmpcam_runtime_suspend/mmpcam_runtime_resume also should be cared, I'll adjust
my patch based on it.
>
> Take care
> Lubo
>
>>
>>>
>>> Cheers
>>> Lubo
>>>
---
drivers/media/platform/marvell-ccic/mmp-driver.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/media/platform/marvell-ccic/mmp-driver.c
b/drivers/media/platform/marvell-ccic/mmp-driver.c
index c4b28a00a3a2..032fdddbbecc 100644
--- a/drivers/media/platform/marvell-ccic/mmp-driver.c
+++ b/drivers/media/platform/marvell-ccic/mmp-driver.c
@@ -307,7 +307,7 @@ static int mmpcam_platform_remove(struct
platform_device *pdev)
* Suspend/resume support.
*/
-static int mmpcam_runtime_resume(struct device *dev)
+static int __maybe_unused mmpcam_runtime_resume(struct device *dev)
{
struct mmp_camera *cam = dev_get_drvdata(dev);
struct mcam_camera *mcam = >mcam;
@@ -321,7 +321,7 @@ static int mmpcam_runtime_resume(struct device *dev)
return 0;
}
-static int mmpcam_runtime_suspend(struct device *dev)
+static int __maybe_unused mmpcam_runtime_suspend(struct device *dev)
{
struct mmp_camera *cam = dev_get_drvdata(dev);
struct mcam_camera *mcam = >mcam;
@@ -335,7 +335,7 @@ static int mmpcam_runtime_suspend(struct device *dev)
return 0;
}
-static int mmpcam_suspend(struct device *dev)
+static int __maybe_unused mmpcam_suspend(struct device *dev)
{
struct mmp_camera *cam = dev_get_drvdata(dev);
@@ -344,7 +344,7 @@ static int mmpcam_suspend(struct device *dev)
return 0;
}
-static int mmpcam_resume(struct device *dev)
+static int __maybe_unused mmpcam_resume(struct device *dev)
{
struct mmp_camera *cam = dev_get_drvdata(dev);
--
2.17.1
>>>
>>> .
>>>
>>
>
> .
>
Re: linux-next: manual merge of the scsi-mkp tree with Linus' tree
Hi all,
On Wed, 2 Sep 2020 15:12:35 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the scsi-mkp tree got a conflict in:
>
> drivers/scsi/aacraid/aachba.c
>
> between commit:
>
> df561f6688fe ("treewide: Use fallthrough pseudo-keyword")
>
> from Linus' tree and commit:
>
> cfd3d2225aa5 ("scsi: aacraid: Remove erroneous fallthrough annotation")
>
> from the scsi-mkp tree.
>
> I fixed it up (I removed the line removed by the latter - it was rewritten
> by the former to "fallthrough;") and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
This is now a conflict between the scsi tree and Linus' tree.
--
Cheers,
Stephen Rothwell
pgpj2lDjokB5_.pgp
Description: OpenPGP digital signature
[PATCH 2/3] exfat: remove useless check in exfat_move_file()
In exfat_move_file(), the identity of source and target directory has been checked by the caller. Also, it gets stream.start_clu from file dir-entry, which is an invalid determination. Signed-off-by: Tetsuhiro Kohada --- fs/exfat/namei.c | 5 - 1 file changed, 5 deletions(-) diff --git a/fs/exfat/namei.c b/fs/exfat/namei.c index 803748946ddb..1c433491f771 100644 --- a/fs/exfat/namei.c +++ b/fs/exfat/namei.c @@ -1095,11 +1095,6 @@ static int exfat_move_file(struct inode *inode, struct exfat_chain *p_olddir, if (!epmov) return -EIO; - /* check if the source and target directory is the same */ - if (exfat_get_entry_type(epmov) == TYPE_DIR && - le32_to_cpu(epmov->dentry.stream.start_clu) == p_newdir->dir) - return -EINVAL; - num_old_entries = exfat_count_ext_entries(sb, p_olddir, oldentry, epmov); if (num_old_entries < 0) -- 2.25.1
[PATCH 3/3] exfat: replace memcpy with structure assignment
Use structure assignment instead of memcpy.
Signed-off-by: Tetsuhiro Kohada
---
fs/exfat/dir.c | 7 ++-
fs/exfat/inode.c | 2 +-
fs/exfat/namei.c | 15 +++
3 files changed, 10 insertions(+), 14 deletions(-)
diff --git a/fs/exfat/dir.c b/fs/exfat/dir.c
index fa5bb72aa295..8520decd120c 100644
--- a/fs/exfat/dir.c
+++ b/fs/exfat/dir.c
@@ -974,11 +974,8 @@ int exfat_find_dir_entry(struct super_block *sb, struct
exfat_inode_info *ei,
if (ei->hint_femp.eidx ==
EXFAT_HINT_NONE ||
candi_empty.eidx <=
-ei->hint_femp.eidx) {
- memcpy(>hint_femp,
- _empty,
- sizeof(candi_empty));
- }
+ei->hint_femp.eidx)
+ ei->hint_femp = candi_empty;
}
brelse(bh);
diff --git a/fs/exfat/inode.c b/fs/exfat/inode.c
index 70a33d4807c3..687f77653187 100644
--- a/fs/exfat/inode.c
+++ b/fs/exfat/inode.c
@@ -554,7 +554,7 @@ static int exfat_fill_inode(struct inode *inode, struct
exfat_dir_entry *info)
struct exfat_inode_info *ei = EXFAT_I(inode);
loff_t size = info->size;
- memcpy(>dir, >dir, sizeof(struct exfat_chain));
+ ei->dir = info->dir;
ei->entry = info->entry;
ei->attr = info->attr;
ei->start_clu = info->start_clu;
diff --git a/fs/exfat/namei.c b/fs/exfat/namei.c
index 1c433491f771..2932b23a3b6c 100644
--- a/fs/exfat/namei.c
+++ b/fs/exfat/namei.c
@@ -318,8 +318,7 @@ static int exfat_find_empty_entry(struct inode *inode,
hint_femp.eidx = EXFAT_HINT_NONE;
if (ei->hint_femp.eidx != EXFAT_HINT_NONE) {
- memcpy(_femp, >hint_femp,
- sizeof(struct exfat_hint_femp));
+ hint_femp = ei->hint_femp;
ei->hint_femp.eidx = EXFAT_HINT_NONE;
}
@@ -519,7 +518,7 @@ static int exfat_add_entry(struct inode *inode, const char
*path,
if (ret)
goto out;
- memcpy(>dir, p_dir, sizeof(struct exfat_chain));
+ info->dir = *p_dir;
info->entry = dentry;
info->flags = ALLOC_NO_FAT_CHAIN;
info->type = type;
@@ -625,7 +624,7 @@ static int exfat_find(struct inode *dir, struct qstr *qname,
if (dentry < 0)
return dentry; /* -error value */
- memcpy(>dir, , sizeof(struct exfat_chain));
+ info->dir = cdir;
info->entry = dentry;
info->num_subdirs = 0;
@@ -1030,7 +1029,7 @@ static int exfat_rename_file(struct inode *inode, struct
exfat_chain *p_dir,
if (!epnew)
return -EIO;
- memcpy(epnew, epold, DENTRY_SIZE);
+ *epnew = *epold;
if (exfat_get_entry_type(epnew) == TYPE_FILE) {
epnew->dentry.file.attr |= cpu_to_le16(ATTR_ARCHIVE);
ei->attr |= ATTR_ARCHIVE;
@@ -1050,7 +1049,7 @@ static int exfat_rename_file(struct inode *inode, struct
exfat_chain *p_dir,
return -EIO;
}
- memcpy(epnew, epold, DENTRY_SIZE);
+ *epnew = *epold;
exfat_update_bh(new_bh, sync);
brelse(old_bh);
brelse(new_bh);
@@ -1113,7 +1112,7 @@ static int exfat_move_file(struct inode *inode, struct
exfat_chain *p_olddir,
if (!epnew)
return -EIO;
- memcpy(epnew, epmov, DENTRY_SIZE);
+ *epnew = *epmov;
if (exfat_get_entry_type(epnew) == TYPE_FILE) {
epnew->dentry.file.attr |= cpu_to_le16(ATTR_ARCHIVE);
ei->attr |= ATTR_ARCHIVE;
@@ -1133,7 +1132,7 @@ static int exfat_move_file(struct inode *inode, struct
exfat_chain *p_olddir,
return -EIO;
}
- memcpy(epnew, epmov, DENTRY_SIZE);
+ *epnew = *epmov;
exfat_update_bh(new_bh, IS_DIRSYNC(inode));
brelse(mov_bh);
brelse(new_bh);
--
2.25.1
[PATCH 1/3] exfat: remove useless directory scan in exfat_add_entry()
There is nothing in directory just created, so there is no need to scan.
Signed-off-by: Tetsuhiro Kohada
---
fs/exfat/namei.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/fs/exfat/namei.c b/fs/exfat/namei.c
index b966b9120c9c..803748946ddb 100644
--- a/fs/exfat/namei.c
+++ b/fs/exfat/namei.c
@@ -530,19 +530,10 @@ static int exfat_add_entry(struct inode *inode, const
char *path,
info->size = 0;
info->num_subdirs = 0;
} else {
- int count;
- struct exfat_chain cdir;
-
info->attr = ATTR_SUBDIR;
info->start_clu = start_clu;
info->size = clu_size;
-
- exfat_chain_set(, info->start_clu,
- EXFAT_B_TO_CLU(info->size, sbi), info->flags);
- count = exfat_count_dir_entries(sb, );
- if (count < 0)
- return -EIO;
- info->num_subdirs = count + EXFAT_MIN_SUBDIR;
+ info->num_subdirs = EXFAT_MIN_SUBDIR;
}
memset(>crtime, 0, sizeof(info->crtime));
memset(>mtime, 0, sizeof(info->mtime));
--
2.25.1
Re: [PATCH v3 3/3] hwrng: xiphera-trng: add support for XIP8001B hwrng
On Wed, Sep 02, 2020 at 01:28:17PM +0300, Atte Tommiska wrote: > Xiphera XIP8001B is an FPGA-based True Random Number Generator > Intellectual Property (IP) Core which can be instantiated in > multiple FPGA families. This driver adds Linux support for it through > the hwrng interface. > > Signed-off-by: Atte Tommiska > Reported-by: kernel test robot This Reported-by appears to be superfluous and I'll remove it when applying. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH RFC tip/core/rcu 4/4] rcu-tasks: Shorten per-grace-period sleep for RCU Tasks Trace
On Thu, Sep 10, 2020 at 08:18:01PM -0700, Alexei Starovoitov wrote: > On Thu, Sep 10, 2020 at 1:20 PM wrote: > > > > From: "Paul E. McKenney" > > > > The various RCU tasks flavors currently wait 100 milliseconds between each > > grace period in order to prevent CPU-bound loops and to favor efficiency > > over latency. However, RCU Tasks Trace needs to have a grace-period > > latency of roughly 25 milliseconds, which is completely infeasible given > > the 100-millisecond per-grace-period sleep. This commit therefore reduces > > this sleep duration to 5 milliseconds (or one jiffy, whichever is longer) > > in kernels built with CONFIG_TASKS_TRACE_RCU_READ_MB=y. > > The commit log is either misleading or wrong? > If I read the code correctly in CONFIG_TASKS_TRACE_RCU_READ_MB=y > case the existing HZ/10 "paranoid sleep" is preserved. Yes, for CONFIG_TASKS_TRACE_RCU_READ_MB=y, the previous 100-millisecond "paranoid sleep" is preserved. Preserving previous behavior is of course especially important for rcupdate.rcu_task_ipi_delay, given that real-time applications are degraded by IPIs. And given that we are avoiding IPIs in this case, speeding up the polling is not all that helpful. > It's for the MB=n case it is reduced to HZ/200. Yes, that is, to roughly 5 milliseconds for large HZ or to one jiffy for HZ<200. Here, we send IPIs much more aggressively, so polling more frequently does help a lot. > Also I don't understand why you're talking about milliseconds but > all numbers are HZ based. HZ/10 gives different number of > milliseconds depending on HZ. As long as HZ is 10 or greater, HZ/10 jiffies is roughly 100 milliseconds. In the unlikely event that HZ is less than 10, the code clamps to one jiffy. Since schedule_timeout_idle() sleep time is specified in jiffies, it all works out. Thanx, Paul
Re: [PATCH] crypto: stm32/crc32 - Avoid lock if hardware is already used
On Fri, Sep 04, 2020 at 01:25:27PM +0200, Nicolas Toromanoff wrote:
> If STM32 CRC device is already in use, calculate CRC by software.
>
> This will release CPU constraint for a concurrent access to the
> hardware, and avoid masking irqs during the whole block processing.
>
> Fixes: 7795c0baf5ac ("crypto: stm32/crc32 - protect from concurrent accesses")
>
> Signed-off-by: Nicolas Toromanoff
> ---
> drivers/crypto/stm32/Kconfig | 2 ++
> drivers/crypto/stm32/stm32-crc32.c | 15 ---
> 2 files changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/crypto/stm32/Kconfig b/drivers/crypto/stm32/Kconfig
> index 4ef3eb11361c..8d605b07571f 100644
> --- a/drivers/crypto/stm32/Kconfig
> +++ b/drivers/crypto/stm32/Kconfig
> @@ -3,6 +3,8 @@ config CRYPTO_DEV_STM32_CRC
> tristate "Support for STM32 crc accelerators"
> depends on ARCH_STM32
> select CRYPTO_HASH
> + select CRYPTO_CRC32
> + select CRYPTO_CRC32C
Shouldn't this be "select CRC32"?
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v6 0/8] crpyto: introduce OSCCA certificate and SM2 asymmetric algorithm
On Thu, Sep 03, 2020 at 09:12:34PM +0800, Tianjia Zhang wrote: > > --- > v6 changes: > 1. remove mpi_sub_ui function from mpi library. > 2. rebase on mainline. This series is still missing acks for patches 6-8. Without them it cannot proceed. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
[PATCH v3] Documentation: kunit: Add naming guidelines
As discussed in [1], KUnit tests have hitherto not had a particularly consistent naming scheme. This adds documentation outlining how tests and test suites should be named, including how those names should be used in Kconfig entries and filenames. [1]: https://lore.kernel.org/linux-kselftest/202006141005.BA19A9D3@keescook/t/#u Signed-off-by: David Gow Reviewed-by: Kees Cook Reviewed-by: Brendan Higgins Reviewed-by: Marco Elver Reviewed-by: Tim Bird --- This is v3 of the KUnit test naming guidelines. It's basically just v2 with some spelling fixes (thanks Marco). Changelog: v3: - Fix a few typos. - Add Marco and Tim's Reviewed-bys. v2: https://lore.kernel.org/linux-kselftest/20200909051631.2960347-1-david...@google.com/ - Rewrote the filename section to use "_test" as a suffix, and focus on module names, not filenames. - Add a motivating introduction, which also calls out existing tests and tests which cause problems when run automatically (long running, flaky tests) as reasons to avoid the guidelines. - Talk about including the type of test in the suite name, but only if theres an actual confict. (And update the example for this). v1: https://lore.kernel.org/linux-kselftest/20200702071416.1780522-1-david...@google.com/ - Fixed a bit of space/tab confusion in the index (Thanks, Randy) - Added some more examples (and some test case examples). - Added some examples of what not to call subsystems and suites. - No longer explicitly require "If unsure, put N" in Kconfig entries. - Minor formatting changes RFC: https://lore.kernel.org/linux-kselftest/20200620054944.167330-1-david...@google.com/T/#u - Initial version Documentation/dev-tools/kunit/index.rst | 1 + Documentation/dev-tools/kunit/style.rst | 207 2 files changed, 208 insertions(+) create mode 100644 Documentation/dev-tools/kunit/style.rst diff --git a/Documentation/dev-tools/kunit/index.rst b/Documentation/dev-tools/kunit/index.rst index e93606ecfb01..c234a3ab3c34 100644 --- a/Documentation/dev-tools/kunit/index.rst +++ b/Documentation/dev-tools/kunit/index.rst @@ -11,6 +11,7 @@ KUnit - Unit Testing for the Linux Kernel usage kunit-tool api/index + style faq What is KUnit? diff --git a/Documentation/dev-tools/kunit/style.rst b/Documentation/dev-tools/kunit/style.rst new file mode 100644 index ..2352b7292eb5 --- /dev/null +++ b/Documentation/dev-tools/kunit/style.rst @@ -0,0 +1,207 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=== +Test Style and Nomenclature +=== + +To make finding, writing, and using KUnit tests as simple as possible, it's +strongly encouraged that they are named and written according to the guidelines +below. While it's possible to write KUnit tests which do not follow these rules, +they may break some tooling, may conflict with other tests, and may not be run +automatically by testing systems. + +It's recommended that you only deviate from these guidelines when: + +1. Porting tests to KUnit which are already known with an existing name, or +2. Writing tests which would cause serious problems if automatically run (e.g., + non-deterministically producing false positives or negatives, or taking an + extremely long time to run). + +Subsystems, Suites, and Tests += + +In order to make tests as easy to find as possible, they're grouped into suites +and subsystems. A test suite is a group of tests which test a related area of +the kernel, and a subsystem is a set of test suites which test different parts +of the same kernel subsystem or driver. + +Subsystems +-- + +Every test suite must belong to a subsystem. A subsystem is a collection of one +or more KUnit test suites which test the same driver or part of the kernel. A +rule of thumb is that a test subsystem should match a single kernel module. If +the code being tested can't be compiled as a module, in many cases the subsystem +should correspond to a directory in the source tree or an entry in the +MAINTAINERS file. If unsure, follow the conventions set by tests in similar +areas. + +Test subsystems should be named after the code being tested, either after the +module (wherever possible), or after the directory or files being tested. Test +subsystems should be named to avoid ambiguity where necessary. + +If a test subsystem name has multiple components, they should be separated by +underscores. *Do not* include "test" or "kunit" directly in the subsystem name +unless you are actually testing other tests or the kunit framework itself. + +Example subsystems could be: + +``ext4`` + Matches the module and filesystem name. +``apparmor`` + Matches the module name and LSM name. +``kasan`` + Common name for the tool, prominent part of the path ``mm/kasan`` +``snd_hda_codec_hdmi`` + Has several components (``snd``, ``hda``, ``codec``, ``hdmi``) separated by + underscores. Matches the module name. +
[PATCH net-next] net: dsa: b53: Configure VLANs while not filtering
Update the B53 driver to support VLANs while not filtering. This
requires us to enable VLAN globally within the switch upon driver
initial configuration (dev->vlan_enabled).
We also need to remove the code that dealt with PVID re-configuration in
b53_vlan_filtering() since that function worked under the assumption
that it would only be called to make a bridge VLAN filtering, or not
filtering, and we would attempt to move the port's PVID accordingly.
Now that VLANs are programmed all the time, even in the case of a
non-VLAN filtering bridge, we would be programming a default_pvid for
the bridged switch ports.
Signed-off-by: Florian Fainelli
---
drivers/net/dsa/b53/b53_common.c | 23 ---
1 file changed, 4 insertions(+), 19 deletions(-)
diff --git a/drivers/net/dsa/b53/b53_common.c b/drivers/net/dsa/b53/b53_common.c
index 6a5796c32721..46ac8875f870 100644
--- a/drivers/net/dsa/b53/b53_common.c
+++ b/drivers/net/dsa/b53/b53_common.c
@@ -1377,23 +1377,6 @@ EXPORT_SYMBOL(b53_phylink_mac_link_up);
int b53_vlan_filtering(struct dsa_switch *ds, int port, bool vlan_filtering)
{
struct b53_device *dev = ds->priv;
- u16 pvid, new_pvid;
-
- b53_read16(dev, B53_VLAN_PAGE, B53_VLAN_PORT_DEF_TAG(port), );
- if (!vlan_filtering) {
- /* Filtering is currently enabled, use the default PVID since
-* the bridge does not expect tagging anymore
-*/
- dev->ports[port].pvid = pvid;
- new_pvid = b53_default_pvid(dev);
- } else {
- /* Filtering is currently disabled, restore the previous PVID */
- new_pvid = dev->ports[port].pvid;
- }
-
- if (pvid != new_pvid)
- b53_write16(dev, B53_VLAN_PAGE, B53_VLAN_PORT_DEF_TAG(port),
- new_pvid);
b53_enable_vlan(dev, dev->vlan_enabled, vlan_filtering);
@@ -1444,7 +1427,7 @@ void b53_vlan_add(struct dsa_switch *ds, int port,
untagged = true;
vl->members |= BIT(port);
- if (untagged && !dsa_is_cpu_port(ds, port))
+ if (untagged)
vl->untag |= BIT(port);
else
vl->untag &= ~BIT(port);
@@ -1482,7 +1465,7 @@ int b53_vlan_del(struct dsa_switch *ds, int port,
if (pvid == vid)
pvid = b53_default_pvid(dev);
- if (untagged && !dsa_is_cpu_port(ds, port))
+ if (untagged)
vl->untag &= ~(BIT(port));
b53_set_vlan_entry(dev, vid, vl);
@@ -2619,6 +2602,8 @@ struct b53_device *b53_switch_alloc(struct device *base,
dev->priv = priv;
dev->ops = ops;
ds->ops = _switch_ops;
+ ds->configure_vlan_while_not_filtering = true;
+ dev->vlan_enabled = ds->configure_vlan_while_not_filtering;
mutex_init(>reg_mutex);
mutex_init(>stats_mutex);
--
2.25.1
Re: [trivial PATCH] treewide: Convert switch/case fallthrough; to break;
On Thu, 2020-09-10 at 15:21 +0100, Robin Murphy wrote:
> On 2020-09-09 21:06, Joe Perches wrote:
> > fallthrough to a separate case/default label break; isn't very readable.
> >
> > Convert pseudo-keyword fallthrough; statements to a simple break; when
> > the next label is case or default and the only statement in the next
> > label block is break;
> >
> > Found using:
> >
> > $ grep-2.5.4 -rP --include=*.[ch] -n
> > "fallthrough;(\s*(case\s+\w+|default)\s*:\s*){1,7}break;" *
> >
> > Miscellanea:
> >
> > o Move or coalesce a couple label blocks above a default: block.
> >
> > Signed-off-by: Joe Perches
> > ---
> >
> > Compiled allyesconfig x86-64 only.
> > A few files for other arches were not compiled.
> >
>
> [...]
> > diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> > b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> > index c192544e874b..743db1abec40 100644
> > --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> > +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> > @@ -3777,7 +3777,7 @@ static int arm_smmu_device_hw_probe(struct
> > arm_smmu_device *smmu)
> > switch (FIELD_GET(IDR0_TTF, reg)) {
> > case IDR0_TTF_AARCH32_64:
> > smmu->ias = 40;
> > - fallthrough;
> > + break;
> > case IDR0_TTF_AARCH64:
> > break;
> > default:
>
> I have to say I don't really agree with the readability argument for
> this one - a fallthrough is semantically correct here, since the first
> case is a superset of the second. It just happens that anything we would
> do for the common subset is implicitly assumed (there are other
> potential cases we simply haven't added support for at the moment), thus
> the second case is currently empty.
> This change actively obfuscates that distinction.
Then perhaps comments should be added to usefully
describe the mechanisms.
case IDR0_TTF_AARCH32_64:
smmu->ias = 40;
fallthrough;/* and still do the 64 bit processing */
case IDR0_TTF_AARCH64:
/* Nothing specific yet */
break;
> Robin.
[PATCH 2/4] soc: aspeed: Fix LPC register offsets
The LPC register offsets are fixed to adapt to the LPC DTS change,
where the LPC partitioning is removed.
Signed-off-by: Chia-Wei, Wang
---
drivers/soc/aspeed/aspeed-lpc-ctrl.c | 6 +++---
drivers/soc/aspeed/aspeed-lpc-snoop.c | 11 +--
2 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/drivers/soc/aspeed/aspeed-lpc-ctrl.c
b/drivers/soc/aspeed/aspeed-lpc-ctrl.c
index 01ed21e8bfee..36faa0618ada 100644
--- a/drivers/soc/aspeed/aspeed-lpc-ctrl.c
+++ b/drivers/soc/aspeed/aspeed-lpc-ctrl.c
@@ -17,12 +17,12 @@
#define DEVICE_NAME"aspeed-lpc-ctrl"
-#define HICR5 0x0
+#define HICR5 0x80
#define HICR5_ENL2HBIT(8)
#define HICR5_ENFWHBIT(10)
-#define HICR7 0x8
-#define HICR8 0xc
+#define HICR7 0x88
+#define HICR8 0x8c
struct aspeed_lpc_ctrl {
struct miscdevice miscdev;
diff --git a/drivers/soc/aspeed/aspeed-lpc-snoop.c
b/drivers/soc/aspeed/aspeed-lpc-snoop.c
index f3d8d53ab84d..7ce5c9fcc73c 100644
--- a/drivers/soc/aspeed/aspeed-lpc-snoop.c
+++ b/drivers/soc/aspeed/aspeed-lpc-snoop.c
@@ -28,26 +28,25 @@
#define NUM_SNOOP_CHANNELS 2
#define SNOOP_FIFO_SIZE 2048
-#define HICR5 0x0
+#define HICR5 0x80
#define HICR5_EN_SNP0W BIT(0)
#define HICR5_ENINT_SNP0W BIT(1)
#define HICR5_EN_SNP1W BIT(2)
#define HICR5_ENINT_SNP1W BIT(3)
-
-#define HICR6 0x4
+#define HICR6 0x84
#define HICR6_STR_SNP0WBIT(0)
#define HICR6_STR_SNP1WBIT(1)
-#define SNPWADR0x10
+#define SNPWADR0x90
#define SNPWADR_CH0_MASK GENMASK(15, 0)
#define SNPWADR_CH0_SHIFT 0
#define SNPWADR_CH1_MASK GENMASK(31, 16)
#define SNPWADR_CH1_SHIFT 16
-#define SNPWDR 0x14
+#define SNPWDR 0x94
#define SNPWDR_CH0_MASKGENMASK(7, 0)
#define SNPWDR_CH0_SHIFT 0
#define SNPWDR_CH1_MASKGENMASK(15, 8)
#define SNPWDR_CH1_SHIFT 8
-#define HICRB 0x80
+#define HICRB 0x100
#define HICRB_ENSNP0D BIT(14)
#define HICRB_ENSNP1D BIT(15)
--
2.17.1
[PATCH 0/4] Remove LPC register partitioning
The LPC controller has no concept of the BMC and the Host partitions. The incorrect partitioning can impose unnecessary range restrictions on register access through the syscon regmap interface. For instance, HICRB contains the I/O port address configuration of KCS channel 1/2. However, the KCS#1/#2 drivers cannot access HICRB as it is located at the other LPC partition. In addition, to be backward compatible, the newly added HW control bits could be added at any reserved bits over the LPC addressing space. Thereby, this patch series aims to remove the LPC partitioning for better driver development and maintenance. Chia-Wei, Wang (4): ARM: dts: Remove LPC BMC and Host partitions soc: aspeed: Fix LPC register offsets ipmi: kcs: aspeed: Fix LPC register offsets pinctrl: aspeed-g5: Fix LPC register offsets arch/arm/boot/dts/aspeed-g4.dtsi | 74 +-- arch/arm/boot/dts/aspeed-g5.dtsi | 135 + arch/arm/boot/dts/aspeed-g6.dtsi | 135 + drivers/char/ipmi/kcs_bmc_aspeed.c | 13 +- drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c | 2 +- drivers/soc/aspeed/aspeed-lpc-ctrl.c | 6 +- drivers/soc/aspeed/aspeed-lpc-snoop.c | 11 +- 7 files changed, 162 insertions(+), 214 deletions(-) -- 2.17.1
[PATCH 4/4] pinctrl: aspeed-g5: Fix LPC register offsets
The LPC register offsets are fixed to adapt to the LPC DTS change,
where the LPC partitioning is removed.
Signed-off-by: Chia-Wei, Wang
---
drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c
b/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c
index 0cab4c2576e2..98e62333fa54 100644
--- a/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c
+++ b/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c
@@ -60,7 +60,7 @@
#define COND2 { ASPEED_IP_SCU, SCU94, GENMASK(1, 0), 0, 0 }
/* LHCR0 is offset from the end of the H8S/2168-compatible registers */
-#define LHCR0 0x20
+#define LHCR0 0xa0
#define GFX064 0x64
#define B14 0
--
2.17.1
[PATCH 3/4] ipmi: kcs: aspeed: Fix LPC register offsets
The LPC register offsets are fixed to adapt to the LPC DTS change,
where the LPC partitioning is removed.
Signed-off-by: Chia-Wei, Wang
---
drivers/char/ipmi/kcs_bmc_aspeed.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/char/ipmi/kcs_bmc_aspeed.c
b/drivers/char/ipmi/kcs_bmc_aspeed.c
index a140203c079b..8843cf867a5d 100644
--- a/drivers/char/ipmi/kcs_bmc_aspeed.c
+++ b/drivers/char/ipmi/kcs_bmc_aspeed.c
@@ -27,7 +27,6 @@
#define KCS_CHANNEL_MAX 4
-/* mapped to lpc-bmc@0 IO space */
#define LPC_HICR00x000
#define LPC_HICR0_LPC3E BIT(7)
#define LPC_HICR0_LPC2E BIT(6)
@@ -52,15 +51,13 @@
#define LPC_STR1 0x03C
#define LPC_STR2 0x040
#define LPC_STR3 0x044
-
-/* mapped to lpc-host@80 IO space */
-#define LPC_HICRB0x080
+#define LPC_HICRB0x100
#define LPC_HICRB_IBFIF4 BIT(1)
#define LPC_HICRB_LPC4E BIT(0)
-#define LPC_LADR40x090
-#define LPC_IDR4 0x094
-#define LPC_ODR4 0x098
-#define LPC_STR4 0x09C
+#define LPC_LADR40x110
+#define LPC_IDR4 0x114
+#define LPC_ODR4 0x118
+#define LPC_STR4 0x11C
struct aspeed_kcs_bmc {
struct regmap *map;
--
2.17.1
[PATCH 1/4] ARM: dts: Remove LPC BMC and Host partitions
The LPC controller has no concept of the BMC and the Host partitions.
A concrete instance is that the HICRB[5:4] are for the I/O port address
configurtaion of KCS channel 1/2. However, the KCS driver cannot access
HICRB for channel 1/2 initialization via syscon regmap interface due to
the parition boundary. (i.e. offset 80h)
In addition, to be backward compatible, the newly added HW control bits
could be located at any reserved bits over the LPC addressing space.
Thereby, this patch removes the lpc-bmc and lpc-host child node and thus
the LPC partitioning for better driver development and maintenance.
Signed-off-by: Chia-Wei, Wang
---
arch/arm/boot/dts/aspeed-g4.dtsi | 74 +++--
arch/arm/boot/dts/aspeed-g5.dtsi | 135 ++-
arch/arm/boot/dts/aspeed-g6.dtsi | 135 ++-
3 files changed, 148 insertions(+), 196 deletions(-)
diff --git a/arch/arm/boot/dts/aspeed-g4.dtsi b/arch/arm/boot/dts/aspeed-g4.dtsi
index 82f0213e3a3c..22996b3c4a00 100644
--- a/arch/arm/boot/dts/aspeed-g4.dtsi
+++ b/arch/arm/boot/dts/aspeed-g4.dtsi
@@ -338,58 +338,44 @@
};
lpc: lpc@1e789000 {
- compatible = "aspeed,ast2400-lpc", "simple-mfd";
+ compatible = "aspeed,ast2400-lpc",
"simple-mfd", "syscon";
reg = <0x1e789000 0x1000>;
+ reg-io-width = <4>;
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x1e789000 0x1000>;
- lpc_bmc: lpc-bmc@0 {
- compatible = "aspeed,ast2400-lpc-bmc";
- reg = <0x0 0x80>;
+ lpc_ctrl: lpc-ctrl@80 {
+ compatible = "aspeed,ast2400-lpc-ctrl";
+ reg = <0x80 0x10>;
+ clocks = < ASPEED_CLK_GATE_LCLK>;
+ status = "disabled";
};
- lpc_host: lpc-host@80 {
- compatible = "aspeed,ast2400-lpc-host",
"simple-mfd", "syscon";
- reg = <0x80 0x1e0>;
- reg-io-width = <4>;
-
- #address-cells = <1>;
- #size-cells = <1>;
- ranges = <0x0 0x80 0x1e0>;
-
- lpc_ctrl: lpc-ctrl@0 {
- compatible =
"aspeed,ast2400-lpc-ctrl";
- reg = <0x0 0x10>;
- clocks = <
ASPEED_CLK_GATE_LCLK>;
- status = "disabled";
- };
-
- lpc_snoop: lpc-snoop@10 {
- compatible =
"aspeed,ast2400-lpc-snoop";
- reg = <0x10 0x8>;
- interrupts = <8>;
- status = "disabled";
- };
-
- lhc: lhc@20 {
- compatible =
"aspeed,ast2400-lhc";
- reg = <0x20 0x24 0x48 0x8>;
- };
-
- lpc_reset: reset-controller@18 {
- compatible =
"aspeed,ast2400-lpc-reset";
- reg = <0x18 0x4>;
- #reset-cells = <1>;
- };
-
- ibt: ibt@c0 {
- compatible =
"aspeed,ast2400-ibt-bmc";
- reg = <0xc0 0x18>;
- interrupts = <8>;
- status = "disabled";
- };
+ lpc_snoop: lpc-snoop@90 {
+ compatible = "aspeed,ast2400-lpc-snoop";
+ reg = <0x90 0x8>;
+ interrupts = <8>;
+ status = "disabled";
+ };
+
+ lhc: lhc@a0 {
+ compatible = "aspeed,ast2400-lhc";
+
Re: [PATCH RESEND v3 04/11] usb: xhci-rcar: convert to readl_poll_timeout_atomic()
On Fri, 2020-09-11 at 03:13 +, Yoshihiro Shimoda wrote:
> Hi Daniel, Chunfeng,
>
> > From: Chunfeng Yun, Sent: Friday, September 11, 2020 11:33 AM
> >
> > On Thu, 2020-09-10 at 14:12 +0100, Daniel Thompson wrote:
> > > On Thu, Sep 10, 2020 at 04:21:45PM +0800, Chunfeng Yun wrote:
> > > > Use readl_poll_timeout_atomic() to simplify code
> > > >
> > > > Cc: Mathias Nyman
> > > > Cc: Yoshihiro Shimoda
> > > > Signed-off-by: Chunfeng Yun
> > > > ---
> > > > v2~v3: no changes
> > > > ---
> > > > drivers/usb/host/xhci-rcar.c | 43
> > > > ---
> > > > 1 file changed, 12 insertions(+), 31 deletions(-)
> > > >
> > > > diff --git a/drivers/usb/host/xhci-rcar.c b/drivers/usb/host/xhci-rcar.c
> > > > index c1025d3..74f836f 100644
> > > > --- a/drivers/usb/host/xhci-rcar.c
> > > > +++ b/drivers/usb/host/xhci-rcar.c
> > > > @@ -6,6 +6,7 @@
> > > > */
> > > >
> > > > #include
> > > > +#include
> > > > #include
> > > > #include
> > > > #include
> > > > @@ -127,8 +128,7 @@ static int xhci_rcar_download_firmware(struct
> > > > usb_hcd *hcd)
> > > > void __iomem *regs = hcd->regs;
> > > > struct xhci_plat_priv *priv = hcd_to_xhci_priv(hcd);
> > > > const struct firmware *fw;
> > > > - int retval, index, j, time;
> > > > - int timeout = 1;
> > > > + int retval, index, j;
> > > > u32 data, val, temp;
> > > > u32 quirks = 0;
> > > > const struct soc_device_attribute *attr;
> > > > @@ -166,32 +166,19 @@ static int xhci_rcar_download_firmware(struct
> > > > usb_hcd *hcd)
> > > > temp |= RCAR_USB3_DL_CTRL_FW_SET_DATA0;
> > > > writel(temp, regs + RCAR_USB3_DL_CTRL);
> > > >
> > > > - for (time = 0; time < timeout; time++) {
> > > > - val = readl(regs + RCAR_USB3_DL_CTRL);
> > > > - if ((val & RCAR_USB3_DL_CTRL_FW_SET_DATA0) == 0)
> > > > - break;
> > > > - udelay(1);
> > > > - }
> > > > - if (time == timeout) {
> > > > - retval = -ETIMEDOUT;
> > > > + retval = readl_poll_timeout_atomic(regs +
> > > > RCAR_USB3_DL_CTRL,
> > > > + val, !(val &
> > > > RCAR_USB3_DL_CTRL_FW_SET_DATA0),
> > > > + 1, 1);
> > > > + if (retval < 0)
How about free firmware and return error number here ? instead of break
> > > > break;
> > > > - }
> > > > }
> > > >
> > > > temp = readl(regs + RCAR_USB3_DL_CTRL);
> > > > temp &= ~RCAR_USB3_DL_CTRL_ENABLE;
> > > > writel(temp, regs + RCAR_USB3_DL_CTRL);
> > > >
> > > > - for (time = 0; time < timeout; time++) {
> > > > - val = readl(regs + RCAR_USB3_DL_CTRL);
> > > > - if (val & RCAR_USB3_DL_CTRL_FW_SUCCESS) {
> > > > - retval = 0;
> > > > - break;
> > > > - }
> > > > - udelay(1);
> > > > - }
> > > > - if (time == timeout)
> > > > - retval = -ETIMEDOUT;
> > > > + retval = readl_poll_timeout_atomic((regs + RCAR_USB3_DL_CTRL),
> > > > + val, (val & RCAR_USB3_DL_CTRL_FW_SUCCESS), 1,
> > > > 1);
> > >
> > > Directly assigning to retval at this point will clobber a previous
> > > -ETIMEDOUT error.
> > >
> > > In other words if there is a timeout waiting for FW_SET_DATA0, but not for
> > > DW_SUCCESS, then we will return the wrong return value.
>
> Thank you for your comment! I didn't realized this.
>
> > Yes, agree with you, but seems I keep its original logic unchanged.
> > Hi Yoshihiro,
> >
> > What do think about Daniel's suggestion? should I fix it up?
>
> I think you should fix it up like below:
>
> if (readl_poll_timeout_atomic(regs + RCAR_USB3_DL_CTRL,
> val, val & RCAR_USB3_DL_CTRL_FW_SUCCESS, 1, 1) < 0)
> retval = -ETIMEOUT; /* Overwrite retval if timeout occurred */
readl_poll_timeout_atomic() only return -ETIMEOUT error number, so this
likes what I did, doesn't fix it.
>
> Otherwise, the xhci_rcar_download_firmware() cannot return -ETIMEDOUT if
> timeout happened on the previous poll [1].
>
> [1]
> + retval = readl_poll_timeout_atomic(regs + RCAR_USB3_DL_CTRL,
> + val, !(val & RCAR_USB3_DL_CTRL_FW_SET_DATA0),
> + 1, 1);
>
> Best regards,
> Yoshihiro Shimoda
>
Re: [v2 PATCH] crypto: sun4i-ss - Fix sparse endianness markers
On Thu, Sep 10, 2020 at 02:22:48PM +0200, Corentin Labbe wrote: > > I get some md5 error on both A20+BE: > alg: ahash: md5 test failed (wrong result) on test vector \"random: psize=129 > ksize=0\", cfg=\"random: inplace use_finup nosimd > src_divs=[85.99%@+3999, 5.85%@+30, 0.96%@+25, > 5.9%@+2263, 2.11%@+1950] iv_offset=2 > key_offset=43\" > and A33+BE: > [ 84.469045] alg: ahash: md5 test failed (wrong result) on test vector > \"random: psize=322 ksize=0\", cfg=\"random: inplace may_sleep use_finup > src_divs=[99.1%@+2668, 0.88%@alignmask+3630, 0.11%@+3403] > iv_offset=33\" > +[ 84.469074] need:35966fc8 b31ea266 2bf064e9 f20f40ad > +[ 84.469084] have:e29e4491 f3b6effc fa366691 00e04bd9 > > Thoses errors are random. (1 boot out of 2) Do these really go away without this patch applied? AFAICS the generated code should be identical. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
[PATCH -next] nfsd: fix comparison to bool warning
Fixes coccicheck warning: fs/nfsd/nfs4proc.c:3234:5-29: WARNING: Comparison to bool Signed-off-by: Zheng Bin --- fs/nfsd/nfs4proc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/nfsd/nfs4proc.c b/fs/nfsd/nfs4proc.c index eaf50eafa935..63e5a4844d8c 100644 --- a/fs/nfsd/nfs4proc.c +++ b/fs/nfsd/nfs4proc.c @@ -3231,7 +3231,7 @@ bool nfsd4_spo_must_allow(struct svc_rqst *rqstp) if (!cstate->minorversion) return false; - if (cstate->spo_must_allowed == true) + if (cstate->spo_must_allowed) return true; opiter = resp->opcnt; -- 2.26.0.106.g9fadedd
Re: [PATCH 0/4] Remove LPC register partitioning
Hello, On Fri, 11 Sep 2020 at 03:46, Chia-Wei, Wang wrote: > > The LPC controller has no concept of the BMC and the Host partitions. > The incorrect partitioning can impose unnecessary range restrictions > on register access through the syscon regmap interface. > > For instance, HICRB contains the I/O port address configuration > of KCS channel 1/2. However, the KCS#1/#2 drivers cannot access > HICRB as it is located at the other LPC partition. > > In addition, to be backward compatible, the newly added HW control > bits could be added at any reserved bits over the LPC addressing space. > > Thereby, this patch series aims to remove the LPC partitioning for > better driver development and maintenance. I support this cleanup. The only consideration is to be careful with breaking the driver/device-tree relationship. We either need to ensure the drivers remain compatible with both device trees. Another solution is to get agreement from all parties that for the LPC device the device tree is always the one shipped with the kernel, so it is okay to make incompatible changes. While we are doing a cleanup, Andrew suggested we remove the detailed description of LPC out of the device tree. We would have the one LPC node, and create a LPC driver that creates all of the sub devices (snoop, FW cycles, kcs, bt, vuart). Andrew, can you elaborate on this plan? Cheers, Joel > > Chia-Wei, Wang (4): > ARM: dts: Remove LPC BMC and Host partitions > soc: aspeed: Fix LPC register offsets > ipmi: kcs: aspeed: Fix LPC register offsets > pinctrl: aspeed-g5: Fix LPC register offsets > > arch/arm/boot/dts/aspeed-g4.dtsi | 74 +-- > arch/arm/boot/dts/aspeed-g5.dtsi | 135 + > arch/arm/boot/dts/aspeed-g6.dtsi | 135 + > drivers/char/ipmi/kcs_bmc_aspeed.c | 13 +- > drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c | 2 +- > drivers/soc/aspeed/aspeed-lpc-ctrl.c | 6 +- > drivers/soc/aspeed/aspeed-lpc-snoop.c | 11 +- > 7 files changed, 162 insertions(+), 214 deletions(-) > > -- > 2.17.1 >
[PATCH -next 1/5] cifs: fix comparison to bool warning in cifsacl.c
Fixes coccicheck warning:
fs/cifs/cifsacl.c:371:6-49: WARNING: Comparison to bool
Signed-off-by: Zheng Bin
---
fs/cifs/cifsacl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/cifs/cifsacl.c b/fs/cifs/cifsacl.c
index fcff14ef1c70..9447ff1a5b6a 100644
--- a/fs/cifs/cifsacl.c
+++ b/fs/cifs/cifsacl.c
@@ -368,7 +368,7 @@ sid_to_id(struct cifs_sb_info *cifs_sb, struct cifs_sid
*psid,
else
is_group = false;
- if (is_well_known_sid(psid, _id, is_group) == false)
+ if (!is_well_known_sid(psid, _id, is_group))
goto try_upcall_to_get_id;
if (is_group) {
--
2.26.0.106.g9fadedd
[PATCH -next 2/5] cifs: fix comparison to bool warning in file.c
Fixes coccicheck warning:
fs/cifs/file.c:780:22-38: WARNING: Comparison to bool
Signed-off-by: Zheng Bin
---
fs/cifs/file.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/cifs/file.c b/fs/cifs/file.c
index be46fab4c96d..bad749f606d5 100644
--- a/fs/cifs/file.c
+++ b/fs/cifs/file.c
@@ -777,7 +777,7 @@ cifs_reopen_file(struct cifsFileInfo *cfile, bool can_flush)
* not dirty locally we could do this.
*/
rc = server->ops->open(xid, , , NULL);
- if (rc == -ENOENT && oparms.reconnect == false) {
+ if (rc == -ENOENT && !oparms.reconnect) {
/* durable handle timeout is expired - open the file again */
rc = server->ops->open(xid, , , NULL);
/* indicate that we need to relock the file */
--
2.26.0.106.g9fadedd
[PATCH -next 0/5] cifs: fix comparison to bool warning
Zheng Bin (5): cifs: fix comparison to bool warning in cifsacl.c cifs: fix comparison to bool warning in file.c cifs: fix comparison to bool warning in smb2misc.c cifs: fix comparison to bool warning in connect.c cifs: fix comparison to bool warning in smb2ops.c fs/cifs/cifsacl.c | 2 +- fs/cifs/connect.c | 6 +++--- fs/cifs/file.c | 2 +- fs/cifs/smb2misc.c | 2 +- fs/cifs/smb2ops.c | 10 +- 5 files changed, 11 insertions(+), 11 deletions(-) -- 2.26.0.106.g9fadedd
[PATCH net-next] net: stmmac: set get_rx_header_len() as void for it didn't have any error code to return
We found the following warning when using W=1 to build kernel:
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:3634:6: warning: variable
‘ret’ set but not used [-Wunused-but-set-variable]
int ret, coe = priv->hw->rx_csum;
When digging stmmac_get_rx_header_len(), dwmac4_get_rx_header_len() and
dwxgmac2_get_rx_header_len() return 0 only, without any error code to
report. Therefore, it's better to define get_rx_header_len() as void.
Signed-off-by: Luo Jiaxing
---
drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c | 3 +--
drivers/net/ethernet/stmicro/stmmac/dwxgmac2_descs.c | 3 +--
drivers/net/ethernet/stmicro/stmmac/hwif.h | 4 ++--
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c| 4 ++--
4 files changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
index eff8206..c6540b0 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
@@ -494,10 +494,9 @@ static void dwmac4_set_vlan(struct dma_desc *p, u32 type)
p->des2 |= cpu_to_le32(type & TDES2_VLAN_TAG_MASK);
}
-static int dwmac4_get_rx_header_len(struct dma_desc *p, unsigned int *len)
+static void dwmac4_get_rx_header_len(struct dma_desc *p, unsigned int *len)
{
*len = le32_to_cpu(p->des2) & RDES2_HL;
- return 0;
}
static void dwmac4_set_sec_addr(struct dma_desc *p, dma_addr_t addr)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_descs.c
b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_descs.c
index c3d654c..0aaf19a 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_descs.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_descs.c
@@ -286,11 +286,10 @@ static int dwxgmac2_get_rx_hash(struct dma_desc *p, u32
*hash,
return -EINVAL;
}
-static int dwxgmac2_get_rx_header_len(struct dma_desc *p, unsigned int *len)
+static void dwxgmac2_get_rx_header_len(struct dma_desc *p, unsigned int *len)
{
if (le32_to_cpu(p->des3) & XGMAC_RDES3_L34T)
*len = le32_to_cpu(p->des2) & XGMAC_RDES2_HL;
- return 0;
}
static void dwxgmac2_set_sec_addr(struct dma_desc *p, dma_addr_t addr)
diff --git a/drivers/net/ethernet/stmicro/stmmac/hwif.h
b/drivers/net/ethernet/stmicro/stmmac/hwif.h
index ffe2d63..e2dca9b 100644
--- a/drivers/net/ethernet/stmicro/stmmac/hwif.h
+++ b/drivers/net/ethernet/stmicro/stmmac/hwif.h
@@ -90,7 +90,7 @@ struct stmmac_desc_ops {
/* RSS */
int (*get_rx_hash)(struct dma_desc *p, u32 *hash,
enum pkt_hash_types *type);
- int (*get_rx_header_len)(struct dma_desc *p, unsigned int *len);
+ void (*get_rx_header_len)(struct dma_desc *p, unsigned int *len);
void (*set_sec_addr)(struct dma_desc *p, dma_addr_t addr);
void (*set_sarc)(struct dma_desc *p, u32 sarc_type);
void (*set_vlan_tag)(struct dma_desc *p, u16 tag, u16 inner_tag,
@@ -150,7 +150,7 @@ struct stmmac_desc_ops {
#define stmmac_get_rx_hash(__priv, __args...) \
stmmac_do_callback(__priv, desc, get_rx_hash, __args)
#define stmmac_get_rx_header_len(__priv, __args...) \
- stmmac_do_callback(__priv, desc, get_rx_header_len, __args)
+ stmmac_do_void_callback(__priv, desc, get_rx_header_len, __args)
#define stmmac_set_desc_sec_addr(__priv, __args...) \
stmmac_do_void_callback(__priv, desc, set_sec_addr, __args)
#define stmmac_set_desc_sarc(__priv, __args...) \
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 89b2b34..7e95412 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -3631,15 +3631,15 @@ static unsigned int stmmac_rx_buf1_len(struct
stmmac_priv *priv,
struct dma_desc *p,
int status, unsigned int len)
{
- int ret, coe = priv->hw->rx_csum;
unsigned int plen = 0, hlen = 0;
+ int coe = priv->hw->rx_csum;
/* Not first descriptor, buffer is always zero */
if (priv->sph && len)
return 0;
/* First descriptor, get split header length */
- ret = stmmac_get_rx_header_len(priv, p, );
+ stmmac_get_rx_header_len(priv, p, );
if (priv->sph && hlen) {
priv->xstats.rx_split_hdr_pkt_n++;
return hlen;
--
2.7.4
[PATCH -next 4/5] cifs: fix comparison to bool warning in connect.c
Fixes coccicheck warning:
fs/cifs/connect.c:2478:5-16: WARNING: Comparison to bool
fs/cifs/connect.c:3560:10-35: WARNING: Comparison to bool
fs/cifs/connect.c:4297:6-21: WARNING: Comparison to bool
Signed-off-by: Zheng Bin
---
fs/cifs/connect.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/fs/cifs/connect.c b/fs/cifs/connect.c
index a5731dd6e656..4d2651b9f019 100644
--- a/fs/cifs/connect.c
+++ b/fs/cifs/connect.c
@@ -2475,7 +2475,7 @@ cifs_parse_mount_options(const char *mountdata, const
char *devname,
else if (override_gid == 1)
pr_notice("ignoring forcegid mount option specified with no
gid= option\n");
- if (got_version == false)
+ if (!got_version)
pr_warn_once("No dialect specified on mount. Default has
changed to a more secure dialect, SMB2.1 or later (e.g. SMB3.1.1), from CIFS
(SMB1). To use the less secure SMB1 dialect to access old servers which do not
support SMB3.1.1 (or even SMB3 or SMB2.1) specify vers=1.0 on mount.\n");
kfree(mountdata_copy);
@@ -3557,7 +3557,7 @@ cifs_get_tcon(struct cifs_ses *ses, struct smb_vol
*volume_info)
}
} else if ((tcon->capabilities & SMB2_SHARE_CAP_CONTINUOUS_AVAILABILITY)
&& (ses->server->capabilities & SMB2_GLOBAL_CAP_PERSISTENT_HANDLES)
-&& (volume_info->nopersistent == false)) {
+&& !volume_info->nopersistent) {
cifs_dbg(FYI, "enabling persistent handles\n");
tcon->use_persistent = true;
} else if (volume_info->resilient) {
@@ -4294,7 +4294,7 @@ static int mount_get_conns(struct smb_vol *vol, struct
cifs_sb_info *cifs_sb,
*nses = ses;
- if ((vol->persistent == true) && (!(ses->server->capabilities &
+ if (vol->persistent && (!(ses->server->capabilities &
SMB2_GLOBAL_CAP_PERSISTENT_HANDLES))) {
cifs_server_dbg(VFS, "persistent handles not supported by
server\n");
return -EOPNOTSUPP;
--
2.26.0.106.g9fadedd
[PATCH -next 3/5] cifs: fix comparison to bool warning in smb2misc.c
Fixes coccicheck warning: fs/cifs/smb2misc.c:416:5-51: WARNING: Comparison to bool Signed-off-by: Zheng Bin --- fs/cifs/smb2misc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/cifs/smb2misc.c b/fs/cifs/smb2misc.c index d88e2683626e..0864cfa87834 100644 --- a/fs/cifs/smb2misc.c +++ b/fs/cifs/smb2misc.c @@ -413,7 +413,7 @@ smb2_calc_size(void *buf, struct TCP_Server_Info *srvr) */ len += le16_to_cpu(pdu->StructureSize2); - if (has_smb2_data_area[le16_to_cpu(shdr->Command)] == false) + if (!has_smb2_data_area[le16_to_cpu(shdr->Command)]) goto calc_size_exit; smb2_get_data_area_len(, _length, shdr); -- 2.26.0.106.g9fadedd
[PATCH -next 5/5] cifs: fix comparison to bool warning in smb2ops.c
Fixes coccicheck warning:
fs/cifs/smb2ops.c:3199:6-15: WARNING: Comparison to bool
fs/cifs/smb2ops.c:3223:5-14: WARNING: Comparison to bool
fs/cifs/smb2ops.c:3301:6-15: WARNING: Comparison to bool
fs/cifs/smb2ops.c:3311:6-15: WARNING: Comparison to bool
fs/cifs/smb2ops.c:3341:6-15: WARNING: Comparison to bool
Signed-off-by: Zheng Bin
---
fs/cifs/smb2ops.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/fs/cifs/smb2ops.c b/fs/cifs/smb2ops.c
index 32f90dc82c84..213a0e3d9f76 100644
--- a/fs/cifs/smb2ops.c
+++ b/fs/cifs/smb2ops.c
@@ -3196,7 +3196,7 @@ static long smb3_zero_range(struct file *file, struct
cifs_tcon *tcon,
/* if file not oplocked can't be sure whether asking to extend size */
if (!CIFS_CACHE_READ(cifsi))
- if (keep_size == false) {
+ if (!keep_size) {
rc = -EOPNOTSUPP;
trace_smb3_zero_err(xid, cfile->fid.persistent_fid,
tcon->tid, ses->Suid, offset, len, rc);
@@ -3220,7 +3220,7 @@ static long smb3_zero_range(struct file *file, struct
cifs_tcon *tcon,
/*
* do we also need to change the size of the file?
*/
- if (keep_size == false && i_size_read(inode) < offset + len) {
+ if (!keep_size && i_size_read(inode) < offset + len) {
eof = cpu_to_le64(offset + len);
rc = SMB2_set_eof(xid, tcon, cfile->fid.persistent_fid,
cfile->fid.volatile_fid, cfile->pid, );
@@ -3298,7 +3298,7 @@ static long smb3_simple_falloc(struct file *file, struct
cifs_tcon *tcon,
tcon->ses->Suid, off, len);
/* if file not oplocked can't be sure whether asking to extend size */
if (!CIFS_CACHE_READ(cifsi))
- if (keep_size == false) {
+ if (!keep_size) {
trace_smb3_falloc_err(xid, cfile->fid.persistent_fid,
tcon->tid, tcon->ses->Suid, off, len, rc);
free_xid(xid);
@@ -3308,7 +3308,7 @@ static long smb3_simple_falloc(struct file *file, struct
cifs_tcon *tcon,
/*
* Extending the file
*/
- if ((keep_size == false) && i_size_read(inode) < off + len) {
+ if (!keep_size && i_size_read(inode) < off + len) {
rc = inode_newsize_ok(inode, off + len);
if (rc)
goto out;
@@ -3338,7 +3338,7 @@ static long smb3_simple_falloc(struct file *file, struct
cifs_tcon *tcon,
goto out;
}
- if ((keep_size == true) || (i_size_read(inode) >= off + len)) {
+ if (keep_size || (i_size_read(inode) >= off + len)) {
/*
* Check if falloc starts within first few pages of file
* and ends within a few pages of the end of file to
--
2.26.0.106.g9fadedd
Re: [PATCH net-next] net: stmmac: Remove unused variable 'ret' at stmmac_rx_buf1_len()
On 2020/9/11 3:29, Jakub Kicinski wrote:
On Thu, 10 Sep 2020 10:42:45 +0800 Luo Jiaxing wrote:
Fixes the following warning when using W=1 to build kernel:
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:3634:6: warning: variable
‘ret’ set but not used [-Wunused-but-set-variable]
int ret, coe = priv->hw->rx_csum;
When digging stmmac_get_rx_header_len(), dwmac4_get_rx_header_len() and
dwxgmac2_get_rx_header_len() return 0 by default. Therefore, ret do not
need to check the error value and can be directly deleted.
Signed-off-by: Luo Jiaxing
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 89b2b34..7e95412 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -3631,15 +3631,15 @@ static unsigned int stmmac_rx_buf1_len(struct
stmmac_priv *priv,
struct dma_desc *p,
int status, unsigned int len)
{
- int ret, coe = priv->hw->rx_csum;
unsigned int plen = 0, hlen = 0;
+ int coe = priv->hw->rx_csum;
/* Not first descriptor, buffer is always zero */
if (priv->sph && len)
return 0;
/* First descriptor, get split header length */
- ret = stmmac_get_rx_header_len(priv, p, );
+ stmmac_get_rx_header_len(priv, p, );
This function should return void if there never are any errors to
report.
Yes, you are right. So, if we need to modify the function type , this
patch need to be drop.
And I will send a new patch later to redefine get_rx_header_len() to
void and delete ret there.
Please check "net: stmmac: set get_rx_header_len() as void for it didn't
have any error code to return" later.
Thanks
Jiaxing
if (priv->sph && hlen) {
priv->xstats.rx_split_hdr_pkt_n++;
return hlen;
.
Re: [PATCH v2] i2c: virtio: add a virtio i2c frontend driver
On 9/10/20 8:48 PM, Jie Deng wrote: > diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig > index 293e7a0..70c8e30 100644 > --- a/drivers/i2c/busses/Kconfig > +++ b/drivers/i2c/busses/Kconfig > @@ -21,6 +21,17 @@ config I2C_ALI1535 > This driver can also be built as a module. If so, the module > will be called i2c-ali1535. > > +config I2C_VIRTIO > + tristate "Virtio I2C Adapter" > + depends on VIRTIO > + help > + If you say yes to this option, support will be included for the virtio > + i2c adapter driver. The hardware can be emulated by any device model I2C preferably > + software according to the virtio protocol. > + > + This driver can also be built as a module. If so, the module > + will be called i2c-virtio. > + > config I2C_ALI1563 > tristate "ALI 1563" > depends on PCI thanks. -- ~Randy
Re: [PATCH 2/3] mmc: sdhci-of-aspeed: Expose data sample phase delay tuning
On Fri, 11 Sep 2020, at 13:03, Joel Stanley wrote:
> On Fri, 11 Sep 2020 at 02:49, Andrew Jeffery wrote:
> >
> >
> >
> > On Fri, 11 Sep 2020, at 11:32, Joel Stanley wrote:
> > > On Thu, 10 Sep 2020 at 10:55, Andrew Jeffery wrote:
> > > >
> > > > Allow sample phase adjustment to deal with layout or tolerance issues.
> > > >
> > > > Signed-off-by: Andrew Jeffery
> > > > ---
> > > > drivers/mmc/host/sdhci-of-aspeed.c | 137 +++--
> > > > 1 file changed, 132 insertions(+), 5 deletions(-)
> > > >
> > > > diff --git a/drivers/mmc/host/sdhci-of-aspeed.c
> > > > b/drivers/mmc/host/sdhci-of-aspeed.c
> > > > index 4f008ba3280e..641accbfcde4 100644
> > > > --- a/drivers/mmc/host/sdhci-of-aspeed.c
> > > > +++ b/drivers/mmc/host/sdhci-of-aspeed.c
>
> > > > +static void
> > > > +aspeed_sdc_configure_phase(struct aspeed_sdc *sdc,
> > > > + const struct aspeed_sdhci_phase_desc *phase,
> > > > + uint8_t value, bool enable)
> > > > +{
> > > > + u32 reg;
> > > > +
> > > > + spin_lock(>lock);
> > >
> > > What is the lock protecting against?
> > >
> > > We call this in the ->probe, so there should be no concurrent access
> > > going on.
> >
> > Because the register is in the "global" part of the SD/MMC controller
> > address
> > space (it's not part of the SDHCI), and there are multiple slots that may
> > have
> > a driver probed concurrently.
>
> That points to having the property be part of the "global" device tree
> node.
Not really. The settings are slot-specific. The only reason it's in the global
register space is that the settings cannot be part of the SDHCI. That Aspeed
chose to pack them in the same register, and _interleaved_ at that, is
unfortunate.
As the settings are slot-specific they should be associated with each slot's
node. We should concentrate on representing the intent of the controls and
not tie the devicetree representation to the register layout that Aspeed came
up with.
> This would simplify the code; you wouldn't need the locking
> either.
IMO this is a loss for readability, so I'm not convinced it should be changed.
The outcome is some opaque register value that is shoved in the devicetree,
and given the baffling interleaving and choices of field sizes that's not a
place
I want to be.
>
> >
> > >
> > >
> > > > + reg = readl(sdc->regs + ASPEED_SDC_PHASE);
> > > > + reg &= ~phase->enable_mask;
> > > > + if (enable) {
> > > > + reg &= ~phase->value_mask;
> > > > + reg |= value << __ffs(phase->value_mask);
> > > > + reg |= phase->enable_value << __ffs(phase->enable_mask);
> > > > + }
> > > > + writel(reg, sdc->regs + ASPEED_SDC_PHASE);
> > > > + spin_unlock(>lock);
> > > > +}
> > > > +
> > > > static void aspeed_sdhci_set_clock(struct sdhci_host *host, unsigned
> > > > int clock)
> > > > {
> > > > struct sdhci_pltfm_host *pltfm_host;
> > > > @@ -155,8 +195,58 @@ static inline int
> > > > aspeed_sdhci_calculate_slot(struct aspeed_sdhci *dev,
> > > > return (delta / 0x100) - 1;
> > > > }
> > > >
> > > > +static int aspeed_sdhci_configure_of(struct platform_device *pdev,
> > > > +struct aspeed_sdhci *sdhci)
> > > > +{
> > > > + u32 iphase, ophase;
> > > > + struct device_node *np;
> > > > + struct device *dev;
> > > > + int ret;
> > > > +
> > > > + if (!sdhci->phase)
> > > > + return 0;
> > > > +
> > > > + dev = >dev;
> > > > + np = dev->of_node;
> > > > +
> > > > + ret = of_property_read_u32(np, "aspeed,input-phase", );
> > > > + if (ret < 0) {
> > > > + aspeed_sdc_configure_phase(sdhci->parent,
> > > > >phase->in, 0,
> > > > + false);
> > >
> > > Will this clear any value that eg. u-boot writes?
> >
> > No, see the 'enable' test in aspeed_sdc_configure_phase()
>
> OK, so this branch will never cause any change in the register? Best
> to drop it then.
So there are two parts to the phase configuration, the phase adjustment
value, and a switch to turn phase adjustment on or off. Both fields exist
for both in and out phase adjustments for both slots.
So this branch will cause the phase control to be disabled, but it won't
change the phase value that was originally programmed. If we maintain
the original semantics it shouldn't be dropped.
However, below you suggest we maintain the configuration (both
enable and value state) in the absence of the property, so the code
needs to be reworked to uphold suggestion.
>
> >
> > >
> > > The register should be left alone if the kernel doesn't have a
> > > configuration of it's own, otherwise we may end up breaking an
> > > otherwise working system.
> >
> > Right, I can rework that.
>
Re: [External] Re: [PATCH v2] stackleak: Fix a race between stack erasing sysctl handlers
Ping guys. Thanks.
On Mon, Sep 7, 2020 at 9:53 PM Muchun Song wrote:
>
> On Mon, Sep 7, 2020 at 7:24 PM Alexander Popov wrote:
> >
> > On 07.09.2020 05:54, Muchun Song wrote:
> > > Hi all,
> > >
> > > Any comments or suggestions? Thanks.
> > >
> > > On Fri, Aug 28, 2020 at 11:19 AM Muchun Song
> > > wrote:
> > >>
> > >> There is a race between the assignment of `table->data` and write value
> > >> to the pointer of `table->data` in the __do_proc_doulongvec_minmax() on
> > >> the other thread.
> > >>
> > >> CPU0: CPU1:
> > >> proc_sys_write
> > >> stack_erasing_sysctlproc_sys_call_handler
> > >> table->data =stack_erasing_sysctl
> > >> table->data =
> > >> proc_doulongvec_minmax
> > >> do_proc_doulongvec_minmax sysctl_head_finish
> > >> __do_proc_doulongvec_minmax unuse_table
> > >> i = table->data;
> > >> *i = val; // corrupt CPU1's stack
> >
> > Hello everyone!
> >
> > As I remember, I implemented stack_erasing_sysctl() very similar to other
> > sysctl
> > handlers. Is that issue relevant for other handlers as well?
>
> Yeah, it's very similar. But the difference is that others use a
> global variable as the
> `table->data`, but here we use a local variable as the `table->data`.
> The local variable
> is allocated from the stack. So other thread could corrupt the stack
> like the diagram
> above.
>
> >
> > Muchun, could you elaborate how CPU1's stack is corrupted and how you
> > detected
> > that? Thanks!
>
> Why did I find this problem? Because I solve another problem which is
> very similar to
> this issue. You can reference the following fix patch. Thanks.
>
> https://lkml.org/lkml/2020/8/22/105
>
>
>
>
> >
> > Best regards,
> > Alexander
> >
> > >> Fix this by duplicating the `table`, and only update the duplicate of
> > >> it.
> > >>
> > >> Fixes: 964c9dff0091 ("stackleak: Allow runtime disabling of kernel stack
> > >> erasing")
> > >> Signed-off-by: Muchun Song
> > >> ---
> > >> changelogs in v2:
> > >> 1. Add more details about how the race happened to the commit message.
> > >>
> > >> kernel/stackleak.c | 11 ---
> > >> 1 file changed, 8 insertions(+), 3 deletions(-)
> > >>
> > >> diff --git a/kernel/stackleak.c b/kernel/stackleak.c
> > >> index a8fc9ae1d03d..fd95b87478ff 100644
> > >> --- a/kernel/stackleak.c
> > >> +++ b/kernel/stackleak.c
> > >> @@ -25,10 +25,15 @@ int stack_erasing_sysctl(struct ctl_table *table,
> > >> int write,
> > >> int ret = 0;
> > >> int state = !static_branch_unlikely(_erasing_bypass);
> > >> int prev_state = state;
> > >> + struct ctl_table dup_table = *table;
> > >>
> > >> - table->data =
> > >> - table->maxlen = sizeof(int);
> > >> - ret = proc_dointvec_minmax(table, write, buffer, lenp, ppos);
> > >> + /*
> > >> +* In order to avoid races with __do_proc_doulongvec_minmax(), we
> > >> +* can duplicate the @table and alter the duplicate of it.
> > >> +*/
> > >> + dup_table.data =
> > >> + dup_table.maxlen = sizeof(int);
> > >> + ret = proc_dointvec_minmax(_table, write, buffer, lenp,
> > >> ppos);
> > >> state = !!state;
> > >> if (ret || !write || state == prev_state)
> > >> return ret;
> > >> --
> > >> 2.11.0
> > >>
> > >
> > >
> >
>
>
> --
> Yours,
> Muchun
--
Yours,
Muchun
Re: [External] Re: [PATCH] mm: memcontrol: Add the missing numa stat of anon and file for cgroup v2
On Fri, Sep 11, 2020 at 12:02 AM Shakeel Butt wrote:
>
> On Thu, Sep 10, 2020 at 1:46 AM Muchun Song wrote:
> >
> > In the cgroup v1, we have a numa_stat interface. This is useful for
> > providing visibility into the numa locality information within an
> > memcg since the pages are allowed to be allocated from any physical
> > node. One of the use cases is evaluating application performance by
> > combining this information with the application's CPU allocation.
> > But the cgroup v2 does not. So this patch adds the missing information.
> >
> > Signed-off-by: Muchun Song
> > ---
>
> I am actually working on exposing this info on v2 as well.
>
> > mm/memcontrol.c | 46 --
> > 1 file changed, 44 insertions(+), 2 deletions(-)
> >
> > diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> > index 75cd1a1e66c8..c779673f29b2 100644
> > --- a/mm/memcontrol.c
> > +++ b/mm/memcontrol.c
> > @@ -1492,10 +1492,34 @@ static bool mem_cgroup_wait_acct_move(struct
> > mem_cgroup *memcg)
> > return false;
> > }
> >
> > +#ifdef CONFIG_NUMA
> > +static unsigned long memcg_node_page_state(struct mem_cgroup *memcg,
> > + unsigned int nid,
> > + enum node_stat_item idx)
> > +{
> > + long x;
> > + struct mem_cgroup_per_node *pn;
> > + struct lruvec *lruvec = mem_cgroup_lruvec(memcg, NODE_DATA(nid));
> > +
> > + VM_BUG_ON(nid >= nr_node_ids);
> > +
> > + pn = container_of(lruvec, struct mem_cgroup_per_node, lruvec);
> > + x = atomic_long_read(>lruvec_stat[idx]);
> > +#ifdef CONFIG_SMP
> > + if (x < 0)
> > + x = 0;
> > +#endif
> > + return x;
> > +}
> > +#endif
> > +
> > static char *memory_stat_format(struct mem_cgroup *memcg)
> > {
> > struct seq_buf s;
> > int i;
> > +#ifdef CONFIG_NUMA
> > + int nid;
> > +#endif
> >
> > seq_buf_init(, kmalloc(PAGE_SIZE, GFP_KERNEL), PAGE_SIZE);
> > if (!s.buffer)
> > @@ -1512,12 +1536,30 @@ static char *memory_stat_format(struct mem_cgroup
> > *memcg)
> > * Current memory state:
> > */
> >
>
> Let's not break the parsers of memory.stat. I would prefer a separate
> interface like v1 i.e. memory.numa_stat.
It is also a good idea to expose a new interface like memory.numa_stat.
>
> > - seq_buf_printf(, "anon %llu\n",
> > + seq_buf_printf(, "anon %llu",
> >(u64)memcg_page_state(memcg, NR_ANON_MAPPED) *
> >PAGE_SIZE);
> > - seq_buf_printf(, "file %llu\n",
> > +#ifdef CONFIG_NUMA
> > + for_each_node_state(nid, N_MEMORY)
> > + seq_buf_printf(, " N%d=%llu", nid,
> > + (u64)memcg_node_page_state(memcg, nid,
> > + NR_ANON_MAPPED) *
> > + PAGE_SIZE);
> > +#endif
> > + seq_buf_putc(, '\n');
> > +
> > + seq_buf_printf(, "file %llu",
> >(u64)memcg_page_state(memcg, NR_FILE_PAGES) *
> >PAGE_SIZE);
> > +#ifdef CONFIG_NUMA
> > + for_each_node_state(nid, N_MEMORY)
> > + seq_buf_printf(, " N%d=%llu", nid,
> > + (u64)memcg_node_page_state(memcg, nid,
> > + NR_FILE_PAGES) *
> > + PAGE_SIZE);
> > +#endif
> > + seq_buf_putc(, '\n');
> > +
>
> The v1's numa_stat exposes the LRUs, why NR_ANON_MAPPED and NR_FILE_PAGES?
If we want to expose the anon per node, we need to add inactive anon and
active anon together. Why not use NR_ANON_MAPPED directly?
>
> Also I think exposing slab_[un]reclaimable per node would be beneficial as
> well.
Yeah, I agree with you. Maybe kernel_stack and percpu also should
be exposed.
>
> > seq_buf_printf(, "kernel_stack %llu\n",
> >(u64)memcg_page_state(memcg, NR_KERNEL_STACK_KB) *
> >1024);
> > --
> > 2.20.1
> >
--
Yours,
Muchun
[PATCH v2] i2c: virtio: add a virtio i2c frontend driver
Add an I2C bus driver for virtio para-virtualization.
The controller can be emulated by the backend driver in
any device model software by following the virtio protocol.
This driver communicates with the backend driver through a
virtio I2C message structure which includes following parts:
- Header: i2c_msg addr, flags, len.
- Data buffer: the pointer to the I2C msg data.
- Status: the processing result from the backend.
People may implement different backend drivers to emulate
different controllers according to their needs. A backend
example can be found in the device model of the open source
project ACRN. For more information, please refer to
https://projectacrn.org.
The virtio device ID 34 is used for this I2C adpter since IDs
before 34 have been reserved by other virtio devices.
Co-developed-by: Conghui Chen
Signed-off-by: Conghui Chen
Signed-off-by: Jie Deng
Reviewed-by: Shuo Liu
Reviewed-by: Andy Shevchenko
---
The device ID request:
https://github.com/oasis-tcs/virtio-spec/issues/85
Changes in v2:
- Addressed comments received from Michael, Andy and Jason.
drivers/i2c/busses/Kconfig | 11 ++
drivers/i2c/busses/Makefile | 3 +
drivers/i2c/busses/i2c-virtio.c | 271
include/uapi/linux/virtio_ids.h | 1 +
4 files changed, 286 insertions(+)
create mode 100644 drivers/i2c/busses/i2c-virtio.c
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 293e7a0..70c8e30 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -21,6 +21,17 @@ config I2C_ALI1535
This driver can also be built as a module. If so, the module
will be called i2c-ali1535.
+config I2C_VIRTIO
+ tristate "Virtio I2C Adapter"
+ depends on VIRTIO
+ help
+ If you say yes to this option, support will be included for the virtio
+ i2c adapter driver. The hardware can be emulated by any device model
+ software according to the virtio protocol.
+
+ This driver can also be built as a module. If so, the module
+ will be called i2c-virtio.
+
config I2C_ALI1563
tristate "ALI 1563"
depends on PCI
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 19aff0e..821acfa 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -6,6 +6,9 @@
# ACPI drivers
obj-$(CONFIG_I2C_SCMI) += i2c-scmi.o
+# VIRTIO I2C host controller driver
+obj-$(CONFIG_I2C_VIRTIO) += i2c-virtio.o
+
# PC SMBus host controller drivers
obj-$(CONFIG_I2C_ALI1535) += i2c-ali1535.o
obj-$(CONFIG_I2C_ALI1563) += i2c-ali1563.o
diff --git a/drivers/i2c/busses/i2c-virtio.c b/drivers/i2c/busses/i2c-virtio.c
new file mode 100644
index 000..aff1a9a
--- /dev/null
+++ b/drivers/i2c/busses/i2c-virtio.c
@@ -0,0 +1,271 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Virtio I2C Bus Driver
+ *
+ * Copyright (c) 2020 Intel Corporation. All rights reserved.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#define VIRTIO_I2C_MSG_OK 0
+#define VIRTIO_I2C_MSG_ERR 1
+
+/**
+ * struct virtio_i2c_hdr - the virtio I2C message header structure
+ * @addr: i2c_msg addr, the slave address
+ * @flags: i2c_msg flags
+ * @len: i2c_msg len
+ */
+struct virtio_i2c_hdr {
+ __le16 addr;
+ __le16 flags;
+ __le16 len;
+};
+
+/**
+ * struct virtio_i2c_msg - the virtio I2C message structure
+ * @hdr: the virtio I2C message header
+ * @buf: virtio I2C message data buffer
+ * @status: the processing result from the backend
+ */
+struct virtio_i2c_msg {
+ struct virtio_i2c_hdr hdr;
+ u8 *buf;
+ u8 status;
+};
+
+/**
+ * struct virtio_i2c - virtio I2C data
+ * @vdev: virtio device for this controller
+ * @completion: completion of virtio I2C message
+ * @vmsg: the virtio I2C message for communication
+ * @adap: I2C adapter for this controller
+ * @i2c_lock: lock for virtqueue processing
+ * @vq: the virtio virtqueue for communication
+ */
+struct virtio_i2c {
+ struct virtio_device *vdev;
+ struct completion completion;
+ struct virtio_i2c_msg vmsg;
+ struct i2c_adapter adap;
+ struct mutex i2c_lock;
+ struct virtqueue *vq;
+};
+
+static void virtio_i2c_msg_done(struct virtqueue *vq)
+{
+ struct virtio_i2c *vi = vq->vdev->priv;
+
+ complete(>completion);
+}
+
+static int virtio_i2c_add_msg(struct virtqueue *vq,
+ struct virtio_i2c_msg *vmsg,
+ struct i2c_msg *msg)
+{
+ struct scatterlist *sgs[3], hdr, bout, bin, status;
+ int outcnt = 0, incnt = 0;
+
+ if (!msg->len)
+ return -EINVAL;
+
+ vmsg->hdr.addr = cpu_to_le16(msg->addr);
+ vmsg->hdr.flags = cpu_to_le16(msg->flags);
+ vmsg->hdr.len = cpu_to_le16(msg->len);
+
+
[PATCH v3] drm/dp_mst: Retrieve extended DPCD caps for topology manager
As per DP-1.3, First check DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT.
If DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT is 1, read the DP_DP13_DPCD_REV to
get the faster capability.
If DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT is 0, read DP_DPCD_REV.
Signed-off-by: Koba Ko
Reviewed-by: Lyude Paul
---
Changelog:
1. Adjust the commit message.
2. use drm_dbg_kms instead and print the return code.
---
drivers/gpu/drm/drm_dp_mst_topology.c | 14 +++---
1 file changed, 3 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 7753c718ddf9..63f8809b9aa4 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -3671,8 +3671,6 @@ EXPORT_SYMBOL(drm_dp_read_mst_cap);
int drm_dp_mst_topology_mgr_set_mst(struct drm_dp_mst_topology_mgr *mgr, bool
mst_state)
{
int ret = 0;
- u8 dpcd_ext = 0;
- unsigned int dpcd_offset = 0;
struct drm_dp_mst_branch *mstb = NULL;
mutex_lock(>payload_lock);
@@ -3686,17 +3684,11 @@ int drm_dp_mst_topology_mgr_set_mst(struct
drm_dp_mst_topology_mgr *mgr, bool ms
struct drm_dp_payload reset_pay;
WARN_ON(mgr->mst_primary);
- drm_dp_dpcd_read(mgr->aux,
-DP_TRAINING_AUX_RD_INTERVAL,
-_ext, sizeof(dpcd_ext));
-
- dpcd_offset =
- ((dpcd_ext & DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT) ?
DP_DP13_DPCD_REV : DP_DPCD_REV);
/* get dpcd info */
- ret = drm_dp_dpcd_read(mgr->aux, dpcd_offset, mgr->dpcd,
DP_RECEIVER_CAP_SIZE);
- if (ret != DP_RECEIVER_CAP_SIZE) {
- DRM_DEBUG_KMS("failed to read DPCD\n");
+ ret = drm_dp_read_dpcd_caps(mgr->aux, mgr->dpcd);
+ if (ret < 0) {
+ drm_dbg_kms(mgr->dev, "failed to read DPCD, ret %d\n",
ret);
goto out_unlock;
}
--
2.25.1
Re: [PATCH V2] scripts : config : Added example use when run without argument,extend help
On 20:08 Thu 10 Sep 2020, Randy Dunlap wrote: On 9/10/20 6:54 PM, Bhaskar Chowdhury wrote: This patch extends the help section by adding an explicit example of use. Signed-off-by: Bhaskar Chowdhury --- Difference between versions goes here. scripts/config | 17 + 1 file changed, 17 insertions(+) diff --git a/scripts/config b/scripts/config index eee5b7f3a092..d905dccabb94 100755 --- a/scripts/config +++ b/scripts/config @@ -45,6 +45,23 @@ make time. By default, $myname will upper-case the given symbol. Use --keep-case to keep the case of all following symbols unchanged. +The concrete example, say, you want to change any particular config,like config, like +GCOV for profiling, you can simply use this command command. + +To enable: + +#scripts/config --enable GCOV_KERNEL && grep GCOV .config + + and the output will be like this: + + CONFIG_GCOV_KERNEL=y + +To disable: + +#scripts/config --disable GCOV_KERNEL && grep GCOV .config + +# CONFIG_GCOV_KERNEL is not set + $myname uses 'CONFIG_' as the default symbol prefix. Set the environment variable CONFIG_ to the prefix to use. Eg.: CONFIG_="FOO_" $myname ... EOL I don't know why we need this extra help text. I am not sure I get you ...should have mentioned in the first place, so it save some of my time moreover, I was doing it because I felt it necessary to let the user of this script to know what/how easily things can be done.Period. Look like decision making is badly bugged. ~Bhaskar -- ~Randy signature.asc Description: PGP signature
[PATCH v2 1/2] scsi: ufs-mediatek: Support performance mode for inline encryption engine
Some MediaTek UFS platforms support high-performance mode that inline
encryption engine can be boosted while UFS is not clock-gated.
The high-performance mode will be enabled if all below conditions are
well-declaired in device tree,
1. Proper platform-specific compatible string which enables the host
capability "UFS_MTK_CAP_BOOST_CRYPT_ENGINE".
2. "dvfsrc-vcore" node is available in this platform.
3. Clock mux and clock parents of inline encryption engine for both
"low-power mode" and "high-performance mode".
Signed-off-by: Stanley Chu
---
drivers/scsi/ufs/ufs-mediatek.c | 176 ++--
drivers/scsi/ufs/ufs-mediatek.h | 22
2 files changed, 192 insertions(+), 6 deletions(-)
diff --git a/drivers/scsi/ufs/ufs-mediatek.c b/drivers/scsi/ufs/ufs-mediatek.c
index 3ec44dfa2567..83b83f21067e 100644
--- a/drivers/scsi/ufs/ufs-mediatek.c
+++ b/drivers/scsi/ufs/ufs-mediatek.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -44,6 +45,28 @@ static struct ufs_dev_fix ufs_mtk_dev_fixups[] = {
END_FIX
};
+static const struct ufs_mtk_host_cfg ufs_mtk_mt8192_cfg = {
+ .caps = UFS_MTK_CAP_BOOST_CRYPT_ENGINE,
+};
+
+static const struct of_device_id ufs_mtk_of_match[] = {
+ {
+ .compatible = "mediatek,mt8183-ufshci",
+ },
+ {
+ .compatible = "mediatek,mt8192-ufshci",
+ .data = _mtk_mt8192_cfg
+ },
+ {},
+};
+
+static bool ufs_mtk_is_boost_crypt_enabled(struct ufs_hba *hba)
+{
+ struct ufs_mtk_host *host = ufshcd_get_variant(hba);
+
+ return (host->caps & UFS_MTK_CAP_BOOST_CRYPT_ENGINE);
+}
+
static void ufs_mtk_cfg_unipro_cg(struct ufs_hba *hba, bool enable)
{
u32 tmp;
@@ -294,6 +317,137 @@ static void ufs_mtk_mphy_power_on(struct ufs_hba *hba,
bool on)
host->mphy_powered_on = on;
}
+static int ufs_mtk_get_host_clk(struct device *dev, const char *name,
+ struct clk **clk_out)
+{
+ struct clk *clk;
+ int err = 0;
+
+ clk = devm_clk_get(dev, name);
+ if (IS_ERR(clk))
+ err = PTR_ERR(clk);
+ else
+ *clk_out = clk;
+
+ return err;
+}
+
+static void ufs_mtk_boost_crypt(struct ufs_hba *hba, bool boost)
+{
+ struct ufs_mtk_host *host = ufshcd_get_variant(hba);
+ struct ufs_mtk_crypt_cfg *cfg;
+ struct regulator *reg;
+ int volt, ret;
+
+ if (!ufs_mtk_is_boost_crypt_enabled(hba))
+ return;
+
+ cfg = host->crypt;
+ volt = cfg->vcore_volt;
+ reg = cfg->reg_vcore;
+
+ ret = clk_prepare_enable(cfg->clk_crypt_mux);
+ if (ret) {
+ dev_info(hba->dev, "clk_prepare_enable(): %d\n",
+ret);
+ return;
+ }
+
+ if (boost) {
+ ret = regulator_set_voltage(reg, volt, INT_MAX);
+ if (ret) {
+ dev_info(hba->dev,
+"failed to set vcore to %d\n", volt);
+ goto out;
+ }
+
+ ret = clk_set_parent(cfg->clk_crypt_mux,
+cfg->clk_crypt_perf);
+ if (ret) {
+ dev_info(hba->dev,
+"failed to set clk_crypt_perf\n");
+ regulator_set_voltage(reg, 0, INT_MAX);
+ goto out;
+ }
+ } else {
+ ret = clk_set_parent(cfg->clk_crypt_mux,
+cfg->clk_crypt_lp);
+ if (ret) {
+ dev_info(hba->dev,
+"failed to set clk_crypt_lp\n");
+ goto out;
+ }
+
+ ret = regulator_set_voltage(reg, 0, INT_MAX);
+ if (ret) {
+ dev_info(hba->dev,
+"failed to set vcore to MIN\n");
+ }
+ }
+out:
+ clk_disable_unprepare(cfg->clk_crypt_mux);
+}
+
+static int ufs_mtk_init_host_clk(struct ufs_hba *hba, const char *name,
+struct clk **clk)
+{
+ int ret;
+
+ ret = ufs_mtk_get_host_clk(hba->dev, name, clk);
+ if (ret) {
+ dev_info(hba->dev, "%s: failed to get %s: %d", __func__,
+name, ret);
+ }
+
+ return ret;
+}
+
+static void ufs_mtk_init_host_caps(struct ufs_hba *hba)
+{
+ struct ufs_mtk_host *host = ufshcd_get_variant(hba);
+ struct ufs_mtk_crypt_cfg *cfg;
+ struct device *dev = hba->dev;
+ struct regulator *reg;
+
+ host->caps = host->cfg->caps;
+
+ if (!ufs_mtk_is_boost_crypt_enabled(hba))
+ return;
+
+ host->crypt = devm_kzalloc(dev, sizeof(*(host->crypt)),
+ GFP_KERNEL);
+ if (!host->crypt)
+ goto
[PATCH] ARM: imx7ulp: enable cpufreq
From: Peng Fan
Enable cpufreq for i.MX7ULP when imx cpufreq dt driver enabled.
Signed-off-by: Peng Fan
---
arch/arm/mach-imx/mach-imx7ulp.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/mach-imx/mach-imx7ulp.c b/arch/arm/mach-imx/mach-imx7ulp.c
index 128cf4c92aab..445256e6a4a0 100644
--- a/arch/arm/mach-imx/mach-imx7ulp.c
+++ b/arch/arm/mach-imx/mach-imx7ulp.c
@@ -67,6 +67,9 @@ static const char *const imx7ulp_dt_compat[] __initconst = {
static void __init imx7ulp_init_late(void)
{
+ if (IS_ENABLED(CONFIG_ARM_IMX_CPUFREQ_DT))
+ platform_device_register_simple("imx-cpufreq-dt", -1, NULL, 0);
+
imx7ulp_cpuidle_init();
}
--
2.28.0
[PATCH v2 2/2] dt-bindings: ufs-mediatek: Add mt8192-ufshci compatible string
Add "mediatek,mt8192-ufshci" compatible string to for MediaTek UFS host controller present on MT8192 chipsets. Signed-off-by: Stanley Chu --- Documentation/devicetree/bindings/ufs/ufs-mediatek.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/ufs/ufs-mediatek.txt b/Documentation/devicetree/bindings/ufs/ufs-mediatek.txt index 72aab8547308..63a953b672d2 100644 --- a/Documentation/devicetree/bindings/ufs/ufs-mediatek.txt +++ b/Documentation/devicetree/bindings/ufs/ufs-mediatek.txt @@ -9,7 +9,9 @@ contain a phandle reference to UFS M-PHY node. Required properties for UFS nodes: - compatible : Compatible list, contains the following controller: "mediatek,mt8183-ufshci" for MediaTek UFS host controller - present on MT81xx chipsets. + present on MT8183 chipsets. + "mediatek,mt8192-ufshci" for MediaTek UFS host controller + present on MT8192 chipsets. - reg: Address and length of the UFS register set. - phys : phandle to m-phy. - clocks : List of phandle and clock specifier pairs. -- 2.18.0
Re: [PATCH v18 06/32] mm/thp: narrow lru locking
在 2020/9/10 下午9:49, Matthew Wilcox 写道:
> On Mon, Aug 24, 2020 at 08:54:39PM +0800, Alex Shi wrote:
>> lru_lock and page cache xa_lock have no reason with current sequence,
>> put them together isn't necessary. let's narrow the lru locking, but
>> left the local_irq_disable to block interrupt re-entry and statistic update.
>
> What stats are you talking about here?
Hi Matthew,
Thanks for comments!
like __dec_node_page_state(head, NR_SHMEM_THPS); will have preemptive warning...
>
>> +++ b/mm/huge_memory.c
>> @@ -2397,7 +2397,7 @@ static void __split_huge_page_tail(struct page *head,
>> int tail,
>> }
>>
>> static void __split_huge_page(struct page *page, struct list_head *list,
>> -pgoff_t end, unsigned long flags)
>> + pgoff_t end)
>
> Please don't change this whitespace. It's really annoying having to
> adjust the whitespace when renaming a function. Just two tabs indentation
> to give a clear separation of arguments from code is fine.
>
>
> How about this patch instead? It occurred to me we already have
> perfectly good infrastructure to track whether or not interrupts are
> already disabled, and so we should use that instead of ensuring that
> interrupts are disabled, or tracking that ourselves.
So your proposal looks like;
1, xa_lock_irq(>i_pages); (optional)
2, spin_lock_irqsave(_queue->split_queue_lock, flags);
3, spin_lock_irqsave(>lru_lock, flags);
Is there meaningful for the 2nd and 3rd flags?
IIRC, I had a similar proposal as your, the flags used in xa_lock_irqsave(),
but objected by Hugh.
Thanks
Alex
>
> But I may have missed something else that's relying on having
> interrupts disabled. Please check carefully.
>
> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> index 2ccff8472cd4..74cae6c032f9 100644
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -2376,17 +2376,16 @@ static void __split_huge_page_tail(struct page *head,
> int tail,
> }
>
> static void __split_huge_page(struct page *page, struct list_head *list,
> - pgoff_t end, unsigned long flags)
> + pgoff_t end)
> {
> struct page *head = compound_head(page);
> pg_data_t *pgdat = page_pgdat(head);
> struct lruvec *lruvec;
> struct address_space *swap_cache = NULL;
> unsigned long offset = 0;
> + unsigned long flags;
> int i;
>
> - lruvec = mem_cgroup_page_lruvec(head, pgdat);
> -
> /* complete memcg works before add pages to LRU */
> mem_cgroup_split_huge_fixup(head);
>
> @@ -2395,9 +2394,13 @@ static void __split_huge_page(struct page *page,
> struct list_head *list,
>
> offset = swp_offset(entry);
> swap_cache = swap_address_space(entry);
> - xa_lock(_cache->i_pages);
> + xa_lock_irq(_cache->i_pages);
> }
>
> + /* prevent PageLRU to go away from under us, and freeze lru stats */
> + spin_lock_irqsave(>lru_lock, flags);
> + lruvec = mem_cgroup_page_lruvec(head, pgdat);
> +
> for (i = HPAGE_PMD_NR - 1; i >= 1; i--) {
> __split_huge_page_tail(head, i, lruvec, list);
> /* Some pages can be beyond i_size: drop them from page cache */
> @@ -2417,6 +2420,7 @@ static void __split_huge_page(struct page *page, struct
> list_head *list,
> }
>
> ClearPageCompound(head);
> + spin_unlock_irqrestore(>lru_lock, flags);
>
> split_page_owner(head, HPAGE_PMD_ORDER);
>
> @@ -2425,18 +2429,16 @@ static void __split_huge_page(struct page *page,
> struct list_head *list,
> /* Additional pin to swap cache */
> if (PageSwapCache(head)) {
> page_ref_add(head, 2);
> - xa_unlock(_cache->i_pages);
> + xa_unlock_irq(_cache->i_pages);
> } else {
> page_ref_inc(head);
> }
> } else {
> /* Additional pin to page cache */
> page_ref_add(head, 2);
> - xa_unlock(>mapping->i_pages);
> + xa_unlock_irq(>mapping->i_pages);
> }
>
> - spin_unlock_irqrestore(>lru_lock, flags);
> -
> remap_page(head);
>
> for (i = 0; i < HPAGE_PMD_NR; i++) {
> @@ -2574,7 +2576,6 @@ bool can_split_huge_page(struct page *page, int
> *pextra_pins)
> int split_huge_page_to_list(struct page *page, struct list_head *list)
> {
> struct page *head = compound_head(page);
> - struct pglist_data *pgdata = NODE_DATA(page_to_nid(head));
> struct deferred_split *ds_queue = get_deferred_split_queue(head);
> struct anon_vma *anon_vma = NULL;
> struct address_space *mapping = NULL;
> @@ -2640,9 +2641,6 @@ int split_huge_page_to_list(struct page *page, struct
> list_head *list)
> unmap_page(head);
> VM_BUG_ON_PAGE(compound_mapcount(head), head);
>
> - /* prevent PageLRU to go away from under us, and freeze lru stats */
> -
[PATCH 4/4] ARM: imx: cpuidle-imx7ulp: Stop mode disallowed when HSRUN
From: Peng Fan
When cpu runs in HSRUN mode, cpuidle is not allowed to run into
Stop mode. So add imx7ulp_get_mode to get thr cpu run mode,
and use WAIT mode instead, when cpu in HSRUN mode.
Signed-off-by: Peng Fan
---
arch/arm/mach-imx/common.h | 1 +
arch/arm/mach-imx/cpuidle-imx7ulp.c | 14 +++---
arch/arm/mach-imx/pm-imx7ulp.c | 10 ++
3 files changed, 22 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-imx/common.h b/arch/arm/mach-imx/common.h
index 72c3fcc32910..707ac650f1c2 100644
--- a/arch/arm/mach-imx/common.h
+++ b/arch/arm/mach-imx/common.h
@@ -103,6 +103,7 @@ void imx6_set_int_mem_clk_lpm(bool enable);
void imx6sl_set_wait_clk(bool enter);
int imx_mmdc_get_ddr_type(void);
int imx7ulp_set_lpm(enum ulp_cpu_pwr_mode mode);
+u32 imx7ulp_get_mode(void);
void imx_cpu_die(unsigned int cpu);
int imx_cpu_kill(unsigned int cpu);
diff --git a/arch/arm/mach-imx/cpuidle-imx7ulp.c
b/arch/arm/mach-imx/cpuidle-imx7ulp.c
index ca86c967d19e..e7009d10b331 100644
--- a/arch/arm/mach-imx/cpuidle-imx7ulp.c
+++ b/arch/arm/mach-imx/cpuidle-imx7ulp.c
@@ -15,10 +15,18 @@
static int imx7ulp_enter_wait(struct cpuidle_device *dev,
struct cpuidle_driver *drv, int index)
{
- if (index == 1)
+ u32 mode;
+
+ if (index == 1) {
imx7ulp_set_lpm(ULP_PM_WAIT);
- else
- imx7ulp_set_lpm(ULP_PM_STOP);
+ } else {
+ mode = imx7ulp_get_mode();
+
+ if (mode == 3)
+ imx7ulp_set_lpm(ULP_PM_WAIT);
+ else
+ imx7ulp_set_lpm(ULP_PM_STOP);
+ }
cpu_do_idle();
diff --git a/arch/arm/mach-imx/pm-imx7ulp.c b/arch/arm/mach-imx/pm-imx7ulp.c
index 543ac69f5f70..eb1578f0bfa5 100644
--- a/arch/arm/mach-imx/pm-imx7ulp.c
+++ b/arch/arm/mach-imx/pm-imx7ulp.c
@@ -63,6 +63,16 @@ int imx7ulp_set_lpm(enum ulp_cpu_pwr_mode mode)
return 0;
}
+u32 imx7ulp_get_mode(void)
+{
+ u32 mode;
+
+ mode = readl_relaxed(smc1_base + SMC_PMCTRL) & BM_PMCTRL_RUNM;
+ mode >>= BP_PMCTRL_RUNM;
+
+ return mode;
+}
+
void __init imx7ulp_pm_init(void)
{
struct device_node *np;
--
2.28.0
Re: [PATCH V2 3/4] perf stat: Support new per thread TopDown metrics
Hello,
On Thu, Sep 10, 2020 at 10:48 PM wrote:
>
> From: Andi Kleen
>
> Icelake has support for reporting per thread TopDown metrics.
> These are reported differently than the previous TopDown support,
> each metric is standalone, but scaled to pipeline "slots".
> We don't need to do anything special for HyperThreading anymore.
> Teach perf stat --topdown to handle these new metrics and
> print them in the same way as the previous TopDown metrics.
> The restrictions of only being able to report information per core is
> gone.
>
> Acked-by: Jiri Olsa
> Co-developed-by: Kan Liang
> Signed-off-by: Kan Liang
> Signed-off-by: Andi Kleen
> ---
> tools/perf/Documentation/perf-stat.txt | 7 +-
> tools/perf/builtin-stat.c | 30 -
> tools/perf/util/stat-shadow.c | 89 ++
> tools/perf/util/stat.c | 4 ++
> tools/perf/util/stat.h | 8 +++
> 5 files changed, 134 insertions(+), 4 deletions(-)
>
> diff --git a/tools/perf/Documentation/perf-stat.txt
> b/tools/perf/Documentation/perf-stat.txt
> index c9bfefc051fb..e803dbdc88a8 100644
> --- a/tools/perf/Documentation/perf-stat.txt
> +++ b/tools/perf/Documentation/perf-stat.txt
> @@ -357,6 +357,11 @@ if the workload is actually bound by the CPU and not by
> something else.
> For best results it is usually a good idea to use it with interval
> mode like -I 1000, as the bottleneck of workloads can change often.
>
> +This enables --metric-only, unless overridden with --no-metric-only.
> +
> +The following restrictions only apply to older Intel CPUs and Atom,
> +on newer CPUs (IceLake and later) TopDown can be collected for any thread:
> +
> The top down metrics are collected per core instead of per
> CPU thread. Per core mode is automatically enabled
> and -a (global monitoring) is needed, requiring root rights or
> @@ -368,8 +373,6 @@ echo 0 > /proc/sys/kernel/nmi_watchdog
> for best results. Otherwise the bottlenecks may be inconsistent
> on workload with changing phases.
>
> -This enables --metric-only, unless overridden with --no-metric-only.
> -
> To interpret the results it is usually needed to know on which
> CPUs the workload runs on. If needed the CPUs can be forced using
> taskset.
> diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
> index 5583e22ca808..6290da5bd142 100644
> --- a/tools/perf/builtin-stat.c
> +++ b/tools/perf/builtin-stat.c
> @@ -128,6 +128,15 @@ static const char * topdown_attrs[] = {
> NULL,
> };
>
> +static const char *topdown_metric_attrs[] = {
> + "slots",
> + "topdown-retiring",
> + "topdown-bad-spec",
> + "topdown-fe-bound",
> + "topdown-be-bound",
> + NULL,
> +};
> +
> static const char *smi_cost_attrs = {
> "{"
> "msr/aperf/,"
> @@ -1691,6 +1700,24 @@ static int add_default_attributes(void)
> char *str = NULL;
> bool warn = false;
>
> + if (!force_metric_only)
> + stat_config.metric_only = true;
> +
> + if (topdown_filter_events(topdown_metric_attrs, , 1) < 0)
> {
> + pr_err("Out of memory\n");
> + return -1;
> + }
> + if (topdown_metric_attrs[0] && str) {
> + if (!stat_config.interval &&
> !stat_config.metric_only) {
> + fprintf(stat_config.output,
> + "Topdown accuracy may decrease when
> measuring long periods.\n"
> + "Please print the result regularly,
> e.g. -I1000\n");
> + }
> + goto setup_metrics;
> + }
> +
> + str = NULL;
zfree() ?
Thanks
Namhyung
> +
> if (stat_config.aggr_mode != AGGR_GLOBAL &&
> stat_config.aggr_mode != AGGR_CORE) {
> pr_err("top down event configuration requires
> --per-core mode\n");
> @@ -1702,8 +1729,6 @@ static int add_default_attributes(void)
> return -1;
> }
>
> - if (!force_metric_only)
> - stat_config.metric_only = true;
> if (topdown_filter_events(topdown_attrs, ,
> arch_topdown_check_group()) < 0) {
> pr_err("Out of memory\n");
> @@ -1712,6 +1737,7 @@ static int add_default_attributes(void)
> if (topdown_attrs[0] && str) {
> if (warn)
> arch_topdown_group_warn();
> +setup_metrics:
> err = parse_events(evsel_list, str, );
> if (err) {
> fprintf(stderr,
[PATCH 3/4] ARM: imx: imx7ulp: support HSRUN mode
From: Peng Fan
Configure PMPROT to let ARM core could run into HSRUN mode.
In LDO-enabled mode, HSRUN mode is not allowed, so add a check before
configure PMPROT.
Signed-off-by: Peng Fan
---
arch/arm/mach-imx/pm-imx7ulp.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/arch/arm/mach-imx/pm-imx7ulp.c b/arch/arm/mach-imx/pm-imx7ulp.c
index 2e756d8191fa..543ac69f5f70 100644
--- a/arch/arm/mach-imx/pm-imx7ulp.c
+++ b/arch/arm/mach-imx/pm-imx7ulp.c
@@ -11,6 +11,10 @@
#include "common.h"
+#define PMC0_CTRL 0x28
+#define BM_CTRL_LDOEN BIT(31)
+
+#define SMC_PMPROT 0x8
#define SMC_PMCTRL 0x10
#define BP_PMCTRL_PSTOPO16
#define PSTOPO_PSTOP3 0x3
@@ -25,7 +29,10 @@
#define BM_PMCTRL_RUNM (3 << BP_PMCTRL_RUNM)
#define BM_PMCTRL_STOPM(7 << BP_PMCTRL_STOPM)
+#define BM_PMPROT_AHSRUN BIT(7)
+
static void __iomem *smc1_base;
+static void __iomem *pmc0_base;
int imx7ulp_set_lpm(enum ulp_cpu_pwr_mode mode)
{
@@ -65,5 +72,13 @@ void __init imx7ulp_pm_init(void)
of_node_put(np);
WARN_ON(!smc1_base);
+ np = of_find_compatible_node(NULL, NULL, "fsl,imx7ulp-pmc-m4");
+ pmc0_base = of_iomap(np, 0);
+ WARN_ON(!pmc0_base);
+ of_node_put(np);
+
+ if (!(readl_relaxed(pmc0_base + PMC0_CTRL) & BM_CTRL_LDOEN))
+ writel_relaxed(BM_PMPROT_AHSRUN, smc1_base + SMC_PMPROT);
+
imx7ulp_set_lpm(ULP_PM_RUN);
}
--
2.28.0
[PATCH 2/4] ARM: dts: imx7ulp: add pmc node
From: Peng Fan
Add i.MX7ULP pmc node for m4 and a7.
Signed-off-by: Peng Fan
---
arch/arm/boot/dts/imx7ulp.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/imx7ulp.dtsi b/arch/arm/boot/dts/imx7ulp.dtsi
index b7ea37ad4e55..d5d67e3db123 100644
--- a/arch/arm/boot/dts/imx7ulp.dtsi
+++ b/arch/arm/boot/dts/imx7ulp.dtsi
@@ -286,6 +286,11 @@ pcc2: clock-controller@403f {
assigned-clock-parents = <
IMX7ULP_CLK_SOSC_BUS_CLK>;
};
+ pmc1: pmc-a7@4040 {
+ compatible = "fsl,imx7ulp-pmc-a7";
+ reg = <0x4040 0x1000>;
+ };
+
smc1: clock-controller@4041 {
compatible = "fsl,imx7ulp-smc1";
reg = <0x4041 0x1000>;
@@ -447,6 +452,11 @@ m4aips1: bus@4108 {
reg = <0x4108 0x8>;
ranges;
+ pmc0: pmc-m4@410a1000 {
+ compatible = "fsl,imx7ulp-pmc-m4";
+ reg = <0x410a1000 0x1000>;
+ };
+
sim: sim@410a3000 {
compatible = "fsl,imx7ulp-sim", "syscon";
reg = <0x410a3000 0x1000>;
--
2.28.0
[PATCH 1/4] dt-bindings: fsl: add i.MX7ULP PMC binding doc
From: Peng Fan
Add i.MX7ULP Power Management Controller binding doc
Signed-off-by: Peng Fan
---
.../bindings/arm/freescale/imx7ulp-pmc.yaml | 33 +++
1 file changed, 33 insertions(+)
create mode 100644
Documentation/devicetree/bindings/arm/freescale/imx7ulp-pmc.yaml
diff --git a/Documentation/devicetree/bindings/arm/freescale/imx7ulp-pmc.yaml
b/Documentation/devicetree/bindings/arm/freescale/imx7ulp-pmc.yaml
new file mode 100644
index ..33a31d87dd62
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/freescale/imx7ulp-pmc.yaml
@@ -0,0 +1,33 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/freescale/imx7ulp-pmc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: i.MX7ULP Power Management Controller(PMC) Device Tree Bindings
+
+maintainers:
+ - Peng Fan
+
+properties:
+ compatible:
+items:
+ - enum:
+ - fsl,imx7ulp-pmc-m4
+ - fsl,imx7ulp-pmc-a7
+
+ reg:
+maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+pmc0: pmc-m4@410a1000 {
+compatible = "fsl,imx7ulp-pmc-m4";
+reg = <0x410a1000 0x1000>;
+};
--
2.28.0
[PATCH v2 0/2] scsi: ufs-mediatek: Support performance mode for inline encryption engine
Hi Martin, Rob, Avri, This series adds high-performance mode support for MediaTek UFS inline encryption engine. This feature is only required in specific platforms, i.e., MT8192 series. Please help consider this patch set in kernel v5.10. Thanks. Changes since v1: - Remove unnecessary printf. Stanley Chu (2): scsi: ufs-mediatek: Support performance mode for inline encryption engine dt-bindings: ufs-mediatek: Add mt8192-ufshci compatible string .../devicetree/bindings/ufs/ufs-mediatek.txt | 4 +- drivers/scsi/ufs/ufs-mediatek.c | 176 +- drivers/scsi/ufs/ufs-mediatek.h | 22 +++ 3 files changed, 195 insertions(+), 7 deletions(-) -- 2.18.0
[PATCH 0/4] imx: support i.MX7ULP HSRUN mode
From: Peng Fan This patchset is to add HSRUN mode support. Patch 1,2 is to add binding doc and dts node Patch 3 is to support HSRUN mode Patch 4 is to use wait mode when HSRUN working per hardware state machine requirement. Peng Fan (4): dt-bindings: fsl: add i.MX7ULP PMC binding doc ARM: dts: imx7ulp: add pmc node ARM: imx: imx7ulp: support HSRUN mode ARM: imx: cpuidle-imx7ulp: Stop mode disallowed when HSRUN .../bindings/arm/freescale/imx7ulp-pmc.yaml | 33 +++ arch/arm/boot/dts/imx7ulp.dtsi| 10 ++ arch/arm/mach-imx/common.h| 1 + arch/arm/mach-imx/cpuidle-imx7ulp.c | 14 ++-- arch/arm/mach-imx/pm-imx7ulp.c| 25 ++ 5 files changed, 80 insertions(+), 3 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/freescale/imx7ulp-pmc.yaml -- 2.28.0
Re: [PATCH 2/3] mmc: sdhci-of-aspeed: Expose data sample phase delay tuning
On Fri, 11 Sep 2020 at 02:49, Andrew Jeffery wrote:
>
>
>
> On Fri, 11 Sep 2020, at 11:32, Joel Stanley wrote:
> > On Thu, 10 Sep 2020 at 10:55, Andrew Jeffery wrote:
> > >
> > > Allow sample phase adjustment to deal with layout or tolerance issues.
> > >
> > > Signed-off-by: Andrew Jeffery
> > > ---
> > > drivers/mmc/host/sdhci-of-aspeed.c | 137 +++--
> > > 1 file changed, 132 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/drivers/mmc/host/sdhci-of-aspeed.c
> > > b/drivers/mmc/host/sdhci-of-aspeed.c
> > > index 4f008ba3280e..641accbfcde4 100644
> > > --- a/drivers/mmc/host/sdhci-of-aspeed.c
> > > +++ b/drivers/mmc/host/sdhci-of-aspeed.c
> > > +static void
> > > +aspeed_sdc_configure_phase(struct aspeed_sdc *sdc,
> > > + const struct aspeed_sdhci_phase_desc *phase,
> > > + uint8_t value, bool enable)
> > > +{
> > > + u32 reg;
> > > +
> > > + spin_lock(>lock);
> >
> > What is the lock protecting against?
> >
> > We call this in the ->probe, so there should be no concurrent access going
> > on.
>
> Because the register is in the "global" part of the SD/MMC controller address
> space (it's not part of the SDHCI), and there are multiple slots that may have
> a driver probed concurrently.
That points to having the property be part of the "global" device tree
node. This would simplify the code; you wouldn't need the locking
either.
>
> >
> >
> > > + reg = readl(sdc->regs + ASPEED_SDC_PHASE);
> > > + reg &= ~phase->enable_mask;
> > > + if (enable) {
> > > + reg &= ~phase->value_mask;
> > > + reg |= value << __ffs(phase->value_mask);
> > > + reg |= phase->enable_value << __ffs(phase->enable_mask);
> > > + }
> > > + writel(reg, sdc->regs + ASPEED_SDC_PHASE);
> > > + spin_unlock(>lock);
> > > +}
> > > +
> > > static void aspeed_sdhci_set_clock(struct sdhci_host *host, unsigned int
> > > clock)
> > > {
> > > struct sdhci_pltfm_host *pltfm_host;
> > > @@ -155,8 +195,58 @@ static inline int aspeed_sdhci_calculate_slot(struct
> > > aspeed_sdhci *dev,
> > > return (delta / 0x100) - 1;
> > > }
> > >
> > > +static int aspeed_sdhci_configure_of(struct platform_device *pdev,
> > > +struct aspeed_sdhci *sdhci)
> > > +{
> > > + u32 iphase, ophase;
> > > + struct device_node *np;
> > > + struct device *dev;
> > > + int ret;
> > > +
> > > + if (!sdhci->phase)
> > > + return 0;
> > > +
> > > + dev = >dev;
> > > + np = dev->of_node;
> > > +
> > > + ret = of_property_read_u32(np, "aspeed,input-phase", );
> > > + if (ret < 0) {
> > > + aspeed_sdc_configure_phase(sdhci->parent,
> > > >phase->in, 0,
> > > + false);
> >
> > Will this clear any value that eg. u-boot writes?
>
> No, see the 'enable' test in aspeed_sdc_configure_phase()
OK, so this branch will never cause any change in the register? Best
to drop it then.
>
> >
> > The register should be left alone if the kernel doesn't have a
> > configuration of it's own, otherwise we may end up breaking an
> > otherwise working system.
>
> Right, I can rework that.
[PATCH] i3c: master: Fix error return in cdns_i3c_master_probe()
Fix to return negative error code -ENOMEM from the error handling
case instead of 0.
Signed-off-by: Jing Xiangfeng
---
drivers/i3c/master/i3c-master-cdns.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/i3c/master/i3c-master-cdns.c
b/drivers/i3c/master/i3c-master-cdns.c
index 3fee8bd7fe20..3f2226928fe0 100644
--- a/drivers/i3c/master/i3c-master-cdns.c
+++ b/drivers/i3c/master/i3c-master-cdns.c
@@ -1635,8 +1635,10 @@ static int cdns_i3c_master_probe(struct platform_device
*pdev)
master->ibi.slots = devm_kcalloc(>dev, master->ibi.num_slots,
sizeof(*master->ibi.slots),
GFP_KERNEL);
- if (!master->ibi.slots)
+ if (!master->ibi.slots) {
+ ret = -ENOMEM;
goto err_disable_sysclk;
+ }
writel(IBIR_THR(1), master->regs + CMD_IBI_THR_CTRL);
writel(MST_INT_IBIR_THR, master->regs + MST_IER);
--
2.17.1
[tip:master] BUILD SUCCESS 6bbdfd0731d82a4fc01877079d93ccb32fb0b593
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git master branch HEAD: 6bbdfd0731d82a4fc01877079d93ccb32fb0b593 Merge branch 'linus' elapsed time: 721m configs tested: 139 configs skipped: 5 The following configs have been built successfully. More configs may be tested in the coming days. gcc tested configs: arm defconfig arm64allyesconfig arm64 defconfig arm allyesconfig arm allmodconfig arm cm_x300_defconfig powerpc maple_defconfig openrisc alldefconfig shtitan_defconfig ia64generic_defconfig arm davinci_all_defconfig sh apsh4a3a_defconfig arc nsimosci_hs_smp_defconfig arm cns3420vb_defconfig sparc64 defconfig arm lpc18xx_defconfig mips ip27_defconfig arm zx_defconfig sh sdk7786_defconfig powerpc rainier_defconfig sh sh2007_defconfig arm stm32_defconfig powerpc bamboo_defconfig shshmin_defconfig arm ebsa110_defconfig c6xevmc6457_defconfig m68kq40_defconfig arm u8500_defconfig powerpc mpc8272_ads_defconfig powerpcmpc7448_hpc2_defconfig armu300_defconfig arm efm32_defconfig arm omap1_defconfig c6xevmc6472_defconfig arm lpd270_defconfig arm corgi_defconfig powerpcfsp2_defconfig arm badge4_defconfig mipsgpr_defconfig microblaze mmu_defconfig armshmobile_defconfig xtensa common_defconfig powerpc pmac32_defconfig shsh7785lcr_defconfig riscv rv32_defconfig mips rt305x_defconfig sh kfr2r09_defconfig mipse55_defconfig ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig m68k allyesconfig nios2 defconfig arc allyesconfig nds32 allnoconfig c6x allyesconfig nds32 defconfig nios2allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig arc defconfig sh allmodconfig parisc defconfig s390 allyesconfig parisc allyesconfig s390defconfig i386 allyesconfig sparcallyesconfig sparc defconfig i386defconfig mips allyesconfig mips allmodconfig powerpc defconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig x86_64 randconfig-a004-20200909 x86_64 randconfig-a006-20200909 x86_64 randconfig-a003-20200909 x86_64 randconfig-a001-20200909 x86_64 randconfig-a005-20200909 x86_64 randconfig-a002-20200909 i386 randconfig-a004-20200911 i386 randconfig-a006-20200911 i386 randconfig-a001-20200911 i386 randconfig-a003-20200911 i386 randconfig-a002-20200911 i386 randconfig-a005-20200911 i386 randconfig-a004-20200910 i386 randconfig-a006-20200910 i386 randconfig-a001-20200910 i386 randconfig-a003-20200910 i386 randconfig-a002-20200910 i386 randconfig-a005-20200910 i386 randconfig-a004-20200909 i386 randconfig-a005-20200909 i386
Re: [PATCH v3] cypto: mediatek - fix leaks in mtk_desc_ring_alloc
On Fri, Sep 11, 2020 at 09:36:19AM +0800, Xiaoliang Pang wrote:
>
> diff --git a/drivers/crypto/mediatek/mtk-platform.c
> b/drivers/crypto/mediatek/mtk-platform.c
> index 7e3ad085b5bd..ebb3bdef0dbe 100644
> --- a/drivers/crypto/mediatek/mtk-platform.c
> +++ b/drivers/crypto/mediatek/mtk-platform.c
> @@ -469,13 +469,13 @@ static int mtk_desc_ring_alloc(struct mtk_cryp *cryp)
> return 0;
>
> err_cleanup:
> - for (; i--; ) {
> + do {
> dma_free_coherent(cryp->dev, MTK_DESC_RING_SZ,
> ring[i]->res_base, ring[i]->res_dma);
> dma_free_coherent(cryp->dev, MTK_DESC_RING_SZ,
> ring[i]->cmd_base, ring[i]->cmd_dma);
> kfree(ring[i]);
> - }
> + }while(i--);
Please add spaces before and after while.
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [v4,0/5] watchdog: mt8192: add wdt support
Matthias, Guenter, These patches have all been reviewed (apart from fairly trivial 2/5), which maintainer should be picking those up? Thanks! On Mon, Aug 3, 2020 at 3:15 PM Crystal Guo wrote: > > v4 changes: > revise commit messages. > > v3 changes: > https://patchwork.kernel.org/patch/11692731/ > https://patchwork.kernel.org/patch/11692767/ > https://patchwork.kernel.org/patch/11692729/ > https://patchwork.kernel.org/patch/11692771/ > https://patchwork.kernel.org/patch/11692733/ > > Crystal Guo (5): > dt-binding: mediatek: watchdog: fix the description of compatible > arm64: dts: mt8183: update watchdog device node > dt-binding: mediatek: mt8192: update mtk-wdt document > dt-binding: mt8192: add toprgu reset-controller head file > watchdog: mt8192: add wdt support > > .../devicetree/bindings/watchdog/mtk-wdt.txt | 5 ++-- > arch/arm64/boot/dts/mediatek/mt8183.dtsi | 3 +- > drivers/watchdog/mtk_wdt.c| 6 > .../reset-controller/mt8192-resets.h | 30 +++ > 4 files changed, 40 insertions(+), 4 deletions(-) > create mode 100644 include/dt-bindings/reset-controller/mt8192-resets.h > >
[PATCH 1/2] scsi: ufs-mediatek: Support performance mode for inline encryption engine
Some MediaTek UFS platforms support high-performance mode that inline
encryption engine can be boosted while UFS is not clock-gated.
The high-performance mode will be enabled if all below conditions are
well-declaired in device tree,
1. Proper platform-specific compatible string which enables the host
capability "UFS_MTK_CAP_BOOST_CRYPT_ENGINE".
2. "dvfsrc-vcore" node is available in this platform.
3. Clock mux and clock parents of inline encryption engine for both
"low-power mode" and "high-performance mode".
Signed-off-by: Stanley Chu
---
drivers/scsi/ufs/ufs-mediatek.c | 178 ++--
drivers/scsi/ufs/ufs-mediatek.h | 22
2 files changed, 194 insertions(+), 6 deletions(-)
diff --git a/drivers/scsi/ufs/ufs-mediatek.c b/drivers/scsi/ufs/ufs-mediatek.c
index 3ec44dfa2567..f6250b54f0a0 100644
--- a/drivers/scsi/ufs/ufs-mediatek.c
+++ b/drivers/scsi/ufs/ufs-mediatek.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -44,6 +45,28 @@ static struct ufs_dev_fix ufs_mtk_dev_fixups[] = {
END_FIX
};
+static const struct ufs_mtk_host_cfg ufs_mtk_mt8192_cfg = {
+ .caps = UFS_MTK_CAP_BOOST_CRYPT_ENGINE,
+};
+
+static const struct of_device_id ufs_mtk_of_match[] = {
+ {
+ .compatible = "mediatek,mt8183-ufshci",
+ },
+ {
+ .compatible = "mediatek,mt8192-ufshci",
+ .data = _mtk_mt8192_cfg
+ },
+ {},
+};
+
+static bool ufs_mtk_is_boost_crypt_enabled(struct ufs_hba *hba)
+{
+ struct ufs_mtk_host *host = ufshcd_get_variant(hba);
+
+ return (host->caps & UFS_MTK_CAP_BOOST_CRYPT_ENGINE);
+}
+
static void ufs_mtk_cfg_unipro_cg(struct ufs_hba *hba, bool enable)
{
u32 tmp;
@@ -294,6 +317,139 @@ static void ufs_mtk_mphy_power_on(struct ufs_hba *hba,
bool on)
host->mphy_powered_on = on;
}
+static int ufs_mtk_get_host_clk(struct device *dev, const char *name,
+ struct clk **clk_out)
+{
+ struct clk *clk;
+ int err = 0;
+
+ clk = devm_clk_get(dev, name);
+ if (IS_ERR(clk))
+ err = PTR_ERR(clk);
+ else
+ *clk_out = clk;
+
+ return err;
+}
+
+static void ufs_mtk_boost_crypt(struct ufs_hba *hba, bool boost)
+{
+ struct ufs_mtk_host *host = ufshcd_get_variant(hba);
+ struct ufs_mtk_crypt_cfg *cfg;
+ struct regulator *reg;
+ int volt, ret;
+
+ if (!ufs_mtk_is_boost_crypt_enabled(hba))
+ return;
+
+ cfg = host->crypt;
+ volt = cfg->vcore_volt;
+ reg = cfg->reg_vcore;
+
+ ret = clk_prepare_enable(cfg->clk_crypt_mux);
+ if (ret) {
+ dev_info(hba->dev, "clk_prepare_enable(): %d\n",
+ret);
+ return;
+ }
+
+ if (boost) {
+ ret = regulator_set_voltage(reg, volt, INT_MAX);
+ if (ret) {
+ dev_info(hba->dev,
+"failed to set vcore to %d\n", volt);
+ goto out;
+ }
+
+ ret = clk_set_parent(cfg->clk_crypt_mux,
+cfg->clk_crypt_perf);
+ if (ret) {
+ dev_info(hba->dev,
+"failed to set clk_crypt_perf\n");
+ regulator_set_voltage(reg, 0, INT_MAX);
+ goto out;
+ }
+ } else {
+ ret = clk_set_parent(cfg->clk_crypt_mux,
+cfg->clk_crypt_lp);
+ if (ret) {
+ dev_info(hba->dev,
+"failed to set clk_crypt_lp\n");
+ goto out;
+ }
+
+ ret = regulator_set_voltage(reg, 0, INT_MAX);
+ if (ret) {
+ dev_info(hba->dev,
+"failed to set vcore to MIN\n");
+ }
+ }
+out:
+ clk_disable_unprepare(cfg->clk_crypt_mux);
+
+ dev_info(hba->dev, "boost %d, %d\n", boost, ret);
+}
+
+static int ufs_mtk_init_host_clk(struct ufs_hba *hba, const char *name,
+struct clk **clk)
+{
+ int ret;
+
+ ret = ufs_mtk_get_host_clk(hba->dev, name, clk);
+ if (ret) {
+ dev_info(hba->dev, "%s: failed to get %s: %d", __func__,
+name, ret);
+ }
+
+ return ret;
+}
+
+static void ufs_mtk_init_host_caps(struct ufs_hba *hba)
+{
+ struct ufs_mtk_host *host = ufshcd_get_variant(hba);
+ struct ufs_mtk_crypt_cfg *cfg;
+ struct device *dev = hba->dev;
+ struct regulator *reg;
+
+ host->caps = host->cfg->caps;
+
+ if (!ufs_mtk_is_boost_crypt_enabled(hba))
+ return;
+
+ host->crypt = devm_kzalloc(dev, sizeof(*(host->crypt)),
+
[PATCH 0/2] scsi: ufs-mediatek: Support performance mode for inline encryption engine
Hi Martin, Rob, Avri, This series adds high-performance mode support for MediaTek UFS inline encryption engine. This feature is only required in specific platforms, i.e., MT8192 series. Please help consider this patch set in kernel v5.10. Thanks. Stanley Chu (2): scsi: ufs-mediatek: Support performance mode for inline encryption engine dt-bindings: ufs-mediatek: Add mt8192-ufshci compatible string .../devicetree/bindings/ufs/ufs-mediatek.txt | 4 +- drivers/scsi/ufs/ufs-mediatek.c | 178 +- drivers/scsi/ufs/ufs-mediatek.h | 22 +++ 3 files changed, 197 insertions(+), 7 deletions(-) -- 2.18.0
Re: [PATCH] iommu/amd: Fix potential @entry null deref
Thanks for catching this.
On 9/11/20 12:16 AM, Joao Martins wrote:
After commit 26e495f34107 ("iommu/amd: Restore IRTE.RemapEn bit after
programming IRTE"), smatch warns:
drivers/iommu/amd/iommu.c:3870 amd_iommu_deactivate_guest_mode()
warn: variable dereferenced before check 'entry' (see line 3867)
Fix this by moving the @valid assignment to after @entry has been checked
for NULL.
Cc: Suravee Suthikulpanit
Fixes: 26e495f34107 ("iommu/amd: Restore IRTE.RemapEn bit after programming
IRTE")
Reported-by: Dan Carpenter
Signed-off-by: Joao Martins
---
drivers/iommu/amd/iommu.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c
index 07ae8b93887e..8abe1c7ad45b 100644
--- a/drivers/iommu/amd/iommu.c
+++ b/drivers/iommu/amd/iommu.c
@@ -3864,12 +3864,14 @@ int amd_iommu_deactivate_guest_mode(void *data)
struct amd_ir_data *ir_data = (struct amd_ir_data *)data;
struct irte_ga *entry = (struct irte_ga *) ir_data->entry;
struct irq_cfg *cfg = ir_data->cfg;
- u64 valid = entry->lo.fields_remap.valid;
+ u64 valid;
if (!AMD_IOMMU_GUEST_IR_VAPIC(amd_iommu_guest_ir) ||
!entry || !entry->lo.fields_vapic.guest_mode)
return 0;
+ valid = entry->lo.fields_remap.valid;
+
entry->lo.val = 0;
entry->hi.val = 0;
Reviewed-by: Suravee Suthikulpanit
Suravee
[PATCH 2/2] dt-bindings: ufs-mediatek: Add mt8192-ufshci compatible string
Add "mediatek,mt8192-ufshci" compatible string to for MediaTek UFS host controller present on MT8192 chipsets. Signed-off-by: Stanley Chu --- Documentation/devicetree/bindings/ufs/ufs-mediatek.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/ufs/ufs-mediatek.txt b/Documentation/devicetree/bindings/ufs/ufs-mediatek.txt index 72aab8547308..63a953b672d2 100644 --- a/Documentation/devicetree/bindings/ufs/ufs-mediatek.txt +++ b/Documentation/devicetree/bindings/ufs/ufs-mediatek.txt @@ -9,7 +9,9 @@ contain a phandle reference to UFS M-PHY node. Required properties for UFS nodes: - compatible : Compatible list, contains the following controller: "mediatek,mt8183-ufshci" for MediaTek UFS host controller - present on MT81xx chipsets. + present on MT8183 chipsets. + "mediatek,mt8192-ufshci" for MediaTek UFS host controller + present on MT8192 chipsets. - reg: Address and length of the UFS register set. - phys : phandle to m-phy. - clocks : List of phandle and clock specifier pairs. -- 2.18.0
Re: [RFC PATCH] PCI/portdrv: No need to call pci_disable_device() during shutdown
On 09/11/2020 10:35 AM, Oliver O'Halloran wrote:
On Fri, Sep 11, 2020 at 11:55 AM Tiezhu Yang wrote:
On 09/11/2020 04:21 AM, Bjorn Helgaas wrote:
[+cc Huacai]
On Thu, Sep 10, 2020 at 02:41:39PM -0500, Bjorn Helgaas wrote:
On Sat, Sep 05, 2020 at 04:33:26PM +0800, Tiezhu Yang wrote:
After commit 745be2e700cd ("PCIe: portdrv: call pci_disable_device
during remove") and commit cc27b735ad3a ("PCI/portdrv: Turn off PCIe
services during shutdown"), it also calls pci_disable_device() during
shutdown, this seems unnecessary, so just remove it.
I would like to get rid of the portdrv completely by folding its
functionality into the PCI core itself, so there would be no portdrv
probe or remove.
Does this solve a problem?
Yes, sometimes it can not shutdown or reboot normally with
pci_disable_device().
Do you have any more details about what goes wrong here?
This issue is related with the operation "pci_command &=
~PCI_COMMAND_MASTER;"
in the following function:
drivers/pci/pci.c
static void do_pci_disable_device(struct pci_dev *dev)
{
u16 pci_command;
pci_read_config_word(dev, PCI_COMMAND, _command);
if (pci_command & PCI_COMMAND_MASTER) {
pci_command &= ~PCI_COMMAND_MASTER;
pci_write_config_word(dev, PCI_COMMAND, pci_command);
}
pcibios_disable_device(dev);
}
When remove "pci_command &= ~PCI_COMMAND_MASTER;", it can work well.
Leaving
devices enabled when actually shutting down probably doesn't matter.
Yes, I think so too.
However, .shutdown() is also used when kexec()ing into a new kernel
and we probably should be disabling devices before handing over to the
new kernel.
Is the real issue that we're closing the bridge windows before the
endpoint drivers have had a chance to clean up?
I notice that check kexec_in_progress first before call pci_disable_devie()
in pci_device_shutdown(), can we do the similar thing in pcie?
drivers/pci/pci-driver.c
static void pci_device_shutdown(struct device *dev)
{
struct pci_dev *pci_dev = to_pci_dev(dev);
struct pci_driver *drv = pci_dev->driver;
pm_runtime_resume(dev);
if (drv && drv->shutdown)
drv->shutdown(pci_dev);
/*
* If this is a kexec reboot, turn off Bus Master bit on the
* device to tell it to not continue to do DMA. Don't touch
* devices in D3cold or unknown states.
* If it is not a kexec reboot, firmware will hit the PCI
* devices with big hammer and stop their DMA any way.
*/
if (kexec_in_progress && (pci_dev->current_state <= PCI_D3hot))
pci_clear_master(pci_dev);
}
Something like this:
diff --git a/drivers/pci/pcie/portdrv_core.c
b/drivers/pci/pcie/portdrv_core.c
index 50a9522..3de1dab 100644
--- a/drivers/pci/pcie/portdrv_core.c
+++ b/drivers/pci/pcie/portdrv_core.c
@@ -491,7 +491,8 @@ void pcie_port_device_remove(struct pci_dev *dev)
{
device_for_each_child(>dev, NULL, remove_iter);
pci_free_irq_vectors(dev);
- pci_disable_device(dev);
+ if (kexec_in_progress && (pci_dev->current_state <= PCI_D3hot))
+ pci_disable_device(dev);
}
/**
Oliver
Re: [PATCH RFC tip/core/rcu 4/4] rcu-tasks: Shorten per-grace-period sleep for RCU Tasks Trace
On Thu, Sep 10, 2020 at 1:20 PM wrote: > > From: "Paul E. McKenney" > > The various RCU tasks flavors currently wait 100 milliseconds between each > grace period in order to prevent CPU-bound loops and to favor efficiency > over latency. However, RCU Tasks Trace needs to have a grace-period > latency of roughly 25 milliseconds, which is completely infeasible given > the 100-millisecond per-grace-period sleep. This commit therefore reduces > this sleep duration to 5 milliseconds (or one jiffy, whichever is longer) > in kernels built with CONFIG_TASKS_TRACE_RCU_READ_MB=y. The commit log is either misleading or wrong? If I read the code correctly in CONFIG_TASKS_TRACE_RCU_READ_MB=y case the existing HZ/10 "paranoid sleep" is preserved. It's for the MB=n case it is reduced to HZ/200. Also I don't understand why you're talking about milliseconds but all numbers are HZ based. HZ/10 gives different number of milliseconds depending on HZ.
RE: [PATCH RESEND v3 04/11] usb: xhci-rcar: convert to readl_poll_timeout_atomic()
Hi Daniel, Chunfeng,
> From: Chunfeng Yun, Sent: Friday, September 11, 2020 11:33 AM
>
> On Thu, 2020-09-10 at 14:12 +0100, Daniel Thompson wrote:
> > On Thu, Sep 10, 2020 at 04:21:45PM +0800, Chunfeng Yun wrote:
> > > Use readl_poll_timeout_atomic() to simplify code
> > >
> > > Cc: Mathias Nyman
> > > Cc: Yoshihiro Shimoda
> > > Signed-off-by: Chunfeng Yun
> > > ---
> > > v2~v3: no changes
> > > ---
> > > drivers/usb/host/xhci-rcar.c | 43
> > > ---
> > > 1 file changed, 12 insertions(+), 31 deletions(-)
> > >
> > > diff --git a/drivers/usb/host/xhci-rcar.c b/drivers/usb/host/xhci-rcar.c
> > > index c1025d3..74f836f 100644
> > > --- a/drivers/usb/host/xhci-rcar.c
> > > +++ b/drivers/usb/host/xhci-rcar.c
> > > @@ -6,6 +6,7 @@
> > > */
> > >
> > > #include
> > > +#include
> > > #include
> > > #include
> > > #include
> > > @@ -127,8 +128,7 @@ static int xhci_rcar_download_firmware(struct usb_hcd
> > > *hcd)
> > > void __iomem *regs = hcd->regs;
> > > struct xhci_plat_priv *priv = hcd_to_xhci_priv(hcd);
> > > const struct firmware *fw;
> > > - int retval, index, j, time;
> > > - int timeout = 1;
> > > + int retval, index, j;
> > > u32 data, val, temp;
> > > u32 quirks = 0;
> > > const struct soc_device_attribute *attr;
> > > @@ -166,32 +166,19 @@ static int xhci_rcar_download_firmware(struct
> > > usb_hcd *hcd)
> > > temp |= RCAR_USB3_DL_CTRL_FW_SET_DATA0;
> > > writel(temp, regs + RCAR_USB3_DL_CTRL);
> > >
> > > - for (time = 0; time < timeout; time++) {
> > > - val = readl(regs + RCAR_USB3_DL_CTRL);
> > > - if ((val & RCAR_USB3_DL_CTRL_FW_SET_DATA0) == 0)
> > > - break;
> > > - udelay(1);
> > > - }
> > > - if (time == timeout) {
> > > - retval = -ETIMEDOUT;
> > > + retval = readl_poll_timeout_atomic(regs + RCAR_USB3_DL_CTRL,
> > > + val, !(val & RCAR_USB3_DL_CTRL_FW_SET_DATA0),
> > > + 1, 1);
> > > + if (retval < 0)
> > > break;
> > > - }
> > > }
> > >
> > > temp = readl(regs + RCAR_USB3_DL_CTRL);
> > > temp &= ~RCAR_USB3_DL_CTRL_ENABLE;
> > > writel(temp, regs + RCAR_USB3_DL_CTRL);
> > >
> > > - for (time = 0; time < timeout; time++) {
> > > - val = readl(regs + RCAR_USB3_DL_CTRL);
> > > - if (val & RCAR_USB3_DL_CTRL_FW_SUCCESS) {
> > > - retval = 0;
> > > - break;
> > > - }
> > > - udelay(1);
> > > - }
> > > - if (time == timeout)
> > > - retval = -ETIMEDOUT;
> > > + retval = readl_poll_timeout_atomic((regs + RCAR_USB3_DL_CTRL),
> > > + val, (val & RCAR_USB3_DL_CTRL_FW_SUCCESS), 1, 1);
> >
> > Directly assigning to retval at this point will clobber a previous
> > -ETIMEDOUT error.
> >
> > In other words if there is a timeout waiting for FW_SET_DATA0, but not for
> > DW_SUCCESS, then we will return the wrong return value.
Thank you for your comment! I didn't realized this.
> Yes, agree with you, but seems I keep its original logic unchanged.
> Hi Yoshihiro,
>
> What do think about Daniel's suggestion? should I fix it up?
I think you should fix it up like below:
if (readl_poll_timeout_atomic(regs + RCAR_USB3_DL_CTRL,
val, val & RCAR_USB3_DL_CTRL_FW_SUCCESS, 1, 1) < 0)
retval = -ETIMEOUT; /* Overwrite retval if timeout occurred */
Otherwise, the xhci_rcar_download_firmware() cannot return -ETIMEDOUT if
timeout happened on the previous poll [1].
[1]
+ retval = readl_poll_timeout_atomic(regs + RCAR_USB3_DL_CTRL,
+ val, !(val & RCAR_USB3_DL_CTRL_FW_SET_DATA0),
+ 1, 1);
Best regards,
Yoshihiro Shimoda
Re: [PATCH V2] scripts : config : Added example use when run without argument,extend help
On 9/10/20 6:54 PM, Bhaskar Chowdhury wrote: > This patch extends the help section by adding an explicit example of use. > > Signed-off-by: Bhaskar Chowdhury > --- Difference between versions goes here. > scripts/config | 17 + > 1 file changed, 17 insertions(+) > > diff --git a/scripts/config b/scripts/config > index eee5b7f3a092..d905dccabb94 100755 > --- a/scripts/config > +++ b/scripts/config > @@ -45,6 +45,23 @@ make time. > By default, $myname will upper-case the given symbol. Use --keep-case to keep > the case of all following symbols unchanged. > > +The concrete example, say, you want to change any particular config,like config, like > +GCOV for profiling, you can simply use this command command. > + > +To enable: > + > +#scripts/config --enable GCOV_KERNEL && grep GCOV .config > + > + and the output will be like this: > + > + CONFIG_GCOV_KERNEL=y > + > +To disable: > + > +#scripts/config --disable GCOV_KERNEL && grep GCOV .config > + > +# CONFIG_GCOV_KERNEL is not set > + > $myname uses 'CONFIG_' as the default symbol prefix. Set the environment > variable CONFIG_ to the prefix to use. Eg.: CONFIG_="FOO_" $myname ... > EOL > I don't know why we need this extra help text. -- ~Randy
[PATCH] media/v4l2: remove V4L2-FLAG-MEMORY-NON-CONSISTENT flag
The patch partially reverts some of the UAPI bits of the buffer
cache management hints. Namely, the queue consistency (memory
coherency) user-space hint because, as it turned out, the kernel
implementation of this feature was misusing DMA_ATTR_NON_CONSISTENT.
The patch revers both kernel and user space parts: removes the
DMA consistency attr functions, rollbacks changes to v4l2_requestbuffers,
v4l2_create_buffers structures and corresponding UAPI functions
(plus compat32 layer) and cleanups the documentation.
Signed-off-by: Christoph Hellwig
Signed-off-by: Sergey Senozhatsky
---
.../userspace-api/media/v4l/buffer.rst| 17 ---
.../media/v4l/vidioc-create-bufs.rst | 6 +--
.../media/v4l/vidioc-reqbufs.rst | 12 +
.../media/common/videobuf2/videobuf2-core.c | 46 +++
.../common/videobuf2/videobuf2-dma-contig.c | 19
.../media/common/videobuf2/videobuf2-dma-sg.c | 3 +-
.../media/common/videobuf2/videobuf2-v4l2.c | 18 +---
drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 10 +---
drivers/media/v4l2-core/v4l2-ioctl.c | 5 +-
include/media/videobuf2-core.h| 7 +--
include/uapi/linux/videodev2.h| 13 +-
11 files changed, 22 insertions(+), 134 deletions(-)
diff --git a/Documentation/userspace-api/media/v4l/buffer.rst
b/Documentation/userspace-api/media/v4l/buffer.rst
index 177ed8b6ce62..4f95496adc5b 100644
--- a/Documentation/userspace-api/media/v4l/buffer.rst
+++ b/Documentation/userspace-api/media/v4l/buffer.rst
@@ -694,23 +694,6 @@ Memory Consistency Flags
:stub-columns: 0
:widths: 3 1 4
-* .. _`V4L2-FLAG-MEMORY-NON-CONSISTENT`:
-
- - ``V4L2_FLAG_MEMORY_NON_CONSISTENT``
- - 0x0001
- - A buffer is allocated either in consistent (it will be automatically
- coherent between the CPU and the bus) or non-consistent memory. The
- latter can provide performance gains, for instance the CPU cache
- sync/flush operations can be avoided if the buffer is accessed by the
- corresponding device only and the CPU does not read/write to/from that
- buffer. However, this requires extra care from the driver -- it must
- guarantee memory consistency by issuing a cache flush/sync when
- consistency is needed. If this flag is set V4L2 will attempt to
- allocate the buffer in non-consistent memory. The flag takes effect
- only if the buffer is used for :ref:`memory mapping ` I/O and the
- queue reports the :ref:`V4L2_BUF_CAP_SUPPORTS_MMAP_CACHE_HINTS
- ` capability.
-
.. c:type:: v4l2_memory
enum v4l2_memory
diff --git a/Documentation/userspace-api/media/v4l/vidioc-create-bufs.rst
b/Documentation/userspace-api/media/v4l/vidioc-create-bufs.rst
index c050dffa4237..d999028f47df 100644
--- a/Documentation/userspace-api/media/v4l/vidioc-create-bufs.rst
+++ b/Documentation/userspace-api/media/v4l/vidioc-create-bufs.rst
@@ -113,13 +113,9 @@ than the number requested.
If you want to just query the capabilities without making any
other changes, then set ``count`` to 0, ``memory`` to
``V4L2_MEMORY_MMAP`` and ``format.type`` to the buffer type.
-* - __u32
- - ``flags``
- - Specifies additional buffer management attributes.
- See :ref:`memory-flags`.
* - __u32
- - ``reserved``\ [6]
+ - ``reserved``\ [7]
- A place holder for future extensions. Drivers and applications
must set the array to zero.
diff --git a/Documentation/userspace-api/media/v4l/vidioc-reqbufs.rst
b/Documentation/userspace-api/media/v4l/vidioc-reqbufs.rst
index 47e433161690..afc35cd7b614 100644
--- a/Documentation/userspace-api/media/v4l/vidioc-reqbufs.rst
+++ b/Documentation/userspace-api/media/v4l/vidioc-reqbufs.rst
@@ -105,17 +105,10 @@ aborting or finishing any DMA in progress, an implicit
``V4L2_MEMORY_MMAP`` and ``type`` set to the buffer type. This will
free any previously allocated buffers, so this is typically something
that will be done at the start of the application.
-* - union {
- - (anonymous)
-* - __u32
- - ``flags``
- - Specifies additional buffer management attributes.
- See :ref:`memory-flags`.
* - __u32
- ``reserved``\ [1]
- - Kept for backwards compatibility. Use ``flags`` instead.
-* - }
- -
+ - A place holder for future extensions. Drivers and applications
+ must set the array to zero.
.. tabularcolumns:: |p{6.1cm}|p{2.2cm}|p{8.7cm}|
@@ -162,7 +155,6 @@ aborting or finishing any DMA in progress, an implicit
- This capability is set by the driver to indicate that the queue
supports
cache and memory management hints. However, it's only valid when the
queue is used for :ref:`memory mapping ` streaming I/O. See
-:ref:`V4L2_FLAG_MEMORY_NON_CONSISTENT
`,
:ref:`V4L2_BUF_FLAG_NO_CACHE_INVALIDATE
` and
Re: [PATCH v3] perf metricgroup: Fix uncore metric expressions
On Fri, Sep 11, 2020 at 3:02 AM Ian Rogers wrote:
>
> A metric like DRAM_BW_Use has on SkylakeX events uncore_imc/cas_count_read/
> and uncore_imc/case_count_write/. These events open 6 events per socket
> with pmu names of uncore_imc_[0-5]. The current metric setup code in
> find_evsel_group assumes one ID will map to 1 event to be recorded in
> metric_events. For events with multiple matches, the first event is
> recorded in metric_events (avoiding matching >1 event with the same
> name) and the evlist_used updated so that duplicate events aren't
> removed when the evlist has unused events removed.
>
> Before this change:
> $ /tmp/perf/perf stat -M DRAM_BW_Use -a -- sleep 1
>
> Performance counter stats for 'system wide':
>
> 41.14 MiB uncore_imc/cas_count_read/
> 1,002,614,251 ns duration_time
>
>1.002614251 seconds time elapsed
>
> After this change:
> $ /tmp/perf/perf stat -M DRAM_BW_Use -a -- sleep 1
>
> Performance counter stats for 'system wide':
>
> 157.47 MiB uncore_imc/cas_count_read/ # 0.00 DRAM_BW_Use
> 126.97 MiB uncore_imc/cas_count_write/
> 1,003,019,728 ns duration_time
>
> v3. cleans up searching for the same event within metric_events to use a
> helper and avoids a redundant search. It uses a continue loop to
> make the search for similarly named events shorter.
> v2. avoids iterating over the whole evlist as suggested by
> namhy...@kernel.org. It also fixes the metric_leader computation
> that was broken in the same commits.
>
> Erroneous duplication introduced in:
> commit 2440689d62e9 ("perf metricgroup: Remove duped metric group events").
>
> Fixes: ded80bda8bc9 ("perf expr: Migrate expr ids table to a hashmap").
> Reported-by: Jin Yao
> Signed-off-by: Ian Rogers
Acked-by: Namhyung Kim
Thanks
Namhyung
> ---
> tools/perf/util/metricgroup.c | 75 ++-
> 1 file changed, 56 insertions(+), 19 deletions(-)
>
> diff --git a/tools/perf/util/metricgroup.c b/tools/perf/util/metricgroup.c
> index 662f4e8777d5..7b66452cb9f9 100644
> --- a/tools/perf/util/metricgroup.c
> +++ b/tools/perf/util/metricgroup.c
> @@ -149,6 +149,18 @@ static void expr_ids__exit(struct expr_ids *ids)
> free(ids->id[i].id);
> }
>
> +static bool contains_event(struct evsel **metric_events, int num_events,
> + const char *event_name)
> +{
> + int i;
> +
> + for (i = 0; i < num_events; i++) {
> + if (!strcmp(metric_events[i]->name, event_name))
> + return true;
> + }
> + return false;
> +}
> +
> /**
> * Find a group of events in perf_evlist that correspond to those from a
> parsed
> * metric expression. Note, as find_evsel_group is called in the same order
> as
> @@ -179,7 +191,11 @@ static struct evsel *find_evsel_group(struct evlist
> *perf_evlist,
> int i = 0, matched_events = 0, events_to_match;
> const int idnum = (int)hashmap__size(>ids);
>
> - /* duration_time is grouped separately. */
> + /*
> +* duration_time is always grouped separately, when events are grouped
> +* (ie has_constraint is false) then ignore it in the matching loop
> and
> +* add it to metric_events at the end.
> +*/
> if (!has_constraint &&
> hashmap__find(>ids, "duration_time", (void **)_ptr))
> events_to_match = idnum - 1;
> @@ -206,23 +222,20 @@ static struct evsel *find_evsel_group(struct evlist
> *perf_evlist,
> sizeof(struct evsel *) * idnum);
> current_leader = ev->leader;
> }
> - if (hashmap__find(>ids, ev->name, (void **)_ptr)) {
> - if (has_constraint) {
> - /*
> -* Events aren't grouped, ensure the same
> event
> -* isn't matched from two groups.
> -*/
> - for (i = 0; i < matched_events; i++) {
> - if (!strcmp(ev->name,
> - metric_events[i]->name)) {
> - break;
> - }
> - }
> - if (i != matched_events)
> - continue;
> - }
> + /*
> +* Check for duplicate events with the same name. For example,
> +* uncore_imc/cas_count_read/ will turn into 6 events per
> socket
> +* on skylakex. Only the first such event is placed in
> +* metric_events. If events aren't grouped then this also
> +* ensures that the same event in different sibling groups
> +* aren't both added to
Re: [PATCH] perf: Fix race in perf_mmap_close function
Hi Jiri, On Thu, Sep 10, 2020 at 11:50 PM Jiri Olsa wrote: > > On Thu, Sep 10, 2020 at 10:48:02PM +0900, Namhyung Kim wrote: > > SNIP > > > > _do_fork+0x83/0x3a0 > > > __do_sys_wait4+0x83/0x90 > > > __do_sys_clone+0x85/0xa0 > > > do_syscall_64+0x5b/0x1e0 > > > entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > > > > > Using atomic decrease and check instead of separated calls. > > > This fixes CVE-2020-14351. > > > > > > Signed-off-by: Jiri Olsa > > > --- > > > kernel/events/core.c | 4 +--- > > > 1 file changed, 1 insertion(+), 3 deletions(-) > > > > > > diff --git a/kernel/events/core.c b/kernel/events/core.c > > > index 7ed5248f0445..29313cc54d9e 100644 > > > --- a/kernel/events/core.c > > > +++ b/kernel/events/core.c > > > @@ -5903,8 +5903,6 @@ static void perf_mmap_close(struct vm_area_struct > > > *vma) > > > mutex_unlock(>mmap_mutex); > > > } > > > > > > - atomic_dec(>mmap_count); > > > - > > > if (!atomic_dec_and_mutex_lock(>mmap_count, > > > >mmap_mutex)) > > > goto out_put; > > > > But when it takes the goto, rb->mmap_count won't decrement anymore.. > > event->mmap_count is per event, so if we have have race in here, > 2 threads can go through with each event->mmap_count reaching zero Maybe I'm missing something. But as far as I can see, perf_mmap_close() always decremented both rb->mmap_count and event->mmap_count. But with this change, it seems not decrement rb->mmap_count when event->mmap_count doesn't go to zero, right? Thanks Namhyung
Re: [PATCH 1/2] extcon: ptn5150: Use defines for registers
On 9/10/20 12:01 AM, Krzysztof Kozlowski wrote:
> The register addresses are not continuous, so use simple defines for
> them. This also makes it easier to find the address for register.
>
> No functional change.
>
> Signed-off-by: Krzysztof Kozlowski
> ---
> drivers/extcon/extcon-ptn5150.c | 22 ++
> 1 file changed, 10 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/extcon/extcon-ptn5150.c b/drivers/extcon/extcon-ptn5150.c
> index dda5b3a3a908..1b68f56d8372 100644
> --- a/drivers/extcon/extcon-ptn5150.c
> +++ b/drivers/extcon/extcon-ptn5150.c
> @@ -19,18 +19,16 @@
> #include
>
> /* PTN5150 registers */
> -enum ptn5150_reg {
> - PTN5150_REG_DEVICE_ID = 0x01,
> - PTN5150_REG_CONTROL,
> - PTN5150_REG_INT_STATUS,
> - PTN5150_REG_CC_STATUS,
> - PTN5150_REG_CON_DET = 0x09,
> - PTN5150_REG_VCONN_STATUS,
> - PTN5150_REG_RESET,
> - PTN5150_REG_INT_MASK = 0x18,
> - PTN5150_REG_INT_REG_STATUS,
> - PTN5150_REG_END,
> -};
> +#define PTN5150_REG_DEVICE_ID0x01
> +#define PTN5150_REG_CONTROL 0x02
> +#define PTN5150_REG_INT_STATUS 0x03
> +#define PTN5150_REG_CC_STATUS0x04
> +#define PTN5150_REG_CON_DET 0x09
> +#define PTN5150_REG_VCONN_STATUS 0x0a
> +#define PTN5150_REG_RESET0x0b
> +#define PTN5150_REG_INT_MASK 0x18
> +#define PTN5150_REG_INT_REG_STATUS 0x19
> +#define PTN5150_REG_END
> PTN5150_REG_INT_REG_STATUS
PTN5150_REG_END should be (PTN5150_REG_INT_REG_STATUS + 1)
for regmap operation of PTN5150_REG_INT_REG_STATUS.
>
> #define PTN5150_DFP_ATTACHED 0x1
> #define PTN5150_UFP_ATTACHED 0x2
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH] fs: use correct parameter in notes of generic_file_llseek_size()
On 9/10/20 7:06 PM, Tianxianting wrote: > Hi viro, > Could I get your feedback? > This patch fixed the build warning, I think it can be applied, thanks :) > > -Original Message- > From: tianxianting (RD) > Sent: Saturday, September 05, 2020 3:15 PM > To: v...@zeniv.linux.org.uk > Cc: linux-fsde...@vger.kernel.org; linux-kernel@vger.kernel.org; tianxianting > (RD) > Subject: [PATCH] fs: use correct parameter in notes of > generic_file_llseek_size() > > Fix warning when compiling with W=1: > fs/read_write.c:88: warning: Function parameter or member 'maxsize' not > described in 'generic_file_llseek_size' > fs/read_write.c:88: warning: Excess function parameter 'size' description in > 'generic_file_llseek_size' > > Signed-off-by: Xianting Tian Acked-by: Randy Dunlap Thanks. > --- > fs/read_write.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/fs/read_write.c b/fs/read_write.c > index 5db58b8c7..058563ee2 100644 > --- a/fs/read_write.c > +++ b/fs/read_write.c > @@ -71,7 +71,7 @@ EXPORT_SYMBOL(vfs_setpos); > * @file:file structure to seek on > * @offset: file offset to seek to > * @whence: type of seek > - * @size:max size of this file in file system > + * @maxsize: max size of this file in file system > * @eof: offset used for SEEK_END position > * > * This is a variant of generic_file_llseek that allows passing in a custom > -- ~Randy
Re: [PATCHSET 0/4] perf stat: Add --multiply-cgroup option
Hi Ian,
On Fri, Sep 11, 2020 at 2:11 AM Ian Rogers wrote:
> Just to throw in some 2c worth. A nice thing about Namhyung's approach
> is that it can apply for metrics, events and pfm-events. It would be
> nice if there were a single option for specifying these, perhaps we
> can figure one out.
Right! Thanks for sharing your opinion. :)
>
> One thought that came to mind based on Namhyung's multiply name was
> and assuming a cgroup could be a modifier:
>
> perf record -e cycles:G1
>
> there could be equivalent to a new syntax of lists and multiplies of:
>
> perf record -e [cycles]*[:G1]
>
> This would allow expressions like:
>
> perf record -e [{instructions,cycles},branches]*[:u,:k]
>
> which would be equivalent to (showing the effect on sibling groups):
>
> perf record -e
> {instructions:u,cycles:u},branches:u,{instructions:k,cycles:k},branches:k
>
> Adding in cgroups makes a longer list of events:
>
> perf record -e [{instructions,cycles},branches]*[:u,:k]*[:G1,:G2]
>
> becomes:
>
> perf record -e
> {instructions:u:G1,cycles:u:G1},branches:u:G1,{instructions:k:G1,cycles:k:G1},branches:k:G1,{instructions:u:G2,cycles:u:G2},branches:u:G2,{instructions:k:G2,cycles:k:G2},branches:k:G2
>
> This is somewhat similar to Arnaldo's proposal but trying to make
> things a bit more generic, avoiding overloading the use of sibling
> groups, .. Perhaps there is a syntax that others prefer or could be
> borrowed from a familiar source like a programming language.
Yes, but this is like a radical change. This would be nice to deal
with repetition in the event list. But I guess mostly we only use a
small number of events (beside the cgroups)...
>
> I think for Namhyung's sake it is important not to get too distracted
> by desires for better syntax, as this change makes a benefit in a way
> that works with the existing flags. If it is accepted, the man pages
> need to be updated.
Right. I wonder whether they're gonna take the new option
(maybe --for-each-cgroup ?) or not regardless of the syntax change.
Thanks
Namhyung
Re: [v4,3/4] reset-controller: ti: introduce a new reset handler
On 9/10/20 9:42 PM, Crystal Guo wrote:
> On Wed, 2020-09-09 at 23:39 +0800, Suman Anna wrote:
>> On 9/8/20 9:57 PM, Crystal Guo wrote:
>>> On Thu, 2020-09-03 at 07:40 +0800, Suman Anna wrote:
Hi Crystal,
On 8/16/20 10:03 PM, Crystal Guo wrote:
> Introduce ti_syscon_reset() to integrate assert and deassert together.
> If some modules need do serialized assert and deassert operations
> to reset itself, reset_control_reset can be called for convenience.
There are multiple changes in this same patch. I think you should split
this
functionality away from the change for the regmap_update_bits() to
regmap_write_bits(), similar to what you have done in your v2 Patch 4.
>>>
>>> Thanks for your suggestion.
>>> I will split this patch in the next version.
>>>
>
> Such as reset-qcom-aoss.c, it integrates assert and deassert together
> by 'reset' method. MTK Socs also need this method to perform reset.
>
> Signed-off-by: Crystal Guo
> ---
> drivers/reset/reset-ti-syscon.c | 26 --
> 1 file changed, 24 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/reset/reset-ti-syscon.c
> b/drivers/reset/reset-ti-syscon.c
> index a2635c21db7f..08289342f9af 100644
> --- a/drivers/reset/reset-ti-syscon.c
> +++ b/drivers/reset/reset-ti-syscon.c
> @@ -15,6 +15,7 @@
> * GNU General Public License for more details.
> */
>
> +#include
> #include
> #include
> #include
> @@ -56,6 +57,7 @@ struct ti_syscon_reset_data {
> struct regmap *regmap;
> struct ti_syscon_reset_control *controls;
> unsigned int nr_controls;
> + unsigned int reset_duration_us;
> };
>
> #define to_ti_syscon_reset_data(rcdev) \
> @@ -89,7 +91,7 @@ static int ti_syscon_reset_assert(struct
> reset_controller_dev *rcdev,
> mask = BIT(control->assert_bit);
> value = (control->flags & ASSERT_SET) ? mask : 0x0;
>
> - return regmap_update_bits(data->regmap, control->assert_offset, mask,
> value);
> + return regmap_write_bits(data->regmap, control->assert_offset, mask,
> value);
> }
>
> /**
> @@ -120,7 +122,7 @@ static int ti_syscon_reset_deassert(struct
> reset_controller_dev *rcdev,
> mask = BIT(control->deassert_bit);
> value = (control->flags & DEASSERT_SET) ? mask : 0x0;
>
> - return regmap_update_bits(data->regmap, control->deassert_offset, mask,
> value);
> + return regmap_write_bits(data->regmap, control->deassert_offset, mask,
> value);
> }
>
> /**
> @@ -158,9 +160,26 @@ static int ti_syscon_reset_status(struct
> reset_controller_dev *rcdev,
> !(control->flags & STATUS_SET);
> }
>
> +static int ti_syscon_reset(struct reset_controller_dev *rcdev,
> + unsigned long id)
> +{
> + struct ti_syscon_reset_data *data = to_ti_syscon_reset_data(rcdev);
> + int ret;
> +
> + ret = ti_syscon_reset_assert(rcdev, id);
> + if (ret)
> + return ret;
> +
> + if (data->reset_duration_us)
> + usleep_range(data->reset_duration_us, data->reset_duration_us *
> 2);
> +
> + return ti_syscon_reset_deassert(rcdev, id);
I echo Philipp's comments [1] from your original v1 series about this. We
don't
need a property to distinguish this, but you could add a flag using match
data
and Mediatek compatible, and use that within this function, or optionally
set
this ops based on compatible (whatever is preferred by Philipp).
regards
Suman
[1] https://patchwork.kernel.org/comment/23519193/
>>> Hi Suman, Philipp
>>>
>>> Which method would you recommend more?
>>> 1. like v2 patch, but assign the flag "data->assert_deassert_together"
>>> directly (maybe rename "assert_deassert_together" to
>>> "reset_op_available")
>>>
>>> 2. use Mediatek compatible to decide the reset handler available or not.
>>
>> I would go with this option. Anyway, I think you might have to add the reset
>> SoC
>> data as well, based on Rob's comment on the binding.
>>
>> regards
>> Suman
>
>
> Thanks for your suggestions
> I will add the following changes in the next version,
> please correct me if there is any misunderstanding.
> 1). revert ti-syscon-reset.txt add a new mediatek reset binding doc.
> 2). split the patch [v4,3/4] with the change for the
> regmap_update_bits() to regmap_write_bits() and the change to integrate
> assert and deassert together.
> 3). add the reset SoC data, which contains the flag "reset_op_available"
> to decide the reset handler available or not.
You would also need to add your SoC-specific data equivalent of the current
ti,reset-bits in your infra node. Please see Rob's comments on patch 2. Also,
your new Mediatek binding should be in YAML
Re: [PATCH v18 00/32] per memcg lru_lock: reviews
在 2020/9/10 上午7:16, Hugh Dickins 写道: > On Wed, 9 Sep 2020, Alex Shi wrote: >> 在 2020/9/9 上午7:41, Hugh Dickins 写道: >>> >>> [PATCH v18 05/32] mm/thp: remove code path which never got into >>> This is a good simplification, but I see no sign that you understand >>> why it's valid: it relies on lru_add_page_tail() being called while >>> head refcount is frozen to 0: we would not get this far if someone >>> else holds a reference to the THP - which they must hold if they have >>> isolated the page from its lru (and that's true before or after your >>> per-memcg changes - but even truer after those changes, since PageLRU >>> can then be flipped without lru_lock at any instant): please explain >>> something of this in the commit message. >> >> Is the following commit log better? >> >> split_huge_page() will never call on a page which isn't on lru list, so >> this code never got a chance to run, and should not be run, to add tail >> pages on a lru list which head page isn't there. >> >> Hugh Dickins' mentioned: >> The path should never be called since lru_add_page_tail() being called >> while head refcount is frozen to 0: we would not get this far if someone >> else holds a reference to the THP - which they must hold if they have >> isolated the page from its lru. >> >> Although the bug was never triggered, it'better be removed for code >> correctness, and add a warn for unexpected calling. > > Not much better, no. split_huge_page() can easily be called for a page > which is not on the lru list at the time, Hi Hugh, Thanks for comments! There are some discussion on this point a couple of weeks ago, https://lkml.org/lkml/2020/7/9/760 Matthew Wilcox and Kirill have the following comments, > I don't understand how we get to split_huge_page() with a page that's > not on an LRU list. Both anonymous and page cache pages should be on > an LRU list. What am I missing? Right, and it's never got removed from LRU during the split. The tail pages have to be added to LRU because they now separate from the tail page. -- Kirill A. Shutemov > and I don't know what was the > bug which was never triggered. So the only path to the removed part should be a bug, like sth here, https://lkml.org/lkml/2020/7/10/118 or https://lkml.org/lkml/2020/7/10/972 > Stick with whatever text you end up with > for the combination of 05/32 and 18/32, and I'll rewrite it after. I am not object to merge them into one, I just don't know how to say clear about 2 patches in commit log. As patch 18, TestClearPageLRU add the incorrect posibility of remove lru bit during split, that's the reason of code path rewrite and a WARN there. Thanks Alex > >>> [PATCH v18 06/32] mm/thp: narrow lru locking >>> Why? What part does this play in the series? "narrow lru locking" can >>> also be described as "widen page cache locking": >> >> Uh, the page cache locking isn't widen, it's still on the old place. > > I'm not sure if you're joking there. Perhaps just a misunderstanding. > > Yes, patch 06/32 does not touch the xa_lock(>i_pages) and > xa_lock(_cache->i_pages) lines (odd how we've arrived at two of > those, but please do not get into cleaning it up now); but it removes > the spin_lock_irqsave(>lru_lock, flags) which used to come > before them, and inserts a spin_lock(>lru_lock) after them. > > You call that narrowing the lru locking, okay, but I see it as also > pushing the page cache locking outwards: before this patch, page cache > lock was taken inside lru_lock; after this patch, page cache lock is > taken outside lru_lock. If you cannot see that, then I think you > should not have touched this code at all; but it's what we have > been testing, and I think we should go forward with it. > >>> But I wish you could give some reason for it in the commit message! >> >> It's a head scratch task. Would you like to tell me what's detailed info >> should be there? Thanks! > > So, you don't know why you did it either: then it will be hard to > justify. I guess I'll have to write something for it later. I'm > strongly tempted just to drop the patch, but expect it will become > useful later, for using lock_page_memcg() before getting lru_lock. > I thought the xa_lock and lru_lock relationship was described clear in the commit log, and still no idea of the move_lock in the chain. Please refill them for what I overlooked. Thanks! >>> Signed-off-by: Wei Yang >>> Is that correct? Or Wei Yang suggested some part of it perhaps? >> >> Yes, we talked a lot to confirm the locking change is safe. > > Okay, but the patch was written by you, and sent by you to Andrew: > that is not a case for "Signed-off-by: Someone Else". > Ok. let's remove his signed-off. >>> [PATCH v18 27/32] mm/swap.c: optimizing __pagevec_lru_add lru_lock >>> Could we please drop this one for the moment? And come back to it later >>> when the basic series is safely in. It's a good idea to try sorting >>> together those pages which
Re: [PATCH v10 21/24] coresight: cti: allow cti to be built as a module
On Fri, Sep 11, 2020 at 07:03:03AM +0800, Mathieu Poirier wrote:
> On Fri, Aug 21, 2020 at 11:44:42AM +0800, Tingwei Zhang wrote:
> > Allow to build coresight-cti as a module, for ease of development.
> >
> > - Kconfig becomes a tristate, to allow =m
> > - append -core to source file name to allow module to
> > be called coresight-cti by the Makefile
> > - add an cti_remove function, for module unload
> > - move cti_remove_conn_xrefs to cti_remove
> > - add a MODULE_DEVICE_TABLE for autoloading on boot
> >
> > Signed-off-by: Tingwei Zhang
> > Tested-by: Mike Leach
> > Reviewed-by Mike Leach
> > ---
> > drivers/hwtracing/coresight/Kconfig | 5 -
> > drivers/hwtracing/coresight/Makefile | 4 ++--
> > .../{coresight-cti.c => coresight-cti-core.c} | 20 ++-
> > .../hwtracing/coresight/coresight-platform.c | 1 +
> > drivers/hwtracing/coresight/coresight.c | 1 +
> > 5 files changed, 27 insertions(+), 4 deletions(-)
> > rename drivers/hwtracing/coresight/{coresight-cti.c =>
> coresight-cti-core.c} (98%)
> >
> > diff --git a/drivers/hwtracing/coresight/Kconfig
> b/drivers/hwtracing/coresight/Kconfig
> > index f31778dd0b5d..b04aae2ceecc 100644
> > --- a/drivers/hwtracing/coresight/Kconfig
> > +++ b/drivers/hwtracing/coresight/Kconfig
> > @@ -136,7 +136,7 @@ config CORESIGHT_CPU_DEBUG
> > module will be called coresight-cpu-debug.
> >
> > config CORESIGHT_CTI
> > - bool "CoreSight Cross Trigger Interface (CTI) driver"
> > + tristate "CoreSight Cross Trigger Interface (CTI) driver"
> > depends on ARM || ARM64
> > help
> > This driver provides support for CoreSight CTI and CTM
> components.
> > @@ -147,6 +147,9 @@ config CORESIGHT_CTI
> > halt compared to disabling sources and sinks normally in driver
> > software.
> >
> > + To compile this driver as a module, choose M here: the
> > + module will be called coresight-cti.
> > +
> > config CORESIGHT_CTI_INTEGRATION_REGS
> > bool "Access CTI CoreSight Integration Registers"
> > depends on CORESIGHT_CTI
> > diff --git a/drivers/hwtracing/coresight/Makefile
> b/drivers/hwtracing/coresight/Makefile
> > index f2a568b969c4..0359d5a1588f 100644
> > --- a/drivers/hwtracing/coresight/Makefile
> > +++ b/drivers/hwtracing/coresight/Makefile
> > @@ -19,6 +19,6 @@ coresight-etm4x-y := coresight-etm4x-core.o
> coresight-etm4x-sysfs.o
> > obj-$(CONFIG_CORESIGHT_STM) += coresight-stm.o
> > obj-$(CONFIG_CORESIGHT_CPU_DEBUG) += coresight-cpu-debug.o
> > obj-$(CONFIG_CORESIGHT_CATU) += coresight-catu.o
> > -obj-$(CONFIG_CORESIGHT_CTI) += coresight-cti.o \
> > - coresight-cti-platform.o \
> > +obj-$(CONFIG_CORESIGHT_CTI) += coresight-cti.o
> > +coresight-cti-y := coresight-cti-core.ocoresight-cti-platform.o \
> > coresight-cti-sysfs.o
> > diff --git a/drivers/hwtracing/coresight/coresight-cti.c
> b/drivers/hwtracing/coresight/coresight-cti-core.c
> > similarity index 98%
> > rename from drivers/hwtracing/coresight/coresight-cti.c
> > rename to drivers/hwtracing/coresight/coresight-cti-core.c
> > index ec286d617b73..d6d5419ec21c 100644
> > --- a/drivers/hwtracing/coresight/coresight-cti.c
> > +++ b/drivers/hwtracing/coresight/coresight-cti-core.c
> > @@ -838,7 +838,6 @@ static void cti_device_release(struct device *dev)
> > struct cti_drvdata *ect_item, *ect_tmp;
> >
> > mutex_lock(_mutex);
> > - cti_remove_conn_xrefs(drvdata);
> > cti_pm_release(drvdata);
> >
> > /* remove from the list */
> > @@ -853,6 +852,18 @@ static void cti_device_release(struct device *dev)
> > if (drvdata->csdev_release)
> > drvdata->csdev_release(dev);
> > }
> > +static int __exit cti_remove(struct amba_device *adev)
> > +{
> > + struct cti_drvdata *drvdata = dev_get_drvdata(>dev);
> > +
> > + mutex_lock(_mutex);
> > + cti_remove_conn_xrefs(drvdata);
> > + mutex_unlock(_mutex);
> > +
> > + coresight_unregister(drvdata->csdev);
> > +
> > + return 0;
>
> Once again my recommendations from V8 were not followed.
>
Sorry for missing your comment. I'll add reason for above change
in commit message in V11.
Thanks,
Tingwei
> > +}
> >
> > static int cti_probe(struct amba_device *adev, const struct amba_id
> *id)
> > {
> > @@ -973,6 +984,8 @@ static const struct amba_id cti_ids[] = {
> > { 0, 0},
> > };
> >
> > +MODULE_DEVICE_TABLE(amba, cti_ids);
> > +
> > static struct amba_driver cti_driver = {
> > .drv = {
> > .name = "coresight-cti",
> > @@ -980,6 +993,7 @@ static struct amba_driver cti_driver = {
> > .suppress_bind_attrs = true,
> > },
> > .probe = cti_probe,
> > + .remove = cti_remove,
> > .id_table = cti_ids,
> > };
> >
> > @@ -1002,3 +1016,7 @@ static void __exit cti_exit(void)
> >
> > module_init(cti_init);
> > module_exit(cti_exit);
> > +
> > +MODULE_AUTHOR("Mike Leach ");
> >
Re: [PATCH v10 08/24] coresight: etm: perf: Fix warning caused by etm_setup_aux failure
On Fri, Sep 11, 2020 at 06:28:40AM +0800, Mathieu Poirier wrote:
> On Fri, Aug 21, 2020 at 11:44:29AM +0800, Tingwei Zhang wrote:
> > When coresight_build_path() fails on all the cpus, etm_setup_aux
> > calls etm_free_aux() to free allocated event_data.
> > WARN_ON(cpumask_empty(mask) will be triggered since cpu mask is empty.
> > Check event_data->snk_config is not NULL first to avoid this
> > warning.
> >
> > Signed-off-by: Tingwei Zhang
> > Reviewed-by: Mike Leach
> > Reviewed-by: Suzuki K Poulose
> > Reviewed-by: Mathieu Poirier
>
> What happend to the Fixed tag that was in V8? This is casting doubts on
> the
> reset of this set.
>
Hi Mathieu,
Sorry about the mess here. I pushed the change to Android mainline and missed
fix tag when making V10.
To make sure there's no other missing, I compared all V8 and V10 patches and
rechecked all comments on V8.
Two issues were found.
1. Reviewed-by from you on [patch 5/24] should not be added.
2. MODULE_LICENSE("GPL v2") was missed in V10.
I'll fix all issues on V11.
Shall I send V11 when it's ready or wait for your comments on other patches?
Thanks,
Tingwei
> > ---
> > drivers/hwtracing/coresight/coresight-etm-perf.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.c
> b/drivers/hwtracing/coresight/coresight-etm-perf.c
> > index dcb0592418ae..3728c44e5763 100644
> > --- a/drivers/hwtracing/coresight/coresight-etm-perf.c
> > +++ b/drivers/hwtracing/coresight/coresight-etm-perf.c
> > @@ -126,10 +126,10 @@ static void free_sink_buffer(struct etm_event_data
> *event_data)
> > cpumask_t *mask = _data->mask;
> > struct coresight_device *sink;
> >
> > - if (WARN_ON(cpumask_empty(mask)))
> > + if (!event_data->snk_config)
> > return;
> >
> > - if (!event_data->snk_config)
> > + if (WARN_ON(cpumask_empty(mask)))
> > return;
> >
> > cpu = cpumask_first(mask);
> > --
> > The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
> Forum,
> > a Linux Foundation Collaborative Project
> >
Re: [PATCH 2/3] mmc: sdhci-of-aspeed: Expose data sample phase delay tuning
On Fri, 11 Sep 2020, at 11:32, Joel Stanley wrote:
> On Thu, 10 Sep 2020 at 10:55, Andrew Jeffery wrote:
> >
> > Allow sample phase adjustment to deal with layout or tolerance issues.
> >
> > Signed-off-by: Andrew Jeffery
> > ---
> > drivers/mmc/host/sdhci-of-aspeed.c | 137 +++--
> > 1 file changed, 132 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/mmc/host/sdhci-of-aspeed.c
> > b/drivers/mmc/host/sdhci-of-aspeed.c
> > index 4f008ba3280e..641accbfcde4 100644
> > --- a/drivers/mmc/host/sdhci-of-aspeed.c
> > +++ b/drivers/mmc/host/sdhci-of-aspeed.c
> > @@ -16,9 +16,18 @@
> >
> > #include "sdhci-pltfm.h"
> >
> > -#define ASPEED_SDC_INFO0x00
> > -#define ASPEED_SDC_S1MMC8BIT(25)
> > -#define ASPEED_SDC_S0MMC8BIT(24)
> > +#define ASPEED_SDC_INFO0x00
> > +#define ASPEED_SDC_S1_MMC8 BIT(25)
> > +#define ASPEED_SDC_S0_MMC8 BIT(24)
> > +#define ASPEED_SDC_PHASE 0xf4
> > +#define ASPEED_SDC_S1_PHASE_IN GENMASK(25, 21)
> > +#define ASPEED_SDC_S0_PHASE_IN GENMASK(20, 16)
> > +#define ASPEED_SDC_S1_PHASE_OUT GENMASK(15, 11)
> > +#define ASPEED_SDC_S1_PHASE_IN_ENBIT(10)
> > +#define ASPEED_SDC_S1_PHASE_OUT_EN GENMASK(9, 8)
> > +#define ASPEED_SDC_S0_PHASE_OUT GENMASK(7, 3)
> > +#define ASPEED_SDC_S0_PHASE_IN_ENBIT(2)
> > +#define ASPEED_SDC_S0_PHASE_OUT_EN GENMASK(1, 0)
> >
> > struct aspeed_sdc {
> > struct clk *clk;
> > @@ -28,9 +37,21 @@ struct aspeed_sdc {
> > void __iomem *regs;
> > };
> >
> > +struct aspeed_sdhci_phase_desc {
> > + u32 value_mask;
> > + u32 enable_mask;
> > + u8 enable_value;
> > +};
> > +
> > +struct aspeed_sdhci_phase {
> > + struct aspeed_sdhci_phase_desc in;
> > + struct aspeed_sdhci_phase_desc out;
> > +};
> > +
> > struct aspeed_sdhci {
> > struct aspeed_sdc *parent;
> > u32 width_mask;
> > + const struct aspeed_sdhci_phase *phase;
> > };
> >
> > static void aspeed_sdc_configure_8bit_mode(struct aspeed_sdc *sdc,
> > @@ -50,6 +71,25 @@ static void aspeed_sdc_configure_8bit_mode(struct
> > aspeed_sdc *sdc,
> > spin_unlock(>lock);
> > }
> >
> > +static void
> > +aspeed_sdc_configure_phase(struct aspeed_sdc *sdc,
> > + const struct aspeed_sdhci_phase_desc *phase,
> > + uint8_t value, bool enable)
> > +{
> > + u32 reg;
> > +
> > + spin_lock(>lock);
>
> What is the lock protecting against?
>
> We call this in the ->probe, so there should be no concurrent access going on.
Because the register is in the "global" part of the SD/MMC controller address
space (it's not part of the SDHCI), and there are multiple slots that may have
a driver probed concurrently.
>
>
> > + reg = readl(sdc->regs + ASPEED_SDC_PHASE);
> > + reg &= ~phase->enable_mask;
> > + if (enable) {
> > + reg &= ~phase->value_mask;
> > + reg |= value << __ffs(phase->value_mask);
> > + reg |= phase->enable_value << __ffs(phase->enable_mask);
> > + }
> > + writel(reg, sdc->regs + ASPEED_SDC_PHASE);
> > + spin_unlock(>lock);
> > +}
> > +
> > static void aspeed_sdhci_set_clock(struct sdhci_host *host, unsigned int
> > clock)
> > {
> > struct sdhci_pltfm_host *pltfm_host;
> > @@ -155,8 +195,58 @@ static inline int aspeed_sdhci_calculate_slot(struct
> > aspeed_sdhci *dev,
> > return (delta / 0x100) - 1;
> > }
> >
> > +static int aspeed_sdhci_configure_of(struct platform_device *pdev,
> > +struct aspeed_sdhci *sdhci)
> > +{
> > + u32 iphase, ophase;
> > + struct device_node *np;
> > + struct device *dev;
> > + int ret;
> > +
> > + if (!sdhci->phase)
> > + return 0;
> > +
> > + dev = >dev;
> > + np = dev->of_node;
> > +
> > + ret = of_property_read_u32(np, "aspeed,input-phase", );
> > + if (ret < 0) {
> > + aspeed_sdc_configure_phase(sdhci->parent,
> > >phase->in, 0,
> > + false);
>
> Will this clear any value that eg. u-boot writes?
No, see the 'enable' test in aspeed_sdc_configure_phase()
>
> The register should be left alone if the kernel doesn't have a
> configuration of it's own, otherwise we may end up breaking an
> otherwise working system.
Right, I can rework that.
>
> > + dev_dbg(dev, "Input phase configuration disabled");
> > + } else if (iphase >= (1 << 5)) {
> > + dev_err(dev,
> > + "Input phase value exceeds field range (5 bits):
> > %u",
> > + iphase);
> > + return -ERANGE;
> > + } else {
> > + aspeed_sdc_configure_phase(sdhci->parent, >phase->in,
> > + iphase, true);
> > +
Re: [PATCH v3 06/17] virt: acrn: Introduce VM management interfaces
Hi Greg,
On 9/11/2020 00:28, Greg Kroah-Hartman wrote:
> On Thu, Sep 10, 2020 at 02:19:00PM +0800, Shuo A Liu wrote:
>> On Wed 9.Sep'20 at 11:45:16 +0200, Greg Kroah-Hartman wrote:
>>> On Wed, Sep 09, 2020 at 05:08:25PM +0800, shuo.a@intel.com wrote:
From: Shuo Liu
The VM management interfaces expose several VM operations to ACRN
userspace via ioctls. For example, creating VM, starting VM, destroying
VM and so on.
The ACRN Hypervisor needs to exchange data with the ACRN userspace
during the VM operations. HSM provides VM operation ioctls to the ACRN
userspace and communicates with the ACRN Hypervisor for VM operations
via hypercalls.
HSM maintains a list of User VM. Each User VM will be bound to an
existing file descriptor of /dev/acrn_hsm. The User VM will be
destroyed when the file descriptor is closed.
Signed-off-by: Shuo Liu
Reviewed-by: Zhi Wang
Reviewed-by: Reinette Chatre
Cc: Zhi Wang
Cc: Zhenyu Wang
Cc: Yu Wang
Cc: Reinette Chatre
Cc: Greg Kroah-Hartman
---
.../userspace-api/ioctl/ioctl-number.rst | 1 +
MAINTAINERS | 1 +
drivers/virt/acrn/Makefile| 2 +-
drivers/virt/acrn/acrn_drv.h | 22 +-
drivers/virt/acrn/hsm.c | 66
drivers/virt/acrn/hypercall.h | 78 +++
drivers/virt/acrn/vm.c| 69
include/uapi/linux/acrn.h | 56 +
8 files changed, 293 insertions(+), 2 deletions(-)
create mode 100644 drivers/virt/acrn/hypercall.h
create mode 100644 drivers/virt/acrn/vm.c
create mode 100644 include/uapi/linux/acrn.h
[...]
+ ret = hcall_create_vm(virt_to_phys(vm_param));
+ if (ret < 0 || vm_param->vmid == ACRN_INVALID_VMID) {
+ dev_err(vm->dev, "Failed to create VM! Error: %d\n", ret);
+ return NULL;
+ }
+
+ vm->vmid = vm_param->vmid;
+ vm->vcpu_num = vm_param->vcpu_num;
+
+ write_lock_bh(_vm_list_lock);
+ list_add(>list, _vm_list);
>>>
>>> Wait, why do you have a global list of devices? Shouldn't that device
>>> be tied to the vm structure? Who will be iterating this list that does
>>> not have the file handle to start with?
>>
>> Active VMs in this list will be used by the I/O requests dispatching
>> tasklet ioreq_tasklet, whose callback function is ioreq_tasklet_handler()
>> in patch 0009. ioreq_tasklet_handler() currently handles the notification
>> interrupt from the hypervisor and dispatches I/O requests to each VMs.
>
> So you need to somehow look through the whole list of devices for every
> I/O request? That feels really really wrong, why don't you have that
> pointer in the first place?
>
> Again, step back and describe what you need/desire and then think about
> how to best solve that. Almost always, a list of objects that you have
> to iterate over all the time is not the way to do it...
Each VM has a shared buffer for I/O requests passing with the
hypervisor. Currently, the hypervisor doesn't indicate the VMs which has
pending I/O requests. So when kernel get the notification interrupt, it
search all VMs' shared buffer and dispatch the pending I/O requests.
The current I/O requests dispatching implementation uses one global
tasklet (be scheduled in the hypervisor notification interrupt), so it
needs to iterate all VMs to do the dispatching.
Each VM has a dedicated hypervisor notification interrupt vector might
be suited (a vector can be linked with a VM). The disadvantage is that
it might occupy many vectors.
Looking forward to more suggestions. Thanks very much.
>
> Somedays I think we need an "here's how to do the things you really need
> to do in a driver" chapter in the Linux Device Driver's book..
That will be great. :)
Thanks
shuo
Re: [v4,3/4] reset-controller: ti: introduce a new reset handler
On Wed, 2020-09-09 at 23:39 +0800, Suman Anna wrote:
> On 9/8/20 9:57 PM, Crystal Guo wrote:
> > On Thu, 2020-09-03 at 07:40 +0800, Suman Anna wrote:
> >> Hi Crystal,
> >>
> >> On 8/16/20 10:03 PM, Crystal Guo wrote:
> >>> Introduce ti_syscon_reset() to integrate assert and deassert together.
> >>> If some modules need do serialized assert and deassert operations
> >>> to reset itself, reset_control_reset can be called for convenience.
> >>
> >> There are multiple changes in this same patch. I think you should split
> >> this
> >> functionality away from the change for the regmap_update_bits() to
> >> regmap_write_bits(), similar to what you have done in your v2 Patch 4.
> >>
> >
> > Thanks for your suggestion.
> > I will split this patch in the next version.
> >
> >>>
> >>> Such as reset-qcom-aoss.c, it integrates assert and deassert together
> >>> by 'reset' method. MTK Socs also need this method to perform reset.
> >>>
> >>> Signed-off-by: Crystal Guo
> >>> ---
> >>> drivers/reset/reset-ti-syscon.c | 26 --
> >>> 1 file changed, 24 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/drivers/reset/reset-ti-syscon.c
> >>> b/drivers/reset/reset-ti-syscon.c
> >>> index a2635c21db7f..08289342f9af 100644
> >>> --- a/drivers/reset/reset-ti-syscon.c
> >>> +++ b/drivers/reset/reset-ti-syscon.c
> >>> @@ -15,6 +15,7 @@
> >>> * GNU General Public License for more details.
> >>> */
> >>>
> >>> +#include
> >>> #include
> >>> #include
> >>> #include
> >>> @@ -56,6 +57,7 @@ struct ti_syscon_reset_data {
> >>> struct regmap *regmap;
> >>> struct ti_syscon_reset_control *controls;
> >>> unsigned int nr_controls;
> >>> + unsigned int reset_duration_us;
> >>> };
> >>>
> >>> #define to_ti_syscon_reset_data(rcdev) \
> >>> @@ -89,7 +91,7 @@ static int ti_syscon_reset_assert(struct
> >>> reset_controller_dev *rcdev,
> >>> mask = BIT(control->assert_bit);
> >>> value = (control->flags & ASSERT_SET) ? mask : 0x0;
> >>>
> >>> - return regmap_update_bits(data->regmap, control->assert_offset, mask,
> >>> value);
> >>> + return regmap_write_bits(data->regmap, control->assert_offset, mask,
> >>> value);
> >>> }
> >>>
> >>> /**
> >>> @@ -120,7 +122,7 @@ static int ti_syscon_reset_deassert(struct
> >>> reset_controller_dev *rcdev,
> >>> mask = BIT(control->deassert_bit);
> >>> value = (control->flags & DEASSERT_SET) ? mask : 0x0;
> >>>
> >>> - return regmap_update_bits(data->regmap, control->deassert_offset, mask,
> >>> value);
> >>> + return regmap_write_bits(data->regmap, control->deassert_offset, mask,
> >>> value);
> >>> }
> >>>
> >>> /**
> >>> @@ -158,9 +160,26 @@ static int ti_syscon_reset_status(struct
> >>> reset_controller_dev *rcdev,
> >>> !(control->flags & STATUS_SET);
> >>> }
> >>>
> >>> +static int ti_syscon_reset(struct reset_controller_dev *rcdev,
> >>> + unsigned long id)
> >>> +{
> >>> + struct ti_syscon_reset_data *data = to_ti_syscon_reset_data(rcdev);
> >>> + int ret;
> >>> +
> >>> + ret = ti_syscon_reset_assert(rcdev, id);
> >>> + if (ret)
> >>> + return ret;
> >>> +
> >>> + if (data->reset_duration_us)
> >>> + usleep_range(data->reset_duration_us, data->reset_duration_us *
> >>> 2);
> >>> +
> >>> + return ti_syscon_reset_deassert(rcdev, id);
> >>
> >> I echo Philipp's comments [1] from your original v1 series about this. We
> >> don't
> >> need a property to distinguish this, but you could add a flag using match
> >> data
> >> and Mediatek compatible, and use that within this function, or optionally
> >> set
> >> this ops based on compatible (whatever is preferred by Philipp).
> >>
> >> regards
> >> Suman
> >>
> >> [1] https://patchwork.kernel.org/comment/23519193/
> >>
> > Hi Suman, Philipp
> >
> > Which method would you recommend more?
> > 1. like v2 patch, but assign the flag "data->assert_deassert_together"
> > directly (maybe rename "assert_deassert_together" to
> > "reset_op_available")
> >
> > 2. use Mediatek compatible to decide the reset handler available or not.
>
> I would go with this option. Anyway, I think you might have to add the reset
> SoC
> data as well, based on Rob's comment on the binding.
>
> regards
> Suman
Thanks for your suggestions
I will add the following changes in the next version,
please correct me if there is any misunderstanding.
1). revert ti-syscon-reset.txt add a new mediatek reset binding doc.
2). split the patch [v4,3/4] with the change for the
regmap_update_bits() to regmap_write_bits() and the change to integrate
assert and deassert together.
3). add the reset SoC data, which contains the flag "reset_op_available"
to decide the reset handler available or not.
4). separate the dts patch from this patch sets
> >
> > Thanks
> > Crystal
> >
> >>> +}
> >>> +
> >>> static const struct reset_control_ops ti_syscon_reset_ops = {
> >>> .assert = ti_syscon_reset_assert,
> >>> .deassert = ti_syscon_reset_deassert,
Re: [PATCH v10 04/24] coresight: add coresight prefix to barrier_pkt
On Fri, Sep 11, 2020 at 06:19:18AM +0800, Mathieu Poirier wrote:
> On Fri, Aug 21, 2020 at 11:44:25AM +0800, Tingwei Zhang wrote:
> > Add coresight prefix to make it specific. It will be a export symbol.
> >
> > Signed-off-by: Mian Yousaf Kaukab
> > Signed-off-by: Tingwei Zhang
> > Reviewed-by: Suzuki K Poulose
> > Reviewed-by: Mathieu Poirier
> > ---
> > drivers/hwtracing/coresight/coresight-etb10.c | 2 +-
> > drivers/hwtracing/coresight/coresight-priv.h| 8
> > drivers/hwtracing/coresight/coresight-tmc-etf.c | 2 +-
> > drivers/hwtracing/coresight/coresight.c | 2 +-
> > 4 files changed, 7 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/hwtracing/coresight/coresight-etb10.c
> b/drivers/hwtracing/coresight/coresight-etb10.c
> > index 03e3f2590191..04ee9cda988d 100644
> > --- a/drivers/hwtracing/coresight/coresight-etb10.c
> > +++ b/drivers/hwtracing/coresight/coresight-etb10.c
> > @@ -525,7 +525,7 @@ static unsigned long etb_update_buffer(struct
> coresight_device *csdev,
> >
> > cur = buf->cur;
> > offset = buf->offset;
> > - barrier = barrier_pkt;
> > + barrier = coresight_barrier_pkt;
> >
> > for (i = 0; i < to_read; i += 4) {
> > buf_ptr = buf->data_pages[cur] + offset;
> > diff --git a/drivers/hwtracing/coresight/coresight-priv.h
> b/drivers/hwtracing/coresight/coresight-priv.h
> > index d801a2755432..dcb8aeb6af62 100644
> > --- a/drivers/hwtracing/coresight/coresight-priv.h
> > +++ b/drivers/hwtracing/coresight/coresight-priv.h
> > @@ -66,8 +66,8 @@ static DEVICE_ATTR_RO(name)
> > #define coresight_simple_reg64(type, name, lo_off, hi_off) \
> > __coresight_simple_func(type, NULL, name, lo_off, hi_off)
> >
> > -extern const u32 barrier_pkt[4];
> > -#define CORESIGHT_BARRIER_PKT_SIZE (sizeof(barrier_pkt))
> > +extern const u32 coresight_barrier_pkt[4];
> > +#define CORESIGHT_BARRIER_PKT_SIZE (sizeof(coresight_barrier_pkt))
> >
> > enum etm_addr_type {
> > ETM_ADDR_TYPE_NONE,
> > @@ -104,10 +104,10 @@ struct cs_buffers {
> > static inline void coresight_insert_barrier_packet(void *buf)
> > {
> > if (buf)
> > - memcpy(buf, barrier_pkt, CORESIGHT_BARRIER_PKT_SIZE);
> > + memcpy(buf, coresight_barrier_pkt,
> > + CORESIGHT_BARRIER_PKT_SIZE);
>
> Didn't I comment on this before?
>
Sorry for missing below comment from you, Mathieu.
Indentation problem.
I'll fix it in v11.
Thanks,
Tingwei
> > }
> >
> > -
> > static inline void CS_LOCK(void __iomem *addr)
> > {
> > do {
> > diff --git a/drivers/hwtracing/coresight/coresight-tmc-etf.c
> b/drivers/hwtracing/coresight/coresight-tmc-etf.c
> > index 6375504ba8b0..44402d413ebb 100644
> > --- a/drivers/hwtracing/coresight/coresight-tmc-etf.c
> > +++ b/drivers/hwtracing/coresight/coresight-tmc-etf.c
> > @@ -519,7 +519,7 @@ static unsigned long tmc_update_etf_buffer(struct
> coresight_device *csdev,
> >
> > cur = buf->cur;
> > offset = buf->offset;
> > - barrier = barrier_pkt;
> > + barrier = coresight_barrier_pkt;
> >
> > /* for every byte to read */
> > for (i = 0; i < to_read; i += 4) {
> > diff --git a/drivers/hwtracing/coresight/coresight.c
> b/drivers/hwtracing/coresight/coresight.c
> > index e9c90f2de34a..d515088cc47d 100644
> > --- a/drivers/hwtracing/coresight/coresight.c
> > +++ b/drivers/hwtracing/coresight/coresight.c
> > @@ -53,7 +53,7 @@ static struct list_head *stm_path;
> > * beginning of the data collected in a buffer. That way the decoder
> knows that
> > * it needs to look for another sync sequence.
> > */
> > -const u32 barrier_pkt[4] = {0x7fff, 0x7fff, 0x7fff,
> 0x7fff};
> > +const u32 coresight_barrier_pkt[4] = {0x7fff, 0x7fff,
> 0x7fff, 0x7fff};
> >
> > static int coresight_id_match(struct device *dev, void *data)
> > {
> > --
> > The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
> Forum,
> > a Linux Foundation Collaborative Project
> >
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Re: [PATCH v2 1/5] mm,hwpoison: Take free pages off the buddy freelists
On Tue, Sep 08, 2020 at 09:56:22AM +0200, Oscar Salvador wrote:
> The crux of the matter is that historically we left poisoned pages
> in the buddy system because we have some checks in place when
> allocating a page that a gatekeeper for poisoned pages.
> Unfortunately, we do have other users (e.g: compaction [1]) that scan
> buddy freelists and try to get a page from there without checking
> whether the page is HWPoison.
>
> As I stated already, I think it is fundamentally wrong to keep
> HWPoison pages within the buddy systems, checks in place or not.
>
> Let us fix this we same way we did for soft_offline [2], and take
> the page off the buddy freelist, so it is completely unreachable.
>
> Note that this is fairly simple to trigger, as we only need
> to poison free buddy pages (madvise MADV_HWPOISON) and then we need
> to run some sort of memory stress system.
>
> Just for a matter of reference, I put a dump_page in compaction_alloc
> to trigger for HWPoison patches:
>
> kernel: page:12b2982b refcount:1 mapcount:0 mapping:
> index:0x1 pfn:0x1d5db
> kernel: flags: 0xfc080(hwpoison)
> kernel: raw: 000fc080 ea7573c8 c9857de0
>
> kernel: raw: 0001 0001
>
> kernel: page dumped because: compaction_alloc
>
> kernel: CPU: 4 PID: 123 Comm: kcompactd0 Tainted: GE
> 5.9.0-rc2-mm1-1-default+ #5
> kernel: Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
> rel-1.10.2-0-g5f4c7b1-prebuilt.qemu-project.org 04/01/2014
> kernel: Call Trace:
> kernel: dump_stack+0x6d/0x8b
> kernel: compaction_alloc+0xb2/0xc0
> kernel: migrate_pages+0x2a6/0x12a0
> kernel: ? isolate_freepages+0xc80/0xc80
> kernel: ? __ClearPageMovable+0xb0/0xb0
> kernel: compact_zone+0x5eb/0x11c0
> kernel: ? finish_task_switch+0x74/0x300
> kernel: ? lock_timer_base+0xa8/0x170
> kernel: proactive_compact_node+0x89/0xf0
> kernel: ? kcompactd+0x2d0/0x3a0
> kernel: kcompactd+0x2d0/0x3a0
> kernel: ? finish_wait+0x80/0x80
> kernel: ? kcompactd_do_work+0x350/0x350
> kernel: kthread+0x118/0x130
> kernel: ? kthread_associate_blkcg+0xa0/0xa0
> kernel: ret_from_fork+0x22/0x30
>
> After that, if e.g: someone faults in the page, that someone will get killed
> unexpectedly.
>
> While we are at it, I also changed the action result for such cases.
> I think that MF_DELAYED is a bit misleading, because in case we could
> contain the page and take it off the buddy, such a page is not to be
> used again unless it is unpoison, so we "fixed" the situation.
Thanks for pointing out this.
Originally (before the reported issue related to compaction is recognized),
this case is categorized as MF_DELAYED because the error page is to be
removed from buddy later when page allocator finds it in subsequent
allocation time (not in memory_failure() time).
But this patch changes the situation, and the removal from buddy is done
immediately in memory_failure(), so ...
>
> So unless I am missing something, I strongly think that we should report
> MF_RECOVERED.
this change looks correct to me.
>
> [1] https://lore.kernel.org/linux-mm/20190826104144.GA7849@linux/T/#u
> [2] https://patchwork.kernel.org/patch/11694847/
>
> Signed-off-by: Oscar Salvador
> ---
> mm/memory-failure.c | 28 ++--
> 1 file changed, 22 insertions(+), 6 deletions(-)
>
> diff --git a/mm/memory-failure.c b/mm/memory-failure.c
> index 696505f56910..b0ef5db45ba6 100644
> --- a/mm/memory-failure.c
> +++ b/mm/memory-failure.c
> @@ -1323,8 +1323,9 @@ int memory_failure(unsigned long pfn, int flags)
> struct page *hpage;
> struct page *orig_head;
> struct dev_pagemap *pgmap;
> - int res;
> unsigned long page_flags;
> + int res = 0;
> + bool retry = true;
>
> if (!sysctl_memory_failure_recovery)
> panic("Memory failure on page %lx", pfn);
> @@ -1364,10 +1365,21 @@ int memory_failure(unsigned long pfn, int flags)
>* In fact it's dangerous to directly bump up page count from 0,
>* that may make page_ref_freeze()/page_ref_unfreeze() mismatch.
>*/
> +try_again:
> if (!(flags & MF_COUNT_INCREASED) && !get_hwpoison_page(p)) {
> if (is_free_buddy_page(p)) {
> - action_result(pfn, MF_MSG_BUDDY, MF_DELAYED);
> - return 0;
> + if (take_page_off_buddy(p)) {
> + action_result(pfn, MF_MSG_BUDDY, MF_RECOVERED);
> + return 0;
> + } else {
> + /* We lost the race, try again */
> + if (retry) {
> + retry = false;
> + goto try_again;
> + }
> + action_result(pfn, MF_MSG_BUDDY, MF_IGNORED);
According to
Re: [PATCH RESEND v3 04/11] usb: xhci-rcar: convert to readl_poll_timeout_atomic()
On Thu, 2020-09-10 at 14:12 +0100, Daniel Thompson wrote:
> On Thu, Sep 10, 2020 at 04:21:45PM +0800, Chunfeng Yun wrote:
> > Use readl_poll_timeout_atomic() to simplify code
> >
> > Cc: Mathias Nyman
> > Cc: Yoshihiro Shimoda
> > Signed-off-by: Chunfeng Yun
> > ---
> > v2~v3: no changes
> > ---
> > drivers/usb/host/xhci-rcar.c | 43
> > ---
> > 1 file changed, 12 insertions(+), 31 deletions(-)
> >
> > diff --git a/drivers/usb/host/xhci-rcar.c b/drivers/usb/host/xhci-rcar.c
> > index c1025d3..74f836f 100644
> > --- a/drivers/usb/host/xhci-rcar.c
> > +++ b/drivers/usb/host/xhci-rcar.c
> > @@ -6,6 +6,7 @@
> > */
> >
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -127,8 +128,7 @@ static int xhci_rcar_download_firmware(struct usb_hcd
> > *hcd)
> > void __iomem *regs = hcd->regs;
> > struct xhci_plat_priv *priv = hcd_to_xhci_priv(hcd);
> > const struct firmware *fw;
> > - int retval, index, j, time;
> > - int timeout = 1;
> > + int retval, index, j;
> > u32 data, val, temp;
> > u32 quirks = 0;
> > const struct soc_device_attribute *attr;
> > @@ -166,32 +166,19 @@ static int xhci_rcar_download_firmware(struct usb_hcd
> > *hcd)
> > temp |= RCAR_USB3_DL_CTRL_FW_SET_DATA0;
> > writel(temp, regs + RCAR_USB3_DL_CTRL);
> >
> > - for (time = 0; time < timeout; time++) {
> > - val = readl(regs + RCAR_USB3_DL_CTRL);
> > - if ((val & RCAR_USB3_DL_CTRL_FW_SET_DATA0) == 0)
> > - break;
> > - udelay(1);
> > - }
> > - if (time == timeout) {
> > - retval = -ETIMEDOUT;
> > + retval = readl_poll_timeout_atomic(regs + RCAR_USB3_DL_CTRL,
> > + val, !(val & RCAR_USB3_DL_CTRL_FW_SET_DATA0),
> > + 1, 1);
> > + if (retval < 0)
> > break;
> > - }
> > }
> >
> > temp = readl(regs + RCAR_USB3_DL_CTRL);
> > temp &= ~RCAR_USB3_DL_CTRL_ENABLE;
> > writel(temp, regs + RCAR_USB3_DL_CTRL);
> >
> > - for (time = 0; time < timeout; time++) {
> > - val = readl(regs + RCAR_USB3_DL_CTRL);
> > - if (val & RCAR_USB3_DL_CTRL_FW_SUCCESS) {
> > - retval = 0;
> > - break;
> > - }
> > - udelay(1);
> > - }
> > - if (time == timeout)
> > - retval = -ETIMEDOUT;
> > + retval = readl_poll_timeout_atomic((regs + RCAR_USB3_DL_CTRL),
> > + val, (val & RCAR_USB3_DL_CTRL_FW_SUCCESS), 1, 1);
>
> Directly assigning to retval at this point will clobber a previous
> -ETIMEDOUT error.
>
> In other words if there is a timeout waiting for FW_SET_DATA0, but not for
> DW_SUCCESS, then we will return the wrong return value.
Yes, agree with you, but seems I keep its original logic unchanged.
Hi Yoshihiro,
What do think about Daniel's suggestion? should I fix it up?
>
>
> Daniel.
>
>
> >
> > release_firmware(fw);
> >
> > @@ -200,18 +187,12 @@ static int xhci_rcar_download_firmware(struct usb_hcd
> > *hcd)
> >
> > static bool xhci_rcar_wait_for_pll_active(struct usb_hcd *hcd)
> > {
> > - int timeout = 1000;
> > + int retval;
> > u32 val, mask = RCAR_USB3_AXH_STA_PLL_ACTIVE_MASK;
> >
> > - while (timeout > 0) {
> > - val = readl(hcd->regs + RCAR_USB3_AXH_STA);
> > - if ((val & mask) == mask)
> > - return true;
> > - udelay(1);
> > - timeout--;
> > - }
> > -
> > - return false;
> > + retval = readl_poll_timeout_atomic(hcd->regs + RCAR_USB3_AXH_STA,
> > + val, ((val & mask) == mask), 1, 1000);
> > + return !!retval;
>
> This function returns a bool so !! is either wrong or redundant... I
> think in this case it is wrong and should be a single ! .
Yes, will fix it
Thanks a lot
>
>
> Daniel.
Re: [PATCHSET 0/4] perf stat: Add --multiply-cgroup option
Hi Andi, On Fri, Sep 11, 2020 at 1:05 AM Andi Kleen wrote: > > On Tue, Sep 08, 2020 at 01:42:24PM +0900, Namhyung Kim wrote: > > When we profile cgroup events with perf stat, it's very annoying to > > specify events and cgroups on the command line as it requires the > > mapping between events and cgroups. (Note that perf record can use > > cgroup sampling but it's not usable for perf stat). > > The problem is real, but I don't really like your solution. > The option is ugly. Should rather be solved with some suitable > syntax in the expression parser to express: apply to all, > instead of adding adhoc options like this. Yeah, I'd admit that I'm terrible at naming. :) I'm open to any suggestions as I'm also bad at making new syntax.. But as Ian said, my approach takes care of the common case without dealing with controversial syntax changes. > > There are some additional problems that really need to be eventually > solved too: > > - If you use the old syntax and some cgroups are not covered you don't > get any warning. At least that should be fixed too. I don't follow. Do you mean like when -G option and --multiply-cgroup option is used at the same time? Or when -G option doesn't match to -e option? > > - And of course if everything works it is still very slow for the kernel > because there are so many perf events to handle. Long term we probably > need some more flexible way to just specify for given perf events which set of > cgroups they should apply, so that sharing and low overhead monitoring > of many cgroups is possible I hate to say it, but maybe some eBPF filter > is the solution here. Yes, I'm also interested in improving that too. Thanks Namhyung
