Re: linux-next: manual merge of the counters tree with the ipmi tree
Hi all,
On Mon, 12 Oct 2020 19:13:40 +1100 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the counters tree got a conflict in:
>
> drivers/char/ipmi/ipmi_msghandler.c
>
> between commit:
>
> f8910ffa81b0 ("ipmi:msghandler: retry to get device id on an error")
>
> from the ipmi tree and commit:
>
> dc87264ac991 ("drivers/char/ipmi: convert stats to use counter_atomic32")
>
> from the counters tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> diff --cc drivers/char/ipmi/ipmi_msghandler.c
> index 8774a3b8ff95,36c0b1be22fb..
> --- a/drivers/char/ipmi/ipmi_msghandler.c
> +++ b/drivers/char/ipmi/ipmi_msghandler.c
> @@@ -34,7 -34,7 +34,8 @@@
> #include
> #include
> #include
> +#include
> + #include
>
> #define IPMI_DRIVER_VERSION "39.2"
>
This is now a conflict between the counters tree and Linus' tree.
--
Cheers,
Stephen Rothwell
pgpLEgjXN9yNE.pgp
Description: OpenPGP digital signature
Re: [PATCH v6 2/2] PCI/ERR: Split the fatal and non-fatal error recovery handling
On 10/14/20 10:05 PM, Ethan Zhao wrote:
On Thu, Oct 15, 2020 at 11:04 AM Kuppuswamy, Sathyanarayanan
wrote:
On 10/14/20 6:58 PM, Ethan Zhao wrote:
On Thu, Oct 15, 2020 at 1:06 AM Kuppuswamy, Sathyanarayanan
wrote:
On 10/14/20 8:07 AM, Ethan Zhao wrote:
On Wed, Oct 14, 2020 at 5:00 PM Kuppuswamy Sathyanarayanan
wrote:
Commit bdb5ac85777d ("PCI/ERR: Handle fatal error recovery")
merged fatal and non-fatal error recovery paths, and also made
recovery code depend on hotplug handler for "remove affected
device + rescan" support. But this change also complicated the
error recovery path and which in turn led to the following
issues.
1. We depend on hotplug handler for removing the affected
devices/drivers on DLLSC LINK down event (on DPC event
trigger) and DPC handler for handling the error recovery. Since
both handlers operate on same set of affected devices, it leads
to race condition, which in turn leads to NULL pointer
exceptions or error recovery failures.You can find more details
about this issue in following link.
https://lore.kernel.org/linux-pci/20201007113158.48933-1-haifeng.z...@intel.com/T/#t
2. For non-hotplug capable devices fatal (DPC) error recovery
is currently broken. Current fatal error recovery implementation
relies on PCIe hotplug (pciehp) handler for detaching and
re-enumerating the affected devices/drivers. So when dealing with
non-hotplug capable devices, recovery code does not restore the state
of the affected devices correctly. You can find more details about
this issue in the following links.
https://lore.kernel.org/linux-pci/20200527083130.4137-1-zhiqiang@nxp.com/
https://lore.kernel.org/linux-pci/12115.1588207324@famine/
https://lore.kernel.org/linux-pci/0e6f89cd6b9e4a72293cc90fafe93487d7c2d295.158584.git.sathyanarayanan.kuppusw...@linux.intel.com/
In order to fix the above two issues, we should stop relying on hotplug
Yes, it doesn't rely on hotplug handler to remove and rescan the device,
but it couldn't prevent hotplug drivers from doing another replicated
removal/rescanning.
it doesn't make sense to leave another useless removal/rescanning there.
Maybe that's why these two paths were merged to one and made it rely on
hotplug.
No, as per PCIe spec, hotplug and DPC has no functional dependency. Hence
depending on it to handle some of its recovery function is in-correct and
would lead to issues in non-hotplug capable platforms (which is true
currently).
Though pciehp is not so hot/scalable and performance critical, but there
is per cpu thread to handle hot-plug operation. synchronize all threads
make them walk backwards for scalability.
DPC events does not happen in high frequency. So I don't think we should
It's holding global lock, once malfunction happens to one device and
it's driver,
the whole system, everyone holds it, would be blocked to work.
worry about the performance here. Even hotplug handler will hold this lock
when adding/removing the devices. So adding/removing devices is a serialized
You don't worry about performance, but if there is a requirement needs
more scalable
and reliable hotplug, the effect will be much harder. what to do then ? choose
another OS ?
As I have mentioned, all device creation/removal in PCI core code is already
protected by this lock (including hotplug code). So the multidomain performance
impact you mentioned should exist even now. All I am doing is, using the
same lock for protecting device removal/rescan in error recovery code.
drivers/pci/xen-pcifront.c:477: pci_lock_rescan_remove();
drivers/pci/xen-pcifront.c:567: pci_lock_rescan_remove();
drivers/pci/xen-pcifront.c:1064:pci_lock_rescan_remove();
drivers/pci/hotplug/rpaphp_core.c:498: pci_lock_rescan_remove();
drivers/pci/hotplug/rpaphp_core.c:520: pci_lock_rescan_remove();
drivers/pci/hotplug/s390_pci_hpc.c:70: pci_lock_rescan_remove();
drivers/pci/hotplug/shpchp_pci.c:31:pci_lock_rescan_remove();
drivers/pci/hotplug/shpchp_pci.c:73:pci_lock_rescan_remove();
drivers/pci/hotplug/pciehp_pci.c:39:pci_lock_rescan_remove();
drivers/pci/hotplug/pciehp_pci.c:96:pci_lock_rescan_remove();
drivers/pci/hotplug/acpiphp_glue.c:762: pci_lock_rescan_remove();
drivers/pci/hotplug/acpiphp_glue.c:787: pci_lock_rescan_remove();
drivers/pci/hotplug/acpiphp_glue.c:975: pci_lock_rescan_remove();
drivers/pci/hotplug/acpiphp_glue.c:1026:pci_lock_rescan_remove();
drivers/pci/hotplug/cpqphp_pci.c:75:pci_lock_rescan_remove();
drivers/pci/hotplug/cpqphp_pci.c:120: pci_lock_rescan_remove();
drivers/pci/hotplug/rpadlpar_core.c:361:pci_lock_rescan_remove();
drivers/pci/hotplug/pnv_php.c:513:
pci_lock_rescan_remove();
drivers/pci/hotplug/pnv_php.c:582: pci_lock_rescan_remove();
drivers/pci/hotplug/ibmphp_core.c:668: pci_lock_rescan_remove();
drivers/pci/hotplug/ibmphp_core.c:738: pci_lock_rescan_remove();
drivers/pci/hotplug/cpci_hotplug_pci.c:245:
Re: linux-next: manual merge of the akpm-current tree with the counters tree
Hi all,
On Mon, 12 Oct 2020 19:48:21 +1100 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the akpm-current tree got a conflict in:
>
> lib/Makefile
>
> between commit:
>
> 37a0dbf631f6 ("counters: Introduce counter_atomic* counters")
>
> from the counters tree and commit:
>
> ed7f5253e189 ("mm/page_alloc.c: fix freeing non-compound pages")
>
> from the akpm-current tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> diff --cc lib/Makefile
> index 95b357bb5f3c,1c7577b2e86a..
> --- a/lib/Makefile
> +++ b/lib/Makefile
> @@@ -99,7 -101,7 +101,8 @@@ obj-$(CONFIG_TEST_BLACKHOLE_DEV) += tes
> obj-$(CONFIG_TEST_MEMINIT) += test_meminit.o
> obj-$(CONFIG_TEST_LOCKUP) += test_lockup.o
> obj-$(CONFIG_TEST_HMM) += test_hmm.o
> +obj-$(CONFIG_TEST_COUNTERS) += test_counters.o
> + obj-$(CONFIG_TEST_FREE_PAGES) += test_free_pages.o
>
> #
> # CFLAGS for compiling floating point code inside the kernel. x86/Makefile
> turns
This is now a conflict between the counters tree and Linus' tree.
--
Cheers,
Stephen Rothwell
pgpoSKKTMTkXD.pgp
Description: OpenPGP digital signature
Dear Friend, My present internet connection is very slow in case you
Dear Friend, My present internet connection is very slow in case you received my email in your spam How are you today?.With due respect to your person and much sincerity of purpose,Well it is a pleasure to contact you on this regard and i pray that this will turn out to be everlasting relationship for both of us. However it's just my urgent need for a Foreign partner that made me to contact you for this Transaction,I got your contact from internet, while searching for a reliable someone that I can go into partnership with. I am Mrs.mcompola, from BURKINA FASO, West Africa .Presently i work in the Bank as bill and exchange manager. I have the opportunity of transferring the left over fund $5.4 Million us dollars of one of my Bank clients who died in the collapsing of the world trade center on september 11th 2001.I have placed this fund to and escrow account without name of beneficiary.i will use my position here in the bank to effect a hitch free transfer of the fund to your bank account and there will be no trace. I agree that 40% of this money will be for you as my foriegn partner,50% for me while 10% will be for the expenses that will occur in this transaction .If you are really interested in my proposal further details of the Transfer will be forwarded unto you as soon as I receive your willingness mail for successful transfer. Yours Faithfully, mrs.mcompola...@gmail.com
Re: [PATCH v3 3/8] of/address: Introduce of_dma_get_max_cpu_address()
> +phys_addr_t __init of_dma_get_max_cpu_address(struct device_node *np)
> +{
> + phys_addr_t max_cpu_addr = PHYS_ADDR_MAX;
> + struct of_range_parser parser;
> + phys_addr_t subtree_max_addr;
> + struct device_node *child;
> + phys_addr_t cpu_end = 0;
> + struct of_range range;
> + const __be32 *ranges;
> + int len;
> +
> + if (!np)
> + np = of_root;
Requiring of_root to be passed explicitly would seem more natural
to me than the magic NULL argument. There doesn't seem to be any
precedent for that kind of calling convention either.
Re: [PATCH v3 8/8] mm: Update DMA zones description
On Wed, Oct 14, 2020 at 09:12:10PM +0200, Nicolas Saenz Julienne wrote:
> The default behavior for arm64 changed, so reflect that.
>
> Signed-off-by: Nicolas Saenz Julienne
> Acked-by: Catalin Marinas
> ---
> include/linux/mmzone.h | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
> index fb3bf696c05e..4ee2306351b9 100644
> --- a/include/linux/mmzone.h
> +++ b/include/linux/mmzone.h
> @@ -363,8 +363,9 @@ enum zone_type {
>* - arm only uses ZONE_DMA, the size, up to 4G, may vary depending on
>*the specific device.
>*
> - * - arm64 has a fixed 1G ZONE_DMA and ZONE_DMA32 for the rest of the
> - *lower 4G.
> + * - arm64 uses a single 4GB ZONE_DMA, except on the Raspberry Pi 4,
> + *in which ZONE_DMA covers the first GB and ZONE_DMA32 the rest of
> + *the lower 4GB.
Honestly I think this comment just needs to go away. We can't really list
every setup in a comment in common code.
Re: [PATCH v3 6/8] arm64: mm: Set ZONE_DMA size based on devicetree's dma-ranges
On Wed, Oct 14, 2020 at 09:12:08PM +0200, Nicolas Saenz Julienne wrote: > + zone_dma_bits = min(zone_dma_bits, > + (unsigned > int)ilog2(of_dma_get_max_cpu_address(NULL))); Plase avoid pointlessly long lines. Especially if it is completely trivial by using either min_t or not overindenting like here.
Re: Use after free in bcm2835_spi_remove()
[cc += Sascha]
On Wed, Oct 14, 2020 at 09:25:05PM +0100, Mark Brown wrote:
> > On Wed, Oct 14, 2020 at 04:09:12PM +0200, Lukas Wunner wrote:
> > > Apparently the problem is that spi_unregister_controller() drops the
> > > last ref on the controller, causing it to be freed, and afterwards we
> > > access the controller's private data, which is part of the same
> > > allocation as struct spi_controller:
>
> Right, the proposed patch is yet another way to fix the issue - it all
> comes back to the fact that you shouldn't be using the driver data after
> unregistering if it was allocated as part of allocating the controller.
> This framework feature is unfortunately quite error prone.
How about holding a ref on the controller as long as the SPI driver
is bound to the controller's parent device? See below for a patch,
compile-tested only for lack of an SPI-equipped machine.
Makes sense or dumb idea?
If this approach is deemed to be a case of "midlayer fallacy",
we could alternatively do this in a library function which drivers
opt-in to. Or, given that the majority of drivers seems to be affected,
make it the default and allow drivers to opt-out.
-- >8 --
diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index 0cab239..5afa275 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -2399,6 +2399,11 @@ static ssize_t slave_store(struct device *dev, struct
device_attribute *attr,
extern struct class spi_slave_class; /* dummy */
#endif
+static void __spi_controller_put(void *ctlr)
+{
+ spi_controller_put(ctlr);
+}
+
/**
* __spi_alloc_controller - allocate an SPI master or slave controller
* @dev: the controller, possibly using the platform_bus
@@ -2414,6 +2419,7 @@ static ssize_t slave_store(struct device *dev, struct
device_attribute *attr,
* This call is used only by SPI controller drivers, which are the
* only ones directly touching chip registers. It's how they allocate
* an spi_controller structure, prior to calling spi_register_controller().
+ * The structure is accessible as long as the SPI driver is bound to @dev.
*
* This must be called from context that can sleep.
*
@@ -2429,6 +2435,7 @@ struct spi_controller *__spi_alloc_controller(struct
device *dev,
{
struct spi_controller *ctlr;
size_t ctlr_size = ALIGN(sizeof(*ctlr), dma_get_cache_alignment());
+ int ret;
if (!dev)
return NULL;
@@ -2449,6 +2456,13 @@ struct spi_controller *__spi_alloc_controller(struct
device *dev,
pm_suspend_ignore_children(>dev, true);
spi_controller_set_devdata(ctlr, (void *)ctlr + ctlr_size);
+ spi_controller_get(ctlr);
+ ret = devm_add_action(dev, __spi_controller_put, ctlr);
+ if (ret) {
+ kfree(ctlr);
+ return NULL;
+ }
+
return ctlr;
}
EXPORT_SYMBOL_GPL(__spi_alloc_controller);
Re: linux-next: manual merge of the akpm-current tree with the kunit-next tree
Hi all,
On Mon, 12 Oct 2020 19:56:49 +1100 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the akpm-current tree got a conflict in:
>
> lib/kunit/test.c
>
> between commit:
>
> 45dcbb6f5ef7 ("kunit: test: add test plan to KUnit TAP format")
>
> from the kunit-next tree and commit:
>
> e685acc91080 ("KUnit: KASAN Integration")
>
> from the akpm-current tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> diff --cc lib/kunit/test.c
> index de07876b6601,dcc35fd30d95..
> --- a/lib/kunit/test.c
> +++ b/lib/kunit/test.c
> @@@ -15,11 -16,16 +16,6 @@@
> #include "string-stream.h"
> #include "try-catch-impl.h"
>
> - static void kunit_set_failure(struct kunit *test)
> -static void kunit_print_tap_version(void)
> --{
> - WRITE_ONCE(test->success, false);
> -static bool kunit_has_printed_tap_version;
> -
> -if (!kunit_has_printed_tap_version) {
> -pr_info("TAP version 14\n");
> -kunit_has_printed_tap_version = true;
> -}
> --}
> --
> /*
>* Append formatted message to log, size of which is limited to
>* KUNIT_LOG_SIZE bytes (including null terminating byte).
This is now a conflict between the kunit-next tree and Linus' tree.
--
Cheers,
Stephen Rothwell
pgpst1GVOBQDP.pgp
Description: OpenPGP digital signature
Re: [PATCH v3 5/8] dma-direct: Turn zone_dma_bits default value into a define
On Wed, Oct 14, 2020 at 09:12:07PM +0200, Nicolas Saenz Julienne wrote: > Set zone_dma_bits default value through a define so as for architectures > to be able to override it with their default value. Architectures can do that already by assigning a value to zone_dma_bits at runtime. I really do not want to add the extra clutter.
PLEASE TAKE NOTE!
Hello friend! I would like to contact you personally for an important proposal that could of interest to you. I send this email only to know if this email address is functional. I have something very important to discuss with you. Contact me for details by: Email: fernrodyup1...@aol.com with your direct contacts. Kind regards. Maria Carmen Gutierrez
[PATCH v4] remoteproc/mediatek: Add support for mt8192 SCP
Add support for mt8192 SCP.
Signed-off-by: Pi-Hsun Shih
Reviewed-by: Tzung-Bi Shih
---
Change since v3:
* Remove unnecessary barrier and readl in mt8192_scp_before_load, which
also fixes build failure on linux-next because of COMPILE_TEST trying
to compile this on other platforms.
Change since v2:
* Inline scp_reset_assert / scp_reset_deassert.
Change since v1:
* Remove unused register definitions.
---
drivers/remoteproc/mtk_common.h | 32 +
drivers/remoteproc/mtk_scp.c | 200 +--
drivers/remoteproc/mtk_scp_ipi.c | 6 +-
3 files changed, 200 insertions(+), 38 deletions(-)
diff --git a/drivers/remoteproc/mtk_common.h b/drivers/remoteproc/mtk_common.h
index 0066c83636d0..47b4561443a9 100644
--- a/drivers/remoteproc/mtk_common.h
+++ b/drivers/remoteproc/mtk_common.h
@@ -32,6 +32,23 @@
#define MT8183_SCP_CACHESIZE_8KB BIT(8)
#define MT8183_SCP_CACHE_CON_WAYEN BIT(10)
+#define MT8192_L2TCM_SRAM_PD_0 0x210C0
+#define MT8192_L2TCM_SRAM_PD_1 0x210C4
+#define MT8192_L2TCM_SRAM_PD_2 0x210C8
+#define MT8192_L1TCM_SRAM_PDN 0x2102C
+#define MT8192_CPU0_SRAM_PD0x21080
+
+#define MT8192_SCP2APMCU_IPC_SET 0x24080
+#define MT8192_SCP2APMCU_IPC_CLR 0x24084
+#define MT8192_SCP_IPC_INT_BIT BIT(0)
+#define MT8192_SCP2SPM_IPC_CLR 0x24094
+#define MT8192_GIPC_IN_SET 0x24098
+#define MT8192_HOST_IPC_INT_BITBIT(0)
+
+#define MT8192_CORE0_SW_RSTN_CLR 0x3
+#define MT8192_CORE0_SW_RSTN_SET 0x30004
+#define MT8192_CORE0_WDT_CFG 0x30034
+
#define SCP_FW_VER_LEN 32
#define SCP_SHARE_BUFFER_SIZE 288
@@ -50,6 +67,19 @@ struct scp_ipi_desc {
void *priv;
};
+struct mtk_scp;
+
+struct mtk_scp_of_data {
+ int (*scp_before_load)(struct mtk_scp *scp);
+ void (*scp_irq_handler)(struct mtk_scp *scp);
+ void (*scp_reset_assert)(struct mtk_scp *scp);
+ void (*scp_reset_deassert)(struct mtk_scp *scp);
+ void (*scp_stop)(struct mtk_scp *scp);
+
+ u32 host_to_scp_reg;
+ u32 host_to_scp_int_bit;
+};
+
struct mtk_scp {
struct device *dev;
struct rproc *rproc;
@@ -58,6 +88,8 @@ struct mtk_scp {
void __iomem *sram_base;
size_t sram_size;
+ const struct mtk_scp_of_data *data;
+
struct mtk_share_obj __iomem *recv_buf;
struct mtk_share_obj __iomem *send_buf;
struct scp_run run;
diff --git a/drivers/remoteproc/mtk_scp.c b/drivers/remoteproc/mtk_scp.c
index ac13e7b046a6..f8c54a0b33fc 100644
--- a/drivers/remoteproc/mtk_scp.c
+++ b/drivers/remoteproc/mtk_scp.c
@@ -2,7 +2,6 @@
//
// Copyright (c) 2019 MediaTek Inc.
-#include
#include
#include
#include
@@ -124,9 +123,6 @@ static int scp_ipi_init(struct mtk_scp *scp)
size_t send_offset = SCP_FW_END - sizeof(struct mtk_share_obj);
size_t recv_offset = send_offset - sizeof(struct mtk_share_obj);
- /* Disable SCP to host interrupt */
- writel(MT8183_SCP_IPC_INT_BIT, scp->reg_base + MT8183_SCP_TO_HOST);
-
/* shared buffer initialization */
scp->recv_buf =
(struct mtk_share_obj __iomem *)(scp->sram_base + recv_offset);
@@ -138,7 +134,7 @@ static int scp_ipi_init(struct mtk_scp *scp)
return 0;
}
-static void scp_reset_assert(const struct mtk_scp *scp)
+static void mt8183_scp_reset_assert(struct mtk_scp *scp)
{
u32 val;
@@ -147,7 +143,7 @@ static void scp_reset_assert(const struct mtk_scp *scp)
writel(val, scp->reg_base + MT8183_SW_RSTN);
}
-static void scp_reset_deassert(const struct mtk_scp *scp)
+static void mt8183_scp_reset_deassert(struct mtk_scp *scp)
{
u32 val;
@@ -156,17 +152,19 @@ static void scp_reset_deassert(const struct mtk_scp *scp)
writel(val, scp->reg_base + MT8183_SW_RSTN);
}
-static irqreturn_t scp_irq_handler(int irq, void *priv)
+static void mt8192_scp_reset_assert(struct mtk_scp *scp)
{
- struct mtk_scp *scp = priv;
- u32 scp_to_host;
- int ret;
+ writel(1, scp->reg_base + MT8192_CORE0_SW_RSTN_SET);
+}
- ret = clk_prepare_enable(scp->clk);
- if (ret) {
- dev_err(scp->dev, "failed to enable clocks\n");
- return IRQ_NONE;
- }
+static void mt8192_scp_reset_deassert(struct mtk_scp *scp)
+{
+ writel(1, scp->reg_base + MT8192_CORE0_SW_RSTN_CLR);
+}
+
+static void mt8183_scp_irq_handler(struct mtk_scp *scp)
+{
+ u32 scp_to_host;
scp_to_host = readl(scp->reg_base + MT8183_SCP_TO_HOST);
if (scp_to_host & MT8183_SCP_IPC_INT_BIT)
@@ -177,6 +175,40 @@ static irqreturn_t scp_irq_handler(int irq, void *priv)
/* SCP won't send another interrupt until we set SCP_TO_HOST to 0. */
writel(MT8183_SCP_IPC_INT_BIT | MT8183_SCP_WDT_INT_BIT,
scp->reg_base + MT8183_SCP_TO_HOST);
+}
+
+static void mt8192_scp_irq_handler(struct
[PATCH 2/2] ASoC: fsl_spdif: Add support for i.MX8QM platform
On i.MX8QM, there are separate interrupts for TX and RX.
As the EDMA can't be configured to swing back to first FIFO
after writing the second FIFO, so we need to force the burst
size to be 2 on i.MX8QM. And EDMA don't support to shift
the data from S24_LE to S16_LE, so the supported TX format
is also different on i.MX8QM.
Signed-off-by: Shengjiu Wang
---
sound/soc/fsl/fsl_spdif.c | 57 ---
1 file changed, 47 insertions(+), 10 deletions(-)
diff --git a/sound/soc/fsl/fsl_spdif.c b/sound/soc/fsl/fsl_spdif.c
index f41496cf5b63..5fa178f3f497 100644
--- a/sound/soc/fsl/fsl_spdif.c
+++ b/sound/soc/fsl/fsl_spdif.c
@@ -49,10 +49,18 @@ static u8 srpc_dpll_locked[] = { 0x0, 0x1, 0x2, 0x3, 0x4,
0xa, 0xb };
* @imx: for imx platform
* @shared_root_clock: flag of sharing a clock source with others;
* so the driver shouldn't set root clock rate
+ * @interrupts: interrupt number
+ * @tx_burst: tx maxburst size
+ * @rx_burst: rx maxburst size
+ * @tx_formats: tx supported data format
*/
struct fsl_spdif_soc_data {
bool imx;
bool shared_root_clock;
+ u32 interrupts;
+ u32 tx_burst;
+ u32 rx_burst;
+ u64 tx_formats;
};
/*
@@ -128,16 +136,38 @@ struct fsl_spdif_priv {
static struct fsl_spdif_soc_data fsl_spdif_vf610 = {
.imx = false,
.shared_root_clock = false,
+ .interrupts = 1,
+ .tx_burst = FSL_SPDIF_TXFIFO_WML,
+ .rx_burst = FSL_SPDIF_RXFIFO_WML,
+ .tx_formats = FSL_SPDIF_FORMATS_PLAYBACK,
};
static struct fsl_spdif_soc_data fsl_spdif_imx35 = {
.imx = true,
.shared_root_clock = false,
+ .interrupts = 1,
+ .tx_burst = FSL_SPDIF_TXFIFO_WML,
+ .rx_burst = FSL_SPDIF_RXFIFO_WML,
+ .tx_formats = FSL_SPDIF_FORMATS_PLAYBACK,
};
static struct fsl_spdif_soc_data fsl_spdif_imx6sx = {
.imx = true,
.shared_root_clock = true,
+ .interrupts = 1,
+ .tx_burst = FSL_SPDIF_TXFIFO_WML,
+ .rx_burst = FSL_SPDIF_RXFIFO_WML,
+ .tx_formats = FSL_SPDIF_FORMATS_PLAYBACK,
+
+};
+
+static struct fsl_spdif_soc_data fsl_spdif_imx8qm = {
+ .imx = true,
+ .shared_root_clock = true,
+ .interrupts = 2,
+ .tx_burst = 2, /* Applied for EDMA */
+ .rx_burst = 2, /* Applied for EDMA */
+ .tx_formats = SNDRV_PCM_FMTBIT_S24_LE, /* Applied for EDMA */
};
/* Check if clk is a root clock that does not share clock source with others */
@@ -1283,6 +1313,8 @@ static int fsl_spdif_probe(struct platform_device *pdev)
/* Initialize this copy of the CPU DAI driver structure */
memcpy(_priv->cpu_dai_drv, _spdif_dai, sizeof(fsl_spdif_dai));
spdif_priv->cpu_dai_drv.name = dev_name(>dev);
+ spdif_priv->cpu_dai_drv.playback.formats =
+ spdif_priv->soc->tx_formats;
/* Get the addresses and IRQ */
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -1297,15 +1329,19 @@ static int fsl_spdif_probe(struct platform_device *pdev)
return PTR_ERR(spdif_priv->regmap);
}
- irq = platform_get_irq(pdev, 0);
- if (irq < 0)
- return irq;
+ for (i = 0; i < spdif_priv->soc->interrupts; i++) {
+ irq = platform_get_irq(pdev, i);
+ if (irq < 0) {
+ dev_err(>dev, "no irq for node %s\n", pdev->name);
+ return irq;
+ }
- ret = devm_request_irq(>dev, irq, spdif_isr, 0,
- dev_name(>dev), spdif_priv);
- if (ret) {
- dev_err(>dev, "could not claim irq %u\n", irq);
- return ret;
+ ret = devm_request_irq(>dev, irq, spdif_isr, 0,
+ dev_name(>dev), spdif_priv);
+ if (ret) {
+ dev_err(>dev, "could not claim irq %u\n", irq);
+ return ret;
+ }
}
/* Get system clock for rx clock rate calculation */
@@ -1354,8 +1390,8 @@ static int fsl_spdif_probe(struct platform_device *pdev)
spdif_priv->dpll_locked = false;
- spdif_priv->dma_params_tx.maxburst = FSL_SPDIF_TXFIFO_WML;
- spdif_priv->dma_params_rx.maxburst = FSL_SPDIF_RXFIFO_WML;
+ spdif_priv->dma_params_tx.maxburst = spdif_priv->soc->tx_burst;
+ spdif_priv->dma_params_rx.maxburst = spdif_priv->soc->rx_burst;
spdif_priv->dma_params_tx.addr = res->start + REG_SPDIF_STL;
spdif_priv->dma_params_rx.addr = res->start + REG_SPDIF_SRL;
@@ -1468,6 +1504,7 @@ static const struct of_device_id fsl_spdif_dt_ids[] = {
{ .compatible = "fsl,imx35-spdif", .data = _spdif_imx35, },
{ .compatible = "fsl,vf610-spdif", .data = _spdif_vf610, },
{ .compatible = "fsl,imx6sx-spdif", .data = _spdif_imx6sx, },
+ { .compatible = "fsl,imx8qm-spdif", .data = _spdif_imx8qm, },
[PATCH 1/2] ASoC: dt-bindings: fsl_spdif: Add new compatible string for i.MX8QM
Add new compatible string "fsl,imx8qm-spdif" for supporting spdif module on i.MX8QM. Signed-off-by: Shengjiu Wang --- Documentation/devicetree/bindings/sound/fsl,spdif.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/sound/fsl,spdif.yaml b/Documentation/devicetree/bindings/sound/fsl,spdif.yaml index 2ac671f5cb9b..50449b6d1048 100644 --- a/Documentation/devicetree/bindings/sound/fsl,spdif.yaml +++ b/Documentation/devicetree/bindings/sound/fsl,spdif.yaml @@ -20,6 +20,7 @@ properties: - fsl,imx35-spdif - fsl,vf610-spdif - fsl,imx6sx-spdif + - fsl,imx8qm-spdif reg: maxItems: 1 -- 2.27.0
Re: [PATCH v6 35/80] docs: fs: fscrypt.rst: get rid of :c:type: tags
Em Wed, 14 Oct 2020 14:59:54 -0700 Eric Biggers escreveu: > On Wed, Oct 14, 2020 at 08:59:07AM +0200, Mauro Carvalho Chehab wrote: > > [PATCH v6.1 35/80] docs: fs: fscrypt.rst: get rid of :c:type: tags > > > > The :c:type: tag has problems with Sphinx 3.x, as structs > > there should be declared with c:struct. > > > > So, remove them, relying at automarkup.py extension to > > convert them into cross-references. > > > > Signed-off-by: Mauro Carvalho Chehab > > "relying at" => "relying on". > > Otherwise looks fine, you can add: > > Reviewed-by: Eric Biggers Thank you for reviewing it! > I do still wonder about your comment though: > > > It should be said that, currently, if there's no documentation for "foo", > > automarkup will just keep using the regular text font, keeping the text > > untouched. > > That will apply to most (maybe all) of the structures mentioned in this file. > I expected that if the documentation system now automatically recognizes > 'struct foo', then it would render it in code font even when 'struct foo' > isn't > documented. Any particular reason why that isn't the case? Not like I care > much myself, but it's a bit unexpected and it means this change actually makes > the rendered documentation look worse... Yeah, I agree that using monospaced fonts on this case too would be nice. The C domain actually uses italic monospaced fonts for broken XREFs. I suspect that changing this at automarkup.py would be simple, but not sure if it would be safe. Jon can tell more about that, as he's the author of automarkup, but I suspect that the reason for the current behavior is to avoid false-positives. I mean, if "struct foo" symbol doesn't exist at the C domain, this might mean that the parser is doing something wrong. So, a more conservative approach is to keep the string as-is. On the other hand, if one finds a valid "struct foo" using normal fonts, this would mean that either the doc is outdated, mentioning an struct that were removed/renamed or that there's a missing kernel-doc markup. In any case, the fix is to simply fix the kernel-doc markup for struct foo. I guess in the future automarkup.py could issue a warning in order to warn about missing cross-references, perhaps when W=1 or W=2 is used. Thanks, Mauro
linux-next: build warnings after merge of the kunit-next tree
Hi all,
After merging the kunit-next tree, today's linux-next build (x86_64
allmodconfig) produced this warning:
lib/bitfield_kunit.c: In function 'test_bitfields_compile':
lib/bitfield_kunit.c:136:21: warning: unsigned conversion from 'int' to 'u16'
{aka 'short unsigned int'} changes value from '393216' to '0' [-Woverflow]
136 | u16_encode_bits(0, 0x6);
| ^~~
At top level:
lib/bitfield_kunit.c:129:20: warning: 'test_bitfields_compile' defined but not
used [-Wunused-function]
129 | static void __init test_bitfields_compile(struct kunit *context)
|^~
Introduced by commit
d2585f5164c2 ("lib: kunit: add bitfield test conversion to KUnit")
--
Cheers,
Stephen Rothwell
pgpDUcJdsD0UO.pgp
Description: OpenPGP digital signature
Re: [PATCH-next 0/4] RDMA: sprintf to sysfs_emit conversions
On Thu, 2020-10-08 at 08:41 +0300, Leon Romanovsky wrote: > On Wed, Oct 07, 2020 at 07:36:23PM -0700, Joe Perches wrote: > > A recent commit added a sysfs_emit and sysfs_emit_at to allow various > > sysfs show functions to ensure that the PAGE_SIZE buffer argument is > > never overrun and always NUL terminated. > > Unfortunately but the sysfs_emit commit is not in rdma-next tree yet. It is in Linus' tree now.
Re: [PATCH 1/2] kunit: Support for Parameterized Testing
On 12/10/20 4:30 pm, Marco Elver wrote:
> On Sat, 10 Oct 2020 at 16:54, Arpitha Raghunandan <98.a...@gmail.com> wrote:
>> Implementation of support for parameterized testing in KUnit.
>>
>> Signed-off-by: Arpitha Raghunandan <98.a...@gmail.com>
>> ---
>> include/kunit/test.h | 29 +
>> lib/kunit/test.c | 44 +++-
>> 2 files changed, 72 insertions(+), 1 deletion(-)
>>
>> diff --git a/include/kunit/test.h b/include/kunit/test.h
>> index 59f3144f009a..4740d66269b4 100644
>> --- a/include/kunit/test.h
>> +++ b/include/kunit/test.h
>> @@ -140,10 +140,14 @@ struct kunit;
>> struct kunit_case {
>> void (*run_case)(struct kunit *test);
>> const char *name;
>> + void* (*get_params)(void);
>> + int max_parameters_count;
>> + int parameter_size;
>>
>> /* private: internal use only. */
>> bool success;
>> char *log;
>> + bool parameterized;
>
> Why do you need this bool? Doesn't get_params being non-NULL tell you
> if the test case is parameterized?
>Yeah, this will.
>> };
>>
>> static inline char *kunit_status_to_string(bool status)
>> @@ -162,6 +166,11 @@ static inline char *kunit_status_to_string(bool status)
>> */
>> #define KUNIT_CASE(test_name) { .run_case = test_name, .name = #test_name }
>>
>> +#define KUNIT_CASE_PARAM(test_name, getparams, count, size)
>>\
>> + { .run_case = test_name, .name = #test_name,
>>\
>> + .parameterized = true, .get_params = (void*
>> (*)(void))getparams, \
>> + .max_parameters_count = count, .parameter_size = size }
>> +
>
> I think this interface is overly complex. For one, if the only purpose
> of the getparams function is to return a pointer to some array, then
> there are only few cases where I see getparams being a function could
> be useful.
>
> Instead, could we make the getparams function behave like a generator?
> Because then you do not need count, nor size. Its function signature
> would be:
>
> void* (*generate_params)(void* prev_param);
>
> The protocol would be:
>
> - The first call to generate_params is passed prev_param of NULL, and
> returns a pointer to the first parameter P[0].
>
> - Every nth successive call to generate_params is passed the previous
> parameter P[n-1].
>
> - When no more parameters are available, generate_params returns NULL.
>
> - (generate_params should otherwise be stateless, but this is only
> relevant if concurrent calls are expected.)
>
>
>> /**
>> * struct kunit_suite - describes a related collection of kunit_case
>> *
>> @@ -206,6 +215,23 @@ struct kunit {
>> /* private: internal use only. */
>> const char *name; /* Read only after initialization! */
>> char *log; /* Points at case log after initialization */
>> + bool parameterized; /* True for parameterized tests */
>> + /* param_values stores the test parameters
>> +* for parameterized tests.
>> +*/
>> + void *param_values;
>> + /* max_parameters_count indicates maximum number of
>> +* parameters for parameterized tests.
>> +*/
>> + int max_parameters_count;
>> + /* iterator_count is used by the iterator method
>> +* for parameterized tests.
>> +*/
>> + int iterator_count;
>> + /* parameter_size indicates size of a single test case
>> +* for parameterized tests.
>> +*/
>> + int parameter_size;
>
> All of this would become much simpler if you used the generator
> approach. Likely only 1 field would be required, which is the current
> param.
>
>> struct kunit_try_catch try_catch;
>> /*
>> * success starts as true, and may only be set to false during a
>> @@ -225,6 +251,7 @@ struct kunit {
>> };
>>
>> void kunit_init_test(struct kunit *test, const char *name, char *log);
>> +void kunit_init_param_test(struct kunit *test, struct kunit_case
>> *test_case);
>>
>> int kunit_run_tests(struct kunit_suite *suite);
>>
>> @@ -237,6 +264,8 @@ int __kunit_test_suites_init(struct kunit_suite
>> **suites);
>>
>> void __kunit_test_suites_exit(struct kunit_suite **suites);
>>
>> +void *get_test_case_parameters(struct kunit *test);
>> +
>> /**
>> * kunit_test_suites() - used to register one or more kunit_suite
>> * with KUnit.
>> diff --git a/lib/kunit/test.c b/lib/kunit/test.c
>> index c36037200310..ab9e13c81d4a 100644
>> --- a/lib/kunit/test.c
>> +++ b/lib/kunit/test.c
>> @@ -142,6 +142,11 @@ unsigned int kunit_test_case_num(struct kunit_suite
>> *suite,
>> }
>> EXPORT_SYMBOL_GPL(kunit_test_case_num);
>>
>> +static void kunit_print_failed_param(struct kunit *test)
>> +{
>> + kunit_err(test, "\n\tTest failed at parameter: %d\n",
>> test->iterator_count);
>> +}
>> +
>> static void kunit_print_string_stream(struct kunit *test,
>>
[PATCH] mips: ralink: mt7621: add zboot debug console
uartlite0 at 0x1e000c00 is a 16550 compatible uart controller. It's usually used for debug console and is already configured by u-boot. Add ZBOOT_UART16550 and related definitions in uart-16550.c for zboot debug output. Signed-off-by: Chuanhong Guo --- arch/mips/boot/compressed/uart-16550.c | 6 ++ arch/mips/ralink/Kconfig | 1 + 2 files changed, 7 insertions(+) diff --git a/arch/mips/boot/compressed/uart-16550.c b/arch/mips/boot/compressed/uart-16550.c index aee8d7b8f091..7122df28967a 100644 --- a/arch/mips/boot/compressed/uart-16550.c +++ b/arch/mips/boot/compressed/uart-16550.c @@ -35,6 +35,12 @@ #define IOTYPE unsigned int #endif +#ifdef CONFIG_SOC_MT7621 +#define UART0_BASE 0x1e000c00 +#define PORT(offset) (CKSEG1ADDR(UART0_BASE) + (4 * offset)) +#define IOTYPE unsigned int +#endif + #ifndef IOTYPE #define IOTYPE char #endif diff --git a/arch/mips/ralink/Kconfig b/arch/mips/ralink/Kconfig index c10d8b233ab1..4c3c6ef330e3 100644 --- a/arch/mips/ralink/Kconfig +++ b/arch/mips/ralink/Kconfig @@ -52,6 +52,7 @@ choice select SYS_SUPPORTS_SMP select SYS_SUPPORTS_MIPS_CPS select SYS_SUPPORTS_HIGHMEM + select SYS_SUPPORTS_ZBOOT_UART16550 select MIPS_GIC select COMMON_CLK select CLKSRC_MIPS_GIC -- 2.26.2
Re: [PATCH v2 02/24] tools: docs: memory-model: fix references for some files
Hi Paul, Em Wed, 14 Oct 2020 11:57:20 -0700 "Paul E. McKenney" escreveu: > On Tue, Oct 13, 2020 at 06:58:40PM -0700, Paul E. McKenney wrote: > > On Tue, Oct 13, 2020 at 12:38:36PM -0400, Alan Stern wrote: > > > On Tue, Oct 13, 2020 at 09:33:54AM -0700, Paul E. McKenney wrote: > > > > On Tue, Oct 13, 2020 at 02:14:29PM +0200, Mauro Carvalho Chehab wrote: > > > > > - The sysfs.txt file was converted to ReST and renamed; > > > > > - The control-dependencies.txt is not at > > > > > Documentation/control-dependencies.txt. As it is at the > > > > > same dir as the README file, which mentions it, just > > > > > remove Documentation/. > > > > > > > > > > With that, ./scripts/documentation-file-ref-check script > > > > > is now happy again for files under tools/. > > > > > > > > > > Signed-off-by: Mauro Carvalho Chehab > > > > > > > > Queued for review and testing, likely target v5.11. > > > > > > Instead of changing the path in the README reference, shouldn't > > > tools/memory-model/control-dependencies.txt be moved to its proper > > > position in .../Documentation? > > > > You are of course quite right. My thought is to let Mauro go ahead, > > given his short deadline. I guess there might be some misunderstanding here. My fault. The plan is to have zero doc warnings for 5.10[1]. In order to get there, The patches for it were split on two series, both for 5.10: - The /80 series with patches that already applies on the top of master; - This /24 patch series, which depends on trees that weren't merged upstream yet (back on Oct, 13). Those applies on the top of next-20201013. I'm intending to submit later today (after next-20201015) a PR with patches from the /80 series. The remaining ones should be sent as a late pull request by the end of the merge window, if the patch that caused the issue gets merged for 5.10. That's the case of this patch. [1] With Sphinx < 3. Sphinx 3 and above brings some additional warnings that depends on a fix at the toolset. The fixup patches for Sphinx were proposed yesterday by the Sphinx maintainer of the C domain parser. More details can be seen here: https://github.com/sphinx-doc/sphinx/pull/8313 > > We can then make this "git mv" change once > > v5.10-rc1 comes out, given that it should have Mauro's patches. I have > > added a reminder to my calendar. > > Except that I cannot find a commit where control-dependencies.txt is > in tools/memory-model. And this file is not yet in mainline, but > only in -rcu and -next. In both places, it is here: > > tools/memory-model/Documentation/control-dependencies.txt > > Mauro, to what commit in what tree are you applying this patch? This is against next-20201013. The specific commit adding README and control-dependencies.txt is this one: commit d34a972f67252457158122e5ba7a0ce5ece62067 Author: Paul E. McKenney AuthorDate: Tue Aug 11 11:27:33 2020 -0700 Commit: Paul E. McKenney CommitDate: Sun Oct 4 17:21:31 2020 -0700 tools/memory-model: Document categories of ordering primitives The Linux kernel has a number of categories of ordering primitives, which are recorded in the LKMM implementation and hinted at by cheatsheet.txt. But there is no overview of these categories, and such an overview is needed in order to understand multithreaded LKMM litmus tests. This commit therefore adds an ordering.txt as well as extracting a control-dependencies.txt from memory-barriers.txt. It also updates the README file. [ paulmck: Apply Akira Yokosawa file-placement feedback. ] [ paulmck: Apply Alan Stern feedback. ] Signed-off-by: Paul E. McKenney Btw, after re-checking the patch, I would drop this hunk: diff --git a/tools/memory-model/Documentation/README b/tools/memory-model/Documentation/README index 16177aaa9752..004969992bac 100644 --- a/tools/memory-model/Documentation/README +++ b/tools/memory-model/Documentation/README @@ -55,7 +55,7 @@ README Documentation/cheatsheet.txt Quick-reference guide to the Linux-kernel memory model. -Documentation/control-dependencies.txt +control-dependencies.txt A guide to preventing compiler optimizations from destroying your control dependencies. The ./scripts/documentation-file-ref-check doesn't complain about broken references for Documentation/ files outside the main docs dir. So, this hunk is not really needed to fix warnings with 5.10. Besides that, there are other references to those files: $ git grep Documentation tools/memory-model/Documentation/README tools/memory-model/Documentation/README:tools/memory-model/Documentation directory. It has been said that at tools/memory-model/Documentation/README:Documentation/cheatsheet.txt tools/memory-model/Documentation/README:Documentation/control-dependencies.txt tools/memory-model/Documentation/README:Documentation/explanation.txt
Re: [Linux-kernel-mentees] [PATCH] net: rose: Fix Null pointer dereference in rose_send_frame()
On Thu, Oct 15, 2020 at 05:47:12AM +0530, Anmol Karn wrote: > In rose_send_frame(), when comparing two ax.25 addresses, it assigns > rose_call to > either global ROSE callsign or default port, but when the former block > triggers and > rose_call is assigned by (ax25_address *)neigh->dev->dev_addr, a NULL pointer > is > dereferenced by 'neigh' when dereferencing 'dev'. > > - net/rose/rose_link.c > This bug seems to get triggered in this line: > > rose_call = (ax25_address *)neigh->dev->dev_addr; > > Prevent it by checking NULL condition for neigh->dev before comparing > addressed for > rose_call initialization. > > Reported-by: syzbot+a1c743815982d9496...@syzkaller.appspotmail.com > Link: > https://syzkaller.appspot.com/bug?id=9d2a7ca8c7f2e4b682c97578dfa3f236258300b3 > Signed-off-by: Anmol Karn > --- > I am bit sceptical about the error return code, please suggest if anything > else is > appropriate in place of '-ENODEV'. > > net/rose/rose_link.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/net/rose/rose_link.c b/net/rose/rose_link.c > index f6102e6f5161..92ea6a31d575 100644 > --- a/net/rose/rose_link.c > +++ b/net/rose/rose_link.c > @@ -97,6 +97,9 @@ static int rose_send_frame(struct sk_buff *skb, struct > rose_neigh *neigh) > ax25_address *rose_call; > ax25_cb *ax25s; > > + if (!neigh->dev) > + return -ENODEV; How can ->dev not be set at this point in time? Shouldn't that be fixed, because it could change right after you check this, right? thanks, greg k-h
Re: [PATCH] nvme-pci: Disable Write Zeroes on Sandisk Skyhawk
> On Oct 14, 2020, at 08:20, Chaitanya Kulkarni
> wrote:
>
> On 10/13/20 01:45, Kai-Heng Feng wrote:
>> Like commit 5611ec2b9814 ("nvme-pci: prevent SK hynix PC400 from using
>> Write Zeroes command"), Sandisk Skyhawk has the same issue:
>> [ 6305.633887] blk_update_request: operation not supported error, dev
>> nvme0n1, sector 340812032 op 0x9:(WRITE_ZEROES) flags 0x0 phys_seg 0 prio
>> class 0
>>
>> So also disable Write Zeroes command on Sandisk Skyhawk.
>>
>> BugLink: https://bugs.launchpad.net/bugs/1899503
>> Signed-off-by: Kai-Heng Feng
>
> Are you sure this happens all the devices of the same model
>
> and not a firmware bug on specific device ?
>
> If yes then looks good.
Yes, and this is the reply from WD, requested by the user:
"These are newest WD branded drives and WD already confirmed they are
the newest firmware / no upgrades are available."
Kai-Heng
>
> Reviewed-by: Chaitanya Kulkarni
>
>
>
Re: [PATCH v6 2/2] PCI/ERR: Split the fatal and non-fatal error recovery handling
On Thu, Oct 15, 2020 at 11:04 AM Kuppuswamy, Sathyanarayanan
wrote:
>
>
>
> On 10/14/20 6:58 PM, Ethan Zhao wrote:
> > On Thu, Oct 15, 2020 at 1:06 AM Kuppuswamy, Sathyanarayanan
> > wrote:
> >>
> >>
> >>
> >> On 10/14/20 8:07 AM, Ethan Zhao wrote:
> >>> On Wed, Oct 14, 2020 at 5:00 PM Kuppuswamy Sathyanarayanan
> >>> wrote:
>
> Commit bdb5ac85777d ("PCI/ERR: Handle fatal error recovery")
> merged fatal and non-fatal error recovery paths, and also made
> recovery code depend on hotplug handler for "remove affected
> device + rescan" support. But this change also complicated the
> error recovery path and which in turn led to the following
> issues.
>
> 1. We depend on hotplug handler for removing the affected
> devices/drivers on DLLSC LINK down event (on DPC event
> trigger) and DPC handler for handling the error recovery. Since
> both handlers operate on same set of affected devices, it leads
> to race condition, which in turn leads to NULL pointer
> exceptions or error recovery failures.You can find more details
> about this issue in following link.
>
> https://lore.kernel.org/linux-pci/20201007113158.48933-1-haifeng.z...@intel.com/T/#t
>
> 2. For non-hotplug capable devices fatal (DPC) error recovery
> is currently broken. Current fatal error recovery implementation
> relies on PCIe hotplug (pciehp) handler for detaching and
> re-enumerating the affected devices/drivers. So when dealing with
> non-hotplug capable devices, recovery code does not restore the state
> of the affected devices correctly. You can find more details about
> this issue in the following links.
>
> https://lore.kernel.org/linux-pci/20200527083130.4137-1-zhiqiang@nxp.com/
> https://lore.kernel.org/linux-pci/12115.1588207324@famine/
> https://lore.kernel.org/linux-pci/0e6f89cd6b9e4a72293cc90fafe93487d7c2d295.158584.git.sathyanarayanan.kuppusw...@linux.intel.com/
>
> In order to fix the above two issues, we should stop relying on hotplug
> >>> Yes, it doesn't rely on hotplug handler to remove and rescan the
> >>> device,
> >>> but it couldn't prevent hotplug drivers from doing another replicated
> >>> removal/rescanning.
> >>> it doesn't make sense to leave another useless removal/rescanning there.
> >>> Maybe that's why these two paths were merged to one and made it rely on
> >>> hotplug.
> >> No, as per PCIe spec, hotplug and DPC has no functional dependency. Hence
> >> depending on it to handle some of its recovery function is in-correct and
> >> would lead to issues in non-hotplug capable platforms (which is true
> >> currently).
> >>>
>
> > pci_lock_rescan_remove() is global lock for PCIe, the mal-functional
> > device's port holds this lock, it prevents the whole system from doing
> > hot-plug operation.
> It does not prevent the hotplug operation, but it might delay it. Since both
> DPC and hotplug operates on same set of devices, it must be synchronized.
Think about a large system with some PCI domains, every domain has some
ports and devices attached. why DPC and hotplug *must* operate on the
same set of devices from different domains ? if it must be synchronized, why
make the hotplug handlers threadable ?
> > Though pciehp is not so hot/scalable and performance critical, but there
> > is per cpu thread to handle hot-plug operation. synchronize all threads
> > make them walk backwards for scalability.
> DPC events does not happen in high frequency. So I don't think we should
It's holding global lock, once malfunction happens to one device and
it's driver,
the whole system, everyone holds it, would be blocked to work.
> worry about the performance here. Even hotplug handler will hold this lock
> when adding/removing the devices. So adding/removing devices is a serialized
You don't worry about performance, but if there is a requirement needs
more scalable
and reliable hotplug, the effect will be much harder. what to do then ? choose
another OS ?
To be honest, I don't like the global lock/ pci_lock_rescan_remove().
BTW, I didn't try the FATAL errors brute force injection on your
patch, duplicated
removal will work naturally because it was removed ?
Thanks,
Ethan
> operation.
> >
>
> >>
> --
> 2.17.1
>
> >>
> >> --
> >> Sathyanarayanan Kuppuswamy
> >> Linux Kernel Developer
>
> --
> Sathyanarayanan Kuppuswamy
> Linux Kernel Developer
Re: fw_devlink on will break all snps,dw-apb-gpio users
On Wed, Oct 14, 2020 at 9:02 PM Jisheng Zhang
wrote:
>
> On Wed, 14 Oct 2020 10:29:36 -0700
> Saravana Kannan wrote:
>
> > CAUTION: Email originated externally, do not click links or open
> > attachments unless you recognize the sender and know the content is safe.
> >
> >
> > On Wed, Oct 14, 2020 at 4:12 AM Jisheng Zhang
> > wrote:
> > >
> > > Hi,
> > >
> > > If set fw_devlink as on, any consumers of dw apb gpio won't probe.
> > >
> > > The related dts looks like:
> > >
> > > gpio0: gpio@2400 {
> > >compatible = "snps,dw-apb-gpio";
> > >#address-cells = <1>;
> > >#size-cells = <0>;
> > >
> > >porta: gpio-port@0 {
> > > compatible = "snps,dw-apb-gpio-port";
> > > gpio-controller;
> > > #gpio-cells = <2>;
> > > ngpios = <32>;
> > > reg = <0>;
> > >};
> > > };
> > >
> > > device_foo {
> > > status = "okay"
> > > ...;
> > > reset-gpio = <, 0, GPIO_ACTIVE_HIGH>;
> > > };
> > >
> > > If I change the reset-gpio property to use another kind of gpio phandle,
> > > e.g gpio expander, then device_foo can be probed successfully.
> > >
> > > The gpio expander dt node looks like:
> > >
> > > expander3: gpio@44 {
> > > compatible = "fcs,fxl6408";
> > > pinctrl-names = "default";
> > > pinctrl-0 = <_pmux>;
> > > reg = <0x44>;
> > > gpio-controller;
> > > #gpio-cells = <2>;
> > > interrupt-parent = <>;
> > > interrupts = <23 IRQ_TYPE_NONE>;
> > > interrupt-controller;
> > > #interrupt-cells = <2>;
> > > };
> > >
> > > The common pattern looks like the devlink can't cope with suppliers from
> > > child dt node.
> >
> > fw_devlink doesn't have any problem dealing with child devices being
> > suppliers. The problem with your case is that the
> > drivers/gpio/gpio-dwapb.c driver directly parses the child nodes and
> > never creates struct devices for them. If you have a node with
> > compatible string, fw_devlink expects you to create and probe a struct
> > device for it. So change your driver to add the child devices as
> > devices instead of just parsing the node directly and doing stuff with
> > it.
> >
> > Either that, or stop putting "compatible" string in a node if you
> > don't plan to actually treat it as a device -- but that's too late for
> > this driver (it needs to be backward compatible). So change the driver
> > to add of_platform_populate() and write a driver that probes
> > "snps,dw-apb-gpio-port".
> >
>
> Thanks for the information. The "snps,dw-apb-gpio-port" is never used,
> so I just sent out a series to remove it.
I'd actually prefer that you fix the kernel code to actually use it.
So that fw_devlink can be backward compatible (Older DT + new kernel).
The change is pretty trivial (I just have time to do it for you).
-Saravana
Re: [PATCH v7 1/2] dt-bindings: display: panel: Add bindings for Novatek nt36672a
Hi Sam,
On Thu, 15 Oct 2020 at 00:14, Sam Ravnborg wrote:
>
> Hi Sumit.
> On Wed, Sep 02, 2020 at 12:14:06PM +0530, Sumit Semwal wrote:
> > Novatek nt36672a is a display driver IC that can drive DSI panel. It
> > is also present in the Tianma video mode panel, which is a FHD+ panel
> > with a resolution of 1080x2246 and 6.18 inches size. It is found in
> > some of the Poco F1 phones.
> >
> > This patch adds the display driver for the IC, with support added for
> > this tianma fhd video mode panel.
> >
> > Signed-off-by: Sumit Semwal
> > Reviewed-by: Rob Herring
> Reviewed-by: Sam Ravnborg
> I assume you will apply the patch yourself.
Thanks, I will.
>
> Sam
Best,
Sumit.
> >
> > ---
> > v2: remove ports node, making port@0 directly under panel@0 node.
> > v3: updated to replace port@0 to just 'port'.
> > v5: renamed to novatek,nt36672a, since the binding is for the IC and not
> > the panel.
> > v6: v5 review comments incorporated.
> > - added enum for the compatible part, since it can be extended in
> > future.
> > - few cosmetic updates.
> > ---
> > .../display/panel/novatek,nt36672a.yaml | 87 +++
> > 1 file changed, 87 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml
> >
> > diff --git
> > a/Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml
> > b/Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml
> > new file mode 100644
> > index ..d2170de6b723
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml
> > @@ -0,0 +1,87 @@
> > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/display/panel/novatek,nt36672a.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Novatek NT36672A based DSI display Panels
> > +
> > +maintainers:
> > + - Sumit Semwal
> > +
> > +description: |
> > + The nt36672a IC from Novatek is a generic DSI Panel IC used to drive dsi
> > + panels.
> > + Right now, support is added only for a Tianma FHD+ LCD display panel
> > with a
> > + resolution of 1080x2246. It is a video mode DSI panel.
> > +
> > +allOf:
> > + - $ref: panel-common.yaml#
> > +
> > +properties:
> > + compatible:
> > +items:
> > + - enum:
> > + - tianma,fhd-video
> > + - const: novatek,nt36672a
> > +description: This indicates the panel manufacturer of the panel that is
> > + in turn using the NT36672A panel driver. This compatible string
> > + determines how the NT36672A panel driver is configured for the
> > indicated
> > + panel. The novatek,nt36672a compatible shall always be provided as a
> > fallback.
> > +
> > + reset-gpios:
> > +description: phandle of gpio for reset line - This should be 8mA, gpio
> > + can be configured using mux, pinctrl, pinctrl-names (active high)
> > +
> > + vddio-supply:
> > +description: phandle of the regulator that provides the supply voltage
> > + Power IC supply
> > +
> > + vddpos-supply:
> > +description: phandle of the positive boost supply regulator
> > +
> > + vddneg-supply:
> > +description: phandle of the negative boost supply regulator
> > +
> > + reg: true
> > + port: true
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - vddi0-supply
> > + - vddpos-supply
> > + - vddneg-supply
> > + - reset-gpios
> > + - port
> > +
> > +unevaluatedProperties: false
> > +
> > +examples:
> > + - |+
> > +#include
> > +
> > +dsi0 {
> > +#address-cells = <1>;
> > +#size-cells = <0>;
> > +
> > +panel@0 {
> > +compatible = "tianma,fhd-video", "novatek,nt36672a";
> > +reg = <0>;
> > +vddi0-supply = <_l14a_1p88>;
> > +vddpos-supply = <>;
> > +vddneg-supply = <>;
> > +
> > +reset-gpios = < 6 GPIO_ACTIVE_HIGH>;
> > +
> > +#address-cells = <1>;
> > +#size-cells = <0>;
> > +port {
> > +tianma_nt36672a_in_0: endpoint {
> > +remote-endpoint = <_out>;
> > +};
> > +};
> > +};
> > +};
> > +
> > +...
> > --
> > 2.28.0
> >
> > ___
> > dri-devel mailing list
> > dri-de...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] usb: cdns3: Add static to cdns3_gadget_exit function
Function cdns3_gadget_exit is used only in gadget.c file.
This patch removes declaration and definition of this
function from gadget-export.h file and makes it static.
Signed-off-by: Pawel Laszczak
Acked-by: Roger Quadros
---
Changelog:
v2
- added "Ackded-by" tag.
drivers/usb/cdns3/gadget-export.h | 3 ---
drivers/usb/cdns3/gadget.c| 2 +-
2 files changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/usb/cdns3/gadget-export.h
b/drivers/usb/cdns3/gadget-export.h
index 577469eee961..702c5a267a92 100644
--- a/drivers/usb/cdns3/gadget-export.h
+++ b/drivers/usb/cdns3/gadget-export.h
@@ -13,7 +13,6 @@
#ifdef CONFIG_USB_CDNS3_GADGET
int cdns3_gadget_init(struct cdns3 *cdns);
-void cdns3_gadget_exit(struct cdns3 *cdns);
#else
static inline int cdns3_gadget_init(struct cdns3 *cdns)
@@ -21,8 +20,6 @@ static inline int cdns3_gadget_init(struct cdns3 *cdns)
return -ENXIO;
}
-static inline void cdns3_gadget_exit(struct cdns3 *cdns) { }
-
#endif
#endif /* __LINUX_CDNS3_GADGET_EXPORT */
diff --git a/drivers/usb/cdns3/gadget.c b/drivers/usb/cdns3/gadget.c
index 692acf7b9b14..6ff3aa3db497 100644
--- a/drivers/usb/cdns3/gadget.c
+++ b/drivers/usb/cdns3/gadget.c
@@ -3069,7 +3069,7 @@ static void cdns3_gadget_release(struct device *dev)
kfree(priv_dev);
}
-void cdns3_gadget_exit(struct cdns3 *cdns)
+static void cdns3_gadget_exit(struct cdns3 *cdns)
{
struct cdns3_device *priv_dev;
--
2.17.1
Fw: RE: [PATCH 2/3] exfat: remove useless check in exfat_move_file()
Thank you for continuing the discussion.
The reply was delayed to summarize the arguing points.
> I already gave my comment on previous thread, and I prefer de array handling
> I sent instead of only two entries.
We haven't discussed enough yet and I have some questions.
I still don't understand what's technically problem.
> It will avoid repetitive loops to get entries from cache buffer.
Is that loop the first verification and name extraction?
I don't understand why you can avoid the repetitive loop by using arrays.
I think getting from an array is equivalent to getting it via a function.
A = obj->array[idx];
B = get(obj, idx);
For using, what's the difference between A and B?
> I think it is also suitable for function definition and union type entry
> structure.
I, too, think the combination is not bad.
However, it has no advantage compared to other methods.
(Can you give me any example?)
Also, as I said in my previous mail, union has the problem of too flexible for
type.
(Especially file-de and stream-de are easy to confuse)
So I want to avoid to access union directly from the upper function, as
possible.
> If you send the patches included this change again, I will actively look into
> your patches.
It will take some time as I haven't come up with a good idea yet.
We have discussed it so far, but there are still some unclear points.
First, I would like to clarify them.
1. About the need for TYPE_NAME-validation in exfat_get_dentry_set().
My opinion is
> It is possible to correctly determine that
> "Immediately follow the Stream Extension directory entry as a consecutive
> series"
> whether the TYPE_NAME check is implemented exfat_get_uniname_from_ext_entry()
> or
> exfat_get_dentry_set().
> It's functionally same, so it is also right to validate in either.
Your opinion is
> We have not checked the problem when it is removed because it was implemented
> according to the specification from the beginning.
I understand that you haven't thought about it yet.
What happens if I don't check here?
Please imagine if you can.
2. About TYPE_NAME-validation in exfat_get_uniname_from_ext_entry()
Below are the changes in '[PATCH v4 1/5] exfat: integrates dir-entry getting
and validation'
> - for (i = 2; i < es->num_entries; i++) {
> - struct exfat_dentry *ep = exfat_get_dentry_cached(es, i);
> -
> - /* end of name entry */
> - if (exfat_get_entry_type(ep) != TYPE_EXTEND)
> - break;
>
> + i = ES_INDEX_NAME;
> + while ((ep = exfat_get_validated_dentry(es, i++, TYPE_NAME))) {
> exfat_extract_uni_name(ep, uniname);
> uniname += EXFAT_FILE_NAME_LEN;
> }
Your request for this change is
> Please find the way to access name entries like ep_file, ep_stream
> without calling exfat_get_validated_dentry().
What is the reason(or rationale) for such a request?
Please explain what the problem is with this change, if you can.
As I explained before, the reason for validating TYPE_NAME here is
> name-length and type validation and name-extraction should not be separated.
> These are closely related, so these should be placed physically and
> temporally close.
Please explain why you shouldn't validate TYPE_NAME here.
3. About using exfat_get_validated_dentry() in
exfat_update_dir_chksum_with_entry_set()
Below are the changes in '[PATCH v4 1/5] exfat: integrates dir-entry getting
and validation'
> for (i = 0; i < es->num_entries; i++) {
> - ep = exfat_get_dentry_cached(es, i);
> + ep = exfat_get_validated_dentry(es, i, TYPE_ALL);
> chksum = exfat_calc_chksum16(ep, DENTRY_SIZE, chksum,
>chksum_type);
Your request for this change is
> Ditto, You do not need to repeatedly call exfat_get_validated_dentry() for
> the entries
> which got from exfat_get_dentry_set().
Even if the entry was got from exfat_get_dentry_set(), we need to get the ep
again to calculate the checksum.
exfat_get_validated_dentry() with TYPE_ALL is the same as
exfat_get_dentry_cached() because it allows all TYPEs.
Please elaborate on what the problem is.
4. About double-checking name entries as TYPE_SECONDARY and TYPE_NAME.
You said in 'RE: [PATCH v3] exfat: integrates dir-entry getting and validation'.
> your v3 patch are
> already checking the name entries as TYPE_SECONDARY. And it check them with
> TYPE_NAME again in exfat_get_uniname_from_ext_entry(). If you check TYPE_NAME
> with stream->name_len, We don't need to perform the loop for extracting
> filename from the name entries if stream->name_len or name entry is invalid.
It is rare case that stream->name_len or name-entry are invalid.
Perform the loop to extract filename when stream->name_len or name-entry is
invalid has little effect.
What is the probrem with perform the loop for extract filename when
stream->name_len or name-entry are invalid?
5. About validate flags as argument of
[PATCH v4] usb: cdns3: Rids of duplicate error message
On failure, the platform_get_irq_byname prints an error message,
so patch removes error message related to this function from
core.c file.
A change was suggested during reviewing CDNSP driver by Chunfeng Yun.
Signed-off-by: Pawel Laszczak
Acked-by: Peter Chen
---
Changelog:
v4
- fixed typo.
- "Acked-by" tag has been added.
v3
- changed error condition checking for dev_irq.
v2
- simplified code as sugested by Roger Quadros.
drivers/usb/cdns3/core.c | 12 ++--
1 file changed, 2 insertions(+), 10 deletions(-)
diff --git a/drivers/usb/cdns3/core.c b/drivers/usb/cdns3/core.c
index a0f73d4711ae..f2dedce3a40e 100644
--- a/drivers/usb/cdns3/core.c
+++ b/drivers/usb/cdns3/core.c
@@ -466,11 +466,8 @@ static int cdns3_probe(struct platform_device *pdev)
cdns->xhci_res[1] = *res;
cdns->dev_irq = platform_get_irq_byname(pdev, "peripheral");
- if (cdns->dev_irq == -EPROBE_DEFER)
- return cdns->dev_irq;
-
if (cdns->dev_irq < 0)
- dev_err(dev, "couldn't get peripheral irq\n");
+ return cdns->dev_irq;
regs = devm_platform_ioremap_resource_byname(pdev, "dev");
if (IS_ERR(regs))
@@ -478,14 +475,9 @@ static int cdns3_probe(struct platform_device *pdev)
cdns->dev_regs = regs;
cdns->otg_irq = platform_get_irq_byname(pdev, "otg");
- if (cdns->otg_irq == -EPROBE_DEFER)
+ if (cdns->otg_irq < 0)
return cdns->otg_irq;
- if (cdns->otg_irq < 0) {
- dev_err(dev, "couldn't get otg irq\n");
- return cdns->otg_irq;
- }
-
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "otg");
if (!res) {
dev_err(dev, "couldn't get otg resource\n");
--
2.17.1
[PATCH v3] usb: cdns3: Variable 'length' set but not used
Patch removes not used variable 'length' from
cdns3_wa2_descmiss_copy_data function.
Fixes: 141e70fef4ee ("usb: cdns3: gadget: need to handle sg case for workaround
2 case")
Signed-off-by: Pawel Laszczak
Acked-by: Roger Quadros
---
Changelog:
v3
- added "Acked-by" tag.
v2
- added "Fixes" tag.
drivers/usb/cdns3/gadget.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/usb/cdns3/gadget.c b/drivers/usb/cdns3/gadget.c
index 6e7b70a2e352..692acf7b9b14 100644
--- a/drivers/usb/cdns3/gadget.c
+++ b/drivers/usb/cdns3/gadget.c
@@ -506,7 +506,6 @@ static void cdns3_wa2_descmiss_copy_data(struct
cdns3_endpoint *priv_ep,
while (!list_empty(_ep->wa2_descmiss_req_list)) {
int chunk_end;
- int length;
descmiss_priv_req =
cdns3_next_priv_request(_ep->wa2_descmiss_req_list);
@@ -517,7 +516,6 @@ static void cdns3_wa2_descmiss_copy_data(struct
cdns3_endpoint *priv_ep,
break;
chunk_end = descmiss_priv_req->flags & REQUEST_INTERNAL_CH;
- length = request->actual + descmiss_req->actual;
request->status = descmiss_req->status;
__cdns3_descmiss_copy_data(request, descmiss_req);
list_del_init(_priv_req->list);
--
2.17.1
linux-next: build failure after merge of the rpmsg tree
Hi all,
After merging the rpmsg tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/remoteproc/mtk_scp.c: In function 'mt8192_scp_before_load':
drivers/remoteproc/mtk_scp.c:326:2: error: implicit declaration of function
'dsb' [-Werror=implicit-function-declaration]
326 | dsb(sy);
| ^~~
drivers/remoteproc/mtk_scp.c:326:6: error: 'sy' undeclared (first use in this
function); did you mean 's8'?
326 | dsb(sy);
| ^~
| s8
Caused by commit
fd0b6c1ff85a ("remoteproc/mediatek: Add support for mt8192 SCP")
I have reverted that commit for today.
--
Cheers,
Stephen Rothwell
pgpXgi25fWrnf.pgp
Description: OpenPGP digital signature
Re: [PATCH v2] vmlinux.lds.h: Keep .ctors.* with .ctors
On Wed, Oct 14, 2020 at 4:04 PM Kees Cook wrote:
>
> On Sun, Oct 04, 2020 at 07:57:20PM -0700, Kees Cook wrote:
> > Under some circumstances, the compiler generates .ctors.* sections. This
> > is seen doing a cross compile of x86_64 from a powerpc64el host:
> >
> > x86_64-linux-gnu-ld: warning: orphan section `.ctors.65435' from
> > `kernel/trace/trace_clock.o' being
> > placed in section `.ctors.65435'
> > x86_64-linux-gnu-ld: warning: orphan section `.ctors.65435' from
> > `kernel/trace/ftrace.o' being
> > placed in section `.ctors.65435'
> > x86_64-linux-gnu-ld: warning: orphan section `.ctors.65435' from
> > `kernel/trace/ring_buffer.o' being
> > placed in section `.ctors.65435'
> >
> > Include these orphans along with the regular .ctors section.
> >
> > Reported-by: Stephen Rothwell
> > Tested-by: Stephen Rothwell
> > Fixes: 83109d5d5fba ("x86/build: Warn on orphan section placement")
> > Signed-off-by: Kees Cook
>
> Ping -- please take this for tip/urgent, otherwise we're drowning sfr in
> warnings. :)
>
> -Kees
>
> > ---
> > v2: brown paper bag version: fix whitespace for proper backslash alignment
> > ---
> > include/asm-generic/vmlinux.lds.h | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/include/asm-generic/vmlinux.lds.h
> > b/include/asm-generic/vmlinux.lds.h
> > index 5430febd34be..b83c00c63997 100644
> > --- a/include/asm-generic/vmlinux.lds.h
> > +++ b/include/asm-generic/vmlinux.lds.h
> > @@ -684,6 +684,7 @@
> > #ifdef CONFIG_CONSTRUCTORS
> > #define KERNEL_CTORS() . = ALIGN(8); \
> > __ctors_start = .; \
> > + KEEP(*(SORT(.ctors.*)))\
> > KEEP(*(.ctors))\
> > KEEP(*(SORT(.init_array.*))) \
> > KEEP(*(.init_array)) \
> > --
> > 2.25.1
> >
>
> --
> Kees Cook
>
> --
> You received this message because you are subscribed to the Google Groups
> "Clang Built Linux" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clang-built-linux+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/clang-built-linux/202010141603.49EA0CE%40keescook.
I think it would be great to figure out why these .ctors.* .dtors.*
are generated.
~GCC 4.7 switched to default to .init_array/.fini_array if libc
supports it. I have some refactoring in this area of Clang as well
(e.g. https://reviews.llvm.org/D71393)
And I am not sure SORT(.init_array.*) or SORT(.ctors.*) will work. The
correct construct is SORT_BY_INIT_PRIORITY(.init_array.*)
[PATCH v2 1/1] dt-bindings: misc: add support for both property names cmd-gpios and cmd-gpio
The definition "gpio_suffixes[] = { "gpios", "gpio" }" shows that both
property names "cmd-gpios" and "cmd-gpio" are supported. But currently
only "cmd-gpios" is allowed in this yaml, and the name used in
mmp2-olpc-xo-1-75.dts is cmd-gpio. As a result, the following errors is
reported.
slave: 'cmd-gpios' is a required property
slave: 'cmd-gpio' does not match any of the regexes: 'pinctrl-[0-9]+'
Signed-off-by: Zhen Lei
---
Documentation/devicetree/bindings/misc/olpc,xo1.75-ec.yaml | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/misc/olpc,xo1.75-ec.yaml
b/Documentation/devicetree/bindings/misc/olpc,xo1.75-ec.yaml
index b3c45c046ba5e37..dd549380a085709 100644
--- a/Documentation/devicetree/bindings/misc/olpc,xo1.75-ec.yaml
+++ b/Documentation/devicetree/bindings/misc/olpc,xo1.75-ec.yaml
@@ -24,15 +24,21 @@ properties:
compatible:
const: olpc,xo1.75-ec
- cmd-gpios:
+ spi-cpha: true
+
+patternProperties:
+ "^cmd-gpio[s]?$":
description: GPIO uspecifier of the CMD pin
maxItems: 1
- spi-cpha: true
-
required:
- compatible
- - cmd-gpios
+
+oneOf:
+ - required:
+ - cmd-gpio
+ - required:
+ - cmd-gpios
additionalProperties: false
--
1.8.3
Re: [PATCH RFC V3 9/9] x86/pks: Add PKS test code
On Tue, Oct 13, 2020 at 12:02:07PM -0700, Dave Hansen wrote:
> On 10/9/20 12:42 PM, ira.we...@intel.com wrote:
> > #ifdef CONFIG_X86_32
> > /*
> > * We can fault-in kernel-space virtual memory on-demand. The
> > diff --git a/include/linux/pkeys.h b/include/linux/pkeys.h
> > index cc3510cde64e..f9552bd9341f 100644
> > --- a/include/linux/pkeys.h
> > +++ b/include/linux/pkeys.h
> > @@ -47,7 +47,6 @@ static inline bool arch_pkeys_enabled(void)
> > static inline void copy_init_pkru_to_fpregs(void)
> > {
> > }
> > -
> > #endif /* ! CONFIG_ARCH_HAS_PKEYS */
>
> ^ Whitespace damage
Done.
>
> > #ifndef CONFIG_ARCH_HAS_SUPERVISOR_PKEYS
> > diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> > index 0c781f912f9f..f015c09ba5a1 100644
> > --- a/lib/Kconfig.debug
> > +++ b/lib/Kconfig.debug
> > @@ -2400,6 +2400,18 @@ config HYPERV_TESTING
> > help
> > Select this option to enable Hyper-V vmbus testing.
> >
> > +config PKS_TESTING
> > + bool "PKey(S)upervisor testing"
>
> Seems like we need a space in there somewhere.
heheh... yea...
>
> > + pid = fork();
> > + if (pid == 0) {
> > + fd = open("/sys/kernel/debug/x86/run_pks", O_RDWR);
> > + if (fd < 0) {
> > + printf("cannot open file\n");
> > + return -1;
> > + }
> > +
>
> Will this return code make anybody mad? Should we have a nicer return
> code for when this is running on non-PKS hardware?
I'm not sure it will matter much but I think it is better to report the missing
file.[1]
>
> I'm not going to be too picky about this. I'll just ask one question:
> Has this found real bugs for you?
Many, especially regressions as things have changed.
>
> Reviewed-by: Dave Hansen
>
Thanks,
Ira
[1]
diff --git a/tools/testing/selftests/x86/test_pks.c
b/tools/testing/selftests/x86/test_pks.c
index 8037a2a9ff5f..11be4e212d54 100644
--- a/tools/testing/selftests/x86/test_pks.c
+++ b/tools/testing/selftests/x86/test_pks.c
@@ -11,6 +11,8 @@
#include
#include
+#define PKS_TEST_FILE "/sys/kernel/debug/x86/run_pks"
+
int main(void)
{
cpu_set_t cpuset;
@@ -25,9 +27,9 @@ int main(void)
pid = fork();
if (pid == 0) {
- fd = open("/sys/kernel/debug/x86/run_pks", O_RDWR);
+ fd = open(PKS_TEST_FILE, O_RDWR);
if (fd < 0) {
- printf("cannot open file\n");
+ printf("cannot open %s\n", PKS_TEST_FILE);
return -1;
}
@@ -45,9 +47,9 @@ int main(void)
} else {
sleep(2);
- fd = open("/sys/kernel/debug/x86/run_pks", O_RDWR);
+ fd = open(PKS_TEST_FILE, O_RDWR);
if (fd < 0) {
- printf("cannot open file\n");
+ printf("cannot open %s\n", PKS_TEST_FILE);
return -1;
}
[PATCH v2 0/1] fix all errors except one reported by dt_binding_check
v1 --> v2: 1. I'm sorry. I'm not familiar with the GPIO driver, which leads to a low-level mistake. Now, I rewrite the patch 6/6 in v1. For more detail, please refer: https://lore.kernel.org/linux-arm-kernel/49b680f8-d7d7-8ea3-894c-73cbfacc5...@huawei.com/T/#u v1: When people add multiple or common YAML files, they usually perform a full dt_binding_check. Unfortunately, some YAML files cannot pass the self-check. The errors or warning are listed below. It is necessary to eliminate them, so that people's time and energy are not wasted every time when execute comprehensive dt_binding_check. This error is fixed by Patch 1: /root/leizhen/linux-next/Documentation/devicetree/bindings/leds/leds-lp55xx.example.dt.yaml: led-controller@33: multi-led@2:color:0:0: 9 is greater than the maximum of 8 From schema: /root/leizhen/linux-next/Documentation/devicetree/bindings/leds/leds-lp55xx.yaml These errors are fixed by Patch 2: /root/leizhen/linux-next/Documentation/devicetree/bindings/chrome/google,cros-ec-typec.example.dt.yaml: ec@0: 'typec' does not match any of the regexes: 'pinctrl-[0-9]+' From schema: /root/leizhen/linux-next/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml /root/leizhen/linux-next/Documentation/devicetree/bindings/extcon/extcon-usbc-cros-ec.example.dt.yaml: cros-ec@0: 'extcon0', 'extcon1' do not match any of the regexes: 'pinctrl-[0-9]+' From schema: /root/leizhen/linux-next/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml /root/leizhen/linux-next/Documentation/devicetree/bindings/pwm/google,cros-ec-pwm.example.dt.yaml: cros-ec@0: 'ec-pwm' does not match any of the regexes: 'pinctrl-[0-9]+' From schema: /root/leizhen/linux-next/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml /root/leizhen/linux-next/Documentation/devicetree/bindings/regulator/google,cros-ec-regulator.example.dt.yaml: ec@0: '#address-cells', '#size-cells', 'regulator@0' do not match any of the regexes: 'pinctrl-[0-9]+' From schema: /root/leizhen/linux-next/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml /root/leizhen/linux-next/Documentation/devicetree/bindings/sound/google,cros-ec-codec.example.dt.yaml: cros-ec@0: '#address-cells', '#size-cells', 'ec-codec@1050' do not match any of the regexes: 'pinctrl-[0-9]+' From schema: /root/leizhen/linux-next/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml These errors are fixed by Patch 3 and 4: Documentation/devicetree/bindings/misc/olpc,xo1.75-ec.example.dts:21.13-30.11: Warning (spi_bus_bridge): /example-0/spi: incorrect #address-cells for SPI bus Documentation/devicetree/bindings/misc/olpc,xo1.75-ec.example.dts:21.13-30.11: Warning (spi_bus_bridge): /example-0/spi: incorrect #size-cells for SPI bus Documentation/devicetree/bindings/misc/olpc,xo1.75-ec.example.dt.yaml: Warning (spi_bus_reg): Failed prerequisite 'spi_bus_bridge' Patch 5 and 6 fix the dtbs_check errors detected by Documentation/devicetree/bindings/misc/olpc,xo1.75-ec.yaml arch/arm/boot/dts/mmp2.dtsi:472.23-480.6: Warning (spi_bus_bridge): /soc/apb@d400/spi@d4037000: incorrect #address-cells for SPI bus also defined at arch/arm/boot/dts/mmp2-olpc-xo-1-75.dts:225.7-237.3 arch/arm/boot/dts/mmp2.dtsi:472.23-480.6: Warning (spi_bus_bridge): /soc/apb@d400/spi@d4037000: incorrect #size-cells for SPI bus also defined at arch/arm/boot/dts/mmp2-olpc-xo-1-75.dts:225.7-237.3 arch/arm/boot/dts/mmp2-olpc-xo-1-75.dtb: Warning (spi_bus_reg): Failed prerequisite 'spi_bus_bridge' arch/arm/boot/dts/mmp2.dtsi:472.23-480.6: Warning (spi_bus_bridge): /soc/apb@d400/spi@d4037000: incorrect #address-cells for SPI bus also defined at arch/arm/boot/dts/mmp2-olpc-xo-1-75.dts:225.7-237.3 arch/arm/boot/dts/mmp2.dtsi:472.23-480.6: Warning (spi_bus_bridge): /soc/apb@d400/spi@d4037000: incorrect #size-cells for SPI bus also defined at arch/arm/boot/dts/mmp2-olpc-xo-1-75.dts:225.7-237.3 arch/arm/boot/dts/mmp2-olpc-xo-1-75.dt.yaml: Warning (spi_bus_reg): Failed prerequisite 'spi_bus_bridge' /root/leizhen/linux-next/arch/arm/boot/dts/mmp2-olpc-xo-1-75.dt.yaml: slave: 'cmd-gpios' is a required property From schema: /root/leizhen/linux-next/Documentation/devicetree/bindings/misc/olpc,xo1.75-ec.yaml /root/leizhen/linux-next/arch/arm/boot/dts/mmp2-olpc-xo-1-75.dt.yaml: slave: 'cmd-gpio' does not match any of the regexes: 'pinctrl-[0-9]+' From schema: /root/leizhen/linux-next/Documentation/devicetree/bindings/misc/olpc,xo1.75-ec.yaml I have no good idea for this one, so leave it. Documentation/devicetree/bindings/pci/xilinx-versal-cpm.example.dts:43.62-47.30: Warning (pci_device_reg): /example-0/versal/pcie@fca1/interrupt-controller: missing PCI reg property Zhen Lei (1): dt-bindings: misc: add support for both property names cmd-gpios and cmd-gpio Documentation/devicetree/bindings/misc/olpc,xo1.75-ec.yaml | 14 ++ 1 file changed, 10 insertions(+), 4
Re: [PATCH] net: sockmap: Don't call bpf_prog_put() on NULL pointer
Jakub Sitnicki wrote:
> On Mon, Oct 12, 2020 at 07:09 PM CEST, Alex Dewar wrote:
> > If bpf_prog_inc_not_zero() fails for skb_parser, then bpf_prog_put() is
> > called unconditionally on skb_verdict, even though it may be NULL. Fix
> > and tidy up error path.
> >
> > Addresses-Coverity-ID: 1497799: Null pointer dereferences (FORWARD_NULL)
> > Fixes: 743df8b7749f ("bpf, sockmap: Check skb_verdict and skb_parser
> > programs explicitly")
> > Signed-off-by: Alex Dewar
> > ---
>
> Acked-by: Jakub Sitnicki
Thanks.
Jakub, any opinions on if we should just throw an error if users try to
add a sock to a map with a parser but no verdict? At the moment we fall
through and add the socket, but it wont do any receive parsing/verdict.
At the moment I think its fine with above fix. The useful cases for RX
are parser+verdict, verdict, and empty. Where empty is just used for
redirects or other socket account tricks. Just something to keep in mind.
Acked-by: John Fastabend
Re: [PATCH v2 1/7] staging: qlge: replace ql_* with qlge_* to avoid namespace clashes with other qlogic drivers
On Thu, Oct 15, 2020 at 12:26:28PM +0800, Coiby Xu wrote: On Thu, Oct 15, 2020 at 10:01:36AM +0900, Benjamin Poirier wrote: On 2020-10-14 18:43 +0800, Coiby Xu wrote: To avoid namespace clashes with other qlogic drivers and also for the sake of naming consistency, use the "qlge_" prefix as suggested in drivers/staging/qlge/TODO. Suggested-by: Benjamin Poirier Signed-off-by: Coiby Xu --- drivers/staging/qlge/TODO |4 - drivers/staging/qlge/qlge.h | 190 ++-- drivers/staging/qlge/qlge_dbg.c | 1073 --- drivers/staging/qlge/qlge_ethtool.c | 231 ++--- drivers/staging/qlge/qlge_main.c| 1257 +-- drivers/staging/qlge/qlge_mpi.c | 352 6 files changed, 1551 insertions(+), 1556 deletions(-) diff --git a/drivers/staging/qlge/TODO b/drivers/staging/qlge/TODO index f93f7428f5d5..5ac55664c3e2 100644 --- a/drivers/staging/qlge/TODO +++ b/drivers/staging/qlge/TODO @@ -28,10 +28,6 @@ * the driver has a habit of using runtime checks where compile time checks are possible (ex. ql_free_rx_buffers(), ql_alloc_rx_buffers()) * reorder struct members to avoid holes if it doesn't impact performance -* in terms of namespace, the driver uses either qlge_, ql_ (used by - other qlogic drivers, with clashes, ex: ql_sem_spinlock) or nothing (with - clashes, ex: struct ob_mac_iocb_req). Rename everything to use the "qlge_" - prefix. You only renamed ql -> qlge. The prefix needs to be added where there is currently none like the second example of that text. Thank you for reminding me of the second example! Besides, the next patch reintroduces the name struct ql_adapter. Oh, there is still a left-over ql_adapter in qlge.h (I renamed ql->qlge after initializing the devlink framework earlier but did a git rebase to make the order of the changes more reasonable). Thank you for the reminding! Btw, is there a way to configure kernel building to let the compiler discover this kind of issue automatically? -- Best regards, Coiby -- Best regards, Coiby
Re: [PATCH v6 69/80] IB/srpt: docs: add a description for cq_size member
On 10/13/20 4:54 AM, Mauro Carvalho Chehab wrote:
> Changeset c804af2c1d31 ("IB/srpt: use new shared CQ mechanism")
> added a new member for struct srpt_rdma_ch, but didn't add the
> corresponding kernel-doc markup, as repoted when doing
> "make htmldocs":
> ./drivers/infiniband/ulp/srpt/ib_srpt.h:331: warning: Function
> parameter or member 'cq_size' not described in 'srpt_rdma_ch'
>
> Add a description for it.
>
> Fixes: c804af2c1d31 ("IB/srpt: use new shared CQ mechanism")
> Signed-off-by: Mauro Carvalho Chehab
> ---
> drivers/infiniband/ulp/srpt/ib_srpt.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/infiniband/ulp/srpt/ib_srpt.h
> b/drivers/infiniband/ulp/srpt/ib_srpt.h
> index 41435a699b53..e5d6af14d073 100644
> --- a/drivers/infiniband/ulp/srpt/ib_srpt.h
> +++ b/drivers/infiniband/ulp/srpt/ib_srpt.h
> @@ -256,6 +256,7 @@ enum rdma_ch_state {
> * @rdma_cm:See below.
> * @rdma_cm.cm_id: RDMA CM ID associated with the channel.
> * @cq:IB completion queue for this channel.
> + * @cq_size:Size of the @cq pool.
> * @zw_cqe: Zero-length write CQE.
> * @rcu: RCU head.
> * @kref: kref for this channel.
That doesn't seem correct to me. My understanding is that cq_size is the
number of CQEs in @cq. @cq is a completion queue and not a CQ pool.
Bart.
Re: [PATCH] opp: Don't always remove static OPPs in _of_add_opp_table_v1()
On 15-10-20, 02:35, Aisheng Dong wrote:
> Hi Viresh
>
> Thanks for the quick fix.
>
> > From: Viresh Kumar
> > Sent: Wednesday, October 14, 2020 12:26 PM
> >
> > The patch missed returning 0 early in case of success and hence the static
> > OPPs
> > got removed by mistake. Fix it.
> >
> > Fixes: 90d46d71cce2 ("opp: Handle multiple calls for same OPP table in
> > _of_add_opp_table_v1()")
> > Reported-by: Aisheng Dong
> > Signed-off-by: Viresh Kumar
>
> Tested-by: Dong Aisheng
Thanks.
Rafael: Please apply this one directly for 5.10-rc. Thanks.
--
viresh
Re: [PATCH v2 1/7] staging: qlge: replace ql_* with qlge_* to avoid namespace clashes with other qlogic drivers
On Thu, Oct 15, 2020 at 10:01:36AM +0900, Benjamin Poirier wrote: On 2020-10-14 18:43 +0800, Coiby Xu wrote: To avoid namespace clashes with other qlogic drivers and also for the sake of naming consistency, use the "qlge_" prefix as suggested in drivers/staging/qlge/TODO. Suggested-by: Benjamin Poirier Signed-off-by: Coiby Xu --- drivers/staging/qlge/TODO |4 - drivers/staging/qlge/qlge.h | 190 ++-- drivers/staging/qlge/qlge_dbg.c | 1073 --- drivers/staging/qlge/qlge_ethtool.c | 231 ++--- drivers/staging/qlge/qlge_main.c| 1257 +-- drivers/staging/qlge/qlge_mpi.c | 352 6 files changed, 1551 insertions(+), 1556 deletions(-) diff --git a/drivers/staging/qlge/TODO b/drivers/staging/qlge/TODO index f93f7428f5d5..5ac55664c3e2 100644 --- a/drivers/staging/qlge/TODO +++ b/drivers/staging/qlge/TODO @@ -28,10 +28,6 @@ * the driver has a habit of using runtime checks where compile time checks are possible (ex. ql_free_rx_buffers(), ql_alloc_rx_buffers()) * reorder struct members to avoid holes if it doesn't impact performance -* in terms of namespace, the driver uses either qlge_, ql_ (used by - other qlogic drivers, with clashes, ex: ql_sem_spinlock) or nothing (with - clashes, ex: struct ob_mac_iocb_req). Rename everything to use the "qlge_" - prefix. You only renamed ql -> qlge. The prefix needs to be added where there is currently none like the second example of that text. Thank you for reminding me of the second example! Besides, the next patch reintroduces the name struct ql_adapter. Oh, there is still a left-over ql_adapter in qlge.h (I renamed ql->qlge after initializing the devlink framework earlier but did a git rebase to make the order of the changes more reasonable). Thank you for the reminding! -- Best regards, Coiby
Re: [PATCH v2 2/7] staging: qlge: Initialize devlink health dump framework
On Wed, Oct 14, 2020 at 04:08:46PM +0300, Dan Carpenter wrote:
On Wed, Oct 14, 2020 at 06:43:01PM +0800, Coiby Xu wrote:
static int qlge_probe(struct pci_dev *pdev,
const struct pci_device_id *pci_entry)
{
struct net_device *ndev = NULL;
struct qlge_adapter *qdev = NULL;
+ struct devlink *devlink;
static int cards_found;
int err = 0;
- ndev = alloc_etherdev_mq(sizeof(struct qlge_adapter),
+ devlink = devlink_alloc(_devlink_ops, sizeof(struct qlge_adapter));
+ if (!devlink)
+ return -ENOMEM;
+
+ qdev = devlink_priv(devlink);
+
+ ndev = alloc_etherdev_mq(sizeof(struct qlge_netdev_priv),
min(MAX_CPUS,
netif_get_num_default_rss_queues()));
if (!ndev)
- return -ENOMEM;
+ goto devlink_free;
- err = qlge_init_device(pdev, ndev, cards_found);
- if (err < 0) {
- free_netdev(ndev);
- return err;
In the old code, if qlge_init_device() fails then it frees "ndev".
- }
+ qdev->ndev = ndev;
+ err = qlge_init_device(pdev, qdev, cards_found);
+ if (err < 0)
+ goto devlink_free;
But the patch introduces a new resource leak.
Thank you for spotting this issue!
- qdev = netdev_priv(ndev);
SET_NETDEV_DEV(ndev, >dev);
ndev->hw_features = NETIF_F_SG |
NETIF_F_IP_CSUM |
@@ -4611,8 +4619,14 @@ static int qlge_probe(struct pci_dev *pdev,
qlge_release_all(pdev);
pci_disable_device(pdev);
free_netdev(ndev);
- return err;
+ goto devlink_free;
}
+
+ err = devlink_register(devlink, >dev);
+ if (err)
+ goto devlink_free;
+
+ qlge_health_create_reporters(qdev);
/* Start up the timer to trigger EEH if
* the bus goes dead
*/
@@ -4623,6 +4637,10 @@ static int qlge_probe(struct pci_dev *pdev,
atomic_set(>lb_count, 0);
cards_found++;
return 0;
+
+devlink_free:
+ devlink_free(devlink);
+ return err;
}
The best way to write error handling code is keep tracke of the most
recent allocation which was allocated successfully.
one = alloc();
if (!one)
return -ENOMEM; // <-- nothing allocated successfully
two = alloc();
if (!two) {
ret = -ENOMEM;
goto free_one; // <-- one was allocated successfully
// Notice that the label name says what
// the goto does.
}
three = alloc();
if (!three) {
ret = -ENOMEM;
goto free_two; // <-- two allocated, two freed.
}
...
return 0;
free_two:
free(two);
free_one:
free(one);
return ret;
Thank you for teaching me this pattern!
In the old code qlge_probe() freed things before returning, and that's
fine if there is only two allocations in the function but when there are
three or more allocations, then use gotos to unwind.
Ideally there would be a ql_deinit_device() function to mirror the
ql_init_device() function. The ql_init_device() is staging quality
code with leaks and bad label names. It should be re-written to free
things one step at a time instead of calling ql_release_all().
I'll see how I can improve ql_init_device. Thank you for the suggestion!
Anyway, let's not introduce new leaks at least.
regards,
dan carpenter
--
Best regards,
Coiby
Re: [PATCH v7 3/3] iommu/tegra-smmu: Add PCI support
On Wed, Oct 14, 2020 at 06:42:36PM +0100, Robin Murphy wrote:
> On 2020-10-09 17:19, Nicolin Chen wrote:
> > This patch simply adds support for PCI devices.
> >
> > Reviewed-by: Dmitry Osipenko
> > Tested-by: Dmitry Osipenko
> > Signed-off-by: Nicolin Chen
> > ---
> >
> > Changelog
> > v6->v7
> > * Renamed goto labels, suggested by Thierry.
> > v5->v6
> > * Added Dmitry's Reviewed-by and Tested-by.
> > v4->v5
> > * Added Dmitry's Reviewed-by
> > v3->v4
> > * Dropped !iommu_present() check
> > * Added CONFIG_PCI check in the exit path
> > v2->v3
> > * Replaced ternary conditional operator with if-else in .device_group()
> > * Dropped change in tegra_smmu_remove()
> > v1->v2
> > * Added error-out labels in tegra_smmu_probe()
> > * Dropped pci_request_acs() since IOMMU core would call it.
> >
> > drivers/iommu/tegra-smmu.c | 35 +--
> > 1 file changed, 25 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/iommu/tegra-smmu.c b/drivers/iommu/tegra-smmu.c
> > index be29f5977145..2941d6459076 100644
> > --- a/drivers/iommu/tegra-smmu.c
> > +++ b/drivers/iommu/tegra-smmu.c
> > @@ -10,6 +10,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -865,7 +866,11 @@ static struct iommu_group
> > *tegra_smmu_device_group(struct device *dev)
> > group->smmu = smmu;
> > group->soc = soc;
> > - group->group = iommu_group_alloc();
> > + if (dev_is_pci(dev))
> > + group->group = pci_device_group(dev);
>
> Just to check, is it OK to have two or more swgroups "owning" the same
> iommu_group if an existing one gets returned here? It looks like that might
> not play nice with the use of iommu_group_set_iommudata().
Do you mean by "gets returned here" the "IS_ERR" check below?
> Robin.
>
> > + else
> > + group->group = generic_device_group(dev);
> > +
> > if (IS_ERR(group->group)) {
> > devm_kfree(smmu->dev, group);
> > mutex_unlock(>lock);
Re: [PATCH RFC V3 7/9] x86/entry: Preserve PKRS MSR across exceptions
On Wed, Oct 14, 2020 at 09:06:44PM -0700, Dave Hansen wrote: > On 10/14/20 8:46 PM, Ira Weiny wrote: > > On Tue, Oct 13, 2020 at 11:52:32AM -0700, Dave Hansen wrote: > >> On 10/9/20 12:42 PM, ira.we...@intel.com wrote: > >>> @@ -341,6 +341,9 @@ noinstr void irqentry_enter(struct pt_regs *regs, > >>> irqentry_state_t *state) > >>> /* Use the combo lockdep/tracing function */ > >>> trace_hardirqs_off(); > >>> instrumentation_end(); > >>> + > >>> +done: > >>> + irq_save_pkrs(state); > >>> } > >> One nit: This saves *and* sets PKRS. It's not obvious from the call > >> here that PKRS is altered at this site. Seems like there could be a > >> better name. > >> > >> Even if we did: > >> > >>irq_save_set_pkrs(state, INIT_VAL); > >> > >> It would probably compile down to the same thing, but be *really* > >> obvious what's going on. > > I suppose that is true. But I think it is odd having a parameter which is > > the > > same for every call site. > > Well, it depends on what you optimize for. I'm trying to optimize for > the code being understood quickly the first time someone reads it. To > me, that's more important than minimizing the number of function > parameters (which are essentially free). > Agreed. Sorry I was not trying to be confrontational. There is just enough other things which are going to take me time to get right I need to focus on them... :-D Sorry, Ira
Re: [PATCH RFC V3 8/9] x86/fault: Report the PKRS state on fault
On Tue, Oct 13, 2020 at 11:56:53AM -0700, Dave Hansen wrote:
> > @@ -548,6 +549,11 @@ show_fault_oops(struct pt_regs *regs, unsigned long
> > error_code, unsigned long ad
> > (error_code & X86_PF_PK)? "protection keys violation" :
> >"permissions violation");
> >
> > +#ifdef CONFIG_ARCH_HAS_SUPERVISOR_PKEYS
> > + if (irq_state && (error_code & X86_PF_PK))
> > + pr_alert("PKRS: 0x%x\n", irq_state->pkrs);
> > +#endif
>
> This means everyone will see 'PKRS: 0x0', even if they're on non-PKS
> hardware. I think I'd rather have this only show PKRS when we're on
> cpu_feature_enabled(PKS) hardware.
Good catch, thanks.
>
> ...
> > @@ -1148,14 +1156,15 @@ static int fault_in_kernel_space(unsigned long
> > address)
> > */
> > static void
> > do_kern_addr_fault(struct pt_regs *regs, unsigned long hw_error_code,
> > - unsigned long address)
> > + unsigned long address, irqentry_state_t *irq_state)
> > {
> > /*
> > -* Protection keys exceptions only happen on user pages. We
> > -* have no user pages in the kernel portion of the address
> > -* space, so do not expect them here.
> > +* If protection keys are not enabled for kernel space
> > +* do not expect Pkey errors here.
> > */
>
> Let's fix the double-negative:
>
> /*
>* PF_PK is only expected on kernel addresses whenn
>* supervisor pkeys are enabled:
>*/
done. thanks.
>
> > - WARN_ON_ONCE(hw_error_code & X86_PF_PK);
> > + if (!IS_ENABLED(CONFIG_ARCH_HAS_SUPERVISOR_PKEYS) ||
> > + !cpu_feature_enabled(X86_FEATURE_PKS))
> > + WARN_ON_ONCE(hw_error_code & X86_PF_PK);
>
> Yeah, please stick X86_FEATURE_PKS in disabled-features so you can use
> cpu_feature_enabled(X86_FEATURE_PKS) by itself here..
done.
thanks,
Ira
Re: [PATCH RFC V3 7/9] x86/entry: Preserve PKRS MSR across exceptions
On 10/14/20 8:46 PM, Ira Weiny wrote: > On Tue, Oct 13, 2020 at 11:52:32AM -0700, Dave Hansen wrote: >> On 10/9/20 12:42 PM, ira.we...@intel.com wrote: >>> @@ -341,6 +341,9 @@ noinstr void irqentry_enter(struct pt_regs *regs, >>> irqentry_state_t *state) >>> /* Use the combo lockdep/tracing function */ >>> trace_hardirqs_off(); >>> instrumentation_end(); >>> + >>> +done: >>> + irq_save_pkrs(state); >>> } >> One nit: This saves *and* sets PKRS. It's not obvious from the call >> here that PKRS is altered at this site. Seems like there could be a >> better name. >> >> Even if we did: >> >> irq_save_set_pkrs(state, INIT_VAL); >> >> It would probably compile down to the same thing, but be *really* >> obvious what's going on. > I suppose that is true. But I think it is odd having a parameter which is the > same for every call site. Well, it depends on what you optimize for. I'm trying to optimize for the code being understood quickly the first time someone reads it. To me, that's more important than minimizing the number of function parameters (which are essentially free).
Re: [f2fs-dev] [PATCH 2/2] f2fs: add F2FS_IOC_SET_COMPRESS_OPTION ioctl
On Wed, Oct 14, 2020 at 11:27:30AM +0900, Daeho Jeong wrote: > > f2fs_readonly() is redundant with mnt_want_write_file(). > > > > Also, shouldn't this require a writable file descriptor? As-is, this ioctl > > can > > be called on a file owned by another user, as long as the caller has read > > access. > > > > Note: if you change this to require a writable file descriptor, then > > f2fs_readonly(), mnt_want_write_file(), and IS_IMMUTABLE() all would no > > longer > > be needed. > > I agree that f2fs_readonly() is redundant. > But, sorry, I don't get the rest. I thought mnt_want_write_file() is a > way to check whether the caller has a proper write permission or not. > I think just using mnt_want_write_file() is enough for this ioctl. Am > I missing something? mnt_want_write_file() checks for write permission to the mount, not to the file. I think this ioctl wants what f2fs_sec_trim_file() does: if (!(filp->f_mode & FMODE_WRITE)) return -EBADF; file_start_write(filp); inode_lock(inode); ... inode_unlock(inode); file_end_write(filp); After all you shouldn't be able to change the compression options of a file given only read access to it, right? > > I don't think the check for i_writecount == 1 accomplishes anything because > > it > > just means there are no *other* writable file descriptors. It doesn't mean > > that > > some other thread isn't concurrently trying to write to this same file > > descriptor. So the lock needs to be enough. Is it? > > This is to detect any possibility of other threads mmap-ing and > writing the file. > Using only inode lock is not enough to prevent them from making dirty pages. Well, as I said, i_writecount == 1 doesn't guarantee that other threads aren't mmap'ing or writing to the file. It just guarantees that there aren't any other writable file descriptors. (Actually, file descriptions.) Multiple threads can be using the same file descriptor (or the same file description) concurrently. - Eric
Re: fw_devlink on will break all snps,dw-apb-gpio users
On Wed, 14 Oct 2020 10:29:36 -0700
Saravana Kannan wrote:
> CAUTION: Email originated externally, do not click links or open attachments
> unless you recognize the sender and know the content is safe.
>
>
> On Wed, Oct 14, 2020 at 4:12 AM Jisheng Zhang
> wrote:
> >
> > Hi,
> >
> > If set fw_devlink as on, any consumers of dw apb gpio won't probe.
> >
> > The related dts looks like:
> >
> > gpio0: gpio@2400 {
> >compatible = "snps,dw-apb-gpio";
> >#address-cells = <1>;
> >#size-cells = <0>;
> >
> >porta: gpio-port@0 {
> > compatible = "snps,dw-apb-gpio-port";
> > gpio-controller;
> > #gpio-cells = <2>;
> > ngpios = <32>;
> > reg = <0>;
> >};
> > };
> >
> > device_foo {
> > status = "okay"
> > ...;
> > reset-gpio = <, 0, GPIO_ACTIVE_HIGH>;
> > };
> >
> > If I change the reset-gpio property to use another kind of gpio phandle,
> > e.g gpio expander, then device_foo can be probed successfully.
> >
> > The gpio expander dt node looks like:
> >
> > expander3: gpio@44 {
> > compatible = "fcs,fxl6408";
> > pinctrl-names = "default";
> > pinctrl-0 = <_pmux>;
> > reg = <0x44>;
> > gpio-controller;
> > #gpio-cells = <2>;
> > interrupt-parent = <>;
> > interrupts = <23 IRQ_TYPE_NONE>;
> > interrupt-controller;
> > #interrupt-cells = <2>;
> > };
> >
> > The common pattern looks like the devlink can't cope with suppliers from
> > child dt node.
>
> fw_devlink doesn't have any problem dealing with child devices being
> suppliers. The problem with your case is that the
> drivers/gpio/gpio-dwapb.c driver directly parses the child nodes and
> never creates struct devices for them. If you have a node with
> compatible string, fw_devlink expects you to create and probe a struct
> device for it. So change your driver to add the child devices as
> devices instead of just parsing the node directly and doing stuff with
> it.
>
> Either that, or stop putting "compatible" string in a node if you
> don't plan to actually treat it as a device -- but that's too late for
> this driver (it needs to be backward compatible). So change the driver
> to add of_platform_populate() and write a driver that probes
> "snps,dw-apb-gpio-port".
>
Thanks for the information. The "snps,dw-apb-gpio-port" is never used,
so I just sent out a series to remove it.
Thanks
Re: [PATCH v1 02/29] virtio-mem: simplify calculation in virtio_mem_mb_state_prepare_next_mb()
On Mon, Oct 12, 2020 at 02:52:56PM +0200, David Hildenbrand wrote:
>We actually need one byte less (next_mb_id is exclusive, first_mb_id is
>inclusive). Simplify.
>
>Cc: "Michael S. Tsirkin"
>Cc: Jason Wang
>Cc: Pankaj Gupta
>Signed-off-by: David Hildenbrand
>---
> drivers/virtio/virtio_mem.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
>diff --git a/drivers/virtio/virtio_mem.c b/drivers/virtio/virtio_mem.c
>index a1f5bf7a571a..670b3faf412d 100644
>--- a/drivers/virtio/virtio_mem.c
>+++ b/drivers/virtio/virtio_mem.c
>@@ -257,8 +257,8 @@ static enum virtio_mem_mb_state
>virtio_mem_mb_get_state(struct virtio_mem *vm,
> */
> static int virtio_mem_mb_state_prepare_next_mb(struct virtio_mem *vm)
> {
>- unsigned long old_bytes = vm->next_mb_id - vm->first_mb_id + 1;
>- unsigned long new_bytes = vm->next_mb_id - vm->first_mb_id + 2;
>+ unsigned long old_bytes = vm->next_mb_id - vm->first_mb_id;
>+ unsigned long new_bytes = old_bytes + 1;
This is correct.
So this looks more like a fix?
> int old_pages = PFN_UP(old_bytes);
> int new_pages = PFN_UP(new_bytes);
> uint8_t *new_mb_state;
>--
>2.26.2
--
Wei Yang
Help you, Help me
[PATCH 8/8] dt-bindings: gpio: dw-apb: remove never-used "snps,dw-apb-gpio-port"
The compatible string is never used.
Signed-off-by: Jisheng Zhang
---
Documentation/devicetree/bindings/gpio/snps,dw-apb-gpio.yaml | 5 -
1 file changed, 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/gpio/snps,dw-apb-gpio.yaml
b/Documentation/devicetree/bindings/gpio/snps,dw-apb-gpio.yaml
index 1240f6289249..76e7b07d592f 100644
--- a/Documentation/devicetree/bindings/gpio/snps,dw-apb-gpio.yaml
+++ b/Documentation/devicetree/bindings/gpio/snps,dw-apb-gpio.yaml
@@ -50,9 +50,6 @@ patternProperties:
"^gpio-(port|controller)@[0-9a-f]+$":
type: object
properties:
- compatible:
-const: snps,dw-apb-gpio-port
-
reg:
maxItems: 1
@@ -111,7 +108,6 @@ examples:
#size-cells = <0>;
porta: gpio-port@0 {
-compatible = "snps,dw-apb-gpio-port";
reg = <0>;
gpio-controller;
#gpio-cells = <2>;
@@ -123,7 +119,6 @@ examples:
};
portb: gpio-port@1 {
-compatible = "snps,dw-apb-gpio-port";
reg = <1>;
gpio-controller;
#gpio-cells = <2>;
--
2.28.0
[PATCH 1/8] ARM: dts: berlin: Remove compatible string from dw apb gpio port
The compatible string is never used.
Signed-off-by: Jisheng Zhang
---
arch/arm/boot/dts/berlin2.dtsi | 6 --
arch/arm/boot/dts/berlin2cd.dtsi | 6 --
arch/arm/boot/dts/berlin2q.dtsi | 6 --
3 files changed, 18 deletions(-)
diff --git a/arch/arm/boot/dts/berlin2.dtsi b/arch/arm/boot/dts/berlin2.dtsi
index 6194857f8a02..02c9b8b5b633 100644
--- a/arch/arm/boot/dts/berlin2.dtsi
+++ b/arch/arm/boot/dts/berlin2.dtsi
@@ -188,7 +188,6 @@ gpio0: gpio@400 {
#size-cells = <0>;
porta: gpio-port@0 {
- compatible = "snps,dw-apb-gpio-port";
gpio-controller;
#gpio-cells = <2>;
snps,nr-gpios = <8>;
@@ -206,7 +205,6 @@ gpio1: gpio@800 {
#size-cells = <0>;
portb: gpio-port@1 {
- compatible = "snps,dw-apb-gpio-port";
gpio-controller;
#gpio-cells = <2>;
snps,nr-gpios = <8>;
@@ -224,7 +222,6 @@ gpio2: gpio@c00 {
#size-cells = <0>;
portc: gpio-port@2 {
- compatible = "snps,dw-apb-gpio-port";
gpio-controller;
#gpio-cells = <2>;
snps,nr-gpios = <8>;
@@ -242,7 +239,6 @@ gpio3: gpio@1000 {
#size-cells = <0>;
portd: gpio-port@3 {
- compatible = "snps,dw-apb-gpio-port";
gpio-controller;
#gpio-cells = <2>;
snps,nr-gpios = <8>;
@@ -443,7 +439,6 @@ sm_gpio1: gpio@5000 {
#size-cells = <0>;
portf: gpio-port@5 {
- compatible = "snps,dw-apb-gpio-port";
gpio-controller;
#gpio-cells = <2>;
snps,nr-gpios = <8>;
@@ -458,7 +453,6 @@ sm_gpio0: gpio@c000 {
#size-cells = <0>;
porte: gpio-port@4 {
- compatible = "snps,dw-apb-gpio-port";
gpio-controller;
#gpio-cells = <2>;
snps,nr-gpios = <8>;
diff --git a/arch/arm/boot/dts/berlin2cd.dtsi b/arch/arm/boot/dts/berlin2cd.dtsi
index 6f30d7eb3b41..f7698ab97abf 100644
--- a/arch/arm/boot/dts/berlin2cd.dtsi
+++ b/arch/arm/boot/dts/berlin2cd.dtsi
@@ -178,7 +178,6 @@ gpio0: gpio@400 {
#size-cells = <0>;
porta: gpio-port@0 {
- compatible = "snps,dw-apb-gpio-port";
gpio-controller;
#gpio-cells = <2>;
snps,nr-gpios = <8>;
@@ -196,7 +195,6 @@ gpio1: gpio@800 {
#size-cells = <0>;
portb: gpio-port@1 {
- compatible = "snps,dw-apb-gpio-port";
gpio-controller;
#gpio-cells = <2>;
snps,nr-gpios = <8>;
@@ -214,7 +212,6 @@ gpio2: gpio@c00 {
#size-cells = <0>;
portc: gpio-port@2 {
- compatible = "snps,dw-apb-gpio-port";
gpio-controller;
#gpio-cells = <2>;
snps,nr-gpios = <8>;
@@ -232,7 +229,6 @@ gpio3: gpio@1000 {
#size-cells = <0>;
portd: gpio-port@3 {
- compatible = "snps,dw-apb-gpio-port";
gpio-controller;
#gpio-cells = <2>;
snps,nr-gpios = <8>;
@@ -470,7 +466,6 @@ sm_gpio1: gpio@5000 {
#size-cells = <0>;
portf: gpio-port@5 {
- compatible = "snps,dw-apb-gpio-port";
gpio-controller;
#gpio-cells = <2>;
[PATCH 5/8] arm64: dts: hip05: Remove compatible string from dw apb gpio port
The compatible string is never used.
Signed-off-by: Jisheng Zhang
---
arch/arm64/boot/dts/hisilicon/hip05.dtsi | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm64/boot/dts/hisilicon/hip05.dtsi
b/arch/arm64/boot/dts/hisilicon/hip05.dtsi
index bc49955360db..390225f8979c 100644
--- a/arch/arm64/boot/dts/hisilicon/hip05.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hip05.dtsi
@@ -332,7 +332,6 @@ peri_gpio0: gpio@802e {
status = "disabled";
porta: gpio-controller@0 {
- compatible = "snps,dw-apb-gpio-port";
gpio-controller;
#gpio-cells = <2>;
snps,nr-gpios = <32>;
@@ -351,7 +350,6 @@ peri_gpio1: gpio@802f {
status = "disabled";
portb: gpio-controller@0 {
- compatible = "snps,dw-apb-gpio-port";
gpio-controller;
#gpio-cells = <2>;
snps,nr-gpios = <32>;
--
2.28.0
[PATCH 6/8] arm: dts: socfpga: Remove compatible string from dw apb gpio port
The compatible string is never used.
Signed-off-by: Jisheng Zhang
---
arch/arm64/boot/dts/intel/socfpga_agilex.dtsi | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm64/boot/dts/intel/socfpga_agilex.dtsi
b/arch/arm64/boot/dts/intel/socfpga_agilex.dtsi
index 9d7f19e97df7..757c53ffe345 100644
--- a/arch/arm64/boot/dts/intel/socfpga_agilex.dtsi
+++ b/arch/arm64/boot/dts/intel/socfpga_agilex.dtsi
@@ -199,7 +199,6 @@ gpio0: gpio@ffc03200 {
status = "disabled";
porta: gpio-controller@0 {
- compatible = "snps,dw-apb-gpio-port";
gpio-controller;
#gpio-cells = <2>;
snps,nr-gpios = <24>;
@@ -219,7 +218,6 @@ gpio1: gpio@ffc03300 {
status = "disabled";
portb: gpio-controller@0 {
- compatible = "snps,dw-apb-gpio-port";
gpio-controller;
#gpio-cells = <2>;
snps,nr-gpios = <24>;
--
2.28.0
[PATCH 0/8] remove never-used "snps,dw-apb-gpio-port"
The "snps,dw-apb-gpio-port" is never used. Jisheng Zhang (8): ARM: dts: berlin: Remove compatible string from dw apb gpio port ARM: dts: socfpga: Remove compatible string from dw apb gpio port arm64: dts: apm: remove compatible string from dw apb gpio port arm64: dts: bitmain: Remove compatible string from dw apb gpio port arm64: dts: hip05: Remove compatible string from dw apb gpio port arm: dts: socfpga: Remove compatible string from dw apb gpio port arm64: dts: synaptics: Remove compatible string from dw apb gpio port dt-bindings: gpio: dw-apb: remove never-used "snps,dw-apb-gpio-port" .../devicetree/bindings/gpio/snps,dw-apb-gpio.yaml | 5 - arch/arm/boot/dts/berlin2.dtsi | 6 -- arch/arm/boot/dts/berlin2cd.dtsi| 6 -- arch/arm/boot/dts/berlin2q.dtsi | 6 -- arch/arm/boot/dts/socfpga.dtsi | 3 --- arch/arm/boot/dts/socfpga_arria10.dtsi | 3 --- arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi | 2 -- arch/arm64/boot/dts/apm/apm-shadowcat.dtsi | 1 - arch/arm64/boot/dts/apm/apm-storm.dtsi | 1 - arch/arm64/boot/dts/bitmain/bm1880.dtsi | 3 --- arch/arm64/boot/dts/hisilicon/hip05.dtsi| 2 -- arch/arm64/boot/dts/intel/socfpga_agilex.dtsi | 2 -- arch/arm64/boot/dts/synaptics/as370.dtsi| 2 -- arch/arm64/boot/dts/synaptics/berlin4ct.dtsi| 6 -- 14 files changed, 48 deletions(-) -- 2.28.0
[PATCH 7/8] arm64: dts: synaptics: Remove compatible string from dw apb gpio port
The compatible string is never used.
Signed-off-by: Jisheng Zhang
---
arch/arm64/boot/dts/synaptics/as370.dtsi | 2 --
arch/arm64/boot/dts/synaptics/berlin4ct.dtsi | 6 --
2 files changed, 8 deletions(-)
diff --git a/arch/arm64/boot/dts/synaptics/as370.dtsi
b/arch/arm64/boot/dts/synaptics/as370.dtsi
index addeb0efc616..f29b21f930b9 100644
--- a/arch/arm64/boot/dts/synaptics/as370.dtsi
+++ b/arch/arm64/boot/dts/synaptics/as370.dtsi
@@ -140,7 +140,6 @@ gpio0: gpio@1800 {
#size-cells = <0>;
porta: gpio-port@0 {
- compatible = "snps,dw-apb-gpio-port";
gpio-controller;
#gpio-cells = <2>;
snps,nr-gpios = <32>;
@@ -158,7 +157,6 @@ gpio1: gpio@2000 {
#size-cells = <0>;
portb: gpio-port@1 {
- compatible = "snps,dw-apb-gpio-port";
gpio-controller;
#gpio-cells = <2>;
snps,nr-gpios = <32>;
diff --git a/arch/arm64/boot/dts/synaptics/berlin4ct.dtsi
b/arch/arm64/boot/dts/synaptics/berlin4ct.dtsi
index 15625b99e336..4b563c0e015e 100644
--- a/arch/arm64/boot/dts/synaptics/berlin4ct.dtsi
+++ b/arch/arm64/boot/dts/synaptics/berlin4ct.dtsi
@@ -137,7 +137,6 @@ gpio0: gpio@400 {
#size-cells = <0>;
porta: gpio-port@0 {
- compatible = "snps,dw-apb-gpio-port";
gpio-controller;
#gpio-cells = <2>;
snps,nr-gpios = <32>;
@@ -155,7 +154,6 @@ gpio1: gpio@800 {
#size-cells = <0>;
portb: gpio-port@1 {
- compatible = "snps,dw-apb-gpio-port";
gpio-controller;
#gpio-cells = <2>;
snps,nr-gpios = <32>;
@@ -173,7 +171,6 @@ gpio2: gpio@c00 {
#size-cells = <0>;
portc: gpio-port@2 {
- compatible = "snps,dw-apb-gpio-port";
gpio-controller;
#gpio-cells = <2>;
snps,nr-gpios = <32>;
@@ -191,7 +188,6 @@ gpio3: gpio@1000 {
#size-cells = <0>;
portd: gpio-port@3 {
- compatible = "snps,dw-apb-gpio-port";
gpio-controller;
#gpio-cells = <2>;
snps,nr-gpios = <32>;
@@ -266,7 +262,6 @@ sm_gpio0: gpio@8000 {
#size-cells = <0>;
porte: gpio-port@4 {
- compatible = "snps,dw-apb-gpio-port";
gpio-controller;
#gpio-cells = <2>;
snps,nr-gpios = <32>;
@@ -281,7 +276,6 @@ sm_gpio1: gpio@9000 {
#size-cells = <0>;
portf: gpio-port@5 {
- compatible = "snps,dw-apb-gpio-port";
gpio-controller;
#gpio-cells = <2>;
snps,nr-gpios = <32>;
--
2.28.0
[PATCH 2/8] ARM: dts: socfpga: Remove compatible string from dw apb gpio port
The compatible string is never used.
Signed-off-by: Jisheng Zhang
---
arch/arm/boot/dts/socfpga.dtsi| 3 ---
arch/arm/boot/dts/socfpga_arria10.dtsi| 3 ---
arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi | 2 --
3 files changed, 8 deletions(-)
diff --git a/arch/arm/boot/dts/socfpga.dtsi b/arch/arm/boot/dts/socfpga.dtsi
index 0b021eef0b53..2c06f1fa3d26 100644
--- a/arch/arm/boot/dts/socfpga.dtsi
+++ b/arch/arm/boot/dts/socfpga.dtsi
@@ -609,7 +609,6 @@ gpio0: gpio@ff708000 {
status = "disabled";
porta: gpio-controller@0 {
- compatible = "snps,dw-apb-gpio-port";
gpio-controller;
#gpio-cells = <2>;
snps,nr-gpios = <29>;
@@ -630,7 +629,6 @@ gpio1: gpio@ff709000 {
status = "disabled";
portb: gpio-controller@0 {
- compatible = "snps,dw-apb-gpio-port";
gpio-controller;
#gpio-cells = <2>;
snps,nr-gpios = <29>;
@@ -651,7 +649,6 @@ gpio2: gpio@ff70a000 {
status = "disabled";
portc: gpio-controller@0 {
- compatible = "snps,dw-apb-gpio-port";
gpio-controller;
#gpio-cells = <2>;
snps,nr-gpios = <27>;
diff --git a/arch/arm/boot/dts/socfpga_arria10.dtsi
b/arch/arm/boot/dts/socfpga_arria10.dtsi
index 0013ec3463c4..a52132d3c62f 100644
--- a/arch/arm/boot/dts/socfpga_arria10.dtsi
+++ b/arch/arm/boot/dts/socfpga_arria10.dtsi
@@ -488,7 +488,6 @@ gpio0: gpio@ffc02900 {
status = "disabled";
porta: gpio-controller@0 {
- compatible = "snps,dw-apb-gpio-port";
gpio-controller;
#gpio-cells = <2>;
snps,nr-gpios = <29>;
@@ -508,7 +507,6 @@ gpio1: gpio@ffc02a00 {
status = "disabled";
portb: gpio-controller@0 {
- compatible = "snps,dw-apb-gpio-port";
gpio-controller;
#gpio-cells = <2>;
snps,nr-gpios = <29>;
@@ -528,7 +526,6 @@ gpio2: gpio@ffc02b00 {
status = "disabled";
portc: gpio-controller@0 {
- compatible = "snps,dw-apb-gpio-port";
gpio-controller;
#gpio-cells = <2>;
snps,nr-gpios = <27>;
diff --git a/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi
b/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi
index a6fb01c7ab34..5da1a69d6e1d 100644
--- a/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi
+++ b/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi
@@ -200,7 +200,6 @@ gpio0: gpio@ffc03200 {
status = "disabled";
porta: gpio-controller@0 {
- compatible = "snps,dw-apb-gpio-port";
gpio-controller;
#gpio-cells = <2>;
snps,nr-gpios = <24>;
@@ -220,7 +219,6 @@ gpio1: gpio@ffc03300 {
status = "disabled";
portb: gpio-controller@0 {
- compatible = "snps,dw-apb-gpio-port";
gpio-controller;
#gpio-cells = <2>;
snps,nr-gpios = <24>;
--
2.28.0
[PATCH 3/8] arm64: dts: apm: remove compatible string from dw apb gpio port
The compatible string is never used.
Signed-off-by: Jisheng Zhang
---
arch/arm64/boot/dts/apm/apm-shadowcat.dtsi | 1 -
arch/arm64/boot/dts/apm/apm-storm.dtsi | 1 -
2 files changed, 2 deletions(-)
diff --git a/arch/arm64/boot/dts/apm/apm-shadowcat.dtsi
b/arch/arm64/boot/dts/apm/apm-shadowcat.dtsi
index 3feb1881bbc2..cc4265cc13f6 100644
--- a/arch/arm64/boot/dts/apm/apm-shadowcat.dtsi
+++ b/arch/arm64/boot/dts/apm/apm-shadowcat.dtsi
@@ -714,7 +714,6 @@ dwgpio: gpio@1c024000 {
#size-cells = <0>;
porta: gpio-controller@0 {
- compatible = "snps,dw-apb-gpio-port";
gpio-controller;
snps,nr-gpios = <32>;
reg = <0>;
diff --git a/arch/arm64/boot/dts/apm/apm-storm.dtsi
b/arch/arm64/boot/dts/apm/apm-storm.dtsi
index 8c802d87e751..64b86b9d1b37 100644
--- a/arch/arm64/boot/dts/apm/apm-storm.dtsi
+++ b/arch/arm64/boot/dts/apm/apm-storm.dtsi
@@ -830,7 +830,6 @@ dwgpio: gpio@1c024000 {
#size-cells = <0>;
porta: gpio-controller@0 {
- compatible = "snps,dw-apb-gpio-port";
gpio-controller;
snps,nr-gpios = <32>;
reg = <0>;
--
2.28.0
[PATCH 4/8] arm64: dts: bitmain: Remove compatible string from dw apb gpio port
The compatible string is never used.
Signed-off-by: Jisheng Zhang
---
arch/arm64/boot/dts/bitmain/bm1880.dtsi | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/arm64/boot/dts/bitmain/bm1880.dtsi
b/arch/arm64/boot/dts/bitmain/bm1880.dtsi
index fa6e6905f588..f80373358bba 100644
--- a/arch/arm64/boot/dts/bitmain/bm1880.dtsi
+++ b/arch/arm64/boot/dts/bitmain/bm1880.dtsi
@@ -124,7 +124,6 @@ gpio0: gpio@50027000 {
reg = <0x0 0x50027000 0x0 0x400>;
porta: gpio-controller@0 {
- compatible = "snps,dw-apb-gpio-port";
gpio-controller;
#gpio-cells = <2>;
snps,nr-gpios = <32>;
@@ -142,7 +141,6 @@ gpio1: gpio@50027400 {
reg = <0x0 0x50027400 0x0 0x400>;
portb: gpio-controller@0 {
- compatible = "snps,dw-apb-gpio-port";
gpio-controller;
#gpio-cells = <2>;
snps,nr-gpios = <32>;
@@ -160,7 +158,6 @@ gpio2: gpio@50027800 {
reg = <0x0 0x50027800 0x0 0x400>;
portc: gpio-controller@0 {
- compatible = "snps,dw-apb-gpio-port";
gpio-controller;
#gpio-cells = <2>;
snps,nr-gpios = <8>;
--
2.28.0
Re: [PATCH v1 01/29] virtio-mem: determine nid only once using memory_add_physaddr_to_nid()
On Mon, Oct 12, 2020 at 02:52:55PM +0200, David Hildenbrand wrote:
>Let's determine the target nid only once in case we have none specified -
>usually, we'll end up with node 0 either way.
>
>Cc: "Michael S. Tsirkin"
>Cc: Jason Wang
>Cc: Pankaj Gupta
>Signed-off-by: David Hildenbrand
Reviewed-by: Wei Yang
>---
> drivers/virtio/virtio_mem.c | 28 +++-
> 1 file changed, 11 insertions(+), 17 deletions(-)
>
>diff --git a/drivers/virtio/virtio_mem.c b/drivers/virtio/virtio_mem.c
>index ba4de598f663..a1f5bf7a571a 100644
>--- a/drivers/virtio/virtio_mem.c
>+++ b/drivers/virtio/virtio_mem.c
>@@ -70,7 +70,7 @@ struct virtio_mem {
>
> /* The device block size (for communicating with the device). */
> uint64_t device_block_size;
>- /* The translated node id. NUMA_NO_NODE in case not specified. */
>+ /* The determined node id for all memory of the device. */
> int nid;
> /* Physical start address of the memory region. */
> uint64_t addr;
>@@ -406,10 +406,6 @@ static int virtio_mem_sb_bitmap_prepare_next_mb(struct
>virtio_mem *vm)
> static int virtio_mem_mb_add(struct virtio_mem *vm, unsigned long mb_id)
> {
> const uint64_t addr = virtio_mem_mb_id_to_phys(mb_id);
>- int nid = vm->nid;
>-
>- if (nid == NUMA_NO_NODE)
>- nid = memory_add_physaddr_to_nid(addr);
>
> /*
>* When force-unloading the driver and we still have memory added to
>@@ -423,7 +419,8 @@ static int virtio_mem_mb_add(struct virtio_mem *vm,
>unsigned long mb_id)
> }
>
> dev_dbg(>vdev->dev, "adding memory block: %lu\n", mb_id);
>- return add_memory_driver_managed(nid, addr, memory_block_size_bytes(),
>+ return add_memory_driver_managed(vm->nid, addr,
>+ memory_block_size_bytes(),
>vm->resource_name,
>MEMHP_MERGE_RESOURCE);
> }
>@@ -440,13 +437,9 @@ static int virtio_mem_mb_add(struct virtio_mem *vm,
>unsigned long mb_id)
> static int virtio_mem_mb_remove(struct virtio_mem *vm, unsigned long mb_id)
> {
> const uint64_t addr = virtio_mem_mb_id_to_phys(mb_id);
>- int nid = vm->nid;
>-
>- if (nid == NUMA_NO_NODE)
>- nid = memory_add_physaddr_to_nid(addr);
>
> dev_dbg(>vdev->dev, "removing memory block: %lu\n", mb_id);
>- return remove_memory(nid, addr, memory_block_size_bytes());
>+ return remove_memory(vm->nid, addr, memory_block_size_bytes());
> }
>
> /*
>@@ -461,14 +454,11 @@ static int virtio_mem_mb_offline_and_remove(struct
>virtio_mem *vm,
> unsigned long mb_id)
> {
> const uint64_t addr = virtio_mem_mb_id_to_phys(mb_id);
>- int nid = vm->nid;
>-
>- if (nid == NUMA_NO_NODE)
>- nid = memory_add_physaddr_to_nid(addr);
>
> dev_dbg(>vdev->dev, "offlining and removing memory block: %lu\n",
> mb_id);
>- return offline_and_remove_memory(nid, addr, memory_block_size_bytes());
>+ return offline_and_remove_memory(vm->nid, addr,
>+ memory_block_size_bytes());
> }
>
> /*
>@@ -1659,6 +1649,10 @@ static int virtio_mem_init(struct virtio_mem *vm)
> virtio_cread_le(vm->vdev, struct virtio_mem_config, region_size,
> >region_size);
>
>+ /* Determine the nid for the device based on the lowest address. */
>+ if (vm->nid == NUMA_NO_NODE)
>+ vm->nid = memory_add_physaddr_to_nid(vm->addr);
>+
> /*
>* We always hotplug memory in memory block granularity. This way,
>* we have to wait for exactly one memory block to online.
>@@ -1707,7 +1701,7 @@ static int virtio_mem_init(struct virtio_mem *vm)
>memory_block_size_bytes());
> dev_info(>vdev->dev, "subblock size: 0x%llx",
>(unsigned long long)vm->subblock_size);
>- if (vm->nid != NUMA_NO_NODE)
>+ if (vm->nid != NUMA_NO_NODE && IS_ENABLED(CONFIG_NUMA))
> dev_info(>vdev->dev, "nid: %d", vm->nid);
>
> return 0;
>--
>2.26.2
--
Wei Yang
Help you, Help me
[PATCH] RCU: fix a typo in comments of rcu_blocking_is_gp
There is a tiny typo in comment of function rcu_blocking_is_gp. Signed-off-by: Zhouyi Zhou --- kernel/rcu/tree.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index f78ee75..4cca03f 100644 --- a/kernel/rcu/tree.c +++ b/kernel/rcu/tree.c @@ -3512,7 +3512,7 @@ void __init kfree_rcu_scheduler_running(void) * During early boot, any blocking grace-period wait automatically * implies a grace period. Later on, this is never the case for PREEMPTION. * - * Howevr, because a context switch is a grace period for !PREEMPTION, any + * However, because a context switch is a grace period for !PREEMPTION, any * blocking grace-period wait automatically implies a grace period if * there is only one CPU online at any point time during execution of * either synchronize_rcu() or synchronize_rcu_expedited(). It is OK to -- 1.7.1
Re: [PATCH RFC V3 7/9] x86/entry: Preserve PKRS MSR across exceptions
On Tue, Oct 13, 2020 at 11:52:32AM -0700, Dave Hansen wrote:
> On 10/9/20 12:42 PM, ira.we...@intel.com wrote:
> > @@ -341,6 +341,9 @@ noinstr void irqentry_enter(struct pt_regs *regs,
> > irqentry_state_t *state)
> > /* Use the combo lockdep/tracing function */
> > trace_hardirqs_off();
> > instrumentation_end();
> > +
> > +done:
> > + irq_save_pkrs(state);
> > }
>
> One nit: This saves *and* sets PKRS. It's not obvious from the call
> here that PKRS is altered at this site. Seems like there could be a
> better name.
>
> Even if we did:
>
> irq_save_set_pkrs(state, INIT_VAL);
>
> It would probably compile down to the same thing, but be *really*
> obvious what's going on.
I suppose that is true. But I think it is odd having a parameter which is the
same for every call site.
But I'm not going to quibble over something like this.
Changed,
Ira
>
> > void irqentry_exit_cond_resched(void)
> > @@ -362,7 +365,12 @@ noinstr void irqentry_exit(struct pt_regs *regs,
> > irqentry_state_t *state)
> > /* Check whether this returns to user mode */
> > if (user_mode(regs)) {
> > irqentry_exit_to_user_mode(regs);
> > - } else if (!regs_irqs_disabled(regs)) {
> > + return;
> > + }
> > +
> > + irq_restore_pkrs(state);
> > +
> > + if (!regs_irqs_disabled(regs)) {
> > /*
> > * If RCU was not watching on entry this needs to be done
> > * carefully and needs the same ordering of lockdep/tracing
> >
>
Re: [PATCH 1/2] dccp: ccid: move timers to struct dccp_sock
On Tue, 13 Oct 2020 19:18:48 +0200 Kleber Sacilotto de Souza wrote: > From: Thadeu Lima de Souza Cascardo > > When dccps_hc_tx_ccid is freed, ccid timers may still trigger. The reason > del_timer_sync can't be used is because this relies on keeping a reference > to struct sock. But as we keep a pointer to dccps_hc_tx_ccid and free that > during disconnect, the timer should really belong to struct dccp_sock. > > This addresses CVE-2020-16119. > > Fixes: 839a6094140a (net: dccp: Convert timers to use timer_setup()) Presumably you chose this commit because the fix won't apply beyond it? But it really fixes 2677d2067731 (dccp: don't free.. right? > Signed-off-by: Thadeu Lima de Souza Cascardo > Signed-off-by: Kleber Sacilotto de Souza
Re: [PATCH 2/2] Revert "dccp: don't free ccid2_hc_tx_sock struct in dccp_disconnect()"
On Tue, 13 Oct 2020 19:18:49 +0200 Kleber Sacilotto de Souza wrote: > From: Thadeu Lima de Souza Cascardo > > This reverts commit 2677d20677314101293e6da0094ede7b5526d2b1. > > This fixes an issue that after disconnect, dccps_hc_tx_ccid will still be > kept, allowing the socket to be reused as a listener socket, and the cloned > socket will free its dccps_hc_tx_ccid, leading to a later use after free, > when the listener socket is closed. > > This addresses CVE-2020-16119. > > Fixes: 2677d2067731 (dccp: don't free ccid2_hc_tx_sock struct in > dccp_disconnect()) > Reported-by: Hadar Manor Does this person has an email address? > Signed-off-by: Thadeu Lima de Souza Cascardo > Signed-off-by: Kleber Sacilotto de Souza
Re: [tip: locking/core] lockdep: Fix lockdep recursion
On Wed, Oct 14, 2020 at 04:55:53PM -0700, Paul E. McKenney wrote:
> On Thu, Oct 15, 2020 at 12:39:54AM +0200, Peter Zijlstra wrote:
> > On Wed, Oct 14, 2020 at 03:11:52PM -0700, Paul E. McKenney wrote:
> > > On Wed, Oct 14, 2020 at 11:53:19PM +0200, Peter Zijlstra wrote:
> > > > On Wed, Oct 14, 2020 at 11:34:05AM -0700, Paul E. McKenney wrote:
> > > > > commit 7deaa04b02298001426730ed0e6214ac20d1a1c1
> > > > > Author: Paul E. McKenney
> > > > > Date: Tue Oct 13 12:39:23 2020 -0700
> > > > >
> > > > > rcu: Prevent lockdep-RCU splats on lock acquisition/release
> > > > >
> > > > > The rcu_cpu_starting() and rcu_report_dead() functions transition
> > > > > the
> > > > > current CPU between online and offline state from an RCU
> > > > > perspective.
> > > > > Unfortunately, this means that the rcu_cpu_starting() function's
> > > > > lock
> > > > > acquisition and the rcu_report_dead() function's lock releases
> > > > > happen
> > > > > while the CPU is offline from an RCU perspective, which can
> > > > > result in
> > > > > lockdep-RCU splats about using RCU from an offline CPU. In
> > > > > reality,
> > > > > aside from the splats, both transitions are safe because a new
> > > > > grace
> > > > > period cannot start until these functions release their locks.
> > > >
> > > > But we call the trace_* crud before we acquire the lock. Are you sure
> > > > that's a false-positive?
> > >
> > > You lost me on this one.
> > >
> > > I am assuming that you are talking about rcu_cpu_starting(), because
> > > that is the one where RCU is not initially watching, that is, the
> > > case where tracing before the lock acquisition would be a problem.
> > > You cannot be talking about rcu_cpu_starting() itself, because it does
> > > not do any tracing before acquiring the lock. But if you are talking
> > > about the caller of rcu_cpu_starting(), then that caller should put the
> > > rcu_cpu_starting() before the tracing. But that would be the other
> > > patch earlier in this thread that was proposing moving the call to
> > > rcu_cpu_starting() much earlier in CPU bringup.
> > >
> > > So what am I missing here?
> >
> > rcu_cpu_starting();
> > raw_spin_lock_irqsave();
> > local_irq_save();
> > preempt_disable();
> > spin_acquire()
> > lock_acquire()
> > trace_lock_acquire() <--- *whoopsie-doodle*
> > /* uses RCU for tracing */
> > arch_spin_lock_flags() <--- the actual spinlock
>
> Gah! Idiot here left out the most important part, so good catch!!!
> Much easier this way than finding out about it the hard way...
>
> I should have asked myself harder questions earlier today about moving
> the counter from the rcu_node structure to the rcu_data structure.
>
> Perhaps something like the following untested patch on top of the
> earlier patch?
Except that this is subtlely flawed also. The delay cannot be at
rcu_gp_cleanup() time because by the time we are working on the last
leaf rcu_node structure, callbacks might already have started being
invoked on CPUs corresponding to the earlier leaf rcu_node structures.
So the (untested) patch below (on top of the other two) moves the delay
to rcu_gp_init(), in particular, to the first loop that traverses only
the leaf rcu_node structures handling CPU hotplug.
Hopefully getting closer!
Oh, and the second smp_mb() added to rcu_gp_init() is probably
redundant given the full barrier implied by the later call to
raw_spin_lock_irq_rcu_node(). But one thing at a time...
Thanx, Paul
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 8b5215e..5904b63 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -1725,6 +1725,7 @@ static void rcu_strict_gp_boundary(void *unused)
*/
static bool rcu_gp_init(void)
{
+ unsigned long firstseq;
unsigned long flags;
unsigned long oldmask;
unsigned long mask;
@@ -1768,6 +1769,12 @@ static bool rcu_gp_init(void)
*/
rcu_state.gp_state = RCU_GP_ONOFF;
rcu_for_each_leaf_node(rnp) {
+ smp_mb(); // Pair with barriers used when updating ->ofl_seq to
odd values.
+ firstseq = READ_ONCE(rnp->ofl_seq);
+ if (firstseq & 0x1)
+ while (firstseq == smp_load_acquire(>ofl_seq))
+ schedule_timeout_idle(1); // Can't wake unless
RCU is watching.
+ smp_mb(); // Pair with barriers used when updating ->ofl_seq to
even values.
raw_spin_lock(_state.ofl_lock);
raw_spin_lock_irq_rcu_node(rnp);
if (rnp->qsmaskinit == rnp->qsmaskinitnext &&
@@ -1982,7 +1989,6 @@ static void rcu_gp_fqs_loop(void)
static void rcu_gp_cleanup(void)
{
int cpu;
- unsigned long firstseq;
bool needgp = false;
unsigned long
Re: [PATCH 5/8] x86/clear_page: add clear_page_uncached()
On 2020-10-14 2:12 p.m., Borislav Petkov wrote: On Wed, Oct 14, 2020 at 02:07:30PM -0700, Andy Lutomirski wrote: I assume it’s for a little optimization of clearing more than one page per SFENCE. In any event, based on the benchmark data upthread, we only want to do NT clears when they’re rather large, so this shouldn’t be just an alternative. I assume this is because a page or two will fit in cache and, for most uses that allocate zeroed pages, we prefer cache-hot pages. When clearing 1G, on the other hand, cache-hot is impossible and we prefer the improved bandwidth and less cache trashing of NT clears. Yeah, use case makes sense but people won't know what to use. At the time I was experimenting with this crap, I remember Linus saying that that selection should be made based on the size of the area cleared, so users should not have to know the difference. I don't disagree but I think the selection of cached/uncached route should be made where we have enough context available to be able to choose to do this. This could be for example, done in mm_populate() or gup where if say the extent is larger than LLC-size, it takes the uncached path. Which perhaps is the only sane use case I see for this. Perhaps SFENCE is so fast that this is a silly optimization, though, and we don’t lose anything measurable by SFENCEing once per page. Yes, I'd like to see real use cases showing improvement from this, not just microbenchmarks. Sure will add. Thanks Ankur
Re: [PATCH v1 1/6] staging: qlge: Initialize devlink health dump framework for the dlge driver
On Tue, Oct 13, 2020 at 09:37:04AM +0900, Benjamin Poirier wrote: On 2020-10-12 19:24 +0800, Coiby Xu wrote: [...] > I think, but didn't check in depth, that in those drivers, the devlink > device is tied to the pci device and can exist independently of the > netdev, at least in principle. > You are right. Take drivers/net/ethernet/mellanox/mlxsw as an example, devlink reload would first first unregister_netdev and then register_netdev but struct devlink stays put. But I have yet to understand when unregister/register_netdev is needed. Maybe it can be useful to manually recover if the hardware or driver gets in an erroneous state. I've used `modprobe -r qlge && modprobe qlge` for the same in the past. Thank you for providing this user case! Do we need to add "devlink reload" for qlge? Not for this patchset. That would be a new feature. To implement this feature, it seems I need to understand how qlge work under the hood. For example, what's the difference between qlge_soft_reset_mpi_risc and qlge_hard_reset_mpi_risc? Or should we use a brute-force way like do the tasks in qlge_remove and then re-do the tasks in qlge_probe? Is a hardware reference manual for qlge device? -- Best regards, Coiby
[PATCH v3 3/3] mm/slub: Actually fix freelist pointer vs redzoning
It turns out that SLUB redzoning ("slub_debug=Z") checks from
s->object_size rather than from s->inuse (which is normally bumped
to make room for the freelist pointer), so a cache created with an
object size less than 24 would have the freelist pointer written beyond
s->object_size, causing the redzone to be corrupted by the freelist
pointer. This was very visible with "slub_debug=ZF":
BUG test (Tainted: GB): Right Redzone overwritten
-
INFO: 0x957ead1c05de-0x957ead1c05df @offset=1502. First byte 0x1a
instead of 0xbb
INFO: Slab 0xef3950b47000 objects=170 used=170 fp=0x
flags=0x8200
INFO: Object 0x957ead1c05d8 @offset=1496 fp=0x957ead1c0620
Redzone (ptrval): bb bb bb bb bb bb bb bb
Object (ptrval): 00 00 00 00 00 f6 f4 a5
Redzone (ptrval): 40 1d e8 1a aa@
Padding (ptrval): 00 00 00 00 00 00 00 00
Adjust the offset to stay within s->object_size.
(Note that no caches in this size range are known to exist in the kernel
currently.)
Reported-by: Marco Elver
Link:
https://lore.kernel.org/linux-mm/20200807160627.ga1420...@elver.google.com/
Fixes: 89b83f282d8b (slub: avoid redzone when choosing freepointer location)
Cc: sta...@vger.kernel.org
Tested-by: Marco Elver
Link:
https://lore.kernel.org/lkml/canpmjnowz5vpkqn+sywovtkfb4vst-rpwyenbmak0dlcpqs...@mail.gmail.com
Signed-off-by: Kees Cook
Acked-by: Vlastimil Babka
Link: https://lore.kernel.org/lkml/0f7dd7b2-7496-5e2d-9488-2ec9f8e90...@suse.cz/
---
mm/slub.c | 14 +++---
1 file changed, 3 insertions(+), 11 deletions(-)
diff --git a/mm/slub.c b/mm/slub.c
index 752fad36522c..6f115e56c5d0 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -3637,7 +3637,6 @@ static int calculate_sizes(struct kmem_cache *s, int
forced_order)
{
slab_flags_t flags = s->flags;
unsigned int size = s->object_size;
- unsigned int freepointer_area;
unsigned int order;
/*
@@ -3646,13 +3645,6 @@ static int calculate_sizes(struct kmem_cache *s, int
forced_order)
* the possible location of the free pointer.
*/
size = ALIGN(size, sizeof(void *));
- /*
-* This is the area of the object where a freepointer can be
-* safely written. If redzoning adds more to the inuse size, we
-* can't use that portion for writing the freepointer, so
-* s->offset must be limited within this for the general case.
-*/
- freepointer_area = size;
#ifdef CONFIG_SLUB_DEBUG
/*
@@ -3678,7 +3670,7 @@ static int calculate_sizes(struct kmem_cache *s, int
forced_order)
/*
* With that we have determined the number of bytes in actual use
-* by the object. This is the potential offset to the free pointer.
+* by the object and redzoning.
*/
s->inuse = size;
@@ -3701,13 +3693,13 @@ static int calculate_sizes(struct kmem_cache *s, int
forced_order)
*/
s->offset = size;
size += sizeof(void *);
- } else if (freepointer_area > sizeof(void *)) {
+ } else {
/*
* Store freelist pointer near middle of object to keep
* it away from the edges of the object to avoid small
* sized over/underflows from neighboring allocations.
*/
- s->offset = ALIGN(freepointer_area / 2, sizeof(void *));
+ s->offset = ALIGN_DOWN(s->object_size / 2, sizeof(void *));
}
#ifdef CONFIG_SLUB_DEBUG
--
2.25.1
[PATCH v3 0/3] Actually fix freelist pointer vs redzoning
v3: - fix commit messages to properly reflect the direction of the overwrite - justify the less-than-word-size patch better - add Acks - move some Fixes up into the commit log as just references v2: https://lore.kernel.org/lkml/20201009195411.4018141-1-keesc...@chromium.org v1: https://lore.kernel.org/lkml/20201008233443.3335464-1-keesc...@chromium.org This fixes redzoning vs the freelist pointer (both for middle-position and very small caches). Both are "theoretical" fixes, in that I see no evidence of such small-sized caches actually be used in the kernel, but that's no reason to let the bugs continue to exist. :) Note on patch 2: Christopher NAKed it, but I actually think this is a reasonable thing to add -- the "too small" check is only made when built with CONFIG_DEBUG_VM, so it *is* actually possible for someone to trip over this directly, even if it would never make it into a released kernel. I see no reason to just leave this foot-gun in place, though, so we might as well just fix it too. (Which seems to be what Longman was similarly supporting, IIUC.) Anyway, if patch 2 stays NAKed, that's fine. It's entirely separable, and the other 2 can land. :) Thanks! -Kees Kees Cook (3): mm/slub: Clarify verification reporting mm/slub: Fix redzoning for small allocations mm/slub: Actually fix freelist pointer vs redzoning Documentation/vm/slub.rst | 10 +- mm/slub.c | 36 +++- 2 files changed, 20 insertions(+), 26 deletions(-) -- 2.25.1
[PATCH v3 1/3] mm/slub: Clarify verification reporting
Instead of repeating "Redzone" and "Poison", clarify which sides of
those zones got tripped. Additionally fix column alignment in the
trailer.
Before:
BUG test (Tainted: GB): Redzone overwritten
...
Redzone (ptrval): bb bb bb bb bb bb bb bb
Object (ptrval): f6 f4 a5 40 1d e8...@..
Redzone (ptrval): 1a aa..
Padding (ptrval): 00 00 00 00 00 00 00 00
After:
BUG test (Tainted: GB): Right Redzone overwritten
...
Redzone (ptrval): bb bb bb bb bb bb bb bb
Object (ptrval): f6 f4 a5 40 1d e8...@..
Redzone (ptrval): 1a aa..
Padding (ptrval): 00 00 00 00 00 00 00 00
The earlier commits that slowly resulted in the "Before" reporting were:
d86bd1bece6f ("mm/slub: support left redzone")
ffc79d288000 ("slub: use print_hex_dump")
2492268472e7 ("SLUB: change error reporting format to follow lockdep loosely")
Signed-off-by: Kees Cook
Acked-by: Vlastimil Babka
Link: https://lore.kernel.org/lkml/cfdb11d7-fb8e-e578-c939-f7f5fb69a...@suse.cz/
---
Documentation/vm/slub.rst | 10 +-
mm/slub.c | 14 +++---
2 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/Documentation/vm/slub.rst b/Documentation/vm/slub.rst
index 289d231cee97..77c7a3331eda 100644
--- a/Documentation/vm/slub.rst
+++ b/Documentation/vm/slub.rst
@@ -181,7 +181,7 @@ SLUB Debug output
Here is a sample of slub debug output::
- BUG kmalloc-8: Redzone overwritten
+ BUG kmalloc-8: Right Redzone overwritten
INFO: 0xc90f6d28-0xc90f6d2b. First byte 0x00 instead of 0xcc
@@ -189,10 +189,10 @@ Here is a sample of slub debug output::
INFO: Object 0xc90f6d20 @offset=3360 fp=0xc90f6d58
INFO: Allocated in get_modalias+0x61/0xf5 age=53 cpu=1 pid=554
- Bytes b4 0xc90f6d10: 00 00 00 00 00 00 00 00 5a 5a 5a 5a 5a 5a 5a 5a
- Object 0xc90f6d20: 31 30 31 39 2e 30 30 35 1019.005
- Redzone 0xc90f6d28: 00 cc cc cc .
- Padding 0xc90f6d50: 5a 5a 5a 5a 5a 5a 5a 5a
+ Bytes b4 (0xc90f6d10): 00 00 00 00 00 00 00 00 5a 5a 5a 5a 5a 5a 5a 5a
+ Object (0xc90f6d20): 31 30 31 39 2e 30 30 35
1019.005
+ Redzone (0xc90f6d28): 00 cc cc cc .
+ Padding (0xc90f6d50): 5a 5a 5a 5a 5a 5a 5a 5a
[] dump_trace+0x63/0x1eb
[] show_trace_log_lvl+0x1a/0x2f
diff --git a/mm/slub.c b/mm/slub.c
index 6d3574013b2f..f4f1d63f0ab9 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -698,15 +698,15 @@ static void print_trailer(struct kmem_cache *s, struct
page *page, u8 *p)
p, p - addr, get_freepointer(s, p));
if (s->flags & SLAB_RED_ZONE)
- print_section(KERN_ERR, "Redzone ", p - s->red_left_pad,
+ print_section(KERN_ERR, "Redzone ", p - s->red_left_pad,
s->red_left_pad);
else if (p > addr + 16)
print_section(KERN_ERR, "Bytes b4 ", p - 16, 16);
- print_section(KERN_ERR, "Object ", p,
+ print_section(KERN_ERR, "Object ", p,
min_t(unsigned int, s->object_size, PAGE_SIZE));
if (s->flags & SLAB_RED_ZONE)
- print_section(KERN_ERR, "Redzone ", p + s->object_size,
+ print_section(KERN_ERR, "Redzone ", p + s->object_size,
s->inuse - s->object_size);
off = get_info_end(s);
@@ -718,7 +718,7 @@ static void print_trailer(struct kmem_cache *s, struct page
*page, u8 *p)
if (off != size_from_object(s))
/* Beginning of the filler is the free pointer */
- print_section(KERN_ERR, "Padding ", p + off,
+ print_section(KERN_ERR, "Padding ", p + off,
size_from_object(s) - off);
dump_stack();
@@ -895,11 +895,11 @@ static int check_object(struct kmem_cache *s, struct page
*page,
u8 *endobject = object + s->object_size;
if (s->flags & SLAB_RED_ZONE) {
- if (!check_bytes_and_report(s, page, object, "Redzone",
+ if (!check_bytes_and_report(s, page, object, "Left Redzone",
object - s->red_left_pad, val, s->red_left_pad))
return 0;
- if (!check_bytes_and_report(s, page, object, "Redzone",
+ if (!check_bytes_and_report(s, page, object, "Right Redzone",
endobject, val, s->inuse - s->object_size))
return 0;
} else {
@@ -914,7 +914,7 @@ static int check_object(struct kmem_cache *s, struct page
[PATCH v3 2/3] mm/slub: Fix redzoning for small allocations
The redzone area for SLUB exists between s->object_size and s->inuse
(which is at least the word-aligned object_size). If a cache were created
with an object_size smaller than sizeof(void *), the in-object stored
freelist pointer would overwrite the redzone (e.g. with boot param
"slub_debug=ZF"):
BUG test (Tainted: GB): Right Redzone overwritten
-
INFO: 0x957ead1c05de-0x957ead1c05df @offset=1502. First byte 0x1a
instead of 0xbb
INFO: Slab 0xef3950b47000 objects=170 used=170 fp=0x
flags=0x8200
INFO: Object 0x957ead1c05d8 @offset=1496 fp=0x957ead1c0620
Redzone (ptrval): bb bb bb bb bb bb bb bb
Object (ptrval): f6 f4 a5 40 1d e8 ...@..
Redzone (ptrval): 1a aa ..
Padding (ptrval): 00 00 00 00 00 00 00 00
Store the freelist pointer out of line when object_size is smaller
than sizeof(void *) and redzoning is enabled. (This object_size is not
actually considered valid, as tested by kmem_cache_sanity_check() under
CONFIG_DEBUG_VM. This is being added for extra robustness, since it IS
possible to build kernels where this is allowed -- why keep foot-guns
around?)
(Note that no caches in this size range are known to exist in the kernel
currently.)
Fixes: 81819f0fc828 ("SLUB core")
Cc: sta...@vger.kernel.org
Signed-off-by: Kees Cook
---
mm/slub.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/mm/slub.c b/mm/slub.c
index f4f1d63f0ab9..752fad36522c 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -3682,15 +3682,17 @@ static int calculate_sizes(struct kmem_cache *s, int
forced_order)
*/
s->inuse = size;
- if (((flags & (SLAB_TYPESAFE_BY_RCU | SLAB_POISON)) ||
- s->ctor)) {
+ if ((flags & (SLAB_TYPESAFE_BY_RCU | SLAB_POISON)) ||
+ ((flags & SLAB_RED_ZONE) && s->object_size < sizeof(void *)) ||
+ s->ctor) {
/*
* Relocate free pointer after the object if it is not
* permitted to overwrite the first word of the object on
* kmem_cache_free.
*
* This is the case if we do RCU, have a constructor or
-* destructor or are poisoning the objects.
+* destructor, are poisoning the objects, or are
+* redzoning an object smaller than sizeof(void *).
*
* The assumption that s->offset >= s->inuse means free
* pointer is outside of the object is used in the
--
2.25.1
Re: [PATCH net-next] net: ptp: get rid of IPV4_HLEN() and OFF_IHL macros
On Wed, Oct 14, 2020 at 01:58:05PM +0200, Christian Eggers wrote:
> Both macros are already marked for removal.
I'm not sure what Daniel Borkmann meant by that comment, but ...
> switch (type & PTP_CLASS_PMASK) {
> case PTP_CLASS_IPV4:
> - ptr += IPV4_HLEN(ptr) + UDP_HLEN;
> + ptr += (((struct iphdr *)ptr)->ihl << 2) + UDP_HLEN;
to my eyes
IPV4_HLEN(ptr)
is way more readable than
(((struct iphdr *)ptr)->ihl << 2)
and this
(struct udphdr *)((char *)ih + (ih->ihl << 2))
is really baroque.
I don't see any improvement here.
Thanks,
Richard
Re: linux-next: manual merge of the tip tree with the dma-mapping tree
Hi all,
On Tue, 6 Oct 2020 17:11:35 +1100 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the tip tree got a conflict in:
>
> arch/x86/kernel/setup.c
>
> between commit:
>
> f47e22d65d08 ("dma-mapping: split ")
>
> from the dma-mapping tree and commit:
>
> a945c8345ec0 ("static_call: Allow early init")
>
> from the tip tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> diff --cc arch/x86/kernel/setup.c
> index 787c5ff1e7c0,fa16b906ea3f..
> --- a/arch/x86/kernel/setup.c
> +++ b/arch/x86/kernel/setup.c
> @@@ -20,7 -19,7 +20,8 @@@
> #include
> #include
> #include
> + #include
> +#include
>
> #include
>
This is now a conflict between the dma-mapping tree and Linus' tree.
--
Cheers,
Stephen Rothwell
pgpwWiO7FeBav.pgp
Description: OpenPGP digital signature
[RESEND PATCH] crypto: sa2ul - Reduce stack usage
Resending to linux-crypto.
---8<---
This patch reduces the stack usage in sa2ul:
1. Move the exported sha state into sa_prepare_iopads so that it
can occupy the same space as the k_pad buffer.
2. Use one buffer for ipad/opad in sa_prepare_iopads.
3. Remove ipad/opad buffer from sa_set_sc_auth.
4. Use async skcipher fallback and remove on-stack request from
sa_cipher_run.
Reported-by: kernel test robot
Fixes: d2c8ac187fc9 ("crypto: sa2ul - Add AEAD algorithm support")
Signed-off-by: Herbert Xu
diff --git a/drivers/crypto/sa2ul.c b/drivers/crypto/sa2ul.c
index 5bc099052bd2..66629cad9531 100644
--- a/drivers/crypto/sa2ul.c
+++ b/drivers/crypto/sa2ul.c
@@ -9,8 +9,10 @@
* Tero Kristo
*/
#include
+#include
#include
#include
+#include
#include
#include
#include
@@ -356,42 +358,45 @@ static void sa_swiz_128(u8 *in, u16 len)
}
/* Prepare the ipad and opad from key as per SHA algorithm step 1*/
-static void prepare_kiopad(u8 *k_ipad, u8 *k_opad, const u8 *key, u16 key_sz)
+static void prepare_kipad(u8 *k_ipad, const u8 *key, u16 key_sz)
{
int i;
- for (i = 0; i < key_sz; i++) {
+ for (i = 0; i < key_sz; i++)
k_ipad[i] = key[i] ^ 0x36;
- k_opad[i] = key[i] ^ 0x5c;
- }
/* Instead of XOR with 0 */
- for (; i < SHA1_BLOCK_SIZE; i++) {
+ for (; i < SHA1_BLOCK_SIZE; i++)
k_ipad[i] = 0x36;
+}
+
+static void prepare_kopad(u8 *k_opad, const u8 *key, u16 key_sz)
+{
+ int i;
+
+ for (i = 0; i < key_sz; i++)
+ k_opad[i] = key[i] ^ 0x5c;
+
+ /* Instead of XOR with 0 */
+ for (; i < SHA1_BLOCK_SIZE; i++)
k_opad[i] = 0x5c;
- }
}
-static void sa_export_shash(struct shash_desc *hash, int block_size,
+static void sa_export_shash(void *state, struct shash_desc *hash,
int digest_size, __be32 *out)
{
- union {
- struct sha1_state sha1;
- struct sha256_state sha256;
- struct sha512_state sha512;
- } sha;
- void *state;
+ struct sha1_state *sha1;
+ struct sha256_state *sha256;
u32 *result;
- int i;
switch (digest_size) {
case SHA1_DIGEST_SIZE:
- state =
- result = sha.sha1.state;
+ sha1 = state;
+ result = sha1->state;
break;
case SHA256_DIGEST_SIZE:
- state =
- result = sha.sha256.state;
+ sha256 = state;
+ result = sha256->state;
break;
default:
dev_err(sa_k3_dev, "%s: bad digest_size=%d\n", __func__,
@@ -401,8 +406,7 @@ static void sa_export_shash(struct shash_desc *hash, int
block_size,
crypto_shash_export(hash, state);
- for (i = 0; i < digest_size >> 2; i++)
- out[i] = cpu_to_be32(result[i]);
+ cpu_to_be32_array(out, result, digest_size / 4);
}
static void sa_prepare_iopads(struct algo_data *data, const u8 *key,
@@ -411,24 +415,28 @@ static void sa_prepare_iopads(struct algo_data *data,
const u8 *key,
SHASH_DESC_ON_STACK(shash, data->ctx->shash);
int block_size = crypto_shash_blocksize(data->ctx->shash);
int digest_size = crypto_shash_digestsize(data->ctx->shash);
- u8 k_ipad[SHA1_BLOCK_SIZE];
- u8 k_opad[SHA1_BLOCK_SIZE];
+ union {
+ struct sha1_state sha1;
+ struct sha256_state sha256;
+ u8 k_pad[SHA1_BLOCK_SIZE];
+ } sha;
shash->tfm = data->ctx->shash;
- prepare_kiopad(k_ipad, k_opad, key, key_sz);
-
- memzero_explicit(ipad, block_size);
- memzero_explicit(opad, block_size);
+ prepare_kipad(sha.k_pad, key, key_sz);
crypto_shash_init(shash);
- crypto_shash_update(shash, k_ipad, block_size);
- sa_export_shash(shash, block_size, digest_size, ipad);
+ crypto_shash_update(shash, sha.k_pad, block_size);
+ sa_export_shash(, shash, digest_size, ipad);
+
+ prepare_kopad(sha.k_pad, key, key_sz);
crypto_shash_init(shash);
- crypto_shash_update(shash, k_opad, block_size);
+ crypto_shash_update(shash, sha.k_pad, block_size);
- sa_export_shash(shash, block_size, digest_size, opad);
+ sa_export_shash(, shash, digest_size, opad);
+
+ memzero_explicit(, sizeof(sha));
}
/* Derive the inverse key used in AES-CBC decryption operation */
@@ -501,7 +509,8 @@ static int sa_set_sc_enc(struct algo_data *ad, const u8
*key, u16 key_sz,
static void sa_set_sc_auth(struct algo_data *ad, const u8 *key, u16 key_sz,
u8 *sc_buf)
{
- __be32 ipad[64], opad[64];
+ __be32 *ipad = (void *)(sc_buf + 32);
+ __be32 *opad = (void *)(sc_buf + 64);
/* Set Authentication mode selector to hash processing */
sc_buf[0] = SA_HASH_PROCESSING;
@@ -510,14
Re: [PATCH v2 17/17] ASoC: sun8i-codec: Add the AIF3 DAI, widgets, and routes
On 10/14/20 1:19 AM, Samuel Holland wrote:
> AIF3 has some differences from AIF1 and AIF2:
> - It supports one channel only
> - It supports master mode only
> - It is not directly connected to any of the mixers; instead all audio
>goes through a mux with AIF2.
> - It does not have its own clock dividers; instead it reuses AIF2 BCLK
>and LRCK. This means that when both AIF2 and AIF3 are active, they
>must use the same sample rate and total frame width. Since AIF2 and
>AIF3 are only used for codec2codec DAI links, constraints are not
>applicable here; the only thing we can do when the rates don't match
>is report an error.
>
> Make the necessary adjustments to support this AIF.
>
> Signed-off-by: Samuel Holland
> ---
> sound/soc/sunxi/sun8i-codec.c | 138 --
> 1 file changed, 130 insertions(+), 8 deletions(-)
>
> diff --git a/sound/soc/sunxi/sun8i-codec.c b/sound/soc/sunxi/sun8i-codec.c
> index 6a8232e07983..180442c62be1 100644
> --- a/sound/soc/sunxi/sun8i-codec.c
> +++ b/sound/soc/sunxi/sun8i-codec.c
[snip]
> @@ -263,19 +273,30 @@ static int sun8i_codec_set_fmt(struct snd_soc_dai *dai,
> unsigned int fmt)
> break;
> case SND_SOC_DAIFMT_CBM_CFM: /* Codec Master, DAI slave */
> value = 0x0;
> break;
> default:
> return -EINVAL;
> }
>
> - regmap_update_bits(scodec->regmap, SUN8I_AIF_CLK_CTRL(dai->id),
> -BIT(SUN8I_AIF_CLK_CTRL_MSTR_MOD),
> -value << SUN8I_AIF_CLK_CTRL_MSTR_MOD);
> + if (dai->id == SUN8I_CODEC_AIF3) {
> + /* AIF3 only supports master mode. */
> + if (value)
> + return -EINVAL;
> +
> + /* Use the AIF2 BCLK and LRCK for AIF3. */
> + regmap_update_bits(scodec->regmap, SUN8I_AIF_CLK_CTRL(dai->id),
> +SUN8I_AIF3_CLK_CTRL_AIF3_CLK_SRC_MASK,
> +SUN8I_AIF3_CLK_CTRL_AIF3_CLK_SRC_AIF2);
Since the AIF3 clock source is set to AIF2 here...
> + } else {
> + regmap_update_bits(scodec->regmap, SUN8I_AIF_CLK_CTRL(dai->id),
> +BIT(SUN8I_AIF_CLK_CTRL_MSTR_MOD),
> +value << SUN8I_AIF_CLK_CTRL_MSTR_MOD);
> + }
>
> /* DAI format */
> switch (fmt & SND_SOC_DAIFMT_FORMAT_MASK) {
> case SND_SOC_DAIFMT_I2S:
> format = 0x0;
> break;
> case SND_SOC_DAIFMT_LEFT_J:
> format = 0x1;
[snip]
> @@ -908,16 +1016,22 @@ static const struct snd_soc_dapm_route
> sun8i_codec_dapm_routes[] = {
> { "CLK AIF2", NULL, "AIF2CLK" },
> { "CLK AIF2", NULL, "SYSCLK" },
> { "RST AIF2", NULL, "CLK AIF2" },
> { "AIF2 ADCL", NULL, "RST AIF2" },
> { "AIF2 ADCR", NULL, "RST AIF2" },
> { "AIF2 DACL", NULL, "RST AIF2" },
> { "AIF2 DACR", NULL, "RST AIF2" },
>
> + { "CLK AIF3", NULL, "AIF1CLK" },
^^^
...this should be "AIF2CLK". I will fix it in the next version.
> + { "CLK AIF3", NULL, "SYSCLK" },
> + { "RST AIF3", NULL, "CLK AIF3" },
> + { "AIF3 ADC", NULL, "RST AIF3" },
> + { "AIF3 DAC", NULL, "RST AIF3" },
> +
> { "CLK ADC", NULL, "SYSCLK" },
> { "RST ADC", NULL, "CLK ADC" },
> { "ADC", NULL, "RST ADC" },
> { "ADCL", NULL, "ADC" },
> { "ADCR", NULL, "ADC" },
>
> { "CLK DAC", NULL, "SYSCLK" },
> { "RST DAC", NULL, "CLK DAC" },
[PATCH v8] Add MediaTek MT6779 devapc driver
add subject On Thu, 2020-10-15 at 11:20 +0800, Neal Liu wrote: > These patch series introduce a MediaTek MT6779 devapc driver. > > MediaTek bus fabric provides TrustZone security support and data protection > to prevent slaves from being accessed by unexpected masters. > The security violation is logged and sent to the processor for further > analysis or countermeasures. > > Any occurrence of security violation would raise an interrupt, and it will be > handled by mtk-devapc driver. > The violation information is printed in order to find the murderer. > > changes since v7: > - fix VIO_MOD_TO_REG_IND calculation wrong problem. > - revise parameter type of ISR. > > changes since v6: > - remove unnecessary mask/unmask module irq during ISR. > > changes since v5: > - remove redundant write reg operation. > - use static variable of vio_dbgs instead. > - add stop_devapc() if driver is removed. > > changes since v4: > - refactor data structure. > - merge two simple functions into one. > - refactor register setting to prevent too many function call overhead. > > changes since v3: > - revise violation handling flow to make it more easily to understand > hardware behavior. > - add more comments to understand how hardware works. > > changes since v2: > - pass platform info through DT data. > - remove unnecessary function. > - remove slave_type because it always equals to 1 in current support SoC. > - use vio_idx_num instread of list all devices' index. > - add more comments to describe hardware behavior. > > changes since v1: > - move SoC specific part to DT data. > - remove unnecessary boundary check. > - remove unnecessary data type declaration. > - use read_poll_timeout() instread of for loop polling. > - revise coding style elegantly. > > > *** BLURB HERE *** > > Neal Liu (2): > dt-bindings: devapc: add bindings for mtk-devapc > soc: mediatek: add mt6779 devapc driver > > .../bindings/soc/mediatek/devapc.yaml | 58 > drivers/soc/mediatek/Kconfig | 9 + > drivers/soc/mediatek/Makefile | 1 + > drivers/soc/mediatek/mtk-devapc.c | 308 ++ > 4 files changed, 376 insertions(+) > create mode 100644 Documentation/devicetree/bindings/soc/mediatek/devapc.yaml > create mode 100644 drivers/soc/mediatek/mtk-devapc.c >
[PATCH] mgmt: Add supports of variable length parameter in mgmt_config
This adds support of variable length parameter in mgmt_config.
Signed-off-by: Howard Chung
Reviewed-by: Alain Michaud
---
net/bluetooth/mgmt_config.c | 134 +---
1 file changed, 80 insertions(+), 54 deletions(-)
diff --git a/net/bluetooth/mgmt_config.c b/net/bluetooth/mgmt_config.c
index b30b571f8caf8..1e3cbeacb09b4 100644
--- a/net/bluetooth/mgmt_config.c
+++ b/net/bluetooth/mgmt_config.c
@@ -11,70 +11,96 @@
#include "mgmt_util.h"
#include "mgmt_config.h"
-#define HDEV_PARAM_U16(_param_code_, _param_name_) \
-{ \
- { cpu_to_le16(_param_code_), sizeof(__u16) }, \
- { cpu_to_le16(hdev->_param_name_) } \
-}
+#define HDEV_PARAM_U16(_param_name_) \
+ struct {\
+ struct mgmt_tlv entry; \
+ __le16 value; \
+ } __packed _param_name_
-#define HDEV_PARAM_U16_JIFFIES_TO_MSECS(_param_code_, _param_name_) \
-{ \
- { cpu_to_le16(_param_code_), sizeof(__u16) }, \
- { cpu_to_le16(jiffies_to_msecs(hdev->_param_name_)) } \
-}
+#define TLV_SET_U16(_param_code_, _param_name_) \
+ { \
+ { cpu_to_le16(_param_code_), sizeof(__u16) }, \
+ cpu_to_le16(hdev->_param_name_) \
+ }
+
+#define TLV_SET_U16_JIFFIES_TO_MSECS(_param_code_, _param_name_) \
+ { \
+ { cpu_to_le16(_param_code_), sizeof(__u16) }, \
+ cpu_to_le16(jiffies_to_msecs(hdev->_param_name_)) \
+ }
int read_def_system_config(struct sock *sk, struct hci_dev *hdev, void *data,
u16 data_len)
{
- struct {
- struct mgmt_tlv entry;
- union {
- /* This is a simplification for now since all values
-* are 16 bits. In the future, this code may need
-* refactoring to account for variable length values
-* and properly calculate the required buffer size.
-*/
- __le16 value;
- };
- } __packed params[] = {
+ int ret;
+ struct mgmt_rp_read_def_system_config {
/* Please see mgmt-api.txt for documentation of these values */
- HDEV_PARAM_U16(0x, def_page_scan_type),
- HDEV_PARAM_U16(0x0001, def_page_scan_int),
- HDEV_PARAM_U16(0x0002, def_page_scan_window),
- HDEV_PARAM_U16(0x0003, def_inq_scan_type),
- HDEV_PARAM_U16(0x0004, def_inq_scan_int),
- HDEV_PARAM_U16(0x0005, def_inq_scan_window),
- HDEV_PARAM_U16(0x0006, def_br_lsto),
- HDEV_PARAM_U16(0x0007, def_page_timeout),
- HDEV_PARAM_U16(0x0008, sniff_min_interval),
- HDEV_PARAM_U16(0x0009, sniff_max_interval),
- HDEV_PARAM_U16(0x000a, le_adv_min_interval),
- HDEV_PARAM_U16(0x000b, le_adv_max_interval),
- HDEV_PARAM_U16(0x000c, def_multi_adv_rotation_duration),
- HDEV_PARAM_U16(0x000d, le_scan_interval),
- HDEV_PARAM_U16(0x000e, le_scan_window),
- HDEV_PARAM_U16(0x000f, le_scan_int_suspend),
- HDEV_PARAM_U16(0x0010, le_scan_window_suspend),
- HDEV_PARAM_U16(0x0011, le_scan_int_discovery),
- HDEV_PARAM_U16(0x0012, le_scan_window_discovery),
- HDEV_PARAM_U16(0x0013, le_scan_int_adv_monitor),
- HDEV_PARAM_U16(0x0014, le_scan_window_adv_monitor),
- HDEV_PARAM_U16(0x0015, le_scan_int_connect),
- HDEV_PARAM_U16(0x0016, le_scan_window_connect),
- HDEV_PARAM_U16(0x0017, le_conn_min_interval),
- HDEV_PARAM_U16(0x0018, le_conn_max_interval),
- HDEV_PARAM_U16(0x0019, le_conn_latency),
- HDEV_PARAM_U16(0x001a, le_supv_timeout),
- HDEV_PARAM_U16_JIFFIES_TO_MSECS(0x001b,
- def_le_autoconnect_timeout),
+ HDEV_PARAM_U16(def_page_scan_type);
+ HDEV_PARAM_U16(def_page_scan_int);
+ HDEV_PARAM_U16(def_page_scan_window);
+ HDEV_PARAM_U16(def_inq_scan_type);
+ HDEV_PARAM_U16(def_inq_scan_int);
+ HDEV_PARAM_U16(def_inq_scan_window);
+ HDEV_PARAM_U16(def_br_lsto);
+ HDEV_PARAM_U16(def_page_timeout);
+ HDEV_PARAM_U16(sniff_min_interval);
+ HDEV_PARAM_U16(sniff_max_interval);
+ HDEV_PARAM_U16(le_adv_min_interval);
+ HDEV_PARAM_U16(le_adv_max_interval);
+ HDEV_PARAM_U16(def_multi_adv_rotation_duration);
+ HDEV_PARAM_U16(le_scan_interval);
+ HDEV_PARAM_U16(le_scan_window);
+ HDEV_PARAM_U16(le_scan_int_suspend);
+ HDEV_PARAM_U16(le_scan_window_suspend);
+ HDEV_PARAM_U16(le_scan_int_discovery);
+ HDEV_PARAM_U16(le_scan_window_discovery);
Re: [PATCH 6/6] dt-bindings: misc: correct the property name cmd-gpios to cmd-gpio
On 2020/10/14 21:50, Rob Herring wrote: > On Wed, Oct 14, 2020 at 09:29:26AM +0800, Leizhen (ThunderTown) wrote: >> >> >> On 2020/10/14 1:32, Dan Murphy wrote: >>> Zhen >>> >>> On 10/13/20 11:08 AM, Zhen Lei wrote: The property name used in arch/arm/boot/dts/mmp2-olpc-xo-1-75.dts is cmd-gpio. arch/arm/boot/dts/mmp2-olpc-xo-1-75.dts:235: cmd-gpio = < 155 GPIO_ACTIVE_HIGH>; Signed-off-by: Zhen Lei --- Documentation/devicetree/bindings/misc/olpc,xo1.75-ec.yaml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Documentation/devicetree/bindings/misc/olpc,xo1.75-ec.yaml b/Documentation/devicetree/bindings/misc/olpc,xo1.75-ec.yaml index b3c45c046ba5e37..c7a06a9650db2ed 100644 --- a/Documentation/devicetree/bindings/misc/olpc,xo1.75-ec.yaml +++ b/Documentation/devicetree/bindings/misc/olpc,xo1.75-ec.yaml @@ -24,7 +24,7 @@ properties: compatible: const: olpc,xo1.75-ec - cmd-gpios: + cmd-gpio: >>> >>> Preference is gpios not gpio. But Rob H accept or reject >> >> Look at the search result below. It seems that the driver have not been >> merged into mainline. > > Yes, in drivers/platform/olpc/olpc-xo175-ec.c. > > Your mistake is the gpiod api takes just 'cmd' as the GPIO core handles > both forms. OK, thanks for your information. I have found that it defined by gpio_suffixes[]. > >> But the property name is really used as cmd-gpio at >> mmp2-olpc-xo-1-75.dts:235, I don't think >> the mmp2-olpc-xo-1-75.dts can make a mistake. Otherwise, the driver will not >> work properly. >> Meanwhile, Both names cmd-gpios and cmd-gpio seem to be in use. But I prefer >> cmd-gpio, after >> all, only one gpio is assigned now. The motorola,cmd-gpios add "s" because >> it contains 3 gpio. > > The preference is it is always '-gpios' just like it's always > 'interrupts' or 'clocks'. > > However, whether to change this is really up to the OLPC folks. Given > the driver has always supported both forms, it should be okay to change > the dts. Though there could be other users besides the kernel. If both "cmd-gpios" and "cmd-gpio" are supported, should we use enum to list both of them in yaml? or use patternProperties? I'm going to send v2 based on this idea. > > Rob > > . >
Re: [PATCH 5/8] x86/clear_page: add clear_page_uncached()
On 2020-10-14 2:07 p.m., Andy Lutomirski wrote: On Oct 14, 2020, at 12:58 PM, Borislav Petkov wrote: On Wed, Oct 14, 2020 at 08:45:37AM -0700, Andy Lutomirski wrote: On Wed, Oct 14, 2020 at 1:33 AM Ankur Arora wrote: Define clear_page_uncached() as an alternative_call() to clear_page_nt() if the CPU sets X86_FEATURE_NT_GOOD and fallback to clear_page() if it doesn't. Similarly define clear_page_uncached_flush() which provides an SFENCE if the CPU sets X86_FEATURE_NT_GOOD. As long as you keep "NT" or "MOVNTI" in the names and keep functions in arch/x86, I think it's reasonable to expect that callers understand that MOVNTI has bizarre memory ordering rules. But once you give something a generic name like "clear_page_uncached" and stick it in generic code, I think the semantics should be more obvious. Why does it have to be a separate call? Why isn't it behind the clear_page() alternative machinery so that the proper function is selected at boot? IOW, why does a user of clear_page functionality need to know at all about an "uncached" variant? I assume it’s for a little optimization of clearing more than one page per SFENCE. In any event, based on the benchmark data upthread, we only want to do NT clears when they’re rather large, so this shouldn’t be just an alternative. I assume this is because a page or two will fit in cache and, for most uses that allocate zeroed pages, we prefer cache-hot pages. When clearing 1G, on the other hand, cache-hot is impossible and we prefer the improved bandwidth and less cache trashing of NT clears. Also, if we did extend clear_page() to take the page-size as parameter we still might not have enough information (ex. a 4K or a 2MB page that clear_page() sees could be part of a GUP of a much larger extent) to decide whether to go uncached or not. Perhaps SFENCE is so fast that this is a silly optimization, though, and we don’t lose anything measurable by SFENCEing once per page. Alas, no. I tried that and dropped about 15% performance on Rome. Thanks Ankur
[PATCH v8 1/2] dt-bindings: devapc: add bindings for mtk-devapc
Add bindings for mtk-devapc.
Signed-off-by: Neal Liu
---
.../devicetree/bindings/soc/mediatek/devapc.yaml | 58
1 file changed, 58 insertions(+)
create mode 100644 Documentation/devicetree/bindings/soc/mediatek/devapc.yaml
diff --git a/Documentation/devicetree/bindings/soc/mediatek/devapc.yaml
b/Documentation/devicetree/bindings/soc/mediatek/devapc.yaml
new file mode 100644
index 000..6c763f8
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/mediatek/devapc.yaml
@@ -0,0 +1,58 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# # Copyright 2020 MediaTek Inc.
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/soc/mediatek/devapc.yaml#;
+$schema: "http://devicetree.org/meta-schemas/core.yaml#;
+
+title: MediaTek Device Access Permission Control driver
+
+description: |
+ MediaTek bus fabric provides TrustZone security support and data
+ protection to prevent slaves from being accessed by unexpected masters.
+ The security violation is logged and sent to the processor for further
+ analysis and countermeasures.
+
+maintainers:
+ - Neal Liu
+
+properties:
+ compatible:
+enum:
+ - mediatek,mt6779-devapc
+
+ reg:
+description: The base address of devapc register bank
+maxItems: 1
+
+ interrupts:
+description: A single interrupt specifier
+maxItems: 1
+
+ clocks:
+description: Contains module clock source and clock names
+maxItems: 1
+
+ clock-names:
+description: Names of the clocks list in clocks property
+maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+
+examples:
+ - |
+#include
+#include
+
+devapc: devapc@10207000 {
+ compatible = "mediatek,mt6779-devapc";
+ reg = <0x10207000 0x1000>;
+ interrupts = ;
+ clocks = <_ao CLK_INFRA_DEVICE_APC>;
+ clock-names = "devapc-infra-clock";
+};
--
1.7.9.5
linux-next: manual merge of the devicetree tree with Linus' tree
Hi all,
Today's linux-next merge of the devicetree tree got a conflict in:
Documentation/x86/index.rst
between commit:
ea4e3bef4c94 ("Documentation/x86: Add documentation for /proc/cpuinfo feature
flags")
from Linus' tree and commit:
441848282c59 ("dt: Remove booting-without-of.rst")
from the devicetree tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc Documentation/x86/index.rst
index 740ee7f87898,1faf44f551bd..
--- a/Documentation/x86/index.rst
+++ b/Documentation/x86/index.rst
@@@ -9,7 -9,7 +9,8 @@@ x86-specific Documentatio
:numbered:
boot
+booting-dt
+ cpuinfo
topology
exception-tables
kernel-stacks
pgp_zLMLlN05E.pgp
Description: OpenPGP digital signature
[no subject]
These patch series introduce a MediaTek MT6779 devapc driver. MediaTek bus fabric provides TrustZone security support and data protection to prevent slaves from being accessed by unexpected masters. The security violation is logged and sent to the processor for further analysis or countermeasures. Any occurrence of security violation would raise an interrupt, and it will be handled by mtk-devapc driver. The violation information is printed in order to find the murderer. changes since v7: - fix VIO_MOD_TO_REG_IND calculation wrong problem. - revise parameter type of ISR. changes since v6: - remove unnecessary mask/unmask module irq during ISR. changes since v5: - remove redundant write reg operation. - use static variable of vio_dbgs instead. - add stop_devapc() if driver is removed. changes since v4: - refactor data structure. - merge two simple functions into one. - refactor register setting to prevent too many function call overhead. changes since v3: - revise violation handling flow to make it more easily to understand hardware behavior. - add more comments to understand how hardware works. changes since v2: - pass platform info through DT data. - remove unnecessary function. - remove slave_type because it always equals to 1 in current support SoC. - use vio_idx_num instread of list all devices' index. - add more comments to describe hardware behavior. changes since v1: - move SoC specific part to DT data. - remove unnecessary boundary check. - remove unnecessary data type declaration. - use read_poll_timeout() instread of for loop polling. - revise coding style elegantly. *** BLURB HERE *** Neal Liu (2): dt-bindings: devapc: add bindings for mtk-devapc soc: mediatek: add mt6779 devapc driver .../bindings/soc/mediatek/devapc.yaml | 58 drivers/soc/mediatek/Kconfig | 9 + drivers/soc/mediatek/Makefile | 1 + drivers/soc/mediatek/mtk-devapc.c | 308 ++ 4 files changed, 376 insertions(+) create mode 100644 Documentation/devicetree/bindings/soc/mediatek/devapc.yaml create mode 100644 drivers/soc/mediatek/mtk-devapc.c -- 2.18.0
[PATCH v8 2/2] soc: mediatek: add mt6779 devapc driver
MediaTek bus fabric provides TrustZone security support and data
protection to prevent slaves from being accessed by unexpected
masters.
The security violation is logged and sent to the processor for
further analysis or countermeasures.
Any occurrence of security violation would raise an interrupt, and
it will be handled by mtk-devapc driver. The violation
information is printed in order to find the murderer.
Signed-off-by: Neal Liu
---
drivers/soc/mediatek/Kconfig |9 ++
drivers/soc/mediatek/Makefile |1 +
drivers/soc/mediatek/mtk-devapc.c | 308 +
3 files changed, 318 insertions(+)
create mode 100644 drivers/soc/mediatek/mtk-devapc.c
diff --git a/drivers/soc/mediatek/Kconfig b/drivers/soc/mediatek/Kconfig
index 59a56cd..1177c98 100644
--- a/drivers/soc/mediatek/Kconfig
+++ b/drivers/soc/mediatek/Kconfig
@@ -17,6 +17,15 @@ config MTK_CMDQ
time limitation, such as updating display configuration during the
vblank.
+config MTK_DEVAPC
+ tristate "Mediatek Device APC Support"
+ help
+ Say yes here to enable support for Mediatek Device APC driver.
+ This driver is mainly used to handle the violation which catches
+ unexpected transaction.
+ The violation information is logged for further analysis or
+ countermeasures.
+
config MTK_INFRACFG
bool "MediaTek INFRACFG Support"
select REGMAP
diff --git a/drivers/soc/mediatek/Makefile b/drivers/soc/mediatek/Makefile
index 01f9f87..abfd4ba 100644
--- a/drivers/soc/mediatek/Makefile
+++ b/drivers/soc/mediatek/Makefile
@@ -1,5 +1,6 @@
# SPDX-License-Identifier: GPL-2.0-only
obj-$(CONFIG_MTK_CMDQ) += mtk-cmdq-helper.o
+obj-$(CONFIG_MTK_DEVAPC) += mtk-devapc.o
obj-$(CONFIG_MTK_INFRACFG) += mtk-infracfg.o
obj-$(CONFIG_MTK_PMIC_WRAP) += mtk-pmic-wrap.o
obj-$(CONFIG_MTK_SCPSYS) += mtk-scpsys.o
diff --git a/drivers/soc/mediatek/mtk-devapc.c
b/drivers/soc/mediatek/mtk-devapc.c
new file mode 100644
index 000..f1cea04
--- /dev/null
+++ b/drivers/soc/mediatek/mtk-devapc.c
@@ -0,0 +1,308 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2020 MediaTek Inc.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define VIO_MOD_TO_REG_IND(m) ((m) / 32)
+#define VIO_MOD_TO_REG_OFF(m) ((m) % 32)
+
+struct mtk_devapc_vio_dbgs {
+ union {
+ u32 vio_dbg0;
+ struct {
+ u32 mstid:16;
+ u32 dmnid:6;
+ u32 vio_w:1;
+ u32 vio_r:1;
+ u32 addr_h:4;
+ u32 resv:4;
+ } dbg0_bits;
+ };
+
+ u32 vio_dbg1;
+};
+
+struct mtk_devapc_data {
+ /* numbers of violation index */
+ u32 vio_idx_num;
+
+ /* reg offset */
+ u32 vio_mask_offset;
+ u32 vio_sta_offset;
+ u32 vio_dbg0_offset;
+ u32 vio_dbg1_offset;
+ u32 apc_con_offset;
+ u32 vio_shift_sta_offset;
+ u32 vio_shift_sel_offset;
+ u32 vio_shift_con_offset;
+};
+
+struct mtk_devapc_context {
+ struct device *dev;
+ void __iomem *infra_base;
+ struct clk *infra_clk;
+ const struct mtk_devapc_data *data;
+};
+
+static void clear_vio_status(struct mtk_devapc_context *ctx)
+{
+ void __iomem *reg;
+ int i;
+
+ reg = ctx->infra_base + ctx->data->vio_sta_offset;
+
+ for (i = 0; i < VIO_MOD_TO_REG_IND(ctx->data->vio_idx_num) - 1; i++)
+ writel(GENMASK(31, 0), reg + 4 * i);
+
+ writel(GENMASK(VIO_MOD_TO_REG_OFF(ctx->data->vio_idx_num) - 1, 0),
+ reg + 4 * i);
+}
+
+static void mask_module_irq(struct mtk_devapc_context *ctx, bool mask)
+{
+ void __iomem *reg;
+ u32 val;
+ int i;
+
+ reg = ctx->infra_base + ctx->data->vio_mask_offset;
+
+ if (mask)
+ val = GENMASK(31, 0);
+ else
+ val = 0;
+
+ for (i = 0; i < VIO_MOD_TO_REG_IND(ctx->data->vio_idx_num) - 1; i++)
+ writel(val, reg + 4 * i);
+
+ val = readl(reg + 4 * i);
+ if (mask)
+ val |= GENMASK(VIO_MOD_TO_REG_OFF(ctx->data->vio_idx_num) - 1,
+ 0);
+ else
+ val &= ~GENMASK(VIO_MOD_TO_REG_OFF(ctx->data->vio_idx_num) - 1,
+ 0);
+
+ writel(val, reg + 4 * i);
+}
+
+#define PHY_DEVAPC_TIMEOUT 0x1
+
+/*
+ * devapc_sync_vio_dbg - do "shift" mechansim" to get full violation
information.
+ * shift mechanism is depends on devapc hardware design.
+ * Mediatek devapc set multiple slaves as a group.
+ * When violation is triggered, violation info is kept
+ * inside devapc hardware.
+ * Driver should do shift mechansim to sync full
violation
+ * info
Re: [PATCH 0/2] vfs: move the clone/dedupe/remap helpers to a single file
On Wed, Oct 14, 2020 at 05:31:14PM -0700, Darrick J. Wong wrote: > AFAICT, nobody is attempting to land any major changes in any of the vfs > remap functions during the 5.10 window -- for-next showed conflicts only > in the Makefile, so it seems like a quiet enough time to do this. There > are no functional changes here, it's just moving code blocks around. > > So, I have a few questions, particularly for Al, Andrew, and Linus: > > (1) Do you find this reorganizing acceptable? No objections, assuming that it's really a move (it's surprisingly easy to screw that up - BTDT ;-/) I have not done function-by-function comparison, but assuming it holds... no problem. > (2) I was planning to rebase this series next Friday and try to throw it > in at the end of the merge window; is that ok? (The current patches are > based on 5.9, and applying them manually to current master and for-next > didn't show any new conflicts.) Up to Linus. I don't have anything in vfs.git around that area; the only remaining stuff touching fs/read_write.c is nowhere near those, AFAICS.
RE: [PATCH] firmware: imx: always export scu symbols
Hi Ying,
> -Original Message-
> From: Ying Liu
> Sent: 2020年10月15日 9:33
> To: Joakim Zhang ; shawn...@kernel.org;
> s.ha...@pengutronix.de
> Cc: ker...@pengutronix.de; feste...@gmail.com; dl-linux-imx
> ; linux-arm-ker...@lists.infradead.org;
> linux-kernel@vger.kernel.org; Peng Fan
> Subject: Re: [PATCH] firmware: imx: always export scu symbols
>
> Hi Joakim,
>
> On Wed, 2020-10-14 at 16:57 +0800, Joakim Zhang wrote:
> > From: Liu Ying
> >
> > Always export scu symbols for both SCU SoCs and non-SCU SoCs to avoid
> > build error.
>
> s/scu/SCU/
OK.
> >
> > Signed-off-by: Liu Ying
> > Signed-off-by: Peng Fan
> > Signed-off-by: Joakim Zhang
> > ---
> > include/linux/firmware/imx/ipc.h | 15 +++
> > include/linux/firmware/imx/svc/misc.h | 23 +++
> > 2 files changed, 38 insertions(+)
> >
> > diff --git a/include/linux/firmware/imx/ipc.h
> > b/include/linux/firmware/imx/ipc.h
> > index 891057434858..300fa253fc30 100644
> > --- a/include/linux/firmware/imx/ipc.h
> > +++ b/include/linux/firmware/imx/ipc.h
> > @@ -34,6 +34,7 @@ struct imx_sc_rpc_msg {
> > uint8_t func;
> > };
> >
> > +#if IS_ENABLED(CONFIG_IMX_SCU)
> > /*
> > * This is an function to send an RPC message over an IPC channel.
> > * It is called by client-side SCFW API function shims.
> > @@ -55,4 +56,18 @@ int imx_scu_call_rpc(struct imx_sc_ipc *ipc, void
> > *msg, bool have_resp);
> > * @return Returns an error code (0 = success, failed if < 0)
> > */
> > int imx_scu_get_handle(struct imx_sc_ipc **ipc);
> > +
> > +#else
> > +static inline int
> > +imx_scu_call_rpc(struct imx_sc_ipc *ipc, void *msg, bool have_resp) {
> > + return -EIO;
> > +}
> > +
> > +static inline int imx_scu_get_handle(struct imx_sc_ipc **ipc) {
> > + return -EIO;
> > +}
> > +#endif
> > +
> > #endif /* _SC_IPC_H */
> > diff --git a/include/linux/firmware/imx/svc/misc.h
> > b/include/linux/firmware/imx/svc/misc.h
> > index 031dd4d3c766..d255048f17de 100644
> > --- a/include/linux/firmware/imx/svc/misc.h
> > +++ b/include/linux/firmware/imx/svc/misc.h
> > @@ -46,6 +46,7 @@ enum imx_misc_func {
> > * Control Functions
> > */
> >
> > +#if IS_ENABLED(CONFIG_IMX_SCU)
> > int imx_sc_misc_set_control(struct imx_sc_ipc *ipc, u32 resource,
> > u8 ctrl, u32 val);
> >
> > @@ -55,4 +56,26 @@ int imx_sc_misc_get_control(struct imx_sc_ipc *ipc,
> > u32 resource, int imx_sc_pm_cpu_start(struct imx_sc_ipc *ipc, u32
> > resource,
> > bool enable, u64 phys_addr);
> >
> > +#else
> > +static inline int
> > +imx_sc_misc_set_control(struct imx_sc_ipc *ipc, u32 resource,
> > + u8 ctrl, u32 val)
> > +{
> > + return -EIO;
> > +}
> > +
> > +static inline int
> > +imx_sc_misc_get_control(struct imx_sc_ipc *ipc, u32 resource,
> > + u8 ctrl, u32 *val)
> > +{
> > + return -EIO;
> > +}
> > +
> > +static inline int imx_sc_pm_cpu_start(struct imx_sc_ipc *ipc, u32
> > resource,
> > + bool enable, u64 phys_addr) {
> > + return -EIO;
> > +}
> > +#endif
> > +
> > #endif /* _SC_MISC_API_H */
>
> This is done in our downstream tree. I did this because a downstream display
> driver covers SoCs w/wo SCU. For upstream, I find the drivers can be splited
> so
> that this is not needed.
>
> Do you see any existing upstream driver covers SoCs w/wo SCU?
Yes, FlexCAN driver covers SoCs w/wo SCU, so I need this patch to avoid adding
IS_ENABLED(CONFIG_IMX_SCU) in FlexCAN driver.
> I think this can be introduced together with the first that kink of driver.
Ok, it seems better, thanks.
Best Regards,
Joakim Zhang
> --
> Liu Ying
Re: [PATCH] slub: Actually fix freelist pointer vs redzoning
On Wed, Oct 14, 2020 at 10:36:01PM -0400, Waiman Long wrote:
> On 10/8/20 7:34 PM, Kees Cook wrote:
> > It turns out that SLUB redzoning ("slub_debug=Z") checks from
> > s->object_size rather than from s->inuse (which is normally bumped to
> > make room for the freelist pointer), so a cache created with an object
> > size less than 24 would have their freelist pointer written beyond
> > s->object_size, causing the redzone to corrupt the freelist pointer.
> > This was very visible with "slub_debug=ZF":
> >
> > BUG test (Tainted: GB): Redzone overwritten
> > -
> >
> > INFO: 0x957ead1c05de-0x957ead1c05df @offset=1502. First byte 0x1a
> > instead of 0xbb
> > INFO: Slab 0xef3950b47000 objects=170 used=170 fp=0x
> > flags=0x8200
> > INFO: Object 0x957ead1c05d8 @offset=1496 fp=0x957ead1c0620
> >
> > Redzone (ptrval): bb bb bb bb bb bb bb bb
> > Object (ptrval): 00 00 00 00 00 f6 f4 a5
> > Redzone (ptrval): 40 1d e8 1a aa@
> > Padding (ptrval): 00 00 00 00 00 00 00 00
> >
> > Adjust the offset to stay within s->object_size.
> >
> > (Note that there appear to be no such small-sized caches in the kernel
> > currently.)
> >
> > Reported-by: Marco Elver
> > Link:
> > https://lore.kernel.org/linux-mm/20200807160627.ga1420...@elver.google.com/
> > Fixes: 89b83f282d8b (slub: avoid redzone when choosing freepointer location)
> > Cc: sta...@vger.kernel.org
> > Signed-off-by: Kees Cook
> > ---
> > mm/slub.c | 17 +
> > 1 file changed, 5 insertions(+), 12 deletions(-)
> >
> > diff --git a/mm/slub.c b/mm/slub.c
> > index 68c02b2eecd9..979f5da26992 100644
> > --- a/mm/slub.c
> > +++ b/mm/slub.c
> > @@ -3641,7 +3641,6 @@ static int calculate_sizes(struct kmem_cache *s, int
> > forced_order)
> > {
> > slab_flags_t flags = s->flags;
> > unsigned int size = s->object_size;
> > - unsigned int freepointer_area;
> > unsigned int order;
> > /*
> > @@ -3650,13 +3649,6 @@ static int calculate_sizes(struct kmem_cache *s, int
> > forced_order)
> > * the possible location of the free pointer.
> > */
> > size = ALIGN(size, sizeof(void *));
> > - /*
> > -* This is the area of the object where a freepointer can be
> > -* safely written. If redzoning adds more to the inuse size, we
> > -* can't use that portion for writing the freepointer, so
> > -* s->offset must be limited within this for the general case.
> > -*/
> > - freepointer_area = size;
> > #ifdef CONFIG_SLUB_DEBUG
> > /*
> > @@ -3682,7 +3674,7 @@ static int calculate_sizes(struct kmem_cache *s, int
> > forced_order)
> > /*
> > * With that we have determined the number of bytes in actual use
> > -* by the object. This is the potential offset to the free pointer.
> > +* by the object and redzoning.
> > */
> > s->inuse = size;
> > @@ -3694,7 +3686,8 @@ static int calculate_sizes(struct kmem_cache *s, int
> > forced_order)
> > * kmem_cache_free.
> > *
> > * This is the case if we do RCU, have a constructor or
> > -* destructor or are poisoning the objects.
> > +* destructor, are poisoning the objects, or are
> > +* redzoning an object smaller than sizeof(void *).
> > *
> > * The assumption that s->offset >= s->inuse means free
> > * pointer is outside of the object is used in the
>
> There is no check to go into this if condition to put free pointer after
> object when redzoning an object smaller than sizeof(void *). In that sense,
> the additional comment isn't correct.
Right -- part of this is why I did my v2 series[1], where I failed to find
where that had been enforced, and explicitly added it[2]. If no one
objects, I could fold that check into this fix, just for robustness.
cache creation is not fast-path, and the size test is a trivial check.
> Should we add that check even though we don't have slab objects with such a
> small size in the kernel?
I'd like to... I will spin a v3.
Thanks!
[1] https://lore.kernel.org/lkml/20201009195411.4018141-1-keesc...@chromium.org/
[2] https://lore.kernel.org/lkml/20201009195411.4018141-3-keesc...@chromium.org/
--
Kees Cook
Re: [PATCH v6 2/2] PCI/ERR: Split the fatal and non-fatal error recovery handling
On 10/14/20 6:58 PM, Ethan Zhao wrote:
On Thu, Oct 15, 2020 at 1:06 AM Kuppuswamy, Sathyanarayanan
wrote:
On 10/14/20 8:07 AM, Ethan Zhao wrote:
On Wed, Oct 14, 2020 at 5:00 PM Kuppuswamy Sathyanarayanan
wrote:
Commit bdb5ac85777d ("PCI/ERR: Handle fatal error recovery")
merged fatal and non-fatal error recovery paths, and also made
recovery code depend on hotplug handler for "remove affected
device + rescan" support. But this change also complicated the
error recovery path and which in turn led to the following
issues.
1. We depend on hotplug handler for removing the affected
devices/drivers on DLLSC LINK down event (on DPC event
trigger) and DPC handler for handling the error recovery. Since
both handlers operate on same set of affected devices, it leads
to race condition, which in turn leads to NULL pointer
exceptions or error recovery failures.You can find more details
about this issue in following link.
https://lore.kernel.org/linux-pci/20201007113158.48933-1-haifeng.z...@intel.com/T/#t
2. For non-hotplug capable devices fatal (DPC) error recovery
is currently broken. Current fatal error recovery implementation
relies on PCIe hotplug (pciehp) handler for detaching and
re-enumerating the affected devices/drivers. So when dealing with
non-hotplug capable devices, recovery code does not restore the state
of the affected devices correctly. You can find more details about
this issue in the following links.
https://lore.kernel.org/linux-pci/20200527083130.4137-1-zhiqiang@nxp.com/
https://lore.kernel.org/linux-pci/12115.1588207324@famine/
https://lore.kernel.org/linux-pci/0e6f89cd6b9e4a72293cc90fafe93487d7c2d295.158584.git.sathyanarayanan.kuppusw...@linux.intel.com/
In order to fix the above two issues, we should stop relying on hotplug
Yes, it doesn't rely on hotplug handler to remove and rescan the device,
but it couldn't prevent hotplug drivers from doing another replicated
removal/rescanning.
it doesn't make sense to leave another useless removal/rescanning there.
Maybe that's why these two paths were merged to one and made it rely on
hotplug.
No, as per PCIe spec, hotplug and DPC has no functional dependency. Hence
depending on it to handle some of its recovery function is in-correct and
would lead to issues in non-hotplug capable platforms (which is true
currently).
pci_lock_rescan_remove() is global lock for PCIe, the mal-functional
device's port holds this lock, it prevents the whole system from doing
hot-plug operation.
It does not prevent the hotplug operation, but it might delay it. Since both
DPC and hotplug operates on same set of devices, it must be synchronized.
Though pciehp is not so hot/scalable and performance critical, but there
is per cpu thread to handle hot-plug operation. synchronize all threads
make them walk backwards for scalability.
DPC events does not happen in high frequency. So I don't think we should
worry about the performance here. Even hotplug handler will hold this lock
when adding/removing the devices. So adding/removing devices is a serialized
operation.
--
2.17.1
--
Sathyanarayanan Kuppuswamy
Linux Kernel Developer
--
Sathyanarayanan Kuppuswamy
Linux Kernel Developer
[PATCH] optee: remove address tag in check_mem_type()
Before passing 'start' to find_vma() we need to remove tags from it to get sane results. Signed-off-by: Volodymyr Babchuk --- drivers/tee/optee/call.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/tee/optee/call.c b/drivers/tee/optee/call.c index a5afbe6dee68..61420395137b 100644 --- a/drivers/tee/optee/call.c +++ b/drivers/tee/optee/call.c @@ -562,6 +562,8 @@ static int check_mem_type(unsigned long start, size_t num_pages) struct mm_struct *mm = current->mm; int rc; + start = untagged_addr(start); + down_read(>mmap_sem); rc = __check_mem_type(find_vma(mm, start), start + num_pages * PAGE_SIZE); -- 2.27.0
Re: [git pull] drm next pull for 5.10-rc1
On Thu, 15 Oct 2020 at 11:33, Dave Airlie wrote: > > Hi Linus, > > This is the main drm pull request for 5.10. > > Not a major amount of change, the i915 trees got split into display > and gt trees to better facilitate higher level review, and there's a > major refactoring of i915 GEM locking to use more core kernel concepts > (like ww-mutexes). msm gets per-process pagetables, older AMD SI cards > get DC support, nouveau got a bump in displayport support with common > code extraction from i915. > > There are a bunch of conflicts but none of them seemed overly scary, > and sfr has provided resolutions for them all. I've put a tree up with > my merge results, so you can tell me I did it wrong here: > https://cgit.freedesktop.org/~airlied/linux/log/?h=drm-next-5.10-merged Apparently I lied, and I only built my merged tree on x86 https://lore.kernel.org/dri-devel/20201015134357.0a4e6...@canb.auug.org.au/T/#t Please apply the patch from this thread once you merge my tree. Dave.
Re: [PATCH 0/2] vfs: move the clone/dedupe/remap helpers to a single file
On Wed, Oct 14, 2020 at 5:31 PM Darrick J. Wong wrote: > > So, I have a few questions, particularly for Al, Andrew, and Linus: > > (1) Do you find this reorganizing acceptable? I don't see a problem. > (3) Can I just grab the copyrights from mm/filemap.c? Or fs/read_write.c? > Or something entirely different? Heh. Those copyright notices look pretty old, and I'm not sure how much - if anything - I had to do with the remap helpers. I suspect just a // SPDX-License-Identifier: GPL-2.0-only is fine, with no need to try to drag along any other copyright notice history from those two files. Linus
[PATCH] iommu/amd: Increase interrupt remapping table limit to 512 entries
Certain device drivers allocate IO queues on a per-cpu basis.
On AMD EPYC platform, which can support up-to 256 cpu threads,
this can exceed the current MAX_IRQ_PER_TABLE limit of 256,
and result in the error message:
AMD-Vi: Failed to allocate IRTE
This has been observed with certain NVME devices.
AMD IOMMU hardware can actually support upto 512 interrupt
remapping table entries. Therefore, update the driver to
match the hardware limit.
Please note that this also increases the size of interrupt remapping
table to 8KB per device when using the 128-bit IRTE format.
Signed-off-by: Suravee Suthikulpanit
---
drivers/iommu/amd/amd_iommu_types.h | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/amd/amd_iommu_types.h
b/drivers/iommu/amd/amd_iommu_types.h
index 30a5d412255a..427484c45589 100644
--- a/drivers/iommu/amd/amd_iommu_types.h
+++ b/drivers/iommu/amd/amd_iommu_types.h
@@ -406,7 +406,11 @@ extern bool amd_iommu_np_cache;
/* Only true if all IOMMUs support device IOTLBs */
extern bool amd_iommu_iotlb_sup;
-#define MAX_IRQS_PER_TABLE 256
+/*
+ * AMD IOMMU hardware only support 512 IRTEs despite
+ * the architectural limitation of 2048 entries.
+ */
+#define MAX_IRQS_PER_TABLE 512
#define IRQ_TABLE_ALIGNMENT128
struct irq_remap_table {
--
2.17.1
Re: linux-next: build failure after merge of the iommu tree
Hi all,
On Tue, 13 Oct 2020 18:31:07 +1100 Stephen Rothwell
wrote:
>
> On Mon, 21 Sep 2020 14:09:01 +1000 Stephen Rothwell
> wrote:
> >
> > After merging the iommu tree, today's linux-next build (arm
> > multi_v7_defconfig) failed like this:
> >
> > drivers/gpu/drm/msm/msm_iommu.c: In function 'msm_iommu_pagetable_unmap':
> > drivers/gpu/drm/msm/msm_iommu.c:46:2: error: implicit declaration of
> > function 'iommu_flush_tlb_all'; did you mean 'iommu_flush_iotlb_all'?
> > [-Werror=implicit-function-declaration]
> >46 | iommu_flush_tlb_all(to_msm_iommu(pagetable->parent)->domain);
> > | ^~~
> > | iommu_flush_iotlb_all
> >
> > Caused by commit
> >
> > aae4c8e27bd7 ("iommu: Rename iommu_tlb_* functions to iommu_iotlb_*")
> >
> > interacting with commit
> >
> > b145c6e65eb0 ("drm/msm: Add support to create a local pagetable")
> >
> > from the drm-msm tree.
> >
> > I have applied the following merge fix patch. Someone will need to tell
> > Linus about this fix up when the trees get merged.
> >
> > From: Stephen Rothwell
> > Date: Mon, 21 Sep 2020 14:04:14 +1000
> > Subject: [PATCH] merge fix upt for iommu_flush_iotlb_all() rename
> >
> > Signed-off-by: Stephen Rothwell
> > ---
> > drivers/gpu/drm/msm/msm_iommu.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/msm/msm_iommu.c
> > b/drivers/gpu/drm/msm/msm_iommu.c
> > index 3a83ffdb3b90..22ac7c692a81 100644
> > --- a/drivers/gpu/drm/msm/msm_iommu.c
> > +++ b/drivers/gpu/drm/msm/msm_iommu.c
> > @@ -43,7 +43,7 @@ static int msm_iommu_pagetable_unmap(struct msm_mmu *mmu,
> > u64 iova,
> > size -= 4096;
> > }
> >
> > - iommu_flush_tlb_all(to_msm_iommu(pagetable->parent)->domain);
> > + iommu_flush_iotlb_all(to_msm_iommu(pagetable->parent)->domain);
> >
> > return (unmapped == size) ? 0 : -EINVAL;
> > }
> > @@ -199,7 +199,7 @@ struct msm_mmu *msm_iommu_pagetable_create(struct
> > msm_mmu *parent)
> >
> > /*
> > * TODO we would like each set of page tables to have a unique ASID
> > -* to optimize TLB invalidation. But iommu_flush_tlb_all() will
> > +* to optimize TLB invalidation. But iommu_flush_iotlb_all() will
> > * end up flushing the ASID used for TTBR1 pagetables, which is not
> > * what we want. So for now just use the same ASID as TTBR1.
> > */
> > --
> > 2.28.0
>
> This merge fix up is now needed when the iommu tree and the drm tree are
> merged.
This merge fix up is now needed when the drm tree is merged with Linus' tree.
--
Cheers,
Stephen Rothwell
pgp2YWfGesxYn.pgp
Description: OpenPGP digital signature
[PATCH] drm/amd: remove unnecessary conversion from bool value to bool
In functions vegam_is_dpm_running & vegam_populate_avfs_parameters,
maybe there is no need to conver bool condition to bool variable
or bool return value.
This change is to make the code a bit more readable.
Signed-off-by: Bernard Zhao
---
drivers/gpu/drm/amd/powerplay/smumgr/vegam_smumgr.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/vegam_smumgr.c
b/drivers/gpu/drm/amd/powerplay/smumgr/vegam_smumgr.c
index 0ecc18b55ffb..32ca472f58a6 100644
--- a/drivers/gpu/drm/amd/powerplay/smumgr/vegam_smumgr.c
+++ b/drivers/gpu/drm/amd/powerplay/smumgr/vegam_smumgr.c
@@ -296,8 +296,9 @@ static int vegam_process_firmware_header(struct pp_hwmgr
*hwmgr)
static bool vegam_is_dpm_running(struct pp_hwmgr *hwmgr)
{
return (1 == PHM_READ_INDIRECT_FIELD(hwmgr->device,
- CGS_IND_REG__SMC, FEATURE_STATUS,
VOLTAGE_CONTROLLER_ON))
- ? true : false;
+CGS_IND_REG__SMC,
+FEATURE_STATUS,
+VOLTAGE_CONTROLLER_ON));
}
static uint32_t vegam_get_mac_definition(uint32_t value)
@@ -1661,7 +1662,7 @@ static int vegam_populate_avfs_parameters(struct pp_hwmgr
*hwmgr)
(avfs_params.ucEnableGB_FUSE_TABLE_CKSON <<
AVFSGB0_Vdroop_Enable_SHIFT) |
(avfs_params.ucEnableGB_FUSE_TABLE_CKSOFF <<
AVFSGB1_Vdroop_Enable_SHIFT);
data->apply_avfs_cks_off_voltage =
- (avfs_params.ucEnableApplyAVFS_CKS_OFF_Voltage
== 1) ? true : false;
+ (avfs_params.ucEnableApplyAVFS_CKS_OFF_Voltage
== 1);
}
return result;
}
--
2.28.0
Re: [PATCH] slub: Actually fix freelist pointer vs redzoning
On 10/8/20 7:34 PM, Kees Cook wrote:
It turns out that SLUB redzoning ("slub_debug=Z") checks from
s->object_size rather than from s->inuse (which is normally bumped to
make room for the freelist pointer), so a cache created with an object
size less than 24 would have their freelist pointer written beyond
s->object_size, causing the redzone to corrupt the freelist pointer.
This was very visible with "slub_debug=ZF":
BUG test (Tainted: GB): Redzone overwritten
-
INFO: 0x957ead1c05de-0x957ead1c05df @offset=1502. First byte 0x1a
instead of 0xbb
INFO: Slab 0xef3950b47000 objects=170 used=170 fp=0x
flags=0x8200
INFO: Object 0x957ead1c05d8 @offset=1496 fp=0x957ead1c0620
Redzone (ptrval): bb bb bb bb bb bb bb bb
Object (ptrval): 00 00 00 00 00 f6 f4 a5
Redzone (ptrval): 40 1d e8 1a aa@
Padding (ptrval): 00 00 00 00 00 00 00 00
Adjust the offset to stay within s->object_size.
(Note that there appear to be no such small-sized caches in the kernel
currently.)
Reported-by: Marco Elver
Link:
https://lore.kernel.org/linux-mm/20200807160627.ga1420...@elver.google.com/
Fixes: 89b83f282d8b (slub: avoid redzone when choosing freepointer location)
Cc: sta...@vger.kernel.org
Signed-off-by: Kees Cook
---
mm/slub.c | 17 +
1 file changed, 5 insertions(+), 12 deletions(-)
diff --git a/mm/slub.c b/mm/slub.c
index 68c02b2eecd9..979f5da26992 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -3641,7 +3641,6 @@ static int calculate_sizes(struct kmem_cache *s, int
forced_order)
{
slab_flags_t flags = s->flags;
unsigned int size = s->object_size;
- unsigned int freepointer_area;
unsigned int order;
/*
@@ -3650,13 +3649,6 @@ static int calculate_sizes(struct kmem_cache *s, int
forced_order)
* the possible location of the free pointer.
*/
size = ALIGN(size, sizeof(void *));
- /*
-* This is the area of the object where a freepointer can be
-* safely written. If redzoning adds more to the inuse size, we
-* can't use that portion for writing the freepointer, so
-* s->offset must be limited within this for the general case.
-*/
- freepointer_area = size;
#ifdef CONFIG_SLUB_DEBUG
/*
@@ -3682,7 +3674,7 @@ static int calculate_sizes(struct kmem_cache *s, int
forced_order)
/*
* With that we have determined the number of bytes in actual use
-* by the object. This is the potential offset to the free pointer.
+* by the object and redzoning.
*/
s->inuse = size;
@@ -3694,7 +3686,8 @@ static int calculate_sizes(struct kmem_cache *s, int forced_order)
* kmem_cache_free.
*
* This is the case if we do RCU, have a constructor or
-* destructor or are poisoning the objects.
+* destructor, are poisoning the objects, or are
+* redzoning an object smaller than sizeof(void *).
*
* The assumption that s->offset >= s->inuse means free
* pointer is outside of the object is used in the
There is no check to go into this if condition to put free pointer after
object when redzoning an object smaller than sizeof(void *). In that
sense, the additional comment isn't correct.
Should we add that check even though we don't have slab objects with
such a small size in the kernel?
@@ -3703,13 +3696,13 @@ static int calculate_sizes(struct kmem_cache *s, int
forced_order)
*/
s->offset = size;
size += sizeof(void *);
- } else if (freepointer_area > sizeof(void *)) {
+ } else {
/*
* Store freelist pointer near middle of object to keep
* it away from the edges of the object to avoid small
* sized over/underflows from neighboring allocations.
*/
- s->offset = ALIGN(freepointer_area / 2, sizeof(void *));
+ s->offset = ALIGN_DOWN(s->object_size / 2, sizeof(void *));
}
#ifdef CONFIG_SLUB_DEBUG
Other than the above, the patch looks good.
Cheers,
Longman
Re: [PATCH 2/2] nvmem: core: add OF_RECONFIG handler for nvmem cells
Hi Michael,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v5.9 next-20201013]
[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/Michael-Auchter/nvmem-add-DT-overlay-support-for-cells/20201015-054223
base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
37187df45af7d28d27b5c130c23f407ca9dbefa2
config: x86_64-randconfig-a006-20201014 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project
e7b4feea8e1bf520b34ad8c116abab6677344b74)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
#
https://github.com/0day-ci/linux/commit/a3191767e8e4e0480e36126ce93e6ab41ab6f498
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Michael-Auchter/nvmem-add-DT-overlay-support-for-cells/20201015-054223
git checkout a3191767e8e4e0480e36126ce93e6ab41ab6f498
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
>> drivers/nvmem/core.c:1701:42: error: use of undeclared identifier
>> 'nvmem_of_notifier'; did you mean 'nvmem_notifier'?
WARN_ON(of_reconfig_notifier_register(_of_notifier));
^
nvmem_notifier
include/asm-generic/bug.h:119:25: note: expanded from macro 'WARN_ON'
int __ret_warn_on = !!(condition); \
^
drivers/nvmem/core.c:67:31: note: 'nvmem_notifier' declared here
static BLOCKING_NOTIFIER_HEAD(nvmem_notifier);
^
drivers/nvmem/core.c:1709:44: error: use of undeclared identifier
'nvmem_of_notifier'; did you mean 'nvmem_notifier'?
WARN_ON(of_reconfig_notifier_unregister(_of_notifier));
^
nvmem_notifier
include/asm-generic/bug.h:119:25: note: expanded from macro 'WARN_ON'
int __ret_warn_on = !!(condition); \
^
drivers/nvmem/core.c:67:31: note: 'nvmem_notifier' declared here
static BLOCKING_NOTIFIER_HEAD(nvmem_notifier);
^
2 errors generated.
vim +1701 drivers/nvmem/core.c
1691
1692 static int __init nvmem_init(void)
1693 {
1694 int rval;
1695
1696 rval = bus_register(_bus_type);
1697 if (rval)
1698 return rval;
1699
1700 if (IS_ENABLED(CONFIG_OF_DYNAMIC))
> 1701
> WARN_ON(of_reconfig_notifier_register(_of_notifier));
1702
1703 return 0;
1704 }
1705
---
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] opp: Don't always remove static OPPs in _of_add_opp_table_v1()
Hi Viresh
Thanks for the quick fix.
> From: Viresh Kumar
> Sent: Wednesday, October 14, 2020 12:26 PM
>
> The patch missed returning 0 early in case of success and hence the static
> OPPs
> got removed by mistake. Fix it.
>
> Fixes: 90d46d71cce2 ("opp: Handle multiple calls for same OPP table in
> _of_add_opp_table_v1()")
> Reported-by: Aisheng Dong
> Signed-off-by: Viresh Kumar
Tested-by: Dong Aisheng
Regards
Aisheng
> ---
> drivers/opp/of.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/opp/of.c b/drivers/opp/of.c index
> 874b58756220..9faeb83e4b32 100644
> --- a/drivers/opp/of.c
> +++ b/drivers/opp/of.c
> @@ -944,6 +944,8 @@ static int _of_add_opp_table_v1(struct device *dev,
> struct opp_table *opp_table)
> nr -= 2;
> }
>
> + return 0;
> +
> remove_static_opp:
> _opp_remove_all_static(opp_table);
>
> --
> 2.25.0.rc1.19.g042ed3e048af
Re: [PATCH 1/1] net: ftgmac100: Fix Aspeed ast2600 TX hang issue
On Thu, 15 Oct 2020 at 01:49, Dylan Hung wrote: > > > I was encountering this issue when I was running the iperf TX test. The > > symptom is the TX descriptors are consumed, but no complete packet is sent > > out. > > > > What parameters are you using for iperf? I did a lot of testing with > > iperf3 (and stress-ng running at the same time) and couldn't reproduce the > > error. > > > > I simply use "iperf -c " on ast2600. It is very easy to > reproduce. I append the log below: > Noticed that this issue only happens when HW scatter-gather (NETIF_F_SG) is > on. Ok. This appears to be on by default in the drivers/net/ethernet/faraday/ftgmac100.c: netdev->hw_features = NETIF_F_RXCSUM | NETIF_F_HW_CSUM | NETIF_F_GRO | NETIF_F_SG | NETIF_F_HW_VLAN_CTAG_RX | NETIF_F_HW_VLAN_CTAG_TX; > [AST /]$ iperf3 -c 192.168.100.89 > Connecting to host 192.168.100.89, port 5201 > [ 4] local 192.168.100.45 port 45346 connected to 192.168.100.89 port 5201 > [ ID] Interval Transfer Bandwidth Retr Cwnd > [ 4] 0.00-1.00 sec 44.8 MBytes 375 Mbits/sec2 1.43 KBytes > [ 4] 1.00-2.00 sec 0.00 Bytes 0.00 bits/sec2 1.43 KBytes > [ 4] 2.00-3.00 sec 0.00 Bytes 0.00 bits/sec0 1.43 KBytes > [ 4] 3.00-4.00 sec 0.00 Bytes 0.00 bits/sec1 1.43 KBytes > [ 4] 4.00-5.00 sec 0.00 Bytes 0.00 bits/sec0 1.43 KBytes > ^C[ 4] 5.00-5.88 sec 0.00 Bytes 0.00 bits/sec0 1.43 KBytes > - - - - - - - - - - - - - - - - - - - - - - - - - > [ ID] Interval Transfer Bandwidth Retr > [ 4] 0.00-5.88 sec 44.8 MBytes 64.0 Mbits/sec5 sender > [ 4] 0.00-5.88 sec 0.00 Bytes 0.00 bits/sec receiver > iperf3: interrupt - the client has terminated I just realised my test machine must be on a 100Mbit network. I will try testing on a gigabit network. > > We could only reproduce it when performing other functions, such as > > debugging/booting the host processor. > > > Could it be another issue? I hope not! We have deployed your patch on our systems and I will let you know if we see the bug again. > > > > > +/* > > > > > + * test mode control register > > > > > + */ > > > > > +#define FTGMAC100_TM_RQ_TX_VALID_DIS (1 << 28) #define > > > > > +FTGMAC100_TM_RQ_RR_IDLE_PREV (1 << 27) #define > > > > > +FTGMAC100_TM_DEFAULT > > > > \ > > > > > + (FTGMAC100_TM_RQ_TX_VALID_DIS | > > > > FTGMAC100_TM_RQ_RR_IDLE_PREV) > > > > > > > > Will aspeed issue an updated datasheet with this register documented? > > > > Did you see this question? > > > Sorry, I missed this question. Aspeed will update the datasheet accordingly. Thank you.
RE: [PATCH 12/13] remoteproc: Refactor rproc delete and cdev release path
> Subject: [PATCH 12/13] remoteproc: Refactor rproc delete and cdev release
> path
>
> Refactor function rproc_del() and rproc_cdev_release() to take into account
> scenarios where the remote processor has been attached to. If the remote
> processor has been started by the remoteproc core then switch it off, and if
> it
> was attached to detach from it. This heuristic is simple and can be enhanced
> easily if there is a need to.
>
> Signed-off-by: Mathieu Poirier
> ---
> drivers/remoteproc/remoteproc_cdev.c | 7 ++-
> drivers/remoteproc/remoteproc_core.c | 5 -
> 2 files changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/remoteproc/remoteproc_cdev.c
> b/drivers/remoteproc/remoteproc_cdev.c
> index 3a3830e27050..18cffbe588c1 100644
> --- a/drivers/remoteproc/remoteproc_cdev.c
> +++ b/drivers/remoteproc/remoteproc_cdev.c
> @@ -87,8 +87,13 @@ static int rproc_cdev_release(struct inode *inode,
> struct file *filp) {
> struct rproc *rproc = container_of(inode->i_cdev, struct rproc, cdev);
>
> - if (rproc->cdev_put_on_release && rproc->state == RPROC_RUNNING)
> + if (!rproc->cdev_put_on_release)
> + return 0;
> +
> + if (rproc->state == RPROC_RUNNING)
> rproc_shutdown(rproc);
> + else if (rproc->state == RPROC_ATTACHED)
> + rproc_detach(rproc);
>
> return 0;
> }
> diff --git a/drivers/remoteproc/remoteproc_core.c
> b/drivers/remoteproc/remoteproc_core.c
> index 95bb40b4ebb3..5586582f54c5 100644
> --- a/drivers/remoteproc/remoteproc_core.c
> +++ b/drivers/remoteproc/remoteproc_core.c
> @@ -2346,7 +2346,10 @@ int rproc_del(struct rproc *rproc)
> return -EINVAL;
>
> /* TODO: make sure this works with rproc->power > 1 */
> - rproc_shutdown(rproc);
> + if (rproc->state == RPROC_RUNNING)
> + rproc_shutdown(rproc);
> + else if (rproc->state == RPROC_ATTACHED)
> + rproc_detach(rproc);
>
> mutex_lock(>lock);
> rproc->state = RPROC_DELETED;
> --
Reviewed-by: Peng Fan
RE: [PATCH 11/13] remoteproc: Properly deal with detach request
> Subject: [PATCH 11/13] remoteproc: Properly deal with detach request
>
> This patch introduces the capability to detach a remote processor that has
> been attached to or booted by the remoteproc core. For that to happen a
> rproc::ops::detach() operation need to be available.
>
> Signed-off-by: Mathieu Poirier
> ---
> drivers/remoteproc/remoteproc_cdev.c | 6 ++
> drivers/remoteproc/remoteproc_sysfs.c | 6 ++
> 2 files changed, 12 insertions(+)
>
> diff --git a/drivers/remoteproc/remoteproc_cdev.c
> b/drivers/remoteproc/remoteproc_cdev.c
> index d06f8d4919c7..3a3830e27050 100644
> --- a/drivers/remoteproc/remoteproc_cdev.c
> +++ b/drivers/remoteproc/remoteproc_cdev.c
> @@ -42,6 +42,12 @@ static ssize_t rproc_cdev_write(struct file *filp, const
> char __user *buf, size_
> return -EINVAL;
>
> ret = rproc_shutdown(rproc);
> + } else if (!strncmp(cmd, "detach", len)) {
> + if (rproc->state != RPROC_RUNNING &&
> + rproc->state != RPROC_ATTACHED)
> + return -EINVAL;
> +
> + ret = rproc_detach(rproc);
> } else {
> dev_err(>dev, "Unrecognized option\n");
> ret = -EINVAL;
> diff --git a/drivers/remoteproc/remoteproc_sysfs.c
> b/drivers/remoteproc/remoteproc_sysfs.c
> index 6134d2f083ce..013231f69837 100644
> --- a/drivers/remoteproc/remoteproc_sysfs.c
> +++ b/drivers/remoteproc/remoteproc_sysfs.c
> @@ -118,6 +118,12 @@ static ssize_t state_store(struct device *dev,
> return -EINVAL;
>
> ret = rproc_shutdown(rproc);
> + } else if (sysfs_streq(buf, "detach")) {
> + if (rproc->state != RPROC_RUNNING &&
> + rproc->state != RPROC_ATTACHED)
> + return -EINVAL;
> +
> + ret = rproc_detach(rproc);
> } else {
> dev_err(>dev, "Unrecognised option: %s\n", buf);
> ret = -EINVAL;
> --
Reviewed-by: Peng Fan
RE: [PATCH 10/13] remoteproc: Properly deal with a stop request when attached
> Subject: [PATCH 10/13] remoteproc: Properly deal with a stop request when
> attached
>
> This patch introduces the capability to stop a remote processor that has been
> attached to by the remoteproc core. For that to happen a rproc::ops::stop()
> operation need to be available.
>
> Signed-off-by: Mathieu Poirier
> ---
> drivers/remoteproc/remoteproc_cdev.c | 5 +++--
> drivers/remoteproc/remoteproc_core.c | 6 +-
> drivers/remoteproc/remoteproc_sysfs.c | 5 +++--
> 3 files changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/remoteproc/remoteproc_cdev.c
> b/drivers/remoteproc/remoteproc_cdev.c
> index b19ea3057bde..d06f8d4919c7 100644
> --- a/drivers/remoteproc/remoteproc_cdev.c
> +++ b/drivers/remoteproc/remoteproc_cdev.c
> @@ -37,10 +37,11 @@ static ssize_t rproc_cdev_write(struct file *filp, const
> char __user *buf, size_
>
> ret = rproc_boot(rproc);
> } else if (!strncmp(cmd, "stop", len)) {
> - if (rproc->state != RPROC_RUNNING)
> + if (rproc->state != RPROC_RUNNING &&
> + rproc->state != RPROC_ATTACHED)
> return -EINVAL;
>
> - rproc_shutdown(rproc);
> + ret = rproc_shutdown(rproc);
> } else {
> dev_err(>dev, "Unrecognized option\n");
> ret = -EINVAL;
> diff --git a/drivers/remoteproc/remoteproc_core.c
> b/drivers/remoteproc/remoteproc_core.c
> index c6c6aba66098..95bb40b4ebb3 100644
> --- a/drivers/remoteproc/remoteproc_core.c
> +++ b/drivers/remoteproc/remoteproc_core.c
> @@ -1619,6 +1619,10 @@ static int rproc_stop(struct rproc *rproc, bool
> crashed)
> struct device *dev = >dev;
> int ret;
>
> + /* No need to continue if a stop() operation has not been provided */
> + if (!rproc->ops->stop)
> + return -EINVAL;
> +
> /* Stop any subdevices for the remote processor */
> rproc_stop_subdevices(rproc, crashed);
>
> @@ -1857,7 +1861,7 @@ int rproc_shutdown(struct rproc *rproc)
> return ret;
> }
>
> - if (rproc->state != RPROC_RUNNING) {
> + if (rproc->state != RPROC_RUNNING && rproc->state !=
> RPROC_ATTACHED) {
> ret = -EPERM;
> goto out;
> }
> diff --git a/drivers/remoteproc/remoteproc_sysfs.c
> b/drivers/remoteproc/remoteproc_sysfs.c
> index c152d11a4d3c..6134d2f083ce 100644
> --- a/drivers/remoteproc/remoteproc_sysfs.c
> +++ b/drivers/remoteproc/remoteproc_sysfs.c
> @@ -113,10 +113,11 @@ static ssize_t state_store(struct device *dev,
> if (ret)
> dev_err(>dev, "Boot failed: %d\n", ret);
> } else if (sysfs_streq(buf, "stop")) {
> - if (rproc->state != RPROC_RUNNING)
> + if (rproc->state != RPROC_RUNNING &&
> + rproc->state != RPROC_ATTACHED)
> return -EINVAL;
>
> - rproc_shutdown(rproc);
> + ret = rproc_shutdown(rproc);
> } else {
> dev_err(>dev, "Unrecognised option: %s\n", buf);
> ret = -EINVAL;
> --
Reviewed-by: Peng Fan
RE: [PATCH 13/13] remoteproc: Properly deal with a kernel panic when attached
> Subject: [PATCH 13/13] remoteproc: Properly deal with a kernel panic when
> attached
>
> The panic handler operation of registered remote processors should also be
> called when remote processors have been attached to.
>
> Signed-off-by: Mathieu Poirier
> ---
> drivers/remoteproc/remoteproc_core.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/remoteproc/remoteproc_core.c
> b/drivers/remoteproc/remoteproc_core.c
> index 5586582f54c5..54b5e3437ab5 100644
> --- a/drivers/remoteproc/remoteproc_core.c
> +++ b/drivers/remoteproc/remoteproc_core.c
> @@ -2491,7 +2491,11 @@ static int rproc_panic_handler(struct
> notifier_block *nb, unsigned long event,
>
> rcu_read_lock();
> list_for_each_entry_rcu(rproc, _list, node) {
> - if (!rproc->ops->panic || rproc->state != RPROC_RUNNING)
> + if (!rproc->ops->panic)
> + continue;
> +
> + if (rproc->state != RPROC_RUNNING &&
> + rproc->state != RPROC_ATTACHED)
> continue;
>
> d = rproc->ops->panic(rproc);
> --
Reviewed-by: Peng Fan
Re: [PATCH v5 00/13] bus/fsl-mc: Extend mc-bus driver functionalities in preparation for mc-bus VFIO support
On Fri, 2 Oct 2020 16:05:49 +0200 Greg KH wrote: > On Fri, Oct 02, 2020 at 04:56:52PM +0300, Laurentiu Tudor wrote: > > Hi Greg, > > > > On 10/2/2020 4:55 PM, Greg KH wrote: > > > On Tue, Sep 29, 2020 at 02:06:41PM +0300, Laurentiu Tudor wrote: > > >> > > >> > > >> On 9/29/2020 11:54 AM, Diana Craciun wrote: > > >>> The vfio-mc bus driver needs some additional services to be exported by > > >>> the > > >>> mc-bus driver like: > > >>> - a way to reset the DPRC container > > >>> - driver_override support > > >>> - functions to setup/tear down a DPRC > > >>> - functions for allocating the pool of interrupts. In case of VFIO the > > >>> interrupts are not configured at probe time, but later by userspace > > >>> request > > >>> > > >>> v4 -> v5 > > >>> - dprc_celanup should not fail > > >>> > > >>> v3 -> v4 > > >>> - Rebased on the latest kernel. > > >>> - Exported a dprc_remove function > > >>> > > >>> v2 -> v3 > > >>> - Add a new version for dprc_get_obj_region > > >>> - Export the cacheability bus specific bits defines > > >>> > > >>> v1 -> v2 > > >>> - Remove driver_override propagation through various functions > > >>> - Cache the DPRC API version > > >>> > > >>> The patches are related with "vfio/fsl-mc: VFIO support for FSL-MC > > >>> devices" patches, but the series were split because they are targeting > > >>> different subsystems. However, the mc-bus patches may suffer changes > > >>> when addressing the VFIO review comments. > > >>> > > >>> The patches do not address the comment regarding moving driver_override > > >>> in the core code. I prefer not to tie these patches on that change and > > >>> address that separately. > > >>> > > >>> Bharat Bhushan (3): > > >>> bus/fsl-mc: add support for 'driver_override' in the mc-bus > > >>> bus/fsl-mc: Add dprc-reset-container support > > >>> bus/fsl-mc: Extend ICID size from 16bit to 32bit > > >>> > > >>> Diana Craciun (10): > > >>> bus/fsl-mc: Do no longer export the total number of irqs outside > > >>> dprc_scan_objects > > >>> bus/fsl-mc: Add a new parameter to dprc_scan_objects function > > >>> bus/fsl-mc: Set the QMAN/BMAN region flags > > >>> bus/fsl-mc: Cache the DPRC API version > > >>> bus/fsl-mc: Export dprc_scan/dprc_remove functions to be used by > > >>> multiple entities > > >>> bus/fsl-mc: Export a cleanup function for DPRC > > >>> bus/fsl-mc: Add a container setup function > > >>> bus/fsl_mc: Do not rely on caller to provide non NULL mc_io > > >>> bus/fsl-mc: Export IRQ pool handling functions to be used by VFIO > > >>> bus/fsl-mc: Add a new version for dprc_get_obj_region command > > >>> > > >>> drivers/bus/fsl-mc/dprc-driver.c | 190 -- > > >>> drivers/bus/fsl-mc/dprc.c | 141 +++ > > >>> drivers/bus/fsl-mc/fsl-mc-allocator.c | 12 +- > > >>> drivers/bus/fsl-mc/fsl-mc-bus.c | 64 - > > >>> drivers/bus/fsl-mc/fsl-mc-private.h | 31 ++--- > > >>> drivers/bus/fsl-mc/mc-io.c| 7 +- > > >>> include/linux/fsl/mc.h| 41 +- > > >>> 7 files changed, 359 insertions(+), 127 deletions(-) > > >>> > > >> > > >> For the series: > > >> Reviewed-by: Laurentiu Tudor > > >> Acked-by: Laurentiu Tudor > > > > > > Do you want me to take these patches in my tree, or are they going to > > > Linus some other way? > > > > I'm prefectly fine with you picking up the patches through your tree. > > Great, now queued up. Hi Greg, Diana has a vfio bus driver for fsl-mc devices queued up in my tree as well. After a linux-next build failure due to our branches being applied in the wrong order, Stephen advised that the proper way to handle this is to merge a shared branch with this series. Do you have a pull request imminent with this series or if not, would you mind pushing such a branch? Thanks, Alex
[PATCH v2] Add support for mv88e6393x family of Marvell.
The Marvell 88E6393X device is a single-chip integration of a 11-port
Ethernet switch with eight integrated Gigabit Ethernet (GbE) transceivers
and three 10-Gigabit interfaces.
This patch adds functionalities specific to mv88e6393x family (88E6393X,
88E6193X and 88E6191X)
Signed-off-by: Pavana Sharma
---
Changes in v2:
- Fix a warning (Reported-by: kernel test robot )
---
drivers/net/dsa/mv88e6xxx/chip.c| 90 +
drivers/net/dsa/mv88e6xxx/chip.h| 2 +
drivers/net/dsa/mv88e6xxx/global1.h | 2 +
drivers/net/dsa/mv88e6xxx/global2.c | 7 +
drivers/net/dsa/mv88e6xxx/global2.h | 8 +
drivers/net/dsa/mv88e6xxx/port.c| 302
drivers/net/dsa/mv88e6xxx/port.h| 39 +++-
drivers/net/dsa/mv88e6xxx/serdes.c | 239 ++
drivers/net/dsa/mv88e6xxx/serdes.h | 39
9 files changed, 727 insertions(+), 1 deletion(-)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index f0dbc05e30a4..241ff788b0b1 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -634,6 +634,23 @@ static void mv88e6390x_phylink_validate(struct
mv88e6xxx_chip *chip, int port,
mv88e6390_phylink_validate(chip, port, mask, state);
}
+static void mv88e6393x_phylink_validate(struct mv88e6xxx_chip *chip, int port,
+ unsigned long *mask,
+ struct phylink_link_state *state)
+{
+ if (port == 0 || port >= 9) {
+ phylink_set(mask, 1baseT_Full);
+ phylink_set(mask, 1baseKR_Full);
+ phylink_set(mask, 2500baseX_Full);
+ phylink_set(mask, 2500baseT_Full);
+ }
+
+ phylink_set(mask, 1000baseT_Full);
+ phylink_set(mask, 1000baseX_Full);
+
+ mv88e6065_phylink_validate(chip, port, mask, state);
+}
+
static void mv88e6xxx_validate(struct dsa_switch *ds, int port,
unsigned long *supported,
struct phylink_link_state *state)
@@ -4141,6 +4158,56 @@ static const struct mv88e6xxx_ops mv88e6191_ops = {
.phylink_validate = mv88e6390_phylink_validate,
};
+static const struct mv88e6xxx_ops mv88e6193x_ops = {
+ /* MV88E6XXX_FAMILY_6393X */
+ .setup_errata = mv88e6393x_setup_errata,
+ .irl_init_all = mv88e6390_g2_irl_init_all,
+ .get_eeprom = mv88e6xxx_g2_get_eeprom8,
+ .set_eeprom = mv88e6xxx_g2_set_eeprom8,
+ .set_switch_mac = mv88e6xxx_g2_set_switch_mac,
+ .phy_read = mv88e6xxx_g2_smi_phy_read,
+ .phy_write = mv88e6xxx_g2_smi_phy_write,
+ .port_set_link = mv88e6xxx_port_set_link,
+ .port_set_speed_duplex = mv88e6393x_port_set_speed_duplex,
+ .port_set_rgmii_delay = mv88e6390_port_set_rgmii_delay,
+ .port_tag_remap = mv88e6390_port_tag_remap,
+ .port_set_frame_mode = mv88e6351_port_set_frame_mode,
+ .port_set_egress_floods = mv88e6352_port_set_egress_floods,
+ .port_set_ether_type = mv88e6393x_port_set_ether_type,
+ .port_set_jumbo_size = mv88e6165_port_set_jumbo_size,
+ .port_egress_rate_limiting = mv88e6097_port_egress_rate_limiting,
+ .port_pause_limit = mv88e6390_port_pause_limit,
+ .port_set_cmode = mv88e6393x_port_set_cmode,
+ .port_disable_learn_limit = mv88e6xxx_port_disable_learn_limit,
+ .port_disable_pri_override = mv88e6xxx_port_disable_pri_override,
+ .port_get_cmode = mv88e6352_port_get_cmode,
+ .stats_snapshot = mv88e6390_g1_stats_snapshot,
+ .stats_set_histogram = mv88e6390_g1_stats_set_histogram,
+ .stats_get_sset_count = mv88e6320_stats_get_sset_count,
+ .stats_get_strings = mv88e6320_stats_get_strings,
+ .stats_get_stats = mv88e6390_stats_get_stats,
+ .set_cpu_port = mv88e6393x_port_set_cpu_dest,
+ .set_egress_port = mv88e6393x_set_egress_port,
+ .watchdog_ops = _watchdog_ops,
+ .mgmt_rsvd2cpu = mv88e6393x_port_mgmt_rsvd2cpu,
+ .pot_clear = mv88e6xxx_g2_pot_clear,
+ .reset = mv88e6352_g1_reset,
+ .rmu_disable = mv88e6390_g1_rmu_disable,
+ .vtu_getnext = mv88e6390_g1_vtu_getnext,
+ .vtu_loadpurge = mv88e6390_g1_vtu_loadpurge,
+ .serdes_power = mv88e6393x_serdes_power,
+ .serdes_get_lane = mv88e6393x_serdes_get_lane,
+ /* Check status register pause & lpa register */
+ .serdes_pcs_get_state = mv88e6390_serdes_pcs_get_state,
+ .serdes_irq_mapping = mv88e6390_serdes_irq_mapping,
+ .serdes_irq_enable = mv88e6393x_serdes_irq_enable,
+ .serdes_irq_status = mv88e6393x_serdes_irq_status,
+ .gpio_ops = _gpio_ops,
+ .avb_ops = _avb_ops,
+ .ptp_ops = _ptp_ops,
+ .phylink_validate = mv88e6393x_phylink_validate,
+};
+
static const struct mv88e6xxx_ops mv88e6240_ops = {
/* MV88E6XXX_FAMILY_6352 */
.ieee_pri_map = mv88e6085_g1_ieee_pri_map,
@@ -5073,6 +5140,29 @@ static const struct
