Re: [PATCH 0/2] memory_hotplug: introduce config and command line options to set the default onlining policy

On Thu, 7 Apr 2016, Vitaly Kuznetsov wrote: > >> > This patchset continues the work I started with: > >> > > >> > commit 31bc3858ea3ebcc3157b3f5f0e624c5962f5a7a6 > >> > Author: Vitaly Kuznetsov > >> > Date: Tue Mar 15 14:56:48 2016 -0700 > >> > > >> > memory-hotplug:

Re: [PATCH] ASoC: docs: add clocking examples for DAI formats

On 2016-04-18 17:11, Mark Brown wrote: > On Mon, Apr 18, 2016 at 01:18:47PM +, Peter Rosin wrote: >> Mark Brown wrote: > >>> >>> There aren't any (beyond the usual references to the Wolfson datasheets >>> which I'd suggest should be in here) but that doesn't mean we should >>> ignore this

Re: [PATCH] Add EDAC peripheral init functions & Ethernet EDAC.

On 04/18/2016 03:02 PM, Borislav Petkov wrote: On Mon, Apr 18, 2016 at 09:27:16AM -0500, Thor Thayer wrote: We're still getting the single bit correction By that you mean, you get that by enabling ECC on the FIFO block? Yes, you are correct. I'd still get the single bit correction by

Re: [PATCH] Add EDAC peripheral init functions & Ethernet EDAC.

On Mon, Apr 18, 2016 at 10:02:27PM +0200, Borislav Petkov wrote: > > the number of uncorrectable errors is useful from a system point of > > view. I forgot: so altr_edac_a10_ecc_irq() panics on uncorrectable errors. Do we want to do that even for UEs coming from the network...? Seems a bit

Re: [PATCH] Add EDAC peripheral init functions & Ethernet EDAC.

On Mon, Apr 18, 2016 at 09:27:16AM -0500, Thor Thayer wrote: > We're still getting the single bit correction By that you mean, you get that by enabling ECC on the FIFO block? > which makes the entire system more stable and the ability to see both > single bit errors corrected and the number of

Re: [RFC v1 3/4] x86, boot: Implement ASLR for kernel memory sections (x86_64)

On April 18, 2016 7:46:05 AM PDT, Joerg Roedel wrote: >On Fri, Apr 15, 2016 at 03:03:12PM -0700, Thomas Garnier wrote: >> +#if defined(CONFIG_KASAN) >> +static const unsigned long memory_rand_end = KASAN_SHADOW_START; >> +#elfif defined(CONFIG_X86_ESPFIX64) >> +static const

Re: [PATCH RFC 2/3] vfio: report group noiommu status

On Mon, 18 Apr 2016 12:58:20 +0300 "Michael S. Tsirkin" wrote: > When using vfio, callers might want to know whether device is added to a > regular group or an non-iommu group. > > Report this status from vfio_add_group_dev. > > Signed-off-by: Michael S. Tsirkin

[PATCH] documentation: trivial typo: adding-syscalls.txt: s/statat/fstatat/

Signed-off-by: Askar Safin --- diff --git a/Documentation/adding-syscalls.txt b/Documentation/adding-syscalls.txt index cc2d4ac..bbb31e0 100644 --- a/Documentation/adding-syscalls.txt +++ b/Documentation/adding-syscalls.txt @@ -136,7 +136,7 @@ an fxyzzy(3) operation for free:

Greetings!!!

Hi, how are you? My name is J Eric Denials, External Financial Auditor at Lloyds Banking Group plc., London. It is a pleasure to contact you at this time through this medium. I have a cool and legitimate deal to do with you as you're a foreigner, it will be mutually beneficial to both. If

Re: [PATCH] documentation: trivial typo: adding-syscalls.txt: s/statat/fstatat/

On Mon, 18 Apr 2016 20:30:56 +0300 Askar Safin wrote: > -page; for an example of AT_EMPTY_PATH, see the statat(2) man page.) > +page; for an example of AT_EMPTY_PATH, see the fstatat(2) man page.) Applied to the docs tree, thanks. jon -- To unsubscribe from this list: send

[PATCH v11 3/4] tpm: Proxy driver for supporting multiple emulated TPMs

This patch implements a proxy driver for supporting multiple emulated TPMs in a system. The driver implements a device /dev/vtpmx that is used to created a client device pair /dev/tpmX (e.g., /dev/tpm10) and a server side that is accessed using a file descriptor returned by an ioctl. The device

Re: SV: [PATCH] ASoC: docs: add clocking examples for DAI formats

On Mon, Apr 18, 2016 at 01:18:47PM +, Peter Rosin wrote: > Mark Brown wrote: > > > > There aren't any (beyond the usual references to the Wolfson datasheets > > which I'd suggest should be in here) but that doesn't mean we should > > ignore this spec when we have it. > This is exactly the

Re: [RFC v1 3/4] x86, boot: Implement ASLR for kernel memory sections (x86_64)

Yes, it is. Certainly happened while editing patches (sorry about that), will be fixed on next iteration once I get a bit more feedback. On Mon, Apr 18, 2016 at 7:46 AM, Joerg Roedel wrote: > On Fri, Apr 15, 2016 at 03:03:12PM -0700, Thomas Garnier wrote: >> +#if

Re: [PATCH] Add EDAC peripheral init functions & Ethernet EDAC.

Hi Boris, On 04/15/2016 04:46 PM, Borislav Petkov wrote: On Fri, Apr 15, 2016 at 10:27:54AM -0500, Thor Thayer wrote: I'll update this patch to only count errors. ... and also think about what that counting is going to bring. If it is only going to be there to show how many network errors

[PATCH v2] ASoC: docs: add clocking examples for DAI formats

Provide *our* view of what the rules are for the different DAI formats, so that we do not have to trust external interpretations for this crucial bit of interoperability. Signed-off-by: Peter Rosin --- Documentation/sound/alsa/soc/clocking.txt | 145

Re: [PATCH] ASoC: docs: add clocking examples for DAI formats

On Mon, Apr 18, 2016 at 12:55:23PM +, Peter Rosin wrote: > Mark Brown wrote: > > There is an actual spec for I2S which is going to be clearer than ASCII > > art: > >https://www.sparkfun.com/datasheets/BreakoutBoards/I2SBUS.pdf > > is the first hit on google (there's a bunch of

RE: [RFC v6 06/10] PCI: Add a new PCI_BUS_FLAGS_MSI_REMAP flag

From: Yongji Xie > Sent: 18 April 2016 11:59 > We introduce a new pci_bus_flags, PCI_BUS_FLAGS_MSI_REMAP > which indicates all devices on the bus are protected by the > hardware which supports IRQ remapping(intel naming). > > This flag will be used to know whether it's safe to expose > MSI-X

Re: [PATCH] ASoC: docs: add clocking examples for DAI formats

On Mon, Apr 18, 2016 at 11:39:50AM +0200, Peter Rosin wrote: > +I2S > + .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. > +-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '- There is an actual spec for I2S which is going to be clearer than ASCII

Re: Kernel docs: muddying the waters a bit

Em Mon, 18 Apr 2016 10:10:17 +0200 Markus Heiser escreveu: > Hi Mauro, hi kernel-doc authors, > > Am 12.04.2016 um 15:58 schrieb Mauro Carvalho Chehab > : > > > Em Fri, 8 Apr 2016 17:12:27 +0200 > > Markus Heiser

[PATCH] ASoC: docs: add clocking examples for DAI formats

Provide *our* view of what the rules are for the different DAI formats, so that we do not have to trust external interpretations for this crucial bit of interoperability. Signed-off-by: Peter Rosin --- Documentation/sound/alsa/soc/clocking.txt | 110

[RFC v6 08/10] PCI: Set PCI_BUS_FLAGS_MSI_REMAP if MSI controller supports IRQ remapping

On ARM HW the capability of IRQ remapping is abstracted on MSI controller side. MSI_FLAG_IRQ_REMAPPING is used to advertise this [1]. To have a universal flag to test this capability for different archs on PCI side, we set PCI_BUS_FLAGS_MSI_REMAP for PCI buses when MSI_FLAG_IRQ_REMAPPING is set.

[RFC v6 09/10] pci-ioda: Set PCI_BUS_FLAGS_MSI_REMAP for IODA host bridge

Any IODA host bridge have the capability of IRQ remapping. So we set PCI_BUS_FLAGS_MSI_REMAP when this kind of host birdge is detected. Signed-off-by: Yongji Xie --- arch/powerpc/platforms/powernv/pci-ioda.c |8 1 file changed, 8 insertions(+) diff --git

[RFC v6 10/10] vfio-pci: Allow to mmap MSI-X table if interrupt remapping is supported

This patch enables mmapping MSI-X tables if hardware supports interrupt remapping which can ensure that a given pci device can only shoot the MSIs assigned for it. With MSI-X table mmapped, we also need to expose the read/write interface which will be used to access MSI-X table. Signed-off-by:

[RFC v6 06/10] PCI: Add a new PCI_BUS_FLAGS_MSI_REMAP flag

We introduce a new pci_bus_flags, PCI_BUS_FLAGS_MSI_REMAP which indicates all devices on the bus are protected by the hardware which supports IRQ remapping(intel naming). This flag will be used to know whether it's safe to expose MSI-X tables of PCI BARs to userspace. Because the capability of

[RFC v6 07/10] iommu: Set PCI_BUS_FLAGS_MSI_REMAP if IOMMU have capability of IRQ remapping

The capability of IRQ remapping is abstracted on IOMMU side on some archs. There is a existing flag IOMMU_CAP_INTR_REMAP for this. To have a universal flag to test this capability for different archs on PCI side, we set PCI_BUS_FLAGS_MSI_REMAP for PCI buses when IOMMU_CAP_INTR_REMAP is set.

[RFC v6 03/10] PCI: Add a new option for resource_alignment to reassign alignment

When using resource_alignment kernel parameter, the current implement reassigns the alignment by changing resources' size which can potentially break some drivers. For example, the driver uses the size to locate some register whose length is related to the size. This patch adds a new option

[RFC v6 01/10] PCI: Ignore resource_alignment if PCI_PROBE_ONLY was set

The resource_alignment will releases memory resources allocated by firmware so that kernel can reassign new resources later on. But this will cause the problem that no resources can be allocated by kernel if PCI_PROBE_ONLY was set, e.g. on pSeries platform because PCI_PROBE_ONLY force kernel to

[RFC v6 00/10] vfio-pci: Allow to mmap sub-page MMIO BARs and MSI-X table

Current vfio-pci implementation disallows to mmap sub-page(size < PAGE_SIZE) MMIO BARs and MSI-X table. This is because sub-page BARs' mmio page may be shared with other BARs and MSI-X table should not be accessed directly from the guest for security reasons. But it will easily cause some

[RFC v6 02/10] PCI: Do not Use IORESOURCE_STARTALIGN to identify bridge resources

Now we use the IORESOURCE_STARTALIGN to identify bridge resources in __assign_resources_sorted(). That's quite fragile. We can't make sure that the PCI devices' resources will not use IORESOURCE_STARTALIGN any more. In this patch, we try to use a more robust way to identify bridge resources.

[RFC v6 04/10] PCI: Add support for enforcing all MMIO BARs to be page aligned

When vfio passthrough a PCI device of which MMIO BARs are smaller than PAGE_SIZE, guest will not handle the mmio accesses to the BARs which leads to mmio emulations in host. This is because vfio will not allow to passthrough one BAR's mmio page which may be shared with other BARs. Otherwise,

[PATCH RFC 2/3] vfio: report group noiommu status

When using vfio, callers might want to know whether device is added to a regular group or an non-iommu group. Report this status from vfio_add_group_dev. Signed-off-by: Michael S. Tsirkin --- drivers/vfio/pci/vfio_pci.c | 2 +-

Re: Kernel docs: muddying the waters a bit

Hi Jonahtan, Am 12.04.2016 um 17:46 schrieb Jonathan Corbet : > On Fri, 8 Apr 2016 17:12:27 +0200 > Markus Heiser wrote: > >> motivated by this MT, I implemented a toolchain to migrate the kernel’s >> DocBook XML documentation to reST markup. >> >>

Re: [PATCH v3] ARM64: ACPI: Update documentation for latest specification version

On Fri, Apr 15, 2016 at 11:54:08AM -0600, Al Stone wrote: [...] > > Understood, the point I wanted to make is that adding a list of methods > > in acpi_object_usage.txt ("Use as needed") is not necessarily additional > > information, you can add a pointer at ACPI specs (for that specific > >

Re: [PATCH 4/4] serial: doc: .break_ctl() may sleep

Hi Jon, On Sat, Apr 16, 2016 at 6:47 PM, Jonathan Corbet wrote: > On Fri, 15 Apr 2016 16:07:39 -0700 > Peter Hurley wrote: > >> > I'm missing something here. >> >> Yes. >> >> The analysis above is required to show that the API contract asserted by >>

Re: Kernel docs: muddying the waters a bit

Hi Mauro, hi kernel-doc authors, Am 12.04.2016 um 15:58 schrieb Mauro Carvalho Chehab : > Em Fri, 8 Apr 2016 17:12:27 +0200 > Markus Heiser escreveu: > >> Hi kernel-doc authors, >> >> motivated by this MT, I implemented a toolchain to

Re: [PATCH v6 20/24] iio: imu: inv_mpu6050: change the i2c gate to be mux-locked

On Sun, Apr 3, 2016 at 1:54 PM, Jonathan Cameron wrote: > On 03/04/16 09:52, Peter Rosin wrote: >> From: Peter Rosin >> >> The root i2c adapter lock is then no longer held by the i2c mux during >> accesses behind the i2c gate, and such accesses need to take