[PATCH 00/15] drivers: usb: misc: update to use usb_control_msg_{send|recv}()
The new usb_control_msg_{send|recv}() API provides an improved way of
using usb_control_msg(). Using this, short reads/writes are considered
as errors, data can be used off the stack, and the need for the calling
function to create a raw usb pipe is eliminated.
This patch series aims to update existing instances of usb_control_msg()
in drivers/usb/misc to usb_control_msg_{send|recv}() appropriately, and
also update the return value checking mechanisms in place (if any), as
necessary so nothing breaks.
I was however unable to update one instance of usb_control_msg() in
drivers/usb/misc/apple-mfi-fastcharge.c.
The return value checking mechanism present here, is as follows.
if (retval) {
dev_dbg(>udev->dev, "retval = %d\n", retval);
return retval;
}
mfi->charge_type = val->intval;
return 0;
This implies that mfi->charge_type = val->intval only when number of
bytes transferred = 0, and the return value is directly returned
otherwise. Since the new API doesn't return the number of bytes
transferred, I wasn't quite sure how this instance could be updated.
In case this check is logically incorrect, a patch with a fix
can be sent in as well.
Anant Thazhemadam (15):
usb: misc: appledisplay: update to use the
usb_control_msg_{send|recv}() API
usb: misc: cypress_cy7c63: update to use usb_control_msg_recv()
usb: misc: cytherm: update to use usb_control_msg_recv()
usb: misc: ehset: update to use the usb_control_msg_{send|recv}() API
usb: misc: emi26: update to use usb_control_msg_send()
usb: misc: emi62: update to use usb_control_msg_send()
usb: misc: ezusb: update to use usb_control_msg_send()
usb: misc: idmouse: update to use usb_control_msg_send()
usb: misc: iowarrior: update to use the usb_control_msg_{send|recv}()
API
usb: misc: isight_firmware: update to use usb_control_msg_send()
usb: misc: ldusb: update to use usb_control_msg_send()
usb: misc: lvstest: update to use the usb_control_msg_{send|recv}()
API
usb: misc: trancevibrator: update to use usb_control_msg_send()
usb: misc: usbsevseg: update to use usb_control_msg_send()
usb: misc: usbtest: update to use the usb_control_msg_{send|recv}()
API
drivers/usb/misc/appledisplay.c| 46
drivers/usb/misc/cypress_cy7c63.c | 10 ++---
drivers/usb/misc/cytherm.c | 42 +-
drivers/usb/misc/ehset.c | 70 +-
drivers/usb/misc/emi26.c | 14 +-
drivers/usb/misc/emi62.c | 14 +-
drivers/usb/misc/ezusb.c | 16 +--
drivers/usb/misc/idmouse.c | 5 ++-
drivers/usb/misc/iowarrior.c | 34 +++
drivers/usb/misc/isight_firmware.c | 22 +-
drivers/usb/misc/ldusb.c | 8 ++--
drivers/usb/misc/lvstest.c | 30 ++---
drivers/usb/misc/trancevibrator.c | 6 +--
drivers/usb/misc/usbsevseg.c | 52 +++---
drivers/usb/misc/usbtest.c | 63 +--
15 files changed, 180 insertions(+), 252 deletions(-)
--
2.25.1
Re: [PATCH] hwmon: corsair-psu: update supported devices
On Sun, 29 Nov 2020 05:00:49 -0800 Guenter Roeck wrote: > On Sun, Nov 29, 2020 at 07:36:18AM +0100, Wilken Gottwalt wrote: > > On Sat, 28 Nov 2020 17:21:40 -0300 > > Jonas Malaco wrote: > > > > > On Sat, Nov 28, 2020 at 7:35 AM Wilken Gottwalt > > > wrote: > > > > > > > > On Sat, 28 Nov 2020 02:37:38 -0300 > > > > Jonas Malaco wrote: > > > > > > > > > On Thu, Nov 26, 2020 at 8:43 AM Wilken Gottwalt > > > > > wrote: > > > > > > > > > > > > Adds support for another Corsair PSUs series: AX760i, AX860i, > > > > > > AX1200i, > > > > > > AX1500i and AX1600i. The first 3 power supplies are supported > > > > > > through > > > > > > the Corsair Link USB Dongle which is some kind of USB/Serial/TTL > > > > > > converter especially made for the COM ports of these power supplies. > > > > > > There are 3 known revisions of these adapters. The AX1500i power > > > > > > supply > > > > > > has revision 3 built into the case and AX1600i is the only one in > > > > > > that > > > > > > series, which has an unique usb hid id like the RM/RX series. > > > > > > > > > > Can I ask what AXi power supplies were tested? > > > > > > > > > > I ask because, based on the user-space implementations I am aware of, > > > > > the AXi dongle protocol appears to be different from the RMi/HXi > > > > > series. > > > > > > > > I was not able to test this against the AX power supplies, they are > > > > really > > > > hard to find (and are far to expensive). But I went through all these > > > > tools > > > > and stuck to the most common commands, which all 3 series support. Not > > > > every > > > > series supports all commands (there also seem to be different firmwares > > > > in > > > > the micro-conrollers). But this is fine, some sensors will show up as > > > > N/A. > > > > Even my HX850i does not support all commands covered in this driver. > > > > > > I think the similarities come from all using wrappers over the PMBus > > > interface to the voltage controller. But I am not sure the wrapping > > > protocols are identical. > > > > > > For example, cpsumon shows significantly more things going on during a > > > read than what is needed for the RMi/HXi series.[1] > > > > > > [1] > > > https://github.com/ka87/cpsumon/blob/fd639684d7f9/libcpsumon/src/cpsumon.c#L213-L231 > > > > > > > > > > > > > > > AXi dongle: > > > > > - https://github.com/ka87/cpsumon > > > > > > > > This tool made me to consider including the AX series, because it uses > > > > some > > > > of the same commands on the AX760i, AX860i, AX1200i and AX1500i. But it > > > > is > > > > a usb-serial tool only. But it was nice to know, that the commands are > > > > mostly > > > > the same. I left out all the commands for configuring, PCIe power rails, > > > > efficiency and others which do not really belong into hwmon. > > > > > > > > > RMi/HXi: > > > > > - https://github.com/jonasmalacofilho/liquidctl > > > > > - https://github.com/audiohacked/OpenCorsairLink > > > > > > > > This tool made me include the AX series, because it uses the rmi > > > > protocol > > > > component for the rmi driver (RM/HX series) and the corsair dongles. > > > > > > The corsairlink_driver_dongle has no implementations for reading sensor > > > data (compare that with the corsairlink_driver_rmi).[2][3] There is > > > also no code that actually tries to read (write) from (to) the device > > > using that dongle driver.[4] > > > > > > I also looked at a few of the issues, and all of the ones I read > > > mentioned AXi support being under development, and the hypothesis of the > > > AXi series being compatible with the RMi/HXi code still remaining to be > > > confirmed. > > > > > > [2] > > > https://github.com/audiohacked/OpenCorsairLink/blob/61d336a61b85/drivers/dongle.c#L33-L39 > > > [3] > > > https://github.com/audiohacked/OpenCorsairLink/blob/61d336a61b85/drivers/rmi.c#L33-L57 > > > [4] > > > https://github.com/audiohacked/OpenCorsairLink/blob/61d336a61b85/main.c#L106 > > > > > > > > > > > > > > > - https://github.com/notaz/corsairmi > > > > > > > > This one covers only some HX/RM PSUs, but is uses the rawhid access > > > > which > > > > made me looking up the actual usb chips/bridges Corsair uses. > > > > > > > > > > > > > > One additional concern is that the non-HID AXi dongles may only have > > > > > bulk > > > > > USB endpoints, and this is a HID driver.[1] > > > > > > > > You are right, in the case of the dongles it could be different. But I > > > > did > > > > some research on Corsair usb driven devices and they really like to > > > > stick to > > > > the cp210x, which is an usb hid bridge. The commit > > > > b9326057a3d8447f5d2e74a7b521ccf21add2ec0 actually covers two Corsair USB > > > > dongles as a cp210x device. So it is very likely that all Corsair PSUs > > > > with > > > > such an interface/dongle use usb hid. But I'm completely open to get > > > > proven > > > > wrong. Actually I really would like to see this tested by people who > > > > have > > >
Re: [PATCH v12 07/10] secretmem: add memcg accounting
On Wed, Nov 25, 2020 at 1:51 AM Mike Rapoport wrote:
>
> From: Mike Rapoport
>
> Account memory consumed by secretmem to memcg. The accounting is updated
> when the memory is actually allocated and freed.
>
> Signed-off-by: Mike Rapoport
> Acked-by: Roman Gushchin
> ---
> mm/filemap.c | 3 ++-
> mm/secretmem.c | 36 +++-
> 2 files changed, 37 insertions(+), 2 deletions(-)
>
> diff --git a/mm/filemap.c b/mm/filemap.c
> index 249cf489f5df..cf7f1dc9f4b8 100644
> --- a/mm/filemap.c
> +++ b/mm/filemap.c
> @@ -42,6 +42,7 @@
> #include
> #include
> #include
> +#include
> #include "internal.h"
>
> #define CREATE_TRACE_POINTS
> @@ -844,7 +845,7 @@ static noinline int __add_to_page_cache_locked(struct
> page *page,
> page->mapping = mapping;
> page->index = offset;
>
> - if (!huge) {
> + if (!huge && !page_is_secretmem(page)) {
> error = mem_cgroup_charge(page, current->mm, gfp);
> if (error)
> goto error;
> diff --git a/mm/secretmem.c b/mm/secretmem.c
> index 52a900a135a5..eb6628390444 100644
> --- a/mm/secretmem.c
> +++ b/mm/secretmem.c
> @@ -18,6 +18,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -44,6 +45,32 @@ struct secretmem_ctx {
>
> static struct cma *secretmem_cma;
>
> +static int secretmem_account_pages(struct page *page, gfp_t gfp, int order)
> +{
> + int err;
> +
> + err = memcg_kmem_charge_page(page, gfp, order);
> + if (err)
> + return err;
> +
> + /*
> +* seceremem caches are unreclaimable kernel allocations, so treat
> +* them as unreclaimable slab memory for VM statistics purposes
> +*/
> + mod_node_page_state(page_pgdat(page), NR_SLAB_UNRECLAIMABLE_B,
> + PAGE_SIZE << order);
Please use mod_lruvec_page_state() instead, so we get the memcg stats too.
BTW I think secretmem deserves a vmstat entry instead of overloading
NR_SLAB_UNRECLAIMABLE_B.
> +
> + return 0;
> +}
> +
> +static void secretmem_unaccount_pages(struct page *page, int order)
> +{
> +
> + mod_node_page_state(page_pgdat(page), NR_SLAB_UNRECLAIMABLE_B,
> + -PAGE_SIZE << order);
> + memcg_kmem_uncharge_page(page, order);
> +}
> +
> static int secretmem_pool_increase(struct secretmem_ctx *ctx, gfp_t gfp)
> {
> unsigned long nr_pages = (1 << PMD_PAGE_ORDER);
> @@ -56,10 +83,14 @@ static int secretmem_pool_increase(struct secretmem_ctx
> *ctx, gfp_t gfp)
> if (!page)
> return -ENOMEM;
>
> - err = set_direct_map_invalid_noflush(page, nr_pages);
> + err = secretmem_account_pages(page, gfp, PMD_PAGE_ORDER);
> if (err)
> goto err_cma_release;
>
> + err = set_direct_map_invalid_noflush(page, nr_pages);
> + if (err)
> + goto err_memcg_uncharge;
> +
> addr = (unsigned long)page_address(page);
> err = gen_pool_add(pool, addr, PMD_SIZE, NUMA_NO_NODE);
> if (err)
> @@ -76,6 +107,8 @@ static int secretmem_pool_increase(struct secretmem_ctx
> *ctx, gfp_t gfp)
> * won't fail
> */
> set_direct_map_default_noflush(page, nr_pages);
> +err_memcg_uncharge:
> + secretmem_unaccount_pages(page, PMD_PAGE_ORDER);
> err_cma_release:
> cma_release(secretmem_cma, page, nr_pages);
> return err;
> @@ -302,6 +335,7 @@ static void secretmem_cleanup_chunk(struct gen_pool *pool,
> int i;
>
> set_direct_map_default_noflush(page, nr_pages);
> + secretmem_unaccount_pages(page, PMD_PAGE_ORDER);
>
> for (i = 0; i < nr_pages; i++)
> clear_highpage(page + i);
> --
> 2.28.0
>
[PATCH] mwl8k: switch from 'pci_' to 'dma_' API
he 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 'mwl8k_rxq_init()' and 'mwl8k_txq_init()'
GFP_KERNEL can be used because this flag is already used in a 'kcalloc()'
call, just a few line below.
When memory is allocated in 'mwl8k_firmware_load_success()' GFP_KERNEL can
be used because this flag is already used within 'ieee80211_register_hw()'
which is called just a few line below.
@@
@@
-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/wireless/marvell/mwl8k.c | 72 +++-
1 file changed, 39 insertions(+), 33 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwl8k.c
b/drivers/net/wireless/marvell/mwl8k.c
index 23efd7075df6..abf3b0233ccc 100644
--- a/drivers/net/wireless/marvell/mwl8k.c
+++ b/drivers/net/wireless/marvell/mwl8k.c
@@ -605,8 +605,9 @@ mwl8k_send_fw_load_cmd(struct mwl8k_priv *priv, void *data,
int length)
dma_addr_t dma_addr;
int loops;
- dma_addr = pci_map_single(priv->pdev, data, length, PCI_DMA_TODEVICE);
- if (pci_dma_mapping_error(priv->pdev, dma_addr))
+ dma_addr = dma_map_single(>pdev->dev, data, length,
+ DMA_TO_DEVICE);
+ if (dma_mapping_error(>pdev->dev, dma_addr))
return -ENOMEM;
iowrite32(dma_addr, regs + MWL8K_HIU_GEN_PTR);
@@ -635,7 +636,7 @@ mwl8k_send_fw_load_cmd(struct mwl8k_priv *priv, void *data,
int length)
udelay(1);
} while (--loops);
- pci_unmap_single(priv->pdev, dma_addr, length, PCI_DMA_TODEVICE);
+ dma_unmap_single(>pdev->dev, dma_addr, length, DMA_TO_DEVICE);
return loops ? 0 : -ETIMEDOUT;
}
@@ -1169,7 +1170,8 @@ static int mwl8k_rxq_init(struct ieee80211_hw *hw, int
index)
size = MWL8K_RX_DESCS * priv->rxd_ops->rxd_size;
- rxq->rxd = pci_zalloc_consistent(priv->pdev, size, >rxd_dma);
+ rxq->rxd = dma_alloc_coherent(>pdev->dev, size, >rxd_dma,
+ GFP_KERNEL);
if (rxq->rxd == NULL) {
wiphy_err(hw->wiphy, "failed to alloc RX descriptors\n");
return -ENOMEM;
@@ -1177,7 +1179,8 @@ static int mwl8k_rxq_init(struct ieee80211_hw *hw, int
index)
rxq->buf = kcalloc(MWL8K_RX_DESCS, sizeof(*rxq->buf), GFP_KERNEL);
if (rxq->buf == NULL) {
- pci_free_consistent(priv->pdev, size, rxq->rxd, rxq->rxd_dma);
+ dma_free_coherent(>pdev->dev, size, rxq->rxd,
+ rxq->rxd_dma);
return -ENOMEM;
}
@@ -1218,7 +1221,7 @@ static int rxq_refill(struct ieee80211_hw *hw, int index,
int limit)
if (skb == NULL)
Re: [PATCH v2] char: tpm: add i2c driver for cr50
On Sun, 2020-11-29 at 05:29 +0200, Jarkko Sakkinen wrote: > On Thu, Nov 26, 2020 at 03:19:24AM -0300, Ezequiel Garcia wrote: > > On Thu, 2020-11-26 at 05:30 +0200, Jarkko Sakkinen wrote: > > > On Tue, 2020-11-24 at 10:14 -0300, Ezequiel Garcia wrote: > > > > Hi Jarkko, > > > > > > > > Thanks for your review. > > > > > > > > On Tue, 2020-11-24 at 00:06 +0200, Jarkko Sakkinen wrote: > > > > > On Fri, Nov 20, 2020 at 07:23:45PM +0200, Adrian Ratiu wrote: > > > > > > From: "dlau...@chromium.org" > > > > > > > > > > > > Add TPM 2.0 compatible I2C interface for chips with cr50 > > > > > > firmware. > > > > > > > > > > > > The firmware running on the currently supported H1 MCU requires a > > > > > > special driver to handle its specific protocol, and this makes it > > > > > > unsuitable to use tpm_tis_core_* and instead it must implement > > > > > > the > > > > > > underlying TPM protocol similar to the other I2C TPM drivers. > > > > > > > > > > > > - All 4 byes of status register must be read/written at once. > > > > > > - FIFO and burst count is limited to 63 and must be drained by > > > > > > AP. > > > > > > - Provides an interrupt to indicate when read response data is > > > > > > ready > > > > > > and when the TPM is finished processing write data. > > > > > > > > > > > > This driver is based on the existing infineon I2C TPM driver, > > > > > > which > > > > > > most closely matches the cr50 i2c protocol behavior. > > > > > > > > > > > > Cc: Helen Koike > > > > > > Signed-off-by: Duncan Laurie > > > > > > [swb...@chromium.org: Depend on i2c even if it's a module, > > > > > > replace > > > > > > boilier plate with SPDX tag, drop asm/byteorder.h include, > > > > > > simplify > > > > > > return from probe] > > > > > > Signed-off-by: Stephen Boyd > > > > > > Signed-off-by: Fabien Lahoudere > > > > > > Signed-off-by: Adrian Ratiu > > > > > > --- > > > > > > Changes in v2: > > > > > > - Various small fixes all over (reorder includes, MAX_BUFSIZE, > > > > > > comments, etc) > > > > > > - Reworked return values of i2c_wait_tpm_ready() to fix timeout > > > > > > mis-handling > > > > > > so ret == 0 now means success, the wait period jiffies is ignored > > > > > > because that > > > > > > number is meaningless and return a proper timeout error in case > > > > > > jiffies == 0. > > > > > > - Make i2c default to 1 message per transfer (requested by > > > > > > Helen) > > > > > > - Move -EIO error reporting to transfer function to cleanup > > > > > > transfer() itself > > > > > > and its R/W callers > > > > > > - Remove magic value hardcodings and introduce enum > > > > > > force_release. > > > > > > > > > > > > v1 posted at https://lkml.org/lkml/2020/2/25/349 > > > > > > > > > > > > Applies on next-20201120, tested on Chromebook EVE. > > > > > > --- > > > > > > drivers/char/tpm/Kconfig| 10 + > > > > > > drivers/char/tpm/Makefile | 2 + > > > > > > drivers/char/tpm/tpm_tis_i2c_cr50.c | 768 > > > > > > > > > > > > 3 files changed, 780 insertions(+) > > > > > > create mode 100644 drivers/char/tpm/tpm_tis_i2c_cr50.c > > > > > > > > > > > > diff --git a/drivers/char/tpm/Kconfig b/drivers/char/tpm/Kconfig > > > > > > index a18c314da211..4308f9ca7a43 100644 > > > > > > --- a/drivers/char/tpm/Kconfig > > > > > > +++ b/drivers/char/tpm/Kconfig > > > > > > @@ -86,6 +86,16 @@ config TCG_TIS_SYNQUACER > > > > > > To compile this driver as a module, choose M here; > > > > > > the module will be called tpm_tis_synquacer. > > > > > > > > > > > > +config TCG_TIS_I2C_CR50 > > > > > > + tristate "TPM Interface Specification 2.0 Interface (I2C > > > > > > - CR50)" > > > > > > + depends on I2C > > > > > > + select TCG_CR50 > > > > > > + help > > > > > > + This is a driver for the Google cr50 I2C TPM interface > > > > > > which is a > > > > > > + custom microcontroller and requires a custom i2c > > > > > > protocol interface > > > > > > + to handle the limitations of the hardware. To compile > > > > > > this driver > > > > > > + as a module, choose M here; the module will be called > > > > > > tcg_tis_i2c_cr50. > > > > > > + > > > > > > config TCG_TIS_I2C_ATMEL > > > > > > tristate "TPM Interface Specification 1.2 Interface (I2C > > > > > > - Atmel)" > > > > > > depends on I2C > > > > > > diff --git a/drivers/char/tpm/Makefile > > > > > > b/drivers/char/tpm/Makefile > > > > > > index 84db4fb3a9c9..66d39ea6bd10 100644 > > > > > > --- a/drivers/char/tpm/Makefile > > > > > > +++ b/drivers/char/tpm/Makefile > > > > > > @@ -27,6 +27,8 @@ obj-$(CONFIG_TCG_TIS_SPI) += tpm_tis_spi.o > > > > > > tpm_tis_spi-y := tpm_tis_spi_main.o > > > > > > tpm_tis_spi-$(CONFIG_TCG_TIS_SPI_CR50) += tpm_tis_spi_cr50.o > > > > > > > > > > > > +obj-$(CONFIG_TCG_TIS_I2C_CR50) += tpm_tis_i2c_cr50.o > > > > > > + > > > > > > obj-$(CONFIG_TCG_TIS_I2C_ATMEL) += tpm_i2c_atmel.o > > > > > >
[PATCH] ARM: dts: OMAP3: disable AES on N950/N9
AES needs to be disabled on Nokia N950/N9 as well (HS devices), otherwise
kernel fails to boot.
Fixes: c312f066314e ("ARM: dts: omap3: Migrate AES from hwmods to sysc-omap2")
Signed-off-by: Aaro Koskinen
---
arch/arm/boot/dts/omap3-n950-n9.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-n950-n9.dtsi
b/arch/arm/boot/dts/omap3-n950-n9.dtsi
index 11d41e86f814..7dde9fbb06d3 100644
--- a/arch/arm/boot/dts/omap3-n950-n9.dtsi
+++ b/arch/arm/boot/dts/omap3-n950-n9.dtsi
@@ -494,3 +494,11 @@
clock-names = "sysclk";
};
};
+
+_target {
+ status = "disabled";
+};
+
+_target {
+ status = "disabled";
+};
--
2.17.0
Re: [PATCH] exit: fix a race in release_task when flushing the dentry
在 2020/11/29 下午2:05, Greg Kroah-Hartman 写道:
On Sat, Nov 28, 2020 at 11:28:53PM +0800, Wen Yang wrote:
在 2020/11/28 下午10:05, Greg Kroah-Hartman 写道:
On Sat, Nov 28, 2020 at 09:59:09PM +0800, Wen Yang wrote:
在 2020/11/28 下午4:06, Greg Kroah-Hartman 写道:
On Sat, Nov 28, 2020 at 02:47:22PM +0800, Wen Yang wrote:
[ Upstream commit 7bc3e6e55acf065500a24621f3b313e7e5998acf ]
No, that is not this commit at all.
What are you wanting to have happen here?
confused,
greg k-h
Thanks.
Let's explain it briefly:
The dentries such as /proc//ns/ipc have the DCACHE_OP_DELETE flag, they
should be deleted when the process exits.
Suppose the following race appears：
release_taskdput
-> proc_flush_task
-> dentry->d_op->d_delete(dentry)
-> __exit_signal
-> dentry->d_lockref.count-- and return.
In the proc_flush_task function, because another processe is using this
dentry, it cannot be deleted;
In the dput function, d_delete may be executed before __exit_signal (the pid
has not been unhashed), so that d_delete returns false and the dentry can
not be deleted.
So this dentry is still caches (count is 0), and its parent dentries are
also caches, and those dentries can only be deleted when drop_caches is
manually triggered.
In the release_task function, we should move proc_flush_task after the
tasklist_lock is released（Just like the commit
7bc3e6e55acf065500a24621f3b313e7e5998acf did).
I do not understand, is this a patch being submitted for the main kernel
tree, or for a stable kernel release?
If stable, please read:
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.
If main kernel tree, you can't have the "Upstream commit" line in the
changelog text as that makes no sense at all.
Hi,
This patch is submitted to the stable branches (from 4.9.y
to 5.6.y).
This problem can also be solved if the following patch could be ported to
the stable branch:
7bc3e6e55acf ("proc: Use a list of inodes to flush from proc")
26dbc60f385f ("proc: Generalize proc_sys_prune_dcache into
proc_prune_siblings_dcache")
f90f3cafe8d5 ("proc: Use d_invalidate in proc_prune_siblings_dcache")
However, the above-mentioned patches modify too much code (more than 100
lines), and there may also be some undiscovered bugs.
So the safer method may be to apply this small patch（also ported from the
equivalent fix already exist in Linus’ tree）.
We will reformat the patch later.
We always prefer to take the original, upstream patches, instead of
one-off changes as almost always, those one-off changes end up being
wrong and hard to work with over time.
So if we need more than one patch to solve this reported problem, that's
fine, can you test the above series of patches and provide a backported
set of them that we can use for this?
Ok, we will follow your suggestions.
Thanks.
--
Best wishes,
Wen
Alert-02
We have been trying to reach you as regards the estate of Late George Brumley, you were made one of the beneficiaries of his estate. Do get back to me at your earliest convenience. The Trustees
[PATCH v9 7/7] i3c: master: mastership handover, defslvs processing in cdns controller driver
Added I3C bus mastership handover and DEFSLVS message handling
code to Cadence's I3C master controller driver.
Signed-off-by: Parshuram Thombare
---
drivers/i3c/master/i3c-master-cdns.c | 329 +++---
1 files changed, 306 insertions(+), 23 deletions(-)
diff --git a/drivers/i3c/master/i3c-master-cdns.c
b/drivers/i3c/master/i3c-master-cdns.c
index f1d6d68..ff07862 100644
--- a/drivers/i3c/master/i3c-master-cdns.c
+++ b/drivers/i3c/master/i3c-master-cdns.c
@@ -160,6 +160,7 @@
#define SLV_IMR0x48
#define SLV_ICR0x4c
#define SLV_ISR0x50
+#define SLV_INT_DEFSLVSBIT(21)
#define SLV_INT_TM BIT(20)
#define SLV_INT_ERROR BIT(19)
#define SLV_INT_EVENT_UP BIT(18)
@@ -192,7 +193,7 @@
#define SLV_STATUS1_HJ_DIS BIT(18)
#define SLV_STATUS1_MR_DIS BIT(17)
#define SLV_STATUS1_PROT_ERR BIT(16)
-#define SLV_STATUS1_DA(x) (((s) & GENMASK(15, 9)) >> 9)
+#define SLV_STATUS1_DA(s) (((s) & GENMASK(15, 9)) >> 9)
#define SLV_STATUS1_HAS_DA BIT(8)
#define SLV_STATUS1_DDR_RX_FULLBIT(7)
#define SLV_STATUS1_DDR_TX_FULLBIT(6)
@@ -397,6 +398,9 @@ struct cdns_i3c_data {
struct cdns_i3c_master {
struct work_struct hj_work;
+ struct work_struct mr_yield_work;
+ struct work_struct defslvs_work;
+ struct completion mr_done;
struct i3c_master_controller base;
u32 free_rr_slots;
unsigned int maxdevs;
@@ -416,6 +420,7 @@ struct cdns_i3c_master {
struct cdns_i3c_master_caps caps;
unsigned long i3c_scl_lim;
const struct cdns_i3c_data *devdata;
+ u8 mr_addr;
};
static inline struct cdns_i3c_master *
@@ -1182,10 +1187,6 @@ static int cdns_i3c_master_do_daa(struct
i3c_master_controller *m)
cdns_i3c_master_upd_i3c_scl_lim(master);
- /* Unmask Hot-Join and Mastership request interrupts. */
- i3c_master_enec_locked(m, I3C_BROADCAST_ADDR,
- I3C_CCC_EVENT_HJ | I3C_CCC_EVENT_MR);
-
return 0;
}
@@ -1208,21 +1209,21 @@ static int cdns_i3c_master_bus_init(struct
i3c_master_controller *m)
struct cdns_i3c_master *master = to_cdns_i3c_master(m);
unsigned long pres_step, sysclk_rate, max_i2cfreq;
struct i3c_bus *bus = i3c_master_get_bus(m);
- u32 ctrl, prescl0, prescl1, pres, low;
+ u32 ctrl, prescl0, prescl1, pres, low, bus_mode;
struct i3c_device_info info = { };
int ret, ncycles;
switch (bus->mode) {
case I3C_BUS_MODE_PURE:
- ctrl = CTRL_PURE_BUS_MODE;
+ bus_mode = CTRL_PURE_BUS_MODE;
break;
case I3C_BUS_MODE_MIXED_FAST:
- ctrl = CTRL_MIXED_FAST_BUS_MODE;
+ bus_mode = CTRL_MIXED_FAST_BUS_MODE;
break;
case I3C_BUS_MODE_MIXED_SLOW:
- ctrl = CTRL_MIXED_SLOW_BUS_MODE;
+ bus_mode = CTRL_MIXED_SLOW_BUS_MODE;
break;
default:
@@ -1253,7 +1254,6 @@ static int cdns_i3c_master_bus_init(struct
i3c_master_controller *m)
bus->scl_rate.i2c = sysclk_rate / ((pres + 1) * 5);
prescl0 |= PRESCL_CTRL0_I2C(pres);
- writel(prescl0, master->regs + PRESCL_CTRL0);
/* Calculate OD and PP low. */
pres_step = 10 / (bus->scl_rate.i3c * 4);
@@ -1261,7 +1261,6 @@ static int cdns_i3c_master_bus_init(struct
i3c_master_controller *m)
if (ncycles < 0)
ncycles = 0;
prescl1 = PRESCL_CTRL1_OD_LOW(ncycles);
- writel(prescl1, master->regs + PRESCL_CTRL1);
/* Get an address for the master. */
ret = i3c_master_get_free_addr(m, 0);
@@ -1279,13 +1278,21 @@ static int cdns_i3c_master_bus_init(struct
i3c_master_controller *m)
if (ret)
return ret;
+ ctrl = readl(master->regs + CTRL);
+ if (ctrl & CTRL_DEV_EN)
+ cdns_i3c_master_disable(master);
+ writel(prescl0, master->regs + PRESCL_CTRL0);
+ writel(prescl1, master->regs + PRESCL_CTRL1);
+ ctrl &= ~CTRL_BUS_MODE_MASK;
+ ctrl |= bus_mode | CTRL_HALT_EN | CTRL_MCS_EN;
/*
* Enable Hot-Join, and, when a Hot-Join request happens, disable all
* events coming from this device.
*
* We will issue ENTDAA afterwards from the threaded IRQ handler.
*/
- ctrl |= CTRL_HJ_ACK | CTRL_HJ_DISEC | CTRL_HALT_EN | CTRL_MCS_EN;
+ if (!m->secondary)
+ ctrl |= CTRL_HJ_ACK | CTRL_HJ_DISEC;
/*
* Configure data hold delay based on device-specific data.
@@ -1358,6 +1365,7 @@ static void cdns_i3c_master_handle_ibi(struct
cdns_i3c_master *master,
static void cnds_i3c_master_demux_ibis(struct cdns_i3c_master
[PATCH v9 6/7] i3c: master: sysfs key for acquire bus
Added support to acquire I3C bus through sysfs interface.
Signed-off-by: Parshuram Thombare
---
drivers/i3c/master.c | 18 ++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c
index c01ba00..beb7495 100644
--- a/drivers/i3c/master.c
+++ b/drivers/i3c/master.c
@@ -581,6 +581,23 @@ static ssize_t i2c_scl_frequency_show(struct device *dev,
}
static DEVICE_ATTR_RO(i2c_scl_frequency);
+static ssize_t i3c_acquire_bus_store(struct device *dev,
+struct device_attribute *attr,
+const char *buf, size_t count)
+{
+ struct i3c_master_controller *master = dev_to_i3cmaster(dev);
+ int ret;
+
+ i3c_bus_normaluse_lock(>bus);
+ ret = i3c_master_acquire_bus(master);
+ i3c_bus_normaluse_unlock(>bus);
+ if (!ret)
+ i3c_master_enable_mr_events(master);
+
+ return ret ?: count;
+}
+static DEVICE_ATTR_WO(i3c_acquire_bus);
+
static struct attribute *i3c_masterdev_attrs[] = {
_attr_mode.attr,
_attr_current_master.attr,
@@ -591,6 +608,7 @@ static ssize_t i2c_scl_frequency_show(struct device *dev,
_attr_pid.attr,
_attr_dynamic_address.attr,
_attr_hdrcap.attr,
+ _attr_i3c_acquire_bus.attr,
NULL,
};
ATTRIBUTE_GROUPS(i3c_masterdev);
--
1.7.1
[PATCH v9 5/7] i3c: master: add defslvs processing
Added defslvs processing code to the I3C master subsystem.
Signed-off-by: Parshuram Thombare
---
drivers/i3c/master.c | 68 ++-
include/linux/i3c/master.h |7
2 files changed, 73 insertions(+), 2 deletions(-)
diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c
index 51ef706..c01ba00 100644
--- a/drivers/i3c/master.c
+++ b/drivers/i3c/master.c
@@ -2172,7 +2172,7 @@ int i3c_master_add_i3c_dev_locked(struct
i3c_master_controller *master,
else
expected_dyn_addr = newdev->info.dyn_addr;
- if (newdev->info.dyn_addr != expected_dyn_addr) {
+ if (!master->secondary && newdev->info.dyn_addr != expected_dyn_addr) {
/*
* Try to apply the expected dynamic address. If it fails, keep
* the address assigned by the master.
@@ -2867,12 +2867,20 @@ int i3c_secondary_master_register(struct
i3c_master_controller *master,
struct device *parent,
const struct i3c_master_controller_ops *ops)
{
- int ret;
+ int ret, sz;
ret = i3c_master_init(master, parent, ops, true);
if (ret)
return ret;
+ sz = sizeof(struct i3c_ccc_dev_desc) * I3C_BUS_MAX_DEVS;
+ master->defslvs_data.devs = devm_kzalloc(>dev, sz,
+GFP_KERNEL);
+ if (!master->defslvs_data.devs) {
+ ret = -ENOMEM;
+ goto err_cleanup_bus;
+ }
+
ret = device_add(>dev);
if (ret)
goto err_cleanup_bus;
@@ -2905,6 +2913,62 @@ int i3c_secondary_master_register(struct
i3c_master_controller *master,
}
EXPORT_SYMBOL_GPL(i3c_secondary_master_register);
+static int
+i3c_master_populate_bus(struct i3c_master_controller *master, u8 dyn_addr)
+{
+ struct i3c_dev_desc *olddev;
+ struct i3c_ccc_dev_desc *desc;
+ int ret, slot;
+
+ i3c_bus_for_each_i3cdev(>bus, olddev)
+ i3c_master_put_i3c_addrs(olddev);
+
+ master->this->info.dyn_addr = dyn_addr;
+ i3c_master_get_i3c_addrs(master->this);
+
+ desc = master->defslvs_data.devs;
+ for (slot = 1; slot < master->defslvs_data.ndevs; slot++) {
+ ret = i3c_master_add_i3c_dev_locked(master,
+ desc[slot].dyn_addr);
+ if (ret)
+ break;
+ }
+
+ return ret;
+}
+
+/**
+ * i3c_master_process_defslvs() - process I3C device list received in
+ * DEFSLVS for device plug/unplug and address change.
+ * @m: I3C master object
+ * @dyn_addr: Current dynamic address of this device
+ *
+ * This function may sleep, so should not be called in the atomic context.
+ */
+int i3c_master_process_defslvs(struct i3c_master_controller *m, u8 dyn_addr)
+{
+ int ret;
+
+ i3c_bus_normaluse_lock(>bus);
+ ret = i3c_master_acquire_bus(m);
+ i3c_bus_normaluse_unlock(>bus);
+ if (ret)
+ return ret;
+
+ i3c_bus_maintenance_lock(>bus);
+ ret = i3c_master_populate_bus(m, dyn_addr);
+ i3c_bus_maintenance_unlock(>bus);
+ if (!ret) {
+ i3c_bus_normaluse_lock(>bus);
+ i3c_master_register_new_i3c_devs(m);
+ i3c_bus_normaluse_unlock(>bus);
+ }
+ i3c_master_enable_mr_events(m);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(i3c_master_process_defslvs);
+
/**
* i3c_master_unregister() - unregister an I3C master
* @master: master used to send frames on the bus
diff --git a/include/linux/i3c/master.h b/include/linux/i3c/master.h
index 77c0422..835f823 100644
--- a/include/linux/i3c/master.h
+++ b/include/linux/i3c/master.h
@@ -478,6 +478,8 @@ struct i3c_master_controller_ops {
* in a thread context. Typical examples are Hot Join processing which
* requires taking the bus lock in maintenance, which in turn, can only
* be done from a sleep-able context
+ * @defslvs_data: list used to pass i3c device list received in DEFSLVS
message,
+ * from DEFSLVS controller driver to I3C core
*
* A i3c_master_controller has to be registered to the I3C subsystem
* through i3c_master_register(). None of i3c_master_controller fields
@@ -497,6 +499,10 @@ struct i3c_master_controller {
} boardinfo;
struct i3c_bus bus;
struct workqueue_struct *wq;
+ struct {
+ u32 ndevs;
+ struct i3c_ccc_dev_desc *devs;
+ } defslvs_data;
};
/**
@@ -523,6 +529,7 @@ struct i3c_master_controller {
void i3c_master_yield_bus(struct i3c_master_controller *m,
u8 sec_mst_dyn_addr);
+int i3c_master_process_defslvs(struct i3c_master_controller *m, u8 dyn_addr);
int i3c_master_do_i2c_xfers(struct i3c_master_controller *master,
const struct i2c_msg *xfers,
int nxfers);
--
[PATCH v9 1/7] i3c: master: master initialization flow document
Document describing master initialization, mastership handover
and DEFSLVS handling processes.
Signed-off-by: Parshuram Thombare
---
Documentation/driver-api/i3c/index.rst |1 +
.../driver-api/i3c/master-initialization-flow.rst | 187
2 files changed, 188 insertions(+), 0 deletions(-)
create mode 100644 Documentation/driver-api/i3c/master-initialization-flow.rst
diff --git a/Documentation/driver-api/i3c/index.rst
b/Documentation/driver-api/i3c/index.rst
index 783d6da..604f1c5 100644
--- a/Documentation/driver-api/i3c/index.rst
+++ b/Documentation/driver-api/i3c/index.rst
@@ -9,3 +9,4 @@ I3C subsystem
protocol
device-driver-api
master-driver-api
+ master-initialization-flow
diff --git a/Documentation/driver-api/i3c/master-initialization-flow.rst
b/Documentation/driver-api/i3c/master-initialization-flow.rst
new file mode 100644
index 000..e02b90d
--- /dev/null
+++ b/Documentation/driver-api/i3c/master-initialization-flow.rst
@@ -0,0 +1,187 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+==
+I3C Master Initialization Flow
+==
+
+.. kernel-render:: DOT
+ :alt: I3C Master Initialization digraph
+ :caption: I3C Master Initialization Flow
+
+ digraph master_init {
+ ranksep=.25; size="35,35";
+ subgraph cluster_0 {
+ style=dashed
+ x0[shape=ellipse, label="I3C driver probe", style="filled"]
+ x1[shape=diamond, label="Secondary Master ?"]
+ a1[shape=box, label="Do I3C master controller specific
initialization"]
+ b1[shape=box, label="Do I3C master controller specific
initialization,\n
+ except enabling the DEFSLVS interrupt."]
+ a2[shape=box, label="Call i3c_primary_master_register"]
+ b2[shape=box, label="Call i3c_secondary_master_register"]
+ x0->x1;
+ x1->a1[label="No"];
+ x1->b1[label="Yes"];
+ a1->a2; b1->b2;
+ }
+
+ subgraph cluster_1 {
+ style=dashed
+ label="Current Master";
+ a3[shape=ellipse, label="i3c_primary_master_register",
style="filled"]
+ a4[shape=box, label="Initialize I3C master controller object."]
+ a5[shape=box, label="Create I2C objects for devices in DTS and add
to I2C list."]
+ a6[shape=box, label="Set appropriate bus mode based on I2C devices
information."]
+ a7[shape=box, label="Create a work queue."]
+ a8[shape=box, label="Call i3c_primary_master_bus_init"]
+ a19[shape=box, label="Add I3C object representing this master to
the system."]
+ a20[shape=box, label="Expose our I3C bus as an I2C adapter so that
I2C devices\n
+ are exposed through the I2C subsystem."]
+ a21[shape=box, label="Register all I3C devices."]
+ a22[shape=box, label="Broadcast ENEC MR, HJ message."]
+ a3->a4->a5->a6->a7->a8; a19->a20->a21->a22;
+ a8->a19[style="invisible"];
+ }
+
+ subgraph cluster_2 {
+ style=dashed
+ label="Current Master";
+ a9[shape=ellipse, label="i3c_primary_master_bus_init",
style="filled"]
+ a10[shape=box, label="Call bus_init to do controller specific bus
initialization\n
+ and enabling the controller."]
+ a11[shape=box, label="Create I3C object representing the master and
add it to\n
+ the I3C device list."]
+ a12[shape=box, label="Set current master to the object created to
represent I3C\n
+ master device."]
+ a13[shape=box, label="Reset all dynamic address that may have been
assigned before."]
+ a14[shape=box, label="Disable all slave events before starting
DAA."]
+ a15[shape=box, label="Pre-assign dynamic address and retrieve
device information."]
+ a16[shape=box, label="Do dynamic address assignment to all I3C
devices currenly\n
+ present on the bus."]
+ a17[shape=box, label="Create I3C objects representing devices found
during DAA."]
+ a18[shape=box, label="Send DEFSVLS message containing information
about all\n
+ known I3C and I2C devices."]
+ a9->a10->a11->a12->a13->a14->a15->a16->a17->a18;
+ }
+
+ subgraph cluster_3 {
+ style=dashed
+ label="Current Master";
+ h1[shape=ellipse, label="MR request interrupt", style="filled"]
+ h2[shape=box, label="Bottom half i3c_master_yield_bus"]
+ h1->h2;
+ }
+
+ subgraph cluster_4 {
+ style=dashed
+ label="Current Master";
+ i1[shape=ellipse, label="i3c_master_yield_bus", style="filled"]
+ i2[shape=box, label="Check if this device is still a master to
handle a case of\n
+ multiple MR requests from different devices at a same time."]
+ i3[shape=box, label="Broadcast DISEC MR, HJ message.\n
+
[PATCH v9 3/7] i3c: master: add i3c_secondary_master_register
add i3c_secondary_master_register which is used
to register secondary masters.
Signed-off-by: Parshuram Thombare
---
drivers/i3c/master.c | 154 +++-
include/linux/i3c/master.h |3 +
2 files changed, 156 insertions(+), 1 deletions(-)
diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c
index 56e8fe4..af0630a 100644
--- a/drivers/i3c/master.c
+++ b/drivers/i3c/master.c
@@ -1797,6 +1797,90 @@ static int i3c_primary_master_bus_init(struct
i3c_master_controller *master)
return ret;
}
+/**
+ * i3c_secondary_master_bus_init() - initialize an I3C bus for secondary
+ * master
+ * @master: secondary master initializing the bus
+ *
+ * This function does
+ *
+ * 1. Attach I2C devs to the master
+ *
+ * 2. Call _master_controller_ops->bus_init() method to initialize
+ *the master controller. That's usually where the bus mode is selected
+ *(pure bus or mixed fast/slow bus)
+ *
+ * Once this is done, I2C devices should be usable.
+ *
+ * Return: a 0 in case of success, an negative error code otherwise.
+ */
+static int i3c_secondary_master_bus_init(struct i3c_master_controller *master)
+{
+ enum i3c_addr_slot_status status;
+ struct i2c_dev_boardinfo *i2cboardinfo;
+ struct i2c_dev_desc *i2cdev;
+ int ret;
+
+ /*
+* First attach all devices with static definitions provided by the
+* FW.
+*/
+ list_for_each_entry(i2cboardinfo, >boardinfo.i2c, node) {
+ status = i3c_bus_get_addr_slot_status(>bus,
+ i2cboardinfo->base.addr);
+ if (status != I3C_ADDR_SLOT_FREE) {
+ ret = -EBUSY;
+ goto err_detach_devs;
+ }
+
+ i3c_bus_set_addr_slot_status(>bus,
+i2cboardinfo->base.addr,
+I3C_ADDR_SLOT_I2C_DEV);
+
+ i2cdev = i3c_master_alloc_i2c_dev(master, i2cboardinfo);
+ if (IS_ERR(i2cdev)) {
+ ret = PTR_ERR(i2cdev);
+ goto err_detach_devs;
+ }
+
+ ret = i3c_master_attach_i2c_dev(master, i2cdev);
+ if (ret) {
+ i3c_master_free_i2c_dev(i2cdev);
+ goto err_detach_devs;
+ }
+ }
+
+ /*
+* Now execute the controller specific ->bus_init() routine, which
+* might configure its internal logic to match the bus limitations.
+*/
+ ret = master->ops->bus_init(master);
+ if (ret)
+ goto err_detach_devs;
+
+ /*
+* The master device should have been instantiated in ->bus_init(),
+* complain if this was not the case.
+*/
+ if (!master->this) {
+ dev_err(>dev,
+ "master_set_info() was not called in ->bus_init()\n");
+ ret = -EINVAL;
+ goto err_bus_cleanup;
+ }
+
+ return 0;
+
+err_bus_cleanup:
+ if (master->ops->bus_cleanup)
+ master->ops->bus_cleanup(master);
+
+err_detach_devs:
+ i3c_master_detach_free_devs(master);
+
+ return ret;
+}
+
static void i3c_master_bus_cleanup(struct i3c_master_controller *master)
{
if (master->ops->bus_cleanup)
@@ -2514,7 +2598,10 @@ static int i3c_master_init(struct i3c_master_controller
*master,
goto err_put_dev;
}
- ret = i3c_primary_master_bus_init(master);
+ if (secondary)
+ ret = i3c_secondary_master_bus_init(master);
+ else
+ ret = i3c_primary_master_bus_init(master);
if (ret)
goto err_destroy_wq;
@@ -2595,6 +2682,71 @@ int i3c_primary_master_register(struct
i3c_master_controller *master,
EXPORT_SYMBOL_GPL(i3c_primary_master_register);
/**
+ * i3c_secondary_master_register() - register an I3C secondary master
+ * @master: master used to send frames on the bus
+ * @parent: the parent device (the one that provides this I3C master
+ * controller)
+ * @ops: the master controller operations
+ *
+ * This function does minimal required initialization for secondary
+ * master, rest functionality like creating and registering I2C
+ * and I3C devices is done in defslvs processing.
+ *
+ * i3c_secondary_master_register() does following things -
+ * - creates and initializes the I3C bus
+ * - populates the bus with static I2C devs if @parent->of_node is not
+ * NULL
+ * initialization
+ * - allocate memory for defslvs_data.devs, which is used to receive
+ * defslvs list
+ * - create I3C device representing this master
+ * - registers the I2C adapter and all I2C devices
+ *
+ * Return: 0 in case of success, a negative error code otherwise.
+ */
+int i3c_secondary_master_register(struct i3c_master_controller *master,
+ struct
[PATCH v9 4/7] i3c: master: add mastership handover support
Added mastership acquire and yield functions.
Signed-off-by: Parshuram Thombare
---
drivers/i3c/master.c | 183 +---
include/linux/i3c/master.h |6 ++
2 files changed, 177 insertions(+), 12 deletions(-)
diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c
index af0630a..51ef706 100644
--- a/drivers/i3c/master.c
+++ b/drivers/i3c/master.c
@@ -44,6 +44,16 @@ static void i3c_bus_maintenance_lock(struct i3c_bus *bus)
}
/**
+ * i3c_bus_maintenance_downgrade_lock - Downgrade maintenance lock to
+ * normaluse lock.
+ * @bus: I3C bus to take the lock on
+ */
+static void i3c_bus_maintenance_downgrade_lock(struct i3c_bus *bus)
+{
+ downgrade_write(>lock);
+}
+
+/**
* i3c_bus_maintenance_unlock - Release the bus lock after a maintenance
* operation
* @bus: I3C bus to release the lock on
@@ -451,6 +461,59 @@ static int i3c_bus_init(struct i3c_bus *i3cbus)
[I3C_BUS_MODE_MIXED_SLOW] = "mixed-slow",
};
+static int i3c_master_enable_mr_events(struct i3c_master_controller *master)
+{
+ int ret;
+
+ master->ops->enable_mr_events(master);
+ i3c_bus_maintenance_lock(>bus);
+ ret = i3c_master_enec_locked(master, I3C_BROADCAST_ADDR,
+I3C_CCC_EVENT_MR | I3C_CCC_EVENT_HJ);
+ i3c_bus_maintenance_unlock(>bus);
+
+ return ret;
+}
+
+/**
+ * i3c_master_acquire_bus() - acquire I3C bus mastership
+ * @m: I3C master object
+ *
+ * This function may sleep.
+ * It is expected to be called with normaluse_lock.
+ */
+static int i3c_master_acquire_bus(struct i3c_master_controller *m)
+{
+ int ret = 0;
+
+ /*
+* Request mastership needs maintenance(write) lock. So, to avoid
+* deadlock, release normaluse(read) lock, which is expected to be
+* held before calling this function.
+* normaluse(read) lock is expected to be held before calling
+* this function to avoid race with maintenance activities
+* like DEFSLVS processing etc
+*/
+ i3c_bus_normaluse_unlock(>bus);
+ i3c_bus_maintenance_lock(>bus);
+
+ if (m->this && m->this == m->bus.cur_master) {
+ i3c_master_disec_locked(m, I3C_BROADCAST_ADDR,
+ I3C_CCC_EVENT_MR |
+ I3C_CCC_EVENT_HJ);
+ goto mr_req_done;
+ }
+
+ ret = m->ops->request_mastership(m);
+ if (ret)
+ goto mr_req_done;
+
+ m->bus.cur_master = m->this;
+
+mr_req_done:
+ i3c_bus_maintenance_downgrade_lock(>bus);
+ return ret;
+}
+
static ssize_t mode_show(struct device *dev,
struct device_attribute *da,
char *buf)
@@ -476,11 +539,12 @@ static ssize_t current_master_show(struct device *dev,
char *buf)
{
struct i3c_bus *i3cbus = dev_to_i3cbus(dev);
- ssize_t ret;
+ ssize_t ret = 0;
i3c_bus_normaluse_lock(i3cbus);
- ret = sprintf(buf, "%d-%llx\n", i3cbus->id,
- i3cbus->cur_master->info.pid);
+ if (i3cbus->cur_master)
+ ret = sprintf(buf, "%d-%llx\n", i3cbus->id,
+ i3cbus->cur_master->info.pid);
i3c_bus_normaluse_unlock(i3cbus);
return ret;
@@ -690,6 +754,33 @@ static int i3c_master_send_ccc_cmd_locked(struct
i3c_master_controller *master,
return 0;
}
+static int i3c_master_get_accmst_locked(struct i3c_master_controller *master,
+ u8 addr)
+{
+ struct i3c_ccc_getaccmst *accmst;
+ struct i3c_ccc_cmd_dest dest;
+ struct i3c_ccc_cmd cmd;
+ int ret;
+
+ accmst = i3c_ccc_cmd_dest_init(, addr, sizeof(*accmst));
+ if (!accmst)
+ return -ENOMEM;
+
+ i3c_ccc_cmd_init(, true, I3C_CCC_GETACCMST, , 1);
+
+ ret = i3c_master_send_ccc_cmd_locked(master, );
+ if (ret)
+ goto out;
+
+ if (dest.payload.len != sizeof(*accmst))
+ ret = -EIO;
+
+out:
+ i3c_ccc_cmd_dest_cleanup();
+
+ return ret;
+}
+
static struct i2c_dev_desc *
i3c_master_find_i2c_dev_by_addr(const struct i3c_master_controller *master,
u16 addr)
@@ -1582,10 +1673,6 @@ int i3c_master_set_info(struct i3c_master_controller
*master,
if (!i3c_bus_dev_addr_is_avail(>bus, info->dyn_addr))
return -EINVAL;
- if (I3C_BCR_DEVICE_ROLE(info->bcr) == I3C_BCR_I3C_MASTER &&
- master->secondary)
- return -EINVAL;
-
if (master->this)
return -EINVAL;
@@ -1594,7 +1681,9 @@ int i3c_master_set_info(struct i3c_master_controller
*master,
return PTR_ERR(i3cdev);
master->this = i3cdev;
- master->bus.cur_master = master->this;
+
+ if (!master->secondary)
+
[PATCH v9 2/7] i3c: master: use i3c_master_register only for main master
Removed last argument 'secondary' and restructured
i3c_master_register to move code that can be common
to i3c_secondary_master_register to separate function
i3c_master_init.
Signed-off-by: Parshuram Thombare
---
drivers/i3c/master.c | 78 -
drivers/i3c/master/dw-i3c-master.c |4 +-
drivers/i3c/master/i3c-master-cdns.c |4 +-
include/linux/i3c/master.h |7 +--
4 files changed, 54 insertions(+), 39 deletions(-)
diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c
index b61bf53..56e8fe4 100644
--- a/drivers/i3c/master.c
+++ b/drivers/i3c/master.c
@@ -1637,7 +1637,7 @@ static void i3c_master_detach_free_devs(struct
i3c_master_controller *master)
}
/**
- * i3c_master_bus_init() - initialize an I3C bus
+ * i3c_primary_master_bus_init() - initialize an I3C bus
* @master: main master initializing the bus
*
* This function is following all initialisation steps described in the I3C
@@ -1668,7 +1668,7 @@ static void i3c_master_detach_free_devs(struct
i3c_master_controller *master)
*
* Return: a 0 in case of success, an negative error code otherwise.
*/
-static int i3c_master_bus_init(struct i3c_master_controller *master)
+static int i3c_primary_master_bus_init(struct i3c_master_controller *master)
{
enum i3c_addr_slot_status status;
struct i2c_dev_boardinfo *i2cboardinfo;
@@ -2441,31 +2441,10 @@ static int i3c_master_check_ops(const struct
i3c_master_controller_ops *ops)
return 0;
}
-/**
- * i3c_master_register() - register an I3C master
- * @master: master used to send frames on the bus
- * @parent: the parent device (the one that provides this I3C master
- * controller)
- * @ops: the master controller operations
- * @secondary: true if you are registering a secondary master. Will return
- *-ENOTSUPP if set to true since secondary masters are not yet
- *supported
- *
- * This function takes care of everything for you:
- *
- * - creates and initializes the I3C bus
- * - populates the bus with static I2C devs if @parent->of_node is not
- * NULL
- * - registers all I3C devices added by the controller during bus
- * initialization
- * - registers the I2C adapter and all I2C devices
- *
- * Return: 0 in case of success, a negative error code otherwise.
- */
-int i3c_master_register(struct i3c_master_controller *master,
- struct device *parent,
- const struct i3c_master_controller_ops *ops,
- bool secondary)
+static int i3c_master_init(struct i3c_master_controller *master,
+ struct device *parent,
+ const struct i3c_master_controller_ops *ops,
+ bool secondary)
{
unsigned long i2c_scl_rate = I3C_BUS_I2C_FM_PLUS_SCL_RATE;
struct i3c_bus *i3cbus = i3c_master_get_bus(master);
@@ -2535,10 +2514,49 @@ int i3c_master_register(struct i3c_master_controller
*master,
goto err_put_dev;
}
- ret = i3c_master_bus_init(master);
+ ret = i3c_primary_master_bus_init(master);
if (ret)
goto err_destroy_wq;
+ return 0;
+
+err_destroy_wq:
+ destroy_workqueue(master->wq);
+
+err_put_dev:
+ put_device(>dev);
+
+ return ret;
+}
+
+/**
+ * i3c_primary_master_register() - register an I3C master
+ * @master: master used to send frames on the bus
+ * @parent: the parent device (the one that provides this I3C master
+ * controller)
+ * @ops: the master controller operations
+ *
+ * This function takes care of everything for you:
+ *
+ * - creates and initializes the I3C bus
+ * - populates the bus with static I2C devs if @parent->of_node is not
+ * NULL
+ * - registers all I3C devices added by the controller during bus
+ * initialization
+ * - registers the I2C adapter and all I2C devices
+ *
+ * Return: 0 in case of success, a negative error code otherwise.
+ */
+int i3c_primary_master_register(struct i3c_master_controller *master,
+ struct device *parent,
+ const struct i3c_master_controller_ops *ops)
+{
+ int ret;
+
+ ret = i3c_master_init(master, parent, ops, false);
+ if (ret)
+ return ret;
+
ret = device_add(>dev);
if (ret)
goto err_cleanup_bus;
@@ -2568,15 +2586,13 @@ int i3c_master_register(struct i3c_master_controller
*master,
err_cleanup_bus:
i3c_master_bus_cleanup(master);
-err_destroy_wq:
destroy_workqueue(master->wq);
-err_put_dev:
put_device(>dev);
return ret;
}
-EXPORT_SYMBOL_GPL(i3c_master_register);
+EXPORT_SYMBOL_GPL(i3c_primary_master_register);
/**
* i3c_master_unregister() - unregister an I3C master
diff --git a/drivers/i3c/master/dw-i3c-master.c
b/drivers/i3c/master/dw-i3c-master.c
index 8513bd3..4f4d41f 100644
---
[PATCH v2 2/2] Input: add driver for power button on Dell Wyse 3020
This adds support for the power button attached to the Embedded Controller
on a Dell Wyse 3020 "Ariel" board.
The Embedded Controller's SPI interface is actually capable sending and
receiving the PS/2 keyboard and mouse protocol data, which looks like
a good fit for a serio driver. Howerver, I don't know of any machines where
this is actually used.
My board only has a single power button and no way to connect an actual
keyboard or a mouse. Using the atkbd driver with serio would be an overkill
and would be inconvenient for the userspace. Therefore this driver
registers an input device that is only capable of reporting the power
button presses and releases.
Signed-off-by: Lubomir Rintel
---
Changes since v1:
- Do away bitfields in order to be endian independent
drivers/input/misc/Kconfig | 11 ++
drivers/input/misc/Makefile | 1 +
drivers/input/misc/ariel-pwrbutton.c | 165 +++
3 files changed, 177 insertions(+)
create mode 100644 drivers/input/misc/ariel-pwrbutton.c
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 362e8a01980cd..e7bb572e15182 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -73,6 +73,17 @@ config INPUT_AD714X_SPI
To compile this driver as a module, choose M here: the
module will be called ad714x-spi.
+config INPUT_ARIEL_PWRBUTTON
+ tristate "Dell Wyse 3020 Power Button Driver"
+ depends on SPI
+ depends on MACH_MMP3_DT || COMPILE_TEST
+ help
+ Say Y to enable support for reporting power button status on
+ on Dell Wyse 3020 ("Ariel") thin client.
+
+ To compile this driver as a module, choose M here: the module
+ will be called ariel-pwrbutton.
+
config INPUT_ARIZONA_HAPTICS
tristate "Arizona haptics support"
depends on MFD_ARIZONA && SND_SOC
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index a48e5f2d859d4..062cea9f181c9 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_INPUT_ADXL34X) += adxl34x.o
obj-$(CONFIG_INPUT_ADXL34X_I2C)+= adxl34x-i2c.o
obj-$(CONFIG_INPUT_ADXL34X_SPI)+= adxl34x-spi.o
obj-$(CONFIG_INPUT_APANEL) += apanel.o
+obj-$(CONFIG_INPUT_ARIEL_PWRBUTTON)+= ariel-pwrbutton.o
obj-$(CONFIG_INPUT_ARIZONA_HAPTICS)+= arizona-haptics.o
obj-$(CONFIG_INPUT_ATI_REMOTE2)+= ati_remote2.o
obj-$(CONFIG_INPUT_ATLAS_BTNS) += atlas_btns.o
diff --git a/drivers/input/misc/ariel-pwrbutton.c
b/drivers/input/misc/ariel-pwrbutton.c
new file mode 100644
index 0..502bc6a65f657
--- /dev/null
+++ b/drivers/input/misc/ariel-pwrbutton.c
@@ -0,0 +1,165 @@
+// SPDX-License-Identifier: BSD-2-Clause OR GPL-2.0-or-later
+/*
+ * Dell Wyse 3020 a.k.a. "Ariel" Power Button Driver
+ *
+ * Copyright (C) 2020 Lubomir Rintel
+ */
+
+#include
+#include
+#include
+#include
+
+#define RESP_COUNTER(response) (response.header & 0x3)
+#define RESP_SIZE(response)((response.header >> 2) & 0x3)
+#define RESP_TYPE(response)((response.header >> 4) & 0xf)
+
+struct ec_input_response {
+ u8 reserved;
+ u8 header;
+ u8 data[3];
+} __packed;
+
+struct ariel_pwrbutton {
+ struct spi_device *client;
+ struct input_dev *input;
+ u8 msg_counter:2;
+};
+
+static int ec_input_read(struct ariel_pwrbutton *priv,
+ struct ec_input_response *response)
+{
+ u8 read_request[] = { 0x00, 0x5a, 0xa5, 0x00, 0x00 };
+ struct spi_device *spi = priv->client;
+ struct spi_transfer t = {
+ .tx_buf = read_request,
+ .rx_buf = response,
+ .len = sizeof(read_request),
+ };
+
+ compiletime_assert(sizeof(read_request) == sizeof(*response),
+ "SPI xfer request/response size mismatch");
+
+ return spi_sync_transfer(spi, , 1);
+}
+
+static irqreturn_t ec_input_interrupt(int irq, void *dev_id)
+{
+ struct ariel_pwrbutton *priv = dev_id;
+ struct spi_device *spi = priv->client;
+ struct ec_input_response response;
+ int i;
+
+ if (ec_input_read(priv, ) < 0) {
+ dev_err(>dev, "EC read failed.\n");
+ return IRQ_HANDLED;
+ }
+
+ if (priv->msg_counter == RESP_COUNTER(response)) {
+ dev_warn(>dev, "No new data to read?\n");
+ return IRQ_HANDLED;
+ }
+
+ priv->msg_counter = RESP_COUNTER(response);
+
+ if (RESP_TYPE(response) != 0x3 && RESP_TYPE(response) != 0xc) {
+ dev_dbg(>dev, "Ignoring message that's not kbd data\n");
+ return IRQ_HANDLED;
+ }
+
+ for (i = 0; i < RESP_SIZE(response); i++) {
+ dev_err(>dev, "scan code %02x\n", response.data[i]);
+ switch (response.data[i]) {
+ case 0x74:
+
[PATCH v2 1/2] dt-bindings: input: Add Dell Wyse 3020 Power Button binding
Add binding document for the Dell Wyse 3020 a.k.a. "Ariel" Power Button.
Signed-off-by: Lubomir Rintel
Reviewed-by: Rob Herring
---
Changes since v1:
- Collect Rob's R-b
.../bindings/input/ariel-pwrbutton.yaml | 53 +++
1 file changed, 53 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/ariel-pwrbutton.yaml
diff --git a/Documentation/devicetree/bindings/input/ariel-pwrbutton.yaml
b/Documentation/devicetree/bindings/input/ariel-pwrbutton.yaml
new file mode 100644
index 0..e022d36c48d23
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/ariel-pwrbutton.yaml
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/ariel-pwrbutton.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Dell Wyse 3020 a.k.a. "Ariel" Power Button
+
+maintainers:
+ - Lubomir Rintel
+
+description: |
+ The ENE Embedded Controller on the Ariel board has an interface to the
+ SPI bus that is capable of sending keyboard and mouse data. A single
+ power button is attached to it. This binding describes this
+ configuration.
+
+allOf:
+ - $ref: input.yaml#
+
+properties:
+ compatible:
+items:
+ - const: dell,wyse-ariel-ec-input
+ - const: ene,kb3930-input
+
+ reg:
+maxItems: 1
+
+ interrupts:
+maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+examples:
+ - |
+#include
+
+spi {
+#address-cells = <1>;
+#size-cells = <0>;
+
+power-button@0 {
+compatible = "dell,wyse-ariel-ec-input", "ene,kb3930-input";
+reg = <0>;
+interrupt-parent = <>;
+interrupts = <60 IRQ_TYPE_EDGE_RISING>;
+spi-max-frequency = <3300>;
+};
+};
--
2.28.0
[PATCH v2 0/2] Add driver for power button on Dell Wyse 3020
please consider applying the patches chained to this message. It's a rather simple driver for a power button on Dell Ariel board along with the Device Tree binding document. Compared to previous version, endianness issues are fixed and I connected a Reviewed-by for the binding doc that I failed to before. Change logs are present in individual patches. Note that this set is versioned "v2", but I've sent the previous version (both unversioned) out twice before, because I've forgotten about the previous submission before. Sorry if it caused a confusion. Thank you Lubo
[RESEND PATCH v9 0/7] I3C mastership handover support
Main changes between v8 and v9 are: - Fix NULL dereference issue in current_master_show when cat'ing sysfs key current_master for secondary master before primary master gets initialized. Main changes between v7 and v8 are: - Document format changed from table to DOT diagram - Appropriate names for few functions - Moved mastership request process entirely to the driver - Reuse of i3c_master_add_i3c_dev_locked in core defslvs processing Main changes between v6 and v7 are: - Added separate functions for main and secondary master initialization - Secondary master initialization don't wait for DEFSLSVS. - Change to use I2C device information from DTS, and corresponding changes in controller driver and I3C core DEFSLVS processing to ignore I2C devices received in DEFSLVS - Reverted bus_init split - Fixed formatting issues in document Main changes between v5 and v6 are: - Moved populate_bus() hook to master subsystem code. - For secondary master initialization i3c_master_register spawan separate threads, as secondary master may have to wait for DEFSLVS and bus mastership. - Populate bus info is based on DEFSLVS data and take care of hot plugged / unplugged I3C devices. - Split bus_init into bus_init and master_set_info callbacks - Moved mastership aquire and handover to separate state machines. - Added DEFSLVS processing code. - Moved back all locks in side the subsystem code. - Secondary mastership support to Cadence I3C master controller driver - Sysfs key 'i3c_acquire_bus' to acauire bus. - NULL check for pool pointer in i3c_generic_ibi_free_pool. Main changes between v4 and v5 are: - Add populate_bus() hook - Split i3c_master_register into init and register pair - Split device information retrieval, let add partialy discovered devices - Make i3c_master_set_info private - Add separate function to register secondary master - Reworked secondary master register in CDNS driver - Export i3c_bus_set_mode Main changes between v3 and v4 are: - Reworked acquire bus ownership - Refactored the code Main changes between v2 and v3 are: - Added DEFSLVS devices are registered from master driver - Reworked I2C registering on secondary master side - Reworked Mastership event is enabled/disabled globally (for all devices) Main changes between initial version and v2 are: - Reworked devices registration on secondary master side - Reworked mastership event disabling/enabling - Reworked bus locking during mastership takeover process - Added DEFSLVS devices registration during initialization - Fixed style issues Parshuram Thombare (7): i3c: master: master initialization flow document i3c: master: use i3c_master_register only for main master i3c: master: add i3c_secondary_master_register i3c: master: add mastership handover support i3c: master: add defslvs processing i3c: master: sysfs key for acquire bus i3c: master: mastership handover, defslvs processing in cdns controller driver Documentation/driver-api/i3c/index.rst |1 + .../driver-api/i3c/master-initialization-flow.rst | 187 drivers/i3c/master.c | 497 ++-- drivers/i3c/master/dw-i3c-master.c |4 +- drivers/i3c/master/i3c-master-cdns.c | 329 - include/linux/i3c/master.h | 23 +- 6 files changed, 968 insertions(+), 73 deletions(-) create mode 100644 Documentation/driver-api/i3c/master-initialization-flow.rst
Re: WARNING in close_fs_devices (3)
syzbot has found a reproducer for the following issue on: HEAD commit:6174f052 Add linux-next specific files for 20201127 git tree: linux-next console output: https://syzkaller.appspot.com/x/log.txt?x=141c955350 kernel config: https://syzkaller.appspot.com/x/.config?x=79c69cf2521bef9c dashboard link: https://syzkaller.appspot.com/bug?extid=a70e2ad0879f160b9217 compiler: gcc (GCC) 10.1.0-syz 20200507 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1172779550 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1793dcc950 IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+a70e2ad0879f160b9...@syzkaller.appspotmail.com [ cut here ] WARNING: CPU: 1 PID: 8537 at fs/btrfs/volumes.c:1174 close_fs_devices+0x71d/0x930 fs/btrfs/volumes.c:1174 Modules linked in: CPU: 1 PID: 8537 Comm: syz-executor956 Not tainted 5.10.0-rc5-next-20201127-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:close_fs_devices+0x71d/0x930 fs/btrfs/volumes.c:1174 Code: e8 88 2f 42 fe 85 db 0f 85 5d f9 ff ff e8 9b 27 42 fe 0f 0b e9 51 f9 ff ff e8 8f 27 42 fe 0f 0b e9 c0 fe ff ff e8 83 27 42 fe <0f> 0b e9 f9 fe ff ff 48 c7 c7 1c 80 ee 8c e8 40 fb 84 fe e9 11 f9 RSP: 0018:c9000183f750 EFLAGS: 00010293 RAX: RBX: 0001 RCX: RDX: 88801e07b580 RSI: 832e99dd RDI: 0003 RBP: dc00 R08: R09: 88801a17b93b R10: 832e98d4 R11: R12: 88801a17b938 R13: 88801a17b9f4 R14: 888013e1c908 R15: 88801a17b850 FS: 025a7880() GS:8880b9f0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7f674003e048 CR3: 12337000 CR4: 001506e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: btrfs_close_devices+0x8e/0x4b0 fs/btrfs/volumes.c:1186 open_ctree+0x3f90/0x4035 fs/btrfs/disk-io.c:3484 btrfs_fill_super fs/btrfs/super.c:1362 [inline] btrfs_mount_root.cold+0x14/0x165 fs/btrfs/super.c:1731 legacy_get_tree+0x105/0x220 fs/fs_context.c:592 vfs_get_tree+0x89/0x2f0 fs/super.c:1549 fc_mount fs/namespace.c:983 [inline] vfs_kern_mount.part.0+0xd3/0x170 fs/namespace.c:1013 vfs_kern_mount+0x3c/0x60 fs/namespace.c:1000 btrfs_mount+0x234/0xa20 fs/btrfs/super.c:1791 legacy_get_tree+0x105/0x220 fs/fs_context.c:592 vfs_get_tree+0x89/0x2f0 fs/super.c:1549 do_new_mount fs/namespace.c:2896 [inline] path_mount+0x12ae/0x1e70 fs/namespace.c:3227 do_mount fs/namespace.c:3240 [inline] __do_sys_mount fs/namespace.c:3448 [inline] __se_sys_mount fs/namespace.c:3425 [inline] __x64_sys_mount+0x27f/0x300 fs/namespace.c:3425 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x4492fa Code: b8 08 00 00 00 0f 05 48 3d 01 f0 ff ff 0f 83 cd a2 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 0f 83 aa a2 fb ff c3 66 0f 1f 84 00 00 00 00 00 RSP: 002b:7ffe66329388 EFLAGS: 0293 ORIG_RAX: 00a5 RAX: ffda RBX: 0004 RCX: 004492fa RDX: 2000 RSI: 2100 RDI: 7ffe663293d0 RBP: 7ffe66329410 R08: 7ffe66329410 R09: R10: R11: 0293 R12: 0003 R13: 7ffe663293d0 R14: 0003 R15: 0005
[PATCH] genirq/irqdomain: Don't try to free an interrupt that has no mapping
When an interrupt allocation fails for N interrupts, it is pretty
common for the error handling code to free the same number of interrupts,
no matter how many interrupts have actually been allocated.
This may result in the domain freeing code to be unexpectedly called
for interrupts that have no mapping in that domain. Things end pretty
badly.
Instead, add some checks to irq_domain_free_irqs_hierarchy() to make
sure that we don't follow the hierarchy if no mapping exists for
a given interrupt.
Signed-off-by: Marc Zyngier
---
kernel/irq/irqdomain.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index cf8b374b892d..4d8f5a661c2a 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -1370,8 +1370,14 @@ static void irq_domain_free_irqs_hierarchy(struct
irq_domain *domain,
unsigned int irq_base,
unsigned int nr_irqs)
{
- if (domain->ops->free)
- domain->ops->free(domain, irq_base, nr_irqs);
+ int i;
+
+ if (!domain->ops->free)
+ return;
+
+ for (i = 0; i < nr_irqs; i++)
+ if (irq_domain_get_irq_data(domain, irq_base + i))
+ domain->ops->free(domain, irq_base + i, 1);
}
int irq_domain_alloc_irqs_hierarchy(struct irq_domain *domain,
--
2.29.2
[PATCH] irqchip/alpine-msi: Fix freeing of interrupts on allocation error path
The alpine-msi driver has an interesting allocation error handling,
where it frees the same interrupts repeatedly. Hilarity follows.
This code is probably never executed, but let's fix it nonetheless.
Fixes: e6b78f2c3e14 ("irqchip: Add the Alpine MSIX interrupt controller")
Cc: Tsahee Zidenberg
Cc: Antoine Tenart
Signed-off-by: Marc Zyngier
---
drivers/irqchip/irq-alpine-msi.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/irqchip/irq-alpine-msi.c b/drivers/irqchip/irq-alpine-msi.c
index 23a3b877f7f1..ede02dc2bcd0 100644
--- a/drivers/irqchip/irq-alpine-msi.c
+++ b/drivers/irqchip/irq-alpine-msi.c
@@ -165,8 +165,7 @@ static int alpine_msix_middle_domain_alloc(struct
irq_domain *domain,
return 0;
err_sgi:
- while (--i >= 0)
- irq_domain_free_irqs_parent(domain, virq, i);
+ irq_domain_free_irqs_parent(domain, virq, i - 1);
alpine_msix_free_sgi(priv, sgi, nr_irqs);
return err;
}
--
2.29.2
[PATCH 1/3] platform-msi: Track shared domain allocation
We have two flavours of platform-MSI:
- MSIs generated by devices for themselves (the usual case)
- MSIs generated on behalf of other devices, as the generating
device is some form of bridge (either a wire-to-MSI bridge,
or even a non-transparent PCI bridge that repaints the PCI
requester ID).
In the latter case, the underlying interrupt architecture may need
to track this in order to keep the mapping alive even when no MSI
are currently being generated.
Add a set of flags to the generic msi_alloc_info_t structure, as
well as the MSI_ALLOC_FLAGS_PROXY_DEVICE flag that will get
advertized by the platform-MSI code when allocating an irqdomain
for a device.
Signed-off-by: Marc Zyngier
---
drivers/base/platform-msi.c | 7 +++
include/asm-generic/msi.h | 4
2 files changed, 11 insertions(+)
diff --git a/drivers/base/platform-msi.c b/drivers/base/platform-msi.c
index c4a17e5edf8b..2c1e2e0c1a59 100644
--- a/drivers/base/platform-msi.c
+++ b/drivers/base/platform-msi.c
@@ -59,9 +59,15 @@ static int platform_msi_init(struct irq_domain *domain,
return irq_domain_set_hwirq_and_chip(domain, virq, hwirq,
info->chip, info->chip_data);
}
+
+static void platform_msi_set_proxy_dev(msi_alloc_info_t *arg)
+{
+ arg->flags |= MSI_ALLOC_FLAGS_PROXY_DEVICE;
+}
#else
#define platform_msi_set_desc NULL
#define platform_msi_init NULL
+#define platform_msi_set_proxy_dev(x) do {} while(0)
#endif
static void platform_msi_update_dom_ops(struct msi_domain_info *info)
@@ -343,6 +349,7 @@ __platform_msi_create_device_domain(struct device *dev,
if (!domain)
goto free_priv;
+ platform_msi_set_proxy_dev(>arg);
err = msi_domain_prepare_irqs(domain->parent, dev, nvec, >arg);
if (err)
goto free_domain;
diff --git a/include/asm-generic/msi.h b/include/asm-generic/msi.h
index e6795f088bdd..1010e74cb8e0 100644
--- a/include/asm-generic/msi.h
+++ b/include/asm-generic/msi.h
@@ -22,12 +22,16 @@ struct msi_desc;
typedef struct msi_alloc_info {
struct msi_desc *desc;
irq_hw_number_t hwirq;
+ unsigned long flags;
union {
unsigned long ul;
void*ptr;
} scratchpad[NUM_MSI_ALLOC_SCRATCHPAD_REGS];
} msi_alloc_info_t;
+/* Device generating MSIs is proxying for another device */
+#define MSI_ALLOC_FLAGS_PROXY_DEVICE (1UL << 0)
+
#define GENERIC_MSI_DOMAIN_OPS 1
#endif
--
2.28.0
[PATCH 2/3] irqchip/gic-v3-its: Tag ITS device as shared if allocating for a proxy device
The ITS already has some notion of "shared" devices. Let's map the
MSI_ALLOC_FLAGS_PROXY_DEVICE flag onto this internal property.
Signed-off-by: Marc Zyngier
---
drivers/irqchip/irq-gic-v3-its.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 0fec31931e11..b99a8ec6585e 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -3488,6 +3488,9 @@ static int its_msi_prepare(struct irq_domain *domain,
struct device *dev,
goto out;
}
+ if (info->flags & MSI_ALLOC_FLAGS_PROXY_DEVICE)
+ its_dev->shared = true;
+
pr_debug("ITT %d entries, %d bits\n", nvec, ilog2(nvec));
out:
mutex_unlock(>dev_alloc_lock);
--
2.28.0
[PATCH 3/3] irqchip/gic-v3-its: Flag device allocation as proxied if behind a PCI bridge
An aliasing PCI bridge is another case where we should flag the
corresponding allocation as "proxied", as MSIs are coming with
the bridge's RID, and not the originating device's.
Signed-off-by: Marc Zyngier
---
drivers/irqchip/irq-gic-v3-its-pci-msi.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/irqchip/irq-gic-v3-its-pci-msi.c
b/drivers/irqchip/irq-gic-v3-its-pci-msi.c
index 87711e0f8014..ad2810c017ed 100644
--- a/drivers/irqchip/irq-gic-v3-its-pci-msi.c
+++ b/drivers/irqchip/irq-gic-v3-its-pci-msi.c
@@ -67,11 +67,16 @@ static int its_pci_msi_prepare(struct irq_domain *domain,
struct device *dev,
/*
* If pdev is downstream of any aliasing bridges, take an upper
* bound of how many other vectors could map to the same DevID.
+* Also tell the ITS that the signalling will come from a proxy
+* device, and that special allocation rules apply.
*/
pci_for_each_dma_alias(pdev, its_get_pci_alias, _dev);
- if (alias_dev != pdev && alias_dev->subordinate)
- pci_walk_bus(alias_dev->subordinate, its_pci_msi_vec_count,
-_count);
+ if (alias_dev != pdev) {
+ if (alias_dev->subordinate)
+ pci_walk_bus(alias_dev->subordinate,
+its_pci_msi_vec_count, _count);
+ info->flags |= MSI_ALLOC_FLAGS_PROXY_DEVICE;
+ }
/* ITS specific DeviceID, as the core ITS ignores dev. */
info->scratchpad[0].ul = pci_msi_domain_get_msi_rid(domain, pdev);
--
2.28.0
[PATCH 0/3] MSI: Track device proxying when allocating MSIs
This series aims to plug a gap found with John's "managed interrupts for platform devices" series. We have a couple of cases where we allocate MSIs for a device, but the endpoint generating the actual interrupts (let's call it the "logical device") isn't the one being seen generating the MSIs (the "effective device"): - PCI devices behind a non transparent bridge - Devices attached to a wire-to-MSI bridge For interrupt infrastructures such as the ITS (where the effective device ID is part of the translation), it is important decouple the lifetime of the effective device mapping from the interrupt allocation on behalf of the logical device. Yes, I have a headache too. To achieve this split, let's tag the such allocations with a new flag that convey the fact that the effective device isn't the logical one. This mostly affects the platform-MSI subsystem. Subsequent patches add handling of this new flag in the GICv3 ITS (though there may be scope for something more generic in the case of the last patch). Marc Zyngier (3): platform-msi: Track shared domain allocation irqchip/gic-v3-its: Tag ITS device as shared if allocating for a proxy device irqchip/gic-v3-its: Flag device allocation as proxied if behind a PCI bridge drivers/base/platform-msi.c | 7 +++ drivers/irqchip/irq-gic-v3-its-pci-msi.c | 11 --- drivers/irqchip/irq-gic-v3-its.c | 3 +++ include/asm-generic/msi.h| 4 4 files changed, 22 insertions(+), 3 deletions(-) -- 2.28.0
[GIT pull] locking/urgent for v5.10-rc6
Linus,
please pull the latest locking/urgent branch from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
locking-urgent-2020-11-29
up to: 6e1d2bc675bd: intel_idle: Fix intel_idle() vs tracing
Yet two more places which invoke tracing from RCU disabled regions in the
idle path. Similar to the entry path the low level idle functions have to
be non-instrumentable.
Thanks,
tglx
-->
Peter Zijlstra (2):
sched/idle: Fix arch_cpu_idle() vs tracing
intel_idle: Fix intel_idle() vs tracing
arch/alpha/kernel/process.c | 2 +-
arch/arm/kernel/process.c| 2 +-
arch/arm64/kernel/process.c | 2 +-
arch/csky/kernel/process.c | 2 +-
arch/h8300/kernel/process.c | 2 +-
arch/hexagon/kernel/process.c| 2 +-
arch/ia64/kernel/process.c | 2 +-
arch/microblaze/kernel/process.c | 2 +-
arch/mips/kernel/idle.c | 12 ++--
arch/nios2/kernel/process.c | 2 +-
arch/openrisc/kernel/process.c | 2 +-
arch/parisc/kernel/process.c | 2 +-
arch/powerpc/kernel/idle.c | 4 ++--
arch/riscv/kernel/process.c | 2 +-
arch/s390/kernel/idle.c | 6 +++---
arch/sh/kernel/idle.c| 2 +-
arch/sparc/kernel/leon_pmc.c | 4 ++--
arch/sparc/kernel/process_32.c | 2 +-
arch/sparc/kernel/process_64.c | 4 ++--
arch/um/kernel/process.c | 2 +-
arch/x86/include/asm/mwait.h | 2 --
arch/x86/kernel/process.c| 12 +++-
drivers/idle/intel_idle.c| 37 -
kernel/sched/idle.c | 28 +++-
24 files changed, 84 insertions(+), 55 deletions(-)
diff --git a/arch/alpha/kernel/process.c b/arch/alpha/kernel/process.c
index 7462a7911002..4c7b0414a3ff 100644
--- a/arch/alpha/kernel/process.c
+++ b/arch/alpha/kernel/process.c
@@ -57,7 +57,7 @@ EXPORT_SYMBOL(pm_power_off);
void arch_cpu_idle(void)
{
wtint(0);
- local_irq_enable();
+ raw_local_irq_enable();
}
void arch_cpu_idle_dead(void)
diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c
index 8e6ace03e960..9f199b1e8383 100644
--- a/arch/arm/kernel/process.c
+++ b/arch/arm/kernel/process.c
@@ -71,7 +71,7 @@ void arch_cpu_idle(void)
arm_pm_idle();
else
cpu_do_idle();
- local_irq_enable();
+ raw_local_irq_enable();
}
void arch_cpu_idle_prepare(void)
diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
index 4784011cecac..9ebe02574127 100644
--- a/arch/arm64/kernel/process.c
+++ b/arch/arm64/kernel/process.c
@@ -126,7 +126,7 @@ void arch_cpu_idle(void)
* tricks
*/
cpu_do_idle();
- local_irq_enable();
+ raw_local_irq_enable();
}
#ifdef CONFIG_HOTPLUG_CPU
diff --git a/arch/csky/kernel/process.c b/arch/csky/kernel/process.c
index f730869e21ee..69af6bc87e64 100644
--- a/arch/csky/kernel/process.c
+++ b/arch/csky/kernel/process.c
@@ -102,6 +102,6 @@ void arch_cpu_idle(void)
#ifdef CONFIG_CPU_PM_STOP
asm volatile("stop\n");
#endif
- local_irq_enable();
+ raw_local_irq_enable();
}
#endif
diff --git a/arch/h8300/kernel/process.c b/arch/h8300/kernel/process.c
index aea0a40b77a9..bc1364db58fe 100644
--- a/arch/h8300/kernel/process.c
+++ b/arch/h8300/kernel/process.c
@@ -57,7 +57,7 @@ asmlinkage void ret_from_kernel_thread(void);
*/
void arch_cpu_idle(void)
{
- local_irq_enable();
+ raw_local_irq_enable();
__asm__("sleep");
}
diff --git a/arch/hexagon/kernel/process.c b/arch/hexagon/kernel/process.c
index 5a0a95d93ddb..67767c5ed98c 100644
--- a/arch/hexagon/kernel/process.c
+++ b/arch/hexagon/kernel/process.c
@@ -44,7 +44,7 @@ void arch_cpu_idle(void)
{
__vmwait();
/* interrupts wake us up, but irqs are still disabled */
- local_irq_enable();
+ raw_local_irq_enable();
}
/*
diff --git a/arch/ia64/kernel/process.c b/arch/ia64/kernel/process.c
index 6b61a703bcf5..c9ff8796b509 100644
--- a/arch/ia64/kernel/process.c
+++ b/arch/ia64/kernel/process.c
@@ -239,7 +239,7 @@ void arch_cpu_idle(void)
if (mark_idle)
(*mark_idle)(1);
- safe_halt();
+ raw_safe_halt();
if (mark_idle)
(*mark_idle)(0);
diff --git a/arch/microblaze/kernel/process.c b/arch/microblaze/kernel/process.c
index a9e46e525cd0..f99860771ff4 100644
--- a/arch/microblaze/kernel/process.c
+++ b/arch/microblaze/kernel/process.c
@@ -149,5 +149,5 @@ int dump_fpu(struct pt_regs *regs, elf_fpregset_t *fpregs)
void arch_cpu_idle(void)
{
- local_irq_enable();
+ raw_local_irq_enable();
}
diff --git a/arch/mips/kernel/idle.c b/arch/mips/kernel/idle.c
index 5bc3b04693c7..18e69ebf5691 100644
--- a/arch/mips/kernel/idle.c
+++ b/arch/mips/kernel/idle.c
@@ -33,19 +33,19 @@ static void __cpuidle r3081_wait(void)
{
unsigned long cfg = read_c0_conf();
write_c0_conf(cfg |
[GIT pull] irq/urgent for v5.10-rc6
Linus,
please pull the latest irq/urgent branch from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
irq-urgent-2020-11-29
up to: 7032908cd584: Merge tag 'irqchip-fixes-5.10-2' of
git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms into irq/urgent
Two fixes for irqchip drivers:
- Save and restore the GICV3 ITS state unconditionally on suspend/resume
to handle firmware which fails to do so.
- Use the correct index into the fwspec parameters to read the irq
trigger type in the EXIU chip driver.
Thanks,
tglx
-->
Chen Baozi (1):
irqchip/exiu: Fix the index of fwspec for IRQ type
Xu Qiang (1):
irqchip/gic-v3-its: Unconditionally save/restore the ITS state on suspend
drivers/irqchip/irq-gic-v3-its.c | 16 +++-
drivers/irqchip/irq-sni-exiu.c | 2 +-
2 files changed, 4 insertions(+), 14 deletions(-)
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 0fec31931e11..4069c215328b 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -42,7 +42,6 @@
#define ITS_FLAGS_CMDQ_NEEDS_FLUSHING (1ULL << 0)
#define ITS_FLAGS_WORKAROUND_CAVIUM_22375 (1ULL << 1)
#define ITS_FLAGS_WORKAROUND_CAVIUM_23144 (1ULL << 2)
-#define ITS_FLAGS_SAVE_SUSPEND_STATE (1ULL << 3)
#define RDIST_FLAGS_PROPBASE_NEEDS_FLUSHING(1 << 0)
#define RDIST_FLAGS_RD_TABLES_PREALLOCATED (1 << 1)
@@ -4741,9 +4740,6 @@ static int its_save_disable(void)
list_for_each_entry(its, _nodes, entry) {
void __iomem *base;
- if (!(its->flags & ITS_FLAGS_SAVE_SUSPEND_STATE))
- continue;
-
base = its->base;
its->ctlr_save = readl_relaxed(base + GITS_CTLR);
err = its_force_quiescent(base);
@@ -4762,9 +4758,6 @@ static int its_save_disable(void)
list_for_each_entry_continue_reverse(its, _nodes, entry) {
void __iomem *base;
- if (!(its->flags & ITS_FLAGS_SAVE_SUSPEND_STATE))
- continue;
-
base = its->base;
writel_relaxed(its->ctlr_save, base + GITS_CTLR);
}
@@ -4784,9 +4777,6 @@ static void its_restore_enable(void)
void __iomem *base;
int i;
- if (!(its->flags & ITS_FLAGS_SAVE_SUSPEND_STATE))
- continue;
-
base = its->base;
/*
@@ -4794,7 +4784,10 @@ static void its_restore_enable(void)
* don't restore it since writing to CBASER or BASER
* registers is undefined according to the GIC v3 ITS
* Specification.
+*
+* Firmware resuming with the ITS enabled is terminally broken.
*/
+ WARN_ON(readl_relaxed(base + GITS_CTLR) & GITS_CTLR_ENABLE);
ret = its_force_quiescent(base);
if (ret) {
pr_err("ITS@%pa: failed to quiesce on resume: %d\n",
@@ -5074,9 +5067,6 @@ static int __init its_probe_one(struct resource *res,
ctlr |= GITS_CTLR_ImDe;
writel_relaxed(ctlr, its->base + GITS_CTLR);
- if (GITS_TYPER_HCC(typer))
- its->flags |= ITS_FLAGS_SAVE_SUSPEND_STATE;
-
err = its_init_domain(handle, its);
if (err)
goto out_free_tables;
diff --git a/drivers/irqchip/irq-sni-exiu.c b/drivers/irqchip/irq-sni-exiu.c
index 1d027623c776..abd011fcecf4 100644
--- a/drivers/irqchip/irq-sni-exiu.c
+++ b/drivers/irqchip/irq-sni-exiu.c
@@ -136,7 +136,7 @@ static int exiu_domain_translate(struct irq_domain *domain,
if (fwspec->param_count != 2)
return -EINVAL;
*hwirq = fwspec->param[0];
- *type = fwspec->param[2] & IRQ_TYPE_SENSE_MASK;
+ *type = fwspec->param[1] & IRQ_TYPE_SENSE_MASK;
}
return 0;
}
Re: [PATCH 2/2] net: dsa: ksz8795: adjust CPU link to host interface
Hi Jean,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on net/master]
[also build test WARNING on ipvs/master linus/master v5.10-rc5]
[cannot apply to net-next/master next-20201127]
[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/Jean-Pihet/net-dsa-ksz-pad-frame-to-64-bytes-for-transmission/20201129-182750
base: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git
4d521943f76bd0d1e68ea5e02df7aadd30b2838a
config: x86_64-allyesconfig (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
reproduce (this is a W=1 build):
#
https://github.com/0day-ci/linux/commit/5a255bc7fbe20060c6f86dfaa0bbe9fbcd024128
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Jean-Pihet/net-dsa-ksz-pad-frame-to-64-bytes-for-transmission/20201129-182750
git checkout 5a255bc7fbe20060c6f86dfaa0bbe9fbcd024128
# save the attached .config to linux build tree
make W=1 ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> drivers/net/dsa/microchip/ksz8795.c:1114:6: warning: no previous prototype
>> for 'ksz8795_adjust_link' [-Wmissing-prototypes]
1114 | void ksz8795_adjust_link(struct dsa_switch *ds, int port,
| ^~~
vim +/ksz8795_adjust_link +1114 drivers/net/dsa/microchip/ksz8795.c
1113
> 1114 void ksz8795_adjust_link(struct dsa_switch *ds, int port,
1115 struct phy_device
*phydev)
1116 {
1117 struct ksz_device *dev = ds->priv;
1118 struct ksz_port *p = >ports[port];
1119
1120 /* Adjust the link interface mode and speed for the CPU port */
1121 if (port == dev->cpu_port)
1122 ksz8795_mii_config(dev, p);
1123 }
1124
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: [PATCH AUTOSEL 5.7 03/30] ima: extend boot_aggregate with kernel measurements
Hi Sasha,
On Wed, 2020-07-08 at 21:27 -0400, Sasha Levin wrote:
> On Wed, Jul 08, 2020 at 12:13:13PM -0400, Mimi Zohar wrote:
> >Hi Sasha,
> >
> >On Wed, 2020-07-08 at 11:40 -0400, Sasha Levin wrote:
> >> From: Maurizio Drocco
> >>
> >> [ Upstream commit 20c59ce010f84300f6c655d32db2610d3433f85c ]
> >>
> >> Registers 8-9 are used to store measurements of the kernel and its
> >> command line (e.g., grub2 bootloader with tpm module enabled). IMA
> >> should include them in the boot aggregate. Registers 8-9 should be
> >> only included in non-SHA1 digests to avoid ambiguity.
> >
> >Prior to Linux 5.8, the SHA1 template data hashes were padded before
> >being extended into the TPM. Support for calculating and extending
> >the per TPM bank template data digests is only being upstreamed in
> >Linux 5.8.
> >
> >How will attestation servers know whether to include PCRs 8 & 9 in the
> >the boot_aggregate calculation? Now, there is a direct relationship
> >between the template data SHA1 padded digest not including PCRs 8 & 9,
> >and the new per TPM bank template data digest including them.
>
> Got it, I'll drop it then, thank you!
After re-thinking this over, I realized that the attestation server can
verify the "boot_aggregate" based on the quoted PCRs without knowing
whether padded SHA1 hashes or per TPM bank hash values were extended
into the TPM[1], but non-SHA1 boot aggregate values [2] should always
include PCRs 8 & 9.
Any place commit 6f1a1d103b48 was backported [2], this commit
20c59ce010f8 ("ima: extend boot_aggregate with kernel measurements")
should be backported as well.
thanks,
Mimi
[1] commit 1ea973df6e21 ("ima: Calculate and extend PCR with digests in
ima_template_entry")
[2] commit 6f1a1d103b48 ("ima: Switch to ima_hash_algo for boot aggregate")
Re: [RESEND] [PATCH 1/2] iio: adc: qcom-spmi-vadc: Use right ratiometric range for 8998,660,845
On Sat, 26 Sep 2020 19:18:34 +0200
khol...@gmail.com wrote:
> From: AngeloGioacchino Del Regno
>
> The ratiometric range for MSM8998, SDM630/636/660 and SDM845 is 1875mV
> instead of the standard 1800mV: address this by adding a new compatible
> "qcom,spmi-vadc-8998" and assigning the different range to the machines
> declaring this one.
>
> Signed-off-by: AngeloGioacchino Del Regno
@Bjorn
Could you take a quick look at this pair of patches. It's been sat in
my queue waiting for appropriate review for rather too long!
(mainly because I've been rather lax in checking on status of older
series really - sorry about that :(
Thanks
Jonathan
> ---
> drivers/iio/adc/qcom-spmi-vadc.c | 10 +-
> drivers/iio/adc/qcom-vadc-common.h | 1 +
> 2 files changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iio/adc/qcom-spmi-vadc.c
> b/drivers/iio/adc/qcom-spmi-vadc.c
> index b0388f8a69f4..59a94ea7bf78 100644
> --- a/drivers/iio/adc/qcom-spmi-vadc.c
> +++ b/drivers/iio/adc/qcom-spmi-vadc.c
> @@ -101,6 +101,7 @@ struct vadc_channel_prop {
> * @dev: pointer to struct device.
> * @base: base address for the ADC peripheral.
> * @nchannels: number of VADC channels.
> + * @ratio_range: ratiometric range for ref points.
> * @chan_props: array of VADC channel properties.
> * @iio_chans: array of IIO channels specification.
> * @are_ref_measured: are reference points measured.
> @@ -114,6 +115,7 @@ struct vadc_priv {
> struct device*dev;
> u16 base;
> unsigned int nchannels;
> + unsigned int ratio_range;
> struct vadc_channel_prop *chan_props;
> struct iio_chan_spec *iio_chans;
> bool are_ref_measured;
> @@ -355,7 +357,7 @@ static int vadc_measure_ref_points(struct vadc_priv *vadc)
> u16 read_1, read_2;
> int ret;
>
> - vadc->graph[VADC_CALIB_RATIOMETRIC].dx = VADC_RATIOMETRIC_RANGE;
> + vadc->graph[VADC_CALIB_RATIOMETRIC].dx = vadc->ratio_range;
> vadc->graph[VADC_CALIB_ABSOLUTE].dx = VADC_ABSOLUTE_RANGE_UV;
>
> prop = vadc_get_channel(vadc, VADC_REF_1250MV);
> @@ -885,6 +887,11 @@ static int vadc_probe(struct platform_device *pdev)
> if (ret)
> return ret;
>
> + if (of_device_is_compatible(node, "qcom,spmi-vadc-8998"))
> + vadc->ratio_range = VADC_RATIOMETRIC_RANGE_8998;
> + else
> + vadc->ratio_range = VADC_RATIOMETRIC_RANGE;
> +
> irq_eoc = platform_get_irq(pdev, 0);
> if (irq_eoc < 0) {
> if (irq_eoc == -EPROBE_DEFER || irq_eoc == -EINVAL)
> @@ -918,6 +925,7 @@ static int vadc_probe(struct platform_device *pdev)
>
> static const struct of_device_id vadc_match_table[] = {
> { .compatible = "qcom,spmi-vadc" },
> + { .compatible = "qcom-spmi-vadc-8998" },
> { }
> };
> MODULE_DEVICE_TABLE(of, vadc_match_table);
> diff --git a/drivers/iio/adc/qcom-vadc-common.h
> b/drivers/iio/adc/qcom-vadc-common.h
> index 17b2fc4d8bf2..b10d5fd59034 100644
> --- a/drivers/iio/adc/qcom-vadc-common.h
> +++ b/drivers/iio/adc/qcom-vadc-common.h
> @@ -16,6 +16,7 @@
>
> #define VADC_ABSOLUTE_RANGE_UV 625000
> #define VADC_RATIOMETRIC_RANGE 1800
> +#define VADC_RATIOMETRIC_RANGE_8998 1875
>
> #define VADC_DEF_PRESCALING 0 /* 1:1 */
> #define VADC_DEF_DECIMATION 0 /* 512 */
Re: [RESEND PATCH 1/2] iio:core: Introduce unlocked version of iio_map_array_unregister()
On Sat, 28 Nov 2020 15:22:16 +0100 Lino Sanfilippo wrote: > Hi Jonathan, > > On 28.11.20 at 14:54, Jonathan Cameron wrote: > > > A few notes to make it harder for people to do that in future. > > 1. Don't send patch series (or new versions of older patches) in reply > >to an existing thread. They get lost and difficult to pull out. > >b4 can't automatically figure out which patches to pull from that > >original thread for example. > > 2. Always version number whole series with same number, even if some patches > >are new. So this should be v3. > > > > Thanks for these hints, I will keep it in mind for future patch submissions. Mailing list seems to have recovered so I can use b4 again :) Applied to the togreg branch of iio.git and pushed out as testing so the autobuilders can try to find anything we missed. Thanks, Jonathan > > Regards, > Lino >
Re: [PATCH v3 00/10] iio: adc: at91_adc: cleanup DT bindings
On Sat, 28 Nov 2020 23:28:08 +0100 Alexandre Belloni wrote: > Hello, > > This series cleans up the at91_adc devicetree bindings. This mainly > moves back the resolution options and names and the triggers description > back in the driver. > Applied 1-7 to the togreg branch of iio.git and pushed out as testing for the autobuilders to do their magic. Thanks, Jonathan > Changes in v3: > - rebased on the togreg branch of iio.git > - dropped "iio: adc: at91_adc: remove forward declaration" as it was already >done in tree > - Reworked patch 1 from "iio: adc: at91_adc: remove platform data" to "iio: >adc: at91_adc: remove at91_adc_ids" > > Changes in v2: > - separated out the dt-binding change to give a chance to Rob to actually >review them. > - Dropped "iio: adc: at91_adc: use devm_input_allocate_device" > - Collected tags > - use of_device_get_match_data instead of device_get_match_data > - include backportable sam9rl trigger fix > > > Alexandre Belloni (9): > iio: adc: at91_adc: remove at91_adc_ids > iio: adc: at91_adc: rework resolution selection > dt-bindings:iio:adc:remove atmel,adc-res and atmel,adc-res-names > iio: adc: at91_adc: rework trigger definition > dt-bindings:iio:adc:remove triggers > iio: adc: at91_adc: merge at91_adc_probe_dt back in at91_adc_probe > ARM: dts: at91: sama5d3: use proper ADC compatible > ARM: dts: at91: at91sam9rl: fix ADC triggers > ARM: dts: at91: remove deprecated ADC properties > > Jonathan Cameron (1): > dt-bindings:iio:adc:atmel,sama9260-adc: conversion to yaml from > at91_adc.txt > > .../devicetree/bindings/iio/adc/at91_adc.txt | 83 - > .../bindings/iio/adc/atmel,sama9260-adc.yaml | 121 +++ > arch/arm/boot/dts/at91sam9260.dtsi| 25 -- > arch/arm/boot/dts/at91sam9g45.dtsi| 27 -- > arch/arm/boot/dts/at91sam9rl.dtsi | 25 -- > arch/arm/boot/dts/at91sam9x5.dtsi | 28 -- > arch/arm/boot/dts/sama5d3.dtsi| 26 +- > arch/arm/boot/dts/sama5d4.dtsi| 22 -- > drivers/iio/adc/at91_adc.c| 294 +++--- > 9 files changed, 237 insertions(+), 414 deletions(-) > delete mode 100644 Documentation/devicetree/bindings/iio/adc/at91_adc.txt > create mode 100644 > Documentation/devicetree/bindings/iio/adc/atmel,sama9260-adc.yaml >
Re: [PATCH] hwmon: corsair-psu: update supported devices
On Sun, Nov 29, 2020 at 07:36:18AM +0100, Wilken Gottwalt wrote: > On Sat, 28 Nov 2020 17:21:40 -0300 > Jonas Malaco wrote: > > > On Sat, Nov 28, 2020 at 7:35 AM Wilken Gottwalt > > wrote: > > > > > > On Sat, 28 Nov 2020 02:37:38 -0300 > > > Jonas Malaco wrote: > > > > > > > On Thu, Nov 26, 2020 at 8:43 AM Wilken Gottwalt > > > > wrote: > > > > > > > > > > Adds support for another Corsair PSUs series: AX760i, AX860i, AX1200i, > > > > > AX1500i and AX1600i. The first 3 power supplies are supported through > > > > > the Corsair Link USB Dongle which is some kind of USB/Serial/TTL > > > > > converter especially made for the COM ports of these power supplies. > > > > > There are 3 known revisions of these adapters. The AX1500i power > > > > > supply > > > > > has revision 3 built into the case and AX1600i is the only one in that > > > > > series, which has an unique usb hid id like the RM/RX series. > > > > > > > > Can I ask what AXi power supplies were tested? > > > > > > > > I ask because, based on the user-space implementations I am aware of, > > > > the AXi dongle protocol appears to be different from the RMi/HXi series. > > > > > > I was not able to test this against the AX power supplies, they are really > > > hard to find (and are far to expensive). But I went through all these > > > tools > > > and stuck to the most common commands, which all 3 series support. Not > > > every > > > series supports all commands (there also seem to be different firmwares in > > > the micro-conrollers). But this is fine, some sensors will show up as N/A. > > > Even my HX850i does not support all commands covered in this driver. > > > > I think the similarities come from all using wrappers over the PMBus > > interface to the voltage controller. But I am not sure the wrapping > > protocols are identical. > > > > For example, cpsumon shows significantly more things going on during a > > read than what is needed for the RMi/HXi series.[1] > > > > [1] > > https://github.com/ka87/cpsumon/blob/fd639684d7f9/libcpsumon/src/cpsumon.c#L213-L231 > > > > > > > > > > > AXi dongle: > > > > - https://github.com/ka87/cpsumon > > > > > > This tool made me to consider including the AX series, because it uses > > > some > > > of the same commands on the AX760i, AX860i, AX1200i and AX1500i. But it is > > > a usb-serial tool only. But it was nice to know, that the commands are > > > mostly > > > the same. I left out all the commands for configuring, PCIe power rails, > > > efficiency and others which do not really belong into hwmon. > > > > > > > RMi/HXi: > > > > - https://github.com/jonasmalacofilho/liquidctl > > > > - https://github.com/audiohacked/OpenCorsairLink > > > > > > This tool made me include the AX series, because it uses the rmi protocol > > > component for the rmi driver (RM/HX series) and the corsair dongles. > > > > The corsairlink_driver_dongle has no implementations for reading sensor > > data (compare that with the corsairlink_driver_rmi).[2][3] There is > > also no code that actually tries to read (write) from (to) the device > > using that dongle driver.[4] > > > > I also looked at a few of the issues, and all of the ones I read > > mentioned AXi support being under development, and the hypothesis of the > > AXi series being compatible with the RMi/HXi code still remaining to be > > confirmed. > > > > [2] > > https://github.com/audiohacked/OpenCorsairLink/blob/61d336a61b85/drivers/dongle.c#L33-L39 > > [3] > > https://github.com/audiohacked/OpenCorsairLink/blob/61d336a61b85/drivers/rmi.c#L33-L57 > > [4] > > https://github.com/audiohacked/OpenCorsairLink/blob/61d336a61b85/main.c#L106 > > > > > > > > > > > - https://github.com/notaz/corsairmi > > > > > > This one covers only some HX/RM PSUs, but is uses the rawhid access which > > > made me looking up the actual usb chips/bridges Corsair uses. > > > > > > > > > > > One additional concern is that the non-HID AXi dongles may only have > > > > bulk > > > > USB endpoints, and this is a HID driver.[1] > > > > > > You are right, in the case of the dongles it could be different. But I did > > > some research on Corsair usb driven devices and they really like to stick > > > to > > > the cp210x, which is an usb hid bridge. The commit > > > b9326057a3d8447f5d2e74a7b521ccf21add2ec0 actually covers two Corsair USB > > > dongles as a cp210x device. So it is very likely that all Corsair PSUs > > > with > > > such an interface/dongle use usb hid. But I'm completely open to get > > > proven > > > wrong. Actually I really would like to see this tested by people who have > > > access to the more rare devices. > > > > I could be wrong (and I am sorry for the noise if that is the case), but > > as far as I can see the cp210x does not create a HID device. > > No no, this is fine. It really helps if some more people are looking into > this. > I wish I had access to at least one of the later models (AX1500i/AX1600i), I > make mistakes from time to time. And it
Re: [RFC PATCH v6 2/8] drivers: thermal: tsens: Add VER_0 tsens version
On Thu, Nov 26, 2020 at 2:16 AM Ansuel Smith wrote:
> > > };
> > > @@ -441,6 +442,10 @@ enum regfield_ids {
> > > CRIT_THRESH_14,
> > > CRIT_THRESH_15,
> > >
> > > + /* VER_0 MIN MAX THRESH */
> > > + MIN_THRESH_0,
> > > + MAX_THRESH_0,
> > > +
> >
> > Consider reusing LOW_THRESH_0 and UP_THRESH_0 for these?
> >
>
> As we already have defined LOW_THRESH and UP how can we reuse that
> regfield to define MIN and MAX?
>
We are using MIN and MAX THRESH on the apq8064 to mean LOW and UP
THRESOLD, isn't it? IIUC, It was just named differently earlier.
When the driver is loaded on the apq8064, only that one field will be
use since v0 has a single threshold for all sensors. When the driver
is loaded on new IPs, all fields will be used.
[PATCH] vdpa: ifcvf: Use dma_set_mask_and_coherent to simplify code
'pci_set_dma_mask()' + 'pci_set_consistent_dma_mask()' can be replaced by
an equivalent 'dma_set_mask_and_coherent()' which is much less verbose.
While at it, fix a typo (s/confiugration/configuration)
Signed-off-by: Christophe JAILLET
---
drivers/vdpa/ifcvf/ifcvf_main.c | 11 ++-
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/drivers/vdpa/ifcvf/ifcvf_main.c b/drivers/vdpa/ifcvf/ifcvf_main.c
index 8b4028556cb6..fa1af301cf55 100644
--- a/drivers/vdpa/ifcvf/ifcvf_main.c
+++ b/drivers/vdpa/ifcvf/ifcvf_main.c
@@ -417,16 +417,9 @@ static int ifcvf_probe(struct pci_dev *pdev, const struct
pci_device_id *id)
return ret;
}
- ret = pci_set_dma_mask(pdev, DMA_BIT_MASK(64));
+ ret = dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64));
if (ret) {
- IFCVF_ERR(pdev, "No usable DMA confiugration\n");
- return ret;
- }
-
- ret = pci_set_consistent_dma_mask(pdev, DMA_BIT_MASK(64));
- if (ret) {
- IFCVF_ERR(pdev,
- "No usable coherent DMA confiugration\n");
+ IFCVF_ERR(pdev, "No usable DMA configuration\n");
return ret;
}
--
2.27.0
Re: [PATCH 2/2] net: dsa: ksz8795: adjust CPU link to host interface
Hi Jean, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on net/master] [also build test WARNING on ipvs/master linus/master v5.10-rc5] [cannot apply to net-next/master next-20201127] [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/Jean-Pihet/net-dsa-ksz-pad-frame-to-64-bytes-for-transmission/20201129-182750 base: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git 4d521943f76bd0d1e68ea5e02df7aadd30b2838a config: i386-randconfig-s031-20201129 (attached as .config) compiler: gcc-9 (Debian 9.3.0-15) 9.3.0 reproduce: # apt-get install sparse # sparse version: v0.6.3-170-g3bc348f6-dirty # https://github.com/0day-ci/linux/commit/5a255bc7fbe20060c6f86dfaa0bbe9fbcd024128 git remote add linux-review https://github.com/0day-ci/linux git fetch --no-tags linux-review Jean-Pihet/net-dsa-ksz-pad-frame-to-64-bytes-for-transmission/20201129-182750 git checkout 5a255bc7fbe20060c6f86dfaa0bbe9fbcd024128 # save the attached .config to linux build tree make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=i386 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot "sparse warnings: (new ones prefixed by >>)" >> drivers/net/dsa/microchip/ksz8795.c:1114:6: sparse: sparse: symbol >> 'ksz8795_adjust_link' was not declared. Should it be static? Please review and possibly fold the followup patch. --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip
[RFC PATCH] net: dsa: ksz8795: ksz8795_adjust_link() can be static
Reported-by: kernel test robot
Signed-off-by: kernel test robot
---
ksz8795.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/dsa/microchip/ksz8795.c
b/drivers/net/dsa/microchip/ksz8795.c
index 09c1173cc6073c..834a8dc251adba 100644
--- a/drivers/net/dsa/microchip/ksz8795.c
+++ b/drivers/net/dsa/microchip/ksz8795.c
@@ -,7 +,7 @@ static int ksz8795_setup(struct dsa_switch *ds)
return 0;
}
-void ksz8795_adjust_link(struct dsa_switch *ds, int port,
+static void ksz8795_adjust_link(struct dsa_switch *ds, int port,
struct phy_device *phydev)
{
struct ksz_device *dev = ds->priv;
Re: [PATCH 1/1] mm: compaction: avoid fast_isolate_around() to set pageblock_skip on reserved pages
Hello Andrea,
On Thu, Nov 26, 2020 at 07:46:05PM +0200, Mike Rapoport wrote:
> On Thu, Nov 26, 2020 at 11:05:14AM +0100, David Hildenbrand wrote:
>
> Let's try to merge init_unavailable_memory() into memmap_init().
> Than it'll be able to set zone/nid for those nasty pfns that BIOS
> decided to keep to itself, like in Andrea's case and will also take care
> of struct pages that do not really have a frame in DRAM, but are there
> because of arbitrary section size.
Did you have a chance to check if this solves your issue?
If yes, I'll resend this as a formal patch.
> Something like this:
>
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index eaa227a479e4..072e94042a11 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -6185,24 +6185,84 @@ static void __meminit zone_init_free_lists(struct
> zone *zone)
> }
> }
>
> -void __meminit __weak memmap_init(unsigned long size, int nid,
> - unsigned long zone,
> - unsigned long range_start_pfn)
> +#if !defined(CONFIG_FLAT_NODE_MEM_MAP)
> +/*
> + * Only struct pages that are backed by physical memory available to the
> + * kernel are zeroed and initialized by memmap_init_zone().
> + * But, there are some struct pages that are either reserved by firmware or
> + * do not correspond to physical page frames becuase actual memory bank is
> + * not a multiple of SECTION_SIZE. Fields of those struct pages may be
> + * accessed (for example page_to_pfn() on some configuration accesses
> + * flags) so we must explicitly initialize those struct pages.
> + */
> +static u64 __init init_unavailable_range(unsigned long spfn, unsigned long
> epfn,
> + int zone, int node)
> {
> - unsigned long start_pfn, end_pfn;
> + unsigned long pfn;
> + u64 pgcnt = 0;
> +
> + for (pfn = spfn; pfn < epfn; pfn++) {
> + if (!pfn_valid(ALIGN_DOWN(pfn, pageblock_nr_pages))) {
> + pfn = ALIGN_DOWN(pfn, pageblock_nr_pages)
> + + pageblock_nr_pages - 1;
> + continue;
> + }
> + __init_single_page(pfn_to_page(pfn), pfn, zone, node);
> + __SetPageReserved(pfn_to_page(pfn));
> + pgcnt++;
> + }
> +
> + return pgcnt;
> +}
> +#else
> +static inline u64 init_unavailable_range(unsigned long spfn, unsigned long
> epfn,
> + int zone, int node)
> +{
> + return 0;
> +}
> +#endif
> +
> +void __init __weak memmap_init(unsigned long size, int nid,
> +unsigned long zone,
> +unsigned long range_start_pfn)
> +{
> + unsigned long start_pfn, end_pfn, next_pfn = 0;
> unsigned long range_end_pfn = range_start_pfn + size;
> + u64 pgcnt = 0;
> int i;
>
> for_each_mem_pfn_range(i, nid, _pfn, _pfn, NULL) {
> start_pfn = clamp(start_pfn, range_start_pfn, range_end_pfn);
> end_pfn = clamp(end_pfn, range_start_pfn, range_end_pfn);
> + next_pfn = clamp(next_pfn, range_start_pfn, range_end_pfn);
>
> if (end_pfn > start_pfn) {
> size = end_pfn - start_pfn;
> memmap_init_zone(size, nid, zone, start_pfn,
>MEMINIT_EARLY, NULL, MIGRATE_MOVABLE);
> }
> +
> + if (next_pfn < start_pfn)
> + pgcnt += init_unavailable_range(next_pfn, start_pfn,
> + zone, nid);
> + next_pfn = end_pfn;
> }
> +
> + /*
> + * Early sections always have a fully populated memmap for the whole
> + * section - see pfn_valid(). If the last section has holes at the
> + * end and that section is marked "online", the memmap will be
> + * considered initialized. Make sure that memmap has a well defined
> + * state.
> + */
> + if (next_pfn < range_end_pfn)
> + pgcnt += init_unavailable_range(next_pfn, range_end_pfn,
> + zone, nid);
> +
> + if (pgcnt)
> + pr_info("%s: Zeroed struct page in unavailable ranges: %lld\n",
> + zone_names[zone], pgcnt);
> +
> }
>
> static int zone_batchsize(struct zone *zone)
> @@ -6995,88 +7055,6 @@ void __init free_area_init_memoryless_node(int nid)
> free_area_init_node(nid);
> }
>
> -#if !defined(CONFIG_FLAT_NODE_MEM_MAP)
> -/*
> - * Initialize all valid struct pages in the range [spfn, epfn) and mark them
> - * PageReserved(). Return the number of struct pages that were initialized.
> - */
> -static u64 __init init_unavailable_range(unsigned long spfn, unsigned long
> epfn)
> -{
> - unsigned long pfn;
> - u64 pgcnt = 0;
> -
> - for (pfn = spfn; pfn < epfn; pfn++) {
> - if (!pfn_valid(ALIGN_DOWN(pfn, pageblock_nr_pages))) {
> -
[PATCH v2] media: saa7146: 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 'saa7146_pgtable_alloc()' GFP_KERNEL can be
used because the callers are either .buf_prepare functions or function that
already use GFP_KERNEL (hidden in a 'vmalloc_32()' call).
When memory is allocated in 'saa7146_init_one()' GFP_KERNEL can be used
because it is probe function and no lock is taken in the between.
When memory is allocated in 'saa7146_vv_init()' GFP_KERNEL can be used
because this function already uses GFP_KERNEL and no lock is taken in the
between.
When memory is allocated in 'vbi_workaround()' GFP_KERNEL can be used
because it is only called from a .open function.
@@
@@
-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
V1 -> v2: fix to GFP_ flag that had been left as-is. They should be GFP_KERNEL
---
drivers/media/common/saa7146/saa7146_core.c | 39 +++--
drivers/media/common/saa7146/saa7146_fops.c | 7 ++--
drivers/media/common/saa7146/saa7146_vbi.c | 6 ++--
3 files changed, 28 insertions(+), 24 deletions(-)
diff --git a/drivers/media/common/saa7146/saa7146_core.c
b/drivers/media/common/saa7146/saa7146_core.c
index 21fb16cc5ca1..f2d13b71416c 100644
--- a/drivers/media/common/saa7146/saa7146_core.c
+++ b/drivers/media/common/saa7146/saa7146_core.c
@@ -177,7 +177,7 @@ void *saa7146_vmalloc_build_pgtable(struct pci_dev *pci,
long length, struct saa
goto err_free_slist;
pt->nents = pages;
- slen = pci_map_sg(pci,pt->slist,pt->nents,PCI_DMA_FROMDEVICE);
+ slen = dma_map_sg(>dev, pt->slist, pt->nents, DMA_FROM_DEVICE);
if (0 == slen)
goto err_free_pgtable;
@@ -187,7 +187,7 @@ void *saa7146_vmalloc_build_pgtable(struct pci_dev *pci,
long length, struct saa
return mem;
err_unmap_sg:
- pci_unmap_sg(pci, pt->slist, pt->nents, PCI_DMA_FROMDEVICE);
+ dma_unmap_sg(>dev, pt->slist, pt->nents, DMA_FROM_DEVICE);
err_free_pgtable:
saa7146_pgtable_free(pci, pt);
err_free_slist:
@@ -201,7 +201,7 @@ void *saa7146_vmalloc_build_pgtable(struct pci_dev *pci,
long length, struct saa
void saa7146_vfree_destroy_pgtable(struct pci_dev *pci, void *mem, struct
saa7146_pgtable *pt)
{
- pci_unmap_sg(pci, pt->slist, pt->nents, PCI_DMA_FROMDEVICE);
+ dma_unmap_sg(>dev, pt->slist, pt->nents, DMA_FROM_DEVICE);
saa7146_pgtable_free(pci, pt);
kfree(pt->slist);
pt->slist = NULL;
@@ -212,7 +212,7 @@ void saa7146_pgtable_free(struct pci_dev *pci, struct
saa7146_pgtable *pt)
{
if (NULL == pt->cpu)
return;
- pci_free_consistent(pci, pt->size, pt->cpu, pt->dma);
+ dma_free_coherent(>dev, pt->size, pt->cpu, pt->dma);
RE: [PATCH 2/2] mmc: core: MMC_CAP2_HS200_1_8V_SDR with mmc-hs400-1_8v
> This patch remove the MMC_CAP2_HS200_1_8V_SDR capacity from > host->cap2 when the dt property mmc-hs400-1v8 set. It cause > error and occasionally hang on boot and reboot. > Board with this issue: rk3399 with SanDisk DG4008 eMMC. > > This patch did not change the mmc-hs400-1_2v host->cap2 > added the MMC_CAP2_HS200_1_2V_SDR. > > Log shows a boot process with a HS400 5.1 capable SanDisk 8G > with mmc-hs400-1_8v dt property and the MMC_CAP2_HS200_1_8V_SDR > append to the host->cap2. > > [1.775721] mmc1: CQHCI version 5.10 > [1.802342] mmc1: SDHCI controller on fe33.sdhci [fe33.sdhci] > using ADMA > [2.007581] mmc1: mmc_select_hs200 failed, error -110 > [2.007589] mmc1: error -110 whilst initialising MMC card > [2.413559] mmc1: mmc_select_hs200 failed, error -110 > [2.413562] mmc1: error -110 whilst initialising MMC card > [3.183343] mmc1: Command Queue Engine enabled > [3.183355] mmc1: new HS400 MMC card at address 0001 > [3.197163] mmcblk1: mmc1:0001 DG4008 7.28 GiB > [3.197256] mmcblk1boot0: mmc1:0001 DG4008 partition 1 4.00 MiB > [3.197360] mmcblk1boot1: mmc1:0001 DG4008 partition 2 4.00 MiB > [3.197479] mmcblk1rpmb: mmc1:0001 DG4008 partition 3 4.00 MiB, chardev > (242:0) > > after patch applied > [1.746691] mmc1: CQHCI version 5.10 > [1.773316] mmc1: SDHCI controller on fe33.sdhci [fe33.sdhci] > using ADMA > [1.858410] mmc1: Command Queue Engine enabled > [1.858418] mmc1: new HS400 MMC card at address 0001 > [1.858897] mmcblk1: mmc1:0001 DG4008 7.28 GiB > [1.859002] mmcblk1boot0: mmc1:0001 DG4008 partition 1 4.00 MiB > [1.859097] mmcblk1boot1: mmc1:0001 DG4008 partition 2 4.00 MiB > [1.859182] mmcblk1rpmb: mmc1:0001 DG4008 partition 3 4.00 MiB, chardev > (242:0) > > Fixes: c373eb489b27b mmc: core: add DT bindings for eMMC HS400 1.8/1.2V > > Signed-off-by: Chris Ruehl Acked-by: Avri Altman
RE: [PATCH] mmc: core: MMC_CAP2_HS200_1_8V_SDR with mmc-hs400-1_8v
> This patch remove the MMC_CAP2_HS200_1_8V_SDR capacity from > host->cap2 when the dt property mmc-hs400-1v8 set. It cause > error and occasionally hang on boot and reboot. > Board with this issue: rk3399 with SanDisk DG4008 eMMC. > > This patch did not change the mmc-hs400-1_2v host->cap2 > added the MMC_CAP2_HS200_1_2V_SDR. > > Log shows a boot process with a HS400 5.1 capable SanDisk 8G > with mmc-hs400-1_8v dt property and the MMC_CAP2_HS200_1_8V_SDR > append to the host->cap2. > > [1.775721] mmc1: CQHCI version 5.10 > [1.802342] mmc1: SDHCI controller on fe33.sdhci [fe33.sdhci] > using ADMA > [2.007581] mmc1: mmc_select_hs200 failed, error -110 > [2.007589] mmc1: error -110 whilst initialising MMC card > [2.413559] mmc1: mmc_select_hs200 failed, error -110 > [2.413562] mmc1: error -110 whilst initialising MMC card > [3.183343] mmc1: Command Queue Engine enabled > [3.183355] mmc1: new HS400 MMC card at address 0001 > [3.197163] mmcblk1: mmc1:0001 DG4008 7.28 GiB > [3.197256] mmcblk1boot0: mmc1:0001 DG4008 partition 1 4.00 MiB > [3.197360] mmcblk1boot1: mmc1:0001 DG4008 partition 2 4.00 MiB > [3.197479] mmcblk1rpmb: mmc1:0001 DG4008 partition 3 4.00 MiB, chardev > (242:0) > > after patch applied > [1.746691] mmc1: CQHCI version 5.10 > [1.773316] mmc1: SDHCI controller on fe33.sdhci [fe33.sdhci] > using ADMA > [1.858410] mmc1: Command Queue Engine enabled > [1.858418] mmc1: new HS400 MMC card at address 0001 > [1.858897] mmcblk1: mmc1:0001 DG4008 7.28 GiB > [1.859002] mmcblk1boot0: mmc1:0001 DG4008 partition 1 4.00 MiB > [1.859097] mmcblk1boot1: mmc1:0001 DG4008 partition 2 4.00 MiB > [1.859182] mmcblk1rpmb: mmc1:0001 DG4008 partition 3 4.00 MiB, chardev > (242:0) > > Fixes: c373eb489b27b mmc: core: add DT bindings for eMMC HS400 1.8/1.2V > > Signed-off-by: Chris Ruehl Acked-by: Avri Altman
Re: [PATCH NACK] media: saa7146: switch from 'pci_' to 'dma_' API
Le 29/11/2020 à 08:38, Christophe JAILLET a écrit : When memory is allocated in 'saa7146_vv_init()' GFP_KERNEL can be used because this function already uses GFP_KERNEL and no lock is taken in the between. When memory is allocated in 'vbi_workaround()' GFP_KERNEL can be used because it is only called from a .open function. diff --git a/drivers/media/common/saa7146/saa7146_fops.c b/drivers/media/common/saa7146/saa7146_fops.c index e936c56b0378..7b1840cad278 100644 --- a/drivers/media/common/saa7146/saa7146_fops.c +++ b/drivers/media/common/saa7146/saa7146_fops.c @@ -515,8 +515,8 @@ int saa7146_vv_init(struct saa7146_dev* dev, struct saa7146_ext_vv *ext_vv) dev->ext_vv_data = ext_vv; vv->d_clipping.cpu_addr = - pci_zalloc_consistent(dev->pci, SAA7146_CLIPPING_MEM, - >d_clipping.dma_handle); + dma_alloc_coherent(>pci->dev, SAA7146_CLIPPING_MEM, + >d_clipping.dma_handle, GFP_); > diff --git a/drivers/media/common/saa7146/saa7146_vbi.c b/drivers/media/common/saa7146/saa7146_vbi.c index e1d369b976ed..e140d4a5aeb2 100644 --- a/drivers/media/common/saa7146/saa7146_vbi.c +++ b/drivers/media/common/saa7146/saa7146_vbi.c @@ -22,7 +22,7 @@ static int vbi_workaround(struct saa7146_dev *dev) as specified. there is this workaround, but please don't let me explain it. ;-) */ - cpu = pci_alloc_consistent(dev->pci, 4096, _addr); + cpu = dma_alloc_coherent(>pci->dev, 4096, _addr, GFP_); The patch don't have 2 needed commit that got stucked on my machine. The analysis at the top of the patch description is fine, but the corresponding s/GFP_/GFP_KERNEL/ are not part of the patch itself. I'll send a v2. Sorry for the noise. CJ
Re: KASAN: use-after-free Read in idr_for_each (2)
On Sun, Nov 29, 2020 at 07:34:29PM +0800, Hillf Danton wrote:
> > radix_tree_next_slot include/linux/radix-tree.h:422 [inline]
> > idr_for_each+0x206/0x220 lib/idr.c:202
> > io_destroy_buffers fs/io_uring.c:8275 [inline]
>
> Matthew, can you shed any light on the link between the use of idr
> routines and the UAF reported?
I presume it's some misuse of IDR by io_uring. I'd rather io_uring
didn't use the IDR at all. This compiles; I promise no more than that.
diff --git a/fs/io_uring.c b/fs/io_uring.c
index ef3cd7fe4416..2fcf196bb3c3 100644
--- a/fs/io_uring.c
+++ b/fs/io_uring.c
@@ -344,7 +344,7 @@ struct io_ring_ctx {
struct socket *ring_sock;
#endif
- struct idr io_buffer_idr;
+ struct xarray io_buffers;
struct idr personality_idr;
@@ -1298,7 +1298,7 @@ static struct io_ring_ctx *io_ring_ctx_alloc(struct
io_uring_params *p)
INIT_LIST_HEAD(>cq_overflow_list);
init_completion(>ref_comp);
init_completion(>sq_thread_comp);
- idr_init(>io_buffer_idr);
+ xa_init(>io_buffers);
idr_init(>personality_idr);
mutex_init(>uring_lock);
init_waitqueue_head(>wait);
@@ -3042,7 +3042,7 @@ static struct io_buffer *io_buffer_select(struct io_kiocb
*req, size_t *len,
lockdep_assert_held(>ctx->uring_lock);
- head = idr_find(>ctx->io_buffer_idr, bgid);
+ head = xa_load(>ctx->io_buffers, bgid);
if (head) {
if (!list_empty(>list)) {
kbuf = list_last_entry(>list, struct io_buffer,
@@ -3050,7 +3050,7 @@ static struct io_buffer *io_buffer_select(struct io_kiocb
*req, size_t *len,
list_del(>list);
} else {
kbuf = head;
- idr_remove(>ctx->io_buffer_idr, bgid);
+ xa_erase(>ctx->io_buffers, bgid);
}
if (*len > kbuf->len)
*len = kbuf->len;
@@ -4130,7 +4130,8 @@ static int __io_remove_buffers(struct io_ring_ctx *ctx,
struct io_buffer *buf,
}
i++;
kfree(buf);
- idr_remove(>io_buffer_idr, bgid);
+ if (nbufs != -1U)
+ xa_erase(>io_buffers, bgid);
return i;
}
@@ -4148,7 +4149,7 @@ static int io_remove_buffers(struct io_kiocb *req, bool
force_nonblock,
lockdep_assert_held(>uring_lock);
ret = -ENOENT;
- head = idr_find(>io_buffer_idr, p->bgid);
+ head = xa_load(>io_buffers, p->bgid);
if (head)
ret = __io_remove_buffers(ctx, head, p->bgid, p->nbufs);
@@ -4225,15 +4226,15 @@ static int io_provide_buffers(struct io_kiocb *req,
bool force_nonblock,
lockdep_assert_held(>uring_lock);
- list = head = idr_find(>io_buffer_idr, p->bgid);
+ list = head = xa_load(>io_buffers, p->bgid);
ret = io_add_buffers(p, );
if (ret < 0)
goto out;
if (!list) {
- ret = idr_alloc(>io_buffer_idr, head, p->bgid, p->bgid + 1,
- GFP_KERNEL);
+ ret = xa_err(xa_store(>io_buffers, p->bgid, head,
+ GFP_KERNEL));
if (ret < 0) {
__io_remove_buffers(ctx, head, p->bgid, -1U);
goto out;
@@ -8468,19 +8469,15 @@ static int io_eventfd_unregister(struct io_ring_ctx
*ctx)
return -ENXIO;
}
-static int __io_destroy_buffers(int id, void *p, void *data)
-{
- struct io_ring_ctx *ctx = data;
- struct io_buffer *buf = p;
-
- __io_remove_buffers(ctx, buf, id, -1U);
- return 0;
-}
-
static void io_destroy_buffers(struct io_ring_ctx *ctx)
{
- idr_for_each(>io_buffer_idr, __io_destroy_buffers, ctx);
- idr_destroy(>io_buffer_idr);
+ unsigned long pgid;
+ struct io_buffer *buf;
+
+ xa_for_each(>io_buffers, pgid, buf) {
+ xa_erase(>io_buffers, pgid);
+ __io_remove_buffers(ctx, buf, pgid, -1U);
+ }
}
static void io_ring_ctx_free(struct io_ring_ctx *ctx)
Re: [PATCH v3 04/10] dt-bindings:iio:adc:atmel,sama9260-adc: conversion to yaml from at91_adc.txt
On Sat, 28 Nov 2020 23:28:12 +0100
Alexandre Belloni wrote:
> From: Jonathan Cameron
>
> There are a few things we would do differently in an ADC binding if we
> were starting from scratch but we are stuck with what we have (which
> made sense back when this was written!)
>
> We may be able to tighten up some elements of this binding in the future
> by careful checking of what values properties can actually take.
>
> Signed-off-by: Jonathan Cameron
> Cc: Alexandre Belloni
> Cc: Nicolas Ferre
> Cc: Ludovic Desroches
> [Alexandre Belloni: add sama5d3, remove atmel,adc-res and atmel,adc-res-names]
> Signed-off-by: Alexandre Belloni
> Reviewed-by: Rob Herring
> Reviewed-by: Ludovic Desroches
So this one is interesting from the question of what the right tag chain is.
I've signed-off on it again whilst applying but also added a note to make
it clear the two sign offs are actually for different things.
Jonathan
> ---
> .../devicetree/bindings/iio/adc/at91_adc.txt | 78
> .../bindings/iio/adc/atmel,sama9260-adc.yaml | 167 ++
> 2 files changed, 167 insertions(+), 78 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/iio/adc/at91_adc.txt
> create mode 100644
> Documentation/devicetree/bindings/iio/adc/atmel,sama9260-adc.yaml
>
> diff --git a/Documentation/devicetree/bindings/iio/adc/at91_adc.txt
> b/Documentation/devicetree/bindings/iio/adc/at91_adc.txt
> deleted file mode 100644
> index da393ac5c05f..
> --- a/Documentation/devicetree/bindings/iio/adc/at91_adc.txt
> +++ /dev/null
> @@ -1,78 +0,0 @@
> -* AT91's Analog to Digital Converter (ADC)
> -
> -Required properties:
> - - compatible: Should be "atmel,-adc"
> - can be "at91sam9260", "at91sam9g45", "at91sam9x5" or "sama5d3"
> - - reg: Should contain ADC registers location and length
> - - interrupts: Should contain the IRQ line for the ADC
> - - clock-names: tuple listing input clock names.
> - Required elements: "adc_clk", "adc_op_clk".
> - - clocks: phandles to input clocks.
> - - atmel,adc-channels-used: Bitmask of the channels muxed and enabled for
> this
> -device
> - - atmel,adc-startup-time: Startup Time of the ADC in microseconds as
> -defined in the datasheet
> - - atmel,adc-vref: Reference voltage in millivolts for the conversions
> -
> -Optional properties:
> - - atmel,adc-use-external-triggers: Boolean to enable the external triggers
> - - atmel,adc-use-res: String selecting the resolution, can be "lowres" or
> -"highres". If not specified, the highest resolution will
> -be used.
> - - atmel,adc-sleep-mode: Boolean to enable sleep mode when no conversion
> - - atmel,adc-sample-hold-time: Sample and Hold Time in microseconds
> - - atmel,adc-ts-wires: Number of touchscreen wires. Should be 4 or 5. If
> this
> -value is set, then the adc driver will enable
> touchscreen
> -support.
> -NOTE: when adc touchscreen is enabled, the adc hardware trigger will be
> - disabled. Since touchscreen will occupy the trigger register.
> - - atmel,adc-ts-pressure-threshold: a pressure threshold for touchscreen. It
> - makes touch detection more precise.
> -
> -Optional trigger Nodes:
> - - Required properties:
> -* trigger-name: Name of the trigger exposed to the user
> -* trigger-value: Value to put in the Trigger register
> - to activate this trigger
> - - Optional properties:
> -* trigger-external: Is the trigger an external trigger?
> -
> -Examples:
> -adc0: adc@fffb {
> - #address-cells = <1>;
> - #size-cells = <0>;
> - compatible = "atmel,at91sam9260-adc";
> - reg = <0xfffb 0x100>;
> - interrupts = <20 IRQ_TYPE_LEVEL_HIGH 0>;
> - clocks = <_clk>, <_op_clk>;
> - clock-names = "adc_clk", "adc_op_clk";
> - atmel,adc-channels-used = <0xff>;
> - atmel,adc-startup-time = <40>;
> - atmel,adc-use-external-triggers;
> - atmel,adc-vref = <3300>;
> - atmel,adc-res = <8 10>;
> - atmel,adc-res-names = "lowres", "highres";
> - atmel,adc-use-res = "lowres";
> -
> - trigger0 {
> - trigger-name = "external-rising";
> - trigger-value = <0x1>;
> - trigger-external;
> - };
> - trigger1 {
> - trigger-name = "external-falling";
> - trigger-value = <0x2>;
> - trigger-external;
> - };
> -
> - trigger2 {
> - trigger-name = "external-any";
> - trigger-value = <0x3>;
> - trigger-external;
> - };
> -
> - trigger3 {
> - trigger-name = "continuous";
> - trigger-value = <0x6>;
> - };
> -};
> diff --git
> a/Documentation/devicetree/bindings/iio/adc/atmel,sama9260-adc.yaml
> b/Documentation/devicetree/bindings/iio/adc/atmel,sama9260-adc.yaml
> new file mode 100644
> index ..9b0ff59e75de
> ---
Re: [BISECTED REGRESSION] Broken USB/GPIO on OMAP1 OSK
Hi, On Sun, Nov 29, 2020 at 01:51:54AM +0200, Aaro Koskinen wrote: > I tried to upgrade my OMAP1 OSK board to v5.9, but the rootfs cannot > be accessed anymore due to broken USB. It fails to probe with the > following logs: > > [9.219940] ohci ohci: cannot find GPIO chip i2c-tps65010, deferring > [9.250366] ohci ohci: cannot find GPIO chip i2c-tps65010, deferring > [9.731445] ohci ohci: cannot find GPIO chip i2c-tps65010, deferring > [ 10.342102] ohci ohci: cannot find GPIO chip i2c-tps65010, deferring > [ 10.966430] ohci ohci: cannot find GPIO chip i2c-tps65010, deferring > > Bisected to: > > commit 15d157e874437e381643c37a10922388d6e55b29 > Author: Linus Walleij > Date: Mon Jul 20 15:55:24 2020 +0200 > > usb: ohci-omap: Convert to use GPIO descriptors > > I suspect one of the issues is the name "i2c-tps65010" vs "tps65010": > > # cat > /sys/devices/platform/omap_i2c.1/i2c-1/i2c-tps65010/gpio/gpiochip208/label > tps65010 > > However changing that in the lookup table still doesn't help much; I got rid > of the "deferring" message but the USB still doesn't work. So far the only > workaround I have is to revert the whole commit. GPIO numbering goes wrong... It's now trying to poke GPIO2. Also gpiod_set_value_cansleep() probably should be used as tps65010 can sleep. A.
Re: [PATCH v2 0/1] arm64: defconfig: Enable Librem 5 hardware
Hi Pavel, On Sat, Nov 28, 2020 at 09:58:48PM +0100, Pavel Machek wrote: > Hi! > > > > > This series enables components found on Purism's Librem 5 > > > > that are available in mainline. > > > > > > > > - changes from v1 > > > > - As per review comments from Krzysztof Kozlowski > > > > > > > > https://lore.kernel.org/linux-arm-kernel/cajkoxpdewistg+cmes_wes5oz2f1qeexsus6ihenuls9sax...@mail.gmail.com/ > > > > - Squash config changes into a single commit > > > > - Add touch controller > > > > > > > > Patches are on top of Shawn's imx/defconfig > > > > > > Thanks for bringing support for your hardware to the mainline. > > > > > > Can I ask phone-de...@vger.kernel.org to be cc-ed for phone-related > > > changes? > > > > Good point. Done with v3. > > > > > How complete is the support? > > > > The components enabled should work in 5.11 (there's some LCD/DSI patches > > in flight (that's why i did not send the corresponding DT addition yet) > > and we need to submit a DT for Evergreen (imx8mq-librem5r4). > > > > https://git.sigxcpu.org/cgit/talks/2020-debconf-mobile/plain/talk.pdf > > > > is a bit outdated but has some numbers starting on page 24. > > Thanks for pointer :-). > > > > In particular, what interface do you use to configure audio routing > > > for the modem? > > > > https://salsa.debian.org/DebianOnMobile-team/callaudiod manages > > > that. > > Does kernel provide mixer interface for callaudiod to do its job? callaudiod handles selecting e.g. earpiece vs. speaker by selecting the right pulseaudio ports (it's invoked by calls (the phone call handling application via DBus) and only relies on the codec being an alsa device and hence handled by pulseaudio/alsa-ucm. Wys (https://source.puri.sm/Librem5/wys) manages the routing between the modem and codec by listening to ModemManager's state and connecting audio source and sink (again solely via pulsaudio so again just relying on modem and codec being alsa devices). Since the modem is not part of the SoC on the Librem 5 it's a completely separate device. Cheers, -- Guido > > Best regards, > > Pavel > -- > http://www.livejournal.com/~pavelmachek
[PATCH 8/8] ASoC: Intel: Skylake: Automatic DMIC format configuration according to information from NHLT
From: Mateusz Gorski
commit 2d744ecf2b98405723a2138a547e5c75009bc4e5 upstream.
Automatically choose DMIC pipeline format configuration depending on
information included in NHLT.
Change the access rights of appropriate kcontrols to read-only in order
to prevent user interference.
Signed-off-by: Mateusz Gorski
Reviewed-by: Cezary Rojewski
Reviewed-by: Pierre-Louis Bossart
Link:
https://lore.kernel.org/r/20200427132727.24942-4-mateusz.gor...@linux.intel.com
Signed-off-by: Mark Brown
Cc: # 5.4.x
---
include/uapi/sound/skl-tplg-interface.h | 1 +
sound/soc/intel/skylake/skl-topology.c | 64 +++--
2 files changed, 62 insertions(+), 3 deletions(-)
diff --git a/include/uapi/sound/skl-tplg-interface.h
b/include/uapi/sound/skl-tplg-interface.h
index f2711186c81f..a93c0decfdd5 100644
--- a/include/uapi/sound/skl-tplg-interface.h
+++ b/include/uapi/sound/skl-tplg-interface.h
@@ -19,6 +19,7 @@
#define SKL_CONTROL_TYPE_BYTE_TLV 0x100
#define SKL_CONTROL_TYPE_MIC_SELECT0x102
#define SKL_CONTROL_TYPE_MULTI_IO_SELECT 0x103
+#define SKL_CONTROL_TYPE_MULTI_IO_SELECT_DMIC 0x104
#define HDA_SST_CFG_MAX900 /* size of copier cfg*/
#define MAX_IN_QUEUE 8
diff --git a/sound/soc/intel/skylake/skl-topology.c
b/sound/soc/intel/skylake/skl-topology.c
index c9cd6d60d57b..aa5833001fde 100644
--- a/sound/soc/intel/skylake/skl-topology.c
+++ b/sound/soc/intel/skylake/skl-topology.c
@@ -1405,6 +1405,18 @@ static int skl_tplg_multi_config_set(struct snd_kcontrol
*kcontrol,
return skl_tplg_multi_config_set_get(kcontrol, ucontrol, true);
}
+static int skl_tplg_multi_config_get_dmic(struct snd_kcontrol *kcontrol,
+ struct snd_ctl_elem_value *ucontrol)
+{
+ return skl_tplg_multi_config_set_get(kcontrol, ucontrol, false);
+}
+
+static int skl_tplg_multi_config_set_dmic(struct snd_kcontrol *kcontrol,
+ struct snd_ctl_elem_value *ucontrol)
+{
+ return skl_tplg_multi_config_set_get(kcontrol, ucontrol, true);
+}
+
static int skl_tplg_tlv_control_get(struct snd_kcontrol *kcontrol,
unsigned int __user *data, unsigned int size)
{
@@ -1949,6 +1961,11 @@ static const struct snd_soc_tplg_kcontrol_ops
skl_tplg_kcontrol_ops[] = {
.get = skl_tplg_multi_config_get,
.put = skl_tplg_multi_config_set,
},
+ {
+ .id = SKL_CONTROL_TYPE_MULTI_IO_SELECT_DMIC,
+ .get = skl_tplg_multi_config_get_dmic,
+ .put = skl_tplg_multi_config_set_dmic,
+ }
};
static int skl_tplg_fill_pipe_cfg(struct device *dev,
@@ -3109,12 +3126,21 @@ static int skl_tplg_control_load(struct
snd_soc_component *cmpnt,
case SND_SOC_TPLG_CTL_ENUM:
tplg_ec = container_of(hdr,
struct snd_soc_tplg_enum_control, hdr);
- if (kctl->access & SNDRV_CTL_ELEM_ACCESS_READWRITE) {
+ if (kctl->access & SNDRV_CTL_ELEM_ACCESS_READ) {
se = (struct soc_enum *)kctl->private_value;
if (tplg_ec->priv.size)
- return skl_init_enum_data(bus->dev, se,
- tplg_ec);
+ skl_init_enum_data(bus->dev, se, tplg_ec);
}
+
+ /*
+* now that the control initializations are done, remove
+* write permission for the DMIC configuration enums to
+* avoid conflicts between NHLT settings and user interaction
+*/
+
+ if (hdr->ops.get == SKL_CONTROL_TYPE_MULTI_IO_SELECT_DMIC)
+ kctl->access = SNDRV_CTL_ELEM_ACCESS_READ;
+
break;
default:
@@ -3584,6 +3610,37 @@ static int skl_manifest_load(struct snd_soc_component
*cmpnt, int index,
return 0;
}
+static void skl_tplg_complete(struct snd_soc_component *component)
+{
+ struct snd_soc_dobj *dobj;
+ struct snd_soc_acpi_mach *mach =
+ dev_get_platdata(component->card->dev);
+ int i;
+
+ list_for_each_entry(dobj, >dobj_list, list) {
+ struct snd_kcontrol *kcontrol = dobj->control.kcontrol;
+ struct soc_enum *se =
+ (struct soc_enum *)kcontrol->private_value;
+ char **texts = dobj->control.dtexts;
+ char chan_text[4];
+
+ if (dobj->type != SND_SOC_DOBJ_ENUM ||
+ dobj->control.kcontrol->put !=
+ skl_tplg_multi_config_set_dmic)
+ continue;
+ sprintf(chan_text, "c%d", mach->mach_params.dmic_num);
+
+ for (i = 0; i < se->items; i++) {
+ struct snd_ctl_elem_value val;
+
+ if (strstr(texts[i], chan_text)) {
+
[PATCH 7/8] ASoC: Intel: Multiple I/O PCM format support for pipe
From: Mateusz Gorski
commit 1b450791d517d4dab9ab6d9a20c8819e3572 upstream.
For pipes supporting multiple input/output formats, kcontrol is
created and selection of pipe input and output configuration
is done based on control set.
If more than one configuration is supported, then this patch
allows user to select configuration of choice
using amixer settings.
Signed-off-by: Mateusz Gorski
Signed-off-by: Pavan K S
Reviewed-by: Cezary Rojewski
Reviewed-by: Pierre-Louis Bossart
Link:
https://lore.kernel.org/r/20200427132727.24942-3-mateusz.gor...@linux.intel.com
Signed-off-by: Mark Brown
Cc: # 5.4.x
---
include/uapi/sound/skl-tplg-interface.h | 1 +
sound/soc/intel/skylake/skl-topology.c | 95 +
sound/soc/intel/skylake/skl-topology.h | 1 +
3 files changed, 97 insertions(+)
diff --git a/include/uapi/sound/skl-tplg-interface.h
b/include/uapi/sound/skl-tplg-interface.h
index 9eee32f5e407..f2711186c81f 100644
--- a/include/uapi/sound/skl-tplg-interface.h
+++ b/include/uapi/sound/skl-tplg-interface.h
@@ -18,6 +18,7 @@
*/
#define SKL_CONTROL_TYPE_BYTE_TLV 0x100
#define SKL_CONTROL_TYPE_MIC_SELECT0x102
+#define SKL_CONTROL_TYPE_MULTI_IO_SELECT 0x103
#define HDA_SST_CFG_MAX900 /* size of copier cfg*/
#define MAX_IN_QUEUE 8
diff --git a/sound/soc/intel/skylake/skl-topology.c
b/sound/soc/intel/skylake/skl-topology.c
index 4b114ece58c6..c9cd6d60d57b 100644
--- a/sound/soc/intel/skylake/skl-topology.c
+++ b/sound/soc/intel/skylake/skl-topology.c
@@ -579,6 +579,38 @@ static int skl_tplg_unload_pipe_modules(struct skl_dev
*skl,
return ret;
}
+static bool skl_tplg_is_multi_fmt(struct skl_dev *skl, struct skl_pipe *pipe)
+{
+ struct skl_pipe_fmt *cur_fmt;
+ struct skl_pipe_fmt *next_fmt;
+ int i;
+
+ if (pipe->nr_cfgs <= 1)
+ return false;
+
+ if (pipe->conn_type != SKL_PIPE_CONN_TYPE_FE)
+ return true;
+
+ for (i = 0; i < pipe->nr_cfgs - 1; i++) {
+ if (pipe->direction == SNDRV_PCM_STREAM_PLAYBACK) {
+ cur_fmt = >configs[i].out_fmt;
+ next_fmt = >configs[i + 1].out_fmt;
+ } else {
+ cur_fmt = >configs[i].in_fmt;
+ next_fmt = >configs[i + 1].in_fmt;
+ }
+
+ if (!CHECK_HW_PARAMS(cur_fmt->channels, cur_fmt->freq,
+cur_fmt->bps,
+next_fmt->channels,
+next_fmt->freq,
+next_fmt->bps))
+ return true;
+ }
+
+ return false;
+}
+
/*
* Here, we select pipe format based on the pipe type and pipe
* direction to determine the current config index for the pipeline.
@@ -601,6 +633,14 @@ skl_tplg_get_pipe_config(struct skl_dev *skl, struct
skl_module_cfg *mconfig)
return 0;
}
+ if (skl_tplg_is_multi_fmt(skl, pipe)) {
+ pipe->cur_config_idx = pipe->pipe_config_idx;
+ pipe->memory_pages = pconfig->mem_pages;
+ dev_dbg(skl->dev, "found pipe config idx:%d\n",
+ pipe->cur_config_idx);
+ return 0;
+ }
+
if (pipe->conn_type == SKL_PIPE_CONN_TYPE_NONE) {
dev_dbg(skl->dev, "No conn_type detected, take 0th config\n");
pipe->cur_config_idx = 0;
@@ -1315,6 +1355,56 @@ static int skl_tplg_pga_event(struct snd_soc_dapm_widget
*w,
return 0;
}
+static int skl_tplg_multi_config_set_get(struct snd_kcontrol *kcontrol,
+struct snd_ctl_elem_value *ucontrol,
+bool is_set)
+{
+ struct snd_soc_component *component =
+ snd_soc_kcontrol_component(kcontrol);
+ struct hdac_bus *bus = snd_soc_component_get_drvdata(component);
+ struct skl_dev *skl = bus_to_skl(bus);
+ struct skl_pipeline *ppl;
+ struct skl_pipe *pipe = NULL;
+ struct soc_enum *ec = (struct soc_enum *)kcontrol->private_value;
+ u32 *pipe_id;
+
+ if (!ec)
+ return -EINVAL;
+
+ if (is_set && ucontrol->value.enumerated.item[0] > ec->items)
+ return -EINVAL;
+
+ pipe_id = ec->dobj.private;
+
+ list_for_each_entry(ppl, >ppl_list, node) {
+ if (ppl->pipe->ppl_id == *pipe_id) {
+ pipe = ppl->pipe;
+ break;
+ }
+ }
+ if (!pipe)
+ return -EIO;
+
+ if (is_set)
+ pipe->pipe_config_idx = ucontrol->value.enumerated.item[0];
+ else
+ ucontrol->value.enumerated.item[0] = pipe->pipe_config_idx;
+
+ return 0;
+}
+
+static int skl_tplg_multi_config_get(struct snd_kcontrol *kcontrol,
+struct snd_ctl_elem_value *ucontrol)
[PATCH 5/8] ASoC: Intel: Allow for ROM init retry on CNL platforms
commit 024aa45f55ccd40704cfdef61b2a8b6d0de9cdd1 upstream.
Due to unconditional initial timeouts, firmware may fail to load during
its initialization. This issue cannot be resolved on driver side as it
is caused by external sources such as CSME but has to be accounted for
nonetheless.
Fixes: cb6a55284629 ("ASoC: Intel: cnl: Add sst library functions for cnl
platform")
Signed-off-by: Cezary Rojewski
Reviewed-by: Pierre-Louis Bossart
Link: https://lore.kernel.org/r/20200305145314.32579-7-cezary.rojew...@intel.com
Signed-off-by: Mark Brown
Cc: # 5.4.x
---
sound/soc/intel/skylake/bxt-sst.c | 2 --
sound/soc/intel/skylake/cnl-sst.c | 15 ++-
sound/soc/intel/skylake/skl-sst-dsp.h | 1 +
3 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/sound/soc/intel/skylake/bxt-sst.c
b/sound/soc/intel/skylake/bxt-sst.c
index 92a82e6b5fe6..cdafade8abd6 100644
--- a/sound/soc/intel/skylake/bxt-sst.c
+++ b/sound/soc/intel/skylake/bxt-sst.c
@@ -38,8 +38,6 @@
/* Delay before scheduling D0i3 entry */
#define BXT_D0I3_DELAY 5000
-#define BXT_FW_ROM_INIT_RETRY 3
-
static unsigned int bxt_get_errorcode(struct sst_dsp *ctx)
{
return sst_dsp_shim_read(ctx, BXT_ADSP_ERROR_CODE);
diff --git a/sound/soc/intel/skylake/cnl-sst.c
b/sound/soc/intel/skylake/cnl-sst.c
index 4f64f097e9ae..060e47ae3391 100644
--- a/sound/soc/intel/skylake/cnl-sst.c
+++ b/sound/soc/intel/skylake/cnl-sst.c
@@ -109,7 +109,7 @@ static int cnl_load_base_firmware(struct sst_dsp *ctx)
{
struct firmware stripped_fw;
struct skl_dev *cnl = ctx->thread_context;
- int ret;
+ int ret, i;
if (!ctx->fw) {
ret = request_firmware(>fw, ctx->fw_name, ctx->dev);
@@ -131,12 +131,16 @@ static int cnl_load_base_firmware(struct sst_dsp *ctx)
stripped_fw.size = ctx->fw->size;
skl_dsp_strip_extended_manifest(_fw);
- ret = cnl_prepare_fw(ctx, stripped_fw.data, stripped_fw.size);
- if (ret < 0) {
- dev_err(ctx->dev, "prepare firmware failed: %d\n", ret);
- goto cnl_load_base_firmware_failed;
+ for (i = 0; i < BXT_FW_ROM_INIT_RETRY; i++) {
+ ret = cnl_prepare_fw(ctx, stripped_fw.data, stripped_fw.size);
+ if (!ret)
+ break;
+ dev_dbg(ctx->dev, "prepare firmware failed: %d\n", ret);
}
+ if (ret < 0)
+ goto cnl_load_base_firmware_failed;
+
ret = sst_transfer_fw_host_dma(ctx);
if (ret < 0) {
dev_err(ctx->dev, "transfer firmware failed: %d\n", ret);
@@ -158,6 +162,7 @@ static int cnl_load_base_firmware(struct sst_dsp *ctx)
return 0;
cnl_load_base_firmware_failed:
+ dev_err(ctx->dev, "firmware load failed: %d\n", ret);
release_firmware(ctx->fw);
ctx->fw = NULL;
diff --git a/sound/soc/intel/skylake/skl-sst-dsp.h
b/sound/soc/intel/skylake/skl-sst-dsp.h
index cdfec0fca577..067d1ea11cde 100644
--- a/sound/soc/intel/skylake/skl-sst-dsp.h
+++ b/sound/soc/intel/skylake/skl-sst-dsp.h
@@ -67,6 +67,7 @@ struct skl_dev;
#define SKL_FW_INIT0x1
#define SKL_FW_RFW_START 0xf
+#define BXT_FW_ROM_INIT_RETRY 3
#define SKL_ADSPIC_IPC 1
#define SKL_ADSPIS_IPC 1
--
2.17.1
[PATCH 6/8] ASoC: Intel: Skylake: Await purge request ack on CNL
commit 7693cadac86548b30389a6e11d78c38db654f393 upstream.
Each purge request is sent by driver after master core is powered up and
unresetted but before it is unstalled. On unstall, ROM begins processing
the request and initializing environment for FW load. Host should await
ROM's ack before moving forward. Without doing so, ROM init poll may
start too early and false timeouts can occur.
Fixes: cb6a55284629 ("ASoC: Intel: cnl: Add sst library functions for cnl
platform")
Signed-off-by: Cezary Rojewski
Reviewed-by: Pierre-Louis Bossart
Link: https://lore.kernel.org/r/20200305145314.32579-8-cezary.rojew...@intel.com
Signed-off-by: Mark Brown
Cc: # 5.4.x
---
sound/soc/intel/skylake/bxt-sst.c | 1 -
sound/soc/intel/skylake/cnl-sst.c | 20 ++--
sound/soc/intel/skylake/skl-sst-dsp.h | 1 +
3 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/sound/soc/intel/skylake/bxt-sst.c
b/sound/soc/intel/skylake/bxt-sst.c
index cdafade8abd6..38b9d7494083 100644
--- a/sound/soc/intel/skylake/bxt-sst.c
+++ b/sound/soc/intel/skylake/bxt-sst.c
@@ -17,7 +17,6 @@
#include "skl.h"
#define BXT_BASEFW_TIMEOUT 3000
-#define BXT_INIT_TIMEOUT 300
#define BXT_ROM_INIT_TIMEOUT 70
#define BXT_IPC_PURGE_FW 0x01004000
diff --git a/sound/soc/intel/skylake/cnl-sst.c
b/sound/soc/intel/skylake/cnl-sst.c
index 060e47ae3391..c6abcd5aa67b 100644
--- a/sound/soc/intel/skylake/cnl-sst.c
+++ b/sound/soc/intel/skylake/cnl-sst.c
@@ -57,18 +57,34 @@ static int cnl_prepare_fw(struct sst_dsp *ctx, const void
*fwdata, u32 fwsize)
ctx->dsp_ops.stream_tag = stream_tag;
memcpy(ctx->dmab.area, fwdata, fwsize);
+ ret = skl_dsp_core_power_up(ctx, SKL_DSP_CORE0_MASK);
+ if (ret < 0) {
+ dev_err(ctx->dev, "dsp core0 power up failed\n");
+ ret = -EIO;
+ goto base_fw_load_failed;
+ }
+
/* purge FW request */
sst_dsp_shim_write(ctx, CNL_ADSP_REG_HIPCIDR,
CNL_ADSP_REG_HIPCIDR_BUSY | (CNL_IPC_PURGE |
((stream_tag - 1) << CNL_ROM_CTRL_DMA_ID)));
- ret = cnl_dsp_enable_core(ctx, SKL_DSP_CORE0_MASK);
+ ret = skl_dsp_start_core(ctx, SKL_DSP_CORE0_MASK);
if (ret < 0) {
- dev_err(ctx->dev, "dsp boot core failed ret: %d\n", ret);
+ dev_err(ctx->dev, "Start dsp core failed ret: %d\n", ret);
ret = -EIO;
goto base_fw_load_failed;
}
+ ret = sst_dsp_register_poll(ctx, CNL_ADSP_REG_HIPCIDA,
+ CNL_ADSP_REG_HIPCIDA_DONE,
+ CNL_ADSP_REG_HIPCIDA_DONE,
+ BXT_INIT_TIMEOUT, "HIPCIDA Done");
+ if (ret < 0) {
+ dev_err(ctx->dev, "timeout for purge request: %d\n", ret);
+ goto base_fw_load_failed;
+ }
+
/* enable interrupt */
cnl_ipc_int_enable(ctx);
cnl_ipc_op_int_enable(ctx);
diff --git a/sound/soc/intel/skylake/skl-sst-dsp.h
b/sound/soc/intel/skylake/skl-sst-dsp.h
index 067d1ea11cde..1df9ef422f61 100644
--- a/sound/soc/intel/skylake/skl-sst-dsp.h
+++ b/sound/soc/intel/skylake/skl-sst-dsp.h
@@ -68,6 +68,7 @@ struct skl_dev;
#define SKL_FW_INIT0x1
#define SKL_FW_RFW_START 0xf
#define BXT_FW_ROM_INIT_RETRY 3
+#define BXT_INIT_TIMEOUT 300
#define SKL_ADSPIC_IPC 1
#define SKL_ADSPIS_IPC 1
--
2.17.1
[PATCH 3/8] ASoC: Intel: Skylake: Enable codec wakeup during chip init
commit e603f11d5df8997d104ab405ff27640b90baffaa upstream. Follow the recommendation set by hda_intel.c and enable HDMI/DP codec wakeup during bus initialization procedure. Disable wakeup once init completes. Signed-off-by: Cezary Rojewski Reviewed-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20200305145314.32579-4-cezary.rojew...@intel.com Signed-off-by: Mark Brown Cc: # 5.4.x --- sound/soc/intel/skylake/skl.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/sound/soc/intel/skylake/skl.c b/sound/soc/intel/skylake/skl.c index f46b90ccb46f..1a3a3d6a3141 100644 --- a/sound/soc/intel/skylake/skl.c +++ b/sound/soc/intel/skylake/skl.c @@ -129,6 +129,7 @@ static int skl_init_chip(struct hdac_bus *bus, bool full_reset) struct hdac_ext_link *hlink; int ret; + snd_hdac_set_codec_wakeup(bus, true); skl_enable_miscbdcge(bus->dev, false); ret = snd_hdac_bus_init_chip(bus, full_reset); @@ -137,6 +138,7 @@ static int skl_init_chip(struct hdac_bus *bus, bool full_reset) writel(0, hlink->ml_addr + AZX_REG_ML_LOSIDV); skl_enable_miscbdcge(bus->dev, true); + snd_hdac_set_codec_wakeup(bus, false); return ret; } -- 2.17.1
[PATCH 4/8] ASoC: Intel: Skylake: Shield against no-NHLT configurations
commit 9e6c382f5a6161eb55115fb56614b9827f2e7da3 upstream.
Some configurations expose no NHLT table at all within their
/sys/firmware/acpi/tables. To prevent NULL-dereference errors from
occurring, adjust probe flow and append additional safety checks in
functions involved in NHLT lifecycle.
Signed-off-by: Cezary Rojewski
Reviewed-by: Pierre-Louis Bossart
Link: https://lore.kernel.org/r/20200305145314.32579-5-cezary.rojew...@intel.com
Signed-off-by: Mark Brown
Cc: # 5.4.x
---
sound/soc/intel/skylake/skl-nhlt.c | 3 ++-
sound/soc/intel/skylake/skl.c | 9 +++--
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/sound/soc/intel/skylake/skl-nhlt.c
b/sound/soc/intel/skylake/skl-nhlt.c
index 19f328d71f24..d9c8f5cb389e 100644
--- a/sound/soc/intel/skylake/skl-nhlt.c
+++ b/sound/soc/intel/skylake/skl-nhlt.c
@@ -182,7 +182,8 @@ void skl_nhlt_remove_sysfs(struct skl_dev *skl)
{
struct device *dev = >pci->dev;
- sysfs_remove_file(>kobj, _attr_platform_id.attr);
+ if (skl->nhlt)
+ sysfs_remove_file(>kobj, _attr_platform_id.attr);
}
/*
diff --git a/sound/soc/intel/skylake/skl.c b/sound/soc/intel/skylake/skl.c
index 1a3a3d6a3141..2e5fbd220923 100644
--- a/sound/soc/intel/skylake/skl.c
+++ b/sound/soc/intel/skylake/skl.c
@@ -632,6 +632,9 @@ static int skl_clock_device_register(struct skl_dev *skl)
struct platform_device_info pdevinfo = {NULL};
struct skl_clk_pdata *clk_pdata;
+ if (!skl->nhlt)
+ return 0;
+
clk_pdata = devm_kzalloc(>pci->dev, sizeof(*clk_pdata),
GFP_KERNEL);
if (!clk_pdata)
@@ -1090,7 +1093,8 @@ static int skl_probe(struct pci_dev *pci,
out_clk_free:
skl_clock_device_unregister(skl);
out_nhlt_free:
- intel_nhlt_free(skl->nhlt);
+ if (skl->nhlt)
+ intel_nhlt_free(skl->nhlt);
out_free:
skl_free(bus);
@@ -1139,7 +1143,8 @@ static void skl_remove(struct pci_dev *pci)
skl_dmic_device_unregister(skl);
skl_clock_device_unregister(skl);
skl_nhlt_remove_sysfs(skl);
- intel_nhlt_free(skl->nhlt);
+ if (skl->nhlt)
+ intel_nhlt_free(skl->nhlt);
skl_free(bus);
dev_set_drvdata(>dev, NULL);
}
--
2.17.1
[PATCH 0/8] ASoC: Intel: Skylake: Fix HDAudio and DMIC for v5.4
First six of the backport address numerous problems troubling HDAudio configuration users for Skylake driver. Upstream series: "ASoC: Intel: Skylake: Fix HDaudio and Dmic" [1] provides the explanation and reasoning behind it. These have been initialy pushed into v5.7-rc1 via: "sound updates for 5.7-rc1" [2] by Takashi. Last two patches are from: "Add support for different DMIC configurations" [3] which focuses on HDAudio with DMIC configuration. Patch: "ASoC: Intel: Skylake: Add alternative topology binary name" of the mentioned series has already been merged to v5.4.y -stable and thus it's not included here. Fixes target mainly Skylake and Kabylake based platforms, released in 2015-2016 period. [1]: https://lore.kernel.org/alsa-devel/20200305145314.32579-1-cezary.rojew...@intel.com/ [2]: https://lore.kernel.org/lkml/s5htv22uso8.wl-ti...@suse.de/ [3]: https://lore.kernel.org/alsa-devel/20200427132727.24942-1-mateusz.gor...@linux.intel.com/ Cezary Rojewski (6): ASoC: Intel: Skylake: Remove superfluous chip initialization ASoC: Intel: Skylake: Select hda configuration permissively ASoC: Intel: Skylake: Enable codec wakeup during chip init ASoC: Intel: Skylake: Shield against no-NHLT configurations ASoC: Intel: Allow for ROM init retry on CNL platforms ASoC: Intel: Skylake: Await purge request ack on CNL Mateusz Gorski (2): ASoC: Intel: Multiple I/O PCM format support for pipe ASoC: Intel: Skylake: Automatic DMIC format configuration according to information from NHLT include/uapi/sound/skl-tplg-interface.h | 2 + sound/soc/intel/skylake/bxt-sst.c | 3 - sound/soc/intel/skylake/cnl-sst.c | 35 -- sound/soc/intel/skylake/skl-nhlt.c | 3 +- sound/soc/intel/skylake/skl-sst-dsp.h | 2 + sound/soc/intel/skylake/skl-topology.c | 159 +++- sound/soc/intel/skylake/skl-topology.h | 1 + sound/soc/intel/skylake/skl.c | 29 ++--- 8 files changed, 204 insertions(+), 30 deletions(-) -- 2.17.1
[PATCH 2/8] ASoC: Intel: Skylake: Select hda configuration permissively
commit a66f88394a78fec9a05fa6e517e9603e8eca8363 upstream.
With _reset_link removed from the probe sequence, codec_mask at the time
skl_find_hda_machine() is invoked will always be 0, so hda machine will
never be chosen. Rather than reorganizing boot flow, be permissive about
invalid mask. codec_mask will be set to proper value during probe_work -
before skl_codec_create() ever gets called.
Signed-off-by: Cezary Rojewski
Reviewed-by: Pierre-Louis Bossart
Link: https://lore.kernel.org/r/20200305145314.32579-3-cezary.rojew...@intel.com
Signed-off-by: Mark Brown
Cc: # 5.4.x
---
sound/soc/intel/skylake/skl.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/sound/soc/intel/skylake/skl.c b/sound/soc/intel/skylake/skl.c
index 861c07417fed..f46b90ccb46f 100644
--- a/sound/soc/intel/skylake/skl.c
+++ b/sound/soc/intel/skylake/skl.c
@@ -480,13 +480,8 @@ static struct skl_ssp_clk skl_ssp_clks[] = {
static struct snd_soc_acpi_mach *skl_find_hda_machine(struct skl_dev *skl,
struct snd_soc_acpi_mach *machines)
{
- struct hdac_bus *bus = skl_to_bus(skl);
struct snd_soc_acpi_mach *mach;
- /* check if we have any codecs detected on bus */
- if (bus->codec_mask == 0)
- return NULL;
-
/* point to common table */
mach = snd_soc_acpi_intel_hda_machines;
--
2.17.1
[PATCH 1/8] ASoC: Intel: Skylake: Remove superfluous chip initialization
commit 2ef81057d80456870b97890dd79c8f56a85b1242 upstream.
Skylake driver does the controller init operation twice:
- first during probe (only to stop it just before scheduling probe_work)
- and during said probe_work where the actual correct sequence is
executed
To properly complete boot sequence when iDisp codec is present, bus
initialization has to be called only after _i915_init() finishes.
With additional _reset_list preceding _i915_init(), iDisp codec never
gets the chance to enumerate on the link. Remove the superfluous
initialization to address the issue.
Signed-off-by: Cezary Rojewski
Reviewed-by: Pierre-Louis Bossart
Link: https://lore.kernel.org/r/20200305145314.32579-2-cezary.rojew...@intel.com
Signed-off-by: Mark Brown
Cc: # 5.4.x
---
sound/soc/intel/skylake/skl.c | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/sound/soc/intel/skylake/skl.c b/sound/soc/intel/skylake/skl.c
index 141dbbf975ac..861c07417fed 100644
--- a/sound/soc/intel/skylake/skl.c
+++ b/sound/soc/intel/skylake/skl.c
@@ -807,6 +807,9 @@ static void skl_probe_work(struct work_struct *work)
return;
}
+ skl_init_pci(skl);
+ skl_dum_set(bus);
+
err = skl_init_chip(bus, true);
if (err < 0) {
dev_err(bus->dev, "Init chip failed with err: %d\n", err);
@@ -922,8 +925,6 @@ static int skl_first_init(struct hdac_bus *bus)
return -ENXIO;
}
- snd_hdac_bus_reset_link(bus, true);
-
snd_hdac_bus_parse_capabilities(bus);
/* check if PPCAP exists */
@@ -971,11 +972,7 @@ static int skl_first_init(struct hdac_bus *bus)
if (err < 0)
return err;
- /* initialize chip */
- skl_init_pci(skl);
- skl_dum_set(bus);
-
- return skl_init_chip(bus, true);
+ return 0;
}
static int skl_probe(struct pci_dev *pci,
@@ -1080,8 +1077,6 @@ static int skl_probe(struct pci_dev *pci,
if (bus->mlcap)
snd_hdac_ext_bus_get_ml_capabilities(bus);
- snd_hdac_bus_stop_chip(bus);
-
/* create device for soc dmic */
err = skl_dmic_device_register(skl);
if (err < 0) {
--
2.17.1
Re: scheduling while atomic in z3fold
On Sun, 2020-11-29 at 12:29 +0100, Oleksandr Natalenko wrote: > > Ummm so do compressors explode under non-rt kernel in your tests as > well, or it is just -rt that triggers this? I only tested a non-rt kernel with z3fold, which worked just fine. -Mike
Re: [PATCH] tpm_tis: Disable interrupts on ThinkPad T490s
Hi All,
On 11/29/20 4:23 AM, Jarkko Sakkinen wrote:
> On Tue, Nov 24, 2020 at 10:45:01PM +0100, Hans de Goede wrote:
>> Hi,
>>
>> On 11/24/20 6:52 PM, Jerry Snitselaar wrote:
>>>
>>> Jarkko Sakkinen @ 2020-11-23 20:26 MST:
>>>
On Wed, Nov 18, 2020 at 11:36:20PM -0700, Jerry Snitselaar wrote:
>
> Matthew Garrett @ 2020-10-15 15:39 MST:
>
>> On Thu, Oct 15, 2020 at 2:44 PM Jerry Snitselaar
>> wrote:
>>>
>>> There is a misconfiguration in the bios of the gpio pin used for the
>>> interrupt in the T490s. When interrupts are enabled in the tpm_tis
>>> driver code this results in an interrupt storm. This was initially
>>> reported when we attempted to enable the interrupt code in the tpm_tis
>>> driver, which previously wasn't setting a flag to enable it. Due to
>>> the reports of the interrupt storm that code was reverted and we went
>>> back
>>> to polling instead of using interrupts. Now that we know the T490s
>>> problem
>>> is a firmware issue, add code to check if the system is a T490s and
>>> disable interrupts if that is the case. This will allow us to enable
>>> interrupts for everyone else. If the user has a fixed bios they can
>>> force the enabling of interrupts with tpm_tis.interrupts=1 on the
>>> kernel command line.
>>
>> I think an implication of this is that systems haven't been
>> well-tested with interrupts enabled. In general when we've found a
>> firmware issue in one place it ends up happening elsewhere as well, so
>> it wouldn't surprise me if there are other machines that will also be
>> unhappy with interrupts enabled. Would it be possible to automatically
>> detect this case (eg, if we get more than a certain number of
>> interrupts in a certain timeframe immediately after enabling the
>> interrupt) and automatically fall back to polling in that case? It
>> would also mean that users with fixed firmware wouldn't need to pass a
>> parameter.
>
> I believe Matthew is correct here. I found another system today
> with completely different vendor for both the system and the tpm chip.
> In addition another Lenovo model, the L490, has the issue.
>
> This initial attempt at a solution like Matthew suggested works on
> the system I found today, but I imagine it is all sorts of wrong.
> In the 2 systems where I've seen it, there are about 10 interrupts
> in around 1.5 seconds, and then the irq code shuts down the interrupt
> because they aren't being handled.
>
>
> diff --git a/drivers/char/tpm/tpm_tis_core.c
> b/drivers/char/tpm/tpm_tis_core.c
> index 49ae09ac604f..478e9d02a3fa 100644
> --- a/drivers/char/tpm/tpm_tis_core.c
> +++ b/drivers/char/tpm/tpm_tis_core.c
> @@ -27,6 +27,11 @@
> #include "tpm.h"
> #include "tpm_tis_core.h"
>
> +static unsigned int time_start = 0;
> +static bool storm_check = true;
> +static bool storm_killed = false;
> +static u32 irqs_fired = 0;
Maybe kstat_irqs() would be a better idea than ad hoc stats.
>>>
>>> Thanks, yes that would be better.
>>>
> +
> static void tpm_tis_clkrun_enable(struct tpm_chip *chip, bool value);
>
> static void tpm_tis_enable_interrupt(struct tpm_chip *chip, u8 mask)
> @@ -464,25 +469,31 @@ static int tpm_tis_send_data(struct tpm_chip *chip,
> const u8 *buf, size_t len)
> return rc;
> }
>
> -static void disable_interrupts(struct tpm_chip *chip)
> +static void __disable_interrupts(struct tpm_chip *chip)
> {
> struct tpm_tis_data *priv = dev_get_drvdata(>dev);
> u32 intmask;
> int rc;
>
> - if (priv->irq == 0)
> - return;
> -
> rc = tpm_tis_read32(priv, TPM_INT_ENABLE(priv->locality),
> );
> if (rc < 0)
> intmask = 0;
>
> intmask &= ~TPM_GLOBAL_INT_ENABLE;
> rc = tpm_tis_write32(priv, TPM_INT_ENABLE(priv->locality),
> intmask);
> + chip->flags &= ~TPM_CHIP_FLAG_IRQ;
> +}
> +
> +static void disable_interrupts(struct tpm_chip *chip)
> +{
> + struct tpm_tis_data *priv = dev_get_drvdata(>dev);
>
> + if (priv->irq == 0)
> + return;
> +
> + __disable_interrupts(chip);
> devm_free_irq(chip->dev.parent, priv->irq, chip);
> priv->irq = 0;
> - chip->flags &= ~TPM_CHIP_FLAG_IRQ;
> }
>
> /*
> @@ -528,6 +539,12 @@ static int tpm_tis_send(struct tpm_chip *chip, u8
> *buf, size_t len)
> int rc, irq;
> struct tpm_tis_data *priv = dev_get_drvdata(>dev);
>
> + if (unlikely(storm_killed)) {
> + devm_free_irq(chip->dev.parent, priv->irq, chip);
> + priv->irq = 0;
> +
Re: [RFC PATCH 2/3] net: sparx5: Add Sparx5 switchdev driver
On Sun, Nov 29, 2020 at 10:52:45AM +, Russell King - ARM Linux admin wrote: > There are other issues too. This is also wrong: + if (port->ndev && port->ndev->phydev) + status->link = port->ndev->phydev->link; phylink already deals with that situation. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
Re: scheduling while atomic in z3fold
On Sun, Nov 29, 2020 at 11:56:55AM +0100, Mike Galbraith wrote: > On Sun, 2020-11-29 at 10:21 +0100, Mike Galbraith wrote: > > On Sun, 2020-11-29 at 08:48 +0100, Mike Galbraith wrote: > > > On Sun, 2020-11-29 at 07:41 +0100, Mike Galbraith wrote: > > > > On Sat, 2020-11-28 at 15:27 +0100, Oleksandr Natalenko wrote: > > > > > > > > > > > > Shouldn't the list manipulation be protected with > > > > > > > local_lock+this_cpu_ptr instead of get_cpu_ptr+spin_lock? > > > > > > > > > > Totally untested: > > > > > > > > Hrm, the thing doesn't seem to care deeply about preemption being > > > > disabled, so adding another lock may be overkill. It looks like you > > > > could get the job done via migrate_disable()+this_cpu_ptr(). > > > > > > There is however an ever so tiny chance that I'm wrong about that :) > > > > Or not, your local_lock+this_cpu_ptr version exploded too. > > > > Perhaps there's a bit of non-rt related racy racy going on in zswap > > thingy that makes swap an even less wonderful idea for RT than usual. > > Raciness seems to be restricted to pool compressor. "zbud" seems to be > solid, virgin "zsmalloc" explodes, as does "z3fold" regardless which of > us puts his grubby fingerprints on it. > > Exploding compressors survived zero runs of runltp -f mm, I declared > zbud to be at least kinda sorta stable after box survived five runs. Ummm so do compressors explode under non-rt kernel in your tests as well, or it is just -rt that triggers this? I've never seen that on both -rt and non-rt, thus asking. -- Oleksandr Natalenko (post-factum)
Re: [RFC PATCH 2/3] net: sparx5: Add Sparx5 switchdev driver
On Sun, Nov 29, 2020 at 10:52:45AM +, Russell King - ARM Linux admin wrote:
> On Sat, Nov 28, 2020 at 10:28:28PM +, Russell King - ARM Linux admin
> wrote:
> > On Sat, Nov 28, 2020 at 08:06:16PM +0100, Andrew Lunn wrote:
> > > > +static void sparx5_phylink_mac_config(struct phylink_config *config,
> > > > + unsigned int mode,
> > > > + const struct phylink_link_state
> > > > *state)
> > > > +{
> > > > + struct sparx5_port *port = netdev_priv(to_net_dev(config->dev));
> > > > + struct sparx5_port_config conf;
> > > > + int err = 0;
> > > > +
> > > > + conf = port->conf;
> > > > + conf.autoneg = state->an_enabled;
> > > > + conf.pause = state->pause;
> > > > + conf.duplex = state->duplex;
> > > > + conf.power_down = false;
> > > > + conf.portmode = state->interface;
> > > > +
> > > > + if (state->speed == SPEED_UNKNOWN) {
> > > > + /* When a SFP is plugged in we use capabilities to
> > > > +* default to the highest supported speed
> > > > +*/
> > >
> > > This looks suspicious.
> >
> > Yes, it looks highly suspicious. The fact that
> > sparx5_phylink_mac_link_up() is empty, and sparx5_phylink_mac_config()
> > does all the work suggests that this was developed before the phylink
> > re-organisation, and this code hasn't been updated for it.
> >
> > Any new code for the kernel really ought to be updated for the new
> > phylink methodology before it is accepted.
> >
> > Looking at sparx5_port_config(), it also seems to use
> > PHY_INTERFACE_MODE_1000BASEX for both 1000BASE-X and 2500BASE-X. All
> > very well for the driver to do that internally, but it's confusing
> > when it comes to reviewing this stuff, especially when people outside
> > of the driver (such as myself) reviewing it need to understand what's
> > going on with the configuration.
>
> There are other issues too.
>
> Looking at sparx5_get_1000basex_status(), we have:
>
> + status->link = DEV2G5_PCS1G_LINK_STATUS_LINK_STATUS_GET(value) |
> + DEV2G5_PCS1G_LINK_STATUS_SYNC_STATUS_GET(value);
>
> Why is the link status the logical OR of these?
>
> + if ((lp_abil >> 8) & 1) /* symmetric pause */
> + status->pause = MLO_PAUSE_RX | MLO_PAUSE_TX;
> + if (lp_abil & (1 << 7)) /* asymmetric pause */
> + status->pause |= MLO_PAUSE_RX;
>
> is actually wrong, and I see I need to improve the documentation for
> mac_pcs_get_state(). The intention in the documentation was concerning
> hardware that indicated the _resolved_ status of pause modes. It was
> not intended that drivers resolve the pause modes themselves.
>
> Even so, the above is still wrong; it takes no account of what is being
> advertised at the local end. If one looks at the implementation in
> phylink_decode_c37_word(), one will notice there is code to deal with
> this.
>
> I think we ought to make phylink_decode_c37_word() and
> phylink_decode_sgmii_word() public functions, and then this driver can
> use these helpers to decode the link partner advertisement to the
> phylink state.
>
> Does the driver need to provide an ethtool .get_link function? That
> seems to bypass phylink. Why can't ethtool_op_get_link() be used?
>
> I think if ethtool_op_get_link() is used, we then have just one caller
> for sparx5_get_port_status(), which means "struct sparx5_port_status"
> can be eliminated and the code cleaned up to use the phylink decoding
> helpers.
(Sorry, I keep spotting bits in the code - it's really not an easy
chunk of code to review.)
I'm also not sure that this is really correct:
+ status->serdes_link = !phy_validate(port->serdes, PHY_MODE_ETHERNET,
+ port->conf.portmode, NULL);
The documentation for phy_validate() says:
* Used to check that the current set of parameters can be handled by
* the phy. Implementations are free to tune the parameters passed as
* arguments if needed by some implementation detail or
* constraints. It will not change any actual configuration of the
* PHY, so calling it as many times as deemed fit will have no side
* effect.
and clearly, passing NULL for opts, gives the function no opportunity
to do what it's intended, so phy_validate() is being used for some
other purpose than that which the drivers/phy subsystem intends it to
be used for.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
Re: [PATCH v5] arm64: dts: marvell: add DT for ESPRESSObin-Ultra
Hi Vladimir,
> This adds support for ESPRESSObin-Ultra from Globalscale.
>
> Specifications are similar to the base ESPRESSObin board, with main
> difference being being WAN port with PoE capability and 2 additional ethernet
> ports.
>
> Full specifications:
>
> 1x Marvell 64 bit Dual Core ARM A53 Armada 3700 SOC clocked up to 1.2Ghz
> 1x Topaz 6341 Networking Switch
> 1GB DDR4
> 8GB eMMC
> 1x WAN with 30W POE
> 4x Gb LAN
> 1x RTC Clock and battery
> 1x DC Jack
> 1x USB 3.0 Type A
> 1x USB 2.0 Type A
> 1x SIM NanoSIM card Slot
> 1x Power Button
> 4x LED
> 1x Reset button
> 1x microUSB for UART
> 1x M.2 2280 slot for memory
> 1x 2x2 802.11ac Wi-Fi
> 1x MiniPCIE slot for Wi-Fi (PCIe interface)
>
> Signed-off-by: Vladimir Vid
Applied on mvebu/dt64
I know that usb3 node is not yet enabled but we are a really close to the
end of the merge window for ARM so let's have this version in 5.11, and
then we can improve it in future version.
Thanks,
Gregory
> ---
>
> v5 changes:
> - update ethernet-phy@1 to match reg value
>
> ---
> arch/arm64/boot/dts/marvell/Makefile | 1 +
> .../marvell/armada-3720-espressobin-ultra.dts | 165 ++
> 2 files changed, 166 insertions(+)
> create mode 100644
> arch/arm64/boot/dts/marvell/armada-3720-espressobin-ultra.dts
>
> diff --git a/arch/arm64/boot/dts/marvell/Makefile
> b/arch/arm64/boot/dts/marvell/Makefile
> index 3e5f2e7a040c..094f451fdd1d 100644
> --- a/arch/arm64/boot/dts/marvell/Makefile
> +++ b/arch/arm64/boot/dts/marvell/Makefile
> @@ -3,6 +3,7 @@
> dtb-$(CONFIG_ARCH_MVEBU) += armada-3720-db.dtb
> dtb-$(CONFIG_ARCH_MVEBU) += armada-3720-espressobin.dtb
> dtb-$(CONFIG_ARCH_MVEBU) += armada-3720-espressobin-emmc.dtb
> +dtb-$(CONFIG_ARCH_MVEBU) += armada-3720-espressobin-ultra.dtb
> dtb-$(CONFIG_ARCH_MVEBU) += armada-3720-espressobin-v7.dtb
> dtb-$(CONFIG_ARCH_MVEBU) += armada-3720-espressobin-v7-emmc.dtb
> dtb-$(CONFIG_ARCH_MVEBU) += armada-3720-turris-mox.dtb
> diff --git a/arch/arm64/boot/dts/marvell/armada-3720-espressobin-ultra.dts
> b/arch/arm64/boot/dts/marvell/armada-3720-espressobin-ultra.dts
> new file mode 100644
> index ..c5eb3604dd5b
> --- /dev/null
> +++ b/arch/arm64/boot/dts/marvell/armada-3720-espressobin-ultra.dts
> @@ -0,0 +1,165 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Device Tree file for ESPRESSObin-Ultra board.
> + * Copyright (C) 2019 Globalscale technologies, Inc.
> + *
> + * Jason Hung
> + */
> +
> +/dts-v1/;
> +
> +#include "armada-3720-espressobin.dtsi"
> +
> +/ {
> + model = "Globalscale Marvell ESPRESSOBin Ultra Board";
> + compatible = "globalscale,espressobin-ultra", "marvell,armada3720",
> + "marvell,armada3710";
> +
> + aliases {
> + /* ethernet1 is WAN port */
> + ethernet1 =
> + ethernet2 =
> + ethernet3 =
> + ethernet4 =
> + ethernet5 =
> + };
> +
> + reg_usb3_vbus: usb3-vbus {
> + compatible = "regulator-fixed";
> + regulator-name = "usb3-vbus";
> + regulator-min-microvolt = <500>;
> + regulator-max-microvolt = <500>;
> + enable-active-high;
> + gpio = < 19 GPIO_ACTIVE_HIGH>;
> + };
> +
> + usb3_phy: usb3-phy {
> + compatible = "usb-nop-xceiv";
> + vcc-supply = <_usb3_vbus>;
> + };
> +
> + gpio-leds {
> + pinctrl-names = "default";
> + compatible = "gpio-leds";
> + /* No assigned functions to the LEDs by default */
> + led1 {
> + label = "ebin-ultra:blue:led1";
> + gpios = < 11 GPIO_ACTIVE_LOW>;
> + };
> + led2 {
> + label = "ebin-ultra:green:led2";
> + gpios = < 12 GPIO_ACTIVE_LOW>;
> + };
> + led3 {
> + label = "ebin-ultra:red:led3";
> + gpios = < 13 GPIO_ACTIVE_LOW>;
> + };
> + led4 {
> + label = "ebin-ultra:yellow:led4";
> + gpios = < 14 GPIO_ACTIVE_LOW>;
> + };
> + };
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "disabled";
> +};
> +
> + {
> + flash@0 {
> + spi-max-frequency = <10800>;
> + spi-rx-bus-width = <4>;
> + spi-tx-bus-width = <4>;
> +
> + partitions {
> + compatible = "fixed-partitions";
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + partition@0 {
> + label = "firmware";
> + reg = <0x0 0x3e>;
> + };
> + partition@3e {
> + label = "hw-info";
> + reg = <0x3e 0x1>;
> +
Re: [PATCH] arm64: dts: marvell: espressobin: Add support for LED2
Hi Pali,
> LED2 is connected to MPP1_2 pin. It is working only on V7 boards.
> V5 boards have hw bug which cause that LED2 is non-working.
>
> So enable LED2 only for Espressobin V7 boards.
>
> Note that LED1 is connected to LED_WLAN# pin on miniPCIe card and LED3 to
> power supply. Therefore on Espressobin board only LED2 can be controlled
> directly from the host. LED1 is possible to control via WiFi card inserted
> in miniPCIe slot if driver for particular card supports it.
>
> Signed-off-by: Pali Rohár
> Tested-by: Gérald Kerma
Applied on mvebu/dt64
Thanks,
Gregory
>
> ---
>
> Previous version of this patch was sent by Uwe in March 2018, but it did
> not work on any tested V5 board. Now we know it was due to V5 HW bug.
>
> https://lore.kernel.org/linux-arm-kernel/20180321105005.18426-3-u.kleine-koe...@pengutronix.de/
> ---
> .../dts/marvell/armada-3720-espressobin-v7-emmc.dts | 4
> .../boot/dts/marvell/armada-3720-espressobin-v7.dts | 4
> .../boot/dts/marvell/armada-3720-espressobin.dtsi | 13 +
> 3 files changed, 21 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/marvell/armada-3720-espressobin-v7-emmc.dts
> b/arch/arm64/boot/dts/marvell/armada-3720-espressobin-v7-emmc.dts
> index 4775a7eda481..75401eab4d42 100644
> --- a/arch/arm64/boot/dts/marvell/armada-3720-espressobin-v7-emmc.dts
> +++ b/arch/arm64/boot/dts/marvell/armada-3720-espressobin-v7-emmc.dts
> @@ -39,3 +39,7 @@
> {
> status = "okay";
> };
> +
> + {
> + status = "okay";
> +};
> diff --git a/arch/arm64/boot/dts/marvell/armada-3720-espressobin-v7.dts
> b/arch/arm64/boot/dts/marvell/armada-3720-espressobin-v7.dts
> index c47a93978386..48a7f50fb427 100644
> --- a/arch/arm64/boot/dts/marvell/armada-3720-espressobin-v7.dts
> +++ b/arch/arm64/boot/dts/marvell/armada-3720-espressobin-v7.dts
> @@ -34,3 +34,7 @@
> {
> label = "wan";
> };
> +
> + {
> + status = "okay";
> +};
> diff --git a/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dtsi
> b/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dtsi
> index 8a1c678bea5f..daffe136c523 100644
> --- a/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dtsi
> +++ b/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dtsi
> @@ -41,6 +41,19 @@
> 330 0x0>;
> enable-active-high;
> };
> +
> + led2: gpio-led2 {
> + /* led2 is working only on v7 board */
> + status = "disabled";
> +
> + compatible = "gpio-leds";
> +
> + led2 {
> + label = "led2";
> + gpios = < 2 GPIO_ACTIVE_LOW>;
> + default-state = "off";
> + };
> + };
> };
>
> /* J9 */
> --
> 2.20.1
>
--
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.com
[PATCH v4 5/5] ARM: mstar: Fill in GPIO controller properties for infinity
Fill in the properties needed to use the GPIO controller
in the infinity and infinity3 chips.
Signed-off-by: Daniel Palmer
Acked-by: Linus Walleij
---
arch/arm/boot/dts/mstar-infinity.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/mstar-infinity.dtsi
b/arch/arm/boot/dts/mstar-infinity.dtsi
index cd911adef014..0bee517797f4 100644
--- a/arch/arm/boot/dts/mstar-infinity.dtsi
+++ b/arch/arm/boot/dts/mstar-infinity.dtsi
@@ -6,6 +6,13 @@
#include "mstar-v7.dtsi"
+#include
+
{
reg = <0xa000 0x16000>;
};
+
+ {
+ compatible = "mstar,msc313-gpio";
+ status = "okay";
+};
--
2.29.2
[PATCH v4 1/5] dt-bindings: gpio: Add a binding header for the MSC313 GPIO driver
Header adds defines for the gpio number of each pad from the driver view. The gpio block seems to have enough registers for 128 lines but what line is mapped to a physical pin depends on the chip. The gpio block also seems to contain some registers that are not related to gpio but needed somewhere to go. Because of the above the driver itself uses the index of a pin's offset in an array of the possible offsets for a chip as the gpio number. Signed-off-by: Daniel Palmer Reviewed-by: Rob Herring --- MAINTAINERS| 1 + include/dt-bindings/gpio/msc313-gpio.h | 53 ++ 2 files changed, 54 insertions(+) create mode 100644 include/dt-bindings/gpio/msc313-gpio.h diff --git a/MAINTAINERS b/MAINTAINERS index 2daa6ee673f7..9e7d12b2d403 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2135,6 +2135,7 @@ W:http://linux-chenxing.org/ F: Documentation/devicetree/bindings/arm/mstar/* F: arch/arm/boot/dts/mstar-* F: arch/arm/mach-mstar/ +F: include/dt-bindings/gpio/msc313-gpio.h ARM/NEC MOBILEPRO 900/c MACHINE SUPPORT M: Michael Petchkovsky diff --git a/include/dt-bindings/gpio/msc313-gpio.h b/include/dt-bindings/gpio/msc313-gpio.h new file mode 100644 index ..2dd56683d3c1 --- /dev/null +++ b/include/dt-bindings/gpio/msc313-gpio.h @@ -0,0 +1,53 @@ +/* SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause */ +/* + * GPIO definitions for MStar/SigmaStar MSC313 and later SoCs + * + * Copyright (C) 2020 Daniel Palmer + */ + +#ifndef _DT_BINDINGS_MSC313_GPIO_H +#define _DT_BINDINGS_MSC313_GPIO_H + +#define MSC313_GPIO_FUART 0 +#define MSC313_GPIO_FUART_RX (MSC313_GPIO_FUART + 0) +#define MSC313_GPIO_FUART_TX (MSC313_GPIO_FUART + 1) +#define MSC313_GPIO_FUART_CTS (MSC313_GPIO_FUART + 2) +#define MSC313_GPIO_FUART_RTS (MSC313_GPIO_FUART + 3) + +#define MSC313_GPIO_SR (MSC313_GPIO_FUART_RTS + 1) +#define MSC313_GPIO_SR_IO2 (MSC313_GPIO_SR + 0) +#define MSC313_GPIO_SR_IO3 (MSC313_GPIO_SR + 1) +#define MSC313_GPIO_SR_IO4 (MSC313_GPIO_SR + 2) +#define MSC313_GPIO_SR_IO5 (MSC313_GPIO_SR + 3) +#define MSC313_GPIO_SR_IO6 (MSC313_GPIO_SR + 4) +#define MSC313_GPIO_SR_IO7 (MSC313_GPIO_SR + 5) +#define MSC313_GPIO_SR_IO8 (MSC313_GPIO_SR + 6) +#define MSC313_GPIO_SR_IO9 (MSC313_GPIO_SR + 7) +#define MSC313_GPIO_SR_IO10(MSC313_GPIO_SR + 8) +#define MSC313_GPIO_SR_IO11(MSC313_GPIO_SR + 9) +#define MSC313_GPIO_SR_IO12(MSC313_GPIO_SR + 10) +#define MSC313_GPIO_SR_IO13(MSC313_GPIO_SR + 11) +#define MSC313_GPIO_SR_IO14(MSC313_GPIO_SR + 12) +#define MSC313_GPIO_SR_IO15(MSC313_GPIO_SR + 13) +#define MSC313_GPIO_SR_IO16(MSC313_GPIO_SR + 14) +#define MSC313_GPIO_SR_IO17(MSC313_GPIO_SR + 15) + +#define MSC313_GPIO_SD (MSC313_GPIO_SR_IO17 + 1) +#define MSC313_GPIO_SD_CLK (MSC313_GPIO_SD + 0) +#define MSC313_GPIO_SD_CMD (MSC313_GPIO_SD + 1) +#define MSC313_GPIO_SD_D0 (MSC313_GPIO_SD + 2) +#define MSC313_GPIO_SD_D1 (MSC313_GPIO_SD + 3) +#define MSC313_GPIO_SD_D2 (MSC313_GPIO_SD + 4) +#define MSC313_GPIO_SD_D3 (MSC313_GPIO_SD + 5) + +#define MSC313_GPIO_I2C1 (MSC313_GPIO_SD_D3 + 1) +#define MSC313_GPIO_I2C1_SCL (MSC313_GPIO_I2C1 + 0) +#define MSC313_GPIO_I2C1_SDA (MSC313_GPIO_I2C1 + 1) + +#define MSC313_GPIO_SPI0 (MSC313_GPIO_I2C1_SDA + 1) +#define MSC313_GPIO_SPI0_CZ(MSC313_GPIO_SPI0 + 0) +#define MSC313_GPIO_SPI0_CK(MSC313_GPIO_SPI0 + 1) +#define MSC313_GPIO_SPI0_DI(MSC313_GPIO_SPI0 + 2) +#define MSC313_GPIO_SPI0_DO(MSC313_GPIO_SPI0 + 3) + +#endif /* _DT_BINDINGS_MSC313_GPIO_H */ -- 2.29.2
[PATCH v4 4/5] ARM: mstar: Add gpio controller to MStar base dtsi
The GPIO controller is at the same address in all of the
currently known chips so create a node for it in the base
dtsi.
Some extra properties are needed to actually use it so
disable it by default.
Signed-off-by: Daniel Palmer
Acked-by: Linus Walleij
---
arch/arm/boot/dts/mstar-v7.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/mstar-v7.dtsi b/arch/arm/boot/dts/mstar-v7.dtsi
index f07880561e11..81369bc07f78 100644
--- a/arch/arm/boot/dts/mstar-v7.dtsi
+++ b/arch/arm/boot/dts/mstar-v7.dtsi
@@ -109,6 +109,16 @@ l3bridge: l3bridge@204400 {
reg = <0x204400 0x200>;
};
+ gpio: gpio@207800 {
+ #gpio-cells = <2>;
+ reg = <0x207800 0x200>;
+ gpio-controller;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ interrupt-parent = <_fiq>;
+ status = "disabled";
+ };
+
pm_uart: uart@221000 {
compatible = "ns16550a";
reg = <0x221000 0x100>;
--
2.29.2
[PATCH v4 2/5] dt-bindings: gpio: Binding for MStar MSC313 GPIO controller
Add a binding description for the MStar/SigmaStar GPIO controller
found in the MSC313 and later ARMv7 SoCs.
Signed-off-by: Daniel Palmer
---
.../bindings/gpio/mstar,msc313-gpio.yaml | 59 +++
MAINTAINERS | 1 +
2 files changed, 60 insertions(+)
create mode 100644
Documentation/devicetree/bindings/gpio/mstar,msc313-gpio.yaml
diff --git a/Documentation/devicetree/bindings/gpio/mstar,msc313-gpio.yaml
b/Documentation/devicetree/bindings/gpio/mstar,msc313-gpio.yaml
new file mode 100644
index ..1f2ef408bb43
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/mstar,msc313-gpio.yaml
@@ -0,0 +1,59 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpio/mstar,msc313-gpio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MStar/SigmaStar GPIO controller
+
+maintainers:
+ - Daniel Palmer
+
+properties:
+ $nodename:
+pattern: "^gpio@[0-9a-f]+$"
+
+ compatible:
+const: mstar,msc313-gpio
+
+ reg:
+maxItems: 1
+
+ gpio-controller: true
+
+ "#gpio-cells":
+const: 2
+
+ gpio-ranges: true
+
+ interrupt-controller: true
+
+ "#interrupt-cells":
+const: 2
+
+required:
+ - compatible
+ - reg
+ - gpio-controller
+ - "#gpio-cells"
+ - interrupt-controller
+ - "#interrupt-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+
+gpio: gpio@207800 {
+ compatible = "mstar,msc313e-gpio";
+ #gpio-cells = <2>;
+ reg = <0x207800 0x200>;
+ gpio-controller;
+ gpio-ranges = < 0 36 22>,
+< 22 63 4>,
+< 26 68 6>;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ interrupt-parent = <_fiq>;
+};
diff --git a/MAINTAINERS b/MAINTAINERS
index 9e7d12b2d403..56a5392b88aa 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2133,6 +2133,7 @@ L:linux-arm-ker...@lists.infradead.org (moderated
for non-subscribers)
S: Maintained
W: http://linux-chenxing.org/
F: Documentation/devicetree/bindings/arm/mstar/*
+F: Documentation/devicetree/bindings/gpio/mstar,msc313-gpio.yaml
F: arch/arm/boot/dts/mstar-*
F: arch/arm/mach-mstar/
F: include/dt-bindings/gpio/msc313-gpio.h
--
2.29.2
[PATCH v4 3/5] gpio: msc313: MStar MSC313 GPIO driver
This adds a driver that supports the GPIO block found in MStar/SigmaStar ARMv7 SoCs. The controller seems to have enough register for 128 lines but where they are wired up differs between chips and no currently known chip uses anywhere near 128 lines so there needs to be some per-chip data to collect together what lines actually have physical pins attached and map the right names to them. The core peripherals seem to use the same lines on the currently known chips but the lines used for the sensor interface, lcd controller etc pins seem to be totally different between the infinity and mercury chips The code tries to collect all of the re-usable names, offsets etc together so that it's easy to build the extra per-chip data for other chips in the future. So far this only supports the MSC313 and MSC313E chips. Support for the SSC8336N (mercury5) is trivial to add once all of the lines have been mapped out. Signed-off-by: Daniel Palmer --- MAINTAINERS| 1 + drivers/gpio/Kconfig | 11 + drivers/gpio/Makefile | 1 + drivers/gpio/gpio-msc313.c | 460 + 4 files changed, 473 insertions(+) create mode 100644 drivers/gpio/gpio-msc313.c diff --git a/MAINTAINERS b/MAINTAINERS index 56a5392b88aa..28283d165aac 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2136,6 +2136,7 @@ F:Documentation/devicetree/bindings/arm/mstar/* F: Documentation/devicetree/bindings/gpio/mstar,msc313-gpio.yaml F: arch/arm/boot/dts/mstar-* F: arch/arm/mach-mstar/ +F: drivers/gpio/gpio-msc313.c F: include/dt-bindings/gpio/msc313-gpio.h ARM/NEC MOBILEPRO 900/c MACHINE SUPPORT diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig index 5d4de5cd6759..22ad5902299a 100644 --- a/drivers/gpio/Kconfig +++ b/drivers/gpio/Kconfig @@ -737,6 +737,17 @@ config GPIO_AMD_FCH Note: This driver doesn't registers itself automatically, as it needs to be provided with platform specific configuration. (See eg. CONFIG_PCENGINES_APU2.) + +config GPIO_MSC313 + bool "MStar MSC313 GPIO support" + depends on ARCH_MSTARV7 + default ARCH_MSTARV7 + select GPIOLIB_IRQCHIP + select IRQ_DOMAIN_HIERARCHY + help + Say Y here to support the main GPIO block on MStar/SigmaStar + ARMv7 based SoCs. + endmenu menu "Port-mapped I/O GPIO drivers" diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile index 09dada80ac34..b6c116a7c785 100644 --- a/drivers/gpio/Makefile +++ b/drivers/gpio/Makefile @@ -101,6 +101,7 @@ obj-$(CONFIG_GPIO_MOCKUP) += gpio-mockup.o obj-$(CONFIG_GPIO_MOXTET) += gpio-moxtet.o obj-$(CONFIG_GPIO_MPC5200) += gpio-mpc5200.o obj-$(CONFIG_GPIO_MPC8XXX) += gpio-mpc8xxx.o +obj-$(CONFIG_GPIO_MSC313) += gpio-msc313.o obj-$(CONFIG_GPIO_MSIC)+= gpio-msic.o obj-$(CONFIG_GPIO_MT7621) += gpio-mt7621.o obj-$(CONFIG_GPIO_MVEBU) += gpio-mvebu.o diff --git a/drivers/gpio/gpio-msc313.c b/drivers/gpio/gpio-msc313.c new file mode 100644 index ..da31a5ff7a2b --- /dev/null +++ b/drivers/gpio/gpio-msc313.c @@ -0,0 +1,460 @@ +// SPDX-License-Identifier: GPL-2.0 +/* Copyright (C) 2020 Daniel Palmer */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include + +#define DRIVER_NAME "gpio-msc313" + +#define MSC313_GPIO_IN BIT(0) +#define MSC313_GPIO_OUT BIT(4) +#define MSC313_GPIO_OEN BIT(5) + +/* + * These bits need to be saved to correctly restore the + * gpio state when resuming from suspend to memory. + */ +#define MSC313_GPIO_BITSTOSAVE (MSC313_GPIO_OUT | MSC313_GPIO_OEN) + +/* pad names for fuart, same for all SoCs so far */ +#define MSC313_PINNAME_FUART_RX"fuart_rx" +#define MSC313_PINNAME_FUART_TX"fuart_tx" +#define MSC313_PINNAME_FUART_CTS "fuart_cts" +#define MSC313_PINNAME_FUART_RTS "fuart_rts" + +/* pad names for sr, mercury5 is different */ +#define MSC313_PINNAME_SR_IO2 "sr_io2" +#define MSC313_PINNAME_SR_IO3 "sr_io3" +#define MSC313_PINNAME_SR_IO4 "sr_io4" +#define MSC313_PINNAME_SR_IO5 "sr_io5" +#define MSC313_PINNAME_SR_IO6 "sr_io6" +#define MSC313_PINNAME_SR_IO7 "sr_io7" +#define MSC313_PINNAME_SR_IO8 "sr_io8" +#define MSC313_PINNAME_SR_IO9 "sr_io9" +#define MSC313_PINNAME_SR_IO10 "sr_io10" +#define MSC313_PINNAME_SR_IO11 "sr_io11" +#define MSC313_PINNAME_SR_IO12 "sr_io12" +#define MSC313_PINNAME_SR_IO13 "sr_io13" +#define MSC313_PINNAME_SR_IO14 "sr_io14" +#define MSC313_PINNAME_SR_IO15 "sr_io15" +#define MSC313_PINNAME_SR_IO16 "sr_io16" +#define MSC313_PINNAME_SR_IO17 "sr_io17" + +/* pad names for sd, same for all SoCs so far */ +#define MSC313_PINNAME_SD_CLK "sd_clk" +#define
[PATCH v4 0/5] Add GPIO support for MStar/SigmaStar ARMv7
At the moment the MStar/SigmaStar support is only really capable of shell from an initramfs and not much else. Most of the interesting drivers are blocked on clock and pinctrl drivers and those are going to take me a little while to get cleaned up. Clock and pinctrl aren't needed for basic GPIO to work (all pins start off as GPIOs..) and it makes it possible to actually do something so this series adds everything that is needed for the main GPIO block in these chips. Changes since v3: - Remove unneeded "gpio-ranges-group-names" property from binding yaml. Changes since v2: - Numerous style and code cleanups as suggested by Andy Shevchenko, Linus Walleij, Marc Zyngier and Rob Herring. - Pad names moved out of the binding header because they are no longer needed there. The pin/pad numbers are still there as I couldn't think of a better way to do this. meson8b-gpio.h seems to be similar. Changes since v1: - Moves the binding header commit before the yaml commit - Fixes the license on the binding header to include BSD-2-Clause - The driver has been reworked to use the gpiolib irqchip functionality as suggested by Linus[0]. I think I got this right. The gpio controller doesn't actually do anything with interrupts itself.. It just happens to have 4 lines that are also wired to lines on one of the interrupt controllers. - Now that the driver is an interrupt controller in it's own right for the gpio lines that have associated interrupts the binding description has been updated to add the interrupt-controller bits and remove the description of the interrupt-names that described how the interrupts used to be passed in. Daniel Palmer (5): dt-bindings: gpio: Add a binding header for the MSC313 GPIO driver dt-bindings: gpio: Binding for MStar MSC313 GPIO controller gpio: msc313: MStar MSC313 GPIO driver ARM: mstar: Add gpio controller to MStar base dtsi ARM: mstar: Fill in GPIO controller properties for infinity .../bindings/gpio/mstar,msc313-gpio.yaml | 59 +++ MAINTAINERS | 3 + arch/arm/boot/dts/mstar-infinity.dtsi | 7 + arch/arm/boot/dts/mstar-v7.dtsi | 10 + drivers/gpio/Kconfig | 11 + drivers/gpio/Makefile | 1 + drivers/gpio/gpio-msc313.c| 460 ++ include/dt-bindings/gpio/msc313-gpio.h| 53 ++ 8 files changed, 604 insertions(+) create mode 100644 Documentation/devicetree/bindings/gpio/mstar,msc313-gpio.yaml create mode 100644 drivers/gpio/gpio-msc313.c create mode 100644 include/dt-bindings/gpio/msc313-gpio.h -- 2.29.2
Re: [PATCH v2 1/1] arm64: dts: marvell: Add a device tree for the IEI Puzzle-M801 board
Luka Kovacic writes:
> Add initial support for the IEI Puzzle-M801 1U Rackmount Network
> Appliance board.
>
> The board is based on the quad-core Marvell Armada 8040 SoC and supports
> up to 16 GB of DDR4 2400 MHz ECC RAM. It has a PCIe x16 slot (x2 lanes
> only) and an M.2 type B slot.
>
> Main system hardware:
> 2x USB 3.0
> 4x Gigabit Ethernet
> 2x SFP+
> 1x SATA 3.0
> 1x M.2 type B
> 1x RJ45 UART
> 1x SPI flash
> 1x IEI WT61P803 PUZZLE Microcontroller
> 1x EPSON RX8010 RTC (used instead of the integrated Marvell RTC controller)
> 6x SFP+ LED
> 1x HDD LED
>
> All of the hardware listed above is supported and tested in this port.
>
> Signed-off-by: Luka Kovacic
> Acked-by: Andrew Lunn
> Cc: Luka Perkov
> Cc: Robert Marko
Applied on mvebu/dt64
Thanks,
Gregory
> ---
> Changes for v2:
> - Use the correct vendor title (IEI instead of iEi)
> - Sync the device tree with dt-bindings
>
> This patch is now sent separately from the IEI WT61P803 PUZZLE MCU
> patchset. Go to the following link for reference:
> https://lore.kernel.org/linux-hwmon/20201025005916.64747-1-luka.kova...@sartura.hr/
>
> arch/arm64/boot/dts/marvell/Makefile | 1 +
> .../dts/marvell/armada-8040-puzzle-m801.dts | 523 ++
> 2 files changed, 524 insertions(+)
> create mode 100644 arch/arm64/boot/dts/marvell/armada-8040-puzzle-m801.dts
>
> diff --git a/arch/arm64/boot/dts/marvell/Makefile
> b/arch/arm64/boot/dts/marvell/Makefile
> index 3e5f2e7a040c..e413c3261792 100644
> --- a/arch/arm64/boot/dts/marvell/Makefile
> +++ b/arch/arm64/boot/dts/marvell/Makefile
> @@ -12,6 +12,7 @@ dtb-$(CONFIG_ARCH_MVEBU) += armada-8040-clearfog-gt-8k.dtb
> dtb-$(CONFIG_ARCH_MVEBU) += armada-8040-db.dtb
> dtb-$(CONFIG_ARCH_MVEBU) += armada-8040-mcbin.dtb
> dtb-$(CONFIG_ARCH_MVEBU) += armada-8040-mcbin-singleshot.dtb
> +dtb-$(CONFIG_ARCH_MVEBU) += armada-8040-puzzle-m801.dtb
> dtb-$(CONFIG_ARCH_MVEBU) += armada-8080-db.dtb
> dtb-$(CONFIG_ARCH_MVEBU) += cn9130-db.dtb
> dtb-$(CONFIG_ARCH_MVEBU) += cn9131-db.dtb
> diff --git a/arch/arm64/boot/dts/marvell/armada-8040-puzzle-m801.dts
> b/arch/arm64/boot/dts/marvell/armada-8040-puzzle-m801.dts
> new file mode 100644
> index ..dac85fa748de
> --- /dev/null
> +++ b/arch/arm64/boot/dts/marvell/armada-8040-puzzle-m801.dts
> @@ -0,0 +1,523 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (C) 2016 Marvell Technology Group Ltd.
> + * Copyright (C) 2020 Sartura Ltd.
> + *
> + * Device Tree file for IEI Puzzle-M801
> + */
> +
> +#include "armada-8040.dtsi"
> +
> +#include
> +#include
> +
> +/ {
> + model = "IEI-Puzzle-M801";
> + compatible = "marvell,armada8040", "marvell,armada-ap806-quad",
> "marvell,armada-ap806";
> +
> + aliases {
> + ethernet0 = _eth0;
> + ethernet1 = _eth0;
> + ethernet2 = _eth1;
> + ethernet3 = _eth2;
> + ethernet4 = _eth1;
> + ethernet5 = _eth2;
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +
> + memory@0 {
> + device_type = "memory";
> + reg = <0x0 0x0 0x0 0x8000>;
> + };
> +
> + /* Regulator labels correspond with schematics */
> + v_3_3: regulator-3-3v {
> + compatible = "regulator-fixed";
> + regulator-name = "v_3_3";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + regulator-always-on;
> + status = "okay";
> + };
> +
> + v_5v0_usb3_hst_vbus: regulator-usb3-vbus0 {
> + compatible = "regulator-fixed";
> + enable-active-high;
> + gpio = <_gpio2 15 GPIO_ACTIVE_HIGH>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_xhci_vbus_pins>;
> + regulator-name = "v_5v0_usb3_hst_vbus";
> + regulator-min-microvolt = <500>;
> + regulator-max-microvolt = <500>;
> + status = "okay";
> + };
> +
> + v_vddo_h: regulator-1-8v {
> + compatible = "regulator-fixed";
> + regulator-name = "v_vddo_h";
> + regulator-min-microvolt = <180>;
> + regulator-max-microvolt = <180>;
> + regulator-always-on;
> + status = "okay";
> + };
> +
> + sfp_cp0_eth0: sfp-cp0-eth0 {
> + compatible = "sff,sfp";
> + i2c-bus = <_i2c>;
> + los-gpio = <_gpio 11 GPIO_ACTIVE_HIGH>;
> + mod-def0-gpio = <_gpio 10 GPIO_ACTIVE_LOW>;
> + tx-disable-gpio = <_gpio 9 GPIO_ACTIVE_HIGH>;
> + tx-fault-gpio = <_gpio 8 GPIO_ACTIVE_HIGH>;
> + maximum-power-milliwatt = <3000>;
> + };
> +
> + sfp_cp1_eth0: sfp-cp1-eth0 {
> + compatible = "sff,sfp";
> + i2c-bus = <_i2c>;
> + los-gpio = <_gpio 3 GPIO_ACTIVE_HIGH>;
> + mod-def0-gpio = <_gpio 2
Re: [PATCH] MAINTAINERS: Move Jason Cooper to CREDITS
Marc Zyngier writes: > Jason's email address has now been bouncing for weeks, and no > reply was received when trying to reach out on other addresses. > > We really hope he is OK. But until we hear of his whereabouts, > let's move him to the CREDITS file so that people stop Cc-ing > him. > > Cc: Andrew Lunn > Cc: Sebastian Hesselbarth > Cc: Gregory Clement > Cc: Thomas Gleixner > Cc: Thomas Petazzoni > Signed-off-by: Marc Zyngier Acked-by: Gregory CLEMENT Thanks, Gregory > --- > CREDITS | 5 + > MAINTAINERS | 4 > 2 files changed, 5 insertions(+), 4 deletions(-) > > diff --git a/CREDITS b/CREDITS > index 8592e45e3932..cf112d3e9382 100644 > --- a/CREDITS > +++ b/CREDITS > @@ -740,6 +740,11 @@ S: (ask for current address) > S: Portland, Oregon > S: USA > > +N: Jason Cooper > +D: ARM/Marvell SOC co-maintainer > +D: irqchip co-maintainer > +D: MVEBU PCI DRIVER co-maintainer > + > N: Robin Cornelius > E: robincornel...@users.sourceforge.net > D: Ralink rt2x00 WLAN driver > diff --git a/MAINTAINERS b/MAINTAINERS > index e451dcce054f..7ba26942a573 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -2012,7 +2012,6 @@ M: Philipp Zabel > S: Maintained > > ARM/Marvell Dove/MV78xx0/Orion SOC support > -M: Jason Cooper > M: Andrew Lunn > M: Sebastian Hesselbarth > M: Gregory Clement > @@ -2029,7 +2028,6 @@ F: arch/arm/plat-orion/ > F: drivers/soc/dove/ > > ARM/Marvell Kirkwood and Armada 370, 375, 38x, 39x, XP, 3700, 7K/8K, CN9130 > SOC support > -M: Jason Cooper > M: Andrew Lunn > M: Gregory Clement > M: Sebastian Hesselbarth > @@ -9255,7 +9253,6 @@ F: kernel/irq/ > > IRQCHIP DRIVERS > M: Thomas Gleixner > -M: Jason Cooper > M: Marc Zyngier > L: linux-kernel@vger.kernel.org > S: Maintained > @@ -13405,7 +13402,6 @@ F:drivers/pci/controller/mobiveil/pcie-mobiveil* > > PCI DRIVER FOR MVEBU (Marvell Armada 370 and Armada XP SOC support) > M: Thomas Petazzoni > -M: Jason Cooper > L: linux-...@vger.kernel.org > L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) > S: Maintained > -- > 2.29.2 > -- Gregory Clement, Bootlin Embedded Linux and Kernel engineering http://bootlin.com
WARNING: suspicious RCU usage in get_counters
Hello,
syzbot found the following issue on:
HEAD commit:127c501a Merge tag '5.10-rc5-smb3-fixes' of git://git.samb..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=17f4912d50
kernel config: https://syzkaller.appspot.com/x/.config?x=6d1e98d0b97781e4
dashboard link: https://syzkaller.appspot.com/bug?extid=5cfc290df4bbf069bc65
compiler: gcc (GCC) 10.1.0-syz 20200507
Unfortunately, I don't have any reproducer for this issue yet.
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+5cfc290df4bbf069b...@syzkaller.appspotmail.com
=
WARNING: suspicious RCU usage
5.10.0-rc5-syzkaller #0 Not tainted
-
kernel/sched/core.c:7270 Illegal context switch in RCU-sched read-side critical
section!
other info that might help us debug this:
rcu_scheduler_active = 2, debug_locks = 0
1 lock held by syz-executor.3/10331:
#0: 8880459f8308 ([i].mutex){+.+.}-{3:3}, at:
xt_find_table_lock+0x41/0x540 net/netfilter/x_tables.c:1206
stack backtrace:
CPU: 3 PID: 10331 Comm: syz-executor.3 Not tainted 5.10.0-rc5-syzkaller #0
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS
rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x107/0x163 lib/dump_stack.c:118
___might_sleep+0x25d/0x2b0 kernel/sched/core.c:7270
get_counters+0x2f5/0x520 net/ipv4/netfilter/ip_tables.c:765
do_ipt_get_ctl+0x634/0x9d0 net/ipv4/netfilter/ip_tables.c:805
nf_getsockopt+0x72/0xd0 net/netfilter/nf_sockopt.c:116
ip_getsockopt net/ipv4/ip_sockglue.c:1777 [inline]
ip_getsockopt+0x164/0x1c0 net/ipv4/ip_sockglue.c:1756
tcp_getsockopt+0x86/0xd0 net/ipv4/tcp.c:3882
__sys_getsockopt+0x219/0x4c0 net/socket.c:2173
__do_sys_getsockopt net/socket.c:2188 [inline]
__se_sys_getsockopt net/socket.c:2185 [inline]
__x64_sys_getsockopt+0xba/0x150 net/socket.c:2185
do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x45ec3a
Code: b8 34 01 00 00 0f 05 48 3d 01 f0 ff ff 0f 83 cd 9f fb ff c3 66 2e 0f 1f
84 00 00 00 00 00 66 90 49 89 ca b8 37 00 00 00 0f 05 <48> 3d 01 f0 ff ff 0f 83
aa 9f fb ff c3 66 0f 1f 84 00 00 00 00 00
RSP: 002b:7ffccbec9f78 EFLAGS: 0212 ORIG_RAX: 0037
RAX: ffda RBX: 7ffccbec9fb0 RCX: 0045ec3a
RDX: 0041 RSI: RDI: 0003
RBP: 00734000 R08: 7ffccbec9fac R09: 4000
R10: 7ffccbeca010 R11: 0212 R12: 7ffccbeca010
R13: 0003 R14: 00732bc0 R15:
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkal...@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
Re: scheduling while atomic in z3fold
On Sun, 2020-11-29 at 10:21 +0100, Mike Galbraith wrote: > On Sun, 2020-11-29 at 08:48 +0100, Mike Galbraith wrote: > > On Sun, 2020-11-29 at 07:41 +0100, Mike Galbraith wrote: > > > On Sat, 2020-11-28 at 15:27 +0100, Oleksandr Natalenko wrote: > > > > > > > > > > Shouldn't the list manipulation be protected with > > > > > > local_lock+this_cpu_ptr instead of get_cpu_ptr+spin_lock? > > > > > > > > Totally untested: > > > > > > Hrm, the thing doesn't seem to care deeply about preemption being > > > disabled, so adding another lock may be overkill. It looks like you > > > could get the job done via migrate_disable()+this_cpu_ptr(). > > > > There is however an ever so tiny chance that I'm wrong about that :) > > Or not, your local_lock+this_cpu_ptr version exploded too. > > Perhaps there's a bit of non-rt related racy racy going on in zswap > thingy that makes swap an even less wonderful idea for RT than usual. Raciness seems to be restricted to pool compressor. "zbud" seems to be solid, virgin "zsmalloc" explodes, as does "z3fold" regardless which of us puts his grubby fingerprints on it. Exploding compressors survived zero runs of runltp -f mm, I declared zbud to be at least kinda sorta stable after box survived five runs. -Mike
Re: [RFC PATCH 2/3] net: sparx5: Add Sparx5 switchdev driver
On Sat, Nov 28, 2020 at 10:28:28PM +, Russell King - ARM Linux admin wrote:
> On Sat, Nov 28, 2020 at 08:06:16PM +0100, Andrew Lunn wrote:
> > > +static void sparx5_phylink_mac_config(struct phylink_config *config,
> > > + unsigned int mode,
> > > + const struct phylink_link_state *state)
> > > +{
> > > + struct sparx5_port *port = netdev_priv(to_net_dev(config->dev));
> > > + struct sparx5_port_config conf;
> > > + int err = 0;
> > > +
> > > + conf = port->conf;
> > > + conf.autoneg = state->an_enabled;
> > > + conf.pause = state->pause;
> > > + conf.duplex = state->duplex;
> > > + conf.power_down = false;
> > > + conf.portmode = state->interface;
> > > +
> > > + if (state->speed == SPEED_UNKNOWN) {
> > > + /* When a SFP is plugged in we use capabilities to
> > > + * default to the highest supported speed
> > > + */
> >
> > This looks suspicious.
>
> Yes, it looks highly suspicious. The fact that
> sparx5_phylink_mac_link_up() is empty, and sparx5_phylink_mac_config()
> does all the work suggests that this was developed before the phylink
> re-organisation, and this code hasn't been updated for it.
>
> Any new code for the kernel really ought to be updated for the new
> phylink methodology before it is accepted.
>
> Looking at sparx5_port_config(), it also seems to use
> PHY_INTERFACE_MODE_1000BASEX for both 1000BASE-X and 2500BASE-X. All
> very well for the driver to do that internally, but it's confusing
> when it comes to reviewing this stuff, especially when people outside
> of the driver (such as myself) reviewing it need to understand what's
> going on with the configuration.
There are other issues too.
Looking at sparx5_get_1000basex_status(), we have:
+ status->link = DEV2G5_PCS1G_LINK_STATUS_LINK_STATUS_GET(value) |
+ DEV2G5_PCS1G_LINK_STATUS_SYNC_STATUS_GET(value);
Why is the link status the logical OR of these?
+ if ((lp_abil >> 8) & 1) /* symmetric pause */
+ status->pause = MLO_PAUSE_RX | MLO_PAUSE_TX;
+ if (lp_abil & (1 << 7)) /* asymmetric pause */
+ status->pause |= MLO_PAUSE_RX;
is actually wrong, and I see I need to improve the documentation for
mac_pcs_get_state(). The intention in the documentation was concerning
hardware that indicated the _resolved_ status of pause modes. It was
not intended that drivers resolve the pause modes themselves.
Even so, the above is still wrong; it takes no account of what is being
advertised at the local end. If one looks at the implementation in
phylink_decode_c37_word(), one will notice there is code to deal with
this.
I think we ought to make phylink_decode_c37_word() and
phylink_decode_sgmii_word() public functions, and then this driver can
use these helpers to decode the link partner advertisement to the
phylink state.
Does the driver need to provide an ethtool .get_link function? That
seems to bypass phylink. Why can't ethtool_op_get_link() be used?
I think if ethtool_op_get_link() is used, we then have just one caller
for sparx5_get_port_status(), which means "struct sparx5_port_status"
can be eliminated and the code cleaned up to use the phylink decoding
helpers.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
[GIT PULL] efi/urgent for v5.10-rc6
Hi Linus,
please pull more forwarded EFI urgent fixes.
Thx.
---
The following changes since commit c2fe61d8be491ff8188edaf22e838f81146b:
efi/x86: Free efi_pgd with free_pages() (2020-11-10 19:18:11 +0100)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
tags/efi-urgent-for-v5.10-rc5
for you to fetch changes up to 36a237526cd81ff4b6829e6ebd60921c6f976e3b:
efi: EFI_EARLYCON should depend on EFI (2020-11-25 16:55:02 +0100)
More EFI fixes for v5.10-rc:
- revert efivarfs kmemleak fix again - it was a false positive;
- make CONFIG_EFI_EARLYCON depend on CONFIG_EFI explicitly so it does not
pull in other dependencies unnecessarily if CONFIG_EFI is not set
- defer attempts to load SSDT overrides from EFI vars until after the
efivar layer is up.
Amadeusz Sławiński (1):
efi/efivars: Set generic ops before loading SSDT
Ard Biesheuvel (1):
efivarfs: revert "fix memory leak in efivarfs_create()"
Geert Uytterhoeven (1):
efi: EFI_EARLYCON should depend on EFI
drivers/firmware/efi/Kconfig | 2 +-
drivers/firmware/efi/efi.c | 2 +-
fs/efivarfs/inode.c | 2 ++
fs/efivarfs/super.c | 1 -
4 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/firmware/efi/Kconfig b/drivers/firmware/efi/Kconfig
index 36ec1f718893..d9895491ff34 100644
--- a/drivers/firmware/efi/Kconfig
+++ b/drivers/firmware/efi/Kconfig
@@ -270,7 +270,7 @@ config EFI_DEV_PATH_PARSER
config EFI_EARLYCON
def_bool y
- depends on SERIAL_EARLYCON && !ARM && !IA64
+ depends on EFI && SERIAL_EARLYCON && !ARM && !IA64
select FONT_SUPPORT
select ARCH_USE_MEMREMAP_PROT
diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index 5e5480a0a32d..6c6eec044a97 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -390,10 +390,10 @@ static int __init efisubsys_init(void)
if (efi_rt_services_supported(EFI_RT_SUPPORTED_GET_VARIABLE |
EFI_RT_SUPPORTED_GET_NEXT_VARIABLE_NAME))
{
- efivar_ssdt_load();
error = generic_ops_register();
if (error)
goto err_put;
+ efivar_ssdt_load();
platform_device_register_simple("efivars", 0, NULL, 0);
}
diff --git a/fs/efivarfs/inode.c b/fs/efivarfs/inode.c
index 96c0c86f3fff..0297ad95eb5c 100644
--- a/fs/efivarfs/inode.c
+++ b/fs/efivarfs/inode.c
@@ -7,6 +7,7 @@
#include
#include
#include
+#include
#include
#include
@@ -103,6 +104,7 @@ static int efivarfs_create(struct inode *dir, struct dentry
*dentry,
var->var.VariableName[i] = '\0';
inode->i_private = var;
+ kmemleak_ignore(var);
err = efivar_entry_add(var, _list);
if (err)
diff --git a/fs/efivarfs/super.c b/fs/efivarfs/super.c
index f943fd0b0699..15880a68faad 100644
--- a/fs/efivarfs/super.c
+++ b/fs/efivarfs/super.c
@@ -21,7 +21,6 @@ LIST_HEAD(efivarfs_list);
static void efivarfs_evict_inode(struct inode *inode)
{
clear_inode(inode);
- kfree(inode->i_private);
}
static const struct super_operations efivarfs_ops = {
--
Regards/Gruss,
Boris.
SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer, HRB 36809, AG
Nürnberg
[GIT PULL] x86/urgent for v5.10-rc6
Hi Linus,
please pull a couple of urgent fixes which accumulated this last week.
Thx.
---
The following changes since commit 418baf2c28f3473039f2f7377760bd8f6897ae18:
Linux 5.10-rc5 (2020-11-22 15:36:08 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
tags/x86_urgent_for_v5.10-rc6
for you to fetch changes up to 25bc65d8ddfc17cc1d7a45bd48e9bdc0e729ced3:
x86/mce: Do not overwrite no_way_out if mce_end() fails (2020-11-27 17:38:36
+0100)
- Two resctrl fixes to prevent refcount leaks when manipulating the
resctrl fs (Xiaochen Shen)
- Correct prctl(PR_GET_SPECULATION_CTRL) reporting (Anand K Mistry)
- A fix to not lose already seen MCE severity which determines whether
the machine can recover (Gabriele Paoloni)
Anand K Mistry (1):
x86/speculation: Fix prctl() when spectre_v2_user={seccomp,prctl},ibpb
Gabriele Paoloni (1):
x86/mce: Do not overwrite no_way_out if mce_end() fails
Xiaochen Shen (2):
x86/resctrl: Remove superfluous kernfs_get() calls to prevent refcount
leak
x86/resctrl: Add necessary kernfs_put() calls to prevent refcount leak
arch/x86/kernel/cpu/bugs.c | 4 +--
arch/x86/kernel/cpu/mce/core.c | 6 ++--
arch/x86/kernel/cpu/resctrl/rdtgroup.c | 65 ++
3 files changed, 32 insertions(+), 43 deletions(-)
diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index 581fb7223ad0..d41b70fe4918 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -739,11 +739,13 @@ spectre_v2_user_select_mitigation(enum
spectre_v2_mitigation_cmd v2_cmd)
if (boot_cpu_has(X86_FEATURE_IBPB)) {
setup_force_cpu_cap(X86_FEATURE_USE_IBPB);
+ spectre_v2_user_ibpb = mode;
switch (cmd) {
case SPECTRE_V2_USER_CMD_FORCE:
case SPECTRE_V2_USER_CMD_PRCTL_IBPB:
case SPECTRE_V2_USER_CMD_SECCOMP_IBPB:
static_branch_enable(_mm_always_ibpb);
+ spectre_v2_user_ibpb = SPECTRE_V2_USER_STRICT;
break;
case SPECTRE_V2_USER_CMD_PRCTL:
case SPECTRE_V2_USER_CMD_AUTO:
@@ -757,8 +759,6 @@ spectre_v2_user_select_mitigation(enum
spectre_v2_mitigation_cmd v2_cmd)
pr_info("mitigation: Enabling %s Indirect Branch Prediction
Barrier\n",
static_key_enabled(_mm_always_ibpb) ?
"always-on" : "conditional");
-
- spectre_v2_user_ibpb = mode;
}
/*
diff --git a/arch/x86/kernel/cpu/mce/core.c b/arch/x86/kernel/cpu/mce/core.c
index 4102b866e7c0..32b7099e3511 100644
--- a/arch/x86/kernel/cpu/mce/core.c
+++ b/arch/x86/kernel/cpu/mce/core.c
@@ -1384,8 +1384,10 @@ noinstr void do_machine_check(struct pt_regs *regs)
* When there's any problem use only local no_way_out state.
*/
if (!lmce) {
- if (mce_end(order) < 0)
- no_way_out = worst >= MCE_PANIC_SEVERITY;
+ if (mce_end(order) < 0) {
+ if (!no_way_out)
+ no_way_out = worst >= MCE_PANIC_SEVERITY;
+ }
} else {
/*
* If there was a fatal machine check we should have
diff --git a/arch/x86/kernel/cpu/resctrl/rdtgroup.c
b/arch/x86/kernel/cpu/resctrl/rdtgroup.c
index af323e2e3100..6f4ca4bea625 100644
--- a/arch/x86/kernel/cpu/resctrl/rdtgroup.c
+++ b/arch/x86/kernel/cpu/resctrl/rdtgroup.c
@@ -507,6 +507,24 @@ static ssize_t rdtgroup_cpus_write(struct kernfs_open_file
*of,
return ret ?: nbytes;
}
+/**
+ * rdtgroup_remove - the helper to remove resource group safely
+ * @rdtgrp: resource group to remove
+ *
+ * On resource group creation via a mkdir, an extra kernfs_node reference is
+ * taken to ensure that the rdtgroup structure remains accessible for the
+ * rdtgroup_kn_unlock() calls where it is removed.
+ *
+ * Drop the extra reference here, then free the rdtgroup structure.
+ *
+ * Return: void
+ */
+static void rdtgroup_remove(struct rdtgroup *rdtgrp)
+{
+ kernfs_put(rdtgrp->kn);
+ kfree(rdtgrp);
+}
+
struct task_move_callback {
struct callback_headwork;
struct rdtgroup *rdtgrp;
@@ -529,7 +547,7 @@ static void move_myself(struct callback_head *head)
(rdtgrp->flags & RDT_DELETED)) {
current->closid = 0;
current->rmid = 0;
- kfree(rdtgrp);
+ rdtgroup_remove(rdtgrp);
}
if (unlikely(current->flags & PF_EXITING))
@@ -1769,7 +1787,6 @@ static int rdtgroup_mkdir_info_resdir(struct rdt_resource
*r, char *name,
if (IS_ERR(kn_subdir))
return PTR_ERR(kn_subdir);
-
[PATCH 2/2] net: dsa: ksz8795: adjust CPU link to host interface
Add support for RGMII in 100 and 1000 Mbps.
Adjust the CPU port based on the host interface settings: interface
MII type, speed, duplex.
Signed-off-by: Jean Pihet
---
drivers/net/dsa/microchip/ksz8795.c | 93 ++---
1 file changed, 57 insertions(+), 36 deletions(-)
diff --git a/drivers/net/dsa/microchip/ksz8795.c
b/drivers/net/dsa/microchip/ksz8795.c
index 1e101ab56cea..09c1173cc607 100644
--- a/drivers/net/dsa/microchip/ksz8795.c
+++ b/drivers/net/dsa/microchip/ksz8795.c
@@ -916,10 +916,53 @@ static void ksz8795_port_mirror_del(struct dsa_switch
*ds, int port,
PORT_MIRROR_SNIFFER, false);
}
+static void ksz8795_mii_config(struct ksz_device *dev, struct ksz_port *p)
+{
+ u8 data8;
+
+ /* Configure MII interface for proper network communication. */
+ ksz_read8(dev, REG_PORT_5_CTRL_6, );
+ data8 &= ~PORT_INTERFACE_TYPE;
+ data8 &= ~PORT_GMII_1GPS_MODE;
+ switch (p->interface) {
+ case PHY_INTERFACE_MODE_MII:
+ p->phydev.speed = SPEED_100;
+ break;
+ case PHY_INTERFACE_MODE_RMII:
+ data8 |= PORT_INTERFACE_RMII;
+ p->phydev.speed = SPEED_100;
+ break;
+ case PHY_INTERFACE_MODE_GMII:
+ data8 |= PORT_GMII_1GPS_MODE;
+ data8 |= PORT_INTERFACE_GMII;
+ p->phydev.speed = SPEED_1000;
+ break;
+ default:
+ data8 &= ~PORT_RGMII_ID_IN_ENABLE;
+ data8 &= ~PORT_RGMII_ID_OUT_ENABLE;
+ if (p->interface == PHY_INTERFACE_MODE_RGMII_ID ||
+ p->interface == PHY_INTERFACE_MODE_RGMII_RXID)
+ data8 |= PORT_RGMII_ID_IN_ENABLE;
+ if (p->interface == PHY_INTERFACE_MODE_RGMII_ID ||
+ p->interface == PHY_INTERFACE_MODE_RGMII_TXID)
+ data8 |= PORT_RGMII_ID_OUT_ENABLE;
+ /* Support RGMII in 100 and 1000 Mbps */
+ if (p->phydev.speed == SPEED_1000) {
+ data8 |= PORT_GMII_1GPS_MODE;
+ } else {
+ p->phydev.speed = SPEED_100;
+ }
+ data8 |= PORT_INTERFACE_RGMII;
+ break;
+ }
+ ksz_write8(dev, REG_PORT_5_CTRL_6, data8);
+ p->phydev.duplex = 1;
+}
+
static void ksz8795_port_setup(struct ksz_device *dev, int port, bool cpu_port)
{
struct ksz_port *p = >ports[port];
- u8 data8, member;
+ u8 member;
/* enable broadcast storm limit */
ksz_port_cfg(dev, port, P_BCAST_STORM_CTRL, PORT_BROADCAST_STORM, true);
@@ -943,41 +986,7 @@ static void ksz8795_port_setup(struct ksz_device *dev, int
port, bool cpu_port)
port);
p->interface = dev->compat_interface;
}
-
- /* Configure MII interface for proper network communication. */
- ksz_read8(dev, REG_PORT_5_CTRL_6, );
- data8 &= ~PORT_INTERFACE_TYPE;
- data8 &= ~PORT_GMII_1GPS_MODE;
- switch (p->interface) {
- case PHY_INTERFACE_MODE_MII:
- p->phydev.speed = SPEED_100;
- break;
- case PHY_INTERFACE_MODE_RMII:
- data8 |= PORT_INTERFACE_RMII;
- p->phydev.speed = SPEED_100;
- break;
- case PHY_INTERFACE_MODE_GMII:
- data8 |= PORT_GMII_1GPS_MODE;
- data8 |= PORT_INTERFACE_GMII;
- p->phydev.speed = SPEED_1000;
- break;
- default:
- data8 &= ~PORT_RGMII_ID_IN_ENABLE;
- data8 &= ~PORT_RGMII_ID_OUT_ENABLE;
- if (p->interface == PHY_INTERFACE_MODE_RGMII_ID ||
- p->interface == PHY_INTERFACE_MODE_RGMII_RXID)
- data8 |= PORT_RGMII_ID_IN_ENABLE;
- if (p->interface == PHY_INTERFACE_MODE_RGMII_ID ||
- p->interface == PHY_INTERFACE_MODE_RGMII_TXID)
- data8 |= PORT_RGMII_ID_OUT_ENABLE;
- data8 |= PORT_GMII_1GPS_MODE;
- data8 |= PORT_INTERFACE_RGMII;
- p->phydev.speed = SPEED_1000;
- break;
- }
- ksz_write8(dev, REG_PORT_5_CTRL_6, data8);
- p->phydev.duplex = 1;
-
+ksz8795_mii_config(dev, p);
member = dev->port_mask;
} else {
member = dev->host_mask | p->vid_member;
@@ -1102,11 +,23 @@ static int ksz8795_setup(struct dsa_switch *ds)
return 0;
}
+void ksz8795_adjust_link(struct dsa_switch *ds, int port,
+struct phy_device *phydev)
+{
+
[PATCH 1/2] net: dsa: ksz: pad frame to 64 bytes for transmission
Some ethernet controllers (e.g. TI CPSW) pad the frames to a minimum
of 64 bytes before the FCS is appended. This causes an issue with the
KSZ tail tag which could not be the last byte before the FCS.
Solve this by padding the frame to 64 bytes minus the tail tag size,
before the tail tag is added and the frame is passed for transmission.
Signed-off-by: Jean Pihet
---
net/dsa/tag_ksz.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/net/dsa/tag_ksz.c b/net/dsa/tag_ksz.c
index 0a5aa982c60d..0074702dcbbc 100644
--- a/net/dsa/tag_ksz.c
+++ b/net/dsa/tag_ksz.c
@@ -19,8 +19,13 @@ static struct sk_buff *ksz_common_xmit(struct sk_buff *skb,
{
struct sk_buff *nskb;
int padlen;
+ const int min_len = ETH_ZLEN + ETH_FCS_LEN;
- padlen = (skb->len >= ETH_ZLEN) ? 0 : ETH_ZLEN - skb->len;
+ /*
+* Pad to the minimum ethernet frame size, minus the size of the
+* tail tag which will be appended at the very end, before the FCS.
+*/
+ padlen = (skb->len >= min_len) ? 0 : min_len - skb->len - len;
if (skb_tailroom(skb) >= padlen + len) {
/* Let dsa_slave_xmit() free skb */
--
2.26.2
Re: [PATCH v2 net-next 3/3] nfc: s3fwrn5: extract the common phy blocks
On Sat, Nov 28, 2020 at 9:49 PM Krzysztof Kozlowski wrote:
>
> On Fri, Nov 27, 2020 at 08:22:18PM +0900, bongsu.je...@gmail.com wrote:
> > From: Bongsu Jeon
> >
> > Extract the common phy blocks to reuse it.
> > The UART module will use the common blocks.
> >
> > Signed-off-by: Bongsu Jeon
> > ---
> > Changes in v2:
> > - remove the common function's definition in common header file.
> > - make the common phy_common.c file to define the common function.
> > - wrap the lines.
> > - change the Header guard.
> > - remove the unused common function.
> >
> > drivers/nfc/s3fwrn5/Makefile | 2 +-
> > drivers/nfc/s3fwrn5/i2c.c| 114
> > +--
> > drivers/nfc/s3fwrn5/phy_common.c | 60 +
> > drivers/nfc/s3fwrn5/phy_common.h | 31 +++
> > 4 files changed, 129 insertions(+), 78 deletions(-)
> > create mode 100644 drivers/nfc/s3fwrn5/phy_common.c
> > create mode 100644 drivers/nfc/s3fwrn5/phy_common.h
> >
> > diff --git a/drivers/nfc/s3fwrn5/Makefile b/drivers/nfc/s3fwrn5/Makefile
> > index d0ffa35..a5279c6 100644
> > --- a/drivers/nfc/s3fwrn5/Makefile
> > +++ b/drivers/nfc/s3fwrn5/Makefile
> > @@ -4,7 +4,7 @@
> > #
> >
> > s3fwrn5-objs = core.o firmware.o nci.o
> > -s3fwrn5_i2c-objs = i2c.o
> > +s3fwrn5_i2c-objs = i2c.o phy_common.o
>
> Thanks for the changes.
>
> Shouldn't this be part of s3fwrn5.ko? Otherwise you would duplicate the
> objects in two modules.
>
Okay. It could be better to avoid the duplication.
I will try to move phy_common.c to s3fwrn5.ko.
> >
> > obj-$(CONFIG_NFC_S3FWRN5) += s3fwrn5.o
> > obj-$(CONFIG_NFC_S3FWRN5_I2C) += s3fwrn5_i2c.o
> > diff --git a/drivers/nfc/s3fwrn5/i2c.c b/drivers/nfc/s3fwrn5/i2c.c
> > index 9a64eea..207f970 100644
> > --- a/drivers/nfc/s3fwrn5/i2c.c
> > +++ b/drivers/nfc/s3fwrn5/i2c.c
> > @@ -16,74 +16,30 @@
> > #include
> >
> > #include "s3fwrn5.h"
> > +#include "phy_common.h"
> >
> > #define S3FWRN5_I2C_DRIVER_NAME "s3fwrn5_i2c"
> >
> > -#define S3FWRN5_EN_WAIT_TIME 20
> > -
> > struct s3fwrn5_i2c_phy {
> > + struct phy_common common;
> > struct i2c_client *i2c_dev;
> > - struct nci_dev *ndev;
> > -
> > - int gpio_en;
> > - int gpio_fw_wake;
> > -
> > - struct mutex mutex;
> >
> > - enum s3fwrn5_mode mode;
> > unsigned int irq_skip:1;
> > };
> >
> > -static void s3fwrn5_i2c_set_wake(void *phy_id, bool wake)
> > -{
> > - struct s3fwrn5_i2c_phy *phy = phy_id;
> > -
> > - mutex_lock(>mutex);
> > - gpio_set_value(phy->gpio_fw_wake, wake);
> > - msleep(S3FWRN5_EN_WAIT_TIME);
> > - mutex_unlock(>mutex);
> > -}
> > -
> > static void s3fwrn5_i2c_set_mode(void *phy_id, enum s3fwrn5_mode mode)
> > {
> > struct s3fwrn5_i2c_phy *phy = phy_id;
> >
> > - mutex_lock(>mutex);
> > + mutex_lock(>common.mutex);
> >
> > - if (phy->mode == mode)
> > + if (s3fwrn5_phy_power_ctrl(>common, mode) == false)
> > goto out;
> >
> > - phy->mode = mode;
> > -
> > - gpio_set_value(phy->gpio_en, 1);
> > - gpio_set_value(phy->gpio_fw_wake, 0);
> > - if (mode == S3FWRN5_MODE_FW)
> > - gpio_set_value(phy->gpio_fw_wake, 1);
> > -
> > - if (mode != S3FWRN5_MODE_COLD) {
> > - msleep(S3FWRN5_EN_WAIT_TIME);
> > - gpio_set_value(phy->gpio_en, 0);
> > - msleep(S3FWRN5_EN_WAIT_TIME);
> > - }
> > -
> > phy->irq_skip = true;
> >
> > out:
> > - mutex_unlock(>mutex);
> > -}
> > -
> > -static enum s3fwrn5_mode s3fwrn5_i2c_get_mode(void *phy_id)
> > -{
> > - struct s3fwrn5_i2c_phy *phy = phy_id;
> > - enum s3fwrn5_mode mode;
> > -
> > - mutex_lock(>mutex);
> > -
> > - mode = phy->mode;
> > -
> > - mutex_unlock(>mutex);
> > -
> > - return mode;
> > + mutex_unlock(>common.mutex);
> > }
> >
> > static int s3fwrn5_i2c_write(void *phy_id, struct sk_buff *skb)
> > @@ -91,7 +47,7 @@ static int s3fwrn5_i2c_write(void *phy_id, struct sk_buff
> > *skb)
> > struct s3fwrn5_i2c_phy *phy = phy_id;
> > int ret;
> >
> > - mutex_lock(>mutex);
> > + mutex_lock(>common.mutex);
> >
> > phy->irq_skip = false;
> >
> > @@ -102,7 +58,7 @@ static int s3fwrn5_i2c_write(void *phy_id, struct
> > sk_buff *skb)
> > ret = i2c_master_send(phy->i2c_dev, skb->data, skb->len);
> > }
> >
> > - mutex_unlock(>mutex);
> > + mutex_unlock(>common.mutex);
> >
> > if (ret < 0)
> > return ret;
> > @@ -114,9 +70,9 @@ static int s3fwrn5_i2c_write(void *phy_id, struct
> > sk_buff *skb)
> > }
> >
> > static const struct s3fwrn5_phy_ops i2c_phy_ops = {
> > - .set_wake = s3fwrn5_i2c_set_wake,
> > + .set_wake = s3fwrn5_phy_set_wake,
> > .set_mode = s3fwrn5_i2c_set_mode,
> > - .get_mode = s3fwrn5_i2c_get_mode,
> > + .get_mode = s3fwrn5_phy_get_mode,
> > .write = s3fwrn5_i2c_write,
> > };
> >
> > @@ -128,7 +84,7 @@ static int s3fwrn5_i2c_read(struct
Re: [PATCH v2 1/2] KVM: SVM: Move asid to vcpu_svm
From: Ashish Kalra This patch breaks SEV guests. The patch stores current ASID in struct vcpu_svm and only moves it to VMCB in svm_vcpu_run(), but by doing so, the ASID allocated for SEV guests and setup in vmcb->control.asid by pre_sev_run() gets over-written by this ASID stored in struct vcpu_svm and hence, VMRUN fails as SEV guest is bound/activated on a different ASID then the one overwritten in vmcb->control.asid at VMRUN. For example, asid#1 was activated for SEV guest and then vmcb->control.asid is overwritten with asid#0 (svm->asid) as part of this patch in svm_vcpu_run() and hence VMRUN fails.
Re: scheduling while atomic in z3fold
On Sun, 2020-11-29 at 08:48 +0100, Mike Galbraith wrote: > On Sun, 2020-11-29 at 07:41 +0100, Mike Galbraith wrote: > > On Sat, 2020-11-28 at 15:27 +0100, Oleksandr Natalenko wrote: > > > > > > > > Shouldn't the list manipulation be protected with > > > > > local_lock+this_cpu_ptr instead of get_cpu_ptr+spin_lock? > > > > > > Totally untested: > > > > Hrm, the thing doesn't seem to care deeply about preemption being > > disabled, so adding another lock may be overkill. It looks like you > > could get the job done via migrate_disable()+this_cpu_ptr(). > > There is however an ever so tiny chance that I'm wrong about that :) Or not, your local_lock+this_cpu_ptr version exploded too. Perhaps there's a bit of non-rt related racy racy going on in zswap thingy that makes swap an even less wonderful idea for RT than usual. crash.rt> bt -s PID: 32399 TASK: 8e4528cd8000 CPU: 4 COMMAND: "cc1" #0 [9f0f1228f488] machine_kexec+366 at 8c05f87e #1 [9f0f1228f4d0] __crash_kexec+210 at 8c14c052 #2 [9f0f1228f590] crash_kexec+48 at 8c14d240 #3 [9f0f1228f5a0] oops_end+202 at 8c02680a #4 [9f0f1228f5c0] exc_general_protection+403 at 8c8be413 #5 [9f0f1228f650] asm_exc_general_protection+30 at 8ca00a0e #6 [9f0f1228f6d8] __z3fold_alloc+118 at 8c2b4ea6 #7 [9f0f1228f760] z3fold_zpool_malloc+115 at 8c2b56c3 #8 [9f0f1228f7c8] zswap_frontswap_store+789 at 8c27d335 #9 [9f0f1228f828] __frontswap_store+110 at 8c27bafe #10 [9f0f1228f858] swap_writepage+55 at 8c273b17 #11 [9f0f1228f870] shmem_writepage+612 at 8c232964 #12 [9f0f1228f8a8] pageout+210 at 8c225f12 #13 [9f0f1228f928] shrink_page_list+2428 at 8c22744c #14 [9f0f1228f9c0] shrink_inactive_list+534 at 8c229746 #15 [9f0f1228fa68] shrink_lruvec+927 at 8c22a35f #16 [9f0f1228fb78] shrink_node+567 at 8c22a7d7 #17 [9f0f1228fbf8] do_try_to_free_pages+185 at 8c22ad39 #18 [9f0f1228fc40] try_to_free_pages+201 at 8c22c239 #19 [9f0f1228fcd0] __alloc_pages_slowpath.constprop.111+1056 at 8c26eb70 #20 [9f0f1228fda8] __alloc_pages_nodemask+786 at 8c26f7e2 #21 [9f0f1228fe00] alloc_pages_vma+309 at 8c288f15 #22 [9f0f1228fe40] handle_mm_fault+1687 at 8c24ee97 #23 [9f0f1228fef8] exc_page_fault+821 at 8c8c1be5 #24 [9f0f1228ff50] asm_exc_page_fault+30 at 8ca00ace RIP: 010fea3b RSP: 7ffc88ad5a50 RFLAGS: 00010206 RAX: 7f4a548d1638 RBX: 7f4a5c0c5000 RCX: RDX: 0002 RSI: 000f RDI: 00018001 RBP: 7f4a5547a000 R8: 00018000 R9: 0024 R10: 7f4a5523a000 R11: 00098628 R12: 7f4a548d1638 R13: 7f4a54ab1478 R14: 5002ac29 R15: ORIG_RAX: CS: 0033 SS: 002b crash.rt>
Re: [PATCH v7] checkpatch: add fix option for LOGICAL_CONTINUATIONS
On 23/11/20 3:58 pm, Aditya Srivastava wrote:
> Currently, checkpatch warns if logical continuations are placed at the
> start of a line and not at the end of previous line.
>
> E.g., running checkpatch on commit 3485507fc272 ("staging:
> bcm2835-camera: Reduce length of enum names") reports:
>
> CHECK:LOGICAL_CONTINUATIONS: Logical continuations should be on the
> previous line
> + if (!ret
> + && camera_port ==
>
> Provide a simple fix by inserting logical operator at the last
> non-comment, non-whitespace char of the previous line and removing from
> current line, if both the lines are additions(ie start with '+')
>
> Signed-off-by: Aditya Srivastava
> ---
> changes in v2: quote $operator at substitution
>
> changes in v3: add a check for previous line ending with comment;
> If so, insert $operator at the last non-comment, non-whitespace char of the
> previous line
>
> changes in v4: improve the matching mechanism by matching line termination at
> comment or white space;
> insert the operator before comments (if any) separated by a whitespace;
> append the comment and its pre-whitespace after the inserted operator (if
> comment was present),
> ie if no comment was present nothing will be inserted after the operator
>
> changes in v5: improve regex for comment and line end with '$;'
>
> changes in v6: remove if-check; modify commit message
>
> changes in v7: add an extra '$' symbol at '$fixed[$fixlinenr - 1]' regex
> substitution to ensure match at line end
>
> scripts/checkpatch.pl | 12 ++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index 5b1a5a65e69a..fb3c50e0bde2 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -3553,8 +3553,16 @@ sub process {
>
> # check for && or || at the start of a line
> if ($rawline =~ /^\+\s*(&&|\|\|)/) {
> - CHK("LOGICAL_CONTINUATIONS",
> - "Logical continuations should be on the previous
> line\n" . $hereprev);
> + my $operator = $1;
> + if (CHK("LOGICAL_CONTINUATIONS",
> + "Logical continuations should be on the
> previous line\n" . $hereprev) &&
> + $fix && $prevrawline =~ /^\+/) {
> + # insert logical operator at last non-comment,
> non-whitepsace char on previous line
> + $prevline =~ /[\s$;]*$/;
> + my $line_end = substr($prevrawline, $-[0]);
> + $fixed[$fixlinenr - 1] =~ s/\Q$line_end\E$/
> $operator$line_end/;
> + $fixed[$fixlinenr] =~ s/\Q$operator\E\s*//;
> + }
> }
>
> # check indentation starts on a tab stop
>
Hi Joe
You probably missed this patch. Please review :)
Thanks
Aditya
Re: [RFC PATCH v0 00/19] x86/insn: Add an insn_decode() API
On Fri, 27 Nov 2020 09:45:39 -0800 Andy Lutomirski wrote: > On Tue, Nov 24, 2020 at 9:46 AM Borislav Petkov wrote: > > > > On Tue, Nov 24, 2020 at 11:19:33AM +0100, Borislav Petkov wrote: > > > In any case, at least the case where I give it > > > > > > 0x48 0xcf 0x48 0x83 > > > > > > and say that buf size is 4, should return an error because the second > > > insn is incomplete. So I need to go look at that now. > > > > Ok, got it: > > > > ./arch/x86/tools/insn_sanity: Success: decoded and checked 1 random > > instructions with 0 errors (seed:0x826fdf9c) > > insn buffer: > > 0x48 0xcf 0x48 0x83 0x90 0x90 0x90 0x90 0x90 0x90 0x90 0x90 0x90 0x90 0x90 > > supplied buf size: 15, ret 0 > > supplied buf size: 2, ret 0 > > supplied buf size: 3, ret 0 > > supplied buf size: 4, ret 0 > > supplied buf size: 1, ret -22 > > > > the current decoder simply decodes the *first* insn in the buffer it > > encounters and that's it. > > > > When you give it a buffer of size smaller than the first instruction: > > > > supplied buf size: 1, ret -22 > > > > while the first insn is 2 bytes long: > > > > 0x48 0xcf (IRETQ) > > > > then it signals an error. > > > > Andy, does that work for your use cases? > > Is -22 (-EINVAL) the same error it returns if you pass in garbage? > How hard would it be to teach it to return a different error code when > the buffer is too small? > Good point. I think we can return, e.g. -EFAULT if we failed in get_next(). Then, we can read out next page, for example. Thank you, -- Masami Hiramatsu
[PATCH] Input: Fix a ref counting issue
In case of a managed resource, 'devm_input_device_release()' already has a
'input_put_device(dev)' call.
Avoid a double reference decrement by explicitly calling
'input_put_device()' only on non-managed input device.
Fixes: 2be975c6d920 ("Input: introduce managed input devices (add devres
support)")
Signed-off-by: Christophe JAILLET
---
This patch is completely speculative and compile tested only.
---
drivers/input/input.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/input/input.c b/drivers/input/input.c
index 3cfd2c18eebd..c09c9f020667 100644
--- a/drivers/input/input.c
+++ b/drivers/input/input.c
@@ -1920,7 +1920,8 @@ void input_free_device(struct input_dev *dev)
devm_input_device_release,
devm_input_device_match,
dev));
- input_put_device(dev);
+ else
+ input_put_device(dev);
}
}
EXPORT_SYMBOL(input_free_device);
--
2.27.0
[PATCH] HID: elan: Fix some error handling path
'input' is a managed resource allocated earlier in the function by:
input = devm_input_allocate_device(>dev);
There is no need to explicitly free it. This would lead to a double
reference decrement.
Fixes: b7429ea53d6c ("HID: elan: Fix memleak in elan_input_configured")
Fixes: 9a6a4193d65b ("HID: Add driver for USB ELAN Touchpad")
Signed-off-by: Christophe JAILLET
---
drivers/hid/hid-elan.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/hid/hid-elan.c b/drivers/hid/hid-elan.c
index dae193749d44..8587f9d2fffb 100644
--- a/drivers/hid/hid-elan.c
+++ b/drivers/hid/hid-elan.c
@@ -188,7 +188,6 @@ static int elan_input_configured(struct hid_device *hdev,
struct hid_input *hi)
ret = input_mt_init_slots(input, ELAN_MAX_FINGERS, INPUT_MT_POINTER);
if (ret) {
hid_err(hdev, "Failed to init elan MT slots: %d\n", ret);
- input_free_device(input);
return ret;
}
@@ -200,7 +199,6 @@ static int elan_input_configured(struct hid_device *hdev,
struct hid_input *hi)
hid_err(hdev, "Failed to register elan input device: %d\n",
ret);
input_mt_destroy_slots(input);
- input_free_device(input);
return ret;
}
--
2.27.0
Re: [PATCH v2 3/4] input: touchscreen: usbtouchscreen: Remove unused variable 'ret'
On Sat, 28 Nov 2020, Dmitry Torokhov wrote:
> Hi Lee,
>
> On Thu, Nov 26, 2020 at 01:36:06PM +, Lee Jones wrote:
> > Fixes the following W=1 kernel build warning(s):
> >
> > drivers/input/touchscreen/usbtouchscreen.c: In function ‘nexio_read_data’:
> > drivers/input/touchscreen/usbtouchscreen.c:1052:50: warning: variable
> > ‘ret’ set but not used [-Wunused-but-set-variable]
> >
> > Cc: Dmitry Torokhov
> > Cc: Henrik Rydberg
> > Cc: James Hilliard
> > Cc: Daniel Ritz
> > Cc: linux-in...@vger.kernel.org
> > Signed-off-by: Lee Jones
> > ---
> > drivers/input/touchscreen/usbtouchscreen.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/input/touchscreen/usbtouchscreen.c
> > b/drivers/input/touchscreen/usbtouchscreen.c
> > index 397cb1d3f481b..c3b7130cd9033 100644
> > --- a/drivers/input/touchscreen/usbtouchscreen.c
> > +++ b/drivers/input/touchscreen/usbtouchscreen.c
> > @@ -1049,7 +1049,7 @@ static int nexio_read_data(struct usbtouch_usb
> > *usbtouch, unsigned char *pkt)
> > unsigned int data_len = be16_to_cpu(packet->data_len);
> > unsigned int x_len = be16_to_cpu(packet->x_len);
> > unsigned int y_len = be16_to_cpu(packet->y_len);
> > - int x, y, begin_x, begin_y, end_x, end_y, w, h, ret;
> > + int x, y, begin_x, begin_y, end_x, end_y, w, h;
> >
> > /* got touch data? */
> > if ((pkt[0] & 0xe0) != 0xe0)
> > @@ -1061,7 +1061,7 @@ static int nexio_read_data(struct usbtouch_usb
> > *usbtouch, unsigned char *pkt)
> > x_len -= 0x80;
> >
> > /* send ACK */
> > - ret = usb_submit_urb(priv->ack, GFP_ATOMIC);
> > + usb_submit_urb(priv->ack, GFP_ATOMIC);
>
> I thought you were going to add error handling here?
Hmm... I thought I handed all of the review comments!
Will look into this again on Monday.
> > if (!usbtouch->type->max_xc) {
> > usbtouch->type->max_xc = 2 * x_len;
>
> Thanks.
>
--
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
