Hi Sean,
> Andi, it would be good to know what the use-case for the original change is.
the use case is the ir-spi itself which doesn't need the lirc to
perform any waiting on its behalf.
To me it just doesn't look right to simulate a fake transmission
period and wait unnecessary time. Of course
'i2c_new_dummy()' does not return an error pointer, so the test can be
simplified to be more consistent.
Signed-off-by: Christophe JAILLET
---
drivers/mfd/bcm590xx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mfd/bcm590xx.c b/drivers/mfd/bcm590xx.c
index 0d76d690
'ubifs_fast_find_freeable()' can not return an error pointer, so this test
can be removed.
Signed-off-by: Christophe JAILLET
---
fs/ubifs/gc.c | 4
1 file changed, 4 deletions(-)
diff --git a/fs/ubifs/gc.c b/fs/ubifs/gc.c
index e845c64b6ce1..7b35e3d6cde7 100644
--- a/fs/ubifs/gc.c
+++ b/fs
Hi,
On 1.11.2016 00:54, Sakari Ailus wrote:
Hi Pavel,
On Sun, Oct 23, 2016 at 10:33:15PM +0200, Pavel Machek wrote:
Hi!
Thanks, this answered half of my questions already. ;-)
:-).
I'll have to go through the patches, et8ek8 driver is probably not
enough to get useful video. platform/vid
* Pavel Machek wrote:
> I'm not going to buy broken hardware just for a test.
Can you suggest a method to find heavily rowhammer affected hardware? Only by
testing it, or are there some chipset IDs ranges or dmidecode info that will
pinpoint potentially affected machines?
Thanks,
In
In the current probe function the GPIO is acquired after the codec's
bus clock is enabled. However if it fails to acquire the GPIO due to
a deferred probe, it does not disable the bus clock before bailing out.
This would result in the clock being enabled multiple times.
Move the code that enables
>From: Mika Westerberg
>Subject: Re: [RFC v2 2/2] i2c: Pass i2c_device_id to probe func when
using DT ids through ACPI
>Date: Monday 13th June 2016 09:26:55 UTC (5 months ago)
>
>On Fri, Jun 10, 2016 at 06:57:36PM +0300, Crestez Dan Leonard wrote:
>> On 06/10/2016 09:32 AM, Mika Westerberg wrote:
On Mon, Oct 31, 2016 at 10:25 PM, Rafael J. Wysocki wrote:
> On Thursday, October 27, 2016 09:05:34 AM Brian Norris wrote:
>> Consider two devices, A and B, where B is a child of A, and B utilizes
>> asynchronous suspend (it does not matter whether A is sync or async). If
>> B fails to suspend_noi
Hi Sascha,
> The current assumption as discussed by Philipp and me is that the ipg
> clk is only needed when the pwm output is driven by the ipg clk
> (MX3_PWMCR[16:17] = MX3_PWMCR_CLKSRC_IPG)
At least on my setup (i.MX6q) the ipg clock (ipg_clk) don't need to be
explicitly enabled in the ->apply
Instead of just delaying for 100us, we should
actually wait for End Transfer Command Complete
interrupt before moving on. Note that this should
only be done if we're dealing with one of the core
revisions that actually require the interrupt before
moving on.
[ felipe.ba...@linux.intel.com: minor i
Jens- Replied inline.
Omar - I tested your WIP repo and figure out System hangs only if I pass "
scsi_mod.use_blk_mq=Y". Without this, your WIP branch works fine, but I am
looking for scsi_mod.use_blk_mq=Y.
Also below is snippet of blktrace. In case of higher per device QD, I see
Requeue reques
On 11/01/16 at 01:10pm, Dave Young wrote:
> On 10/06/16 at 04:46pm, Baoquan He wrote:
> > KASLR memory randomization can randomize the base of the physical memory
> > mapping (PAGE_OFFSET), vmalloc (VMALLOC_START) and vmemmap
> > (VMEMMAP_START). These need be exported to VMCOREINFO so that user sp
Dear friends, I have problem booting my custom HW (around s5pv210 SoC)
using the latest stable kernel release (v4.8.5). Of course this is the first DT
based kernel I'm trying to boot with in this HW. I chose s5pv210_defconfig and
by checking CONFIG_ARM_APPENDED_DTB, appended the DTB (s5pv210-smdk
On 11/01/2016 11:44 AM, Alex Williamson wrote:
> On Tue, 01 Nov 2016 11:08:15 +0800
> Jike Song wrote:
>> On 10/27/2016 05:29 AM, Kirti Wankhede wrote:
>>> +static int mdev_attach_iommu(struct mdev_device *mdev)
>>> +{
>>> + int ret;
>>> + struct iommu_group *group;
>>> +
>>> + group = iommu
David Miller writes:
> From: Kalle Valo
> Date: Sun, 30 Oct 2016 11:20:46 +0200
>
>> few fixes for 4.9. I tagged this on the plane over a slow mosh
>> connection while travelling to Plumbers so I might have done something
>> wrong, please check more carefully than usually. For example I had to
>
Hi Rafael,
On Tue, Nov 01, 2016 at 05:25:39AM +0100, Rafael J. Wysocki wrote:
> On Thursday, October 27, 2016 09:05:34 AM Brian Norris wrote:
> > diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
> > index c58563581345..eaf6b53463a5 100644
> > --- a/drivers/base/power/main.c
> > +
On 10/06/16 at 04:46pm, Baoquan He wrote:
> KASLR memory randomization can randomize the base of the physical memory
> mapping (PAGE_OFFSET), vmalloc (VMALLOC_START) and vmemmap
> (VMEMMAP_START). These need be exported to VMCOREINFO so that user space
> utility, mainly makedumpfile can use them to
From: Stephen Hemminger
In commit 9a56e5d6a0ba ("Drivers: hv: make VMBus bus ids persistent")
the name of vmbus devices in sysfs changed to be (in 4.9-rc1):
/sys/bus/vmbus/vmbus-6aebe374-9ba0-11e6-933c-00259086b36b
The prefix ("vmbus-") is redundant and differs from how PCI is
represented in s
This patch add dbc debug device support in usb_debug driver.
Signed-off-by: Lu Baolu
Acked-by: Johan Hovold
---
drivers/usb/serial/usb_debug.c | 28 +---
1 file changed, 25 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/serial/usb_debug.c b/drivers/usb/serial/us
Add Documentation/usb/usb3-debug-port.rst. This document includes
the user guide for USB3 debug port.
Cc: linux-...@vger.kernel.org
Signed-off-by: Lu Baolu
---
Documentation/usb/usb3-debug-port.rst | 95 +++
1 file changed, 95 insertions(+)
create mode 100644 Doc
xHCI debug capability (DbC) is an optional but standalone
functionality provided by an xHCI host controller. Software
learns this capability by walking through the extended
capability list of the host. xHCI specification describes
DbC in section 7.6.
This patch introduces the code to probe and ini
xHCI debug capability (DbC) is an optional but standalone
functionality provided by an xHCI host controller. With DbC
hardware initialized, the system will present a debug device
through the USB3 debug port (normally the first USB3 port).
The debug device is fully compliant with the USB framework
a
Add support for early printk by writing debug messages to the
USB3 debug port. Users can use this type of early printk by
specifying kernel parameter of "earlyprintk=xdbc". This gives
users a chance of providing debug output.
The hardware for USB3 debug port requires DMA memory blocks.
This requ
Em Mon, 31 Oct 2016 16:41:48 -0600
Mauro Carvalho Chehab escreveu:
> Em Mon, 31 Oct 2016 16:40:02 -0600
> Mauro Carvalho Chehab escreveu:
>
> > Em Mon, 31 Oct 2016 15:04:42 -0700
> > Jim Davis escreveu:
> >
> > > On Mon, Oct 31, 2016 at 1:58 PM, Mauro Carvalho Chehab
> > > wrote:
> > > > Em
The Lattice iCE40 is a family of FPGAs with a minimalistic architecture
and very regular structure, designed for low-cost, high-volume consumer
and system applications.
This patch adds support to the FPGA manager for configuring the SRAM of
iCE40LM, iCE40LP, iCE40HX, iCE40 Ultra, iCE40 UltraLite a
---
.../bindings/fpga/lattice-ice40-fpga-mgr.txt| 21 +
1 file changed, 21 insertions(+)
create mode 100644
Documentation/devicetree/bindings/fpga/lattice-ice40-fpga-mgr.txt
diff --git a/Documentation/devicetree/bindings/fpga/lattice-ice40-fpga-mgr.txt
b/Documentati
Acked-by: Rob Herring
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 1992aa9..d64a835 100644
--- a/Documentation/devi
The Lattice iCE40 is a family of FPGAs with a minimalistic architecture
and very regular structure, designed for low-cost, high-volume consumer
and system applications.
This patch adds support to the FPGA manager for configuring the SRAM of
iCE40LM, iCE40LP, iCE40HX, iCE40 Ultra, iCE40 UltraLite a
---
.../bindings/fpga/lattice-ice40-fpga-mgr.txt| 21 +
1 file changed, 21 insertions(+)
create mode 100644
Documentation/devicetree/bindings/fpga/lattice-ice40-fpga-mgr.txt
diff --git a/Documentation/devicetree/bindings/fpga/lattice-ice40-fpga-mgr.txt
b/Documentati
Hi David and Jan,
I did more testing on the code. Casting to either (long) or (unsigned long)
would be fine.
However, there is still an issue that ref is of type uint32_t and
IS_ERR_VALUE((unsigned long)ref) would not return true when ref=-ENOSPC (or
other error code).
IS_ERR_VALUE((long)ref) wo
From: Joel Holdsworth
Acked-by: Rob Herring
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 1992aa9..d64a835 100644
On Wednesday, October 26, 2016 01:00:08 PM Pavel Machek wrote:
>
> --zhXaljGHf11kAtnf
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
>
> On Tue 2016-10-25 11:14:40, Kevin Hilman wrote:
> > Colin King writes:
> >=20
> > > F
Sergey Senozhatsky writes:
> On (10/31/16 15:50), Paul Burton wrote:
> [..]
>> Actually whilst this fixes the output in QEMU it has other problems. I'm
>> still
>> digging...
>
> I propose a revert of '05fd007e46296', so you guys can find the
> problem and fix it, not being under 'rc3' pressure.
The accelerometer event relies on on the ACERWMID_EVENT_GUID notify.
So, this patch changes the codes to setup accelerometer input device
when detected ACERWMID_EVENT_GUID. It avoids that the accel input
device created on every acer machines.
In addition, patch adds a clearly parsing logic of acce
The AMW0_GUID1 wmi is not only found on Acer family but also other
machines like Lenovo, Fujitsu and Medion. In the past days, acer-wmi
driver handled those non-Acer machines by quirks list.
But actually acer-wmi driver was loaded on any machines that have
AMW0_GUID1. This behavior is strange beca
On 31/10/16 18:08, David Miller wrote:
> From: Juergen Gross
> Date: Mon, 31 Oct 2016 17:48:18 +0100
>
>> There are multiple instances of code reading an optional unsigned
>> parameter from Xenstore via xenbus_scanf(). Instead of repeating the
>> same code over and over add a service function doi
On Wednesday, October 19, 2016 05:26:09 PM Brian Norris wrote:
> From: Douglas Anderson
>
> The printouts writen to the logs by suspend can be a bit opaque: it can
> be hard to track them down to the actual function called. You might
> see:
>
> calling rfkill1+ @ 19473, parent: phy0
> call
On Thursday, October 27, 2016 09:05:34 AM Brian Norris wrote:
> Consider two devices, A and B, where B is a child of A, and B utilizes
> asynchronous suspend (it does not matter whether A is sync or async). If
> B fails to suspend_noirq() or suspend_late(), or is interrupted by a
> wakeup (pm_wakeu
On Thursday, October 27, 2016 02:05:04 PM Gautham R. Shenoy wrote:
> From: "Gautham R. Shenoy"
>
> Hi,
>
> This is the second iteration of the patchset to use the psscr_val and
> psscr_mask provided by the firmware for each of the stop states.
>
> The previous version can be found here:
> http
On Mon, Oct 31, 2016 at 10:04 AM, Eva Rachel Retuya wrote:
> The name passed to devm_regulator_get() should match the name of the
> supply as specified in the device datasheet. This makes it clear what
> power supply is being referred to in case of presence of other
> regulators.
>
> Currently, th
On Tue, 01 Nov 2016 11:08:15 +0800
Jike Song wrote:
> On 10/27/2016 05:29 AM, Kirti Wankhede wrote:
> > +static int mdev_attach_iommu(struct mdev_device *mdev)
> > +{
> > + int ret;
> > + struct iommu_group *group;
> > +
> > + group = iommu_group_alloc();
> > + if (IS_ERR(group))
> > +
On Monday, October 31, 2016 11:47:03 AM Greg Kroah-Hartman wrote:
> On Sun, Oct 30, 2016 at 05:22:13PM +0100, Rafael J. Wysocki wrote:
> > Hi,
> >
> > Let me quote from the previous intro messages for this series first:
> >
> > > > Time for another update. :-)
> > > >
> > > > Fewer changes this
On Mon, Oct 31, 2016 at 3:00 PM, Peter Hurley wrote:
> On Tue, Oct 25, 2016 at 4:02 PM, Rob Herring wrote:
>>
>> > Maybe you can try to find some minutes at the Kernel Summit to talk
>> > about this?
>>
>> Still waiting for my invite...
>>
>> But I will be at Plumbers if folks want to discuss thi
Hi Mark,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 0c183d92b20b5c84ca655b45ef57b3318b83eb9e
commit: 3ceeda1cbee9f93bb5537c9b840d1f7e767d7c01 Merge remote-tracking branches
'asoc/topic/cs53l30', 'asoc/topic/cyg
Now that we have setters to configure the port's MAC, use them to
refactor the port setup and adjust_link code.
Note that port's MAC speed, duplex or RGMII delay must not be changed
unless the port's link is forced down. So wrap all that in a
mv88e6xxx_port_ctrl_mac function.
Signed-off-by: Vivie
Add functions to port files to access the ports default FID.
Signed-off-by: Vivien Didelot
---
drivers/net/dsa/mv88e6xxx/chip.c | 77 +++-
drivers/net/dsa/mv88e6xxx/port.c | 67 ++
drivers/net/dsa/mv88e6xxx/port.h | 3 ++
3 fil
Usually, the 800MHz and 1GHz are supplied for CPLL and NPLL in the RK3399.
But dues to the carelessly copying from RK3036 when the RK3399 bringing up,
the refdiv == 6, it will increase the lock time, and it is not an optimal
configuration.
Please let's fix them for the lock time and jitter are low
Add the port STP state setter to the port files.
Signed-off-by: Vivien Didelot
---
drivers/net/dsa/mv88e6xxx/chip.c | 49
drivers/net/dsa/mv88e6xxx/port.c | 31 +
drivers/net/dsa/mv88e6xxx/port.h | 2 ++
3 files changed, 37 insert
Add a port function to access the Port Based VLAN Map register.
Signed-off-by: Vivien Didelot
---
drivers/net/dsa/mv88e6xxx/chip.c | 14 ++
drivers/net/dsa/mv88e6xxx/port.c | 25 +
drivers/net/dsa/mv88e6xxx/port.h | 2 ++
3 files changed, 29 insertions(+), 12
The Marvell switches contains one internal SMI device per port, called
"Port Registers". Depending on the model, the addresses of these devices
start from 0x0, 0x8 or 0x10.
Start moving Port Registers specific code to their own files.
Signed-off-by: Vivien Didelot
---
drivers/net/dsa/mv88e6xxx/
Most of the chips will have a port register control bits to force the
port's link up, down, or let normal link detection occurs.
Implement such operation to use it later when setting duplex, etc.
Signed-off-by: Vivien Didelot
---
drivers/net/dsa/mv88e6xxx/chip.c | 17 +
dri
Add port functions to access the ports default VID.
Signed-off-by: Vivien Didelot
---
drivers/net/dsa/mv88e6xxx/chip.c | 51
drivers/net/dsa/mv88e6xxx/port.c | 38 ++
drivers/net/dsa/mv88e6xxx/port.h | 3 +++
3 files changed,
Similarly to port's link, add setter to force port's half duplex, full
duplex or let normal duplex detection occurs.
Signed-off-by: Vivien Didelot
---
drivers/net/dsa/mv88e6xxx/chip.c | 17 +
drivers/net/dsa/mv88e6xxx/mv88e6xxx.h | 7 +++
drivers/net/dsa/mv88e6xxx/port.
Some chips such as 88E6352 and 88E6390 can be programmed to add delays
to RXCLK for IND inputs or to GTXCLK for OUTD outputs when port is in
RGMII mode.
Add a port function to program such delays according to the provided PHY
interface mode.
Signed-off-by: Vivien Didelot
---
drivers/net/dsa/mv8
Add port functions to set the port 802.1Q mode.
Signed-off-by: Vivien Didelot
---
drivers/net/dsa/mv88e6xxx/chip.c | 33 ++---
drivers/net/dsa/mv88e6xxx/port.c | 32
drivers/net/dsa/mv88e6xxx/port.h | 3 +++
3 files changed, 37 insert
While the two bits for link, duplex or RGMII delays are used the same
way on chips supporting the said feature, the two bits for speed have
different meaning for most of the chips out there.
Speed value is stored in bits 1:0, 0x3 means unforce (normal detection).
Some chips reuse values for alter
The Marvell chips have one internal SMI device per port, containing a
set of registers used to configure a port's link, STP state, default
VLAN or addresses database, etc.
This patchset creates port files to implement the port operations as
described in datasheets, and extend the chip ops structur
Hi,
On 31 October 2016 at 20:53, Felipe Balbi wrote:
>
> Hi,
>
> Baolin Wang writes:
>> Instead of just delaying for 100us, we should
>> actually wait for End Transfer Command Complete
>> interrupt before moving on. Note that this should
>> only be done if we're dealing with one of the core
>> r
On 10/27/2016 05:29 AM, Kirti Wankhede wrote:
> Design for Mediated Device Driver:
> Main purpose of this driver is to provide a common interface for mediated
> device management that can be used by different drivers of different
> devices.
>
> This module provides a generic interface to create th
On Tue, 2016-11-01 at 08:15 +1000, John Heenan wrote:
> > On 1 November 2016 at 07:25, Jes Sorensen wrote:
> > > > John Heenan writes:
> > > The rtl8723bu wireless IC shows evidence of a more agressive approach to
> > > power saving, powering down its RF side when there is no wireless
> > > inter
On Mon, Oct 31, 2016 at 2:27 PM, Sean Young wrote:
> On Sun, Oct 30, 2016 at 10:33:02AM -0500, Nathan wrote:
>> I think this should be PNP0501 instead of PNP0c02.
>> Once I alter that then when I boot the serial comes up on irq 3. However it
>> still hangs.
>> I'll keep digging.
>
> Well that's th
On 10/17/16 10:28, Randy Dunlap wrote:
> Boris or Thiago,
>
> Any comments, suggestions, or patches about this?
>
> thanks.
Hi Boris and Thiago,
Other than you patch of Oct. 17 (which needs to be added to linux-kconfig for
linux-next testing), the OP (Jason) mentioned that the xconfig "Help,
I
On Sun, 30 Oct 2016, Jens Axboe wrote:
> On 10/30/2016 08:00 AM, Kent Overstreet wrote:
> > On Sat, Oct 29, 2016 at 06:32:38PM -0700, Eric Wheeler wrote:
> > > On Thu, 27 Oct 2016, Jens Axboe wrote:
> > >
> > > > On 10/27/2016 05:27 PM, Eric Wheeler wrote:
> > > > > Hi Jens,
> > > > >
> > > > > Ple
Hi Matthias,
2016-11-01 6:29 GMT+09:00 Matthias Brugger :
>
>
> On 10/31/2016 07:15 AM, Masahiro Yamada wrote:
>>
>> Hi Matthias,
>>
>>
>> Can you pick up this for your next pull request?
>>
>
> Sure, pushed to v4.9-next/kconfig
>
> Next time please don't forget to send your patches to the mediate
diff --git a/Documentation/x86/exception-tables.txt
b/Documentation/x86/exception-tables.txt
index e396bcd8d830..32901aa36f0a 100644
--- a/Documentation/x86/exception-tables.txt
+++ b/Documentation/x86/exception-tables.txt
@@ -290,38 +290,3 @@ Due to the way that the exception table is built and n
I'm announcing the release of the 4.4.30 kernel. This fixes a bug in
4.4.29 and older kernels by reverting two patches that should not have
been applied.
All users of the 4.4 kernel series must upgrade.
The updated 4.4.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel
On Thu, 2016-10-27 at 14:50 +0800, Ian Kent wrote:
> On Thu, 2016-10-27 at 10:47 +0800, Ian Kent wrote:
> >
> > On Thu, 2016-10-27 at 03:11 +0100, Al Viro wrote:
> > >
> > >
> > >
> > > How much testing did it get? I've several test setups involving
> > > autofs, but they are nowhere near exh
Hi Darren and Greg,
On Mon, Oct 31, 2016 at 03:14:05PM -0700, Darren Hart wrote:
> On Mon, Oct 31, 2016 at 06:21:12PM -0200, Marcos Paulo de Souza wrote:
> > Without this patch, the Asus X45U wireless card can't be turned
> > on (hard-blocked), but after a suspend/resume it just starts working.
>
Without this patch, the Asus X45U wireless card can't be turned
on (hard-blocked), but after a suspend/resume it just starts working.
Following this bug report[1], there are other cases like this one, but
this Asus is the only model that I can test.
[1] https://ubuntuforums.org/showthread.php?t=2
Hook up arch_prctl to call do_arch_prctl on x86-32, and in 32 bit compat
mode on x86-64. This allows us to have arch_prctls that are not specific to
64 bits.
On UML, simply stub out this syscall.
Signed-off-by: Kyle Huey
---
arch/x86/entry/syscalls/syscall_32.tbl | 1 +
arch/x86/kernel/process_
Add do_arch_prctl_common to handle arch_prctls that are not specific to 64
bits. Call it from the syscall entry point, but not any of the other
callsites in the kernel, which all want one of the existing 64 bit only
arch_prctls.
Signed-off-by: Kyle Huey
---
arch/x86/include/asm/proto.h | 1 +
ar
Intel supports faulting on the CPUID instruction beginning with Ivy Bridge.
When enabled, the processor will fault on attempts to execute the CPUID
instruction with CPL>0. Exposing this feature to userspace will allow a
ptracer to trap and emulate the CPUID instruction.
When supported, this featur
Signed-off-by: Kyle Huey
---
arch/x86/kernel/process_64.c | 3 ++-
arch/x86/um/syscalls_64.c| 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c
index b3760b3..2718cf9 100644
--- a/arch/x86/kernel/process_64.c
+++
Intel supports faulting on the CPUID instruction beginning with Ivy Bridge.
When enabled, the processor will fault on attempts to execute the CPUID
instruction with CPL>0. This will allow a ptracer to emulate the CPUID
instruction.
Bit 31 of MSR_PLATFORM_INFO advertises support for this feature. I
Hardware support for faulting on the cpuid instruction is not required to
emulate it, because cpuid triggers a VM exit anyways. KVM handles the relevant
MSRs (MSR_PLATFORM_INFO and MSR_MISC_FEATURES_ENABLE) and upon a
cpuid-induced VM exit checks the cpuid faulting state and the CPL.
kvm_require_cp
In order to introduce new arch_prctls that are not 64 bit only, rename the
existing 64 bit implementation to do_arch_prctl_64. Also rename the second
argument to arch_prctl, which will no longer always be an address.
Signed-off-by: Kyle Huey
Reviewed-by: Andy Lutomirski
---
arch/x86/include/asm
rr (http://rr-project.org/), a userspace record-and-replay reverse-
execution debugger, would like to trap and emulate the CPUID instruction.
This would allow us to a) mask away certain hardware features that rr does
not support (e.g. RDRAND) and b) enable trace portability across machines
by provi
On Mon, Oct 31, 2016 at 1:25 PM, Dave Chinner wrote:
>
> You mean like this version I posted a year ago:
>
> https://lkml.org/lkml/2015/10/29/517
I still suspect that if we want to do this, we should strive to expose
all the other syncing flags from sync_file_range() too.
Not everybody wants to
On Sun, 30 Oct 2016 14:15:30 -0400, Paul Gortmaker said:
> On Thu, Oct 27, 2016 at 9:28 PM, wrote:
> > The mm-of-the-moment snapshot 2016-10-27-18-27 has been uploaded to
> >
> >http://www.ozlabs.org/~akpm/mmotm/
>
> Just a heads up:
>
> Somehow one of the akpm commits as it appears in linux-
On Tue, Nov 1, 2016 at 1:59 AM, Christoph Hellwig wrote:
> From: Kent Overstreet
>
> This is a helper that pins down a range from an iov_iter and adds it to
> a bio without requiring a separate memory allocation for the page array.
> It will be used for upcoming direct I/O implementations for blo
Hi David, thanks for looking at it.
On Mon, Oct 31, 2016 at 9:31 PM, David Miller wrote:
> From: Isaac Boukris
> Date: Sat, 29 Oct 2016 22:20:20 +0300
>
>> Abstract unix domain socket may embed null characters,
>> these should be translated to '@' when printed out to
>> proc the same way the nul
DEAR FRIEND,
How are you together with your family and business hope all is well. I know
that this message will come to you as a surprise. I Hope that you will not
expose or betray this trust and confident that I am about to repose on you for
our mutual benefit of our both families. I need y
When memory_failure() runs on a thp tail page after pmd is split, we trigger
the following VM_BUG_ON_PAGE():
[ 619.550520] page:d7cd819b0040 count:0 mapcount:0 mapping:
(null) index:0x1
[ 619.555486] flags: 0x1fffc00040(hwpoison)
[ 619.556408] page dumped because: VM_BUG_
On 10/31/2016 05:01 PM, kbuild test robot wrote:
> Hi Vineet,
>
> [auto build test ERROR on linus/master]
> [also build test ERROR on v4.9-rc3]
> [cannot apply to arc/for-next]
> [if your patch is applied to the wrong git tree, please drop us a note to
> help improve the system]
> [Suggest to use
On Tue, Oct 25, 2016 at 11:29:10PM +0200, Arnd Bergmann wrote:
> Building the caam driver on arm64 produces a harmless warning:
>
> drivers/crypto/caam/caamalg.c:140:139: warning: comparison of distinct
> pointer types lacks a cast
>
> We can use min_t to tell the compiler which type we want it
On Tue, Oct 25, 2016 at 12:07:27PM +0100, Colin King wrote:
> From: Colin Ian King
>
> Trivial fix to typo in dev_dbg message
>
> Signed-off-by: Colin Ian King
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~he
Abstract unix domain socket may embed null characters,
these should be translated to '@' when printed out to
proc the same way the null prefix is currently being
translated.
This helps for tools such as netstat, lsof and the proc
based implementation in ss to show all the significant
bytes of the
Add support for the second generation of the iProc PCIe PAXC host
controller to the iProc PCIe host driver
Signed-off-by: Ray Jui
Reviewed-by: Anup Patel
Reviewed-by: Scott Branden
---
drivers/pci/host/pcie-iproc-platform.c | 3 +
drivers/pci/host/pcie-iproc.c | 176
The iProc PCIe driver is currently using type IPROC_PCIE_PAXB for
the following SoCs: NS, NSP, Cygnus, NS2, and Pegasus. In fact, the BCMA
based NS uses a legacy PAXB controller that is slightly different from
the PAXB controller used in the rest of SoCs, e.g., some registers are
missing and it doe
Remove the following outbound related device tree properties:
brcm,pcie-ob-window-size
brcm,pcie-ob-oarr-size
The above two properties are a bit duplicated in functions. In addition,
the next generation iProc PCIe controller has outbound mapping window that
supports more than just two sizes, which
During initialization, the current iProc PCIe host driver resets PAXC
and the downstream internal endpoint device that PAXC connects to. If
the endpoint device is already loaded with firmware and has started
running from the bootloader stage, this downstream reset causes the
endpoint device to stop
As the number of iProc PCIe core registers starts to grow and differ
between different revisions of the iProc PCIe controllers, the
current way of populating each individual unsupported register with
value 'IPROC_PCIE_REG_INVALID' with a table entry has become a bit
messy and is difficult to scale
This patch adds the support of inbound mapping to the iProc PCIe driver.
The range of the inbound mapping is configured by the optional device
tree property 'dma-ranges'.
While inbound mapping is done automatically in the ASIC on most iProc
based SoCs, newer ASIC (e.g., Stingray) requires inbound
Add description for optional device tree property 'dma-ranges' for
inbound mapping
Signed-off-by: Oza Oza
Signed-off-by: Ray Jui
Reviewed-by: Scott Branden
---
Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicet
Improve the iProc PCIe outbound mapping code by making it more generic
and removing redundant device tree properties
'brcm,pcie-ob-window-size' and 'brcm,pcie-ob-oarr-size'. The driver is
still backward compatible to device tree binaries with the two
properties specified
The driver now automatical
Add new compatible string "brcm,iproc-pcie-paxc-v2" to the iProc
PCIe device tree binding document. "brcm,iproc-pcie-paxc-v2" is for the
second generation of the Broadcom iProc PCIe PAXC host controller
Also updated the binding document with more detailed description of
each compatible string and
Add new compatible string 'brcm,iproc-pcie-paxb-v2', for the next
generation of the iProc PAXB PCIe host controller
Signed-off-by: Oza Oza
Signed-off-by: Ray Jui
Reviewed-by: Scott Branden
---
Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt | 2 ++
1 file changed, 2 insertions(+)
di
During enumeration with multi-function EP devices, access to the
configuration space of a non-exist function results in an unsupported
request being returned as expected. By default the PAXB based iProc
PCIe controller forwards this as an APB error to the host system and
that causes an exception, w
This patch adds the support for the next generation of the iProc PAXB
host controller, used in Stingray
Signed-off-by: Oza Oza
Signed-off-by: Ray Jui
Reviewed-by: Scott Branden
---
drivers/pci/host/pcie-iproc-platform.c | 3 +
drivers/pci/host/pcie-iproc.c | 128
On 10/31/2016 09:22 PM, Jens Axboe wrote:
> On 10/31/2016 07:08 AM, Matias Bjørling wrote:
>> On 10/27/2016 08:01 PM, Javier González wrote:
>>> From: Javier González
>>>
>>> On target initialization, targets use callbacks to the media manager to
>>> configure the LUNs they use. In order to simpli
1 - 100 of 761 matches
Mail list logo
