Re: [PATCH v2 00/22] xfs-4.20: major documentation surgery

On Thu, Oct 11, 2018 at 11:27:35AM -0600, Jonathan Corbet wrote: > On Sat, 6 Oct 2018 10:51:54 +1000 > Dave Chinner wrote: > > > Can you let us know whether the CC-by-SA 4.0 license is acceptible > > or not? That's really the only thing that we need clarified at this > > point - if it's OK I'll

Re: [PATCH 13/18] wait: wait.h: Get rid of a kernel-doc/Sphinx warnings

> * Use either while holding wait_queue_head::lock or when used for wakeups > - * with an extra smp_mb() like: > + * with an extra smp_mb() like:: Independent of any philosophical discussion not allowing a setence to end with a single ':' is completely idiotic. Please fix the tooling instead

Re: [PATCH 2/3] mm: replace __HAVE_ARCH_PTE_SPECIAL

> -#ifdef __HAVE_ARCH_PTE_SPECIAL > +#ifdef CONFIG_ARCH_HAS_PTE_SPECIAL > # define HAVE_PTE_SPECIAL 1 > #else > # define HAVE_PTE_SPECIAL 0 I'd say kill this odd indirection and just use the CONFIG_ARCH_HAS_PTE_SPECIAL symbol directly. -- To unsubscribe from this list: send the line

Re: [PATCH 00/16] remove eight obsolete architectures

On Thu, Mar 15, 2018 at 11:42:25AM +0100, Arnd Bergmann wrote: > Is anyone producing a chip that includes enough of the Privileged ISA spec > to have things like system calls, but not the MMU parts? Various SiFive SOCs seem to support M and U mode, but no S mode or iommu. That should be enough

Re: [PATCH v3 2/4] soc: qcom: Add GENI based QUP Wrapper driver

On Thu, Mar 08, 2018 at 01:24:45PM +, Robin Murphy wrote: > Implementing dma_map_ops inside a driver for real hardware is almost always > the wrong thing to do. Agreed. dma_map_ops should be a platform decision based on the bus. Even our dma_virt_ops basically just works around bad driver

Re: [PATCH] pci: Add a acs_disable option for pci kernel parameter

On Thu, Oct 26, 2017 at 08:37:49PM -0600, sba...@raithlin.com wrote: > From: Stephen Bates > > On some servers the BIOS sets up ACS on any valid pci_dev in the > system. The kernel has no way of backing this out since the kernel > only turns ACS capabilities on. > > This

Re: [PATCH, RESEND 08/12] ima: added parser for RPM data type

On Tue, Aug 01, 2017 at 12:20:36PM +0200, Roberto Sassu wrote: > This patch introduces a parser for RPM packages. It extracts the digests > from the RPMTAG_FILEDIGESTS header section and converts them to binary data > before adding them to the hash table. > > The advantage of this data type is

Re: [PATCH v5 1/5] mm: add vm_insert_mixed_mkwrite()

On Tue, Jul 25, 2017 at 01:14:00AM +0300, Kirill A. Shutemov wrote: > I guess it's up to filesystem if it wants to reuse the same spot to write > data or not. I think your assumptions works for ext4 and xfs. I wouldn't > be that sure for btrfs or other filesystems with CoW support. Or XFS with

Re: [PATCH] changes.rst: explain the usage of virtual environment

On Mon, Jun 19, 2017 at 08:24:10AM -0300, Mauro Carvalho Chehab wrote: > As the Sphinx build seems very fragile, specially for > PDF output, add a notice about how to use it on a virtual > environment. Please don't. python venv are good at one thing only, and that is making a mess of your python

Re: [PATCH v6 25/34] swiotlb: Add warnings for use of bounce buffers with SME

On Wed, Jun 07, 2017 at 02:17:32PM -0500, Tom Lendacky wrote: > Add warnings to let the user know when bounce buffers are being used for > DMA when SME is active. Since the bounce buffers are not in encrypted > memory, these notifications are to allow the user to determine some > appropriate

Re: [PATCH 1/3] include: linux: visorbus: Add visorbus to include/linux directory

Please don't send any move patches but the actual code added to the kernel proper. And based on what's in linux-next I don't think this giant pile of junk is anywhere near mergeable. -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to

Re: [PATCH v2 04/22] Documentation: PCI: Guide to use pci endpoint configfs

I'm commenting on the configfs layout here instead of the patch with the code as the issues are easier to explain that way. I think the layout is a bit confusing and could be cleaner by making use of pre-created entries and symlinks. Here is my suggestion: /sys/kernel/config/pci_ep/functions/

Re: [PATCH v2 03/22] PCI: endpoint: Introduce configfs entry for configuring EP functions

On Fri, Feb 17, 2017 at 03:20:23PM +0530, Kishon Vijay Abraham I wrote: > Introduce a new configfs entry to configure the EP function (like > configuring the standard configuration header entries) and to > bind the EP function with EP controller. > > Signed-off-by: Kishon Vijay Abraham I

[PATCH 1/2] PCI: update pci.txt to talk about pci_alloc_irq_vectors

instead of the deprecated pci_enable_msi* APIs. Signed-off-by: Christoph Hellwig <h...@lst.de> --- Documentation/PCI/pci.txt | 24 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/Documentation/PCI/pci.txt b/Documentation/PCI/pci.txt index 77f49d

[PATCH 2/2] PCI: update MSI/MSI-X bits in PCIEBUS-HOWTO

Stop talking about low-level details that mention deprecated APIs and concentrate on what service drivers should do and why. Signed-off-by: Christoph Hellwig <h...@lst.de> --- Documentation/PCI/PCIEBUS-HOWTO.txt | 33 +++-- 1 file changed, 7 insertions(

two small PCI documentation fixups

Avoid mentioning deprecated APIs and make the text a little easier to understand. -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH 31/37] misc: Add host side pci driver for pci test function device

On Thu, Jan 12, 2017 at 03:56:20PM +0530, Kishon Vijay Abraham I wrote: > Add PCI endpoint test driver that can verify base address > register, legacy interrupt/MSI interrupt and read/write/copy > buffers between host and device. The corresponding pci-epf-test > function driver should be used on

Re: [PATCH 16/37] PCI: endpoint: Introduce configfs entry for configuring EP functions

On Mon, Jan 16, 2017 at 11:31:23AM +0530, Kishon Vijay Abraham I wrote: > Actually not all devices have hardcoded headers. E.g the platform I'm using > doesn't have hardcoded headers and it can be configured based on the function > the user would like to use. If the devices are hardcoded, then

Re: [PATCH 16/37] PCI: endpoint: Introduce configfs entry for configuring EP functions

Hi Kishon, a couple comments on the configfs layout based on my experiments with your previous drop to implement a NVMe device using it. I don't think most of these configfs files should be present here, as they are properties of the implemented PCIe devices. E.g. for my NVMe device they will

Re: [PATCH v2 7/7] uapi: export all headers under uapi directories

On Fri, Jan 06, 2017 at 10:43:59AM +0100, Nicolas Dichtel wrote: > Regularly, when a new header is created in include/uapi/, the developer > forgets to add it in the corresponding Kbuild file. This error is usually > detected after the release is out. > > In fact, all headers under uapi

Re: [PATCH v7 09/11] scsi: ufs: connect to RPMB subsystem

On Mon, Nov 07, 2016 at 07:27:38PM +, Winkler, Tomas wrote: > I value your opinion but I'm not responsible for inventing RPMB > and/or its implementation storage devices (eMMC, UFC, NVMe), it's pretty > much done deal out there in the wild. > I'm just trying to provide common API above

Re: [PATCH v7 09/11] scsi: ufs: connect to RPMB subsystem

On Mon, Nov 07, 2016 at 09:53:12PM +0200, Tomas Winkler wrote: > Register UFS RPMB LUN with the RPMB subsystem and provide > implementation for the RPMB access operations. RPMB partition is > accessed via a sequence of security protocol in and security protocol > out commands with UFS specific

Re: [RFC PATCH-tip v4 02/10] locking/rwsem: Stop active read lock ASAP

On Wed, Oct 12, 2016 at 08:06:40AM +1100, Dave Chinner wrote: > Um, I seem to have completely missed that change - when did that > happen and why? > > Oh, it was part of the misguided "enable DAX on block devices" > changes - o, that commit just switched it to use ->f_mapping: - return

Re: [RFC PATCH 05/11] pci: rename *host* directory to *controller*

This is a big and painful change. I'd suggest to either drop it for now or convince Bjorn to take it as a scripted renamed just after -rc1. -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at

Re: [RFC PATCH 02/11] pci: endpoint: introduce configfs entry for configuring EP functions

On Wed, Sep 14, 2016 at 10:41:58AM +0530, Kishon Vijay Abraham I wrote: > diff --git a/drivers/pci/endpoint/Kconfig b/drivers/pci/endpoint/Kconfig > index a6d827c..f1dd206 100644 > --- a/drivers/pci/endpoint/Kconfig > +++ b/drivers/pci/endpoint/Kconfig > @@ -13,7 +13,9 @@ config PCI_ENDPOINT > >

Re: [RFC PATCH 00/11] pci: support for configurable PCI endpoint

On Mon, Sep 26, 2016 at 11:38:41AM +0530, Kishon Vijay Abraham I wrote: > > Ok, so in theory there can be other hardware (and quite likely is) > > that supports multiple functions, and we can extend the framework > > to support them without major obstacles, but your hardware doesn't, > > so you

Re: [RFC PATCH 01/11] pci: endpoint: add EP core layer to enable EP controller and EP functions

> +/** > + * pci_epc_stop() - stop the PCI link > + * @epc: the link of the EPC device that has to be stopped > + * > + * Invoke to stop the PCI link > + */ > +void pci_epc_stop(struct pci_epc *epc) > +{ > + if (IS_ERR(epc) || !epc->ops->stop) > + return; > + > +

Re: [RFC PATCH-tip v4 02/10] locking/rwsem: Stop active read lock ASAP

On Mon, Oct 10, 2016 at 05:07:45PM +1100, Dave Chinner wrote: > > > *However*, the DAX IO path locking in XFS has changed in 4.9-rc1 to > > > match the buffered IO single writer POSIX semantics - the test is a > > > bad test based on the fact it exercised a path that is under heavy > > >

Re: [RFC PATCH-tip v4 02/10] locking/rwsem: Stop active read lock ASAP

On Fri, Oct 07, 2016 at 08:47:51AM +1100, Dave Chinner wrote: > Except that it's DAX, and in 4.7-rc1 that used shared locking at the > XFS level and never took exclusive locks. > > *However*, the DAX IO path locking in XFS has changed in 4.9-rc1 to > match the buffered IO single writer POSIX

Re: [PATCH] printk: introduce kptr_restrict level 3

On Wed, Oct 05, 2016 at 02:04:46PM -0400, william.c.robe...@intel.com wrote: > From: William Roberts > > Some out-of-tree modules do not use %pK and just use %p, as it's > the common C paradigm for printing pointers. Because of this, > kptr_restrict has no affect on

Re: [PATCHv12 1/3] rdmacg: Added rdma cgroup controller

FYI, the patches look fine to me: Acked-by: Christoph Hellwig <h...@lst.de> but we're past the merge window for 4.9 now unfortunately. -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordo

Re: [PATCHv12 1/3] rdmacg: Added rdma cgroup controller

On Sun, Sep 11, 2016 at 11:14:09AM -0600, Jason Gunthorpe wrote: > > > We stil always have the common structure first. And at least for > > > cgroups supports that's what matters. > > > > > > Re the actual structures - we'll really need to make sure we > > > > > > a) expose proper userspace abi

[PATCH] DMA-API-HOWTO: is no more

So don't mention it. Signed-off-by: Christoph Hellwig <h...@lst.de> --- Documentation/DMA-API-HOWTO.txt | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/Documentation/DMA-API-HOWTO.txt b/Documentation/DMA-API-HOWTO.txt index 781024e..494ffac 100644 --- a/Documen

Re: [PATCHv12 1/3] rdmacg: Added rdma cgroup controller

On Sat, Sep 10, 2016 at 11:01:51AM -0600, Jason Gunthorpe wrote: > Sadly, it isn't a step backwards, it is status quo - at least as far > as the uapi is concerned. Sort of, see below: > struct mlx5_create_cq { > struct ibv_create_cqibv_cmd; > __u64

Re: [PATCHv12 1/3] rdmacg: Added rdma cgroup controller

On Wed, Sep 07, 2016 at 11:51:42AM +0300, Matan Barak wrote: > All recent proposals of the new ABI schema deals with extending the > flexibility of the current schema by letting drivers define their specific > types, actions, attributes, etc. Even more than that, the dispatching > starts from

Re: [PATCHv12 1/3] rdmacg: Added rdma cgroup controller

On Wed, Sep 07, 2016 at 01:25:13PM +0530, Parav Pandit wrote: > > a) delay cgroups support until the grand rewrite is done > > b) add it now and deal with the consequences later > > > Can we do (b) now and differ adding any HW resources to cgroup until > they are clearly called out. >

Re: [PATCHv12 1/3] rdmacg: Added rdma cgroup controller

On Thu, Sep 01, 2016 at 10:25:40AM +0300, Matan Barak wrote: > Well, if I recall, the reason doing so last time was in order to allow > flexible updating of ib_core independently, which is obviously not a good > reason (to say the least). > > Since the new ABI will probably define new object

Re: [PATCHv11 0/3] rdmacg: IB/core: rdma controller support

On Wed, Aug 24, 2016 at 05:17:47PM -0400, Tejun Heo wrote: > Looks good to me. I just have a nit in the documentation. Christoph, > what do you think? Looks reasonable from a quick look, but I didn't do a full review yet. -- To unsubscribe from this list: send the line "unsubscribe linux-doc"

Re: [PATCH 03/10] docs: sphinxify sparse.txt and move to dev-tools

On Thu, Aug 18, 2016 at 05:46:30PM -0600, Jonathan Corbet wrote: > So would the old hats be happier with a patch that looks like this? The > quality of the formatted output suffers slightly, but it's not a big > deal... I think this a major improvement. The only thing that still strikes me as

Re: [PATCH 03/10] docs: sphinxify sparse.txt and move to dev-tools

On Tue, Aug 09, 2016 at 11:19:50AM +0300, Jani Nikula wrote: > On Tue, 09 Aug 2016, Christoph Hellwig <h...@infradead.org> wrote: > > The ugly format is a major regression over a proper simple text > > file. What's the point? > > Major regression? Please be reasonabl

[PATCH] DMA-API-HOWTO: is no more

So don't mention it. Signed-off-by: Christoph Hellwig <h...@lst.de> --- Documentation/DMA-API-HOWTO.txt | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/Documentation/DMA-API-HOWTO.txt b/Documentation/DMA-API-HOWTO.txt index 781024e..494ffac 100644 --- a/Documen

Re: [PATCH] Revert "mm: rename _count, field of the struct page, to _refcount"

On Thu, Jun 16, 2016 at 11:22:46AM +0200, Vitaly Kuznetsov wrote: > _count -> _refcount rename in commit 0139aa7b7fa12 ("mm: rename _count, > field of the struct page, to _refcount") broke kdump. makedumpfile(8) does > stuff like READ_MEMBER_OFFSET("page._count", page._count) and fails. While > it

Re: [PATCH] Add kernel parameter to blacklist modules

On Mon, Jun 13, 2016 at 08:32:41AM -0400, Prarit Bhargava wrote: > Blacklisting a module in linux has long been a problem. The process of > blacklisting a module has changed over time, and it seems that every OS > does it slightly differently and depends on the age of the init system > used on

Re: [PATCH v4 01/44] dma-mapping: Use unsigned long for dma_attrs

On Fri, Jun 10, 2016 at 04:49:47PM +0200, Luis R. Rodriguez wrote: > Do we not expect the number of argument to grow ? This "cleanup" would > do away with such possibilities, and then require adding the API later, > and this requiring a full set of collateral evolutions again when this > is

Re: [RFC v2] dma-mapping: Use unsigned long for dma_attrs

On Wed, Jun 01, 2016 at 07:36:42AM +0200, Krzysztof Kozlowski wrote: > > No really for this patch, but I would much prefer to document them next > > to the code in the long run. Also I really think these BIT() macros > > are a distraction compared to the (1 << N) notation. > > Not much

Re: [RFC v2] dma-mapping: Use unsigned long for dma_attrs

On Mon, May 30, 2016 at 01:54:06PM +0200, Krzysztof Kozlowski wrote: > The dma-mapping core and the implementations do not change the > DMA attributes passed by pointer. Thus the pointer can point to const > data. However the attributes do not have to be a bitfield. Instead > unsigned long will

Re: [PATCHv10 1/3] rdmacg: Added rdma cgroup controller

On Tue, Apr 05, 2016 at 05:55:26AM -0700, Parav Pandit wrote: > Just because we add one more rdma resource, we need to ask someone to > upgrade kernel? Yes. Just like when you need any other core kernel resource. -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body