[PATCH] net: fix uninit value error in __sys_sendmmsg
The crash report showed that there was a local variable;
iovstack.i@__sys_sendmmsg created at:
___sys_sendmsg net/socket.c:2388 [inline]
__sys_sendmmsg+0x6db/0xc90 net/socket.c:2480
that was left uninitialized.
The contents of iovstack are of interest, since the respective pointer
is passed down as an argument to sendmsg_copy_msghdr as well.
Initializing this contents of this stack prevents this bug from happening.
Since the memory that was initialized is freed at the end of the function
call, memory leaks are not likely to be an issue.
syzbot seems to have triggered this error by passing an array of 0's as
a parameter while making the initial system call.
Reported-by: syzbot+09a5d591c1f98cf5e...@syzkaller.appspotmail.com
Tested-by: syzbot+09a5d591c1f98cf5e...@syzkaller.appspotmail.com
Signed-off-by: Anant Thazhemadam
---
net/socket.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/socket.c b/net/socket.c
index 0c0144604f81..d74443dfd73b 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -2396,6 +2396,7 @@ static int ___sys_sendmsg(struct socket *sock, struct
user_msghdr __user *msg,
{
struct sockaddr_storage address;
struct iovec iovstack[UIO_FASTIOV], *iov = iovstack;
+ memset(iov, 0, UIO_FASTIOV);
ssize_t err;
msg_sys->msg_name =
--
2.25.1
[PATCH V2] natsemi: switch from 'pci_' to 'dma_' API
The wrappers in include/linux/pci-dma-compat.h should go away.
The patch has been generated with the coccinelle script below and has been
hand modified to replace GFP_ with a correct flag.
It has been compile tested.
When memory is allocated in 'alloc_ring()' (natsemi.c) GFP_KERNEL can be
used because it is only called from 'netdev_open()', which is a '.ndo_open'
function. Such function are synchronized with the rtnl_lock() semaphore.
When memory is allocated in 'ns83820_init_one()' (ns83820.c) GFP_KERNEL can
be used because it is a probe function and no lock is taken in the between.
@@
@@
-PCI_DMA_BIDIRECTIONAL
+DMA_BIDIRECTIONAL
@@
@@
-PCI_DMA_TODEVICE
+DMA_TO_DEVICE
@@
@@
-PCI_DMA_FROMDEVICE
+DMA_FROM_DEVICE
@@
@@
-PCI_DMA_NONE
+DMA_NONE
@@
expression e1, e2, e3;
@@
-pci_alloc_consistent(e1, e2, e3)
+dma_alloc_coherent(>dev, e2, e3, GFP_)
@@
expression e1, e2, e3;
@@
-pci_zalloc_consistent(e1, e2, e3)
+dma_alloc_coherent(>dev, e2, e3, GFP_)
@@
expression e1, e2, e3, e4;
@@
-pci_free_consistent(e1, e2, e3, e4)
+dma_free_coherent(>dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
-pci_map_single(e1, e2, e3, e4)
+dma_map_single(>dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
-pci_unmap_single(e1, e2, e3, e4)
+dma_unmap_single(>dev, e2, e3, e4)
@@
expression e1, e2, e3, e4, e5;
@@
-pci_map_page(e1, e2, e3, e4, e5)
+dma_map_page(>dev, e2, e3, e4, e5)
@@
expression e1, e2, e3, e4;
@@
-pci_unmap_page(e1, e2, e3, e4)
+dma_unmap_page(>dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
-pci_map_sg(e1, e2, e3, e4)
+dma_map_sg(>dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
-pci_unmap_sg(e1, e2, e3, e4)
+dma_unmap_sg(>dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
-pci_dma_sync_single_for_cpu(e1, e2, e3, e4)
+dma_sync_single_for_cpu(>dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
-pci_dma_sync_single_for_device(e1, e2, e3, e4)
+dma_sync_single_for_device(>dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
-pci_dma_sync_sg_for_cpu(e1, e2, e3, e4)
+dma_sync_sg_for_cpu(>dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
-pci_dma_sync_sg_for_device(e1, e2, e3, e4)
+dma_sync_sg_for_device(>dev, e2, e3, e4)
@@
expression e1, e2;
@@
-pci_dma_mapping_error(e1, e2)
+dma_mapping_error(>dev, e2)
@@
expression e1, e2;
@@
-pci_set_dma_mask(e1, e2)
+dma_set_mask(>dev, e2)
@@
expression e1, e2;
@@
-pci_set_consistent_dma_mask(e1, e2)
+dma_set_coherent_mask(>dev, e2)
Signed-off-by: Christophe JAILLET
---
If needed, see post from Christoph Hellwig on the kernel-janitors ML:
https://marc.info/?l=kernel-janitors=158745678307186=4
V2: fix description (duplicated comment and wrong file name)
---
drivers/net/ethernet/natsemi/natsemi.c | 63 +-
drivers/net/ethernet/natsemi/ns83820.c | 61 +
2 files changed, 62 insertions(+), 62 deletions(-)
diff --git a/drivers/net/ethernet/natsemi/natsemi.c
b/drivers/net/ethernet/natsemi/natsemi.c
index 3de8430ee8c5..05d43fd7ea98 100644
--- a/drivers/net/ethernet/natsemi/natsemi.c
+++ b/drivers/net/ethernet/natsemi/natsemi.c
@@ -1916,9 +1916,9 @@ static void ns_tx_timeout(struct net_device *dev,
unsigned int txqueue)
static int alloc_ring(struct net_device *dev)
{
struct netdev_private *np = netdev_priv(dev);
- np->rx_ring = pci_alloc_consistent(np->pci_dev,
- sizeof(struct netdev_desc) * (RX_RING_SIZE+TX_RING_SIZE),
- >ring_dma);
+ np->rx_ring = dma_alloc_coherent(>pci_dev->dev,
+sizeof(struct netdev_desc) *
(RX_RING_SIZE + TX_RING_SIZE),
+>ring_dma, GFP_KERNEL);
if (!np->rx_ring)
return -ENOMEM;
np->tx_ring = >rx_ring[RX_RING_SIZE];
@@ -1939,10 +1939,10 @@ static void refill_rx(struct net_device *dev)
np->rx_skbuff[entry] = skb;
if (skb == NULL)
break; /* Better luck next round. */
- np->rx_dma[entry] = pci_map_single(np->pci_dev,
- skb->data, buflen, PCI_DMA_FROMDEVICE);
- if (pci_dma_mapping_error(np->pci_dev,
- np->rx_dma[entry])) {
+ np->rx_dma[entry] = dma_map_single(>pci_dev->dev,
+ skb->data, buflen,
+ DMA_FROM_DEVICE);
+ if (dma_mapping_error(>pci_dev->dev,
np->rx_dma[entry])) {
dev_kfree_skb_any(skb);
np->rx_skbuff[entry] = NULL;
break; /* Better luck next round. */
@@ -2013,9 +2013,8 @@ static void drain_tx(struct net_device *dev)
[PATCH v2] arm64: dts: layerscape: Add label to pcie nodes
From: Wasim Khan
Add label to pcie nodes so that they are easy to
refer.
Signed-off-by: Wasim Khan
---
Changes in v2:
- clubbed separate patches in single patch
arch/arm64/boot/dts/freescale/fsl-ls1012a-oxalis.dts | 2 +-
arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi | 5 +++--
arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 6 +++---
arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi | 10 +-
arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 16
arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 8
arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi | 12 ++--
7 files changed, 30 insertions(+), 29 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1012a-oxalis.dts
b/arch/arm64/boot/dts/freescale/fsl-ls1012a-oxalis.dts
index 9927b09..242f4b0 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1012a-oxalis.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1012a-oxalis.dts
@@ -87,7 +87,7 @@
status = "okay";
};
- {
+ {
status = "okay";
};
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
b/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
index ff19ec4..6a2c091 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
@@ -1,8 +1,9 @@
// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
/*
- * Device Tree Include file for Freescale Layerscape-1012A family SoC.
+ * Device Tree Include file for NXP Layerscape-1012A family SoC.
*
* Copyright 2016 Freescale Semiconductor, Inc.
+ * Copyright 2019-2020 NXP
*
*/
@@ -489,7 +490,7 @@
interrupts = <0 126 IRQ_TYPE_LEVEL_HIGH>;
};
- pcie: pcie@340 {
+ pcie1: pcie@340 {
compatible = "fsl,ls1012a-pcie";
reg = <0x00 0x0340 0x0 0x0010 /* controller
registers */
0x40 0x 0x0 0x2000>; /*
configuration space */
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
index 0efeb8f..55b6e72 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
@@ -2,7 +2,7 @@
/*
* Device Tree Include file for NXP Layerscape-1028A family SoC.
*
- * Copyright 2018 NXP
+ * Copyright 2018-2020 NXP
*
* Harninder Rai
*
@@ -553,7 +553,7 @@
status = "disabled";
};
- pcie@340 {
+ pcie1: pcie@340 {
compatible = "fsl,ls1028a-pcie";
reg = <0x00 0x0340 0x0 0x0010 /* controller
registers */
0x80 0x 0x0 0x2000>; /*
configuration space */
@@ -580,7 +580,7 @@
status = "disabled";
};
- pcie@350 {
+ pcie2: pcie@350 {
compatible = "fsl,ls1028a-pcie";
reg = <0x00 0x0350 0x0 0x0010 /* controller
registers */
0x88 0x 0x0 0x2000>; /*
configuration space */
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
index 5c2e370..0464b8a 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
@@ -1,9 +1,9 @@
// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
/*
- * Device Tree Include file for Freescale Layerscape-1043A family SoC.
+ * Device Tree Include file for NXP Layerscape-1043A family SoC.
*
* Copyright 2014-2015 Freescale Semiconductor, Inc.
- * Copyright 2018 NXP
+ * Copyright 2018, 2020 NXP
*
* Mingkai Hu
*/
@@ -814,7 +814,7 @@
interrupts = <0 160 0x4>;
};
- pcie@340 {
+ pcie1: pcie@340 {
compatible = "fsl,ls1043a-pcie";
reg = <0x00 0x0340 0x0 0x0010 /* controller
registers */
0x40 0x 0x0 0x2000>; /*
configuration space */
@@ -840,7 +840,7 @@
status = "disabled";
};
- pcie@350 {
+ pcie2: pcie@350 {
compatible = "fsl,ls1043a-pcie";
reg = <0x00 0x0350 0x0 0x0010 /* controller
registers */
0x48 0x 0x0 0x2000>; /*
configuration space */
@@ -866,7 +866,7 @@
status = "disabled";
};
- pcie@360 {
+ pcie3: pcie@360 {
compatible = "fsl,ls1043a-pcie";
reg = <0x00 0x0360 0x0 0x0010 /* controller
registers */
0x50 0x 0x0 0x2000>; /*
configuration space
RE: [PATCH 2/3] phy: cadence: salvo: Constify cdns_nxp_sequence_pair
>
> cdns_nxp_sequence_pair[] are never modified and can be made const to allow
> the compiler to put them in read-only memory.
>
> Signed-off-by: Rikard Falkeborn
Reviewed-by: Peter Chen
Peter
> ---
> drivers/phy/cadence/phy-cadence-salvo.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/phy/cadence/phy-cadence-salvo.c
> b/drivers/phy/cadence/phy-cadence-salvo.c
> index 8c33d3215f2d..88e239adc3b8 100644
> --- a/drivers/phy/cadence/phy-cadence-salvo.c
> +++ b/drivers/phy/cadence/phy-cadence-salvo.c
> @@ -97,7 +97,7 @@ struct cdns_reg_pairs {
>
> struct cdns_salvo_data {
> u8 reg_offset_shift;
> - struct cdns_reg_pairs *init_sequence_val;
> + const struct cdns_reg_pairs *init_sequence_val;
> u8 init_sequence_length;
> };
>
> @@ -126,7 +126,7 @@ static void cdns_salvo_write(struct cdns_salvo_phy
> *salvo_phy,
> * Below bringup sequence pair are from Cadence PHY's User Guide
> * and NXP platform tuning results.
> */
> -static struct cdns_reg_pairs cdns_nxp_sequence_pair[] = {
> +static const struct cdns_reg_pairs cdns_nxp_sequence_pair[] = {
> {0x0830, PHY_PMA_CMN_CTRL1},
> {0x0010, TB_ADDR_CMN_DIAG_HSCLK_SEL},
> {0x00f0, TB_ADDR_CMN_PLL0_VCOCAL_INIT_TMR},
> @@ -217,7 +217,7 @@ static int cdns_salvo_phy_init(struct phy *phy)
> return ret;
>
> for (i = 0; i < data->init_sequence_length; i++) {
> - struct cdns_reg_pairs *reg_pair = data->init_sequence_val + i;
> + const struct cdns_reg_pairs *reg_pair = data->init_sequence_val
> + i;
>
> cdns_salvo_write(salvo_phy, reg_pair->off, reg_pair->val);
> }
> --
> 2.28.0
Re: [PATCH v2 3/3] ARM: dts: add Plymovent M2M board
On Fri, Sep 11, 2020 at 08:03:12AM +0200, Marco Felsch wrote: > On 20-09-11 07:09, Oleksij Rempel wrote: > > Plymovent M2M is a control interface produced for the Plymovent filter > > systems. > > > > Signed-off-by: David Jander > > Signed-off-by: Oleksij Rempel > > --- > > arch/arm/boot/dts/Makefile | 1 + > > arch/arm/boot/dts/imx6dl-plym2m.dts | 394 > > 2 files changed, 395 insertions(+) > > create mode 100644 arch/arm/boot/dts/imx6dl-plym2m.dts > > > > diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile > > index 4572db3fa5ae..3c3811fd8613 100644 > > --- a/arch/arm/boot/dts/Makefile > > +++ b/arch/arm/boot/dts/Makefile > > @@ -455,6 +455,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \ > > imx6dl-pico-hobbit.dtb \ > > imx6dl-pico-nymph.dtb \ > > imx6dl-pico-pi.dtb \ > > + imx6dl-plym2m.dtb \ > > imx6dl-prtrvt.dtb \ > > imx6dl-prtvt7.dtb \ > > imx6dl-rex-basic.dtb \ > > diff --git a/arch/arm/boot/dts/imx6dl-plym2m.dts > > b/arch/arm/boot/dts/imx6dl-plym2m.dts > > new file mode 100644 > > index ..4f96e05aa03f > > --- /dev/null > > +++ b/arch/arm/boot/dts/imx6dl-plym2m.dts > > @@ -0,0 +1,394 @@ > > +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT > > +// SPDX-FileCopyrightText: 2014 Protonic Holland > > +// SPDX-FileCopyrightText: 2020 Oleksij Rempel , > > Pengutronix > ^ > @shawn: I saw a few patches adding these tags. Are they used in the near > future? I'm not sure. I haven't seen this in Documentation/process/license-rules.rst, nor the discussion around this. Shawn
[PATCH] tee/tee_shm.c: Fix error handling path
When shm->num_pages <= 0, we should avoid calling
release_registered_pages() in error handling path.
Signed-off-by: Souptick Joarder
Cc: John Hubbard
---
drivers/tee/tee_shm.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/tee/tee_shm.c b/drivers/tee/tee_shm.c
index 00472f5..e517d9f 100644
--- a/drivers/tee/tee_shm.c
+++ b/drivers/tee/tee_shm.c
@@ -260,8 +260,7 @@ struct tee_shm *tee_shm_register(struct tee_context *ctx,
unsigned long addr,
rc = get_kernel_pages(kiov, num_pages, 0, shm->pages);
kfree(kiov);
}
- if (rc > 0)
- shm->num_pages = rc;
+ shm->num_pages = rc;
if (rc != num_pages) {
if (rc >= 0)
rc = -ENOMEM;
@@ -309,7 +308,9 @@ struct tee_shm *tee_shm_register(struct tee_context *ctx,
unsigned long addr,
idr_remove(>idr, shm->id);
mutex_unlock(>mutex);
}
- release_registered_pages(shm);
+ if (shm->pages && (shm->num_pages > 0))
+ release_registered_pages(shm);
+
}
kfree(shm);
teedev_ctx_put(ctx);
--
1.9.1
[ANNOUNCE] 4.9.236-rt154
Hello RT-list! I'm pleased to announce the 4.9.236-rt154 stable release. You can get this release via the git tree at: git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git branch: v4.9-rt Head SHA1: d81b19f462cdf108afa79e7f7717190a280a299e Or to build 4.9.236-rt154 directly, the following patches should be applied: https://www.kernel.org/pub/linux/kernel/v4.x/linux-4.9.tar.xz https://www.kernel.org/pub/linux/kernel/v4.x/patch-4.9.236.xz https://www.kernel.org/pub/linux/kernel/projects/rt/4.9/patch-4.9.236-rt154.patch.xz You can also build from 4.9.235-rt153 by applying the incremental patch: https://www.kernel.org/pub/linux/kernel/projects/rt/4.9/incr/patch-4.9.235-rt153-rt154.patch.xz Enjoy! Clark
Re: [PATCH] driver/pci: reduce the single block time in pci_read_config
Hi, Bjorn
On Thu, 10 Sep 2020 at 09:59, Bjorn Helgaas wrote:
>
> On Thu, Sep 10, 2020 at 09:54:02AM +0800, Jiang Biao wrote:
> > Hi,
> >
> > On Thu, 10 Sep 2020 at 09:25, Bjorn Helgaas wrote:
> > >
> > > On Mon, Aug 24, 2020 at 01:20:25PM +0800, Jiang Biao wrote:
> > > > From: Jiang Biao
> > > >
> > > > pci_read_config() could block several ms in kernel space, mainly
> > > > caused by the while loop to call pci_user_read_config_dword().
> > > > Singel pci_user_read_config_dword() loop could consume 130us+,
> > > > |pci_user_read_config_dword() {
> > > > | _raw_spin_lock_irq() {
> > > > ! 136.698 us |native_queued_spin_lock_slowpath();
> > > > ! 137.582 us | }
> > > > | pci_read() {
> > > > |raw_pci_read() {
> > > > | pci_conf1_read() {
> > > > 0.230 us|_raw_spin_lock_irqsave();
> > > > 0.035 us|_raw_spin_unlock_irqrestore();
> > > > 8.476 us| }
> > > > 8.790 us|}
> > > > 9.091 us| }
> > > > ! 147.263 us |}
> > > > and dozens of the loop could consume ms+.
> > > >
> > > > If we execute some lspci commands concurrently, ms+ scheduling
> > > > latency could be detected.
> > > >
> > > > Add scheduling chance in the loop to improve the latency.
> > >
> > > Thanks for the patch, this makes a lot of sense.
> > >
> > > Shouldn't we do the same in pci_write_config()?
> > Yes, IMHO, that could be helpful too.
>
> If it's feasible, it would be nice to actually verify that it makes a
> difference. I know config writes should be faster than reads, but
> they're certainly not as fast as a CPU can pump out data, so there
> must be *some* mechanism that slows the CPU down.
>
> Bjorn
We failed to build a test case to produce the latency by setpci command,
AFAIU, setpci could be much less frequently realistically used than lspci.
So, the latency from pci_write_config() path could not be verified for now,
could we apply this patch alone to erase the verified latency introduced
by pci_read_config() path? :)
Thanks a lot.
Regards,
Jiang
Re: [PATCH] checkpatch: Allow not using -f with files that are in git
On Mon, 2020-08-24 at 17:09 -0700, Joe Perches wrote:
> If a file exists in git and checkpatch is used without the -f
> flag for scanning a file, then checkpatch will scan the file
> assuming it's a patch and emit:
>
> ERROR: Does not appear to be a unified-diff format patch
>
> Change the behavior to assume the -f flag if the file exists
> in git.
Andrew? ping?
> Signed-off-by: Joe Perches
> ---
> scripts/checkpatch.pl | 14 ++
> 1 file changed, 14 insertions(+)
>
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index 79fc357b18cd..cdee7cfadc11 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -976,6 +976,16 @@ sub seed_camelcase_includes {
> }
> }
>
> +sub git_is_single_file {
> + my ($filename) = @_;
> +
> + return 0 if ((which("git") eq "") || !(-e "$gitroot"));
> +
> + my $output = `${git_command} ls-files -- $filename`;
> + my $count = $output =~ tr/\n//;
> + return $count eq 1 && $output =~ m{^${filename}$};
> +}
> +
> sub git_commit_info {
> my ($commit, $id, $desc) = @_;
>
> @@ -1049,6 +1059,9 @@ my $vname;
> $allow_c99_comments = !defined $ignore_type{"C99_COMMENT_TOLERANCE"};
> for my $filename (@ARGV) {
> my $FILE;
> + my $is_git_file = git_is_single_file($filename);
> + my $oldfile = $file;
> + $file = 1 if ($is_git_file);
> if ($git) {
> open($FILE, '-|', "git format-patch -M --stdout -1 $filename")
> ||
> die "$P: $filename: git format-patch failed - $!\n";
> @@ -1093,6 +1106,7 @@ for my $filename (@ARGV) {
> @modifierListFile = ();
> @typeListFile = ();
> build_types();
> + $file = $oldfile if ($is_git_file);
> }
>
> if (!$quiet) {
>
Re: [PATCH] clk: qcom: gcc-msm8939: remove defined but not used variables
On Thu 10 Sep 20:37 CDT 2020, Jason Yan wrote:
> This addresses the following gcc warning with "make W=1":
>
> drivers/clk/qcom/gcc-msm8939.c:610:32: warning:
> ‘gcc_xo_gpll6_gpll0a_map’ defined but not used
> [-Wunused-const-variable=]
> static const struct parent_map gcc_xo_gpll6_gpll0a_map[] = {
> ^~~
> drivers/clk/qcom/gcc-msm8939.c:598:32: warning: ‘gcc_xo_gpll6_gpll0_map’
> defined but not used [-Wunused-const-variable=]
> static const struct parent_map gcc_xo_gpll6_gpll0_map[] = {
> ^~
>
Reviewed-by: Bjorn Andersson
> Reported-by: Hulk Robot
> Signed-off-by: Jason Yan
> ---
> drivers/clk/qcom/gcc-msm8939.c | 12
> 1 file changed, 12 deletions(-)
>
> diff --git a/drivers/clk/qcom/gcc-msm8939.c b/drivers/clk/qcom/gcc-msm8939.c
> index 778354f82b1e..39ebb443ae3d 100644
> --- a/drivers/clk/qcom/gcc-msm8939.c
> +++ b/drivers/clk/qcom/gcc-msm8939.c
> @@ -595,24 +595,12 @@ static const struct clk_parent_data
> gcc_xo_gpll1_emclk_sleep_parent_data[] = {
> { .fw_name = "sleep_clk", .name = "sleep_clk" },
> };
>
> -static const struct parent_map gcc_xo_gpll6_gpll0_map[] = {
> - { P_XO, 0 },
> - { P_GPLL6, 1 },
> - { P_GPLL0, 2 },
> -};
> -
> static const struct clk_parent_data gcc_xo_gpll6_gpll0_parent_data[] = {
> { .fw_name = "xo" },
> { .hw = _vote.hw },
> { .hw = _vote.hw },
> };
>
> -static const struct parent_map gcc_xo_gpll6_gpll0a_map[] = {
> - { P_XO, 0 },
> - { P_GPLL6, 1 },
> - { P_GPLL0_AUX, 2 },
> -};
> -
> static const struct clk_parent_data gcc_xo_gpll6_gpll0a_parent_data[] = {
> { .fw_name = "xo" },
> { .hw = _vote.hw },
> --
> 2.25.4
>
Re: [RFC PATCH v1 1/1] sched/fair: select idle cpu from idle cpumask in sched domain
Hi, Aubrey
On Fri, 11 Sep 2020 at 23:48, Aubrey Li wrote:
>
> Added idle cpumask to track idle cpus in sched domain. When a CPU
> enters idle, its corresponding bit in the idle cpumask will be set,
> and when the CPU exits idle, its bit will be cleared.
>
> When a task wakes up to select an idle cpu, scanning idle cpumask
> has low cost than scanning all the cpus in last level cache domain,
> especially when the system is heavily loaded.
>
> Signed-off-by: Aubrey Li
> ---
> include/linux/sched/topology.h | 13 +
> kernel/sched/fair.c| 4 +++-
> kernel/sched/topology.c| 2 +-
> 3 files changed, 17 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/sched/topology.h b/include/linux/sched/topology.h
> index fb11091129b3..43a641d26154 100644
> --- a/include/linux/sched/topology.h
> +++ b/include/linux/sched/topology.h
> @@ -65,8 +65,21 @@ struct sched_domain_shared {
> atomic_tref;
> atomic_tnr_busy_cpus;
> int has_idle_cores;
> + /*
> +* Span of all idle CPUs in this domain.
> +*
> +* NOTE: this field is variable length. (Allocated dynamically
> +* by attaching extra space to the end of the structure,
> +* depending on how many CPUs the kernel has booted up with)
> +*/
> + unsigned long idle_cpus_span[];
> };
>
> +static inline struct cpumask *sds_idle_cpus(struct sched_domain_shared *sds)
> +{
> + return to_cpumask(sds->idle_cpus_span);
> +}
> +
> struct sched_domain {
> /* These fields must be setup */
> struct sched_domain __rcu *parent; /* top domain must be null
> terminated */
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 6b3b59cc51d6..3b6f8a3589be 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -6136,7 +6136,7 @@ static int select_idle_cpu(struct task_struct *p,
> struct sched_domain *sd, int t
>
> time = cpu_clock(this);
>
> - cpumask_and(cpus, sched_domain_span(sd), p->cpus_ptr);
> + cpumask_and(cpus, sds_idle_cpus(sd->shared), p->cpus_ptr);
Is the sds_idle_cpus() always empty if nohz=off?
Do we need to initialize the idle_cpus_span with sched_domain_span(sd)?
>
> for_each_cpu_wrap(cpu, cpus, target) {
> if (!--nr)
> @@ -10182,6 +10182,7 @@ static void set_cpu_sd_state_busy(int cpu)
> sd->nohz_idle = 0;
>
> atomic_inc(>shared->nr_busy_cpus);
> + cpumask_clear_cpu(cpu, sds_idle_cpus(sd->shared));
> unlock:
> rcu_read_unlock();
> }
> @@ -10212,6 +10213,7 @@ static void set_cpu_sd_state_idle(int cpu)
> sd->nohz_idle = 1;
>
> atomic_dec(>shared->nr_busy_cpus);
> + cpumask_set_cpu(cpu, sds_idle_cpus(sd->shared));
This only works when entering/exiting tickless mode? :)
Why not update idle_cpus_span during tick_nohz_idle_enter()/exit()?
Thx.
Regards,
Jiang
> unlock:
> rcu_read_unlock();
> }
> diff --git a/kernel/sched/topology.c b/kernel/sched/topology.c
> index 9079d865a935..92d0aeef86bf 100644
> --- a/kernel/sched/topology.c
> +++ b/kernel/sched/topology.c
> @@ -1769,7 +1769,7 @@ static int __sdt_alloc(const struct cpumask *cpu_map)
>
> *per_cpu_ptr(sdd->sd, j) = sd;
>
> - sds = kzalloc_node(sizeof(struct sched_domain_shared),
> + sds = kzalloc_node(sizeof(struct sched_domain_shared)
> + cpumask_size(),
> GFP_KERNEL, cpu_to_node(j));
> if (!sds)
> return -ENOMEM;
> --
> 2.25.1
>
Re: [PATCH 3/3] spi: spi-geni-qcom: Slightly optimize setup of bidirectional xfters
Hi Douglas,
I love your patch! Yet something to improve:
[auto build test ERROR on spi/for-next]
[also build test ERROR on v5.9-rc4 next-20200911]
[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/Douglas-Anderson/spi-spi-geni-qcom-Use-the-FIFO-even-more/20200913-050928
base: https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
config: x86_64-randconfig-a002-20200913 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project
3170d54842655d6d936aae32b7d0bc92fce7f22e)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross 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 >>):
>> drivers/spi/spi-geni-qcom.c:385:2: error: implicit declaration of function
>> '__iowmb' [-Werror,-Wimplicit-function-declaration]
__iowmb();
^
1 error generated.
#
https://github.com/0day-ci/linux/commit/4458adf4007926cfaaa505b54a83059c9ba813ad
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Douglas-Anderson/spi-spi-geni-qcom-Use-the-FIFO-even-more/20200913-050928
git checkout 4458adf4007926cfaaa505b54a83059c9ba813ad
vim +/__iowmb +385 drivers/spi/spi-geni-qcom.c
334
335 static void setup_fifo_xfer(struct spi_transfer *xfer,
336 struct spi_geni_master *mas,
337 u16 mode, struct spi_master *spi)
338 {
339 u32 m_cmd = 0;
340 u32 len;
341 struct geni_se *se = >se;
342 int ret;
343
344 /*
345 * Ensure that our interrupt handler isn't still running from
some
346 * prior command before we start messing with the hardware
behind
347 * its back. We don't need to _keep_ the lock here since we're
only
348 * worried about racing with out interrupt handler. The SPI
core
349 * already handles making sure that we're not trying to do two
350 * transfers at once or setting a chip select and doing a
transfer
351 * concurrently.
352 *
353 * NOTE: we actually _can't_ hold the lock here because
possibly we
354 * might call clk_set_rate() which needs to be able to sleep.
355 */
356 spin_lock_irq(>lock);
357 spin_unlock_irq(>lock);
358
359 if (xfer->bits_per_word != mas->cur_bits_per_word) {
360 spi_setup_word_len(mas, mode, xfer->bits_per_word);
361 mas->cur_bits_per_word = xfer->bits_per_word;
362 }
363
364 /* Speed and bits per word can be overridden per transfer */
365 ret = geni_spi_set_clock_and_bw(mas, xfer->speed_hz);
366 if (ret)
367 return;
368
369 mas->tx_rem_bytes = 0;
370 mas->rx_rem_bytes = 0;
371
372 if (!(mas->cur_bits_per_word % MIN_WORD_LEN))
373 len = xfer->len * BITS_PER_BYTE /
mas->cur_bits_per_word;
374 else
375 len = xfer->len / (mas->cur_bits_per_word /
BITS_PER_BYTE + 1);
376 len &= TRANS_LEN_MSK;
377
378 mas->cur_xfer = xfer;
379
380 /*
381 * Factor out the __iowmb() so that we can use writel_relaxed()
for
382 * both writes below and thus only incur the overhead once even
if
383 * we execute both of them.
384 */
> 385 __iowmb();
386
387 if (xfer->tx_buf) {
388 m_cmd |= SPI_TX_ONLY;
389 mas->tx_rem_bytes = xfer->len;
390 writel_relaxed(len, se->base + SE_SPI_TX_TRANS_LEN);
391 }
392 if (xfer->rx_buf) {
393 m_cmd |= SPI_RX_ONLY;
394 writel_relaxed(len, se->base + SE_SPI_RX_TRANS_LEN);
395 mas->rx_rem_bytes = xfer->len;
396 }
397
398 /*
399 * Lock around right before we start the transfer since our
400 * interrupt could come in at any time now.
401 */
402 spin_lock_irq(>lock);
403 geni_se_setup_m_cmd(se, m_cmd, FRAGMENTATION);
404
405 /*
406 *
Re: [PATCH v2 1/2] PM / Domains: Add GENPD_FLAG_NO_SUSPEND/RESUME flags
On Thu 10 Sep 03:18 CDT 2020, Ulf Hansson wrote: > On Thu, 10 Sep 2020 at 09:23, Sibi Sankar wrote: > > > > On 2020-08-25 23:23, Bjorn Andersson wrote: > > > On Tue 25 Aug 02:20 CDT 2020, Stephen Boyd wrote: > > >> Quoting Bjorn Andersson (2020-08-24 09:42:12) > > >> > On Fri 21 Aug 14:41 PDT 2020, Stephen Boyd wrote: > > > [..] > > >> > > I find it odd that this is modeled as a power domain instead of some > > >> > > Qualcomm specific message that the remoteproc driver sends to AOSS. > > >> > > Is > > >> > > there some sort of benefit the driver gets from using the power > > >> > > domain > > >> > > APIs for this vs. using a custom API? > > >> > > > >> > We need to send "up" and "down" notifications and this needs to happen > > >> > at the same time as other standard resources are enabled/disabled. > > >> > > > >> > Further more, at the time the all resources handled by the downstream > > >> > driver was either power-domains (per above understanding) or clocks, so > > >> > it made sense to me not to spin up a custom API. > > >> > > > >> > > >> So the benefit is not spinning up a custom API? I'm not Ulf, but it > > >> looks like this is hard to rationalize about as a power domain. It > > >> doesn't have any benefit to model it this way besides to make it > > >> possible to turn on with other power domains. > > >> > > >> This modem remoteproc drivers isn't SoC agnostic anyway, it relies on > > >> SMEM APIs, so standing up another small qmp_remoteproc_booted() and > > >> qmp_remoteproc_shutdown() API would avoid adding a genpd flag here > > >> that > > >> probably will never be used outside of this corner-case. There is also > > >> some get/put EPROBE_DEFER sort of logic to implement, but otherwise it > > >> would be possible to do this outside of power domains, and that seems > > >> better given that this isn't really a power domain to start with. > > > > > > In later platforms a few new users of the AOSS communication interface > > > is introduced that certainly doesn't fit any existing API/framework in > > > the kernel. So the plan was to pretty much expose qmp_send() to these > > > drivers. > > > > > > My worry with using this interface is that we'll probably have to come > > > up with some DT binding pieces and probably we'll end up adding yet > > > another piece of hard coded information in the remoteproc drivers. > > > > > > But I'm not against us doing this work in favor of not having to > > > introduce a one-off for this corner case. > > > > Bjorn/Stephen, > > > > So the consensus is to stop modelling > > aoss load_state as pds and expose qmp_send > > to drivers? > > Would that mean qmp_send would have to be called from generic drivers? > Then, please no. We want to keep drivers portable. > No, this is only called from Qualcomm specific drivers. So I'm okay with that approach. Regards, Bjorn
Re: [PATCH v3 6/8] iommu/arm-smmu: Add impl hook for inherit boot mappings
On Fri 11 Sep 12:13 CDT 2020, Robin Murphy wrote:
> On 2020-09-04 16:55, Bjorn Andersson wrote:
> > Add a new operation to allow platform implementations to inherit any
> > stream mappings from the boot loader.
>
> Is there a reason we need an explicit step for this? The aim of the
> cfg_probe hook is that the SMMU software state should all be set up by then,
> and you can mess about with it however you like before arm_smmu_reset()
> actually commits anything to hardware. I would have thought you could
> permanently steal a context bank, configure it as your bypass hole, read out
> the previous SME configuration and tweak smmu->smrs and smmu->s2crs
> appropriately all together "invisibly" at that point.
I did this because as of 6a79a5a3842b ("iommu/arm-smmu: Call
configuration impl hook before consuming features") we no longer have
setup pgsize_bitmap as we hit cfg_probe, which means that I need to
replicate this logic to set up the iommu_domain.
If I avoid setting up an iommu_domain for the identity context, as you
request in patch 8, this shouldn't be needed anymore.
> If that can't work, I'm very curious as to what I've overlooked.
>
I believe that will work, I will rework the patches and try it out.
Thanks,
Bjorn
> Robin.
>
> > Signed-off-by: Bjorn Andersson
> > ---
> >
> > Changes since v2:
> > - New patch/interface
> >
> > drivers/iommu/arm/arm-smmu/arm-smmu.c | 11 ++-
> > drivers/iommu/arm/arm-smmu/arm-smmu.h | 6 ++
> > 2 files changed, 12 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c
> > b/drivers/iommu/arm/arm-smmu/arm-smmu.c
> > index eb5c6ca5c138..4c4d302cd747 100644
> > --- a/drivers/iommu/arm/arm-smmu/arm-smmu.c
> > +++ b/drivers/iommu/arm/arm-smmu/arm-smmu.c
> > @@ -85,11 +85,6 @@ static inline void arm_smmu_rpm_put(struct
> > arm_smmu_device *smmu)
> > pm_runtime_put_autosuspend(smmu->dev);
> > }
> > -static struct arm_smmu_domain *to_smmu_domain(struct iommu_domain *dom)
> > -{
> > - return container_of(dom, struct arm_smmu_domain, domain);
> > -}
> > -
> > static struct platform_driver arm_smmu_driver;
> > static struct iommu_ops arm_smmu_ops;
> > @@ -2188,6 +2183,12 @@ static int arm_smmu_device_probe(struct
> > platform_device *pdev)
> > if (err)
> > return err;
> > + if (smmu->impl->inherit_mappings) {
> > + err = smmu->impl->inherit_mappings(smmu);
> > + if (err)
> > + return err;
> > + }
> > +
> > if (smmu->version == ARM_SMMU_V2) {
> > if (smmu->num_context_banks > smmu->num_context_irqs) {
> > dev_err(dev,
> > diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.h
> > b/drivers/iommu/arm/arm-smmu/arm-smmu.h
> > index 235d9a3a6ab6..f58164976e74 100644
> > --- a/drivers/iommu/arm/arm-smmu/arm-smmu.h
> > +++ b/drivers/iommu/arm/arm-smmu/arm-smmu.h
> > @@ -378,6 +378,11 @@ struct arm_smmu_domain {
> > struct iommu_domain domain;
> > };
> > +static inline struct arm_smmu_domain *to_smmu_domain(struct iommu_domain
> > *dom)
> > +{
> > + return container_of(dom, struct arm_smmu_domain, domain);
> > +}
> > +
> > struct arm_smmu_master_cfg {
> > struct arm_smmu_device *smmu;
> > s16 smendx[];
> > @@ -442,6 +447,7 @@ struct arm_smmu_impl {
> > int (*alloc_context_bank)(struct arm_smmu_domain *smmu_domain,
> > struct arm_smmu_device *smmu,
> > struct device *dev, int start);
> > + int (*inherit_mappings)(struct arm_smmu_device *smmu);
> > };
> > #define INVALID_SMENDX-1
> >
Re: [PATCH] drm/msm/adreno: fix probe without iommu
On Fri 11 Sep 11:08 CDT 2020, Luca Weiss wrote:
> The function iommu_domain_alloc returns NULL on platforms without IOMMU
> such as msm8974. This resulted in PTR_ERR(-ENODEV) being assigned to
> gpu->aspace so the correct code path wasn't taken.
>
> Fixes: ccac7ce373c1 ("drm/msm: Refactor address space initialization")
> Signed-off-by: Luca Weiss
Reviewed-by: Bjorn Andersson
> ---
> drivers/gpu/drm/msm/adreno/adreno_gpu.c | 10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> index 862dd35b27d3..6e8bef1a9ea2 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> @@ -189,10 +189,16 @@ struct msm_gem_address_space *
> adreno_iommu_create_address_space(struct msm_gpu *gpu,
> struct platform_device *pdev)
> {
> - struct iommu_domain *iommu = iommu_domain_alloc(_bus_type);
> - struct msm_mmu *mmu = msm_iommu_new(>dev, iommu);
> + struct iommu_domain *iommu;
> + struct msm_mmu *mmu;
> struct msm_gem_address_space *aspace;
>
> + iommu = iommu_domain_alloc(_bus_type);
> + if (!iommu)
> + return NULL;
> +
> + mmu = msm_iommu_new(>dev, iommu);
> +
> aspace = msm_gem_address_space_create(mmu, "gpu", SZ_16M,
> 0x - SZ_16M);
>
> --
> 2.28.0
>
Re: [PATCH 1/3] spi: spi-geni-qcom: Use the FIFO even more
On Sat 12 Sep 20:11 CDT 2020, Doug Anderson wrote:
> Hi,
>
> On Sat, Sep 12, 2020 at 3:53 PM Bjorn Andersson
> wrote:
> >
> > On Sat 12 Sep 16:07 CDT 2020, Douglas Anderson wrote:
> >
> > > In commit 902481a78ee4 ("spi: spi-geni-qcom: Actually use our FIFO") I
> > > explained that the maximum size we could program the FIFO was
> > > "mas->tx_fifo_depth - 3" but that I chose "mas->tx_fifo_depth()"
> > > because I was worried about decreased bandwidth.
> > >
> > > Since that time:
> > > * All the interconnect patches have landed, making things run at the
> > > proper speed.
> > > * I've done more measurements.
> > >
> > > This lets me confirm that there's really no downside of using the FIFO
> > > more. Specifically I did "flashrom -p ec -r /tmp/foo.bin" on a
> > > Chromebook and averaged over several runs.
> >
> > Wouldn't there be a downside in the form of setting the watermark that
> > close to the full FIFO we have less room for being late handling the
> > interrupt? Or is there some mechanism involved that will prevent
> > the FIFO from being overrun?
>
> Yeah, I had that worry too, but, as described in 902481a78ee4 ("spi:
> spi-geni-qcom: Actually use our FIFO"), it doesn't seem to be a
> problem. From that commit: "We are the SPI master, so it makes sense
> that there would be no problems with overruns, the master should just
> stop clocking."
>
Actually read the message of the linked commit now. I share your view
that this indicates that the controller does something wrt the clocking
to handle this case.
Change itself looks good, so:
Reviewed-by: Bjorn Andersson
Regards,
Bjorn
Re: [PATCH] ARM: imx7ulp: enable cpufreq
On Fri, Sep 11, 2020 at 11:31:44AM +0800, peng@nxp.com wrote: > From: Peng Fan > > Enable cpufreq for i.MX7ULP when imx cpufreq dt driver enabled. > > Signed-off-by: Peng Fan Applied, thanks.
Re: [PATCH 1/4] dt-bindings: fsl: add i.MX7ULP PMC binding doc
On Fri, Sep 11, 2020 at 07:19:59AM +, Aisheng Dong wrote: > > From: Peng Fan > > Sent: Friday, September 11, 2020 11:31 AM > > > > Add i.MX7ULP Power Management Controller binding doc > > > > Signed-off-by: Peng Fan > > --- > > .../bindings/arm/freescale/imx7ulp-pmc.yaml | 33 +++ > > 1 file changed, 33 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/arm/freescale/imx7ulp-pmc.yaml > > I wonder if we can merge it into the exist imx7ulp pm binding doc. > Documentation/devicetree/bindings/arm/freescale/fsl,imx7ulp-pm.yaml +1 Shawn
Re: [PATCH net-next v2 7/7] net: ipa: do not enable GSI interrupt for wakeup
On Fri 11 Sep 19:45 CDT 2020, Alex Elder wrote:
> We now trigger a system resume when we receive an IPA SUSPEND
> interrupt. We should *not* wake up on GSI interrupts.
>
Reviewed-by: Bjorn Andersson
> Signed-off-by: Alex Elder
> ---
> drivers/net/ipa/gsi.c | 17 -
> drivers/net/ipa/gsi.h | 1 -
> 2 files changed, 4 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/net/ipa/gsi.c b/drivers/net/ipa/gsi.c
> index 0e63d35320aaf..cb75f7d540571 100644
> --- a/drivers/net/ipa/gsi.c
> +++ b/drivers/net/ipa/gsi.c
> @@ -1987,31 +1987,26 @@ int gsi_init(struct gsi *gsi, struct platform_device
> *pdev, bool prefetch,
> }
> gsi->irq = irq;
>
> - ret = enable_irq_wake(gsi->irq);
> - if (ret)
> - dev_warn(dev, "error %d enabling gsi wake irq\n", ret);
> - gsi->irq_wake_enabled = !ret;
> -
> /* Get GSI memory range and map it */
> res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "gsi");
> if (!res) {
> dev_err(dev, "DT error getting \"gsi\" memory property\n");
> ret = -ENODEV;
> - goto err_disable_irq_wake;
> + goto err_free_irq;
> }
>
> size = resource_size(res);
> if (res->start > U32_MAX || size > U32_MAX - res->start) {
> dev_err(dev, "DT memory resource \"gsi\" out of range\n");
> ret = -EINVAL;
> - goto err_disable_irq_wake;
> + goto err_free_irq;
> }
>
> gsi->virt = ioremap(res->start, size);
> if (!gsi->virt) {
> dev_err(dev, "unable to remap \"gsi\" memory\n");
> ret = -ENOMEM;
> - goto err_disable_irq_wake;
> + goto err_free_irq;
> }
>
> ret = gsi_channel_init(gsi, prefetch, count, data, modem_alloc);
> @@ -2025,9 +2020,7 @@ int gsi_init(struct gsi *gsi, struct platform_device
> *pdev, bool prefetch,
>
> err_iounmap:
> iounmap(gsi->virt);
> -err_disable_irq_wake:
> - if (gsi->irq_wake_enabled)
> - (void)disable_irq_wake(gsi->irq);
> +err_free_irq:
> free_irq(gsi->irq, gsi);
>
> return ret;
> @@ -2038,8 +2031,6 @@ void gsi_exit(struct gsi *gsi)
> {
> mutex_destroy(>mutex);
> gsi_channel_exit(gsi);
> - if (gsi->irq_wake_enabled)
> - (void)disable_irq_wake(gsi->irq);
> free_irq(gsi->irq, gsi);
> iounmap(gsi->virt);
> }
> diff --git a/drivers/net/ipa/gsi.h b/drivers/net/ipa/gsi.h
> index 061312773df09..3f9f29d531c43 100644
> --- a/drivers/net/ipa/gsi.h
> +++ b/drivers/net/ipa/gsi.h
> @@ -150,7 +150,6 @@ struct gsi {
> struct net_device dummy_dev;/* needed for NAPI */
> void __iomem *virt;
> u32 irq;
> - bool irq_wake_enabled;
> u32 channel_count;
> u32 evt_ring_count;
> struct gsi_channel channel[GSI_CHANNEL_COUNT_MAX];
> --
> 2.20.1
>
Re: [PATCH 1/4] dt-bindings: fsl: add i.MX7ULP PMC binding doc
On Fri, Sep 11, 2020 at 07:45:20AM +, Peng Fan wrote: > > b/Documentation/devicetree/bindings/arm/freescale/imx7ulp-pmc.yaml > > > @@ -0,0 +1,33 @@ > > > +# SPDX-License-Identifier: GPL-2.0 > > > +%YAML 1.2 > > > +--- > > > +$id: http://devicetree.org/schemas/arm/freescale/imx7ulp-pmc.yaml# > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > + > > > +title: i.MX7ULP Power Management Controller(PMC) Device Tree Bindings > > > + > > > +maintainers: > > > + - Peng Fan > > > + > > > +properties: > > > + compatible: > > > +items: > > > + - enum: > > > + - fsl,imx7ulp-pmc-m4 > > > + - fsl,imx7ulp-pmc-a7 > > > > Can we change to the exist naming pattern which also align with HW > > reference manual? > > e.g. > > fsl,imx7ulp-pmc0 > > fsl,imx7ulp-pmc1 > > This was rejected by Shawn before. > https://patchwork.kernel.org/patch/11390591/ Oh, I'm fine with the naming if pmc0 and pmc1 are different HW block rather than two instances of the same block. Shawn
Re: [PATCH net-next v2 6/7] net: ipa: enable wakeup on IPA interrupt
On Fri 11 Sep 19:45 CDT 2020, Alex Elder wrote:
> Now that we handle wakeup interrupts properly, arrange for the IPA
> interrupt to be treated as a wakeup interrupt.
>
Reviewed-by: Bjorn Andersson
> Signed-off-by: Alex Elder
> ---
> drivers/net/ipa/ipa_interrupt.c | 14 ++
> 1 file changed, 14 insertions(+)
>
> diff --git a/drivers/net/ipa/ipa_interrupt.c b/drivers/net/ipa/ipa_interrupt.c
> index 90353987c45fc..cc1ea28f7bc2e 100644
> --- a/drivers/net/ipa/ipa_interrupt.c
> +++ b/drivers/net/ipa/ipa_interrupt.c
> @@ -237,8 +237,16 @@ struct ipa_interrupt *ipa_interrupt_setup(struct ipa
> *ipa)
> goto err_kfree;
> }
>
> + ret = enable_irq_wake(irq);
> + if (ret) {
> + dev_err(dev, "error %d enabling wakeup for \"ipa\" IRQ\n", ret);
> + goto err_free_irq;
> + }
> +
> return interrupt;
>
> +err_free_irq:
> + free_irq(interrupt->irq, interrupt);
> err_kfree:
> kfree(interrupt);
>
> @@ -248,6 +256,12 @@ struct ipa_interrupt *ipa_interrupt_setup(struct ipa
> *ipa)
> /* Tear down the IPA interrupt framework */
> void ipa_interrupt_teardown(struct ipa_interrupt *interrupt)
> {
> + struct device *dev = >ipa->pdev->dev;
> + int ret;
> +
> + ret = disable_irq_wake(interrupt->irq);
> + if (ret)
> + dev_err(dev, "error %d disabling \"ipa\" IRQ wakeup\n", ret);
> free_irq(interrupt->irq, interrupt);
> kfree(interrupt);
> }
> --
> 2.20.1
>
Re: [PATCH 1/6] of: Add basic infrastructure to create early probe arrays
On Sat 12 Sep 07:51 CDT 2020, Marc Zyngier wrote:
> We currently probe interrupt controller and timers that need
> to be available very early using an infratstructure that creates
s/infratstructure/infrastructure/
> struct of_device_id instances in a special section. These are
> individual structures that are ultimately collated by the linker.
>
> In order to facilitate further use of this infrastructure for
> drivers that can either be built modular or as an early driver,
> let's add a couple of helpers that will make it look like a
> "normal" device_id array, like this:
>
> _OF_DECLARE_ARRAY_START(table, name)
> _OF_DECLARE_ELMT("compat-1", probe, type)
> _OF_DECLARE_ELMT("compat-2", probe, type)
> _OF_DECLARE_ELMT("compat-3", other_probe, type)
> _OF_DECLARE_ARRAY_END
>
> Signed-off-by: Marc Zyngier
> ---
> include/linux/of.h | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/include/linux/of.h b/include/linux/of.h
> index 5cf7ae0465d1..08f78da95378 100644
> --- a/include/linux/of.h
> +++ b/include/linux/of.h
> @@ -1291,20 +1291,35 @@ static inline int of_get_available_child_count(const
> struct device_node *np)
> return num;
> }
>
> +#define __OF_DECLARE_ARRAY_START(name, section)
> \
> + static const struct of_device_id __of_table_##name[]\
> + __used __section(section) = {
> +
> #if defined(CONFIG_OF) && !defined(MODULE)
> #define _OF_DECLARE(table, name, compat, fn, fn_type)
> \
> static const struct of_device_id __of_table_##name \
> __used __section(__##table##_of_table) \
>= { .compatible = compat, \
>.data = (fn == (fn_type)NULL) ? fn : fn }
> +#define _OF_DECLARE_ARRAY_START(table, name) \
> + __OF_DECLARE_ARRAY_START(name, __##table##_of_table)
> #else
> #define _OF_DECLARE(table, name, compat, fn, fn_type)
> \
> static const struct of_device_id __of_table_##name \
> __attribute__((unused)) \
>= { .compatible = compat, \
>.data = (fn == (fn_type)NULL) ? fn : fn }
> +#define _OF_DECLARE_ARRAY_START(table, name) \
> + __OF_DECLARE_ARRAY_START(name, unused)
> #endif
>
> +#define _OF_DECLARE_ARRAY_END}
> +#define _OF_DECLARE_ELMT(compat, fn, fn_type)
> \
> + { \
> + .compatible = compat, \
> + .data = (fn == (fn_type)NULL) ? fn : fn,\
> + },
> +
> typedef int (*of_init_fn_2)(struct device_node *, struct device_node *);
> typedef int (*of_init_fn_1_ret)(struct device_node *);
> typedef void (*of_init_fn_1)(struct device_node *);
> --
> 2.28.0
>
Re: [PATCH 8/8] arm64: dts: imx8mm-var-som-symphony: Drop unused gpioledgrp
On Tue, Sep 08, 2020 at 05:02:41PM +0200, Krzysztof Kozlowski wrote: > The gpioledgrp in iomux is not used, so it can be dropped. > > Signed-off-by: Krzysztof Kozlowski Applied, thanks.
Re: [PATCH 1/8] ARM: dts: imx6qdl: Correct interrupt flags in examples
Add Tim who is the board owner.
On Tue, Sep 08, 2020 at 05:02:34PM +0200, Krzysztof Kozlowski wrote:
> GPIO_ACTIVE_x flags are not correct in the context of interrupt flags.
> These are simple defines so they could be used in DTS but they will not
> have the same meaning:
> 1. GPIO_ACTIVE_HIGH = 0 = IRQ_TYPE_NONE
> 2. GPIO_ACTIVE_LOW = 1 = IRQ_TYPE_EDGE_RISING
>
> Correct the interrupt flags, assuming the author of the code wanted some
> logical behavior behind the name "ACTIVE_xxx", this is:
> ACTIVE_LOW => IRQ_TYPE_LEVEL_LOW
>
> Signed-off-by: Krzysztof Kozlowski
The subject prefix could be a bit more specific, like 'ARM: dts:
imx6qdl-gw5xxx'. Also, I do not quite understand meaning of 'in
examples' in subject.
Shawn
>
> ---
>
> Not tested on HW.
> ---
> arch/arm/boot/dts/imx6qdl-gw51xx.dtsi | 3 ++-
> arch/arm/boot/dts/imx6qdl-gw52xx.dtsi | 3 ++-
> arch/arm/boot/dts/imx6qdl-gw53xx.dtsi | 3 ++-
> arch/arm/boot/dts/imx6qdl-gw54xx.dtsi | 3 ++-
> arch/arm/boot/dts/imx6qdl-gw551x.dtsi | 3 ++-
> arch/arm/boot/dts/imx6qdl-gw552x.dtsi | 3 ++-
> arch/arm/boot/dts/imx6qdl-gw553x.dtsi | 3 ++-
> arch/arm/boot/dts/imx6qdl-gw560x.dtsi | 3 ++-
> arch/arm/boot/dts/imx6qdl-gw5903.dtsi | 3 ++-
> arch/arm/boot/dts/imx6qdl-gw5904.dtsi | 3 ++-
> arch/arm/boot/dts/imx6qdl-gw5907.dtsi | 3 ++-
> arch/arm/boot/dts/imx6qdl-gw5910.dtsi | 3 ++-
> arch/arm/boot/dts/imx6qdl-gw5912.dtsi | 3 ++-
> arch/arm/boot/dts/imx6qdl-gw5913.dtsi | 3 ++-
> 14 files changed, 28 insertions(+), 14 deletions(-)
>
> diff --git a/arch/arm/boot/dts/imx6qdl-gw51xx.dtsi
> b/arch/arm/boot/dts/imx6qdl-gw51xx.dtsi
> index 4d01c3300b97..3c04b5a4f3cb 100644
> --- a/arch/arm/boot/dts/imx6qdl-gw51xx.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-gw51xx.dtsi
> @@ -5,6 +5,7 @@
>
> #include
> #include
> +#include
>
> / {
> /* these are used by bootloader for disabling nodes */
> @@ -152,7 +153,7 @@
> compatible = "gw,gsc";
> reg = <0x20>;
> interrupt-parent = <>;
> - interrupts = <4 GPIO_ACTIVE_LOW>;
> + interrupts = <4 IRQ_TYPE_LEVEL_LOW>;
> interrupt-controller;
> #interrupt-cells = <1>;
> #size-cells = <0>;
> diff --git a/arch/arm/boot/dts/imx6qdl-gw52xx.dtsi
> b/arch/arm/boot/dts/imx6qdl-gw52xx.dtsi
> index f6182a9d201c..736074f1c3ef 100644
> --- a/arch/arm/boot/dts/imx6qdl-gw52xx.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-gw52xx.dtsi
> @@ -5,6 +5,7 @@
>
> #include
> #include
> +#include
>
> / {
> /* these are used by bootloader for disabling nodes */
> @@ -217,7 +218,7 @@
> compatible = "gw,gsc";
> reg = <0x20>;
> interrupt-parent = <>;
> - interrupts = <4 GPIO_ACTIVE_LOW>;
> + interrupts = <4 IRQ_TYPE_LEVEL_LOW>;
> interrupt-controller;
> #interrupt-cells = <1>;
> #size-cells = <0>;
> diff --git a/arch/arm/boot/dts/imx6qdl-gw53xx.dtsi
> b/arch/arm/boot/dts/imx6qdl-gw53xx.dtsi
> index a28e79463d0c..8072ed47c6bb 100644
> --- a/arch/arm/boot/dts/imx6qdl-gw53xx.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-gw53xx.dtsi
> @@ -5,6 +5,7 @@
>
> #include
> #include
> +#include
>
> / {
> /* these are used by bootloader for disabling nodes */
> @@ -210,7 +211,7 @@
> compatible = "gw,gsc";
> reg = <0x20>;
> interrupt-parent = <>;
> - interrupts = <4 GPIO_ACTIVE_LOW>;
> + interrupts = <4 IRQ_TYPE_LEVEL_LOW>;
> interrupt-controller;
> #interrupt-cells = <1>;
> #size-cells = <0>;
> diff --git a/arch/arm/boot/dts/imx6qdl-gw54xx.dtsi
> b/arch/arm/boot/dts/imx6qdl-gw54xx.dtsi
> index 55f368e192c0..8c9bcdd39830 100644
> --- a/arch/arm/boot/dts/imx6qdl-gw54xx.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-gw54xx.dtsi
> @@ -5,6 +5,7 @@
>
> #include
> #include
> +#include
> #include
>
> / {
> @@ -247,7 +248,7 @@
> compatible = "gw,gsc";
> reg = <0x20>;
> interrupt-parent = <>;
> - interrupts = <4 GPIO_ACTIVE_LOW>;
> + interrupts = <4 IRQ_TYPE_LEVEL_LOW>;
> interrupt-controller;
> #interrupt-cells = <1>;
> #address-cells = <1>;
> diff --git a/arch/arm/boot/dts/imx6qdl-gw551x.dtsi
> b/arch/arm/boot/dts/imx6qdl-gw551x.dtsi
> index 1516e2b0bcde..e5d803d023c8 100644
> --- a/arch/arm/boot/dts/imx6qdl-gw551x.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-gw551x.dtsi
> @@ -48,6 +48,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> / {
> @@ -219,7 +220,7 @@
> compatible = "gw,gsc";
> reg = <0x20>;
> interrupt-parent = <>;
> - interrupts = <4 GPIO_ACTIVE_LOW>;
> + interrupts = <4 IRQ_TYPE_LEVEL_LOW>;
> interrupt-controller;
> #interrupt-cells = <1>;
> #size-cells = <0>;
> diff
Re: [PATCH net-next v2 4/7] net: ipa: manage endpoints separate from clock
On Fri 11 Sep 19:45 CDT 2020, Alex Elder wrote:
> Currently, when (before) the last IPA clock reference is dropped,
> all endpoints are suspended. And whenever the first IPA clock
> reference is taken, all endpoints are resumed (or started).
>
> In most cases there's no need to start endpoints when the clock
> starts. So move the calls to ipa_endpoint_suspend() and
> ipa_endpoint_resume() out of ipa_clock_put() and ipa_clock_get(),
> respectiely. Instead, only suspend endpoints when handling a system
> suspend, and only resume endpoints when handling a system resume.
>
Reviewed-by: Bjorn Andersson
Regards,
Bjorn
> Signed-off-by: Alex Elder
> ---
> drivers/net/ipa/ipa_clock.c | 14 --
> drivers/net/ipa/ipa_main.c | 8
> 2 files changed, 12 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/net/ipa/ipa_clock.c b/drivers/net/ipa/ipa_clock.c
> index b703866f2e20b..a2c0fde058199 100644
> --- a/drivers/net/ipa/ipa_clock.c
> +++ b/drivers/net/ipa/ipa_clock.c
> @@ -200,9 +200,8 @@ bool ipa_clock_get_additional(struct ipa *ipa)
>
> /* Get an IPA clock reference. If the reference count is non-zero, it is
> * incremented and return is immediate. Otherwise it is checked again
> - * under protection of the mutex, and if appropriate the clock (and
> - * interconnects) are enabled suspended endpoints (if any) are resumed
> - * before returning.
> + * under protection of the mutex, and if appropriate the IPA clock
> + * is enabled.
> *
> * Incrementing the reference count is intentionally deferred until
> * after the clock is running and endpoints are resumed.
> @@ -229,17 +228,14 @@ void ipa_clock_get(struct ipa *ipa)
> goto out_mutex_unlock;
> }
>
> - ipa_endpoint_resume(ipa);
> -
> refcount_set(>count, 1);
>
> out_mutex_unlock:
> mutex_unlock(>mutex);
> }
>
> -/* Attempt to remove an IPA clock reference. If this represents the last
> - * reference, suspend endpoints and disable the clock (and interconnects)
> - * under protection of a mutex.
> +/* Attempt to remove an IPA clock reference. If this represents the
> + * last reference, disable the IPA clock under protection of the mutex.
> */
> void ipa_clock_put(struct ipa *ipa)
> {
> @@ -249,8 +245,6 @@ void ipa_clock_put(struct ipa *ipa)
> if (!refcount_dec_and_mutex_lock(>count, >mutex))
> return;
>
> - ipa_endpoint_suspend(ipa);
> -
> ipa_clock_disable(ipa);
>
> mutex_unlock(>mutex);
> diff --git a/drivers/net/ipa/ipa_main.c b/drivers/net/ipa/ipa_main.c
> index cfdf60ded86ca..3b68b53c99015 100644
> --- a/drivers/net/ipa/ipa_main.c
> +++ b/drivers/net/ipa/ipa_main.c
> @@ -913,11 +913,15 @@ static int ipa_remove(struct platform_device *pdev)
> * Return: Always returns zero
> *
> * Called by the PM framework when a system suspend operation is invoked.
> + * Suspends endpoints and releases the clock reference held to keep
> + * the IPA clock running until this point.
> */
> static int ipa_suspend(struct device *dev)
> {
> struct ipa *ipa = dev_get_drvdata(dev);
>
> + ipa_endpoint_suspend(ipa);
> +
> ipa_clock_put(ipa);
> if (!test_and_clear_bit(IPA_FLAG_CLOCK_HELD, ipa->flags))
> dev_err(dev, "suspend: missing suspend clock reference\n");
> @@ -932,6 +936,8 @@ static int ipa_suspend(struct device *dev)
> * Return: Always returns 0
> *
> * Called by the PM framework when a system resume operation is invoked.
> + * Takes an IPA clock reference to keep the clock running until suspend,
> + * and resumes endpoints.
> */
> static int ipa_resume(struct device *dev)
> {
> @@ -945,6 +951,8 @@ static int ipa_resume(struct device *dev)
> else
> dev_err(dev, "resume: duplicate suspend clock reference\n");
>
> + ipa_endpoint_resume(ipa);
> +
> return 0;
> }
>
> --
> 2.20.1
>
Re: [PATCH net-next v2 5/7] net: ipa: use device_init_wakeup()
On Fri 11 Sep 19:45 CDT 2020, Alex Elder wrote:
> The call to wakeup_source_register() in ipa_probe() does not do what
> it was intended to do. Call device_init_wakeup() in ipa_setup()
> instead, to set the IPA device as wakeup-capable and to initially
> enable wakeup capability.
>
> When we receive a SUSPEND interrupt, call pm_wakeup_dev_event()
> with a zero processing time, to simply call for a resume without
> any other processing. The ipa_resume() call will take care of
> waking things up again, and will handle receiving the packet.
>
Reviewed-by: Bjorn Andersson
Regards,
Bjorn
> Signed-off-by: Alex Elder
> ---
> drivers/net/ipa/ipa.h | 2 --
> drivers/net/ipa/ipa_main.c | 43 --
> 2 files changed, 18 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/net/ipa/ipa.h b/drivers/net/ipa/ipa.h
> index e02fe979b645b..c688155ccf375 100644
> --- a/drivers/net/ipa/ipa.h
> +++ b/drivers/net/ipa/ipa.h
> @@ -114,8 +114,6 @@ struct ipa {
> void *zero_virt;
> size_t zero_size;
>
> - struct wakeup_source *wakeup_source;
> -
> /* Bit masks indicating endpoint state */
> u32 available; /* supported by hardware */
> u32 filter_map;
> diff --git a/drivers/net/ipa/ipa_main.c b/drivers/net/ipa/ipa_main.c
> index 3b68b53c99015..5e714d9d2e5cb 100644
> --- a/drivers/net/ipa/ipa_main.c
> +++ b/drivers/net/ipa/ipa_main.c
> @@ -75,18 +75,19 @@
> * @ipa: IPA pointer
> * @irq_id: IPA interrupt type (unused)
> *
> - * When in suspended state, the IPA can trigger a resume by sending a SUSPEND
> - * IPA interrupt.
> + * If an RX endpoint is in suspend state, and the IPA has a packet
> + * destined for that endpoint, the IPA generates a SUSPEND interrupt
> + * to inform the AP that it should resume the endpoint. If we get
> + * one of these interrupts we just resume everything.
> */
> static void ipa_suspend_handler(struct ipa *ipa, enum ipa_irq_id irq_id)
> {
> - /* Take a a single clock reference to prevent suspend. All
> - * endpoints will be resumed as a result. This reference will
> - * be dropped when we get a power management suspend request.
> - * The first call activates the clock; ignore any others.
> + /* Just report the event, and let system resume handle the rest.
> + * More than one endpoint could signal this; if so, ignore
> + * all but the first.
>*/
> if (!test_and_set_bit(IPA_FLAG_CLOCK_HELD, ipa->flags))
> - ipa_clock_get(ipa);
> + pm_wakeup_dev_event(>pdev->dev, 0, true);
>
> /* Acknowledge/clear the suspend interrupt on all endpoints */
> ipa_interrupt_suspend_clear_all(ipa->interrupt);
> @@ -107,6 +108,7 @@ int ipa_setup(struct ipa *ipa)
> {
> struct ipa_endpoint *exception_endpoint;
> struct ipa_endpoint *command_endpoint;
> + struct device *dev = >pdev->dev;
> int ret;
>
> /* Setup for IPA v3.5.1 has some slight differences */
> @@ -124,6 +126,10 @@ int ipa_setup(struct ipa *ipa)
>
> ipa_uc_setup(ipa);
>
> + ret = device_init_wakeup(dev, true);
> + if (ret)
> + goto err_uc_teardown;
> +
> ipa_endpoint_setup(ipa);
>
> /* We need to use the AP command TX endpoint to perform other
> @@ -159,7 +165,7 @@ int ipa_setup(struct ipa *ipa)
>
> ipa->setup_complete = true;
>
> - dev_info(>pdev->dev, "IPA driver setup completed successfully\n");
> + dev_info(dev, "IPA driver setup completed successfully\n");
>
> return 0;
>
> @@ -174,6 +180,8 @@ int ipa_setup(struct ipa *ipa)
> ipa_endpoint_disable_one(command_endpoint);
> err_endpoint_teardown:
> ipa_endpoint_teardown(ipa);
> + (void)device_init_wakeup(dev, false);
> +err_uc_teardown:
> ipa_uc_teardown(ipa);
> ipa_interrupt_remove(ipa->interrupt, IPA_IRQ_TX_SUSPEND);
> ipa_interrupt_teardown(ipa->interrupt);
> @@ -201,6 +209,7 @@ static void ipa_teardown(struct ipa *ipa)
> command_endpoint = ipa->name_map[IPA_ENDPOINT_AP_COMMAND_TX];
> ipa_endpoint_disable_one(command_endpoint);
> ipa_endpoint_teardown(ipa);
> + (void)device_init_wakeup(>pdev->dev, false);
> ipa_uc_teardown(ipa);
> ipa_interrupt_remove(ipa->interrupt, IPA_IRQ_TX_SUSPEND);
> ipa_interrupt_teardown(ipa->interrupt);
> @@ -715,7 +724,6 @@ static void ipa_validate_build(void)
> */
> static int ipa_probe(struct platform_device *pdev)
> {
> - struct wakeup_source *wakeup_source;
> struct device *dev = >dev;
> const struct ipa_data *data;
> struct ipa_clock *clock;
> @@ -764,19 +772,11 @@ static int ipa_probe(struct platform_device *pdev)
> goto err_clock_exit;
> }
>
> - /* Create a wakeup source. */
> - wakeup_source = wakeup_source_register(dev, "ipa");
> - if (!wakeup_source) {
> - /* The most likely reason for failure is memory exhaustion */
> -
Re: [PATCH net-next v2 3/7] net: ipa: verify reference flag values
On Fri 11 Sep 19:45 CDT 2020, Alex Elder wrote:
> We take a single IPA clock reference to keep the clock running until
> we get a system suspend operation, and maintain a flag indicating
> whether that reference has been taken. When a suspend request
> arrives, we drop that reference and clear the flag.
>
> In most places we simply set or clear the extra-reference flag.
> Instead--primarily to catch coding errors--test the previous value
> of the flag and report an error in the event the previous value is
> unexpected. And if the clock reference is already taken, don't take
> another.
>
> In a couple of cases it's pretty clear atomic access is not
> necessary and an error should never be reported. Report these
> anyway, conveying our surprise with an added exclamation point.
>
> Signed-off-by: Alex Elder
> ---
> v2: Updated to operate on a bitmap bit rather than an atomic_t.
>
> drivers/net/ipa/ipa_main.c | 23 ---
> 1 file changed, 16 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/ipa/ipa_main.c b/drivers/net/ipa/ipa_main.c
> index 409375b96eb8f..cfdf60ded86ca 100644
> --- a/drivers/net/ipa/ipa_main.c
> +++ b/drivers/net/ipa/ipa_main.c
> @@ -83,6 +83,7 @@ static void ipa_suspend_handler(struct ipa *ipa, enum
> ipa_irq_id irq_id)
> /* Take a a single clock reference to prevent suspend. All
>* endpoints will be resumed as a result. This reference will
>* be dropped when we get a power management suspend request.
> + * The first call activates the clock; ignore any others.
>*/
> if (!test_and_set_bit(IPA_FLAG_CLOCK_HELD, ipa->flags))
> ipa_clock_get(ipa);
> @@ -502,14 +503,17 @@ static void ipa_resource_deconfig(struct ipa *ipa)
> */
> static int ipa_config(struct ipa *ipa, const struct ipa_data *data)
> {
> + struct device *dev = >pdev->dev;
> int ret;
>
> /* Get a clock reference to allow initialization. This reference
>* is held after initialization completes, and won't get dropped
>* unless/until a system suspend request arrives.
>*/
> - __set_bit(IPA_FLAG_CLOCK_HELD, ipa->flags);
> - ipa_clock_get(ipa);
> + if (!__test_and_set_bit(IPA_FLAG_CLOCK_HELD, ipa->flags))
> + ipa_clock_get(ipa);
> + else
> + dev_err(dev, "suspend clock reference already taken!\n");
>
> ipa_hardware_config(ipa);
>
> @@ -544,7 +548,8 @@ static int ipa_config(struct ipa *ipa, const struct
> ipa_data *data)
> err_hardware_deconfig:
> ipa_hardware_deconfig(ipa);
> ipa_clock_put(ipa);
> - __clear_bit(IPA_FLAG_CLOCK_HELD, ipa->flags);
> + if (!__test_and_clear_bit(IPA_FLAG_CLOCK_HELD, ipa->flags))
> + dev_err(dev, "suspend clock reference already dropped!\n");
>
> return ret;
> }
> @@ -562,7 +567,8 @@ static void ipa_deconfig(struct ipa *ipa)
> ipa_endpoint_deconfig(ipa);
> ipa_hardware_deconfig(ipa);
> ipa_clock_put(ipa);
> - __clear_bit(IPA_FLAG_CLOCK_HELD, ipa->flags);
> + if (!test_and_clear_bit(IPA_FLAG_CLOCK_HELD, ipa->flags))
Doesn't this imply that we ran with the clocks disabled, which
presumably would have nasty side effects?
This seems like something that is worthy of more than just a simple
printout - which no one will actually read. If you instead use a
WARN_ON() to highlight this at least some of the test environments out
there will pick it up and report it...
Regards,
Bjorn
> + dev_err(>pdev->dev, "no suspend clock reference\n");
> }
>
> static int ipa_firmware_load(struct device *dev)
> @@ -913,7 +919,8 @@ static int ipa_suspend(struct device *dev)
> struct ipa *ipa = dev_get_drvdata(dev);
>
> ipa_clock_put(ipa);
> - __clear_bit(IPA_FLAG_CLOCK_HELD, ipa->flags);
> + if (!test_and_clear_bit(IPA_FLAG_CLOCK_HELD, ipa->flags))
> + dev_err(dev, "suspend: missing suspend clock reference\n");
>
> return 0;
> }
> @@ -933,8 +940,10 @@ static int ipa_resume(struct device *dev)
> /* This clock reference will keep the IPA out of suspend
>* until we get a power management suspend request.
>*/
> - __set_bit(IPA_FLAG_CLOCK_HELD, ipa->flags);
> - ipa_clock_get(ipa);
> + if (!test_and_set_bit(IPA_FLAG_CLOCK_HELD, ipa->flags))
> + ipa_clock_get(ipa);
> + else
> + dev_err(dev, "resume: duplicate suspend clock reference\n");
>
> return 0;
> }
> --
> 2.20.1
>
[ANNOUNCE] 4.14.198-rt96
Hello RT-list! I'm pleased to announce the 4.14.198-rt96 stable release. You can get this release via the git tree at: git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git branch: v4.14-rt Head SHA1: 8c4828cbd4220fc1c97c0db534fce850b86aa8d4 Or to build 4.14.198-rt96 directly, the following patches should be applied: https://www.kernel.org/pub/linux/kernel/v4.x/linux-4.14.tar.xz https://www.kernel.org/pub/linux/kernel/v4.x/patch-4.14.198.xz https://www.kernel.org/pub/linux/kernel/projects/rt/4.14/patch-4.14.198-rt96.patch.xz You can also build from 4.14.197-rt95 by applying the incremental patch: https://www.kernel.org/pub/linux/kernel/projects/rt/4.14/incr/patch-4.14.197-rt95-rt96.patch.xz Enjoy! Clark
BUG: Bad page state in process dirtyc0w_child
Occasionally, running this LTP test will trigger an error below on
s390:
https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/security/dirtyc0w/dirtyc0w.c
https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/security/dirtyc0w/dirtyc0w_child.c
this .config:
https://gitlab.com/cailca/linux-mm/-/blob/master/s390.config
[ 6970.253173] LTP: starting dirtyc0w
[ 6971.599102] BUG: Bad page state in process dirtyc0w_child pfn:8865d
[ 6971.599867] page:1a8328d7 refcount:0 mapcount:0
mapping: index:0x0 pfn:0x8865d
[ 6971.599876] flags: 0x4008000e(referenced|uptodate|dirty|swapbacked)
[ 6971.599886] raw: 4008000e 0100 0122
[ 6971.599893] raw:
[ 6971.599900] page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set
[ 6971.599906] Modules linked in: loop kvm ip_tables x_tables dm_mirror
dm_region_hash dm_log dm_mod [last unloaded: dummy_del_mod]
[ 6971.599952] CPU: 1 PID: 65238 Comm: dirtyc0w_child Tainted: G O
5.9.0-rc4-next-20200909 #1
[ 6971.599959] Hardware name: IBM 2964 N96 400 (z/VM 6.4.0)
[ 6971.599964] Call Trace:
[ 6971.599979] [<73aec038>] show_stack+0x158/0x1f0
[ 6971.599986] [<73af724a>] dump_stack+0x1f2/0x238
[ 6971.54] [<72ed086a>] bad_page+0x1ba/0x1c0
[ 6971.60] [<72ed20c4>] free_pcp_prepare+0x4fc/0x658
[ 6971.66] [<72ed96a6>] free_unref_page+0xae/0x158
[ 6971.600013] [<72e8286a>] unmap_page_range+0xb62/0x1df8
[ 6971.600019] [<72e83bbc>] unmap_single_vma+0xbc/0x1c8
[ 6971.600025] [<72e8418e>] zap_page_range+0x176/0x230
[ 6971.600033] [<72eece8e>] do_madvise+0xfde/0x1270
[ 6971.600039] [<72eed50a>] __s390x_sys_madvise+0x72/0x98
[ 6971.600047] [<73b1cce4>] system_call+0xdc/0x278
[ 6971.600053] 2 locks held by dirtyc0w_child/65238:
[ 6971.600058] #0: 00013442fa18 (>mmap_lock){}-{3:3}, at:
do_madvise+0x17a/0x1270
[ 6971.600432] #1: 0001343f9060 (ptlock_ptr(page)#2){+.+.}-{2:2}, at:
unmap_page_range+0x640/0x1df8
[ 6971.600487] Disabling lock debugging due to kernel taint
Once it happens, running it again will trigger in on another PFN.
[39717.085115] BUG: Bad page state in process dirtyc0w_child pfn:af065
Any thoughts?
Re: [PATCH 0/6] arch: arm64: Add label to pcie nodes
On Wed, Sep 09, 2020 at 07:14:30PM +0530, Wasim Khan wrote: > From: Wasim Khan > > This patch series adds label to pcie nodes > so that they are easy to refer. > > Wasim Khan (6): > arm64: dts: lx2160a: Add label to pcie nodes > arm64: dts: ls1012a: Add label to pcie nodes > arm64: dts: ls1043a: Add label to pcie nodes > arm64: dts: ls1046a: Add label to pcie nodes > arm64: dts: ls1028a: Add label to pcie nodes > arm64: dts: ls1088a: Add label to pcie nodes Please squash them into one patch. Shawn
Re: [PATCH v5 05/10] powerpc/smp: Dont assume l2-cache to be superset of sibling
Srikar Dronamraju writes: > * Michael Ellerman [2020-09-11 21:55:23]: > >> Srikar Dronamraju writes: >> > Current code assumes that cpumask of cpus sharing a l2-cache mask will >> > always be a superset of cpu_sibling_mask. >> > >> > Lets stop that assumption. cpu_l2_cache_mask is a superset of >> > cpu_sibling_mask if and only if shared_caches is set. >> >> I'm seeing oopses with this: >> >> [0.117392][T1] smp: Bringing up secondary CPUs ... >> [0.156515][T1] smp: Brought up 2 nodes, 2 CPUs >> [0.158265][T1] numa: Node 0 CPUs: 0 >> [0.158520][T1] numa: Node 1 CPUs: 1 >> [0.167453][T1] BUG: Unable to handle kernel data access on read at >> 0x800041228298 >> [0.167992][T1] Faulting instruction address: 0xc018c128 >> [0.168817][T1] Oops: Kernel access of bad area, sig: 11 [#1] >> [0.168964][T1] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA >> pSeries >> [0.169417][T1] Modules linked in: >> [0.170047][T1] CPU: 0 PID: 1 Comm: swapper/0 Not tainted >> 5.9.0-rc2-00095-g7430ad5aa700 #209 >> [0.170305][T1] NIP: c018c128 LR: c018c0cc CTR: >> c004dce0 >> [0.170498][T1] REGS: c0007e343880 TRAP: 0380 Not tainted >> (5.9.0-rc2-00095-g7430ad5aa700) >> [0.170602][T1] MSR: 82009033 >> CR: 4400 XER: >> [0.170985][T1] CFAR: c018c288 IRQMASK: 0 >> [0.170985][T1] GPR00: c0007e343b10 >> c173e400 4000 >> [0.170985][T1] GPR04: 0800 >> 0800 >> [0.170985][T1] GPR08: c122c298 >> c0003fffc000 c0007fd05ce8 >> [0.170985][T1] GPR12: c0007e0119f8 c193 >> 8ade >> [0.170985][T1] GPR16: c0007e3c0640 0917 >> c0007e3c0658 0008 >> [0.170985][T1] GPR20: c15d0bb8 8ade >> c0f57400 c1817c28 >> [0.170985][T1] GPR24: c176dc80 c0007e3c0890 >> c0007e3cfe00 >> [0.170985][T1] GPR28: c1772310 c0007e011900 >> c0007e3c0800 0001 >> [0.172750][T1] NIP [c018c128] >> build_sched_domains+0x808/0x14b0 >> [0.172900][T1] LR [c018c0cc] build_sched_domains+0x7ac/0x14b0 >> [0.173186][T1] Call Trace: >> [0.173484][T1] [c0007e343b10] [c018bfe8] >> build_sched_domains+0x6c8/0x14b0 (unreliable) >> [0.173821][T1] [c0007e343c50] [c018dcdc] >> sched_init_domains+0xec/0x130 >> [0.174037][T1] [c0007e343ca0] [c10d59d8] >> sched_init_smp+0x50/0xc4 >> [0.174207][T1] [c0007e343cd0] [c10b45c4] >> kernel_init_freeable+0x1b4/0x378 >> [0.174378][T1] [c0007e343db0] [c00129fc] >> kernel_init+0x24/0x158 >> [0.174740][T1] [c0007e343e20] [c000d9d0] >> ret_from_kernel_thread+0x5c/0x6c >> [0.175050][T1] Instruction dump: >> [0.175626][T1] 554905ee 71480040 7d2907b4 4182016c 2c29 3920006e >> 913e002c 41820034 >> [0.175841][T1] 7c6307b4 e9300020 78631f24 7d58182a <7d2a482a> >> f93e0080 7d404828 314a0001 >> [0.178340][T1] ---[ end trace 6876b88dd1d4b3bb ]--- >> [0.178512][T1] >> [1.180458][T1] Kernel panic - not syncing: Attempted to kill init! >> exitcode=0x000b >> >> That's qemu: >> >> qemu-system-ppc64 -nographic -vga none -M pseries -cpu POWER8 \ >> -kernel build~/vmlinux \ >> -m 2G,slots=2,maxmem=4G \ >> -object memory-backend-ram,size=1G,id=m0 \ >> -object memory-backend-ram,size=1G,id=m1 \ >> -numa node,nodeid=0,memdev=m0 \ >> -numa node,nodeid=1,memdev=m1 \ >> -smp 2,sockets=2,maxcpus=2 \ >> > > Thanks Michael for the report and also for identifying the patch and also > giving an easy reproducer. That made my task easy. (My only problem was all > my PowerKVM hosts had a old compiler that refuse to compile never kernels.) > > So in this setup, CPU doesn't have a l2-cache. And in that scenario, we > miss updating the l2-cache domain. Actually the initial patch had this > exact code. However it was my mistake. I should have reassessed it before > making changes suggested by Gautham. > > Patch below. Do let me know if you want me to send the patch separately. >> On mambo I get: >> >> [0.005069][T1] smp: Bringing up secondary CPUs ... >> [0.011656][T1] smp: Brought up 2 nodes, 8 CPUs >> [0.011682][T1] numa: Node 0 CPUs: 0-3 >> [0.011709][T1] numa: Node 1 CPUs: 4-7 >> [0.012015][T1] BUG: arch topology borken >> [0.012040][T1] the SMT domain not a subset of the CACHE domain >> [0.012107][T1] BUG: Unable to handle kernel data access on read at >> 0x8001012e7398 >> [0.012142][T1] Faulting instruction address:
Re: [PATCH] firmware: imx: scu-pd: ignore power domain not owned
On Tue, Sep 08, 2020 at 06:07:01PM +0800, peng@nxp.com wrote: > From: Peng Fan > > Should not register power domain that not owned by current > partition. > > Alought power domains will not be registered when power on failure, > we have to let CPU waste more cycles. > > Whether power on or owned check, both need communicate with SCU, > but with owned check, we no need to run more code path to save CPU > cycles. > > Signed-off-by: Peng Fan > Reviewed-by: Leonard Crestez Applied, thanks.
Re: [PATCH] Revert "net: linkwatch: add check for netdevice being present to linkwatch_do_dev"
From: Geert Uytterhoeven Date: Sat, 12 Sep 2020 14:33:59 +0200 > "dev" is not the bridge device, but the physical Ethernet interface, which > may already be suspended during s2ram. Hmmm, ok. Looking more deeply NETDEV_CHANGE causes br_port_carrier_check() to run which exits early if netif_running() is false, which is going to be true if netif_device_present() is false: *notified = false; if (!netif_running(br->dev)) return; The only other work the bridge notifier does is: if (event != NETDEV_UNREGISTER) br_vlan_port_event(p, event); and: /* Events that may cause spanning tree to refresh */ if (!notified && (event == NETDEV_CHANGEADDR || event == NETDEV_UP || event == NETDEV_CHANGE || event == NETDEV_DOWN)) br_ifinfo_notify(RTM_NEWLINK, NULL, p); So some vlan stuff, and emitting a netlink message to any available listeners. Should we really do all of this for a device which is not even present? This whole situation seems completely illogical. The device is useless, it logically has no link or other state that can be managed or used, while it is not present. So all of these bridge operations should only happen when the device transitions back to present again.
Re: [PATCH v3 1/3] ARM: dts: imx6qdl: tqma6: fix indentation
On Mon, Sep 07, 2020 at 10:04:27AM +0200, Matthias Schiffer wrote:
> The PMIC configuration is indented one level too deep.
>
> Fixes: cac849e9bbc8 ("ARM: dts: imx6qdl: add TQMa6{S,Q,QP} SoM")
> Signed-off-by: Matthias Schiffer
I change the subject prefix to 'ARM: dts: imx6qdl-tqma6:' and applied
all 3.
Shawn
Re: [RESEND PATCH v2 2/2] drm/mediatek: mtk_dpi: Convert to bridge driver
Hi,
Daniel Vetter 於 2020年9月10日 週四 下午1:48寫道：
>
> On Thu, Sep 10, 2020 at 06:35:21AM +0800, Chun-Kuang Hu wrote:
> > Hi, Andrzej & Neil:
> >
> > Enric Balletbo i Serra 於 2020年8月26日 週三
> > 下午4:53寫道：
> >
> > >
> > > Convert mtk_dpi to a bridge driver with built-in encoder support for
> > > compatibility with existing component drivers.
> > >
> >
> > This is a DRM-bridge related patch, how do you think about it?
>
> bridge stuff is also maintained in drm-misc, so good to go imo.
>
> For the bigger picture I think it'd be really good if bridges drivers
> would use the of bridge lookup, and not hand roll something with
> component. So 2nd step of converting this over to a proper bridge driver
> would be to replace the component code here too.
OK, so this series is applied to mediatek-drm-next [1].
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-next
Regards,
Chun-Kuang.
>
> Cheers, Daniel
>
> >
> > Regards,
> > Chun-Kuang.
> >
> > > Reviewed-by: Chun-Kuang Hu
> > > Signed-off-by: Enric Balletbo i Serra
> > > ---
> > >
> > > Changes in v2:
> > > - Maintain error message when attach to bridge fails. (Boris)
> > >
> > > drivers/gpu/drm/mediatek/mtk_dpi.c | 71 ++
> > > 1 file changed, 42 insertions(+), 29 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c
> > > b/drivers/gpu/drm/mediatek/mtk_dpi.c
> > > index f7372dbdac0e..589ef33a1780 100644
> > > --- a/drivers/gpu/drm/mediatek/mtk_dpi.c
> > > +++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
> > > @@ -64,6 +64,7 @@ enum mtk_dpi_out_color_format {
> > > struct mtk_dpi {
> > > struct mtk_ddp_comp ddp_comp;
> > > struct drm_encoder encoder;
> > > + struct drm_bridge bridge;
> > > struct drm_bridge *next_bridge;
> > > void __iomem *regs;
> > > struct device *dev;
> > > @@ -83,9 +84,9 @@ struct mtk_dpi {
> > > int refcount;
> > > };
> > >
> > > -static inline struct mtk_dpi *mtk_dpi_from_encoder(struct drm_encoder *e)
> > > +static inline struct mtk_dpi *bridge_to_dpi(struct drm_bridge *b)
> > > {
> > > - return container_of(e, struct mtk_dpi, encoder);
> > > + return container_of(b, struct mtk_dpi, bridge);
> > > }
> > >
> > > enum mtk_dpi_polarity {
> > > @@ -521,50 +522,53 @@ static int mtk_dpi_set_display_mode(struct mtk_dpi
> > > *dpi,
> > > return 0;
> > > }
> > >
> > > -static bool mtk_dpi_encoder_mode_fixup(struct drm_encoder *encoder,
> > > - const struct drm_display_mode
> > > *mode,
> > > - struct drm_display_mode
> > > *adjusted_mode)
> > > +static void mtk_dpi_encoder_destroy(struct drm_encoder *encoder)
> > > {
> > > - return true;
> > > + drm_encoder_cleanup(encoder);
> > > }
> > >
> > > -static void mtk_dpi_encoder_mode_set(struct drm_encoder *encoder,
> > > -struct drm_display_mode *mode,
> > > -struct drm_display_mode
> > > *adjusted_mode)
> > > +static const struct drm_encoder_funcs mtk_dpi_encoder_funcs = {
> > > + .destroy = mtk_dpi_encoder_destroy,
> > > +};
> > > +
> > > +static int mtk_dpi_bridge_attach(struct drm_bridge *bridge,
> > > +enum drm_bridge_attach_flags flags)
> > > {
> > > - struct mtk_dpi *dpi = mtk_dpi_from_encoder(encoder);
> > > + struct mtk_dpi *dpi = bridge_to_dpi(bridge);
> > > +
> > > + return drm_bridge_attach(bridge->encoder, dpi->next_bridge,
> > > +>bridge, flags);
> > > +}
> > > +
> > > +static void mtk_dpi_bridge_mode_set(struct drm_bridge *bridge,
> > > + const struct drm_display_mode *mode,
> > > + const struct drm_display_mode
> > > *adjusted_mode)
> > > +{
> > > + struct mtk_dpi *dpi = bridge_to_dpi(bridge);
> > >
> > > drm_mode_copy(>mode, adjusted_mode);
> > > }
> > >
> > > -static void mtk_dpi_encoder_disable(struct drm_encoder *encoder)
> > > +static void mtk_dpi_bridge_disable(struct drm_bridge *bridge)
> > > {
> > > - struct mtk_dpi *dpi = mtk_dpi_from_encoder(encoder);
> > > + struct mtk_dpi *dpi = bridge_to_dpi(bridge);
> > >
> > > mtk_dpi_power_off(dpi);
> > > }
> > >
> > > -static void mtk_dpi_encoder_enable(struct drm_encoder *encoder)
> > > +static void mtk_dpi_bridge_enable(struct drm_bridge *bridge)
> > > {
> > > - struct mtk_dpi *dpi = mtk_dpi_from_encoder(encoder);
> > > + struct mtk_dpi *dpi = bridge_to_dpi(bridge);
> > >
> > > mtk_dpi_power_on(dpi);
> > > mtk_dpi_set_display_mode(dpi, >mode);
> > > }
> > >
> > > -static int mtk_dpi_atomic_check(struct drm_encoder *encoder,
> > > - struct drm_crtc_state *crtc_state,
> > > - struct drm_connector_state *conn_state)
> > > -{
> > > -
Re: [PATCH] tlan: switch from 'pci_' to 'dma_' API
From: Christophe JAILLET Date: Sat, 12 Sep 2020 09:43:58 +0200 > The wrappers in include/linux/pci-dma-compat.h should go away. > > The patch has been generated with the coccinelle script below and has been > hand modified to replace GFP_ with a correct flag. > It has been compile tested. > > When memory is allocated in 'tlan_init()' GFP_KERNEL can be used because > it is only called from a probe function or a module_init function and no > lock is taken in the between. > The call chain is: > tlan_probe(module_init function) > --> tlan_eisa_probe > or > tlan_init_one (probe function) > > then in both cases: > --> tlan_probe1 > --> tlan_init > ... > Signed-off-by: Christophe JAILLET Applied.
Re: [PATCH] net: tehuti: switch from 'pci_' to 'dma_' API
From: Christophe JAILLET Date: Sat, 12 Sep 2020 16:12:32 +0200 > The wrappers in include/linux/pci-dma-compat.h should go away. > > The patch has been generated with the coccinelle script below and has been > hand modified to replace GFP_ with a correct flag. > It has been compile tested. > > When memory is allocated in 'bdx_fifo_init()' GFP_ATOMIC must be used > because it can be called from a '.ndo_set_rx_mode' function. Such functions > hold the 'netif_addr_lock' spinlock. > > .ndo_set_rx_mode (see struct net_device_ops) > --> bdx_change_mtu > --> bdx_open > --> bdx_rx_init > --> bdx_tx_init > --> bdx_fifo_init ... > Signed-off-by: Christophe JAILLET Applied.
Re: [PATCH] rocker: switch from 'pci_' to 'dma_' API
From: Christophe JAILLET Date: Sat, 12 Sep 2020 13:44:18 +0200 > The wrappers in include/linux/pci-dma-compat.h should go away. > > The patch has been generated with the coccinelle script below and has been > hand modified to replace GFP_ with a correct flag. > It has been compile tested. > > When memory is allocated in 'rocker_dma_ring_create()' GFP_KERNEL can be > used because it is already used in the same function just a few lines > above. ... > Signed-off-by: Christophe JAILLET Applied.
Re: [PATCH] sc92031: switch from 'pci_' to 'dma_' API
From: Christophe JAILLET Date: Sat, 12 Sep 2020 13:28:58 +0200 > The wrappers in include/linux/pci-dma-compat.h should go away. > > The patch has been generated with the coccinelle script below and has been > hand modified to replace GFP_ with a correct flag. > It has been compile tested. > > When memory is allocated in 'sc92031_open()' GFP_KERNEL can be used > because it is a '.ndo_open' function and no lock is taken in the between. > '.ndo_open' functions are synchronized with the rtnl_lock() semaphore. ... > Signed-off-by: Christophe JAILLET Applied.
Re: [PATCH net-next] net: ethernet: mlx4: Avoid assigning a value to ring_cons but not used it anymore in mlx4_en_xmit()
From: Luo Jiaxing
Date: Sat, 12 Sep 2020 16:08:15 +0800
> We found a set but not used variable 'ring_cons' in mlx4_en_xmit(), it will
> cause a warning when build the kernel. And after checking the commit record
> of this function, we found that it was introduced by a previous patch.
>
> So, We delete this redundant assignment code.
>
> Fixes: 488a9b48e398 ("net/mlx4_en: Wake TX queues only when there's enough
> room")
>
> Signed-off-by: Luo Jiaxing
Looks good, applied, thanks.
Re: [Linux-kernel-mentees] [PATCH net] tipc: Fix memory leak in tipc_group_create_member()
From: Peilin Ye Date: Sat, 12 Sep 2020 06:22:30 -0400 > @@ -291,10 +291,11 @@ static void tipc_group_add_to_tree(struct tipc_group > *grp, > else if (key > nkey) > n = &(*n)->rb_right; > else > - return; > + return -1; Use a real error code like "-EEXIST", thank you.
Re: [PATCH v2] clk: imx: gate2: Fix a few typos
On Sat, Sep 05, 2020 at 05:10:16PM +0200, Jonathan Neuschäfer wrote: > A few words were misspelled in this comment. > > Signed-off-by: Jonathan Neuschäfer Applied, thanks.
Re: [PATCH 08/13] arm64: dts: imx8mm-var-som-symphony: Use newer interrupts property
On Fri, Sep 04, 2020 at 04:53:07PM +0200, Krzysztof Kozlowski wrote: > The int-gpios was deprecated in favor of generic interrupts property. > > Signed-off-by: Krzysztof Kozlowski Applied patch #8 ~ #13, thanks.
Re: [PATCH 1/3] spi: spi-geni-qcom: Use the FIFO even more
Hi,
On Sat, Sep 12, 2020 at 3:53 PM Bjorn Andersson
wrote:
>
> On Sat 12 Sep 16:07 CDT 2020, Douglas Anderson wrote:
>
> > In commit 902481a78ee4 ("spi: spi-geni-qcom: Actually use our FIFO") I
> > explained that the maximum size we could program the FIFO was
> > "mas->tx_fifo_depth - 3" but that I chose "mas->tx_fifo_depth()"
> > because I was worried about decreased bandwidth.
> >
> > Since that time:
> > * All the interconnect patches have landed, making things run at the
> > proper speed.
> > * I've done more measurements.
> >
> > This lets me confirm that there's really no downside of using the FIFO
> > more. Specifically I did "flashrom -p ec -r /tmp/foo.bin" on a
> > Chromebook and averaged over several runs.
>
> Wouldn't there be a downside in the form of setting the watermark that
> close to the full FIFO we have less room for being late handling the
> interrupt? Or is there some mechanism involved that will prevent
> the FIFO from being overrun?
Yeah, I had that worry too, but, as described in 902481a78ee4 ("spi:
spi-geni-qcom: Actually use our FIFO"), it doesn't seem to be a
problem. From that commit: "We are the SPI master, so it makes sense
that there would be no problems with overruns, the master should just
stop clocking."
-Doug
Re: [PATCH 3/3] spi: spi-geni-qcom: Slightly optimize setup of bidirectional xfters
Hi, On Sat, Sep 12, 2020 at 3:54 PM Bjorn Andersson wrote: > > On Sat 12 Sep 16:08 CDT 2020, Douglas Anderson wrote: > > > When setting up a bidirectional transfer we need to program both the > > TX and RX lengths. We don't need a memory barrier between those two > > writes. Factor out the __iowmb() and use writel_relaxed(). This > > saves a fraction of a microsecond of setup overhead on bidirectional > > transfers. > > > > Signed-off-by: Douglas Anderson > > --- > > > > drivers/spi/spi-geni-qcom.c | 13 ++--- > > 1 file changed, 10 insertions(+), 3 deletions(-) > > > > diff --git a/drivers/spi/spi-geni-qcom.c b/drivers/spi/spi-geni-qcom.c > > index 92d88bf85a90..6c7e12b68bf0 100644 > > --- a/drivers/spi/spi-geni-qcom.c > > +++ b/drivers/spi/spi-geni-qcom.c > > @@ -376,15 +376,22 @@ static void setup_fifo_xfer(struct spi_transfer *xfer, > > len &= TRANS_LEN_MSK; > > > > mas->cur_xfer = xfer; > > + > > + /* > > + * Factor out the __iowmb() so that we can use writel_relaxed() for > > + * both writes below and thus only incur the overhead once even if > > + * we execute both of them. > > + */ > > How many passes through this function do we have to take before saving > the amount of time it took me to read this comment? > > Reviewed-by: Bjorn Andersson Thanks for the review! Yeah, in Chrome OS we do a crazy amount of SPI transfers since our EC and security chip are connected over SPI and we seem to pile a whole lot of stuff into the EC. This means we keep coming back to the SPI controller again and again when profiling things. I'm hoping that we'll eventually be able to get DMA enabled here, but until then at least it's nice to make the FIFO transfers better... -Doug
Re: [PATCH] mm: memcontrol: Fix out-of-bounds on the buf returned by memory_stat_format
On Sat, 12 Sep 2020 23:51:00 +0800 Muchun Song wrote: > The memory_stat_format() returns a format string, but the return buf > may not including the trailing '\0'. So the users may read the buf > out of bounds. That sounds serious. Is a cc:stable appropriate?
Re: [PATCH 6/6] irqchip/qcom-pdc: Allow modular build
On Sat 12 Sep 07:51 CDT 2020, Marc Zyngier wrote:
> Switch the driver to a "hybrid probe" model which preserves the
> built-in behaviour while allowing the driver to be optionnally
> built as a module for development purposes.
>
Reviewed-by: Bjorn Andersson
> Signed-off-by: Marc Zyngier
> ---
> drivers/irqchip/qcom-pdc.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/irqchip/qcom-pdc.c b/drivers/irqchip/qcom-pdc.c
> index 6ae9e1f0819d..8543fa23da10 100644
> --- a/drivers/irqchip/qcom-pdc.c
> +++ b/drivers/irqchip/qcom-pdc.c
> @@ -430,4 +430,6 @@ static int qcom_pdc_init(struct device_node *node, struct
> device_node *parent)
> return ret;
> }
>
> -IRQCHIP_DECLARE(qcom_pdc, "qcom,pdc", qcom_pdc_init);
> +IRQCHIP_HYBRID_DRIVER_BEGIN(qcom_pdc)
> +IRQCHIP_MATCH("qcom,pdc", qcom_pdc_init)
> +IRQCHIP_HYBRID_DRIVER_END(qcom_pdc)
> --
> 2.28.0
>
Re: [PATCH 5/6] irqchip/mtk-sysirq: Allow modular build
On Sat 12 Sep 07:51 CDT 2020, Marc Zyngier wrote:
> Switch the driver to a "hybrid probe" model which preserves the
> built-in behaviour while allowing the driver to be optionnally
> built as a module for development purposes.
>
Reviewed-by: Bjorn Andersson
> Signed-off-by: Marc Zyngier
> ---
> drivers/irqchip/irq-mtk-sysirq.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/irqchip/irq-mtk-sysirq.c
> b/drivers/irqchip/irq-mtk-sysirq.c
> index 6ff98b87e5c0..ee45d8f71ec3 100644
> --- a/drivers/irqchip/irq-mtk-sysirq.c
> +++ b/drivers/irqchip/irq-mtk-sysirq.c
> @@ -231,4 +231,6 @@ static int __init mtk_sysirq_of_init(struct device_node
> *node,
> kfree(chip_data);
> return ret;
> }
> -IRQCHIP_DECLARE(mtk_sysirq, "mediatek,mt6577-sysirq", mtk_sysirq_of_init);
> +IRQCHIP_HYBRID_DRIVER_BEGIN(mtk_sysirq)
> +IRQCHIP_MATCH("mediatek,mt6577-sysirq", mtk_sysirq_of_init)
> +IRQCHIP_HYBRID_DRIVER_END(mtk_sysirq)
> --
> 2.28.0
>
Re: [PATCH 4/6] irqchip/mtk-cirq: Allow modular build
On Sat 12 Sep 07:51 CDT 2020, Marc Zyngier wrote:
> Switch the driver to a "hybrid probe" model which preserves the
> built-in behaviour while allowing the driver to be optionnally
> built as a module for development purposes.
>
Reviewed-by: Bjorn Andersson
> Signed-off-by: Marc Zyngier
> ---
> drivers/irqchip/irq-mtk-cirq.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/irqchip/irq-mtk-cirq.c b/drivers/irqchip/irq-mtk-cirq.c
> index 69ba8ce3c178..43e880b63ed2 100644
> --- a/drivers/irqchip/irq-mtk-cirq.c
> +++ b/drivers/irqchip/irq-mtk-cirq.c
> @@ -295,4 +295,6 @@ static int __init mtk_cirq_of_init(struct device_node
> *node,
> return ret;
> }
>
> -IRQCHIP_DECLARE(mtk_cirq, "mediatek,mtk-cirq", mtk_cirq_of_init);
> +IRQCHIP_HYBRID_DRIVER_BEGIN(mtk_cirq)
> +IRQCHIP_MATCH("mediatek,mtk-cirq", mtk_cirq_of_init)
> +IRQCHIP_HYBRID_DRIVER_END(mtk_cirq)
> --
> 2.28.0
>
Re: [PATCH 3/6] irqchip: Introduce IRQCHIP_HYBRID_DRIVER_{BEGIN,END} macros
On Sat 12 Sep 07:51 CDT 2020, Marc Zyngier wrote:
> Although we are trying to move to a world where a large number
> of irqchip drivers can safely be built as platform drivers
> the reality is that most endpoint drivers are not ready for that,
> and will fail to probe as they expect their interrupt controller
> to be up and running.
>
> A halfway house solution is to let the driver indicate that if
> it is built-in (i.e. not a module), then it must use the earily
> probe mechanism, IRQCHIP_DECLARE() style. Otherwise, it is a
> normal module implemenenting a platform driver, and we can
> fallback to the existing code.
>
> Hopefully we'll one day be able to drop this code altogether,
> but that's not for tomorrow.
>
Reviewed-by: Bjorn Andersson
> Signed-off-by: Marc Zyngier
> ---
> include/linux/irqchip.h | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/include/linux/irqchip.h b/include/linux/irqchip.h
> index f8f25e9f8200..31fc9d00101f 100644
> --- a/include/linux/irqchip.h
> +++ b/include/linux/irqchip.h
> @@ -50,6 +50,18 @@ static struct platform_driver drv_name##_driver = {
> \
> }; \
> builtin_platform_driver(drv_name##_driver)
>
> +#ifdef MODULE
> +#define IRQCHIP_HYBRID_DRIVER_BEGIN(drv) \
> + IRQCHIP_PLATFORM_DRIVER_BEGIN(drv)
> +#define IRQCHIP_HYBRID_DRIVER_END(drv) \
> + IRQCHIP_PLATFORM_DRIVER_END(drv)
> +#else
> +#define IRQCHIP_HYBRID_DRIVER_BEGIN(drv) \
> + _OF_DECLARE_ARRAY_START(irqchip, drv)
> +#define IRQCHIP_HYBRID_DRIVER_END(drv) \
> + _OF_DECLARE_ARRAY_END;
> +#endif
> +
> /*
> * This macro must be used by the different irqchip drivers to declare
> * the association between their version and their initialization function.
> --
> 2.28.0
>
Re: [PATCH 2/6] irqchip: Make IRQCHIP_MATCH() type safe
On Sat 12 Sep 07:51 CDT 2020, Marc Zyngier wrote:
> IRQCHIP_DECLARE() is backed by macros that perform some elementary
> type checking on the probe function. Unfortunately, IRQCHIP_MATCH()
> doesn't, risking difficult debugging sessions...
>
> Rewrite IRQCHIP_MATCH() in terms of _OF_DECLARE_ELMT() restore
> the missing type safety.
>
Reviewed-by: Bjorn Andersson
> Signed-off-by: Marc Zyngier
> ---
> include/linux/irqchip.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linux/irqchip.h b/include/linux/irqchip.h
> index 67351aac65ef..f8f25e9f8200 100644
> --- a/include/linux/irqchip.h
> +++ b/include/linux/irqchip.h
> @@ -33,7 +33,7 @@ extern int platform_irqchip_probe(struct platform_device
> *pdev);
> #define IRQCHIP_PLATFORM_DRIVER_BEGIN(drv_name) \
> static const struct of_device_id drv_name##_irqchip_match_table[] = {
>
> -#define IRQCHIP_MATCH(compat, fn) { .compatible = compat, .data = fn },
> +#define IRQCHIP_MATCH(compat, fn) _OF_DECLARE_ELMT(compat, fn, of_init_fn_2)
>
> #define IRQCHIP_PLATFORM_DRIVER_END(drv_name)
> \
> {}, \
> --
> 2.28.0
>
Re: [PATCH 1/6] of: Add basic infrastructure to create early probe arrays
On Sat 12 Sep 07:51 CDT 2020, Marc Zyngier wrote:
> We currently probe interrupt controller and timers that need
> to be available very early using an infratstructure that creates
> struct of_device_id instances in a special section. These are
> individual structures that are ultimately collated by the linker.
>
> In order to facilitate further use of this infrastructure for
> drivers that can either be built modular or as an early driver,
> let's add a couple of helpers that will make it look like a
> "normal" device_id array, like this:
>
> _OF_DECLARE_ARRAY_START(table, name)
> _OF_DECLARE_ELMT("compat-1", probe, type)
> _OF_DECLARE_ELMT("compat-2", probe, type)
> _OF_DECLARE_ELMT("compat-3", other_probe, type)
> _OF_DECLARE_ARRAY_END
>
Reviewed-by: Bjorn Andersson
Regards,
Bjorn
> Signed-off-by: Marc Zyngier
> ---
> include/linux/of.h | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/include/linux/of.h b/include/linux/of.h
> index 5cf7ae0465d1..08f78da95378 100644
> --- a/include/linux/of.h
> +++ b/include/linux/of.h
> @@ -1291,20 +1291,35 @@ static inline int of_get_available_child_count(const
> struct device_node *np)
> return num;
> }
>
> +#define __OF_DECLARE_ARRAY_START(name, section)
> \
> + static const struct of_device_id __of_table_##name[]\
> + __used __section(section) = {
> +
> #if defined(CONFIG_OF) && !defined(MODULE)
> #define _OF_DECLARE(table, name, compat, fn, fn_type)
> \
> static const struct of_device_id __of_table_##name \
> __used __section(__##table##_of_table) \
>= { .compatible = compat, \
>.data = (fn == (fn_type)NULL) ? fn : fn }
> +#define _OF_DECLARE_ARRAY_START(table, name) \
> + __OF_DECLARE_ARRAY_START(name, __##table##_of_table)
> #else
> #define _OF_DECLARE(table, name, compat, fn, fn_type)
> \
> static const struct of_device_id __of_table_##name \
> __attribute__((unused)) \
>= { .compatible = compat, \
>.data = (fn == (fn_type)NULL) ? fn : fn }
> +#define _OF_DECLARE_ARRAY_START(table, name) \
> + __OF_DECLARE_ARRAY_START(name, unused)
> #endif
>
> +#define _OF_DECLARE_ARRAY_END}
> +#define _OF_DECLARE_ELMT(compat, fn, fn_type)
> \
> + { \
> + .compatible = compat, \
> + .data = (fn == (fn_type)NULL) ? fn : fn,\
> + },
> +
> typedef int (*of_init_fn_2)(struct device_node *, struct device_node *);
> typedef int (*of_init_fn_1_ret)(struct device_node *);
> typedef void (*of_init_fn_1)(struct device_node *);
> --
> 2.28.0
>
Re: [PATCH] spi: spi-geni-qcom: Don't wait to start 1st transfer if transmitting
On Sat 12 Sep 13:17 CDT 2020, Douglas Anderson wrote:
> If we're sending bytes over SPI, we know the FIFO is empty at the
> start of the transfer. There's no reason to wait for the interrupt
> telling us to start--we can just start right away. Then if we
> transmit everything in one swell foop we don't even need to bother
> listening for TX interrupts.
>
> In a test of "flashrom -p ec -r /tmp/foo.bin" interrupts were reduced
> from ~30560 to ~29730, about a 3% savings.
>
> This patch looks bigger than it is because I moved a few functions
> rather than adding a forward declaration. The only actual change to
> geni_spi_handle_tx() was to make it return a bool indicating if there
> is more to tx.
>
Reviewed-by: Bjorn Andersson
Regards,
Bjorn
> Signed-off-by: Douglas Anderson
> ---
>
> drivers/spi/spi-geni-qcom.c | 167 +++-
> 1 file changed, 86 insertions(+), 81 deletions(-)
>
> diff --git a/drivers/spi/spi-geni-qcom.c b/drivers/spi/spi-geni-qcom.c
> index 0dc3f4c55b0b..49c9eb870755 100644
> --- a/drivers/spi/spi-geni-qcom.c
> +++ b/drivers/spi/spi-geni-qcom.c
> @@ -326,6 +326,88 @@ static int spi_geni_init(struct spi_geni_master *mas)
> return 0;
> }
>
> +static unsigned int geni_byte_per_fifo_word(struct spi_geni_master *mas)
> +{
> + /*
> + * Calculate how many bytes we'll put in each FIFO word. If the
> + * transfer words don't pack cleanly into a FIFO word we'll just put
> + * one transfer word in each FIFO word. If they do pack we'll pack 'em.
> + */
> + if (mas->fifo_width_bits % mas->cur_bits_per_word)
> + return roundup_pow_of_two(DIV_ROUND_UP(mas->cur_bits_per_word,
> +BITS_PER_BYTE));
> +
> + return mas->fifo_width_bits / BITS_PER_BYTE;
> +}
> +
> +static bool geni_spi_handle_tx(struct spi_geni_master *mas)
> +{
> + struct geni_se *se = >se;
> + unsigned int max_bytes;
> + const u8 *tx_buf;
> + unsigned int bytes_per_fifo_word = geni_byte_per_fifo_word(mas);
> + unsigned int i = 0;
> +
> + max_bytes = (mas->tx_fifo_depth - mas->tx_wm) * bytes_per_fifo_word;
> + if (mas->tx_rem_bytes < max_bytes)
> + max_bytes = mas->tx_rem_bytes;
> +
> + tx_buf = mas->cur_xfer->tx_buf + mas->cur_xfer->len - mas->tx_rem_bytes;
> + while (i < max_bytes) {
> + unsigned int j;
> + unsigned int bytes_to_write;
> + u32 fifo_word = 0;
> + u8 *fifo_byte = (u8 *)_word;
> +
> + bytes_to_write = min(bytes_per_fifo_word, max_bytes - i);
> + for (j = 0; j < bytes_to_write; j++)
> + fifo_byte[j] = tx_buf[i++];
> + iowrite32_rep(se->base + SE_GENI_TX_FIFOn, _word, 1);
> + }
> + mas->tx_rem_bytes -= max_bytes;
> + if (!mas->tx_rem_bytes) {
> + writel(0, se->base + SE_GENI_TX_WATERMARK_REG);
> + return false;
> + }
> + return true;
> +}
> +
> +static void geni_spi_handle_rx(struct spi_geni_master *mas)
> +{
> + struct geni_se *se = >se;
> + u32 rx_fifo_status;
> + unsigned int rx_bytes;
> + unsigned int rx_last_byte_valid;
> + u8 *rx_buf;
> + unsigned int bytes_per_fifo_word = geni_byte_per_fifo_word(mas);
> + unsigned int i = 0;
> +
> + rx_fifo_status = readl(se->base + SE_GENI_RX_FIFO_STATUS);
> + rx_bytes = (rx_fifo_status & RX_FIFO_WC_MSK) * bytes_per_fifo_word;
> + if (rx_fifo_status & RX_LAST) {
> + rx_last_byte_valid = rx_fifo_status & RX_LAST_BYTE_VALID_MSK;
> + rx_last_byte_valid >>= RX_LAST_BYTE_VALID_SHFT;
> + if (rx_last_byte_valid && rx_last_byte_valid < 4)
> + rx_bytes -= bytes_per_fifo_word - rx_last_byte_valid;
> + }
> + if (mas->rx_rem_bytes < rx_bytes)
> + rx_bytes = mas->rx_rem_bytes;
> +
> + rx_buf = mas->cur_xfer->rx_buf + mas->cur_xfer->len - mas->rx_rem_bytes;
> + while (i < rx_bytes) {
> + u32 fifo_word = 0;
> + u8 *fifo_byte = (u8 *)_word;
> + unsigned int bytes_to_read;
> + unsigned int j;
> +
> + bytes_to_read = min(bytes_per_fifo_word, rx_bytes - i);
> + ioread32_rep(se->base + SE_GENI_RX_FIFOn, _word, 1);
> + for (j = 0; j < bytes_to_read; j++)
> + rx_buf[i++] = fifo_byte[j];
> + }
> + mas->rx_rem_bytes -= rx_bytes;
> +}
> +
> static void setup_fifo_xfer(struct spi_transfer *xfer,
> struct spi_geni_master *mas,
> u16 mode, struct spi_master *spi)
> @@ -398,8 +480,10 @@ static void setup_fifo_xfer(struct spi_transfer *xfer,
>* setting up GENI SE engine, as driver starts data transfer
>* for the watermark interrupt.
>*/
> - if (m_cmd & SPI_TX_ONLY)
> - writel(mas->tx_wm, se->base + SE_GENI_TX_WATERMARK_REG);
> + if (m_cmd &
Re: [PATCH 2/3] spi: spi-geni-qcom: Don't program CS_TOGGLE again and again
On Sat 12 Sep 16:08 CDT 2020, Douglas Anderson wrote:
> We always toggle the chip select manually in spi-geni-qcom so that we
> can properly implement the Linux API. There's no reason to program
> this to the hardware on every transfer. Program it once at init and
> be done with it.
>
> This saves some part of a microsecond of overhead on each transfer.
> While not really noticeable on any real world benchmarks, we might as
> well save the time.
>
Reviewed-by: Bjorn Andersson
Regards,
Bjorn
> Signed-off-by: Douglas Anderson
> ---
>
> drivers/spi/spi-geni-qcom.c | 12 +++-
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/spi/spi-geni-qcom.c b/drivers/spi/spi-geni-qcom.c
> index 7f0bf0dec466..92d88bf85a90 100644
> --- a/drivers/spi/spi-geni-qcom.c
> +++ b/drivers/spi/spi-geni-qcom.c
> @@ -290,6 +290,7 @@ static int spi_geni_init(struct spi_geni_master *mas)
> {
> struct geni_se *se = >se;
> unsigned int proto, major, minor, ver;
> + u32 spi_tx_cfg;
>
> pm_runtime_get_sync(mas->dev);
>
> @@ -322,6 +323,11 @@ static int spi_geni_init(struct spi_geni_master *mas)
>
> geni_se_select_mode(se, GENI_SE_FIFO);
>
> + /* We always control CS manually */
> + spi_tx_cfg = readl(se->base + SE_SPI_TRANS_CFG);
> + spi_tx_cfg &= ~CS_TOGGLE;
> + writel(spi_tx_cfg, se->base + SE_SPI_TRANS_CFG);
> +
> pm_runtime_put(mas->dev);
> return 0;
> }
> @@ -331,7 +337,7 @@ static void setup_fifo_xfer(struct spi_transfer *xfer,
> u16 mode, struct spi_master *spi)
> {
> u32 m_cmd = 0;
> - u32 spi_tx_cfg, len;
> + u32 len;
> struct geni_se *se = >se;
> int ret;
>
> @@ -350,7 +356,6 @@ static void setup_fifo_xfer(struct spi_transfer *xfer,
> spin_lock_irq(>lock);
> spin_unlock_irq(>lock);
>
> - spi_tx_cfg = readl(se->base + SE_SPI_TRANS_CFG);
> if (xfer->bits_per_word != mas->cur_bits_per_word) {
> spi_setup_word_len(mas, mode, xfer->bits_per_word);
> mas->cur_bits_per_word = xfer->bits_per_word;
> @@ -364,8 +369,6 @@ static void setup_fifo_xfer(struct spi_transfer *xfer,
> mas->tx_rem_bytes = 0;
> mas->rx_rem_bytes = 0;
>
> - spi_tx_cfg &= ~CS_TOGGLE;
> -
> if (!(mas->cur_bits_per_word % MIN_WORD_LEN))
> len = xfer->len * BITS_PER_BYTE / mas->cur_bits_per_word;
> else
> @@ -384,7 +387,6 @@ static void setup_fifo_xfer(struct spi_transfer *xfer,
> writel(len, se->base + SE_SPI_RX_TRANS_LEN);
> mas->rx_rem_bytes = xfer->len;
> }
> - writel(spi_tx_cfg, se->base + SE_SPI_TRANS_CFG);
>
> /*
>* Lock around right before we start the transfer since our
> --
> 2.28.0.618.gf4bc123cb7-goog
>
Re: [PATCH 3/3] spi: spi-geni-qcom: Slightly optimize setup of bidirectional xfters
On Sat 12 Sep 16:08 CDT 2020, Douglas Anderson wrote:
> When setting up a bidirectional transfer we need to program both the
> TX and RX lengths. We don't need a memory barrier between those two
> writes. Factor out the __iowmb() and use writel_relaxed(). This
> saves a fraction of a microsecond of setup overhead on bidirectional
> transfers.
>
> Signed-off-by: Douglas Anderson
> ---
>
> drivers/spi/spi-geni-qcom.c | 13 ++---
> 1 file changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/spi/spi-geni-qcom.c b/drivers/spi/spi-geni-qcom.c
> index 92d88bf85a90..6c7e12b68bf0 100644
> --- a/drivers/spi/spi-geni-qcom.c
> +++ b/drivers/spi/spi-geni-qcom.c
> @@ -376,15 +376,22 @@ static void setup_fifo_xfer(struct spi_transfer *xfer,
> len &= TRANS_LEN_MSK;
>
> mas->cur_xfer = xfer;
> +
> + /*
> + * Factor out the __iowmb() so that we can use writel_relaxed() for
> + * both writes below and thus only incur the overhead once even if
> + * we execute both of them.
> + */
How many passes through this function do we have to take before saving
the amount of time it took me to read this comment?
Reviewed-by: Bjorn Andersson
Regards,
Bjorn
> + __iowmb();
> +
> if (xfer->tx_buf) {
> m_cmd |= SPI_TX_ONLY;
> mas->tx_rem_bytes = xfer->len;
> - writel(len, se->base + SE_SPI_TX_TRANS_LEN);
> + writel_relaxed(len, se->base + SE_SPI_TX_TRANS_LEN);
> }
> -
> if (xfer->rx_buf) {
> m_cmd |= SPI_RX_ONLY;
> - writel(len, se->base + SE_SPI_RX_TRANS_LEN);
> + writel_relaxed(len, se->base + SE_SPI_RX_TRANS_LEN);
> mas->rx_rem_bytes = xfer->len;
> }
>
> --
> 2.28.0.618.gf4bc123cb7-goog
>
Re: [PATCH 1/3] spi: spi-geni-qcom: Use the FIFO even more
On Sat 12 Sep 16:07 CDT 2020, Douglas Anderson wrote:
> In commit 902481a78ee4 ("spi: spi-geni-qcom: Actually use our FIFO") I
> explained that the maximum size we could program the FIFO was
> "mas->tx_fifo_depth - 3" but that I chose "mas->tx_fifo_depth()"
> because I was worried about decreased bandwidth.
>
> Since that time:
> * All the interconnect patches have landed, making things run at the
> proper speed.
> * I've done more measurements.
>
> This lets me confirm that there's really no downside of using the FIFO
> more. Specifically I did "flashrom -p ec -r /tmp/foo.bin" on a
> Chromebook and averaged over several runs.
Wouldn't there be a downside in the form of setting the watermark that
close to the full FIFO we have less room for being late handling the
interrupt? Or is there some mechanism involved that will prevent
the FIFO from being overrun?
Regards,
Bjorn
>
> Before: It took 6.66 seconds and 59669 interrupts fired.
> After: It took 6.66 seconds and 47992 interrupts fired.
>
> Signed-off-by: Douglas Anderson
> ---
>
> drivers/spi/spi-geni-qcom.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/spi/spi-geni-qcom.c b/drivers/spi/spi-geni-qcom.c
> index 0dc3f4c55b0b..7f0bf0dec466 100644
> --- a/drivers/spi/spi-geni-qcom.c
> +++ b/drivers/spi/spi-geni-qcom.c
> @@ -308,7 +308,7 @@ static int spi_geni_init(struct spi_geni_master *mas)
>* Hardware programming guide suggests to configure
>* RX FIFO RFR level to fifo_depth-2.
>*/
> - geni_se_init(se, mas->tx_fifo_depth / 2, mas->tx_fifo_depth - 2);
> + geni_se_init(se, mas->tx_fifo_depth - 3, mas->tx_fifo_depth - 2);
> /* Transmit an entire FIFO worth of data per IRQ */
> mas->tx_wm = 1;
> ver = geni_se_get_qup_hw_version(se);
> --
> 2.28.0.618.gf4bc123cb7-goog
>
Re: [PATCH v12 0/5] Add support for DisplayPort driver on SnapDragon
Thanks Rob for pushing the changes. I confirm that the versions which you have pushed are the latest ones. I have rebased audio changes on top of the latest DP changes and posted them here https://patchwork.freedesktop.org/series/81612/. The other DP change which is missing is the video pattern CTS change https://patchwork.freedesktop.org/series/81614/ which also I have now rebased on top of the latest DP patch series and posted. Thanks Abhinav On 2020-09-12 11:25, Rob Clark wrote: Fyi, I've pushed this series and the dp-compliance bits to msm-next-dp[1] I didn't include the dp audio series yet, which seems to need some minor rebasing. (And a small request, when resending, cc freedr...@lists.freedesktop.org, so it shows up in the patchwork instance[2] I use) You might want to double check that I got the correct versions of the series, etc. And that nothing else (other than audio) is missing. BR, -R [1] https://gitlab.freedesktop.org/drm/msm/-/commits/msm-next-dp [2] https://patchwork.freedesktop.org/project/freedreno On Thu, Aug 27, 2020 at 2:17 PM Tanmay Shah wrote: These patches add Display-Port driver on SnapDragon/msm hardware. This series also contains device-tree bindings for msm DP driver. It also contains Makefile and Kconfig changes to compile msm DP driver. The block diagram of DP driver is shown below: +-+ |DRM FRAMEWORK| +--+--+ | +v+ | DP DRM | +++ | +v+ ++| DP+--++--+ ++---+| DISPLAY |+---+ | | |++-+-+-+| | | || | | | | | || | | | | | || | | | | | vv v v v v v +--+ +--+ +---+ ++ ++ +---+ +-+ | DP | | DP | |DP | | DP | | DP | |DP | | DP | |PARSER| | HPD | |AUX| |LINK| |CTRL| |PHY| |POWER| +--+---+ +---+--+ +---+ ++ +--+-+ +-+-+ +-+ | | | +--v---+ +v-v+ |DEVICE| | DP | | TREE | |CATALOG| +--+ +---+---+ | +---v+ |CTRL/PHY| | HW | ++ Changes in v12: -- Add support of pm ops in display port driver -- Clear bpp depth bits before writing to MISC register -- Fix edid read Previous change log: https://lkml.kernel.org/lkml/20200818051137.21478-1-tan...@codeaurora.org/ Chandan Uddaraju (4): dt-bindings: msm/dp: add bindings of DP/DP-PLL driver for Snapdragon drm: add constant N value in helper file drm/msm/dp: add displayPort driver support drm/msm/dp: add support for DP PLL driver Jeykumar Sankaran (1): drm/msm/dpu: add display port support in DPU Tanmay Shah (1): drm/msm/dp: Add Display Port HPD feature drivers/gpu/drm/i915/display/intel_display.c |2 +- drivers/gpu/drm/msm/Kconfig |9 + drivers/gpu/drm/msm/Makefile | 14 + drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 27 +- .../drm/msm/disp/dpu1/dpu_encoder_phys_vid.c |8 + drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 83 +- drivers/gpu/drm/msm/dp/dp_aux.c | 535 ++ drivers/gpu/drm/msm/dp/dp_aux.h | 30 + drivers/gpu/drm/msm/dp/dp_catalog.c | 1045 ++ drivers/gpu/drm/msm/dp/dp_catalog.h | 105 + drivers/gpu/drm/msm/dp/dp_ctrl.c | 1693 + drivers/gpu/drm/msm/dp/dp_ctrl.h | 35 + drivers/gpu/drm/msm/dp/dp_display.c | 1046 ++ drivers/gpu/drm/msm/dp/dp_display.h | 31 + drivers/gpu/drm/msm/dp/dp_drm.c | 168 ++ drivers/gpu/drm/msm/dp/dp_drm.h | 18 + drivers/gpu/drm/msm/dp/dp_hpd.c | 69 + drivers/gpu/drm/msm/dp/dp_hpd.h | 79 + drivers/gpu/drm/msm/dp/dp_link.c | 1214 drivers/gpu/drm/msm/dp/dp_link.h | 132 ++ drivers/gpu/drm/msm/dp/dp_panel.c | 486 + drivers/gpu/drm/msm/dp/dp_panel.h | 95 + drivers/gpu/drm/msm/dp/dp_parser.c| 267 +++ drivers/gpu/drm/msm/dp/dp_parser.h| 138 ++ drivers/gpu/drm/msm/dp/dp_pll.c | 99 + drivers/gpu/drm/msm/dp/dp_pll.h | 61 + drivers/gpu/drm/msm/dp/dp_pll_10nm.c | 930 + drivers/gpu/drm/msm/dp/dp_pll_private.h | 89 + drivers/gpu/drm/msm/dp/dp_power.c | 373 drivers/gpu/drm/msm/dp/dp_power.h | 103 +
[PATCH 2/3] spi: spi-geni-qcom: Don't program CS_TOGGLE again and again
We always toggle the chip select manually in spi-geni-qcom so that we
can properly implement the Linux API. There's no reason to program
this to the hardware on every transfer. Program it once at init and
be done with it.
This saves some part of a microsecond of overhead on each transfer.
While not really noticeable on any real world benchmarks, we might as
well save the time.
Signed-off-by: Douglas Anderson
---
drivers/spi/spi-geni-qcom.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/spi/spi-geni-qcom.c b/drivers/spi/spi-geni-qcom.c
index 7f0bf0dec466..92d88bf85a90 100644
--- a/drivers/spi/spi-geni-qcom.c
+++ b/drivers/spi/spi-geni-qcom.c
@@ -290,6 +290,7 @@ static int spi_geni_init(struct spi_geni_master *mas)
{
struct geni_se *se = >se;
unsigned int proto, major, minor, ver;
+ u32 spi_tx_cfg;
pm_runtime_get_sync(mas->dev);
@@ -322,6 +323,11 @@ static int spi_geni_init(struct spi_geni_master *mas)
geni_se_select_mode(se, GENI_SE_FIFO);
+ /* We always control CS manually */
+ spi_tx_cfg = readl(se->base + SE_SPI_TRANS_CFG);
+ spi_tx_cfg &= ~CS_TOGGLE;
+ writel(spi_tx_cfg, se->base + SE_SPI_TRANS_CFG);
+
pm_runtime_put(mas->dev);
return 0;
}
@@ -331,7 +337,7 @@ static void setup_fifo_xfer(struct spi_transfer *xfer,
u16 mode, struct spi_master *spi)
{
u32 m_cmd = 0;
- u32 spi_tx_cfg, len;
+ u32 len;
struct geni_se *se = >se;
int ret;
@@ -350,7 +356,6 @@ static void setup_fifo_xfer(struct spi_transfer *xfer,
spin_lock_irq(>lock);
spin_unlock_irq(>lock);
- spi_tx_cfg = readl(se->base + SE_SPI_TRANS_CFG);
if (xfer->bits_per_word != mas->cur_bits_per_word) {
spi_setup_word_len(mas, mode, xfer->bits_per_word);
mas->cur_bits_per_word = xfer->bits_per_word;
@@ -364,8 +369,6 @@ static void setup_fifo_xfer(struct spi_transfer *xfer,
mas->tx_rem_bytes = 0;
mas->rx_rem_bytes = 0;
- spi_tx_cfg &= ~CS_TOGGLE;
-
if (!(mas->cur_bits_per_word % MIN_WORD_LEN))
len = xfer->len * BITS_PER_BYTE / mas->cur_bits_per_word;
else
@@ -384,7 +387,6 @@ static void setup_fifo_xfer(struct spi_transfer *xfer,
writel(len, se->base + SE_SPI_RX_TRANS_LEN);
mas->rx_rem_bytes = xfer->len;
}
- writel(spi_tx_cfg, se->base + SE_SPI_TRANS_CFG);
/*
* Lock around right before we start the transfer since our
--
2.28.0.618.gf4bc123cb7-goog
[PATCH 3/3] spi: spi-geni-qcom: Slightly optimize setup of bidirectional xfters
When setting up a bidirectional transfer we need to program both the
TX and RX lengths. We don't need a memory barrier between those two
writes. Factor out the __iowmb() and use writel_relaxed(). This
saves a fraction of a microsecond of setup overhead on bidirectional
transfers.
Signed-off-by: Douglas Anderson
---
drivers/spi/spi-geni-qcom.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/spi/spi-geni-qcom.c b/drivers/spi/spi-geni-qcom.c
index 92d88bf85a90..6c7e12b68bf0 100644
--- a/drivers/spi/spi-geni-qcom.c
+++ b/drivers/spi/spi-geni-qcom.c
@@ -376,15 +376,22 @@ static void setup_fifo_xfer(struct spi_transfer *xfer,
len &= TRANS_LEN_MSK;
mas->cur_xfer = xfer;
+
+ /*
+* Factor out the __iowmb() so that we can use writel_relaxed() for
+* both writes below and thus only incur the overhead once even if
+* we execute both of them.
+*/
+ __iowmb();
+
if (xfer->tx_buf) {
m_cmd |= SPI_TX_ONLY;
mas->tx_rem_bytes = xfer->len;
- writel(len, se->base + SE_SPI_TX_TRANS_LEN);
+ writel_relaxed(len, se->base + SE_SPI_TX_TRANS_LEN);
}
-
if (xfer->rx_buf) {
m_cmd |= SPI_RX_ONLY;
- writel(len, se->base + SE_SPI_RX_TRANS_LEN);
+ writel_relaxed(len, se->base + SE_SPI_RX_TRANS_LEN);
mas->rx_rem_bytes = xfer->len;
}
--
2.28.0.618.gf4bc123cb7-goog
[PATCH 1/3] spi: spi-geni-qcom: Use the FIFO even more
In commit 902481a78ee4 ("spi: spi-geni-qcom: Actually use our FIFO") I
explained that the maximum size we could program the FIFO was
"mas->tx_fifo_depth - 3" but that I chose "mas->tx_fifo_depth()"
because I was worried about decreased bandwidth.
Since that time:
* All the interconnect patches have landed, making things run at the
proper speed.
* I've done more measurements.
This lets me confirm that there's really no downside of using the FIFO
more. Specifically I did "flashrom -p ec -r /tmp/foo.bin" on a
Chromebook and averaged over several runs.
Before: It took 6.66 seconds and 59669 interrupts fired.
After: It took 6.66 seconds and 47992 interrupts fired.
Signed-off-by: Douglas Anderson
---
drivers/spi/spi-geni-qcom.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/spi/spi-geni-qcom.c b/drivers/spi/spi-geni-qcom.c
index 0dc3f4c55b0b..7f0bf0dec466 100644
--- a/drivers/spi/spi-geni-qcom.c
+++ b/drivers/spi/spi-geni-qcom.c
@@ -308,7 +308,7 @@ static int spi_geni_init(struct spi_geni_master *mas)
* Hardware programming guide suggests to configure
* RX FIFO RFR level to fifo_depth-2.
*/
- geni_se_init(se, mas->tx_fifo_depth / 2, mas->tx_fifo_depth - 2);
+ geni_se_init(se, mas->tx_fifo_depth - 3, mas->tx_fifo_depth - 2);
/* Transmit an entire FIFO worth of data per IRQ */
mas->tx_wm = 1;
ver = geni_se_get_qup_hw_version(se);
--
2.28.0.618.gf4bc123cb7-goog
RE: [PATCH 01/24] inet_net_pton.3: Use 'PRIx32' rather than "%x" when printing 'uint32_t' values
From: Michael Kerrisk
> Sent: 11 September 2020 10:31
>
> Hi Alex,
>
> On 9/10/20 11:13 PM, Alejandro Colomar wrote:
> > Signed-off-by: Alejandro Colomar
> > ---
> > man3/inet_net_pton.3 | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/man3/inet_net_pton.3 b/man3/inet_net_pton.3
> > index 00f94b9d4..d74a33d74 100644
> > --- a/man3/inet_net_pton.3
> > +++ b/man3/inet_net_pton.3
> > @@ -332,6 +332,7 @@ Raw address: c1a80180
> > /* Link with "\-lresolv" */
> >
> > #include
> > +#include
> > #include
> > #include
> >
> > @@ -381,7 +382,7 @@ main(int argc, char *argv[])
> > may not have been touched by inet_net_ntop(), and so will still
> > have any initial value that was specified in argv[2]. */
> >
> > -printf("Raw address: %x\en", htonl(addr.s_addr));
> > +printf("Raw address: %"PRIx32"\en", htonl(addr.s_addr));
> >
> > exit(EXIT_SUCCESS);
> > }
>
> So, I'm in a little bit of doubt about patches 01 and 02. Does
> this really win us anything? On the one hand, %"PRIx32" is more
> difficult to read than %x. On the other, does it win us anything
> in terms of portability? At first glance, the answers seems to me
> to be "no". Your thoughts?
On 32bit systems uint32_t might be either 'int' or 'long'.
So the format has to match - even though the ABI is probably
the same in both cases.
Mind you, htonl() itself could be problematic.
On BE systems it is likely to be #define htonl(x) (x)
so the type is whatever was passed.
On LE systems it might even be long htonl(long)
- which is its historic prototype.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT,
UK
Registration No: 1397386 (Wales)
Re: [PATCH v3 0/10] libperf and arm64 userspace counter access support
On Fri, Sep 11, 2020 at 03:51:08PM -0600, Rob Herring wrote: > This is resurrecting Raphael's series[1] to enable userspace counter > access on arm64. My previous versions are here[2][3]. > > Changes in v3: > - Dropped removing x86 rdpmc test until libperf tests can run via 'perf test' > - Added verbose prints for tests > - Split adding perf_evsel__mmap() to separate patch hi, which commit/branch did you base on? I can't apply arm bits: Applying: arm64: pmu: Add hook to handle pmu-related undefined instructions Applying: arm64: perf: Enable pmu counter direct access for perf event on armv8 error: patch failed: arch/arm64/kernel/perf_event.c:836 error: arch/arm64/kernel/perf_event.c: patch does not apply Patch failed at 0002 arm64: perf: Enable pmu counter direct access for perf event on armv8 thanks, jirka
Re: [PATCH] perf bench: Fix 2 memory sanitizer warnings
On Fri, Sep 11, 2020 at 10:37:25PM -0700, Ian Rogers wrote:
> Memory sanitizer warns if a write is performed where the memory
> being read for the write is uninitialized. Avoid this warning by
> initializing the memory.
>
> Signed-off-by: Ian Rogers
Acked-by: Jiri Olsa
thanks,
jirka
> ---
> tools/perf/bench/sched-messaging.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/tools/perf/bench/sched-messaging.c
> b/tools/perf/bench/sched-messaging.c
> index 71d830d7b923..cecce93ccc63 100644
> --- a/tools/perf/bench/sched-messaging.c
> +++ b/tools/perf/bench/sched-messaging.c
> @@ -66,11 +66,10 @@ static void fdpair(int fds[2])
> /* Block until we're ready to go */
> static void ready(int ready_out, int wakefd)
> {
> - char dummy;
> struct pollfd pollfd = { .fd = wakefd, .events = POLLIN };
>
> /* Tell them we're ready. */
> - if (write(ready_out, , 1) != 1)
> + if (write(ready_out, "R", 1) != 1)
> err(EXIT_FAILURE, "CLIENT: ready write");
>
> /* Wait for "GO" signal */
> @@ -85,6 +84,7 @@ static void *sender(struct sender_context *ctx)
> unsigned int i, j;
>
> ready(ctx->ready_out, ctx->wakefd);
> + memset(data, 'S', sizeof(data));
>
> /* Now pump to every receiver. */
> for (i = 0; i < nr_loops; i++) {
> --
> 2.28.0.618.gf4bc123cb7-goog
>
Re: [PATCH v3 0/4] Fixes for setting event freq/periods
On Fri, Sep 11, 2020 at 07:56:51PM -0700, Ian Rogers wrote: > Some fixes that address issues for regular and pfm4 events with 2 > additional perf_event_attr tests. Various authors, David Sharp isn't > currently at Google. > > v3. moved a loop into a helper following Adrian Hunter's suggestion. > v2. corrects the commit message following Athira Rajeev's suggestion. > > David Sharp (1): > perf record: Set PERF_RECORD_PERIOD if attr->freq is set. > > Ian Rogers (2): > perf record: Don't clear event's period if set by a term > perf test: Leader sampling shouldn't clear sample period > > Stephane Eranian (1): > perf record: Prevent override of attr->sample_period for libpfm4 > events Acked-by: Jiri Olsa thanks, jirka > > tools/perf/tests/attr/README | 1 + > tools/perf/tests/attr/test-record-group2 | 29 > tools/perf/util/evsel.c | 10 --- > tools/perf/util/record.c | 34 ++-- > 4 files changed, 63 insertions(+), 11 deletions(-) > create mode 100644 tools/perf/tests/attr/test-record-group2 > > -- > 2.28.0.618.gf4bc123cb7-goog >
[PATCH 2/3] phy: cadence: salvo: Constify cdns_nxp_sequence_pair
cdns_nxp_sequence_pair[] are never modified and can be made const to allow
the compiler to put them in read-only memory.
Signed-off-by: Rikard Falkeborn
---
drivers/phy/cadence/phy-cadence-salvo.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/phy/cadence/phy-cadence-salvo.c
b/drivers/phy/cadence/phy-cadence-salvo.c
index 8c33d3215f2d..88e239adc3b8 100644
--- a/drivers/phy/cadence/phy-cadence-salvo.c
+++ b/drivers/phy/cadence/phy-cadence-salvo.c
@@ -97,7 +97,7 @@ struct cdns_reg_pairs {
struct cdns_salvo_data {
u8 reg_offset_shift;
- struct cdns_reg_pairs *init_sequence_val;
+ const struct cdns_reg_pairs *init_sequence_val;
u8 init_sequence_length;
};
@@ -126,7 +126,7 @@ static void cdns_salvo_write(struct cdns_salvo_phy
*salvo_phy,
* Below bringup sequence pair are from Cadence PHY's User Guide
* and NXP platform tuning results.
*/
-static struct cdns_reg_pairs cdns_nxp_sequence_pair[] = {
+static const struct cdns_reg_pairs cdns_nxp_sequence_pair[] = {
{0x0830, PHY_PMA_CMN_CTRL1},
{0x0010, TB_ADDR_CMN_DIAG_HSCLK_SEL},
{0x00f0, TB_ADDR_CMN_PLL0_VCOCAL_INIT_TMR},
@@ -217,7 +217,7 @@ static int cdns_salvo_phy_init(struct phy *phy)
return ret;
for (i = 0; i < data->init_sequence_length; i++) {
- struct cdns_reg_pairs *reg_pair = data->init_sequence_val + i;
+ const struct cdns_reg_pairs *reg_pair = data->init_sequence_val
+ i;
cdns_salvo_write(salvo_phy, reg_pair->off, reg_pair->val);
}
--
2.28.0
Re: [RESEND][RFC PATCH 0/6] Fork brute force attack mitigation (fbfam)
On Sat, Sep 12, 2020 at 4:51 PM Mel Gorman wrote:
> On Sat, Sep 12, 2020 at 11:36:52AM +0200, John Wood wrote:
> > On Sat, Sep 12, 2020 at 12:56:18AM -0700, Kees Cook wrote:
> > > On Sat, Sep 12, 2020 at 10:03:23AM +1000, James Morris wrote:
> > > > On Thu, 10 Sep 2020, Kees Cook wrote:
> > > >
> > > > > [kees: re-sending this series on behalf of John Wood
> > > > >
> > > > > also visible at https://github.com/johwood/linux fbfam]
> > > > >
> > > > > From: John Wood
> > > >
> > > > Why are you resending this? The author of the code needs to be able to
> > > > send and receive emails directly as part of development and maintenance.
> >
> > I tried to send the full patch serie by myself but my email got blocked.
> > After
> > get support from my email provider it told to me that my account is young,
> > and due to its spam policie I am not allow, for now, to send a big amount
> > of mails in a short period. They also informed me that soon I will be able
> > to send more mails. The quantity increase with the age of the account.
> >
>
> If you're using "git send-email" then specify --confirm=always and
> either manually send a mail every few seconds or use an expect script
> like
>
> #!/bin/bash
> EXPECT_SCRIPT=
> function cleanup() {
> if [ "$EXPECT_SCRIPT" != "" ]; then
> rm $EXPECT_SCRIPT
> fi
> }
> trap cleanup EXIT
>
> EXPECT_SCRIPT=`mktemp`
> cat > $EXPECT_SCRIPT < spawn sh ./SEND
> expect {
> "Send this email" { sleep 10; exp_send y\\r; exp_continue }
> }
> EOF
>
> expect -f $EXPECT_SCRIPT
> exit $?
>
> This will work if your provider limits the rate mails are sent rather
> than the total amount.
...or you could keep it simple and just pass "--batch-size 1
--relogin-delay 10" to git send-email ;)
--
Ondrej Mosnacek
Software Engineer, Platform Security - SELinux kernel
Red Hat, Inc.
[PATCH 3/3] phy: cadence: torrent: Constify regmap_config structs
The regmap_config structs are never modified and can be made const to
allow the compiler to put them in read-only memory.
Signed-off-by: Rikard Falkeborn
---
drivers/phy/cadence/phy-cadence-torrent.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/phy/cadence/phy-cadence-torrent.c
b/drivers/phy/cadence/phy-cadence-torrent.c
index 7116127358ee..835bd7563f36 100644
--- a/drivers/phy/cadence/phy-cadence-torrent.c
+++ b/drivers/phy/cadence/phy-cadence-torrent.c
@@ -331,21 +331,21 @@ static int cdns_regmap_dptx_read(void *context, unsigned
int reg,
.reg_read = cdns_regmap_read, \
}
-static struct regmap_config cdns_torrent_tx_lane_cdb_config[] = {
+static const struct regmap_config cdns_torrent_tx_lane_cdb_config[] = {
TORRENT_TX_LANE_CDB_REGMAP_CONF("0"),
TORRENT_TX_LANE_CDB_REGMAP_CONF("1"),
TORRENT_TX_LANE_CDB_REGMAP_CONF("2"),
TORRENT_TX_LANE_CDB_REGMAP_CONF("3"),
};
-static struct regmap_config cdns_torrent_rx_lane_cdb_config[] = {
+static const struct regmap_config cdns_torrent_rx_lane_cdb_config[] = {
TORRENT_RX_LANE_CDB_REGMAP_CONF("0"),
TORRENT_RX_LANE_CDB_REGMAP_CONF("1"),
TORRENT_RX_LANE_CDB_REGMAP_CONF("2"),
TORRENT_RX_LANE_CDB_REGMAP_CONF("3"),
};
-static struct regmap_config cdns_torrent_common_cdb_config = {
+static const struct regmap_config cdns_torrent_common_cdb_config = {
.name = "torrent_common_cdb",
.reg_stride = 1,
.fast_io = true,
@@ -353,7 +353,7 @@ static struct regmap_config cdns_torrent_common_cdb_config
= {
.reg_read = cdns_regmap_read,
};
-static struct regmap_config cdns_torrent_phy_pcs_cmn_cdb_config = {
+static const struct regmap_config cdns_torrent_phy_pcs_cmn_cdb_config = {
.name = "torrent_phy_pcs_cmn_cdb",
.reg_stride = 1,
.fast_io = true,
@@ -361,7 +361,7 @@ static struct regmap_config
cdns_torrent_phy_pcs_cmn_cdb_config = {
.reg_read = cdns_regmap_read,
};
-static struct regmap_config cdns_torrent_phy_pma_cmn_cdb_config = {
+static const struct regmap_config cdns_torrent_phy_pma_cmn_cdb_config = {
.name = "torrent_phy_pma_cmn_cdb",
.reg_stride = 1,
.fast_io = true,
@@ -369,7 +369,7 @@ static struct regmap_config
cdns_torrent_phy_pma_cmn_cdb_config = {
.reg_read = cdns_regmap_read,
};
-static struct regmap_config cdns_torrent_dptx_phy_config = {
+static const struct regmap_config cdns_torrent_dptx_phy_config = {
.name = "torrent_dptx_phy",
.reg_stride = 1,
.fast_io = true,
--
2.28.0
[PATCH 1/3] phy: cadence: Sierra: Constify static structs
The static cdns_reg_pairs and regmap_config structs are not modified and
can be made const. This allows the compiler to put them in read-only
memory.
Signed-off-by: Rikard Falkeborn
---
drivers/phy/cadence/phy-cadence-sierra.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/phy/cadence/phy-cadence-sierra.c
b/drivers/phy/cadence/phy-cadence-sierra.c
index faed652b73f7..453ef26fa1c7 100644
--- a/drivers/phy/cadence/phy-cadence-sierra.c
+++ b/drivers/phy/cadence/phy-cadence-sierra.c
@@ -172,10 +172,10 @@ struct cdns_sierra_data {
u32 pcie_ln_regs;
u32 usb_cmn_regs;
u32 usb_ln_regs;
- struct cdns_reg_pairs *pcie_cmn_vals;
- struct cdns_reg_pairs *pcie_ln_vals;
- struct cdns_reg_pairs *usb_cmn_vals;
- struct cdns_reg_pairs *usb_ln_vals;
+ const struct cdns_reg_pairs *pcie_cmn_vals;
+ const struct cdns_reg_pairs *pcie_ln_vals;
+ const struct cdns_reg_pairs *usb_cmn_vals;
+ const struct cdns_reg_pairs *usb_ln_vals;
};
struct cdns_regmap_cdb_context {
@@ -233,7 +233,7 @@ static int cdns_regmap_read(void *context, unsigned int
reg, unsigned int *val)
.reg_read = cdns_regmap_read, \
}
-static struct regmap_config cdns_sierra_lane_cdb_config[] = {
+static const struct regmap_config cdns_sierra_lane_cdb_config[] = {
SIERRA_LANE_CDB_REGMAP_CONF("0"),
SIERRA_LANE_CDB_REGMAP_CONF("1"),
SIERRA_LANE_CDB_REGMAP_CONF("2"),
@@ -252,7 +252,7 @@ static struct regmap_config cdns_sierra_lane_cdb_config[] =
{
SIERRA_LANE_CDB_REGMAP_CONF("15"),
};
-static struct regmap_config cdns_sierra_common_cdb_config = {
+static const struct regmap_config cdns_sierra_common_cdb_config = {
.name = "sierra_common_cdb",
.reg_stride = 1,
.fast_io = true,
@@ -260,7 +260,7 @@ static struct regmap_config cdns_sierra_common_cdb_config =
{
.reg_read = cdns_regmap_read,
};
-static struct regmap_config cdns_sierra_phy_config_ctrl_config = {
+static const struct regmap_config cdns_sierra_phy_config_ctrl_config = {
.name = "sierra_phy_config_ctrl",
.reg_stride = 1,
.fast_io = true,
@@ -274,7 +274,7 @@ static int cdns_sierra_phy_init(struct phy *gphy)
struct cdns_sierra_phy *phy = dev_get_drvdata(gphy->dev.parent);
struct regmap *regmap;
int i, j;
- struct cdns_reg_pairs *cmn_vals, *ln_vals;
+ const struct cdns_reg_pairs *cmn_vals, *ln_vals;
u32 num_cmn_regs, num_ln_regs;
/* Initialise the PHY registers, unless auto configured */
@@ -654,7 +654,7 @@ static int cdns_sierra_phy_remove(struct platform_device
*pdev)
}
/* refclk100MHz_32b_PCIe_cmn_pll_ext_ssc */
-static struct cdns_reg_pairs cdns_pcie_cmn_regs_ext_ssc[] = {
+static const struct cdns_reg_pairs cdns_pcie_cmn_regs_ext_ssc[] = {
{0x2106, SIERRA_CMN_PLLLC_LF_COEFF_MODE1_PREG},
{0x2106, SIERRA_CMN_PLLLC_LF_COEFF_MODE0_PREG},
{0x8A06, SIERRA_CMN_PLLLC_BWCAL_MODE1_PREG},
@@ -663,7 +663,7 @@ static struct cdns_reg_pairs cdns_pcie_cmn_regs_ext_ssc[] =
{
};
/* refclk100MHz_32b_PCIe_ln_ext_ssc */
-static struct cdns_reg_pairs cdns_pcie_ln_regs_ext_ssc[] = {
+static const struct cdns_reg_pairs cdns_pcie_ln_regs_ext_ssc[] = {
{0x813E, SIERRA_CLKPATHCTRL_TMR_PREG},
{0x8047, SIERRA_RX_CREQ_FLTR_A_MODE3_PREG},
{0x808F, SIERRA_RX_CREQ_FLTR_A_MODE2_PREG},
@@ -674,7 +674,7 @@ static struct cdns_reg_pairs cdns_pcie_ln_regs_ext_ssc[] = {
};
/* refclk100MHz_20b_USB_cmn_pll_ext_ssc */
-static struct cdns_reg_pairs cdns_usb_cmn_regs_ext_ssc[] = {
+static const struct cdns_reg_pairs cdns_usb_cmn_regs_ext_ssc[] = {
{0x2085, SIERRA_CMN_PLLLC_LF_COEFF_MODE1_PREG},
{0x2085, SIERRA_CMN_PLLLC_LF_COEFF_MODE0_PREG},
{0x, SIERRA_CMN_PLLLC_BWCAL_MODE0_PREG},
@@ -682,7 +682,7 @@ static struct cdns_reg_pairs cdns_usb_cmn_regs_ext_ssc[] = {
};
/* refclk100MHz_20b_USB_ln_ext_ssc */
-static struct cdns_reg_pairs cdns_usb_ln_regs_ext_ssc[] = {
+static const struct cdns_reg_pairs cdns_usb_ln_regs_ext_ssc[] = {
{0xFE0A, SIERRA_DET_STANDEC_A_PREG},
{0x000F, SIERRA_DET_STANDEC_B_PREG},
{0x55A5, SIERRA_DET_STANDEC_C_PREG},
--
2.28.0
[PATCH 0/3] drivers/phy/cadence: Constify static structs
Constify a number of static structs that are never changed to allow the compiler to put them in read-only memory. Rikard Falkeborn (3): phy: cadence: Sierra: Constify static structs phy: cadence: salvo: Constify cdns_nxp_sequence_pair phy: cadence: torrent: Constify regmap_config structs drivers/phy/cadence/phy-cadence-salvo.c | 6 +++--- drivers/phy/cadence/phy-cadence-sierra.c | 24 +++ drivers/phy/cadence/phy-cadence-torrent.c | 12 ++-- 3 files changed, 21 insertions(+), 21 deletions(-) -- 2.28.0
Re: [PATCH v3 3/7] ASoC: sun4i-i2s: Add support for H6 I2S
Maxime, On 9/10/20 9:33 AM, Maxime Ripard wrote: > On Thu, Sep 03, 2020 at 09:54:39PM -0500, Samuel Holland wrote: >> On 9/3/20 3:58 PM, Maxime Ripard wrote: >>> On Thu, Sep 03, 2020 at 10:02:31PM +0200, Clément Péron wrote: Hi Maxime, On Wed, 29 Jul 2020 at 17:16, Mark Brown wrote: > > On Wed, Jul 29, 2020 at 04:39:27PM +0200, Maxime Ripard wrote: > >> It really looks like the polarity of LRCK is fine though. The first word >> is sent with LRCK low, and then high, so we have channel 0 and then >> channel 1 which seems to be the proper ordering? >> >> Which image file is this in reference to? >> > Yes, that's normal. Thank you very much for this test. So I will revert the following commit: ASoC: sun4i-i2s: Fix the LRCK polarity https://github.com/clementperon/linux/commit/dd657eae8164f7e4bafe8b875031a7c6c50646a9 >>> >>> Like I said, the current code is working as expected with regard to the >>> LRCK polarity. The issue is that the samples are delayed and start to be >>> transmitted on the wrong phase of the signal. >> >> Since an I2S LRCK frame is radially symmetric, "wrong phase" and "inverted >> polarity" look the same. The only way to definitively distinguish them is by >> looking at the sample data. >> >> In "i2s-h6.png", the samples are all zeroes, so you're assuming that the >> first >> sample transmitted (that is, when the bit clock starts transitioning) was a >> "left" sample. >> >> However, in "h6-i2s-start-data.png", there are pairs of samples we can look >> at. >> I'm still assuming that similar samples are a left/right pair, but that's >> probably a safe assumption. Here we see the first sample in each pair is >> transmitted with LRCK *high*, and the second sample in the pair is >> transmitted >> with LRCK *low*. This is the opposite of your claim above. >> >> An ideal test would put left/right markers and frame numbers in the data >> channel. The Python script below can generate such a file. Then you would >> know >> how much startup delay there is, which channel the "first sample" came from, >> and >> how each channel maps to the LRCK level. >> >> It would also be helpful to test DSP_A mode, where the LRCK signal is >> asymmetric and an inversion would be obvious. > > I had no idea that there was a wave module in Python, that's a great > suggestion, thanks! > > You'll find attached the screenshots for both the I2S and DSP_A formats. > I zoomed out a bit to be able to have the first valid samples, but it > should be readable. > > The code I used is there: > https://github.com/mripard/linux/tree/sunxi/h6-i2s-test > > It's basically the v3, plus the DT bits. > > As you can see, in the i2s case, LRCK starts low and then goes up, with > the first channel (0x2*** samples) transmitted first, so everything > looks right here. > > On the DSP_A screenshot, LRCK will be low with small bursts high, and > once again with the first channel being transmitted first, so it looks > right to me too. Indeed, for H6 i2s0 with LRCK inversion in software, everything looks correct on the wire. It's still concerning to me that the BSP has no evidence of this inversion, either for i2s0 or i2s1[1]. And the inversion seems not to be required for HDMI audio on mainline either (but there could be an inversion on the HDMI side or on the interconnect). Even so, your research is sufficient justification for me that the code is correct as-is (with the inversion). Thank you very much for collecting the data! Cheers, Samuel [1]: https://github.com/Allwinner-Homlet/H6-BSP4.9-linux/blob/e634a9603161eb50f2a6cf237f2f1c6da3e6/sound/soc/sunxi/sunxi-daudio.c#L1062 where 1 == SND_SOC_DAIFMT_NB_NF, and there's no inversion in sunxi_daudio_init_fmt().
Re: [PATCH] Using a pointer and kzalloc in place of a struct directly
On 12/09/20 8:25 pm, Greg KH wrote: > On Sat, Sep 12, 2020 at 05:43:38PM +0530, Anant Thazhemadam wrote: >> On 12/09/20 5:17 pm, Greg KH wrote: >>> Note, your "To:" line seemed corrupted, and why not cc: the bpf mailing >>> list as well? >> Oh, I'm sorry about that. I pulled the emails of all the people to whom >> this mail was sent off from the header in lkml mail, and just cc-ed >> everyone. >> >>> You leaked memory :( >>> >>> Did you test this patch? Where do you free this memory, I don't see >>> that happening anywhere in this patch, did I miss it? >> Yes, I did test this patch, which didn't seem to trigger any issues. >> It surprised me so much, that I ended up sending it in, to have >> it checked out. > You might not have noticed the memory leak if you were not looking for > it. > > How did you test this? Ah, that must be it. I tested this using syzbot, which wouldn't have looked for memory leaks, but only the issue that was reported. My apologies. >> I wasn't sure where exactly the memory allocated here was >> supposed to be freed (might be why the current implementation >> isn't exactly using kzalloc). I forgot to mention it in the initial mail, >> and I was hoping that someone would point me in the right direction >> (if this approach was actually going to be considered, that is, which in >> retrospect I now feel might not be the best thing) > It has to be freed somewhere, you wrote the patch :) > > But back to the original question here, why do you feel this change is > needed? What does this do better/faster/more correct than the code that > is currently there? Unless you can provide that, the change should not > be needed, right? I was initially trying to see if allocating memory would be an appropriate heuristic in trying to get a better sense of the bug and crash report, and at that moment, that was my goal, and figured that I'd deal with rest (such as freeing the memory) later on, if this was a something that could work. I was surprised when the patch (although it caused a memory leak), seemed to pass the test for the bug, without triggering any issues; since this patch basically only allocates memory as compared to locally declaring variables. I wanted some input or explanation, about how is it that doing this no longer triggers the bug? It felt (and still feels) extremely unlikely to me, that allocating memory also prevents the issue, which is why I figured it might do some help asking someone, if it does, and I just felt sending in the patch might make it at least a little less absurd sounding. Also, if simply allocating memory provides this security (which syzbot seems to approve, but I still do not understand fully how), wouldn't it be a welcome change? Like I said, I'm trying to understand how things work, a little better here, and I apologize for any confusion that I may have caused. TLDR; I tried allocating memory as a heuristic while trying to understand the bug and the bpf-next tree a little better. Surprisingly the bug didn't seem to get triggered. I would like to know the reason why the bug didn't get triggered when syzbot applied this patch to the bpf-next tree. If the reason, and allocating memory approach seems sensible enough, (or provides some sort of security that I seem to oblivious to), I will try and come up with a way to free the allocated memory, and send in a v2 as well. (For anyone who might say that there is another commit that fixes this - yes, I am aware. However, if you take a look at the bug at https://syzkaller.appspot.com/bug?extid=976d5ecfab0c7eb43ac3 you can see that a generic test (no patch attached) to see if the bug was still valid was issued much later, and it still turned out to trigger an issue)
Re: [GIT PULL] Btrfs fixes for 5.9-rc5
The pull request you sent on Sat, 12 Sep 2020 19:01:18 +0200: > git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux.git for-5.9-rc4-tag has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/edf6b0e1e4ddb12e022ce0c17829bad6d4161ea7 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL] SMB3 DFS Fix
The pull request you sent on Sat, 12 Sep 2020 11:56:45 -0500: > git://git.samba.org/sfrench/cifs-2.6.git tags/5.9-rc4-smb3-fix has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/5a3c558a9f05f4664f569b06f04d6b217785fd21 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL] seccomp fixes for v5.9-rc5
The pull request you sent on Fri, 11 Sep 2020 17:20:02 -0700: > https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git > tags/seccomp-v5.9-rc5 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/ef2e9a563b0cd7965e2a1263125dcbb1c86aa6cc Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL] libnvdimm fix for v5.9-rc5
The pull request you sent on Fri, 11 Sep 2020 22:19:57 +: > git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm.git > tags/libnvdimm-fix-v5.9-rc5 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/4f8b0a5b3f7e5f03b188de9025b60c15559790f9 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
RE: [PATCH v3 11/11] scsi: storvsc: Support PAGE_SIZE larger than 4K
From: Boqun Feng Sent: Thursday, September 10, 2020 7:35
AM
>
> Hyper-V always use 4k page size (HV_HYP_PAGE_SIZE), so when
> communicating with Hyper-V, a guest should always use HV_HYP_PAGE_SIZE
> as the unit for page related data. For storvsc, the data is
> vmbus_packet_mpb_array. And since in scsi_cmnd, sglist of pages (in unit
> of PAGE_SIZE) is used, we need convert pages in the sglist of scsi_cmnd
> into Hyper-V pages in vmbus_packet_mpb_array.
>
> This patch does the conversion by dividing pages in sglist into Hyper-V
> pages, offset and indexes in vmbus_packet_mpb_array are recalculated
> accordingly.
>
> Signed-off-by: Boqun Feng
> ---
> drivers/scsi/storvsc_drv.c | 54 +-
> 1 file changed, 47 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
> index 8f5f5dc863a4..119b76ca24a1 100644
> --- a/drivers/scsi/storvsc_drv.c
> +++ b/drivers/scsi/storvsc_drv.c
> @@ -1739,23 +1739,63 @@ static int storvsc_queuecommand(struct Scsi_Host
> *host, struct
> scsi_cmnd *scmnd)
> payload_sz = sizeof(cmd_request->mpb);
>
> if (sg_count) {
> - if (sg_count > MAX_PAGE_BUFFER_COUNT) {
> + unsigned int hvpgoff = 0;
> + unsigned long hvpg_offset = sgl->offset & ~HV_HYP_PAGE_MASK;
This is a minor nit. The above expression uses sgl->offset. Code below uses
sgl[0].offset. They're the same but the inconsistency sticks out a bit.
> + unsigned int hvpg_count = HVPFN_UP(hvpg_offset + length);
> + u64 hvpfn;
>
> - payload_sz = (sg_count * sizeof(u64) +
> + if (hvpg_count > MAX_PAGE_BUFFER_COUNT) {
> +
> + payload_sz = (hvpg_count * sizeof(u64) +
> sizeof(struct vmbus_packet_mpb_array));
> payload = kzalloc(payload_sz, GFP_ATOMIC);
> if (!payload)
> return SCSI_MLQUEUE_DEVICE_BUSY;
> }
>
> + /*
> + * sgl is a list of PAGEs, and payload->range.pfn_array
> + * expects the page number in the unit of HV_HYP_PAGE_SIZE (the
> + * page size that Hyper-V uses, so here we need to divide PAGEs
> + * into HV_HYP_PAGE in case that PAGE_SIZE > HV_HYP_PAGE_SIZE.
> + */
> payload->range.len = length;
> - payload->range.offset = sgl[0].offset;
> + payload->range.offset = sgl[0].offset & ~HV_HYP_PAGE_MASK;
Another nit. The right hand side of the above assignment is already calculated
as
hvpg_offset.
Nits aside,
Reviewed-by: Michael Kelley
> + hvpgoff = sgl[0].offset >> HV_HYP_PAGE_SHIFT;
>
> cur_sgl = sgl;
> - for (i = 0; i < sg_count; i++) {
> - payload->range.pfn_array[i] =
> - page_to_pfn(sg_page((cur_sgl)));
> - cur_sgl = sg_next(cur_sgl);
> + for (i = 0; i < hvpg_count; i++) {
> + /*
> + * 'i' is the index of hv pages in the payload and
> + * 'hvpgoff' is the offset (in hv pages) of the first
> + * hv page in the the first page. The relationship
> + * between the sum of 'i' and 'hvpgoff' and the offset
> + * (in hv pages) in a payload page ('hvpgoff_in_page')
> + * is as follow:
> + *
> + * |-- PAGE ---|
> + * | NR_HV_HYP_PAGES_IN_PAGE hvpgs in total |
> + * |hvpg|hvpg| ... |hvpg|... |hvpg|
> + * ^ ^ ^
> ^
> + * +-hvpgoff-+
> +-hvpgoff_in_page-+
> + * ^
> |
> + * +- i
> ---+
> + */
> + unsigned int hvpgoff_in_page =
> + (i + hvpgoff) % NR_HV_HYP_PAGES_IN_PAGE;
> +
> + /*
> + * Two cases that we need to fetch a page:
> + * 1) i == 0, the first step or
> + * 2) hvpgoff_in_page == 0, when we reach the boundary
> + *of a page.
> + */
> + if (hvpgoff_in_page == 0 || i == 0) {
> + hvpfn = page_to_hvpfn(sg_page(cur_sgl));
> + cur_sgl = sg_next(cur_sgl);
> + }
> +
> + payload->range.pfn_array[i] = hvpfn + hvpgoff_in_page;
> }
> }
>
> --
> 2.28.0
Re: [PATCH] media: vidtv: fix 32-bit warnings
On Sat, 2020-09-12 at 11:22 +0200, Mauro Carvalho Chehab wrote: > There are several warnings produced when the driver is built > for 32-bit archs. Solve them. [] > diff --git a/drivers/media/test-drivers/vidtv/vidtv_common.c > b/drivers/media/test-drivers/vidtv/vidtv_common.c [] > diff --git a/drivers/media/test-drivers/vidtv/vidtv_pes.c > b/drivers/media/test-drivers/vidtv/vidtv_pes.c [] > @@ -91,13 +91,13 @@ static u32 vidtv_pes_write_pts_dts(struct > pes_header_write_args args) > return 0; > > #ifdef __BIG_ENDIAN > - mask1 = GENMASK(30, 32); > - mask2 = GENMASK(15, 29); > - mask3 = GENMASK(0, 14); > + mask1 = GENMASK_ULL(30, 32); > + mask2 = GENMASK_ULL(15, 29); > + mask3 = GENMASK_ULL(0, 14); These are broken as GENMASK_ULL takes arguments in high then low order. > #else > - mask1 = GENMASK(32, 30); > - mask2 = GENMASK(29, 15); > - mask3 = GENMASK(14, 0); > + mask1 = GENMASK_ULL(32, 30); > + mask2 = GENMASK_ULL(29, 15); > + mask3 = GENMASK_ULL(14, 0); > #endif The #ifdef can be removed instead.
[PATCH] natsemi: switch from 'pci_' to 'dma_' API
The wrappers in include/linux/pci-dma-compat.h should go away.
The patch has been generated with the coccinelle script below and has been
hand modified to replace GFP_ with a correct flag.
It has been compile tested.
When memory is allocated in 'alloc_ring()' (natsemi.c) GFP_KERNEL can be
used because it is only called from 'netdev_open()', which is a '.ndo_open'
function. Such function are synchronized with the rtnl_lock() semaphore.
When memory is allocated in 'alloc_ring()' (natsemi.c) GFP_KERNEL can be
used because it is only called from 'netdev_open()', which is a '.ndo_open'
function. Such function are synchronized with the rtnl_lock() semaphore.
When memory is allocated in 'ns83820_init_one()' (natsemi.c) GFP_KERNEL can
be used because it is a probe function and no lock is taken in the between.
@@
@@
-PCI_DMA_BIDIRECTIONAL
+DMA_BIDIRECTIONAL
@@
@@
-PCI_DMA_TODEVICE
+DMA_TO_DEVICE
@@
@@
-PCI_DMA_FROMDEVICE
+DMA_FROM_DEVICE
@@
@@
-PCI_DMA_NONE
+DMA_NONE
@@
expression e1, e2, e3;
@@
-pci_alloc_consistent(e1, e2, e3)
+dma_alloc_coherent(>dev, e2, e3, GFP_)
@@
expression e1, e2, e3;
@@
-pci_zalloc_consistent(e1, e2, e3)
+dma_alloc_coherent(>dev, e2, e3, GFP_)
@@
expression e1, e2, e3, e4;
@@
-pci_free_consistent(e1, e2, e3, e4)
+dma_free_coherent(>dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
-pci_map_single(e1, e2, e3, e4)
+dma_map_single(>dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
-pci_unmap_single(e1, e2, e3, e4)
+dma_unmap_single(>dev, e2, e3, e4)
@@
expression e1, e2, e3, e4, e5;
@@
-pci_map_page(e1, e2, e3, e4, e5)
+dma_map_page(>dev, e2, e3, e4, e5)
@@
expression e1, e2, e3, e4;
@@
-pci_unmap_page(e1, e2, e3, e4)
+dma_unmap_page(>dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
-pci_map_sg(e1, e2, e3, e4)
+dma_map_sg(>dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
-pci_unmap_sg(e1, e2, e3, e4)
+dma_unmap_sg(>dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
-pci_dma_sync_single_for_cpu(e1, e2, e3, e4)
+dma_sync_single_for_cpu(>dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
-pci_dma_sync_single_for_device(e1, e2, e3, e4)
+dma_sync_single_for_device(>dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
-pci_dma_sync_sg_for_cpu(e1, e2, e3, e4)
+dma_sync_sg_for_cpu(>dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
-pci_dma_sync_sg_for_device(e1, e2, e3, e4)
+dma_sync_sg_for_device(>dev, e2, e3, e4)
@@
expression e1, e2;
@@
-pci_dma_mapping_error(e1, e2)
+dma_mapping_error(>dev, e2)
@@
expression e1, e2;
@@
-pci_set_dma_mask(e1, e2)
+dma_set_mask(>dev, e2)
@@
expression e1, e2;
@@
-pci_set_consistent_dma_mask(e1, e2)
+dma_set_coherent_mask(>dev, e2)
Signed-off-by: Christophe JAILLET
---
If needed, see post from Christoph Hellwig on the kernel-janitors ML:
https://marc.info/?l=kernel-janitors=158745678307186=4
---
drivers/net/ethernet/natsemi/natsemi.c | 63 +-
drivers/net/ethernet/natsemi/ns83820.c | 61 +
2 files changed, 62 insertions(+), 62 deletions(-)
diff --git a/drivers/net/ethernet/natsemi/natsemi.c
b/drivers/net/ethernet/natsemi/natsemi.c
index 3de8430ee8c5..05d43fd7ea98 100644
--- a/drivers/net/ethernet/natsemi/natsemi.c
+++ b/drivers/net/ethernet/natsemi/natsemi.c
@@ -1916,9 +1916,9 @@ static void ns_tx_timeout(struct net_device *dev,
unsigned int txqueue)
static int alloc_ring(struct net_device *dev)
{
struct netdev_private *np = netdev_priv(dev);
- np->rx_ring = pci_alloc_consistent(np->pci_dev,
- sizeof(struct netdev_desc) * (RX_RING_SIZE+TX_RING_SIZE),
- >ring_dma);
+ np->rx_ring = dma_alloc_coherent(>pci_dev->dev,
+sizeof(struct netdev_desc) *
(RX_RING_SIZE + TX_RING_SIZE),
+>ring_dma, GFP_KERNEL);
if (!np->rx_ring)
return -ENOMEM;
np->tx_ring = >rx_ring[RX_RING_SIZE];
@@ -1939,10 +1939,10 @@ static void refill_rx(struct net_device *dev)
np->rx_skbuff[entry] = skb;
if (skb == NULL)
break; /* Better luck next round. */
- np->rx_dma[entry] = pci_map_single(np->pci_dev,
- skb->data, buflen, PCI_DMA_FROMDEVICE);
- if (pci_dma_mapping_error(np->pci_dev,
- np->rx_dma[entry])) {
+ np->rx_dma[entry] = dma_map_single(>pci_dev->dev,
+ skb->data, buflen,
+ DMA_FROM_DEVICE);
+ if (dma_mapping_error(>pci_dev->dev,
np->rx_dma[entry])) {
dev_kfree_skb_any(skb);
RE: [PATCH v3 10/11] Driver: hv: util: Make ringbuffer at least take two pages
From: Boqun Feng Sent: Thursday, September 10, 2020 7:35 AM > > When PAGE_SIZE > HV_HYP_PAGE_SIZE, we need the ringbuffer size to be at > least 2 * PAGE_SIZE: one page for the header and at least one page of > the data part (because of the alignment requirement for double mapping). > > So make sure the ringbuffer sizes to be at least 2 * PAGE_SIZE when > using vmbus_open() to establish the vmbus connection. > > Signed-off-by: Boqun Feng > --- > drivers/hv/hv_util.c | 16 > 1 file changed, 12 insertions(+), 4 deletions(-) > Reviewed-by: Michael Kelley
RE: [PATCH v3 09/11] HID: hyperv: Make ringbuffer at least take two pages
From: Boqun Feng Sent: Thursday, September 10, 2020 7:35 AM > > When PAGE_SIZE > HV_HYP_PAGE_SIZE, we need the ringbuffer size to be at > least 2 * PAGE_SIZE: one page for the header and at least one page of > the data part (because of the alignment requirement for double mapping). > > So make sure the ringbuffer sizes to be at least 2 * PAGE_SIZE when > using vmbus_open() to establish the vmbus connection. > > Signed-off-by: Boqun Feng > Acked-by: Jiri Kosina > --- > Hi Jiri, > > Thanks for your acked-by. I make a small change in this version (casting > 2 * PAGE_SIZE into int to avoid compiler warnings), and it make no > functional change. If the change is inappropriate, please let me know. > > drivers/hid/hid-hyperv.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > Reviewed-by: Michael Kelley
RE: [PATCH v3 08/11] Input: hyperv-keyboard: Make ringbuffer at least take two pages
From: Boqun Feng Sent: Thursday, September 10, 2020 7:35 AM > > When PAGE_SIZE > HV_HYP_PAGE_SIZE, we need the ringbuffer size to be at > least 2 * PAGE_SIZE: one page for the header and at least one page of > the data part (because of the alignment requirement for double mapping). > > So make sure the ringbuffer sizes to be at least 2 * PAGE_SIZE when > using vmbus_open() to establish the vmbus connection. > > Signed-off-by: Boqun Feng > --- > drivers/input/serio/hyperv-keyboard.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > Reviewed-by: Michael Kelley
RE: [PATCH v3 07/11] hv_netvsc: Use HV_HYP_PAGE_SIZE for Hyper-V communication
From: Boqun Feng Sent: Thursday, September 10, 2020 7:35 AM > > When communicating with Hyper-V, HV_HYP_PAGE_SIZE should be used since > that's the page size used by Hyper-V and Hyper-V expects all > page-related data using the unit of HY_HYP_PAGE_SIZE, for example, the > "pfn" in hv_page_buffer is actually the HV_HYP_PAGE (i.e. the Hyper-V > page) number. > > In order to support guest whose page size is not 4k, we need to make > hv_netvsc always use HV_HYP_PAGE_SIZE for Hyper-V communication. > > Signed-off-by: Boqun Feng > --- > drivers/net/hyperv/netvsc.c | 2 +- > drivers/net/hyperv/netvsc_drv.c | 46 +++ > drivers/net/hyperv/rndis_filter.c | 13 - > 3 files changed, 30 insertions(+), 31 deletions(-) > Reviewed-by: Michael Kelley
RE: [PATCH v3 06/11] hv: hyperv.h: Introduce some hvpfn helper functions
From: Boqun Feng Sent: Thursday, September 10, 2020 7:35 AM > > When a guest communicate with the hypervisor, it must use HV_HYP_PAGE to > calculate PFN, so introduce a few hvpfn helper functions as the > counterpart of the page helper functions. This is the preparation for > supporting guest whose PAGE_SIZE is not 4k. > > Signed-off-by: Boqun Feng > --- > include/linux/hyperv.h | 5 + > 1 file changed, 5 insertions(+) > Reviewed-by: Michael Kelley
RE: [PATCH v3 05/11] Drivers: hv: vmbus: Move virt_to_hvpfn() to hyperv header
From: Boqun Feng Sent: Thursday, September 10, 2020 7:35 AM > > There will be more places other than vmbus where we need to calculate > the Hyper-V page PFN from a virtual address, so move virt_to_hvpfn() to > hyperv generic header. > > Signed-off-by: Boqun Feng > --- > drivers/hv/channel.c | 13 - > include/linux/hyperv.h | 15 +++ > 2 files changed, 15 insertions(+), 13 deletions(-) > Reviewed-by: Michael Kelley
RE: [PATCH v3 04/11] Drivers: hv: Use HV_HYP_PAGE in hv_synic_enable_regs()
From: Boqun Feng Sent: Thursday, September 10, 2020 7:35 AM > > Both the base_*_gpa should use the guest page number in Hyper-V page, so > use HV_HYP_PAGE instead of PAGE. > > Signed-off-by: Boqun Feng > --- > drivers/hv/hv.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > Reviewed-by: Michael Kelley
RE: [PATCH v3 03/11] Drivers: hv: vmbus: Introduce types of GPADL
From: Boqun Feng Sent: Thursday, September 10, 2020 7:35
AM
>
> This patch introduces two types of GPADL: HV_GPADL_{BUFFER, RING}. The
> types of GPADL are purely the concept in the guest, IOW the hypervisor
> treat them as the same.
>
> The reason of introducing the types for GPADL is to support guests whose
> page size is not 4k (the page size of Hyper-V hypervisor). In these
> guests, both the headers and the data parts of the ringbuffers need to
> be aligned to the PAGE_SIZE, because 1) some of the ringbuffers will be
> mapped into userspace and 2) we use "double mapping" mechanism to
> support fast wrap-around, and "double mapping" relies on ringbuffers
> being page-aligned. However, the Hyper-V hypervisor only uses 4k
> (HV_HYP_PAGE_SIZE) headers. Our solution to this is that we always make
> the headers of ringbuffers take one guest page and when GPADL is
> established between the guest and hypervisor, the only first 4k of
> header is used. To handle this special case, we need the types of GPADL
> to differ different guest memory usage for GPADL.
>
> Type enum is introduced along with several general interfaces to
> describe the differences between normal buffer GPADL and ringbuffer
> GPADL.
>
> Signed-off-by: Boqun Feng
> ---
> drivers/hv/channel.c | 160 +++--
> include/linux/hyperv.h | 44 +++-
> 2 files changed, 183 insertions(+), 21 deletions(-)
>
Reviewed-by: Michael Kelley
RE: [PATCH v3 02/11] Drivers: hv: vmbus: Move __vmbus_open()
From: Boqun Feng Sent: Thursday, September 10, 2020 7:35 AM > > Pure function movement, no functional changes. The move is made, because > in a later change, __vmbus_open() will rely on some static functions > afterwards, so we separate the move and the modification of > __vmbus_open() in two patches to make it easy to review. > > Signed-off-by: Boqun Feng > Reviewed-by: Wei Liu > --- > drivers/hv/channel.c | 309 ++- > 1 file changed, 155 insertions(+), 154 deletions(-) > Reviewed-by: Michael Kelley
RE: [PATCH v3 01/11] Drivers: hv: vmbus: Always use HV_HYP_PAGE_SIZE for gpadl
From: Boqun Feng Sent: Thursday, September 10, 2020 7:35 AM > > Since the hypervisor always uses 4K as its page size, the size of PFNs > used for gpadl should be HV_HYP_PAGE_SIZE rather than PAGE_SIZE, so > adjust this accordingly as the preparation for supporting 16K/64K page > size guests. No functional changes on x86, since PAGE_SIZE is always 4k > (equals to HV_HYP_PAGE_SIZE). > > Signed-off-by: Boqun Feng > --- > drivers/hv/channel.c | 13 + > 1 file changed, 5 insertions(+), 8 deletions(-) > Reviewed-by: Michael Kelley
Re: [GIT] Networking
On Thu, Sep 3, 2015 at 11:31 AM, Linus Torvalds
wrote:
>> [-Wsizeof-array-argument]
> Ahh. Google shows that it's an old clang warning that gcc has recently
> picked up.
> But even clang doesn't seem to have any way for a project to say
> "please warn about arrays in function argument declaration". It *is*
> very traditional idiomatic C, it's just that I personally think it's
> one of those bad traditional C things exactly because it's so
> misleading about what actually goes on. But I guess that in practice,
> the only thing that it actually *affects* is "sizeof" (and assignment
> to the variable name - something that would be invalid for a real
> array, but works on argument arrays because they are really just
> pointers).
> The "array as function argument" syntax is occasionally useful
> (particularly for the multi-dimensional array case), so I very much
> understand why it exists, I just think that in the kernel we'd be
> better off with the rule that it's against our coding practices.
> Linus
Hi Linus,
First of all, this is my first message to this mailing list, and I'm
trying to reply to a very old thread, so sorry if I don't know how/if I
should do it.
I have a different approach in my code to avoid that whole class of bugs
relating sizeof and false arrays in function argument declarations.
I do like the sintactic sugar that they provide, so I decided to ban
"sizeof(array)" completely off my code.
I have developed the following macro:
#define ARRAY_BYTES(arr)(sizeof((arr)[0]) * ARRAY_SIZE(arr))
which compiles to a simple "sizeof(arr)" by undoing the division in
"ARRAY_SIZE()", but with the added benefit that it checks that the
argument is an array (due to "ARRAY_SIZE()"), and if not, compilation
breaks which means that the array is not an array but a pointer.
My rules are:
- Size of an array (number of elements):
ARRAY_SIZE(arr)
- Signed size of an array (normally for loops where I compare against a
signed variable):
ARRAY_SSIZE(arr)defined as: ((ptrdiff_t)ARRAY_SIZE(arr))
- Size of an array in bytes (normally for buffers):
ARRAY_BYTES(arr)
No use of "sizeof" is allowed for arrays, which completely rules
out bugs of that class, because I never pass an array to "sizeof", which
is the core of the problem. I've been using those macros in my code for
more than a year, and they work really nice.
I propose to include the macro "ARRAY_BYTES()" in just
after "ARRAY_SIZE()" and replace every appearance of "sizeof(array)" in
Linux by "ARRAY_BYTES(array)", and modify the coding style guide to ban
"sizeof(array)" completely off the kernel.
Below are two patches: one that adds the macro to
, and another one that serves as an example of usage
for the macro (that one is just as an example).
I don't intend those patches to be applied directly, but instead to
be an example of what I mean. If you think the change is good, then
I'll prepare a big patch set for all of the appearances of sizeof()
that are unsafe :)
Cheers,
Alex.
Please CC me in any response to this thread.
From b5b674d39b28e703300698fa63e4ab4be646df8f Mon Sep 17 00:00:00 2001
From: Alejandro Colomar
Date: Sun, 5 Apr 2020 01:45:35 +0200
Subject: [PATCH 1/2] linux/kernel.h: add ARRAY_BYTES() macro
Signed-off-by: Alejandro Colomar
---
include/linux/kernel.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 9b7a8d74a9d6..dc806e2a7799 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -46,6 +46,12 @@
*/
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) +
__must_be_array(arr))
+/**
+ * ARRAY_BYTES - get the number of bytes in array @arr
+ * @arr: array to be sized
+ */
+#define ARRAY_BYTES(arr) (sizeof(arr) + __must_be_array(arr))
+
#define u64_to_user_ptr(x) ( \
{ \
typecheck(u64, (x));\
--
2.25.1
From 3e7bcf70b708b51a7807c336c5d1b01403989d3b Mon Sep 17 00:00:00 2001
From: Alejandro Colomar
Date: Sun, 5 Apr 2020 01:48:17 +0200
Subject: [PATCH 2/2] block, bfq: Use ARRAY_BYTES() for arrays instead of
sizeof()
Signed-off-by: Alejandro Colomar
---
block/bfq-cgroup.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/block/bfq-cgroup.c b/block/bfq-cgroup.c
index 68882b9b8f11..51ba9b9a8855 100644
--- a/block/bfq-cgroup.c
+++ b/block/bfq-cgroup.c
@@ -7,6 +7,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -794,7 +795,8 @@ void bfq_bic_update_cgroup(struct bfq_io_cq *bic,
struct bio *bio)
* refcounter for bfqg, to let it disappear only after no
* bfq_queue refers to it any longer.
*/
- blkg_path(bfqg_to_blkg(bfqg),
[PATCH] media: venus: helpers: Fix ALIGN() of non power of two
ALIGN() expects its second argument to be a power of 2, otherwise
incorrect results are produced for some inputs. The output can be
both larger or smaller than what is expected.
For example, ALIGN(304, 192) equals 320 instead of 384, and
ALIGN(65, 192) equals 256 instead of 192.
However, nestling two ALIGN() as is done in this case seem to only
produce results equal to or bigger than the expected result if ALIGN()
had handled non powers of two, and that in turn results in framesizes
that are either the correct size or too large.
Fortunately, since 192 * 4 / 3 equals 256, it turns out that one ALIGN()
is sufficient.
Fixes: ab1eda449c6e ("media: venus: vdec: handle 10bit bitstreams")
Signed-off-by: Rikard Falkeborn
---
I'm fairly certain this patch does the right thing, but I have only
compile-tested it (I don't have the hardware to test on). The only
reason I spotted it is that I tried implementing compile-time checking
of arguments to ALIGN (and some other functions) to check that arguments
that are supposed to be powers of two really are powers of two, and it
found this.
drivers/media/platform/qcom/venus/helpers.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/qcom/venus/helpers.c
b/drivers/media/platform/qcom/venus/helpers.c
index 7147871d9dc1..194c5dd08803 100644
--- a/drivers/media/platform/qcom/venus/helpers.c
+++ b/drivers/media/platform/qcom/venus/helpers.c
@@ -678,8 +678,8 @@ static u32 get_framesize_raw_yuv420_tp10_ubwc(u32 width,
u32 height)
u32 extradata = SZ_16K;
u32 size;
- y_stride = ALIGN(ALIGN(width, 192) * 4 / 3, 256);
- uv_stride = ALIGN(ALIGN(width, 192) * 4 / 3, 256);
+ y_stride = ALIGN(width * 4 / 3, 256);
+ uv_stride = ALIGN(width * 4 / 3, 256);
y_sclines = ALIGN(height, 16);
uv_sclines = ALIGN((height + 1) >> 1, 16);
--
2.28.0
[PATCH 1/2] media: vidtv: fix frequency tuning logic
Right now, there are some issues at the tuning logic:
1) the config struct is not copied at the tuner driver.
so, it won't use any frequency table at all;
2) the code that checks for frequency shifts is called
at set_params. So, lock_status will never be zeroed;
3) the signal strength will also report a strong
signal, even if not tuned;
4) the logic is not excluding non-set frequencies.
Fix those issues.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/test-drivers/vidtv/vidtv_tuner.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/media/test-drivers/vidtv/vidtv_tuner.c
b/drivers/media/test-drivers/vidtv/vidtv_tuner.c
index 39e848ae5836..268f980c6de8 100644
--- a/drivers/media/test-drivers/vidtv/vidtv_tuner.c
+++ b/drivers/media/test-drivers/vidtv/vidtv_tuner.c
@@ -120,7 +120,7 @@ vidtv_tuner_get_dev(struct dvb_frontend *fe)
return i2c_get_clientdata(fe->tuner_priv);
}
-static s32 vidtv_tuner_check_frequency_shift(struct dvb_frontend *fe)
+static int vidtv_tuner_check_frequency_shift(struct dvb_frontend *fe)
{
struct vidtv_tuner_dev *tuner_dev = vidtv_tuner_get_dev(fe);
struct dtv_frontend_properties *c = >dtv_property_cache;
@@ -156,6 +156,8 @@ static s32 vidtv_tuner_check_frequency_shift(struct
dvb_frontend *fe)
}
for (i = 0; i < array_sz; i++) {
+ if (!valid_freqs[i])
+ break;
shift = abs(c->frequency - valid_freqs[i]);
if (!shift)
@@ -177,6 +179,7 @@ static int
vidtv_tuner_get_signal_strength(struct dvb_frontend *fe, u16 *strength)
{
struct dtv_frontend_properties *c = >dtv_property_cache;
+ struct vidtv_tuner_dev *tuner_dev = vidtv_tuner_get_dev(fe);
const struct vidtv_tuner_cnr_to_qual_s *cnr2qual = NULL;
struct device *dev = fe->dvb->device;
u32 array_size = 0;
@@ -184,6 +187,10 @@ vidtv_tuner_get_signal_strength(struct dvb_frontend *fe,
u16 *strength)
u32 i;
shift = vidtv_tuner_check_frequency_shift(fe);
+ if (shift < 0) {
+ tuner_dev->hw_state.lock_status = 0;
+ return shift;
+ }
switch (c->delivery_system) {
case SYS_DVBT:
@@ -288,6 +295,7 @@ static int vidtv_tuner_set_params(struct dvb_frontend *fe)
struct vidtv_tuner_dev *tuner_dev = vidtv_tuner_get_dev(fe);
struct vidtv_tuner_config config = tuner_dev->config;
struct dtv_frontend_properties *c = >dtv_property_cache;
+ s32 shift;
u32 min_freq = fe->ops.tuner_ops.info.frequency_min_hz;
u32 max_freq = fe->ops.tuner_ops.info.frequency_max_hz;
@@ -305,6 +313,13 @@ static int vidtv_tuner_set_params(struct dvb_frontend *fe)
tuner_dev->hw_state.lock_status = TUNER_STATUS_LOCKED;
msleep_interruptible(config.mock_tune_delay_msec);
+
+ shift = vidtv_tuner_check_frequency_shift(fe);
+ if (shift < 0) {
+ tuner_dev->hw_state.lock_status = 0;
+ return shift;
+ }
+
return 0;
}
@@ -395,6 +410,7 @@ static int vidtv_tuner_i2c_probe(struct i2c_client *client,
_tuner_ops,
sizeof(struct dvb_tuner_ops));
+ memcpy(_dev->config, config, sizeof(tuner_dev->config));
fe->tuner_priv = client;
return 0;
--
2.26.2
[PATCH 2/2] media: vidtv: add an initial channel frequency
Use 474 MHz frequency for DVB-T/DVB-C, as this is the first
channel that it is valid on most places for DVB-T.
In the case of DVB-S, let's add Astra 19.2E initial
frequency at the scan files as the default, e. g. 12.5515 GHz.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/test-drivers/vidtv/vidtv_bridge.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/media/test-drivers/vidtv/vidtv_bridge.c
b/drivers/media/test-drivers/vidtv/vidtv_bridge.c
index 270c183b1d67..cb32f82f88f9 100644
--- a/drivers/media/test-drivers/vidtv/vidtv_bridge.c
+++ b/drivers/media/test-drivers/vidtv/vidtv_bridge.c
@@ -47,17 +47,25 @@ static unsigned int mock_tune_delay_msec;
module_param(mock_tune_delay_msec, uint, 0);
MODULE_PARM_DESC(mock_tune_delay_msec, "Simulate a tune delay");
-static unsigned int vidtv_valid_dvb_t_freqs[NUM_VALID_TUNER_FREQS];
+static unsigned int vidtv_valid_dvb_t_freqs[NUM_VALID_TUNER_FREQS] = {
+ 47400
+};
+
module_param_array(vidtv_valid_dvb_t_freqs, uint, NULL, 0);
MODULE_PARM_DESC(vidtv_valid_dvb_t_freqs,
"Valid DVB-T frequencies to simulate");
-static unsigned int vidtv_valid_dvb_c_freqs[NUM_VALID_TUNER_FREQS];
+static unsigned int vidtv_valid_dvb_c_freqs[NUM_VALID_TUNER_FREQS] = {
+ 47400
+};
+
module_param_array(vidtv_valid_dvb_c_freqs, uint, NULL, 0);
MODULE_PARM_DESC(vidtv_valid_dvb_c_freqs,
"Valid DVB-C frequencies to simulate");
-static unsigned int vidtv_valid_dvb_s_freqs[NUM_VALID_TUNER_FREQS];
+static unsigned int vidtv_valid_dvb_s_freqs[NUM_VALID_TUNER_FREQS] = {
+ 12551500
+};
module_param_array(vidtv_valid_dvb_s_freqs, uint, NULL, 0);
MODULE_PARM_DESC(vidtv_valid_dvb_s_freqs,
"Valid DVB-C frequencies to simulate");
--
2.26.2
Re: WARNING: refcount bug in io_wqe_worker
syzbot has found a reproducer for the following issue on: HEAD commit:729e3d09 Merge tag 'ceph-for-5.9-rc5' of git://github.com/.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=12f2ce0d90 kernel config: https://syzkaller.appspot.com/x/.config?x=c61610091f4ca8c4 dashboard link: https://syzkaller.appspot.com/bug?extid=956ef5eac18eadd0fb7f compiler: gcc (GCC) 10.1.0-syz 20200507 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=10f3a85390 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=157f726390 IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+956ef5eac18eadd0f...@syzkaller.appspotmail.com [ cut here ] refcount_t: underflow; use-after-free. WARNING: CPU: 0 PID: 7382 at lib/refcount.c:28 refcount_warn_saturate+0x1d1/0x1e0 lib/refcount.c:28 Kernel panic - not syncing: panic_on_warn set ... CPU: 0 PID: 7382 Comm: io_wqe_worker-1 Not tainted 5.9.0-rc4-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x198/0x1fd lib/dump_stack.c:118 panic+0x347/0x7c0 kernel/panic.c:231 __warn.cold+0x20/0x46 kernel/panic.c:600 report_bug+0x1bd/0x210 lib/bug.c:198 handle_bug+0x38/0x90 arch/x86/kernel/traps.c:234 exc_invalid_op+0x14/0x40 arch/x86/kernel/traps.c:254 asm_exc_invalid_op+0x12/0x20 arch/x86/include/asm/idtentry.h:536 RIP: 0010:refcount_warn_saturate+0x1d1/0x1e0 lib/refcount.c:28 Code: e9 db fe ff ff 48 89 df e8 2c dd 18 fe e9 8a fe ff ff e8 c2 d6 d8 fd 48 c7 c7 60 dc 93 88 c6 05 0d 0d 12 07 01 e8 b1 d7 a9 fd <0f> 0b e9 af fe ff ff 0f 1f 84 00 00 00 00 00 41 56 41 55 41 54 55 RSP: 0018:c9000810fe08 EFLAGS: 00010286 RAX: RBX: RCX: RDX: 88809592a200 RSI: 815db9a7 RDI: f52001021fb3 RBP: 0003 R08: 0001 R09: 8880ae6318e7 R10: R11: R12: 88809a6080b8 R13: 8880a7896e30 R14: 8880a7896e00 R15: 8880a6727f00 refcount_sub_and_test include/linux/refcount.h:274 [inline] refcount_dec_and_test include/linux/refcount.h:294 [inline] io_worker_exit fs/io-wq.c:236 [inline] io_wqe_worker+0xcdb/0x10e0 fs/io-wq.c:596 kthread+0x3b5/0x4a0 kernel/kthread.c:292 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294 Kernel Offset: disabled Rebooting in 86400 seconds..
Re: [PATCH 1/5] staging: rtl8723bs: refactor cckrates{only}_included
On Sat, 2020-09-12 at 11:22 -0700, Joe Perches wrote:
> On Sat, 2020-09-12 at 10:45 +0200, Michael Straube wrote:
> > Refactor cckrates_included() and cckratesonly_included() to simplify
> > the code and improve readability.
[]
> diff --git a/drivers/staging/rtl8723bs/core/rtw_wlan_util.c
> b/drivers/staging/rtl8723bs/core/rtw_wlan_util.c
[]
> bool cckratesonly_included(unsigned char *rate, int ratelen)
> {
[]
> if (i <= 0)
if (ratelen <= 0) of course...
> return false;
>
> for (i = 0; i < ratelen; i++) {
> if (!is_cckrate(rate[i])
> return false;
> }
>
> return true;
> }
>
>
[PATCH] MAINTAINERS: make linux-aspeed list remarks consistent
Commit f15a3ea80391 ("MAINTAINERS: Add ASPEED BMC GFX DRM driver entry")
does not mention that linux-asp...@lists.ozlabs.org is moderated for
non-subscribers, but the other three entries for
linux-asp...@lists.ozlabs.org do.
By 'majority vote' among entries, let us assume it was just missed here and
adjust it to be consistent with others.
Signed-off-by: Lukas Bulwahn
---
applies cleanly on master and next-20200911
Joel, please ack.
David, Daniel, please pick this minor non-urgent clean-up patch.
This patch submission will also show me if linux-aspeed is moderated or
not. I have not subscribed to linux-aspeed and if it shows up quickly in
the archive, the list is probably not moderated; and if it takes longer,
it is moderated, and hence, validating the patch.
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 26af84f97353..f2561c3fc9db 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5448,7 +5448,7 @@ F:drivers/gpu/drm/panel/panel-arm-versatile.c
DRM DRIVER FOR ASPEED BMC GFX
M: Joel Stanley
-L: linux-asp...@lists.ozlabs.org
+L: linux-asp...@lists.ozlabs.org (moderated for non-subscribers)
S: Supported
T: git git://anongit.freedesktop.org/drm/drm-misc
F: Documentation/devicetree/bindings/gpu/aspeed-gfx.txt
--
2.17.1
Re: [PATCH v12 0/5] Add support for DisplayPort driver on SnapDragon
Fyi, I've pushed this series and the dp-compliance bits to msm-next-dp[1] I didn't include the dp audio series yet, which seems to need some minor rebasing. (And a small request, when resending, cc freedr...@lists.freedesktop.org, so it shows up in the patchwork instance[2] I use) You might want to double check that I got the correct versions of the series, etc. And that nothing else (other than audio) is missing. BR, -R [1] https://gitlab.freedesktop.org/drm/msm/-/commits/msm-next-dp [2] https://patchwork.freedesktop.org/project/freedreno On Thu, Aug 27, 2020 at 2:17 PM Tanmay Shah wrote: > > These patches add Display-Port driver on SnapDragon/msm hardware. > This series also contains device-tree bindings for msm DP driver. > It also contains Makefile and Kconfig changes to compile msm DP driver. > > The block diagram of DP driver is shown below: > > > +-+ > |DRM FRAMEWORK| > +--+--+ > | >+v+ >| DP DRM | >+++ > | >+v+ > ++| DP+--++--+ > ++---+| DISPLAY |+---+ | | > |++-+-+-+| | | > || | | | | | > || | | | | | > || | | | | | > vv v v v v v > +--+ +--+ +---+ ++ ++ +---+ +-+ > | DP | | DP | |DP | | DP | | DP | |DP | | DP | > |PARSER| | HPD | |AUX| |LINK| |CTRL| |PHY| |POWER| > +--+---+ +---+--+ +---+ ++ +--+-+ +-+-+ +-+ > | | | > +--v---+ +v-v+ > |DEVICE| | DP | > | TREE | |CATALOG| > +--+ +---+---+ > | > +---v+ > |CTRL/PHY| > | HW | > ++ > > Changes in v12: > > -- Add support of pm ops in display port driver > -- Clear bpp depth bits before writing to MISC register > -- Fix edid read > > Previous change log: > https://lkml.kernel.org/lkml/20200818051137.21478-1-tan...@codeaurora.org/ > > Chandan Uddaraju (4): > dt-bindings: msm/dp: add bindings of DP/DP-PLL driver for Snapdragon > drm: add constant N value in helper file > drm/msm/dp: add displayPort driver support > drm/msm/dp: add support for DP PLL driver > > Jeykumar Sankaran (1): > drm/msm/dpu: add display port support in DPU > > Tanmay Shah (1): > drm/msm/dp: Add Display Port HPD feature > > drivers/gpu/drm/i915/display/intel_display.c |2 +- > drivers/gpu/drm/msm/Kconfig |9 + > drivers/gpu/drm/msm/Makefile | 14 + > drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 27 +- > .../drm/msm/disp/dpu1/dpu_encoder_phys_vid.c |8 + > drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 83 +- > drivers/gpu/drm/msm/dp/dp_aux.c | 535 ++ > drivers/gpu/drm/msm/dp/dp_aux.h | 30 + > drivers/gpu/drm/msm/dp/dp_catalog.c | 1045 ++ > drivers/gpu/drm/msm/dp/dp_catalog.h | 105 + > drivers/gpu/drm/msm/dp/dp_ctrl.c | 1693 + > drivers/gpu/drm/msm/dp/dp_ctrl.h | 35 + > drivers/gpu/drm/msm/dp/dp_display.c | 1046 ++ > drivers/gpu/drm/msm/dp/dp_display.h | 31 + > drivers/gpu/drm/msm/dp/dp_drm.c | 168 ++ > drivers/gpu/drm/msm/dp/dp_drm.h | 18 + > drivers/gpu/drm/msm/dp/dp_hpd.c | 69 + > drivers/gpu/drm/msm/dp/dp_hpd.h | 79 + > drivers/gpu/drm/msm/dp/dp_link.c | 1214 > drivers/gpu/drm/msm/dp/dp_link.h | 132 ++ > drivers/gpu/drm/msm/dp/dp_panel.c | 486 + > drivers/gpu/drm/msm/dp/dp_panel.h | 95 + > drivers/gpu/drm/msm/dp/dp_parser.c| 267 +++ > drivers/gpu/drm/msm/dp/dp_parser.h| 138 ++ > drivers/gpu/drm/msm/dp/dp_pll.c | 99 + > drivers/gpu/drm/msm/dp/dp_pll.h | 61 + > drivers/gpu/drm/msm/dp/dp_pll_10nm.c | 930 + > drivers/gpu/drm/msm/dp/dp_pll_private.h | 89 + > drivers/gpu/drm/msm/dp/dp_power.c | 373 > drivers/gpu/drm/msm/dp/dp_power.h | 103 + > drivers/gpu/drm/msm/dp/dp_reg.h | 518 + > drivers/gpu/drm/msm/msm_drv.c |2 + > drivers/gpu/drm/msm/msm_drv.h | 59 +- > include/drm/drm_dp_helper.h |1 + > 34 files changed, 9545 insertions(+), 19 deletions(-) > create mode 100644
Re: [PATCH 1/5] staging: rtl8723bs: refactor cckrates{only}_included
On Sat, 2020-09-12 at 10:45 +0200, Michael Straube wrote:
> Refactor cckrates_included() and cckratesonly_included() to simplify
> the code and improve readability.
>
> Signed-off-by: Michael Straube
> ---
> drivers/staging/rtl8723bs/core/rtw_wlan_util.c | 14 --
> 1 file changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/staging/rtl8723bs/core/rtw_wlan_util.c
> b/drivers/staging/rtl8723bs/core/rtw_wlan_util.c
> index a5790a648a5b..4e0d86b2e2e0 100644
> --- a/drivers/staging/rtl8723bs/core/rtw_wlan_util.c
> +++ b/drivers/staging/rtl8723bs/core/rtw_wlan_util.c
> @@ -56,11 +56,12 @@ static u8 rtw_basic_rate_ofdm[3] = {
>
> int cckrates_included(unsigned char *rate, int ratelen)
> {
> - int i;
> + int i;
>
> for (i = 0; i < ratelen; i++) {
> - if rate[i]) & 0x7f) == 2) || (((rate[i]) & 0x7f) == 4) ||
> - (((rate[i]) & 0x7f) == 11) || (((rate[i]) & 0x7f) == 22))
> + u8 r = rate[i] & 0x7f;
> +
> + if (r == 2 || r == 4 || r == 11 || r == 22)
> return true;
> }
>
> @@ -69,11 +70,12 @@ int cckrates_included(unsigned char *rate, int ratelen)
>
> int cckratesonly_included(unsigned char *rate, int ratelen)
> {
> - int i;
> + int i;
>
> for (i = 0; i < ratelen; i++) {
> - if rate[i]) & 0x7f) != 2) && (((rate[i]) & 0x7f) != 4) &&
> - (((rate[i]) & 0x7f) != 11) && (((rate[i]) & 0x7f) != 22))
> + u8 r = rate[i] & 0x7f;
> +
> + if (r != 2 && r != 4 && r != 11 && r != 22)
> return false;
It would be simpler to add and use an inline like:
static bool is_cckrate(unsigned char rate)
{
rate &= 0x7f;
return rate == 2 || rate == 4 || rate == 11 || rate == 22;
}
so these could be
bool cckrates_included(unsigned char *rate, int ratelen)
{
int i;
for (i = 0; i < ratelen; i++) {
if (is_cckrate(rate[i])
return true;
}
return false;
}
bool cckratesonly_included(unsigned char *rate, int ratelen)
{
int i;
if (i <= 0)
return false;
for (i = 0; i < ratelen; i++) {
if (!is_cckrate(rate[i])
return false;
}
return true;
}
[PATCH] spi: spi-geni-qcom: Don't wait to start 1st transfer if transmitting
If we're sending bytes over SPI, we know the FIFO is empty at the
start of the transfer. There's no reason to wait for the interrupt
telling us to start--we can just start right away. Then if we
transmit everything in one swell foop we don't even need to bother
listening for TX interrupts.
In a test of "flashrom -p ec -r /tmp/foo.bin" interrupts were reduced
from ~30560 to ~29730, about a 3% savings.
This patch looks bigger than it is because I moved a few functions
rather than adding a forward declaration. The only actual change to
geni_spi_handle_tx() was to make it return a bool indicating if there
is more to tx.
Signed-off-by: Douglas Anderson
---
drivers/spi/spi-geni-qcom.c | 167 +++-
1 file changed, 86 insertions(+), 81 deletions(-)
diff --git a/drivers/spi/spi-geni-qcom.c b/drivers/spi/spi-geni-qcom.c
index 0dc3f4c55b0b..49c9eb870755 100644
--- a/drivers/spi/spi-geni-qcom.c
+++ b/drivers/spi/spi-geni-qcom.c
@@ -326,6 +326,88 @@ static int spi_geni_init(struct spi_geni_master *mas)
return 0;
}
+static unsigned int geni_byte_per_fifo_word(struct spi_geni_master *mas)
+{
+ /*
+* Calculate how many bytes we'll put in each FIFO word. If the
+* transfer words don't pack cleanly into a FIFO word we'll just put
+* one transfer word in each FIFO word. If they do pack we'll pack 'em.
+*/
+ if (mas->fifo_width_bits % mas->cur_bits_per_word)
+ return roundup_pow_of_two(DIV_ROUND_UP(mas->cur_bits_per_word,
+ BITS_PER_BYTE));
+
+ return mas->fifo_width_bits / BITS_PER_BYTE;
+}
+
+static bool geni_spi_handle_tx(struct spi_geni_master *mas)
+{
+ struct geni_se *se = >se;
+ unsigned int max_bytes;
+ const u8 *tx_buf;
+ unsigned int bytes_per_fifo_word = geni_byte_per_fifo_word(mas);
+ unsigned int i = 0;
+
+ max_bytes = (mas->tx_fifo_depth - mas->tx_wm) * bytes_per_fifo_word;
+ if (mas->tx_rem_bytes < max_bytes)
+ max_bytes = mas->tx_rem_bytes;
+
+ tx_buf = mas->cur_xfer->tx_buf + mas->cur_xfer->len - mas->tx_rem_bytes;
+ while (i < max_bytes) {
+ unsigned int j;
+ unsigned int bytes_to_write;
+ u32 fifo_word = 0;
+ u8 *fifo_byte = (u8 *)_word;
+
+ bytes_to_write = min(bytes_per_fifo_word, max_bytes - i);
+ for (j = 0; j < bytes_to_write; j++)
+ fifo_byte[j] = tx_buf[i++];
+ iowrite32_rep(se->base + SE_GENI_TX_FIFOn, _word, 1);
+ }
+ mas->tx_rem_bytes -= max_bytes;
+ if (!mas->tx_rem_bytes) {
+ writel(0, se->base + SE_GENI_TX_WATERMARK_REG);
+ return false;
+ }
+ return true;
+}
+
+static void geni_spi_handle_rx(struct spi_geni_master *mas)
+{
+ struct geni_se *se = >se;
+ u32 rx_fifo_status;
+ unsigned int rx_bytes;
+ unsigned int rx_last_byte_valid;
+ u8 *rx_buf;
+ unsigned int bytes_per_fifo_word = geni_byte_per_fifo_word(mas);
+ unsigned int i = 0;
+
+ rx_fifo_status = readl(se->base + SE_GENI_RX_FIFO_STATUS);
+ rx_bytes = (rx_fifo_status & RX_FIFO_WC_MSK) * bytes_per_fifo_word;
+ if (rx_fifo_status & RX_LAST) {
+ rx_last_byte_valid = rx_fifo_status & RX_LAST_BYTE_VALID_MSK;
+ rx_last_byte_valid >>= RX_LAST_BYTE_VALID_SHFT;
+ if (rx_last_byte_valid && rx_last_byte_valid < 4)
+ rx_bytes -= bytes_per_fifo_word - rx_last_byte_valid;
+ }
+ if (mas->rx_rem_bytes < rx_bytes)
+ rx_bytes = mas->rx_rem_bytes;
+
+ rx_buf = mas->cur_xfer->rx_buf + mas->cur_xfer->len - mas->rx_rem_bytes;
+ while (i < rx_bytes) {
+ u32 fifo_word = 0;
+ u8 *fifo_byte = (u8 *)_word;
+ unsigned int bytes_to_read;
+ unsigned int j;
+
+ bytes_to_read = min(bytes_per_fifo_word, rx_bytes - i);
+ ioread32_rep(se->base + SE_GENI_RX_FIFOn, _word, 1);
+ for (j = 0; j < bytes_to_read; j++)
+ rx_buf[i++] = fifo_byte[j];
+ }
+ mas->rx_rem_bytes -= rx_bytes;
+}
+
static void setup_fifo_xfer(struct spi_transfer *xfer,
struct spi_geni_master *mas,
u16 mode, struct spi_master *spi)
@@ -398,8 +480,10 @@ static void setup_fifo_xfer(struct spi_transfer *xfer,
* setting up GENI SE engine, as driver starts data transfer
* for the watermark interrupt.
*/
- if (m_cmd & SPI_TX_ONLY)
- writel(mas->tx_wm, se->base + SE_GENI_TX_WATERMARK_REG);
+ if (m_cmd & SPI_TX_ONLY) {
+ if (geni_spi_handle_tx(mas))
+ writel(mas->tx_wm, se->base + SE_GENI_TX_WATERMARK_REG);
+ }
spin_unlock_irq(>lock);
}
@@ -417,85
Re: [v10 0/4] media: vidtv: Implement a virtual DVB driver
Em Sat, 12 Sep 2020 11:49:01 -0300 "Daniel W. S. Almeida" escreveu: > Hi Hans and Mauro & all > > > >Why the dvb_ prefix? All virtual drivers just start with 'vi'. > > > >And wouldn't it make more sense to call dvb_vidtv_bridge.ko just vidtv.ko? > >Just like the other virtual media drivers? > > I guess Mauro was the one to come up with the dvb_* prefix for the > kernel modules for the reasons he explicited up in this thread. > > As far as dvb_vidtv_bridge.ko and vidtv_bridge.c, I just wanted to be > verbose so that people would look at this and see that it is the code > for a bridge driver, since this is also supposed to be a template. > > Also because I had some trouble myself figuring out what was what when > first browsing through other dvb drivers. That said, I am 100% onboard > with renaming this to vidtv.ko or whatever seems more appropiate :) Let us think a little bit about that. > > > >Yet, I agree with you that at least an alias is needed. > >earlier today, I wrote a patch with such purpose: > > If you all would like to just leave this at that ^ I am also ok with it. > > >For regression testing of vidtv during the daily build it would be > great if > >the contrib/test/test-media script can be enhanced to include vidtv. > > Sure, I can do that if you'd like. Can you provide some tips on how to > get started? :) Hans can explain it better, but the hole idea is to have a set of userspace apps that will ensure that drivers will properly implement the DVB API. I suspect that, before that (or together with such tooling), we need to properly implement the frontend ioctl, validating the per delivery system parameters, as, right now, it just accepts anything from userspace. > >Note that this script relies on the /dev/mediaX devices to run the > tests. I > >noticed that vidtv doesn't appear to create a /dev/mediaX device, even though > >CONFIG_MEDIA_CONTROLLER_DVB=y. This is definitely something that would > be good > >to support in vidtv. > > I didn't write any code for this specifically. I was under the > impression that the dvb core would create any/all the necessary files. Mauro? It should be easy to implement support for it. The core does almost everything. Drivers just need to initialize the media controller. See for example: drivers/media/usb/em28xx/em28xx-dvb.c > >I'm thinking on something like: > > > >echo 1 >/sys/kernel/debug/vidtv/discontinuity > > > >to generate a frame numbering discontinuity > > > >and other things like that, changing S/N ratio and other parameters > >and injecting errors, in order to test the effects on user apps. > > Can you provide an initial list of things you would like to see? I can > then implement these and we can go from there Well, things that could help identifying bugs on userspace... > > When you say 'frame numbering discontinuity', do you mean having a gap > in the the TS continuity counter for a given pid? ... like this. Yeah, adding a gap a TS continuity counter. Other things could be to add noise to frames and increment the dvbv5-stat numbers and shifting bits and/or dropping 188-byte frames. With that regards, I'm planning to add support for dvb5-stat myself, as this should be trivial for me. Once support gets added, changing the stats is just a matter of increment some counters at fe cache. > > For the s302m encoder, maybe we can add some noise to the samples? Yes. > > > changing S/N ratio > > Btw 'lose lock if signal goes bad' code in vidtv_tuner.c and > vidtv_demod.c does not work currently. Mainly because they expect an > array of valid frequencies to compare to and as of now there's no default. > > I mean these, just to be clear: > > static unsigned int vidtv_valid_dvb_t_freqs[NUM_VALID_TUNER_FREQS]; > module_param_array(vidtv_valid_dvb_t_freqs, uint, NULL, 0); > MODULE_PARM_DESC(vidtv_valid_dvb_t_freqs, >"Valid DVB-T frequencies to simulate"); > > static unsigned int vidtv_valid_dvb_c_freqs[NUM_VALID_TUNER_FREQS]; > module_param_array(vidtv_valid_dvb_c_freqs, uint, NULL, 0); > MODULE_PARM_DESC(vidtv_valid_dvb_c_freqs, >"Valid DVB-C frequencies to simulate"); > > static unsigned int vidtv_valid_dvb_s_freqs[NUM_VALID_TUNER_FREQS]; > module_param_array(vidtv_valid_dvb_s_freqs, uint, NULL, 0); > MODULE_PARM_DESC(vidtv_valid_dvb_s_freqs, >"Valid DVB-C frequencies to simulate"); > > static unsigned int max_frequency_shift_hz; > module_param(max_frequency_shift_hz, uint, 0); > MODULE_PARM_DESC(max_frequency_shift_hz, >"Maximum shift in HZ allowed when tuning in a channel") Yes, I know (btw, there's a bug on its implementation - I'm working on a fix ATM). There are two different things here. With the above, you're simulating tuning at a wrong frequency. Another thing would be to have a parameter forcing errors. This can be helpful to dynamically inject errors on a tuned channel, and see how apps will behave. > > No. I
Re: WARNING in syscall_exit_to_user_mode
On Fri, Sep 11, 2020 at 03:39:19AM -0700, syzbot wrote: > Hello, > > syzbot found the following issue on: > > HEAD commit:f4d51dff Linux 5.9-rc4 > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt?x=12a4e7cd90 > kernel config: https://syzkaller.appspot.com/x/.config?x=a9075b36a6ae26c9 > dashboard link: https://syzkaller.appspot.com/bug?extid=7ffc7214b893651d52b8 > compiler: gcc (GCC) 10.1.0-syz 20200507 > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=122d733590 > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=13cea1a590 > > Bisection is inconclusive: the issue happens on the oldest tested release. > > bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=162247cd90 > final oops: https://syzkaller.appspot.com/x/report.txt?x=152247cd90 > console output: https://syzkaller.appspot.com/x/log.txt?x=112247cd90 > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > Reported-by: syzbot+7ffc7214b893651d5...@syzkaller.appspotmail.com > > [ cut here ] > syscall 56 left IRQs disabled This WARN appears reachable. :) I also see on the dashboard these other problems with the new entry code: https://syzkaller.appspot.com/bug?extid=d4336c84ed0099fdbe47 https://syzkaller.appspot.com/bug?extid=c4af95386364bc59b13e I can't tell if any of these have been looked at yet, though. -- Kees Cook
