Re: [PATCH v3 1/2] s390/kvm: extend kvm_s390_shadow_fault to return entry pointer
On 09.02.21 16:43, Claudio Imbrenda wrote:
Extend kvm_s390_shadow_fault to return the pointer to the valid leaf
DAT table entry, or to the invalid entry.
Also return some flags in the lower bits of the address:
DAT_PROT: indicates that DAT protection applies because of the
protection bit in the segment (or, if EDAT, region) tables
NOT_PTE: indicates that the address of the DAT table entry returned
does not refer to a PTE, but to a segment or region table.
I've been thinking about one possible issue, but I think it's not
actually an issue. Just sharing so others can verify:
In case our guest uses huge pages / gigantic pages / ASCE R, we create
fake page tables (GMAP_SHADOW_FAKE_TABLE).
So, it could be that kvm_s390_shadow_fault()->gmap_shadow_pgt_lookup()
succeeds, however, we have a fake PTE in our hands. We lost the
actual guest STE/RTE address. (I think it could be recovered somehow via
page->index, thought)
But I guess, if there is a fake PTE, then there is not acutally
something that could go wrong in gmap_shadow_page() anymore that could
lead us in responding something wrong to the guest. We can only really
fail with -EINVAL, -ENOMEM or -EFAULT.
So if the guest changed anything in the meantime (e.g., zap a segment),
we would have unshadowed the whole fake page table hierarchy and would
simply retry.
Signed-off-by: Claudio Imbrenda
Cc: sta...@vger.kernel.org
---
arch/s390/kvm/gaccess.c | 30 +-
arch/s390/kvm/gaccess.h | 5 -
arch/s390/kvm/vsie.c| 8
3 files changed, 33 insertions(+), 10 deletions(-)
diff --git a/arch/s390/kvm/gaccess.c b/arch/s390/kvm/gaccess.c
index 6d6b57059493..e0ab83f051d2 100644
--- a/arch/s390/kvm/gaccess.c
+++ b/arch/s390/kvm/gaccess.c
@@ -976,7 +976,9 @@ int kvm_s390_check_low_addr_prot_real(struct kvm_vcpu
*vcpu, unsigned long gra)
* kvm_s390_shadow_tables - walk the guest page table and create shadow tables
* @sg: pointer to the shadow guest address space structure
* @saddr: faulting address in the shadow gmap
- * @pgt: pointer to the page table address result
+ * @pgt: pointer to the beginning of the page table for the given address if
+ * successful (return value 0), or to the first invalid DAT entry in
+ * case of exceptions (return value > 0)
* @fake: pgt references contiguous guest memory block, not a pgtable
*/
static int kvm_s390_shadow_tables(struct gmap *sg, unsigned long saddr,
@@ -1034,6 +1036,7 @@ static int kvm_s390_shadow_tables(struct gmap *sg,
unsigned long saddr,
rfte.val = ptr;
goto shadow_r2t;
}
+ *pgt = ptr + vaddr.rfx * 8;
rc = gmap_read_table(parent, ptr + vaddr.rfx * 8, );
Using
gmap_read_table(parent, *pgt, );
or similar with a local variable might then be even clearer. But no
strong opinion.
if (rc)
return rc;
@@ -1060,6 +1063,7 @@ static int kvm_s390_shadow_tables(struct gmap *sg,
unsigned long saddr,
rste.val = ptr;
goto shadow_r3t;
}
+ *pgt = ptr + vaddr.rsx * 8;
rc = gmap_read_table(parent, ptr + vaddr.rsx * 8, );
if (rc)
return rc;
@@ -1087,6 +1091,7 @@ static int kvm_s390_shadow_tables(struct gmap *sg,
unsigned long saddr,
rtte.val = ptr;
goto shadow_sgt;
}
+ *pgt = ptr + vaddr.rtx * 8;
rc = gmap_read_table(parent, ptr + vaddr.rtx * 8, );
if (rc)
return rc;
@@ -1123,6 +1128,7 @@ static int kvm_s390_shadow_tables(struct gmap *sg,
unsigned long saddr,
ste.val = ptr;
goto shadow_pgt;
}
+ *pgt = ptr + vaddr.sx * 8;
rc = gmap_read_table(parent, ptr + vaddr.sx * 8, );
if (rc)
return rc;
@@ -1157,6 +1163,8 @@ static int kvm_s390_shadow_tables(struct gmap *sg,
unsigned long saddr,
* @vcpu: virtual cpu
* @sg: pointer to the shadow guest address space structure
* @saddr: faulting address in the shadow gmap
+ * @datptr: will contain the address of the faulting DAT table entry, or of
+ * the valid leaf, plus some flags
*
* Returns: - 0 if the shadow fault was successfully resolved
*- > 0 (pgm exception code) on exceptions while faulting
@@ -1165,11 +1173,11 @@ static int kvm_s390_shadow_tables(struct gmap *sg,
unsigned long saddr,
*- -ENOMEM if out of memory
*/
int kvm_s390_shadow_fault(struct kvm_vcpu *vcpu, struct gmap *sg,
- unsigned long saddr)
+ unsigned long saddr, unsigned long *datptr)
{
union vaddress vaddr;
union page_table_entry pte;
- unsigned long pgt;
+
Re: [PATCH] perf: Replace lkml.org links with lore
Hello,
On Thu, Feb 11, 2021 at 8:42 AM Kees Cook wrote:
>
> As started by commit 05a5f51ca566 ("Documentation: Replace lkml.org
> links with lore"), replace lkml.org links with lore to better use a
> single source that's more likely to stay available long-term.
>
> Signed-off-by: Kees Cook
Acked-by: Namhyung Kim
Thanks,
Namhyung
> ---
> tools/perf/Documentation/examples.txt | 2 +-
> tools/perf/util/data-convert-bt.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/tools/perf/Documentation/examples.txt
> b/tools/perf/Documentation/examples.txt
> index a4e392156488..c0d22fbe9201 100644
> --- a/tools/perf/Documentation/examples.txt
> +++ b/tools/perf/Documentation/examples.txt
> @@ -3,7 +3,7 @@
> ** perf by examples **
> --
>
> -[ From an e-mail by Ingo Molnar, http://lkml.org/lkml/2009/8/4/346 ]
> +[ From an e-mail by Ingo Molnar,
> https://lore.kernel.org/lkml/20090804195717.ga5...@elte.hu ]
>
>
> First, discovery/enumeration of available counters can be done via
> diff --git a/tools/perf/util/data-convert-bt.c
> b/tools/perf/util/data-convert-bt.c
> index 27c5fef9ad54..8b67bd97d122 100644
> --- a/tools/perf/util/data-convert-bt.c
> +++ b/tools/perf/util/data-convert-bt.c
> @@ -948,7 +948,7 @@ static char *change_name(char *name, char *orig_name, int
> dup)
> goto out;
> /*
> * Add '_' prefix to potential keywork. According to
> -* Mathieu Desnoyers (https://lkml.org/lkml/2015/1/23/652),
> +* Mathieu Desnoyers
> (https://lore.kernel.org/lkml/1074266107.40857.1422045946295.javamail.zim...@efficios.com),
> * futher CTF spec updating may require us to use '$'.
> */
> if (dup < 0)
> --
> 2.25.1
>
Re: [PATCH v2 net-next 04/11] net: bridge: offload initial and final port flags through switchdev
On Thu, Feb 11, 2021 at 09:44:43AM +0200, Ido Schimmel wrote:
> On Thu, Feb 11, 2021 at 01:23:52AM +0200, Vladimir Oltean wrote:
> > On Wed, Feb 10, 2021 at 12:59:49PM +0200, Ido Schimmel wrote:
> > > > > The reverse, during unlinking, would be to refuse unlinking if the
> > > > > upper
> > > > > has uppers of its own. netdev_upper_dev_unlink() needs to learn to
> > > > > return an error and callers such as team/bond need to learn to handle
> > > > > it, but it seems patchable.
> > > >
> > > > Again, this was treated prior to my deletion in this series and not by
> > > > erroring out, I just really didn't think it through.
> > > >
> > > > So you're saying that if we impose that all switchdev drivers restrict
> > > > the house of cards to be constructed from the bottom up, and destructed
> > > > from the top down, then the notification of bridge port flags can stay
> > > > in the bridge layer?
> > >
> > > I actually don't think it's a good idea to have this in the bridge in
> > > any case. I understand that it makes sense for some devices where
> > > learning, flooding, etc are port attributes, but in other devices these
> > > can be {port,vlan} attributes and then you need to take care of them
> > > when a vlan is added / deleted and not only when a port is removed from
> > > the bridge. So for such devices this really won't save anything. I would
> > > thus leave it to the lower levels to decide.
> >
> > Just for my understanding, how are per-{port,vlan} attributes such as
> > learning and flooding managed by the Linux bridge? How can I disable
> > flooding only in a certain VLAN?
>
> You can't (currently). But it does not change the fact that in some
> devices these are {port,vlan} attributes and we are talking here about
> the interface towards these devices. Having these as {port,vlan}
> attributes allows you to support use cases such as a port being enslaved
> to a VLAN-aware bridge and its VLAN upper(s) enslaved to VLAN unaware
> bridge(s).
I don't think I understand the use case really. You mean something like this?
br1 (vlan_filtering=0)
/ \
/ \
swp0.100 \
| \
|(vlan_filtering \
| br0 =1) \
| / \\
|/ \\
swp0swp1 swp2
A packet received on swp0 with VLAN tag 100 will go to swp0.100 which
will be forwarded according to the FDB of br1, and will be delivered to
swp2 as untagged? Respectively in the other direction, a packet received
on swp2 will have a VLAN 100 tag pushed on egress towards swp0, even if
it is already VLAN-tagged?
What do you even use this for?
And also: if the {port,vlan} attributes can be simulated by making the
bridge port be an 8021q upper of a physical interface, then as far as
the bridge is concerned, they still are per-port attributes, and they
are per-{port,vlan} only as far as the switch driver is concerned -
therefore I don't see why it isn't okay for the bridge to notify the
brport flags in exactly the same way for them too.
> Obviously you need to ensure there is no conflict between the
> VLANs used by the VLAN-aware bridge and the VLAN device(s).
On the other hand I think I have a more real-life use case that I think
is in conflict with this last phrase.
I have a VLAN-aware bridge and I want to run PTP in VLAN 7, but I also
need to add VLAN 7 in the VLAN table of the bridge ports so that it
doesn't drop traffic. PTP is link-local, so I need to run it on VLAN
uppers of the switch ports. Like this:
ip link add br0 type bridge vlan_filtering 1
ip link set swp0 master br0
ip link set swp1 master br0
bridge vlan add dev swp0 vid 7 master
bridge vlan add dev swp1 vid 7 master
bridge vlan add dev br0 vid 7 self
ip link add link swp0 name swp0.7 type vlan id 7
ip link add link swp1 name swp0.7 type vlan id 7
ptp4l -i swp0.7 -i swp1.7 -m
How can I do that considering that you recommend avoiding conflicts
between the VLAN-aware bridge and 8021q uppers? Or is that true only
when the 8021q uppers are bridged?
Re: [PATCH v5 6/6] docs: ABI: Add sysfs documentation interface of dw-xdata-pcie driver
On Thu, Feb 11, 2021 at 11:29:14AM +0200, Leon Romanovsky wrote: > On Thu, Feb 11, 2021 at 10:08:43AM +0100, Gustavo Pimentel wrote: > > This patch describes the sysfs interface implemented on the dw-xdata-pcie > > driver. > > > > Signed-off-by: Gustavo Pimentel > > --- > > Documentation/ABI/testing/sysfs-driver-xdata | 46 > > > > 1 file changed, 46 insertions(+) > > create mode 100644 Documentation/ABI/testing/sysfs-driver-xdata > > I don't know and maybe this is how modern drivers are developed now, but my > laptop doesn't have anything driver and vendor specific related under plain > /sys/kernel/* directory. > > ➜ kernel git:(rdma-next) ls -l /sys/kernel > total 0 > drwxr-xr-x. 2 root root0 Feb 11 11:20 boot_params > drwxr-xr-x. 2 root root0 Feb 11 11:20 btf > drwxr-xr-x. 2 root root0 Feb 11 11:20 cgroup > drwxr-xr-x. 2 root root0 Feb 8 07:45 config > drwx--. 51 root root0 Feb 8 07:45 debug > -r--r--r--. 1 root root 4096 Feb 11 11:20 fscaps > drwxr-xr-x. 2 root root0 Feb 8 10:16 iommu_groups > drwxr-xr-x. 94 root root0 Feb 11 11:20 irq > -r--r--r--. 1 root root 4096 Feb 11 11:20 kexec_crash_loaded > -rw-r--r--. 1 root root 4096 Feb 11 11:20 kexec_crash_size > -r--r--r--. 1 root root 4096 Feb 11 11:20 kexec_loaded > drwxr-xr-x. 2 root root0 Feb 11 11:20 livepatch > drwxr-xr-x. 6 root root0 Feb 8 07:45 mm > -r--r--r--. 1 root root 512 Feb 11 11:20 notes > -rw-r--r--. 1 root root 4096 Feb 11 11:20 profiling > -rw-r--r--. 1 root root 4096 Feb 11 11:20 rcu_expedited > -rw-r--r--. 1 root root 4096 Feb 11 11:20 rcu_normal > drwxr-xr-x. 4 root root0 Feb 8 07:45 security > drwxr-xr-x. 163 root root0 Feb 11 11:20 slab > drwxr-xr-x. 4 root root0 Feb 11 11:20 software_nodes > drwx--. 8 root root0 Feb 8 07:45 tracing > -r--r--r--. 1 root root 4096 Feb 11 11:20 uevent_seqnum > -r--r--r--. 1 root root 4096 Feb 11 11:20 vmcoreinfo > > Also it is very uncommon in large subsystems to see custom sysfs entries > for the specific driver. I wonder why this dw-xdata-pcie driver is different. It is not, and should not do that at all.
Re: [PATCH v2] dt-bindings: spi: zynq: Convert Zynq QSPI binding to yaml
st 10. 2. 2021 v 11:10 odesílatel Michal Simek napsal:
>
> Convert spi-zynq-qspi.txt to yaml.
>
> Signed-off-by: Michal Simek
> ---
>
> Changes in v2:
> - s/additionalProperties: true/unevaluatedProperties: false/
>
> .../devicetree/bindings/spi/spi-zynq-qspi.txt | 25
> .../bindings/spi/xlnx,zynq-qspi.yaml | 59 +++
> MAINTAINERS | 1 +
> 3 files changed, 60 insertions(+), 25 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/spi/spi-zynq-qspi.txt
> create mode 100644 Documentation/devicetree/bindings/spi/xlnx,zynq-qspi.yaml
>
> diff --git a/Documentation/devicetree/bindings/spi/spi-zynq-qspi.txt
> b/Documentation/devicetree/bindings/spi/spi-zynq-qspi.txt
> deleted file mode 100644
> index 16b734ad3102..
> --- a/Documentation/devicetree/bindings/spi/spi-zynq-qspi.txt
> +++ /dev/null
> @@ -1,25 +0,0 @@
> -Xilinx Zynq QSPI controller Device Tree Bindings
>
> -
> -Required properties:
> -- compatible : Should be "xlnx,zynq-qspi-1.0".
> -- reg : Physical base address and size of QSPI registers
> map.
> -- interrupts : Property with a value describing the interrupt
> - number.
> -- clock-names : List of input clock names - "ref_clk", "pclk"
> - (See clock bindings for details).
> -- clocks : Clock phandles (see clock bindings for details).
> -
> -Optional properties:
> -- num-cs : Number of chip selects used.
> -
> -Example:
> - qspi: spi@e000d000 {
> - compatible = "xlnx,zynq-qspi-1.0";
> - reg = <0xe000d000 0x1000>;
> - interrupt-parent = <>;
> - interrupts = <0 19 4>;
> - clock-names = "ref_clk", "pclk";
> - clocks = < 10>, < 43>;
> - num-cs = <1>;
> - };
> diff --git a/Documentation/devicetree/bindings/spi/xlnx,zynq-qspi.yaml
> b/Documentation/devicetree/bindings/spi/xlnx,zynq-qspi.yaml
> new file mode 100644
> index ..1f1c40a9f320
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/spi/xlnx,zynq-qspi.yaml
> @@ -0,0 +1,59 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/spi/xlnx,zynq-qspi.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Xilinx Zynq QSPI controller
> +
> +description:
> + The Xilinx Zynq QSPI controller is used to access multi-bit serial flash
> + memory devices.
> +
> +allOf:
> + - $ref: "spi-controller.yaml#"
> +
> +maintainers:
> + - Michal Simek
> +
> +# Everything else is described in the common file
> +properties:
> + compatible:
> +const: xlnx,zynq-qspi-1.0
> +
> + reg:
> +maxItems: 1
> +
> + interrupts:
> +maxItems: 1
> +
> + clocks:
> +items:
> + - description: reference clock
> + - description: peripheral clock
> +
> + clock-names:
> +items:
> + - const: ref_clk
> + - const: pclk
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> + - clocks
> + - clock-names
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> +spi@e000d000 {
> +compatible = "xlnx,zynq-qspi-1.0";
> +reg = <0xe000d000 0x1000>;
> +interrupt-parent = <>;
> +interrupts = <0 19 4>;
> +clock-names = "ref_clk", "pclk";
> +clocks = < 10>, < 43>;
> +num-cs = <1>;
> +};
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 546aa66428c9..e494b061dcd1 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2766,6 +2766,7 @@ W:http://wiki.xilinx.com
> T: git https://github.com/Xilinx/linux-xlnx.git
> F: Documentation/devicetree/bindings/i2c/cdns,i2c-r1p10.yaml
> F: Documentation/devicetree/bindings/i2c/xlnx,xps-iic-2.00.a.yaml
> +F: Documentation/devicetree/bindings/spi/xlnx,zynq-qspi.yaml
> F: arch/arm/mach-zynq/
> F: drivers/block/xsysace.c
> F: drivers/clocksource/timer-cadence-ttc.c
> --
> 2.30.0
>
Applied.
M
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs
sdhci.c:undefined reference to `mmc_can_gpio_cd'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 291009f656e8eaebbdfd3a8d99f6b190a9ce9deb commit: e65bb38824711559844ba932132f417bc5a355e2 mmc: sdhci: do not enable card detect interrupt for gpio cd type date: 11 months ago config: powerpc-randconfig-r032-20210210 (attached as .config) compiler: powerpc-linux-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e65bb38824711559844ba932132f417bc5a355e2 git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout e65bb38824711559844ba932132f417bc5a355e2 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=powerpc If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): powerpc-linux-ld: warning: orphan section `.ctors.65435' from `net/wimax/op-msg.o' being placed in section `.ctors.65435' powerpc-linux-ld: warning: orphan section `.ctors.65435' from `net/wimax/op-reset.o' being placed in section `.ctors.65435' powerpc-linux-ld: warning: orphan section `.ctors.65435' from `net/wimax/op-rfkill.o' being placed in section `.ctors.65435' powerpc-linux-ld: warning: orphan section `.ctors.65435' from `net/wimax/op-state-get.o' being placed in section `.ctors.65435' powerpc-linux-ld: warning: orphan section `.ctors.65435' from `net/wimax/stack.o' being placed in section `.ctors.65435' powerpc-linux-ld: warning: orphan section `.ctors.65435' from `net/wimax/debugfs.o' being placed in section `.ctors.65435' powerpc-linux-ld: warning: orphan section `.ctors.65435' from `net/batman-adv/bat_algo.o' being placed in section `.ctors.65435' powerpc-linux-ld: warning: orphan section `.ctors.65435' from `net/batman-adv/bat_iv_ogm.o' being placed in section `.ctors.65435' powerpc-linux-ld: warning: orphan section `.ctors.65435' from `net/batman-adv/bitarray.o' being placed in section `.ctors.65435' powerpc-linux-ld: warning: orphan section `.ctors.65435' from `net/batman-adv/fragmentation.o' being placed in section `.ctors.65435' powerpc-linux-ld: warning: orphan section `.ctors.65435' from `net/batman-adv/gateway_client.o' being placed in section `.ctors.65435' powerpc-linux-ld: warning: orphan section `.ctors.65435' from `net/batman-adv/gateway_common.o' being placed in section `.ctors.65435' powerpc-linux-ld: warning: orphan section `.ctors.65435' from `net/batman-adv/hard-interface.o' being placed in section `.ctors.65435' powerpc-linux-ld: warning: orphan section `.ctors.65435' from `net/batman-adv/hash.o' being placed in section `.ctors.65435' powerpc-linux-ld: warning: orphan section `.ctors.65435' from `net/batman-adv/log.o' being placed in section `.ctors.65435' powerpc-linux-ld: warning: orphan section `.ctors.65435' from `net/batman-adv/main.o' being placed in section `.ctors.65435' powerpc-linux-ld: warning: orphan section `.ctors.65435' from `net/batman-adv/netlink.o' being placed in section `.ctors.65435' powerpc-linux-ld: warning: orphan section `.ctors.65435' from `net/batman-adv/originator.o' being placed in section `.ctors.65435' powerpc-linux-ld: warning: orphan section `.ctors.65435' from `net/batman-adv/routing.o' being placed in section `.ctors.65435' powerpc-linux-ld: warning: orphan section `.ctors.65435' from `net/batman-adv/send.o' being placed in section `.ctors.65435' powerpc-linux-ld: warning: orphan section `.ctors.65435' from `net/batman-adv/soft-interface.o' being placed in section `.ctors.65435' powerpc-linux-ld: warning: orphan section `.ctors.65435' from `net/batman-adv/tp_meter.o' being placed in section `.ctors.65435' powerpc-linux-ld: warning: orphan section `.ctors.65435' from `net/batman-adv/translation-table.o' being placed in section `.ctors.65435' powerpc-linux-ld: warning: orphan section `.ctors.65435' from `net/batman-adv/tvlv.o' being placed in section `.ctors.65435' powerpc-linux-ld: warning: orphan section `.ctors.65435' from `net/nfc/core.o' being placed in section `.ctors.65435' powerpc-linux-ld: warning: orphan section `.ctors.65435' from `net/nfc/netlink.o' being placed in section `.ctors.65435' powerpc-linux-ld: warning: orphan section `.ctors.65435' from `net/nfc/af_nfc.o' being placed in section `.ctors.65435' powerpc-linux-ld: warning: orphan section `.ctors.65435' from `net/nfc/rawsock.o' being placed in section `.ctors.65435' powerpc-linux-ld: warning: orphan section `.ctors.65435' from `net/nfc/llcp_core.o' being placed in section `.ctors.65435' powerpc-linux-ld: warning: orphan
[PATCH v8 0/6] Support ROHM BD9576MUF and BD9573MUF PMICs
Initial support for ROHM BD9576MUF and BD9573MUF PMICs. These PMICs are primarily intended to be used to power the R-Car family processors. BD9576MUF includes some additional safety features the BD9573MUF does not have. This initial version of drivers provides temperature, over voltage and under voltage warnings is IRQ information is passed via DT. This patch series includes MFD and watchdog drivers. Regulator part was already applied. This series brings in the IRQ support which will be utilized by the regulator driver(s). The regulator part was splitted in own series as it contains some changes to drivers which are not yet in other trees. WDG supports - Enabling and pinging the watchdog - configuring watchog timeout / window from device-tree Please note that not all of the boards are expected to be utilizing the warning IRQs. Thus populating the IRQ information from DT is optional. Changelog v8: - Drop regulator driver changes which are covered by the separate RFC series. - Renamed regulator driver cell. Regulator driver change will be brought in in the RFC series to avoid conflicts. - Add patch introducing register definitions required by the regulator RFC series. - Cleaned comments at MFD as was suggested by Lee - Do not abort MFD probe if IRQ information for BD9573 is populated - MFD driver/header styling Changelog v7: - Added interrupt handling - Added notifications and error_flag getter to regulators Changelog v6: - Fixed watchdog timeout Changelog v5: - rebased on top of v5.10-rc2 - few styling fixes in MFD as suggested by Lee Changelog v4: - rebased on top of 5.10-rc1 - Fix typo (repeated word maximum) from the DT binding doc Changelog v3: - use only one binding to specify watchdog time-out window. Changelog v2: - dropped already applied regulator part - dt_bindings: Fix case for regulator-names in the example - watchdod: unify probe error check and revise includes --- Matti Vaittinen (6): dt_bindings: mfd: Add ROHM BD9576MUF and BD9573MUF PMICs mfd: Support ROHM BD9576MUF and BD9573MUF mfd: bd9576: Add IRQ support wdt: Support wdt on ROHM BD9576MUF and BD9573MUF MAINTAINERS: Add ROHM BD9576MUF and BD9573MUF drivers mfd: bd9576: Add safety limit/monitoring registers .../bindings/mfd/rohm,bd9576-pmic.yaml| 123 MAINTAINERS | 4 + drivers/mfd/Kconfig | 11 + drivers/mfd/Makefile | 1 + drivers/mfd/rohm-bd9576.c | 187 +++ drivers/watchdog/Kconfig | 13 + drivers/watchdog/Makefile | 1 + drivers/watchdog/bd9576_wdt.c | 291 ++ include/linux/mfd/rohm-bd957x.h | 140 + include/linux/mfd/rohm-generic.h | 2 + 10 files changed, 773 insertions(+) create mode 100644 Documentation/devicetree/bindings/mfd/rohm,bd9576-pmic.yaml create mode 100644 drivers/mfd/rohm-bd9576.c create mode 100644 drivers/watchdog/bd9576_wdt.c create mode 100644 include/linux/mfd/rohm-bd957x.h -- 2.25.4 -- Matti Vaittinen, Linux device drivers ROHM Semiconductors, Finland SWDC Kiviharjunlenkki 1E 90220 OULU FINLAND ~~~ "I don't think so," said Rene Descartes. Just then he vanished ~~~ Simon says - in Latin please. ~~~ "non cogito me" dixit Rene Descarte, deinde evanescavit ~~~ Thanks to Simon Glass for the translation =]
[PATCH v8 2/6] mfd: Support ROHM BD9576MUF and BD9573MUF
Add core support for ROHM BD9576MUF and BD9573MUF PMICs which are
mainly used to power the R-Car series processors.
Signed-off-by: Matti Vaittinen
---
Changes:
- Comments fixed based on suggestions from Lee
- Name of regulator cell changed as suggested by Lee
- Renamed MFD cell variables for better readability
- Aligned header definitions for better readability
drivers/mfd/Kconfig | 11
drivers/mfd/Makefile | 1 +
drivers/mfd/rohm-bd9576.c| 109 +++
include/linux/mfd/rohm-bd957x.h | 59 +
include/linux/mfd/rohm-generic.h | 2 +
5 files changed, 182 insertions(+)
create mode 100644 drivers/mfd/rohm-bd9576.c
create mode 100644 include/linux/mfd/rohm-bd957x.h
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index bdfce7b15621..53c7c96283bd 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -1998,6 +1998,17 @@ config MFD_ROHM_BD71828
Also included is a Coulomb counter, a real-time clock (RTC), and
a 32.768 kHz clock gate.
+config MFD_ROHM_BD957XMUF
+ tristate "ROHM BD9576MUF and BD9573MUF Power Management ICs"
+ depends on I2C=y
+ depends on OF
+ select REGMAP_I2C
+ select MFD_CORE
+ help
+ Select this option to get support for the ROHM BD9576MUF and
+ BD9573MUF Power Management ICs. BD9576 and BD9573 are primarily
+ designed to be used to power R-Car series processors.
+
config MFD_STM32_LPTIMER
tristate "Support for STM32 Low-Power Timer"
depends on (ARCH_STM32 && OF) || COMPILE_TEST
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 14fdb188af02..e58fae024bb2 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -262,6 +262,7 @@ obj-$(CONFIG_RAVE_SP_CORE) += rave-sp.o
obj-$(CONFIG_MFD_ROHM_BD70528) += rohm-bd70528.o
obj-$(CONFIG_MFD_ROHM_BD71828) += rohm-bd71828.o
obj-$(CONFIG_MFD_ROHM_BD718XX) += rohm-bd718x7.o
+obj-$(CONFIG_MFD_ROHM_BD957XMUF) += rohm-bd9576.o
obj-$(CONFIG_MFD_STMFX)+= stmfx.o
obj-$(CONFIG_MFD_KHADAS_MCU) += khadas-mcu.o
diff --git a/drivers/mfd/rohm-bd9576.c b/drivers/mfd/rohm-bd9576.c
new file mode 100644
index ..efd439677c9e
--- /dev/null
+++ b/drivers/mfd/rohm-bd9576.c
@@ -0,0 +1,109 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (C) 2020 ROHM Semiconductors
+ *
+ * ROHM BD9576MUF and BD9573MUF PMIC driver
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static struct mfd_cell bd9573_mfd_cells[] = {
+ { .name = "bd9573-regulator", },
+ { .name = "bd9576-wdt", },
+};
+
+static struct mfd_cell bd9576_mfd_cells[] = {
+ { .name = "bd9576-regulator", },
+ { .name = "bd9576-wdt", },
+};
+
+static const struct regmap_range volatile_ranges[] = {
+ regmap_reg_range(BD957X_REG_SMRB_ASSERT, BD957X_REG_SMRB_ASSERT),
+ regmap_reg_range(BD957X_REG_PMIC_INTERNAL_STAT,
+BD957X_REG_PMIC_INTERNAL_STAT),
+ regmap_reg_range(BD957X_REG_INT_THERM_STAT, BD957X_REG_INT_THERM_STAT),
+ regmap_reg_range(BD957X_REG_INT_OVP_STAT, BD957X_REG_INT_SYS_STAT),
+ regmap_reg_range(BD957X_REG_INT_MAIN_STAT, BD957X_REG_INT_MAIN_STAT),
+};
+
+static const struct regmap_access_table volatile_regs = {
+ .yes_ranges = _ranges[0],
+ .n_yes_ranges = ARRAY_SIZE(volatile_ranges),
+};
+
+static struct regmap_config bd957x_regmap = {
+ .reg_bits = 8,
+ .val_bits = 8,
+ .volatile_table = _regs,
+ .max_register = BD957X_MAX_REGISTER,
+ .cache_type = REGCACHE_RBTREE,
+};
+
+static int bd957x_i2c_probe(struct i2c_client *i2c,
+const struct i2c_device_id *id)
+{
+ int ret;
+ struct regmap *regmap;
+ struct mfd_cell *cells;
+ int num_cells;
+ unsigned long chip_type;
+
+ chip_type = (unsigned long)of_device_get_match_data(>dev);
+
+ switch (chip_type) {
+ case ROHM_CHIP_TYPE_BD9576:
+ cells = bd9576_mfd_cells;
+ num_cells = ARRAY_SIZE(bd9576_mfd_cells);
+ break;
+ case ROHM_CHIP_TYPE_BD9573:
+ cells = bd9573_mfd_cells;
+ num_cells = ARRAY_SIZE(bd9573_mfd_cells);
+ break;
+ default:
+ dev_err(>dev, "Unknown device type");
+ return -EINVAL;
+ }
+
+ regmap = devm_regmap_init_i2c(i2c, _regmap);
+ if (IS_ERR(regmap)) {
+ dev_err(>dev, "Failed to initialize Regmap\n");
+ return PTR_ERR(regmap);
+ }
+
+ ret = devm_mfd_add_devices(>dev, PLATFORM_DEVID_AUTO, cells,
+ num_cells, NULL, 0, NULL);
+ if (ret)
+ dev_err(>dev, "Failed to create subdevices\n");
+
+ return ret;
+}
+
+static const struct of_device_id bd957x_of_match[] = {
+ {
[PATCH v8 1/6] dt_bindings: mfd: Add ROHM BD9576MUF and BD9573MUF PMICs
Add bindings for ROHM BD9576MUF and BD9573MUF PMICs. These
PMICs are primarily intended to be used to power the R-Car series
processors. They provide 6 power outputs, safety features and a
watchdog with two functional modes.
Signed-off-by: Matti Vaittinen
Reviewed-by: Rob Herring
---
Changes since v7:
- No changes
.../bindings/mfd/rohm,bd9576-pmic.yaml| 123 ++
1 file changed, 123 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/rohm,bd9576-pmic.yaml
diff --git a/Documentation/devicetree/bindings/mfd/rohm,bd9576-pmic.yaml
b/Documentation/devicetree/bindings/mfd/rohm,bd9576-pmic.yaml
new file mode 100644
index ..6483860da955
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/rohm,bd9576-pmic.yaml
@@ -0,0 +1,123 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/rohm,bd9576-pmic.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ROHM BD9576MUF and BD9573MUF Power Management Integrated Circuit
bindings
+
+maintainers:
+ - Matti Vaittinen
+
+description: |
+ BD9576MUF and BD9573MUF are power management ICs primarily intended for
+ powering the R-Car series processors.
+ The IC provides 6 power outputs with configurable sequencing and safety
+ monitoring. A watchdog logic with slow ping/windowed modes is also included.
+
+properties:
+ compatible:
+enum:
+ - rohm,bd9576
+ - rohm,bd9573
+
+ reg:
+description:
+ I2C slave address.
+maxItems: 1
+
+ interrupts:
+maxItems: 1
+
+ rohm,vout1-en-low:
+description:
+ BD9576 and BD9573 VOUT1 regulator enable state can be individually
+ controlled by a GPIO. This is dictated by state of vout1-en pin during
+ the PMIC startup. If vout1-en is LOW during PMIC startup then the VOUT1
+ enable sate is controlled via this pin. Set this property if vout1-en
+ is wired to be down at PMIC start-up.
+type: boolean
+
+ rohm,vout1-en-gpios:
+description:
+ GPIO specifier to specify the GPIO connected to vout1-en for vout1 ON/OFF
+ state control.
+maxItems: 1
+
+ rohm,ddr-sel-low:
+description:
+ The BD9576 and BD9573 output voltage for DDR can be selected by setting
+ the ddr-sel pin low or high. Set this property if ddr-sel is grounded.
+type: boolean
+
+ rohm,watchdog-enable-gpios:
+description: The GPIO line used to enable the watchdog.
+maxItems: 1
+
+ rohm,watchdog-ping-gpios:
+description: The GPIO line used to ping the watchdog.
+maxItems: 1
+
+ rohm,hw-timeout-ms:
+maxItems: 2
+description:
+ Watchog timeout in milliseconds. If single value is given it is
+ the maximum timeout. Eg. if pinging watchdog is not done within this time
+ limit the watchdog will be triggered. If two values are given watchdog
+ is configured in "window mode". Then first value is limit for short-ping
+ Eg. if watchdog is pinged sooner than that the watchdog will trigger.
+ When two values is given the second value is the maximum timeout.
+ # (HW) minimum for short timeout is 2ms, maximum 220 ms.
+ # (HW) minimum for max timeout is 4ms, maximum 4416 ms.
+
+ regulators:
+$ref: ../regulator/rohm,bd9576-regulator.yaml
+description:
+ List of child nodes that specify the regulators.
+
+required:
+ - compatible
+ - reg
+ - regulators
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+i2c {
+#address-cells = <1>;
+#size-cells = <0>;
+pmic: pmic@30 {
+compatible = "rohm,bd9576";
+reg = <0x30>;
+rohm,vout1-en-low;
+rohm,vout1-en-gpios = < 6 GPIO_ACTIVE_HIGH>;
+rohm,ddr-sel-low;
+rohm,watchdog-enable-gpios = < 6 GPIO_ACTIVE_HIGH>;
+rohm,watchdog-ping-gpios = < 7 GPIO_ACTIVE_HIGH>;
+rohm,hw-timeout-ms = <150>, <2300>;
+
+regulators {
+boost1: regulator-vd50 {
+regulator-name = "VD50";
+};
+buck1: regulator-vd18 {
+regulator-name = "VD18";
+};
+buck2: regulator-vdddr {
+regulator-name = "VDDDR";
+};
+buck3: regulator-vd10 {
+regulator-name = "VD10";
+};
+ldo: regulator-voutl1 {
+regulator-name = "VOUTL1";
+};
+sw: regulator-vouts1 {
+regulator-name = "VOUTS1";
+};
+};
+};
+};
--
2.25.4
--
Matti Vaittinen, Linux device drivers
ROHM Semiconductors, Finland SWDC
Kiviharjunlenkki 1E
90220 OULU
FINLAND
~~~ "I don't think so," said Rene Descartes. Just then he vanished ~~~
Simon says - in Latin please.
~~~ "non cogito me" dixit Rene Descarte, deinde evanescavit ~~~
[PATCH v8 3/6] mfd: bd9576: Add IRQ support
BD9573 and BD9576 support set of "protection" interrupts for "fatal"
issues. Those lead to SOC reset as PMIC shuts the power outputs. Thus
there is no relevant IRQ handling for them.
Few "detection" interrupts were added to the BD9576 with the idea that
SOC could take some recovery-action before error gets unrecoverable.
Unfortunately the BD9576 interrupt logic was not re-evaluated. IRQs
are not designed to be properly acknowleged - and IRQ line is kept
active for whole duration of error condition (in comparison to
informing only about state change).
For above reason, do not consider missing IRQ as error.
Signed-off-by: Matti Vaittinen
---
Changes since v7:
- Do not fail probe is BD9573 IRQ information is populated
- Comment clean-up/clarifications as suggested by Lee
drivers/mfd/rohm-bd9576.c | 80 -
include/linux/mfd/rohm-bd957x.h | 62 +
2 files changed, 141 insertions(+), 1 deletion(-)
diff --git a/drivers/mfd/rohm-bd9576.c b/drivers/mfd/rohm-bd9576.c
index efd439677c9e..6084f9a0aa1c 100644
--- a/drivers/mfd/rohm-bd9576.c
+++ b/drivers/mfd/rohm-bd9576.c
@@ -17,12 +17,27 @@
#include
#include
+/*
+ * Due to the BD9576MUF nasty IRQ behaiour we don't always populate IRQs.
+ * These will be added to regulator resources only if IRQ information for the
+ * PMIC is populated in device-tree.
+ */
+static const struct resource bd9576_regulator_irqs[] = {
+ DEFINE_RES_IRQ_NAMED(BD9576_INT_THERM, "bd9576-temp"),
+ DEFINE_RES_IRQ_NAMED(BD9576_INT_OVD, "bd9576-ovd"),
+ DEFINE_RES_IRQ_NAMED(BD9576_INT_UVD, "bd9576-uvd"),
+};
+
static struct mfd_cell bd9573_mfd_cells[] = {
{ .name = "bd9573-regulator", },
{ .name = "bd9576-wdt", },
};
static struct mfd_cell bd9576_mfd_cells[] = {
+ /*
+* Please keep regulators as first cell as resources may be overwritten
+* from probe and the code expects regulators to be at index 0.
+*/
{ .name = "bd9576-regulator", },
{ .name = "bd9576-wdt", },
};
@@ -49,6 +64,29 @@ static struct regmap_config bd957x_regmap = {
.cache_type = REGCACHE_RBTREE,
};
+static struct regmap_irq bd9576_irqs[] = {
+ REGMAP_IRQ_REG(BD9576_INT_THERM, 0, BD957X_MASK_INT_MAIN_THERM),
+ REGMAP_IRQ_REG(BD9576_INT_OVP, 0, BD957X_MASK_INT_MAIN_OVP),
+ REGMAP_IRQ_REG(BD9576_INT_SCP, 0, BD957X_MASK_INT_MAIN_SCP),
+ REGMAP_IRQ_REG(BD9576_INT_OCP, 0, BD957X_MASK_INT_MAIN_OCP),
+ REGMAP_IRQ_REG(BD9576_INT_OVD, 0, BD957X_MASK_INT_MAIN_OVD),
+ REGMAP_IRQ_REG(BD9576_INT_UVD, 0, BD957X_MASK_INT_MAIN_UVD),
+ REGMAP_IRQ_REG(BD9576_INT_UVP, 0, BD957X_MASK_INT_MAIN_UVP),
+ REGMAP_IRQ_REG(BD9576_INT_SYS, 0, BD957X_MASK_INT_MAIN_SYS),
+};
+
+static struct regmap_irq_chip bd9576_irq_chip = {
+ .name = "bd9576_irq",
+ .irqs = _irqs[0],
+ .num_irqs = ARRAY_SIZE(bd9576_irqs),
+ .status_base = BD957X_REG_INT_MAIN_STAT,
+ .mask_base = BD957X_REG_INT_MAIN_MASK,
+ .ack_base = BD957X_REG_INT_MAIN_STAT,
+ .init_ack_masked = true,
+ .num_regs = 1,
+ .irq_reg_stride = 1,
+};
+
static int bd957x_i2c_probe(struct i2c_client *i2c,
const struct i2c_device_id *id)
{
@@ -57,6 +95,8 @@ static int bd957x_i2c_probe(struct i2c_client *i2c,
struct mfd_cell *cells;
int num_cells;
unsigned long chip_type;
+ struct irq_domain *domain;
+ bool usable_irqs;
chip_type = (unsigned long)of_device_get_match_data(>dev);
@@ -64,10 +104,16 @@ static int bd957x_i2c_probe(struct i2c_client *i2c,
case ROHM_CHIP_TYPE_BD9576:
cells = bd9576_mfd_cells;
num_cells = ARRAY_SIZE(bd9576_mfd_cells);
+ usable_irqs = !!i2c->irq;
break;
case ROHM_CHIP_TYPE_BD9573:
cells = bd9573_mfd_cells;
num_cells = ARRAY_SIZE(bd9573_mfd_cells);
+ /*
+* BD9573 only supports fatal IRQs which we can not handle
+* because SoC is going to lose the power.
+*/
+ usable_irqs = false;
break;
default:
dev_err(>dev, "Unknown device type");
@@ -79,9 +125,41 @@ static int bd957x_i2c_probe(struct i2c_client *i2c,
dev_err(>dev, "Failed to initialize Regmap\n");
return PTR_ERR(regmap);
}
+ /*
+* BD9576 behaves badly. It kepts IRQ line asserted for the whole
+* duration of detected HW condition (like over temperature). So we
+* don't require IRQ to be populated.
+* If IRQ information is not given, then we mask all IRQs and do not
+* provide IRQ resources to regulator driver - which then just omits
+* the notifiers.
+*/
+ if (usable_irqs) {
+ struct regmap_irq_chip_data *irq_data;
+ struct mfd_cell
[PATCH v8 4/6] wdt: Support wdt on ROHM BD9576MUF and BD9573MUF
Add Watchdog support for ROHM BD9576MUF and BD9573MUF PMICs which are
mainly used to power the R-Car series processors. The watchdog is
pinged using a GPIO and enabled using another GPIO. Additionally
watchdog time-out can be configured to HW prior starting the watchdog.
Watchdog timeout can be configured to detect only delayed ping or in
a window mode where also too fast pings are detected.
Signed-off-by: Matti Vaittinen
Reviewed-by: Guenter Roeck
---
No changes since v6
drivers/watchdog/Kconfig | 13 ++
drivers/watchdog/Makefile | 1 +
drivers/watchdog/bd9576_wdt.c | 291 ++
3 files changed, 305 insertions(+)
create mode 100644 drivers/watchdog/bd9576_wdt.c
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 7ff941e71b79..67eff0cbd7e1 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -172,6 +172,19 @@ config BD70528_WATCHDOG
Alternatively say M to compile the driver as a module,
which will be called bd70528_wdt.
+config BD957XMUF_WATCHDOG
+ tristate "ROHM BD9576MUF and BD9573MUF PMIC Watchdog"
+ depends on MFD_ROHM_BD957XMUF
+ select WATCHDOG_CORE
+ help
+ Support for the watchdog in the ROHM BD9576 and BD9573 PMICs.
+ These PMIC ICs contain watchdog block which can be configured
+ to toggle reset line if SoC fails to ping watchdog via GPIO.
+
+ Say Y here to include support for the ROHM BD9576 or BD9573
+ watchdog. Alternatively say M to compile the driver as a module,
+ which will be called bd9576_wdt.
+
config DA9052_WATCHDOG
tristate "Dialog DA9052 Watchdog"
depends on PMIC_DA9052 || COMPILE_TEST
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 5c74ee19d441..9341f72bf0aa 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -208,6 +208,7 @@ obj-$(CONFIG_XEN_WDT) += xen_wdt.o
# Architecture Independent
obj-$(CONFIG_BD70528_WATCHDOG) += bd70528_wdt.o
+obj-$(CONFIG_BD957XMUF_WATCHDOG) += bd9576_wdt.o
obj-$(CONFIG_DA9052_WATCHDOG) += da9052_wdt.o
obj-$(CONFIG_DA9055_WATCHDOG) += da9055_wdt.o
obj-$(CONFIG_DA9062_WATCHDOG) += da9062_wdt.o
diff --git a/drivers/watchdog/bd9576_wdt.c b/drivers/watchdog/bd9576_wdt.c
new file mode 100644
index ..0b6999f3b6e8
--- /dev/null
+++ b/drivers/watchdog/bd9576_wdt.c
@@ -0,0 +1,291 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (C) 2020 ROHM Semiconductors
+ *
+ * ROHM BD9576MUF and BD9573MUF Watchdog driver
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static bool nowayout;
+module_param(nowayout, bool, 0);
+MODULE_PARM_DESC(nowayout,
+ "Watchdog cannot be stopped once started (default=\"false\")");
+
+#define HW_MARGIN_MIN 2
+#define HW_MARGIN_MAX 4416
+#define BD957X_WDT_DEFAULT_MARGIN 4416
+#define WATCHDOG_TIMEOUT 30
+
+struct bd9576_wdt_priv {
+ struct gpio_desc*gpiod_ping;
+ struct gpio_desc*gpiod_en;
+ struct device *dev;
+ struct regmap *regmap;
+ boolalways_running;
+ struct watchdog_device wdd;
+};
+
+static void bd9576_wdt_disable(struct bd9576_wdt_priv *priv)
+{
+ gpiod_set_value_cansleep(priv->gpiod_en, 0);
+}
+
+static int bd9576_wdt_ping(struct watchdog_device *wdd)
+{
+ struct bd9576_wdt_priv *priv = watchdog_get_drvdata(wdd);
+
+ /* Pulse */
+ gpiod_set_value_cansleep(priv->gpiod_ping, 1);
+ gpiod_set_value_cansleep(priv->gpiod_ping, 0);
+
+ return 0;
+}
+
+static int bd9576_wdt_start(struct watchdog_device *wdd)
+{
+ struct bd9576_wdt_priv *priv = watchdog_get_drvdata(wdd);
+
+ gpiod_set_value_cansleep(priv->gpiod_en, 1);
+
+ return bd9576_wdt_ping(wdd);
+}
+
+static int bd9576_wdt_stop(struct watchdog_device *wdd)
+{
+ struct bd9576_wdt_priv *priv = watchdog_get_drvdata(wdd);
+
+ if (!priv->always_running)
+ bd9576_wdt_disable(priv);
+ else
+ set_bit(WDOG_HW_RUNNING, >status);
+
+ return 0;
+}
+
+static const struct watchdog_info bd957x_wdt_ident = {
+ .options= WDIOF_MAGICCLOSE | WDIOF_KEEPALIVEPING |
+ WDIOF_SETTIMEOUT,
+ .identity = "BD957x Watchdog",
+};
+
+static const struct watchdog_ops bd957x_wdt_ops = {
+ .owner = THIS_MODULE,
+ .start = bd9576_wdt_start,
+ .stop = bd9576_wdt_stop,
+ .ping = bd9576_wdt_ping,
+};
+
+/* Unit is hundreds of uS */
+#define FASTNG_MIN 23
+
+static int find_closest_fast(int target, int *sel, int *val)
+{
+ int i;
+ int window = FASTNG_MIN;
+
+ for (i = 0; i < 8 && window < target; i++)
+ window <<= 1;
+
+ *val = window;
+ *sel = i;
+
+ if (i == 8)
+ return -EINVAL;
+
+ return 0;
+
+}
+
+static
RE: [PATCH v5 1/6] misc: Add Synopsys DesignWare xData IP driver
On Thu, Feb 11, 2021 at 9:30:16, Greg Kroah-Hartman
wrote:
> On Thu, Feb 11, 2021 at 10:08:38AM +0100, Gustavo Pimentel wrote:
> > +static ssize_t write_show(struct device *dev, struct device_attribute
> > *attr,
> > + char *buf)
> > +{
> > + struct pci_dev *pdev = to_pci_dev(dev);
> > + struct dw_xdata *dw = pci_get_drvdata(pdev);
> > + u64 rate;
> > +
> > + mutex_lock(>mutex);
> > + dw_xdata_perf(dw, , true);
> > + mutex_unlock(>mutex);
> > +
> > + return sysfs_emit(buf, "%llu MB/s\n", rate);
>
> Do not put units in a sysfs file, that should be in the documentation,
> otherwise this forces userspace to "parse" the units which is a mess.
Okay.
>
> Same for the other sysfs file.
>
> And why do you need a lock for this show function?
Maybe I understood it wrongly, please correct me in that case. The
dw_xdata_perf() is called on the write_show() and read_show(), to avoid a
possible race condition between those calls, I have added this mutex.
Thanks.
-Gustavo
>
> thanks,
>
> greg k-h
Re: [PATCH v11 7/7] at24: Support probing while in non-zero ACPI D state
On Thu, Feb 11, 2021 at 12:08 AM Sakari Ailus wrote: > > In certain use cases (where the chip is part of a camera module, and the > camera module is wired together with a camera privacy LED), powering on > the device during probe is undesirable. Add support for the at24 to > execute probe while being in ACPI D state other than 0 (which means fully > powered on). > > Signed-off-by: Sakari Ailus > Reviewed-by: Tomasz Figa > --- I like this much better now, thanks! Acked-by: Bartosz Golaszewski
[PATCH v2] Updated locking documentation for journal_t
Some members of transaction_t are allowed to be read without
any lock being held if consistency doesn't matter.
Based on LockDoc's findings, we extended the locking
documentation of those members.
Each one of them is marked with a short comment:
"no lock for quick racy checks".
Signed-off-by: Alexander Lochmann
Signed-off-by: Horst Schirmeier
Reviewed-by: Jan Kara
---
include/linux/jbd2.h | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/include/linux/jbd2.h b/include/linux/jbd2.h
index 18f77d9b1745..4dca33a063dd 100644
--- a/include/linux/jbd2.h
+++ b/include/linux/jbd2.h
@@ -768,7 +768,7 @@ enum passtype {PASS_SCAN, PASS_REVOKE, PASS_REPLAY};
struct journal_s
{
/**
-* @j_flags: General journaling state flags [j_state_lock]
+ * @j_flags: General journaling state flags [j_state_lock, no lock for
quick racy checks]
*/
unsigned long j_flags;
@@ -808,7 +808,7 @@ struct journal_s
/**
* @j_barrier_count:
*
-* Number of processes waiting to create a barrier lock [j_state_lock]
+ * Number of processes waiting to create a barrier lock [j_state_lock,
no lock for quick racy checks]
*/
int j_barrier_count;
@@ -821,7 +821,7 @@ struct journal_s
* @j_running_transaction:
*
* Transactions: The current running transaction...
-* [j_state_lock] [caller holding open handle]
+ * [j_state_lock, no lock for quick racy checks] [caller holding open
handle]
*/
transaction_t *j_running_transaction;
@@ -1033,7 +1033,7 @@ struct journal_s
* @j_commit_sequence:
*
* Sequence number of the most recently committed transaction
-* [j_state_lock].
+* [j_state_lock, no lock for quick racy checks].
*/
tid_t j_commit_sequence;
@@ -1041,7 +1041,7 @@ struct journal_s
* @j_commit_request:
*
* Sequence number of the most recent transaction wanting commit
-* [j_state_lock]
+* [j_state_lock, no lock for quick racy checks]
*/
tid_t j_commit_request;
--
2.20.1
OpenPGP_signature
Description: OpenPGP digital signature
Re: [PATCH] platform/x86: intel_scu_ipc: Increase virtual timeout from 3 to 5 seconds
On Wed, Feb 10, 2021 at 9:20 PM Casey Bowman wrote:
>
> Increasing the virtual timeout time to account for scenarios
> that may require more time, like DisplayPort Multi-Stream Transport
> (DP MST), where the disconnect time can be extended longer than
> usual.
>
> The recommended timeout range is 5-10 seconds, of which
> we will take the lower bound.
Since the driver is used across several platforms, can we somehow be
more flexible with it on a per platform basis or so (per command?)?
In general I'm not against the patch and I usually don't see the long
timeouts on other platforms, so if Hans thinks it's okay to take,
Acked-by: Andy Shevchenko
> Signed-off-by: Casey Bowman
> Acked-by: Heikki Krogerus
> Acked-by: Mika Westerberg
> ---
> drivers/platform/x86/intel_scu_ipc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/platform/x86/intel_scu_ipc.c
> b/drivers/platform/x86/intel_scu_ipc.c
> index d9cf7f7602b0..9171a46a9e3f 100644
> --- a/drivers/platform/x86/intel_scu_ipc.c
> +++ b/drivers/platform/x86/intel_scu_ipc.c
> @@ -75,7 +75,7 @@ struct intel_scu_ipc_dev {
> #define IPC_READ_BUFFER0x90
>
> /* Timeout in jiffies */
> -#define IPC_TIMEOUT(3 * HZ)
> +#define IPC_TIMEOUT(5 * HZ)
>
> static struct intel_scu_ipc_dev *ipcdev; /* Only one for now */
> static DEFINE_MUTEX(ipclock); /* lock used to prevent multiple call to SCU */
> --
> 2.17.1
>
--
With Best Regards,
Andy Shevchenko
Re: [PATCH] powerpc/bug: Remove specific powerpc BUG_ON()
Excerpts from Christophe Leroy's message of February 11, 2021 5:41 pm: > powerpc BUG_ON() is based on using twnei or tdnei instruction, > which obliges gcc to format the condition into a 0 or 1 value > in a register. > > By using a generic implementation, gcc will generate a branch > to the unconditional trap generated by BUG(). We don't want to do this on 64s because that will lose the useful CFAR contents. Unfortunately the code generation is not great and the registers that give some useful information about the condition are often mangled :( It would be nice if we could have a __builtin_trap_if that gcc would use conditional traps with, (and which never assumes following code is unreachable even for constant true, so we can use it with WARN and put explicit unreachable for BUG). > > As modern powerpc implement branch folding, that's even more efficient. I think POWER will speculate conditional traps as non faulting always so it should be just as good if not better than the branch. Thanks, Nick
Re: [PATCH -next] mfd: arizona: Make some symbols static
On Wed, Feb 10, 2021 at 07:56:26AM +, Wei Yongjun wrote:
> The sparse tool complains as follows:
>
> drivers/mfd/arizona-spi.c:28:31: warning:
> symbol 'reset_gpios' was not declared. Should it be static?
> drivers/mfd/arizona-spi.c:29:31: warning:
> symbol 'ldoena_gpios' was not declared. Should it be static?
>
> Those symbols are not used outside of arizona-spi.c, so this
> commit marks them static.
>
> Fixes: e933836744a2 ("mfd: arizona: Add support for ACPI enumeration of
> WM5102 connected over SPI")
> Reported-by: Hulk Robot
> Signed-off-by: Wei Yongjun
> ---
Acked-by: Charles Keepax
Thanks,
Charles
Re: [greybus-dev] [PATCH 1/1] staging: greybus: Added do - while in multi statement macro
On 11-02-21, 11:00, Greg KH wrote: > On Thu, Feb 11, 2021 at 03:24:44PM +0530, Hemansh Agnihotri wrote: > > This patch add fixes an checkpatch error for "Macros with multiple > > statements > > should be enclosed in a do - while loop" > > > > Signed-off-by: Hemansh Agnihotri > > Any reason you didn't test-build your patch before sending it out? > > That's a bit rude to reviewers :( I also wonder how two people stumbled upon the exact same thing at the same time. Copy/paste ? https://lore.kernel.org/lkml/20210210221439.3489-2-yildirim.fa...@gmail.com/ And of course NAK for the patch. The macro is used outside of any other routine, and is actually used to create routines. No do-while required here. -- viresh
[PATCH v2 0/8] xen/events: bug fixes and some diagnostic aids
The first four patches are fixes for XSA-332. The avoid WARN splats and a performance issue with interdomain events. Patches 5 and 6 are some additions to event handling in order to add some per pv-device statistics to sysfs and the ability to have a per backend device spurious event delay control. Patches 7 and 8 are minor fixes I had lying around. Juergen Gross (8): xen/events: reset affinity of 2-level event when tearing it down xen/events: don't unmask an event channel when an eoi is pending xen/events: avoid handling the same event on two cpus at the same time xen/netback: fix spurious event detection for common event case xen/events: link interdomain events to associated xenbus device xen/events: add per-xenbus device event statistics and settings xen/evtchn: use smp barriers for user event ring xen/evtchn: use READ/WRITE_ONCE() for accessing ring indices .../ABI/testing/sysfs-devices-xenbus | 41 drivers/block/xen-blkback/xenbus.c| 2 +- drivers/net/xen-netback/interface.c | 24 ++- drivers/xen/events/events_2l.c| 22 +- drivers/xen/events/events_base.c | 190 ++ drivers/xen/events/events_fifo.c | 7 - drivers/xen/events/events_internal.h | 14 +- drivers/xen/evtchn.c | 29 ++- drivers/xen/pvcalls-back.c| 4 +- drivers/xen/xen-pciback/xenbus.c | 2 +- drivers/xen/xen-scsiback.c| 2 +- drivers/xen/xenbus/xenbus_probe.c | 66 ++ include/xen/events.h | 7 +- include/xen/xenbus.h | 7 + 14 files changed, 323 insertions(+), 94 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-devices-xenbus -- 2.26.2
Re: [PATCH v4 net-next 09/11] skbuff: allow to optionally use NAPI cache from __alloc_skb()
On Wed, 2021-02-10 at 16:30 +, Alexander Lobakin wrote: > Reuse the old and forgotten SKB_ALLOC_NAPI to add an option to get > an skbuff_head from the NAPI cache instead of inplace allocation > inside __alloc_skb(). > This implies that the function is called from softirq or BH-off > context, not for allocating a clone or from a distant node. > > Signed-off-by: Alexander Lobakin > --- > net/core/skbuff.c | 13 + > 1 file changed, 9 insertions(+), 4 deletions(-) > > diff --git a/net/core/skbuff.c b/net/core/skbuff.c > index 9e1a8ded4acc..750fa1825b28 100644 > --- a/net/core/skbuff.c > +++ b/net/core/skbuff.c > @@ -397,15 +397,20 @@ struct sk_buff *__alloc_skb(unsigned int size, gfp_t > gfp_mask, > struct sk_buff *skb; > u8 *data; > bool pfmemalloc; > + bool clone; > > - cache = (flags & SKB_ALLOC_FCLONE) > - ? skbuff_fclone_cache : skbuff_head_cache; > + clone = !!(flags & SKB_ALLOC_FCLONE); > + cache = clone ? skbuff_fclone_cache : skbuff_head_cache; > > if (sk_memalloc_socks() && (flags & SKB_ALLOC_RX)) > gfp_mask |= __GFP_MEMALLOC; > > /* Get the HEAD */ > - skb = kmem_cache_alloc_node(cache, gfp_mask & ~__GFP_DMA, node); > + if (!clone && (flags & SKB_ALLOC_NAPI) && > + likely(node == NUMA_NO_NODE || node == numa_mem_id())) > + skb = napi_skb_cache_get(); > + else > + skb = kmem_cache_alloc_node(cache, gfp_mask & ~GFP_DMA, node); > if (unlikely(!skb)) > return NULL; > prefetchw(skb); I hope the opt-in thing would have allowed leaving this code unchanged. I see it's not trivial avoid touching this code path. Still I think it would be nice if you would be able to let the device driver use the cache without touching the above, which is also used e.g. by the TCP xmit path, which in turn will not leverage the cache (as it requires FCLONE skbs). If I read correctly, the above chunk is needed to allow __napi_alloc_skb() access the cache even for small skb allocation. Good device drivers should not call alloc_skb() in the fast path. What about changing __napi_alloc_skb() to always use the __napi_build_skb(), for both kmalloc and page backed skbs? That is, always doing the 'data' allocation in __napi_alloc_skb() - either via page_frag or via kmalloc() - and than call __napi_build_skb(). I think that should avoid adding more checks in __alloc_skb() and should probably reduce the number of conditional used by __napi_alloc_skb(). Thanks! Paolo
Re: [PATCH] pinctrl: imx: imx8mm: fix pad offset of SD1_DATA0 pin
On 11.02.21 10:54, Claudius Heine wrote:
There is a 0 missing in the pad register offset. This patch adds it.
Signed-off-by: Claudius Heine
I think this should rather be prefixed by "arm64: dts: imx8mm:" as this
is no change in the pinctrl driver, but only in the devicetree.
And I guess this deserves a "Fixes" and "Cc: stable" tag, so:
Fixes: c1c9d41319c3 ("dt-bindings: imx: Add pinctrl binding doc for imx8mm")
Cc: sta...@vger.kernel.org
Reviewed-by: Frieder Schrempf
---
arch/arm64/boot/dts/freescale/imx8mm-pinfunc.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-pinfunc.h
b/arch/arm64/boot/dts/freescale/imx8mm-pinfunc.h
index 5ccc4cc91959d..a003e6af33533 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-pinfunc.h
+++ b/arch/arm64/boot/dts/freescale/imx8mm-pinfunc.h
@@ -124,7 +124,7 @@
#define MX8MM_IOMUXC_SD1_CMD_USDHC1_CMD
0x0A4 0x30C 0x000 0x0 0x0
#define MX8MM_IOMUXC_SD1_CMD_GPIO2_IO1
0x0A4 0x30C 0x000 0x5 0x0
#define MX8MM_IOMUXC_SD1_DATA0_USDHC1_DATA0
0x0A8 0x310 0x000 0x0 0x0
-#define MX8MM_IOMUXC_SD1_DATA0_GPIO2_IO2
0x0A8 0x31 0x000 0x5 0x0
+#define MX8MM_IOMUXC_SD1_DATA0_GPIO2_IO2
0x0A8 0x310 0x000 0x5 0x0
#define MX8MM_IOMUXC_SD1_DATA1_USDHC1_DATA1
0x0AC 0x314 0x000 0x0 0x0
#define MX8MM_IOMUXC_SD1_DATA1_GPIO2_IO3
0x0AC 0x314 0x000 0x5 0x0
#define MX8MM_IOMUXC_SD1_DATA2_USDHC1_DATA2
0x0B0 0x318 0x000 0x0 0x0
Re: [PATCH] pinctrl: imx: imx8mm: fix pad offset of SD1_DATA0 pin
Hi Claudius,
On Thu, Feb 11, 2021 at 7:15 AM Claudius Heine wrote:
>
> Hi,
>
> can you please add:
>
> Fixes: c1c9d41319c3 ("dt-bindings: imx: Add pinctrl binding doc for imx8mm")
Yes, I was about to suggest the same. Thanks for the fix:
Reviewed-by: Fabio Estevam
Re: [PATCH v4 2/2] pinctrl: pinmux: Add pinmux-select debugfs file
Hi Drew,
On Wed, Feb 10, 2021 at 11:33 PM Drew Fustini wrote:
> Add "pinmux-select" to debugfs which will activate a function and group
> when "" are written to the file. The write
> operation pinmux_select() handles this by checking that the names map to
> valid selectors and then calling ops->set_mux().
>
> The existing "pinmux-functions" debugfs file lists the pin functions
> registered for the pin controller. For example:
>
> function: pinmux-uart0, groups = [ pinmux-uart0-pins ]
> function: pinmux-mmc0, groups = [ pinmux-mmc0-pins ]
> function: pinmux-mmc1, groups = [ pinmux-mmc1-pins ]
> function: pinmux-i2c0, groups = [ pinmux-i2c0-pins ]
> function: pinmux-i2c1, groups = [ pinmux-i2c1-pins ]
> function: pinmux-spi1, groups = [ pinmux-spi1-pins ]
>
> To activate function pinmux-i2c1 and group pinmux-i2c1-pins:
>
> echo "pinmux-i2c1 pinmux-i2c1-pins" > pinmux-select
>
> Signed-off-by: Drew Fustini
Thanks for your patch!
> --- a/drivers/pinctrl/pinmux.c
> +++ b/drivers/pinctrl/pinmux.c
> @@ -673,6 +673,111 @@ void pinmux_show_setting(struct seq_file *s,
> DEFINE_SHOW_ATTRIBUTE(pinmux_functions);
> DEFINE_SHOW_ATTRIBUTE(pinmux_pins);
>
> +#define PINMUX_MAX_NAME 64
> +static ssize_t pinmux_select(struct file *file, const char __user *user_buf,
> + size_t len, loff_t *ppos)
> +{
> + struct seq_file *sfile = file->private_data;
> + struct pinctrl_dev *pctldev = sfile->private;
> + const struct pinmux_ops *pmxops = pctldev->desc->pmxops;
> + const char *const *groups;
> + char *buf, *fname, *gname;
> + unsigned int num_groups;
> + int fsel, gsel, ret;
> +
> + if (len > (PINMUX_MAX_NAME * 2)) {
> + dev_err(pctldev->dev, "write too big for buffer");
> + return -EINVAL;
> + }
> +
> + buf = kzalloc(PINMUX_MAX_NAME * 2, GFP_KERNEL);
> + if (!buf)
> + return -ENOMEM;
> +
> + fname = kzalloc(PINMUX_MAX_NAME, GFP_KERNEL);
> + if (!fname) {
> + ret = -ENOMEM;
> + goto free_buf;
> + }
> +
> + gname = kzalloc(PINMUX_MAX_NAME, GFP_KERNEL);
> + if (!buf) {
> + ret = -ENOMEM;
> + goto free_fname;
> + }
> +
> + ret = strncpy_from_user(buf, user_buf, PINMUX_MAX_NAME * 2);
While this guarantees buf is not overflowed...
> + if (ret < 0) {
> + dev_err(pctldev->dev, "failed to copy buffer from userspace");
> + goto free_gname;
> + }
> + buf[len-1] = '\0';
> +
> + ret = sscanf(buf, "%s %s", fname, gname);
... one of the two strings can still be longer than PINMUX_MAX_NAME,
thus overflowing fname or gname.
As buf is already a copy, it may be easier to just find the strings in
buf, write the NUL terminators into buf, and set up fname and gname
to point to the strings inside buf.
> + if (ret != 2) {
> + dev_err(pctldev->dev, "expected format:
> ");
> + goto free_gname;
> + }
> +static const struct file_operations pinmux_select_ops = {
> + .owner = THIS_MODULE,
> + .open = pinmux_select_open,
> + .read = seq_read,
I don't think you need to fill in .read for a write-only file.
> + .write = pinmux_select,
> + .llseek = no_llseek,
> + .release = single_release,
> +};
> +
> void pinmux_init_device_debugfs(struct dentry *devroot,
> struct pinctrl_dev *pctldev)
> {
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v2 net-next 04/11] net: bridge: offload initial and final port flags through switchdev
On Thu, Feb 11, 2021 at 01:23:52AM +0200, Vladimir Oltean wrote:
> On Wed, Feb 10, 2021 at 12:59:49PM +0200, Ido Schimmel wrote:
> > > > The reverse, during unlinking, would be to refuse unlinking if the upper
> > > > has uppers of its own. netdev_upper_dev_unlink() needs to learn to
> > > > return an error and callers such as team/bond need to learn to handle
> > > > it, but it seems patchable.
> > >
> > > Again, this was treated prior to my deletion in this series and not by
> > > erroring out, I just really didn't think it through.
> > >
> > > So you're saying that if we impose that all switchdev drivers restrict
> > > the house of cards to be constructed from the bottom up, and destructed
> > > from the top down, then the notification of bridge port flags can stay
> > > in the bridge layer?
> >
> > I actually don't think it's a good idea to have this in the bridge in
> > any case. I understand that it makes sense for some devices where
> > learning, flooding, etc are port attributes, but in other devices these
> > can be {port,vlan} attributes and then you need to take care of them
> > when a vlan is added / deleted and not only when a port is removed from
> > the bridge. So for such devices this really won't save anything. I would
> > thus leave it to the lower levels to decide.
>
> Just for my understanding, how are per-{port,vlan} attributes such as
> learning and flooding managed by the Linux bridge? How can I disable
> flooding only in a certain VLAN?
You can't (currently). But it does not change the fact that in some
devices these are {port,vlan} attributes and we are talking here about
the interface towards these devices. Having these as {port,vlan}
attributes allows you to support use cases such as a port being enslaved
to a VLAN-aware bridge and its VLAN upper(s) enslaved to VLAN unaware
bridge(s). Obviously you need to ensure there is no conflict between the
VLANs used by the VLAN-aware bridge and the VLAN device(s).
Re: [PATCH] staging: rtl8723bs: remove obsolete commented out code
On Thu, Feb 11, 2021 at 12:40:41AM +0530, karthik alapati wrote:
> @@ -867,10 +845,8 @@ static void PHY_HandleSwChnlAndSetBW8723B(
> if (bSetBandWidth)
> pHalData->bSetChnlBW = true;
>
> - if (!pHalData->bSetChnlBW && !pHalData->bSwChnl) {
> - /* DBG_871X("<= PHY_HandleSwChnlAndSetBW8812: bSwChnl %d,
> bSetChnlBW %d\n", pHalData->bSwChnl, pHalData->bSetChnlBW); */
> + if (!pHalData->bSetChnlBW && !pHalData->bSwChnl)
> return;
> - }
In this case, the + line is correct. Good job.
>
>
> if (pHalData->bSwChnl) {
> @@ -929,9 +905,7 @@ void PHY_SetSwChnlBWMode8723B(
> u8 Offset80
> )
> {
> - /* DBG_871X("%s() ===>\n", __func__); */
>
> PHY_HandleSwChnlAndSetBW8723B(Adapter, true, true, channel, Bandwidth,
> Offset40, Offset80, channel);
>
> - /* DBG_871X("<==%s()\n", __func__); */
Please delete the blank lines as well.
regards,
dan carpenter
Re: [PATCH 0/9] Add support for SVM atomics in Nouveau
On Wed, Feb 10, 2021 at 01:59:13PM -0400, Jason Gunthorpe wrote: > Really what you want to do here is leave the CPU page in the VMA and > the page tables where it started and deny CPU access to the page. Then > all the proper machinery will continue to work. > > IMHO "migration" is the wrong idea if the data isn't actually moving. Agreed.
Re: [PATCH v7 3/4] x509: Add support for parsing x509 certs with ECDSA keys
Hi Stefan,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on cryptodev/master]
[also build test ERROR on crypto/master security/next-testing v5.11-rc7
next-20210125]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Stefan-Berger/Add-support-for-x509-certs-with-NIST-p256-and-p192-keys/20210201-232803
base:
https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master
config: x86_64-randconfig-a011-20200911 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
reproduce (this is a W=1 build):
#
https://github.com/0day-ci/linux/commit/6e1523b0e77785c263bcb639b87a862ae59731a4
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Stefan-Berger/Add-support-for-x509-certs-with-NIST-p256-and-p192-keys/20210201-232803
git checkout 6e1523b0e77785c263bcb639b87a862ae59731a4
# save the attached .config to linux build tree
make W=1 ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
ld: crypto/asymmetric_keys/public_key.o: in function
`software_key_determine_akcipher':
>> crypto/asymmetric_keys/public_key.c:97: undefined reference to `parse_OID'
vim +97 crypto/asymmetric_keys/public_key.c
61
62 /*
63 * Determine the crypto algorithm name.
64 */
65 static
66 int software_key_determine_akcipher(const char *encoding,
67 const char *hash_algo,
68 const struct public_key *pkey,
69 char alg_name[CRYPTO_MAX_ALG_NAME])
70 {
71 int n;
72
73 if (strcmp(encoding, "pkcs1") == 0) {
74 /* The data wangled by the RSA algorithm is typically
padded
75 * and encoded in some manner, such as EMSA-PKCS1-1_5
[RFC3447
76 * sec 8.2].
77 */
78 if (!hash_algo)
79 n = snprintf(alg_name, CRYPTO_MAX_ALG_NAME,
80 "pkcs1pad(%s)",
81 pkey->pkey_algo);
82 else
83 n = snprintf(alg_name, CRYPTO_MAX_ALG_NAME,
84 "pkcs1pad(%s,%s)",
85 pkey->pkey_algo, hash_algo);
86 return n >= CRYPTO_MAX_ALG_NAME ? -EINVAL : 0;
87 }
88
89 if (strcmp(encoding, "raw") == 0) {
90 strcpy(alg_name, pkey->pkey_algo);
91 return 0;
92 }
93
94 if (strcmp(encoding, "x962") == 0) {
95 enum OID oid;
96
> 97 if (parse_OID(pkey->params, pkey->paramlen, ) != 0)
98 return -EBADMSG;
99
100 switch (oid) {
101 case OID_id_prime192v1:
102 strcpy(alg_name, "ecdsa-nist-p192");
103 return 0;
104 case OID_id_prime256v1:
105 strcpy(alg_name, "ecdsa-nist-p256");
106 return 0;
107 default:
108 return -EINVAL;
109 }
110 }
111
112 return -ENOPKG;
113 }
114
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: [PATCH 3/3] dma-contiguous: Type cast MAX_ORDER as unsigned int
On Thu, Feb 11, 2021 at 11:52:11AM +0530, Anshuman Khandual wrote:
> Type cast MAX_ORDER as unsigned int to fix the following build warning.
>
> In file included from ./include/linux/kernel.h:14,
> from ./include/asm-generic/bug.h:20,
> from ./arch/arm64/include/asm/bug.h:26,
> from ./include/linux/bug.h:5,
> from ./include/linux/mmdebug.h:5,
> from ./arch/arm64/include/asm/memory.h:166,
> from ./arch/arm64/include/asm/page.h:42,
> from kernel/dma/contiguous.c:46:
> kernel/dma/contiguous.c: In function ‘rmem_cma_setup’:
> ./include/linux/minmax.h:18:28: warning: comparison of distinct pointer
> types lacks a cast
> (!!(sizeof((typeof(x) *)1 == (typeof(y) *)1)))
> ^~
> ./include/linux/minmax.h:32:4: note: in expansion of macro ‘__typecheck’
>(__typecheck(x, y) && __no_side_effects(x, y))
> ^~~
> ./include/linux/minmax.h:42:24: note: in expansion of macro ‘__safe_cmp’
> __builtin_choose_expr(__safe_cmp(x, y), \
> ^~
> ./include/linux/minmax.h:58:19: note: in expansion of macro
> ‘__careful_cmp’
> #define max(x, y) __careful_cmp(x, y, >)
>^
> kernel/dma/contiguous.c:402:35: note: in expansion of macro ‘max’
> phys_addr_t align = PAGE_SIZE << max(MAX_ORDER - 1, pageblock_order);
>
> Cc: Christoph Hellwig
> Cc: Marek Szyprowski
> Cc: Robin Murphy
> Cc: io...@lists.linux-foundation.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Anshuman Khandual
> ---
> kernel/dma/contiguous.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/dma/contiguous.c b/kernel/dma/contiguous.c
> index 3d63d91cba5c..1c2782349d71 100644
> --- a/kernel/dma/contiguous.c
> +++ b/kernel/dma/contiguous.c
> @@ -399,7 +399,7 @@ static const struct reserved_mem_ops rmem_cma_ops = {
>
> static int __init rmem_cma_setup(struct reserved_mem *rmem)
> {
> - phys_addr_t align = PAGE_SIZE << max(MAX_ORDER - 1, pageblock_order);
> + phys_addr_t align = PAGE_SIZE << max((unsigned int)MAX_ORDER - 1,
> pageblock_order);
MAX_ORDER and pageblock_order should be the same type. So either fix
MAX_ORDER to be an unsigned constant, which would be fundamentally
the right thing to do but might cause some fallout, or turn
pageblock_order into an int, which is probably much either as the stub
define of it already has an integer type derived from MAX_ORDER as well.
Re: [PATCH] usb: Replace lkml.org links with lore
On Wed, Feb 10, 2021 at 03:53:30PM -0800, Kees Cook wrote:
> As started by commit 05a5f51ca566 ("Documentation: Replace lkml.org
> links with lore"), replace lkml.org links with lore to better use a
> single source that's more likely to stay available long-term.
>
> Signed-off-by: Kees Cook
Acked-by: Johan Hovold
Re: [PATCH v1] mm, hwpoison: enable error handling on shmem thp
On Tue, Feb 09, 2021 at 03:21:28PM +0900, Naoya Horiguchi wrote: > From: Naoya Horiguchi > > Currently hwpoison code checks PageAnon() for thp and refuses to handle > errors on non-anonymous thps (just for historical reason). We now > support non-anonymou thp like shmem one, so this patch suggests to enable > to handle shmem thps. Fortunately, we already have can_split_huge_page() > to check if a give thp is splittable, so this patch relies on it. > > Signed-off-by: Naoya Horiguchi Looks good to me, thanks Naoya: Reviewed-by: Oscar Salvador -- Oscar Salvador SUSE L3
Re: possible deadlock in fs_reclaim_acquire (2)
On Thu 11-02-21 12:07:29, Hillf Danton wrote:
> On Wed, 10 Feb 2021 17:25:19 -0800
> > syzbot found the following issue on:
> >
> > HEAD commit:825b5991 Merge tag '5.11-rc6-smb3' of git://git.samba.org/..
> > git tree: upstream
> > console output: https://syzkaller.appspot.com/x/log.txt?x=117927bf50
> > kernel config: https://syzkaller.appspot.com/x/.config?x=bd1f72220b2e57eb
> > dashboard link: https://syzkaller.appspot.com/bug?extid=a7ab8df042baaf42ae3c
> > userspace arch: i386
> >
> > Unfortunately, I don't have any reproducer for this issue yet.
> >
> > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > Reported-by: syzbot+a7ab8df042baaf42a...@syzkaller.appspotmail.com
> >
> > ==
> > WARNING: possible circular locking dependency detected
> > 5.11.0-rc6-syzkaller #0 Not tainted
> > --
> > syz-executor.3/24553 is trying to acquire lock:
> > 8be892c0 (fs_reclaim){+.+.}-{0:0}, at:
> > fs_reclaim_acquire+0xf7/0x150 mm/page_alloc.c:4348
> >
> > but task is already holding lock:
> > 888019b6b2c8 (>xattr_sem){}-{3:3}, at: ext4_write_lock_xattr
> > fs/ext4/xattr.h:142 [inline]
> > 888019b6b2c8 (>xattr_sem){}-{3:3}, at:
> > ext4_xattr_set_handle+0x15c/0x13e0 fs/ext4/xattr.c:2308
> >
> > which lock already depends on the new lock.
> >
> >
> > the existing dependency chain (in reverse order) is:
> >
> > -> #3 (>xattr_sem){}-{3:3}:
> >down_read+0x95/0x440 kernel/locking/rwsem.c:1353
> >ext4_setattr+0x570/0x1fd0 fs/ext4/inode.c:5375
> >notify_change+0xb60/0x10a0 fs/attr.c:336
> >chown_common+0x4a9/0x550 fs/open.c:674
> >vfs_fchown fs/open.c:741 [inline]
> >vfs_fchown fs/open.c:733 [inline]
> >ksys_fchown+0x111/0x170 fs/open.c:752
> >__do_sys_fchown fs/open.c:760 [inline]
> >__se_sys_fchown fs/open.c:758 [inline]
> >__x64_sys_fchown+0x6f/0xb0 fs/open.c:758
> >do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
> >entry_SYSCALL_64_after_hwframe+0x44/0xa9
> >
> > -> #2 (jbd2_handle){}-{0:0}:
> >start_this_handle+0xfb4/0x1380 fs/jbd2/transaction.c:446
> >jbd2__journal_start+0x399/0x930 fs/jbd2/transaction.c:503
> >__ext4_journal_start_sb+0x227/0x4a0 fs/ext4/ext4_jbd2.c:105
> >ext4_sample_last_mounted fs/ext4/file.c:804 [inline]
> >ext4_file_open+0x613/0xb40 fs/ext4/file.c:832
> >do_dentry_open+0x4b9/0x11b0 fs/open.c:817
> >do_open fs/namei.c:3254 [inline]
> >path_openat+0x1b9a/0x2730 fs/namei.c:3371
> >do_filp_open+0x17e/0x3c0 fs/namei.c:3398
> >do_open_execat+0x116/0x690 fs/exec.c:913
> >bprm_execve fs/exec.c:1801 [inline]
> >bprm_execve+0x4be/0x19a0 fs/exec.c:1788
> >do_execveat_common+0x626/0x7c0 fs/exec.c:1915
> >do_execve fs/exec.c:1983 [inline]
> >__do_sys_execve fs/exec.c:2059 [inline]
> >__se_sys_execve fs/exec.c:2054 [inline]
> >__x64_sys_execve+0x8f/0xc0 fs/exec.c:2054
> >do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
> >entry_SYSCALL_64_after_hwframe+0x44/0xa9
> >
> > -> #1 (sb_internal){.+.+}-{0:0}:
> >percpu_down_read include/linux/percpu-rwsem.h:51 [inline]
> >__sb_start_write include/linux/fs.h:1592 [inline]
> >sb_start_intwrite include/linux/fs.h:1709 [inline]
> >ext4_evict_inode+0xe6f/0x1940 fs/ext4/inode.c:241
> >evict+0x2ed/0x6b0 fs/inode.c:577
> >iput_final fs/inode.c:1653 [inline]
> >iput.part.0+0x57e/0x810 fs/inode.c:1679
> >iput fs/inode.c:1669 [inline]
> >inode_lru_isolate+0x301/0x4f0 fs/inode.c:778
> >__list_lru_walk_one+0x178/0x5c0 mm/list_lru.c:222
> >list_lru_walk_one+0x99/0xd0 mm/list_lru.c:266
> >list_lru_shrink_walk include/linux/list_lru.h:195 [inline]
> >prune_icache_sb+0xdc/0x140 fs/inode.c:803
> >super_cache_scan+0x38d/0x590 fs/super.c:107
> >do_shrink_slab+0x3e4/0x9f0 mm/vmscan.c:511
> >shrink_slab+0x16f/0x5d0 mm/vmscan.c:672
> >shrink_node_memcgs mm/vmscan.c:2665 [inline]
> >shrink_node+0x8cc/0x1de0 mm/vmscan.c:2780
> >kswapd_shrink_node mm/vmscan.c:3523 [inline]
> >balance_pgdat+0x745/0x1270 mm/vmscan.c:3681
> >kswapd+0x5b1/0xdb0 mm/vmscan.c:3938
> >kthread+0x3b1/0x4a0 kernel/kthread.c:292
> >ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:296
> >
> > -> #0 (fs_reclaim){+.+.}-{0:0}:
> >check_prev_add kernel/locking/lockdep.c:2868 [inline]
> >check_prevs_add kernel/locking/lockdep.c:2993 [inline]
> >validate_chain kernel/locking/lockdep.c:3608 [inline]
> >__lock_acquire+0x2b26/0x54f0 kernel/locking/lockdep.c:4832
> >lock_acquire kernel/locking/lockdep.c:5442 [inline]
> >lock_acquire+0x1a8/0x720
RE: [PATCH v5 1/6] misc: Add Synopsys DesignWare xData IP driver
On Thu, Feb 11, 2021 at 9:59:26, Greg Kroah-Hartman
wrote:
> On Thu, Feb 11, 2021 at 09:50:33AM +, Gustavo Pimentel wrote:
> > On Thu, Feb 11, 2021 at 9:30:16, Greg Kroah-Hartman
> > wrote:
> >
> > > On Thu, Feb 11, 2021 at 10:08:38AM +0100, Gustavo Pimentel wrote:
> > > > +static ssize_t write_show(struct device *dev, struct device_attribute
> > > > *attr,
> > > > + char *buf)
> > > > +{
> > > > + struct pci_dev *pdev = to_pci_dev(dev);
> > > > + struct dw_xdata *dw = pci_get_drvdata(pdev);
> > > > + u64 rate;
> > > > +
> > > > + mutex_lock(>mutex);
> > > > + dw_xdata_perf(dw, , true);
> > > > + mutex_unlock(>mutex);
> > > > +
> > > > + return sysfs_emit(buf, "%llu MB/s\n", rate);
> > >
> > > Do not put units in a sysfs file, that should be in the documentation,
> > > otherwise this forces userspace to "parse" the units which is a mess.
> >
> > Okay.
> >
> > >
> > > Same for the other sysfs file.
> > >
> > > And why do you need a lock for this show function?
> >
> > Maybe I understood it wrongly, please correct me in that case. The
> > dw_xdata_perf() is called on the write_show() and read_show(), to avoid a
> > possible race condition between those calls, I have added this mutex.
>
> What race? If the value changes with a write right after a read, what
> does it matter?
>
> What exactly are you trying to protect with this lock?
The write_store() does a procedure to enable the traffic on the write
direction, however, the write_show() does a different procedure to
calculate the link throughput speed, which uses a different set of
registers on the HW.
Similar happens on the read_store() (which enable the traffic on the read
direction) and on the read_show()
To summarize write_store() follows the same approach of read_store() and
the write_show() of the read_show(). I added the mutex on those functions
for instance to avoid while during the write_show() call the possibility
of been called the read_show() messing up the link throughput speed
calculation.
Or while during the write_store() call to be called the read_store or
even the write_show() for the same reasons.
This is the reason why I added those mutexes, maybe this isn't necessary
and it's overkill. Please advise me if a different approach can be done.
-Gustavo
>
> thanks,
>
> greg k-h
Re: [PATCH] platform/surface: aggregator: Fix access of unaligned value
On Thu, Feb 11, 2021 at 12:04:11AM +0100, Maximilian Luz wrote:
> The raw message frame length is unaligned and explicitly marked as
> little endian. It should not be accessed without the appropriatte
> accessor functions. Fix this.
Reviewed-by: Andy Shevchenko
Though a few nit-picks below.
> Reported-by: kernel-test-robot
> Fixes: c167b9c7e3d6 ("platform/surface: Add Surface Aggregator subsystem")
> Signed-off-by: Maximilian Luz
> ---
> drivers/platform/surface/aggregator/ssh_packet_layer.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/platform/surface/aggregator/ssh_packet_layer.c
> b/drivers/platform/surface/aggregator/ssh_packet_layer.c
> index 583315db8b02..9a78188d8d1c 100644
> --- a/drivers/platform/surface/aggregator/ssh_packet_layer.c
> +++ b/drivers/platform/surface/aggregator/ssh_packet_layer.c
> @@ -1774,7 +1774,8 @@ static size_t ssh_ptl_rx_eval(struct ssh_ptl *ptl,
> struct ssam_span *source)
> break;
> }
>
> - return aligned.ptr - source->ptr + SSH_MESSAGE_LENGTH(frame->len);
> + return aligned.ptr - source->ptr
> + + SSH_MESSAGE_LENGTH(get_unaligned_le16(>len));
I would leave + on previous line.
Also it's possible to annotate temporary variable and use it, but it seems not
worth to do.
Side question: Do you think the below is correct (& operator)?
sp.len = get_unaligned_le16(&((struct ssh_frame *)sf.ptr)->len);
To me seems like you take an address to len member rather its value.
> }
>
> static int ssh_ptl_rx_threadfn(void *data)
--
With Best Regards,
Andy Shevchenko
[PATCH v2 7/8] xen/evtch: use smp barriers for user event ring
The ring buffer for user events is local to the given kernel instance,
so smp barriers are fine for ensuring consistency.
Reported-by: Andrew Cooper
Signed-off-by: Juergen Gross
Reviewed-by: Jan Beulich
---
drivers/xen/evtchn.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/xen/evtchn.c b/drivers/xen/evtchn.c
index a7a85719a8c8..421382c73d88 100644
--- a/drivers/xen/evtchn.c
+++ b/drivers/xen/evtchn.c
@@ -173,7 +173,7 @@ static irqreturn_t evtchn_interrupt(int irq, void *data)
if ((u->ring_prod - u->ring_cons) < u->ring_size) {
*evtchn_ring_entry(u, u->ring_prod) = evtchn->port;
- wmb(); /* Ensure ring contents visible */
+ smp_wmb(); /* Ensure ring contents visible */
if (u->ring_cons == u->ring_prod++) {
wake_up_interruptible(>evtchn_wait);
kill_fasync(>evtchn_async_queue,
@@ -245,7 +245,7 @@ static ssize_t evtchn_read(struct file *file, char __user
*buf,
}
rc = -EFAULT;
- rmb(); /* Ensure that we see the port before we copy it. */
+ smp_rmb(); /* Ensure that we see the port before we copy it. */
if (copy_to_user(buf, evtchn_ring_entry(u, c), bytes1) ||
((bytes2 != 0) &&
copy_to_user([bytes1], >ring[0], bytes2)))
--
2.26.2
Re: phy_attach_direct()'s use of device_bind_driver()
On 10/02/2021 22:56, Andrew Lunn wrote: > On Wed, Feb 10, 2021 at 02:13:48PM -0800, Saravana Kannan wrote: >> Hi, >> >> This email was triggered by this other email[1]. > > And it appears the Tegra194 Jetson Xavier uses the Marvell 88E1512 > PHY. So ensure the Marvell driver is available, and it should get > probed in the usual way, the fallback driver will not be needed. Yes that is correct. Enabling the Marvell PHY does fix this indeed and so I can enable that as part of our testsuite. We were seeing the same warning on Tegra186 Jetson TX2 and enabling the BRCM PHY resolves that as well. I will ensure that these are enabled going forward. Cheers Jon -- nvpublic
Re: [RFC PATCH v3 1/2] mempinfd: Add new syscall to provide memory pin
Again in proper SVA it should be quite unlikely to take a fault caused by something like migration, on the same likelyhood as the CPU. If things are faulting so much this is a problem then I think it is a system level problem with doing too much page motion. My point is that single one SVA application shouldn't require system to make global changes, such as disabling numa balancing, disabling THP, to decrease page fault frequency by affecting other applications. Anyway, guys are in lunar new year. Hopefully, we are getting more real benchmark data afterwards to make the discussion more targeted. Right, but I think functionality as proposed in this patch is highly unlikely to make it into the kernel. I'd be interested in approaches to mitigate this per process. E.g., temporarily stop the kernel from messing with THP of this specific process. But even then, why should some random library make such decisions for a whole process? Just as, why should some random library pin pages never allocated by it and stop THP from being created or NUMA layout from getting optimized? This looks like a clear layer violation to me. I fully agree with Jason: Why do the events happen that often such that your use cases are affected that heavily, such that we even need such ugly handling? What mempinfd does is exposing dangerous functionality that we don't want 99.6% of all user space to ever use via a syscall to generic users to fix broken* hw. *broken might be over-stressing the situation, but the HW (SVA) obviously seems to perform way worse than ordinary CPUs. -- Thanks, David / dhildenb
Re: [PATCH] scripts: Fix linking extract-cert against libcrypto
Am Dienstag, 9. Februar 2021, 09:44:33 CET schrieb Rolf Eike Beer: > Am Dienstag, 9. Februar 2021, 05:59:56 CET schrieb Daniel Díaz: > > When compiling under OpenEmbedded, the following error is seen > > > > as of recently: > > /srv/oe/build/tmp/hosttools/ld: cannot find /lib/libc.so.6 inside / > > /srv/oe/build/tmp/hosttools/ld: cannot find /usr/lib/libc_nonshared.a > > > > inside / /srv/oe/build/tmp/hosttools/ld: cannot find > > /lib/ld-linux-x86-64.so.2 inside / collect2: error: ld returned 1 exit > > status > > > > make[2]: *** [scripts/Makefile.host:95: scripts/extract-cert] Error 1 > > [...] > > > As per `make`'s documentation: > > LDFLAGS > > > > Extra flags to give to compilers when they are supposed to > > invoke the linker, ‘ld’, such as -L. Libraries (-lfoo) > > should be added to the LDLIBS variable instead. > > > > LDLIBS > > > > Library flags or names given to compilers when they are > > supposed to invoke the linker, ‘ld’. LOADLIBES is a > > deprecated (but still supported) alternative to LDLIBS. > > Non-library linker flags, such as -L, should go in the > > LDFLAGS variable. > > Correct. And the patch I use for my local 4.19 build actually uses LDLIBS, > so it must have gone wrong in some rebase for one of the intermediate > versions. > > Acked-by: Rolf Eike Beer Ok, now actually with proper testing: no, your patch doesn't work. When changing LDLIBS to LDFLAGS things do not show up on the commandline at all. LDLIBS: gcc -Wp,-MMD,scripts/.sign-file.d -Wall -Wmissing-prototypes -Wstrict- prototypes -O2 -fomit-frame-pointer -std=gnu89 -I/opt/emlix/test/include -I ./scripts -o scripts/sign-file /tmp/e2/build/linux-kernel/scripts/sign- file.c -L/opt/emlix/test/lib -lcrypto -lz -ldl -pthread LDFLAGS: gcc -Wp,-MMD,scripts/.sign-file.d -Wall -Wmissing-prototypes -Wstrict- prototypes -O2 -fomit-frame-pointer -std=gnu89 -I/opt/emlix/test/include -I ./scripts -o scripts/sign-file /tmp/e2/build/linux-kernel/scripts/sign- file.c When looking closely you may notice that this is not entirely the same as current master would output: I missed the CFLAGS for sign-file in my patch. When testing your patch I accidentially had a .config that had module signatures disabled, so I have not tested it actually, that's why I didn't notice that it doesn't work. I'm just guessing, but your build error looks like you are also cross-building the tools, which is wrong. You want them to be host-tools. So don't export PKG_CONFIG_SYSROOT_DIR, it would then try to link target libraries into a host binary. Eike -- Rolf Eike Beer, emlix GmbH, http://www.emlix.com Fon +49 551 30664-0, Fax +49 551 30664-11 Gothaer Platz 3, 37083 Göttingen, Germany Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160 Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055 emlix - smart embedded open source signature.asc Description: This is a digitally signed message part.
Re: [PATCH] staging: rtl8723bs: remove obsolete commented out code
Should i send them as patch series?
On Thu, Feb 11, 2021 at 1:27 PM Dan Carpenter wrote:
>
> On Thu, Feb 11, 2021 at 12:40:41AM +0530, karthik alapati wrote:
> > @@ -867,10 +845,8 @@ static void PHY_HandleSwChnlAndSetBW8723B(
> > if (bSetBandWidth)
> > pHalData->bSetChnlBW = true;
> >
> > - if (!pHalData->bSetChnlBW && !pHalData->bSwChnl) {
> > - /* DBG_871X("<= PHY_HandleSwChnlAndSetBW8812: bSwChnl %d,
> > bSetChnlBW %d\n", pHalData->bSwChnl, pHalData->bSetChnlBW); */
> > + if (!pHalData->bSetChnlBW && !pHalData->bSwChnl)
> > return;
> > - }
>
> In this case, the + line is correct. Good job.
>
> >
> >
> > if (pHalData->bSwChnl) {
> > @@ -929,9 +905,7 @@ void PHY_SetSwChnlBWMode8723B(
> > u8 Offset80
> > )
> > {
> > - /* DBG_871X("%s() ===>\n", __func__); */
> >
> > PHY_HandleSwChnlAndSetBW8723B(Adapter, true, true, channel,
> > Bandwidth, Offset40, Offset80, channel);
> >
> > - /* DBG_871X("<==%s()\n", __func__); */
>
> Please delete the blank lines as well.
>
> regards,
> dan carpenter
>
This reply comments on the patch to fixes the missing a blank line warning
^ Please create proper patch subjects. Nobody has a glue what you are doing when looking at the subject. "mm/util: fix ??? warning" Which raises the question, what is ??? Compiler? static code checker? ... ? Thanks On 11.02.21 08:29, Adithya Chandrakasan wrote: FILE: mm/util.c:930: WARNING: Missing a blank line after declarations Signed-off-by: Adithya Chandrakasan --- mm/util.c | 1 + 1 file changed, 1 insertion(+) diff --git a/mm/util.c b/mm/util.c index 8c9b7d1e7c49..60286876636d 100644 --- a/mm/util.c +++ b/mm/util.c @@ -927,6 +927,7 @@ int get_cmdline(struct task_struct *task, char *buffer, int buflen) unsigned int len; struct mm_struct *mm = get_task_mm(task); unsigned long arg_start, arg_end, env_start, env_end; + if (!mm) goto out; if (!mm->arg_end) -- Thanks, David / dhildenb
[PATCH] afs: Fix updating of i_mode due to 3rd party change
Fix afs_apply_status() to mask off the irrelevant bits from status->mode
when OR'ing them into i_mode. This can happen when a 3rd party chmod
occurs.
Also fix afs_inode_init_from_status() to mask off the mode bits when
initialising i_mode.
Fixes: 260a980317da ("[AFS]: Add "directory write" support.")
Reported-by: Al Viro
Signed-off-by: David Howells
---
fs/afs/inode.c |9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/fs/afs/inode.c b/fs/afs/inode.c
index b0d7b892090d..d68abb9804b6 100644
--- a/fs/afs/inode.c
+++ b/fs/afs/inode.c
@@ -74,6 +74,7 @@ static int afs_inode_init_from_status(struct afs_operation
*op,
struct afs_file_status *status = >scb.status;
struct inode *inode = AFS_VNODE_TO_I(vnode);
struct timespec64 t;
+ mode_t mode = status->mode & S_IALLUGO;
_enter("{%llx:%llu.%u} %s",
vp->fid.vid, vp->fid.vnode, vp->fid.unique,
@@ -103,13 +104,13 @@ static int afs_inode_init_from_status(struct
afs_operation *op,
switch (status->type) {
case AFS_FTYPE_FILE:
- inode->i_mode = S_IFREG | status->mode;
+ inode->i_mode = S_IFREG | mode;
inode->i_op = _file_inode_operations;
inode->i_fop= _file_operations;
inode->i_mapping->a_ops = _fs_aops;
break;
case AFS_FTYPE_DIR:
- inode->i_mode = S_IFDIR | status->mode;
+ inode->i_mode = S_IFDIR | mode;
inode->i_op = _dir_inode_operations;
inode->i_fop= _dir_file_operations;
inode->i_mapping->a_ops = _dir_aops;
@@ -126,7 +127,7 @@ static int afs_inode_init_from_status(struct afs_operation
*op,
inode->i_fop= _mntpt_file_operations;
inode->i_mapping->a_ops = _fs_aops;
} else {
- inode->i_mode = S_IFLNK | status->mode;
+ inode->i_mode = S_IFLNK | mode;
inode->i_op = _symlink_inode_operations;
inode->i_mapping->a_ops = _fs_aops;
}
@@ -199,7 +200,7 @@ static void afs_apply_status(struct afs_operation *op,
if (status->mode != vnode->status.mode) {
mode = inode->i_mode;
mode &= ~S_IALLUGO;
- mode |= status->mode;
+ mode |= status->mode & S_IALLUGO;
WRITE_ONCE(inode->i_mode, mode);
}
Re: [PATCH] Input: psmouse - add support for FocalTech PS/2 Protocol v2
Hi Hamza,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on input/next]
[also build test ERROR on linux/master hid/for-next linus/master v5.11-rc7
next-20210125]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Hamza-Farooq/Input-psmouse-add-support-for-FocalTech-PS-2-Protocol-v2/20210211-074527
base: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git next
config: parisc-randconfig-r004-20210211 (attached as .config)
compiler: hppa-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/0day-ci/linux/commit/958fb71223bb82ea01edbcbf4970af1d888b1050
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Hamza-Farooq/Input-psmouse-add-support-for-FocalTech-PS-2-Protocol-v2/20210211-074527
git checkout 958fb71223bb82ea01edbcbf4970af1d888b1050
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=parisc
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All error/warnings (new ones prefixed by >>):
In file included from include/linux/build_bug.h:5,
from include/linux/bits.h:22,
from include/linux/bitops.h:5,
from drivers/input/mouse/psmouse-base.c:13:
drivers/input/mouse/psmouse-base.c: In function 'psmouse_extensions':
>> drivers/input/mouse/psmouse-base.c:1089:24: error: 'focaltech_v2_detect'
>> undeclared (first use in this function); did you mean 'focaltech_detect'?
1089 | if (psmouse_do_detect(focaltech_v2_detect,
|^~~
include/linux/compiler.h:58:52: note: in definition of macro '__trace_if_var'
58 | #define __trace_if_var(cond) (__builtin_constant_p(cond) ? (cond) :
__trace_if_value(cond))
|^~~~
drivers/input/mouse/psmouse-base.c:1089:2: note: in expansion of macro 'if'
1089 | if (psmouse_do_detect(focaltech_v2_detect,
| ^~
drivers/input/mouse/psmouse-base.c:1089:24: note: each undeclared identifier
is reported only once for each function it appears in
1089 | if (psmouse_do_detect(focaltech_v2_detect,
|^~~
include/linux/compiler.h:58:52: note: in definition of macro '__trace_if_var'
58 | #define __trace_if_var(cond) (__builtin_constant_p(cond) ? (cond) :
__trace_if_value(cond))
|^~~~
drivers/input/mouse/psmouse-base.c:1089:2: note: in expansion of macro 'if'
1089 | if (psmouse_do_detect(focaltech_v2_detect,
| ^~
--
>> drivers/input/mouse/focaltech_v2.c:27:5: warning: no previous prototype for
>> 'focaltech_v2_detect' [-Wmissing-prototypes]
27 | int focaltech_v2_detect(struct psmouse *psmouse, bool set_properties)
| ^~~
drivers/input/mouse/focaltech_v2.c:17:33: warning: 'switch_protocol' defined
but not used [-Wunused-const-variable=]
17 | static const struct fte_command switch_protocol[] = {
| ^~~
vim +1089 drivers/input/mouse/psmouse-base.c
1052
1053 /*
1054 * psmouse_extensions() probes for any extensions to the basic PS/2
protocol
1055 * the mouse may have.
1056 */
1057 static int psmouse_extensions(struct psmouse *psmouse,
1058unsigned int max_proto, bool
set_properties)
1059 {
1060 bool synaptics_hardware = false;
1061 int ret;
1062
1063 /*
1064 * Always check for focaltech, this is safe as it uses pnp-id
1065 * matching.
1066 */
1067 if (psmouse_do_detect(focaltech_detect,
1068psmouse, false, set_properties)) {
1069 if (max_proto > PSMOUSE_IMEX &&
1070 IS_ENABLED(CONFIG_MOUSE_PS2_FOCALTECH) &&
1071 (!set_properties || focaltech_init(psmouse) == 0)) {
1072 return PSMOUSE_FOCALTECH;
1073 }
1074 /*
1075 * Restrict psmouse_max_proto so that
psmouse_initialize()
1076 * does not try to reset rate and resolution, because
even
1077 * that upsets the device.
1078 * This also causes us to basically fall through to
basic
1079
Re: [PATCH 01/20] net: phy: realtek: Fix events detection failure in LPI mode
On Wed, Feb 10, 2021 at 07:47:20PM +0300, Serge Semin wrote:
> On Tue, Feb 09, 2021 at 10:56:46AM +, Russell King - ARM Linux admin
> wrote:
> > On Tue, Feb 09, 2021 at 11:37:29AM +0100, Heiner Kallweit wrote:
> > > Right, adding something like a genphy_{read,write}_mmd() doesn't make
> > > too much sense for now. What I meant is just exporting mmd_phy_indirect().
> > > Then you don't have to open-code the first three steps of a mmd
> > > read/write.
> > > And it requires no additional code in phylib.
> >
> > ... but at the cost that the compiler can no longer inline that code,
> > as I mentioned in my previous reply. (However, the cost of the accesses
> > will be higher.) On the plus side, less I-cache footprint, and smaller
> > kernel code.
>
> Just to note mmd_phy_indirect() isn't defined with inline specifier,
> but just as static and it's used twice in the
> drivers/net/phy/phy-core.c unit. So most likely the compiler won't
> inline the function code in there.
You can't always tell whether the compiler will inline a static function
or not.
> Anyway it's up to the PHY
> library maintainers to decide. Please settle the issue with Heiner and
> Andrew then. I am ok with both solutions and will do as you decide.
FYI, *I* am one of the phylib maintainers.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
Re: [PATCH] staging: rtl8723bs: fix function comments to follow kernel-doc
Sorry On Thu, Feb 11, 2021 at 3:34 PM Greg Kroah-Hartman wrote: > > On Thu, Feb 11, 2021 at 12:48:16AM +0530, karthek wrote: > > check this out > > Why ask us again when you already sent a patch? Do you see any other > developers doing that on the mailing lists? > > thanks, > > greg k-h
Re: possible deadlock in start_this_handle (2)
Hello,
added mm guys to CC.
On Wed 10-02-21 05:35:18, syzbot wrote:
> HEAD commit:1e0d27fc Merge branch 'akpm' (patches from Andrew)
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=15cbce90d0
> kernel config: https://syzkaller.appspot.com/x/.config?x=bd1f72220b2e57eb
> dashboard link: https://syzkaller.appspot.com/bug?extid=bfdded10ab7dcd7507ae
> userspace arch: i386
>
> Unfortunately, I don't have any reproducer for this issue yet.
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+bfdded10ab7dcd750...@syzkaller.appspotmail.com
>
> ==
> WARNING: possible circular locking dependency detected
> 5.11.0-rc6-syzkaller #0 Not tainted
> --
> kswapd0/2246 is trying to acquire lock:
> 888041a988e0 (jbd2_handle){}-{0:0}, at:
> start_this_handle+0xf81/0x1380 fs/jbd2/transaction.c:444
>
> but task is already holding lock:
> 8be892c0 (fs_reclaim){+.+.}-{0:0}, at: __fs_reclaim_acquire+0x0/0x30
> mm/page_alloc.c:5195
>
> which lock already depends on the new lock.
>
> the existing dependency chain (in reverse order) is:
>
> -> #2 (fs_reclaim){+.+.}-{0:0}:
>__fs_reclaim_acquire mm/page_alloc.c:4326 [inline]
>fs_reclaim_acquire+0x117/0x150 mm/page_alloc.c:4340
>might_alloc include/linux/sched/mm.h:193 [inline]
>slab_pre_alloc_hook mm/slab.h:493 [inline]
>slab_alloc_node mm/slub.c:2817 [inline]
>__kmalloc_node+0x5f/0x430 mm/slub.c:4015
>kmalloc_node include/linux/slab.h:575 [inline]
>kvmalloc_node+0x61/0xf0 mm/util.c:587
>kvmalloc include/linux/mm.h:781 [inline]
>ext4_xattr_inode_cache_find fs/ext4/xattr.c:1465 [inline]
>ext4_xattr_inode_lookup_create fs/ext4/xattr.c:1508 [inline]
>ext4_xattr_set_entry+0x1ce6/0x3780 fs/ext4/xattr.c:1649
>ext4_xattr_ibody_set+0x78/0x2b0 fs/ext4/xattr.c:2224
>ext4_xattr_set_handle+0x8f4/0x13e0 fs/ext4/xattr.c:2380
>ext4_xattr_set+0x13a/0x340 fs/ext4/xattr.c:2493
>ext4_xattr_user_set+0xbc/0x100 fs/ext4/xattr_user.c:40
>__vfs_setxattr+0x10e/0x170 fs/xattr.c:177
>__vfs_setxattr_noperm+0x11a/0x4c0 fs/xattr.c:208
>__vfs_setxattr_locked+0x1bf/0x250 fs/xattr.c:266
>vfs_setxattr+0x135/0x320 fs/xattr.c:291
>setxattr+0x1ff/0x290 fs/xattr.c:553
>path_setxattr+0x170/0x190 fs/xattr.c:572
>__do_sys_setxattr fs/xattr.c:587 [inline]
>__se_sys_setxattr fs/xattr.c:583 [inline]
>__ia32_sys_setxattr+0xbc/0x150 fs/xattr.c:583
>do_syscall_32_irqs_on arch/x86/entry/common.c:77 [inline]
>__do_fast_syscall_32+0x56/0x80 arch/x86/entry/common.c:139
>do_fast_syscall_32+0x2f/0x70 arch/x86/entry/common.c:164
>entry_SYSENTER_compat_after_hwframe+0x4d/0x5c
This stacktrace should never happen. ext4_xattr_set() starts a transaction.
That internally goes through start_this_handle() which calls:
handle->saved_alloc_context = memalloc_nofs_save();
and we restore the allocation context only in stop_this_handle() when
stopping the handle. And with this fs_reclaim_acquire() should remove
__GFP_FS from the mask and not call __fs_reclaim_acquire().
Now I have no idea why something here didn't work out. Given we don't have
a reproducer it will be probably difficult to debug this. I'd note that
about year and half ago similar report happened (got autoclosed) so it may
be something real somewhere but it may also be just some HW glitch or
something like that.
Honza
--
Jan Kara
SUSE Labs, CR
[PATCH v13 net-next 00/15] net: mvpp2: Add TX Flow Control support
From: Stefan Chulski Armada hardware has a pause generation mechanism in GOP (MAC). The GOP generate flow control frames based on an indication programmed in Ports Control 0 Register. There is a bit per port. However assertion of the PortX Pause bits in the ports control 0 register only sends a one time pause. To complement the function the GOP has a mechanism to periodically send pause control messages based on periodic counters. This mechanism ensures that the pause is effective as long as the Appropriate PortX Pause is asserted. Problem is that Packet Processor that actually can drop packets due to lack of resources not connected to the GOP flow control generation mechanism. To solve this issue Armada has firmware running on CM3 CPU dedicated for Flow Control support. Firmware monitors Packet Processor resources and asserts XON/XOFF by writing to Ports Control 0 Register. MSS shared SRAM memory used to communicate between CM3 firmware and PP2 driver. During init PP2 driver informs firmware about used BM pools, RXQs, congestion and depletion thresholds. The pause frames are generated whenever congestion or depletion in resources is detected. The back pressure is stopped when the resource reaches a sufficient level. So the congestion/depletion and sufficient level implement a hysteresis that reduces the XON/XOFF toggle frequency. Packet Processor v23 hardware introduces support for RX FIFO fill level monitor. Patch "add PPv23 version definition" to differ between v23 and v22 hardware. Patch "add TX FC firmware check" verifies that CM3 firmware supports Flow Control monitoring. v12 --> v13 - Remove bm_underrun_protect module_param v11 --> v12 - Improve warning message in "net: mvpp2: add TX FC firmware check" patch v10 --> v11 - Improve "net: mvpp2: add CM3 SRAM memory map" comment - Move condition check to 'net: mvpp2: always compare hw-version vs MVPP21' patch v9 --> v10 - Add CM3 SRAM description to PPv2 documentation v8 --> v9 - Replace generic pool allocation with devm_ioremap_resource v7 --> v8 - Reorder "always compare hw-version vs MVPP21" and "add PPv23 version definition" commits - Typo fixes - Remove condition fix from "add RXQ flow control configurations" v6 --> v7 - Reduce patch set from 18 to 15 patches - Documentation change combined into a single patch - RXQ and BM size change combined into a single patch - Ring size change check moved into "add RXQ flow control configurations" commit v5 --> v6 - No change v4 --> v5 - Add missed Signed-off - Fix warnings in patches 3 and 12 - Add revision requirement to warning message - Move mss_spinlock into RXQ flow control configurations patch - Improve FCA RXQ non occupied descriptor threshold commit message v3 --> v4 - Remove RFC tag v2 --> v3 - Remove inline functions - Add PPv2.3 description into marvell-pp2.txt - Improve mvpp2_interrupts_mask/unmask procedure - Improve FC enable/disable procedure - Add priv->sram_pool check - Remove gen_pool_destroy call - Reduce Flow Control timer to x100 faster v1 --> v2 - Add memory requirements information - Add EPROBE_DEFER if of_gen_pool_get return NULL - Move Flow control configuration to mvpp2_mac_link_up callback - Add firmware version info with Flow control support Konstantin Porotchkin (1): dts: marvell: add CM3 SRAM memory to cp11x ethernet device tree Stefan Chulski (14): doc: marvell: add CM3 address space and PPv2.3 description net: mvpp2: add CM3 SRAM memory map net: mvpp2: always compare hw-version vs MVPP21 net: mvpp2: add PPv23 version definition net: mvpp2: increase BM pool and RXQ size net: mvpp2: add FCA periodic timer configurations net: mvpp2: add FCA RXQ non occupied descriptor threshold net: mvpp2: enable global flow control net: mvpp2: add RXQ flow control configurations net: mvpp2: add ethtool flow control configuration support net: mvpp2: add BM protection underrun feature support net: mvpp2: add PPv23 RX FIFO flow control net: mvpp2: set 802.3x GoP Flow Control mode net: mvpp2: add TX FC firmware check Documentation/devicetree/bindings/net/marvell-pp2.txt | 6 +- arch/arm64/boot/dts/marvell/armada-cp11x.dtsi | 2 +- drivers/net/ethernet/marvell/mvpp2/mvpp2.h| 124 - drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 516 ++-- 4 files changed, 599 insertions(+), 49 deletions(-) -- 1.9.1
[PATCH v13 net-next 01/15] doc: marvell: add CM3 address space and PPv2.3 description
From: Stefan Chulski
Patch adds CM3 address space and PPv2.3 description.
Signed-off-by: Stefan Chulski
Acked-by: Marcin Wojtas
---
Documentation/devicetree/bindings/net/marvell-pp2.txt | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/marvell-pp2.txt
b/Documentation/devicetree/bindings/net/marvell-pp2.txt
index b783976..ce15c17 100644
--- a/Documentation/devicetree/bindings/net/marvell-pp2.txt
+++ b/Documentation/devicetree/bindings/net/marvell-pp2.txt
@@ -1,5 +1,6 @@
* Marvell Armada 375 Ethernet Controller (PPv2.1)
Marvell Armada 7K/8K Ethernet Controller (PPv2.2)
+ Marvell CN913X Ethernet Controller (PPv2.3)
Required properties:
@@ -12,10 +13,11 @@ Required properties:
- common controller registers
- LMS registers
- one register area per Ethernet port
- For "marvell,armada-7k-pp2", must contain the following register
+ For "marvell,armada-7k-pp2" used by 7K/8K and CN913X, must contain the
following register
sets:
- packet processor registers
- networking interfaces registers
+ - CM3 address space used for TX Flow Control
- clocks: pointers to the reference clocks for this device, consequently:
- main controller clock (for both armada-375-pp2 and armada-7k-pp2)
@@ -81,7 +83,7 @@ Example for marvell,armada-7k-pp2:
cpm_ethernet: ethernet@0 {
compatible = "marvell,armada-7k-pp22";
- reg = <0x0 0x10>, <0x129000 0xb000>;
+ reg = <0x0 0x10>, <0x129000 0xb000>, <0x22 0x800>;
clocks = <_syscon0 1 3>, <_syscon0 1 9>,
<_syscon0 1 5>, <_syscon0 1 6>, <_syscon0 1 18>;
clock-names = "pp_clk", "gop_clk", "mg_clk", "mg_core_clk", "axi_clk";
--
1.9.1
[PATCH v13 net-next 02/15] dts: marvell: add CM3 SRAM memory to cp11x ethernet device tree
From: Konstantin Porotchkin
CM3 SRAM address space will be used for Flow Control configuration.
Signed-off-by: Stefan Chulski
Signed-off-by: Konstantin Porotchkin
Acked-by: Marcin Wojtas
Acked-by: Rob Herring
---
arch/arm64/boot/dts/marvell/armada-cp11x.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/marvell/armada-cp11x.dtsi
b/arch/arm64/boot/dts/marvell/armada-cp11x.dtsi
index 9dcf16b..6fe0d26 100644
--- a/arch/arm64/boot/dts/marvell/armada-cp11x.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-cp11x.dtsi
@@ -59,7 +59,7 @@
CP11X_LABEL(ethernet): ethernet@0 {
compatible = "marvell,armada-7k-pp22";
- reg = <0x0 0x10>, <0x129000 0xb000>;
+ reg = <0x0 0x10>, <0x129000 0xb000>, <0x22
0x800>;
clocks = <_LABEL(clk) 1 3>, <_LABEL(clk) 1
9>,
<_LABEL(clk) 1 5>, <_LABEL(clk) 1
6>,
<_LABEL(clk) 1 18>;
--
1.9.1
[PATCH v13 net-next 09/15] net: mvpp2: enable global flow control
From: Stefan Chulski
This patch enables global flow control in FW and in the phylink validate mask.
Signed-off-by: Stefan Chulski
Acked-by: Marcin Wojtas
---
drivers/net/ethernet/marvell/mvpp2/mvpp2.h | 11 +--
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 30 +++-
2 files changed, 37 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
index d2cc513c..8945fb9 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
@@ -763,9 +763,11 @@
((kb) * 1024 - MVPP2_TX_FIFO_THRESHOLD_MIN)
/* MSS Flow control */
-#define FC_QUANTA 0x
-#define FC_CLK_DIVIDER 100
-#define MSS_THRESHOLD_STOP 768
+#define MSS_FC_COM_REG 0
+#define FLOW_CONTROL_ENABLE_BITBIT(0)
+#define FC_QUANTA 0x
+#define FC_CLK_DIVIDER 100
+#define MSS_THRESHOLD_STOP 768
/* RX buffer constants */
#define MVPP2_SKB_SHINFO_SIZE \
@@ -1017,6 +1019,9 @@ struct mvpp2 {
/* page_pool allocator */
struct page_pool *page_pool[MVPP2_PORT_MAX_RXQ];
+
+ /* Global TX Flow Control config */
+ bool global_tx_fc;
};
struct mvpp2_pcpu_stats {
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
index 8b4073c..027101b 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
@@ -91,6 +91,16 @@ static inline u32 mvpp2_cpu_to_thread(struct mvpp2 *priv,
int cpu)
return cpu % priv->nthreads;
}
+static void mvpp2_cm3_write(struct mvpp2 *priv, u32 offset, u32 data)
+{
+ writel(data, priv->cm3_base + offset);
+}
+
+static u32 mvpp2_cm3_read(struct mvpp2 *priv, u32 offset)
+{
+ return readl(priv->cm3_base + offset);
+}
+
static struct page_pool *
mvpp2_create_page_pool(struct device *dev, int num, int len,
enum dma_data_direction dma_dir)
@@ -5950,6 +5960,11 @@ static void mvpp2_phylink_validate(struct phylink_config
*config,
phylink_set(mask, Autoneg);
phylink_set_port_modes(mask);
+ if (port->priv->global_tx_fc) {
+ phylink_set(mask, Pause);
+ phylink_set(mask, Asym_Pause);
+ }
+
switch (state->interface) {
case PHY_INTERFACE_MODE_10GBASER:
case PHY_INTERFACE_MODE_XAUI:
@@ -6951,7 +6966,7 @@ static int mvpp2_probe(struct platform_device *pdev)
struct resource *res;
void __iomem *base;
int i, shared;
- int err;
+ int err, val;
priv = devm_kzalloc(>dev, sizeof(*priv), GFP_KERNEL);
if (!priv)
@@ -7003,6 +7018,10 @@ static int mvpp2_probe(struct platform_device *pdev)
err = mvpp2_get_sram(pdev, priv);
if (err)
dev_warn(>dev, "Fail to alloc CM3 SRAM\n");
+
+ /* Enable global Flow Control only if handler to SRAM not NULL
*/
+ if (priv->cm3_base)
+ priv->global_tx_fc = true;
}
if (priv->hw_version != MVPP21 && dev_of_node(>dev)) {
@@ -7168,6 +7187,15 @@ static int mvpp2_probe(struct platform_device *pdev)
goto err_port_probe;
}
+ /* Enable global flow control. In this stage global
+* flow control enabled, but still disabled per port.
+*/
+ if (priv->global_tx_fc && priv->hw_version != MVPP21) {
+ val = mvpp2_cm3_read(priv, MSS_FC_COM_REG);
+ val |= FLOW_CONTROL_ENABLE_BIT;
+ mvpp2_cm3_write(priv, MSS_FC_COM_REG, val);
+ }
+
mvpp2_dbgfs_init(priv, pdev->name);
platform_set_drvdata(pdev, priv);
--
1.9.1
Re: [PATCH v2 4/8] xen/netback: fix spurious event detection for common event case
On 11.02.2021 11:16, Juergen Gross wrote:
> --- a/drivers/net/xen-netback/interface.c
> +++ b/drivers/net/xen-netback/interface.c
> @@ -162,13 +162,15 @@ irqreturn_t xenvif_interrupt(int irq, void *dev_id)
> {
> struct xenvif_queue *queue = dev_id;
> int old;
> + bool has_rx, has_tx;
>
> old = atomic_fetch_or(NETBK_COMMON_EOI, >eoi_pending);
> WARN(old, "Interrupt while EOI pending\n");
>
> - /* Use bitwise or as we need to call both functions. */
> - if ((!xenvif_handle_tx_interrupt(queue) |
> - !xenvif_handle_rx_interrupt(queue))) {
> + has_tx = xenvif_handle_tx_interrupt(queue);
> + has_rx = xenvif_handle_rx_interrupt(queue);
> +
> + if (!has_rx && !has_tx) {
> atomic_andnot(NETBK_COMMON_EOI, >eoi_pending);
> xen_irq_lateeoi(irq, XEN_EOI_FLAG_SPURIOUS);
> }
>
Ah yes, what was originally meant really was
if (!(xenvif_handle_tx_interrupt(queue) |
xenvif_handle_rx_interrupt(queue))) {
(also hinted at by the otherwise pointless inner parentheses),
which you simply write in an alternative way.
Reviewed-by: Jan Beulich
Jan
[PATCH v13 net-next 08/15] net: mvpp2: add FCA RXQ non occupied descriptor threshold
From: Stefan Chulski
The firmware needs to monitor the RX Non-occupied descriptor
bits for flow control to move to XOFF mode.
These bits need to be unmasked to be functional, but they will
not raise interrupts as we leave the RX exception summary
bit in MVPP2_ISR_RX_TX_MASK_REG clear.
Signed-off-by: Stefan Chulski
Acked-by: Marcin Wojtas
---
drivers/net/ethernet/marvell/mvpp2/mvpp2.h | 3 ++
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 44
2 files changed, 40 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
index 9239d80..d2cc513c 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
@@ -295,6 +295,8 @@
#define MVPP2_PON_CAUSE_TXP_OCCUP_DESC_ALL_MASK0x3fc0
#define MVPP2_PON_CAUSE_MISC_SUM_MASK BIT(31)
#define MVPP2_ISR_MISC_CAUSE_REG 0x55b0
+#define MVPP2_ISR_RX_ERR_CAUSE_REG(port) (0x5520 + 4 * (port))
+#define MVPP2_ISR_RX_ERR_CAUSE_NONOCC_MASK 0x00ff
/* Buffer Manager registers */
#define MVPP2_BM_POOL_BASE_REG(pool) (0x6000 + ((pool) * 4))
@@ -763,6 +765,7 @@
/* MSS Flow control */
#define FC_QUANTA 0x
#define FC_CLK_DIVIDER 100
+#define MSS_THRESHOLD_STOP 768
/* RX buffer constants */
#define MVPP2_SKB_SHINFO_SIZE \
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
index 761f745..8b4073c 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
@@ -1133,14 +1133,19 @@ static inline void mvpp2_qvec_interrupt_disable(struct
mvpp2_queue_vector *qvec)
static void mvpp2_interrupts_mask(void *arg)
{
struct mvpp2_port *port = arg;
+ int cpu = smp_processor_id();
+ u32 thread;
/* If the thread isn't used, don't do anything */
- if (smp_processor_id() > port->priv->nthreads)
+ if (cpu > port->priv->nthreads)
return;
- mvpp2_thread_write(port->priv,
- mvpp2_cpu_to_thread(port->priv, smp_processor_id()),
+ thread = mvpp2_cpu_to_thread(port->priv, cpu);
+
+ mvpp2_thread_write(port->priv, thread,
MVPP2_ISR_RX_TX_MASK_REG(port->id), 0);
+ mvpp2_thread_write(port->priv, thread,
+ MVPP2_ISR_RX_ERR_CAUSE_REG(port->id), 0);
}
/* Unmask the current thread's Rx/Tx interrupts.
@@ -1150,20 +1155,25 @@ static void mvpp2_interrupts_mask(void *arg)
static void mvpp2_interrupts_unmask(void *arg)
{
struct mvpp2_port *port = arg;
- u32 val;
+ int cpu = smp_processor_id();
+ u32 val, thread;
/* If the thread isn't used, don't do anything */
- if (smp_processor_id() > port->priv->nthreads)
+ if (cpu > port->priv->nthreads)
return;
+ thread = mvpp2_cpu_to_thread(port->priv, cpu);
+
val = MVPP2_CAUSE_MISC_SUM_MASK |
MVPP2_CAUSE_RXQ_OCCUP_DESC_ALL_MASK(port->priv->hw_version);
if (port->has_tx_irqs)
val |= MVPP2_CAUSE_TXQ_OCCUP_DESC_ALL_MASK;
- mvpp2_thread_write(port->priv,
- mvpp2_cpu_to_thread(port->priv, smp_processor_id()),
+ mvpp2_thread_write(port->priv, thread,
MVPP2_ISR_RX_TX_MASK_REG(port->id), val);
+ mvpp2_thread_write(port->priv, thread,
+ MVPP2_ISR_RX_ERR_CAUSE_REG(port->id),
+ MVPP2_ISR_RX_ERR_CAUSE_NONOCC_MASK);
}
static void
@@ -1188,6 +1198,9 @@ static void mvpp2_interrupts_unmask(void *arg)
mvpp2_thread_write(port->priv, v->sw_thread_id,
MVPP2_ISR_RX_TX_MASK_REG(port->id), val);
+ mvpp2_thread_write(port->priv, v->sw_thread_id,
+ MVPP2_ISR_RX_ERR_CAUSE_REG(port->id),
+ MVPP2_ISR_RX_ERR_CAUSE_NONOCC_MASK);
}
}
@@ -2393,6 +2406,20 @@ static void mvpp2_txp_max_tx_size_set(struct mvpp2_port
*port)
}
}
+/* Set the number of non-occupied descriptors threshold */
+static void mvpp2_set_rxq_free_tresh(struct mvpp2_port *port,
+struct mvpp2_rx_queue *rxq)
+{
+ u32 val;
+
+ mvpp2_write(port->priv, MVPP2_RXQ_NUM_REG, rxq->id);
+
+ val = mvpp2_read(port->priv, MVPP2_RXQ_THRESH_REG);
+ val &= ~MVPP2_RXQ_NON_OCCUPIED_MASK;
+ val |= MSS_THRESHOLD_STOP << MVPP2_RXQ_NON_OCCUPIED_OFFSET;
+ mvpp2_write(port->priv, MVPP2_RXQ_THRESH_REG, val);
+}
+
/* Set the number of packets that will be received before Rx interrupt
* will be generated by HW.
*/
@@ -2648,6 +2675,9 @@ static int mvpp2_rxq_init(struct mvpp2_port *port,
mvpp2_rx_pkts_coal_set(port, rxq);
mvpp2_rx_time_coal_set(port, rxq);
+
Re: [PATCH 01/20] net: phy: realtek: Fix events detection failure in LPI mode
On Thu, Feb 11, 2021 at 10:39:41AM +, Russell King - ARM Linux admin wrote:
> On Wed, Feb 10, 2021 at 07:47:20PM +0300, Serge Semin wrote:
> > On Tue, Feb 09, 2021 at 10:56:46AM +, Russell King - ARM Linux admin
> > wrote:
> > > On Tue, Feb 09, 2021 at 11:37:29AM +0100, Heiner Kallweit wrote:
> > > > Right, adding something like a genphy_{read,write}_mmd() doesn't make
> > > > too much sense for now. What I meant is just exporting
> > > > mmd_phy_indirect().
> > > > Then you don't have to open-code the first three steps of a mmd
> > > > read/write.
> > > > And it requires no additional code in phylib.
> > >
> > > ... but at the cost that the compiler can no longer inline that code,
> > > as I mentioned in my previous reply. (However, the cost of the accesses
> > > will be higher.) On the plus side, less I-cache footprint, and smaller
> > > kernel code.
> >
> > Just to note mmd_phy_indirect() isn't defined with inline specifier,
> > but just as static and it's used twice in the
> > drivers/net/phy/phy-core.c unit. So most likely the compiler won't
> > inline the function code in there.
>
> You can't always tell whether the compiler will inline a static function
> or not.
>
> > Anyway it's up to the PHY
> > library maintainers to decide. Please settle the issue with Heiner and
> > Andrew then. I am ok with both solutions and will do as you decide.
>
> FYI, *I* am one of the phylib maintainers.
Of course I saw you in the list of maintainers. My message was that
currently two maintainers claims contradicting requests. Thus in order
to go further with this patch first you need to get to some agreement
between yourself. That's why we need to have a response from Hainer
about your arguments against his suggestion.
-Sergey
>
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
Re: [RFC PATCH v4 01/17] af_vsock: update functions for connectible socket
On Sun, Feb 07, 2021 at 06:14:23PM +0300, Arseny Krasnov wrote:
This prepares af_vsock.c for SEQPACKET support: some functions such
as setsockopt(), getsockopt(), connect(), recvmsg(), sendmsg() are
shared between both types of sockets, so rename them in general
manner.
Signed-off-by: Arseny Krasnov
---
net/vmw_vsock/af_vsock.c | 64 +---
1 file changed, 34 insertions(+), 30 deletions(-)
This patch LGTM:
Reviewed-by: Stefano Garzarella
Thanks,
Stefano
diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c
index 6894f21dc147..f4fabec50650 100644
--- a/net/vmw_vsock/af_vsock.c
+++ b/net/vmw_vsock/af_vsock.c
@@ -604,8 +604,8 @@ static void vsock_pending_work(struct work_struct *work)
/ SOCKET OPERATIONS /
-static int __vsock_bind_stream(struct vsock_sock *vsk,
- struct sockaddr_vm *addr)
+static int __vsock_bind_connectible(struct vsock_sock *vsk,
+ struct sockaddr_vm *addr)
{
static u32 port;
struct sockaddr_vm new_addr;
@@ -685,7 +685,7 @@ static int __vsock_bind(struct sock *sk, struct sockaddr_vm
*addr)
switch (sk->sk_socket->type) {
case SOCK_STREAM:
spin_lock_bh(_table_lock);
- retval = __vsock_bind_stream(vsk, addr);
+ retval = __vsock_bind_connectible(vsk, addr);
spin_unlock_bh(_table_lock);
break;
@@ -767,6 +767,11 @@ static struct sock *__vsock_create(struct net *net,
return sk;
}
+static bool sock_type_connectible(u16 type)
+{
+ return type == SOCK_STREAM;
+}
+
static void __vsock_release(struct sock *sk, int level)
{
if (sk) {
@@ -785,7 +790,7 @@ static void __vsock_release(struct sock *sk, int level)
if (vsk->transport)
vsk->transport->release(vsk);
- else if (sk->sk_type == SOCK_STREAM)
+ else if (sock_type_connectible(sk->sk_type))
vsock_remove_sock(vsk);
sock_orphan(sk);
@@ -945,7 +950,7 @@ static int vsock_shutdown(struct socket *sock, int mode)
sk = sock->sk;
if (sock->state == SS_UNCONNECTED) {
err = -ENOTCONN;
- if (sk->sk_type == SOCK_STREAM)
+ if (sock_type_connectible(sk->sk_type))
return err;
} else {
sock->state = SS_DISCONNECTING;
@@ -960,7 +965,7 @@ static int vsock_shutdown(struct socket *sock, int mode)
sk->sk_state_change(sk);
release_sock(sk);
- if (sk->sk_type == SOCK_STREAM) {
+ if (sock_type_connectible(sk->sk_type)) {
sock_reset_flag(sk, SOCK_DONE);
vsock_send_shutdown(sk, mode);
}
@@ -1013,7 +1018,7 @@ static __poll_t vsock_poll(struct file *file, struct
socket *sock,
if (!(sk->sk_shutdown & SEND_SHUTDOWN))
mask |= EPOLLOUT | EPOLLWRNORM | EPOLLWRBAND;
- } else if (sock->type == SOCK_STREAM) {
+ } else if (sock_type_connectible(sk->sk_type)) {
const struct vsock_transport *transport;
lock_sock(sk);
@@ -1263,8 +1268,8 @@ static void vsock_connect_timeout(struct work_struct
*work)
sock_put(sk);
}
-static int vsock_stream_connect(struct socket *sock, struct sockaddr *addr,
- int addr_len, int flags)
+static int vsock_connect(struct socket *sock, struct sockaddr *addr,
+int addr_len, int flags)
{
int err;
struct sock *sk;
@@ -1414,7 +1419,7 @@ static int vsock_accept(struct socket *sock, struct
socket *newsock, int flags,
lock_sock(listener);
- if (sock->type != SOCK_STREAM) {
+ if (!sock_type_connectible(sock->type)) {
err = -EOPNOTSUPP;
goto out;
}
@@ -1491,7 +1496,7 @@ static int vsock_listen(struct socket *sock, int backlog)
lock_sock(sk);
- if (sock->type != SOCK_STREAM) {
+ if (!sock_type_connectible(sk->sk_type)) {
err = -EOPNOTSUPP;
goto out;
}
@@ -1535,11 +1540,11 @@ static void vsock_update_buffer_size(struct vsock_sock
*vsk,
vsk->buffer_size = val;
}
-static int vsock_stream_setsockopt(struct socket *sock,
- int level,
- int optname,
- sockptr_t optval,
- unsigned int optlen)
+static int vsock_connectible_setsockopt(struct socket *sock,
+ int level,
+ int optname,
+ sockptr_t optval,
+ unsigned int optlen)
{
int err;
struct sock *sk;
@@ -1617,10 +1622,10 @@ static int
Re: [PATCH] staging: rtl8723bs: remove obsolete commented out code
On Thu, Feb 11, 2021 at 4:16 PM Greg Kroah-Hartman wrote: > > A: http://en.wikipedia.org/wiki/Top_post > Q: Were do I find info about this thing called top-posting? > A: Because it messes up the order in which people normally read text. > Q: Why is top-posting such a bad thing? > A: Top-posting. > Q: What is the most annoying thing in e-mail? > > A: No. > Q: Should I include quotations after my reply? > > http://daringfireball.net/2007/07/on_top > > On Thu, Feb 11, 2021 at 04:00:04PM +0530, karthek wrote: > > Should i send them as patch series? > > Please do. > > thanks, > > greg k-h Yeah, it is clearly mentioned in lfd103 which i do remember but i want you to know that it's purely accidental
[PATCH] staging: wfx: avoid defining array of flexible struct
In this particular case, the struct element is already flexible struct.
Thus struct element ie[] is ambiguous inside another struct. The members
of struct element ie aren't being accessed in code anywhere. The data of
u8 type is copied in it. So it has been changed to u8 ie[] to make the
sparse happy and code simple.
Warning from sparse:
drivers/stagingwfx/hif_tx.c: note: in included file (through
drivers/stagingwfx/data_tx.h, drivers/staging//wfx/wfx.h):
drivers/staging//wfx/hif_api_cmd.h:103:26: warning: array of flexible structures
Signed-off-by: Muhammad Usama Anjum
---
drivers/staging/wfx/hif_api_cmd.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/wfx/hif_api_cmd.h
b/drivers/staging/wfx/hif_api_cmd.h
index 11bc1a58edae..58c9bb036011 100644
--- a/drivers/staging/wfx/hif_api_cmd.h
+++ b/drivers/staging/wfx/hif_api_cmd.h
@@ -100,7 +100,7 @@ struct hif_req_update_ie {
u8 reserved1:5;
u8 reserved2;
__le16 num_ies;
- struct element ie[];
+ u8 ie[];
} __packed;
struct hif_cnf_update_ie {
--
2.25.1
Re: [PATCH -next] staging: ks7010: Macros with complex values
On Thu, Feb 11, 2021 at 11:02:51AM +0100, Greg KH wrote:
> On Thu, Feb 11, 2021 at 12:22:39PM +0300, Fatih Yildirim wrote:
> > Fix for checkpatch.pl warning:
> > Macros with complex values should be enclosed in parentheses.
> >
> > Signed-off-by: Fatih Yildirim
> > ---
> > drivers/staging/ks7010/ks_hostif.h | 24
> > 1 file changed, 12 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/staging/ks7010/ks_hostif.h
> > b/drivers/staging/ks7010/ks_hostif.h
> > index 39138191a556..c62a494ed6bb 100644
> > --- a/drivers/staging/ks7010/ks_hostif.h
> > +++ b/drivers/staging/ks7010/ks_hostif.h
> > @@ -498,20 +498,20 @@ struct hostif_mic_failure_request {
> > #define TX_RATE_FIXED 5
> >
> > /* 11b rate */
> > -#define TX_RATE_1M (u8)(10 / 5)/* 11b 11g basic rate */
> > -#define TX_RATE_2M (u8)(20 / 5)/* 11b 11g basic rate */
> > -#define TX_RATE_5M (u8)(55 / 5)/* 11g basic rate */
> > -#define TX_RATE_11M(u8)(110 / 5) /* 11g basic rate */
> > +#define TX_RATE_1M ((u8)(10 / 5)) /* 11b 11g basic rate */
> > +#define TX_RATE_2M ((u8)(20 / 5)) /* 11b 11g basic rate */
> > +#define TX_RATE_5M ((u8)(55 / 5)) /* 11g basic rate */
> > +#define TX_RATE_11M((u8)(110 / 5)) /* 11g basic rate */
>
> But these are not "complex macros" that need an extra () added to them,
> right?
>
> Checkpatch is a hint, it's not a code parser and can not always know
> what is happening. With your knowledge of C, does this look like
> something that needs to be "fixed"?
>
> thanks,
>
> greg k-h
Hi Greg,
Thanks for your reply.
Actually, I'm following the Eudyptula Challenge and I'm at task 10.
Task is to find and fix a coding style in linux-next/drivers/staging.
I've checked many files with checkpatch.pl but they are almost fine :)
I found this one and prepared a patch for it.
Thanks in advance for your comments and advice.
Thanks,
Fatih
[PATCH 3/3] regulator: pca9450: Enable system reset on WDOG_B assertion
From: Frieder Schrempf
By default the PCA9450 doesn't handle the assertion of the WDOG_B
signal, but this is required to guarantee that things like software
resets triggered by the watchdog work reliably.
As we don't want to rely on the bootloader to enable this, we tell
the PMIC to issue a cold reset in case the WDOG_B signal is
asserted (WDOG_B_CFG = 10), just as the NXP U-Boot code does.
Signed-off-by: Frieder Schrempf
---
drivers/regulator/pca9450-regulator.c | 8
include/linux/regulator/pca9450.h | 7 +++
2 files changed, 15 insertions(+)
diff --git a/drivers/regulator/pca9450-regulator.c
b/drivers/regulator/pca9450-regulator.c
index 1bba8fdcb7b7..833d398c6aa2 100644
--- a/drivers/regulator/pca9450-regulator.c
+++ b/drivers/regulator/pca9450-regulator.c
@@ -797,6 +797,14 @@ static int pca9450_i2c_probe(struct i2c_client *i2c,
return ret;
}
+ /* Set reset behavior on assertion of WDOG_B signal */
+ ret = regmap_update_bits(pca9450->regmap, PCA9450_REG_RESET_CTRL,
+ WDOG_B_CFG_MASK, WDOG_B_CFG_COLD_LDO12);
+ if (ret) {
+ dev_err(>dev, "Failed to set WDOG_B reset behavior\n");
+ return ret;
+ }
+
/*
* The driver uses the LDO5CTRL_H register to control the LDO5
regulator.
* This is only valid if the SD_VSEL input of the PMIC is high. Let's
diff --git a/include/linux/regulator/pca9450.h
b/include/linux/regulator/pca9450.h
index 1bbd3014f906..ccdb5320a240 100644
--- a/include/linux/regulator/pca9450.h
+++ b/include/linux/regulator/pca9450.h
@@ -216,4 +216,11 @@ enum {
#define IRQ_THERM_105 0x02
#define IRQ_THERM_125 0x01
+/* PCA9450_REG_RESET_CTRL bits */
+#define WDOG_B_CFG_MASK0xC0
+#define WDOG_B_CFG_NONE0x00
+#define WDOG_B_CFG_WARM0x40
+#define WDOG_B_CFG_COLD_LDO12 0x80
+#define WDOG_B_CFG_COLD0xC0
+
#endif /* __LINUX_REG_PCA9450_H__ */
--
2.25.1
[PATCH v2 1/4] net: ti: am65-cpsw-nuss: Add devlink support
AM65 NUSS ethernet switch on K3 devices can be configured to work either
in independent mac mode where each port acts as independent network
interface (multi mac) or switch mode.
Add devlink hooks to provide a way to switch b/w these modes.
Rationale to use devlink instead of defaulting to bridge mode is that
SoC use cases require to support multiple independent MAC ports with no
switching so that users can use software bridges with multi-mac
configuration (e.g: to support LAG, HSR/PRP, etc). Also, switching
between multi mac and switch mode requires significant Port and ALE
reconfiguration, therefore is easier to be made as part of mode change
devlink hooks. It also allows to keep user interface similar to what
was implemented for the previous generation of TI CPSW IP
(on AM33/AM43/AM57 SoCs).
Signed-off-by: Vignesh Raghavendra
---
.../devlink/am65-nuss-cpsw-switch.rst | 26 ++
Documentation/networking/devlink/index.rst| 1 +
drivers/net/ethernet/ti/Kconfig | 10 +
drivers/net/ethernet/ti/am65-cpsw-nuss.c | 363 +-
drivers/net/ethernet/ti/am65-cpsw-nuss.h | 22 ++
5 files changed, 404 insertions(+), 18 deletions(-)
create mode 100644 Documentation/networking/devlink/am65-nuss-cpsw-switch.rst
diff --git a/Documentation/networking/devlink/am65-nuss-cpsw-switch.rst
b/Documentation/networking/devlink/am65-nuss-cpsw-switch.rst
new file mode 100644
index ..1e589c26abff
--- /dev/null
+++ b/Documentation/networking/devlink/am65-nuss-cpsw-switch.rst
@@ -0,0 +1,26 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+==
+am65-cpsw-nuss devlink support
+==
+
+This document describes the devlink features implemented by the
``am65-cpsw-nuss``
+device driver.
+
+Parameters
+==
+
+The ``am65-cpsw-nuss`` driver implements the following driver-specific
+parameters.
+
+.. list-table:: Driver-specific parameters implemented
+ :widths: 5 5 5 85
+
+ * - Name
+ - Type
+ - Mode
+ - Description
+ * - ``switch_mode``
+ - Boolean
+ - runtime
+ - Enable switch mode
diff --git a/Documentation/networking/devlink/index.rst
b/Documentation/networking/devlink/index.rst
index aab79667f97b..8428a1220723 100644
--- a/Documentation/networking/devlink/index.rst
+++ b/Documentation/networking/devlink/index.rst
@@ -45,3 +45,4 @@ parameters, info versions, and other features it supports.
sja1105
qed
ti-cpsw-switch
+ am65-nuss-cpsw-switch
diff --git a/drivers/net/ethernet/ti/Kconfig b/drivers/net/ethernet/ti/Kconfig
index abfc4c435d59..affcf92cd3aa 100644
--- a/drivers/net/ethernet/ti/Kconfig
+++ b/drivers/net/ethernet/ti/Kconfig
@@ -92,6 +92,7 @@ config TI_CPTS
config TI_K3_AM65_CPSW_NUSS
tristate "TI K3 AM654x/J721E CPSW Ethernet driver"
depends on ARCH_K3 && OF && TI_K3_UDMA_GLUE_LAYER
+ select NET_DEVLINK
select TI_DAVINCI_MDIO
imply PHY_TI_GMII_SEL
depends on TI_K3_AM65_CPTS || !TI_K3_AM65_CPTS
@@ -105,6 +106,15 @@ config TI_K3_AM65_CPSW_NUSS
To compile this driver as a module, choose M here: the module
will be called ti-am65-cpsw-nuss.
+config TI_K3_AM65_CPSW_SWITCHDEV
+ bool "TI K3 AM654x/J721E CPSW Switch mode support"
+ depends on TI_K3_AM65_CPSW_NUSS
+ depends on NET_SWITCHDEV
+ help
+This enables switchdev support for TI K3 CPSWxG Ethernet
+Switch. Enable this driver to support hardware switch support for AM65
+CPSW NUSS driver.
+
config TI_K3_AM65_CPTS
tristate "TI K3 AM65x CPTS"
depends on ARCH_K3 && OF
diff --git a/drivers/net/ethernet/ti/am65-cpsw-nuss.c
b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
index b18db3c8207f..75dbd9239061 100644
--- a/drivers/net/ethernet/ti/am65-cpsw-nuss.c
+++ b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
@@ -408,6 +408,11 @@ void am65_cpsw_nuss_set_p0_ptype(struct am65_cpsw_common
*common)
writel(val, host_p->port_base + AM65_CPSW_PORT_REG_PRI_CTL);
}
+static void am65_cpsw_init_host_port_switch(struct am65_cpsw_common *common);
+static void am65_cpsw_init_host_port_emac(struct am65_cpsw_common *common);
+static void am65_cpsw_init_port_switch_ale(struct am65_cpsw_port *port);
+static void am65_cpsw_init_port_emac_ale(struct am65_cpsw_port *port);
+
static int am65_cpsw_nuss_common_open(struct am65_cpsw_common *common,
netdev_features_t features)
{
@@ -454,9 +459,6 @@ static int am65_cpsw_nuss_common_open(struct
am65_cpsw_common *common,
ALE_DEFAULT_THREAD_ID, 0);
cpsw_ale_control_set(common->ale, HOST_PORT_NUM,
ALE_DEFAULT_THREAD_ENABLE, 1);
- if (AM65_CPSW_IS_CPSW2G(common))
- cpsw_ale_control_set(common->ale, HOST_PORT_NUM,
-ALE_PORT_NOLEARN, 1);
/* switch to vlan unaware mode */
[PATCH v2 3/4] net: ti: am65-cpsw-nuss: Add switchdev support
J721e, J7200 and AM64 have multi port switches which can work in multi
mac mode and in switch mode. Add support for configuring this HW in
switch mode using devlink and switchdev notifiers.
Support is similar to existing CPSW switchdev implementation of TI's 32 bit
platform like AM33/AM43/AM57.
To enable switch mode:
devlink dev param set platform/800.ethernet name switch_mode value true
cmode runtime
All configuration is implemented via switchdev API and notifiers.
Supported:
- SWITCHDEV_ATTR_ID_PORT_PRE_BRIDGE_FLAGS
- SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS
- SWITCHDEV_ATTR_ID_PORT_STP_STATE
- SWITCHDEV_OBJ_ID_PORT_VLAN
- SWITCHDEV_OBJ_ID_PORT_MDB
- SWITCHDEV_OBJ_ID_HOST_MDB
Hence AM65 CPSW switchdev driver supports:
- FDB offloading
- MDB offloading
- VLAN filtering and offloading
- STP
Signed-off-by: Vignesh Raghavendra
---
drivers/net/ethernet/ti/Makefile | 1 +
drivers/net/ethernet/ti/am65-cpsw-nuss.c | 20 +-
drivers/net/ethernet/ti/am65-cpsw-switchdev.c | 533 ++
drivers/net/ethernet/ti/am65-cpsw-switchdev.h | 34 ++
4 files changed, 587 insertions(+), 1 deletion(-)
create mode 100644 drivers/net/ethernet/ti/am65-cpsw-switchdev.c
create mode 100644 drivers/net/ethernet/ti/am65-cpsw-switchdev.h
diff --git a/drivers/net/ethernet/ti/Makefile b/drivers/net/ethernet/ti/Makefile
index 6e779292545d..75f761efbea7 100644
--- a/drivers/net/ethernet/ti/Makefile
+++ b/drivers/net/ethernet/ti/Makefile
@@ -26,4 +26,5 @@ keystone_netcp_ethss-y := netcp_ethss.o netcp_sgmii.o
netcp_xgbepcsr.o cpsw_ale.
obj-$(CONFIG_TI_K3_AM65_CPSW_NUSS) += ti-am65-cpsw-nuss.o
ti-am65-cpsw-nuss-y := am65-cpsw-nuss.o cpsw_sl.o am65-cpsw-ethtool.o
cpsw_ale.o k3-cppi-desc-pool.o am65-cpsw-qos.o
+ti-am65-cpsw-nuss-$(CONFIG_TI_K3_AM65_CPSW_SWITCHDEV) += am65-cpsw-switchdev.o
obj-$(CONFIG_TI_K3_AM65_CPTS) += am65-cpts.o
diff --git a/drivers/net/ethernet/ti/am65-cpsw-nuss.c
b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
index d26228395e8d..80f3f4899f21 100644
--- a/drivers/net/ethernet/ti/am65-cpsw-nuss.c
+++ b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
@@ -31,6 +31,7 @@
#include "cpsw_ale.h"
#include "cpsw_sl.h"
#include "am65-cpsw-nuss.h"
+#include "am65-cpsw-switchdev.h"
#include "k3-cppi-desc-pool.h"
#include "am65-cpts.h"
@@ -228,6 +229,9 @@ static int am65_cpsw_nuss_ndo_slave_add_vid(struct
net_device *ndev,
u32 port_mask, unreg_mcast = 0;
int ret;
+ if (!common->is_emac_mode)
+ return 0;
+
if (!netif_running(ndev) || !vid)
return 0;
@@ -255,6 +259,9 @@ static int am65_cpsw_nuss_ndo_slave_kill_vid(struct
net_device *ndev,
struct am65_cpsw_port *port = am65_ndev_to_port(ndev);
int ret;
+ if (!common->is_emac_mode)
+ return 0;
+
if (!netif_running(ndev) || !vid)
return 0;
@@ -277,6 +284,11 @@ static void am65_cpsw_slave_set_promisc(struct
am65_cpsw_port *port,
{
struct am65_cpsw_common *common = port->common;
+ if (promisc && !common->is_emac_mode) {
+ dev_dbg(common->dev, "promisc mode requested in switch mode");
+ return;
+ }
+
if (promisc) {
/* Enable promiscuous mode */
cpsw_ale_control_set(common->ale, port->port_id,
@@ -800,12 +812,13 @@ static int am65_cpsw_nuss_rx_packets(struct
am65_cpsw_common *common,
new_skb = netdev_alloc_skb_ip_align(ndev, AM65_CPSW_MAX_PACKET_SIZE);
if (new_skb) {
+ ndev_priv = netdev_priv(ndev);
+ am65_cpsw_nuss_set_offload_fwd_mark(skb,
ndev_priv->offload_fwd_mark);
skb_put(skb, pkt_len);
skb->protocol = eth_type_trans(skb, ndev);
am65_cpsw_nuss_rx_csum(skb, csum_info);
napi_gro_receive(>napi_rx, skb);
- ndev_priv = netdev_priv(ndev);
stats = this_cpu_ptr(ndev_priv->stats);
u64_stats_update_begin(>syncp);
@@ -2144,6 +2157,10 @@ static int am65_cpsw_register_notifiers(struct
am65_cpsw_common *cpsw)
return ret;
}
+ ret = am65_cpsw_switchdev_register_notifiers(cpsw);
+ if (ret)
+ unregister_netdevice_notifier(>am65_cpsw_netdevice_nb);
+
return ret;
}
@@ -2153,6 +2170,7 @@ static void am65_cpsw_unregister_notifiers(struct
am65_cpsw_common *cpsw)
!IS_REACHABLE(CONFIG_TI_K3_AM65_CPSW_SWITCHDEV))
return;
+ am65_cpsw_switchdev_unregister_notifiers(cpsw);
unregister_netdevice_notifier(>am65_cpsw_netdevice_nb);
}
diff --git a/drivers/net/ethernet/ti/am65-cpsw-switchdev.c
b/drivers/net/ethernet/ti/am65-cpsw-switchdev.c
new file mode 100644
index ..1067e7772dbf
--- /dev/null
+++ b/drivers/net/ethernet/ti/am65-cpsw-switchdev.c
@@ -0,0 +1,533 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/* Texas
[PATCH v2 4/4] docs: networking: ti: Add driver doc for AM65 NUSS switch driver
J721e, J7200 and AM64 have multi port switches which can work in multi
mac mode and in switch mode. Add documentation explaining how to use
different modes.
Borrowed from:
Documentation/networking/device_drivers/ethernet/ti/cpsw_switchdev.rst
Signed-off-by: Vignesh Raghavendra
---
.../device_drivers/ethernet/index.rst | 1 +
.../ethernet/ti/am65_nuss_cpsw_switchdev.rst | 143 ++
2 files changed, 144 insertions(+)
create mode 100644
Documentation/networking/device_drivers/ethernet/ti/am65_nuss_cpsw_switchdev.rst
diff --git a/Documentation/networking/device_drivers/ethernet/index.rst
b/Documentation/networking/device_drivers/ethernet/index.rst
index cbb75a1818c0..6b5dc203da2b 100644
--- a/Documentation/networking/device_drivers/ethernet/index.rst
+++ b/Documentation/networking/device_drivers/ethernet/index.rst
@@ -49,6 +49,7 @@ Contents:
stmicro/stmmac
ti/cpsw
ti/cpsw_switchdev
+ ti/am65_nuss_cpsw_switchdev
ti/tlan
toshiba/spider_net
diff --git
a/Documentation/networking/device_drivers/ethernet/ti/am65_nuss_cpsw_switchdev.rst
b/Documentation/networking/device_drivers/ethernet/ti/am65_nuss_cpsw_switchdev.rst
new file mode 100644
index ..f24adfab6a1b
--- /dev/null
+++
b/Documentation/networking/device_drivers/ethernet/ti/am65_nuss_cpsw_switchdev.rst
@@ -0,0 +1,143 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+===
+Texas Instruments K3 AM65 CPSW NUSS switchdev based ethernet driver
+===
+
+:Version: 1.0
+
+Port renaming
+=
+
+In order to rename via udev::
+
+ip -d link show dev sw0p1 | grep switchid
+
+SUBSYSTEM=="net", ACTION=="add", ATTR{phys_switch_id}==, \
+ ATTR{phys_port_name}!="", NAME="sw0$attr{phys_port_name}"
+
+
+Multi mac mode
+==
+
+- The driver is operating in multi-mac mode by default, thus
+ working as N individual network interfaces.
+
+Devlink configuration parameters
+
+
+See Documentation/networking/devlink/am65-nuss-cpsw-switch.rst
+
+Enabling "switch"
+=
+
+The Switch mode can be enabled by configuring devlink driver parameter
+"switch_mode" to 1/true::
+
+devlink dev param set platform/c00.ethernet \
+name switch_mode value true cmode runtime
+
+This can be done regardless of the state of Port's netdev devices - UP/DOWN,
but
+Port's netdev devices have to be in UP before joining to the bridge to avoid
+overwriting of bridge configuration as CPSW switch driver completely reloads
its
+configuration when first port changes its state to UP.
+
+When the both interfaces joined the bridge - CPSW switch driver will enable
+marking packets with offload_fwd_mark flag.
+
+All configuration is implemented via switchdev API.
+
+Bridge setup
+
+
+::
+
+devlink dev param set platform/c00.ethernet \
+name switch_mode value true cmode runtime
+
+ ip link add name br0 type bridge
+ ip link set dev br0 type bridge ageing_time 1000
+ ip link set dev sw0p1 up
+ ip link set dev sw0p2 up
+ ip link set dev sw0p1 master br0
+ ip link set dev sw0p2 master br0
+
+ [*] bridge vlan add dev br0 vid 1 pvid untagged self
+
+ [*] if vlan_filtering=1. where default_pvid=1
+
+ Note. Steps [*] are mandatory.
+
+
+On/off STP
+==
+
+::
+
+ ip link set dev BRDEV type bridge stp_state 1/0
+
+VLAN configuration
+==
+
+::
+
+ bridge vlan add dev br0 vid 1 pvid untagged self < add cpu port to VLAN 1
+
+Note. This step is mandatory for bridge/default_pvid.
+
+Add extra VLANs
+===
+
+ 1. untagged::
+
+ bridge vlan add dev sw0p1 vid 100 pvid untagged master
+ bridge vlan add dev sw0p2 vid 100 pvid untagged master
+ bridge vlan add dev br0 vid 100 pvid untagged self < Add cpu port
to VLAN100
+
+ 2. tagged::
+
+ bridge vlan add dev sw0p1 vid 100 master
+ bridge vlan add dev sw0p2 vid 100 master
+ bridge vlan add dev br0 vid 100 pvid tagged self < Add cpu port to
VLAN100
+
+FDBs
+
+
+FDBs are automatically added on the appropriate switch port upon detection
+
+Manually adding FDBs::
+
+bridge fdb add aa:bb:cc:dd:ee:ff dev sw0p1 master vlan 100
+bridge fdb add aa:bb:cc:dd:ee:fe dev sw0p2 master < Add on all VLANs
+
+MDBs
+
+
+MDBs are automatically added on the appropriate switch port upon detection
+
+Manually adding MDBs::
+
+ bridge mdb add dev br0 port sw0p1 grp 239.1.1.1 permanent vid 100
+ bridge mdb add dev br0 port sw0p1 grp 239.1.1.1 permanent < Add on all
VLANs
+
+Multicast flooding
+==
+CPU port mcast_flooding is always on
+
+Turning flooding on/off on swithch ports:
+bridge link set dev sw0p1 mcast_flood on/off
+
+Access and Trunk port
+=
+
+::
+
+ bridge vlan add dev sw0p1 vid
[PATCH v2 0/4] net: ti: am65-cpsw-nuss: Add switchdev driver
This series adds switchdev support for AM65 CPSW NUSS driver to support multi port CPSW present on J721e and AM64 SoCs. It adds devlink hook to switch b/w switch mode and multi mac mode. v2: Rebased on latest net-next Update patch 1/4 with rationale for using devlink Vignesh Raghavendra (4): net: ti: am65-cpsw-nuss: Add devlink support net: ti: am65-cpsw-nuss: Add netdevice notifiers net: ti: am65-cpsw-nuss: Add switchdev support docs: networking: ti: Add driver doc for AM65 NUSS switch driver .../device_drivers/ethernet/index.rst | 1 + .../ethernet/ti/am65_nuss_cpsw_switchdev.rst | 143 + .../devlink/am65-nuss-cpsw-switch.rst | 26 + Documentation/networking/devlink/index.rst| 1 + drivers/net/ethernet/ti/Kconfig | 10 + drivers/net/ethernet/ti/Makefile | 1 + drivers/net/ethernet/ti/am65-cpsw-nuss.c | 511 - drivers/net/ethernet/ti/am65-cpsw-nuss.h | 26 + drivers/net/ethernet/ti/am65-cpsw-switchdev.c | 533 ++ drivers/net/ethernet/ti/am65-cpsw-switchdev.h | 34 ++ 10 files changed, 1267 insertions(+), 19 deletions(-) create mode 100644 Documentation/networking/device_drivers/ethernet/ti/am65_nuss_cpsw_switchdev.rst create mode 100644 Documentation/networking/devlink/am65-nuss-cpsw-switch.rst create mode 100644 drivers/net/ethernet/ti/am65-cpsw-switchdev.c create mode 100644 drivers/net/ethernet/ti/am65-cpsw-switchdev.h -- 2.30.0
[PATCH 2/3] dt-bindings: regulator: pca9450: Add sd-vsel GPIO
From: Frieder Schrempf Add the binding documentation for the optional sd-vsel GPIO. Signed-off-by: Frieder Schrempf --- .../devicetree/bindings/regulator/nxp,pca9450-regulator.yaml | 5 + 1 file changed, 5 insertions(+) diff --git a/Documentation/devicetree/bindings/regulator/nxp,pca9450-regulator.yaml b/Documentation/devicetree/bindings/regulator/nxp,pca9450-regulator.yaml index c2b0a8b6da1e..f70f2e758a00 100644 --- a/Documentation/devicetree/bindings/regulator/nxp,pca9450-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/nxp,pca9450-regulator.yaml @@ -87,6 +87,11 @@ properties: additionalProperties: false + sd-vsel-gpios: +description: GPIO that is used to switch LDO5 between being configured by + LDO5CTRL_L or LDO5CTRL_H register. Use this if the SD_VSEL signal is + connected to a host GPIO. + required: - compatible - reg -- 2.25.1
RE: [EXT] Re: [PATCH v13 net-next 04/15] net: mvpp2: always compare hw-version vs MVPP21
> On Thu, Feb 11, 2021 at 12:48:51PM +0200, stef...@marvell.com wrote:
> > @@ -1199,7 +1199,7 @@ static bool mvpp2_port_supports_xlg(struct
> > mvpp2_port *port)
> >
> > static bool mvpp2_port_supports_rgmii(struct mvpp2_port *port) {
> > - return !(port->priv->hw_version == MVPP22 && port->gop_id == 0);
> > + return !(port->priv->hw_version != MVPP21 && port->gop_id == 0);
>
> I'm still very much of the opinion (as raised several revisions back) that
> using
> > MVPP21 or >= MVPP22 would be a lot better - especially when we have
> situations like this. Having negatives within negatives does not help
> readability.
Ok, I would update in next series.
Thanks,
Stefan
Re: [PATCH] staging: rtl8723bs: fix function comments to follow kernel-doc
On Thu, Feb 11, 2021 at 12:40:15AM +0530, karthik alapati wrote: > fix checkpatch.pl warning for "block comments should align the > * on each line" and make function comments follow kernel-doc > > Signed-off-by: karthik alapati > --- > .../staging/rtl8723bs/hal/rtl8723b_phycfg.c | 185 +++--- > 1 file changed, 73 insertions(+), 112 deletions(-) > > diff --git a/drivers/staging/rtl8723bs/hal/rtl8723b_phycfg.c > b/drivers/staging/rtl8723bs/hal/rtl8723b_phycfg.c > index cf23414d7..1fd504181 100644 > --- a/drivers/staging/rtl8723bs/hal/rtl8723b_phycfg.c > +++ b/drivers/staging/rtl8723bs/hal/rtl8723b_phycfg.c > @@ -20,16 +20,11 @@ > #define MAX_DOZE_WAITING_TIMES_9x 64 > > /** > -* Function: phy_CalculateBitShift > -* > -* OverView: Get shifted position of the BitMask > -* > -* Input: > -*u32 BitMask, > -* > -* Output:none > -* Return:u32 Return the shift bit bit position of the mask > -*/ > + * phy_CalculateBitShift - Get shifted position of the BitMask. > + * @BitMask: Bitmask. > + * > + * Return: Return the shift bit position of the mask > + */ Why indent these comments by a tab? A single space is fine. thanks, greg k-h
Re: [PATCH -next] staging: ks7010: Macros with complex values
On Thu, Feb 11, 2021 at 01:57:04PM +0300, Fatih YILDIRIM wrote:
> On Thu, Feb 11, 2021 at 11:02:51AM +0100, Greg KH wrote:
> > On Thu, Feb 11, 2021 at 12:22:39PM +0300, Fatih Yildirim wrote:
> > > Fix for checkpatch.pl warning:
> > > Macros with complex values should be enclosed in parentheses.
> > >
> > > Signed-off-by: Fatih Yildirim
> > > ---
> > > drivers/staging/ks7010/ks_hostif.h | 24
> > > 1 file changed, 12 insertions(+), 12 deletions(-)
> > >
> > > diff --git a/drivers/staging/ks7010/ks_hostif.h
> > > b/drivers/staging/ks7010/ks_hostif.h
> > > index 39138191a556..c62a494ed6bb 100644
> > > --- a/drivers/staging/ks7010/ks_hostif.h
> > > +++ b/drivers/staging/ks7010/ks_hostif.h
> > > @@ -498,20 +498,20 @@ struct hostif_mic_failure_request {
> > > #define TX_RATE_FIXED5
> > >
> > > /* 11b rate */
> > > -#define TX_RATE_1M (u8)(10 / 5)/* 11b 11g basic rate */
> > > -#define TX_RATE_2M (u8)(20 / 5)/* 11b 11g basic rate */
> > > -#define TX_RATE_5M (u8)(55 / 5)/* 11g basic rate */
> > > -#define TX_RATE_11M (u8)(110 / 5) /* 11g basic rate */
> > > +#define TX_RATE_1M ((u8)(10 / 5)) /* 11b 11g basic rate */
> > > +#define TX_RATE_2M ((u8)(20 / 5)) /* 11b 11g basic rate */
> > > +#define TX_RATE_5M ((u8)(55 / 5)) /* 11g basic rate */
> > > +#define TX_RATE_11M ((u8)(110 / 5)) /* 11g basic rate */
> >
> > But these are not "complex macros" that need an extra () added to them,
> > right?
> >
> > Checkpatch is a hint, it's not a code parser and can not always know
> > what is happening. With your knowledge of C, does this look like
> > something that needs to be "fixed"?
> >
> > thanks,
> >
> > greg k-h
>
> Hi Greg,
>
> Thanks for your reply.
> Actually, I'm following the Eudyptula Challenge and I'm at task 10.
First rule of that challenge is that you are not allowed to talk about
it in public :)
That being said, you didn't answer any of my questions above :(
greg k-h
linux-next: Tree for Feb 11
Hi all, Changes since 20210210: The powerpc tree still had its build failure in the allyesconfig for which I applied a supplied patch. The v4l-dvb tree lost its build failure. The drm-misc tree lost its build failure. The modules tree lost its build failure. The device-mapper tree gained a build failure so I used the version from next-20210210. The tip tree lost its boot failure. The rcu tree gained conflicts against the block tree. The driver-core tree lost its build failure. The akpm-current tree gained conflicts against the fscache tree. Non-merge commits (relative to Linus' tree): 9533 9470 files changed, 385794 insertions(+), 266880 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig and htmldocs. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 333 trees (counting Linus' and 87 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (291009f656e8 Merge tag 'pm-5.11-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm) Merging fixes/fixes (e71ba9452f0b Linux 5.11-rc2) Merging kbuild-current/fixes (efe6e3068067 kallsyms: fix nonconverging kallsyms table with lld) Merging arc-current/for-curr (7c53f6b671f4 Linux 5.11-rc3) Merging arm-current/fixes (4d62e81b60d4 ARM: kexec: fix oops after TLB are invalidated) Merging arm64-fixes/for-next/fixes (22cd5edb2d9c arm64: Use simpler arithmetics for the linear map macros) Merging arm-soc-fixes/arm/fixes (090e502e4e63 Merge tag 'socfpga_dts_fix_for_v5.12' of git://git.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux into arm/fixes) Merging drivers-memory-fixes/fixes (5c8fe583cce5 Linux 5.11-rc1) Merging m68k-current/for-linus (2ae92e8b9b7e MAINTAINERS: Update m68k Mac entry) Merging powerpc-fixes/fixes (8c511eff1827 powerpc/kuap: Allow kernel thread to access userspace after kthread_use_mm) Merging s390-fixes/fixes (92bf22614b21 Linux 5.11-rc7) Merging sparc/master (0a95a6d1a4cd sparc: use for_each_child_of_node() macro) Merging fscrypt-current/for-stable (d19d8d345eec fscrypt: fix inline encryption not used on new files) Merging net/master (291009f656e8 Merge tag 'pm-5.11-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm) Merging bpf/master (b8776f14a470 Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf) Merging ipsec/master (da64ae2d35d3 xfrm: Fix wraparound in xfrm_policy_addr_delta()) Merging netfilter/master (450bbc339518 Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf) Merging ipvs/master (44a674d6f798 Merge tag 'mlx5-fixes-2021-01-26' of git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux) Merging wireless-drivers/master (93a1d4791c10 mt76: dma: fix a possible memory leak in mt76_add_fragment()) Merging mac80211/master (b3d2c7b876d4 Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf) Merging rdma-fixes/for-rc (1048ba83fb1c Linux 5.11-rc6) Merging sound-current/for-linus (4841b8e6318a ALSA: hda/realtek: modify EAPD in the ALC886) Merging sound-asoc-fixes/for-linus (3dbacbd3c18f Merge remote-tracking branch 'asoc/for-5.11' into asoc-linus) Merging regmap-fixes/for-linus (19c329f68089 Linux 5.11-rc4) Merging regulator-fixes/for-linus (1b6c3cc3b388 Merge remote-tracking branch 'regulator/for-5.11' into regulator-linus) Merging spi-fixes/for-linus (6c96bb2c369c Merge remote-tracking branch 'spi/for-5.11' into
Re: [PATCH v17 07/10] mm: introduce memfd_secret system call to create "secret" memory areas
On Thu, Feb 11, 2021 at 10:01:32AM +0100, David Hildenbrand wrote: > On 11.02.21 09:39, Michal Hocko wrote: > > On Thu 11-02-21 09:13:19, Mike Rapoport wrote: > > > On Tue, Feb 09, 2021 at 02:17:11PM +0100, Michal Hocko wrote: > > > > On Tue 09-02-21 11:09:38, Mike Rapoport wrote: > > [...] > > > > > Citing my older email: > > > > > > > > > > I've hesitated whether to continue to use new flags to > > > > > memfd_create() or to > > > > > add a new system call and I've decided to use a new system call > > > > > after I've > > > > > started to look into man pages update. There would have been two > > > > > completely > > > > > independent descriptions and I think it would have been very > > > > > confusing. > > > > > > > > Could you elaborate? Unmapping from the kernel address space can work > > > > both for sealed or hugetlb memfds, no? Those features are completely > > > > orthogonal AFAICS. With a dedicated syscall you will need to introduce > > > > this functionality on top if that is required. Have you considered that? > > > > I mean hugetlb pages are used to back guest memory very often. Is this > > > > something that will be a secret memory usecase? > > > > > > > > Please be really specific when giving arguments to back a new syscall > > > > decision. > > > > > > Isn't "syscalls have completely independent description" specific enough? > > > > No, it's not as you can see from questions I've had above. More on that > > below. > > > > > We are talking about API here, not the implementation details whether > > > secretmem supports large pages or not. > > > > > > The purpose of memfd_create() is to create a file-like access to memory. > > > The purpose of memfd_secret() is to create a way to access memory hidden > > > from the kernel. > > > > > > I don't think overloading memfd_create() with the secretmem flags because > > > they happen to return a file descriptor will be better for users, but > > > rather will be more confusing. > > > > This is quite a subjective conclusion. I could very well argue that it > > would be much better to have a single syscall to get a fd backed memory > > with spedific requirements (sealing, unmapping from the kernel address > > space). Neither of us would be clearly right or wrong. A more important > > point is a future extensibility and usability, though. So let's just > > think of few usecases I have outlined above. Is it unrealistic to expect > > that secret memory should be sealable? What about hugetlb? Because if > > the answer is no then a new API is a clear win as the combination of > > flags would never work and then we would just suffer from the syscall > > multiplexing without much gain. On the other hand if combination of the > > functionality is to be expected then you will have to jam it into > > memfd_create and copy the interface likely causing more confusion. See > > what I mean? > > > > I by no means do not insist one way or the other but from what I have > > seen so far I have a feeling that the interface hasn't been thought > > through enough. Sure you have landed with fd based approach and that > > seems fair. But how to get that fd seems to still have some gaps IMHO. > > > > I agree with Michal. This has been raised by different > people already, including on LWN (https://lwn.net/Articles/835342/). > > I can follow Mike's reasoning (man page), and I am also fine if there is > a valid reason. However, IMHO the basic description seems to match quite good: > >memfd_create() creates an anonymous file and returns a file descriptor > that refers to it. The >file behaves like a regular file, and so can be modified, truncated, > memory-mapped, and so on. >However, unlike a regular file, it lives in RAM and has a volatile > backing storage. Once all >references to the file are dropped, it is automatically released. > Anonymous memory is used >for all backing pages of the file. Therefore, files created by > memfd_create() have the same >semantics as other anonymous memory allocations such as those > allocated using mmap(2) with the >MAP_ANONYMOUS flag. Even despite my laziness and huge amount of copy-paste you can spot the differences (this is a very old version, update is due): memfd_secret() creates an anonymous file and returns a file descriptor that refers to it. The file can only be memory-mapped; the memory in such mapping will have stronger protection than usual memory mapped files, and so it can be used to store application secrets. Unlike a regular file, a file created with memfd_secret() lives in RAM and has a volatile backing storage. Once all references to the file are dropped, it is automatically released. The initial size of the file is set to 0. Following the call, the file size should be set using ftruncate(2). The memory areas obtained with mmap(2) from the
Re: [PATCH] ARM: zynq: Update Copyright date in DTS
On Mon, Feb 1, 2021 at 3:28 PM Michal Simek wrote: > > Update years in header to be up2date. > > Signed-off-by: Michal Simek I saw this in your pull request, and I did not think this was how copyrights work. >From what I can tell, most of the files have not been touched in years, so it's surprising that the copyright would include every year up to 2021. Would you mind respinning the pull request either without this patch, or with a clarified patch description that explains what you do and a Signed-off-by from one of your company's lawyers if they asked you for it? Arnd
Re: possible deadlock in start_this_handle (2)
On Thu, Feb 11, 2021 at 12:22 PM Dmitry Vyukov wrote:
>
> On Thu, Feb 11, 2021 at 11:49 AM Jan Kara wrote:
> >
> > Hello,
> >
> > added mm guys to CC.
> >
> > On Wed 10-02-21 05:35:18, syzbot wrote:
> > > HEAD commit:1e0d27fc Merge branch 'akpm' (patches from Andrew)
> > > git tree: upstream
> > > console output: https://syzkaller.appspot.com/x/log.txt?x=15cbce90d0
> > > kernel config: https://syzkaller.appspot.com/x/.config?x=bd1f72220b2e57eb
> > > dashboard link:
> > > https://syzkaller.appspot.com/bug?extid=bfdded10ab7dcd7507ae
> > > userspace arch: i386
> > >
> > > Unfortunately, I don't have any reproducer for this issue yet.
> > >
> > > IMPORTANT: if you fix the issue, please add the following tag to the
> > > commit:
> > > Reported-by: syzbot+bfdded10ab7dcd750...@syzkaller.appspotmail.com
> > >
> > > ==
> > > WARNING: possible circular locking dependency detected
> > > 5.11.0-rc6-syzkaller #0 Not tainted
> > > --
> > > kswapd0/2246 is trying to acquire lock:
> > > 888041a988e0 (jbd2_handle){}-{0:0}, at:
> > > start_this_handle+0xf81/0x1380 fs/jbd2/transaction.c:444
> > >
> > > but task is already holding lock:
> > > 8be892c0 (fs_reclaim){+.+.}-{0:0}, at:
> > > __fs_reclaim_acquire+0x0/0x30 mm/page_alloc.c:5195
> > >
> > > which lock already depends on the new lock.
> > >
> > > the existing dependency chain (in reverse order) is:
> > >
> > > -> #2 (fs_reclaim){+.+.}-{0:0}:
> > >__fs_reclaim_acquire mm/page_alloc.c:4326 [inline]
> > >fs_reclaim_acquire+0x117/0x150 mm/page_alloc.c:4340
> > >might_alloc include/linux/sched/mm.h:193 [inline]
> > >slab_pre_alloc_hook mm/slab.h:493 [inline]
> > >slab_alloc_node mm/slub.c:2817 [inline]
> > >__kmalloc_node+0x5f/0x430 mm/slub.c:4015
> > >kmalloc_node include/linux/slab.h:575 [inline]
> > >kvmalloc_node+0x61/0xf0 mm/util.c:587
> > >kvmalloc include/linux/mm.h:781 [inline]
> > >ext4_xattr_inode_cache_find fs/ext4/xattr.c:1465 [inline]
> > >ext4_xattr_inode_lookup_create fs/ext4/xattr.c:1508 [inline]
> > >ext4_xattr_set_entry+0x1ce6/0x3780 fs/ext4/xattr.c:1649
> > >ext4_xattr_ibody_set+0x78/0x2b0 fs/ext4/xattr.c:2224
> > >ext4_xattr_set_handle+0x8f4/0x13e0 fs/ext4/xattr.c:2380
> > >ext4_xattr_set+0x13a/0x340 fs/ext4/xattr.c:2493
> > >ext4_xattr_user_set+0xbc/0x100 fs/ext4/xattr_user.c:40
> > >__vfs_setxattr+0x10e/0x170 fs/xattr.c:177
> > >__vfs_setxattr_noperm+0x11a/0x4c0 fs/xattr.c:208
> > >__vfs_setxattr_locked+0x1bf/0x250 fs/xattr.c:266
> > >vfs_setxattr+0x135/0x320 fs/xattr.c:291
> > >setxattr+0x1ff/0x290 fs/xattr.c:553
> > >path_setxattr+0x170/0x190 fs/xattr.c:572
> > >__do_sys_setxattr fs/xattr.c:587 [inline]
> > >__se_sys_setxattr fs/xattr.c:583 [inline]
> > >__ia32_sys_setxattr+0xbc/0x150 fs/xattr.c:583
> > >do_syscall_32_irqs_on arch/x86/entry/common.c:77 [inline]
> > >__do_fast_syscall_32+0x56/0x80 arch/x86/entry/common.c:139
> > >do_fast_syscall_32+0x2f/0x70 arch/x86/entry/common.c:164
> > >entry_SYSENTER_compat_after_hwframe+0x4d/0x5c
> >
> > This stacktrace should never happen. ext4_xattr_set() starts a transaction.
> > That internally goes through start_this_handle() which calls:
> >
> > handle->saved_alloc_context = memalloc_nofs_save();
> >
> > and we restore the allocation context only in stop_this_handle() when
> > stopping the handle. And with this fs_reclaim_acquire() should remove
> > __GFP_FS from the mask and not call __fs_reclaim_acquire().
> >
> > Now I have no idea why something here didn't work out. Given we don't have
> > a reproducer it will be probably difficult to debug this. I'd note that
> > about year and half ago similar report happened (got autoclosed) so it may
> > be something real somewhere but it may also be just some HW glitch or
> > something like that.
>
> HW glitch is theoretically possible. But if we are considering such
> causes, I would say a kernel memory corruption is way more likely, we
> have hundreds of known memory-corruption-capable bugs open. In most
> cases they are caught by KASAN before doing silent damage. But KASAN
> can miss some cases.
>
> I see at least 4 existing bugs with similar stack:
> https://syzkaller.appspot.com/bug?extid=bfdded10ab7dcd7507ae
> https://syzkaller.appspot.com/bug?extid=a7ab8df042baaf42ae3c
> https://syzkaller.appspot.com/bug?id=c814a55a728493959328551c769ede4c8ff72aab
> https://syzkaller.appspot.com/bug?id=426ad9adca053dafcd698f3a48ad5406dccc972b
>
> All in all, I would not assume it's a memory corruption. When we had
> bugs that actually caused silent memory corruption, that caused a
> spike of random one-time crashes all over the kernel. This does not
> look like it.
I wonder if memalloc_nofs_save
Re: [PATCH v5 3/6] misc: Add Synopsys DesignWare xData IP driver to Kconfig
Hi Gustavo, [...] > +config DW_XDATA_PCIE > + depends on PCI > + tristate "Synopsys DesignWare xData PCIe driver" > + help > + This driver allows controlling Synopsys DesignWare PCIe traffic > + generator IP also known as xData, present in Synopsys Designware > + PCIe Endpoint prototype. [...] To be consistent. It would be "DesignWare" in the sentence above. Krzysztof
Re: [RFC PATCH v4 03/17] af_vsock: separate receive data loop
On Sun, Feb 07, 2021 at 06:15:05PM +0300, Arseny Krasnov wrote:
This moves STREAM specific data receive logic to dedicated function:
'__vsock_stream_recvmsg()', while checks that will be same for both
types of socket are in shared function: 'vsock_connectible_recvmsg()'.
Signed-off-by: Arseny Krasnov
---
net/vmw_vsock/af_vsock.c | 117 +++
1 file changed, 68 insertions(+), 49 deletions(-)
diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c
index 38927695786f..66c8a932f49b 100644
--- a/net/vmw_vsock/af_vsock.c
+++ b/net/vmw_vsock/af_vsock.c
@@ -1898,65 +1898,22 @@ static int vsock_wait_data(struct sock *sk, struct
wait_queue_entry *wait,
return err;
}
-static int
-vsock_connectible_recvmsg(struct socket *sock, struct msghdr *msg, size_t len,
- int flags)
+static int __vsock_stream_recvmsg(struct sock *sk, struct msghdr *msg,
+ size_t len, int flags)
{
- struct sock *sk;
- struct vsock_sock *vsk;
+ struct vsock_transport_recv_notify_data recv_data;
const struct vsock_transport *transport;
- int err;
- size_t target;
+ struct vsock_sock *vsk;
ssize_t copied;
+ size_t target;
long timeout;
- struct vsock_transport_recv_notify_data recv_data;
+ int err;
DEFINE_WAIT(wait);
- sk = sock->sk;
vsk = vsock_sk(sk);
- err = 0;
-
- lock_sock(sk);
-
transport = vsk->transport;
- if (!transport || sk->sk_state != TCP_ESTABLISHED) {
- /* Recvmsg is supposed to return 0 if a peer performs an
-* orderly shutdown. Differentiate between that case and when a
-* peer has not connected or a local shutdown occured with the
-* SOCK_DONE flag.
-*/
- if (sock_flag(sk, SOCK_DONE))
- err = 0;
- else
- err = -ENOTCONN;
-
- goto out;
- }
-
- if (flags & MSG_OOB) {
- err = -EOPNOTSUPP;
- goto out;
- }
-
- /* We don't check peer_shutdown flag here since peer may actually shut
-* down, but there can be data in the queue that a local socket can
-* receive.
-*/
- if (sk->sk_shutdown & RCV_SHUTDOWN) {
- err = 0;
- goto out;
- }
-
- /* It is valid on Linux to pass in a zero-length receive buffer. This
-* is not an error. We may as well bail out now.
-*/
- if (!len) {
- err = 0;
- goto out;
- }
-
/* We must not copy less than target bytes into the user's buffer
* before returning successfully, so we wait for the consume queue to
* have that much data to consume before dequeueing. Note that this
At the end of __vsock_stream_recvmsg() you are calling release_sock(sk)
and it's wrong since we are releasing it in vsock_connectible_recvmsg().
Please fix it.
@@ -2020,6 +1977,68 @@ vsock_connectible_recvmsg(struct socket *sock,
struct msghdr *msg, size_t len,
return err;
}
+static int
+vsock_connectible_recvmsg(struct socket *sock, struct msghdr *msg, size_t len,
+ int flags)
+{
+ struct sock *sk;
+ struct vsock_sock *vsk;
+ const struct vsock_transport *transport;
+ int err;
+
+ DEFINE_WAIT(wait);
+
+ sk = sock->sk;
+ vsk = vsock_sk(sk);
+ err = 0;
+
+ lock_sock(sk);
+
+ transport = vsk->transport;
+
+ if (!transport || sk->sk_state != TCP_ESTABLISHED) {
+ /* Recvmsg is supposed to return 0 if a peer performs an
+* orderly shutdown. Differentiate between that case and when a
+* peer has not connected or a local shutdown occurred with the
+* SOCK_DONE flag.
+*/
+ if (sock_flag(sk, SOCK_DONE))
+ err = 0;
+ else
+ err = -ENOTCONN;
+
+ goto out;
+ }
+
+ if (flags & MSG_OOB) {
+ err = -EOPNOTSUPP;
+ goto out;
+ }
+
+ /* We don't check peer_shutdown flag here since peer may actually shut
+* down, but there can be data in the queue that a local socket can
+* receive.
+*/
+ if (sk->sk_shutdown & RCV_SHUTDOWN) {
+ err = 0;
+ goto out;
+ }
+
+ /* It is valid on Linux to pass in a zero-length receive buffer. This
+* is not an error. We may as well bail out now.
+*/
+ if (!len) {
+ err = 0;
+ goto out;
+ }
+
+ err = __vsock_stream_recvmsg(sk, msg, len, flags);
+
+out:
+ release_sock(sk);
+ return err;
+}
+
The rest of the patch LGTM.
Stefano
Re: RFC: oftree based setup of composite board devices
On Thu, Feb 11, 2021 at 1:15 PM Enrico Weigelt, metux IT consult wrote: > On 10.02.21 11:30, Andy Shevchenko wrote: > >> Use cases are boards with non-oftree firmware (ACPI, etc) where certain > >> platform devices can't be directly enumerated via firmware. Traditionally > >> we had to write board specific drivers that check for board identification > >> (DMI strings, etc), then initialize the actual devices and their links > >> (eg. gpio<->leds/buttons, ...). Often this can be expressed just by DT. > > > > In ACPI we support DT compatible strings, and we support overlays for > > a long time. Would it work for you? > > please tell me more, how ACPI and DT can already work together ? It's all in documentation. https://www.kernel.org/doc/html/latest/firmware-guide/acpi/enumeration.html#device-tree-namespace-link-device-id https://www.kernel.org/doc/html/latest/admin-guide/acpi/ssdt-overlays.html Please, please, read documentation beforehand! > You already know my apu board driver - that's my first example usecase. Sorry, but I forgot about it. Can you summarize what is your use case that really needs so intrusive and hard work? > There're few things I don't know how to solve w/ overlays: > > * match rules shall be inside the DTS > * future match rules shall also check for bios versions etc > * adding new boards shall be possible by just adding another DTS to >the tree (not a whole module) > * supporting several board variants (w/ small differences) by one DTS > * sometimes existing devices (eg. enumerated by acpi) need to be kicked >out (buggy firmware, ...) > * can't rely on any special userland tweaks Show an example why either of the above is needed in your case and tell what is the exact issue. > >> The approach can be easily be extended to other kinds of composite devices, > >> eg. PCI cards or USB dongles. > > > > What do you mean? PCI and USB are self-enumerated. What's wrong with them? > > In general yes, but of course you need drivers for them. Sometimes those > devices are composites of other devices, wired up in some special way. > Traditionally, we'd need to write a special driver that just don't do > much more than instantiating other drivers. Yes, that driver represents hardware. MFD already has some support for composite devices. We have the auxiliary bus for some other interesting cases, etc. Depending on the hardware in question you have to choose a proper bus and locking (access synchronisation) schema. > Those things could be expressed via DTS, so we don't need to write > individual drivers anymore. It seems you are trying to create something like "universal quirk". Brave idea, but from my experience a fiasco is what will be out of it. The hardware has a lot of different issues and levels of issues and it is close to impossible to describe everything possible and predict the future... Good luck! ... > * need to split the information into several places (instead of having >all in one DTS) > * need to have one separate module board, or merge the dmi tables. Have no idea what you are talking about here, sorry. > My goal is having everything that describes a board into one DTS > (source) file. I'm confused, you are talking about non-DT platforms in the cover-letter and now you are talking about DTS. AFAIK DTS allows you to put everything in one source. -- With Best Regards, Andy Shevchenko
Re: [PATCH 00/49] Add Alder Lake support for perf
On Mon, Feb 08, 2021 at 07:24:57AM -0800, kan.li...@linux.intel.com wrote: SNIP > Jin Yao (24): > perf jevents: Support unit value "cpu_core" and "cpu_atom" > perf util: Save pmu name to struct perf_pmu_alias > perf pmu: Save detected hybrid pmus to a global pmu list > perf pmu: Add hybrid helper functions > perf list: Support --cputype option to list hybrid pmu events > perf stat: Hybrid evsel uses its own cpus > perf header: Support HYBRID_TOPOLOGY feature > perf header: Support hybrid CPU_PMU_CAPS > tools headers uapi: Update tools's copy of linux/perf_event.h > perf parse-events: Create two hybrid hardware events > perf parse-events: Create two hybrid cache events > perf parse-events: Support hardware events inside PMU > perf list: Display pmu prefix for partially supported hybrid cache > events > perf parse-events: Support hybrid raw events > perf stat: Support --cputype option for hybrid events > perf stat: Support metrics with hybrid events > perf evlist: Create two hybrid 'cycles' events by default > perf stat: Add default hybrid events > perf stat: Uniquify hybrid event name > perf stat: Merge event counts from all hybrid PMUs > perf stat: Filter out unmatched aggregation for hybrid event > perf evlist: Warn as events from different hybrid PMUs in a group > perf Documentation: Document intel-hybrid support > perf evsel: Adjust hybrid event and global event mixed group > > Kan Liang (22): > perf/x86/intel: Hybrid PMU support for perf capabilities > perf/x86: Hybrid PMU support for intel_ctrl > perf/x86: Hybrid PMU support for counters > perf/x86: Hybrid PMU support for unconstrained > perf/x86: Hybrid PMU support for hardware cache event > perf/x86: Hybrid PMU support for event constraints > perf/x86: Hybrid PMU support for extra_regs > perf/x86/intel: Factor out intel_pmu_check_num_counters > perf/x86/intel: Factor out intel_pmu_check_event_constraints > perf/x86/intel: Factor out intel_pmu_check_extra_regs > perf/x86: Expose check_hw_exists > perf/x86: Remove temporary pmu assignment in event_init > perf/x86: Factor out x86_pmu_show_pmu_cap > perf/x86: Register hybrid PMUs > perf/x86: Add structures for the attributes of Hybrid PMUs > perf/x86/intel: Add attr_update for Hybrid PMUs > perf/x86: Support filter_match callback > perf/x86/intel: Add Alder Lake Hybrid support > perf: Introduce PERF_TYPE_HARDWARE_PMU and PERF_TYPE_HW_CACHE_PMU > perf/x86/intel/uncore: Add Alder Lake support > perf/x86/msr: Add Alder Lake CPU support > perf/x86/cstate: Add Alder Lake CPU support > > Ricardo Neri (2): > x86/cpufeatures: Enumerate Intel Hybrid Technology feature bit > x86/cpu: Describe hybrid CPUs in cpuinfo_x86 > > Zhang Rui (1): > perf/x86/rapl: Add support for Intel Alder Lake hi, would you have git branch with all this somewhere? thanks, jirka
Re: [PATCH v13 net-next 05/15] net: mvpp2: add PPv23 version definition
On Thu, Feb 11, 2021 at 12:48:52PM +0200, stef...@marvell.com wrote:
> From: Stefan Chulski
>
> This patch add PPv23 version definition.
> PPv23 is new packet processor in CP115.
> Everything that supported by PPv22, also supported by PPv23.
> No functional changes in this stage.
>
> Signed-off-by: Stefan Chulski
> Acked-by: Marcin Wojtas
Reviewed-by: Russell King
> @@ -7049,6 +7049,11 @@ static int mvpp2_probe(struct platform_device *pdev)
> priv->port_map |= BIT(i);
> }
>
> + if (priv->hw_version != MVPP21) {
> + if (mvpp2_read(priv, MVPP2_VER_ID_REG) == MVPP2_VER_PP23)
> + priv->hw_version = MVPP23;
> + }
> +
The only minor comment I have on this is... the formatting of the
above. Wouldn't:
if (priv->hw_version >= MVPP22 &&
mvpp2_read(priv, MVPP2_VER_ID_REG) == MVPP2_VER_PP23)
priv->hw_version = MVPP23;
read better?
Do we need to even check priv->hw_version here? Isn't this register
implemented in PPv2.1 where it contains the value zero?
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
RE: [EXT] Re: [PATCH v13 net-next 05/15] net: mvpp2: add PPv23 version definition
> --
> On Thu, Feb 11, 2021 at 12:48:52PM +0200, stef...@marvell.com wrote:
> > From: Stefan Chulski
> >
> > This patch add PPv23 version definition.
> > PPv23 is new packet processor in CP115.
> > Everything that supported by PPv22, also supported by PPv23.
> > No functional changes in this stage.
> >
> > Signed-off-by: Stefan Chulski
> > Acked-by: Marcin Wojtas
>
> Reviewed-by: Russell King
>
> > @@ -7049,6 +7049,11 @@ static int mvpp2_probe(struct platform_device
> *pdev)
> > priv->port_map |= BIT(i);
> > }
> >
> > + if (priv->hw_version != MVPP21) {
> > + if (mvpp2_read(priv, MVPP2_VER_ID_REG) ==
> MVPP2_VER_PP23)
> > + priv->hw_version = MVPP23;
> > + }
> > +
>
> The only minor comment I have on this is... the formatting of the above.
> Wouldn't:
>
> if (priv->hw_version >= MVPP22 &&
> mvpp2_read(priv, MVPP2_VER_ID_REG) == MVPP2_VER_PP23)
> priv->hw_version = MVPP23;
>
> read better?
>
> Do we need to even check priv->hw_version here? Isn't this register
> implemented in PPv2.1 where it contains the value zero?
Yes, we can just:
if (mvpp2_read(priv, MVPP2_VER_ID_REG) == MVPP2_VER_PP23)
priv->hw_version = MVPP23;
Thanks,
Stefan.
Re: possible deadlock in fs_reclaim_acquire (2)
On Thu, Feb 11, 2021 at 11:50:38AM +0100, 'Michal Hocko' via syzkaller-bugs
wrote:
> On Thu 11-02-21 11:22:25, Jan Kara wrote:
> > On Thu 11-02-21 12:07:29, Hillf Danton wrote:
>
> I haven't received Hillf's email.
>
> [...]
> > > Fix 71b565ceff37 ("ext4: drop ext4_kvmalloc()") by restoring the
> > > GFP_NOFS introduced in dec214d00e0d ("ext4: xattr inode deduplication").
> > >
> > > Note this may be the fix also to possible deadlock
> > > Reported-by: syzbot+bfdded10ab7dcd750...@syzkaller.appspotmail.com
> > >
> > > https://lore.kernel.org/linux-ext4/563a0205bafb7...@google.com/
> >
> > Please no. Ext4 is using scoping API to limit allocations to GFP_NOFS
> > inside transactions. In this case something didn't work which seems like a
> > lockdep bug at the first sight but I'll talk to mm guys about it.
> > Definitely to problem doesn't seem to be in ext4.
>
> Agreed. kvmalloc(NOFS) is not even supported because vmalloc doesn't
> support GFP_KERNEL incompatible requests.
Okay. I have created a new Smatch warning when people pass GFP_NOFS
to kvmalloc() and friends. We'll see if it finds anything tomorrow.
(We could probably find the same information with grep, but I run
Smatch every day so it prevents future bugs).
regards,
dan carpenter
[PATCH 4/4] arm64: dts: imx8mq: Use reset driver for VPU hardware block
Add a vpu reset hardware block node.
Signed-off-by: Benjamin Gaignard
---
arch/arm64/boot/dts/freescale/imx8mq.dtsi | 31 ++-
1 file changed, 25 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
index a841a023e8e0..7d4863d47112 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
@@ -7,6 +7,7 @@
#include
#include
#include
+#include
#include
#include "dt-bindings/input/input.h"
#include
@@ -1267,19 +1268,36 @@ usb3_phy1: usb-phy@382f0040 {
status = "disabled";
};
+ vpu_reset: vpu-reset@3832 {
+ compatible = "fsl,imx8mq-vpu-reset", "syscon";
+ reg = <0x3832 0x1>;
+ clocks = < IMX8MQ_CLK_VPU_G1_ROOT>,
+< IMX8MQ_CLK_VPU_G2_ROOT>,
+< IMX8MQ_CLK_VPU_DEC_ROOT>;
+ assigned-clocks = < IMX8MQ_CLK_VPU_G1>,
+ < IMX8MQ_CLK_VPU_G2>,
+ < IMX8MQ_CLK_VPU_BUS>,
+ < IMX8MQ_VPU_PLL_BYPASS>;
+ assigned-clock-parents = < IMX8MQ_VPU_PLL_OUT>,
+< IMX8MQ_VPU_PLL_OUT>,
+< IMX8MQ_SYS1_PLL_800M>,
+< IMX8MQ_VPU_PLL>;
+ assigned-clock-rates = <6>, <6>,
+ <8>, <0>;
+ #reset-cells = <1>;
+ };
+
vpu: video-codec@3830 {
compatible = "nxp,imx8mq-vpu";
reg = <0x3830 0x1>,
- <0x3831 0x1>,
- <0x3832 0x1>;
- reg-names = "g1", "g2", "ctrl";
+ <0x3831 0x1>;
+ reg-names = "g1", "g2";
interrupts = ,
;
interrupt-names = "g1", "g2";
clocks = < IMX8MQ_CLK_VPU_G1_ROOT>,
-< IMX8MQ_CLK_VPU_G2_ROOT>,
-< IMX8MQ_CLK_VPU_DEC_ROOT>;
- clock-names = "g1", "g2", "bus";
+< IMX8MQ_CLK_VPU_G2_ROOT>;
+ clock-names = "g1", "g2";
assigned-clocks = < IMX8MQ_CLK_VPU_G1>,
< IMX8MQ_CLK_VPU_G2>,
< IMX8MQ_CLK_VPU_BUS>,
@@ -1290,6 +1308,7 @@ vpu: video-codec@3830 {
< IMX8MQ_VPU_PLL>;
assigned-clock-rates = <6>, <6>,
<8>, <0>;
+ resets = <_reset IMX8MQ_RESET_VPU_RESET_G1>;
power-domains = <_vpu>;
};
--
2.25.1
Re: [PATCH v2 6/8] cxl/mem: Enable commands via CEL
On Tue, 9 Feb 2021 16:02:57 -0800
Ben Widawsky wrote:
> CXL devices identified by the memory-device class code must implement
> the Device Command Interface (described in 8.2.9 of the CXL 2.0 spec).
> While the driver already maintains a list of commands it supports, there
> is still a need to be able to distinguish between commands that the
> driver knows about from commands that are optionally supported by the
> hardware.
>
> The Command Effects Log (CEL) is specified in the CXL 2.0 specification.
> The CEL is one of two types of logs, the other being vendor specific.
I'd say "vendor specific debug" just so that no one thinks it has anything
to do with the rest of this description (which mentioned vendor specific
commands).
> They are distinguished in hardware/spec via UUID. The CEL is useful for
> 2 things:
> 1. Determine which optional commands are supported by the CXL device.
> 2. Enumerate any vendor specific commands
>
> The CEL is used by the driver to determine which commands are available
> in the hardware and therefore which commands userspace is allowed to
> execute. The set of enabled commands might be a subset of commands which
> are advertised in UAPI via CXL_MEM_SEND_COMMAND IOCTL.
>
> The implementation leaves the statically defined table of commands and
> supplements it with a bitmap to determine commands that are enabled.
> This organization was chosen for the following reasons:
> - Smaller memory footprint. Doesn't need a table per device.
> - Reduce memory allocation complexity.
> - Fixed command IDs to opcode mapping for all devices makes development
> and debugging easier.
> - Certain helpers are easily achievable, like cxl_for_each_cmd().
>
> Signed-off-by: Ben Widawsky
> Reviewed-by: Dan Williams
> ---
> drivers/cxl/cxl.h| 2 +
> drivers/cxl/mem.c| 216 +++
> include/uapi/linux/cxl_mem.h | 1 +
> 3 files changed, 219 insertions(+)
>
> diff --git a/drivers/cxl/cxl.h b/drivers/cxl/cxl.h
> index b3c56fa6e126..9a5e595abfa4 100644
> --- a/drivers/cxl/cxl.h
> +++ b/drivers/cxl/cxl.h
> @@ -68,6 +68,7 @@ struct cxl_memdev;
> *(CXL 2.0 8.2.8.4.3 Mailbox Capabilities Register)
> * @mbox_mutex: Mutex to synchronize mailbox access.
> * @firmware_version: Firmware version for the memory device.
> + * @enabled_commands: Hardware commands found enabled in CEL.
> * @pmem: Persistent memory capacity information.
> * @ram: Volatile memory capacity information.
> */
> @@ -83,6 +84,7 @@ struct cxl_mem {
> size_t payload_size;
> struct mutex mbox_mutex; /* Protects device mailbox and firmware */
> char firmware_version[0x10];
> + unsigned long *enabled_cmds;
>
> struct {
> struct range range;
> diff --git a/drivers/cxl/mem.c b/drivers/cxl/mem.c
> index 6d766a994dce..e9aa6ca18d99 100644
> --- a/drivers/cxl/mem.c
> +++ b/drivers/cxl/mem.c
> @@ -45,6 +45,8 @@ enum opcode {
> CXL_MBOX_OP_INVALID = 0x,
> CXL_MBOX_OP_RAW = CXL_MBOX_OP_INVALID,
> CXL_MBOX_OP_ACTIVATE_FW = 0x0202,
> + CXL_MBOX_OP_GET_SUPPORTED_LOGS = 0x0400,
> + CXL_MBOX_OP_GET_LOG = 0x0401,
> CXL_MBOX_OP_IDENTIFY= 0x4000,
> CXL_MBOX_OP_SET_PARTITION_INFO = 0x4101,
> CXL_MBOX_OP_SET_LSA = 0x4103,
> @@ -103,6 +105,19 @@ static DEFINE_IDA(cxl_memdev_ida);
> static struct dentry *cxl_debugfs;
> static bool raw_allow_all;
>
> +enum {
> + CEL_UUID,
> + VENDOR_DEBUG_UUID
Who wants to take a bet this will get extended at somepoint in the future?
Add a trailing comma to make that less noisy.
They would never have used a UUID if this wasn't expected to expand.
CXL spec calls out that "The following Log Identifier UUIDs are defined in
_this_
specification" rather implying other specs may well define more.
Fun for the future!
> +};
> +
> +/* See CXL 2.0 Table 170. Get Log Input Payload */
> +static const uuid_t log_uuid[] = {
> + [CEL_UUID] = UUID_INIT(0xda9c0b5, 0xbf41, 0x4b78, 0x8f, 0x79, 0x96,
> +0xb1, 0x62, 0x3b, 0x3f, 0x17),
> + [VENDOR_DEBUG_UUID] = UUID_INIT(0xe1819d9, 0x11a9, 0x400c, 0x81, 0x1f,
> + 0xd6, 0x07, 0x19, 0x40, 0x3d, 0x86)
likewise on trailing comma
> +};
> +
> /**
> * struct cxl_mem_command - Driver representation of a memory device command
> * @info: Command information as it exists for the UAPI
> @@ -111,6 +126,8 @@ static bool raw_allow_all;
> *
> * * %CXL_CMD_FLAG_MANDATORY: Hardware must support this command. This flag
> is
> *only used internally by the driver for sanity checking.
> + * * %CXL_CMD_INTERNAL_FLAG_PSEUDO: This is a pseudo command which doesn't
> have
> + *a direct mapping to hardware. They are implicitly always enabled.
Stale comment?
> *
> * The cxl_mem_command is the driver's internal representation of commands
> that
> * are
Re: possible deadlock in start_this_handle (2)
On Thu 11-02-21 12:28:48, Dmitry Vyukov wrote:
> On Thu, Feb 11, 2021 at 12:22 PM Dmitry Vyukov wrote:
> >
> > On Thu, Feb 11, 2021 at 11:49 AM Jan Kara wrote:
> > >
> > > Hello,
> > >
> > > added mm guys to CC.
> > >
> > > On Wed 10-02-21 05:35:18, syzbot wrote:
> > > > HEAD commit:1e0d27fc Merge branch 'akpm' (patches from Andrew)
> > > > git tree: upstream
> > > > console output: https://syzkaller.appspot.com/x/log.txt?x=15cbce90d0
> > > > kernel config:
> > > > https://syzkaller.appspot.com/x/.config?x=bd1f72220b2e57eb
> > > > dashboard link:
> > > > https://syzkaller.appspot.com/bug?extid=bfdded10ab7dcd7507ae
> > > > userspace arch: i386
> > > >
> > > > Unfortunately, I don't have any reproducer for this issue yet.
> > > >
> > > > IMPORTANT: if you fix the issue, please add the following tag to the
> > > > commit:
> > > > Reported-by: syzbot+bfdded10ab7dcd750...@syzkaller.appspotmail.com
> > > >
> > > > ==
> > > > WARNING: possible circular locking dependency detected
> > > > 5.11.0-rc6-syzkaller #0 Not tainted
> > > > --
> > > > kswapd0/2246 is trying to acquire lock:
> > > > 888041a988e0 (jbd2_handle){}-{0:0}, at:
> > > > start_this_handle+0xf81/0x1380 fs/jbd2/transaction.c:444
> > > >
> > > > but task is already holding lock:
> > > > 8be892c0 (fs_reclaim){+.+.}-{0:0}, at:
> > > > __fs_reclaim_acquire+0x0/0x30 mm/page_alloc.c:5195
> > > >
> > > > which lock already depends on the new lock.
> > > >
> > > > the existing dependency chain (in reverse order) is:
> > > >
> > > > -> #2 (fs_reclaim){+.+.}-{0:0}:
> > > >__fs_reclaim_acquire mm/page_alloc.c:4326 [inline]
> > > >fs_reclaim_acquire+0x117/0x150 mm/page_alloc.c:4340
> > > >might_alloc include/linux/sched/mm.h:193 [inline]
> > > >slab_pre_alloc_hook mm/slab.h:493 [inline]
> > > >slab_alloc_node mm/slub.c:2817 [inline]
> > > >__kmalloc_node+0x5f/0x430 mm/slub.c:4015
> > > >kmalloc_node include/linux/slab.h:575 [inline]
> > > >kvmalloc_node+0x61/0xf0 mm/util.c:587
> > > >kvmalloc include/linux/mm.h:781 [inline]
> > > >ext4_xattr_inode_cache_find fs/ext4/xattr.c:1465 [inline]
> > > >ext4_xattr_inode_lookup_create fs/ext4/xattr.c:1508 [inline]
> > > >ext4_xattr_set_entry+0x1ce6/0x3780 fs/ext4/xattr.c:1649
> > > >ext4_xattr_ibody_set+0x78/0x2b0 fs/ext4/xattr.c:2224
> > > >ext4_xattr_set_handle+0x8f4/0x13e0 fs/ext4/xattr.c:2380
> > > >ext4_xattr_set+0x13a/0x340 fs/ext4/xattr.c:2493
> > > >ext4_xattr_user_set+0xbc/0x100 fs/ext4/xattr_user.c:40
> > > >__vfs_setxattr+0x10e/0x170 fs/xattr.c:177
> > > >__vfs_setxattr_noperm+0x11a/0x4c0 fs/xattr.c:208
> > > >__vfs_setxattr_locked+0x1bf/0x250 fs/xattr.c:266
> > > >vfs_setxattr+0x135/0x320 fs/xattr.c:291
> > > >setxattr+0x1ff/0x290 fs/xattr.c:553
> > > >path_setxattr+0x170/0x190 fs/xattr.c:572
> > > >__do_sys_setxattr fs/xattr.c:587 [inline]
> > > >__se_sys_setxattr fs/xattr.c:583 [inline]
> > > >__ia32_sys_setxattr+0xbc/0x150 fs/xattr.c:583
> > > >do_syscall_32_irqs_on arch/x86/entry/common.c:77 [inline]
> > > >__do_fast_syscall_32+0x56/0x80 arch/x86/entry/common.c:139
> > > >do_fast_syscall_32+0x2f/0x70 arch/x86/entry/common.c:164
> > > >entry_SYSENTER_compat_after_hwframe+0x4d/0x5c
> > >
> > > This stacktrace should never happen. ext4_xattr_set() starts a
> > > transaction.
> > > That internally goes through start_this_handle() which calls:
> > >
> > > handle->saved_alloc_context = memalloc_nofs_save();
> > >
> > > and we restore the allocation context only in stop_this_handle() when
> > > stopping the handle. And with this fs_reclaim_acquire() should remove
> > > __GFP_FS from the mask and not call __fs_reclaim_acquire().
> > >
> > > Now I have no idea why something here didn't work out. Given we don't have
> > > a reproducer it will be probably difficult to debug this. I'd note that
> > > about year and half ago similar report happened (got autoclosed) so it may
> > > be something real somewhere but it may also be just some HW glitch or
> > > something like that.
> >
> > HW glitch is theoretically possible. But if we are considering such
> > causes, I would say a kernel memory corruption is way more likely, we
> > have hundreds of known memory-corruption-capable bugs open. In most
> > cases they are caught by KASAN before doing silent damage. But KASAN
> > can miss some cases.
> >
> > I see at least 4 existing bugs with similar stack:
> > https://syzkaller.appspot.com/bug?extid=bfdded10ab7dcd7507ae
> > https://syzkaller.appspot.com/bug?extid=a7ab8df042baaf42ae3c
> > https://syzkaller.appspot.com/bug?id=c814a55a728493959328551c769ede4c8ff72aab
> > https://syzkaller.appspot.com/bug?id=426ad9adca053dafcd698f3a48ad5406dccc972b
> >
>
[PATCH v5] kvfree_rcu: Release page cache under memory pressure
From: Zqiang
Add free per-cpu existing krcp's page cache operation in shrink callback
function, and also during shrink period, simple delay schedule fill page
work, to avoid refill page while free krcp page cache.
Signed-off-by: Zqiang
Co-developed-by: Uladzislau Rezki (Sony)
---
v1->v4:
During the test a page shrinker is pretty active, because of low memory
condition. callback drains it whereas kvfree_rcu() part refill it right
away making kind of vicious circle.
Through Vlad Rezki suggestion, to avoid this, schedule a periodic delayed
work with HZ, and it's easy to do that.
v4->v5:
change commit message and use xchg replace WRITE_ONCE()
kernel/rcu/tree.c | 49 +++
1 file changed, 41 insertions(+), 8 deletions(-)
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index c1ae1e52f638..f1fba23f5036 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -3139,7 +3139,7 @@ struct kfree_rcu_cpu {
bool initialized;
int count;
- struct work_struct page_cache_work;
+ struct delayed_work page_cache_work;
atomic_t work_in_progress;
struct hrtimer hrtimer;
@@ -3395,7 +3395,7 @@ schedule_page_work_fn(struct hrtimer *t)
struct kfree_rcu_cpu *krcp =
container_of(t, struct kfree_rcu_cpu, hrtimer);
- queue_work(system_highpri_wq, >page_cache_work);
+ queue_delayed_work(system_highpri_wq, >page_cache_work, 0);
return HRTIMER_NORESTART;
}
@@ -3404,7 +3404,7 @@ static void fill_page_cache_func(struct work_struct *work)
struct kvfree_rcu_bulk_data *bnode;
struct kfree_rcu_cpu *krcp =
container_of(work, struct kfree_rcu_cpu,
- page_cache_work);
+ page_cache_work.work);
unsigned long flags;
bool pushed;
int i;
@@ -3428,15 +3428,21 @@ static void fill_page_cache_func(struct work_struct
*work)
atomic_set(>work_in_progress, 0);
}
+static atomic_t backoff_page_cache_fill = ATOMIC_INIT(0);
+
static void
run_page_cache_worker(struct kfree_rcu_cpu *krcp)
{
if (rcu_scheduler_active == RCU_SCHEDULER_RUNNING &&
!atomic_xchg(>work_in_progress, 1)) {
- hrtimer_init(>hrtimer, CLOCK_MONOTONIC,
- HRTIMER_MODE_REL);
- krcp->hrtimer.function = schedule_page_work_fn;
- hrtimer_start(>hrtimer, 0, HRTIMER_MODE_REL);
+ if (atomic_xchg(_page_cache_fill, 0)) {
+ queue_delayed_work(system_highpri_wq,
>page_cache_work, HZ);
+ } else {
+ hrtimer_init(>hrtimer, CLOCK_MONOTONIC,
+ HRTIMER_MODE_REL);
+ krcp->hrtimer.function = schedule_page_work_fn;
+ hrtimer_start(>hrtimer, 0, HRTIMER_MODE_REL);
+ }
}
}
@@ -3571,19 +3577,44 @@ void kvfree_call_rcu(struct rcu_head *head,
rcu_callback_t func)
}
EXPORT_SYMBOL_GPL(kvfree_call_rcu);
+static int free_krc_page_cache(struct kfree_rcu_cpu *krcp)
+{
+ unsigned long flags;
+ struct llist_node *page_list, *pos, *n;
+ int freed = 0;
+
+ raw_spin_lock_irqsave(>lock, flags);
+ page_list = llist_del_all(>bkvcache);
+ krcp->nr_bkv_objs = 0;
+ raw_spin_unlock_irqrestore(>lock, flags);
+
+ llist_for_each_safe(pos, n, page_list) {
+ free_page((unsigned long)pos);
+ freed++;
+ }
+
+ return freed;
+}
+
static unsigned long
kfree_rcu_shrink_count(struct shrinker *shrink, struct shrink_control *sc)
{
int cpu;
unsigned long count = 0;
+ unsigned long flags;
/* Snapshot count of all CPUs */
for_each_possible_cpu(cpu) {
struct kfree_rcu_cpu *krcp = per_cpu_ptr(, cpu);
count += READ_ONCE(krcp->count);
+
+ raw_spin_lock_irqsave(>lock, flags);
+ count += krcp->nr_bkv_objs;
+ raw_spin_unlock_irqrestore(>lock, flags);
}
+ atomic_set(_page_cache_fill, 1);
return count;
}
@@ -3598,6 +3629,8 @@ kfree_rcu_shrink_scan(struct shrinker *shrink, struct
shrink_control *sc)
struct kfree_rcu_cpu *krcp = per_cpu_ptr(, cpu);
count = krcp->count;
+ count += free_krc_page_cache(krcp);
+
raw_spin_lock_irqsave(>lock, flags);
if (krcp->monitor_todo)
kfree_rcu_drain_unlock(krcp, flags);
@@ -4574,7 +4607,7 @@ static void __init kfree_rcu_batch_init(void)
}
INIT_DELAYED_WORK(>monitor_work, kfree_rcu_monitor);
- INIT_WORK(>page_cache_work, fill_page_cache_func);
+ INIT_DELAYED_WORK(>page_cache_work, fill_page_cache_func);
krcp->initialized = true;
}
if (register_shrinker(_rcu_shrinker))
--
[PATCH v2 1/8] xen/events: reset affinity of 2-level event when tearing it down
When creating a new event channel with 2-level events the affinity
needs to be reset initially in order to avoid using an old affinity
from earlier usage of the event channel port. So when tearing an event
channel down reset all affinity bits.
The same applies to the affinity when onlining a vcpu: all old
affinity settings for this vcpu must be reset. As percpu events get
initialized before the percpu event channel hook is called,
resetting of the affinities happens after offlining a vcpu (this is
working, as initial percpu memory is zeroed out).
Cc: sta...@vger.kernel.org
Reported-by: Julien Grall
Signed-off-by: Juergen Gross
---
V2:
- reset affinity when tearing down the event (Julien Grall)
---
drivers/xen/events/events_2l.c | 15 +++
drivers/xen/events/events_base.c | 1 +
drivers/xen/events/events_internal.h | 8
3 files changed, 24 insertions(+)
diff --git a/drivers/xen/events/events_2l.c b/drivers/xen/events/events_2l.c
index da87f3a1e351..a7f413c5c190 100644
--- a/drivers/xen/events/events_2l.c
+++ b/drivers/xen/events/events_2l.c
@@ -47,6 +47,11 @@ static unsigned evtchn_2l_max_channels(void)
return EVTCHN_2L_NR_CHANNELS;
}
+static void evtchn_2l_remove(evtchn_port_t evtchn, unsigned int cpu)
+{
+ clear_bit(evtchn, BM(per_cpu(cpu_evtchn_mask, cpu)));
+}
+
static void evtchn_2l_bind_to_cpu(evtchn_port_t evtchn, unsigned int cpu,
unsigned int old_cpu)
{
@@ -355,9 +360,18 @@ static void evtchn_2l_resume(void)
EVTCHN_2L_NR_CHANNELS/BITS_PER_EVTCHN_WORD);
}
+static int evtchn_2l_percpu_deinit(unsigned int cpu)
+{
+ memset(per_cpu(cpu_evtchn_mask, cpu), 0, sizeof(xen_ulong_t) *
+ EVTCHN_2L_NR_CHANNELS/BITS_PER_EVTCHN_WORD);
+
+ return 0;
+}
+
static const struct evtchn_ops evtchn_ops_2l = {
.max_channels = evtchn_2l_max_channels,
.nr_channels = evtchn_2l_max_channels,
+ .remove= evtchn_2l_remove,
.bind_to_cpu = evtchn_2l_bind_to_cpu,
.clear_pending = evtchn_2l_clear_pending,
.set_pending = evtchn_2l_set_pending,
@@ -367,6 +381,7 @@ static const struct evtchn_ops evtchn_ops_2l = {
.unmask= evtchn_2l_unmask,
.handle_events = evtchn_2l_handle_events,
.resume= evtchn_2l_resume,
+ .percpu_deinit = evtchn_2l_percpu_deinit,
};
void __init xen_evtchn_2l_init(void)
diff --git a/drivers/xen/events/events_base.c b/drivers/xen/events/events_base.c
index e850f79351cb..6c539db81f8f 100644
--- a/drivers/xen/events/events_base.c
+++ b/drivers/xen/events/events_base.c
@@ -368,6 +368,7 @@ static int xen_irq_info_pirq_setup(unsigned irq,
static void xen_irq_info_cleanup(struct irq_info *info)
{
set_evtchn_to_irq(info->evtchn, -1);
+ xen_evtchn_port_remove(info->evtchn, info->cpu);
info->evtchn = 0;
channels_on_cpu_dec(info);
}
diff --git a/drivers/xen/events/events_internal.h
b/drivers/xen/events/events_internal.h
index 0a97c0549db7..18a4090d0709 100644
--- a/drivers/xen/events/events_internal.h
+++ b/drivers/xen/events/events_internal.h
@@ -14,6 +14,7 @@ struct evtchn_ops {
unsigned (*nr_channels)(void);
int (*setup)(evtchn_port_t port);
+ void (*remove)(evtchn_port_t port, unsigned int cpu);
void (*bind_to_cpu)(evtchn_port_t evtchn, unsigned int cpu,
unsigned int old_cpu);
@@ -54,6 +55,13 @@ static inline int xen_evtchn_port_setup(evtchn_port_t evtchn)
return 0;
}
+static inline void xen_evtchn_port_remove(evtchn_port_t evtchn,
+ unsigned int cpu)
+{
+ if (evtchn_ops->remove)
+ evtchn_ops->remove(evtchn, cpu);
+}
+
static inline void xen_evtchn_port_bind_to_cpu(evtchn_port_t evtchn,
unsigned int cpu,
unsigned int old_cpu)
--
2.26.2
[PATCH v2 5/8] xen/events: link interdomain events to associated xenbus device
In order to support the possibility of per-device event channel
settings (e.g. lateeoi spurious event thresholds) add a xenbus device
pointer to struct irq_info() and modify the related event channel
binding interfaces to take the pointer to the xenbus device as a
parameter instead of the domain id of the other side.
While at it remove the stale prototype of bind_evtchn_to_irq_lateeoi().
Signed-off-by: Juergen Gross
Reviewed-by: Boris Ostrovsky
Reviewed-by: Wei Liu
---
drivers/block/xen-blkback/xenbus.c | 2 +-
drivers/net/xen-netback/interface.c | 16 +--
drivers/xen/events/events_base.c| 41 +
drivers/xen/pvcalls-back.c | 4 +--
drivers/xen/xen-pciback/xenbus.c| 2 +-
drivers/xen/xen-scsiback.c | 2 +-
include/xen/events.h| 7 ++---
7 files changed, 41 insertions(+), 33 deletions(-)
diff --git a/drivers/block/xen-blkback/xenbus.c
b/drivers/block/xen-blkback/xenbus.c
index 9860d4842f36..c2aaf690352c 100644
--- a/drivers/block/xen-blkback/xenbus.c
+++ b/drivers/block/xen-blkback/xenbus.c
@@ -245,7 +245,7 @@ static int xen_blkif_map(struct xen_blkif_ring *ring,
grant_ref_t *gref,
if (req_prod - rsp_prod > size)
goto fail;
- err = bind_interdomain_evtchn_to_irqhandler_lateeoi(blkif->domid,
+ err = bind_interdomain_evtchn_to_irqhandler_lateeoi(blkif->be->dev,
evtchn, xen_blkif_be_int, 0, "blkif-backend", ring);
if (err < 0)
goto fail;
diff --git a/drivers/net/xen-netback/interface.c
b/drivers/net/xen-netback/interface.c
index e02a4fbb74de..50a94e58c150 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -630,13 +630,13 @@ int xenvif_connect_ctrl(struct xenvif *vif, grant_ref_t
ring_ref,
unsigned int evtchn)
{
struct net_device *dev = vif->dev;
+ struct xenbus_device *xendev = xenvif_to_xenbus_device(vif);
void *addr;
struct xen_netif_ctrl_sring *shared;
RING_IDX rsp_prod, req_prod;
int err;
- err = xenbus_map_ring_valloc(xenvif_to_xenbus_device(vif),
-_ref, 1, );
+ err = xenbus_map_ring_valloc(xendev, _ref, 1, );
if (err)
goto err;
@@ -650,7 +650,7 @@ int xenvif_connect_ctrl(struct xenvif *vif, grant_ref_t
ring_ref,
if (req_prod - rsp_prod > RING_SIZE(>ctrl))
goto err_unmap;
- err = bind_interdomain_evtchn_to_irq_lateeoi(vif->domid, evtchn);
+ err = bind_interdomain_evtchn_to_irq_lateeoi(xendev, evtchn);
if (err < 0)
goto err_unmap;
@@ -673,8 +673,7 @@ int xenvif_connect_ctrl(struct xenvif *vif, grant_ref_t
ring_ref,
vif->ctrl_irq = 0;
err_unmap:
- xenbus_unmap_ring_vfree(xenvif_to_xenbus_device(vif),
- vif->ctrl.sring);
+ xenbus_unmap_ring_vfree(xendev, vif->ctrl.sring);
vif->ctrl.sring = NULL;
err:
@@ -719,6 +718,7 @@ int xenvif_connect_data(struct xenvif_queue *queue,
unsigned int tx_evtchn,
unsigned int rx_evtchn)
{
+ struct xenbus_device *dev = xenvif_to_xenbus_device(queue->vif);
struct task_struct *task;
int err;
@@ -755,7 +755,7 @@ int xenvif_connect_data(struct xenvif_queue *queue,
if (tx_evtchn == rx_evtchn) {
/* feature-split-event-channels == 0 */
err = bind_interdomain_evtchn_to_irqhandler_lateeoi(
- queue->vif->domid, tx_evtchn, xenvif_interrupt, 0,
+ dev, tx_evtchn, xenvif_interrupt, 0,
queue->name, queue);
if (err < 0)
goto err;
@@ -766,7 +766,7 @@ int xenvif_connect_data(struct xenvif_queue *queue,
snprintf(queue->tx_irq_name, sizeof(queue->tx_irq_name),
"%s-tx", queue->name);
err = bind_interdomain_evtchn_to_irqhandler_lateeoi(
- queue->vif->domid, tx_evtchn, xenvif_tx_interrupt, 0,
+ dev, tx_evtchn, xenvif_tx_interrupt, 0,
queue->tx_irq_name, queue);
if (err < 0)
goto err;
@@ -776,7 +776,7 @@ int xenvif_connect_data(struct xenvif_queue *queue,
snprintf(queue->rx_irq_name, sizeof(queue->rx_irq_name),
"%s-rx", queue->name);
err = bind_interdomain_evtchn_to_irqhandler_lateeoi(
- queue->vif->domid, rx_evtchn, xenvif_rx_interrupt, 0,
+ dev, rx_evtchn, xenvif_rx_interrupt, 0,
queue->rx_irq_name, queue);
if (err < 0)
goto err;
diff --git a/drivers/xen/events/events_base.c b/drivers/xen/events/events_base.c
index f7e22330dcef..a5cce4c626c2 100644
---
Re: [PATCH v2 3/8] cxl/mem: Register CXL memX devices
On Wed, 10 Feb 2021 18:17:25 +
Jonathan Cameron wrote:
> On Tue, 9 Feb 2021 16:02:54 -0800
> Ben Widawsky wrote:
>
> > From: Dan Williams
> >
> > Create the /sys/bus/cxl hierarchy to enumerate:
> >
> > * Memory Devices (per-endpoint control devices)
> >
> > * Memory Address Space Devices (platform address ranges with
> > interleaving, performance, and persistence attributes)
> >
> > * Memory Regions (active provisioned memory from an address space device
> > that is in use as System RAM or delegated to libnvdimm as Persistent
> > Memory regions).
> >
> > For now, only the per-endpoint control devices are registered on the
> > 'cxl' bus. However, going forward it will provide a mechanism to
> > coordinate cross-device interleave.
> >
> > Signed-off-by: Dan Williams
> > Signed-off-by: Ben Widawsky
>
> One stray header, and a request for a tiny bit of reordering to
> make it easier to chase through creation and destruction.
>
> Either way with the header move to earlier patch I'm fine with this one.
>
> Reviewed-by: Jonathan Cameron
Actually thinking more on this, what is the justification for the
complexity + overhead of a percpu_refcount vs a refcount
I don't think this is a high enough performance path for it to matter.
Perhaps I'm missing a usecase where it does?
Jonathan
>
> > ---
> > Documentation/ABI/testing/sysfs-bus-cxl | 26 ++
> > .../driver-api/cxl/memory-devices.rst | 17 +
> > drivers/cxl/Makefile | 3 +
> > drivers/cxl/bus.c | 29 ++
> > drivers/cxl/cxl.h | 4 +
> > drivers/cxl/mem.c | 301 +-
> > 6 files changed, 378 insertions(+), 2 deletions(-)
> > create mode 100644 Documentation/ABI/testing/sysfs-bus-cxl
> > create mode 100644 drivers/cxl/bus.c
> >
>
>
> > diff --git a/drivers/cxl/cxl.h b/drivers/cxl/cxl.h
> > index 745f5e0bfce3..b3c56fa6e126 100644
> > --- a/drivers/cxl/cxl.h
> > +++ b/drivers/cxl/cxl.h
> > @@ -3,6 +3,7 @@
> >
> > #ifndef __CXL_H__
> > #define __CXL_H__
> > +#include
>
> Why is this coming in now? Feels like it should have been in earlier
> patch that started using struct range
>
> >
> > #include
> > #include
> > @@ -55,6 +56,7 @@
> > (FIELD_GET(CXLMDEV_RESET_NEEDED_MASK, status) != \
> > CXLMDEV_RESET_NEEDED_NOT)
> >
> > +struct cxl_memdev;
> > /**
> > * struct cxl_mem - A CXL memory device
> > * @pdev: The PCI device associated with this CXL device.
> > @@ -72,6 +74,7 @@
> > struct cxl_mem {
> > struct pci_dev *pdev;
> > void __iomem *regs;
> > + struct cxl_memdev *cxlmd;
> >
> > void __iomem *status_regs;
> > void __iomem *mbox_regs;
> > @@ -90,4 +93,5 @@ struct cxl_mem {
> > } ram;
> > };
> >
> > +extern struct bus_type cxl_bus_type;
> > #endif /* __CXL_H__ */
> > diff --git a/drivers/cxl/mem.c b/drivers/cxl/mem.c
> > index 0a868a15badc..8bbd2495e237 100644
> > --- a/drivers/cxl/mem.c
> > +++ b/drivers/cxl/mem.c
> > @@ -1,11 +1,36 @@
> >
>
> > +
> > +static void cxl_memdev_release(struct device *dev)
> > +{
> > + struct cxl_memdev *cxlmd = to_cxl_memdev(dev);
> > +
> > + percpu_ref_exit(>ops_active);
> > + ida_free(_memdev_ida, cxlmd->id);
> > + kfree(cxlmd);
> > +}
> > +
> ...
>
> > +static int cxl_mem_add_memdev(struct cxl_mem *cxlm)
> > +{
> > + struct pci_dev *pdev = cxlm->pdev;
> > + struct cxl_memdev *cxlmd;
> > + struct device *dev;
> > + struct cdev *cdev;
> > + int rc;
> > +
> > + cxlmd = kzalloc(sizeof(*cxlmd), GFP_KERNEL);
> > + if (!cxlmd)
> > + return -ENOMEM;
> > + init_completion(>ops_dead);
> > +
> > + /*
> > +* @cxlm is deallocated when the driver unbinds so operations
> > +* that are using it need to hold a live reference.
> > +*/
> > + cxlmd->cxlm = cxlm;
> > + rc = percpu_ref_init(>ops_active, cxlmdev_ops_active_release, 0,
> > +GFP_KERNEL);
> > + if (rc)
> > + goto err_ref;
> > +
> > + rc = ida_alloc_range(_memdev_ida, 0, CXL_MEM_MAX_DEVS, GFP_KERNEL);
> > + if (rc < 0)
> > + goto err_id;
> > + cxlmd->id = rc;
> > +
> > + dev = >dev;
> > + device_initialize(dev);
> > + dev->parent = >dev;
> > + dev->bus = _bus_type;
> > + dev->devt = MKDEV(cxl_mem_major, cxlmd->id);
> > + dev->type = _memdev_type;
> > + dev_set_name(dev, "mem%d", cxlmd->id);
> > +
> > + cdev = >cdev;
> > + cdev_init(cdev, _memdev_fops);
> > +
> > + rc = cdev_device_add(cdev, dev);
> > + if (rc)
> > + goto err_add;
> > +
> > + return devm_add_action_or_reset(dev->parent, cxlmdev_unregister,
> > cxlmd);
>
> This had me scratching my head. The cxlmdev_unregister() if called normally
> or in the _or_reset() results in
>
> percpu_ref_kill(>ops_active);
> cdev_device_del(>cdev, dev);
> wait_for_completion(>ops_dead);
> cxlmd->cxlm = NULL;
>
[PATCH v2 6/8] xen/events: add per-xenbus device event statistics and settings
Add syfs nodes for each xenbus device showing event statistics (number
of events and spurious events, number of associated event channels)
and for setting a spurious event threshold in case a frontend is
sending too many events without being rogue on purpose.
Signed-off-by: Juergen Gross
---
V2:
- add documentation (Boris Ostrovsky)
---
.../ABI/testing/sysfs-devices-xenbus | 41
drivers/xen/events/events_base.c | 27 +++-
drivers/xen/xenbus/xenbus_probe.c | 66 +++
include/xen/xenbus.h | 7 ++
4 files changed, 139 insertions(+), 2 deletions(-)
create mode 100644 Documentation/ABI/testing/sysfs-devices-xenbus
diff --git a/Documentation/ABI/testing/sysfs-devices-xenbus
b/Documentation/ABI/testing/sysfs-devices-xenbus
new file mode 100644
index ..fd796cb4f315
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-devices-xenbus
@@ -0,0 +1,41 @@
+What: /sys/devices/*/xenbus/event_channels
+Date: February 2021
+Contact: Xen Developers mailing list
+Description:
+ Number of Xen event channels associated with a kernel based
+ paravirtualized device frontend or backend.
+
+What: /sys/devices/*/xenbus/events
+Date: February 2021
+Contact: Xen Developers mailing list
+Description:
+ Total number of Xen events received for a Xen pv device
+ frontend or backend.
+
+What: /sys/devices/*/xenbus/jiffies_eoi_delayed
+Date: February 2021
+Contact: Xen Developers mailing list
+Description:
+ Summed up time in jiffies the EOI of an interrupt for a Xen
+ pv device has been delayed in order to avoid stalls due to
+ event storms. This value rising is a first sign for a rogue
+ other end of the pv device.
+
+What: /sys/devices/*/xenbus/spurious_events
+Date: February 2021
+Contact: Xen Developers mailing list
+Description:
+ Number of events received for a Xen pv device which did not
+ require any action. Too many spurious events in a row will
+ trigger delayed EOI processing.
+
+What: /sys/devices/*/xenbus/spurious_threshold
+Date: February 2021
+Contact: Xen Developers mailing list
+Description:
+ Controls the tolerated number of subsequent spurious events
+ before delayed EOI processing is triggered for a Xen pv
+ device. Default is 1. This can be modified in case the other
+ end of the pv device is issuing spurious events on a regular
+ basis and is known not to be malicious on purpose. Raising
+ the value for such cases can improve pv device performance.
diff --git a/drivers/xen/events/events_base.c b/drivers/xen/events/events_base.c
index a5cce4c626c2..48210c1e62e3 100644
--- a/drivers/xen/events/events_base.c
+++ b/drivers/xen/events/events_base.c
@@ -332,6 +332,8 @@ static int xen_irq_info_evtchn_setup(unsigned irq,
ret = xen_irq_info_common_setup(info, irq, IRQT_EVTCHN, evtchn, 0);
info->u.interdomain = dev;
+ if (dev)
+ atomic_inc(>event_channels);
return ret;
}
@@ -606,18 +608,28 @@ static void xen_irq_lateeoi_locked(struct irq_info *info,
bool spurious)
return;
if (spurious) {
+ struct xenbus_device *dev = info->u.interdomain;
+ unsigned int threshold = 1;
+
+ if (dev && dev->spurious_threshold)
+ threshold = dev->spurious_threshold;
+
if ((1 << info->spurious_cnt) < (HZ << 2)) {
if (info->spurious_cnt != 0xFF)
info->spurious_cnt++;
}
- if (info->spurious_cnt > 1) {
- delay = 1 << (info->spurious_cnt - 2);
+ if (info->spurious_cnt > threshold) {
+ delay = 1 << (info->spurious_cnt - 1 - threshold);
if (delay > HZ)
delay = HZ;
if (!info->eoi_time)
info->eoi_cpu = smp_processor_id();
info->eoi_time = get_jiffies_64() + delay;
+ if (dev)
+ atomic_add(delay, >jiffies_eoi_delayed);
}
+ if (dev)
+ atomic_inc(>spurious_events);
} else {
info->spurious_cnt = 0;
}
@@ -950,6 +962,7 @@ static void __unbind_from_irq(unsigned int irq)
if (VALID_EVTCHN(evtchn)) {
unsigned int cpu = cpu_from_irq(irq);
+ struct xenbus_device *dev;
xen_evtchn_close(evtchn);
@@ -960,6 +973,11 @@ static void __unbind_from_irq(unsigned int irq)
case
[PATCH v2 8/8] xen/evtchn: use READ/WRITE_ONCE() for accessing ring indices
For avoiding read- and write-tearing by the compiler use READ_ONCE()
and WRITE_ONCE() for accessing the ring indices in evtchn.c.
Signed-off-by: Juergen Gross
---
V2:
- modify all accesses (Julien Grall)
---
drivers/xen/evtchn.c | 25 -
1 file changed, 16 insertions(+), 9 deletions(-)
diff --git a/drivers/xen/evtchn.c b/drivers/xen/evtchn.c
index 421382c73d88..620008f89dbe 100644
--- a/drivers/xen/evtchn.c
+++ b/drivers/xen/evtchn.c
@@ -162,6 +162,7 @@ static irqreturn_t evtchn_interrupt(int irq, void *data)
{
struct user_evtchn *evtchn = data;
struct per_user_data *u = evtchn->user;
+ unsigned int prod, cons;
WARN(!evtchn->enabled,
"Interrupt for port %u, but apparently not enabled; per-user %p\n",
@@ -171,10 +172,14 @@ static irqreturn_t evtchn_interrupt(int irq, void *data)
spin_lock(>ring_prod_lock);
- if ((u->ring_prod - u->ring_cons) < u->ring_size) {
- *evtchn_ring_entry(u, u->ring_prod) = evtchn->port;
+ prod = READ_ONCE(u->ring_prod);
+ cons = READ_ONCE(u->ring_cons);
+
+ if ((prod - cons) < u->ring_size) {
+ *evtchn_ring_entry(u, prod) = evtchn->port;
smp_wmb(); /* Ensure ring contents visible */
- if (u->ring_cons == u->ring_prod++) {
+ if (cons == prod++) {
+ WRITE_ONCE(u->ring_prod, prod);
wake_up_interruptible(>evtchn_wait);
kill_fasync(>evtchn_async_queue,
SIGIO, POLL_IN);
@@ -210,8 +215,8 @@ static ssize_t evtchn_read(struct file *file, char __user
*buf,
if (u->ring_overflow)
goto unlock_out;
- c = u->ring_cons;
- p = u->ring_prod;
+ c = READ_ONCE(u->ring_cons);
+ p = READ_ONCE(u->ring_prod);
if (c != p)
break;
@@ -221,7 +226,7 @@ static ssize_t evtchn_read(struct file *file, char __user
*buf,
return -EAGAIN;
rc = wait_event_interruptible(u->evtchn_wait,
- u->ring_cons != u->ring_prod);
+ READ_ONCE(u->ring_cons) != READ_ONCE(u->ring_prod));
if (rc)
return rc;
}
@@ -251,7 +256,7 @@ static ssize_t evtchn_read(struct file *file, char __user
*buf,
copy_to_user([bytes1], >ring[0], bytes2)))
goto unlock_out;
- u->ring_cons += (bytes1 + bytes2) / sizeof(evtchn_port_t);
+ WRITE_ONCE(u->ring_cons, c + (bytes1 + bytes2) / sizeof(evtchn_port_t));
rc = bytes1 + bytes2;
unlock_out:
@@ -552,7 +557,9 @@ static long evtchn_ioctl(struct file *file,
/* Initialise the ring to empty. Clear errors. */
mutex_lock(>ring_cons_mutex);
spin_lock_irq(>ring_prod_lock);
- u->ring_cons = u->ring_prod = u->ring_overflow = 0;
+ WRITE_ONCE(u->ring_cons, 0);
+ WRITE_ONCE(u->ring_prod, 0);
+ u->ring_overflow = 0;
spin_unlock_irq(>ring_prod_lock);
mutex_unlock(>ring_cons_mutex);
rc = 0;
@@ -595,7 +602,7 @@ static __poll_t evtchn_poll(struct file *file, poll_table
*wait)
struct per_user_data *u = file->private_data;
poll_wait(file, >evtchn_wait, wait);
- if (u->ring_cons != u->ring_prod)
+ if (READ_ONCE(u->ring_cons) != READ_ONCE(u->ring_prod))
mask |= EPOLLIN | EPOLLRDNORM;
if (u->ring_overflow)
mask = EPOLLERR;
--
2.26.2
[PATCH v2 2/8] xen/events: don't unmask an event channel when an eoi is pending
An event channel should be kept masked when an eoi is pending for it.
When being migrated to another cpu it might be unmasked, though.
In order to avoid this keep three different flags for each event channel
to be able to distinguish "normal" masking/unmasking from eoi related
masking/unmasking and temporary masking. The event channel should only
be able to generate an interrupt if all flags are cleared.
Cc: sta...@vger.kernel.org
Fixes: 54c9de89895e0a36047 ("xen/events: add a new late EOI evtchn framework")
Reported-by: Julien Grall
Signed-off-by: Juergen Gross
---
V2:
- introduce a lock around masking/unmasking
- merge patch 3 into this one (Jan Beulich)
---
drivers/xen/events/events_2l.c | 7 --
drivers/xen/events/events_base.c | 102 +--
drivers/xen/events/events_fifo.c | 7 --
drivers/xen/events/events_internal.h | 6 --
4 files changed, 81 insertions(+), 41 deletions(-)
diff --git a/drivers/xen/events/events_2l.c b/drivers/xen/events/events_2l.c
index a7f413c5c190..b8f2f971c2f0 100644
--- a/drivers/xen/events/events_2l.c
+++ b/drivers/xen/events/events_2l.c
@@ -77,12 +77,6 @@ static bool evtchn_2l_is_pending(evtchn_port_t port)
return sync_test_bit(port, BM(>evtchn_pending[0]));
}
-static bool evtchn_2l_test_and_set_mask(evtchn_port_t port)
-{
- struct shared_info *s = HYPERVISOR_shared_info;
- return sync_test_and_set_bit(port, BM(>evtchn_mask[0]));
-}
-
static void evtchn_2l_mask(evtchn_port_t port)
{
struct shared_info *s = HYPERVISOR_shared_info;
@@ -376,7 +370,6 @@ static const struct evtchn_ops evtchn_ops_2l = {
.clear_pending = evtchn_2l_clear_pending,
.set_pending = evtchn_2l_set_pending,
.is_pending= evtchn_2l_is_pending,
- .test_and_set_mask = evtchn_2l_test_and_set_mask,
.mask = evtchn_2l_mask,
.unmask= evtchn_2l_unmask,
.handle_events = evtchn_2l_handle_events,
diff --git a/drivers/xen/events/events_base.c b/drivers/xen/events/events_base.c
index 6c539db81f8f..e157e7506830 100644
--- a/drivers/xen/events/events_base.c
+++ b/drivers/xen/events/events_base.c
@@ -97,13 +97,18 @@ struct irq_info {
short refcnt;
u8 spurious_cnt;
u8 is_accounted;
- enum xen_irq_type type; /* type */
+ short type; /* type: IRQT_* */
+ u8 mask_reason; /* Why is event channel masked */
+#define EVT_MASK_REASON_EXPLICIT 0x01
+#define EVT_MASK_REASON_TEMPORARY 0x02
+#define EVT_MASK_REASON_EOI_PENDING0x04
unsigned irq;
evtchn_port_t evtchn; /* event channel */
unsigned short cpu; /* cpu bound */
unsigned short eoi_cpu; /* EOI must happen on this cpu-1 */
unsigned int irq_epoch; /* If eoi_cpu valid: irq_epoch of event */
u64 eoi_time; /* Time in jiffies when to EOI. */
+ spinlock_t lock;
union {
unsigned short virq;
@@ -152,6 +157,7 @@ static DEFINE_RWLOCK(evtchn_rwlock);
* evtchn_rwlock
* IRQ-desc lock
* percpu eoi_list_lock
+ * irq_info->lock
*/
static LIST_HEAD(xen_irq_list_head);
@@ -302,6 +308,8 @@ static int xen_irq_info_common_setup(struct irq_info *info,
info->irq = irq;
info->evtchn = evtchn;
info->cpu = cpu;
+ info->mask_reason = EVT_MASK_REASON_EXPLICIT;
+ spin_lock_init(>lock);
ret = set_evtchn_to_irq(evtchn, irq);
if (ret < 0)
@@ -450,6 +458,34 @@ unsigned int cpu_from_evtchn(evtchn_port_t evtchn)
return ret;
}
+static void do_mask(struct irq_info *info, u8 reason)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(>lock, flags);
+
+ if (!info->mask_reason)
+ mask_evtchn(info->evtchn);
+
+ info->mask_reason |= reason;
+
+ spin_unlock_irqrestore(>lock, flags);
+}
+
+static void do_unmask(struct irq_info *info, u8 reason)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(>lock, flags);
+
+ info->mask_reason &= ~reason;
+
+ if (!info->mask_reason)
+ unmask_evtchn(info->evtchn);
+
+ spin_unlock_irqrestore(>lock, flags);
+}
+
#ifdef CONFIG_X86
static bool pirq_check_eoi_map(unsigned irq)
{
@@ -586,7 +622,7 @@ static void xen_irq_lateeoi_locked(struct irq_info *info,
bool spurious)
}
info->eoi_time = 0;
- unmask_evtchn(evtchn);
+ do_unmask(info, EVT_MASK_REASON_EOI_PENDING);
}
static void xen_irq_lateeoi_worker(struct work_struct *work)
@@ -831,7 +867,8 @@ static unsigned int __startup_pirq(unsigned int irq)
goto err;
out:
- unmask_evtchn(evtchn);
+ do_unmask(info, EVT_MASK_REASON_EXPLICIT);
+
eoi_pirq(irq_get_irq_data(irq));
return 0;
@@ -858,7 +895,7 @@ static void shutdown_pirq(struct irq_data *data)
if (!VALID_EVTCHN(evtchn))
return;
- mask_evtchn(evtchn);
+
Re: [PATCH v2] MIPS: Add basic support for ptrace single step
On Wed, Feb 10, 2021 at 02:52:41PM +0800, Tiezhu Yang wrote: > In the current code, arch_has_single_step() is not defined on MIPS, > that means MIPS does not support instruction single-step for user mode. > > Delve is a debugger for the Go programming language, the ptrace syscall > PtraceSingleStep() failed [1] on MIPS and then the single step function > can not work well, we can see that PtraceSingleStep() definition returns > ptrace(PTRACE_SINGLESTEP) [2]. > > So it is necessary to support ptrace single step on MIPS. one way to see it. The other way is, that the Go debugger needs to learn single stepping without ptrace single step support. IMHO gdb is already able to do that. IMHO ptrace single step is for CPUs supporting single stepping and not for emulating it in the kernel. Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessarily a good idea.[ RFC1925, 2.3 ]
Re: [PATCH v3 RESEND] MIPS: Make check condition for SDBBP more readable
On Wed, Feb 10, 2021 at 04:30:26PM +0800, Tiezhu Yang wrote: > According to MIPS EJTAG Specification [1], a Debug Breakpoint > exception occurs when an SDBBP instruction is executed, the > CP0_DEBUG bit DBp indicates that a Debug Breakpoint exception > occurred. > > When I read the original code, it looks a little confusing > at first glance, just check bit DBp for SDBBP to make the > code more readable, it will be much easier to understand. > > [1] http://www.t-es-t.hu/download/mips/md00047f.pdf > > Signed-off-by: Tiezhu Yang > --- > > RESEND due to send to mail list failed. > > v3: update the commit message and modify the patch subject > > v2: add MIPS_DEBUG_DBP definition > > arch/mips/include/asm/mipsregs.h | 4 > arch/mips/kernel/genex.S | 4 ++-- > 2 files changed, 6 insertions(+), 2 deletions(-) applied to mips-next. Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessarily a good idea.[ RFC1925, 2.3 ]
Re: [PATCH] mips: Replace lkml.org links with lore
On Wed, Feb 10, 2021 at 03:50:25PM -0800, Kees Cook wrote:
> As started by commit 05a5f51ca566 ("Documentation: Replace lkml.org
> links with lore"), replace lkml.org links with lore to better use a
> single source that's more likely to stay available long-term.
>
> Signed-off-by: Kees Cook
> ---
> This patch may make more sense if this entire comment and the related
> code is fixed instead (gcc 3.x has been quite retired...)
> ---
> arch/mips/include/asm/page.h | 11 +--
> 1 file changed, 5 insertions(+), 6 deletions(-)
applied to mips-next.
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.[ RFC1925, 2.3 ]
Re: [PATCH v3 4/4] RDMA/umem: batch page unpin in __ib_umem_release()
On 2/10/21 11:17 PM, Jason Gunthorpe wrote: > On Fri, Feb 05, 2021 at 08:41:27PM +, Joao Martins wrote: >> Use the newly added unpin_user_page_range_dirty_lock() >> for more quickly unpinning a consecutive range of pages >> represented as compound pages. This will also calculate >> number of pages to unpin (for the tail pages which matching >> head page) and thus batch the refcount update. >> >> Running a test program which calls mr reg/unreg on a 1G in size >> and measures cost of both operations together (in a guest using rxe) >> with THP and hugetlbfs: >> >> Before: >> 590 rounds in 5.003 sec: 8480.335 usec / round >> 6898 rounds in 60.001 sec: 8698.367 usec / round >> >> After: >> 2688 rounds in 5.002 sec: 1860.786 usec / round >> 32517 rounds in 60.001 sec: 1845.225 usec / round >> >> Signed-off-by: Joao Martins >> --- >> drivers/infiniband/core/umem.c | 12 ++-- >> 1 file changed, 6 insertions(+), 6 deletions(-) > > Would best for this to go through Andrew's tree > > Acked-by: Jason Gunthorpe > > 4x improvement is pretty good! > It would only be half of that improvement if it wasn't for your unpin_user_page_range_dirty_lock() suggestion, so thanks for all the input :) Joao
Re: [PATCH v8 1/4] KEYS: trusted: Add generic trusted keys framework
Hello Jarkko,
On 10.02.21 18:00, Jarkko Sakkinen wrote:
> On Tue, Nov 03, 2020 at 09:31:43PM +0530, Sumit Garg wrote:
>> +case Opt_new:
>> +key_len = payload->key_len;
>> +ret = static_call(trusted_key_get_random)(payload->key,
>> + key_len);
>> +if (ret != key_len) {
>> +pr_info("trusted_key: key_create failed (%d)\n", ret);
>> +goto out;
>> +}
>
> This repeats a regression in existing code, i.e. does not check
> "ret < 0" condition. I noticed this now when I rebased the code
> on top of my fixes.
>
> I.e. it's fixed in my master branch, which caused a merge conflict,
> and I found this.
Does that mean this series will go out for the next merge window?
Can you point me where your git tree is, so I can rebase on top?
>
> /Jarkko
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
RE: kernel BUG at mm/zswap.c:1275! (rc6 - git 61556703b610)
> -Original Message- > From: Mikhail Gavrilov [mailto:mikhail.v.gavri...@gmail.com] > Sent: Thursday, February 11, 2021 9:58 PM > To: sjenn...@linux.vnet.ibm.com; Song Bao Hua (Barry Song) > > Cc: Linux List Kernel Mailing ; Linux Memory > Management List > Subject: kernel BUG at mm/zswap.c:1275! (rc6 - git 61556703b610) > > Hi folks. > During the 5.11 test cycle I caught a rare but repeatable problem when > after a day uptime happens "BUG at mm/zswap.c:1275!". I am still not > having an idea how to reproduce it, but maybe the authors of this code > could explain what happens here? Are you using zsmalloc? There is a known bug on the combination of zsmalloc and zswap, fixed by patches of tiantao: mm: set the sleep_mapped to true for zbud and z3fold mm/zswap: fix variable 'entry' is uninitialized when used mm/zswap: fix potential memory leak mm/zswap: add the flag can_sleep_mapped at Linux-next: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/log/?qt=author=tiantao6%40hisilicon.com > > $ grep "mm/zswap.c" dmesg*.txt > dmesg101.txt:[127850.513201] kernel BUG at mm/zswap.c:1275! > dmesg11.txt:[52211.962861] kernel BUG at mm/zswap.c:1275! > dmesg8.txt:[46610.641843] kernel BUG at mm/zswap.c:1275! > > [127850.513193] [ cut here ] > [127850.513201] kernel BUG at mm/zswap.c:1275! > [127850.513210] invalid opcode: [#1] SMP NOPTI > [127850.513214] CPU: 6 PID: 485132 Comm: brave Tainted: GW >- --- 5.11.0-0.rc6.20210204git61556703b610.145.fc34.x86_64 > #1 > [127850.513218] Hardware name: System manufacturer System Product > Name/ROG STRIX X570-I GAMING, BIOS 3402 01/13/2021 > [127850.513221] RIP: 0010:zswap_frontswap_load+0x258/0x260 > [127850.513228] Code: ab 83 aa f0 2f 00 00 01 65 ff 0d c3 73 cd 54 eb > 88 48 8d 7b 10 e8 78 b9 9f 00 c7 43 10 00 00 00 00 44 8b 63 70 e9 4a > ff ff ff <0f> 0b 0f 0b 0f 0b 66 90 0f 1f 44 00 00 41 57 31 c0 b9 0c 00 > 00 00 > [127850.513231] RSP: :a92e866c7c48 EFLAGS: 00010282 > [127850.513235] RAX: 0006 RBX: c92e7ca61830 RCX: > 0001 > [127850.513238] RDX: RSI: ab3429fe RDI: > 97f4d0393010 > [127850.513240] RBP: 97ee5544d1c0 R08: 0001 R09: > > [127850.513242] R10: R11: R12: > ffea > [127850.513244] R13: 97ee016800c8 R14: 97ee016800c0 R15: > c0d54020 > [127850.513247] FS: 7fcbe628de40() GS:97f50760() > knlGS: > [127850.513249] CS: 0010 DS: ES: CR0: 80050033 > [127850.513252] CR2: 381208c29250 CR3: 0001c54ea000 CR4: > 00350ee0 > [127850.513254] Call Trace: > [127850.513261] __frontswap_load+0xc3/0x160 > [127850.513265] swap_readpage+0x1ca/0x3a0 > [127850.513270] swapin_readahead+0x2ee/0x4e0 > [127850.513276] do_swap_page+0x4a4/0x900 > [127850.513279] ? lock_release+0x1e9/0x400 > [127850.513283] ? trace_hardirqs_on+0x1b/0xe0 > [127850.513288] handle_mm_fault+0xe7d/0x19d0 > [127850.513294] do_user_addr_fault+0x1c7/0x4c0 > [127850.513299] exc_page_fault+0x67/0x2a0 > [127850.513304] ? asm_exc_page_fault+0x8/0x30 > [127850.513307] asm_exc_page_fault+0x1e/0x30 > [127850.513310] RIP: 0033:0x560297642f44 > [127850.513314] Code: 64 75 07 45 8b 76 03 4d 03 f5 45 8b 56 ff 4d 03 > d5 66 41 81 7a 07 83 00 0f 85 4f 01 00 00 8b 5f 13 49 03 dd 8b 5b 03 > 49 03 dd <8b> 4b ff 49 03 cd 66 81 79 07 a5 00 0f 85 0f 00 00 00 8b 4b > 0f f6 > [127850.513317] RSP: 002b:7ffc04cd4b30 EFLAGS: 00010202 > [127850.513320] RAX: RBX: 381208c29251 RCX: > 560297642f00 > [127850.513322] RDX: 3812080423b1 RSI: 381209b11231 RDI: > 381209b1141d > [127850.513323] RBP: 7ffc04cd4b90 R08: 0043 R09: > 0024 > [127850.513325] R10: 381208042a1d R11: 381209b1141f R12: > 09b1141d > [127850.513327] R13: 3812 R14: 381208b368ed R15: > 3d2fb6b7da10 > [127850.51] Modules linked in: tun snd_seq_dummy snd_hrtimer > uinput rfcomm nft_objref nf_conntrack_netbios_ns > nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib > nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct > nft_chain_nat ip6table_nat ip6table_mangle ip6table_raw > ip6table_security iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 > nf_defrag_ipv4 iptable_mangle iptable_raw iptable_security ip_set > nf_tables nfnetlink ip6table_filter ip6_tables iptable_filter cmac > bnep zstd sunrpc vfat fat hid_logitech_hidpp hid_logitech_dj > snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio > snd_hda_codec_hdmi snd_hda_intel snd_intel_dspcfg soundwire_intel > soundwire_generic_allocation mt76x2u mt76x2_common snd_soc_core > mt76x02_usb snd_compress mt76_usb snd_pcm_dmaengine soundwire_cadence > intel_rapl_msr intel_rapl_common iwlmvm snd_hda_codec uvcvideo > mt76x02_lib snd_usb_audio videobuf2_vmalloc snd_hda_core mt76 >
Re: [RFC PATCH 1/2] mm,page_alloc: Make alloc_contig_range handle in-use hugetlb pages
On 11.02.21 01:56, Mike Kravetz wrote:
On 2/8/21 2:38 AM, Oscar Salvador wrote:
alloc_contig_range is not prepared to handle hugetlb pages and will
fail if it ever sees one, but since they can be migrated as any other
page (LRU and Movable), it makes sense to also handle them.
For now, do it only when coming from alloc_contig_range.
Signed-off-by: Oscar Salvador
---
mm/compaction.c | 17 +
mm/vmscan.c | 5 +++--
2 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/mm/compaction.c b/mm/compaction.c
index e5acb9714436..89cd2e60da29 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -940,6 +940,22 @@ isolate_migratepages_block(struct compact_control *cc,
unsigned long low_pfn,
goto isolate_fail;
}
+ /*
+* Handle hugetlb pages only when coming from alloc_contig
+*/
+ if (PageHuge(page) && cc->alloc_contig) {
+ if (page_count(page)) {
Thanks for doing this!
I agree with everything in the discussion you and David had. This code
is racy, but since we are scanning lockless there is no way to eliminate
them all. Best to just minimize the windows and document.
Agreed - and make sure that we don't have strange side. (e.g., in the
next patch, allocate a new page, try to dissolve. Dissolving fails, what
happens to the just-allocated page?)
--
Thanks,
David / dhildenb
Re: [PATCH][next] media: i2c: imx334: Fix a read of the uninitialized variable ret
On Wed, Feb 10, 2021 at 11:03:03PM +0200, Sakari Ailus wrote:
> Hi Colin,
>
> On Wed, Feb 10, 2021 at 07:07:52PM +, Colin King wrote:
> > From: Colin Ian King
> >
> > Currently there is a dev_err error message that is printing the
> > error status in variable ret (that has not been set) instead of
> > the correct error status from imx334->reset_gpio. Fix this.
> >
> > Addresses-Coverity: ("Uninitialized scalar variable")
> > Fixes: 9746b11715c3 ("media: i2c: Add imx334 camera sensor driver")
> >
> > Signed-off-by: Colin Ian King
> > ---
> > drivers/media/i2c/imx334.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/media/i2c/imx334.c b/drivers/media/i2c/imx334.c
> > index 07e31bc2ef18..f8b1caf26c9b 100644
> > --- a/drivers/media/i2c/imx334.c
> > +++ b/drivers/media/i2c/imx334.c
> > @@ -790,7 +790,8 @@ static int imx334_parse_hw_config(struct imx334 *imx334)
> > imx334->reset_gpio = devm_gpiod_get_optional(imx334->dev, "reset",
> > GPIOD_OUT_LOW);
> > if (IS_ERR(imx334->reset_gpio)) {
> > - dev_err(imx334->dev, "failed to get reset gpio %d", ret);
> > + dev_err(imx334->dev, "failed to get reset gpio %ld",
> > + IS_ERR_VALUE(imx334->reset_gpio));
IS_ERR_VALUE() isn't right. It would always print 1 here. It should
just be PTR_ERR().
IS_ERR_VALUE() is like IS_ERR() but for when you're storing memory
addresses in an unsigned long variable. get_unmapped_area(), for
example, returns unsigned longs.
regards,
dan carpenter
Re: [PATCH v2 02/12] dts: mvebu: Update A8K AP806/AP807 SDHCI settings
On Wed, Feb 10, 2021 at 04:09:39PM +0200, kos...@marvell.com wrote:
> From: Konstantin Porotchkin
>
> Select the AP SDHCI PHY slow mode for AP806 die only (move it
> from armada-ap80x.dtsi to armada-ap806.dtsi). This will allow
> running AP807 based devices at HS400 speed.
> Remove Ap SDHCI slow mode property from MacchiatoBin board DTS
> since it is already selected on the SoC level.
>
> Signed-off-by: Konstantin Porotchkin
Acked-by: Russell King
> ---
> arch/arm64/boot/dts/marvell/armada-8040-mcbin.dtsi | 5 -
> arch/arm64/boot/dts/marvell/armada-ap806.dtsi | 12
> arch/arm64/boot/dts/marvell/armada-ap80x.dtsi | 1 -
> 3 files changed, 12 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dtsi
> b/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dtsi
> index 73733b4126e2..69653de998e2 100644
> --- a/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dtsi
> +++ b/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dtsi
> @@ -109,11 +109,6 @@
>
> _sdhci0 {
> bus-width = <8>;
> - /*
> - * Not stable in HS modes - phy needs "more calibration", so add
> - * the "slow-mode" and disable SDR104, SDR50 and DDR50 modes.
> - */
> - marvell,xenon-phy-slow-mode;
> no-1-8-v;
> no-sd;
> no-sdio;
> diff --git a/arch/arm64/boot/dts/marvell/armada-ap806.dtsi
> b/arch/arm64/boot/dts/marvell/armada-ap806.dtsi
> index 866628679ac7..828cd539173b 100644
> --- a/arch/arm64/boot/dts/marvell/armada-ap806.dtsi
> +++ b/arch/arm64/boot/dts/marvell/armada-ap806.dtsi
> @@ -28,3 +28,15 @@
> reg = <0x278 0xa30>;
> };
> };
> +
> +_sdhci0 {
> + /*
> + * SoC based on AP806 revision A0, A1 and A2 should use slow mode
> + * settings for Ap SDHCI due to HW Erratum HWE-7296210
> + * AP806 revesion B0 and later has this erratum fixed and the slow
> + * mode could be removed in board DTS:
> + * /delete-property/marvell,xenon-phy-slow-mode;
> + * Starting from B0 revision, the AP SDHCI can run with HS400 timing.
> + */
> + marvell,xenon-phy-slow-mode;
> +};
> diff --git a/arch/arm64/boot/dts/marvell/armada-ap80x.dtsi
> b/arch/arm64/boot/dts/marvell/armada-ap80x.dtsi
> index 12e477f1aeb9..edd6131a0587 100644
> --- a/arch/arm64/boot/dts/marvell/armada-ap80x.dtsi
> +++ b/arch/arm64/boot/dts/marvell/armada-ap80x.dtsi
> @@ -257,7 +257,6 @@
> clock-names = "core";
> clocks = <_clk 4>;
> dma-coherent;
> - marvell,xenon-phy-slow-mode;
> status = "disabled";
> };
>
> --
> 2.17.1
>
>
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
Re: [PATCH] kbuild: fix CONFIG_TRIM_UNUSED_KSYMS build for ppc64
+++ Masahiro Yamada [11/02/21 15:14 +0900]:
Stephen Rothwell reported a build error on ppc64 when
CONFIG_TRIM_UNUSED_KSYMS is enabled.
Jessica Yu pointed out the cause of the error with the reference to the
ppc64 elf ABI:
"Symbol names with a dot (.) prefix are reserved for holding entry
point addresses. The value of a symbol named ".FN", if it exists,
is the entry point of the function "FN".
As it turned out, CONFIG_TRIM_UNUSED_KSYMS has never worked for ppc64,
which has been unnoticed until recently because this option depends on
!UNUSED_SYMBOLS hence is disabled by all{mod,yes}config. (Then, it was
uncovered by another patch removing UNUSED_SYMBOLS.)
Removing the dot prefix in scripts/gen_autoksyms.sh fixes the issue.
Please note it must be done before 'sort -u', because modules have
both ._mcount and _mcount undefined when CONFIG_FUNCTION_TRACER=y.
Link: https://lore.kernel.org/lkml/20210209210843.3af66...@canb.auug.org.au/
Reported-by: Stephen Rothwell
Signed-off-by: Masahiro Yamada
Thanks a lot for the quick fix. This fixes the ppc64 build issue on my end:
Tested-by: Jessica Yu
Do you plan to take this through the kbuild tree? If so, please let me
know when you've applied it, then I can undo the temporary workaround
I currently have in modules-next.
Thank you!
Jessica
Re: [PATCH v3 1/4] mm/gup: add compound page list iterator
On 2/10/21 11:20 PM, Jason Gunthorpe wrote: > On Fri, Feb 05, 2021 at 08:41:24PM +, Joao Martins wrote: >> Add an helper that iterates over head pages in a list of pages. It >> essentially counts the tails until the next page to process has a >> different head that the current. This is going to be used by >> unpin_user_pages() family of functions, to batch the head page refcount >> updates once for all passed consecutive tail pages. >> >> Suggested-by: Jason Gunthorpe >> Signed-off-by: Joao Martins >> Reviewed-by: John Hubbard >> --- >> mm/gup.c | 26 ++ >> 1 file changed, 26 insertions(+) > > Reviewed-by: Jason Gunthorpe > Thanks! > This can be used for check_and_migrate_cma_pages() too (there is a > series around to change this logic though, not sure if it is landed > yet) It got unqueued AFAIUI. It makes sense for most users today except hugetlb pages, which are also the fastest page pinner today. And unilaterally using this iterator makes all page types pay the added cost. So either keeping the current loop having the exception to PageHuge() head pages, or doing it correctly with that split logic we were talking on the other thread. Joao
[tip:x86/paravirt] BUILD SUCCESS ab234a260b1f625b26cbefa93ca365b0ae66df33
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/paravirt branch HEAD: ab234a260b1f625b26cbefa93ca365b0ae66df33 x86/pv: Rework arch_local_irq_restore() to not use popf elapsed time: 726m configs tested: 125 configs skipped: 70 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 sama5_defconfig m68kmvme147_defconfig arm badge4_defconfig shdreamcast_defconfig openrisc alldefconfig arm bcm2835_defconfig powerpcklondike_defconfig c6x dsk6455_defconfig mips malta_defconfig powerpccell_defconfig xtensa virt_defconfig armmagician_defconfig mips ip32_defconfig powerpc tqm8540_defconfig sh kfr2r09_defconfig nios2 10m50_defconfig mips decstation_r4k_defconfig arcnsimosci_defconfig powerpc mpc885_ads_defconfig arc haps_hs_defconfig arm prima2_defconfig powerpc g5_defconfig sh sh7785lcr_32bit_defconfig mips tb0287_defconfig powerpcsocrates_defconfig mipsar7_defconfig powerpc sbc8548_defconfig powerpc tqm8555_defconfig powerpc allmodconfig powerpc xes_mpc85xx_defconfig m68km5407c3_defconfig sh apsh4a3a_defconfig powerpc ep8248e_defconfig mipsomega2p_defconfig riscvalldefconfig armvexpress_defconfig m68kmac_defconfig arm pxa_defconfig powerpc mpc832x_rdb_defconfig sh se7751_defconfig powerpc sequoia_defconfig ia64 bigsur_defconfig ia64 gensparse_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 s390 allmodconfig parisc allyesconfig s390defconfig i386 allyesconfig sparcallyesconfig sparc defconfig i386 tinyconfig i386defconfig mips allyesconfig mips allmodconfig powerpc allyesconfig powerpc allnoconfig x86_64 randconfig-a006-20210209 x86_64 randconfig-a001-20210209 x86_64 randconfig-a005-20210209 x86_64 randconfig-a004-20210209 x86_64 randconfig-a002-20210209 x86_64 randconfig-a003-20210209 i386 randconfig-a001-20210209 i386 randconfig-a005-20210209 i386 randconfig-a003-20210209 i386 randconfig-a002-20210209 i386 randconfig-a006-20210209 i386 randconfig-a004-20210209 x86_64 randconfig-a016-20210211 x86_64 randconfig-a013-20210211 x86_64 randconfig-a012-20210211 x86_64 randconfig-a015-20210211 x86_64 randconfig-a014-20210211 x86_64 randconfig-a011-20210211 i386 randconfig-a016-20210209 i386
[tip:objtool/core] BUILD SUCCESS aafeb14e9da29e323b0605f8f1bae0d45d5f3acf
sequoia_defconfig ia64 gensparse_defconfig m68k alldefconfig m68k apollo_defconfig m68k bvme6000_defconfig mips ci20_defconfig m68kdefconfig ia64defconfig ia64 allyesconfig m68k allmodconfig 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 i386 tinyconfig i386defconfig mips allyesconfig mips allmodconfig powerpc allnoconfig x86_64 randconfig-a006-20210209 x86_64 randconfig-a001-20210209 x86_64 randconfig-a005-20210209 x86_64 randconfig-a004-20210209 x86_64 randconfig-a002-20210209 x86_64 randconfig-a003-20210209 i386 randconfig-a001-20210209 i386 randconfig-a005-20210209 i386 randconfig-a003-20210209 i386 randconfig-a002-20210209 i386 randconfig-a006-20210209 i386 randconfig-a004-20210209 x86_64 randconfig-a016-20210211 x86_64 randconfig-a013-20210211 x86_64 randconfig-a012-20210211 x86_64 randconfig-a015-20210211 x86_64 randconfig-a014-20210211 x86_64 randconfig-a011-20210211 i386 randconfig-a016-20210209 i386 randconfig-a013-20210209 i386 randconfig-a012-20210209 i386 randconfig-a014-20210209 i386 randconfig-a011-20210209 i386 randconfig-a015-20210209 riscvnommu_k210_defconfig riscvallyesconfig riscv allnoconfig riscv defconfig riscv rv32_defconfig riscvallmodconfig x86_64 rhel x86_64 allyesconfig x86_64rhel-7.6-kselftests x86_64 defconfig x86_64 rhel-8.3 x86_64 rhel-8.3-kbuiltin x86_64 kexec clang tested configs: x86_64 randconfig-a013-20210209 x86_64 randconfig-a014-20210209 x86_64 randconfig-a015-20210209 x86_64 randconfig-a012-20210209 x86_64 randconfig-a016-20210209 x86_64 randconfig-a011-20210209 --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
[tip:sched/core] BUILD SUCCESS 82891be90f3c42dc964fd61b8b2a89de12940c9f
allyesconfig arc defconfig sh allmodconfig parisc defconfig s390 allyesconfig s390 allmodconfig parisc allyesconfig s390defconfig i386 allyesconfig sparcallyesconfig sparc defconfig i386 tinyconfig i386defconfig mips allyesconfig mips allmodconfig powerpc allnoconfig x86_64 randconfig-a006-20210209 x86_64 randconfig-a001-20210209 x86_64 randconfig-a005-20210209 x86_64 randconfig-a004-20210209 x86_64 randconfig-a002-20210209 x86_64 randconfig-a003-20210209 i386 randconfig-a001-20210209 i386 randconfig-a005-20210209 i386 randconfig-a003-20210209 i386 randconfig-a002-20210209 i386 randconfig-a006-20210209 i386 randconfig-a004-20210209 x86_64 randconfig-a016-20210211 x86_64 randconfig-a013-20210211 x86_64 randconfig-a012-20210211 x86_64 randconfig-a015-20210211 x86_64 randconfig-a014-20210211 x86_64 randconfig-a011-20210211 i386 randconfig-a016-20210209 i386 randconfig-a013-20210209 i386 randconfig-a012-20210209 i386 randconfig-a014-20210209 i386 randconfig-a011-20210209 i386 randconfig-a015-20210209 riscvnommu_k210_defconfig riscvallyesconfig riscv allnoconfig riscv defconfig riscv rv32_defconfig riscvallmodconfig x86_64 rhel x86_64 allyesconfig x86_64rhel-7.6-kselftests x86_64 defconfig x86_64 rhel-8.3 x86_64 rhel-8.3-kbuiltin x86_64 kexec clang tested configs: x86_64 randconfig-a013-20210209 x86_64 randconfig-a014-20210209 x86_64 randconfig-a015-20210209 x86_64 randconfig-a012-20210209 x86_64 randconfig-a016-20210209 x86_64 randconfig-a011-20210209 --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
[tip:locking/core] BUILD SUCCESS 6c80408a8a0360fa9223b8c21c0ab8ef42e88bfe
randconfig-a003-20210209 i386 randconfig-a002-20210209 i386 randconfig-a006-20210209 i386 randconfig-a004-20210209 x86_64 randconfig-a016-20210211 x86_64 randconfig-a013-20210211 x86_64 randconfig-a012-20210211 x86_64 randconfig-a015-20210211 x86_64 randconfig-a014-20210211 x86_64 randconfig-a011-20210211 i386 randconfig-a016-20210209 i386 randconfig-a013-20210209 i386 randconfig-a012-20210209 i386 randconfig-a014-20210209 i386 randconfig-a011-20210209 i386 randconfig-a015-20210209 riscvnommu_k210_defconfig riscvallyesconfig riscv allnoconfig riscv defconfig riscv rv32_defconfig riscvallmodconfig x86_64 rhel x86_64 allyesconfig x86_64rhel-7.6-kselftests x86_64 defconfig x86_64 rhel-8.3 x86_64 rhel-8.3-kbuiltin x86_64 kexec clang tested configs: x86_64 randconfig-a013-20210209 x86_64 randconfig-a014-20210209 x86_64 randconfig-a015-20210209 x86_64 randconfig-a012-20210209 x86_64 randconfig-a016-20210209 x86_64 randconfig-a011-20210209 --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
