Hi,
These patches address a boot failure on arm64 observed when booting a kernel
built with the hotplug rwsem changes currently queued in the tip smp/hotplug
branch.
I've given these a spin on Juno R1, which now boots happily.
FWIW, I also did a test-merge with the arm64 for-next/core branch, wh
From: Sebastian Andrzej Siewior
Provide static_key_[enable|slow_inc]_cpuslocked() variant that
don't take cpu_hotplug_lock().
Signed-off-by: Sebastian Andrzej Siewior
Signed-off-by: Mark Rutland
Cc: Peter Zijlstra
Cc: Sebastian Siewior
Cc: Steven Rostedt
Cc: jba...@akamai.com
---
include/l
Recently, the hotplug locking was conveted to use a percpu rwsem. Unlike
the existing {get,put}_online_cpus() logic, this can't nest.
Unfortunately, in arm64's secondary boot path we can end up nesting via
static_branch_enable() in cpus_set_cap() when we detect an erratum.
This leads to a stream o
On Thu 27-04-17 10:38:58, Florian Fainelli wrote:
> If the caller has set __GFP_NOWARN don't print the following message:
> vmap allocation for size 15736832 failed: use vmalloc= to increase
> size.
>
> This can happen with the ARM/Linux or ARM64/Linux module loader built
> with CONFIG_ARM{,64}_MO
From: Colin Ian King
clean up a few sparse warnings, these following
functions can be made static:
drivers/net/ethernet/intel/igb/igb_main.c: warning: symbol
'igb_add_mac_filter' was not declared. Should it be static?
drivers/net/ethernet/intel/igb/igb_main.c: warning: symbol
'igb_del_mac_fi
On Thu, Apr 27, 2017 at 06:44:37PM +0100, Mark Rutland wrote:
> Recently, the hotplug locking was conveted to use a percpu rwsem. Unlike
> the existing {get,put}_online_cpus() logic, this can't nest.
> Unfortunately, in arm64's secondary boot path we can end up nesting via
> static_branch_enable()
On 04/27/2017 10:56 AM, Michal Hocko wrote:
> On Thu 27-04-17 10:38:58, Florian Fainelli wrote:
>> If the caller has set __GFP_NOWARN don't print the following message:
>> vmap allocation for size 15736832 failed: use vmalloc= to increase
>> size.
>>
>> This can happen with the ARM/Linux or ARM64/L
> On 27 Apr 2017, at 18:39, Florian Fainelli wrote:
>
> When CONFIG_ARM64_MODULE_PLTS is enabled, the first allocation using the
> module space fails, because the module is too big, and then the module
> allocation is attempted from vmalloc space. Silence the first allocation
> failure in that c
Hi Chao,
On 04/27, Chao Yu wrote:
> From: Hou Pengyang
>
> We don't need to rewrite the page under cp_rwsem and dnode locks.
>
> Signed-off-by: Hou Pengyang
> Signed-off-by: Chao Yu
> Signed-off-by: Jaegeuk Kim
> ---
> fs/f2fs/data.c| 39 ---
> fs/f2f
On 04/27/2017 11:07 AM, Ard Biesheuvel wrote:
>
>> On 27 Apr 2017, at 18:39, Florian Fainelli wrote:
>>
>> When CONFIG_ARM64_MODULE_PLTS is enabled, the first allocation using the
>> module space fails, because the module is too big, and then the module
>> allocation is attempted from vmalloc spa
On Thu, 27 Apr 2017 17:28:23 +0200
Joerg Roedel wrote:
> Hey,
>
> here are two patches for the s390 PCI and IOMMU code. It is
> based on the assumption that every pci_dev that points to
> the same zpci_dev shares a single dma-table (and thus a
> single address space).
Well, there is a separate
On Thu, Apr 27, 2017 at 11:50:12AM +0530, Rajaram R wrote:
> On Tue, Apr 25, 2017 at 7:40 PM, Guenter Roeck wrote:
> > On 04/25/2017 01:26 AM, Rajaram R wrote:
> >>
> >> On Mon, Apr 24, 2017 at 11:20 PM, Badhri Jagan Sridharan
> >> wrote:
> >>>
> >>> On Sat, Apr 22, 2017 at 2:23 AM, Rajaram R
>
On Thu, 27 Apr 2017 17:28:24 +0200
Joerg Roedel wrote:
> From: Joerg Roedel
>
> Currently the s390 iommu driver allocates an iommu-group for
> every device that is added. But that is wrong, as there is
> only one dma-table per pci-root-bus. Make all devices behind
> one dma-table share one iomm
On 27-04-17 11:16, Lars-Peter Clausen wrote:
On 04/27/2017 07:52 AM, Jonathan Cameron wrote:
On 26/04/17 10:44, Mike Looijmans wrote:
The Linear Technology LTC2631, LTC2633 and LTC2635 are very similar
to the AD5064 device, in particular the LTC2627.
This patch adds support for those devices.
> On 27 Apr 2017, at 19:09, Florian Fainelli wrote:
>
>> On 04/27/2017 11:07 AM, Ard Biesheuvel wrote:
>>
>>> On 27 Apr 2017, at 18:39, Florian Fainelli wrote:
>>>
>>> When CONFIG_ARM64_MODULE_PLTS is enabled, the first allocation using the
>>> module space fails, because the module is too b
在 2017-04-27 21:28，Maxime Ripard 写道：
On Wed, Apr 26, 2017 at 11:20:14PM +0800, Icenowy Zheng wrote:
Allwinner A64 have a RSB controller like the one on A23/A33 SoCs.
Add it and its pinmux.
Signed-off-by: Icenowy Zheng
Acked-by: Chen-Yu Tsai
---
Changes in v2:
- Removed bonus properties in pi
Hi Chao,
Could you add this state in print_cp_state() of f2fs-tools as well?
Thanks,
On 04/27, Chao Yu wrote:
> Introduce CP_TRIMMED_FLAG to indicate all invalid block were trimmed
> before umount, so once we do mount with image which contain the flag,
> we don't record invalid blocks as undisca
> WARNING: Possible unnecessary 'out of memory' message
I have noticed a moment ago that a similar change is also contained
in the update suggestion “HID: Remove unnecessary OOM messages”
by Joe Perches from 2017-03-01.
https://patchwork.kernel.org/patch/9598997/
https://lkml.kernel.org/r/<0fbe692
With kernels built with CONFIG_ARM{,64}_MODULES_PLTS=y, the first allocation
done from module space will fail, produce a general OOM allocation and also a
vmap warning. The second allocation from vmalloc space may or may not be
successful, but is actually the one we are interested about in these ca
When CONFIG_ARM64_MODULE_PLTS is enabled, the first allocation using the
module space fails, because the module is too big, and then the module
allocation is attempted from vmalloc space. Silence the first allocation
failure in that case by setting __GFP_NOWARN.
Reviewed-by: Ard Biesheuvel
Signed
When CONFIG_ARM_MODULE_PLTS is enabled, the first allocation using the
module space fails, because the module is too big, and then the module
allocation is attempted from vmalloc space. Silence the first allocation
failure in that case by setting __GFP_NOWARN.
Signed-off-by: Florian Fainelli
---
If the caller has set __GFP_NOWARN don't print the following message:
vmap allocation for size 15736832 failed: use vmalloc= to increase
size.
This can happen with the ARM/Linux or ARM64/Linux module loader built
with CONFIG_ARM{,64}_MODULE_PLTS=y which does a first attempt at loading
a large modu
On Thu 27-04-17 11:03:31, Florian Fainelli wrote:
> On 04/27/2017 10:56 AM, Michal Hocko wrote:
> > On Thu 27-04-17 10:38:58, Florian Fainelli wrote:
> >> If the caller has set __GFP_NOWARN don't print the following message:
> >> vmap allocation for size 15736832 failed: use vmalloc= to increase
>
On 04/27/2017 11:20 AM, Michal Hocko wrote:
>>> would be shorter and you wouldn't need the goto and a label.
>>
>> Do you want me to resubmit with that change included?
>
> Up to you. As I've said this is a nit at best.
I just sent a v3 based on feedback from Ard, thanks!
--
Florian
> On 27 Apr 2017, at 19:18, Florian Fainelli wrote:
>
> With kernels built with CONFIG_ARM{,64}_MODULES_PLTS=y, the first allocation
> done from module space will fail, produce a general OOM allocation and also a
> vmap warning. The second allocation from vmalloc space may or may not be
> succes
On Wed, Apr 26, 2017 at 11:53:20AM -0400, Vivien Didelot wrote:
> VLAN aware Marvell chips can program 802.1Q VLAN membership as well as
> 802.1s per VLAN Spanning Tree state using the same 3 VTU Data registers.
>
> Some chips such as 88E6185 use different Data registers offsets for
> ports state
From: Kieran Bingham
This is an RFC for the Analog Devices ADV748x driver, and follows on from a
previous posting by Niklas Söderlund [0] of an earlier incarnation of this
driver.
This is an early posting of the driver following the release early, release
often method after quite a bit of refact
From: Kieran Bingham
Devices such as the the ADV748x support multiple parallel stream routes
through a single chip. This leads towards needing to provide multiple
distinct entities and subdevs from a single device-tree node.
To distinguish these separate outputs, the device-tree binding must
spe
From: Kieran Bingham
Provide bindings between the VIN, CSI and the ADV7482 on the r8a7796.
Signed-off-by: Kieran Bingham
---
arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts | 129 +
1 file changed, 129 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a7796-salva
From: Kieran Bingham
Provide basic support for the ADV7481 and ADV7482.
The driver is modelled with 2 subdevices to allow simultaneous streaming
from the AFE (Analog front end) and HDMI inputs.
Presently the HDMI is hardcoded to link to the TXA CSI bus, whilst the
AFE is linked to the TXB CSI b
From: Kieran Bingham
If an endpoint source specifies a port number, then it may have
multiple entities provided by one DT node. In this event, match
against both the DT node and it's relevant port.
Signed-off-by: Kieran Bingham
---
drivers/media/platform/rcar-vin/rcar-core.c | 15 -
From: Kieran Bingham
Provide bindings between the VIN, CSI and the ADV7482 on the r8a7795.
Signed-off-by: Kieran Bingham
---
arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 129 +
1 file changed, 129 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a7795-salva
On 25 April 2017 at 12:29, Markus Mayer wrote:
> Hi Rob,
>
> On 18 April 2017 at 13:17, Markus Mayer wrote:
>> From: Markus Mayer
>>
>> Provide bindings for the Broadcom STB DDR PHY Front End (DPFE).
>
> Would you be able to have a look at this binding? The driver won't be
> upstreamed as hwmon
On Thu, Apr 27, 2017 at 05:52:44PM +0200, Laurent Dufour wrote:
> From: Peter Zijlstra
>
> Manage the VMAs with SRCU such that we can do a lockless VMA lookup.
>
> We put the fput(vma->vm_file) in the SRCU callback, this keeps files
> valid during speculative faults, this is possible due to the
On Wed, Apr 26, 2017 at 11:53:21AM -0400, Vivien Didelot wrote:
> Move the helper functions to access the Global 1 VTU Operation register
> to a new global1_vtu.c file, and get rid of the old underscore prefix
> naming convention. This file will be extended will all VTU/STU related
> code.
>
> Sig
On Wed, Apr 26, 2017 at 11:53:21AM -0400, Vivien Didelot wrote:
> Move the helper functions to access the Global 1 VTU Operation register
> to a new global1_vtu.c file, and get rid of the old underscore prefix
> naming convention. This file will be extended will all VTU/STU related
> code.
>
> Sig
On Wed, Apr 26, 2017 at 11:53:22AM -0400, Vivien Didelot wrote:
> Move the VTU flush operation to global1_vtu.c and call it from a
> mv88e6xxx_vtu_setup helper, similarly to the ATU and PVT setup.
>
> Signed-off-by: Vivien Didelot
Reviewed-by: Andrew Lunn
Andrew
On 04/27/2017 11:24 AM, Ard Biesheuvel wrote:
>
>> On 27 Apr 2017, at 19:18, Florian Fainelli wrote:
>>
>> With kernels built with CONFIG_ARM{,64}_MODULES_PLTS=y, the first allocation
>> done from module space will fail, produce a general OOM allocation and also a
>> vmap warning. The second allo
On Wed, Apr 26, 2017 at 11:53:23AM -0400, Vivien Didelot wrote:
> Add helpers to access the VTU FID register in the global1_vtu.c file.
>
> Signed-off-by: Vivien Didelot
Reviewed-by: Andrew Lunn
Andrew
On Wed, Apr 26, 2017 at 11:53:24AM -0400, Vivien Didelot wrote:
> Add helpers to access the VTU SID register in the global1_vtu.c file.
>
> Signed-off-by: Vivien Didelot
Reviewed-by: Andrew Lunn
Andrew
On 04/27/2017 05:48 AM, David Lin wrote:
> On Tue, Apr 25, 2017 at 1:15 PM, Jacek Anaszewski
> wrote:
>>> However, there's a need to
>>> support hrtimer if the LED subsystem claims support the use case of
>>> vibrator (please see Documentation/leds/ledtrig-transient.txt) as even
>>> a 5ms of varia
Dan Williams writes:
>> The sentiment is that programs shouldn't have to grovel around in sysfs
>> to do stuff related to an open file descriptor or mapping. I don't take
>> issue with the name. I do worry that something like 'wpq_drain' may be
>> too platform specific, though. The NVM Program
Hi Vineet,
On 27-04-2017 00:31, Vineet Gupta wrote:
> On 04/26/2017 01:55 AM, Jose Abreu wrote:
>> Hi Vineet,
>>
>>
>> On 24-04-2017 18:36, Vineet Gupta wrote:
>>> On 04/21/2017 03:15 AM, Jose Abreu wrote:
This patch adds the necessary DT bindings to get HDMI audio
output in ARC AXS10x
On Thu, 2017-04-27 at 19:12 +0200, Sebastien Buisson wrote:
> 2017-04-27 17:18 GMT+02:00 Stephen Smalley :
> > Ok, that should work as long as you just want to validate that all
> > the
> > clients loaded the same policy file, and aren't concerned about
> > non-
> > persistent policy boolean change
Hi,
On 21-04-2017 11:49, Mark Brown wrote:
> On Fri, Apr 21, 2017 at 12:39:30PM +0200, Takashi Iwai wrote:
>> Jose Abreu wrote:
>>> Maybe rename to "dwc-i2s.c" and "dwc-pcm.c" (as the folder is
>>> called "dwc") and let the module still be called "designware-i2s"?
>> Lubomir's patch keeps the mod
> @@ -1464,13 +1457,16 @@ static int _mv88e6xxx_vtu_loadpurge(struct
> mv88e6xxx_chip *chip,
> struct mv88e6xxx_vtu_entry *entry)
> {
> u16 op = GLOBAL_VTU_OP_VTU_LOAD_PURGE;
> - u16 reg = 0;
> int err;
>
> err = mv88e6xxx_g1_vtu_op_wait(c
On Wed, Apr 26, 2017 at 10:10 AM, Ryder Lee wrote:
> On Tue, 2017-04-25 at 14:38 +0200, Arnd Bergmann wrote:
>> On Sun, Apr 23, 2017 at 10:19 AM, Ryder Lee wrote:
>> > +static int mtk_pcie_enable_ports(struct mtk_pcie *pcie)
>> > +{
>> > + struct device *dev = pcie->dev;
>> > + struc
On Wed, Apr 26, 2017 at 11:53:26AM -0400, Vivien Didelot wrote:
> Even though every switch model has a different way to access the VTU
> Data bits, the base implementation of the VTU GetNext operation remains
> the same: wait, write the first VID to iterate from, start the
> operation, and read the
> On Apr 27, 2017, at 9:54 AM, David Howells wrote:
>
> Mehmet Kayaalp wrote:
>
>> +/* TODO: update CRC */
>
> Is this bit missing?
I didn't add it, since I wasn't sure it was still used with secure boot. The
CRC
code is implemented in multiple places, but not exposed to the tools/scri
Hi Anders,
On 04/27/2017 08:37 AM, Anders Darander wrote:
> Add a new DT property, nxp,inverted-out, to invert the polarity of the output.
>
> Tested on PCA9634.
>
> Signed-off-by: Anders Darander
> ---
> Documentation/devicetree/bindings/leds/pca963x.txt | 1 +
> drivers/leds/leds-pca963x.c
The new wake function is only used by the suspend/resume handlers that
are defined in inside of an #ifdef, which can cause this harmless
warning:
drivers/net/ethernet/intel/igb/igb_main.c:7988:13: warning:
'igb_deliver_wake_packet' defined but not used [-Wunused-function]
Removing the #ifdef, in
When CONFIG_IIO=m and the axp20x_usb_power driver is built-in, we get
a link time error:
drivers/power/built-in.o: In function `axp20x_usb_power_get_property':
undefined reference to `iio_read_channel_processed'
drivers/power/built-in.o: In function `axp20x_usb_power_probe':
undefined reference to
On 04/27/2017 11:42 AM, Jose Abreu wrote:
> Hi Vineet,
>
>
> On 27-04-2017 00:31, Vineet Gupta wrote:
>> On 04/26/2017 01:55 AM, Jose Abreu wrote:
>>> Hi Vineet,
>>>
>>>
>>> On 24-04-2017 18:36, Vineet Gupta wrote:
On 04/21/2017 03:15 AM, Jose Abreu wrote:
> This patch adds the necessary D
On Thu, Apr 27, 2017 at 11:41 AM, Jeff Moyer wrote:
> Dan Williams writes:
>
>>> The sentiment is that programs shouldn't have to grovel around in sysfs
>>> to do stuff related to an open file descriptor or mapping. I don't take
>>> issue with the name. I do worry that something like 'wpq_drain
On Wed, Apr 26, 2017 at 11:53:27AM -0400, Vivien Didelot wrote:
> The code to access the VTU Data registers currently only supports the
> 88E6185 family and alike: 2-bit membership adjacent to 2-bit port state.
>
> Even though the 88E6352 family introduced an indirect table to program
> the VLAN S
On Thu, Apr 27, 2017 at 12:17 PM, Dan Williams wrote:
> On Thu, Apr 27, 2017 at 11:41 AM, Jeff Moyer wrote:
>> Dan Williams writes:
>>
The sentiment is that programs shouldn't have to grovel around in sysfs
to do stuff related to an open file descriptor or mapping. I don't take
i
On 04/26/2017 02:43 PM, Joerg Roedel wrote:
On Wed, Apr 26, 2017 at 02:31:40PM -0700, Samuel Sieb wrote:
This test was done with the patch that always disables ATS. Which
is the current patch to selectively disable it? The last patch I
tried didn't seem to work.
Its
[PATCH v2] PCI:
Hi David,
On Thu, Apr 27, 2017 at 10:59:15AM +0200, David Oberhollenzer wrote:
> > Are you sure? I just tried rebasing my ubifs support patches for xfstests
> > and
> > xfstests-bld onto the latest xfstests and xfstests-bld respectively, then
> > building a new kvm-xfstests appliance and the lat
Dan Williams writes:
> On Thu, Apr 27, 2017 at 11:41 AM, Jeff Moyer wrote:
>> Dan Williams writes:
>>
The sentiment is that programs shouldn't have to grovel around in sysfs
to do stuff related to an open file descriptor or mapping. I don't take
issue with the name. I do worry
On Wed, Apr 26, 2017 at 11:53:28AM -0400, Vivien Didelot wrote:
> Extract the generic portion of code to issue an STU GetNext operation,
> which will be used in other implementations.
>
> Signed-off-by: Vivien Didelot
Reviewed-by: Andrew Lunn
Andrew
Dan Williams writes:
> We also still seem to need a discovery mechanism as I've had questions
> about "how do I tell if my system supports deep flush?". That's where
> sysfs is much better than an ioctl. The need for deep flush discovery
> tips the scales, at least for me, to also do deep flush t
From: Markus Elfring
Date: Thu, 27 Apr 2017 21:34:32 +0200
Two update suggestions were taken into account
from static source code analysis.
Markus Elfring (2):
Use devm_kcalloc() in stm_probe()
Use devm_kcalloc() in of_coresight_alloc_memory()
drivers/hwtracing/coresight/coresight-stm.c |
On Fri, Apr 21, 2017 at 6:40 PM, Krzysztof Kozlowski wrote:
> The following changes since commit e3c07546747cdec07ff15c984bc6cebc9c9f788c:
>
> arm64: dts: exynos: Add the burst and esc clock frequency properties to DSI
> node (2017-03-08 08:55:39 +0200)
>
> are available in the git repository a
From: Markus Elfring
Date: Thu, 27 Apr 2017 21:18:57 +0200
* A multiplication for the size determination of a memory allocation
indicated that an array data structure should be processed.
Thus use the corresponding function "devm_kcalloc".
This issue was detected by using the Coccinelle so
From: Markus Elfring
Date: Thu, 27 Apr 2017 21:29:12 +0200
Multiplications for the size determination of memory allocations
indicated that array data structures should be processed.
Thus use the corresponding function "devm_kcalloc".
This issue was detected by using the Coccinelle software.
Sig
On Thu, Apr 27, 2017 at 09:46:03PM +0200, Arnd Bergmann wrote:
> On Fri, Apr 21, 2017 at 6:40 PM, Krzysztof Kozlowski wrote:
> > The following changes since commit e3c07546747cdec07ff15c984bc6cebc9c9f788c:
> >
> > arm64: dts: exynos: Add the burst and esc clock frequency properties to
> > DSI n
On Fri, Apr 21, 2017 at 6:40 PM, Krzysztof Kozlowski wrote:
> Hi,
>
> I know it is late so just one fix for v4.12.
> On top of previous pull request.
Pulled into next/dt, thanks
Arnd
[I had actually pulled it already, but forgot to send out the mail reply and now
saw your reminder, thanks
On Fri, Apr 21, 2017 at 5:47 AM, Chunyan Zhang
wrote:
> From: Orson Zhai
>
> SC9860G is a 8 cores of A53 SoC with 4G LTE support SoC from Spreadtrum.
>
> According to regular hierarchy of sprd dts, whale2.dtsi contains SoC
> peripherals IP nodes, sc9860.dtsi contains stuff related to ARM core stu
Hi Baoquan,
On 04/26/2017 06:16 AM, Baoquan He wrote:
> People reported kernel panic occurs during system boots up with mem boot
> option.
> After checking code, several problems are found about memmap= and mem= in
> boot stage
> kaslr.
>
> *) In commit f28442497b5c ("x86/boot: Fix KASLR and m
On Thu, Apr 20, 2017 at 10:02 AM, Maxime Ripard
wrote:
> On Wed, Apr 19, 2017 at 07:35:36PM +0200, Arnd Bergmann wrote:
>> The sunxi clk driver causes a link error when the reset controller
>> subsystem is disabled:
>>
>> drivers/clk/built-in.o: In function `sun4i_ve_clk_setup':
>> :(.init.text+0x
On 04/27/2017 12:46 PM, Andy Lutomirski wrote:
> On Thu, Apr 27, 2017 at 6:21 AM, Boris Ostrovsky
> wrote:
>>> Also, this code in drop_other_mm_ref() looks dubious to me:
>>>
>>> /* If this cpu still has a stale cr3 reference, then make sure
>>>it has been flushed. */
>
On Thu, Apr 27, 2017 at 12:40 PM, Jeff Moyer wrote:
> Dan Williams writes:
>
>> On Thu, Apr 27, 2017 at 11:41 AM, Jeff Moyer wrote:
>>> Dan Williams writes:
>>>
> The sentiment is that programs shouldn't have to grovel around in sysfs
> to do stuff related to an open file descriptor or
merged into cifs-2.6.git for-next
On Sun, Apr 9, 2017 at 9:08 PM, NeilBrown wrote:
>
> mempool_alloc() cannot fail if the gfp flags allow it to
> sleep, and both GFP_FS allows for sleeping.
>
> So these tests of the return value from mempool_alloc()
> cannot be needed.
>
> Signed-off-by: NeilBrow
On 26/04/17 01:44 AM, Christoph Hellwig wrote:
> I think we'll at least need a draft of those to make sense of these
> patches. Otherwise they just look very clumsy.
Ok, what follows is a draft patch attempting to show where I'm thinking
of going with this. Obviously it will not compile because
On Wed, Apr 26, 2017 at 11:53:29AM -0400, Vivien Didelot wrote:
> Now that the code reads both VTU and STU data on VTU GetNext operation,
> fetch the STU entry data of a VTU entry at the same time.
>
> The STU data bits are masked with the VTU data bits and they are now all
> read at the same time
On 26/04/17 01:37 AM, Roger Pau Monné wrote:
> On Tue, Apr 25, 2017 at 12:21:02PM -0600, Logan Gunthorpe wrote:
>> Straightforward conversion to the new helper, except due to the lack
>> of error path, we have to use SG_MAP_MUST_NOT_FAIL which may BUG_ON in
>> certain cases in the future.
>>
>> S
On Wed, Apr 26, 2017 at 6:31 PM, kbuild test robot wrote:
> Hi Kees,
>
> [auto build test WARNING on next-20170424]
> [cannot apply to tip/x86/core linus/master linux/master v4.9-rc8 v4.9-rc7
> v4.9-rc6 v4.11-rc8]
> [if your patch is applied to the wrong git tree, please drop us a note to
> help
Hi Ankit,
> After commit c950fd6f201a kernel registers pstore write based on flag
> set. Pstore write for powerpc is broken as flags(PSTORE_FLAGS_DMESG)
> is not set for powerpc architecture. On panic, kernel doesn't write
> message to /fs/pstore/dmesg*(Entry doesn't gets created at all).
>
> Thi
Please pull knfsd bugfixes for 4.11 from
git://linux-nfs.org/~bfields/linux.git tags/nfsd-4.11-3
Thanks to Ari Kauppi and Tuomas Haanpää at Synopsis for spotting bugs in
our NFSv2/v3 xdr code that could crash the server or expose memory.
--b.
J. Bruce Fields (3):
nfsd: check for oversiz
On Wed, Apr 26, 2017 at 2:20 PM, Paul Moore wrote:
> Thanks for the report, this is the only one like it that I've seen.
> I'm looking at the code in Linus' tree and I'm not seeing anything
> obvious ... looking at the trace above it appears that the problem is
> when get_net() goes to bump the re
Hi,
Thanks for your comments!
El Mon, Apr 24, 2017 at 02:34:47PM +0100 Will Deacon ha dit:
> On Thu, Apr 20, 2017 at 09:42:07AM +0100, Mark Rutland wrote:
> > On Wed, Apr 19, 2017 at 02:22:11PM -0700, Matthias Kaehlcke wrote:
> > > clang fails to build with the current code:
> > >
> > > arch/ar
Hello, Ingo,
This series adds a small change to yesterday's pull request, namely
changing the default value of the srcutree.exp_holdoff kernel boot
parameter from 50 microseconds to 25 microseconds. This change completely
eliminates the performance shortfall that Mike Galbraith observed.
This com
Michal Hocko writes:
> On Tue 25-04-17 16:27:51, Laurent Dufour wrote:
>> When page are poisoned, they should be uncharged from the root memory
>> cgroup.
>>
>> This is required to avoid a BUG raised when the page is onlined back:
>> BUG: Bad page state in process mem-on-off-test pfn:7ae3b
>> p
On Thu, Apr 27, 2017 at 02:19:24PM -0600, Logan Gunthorpe wrote:
>
>
> On 26/04/17 01:37 AM, Roger Pau Monné wrote:
> > On Tue, Apr 25, 2017 at 12:21:02PM -0600, Logan Gunthorpe wrote:
> >> Straightforward conversion to the new helper, except due to the lack
> >> of error path, we have to use SG_
This patch needs to be applied on top of the other memconsole patches
currently queued up in char-misc-next (ending in 049a59db34e).
-8<
The upstream coreboot implementation of memconsole was enhanced from a
single-boot console t
Hi Gerald,
thanks for your reply. I have some more questions, please see below.
On Thu, Apr 27, 2017 at 08:10:18PM +0200, Gerald Schaefer wrote:
> Well, there is a separate zpci_dev for each pci_dev on s390,
> and each of those has its own separate dma-table (thus not shared).
Is that true for
arate out the config information
b06e13c38d Merge branch 'nvme-4.12' of git://git.infradead.org/nvme into
for-4.12/post-merge
3dcee15bbb Add linux-ne
From: Guenter Roeck
The port controller interface driver interconnects the Type-C Port
Manager with a Type-C Port Controller Interface (TCPCI) compliant
port controller.
Signed-off-by: Guenter Roeck
Signed-off-by: Guenter Roeck
---
v7:
- Adjust subject to indicate that this is a staging driver
From: Guenter Roeck
This driver implements the USB Type-C Power Delivery state machine
for both source and sink ports. Alternate mode support is not
fully implemented.
The driver attaches to the USB Type-C class code implemented in
the following patches.
usb: typec: add driver for Intel
From: Yueyao Zhu
Fairchild FUSB302 Type-C chip driver that works with
Type-C Port Controller Manager to provide USB PD and
USB Type-C functionalities.
Signed-off-by: Yueyao Zhu
Signed-off-by: Guenter Roeck
---
v7: Added patch to series
drivers/staging/typec/Kconfig |2 +
dr
On Thu, Apr 27, 2017 at 08:11:42PM +0200, Gerald Schaefer wrote:
> > +void zpci_destroy_iommu(struct zpci_dev *zdev)
> > +{
> > + iommu_group_put(zdev->group);
> > + zdev->group = NULL;
> > +}
>
> While the rest of this patch doesn't seem to make much of a difference to
> the current behavior,
From: Kalle Valo
Date: Thu, 27 Apr 2017 12:41:37 +0300
> here's a pull request for net-next, more info in the tag below. This
> should be the last pull request to net-next for 4.12. Please let me know
> if there are any problems.
Pulled, thanks Kalle.
On Thu, Apr 27, 2017 at 1:00 PM, Boris Ostrovsky
wrote:
> On 04/27/2017 12:46 PM, Andy Lutomirski wrote:
>> On Thu, Apr 27, 2017 at 6:21 AM, Boris Ostrovsky
>> wrote:
Also, this code in drop_other_mm_ref() looks dubious to me:
/* If this cpu still has a stale cr3 re
Changes in v2:
* Split SoC enablement into a separate patch (per Eduardo Valentin)
* Added Eduardo Valentin's Acked-by to the DTS patch
This adds support for NSP to the existing Northstar thermal driver.
This code is based on patches currently in the Linux SoC Thermal git
tree. Specfically,
http
Add thermal support via the ns-thermal driver and create a single
thermal zone for the entire SoC.
Signed-off-by: Jon Mason
Acked-by: Eduardo Valentin
---
arch/arm/boot/dts/bcm-nsp.dtsi | 26 ++
1 file changed, 26 insertions(+)
diff --git a/arch/arm/boot/dts/bcm-nsp.dts
Change the iProc Kconfig to select THERMAL and THERMAL_OF, which allows
the ns-thermal driver to be selected via menuconfig.
Signed-off-by: Jon Mason
---
arch/arm/mach-bcm/Kconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
index a0
Tweak the Kconfig description to mention support for NSP and make the
default on for iProc based platforms.
Signed-off-by: Jon Mason
---
drivers/thermal/broadcom/Kconfig | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/thermal/broadcom/Kconfig b/drivers/therma
In prior commits the selected clock frequency does not propagate
correctly to what is written to the TRF7970A_MODULATOR_SYS_CLK_CTRL
register.
Signed-off-by: Geoff Lansberry
---
drivers/nfc/trf7970a.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/nfc/trf7970a.c b/drivers/nfc
Jeffy Chen writes:
> We need to set vop config done after update line flag config, it's a
> new requirement for chips newer than rk3368.
>
> Since we would only use line flag irq for vact_end, let's move it to
> vop_crtc_enable.
>
> Signed-off-by: Jeffy Chen
>
> ---
>
> drivers/gpu/drm/rockchip
On Thu, Apr 27, 2017 at 1:31 PM, Cong Wang wrote:
> On Wed, Apr 26, 2017 at 2:20 PM, Paul Moore wrote:
>> Thanks for the report, this is the only one like it that I've seen.
>> I'm looking at the code in Linus' tree and I'm not seeing anything
>> obvious ... looking at the trace above it appears
401 - 500 of 686 matches
Mail list logo
