[PATCH] mm/kprobes: Add generic kprobe_fault_handler() fallback definition
Architectures like parisc enable CONFIG_KROBES without having a definition
for kprobe_fault_handler() which results in a build failure. Arch needs to
provide kprobe_fault_handler() as it is platform specific and cannot have
a generic working alternative. But in the event when platform lacks such a
definition there needs to be a fallback.
This adds a stub kprobe_fault_handler() definition which not only prevents
a build failure but also makes sure that kprobe_page_fault() if called will
always return negative in absence of a sane platform specific alternative.
While here wrap kprobe_page_fault() in CONFIG_KPROBES. This enables stud
definitions for generic kporbe_fault_handler() and kprobes_built_in() can
just be dropped. Only on x86 it needs to be added back locally as it gets
used in a !CONFIG_KPROBES function do_general_protection().
Cc: Vineet Gupta
Cc: Russell King
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Tony Luck
Cc: Fenghua Yu
Cc: Ralf Baechle
Cc: Paul Burton
Cc: James Hogan
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
Cc: Heiko Carstens
Cc: Vasily Gorbik
Cc: Christian Borntraeger
Cc: Yoshinori Sato
Cc: Rich Felker
Cc: "David S. Miller"
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: "H. Peter Anvin"
Cc: "Naveen N. Rao"
Cc: Anil S Keshavamurthy
Cc: Masami Hiramatsu
Cc: Allison Randal
Cc: Greg Kroah-Hartman
Cc: Enrico Weigelt
Cc: Richard Fontana
Cc: Kate Stewart
Cc: Mark Rutland
Cc: Andrew Morton
Cc: Guenter Roeck
Cc: x...@kernel.org
Cc: linux-snps-...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-i...@vger.kernel.org
Cc: linux-m...@vger.kernel.org
Cc: linuxppc-...@lists.ozlabs.org
Cc: linux-s...@vger.kernel.org
Cc: linux...@vger.kernel.org
Cc: sparcli...@vger.kernel.org
Signed-off-by: Anshuman Khandual
---
arch/arc/include/asm/kprobes.h | 1 +
arch/arm/include/asm/kprobes.h | 1 +
arch/arm64/include/asm/kprobes.h | 1 +
arch/ia64/include/asm/kprobes.h| 1 +
arch/mips/include/asm/kprobes.h| 1 +
arch/powerpc/include/asm/kprobes.h | 1 +
arch/s390/include/asm/kprobes.h| 1 +
arch/sh/include/asm/kprobes.h | 1 +
arch/sparc/include/asm/kprobes.h | 1 +
arch/x86/include/asm/kprobes.h | 6 ++
include/linux/kprobes.h| 32 ++
11 files changed, 34 insertions(+), 13 deletions(-)
diff --git a/arch/arc/include/asm/kprobes.h b/arch/arc/include/asm/kprobes.h
index 2134721dce44..ee8efe256675 100644
--- a/arch/arc/include/asm/kprobes.h
+++ b/arch/arc/include/asm/kprobes.h
@@ -45,6 +45,7 @@ struct kprobe_ctlblk {
struct prev_kprobe prev_kprobe;
};
+#define kprobe_fault_handler kprobe_fault_handler
int kprobe_fault_handler(struct pt_regs *regs, unsigned long cause);
void kretprobe_trampoline(void);
void trap_is_kprobe(unsigned long address, struct pt_regs *regs);
diff --git a/arch/arm/include/asm/kprobes.h b/arch/arm/include/asm/kprobes.h
index 213607a1f45c..660f877b989f 100644
--- a/arch/arm/include/asm/kprobes.h
+++ b/arch/arm/include/asm/kprobes.h
@@ -38,6 +38,7 @@ struct kprobe_ctlblk {
struct prev_kprobe prev_kprobe;
};
+#define kprobe_fault_handler kprobe_fault_handler
void arch_remove_kprobe(struct kprobe *);
int kprobe_fault_handler(struct pt_regs *regs, unsigned int fsr);
int kprobe_exceptions_notify(struct notifier_block *self,
diff --git a/arch/arm64/include/asm/kprobes.h b/arch/arm64/include/asm/kprobes.h
index 97e511d645a2..667773f75616 100644
--- a/arch/arm64/include/asm/kprobes.h
+++ b/arch/arm64/include/asm/kprobes.h
@@ -42,6 +42,7 @@ struct kprobe_ctlblk {
struct kprobe_step_ctx ss_ctx;
};
+#define kprobe_fault_handler kprobe_fault_handler
void arch_remove_kprobe(struct kprobe *);
int kprobe_fault_handler(struct pt_regs *regs, unsigned int fsr);
int kprobe_exceptions_notify(struct notifier_block *self,
diff --git a/arch/ia64/include/asm/kprobes.h b/arch/ia64/include/asm/kprobes.h
index c5cf5e4fb338..c321e8585089 100644
--- a/arch/ia64/include/asm/kprobes.h
+++ b/arch/ia64/include/asm/kprobes.h
@@ -106,6 +106,7 @@ struct arch_specific_insn {
unsigned short slot;
};
+#define kprobe_fault_handler kprobe_fault_handler
extern int kprobe_fault_handler(struct pt_regs *regs, int trapnr);
extern int kprobe_exceptions_notify(struct notifier_block *self,
unsigned long val, void *data);
diff --git a/arch/mips/include/asm/kprobes.h b/arch/mips/include/asm/kprobes.h
index 68b1e5d458cf..d1efe991ea22 100644
--- a/arch/mips/include/asm/kprobes.h
+++ b/arch/mips/include/asm/kprobes.h
@@ -40,6 +40,7 @@ do {
\
#define kretprobe_blacklist_size 0
+#define kprobe_fault_handler kprobe_fault_handler
void arch_remove_kprobe(struct kprobe *p);
int kprobe_fault_handler(struct pt_regs *regs, int trapnr);
diff --git a/arch/powerpc/include/asm/kprobes.h
Re: [Linux-kernel-mentees] [Linux-kernel-mentee, PATCH] media: dvb_frontend.h: Fix shifting signed 32-bit value problem
On Thu, Jul 04, 2019 at 10:04:22AM -0700, Luke Nowakowski-Krijger wrote:
> Fix DVBFE_ALGO_RECOVERY and DVBFE_ALGO_SEARCH_ERROR to use U cast which
> fixes undefined behavior error by certain compilers.
>
> Signed-off-by: Luke Nowakowski-Krijger
> ---
> include/media/dvb_frontend.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/include/media/dvb_frontend.h b/include/media/dvb_frontend.h
> index f05cd7b94a2c..472fe5871d94 100644
> --- a/include/media/dvb_frontend.h
> +++ b/include/media/dvb_frontend.h
> @@ -144,7 +144,7 @@ enum dvbfe_algo {
> DVBFE_ALGO_HW = (1 << 0),
> DVBFE_ALGO_SW = (1 << 1),
> DVBFE_ALGO_CUSTOM = (1 << 2),
> - DVBFE_ALGO_RECOVERY = (1 << 31)
> + DVBFE_ALGO_RECOVERY = (1U << 31)
BIT() is better for stuff like this.
thanks,
greg k-h
Re: [PATCH 1/2] usb: pci-quirks: Correct AMD PLL quirk detection
On Thu, Jul 04, 2019 at 11:35:28AM -0400, Ryan Kennedy wrote: > The AMD PLL USB quirk is incorrectly enabled on newer Ryzen > chipsets. The logic in usb_amd_find_chipset_info currently checks > for unaffected chipsets rather than affected ones. This broke > once a new chipset was added in e788787ef. It makes more sense > to reverse the logic so it won't need to be updated as new > chipsets are added. Note that the core of the workaround in > usb_amd_quirk_pll does correctly check the chipset. > > Signed-off-by: Ryan Kennedy > --- > drivers/usb/host/pci-quirks.c | 31 +++ > 1 file changed, 19 insertions(+), 12 deletions(-) Should this be backported to stable kernels? thanks, greg k-h
Klientskie bazy. Email: proda...@armyspy.com Uznajte podrobnee!
Klientskie bazy. Email: proda...@armyspy.com Uznajte podrobnee!
Re: [bisected] "mm/vmalloc: Add flag for freeing of special permsissions" corrupts memory on ia64
On Thu, 2019-07-04 at 12:53 +0300, Meelis Roos wrote: > I noticed that while 5.1 works on my HP Integrity RX2620, 5.2-rc6 > crashed on boot nondeterministically. > Bisecting it took many tries sice it does not happen on each boot and > when it happes, the symptoms are > different each time. But now the bisection converged to Thanks for the report. This arch seems similar to sparc in that there are no set_memory_() implementations, except that it's even simpler because flush_tlb_kernel_range() just calls flush_tlb_all() so the range shouldn't matter either. So this commit *should* have just been adding a TLB flush, with most of it not affecting ia64. From these logs, especially the fault stack traces and BUG()'s, it seems like the vmalloc memory might be the allocations being corrupted. After scrutinizing this so much for sparc, only to have the cause be sparc's TLB flush in the end, I wonder if something similar could be happening here. If the TLB wasn't getting flushed on all cores or in the vmalloc range or something like that, the module loader may be reading and writing to old entries pointing to re-cycled pages and cause strange behavior like this. I am out of the office and don't have access to this hardware either. I will try to find someone at Intel that does to speed this up. In the meantime I can send you a logging patch to do some sanity checks if you are able to run it. I think I found your earlier mail, and it said 5.2-rc1 did not show the problem. I guess this wasn't the case after further testing, but 5.1 continued to be problem free? Thanks, Rick
[PATCH 1/6] thermal: qoriq: Use devm_platform_ioremap_resource() instead of of_iomap()
From: Anson Huang
Use devm_platform_ioremap_resource() instead of of_iomap() to
save the iounmap() call in error handle path;
Signed-off-by: Anson Huang
---
drivers/thermal/qoriq_thermal.c | 18 ++
1 file changed, 6 insertions(+), 12 deletions(-)
diff --git a/drivers/thermal/qoriq_thermal.c b/drivers/thermal/qoriq_thermal.c
index 7b36493..c7c7de2 100644
--- a/drivers/thermal/qoriq_thermal.c
+++ b/drivers/thermal/qoriq_thermal.c
@@ -202,32 +202,27 @@ static int qoriq_tmu_probe(struct platform_device *pdev)
data->little_endian = of_property_read_bool(np, "little-endian");
- data->regs = of_iomap(np, 0);
- if (!data->regs) {
+ data->regs = devm_platform_ioremap_resource(pdev, 0);
+ if (IS_ERR(data->regs)) {
dev_err(>dev, "Failed to get memory region\n");
- ret = -ENODEV;
- goto err_iomap;
+ return PTR_ERR(data->regs);
}
qoriq_tmu_init_device(data);/* TMU initialization */
ret = qoriq_tmu_calibration(pdev); /* TMU calibration */
if (ret < 0)
- goto err_tmu;
+ goto err;
ret = qoriq_tmu_register_tmu_zone(pdev);
if (ret < 0) {
dev_err(>dev, "Failed to register sensors\n");
- ret = -ENODEV;
- goto err_iomap;
+ goto err;
}
return 0;
-err_tmu:
- iounmap(data->regs);
-
-err_iomap:
+err:
platform_set_drvdata(pdev, NULL);
return ret;
@@ -240,7 +235,6 @@ static int qoriq_tmu_remove(struct platform_device *pdev)
/* Disable monitoring */
tmu_write(data, TMR_DISABLE, >regs->tmr);
- iounmap(data->regs);
platform_set_drvdata(pdev, NULL);
return 0;
--
2.7.4
[PATCH 2/6] thermal: qoriq: Use __maybe_unused instead of #if CONFIG_PM_SLEEP
From: Anson Huang
Use __maybe_unused for power management related functions
instead of #if CONFIG_PM_SLEEP to simply the code.
Signed-off-by: Anson Huang
---
drivers/thermal/qoriq_thermal.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/thermal/qoriq_thermal.c b/drivers/thermal/qoriq_thermal.c
index c7c7de2..2b2f79b 100644
--- a/drivers/thermal/qoriq_thermal.c
+++ b/drivers/thermal/qoriq_thermal.c
@@ -240,8 +240,7 @@ static int qoriq_tmu_remove(struct platform_device *pdev)
return 0;
}
-#ifdef CONFIG_PM_SLEEP
-static int qoriq_tmu_suspend(struct device *dev)
+static int __maybe_unused qoriq_tmu_suspend(struct device *dev)
{
u32 tmr;
struct qoriq_tmu_data *data = dev_get_drvdata(dev);
@@ -254,7 +253,7 @@ static int qoriq_tmu_suspend(struct device *dev)
return 0;
}
-static int qoriq_tmu_resume(struct device *dev)
+static int __maybe_unused qoriq_tmu_resume(struct device *dev)
{
u32 tmr;
struct qoriq_tmu_data *data = dev_get_drvdata(dev);
@@ -266,7 +265,6 @@ static int qoriq_tmu_resume(struct device *dev)
return 0;
}
-#endif
static SIMPLE_DEV_PM_OPS(qoriq_tmu_pm_ops,
qoriq_tmu_suspend, qoriq_tmu_resume);
--
2.7.4
[PATCH 6/6] arm64: dts: imx8mq: Add clock for TMU node
From: Anson Huang i.MX8MQ has clock gate for TMU module, add clock info to TMU node for clock management. Signed-off-by: Anson Huang --- arch/arm64/boot/dts/freescale/imx8mq.dtsi | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/boot/dts/freescale/imx8mq.dtsi b/arch/arm64/boot/dts/freescale/imx8mq.dtsi index c61e968..edfc1aa 100644 --- a/arch/arm64/boot/dts/freescale/imx8mq.dtsi +++ b/arch/arm64/boot/dts/freescale/imx8mq.dtsi @@ -348,6 +348,7 @@ compatible = "fsl,imx8mq-tmu"; reg = <0x3026 0x1>; interrupt = ; + clocks = < IMX8MQ_CLK_TMU_ROOT>; little-endian; fsl,tmu-range = <0xb 0xa0026 0x80048 0x70061>; fsl,tmu-calibration = <0x 0x0023 -- 2.7.4
[PATCH 5/6] clk: imx8mq: Remove CLK_IS_CRITICAL flag for IMX8MQ_CLK_TMU_ROOT
From: Anson Huang
IMX8MQ_CLK_TMU_ROOT is ONLY used for thermal module, the driver
should manage this clock, so no need to have CLK_IS_CRITICAL flag
set.
Signed-off-by: Anson Huang
---
drivers/clk/imx/clk-imx8mq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/imx/clk-imx8mq.c b/drivers/clk/imx/clk-imx8mq.c
index d407a07..91de69a 100644
--- a/drivers/clk/imx/clk-imx8mq.c
+++ b/drivers/clk/imx/clk-imx8mq.c
@@ -539,7 +539,7 @@ static int imx8mq_clocks_probe(struct platform_device *pdev)
clks[IMX8MQ_CLK_DISP_AXI_ROOT] =
imx_clk_gate2_shared2("disp_axi_root_clk", "disp_axi", base + 0x45d0, 0,
_count_dcss);
clks[IMX8MQ_CLK_DISP_APB_ROOT] =
imx_clk_gate2_shared2("disp_apb_root_clk", "disp_apb", base + 0x45d0, 0,
_count_dcss);
clks[IMX8MQ_CLK_DISP_RTRM_ROOT] =
imx_clk_gate2_shared2("disp_rtrm_root_clk", "disp_rtrm", base + 0x45d0, 0,
_count_dcss);
- clks[IMX8MQ_CLK_TMU_ROOT] = imx_clk_gate4_flags("tmu_root_clk",
"ipg_root", base + 0x4620, 0, CLK_IS_CRITICAL);
+ clks[IMX8MQ_CLK_TMU_ROOT] = imx_clk_gate4("tmu_root_clk", "ipg_root",
base + 0x4620, 0);
clks[IMX8MQ_CLK_VPU_DEC_ROOT] = imx_clk_gate2_flags("vpu_dec_root_clk",
"vpu_bus", base + 0x4630, 0, CLK_SET_RATE_PARENT | CLK_OPS_PARENT_ENABLE);
clks[IMX8MQ_CLK_CSI1_ROOT] = imx_clk_gate4("csi1_root_clk",
"csi1_core", base + 0x4650, 0);
clks[IMX8MQ_CLK_CSI2_ROOT] = imx_clk_gate4("csi2_root_clk",
"csi2_core", base + 0x4660, 0);
--
2.7.4
[PATCH 4/6] thermal: qoriq: Add clock operations
From: Anson Huang
Some platforms like i.MX8MQ has clock control for this module,
need to add clock operations to make sure the driver is working
properly.
Signed-off-by: Anson Huang
---
drivers/thermal/qoriq_thermal.c | 24
1 file changed, 24 insertions(+)
diff --git a/drivers/thermal/qoriq_thermal.c b/drivers/thermal/qoriq_thermal.c
index 2b2f79b..0813c1b 100644
--- a/drivers/thermal/qoriq_thermal.c
+++ b/drivers/thermal/qoriq_thermal.c
@@ -2,6 +2,7 @@
//
// Copyright 2016 Freescale Semiconductor, Inc.
+#include
#include
#include
#include
@@ -72,6 +73,7 @@ struct qoriq_sensor {
struct qoriq_tmu_data {
struct qoriq_tmu_regs __iomem *regs;
+ struct clk *clk;
bool little_endian;
struct qoriq_sensor *sensor[SITES_MAX];
};
@@ -208,6 +210,19 @@ static int qoriq_tmu_probe(struct platform_device *pdev)
return PTR_ERR(data->regs);
}
+ data->clk = devm_clk_get(>dev, NULL);
+ if (IS_ERR(data->clk)) {
+ if (PTR_ERR(data->clk) == -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+ data->clk = NULL;
+ }
+
+ ret = clk_prepare_enable(data->clk);
+ if (ret) {
+ dev_err(>dev, "Failed to enable clock\n");
+ return ret;
+ }
+
qoriq_tmu_init_device(data);/* TMU initialization */
ret = qoriq_tmu_calibration(pdev); /* TMU calibration */
@@ -235,6 +250,8 @@ static int qoriq_tmu_remove(struct platform_device *pdev)
/* Disable monitoring */
tmu_write(data, TMR_DISABLE, >regs->tmr);
+ clk_disable_unprepare(data->clk);
+
platform_set_drvdata(pdev, NULL);
return 0;
@@ -250,14 +267,21 @@ static int __maybe_unused qoriq_tmu_suspend(struct device
*dev)
tmr &= ~TMR_ME;
tmu_write(data, tmr, >regs->tmr);
+ clk_disable_unprepare(data->clk);
+
return 0;
}
static int __maybe_unused qoriq_tmu_resume(struct device *dev)
{
u32 tmr;
+ int ret;
struct qoriq_tmu_data *data = dev_get_drvdata(dev);
+ ret = clk_prepare_enable(data->clk);
+ if (ret)
+ return ret;
+
/* Enable monitoring */
tmr = tmu_read(data, >regs->tmr);
tmr |= TMR_ME;
--
2.7.4
[PATCH 3/6] dt-bindings: thermal: qoriq: Add optional clocks property
From: Anson Huang Some platforms have clock control for TMU, add optional clocks property to the binding doc. Signed-off-by: Anson Huang --- Documentation/devicetree/bindings/thermal/qoriq-thermal.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/thermal/qoriq-thermal.txt b/Documentation/devicetree/bindings/thermal/qoriq-thermal.txt index 04cbb90..28f2cba 100644 --- a/Documentation/devicetree/bindings/thermal/qoriq-thermal.txt +++ b/Documentation/devicetree/bindings/thermal/qoriq-thermal.txt @@ -23,6 +23,7 @@ Required properties: Optional property: - little-endian : If present, the TMU registers are little endian. If absent, the default is big endian. +- clocks : the clock for clocking the TMU silicon. Example: -- 2.7.4
[PATCH] mfd: intel-lpss: Remove D3cold delay
Goodix touchpad may drop its first couple input events when i2c-designware-platdrv and intel-lpss it connects to took too long to runtime resume from runtime suspended state. This issue happens becuase the touchpad has a rather small buffer to store up to 13 input events, so if the host doesn't read those events in time (i.e. runtime resume takes too long), events are dropped from the touchpad's buffer. The bottleneck is D3cold delay it waits when transitioning from D3cold to D0, hence remove the delay to make the resume faster. I've tested some systems with intel-lpss and haven't seen any regression. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=202683 Signed-off-by: Kai-Heng Feng --- drivers/mfd/intel-lpss-pci.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/mfd/intel-lpss-pci.c b/drivers/mfd/intel-lpss-pci.c index aed2c0447966..3c271b14e7c6 100644 --- a/drivers/mfd/intel-lpss-pci.c +++ b/drivers/mfd/intel-lpss-pci.c @@ -35,6 +35,8 @@ static int intel_lpss_pci_probe(struct pci_dev *pdev, info->mem = >resource[0]; info->irq = pdev->irq; + pdev->d3cold_delay = 0; + /* Probably it is enough to set this for iDMA capable devices only */ pci_set_master(pdev); pci_try_set_mwi(pdev); -- 2.17.1
Re: [PATCH v1 net-next] net: stmmac: enable clause 45 mdio support
> If the community prefers readability Readability nearly always comes first. There is nothing performance critical here, MDIO is a slow bus. So the code should be readable, simple to understand. , I will suggest to do the c45 setup in > both stmmac_mdio_read() and stmmac_mdio_write() 's if(C45) condition rather > than splitting into 2 new c45_read() and c45_write() functions. Fine. Andrew
Re: [PATCH net-next 4/6] arm64: dts: fsl: ls1028a: Add Felix switch port DT node
Hi Vladimir > - DSA is typically used for discrete switches, switchdev is typically > used for embedded ones. Typically DSA is for discrete switches, but not exclusively. The b53/SF2 is embedded in a number of Broadcom SoCs. So this is no different to Ocelot, except ARM vs MIPS. Also, i would disagree that switchdev is used for embedded ones. Mellonex devices are discrete, on a PCIe bus. I believe Netronome devices are also discrete PCIe devices. In fact, i think ocelot is the only embedded switchdev switch. So embedded vs discrete plays no role here at all. > - The D in DSA is for cascaded switches. Apart from the absence of > such a "Ocelot SoC" driver (which maybe can be written, I don't know), > I think the switching core itself has some fundamental limitations > that make a DSA implementation questionable: There is no requirement to implement D in DSA. In fact, only Marvell does. None of the other switches do. And you will also find that most boards with a Marvell switch use a single device. D in DSA is totally optional. In fact, DSA is built from the ground up that nearly everything is optional. Take a look at mv88e6060, as an example. It implements nearly nothing. It cannot even offload a bridge to the switch. > So my conclusion is that DSA for Felix/Ocelot doesn't make a lot of > sense if the whole purpose is to hide the CPU-facing netdev. You actually convinced me the exact opposite. You described the headers which are needed to implement DSA. The switch sounds like it can do what DSA requires. So DSA is the correct model. Andrew
RE: linux-next: build failure after merge of the usb and usb-gadget trees
Hi,
>
>Hi,
>
>Greg KH writes:
>
>> On Thu, Jul 04, 2019 at 12:44:08PM +0300, Felipe Balbi wrote:
>>>
>>> Hi,
>>>
>>> Pawel Laszczak writes:
>>>
>>> >>
>>> >>
>>> >>Hi,
>>> >>
>>> >>Pawel Laszczak writes:
>>> >>
>>>
>>> Hi,
>>>
>>> On Thu, Jul 4, 2019 at 9:59 AM Greg KH wrote:
>>> >
>>> > On Thu, Jul 04, 2019 at 04:34:58PM +1000, Stephen Rothwell wrote:
>>> > > Hi all,
>>> > >
>>> > > After merging the usb tree, today's linux-next build (arm
>>> > > multi_v7_defconfig) failed like this:
>>> > >
>>> > > arm-linux-gnueabi-ld: drivers/usb/dwc3/trace.o: in function
>>> > > `trace_raw_output_dwc3_log_ctrl':
>>> > > trace.c:(.text+0x119c): undefined reference to `usb_decode_ctrl'
>>> > >
>>> > > Caused by commit
>>> > >
>>> > > 3db1b636c07e ("usb:gadget Separated decoding functions from dwc3
>>> > > driver.")
>>> > >
>>> > > I have used the usb tree from next-20190703 for today.
>>> > >
>>> > > This also occurs in the usb-gadget tree so I have used the version
>>> > > of
>>> > > that from next-20190703 as well.
>>> >
>>> > Odd, I thought I pulled the usb-gadget tree into mine. Felipe, can
>>> > you
>>> > take a look at this to see if I messed something up?
>>>
>>> This looks like it was caused by Pawel's patches.
>>>
>>> I'll try to reproduce here and see what's causing it.
>>> >>>
>>> >>> Problem is in my Patch. I reproduced it, but I don't understand why
>>> >>> compiler
>>> >>> complains about usb_decode_ctrl. It's compiled into libcomposite.ko and
>>> >>> declaration is in drivers/usb/gadget.h.
>>> >>
>>> >>That's because in multi_v7_defconfig dwc3 is built-in while libcomposite
>>> >>is a module:
>>> >>
>>> >>CONFIG_USB_DWC3=y
>>> >>CONFIG_USB_LIBCOMPOSITE=m
>>> >>
>>> >>
>>> >>I remember that when you were doing this work, I asked you to move
>>> >>functions to usb/common. Why did you deviate from that suggestion? It's
>>> >>clear that decoding a ctrl request can be used by peripheral and host
>>> >>and we wouldn't have to deal with this problem if you had just followed
>>> >>the suggestion.
>>> >
>>> > Some time ago Greg wrote:
>>> > " It's nice to have these in a common place, but you just bloated all of
>>> > the USB-enabled systems in the world for the use of 2 odd-ball system
>>> > controllers that almost no one has :) "
>>> >
>>> > So I moved these functions to gadget directory.
>>> >
>>> > It was mistake that I added debug.c file to libcomposite.ko.
>>>
>>> The plan is to use this decoding function for xHCI as well. Other host
>>> controllers can use it as well.
>>>
>>> The biggest mistake was to put this under gadget. What you should have
>>> done was create a file under usb/common that only gets compile in if
>>> tracing is enabled.
>>>
>>> Then there's no bloating unless you have a kernel purposefuly built for
>>> debugging and tracing.
>>>
>>> Greg, does that work for you?
>>
>> I guess, but I'd like to see patches before answering that :)
>
>Sure, understandable. I should've done a better job at filtering that
>out. Sorry about htat
I will return debug.c again to usb/common directory.
I made it as suggested by Felipe.
I will try correct this patches on Monday.
I apologize for my mistake and for wasting your time.
Regards,
Pawel.
[PATCH v2] sched: fix unlikely use of sched_info_on()
sched_info_on() is called with unlikely hint, however, the test
is to be a constant(1) on which compiler will do nothing when
make defconfig, so remove the hint.
Also, fix a lack of {}.
Signed-off-by: Yi Wang
---
v2: remove the hint rather than replace with likely, and fix a
coding style.
kernel/sched/stats.h | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/kernel/sched/stats.h b/kernel/sched/stats.h
index aa0de24..ba683fe 100644
--- a/kernel/sched/stats.h
+++ b/kernel/sched/stats.h
@@ -157,9 +157,10 @@ static inline void sched_info_dequeued(struct rq *rq,
struct task_struct *t)
{
unsigned long long now = rq_clock(rq), delta = 0;
- if (unlikely(sched_info_on()))
+ if (sched_info_on()) {
if (t->sched_info.last_queued)
delta = now - t->sched_info.last_queued;
+ }
sched_info_reset_dequeued(t);
t->sched_info.run_delay += delta;
@@ -192,7 +193,7 @@ static void sched_info_arrive(struct rq *rq, struct
task_struct *t)
*/
static inline void sched_info_queued(struct rq *rq, struct task_struct *t)
{
- if (unlikely(sched_info_on())) {
+ if (sched_info_on()) {
if (!t->sched_info.last_queued)
t->sched_info.last_queued = rq_clock(rq);
}
@@ -239,7 +240,7 @@ static inline void sched_info_depart(struct rq *rq, struct
task_struct *t)
static inline void
sched_info_switch(struct rq *rq, struct task_struct *prev, struct task_struct
*next)
{
- if (unlikely(sched_info_on()))
+ if (sched_info_on())
__sched_info_switch(rq, prev, next);
}
--
1.8.3.1
Re: [PATCH v2] rtl8xxxu: Fix wifi low signal strength issue of RTL8723BU
On Fri, Jul 5, 2019 at 11:41 AM Daniel Drake wrote: > > On Thu, Jul 4, 2019 at 6:55 PM Chris Chiu wrote: > > The WiFi tx power of RTL8723BU is extremely low after booting. So > > the WiFi scan gives very limited AP list and it always fails to > > connect to the selected AP. This module only supports 1x1 antenna > > and the antenna is switched to bluetooth due to some incorrect > > register settings. > > > > Compare with the vendor driver https://github.com/lwfinger/rtl8723bu, > > we realized that the 8723bu's enable_rf() does the same thing as > > rtw_btcoex_HAL_Initialize() in vendor driver. And it by default > > sets the antenna path to BTC_ANT_PATH_BT which we verified it's > > the cause of the wifi weak tx power. The vendor driver will set > > the antenna path to BTC_ANT_PATH_PTA in the consequent btcoexist > > mechanism, by the function halbtc8723b1ant_PsTdma. > > Checking these details in the vendor driver: > EXhalbtc8723b1ant_PowerOnSetting sets: > pBoardInfo->btdmAntPos = BTC_ANTENNA_AT_AUX_PORT; > > Following the code flow from rtw_btcoex_HAL_Initialize(), this has a > bWifiOnly parameter which will ultimately influence the final register > value. > Continuing the flow, we reach halbtc8723b1ant_SetAntPath() with > bInitHwCfg=TRUE, bWifiOff=FALSE. antPosType is set to WIFI in the > bWifiOnly case, and BT otherwise. > > I'm assuming that bUseExtSwitch = FALSE (existing rtl8xxxu code also > seems to make the same assumption). > For the bWifiOnly=FALSE case, it uses BT, > pBtCoexist->fBtcWrite4Byte(pBtCoexist, 0x948, 0x0); > and rtl8xxxu seems to do the same - seemingly routing the antenna path > for BT only. > > As for halbtc8723b1ant_PsTdma() then being called in a way that causes > it to switch to the PTA path a little later, it's more difficult to > point out how that happens in an email, but I thin kwe can trust you > on that :) There are certainly many callsites that would pass those > parameters. > > > +* Different settings per different antenna position. > > +* Antenna Position: | Normal Inverse > > +* -- > > +* Antenna switch to BT:| 0x280, 0x00 > > +* Antenna switch to WiFi: | 0x0, 0x280 > > +* Antenna switch to PTA: | 0x200, 0x80 > > */ > > - rtl8xxxu_write32(priv, REG_S0S1_PATH_SWITCH, 0x00); > > + rtl8xxxu_write32(priv, REG_S0S1_PATH_SWITCH, 0x80); > > I don't really understand what we mean by an "inverse" antenna and my > reading of the vendor driver leads me to another interpretation. > > The logic is based around an antenna position - btdmAntPos. It takes > one of two values: > BTC_ANTENNA_AT_MAIN_PORT= 0x1, > BTC_ANTENNA_AT_AUX_PORT= 0x2, > > So the chip has pins to support two antennas - a "main" antenna and an > "aux" one. > > We know we're dealing with a single antenna, so the actual module is > going to only be using one of those antenna interfaces. If the chip > tries to use the other antenna interface, it's effectively not using > the antenna. So it's rather important to tell the chip to use the > right interface. > > And that's exactly what happens here. btdmAntPos is hardcoded that the > antenna is on the aux port for these devices, and this code is telling > the chip that this is how things are wired up. > > The alternative way of calling this an antenna inverse (which the > vendor driver also does in another section), i.e. "antenna is not > connected to the main port but instead it's connected to the other > one", seems less clear to me. > I agree with this part. From my past experience working on drivers for WiFi access point, there's always a board config to describe how the antenna wired up. The driver or firmware will select antennas from something like txchainmask/rxchainmask to perform some smart antenna and MIMO features. So The antenna position setting is quite important for each wifi(MIMO) product because it could have impact on the coverage and throughput. Back to the 1x1 rtl8723bu here, I think it's the same thing. The antenna position is fixed in the factory and wired to the AUX port. Maybe we can just take this antenna settings as the default for 8723bu based on the assumption that there will be no other antenna configuration. Chris > Even if we don't fully understand what's going on here, I'm convinced > that your code change is fixing an inconsistency with the vendor > driver, and most significantly, making the signal level actually > usable on our devices. But if you agree with my interpretation of > these values then maybe you could update the comment here! > > Daniel
[PATCH 2/2] x86/numa: instance all parsed numa node
I hit a bug on an AMD machine, with kexec -l nr_cpus=4 option. nr_cpus option
is used to speed up kdump process, so it is not a rare case.
It turns out that some pgdat is not instanced when specifying nr_cpus, e.g, on
x86, not initialized by init_cpu_to_node()->init_memory_less_node(). But
device->numa_node info is used as preferred_nid param for
__alloc_pages_nodemask(), which causes NULL reference ac->zonelist =
node_zonelist(preferred_nid, gfp_mask);
Although this bug is detected on x86, it should affect all archs, where a
machine with a numa-node having no memory, if nr_cpus prevents the instance of
the node, and the device on the node tries to allocate memory with
device->numa_node info.
The patch takes the way by instancing all parsed numa node on x86. (for more
detail, please refer to section I and II)
I. Notes about the crashing info:
-1 kexec -l with nr_cpus=4
-2 system info
NUMA node0 CPU(s): 0,8,16,24
NUMA node1 CPU(s): 2,10,18,26
NUMA node2 CPU(s): 4,12,20,28
NUMA node3 CPU(s): 6,14,22,30
NUMA node4 CPU(s): 1,9,17,25
NUMA node5 CPU(s): 3,11,19,27
NUMA node6 CPU(s): 5,13,21,29
NUMA node7 CPU(s): 7,15,23,31
-3 panic stack
[...]
[5.721547] atomic64_test: passed for x86-64 platform with CX8 and with SSE
[5.729187] pcieport :00:01.1: Signaling PME with IRQ 34
[5.735187] pcieport :00:01.2: Signaling PME with IRQ 35
[5.741168] pcieport :00:01.3: Signaling PME with IRQ 36
[5.747189] pcieport :00:07.1: Signaling PME with IRQ 37
[5.754061] pcieport :00:08.1: Signaling PME with IRQ 39
[5.760727] pcieport :20:07.1: Signaling PME with IRQ 40
[5.766955] pcieport :20:08.1: Signaling PME with IRQ 42
[5.772742] BUG: unable to handle kernel paging request at 2088
[5.773618] PGD 0 P4D 0
[5.773618] Oops: [#1] SMP NOPTI
[5.773618] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.20.0-rc1+ #3
[5.773618] Hardware name: Dell Inc. PowerEdge R7425/02MJ3T, BIOS 1.4.3
06/29/2018
[5.773618] RIP: 0010:__alloc_pages_nodemask+0xe2/0x2a0
[5.773618] Code: 00 00 44 89 ea 80 ca 80 41 83 f8 01 44 0f 44 ea 89 da c1
ea 08 83 e2 01 88 54 24 20 48 8b 54 24 08 48 85 d2 0f 85 46 01 00 00 <3b> 77 08
0f 82 3d 01 00 00 48 89 f8 44 89 ea 48 89
e1 44 89 e6 89
[5.773618] RSP: 0018:aa65fb20 EFLAGS: 00010246
[5.773618] RAX: RBX: 006012c0 RCX:
[5.773618] RDX: RSI: 0002 RDI: 2080
[5.773618] RBP: 006012c0 R08: R09: 0002
[5.773618] R10: 006080c0 R11: 0002 R12:
[5.773618] R13: 0001 R14: R15: 0002
[5.773618] FS: () GS:8c69afe0()
knlGS:
[5.773618] CS: 0010 DS: ES: CR0: 80050033
[5.773618] CR2: 2088 CR3: 00087e00a000 CR4: 003406e0
[5.773618] Call Trace:
[5.773618] new_slab+0xa9/0x570
[5.773618] ___slab_alloc+0x375/0x540
[5.773618] ? pinctrl_bind_pins+0x2b/0x2a0
[5.773618] __slab_alloc+0x1c/0x38
[5.773618] __kmalloc_node_track_caller+0xc8/0x270
[5.773618] ? pinctrl_bind_pins+0x2b/0x2a0
[5.773618] devm_kmalloc+0x28/0x60
[5.773618] pinctrl_bind_pins+0x2b/0x2a0
[5.773618] really_probe+0x73/0x420
[5.773618] driver_probe_device+0x115/0x130
[5.773618] __driver_attach+0x103/0x110
[5.773618] ? driver_probe_device+0x130/0x130
[5.773618] bus_for_each_dev+0x67/0xc0
[5.773618] ? klist_add_tail+0x3b/0x70
[5.773618] bus_add_driver+0x41/0x260
[5.773618] ? pcie_port_setup+0x4d/0x4d
[5.773618] driver_register+0x5b/0xe0
[5.773618] ? pcie_port_setup+0x4d/0x4d
[5.773618] do_one_initcall+0x4e/0x1d4
[5.773618] ? init_setup+0x25/0x28
[5.773618] kernel_init_freeable+0x1c1/0x26e
[5.773618] ? loglevel+0x5b/0x5b
[5.773618] ? rest_init+0xb0/0xb0
[5.773618] kernel_init+0xa/0x110
[5.773618] ret_from_fork+0x22/0x40
[5.773618] Modules linked in:
[5.773618] CR2: 2088
[5.773618] ---[ end trace 1030c9120a03d081 ]---
[...]
-4 other notes about the reproduction of this bug:
On my test machine, this bug is covered by 'commit 0d76bcc960e6 ("Revert
"ACPI/PCI: Pay attention to device-specific _PXM node values"")', but the
crack caused by dev->numa_node is still exposed from other path.
II. history
I had a original try on [1], which took the way by deferring the instance of
offline node.
Later Michal has suggested a fix [2], which only consider node with memory as
online. Beside fixing this bug, that patch also aimed at excluding memory-less
node as a candidate when iterating the zones. It is a pity that the method
conflicts with the scheduler code, which assumes node with cpu as online too.
You can find the broken by "git grep for_each_online_node | grep
[PATCH 1/2] x86/numa: carve node online semantics out of alloc_node_data()
Node online means either memory online or cpu online. But there is
requirement to instance a pglist_data, which has neither cpu nor memory
online (refer to [2/2]).
So carve out the online semantics, and call node_set_online() where either
memory or cpu is online.
Signed-off-by: Pingfan Liu
Cc: Michal Hocko
Cc: Dave Hansen
Cc: Mike Rapoport
Cc: Tony Luck
Cc: Andy Lutomirski
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: "H. Peter Anvin"
Cc: Andrew Morton
Cc: Michal Hocko
Cc: Vlastimil Babka
Cc: Oscar Salvador
Cc: Pavel Tatashin
Cc: Mel Gorman
Cc: Benjamin Herrenschmidt
Cc: Michael Ellerman
Cc: Stephen Rothwell
Cc: Qian Cai
Cc: Barret Rhoden
Cc: Bjorn Helgaas
Cc: David Rientjes
Cc: linux...@kvack.org
Cc: linux-kernel@vger.kernel.org
---
arch/x86/mm/numa.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c
index e6dad60..b48d507 100644
--- a/arch/x86/mm/numa.c
+++ b/arch/x86/mm/numa.c
@@ -213,8 +213,6 @@ static void __init alloc_node_data(int nid)
node_data[nid] = nd;
memset(NODE_DATA(nid), 0, sizeof(pg_data_t));
-
- node_set_online(nid);
}
/**
@@ -589,6 +587,7 @@ static int __init numa_register_memblks(struct numa_meminfo
*mi)
continue;
alloc_node_data(nid);
+ node_set_online(nid);
}
/* Dump memblock with node info and return. */
@@ -760,8 +759,10 @@ void __init init_cpu_to_node(void)
if (node == NUMA_NO_NODE)
continue;
- if (!node_online(node))
+ if (!node_online(node)) {
init_memory_less_node(node);
+ node_set_online(nid);
+ }
numa_set_node(cpu, node);
}
--
2.7.5
Re: [PATCH v2] RDMA/core: Fix race when resolving IP address
On Fri, Jul 05, 2019 at 07:49:06AM +0530, Parav Pandit wrote:
> On Fri, Jun 28, 2019 at 2:20 PM Dag Moxnes wrote:
> >
> > Use neighbour lock when copying MAC address from neighbour data struct
> > in dst_fetch_ha.
> >
> > When not using the lock, it is possible for the function to race with
> > neigh_update, causing it to copy an invalid MAC address.
> >
> > It is possible to provoke this error by calling rdma_resolve_addr in a
> > tight loop, while deleting the corresponding ARP entry in another tight
> > loop.
> >
> > Signed-off-by: Dag Moxnes
> > Signed-off-by: Håkon Bugge
> >
> > ---
> > v1 -> v2:
> >* Modified implementation to improve readability
> > ---
> > drivers/infiniband/core/addr.c | 9 ++---
> > 1 file changed, 6 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/infiniband/core/addr.c b/drivers/infiniband/core/addr.c
> > index 2f7d141598..51323ffbc5 100644
> > --- a/drivers/infiniband/core/addr.c
> > +++ b/drivers/infiniband/core/addr.c
> > @@ -333,11 +333,14 @@ static int dst_fetch_ha(const struct dst_entry *dst,
> > if (!n)
> > return -ENODATA;
> >
> > - if (!(n->nud_state & NUD_VALID)) {
> > + read_lock_bh(>lock);
> > + if (n->nud_state & NUD_VALID) {
> > + memcpy(dev_addr->dst_dev_addr, n->ha, MAX_ADDR_LEN);
> > + read_unlock_bh(>lock);
> > + } else {
> > + read_unlock_bh(>lock);
> > neigh_event_send(n, NULL);
> > ret = -ENODATA;
> > - } else {
> > - memcpy(dev_addr->dst_dev_addr, n->ha, MAX_ADDR_LEN);
> > }
> >
> > neigh_release(n);
> > --
> > 2.20.1
> >
> Reviewed-by: Parav Pandit
>
> A sample trace such as below in commit message would be good to have.
> Or the similar one that you noticed with ARP delete sequence.
>
> neigh_changeaddr()
> neigh_flush_dev()
>n->nud_state = NUD_NOARP;
>
> Having some issues with office outlook, so replying via gmail.
Your replies from gmail looks much better when you used Outlook - proper
spacing between quoted text and your reply.
Thanks
Re: [PATCH] rcuperf: Make rcuperf kernel test more robust for !expedited mode
On Thu, Jul 04, 2019 at 10:40:44AM -0700, Paul E. McKenney wrote:
> On Thu, Jul 04, 2019 at 12:34:30AM -0400, Joel Fernandes (Google) wrote:
> > It is possible that the rcuperf kernel test runs concurrently with init
> > starting up. During this time, the system is running all grace periods
> > as expedited. However, rcuperf can also be run for normal GP tests.
> > Right now, it depends on a holdoff time before starting the test to
> > ensure grace periods start later. This works fine with the default
> > holdoff time however it is not robust in situations where init takes
> > greater than the holdoff time to finish running. Or, as in my case:
> >
> > I modified the rcuperf test locally to also run a thread that did
> > preempt disable/enable in a loop. This had the effect of slowing down
> > init. The end result was that the "batches:" counter in rcuperf was 0
> > causing a division by 0 error in the results. This counter was 0 because
> > only expedited GPs seem to happen, not normal ones which led to the
> > rcu_state.gp_seq counter remaining constant across grace periods which
> > unexpectedly happen to be expedited. The system was running expedited
> > RCU all the time because rcu_unexpedited_gp() would not have run yet
> > from init. In other words, the test would concurrently with init
> > booting in expedited GP mode.
> >
> > To fix this properly, let us check if system_state if SYSTEM_RUNNING
> > is set before starting the test. The system_state approximately aligns
Just minor typo..
To fix this properly, let us check if system_state if SYSTEM_RUNNING
is set before starting the test. ...
Should be
To fix this properly, let us check if system_state is set to
SYSTEM_RUNNING before starting the test. ...
Thanks,
Byungchul
> > with when rcu_unexpedited_gp() is called and works well in practice.
> >
> > I also tried late_initcall however it is still too early to be
> > meaningful for this case.
> >
> > Signed-off-by: Joel Fernandes (Google)
>
> Good catch, queued, thank you!
>
> Thanx, Paul
>
> > ---
> > kernel/rcu/rcuperf.c | 8
> > 1 file changed, 8 insertions(+)
> >
> > diff --git a/kernel/rcu/rcuperf.c b/kernel/rcu/rcuperf.c
> > index 4513807cd4c4..5a879d073c1c 100644
> > --- a/kernel/rcu/rcuperf.c
> > +++ b/kernel/rcu/rcuperf.c
> > @@ -375,6 +375,14 @@ rcu_perf_writer(void *arg)
> > if (holdoff)
> > schedule_timeout_uninterruptible(holdoff * HZ);
> >
> > + /*
> > +* Wait until rcu_end_inkernel_boot() is called for normal GP tests
> > +* so that RCU is not always expedited for normal GP tests.
> > +* The system_state test is approximate, but works well in practice.
> > +*/
> > + while (!gp_exp && system_state != SYSTEM_RUNNING)
> > + schedule_timeout_uninterruptible(1);
> > +
> > t = ktime_get_mono_fast_ns();
> > if (atomic_inc_return(_rcu_perf_writer_started) >= nrealwriters) {
> > t_rcu_perf_writer_started = t;
> > --
> > 2.22.0.410.gd8fdbe21b5-goog
> >
RE: audio lost from speaker after reboot from windows on the device ALC295
Hi, Kailiang: Thanks for your tools, here are the two enclosed alsa-info with and without sound. -Original Message- From: Kailang Sent: Friday, July 5, 2019 10:42 AM To: He, Bo ; alsa-de...@alsa-project.org; linux-kernel@vger.kernel.org Cc: pe...@perex.cz; ti...@suse.com; jian-h...@endlessm.com; dr...@endlessm.com; c...@endlessm.com; hui.w...@canonical.com Subject: RE: audio lost from speaker after reboot from windows on the device ALC295 Sorry!! Forgot attach file. > -Original Message- > From: Kailang > Sent: Friday, July 5, 2019 10:41 AM > To: 'He, Bo' ; alsa-de...@alsa-project.org; > linux-kernel@vger.kernel.org > Cc: pe...@perex.cz; ti...@suse.com; jian-h...@endlessm.com; > dr...@endlessm.com; c...@endlessm.com; hui.w...@canonical.com > Subject: RE: audio lost from speaker after reboot from windows on the > device > ALC295 > > Hi Bo He, > > Could you help to dump info for us? > Please use attach file to get results. > > ./alsa-info.sh --no-upload > > You will find dump file in folder /tmp/alsa-info.txt-. > > Please run one time in normal state and one time in fail state. > Please send two result files to me. > > BR, > Kailang > > > -Original Message- > > From: He, Bo > > Sent: Thursday, July 4, 2019 8:02 PM > > To: Kailang ; alsa-de...@alsa-project.org; > > linux-kernel@vger.kernel.org > > Cc: pe...@perex.cz; ti...@suse.com; jian-h...@endlessm.com; > > dr...@endlessm.com; c...@endlessm.com; hui.w...@canonical.com > > Subject: audio lost from speaker after reboot from windows on the > > device > > ALC295 > > > > Hi, patch_realtek.c maintainer: > > I see one issue that reboot from windows and boot to ubuntu, the > > audio lost from speaker, I suspect there are some bugs in > > patch_realtek.c drivers, the device is ALC295 and the device id is > 0x10ec0295. > > > > I have done the below experiments: > > 1. reboot from windows to windows, the audio is persist . > > 2. reboot from windows to ubuntu, the audio lost from speaker, but > > can hear if I hotplug one earphone. > > 3. if the issue reproduce after reboot from windows, reboot the > > ubuntu can't restore the audio, I suspect it's warm reset. > > 4. if I write the port 0xcf9 with 0xe to do cold reset, the audio can > > restore. > > 5. if I do suspend/resume, the audio can restore, I suspect do cold > > boot and suspend will trigger the platform reset to reset the ALC295. > > 6. if I do double function reset (write the verb 0x7ff in alc_init), > > the audio is still can't restore. > > snd_hda_codec_write(codec, 0x01, 0, AC_VERB_SET_CODEC_RESET, 0); /* > > Function reset */ snd_hda_codec_write(codec, 0x01, 0, > > AC_VERB_SET_CODEC_RESET, 0); /* double Function reset */ 7. the > > issue is first found on kernel 4.19.50, I still see the issue with > > the latest kernel 5.2-rc2, is it possible windows change some > > default registers, but ALC295 don't initialize the register? > > > > --Please consider the environment before printing this e-mail. upload=true=true= !! !!ALSA Information Script v 0.4.63 !! !!Script ran on: Fri Jul 5 11:36:08 UTC 2019 !!Linux Distribution !!-- Ubuntu 19.04 \n \l DISTRIB_ID=Ubuntu DISTRIB_DESCRIPTION="Ubuntu 19.04" NAME="Ubuntu" ID=ubuntu ID_LIKE=debian PRETTY_NAME="Ubuntu 19.04" HOME_URL="https://www.ubuntu.com/; SUPPORT_URL="https://help.ubuntu.com/; BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/; PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy; UBUNTU_CODENAME=disco !!DMI Information !!--- Manufacturer: HP Product Name: HP Pavilion x360 Convertible 14-dh0xxx Product Version: Type1ProductConfigId Firmware Version: F.02 !!Kernel Information !!-- Kernel release:5.0.0-13-generic Operating System: GNU/Linux Architecture: x86_64 Processor: x86_64 SMP Enabled: Yes !!ALSA Version !! Driver version: k5.0.0-13-generic Library version:1.1.8 Utilities version: 1.1.8 !!Loaded ALSA modules !!--- snd_hda_intel !!Sound Servers on this system !! Pulseaudio: Installed - Yes (/usr/bin/pulseaudio) Running - Yes !!Soundcards recognised by ALSA !!- 0 [PCH]: HDA-Intel - HDA Intel PCH HDA Intel PCH at 0xa1318000 irq 157 !!PCI Soundcards installed in the system !!-- 00:1f.3 Audio device: Intel Corporation Device 9dc8 (rev 30) !!Advanced information - PCI Vendor/Device/Subsystem ID's !!--- 00:1f.3 0403: 8086:9dc8 (rev 30) (prog-if 80) Subsystem: 103c:85c4 !!Modprobe options (Sound related) !! snd_pcsp: index=-2 snd_usb_audio: index=-2 snd_atiixp_modem: index=-2 snd_intel8x0m: index=-2
Re: [PATCH] rtl8xxxu: Fix wifi low signal strength issue of RTL8723BU
On Wed, Jul 3, 2019 at 8:59 PM Jes Sorensen wrote: > My point is this seems to be very dongle dependent :( We have to be > careful not breaking it for some users while fixing it for others. Do you still have your device? Once we get to the point when you are happy with Chris's two patches here on a code review level, we'll reach out to other driver contributors plus people who previously complained about these types of problems, and see if we can get some wider testing. Larry, do you have these devices, can you help with testing too? Thanks Daniel
Re: [PATCH v2] rtl8xxxu: Fix wifi low signal strength issue of RTL8723BU
On Thu, Jul 4, 2019 at 6:55 PM Chris Chiu wrote: > The WiFi tx power of RTL8723BU is extremely low after booting. So > the WiFi scan gives very limited AP list and it always fails to > connect to the selected AP. This module only supports 1x1 antenna > and the antenna is switched to bluetooth due to some incorrect > register settings. > > Compare with the vendor driver https://github.com/lwfinger/rtl8723bu, > we realized that the 8723bu's enable_rf() does the same thing as > rtw_btcoex_HAL_Initialize() in vendor driver. And it by default > sets the antenna path to BTC_ANT_PATH_BT which we verified it's > the cause of the wifi weak tx power. The vendor driver will set > the antenna path to BTC_ANT_PATH_PTA in the consequent btcoexist > mechanism, by the function halbtc8723b1ant_PsTdma. Checking these details in the vendor driver: EXhalbtc8723b1ant_PowerOnSetting sets: pBoardInfo->btdmAntPos = BTC_ANTENNA_AT_AUX_PORT; Following the code flow from rtw_btcoex_HAL_Initialize(), this has a bWifiOnly parameter which will ultimately influence the final register value. Continuing the flow, we reach halbtc8723b1ant_SetAntPath() with bInitHwCfg=TRUE, bWifiOff=FALSE. antPosType is set to WIFI in the bWifiOnly case, and BT otherwise. I'm assuming that bUseExtSwitch = FALSE (existing rtl8xxxu code also seems to make the same assumption). For the bWifiOnly=FALSE case, it uses BT, pBtCoexist->fBtcWrite4Byte(pBtCoexist, 0x948, 0x0); and rtl8xxxu seems to do the same - seemingly routing the antenna path for BT only. As for halbtc8723b1ant_PsTdma() then being called in a way that causes it to switch to the PTA path a little later, it's more difficult to point out how that happens in an email, but I thin kwe can trust you on that :) There are certainly many callsites that would pass those parameters. > +* Different settings per different antenna position. > +* Antenna Position: | Normal Inverse > +* -- > +* Antenna switch to BT:| 0x280, 0x00 > +* Antenna switch to WiFi: | 0x0, 0x280 > +* Antenna switch to PTA: | 0x200, 0x80 > */ > - rtl8xxxu_write32(priv, REG_S0S1_PATH_SWITCH, 0x00); > + rtl8xxxu_write32(priv, REG_S0S1_PATH_SWITCH, 0x80); I don't really understand what we mean by an "inverse" antenna and my reading of the vendor driver leads me to another interpretation. The logic is based around an antenna position - btdmAntPos. It takes one of two values: BTC_ANTENNA_AT_MAIN_PORT= 0x1, BTC_ANTENNA_AT_AUX_PORT= 0x2, So the chip has pins to support two antennas - a "main" antenna and an "aux" one. We know we're dealing with a single antenna, so the actual module is going to only be using one of those antenna interfaces. If the chip tries to use the other antenna interface, it's effectively not using the antenna. So it's rather important to tell the chip to use the right interface. And that's exactly what happens here. btdmAntPos is hardcoded that the antenna is on the aux port for these devices, and this code is telling the chip that this is how things are wired up. The alternative way of calling this an antenna inverse (which the vendor driver also does in another section), i.e. "antenna is not connected to the main port but instead it's connected to the other one", seems less clear to me. Even if we don't fully understand what's going on here, I'm convinced that your code change is fixing an inconsistency with the vendor driver, and most significantly, making the signal level actually usable on our devices. But if you agree with my interpretation of these values then maybe you could update the comment here! Daniel
Re: [PATCH v2 5/7] x86/mm, tracing: Fix CR2 corruption
On Fri, Jul 5, 2019 at 12:16 PM Andy Lutomirski wrote: > > If nothing else, MOV to CR2 is architecturally serializing, so, unless > there’s some fancy unwinding involved, this will be quite slow. That's why the NMI code does this: if (unlikely(this_cpu_read(nmi_cr2) != read_cr2())) write_cr2(this_cpu_read(nmi_cr2)); so that it normally only does a read. Only if you actually took a page fault will it restore cr2 to the old value (and if you took a page fault the performance issues will be _there_, not in the "restore cr2" part) Linus
Re: [PATCH v2 5/7] x86/mm, tracing: Fix CR2 corruption
> On Jul 4, 2019, at 7:18 PM, Linus Torvalds > wrote: > >> On Fri, Jul 5, 2019 at 5:03 AM Peter Zijlstra wrote: >> >> Despire the current efforts to read CR2 before tracing happens there >> still exist a number of possible holes: > > So this whole series disturbs me for the simple reason that I thought > tracing was supposed to save/restore cr2 and make it unnecessary to > worry about this in non-tracing code. > > That is very much what the NMI code explicitly does. Why shouldn't all > the other tracing code do the same thing in case they can take page > faults? > If nothing else, MOV to CR2 is architecturally serializing, so, unless there’s some fancy unwinding involved, this will be quite slow.
[PATCH v3] checkpatch: add several Kconfig default value tests
This change adds 3 Kconfig default value tests.
1. discourage default n cases:
e.g.,
default n
2. discourage default "[ynm]" cases:
e.g.,
arch/powerpc/Kconfig: default "y" if PPC_POWERNV
arch/powerpc/Kconfig: default "y" if PPC_POWERNV
arch/powerpc/Kconfig: default "n"
drivers/auxdisplay/Kconfig: default "n"
drivers/crypto/Kconfig: default "m"
drivers/rapidio/devices/Kconfig:default "n"
3. discourage default EXPERT or default !EXPERT cases:
e.g.,
drivers/hid/Kconfig:default !EXPERT
tested cases:
default m
default n if ALPHA_EV5 || ALPHA_EV56 || (ALPHA_EV4 && !ALPHA_LCA)
default y if ALPHA_QEMU
default n if PPC_POWERNV
default n
default EXPERT
default !EXPERT
default "m"
default "n"
default "y" if EXPERT
default "y" if PPC_POWERNV
test result:
WARNING: 'default n' is the default value, no need to write it explicitly
+ default n
WARNING: Avoid using default EXPERT
+ default EXPERT
WARNING: Avoid using default EXPERT
+ default !EXPERT
WARNING: Use 'default m' not 'default "m"'
+ default "m"
WARNING: Use 'default n' not 'default "n"'
+ default "n"
WARNING: Use 'default y' not 'default "y"'
+ default "y" if EXPERT
WARNING: Use 'default y' not 'default "y"'
+ default "y" if PPC_POWERNV
test --fix capability:
default n => delete line
default "m" => default m
default "n" => default n
default "y" if EXPERT => default y if EXPERT
default "y" if PPC_POWERNV => default y if PPC_POWERNV
default !EXPERT => no change
default EXPERT => no change
Change since v1:
discourage default n$
discourage default "[ynm]"
discourage default \!?EXPERT
Change since v2:
(Joe has provided the whole patch and I just post it)
test Kconfig in a single block
print precise message such as 'default "m"', not 'default "[ynm]"'
provide --fix capability
Cc: Joe Perches
Cc: Yingjoe Chen
Signed-off-by: Miles Chen
---
scripts/checkpatch.pl | 139 ++
1 file changed, 85 insertions(+), 54 deletions(-)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 342c7c781ba5..94799f23339c 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -2932,60 +2932,98 @@ sub process {
"Do not include the paragraph about
writing to the Free Software Foundation's mailing address from the sample GPL
notice. The FSF has changed addresses in the past, and may do so again. Linux
already includes a copy of the GPL.\n" . $herevet)
}
-# check for Kconfig help text having a real description
-# Only applies when adding the entry originally, after that we do not have
-# sufficient context to determine whether it is indeed long enough.
- if ($realfile =~ /Kconfig/ &&
- # 'choice' is usually the last thing on the line (though
- # Kconfig supports named choices), so use a word boundary
- # (\b) rather than a whitespace character (\s)
- $line =~ /^\+\s*(?:config|menuconfig|choice)\b/) {
- my $length = 0;
- my $cnt = $realcnt;
- my $ln = $linenr + 1;
- my $f;
- my $is_start = 0;
- my $is_end = 0;
- for (; $cnt > 0 && defined $lines[$ln - 1]; $ln++) {
- $f = $lines[$ln - 1];
- $cnt-- if ($lines[$ln - 1] !~ /^-/);
- $is_end = $lines[$ln - 1] =~ /^\+/;
-
- next if ($f =~ /^-/);
- last if (!$file && $f =~ /^\@\@/);
-
- if ($lines[$ln - 1] =~
/^\+\s*(?:bool|tristate|prompt)\s*["']/) {
- $is_start = 1;
- } elsif ($lines[$ln - 1] =~
/^\+\s*(?:help|---help---)\s*$/) {
- if ($lines[$ln - 1] =~ "---help---") {
- WARN("CONFIG_DESCRIPTION",
-"prefer 'help' over
'---help---' for new help texts\n" . $herecurr);
+# Kconfig tests
+ if ($realfile =~ /Kconfig/) {
+ # check for Kconfig help text having a real description
+ # Only applies when adding the entry originally, after
+ # that we do not have sufficient context to determine
+ # whether it is indeed long enough.
+ # 'choice' is usually the last thing on the line (though
+ # Kconfig supports named choices), so use a word
+ # boundary (\b) rather than a whitespace character (\s)
+ if ($line =~ /^\+\s*(?:config|menuconfig|choice)\b/) {
+ my $length = 0;
+ my $cnt = $realcnt;
+
RE: [PATCH v1 net-next] net: stmmac: enable clause 45 mdio support
> I think there is too much passing variables around by reference than by
> value, to make this code easy to understand.
>
> Maybe a better structure would be
>
> static int stmmac_mdion_c45_read(struct stmmac_priv *priv, int phyaddr,
> int phyreg) {
>
> unsigned int reg_shift = priv->hw->mii.reg_shift;
> unsigned int reg_mask = priv->hw->mii.reg_mask;
> u32 mii_addr_val, mii_data_val;
>
> mii_addr_val = MII_GMAC4_C45E |
>((phyreg >> MII_DEVADDR_C45_SHIFT) << reg_shift)
> & reg_mask;
> mii_data_val = (phyreg & MII_REGADDR_C45_MASK) <<
> MII_GMAC4_REG_ADDR_SHIFT;
>
> writel(mii_data_val, priv->ioaddr + priv->hw->mii_data);
> writel(mii_addr_val, priv->ioaddr + priv->hw->mii_addrress);
>
> return (int)readl(priv->ioaddr + mii_data) & MII_DATA_MASK;
> }
>
> static int stmmac_mdio_read(struct mii_bus *bus, int phyaddr, int phyreg)
> {
>
> ...
> if (readl_poll_timeout(priv->ioaddr + mii_address, v, !(v &
> MII_BUSY),
> 100, 1))
> return -EBUSY;
>
> if (priv->plat->has_gmac4 && phyreg & MII_ADDR_C45)
> return stmmac_mdio_c45_read(priv, phyaddr, phyreg);
>
> Andrew
Both c45 read/write needs to set c45 enable bit(MII_ADDR_C45) in mii_adrress
and set the register address in mii_data. Besides this, the whole programming
flow will be the same as c22. With the current design, user can easily know
that the different between c22 and c45 is just in stmmac_mdio_c45_setup().
If the community prefers readability, I will suggest to do the c45 setup in
both stmmac_mdio_read() and stmmac_mdio_write() 's if(C45) condition rather
than splitting into 2 new c45_read() and c45_write() functions.
static int stmmac_mdio_read(struct mii_bus *bus, int phyaddr, int phyreg)
{
...
if (phyreg & MII_ADDR_C45)
*val |= MII_GMAC4_C45E;
*val &= ~reg_mask;
*val |= ((phyreg >> MII_DEVADDR_C45_SHIFT) << reg_shift) & reg_mask;
*data |= (phyreg & MII_REGADDR_C45_MASK) << MII_GMAC4_REG_ADDR_SHIFT;
Weifeng
Re: mmotm 2019-07-04-15-01 uploaded (mm/vmscan.c)
On 7/4/19 3:01 PM, a...@linux-foundation.org wrote:
> The mm-of-the-moment snapshot 2019-07-04-15-01 has been uploaded to
>
>http://www.ozlabs.org/~akpm/mmotm/
>
> mmotm-readme.txt says
>
> README for mm-of-the-moment:
>
> http://www.ozlabs.org/~akpm/mmotm/
>
> This is a snapshot of my -mm patch queue. Uploaded at random hopefully
> more than once a week.
>
on i386:
CONFIG_SLOB=y <<
../mm/vmscan.c: In function ‘prealloc_memcg_shrinker’:
../mm/vmscan.c:220:3: error: implicit declaration of function
‘memcg_expand_shrinker_maps’ [-Werror=implicit-function-declaration]
if (memcg_expand_shrinker_maps(id)) {
^
In file included from ../include/linux/rbtree.h:22:0,
from ../include/linux/mm_types.h:10,
from ../include/linux/mmzone.h:21,
from ../include/linux/gfp.h:6,
from ../include/linux/mm.h:10,
from ../mm/vmscan.c:17:
../mm/vmscan.c: In function ‘shrink_slab_memcg’:
../mm/vmscan.c:608:54: error: ‘struct mem_cgroup_per_node’ has no member named
‘shrinker_map’
map = rcu_dereference_protected(memcg->nodeinfo[nid]->shrinker_map,
^
../include/linux/rcupdate.h:321:12: note: in definition of macro
‘__rcu_dereference_protected’
((typeof(*p) __force __kernel *)(p)); \
^
../mm/vmscan.c:608:8: note: in expansion of macro ‘rcu_dereference_protected’
map = rcu_dereference_protected(memcg->nodeinfo[nid]->shrinker_map,
^
../mm/vmscan.c:608:54: error: ‘struct mem_cgroup_per_node’ has no member named
‘shrinker_map’
map = rcu_dereference_protected(memcg->nodeinfo[nid]->shrinker_map,
^
../include/linux/rcupdate.h:321:35: note: in definition of macro
‘__rcu_dereference_protected’
((typeof(*p) __force __kernel *)(p)); \
^
../mm/vmscan.c:608:8: note: in expansion of macro ‘rcu_dereference_protected’
map = rcu_dereference_protected(memcg->nodeinfo[nid]->shrinker_map,
^
--
~Randy
[PATCH] sound: pci: asihpi: Remove unneeded variable change
this patch fixes below issue reported by coccicheck
sound/pci/asihpi/asihpi.c:1558:5-11: Unneeded variable: "change". Return
"1" on line 1564
Signed-off-by: Hariprasad Kelam
---
sound/pci/asihpi/asihpi.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/sound/pci/asihpi/asihpi.c b/sound/pci/asihpi/asihpi.c
index e7234f3..2a21a3d 100644
--- a/sound/pci/asihpi/asihpi.c
+++ b/sound/pci/asihpi/asihpi.c
@@ -1519,7 +1519,6 @@ static int snd_asihpi_volume_get(struct snd_kcontrol
*kcontrol,
static int snd_asihpi_volume_put(struct snd_kcontrol *kcontrol,
struct snd_ctl_elem_value *ucontrol)
{
- int change;
u32 h_control = kcontrol->private_value;
short an_gain_mB[HPI_MAX_CHANNELS];
@@ -1530,9 +1529,8 @@ static int snd_asihpi_volume_put(struct snd_kcontrol
*kcontrol,
/* change = asihpi->mixer_volume[addr][0] != left ||
asihpi->mixer_volume[addr][1] != right;
*/
- change = 1;
hpi_handle_error(hpi_volume_set_gain(h_control, an_gain_mB));
- return change;
+ return 1;
}
static const DECLARE_TLV_DB_SCALE(db_scale_100, -1, VOL_STEP_mB, 0);
@@ -1555,13 +1553,12 @@ static int snd_asihpi_volume_mute_put(struct
snd_kcontrol *kcontrol,
struct snd_ctl_elem_value *ucontrol)
{
u32 h_control = kcontrol->private_value;
- int change = 1;
/* HPI currently only supports all or none muting of multichannel volume
ALSA Switch element has opposite sense to HPI mute: on==unmuted,
off=muted
*/
int mute = ucontrol->value.integer.value[0] ? 0 :
HPI_BITMASK_ALL_CHANNELS;
hpi_handle_error(hpi_volume_set_mute(h_control, mute));
- return change;
+ return 1;
}
static int snd_asihpi_volume_add(struct snd_card_asihpi *asihpi,
--
2.7.4
Re: [GIT PULL] dax fix for v5.2-rc8
The pull request you sent on Thu, 4 Jul 2019 17:11:16 -0700: > git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm > tags/dax-fix-5.2-rc8 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/cde357c392e93aa7fcfc019403e0d1792081d634 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] ARM: SoC fixes
The pull request you sent on Thu, 4 Jul 2019 17:22:23 -0700: > git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git tags/armsoc-fixes has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/ecbe5086adc2876b22c898987d8a20f932de87a9 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [git pull] do_move_mount() fix
The pull request you sent on Thu, 4 Jul 2019 21:57:41 +0100: > git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git fixes has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/2cd7cdc7e420a343743db781484e801fd784a1f1 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
RE: [EXT] Re: [PATCH nvmem 1/1] nvmem: imx: correct the fuse word index
From: Andy Duan Sent: Friday, July 5, 2019 12:08 AM
> From: Lothar Waßmann Sent: Thursday, July 4,
> 2019 11:46 PM
> > Hi,
> >
> > On Thu, 4 Jul 2019 22:20:15 +0800 fugang.d...@nxp.com wrote:
> > > From: Fugang Duan
> > >
> > > iMX8 fuse word index represent as one 4-bytes word, it should not be
> > > divided by 4.
> > >
> > > Exp:
> > > - MAC0 address layout in fuse:
> > > offset 708: MAC[3] MAC[2] MAC[1] MAC[0]
> > > offset 709: XX xx MAC[5] MAC[4]
> > >
> > > Signed-off-by: Fugang Duan
> > > ---
> > > drivers/nvmem/imx-ocotp-scu.c | 6 +++---
> > > 1 file changed, 3 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/nvmem/imx-ocotp-scu.c
> > > b/drivers/nvmem/imx-ocotp-scu.c index d9dc482..be2f5f0 100644
> > > --- a/drivers/nvmem/imx-ocotp-scu.c
> > > +++ b/drivers/nvmem/imx-ocotp-scu.c
> > > @@ -71,8 +71,8 @@ static int imx_scu_ocotp_read(void *context,
> > > unsigned
> > int offset,
> > > void *p;
> > > int i, ret;
> > >
> > > - index = offset >> 2;
> > > - num_bytes = round_up((offset % 4) + bytes, 4);
> > > + index = offset;
> > > + num_bytes = round_up(bytes, 4);
> > > count = num_bytes >> 2;
> > >
> > > if (count > (priv->data->nregs - index)) @@ -100,7 +100,7 @@
> > > static int imx_scu_ocotp_read(void *context, unsigned int offset,
> > > buf++;
> > > }
> > >
> > > - memcpy(val, (u8 *)p + offset % 4, bytes);
> > > + memcpy(val, (u8 *)p, bytes);
> > >
> > > kfree(p);
> > >
> > With these changes you could use the 'val' pointer directly as the
> > destination for ocotp_read() without need for an intermediate buffer.
> >
> >
> > Lothar Waßmann
>
> You are right, in fact, we can remove "p" and "buf" pointer.
> Thanks for your review, I will send out the V2.
Hi Lothar,
It still need intermediate buffer to read out n words (n * 4 bytes) from eFuse.
Because 'val' buffer size is real count parsed from DT, which is not an integer
multiple of 4.
For example, cell->bytes is parsed from "reg" property and it is real count
like 6.
fec_mac0: mac@2c4 {
reg = <0x2c4 6>;
};
So we have to use intermediate buffer here.
WITH DUE RESPECT
Compliment of the day, I am Mr. Salif Naba I Have a Business Proposal of $15.5)million For You. I am aware of the unsafe nature of the internet, and was compelled to use this medium due to the nature of this project. I have access to very vital information that can be used to transfer this huge amount of money, which may culminate into the investment of the said funds into your company or any lucrative venture in your country. If you will like to assist me as a partner then indicate your interest, after which we shall both discuss the modalities and the sharing percentage. Upon receipt of your reply on your expression of Interest I will give you full details, on how the business will be executed I am open for negotiation. You should forward your reply to this private email id (salifnab...@gmail.com) Thanks for your anticipated cooperation. Note you might receive this message in your inbox or spam or junk folder, depends on your web host or server network. Thanks’ Best Regards Mr., Salif Naba
RE: audio lost from speaker after reboot from windows on the device ALC295
Sorry!! Forgot attach file. > -Original Message- > From: Kailang > Sent: Friday, July 5, 2019 10:41 AM > To: 'He, Bo' ; alsa-de...@alsa-project.org; > linux-kernel@vger.kernel.org > Cc: pe...@perex.cz; ti...@suse.com; jian-h...@endlessm.com; > dr...@endlessm.com; c...@endlessm.com; hui.w...@canonical.com > Subject: RE: audio lost from speaker after reboot from windows on the device > ALC295 > > Hi Bo He, > > Could you help to dump info for us? > Please use attach file to get results. > > ./alsa-info.sh --no-upload > > You will find dump file in folder /tmp/alsa-info.txt-. > > Please run one time in normal state and one time in fail state. > Please send two result files to me. > > BR, > Kailang > > > -Original Message- > > From: He, Bo > > Sent: Thursday, July 4, 2019 8:02 PM > > To: Kailang ; alsa-de...@alsa-project.org; > > linux-kernel@vger.kernel.org > > Cc: pe...@perex.cz; ti...@suse.com; jian-h...@endlessm.com; > > dr...@endlessm.com; c...@endlessm.com; hui.w...@canonical.com > > Subject: audio lost from speaker after reboot from windows on the > > device > > ALC295 > > > > Hi, patch_realtek.c maintainer: > > I see one issue that reboot from windows and boot to ubuntu, the > > audio lost from speaker, I suspect there are some bugs in > > patch_realtek.c drivers, the device is ALC295 and the device id is > 0x10ec0295. > > > > I have done the below experiments: > > 1. reboot from windows to windows, the audio is persist . > > 2. reboot from windows to ubuntu, the audio lost from speaker, but can > > hear if I hotplug one earphone. > > 3. if the issue reproduce after reboot from windows, reboot the ubuntu > > can't restore the audio, I suspect it's warm reset. > > 4. if I write the port 0xcf9 with 0xe to do cold reset, the audio can > > restore. > > 5. if I do suspend/resume, the audio can restore, I suspect do cold > > boot and suspend will trigger the platform reset to reset the ALC295. > > 6. if I do double function reset (write the verb 0x7ff in alc_init), > > the audio is still can't restore. > > snd_hda_codec_write(codec, 0x01, 0, AC_VERB_SET_CODEC_RESET, 0); /* > > Function reset */ snd_hda_codec_write(codec, 0x01, 0, > > AC_VERB_SET_CODEC_RESET, 0); /* double Function reset */ 7. the issue > > is first found on kernel 4.19.50, I still see the issue with the > > latest kernel 5.2-rc2, is it possible windows change some default > > registers, but ALC295 don't initialize the register? > > > > --Please consider the environment before printing this e-mail. alsa-info.sh Description: alsa-info.sh
RE: audio lost from speaker after reboot from windows on the device ALC295
Hi Bo He, Could you help to dump info for us? Please use attach file to get results. ./alsa-info.sh --no-upload You will find dump file in folder /tmp/alsa-info.txt-. Please run one time in normal state and one time in fail state. Please send two result files to me. BR, Kailang > -Original Message- > From: He, Bo > Sent: Thursday, July 4, 2019 8:02 PM > To: Kailang ; alsa-de...@alsa-project.org; > linux-kernel@vger.kernel.org > Cc: pe...@perex.cz; ti...@suse.com; jian-h...@endlessm.com; > dr...@endlessm.com; c...@endlessm.com; hui.w...@canonical.com > Subject: audio lost from speaker after reboot from windows on the device > ALC295 > > Hi, patch_realtek.c maintainer: > I see one issue that reboot from windows and boot to ubuntu, the audio > lost from speaker, I suspect there are some bugs in patch_realtek.c drivers, > the device is ALC295 and the device id is 0x10ec0295. > > I have done the below experiments: > 1. reboot from windows to windows, the audio is persist . > 2. reboot from windows to ubuntu, the audio lost from speaker, but can hear if > I hotplug one earphone. > 3. if the issue reproduce after reboot from windows, reboot the ubuntu can't > restore the audio, I suspect it's warm reset. > 4. if I write the port 0xcf9 with 0xe to do cold reset, the audio can restore. > 5. if I do suspend/resume, the audio can restore, I suspect do cold boot and > suspend will trigger the platform reset to reset the ALC295. > 6. if I do double function reset (write the verb 0x7ff in alc_init), the > audio is > still can't restore. > snd_hda_codec_write(codec, 0x01, 0, AC_VERB_SET_CODEC_RESET, 0); /* > Function reset */ snd_hda_codec_write(codec, 0x01, 0, > AC_VERB_SET_CODEC_RESET, 0); /* double Function reset */ 7. the issue is > first found on kernel 4.19.50, I still see the issue with the latest kernel > 5.2-rc2, > is it possible windows change some default registers, but ALC295 don't > initialize the register? > > --Please consider the environment before printing this e-mail.
RE: [PATCHv5 02/20] PCI: mobiveil: Format the code without functionality change
Hi Lorenzo, > -Original Message- > From: Lorenzo Pieralisi > Sent: 2019年7月4日 18:57 > To: Z.q. Hou > Cc: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; > bhelg...@google.com; robh...@kernel.org; mark.rutl...@arm.com; > l.subrahma...@mobiveil.co.in; shawn...@kernel.org; Leo Li > ; catalin.mari...@arm.com; will.dea...@arm.com; > Mingkai Hu ; M.h. Lian ; > Xiaowei Bao > Subject: Re: [PATCHv5 02/20] PCI: mobiveil: Format the code without > functionality change > > On Thu, Jul 04, 2019 at 03:00:37AM +, Z.q. Hou wrote: > > [...] > > > > If you can manage to rebase patches on pci/mobiveil on top of > > > v5.2-rc1, send them separately so that I can merge them as a base > > > for the subsequent patches to be applied. > > > > You meant send the patches one by one, which you requested to split, > > and other patches without any changes can be send together, right? > > First step, rebase my branch above against v5.2-rc1 *without* this patch. > Then apply all the patches I requested to split (inclusive of this one) on > top of > it and send the whole patch series in one go. > > Please let me know if that's still unclear. It's clear now. Thanks, Zhiqiang > Thanks, > Lorenzo > > > > If you have any questions please ask, do not post patches if there > > > is something that is not clear. > > > > Yes, I'll, thanks for your guide again! > > > > B.R, > > Zhiqiang > > > > > > > > Lorenzo > > > > > > > diff --git a/drivers/pci/controller/pcie-mobiveil.c > > > > b/drivers/pci/controller/pcie-mobiveil.c > > > > index d55c7e780c6e..b87471f08a40 100644 > > > > --- a/drivers/pci/controller/pcie-mobiveil.c > > > > +++ b/drivers/pci/controller/pcie-mobiveil.c > > > > @@ -31,38 +31,40 @@ > > > > * translation tables are grouped into windows, each window > > > > registers > > > are > > > > * grouped into blocks of 4 or 16 registers each > > > > */ > > > > -#define PAB_REG_BLOCK_SIZE 16 > > > > -#define PAB_EXT_REG_BLOCK_SIZE 4 > > > > +#define PAB_REG_BLOCK_SIZE 16 > > > > +#define PAB_EXT_REG_BLOCK_SIZE 4 > > > > > > > > -#define PAB_REG_ADDR(offset, win) (offset + (win * > > > > PAB_REG_BLOCK_SIZE)) -#define PAB_EXT_REG_ADDR(offset, win) > > > > (offset > > > + > > > > (win * PAB_EXT_REG_BLOCK_SIZE)) > > > > +#define PAB_REG_ADDR(offset, win) \ > > > > + (offset + (win * PAB_REG_BLOCK_SIZE)) > > > > +#define PAB_EXT_REG_ADDR(offset, win) \ > > > > + (offset + (win * PAB_EXT_REG_BLOCK_SIZE)) > > > > > > > > -#define LTSSM_STATUS 0x0404 > > > > -#define LTSSM_STATUS_L0_MASK 0x3f > > > > -#define LTSSM_STATUS_L0 0x2d > > > > +#define LTSSM_STATUS 0x0404 > > > > +#define LTSSM_STATUS_L0_MASK 0x3f > > > > +#define LTSSM_STATUS_L0 0x2d > > > > > > > > -#define PAB_CTRL 0x0808 > > > > -#define AMBA_PIO_ENABLE_SHIFT 0 > > > > -#define PEX_PIO_ENABLE_SHIFT 1 > > > > -#define PAGE_SEL_SHIFT13 > > > > -#define PAGE_SEL_MASK 0x3f > > > > -#define PAGE_LO_MASK 0x3ff > > > > -#define PAGE_SEL_OFFSET_SHIFT 10 > > > > +#define PAB_CTRL 0x0808 > > > > +#define AMBA_PIO_ENABLE_SHIFT 0 > > > > +#define PEX_PIO_ENABLE_SHIFT 1 > > > > +#define PAGE_SEL_SHIFT13 > > > > +#define PAGE_SEL_MASK 0x3f > > > > +#define PAGE_LO_MASK 0x3ff > > > > +#define PAGE_SEL_OFFSET_SHIFT 10 > > > > > > > > -#define PAB_AXI_PIO_CTRL 0x0840 > > > > -#define APIO_EN_MASK 0xf > > > > +#define PAB_AXI_PIO_CTRL 0x0840 > > > > +#define APIO_EN_MASK 0xf > > > > > > > > -#define PAB_PEX_PIO_CTRL 0x08c0 > > > > -#define PIO_ENABLE_SHIFT 0 > > > > +#define PAB_PEX_PIO_CTRL 0x08c0 > > > > +#define PIO_ENABLE_SHIFT 0 > > > > > > > > #define PAB_INTP_AMBA_MISC_ENB 0x0b0c > > > > -#define PAB_INTP_AMBA_MISC_STAT0x0b1c > > > > +#define PAB_INTP_AMBA_MISC_STAT0x0b1c > > > > #define PAB_INTP_INTX_MASK0x01e0 > > > > #define PAB_INTP_MSI_MASK 0x8 > > > > > > > > -#define PAB_AXI_AMAP_CTRL(win) PAB_REG_ADDR(0x0ba0, win) > > > > -#define WIN_ENABLE_SHIFT 0 > > > > -#define WIN_TYPE_SHIFT1 > > > > +#define PAB_AXI_AMAP_CTRL(win) PAB_REG_ADDR(0x0ba0, > win) > > > > +#define WIN_ENABLE_SHIFT 0 > > > > +#define WIN_TYPE_SHIFT1 > > > > > > > > #define PAB_EXT_AXI_AMAP_SIZE(win) > PAB_EXT_REG_ADDR(0xbaf0, > > > win) > > > > > > > > @@ -70,16 +72,16 @@ > > > > #define AXI_WINDOW_ALIGN_MASK 3 > > > > > > > > #define PAB_AXI_AMAP_PEX_WIN_L(win) > PAB_REG_ADDR(0x0ba8, > > > win) > > > > -#define PAB_BUS_SHIFT 24 > > > > -#define PAB_DEVICE_SHIFT 19 > > > > -#define PAB_FUNCTION_SHIFT16 > > >
Re: [PATCH v2] ASoC: sunxi: sun50i-codec-analog: Add earpiece
On Thu, Jul 4, 2019 at 2:49 AM Luca Weiss wrote: > > This adds the necessary registers and audio routes to play audio using > the Earpiece, that's supported on the A64. > > Signed-off-by: Luca Weiss LGTM. Reviewed-by: Chen-Yu Tsai
Re: [PATCH v2] rtl8xxxu: Fix wifi low signal strength issue of RTL8723BU
On Fri, Jul 5, 2019 at 12:43 AM Jes Sorensen wrote: > > On 7/4/19 6:55 AM, Chris Chiu wrote: > > The WiFi tx power of RTL8723BU is extremely low after booting. So > > the WiFi scan gives very limited AP list and it always fails to > > connect to the selected AP. This module only supports 1x1 antenna > > and the antenna is switched to bluetooth due to some incorrect > > register settings. > > > > Compare with the vendor driver https://github.com/lwfinger/rtl8723bu, > > we realized that the 8723bu's enable_rf() does the same thing as > > rtw_btcoex_HAL_Initialize() in vendor driver. And it by default > > sets the antenna path to BTC_ANT_PATH_BT which we verified it's > > the cause of the wifi weak tx power. The vendor driver will set > > the antenna path to BTC_ANT_PATH_PTA in the consequent btcoexist > > mechanism, by the function halbtc8723b1ant_PsTdma. > > > > This commit hand over the antenna control to PTA(Packet Traffic > > Arbitration), which compares the weight of bluetooth/wifi traffic > > then determine whether to continue current wifi traffic or not. > > After PTA take control, The wifi signal will be back to normal and > > the bluetooth scan can also work at the same time. However, the > > btcoexist still needs to be handled under different circumstances. > > If there's a BT connection established, the wifi still fails to > > connect until BT disconnected. > > > > Signed-off-by: Chris Chiu > > --- > > > > > > Note: > > v2: > > - Replace BIT(11) with the descriptive definition > > - Meaningful comment for the REG_S0S1_PATH_SWITCH setting > > > > > > drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c | 11 --- > > drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 3 ++- > > 2 files changed, 10 insertions(+), 4 deletions(-) > > > > diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c > > b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c > > index 3adb1d3d47ac..ceffe05bd65b 100644 > > --- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c > > +++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c > > @@ -1525,7 +1525,7 @@ static void rtl8723b_enable_rf(struct rtl8xxxu_priv > > *priv) > > /* > >* WLAN action by PTA > >*/ > > - rtl8xxxu_write8(priv, REG_WLAN_ACT_CONTROL_8723B, 0x04); > > + rtl8xxxu_write8(priv, REG_WLAN_ACT_CONTROL_8723B, 0x0c); > > > > /* > >* BT select S0/S1 controlled by WiFi > > @@ -1568,9 +1568,14 @@ static void rtl8723b_enable_rf(struct rtl8xxxu_priv > > *priv) > > rtl8xxxu_gen2_h2c_cmd(priv, , sizeof(h2c.ant_sel_rsv)); > > > > /* > > - * 0x280, 0x00, 0x200, 0x80 - not clear > > + * Different settings per different antenna position. > > + * Antenna Position: | Normal Inverse > > + * -- > > + * Antenna switch to BT:| 0x280, 0x00 > > + * Antenna switch to WiFi: | 0x0, 0x280 > > + * Antenna switch to PTA: | 0x200, 0x80 > >*/ > > - rtl8xxxu_write32(priv, REG_S0S1_PATH_SWITCH, 0x00); > > + rtl8xxxu_write32(priv, REG_S0S1_PATH_SWITCH, 0x80); > > Per the documentation, shouldn't this be set to 0x200 then rather than 0x80? > Per the code before REG_S0S1_PATH_SWITCH setting, the driver has told the co-processor the antenna is inverse. memset(, 0, sizeof(struct h2c_cmd)); h2c.ant_sel_rsv.cmd = H2C_8723B_ANT_SEL_RSV; h2c.ant_sel_rsv.ant_inverse = 1; h2c.ant_sel_rsv.int_switch_type = 0; rtl8xxxu_gen2_h2c_cmd(priv, , sizeof(h2c.ant_sel_rsv)); At least the current modification is consistent with the antenna inverse setting. I'll verify on vendor driver about when/how the inverse be determined. Chris > We may need to put in place so > > Cheers, > Jesme code to detect whether we have normal > or inverse configuration of the dongle otherwise? > > I really appreciate you're digging into this!
Re: [RFC v2] vhost: introduce mdev based hardware vhost backend
On Fri, Jul 05, 2019 at 08:30:00AM +0800, Jason Wang wrote:
> On 2019/7/4 下午3:02, Tiwei Bie wrote:
> > On Thu, Jul 04, 2019 at 02:35:20PM +0800, Jason Wang wrote:
> > > On 2019/7/4 下午2:21, Tiwei Bie wrote:
> > > > On Thu, Jul 04, 2019 at 12:31:48PM +0800, Jason Wang wrote:
> > > > > On 2019/7/3 下午9:08, Tiwei Bie wrote:
> > > > > > On Wed, Jul 03, 2019 at 08:16:23PM +0800, Jason Wang wrote:
> > > > > > > On 2019/7/3 下午7:52, Tiwei Bie wrote:
> > > > > > > > On Wed, Jul 03, 2019 at 06:09:51PM +0800, Jason Wang wrote:
> > > > > > > > > On 2019/7/3 下午5:13, Tiwei Bie wrote:
> > > > > > > > > > Details about this can be found here:
> > > > > > > > > >
> > > > > > > > > > https://lwn.net/Articles/750770/
> > > > > > > > > >
> > > > > > > > > > What's new in this version
> > > > > > > > > > ==
> > > > > > > > > >
> > > > > > > > > > A new VFIO device type is introduced - vfio-vhost. This
> > > > > > > > > > addressed
> > > > > > > > > > some comments from
> > > > > > > > > > here:https://patchwork.ozlabs.org/cover/984763/
> > > > > > > > > >
> > > > > > > > > > Below is the updated device interface:
> > > > > > > > > >
> > > > > > > > > > Currently, there are two regions of this device: 1)
> > > > > > > > > > CONFIG_REGION
> > > > > > > > > > (VFIO_VHOST_CONFIG_REGION_INDEX), which can be used to
> > > > > > > > > > setup the
> > > > > > > > > > device; 2) NOTIFY_REGION (VFIO_VHOST_NOTIFY_REGION_INDEX),
> > > > > > > > > > which
> > > > > > > > > > can be used to notify the device.
> > > > > > > > > >
> > > > > > > > > > 1. CONFIG_REGION
> > > > > > > > > >
> > > > > > > > > > The region described by CONFIG_REGION is the main control
> > > > > > > > > > interface.
> > > > > > > > > > Messages will be written to or read from this region.
> > > > > > > > > >
> > > > > > > > > > The message type is determined by the `request` field in
> > > > > > > > > > message
> > > > > > > > > > header. The message size is encoded in the message header
> > > > > > > > > > too.
> > > > > > > > > > The message format looks like this:
> > > > > > > > > >
> > > > > > > > > > struct vhost_vfio_op {
> > > > > > > > > > __u64 request;
> > > > > > > > > > __u32 flags;
> > > > > > > > > > /* Flag values: */
> > > > > > > > > > #define VHOST_VFIO_NEED_REPLY 0x1 /* Whether need
> > > > > > > > > > reply */
> > > > > > > > > > __u32 size;
> > > > > > > > > > union {
> > > > > > > > > > __u64 u64;
> > > > > > > > > > struct vhost_vring_state state;
> > > > > > > > > > struct vhost_vring_addr addr;
> > > > > > > > > > } payload;
> > > > > > > > > > };
> > > > > > > > > >
> > > > > > > > > > The existing vhost-kernel ioctl cmds are reused as the
> > > > > > > > > > message
> > > > > > > > > > requests in above structure.
> > > > > > > > > Still a comments like V1. What's the advantage of inventing a
> > > > > > > > > new protocol?
> > > > > > > > I'm trying to make it work in VFIO's way..
> > > > > > > >
> > > > > > > > > I believe either of the following should be better:
> > > > > > > > >
> > > > > > > > > - using vhost ioctl, we can start from
> > > > > > > > > SET_VRING_KICK/SET_VRING_CALL and
> > > > > > > > > extend it with e.g notify region. The advantages is that all
> > > > > > > > > exist userspace
> > > > > > > > > program could be reused without modification (or minimal
> > > > > > > > > modification). And
> > > > > > > > > vhost API hides lots of details that is not necessary to be
> > > > > > > > > understood by
> > > > > > > > > application (e.g in the case of container).
> > > > > > > > Do you mean reusing vhost's ioctl on VFIO device fd directly,
> > > > > > > > or introducing another mdev driver (i.e. vhost_mdev instead of
> > > > > > > > using the existing vfio_mdev) for mdev device?
> > > > > > > Can we simply add them into ioctl of mdev_parent_ops?
> > > > > > Right, either way, these ioctls have to be and just need to be
> > > > > > added in the ioctl of the mdev_parent_ops. But another thing we
> > > > > > also need to consider is that which file descriptor the userspace
> > > > > > will do the ioctl() on. So I'm wondering do you mean let the
> > > > > > userspace do the ioctl() on the VFIO device fd of the mdev
> > > > > > device?
> > > > > >
> > > > > Yes.
> > > > Got it! I'm not sure what's Alex opinion on this. If we all
> > > > agree with this, I can do it in this way.
> > > >
> > > > > Is there any other way btw?
> > > > Just a quick thought.. Maybe totally a bad idea.
> > >
> > > It's not for sure :)
> > Thanks!
> >
> > >
> > > >I was thinking
> > > > whether it would be odd to do non-VFIO's ioctls on VFIO's device
> > > > fd. So I was wondering whether it's possible to allow binding
> > > > another mdev driver (e.g. vhost_mdev) to the supported mdev
> > > > devices. The new mdev driver, vhost_mdev, can provide similar
> > > > ways to let userspace open the mdev device and do the vhost
Re: [PATCH v2] RDMA/core: Fix race when resolving IP address
On Fri, Jun 28, 2019 at 2:20 PM Dag Moxnes wrote:
>
> Use neighbour lock when copying MAC address from neighbour data struct
> in dst_fetch_ha.
>
> When not using the lock, it is possible for the function to race with
> neigh_update, causing it to copy an invalid MAC address.
>
> It is possible to provoke this error by calling rdma_resolve_addr in a
> tight loop, while deleting the corresponding ARP entry in another tight
> loop.
>
> Signed-off-by: Dag Moxnes
> Signed-off-by: Håkon Bugge
>
> ---
> v1 -> v2:
>* Modified implementation to improve readability
> ---
> drivers/infiniband/core/addr.c | 9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/infiniband/core/addr.c b/drivers/infiniband/core/addr.c
> index 2f7d141598..51323ffbc5 100644
> --- a/drivers/infiniband/core/addr.c
> +++ b/drivers/infiniband/core/addr.c
> @@ -333,11 +333,14 @@ static int dst_fetch_ha(const struct dst_entry *dst,
> if (!n)
> return -ENODATA;
>
> - if (!(n->nud_state & NUD_VALID)) {
> + read_lock_bh(>lock);
> + if (n->nud_state & NUD_VALID) {
> + memcpy(dev_addr->dst_dev_addr, n->ha, MAX_ADDR_LEN);
> + read_unlock_bh(>lock);
> + } else {
> + read_unlock_bh(>lock);
> neigh_event_send(n, NULL);
> ret = -ENODATA;
> - } else {
> - memcpy(dev_addr->dst_dev_addr, n->ha, MAX_ADDR_LEN);
> }
>
> neigh_release(n);
> --
> 2.20.1
>
Reviewed-by: Parav Pandit
A sample trace such as below in commit message would be good to have.
Or the similar one that you noticed with ARP delete sequence.
neigh_changeaddr()
neigh_flush_dev()
n->nud_state = NUD_NOARP;
Having some issues with office outlook, so replying via gmail.
Re: [PATCH v2 5/7] x86/mm, tracing: Fix CR2 corruption
On Fri, Jul 5, 2019 at 5:03 AM Peter Zijlstra wrote: > > Despire the current efforts to read CR2 before tracing happens there > still exist a number of possible holes: So this whole series disturbs me for the simple reason that I thought tracing was supposed to save/restore cr2 and make it unnecessary to worry about this in non-tracing code. That is very much what the NMI code explicitly does. Why shouldn't all the other tracing code do the same thing in case they can take page faults? So I don't think the patches are wrong per se, but this seems to solve it at the wrong level. Linus
Re: [PATCH] fs: ocfs2: dlmglue: Unneeded variable: "status"
On 19/7/3 02:32, Hariprasad Kelam wrote:
> fix below issue reported by coccicheck
> fs/ocfs2/dlmglue.c:4410:5-11: Unneeded variable: "status". Return "0" on
> line 4428
>
> We can not change return type of ocfs2_downconvert_thread as its
> registered as callback of kthread_create.
>
> Signed-off-by: Hariprasad Kelam
Reviewed-by: Joseph Qi
> ---
> fs/ocfs2/dlmglue.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/fs/ocfs2/dlmglue.c b/fs/ocfs2/dlmglue.c
> index dc987f5..1420723 100644
> --- a/fs/ocfs2/dlmglue.c
> +++ b/fs/ocfs2/dlmglue.c
> @@ -4407,7 +4407,6 @@ static int ocfs2_downconvert_thread_should_wake(struct
> ocfs2_super *osb)
>
> static int ocfs2_downconvert_thread(void *arg)
> {
> - int status = 0;
> struct ocfs2_super *osb = arg;
>
> /* only quit once we've been asked to stop and there is no more
> @@ -4425,7 +4424,7 @@ static int ocfs2_downconvert_thread(void *arg)
> }
>
> osb->dc_task = NULL;
> - return status;
> + return 0;
> }
>
> void ocfs2_wake_downconvert_thread(struct ocfs2_super *osb)
>
Re: [PATCH v2] checkpatch: add several Kconfig default value tests
On Thu, 2019-07-04 at 11:49 -0700, Joe Perches wrote:
> On Thu, 2019-07-04 at 17:40 +0800, Miles Chen wrote:
> > This change adds 3 Kconfig default value tests:
> []
> > diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> []
> > @@ -3005,6 +3005,27 @@ sub process {
> > "Use of boolean is deprecated, please use bool
> > instead.\n" . $herecurr);
> > }
> >
> > +# discourage redundant 'default n'
> > + if ($realfile =~ /Kconfig/ &&
> > + $line =~ /^\+\s*default n$/) {
> > + WARN("DEFAULT_VALUE_STYLE",
> > +"'default n' is the default value, no need to
> > write it explicitly.\n" . $herecurr);
> > + }
> > +
> > +# discourage quote: use default [ynm], not default "[ynm]"
> > + if ($realfile =~ /Kconfig/ &&
> > + $rawline =~ /^\+\s*default\s*"[ynm]"/) {
> > + WARN("DEFAULT_VALUE_STYLE",
> > +"Use default [ynm] instead of default \"[ynm]\"\n"
> > . $herecurr);
> > + }
> > +
> > +# discourage default \!?EXPERT
> > + if ($realfile =~ /Kconfig/ &&
> > + $line =~ /^\+\s*default \!?EXPERT/) {
> > + WARN("DEFAULT_VALUE_STYLE",
> > +"Avoid default turn on kernel configs by default
> > !?EXPERT\n" . $herecurr);
> > + }
> > +
>
> I'd prefer to create a block for all the Kconfig file tests and
> avoid multiply determining if the filename includes Kconfig so
> the script runs a bit faster.
>
Thanks for your comments.
yes, the script runs faster this way.
> Also some trivial changes to the added tests with added --fix
> capability. Something like:
Thanks for posting the patch, I'll verify it and post as patch v3.
> ---
> scripts/checkpatch.pl | 139
> ++
> 1 file changed, 85 insertions(+), 54 deletions(-)
>
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index 6cb99ec62000..4780149a8d30 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -2934,60 +2934,98 @@ sub process {
> "Do not include the paragraph about
> writing to the Free Software Foundation's mailing address from the sample GPL
> notice. The FSF has changed addresses in the past, and may do so again. Linux
> already includes a copy of the GPL.\n" . $herevet)
> }
>
> -# check for Kconfig help text having a real description
> -# Only applies when adding the entry originally, after that we do not have
> -# sufficient context to determine whether it is indeed long enough.
> - if ($realfile =~ /Kconfig/ &&
> - # 'choice' is usually the last thing on the line (though
> - # Kconfig supports named choices), so use a word boundary
> - # (\b) rather than a whitespace character (\s)
> - $line =~ /^\+\s*(?:config|menuconfig|choice)\b/) {
> - my $length = 0;
> - my $cnt = $realcnt;
> - my $ln = $linenr + 1;
> - my $f;
> - my $is_start = 0;
> - my $is_end = 0;
> - for (; $cnt > 0 && defined $lines[$ln - 1]; $ln++) {
> - $f = $lines[$ln - 1];
> - $cnt-- if ($lines[$ln - 1] !~ /^-/);
> - $is_end = $lines[$ln - 1] =~ /^\+/;
> -
> - next if ($f =~ /^-/);
> - last if (!$file && $f =~ /^\@\@/);
> -
> - if ($lines[$ln - 1] =~
> /^\+\s*(?:bool|tristate|prompt)\s*["']/) {
> - $is_start = 1;
> - } elsif ($lines[$ln - 1] =~
> /^\+\s*(?:help|---help---)\s*$/) {
> - if ($lines[$ln - 1] =~ "---help---") {
> - WARN("CONFIG_DESCRIPTION",
> - "prefer 'help' over
> '---help---' for new help texts\n" . $herecurr);
> +# Kconfig tests
> + if ($realfile =~ /Kconfig/) {
> + # check for Kconfig help text having a real description
> + # Only applies when adding the entry originally, after
> + # that we do not have sufficient context to determine
> + # whether it is indeed long enough.
> + # 'choice' is usually the last thing on the line (though
> + # Kconfig supports named choices), so use a word
> + # boundary (\b) rather than a whitespace character (\s)
> + if ($line =~ /^\+\s*(?:config|menuconfig|choice)\b/) {
> + my $length = 0;
> + my $cnt = $realcnt;
> + my
RE: [EXT] [BUG BISECT] Net boot fails on VF50 after "dmaengine: fsl-edma: support little endian for edma driver"
Hi Krzysztof, Got it. Thanks for your help Best Regards, Peng >-Original Message- >From: Krzysztof Kozlowski >Sent: 2019年7月4日 20:57 >To: Peng Ma >Cc: Vinod Koul ; dmaeng...@vger.kernel.org; >linux-kernel@vger.kernel.org; Fabio Estevam ; Leo >Li ; Andy Tang >Subject: Re: [EXT] [BUG BISECT] Net boot fails on VF50 after "dmaengine: >fsl-edma: support little endian for edma driver" > >Caution: EXT Email > >On Thu, 4 Jul 2019 at 04:10, Peng Ma wrote: >> >> Hi Krzysztof, >> >> I am sorry, It is my mistake to forget about VF50 used EDMA IP with little >endian. >> The Register(CHCFG0 - CHCFG15) of our platform designed as follows: >> *- >> --* >> | Offset | Big endian Register| Little endian Register| >> |-|--|-| >> | 0x0 | CHCFG0| CHCFG3 | >> |-|--|-| >> | 0x1 | CHCFG1| CHCFG2 | >> |-|--|-| >> | 0x2 | CHCFG2| CHCFG1 | >> |-|--|-| >> | 0x3 | CHCFG3| CHCFG0 | >> |-|--|-| >> | ... |.. | .. | >> |-|--|-| >> | 0xC | CHCFG12 | CHCFG15 | >> |-|--|-| >> | 0xD | CHCFG13 | CHCFG14 | >> |-|--|-| >> | 0xE | CHCFG14 | CHCFG13 | >> |-|--|-| >> | 0xF | CHCFG15 | CHCFG12 | >> *- >> --* >> >> So we need this patch, I make some changes,Please help me to test >> attatchment on VF50 board, Thanks. > >With the patch VF50 boots fine. > >BTW, Colibri VF50 nicely boots from network almost out of the box so it is easy >to add it to automated tests for simple boot tests. This way you do not have to >manually test it on such platform... > >Best regards, >Krzysztof
RE: [EXT] [BUG BISECT] Net boot fails on VF50 after "dmaengine: fsl-edma: support little endian for edma driver"
Hi Fabio, Thanks very much for your suggestion, I will do some changes then to Send upstream review. Best Regards, Peng >-Original Message- >From: Fabio Estevam >Sent: 2019年7月4日 20:07 >To: Peng Ma >Cc: Krzysztof Kozłowski ; Vinod Koul >; dmaeng...@vger.kernel.org; >linux-kernel@vger.kernel.org; Fabio Estevam ; Leo >Li ; Andy Tang >Subject: Re: [EXT] [BUG BISECT] Net boot fails on VF50 after "dmaengine: >fsl-edma: support little endian for edma driver" > >Caution: EXT Email > >Hi Peng, > >On Wed, Jul 3, 2019 at 11:10 PM Peng Ma wrote: > >> So we need this patch, I make some changes,Please help me to test >attatchment on VF50 board, > >You need to change the Subject to something like: > >Subject: [PATCH] dmaengine: fsl-edma: Add support for LS1028A > >Also, in the commit log, please change "Our platforms" to "LS1028A" > >Please remove this part: "Current eDMA driver does not support Little endian" > >,which is not correct.
Re: [PATCH 2/2] usbip: Implement SG support to vhci
On Fri, 5 Jul 2019, Suwan Kim wrote: > On Mon, Jun 24, 2019 at 01:24:15PM -0400, Alan Stern wrote: > > On Mon, 24 Jun 2019, Suwan Kim wrote: > > > > > > > + hcd->self.sg_tablesize = ~0; > > > > > + hcd->self.no_sg_constraint = 1; > > > > > > > > You probably shouldn't do this, for two reasons. First, sg_tablesize > > > > of the server's HCD may be smaller than ~0. If the client's value is > > > > larger than the server's, a transfer could be accepted on the client > > > > but then fail on the server because the SG list was too big. > > > > On the other hand, I don't know of any examples where an HCD has > > sg_tablesize set to anything other than 0 or ~0. vhci-hcd might end up > > being the only one. > > > > > > Also, you may want to restrict the size of SG transfers even further, > > > > so that you don't have to allocate a tremendous amount of memory all at > > > > once on the server. An SG transfer can be quite large. I don't know > > > > what a reasonable limit would be -- 16 perhaps? > > > > > > Is there any reason why you think that 16 is ok? Or Can I set this > > > value as the smallest value of all HC? I think that sg_tablesize > > > cannot be a variable value because vhci interacts with different > > > machines and all machines has different sg_tablesize value. > > > > I didn't have any good reason for picking 16. Using the smallest value > > of all the HCDs seems like a good idea. > > I also have not seen an HCD with a value other than ~0 or 0 except for > whci which uses 2048, but is not 2048 the maximum value of sg_tablesize? > If so, ~0 is the minimum value of sg_tablesize that supports SG. Then > can vhci use ~0 if we don't consider memory pressure of the server? > > If all of the HCDs supporting SG have ~0 as sg_tablesize value, I > think that whether we use an HCD locally or remotely, the degree of > memory pressure is same in both local and remote usage. You have a lot of leeway. For example, there's no reason a single SG transfer on the client has to correspond to a single SG transfer on the host. In theory the client's vhci-hcd can break a large SG transfer up into a bunch of smaller pieces and send them to the host one by one, then reassemble the results to complete the original transfer. That way the memory pressure on the host would be a lot smaller than on the client. Alan Stern
Re: [patch V2 21/25] x86/smp: Enhance native_send_call_func_ipi()
> On Jul 4, 2019, at 8:52 AM, Thomas Gleixner wrote:
>
> Nadav noticed that the cpumask allocations in native_send_call_func_ipi()
> are noticeable in microbenchmarks.
>
> Use the new cpumask_or_equal() function to simplify the decision whether
> the supplied target CPU mask is either equal to cpu_online_mask or equal to
> cpu_online_mask except for the CPU on which the function is invoked.
>
> cpumask_or_equal() or's the target mask and the cpumask of the current CPU
> together and compares it to cpu_online_mask.
>
> If the result is false, use the mask based IPI function, otherwise check
> whether the current CPU is set in the target mask and invoke either the
> send_IPI_all() or the send_IPI_allbutselt() APIC callback.
>
> Make the shorthand decision also depend on the static key which enables
> shorthand mode. That allows to remove the extra cpumask comparison with
> cpu_callout_mask.
>
> Reported-by: Nadav Amit
> Signed-off-by: Thomas Gleixner
> ---
> V2: New patch
> ---
> arch/x86/kernel/apic/ipi.c | 24 +++-
> 1 file changed, 11 insertions(+), 13 deletions(-)
>
> --- a/arch/x86/kernel/apic/ipi.c
> +++ b/arch/x86/kernel/apic/ipi.c
> @@ -83,23 +83,21 @@ void native_send_call_func_single_ipi(in
>
> void native_send_call_func_ipi(const struct cpumask *mask)
> {
> - cpumask_var_t allbutself;
> + if (static_branch_likely(_use_ipi_shorthand)) {
> + unsigned int cpu = smp_processor_id();
>
> - if (!alloc_cpumask_var(, GFP_ATOMIC)) {
> - apic->send_IPI_mask(mask, CALL_FUNCTION_VECTOR);
> + if (!cpumask_or_equal(mask, cpumask_of(cpu), cpu_online_mask))
> + goto sendmask;
> +
> + if (cpumask_test_cpu(cpu, mask))
> + apic->send_IPI_all(CALL_FUNCTION_VECTOR);
> + else if (num_online_cpus() > 1)
> + apic->send_IPI_allbutself(CALL_FUNCTION_VECTOR);
> return;
> }
>
> - cpumask_copy(allbutself, cpu_online_mask);
> - cpumask_clear_cpu(smp_processor_id(), allbutself);
> -
> - if (cpumask_equal(mask, allbutself) &&
> - cpumask_equal(cpu_online_mask, cpu_callout_mask))
> - apic->send_IPI_allbutself(CALL_FUNCTION_VECTOR);
> - else
> - apic->send_IPI_mask(mask, CALL_FUNCTION_VECTOR);
> -
> - free_cpumask_var(allbutself);
> +sendmask:
> + apic->send_IPI_mask(mask, CALL_FUNCTION_VECTOR);
> }
>
> #endif /* CONFIG_SMP */
It does look better and simpler than my solution.
Re: linux-next: build failure after merge of the clk tree
Hi all,
On Tue, 2 Jul 2019 12:03:50 +1000 Stephen Rothwell
wrote:
>
> This at least passes my (few) build tests (this will be in linux-next
> today):
>
> From: Stephen Rothwell
> Date: Tue, 2 Jul 2019 11:53:07 +1000
> Subject: [PATCH] clk: consoldiate the __clk_get_hw() declarations
>
> Without this we were getting errors like:
>
> In file included from drivers/clk/clkdev.c:22:0:
> drivers/clk/clk.h:36:23: error: static declaration of '__clk_get_hw' follows
> non-static declaration
> include/linux/clk-provider.h:808:16: note: previous declaration of
> '__clk_get_hw' was here
>
> Fixes: 59fcdce425b7 ("clk: Remove ifdef for COMMON_CLK in clk-provider.h")
> fixes: 73e0e496afda ("clkdev: Always allocate a struct clk and call
> __clk_get() w/ CCF")
> Signed-off-by: Stephen Rothwell
> ---
> drivers/clk/clk.h | 4
> drivers/clk/imx/clk-imx6q.c | 1 +
> drivers/clk/imx/clk-imx6sll.c | 1 +
> drivers/clk/imx/clk-imx6sx.c | 1 +
> drivers/clk/imx/clk-imx6ul.c | 1 +
> drivers/clk/imx/clk-imx7d.c | 1 +
> drivers/clk/imx/clk.c | 1 +
> include/linux/clk-provider.h | 7 +++
> 8 files changed, 13 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/clk/clk.h b/drivers/clk/clk.h
> index d8400d623b34..2d801900cad5 100644
> --- a/drivers/clk/clk.h
> +++ b/drivers/clk/clk.h
> @@ -33,10 +33,6 @@ clk_hw_create_clk(struct device *dev, struct clk_hw *hw,
> const char *dev_id,
> {
> return (struct clk *)hw;
> }
> -static struct clk_hw *__clk_get_hw(struct clk *clk)
> -{
> - return (struct clk_hw *)clk;
> -}
> static inline void __clk_put(struct clk *clk) { }
>
> #endif
> diff --git a/drivers/clk/imx/clk-imx6q.c b/drivers/clk/imx/clk-imx6q.c
> index 4e61f5189a1f..466561fb8925 100644
> --- a/drivers/clk/imx/clk-imx6q.c
> +++ b/drivers/clk/imx/clk-imx6q.c
> @@ -14,6 +14,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> diff --git a/drivers/clk/imx/clk-imx6sll.c b/drivers/clk/imx/clk-imx6sll.c
> index 342dcc58ac16..5f3e92c09a5e 100644
> --- a/drivers/clk/imx/clk-imx6sll.c
> +++ b/drivers/clk/imx/clk-imx6sll.c
> @@ -7,6 +7,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> diff --git a/drivers/clk/imx/clk-imx6sx.c b/drivers/clk/imx/clk-imx6sx.c
> index fb58479eaa68..2ada63e6ba16 100644
> --- a/drivers/clk/imx/clk-imx6sx.c
> +++ b/drivers/clk/imx/clk-imx6sx.c
> @@ -12,6 +12,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> diff --git a/drivers/clk/imx/clk-imx6ul.c b/drivers/clk/imx/clk-imx6ul.c
> index 95ca895c8776..d860a244363a 100644
> --- a/drivers/clk/imx/clk-imx6ul.c
> +++ b/drivers/clk/imx/clk-imx6ul.c
> @@ -12,6 +12,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> diff --git a/drivers/clk/imx/clk-imx7d.c b/drivers/clk/imx/clk-imx7d.c
> index c6d86700a080..c1efb061d237 100644
> --- a/drivers/clk/imx/clk-imx7d.c
> +++ b/drivers/clk/imx/clk-imx7d.c
> @@ -12,6 +12,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> diff --git a/drivers/clk/imx/clk.c b/drivers/clk/imx/clk.c
> index 76457b2bd7f0..f628071f6605 100644
> --- a/drivers/clk/imx/clk.c
> +++ b/drivers/clk/imx/clk.c
> @@ -1,5 +1,6 @@
> // SPDX-License-Identifier: GPL-2.0
> #include
> +#include
> #include
> #include
> #include
> diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
> index 0fbf3ccad849..2ae7604783dd 100644
> --- a/include/linux/clk-provider.h
> +++ b/include/linux/clk-provider.h
> @@ -805,7 +805,14 @@ void devm_clk_hw_unregister(struct device *dev, struct
> clk_hw *hw);
> /* helper functions */
> const char *__clk_get_name(const struct clk *clk);
> const char *clk_hw_get_name(const struct clk_hw *hw);
> +#ifdef CONFIG_COMMON_CLK
> struct clk_hw *__clk_get_hw(struct clk *clk);
> +#else
> +static inline struct clk_hw *__clk_get_hw(struct clk *clk)
> +{
> + return (struct clk_hw *)clk;
> +}
> +#endif
> unsigned int clk_hw_get_num_parents(const struct clk_hw *hw);
> struct clk_hw *clk_hw_get_parent(const struct clk_hw *hw);
> struct clk_hw *clk_hw_get_parent_by_index(const struct clk_hw *hw,
I am still applying this ...
--
Cheers,
Stephen Rothwell
pgpvVzIirFFGH.pgp
Description: OpenPGP digital signature
Re: [PATCH v2 31/35] ocfs2: Use kmemdup rather than duplicating its implementation
On 19/7/4 00:31, Fuqian Huang wrote:
> kmemdup is introduced to duplicate a region of memory in a neat way.
> Rather than kmalloc/kzalloc + memcpy, which the programmer needs to
> write the size twice (sometimes lead to mistakes), kmemdup improves
> readability, leads to smaller code and also reduce the chances of mistakes.
> Suggestion to use kmemdup rather than using kmalloc/kzalloc + memcpy.
>
> Signed-off-by: Fuqian Huang
Looks good.
Reviewed-by: Joseph Qi
> ---
> Changes in v2:
> - Fix a typo in commit message (memset -> memcpy)
>
> fs/ocfs2/alloc.c | 8 +++-
> fs/ocfs2/localalloc.c | 6 ++
> 2 files changed, 5 insertions(+), 9 deletions(-)
>
> diff --git a/fs/ocfs2/alloc.c b/fs/ocfs2/alloc.c
> index d1348fc4ca6d..d4911d70c326 100644
> --- a/fs/ocfs2/alloc.c
> +++ b/fs/ocfs2/alloc.c
> @@ -6191,17 +6191,15 @@ int ocfs2_begin_truncate_log_recovery(struct
> ocfs2_super *osb,
> if (le16_to_cpu(tl->tl_used)) {
> trace_ocfs2_truncate_log_recovery_num(le16_to_cpu(tl->tl_used));
>
> - *tl_copy = kmalloc(tl_bh->b_size, GFP_KERNEL);
> + /* Assuming the write-out below goes well, this copy
> + * will be passed back to recovery for processing. */
> + *tl_copy = kmemdup(tl_bh->b_data, tl_bh->b_size, GFP_KERNEL);
> if (!(*tl_copy)) {
> status = -ENOMEM;
> mlog_errno(status);
> goto bail;
> }
>
> - /* Assuming the write-out below goes well, this copy
> - * will be passed back to recovery for processing. */
> - memcpy(*tl_copy, tl_bh->b_data, tl_bh->b_size);
> -
> /* All we need to do to clear the truncate log is set
>* tl_used. */
> tl->tl_used = 0;
> diff --git a/fs/ocfs2/localalloc.c b/fs/ocfs2/localalloc.c
> index f03674afbd30..158e5af767fd 100644
> --- a/fs/ocfs2/localalloc.c
> +++ b/fs/ocfs2/localalloc.c
> @@ -424,12 +424,11 @@ void ocfs2_shutdown_local_alloc(struct ocfs2_super *osb)
> bh = osb->local_alloc_bh;
> alloc = (struct ocfs2_dinode *) bh->b_data;
>
> - alloc_copy = kmalloc(bh->b_size, GFP_NOFS);
> + alloc_copy = kmemdup(alloc, bh->b_size, GFP_NOFS);
> if (!alloc_copy) {
> status = -ENOMEM;
> goto out_commit;
> }
> - memcpy(alloc_copy, alloc, bh->b_size);
>
> status = ocfs2_journal_access_di(handle, INODE_CACHE(local_alloc_inode),
>bh, OCFS2_JOURNAL_ACCESS_WRITE);
> @@ -1272,13 +1271,12 @@ static int ocfs2_local_alloc_slide_window(struct
> ocfs2_super *osb,
>* local alloc shutdown won't try to double free main bitmap
>* bits. Make a copy so the sync function knows which bits to
>* free. */
> - alloc_copy = kmalloc(osb->local_alloc_bh->b_size, GFP_NOFS);
> + alloc_copy = kmemdup(alloc, osb->local_alloc_bh->b_size, GFP_NOFS);
> if (!alloc_copy) {
> status = -ENOMEM;
> mlog_errno(status);
> goto bail;
> }
> - memcpy(alloc_copy, alloc, osb->local_alloc_bh->b_size);
>
> status = ocfs2_journal_access_di(handle,
>INODE_CACHE(local_alloc_inode),
>
Re: [PATCH 05/10] sched,fair: remove cfs rqs from leaf_cfs_rq_list bottom up
On Thu, 2019-07-04 at 11:33 +0200, Vincent Guittot wrote: > On Fri, 28 Jun 2019 at 22:49, Rik van Riel wrote: > > Reducing the overhead of the CPU controller is achieved by not > > walking > > all the sched_entities every time a task is enqueued or dequeued. > > @@ -7687,6 +7700,10 @@ static inline bool cfs_rq_is_decayed(struct > > cfs_rq *cfs_rq) > > if (cfs_rq->avg.util_sum) > > return false; > > > > + /* Remove decayed parents once their decayed children are > > gone. */ > > + if (cfs_rq->children_on_list) > > I'm not sure that you really need to count whether childrens are on > the list. > Instead you can take advantage of the list ordering and you only have > to test if the previous cfs_rq in the list is a child. If it's not > then there is no more child > > and you can remove the new field children_on_list and inc/dec it Good suggestion. I'll do that for v3. Thank you. -- All Rights Reversed. signature.asc Description: This is a digitally signed message part
Re: [PATCH 1/2] scsi_host: add support for request batching
On Mon, Jun 3, 2019 at 4:16 PM Paolo Bonzini wrote: > > On 31/05/19 05:27, Ming Lei wrote: > > It should be fine to implement scsi_commit_rqs() as: > > > > if (shost->hostt->commit_rqs) > >shost->hostt->commit_rqs(shost, hctx->queue_num); > > > > then scsi_mq_ops_no_commit can be saved. > > > > Because .commit_rqs() is only called when BLK_STS_*_RESOURCE is > > returned from scsi_queue_rq(), at that time shost->hostt->commit_rqs should > > have been hit from cache given .queuecommand is called via > > host->hostt->queuecommand. > > This is not about d-cache, it's about preserving the heuristics that > blk-mq applies depending on whether commit_rqs is there or not. Fair enough, at least difference would be made by the check in blk_mq_make_request() if scsi_commit_rqs is provided unconditionally, so looks fine: Reviewed-by: Ming Lei Thanks, Ming Lei
[PATCH v2 07/11] fpga: dfl: afu: export __port_enable/disable function.
As these two functions are used by other private features. e.g.
in error reporting private feature, it requires to check port status
and reset port for error clearing.
Signed-off-by: Xu Yilun
Signed-off-by: Wu Hao
Acked-by: Moritz Fischer
Acked-by: Alan Tull
Signed-off-by: Moritz Fischer
---
v2: rebased.
---
drivers/fpga/dfl-afu-main.c | 25 ++---
drivers/fpga/dfl-afu.h | 3 +++
2 files changed, 17 insertions(+), 11 deletions(-)
diff --git a/drivers/fpga/dfl-afu-main.c b/drivers/fpga/dfl-afu-main.c
index fbd9553..22d294b 100644
--- a/drivers/fpga/dfl-afu-main.c
+++ b/drivers/fpga/dfl-afu-main.c
@@ -22,14 +22,16 @@
#include "dfl-afu.h"
/**
- * port_enable - enable a port
+ * __port_enable - enable a port
* @pdev: port platform device.
*
* Enable Port by clear the port soft reset bit, which is set by default.
* The AFU is unable to respond to any MMIO access while in reset.
- * port_enable function should only be used after port_disable function.
+ * __port_enable function should only be used after __port_disable function.
+ *
+ * The caller needs to hold lock for protection.
*/
-static void port_enable(struct platform_device *pdev)
+void __port_enable(struct platform_device *pdev)
{
struct dfl_feature_platform_data *pdata = dev_get_platdata(>dev);
void __iomem *base;
@@ -52,13 +54,14 @@ static void port_enable(struct platform_device *pdev)
#define RST_POLL_TIMEOUT 1000 /* us */
/**
- * port_disable - disable a port
+ * __port_disable - disable a port
* @pdev: port platform device.
*
- * Disable Port by setting the port soft reset bit, it puts the port into
- * reset.
+ * Disable Port by setting the port soft reset bit, it puts the port into
reset.
+ *
+ * The caller needs to hold lock for protection.
*/
-static int port_disable(struct platform_device *pdev)
+int __port_disable(struct platform_device *pdev)
{
struct dfl_feature_platform_data *pdata = dev_get_platdata(>dev);
void __iomem *base;
@@ -104,9 +107,9 @@ static int __port_reset(struct platform_device *pdev)
{
int ret;
- ret = port_disable(pdev);
+ ret = __port_disable(pdev);
if (!ret)
- port_enable(pdev);
+ __port_enable(pdev);
return ret;
}
@@ -806,9 +809,9 @@ static int port_enable_set(struct platform_device *pdev,
bool enable)
mutex_lock(>lock);
if (enable)
- port_enable(pdev);
+ __port_enable(pdev);
else
- ret = port_disable(pdev);
+ ret = __port_disable(pdev);
mutex_unlock(>lock);
return ret;
diff --git a/drivers/fpga/dfl-afu.h b/drivers/fpga/dfl-afu.h
index 0c7630a..35e60c5 100644
--- a/drivers/fpga/dfl-afu.h
+++ b/drivers/fpga/dfl-afu.h
@@ -79,6 +79,9 @@ struct dfl_afu {
struct dfl_feature_platform_data *pdata;
};
+void __port_enable(struct platform_device *pdev);
+int __port_disable(struct platform_device *pdev);
+
void afu_mmio_region_init(struct dfl_feature_platform_data *pdata);
int afu_mmio_region_add(struct dfl_feature_platform_data *pdata,
u32 region_index, u64 region_size, u64 phys, u32 flags);
--
1.8.3.1
[PATCH v2 09/11] fpga: dfl: afu: add STP (SignalTap) support
STP (SignalTap) is one of the private features under the port for
debugging. This patch adds private feature driver support for it
to allow userspace applications to mmap related mmio region and
provide STP service.
Signed-off-by: Xu Yilun
Signed-off-by: Wu Hao
Acked-by: Moritz Fischer
Acked-by: Alan Tull
Signed-off-by: Moritz Fischer
---
drivers/fpga/dfl-afu-main.c | 34 ++
1 file changed, 34 insertions(+)
diff --git a/drivers/fpga/dfl-afu-main.c b/drivers/fpga/dfl-afu-main.c
index 15dd4cb..395f96e 100644
--- a/drivers/fpga/dfl-afu-main.c
+++ b/drivers/fpga/dfl-afu-main.c
@@ -514,6 +514,36 @@ static void port_afu_uinit(struct platform_device *pdev,
.uinit = port_afu_uinit,
};
+static int port_stp_init(struct platform_device *pdev,
+struct dfl_feature *feature)
+{
+ struct resource *res = >resource[feature->resource_index];
+
+ dev_dbg(>dev, "PORT STP Init.\n");
+
+ return afu_mmio_region_add(dev_get_platdata(>dev),
+ DFL_PORT_REGION_INDEX_STP,
+ resource_size(res), res->start,
+ DFL_PORT_REGION_MMAP | DFL_PORT_REGION_READ |
+ DFL_PORT_REGION_WRITE);
+}
+
+static void port_stp_uinit(struct platform_device *pdev,
+ struct dfl_feature *feature)
+{
+ dev_dbg(>dev, "PORT STP UInit.\n");
+}
+
+static const struct dfl_feature_id port_stp_id_table[] = {
+ {.id = PORT_FEATURE_ID_STP,},
+ {0,}
+};
+
+static const struct dfl_feature_ops port_stp_ops = {
+ .init = port_stp_init,
+ .uinit = port_stp_uinit,
+};
+
static struct dfl_feature_driver port_feature_drvs[] = {
{
.id_table = port_hdr_id_table,
@@ -528,6 +558,10 @@ static void port_afu_uinit(struct platform_device *pdev,
.ops = _err_ops,
},
{
+ .id_table = port_stp_id_table,
+ .ops = _stp_ops,
+ },
+ {
.ops = NULL,
}
};
--
1.8.3.1
[PATCH v2 00/11] FPGA DFL updates
Hi Greg / Moritz This is v2 patchset which adds more features to FPGA DFL. This patchset is made on top of patch[1] and char-misc-next tree. Documentation patch for DFL is dropped from this patchset, and will resubmit it later to avoid conflict. Main changes from v1: - remove DRV/MODULE_VERSION modifications. (patch #1, #3, #4, #6) - remove argsz from new ioctls. (patch #2) - replace sysfs_create/remove_* with device_add/remove_* for sysfs entries. (patch #5, #8, #11) [1] [PATCH] fpga: dfl: use driver core functions, not sysfs ones. https://lkml.org/lkml/2019/7/4/36 Wu Hao (11): fpga: dfl: fme: support 512bit data width PR fpga: dfl: fme: add DFL_FPGA_FME_PORT_RELEASE/ASSIGN ioctl support. fpga: dfl: pci: enable SRIOV support. fpga: dfl: afu: add AFU state related sysfs interfaces fpga: dfl: afu: add userclock sysfs interfaces. fpga: dfl: add id_table for dfl private feature driver fpga: dfl: afu: export __port_enable/disable function. fpga: dfl: afu: add error reporting support. fpga: dfl: afu: add STP (SignalTap) support fpga: dfl: fme: add capability sysfs interfaces fpga: dfl: fme: add global error reporting support Documentation/ABI/testing/sysfs-platform-dfl-fme | 98 ++ Documentation/ABI/testing/sysfs-platform-dfl-port | 104 ++ drivers/fpga/Makefile | 3 +- drivers/fpga/dfl-afu-error.c | 225 + drivers/fpga/dfl-afu-main.c | 328 +- drivers/fpga/dfl-afu.h| 7 + drivers/fpga/dfl-fme-error.c | 385 ++ drivers/fpga/dfl-fme-main.c | 93 +- drivers/fpga/dfl-fme-mgr.c| 110 ++- drivers/fpga/dfl-fme-pr.c | 50 ++- drivers/fpga/dfl-fme.h| 7 +- drivers/fpga/dfl-pci.c| 39 +++ drivers/fpga/dfl.c| 166 +- drivers/fpga/dfl.h| 54 ++- include/uapi/linux/fpga-dfl.h | 19 ++ 15 files changed, 1617 insertions(+), 71 deletions(-) create mode 100644 drivers/fpga/dfl-afu-error.c create mode 100644 drivers/fpga/dfl-fme-error.c -- 1.8.3.1
[PATCH v2 01/11] fpga: dfl: fme: support 512bit data width PR
In early partial reconfiguration private feature, it only
supports 32bit data width when writing data to hardware for
PR. 512bit data width PR support is an important optimization
for some specific solutions (e.g. XEON with FPGA integrated),
it allows driver to use AVX512 instruction to improve the
performance of partial reconfiguration. e.g. programming one
100MB bitstream image via this 512bit data width PR hardware
only takes ~300ms, but 32bit revision requires ~3s per test
result.
Please note now this optimization is only done on revision 2
of this PR private feature which is only used in integrated
solution that AVX512 is always supported. This revision 2
hardware doesn't support 32bit PR.
Signed-off-by: Ananda Ravuri
Signed-off-by: Xu Yilun
Signed-off-by: Wu Hao
Acked-by: Alan Tull
Signed-off-by: Moritz Fischer
---
v2: remove DRV/MODULE_VERSION modifications
---
drivers/fpga/dfl-fme-mgr.c | 110 ++---
drivers/fpga/dfl-fme-pr.c | 43 +++---
drivers/fpga/dfl-fme.h | 2 +
drivers/fpga/dfl.h | 5 +++
4 files changed, 129 insertions(+), 31 deletions(-)
diff --git a/drivers/fpga/dfl-fme-mgr.c b/drivers/fpga/dfl-fme-mgr.c
index b3f7eee..46e17f0 100644
--- a/drivers/fpga/dfl-fme-mgr.c
+++ b/drivers/fpga/dfl-fme-mgr.c
@@ -22,6 +22,7 @@
#include
#include
+#include "dfl.h"
#include "dfl-fme-pr.h"
/* FME Partial Reconfiguration Sub Feature Register Set */
@@ -30,6 +31,7 @@
#define FME_PR_STS 0x10
#define FME_PR_DATA0x18
#define FME_PR_ERR 0x20
+#define FME_PR_512_DATA0x40 /* Data Register for 512bit
datawidth PR */
#define FME_PR_INTFC_ID_L 0xA8
#define FME_PR_INTFC_ID_H 0xB0
@@ -67,8 +69,43 @@
#define PR_WAIT_TIMEOUT 800
#define PR_HOST_STATUS_IDLE0
+#if defined(CONFIG_X86) && defined(CONFIG_AS_AVX512)
+
+#include
+#include
+
+static inline int is_cpu_avx512_enabled(void)
+{
+ return cpu_feature_enabled(X86_FEATURE_AVX512F);
+}
+
+static inline void copy512(const void *src, void __iomem *dst)
+{
+ kernel_fpu_begin();
+
+ asm volatile("vmovdqu64 (%0), %%zmm0;"
+"vmovntdq %%zmm0, (%1);"
+:
+: "r"(src), "r"(dst)
+: "memory");
+
+ kernel_fpu_end();
+}
+#else
+static inline int is_cpu_avx512_enabled(void)
+{
+ return 0;
+}
+
+static inline void copy512(const void *src, void __iomem *dst)
+{
+ WARN_ON_ONCE(1);
+}
+#endif
+
struct fme_mgr_priv {
void __iomem *ioaddr;
+ unsigned int pr_datawidth;
u64 pr_error;
};
@@ -169,7 +206,7 @@ static int fme_mgr_write(struct fpga_manager *mgr,
struct fme_mgr_priv *priv = mgr->priv;
void __iomem *fme_pr = priv->ioaddr;
u64 pr_ctrl, pr_status, pr_data;
- int delay = 0, pr_credit, i = 0;
+ int ret = 0, delay = 0, pr_credit;
dev_dbg(dev, "start request\n");
@@ -181,9 +218,9 @@ static int fme_mgr_write(struct fpga_manager *mgr,
/*
* driver can push data to PR hardware using PR_DATA register once HW
-* has enough pr_credit (> 1), pr_credit reduces one for every 32bit
-* pr data write to PR_DATA register. If pr_credit <= 1, driver needs
-* to wait for enough pr_credit from hardware by polling.
+* has enough pr_credit (> 1), pr_credit reduces one for every pr data
+* width write to PR_DATA register. If pr_credit <= 1, driver needs to
+* wait for enough pr_credit from hardware by polling.
*/
pr_status = readq(fme_pr + FME_PR_STS);
pr_credit = FIELD_GET(FME_PR_STS_PR_CREDIT, pr_status);
@@ -192,7 +229,8 @@ static int fme_mgr_write(struct fpga_manager *mgr,
while (pr_credit <= 1) {
if (delay++ > PR_WAIT_TIMEOUT) {
dev_err(dev, "PR_CREDIT timeout\n");
- return -ETIMEDOUT;
+ ret = -ETIMEDOUT;
+ goto done;
}
udelay(1);
@@ -200,21 +238,27 @@ static int fme_mgr_write(struct fpga_manager *mgr,
pr_credit = FIELD_GET(FME_PR_STS_PR_CREDIT, pr_status);
}
- if (count < 4) {
- dev_err(dev, "Invalid PR bitstream size\n");
- return -EINVAL;
+ WARN_ON(count < priv->pr_datawidth);
+
+ switch (priv->pr_datawidth) {
+ case 4:
+ pr_data = FIELD_PREP(FME_PR_DATA_PR_DATA_RAW,
+*(u32 *)buf);
+ writeq(pr_data, fme_pr + FME_PR_DATA);
+ break;
+ case 64:
+ copy512(buf, fme_pr + FME_PR_512_DATA);
+ break;
+ default:
+
[PATCH v2 02/11] fpga: dfl: fme: add DFL_FPGA_FME_PORT_RELEASE/ASSIGN ioctl support.
In order to support virtualization usage via PCIe SRIOV, this patch
adds two ioctls under FPGA Management Engine (FME) to release and
assign back the port device. In order to safely turn Port from PF
into VF and enable PCIe SRIOV, it requires user to invoke this
PORT_RELEASE ioctl to release port firstly to remove userspace
interfaces, and then configure the PF/VF access register in FME.
After disable SRIOV, it requires user to invoke this PORT_ASSIGN
ioctl to attach the port back to PF.
Ioctl interfaces:
* DFL_FPGA_FME_PORT_RELEASE
Release platform device of given port, it deletes port platform
device to remove related userspace interfaces on PF, then
configures PF/VF access mode to VF.
* DFL_FPGA_FME_PORT_ASSIGN
Assign platform device of given port back to PF, it configures
PF/VF access mode to PF, then adds port platform device back to
re-enable related userspace interfaces on PF.
Signed-off-by: Zhang Yi Z
Signed-off-by: Xu Yilun
Signed-off-by: Wu Hao
Acked-by: Alan Tull
Acked-by: Moritz Fischer
Signed-off-by: Moritz Fischer
---
v2: remove argsz from ioctls.
---
drivers/fpga/dfl-fme-main.c | 30
drivers/fpga/dfl.c| 107 +-
drivers/fpga/dfl.h| 10
include/uapi/linux/fpga-dfl.h | 19
4 files changed, 154 insertions(+), 12 deletions(-)
diff --git a/drivers/fpga/dfl-fme-main.c b/drivers/fpga/dfl-fme-main.c
index 0be4635..e61e0fe 100644
--- a/drivers/fpga/dfl-fme-main.c
+++ b/drivers/fpga/dfl-fme-main.c
@@ -16,6 +16,7 @@
#include
#include
+#include
#include
#include "dfl.h"
@@ -104,9 +105,38 @@ static void fme_hdr_uinit(struct platform_device *pdev,
device_remove_groups(>dev, fme_hdr_groups);
}
+static long fme_hdr_ioctl_config_port(struct dfl_feature_platform_data *pdata,
+ unsigned long arg, bool release)
+{
+ struct dfl_fpga_cdev *cdev = pdata->dfl_cdev;
+ int port_id;
+
+ if (get_user(port_id, (int __user *)arg))
+ return -EFAULT;
+
+ return dfl_fpga_cdev_config_port(cdev, port_id, release);
+}
+
+static long fme_hdr_ioctl(struct platform_device *pdev,
+ struct dfl_feature *feature,
+ unsigned int cmd, unsigned long arg)
+{
+ struct dfl_feature_platform_data *pdata = dev_get_platdata(>dev);
+
+ switch (cmd) {
+ case DFL_FPGA_FME_PORT_RELEASE:
+ return fme_hdr_ioctl_config_port(pdata, arg, true);
+ case DFL_FPGA_FME_PORT_ASSIGN:
+ return fme_hdr_ioctl_config_port(pdata, arg, false);
+ }
+
+ return -ENODEV;
+}
+
static const struct dfl_feature_ops fme_hdr_ops = {
.init = fme_hdr_init,
.uinit = fme_hdr_uinit,
+ .ioctl = fme_hdr_ioctl,
};
static struct dfl_feature_driver fme_feature_drvs[] = {
diff --git a/drivers/fpga/dfl.c b/drivers/fpga/dfl.c
index 4b66aaa..e04ed45 100644
--- a/drivers/fpga/dfl.c
+++ b/drivers/fpga/dfl.c
@@ -231,16 +231,20 @@ void dfl_fpga_port_ops_del(struct dfl_fpga_port_ops *ops)
*/
int dfl_fpga_check_port_id(struct platform_device *pdev, void *pport_id)
{
- struct dfl_fpga_port_ops *port_ops = dfl_fpga_port_ops_get(pdev);
- int port_id;
+ struct dfl_feature_platform_data *pdata = dev_get_platdata(>dev);
+ struct dfl_fpga_port_ops *port_ops;
+
+ if (pdata->id != FEATURE_DEV_ID_UNUSED)
+ return pdata->id == *(int *)pport_id;
+ port_ops = dfl_fpga_port_ops_get(pdev);
if (!port_ops || !port_ops->get_id)
return 0;
- port_id = port_ops->get_id(pdev);
+ pdata->id = port_ops->get_id(pdev);
dfl_fpga_port_ops_put(port_ops);
- return port_id == *(int *)pport_id;
+ return pdata->id == *(int *)pport_id;
}
EXPORT_SYMBOL_GPL(dfl_fpga_check_port_id);
@@ -474,6 +478,7 @@ static int build_info_commit_dev(struct
build_feature_devs_info *binfo)
pdata->dev = fdev;
pdata->num = binfo->feature_num;
pdata->dfl_cdev = binfo->cdev;
+ pdata->id = FEATURE_DEV_ID_UNUSED;
mutex_init(>lock);
lockdep_set_class_and_name(>lock, _pdata_keys[type],
dfl_pdata_key_strings[type]);
@@ -973,25 +978,27 @@ void dfl_fpga_feature_devs_remove(struct dfl_fpga_cdev
*cdev)
{
struct dfl_feature_platform_data *pdata, *ptmp;
- remove_feature_devs(cdev);
-
mutex_lock(>lock);
- if (cdev->fme_dev) {
- /* the fme should be unregistered. */
- WARN_ON(device_is_registered(cdev->fme_dev));
+ if (cdev->fme_dev)
put_device(cdev->fme_dev);
- }
list_for_each_entry_safe(pdata, ptmp, >port_dev_list, node) {
struct platform_device *port_dev = pdata->dev;
- /* the port should be unregistered. */
- WARN_ON(device_is_registered(_dev->dev));
+
[PATCH v2 08/11] fpga: dfl: afu: add error reporting support.
Error reporting is one important private feature, it reports error
detected on port and accelerated function unit (AFU). It introduces
several sysfs interfaces to allow userspace to check and clear
errors detected by hardware.
Signed-off-by: Xu Yilun
Signed-off-by: Wu Hao
Acked-by: Alan Tull
Signed-off-by: Moritz Fischer
---
v2: switch to device_add/remove_group for sysfs.
---
Documentation/ABI/testing/sysfs-platform-dfl-port | 39
drivers/fpga/Makefile | 1 +
drivers/fpga/dfl-afu-error.c | 225 ++
drivers/fpga/dfl-afu-main.c | 4 +
drivers/fpga/dfl-afu.h| 4 +
5 files changed, 273 insertions(+)
create mode 100644 drivers/fpga/dfl-afu-error.c
diff --git a/Documentation/ABI/testing/sysfs-platform-dfl-port
b/Documentation/ABI/testing/sysfs-platform-dfl-port
index 04ea7f2..4aeca94 100644
--- a/Documentation/ABI/testing/sysfs-platform-dfl-port
+++ b/Documentation/ABI/testing/sysfs-platform-dfl-port
@@ -79,3 +79,42 @@ KernelVersion: 5.3
Contact: Wu Hao
Description: Read-only. Read this file to get the status of issued command
to userclck_freqcntrcmd.
+
+What: /sys/bus/platform/devices/dfl-port.0/errors/revision
+Date: June 2019
+KernelVersion: 5.3
+Contact: Wu Hao
+Description: Read-only. Read this file to get the revision of this error
+ reporting private feature.
+
+What: /sys/bus/platform/devices/dfl-port.0/errors/errors
+Date: June 2019
+KernelVersion: 5.3
+Contact: Wu Hao
+Description: Read-only. Read this file to get errors detected on port and
+ Accelerated Function Unit (AFU).
+
+What: /sys/bus/platform/devices/dfl-port.0/errors/first_error
+Date: June 2019
+KernelVersion: 5.3
+Contact: Wu Hao
+Description: Read-only. Read this file to get the first error detected by
+ hardware.
+
+What: /sys/bus/platform/devices/dfl-port.0/errors/first_malformed_req
+Date: June 2019
+KernelVersion: 5.3
+Contact: Wu Hao
+Description: Read-only. Read this file to get the first malformed request
+ captured by hardware.
+
+What: /sys/bus/platform/devices/dfl-port.0/errors/clear
+Date: June 2019
+KernelVersion: 5.3
+Contact: Wu Hao
+Description: Write-only. Write error code to this file to clear errors.
+ Write fails with -EINVAL if input parsing fails or input error
+ code doesn't match.
+ Write fails with -EBUSY or -ETIMEDOUT if error can't be cleared
+ as hardware is in low power state (-EBUSY) or not responding
+ (-ETIMEDOUT).
diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
index 312b937..7255891 100644
--- a/drivers/fpga/Makefile
+++ b/drivers/fpga/Makefile
@@ -41,6 +41,7 @@ obj-$(CONFIG_FPGA_DFL_AFU)+= dfl-afu.o
dfl-fme-objs := dfl-fme-main.o dfl-fme-pr.o
dfl-afu-objs := dfl-afu-main.o dfl-afu-region.o dfl-afu-dma-region.o
+dfl-afu-objs += dfl-afu-error.o
# Drivers for FPGAs which implement DFL
obj-$(CONFIG_FPGA_DFL_PCI) += dfl-pci.o
diff --git a/drivers/fpga/dfl-afu-error.c b/drivers/fpga/dfl-afu-error.c
new file mode 100644
index 000..9649da8
--- /dev/null
+++ b/drivers/fpga/dfl-afu-error.c
@@ -0,0 +1,225 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Driver for FPGA Accelerated Function Unit (AFU) Error Reporting
+ *
+ * Copyright 2019 Intel Corporation, Inc.
+ *
+ * Authors:
+ * Wu Hao
+ * Xiao Guangrong
+ * Joseph Grecco
+ * Enno Luebbers
+ * Tim Whisonant
+ * Ananda Ravuri
+ * Mitchel Henry
+ */
+
+#include
+
+#include "dfl-afu.h"
+
+#define PORT_ERROR_MASK0x8
+#define PORT_ERROR 0x10
+#define PORT_FIRST_ERROR 0x18
+#define PORT_MALFORMED_REQ00x20
+#define PORT_MALFORMED_REQ10x28
+
+#define ERROR_MASK GENMASK_ULL(63, 0)
+
+/* mask or unmask port errors by the error mask register. */
+static void __port_err_mask(struct device *dev, bool mask)
+{
+ void __iomem *base;
+
+ base = dfl_get_feature_ioaddr_by_id(dev, PORT_FEATURE_ID_ERROR);
+
+ writeq(mask ? ERROR_MASK : 0, base + PORT_ERROR_MASK);
+}
+
+/* clear port errors. */
+static int __port_err_clear(struct device *dev, u64 err)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ void __iomem *base_err, *base_hdr;
+ int ret;
+ u64 v;
+
+ base_err = dfl_get_feature_ioaddr_by_id(dev, PORT_FEATURE_ID_ERROR);
+ base_hdr = dfl_get_feature_ioaddr_by_id(dev, PORT_FEATURE_ID_HEADER);
+
+ /*
+* clear Port Errors
+*
+* - Check for AP6 State
+* - Halt Port by keeping Port in reset
+* - Set PORT Error mask to all 1 to mask errors
+* - Clear all errors
+* - Set Port mask to all 0 to enable errors
+
[PATCH v2 03/11] fpga: dfl: pci: enable SRIOV support.
This patch enables the standard sriov support. It allows user to
enable SRIOV (and VFs), then user could pass through accelerators
(VFs) into virtual machine or use VFs directly in host.
Signed-off-by: Zhang Yi Z
Signed-off-by: Xu Yilun
Signed-off-by: Wu Hao
Acked-by: Alan Tull
Acked-by: Moritz Fischer
Signed-off-by: Moritz Fischer
---
v2: remove DRV/MODULE_VERSION modifications.
---
drivers/fpga/dfl-pci.c | 39 +++
drivers/fpga/dfl.c | 41 +
drivers/fpga/dfl.h | 1 +
3 files changed, 81 insertions(+)
diff --git a/drivers/fpga/dfl-pci.c b/drivers/fpga/dfl-pci.c
index 66b5720..0e65d81 100644
--- a/drivers/fpga/dfl-pci.c
+++ b/drivers/fpga/dfl-pci.c
@@ -223,8 +223,46 @@ int cci_pci_probe(struct pci_dev *pcidev, const struct
pci_device_id *pcidevid)
return ret;
}
+static int cci_pci_sriov_configure(struct pci_dev *pcidev, int num_vfs)
+{
+ struct cci_drvdata *drvdata = pci_get_drvdata(pcidev);
+ struct dfl_fpga_cdev *cdev = drvdata->cdev;
+ int ret = 0;
+
+ mutex_lock(>lock);
+
+ if (!num_vfs) {
+ /*
+* disable SRIOV and then put released ports back to default
+* PF access mode.
+*/
+ pci_disable_sriov(pcidev);
+
+ __dfl_fpga_cdev_config_port_vf(cdev, false);
+
+ } else if (cdev->released_port_num == num_vfs) {
+ /*
+* only enable SRIOV if cdev has matched released ports, put
+* released ports into VF access mode firstly.
+*/
+ __dfl_fpga_cdev_config_port_vf(cdev, true);
+
+ ret = pci_enable_sriov(pcidev, num_vfs);
+ if (ret)
+ __dfl_fpga_cdev_config_port_vf(cdev, false);
+ } else {
+ ret = -EINVAL;
+ }
+
+ mutex_unlock(>lock);
+ return ret;
+}
+
static void cci_pci_remove(struct pci_dev *pcidev)
{
+ if (dev_is_pf(>dev))
+ cci_pci_sriov_configure(pcidev, 0);
+
cci_remove_feature_devs(pcidev);
pci_disable_pcie_error_reporting(pcidev);
}
@@ -234,6 +272,7 @@ static void cci_pci_remove(struct pci_dev *pcidev)
.id_table = cci_pcie_id_tbl,
.probe = cci_pci_probe,
.remove = cci_pci_remove,
+ .sriov_configure = cci_pci_sriov_configure,
};
module_pci_driver(cci_pci_driver);
diff --git a/drivers/fpga/dfl.c b/drivers/fpga/dfl.c
index e04ed45..c3a8e1d 100644
--- a/drivers/fpga/dfl.c
+++ b/drivers/fpga/dfl.c
@@ -1112,6 +1112,47 @@ int dfl_fpga_cdev_config_port(struct dfl_fpga_cdev
*cdev, int port_id,
}
EXPORT_SYMBOL_GPL(dfl_fpga_cdev_config_port);
+static void config_port_vf(struct device *fme_dev, int port_id, bool is_vf)
+{
+ void __iomem *base;
+ u64 v;
+
+ base = dfl_get_feature_ioaddr_by_id(fme_dev, FME_FEATURE_ID_HEADER);
+
+ v = readq(base + FME_HDR_PORT_OFST(port_id));
+
+ v &= ~FME_PORT_OFST_ACC_CTRL;
+ v |= FIELD_PREP(FME_PORT_OFST_ACC_CTRL,
+ is_vf ? FME_PORT_OFST_ACC_VF : FME_PORT_OFST_ACC_PF);
+
+ writeq(v, base + FME_HDR_PORT_OFST(port_id));
+}
+
+/**
+ * __dfl_fpga_cdev_config_port_vf - configure port to VF access mode
+ *
+ * @cdev: parent container device.
+ * @if_vf: true for VF access mode, and false for PF access mode
+ *
+ * Return: 0 on success, negative error code otherwise.
+ *
+ * This function is needed in sriov configuration routine. It could be used to
+ * configures the released ports access mode to VF or PF.
+ * The caller needs to hold lock for protection.
+ */
+void __dfl_fpga_cdev_config_port_vf(struct dfl_fpga_cdev *cdev, bool is_vf)
+{
+ struct dfl_feature_platform_data *pdata;
+
+ list_for_each_entry(pdata, >port_dev_list, node) {
+ if (device_is_registered(>dev->dev))
+ continue;
+
+ config_port_vf(cdev->fme_dev, pdata->id, is_vf);
+ }
+}
+EXPORT_SYMBOL_GPL(__dfl_fpga_cdev_config_port_vf);
+
static int __init dfl_fpga_init(void)
{
int ret;
diff --git a/drivers/fpga/dfl.h b/drivers/fpga/dfl.h
index d700ee9..061ccd4 100644
--- a/drivers/fpga/dfl.h
+++ b/drivers/fpga/dfl.h
@@ -421,5 +421,6 @@ struct platform_device *
int dfl_fpga_cdev_config_port(struct dfl_fpga_cdev *cdev,
int port_id, bool release);
+void __dfl_fpga_cdev_config_port_vf(struct dfl_fpga_cdev *cdev, bool is_vf);
#endif /* __FPGA_DFL_H */
--
1.8.3.1
[PATCH v2 11/11] fpga: dfl: fme: add global error reporting support
This patch adds support for global error reporting for FPGA Management Engine (FME), it introduces sysfs interfaces to report different error detected by the hardware, and allow user to clear errors or inject error for testing purpose. Signed-off-by: Luwei Kang Signed-off-by: Ananda Ravuri Signed-off-by: Xu Yilun Signed-off-by: Wu Hao Acked-by: Alan Tull Signed-off-by: Moritz Fischer --- v2: switch to device_add/remove_groups for sysfs. --- Documentation/ABI/testing/sysfs-platform-dfl-fme | 75 + drivers/fpga/Makefile| 2 +- drivers/fpga/dfl-fme-error.c | 385 +++ drivers/fpga/dfl-fme-main.c | 4 + drivers/fpga/dfl-fme.h | 2 + drivers/fpga/dfl.h | 2 + 6 files changed, 469 insertions(+), 1 deletion(-) create mode 100644 drivers/fpga/dfl-fme-error.c diff --git a/Documentation/ABI/testing/sysfs-platform-dfl-fme b/Documentation/ABI/testing/sysfs-platform-dfl-fme index 99cd3b2..86eef83 100644 --- a/Documentation/ABI/testing/sysfs-platform-dfl-fme +++ b/Documentation/ABI/testing/sysfs-platform-dfl-fme @@ -44,3 +44,78 @@ Description: Read-only. It returns socket_id to indicate which socket this FPGA belongs to, only valid for integrated solution. User only needs this information, in case standard numa node can't provide correct information. + +What: /sys/bus/platform/devices/dfl-fme.0/errors/revision +Date: June 2019 +KernelVersion: 5.3 +Contact: Wu Hao +Description: Read-only. Read this file to get the revision of this global + error reporting private feature. + +What: /sys/bus/platform/devices/dfl-fme.0/errors/pcie0_errors +Date: June 2019 +KernelVersion: 5.3 +Contact: Wu Hao +Description: Read-Write. Read this file for errors detected on pcie0 link. + Write this file to clear errors logged in pcie0_errors. Write + fails with -EINVAL if input parsing fails or input error code + doesn't match. + +What: /sys/bus/platform/devices/dfl-fme.0/errors/pcie1_errors +Date: June 2019 +KernelVersion: 5.3 +Contact: Wu Hao +Description: Read-Write. Read this file for errors detected on pcie1 link. + Write this file to clear errors logged in pcie1_errors. Write + fails with -EINVAL if input parsing fails or input error code + doesn't match. + +What: /sys/bus/platform/devices/dfl-fme.0/errors/nonfatal_errors +Date: June 2019 +KernelVersion: 5.3 +Contact: Wu Hao +Description: Read-only. It returns non-fatal errors detected. + +What: /sys/bus/platform/devices/dfl-fme.0/errors/catfatal_errors +Date: June 2019 +KernelVersion: 5.3 +Contact: Wu Hao +Description: Read-only. It returns catastrophic and fatal errors detected. + +What: /sys/bus/platform/devices/dfl-fme.0/errors/inject_error +Date: June 2019 +KernelVersion: 5.3 +Contact: Wu Hao +Description: Read-Write. Read this file to check errors injected. Write this + file to inject errors for testing purpose. Write fails with + -EINVAL if input parsing fails or input inject error code isn't + supported. + +What: /sys/bus/platform/devices/dfl-fme.0/errors/fme-errors/errors +Date: June 2019 +KernelVersion: 5.3 +Contact: Wu Hao +Description: Read-only. Read this file to get errors detected by hardware. + +What: /sys/bus/platform/devices/dfl-fme.0/errors/fme-errors/first_error +Date: June 2019 +KernelVersion: 5.3 +Contact: Wu Hao +Description: Read-only. Read this file to get the first error detected by + hardware. + +What: /sys/bus/platform/devices/dfl-fme.0/errors/fme-errors/next_error +Date: June 2019 +KernelVersion: 5.3 +Contact: Wu Hao +Description: Read-only. Read this file to get the second error detected by + hardware. + +What: /sys/bus/platform/devices/dfl-fme.0/errors/fme-errors/clear +Date: June 2019 +KernelVersion: 5.3 +Contact: Wu Hao +Description: Write-only. Write error code to this file to clear all errors + logged in errors, first_error and next_error. Write fails with + -EINVAL if input parsing fails or input error code doesn't + match. diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile index 7255891..4865b74 100644 --- a/drivers/fpga/Makefile +++ b/drivers/fpga/Makefile @@ -39,7 +39,7 @@ obj-$(CONFIG_FPGA_DFL_FME_BRIDGE) += dfl-fme-br.o obj-$(CONFIG_FPGA_DFL_FME_REGION) += dfl-fme-region.o obj-$(CONFIG_FPGA_DFL_AFU) += dfl-afu.o -dfl-fme-objs := dfl-fme-main.o dfl-fme-pr.o +dfl-fme-objs := dfl-fme-main.o dfl-fme-pr.o dfl-fme-error.o
[PATCH v2 04/11] fpga: dfl: afu: add AFU state related sysfs interfaces
This patch introduces more sysfs interfaces for Accelerated
Function Unit (AFU). These interfaces allow users to read
current AFU Power State (APx), read / clear AFU Power (APx)
events which are sticky to identify transient APx state,
and manage AFU's LTR (latency tolerance reporting).
Signed-off-by: Ananda Ravuri
Signed-off-by: Xu Yilun
Signed-off-by: Wu Hao
Acked-by: Alan Tull
Signed-off-by: Moritz Fischer
---
v2: rebased, and remove DRV/MODULE_VERSION modifications
---
Documentation/ABI/testing/sysfs-platform-dfl-port | 30 +
drivers/fpga/dfl-afu-main.c | 137 ++
drivers/fpga/dfl.h| 11 ++
3 files changed, 178 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-platform-dfl-port
b/Documentation/ABI/testing/sysfs-platform-dfl-port
index 6a92dda..17b37d1 100644
--- a/Documentation/ABI/testing/sysfs-platform-dfl-port
+++ b/Documentation/ABI/testing/sysfs-platform-dfl-port
@@ -14,3 +14,33 @@ Description: Read-only. User can program different PR
bitstreams to FPGA
Accelerator Function Unit (AFU) for different functions. It
returns uuid which could be used to identify which PR bitstream
is programmed in this AFU.
+
+What: /sys/bus/platform/devices/dfl-port.0/power_state
+Date: June 2019
+KernelVersion: 5.3
+Contact: Wu Hao
+Description: Read-only. It reports the APx (AFU Power) state, different APx
+ means different throttling level. When reading this file, it
+ returns "0" - Normal / "1" - AP1 / "2" - AP2 / "6" - AP6.
+
+What: /sys/bus/platform/devices/dfl-port.0/ap1_event
+Date: June 2019
+KernelVersion: 5.3
+Contact: Wu Hao
+Description: Read-write. Read or set 1 to clear AP1 (AFU Power State 1)
+ event. It's used to indicate transient AP1 state.
+
+What: /sys/bus/platform/devices/dfl-port.0/ap2_event
+Date: June 2019
+KernelVersion: 5.3
+Contact: Wu Hao
+Description: Read-write. Read or set 1 to clear AP2 (AFU Power State 2)
+ event. It's used to indicate transient AP2 state.
+
+What: /sys/bus/platform/devices/dfl-port.0/ltr
+Date: June 2019
+KernelVersion: 5.3
+Contact: Wu Hao
+Description: Read-write. Read and set AFU latency tolerance reporting value.
+ Set ltr to 1 if the AFU can tolerate latency >= 40us or set it
+ to 0 if it is latency sensitive.
diff --git a/drivers/fpga/dfl-afu-main.c b/drivers/fpga/dfl-afu-main.c
index 68b4d08..cb3f73e 100644
--- a/drivers/fpga/dfl-afu-main.c
+++ b/drivers/fpga/dfl-afu-main.c
@@ -141,8 +141,145 @@ static int port_get_id(struct platform_device *pdev)
}
static DEVICE_ATTR_RO(id);
+static ssize_t
+ltr_show(struct device *dev, struct device_attribute *attr, char *buf)
+{
+ struct dfl_feature_platform_data *pdata = dev_get_platdata(dev);
+ void __iomem *base;
+ u64 v;
+
+ base = dfl_get_feature_ioaddr_by_id(dev, PORT_FEATURE_ID_HEADER);
+
+ mutex_lock(>lock);
+ v = readq(base + PORT_HDR_CTRL);
+ mutex_unlock(>lock);
+
+ return sprintf(buf, "%x\n", (u8)FIELD_GET(PORT_CTRL_LATENCY, v));
+}
+
+static ssize_t
+ltr_store(struct device *dev, struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct dfl_feature_platform_data *pdata = dev_get_platdata(dev);
+ void __iomem *base;
+ u8 ltr;
+ u64 v;
+
+ if (kstrtou8(buf, 0, ) || ltr > 1)
+ return -EINVAL;
+
+ base = dfl_get_feature_ioaddr_by_id(dev, PORT_FEATURE_ID_HEADER);
+
+ mutex_lock(>lock);
+ v = readq(base + PORT_HDR_CTRL);
+ v &= ~PORT_CTRL_LATENCY;
+ v |= FIELD_PREP(PORT_CTRL_LATENCY, ltr);
+ writeq(v, base + PORT_HDR_CTRL);
+ mutex_unlock(>lock);
+
+ return count;
+}
+static DEVICE_ATTR_RW(ltr);
+
+static ssize_t
+ap1_event_show(struct device *dev, struct device_attribute *attr, char *buf)
+{
+ struct dfl_feature_platform_data *pdata = dev_get_platdata(dev);
+ void __iomem *base;
+ u64 v;
+
+ base = dfl_get_feature_ioaddr_by_id(dev, PORT_FEATURE_ID_HEADER);
+
+ mutex_lock(>lock);
+ v = readq(base + PORT_HDR_STS);
+ mutex_unlock(>lock);
+
+ return sprintf(buf, "%x\n", (u8)FIELD_GET(PORT_STS_AP1_EVT, v));
+}
+
+static ssize_t
+ap1_event_store(struct device *dev, struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct dfl_feature_platform_data *pdata = dev_get_platdata(dev);
+ void __iomem *base;
+ u8 ap1_event;
+
+ if (kstrtou8(buf, 0, _event) || ap1_event != 1)
+ return -EINVAL;
+
+ base = dfl_get_feature_ioaddr_by_id(dev, PORT_FEATURE_ID_HEADER);
+
+ mutex_lock(>lock);
+ writeq(PORT_STS_AP1_EVT, base + PORT_HDR_STS);
+ mutex_unlock(>lock);
+
+ return count;
+}
+static
[PATCH v2 06/11] fpga: dfl: add id_table for dfl private feature driver
This patch adds id_table for each dfl private feature driver,
it allows to reuse same private feature driver to match and support
multiple dfl private features.
Signed-off-by: Xu Yilun
Signed-off-by: Wu Hao
Acked-by: Moritz Fischer
Acked-by: Alan Tull
Signed-off-by: Moritz Fischer
---
v2: rebased, remove DRV/MODULE_VERSION modifications
---
drivers/fpga/dfl-afu-main.c | 14 --
drivers/fpga/dfl-fme-main.c | 11 ---
drivers/fpga/dfl-fme-pr.c | 7 ++-
drivers/fpga/dfl-fme.h | 3 ++-
drivers/fpga/dfl.c | 18 --
drivers/fpga/dfl.h | 21 +++--
6 files changed, 59 insertions(+), 15 deletions(-)
diff --git a/drivers/fpga/dfl-afu-main.c b/drivers/fpga/dfl-afu-main.c
index 9025314..fbd9553 100644
--- a/drivers/fpga/dfl-afu-main.c
+++ b/drivers/fpga/dfl-afu-main.c
@@ -435,6 +435,11 @@ static void port_hdr_uinit(struct platform_device *pdev,
return ret;
}
+static const struct dfl_feature_id port_hdr_id_table[] = {
+ {.id = PORT_FEATURE_ID_HEADER,},
+ {0,}
+};
+
static const struct dfl_feature_ops port_hdr_ops = {
.init = port_hdr_init,
.uinit = port_hdr_uinit,
@@ -496,6 +501,11 @@ static void port_afu_uinit(struct platform_device *pdev,
device_remove_groups(>dev, port_afu_groups);
}
+static const struct dfl_feature_id port_afu_id_table[] = {
+ {.id = PORT_FEATURE_ID_AFU,},
+ {0,}
+};
+
static const struct dfl_feature_ops port_afu_ops = {
.init = port_afu_init,
.uinit = port_afu_uinit,
@@ -503,11 +513,11 @@ static void port_afu_uinit(struct platform_device *pdev,
static struct dfl_feature_driver port_feature_drvs[] = {
{
- .id = PORT_FEATURE_ID_HEADER,
+ .id_table = port_hdr_id_table,
.ops = _hdr_ops,
},
{
- .id = PORT_FEATURE_ID_AFU,
+ .id_table = port_afu_id_table,
.ops = _afu_ops,
},
{
diff --git a/drivers/fpga/dfl-fme-main.c b/drivers/fpga/dfl-fme-main.c
index e61e0fe..e333f19 100644
--- a/drivers/fpga/dfl-fme-main.c
+++ b/drivers/fpga/dfl-fme-main.c
@@ -133,6 +133,11 @@ static long fme_hdr_ioctl(struct platform_device *pdev,
return -ENODEV;
}
+static const struct dfl_feature_id fme_hdr_id_table[] = {
+ {.id = FME_FEATURE_ID_HEADER,},
+ {0,}
+};
+
static const struct dfl_feature_ops fme_hdr_ops = {
.init = fme_hdr_init,
.uinit = fme_hdr_uinit,
@@ -141,12 +146,12 @@ static long fme_hdr_ioctl(struct platform_device *pdev,
static struct dfl_feature_driver fme_feature_drvs[] = {
{
- .id = FME_FEATURE_ID_HEADER,
+ .id_table = fme_hdr_id_table,
.ops = _hdr_ops,
},
{
- .id = FME_FEATURE_ID_PR_MGMT,
- .ops = _mgmt_ops,
+ .id_table = fme_pr_mgmt_id_table,
+ .ops = _pr_mgmt_ops,
},
{
.ops = NULL,
diff --git a/drivers/fpga/dfl-fme-pr.c b/drivers/fpga/dfl-fme-pr.c
index cd94ba8..52f1745 100644
--- a/drivers/fpga/dfl-fme-pr.c
+++ b/drivers/fpga/dfl-fme-pr.c
@@ -483,7 +483,12 @@ static long fme_pr_ioctl(struct platform_device *pdev,
return ret;
}
-const struct dfl_feature_ops pr_mgmt_ops = {
+const struct dfl_feature_id fme_pr_mgmt_id_table[] = {
+ {.id = FME_FEATURE_ID_PR_MGMT,},
+ {0}
+};
+
+const struct dfl_feature_ops fme_pr_mgmt_ops = {
.init = pr_mgmt_init,
.uinit = pr_mgmt_uinit,
.ioctl = fme_pr_ioctl,
diff --git a/drivers/fpga/dfl-fme.h b/drivers/fpga/dfl-fme.h
index de20755..7a021c4 100644
--- a/drivers/fpga/dfl-fme.h
+++ b/drivers/fpga/dfl-fme.h
@@ -35,6 +35,7 @@ struct dfl_fme {
struct dfl_feature_platform_data *pdata;
};
-extern const struct dfl_feature_ops pr_mgmt_ops;
+extern const struct dfl_feature_ops fme_pr_mgmt_ops;
+extern const struct dfl_feature_id fme_pr_mgmt_id_table[];
#endif /* __DFL_FME_H */
diff --git a/drivers/fpga/dfl.c b/drivers/fpga/dfl.c
index c3a8e1d..3eb67ab 100644
--- a/drivers/fpga/dfl.c
+++ b/drivers/fpga/dfl.c
@@ -281,6 +281,21 @@ static int dfl_feature_instance_init(struct
platform_device *pdev,
return ret;
}
+static bool dfl_feature_drv_match(struct dfl_feature *feature,
+ struct dfl_feature_driver *driver)
+{
+ const struct dfl_feature_id *ids = driver->id_table;
+
+ if (ids) {
+ while (ids->id) {
+ if (ids->id == feature->id)
+ return true;
+ ids++;
+ }
+ }
+ return false;
+}
+
/**
* dfl_fpga_dev_feature_init - init for sub features of dfl feature device
* @pdev: feature device.
@@ -301,8 +316,7 @@ int dfl_fpga_dev_feature_init(struct platform_device *pdev,
while (drv->ops) {
dfl_fpga_dev_for_each_feature(pdata, feature) {
-
[PATCH v2 05/11] fpga: dfl: afu: add userclock sysfs interfaces.
This patch introduces userclock sysfs interfaces for AFU, user
could use these interfaces for clock setting to AFU.
Please note that, this is only working for port header feature
with revision 0, for later revisions, userclock setting is moved
to a separated private feature, so one revision sysfs interface
is exposed to userspace application for this purpose too.
Signed-off-by: Ananda Ravuri
Signed-off-by: Russ Weight
Signed-off-by: Xu Yilun
Signed-off-by: Wu Hao
Acked-by: Alan Tull
Signed-off-by: Moritz Fischer
---
v2: rebased, and switched to use device_add/remove_groups for sysfs.
---
Documentation/ABI/testing/sysfs-platform-dfl-port | 35 +++
drivers/fpga/dfl-afu-main.c | 114 +-
drivers/fpga/dfl.h| 4 +
3 files changed, 152 insertions(+), 1 deletion(-)
diff --git a/Documentation/ABI/testing/sysfs-platform-dfl-port
b/Documentation/ABI/testing/sysfs-platform-dfl-port
index 17b37d1..04ea7f2 100644
--- a/Documentation/ABI/testing/sysfs-platform-dfl-port
+++ b/Documentation/ABI/testing/sysfs-platform-dfl-port
@@ -44,3 +44,38 @@ Contact: Wu Hao
Description: Read-write. Read and set AFU latency tolerance reporting value.
Set ltr to 1 if the AFU can tolerate latency >= 40us or set it
to 0 if it is latency sensitive.
+
+What: /sys/bus/platform/devices/dfl-port.0/revision
+Date: June 2019
+KernelVersion: 5.3
+Contact: Wu Hao
+Description: Read-only. Read this file to get the revision of port header
+ feature.
+
+What: /sys/bus/platform/devices/dfl-port.0/userclk_freqcmd
+Date: June 2019
+KernelVersion: 5.3
+Contact: Wu Hao
+Description: Write-only. User writes command to this interface to set
+ userclock to AFU.
+
+What: /sys/bus/platform/devices/dfl-port.0/userclk_freqsts
+Date: June 2019
+KernelVersion: 5.3
+Contact: Wu Hao
+Description: Read-only. Read this file to get the status of issued command
+ to userclck_freqcmd.
+
+What: /sys/bus/platform/devices/dfl-port.0/userclk_freqcntrcmd
+Date: June 2019
+KernelVersion: 5.3
+Contact: Wu Hao
+Description: Write-only. User writes command to this interface to set
+ userclock counter.
+
+What: /sys/bus/platform/devices/dfl-port.0/userclk_freqcntrsts
+Date: June 2019
+KernelVersion: 5.3
+Contact: Wu Hao
+Description: Read-only. Read this file to get the status of issued command
+ to userclck_freqcntrcmd.
diff --git a/drivers/fpga/dfl-afu-main.c b/drivers/fpga/dfl-afu-main.c
index cb3f73e..9025314 100644
--- a/drivers/fpga/dfl-afu-main.c
+++ b/drivers/fpga/dfl-afu-main.c
@@ -142,6 +142,17 @@ static int port_get_id(struct platform_device *pdev)
static DEVICE_ATTR_RO(id);
static ssize_t
+revision_show(struct device *dev, struct device_attribute *attr, char *buf)
+{
+ void __iomem *base;
+
+ base = dfl_get_feature_ioaddr_by_id(dev, PORT_FEATURE_ID_HEADER);
+
+ return sprintf(buf, "%x\n", dfl_feature_revision(base));
+}
+static DEVICE_ATTR_RO(revision);
+
+static ssize_t
ltr_show(struct device *dev, struct device_attribute *attr, char *buf)
{
struct dfl_feature_platform_data *pdata = dev_get_platdata(dev);
@@ -276,6 +287,7 @@ static int port_get_id(struct platform_device *pdev)
static struct attribute *port_hdr_attrs[] = {
_attr_id.attr,
+ _attr_revision.attr,
_attr_ltr.attr,
_attr_ap1_event.attr,
_attr_ap2_event.attr,
@@ -284,14 +296,113 @@ static int port_get_id(struct platform_device *pdev)
};
ATTRIBUTE_GROUPS(port_hdr);
+static ssize_t
+userclk_freqcmd_store(struct device *dev, struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct dfl_feature_platform_data *pdata = dev_get_platdata(dev);
+ u64 userclk_freq_cmd;
+ void __iomem *base;
+
+ if (kstrtou64(buf, 0, _freq_cmd))
+ return -EINVAL;
+
+ base = dfl_get_feature_ioaddr_by_id(dev, PORT_FEATURE_ID_HEADER);
+
+ mutex_lock(>lock);
+ writeq(userclk_freq_cmd, base + PORT_HDR_USRCLK_CMD0);
+ mutex_unlock(>lock);
+
+ return count;
+}
+static DEVICE_ATTR_WO(userclk_freqcmd);
+
+static ssize_t
+userclk_freqcntrcmd_store(struct device *dev, struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct dfl_feature_platform_data *pdata = dev_get_platdata(dev);
+ u64 userclk_freqcntr_cmd;
+ void __iomem *base;
+
+ if (kstrtou64(buf, 0, _freqcntr_cmd))
+ return -EINVAL;
+
+ base = dfl_get_feature_ioaddr_by_id(dev, PORT_FEATURE_ID_HEADER);
+
+ mutex_lock(>lock);
+ writeq(userclk_freqcntr_cmd, base + PORT_HDR_USRCLK_CMD1);
+ mutex_unlock(>lock);
+
+ return count;
+}
+static DEVICE_ATTR_WO(userclk_freqcntrcmd);
+
[PATCH v2 10/11] fpga: dfl: fme: add capability sysfs interfaces
This patch adds 3 read-only sysfs interfaces for FPGA Management Engine
(FME) block for capabilities including cache_size, fabric_version and
socket_id.
Signed-off-by: Luwei Kang
Signed-off-by: Xu Yilun
Signed-off-by: Wu Hao
Acked-by: Alan Tull
Signed-off-by: Moritz Fischer
---
v2: rebased.
---
Documentation/ABI/testing/sysfs-platform-dfl-fme | 23
drivers/fpga/dfl-fme-main.c | 48
2 files changed, 71 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-platform-dfl-fme
b/Documentation/ABI/testing/sysfs-platform-dfl-fme
index 8fa4feb..99cd3b2 100644
--- a/Documentation/ABI/testing/sysfs-platform-dfl-fme
+++ b/Documentation/ABI/testing/sysfs-platform-dfl-fme
@@ -21,3 +21,26 @@ Contact: Wu Hao
Description: Read-only. It returns Bitstream (static FPGA region) meta
data, which includes the synthesis date, seed and other
information of this static FPGA region.
+
+What: /sys/bus/platform/devices/dfl-fme.0/cache_size
+Date: June 2019
+KernelVersion: 5.3
+Contact: Wu Hao
+Description: Read-only. It returns cache size of this FPGA device.
+
+What: /sys/bus/platform/devices/dfl-fme.0/fabric_version
+Date: June 2019
+KernelVersion: 5.3
+Contact: Wu Hao
+Description: Read-only. It returns fabric version of this FPGA device.
+ Userspace applications need this information to select
+ best data channels per different fabric design.
+
+What: /sys/bus/platform/devices/dfl-fme.0/socket_id
+Date: June 2019
+KernelVersion: 5.3
+Contact: Wu Hao
+Description: Read-only. It returns socket_id to indicate which socket
+ this FPGA belongs to, only valid for integrated solution.
+ User only needs this information, in case standard numa node
+ can't provide correct information.
diff --git a/drivers/fpga/dfl-fme-main.c b/drivers/fpga/dfl-fme-main.c
index e333f19..c8703c4 100644
--- a/drivers/fpga/dfl-fme-main.c
+++ b/drivers/fpga/dfl-fme-main.c
@@ -73,10 +73,58 @@ static ssize_t bitstream_metadata_show(struct device *dev,
}
static DEVICE_ATTR_RO(bitstream_metadata);
+static ssize_t cache_size_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ void __iomem *base;
+ u64 v;
+
+ base = dfl_get_feature_ioaddr_by_id(dev, FME_FEATURE_ID_HEADER);
+
+ v = readq(base + FME_HDR_CAP);
+
+ return sprintf(buf, "%u\n",
+ (unsigned int)FIELD_GET(FME_CAP_CACHE_SIZE, v));
+}
+static DEVICE_ATTR_RO(cache_size);
+
+static ssize_t fabric_version_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ void __iomem *base;
+ u64 v;
+
+ base = dfl_get_feature_ioaddr_by_id(dev, FME_FEATURE_ID_HEADER);
+
+ v = readq(base + FME_HDR_CAP);
+
+ return sprintf(buf, "%u\n",
+ (unsigned int)FIELD_GET(FME_CAP_FABRIC_VERID, v));
+}
+static DEVICE_ATTR_RO(fabric_version);
+
+static ssize_t socket_id_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ void __iomem *base;
+ u64 v;
+
+ base = dfl_get_feature_ioaddr_by_id(dev, FME_FEATURE_ID_HEADER);
+
+ v = readq(base + FME_HDR_CAP);
+
+ return sprintf(buf, "%u\n",
+ (unsigned int)FIELD_GET(FME_CAP_SOCKET_ID, v));
+}
+static DEVICE_ATTR_RO(socket_id);
+
static struct attribute *fme_hdr_attrs[] = {
_attr_ports_num.attr,
_attr_bitstream_id.attr,
_attr_bitstream_metadata.attr,
+ _attr_cache_size.attr,
+ _attr_fabric_version.attr,
+ _attr_socket_id.attr,
NULL,
};
ATTRIBUTE_GROUPS(fme_hdr);
--
1.8.3.1
Re: [RFC v2] vhost: introduce mdev based hardware vhost backend
On 2019/7/4 下午3:02, Tiwei Bie wrote:
On Thu, Jul 04, 2019 at 02:35:20PM +0800, Jason Wang wrote:
On 2019/7/4 下午2:21, Tiwei Bie wrote:
On Thu, Jul 04, 2019 at 12:31:48PM +0800, Jason Wang wrote:
On 2019/7/3 下午9:08, Tiwei Bie wrote:
On Wed, Jul 03, 2019 at 08:16:23PM +0800, Jason Wang wrote:
On 2019/7/3 下午7:52, Tiwei Bie wrote:
On Wed, Jul 03, 2019 at 06:09:51PM +0800, Jason Wang wrote:
On 2019/7/3 下午5:13, Tiwei Bie wrote:
Details about this can be found here:
https://lwn.net/Articles/750770/
What's new in this version
==
A new VFIO device type is introduced - vfio-vhost. This addressed
some comments from here:https://patchwork.ozlabs.org/cover/984763/
Below is the updated device interface:
Currently, there are two regions of this device: 1) CONFIG_REGION
(VFIO_VHOST_CONFIG_REGION_INDEX), which can be used to setup the
device; 2) NOTIFY_REGION (VFIO_VHOST_NOTIFY_REGION_INDEX), which
can be used to notify the device.
1. CONFIG_REGION
The region described by CONFIG_REGION is the main control interface.
Messages will be written to or read from this region.
The message type is determined by the `request` field in message
header. The message size is encoded in the message header too.
The message format looks like this:
struct vhost_vfio_op {
__u64 request;
__u32 flags;
/* Flag values: */
#define VHOST_VFIO_NEED_REPLY 0x1 /* Whether need reply */
__u32 size;
union {
__u64 u64;
struct vhost_vring_state state;
struct vhost_vring_addr addr;
} payload;
};
The existing vhost-kernel ioctl cmds are reused as the message
requests in above structure.
Still a comments like V1. What's the advantage of inventing a new protocol?
I'm trying to make it work in VFIO's way..
I believe either of the following should be better:
- using vhost ioctl, we can start from SET_VRING_KICK/SET_VRING_CALL and
extend it with e.g notify region. The advantages is that all exist userspace
program could be reused without modification (or minimal modification). And
vhost API hides lots of details that is not necessary to be understood by
application (e.g in the case of container).
Do you mean reusing vhost's ioctl on VFIO device fd directly,
or introducing another mdev driver (i.e. vhost_mdev instead of
using the existing vfio_mdev) for mdev device?
Can we simply add them into ioctl of mdev_parent_ops?
Right, either way, these ioctls have to be and just need to be
added in the ioctl of the mdev_parent_ops. But another thing we
also need to consider is that which file descriptor the userspace
will do the ioctl() on. So I'm wondering do you mean let the
userspace do the ioctl() on the VFIO device fd of the mdev
device?
Yes.
Got it! I'm not sure what's Alex opinion on this. If we all
agree with this, I can do it in this way.
Is there any other way btw?
Just a quick thought.. Maybe totally a bad idea.
It's not for sure :)
Thanks!
I was thinking
whether it would be odd to do non-VFIO's ioctls on VFIO's device
fd. So I was wondering whether it's possible to allow binding
another mdev driver (e.g. vhost_mdev) to the supported mdev
devices. The new mdev driver, vhost_mdev, can provide similar
ways to let userspace open the mdev device and do the vhost ioctls
on it. To distinguish with the vfio_mdev compatible mdev devices,
the device API of the new vhost_mdev compatible mdev devices
might be e.g. "vhost-net" for net?
So in VFIO case, the device will be for passthru directly. And
in VHOST case, the device can be used to accelerate the existing
virtualized devices.
How do you think?
If my understanding is correct, there will be no VFIO ioctl if we go for
vhost_mdev?
Yeah, exactly. If we go for vhost_mdev, we may have some vhost nodes
in /dev similar to what /dev/vfio/* does to handle the $UUID and open
the device (e.g. similar to VFIO_GROUP_GET_DEVICE_FD in VFIO). And
to setup the device, we can try to reuse the ioctls of the existing
kernel vhost as much as possible.
Interesting, actually, I've considered something similar. I think there
should be no issues other than DMA:
- Need to invent new API for DMA mapping other than SET_MEM_TABLE?
(Which is too heavyweight).
- Need to consider a way to co-work with both on chip IOMMU (your
proposal should be fine) and scalable IOV.
Thanks
Thanks,
Tiwei
Thanks
Thanks,
Tiwei
Thanks
RE: [PATCH V3 1/2] dt-bindings: reset: imx7: Add support for i.MX8MM
Hi, Philipp > On Thu, 2019-07-04 at 17:44 +0800, anson.hu...@nxp.com wrote: > > From: Anson Huang > > > > i.MX8MM can reuse i.MX8MQ's reset driver, update the compatible > > property and related info to support i.MX8MM. > > > > Signed-off-by: Anson Huang > > --- > > Changes since V2: > > - Add separate line for i.MX8MM in case anything different later for > i.MX8MM. > > --- > > Documentation/devicetree/bindings/reset/fsl,imx7-src.txt | 6 -- > > 1 file changed, 4 insertions(+), 2 deletions(-) > > > > diff --git a/Documentation/devicetree/bindings/reset/fsl,imx7-src.txt > > b/Documentation/devicetree/bindings/reset/fsl,imx7-src.txt > > index 13e0951..c2489e4 100644 > > --- a/Documentation/devicetree/bindings/reset/fsl,imx7-src.txt > > +++ b/Documentation/devicetree/bindings/reset/fsl,imx7-src.txt > > @@ -8,6 +8,7 @@ Required properties: > > - compatible: > > - For i.MX7 SoCs should be "fsl,imx7d-src", "syscon" > > - For i.MX8MQ SoCs should be "fsl,imx8mq-src", "syscon" > > + - For i.MX8MM SoCs should be "fsl,imx8mm-src", "fsl,imx8mq-src", > "syscon" > > - reg: should be register base and length as documented in the > >datasheet > > - interrupts: Should contain SRC interrupt @@ -46,5 +47,6 @@ Example: > > > > > > For list of all valid reset indices see > > - for i.MX7 and > > - for i.MX8MQ > > + for i.MX7, > > + for i.MX8MQ and > > + for i.MX8MM > > The last line is misleading, as that file contains reset indices that are > invalid > for i.MX8MM. What is your suggestion about this line? Just NOT change it? Or adding a new file imx8mm-reset.h but still use the IMX8MQ_RESET_ as prefix ? Or keep what I changed, but adding some comments in those macros that i.MX8MM does NOT support? Thanks, Anson. > > regards > Philipp
Re: [PATCH] perf/x86/intel: Fix spurious NMI on fixed counter
On 6/25/2019 10:58 PM, Jiri Olsa wrote:
On Tue, Jun 25, 2019 at 07:21:35AM -0700, kan.li...@linux.intel.com wrote:
From: Kan Liang
If a user first sample a PEBS event on a fixed counter, then sample a
non-PEBS event on the same fixed counter on Icelake, it will trigger
spurious NMI. For example,
perf record -e 'cycles:p' -a
perf record -e 'cycles' -a
The error message for spurious NMI.
[June 21 15:38] Uhhuh. NMI received for unknown reason 30 on CPU 2.
[ +0.00] Do you have a strange power saving mode enabled?
[ +0.00] Dazed and confused, but trying to continue
The issue was introduced by the following commit:
commit 6f55967ad9d9 ("perf/x86/intel: Fix race in intel_pmu_disable_event()")
The commit moves the intel_pmu_pebs_disable() after
intel_pmu_disable_fixed(), which returns immediately.
The related bit of PEBS_ENABLE MSR will never be cleared for the fixed
counter. Then a non-PEBS event runs on the fixed counter, but the bit
on PEBS_ENABLE is still set, which trigger spurious NMI.
Check and disable PEBS for fixed counter after intel_pmu_disable_fixed().
Reported-by: Yi, Ammy
Signed-off-by: Kan Liang
Fixes: 6f55967ad9d9 ("perf/x86/intel: Fix race in intel_pmu_disable_event()")
---
arch/x86/events/intel/core.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
index 4377bf6a6f82..464316218b77 100644
--- a/arch/x86/events/intel/core.c
+++ b/arch/x86/events/intel/core.c
@@ -2160,12 +2160,10 @@ static void intel_pmu_disable_event(struct perf_event
*event)
cpuc->intel_ctrl_host_mask &= ~(1ull << hwc->idx);
cpuc->intel_cp_status &= ~(1ull << hwc->idx);
- if (unlikely(hwc->config_base == MSR_ARCH_PERFMON_FIXED_CTR_CTRL)) {
+ if (unlikely(hwc->config_base == MSR_ARCH_PERFMON_FIXED_CTR_CTRL))
intel_pmu_disable_fixed(hwc);
- return;
- }
-
- x86_pmu_disable_event(event);
+ else
+ x86_pmu_disable_event(event);
oops, I overlooed this, looks good
Acked-by: Jiri Olsa
thanks,
jirka
Hi,
Could this fix be accepted?
Thanks
Jin Yao
/*
* Needs to be called after x86_pmu_disable_event,
--
2.14.5
[GIT PULL] ARM: SoC fixes
Hi Linus, Greg, The following changes since commit 6fbc7275c7a9ba97877050335f290341a1fd8dbf: Linux 5.2-rc7 (2019-06-30 11:25:36 +0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git tags/armsoc-fixes for you to fetch changes up to 2659dc8d225c956b91d8a8e4ef05d91b2e985c02: Merge tag 'davinci-fixes-for-v5.2-part2' of git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci into arm/fixes (2019-07-02 15:13:20 -0700) ARM: SoC fixes Likely our final small batch of fixes for 5.2: - Some fixes for USB on davinci, regressions were due to the recent conversion of the OCHI driver to use GPIO regulators - A fixup of kconfig dependencies for a TI irq controller - A switch of armada-38x to avoid dropped characters on uart, caused by switch of base inherited platform description earlier this year Arnd Bergmann (1): soc: ti: fix irq-ti-sci link error Bartosz Golaszewski (3): ARM: davinci: da830-evm: add missing regulator constraints for OHCI ARM: davinci: omapl138-hawk: add missing regulator constraints for OHCI ARM: davinci: da830-evm: fix GPIO lookup for OHCI Joshua Scott (1): ARM: dts: armada-xp-98dx3236: Switch to armada-38x-uart serial node Olof Johansson (2): Merge tag 'mvebu-fixes-5.2-2' of git://git.infradead.org/linux-mvebu into arm/fixes Merge tag 'davinci-fixes-for-v5.2-part2' of git://git.kernel.org/.../nsekhar/linux-davinci into arm/fixes arch/arm/boot/dts/armada-xp-98dx3236.dtsi | 8 arch/arm/mach-davinci/board-da830-evm.c | 5 - arch/arm/mach-davinci/board-omapl138-hawk.c | 3 +++ drivers/soc/Makefile| 2 +- drivers/soc/ti/Kconfig | 4 ++-- 5 files changed, 18 insertions(+), 4 deletions(-)
Re: [PATCH v2 1/3] vsock/virtio: use RCU to avoid use-after-free on the_virtio_vsock
On 2019/7/4 下午5:20, Stefano Garzarella wrote: This is still suspicious, can we access the_virtio_vsock through vdev->priv? If yes, we may still get use-after-free since it was not protected by RCU. We will free the object only after calling the del_vqs(), so we are sure that the vq_callbacks ended and will no longer be invoked. So, IIUC it shouldn't happen. Yes, but any dereference that is not done in vq_callbacks will be very dangerous in the future. Right. Do you think make sense to continue with this series in order to fix the hot-unplug issue, then I'll work to refactor the driver code to use the refcnt (as you suggested in patch 2) and singleton for the_virtio_vsock? Thanks, Stefano Yes. Thanks
[PATCH bpf-next] Enable zext optimization for more RV64G ALU ops
commit 66d0d5a854a6 ("riscv: bpf: eliminate zero extension code-gen")
added the new zero-extension optimization for some BPF ALU operations.
Since then, bugs in the JIT that have been fixed in the bpf tree require
this optimization to be added to other operations: commit 1e692f09e091
("bpf, riscv: clear high 32 bits for ALU32 add/sub/neg/lsh/rsh/arsh"),
and commit fe121ee531d1 ("bpf, riscv: clear target register high 32-bits
for and/or/xor on ALU32")
Now that these have been merged to bpf-next, the zext optimization can
be enabled for the fixed operations.
Cc: Song Liu
Cc: Jiong Wang
Cc: Xi Wang
Signed-off-by: Luke Nelson
---
arch/riscv/net/bpf_jit_comp.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/riscv/net/bpf_jit_comp.c b/arch/riscv/net/bpf_jit_comp.c
index 876cb9c705ce..5451ef3845f2 100644
--- a/arch/riscv/net/bpf_jit_comp.c
+++ b/arch/riscv/net/bpf_jit_comp.c
@@ -757,31 +757,31 @@ static int emit_insn(const struct bpf_insn *insn, struct
rv_jit_context *ctx,
case BPF_ALU | BPF_ADD | BPF_X:
case BPF_ALU64 | BPF_ADD | BPF_X:
emit(is64 ? rv_add(rd, rd, rs) : rv_addw(rd, rd, rs), ctx);
- if (!is64)
+ if (!is64 && !aux->verifier_zext)
emit_zext_32(rd, ctx);
break;
case BPF_ALU | BPF_SUB | BPF_X:
case BPF_ALU64 | BPF_SUB | BPF_X:
emit(is64 ? rv_sub(rd, rd, rs) : rv_subw(rd, rd, rs), ctx);
- if (!is64)
+ if (!is64 && !aux->verifier_zext)
emit_zext_32(rd, ctx);
break;
case BPF_ALU | BPF_AND | BPF_X:
case BPF_ALU64 | BPF_AND | BPF_X:
emit(rv_and(rd, rd, rs), ctx);
- if (!is64)
+ if (!is64 && !aux->verifier_zext)
emit_zext_32(rd, ctx);
break;
case BPF_ALU | BPF_OR | BPF_X:
case BPF_ALU64 | BPF_OR | BPF_X:
emit(rv_or(rd, rd, rs), ctx);
- if (!is64)
+ if (!is64 && !aux->verifier_zext)
emit_zext_32(rd, ctx);
break;
case BPF_ALU | BPF_XOR | BPF_X:
case BPF_ALU64 | BPF_XOR | BPF_X:
emit(rv_xor(rd, rd, rs), ctx);
- if (!is64)
+ if (!is64 && !aux->verifier_zext)
emit_zext_32(rd, ctx);
break;
case BPF_ALU | BPF_MUL | BPF_X:
@@ -811,13 +811,13 @@ static int emit_insn(const struct bpf_insn *insn, struct
rv_jit_context *ctx,
case BPF_ALU | BPF_RSH | BPF_X:
case BPF_ALU64 | BPF_RSH | BPF_X:
emit(is64 ? rv_srl(rd, rd, rs) : rv_srlw(rd, rd, rs), ctx);
- if (!is64)
+ if (!is64 && !aux->verifier_zext)
emit_zext_32(rd, ctx);
break;
case BPF_ALU | BPF_ARSH | BPF_X:
case BPF_ALU64 | BPF_ARSH | BPF_X:
emit(is64 ? rv_sra(rd, rd, rs) : rv_sraw(rd, rd, rs), ctx);
- if (!is64)
+ if (!is64 && !aux->verifier_zext)
emit_zext_32(rd, ctx);
break;
@@ -826,7 +826,7 @@ static int emit_insn(const struct bpf_insn *insn, struct
rv_jit_context *ctx,
case BPF_ALU64 | BPF_NEG:
emit(is64 ? rv_sub(rd, RV_REG_ZERO, rd) :
rv_subw(rd, RV_REG_ZERO, rd), ctx);
- if (!is64)
+ if (!is64 && !aux->verifier_zext)
emit_zext_32(rd, ctx);
break;
--
2.20.1
[GIT PULL] dax fix for v5.2-rc8
Hi Linus, please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm tags/dax-fix-5.2-rc8 ...to receive a single dax fix that has been soaking awaiting other fixes under discussion to join it. As it is getting late in the cycle lets proceed with this fix and save follow-on changes for post-v5.3-rc1. --- The following changes since commit f2c7c76c5d0a443053e94adb9f0918fa2fb85c3a: Linux 5.2-rc3 (2019-06-02 13:55:33 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm tags/dax-fix-5.2-rc8 for you to fetch changes up to 1571c029a2ff289683ddb0a32253850363bcb8a7: dax: Fix xarray entry association for mixed mappings (2019-06-06 22:18:49 -0700) dax fix v5.2-rc8 - Ensure proper accounting page->index and page->mapping, needed for memory error handling, when downgrading a PMD mapping/entry to PTE size. Jan Kara (1): dax: Fix xarray entry association for mixed mappings fs/dax.c | 9 - 1 file changed, 4 insertions(+), 5 deletions(-)
[PATCH 5/8] net: ethernet: sun4i-emac: Fix misuse of strlcpy
Probable cut typo - use the correct field size.
Signed-off-by: Joe Perches
---
drivers/net/ethernet/allwinner/sun4i-emac.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/allwinner/sun4i-emac.c
b/drivers/net/ethernet/allwinner/sun4i-emac.c
index 9e06dff619c3..40a359dd90b4 100644
--- a/drivers/net/ethernet/allwinner/sun4i-emac.c
+++ b/drivers/net/ethernet/allwinner/sun4i-emac.c
@@ -224,8 +224,8 @@ static int emac_ioctl(struct net_device *dev, struct ifreq
*rq, int cmd)
static void emac_get_drvinfo(struct net_device *dev,
struct ethtool_drvinfo *info)
{
- strlcpy(info->driver, DRV_NAME, sizeof(DRV_NAME));
- strlcpy(info->version, DRV_VERSION, sizeof(DRV_VERSION));
+ strlcpy(info->driver, DRV_NAME, sizeof(info->driver));
+ strlcpy(info->version, DRV_VERSION, sizeof(info->version));
strlcpy(info->bus_info, dev_name(>dev), sizeof(info->bus_info));
}
--
2.15.0
[PATCH 3/8] media: m2m-deinterlace: Fix misuse of strscpy
Probable cut typo - use the correct field size.
Signed-off-by: Joe Perches
---
drivers/media/platform/m2m-deinterlace.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/m2m-deinterlace.c
b/drivers/media/platform/m2m-deinterlace.c
index beb7fd7442fb..dd573d23d0ce 100644
--- a/drivers/media/platform/m2m-deinterlace.c
+++ b/drivers/media/platform/m2m-deinterlace.c
@@ -436,7 +436,7 @@ static int vidioc_querycap(struct file *file, void *priv,
{
strscpy(cap->driver, MEM2MEM_NAME, sizeof(cap->driver));
strscpy(cap->card, MEM2MEM_NAME, sizeof(cap->card));
- strscpy(cap->bus_info, MEM2MEM_NAME, sizeof(cap->card));
+ strscpy(cap->bus_info, MEM2MEM_NAME, sizeof(cap->bus_info));
/*
* This is only a mem-to-mem video device. The capture and output
* device capability flags are left only for backward compatibility
--
2.15.0
[PATCH 7/8] tty: hvcs: Fix odd use of strlcpy
Use the typical style of array, not the equivalent [0]. Signed-off-by: Joe Perches --- drivers/tty/hvc/hvcs.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/tty/hvc/hvcs.c b/drivers/tty/hvc/hvcs.c index cb4db1b3ca3c..b6c1c1be06f9 100644 --- a/drivers/tty/hvc/hvcs.c +++ b/drivers/tty/hvc/hvcs.c @@ -871,8 +871,8 @@ static void hvcs_set_pi(struct hvcs_partner_info *pi, struct hvcs_struct *hvcsd) hvcsd->p_partition_ID = pi->partition_ID; /* copy the null-term char too */ - strlcpy(>p_location_code[0], - >location_code[0], sizeof(hvcsd->p_location_code)); + strlcpy(hvcsd->p_location_code, pi->location_code, + sizeof(hvcsd->p_location_code)); } /* -- 2.15.0
[PATCH 4/8] media: go7007: Fix misuse of strscpy
Probable cut typo - use the correct field size. Signed-off-by: Joe Perches --- drivers/media/usb/go7007/snd-go7007.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/usb/go7007/snd-go7007.c b/drivers/media/usb/go7007/snd-go7007.c index 4a449c62fc32..b05fa227ffb2 100644 --- a/drivers/media/usb/go7007/snd-go7007.c +++ b/drivers/media/usb/go7007/snd-go7007.c @@ -253,7 +253,7 @@ int go7007_snd_init(struct go7007 *go) return ret; } strscpy(gosnd->card->driver, "go7007", sizeof(gosnd->card->driver)); - strscpy(gosnd->card->shortname, go->name, sizeof(gosnd->card->driver)); + strscpy(gosnd->card->shortname, go->name, sizeof(gosnd->card->shortname)); strscpy(gosnd->card->longname, gosnd->card->shortname, sizeof(gosnd->card->longname)); -- 2.15.0
[PATCH 2/8] leds: as3645a: Fix misuse of strlcpy
Probable cut typo - use the correct field size. Signed-off-by: Joe Perches --- drivers/leds/leds-as3645a.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/leds/leds-as3645a.c b/drivers/leds/leds-as3645a.c index 14ab6b0e4de9..050088dff8dd 100644 --- a/drivers/leds/leds-as3645a.c +++ b/drivers/leds/leds-as3645a.c @@ -668,7 +668,7 @@ static int as3645a_v4l2_setup(struct as3645a *flash) }; strlcpy(cfg.dev_name, led->name, sizeof(cfg.dev_name)); - strlcpy(cfgind.dev_name, flash->iled_cdev.name, sizeof(cfg.dev_name)); + strlcpy(cfgind.dev_name, flash->iled_cdev.name, sizeof(cfgind.dev_name)); flash->vf = v4l2_flash_init( >client->dev, flash->flash_node, >fled, NULL, -- 2.15.0
[PATCH 6/8] net: nixge: Fix misuse of strlcpy
Probable cut typo - use the correct field size.
Signed-off-by: Joe Perches
---
drivers/net/ethernet/ni/nixge.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/ni/nixge.c b/drivers/net/ethernet/ni/nixge.c
index 96f7a9818294..0b384f97d2fd 100644
--- a/drivers/net/ethernet/ni/nixge.c
+++ b/drivers/net/ethernet/ni/nixge.c
@@ -990,7 +990,7 @@ static void nixge_ethtools_get_drvinfo(struct net_device
*ndev,
struct ethtool_drvinfo *ed)
{
strlcpy(ed->driver, "nixge", sizeof(ed->driver));
- strlcpy(ed->bus_info, "platform", sizeof(ed->driver));
+ strlcpy(ed->bus_info, "platform", sizeof(ed->bus_info));
}
static int nixge_ethtools_get_coalesce(struct net_device *ndev,
--
2.15.0
[PATCH 1/8] Input: synaptics: Fix misuse of strlcpy
Probable cut typo - use the correct field size. Signed-off-by: Joe Perches --- drivers/input/mouse/synaptics.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/input/mouse/synaptics.c b/drivers/input/mouse/synaptics.c index 1080c0c49815..00a0cf14f27f 100644 --- a/drivers/input/mouse/synaptics.c +++ b/drivers/input/mouse/synaptics.c @@ -705,7 +705,7 @@ static void synaptics_pt_create(struct psmouse *psmouse) serio->id.type = SERIO_PS_PSTHRU; strlcpy(serio->name, "Synaptics pass-through", sizeof(serio->name)); - strlcpy(serio->phys, "synaptics-pt/serio0", sizeof(serio->name)); + strlcpy(serio->phys, "synaptics-pt/serio0", sizeof(serio->phys)); serio->write = synaptics_pt_write; serio->start = synaptics_pt_start; serio->stop = synaptics_pt_stop; -- 2.15.0
[PATCH 0/8] treewide: correct misuses of strscpy/strlcpy
These are all likely copy/paste defects where the field size of the 'copied to' array is incorrect. Each patch in this series is independent. Joe Perches (8): Input: synaptics: Fix misuse of strlcpy leds: as3645a: Fix misuse of strlcpy media: m2m-deinterlace: Fix misuse of strscpy media: go7007: Fix misuse of strscpy net: ethernet: sun4i-emac: Fix misuse of strlcpy net: nixge: Fix misuse of strlcpy tty: hvcs: Fix odd use of strlcpy nfsd: Fix misuse of strlcpy drivers/input/mouse/synaptics.c | 2 +- drivers/leds/leds-as3645a.c | 2 +- drivers/media/platform/m2m-deinterlace.c| 2 +- drivers/media/usb/go7007/snd-go7007.c | 2 +- drivers/net/ethernet/allwinner/sun4i-emac.c | 4 ++-- drivers/net/ethernet/ni/nixge.c | 2 +- drivers/tty/hvc/hvcs.c | 4 ++-- fs/nfsd/nfs4idmap.c | 2 +- 8 files changed, 10 insertions(+), 10 deletions(-) -- 2.15.0
[PATCH 8/8] nfsd: Fix misuse of strlcpy
Probable cut typo - use the correct field size. Signed-off-by: Joe Perches --- fs/nfsd/nfs4idmap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/nfsd/nfs4idmap.c b/fs/nfsd/nfs4idmap.c index 2961016097ac..d1f285245af8 100644 --- a/fs/nfsd/nfs4idmap.c +++ b/fs/nfsd/nfs4idmap.c @@ -83,7 +83,7 @@ ent_init(struct cache_head *cnew, struct cache_head *citm) new->type = itm->type; strlcpy(new->name, itm->name, sizeof(new->name)); - strlcpy(new->authname, itm->authname, sizeof(new->name)); + strlcpy(new->authname, itm->authname, sizeof(new->authname)); } static void -- 2.15.0
Re: [PATCH v3 0/4] Devmap cleanups + arm64 support
On Thu, Jul 4, 2019 at 12:59 PM Jason Gunthorpe wrote: > > On Thu, Jul 04, 2019 at 11:53:24AM -0700, Andrew Morton wrote: > > On Wed, 26 Jun 2019 20:35:51 -0700 Andrew Morton > > wrote: > > > > > > Let me know and I can help orchestate this. > > > > > > Well. Whatever works. In this situation I'd stage the patches after > > > linux-next and would merge them up after the prereq patches have been > > > merged into mainline. Easy. > > > > All right, what the hell just happened? > > Christoph's patch series for the devmap & hmm rework finally made it > into linux-next, sorry, it took quite a few iterations on the list to > get all the reviews and tests, and figure out how to resolve some > other conflicting things. So it just made it this week. > > Recall, this is the patch series I asked you about routing a few weeks > ago, as it really exceeded the small area that hmm.git was supposed to > cover. I think we are both caught off guard how big the conflict is! > > > A bunch of new material has just been introduced into linux-next. > > I've partially unpicked the resulting mess, haven't dared trying to > > compile it yet. To get this far I'll need to drop two patch series > > and one individual patch: > > > mm-clean-up-is_device__page-definitions.patch > > mm-introduce-arch_has_pte_devmap.patch > > arm64-mm-implement-pte_devmap-support.patch > > arm64-mm-implement-pte_devmap-support-fix.patch > > This one we discussed, and I thought we agreed would go to your 'stage > after linux-next' flow (see above). I think the conflict was minor > here. > > > mm-sparsemem-introduce-struct-mem_section_usage.patch > > mm-sparsemem-introduce-a-section_is_early-flag.patch > > mm-sparsemem-add-helpers-track-active-portions-of-a-section-at-boot.patch > > mm-hotplug-prepare-shrink_zone-pgdat_span-for-sub-section-removal.patch > > mm-sparsemem-convert-kmalloc_section_memmap-to-populate_section_memmap.patch > > mm-hotplug-kill-is_dev_zone-usage-in-__remove_pages.patch > > mm-kill-is_dev_zone-helper.patch > > mm-sparsemem-prepare-for-sub-section-ranges.patch > > mm-sparsemem-support-sub-section-hotplug.patch > > mm-document-zone_device-memory-model-implications.patch > > mm-document-zone_device-memory-model-implications-fix.patch > > mm-devm_memremap_pages-enable-sub-section-remap.patch > > libnvdimm-pfn-fix-fsdax-mode-namespace-info-block-zero-fields.patch > > libnvdimm-pfn-stop-padding-pmem-namespaces-to-section-alignment.patch > > Dan pointed to this while reviewing CH's series and said the conflicts > would be manageable, but they are certainly larger than I expected! > > This series is the one that seems to be the really big trouble. I > already checked all the other stuff that Stephen resolved, and it > looks OK and managable. Just this one conflict with kernel/memremap.c > is beyond me. > > What approach do you want to take to go forward? Here are some thoughts: > > CH has said he is away for the long weekend, so the path that involves > the fewest people is if Dan respins the above on linux-next and it > goes later with the arm patches above, assuming defering it for now > has no other adverse effects on -mm. > > Pushing CH's series to -mm would need a respin on top of Dan's series > above and would need to carry along the whole hmm.git (about 44 > patches). Signs are that this could be managed with the code currently > in the GPU trees. > > If we give up on CH's series the hmm.git will not have conflicts, > however we just kick the can to the next merge window where we will be > back to having to co-ordinate amd/nouveau/rdma git trees and -mm's > patch workflow - and I think we will be worse off as we will have > totally given up on a git based work flow for this. :( I think the problem would be resolved going forward post-v5.3 since we won't have two tress managing kernel/memremap.c. This cycle however there is a backlog of kernel/memremap.c changes in -mm.
Re: [PATCH] cpu/hotplug: Cache number of online CPUs
- On Jul 4, 2019, at 6:33 PM, Thomas Gleixner t...@linutronix.de wrote: > On Thu, 4 Jul 2019, Mathieu Desnoyers wrote: >> - On Jul 4, 2019, at 5:10 PM, Thomas Gleixner t...@linutronix.de wrote: >> > >> > num_online_cpus() is racy today vs. CPU hotplug operations as >> > long as you don't hold the hotplug lock. >> >> Fair point, AFAIU none of the loads performed within num_online_cpus() >> seem to rely on atomic nor volatile accesses. So not using a volatile >> access to load the cached value should not introduce any regression. >> >> I'm concerned that some code may rely on re-fetching of the cached >> value between iterations of a loop. The lack of READ_ONCE() would >> let the compiler keep a lifted load within a register and never >> re-fetch, unless there is a cpu_relax() or a barrier() within the >> loop. > > If someone really wants to write code which can handle concurrent CPU > hotplug operations and rely on that information, then it's probably better > to write out: > > ncpus = READ_ONCE(__num_online_cpus); > > explicitely along with a big fat comment. > > I can't figure out why one wants to do that and how it is supposed to work, > but my brain is in shutdown mode already :) > > I'd rather write a proper kernel doc comment for num_online_cpus() which > explains what the constraints are instead of pretending that the READ_ONCE > in the inline has any meaning. The other aspect I am concerned about is freedom given to the compiler to perform the store to __num_online_cpus non-atomically, or the load non-atomically due to memory pressure. Is that something we should be concerned about ? I thought we had WRITE_ONCE and READ_ONCE to take care of that kind of situation. The semantic I am looking for here is C11's relaxed atomics. Thanks, Mathieu > > Thanks, > > tglx -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com
Re: [PATCH net-next 4/6] arm64: dts: fsl: ls1028a: Add Felix switch port DT node
On Tue, 25 Jun 2019 at 00:23, Alexandre Belloni wrote: > > On 24/06/2019 18:24:31+0200, Andrew Lunn wrote: > > On Mon, Jun 24, 2019 at 05:23:45PM +0200, Allan W. Nielsen wrote: > > > Hi Andrew, > > > > > > The 06/24/2019 16:26, Andrew Lunn wrote: > > > > > > Yeah, there are 2 ethernet controller ports (managed by the enetc > > > > > > driver) > > > > > > connected inside the SoC via SGMII links to 2 of the switch ports, > > > > > > one of > > > > > > these switch ports can be configured as CPU port (with follow-up > > > > > > patches). > > > > > > > > > > > > This configuration may look prettier on DSA, but the main > > > > > > restriction here > > > > > > is that the entire functionality is provided by the ocelot driver > > > > > > which is a > > > > > > switchdev driver. I don't think it would be a good idea to > > > > > > copy-paste code > > > > > > from ocelot to a separate dsa driver. > > > > > > > > > > > > > > > > We should probably make the ocelot driver a DSA driver then... > > > > An important part of DSA is being able to direct frames out specific > > > > ports when they ingress via the CPU port. Does the silicon support > > > > this? At the moment, i think it is using polled IO. > > > > > > That is supported, it requires a bit of initial configuration of the > > > Chip, but > > > nothing big (I believe this configuration is part of Claudiu's > > > change-set). > > > > > > But how do you envision this done? > > > > > > - Let the existing SwitchDev driver and the DSA driver use a set of common > > > functions. > > > - Convert the existing Ocelot driver from SwitchDev to DSA > > > - Fork (copy) the existing driver of Ocelot, and modify it as needed for > > > the > > > Felix driver > > > > > > My guess is the first one, but I would like to understand what you have > > > in mind. > > > > I don't know the various architectures the switch is used in. But it > > does seem like a core library, and then a switchdev wrapper for Ocelot > > and a DSA wrapper for Felix would make sense. > > Ocelot could also be used in a DSA setting where one port can be > connected to an external MAC and be used to inject/extract frames > to/from any other ports. In that case, the IFH would serve as the DSA > tag. > > > -- > Alexandre Belloni, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com Hi everyone, Thank you for the nice discussion. I've been talking off-list to Claudiu and Alexandru about switchdev vs DSA for the Felix/Ocelot switches. My initial reaction was the same as Andrew's - there's a CPU-facing Ethernet MAC with some vendor-defined injection and extraction headers? Sounds like DSA. But then we discussed about what DSA for Felix/Ocelot would look like. Here are some points to consider: - DSA is typically used for discrete switches, switchdev is typically used for embedded ones. As far as I understand from Allan's message, Ocelot is really an entire switching SoC that's running Linux inside (on the MIPS CPU) with a switchdev driver. There is no (mainline?) driver that would control the Ocelot SoC from a higher-level Linux system. The latter would (maybe) fit DSA more. - The D in DSA is for cascaded switches. Apart from the absence of such a "Ocelot SoC" driver (which maybe can be written, I don't know), I think the switching core itself has some fundamental limitations that make a DSA implementation questionable: 1. The switch has a single port which can apply these vendor tags. Also the injection header is different than the extraction header. See more at #4. 2. The switch will tag all frames that go upstream on this port towards the CPU, no matter what source port they came from. It can't be told "hey, don't add a tag for frames coming from this downstream-facing port, because it's a DSA port and not front-panel, so there's another switch underneath you who already added a tag to the frame". So frames that arrive at the CPU through an array of N cascaded Felix/Ocelot switches will need to be peeled off, one by one, by N vendor tags. 3. The extraction header does not contain a field for the "switch id", only for the "source port". This means that if you want to figure out the switch id, you really *need* to make a topology out of those stacked vendor tags and figure out which switch it was by counting the tags. It also means that you can only have Felix/Ocelot in a linear topology. 4. The switch cannot parse its own vendor tags. This is a big one, because it means that for an autonomously forwarded frame which transits two cascaded switches but doesn't reach the CPU, there is no one in the path who's going to consume the vendor tag. So the frame will exit the other front-panel port with extra bytes in it. Ok, let's say that all of the above limitations have one thing in common - the vendor tags aren't really thought out with DSA-like setups in mind. In theory it's possible to not use the native tags and instead implement a dsa_8021q tagger for it. But
Re: linux-next: manual merge of the akpm-current tree with the hmm tree
Guys, Andrew has kicked the subsection patches out of -mm because of the merge conflicts. Can we hold off on the hmm cleanups for this cycle? On Thu, Jul 4, 2019 at 2:08 PM Stephen Rothwell wrote: > > Hi Jason, > > On Thu, 4 Jul 2019 13:28:41 + Jason Gunthorpe wrote: > > > > BTW, do you use a script to get these conflicting patch commit ID > > automatically? It is so helpful to have them. > > No, I just use gitk and a bit of searching. Though often there are not > many possible commits to search. > > -- > Cheers, > Stephen Rothwell
Re: [PATCH] dax: Fix missed PMD wakeups
On Thu, Jul 4, 2019 at 12:14 PM Matthew Wilcox wrote: > > On Thu, Jul 04, 2019 at 06:54:50PM +0200, Jan Kara wrote: > > On Wed 03-07-19 20:27:28, Matthew Wilcox wrote: > > > So I think we're good for all current users. > > > > Agreed but it is an ugly trap. As I already said, I'd rather pay the > > unnecessary cost of waiting for pte entry and have an easy to understand > > interface. If we ever have a real world use case that would care for this > > optimization, we will need to refactor functions to make this possible and > > still keep the interfaces sane. For example get_unlocked_entry() could > > return special "error code" indicating that there's no entry with matching > > order in xarray but there's a conflict with it. That would be much less > > error-prone interface. > > This is an internal interface. I think it's already a pretty gnarly > interface to use by definition -- it's going to sleep and might return > almost anything. There's not much scope for returning an error indicator > either; value entries occupy half of the range (all odd numbers between 1 > and ULONG_MAX inclusive), plus NULL. We could use an internal entry, but > I don't think that makes the interface any easier to use than returning > a locked entry. > > I think this iteration of the patch makes it a little clearer. What do you > think? > Not much clearer to me. get_unlocked_entry() is now misnamed and this arrangement allows for mismatches of @order argument vs @xas configuration. Can you describe, or even better demonstrate with numbers, why it's better to carry this complication than just converging the waitqueues between the types?
Re: audio lost from speaker after reboot from windows on the device ALC295
Maybe your machine has an external amplifier which needs to be set by software before it can work. On 2019/7/4 下午8:02, He, Bo wrote: Hi, patch_realtek.c maintainer: I see one issue that reboot from windows and boot to ubuntu, the audio lost from speaker, I suspect there are some bugs in patch_realtek.c drivers, the device is ALC295 and the device id is 0x10ec0295. I have done the below experiments: 1. reboot from windows to windows, the audio is persist . 2. reboot from windows to ubuntu, the audio lost from speaker, but can hear if I hotplug one earphone. 3. if the issue reproduce after reboot from windows, reboot the ubuntu can't restore the audio, I suspect it's warm reset. 4. if I write the port 0xcf9 with 0xe to do cold reset, the audio can restore. 5. if I do suspend/resume, the audio can restore, I suspect do cold boot and suspend will trigger the platform reset to reset the ALC295. 6. if I do double function reset (write the verb 0x7ff in alc_init), the audio is still can't restore. snd_hda_codec_write(codec, 0x01, 0, AC_VERB_SET_CODEC_RESET, 0); /* Function reset */ snd_hda_codec_write(codec, 0x01, 0, AC_VERB_SET_CODEC_RESET, 0); /* double Function reset */ 7. the issue is first found on kernel 4.19.50, I still see the issue with the latest kernel 5.2-rc2, is it possible windows change some default registers, but ALC295 don't initialize the register?
[PATCH v7 net-next 5/5] net: ethernet: ti: cpsw: add XDP support
Add XDP support based on rx page_pool allocator, one frame per page.
Page pool allocator is used with assumption that only one rx_handler
is running simultaneously. DMA map/unmap is reused from page pool
despite there is no need to map whole page.
Due to specific of cpsw, the same TX/RX handler can be used by 2
network devices, so special fields in buffer are added to identify
an interface the frame is destined to. Thus XDP works for both
interfaces, that allows to test xdp redirect between two interfaces
easily. Aslo, each rx queue have own page pools, but common for both
netdevs.
XDP prog is common for all channels till appropriate changes are added
in XDP infrastructure. Also, once page_pool recycling becomes part of
skb netstack some simplifications can be added, like removing
page_pool_release_page() before skb receive.
In order to keep rx_dev while redirect, that can be somehow used in
future, do flush in rx_handler, that allows to keep rx dev the same
while reidrect. It allows to conform with tracing rx_dev pointed
by Jesper.
Also, there is probability, that XDP generic code can be extended to
support multi ndev drivers like this one, using same rx queue for
several ndevs, based on switchdev for instance or else. In this case,
driver can be modified like exposed here:
https://lkml.org/lkml/2019/7/3/243
Signed-off-by: Ivan Khoronzhuk
---
drivers/net/ethernet/ti/Kconfig| 1 +
drivers/net/ethernet/ti/cpsw.c | 502 ++---
drivers/net/ethernet/ti/cpsw_ethtool.c | 37 +-
drivers/net/ethernet/ti/cpsw_priv.h| 7 +
4 files changed, 488 insertions(+), 59 deletions(-)
diff --git a/drivers/net/ethernet/ti/Kconfig b/drivers/net/ethernet/ti/Kconfig
index a800d3417411..834afca3a019 100644
--- a/drivers/net/ethernet/ti/Kconfig
+++ b/drivers/net/ethernet/ti/Kconfig
@@ -50,6 +50,7 @@ config TI_CPSW
depends on ARCH_DAVINCI || ARCH_OMAP2PLUS || COMPILE_TEST
select TI_DAVINCI_MDIO
select MFD_SYSCON
+ select PAGE_POOL
select REGMAP
---help---
This driver supports TI's CPSW Ethernet Switch.
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 32b7b3b74a6b..c17bb9381116 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -31,6 +31,10 @@
#include
#include
#include
+#include
+#include
+#include
+#include
#include
#include
@@ -60,6 +64,10 @@ static int descs_pool_size =
CPSW_CPDMA_DESCS_POOL_SIZE_DEFAULT;
module_param(descs_pool_size, int, 0444);
MODULE_PARM_DESC(descs_pool_size, "Number of CPDMA CPPI descriptors in pool");
+/* The buf includes headroom compatible with both skb and xdpf */
+#define CPSW_HEADROOM_NA (max(XDP_PACKET_HEADROOM, NET_SKB_PAD) + NET_IP_ALIGN)
+#define CPSW_HEADROOM ALIGN(CPSW_HEADROOM_NA, sizeof(long))
+
#define for_each_slave(priv, func, arg...) \
do {\
struct cpsw_slave *slave; \
@@ -74,6 +82,11 @@ MODULE_PARM_DESC(descs_pool_size, "Number of CPDMA CPPI
descriptors in pool");
(func)(slave++, ##arg); \
} while (0)
+#define CPSW_XMETA_OFFSET ALIGN(sizeof(struct xdp_frame), sizeof(long))
+
+#define CPSW_XDP_CONSUMED 1
+#define CPSW_XDP_PASS 0
+
static int cpsw_ndo_vlan_rx_add_vid(struct net_device *ndev,
__be16 proto, u16 vid);
@@ -337,24 +350,58 @@ void cpsw_intr_disable(struct cpsw_common *cpsw)
return;
}
+static int cpsw_is_xdpf_handle(void *handle)
+{
+ return (unsigned long)handle & BIT(0);
+}
+
+static void *cpsw_xdpf_to_handle(struct xdp_frame *xdpf)
+{
+ return (void *)((unsigned long)xdpf | BIT(0));
+}
+
+static struct xdp_frame *cpsw_handle_to_xdpf(void *handle)
+{
+ return (struct xdp_frame *)((unsigned long)handle & ~BIT(0));
+}
+
+struct __aligned(sizeof(long)) cpsw_meta_xdp {
+ struct net_device *ndev;
+ int ch;
+};
+
void cpsw_tx_handler(void *token, int len, int status)
{
+ struct cpsw_meta_xdp*xmeta;
+ struct xdp_frame*xdpf;
+ struct net_device *ndev;
struct netdev_queue *txq;
- struct sk_buff *skb = token;
- struct net_device *ndev = skb->dev;
- struct cpsw_common *cpsw = ndev_to_cpsw(ndev);
+ struct sk_buff *skb;
+ int ch;
+
+ if (cpsw_is_xdpf_handle(token)) {
+ xdpf = cpsw_handle_to_xdpf(token);
+ xmeta = (void *)xdpf + CPSW_XMETA_OFFSET;
+ ndev = xmeta->ndev;
+ ch = xmeta->ch;
+ xdp_return_frame(xdpf);
+ } else {
+ skb = token;
+ ndev = skb->dev;
+ ch = skb_get_queue_mapping(skb);
+
[PATCH v7 net-next 2/5] net: ethernet: ti: davinci_cpdma: add dma mapped submit
In case if dma mapped packet needs to be sent, like with XDP
page pool, the "mapped" submit can be used. This patch adds dma
mapped submit based on regular one.
Signed-off-by: Ivan Khoronzhuk
---
drivers/net/ethernet/ti/davinci_cpdma.c | 89 ++---
drivers/net/ethernet/ti/davinci_cpdma.h | 4 ++
2 files changed, 83 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/ti/davinci_cpdma.c
b/drivers/net/ethernet/ti/davinci_cpdma.c
index 5cf1758d425b..8da46394c0e7 100644
--- a/drivers/net/ethernet/ti/davinci_cpdma.c
+++ b/drivers/net/ethernet/ti/davinci_cpdma.c
@@ -139,6 +139,7 @@ struct submit_info {
int directed;
void *token;
void *data;
+ int flags;
int len;
};
@@ -184,6 +185,8 @@ static struct cpdma_control_info controls[] = {
(directed << CPDMA_TO_PORT_SHIFT));\
} while (0)
+#define CPDMA_DMA_EXT_MAP BIT(16)
+
static void cpdma_desc_pool_destroy(struct cpdma_ctlr *ctlr)
{
struct cpdma_desc_pool *pool = ctlr->pool;
@@ -1015,6 +1018,7 @@ static int cpdma_chan_submit_si(struct submit_info *si)
struct cpdma_chan *chan = si->chan;
struct cpdma_ctlr *ctlr = chan->ctlr;
int len = si->len;
+ int swlen = len;
struct cpdma_desc __iomem *desc;
dma_addr_t buffer;
u32 mode;
@@ -1036,16 +1040,22 @@ static int cpdma_chan_submit_si(struct submit_info *si)
chan->stats.runt_transmit_buff++;
}
- buffer = dma_map_single(ctlr->dev, si->data, len, chan->dir);
- ret = dma_mapping_error(ctlr->dev, buffer);
- if (ret) {
- cpdma_desc_free(ctlr->pool, desc, 1);
- return -EINVAL;
- }
-
mode = CPDMA_DESC_OWNER | CPDMA_DESC_SOP | CPDMA_DESC_EOP;
cpdma_desc_to_port(chan, mode, si->directed);
+ if (si->flags & CPDMA_DMA_EXT_MAP) {
+ buffer = (u32)si->data;
+ dma_sync_single_for_device(ctlr->dev, buffer, len, chan->dir);
+ swlen |= CPDMA_DMA_EXT_MAP;
+ } else {
+ buffer = dma_map_single(ctlr->dev, si->data, len, chan->dir);
+ ret = dma_mapping_error(ctlr->dev, buffer);
+ if (ret) {
+ cpdma_desc_free(ctlr->pool, desc, 1);
+ return -EINVAL;
+ }
+ }
+
/* Relaxed IO accessors can be used here as there is read barrier
* at the end of write sequence.
*/
@@ -1055,7 +1065,7 @@ static int cpdma_chan_submit_si(struct submit_info *si)
writel_relaxed(mode | len, >hw_mode);
writel_relaxed((uintptr_t)si->token, >sw_token);
writel_relaxed(buffer, >sw_buffer);
- writel_relaxed(len, >sw_len);
+ writel_relaxed(swlen, >sw_len);
desc_read(desc, sw_len);
__cpdma_chan_submit(chan, desc);
@@ -1079,6 +1089,32 @@ int cpdma_chan_idle_submit(struct cpdma_chan *chan, void
*token, void *data,
si.data = data;
si.len = len;
si.directed = directed;
+ si.flags = 0;
+
+ spin_lock_irqsave(>lock, flags);
+ if (chan->state == CPDMA_STATE_TEARDOWN) {
+ spin_unlock_irqrestore(>lock, flags);
+ return -EINVAL;
+ }
+
+ ret = cpdma_chan_submit_si();
+ spin_unlock_irqrestore(>lock, flags);
+ return ret;
+}
+
+int cpdma_chan_idle_submit_mapped(struct cpdma_chan *chan, void *token,
+ dma_addr_t data, int len, int directed)
+{
+ struct submit_info si;
+ unsigned long flags;
+ int ret;
+
+ si.chan = chan;
+ si.token = token;
+ si.data = (void *)(u32)data;
+ si.len = len;
+ si.directed = directed;
+ si.flags = CPDMA_DMA_EXT_MAP;
spin_lock_irqsave(>lock, flags);
if (chan->state == CPDMA_STATE_TEARDOWN) {
@@ -1103,6 +1139,32 @@ int cpdma_chan_submit(struct cpdma_chan *chan, void
*token, void *data,
si.data = data;
si.len = len;
si.directed = directed;
+ si.flags = 0;
+
+ spin_lock_irqsave(>lock, flags);
+ if (chan->state != CPDMA_STATE_ACTIVE) {
+ spin_unlock_irqrestore(>lock, flags);
+ return -EINVAL;
+ }
+
+ ret = cpdma_chan_submit_si();
+ spin_unlock_irqrestore(>lock, flags);
+ return ret;
+}
+
+int cpdma_chan_submit_mapped(struct cpdma_chan *chan, void *token,
+dma_addr_t data, int len, int directed)
+{
+ struct submit_info si;
+ unsigned long flags;
+ int ret;
+
+ si.chan = chan;
+ si.token = token;
+ si.data = (void *)(u32)data;
+ si.len = len;
+ si.directed = directed;
+ si.flags = CPDMA_DMA_EXT_MAP;
spin_lock_irqsave(>lock, flags);
[PATCH v7 net-next 3/5] net: ethernet: ti: davinci_cpdma: allow desc split while down
That's possible to set ring params while interfaces are down. When
interface gets up it uses number of descs to fill rx queue and on
later on changes to create rx pools. Usually, this resplit can happen
after phy is up, but it can be needed before this, so allow it to
happen while setting number of rx descs, when interfaces are down.
Also, if no dependency on intf state, move it to cpdma layer, where
it should be.
Signed-off-by: Ivan Khoronzhuk
---
drivers/net/ethernet/ti/cpsw_ethtool.c | 17 +++--
drivers/net/ethernet/ti/davinci_cpdma.c | 17 -
drivers/net/ethernet/ti/davinci_cpdma.h | 3 +--
3 files changed, 28 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/ti/cpsw_ethtool.c
b/drivers/net/ethernet/ti/cpsw_ethtool.c
index f60dc1dfc443..c477e6b620d6 100644
--- a/drivers/net/ethernet/ti/cpsw_ethtool.c
+++ b/drivers/net/ethernet/ti/cpsw_ethtool.c
@@ -650,7 +650,7 @@ int cpsw_set_ringparam(struct net_device *ndev,
{
struct cpsw_priv *priv = netdev_priv(ndev);
struct cpsw_common *cpsw = priv->cpsw;
- int ret;
+ int descs_num, ret;
/* ignore ering->tx_pending - only rx_pending adjustment is supported */
@@ -659,20 +659,25 @@ int cpsw_set_ringparam(struct net_device *ndev,
ering->rx_pending > (cpsw->descs_pool_size - CPSW_MAX_QUEUES))
return -EINVAL;
- if (ering->rx_pending == cpdma_get_num_rx_descs(cpsw->dma))
+ descs_num = cpdma_get_num_rx_descs(cpsw->dma);
+ if (ering->rx_pending == descs_num)
return 0;
cpsw_suspend_data_pass(ndev);
- cpdma_set_num_rx_descs(cpsw->dma, ering->rx_pending);
+ ret = cpdma_set_num_rx_descs(cpsw->dma, ering->rx_pending);
+ if (ret) {
+ if (cpsw_resume_data_pass(ndev))
+ goto err;
- if (cpsw->usage_count)
- cpdma_chan_split_pool(cpsw->dma);
+ return ret;
+ }
ret = cpsw_resume_data_pass(ndev);
if (!ret)
return 0;
-
+err:
+ cpdma_set_num_rx_descs(cpsw->dma, descs_num);
dev_err(cpsw->dev, "cannot set ring params, closing device\n");
dev_close(ndev);
return ret;
diff --git a/drivers/net/ethernet/ti/davinci_cpdma.c
b/drivers/net/ethernet/ti/davinci_cpdma.c
index 8da46394c0e7..a3b6aeb4e935 100644
--- a/drivers/net/ethernet/ti/davinci_cpdma.c
+++ b/drivers/net/ethernet/ti/davinci_cpdma.c
@@ -1423,8 +1423,23 @@ int cpdma_get_num_tx_descs(struct cpdma_ctlr *ctlr)
return ctlr->num_tx_desc;
}
-void cpdma_set_num_rx_descs(struct cpdma_ctlr *ctlr, int num_rx_desc)
+int cpdma_set_num_rx_descs(struct cpdma_ctlr *ctlr, int num_rx_desc)
{
+ unsigned long flags;
+ int temp, ret;
+
+ spin_lock_irqsave(>lock, flags);
+
+ temp = ctlr->num_rx_desc;
ctlr->num_rx_desc = num_rx_desc;
ctlr->num_tx_desc = ctlr->pool->num_desc - ctlr->num_rx_desc;
+ ret = cpdma_chan_split_pool(ctlr);
+ if (ret) {
+ ctlr->num_rx_desc = temp;
+ ctlr->num_tx_desc = ctlr->pool->num_desc - ctlr->num_rx_desc;
+ }
+
+ spin_unlock_irqrestore(>lock, flags);
+
+ return ret;
}
diff --git a/drivers/net/ethernet/ti/davinci_cpdma.h
b/drivers/net/ethernet/ti/davinci_cpdma.h
index 0271a20c2e09..d3cfe234d16a 100644
--- a/drivers/net/ethernet/ti/davinci_cpdma.h
+++ b/drivers/net/ethernet/ti/davinci_cpdma.h
@@ -116,8 +116,7 @@ enum cpdma_control {
int cpdma_control_get(struct cpdma_ctlr *ctlr, int control);
int cpdma_control_set(struct cpdma_ctlr *ctlr, int control, int value);
int cpdma_get_num_rx_descs(struct cpdma_ctlr *ctlr);
-void cpdma_set_num_rx_descs(struct cpdma_ctlr *ctlr, int num_rx_desc);
+int cpdma_set_num_rx_descs(struct cpdma_ctlr *ctlr, int num_rx_desc);
int cpdma_get_num_tx_descs(struct cpdma_ctlr *ctlr);
-int cpdma_chan_split_pool(struct cpdma_ctlr *ctlr);
#endif
--
2.17.1
[PATCH v7 net-next 0/5] net: ethernet: ti: cpsw: Add XDP support
This patchset adds XDP support for TI cpsw driver and base it on page_pool allocator. It was verified on af_xdp socket drop, af_xdp l2f, ebpf XDP_DROP, XDP_REDIRECT, XDP_PASS, XDP_TX. It was verified with following configs enabled: CONFIG_JIT=y CONFIG_BPFILTER=y CONFIG_BPF_SYSCALL=y CONFIG_XDP_SOCKETS=y CONFIG_BPF_EVENTS=y CONFIG_HAVE_EBPF_JIT=y CONFIG_BPF_JIT=y CONFIG_CGROUP_BPF=y Link on previous v6: https://lkml.org/lkml/2019/7/3/243 Also regular tests with iperf2 were done in order to verify impact on regular netstack performance, compared with base commit: https://pastebin.com/JSMT0iZ4 v6..v7: - rolled back to v4 solution but with small modification - picked up patch: https://www.spinics.net/lists/netdev/msg583145.html - added changes related to netsec fix and cpsw v5..v6: - do changes that is rx_dev while redirect/flush cycle is kept the same - dropped net: ethernet: ti: davinci_cpdma: return handler status - other changes desc in patches v4..v5: - added two plreliminary patches: net: ethernet: ti: davinci_cpdma: allow desc split while down net: ethernet: ti: cpsw_ethtool: allow res split while down - added xdp alocator refcnt on xdp level, avoiding page pool refcnt - moved flush status as separate argument for cpdma_chan_process - reworked cpsw code according to last changes to allocator - added missed statistic counter v3..v4: - added page pool user counter - use same pool for ndevs in dual mac - restructured page pool create/destroy according to the last changes in API v2..v3: - each rxq and ndev has its own page pool v1..v2: - combined xdp_xmit functions - used page allocation w/o refcnt juggle - unmapped page for skb netstack - moved rxq/page pool allocation to open/close pair - added several preliminary patches: net: page_pool: add helper function to retrieve dma addresses net: page_pool: add helper function to unmap dma addresses net: ethernet: ti: cpsw: use cpsw as drv data net: ethernet: ti: cpsw_ethtool: simplify slave loops Ivan Khoronzhuk (5): net: core: page_pool: add user refcnt and reintroduce page_pool_destroy net: ethernet: ti: davinci_cpdma: add dma mapped submit net: ethernet: ti: davinci_cpdma: allow desc split while down net: ethernet: ti: cpsw_ethtool: allow res split while down net: ethernet: ti: cpsw: add XDP support .../net/ethernet/mellanox/mlx5/core/en_main.c | 4 +- drivers/net/ethernet/socionext/netsec.c | 8 +- drivers/net/ethernet/ti/Kconfig | 1 + drivers/net/ethernet/ti/cpsw.c| 502 -- drivers/net/ethernet/ti/cpsw_ethtool.c| 57 +- drivers/net/ethernet/ti/cpsw_priv.h | 7 + drivers/net/ethernet/ti/davinci_cpdma.c | 106 +++- drivers/net/ethernet/ti/davinci_cpdma.h | 7 +- include/net/page_pool.h | 25 + net/core/page_pool.c | 8 + net/core/xdp.c| 3 + 11 files changed, 640 insertions(+), 88 deletions(-) -- 2.17.1
[PATCH v7 net-next 1/5] net: core: page_pool: add user refcnt and reintroduce page_pool_destroy
Jesper recently removed page_pool_destroy() (from driver invocation)
and moved shutdown and free of page_pool into xdp_rxq_info_unreg(),
in-order to handle in-flight packets/pages. This created an asymmetry
in drivers create/destroy pairs.
This patch reintroduce page_pool_destroy and add page_pool user
refcnt. This serves the purpose to simplify drivers error handling as
driver now drivers always calls page_pool_destroy() and don't need to
track if xdp_rxq_info_reg_mem_model() was unsuccessful.
This could be used for a special cases where a single RX-queue (with a
single page_pool) provides packets for two net_device'es, and thus
needs to register the same page_pool twice with two xdp_rxq_info
structures.
This patch is primarily to ease API usage for drivers. The recently
merged netsec driver, actually have a bug in this area, which is
solved by this API change.
This patch is a modified version of Ivan Khoronzhu's original patch.
Link:
https://lore.kernel.org/netdev/20190625175948.24771-2-ivan.khoronz...@linaro.org/
Fixes: 5c67bf0ec4d0 ("net: netsec: Use page_pool API")
Signed-off-by: Jesper Dangaard Brouer
Reviewed-by: Ilias Apalodimas
Signed-off-by: Ivan Khoronzhuk
---
.../net/ethernet/mellanox/mlx5/core/en_main.c | 4 +--
drivers/net/ethernet/socionext/netsec.c | 8 ++
include/net/page_pool.h | 25 +++
net/core/page_pool.c | 8 ++
net/core/xdp.c| 3 +++
5 files changed, 40 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
index 2f9093ba82aa..ac882b2341d0 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
@@ -575,8 +575,6 @@ static int mlx5e_alloc_rq(struct mlx5e_channel *c,
}
err = xdp_rxq_info_reg_mem_model(>xdp_rxq,
MEM_TYPE_PAGE_POOL,
rq->page_pool);
- if (err)
- page_pool_free(rq->page_pool);
}
if (err)
goto err_free;
@@ -644,6 +642,7 @@ static int mlx5e_alloc_rq(struct mlx5e_channel *c,
if (rq->xdp_prog)
bpf_prog_put(rq->xdp_prog);
xdp_rxq_info_unreg(>xdp_rxq);
+ page_pool_destroy(rq->page_pool);
mlx5_wq_destroy(>wq_ctrl);
return err;
@@ -678,6 +677,7 @@ static void mlx5e_free_rq(struct mlx5e_rq *rq)
}
xdp_rxq_info_unreg(>xdp_rxq);
+ page_pool_destroy(rq->page_pool);
mlx5_wq_destroy(>wq_ctrl);
}
diff --git a/drivers/net/ethernet/socionext/netsec.c
b/drivers/net/ethernet/socionext/netsec.c
index 5544a722543f..43ab0ce90704 100644
--- a/drivers/net/ethernet/socionext/netsec.c
+++ b/drivers/net/ethernet/socionext/netsec.c
@@ -1210,15 +1210,11 @@ static void netsec_uninit_pkt_dring(struct netsec_priv
*priv, int id)
}
}
- /* Rx is currently using page_pool
-* since the pool is created during netsec_setup_rx_dring(), we need to
-* free the pool manually if the registration failed
-*/
+ /* Rx is currently using page_pool */
if (id == NETSEC_RING_RX) {
if (xdp_rxq_info_is_reg(>xdp_rxq))
xdp_rxq_info_unreg(>xdp_rxq);
- else
- page_pool_free(dring->page_pool);
+ page_pool_destroy(dring->page_pool);
}
memset(dring->desc, 0, sizeof(struct netsec_desc) * DESC_NUM);
diff --git a/include/net/page_pool.h b/include/net/page_pool.h
index ee9c871d2043..2cbcdbdec254 100644
--- a/include/net/page_pool.h
+++ b/include/net/page_pool.h
@@ -101,6 +101,12 @@ struct page_pool {
struct ptr_ring ring;
atomic_t pages_state_release_cnt;
+
+ /* A page_pool is strictly tied to a single RX-queue being
+* protected by NAPI, due to above pp_alloc_cache. This
+* refcnt serves purpose is to simplify drivers error handling.
+*/
+ refcount_t user_cnt;
};
struct page *page_pool_alloc_pages(struct page_pool *pool, gfp_t gfp);
@@ -134,6 +140,15 @@ static inline void page_pool_free(struct page_pool *pool)
#endif
}
+/* Drivers use this instead of page_pool_free */
+static inline void page_pool_destroy(struct page_pool *pool)
+{
+ if (!pool)
+ return;
+
+ page_pool_free(pool);
+}
+
/* Never call this directly, use helpers below */
void __page_pool_put_page(struct page_pool *pool,
struct page *page, bool allow_direct);
@@ -201,4 +216,14 @@ static inline bool is_page_pool_compiled_in(void)
#endif
}
+static inline void page_pool_get(struct page_pool *pool)
+{
+ refcount_inc(>user_cnt);
+}
+
+static inline bool page_pool_put(struct page_pool *pool)
+{
+ return refcount_dec_and_test(>user_cnt);
+}
+
#endif /*
[PATCH v7 net-next 4/5] net: ethernet: ti: cpsw_ethtool: allow res split while down
That's possible to set channel num while interfaces are down. When interface gets up it should resplit budget. This resplit can happen after phy is up but only if speed is changed, so should be set before this, for this allow it to happen while changing number of channels, when interfaces are down. Signed-off-by: Ivan Khoronzhuk --- drivers/net/ethernet/ti/cpsw_ethtool.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/net/ethernet/ti/cpsw_ethtool.c b/drivers/net/ethernet/ti/cpsw_ethtool.c index c477e6b620d6..e4d7185fde49 100644 --- a/drivers/net/ethernet/ti/cpsw_ethtool.c +++ b/drivers/net/ethernet/ti/cpsw_ethtool.c @@ -620,8 +620,7 @@ int cpsw_set_channels_common(struct net_device *ndev, } } - if (cpsw->usage_count) - cpsw_split_res(cpsw); + cpsw_split_res(cpsw); ret = cpsw_resume_data_pass(ndev); if (!ret) -- 2.17.1
Re: suspend broken in next-20190704 on Thinkpad X60
On Thu, Jul 4, 2019 at 9:20 PM Pavel Machek wrote: > > Hi! > > Suspend is broken in next-20190704 on Thinkpad X60. Broken in what way? Any details? > It very very probably worked ok in 20190701. Well, please try the linux-next branch from linux-pm.git (git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git) alone and see if that fails.
[tip:WIP.x86/ipi 1/25] arch/x86/kernel/kgdb.c:427:28: error: 'VECTOR_NMI' undeclared; did you mean 'ESTACK_NMI'?
tree: https://kernel.googlesource.com/pub/scm/linux/kernel/git/tip/tip.git
WIP.x86/ipi
head: 64fca03f132d830b48b20a8547fb8337e89715cd
commit: 3883fea4fbeb4a505c6db87b0ba9af910e10a07e [1/25] x86/kgbd: Use
NMI_VECTOR not APIC_DM_NMI
config: x86_64-allyesconfig (attached as .config)
compiler: gcc-7 (Debian 7.4.0-6) 7.4.0
reproduce:
git checkout 3883fea4fbeb4a505c6db87b0ba9af910e10a07e
# save the attached .config to linux build tree
make ARCH=x86_64
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
arch/x86/kernel/kgdb.c: In function 'kgdb_roundup_cpus':
>> arch/x86/kernel/kgdb.c:427:28: error: 'VECTOR_NMI' undeclared (first use in
>> this function); did you mean 'ESTACK_NMI'?
apic->send_IPI_allbutself(VECTOR_NMI);
^~
ESTACK_NMI
arch/x86/kernel/kgdb.c:427:28: note: each undeclared identifier is reported
only once for each function it appears in
vim +427 arch/x86/kernel/kgdb.c
412
413 #ifdef CONFIG_SMP
414 /**
415 * kgdb_roundup_cpus - Get other CPUs into a holding pattern
416 *
417 * On SMP systems, we need to get the attention of the other CPUs
418 * and get them be in a known state. This should do what is needed
419 * to get the other CPUs to call kgdb_wait(). Note that on some
arches,
420 * the NMI approach is not used for rounding up all the CPUs. For
example,
421 * in case of MIPS, smp_call_function() is used to roundup CPUs.
422 *
423 * On non-SMP systems, this is not called.
424 */
425 void kgdb_roundup_cpus(void)
426 {
> 427 apic->send_IPI_allbutself(VECTOR_NMI);
428 }
429 #endif
430
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
[tip:WIP.x86/ipi 1/25] arch/x86/kernel/kgdb.c:427:28: error: 'VECTOR_NMI' undeclared
tree: https://kernel.googlesource.com/pub/scm/linux/kernel/git/tip/tip.git
WIP.x86/ipi
head: 64fca03f132d830b48b20a8547fb8337e89715cd
commit: 3883fea4fbeb4a505c6db87b0ba9af910e10a07e [1/25] x86/kgbd: Use
NMI_VECTOR not APIC_DM_NMI
config: i386-allmodconfig (attached as .config)
compiler: gcc-7 (Debian 7.4.0-6) 7.4.0
reproduce:
git checkout 3883fea4fbeb4a505c6db87b0ba9af910e10a07e
# save the attached .config to linux build tree
make ARCH=i386
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
arch/x86/kernel/kgdb.c: In function 'kgdb_roundup_cpus':
>> arch/x86/kernel/kgdb.c:427:28: error: 'VECTOR_NMI' undeclared (first use in
>> this function)
apic->send_IPI_allbutself(VECTOR_NMI);
^~
arch/x86/kernel/kgdb.c:427:28: note: each undeclared identifier is reported
only once for each function it appears in
vim +/VECTOR_NMI +427 arch/x86/kernel/kgdb.c
412
413 #ifdef CONFIG_SMP
414 /**
415 * kgdb_roundup_cpus - Get other CPUs into a holding pattern
416 *
417 * On SMP systems, we need to get the attention of the other CPUs
418 * and get them be in a known state. This should do what is needed
419 * to get the other CPUs to call kgdb_wait(). Note that on some
arches,
420 * the NMI approach is not used for rounding up all the CPUs. For
example,
421 * in case of MIPS, smp_call_function() is used to roundup CPUs.
422 *
423 * On non-SMP systems, this is not called.
424 */
425 void kgdb_roundup_cpus(void)
426 {
> 427 apic->send_IPI_allbutself(VECTOR_NMI);
428 }
429 #endif
430
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH] cpu/hotplug: Cache number of online CPUs
On Thu, 4 Jul 2019, Mathieu Desnoyers wrote: > - On Jul 4, 2019, at 5:10 PM, Thomas Gleixner t...@linutronix.de wrote: > > > > num_online_cpus() is racy today vs. CPU hotplug operations as > > long as you don't hold the hotplug lock. > > Fair point, AFAIU none of the loads performed within num_online_cpus() > seem to rely on atomic nor volatile accesses. So not using a volatile > access to load the cached value should not introduce any regression. > > I'm concerned that some code may rely on re-fetching of the cached > value between iterations of a loop. The lack of READ_ONCE() would > let the compiler keep a lifted load within a register and never > re-fetch, unless there is a cpu_relax() or a barrier() within the > loop. If someone really wants to write code which can handle concurrent CPU hotplug operations and rely on that information, then it's probably better to write out: ncpus = READ_ONCE(__num_online_cpus); explicitely along with a big fat comment. I can't figure out why one wants to do that and how it is supposed to work, but my brain is in shutdown mode already :) I'd rather write a proper kernel doc comment for num_online_cpus() which explains what the constraints are instead of pretending that the READ_ONCE in the inline has any meaning. Thanks, tglx
Re: [PATCH] media: bcm2048: Macros with complex values should be enclosed in parentheses
Hi Lukas,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linuxtv-media/master]
[cannot apply to v5.2-rc7 next-20190704]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Lukas-Schneider/media-bcm2048-Macros-with-complex-values-should-be-enclosed-in-parentheses/20190628-003532
base: git://linuxtv.org/media_tree.git master
config: i386-allyesconfig (attached as .config)
compiler: gcc-7 (Debian 7.4.0-6) 7.4.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
>> drivers/staging/media/bcm2048/radio-bcm2048.c:2004:1: error: expected
>> identifier or '(' before 'do'
do { \
^
drivers/staging/media/bcm2048/radio-bcm2048.c:2033:1: note: in expansion of
macro 'DEFINE_SYSFS_PROPERTY'
DEFINE_SYSFS_PROPERTY(power_state, unsigned int, "%u", 0)
^
>> drivers/staging/media/bcm2048/radio-bcm2048.c:2007:3: error: expected
>> identifier or '(' before 'while'
} while (0)\
^
drivers/staging/media/bcm2048/radio-bcm2048.c:2033:1: note: in expansion of
macro 'DEFINE_SYSFS_PROPERTY'
DEFINE_SYSFS_PROPERTY(power_state, unsigned int, "%u", 0)
^
>> drivers/staging/media/bcm2048/radio-bcm2048.c:2007:3: error: expected
>> identifier or '(' before 'while'
} while (0)\
^
drivers/staging/media/bcm2048/radio-bcm2048.c:2034:1: note: in expansion of
macro 'DEFINE_SYSFS_PROPERTY'
DEFINE_SYSFS_PROPERTY(mute, unsigned int, "%u", 0)
^
>> drivers/staging/media/bcm2048/radio-bcm2048.c:2007:3: error: expected
>> identifier or '(' before 'while'
} while (0)\
^
drivers/staging/media/bcm2048/radio-bcm2048.c:2035:1: note: in expansion of
macro 'DEFINE_SYSFS_PROPERTY'
DEFINE_SYSFS_PROPERTY(audio_route, unsigned int, "%u", 0)
^
>> drivers/staging/media/bcm2048/radio-bcm2048.c:2007:3: error: expected
>> identifier or '(' before 'while'
} while (0)\
^
drivers/staging/media/bcm2048/radio-bcm2048.c:2036:1: note: in expansion of
macro 'DEFINE_SYSFS_PROPERTY'
DEFINE_SYSFS_PROPERTY(dac_output, unsigned int, "%u", 0)
^
>> drivers/staging/media/bcm2048/radio-bcm2048.c:2007:3: error: expected
>> identifier or '(' before 'while'
} while (0)\
^
drivers/staging/media/bcm2048/radio-bcm2048.c:2038:1: note: in expansion of
macro 'DEFINE_SYSFS_PROPERTY'
DEFINE_SYSFS_PROPERTY(fm_hi_lo_injection, unsigned int, "%u", 0)
^
>> drivers/staging/media/bcm2048/radio-bcm2048.c:2007:3: error: expected
>> identifier or '(' before 'while'
} while (0)\
^
drivers/staging/media/bcm2048/radio-bcm2048.c:2039:1: note: in expansion of
macro 'DEFINE_SYSFS_PROPERTY'
DEFINE_SYSFS_PROPERTY(fm_frequency, unsigned int, "%u", 0)
^
>> drivers/staging/media/bcm2048/radio-bcm2048.c:2007:3: error: expected
>> identifier or '(' before 'while'
} while (0)\
^
drivers/staging/media/bcm2048/radio-bcm2048.c:2040:1: note: in expansion of
macro 'DEFINE_SYSFS_PROPERTY'
DEFINE_SYSFS_PROPERTY(fm_af_frequency, unsigned int, "%u", 0)
^
>> drivers/staging/media/bcm2048/radio-bcm2048.c:2007:3: error: expected
>> identifier or '(' before 'while'
} while (0)\
^
drivers/staging/media/bcm2048/radio-bcm2048.c:2041:1: note: in expansion of
macro 'DEFINE_SYSFS_PROPERTY'
DEFINE_SYSFS_PROPERTY(fm_deemphasis, unsigned int, "%u", 0)
^
>> drivers/staging/media/bcm2048/radio-bcm2048.c:2007:3: error: expected
>> identifier or '(' before 'while'
} while (0)\
^
drivers/staging/media/bcm2048/radio-bcm2048.c:2042:1: note: in expansion of
macro 'DEFINE_SYSFS_PROPERTY'
DEFINE_SYSFS_PROPERTY(fm_rds_mask, unsigned int, "%u", 0)
^
>> drivers/staging/media/bcm2048/radio-bcm2048.c:2007:3: error: expected
>> identifier or '(' before 'while'
} while (0)\
^
drivers/staging/media/bcm2048/radio-bcm2048.c:2043:1: note: in expansion of
macro 'DEFINE_SYSFS_PROPERTY'
DEFINE_SYSFS_PROPERTY(fm_best_tune_mode, unsigned int, "%u", 0)
^
>> drivers/staging/media/bcm2048/radio-bcm2048.c:2007:3: error: expected
>> identifier or '(' before 'while'
} while (0)\
^
drivers/staging/media/bcm2048/radio-bcm2048.c:2044:1: note: in expansion
[PATCH v3 4/4] net: dsa: vsc73xx: Assert reset if iCPU is enabled
Driver allow to use devices with disabled iCPU only.
Some devices have pre-initialised iCPU by bootloader.
That state make switch unmanaged. This patch force reset
if device is in unmanaged state. In the result chip lost
internal firmware from RAM and it can be managed.
Signed-off-by: Pawel Dembicki
Reviewed-by: Linus Walleij
Reviewed-by: Florian Fainelli
---
drivers/net/dsa/vitesse-vsc73xx-core.c | 36 --
1 file changed, 17 insertions(+), 19 deletions(-)
diff --git a/drivers/net/dsa/vitesse-vsc73xx-core.c
b/drivers/net/dsa/vitesse-vsc73xx-core.c
index 10063f31d9a3..614377ef7956 100644
--- a/drivers/net/dsa/vitesse-vsc73xx-core.c
+++ b/drivers/net/dsa/vitesse-vsc73xx-core.c
@@ -417,22 +417,8 @@ static int vsc73xx_detect(struct vsc73xx *vsc)
}
if (val == 0x) {
- dev_info(vsc->dev, "chip seems dead, assert reset\n");
- gpiod_set_value_cansleep(vsc->reset, 1);
- /* Reset pulse should be 20ns minimum, according to datasheet
-* table 245, so 10us should be fine
-*/
- usleep_range(10, 100);
- gpiod_set_value_cansleep(vsc->reset, 0);
- /* Wait 20ms according to datasheet table 245 */
- msleep(20);
-
- ret = vsc73xx_read(vsc, VSC73XX_BLOCK_SYSTEM, 0,
- VSC73XX_ICPU_MBOX_VAL, );
- if (val == 0x) {
- dev_err(vsc->dev, "seems not to help, giving up\n");
- return -ENODEV;
- }
+ dev_info(vsc->dev, "chip seems dead.\n");
+ return -EAGAIN;
}
ret = vsc73xx_read(vsc, VSC73XX_BLOCK_SYSTEM, 0,
@@ -483,9 +469,8 @@ static int vsc73xx_detect(struct vsc73xx *vsc)
}
if (icpu_si_boot_en && !icpu_pi_en) {
dev_err(vsc->dev,
- "iCPU enabled boots from SI, no external memory\n");
- dev_err(vsc->dev, "no idea how to deal with this\n");
- return -ENODEV;
+ "iCPU enabled boots from PI/SI, no external memory\n");
+ return -EAGAIN;
}
if (!icpu_si_boot_en && icpu_pi_en) {
dev_err(vsc->dev,
@@ -1158,6 +1143,19 @@ int vsc73xx_probe(struct vsc73xx *vsc)
msleep(20);
ret = vsc73xx_detect(vsc);
+ if (ret == -EAGAIN) {
+ dev_err(vsc->dev,
+ "Chip seems to be out of control. Assert reset and try
again.\n");
+ gpiod_set_value_cansleep(vsc->reset, 1);
+ /* Reset pulse should be 20ns minimum, according to datasheet
+* table 245, so 10us should be fine
+*/
+ usleep_range(10, 100);
+ gpiod_set_value_cansleep(vsc->reset, 0);
+ /* Wait 20ms according to datasheet table 245 */
+ msleep(20);
+ ret = vsc73xx_detect(vsc);
+ }
if (ret) {
dev_err(dev, "no chip found (%d)\n", ret);
return -ENODEV;
--
2.20.1
[PATCH v3 0/4] net: dsa: Add Vitesse VSC73xx parallel mode
Main goal of this patch series is to add support for CPU attached parallel
bus in Vitesse VSC73xx switches. Existing driver supports only SPI mode.
Second change is needed for devices in unmanaged state.
V3:
- fix commit messages and descriptions about memory-mapped I/O mode
V2:
- drop changes in compatible strings
- make changes less invasive
- drop mutex in platform part and move mutex from core to spi part
- fix indentation
- fix devm_ioremap_resource result check
- add cover letter
Pawel Dembicki (4):
net: dsa: Change DT bindings for Vitesse VSC73xx switches
net: dsa: vsc73xx: Split vsc73xx driver
net: dsa: vsc73xx: add support for parallel mode
net: dsa: vsc73xx: Assert reset if iCPU is enabled
.../bindings/net/dsa/vitesse,vsc73xx.txt | 58 -
drivers/net/dsa/Kconfig | 20 +-
drivers/net/dsa/Makefile | 4 +-
...tesse-vsc73xx.c => vitesse-vsc73xx-core.c} | 206 +++---
drivers/net/dsa/vitesse-vsc73xx-platform.c| 164 ++
drivers/net/dsa/vitesse-vsc73xx-spi.c | 203 +
drivers/net/dsa/vitesse-vsc73xx.h | 29 +++
7 files changed, 499 insertions(+), 185 deletions(-)
rename drivers/net/dsa/{vitesse-vsc73xx.c => vitesse-vsc73xx-core.c} (90%)
create mode 100644 drivers/net/dsa/vitesse-vsc73xx-platform.c
create mode 100644 drivers/net/dsa/vitesse-vsc73xx-spi.c
create mode 100644 drivers/net/dsa/vitesse-vsc73xx.h
--
2.20.1
