Re: [PATCH 1/2] phy: qcom-qusb2: New driver for QUSB2 PHY on Qcom chips

On Wed, Oct 19, 2016 at 04:13:46PM +0530, Vivek Gautam wrote: > PHY transceiver driver for QUSB2 phy controller that provides > HighSpeed functionality for DWC3 controller present on > Qualcomm chipsets. > > This driver is based on phy-msm-qusb driver available in > msm-4.4 kernel @codeaurora[1]

Re: [PATCH 1/2] phy: qcom-qusb2: New driver for QUSB2 PHY on Qcom chips

On Wed, Oct 19, 2016 at 04:13:46PM +0530, Vivek Gautam wrote: > PHY transceiver driver for QUSB2 phy controller that provides > HighSpeed functionality for DWC3 controller present on > Qualcomm chipsets. > > This driver is based on phy-msm-qusb driver available in > msm-4.4 kernel @codeaurora[1]

Re: [PATCH v5 10/18] x86/intel_rdt: Build structures for each resource based on cache topology

On Wed, Oct 26, 2016 at 03:02:56PM +0200, Thomas Gleixner wrote: > On Sat, 22 Oct 2016, Fenghua Yu wrote: > > +void rdt_cbm_update(void *arg) > > +{ > > + struct msr_param *m = (struct msr_param *)arg; > > + struct rdt_resource *r = m->res; > > + int i, cpu = smp_processor_id(); > > +

Re: [PATCH v5 10/18] x86/intel_rdt: Build structures for each resource based on cache topology

On Wed, Oct 26, 2016 at 03:02:56PM +0200, Thomas Gleixner wrote: > On Sat, 22 Oct 2016, Fenghua Yu wrote: > > +void rdt_cbm_update(void *arg) > > +{ > > + struct msr_param *m = (struct msr_param *)arg; > > + struct rdt_resource *r = m->res; > > + int i, cpu = smp_processor_id(); > > +

Re: [PATCH 2/2] hwmon: (mcp3021) add devicetree bindings documentation

On Wed, Oct 19, 2016 at 11:40:56AM +0200, Clemens Gruber wrote: > Documents the devicetree bindings for the Microchip MCP3021/3221. > > Signed-off-by: Clemens Gruber > --- > Documentation/devicetree/bindings/hwmon/mcp3021.txt | 21 > + > 1 file

Re: [PATCH 2/2] hwmon: (mcp3021) add devicetree bindings documentation

On Wed, Oct 19, 2016 at 11:40:56AM +0200, Clemens Gruber wrote: > Documents the devicetree bindings for the Microchip MCP3021/3221. > > Signed-off-by: Clemens Gruber > --- > Documentation/devicetree/bindings/hwmon/mcp3021.txt | 21 > + > 1 file changed, 21 insertions(+) >

Re: [PATCH] net: bonding: use new api ethtool_{get|set}_link_ksettings

Hi Jay, On Wed, Oct 26, 2016 at 8:00 PM, Jay Vosburgh wrote: > Philippe Reynes wrote: > >>The ethtool api {get|set}_settings is deprecated. >>We move this driver to new api {get|set}_link_ksettings. > > This is just an API change, i.e., no

Re: [PATCH] net: bonding: use new api ethtool_{get|set}_link_ksettings

Hi Jay, On Wed, Oct 26, 2016 at 8:00 PM, Jay Vosburgh wrote: > Philippe Reynes wrote: > >>The ethtool api {get|set}_settings is deprecated. >>We move this driver to new api {get|set}_link_ksettings. > > This is just an API change, i.e., no change to functionality? Yes, it's juste an

Geschäftsvorschlag!!!

-- Geschäftsvorschlag!!! Ich vermute das diese E-Mail eine Überraschung für Sie sein wird, aber es ist wahr.Ich bin bei einer routinen Überprüfung in meiner Bank (First National Bank von Süd Afrika) wo ich arbeite, auf einem Konto gestoßen, was nicht in anspruch genommen worden ist, wo

Geschäftsvorschlag!!!

-- Geschäftsvorschlag!!! Ich vermute das diese E-Mail eine Überraschung für Sie sein wird, aber es ist wahr.Ich bin bei einer routinen Überprüfung in meiner Bank (First National Bank von Süd Afrika) wo ich arbeite, auf einem Konto gestoßen, was nicht in anspruch genommen worden ist, wo

[PATCH] USB: OHCI: make ohci-da8xx a separate driver

From: Manjunath Goudar Separate the Davinci OHCI host controller driver from ohci-hcd host code so that it can be built as a separate driver module. This work is part of enabling multi-platform kernels on ARM Signed-off-by: Manjunath Goudar

[PATCH] USB: OHCI: make ohci-da8xx a separate driver

From: Manjunath Goudar Separate the Davinci OHCI host controller driver from ohci-hcd host code so that it can be built as a separate driver module. This work is part of enabling multi-platform kernels on ARM Signed-off-by: Manjunath Goudar [Axel: adapted and rebased, fixed minor comments]

Re: [PATCH] mcp3021: rework for DT support of reference-voltage

On Wed, Oct 19, 2016 at 12:44:44AM +0200, Clemens Gruber wrote: > Support setting the reference voltage in the device tree. > Rework of driver structure, put chip specific data in a separate > structure and assign it depending on device id from platform data or > DT match. > Extend the device

Re: [PATCH] mcp3021: rework for DT support of reference-voltage

On Wed, Oct 19, 2016 at 12:44:44AM +0200, Clemens Gruber wrote: > Support setting the reference voltage in the device tree. > Rework of driver structure, put chip specific data in a separate > structure and assign it depending on device id from platform data or > DT match. > Extend the device

Re: [RFC 1/2] mmc: sdhci: dt: Add device tree property sdhci-cap-speed-modes-broken

On Tue, Oct 18, 2016 at 04:05:35PM -0500, Zach Brown wrote: > On some systems the sdhci capabilty registers are incorrect for one > reason or another. > > The sdhci-cap-speed-modes-broken property will let the driver know that > the sdhci capability registers should not be relied on for speed

Re: [RFC 1/2] mmc: sdhci: dt: Add device tree property sdhci-cap-speed-modes-broken

On Tue, Oct 18, 2016 at 04:05:35PM -0500, Zach Brown wrote: > On some systems the sdhci capabilty registers are incorrect for one > reason or another. > > The sdhci-cap-speed-modes-broken property will let the driver know that > the sdhci capability registers should not be relied on for speed

Re: CONFIG_VMAP_STACK, on-stack struct, and wake_up_bit

- Original Message - | On Wed, Oct 26, 2016 at 11:04 AM, Bob Peterson wrote: | > | > I can test it for you, if you give me about an hour. | | I can definitely wait an hour, it would be lovely to see more testing. | Especially if you have a NUMA machine and an

Re: CONFIG_VMAP_STACK, on-stack struct, and wake_up_bit

- Original Message - | On Wed, Oct 26, 2016 at 11:04 AM, Bob Peterson wrote: | > | > I can test it for you, if you give me about an hour. | | I can definitely wait an hour, it would be lovely to see more testing. | Especially if you have a NUMA machine and an interesting workload. | |

Re: [PATCH 4/5] misc: sgi-gru: print a hex number after a 0x prefix

On Wed, Oct 26, 2016 at 02:56:57PM +0200, Uwe Kleine-König wrote: > It makes the result hard to interpret correctly if a base 10 number is > prefixed by 0x. So change to a hex number. > Would like to have this be a decimal number. Signed-off-by: Dimitri Sivanich ---

Re: [PATCH 4/5] misc: sgi-gru: print a hex number after a 0x prefix

On Wed, Oct 26, 2016 at 02:56:57PM +0200, Uwe Kleine-König wrote: > It makes the result hard to interpret correctly if a base 10 number is > prefixed by 0x. So change to a hex number. > Would like to have this be a decimal number. Signed-off-by: Dimitri Sivanich ---

[PATCH v3] Input: synaptics-rmi4 - stop scanning PDT after two empty pages

We have encountered some RMI4 firmwares where there are blank pages in between PDT pages which contain functions. This change makes them correctly enumerate all functions on the device. Tested on S7817 (has empty page 2). Signed-off-by: Nick Dyer [Tested successfully on

[PATCH v3] Input: synaptics-rmi4 - stop scanning PDT after two empty pages

We have encountered some RMI4 firmwares where there are blank pages in between PDT pages which contain functions. This change makes them correctly enumerate all functions on the device. Tested on S7817 (has empty page 2). Signed-off-by: Nick Dyer [Tested successfully on S7817 and S7300

Re: Device or HBA level QD throttling creates randomness in sequetial workload

On Tue, Oct 25, 2016 at 12:24:24AM +0530, Kashyap Desai wrote: > > -Original Message- > > From: Omar Sandoval [mailto:osan...@osandov.com] > > Sent: Monday, October 24, 2016 9:11 PM > > To: Kashyap Desai > > Cc: linux-s...@vger.kernel.org; linux-kernel@vger.kernel.org; linux- > >

Re: Device or HBA level QD throttling creates randomness in sequetial workload

On Tue, Oct 25, 2016 at 12:24:24AM +0530, Kashyap Desai wrote: > > -Original Message- > > From: Omar Sandoval [mailto:osan...@osandov.com] > > Sent: Monday, October 24, 2016 9:11 PM > > To: Kashyap Desai > > Cc: linux-s...@vger.kernel.org; linux-kernel@vger.kernel.org; linux- > >

Getting interrupt every million cache misses

Hi! I'd like to get an interrupt every million cache misses... to do a printk() or something like that. As far as I can tell, modern hardware should allow me to do that. AFAICT performance events subsystem can do something like that, but I can't figure out where the code is / what I should call.

Getting interrupt every million cache misses

Hi! I'd like to get an interrupt every million cache misses... to do a printk() or something like that. As far as I can tell, modern hardware should allow me to do that. AFAICT performance events subsystem can do something like that, but I can't figure out where the code is / what I should call.

[PATCH 4/8] writeback: track if we're sleeping on progress in balance_dirty_pages()

Note in the bdi_writeback structure whenever a task ends up sleeping waiting for progress. We can use that information in the lower layers to increase the priority of writes. Signed-off-by: Jens Axboe --- include/linux/backing-dev-defs.h | 2 ++ mm/backing-dev.c |

[PATCH 2/8] writeback: add wbc_to_write_flags()

Add wbc_to_write_flags(), which returns the write modifier flags to use, based on a struct writeback_control. No functional changes in this patch, but it prepares us for factoring other wbc fields for write type. Signed-off-by: Jens Axboe Reviewed-by: Jan Kara ---

[PATCH 4/8] writeback: track if we're sleeping on progress in balance_dirty_pages()

Note in the bdi_writeback structure whenever a task ends up sleeping waiting for progress. We can use that information in the lower layers to increase the priority of writes. Signed-off-by: Jens Axboe --- include/linux/backing-dev-defs.h | 2 ++ mm/backing-dev.c | 1 +

[PATCH 2/8] writeback: add wbc_to_write_flags()

Add wbc_to_write_flags(), which returns the write modifier flags to use, based on a struct writeback_control. No functional changes in this patch, but it prepares us for factoring other wbc fields for write type. Signed-off-by: Jens Axboe Reviewed-by: Jan Kara --- fs/buffer.c | 2

[PATCH 3/8] writeback: use WRITE_BG for kupdate and background writeback

If we're doing background type writes, then use the appropriate write command for that. Signed-off-by: Jens Axboe --- include/linux/writeback.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/linux/writeback.h b/include/linux/writeback.h index

[PATCH 5/8] block: add code to track actual device queue depth

For blk-mq, ->nr_requests does track queue depth, at least at init time. But for the older queue paths, it's simply a soft setting. On top of that, it's generally larger than the hardware setting on purpose, to allow backup of requests for merging. Fill a hole in struct request with a

[PATCH 3/8] writeback: use WRITE_BG for kupdate and background writeback

If we're doing background type writes, then use the appropriate write command for that. Signed-off-by: Jens Axboe --- include/linux/writeback.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/linux/writeback.h b/include/linux/writeback.h index 78b87c517b5f..f12f0b34daca 100644 ---

[PATCH 5/8] block: add code to track actual device queue depth

For blk-mq, ->nr_requests does track queue depth, at least at init time. But for the older queue paths, it's simply a soft setting. On top of that, it's generally larger than the hardware setting on purpose, to allow backup of requests for merging. Fill a hole in struct request with a

[PATCH 6/8] block: add scalable completion tracking of requests

For legacy block, we simply track them in the request queue. For blk-mq, we track them on a per-sw queue basis, which we can then sum up through the hardware queues and finally to a per device state. The stats are tracked in, roughly, 0.1s interval windows. Add sysfs files to display the stats.

[PATCH 6/8] block: add scalable completion tracking of requests

For legacy block, we simply track them in the request queue. For blk-mq, we track them on a per-sw queue basis, which we can then sum up through the hardware queues and finally to a per device state. The stats are tracked in, roughly, 0.1s interval windows. Add sysfs files to display the stats.

[PATCH 8/8] block: hook up writeback throttling

Enable throttling of buffered writeback to make it a lot more smooth, and has way less impact on other system activity. Background writeback should be, by definition, background activity. The fact that we flush huge bundles of it at the time means that it potentially has heavy impacts on

[PATCH 1/8] block: add WRITE_BG

This adds a new request flag, REQ_BG, that callers can use to tell the block layer that this is background (non-urgent) IO. Signed-off-by: Jens Axboe --- include/linux/blk_types.h | 4 +++- include/linux/fs.h| 3 +++ 2 files changed, 6 insertions(+), 1 deletion(-) diff

[PATCH 7/8] blk-wbt: add general throttling mechanism

We can hook this up to the block layer, to help throttle buffered writes. wbt registers a few trace points that can be used to track what is happening in the system: wbt_lat: 259:0: latency 2446318 wbt_stat: 259:0: rmean=2446318, rmin=2446318, rmax=2446318, rsamples=1,

[PATCH 8/8] block: hook up writeback throttling

Enable throttling of buffered writeback to make it a lot more smooth, and has way less impact on other system activity. Background writeback should be, by definition, background activity. The fact that we flush huge bundles of it at the time means that it potentially has heavy impacts on

[PATCH 1/8] block: add WRITE_BG

This adds a new request flag, REQ_BG, that callers can use to tell the block layer that this is background (non-urgent) IO. Signed-off-by: Jens Axboe --- include/linux/blk_types.h | 4 +++- include/linux/fs.h| 3 +++ 2 files changed, 6 insertions(+), 1 deletion(-) diff --git

[PATCH 7/8] blk-wbt: add general throttling mechanism

We can hook this up to the block layer, to help throttle buffered writes. wbt registers a few trace points that can be used to track what is happening in the system: wbt_lat: 259:0: latency 2446318 wbt_stat: 259:0: rmean=2446318, rmin=2446318, rmax=2446318, rsamples=1,

[PATCHSET] block: buffered writeback throttling

Since the dawn of time, our background buffered writeback has sucked. When we do background buffered writeback, it should have little impact on foreground activity. That's the definition of background activity... But for as long as I can remember, heavy buffered writers have not behaved like that.

[PATCHSET] block: buffered writeback throttling

Since the dawn of time, our background buffered writeback has sucked. When we do background buffered writeback, it should have little impact on foreground activity. That's the definition of background activity... But for as long as I can remember, heavy buffered writers have not behaved like that.

[PATCH 2/2] KVM: x86: save one bit in ctxt->d

Alignments are exclusive, so 5 modes can be expressed in 3 bits. Signed-off-by: Radim Krčmář --- arch/x86/kvm/emulate.c | 23 +-- 1 file changed, 13 insertions(+), 10 deletions(-) diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c index

[PATCH 2/2] KVM: x86: save one bit in ctxt->d

Alignments are exclusive, so 5 modes can be expressed in 3 bits. Signed-off-by: Radim Krčmář --- arch/x86/kvm/emulate.c | 23 +-- 1 file changed, 13 insertions(+), 10 deletions(-) diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c index f360876d6b7f..8fe2dbfb6338

[PATCH 0/2] KVM: x86: emulate fxsave and fxrstor

[1/2] adds the emulation (and could be split into two patches if you'd like), [2/2] just refactors the code. This should fix an issue that users are hitting. Laszlo found several reports: - https://bugs.launchpad.net/qemu/+bug/1623276 - https://bugzilla.proxmox.com/show_bug.cgi?id=1182 -

[PATCH 0/2] KVM: x86: emulate fxsave and fxrstor

[1/2] adds the emulation (and could be split into two patches if you'd like), [2/2] just refactors the code. This should fix an issue that users are hitting. Laszlo found several reports: - https://bugs.launchpad.net/qemu/+bug/1623276 - https://bugzilla.proxmox.com/show_bug.cgi?id=1182 -

[PATCH 1/2] KVM: x86: emulate fxsave and fxrstor

Internal errors were reported on 16 bit fxsave and fxrstor with iPXE. Old Intels don't have unrestricted_guest, so we have to emulate them. The patch takes advantage of the hardware implementation. There should be no problem as long as the buffer is aligned. Signed-off-by: Radim Krčmář

Re: [PATCH 2/3] x86/vmware: Add basic paravirt ops support

On Wed, 26 Oct 2016, Tim Mann wrote: > I believe our trademark guidelines say we aren't supposed to use VMware as a > noun to mean a product, only to mean the company. So we can say "running on > VMware ESXi" or "running in a VMware virtual machine", but "running on VMware" > is wrong. There is

Re: [PATCH 2/3] x86/vmware: Add basic paravirt ops support

On Wed, 26 Oct 2016, Tim Mann wrote: > I believe our trademark guidelines say we aren't supposed to use VMware as a > noun to mean a product, only to mean the company. So we can say "running on > VMware ESXi" or "running in a VMware virtual machine", but "running on VMware" > is wrong. There is

[PATCH 1/2] KVM: x86: emulate fxsave and fxrstor

Internal errors were reported on 16 bit fxsave and fxrstor with iPXE. Old Intels don't have unrestricted_guest, so we have to emulate them. The patch takes advantage of the hardware implementation. There should be no problem as long as the buffer is aligned. Signed-off-by: Radim Krčmář ---

Re: [PATCH v1] memcg: Prevent caches to be both OFF_SLAB & OBJFREELIST_SLAB

On Wed, 26 Oct 2016, Thomas Garnier wrote: > Okay, I think for SLAB we can allow everything except the two flags > mentioned here. No no no. Just allow the flags already defined in include/linux/slab.h that can be specd by subsystems when they call into the slab allocators. > Should I deny

Re: [PATCH v1] memcg: Prevent caches to be both OFF_SLAB & OBJFREELIST_SLAB

On Wed, 26 Oct 2016, Thomas Garnier wrote: > Okay, I think for SLAB we can allow everything except the two flags > mentioned here. No no no. Just allow the flags already defined in include/linux/slab.h that can be specd by subsystems when they call into the slab allocators. > Should I deny

Re: [PATCH 2/3] x86/vmware: Add basic paravirt ops support

I believe our trademark guidelines say we aren't supposed to use VMware as a noun to mean a product, only to mean the company. So we can say "running on VMware ESXi" or "running in a VMware virtual machine", but "running on VMware" is wrong. There is supposedly some good legal reason for this

Re: [PATCH 2/3] x86/vmware: Add basic paravirt ops support

I believe our trademark guidelines say we aren't supposed to use VMware as a noun to mean a product, only to mean the company. So we can say "running on VMware ESXi" or "running in a VMware virtual machine", but "running on VMware" is wrong. There is supposedly some good legal reason for this

Re: [PATCH v5 06/18] x86/intel_rdt: Add CONFIG, Makefile, and basic initialization

On Sat, 22 Oct 2016, Fenghua Yu wrote: > +config INTEL_RDT_A > + bool "Intel Resource Director Technology Allocation support" > + default n > + depends on X86 && CPU_SUP_INTEL depends on X86 is more than pointless for a config switch which sits in the arch/x86/Kconfig file

Re: [PATCH v5 06/18] x86/intel_rdt: Add CONFIG, Makefile, and basic initialization

On Sat, 22 Oct 2016, Fenghua Yu wrote: > +config INTEL_RDT_A > + bool "Intel Resource Director Technology Allocation support" > + default n > + depends on X86 && CPU_SUP_INTEL depends on X86 is more than pointless for a config switch which sits in the arch/x86/Kconfig file

Re: [PATCH 3/5] PCI: Extract link retraining from pcie_aspm_configure_common_clock()

On Wed, 26 Oct 2016 12:01:28 -0600 Alex Williamson wrote: > Signed-off-by: Alex Williamson > --- > drivers/pci/pci.c | 29 + > drivers/pci/pcie/aspm.c | 17 + > include/linux/pci.h

Re: [PATCH 3/5] PCI: Extract link retraining from pcie_aspm_configure_common_clock()

On Wed, 26 Oct 2016 12:01:28 -0600 Alex Williamson wrote: > Signed-off-by: Alex Williamson > --- > drivers/pci/pci.c | 29 + > drivers/pci/pcie/aspm.c | 17 + > include/linux/pci.h |1 + > 3 files changed, 31 insertions(+), 16

[PATCH] [media] smiapp: make PM functions as __maybe_unused

The rework of the PM support has caused two functions to be orphaned when CONFIG_PM is disabled: media/i2c/smiapp/smiapp-core.c:1352:12: error: 'smiapp_power_off' defined but not used [-Werror=unused-function] media/i2c/smiapp/smiapp-core.c:1206:12: error: 'smiapp_power_on' defined but not used

[PATCH] [media] smiapp: make PM functions as __maybe_unused

The rework of the PM support has caused two functions to be orphaned when CONFIG_PM is disabled: media/i2c/smiapp/smiapp-core.c:1352:12: error: 'smiapp_power_off' defined but not used [-Werror=unused-function] media/i2c/smiapp/smiapp-core.c:1206:12: error: 'smiapp_power_on' defined but not used

Re: [RFC v1 00/14] Bus1 Kernel Message Bus

Hi On Wed, Oct 26, 2016 at 9:39 PM, Linus Torvalds wrote: > So the thing that tends to worry me about these is resource management. > > If I understood the documentation correctly, this has per-user > resource management, which guarantees that at least the system

Re: [RFC v1 00/14] Bus1 Kernel Message Bus

Hi On Wed, Oct 26, 2016 at 9:39 PM, Linus Torvalds wrote: > So the thing that tends to worry me about these is resource management. > > If I understood the documentation correctly, this has per-user > resource management, which guarantees that at least the system won't > run out of memory. Good.

[PATCH 1/2] backlight: arcxcnn: add support for ArticSand devices

Resubmition of arcxcnn backliught driver adding devicetree entries for all registers Signed-off-by: Olimpiu Dejeu --- drivers/video/backlight/Kconfig | 7 + drivers/video/backlight/Makefile | 1 + drivers/video/backlight/arcxcnn_bl.c | 541

Re: [PATCH 4/5] KVM: x86: remove unnecessary sync_pir_to_irr

2016-10-14 20:21+0200, Paolo Bonzini: > Synchronizing PIR to IRR is not needed in most callers of > apic_find_highest_irr. Move it to the one place that matters, > interrupt acknowledgement. > > Signed-off-by: Paolo Bonzini > --- Reviewed-by: Radim Krčmář

[PATCH 1/2] backlight: arcxcnn: add support for ArticSand devices

Resubmition of arcxcnn backliught driver adding devicetree entries for all registers Signed-off-by: Olimpiu Dejeu --- drivers/video/backlight/Kconfig | 7 + drivers/video/backlight/Makefile | 1 + drivers/video/backlight/arcxcnn_bl.c | 541 +++

Re: [PATCH 4/5] KVM: x86: remove unnecessary sync_pir_to_irr

2016-10-14 20:21+0200, Paolo Bonzini: > Synchronizing PIR to IRR is not needed in most callers of > apic_find_highest_irr. Move it to the one place that matters, > interrupt acknowledgement. > > Signed-off-by: Paolo Bonzini > --- Reviewed-by: Radim Krčmář > diff --git a/arch/x86/kvm/lapic.c

Re: [PATCH v2 04/10] phy: qcom-ufs-qmp-xx: Discard remove callback for drivers.

On Tuesday 18 October 2016 07:58 PM, Vivek Gautam wrote: > remove() callback does a phy_exit() only and nothing else now. remove callback calls a phy_power_off() ;-) -Kishon > The phy_exit() over the generic phy is called from the phy > consumer, and phy provider driver should not explicitly

Re: [PATCH v2 04/10] phy: qcom-ufs-qmp-xx: Discard remove callback for drivers.

On Tuesday 18 October 2016 07:58 PM, Vivek Gautam wrote: > remove() callback does a phy_exit() only and nothing else now. remove callback calls a phy_power_off() ;-) -Kishon > The phy_exit() over the generic phy is called from the phy > consumer, and phy provider driver should not explicitly

Re: CONFIG_VMAP_STACK, on-stack struct, and wake_up_bit

On Wed, Oct 26, 2016 at 10:15:30AM -0700, Linus Torvalds wrote: > On Wed, Oct 26, 2016 at 9:32 AM, Linus Torvalds > wrote: > > > > Quite frankly, I think the solution is to just rip out all the insane > > zone crap. > > IOW, something like the attached. > >

Re: CONFIG_VMAP_STACK, on-stack struct, and wake_up_bit

On Wed, Oct 26, 2016 at 10:15:30AM -0700, Linus Torvalds wrote: > On Wed, Oct 26, 2016 at 9:32 AM, Linus Torvalds > wrote: > > > > Quite frankly, I think the solution is to just rip out all the insane > > zone crap. > > IOW, something like the attached. > > Advantage: > > - just look at the

selinux: should execmem disable shmat(..., SHM_EXEC)?

Hi, Maybe this is a stupid question and I didn't test this with SELinux, but it looks to me that SELinux execmem does not prevent process from getting writable and executable memory mappings by using shmat(..., SHM_EXEC). Shouldn't this be blocked by execmem, I suppose it is there to prevent this

selinux: should execmem disable shmat(..., SHM_EXEC)?

Hi, Maybe this is a stupid question and I didn't test this with SELinux, but it looks to me that SELinux execmem does not prevent process from getting writable and executable memory mappings by using shmat(..., SHM_EXEC). Shouldn't this be blocked by execmem, I suppose it is there to prevent this

[PATCH 2/2] backlight: arcxcnn: devicetree bindings for ArticSand devices

Resubmition of arcxcnn backliught driver bindings with added register documentation Signed-off-by: Olimpiu Dejeu --- .../bindings/leds/backlight/arcxcnn_bl.txt | 31 ++ 1 file changed, 31 insertions(+) create mode 100644

[PATCH 2/2] backlight: arcxcnn: devicetree bindings for ArticSand devices

Resubmition of arcxcnn backliught driver bindings with added register documentation Signed-off-by: Olimpiu Dejeu --- .../bindings/leds/backlight/arcxcnn_bl.txt | 31 ++ 1 file changed, 31 insertions(+) create mode 100644

Re: [PATCH v2 5/5] posix-timers: make it configurable

On Wed, Oct 26, 2016 at 09:56:13AM -0400, Nicolas Pitre wrote: > So if my Fedora usage doesn't need them, we can infer that > the number of embedded systems also not needing them might tend towards > a high percentage. (I wouldn't call Fedora an embedded distro, but heh...) > But let's be

Re: [PATCH v2 5/5] posix-timers: make it configurable

On Wed, Oct 26, 2016 at 09:56:13AM -0400, Nicolas Pitre wrote: > So if my Fedora usage doesn't need them, we can infer that > the number of embedded systems also not needing them might tend towards > a high percentage. (I wouldn't call Fedora an embedded distro, but heh...) > But let's be

Re: [kernel-hardening] [RFC v4 03/18] bpf,landlock: Add a new arraymap type to deal with (Landlock) handles

On Wed, Oct 26, 2016 at 10:03:09PM +0200, Mickaël Salaün wrote: > On 26/10/2016 21:01, Jann Horn wrote: > > On Wed, Oct 26, 2016 at 08:56:39AM +0200, Mickaël Salaün wrote: > >> This new arraymap looks like a set and brings new properties: > >> * strong typing of entries: the eBPF functions get the

Re: [kernel-hardening] [RFC v4 03/18] bpf,landlock: Add a new arraymap type to deal with (Landlock) handles

On Wed, Oct 26, 2016 at 10:03:09PM +0200, Mickaël Salaün wrote: > On 26/10/2016 21:01, Jann Horn wrote: > > On Wed, Oct 26, 2016 at 08:56:39AM +0200, Mickaël Salaün wrote: > >> This new arraymap looks like a set and brings new properties: > >> * strong typing of entries: the eBPF functions get the

[3.7 M USD Deposit+

Hello Sir/Madam, You have been Chosen to benefit from Susanne Klatten 50M Philanthropic Donation. Contact: charityanddonat...@aol.de

[3.7 M USD Deposit+

Hello Sir/Madam, You have been Chosen to benefit from Susanne Klatten 50M Philanthropic Donation. Contact: charityanddonat...@aol.de

Re: [PATCH] ARM: davinci: register the usb20_phy clock on the DT file

On 10/26/2016 03:05 PM, Axel Haslam wrote: On Wed, Oct 26, 2016 at 10:03 PM, David Lechner wrote: On 10/26/2016 03:01 PM, David Lechner wrote: On 10/26/2016 02:49 PM, ahas...@baylibre.com wrote: From: Axel Haslam The usb20_phy clock needs to be

[PATCH 8/9] mfd: wm97xx-core: core support for wm97xx Codec

The WM9705, WM9712 and WM9713 are highly integrated codecs, with an audio codec, DAC and ADC, GPIO unit and a touchscreen interface. Historically the support was spread across drivers/input/touchscreen and sound/soc/codecs. The sharing was done through ac97 bus sharing. This model will not

Re: [PATCH] ARM: davinci: register the usb20_phy clock on the DT file

On Wed, Oct 26, 2016 at 10:03 PM, David Lechner wrote: > On 10/26/2016 03:01 PM, David Lechner wrote: >> >> On 10/26/2016 02:49 PM, ahas...@baylibre.com wrote: >>> >>> From: Axel Haslam >>> >>> The usb20_phy clock needs to be registered for the driver

[PATCH 8/9] mfd: wm97xx-core: core support for wm97xx Codec

The WM9705, WM9712 and WM9713 are highly integrated codecs, with an audio codec, DAC and ADC, GPIO unit and a touchscreen interface. Historically the support was spread across drivers/input/touchscreen and sound/soc/codecs. The sharing was done through ac97 bus sharing. This model will not

Re: [PATCH] ARM: davinci: register the usb20_phy clock on the DT file

On Wed, Oct 26, 2016 at 10:03 PM, David Lechner wrote: > On 10/26/2016 03:01 PM, David Lechner wrote: >> >> On 10/26/2016 02:49 PM, ahas...@baylibre.com wrote: >>> >>> From: Axel Haslam >>> >>> The usb20_phy clock needs to be registered for the driver to be able >>> to get and enable a clock.

Re: [PATCH] ARM: davinci: register the usb20_phy clock on the DT file

On 10/26/2016 03:05 PM, Axel Haslam wrote: On Wed, Oct 26, 2016 at 10:03 PM, David Lechner wrote: On 10/26/2016 03:01 PM, David Lechner wrote: On 10/26/2016 02:49 PM, ahas...@baylibre.com wrote: From: Axel Haslam The usb20_phy clock needs to be registered for the driver to be able to get

[PATCH 7/9] Input: wm97xx: split out touchscreen registering

wm97xx-core does several things in it initialization : - touchscreen input device setup - battery device creation As the wm97xx is actually a multi-function device handling an audio codec, a touchscreen, a gpio block and an ADC, reshape the probing to isolate what is truly input/touchscreen

[PATCH 7/9] Input: wm97xx: split out touchscreen registering

wm97xx-core does several things in it initialization : - touchscreen input device setup - battery device creation As the wm97xx is actually a multi-function device handling an audio codec, a touchscreen, a gpio block and an ADC, reshape the probing to isolate what is truly input/touchscreen

Re: [PATCH] phy: Add reset callback for not generic phy

On Wednesday 26 October 2016 02:17 AM, John Youn wrote: > On 10/25/2016 7:15 AM, Randy Li wrote: >> I forget to add a dummy function in case the CONFIG_GENERIC_PHY >> is disabled. >> >> Signed-off-by: Randy Li > > Fixes: cac18ecb6f44 ("phy: Add reset callback") > Tested-by:

Re: [PATCH 2/2] phy: qcom-qmp: new qmp phy driver for qcom-chipsets

Hi, On Wednesday 19 October 2016 04:13 PM, Vivek Gautam wrote: > Qualcomm SOCs have QMP phy controller that provides support > to a number of controller, viz. PCIe, UFS, and USB. > Add a new driver, based on generic phy framework, for this > phy controller. > > USB3-phy changes: Based on

Re: [PATCH 5/5] KVM: vmx: clear pending interrupts on KVM_SET_LAPIC

2016-10-14 20:21+0200, Paolo Bonzini: > Pending interrupts might be in the PI descriptor when the > LAPIC is restored from an external state; we do not want > them to be injected. > > Signed-off-by: Paolo Bonzini > --- Reviewed-by: Radim Krčmář

Re: [PATCH] phy: Add reset callback for not generic phy

On Wednesday 26 October 2016 02:17 AM, John Youn wrote: > On 10/25/2016 7:15 AM, Randy Li wrote: >> I forget to add a dummy function in case the CONFIG_GENERIC_PHY >> is disabled. >> >> Signed-off-by: Randy Li > > Fixes: cac18ecb6f44 ("phy: Add reset callback") > Tested-by: John Youn > > Hi

Re: [PATCH 2/2] phy: qcom-qmp: new qmp phy driver for qcom-chipsets

Hi, On Wednesday 19 October 2016 04:13 PM, Vivek Gautam wrote: > Qualcomm SOCs have QMP phy controller that provides support > to a number of controller, viz. PCIe, UFS, and USB. > Add a new driver, based on generic phy framework, for this > phy controller. > > USB3-phy changes: Based on

Re: [PATCH 5/5] KVM: vmx: clear pending interrupts on KVM_SET_LAPIC

2016-10-14 20:21+0200, Paolo Bonzini: > Pending interrupts might be in the PI descriptor when the > LAPIC is restored from an external state; we do not want > them to be injected. > > Signed-off-by: Paolo Bonzini > --- Reviewed-by: Radim Krčmář

Re: [PATCH] lib/ida: Document locking requirements a bit better

Hello, Daniel. On Wed, Oct 26, 2016 at 09:25:25PM +0200, Daniel Vetter wrote: > > > + * Note that callers must ensure that concurrent access to @ida is not > > > possible. > > > + * When simplicity trumps concurrency needs look at ida_simple_get() > > > instead. > > > > Maybe we can make it a

Re: [PATCH] lib/ida: Document locking requirements a bit better

Hello, Daniel. On Wed, Oct 26, 2016 at 09:25:25PM +0200, Daniel Vetter wrote: > > > + * Note that callers must ensure that concurrent access to @ida is not > > > possible. > > > + * When simplicity trumps concurrency needs look at ida_simple_get() > > > instead. > > > > Maybe we can make it a

Re: [PATCH 3/5] KVM: x86: do not use KVM_REQ_EVENT for APICv interrupt injection

2016-10-14 20:21+0200, Paolo Bonzini: > Since bf9f6ac8d749 ("KVM: Update Posted-Interrupts Descriptor when vCPU > is blocked", 2015-09-18) the posted interrupt descriptor is checked > unconditionally for PIR.ON. Therefore we don't need KVM_REQ_EVENT to > trigger the scan and, if NMIs or SMIs are

Re: [PATCH 3/5] KVM: x86: do not use KVM_REQ_EVENT for APICv interrupt injection

2016-10-14 20:21+0200, Paolo Bonzini: > Since bf9f6ac8d749 ("KVM: Update Posted-Interrupts Descriptor when vCPU > is blocked", 2015-09-18) the posted interrupt descriptor is checked > unconditionally for PIR.ON. Therefore we don't need KVM_REQ_EVENT to > trigger the scan and, if NMIs or SMIs are

<    1   2   3   4   5   6   7   8   9   10   >