Re: [PATCH 01/32] staging: gasket: remove X86 Kconfig restriction
Hi Todd,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on staging/staging-testing]
[also build test ERROR on next-20180718]
[cannot apply to v4.18-rc5]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Todd-Poynor/staging-gasket-sundry-fixes-and-fixups/20180717-101844
config: arm-allyesconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.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.2.0 make.cross ARCH=arm
All errors (new ones prefixed by >>):
In file included from drivers/staging/gasket/gasket_core.c:9:0:
drivers/staging/gasket/gasket_core.h: In function 'gasket_dev_read_64':
>> drivers/staging/gasket/gasket_core.h:651:9: error: implicit declaration of
>> function 'readq'; did you mean 'readb'?
>> [-Werror=implicit-function-declaration]
return readq(_dev->bar_data[bar].virt_base[location]);
^
readb
drivers/staging/gasket/gasket_core.h: In function 'gasket_dev_write_64':
>> drivers/staging/gasket/gasket_core.h:657:2: error: implicit declaration of
>> function 'writeq'; did you mean 'writeb'?
>> [-Werror=implicit-function-declaration]
writeq(value, >bar_data[bar].virt_base[location]);
^~
writeb
cc1: some warnings being treated as errors
--
In file included from drivers/staging/gasket/gasket_ioctl.h:6:0,
from drivers/staging/gasket/gasket_ioctl.c:4:
drivers/staging/gasket/gasket_core.h: In function 'gasket_dev_read_64':
>> drivers/staging/gasket/gasket_core.h:651:9: error: implicit declaration of
>> function 'readq'; did you mean 'readb'?
>> [-Werror=implicit-function-declaration]
return readq(_dev->bar_data[bar].virt_base[location]);
^
readb
drivers/staging/gasket/gasket_core.h: In function 'gasket_dev_write_64':
>> drivers/staging/gasket/gasket_core.h:657:2: error: implicit declaration of
>> function 'writeq'; did you mean 'writeb'?
>> [-Werror=implicit-function-declaration]
writeq(value, >bar_data[bar].virt_base[location]);
^~
writeb
drivers/staging/gasket/gasket_ioctl.c: In function
'gasket_config_coherent_allocator':
drivers/staging/gasket/gasket_ioctl.c:434:27: error: passing argument 3 of
'gasket_alloc_coherent_memory' from incompatible pointer type
[-Werror=incompatible-pointer-types]
gasket_dev, ibuf.size, _address,
^
In file included from drivers/staging/gasket/gasket_ioctl.c:9:0:
drivers/staging/gasket/gasket_page_table.h:226:5: note: expected 'dma_addr_t
* {aka unsigned int *}' but argument is of type 'u64 * {aka long long unsigned
int *}'
int gasket_alloc_coherent_memory(struct gasket_dev *gasket_dev, uint64_t
size,
^~~~
cc1: some warnings being treated as errors
--
In file included from drivers/staging/gasket/gasket_page_table.h:19:0,
from drivers/staging/gasket/gasket_page_table.c:34:
drivers/staging/gasket/gasket_core.h: In function 'gasket_dev_read_64':
>> drivers/staging/gasket/gasket_core.h:651:9: error: implicit declaration of
>> function 'readq'; did you mean 'readb'?
>> [-Werror=implicit-function-declaration]
return readq(_dev->bar_data[bar].virt_base[location]);
^
readb
drivers/staging/gasket/gasket_core.h: In function 'gasket_dev_write_64':
>> drivers/staging/gasket/gasket_core.h:657:2: error: implicit declaration of
>> function 'writeq'; did you mean 'writeb'?
>> [-Werror=implicit-function-declaration]
writeq(value, >bar_data[bar].virt_base[location]);
^~
writeb
drivers/staging/gasket/gasket_page_table.c: In function
'gasket_is_extended_dev_addr_bad':
drivers/staging/gasket/gasket_page_table.c:1373:11: warning: right shift
count >= width of type [-Wshift-count-overflow]
if (addr >> (GASKET_EXTENDED_LVL0_WIDTH + GASKET_EXTENDED_LVL0_SHIFT)) {
^~
drivers/staging/gasket/gasket_page_table.c: In function
'gasket_alloc_coherent_memory':
drivers/staging/gasket/gasket_page_table.c:1679:4: warning: cast from
pointer to integer of different size [-Wpointer-to-int-cast]
(u64)mem + j * PAGE_SIZE;
^
cc1: some warnings being treated as errors
vim +651 drivers/staging/gasket/gasket_core.h
9a69f508 Simon Que 2018-06-29 620
9a69f508 Simon Que 2018-06-29 621 /*
9a69f508 Simon Que 2018-06-29 622 * Memory management functions. These will
likely be spun off into their own
9a69f508 Simon Que 2018-06-29 623 * file in the fut
Re: [PATCH resend] staging: gasket: remove X86 Kconfig restriction
On Wed, Jul 18, 2018 at 6:18 PM, kbuild test robot wrote:
> Hi Todd,
>
> Thank you for the patch! Yet something to improve:
>
> [auto build test ERROR on staging/staging-testing]
> [also build test ERROR on next-20180718]
> [cannot apply to v4.18-rc5]
> [if your patch is applied to the wrong git tree, please drop us a note to
> help improve the system]
>
> url:
> https://github.com/0day-ci/linux/commits/Todd-Poynor/staging-gasket-remove-X86-Kconfig-restriction/20180716-031056
> config: xtensa-allmodconfig (attached as .config)
> compiler: xtensa-linux-gcc (GCC) 8.1.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=8.1.0 make.cross ARCH=xtensa
>
> All errors (new ones prefixed by >>):
>
>In file included from drivers/staging/gasket/gasket_page_table.h:19,
> from drivers/staging/gasket/gasket_page_table.c:34:
>drivers/staging/gasket/gasket_core.h: In function 'gasket_dev_read_64':
>>> drivers/staging/gasket/gasket_core.h:651:9: error: implicit declaration of
>>> function 'readq'; did you mean 'readl'?
>>> [-Werror=implicit-function-declaration]
Will respin this patch to explicitly list X86_64 and ARM64 as the only
architectures to build for now, and fixup some of these other issues
soon.
> return readq(_dev->bar_data[bar].virt_base[location]);
> ^
> readl
>drivers/staging/gasket/gasket_core.h: In function 'gasket_dev_write_64':
>>> drivers/staging/gasket/gasket_core.h:657:2: error: implicit declaration of
>>> function 'writeq'; did you mean 'writel'?
>>> [-Werror=implicit-function-declaration]
> writeq(value, >bar_data[bar].virt_base[location]);
> ^~
> writel
>drivers/staging/gasket/gasket_page_table.c: In function
> 'gasket_is_extended_dev_addr_bad':
>drivers/staging/gasket/gasket_page_table.c:1373:11: warning: right shift
> count >= width of type [-Wshift-count-overflow]
> if (addr >> (GASKET_EXTENDED_LVL0_WIDTH + GASKET_EXTENDED_LVL0_SHIFT)) {
> ^~
>drivers/staging/gasket/gasket_page_table.c: In function
> 'gasket_alloc_coherent_memory':
>drivers/staging/gasket/gasket_page_table.c:1679:4: warning: cast from
> pointer to integer of different size [-Wpointer-to-int-cast]
>(u64)mem + j * PAGE_SIZE;
>^
>cc1: some warnings being treated as errors
> --
>In file included from drivers/staging/gasket/gasket_sysfs.h:21,
> from drivers/staging/gasket/gasket_sysfs.c:3:
>drivers/staging/gasket/gasket_core.h: In function 'gasket_dev_read_64':
>>> drivers/staging/gasket/gasket_core.h:651:9: error: implicit declaration of
>>> function 'readq'; did you mean 'readl'?
>>> [-Werror=implicit-function-declaration]
> return readq(_dev->bar_data[bar].virt_base[location]);
> ^
> readl
>drivers/staging/gasket/gasket_core.h: In function 'gasket_dev_write_64':
>>> drivers/staging/gasket/gasket_core.h:657:2: error: implicit declaration of
>>> function 'writeq'; did you mean 'writel'?
>>> [-Werror=implicit-function-declaration]
> writeq(value, >bar_data[bar].virt_base[location]);
> ^~
> writel
>cc1: some warnings being treated as errors
> --
>In file included from drivers/staging/gasket/gasket_ioctl.h:6,
> from drivers/staging/gasket/gasket_ioctl.c:4:
>drivers/staging/gasket/gasket_core.h: In function 'gasket_dev_read_64':
>>> drivers/staging/gasket/gasket_core.h:651:9: error: implicit declaration of
>>> function 'readq'; did you mean 'readl'?
>>> [-Werror=implicit-function-declaration]
> return readq(_dev->bar_data[bar].virt_base[location]);
> ^
> readl
>drivers/staging/gasket/gasket_core.h: In function 'gasket_dev_write_64':
>>> drivers/staging/gasket/gasket_core.h:657:2: error: implicit declaration of
>>> function 'writeq'; did you mean 'writel'?
>>> [-Werror=implicit-function-declaration]
> writeq(value, >bar_data[bar].virt_base[location]);
> ^~
> writel
>drivers/staging/gasket/gasket_ioctl.c: In function
> 'gasket_config_coherent_allocator':
>>> drivers/staging/gasket/gasket_ioctl.c:434:27: error: passing argument 3 of
>>> 'gasket_alloc_coherent_memory' from incompatible pointer type
>>> [-Werror=incompatible-pointer-types]
>gasket_dev, ibuf.size, _address,
[RFC PATCH v3] Xilinx AXI-Stream FIFO v4.1 IP core driver
I hope I did the Makefile/Kconfig corretly :) Thanks for all the feedback. Cheers, Jacob This IP core has read and write AXI-Stream FIFOs, the contents of which can be accessed from the AXI4 memory-mapped interface. This is useful for transferring data from a processor into the FPGA fabric. The driver creates a character device that can be read/written to with standard open/read/write/close. See Xilinx PG080 document for IP details. https://www.xilinx.com/support/documentation/ip_documentation/axi_fifo_mm_s/v4_1/pg080-axi-fifo-mm-s.pdf The driver currently supports only store-forward mode with a 32-bit AXI4 Lite interface. DOES NOT support: - cut-through mode - AXI4 (non-lite) Signed-off-by: Jacob Feder --- drivers/staging/axisfifo/Kconfig |9 + drivers/staging/axisfifo/Makefile |1 + drivers/staging/axisfifo/axis-fifo.c | 1125 + drivers/staging/axisfifo/axisfifo.txt | 89 +++ 4 files changed, 1224 insertions(+) create mode 100644 drivers/staging/axisfifo/Kconfig create mode 100644 drivers/staging/axisfifo/Makefile create mode 100644 drivers/staging/axisfifo/axis-fifo.c create mode 100644 drivers/staging/axisfifo/axisfifo.txt diff --git a/drivers/staging/axisfifo/Kconfig b/drivers/staging/axisfifo/Kconfig new file mode 100644 index 000..5ad68bf --- /dev/null +++ b/drivers/staging/axisfifo/Kconfig @@ -0,0 +1,9 @@ +# +# "Xilinx AXI-Stream FIFO IP core driver" +# +config XIL_AXISFIFO + tristate "Xilinx AXI-Stream FIFO IP core driver" + default n + help + This adds support for the Xilinx AXI-Stream + FIFO IP core driver. \ No newline at end of file diff --git a/drivers/staging/axisfifo/Makefile b/drivers/staging/axisfifo/Makefile new file mode 100644 index 000..bab1770 --- /dev/null +++ b/drivers/staging/axisfifo/Makefile @@ -0,0 +1 @@ +obj-$(CONFIG_XIL_AXISFIFO) := axis-fifo.o diff --git a/drivers/staging/axisfifo/axis-fifo.c b/drivers/staging/axisfifo/axis-fifo.c new file mode 100644 index 000..9cd203f --- /dev/null +++ b/drivers/staging/axisfifo/axis-fifo.c @@ -0,0 +1,1125 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Xilinx AXIS FIFO: interface to the Xilinx AXI-Stream FIFO IP core + * + * Copyright (C) 2018 Jacob Feder + * + * Authors: Jacob Feder + * + * See Xilinx PG080 document for IP details + */ + +/* + * includes + * + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include + +/* + * driver parameters + * + */ + +#define DRIVER_NAME "axis_fifo" + +#define READ_BUF_SIZE 128 /* read buffer length in words */ +#define WRITE_BUF_SIZE 128 /* write buffer length in words */ + +/* + * IP register offsets + * + */ + +#define XLLF_ISR_OFFSET 0x /* Interrupt Status */ +#define XLLF_IER_OFFSET 0x0004 /* Interrupt Enable */ + +#define XLLF_TDFR_OFFSET 0x0008 /* Transmit Reset */ +#define XLLF_TDFV_OFFSET 0x000c /* Transmit Vacancy */ +#define XLLF_TDFD_OFFSET 0x0010 /* Transmit Data */ +#define XLLF_TLR_OFFSET 0x0014 /* Transmit Length */ + +#define XLLF_RDFR_OFFSET 0x0018 /* Receive Reset */ +#define XLLF_RDFO_OFFSET 0x001c /* Receive Occupancy */ +#define XLLF_RDFD_OFFSET 0x0020 /* Receive Data */ +#define XLLF_RLR_OFFSET 0x0024 /* Receive Length */ +#define XLLF_SRR_OFFSET 0x0028 /* Local Link Reset */ +#define XLLF_TDR_OFFSET 0x002C /* Transmit Destination */ +#define XLLF_RDR_OFFSET 0x0030 /* Receive Destination */ + +/* + * reset register masks + * + */ + +#define XLLF_RDFR_RESET_MASK0x00a5 /* receive reset value */ +#define XLLF_TDFR_RESET_MASK0x00a5 /* Transmit reset value */ +#define XLLF_SRR_RESET_MASK 0x00a5 /* Local Link reset value */ + +/* + * interrupt masks + * + */ + +#define XLLF_INT_RPURE_MASK 0x8000 /* Receive under-read */ +#define XLLF_INT_RPORE_MASK 0x4000 /* Receive over-read */ +#define XLLF_INT_RPUE_MASK0x2000 /* Receive underrun (empty) */ +#define XLLF_INT_TPOE_MASK0x1000 /* Transmit overrun */ +#define XLLF_INT_TC_MASK 0x0800 /* Transmit complete */ +#define XLLF_INT_RC_MASK 0x0400 /* Receive complete */ +#define XLLF_INT_TSE_MASK 0x0200 /* Transmit length mismatch */ +#define XLLF_INT_TRC_MASK 0x0100 /* Transmit reset complete */ +#define XLLF_INT_RRC_MASK 0x0080 /* Receive reset complete */ +#define XLLF_INT_TFPF_MASK0x0040
Re: [PATCH resend] staging: gasket: remove X86 Kconfig restriction
Hi Todd,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on staging/staging-testing]
[also build test ERROR on next-20180718]
[cannot apply to v4.18-rc5]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Todd-Poynor/staging-gasket-remove-X86-Kconfig-restriction/20180716-031056
config: xtensa-allmodconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 8.1.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=8.1.0 make.cross ARCH=xtensa
All errors (new ones prefixed by >>):
In file included from drivers/staging/gasket/gasket_page_table.h:19,
from drivers/staging/gasket/gasket_page_table.c:34:
drivers/staging/gasket/gasket_core.h: In function 'gasket_dev_read_64':
>> drivers/staging/gasket/gasket_core.h:651:9: error: implicit declaration of
>> function 'readq'; did you mean 'readl'?
>> [-Werror=implicit-function-declaration]
return readq(_dev->bar_data[bar].virt_base[location]);
^
readl
drivers/staging/gasket/gasket_core.h: In function 'gasket_dev_write_64':
>> drivers/staging/gasket/gasket_core.h:657:2: error: implicit declaration of
>> function 'writeq'; did you mean 'writel'?
>> [-Werror=implicit-function-declaration]
writeq(value, >bar_data[bar].virt_base[location]);
^~
writel
drivers/staging/gasket/gasket_page_table.c: In function
'gasket_is_extended_dev_addr_bad':
drivers/staging/gasket/gasket_page_table.c:1373:11: warning: right shift
count >= width of type [-Wshift-count-overflow]
if (addr >> (GASKET_EXTENDED_LVL0_WIDTH + GASKET_EXTENDED_LVL0_SHIFT)) {
^~
drivers/staging/gasket/gasket_page_table.c: In function
'gasket_alloc_coherent_memory':
drivers/staging/gasket/gasket_page_table.c:1679:4: warning: cast from
pointer to integer of different size [-Wpointer-to-int-cast]
(u64)mem + j * PAGE_SIZE;
^
cc1: some warnings being treated as errors
--
In file included from drivers/staging/gasket/gasket_sysfs.h:21,
from drivers/staging/gasket/gasket_sysfs.c:3:
drivers/staging/gasket/gasket_core.h: In function 'gasket_dev_read_64':
>> drivers/staging/gasket/gasket_core.h:651:9: error: implicit declaration of
>> function 'readq'; did you mean 'readl'?
>> [-Werror=implicit-function-declaration]
return readq(_dev->bar_data[bar].virt_base[location]);
^
readl
drivers/staging/gasket/gasket_core.h: In function 'gasket_dev_write_64':
>> drivers/staging/gasket/gasket_core.h:657:2: error: implicit declaration of
>> function 'writeq'; did you mean 'writel'?
>> [-Werror=implicit-function-declaration]
writeq(value, >bar_data[bar].virt_base[location]);
^~
writel
cc1: some warnings being treated as errors
--
In file included from drivers/staging/gasket/gasket_ioctl.h:6,
from drivers/staging/gasket/gasket_ioctl.c:4:
drivers/staging/gasket/gasket_core.h: In function 'gasket_dev_read_64':
>> drivers/staging/gasket/gasket_core.h:651:9: error: implicit declaration of
>> function 'readq'; did you mean 'readl'?
>> [-Werror=implicit-function-declaration]
return readq(_dev->bar_data[bar].virt_base[location]);
^
readl
drivers/staging/gasket/gasket_core.h: In function 'gasket_dev_write_64':
>> drivers/staging/gasket/gasket_core.h:657:2: error: implicit declaration of
>> function 'writeq'; did you mean 'writel'?
>> [-Werror=implicit-function-declaration]
writeq(value, >bar_data[bar].virt_base[location]);
^~
writel
drivers/staging/gasket/gasket_ioctl.c: In function
'gasket_config_coherent_allocator':
>> drivers/staging/gasket/gasket_ioctl.c:434:27: error: passing argument 3 of
>> 'gasket_alloc_coherent_memory' from incompatible pointer type
>> [-Werror=incompatible-pointer-types]
gasket_dev, ibuf.size, _address,
^
In file included from drivers/staging/gasket/gasket_ioctl.c:9:
drivers/staging/gasket/gasket_page_table.h:227:18: note: expected
'dma_addr_t *' {aka 'unsigned int *'} but argument is of type 'u64 *' {aka
'long long unsigned int *'}
dma_addr_t *dma_address, uint64_t index);
^~~
cc1: some warnings being treated as errors
vim +651 drivers/staging/gasket/gasket_core.h
9a69f508 Simon Que 2018-06-29 620
9a69f508 Simon Que 2018-06-29 621 /*
9a69f508 Simon Que 2018-06-29 622 * Memory management functions. These will
likely be spun off into their
RE: [PATCH 1/2] staging:fsl-mc: Move DPIO from staging to drivers/soc/fsl
> -Original Message-
> From: Roy Pledge
> Sent: Monday, July 9, 2018 10:24 AM
> To: Laurentiu Tudor ;
> de...@driverdev.osuosl.org; linux-arm-ker...@lists.infradead.org;
> gre...@linuxfoundation.org; Leo Li
> Cc: Ioana Ciocoi Radulescu ; Horia Geanta
> ; linux-ker...@vger.kernel.org; a...@arndb.de;
> catalin.mari...@arm.com; robin.mur...@arm.com
> Subject: Re: [PATCH 1/2] staging:fsl-mc: Move DPIO from staging to
> drivers/soc/fsl
>
> On 7/9/2018 6:37 AM, Laurentiu Tudor wrote:
> > Hi Roy,
> >
> > Couple of comments inline.
> >
> > On 05.07.2018 22:41, Roy Pledge wrote:
> >> Move the NXP DPIO (Datapath I/O Driver) out of the drivers/staging
> >> directory and into the drivers/soc/fsl directory.
> >>
> >> The DPIO driver enables access to Queue and Buffer Manager (QBMAN)
> >> hardware on NXP DPAA2 devices. This is a prerequisite to moving the
> >> DPAA2 Ethernet driver out of staging.
> >>
> >> Signed-off-by: Roy Pledge
> >> ---
> >> MAINTAINERS| 2 +-
> >> drivers/crypto/caam/sg_sw_qm2.h| 2 +-
> >> drivers/crypto/caam/sg_sw_sec4.h | 2 +-
> >> drivers/soc/fsl/Kconfig| 10
> >> ++
> >> drivers/soc/fsl/Makefile | 1 +
> >> drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/Makefile | 0
> >> drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/dpio-cmd.h| 0
> >> drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/dpio-driver.c | 2 +-
> >> drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/dpio-driver.txt | 0
> > Maybe this should be converted to .rst and go in the already existing
> > Documentation/networking/dpaa2/?
>
> I can look into converting this to RST but I'm not sure it belongs in the
> networking documentation folder since it will be used by other non
> networking drivers in the near future - compress/decompress for example.
> >
> >> drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/dpio-service.c| 2 +-
> >> drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/dpio.c| 0
> >> drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/dpio.h| 0
> >> drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/qbman-portal.c| 2 +-
> >> drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/qbman-portal.h| 2 +-
> >> drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.h | 4 ++--
> >> drivers/staging/fsl-mc/bus/Kconfig | 9
> >> -
> >> drivers/staging/fsl-mc/bus/Makefile| 2 --
> >> {drivers/staging/fsl-mc/include => include/soc/fsl}/dpaa2-fd.h | 0
> >> .../staging/fsl-mc/include => include/soc/fsl}/dpaa2-global.h | 0
> >> {drivers/staging/fsl-mc/include => include/soc/fsl}/dpaa2-io.h | 0
> >> 20 files changed, 20 insertions(+), 20 deletions(-)
> >> rename drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/Makefile (100%)
> >> rename drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/dpio-cmd.h (100%)
> >> rename drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/dpio-driver.c (99%)
> >> rename drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/dpio-driver.txt
> (100%)
> >> rename drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/dpio-service.c (99%)
> >> rename drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/dpio.c (100%)
> >> rename drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/dpio.h (100%)
> >> rename drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/qbman-portal.c
> (99%)
> >> rename drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/qbman-portal.h
> (99%)
> >> rename {drivers/staging/fsl-mc/include => include/soc/fsl}/dpaa2-fd.h
> (100%)
> >> rename {drivers/staging/fsl-mc/include => include/soc/fsl}/dpaa2-
> global.h (100%)
> >> rename {drivers/staging/fsl-mc/include =>
> >> include/soc/fsl}/dpaa2-io.h (100%)
> > I received feedback in the past on mc-bus that a driver should limit
> > to only one public header and one private one. Would it make sense to
> > do the same for dpio too?
> Looking at this the dpaa-2global.h file should probably be integrated into the
> dpaa2-io.h file.
> The dpaaa2-fd.h can be used by devices that don't need to used DPIO - the
> definition of a frame descriptor isn't DPIO specific so I would argue it
> should
> be kept in a seperate file.
Hi Roy,
Will there be a re-spin of the patch soon so that we can probably catch the
next merge window?
Regards,
Leo
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v7 4/4] kexec_file: Load kernel at top of system RAM if required
On Wed, 18 Jul 2018 10:49:44 +0800 Baoquan He wrote: > For kexec_file loading, if kexec_buf.top_down is 'true', the memory which > is used to load kernel/initrd/purgatory is supposed to be allocated from > top to down. This is what we have been doing all along in the old kexec > loading interface and the kexec loading is still default setting in some > distributions. However, the current kexec_file loading interface doesn't > do like this. The function arch_kexec_walk_mem() it calls ignores checking > kexec_buf.top_down, but calls walk_system_ram_res() directly to go through > all resources of System RAM from bottom to up, to try to find memory region > which can contain the specific kexec buffer, then call > locate_mem_hole_callback() > to allocate memory in that found memory region from top to down. This brings > confusion especially when KASLR is widely supported , users have to make clear > why kexec/kdump kernel loading position is different between these two > interfaces in order to exclude unnecessary noises. Hence these two interfaces > need be unified on behaviour. As far as I can tell, the above is the whole reason for the patchset, yes? To avoid confusing users. Is that sufficient? Can we instead simplify their lives by providing better documentation or informative printks or better Kconfig text, etc? And who *are* the people who are performing this configuration? Random system administrators? Linux distro engineers? If the latter then they presumably aren't easily confused! In other words, I'm trying to understand how much benefit this patchset will provide to our users as a whole. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH net,v2] hv_netvsc: Fix napi reschedule while receive completion is busy
From: Haiyang Zhang
Date: Tue, 17 Jul 2018 17:11:13 +
> From: Haiyang Zhang
>
> If out ring is full temporarily and receive completion cannot go out,
> we may still need to reschedule napi if certain conditions are met.
> Otherwise the napi poll might be stopped forever, and cause network
> disconnect.
>
> Fixes: 7426b1a51803 ("netvsc: optimize receive completions")
> Signed-off-by: Stephen Hemminger
> Signed-off-by: Haiyang Zhang
Applied and queued up for -stable.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v7 1/4] resource: Move reparent_resources() to kernel/resource.c and make it public
On Wed, Jul 18, 2018 at 7:36 PM, Andy Shevchenko wrote: > On Wed, Jul 18, 2018 at 5:49 AM, Baoquan He wrote: >> reparent_resources() is duplicated in arch/microblaze/pci/pci-common.c >> and arch/powerpc/kernel/pci-common.c, so move it to kernel/resource.c >> so that it's shared. >> + * Returns 0 on success, -ENOTSUPP if child resource is not completely >> + * contained by 'res', -ECANCELED if no any conflicting entry found. You also can refer to constants by prefixing them with %, e.g. %-ENOTSUPP. But this is up to you completely. -- With Best Regards, Andy Shevchenko ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v7 1/4] resource: Move reparent_resources() to kernel/resource.c and make it public
On Wed, Jul 18, 2018 at 5:49 AM, Baoquan He wrote:
> reparent_resources() is duplicated in arch/microblaze/pci/pci-common.c
> and arch/powerpc/kernel/pci-common.c, so move it to kernel/resource.c
> so that it's shared.
Some minor stuff.
> +/**
> + * reparent_resources - reparent resource children of parent that res covers
> + * @parent: parent resource descriptor
> + * @res: resource descriptor desired by caller
> + *
> + * Returns 0 on success, -ENOTSUPP if child resource is not completely
> + * contained by 'res', -ECANCELED if no any conflicting entry found.
'res' -> @res
> + *
> + * Reparent resource children of 'parent' that conflict with 'res'
Ditto + 'parent' -> @parent
> + * under 'res', and make 'res' replace those children.
Ditto.
> + */
> +int reparent_resources(struct resource *parent, struct resource *res)
> +{
> + struct resource *p, **pp;
> + struct resource **firstpp = NULL;
> +
> + for (pp = >child; (p = *pp) != NULL; pp = >sibling) {
> + if (p->end < res->start)
> + continue;
> + if (res->end < p->start)
> + break;
> + if (p->start < res->start || p->end > res->end)
> + return -ENOTSUPP; /* not completely contained */
> + if (firstpp == NULL)
> + firstpp = pp;
> + }
> + if (firstpp == NULL)
> + return -ECANCELED; /* didn't find any conflicting entries? */
> + res->parent = parent;
> + res->child = *firstpp;
> + res->sibling = *pp;
> + *firstpp = res;
> + *pp = NULL;
> + for (p = res->child; p != NULL; p = p->sibling) {
> + p->parent = res;
> + pr_debug("PCI: Reparented %s %pR under %s\n",
> +p->name, p, res->name);
Now, PCI is a bit confusing here.
> + }
> + return 0;
> +}
> +EXPORT_SYMBOL(reparent_resources);
> +
> static void __init __reserve_region_with_split(struct resource *root,
> resource_size_t start, resource_size_t end,
> const char *name)
> --
> 2.13.6
>
--
With Best Regards,
Andy Shevchenko
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH V2 2/5] KVM: Add tlb remote flush callback in kvm_x86_ops.
Hi Paolo: Thanks for review. On 7/18/2018 8:01 PM, Paolo Bonzini wrote: > On 09/07/2018 11:02, Tianyu Lan wrote: >> +/* >> + * Call kvm_arch_hv_tlb_remote first and go back old way when >> + * return failure. >> + */ >> +if (!kvm_arch_hv_flush_remote_tlb(kvm)) >> +return; >> + >> /* >> * Read tlbs_dirty before setting KVM_REQ_TLB_FLUSH in >> * kvm_make_all_cpus_request. >> */ >> -long dirty_count = smp_load_acquire(>tlbs_dirty); >> +dirty_count = smp_load_acquire(>tlbs_dirty); > > Also, the call to kvm_arch_flush_remote_tlbs should not replace the > whole function. It should be something like: > > long dirty_count = smp_load_acquire(>tlbs_dirty); > > /* > * We want to publish modifications to the page tables before reading > * mode. Pairs with a memory barrier in arch-specific code. > * - x86: smp_mb__after_srcu_read_unlock in vcpu_enter_guest > * and smp_mb in walk_shadow_page_lockless_begin/end. > * - powerpc: smp_mb in kvmppc_prepare_to_enter. > * > * There is already an smp_mb__after_atomic() before > * kvm_make_all_cpus_request() reads vcpu->mode. We reuse that > * barrier here. > */ > if (!kvm_arch_hv_flush_remote_tlb(kvm) || > kvm_make_all_cpus_request(kvm, KVM_REQ_TLB_FLUSH)) > ++kvm->stat.remote_tlb_flush; > cmpxchg(>tlbs_dirty, dirty_count, 0); > > Otherwise, kvm_mmu_notifier_invalidate_range_start will incorrectly skip > a TLB flush. Nice catch. Will update in the next version. > > Thanks, > > Paolo > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH V2 3/5] KVM/VMX: Add identical ept table pointer check
On 7/18/2018 7:59 PM, Paolo Bonzini wrote:
> On 09/07/2018 11:02, Tianyu Lan wrote:
>> +static void check_ept_pointer(struct kvm_vcpu *vcpu, u64 eptp)
>> +{
>> +struct kvm *kvm = vcpu->kvm;
>> +u64 tmp_eptp = INVALID_PAGE;
>> +int i;
>> +
>> +if (!kvm_x86_ops->tlb_remote_flush)
>> +return;
>> +
>> +spin_lock(_kvm_vmx(kvm)->ept_pointer_lock);
>> +to_vmx(vcpu)->ept_pointer = eptp;
>> +
>> +kvm_for_each_vcpu(i, vcpu, kvm) {
>> +if (!VALID_PAGE(tmp_eptp)) {
>> +tmp_eptp = to_vmx(vcpu)->ept_pointer;
>> +} else if (tmp_eptp != to_vmx(vcpu)->ept_pointer) {
>> +to_kvm_vmx(kvm)->ept_pointers_match = false;
>> +spin_unlock(_kvm_vmx(kvm)->ept_pointer_lock);
>> +return;
>> +}
>> +}
>> +
>> +to_kvm_vmx(kvm)->ept_pointers_match = true;
>> +spin_unlock(_kvm_vmx(kvm)->ept_pointer_lock);
>> +}
>> +
>
> Is there any reason to do the check here, rather than the first time the
> TLB flush is invoked? You could:
>
> - have a tristate (true, false, check) value for ept_pointers_match
>
> - reset it to "check" in vmx_set_cr3
>
> - set it to either true or false in tlb_remote_flush if it is check, and
> do the hypercall if it is true.
>
Thanks for your suggestion. Will update.
> Paolo
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH V2 2/5] KVM: Add tlb remote flush callback in kvm_x86_ops.
On 09/07/2018 11:02, Tianyu Lan wrote: > + /* > + * Call kvm_arch_hv_tlb_remote first and go back old way when > + * return failure. > + */ > + if (!kvm_arch_hv_flush_remote_tlb(kvm)) > + return; > + > /* >* Read tlbs_dirty before setting KVM_REQ_TLB_FLUSH in >* kvm_make_all_cpus_request. >*/ > - long dirty_count = smp_load_acquire(>tlbs_dirty); > + dirty_count = smp_load_acquire(>tlbs_dirty); Also, the call to kvm_arch_flush_remote_tlbs should not replace the whole function. It should be something like: long dirty_count = smp_load_acquire(>tlbs_dirty); /* * We want to publish modifications to the page tables before reading * mode. Pairs with a memory barrier in arch-specific code. * - x86: smp_mb__after_srcu_read_unlock in vcpu_enter_guest * and smp_mb in walk_shadow_page_lockless_begin/end. * - powerpc: smp_mb in kvmppc_prepare_to_enter. * * There is already an smp_mb__after_atomic() before * kvm_make_all_cpus_request() reads vcpu->mode. We reuse that * barrier here. */ if (!kvm_arch_hv_flush_remote_tlb(kvm) || kvm_make_all_cpus_request(kvm, KVM_REQ_TLB_FLUSH)) ++kvm->stat.remote_tlb_flush; cmpxchg(>tlbs_dirty, dirty_count, 0); Otherwise, kvm_mmu_notifier_invalidate_range_start will incorrectly skip a TLB flush. Thanks, Paolo ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH V2 3/5] KVM/VMX: Add identical ept table pointer check
On 09/07/2018 11:02, Tianyu Lan wrote:
> +static void check_ept_pointer(struct kvm_vcpu *vcpu, u64 eptp)
> +{
> + struct kvm *kvm = vcpu->kvm;
> + u64 tmp_eptp = INVALID_PAGE;
> + int i;
> +
> + if (!kvm_x86_ops->tlb_remote_flush)
> + return;
> +
> + spin_lock(_kvm_vmx(kvm)->ept_pointer_lock);
> + to_vmx(vcpu)->ept_pointer = eptp;
> +
> + kvm_for_each_vcpu(i, vcpu, kvm) {
> + if (!VALID_PAGE(tmp_eptp)) {
> + tmp_eptp = to_vmx(vcpu)->ept_pointer;
> + } else if (tmp_eptp != to_vmx(vcpu)->ept_pointer) {
> + to_kvm_vmx(kvm)->ept_pointers_match = false;
> + spin_unlock(_kvm_vmx(kvm)->ept_pointer_lock);
> + return;
> + }
> + }
> +
> + to_kvm_vmx(kvm)->ept_pointers_match = true;
> + spin_unlock(_kvm_vmx(kvm)->ept_pointer_lock);
> +}
> +
Is there any reason to do the check here, rather than the first time the
TLB flush is invoked? You could:
- have a tristate (true, false, check) value for ept_pointers_match
- reset it to "check" in vmx_set_cr3
- set it to either true or false in tlb_remote_flush if it is check, and
do the hypercall if it is true.
Paolo
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH V2 2/5] KVM: Add tlb remote flush callback in kvm_x86_ops.
On 09/07/2018 11:02, Tianyu Lan wrote: > + > + /* > + * Call kvm_arch_hv_tlb_remote first and go back old way when > + * return failure. > + */ Please call it "kvm_arch_flush_remote_tlbs", since Hyper-V should not be mentioned in the generic code. Paolo ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 0/6] lib/crc32: treewide: Use existing define with polynomial
On 18 July 2018 at 02:12, Eric Biggers wrote:
> Hi Krzysztof,
>
> On Tue, Jul 17, 2018 at 06:05:35PM +0200, Krzysztof Kozlowski wrote:
>> Hi,
>>
>> Kernel defines same polynomial for CRC-32 in few places.
>> This is unnecessary duplication of the same value. Also this might
>> be error-prone for future code - every driver will define the
>> polynomial again.
>>
>> This is an attempt to unify definition of polynomial. Few obvious
>> hard-coded locations are fixed with define.
>>
>> All series depend on each 1/6 and 2/6.
>>
>> This could be merged in two different merge windows (1st lib/crc and then
>> the rest) or taken through one tree.
>>
>> It would be nice to get some testing. Only generic lib/crc, bunzip, xz_crc32
>> and Freescale's Ethernet driver were tested on HW. Rest got just different
>> builds.
>>
>> Best regards,
>> Krzysztof
>>
>> Krzysztof Kozlowski (6):
>> lib/crc: Move polynomial definition to separate header
>> lib/crc: Use consistent naming for CRC-32 polynomials
>> crypto: stm32_crc32 - Use existing define with polynomial
>> net: ethernet: Use existing define with polynomial
>> staging: rtl: Use existing define with polynomial
>> lib: Use existing define with polynomial
>>
>> drivers/crypto/stm32/stm32_crc32.c | 11 ---
>> drivers/net/ethernet/amd/xgbe/xgbe-dev.c | 4 ++--
>> drivers/net/ethernet/apple/bmac.c| 8 ++--
>> drivers/net/ethernet/broadcom/tg3.c | 3 ++-
>> drivers/net/ethernet/freescale/fec_main.c| 4 ++--
>> drivers/net/ethernet/freescale/fs_enet/fec.h | 3 ---
>> drivers/net/ethernet/freescale/fs_enet/mac-fec.c | 3 ++-
>> drivers/net/ethernet/micrel/ks8851_mll.c | 3 ++-
>> drivers/net/ethernet/synopsys/dwc-xlgmac-hw.c| 4 ++--
>> drivers/staging/rtl8712/rtl871x_security.c | 5 ++---
>> drivers/staging/rtl8723bs/core/rtw_security.c| 5 ++---
>> include/linux/crc32poly.h| 20
>> lib/crc32.c | 11 ++-
>> lib/crc32defs.h | 14 --
>> lib/decompress_bunzip2.c | 3 ++-
>> lib/gen_crc32table.c | 5 +++--
>> lib/xz/xz_crc32.c| 3 ++-
>> 17 files changed, 55 insertions(+), 54 deletions(-)
>> create mode 100644 include/linux/crc32poly.h
>>
>
> Did you check whether any of these users can be converted to use the CRC
> implementations in lib/, so they wouldn't need the polynomial definition
> themselves?
I did not check but that's interesting point... The Ethernet drivers
(xgbe, tg3, fec, ks8851, dwc-xlgmac) look like could be converted to
generic implementation. The apple/bmac looks weird. The rtl WiFi
drivers in long term can be converted to use generic lib80211 for
encryption (see commit 0d4876f4e977 ("staging:r8188eu: Use lib80211 to
encrypt (TKIP) tx frames")) but that is much bigger task. The
remaining use the polynomials in different aspect:
1. XZ and BUNZIP use it to create CRC tables - probably generic
gen_crc32table.c could be used,
2. stm32_crc32.c uses it to initialize HW CRC accelerator.
I can work on Freescale FEC, xz and bunzip code because these I can
test but I would prefer to do it as follow up.
Best regards,
Krzysztof
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
