RE: [EXT] Re: [V4 2/2] dmaengine: fsl-dpaa2-qdma: Add NXP dpaa2 qDMA controller driver for Layerscape SoCs
Hi Vinod, Ok, thanks. I will resend them after next Monday. Best Regards, Peng >-Original Message- >From: Vinod Koul >Sent: 2019年9月26日 0:34 >To: Peng Ma >Cc: dan.j.willi...@intel.com; Leo Li ; >linux-kernel@vger.kernel.org; dmaeng...@vger.kernel.org >Subject: Re: [EXT] Re: [V4 2/2] dmaengine: fsl-dpaa2-qdma: Add NXP dpaa2 >qDMA controller driver for Layerscape SoCs > >Caution: EXT Email > >On 25-09-19, 02:27, Peng Ma wrote: > >> >Can you please resend me after rc1 is out and I will review it and do >> >the needful >> [Peng Ma] Got it. By the way, when will rc1 out? > >It is supposed to be out on coming monday! > >-- >~Vinod
Re: [PATCH 1/2] spi: Add call to spi_slave_abort() function when spidev driver is released
Hi Lukasz,
On Thu, Sep 26, 2019 at 3:33 AM Lukasz Majewski wrote:
> This change is necessary for spidev devices (e.g. /dev/spidev3.0) working
> in the slave mode (like NXP's dspi driver for Vybrid SoC).
>
> When SPI HW works in this mode - the master is responsible for providing
> CS and CLK signals. However, when some fault happens - like for example
> distortion on SPI lines - the SPI Linux driver needs a chance to recover
> from this abnormal situation and prepare itself for next (correct)
> transmission.
>
> This change doesn't pose any threat on drivers working in master mode as
> spi_slave_abort() function checks if SPI slave mode is supported.
>
> Signed-off-by: Lukasz Majewski
Thanks for your patch!
Yesterday I saw this appear on spi/for-next, but I couldn't find the
email in my mbox. Today it has arrived. Looks like gmail had some troubles
("Delivered after 138401 seconds", ugh).
> --- a/drivers/spi/spidev.c
> +++ b/drivers/spi/spidev.c
> @@ -627,6 +627,7 @@ static int spidev_release(struct inode *inode, struct
> file *filp)
> if (dofree)
> kfree(spidev);
> }
> + spi_slave_abort(spidev->spi);
Looks good to me. Just wondering if this should be done for the last user only,
i.e. in the "if" block above, like resetting speed_hz?
> mutex_unlock(&device_list_lock);
>
> return 0;
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH] riscv: move flush_icache_range/user_range() after flush_icache_all()
https://lore.kernel.org/linux-riscv/mvm7e9spggv@suse.de/ Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
Re: [PATCH 1/1] MAINTAINERS: add Yanjun to FORCEDETH maintainers list
From: rain.1986.08...@gmail.com Date: Mon, 23 Sep 2019 22:37:46 +0800 > From: Rain River > > Yanjun has been spending quite a lot of time fixing bugs > in FORCEDETH source code. I'd like to add Yanjun to maintainers > list. > > Signed-off-by: Rain River Applied, thank you.
Re: [PATCH 4/4] dmaengine: Add debugfs entries for PTDMA information
On 9/24/2019 1:35 PM, gre...@linuxfoundation.org wrote:
> [CAUTION: External Email]
>
> On Tue, Sep 24, 2019 at 07:33:02AM +, Mehta, Sanju wrote:
>> +static const struct file_operations pt_debugfs_info_ops = {
>> + .owner = THIS_MODULE,
>> + .open = simple_open,
>> + .read = ptdma_debugfs_info_read,
>> + .write = NULL,
>> +};
>> +
>> +static const struct file_operations pt_debugfs_queue_ops = {
>> + .owner = THIS_MODULE,
>> + .open = simple_open,
>> + .read = ptdma_debugfs_queue_read,
>> + .write = ptdma_debugfs_queue_write,
>> +};
>> +
>> +static const struct file_operations pt_debugfs_stats_ops = {
>> + .owner = THIS_MODULE,
>> + .open = simple_open,
>> + .read = ptdma_debugfs_stats_read,
>> + .write = ptdma_debugfs_stats_write,
>> +};
> Can you use DEFINE_SIMPLE_ATTRIBUTE() here intead of these?
Okay Greg, noted. This will be resolved in next set of patches.
>
> thanks,
>
> greg k-h
Re: [PATCH 4/5] dt-bindings: usb: dwc3: of-simple: add compatible for HiSi
On Wed, 2019-09-25 at 21:06 -0700, John Stultz wrote: > On Wed, Sep 25, 2019 at 6:34 PM Chunfeng Yun > wrote: > > On Wed, 2019-09-25 at 23:42 +, John Stultz wrote: > > > +++ b/Documentation/devicetree/bindings/usb/hisi,dwc3.txt > > > @@ -0,0 +1,52 @@ > > > +HiSi SuperSpeed DWC3 USB SoC controller > > > + > > > +Required properties: > > > +- compatible:should contain "hisilicon,hi3660-dwc3" for > > > HiSi SoC > > > +- clocks:A list of phandle + clock-specifier pairs for the > > > + clocks listed in clock-names > > > +- clock-names: Should contain the following: > > > + "clk_usb3phy_ref" Phy reference clk > > It's not good idea to apply phy's clock in dwc3's node > > Hey! Thanks for taking a look at this! > > So first, my apologies, I'm not the driver author and I don't have any > real specs on the hardware other then what's in the source tree I'm > working on. Not the ideal person to be documenting the binding, but I > realized we still needed some binding documentation (although a few > other dwc-of-simple compat entries are undocumented), so this is my > rough stab at it. :/ > > Given the name clk_usb3phy_ref I'm assuming its a phy reference clock, > but I honestly don't know if I'm getting that wrong. It all seems to > be leveraging the fact that the dwc-of-simple driver batch enables and > disables all the clocks w/o really looking at the names. > > Do you have a recommendation for what would be best here? I suspect > it's necessary to enable/disable the clk in a similar path(though I'm > unfortunately traveling this week so I can't validate that). Do I try > to move the clk_usb3phy_ref clock enable/disable handling to somewhere > else? If it's phy clock, we should enable/disable it in phy driver, maybe we'd better ask for help from Yu Chen > > thanks > -john
Re: [EXT] [PATCH v3] serial: imx: adapt rx buffer and dma periods
On Wed, 2019-09-25 at 10:14 -0500, Adam Ford wrote:
> [External]
>
> On Fri, Sep 20, 2019 at 2:06 AM Philipp Puschmann
> wrote:
> > Hi Andy,
> >
> > Am 20.09.19 um 05:42 schrieb Andy Duan:
> > > From: Philipp Puschmann Sent: Thursday,
> > > September 19, 2019 10:51 PM
> > > > Using only 4 DMA periods for UART RX is very few if we have a high
> > > > frequency
> > > > of small transfers - like in our case using Bluetooth with many
> > > > small packets
> > > > via UART - causing many dma transfers but in each only filling a
> > > > fraction of a
> > > > single buffer. Such a case may lead to the situation that DMA RX
> > > > transfer is
> > > > triggered but no free buffer is available. When this happens dma
> > > > channel ist
> > > > stopped - with the patch
> > > > "dmaengine: imx-sdma: fix dma freezes" temporarily only - with the
> > > > possible
> > > > consequences that:
>
> I have an i.MX6Q with Wl1837MOD on UART 2 with flow control, and I am
> getting Bluetooth transfer timeouts.
> (see imx6-logicpd-som.dtsi)
>
> On top of 5.3.1, I have installed:
>
> dmaengine: imx-sdma: fix buffer ownership
> dmaengine: imx-sdma: fix dma freezes
> dmaengine: imx-sdma: drop redundant variable
> dmaengine: imx-sdma: fix kernel hangs with SLUB slab allocator
> serial: imx: adapt rx buffer and dma periods
>
> and I still get timeouts:
>
> [ 66.632006] Bluetooth: hci0: command 0xff36 tx timeout
> [ 76.790499] Bluetooth: hci0: command 0x1001 tx timeout
> [ 87.110488] Bluetooth: hci0: command 0xff36 tx timeout
> [ 97.270507] Bluetooth: hci0: command 0x1001 tx timeout
> [ 107.590457] Bluetooth: hci0: command 0xff36 tx timeout
> [ 117.750477] Bluetooth: hci0: command 0x1001 tx timeout
> [ 226.390499] Bluetooth: hci0: command 0xfe38 tx timeout
> [ 231.590735] Bluetooth: hci0: command tx timeout
>
> I did a bisect and found the start of my problems came from
>
> 361deb7243d2 ("dmaengine: dmatest: wrap src & dst data into a struct")
That commit only touches `drivers/dma/dmatest.c`
Are you using that module?
It's a "unit-test" module for testing DMAengine drivers.
The only way that can break anything [from what I can tell], is if it is
being run. It will probably put the DMA into a weird state (it is a test-
module after-all), and it may require some DMAs to be reset.
I admit it would be nice that the test-module would put the DMA back into a
normal-working state, but that effort could be big for some cases.
>
> This happened sometime between v5.0 and v5.1
>
> Is there a patch I missed somewhere? Do I need to change my device
> tree configuration somehow to allocate the proper DMA memory?
>
>
>
> > > > with disabled hw flow control:
> > > > If enough data is incoming on UART port the RX FIFO runs over and
> > > > characters will be lost. What then happens depends on upper
> > > > layer.
> > > >
> > > > with enabled hw flow control:
> > > > If enough data is incoming on UART port the RX FIFO reaches a
> > > > level
> > > > where CTS is deasserted and remote device sending the data stops.
> > > > If it fails to stop timely the i.MX' RX FIFO may run over and
> > > > data
> > > > get lost. Otherwise it's internal TX buffer may getting filled to
> > > > a point where it runs over and data is again lost. It depends on
> > > > the remote device how this case is handled and if it is
> > > > recoverable.
> > > >
> > > > Obviously we want to avoid having no free buffers available. So we
> > > > decrease
> > > > the size of the buffers and increase their number and the total
> > > > buffer size.
> > > >
> > > > Signed-off-by: Philipp Puschmann
> > > > Reviewed-by: Lucas Stach
> > > > ---
> > > >
> > > > Changelog v3:
> > > > - enhance description
> > > >
> > > > Changelog v2:
> > > > - split this patch from series "Fix UART DMA freezes for iMX6"
> > > > - add Reviewed-by tag
> > > >
> > > > drivers/tty/serial/imx.c | 5 ++---
> > > > 1 file changed, 2 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
> > > > index
> > > > 87c58f9f6390..51dc19833eab 100644
> > > > --- a/drivers/tty/serial/imx.c
> > > > +++ b/drivers/tty/serial/imx.c
> > > > @@ -1034,8 +1034,6 @@ static void imx_uart_timeout(struct
> > > > timer_list *t)
> > > > }
> > > > }
> > > >
> > > > -#define RX_BUF_SIZE(PAGE_SIZE)
> > > > -
> > > > /*
> > > > * There are two kinds of RX DMA interrupts(such as in the MX6Q):
> > > > * [1] the RX DMA buffer is full.
> > > > @@ -1118,7 +1116,8 @@ static void imx_uart_dma_rx_callback(void
> > > > *data) }
> > > >
> > > > /* RX DMA buffer periods */
> > > > -#define RX_DMA_PERIODS 4
> > > > +#define RX_DMA_PERIODS 16
> > > > +#define RX_BUF_SIZE(PAGE_SIZE / 4)
> > > >
> > > Why to decrease the DMA RX buffer size here ?
> > >
> > > The current DMA implementation support DMA cyclic mode, one SDMA BD
> > > receive one Bluetooth frame can
> > > bring better performance.
> > > As you know, fo
[PATCH net] net: socionext: ave: Avoid using netdev_err() before calling register_netdev()
Until calling register_netdev(), ndev->dev_name isn't specified, and
netdev_err() displays "(unnamed net_device)".
ave 6500.ethernet (unnamed net_device) (uninitialized): invalid
phy-mode setting
ave: probe of 6500.ethernet failed with error -22
This replaces netdev_err() with dev_err() before calling register_netdev().
Signed-off-by: Kunihiko Hayashi
---
drivers/net/ethernet/socionext/sni_ave.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/socionext/sni_ave.c
b/drivers/net/ethernet/socionext/sni_ave.c
index 10d0c3e..f20f6c4 100644
--- a/drivers/net/ethernet/socionext/sni_ave.c
+++ b/drivers/net/ethernet/socionext/sni_ave.c
@@ -1662,19 +1662,19 @@ static int ave_probe(struct platform_device *pdev)
"socionext,syscon-phy-mode",
1, 0, &args);
if (ret) {
- netdev_err(ndev, "can't get syscon-phy-mode property\n");
+ dev_err(dev, "can't get syscon-phy-mode property\n");
goto out_free_netdev;
}
priv->regmap = syscon_node_to_regmap(args.np);
of_node_put(args.np);
if (IS_ERR(priv->regmap)) {
- netdev_err(ndev, "can't map syscon-phy-mode\n");
+ dev_err(dev, "can't map syscon-phy-mode\n");
ret = PTR_ERR(priv->regmap);
goto out_free_netdev;
}
ret = priv->data->get_pinmode(priv, phy_mode, args.args[0]);
if (ret) {
- netdev_err(ndev, "invalid phy-mode setting\n");
+ dev_err(dev, "invalid phy-mode setting\n");
goto out_free_netdev;
}
--
2.7.4
Re: [PATCH] bluetooth: hci_nokia: Save a few cycles in 'nokia_enqueue()'
Hi Christophe, > 'skb_pad()' a few lines above already initializes the "padded" byte to 0. > So there is no need to do it twice. > > All what is needed is to increase the len of the skb. So 'skb_put(..., 1)' > is enough here. > > Signed-off-by: Christophe JAILLET > --- > drivers/bluetooth/hci_nokia.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) patch has been applied to bluetooth-next tree. Regards Marcel
Re: [PATCH net] Bluetooth: SMP: remove set but not used variable 'smp'
Hi Yue,
> On Sep 23, 2019, at 16:05, YueHaibing wrote:
>
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> net/bluetooth/smp.c: In function 'smp_irk_matches':
> net/bluetooth/smp.c:505:18: warning:
> variable 'smp' set but not used [-Wunused-but-set-variable]
>
> net/bluetooth/smp.c: In function 'smp_generate_rpa':
> net/bluetooth/smp.c:526:18: warning:
> variable 'smp' set but not used [-Wunused-but-set-variable]
>
> It is not used since commit 28a220aac596 ("bluetooth: switch
> to AES library")
>
> Signed-off-by: YueHaibing
> ---
> net/bluetooth/smp.c | 6 --
> 1 file changed, 6 deletions(-)
patch has been applied to bluetooth-next tree.
Regards
Marcel
Re: [PATCHv2] Bluetooth: trivial: tidy up printk message output from btrtl.
Hi Rui, > v2: also remove new line from hci_h5.c > > The rtl_dev_* calls in the Realtek USB Bluetooth driver add unnecessary > device prefixes and new lines at the end of most messages, which make the > dmesg output look like this: > > [5.667121] sd 0:0:0:0: [sda] Attached SCSI disk > [5.736869] Bluetooth: hci0: RTL: rtl: examining hci_ver=06 hci_rev=000a > lmp_ver=06 lmp_subver=8821 > > [5.737853] Bluetooth: hci0: RTL: rom_version status=0 version=1 > > [5.737857] Bluetooth: hci0: RTL: rtl: loading rtl_bt/rtl8821a_fw.bin > > [5.737946] Bluetooth: hci0: RTL: rtl: loading rtl_bt/rtl8821a_config.bin > > [5.737965] bluetooth hci0: Direct firmware load for > rtl_bt/rtl8821a_config.bin failed with error -2 > [5.737972] Bluetooth: hci0: RTL: cfg_sz -2, total sz 17428 > > [5.997375] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300) > > Clean this up by removing extraneous new lines and redundant device prefixes, > with the following result: > > [5.667008] sd 0:0:0:0: [sda] Attached SCSI disk > [5.716945] Bluetooth: hci0: rtl: examining hci_ver=06 hci_rev=000a > lmp_ver=06 lmp_subver=8821 > [5.718745] Bluetooth: hci0: rtl: rom_version status=0 version=1 > [5.718749] Bluetooth: hci0: rtl: loading rtl_bt/rtl8821a_fw.bin > [5.718830] Bluetooth: hci0: rtl: loading rtl_bt/rtl8821a_config.bin > [5.718849] bluetooth hci0: Direct firmware load for > rtl_bt/rtl8821a_config.bin failed with error -2 > [5.718858] Bluetooth: hci0: rtl: cfg_sz -2, total sz 17428 > [5.997400] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300) > > Signed-off-by: Rui Salvaterra > --- > drivers/bluetooth/btrtl.c | 62 +++--- > drivers/bluetooth/btrtl.h | 8 ++--- > drivers/bluetooth/hci_h5.c | 2 +- > 3 files changed, 36 insertions(+), 36 deletions(-) I have some similar patch in my tree. Can you check what is still missing and send a new version. Thanks. Regards Marcel
Re: [PATCH] Bluetooth: btrtl: Fix an issue for the incorrect error return code.
Hi Max, > It does not need the '-' for PTR_ERR(skb) because PTR_ERR(skb) will > return the negative value during errors. > > Signed-off-by: Max Chou > --- > drivers/bluetooth/btrtl.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) patch has been applied to bluetooth-next tree. Regards Marcel
Re: [PATCH 4/4] dmaengine: Add debugfs entries for PTDMA information
On 9/24/2019 1:35 PM, gre...@linuxfoundation.org wrote:
> [CAUTION: External Email]
>
> On Tue, Sep 24, 2019 at 07:33:02AM +, Mehta, Sanju wrote:
>> +static const struct file_operations pt_debugfs_info_ops = {
>> + .owner = THIS_MODULE,
>> + .open = simple_open,
>> + .read = ptdma_debugfs_info_read,
>> + .write = NULL,
>> +};
>> +
>> +static const struct file_operations pt_debugfs_queue_ops = {
>> + .owner = THIS_MODULE,
>> + .open = simple_open,
>> + .read = ptdma_debugfs_queue_read,
>> + .write = ptdma_debugfs_queue_write,
>> +};
>> +
>> +static const struct file_operations pt_debugfs_stats_ops = {
>> + .owner = THIS_MODULE,
>> + .open = simple_open,
>> + .read = ptdma_debugfs_stats_read,
>> + .write = ptdma_debugfs_stats_write,
>> +};
> Can you use DEFINE_SIMPLE_ATTRIBUTE() here intead of these?
Okay Greg, noted. This will be resolved in next set of patches.
>
> thanks,
>
> greg k-h
Re: [PATCH v2 3/3] platform/x86: intel_oaktrail: Use pr_warn instead of pr_warning
On 2019/9/26 13:48, Andy Shevchenko wrote: > On Thu, Sep 26, 2019 at 4:29 AM Kefeng Wang > wrote: >> On 2019/9/25 23:04, Andy Shevchenko wrote: >>> On Fri, Sep 20, 2019 at 1:55 PM Kefeng Wang >>> wrote: >>> You have to send to proper mailing lists and people. >> Used get_maintainer.pl to find the people, and all already in the CC, will >> add proper maillist into each patch. >> >>> Don't spam the rest! >> Not so clearly, should I not CC other people not in the list below? >> >> [wkf@localhost linux]$ ./scripts/get_maintainer.pl >> pr_warning/v3/0018-platform-x86-eeepc-laptop-Use-pr_warn-instead-of-pr_.patch >> Corentin Chary (maintainer:ASUS NOTEBOOKS AND >> EEEPC ACPI/WMI EXTRAS DRIVERS) >> Darren Hart (odd fixer:X86 PLATFORM DRIVERS) >> Andy Shevchenko (odd fixer:X86 PLATFORM DRIVERS) > You put a lot more people in Cc, than above list contains. This is a treewide change, and finally kill pr_warning in the whole linux code, so I add more people into Cc list. Here is a brief discussion about how this be picked up, is this ok for you? https://lore.kernel.org/lkml/82fe3d04-2985-7844-31bb-269655c83...@huawei.com/ > >> acpi4asus-u...@lists.sourceforge.net (open list:ASUS NOTEBOOKS AND EEEPC >> ACPI/WMI EXTRAS DRIVERS) >> platform-driver-...@vger.kernel.org (open list:ASUS NOTEBOOKS AND EEEPC >> ACPI/WMI EXTRAS DRIVERS) > This had been absent in your submission. Ok , will be more careful about this next time. Thanks. > >> linux-kernel@vger.kernel.org (open list)
[PATCH 3/4] arm64: vdso32: Fix compilation warning
As reported by Will Deacon the following compilation warning appears
during the compilation of the vdso32:
In file included from ./arch/arm64/include/asm/thread_info.h:17:0,
from ./include/linux/thread_info.h:38,
from ./arch/arm64/include/asm/preempt.h:5,
from ./include/linux/preempt.h:78,
from ./include/linux/spinlock.h:51,
from ./include/linux/seqlock.h:36,
from ./include/linux/time.h:6,
from .../work/linux/lib/vdso/gettimeofday.c:7,
from :0:
./arch/arm64/include/asm/memory.h: In function ‘__tag_set’:
./arch/arm64/include/asm/memory.h:233:15: warning: cast from pointer to
integer of different size [-Wpointer-to-int-cast]
u64 __addr = (u64)addr & ~__tag_shifted(0xff);
^
In file included from ./arch/arm64/include/asm/pgtable-hwdef.h:8:0,
from ./arch/arm64/include/asm/processor.h:34,
from ./arch/arm64/include/asm/elf.h:118,
from ./include/linux/elf.h:5,
from ./include/linux/elfnote.h:62,
from arch/arm64/kernel/vdso32/note.c:11:
./arch/arm64/include/asm/memory.h: In function ‘__tag_set’:
./arch/arm64/include/asm/memory.h:233:15: warning: cast from pointer to
integer of different size [-Wpointer-to-int-cast]
u64 __addr = (u64)addr & ~__tag_shifted(0xff);
^
This happens because few 64 bit compilation headers are included during
the generation of vdso32.
Fix the issue redefining the __tag_set function.
Note: This fix is meant to be temporary, a more comprehensive solution
based on the refactoring of the generic headers will be provided with a
future patch set. At that point it will be possible to revert this patch.
Cc: Will Deacon
Cc: Catalin Marinas
Signed-off-by: Vincenzo Frascino
---
arch/arm64/include/asm/memory.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
index b61b50bf68b1..b1c8c43234c5 100644
--- a/arch/arm64/include/asm/memory.h
+++ b/arch/arm64/include/asm/memory.h
@@ -228,11 +228,16 @@ static inline unsigned long kaslr_offset(void)
#define __tag_get(addr)0
#endif /* CONFIG_KASAN_SW_TAGS */
+#ifdef __aarch64__
static inline const void *__tag_set(const void *addr, u8 tag)
{
u64 __addr = (u64)addr & ~__tag_shifted(0xff);
return (const void *)(__addr | __tag_shifted(tag));
}
+#else
+/* Unused in 32 bit mode */
+#define __tag_set(addr, tag) 0
+#endif
/*
* Physical vs virtual RAM address space conversion. These are
--
2.23.0
[PATCH 1/4] arm64: vdso32: Introduce COMPAT_CC_IS_GCC
As reported by Will Deacon the .config file and the generated include/config/auto.conf can end up out of sync after a set of commands since CONFIG_CROSS_COMPILE_COMPAT_VDSO is not updated correctly. The sequence can be reproduced as follows: $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- defconfig [...] $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- menuconfig [set CONFIG_CROSS_COMPILE_COMPAT_VDSO="arm-linux-gnueabihf-"] $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- Which results in: arch/arm64/Makefile:62: CROSS_COMPILE_COMPAT not defined or empty, the compat vDSO will not be built even though the compat vDSO has been built: $ file arch/arm64/kernel/vdso32/vdso.so arch/arm64/kernel/vdso32/vdso.so: ELF 32-bit LSB pie executable, ARM, EABI5 version 1 (SYSV), dynamically linked, BuildID[sha1]=c67f6c786f2d2d6f86c71f708595594aa25247f6, stripped A similar case that involves changing the configuration parameter multiple times can be reconducted to the same family of problems. The reason behind it comes from the fact that the master Makefile includes that architecture Makefile twice, once before the syncconfig and one after. Since the synchronization of the files happens only upon syncconfig, the architecture Makefile included before this event does not see the change in configuration. As a consequence of this it is not possible to handle the cross compiler definitions inside the architecture Makefile. Address the problem removing CONFIG_CROSS_COMPILE_COMPAT_VDSO and moving the detection of the correct compiler into Kconfig via COMPAT_CC_IS_GCC. As a consequence of this it is not possible anymore to set the compat cross compiler from menuconfig but it requires to be exported via command line. E.g.: $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- CROSS_COMPILE_COMPAT=arm-linux-gnueabihf Cc: Will Deacon Cc: Catalin Marinas Signed-off-by: Vincenzo Frascino --- arch/arm64/Kconfig | 5 - arch/arm64/Makefile | 15 ++- 2 files changed, 6 insertions(+), 14 deletions(-) diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index 37c610963eee..afe8c948b493 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -110,7 +110,7 @@ config ARM64 select GENERIC_STRNLEN_USER select GENERIC_TIME_VSYSCALL select GENERIC_GETTIMEOFDAY - select GENERIC_COMPAT_VDSO if (!CPU_BIG_ENDIAN && COMPAT) + select GENERIC_COMPAT_VDSO if (!CPU_BIG_ENDIAN && COMPAT && COMPAT_CC_IS_GCC) select HANDLE_DOMAIN_IRQ select HARDIRQS_SW_RESEND select HAVE_PCI @@ -313,6 +313,9 @@ config KASAN_SHADOW_OFFSET default 0xeff9 if ARM64_VA_BITS_36 && KASAN_SW_TAGS default 0x +config COMPAT_CC_IS_GCC + def_bool $(success,$(CROSS_COMPILE_COMPAT)gcc --version | head -n 1 | grep -q arm) + source "arch/arm64/Kconfig.platforms" menu "Kernel Features" diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile index 84a3d502c5a5..34f53eb11878 100644 --- a/arch/arm64/Makefile +++ b/arch/arm64/Makefile @@ -54,19 +54,8 @@ $(warning Detected assembler with broken .inst; disassembly will be unreliable) endif ifeq ($(CONFIG_GENERIC_COMPAT_VDSO), y) - CROSS_COMPILE_COMPAT ?= $(CONFIG_CROSS_COMPILE_COMPAT_VDSO:"%"=%) - - ifeq ($(CONFIG_CC_IS_CLANG), y) -$(warning CROSS_COMPILE_COMPAT is clang, the compat vDSO will not be built) - else ifeq ($(strip $(CROSS_COMPILE_COMPAT)),) -$(warning CROSS_COMPILE_COMPAT not defined or empty, the compat vDSO will not be built) - else ifeq ($(shell which $(CROSS_COMPILE_COMPAT)gcc 2> /dev/null),) -$(error $(CROSS_COMPILE_COMPAT)gcc not found, check CROSS_COMPILE_COMPAT) - else -export CROSS_COMPILE_COMPAT -export CONFIG_COMPAT_VDSO := y -compat_vdso := -DCONFIG_COMPAT_VDSO=1 - endif + export CONFIG_COMPAT_VDSO := y + compat_vdso := -DCONFIG_COMPAT_VDSO=1 endif KBUILD_CFLAGS += -mgeneral-regs-only $(lseinstr) $(brokengasinst) \ -- 2.23.0
[PATCH 2/4] arm64: vdso32: Detect binutils support for dmb ishld
As reported by Will Deacon, older versions of binutils that do not
support certain types of memory barriers can cause build failure of the
vdso32 library.
Add a compilation time mechanism that detects if binutils supports those
instructions and configure the kernel accordingly.
Cc: Will Deacon
Cc: Catalin Marinas
Signed-off-by: Vincenzo Frascino
---
arch/arm64/include/asm/vdso/compat_barrier.h | 2 +-
arch/arm64/kernel/vdso32/Makefile| 5 -
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/include/asm/vdso/compat_barrier.h
b/arch/arm64/include/asm/vdso/compat_barrier.h
index fb60a88b5ed4..3fd8fd6d8fc2 100644
--- a/arch/arm64/include/asm/vdso/compat_barrier.h
+++ b/arch/arm64/include/asm/vdso/compat_barrier.h
@@ -20,7 +20,7 @@
#define dmb(option) __asm__ __volatile__ ("dmb " #option : : : "memory")
-#if __LINUX_ARM_ARCH__ >= 8
+#if __LINUX_ARM_ARCH__ >= 8 && defined(CONFIG_AS_DMB_ISHLD)
#define aarch32_smp_mb() dmb(ish)
#define aarch32_smp_rmb() dmb(ishld)
#define aarch32_smp_wmb() dmb(ishst)
diff --git a/arch/arm64/kernel/vdso32/Makefile
b/arch/arm64/kernel/vdso32/Makefile
index 1fba0776ed40..1a3299d901b1 100644
--- a/arch/arm64/kernel/vdso32/Makefile
+++ b/arch/arm64/kernel/vdso32/Makefile
@@ -55,6 +55,9 @@ endif
VDSO_CAFLAGS += -fPIC -fno-builtin -fno-stack-protector
VDSO_CAFLAGS += -DDISABLE_BRANCH_PROFILING
+# Check for binutils support for dmb ishld
+dmbinstr := $(call as-instr,dmb ishld,-DCONFIG_AS_DMB_ISHLD=1)
+
# Try to compile for ARMv8. If the compiler is too old and doesn't support it,
# fall back to v7. There is no easy way to check for what architecture the code
# is being compiled, so define a macro specifying that (see arch/arm/Makefile).
@@ -62,7 +65,7 @@ VDSO_CAFLAGS += $(call cc32-option,-march=armv8-a
-D__LINUX_ARM_ARCH__=8,\
-march=armv7-a -D__LINUX_ARM_ARCH__=7)
VDSO_CFLAGS := $(VDSO_CAFLAGS)
-VDSO_CFLAGS += -DENABLE_COMPAT_VDSO=1
+VDSO_CFLAGS += -DENABLE_COMPAT_VDSO=1 $(dmbinstr)
# KBUILD_CFLAGS from top-level Makefile
VDSO_CFLAGS += -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \
-fno-strict-aliasing -fno-common \
--
2.23.0
[PATCH 0/4] arm64: vdso32: Address various issues
Hi Will, this patch series is meant to address the various compilation issues you reported about arm64 vdso32. Please let me know if there is still something missing. Thanks, Vincenzo Cc: Will Deacon Cc: Catalin Marinas Cc: Thomas Gleixner Vincenzo Frascino (4): arm64: vdso32: Introduce COMPAT_CC_IS_GCC arm64: vdso32: Detect binutils support for dmb ishld arm64: vdso32: Fix compilation warning arm64: Remove gettimeofday.S arch/arm64/Kconfig | 5 - arch/arm64/Makefile | 15 ++- arch/arm64/include/asm/memory.h | 5 + arch/arm64/include/asm/vdso/compat_barrier.h | 2 +- arch/arm64/kernel/vdso/gettimeofday.S| 0 arch/arm64/kernel/vdso32/Makefile| 5 - 6 files changed, 16 insertions(+), 16 deletions(-) delete mode 100644 arch/arm64/kernel/vdso/gettimeofday.S -- 2.23.0
[PATCH 4/4] arm64: Remove gettimeofday.S
gettimeofday.S was originally removed with the introduction of the support for Unified vDSOs in arm64 and replaced with the C implementation. The file seems again present in the repository due to a side effect of rebase. Remove the file again. Cc: Will Deacon Cc: Catalin Marinas Signed-off-by: Vincenzo Frascino --- arch/arm64/kernel/vdso/gettimeofday.S | 0 1 file changed, 0 insertions(+), 0 deletions(-) delete mode 100644 arch/arm64/kernel/vdso/gettimeofday.S diff --git a/arch/arm64/kernel/vdso/gettimeofday.S b/arch/arm64/kernel/vdso/gettimeofday.S deleted file mode 100644 index e69de29bb2d1.. -- 2.23.0
Re: [PATCH] greybus: remove excessive check in gb_connection_hd_cport_quiesce()
On Thu, Sep 26, 2019 at 12:36:56AM +0300, Denis Efremov wrote: > Function pointer "hd->driver->cport_quiesce" is already checked > at the beginning of gb_connection_hd_cport_quiesce(). Thus, the > second check can be removed. > > Signed-off-by: Denis Efremov > --- > drivers/greybus/connection.c | 3 --- > 1 file changed, 3 deletions(-) > > diff --git a/drivers/greybus/connection.c b/drivers/greybus/connection.c > index fc8f57f97ce6..e3799a53a193 100644 > --- a/drivers/greybus/connection.c > +++ b/drivers/greybus/connection.c > @@ -361,9 +361,6 @@ static int gb_connection_hd_cport_quiesce(struct > gb_connection *connection) > if (connection->mode_switch) > peer_space += sizeof(struct gb_operation_msg_hdr); > > - if (!hd->driver->cport_quiesce) > - return 0; > - > ret = hd->driver->cport_quiesce(hd, connection->hd_cport_id, > peer_space, > GB_CONNECTION_CPORT_QUIESCE_TIMEOUT); Nice catch, thanks. Acked-by: Johan Hovold
Re: [GIT PULL] perf/core improvements and fixes
* Arnaldo Carvalho de Melo wrote: > Hi Ingo/Thomas, > > Please consider pulling, > > Best regards, > > - Arnaldo > > Test results at the end of this message, as usual. > > The following changes since commit 2b32769700f857a8e608a8ee24080833889965b9: > > Merge tag 'perf-urgent-for-mingo-5.4-20190921' of > git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/urgent > (2019-09-22 12:45:11 +0200) > > are available in the Git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git > tags/perf-core-for-mingo-5.5-20190925 > > for you to fetch changes up to d6840d87b2d148e19e244ad2b44d28ba07f437a0: > > perf parser: Remove needless include directives (2019-09-25 16:26:41 -0300) > > > perf/core improvements and fixes: > > perf record: > > Stephane Eranian: > > - Fix priv level with branch sampling for paranoid=2, i.e. the kernel checks > if perf_event_attr_attr.exclude_hv is set in addition to .exclude_kernel, > so reset both to zero. > > Arnaldo Carvalho de Melo: > > - Don't warn about not being able to read kernel maps (kallsyms, etc) when > kernel samples aren't being collected. > > perf list: > > Kim Phillips: > > - Allow plurals for metric, metricgroup., i.e.: > > $ perf list metrics > > was showing nothing, which is very confusing, make it work like: > > $ perf stat metric > > perf stat: > > Andi Kleen: > > - Free memory access/leaks detected via valgrind, related to metrics. > > Libraries: > > libperf: > > Jiri Olsa: > > - Move more stuff from tools/perf, this time a first stab at moving > perf_mmap > methods. > > libtracevent: > > Steven Rostedt (VMware): > > - Round up in tep_print_event() time precision. > > Tzvetomir Stoyanov (VMware): > > - Man pages for event print and related and plugins APIs. > > - Move traceevent plugins in its own subdirectory. > > Feature detection: > > Thomas Richter: > > - Add detection of java-11-openjdk-devel package, in addition to the older > versions supported. > > Architecture specific: > > S/390: > > Thomas Richter (2): > > - Include JVMTI support for s390 > > Vendor events: > > AMD: > > Kim Phillips: > > - Add L3 cache events for Family 17h. > > - Remove redundant '['. > > PowerPC: > > Mamatha Inamdar: > > - Remove P8 HW events which are not supported. > > Cleanups: > > Arnaldo Carvalho de Melo: > > - Remove needless headers, add needed ones, move things around to reduce the > headers dependency tree, speeding up builds by not doing needless compiles > when unrelated stuff gets changed. > > - Ditch unused code that was dragging headers. > > Signed-off-by: Arnaldo Carvalho de Melo > > > Andi Kleen (2): > perf stat: Fix free memory access / memory leaks in metrics > perf evlist: Fix access of freed id arrays > > Arnaldo Carvalho de Melo (12): > perf record: Move restricted maps check to after a possible fallback to > not collect kernel samples > perf evlist: Adopt backwards ring buffer state enum > libperf: Add missing 'struct xyarray' forward declaration > perf tools: No need to include internal/lib.h from util/util.h > libperf: Use sys/types.h to get ssize_t, not unistd.h > perf copyfile: Move copyfile routines to separate files > perf evsel: Remove need for symbol_conf in evsel_fprintf.c > perf evsel: Introduce evsel_fprintf.h > perf evlist: Remove unused perf_evlist__fprintf() method > perf evsel: Move config terms to a separate header > perf tools: Replace needless mmap.h with what is needed, event.h > perf parser: Remove needless include directives > > Jiri Olsa (37): > tools: Add missing stdio.h include to asm/bug.h header > perf tools: Rename 'struct perf_mmap' to 'struct mmap' > perf tools: Rename perf_evlist__mmap() to evlist__mmap() > perf tools: Rename perf_evlist__munmap() to evlist__munmap() > perf tools: Rename perf_evlist__alloc_mmap() to evlist__alloc_mmap() > perf tools: Rename perf_evlist__exit() to evlist__exit() > perf tools: Rename perf_evlist__purge() to evlist__purge() > libperf: Link libapi.a in libperf.so > libperf: Add perf_mmap struct > libperf: Ad
RE: [PATCH -next 3/8] dmaengine: xilinx_dma: Introduce xilinx_dma_get_residue
> -Original Message-
> From: Vinod Koul
> Sent: Thursday, September 26, 2019 2:31 AM
> To: Radhey Shyam Pandey
> Cc: dan.j.willi...@intel.com; Michal Simek ;
> nick.graum...@gmail.com; andrea.mere...@gmail.com; Appana Durga
> Kedareswara Rao ; mcg...@kernel.org;
> dmaeng...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH -next 3/8] dmaengine: xilinx_dma: Introduce
> xilinx_dma_get_residue
>
> On 05-09-19, 22:06, Radhey Shyam Pandey wrote:
> > From: Nicholas Graumann
> >
> > Introduce a function that can calculate residues for IPs that support it:
> > AXI DMA and CDMA.
> >
> > Signed-off-by: Nicholas Graumann
> > Signed-off-by: Radhey Shyam Pandey
>
> > ---
> > drivers/dma/xilinx/xilinx_dma.c | 75
> > ++---
> > 1 file changed, 56 insertions(+), 19 deletions(-)
> >
> > diff --git a/drivers/dma/xilinx/xilinx_dma.c
> > b/drivers/dma/xilinx/xilinx_dma.c index 9909bfb..4094adb 100644
> > --- a/drivers/dma/xilinx/xilinx_dma.c
> > +++ b/drivers/dma/xilinx/xilinx_dma.c
> > @@ -787,6 +787,51 @@ static void xilinx_dma_free_chan_resources(struct
> > dma_chan *dchan) }
> >
> > /**
> > + * xilinx_dma_get_residue - Compute residue for a given descriptor
> > + * @chan: Driver specific dma channel
> > + * @desc: dma transaction descriptor
> > + *
> > + * Return: The number of residue bytes for the descriptor.
> > + */
> > +static u32 xilinx_dma_get_residue(struct xilinx_dma_chan *chan,
> > + struct xilinx_dma_tx_descriptor *desc) {
> > + struct xilinx_cdma_tx_segment *cdma_seg;
> > + struct xilinx_axidma_tx_segment *axidma_seg;
> > + struct xilinx_cdma_desc_hw *cdma_hw;
> > + struct xilinx_axidma_desc_hw *axidma_hw;
> > + struct list_head *entry;
> > + u32 residue = 0;
> > +
> > + /**
>
> it should be:
> /*
> * comment...
>
Thanks for pointing it out. I will fix it in v2.
> > +* VDMA and simple mode do not support residue reporting, so the
> > +* residue field will always be 0.
> > +*/
> > + if (chan->xdev->dma_config->dmatype == XDMA_TYPE_VDMA ||
> !chan->has_sg)
> > + return residue;
>
> why not check this in status callback?
Assuming we mean to move vdma and non-sg check to xilinx_dma_tx_status.
Just a thought- Keeping this check in xilinx_dma_get_residue provides
an abstraction and caller can simply call this func with knowing about
IP config specific residue calculation. Considering this point does it
looks ok ?
>
> > +
> > + list_for_each(entry, &desc->segments) {
> > + if (chan->xdev->dma_config->dmatype ==
> XDMA_TYPE_CDMA) {
> > + cdma_seg = list_entry(entry,
> > + struct xilinx_cdma_tx_segment,
> > + node);
> > + cdma_hw = &cdma_seg->hw;
> > + residue += (cdma_hw->control - cdma_hw->status)
> &
> > + chan->xdev->max_buffer_len;
> > + } else {
> > + axidma_seg = list_entry(entry,
> > + struct
> xilinx_axidma_tx_segment,
> > + node);
> > + axidma_hw = &axidma_seg->hw;
> > + residue += (axidma_hw->control - axidma_hw-
> >status) &
> > + chan->xdev->max_buffer_len;
> > + }
> > + }
> > +
> > + return residue;
> > +}
> > +
> > +/**
> > * xilinx_dma_chan_handle_cyclic - Cyclic dma callback
> > * @chan: Driver specific dma channel
> > * @desc: dma transaction descriptor
> > @@ -995,33 +1040,22 @@ static enum dma_status
> > xilinx_dma_tx_status(struct dma_chan *dchan, {
> > struct xilinx_dma_chan *chan = to_xilinx_chan(dchan);
> > struct xilinx_dma_tx_descriptor *desc;
> > - struct xilinx_axidma_tx_segment *segment;
> > - struct xilinx_axidma_desc_hw *hw;
> > enum dma_status ret;
> > unsigned long flags;
> > - u32 residue = 0;
> >
> > ret = dma_cookie_status(dchan, cookie, txstate);
> > if (ret == DMA_COMPLETE || !txstate)
> > return ret;
> >
> > - if (chan->xdev->dma_config->dmatype == XDMA_TYPE_AXIDMA) {
> > - spin_lock_irqsave(&chan->lock, flags);
> > + spin_lock_irqsave(&chan->lock, flags);
> >
> > - desc = list_last_entry(&chan->active_list,
> > - struct xilinx_dma_tx_descriptor, node);
> > - if (chan->has_sg) {
> > - list_for_each_entry(segment, &desc->segments,
> node) {
> > - hw = &segment->hw;
> > - residue += (hw->control - hw->status) &
> > - chan->xdev->max_buffer_len;
> > - }
> > - }
> > - spin_unlock_irqrestore(&chan->lock, flags);
> > + desc = list_last_entry(&chan->active_list,
> > + struct xilinx_dma_tx_
[PATCH 1/2] regulator: da9062: Simplify da9062_buck_set_mode for BUCK_MODE_MANUAL case
The sleep flag bit decides the mode for BUCK_MODE_MANUAL case, simplify
the logic as the result is the same.
Signed-off-by: Axel Lin
---
drivers/regulator/da9062-regulator.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/regulator/da9062-regulator.c
b/drivers/regulator/da9062-regulator.c
index 710e67081d53..739a40f256f6 100644
--- a/drivers/regulator/da9062-regulator.c
+++ b/drivers/regulator/da9062-regulator.c
@@ -136,7 +136,7 @@ static int da9062_buck_set_mode(struct regulator_dev *rdev,
unsigned mode)
static unsigned da9062_buck_get_mode(struct regulator_dev *rdev)
{
struct da9062_regulator *regl = rdev_get_drvdata(rdev);
- unsigned int val, mode = 0;
+ unsigned int val;
int ret;
ret = regmap_field_read(regl->mode, &val);
@@ -146,7 +146,6 @@ static unsigned da9062_buck_get_mode(struct regulator_dev
*rdev)
switch (val) {
default:
case BUCK_MODE_MANUAL:
- mode = REGULATOR_MODE_FAST | REGULATOR_MODE_STANDBY;
/* Sleep flag bit decides the mode */
break;
case BUCK_MODE_SLEEP:
@@ -162,11 +161,9 @@ static unsigned da9062_buck_get_mode(struct regulator_dev
*rdev)
return 0;
if (val)
- mode &= REGULATOR_MODE_STANDBY;
+ return REGULATOR_MODE_STANDBY;
else
- mode &= REGULATOR_MODE_NORMAL | REGULATOR_MODE_FAST;
-
- return mode;
+ return REGULATOR_MODE_FAST;
}
/*
--
2.20.1
[PATCH 2/2] regulator: da9063: Simplify da9063_buck_set_mode for BUCK_MODE_MANUAL case
The sleep flag bit decides the mode for BUCK_MODE_MANUAL case, simplify
the logic as the result is the same.
Signed-off-by: Axel Lin
---
drivers/regulator/da9063-regulator.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/regulator/da9063-regulator.c
b/drivers/regulator/da9063-regulator.c
index 28b1b20f45bd..2aceb3b7afc2 100644
--- a/drivers/regulator/da9063-regulator.c
+++ b/drivers/regulator/da9063-regulator.c
@@ -225,7 +225,7 @@ static unsigned da9063_buck_get_mode(struct regulator_dev
*rdev)
{
struct da9063_regulator *regl = rdev_get_drvdata(rdev);
struct regmap_field *field;
- unsigned int val, mode = 0;
+ unsigned int val;
int ret;
ret = regmap_field_read(regl->mode, &val);
@@ -235,7 +235,6 @@ static unsigned da9063_buck_get_mode(struct regulator_dev
*rdev)
switch (val) {
default:
case BUCK_MODE_MANUAL:
- mode = REGULATOR_MODE_FAST | REGULATOR_MODE_STANDBY;
/* Sleep flag bit decides the mode */
break;
case BUCK_MODE_SLEEP:
@@ -262,11 +261,9 @@ static unsigned da9063_buck_get_mode(struct regulator_dev
*rdev)
return 0;
if (val)
- mode &= REGULATOR_MODE_STANDBY;
+ return REGULATOR_MODE_STANDBY;
else
- mode &= REGULATOR_MODE_NORMAL | REGULATOR_MODE_FAST;
-
- return mode;
+ return REGULATOR_MODE_FAST;
}
/*
--
2.20.1
Re: [PATCH v2 1/4] lib: introduce copy_struct_from_user() helper
Hi Aleksa,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[cannot apply to v5.3 next-20190924]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Aleksa-Sarai/lib-introduce-copy_struct_from_user-helper/20190926-071752
config: sh-allmodconfig (attached as .config)
compiler: sh4-linux-gcc (GCC) 7.4.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.4.0 make.cross ARCH=sh
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All warnings (new ones prefixed by >>):
In file included from include/linux/printk.h:7:0,
from include/linux/kernel.h:15,
from include/asm-generic/bug.h:18,
from arch/sh/include/asm/bug.h:112,
from include/linux/bug.h:5,
from include/linux/mmdebug.h:5,
from include/linux/mm.h:9,
from include/linux/mman.h:5,
from lib/test_user_copy.c:13:
lib/test_user_copy.c: In function 'test_is_zeroed_user':
include/linux/kern_levels.h:5:18: warning: format '%lu' expects argument of
type 'long unsigned int', but argument 5 has type 'size_t {aka unsigned int}'
[-Wformat=]
#define KERN_SOH "\001" /* ASCII Start Of Header */
^
include/linux/kern_levels.h:12:22: note: in expansion of macro 'KERN_SOH'
#define KERN_WARNING KERN_SOH "4" /* warning conditions */
^~~~
include/linux/printk.h:306:9: note: in expansion of macro 'KERN_WARNING'
printk(KERN_WARNING pr_fmt(fmt), ##__VA_ARGS__)
^~~~
include/linux/printk.h:307:17: note: in expansion of macro 'pr_warning'
#define pr_warn pr_warning
^~
>> lib/test_user_copy.c:38:3: note: in expansion of macro 'pr_warn'
pr_warn("[%d] " msg "\n", __LINE__, ##__VA_ARGS__); \
^~~
>> lib/test_user_copy.c:77:11: note: in expansion of macro 'test'
ret |= test(retval != expected,
^~~~
include/linux/kern_levels.h:5:18: warning: format '%lu' expects argument of
type 'long unsigned int', but argument 6 has type 'size_t {aka unsigned int}'
[-Wformat=]
#define KERN_SOH "\001" /* ASCII Start Of Header */
^
include/linux/kern_levels.h:12:22: note: in expansion of macro 'KERN_SOH'
#define KERN_WARNING KERN_SOH "4" /* warning conditions */
^~~~
include/linux/printk.h:306:9: note: in expansion of macro 'KERN_WARNING'
printk(KERN_WARNING pr_fmt(fmt), ##__VA_ARGS__)
^~~~
include/linux/printk.h:307:17: note: in expansion of macro 'pr_warning'
#define pr_warn pr_warning
^~
>> lib/test_user_copy.c:38:3: note: in expansion of macro 'pr_warn'
pr_warn("[%d] " msg "\n", __LINE__, ##__VA_ARGS__); \
^~~
>> lib/test_user_copy.c:77:11: note: in expansion of macro 'test'
ret |= test(retval != expected,
^~~~
vim +/pr_warn +38 lib/test_user_copy.c
33
34 #define test(condition, msg, ...)
\
35 ({
\
36 int cond = (condition);
\
37 if (cond)
\
> 38 pr_warn("[%d] " msg "\n", __LINE__, ##__VA_ARGS__);
\
39 cond;
\
40 })
41
42 static int test_is_zeroed_user(char *kmem, char __user *umem, size_t
size)
43 {
44 int ret = 0;
45 size_t start, end, i;
46 size_t zero_start = size / 4;
47 size_t zero_end = size - zero_start;
48
49 /*
50 * We conduct a series of is_zeroed_user() tests on a block of
memory
51 * with the following byte-pattern (trying every possible
[start,end]
52 * pair):
53 *
54 * [ 00 ff 00 ff ... 00 00 00 00 ... ff 00 ff 00 ]
55 *
56 * And we verify that is_zeroed_user() acts identically to
memchr_inv().
57 */
58
59 for (i = 0; i < zero_start; i += 2)
60 kmem[i] = 0x00;
61 for (i = 1; i < zero_start; i += 2)
62 kmem[i] = 0xff;
63
64 for (i = zero_end; i < size; i += 2)
65
Re: [PATCH v2 3/3] platform/x86: intel_oaktrail: Use pr_warn instead of pr_warning
On Thu, Sep 26, 2019 at 4:29 AM Kefeng Wang wrote: > On 2019/9/25 23:04, Andy Shevchenko wrote: > > On Fri, Sep 20, 2019 at 1:55 PM Kefeng Wang > > wrote: > > You have to send to proper mailing lists and people. > > Used get_maintainer.pl to find the people, and all already in the CC, will > add proper maillist into each patch. > > > Don't spam the rest! > Not so clearly, should I not CC other people not in the list below? > > [wkf@localhost linux]$ ./scripts/get_maintainer.pl > pr_warning/v3/0018-platform-x86-eeepc-laptop-Use-pr_warn-instead-of-pr_.patch > Corentin Chary (maintainer:ASUS NOTEBOOKS AND > EEEPC ACPI/WMI EXTRAS DRIVERS) > Darren Hart (odd fixer:X86 PLATFORM DRIVERS) > Andy Shevchenko (odd fixer:X86 PLATFORM DRIVERS) You put a lot more people in Cc, than above list contains. > acpi4asus-u...@lists.sourceforge.net (open list:ASUS NOTEBOOKS AND EEEPC > ACPI/WMI EXTRAS DRIVERS) > platform-driver-...@vger.kernel.org (open list:ASUS NOTEBOOKS AND EEEPC > ACPI/WMI EXTRAS DRIVERS) This had been absent in your submission. > linux-kernel@vger.kernel.org (open list) -- With Best Regards, Andy Shevchenko
Re: [RFC PATCHv2 1/3] dt-bindings: misc: Add dt bindings for flex noc Performance Monitor
On Thu, Sep 26, 2019 at 10:46:24AM +0530, Shubhrajyoti Datta wrote: > Add dt bindings for flexnoc Performance Monitor. > The flexnoc counters for read and write response and requests are > supported. > > Signed-off-by: Shubhrajyoti Datta > --- > .../devicetree/bindings/misc/xlnx,flexnoc.txt | 24 > ++ > 1 file changed, 24 insertions(+) > create mode 100644 Documentation/devicetree/bindings/misc/xlnx,flexnoc.txt Why are these "RFC"? I guess you don't want them merged because you are not thinking that they are good enough? What needs to be done on them that you are sending them out now? greg k-h
[PATCH v2] scsi: core: Log SCSI command age with errors
Couple of users had requested to print the SCSI command age along with command failure errors. This is a small change, but allows users to get more important information about the command that was failed, it would help the users in debugging the command failures: Signed-off-by: Milan P. Gandhi --- changes v2: - Changed the message to print SCSI command age as 'cmd_age' and not 'cmd-age' to avoid any confusion. 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/drivers/scsi/scsi_logging.c b/drivers/scsi/scsi_logging.c index 39b8cc4574b4..0ccb4c95266d 100644 --- a/drivers/scsi/scsi_logging.c +++ b/drivers/scsi/scsi_logging.c @@ -432,6 +432,7 @@ void scsi_print_result(const struct scsi_cmnd *cmd, const char *msg, const char *mlret_string = scsi_mlreturn_string(disposition); const char *hb_string = scsi_hostbyte_string(cmd->result); const char *db_string = scsi_driverbyte_string(cmd->result); + unsigned long cmd_age = (jiffies - cmd->jiffies_at_alloc) / HZ; logbuf = scsi_log_reserve_buffer(&logbuf_len); if (!logbuf) @@ -473,10 +474,15 @@ void scsi_print_result(const struct scsi_cmnd *cmd, const char *msg, if (db_string) off += scnprintf(logbuf + off, logbuf_len - off, -"driverbyte=%s", db_string); +"driverbyte=%s ", db_string); else off += scnprintf(logbuf + off, logbuf_len - off, -"driverbyte=0x%02x", driver_byte(cmd->result)); +"driverbyte=0x%02x ", +driver_byte(cmd->result)); + + off += scnprintf(logbuf + off, logbuf_len - off, +"cmd_age=%lus", cmd_age); + out_printk: dev_printk(KERN_INFO, &cmd->device->sdev_gendev, "%s", logbuf); scsi_log_release_buffer(logbuf);
[RFC PATCHv2 1/3] dt-bindings: misc: Add dt bindings for flex noc Performance Monitor
Add dt bindings for flexnoc Performance Monitor.
The flexnoc counters for read and write response and requests are
supported.
Signed-off-by: Shubhrajyoti Datta
---
.../devicetree/bindings/misc/xlnx,flexnoc.txt | 24 ++
1 file changed, 24 insertions(+)
create mode 100644 Documentation/devicetree/bindings/misc/xlnx,flexnoc.txt
diff --git a/Documentation/devicetree/bindings/misc/xlnx,flexnoc.txt
b/Documentation/devicetree/bindings/misc/xlnx,flexnoc.txt
new file mode 100644
index 000..6b533bc
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/xlnx,flexnoc.txt
@@ -0,0 +1,24 @@
+* Xilinx Flexnoc Performance Monitor driver
+
+The FlexNoc Performance Monitor has counters for monitoring
+the read and the write transaction counter.
+
+Required properties:
+- compatible: "xlnx,flexnoc-pm-2.7"
+- reg : Address and length of register sets for each device in
+ "reg-names"
+- reg-names : The names of the register addresses corresponding to the
+ registers filled in "reg"
+ - funnel: base address of the funnel registers
+ - baselpd: base address of the LPD PM registers
+ - basefpd: base address FPD PM registers
+
+Example:
+
+performance-monitor@f092 {
+ compatible = "xlnx,flexnoc-pm-2.7";
+ reg-names = "funnel", "baselpd", "basefpd";
+ reg = <0x0 0xf092 0x0 0x1000>,
+ <0x0 0xf098 0x0 0x9000>,
+ <0x0 0xf0b8 0x0 0x9000>;
+};
--
2.1.1
This email and any attachments are intended for the sole use of the named
recipient(s) and contain(s) confidential information that may be proprietary,
privileged or copyrighted under applicable law. If you are not the intended
recipient, do not read, copy, or forward this email message or any attachments.
Delete this email message and any attachments immediately.
[RFC PATCHv2 3/3] Documentation: short descriptions for Flexnoc Performance Monitor driver
Add short documentation for FlexNoc Performance Monitor driver. Signed-off-by: Shubhrajyoti Datta --- v2: patch added Documentation/misc-devices/xilinx_flex.txt | 66 ++ 1 file changed, 66 insertions(+) create mode 100644 Documentation/misc-devices/xilinx_flex.txt diff --git a/Documentation/misc-devices/xilinx_flex.txt b/Documentation/misc-devices/xilinx_flex.txt new file mode 100644 index 000..c075934 --- /dev/null +++ b/Documentation/misc-devices/xilinx_flex.txt @@ -0,0 +1,66 @@ +Kernel driver xilinx_flex + + +Supported chips: +Versal SOC + +Author: + Shubhrajyoti Datta + +Description +--- + +Versal uses the Arteris FlexNoC interconnect instead of the ARM NIC. FlexNoC +provides the capability to integrate performance counters in the interconnect. +It has configurable probe points to monitor the packet and forwards it to +observer for logging. It supports read and write transaction counts for +request and response. + +Features: +---> Run-time programmable selection of packet probe points. +---> Recording of traffic and link statistics. +---> Separate read and write response and request count. + +SYSFS: + +counteridfpd + RW - shows the counter number selected for the FPD Flexnoc. + +counterfpd_rdreq + RO - shows the read request count for the FPD counters. + +counterfpdsrc + WO - sets the source of the FPD counter. + +counterfpd_wrrsp + RO - shows the write response count for the FPD counters. + +counterfpd_rdrsp + RO - shows the read response count for the FPD counters. + +counterfpd_wrreq + RO - shows the write request count for the FPD counters. + +counterfpdport + WO - sets the port number selected for the FPD Flexnoc. + +counteridlpd + RW - shows the counter number selected for the LPD Flexnoc. + +counterlpdport + WO - sets the port number selected for the LPD Flexnoc. + +counterlpd_rdreq + RO - shows the read request count for the LPD counters. + +counterlpd_wrreq + RO - shows the write request count for the LPD counters. + +counterlpd_wrrsp + RO - shows the write response count for the LPD counters. + +counterlpdsrc + WO - sets the source of the LPD counter. + +counterlpd_rdrsp + RO - shows the read response count for the LPD counters. -- 2.1.1 This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
[RFC PATCHv2 2/3] misc: xilinx_flex: Add support for the flex noc Performance Monitor
Add support for the FlexNoc Performance Monitor.
Adds support for various port setting and monitoring
the packets transactions. It supports LPD and FPD monitoring
counters for read and write transaction requests and responses.
Signed-off-by: Shubhrajyoti Datta
---
v2:
Add a mutex to prevent race
---
drivers/misc/Kconfig | 9 +
drivers/misc/Makefile | 1 +
drivers/misc/xilinx_flex_pm.c | 653 ++
3 files changed, 663 insertions(+)
create mode 100644 drivers/misc/xilinx_flex_pm.c
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index c55b637..1e9a6fa 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -454,6 +454,15 @@ config XILINX_SDFEC
If unsure, say N.
+config XILINX_FLEX_PM
+ tristate "Xilinx Flexnoc Performance Monitor"
+ help
+ This option enables support for the Xilinx Flex Noc Performance
Monitor driver.
+ It monitors the read and write transactions. It has counters for the
LPD and
+ FPD domains.
+
+ If unsure, say N
+
config MISC_RTSX
tristate
default MISC_RTSX_PCI || MISC_RTSX_USB
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index c1860d3..1f1c34d 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -57,3 +57,4 @@ obj-y += cardreader/
obj-$(CONFIG_PVPANIC) += pvpanic.o
obj-$(CONFIG_HABANA_AI)+= habanalabs/
obj-$(CONFIG_XILINX_SDFEC) += xilinx_sdfec.o
+obj-$(CONFIG_XILINX_FLEX_PM) += xilinx_flex_pm.o
diff --git a/drivers/misc/xilinx_flex_pm.c b/drivers/misc/xilinx_flex_pm.c
new file mode 100644
index 000..e7684d1
--- /dev/null
+++ b/drivers/misc/xilinx_flex_pm.c
@@ -0,0 +1,653 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Xilinx Flex Noc Performance Monitor driver.
+ * Copyright (c) 2019 Xilinx Inc.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define to_xflex_dev_info(n) ((struct xflex_dev_info *)dev_get_drvdata(n))
+
+#define FPM_LAR_OFFSET 0xFB0
+#define FPM_UNLOCK 0xC5ACCE55
+
+#define FPM_RD_REQ_OFFSET 0x1000
+#define FPM_RD_RES_OFFSET 0x2000
+#define FPM_WR_REQ_OFFSET 0x3000
+#define FPM_WR_RES_OFFSET 0x4000
+
+#define FPM_PORT_SEL_OFFSET0x134
+#define FPM_MAIN_CTRL_OFFSET 0x008
+#define FPM_SRC_SEL_OFFSET 0x138
+#define FPM_STATPERIOD 0x24
+#define FPM_CFGCTRL0x0C
+#define FPM_LPD0x4210002
+#define FPM_FPD0x420c003
+
+#define FPM_VAL0x300
+#define FPM_SRC0x200
+#define FPM_WRRSP_L0x7
+#define FPM_WRREQ_L0x6
+#define FPM_RDRSP_L0x5
+#define FPM_RDREQ_L0x4
+#define FPM_PROBE_SHIFT16
+#define FPM_COUNTER_OFFSET 0x14
+#define FPM_GLOBALEN BIT(0)
+#define FPM_STATEN BIT(3)
+#define FPM_STATCOND_DUMP BIT(5)
+#define FPM_NUM_COUNTERS 4
+#define FPM_MAINCTL_DIS0
+
+#define FPM_SRC_OFF0x0
+#define FPM_SRC_CYCLE 0x1
+#define FPM_SRC_IDLE 0x2
+#define FPM_SRC_XFER 0x3
+#define FPM_SRC_BUSY 0x4
+#define FPM_SRC_WAIT 0x5
+#define FPM_SRC_PACKET 0x6
+
+/* Port values */
+#define FPM_PORT_LPD_AFIFS_AXI 0x0
+#define FPM_PORT_LPD_OCM 0x1
+#define FPM_PORT_LPD_OCMEXT0x2
+#define FPM_PORT_PMC_RPU_AXI0 0x3
+
+#define FPM_PORT_FPDAXI0x1
+#define FPM_PORT_PROTXPPU 0x2
+
+/**
+ * struct xflex_dev_info - Global Driver structure
+ * @dev: Device structure
+ * @baselpd: Iomapped LPD base address
+ * @basefpd: Iomapped FPD base address
+ * @funnel: Iomapped funnel register base address
+ * @counterid_lpd: LPD counter id
+ * @counterid_fpd: FPD counter id
+ */
+struct xflex_dev_info {
+ struct device *dev;
+ void __iomem *baselpd;
+ void __iomem *basefpd;
+ void __iomem *funnel;
+ u32 counterid_fpd;
+ u32 counterid_lpd;
+ struct mutex mutex; /* avoid parallel access to device */
+};
+
+/**
+ * enum xflex_sysfs_cmd_codes - sysfs command codes
+ * @XFLEX_GET_COUNTER_FPD: get the FPD counter value
+ * @XFLEX_SET_COUNTER_FPD: set the FPD counter value
+ * @XFLEX_GET_COUNTER_FPD_RDREQ: get the FPD read request count
+ * @XFLEX_GET_COUNTER_FPD_RDRSP: get the FPD read response count
+ * @XFLEX_GET_COUNTER_FPD_WRREQ: get the FPD write request count
+ * @XFLEX_GET_COUNTER_FPD_WRRSP: get the FPD write response count
+ * @XFLEX_GET_COUNTER_LPD_RDREQ: get the LPD read
Re: [PATCH] scsi: core: Log SCSI command age with errors
On 9/25/19 9:15 PM, Bart Van Assche wrote: > On 9/22/19 11:01 PM, Milan P. Gandhi wrote: >> + off += scnprintf(logbuf + off, logbuf_len - off, >> + "cmd-age=%lus", cmd_age); > > Have you considered to change cmd-age into cmd_age? I'm afraid otherwise > someone might interpret the hyphen as a subtraction sign... Thanks for your suggestion Bart. Yes, it would be better to use cmd_age to avoid any confusion. I will change it and send the updated patch. Thanks, Milan.
[PATCH] vhost: introduce mdev based hardware backend
This patch introduces a mdev based hardware vhost backend.
This backend is built on top of the same abstraction used
in virtio-mdev and provides a generic vhost interface for
userspace to accelerate the virtio devices in guest.
This backend is implemented as a mdev device driver on top
of the same mdev device ops used in virtio-mdev but using
a different mdev class id, and it will register the device
as a VFIO device for userspace to use. Userspace can setup
the IOMMU with the existing VFIO container/group APIs and
then get the device fd with the device name. After getting
the device fd of this device, userspace can use vhost ioctls
to setup the backend.
Signed-off-by: Tiwei Bie
---
This patch depends on below series:
https://lkml.org/lkml/2019/9/24/357
RFC v4 -> v1:
- Implement vhost-mdev as a mdev device driver directly and
connect it to VFIO container/group. (Jason);
- Pass ring addresses as GPAs/IOVAs in vhost-mdev to avoid
meaningless HVA->GPA translations (Jason);
RFC v3 -> RFC v4:
- Build vhost-mdev on top of the same abstraction used by
virtio-mdev (Jason);
- Introduce vhost fd and pass VFIO fd via SET_BACKEND ioctl (MST);
RFC v2 -> RFC v3:
- Reuse vhost's ioctls instead of inventing a VFIO regions/irqs
based vhost protocol on top of vfio-mdev (Jason);
RFC v1 -> RFC v2:
- Introduce a new VFIO device type to build a vhost protocol
on top of vfio-mdev;
drivers/vhost/Kconfig | 9 +
drivers/vhost/Makefile | 3 +
drivers/vhost/mdev.c | 381 +
include/uapi/linux/vhost.h | 8 +
4 files changed, 401 insertions(+)
create mode 100644 drivers/vhost/mdev.c
diff --git a/drivers/vhost/Kconfig b/drivers/vhost/Kconfig
index 3d03ccbd1adc..decf0be8efe9 100644
--- a/drivers/vhost/Kconfig
+++ b/drivers/vhost/Kconfig
@@ -34,6 +34,15 @@ config VHOST_VSOCK
To compile this driver as a module, choose M here: the module will be
called
vhost_vsock.
+config VHOST_MDEV
+ tristate "Vhost driver for Mediated devices"
+ depends on EVENTFD && VFIO && VFIO_MDEV
+ select VHOST
+ default n
+ ---help---
+ Say M here to enable the vhost_mdev module for use with
+ the mediated device based hardware vhost accelerators
+
config VHOST
tristate
---help---
diff --git a/drivers/vhost/Makefile b/drivers/vhost/Makefile
index 6c6df24f770c..ad9c0f8c6d8c 100644
--- a/drivers/vhost/Makefile
+++ b/drivers/vhost/Makefile
@@ -10,4 +10,7 @@ vhost_vsock-y := vsock.o
obj-$(CONFIG_VHOST_RING) += vringh.o
+obj-$(CONFIG_VHOST_MDEV) += vhost_mdev.o
+vhost_mdev-y := mdev.o
+
obj-$(CONFIG_VHOST)+= vhost.o
diff --git a/drivers/vhost/mdev.c b/drivers/vhost/mdev.c
new file mode 100644
index ..1c12a25b86a2
--- /dev/null
+++ b/drivers/vhost/mdev.c
@@ -0,0 +1,381 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2018-2019 Intel Corporation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "vhost.h"
+
+struct vhost_mdev {
+ /* The lock is to protect this structure. */
+ struct mutex mutex;
+ struct vhost_dev dev;
+ struct vhost_virtqueue *vqs;
+ int nvqs;
+ u64 state;
+ u64 features;
+ u64 acked_features;
+ bool opened;
+ struct mdev_device *mdev;
+};
+
+static u8 mdev_get_status(struct mdev_device *mdev)
+{
+ const struct virtio_mdev_device_ops *ops = mdev_get_dev_ops(mdev);
+
+ return ops->get_status(mdev);
+}
+
+static void mdev_set_status(struct mdev_device *mdev, u8 status)
+{
+ const struct virtio_mdev_device_ops *ops = mdev_get_dev_ops(mdev);
+
+ return ops->set_status(mdev, status);
+}
+
+static void mdev_add_status(struct mdev_device *mdev, u8 status)
+{
+ status |= mdev_get_status(mdev);
+ mdev_set_status(mdev, status);
+}
+
+static void mdev_reset(struct mdev_device *mdev)
+{
+ mdev_set_status(mdev, 0);
+}
+
+static void handle_vq_kick(struct vhost_work *work)
+{
+ struct vhost_virtqueue *vq = container_of(work, struct vhost_virtqueue,
+ poll.work);
+ struct vhost_mdev *m = container_of(vq->dev, struct vhost_mdev, dev);
+ const struct virtio_mdev_device_ops *ops = mdev_get_dev_ops(m->mdev);
+
+ ops->kick_vq(m->mdev, vq - m->vqs);
+}
+
+static irqreturn_t vhost_mdev_virtqueue_cb(void *private)
+{
+ struct vhost_virtqueue *vq = private;
+ struct eventfd_ctx *call_ctx = vq->call_ctx;
+
+ if (call_ctx)
+ eventfd_signal(call_ctx, 1);
+ return IRQ_HANDLED;
+}
+
+static long vhost_mdev_reset(struct vhost_mdev *m)
+{
+ struct mdev_device *mdev = m->mdev;
+
+ mdev_reset(mdev);
+ mdev_add_status(mdev, VIRTIO_CONFIG_S_ACKNOWLEDGE);
+ mdev_add_status(mdev, VIRTIO_CONFIG_S_DRIVER);
+ return 0;
+}
+
+static long vhost_mdev_start(struct vhost_mdev *m)
+{
+ struct mdev_device *mdev = m
[PATCH v4 6/6] powerpc: Don't flush caches when adding memory
From: Alastair D'Silva
This operation takes a significant amount of time when hotplugging
large amounts of memory (~50 seconds with 890GB of persistent memory).
This was orignally in commit fb5924fddf9e
("powerpc/mm: Flush cache on memory hot(un)plug") to support memtrace,
but the flush on add is not needed as it is flushed on remove.
Signed-off-by: Alastair D'Silva
---
arch/powerpc/mm/mem.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index a2758e473d58..9afb77a8c8d5 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -142,8 +142,6 @@ int __ref arch_add_memory(int nid, u64 start, u64 size,
return -EFAULT;
}
- flush_dcache_range_chunked(start, start + size, FLUSH_CHUNK_SIZE);
-
return __add_pages(nid, start_pfn, nr_pages, restrictions);
}
--
2.21.0
[PATCH v4 5/6] powerpc: Chunk calls to flush_dcache_range in arch_*_memory
From: Alastair D'Silva
When presented with large amounts of memory being hotplugged
(in my test case, ~890GB), the call to flush_dcache_range takes
a while (~50 seconds), triggering RCU stalls.
This patch breaks up the call into 1GB chunks, calling
cond_resched() inbetween to allow the scheduler to run.
Signed-off-by: Alastair D'Silva
---
arch/powerpc/mm/mem.c | 27 +--
1 file changed, 25 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index cff947cb2a84..a2758e473d58 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -104,6 +104,27 @@ int __weak remove_section_mapping(unsigned long start,
unsigned long end)
return -ENODEV;
}
+#define FLUSH_CHUNK_SIZE SZ_1G
+/**
+ * flush_dcache_range_chunked(): Write any modified data cache blocks out to
+ * memory and invalidate them, in chunks of up to FLUSH_CHUNK_SIZE
+ * Does not invalidate the corresponding instruction cache blocks.
+ *
+ * @start: the start address
+ * @stop: the stop address (exclusive)
+ * @chunk: the max size of the chunks
+ */
+static void flush_dcache_range_chunked(unsigned long start, unsigned long stop,
+ unsigned long chunk)
+{
+ unsigned long i;
+
+ for (i = start; i < stop; i += FLUSH_CHUNK_SIZE) {
+ flush_dcache_range(i, min(stop, start + FLUSH_CHUNK_SIZE));
+ cond_resched();
+ }
+}
+
int __ref arch_add_memory(int nid, u64 start, u64 size,
struct mhp_restrictions *restrictions)
{
@@ -120,7 +141,8 @@ int __ref arch_add_memory(int nid, u64 start, u64 size,
start, start + size, rc);
return -EFAULT;
}
- flush_dcache_range(start, start + size);
+
+ flush_dcache_range_chunked(start, start + size, FLUSH_CHUNK_SIZE);
return __add_pages(nid, start_pfn, nr_pages, restrictions);
}
@@ -137,7 +159,8 @@ void __ref arch_remove_memory(int nid, u64 start, u64 size,
/* Remove htab bolted mappings for this section of memory */
start = (unsigned long)__va(start);
- flush_dcache_range(start, start + size);
+ flush_dcache_range_chunked(start, start + size, FLUSH_CHUNK_SIZE);
+
ret = remove_section_mapping(start, start + size);
WARN_ON_ONCE(ret);
--
2.21.0
[PATCH v4 3/6] powerpc: define helpers to get L1 icache sizes
From: Alastair D'Silva
This patch adds helpers to retrieve icache sizes, and renames the existing
helpers to make it clear that they are for dcache.
Signed-off-by: Alastair D'Silva
---
arch/powerpc/include/asm/cache.h | 29 +++
arch/powerpc/include/asm/cacheflush.h | 12 +--
2 files changed, 31 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/include/asm/cache.h b/arch/powerpc/include/asm/cache.h
index b3388d95f451..f852d5cd746c 100644
--- a/arch/powerpc/include/asm/cache.h
+++ b/arch/powerpc/include/asm/cache.h
@@ -55,25 +55,46 @@ struct ppc64_caches {
extern struct ppc64_caches ppc64_caches;
-static inline u32 l1_cache_shift(void)
+static inline u32 l1_dcache_shift(void)
{
return ppc64_caches.l1d.log_block_size;
}
-static inline u32 l1_cache_bytes(void)
+static inline u32 l1_dcache_bytes(void)
{
return ppc64_caches.l1d.block_size;
}
+
+static inline u32 l1_icache_shift(void)
+{
+ return ppc64_caches.l1i.log_block_size;
+}
+
+static inline u32 l1_icache_bytes(void)
+{
+ return ppc64_caches.l1i.block_size;
+}
#else
-static inline u32 l1_cache_shift(void)
+static inline u32 l1_dcache_shift(void)
{
return L1_CACHE_SHIFT;
}
-static inline u32 l1_cache_bytes(void)
+static inline u32 l1_dcache_bytes(void)
{
return L1_CACHE_BYTES;
}
+
+static inline u32 l1_icache_shift(void)
+{
+ return L1_CACHE_SHIFT;
+}
+
+static inline u32 l1_icache_bytes(void)
+{
+ return L1_CACHE_BYTES;
+}
+
#endif
#endif /* ! __ASSEMBLY__ */
diff --git a/arch/powerpc/include/asm/cacheflush.h
b/arch/powerpc/include/asm/cacheflush.h
index eef388f2659f..ed57843ef452 100644
--- a/arch/powerpc/include/asm/cacheflush.h
+++ b/arch/powerpc/include/asm/cacheflush.h
@@ -63,8 +63,8 @@ static inline void __flush_dcache_icache_phys(unsigned long
physaddr)
*/
static inline void flush_dcache_range(unsigned long start, unsigned long stop)
{
- unsigned long shift = l1_cache_shift();
- unsigned long bytes = l1_cache_bytes();
+ unsigned long shift = l1_dcache_shift();
+ unsigned long bytes = l1_dcache_bytes();
void *addr = (void *)(start & ~(bytes - 1));
unsigned long size = stop - (unsigned long)addr + (bytes - 1);
unsigned long i;
@@ -89,8 +89,8 @@ static inline void flush_dcache_range(unsigned long start,
unsigned long stop)
*/
static inline void clean_dcache_range(unsigned long start, unsigned long stop)
{
- unsigned long shift = l1_cache_shift();
- unsigned long bytes = l1_cache_bytes();
+ unsigned long shift = l1_dcache_shift();
+ unsigned long bytes = l1_dcache_bytes();
void *addr = (void *)(start & ~(bytes - 1));
unsigned long size = stop - (unsigned long)addr + (bytes - 1);
unsigned long i;
@@ -108,8 +108,8 @@ static inline void clean_dcache_range(unsigned long start,
unsigned long stop)
static inline void invalidate_dcache_range(unsigned long start,
unsigned long stop)
{
- unsigned long shift = l1_cache_shift();
- unsigned long bytes = l1_cache_bytes();
+ unsigned long shift = l1_dcache_shift();
+ unsigned long bytes = l1_dcache_bytes();
void *addr = (void *)(start & ~(bytes - 1));
unsigned long size = stop - (unsigned long)addr + (bytes - 1);
unsigned long i;
--
2.21.0
[PATCH v4 2/6] powerpc: Allow 64bit VDSO __kernel_sync_dicache to work across ranges >4GB
From: Alastair D'Silva When calling __kernel_sync_dicache with a size >4GB, we were masking off the upper 32 bits, so we would incorrectly flush a range smaller than intended. This patch replaces the 32 bit shifts with 64 bit ones, so that the full size is accounted for. Signed-off-by: Alastair D'Silva Cc: sta...@vger.kernel.org --- arch/powerpc/kernel/vdso64/cacheflush.S | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/kernel/vdso64/cacheflush.S b/arch/powerpc/kernel/vdso64/cacheflush.S index 3f92561a64c4..526f5ba2593e 100644 --- a/arch/powerpc/kernel/vdso64/cacheflush.S +++ b/arch/powerpc/kernel/vdso64/cacheflush.S @@ -35,7 +35,7 @@ V_FUNCTION_BEGIN(__kernel_sync_dicache) subfr8,r6,r4/* compute length */ add r8,r8,r5/* ensure we get enough */ lwz r9,CFG_DCACHE_LOGBLOCKSZ(r10) - srw.r8,r8,r9/* compute line count */ + srd.r8,r8,r9/* compute line count */ crclr cr0*4+so beqlr /* nothing to do? */ mtctr r8 @@ -52,7 +52,7 @@ V_FUNCTION_BEGIN(__kernel_sync_dicache) subfr8,r6,r4/* compute length */ add r8,r8,r5 lwz r9,CFG_ICACHE_LOGBLOCKSZ(r10) - srw.r8,r8,r9/* compute line count */ + srd.r8,r8,r9/* compute line count */ crclr cr0*4+so beqlr /* nothing to do? */ mtctr r8 -- 2.21.0
[PATCH v4 4/6] powerpc: Convert flush_icache_range & friends to C
From: Alastair D'Silva
Similar to commit 22e9c88d486a
("powerpc/64: reuse PPC32 static inline flush_dcache_range()")
this patch converts the following ASM symbols to C:
flush_icache_range()
__flush_dcache_icache()
__flush_dcache_icache_phys()
This was done as we discovered a long-standing bug where the length of the
range was truncated due to using a 32 bit shift instead of a 64 bit one.
By converting these functions to C, it becomes easier to maintain.
flush_dcache_icache_phys() retains a critical assembler section as we must
ensure there are no memory accesses while the data MMU is disabled
(authored by Christophe Leroy). Since this has no external callers, it has
also been made static, allowing the compiler to inline it within
flush_dcache_icache_page().
Signed-off-by: Alastair D'Silva
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/cache.h | 26 ++---
arch/powerpc/include/asm/cacheflush.h | 24 ++--
arch/powerpc/kernel/misc_32.S | 117
arch/powerpc/kernel/misc_64.S | 102 -
arch/powerpc/mm/mem.c | 151 +-
5 files changed, 172 insertions(+), 248 deletions(-)
diff --git a/arch/powerpc/include/asm/cache.h b/arch/powerpc/include/asm/cache.h
index f852d5cd746c..e33451a9c4e6 100644
--- a/arch/powerpc/include/asm/cache.h
+++ b/arch/powerpc/include/asm/cache.h
@@ -98,20 +98,7 @@ static inline u32 l1_icache_bytes(void)
#endif
#endif /* ! __ASSEMBLY__ */
-#if defined(__ASSEMBLY__)
-/*
- * For a snooping icache, we still need a dummy icbi to purge all the
- * prefetched instructions from the ifetch buffers. We also need a sync
- * before the icbi to order the the actual stores to memory that might
- * have modified instructions with the icbi.
- */
-#define PURGE_PREFETCHED_INS \
- sync; \
- icbi0,r3; \
- sync; \
- isync
-
-#else
+#if !defined(__ASSEMBLY__)
#define __read_mostly __attribute__((__section__(".data..read_mostly")))
#ifdef CONFIG_PPC_BOOK3S_32
@@ -145,6 +132,17 @@ static inline void dcbst(void *addr)
{
__asm__ __volatile__ ("dcbst %y0" : : "Z"(*(u8 *)addr) : "memory");
}
+
+static inline void icbi(void *addr)
+{
+ asm volatile ("icbi 0, %0" : : "r"(addr) : "memory");
+}
+
+static inline void iccci(void *addr)
+{
+ asm volatile ("iccci 0, %0" : : "r"(addr) : "memory");
+}
+
#endif /* !__ASSEMBLY__ */
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_CACHE_H */
diff --git a/arch/powerpc/include/asm/cacheflush.h
b/arch/powerpc/include/asm/cacheflush.h
index ed57843ef452..4a1c9f0200e1 100644
--- a/arch/powerpc/include/asm/cacheflush.h
+++ b/arch/powerpc/include/asm/cacheflush.h
@@ -42,24 +42,20 @@ extern void flush_dcache_page(struct page *page);
#define flush_dcache_mmap_lock(mapping)do { } while (0)
#define flush_dcache_mmap_unlock(mapping) do { } while (0)
-extern void flush_icache_range(unsigned long, unsigned long);
+void flush_icache_range(unsigned long start, unsigned long stop);
extern void flush_icache_user_range(struct vm_area_struct *vma,
struct page *page, unsigned long addr,
int len);
-extern void __flush_dcache_icache(void *page_va);
extern void flush_dcache_icache_page(struct page *page);
-#if defined(CONFIG_PPC32) && !defined(CONFIG_BOOKE)
-extern void __flush_dcache_icache_phys(unsigned long physaddr);
-#else
-static inline void __flush_dcache_icache_phys(unsigned long physaddr)
-{
- BUG();
-}
-#endif
-
-/*
- * Write any modified data cache blocks out to memory and invalidate them.
- * Does not invalidate the corresponding instruction cache blocks.
+void __flush_dcache_icache(void *page);
+
+/**
+ * flush_dcache_range(): Write any modified data cache blocks out to memory and
+ * invalidate them. Does not invalidate the corresponding instruction cache
+ * blocks.
+ *
+ * @start: the start address
+ * @stop: the stop address (exclusive)
*/
static inline void flush_dcache_range(unsigned long start, unsigned long stop)
{
diff --git a/arch/powerpc/kernel/misc_32.S b/arch/powerpc/kernel/misc_32.S
index fe4bd321730e..12b95e6799d4 100644
--- a/arch/powerpc/kernel/misc_32.S
+++ b/arch/powerpc/kernel/misc_32.S
@@ -318,123 +318,6 @@ END_FTR_SECTION_IFSET(CPU_FTR_UNIFIED_ID_CACHE)
EXPORT_SYMBOL(flush_instruction_cache)
#endif /* CONFIG_PPC_8xx */
-/*
- * Write any modified data cache blocks out to memory
- * and invalidate the corresponding instruction cache blocks.
- * This is a no-op on the 601.
- *
- * flush_icache_range(unsigned long start, unsigned long stop)
- */
-_GLOBAL(flush_icache_range)
-BEGIN_FTR_SECTION
- PURGE_PREFETCHED_INS
- blr /* for 601, do nothing */
-END_FTR_SECTION_IFSET(CPU_FTR_COHERENT_ICACHE)
- rlwinm r3,r3,0,0,31 - L1_CACHE_SHIFT
- subfr4,r3,r4
- addir4,r4,L1_C
[PATCH v4 1/6] powerpc: Allow flush_icache_range to work across ranges >4GB
From: Alastair D'Silva When calling flush_icache_range with a size >4GB, we were masking off the upper 32 bits, so we would incorrectly flush a range smaller than intended. This patch replaces the 32 bit shifts with 64 bit ones, so that the full size is accounted for. Signed-off-by: Alastair D'Silva Cc: sta...@vger.kernel.org --- arch/powerpc/kernel/misc_64.S | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/kernel/misc_64.S b/arch/powerpc/kernel/misc_64.S index b55a7b4cb543..9bc0aa9aeb65 100644 --- a/arch/powerpc/kernel/misc_64.S +++ b/arch/powerpc/kernel/misc_64.S @@ -82,7 +82,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_COHERENT_ICACHE) subfr8,r6,r4/* compute length */ add r8,r8,r5/* ensure we get enough */ lwz r9,DCACHEL1LOGBLOCKSIZE(r10)/* Get log-2 of cache block size */ - srw.r8,r8,r9/* compute line count */ + srd.r8,r8,r9/* compute line count */ beqlr /* nothing to do? */ mtctr r8 1: dcbst 0,r6 @@ -98,7 +98,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_COHERENT_ICACHE) subfr8,r6,r4/* compute length */ add r8,r8,r5 lwz r9,ICACHEL1LOGBLOCKSIZE(r10)/* Get log-2 of Icache block size */ - srw.r8,r8,r9/* compute line count */ + srd.r8,r8,r9/* compute line count */ beqlr /* nothing to do? */ mtctr r8 2: icbi0,r6 -- 2.21.0
[PATCH v4 0/6] powerpc: convert cache asm to C
From: Alastair D'Silva This series addresses a few issues discovered in how we flush caches: 1. Flushes were truncated at 4GB, so larger flushes were incorrect. 2. Flushing the dcache in arch_add_memory was unnecessary This series also converts much of the cache assembler to C, with the aim of making it easier to maintain. Changelog: V4: - Split out VDSO patch - Pass/cast the correct types in 'powerpc: Convert flush_icache_range & friends to C' V3: - factor out chunking loop - Replace __asm__ __volatile__ with asm volatile - Replace flush_coherent_icache_or_return macro with flush_coherent_icache function - factor our invalidate_icache_range - Replace code duplicating clean_dcache_range() in __flush_dcache_icache() with a call to clean_dcache_range() - Remove redundant #ifdef CONFIG_44x - Fix preprocessor logic: #if !defined(CONFIG_PPC_8xx) & !defined(CONFIG_PPC64) - Added loop(1|2) to earlyclobbers in flush_dcache_icache_phys - Drop "Remove extern" patch - Replace 32 bit shifts in 64 bit VDSO with 64 bit ones V2: - Replace C implementation of flush_dcache_icache_phys() with inline assembler authored by Christophe Leroy - Add memory clobbers for iccci implementation - Give __flush_dcache_icache a real implementation, it can't just be a wrapper around flush_icache_range() - Remove PPC64_CACHES from misc_64.S - Replace code duplicating clean_dcache_range() in flush_icache_range() with a call to clean_dcache_range() - Replace #ifdef CONFIG_44x with IS_ENABLED(...) in flush_icache_cange() - Use 1GB chunks instead of 16GB in arch_*_memory Alastair D'Silva (6): powerpc: Allow flush_icache_range to work across ranges >4GB powerpc: Allow 64bit VDSO __kernel_sync_dicache to work across ranges >4GB powerpc: define helpers to get L1 icache sizes powerpc: Convert flush_icache_range & friends to C powerpc: Chunk calls to flush_dcache_range in arch_*_memory powerpc: Don't flush caches when adding memory arch/powerpc/include/asm/cache.h| 55 +--- arch/powerpc/include/asm/cacheflush.h | 36 +++-- arch/powerpc/kernel/misc_32.S | 117 arch/powerpc/kernel/misc_64.S | 102 -- arch/powerpc/kernel/vdso64/cacheflush.S | 4 +- arch/powerpc/mm/mem.c | 176 +++- 6 files changed, 228 insertions(+), 262 deletions(-) -- 2.21.0
Re: [PATCH v2] net: flow_offload: fix memory leak in nfp_abm_u32_knode_replace
On Wed, 25 Sep 2019 21:22:35 -0500, Navid Emamdoost wrote:
> In nfp_abm_u32_knode_replace if the allocation for match fails it should
> go to the error handling instead of returning.
>
> Signed-off-by: Navid Emamdoost
> ---
> Changes in v2:
> - Reused err variable for erorr value returning.
Thanks, there's another goto up top. And I think subject prefix could
be "nfp: abm:", perhaps?
> drivers/net/ethernet/netronome/nfp/abm/cls.c | 10 +++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ethernet/netronome/nfp/abm/cls.c
> b/drivers/net/ethernet/netronome/nfp/abm/cls.c
> index 23ebddfb9532..b0cb9d201f7d 100644
> --- a/drivers/net/ethernet/netronome/nfp/abm/cls.c
> +++ b/drivers/net/ethernet/netronome/nfp/abm/cls.c
> @@ -198,14 +198,18 @@ nfp_abm_u32_knode_replace(struct nfp_abm_link *alink,
> if ((iter->val & cmask) == (val & cmask) &&
> iter->band != knode->res->classid) {
> NL_SET_ERR_MSG_MOD(extack, "conflict with already
> offloaded filter");
> + err = -EOPNOTSUPP;
> goto err_delete;
> }
> }
>
> if (!match) {
> match = kzalloc(sizeof(*match), GFP_KERNEL);
> - if (!match)
> - return -ENOMEM;
> + if (!match) {
> + err = -ENOMEM;
> + goto err_delete;
> + }
> +
> list_add(&match->list, &alink->dscp_map);
> }
> match->handle = knode->handle;
> @@ -221,7 +225,7 @@ nfp_abm_u32_knode_replace(struct nfp_abm_link *alink,
>
> err_delete:
> nfp_abm_u32_knode_delete(alink, knode);
> - return -EOPNOTSUPP;
> + return err;
> }
>
> static int nfp_abm_setup_tc_block_cb(enum tc_setup_type type,
[PATCH v2 1/1] i2c: iproc: Add i2c repeated start capability
From: Lori Hikichi
Enable handling of i2c repeated start. The current code
handles a multi msg i2c transfer as separate i2c bus
transactions. This change will now handle this case
using the i2c repeated start protocol. The number of msgs
in a transfer is limited to two, and must be a write
followed by a read.
Signed-off-by: Lori Hikichi
Signed-off-by: Rayagonda Kokatanur
Signed-off-by: Icarus Chau
Signed-off-by: Ray Jui
Signed-off-by: Shivaraj Shetty
---
changes from v1:
- Address code review comment from Wolfram Sang
drivers/i2c/busses/i2c-bcm-iproc.c | 63 ++
1 file changed, 50 insertions(+), 13 deletions(-)
diff --git a/drivers/i2c/busses/i2c-bcm-iproc.c
b/drivers/i2c/busses/i2c-bcm-iproc.c
index d7fd76b..e478db7 100644
--- a/drivers/i2c/busses/i2c-bcm-iproc.c
+++ b/drivers/i2c/busses/i2c-bcm-iproc.c
@@ -81,6 +81,7 @@
#define M_CMD_PROTOCOL_MASK 0xf
#define M_CMD_PROTOCOL_BLK_WR0x7
#define M_CMD_PROTOCOL_BLK_RD0x8
+#define M_CMD_PROTOCOL_PROCESS 0xa
#define M_CMD_PEC_SHIFT 8
#define M_CMD_RD_CNT_SHIFT 0
#define M_CMD_RD_CNT_MASK0xff
@@ -675,13 +676,20 @@ static int bcm_iproc_i2c_xfer_wait(struct
bcm_iproc_i2c_dev *iproc_i2c,
return 0;
}
-static int bcm_iproc_i2c_xfer_single_msg(struct bcm_iproc_i2c_dev *iproc_i2c,
-struct i2c_msg *msg)
+/*
+ * If 'process_call' is true, then this is a multi-msg transfer that requires
+ * a repeated start between the messages.
+ * More specifically, it must be a write (reg) followed by a read (data).
+ * The i2c quirks are set to enforce this rule.
+ */
+static int bcm_iproc_i2c_xfer_internal(struct bcm_iproc_i2c_dev *iproc_i2c,
+ struct i2c_msg *msgs, bool process_call)
{
int i;
u8 addr;
u32 val, tmp, val_intr_en;
unsigned int tx_bytes;
+ struct i2c_msg *msg = &msgs[0];
/* check if bus is busy */
if (!!(iproc_i2c_rd_reg(iproc_i2c,
@@ -707,14 +715,29 @@ static int bcm_iproc_i2c_xfer_single_msg(struct
bcm_iproc_i2c_dev *iproc_i2c,
val = msg->buf[i];
/* mark the last byte */
- if (i == msg->len - 1)
- val |= BIT(M_TX_WR_STATUS_SHIFT);
+ if (!process_call && (i == msg->len - 1))
+ val |= 1 << M_TX_WR_STATUS_SHIFT;
iproc_i2c_wr_reg(iproc_i2c, M_TX_OFFSET, val);
}
iproc_i2c->tx_bytes = tx_bytes;
}
+ /* Process the read message if this is process call */
+ if (process_call) {
+ msg++;
+ iproc_i2c->msg = msg; /* point to second msg */
+
+ /*
+* The last byte to be sent out should be a slave
+* address with read operation
+*/
+ addr = i2c_8bit_addr_from_msg(msg);
+ /* mark it the last byte out */
+ val = addr | (1 << M_TX_WR_STATUS_SHIFT);
+ iproc_i2c_wr_reg(iproc_i2c, M_TX_OFFSET, val);
+ }
+
/* mark as incomplete before starting the transaction */
if (iproc_i2c->irq)
reinit_completion(&iproc_i2c->done);
@@ -733,7 +756,7 @@ static int bcm_iproc_i2c_xfer_single_msg(struct
bcm_iproc_i2c_dev *iproc_i2c,
* underrun interrupt, which will be triggerred when the TX FIFO is
* empty. When that happens we can then pump more data into the FIFO
*/
- if (!(msg->flags & I2C_M_RD) &&
+ if (!process_call && !(msg->flags & I2C_M_RD) &&
msg->len > iproc_i2c->tx_bytes)
val_intr_en |= BIT(IE_M_TX_UNDERRUN_SHIFT);
@@ -743,6 +766,8 @@ static int bcm_iproc_i2c_xfer_single_msg(struct
bcm_iproc_i2c_dev *iproc_i2c,
*/
val = BIT(M_CMD_START_BUSY_SHIFT);
if (msg->flags & I2C_M_RD) {
+ u32 protocol;
+
iproc_i2c->rx_bytes = 0;
if (msg->len > M_RX_FIFO_MAX_THLD_VALUE)
iproc_i2c->thld_bytes = M_RX_FIFO_THLD_VALUE;
@@ -758,7 +783,10 @@ static int bcm_iproc_i2c_xfer_single_msg(struct
bcm_iproc_i2c_dev *iproc_i2c,
/* enable the RX threshold interrupt */
val_intr_en |= BIT(IE_M_RX_THLD_SHIFT);
- val |= (M_CMD_PROTOCOL_BLK_RD << M_CMD_PROTOCOL_SHIFT) |
+ protocol = process_call ?
+ M_CMD_PROTOCOL_PROCESS : M_CMD_PROTOCOL_BLK_RD;
+
+ val |= (protocol << M_CMD_PROTOCOL_SHIFT) |
(msg->len << M_CMD_RD_CNT_SHIFT);
} else {
val |= (M_CMD_PROTOCOL_BLK_WR << M_CMD_PROTOCOL_SHIFT);
@@ -774,17 +802,24 @@ static int bcm_iproc_i2c_xfer(struct i2c_adapter *adapter,
struct i2c_msg msgs[], int num)
{
s
Re: [PATCH 1/2] perf script python: integrate page reclaim analyze script
On Thu, Sep 26, 2019 at 9:56 AM Tony Jones wrote:
>
> On 9/18/19 7:38 AM, Yafang Shao wrote:
> > A new perf script page-reclaim is introduced in this patch. This new script
> > is used to report the page reclaim details. The possible usage of this
> > script is as bellow,
> > - identify latency spike caused by direct reclaim
> > - whehter the latency spike is relevant with pageout
> > - why is page reclaim requested, i.e. whether it is because of memory
> > fragmentation
> > - page reclaim efficiency
> > etc
> > In the future we may also enhance it to analyze the memcg reclaim.
> >
> > Bellow is how to use this script,
> > # Record, one of the following
> > $ perf record -e 'vmscan:mm_vmscan_*' ./workload
> > $ perf script record page-reclaim
> >
> > # Report
> > $ perf script report page-reclaim
> >
> > # Report per process latency
> > $ perf script report page-reclaim -- -p
>
>
> I tested it with global-dhp__pagereclaim-performance from mmtests and got
> what appears to be reasonable results and the output looks correct and
> useful. However I'm not a vm expert so I can't comment further. Hopefully
> someone on linux-mm can give more specific feedback.
>
+ Mel
Hi Mel,
This is motivated by
Documentation/trace/postprocess/trace-vmscan-postprocess.pl created by
you.
Could you pls. help take a look ?
Thanks
Yafang
> There is one issue with Python3, see below. I didn't test with Python2.
>
> >
> > + @classmethod
> > + def shrink_inactive(cls, pid, scanned, reclaimed, flags):
> > + event = cls.events.get(pid)
> > + if event and event.tracing():
> > + # RECLAIM_WB_ANON 0x1
> > + # RECLAIM_WB_FILE 0x2
> > + _type = (flags & 0x2) >> 1
> > + event.process_lru(lru[_type], scanned, reclaimed)
> > +
> > + @classmethod
> > + def writepage(cls, pid, flags):
> > + event = cls.events.get(pid)
> > + if event and event.tracing():
> > + # RECLAIM_WB_ANON 0x1
> > + # RECLAIM_WB_FILE 0x2
> > + # RECLAIM_WB_SYNC 0x4
> > + # RECLAIM_WB_ASYNC 0x8
> > + _type = (flags & 0x2) >> 1
> > + _io = (flags & 0x4) >> 2
> > +
> > + event.process_writepage(lru[_type], sync_io[_io])
> > +
> > +@classmethod
>
> Space indentation on line above. For python3 this results in:
>
> File "tools/perf/scripts/python/page-reclaim.py", line 217
> @classmethod
>^
> TabError: inconsistent use of tabs and spaces in indentation
>
> > + def iterate_proc(cls):
> > + if show_opt != Show.DEFAULT:
> > + print("\nPer process latency (ms):")
> > + print_proc_latency(latency_metric, 'pid', '[comm]')
> > +
> > + if show_opt == Show.VERBOSE:
> > + print("%20s %s" %
> > ('timestamp','latency(ns)'))
>
>
> Thanks
>
> Tony
>
Re: [PATCH 1/2] perf script python: integrate page reclaim analyze script
On Thu, Sep 26, 2019 at 11:36 AM Tony Jones wrote: > > On 9/25/19 6:56 PM, Tony Jones wrote: > > On 9/18/19 7:38 AM, Yafang Shao wrote: > >> A new perf script page-reclaim is introduced in this patch. This new script > >> is used to report the page reclaim details. The possible usage of this > >> script is as bellow, > >> - identify latency spike caused by direct reclaim > >> - whehter the latency spike is relevant with pageout > >> - why is page reclaim requested, i.e. whether it is because of memory > >> fragmentation > >> - page reclaim efficiency > >> etc > >> In the future we may also enhance it to analyze the memcg reclaim. > >> > >> Bellow is how to use this script, > >> # Record, one of the following > >> $ perf record -e 'vmscan:mm_vmscan_*' ./workload > >> $ perf script record page-reclaim > >> > >> # Report > >> $ perf script report page-reclaim > >> > >> # Report per process latency > >> $ perf script report page-reclaim -- -p > > > > > > I tested it with global-dhp__pagereclaim-performance from mmtests and got > > what appears to be reasonable results and the output looks correct and > > useful. However I'm not a vm expert so I can't comment further. Hopefully > > someone on linux-mm can give more specific feedback. > > > > There is one issue with Python3, see below. I didn't test with Python2. > > Ok, I guess this wasn't actually tested with Python3 as itervalues() is > Python2 only. Any scripts need to work with both Python2.6+ and Python3. > > # perf script -i /tmp/perf.out -s page-reclaim.py -- -p > ... > > Traceback (most recent call last): > File "page-reclaim.py", line 305, in trace_end > i.display_proc(), > File "page-reclaim.py", line 268, in display_proc > print_proc_latency(sorted(self.stat.stats['latency'].itervalues(), > AttributeError: 'dict' object has no attribute 'itervalues' > Fatal Python error: problem in Python trace event handler > > Use a try/except to handle this. > Hi Tony, Thanks for your review. I only verified it with python2. I will improve it to make it work with both python2.6+ and python3. Thanks Yafang
bug in KBUILD_OUTPUT handling - for relative paths in kselftest
I found a bug in kselftest KBUILD_OUTPUT handling. The following works: $ cd /home/tbird/work/linux $ export KBUILD_OUTPUT=/home/tbird/work/kbuild $ yes '' | make localmodconfig $ make TARGETS=size kselftest But this doesn't work: $ cd /home/tbird/work/linux $ export KBUILD_OUTPUT=../kbuild $ yes '' | make localmodconfig $ make TARGETS=size kselftest I see the following: make[1]: Entering directory '/home/tbird/work/kbuild' make --no-builtin-rules INSTALL_HDR_PATH=$BUILD/usr \ ARCH=x86 -C ../../.. headers_install INSTALL ../kbuild/kselftest/usr/include gcc -static -ffreestanding -nostartfiles -sget_size.c -o ../kbuild/kselftest/size/get_size /usr/bin/ld: cannot open output file ../kbuild/kselftest/size/get_size: No such file or directory collect2: error: ld returned 1 exit status ../lib.mk:138: recipe for target '../kbuild/kselftest/size/get_size' failed make[3]: *** [../kbuild/kselftest/size/get_size] Error 1 Makefile:136: recipe for target 'all' failed make[2]: *** [all] Error 2 /home/tbird/work/linux/Makefile:1240: recipe for target 'kselftest' failed make[1]: *** [kselftest] Error 2 make[1]: Leaving directory '/home/tbird/work/kbuild' Makefile:179: recipe for target 'sub-make' failed make: *** [sub-make] Error 2 This is due to the relative path for KBUILD_OUTPUT being handled incorrectly (I believe) in tools/testing/selftests/Makefile. There are these lines in the Makefile, which are responsible for creating the output directory: BUILD_TARGET=$$BUILD/$$TARGET mkdir $$BUILD_TARGET -p But these are executed from working directory tools/testing/selftests, so the 'size' directory gets created at tools/testing/kbuild/kselftest/size, instead of /home/tbird/work/kbuild/kselftest/size. I can add some code to the Makefile to change the assignment of the variable BUILD, so that if it is a relative path it is relative to $(top_srcdir) instead of the current directory. But I wanted to check and make sure that I'm not breaking anyone else's workflow. I'm not sure what the expectation would be for someone who did this: $ export KBUILD_OUTPUT=../kbuild ; make -C tools/testing/selftests run_tests But I assume if someone is running the kernel's 'make' from the top-level kernel source directory, and they have a relative KBUILD_OUTPUT directory, then they want that output directory to be relative to the top-level directory and not somewhere else. Should I just code up something for review? I use relative KBUILD_OUTPUT paths for a number of my kernel build scripts, and right now these are incompatible with kselftests. Thanks, -- Tim
Re: [PATCH 4/5] dt-bindings: usb: dwc3: of-simple: add compatible for HiSi
On Wed, Sep 25, 2019 at 6:34 PM Chunfeng Yun wrote: > On Wed, 2019-09-25 at 23:42 +, John Stultz wrote: > > +++ b/Documentation/devicetree/bindings/usb/hisi,dwc3.txt > > @@ -0,0 +1,52 @@ > > +HiSi SuperSpeed DWC3 USB SoC controller > > + > > +Required properties: > > +- compatible:should contain "hisilicon,hi3660-dwc3" for > > HiSi SoC > > +- clocks:A list of phandle + clock-specifier pairs for the > > + clocks listed in clock-names > > +- clock-names: Should contain the following: > > + "clk_usb3phy_ref" Phy reference clk > It's not good idea to apply phy's clock in dwc3's node Hey! Thanks for taking a look at this! So first, my apologies, I'm not the driver author and I don't have any real specs on the hardware other then what's in the source tree I'm working on. Not the ideal person to be documenting the binding, but I realized we still needed some binding documentation (although a few other dwc-of-simple compat entries are undocumented), so this is my rough stab at it. :/ Given the name clk_usb3phy_ref I'm assuming its a phy reference clock, but I honestly don't know if I'm getting that wrong. It all seems to be leveraging the fact that the dwc-of-simple driver batch enables and disables all the clocks w/o really looking at the names. Do you have a recommendation for what would be best here? I suspect it's necessary to enable/disable the clk in a similar path(though I'm unfortunately traveling this week so I can't validate that). Do I try to move the clk_usb3phy_ref clock enable/disable handling to somewhere else? thanks -john
Re: [PATCH v2] mm: don't expose page to fast gup prematurely
On Wed, Sep 25, 2019 at 03:17:50PM +0300, Kirill A. Shutemov wrote: > On Tue, Sep 24, 2019 at 04:05:50PM -0600, Yu Zhao wrote: > > On Tue, Sep 24, 2019 at 02:23:16PM +0300, Kirill A. Shutemov wrote: > > > On Sat, Sep 14, 2019 at 01:05:18AM -0600, Yu Zhao wrote: > > > > We don't want to expose page to fast gup running on a remote CPU > > > > before all local non-atomic ops on page flags are visible first. > > > > > > > > For anon page that isn't in swap cache, we need to make sure all > > > > prior non-atomic ops, especially __SetPageSwapBacked() in > > > > page_add_new_anon_rmap(), are order before set_pte_at() to prevent > > > > the following race: > > > > > > > > CPU 1 CPU1 > > > > set_pte_at()get_user_pages_fast() > > > > page_add_new_anon_rmap()gup_pte_range() > > > > __SetPageSwapBacked() SetPageReferenced() > > > > > > Is there a particular codepath that has what you listed for CPU? > > > After quick look, I only saw that we page_add_new_anon_rmap() called > > > before set_pte_at(). > > > > I think so. One in do_swap_page() and another in unuse_pte(). Both > > are on KSM paths. Am I referencing a stale copy of the source? > > I *think* it is a bug. Setting a pte before adding the page to rmap may > lead to rmap (like try_to_unmap() or something) to miss the VMA. > > Do I miss something? We have the pages locked in those two places, so for try_to_unmap() and the rest of page_vma_mapped_walk() users, they will block on the page lock: CPU 1 CPU 2 lock_page() set_pte_at() unlock_page() lock_page() try_to_unmap() page_vma_mapped_walk() pte_present() without holding ptl unlock_page() For others that don't use page_vma_mapped_walk(), they should either lock pages or grab ptl before checking pte_present(). AFAIK, the fast gup is the only one doesn't fall into the either category.
Re: [PATCH V5 4/4] ASoC: fsl_asrc: Fix error with S24_3LE format bitstream in i.MX8
Hi
> Just a small concern...
>
> On Thu, Sep 26, 2019 at 09:29:51AM +0800, Shengjiu Wang wrote:
> > static int fsl_asrc_dma_startup(struct snd_pcm_substream *substream)
> > {
> > +
> > + release_pair = false;
> > + ret = snd_soc_set_runtime_hwparams(substream,
> > + &snd_imx_hardware);
>
> This set_runtime_hwparams() always returns 0 for now, but if one day it
> changes and it fails here, kfree() will be still ignored although the
> startup()
> gets error-out.
>
> We could avoid this if we continue to ignore the return value like the
> current code. Or we may check ret at kfree() also?
I like to ignore the return value.
Best regards
Wang shengjiu
Re: [PATCH v2 3/3] reset: add support for the Meson-A1 SoC Reset Controller
Hi, Kevin Thanks for your reminder On 2019/9/26 6:57, Kevin Hilman wrote: Hi Xingyu, Xingyu Chen writes: The number of RESET registers and offset of RESET_LEVEL register for Meson-A1 are different from previous SoCs, In order to describe these differences, we introduce the struct meson_reset_param. Signed-off-by: Xingyu Chen Signed-off-by: Jianxin Pan Reviewed-by: Neil Armstrong Again, order here isn't quite right. Add the reviewed-by tags first, and the sender should be the last sign-off. I will reorder Signed-off and Reviewed in next version Other than that, driver looks good. Reviewed-by: Kevin Hilman Kevin .
Re: [PATCH v2 2/3] dt-bindings: reset: add bindings for the Meson-A1 SoC Reset Controller
Hi, Kevin Thanks for your review On 2019/9/26 6:55, Kevin Hilman wrote: Xingyu Chen writes: Add DT bindings for the Meson-A1 SoC Reset Controller include file, and also slightly update documentation. Signed-off-by: Xingyu Chen Signed-off-by: Jianxin Pan The order here doesn't look right. As the sender, your sign-off should be last. Is Jianxin the author or are you? If Jianxin, there should be a "From:" line at the beginning of the changelog to indicate authorship that's different from the sender. I am an author for this patchset, i will reorder Signed-off in next version. --- .../bindings/reset/amlogic,meson-reset.yaml| 1 + include/dt-bindings/reset/amlogic,meson-a1-reset.h | 59 ++ 2 files changed, 60 insertions(+) create mode 100644 include/dt-bindings/reset/amlogic,meson-a1-reset.h diff --git a/Documentation/devicetree/bindings/reset/amlogic,meson-reset.yaml b/Documentation/devicetree/bindings/reset/amlogic,meson-reset.yaml index 00917d8..b3f57d8 100644 --- a/Documentation/devicetree/bindings/reset/amlogic,meson-reset.yaml +++ b/Documentation/devicetree/bindings/reset/amlogic,meson-reset.yaml @@ -16,6 +16,7 @@ properties: - amlogic,meson8b-reset # Reset Controller on Meson8b and compatible SoCs - amlogic,meson-gxbb-reset # Reset Controller on GXBB and compatible SoCs - amlogic,meson-axg-reset # Reset Controller on AXG and compatible SoCs + - amlogic,meson-a1-reset # Reset Controller on A1 and compatible SoCs reg: maxItems: 1 diff --git a/include/dt-bindings/reset/amlogic,meson-a1-reset.h b/include/dt-bindings/reset/amlogic,meson-a1-reset.h new file mode 100644 index ..8d76a47 --- /dev/null +++ b/include/dt-bindings/reset/amlogic,meson-a1-reset.h @@ -0,0 +1,59 @@ +/* SPDX-License-Identifier: (GPL-2.0+ OR MIT) + * + * Copyright (c) 2019 Amlogic, Inc. All rights reserved. + * Author: Xingyu Chen + * + */ + +#ifndef _DT_BINDINGS_AMLOGIC_MESON_A1_RESET_H +#define _DT_BINDINGS_AMLOGIC_MESON_A1_RESET_H + +/* RESET0 */ +#define RESET_AM2AXI_VAD 1 minor nit: can you use comments/whitespace here to indicate holes? Please see the other amlogic files in this dir for examples. I will fix it in next version. Kevin .
Re: [PATCH 1/2] perf script python: integrate page reclaim analyze script
On 9/25/19 6:56 PM, Tony Jones wrote: > On 9/18/19 7:38 AM, Yafang Shao wrote: >> A new perf script page-reclaim is introduced in this patch. This new script >> is used to report the page reclaim details. The possible usage of this >> script is as bellow, >> - identify latency spike caused by direct reclaim >> - whehter the latency spike is relevant with pageout >> - why is page reclaim requested, i.e. whether it is because of memory >> fragmentation >> - page reclaim efficiency >> etc >> In the future we may also enhance it to analyze the memcg reclaim. >> >> Bellow is how to use this script, >> # Record, one of the following >> $ perf record -e 'vmscan:mm_vmscan_*' ./workload >> $ perf script record page-reclaim >> >> # Report >> $ perf script report page-reclaim >> >> # Report per process latency >> $ perf script report page-reclaim -- -p > > > I tested it with global-dhp__pagereclaim-performance from mmtests and got > what appears to be reasonable results and the output looks correct and > useful. However I'm not a vm expert so I can't comment further. Hopefully > someone on linux-mm can give more specific feedback. > > There is one issue with Python3, see below. I didn't test with Python2. Ok, I guess this wasn't actually tested with Python3 as itervalues() is Python2 only. Any scripts need to work with both Python2.6+ and Python3. # perf script -i /tmp/perf.out -s page-reclaim.py -- -p ... Traceback (most recent call last): File "page-reclaim.py", line 305, in trace_end i.display_proc(), File "page-reclaim.py", line 268, in display_proc print_proc_latency(sorted(self.stat.stats['latency'].itervalues(), AttributeError: 'dict' object has no attribute 'itervalues' Fatal Python error: problem in Python trace event handler Use a try/except to handle this. Thanks Tony
Re: [PATCH 2/2] selftests: Add kselftest_install target to main Makefile
Hi Shuah, On Thu, Sep 26, 2019 at 8:05 AM Shuah Khan wrote: > > Add kselftest_install target to install tests from the top level > Makefile. This is to simplify kselftest use-cases for CI and > distributions where build and test systems are different. > > This change addresses requests from developers and testers to add > support for installing kselftest from the main Makefile. > > In addition, make the install directory the same when install is > run using "make kselftest_install" or by running kselftest_install.sh. > Also fix the INSTALL_PATH variable conflict between main Makefile. > > Signed-off-by: Shuah Khan So, if these two patches were applied, we would see the following: PHONY += kselftest_build kselftest_build: $(Q)$(MAKE) -C $(srctree)/tools/testing/selftests all PHONY += kselftest kselftest: $(Q)$(MAKE) -C $(srctree)/tools/testing/selftests run_tests PHONY += kselftest_install kselftest_install: $(Q)$(MAKE) -C $(srctree)/tools/testing/selftests install PHONY += kselftest-clean kselftest-clean: $(Q)$(MAKE) -C $(srctree)/tools/testing/selftests clean I do not want to see this endless crap addition just for changing the working directory to $(srctree)/tools/testing/selftests Why don't you use pattern rule? Those will be reduced into the two rules. PHONY += kselftest kselftest: $(Q)$(MAKE) -C $(srctree)/tools/testing/selftests run_tests kselftest-%: FORCE $(Q)$(MAKE) -C $(srctree)/tools/testing/selftests $* This also avoids your inconsistency about "kselftest-" vs "kselftest_". Given the existing "kselftest-clean" and "kselftest-merge", "kselftest_build" and "kselftest_install" (using an underscore instead of n hyphen) would add needless confusion. -- Best Regards Masahiro Yamada
Re: [PATCH 4/5] ocxl: Add functions to map/unmap LPC memory
On Mon, 2019-09-23 at 13:39 +0200, Frederic Barrat wrote:
>
>
> > diff --git a/drivers/misc/ocxl/link.c b/drivers/misc/ocxl/link.c
> > index 2874811a4398..9e303a5f4d85 100644
> > --- a/drivers/misc/ocxl/link.c
> > +++ b/drivers/misc/ocxl/link.c
> > @@ -738,7 +738,7 @@ int ocxl_link_add_lpc_mem(void *link_handle,
> > u64 size)
> > }
> > EXPORT_SYMBOL_GPL(ocxl_link_add_lpc_mem);
> >
> > -u64 ocxl_link_lpc_map(void *link_handle, struct pci_dev *pdev)
> > +u64 ocxl_link_lpc_online(void *link_handle, struct pci_dev *pdev)
> > {
> > struct ocxl_link *link = (struct ocxl_link *) link_handle;
> >
>
> A bit of a nitpick, but is there any specific reason to rename with
> "online" suffix? I'm discovering it myself, but with memory hotplug,
> "onlining" seems to refer to the second, a.k.a logical memory
> hotplug
> phase (as described in Documentation/admin-guide/mm/memory-
> hotplug.rst).
> We'll need to worry about it, but the function here is really doing
> the
> first phase, a.k.a physical memory hotplug.
>
>Fred
It's been a while since I wrote that, so I can't remember why, but your
reasoning is sound, I'll drop the rename.
>
>
> > @@ -759,7 +759,7 @@ u64 ocxl_link_lpc_map(void *link_handle, struct
> > pci_dev *pdev)
> > return link->lpc_mem;
> > }
> >
> > -void ocxl_link_lpc_release(void *link_handle, struct pci_dev
> > *pdev)
> > +void ocxl_link_lpc_offline(void *link_handle, struct pci_dev
> > *pdev)
> > {
> > struct ocxl_link *link = (struct ocxl_link *) link_handle;
> >
> > diff --git a/drivers/misc/ocxl/ocxl_internal.h
> > b/drivers/misc/ocxl/ocxl_internal.h
> > index db2647a90fc8..5656a4aab5b7 100644
> > --- a/drivers/misc/ocxl/ocxl_internal.h
> > +++ b/drivers/misc/ocxl/ocxl_internal.h
> > @@ -52,6 +52,12 @@ struct ocxl_afu {
> > void __iomem *global_mmio_ptr;
> > u64 pp_mmio_start;
> > void *private;
> > + u64 lpc_base_addr; /* Covers both LPC & special purpose memory
> > */
> > + struct bin_attribute attr_global_mmio;
> > + struct bin_attribute attr_lpc_mem;
> > + struct resource lpc_res;
> > + struct bin_attribute attr_special_purpose_mem;
> > + struct resource special_purpose_res;
> > };
> >
> > enum ocxl_context_status {
> > @@ -170,7 +176,7 @@ extern u64 ocxl_link_get_lpc_mem_sz(void
> > *link_handle);
> >* @link_handle: The OpenCAPI link handle
> >* @pdev: A device that is on the link
> >*/
> > -u64 ocxl_link_lpc_map(void *link_handle, struct pci_dev *pdev);
> > +u64 ocxl_link_lpc_online(void *link_handle, struct pci_dev *pdev);
> >
> > /**
> >* Release the LPC memory device for an OpenCAPI device
> > @@ -181,6 +187,6 @@ u64 ocxl_link_lpc_map(void *link_handle, struct
> > pci_dev *pdev);
> >* @link_handle: The OpenCAPI link handle
> >* @pdev: A device that is on the link
> >*/
> > -void ocxl_link_lpc_release(void *link_handle, struct pci_dev
> > *pdev);
> > +void ocxl_link_lpc_offline(void *link_handle, struct pci_dev
> > *pdev);
> >
> > #endif /* _OCXL_INTERNAL_H_ */
> > diff --git a/include/misc/ocxl.h b/include/misc/ocxl.h
> > index 06dd5839e438..a1897737908d 100644
> > --- a/include/misc/ocxl.h
> > +++ b/include/misc/ocxl.h
> > @@ -212,6 +212,24 @@ int ocxl_irq_set_handler(struct ocxl_context
> > *ctx, int irq_id,
> >
> > // AFU Metadata
> >
> > +/**
> > + * Map the LPC system & special purpose memory for an AFU
> > + *
> > + * Do not call this during device discovery, as there may me
> > multiple
> > + * devices on a link, and the memory is mapped for the whole link,
> > not
> > + * just one device. It should only be called after all devices
> > have
> > + * registered their memory on the link.
> > + *
> > + * afu: The AFU that has the LPC memory to map
> > + */
> > +extern int ocxl_map_lpc_mem(struct ocxl_afu *afu);
> > +
> > +/**
> > + * Get the physical address range of LPC memory for an AFU
> > + * afu: The AFU associated with the LPC memory
> > + */
> > +extern struct resource *ocxl_afu_lpc_mem(struct ocxl_afu *afu);
> > +
> > /**
> >* Get a pointer to the config for an AFU
> >*
> >
--
Alastair D'Silva
Open Source Developer
Linux Technology Centre, IBM Australia
mob: 0423 762 819
Re: [RFC patch 10/15] x86/entry: Move irq tracing to C code
On Thu, Sep 19, 2019 at 05:03:24PM +0200, Thomas Gleixner wrote: > ENTRY(error_exit) > - UNWIND_HINT_REGS > DISABLE_INTERRUPTS(CLBR_ANY) > TRACE_IRQS_OFF > + UNWIND_HINT_REGS > testb $3, CS(%rsp) > jz retint_kernel > jmp retint_user I don't think this UNWIND_HINT_REGS needs to be moved? -- Josh
[v4,2/3] arm: dts: ls1021a: fix that FlexTimer cannot wakeup system in deep sleep
The patch fixes a bug that FlexTimer cannot
wakeup system in deep sleep.
Signed-off-by: Biwen Li
---
Change in v4:
- update property name
fsl,ippdexpcr-alt-addr -> fsl,ippdexpcr1-alt-addr
Change in v3:
- update property name
fsl,rcpm-scfg -> fsl,ippdexpcr-alt-addr
Change in v2:
- None
arch/arm/boot/dts/ls1021a.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
index e3973b611c3a..ae427f039e8b 100644
--- a/arch/arm/boot/dts/ls1021a.dtsi
+++ b/arch/arm/boot/dts/ls1021a.dtsi
@@ -1000,6 +1000,12 @@
compatible = "fsl,ls1021a-rcpm", "fsl,qoriq-rcpm-2.1+";
reg = <0x0 0x1ee2140 0x0 0x8>;
#fsl,rcpm-wakeup-cells = <2>;
+
+ /*
+* The second and third entry compose an alt offset
+* address for IPPDEXPCR1(SCFG_SPARECR8)
+*/
+ fsl,ippdexpcr1-alt-addr = <&scfg 0x0 0x51c>;
};
ftm_alarm0: timer0@29d {
--
2.17.1
[v4,1/3] soc: fsl: handle RCPM errata A-008646 on SoC LS1021A
Description:
- Reading configuration register RCPM_IPPDEXPCR1
always return zero
Workaround:
- Save register RCPM_IPPDEXPCR1's value to
register SCFG_SPARECR8.(uboot's psci also
need reading value from the register SCFG_SPARECR8
to set register RCPM_IPPDEXPCR1)
Impact:
- FlexTimer module will cannot wakeup system in
deep sleep on SoC LS1021A
Signed-off-by: Biwen Li
---
Change in v4:
- rename property name
fsl,ippdexpcr-alt-addr -> fsl,ippdexpcr1-alt-addr
Change in v3:
- update commit message
- rename property name
fsl,rcpm-scfg -> fsl,ippdexpcr-alt-addr
Change in v2:
- fix stype problems
drivers/soc/fsl/rcpm.c | 33 +
1 file changed, 33 insertions(+)
diff --git a/drivers/soc/fsl/rcpm.c b/drivers/soc/fsl/rcpm.c
index 82c0ad5e663e..9a29c482fc2e 100644
--- a/drivers/soc/fsl/rcpm.c
+++ b/drivers/soc/fsl/rcpm.c
@@ -13,6 +13,8 @@
#include
#include
#include
+#include
+#include
#define RCPM_WAKEUP_CELL_MAX_SIZE 7
@@ -29,6 +31,9 @@ static int rcpm_pm_prepare(struct device *dev)
struct rcpm *rcpm;
u32 value[RCPM_WAKEUP_CELL_MAX_SIZE + 1], tmp;
int i, ret, idx;
+ struct regmap *scfg_addr_regmap = NULL;
+ u32 reg_offset[RCPM_WAKEUP_CELL_MAX_SIZE + 1];
+ u32 reg_value = 0;
rcpm = dev_get_drvdata(dev);
if (!rcpm)
@@ -63,6 +68,34 @@ static int rcpm_pm_prepare(struct device *dev)
tmp |= value[i + 1];
iowrite32be(tmp, rcpm->ippdexpcr_base +
i * 4);
}
+ /* Workaround of errata A-008646 on SoC LS1021A:
+* There is a bug of register ippdexpcr1.
+* Reading configuration register
RCPM_IPPDEXPCR1
+* always return zero. So save ippdexpcr1's
value
+* to register SCFG_SPARECR8.And the value of
+* ippdexpcr1 will be read from SCFG_SPARECR8.
+*/
+ scfg_addr_regmap =
syscon_regmap_lookup_by_phandle(np,
+
"fsl,ippdexpcr1-alt-addr");
+ if (scfg_addr_regmap && (1 == i)) {
+ if
(of_property_read_u32_array(dev->of_node,
+ "fsl,ippdexpcr1-alt-addr",
+ reg_offset,
+ 1 + sizeof(u64)/sizeof(u32))) {
+ scfg_addr_regmap = NULL;
+ continue;
+ }
+ /* Read value from register
SCFG_SPARECR8 */
+ regmap_read(scfg_addr_regmap,
+ (u32)(((u64)(reg_offset[1]
<< (sizeof(u32) * 8) |
+ reg_offset[2])) &
0x),
+ ®_value);
+ /* Write value to register
SCFG_SPARECR8 */
+ regmap_write(scfg_addr_regmap,
+(u32)(((u64)(reg_offset[1]
<< (sizeof(u32) * 8) |
+reg_offset[2])) &
0x),
+tmp | reg_value);
+ }
}
}
} while (ws = wakeup_source_get_next(ws));
--
2.17.1
[v4,3/3] Documentation: dt: binding: fsl: Add 'fsl,ippdexpcr1-alt-addr' property
The 'fsl,ippdexpcr1-alt-addr' property is used to handle an errata A-008646
on LS1021A
Signed-off-by: Biwen Li
---
Change in v4:
- rename property name
fsl,ippdexpcr-alt-addr -> fsl,ippdexpcr1-alt-addr
Change in v3:
- rename property name
fsl,rcpm-scfg -> fsl,ippdexpcr-alt-addr
Change in v2:
- update desc of the property 'fsl,rcpm-scfg'
.../devicetree/bindings/soc/fsl/rcpm.txt | 21 +++
1 file changed, 21 insertions(+)
diff --git a/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
index 5a33619d881d..751a7655b694 100644
--- a/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
+++ b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
@@ -34,6 +34,13 @@ Chassis Version Example Chips
Optional properties:
- little-endian : RCPM register block is Little Endian. Without it RCPM
will be Big Endian (default case).
+ - fsl,ippdexpcr1-alt-addr : The property is related to a hardware issue
+ on SoC LS1021A and only needed on SoC LS1021A.
+ Must include 1 + 2 entries.
+ The first entry must be a link to the SCFG device node.
+ The non-first entry must be offset of registers of SCFG.
+ The second and third entry compose an alt offset address
+ for IPPDEXPCR1(SCFG_SPARECR8)
Example:
The RCPM node for T4240:
@@ -43,6 +50,20 @@ The RCPM node for T4240:
#fsl,rcpm-wakeup-cells = <2>;
};
+The RCPM node for LS1021A:
+ rcpm: rcpm@1ee2140 {
+ compatible = "fsl,ls1021a-rcpm", "fsl,qoriq-rcpm-2.1+";
+ reg = <0x0 0x1ee2140 0x0 0x8>;
+ #fsl,rcpm-wakeup-cells = <2>;
+
+ /*
+* The second and third entry compose an alt offset
+* address for IPPDEXPCR1(SCFG_SPARECR8)
+*/
+ fsl,ippdexpcr1-alt-addr = <&scfg 0x0 0x51c>;
+ };
+
+
* Freescale RCPM Wakeup Source Device Tree Bindings
---
Required fsl,rcpm-wakeup property should be added to a device node if the
device
--
2.17.1
Re: [PATCH v2 13/13] vfio/type1: track iommu backed group attach
On Thu, 5 Sep 2019 16:08:43 +0800
Liu Yi L wrote:
> With the introduction of iommu aware mdev group, user may wrap a PF/VF
> as a mdev. Such mdevs will be called as wrapped PF/VF mdevs in following
> statements. If it's applied on a non-singleton iommu group, there would
> be multiple domain attach on an iommu_device group (equal to iommu backed
> group). Reason is that mdev group attaches is finally an iommu_device
> group attach in the end. And existing vfio_domain.gorup_list has no idea
> about it. Thus multiple attach would happen.
>
> What's more, under default domain policy, group attach is allowed only
> when its in-use domain is equal to its default domain as the code below:
>
> static int __iommu_attach_group(struct iommu_domain *domain, ..)
> {
> ..
> if (group->default_domain && group->domain != group->default_domain)
> return -EBUSY;
> ...
> }
>
> So for the above scenario, only the first group attach on the
> non-singleton iommu group will be successful. Subsequent group
> attaches will be failed. However, this is a fairly valid usage case
> if the wrapped PF/VF mdevs and other devices are assigned to a single
> VM. We may want to prevent it. In other words, the subsequent group
> attaches should return success before going to __iommu_attach_group().
>
> However, if user tries to assign the wrapped PF/VF mdevs and other
> devices to different VMs, the subsequent group attaches on a single
> iommu_device group should be failed. This means the subsequent group
> attach should finally calls into __iommu_attach_group() and be failed.
>
> To meet the above requirements, this patch introduces vfio_group_object
> structure to track the group attach of an iommu_device group (a.ka.
> iommu backed group). Each vfio_domain will have a group_obj_list to
> record the vfio_group_objects. The search of the group_obj_list should
> use iommu_device group if a group is mdev group.
>
> struct vfio_group_object {
> atomic_tcount;
> struct iommu_group *iommu_group;
> struct vfio_domain *domain;
> struct list_headnext;
> };
>
> Each time, a successful group attach should either have a new
> vfio_group_object created or count increasing of an existing
> vfio_group_object instance. Details can be found in
> vfio_domain_attach_group_object().
>
> For group detach, should have count decreasing. Please check
> vfio_domain_detach_group_object().
>
> As the vfio_domain.group_obj_list is within vfio container(vfio_iommu)
> scope, if user wants to passthru a non-singleton to multiple VMs, it
> will be failed as VMs will have separate vfio containers. Also, if
> vIOMMU is exposed, it will also fail the attempts of assigning multiple
> devices (via vfio-pci or PF/VF wrapped mdev) to a single VM. This is
> aligned with current vfio passthru rules.
>
> Cc: Kevin Tian
> Cc: Lu Baolu
> Suggested-by: Alex Williamson
> Signed-off-by: Liu Yi L
> ---
> drivers/vfio/vfio_iommu_type1.c | 167
>
> 1 file changed, 154 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
> index 317430d..6a67bd6 100644
> --- a/drivers/vfio/vfio_iommu_type1.c
> +++ b/drivers/vfio/vfio_iommu_type1.c
> @@ -75,6 +75,7 @@ struct vfio_domain {
> struct iommu_domain *domain;
> struct list_headnext;
> struct list_headgroup_list;
> + struct list_headgroup_obj_list;
> int prot; /* IOMMU_CACHE */
> boolfgsp; /* Fine-grained super pages */
> };
> @@ -97,6 +98,13 @@ struct vfio_group {
> boolmdev_group; /* An mdev group */
> };
>
> +struct vfio_group_object {
> + atomic_tcount;
> + struct iommu_group *iommu_group;
> + struct vfio_domain *domain;
> + struct list_headnext;
> +};
> +
So vfio_domain already has a group_list for all the groups attached to
that iommu domain. We add a vfio_group_object list, which is also
effectively a list of groups attached to the domain, but we're tracking
something different with it. All groups seem to get added as a
vfio_group_object, so why do we need both lists? As I suspected when
we discussed this last, this adds complexity for something that's
currently being proposed as a sample driver.
> /*
> * Guest RAM pinning working set or DMA target
> */
> @@ -1263,6 +1271,85 @@ static struct vfio_group *find_iommu_group(struct
> vfio_domain *domain,
> return NULL;
> }
>
> +static struct vfio_group_object *find_iommu_group_object(
> + struct vfio_domain *domain, struct iommu_group *iommu_group)
> +{
> + struct vfio_group_object *g;
> +
> + list_for_each_entry(g, &domain->group_obj_list, next) {
> + if (g->iommu_group == iommu_group)
> +
Re: [RFC PATCH 2/4] iommu/vt-d: Add first level page table interfaces
Hi Peter,
Thanks for reviewing my code.
On 9/25/19 1:21 PM, Peter Xu wrote:
On Mon, Sep 23, 2019 at 08:24:52PM +0800, Lu Baolu wrote:
This adds functions to manipulate first level page tables
which could be used by a scalale mode capable IOMMU unit.
intel_mmmap_range(domain, addr, end, phys_addr, prot)
- Map an iova range of [addr, end) to the physical memory
started at @phys_addr with the @prot permissions.
intel_mmunmap_range(domain, addr, end)
- Tear down the map of an iova range [addr, end). A page
list will be returned which will be freed after iotlb
flushing.
Cc: Ashok Raj
Cc: Jacob Pan
Cc: Kevin Tian
Cc: Liu Yi L
Cc: Yi Sun
Signed-off-by: Lu Baolu
---
drivers/iommu/Makefile | 2 +-
drivers/iommu/intel-pgtable.c | 342 +
include/linux/intel-iommu.h| 24 +-
include/trace/events/intel_iommu.h | 60 +
4 files changed, 426 insertions(+), 2 deletions(-)
create mode 100644 drivers/iommu/intel-pgtable.c
diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile
index 4f405f926e73..dc550e14cc58 100644
--- a/drivers/iommu/Makefile
+++ b/drivers/iommu/Makefile
@@ -17,7 +17,7 @@ obj-$(CONFIG_ARM_SMMU) += arm-smmu.o arm-smmu-impl.o
obj-$(CONFIG_ARM_SMMU_V3) += arm-smmu-v3.o
obj-$(CONFIG_DMAR_TABLE) += dmar.o
obj-$(CONFIG_INTEL_IOMMU) += intel-iommu.o intel-pasid.o
-obj-$(CONFIG_INTEL_IOMMU) += intel-trace.o
+obj-$(CONFIG_INTEL_IOMMU) += intel-trace.o intel-pgtable.o
obj-$(CONFIG_INTEL_IOMMU_DEBUGFS) += intel-iommu-debugfs.o
obj-$(CONFIG_INTEL_IOMMU_SVM) += intel-svm.o
obj-$(CONFIG_IPMMU_VMSA) += ipmmu-vmsa.o
diff --git a/drivers/iommu/intel-pgtable.c b/drivers/iommu/intel-pgtable.c
new file mode 100644
index ..8e95978cd381
--- /dev/null
+++ b/drivers/iommu/intel-pgtable.c
@@ -0,0 +1,342 @@
+// SPDX-License-Identifier: GPL-2.0
+/**
+ * intel-pgtable.c - Intel IOMMU page table manipulation library
Could this be a bit misleading? Normally I'll use "IOMMU page table"
to refer to the 2nd level page table only, and I'm always
understanding it as "the new IOMMU will understand MMU page table as
the 1st level". At least mention "IOMMU 1st level page table"?
This file is a place holder for all code that manipulating iommu page
tables (both first level and second level). Instead of putting
everything in intel_iommu.c, let's make the code more structured so that
it's easier for reading and maintaining. This is the motivation of this
file.
+ *
+ * Copyright (C) 2019 Intel Corporation
+ *
+ * Author: Lu Baolu
+ */
+
+#define pr_fmt(fmt) "DMAR: " fmt
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#ifdef CONFIG_X86
+/*
+ * mmmap: Map a range of IO virtual address to physical addresses.
"... to physical addresses using MMU page table"?
Might be clearer?
Yes.
+ */
+#define pgtable_populate(domain, nm) \
+do { \
+ void *__new = alloc_pgtable_page(domain->nid); \
+ if (!__new) \
+ return -ENOMEM; \
+ smp_wmb(); \
Could I ask what's this wmb used for?
Sure. This is answered by a comment in __pte_alloc() in mm/memory.c. Let
me post it here.
/*
* Ensure all pte setup (eg. pte page lock and page clearing) are
* visible before the pte is made visible to other CPUs by being
* put into page tables.
*
* The other side of the story is the pointer chasing in the page
* table walking code (when walking the page table without locking;
* ie. most of the time). Fortunately, these data accesses consist
* of a chain of data-dependent loads, meaning most CPUs (alpha
* being the notable exception) will already guarantee loads are
* seen in-order. See the alpha page table accessors for the
* smp_read_barrier_depends() barriers in page table walking code.
*/
smp_wmb(); /* Could be smp_wmb__xxx(before|after)_spin_lock */
+ spin_lock(&(domain)->page_table_lock); \
Is this intended to lock here instead of taking the lock during the
whole page table walk? Is it safe?
Taking the example where nm==PTE: when we reach here how do we
guarantee that the PMD page that has this PTE is still valid?
We will always keep the non-leaf pages in the table, hence we only need
a spin lock to serialize multiple tries of populating a entry for pde.
As for pte, we can assume there is only single thread which can access
it at a time because different mappings will have different iova's.
+ if (nm ## _present(*nm)) { \
+ free_pgtable_page(__new)
[PATCH] mm: fix typo in the comment when calling function __SetPageUptodate()
There are several places emphasise the effect of __SetPageUptodate(), while the comment seems to have a typo in two places. Signed-off-by: Wei Yang --- mm/memory.c | 2 +- mm/userfaultfd.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/mm/memory.c b/mm/memory.c index b1ca51a079f2..3ac2803d49b8 100644 --- a/mm/memory.c +++ b/mm/memory.c @@ -3009,7 +3009,7 @@ static vm_fault_t do_anonymous_page(struct vm_fault *vmf) /* * The memory barrier inside __SetPageUptodate makes sure that -* preceeding stores to the page contents become visible before +* preceding stores to the page contents become visible before * the set_pte_at() write. */ __SetPageUptodate(page); diff --git a/mm/userfaultfd.c b/mm/userfaultfd.c index 80834c644692..c153344774c7 100644 --- a/mm/userfaultfd.c +++ b/mm/userfaultfd.c @@ -90,7 +90,7 @@ static int mcopy_atomic_pte(struct mm_struct *dst_mm, /* * The memory barrier inside __SetPageUptodate makes sure that -* preceeding stores to the page contents become visible before +* preceding stores to the page contents become visible before * the set_pte_at() write. */ __SetPageUptodate(page); -- 2.17.1
Re: [PATCH v2 12/13] vfio/type1: use iommu_attach_group() for wrapping PF/VF as mdev
On Thu, 5 Sep 2019 15:59:29 +0800
Liu Yi L wrote:
> This patch uses iommu_attach_group() to do group attach when it is
> for the case of wrapping a PF/VF as a mdev. iommu_attach_device()
> doesn't support non-singleton iommu group attach. With this change,
> wrapping PF/VF as mdev can work on non-singleton iommu groups.
>
> Cc: Kevin Tian
> Cc: Lu Baolu
> Suggested-by: Alex Williamson
> Signed-off-by: Liu Yi L
> ---
> drivers/vfio/vfio_iommu_type1.c | 22 ++
> 1 file changed, 18 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
> index 054391f..317430d 100644
> --- a/drivers/vfio/vfio_iommu_type1.c
> +++ b/drivers/vfio/vfio_iommu_type1.c
> @@ -1312,13 +1312,20 @@ static int vfio_mdev_attach_domain(struct device
> *dev, void *data)
> {
> struct iommu_domain *domain = data;
> struct device *iommu_device;
> + struct iommu_group *group;
>
> iommu_device = vfio_mdev_get_iommu_device(dev);
> if (iommu_device) {
> if (iommu_dev_feature_enabled(iommu_device, IOMMU_DEV_FEAT_AUX))
> return iommu_aux_attach_device(domain, iommu_device);
> - else
> - return iommu_attach_device(domain, iommu_device);
> + else {
> + group = iommu_group_get(iommu_device);
> + if (!group) {
> + WARN_ON(1);
What's the value of the WARN_ON here and below?
iommu_group_get() increments the kobject reference, looks like it's
leaked. Thanks,
Alex
> + return -EINVAL;
> + }
> + return iommu_attach_group(domain, group);
> + }
> }
>
> return -EINVAL;
> @@ -1328,13 +1335,20 @@ static int vfio_mdev_detach_domain(struct device
> *dev, void *data)
> {
> struct iommu_domain *domain = data;
> struct device *iommu_device;
> + struct iommu_group *group;
>
> iommu_device = vfio_mdev_get_iommu_device(dev);
> if (iommu_device) {
> if (iommu_dev_feature_enabled(iommu_device, IOMMU_DEV_FEAT_AUX))
> iommu_aux_detach_device(domain, iommu_device);
> - else
> - iommu_detach_device(domain, iommu_device);
> + else {
> + group = iommu_group_get(iommu_device);
> + if (!group) {
> + WARN_ON(1);
> + return -EINVAL;
> + }
> + iommu_detach_group(domain, group);
> + }
> }
>
> return 0;
Re: [PATCH v2 10/13] samples: refine vfio-mdev-pci driver
On Thu, 5 Sep 2019 15:59:27 +0800
Liu Yi L wrote:
> From: Alex Williamson
>
> This patch refines the implementation of original vfio-mdev-pci driver.
>
> And the vfio-mdev-pci-type_name will be named per the following rule:
>
> vmdev->attr.name = kasprintf(GFP_KERNEL,
>"%04x:%04x:%04x:%04x:%06x:%02x",
>pdev->vendor, pdev->device,
>pdev->subsystem_vendor,
>pdev->subsystem_device, pdev->class,
>pdev->revision);
>
> Before usage, check the /sys/bus/pci/devices/$bdf/mdev_supported_types/
> to ensure the final mdev_supported_types.
>
> Cc: Kevin Tian
> Cc: Lu Baolu
> Signed-off-by: Alex Williamson
> Signed-off-by: Liu Yi L
> ---
> drivers/vfio/pci/vfio_mdev_pci.c | 123
> +++
> 1 file changed, 72 insertions(+), 51 deletions(-)
>
> diff --git a/drivers/vfio/pci/vfio_mdev_pci.c
> b/drivers/vfio/pci/vfio_mdev_pci.c
> index 07c8067..09143d3 100644
> --- a/drivers/vfio/pci/vfio_mdev_pci.c
> +++ b/drivers/vfio/pci/vfio_mdev_pci.c
> @@ -65,18 +65,22 @@ MODULE_PARM_DESC(disable_idle_d3,
>
> static struct pci_driver vfio_mdev_pci_driver;
>
> -static ssize_t
> -name_show(struct kobject *kobj, struct device *dev, char *buf)
> -{
> - return sprintf(buf, "%s-type1\n", dev_name(dev));
> -}
> -
> -MDEV_TYPE_ATTR_RO(name);
> +struct vfio_mdev_pci_device {
> + struct vfio_pci_device vdev;
> + struct mdev_parent_ops ops;
> + struct attribute_group *groups[2];
> + struct attribute_group attr;
> + atomic_t avail;
> +};
>
> static ssize_t
> available_instances_show(struct kobject *kobj, struct device *dev, char *buf)
> {
> - return sprintf(buf, "%d\n", 1);
> + struct vfio_mdev_pci_device *vmdev;
> +
> + vmdev = pci_get_drvdata(to_pci_dev(dev));
> +
> + return sprintf(buf, "%d\n", atomic_read(&vmdev->avail));
> }
>
> MDEV_TYPE_ATTR_RO(available_instances);
> @@ -90,62 +94,57 @@ static ssize_t device_api_show(struct kobject *kobj,
> struct device *dev,
> MDEV_TYPE_ATTR_RO(device_api);
>
> static struct attribute *vfio_mdev_pci_types_attrs[] = {
> - &mdev_type_attr_name.attr,
> &mdev_type_attr_device_api.attr,
> &mdev_type_attr_available_instances.attr,
> NULL,
> };
>
> -static struct attribute_group vfio_mdev_pci_type_group1 = {
> - .name = "type1",
> - .attrs = vfio_mdev_pci_types_attrs,
> -};
> -
> -struct attribute_group *vfio_mdev_pci_type_groups[] = {
> - &vfio_mdev_pci_type_group1,
> - NULL,
> -};
> -
> struct vfio_mdev_pci {
> struct vfio_pci_device *vdev;
> struct mdev_device *mdev;
> - unsigned long handle;
> };
>
> static int vfio_mdev_pci_create(struct kobject *kobj, struct mdev_device
> *mdev)
> {
> struct device *pdev;
> - struct vfio_pci_device *vdev;
> + struct vfio_mdev_pci_device *vmdev;
> struct vfio_mdev_pci *pmdev;
> int ret;
>
> pdev = mdev_parent_dev(mdev);
> - vdev = dev_get_drvdata(pdev);
> + vmdev = dev_get_drvdata(pdev);
> +
> + if (atomic_dec_if_positive(&vmdev->avail) < 0)
> + return -ENOSPC;
> +
> pmdev = kzalloc(sizeof(struct vfio_mdev_pci), GFP_KERNEL);
> - if (pmdev == NULL) {
> - ret = -EBUSY;
> - goto out;
> - }
> + if (!pmdev)
> + return -ENOMEM;
Needs an atomic_inc(&vmdev->avail) in this error path. Thanks,
Alex
>
> pmdev->mdev = mdev;
> - pmdev->vdev = vdev;
> + pmdev->vdev = &vmdev->vdev;
> mdev_set_drvdata(mdev, pmdev);
> ret = mdev_set_iommu_device(mdev_dev(mdev), pdev);
> if (ret) {
> pr_info("%s, failed to config iommu isolation for mdev: %s on
> pf: %s\n",
> __func__, dev_name(mdev_dev(mdev)), dev_name(pdev));
> - goto out;
> + kfree(pmdev);
> + atomic_inc(&vmdev->avail);
> + return ret;
> }
>
> -out:
> - return ret;
> + return 0;
> }
>
> static int vfio_mdev_pci_remove(struct mdev_device *mdev)
> {
> struct vfio_mdev_pci *pmdev = mdev_get_drvdata(mdev);
> + struct vfio_mdev_pci_device *vmdev;
> +
> + vmdev = container_of(pmdev->vdev, struct vfio_mdev_pci_device, vdev);
>
> kfree(pmdev);
> + atomic_inc(&vmdev->avail);
> pr_info("%s, succeeded for mdev: %s\n", __func__,
>dev_name(mdev_dev(mdev)));
>
> @@ -237,24 +236,12 @@ static ssize_t vfio_mdev_pci_write(struct mdev_device
> *mdev,
> return vfio_pci_write(pmdev->vdev, (char __user *)buf, count, ppos);
> }
>
> -static const struct mdev_parent_ops vfio_mdev_pci_ops = {
> - .supported_type_groups = vfio_mdev_pci_type_groups,
> - .create = vfio_mdev_pci_create,
> - .remove = vfio_mdev_pci_remove,
> -
> - .open
Re: [PATCH v2 11/13] samples/vfio-mdev-pci: call vfio_add_group_dev()
On Thu, 5 Sep 2019 15:59:28 +0800
Liu Yi L wrote:
> This patch adds vfio_add_group_dev() calling in probe() to make
> vfio-mdev-pci work well with non-singleton iommu group. User could
> bind devices from a non-singleton iommu group to either vfio-pci
> driver or this sample driver. Existing passthru policy works well
> for this non-singleton group.
>
> This is actually a policy choice. A device driver can make this call
> if it wants to be vfio viable. And it needs to provide dummy
> vfio_device_ops which is required by vfio framework. To prevent user
> from opening the device from the iommu backed group fd, the open
> callback of the dummy vfio_device_ops should return -ENODEV to fail
> the VFIO_GET_DEVICE_FD request from userspace.
>
> Cc: Kevin Tian
> Cc: Lu Baolu
> Signed-off-by: Liu Yi L
> ---
> drivers/vfio/pci/vfio_mdev_pci.c | 91
>
> 1 file changed, 82 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/vfio/pci/vfio_mdev_pci.c
> b/drivers/vfio/pci/vfio_mdev_pci.c
> index 09143d3..a61c20d 100644
> --- a/drivers/vfio/pci/vfio_mdev_pci.c
> +++ b/drivers/vfio/pci/vfio_mdev_pci.c
> @@ -107,19 +107,27 @@ struct vfio_mdev_pci {
> static int vfio_mdev_pci_create(struct kobject *kobj, struct mdev_device
> *mdev)
> {
> struct device *pdev;
> + struct vfio_device *device;
> struct vfio_mdev_pci_device *vmdev;
> struct vfio_mdev_pci *pmdev;
> int ret;
>
> pdev = mdev_parent_dev(mdev);
> - vmdev = dev_get_drvdata(pdev);
> + device = vfio_device_get_from_dev(pdev);
> + vmdev = vfio_device_data(device);
>
> - if (atomic_dec_if_positive(&vmdev->avail) < 0)
> - return -ENOSPC;
> + if (atomic_dec_if_positive(&vmdev->avail) < 0) {
> + ret = -ENOSPC;
> + goto out;
> + }
>
> + pr_info("%s, available instance: %d\n",
> + __func__, atomic_read(&vmdev->avail));
> pmdev = kzalloc(sizeof(struct vfio_mdev_pci), GFP_KERNEL);
> - if (!pmdev)
> - return -ENOMEM;
> + if (!pmdev) {
> + ret = -ENOMEM;
> + goto out;
> + }
>
> pmdev->mdev = mdev;
> pmdev->vdev = &vmdev->vdev;
> @@ -130,10 +138,11 @@ static int vfio_mdev_pci_create(struct kobject *kobj,
> struct mdev_device *mdev)
> __func__, dev_name(mdev_dev(mdev)), dev_name(pdev));
> kfree(pmdev);
> atomic_inc(&vmdev->avail);
> - return ret;
> }
>
> - return 0;
> +out:
> + vfio_device_put(device);
> + return ret;
> }
>
> static int vfio_mdev_pci_remove(struct mdev_device *mdev)
> @@ -145,6 +154,8 @@ static int vfio_mdev_pci_remove(struct mdev_device *mdev)
>
> kfree(pmdev);
> atomic_inc(&vmdev->avail);
> + pr_info("%s, available instance: %d\n",
> + __func__, atomic_read(&vmdev->avail));
> pr_info("%s, succeeded for mdev: %s\n", __func__,
>dev_name(mdev_dev(mdev)));
>
> @@ -236,12 +247,65 @@ static ssize_t vfio_mdev_pci_write(struct mdev_device
> *mdev,
> return vfio_pci_write(pmdev->vdev, (char __user *)buf, count, ppos);
> }
>
> +static int vfio_pci_dummy_open(void *device_data)
> +{
> + struct vfio_mdev_pci_device *vmdev =
> + (struct vfio_mdev_pci_device *) device_data;
> + pr_warn("Device %s is not viable for vfio-pci passthru, please follow"
> + " vfio-mdev passthru path as it has been wrapped as mdev!!!\n",
> + dev_name(&vmdev->vdev.pdev->dev));
> + return -ENODEV;
> +}
> +
> +static void vfio_pci_dummy_release(void *device_data)
> +{
> +}
Theoretically .release will never be called. If we're paranoid, we
could keep it with a pr_warn.
> +
> +long vfio_pci_dummy_ioctl(void *device_data,
> +unsigned int cmd, unsigned long arg)
> +{
> + return 0;
> +}
> +
> +ssize_t vfio_pci_dummy_read(void *device_data, char __user *buf,
> + size_t count, loff_t *ppos)
> +{
> + return 0;
> +}
> +
> +ssize_t vfio_pci_dummy_write(void *device_data, const char __user *buf,
> + size_t count, loff_t *ppos)
> +{
> + return 0;
> +}
> +
> +int vfio_pci_dummy_mmap(void *device_data, struct vm_area_struct *vma)
> +{
> + return 0;
> +}
> +
> +void vfio_pci_dummy_request(void *device_data, unsigned int count)
> +{
> +}
AFAICT, none of .ioctl, .read, .write, .mmap, or .request need to be
provided, only .open and only .release for paranoia.
> +
> +static const struct vfio_device_ops vfio_pci_dummy_ops = {
> + .name = "vfio-pci",
This is impersonating vfio-pci, shouldn't we use something like
"vfio-mdev-pci-dummy". Thanks,
Alex
> + .open = vfio_pci_dummy_open,
> + .release= vfio_pci_dummy_release,
> + .ioctl = vfio_pci_dummy_ioctl,
> + .read = vfio_pci_dummy_read,
> +
Re: [PATCH v2 08/13] vfio/pci: protect cap/ecap_perm bits alloc/free with atomic op
On Thu, 5 Sep 2019 15:59:25 +0800
Liu Yi L wrote:
> There is a case in which cap_perms and ecap_perms can be reallocated
> by different modules. e.g. the vfio-mdev-pci sample driver. To secure
> the initialization of cap_perms and ecap_perms, this patch adds an
> atomic variable to track the user of cap/ecap_perms bits. First caller
> of vfio_pci_init_perm_bits() will initialize the bits. While the last
> caller of vfio_pci_uninit_perm_bits() will free the bits.
Yes, but it still allows races; we're not really protecting the data.
If driver A begins freeing the shared data in the uninit path, driver B
could start allocating shared data in the init path and we're left with
either use after free issues or memory leaks. Probably better to hold
a semaphore around the allocation/free and a non-atomic for reference
counting. Thanks,
Alex
> Cc: Kevin Tian
> Cc: Lu Baolu
> Suggested-by: Alex Williamson
> Signed-off-by: Liu Yi L
> ---
> drivers/vfio/pci/vfio_pci_config.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/vfio/pci/vfio_pci_config.c
> b/drivers/vfio/pci/vfio_pci_config.c
> index f0891bd..1b3e6e5 100644
> --- a/drivers/vfio/pci/vfio_pci_config.c
> +++ b/drivers/vfio/pci/vfio_pci_config.c
> @@ -992,11 +992,17 @@ static int __init init_pci_ext_cap_pwr_perm(struct
> perm_bits *perm)
> return 0;
> }
>
> +/* Track the user number of the cap/ecap perm_bits */
> +atomic_t vfio_pci_perm_bits_users = ATOMIC_INIT(0);
> +
> /*
> * Initialize the shared permission tables
> */
> void vfio_pci_uninit_perm_bits(void)
> {
> + if (atomic_dec_return(&vfio_pci_perm_bits_users))
> + return;
> +
> free_perm_bits(&cap_perms[PCI_CAP_ID_BASIC]);
>
> free_perm_bits(&cap_perms[PCI_CAP_ID_PM]);
> @@ -1013,6 +1019,9 @@ int __init vfio_pci_init_perm_bits(void)
> {
> int ret;
>
> + if (atomic_inc_return(&vfio_pci_perm_bits_users) != 1)
> + return 0;
> +
> /* Basic config space */
> ret = init_pci_cap_basic_perm(&cap_perms[PCI_CAP_ID_BASIC]);
>
Re: [PATCH v2 02/13] vfio_pci: refine user config reference in vfio-pci module
On Thu, 5 Sep 2019 15:59:19 +0800
Liu Yi L wrote:
> This patch adds three fields in struct vfio_pci_device to pass the user
> configs of vfio-pci module to some functions which could be common in
> future usage.
>
> Cc: Kevin Tian
> Cc: Lu Baolu
> Signed-off-by: Liu Yi L
> ---
> drivers/vfio/pci/vfio_pci.c | 24 +++-
> drivers/vfio/pci/vfio_pci_private.h | 9 +++--
> 2 files changed, 22 insertions(+), 11 deletions(-)
A subtle behavioral difference here is that disable_idle_d3 and
nointxmask are runtime modifiable parameters, if the value is changed
in sysfs the device will adopt the new behavior on its next
transition. After this patch, each device operates in the mode defined
at the time it was probed. Should we maybe refresh the value at key
points, like the user opening or releasing the device so that it tracks
the module parameter? I think we could defend not changing the
behavior of a device while it's in use by a user. Otherwise we might
want to make the module parameter read-only to avoid the
inconsistency.
>
> diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
> index 38271df..fed2687 100644
> --- a/drivers/vfio/pci/vfio_pci.c
> +++ b/drivers/vfio/pci/vfio_pci.c
> @@ -69,7 +69,8 @@ static unsigned int vfio_pci_set_vga_decode(void *opaque,
> bool single_vga)
> unsigned char max_busnr;
> unsigned int decodes;
>
> - if (single_vga || !vfio_vga_disabled() || pci_is_root_bus(pdev->bus))
> + if (single_vga || !vfio_vga_disabled(vdev) ||
> + pci_is_root_bus(pdev->bus))
> return VGA_RSRC_NORMAL_IO | VGA_RSRC_NORMAL_MEM |
> VGA_RSRC_LEGACY_IO | VGA_RSRC_LEGACY_MEM;
>
> @@ -273,7 +274,7 @@ static int vfio_pci_enable(struct vfio_pci_device *vdev)
> if (!vdev->pci_saved_state)
> pci_dbg(pdev, "%s: Couldn't store saved state\n", __func__);
>
> - if (likely(!nointxmask)) {
> + if (likely(!vdev->nointxmask)) {
> if (vfio_pci_nointx(pdev)) {
> pci_info(pdev, "Masking broken INTx support\n");
> vdev->nointx = true;
> @@ -310,7 +311,7 @@ static int vfio_pci_enable(struct vfio_pci_device *vdev)
> } else
> vdev->msix_bar = 0xFF;
>
> - if (!vfio_vga_disabled() && vfio_pci_is_vga(pdev))
> + if (!vfio_vga_disabled(vdev) && vfio_pci_is_vga(pdev))
> vdev->has_vga = true;
>
>
> @@ -436,7 +437,7 @@ static void vfio_pci_disable(struct vfio_pci_device *vdev)
>
> vfio_pci_try_bus_reset(vdev);
>
> - if (!disable_idle_d3)
> + if (!vdev->disable_idle_d3)
> vfio_pci_set_power_state(vdev, PCI_D3hot);
> }
>
> @@ -1304,6 +1305,11 @@ static int vfio_pci_probe(struct pci_dev *pdev, const
> struct pci_device_id *id)
> spin_lock_init(&vdev->irqlock);
> mutex_init(&vdev->ioeventfds_lock);
> INIT_LIST_HEAD(&vdev->ioeventfds_list);
> + vdev->nointxmask = nointxmask;
> +#ifdef CONFIG_VFIO_PCI_VGA
> + vdev->disable_vga = disable_vga;
> +#endif
> + vdev->disable_idle_d3 = disable_idle_d3;
>
> ret = vfio_add_group_dev(&pdev->dev, &vfio_pci_ops, vdev);
> if (ret) {
> @@ -1328,7 +1334,7 @@ static int vfio_pci_probe(struct pci_dev *pdev, const
> struct pci_device_id *id)
>
> vfio_pci_probe_power_state(vdev);
>
> - if (!disable_idle_d3) {
> + if (!vdev->disable_idle_d3) {
> /*
>* pci-core sets the device power state to an unknown value at
>* bootup and after being removed from a driver. The only
> @@ -1359,7 +1365,7 @@ static void vfio_pci_remove(struct pci_dev *pdev)
> kfree(vdev->region);
> mutex_destroy(&vdev->ioeventfds_lock);
>
> - if (!disable_idle_d3)
> + if (!vdev->disable_idle_d3)
> vfio_pci_set_power_state(vdev, PCI_D0);
>
> kfree(vdev->pm_save);
> @@ -1594,7 +1600,7 @@ static void vfio_pci_try_bus_reset(struct
> vfio_pci_device *vdev)
> if (!ret) {
> tmp->needs_reset = false;
>
> - if (tmp != vdev && !disable_idle_d3)
> + if (tmp != vdev && !tmp->disable_idle_d3)
> vfio_pci_set_power_state(tmp, PCI_D3hot);
> }
>
> @@ -1610,7 +1616,7 @@ static void __exit vfio_pci_cleanup(void)
> vfio_pci_uninit_perm_bits();
> }
>
> -static void __init vfio_pci_fill_ids(void)
> +static void __init vfio_pci_fill_ids(char *ids)
> {
> char *p, *id;
> int rc;
> @@ -1665,7 +1671,7 @@ static int __init vfio_pci_init(void)
> if (ret)
> goto out_driver;
>
> - vfio_pci_fill_ids();
> + vfio_pci_fill_ids(&ids[0]);
Or just 'ids'. Thanks,
Alex
>
> return 0;
>
> diff --git a/drivers/vfio/pci/vfio_pci_private.h
> b/drivers/vfio/pci/vfio_pci_private.h
> index f12d92c..68521d2 100644
> --- a/drivers/vfio/pci/vfio_pci_private.h
Re: [PATCH v3 18/26] scsi: pm80xx: Use PCI_STD_NUM_BARS
On Mon, Sep 23, 2019 at 10:22:42PM -0400, Martin K. Petersen wrote: > > Denis, > > > Replace the magic constant (6) with define PCI_STD_NUM_BARS > > representing the number of PCI BARs. > > Applied to 5.4/scsi-fixes. Thanks! I think this depends on a previous patch that actually adds the PCI_STD_NUM_BARS definition. It will probably be easier if I apply the whole series via the PCI tree. Bjorn
Re: [PATCH] riscv: move flush_icache_range/user_range() after flush_icache_all()
Please ignore this version. On 2019/9/26 10:29, Kefeng Wang wrote: > When build lkdtm module, which used flush_icache_range(), error occurred, > > ERROR: "flush_icache_all" [drivers/misc/lkdtm/lkdtm.ko] undefined! > > Fix it. > > Cc: Paul Walmsley > Cc: Palmer Dabbelt > Cc: Albert Ou > Signed-off-by: Kefeng Wang > --- > arch/riscv/include/asm/cacheflush.h | 14 +++--- > 1 file changed, 7 insertions(+), 7 deletions(-) > > diff --git a/arch/riscv/include/asm/cacheflush.h > b/arch/riscv/include/asm/cacheflush.h > index 555b20b11dc3..f6ec26589620 100644 > --- a/arch/riscv/include/asm/cacheflush.h > +++ b/arch/riscv/include/asm/cacheflush.h > @@ -80,13 +80,6 @@ static inline void flush_dcache_page(struct page *page) > clear_bit(PG_dcache_clean, &page->flags); > } > > -/* > - * RISC-V doesn't have an instruction to flush parts of the instruction > cache, > - * so instead we just flush the whole thing. > - */ > -#define flush_icache_range(start, end) flush_icache_all() > -#define flush_icache_user_range(vma, pg, addr, len) flush_icache_all() > - > #ifndef CONFIG_SMP > > #define flush_icache_all() local_flush_icache_all() > @@ -99,6 +92,13 @@ void flush_icache_mm(struct mm_struct *mm, bool local); > > #endif /* CONFIG_SMP */ > > +/* > + * RISC-V doesn't have an instruction to flush parts of the instruction > cache, > + * so instead we just flush the whole thing. > + */ > +#define flush_icache_range(start, end) flush_icache_all() > +#define flush_icache_user_range(vma, pg, addr, len) flush_icache_all() > + > /* > * Bits in sys_riscv_flush_icache()'s flags argument. > */
[PATCH v2] net: flow_offload: fix memory leak in nfp_abm_u32_knode_replace
In nfp_abm_u32_knode_replace if the allocation for match fails it should
go to the error handling instead of returning.
Signed-off-by: Navid Emamdoost
---
Changes in v2:
- Reused err variable for erorr value returning.
---
drivers/net/ethernet/netronome/nfp/abm/cls.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/netronome/nfp/abm/cls.c
b/drivers/net/ethernet/netronome/nfp/abm/cls.c
index 23ebddfb9532..b0cb9d201f7d 100644
--- a/drivers/net/ethernet/netronome/nfp/abm/cls.c
+++ b/drivers/net/ethernet/netronome/nfp/abm/cls.c
@@ -198,14 +198,18 @@ nfp_abm_u32_knode_replace(struct nfp_abm_link *alink,
if ((iter->val & cmask) == (val & cmask) &&
iter->band != knode->res->classid) {
NL_SET_ERR_MSG_MOD(extack, "conflict with already
offloaded filter");
+ err = -EOPNOTSUPP;
goto err_delete;
}
}
if (!match) {
match = kzalloc(sizeof(*match), GFP_KERNEL);
- if (!match)
- return -ENOMEM;
+ if (!match) {
+ err = -ENOMEM;
+ goto err_delete;
+ }
+
list_add(&match->list, &alink->dscp_map);
}
match->handle = knode->handle;
@@ -221,7 +225,7 @@ nfp_abm_u32_knode_replace(struct nfp_abm_link *alink,
err_delete:
nfp_abm_u32_knode_delete(alink, knode);
- return -EOPNOTSUPP;
+ return err;
}
static int nfp_abm_setup_tc_block_cb(enum tc_setup_type type,
--
2.17.1
linux-next: Tree for Sep 25
Hi all, News: Builds for this week won't appear every day, I will try to do some but no guarantees until Stephen returns on the 30th. pending-fixes will get more updates than full -next. Changes since 20190924: The risc-v-fixes tree gained a conflict with Linus' tree which I fixed up. Non-merge commits (relative to Linus' tree): 1068 1327 files changed, 30940 insertions(+), 14589 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a defconfig for arm64, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. Below is a summary of the state of the merge. I am currently merging 311 trees (counting Linus' and 77 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. signature.asc Description: PGP signature
[PATCH] riscv: move flush_icache_range/user_range() after flush_icache_all()
When build lkdtm module, which used flush_icache_range(), error occurred, ERROR: "flush_icache_all" [drivers/misc/lkdtm/lkdtm.ko] undefined! Fix it. Cc: Paul Walmsley Cc: Palmer Dabbelt Cc: Albert Ou Signed-off-by: Kefeng Wang --- arch/riscv/include/asm/cacheflush.h | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/arch/riscv/include/asm/cacheflush.h b/arch/riscv/include/asm/cacheflush.h index 555b20b11dc3..f6ec26589620 100644 --- a/arch/riscv/include/asm/cacheflush.h +++ b/arch/riscv/include/asm/cacheflush.h @@ -80,13 +80,6 @@ static inline void flush_dcache_page(struct page *page) clear_bit(PG_dcache_clean, &page->flags); } -/* - * RISC-V doesn't have an instruction to flush parts of the instruction cache, - * so instead we just flush the whole thing. - */ -#define flush_icache_range(start, end) flush_icache_all() -#define flush_icache_user_range(vma, pg, addr, len) flush_icache_all() - #ifndef CONFIG_SMP #define flush_icache_all() local_flush_icache_all() @@ -99,6 +92,13 @@ void flush_icache_mm(struct mm_struct *mm, bool local); #endif /* CONFIG_SMP */ +/* + * RISC-V doesn't have an instruction to flush parts of the instruction cache, + * so instead we just flush the whole thing. + */ +#define flush_icache_range(start, end) flush_icache_all() +#define flush_icache_user_range(vma, pg, addr, len) flush_icache_all() + /* * Bits in sys_riscv_flush_icache()'s flags argument. */ -- 2.20.1
Re: [PATCH 0/6] arm64: meson-gx: misc fixes and updates
Christian Hewitt writes: > This patchset: > > - Fixes bluetooth on Khadas VIM2 > - Fixes bluetooth on Khadas VIM > - Fixes GPIO key dt on Khadas VIM > - Updates model for AML-S805X-CC > - Updates model/compatible for AML-S905X-CC Queued for v5.5. Thanks for the updates/fixups, Kevin
Re: [BACKPORT 4.14.y v3 1/3] locking/lockdep: Add debug_locks check in __lock_downgrade()
On Wed, 25 Sep 2019 at 22:05, Waiman Long wrote: > > On 9/25/19 6:01 AM, Baolin Wang wrote: > > From: Waiman Long > > > > [Upstream commit 513e1073d52e55b8024b4f238a48de7587c64ccf] > > > > Tetsuo Handa had reported he saw an incorrect "downgrading a read lock" > > warning right after a previous lockdep warning. It is likely that the > > previous warning turned off lock debugging causing the lockdep to have > > inconsistency states leading to the lock downgrade warning. > > > > Fix that by add a check for debug_locks at the beginning of > > __lock_downgrade(). > > > > Reported-by: Tetsuo Handa > > Reported-by: syzbot+53383ae265fb161ef...@syzkaller.appspotmail.com > > Signed-off-by: Waiman Long > > Signed-off-by: Peter Zijlstra (Intel) > > Cc: Andrew Morton > > Cc: Linus Torvalds > > Cc: Paul E. McKenney > > Cc: Peter Zijlstra > > Cc: Thomas Gleixner > > Cc: Will Deacon > > Link: > > https://lkml.kernel.org/r/1547093005-26085-1-git-send-email-long...@redhat.com > > Signed-off-by: Ingo Molnar > > Signed-off-by: Baolin Wang > > --- > > kernel/locking/lockdep.c |3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c > > index 565005a..5c370c6 100644 > > --- a/kernel/locking/lockdep.c > > +++ b/kernel/locking/lockdep.c > > @@ -3650,6 +3650,9 @@ static int reacquire_held_locks(struct task_struct > > *curr, unsigned int depth, > > unsigned int depth; > > int i; > > > > + if (unlikely(!debug_locks)) > > + return 0; > > + > > depth = curr->lockdep_depth; > > /* > >* This function is about (re)setting the class of a held lock, > > Apparently, there are 2 such patches in the upstream kernel - commit > 513e1073d52e55b8024b4f238a48de7587c64ccf and > 71492580571467fb7177aade19c18ce7486267f5. These are probably caused by > the fact that there are 2 places in the code that can match the hunks. > Anyway, this looks like it is applying to the wrong function. It should > be applied to __lock_downgrade. Though it shouldn't harm if it is > applied to the wrong function. Ah, I noticed there are 2 commits with the same commit message, though 513e1073d52e55b8024b4f238a48de7587c64ccf patch did not change the __lock_downgrade(), which is really confusing. This patch (513e1073d52e55b8024b4f238a48de7587c64ccf) did the right thing, and 71492580571467fb7177aade19c18ce7486267f5 patch should be applied to __lock_downgrade. I'll backport commit 71492580571467fb7177aade19c18ce7486267f5 too in future. Thanks. -- Baolin Wang Best Regards
Re: [PATCH 30/32] tools lib bpf: Renaming pr_warning to pr_warn
On 2019/9/23 21:35, Daniel Borkmann wrote:
> On Mon, Sep 23, 2019 at 01:03:06PM +0200, Petr Mladek wrote:
>> On Mon 2019-09-23 10:20:39, Daniel Borkmann wrote:
>>> On Sun, Sep 22, 2019 at 02:07:21PM -0700, Andrii Nakryiko wrote:
On Fri, Sep 20, 2019 at 10:06 AM Kefeng Wang
wrote:
> For kernel logging macro, pr_warning is completely removed and
> replaced by pr_warn, using pr_warn in tools lib bpf for symmetry
> to kernel logging macro, then we could drop pr_warning in the
> whole linux code.
>
> Signed-off-by: Kefeng Wang
> ---
> tools/lib/bpf/btf.c | 56 +--
> tools/lib/bpf/btf_dump.c| 20 +-
> tools/lib/bpf/libbpf.c | 652
> tools/lib/bpf/libbpf_internal.h | 2 +-
> tools/lib/bpf/xsk.c | 4 +-
> 5 files changed, 363 insertions(+), 371 deletions(-)
Thanks! This will allow to get rid of tons warnings from checkpatch.pl.
Alexei, Daniel, can we take this through bpf-next tree once it's open?
>>> I'd be fine with that, in fact, it probably should be in order to avoid
>>> merge conflicts since pr_warn{ing}() is used all over the place in libbpf.
>> The entire patchset modifies many files all over the tree.
>> This is from
>> https://lkml.kernel.org/r/20190920062544.180997-1-wangkefeng.w...@huawei.com
>>
>> 120 files changed, 882 insertions(+), 927 deletions(-)
>>
>> Would it make sense to push everything at the end of the merge window
>> or for 5.4-rc2 after master settles down?
> If all over the tree it would probably make more sense for e.g. Andrew Morton
> to
> pick it up if there are no other objections, and try to merge it during
> mentioned
> time frame.
Hi Andrew，could you pick them up if no objections, and I could resend all with
comment fixed
with better time frame(rc1 or rc2 ), is it OK？
Thanks.
>
> Thanks,
> Daniel
>
> .
>
Re: [PATCH 1/2] perf script python: integrate page reclaim analyze script
On 9/18/19 7:38 AM, Yafang Shao wrote:
> A new perf script page-reclaim is introduced in this patch. This new script
> is used to report the page reclaim details. The possible usage of this
> script is as bellow,
> - identify latency spike caused by direct reclaim
> - whehter the latency spike is relevant with pageout
> - why is page reclaim requested, i.e. whether it is because of memory
> fragmentation
> - page reclaim efficiency
> etc
> In the future we may also enhance it to analyze the memcg reclaim.
>
> Bellow is how to use this script,
> # Record, one of the following
> $ perf record -e 'vmscan:mm_vmscan_*' ./workload
> $ perf script record page-reclaim
>
> # Report
> $ perf script report page-reclaim
>
> # Report per process latency
> $ perf script report page-reclaim -- -p
I tested it with global-dhp__pagereclaim-performance from mmtests and got what
appears to be reasonable results and the output looks correct and useful.
However I'm not a vm expert so I can't comment further. Hopefully someone on
linux-mm can give more specific feedback.
There is one issue with Python3, see below. I didn't test with Python2.
>
> + @classmethod
> + def shrink_inactive(cls, pid, scanned, reclaimed, flags):
> + event = cls.events.get(pid)
> + if event and event.tracing():
> + # RECLAIM_WB_ANON 0x1
> + # RECLAIM_WB_FILE 0x2
> + _type = (flags & 0x2) >> 1
> + event.process_lru(lru[_type], scanned, reclaimed)
> +
> + @classmethod
> + def writepage(cls, pid, flags):
> + event = cls.events.get(pid)
> + if event and event.tracing():
> + # RECLAIM_WB_ANON 0x1
> + # RECLAIM_WB_FILE 0x2
> + # RECLAIM_WB_SYNC 0x4
> + # RECLAIM_WB_ASYNC 0x8
> + _type = (flags & 0x2) >> 1
> + _io = (flags & 0x4) >> 2
> +
> + event.process_writepage(lru[_type], sync_io[_io])
> +
> +@classmethod
Space indentation on line above. For python3 this results in:
File "tools/perf/scripts/python/page-reclaim.py", line 217
@classmethod
^
TabError: inconsistent use of tabs and spaces in indentation
> + def iterate_proc(cls):
> + if show_opt != Show.DEFAULT:
> + print("\nPer process latency (ms):")
> + print_proc_latency(latency_metric, 'pid', '[comm]')
> +
> + if show_opt == Show.VERBOSE:
> + print("%20s %s" % ('timestamp','latency(ns)'))
Thanks
Tony
RE: [EXT] Re: [v3,3/3] Documentation: dt: binding: fsl: Add 'fsl,ippdexpcr-alt-addr' property
> Caution: EXT Email > > On Tue, Sep 24, 2019 at 11:27 PM Biwen Li wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The 'fsl,ippdexpcr-alt-addr' property is used to > > > > > > > > > > > handle an errata > > > > > > > > > > > A-008646 on LS1021A > > > > > > > > > > > > > > > > > > > > > > Signed-off-by: Biwen Li > > > > > > > > > > > --- > > > > > > > > > > > Change in v3: > > > > > > > > > > > - rename property name > > > > > > > > > > > fsl,rcpm-scfg -> fsl,ippdexpcr-alt-addr > > > > > > > > > > > > > > > > > > > > > > Change in v2: > > > > > > > > > > > - update desc of the property 'fsl,rcpm-scfg' > > > > > > > > > > > > > > > > > > > > > > Documentation/devicetree/bindings/soc/fsl/rcpm.txt > > > > > > > > > > > | 14 > > > > > > > > > > > ++ > > > > > > > > > > > 1 file changed, 14 insertions(+) > > > > > > > > > > > > > > > > > > > > > > diff --git > > > > > > > > > > > a/Documentation/devicetree/bindings/soc/fsl/rcpm.txt > > > > > > > > > > > b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt > > > > > > > > > > > index 5a33619d881d..157dcf6da17c 100644 > > > > > > > > > > > --- > > > > > > > > > > > a/Documentation/devicetree/bindings/soc/fsl/rcpm.txt > > > > > > > > > > > +++ b/Documentation/devicetree/bindings/soc/fsl/rcpm > > > > > > > > > > > +++ .txt > > > > > > > > > > > @@ -34,6 +34,11 @@ Chassis VersionExample > > > > > Chips > > > > > > > > > > > Optional properties: > > > > > > > > > > > - little-endian : RCPM register block is Little Endian. > > > > > > > > > > > Without it > > > > > > RCPM > > > > > > > > > > > will be Big Endian (default case). > > > > > > > > > > > + - fsl,ippdexpcr-alt-addr : Must add the property > > > > > > > > > > > + for SoC LS1021A, > > > > > > > > > > > > > > > > > > > > You probably should mention this is related to a > > > > > > > > > > hardware issue on LS1021a and only needed on LS1021a. > > > > > > > > > Okay, got it, thanks, I will add this in v4. > > > > > > > > > > > > > > > > > > > > > + Must include n + 1 entries (n = > > > > > > > > > > > + #fsl,rcpm-wakeup-cells, such > > > > as: > > > > > > > > > > > + #fsl,rcpm-wakeup-cells equal to 2, then must > > > > > > > > > > > + include > > > > > > > > > > > + 2 > > > > > > > > > > > + + > > > > > > > > > > > + 1 > > > > > > entries). > > > > > > > > > > > > > > > > > > > > #fsl,rcpm-wakeup-cells is the number of IPPDEXPCR > > > > > > > > > > registers on an > > > > > > SoC. > > > > > > > > > > However you are defining an offset to scfg registers here. > > > > > > > > > > Why these two are related? The length here should > > > > > > > > > > actually be related to the #address-cells of the soc/. > > > > > > > > > > But since this is only needed for LS1021, you can > > > > > > > > > just make it 3. > > > > > > > > > I need set the value of IPPDEXPCR resgiters from > > > > > > > > > ftm_alarm0 device node(fsl,rcpm-wakeup = <&rcpm 0x0 > > > > > > > > > 0x2000>; > > > > > > > > > 0x0 is a value for IPPDEXPCR0, 0x2000 is a value for > > > > > > IPPDEXPCR1). > > > > > > > > > But because of the hardware issue on LS1021A, I need > > > > > > > > > store the value of IPPDEXPCR registers to an alt > > > > > > > > > address. So I defining an offset to scfg registers, then > > > > > > > > > RCPM driver get an abosolute address from offset, RCPM > > > > > > > > > driver write the value of IPPDEXPCR registers to these > > > > > > > > > abosolute addresses(backup the value of IPPDEXPCR > > > > > > registers). > > > > > > > > > > > > > > > > I understand what you are trying to do. The problem is > > > > > > > > that the new fsl,ippdexpcr-alt-addr property contains a > > > > > > > > phandle and an > > > offset. > > > > > > > > The size of it shouldn't be related to #fsl,rcpm-wakeup-cells. > > > > > > > You maybe like this: fsl,ippdexpcr-alt-addr = <&scfg > > > > > > > 0x51c>;/* > > > > > > > SCFG_SPARECR8 */ > > > > > > > > > > > > No. The #address-cell for the soc/ is 2, so the offset to > > > > > > scfg should be 0x0 0x51c. The total size should be 3, but it > > > > > > shouldn't be coming from #fsl,rcpm-wakeup-cells like you > > > > > > mentioned in the > > > binding. > > > > > Oh, I got it. You want that fsl,ippdexpcr-alt-add is relative > > > > > with #address-cells instead of #fsl,rcpm-wakeup-cells. > > > > > > > > Yes. > > > I got an example from drivers/pci/controller/dwc/pci-layerscape.c > > > and arch/arm/boot/dts/ls1021a.dtsi as follows: > > > fsl,pcie-scfg = <&scfg 0>, 0 is an index > > > > > > In my fsl,ippdexpcr-alt-addr = <&scfg 0x0 0x51c>, It means that 0x0 > > > is an alt offset address for IPPDEXPCR0, 0x51c is an alt offset > > > address For > > > IPPDEXPCR1 instead of 0x0 and 0x51c compose to an alt address of > > > SCFG_SPARECR8. > > Maybe I need write it as: > > fsl,ippdexpcr-alt-addr = <&scfg 0x0 0x0 0x0 0x51c>; first two 0x0 > > compose an alt offset address for IPPDEXPCR0, last 0x0 and 0x51c > > compose an alt add
Re: [PATCH V5 4/4] ASoC: fsl_asrc: Fix error with S24_3LE format bitstream in i.MX8
Just a small concern...
On Thu, Sep 26, 2019 at 09:29:51AM +0800, Shengjiu Wang wrote:
> static int fsl_asrc_dma_startup(struct snd_pcm_substream *substream)
> {
> +
> + release_pair = false;
> + ret = snd_soc_set_runtime_hwparams(substream, &snd_imx_hardware);
This set_runtime_hwparams() always returns 0 for now, but if
one day it changes and it fails here, kfree() will be still
ignored although the startup() gets error-out.
We could avoid this if we continue to ignore the return value
like the current code. Or we may check ret at kfree() also?
> +
> +out:
> + dma_release_channel(tmp_chan);
> +
> +dma_chan_err:
> + fsl_asrc_release_pair(pair);
> +
> +req_pair_err:
> + if (release_pair)
> + kfree(pair);
> +
> + return ret;
> }
Re: [PATCH v2 4/4] task: RCUify the assignment of rq->curr
Frederic Weisbecker writes:
> On Sat, Sep 14, 2019 at 07:35:02AM -0500, Eric W. Biederman wrote:
>> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
>> index 69015b7c28da..668262806942 100644
>> --- a/kernel/sched/core.c
>> +++ b/kernel/sched/core.c
>> @@ -3857,7 +3857,11 @@ static void __sched notrace __schedule(bool preempt)
>>
>> if (likely(prev != next)) {
>> rq->nr_switches++;
>> -rq->curr = next;
>> +/*
>> + * RCU users of rcu_dereference(rq->curr) may not see
>> + * changes to task_struct made by pick_next_task().
>> + */
>> +RCU_INIT_POINTER(rq->curr, next);
>
> It would be nice to have more explanations in the comments as to why we
> don't use rcu_assign_pointer() here (the very fast-path issue) and why
> it is expected to be fine (the rq_lock() + post spinlock barrier) under
> which condition. Some short summary of the changelog. Because that line
> implies way too many subtleties.
Crucially that line documents the standard rules don't apply,
and it documents which guarantees a new user of the code can probably
count on. I say probably because the comment may go stale before I new
user of rcu appears. I have my hopes things are simple enough at that
location that if the comment needs to be changed it can be.
If it is not obvious from reading the code that calls
"task_rcu_dereference(rq->curr)" now "rcu_dereference(rq->curr)" why we
don't need the guarantees from rcu_assign_pointet() my sense is that
it should be those locations that document what guarantees they need.
Of the several different locations that use this my sense is that they
all have different requirements.
- The rcuwait code just needs the lifetime change as it never dereferences
rq->curr.
- The membarrier code just looks at rq->curr->mm for a moment so it
hardly needs anything. I suspect we might be able to make the rcu
critical section smaller in that code.
- I don't know the code in task_numa_compare() well enough even to make an
educated guess. Peter asserts (if I read his reply correctly) it is
all just a heuristic so stale values should not matter.
My reading of the code strongly suggests that we have the ordinary
rcu_assign_pointer() guarantees there. The few fields that are not
covered by the ordinary guarantees do not appear to be read. So even
if Peter is wrong RCU_INIT_POINTER appears safe to me.
I also don't think we will have confusion with people reading the
code and expecting ordinary rcu_dereference semantics().
I can't possibly see putting the above several lines in a meaningful
comment where RCU_INIT_POINTER is called. Especially in a comment
that will survive changes to any of those functions. My experience
is comments that try that are almost always overlooked when someone
updates the code.
I barely found all of the comments that depended upon the details of
task_rcu_dereference and updated them in my patchset, when I removed
the need for task_rcu_dereference.
I don't think it would be wise to put a comment that is a wall of words
in the middle of __schedule(). I think it will become inaccurate with
time and because it is a lot of words I think it will be ignored.
As for the __schedule: It is the heart of the scheduler. It is
performance code. It is clever code. It is likely to stay that way
because it is the scheduler. There are good technical reasons for the
code is the way it is, and anyone changing the scheduler in a
responsible manner that includes benchmarking should find those
technical reasons quickly enough.
So I think a quick word to the wise is enough. Comments are certainly
not enough to prevent people being careless and making foolish mistakes.
Eric
Re: [PATCH 24/32] dma-debug: Use pr_warn instead of pr_warning
On 2019/9/26 1:13, Christoph Hellwig wrote:
> On Fri, Sep 20, 2019 at 02:25:36PM +0800, Kefeng Wang wrote:
>> As said in commit f2c2cbcc35d4 ("powerpc: Use pr_warn instead of
>> pr_warning"), removing pr_warning so all logging messages use a
>> consistent _warn style. Let's do it.
> Please just send a script after -rc1 instead of sending all these
> little patches.
For all changes, just git grep -w pr_warning | cut -d ':' -f1 | uniq | sort |
xargs sed -i 's/pr_warning/pr_warn/g',
but I do need check them manually and make some minor improvements, like
coalesce format, realign arguments,
and remove unnecessary line continuations. thus, send these littles patches.
Thanks.
> .
>
Re: [PATCH 2/2] devfreq: Rename df->previous_freq to df->cur_freq
Hi,
I'm not objecting this patch.
But, as I commented on previous patch,
Actually, according to reference time of the 'df->previous_freq',
'previous_freq' is proper or 'cur_freq is proper.
But, In the comment of 'struct devfreq', it means the configured time
as following: It was the intention of author (Myungjoo).
* @previous_freq: previously configured frequency value.
I think that it's not problem ans better to keep the name if possible.
I leave the final decision of this patch to Myungjoo.
If he like this patch, I have no any objection.
On 19. 9. 26. 오전 3:43, Matthias Kaehlcke wrote:
> The vast majority of code uses df->previous_freq to get the current
> frequency of the devfreq device, not the previous one. Rename the
> struct field to reflect this.
>
> Add a comment to devfreq_update_stats() to make clear that df->cur_freq
> must only be updated after calling this function in the context of a
> frequency transition.
>
> Signed-off-by: Matthias Kaehlcke
> ---
> drivers/devfreq/devfreq.c| 28
> drivers/devfreq/governor_passive.c | 6 +++---
> drivers/devfreq/governor_userspace.c | 2 +-
> drivers/devfreq/tegra20-devfreq.c| 2 +-
> drivers/devfreq/tegra30-devfreq.c| 2 +-
> include/linux/devfreq.h | 4 ++--
> include/trace/events/devfreq.h | 2 +-
> 7 files changed, 25 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
> index fb4318d59aa9..bf42130bb4ec 100644
> --- a/drivers/devfreq/devfreq.c
> +++ b/drivers/devfreq/devfreq.c
> @@ -154,6 +154,10 @@ static int set_freq_table(struct devfreq *devfreq)
> * devfreq_update_stats() - Update statistics of devfreq behavior
> * @devfreq: the devfreq instance
> * @freq:the update target frequency
> + *
> + * If the function is called in the context of a frequency transition
> + * it expects df->cur_freq to contain the value *before* the transition.
> + * The field must only be updated after calling devfreq_update_stats().
> */
> int devfreq_update_stats(struct devfreq *devfreq, unsigned long freq)
> {
> @@ -162,11 +166,11 @@ int devfreq_update_stats(struct devfreq *devfreq,
> unsigned long freq)
>
> cur_time = jiffies;
>
> - /* Immediately exit if previous_freq is not initialized yet. */
> - if (!devfreq->previous_freq)
> + /* Immediately exit if cur_freq is not initialized yet. */
> + if (!devfreq->cur_freq)
> goto out;
>
> - prev_lev = devfreq_get_freq_level(devfreq, devfreq->previous_freq);
> + prev_lev = devfreq_get_freq_level(devfreq, devfreq->cur_freq);
> if (prev_lev < 0) {
> ret = prev_lev;
> goto out;
> @@ -295,7 +299,7 @@ static int devfreq_set_target(struct devfreq *devfreq,
> unsigned long new_freq,
> if (devfreq->profile->get_cur_freq)
> devfreq->profile->get_cur_freq(devfreq->dev.parent, &cur_freq);
> else
> - cur_freq = devfreq->previous_freq;
> + cur_freq = devfreq->cur_freq;
>
> freqs.old = cur_freq;
> freqs.new = new_freq;
> @@ -315,7 +319,7 @@ static int devfreq_set_target(struct devfreq *devfreq,
> unsigned long new_freq,
> dev_err(&devfreq->dev,
> "Couldn't update frequency transition information.\n");
>
> - devfreq->previous_freq = new_freq;
> + devfreq->cur_freq = new_freq;
>
> if (devfreq->suspend_freq)
> devfreq->resume_freq = cur_freq;
> @@ -450,7 +454,7 @@ void devfreq_monitor_suspend(struct devfreq *devfreq)
> return;
> }
>
> - devfreq_update_stats(devfreq, devfreq->previous_freq);
> + devfreq_update_stats(devfreq, devfreq->cur_freq);
> devfreq->stop_polling = true;
> mutex_unlock(&devfreq->lock);
> cancel_delayed_work_sync(&devfreq->work);
> @@ -483,7 +487,7 @@ void devfreq_monitor_resume(struct devfreq *devfreq)
>
> if (devfreq->profile->get_cur_freq &&
> !devfreq->profile->get_cur_freq(devfreq->dev.parent, &freq))
> - devfreq->previous_freq = freq;
> + devfreq->cur_freq = freq;
>
> out:
> mutex_unlock(&devfreq->lock);
> @@ -644,7 +648,7 @@ struct devfreq *devfreq_add_device(struct device *dev,
> devfreq->dev.release = devfreq_dev_release;
> devfreq->profile = profile;
> strncpy(devfreq->governor_name, governor_name, DEVFREQ_NAME_LEN);
> - devfreq->previous_freq = profile->initial_freq;
> + devfreq->cur_freq = profile->initial_freq;
> devfreq->last_status.current_frequency = profile->initial_freq;
> devfreq->data = data;
> devfreq->nb.notifier_call = devfreq_notifier_call;
> @@ -1235,14 +1239,14 @@ static ssize_t cur_freq_show(struct device *dev,
> struct device_attribute *attr,
> !devfreq->profile->get_cur_freq(devfreq->dev.parent, &freq))
> return sprintf(buf, "%lu\n", freq);
>
> -
[PATCH v4 0/1] Add bounds check for Hotplugged memory
From: Alastair D'Silva This series adds bounds checks for hotplugged memory, ensuring that it is within the physically addressable range (for platforms that define MAX_(POSSIBLE_)PHYSMEM_BITS. This allows for early failure, rather than attempting to access bogus section numbers. Changelog: V4: - Relocate call to __add_pages - Add a warning when the addressable check fails V3: - Perform the addressable check before we take the hotplug lock V2: - Don't use MAX_POSSIBLE_PHYSMEM_BITS as it's wider that what may be available Alastair D'Silva (1): memory_hotplug: Add a bounds check to __add_pages mm/memory_hotplug.c | 21 + 1 file changed, 21 insertions(+) -- 2.21.0
[PATCH v4] memory_hotplug: Add a bounds check to __add_pages
From: Alastair D'Silva
On PowerPC, the address ranges allocated to OpenCAPI LPC memory
are allocated from firmware. These address ranges may be higher
than what older kernels permit, as we increased the maximum
permissable address in commit 4ffe713b7587
("powerpc/mm: Increase the max addressable memory to 2PB"). It is
possible that the addressable range may change again in the
future.
In this scenario, we end up with a bogus section returned from
__section_nr (see the discussion on the thread "mm: Trigger bug on
if a section is not found in __section_nr").
Adding a check here means that we fail early and have an
opportunity to handle the error gracefully, rather than rumbling
on and potentially accessing an incorrect section.
Further discussion is also on the thread ("powerpc: Perform a bounds
check in arch_add_memory")
http://lkml.kernel.org/r/20190827052047.31547-1-alast...@au1.ibm.com
Signed-off-by: Alastair D'Silva
---
mm/memory_hotplug.c | 20
1 file changed, 20 insertions(+)
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index c73f09913165..212804c0f7f5 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -278,6 +278,22 @@ static int check_pfn_span(unsigned long pfn, unsigned long
nr_pages,
return 0;
}
+static int check_hotplug_memory_addressable(unsigned long pfn,
+ unsigned long nr_pages)
+{
+ unsigned long max_addr = ((pfn + nr_pages) << PAGE_SHIFT) - 1;
+
+ if (max_addr >> MAX_PHYSMEM_BITS) {
+ WARN(1,
+"Hotplugged memory exceeds maximum addressable address,
range=%#lx-%#lx, maximum=%#lx\n",
+pfn << PAGE_SHIFT, max_addr,
+(1ul << (MAX_PHYSMEM_BITS + 1)) - 1);
+ return -E2BIG;
+ }
+
+ return 0;
+}
+
/*
* Reasonably generic function for adding memory. It is
* expected that archs that support memory hotplug will
@@ -291,6 +307,10 @@ int __ref __add_pages(int nid, unsigned long pfn, unsigned
long nr_pages,
unsigned long nr, start_sec, end_sec;
struct vmem_altmap *altmap = restrictions->altmap;
+ err = check_hotplug_memory_addressable(pfn, nr_pages);
+ if (err)
+ return err;
+
if (altmap) {
/*
* Validate altmap is within bounds of the total request
--
2.21.0
Re: [PATCH 4/5] dt-bindings: usb: dwc3: of-simple: add compatible for HiSi
On Wed, 2019-09-25 at 23:42 +, John Stultz wrote:
> Add necessary compatible flag for HiSi's DWC3 so
> dwc3-of-simple will probe.
>
> Cc: Greg Kroah-Hartman
> Cc: Felipe Balbi
> Cc: Andy Shevchenko
> Cc: Rob Herring
> Cc: Mark Rutland
> Cc: Yu Chen
> Cc: Matthias Brugger
> Cc: Chunfeng Yun
> Cc: linux-...@vger.kernel.org
> Cc: devicet...@vger.kernel.org
> Signed-off-by: John Stultz
> ---
> .../devicetree/bindings/usb/hisi,dwc3.txt | 52 +++
> 1 file changed, 52 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/usb/hisi,dwc3.txt
>
> diff --git a/Documentation/devicetree/bindings/usb/hisi,dwc3.txt
> b/Documentation/devicetree/bindings/usb/hisi,dwc3.txt
> new file mode 100644
> index ..dc31b8a3c006
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/hisi,dwc3.txt
> @@ -0,0 +1,52 @@
> +HiSi SuperSpeed DWC3 USB SoC controller
> +
> +Required properties:
> +- compatible:should contain "hisilicon,hi3660-dwc3" for HiSi
> SoC
> +- clocks:A list of phandle + clock-specifier pairs for the
> + clocks listed in clock-names
> +- clock-names: Should contain the following:
> + "clk_usb3phy_ref" Phy reference clk
It's not good idea to apply phy's clock in dwc3's node
> + "aclk_usb3otg" USB3 OTG aclk
> +
> +- assigned-clocks: Should be:
> + HI3660_ACLK_GATE_USB3OTG
> +- assigned-clock-rates: Should be:
> + 229Mhz (22900) for HI3660_ACLK_GATE_USB3OTG
> +
> +Optional properties:
> +- resets:Phandle to reset control that resets core and wrapper.
> +
> +Required child node:
> +A child node must exist to represent the core DWC3 IP block. The name of
> +the node is not important. The content of the node is defined in dwc3.txt.
> +
> +Example device nodes:
> +
> + usb3: hisi_dwc3 {
> + compatible = "hisilicon,hi3660-dwc3";
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> +
> + clocks = <&crg_ctrl HI3660_CLK_ABB_USB>,
> + <&crg_ctrl HI3660_ACLK_GATE_USB3OTG>;
> + clock-names = "clk_usb3phy_ref", "aclk_usb3otg";
> +
> + assigned-clocks = <&crg_ctrl HI3660_ACLK_GATE_USB3OTG>;
> + assigned-clock-rates = <229 000 000>;
> + resets = <&crg_rst 0x90 8>,
> + <&crg_rst 0x90 7>,
> + <&crg_rst 0x90 6>,
> + <&crg_rst 0x90 5>;
> +
> + dwc3: dwc3@ff10 {
> + compatible = "snps,dwc3";
> + reg = <0x0 0xff10 0x0 0x10>;
> + interrupts = <0 159 4>, <0 161 4>;
> + phys = <&usb_phy>;
> + phy-names = "usb3-phy";
> + dr_mode = "otg";
> +
> + ...
> + };
> + };
Re: [PATCH 1/2] devfreq: Rename devfreq_update_status() to devfreq_update_stats() and viceversa
Hi,
I'm not sure that it is necessary. I think that it depends on
personal opinions. There are no correct answer perfectly.
Also, after this changes, there are no any beneficial.
It touch the history rather than behavior improvement.
On 19. 9. 26. 오전 3:43, Matthias Kaehlcke wrote:
> devfreq has two functions with very similar names, devfreq_update_status()
> and devfreq_update_stats(). _update_status() currently updates
> frequency transitions statistics, while _update_stats() retrieves the
> device 'status'. The function names are inversed with respect to what
> the functions are actually doing, rename devfreq_update_status() to
> devfreq_update_stats() and viceversa.
>
> Signed-off-by: Matthias Kaehlcke
> ---
> We could also rename the current devfreq_update_stats() to
> devfreq_refresh_status() to make it easier to distinguish it from
> devfreq_update_stats().
> ---
> drivers/devfreq/devfreq.c | 12 ++--
> drivers/devfreq/governor.h| 4 ++--
> drivers/devfreq/governor_passive.c| 2 +-
> drivers/devfreq/governor_simpleondemand.c | 2 +-
> drivers/devfreq/tegra30-devfreq.c | 2 +-
> 5 files changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
> index 446490c9d635..fb4318d59aa9 100644
> --- a/drivers/devfreq/devfreq.c
> +++ b/drivers/devfreq/devfreq.c
> @@ -151,11 +151,11 @@ static int set_freq_table(struct devfreq *devfreq)
> }
>
> /**
> - * devfreq_update_status() - Update statistics of devfreq behavior
> + * devfreq_update_stats() - Update statistics of devfreq behavior
> * @devfreq: the devfreq instance
> * @freq:the update target frequency
> */
> -int devfreq_update_status(struct devfreq *devfreq, unsigned long freq)
> +int devfreq_update_stats(struct devfreq *devfreq, unsigned long freq)
> {
> int lev, prev_lev, ret = 0;
> unsigned long cur_time;
> @@ -191,7 +191,7 @@ int devfreq_update_status(struct devfreq *devfreq,
> unsigned long freq)
> devfreq->last_stat_updated = cur_time;
> return ret;
> }
> -EXPORT_SYMBOL(devfreq_update_status);
> +EXPORT_SYMBOL(devfreq_update_stats);
>
> /**
> * find_devfreq_governor() - find devfreq governor from name
> @@ -311,7 +311,7 @@ static int devfreq_set_target(struct devfreq *devfreq,
> unsigned long new_freq,
> freqs.new = new_freq;
> devfreq_notify_transition(devfreq, &freqs, DEVFREQ_POSTCHANGE);
>
> - if (devfreq_update_status(devfreq, new_freq))
> + if (devfreq_update_stats(devfreq, new_freq))
> dev_err(&devfreq->dev,
> "Couldn't update frequency transition information.\n");
>
> @@ -450,7 +450,7 @@ void devfreq_monitor_suspend(struct devfreq *devfreq)
> return;
> }
>
> - devfreq_update_status(devfreq, devfreq->previous_freq);
> + devfreq_update_stats(devfreq, devfreq->previous_freq);
> devfreq->stop_polling = true;
> mutex_unlock(&devfreq->lock);
> cancel_delayed_work_sync(&devfreq->work);
> @@ -1398,7 +1398,7 @@ static ssize_t trans_stat_show(struct device *dev,
> unsigned int max_state = devfreq->profile->max_state;
>
> if (!devfreq->stop_polling &&
> - devfreq_update_status(devfreq, devfreq->previous_freq))
> + devfreq_update_stats(devfreq, devfreq->previous_freq))
> return 0;
> if (max_state == 0)
> return sprintf(buf, "Not Supported.\n");
> diff --git a/drivers/devfreq/governor.h b/drivers/devfreq/governor.h
> index bbe5ff9fcecf..e11f447be2b5 100644
> --- a/drivers/devfreq/governor.h
> +++ b/drivers/devfreq/governor.h
> @@ -64,9 +64,9 @@ extern void devfreq_interval_update(struct devfreq *devfreq,
> extern int devfreq_add_governor(struct devfreq_governor *governor);
> extern int devfreq_remove_governor(struct devfreq_governor *governor);
>
> -extern int devfreq_update_status(struct devfreq *devfreq, unsigned long
> freq);
> +extern int devfreq_update_stats(struct devfreq *devfreq, unsigned long freq);
>
> -static inline int devfreq_update_stats(struct devfreq *df)
> +static inline int devfreq_update_status(struct devfreq *df)
> {
> return df->profile->get_dev_status(df->dev.parent, &df->last_status);
> }
> diff --git a/drivers/devfreq/governor_passive.c
> b/drivers/devfreq/governor_passive.c
> index be6eeab9c814..1c746b96d3db 100644
> --- a/drivers/devfreq/governor_passive.c
> +++ b/drivers/devfreq/governor_passive.c
> @@ -110,7 +110,7 @@ static int update_devfreq_passive(struct devfreq
> *devfreq, unsigned long freq)
> goto out;
>
> if (devfreq->profile->freq_table
> - && (devfreq_update_status(devfreq, freq)))
> + && (devfreq_update_stats(devfreq, freq)))
> dev_err(&devfreq->dev,
> "Couldn't update frequency transition information.\n");
>
> diff --git a/drivers/devfreq/governor_simpleondeman
Re: WARN_ON_ONCE in qla2x00_status_cont_entry
On 2019-09-25 05:39, Daniel Wagner wrote: > So I after starring on the code I am not sure if the WARN_ON_ONCE is > correct. It assumes that after processing one status continuation, > there is no more work. Though it looks like there is another element > to process. Is it possible that two sense continuation are possible? According to the firmware documentation it is possible that multiple status continuations are emitted by the firmware. Do you want to submit a patch or do you prefer that I do this myself? Thanks, Bart.
[PATCH V5 1/4] ASoC: fsl_asrc: Use in(out)put_format instead of in(out)put_word_width
snd_pcm_format_t is more formal than enum asrc_word_width, which has
two property, width and physical width, which is more accurate than
enum asrc_word_width. So it is better to use in(out)put_format
instead of in(out)put_word_width.
Signed-off-by: Shengjiu Wang
Acked-by: Nicolin Chen
---
sound/soc/fsl/fsl_asrc.c | 56 +++-
sound/soc/fsl/fsl_asrc.h | 4 +--
2 files changed, 40 insertions(+), 20 deletions(-)
diff --git a/sound/soc/fsl/fsl_asrc.c b/sound/soc/fsl/fsl_asrc.c
index cfa40ef6b1ca..4d3804a1ea55 100644
--- a/sound/soc/fsl/fsl_asrc.c
+++ b/sound/soc/fsl/fsl_asrc.c
@@ -265,6 +265,8 @@ static int fsl_asrc_config_pair(struct fsl_asrc_pair *pair)
struct asrc_config *config = pair->config;
struct fsl_asrc *asrc_priv = pair->asrc_priv;
enum asrc_pair_index index = pair->index;
+ enum asrc_word_width input_word_width;
+ enum asrc_word_width output_word_width;
u32 inrate, outrate, indiv, outdiv;
u32 clk_index[2], div[2];
int in, out, channels;
@@ -283,9 +285,32 @@ static int fsl_asrc_config_pair(struct fsl_asrc_pair *pair)
return -EINVAL;
}
- /* Validate output width */
- if (config->output_word_width == ASRC_WIDTH_8_BIT) {
- pair_err("does not support 8bit width output\n");
+ switch (snd_pcm_format_width(config->input_format)) {
+ case 8:
+ input_word_width = ASRC_WIDTH_8_BIT;
+ break;
+ case 16:
+ input_word_width = ASRC_WIDTH_16_BIT;
+ break;
+ case 24:
+ input_word_width = ASRC_WIDTH_24_BIT;
+ break;
+ default:
+ pair_err("does not support this input format, %d\n",
+config->input_format);
+ return -EINVAL;
+ }
+
+ switch (snd_pcm_format_width(config->output_format)) {
+ case 16:
+ output_word_width = ASRC_WIDTH_16_BIT;
+ break;
+ case 24:
+ output_word_width = ASRC_WIDTH_24_BIT;
+ break;
+ default:
+ pair_err("does not support this output format, %d\n",
+config->output_format);
return -EINVAL;
}
@@ -383,8 +408,8 @@ static int fsl_asrc_config_pair(struct fsl_asrc_pair *pair)
/* Implement word_width configurations */
regmap_update_bits(asrc_priv->regmap, REG_ASRMCR1(index),
ASRMCR1i_OW16_MASK | ASRMCR1i_IWD_MASK,
- ASRMCR1i_OW16(config->output_word_width) |
- ASRMCR1i_IWD(config->input_word_width));
+ ASRMCR1i_OW16(output_word_width) |
+ ASRMCR1i_IWD(input_word_width));
/* Enable BUFFER STALL */
regmap_update_bits(asrc_priv->regmap, REG_ASRMCR(index),
@@ -497,13 +522,13 @@ static int fsl_asrc_dai_hw_params(struct
snd_pcm_substream *substream,
struct snd_soc_dai *dai)
{
struct fsl_asrc *asrc_priv = snd_soc_dai_get_drvdata(dai);
- int width = params_width(params);
struct snd_pcm_runtime *runtime = substream->runtime;
struct fsl_asrc_pair *pair = runtime->private_data;
unsigned int channels = params_channels(params);
unsigned int rate = params_rate(params);
struct asrc_config config;
- int word_width, ret;
+ snd_pcm_format_t format;
+ int ret;
ret = fsl_asrc_request_pair(channels, pair);
if (ret) {
@@ -513,15 +538,10 @@ static int fsl_asrc_dai_hw_params(struct
snd_pcm_substream *substream,
pair->config = &config;
- if (width == 16)
- width = ASRC_WIDTH_16_BIT;
- else
- width = ASRC_WIDTH_24_BIT;
-
if (asrc_priv->asrc_width == 16)
- word_width = ASRC_WIDTH_16_BIT;
+ format = SNDRV_PCM_FORMAT_S16_LE;
else
- word_width = ASRC_WIDTH_24_BIT;
+ format = SNDRV_PCM_FORMAT_S24_LE;
config.pair = pair->index;
config.channel_num = channels;
@@ -529,13 +549,13 @@ static int fsl_asrc_dai_hw_params(struct
snd_pcm_substream *substream,
config.outclk = OUTCLK_ASRCK1_CLK;
if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
- config.input_word_width = width;
- config.output_word_width = word_width;
+ config.input_format = params_format(params);
+ config.output_format = format;
config.input_sample_rate = rate;
config.output_sample_rate = asrc_priv->asrc_rate;
} else {
- config.input_word_width = word_width;
- config.output_word_width = width;
+ config.input_format = format;
+ config.output_format = params_format(params);
config.input_sample_rate
[PATCH V5 3/4] ASoC: pcm_dmaengine: Extract snd_dmaengine_pcm_refine_runtime_hwparams
When set the runtime hardware parameters, we may need to query
the capability of DMA to complete the parameters.
This patch is to Extract this operation from
dmaengine_pcm_set_runtime_hwparams function to a separate function
snd_dmaengine_pcm_refine_runtime_hwparams, that other components
which need this feature can call this function.
Signed-off-by: Shengjiu Wang
Reviewed-by: Nicolin Chen
---
include/sound/dmaengine_pcm.h | 5 ++
sound/core/pcm_dmaengine.c| 83 +++
sound/soc/soc-generic-dmaengine-pcm.c | 61 ++--
3 files changed, 94 insertions(+), 55 deletions(-)
diff --git a/include/sound/dmaengine_pcm.h b/include/sound/dmaengine_pcm.h
index c679f6116580..b65220685920 100644
--- a/include/sound/dmaengine_pcm.h
+++ b/include/sound/dmaengine_pcm.h
@@ -83,6 +83,11 @@ void snd_dmaengine_pcm_set_config_from_dai_data(
const struct snd_dmaengine_dai_dma_data *dma_data,
struct dma_slave_config *config);
+int snd_dmaengine_pcm_refine_runtime_hwparams(
+ struct snd_pcm_substream *substream,
+ struct snd_dmaengine_dai_dma_data *dma_data,
+ struct snd_pcm_hardware *hw,
+ struct dma_chan *chan);
/*
* Try to request the DMA channel using compat_request_channel or
diff --git a/sound/core/pcm_dmaengine.c b/sound/core/pcm_dmaengine.c
index 89a05926ac73..5749a8a49784 100644
--- a/sound/core/pcm_dmaengine.c
+++ b/sound/core/pcm_dmaengine.c
@@ -369,4 +369,87 @@ int snd_dmaengine_pcm_close_release_chan(struct
snd_pcm_substream *substream)
}
EXPORT_SYMBOL_GPL(snd_dmaengine_pcm_close_release_chan);
+/**
+ * snd_dmaengine_pcm_refine_runtime_hwparams - Refine runtime hw params
+ * @substream: PCM substream
+ * @dma_data: DAI DMA data
+ * @hw: PCM hw params
+ * @chan: DMA channel to use for data transfers
+ *
+ * Returns 0 on success, a negative error code otherwise.
+ *
+ * This function will query DMA capability, then refine the pcm hardware
+ * parameters.
+ */
+int snd_dmaengine_pcm_refine_runtime_hwparams(
+ struct snd_pcm_substream *substream,
+ struct snd_dmaengine_dai_dma_data *dma_data,
+ struct snd_pcm_hardware *hw,
+ struct dma_chan *chan)
+{
+ struct dma_slave_caps dma_caps;
+ u32 addr_widths = BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) |
+ BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) |
+ BIT(DMA_SLAVE_BUSWIDTH_4_BYTES);
+ snd_pcm_format_t i;
+ int ret = 0;
+
+ if (!hw || !chan || !dma_data)
+ return -EINVAL;
+
+ ret = dma_get_slave_caps(chan, &dma_caps);
+ if (ret == 0) {
+ if (dma_caps.cmd_pause && dma_caps.cmd_resume)
+ hw->info |= SNDRV_PCM_INFO_PAUSE |
SNDRV_PCM_INFO_RESUME;
+ if (dma_caps.residue_granularity <=
DMA_RESIDUE_GRANULARITY_SEGMENT)
+ hw->info |= SNDRV_PCM_INFO_BATCH;
+
+ if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
+ addr_widths = dma_caps.dst_addr_widths;
+ else
+ addr_widths = dma_caps.src_addr_widths;
+ }
+
+ /*
+* If SND_DMAENGINE_PCM_DAI_FLAG_PACK is set keep
+* hw.formats set to 0, meaning no restrictions are in place.
+* In this case it's the responsibility of the DAI driver to
+* provide the supported format information.
+*/
+ if (!(dma_data->flags & SND_DMAENGINE_PCM_DAI_FLAG_PACK))
+ /*
+* Prepare formats mask for valid/allowed sample types. If the
+* dma does not have support for the given physical word size,
+* it needs to be masked out so user space can not use the
+* format which produces corrupted audio.
+* In case the dma driver does not implement the slave_caps the
+* default assumption is that it supports 1, 2 and 4 bytes
+* widths.
+*/
+ for (i = SNDRV_PCM_FORMAT_FIRST; i <= SNDRV_PCM_FORMAT_LAST;
i++) {
+ int bits = snd_pcm_format_physical_width(i);
+
+ /*
+* Enable only samples with DMA supported physical
+* widths
+*/
+ switch (bits) {
+ case 8:
+ case 16:
+ case 24:
+ case 32:
+ case 64:
+ if (addr_widths & (1 << (bits / 8)))
+ hw->formats |= pcm_format_to_bits(i);
+ break;
+ default:
+ /* Unsupported types */
+ break;
+ }
+ }
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(snd_dmaengine_pcm_refine_runtime_hwparams);
+
MODULE_LICENSE("GPL");
diff
[PATCH V5 4/4] ASoC: fsl_asrc: Fix error with S24_3LE format bitstream in i.MX8
There is error "aplay: pcm_write:2023: write error: Input/output error"
on i.MX8QM/i.MX8QXP platform for S24_3LE format.
In i.MX8QM/i.MX8QXP, the DMA is EDMA, which don't support 24bit
sample, but we didn't add any constraint, that cause issues.
So we need to query the caps of dma, then update the hw parameters
according to the caps.
Signed-off-by: Shengjiu Wang
---
sound/soc/fsl/fsl_asrc.c | 4 +--
sound/soc/fsl/fsl_asrc.h | 3 ++
sound/soc/fsl/fsl_asrc_dma.c | 66 +++-
3 files changed, 63 insertions(+), 10 deletions(-)
diff --git a/sound/soc/fsl/fsl_asrc.c b/sound/soc/fsl/fsl_asrc.c
index 584badf956d2..0bf91a6f54b9 100644
--- a/sound/soc/fsl/fsl_asrc.c
+++ b/sound/soc/fsl/fsl_asrc.c
@@ -115,7 +115,7 @@ static void fsl_asrc_sel_proc(int inrate, int outrate,
* within range [ANCA, ANCA+ANCB-1], depends on the channels of pair A
* while pair A and pair C are comparatively independent.
*/
-static int fsl_asrc_request_pair(int channels, struct fsl_asrc_pair *pair)
+int fsl_asrc_request_pair(int channels, struct fsl_asrc_pair *pair)
{
enum asrc_pair_index index = ASRC_INVALID_PAIR;
struct fsl_asrc *asrc_priv = pair->asrc_priv;
@@ -158,7 +158,7 @@ static int fsl_asrc_request_pair(int channels, struct
fsl_asrc_pair *pair)
*
* It clears the resource from asrc_priv and releases the occupied channels.
*/
-static void fsl_asrc_release_pair(struct fsl_asrc_pair *pair)
+void fsl_asrc_release_pair(struct fsl_asrc_pair *pair)
{
struct fsl_asrc *asrc_priv = pair->asrc_priv;
enum asrc_pair_index index = pair->index;
diff --git a/sound/soc/fsl/fsl_asrc.h b/sound/soc/fsl/fsl_asrc.h
index 38af485bdd22..2b57e8c53728 100644
--- a/sound/soc/fsl/fsl_asrc.h
+++ b/sound/soc/fsl/fsl_asrc.h
@@ -462,4 +462,7 @@ struct fsl_asrc {
#define DRV_NAME "fsl-asrc-dai"
extern struct snd_soc_component_driver fsl_asrc_component;
struct dma_chan *fsl_asrc_get_dma_channel(struct fsl_asrc_pair *pair, bool
dir);
+int fsl_asrc_request_pair(int channels, struct fsl_asrc_pair *pair);
+void fsl_asrc_release_pair(struct fsl_asrc_pair *pair);
+
#endif /* _FSL_ASRC_H */
diff --git a/sound/soc/fsl/fsl_asrc_dma.c b/sound/soc/fsl/fsl_asrc_dma.c
index 01052a0808b0..7712970aeb28 100644
--- a/sound/soc/fsl/fsl_asrc_dma.c
+++ b/sound/soc/fsl/fsl_asrc_dma.c
@@ -16,13 +16,11 @@
#define FSL_ASRC_DMABUF_SIZE (256 * 1024)
-static const struct snd_pcm_hardware snd_imx_hardware = {
+static struct snd_pcm_hardware snd_imx_hardware = {
.info = SNDRV_PCM_INFO_INTERLEAVED |
SNDRV_PCM_INFO_BLOCK_TRANSFER |
SNDRV_PCM_INFO_MMAP |
- SNDRV_PCM_INFO_MMAP_VALID |
- SNDRV_PCM_INFO_PAUSE |
- SNDRV_PCM_INFO_RESUME,
+ SNDRV_PCM_INFO_MMAP_VALID,
.buffer_bytes_max = FSL_ASRC_DMABUF_SIZE,
.period_bytes_min = 128,
.period_bytes_max = 65535, /* Limited by SDMA engine */
@@ -270,12 +268,25 @@ static int fsl_asrc_dma_hw_free(struct snd_pcm_substream
*substream)
static int fsl_asrc_dma_startup(struct snd_pcm_substream *substream)
{
+ bool tx = substream->stream == SNDRV_PCM_STREAM_PLAYBACK;
struct snd_soc_pcm_runtime *rtd = substream->private_data;
struct snd_pcm_runtime *runtime = substream->runtime;
struct snd_soc_component *component = snd_soc_rtdcom_lookup(rtd,
DRV_NAME);
+ struct snd_dmaengine_dai_dma_data *dma_data;
struct device *dev = component->dev;
struct fsl_asrc *asrc_priv = dev_get_drvdata(dev);
struct fsl_asrc_pair *pair;
+ struct dma_chan *tmp_chan = NULL;
+ u8 dir = tx ? OUT : IN;
+ bool release_pair = true;
+ int ret = 0;
+
+ ret = snd_pcm_hw_constraint_integer(substream->runtime,
+ SNDRV_PCM_HW_PARAM_PERIODS);
+ if (ret < 0) {
+ dev_err(dev, "failed to set pcm hw params periods\n");
+ return ret;
+ }
pair = kzalloc(sizeof(struct fsl_asrc_pair), GFP_KERNEL);
if (!pair)
@@ -285,11 +296,50 @@ static int fsl_asrc_dma_startup(struct snd_pcm_substream
*substream)
runtime->private_data = pair;
- snd_pcm_hw_constraint_integer(substream->runtime,
- SNDRV_PCM_HW_PARAM_PERIODS);
- snd_soc_set_runtime_hwparams(substream, &snd_imx_hardware);
+ /* Request a dummy pair, which will be released later.
+* Request pair function needs channel num as input, for this
+* dummy pair, we just request "1" channel temporarily.
+*/
+ ret = fsl_asrc_request_pair(1, pair);
+ if (ret < 0) {
+ dev_err(dev, "failed to request asrc pair\n");
+ goto req_pair_err;
+ }
- return 0;
+ /* Request a dummy dma channel, which will be released later. */
+ tmp_chan = fsl_asrc_get_dma_channel(pair, dir);
+ if (!tmp_chan) {
+ dev_er
[PATCH V5 2/4] ASoC: fsl_asrc: update supported sample format
The ASRC support 24bit/16bit/8bit input width, which is
data width, not slot width.
For the S20_3LE format, the data with is 20bit, slot width
is 24bit, if we set ASRMCR1n.IWD to be 24bits, the result
is the volume is lower than expected, it likes 24bit data
right shift 4 bits
So replace S20_3LE with S24_3LE in supported list and add S8
format in TX supported list
Signed-off-by: Shengjiu Wang
Acked-by: Nicolin Chen
---
sound/soc/fsl/fsl_asrc.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/sound/soc/fsl/fsl_asrc.c b/sound/soc/fsl/fsl_asrc.c
index 4d3804a1ea55..584badf956d2 100644
--- a/sound/soc/fsl/fsl_asrc.c
+++ b/sound/soc/fsl/fsl_asrc.c
@@ -624,7 +624,7 @@ static int fsl_asrc_dai_probe(struct snd_soc_dai *dai)
#define FSL_ASRC_FORMATS (SNDRV_PCM_FMTBIT_S24_LE | \
SNDRV_PCM_FMTBIT_S16_LE | \
-SNDRV_PCM_FMTBIT_S20_3LE)
+SNDRV_PCM_FMTBIT_S24_3LE)
static struct snd_soc_dai_driver fsl_asrc_dai = {
.probe = fsl_asrc_dai_probe,
@@ -635,7 +635,8 @@ static struct snd_soc_dai_driver fsl_asrc_dai = {
.rate_min = 5512,
.rate_max = 192000,
.rates = SNDRV_PCM_RATE_KNOT,
- .formats = FSL_ASRC_FORMATS,
+ .formats = FSL_ASRC_FORMATS |
+ SNDRV_PCM_FMTBIT_S8,
},
.capture = {
.stream_name = "ASRC-Capture",
--
2.21.0
[PATCH V5 0/4] update supported sample format
This patch serial is to update the supported format for fsl_asrc and fix some format issue. Shengjiu Wang (4): ASoC: fsl_asrc: Use in(out)put_format instead of in(out)put_word_width ASoC: fsl_asrc: update supported sample format ASoC: pcm_dmaengine: Extract snd_dmaengine_pcm_refine_runtime_hwparams ASoC: fsl_asrc: Fix error with S24_3LE format bitstream in i.MX8 changes in v2 - extract snd_dmaengine_pcm_set_runtime_hwparams in one separate path. - 4th patch depends on 3rd patch changes in v3 - Fix build report by kbuild test robot - change snd_dmaengine_pcm_set_runtime_hwparams to snd_dmaengine_pcm_refine_runtime_hwparams changes in v4 - update according to Nicolin's comments. changes in v5 - free asrc pair when error happens include/sound/dmaengine_pcm.h | 5 ++ sound/core/pcm_dmaengine.c| 83 +++ sound/soc/fsl/fsl_asrc.c | 65 ++--- sound/soc/fsl/fsl_asrc.h | 7 ++- sound/soc/fsl/fsl_asrc_dma.c | 66 ++--- sound/soc/soc-generic-dmaengine-pcm.c | 61 ++-- 6 files changed, 200 insertions(+), 87 deletions(-) -- 2.21.0
Re: [PATCH 07/32] x86: Use pr_warn instead of pr_warning
On 2019/9/20 23:28, Joe Perches wrote:
> On Fri, 2019-09-20 at 19:57 +0800, Kefeng Wang wrote:
>> On 2019/9/20 17:28, Robert Richter wrote:
>>> On 20.09.19 14:25:19, Kefeng Wang wrote:
As said in commit f2c2cbcc35d4 ("powerpc: Use pr_warn instead of
pr_warning"), removing pr_warning so all logging messages use a
consistent _warn style. Let's do it.
> []
diff --git a/arch/x86/kernel/amd_gart_64.c b/arch/x86/kernel/amd_gart_64.c
> []
@@ -665,7 +664,7 @@ static __init int init_amd_gatt(struct agp_kern_info
*info)
nommu:
/* Should not happen anymore */
- pr_warning("PCI-DMA: More than 4GB of RAM and no IOMMU\n"
+ pr_warn("PCI-DMA: More than 4GB of RAM and no IOMMU\n"
"falling back to iommu=soft.\n");
>>> This indentation should be fixed too, while at it.
>> Will update later, thanks.
> trivia:
>
> likely better as a single line output:
>
> pr_warn("PCI-DMA: More than 4GB of RAM and no IOMMU - falling back to
> iommu=soft\n");
ok, will resend all patches after rc1 with this change and other comment fixes,
thanks.
>
>
>
> .
>
Re: [PATCH] net: flow_offload: fix memory leak in nfp_abm_u32_knode_replace
On Wed, 25 Sep 2019 13:34:46 -0500, Navid Emamdoost wrote:
> In nfp_abm_u32_knode_replace if the allocation for match fails it should
> go to the error handling instead of returning.
>
> Signed-off-by: Navid Emamdoost
> ---
> drivers/net/ethernet/netronome/nfp/abm/cls.c | 11 +++
> 1 file changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/ethernet/netronome/nfp/abm/cls.c
> b/drivers/net/ethernet/netronome/nfp/abm/cls.c
> index 23ebddfb9532..32eaab99d96c 100644
> --- a/drivers/net/ethernet/netronome/nfp/abm/cls.c
> +++ b/drivers/net/ethernet/netronome/nfp/abm/cls.c
> @@ -174,7 +174,7 @@ nfp_abm_u32_knode_replace(struct nfp_abm_link *alink,
> struct nfp_abm_u32_match *match = NULL, *iter;
> unsigned int tos_off;
> u8 mask, val;
> - int err;
> + int err, ret = -EOPNOTSUPP;
You can use the err variable for the return. Please don't break the
reverse christmas tree ordering. Please initialize the err variable
in the branch where failure occurred, not at the start of the function.
> if (!nfp_abm_u32_check_knode(alink->abm, knode, proto, extack))
> goto err_delete;
> @@ -204,8 +204,11 @@ nfp_abm_u32_knode_replace(struct nfp_abm_link *alink,
>
> if (!match) {
> match = kzalloc(sizeof(*match), GFP_KERNEL);
> - if (!match)
> - return -ENOMEM;
> + if (!match) {
> + ret = -ENOMEM;
> + goto err_delete;
> + }
> +
> list_add(&match->list, &alink->dscp_map);
> }
> match->handle = knode->handle;
> @@ -221,7 +224,7 @@ nfp_abm_u32_knode_replace(struct nfp_abm_link *alink,
>
> err_delete:
> nfp_abm_u32_knode_delete(alink, knode);
> - return -EOPNOTSUPP;
> + return ret;
> }
>
> static int nfp_abm_setup_tc_block_cb(enum tc_setup_type type,
Re: [PATCH v2 3/3] platform/x86: intel_oaktrail: Use pr_warn instead of pr_warning
On 2019/9/25 23:04, Andy Shevchenko wrote:
> On Fri, Sep 20, 2019 at 1:55 PM Kefeng Wang
> wrote:
>> As said in commit f2c2cbcc35d4 ("powerpc: Use pr_warn instead of
>> pr_warning"), removing pr_warning so all logging messages use a
>> consistent _warn style. Let's do it.
>>
> You have to send to proper mailing lists and people.
Used get_maintainer.pl to find the people, and all already in the CC, will add
proper maillist into each patch.
> Don't spam the rest!
Not so clearly, should I not CC other people not in the list below?
[wkf@localhost linux]$ ./scripts/get_maintainer.pl
pr_warning/v3/0018-platform-x86-eeepc-laptop-Use-pr_warn-instead-of-pr_.patch
Corentin Chary (maintainer:ASUS NOTEBOOKS AND EEEPC
ACPI/WMI EXTRAS DRIVERS)
Darren Hart (odd fixer:X86 PLATFORM DRIVERS)
Andy Shevchenko (odd fixer:X86 PLATFORM DRIVERS)
acpi4asus-u...@lists.sourceforge.net (open list:ASUS NOTEBOOKS AND EEEPC
ACPI/WMI EXTRAS DRIVERS)
platform-driver-...@vger.kernel.org (open list:ASUS NOTEBOOKS AND EEEPC
ACPI/WMI EXTRAS DRIVERS)
linux-kernel@vger.kernel.org (open list)
[wkf@localhost linux]$ ./scripts/get_maintainer.pl
pr_warning/v3/0019-platform-x86-asus-laptop-Use-pr_warn-instead-of-pr_w.patch
Corentin Chary (maintainer:ASUS NOTEBOOKS AND EEEPC
ACPI/WMI EXTRAS DRIVERS)
Darren Hart (odd fixer:X86 PLATFORM DRIVERS)
Andy Shevchenko (odd fixer:X86 PLATFORM DRIVERS)
acpi4asus-u...@lists.sourceforge.net (open list:ASUS NOTEBOOKS AND EEEPC
ACPI/WMI EXTRAS DRIVERS)
platform-driver-...@vger.kernel.org (open list:ASUS NOTEBOOKS AND EEEPC
ACPI/WMI EXTRAS DRIVERS)
linux-kernel@vger.kernel.org (open list)
[wkf@localhost linux]$ ./scripts/get_maintainer.pl
pr_warning/v3/0020-platform-x86-intel_oaktrail-Use-pr_warn-instead-of-p.patch
Darren Hart (odd fixer:X86 PLATFORM DRIVERS)
Andy Shevchenko (odd fixer:X86 PLATFORM
DRIVERS,commit_signer:2/2=100%,authored:2/2=100%,added_lines:9/9=100%,removed_lines:23/23=100%)
platform-driver-...@vger.kernel.org (open list:X86 PLATFORM DRIVERS)
linux-kernel@vger.kernel.org (open list)
>> Cc: Corentin Chary
>> Cc: Darren Hart
>> Cc: Andy Shevchenko
>> Cc: Andy Shevchenko
>> Signed-off-by: Kefeng Wang
>> ---
>> drivers/platform/x86/intel_oaktrail.c | 10 +-
>> 1 file changed, 5 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/platform/x86/intel_oaktrail.c
>> b/drivers/platform/x86/intel_oaktrail.c
>> index 3c0438ba385e..1a09a75bd16d 100644
>> --- a/drivers/platform/x86/intel_oaktrail.c
>> +++ b/drivers/platform/x86/intel_oaktrail.c
>> @@ -243,7 +243,7 @@ static int oaktrail_backlight_init(void)
>>
>> if (IS_ERR(bd)) {
>> oaktrail_bl_device = NULL;
>> - pr_warning("Unable to register backlight device\n");
>> + pr_warn("Unable to register backlight device\n");
>> return PTR_ERR(bd);
>> }
>>
>> @@ -313,20 +313,20 @@ static int __init oaktrail_init(void)
>>
>> ret = platform_driver_register(&oaktrail_driver);
>> if (ret) {
>> - pr_warning("Unable to register platform driver\n");
>> + pr_warn("Unable to register platform driver\n");
>> goto err_driver_reg;
>> }
>>
>> oaktrail_device = platform_device_alloc(DRIVER_NAME, -1);
>> if (!oaktrail_device) {
>> - pr_warning("Unable to allocate platform device\n");
>> + pr_warn("Unable to allocate platform device\n");
>> ret = -ENOMEM;
>> goto err_device_alloc;
>> }
>>
>> ret = platform_device_add(oaktrail_device);
>> if (ret) {
>> - pr_warning("Unable to add platform device\n");
>> + pr_warn("Unable to add platform device\n");
>> goto err_device_add;
>> }
>>
>> @@ -338,7 +338,7 @@ static int __init oaktrail_init(void)
>>
>> ret = oaktrail_rfkill_init();
>> if (ret) {
>> - pr_warning("Setup rfkill failed\n");
>> + pr_warn("Setup rfkill failed\n");
>> goto err_rfkill;
>> }
>>
>> --
>> 2.20.1
>>
>
[PATCH v2] scripts: Move ipc/ to kernel/ipc/: don't check the ipc dir
After the commit 76128326f97c ("toplevel: Move ipc/ to kernel/ipc/: move
the files"), we met some error messages:
./scripts/checkpatch.pl:
"Must be run from the top-level dir. of a kernel tree"
./scripts/get_maintainer.pl:
"The current directory does not appear to be a linux kernel source tree.
Don't check the ipc dir in checkpatch.pl and get_maintainer.pl.
Signed-off-by: Yunfeng Ye
---
v1 -> v2:
- update the subject "scripts:" instead of "toplevel:"
scripts/checkpatch.pl | 2 +-
scripts/get_maintainer.pl | 1 -
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 93a7edf..6117d0e 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -1097,7 +1097,7 @@ sub top_of_kernel_tree {
my @tree_check = (
"COPYING", "CREDITS", "Kbuild", "MAINTAINERS", "Makefile",
"README", "Documentation", "arch", "include", "drivers",
- "fs", "init", "ipc", "kernel", "lib", "scripts",
+ "fs", "init", "kernel", "lib", "scripts",
);
foreach my $check (@tree_check) {
diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
index 5ef5921..2e42aeb 100755
--- a/scripts/get_maintainer.pl
+++ b/scripts/get_maintainer.pl
@@ -1109,7 +1109,6 @@ sub top_of_kernel_tree {
&& (-d "${lk_path}drivers")
&& (-d "${lk_path}fs")
&& (-d "${lk_path}init")
- && (-d "${lk_path}ipc")
&& (-d "${lk_path}kernel")
&& (-d "${lk_path}lib")
&& (-d "${lk_path}scripts")) {
--
2.7.4
Re: [PATCH] nfp: flower: prevent memory leak in nfp_flower_spawn_phy_reprs
On Wed, 25 Sep 2019 13:24:02 -0500, Navid Emamdoost wrote:
> In nfp_flower_spawn_phy_reprs, in the for loop over eth_tbl if any of
> intermediate allocations or initializations fail memory is leaked.
> requiered releases are added.
>
> Signed-off-by: Navid Emamdoost
Fixes: b94524529741 ("nfp: flower: add per repr private data for LAG offload")
Acked-by: Jakub Kicinski
Re: [PATCH] nfp: flower: fix memory leak in nfp_flower_spawn_vnic_reprs
On Wed, 25 Sep 2019 14:05:09 -0500, Navid Emamdoost wrote:
> In nfp_flower_spawn_vnic_reprs in the loop if initialization or the
> allocations fail memory is leaked. Appropriate releases are added.
>
> Signed-off-by: Navid Emamdoost
Fixes: b94524529741 ("nfp: flower: add per repr private data for LAG offload")
Acked-by: Jakub Kicinski
Re: [PATCH] toplevel: Move ipc/ to kernel/ipc/: don't check the ipc dir
On 2019/9/26 0:32, Joe Perches wrote:
> On Wed, 2019-09-25 at 20:37 +0800, Yunfeng Ye wrote:
>> After the commit 76128326f97c ("toplevel: Move ipc/ to kernel/ipc/: move
>> the files"), we met some error messages:
>>
>> ./scripts/checkpatch.pl:
>> "Must be run from the top-level dir. of a kernel tree"
>>
>> ./scripts/get_maintainer.pl:
>> "The current directory does not appear to be a linux kernel source tree.
>>
>> Don't check the ipc dir in checkpatch.pl and get_maintainer.pl.
>
> Thanks.
>
> Maybe the commit subject could use "scripts:"
> or something similar and not "toplevel:".
>The purpose of subject "toplevel" is to maintain consistency with previous
modification patches. ok, I will modify it, thanks.
> Trivially, it one day it'd be good to use the
> same routine and output message too.
>
>> Signed-off-by: Yunfeng Ye
>> ---
>> scripts/checkpatch.pl | 2 +-
>> scripts/get_maintainer.pl | 1 -
>> 2 files changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
>> index 93a7edf..6117d0e 100755
>> --- a/scripts/checkpatch.pl
>> +++ b/scripts/checkpatch.pl
>> @@ -1097,7 +1097,7 @@ sub top_of_kernel_tree {
>> my @tree_check = (
>> "COPYING", "CREDITS", "Kbuild", "MAINTAINERS", "Makefile",
>> "README", "Documentation", "arch", "include", "drivers",
>> -"fs", "init", "ipc", "kernel", "lib", "scripts",
>> +"fs", "init", "kernel", "lib", "scripts",
>> );
>>
>> foreach my $check (@tree_check) {
>> diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
>> index 5ef5921..2e42aeb 100755
>> --- a/scripts/get_maintainer.pl
>> +++ b/scripts/get_maintainer.pl
>> @@ -1109,7 +1109,6 @@ sub top_of_kernel_tree {
>> && (-d "${lk_path}drivers")
>> && (-d "${lk_path}fs")
>> && (-d "${lk_path}init")
>> -&& (-d "${lk_path}ipc")
>> && (-d "${lk_path}kernel")
>> && (-d "${lk_path}lib")
>> && (-d "${lk_path}scripts")) {
>
>
> .
>
[PATCH] serial: move Non-standard serial drivers menu to the Serial drivers menu
From: Randy Dunlap Since Non-standard serial port drivers are also Serial drivers, move the "Non-standard serial port support" menu to be under/in the "Serial drivers" menu. With this move, the "Serial drivers" menu contains (a) 8250/16550 support, (b) non-8250 support, and (c) non-standard serial port support. Signed-off-by: Randy Dunlap --- drivers/tty/Kconfig| 119 --- drivers/tty/serial/Kconfig | 119 +++ 2 files changed, 119 insertions(+), 119 deletions(-) --- lnx-53.orig/drivers/tty/Kconfig +++ lnx-53/drivers/tty/Kconfig @@ -151,125 +151,6 @@ config LEGACY_PTY_COUNT When not in use, each legacy PTY occupies 12 bytes on 32-bit architectures and 24 bytes on 64-bit architectures. -config SERIAL_NONSTANDARD - bool "Non-standard serial port support" - depends on HAS_IOMEM - ---help--- - Say Y here if you have any non-standard serial boards -- boards - which aren't supported using the standard "dumb" serial driver. - This includes intelligent serial boards such as Cyclades, - Digiboards, etc. These are usually used for systems that need many - serial ports because they serve many terminals or dial-in - connections. - - Note that the answer to this question won't directly affect the - kernel: saying N will just cause the configurator to skip all - the questions about non-standard serial boards. - - Most people can say N here. - -config ROCKETPORT - tristate "Comtrol RocketPort support" - depends on SERIAL_NONSTANDARD && (ISA || EISA || PCI) - help - This driver supports Comtrol RocketPort and RocketModem PCI boards. - These boards provide 2, 4, 8, 16, or 32 high-speed serial ports or - modems. For information about the RocketPort/RocketModem boards - and this driver read . - - To compile this driver as a module, choose M here: the - module will be called rocket. - - If you want to compile this driver into the kernel, say Y here. If - you don't have a Comtrol RocketPort/RocketModem card installed, say N. - -config CYCLADES - tristate "Cyclades async mux support" - depends on SERIAL_NONSTANDARD && (PCI || ISA) - select FW_LOADER - ---help--- - This driver supports Cyclades Z and Y multiserial boards. - You would need something like this to connect more than two modems to - your Linux box, for instance in order to become a dial-in server. - - For information about the Cyclades-Z card, read - . - - To compile this driver as a module, choose M here: the - module will be called cyclades. - - If you haven't heard about it, it's safe to say N. - -config CYZ_INTR - bool "Cyclades-Z interrupt mode operation" - depends on CYCLADES && PCI - help - The Cyclades-Z family of multiport cards allows 2 (two) driver op - modes: polling and interrupt. In polling mode, the driver will check - the status of the Cyclades-Z ports every certain amount of time - (which is called polling cycle and is configurable). In interrupt - mode, it will use an interrupt line (IRQ) in order to check the - status of the Cyclades-Z ports. The default op mode is polling. If - unsure, say N. - -config MOXA_INTELLIO - tristate "Moxa Intellio support" - depends on SERIAL_NONSTANDARD && (ISA || EISA || PCI) - select FW_LOADER - help - Say Y here if you have a Moxa Intellio multiport serial card. - - To compile this driver as a module, choose M here: the - module will be called moxa. - -config MOXA_SMARTIO - tristate "Moxa SmartIO support v. 2.0" - depends on SERIAL_NONSTANDARD && (PCI || EISA || ISA) - help - Say Y here if you have a Moxa SmartIO multiport serial card and/or - want to help develop a new version of this driver. - - This is upgraded (1.9.1) driver from original Moxa drivers with - changes finally resulting in PCI probing. - - This driver can also be built as a module. The module will be called - mxser. If you want to do that, say M here. - -config SYNCLINK - tristate "Microgate SyncLink card support" - depends on SERIAL_NONSTANDARD && PCI && ISA_DMA_API - help - Provides support for the SyncLink ISA and PCI multiprotocol serial - adapters. These adapters support asynchronous and HDLC bit - synchronous communication up to 10Mbps (PCI adapter). - - This driver can only be built as a module ( = code which can be - inserted in and removed from the running kernel whenever you want). - The module will be called synclink. If you want to do that, say M - here. - -config SYNCLINKMP - tristate "SyncLink Mult
Business Proposal
-- Hello, I have sent mail to you previously ,maybe it didn't delivered. I am Naomi Hayashi By name. I am sorry for contacting you directly to your email. I will like to talk to you about something very important. Please acknowledge my email so I can provide you with details.await your response.Best Regards,Naomi Hayashi
Re: [PATCH v2 0/4] task: Making tasks on the runqueue rcu protected
Peter Zijlstra writes: > On Tue, Sep 17, 2019 at 12:38:04PM -0500, Eric W. Biederman wrote: >> Linus Torvalds writes: > >> > Can anybody see anything wrong with the series? Because I'd love to >> > have it for 5.4, >> >> Peter, >> >> I am more than happy for these to come through your tree. However >> if this is one thing to many I will be happy to send Linus a pull >> request myself early next week. > > Yeah, sorry for being late, I fell ill after LPC and am only now > getting back to things. > > I see nothing wrong with these patches; if they've not been picked up > (and I'm not seeing them in Linus' tree yet) I'll pick them up now and > munge them together with Mathieu's membarrier patches and get them to > Linus in a few days. Sounds good. I had some distractions so I wasn't able to get this yet. So I am more than happy for you to pick these up. This is better coming through your tree in any event. Eric
mmotm 2019-09-25-18-10 uploaded
The mm-of-the-moment snapshot 2019-09-25-18-10 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. You will need quilt to apply these patches to the latest Linus release (5.x or 5.x-rcY). The series file is in broken-out.tar.gz and is duplicated in http://ozlabs.org/~akpm/mmotm/series The file broken-out.tar.gz contains two datestamp files: .DATE and .DATE--mm-dd-hh-mm-ss. Both contain the string -mm-dd-hh-mm-ss, followed by the base kernel version against which this patch series is to be applied. This tree is partially included in linux-next. To see which patches are included in linux-next, consult the `series' file. Only the patches within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in linux-next. A full copy of the full kernel tree with the linux-next and mmotm patches already applied is available through git within an hour of the mmotm release. Individual mmotm releases are tagged. The master branch always points to the latest release, so it's constantly rebasing. http://git.cmpxchg.org/cgit.cgi/linux-mmotm.git/ The directory http://www.ozlabs.org/~akpm/mmots/ (mm-of-the-second) contains daily snapshots of the -mm tree. It is updated more frequently than mmotm, and is untested. A git copy of this tree is available at http://git.cmpxchg.org/cgit.cgi/linux-mmots.git/ and use of this tree is similar to http://git.cmpxchg.org/cgit.cgi/linux-mmotm.git/, described above. This mmotm tree contains the following patches against 5.3: (patches marked "*" will be included in linux-next) origin.patch * memcg-kmem-do-not-fail-__gfp_nofail-charges.patch * linux-coffh-add-include-guard.patch * include-proper-prototypes-for-kernel-elfcorec.patch * rbtree-sync-up-the-tools-copy-of-the-code-with-the-main-one.patch * augmented-rbtree-add-comments-for-rb_declare_callbacks-macro.patch * augmented-rbtree-add-new-rb_declare_callbacks_max-macro.patch * augmented-rbtree-rework-the-rb_declare_callbacks-macro-definition.patch * kernel-doc-core-api-include-stringh-into-core-api.patch * writeback-fix-wstringop-truncation-warnings.patch * strscpy-reject-buffer-sizes-larger-than-int_max.patch * lib-generic-radix-treec-make-2-functions-static-inline.patch * lib-extablec-add-missing-prototypes.patch * lib-hexdump-make-print_hex_dump_bytes-a-nop-on-debug-builds.patch * checkpatch-dont-interpret-stack-dumps-as-commit-ids.patch * checkpatch-improve-spdx-license-checking.patch * checkpatchpl-warn-on-invalid-commit-id.patch * checkpatch-exclude-sizeof-sub-expressions-from-macro_arg_reuse.patch * checkpatch-prefer-__section-over-__attribute__section.patch * checkpatch-allow-consecutive-close-braces.patch * checkpatch-remove-obsolete-period-from-ambiguous-sha1-query.patch * checkpatch-make-git-output-use-language=en_usutf8.patch * fs-reiserfs-remove-unnecessary-check-of-bh-in-remove_from_transaction.patch * fs-reiserfs-journalc-remove-set-but-not-used-variables.patch * fs-reiserfs-streec-remove-set-but-not-used-variables.patch * fs-reiserfs-lbalancec-remove-set-but-not-used-variables.patch * fs-reiserfs-objectidc-remove-set-but-not-used-variables.patch * fs-reiserfs-printsc-remove-set-but-not-used-variables.patch * fs-reiserfs-fix_nodec-remove-set-but-not-used-variables.patch * fs-reiserfs-do_balanc-remove-set-but-not-used-variables.patch * reiserfs-remove-set-but-not-used-variable-in-journalc.patch * reiserfs-remove-set-but-not-used-variable-in-do_balanc.patch * fat-delete-an-unnecessary-check-before-brelse.patch * fork-improve-error-message-for-corrupted-page-tables.patch * cpumask-nicer-for_each_cpumask_and-signature.patch * kexec-bail-out-upon-sigkill-when-allocating-memory.patch * kexec-restore-arch_kexec_kernel_image_probe-declaration.patch * uaccess-add-missing-__must_check-attributes.patch * compiler-enable-config_optimize_inlining-forcibly.patch * kgdb-dont-use-a-notifier-to-enter-kgdb-at-panic-call-directly.patch * scripts-gdb-handle-split-debug.patch * bug-refactor-away-warn_slowpath_fmt_taint.patch * bug-rename-__warn_printf_taint-to-__warn_printf.patch * bug-consolidate-warn_slowpath_fmt-usage.patch * bug-lift-cut-here-out-of-__warn.patch * bug-clean-up-helper-macros-to-remove-__warn_taint.patch * bug-consolidate-__warn_flags-usage.patch * bug-move-warn_on-cut-here-into-exception-handler.patch * ipc-mqueuec-delete-an-unnecessary-check-before-the-macro-call-dev_kfree_skb.patch * ipc-mqueue-improve-exception-handling-in-do_mq_notify.patch * ipc-sem-convert-to-use-built-in-rcu-list-checking.patch * lib-lzo-fix-alignment-bug-in-lzo-rle.patch * lib-untag-user-pointers-in-strn_user.patch * mm-untag-user-pointers-passed-to-memory-syscalls.patch * mm-untag-user-pointers-in-mm-gupc.patch * mm-untag-user-pointers-in-get_vaddr_frames.patch * fs-namespace-untag-user-pointers-in-copy_mount_opti
