On Thu, Apr 19, 2018 at 9:23 PM, Richard Guy Briggs wrote:
> On 2018-04-18 20:39, Paul Moore wrote:
>> On Fri, Mar 16, 2018 at 5:00 AM, Richard Guy Briggs wrote:
>> > Standalone audit records have the timestamp and serial number generated
>> > on the fly and as such are unique, making them standa
On Fri, Apr 20, 2018 at 7:38 AM, Eric W. Biederman
wrote:
> Filling in struct siginfo before calling force_sig_info a tedious and
> error prone process, where once in a great while the wrong fields
> are filled out, and siginfo has been inconsistently cleared.
>
> Simplify this process by using th
On 20.04.2018 09:57, Peter Zijlstra wrote:
> On Mon, Apr 16, 2018 at 10:54:26AM +0200, Philipp Klocke wrote:
>
>> This patch is motivated by the clang warning Wconstant-logical-operand,
>> issued when logically comparing a variable to a constant integer that is
>> neither 1 nor 0. It happens for
On Fri, Apr 20, 2018 at 03:42:45PM +0100, Quentin Perret wrote:
> Hi Leo,
>
> On Wednesday 18 Apr 2018 at 20:15:47 (+0800), Leo Yan wrote:
> > Sorry I introduce mess at here to spread my questions in several
> > replying, later will try to ask questions in one replying. Below are
> > more questio
On Fri, Apr 20, 2018 at 1:13 AM Marc Zyngier wrote:
> Clang isn't
> really supported to build the arm64 kernel anyway
Can you expand on this? There are millions of arm64 devices shipping with
Clang built Linux kernels.
--
Thanks,
~Nick Desaulniers
On Fri, Apr 20, 2018 at 9:00 AM, Vincent Guittot
wrote:
[..]
>
> Le Saturday 14 Apr 2018 à 13:24:20 (+0200), Vincent Guittot a écrit :
>> Hi Niklas,
>>
>> On 13 April 2018 at 00:39, Niklas Söderlund
>> wrote:
>> > Hi Vincent,
>> >
>> > Thanks for helping trying to figure this out.
>> >
>> > On 20
ASPLOS 2018 was held in March: make sure this is reflected in
header comments and references.
Signed-off-by: Andrea Parri
Cc: Alan Stern
Cc: Will Deacon
Cc: Peter Zijlstra
Cc: Boqun Feng
Cc: Nicholas Piggin
Cc: David Howells
Cc: Jade Alglave
Cc: Luc Maranget
Cc: "Paul E. McKenney"
Cc: Ak
The paper discusses the revised ARMv8 memory model; such revision
had an important impact on the design of the LKMM.
Signed-off-by: Andrea Parri
Cc: Alan Stern
Cc: Will Deacon
Cc: Peter Zijlstra
Cc: Boqun Feng
Cc: Nicholas Piggin
Cc: David Howells
Cc: Jade Alglave
Cc: Luc Maranget
Cc: "Pa
A couple of fixes to our references and comments: the first updating
ASPLOS information, the second adding a reference.
Cheers,
Andrea
Cc: Alan Stern
Cc: Will Deacon
Cc: Peter Zijlstra
Cc: Boqun Feng
Cc: Nicholas Piggin
Cc: David Howells
Cc: Jade Alglave
Cc: Luc Maranget
Cc: "Paul E. Mc
This patch series compose of 2 patches.
First patch, adding support for S5PV210 FIMD variant to Exynos driver.
Compatible for this soc was already existing in documentation.
Second patch, brings back possibility to use drivers depending on
DRM_EXYNOS, on Samsung S5PV210/S5PC110 series based syste
This patch brings back possibility to use drivers depending on
DRM_EXYNOS, on Samsung S5PV210/S5PC110 series based systems.
Fixes: dbbc925bb83a ("drm/exynos: depend on ARCH_EXYNOS for DRM_EXYNOS")
Signed-off-by: Paweł Chmiel
---
drivers/gpu/drm/exynos/Kconfig | 2 +-
1 file changed, 1 insertion(
From: Tomasz Figa
This patch adds support for FIMD variant found on S5PV210 SoC.
Except CLKSEL bit availability, it is identical to Exynos4210.
Tested-by: Paweł Chmiel
Signed-off-by: Tomasz Figa
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 8
1 file changed, 8 insertions(+)
diff -
Since tmpfs THP was supported in 4.8, hugetlbfs is not the only
filesystem with huge page support anymore. tmpfs can use huge page via
THP when mounting by "huge=" mount option.
When applications use huge page on hugetlbfs, it just need check the
filesystem magic number, but it is not enough for t
This series is meant to add support for SR-IOV on devices when the VFs are
not managed by the kernel. Examples of recent patches attempting to do this
include:
virto - https://patchwork.kernel.org/patch/10241225/
pci-stub - https://patchwork.kernel.org/patch/10109935/
vfio - https://patchwork.kerne
This patch adds a common configuration function called
pci_sriov_configure_simple that will allow for managing VFs on devices
where the PF is not capable of managing VF resources.
Signed-off-by: Alexander Duyck
Tested-by: Mark Rustad
---
v5: New patch replacing pci_sriov_configure_unmanaged wit
On 20/04/18 17:30, Nick Desaulniers wrote:
> On Fri, Apr 20, 2018 at 1:13 AM Marc Zyngier wrote:
>> Clang isn't
>> really supported to build the arm64 kernel anyway
>
> Can you expand on this? There are millions of arm64 devices shipping with
> Clang built Linux kernels.
How many of these devic
Memory controller implements the memory.low best-effort memory
protection mechanism, which works perfectly in many cases and
allows protecting working sets of important workloads from
sudden reclaim.
But it's semantics has a significant limitation: it works
only until there is a supply of reclaima
We do store memory.min, memory.low and memory.max actual values
in struct page_counter fields, while memory.high value is located
in the struct mem_cgroup directly, which is not very consistent.
This patch moves the high field from struct mem_cgroup to
struct page_counter to simplify the code and
Instead of implementing our own version of a SR-IOV configuration stub in
the ena driver we can just reuse the existing
pci_sriov_configure_simple function.
Signed-off-by: Alexander Duyck
---
v5: Replaced call to pci_sriov_configure_unmanaged with
pci_sriov_configure_simple
v6: Dropped "
Add a new driver called "pci-pf-stub" to act as a "white-list" for PF
devices that provide no other functionality other then acting as a means of
allocating a set of VFs. For now I only have one example ID provided by
Amazon in terms of devices that require this functionality. The general
idea is t
Add hardware tuning function instead of software tuning because O2/Bayhub
SD host controller support hardware tuning.
Changes in V5:
In function sdhci_o2_send_tuning, mrq.data should set to NULL for
cmd.data has been set to NULL.
Changes in V4:
Patch V3 delete register SDH
When use eMMC as boot device, the eMMC signaling voltage is tied to 1.8v
fixed output voltage, bios can set o2 sd host controller PCI configuration
register 0x308 bit4 to 1 to let driver skip 3.3v signaling voltage and
direct use 1.8v singling voltage in eMMC initialize process.
Changes in V5:
Instead of implementing our own version of a SR-IOV configuration stub in
the nvme driver we can just reuse the existing
pci_sriov_configure_simple function.
Reviewed-by: Christoph Hellwig
Signed-off-by: Alexander Duyck
---
v5: Replaced call to pci_sriov_configure_unmanaged with
pci_sri
From: Bartosz Golaszewski
All users of early_platform_driver_register_all() subsequently call
early_platform_driver_probe(). Provide a helper that calls both
functions.
Signed-off-by: Bartosz Golaszewski
---
include/linux/platform_device.h | 9 +
1 file changed, 9 insertions(+)
diff -
From: Bartosz Golaszewski
Currently we only have early_platform_add_devices() which takes struct
platform_device ** as argument, requiring the users to have an
intermediate array of platform_device pointers even if we're only
adding a single device. Provide a helper for adding a single device at
From: Bartosz Golaszewski
I'm using the early_platform infrastructure for converting the davinci
timer support to a real platform_driver. I noticed that it would be
nice to have these two helpers for more code brevity.
Bartosz Golaszewski (2):
platform: provide early_platform_add_device()
pl
Add MSI interrupt support if the SD host device can support MSI interrupt.
Changes in V5:
1. Because pci_enable_msi is marked as deprecated and should not be
used in new code, use pci_alloc_irq_vectors instead.
2. Remove unneeded CONFIG_PCI_MSI macro check
Changes in V4:
On Fri, Apr 20, 2018 at 9:36 AM Marc Zyngier wrote:
> On 20/04/18 17:30, Nick Desaulniers wrote:
> > On Fri, Apr 20, 2018 at 1:13 AM Marc Zyngier
wrote:
> >> Clang isn't
> >> really supported to build the arm64 kernel anyway
> >
> > Can you expand on this? There are millions of arm64 devices sh
On Fri, Apr 20, 2018 at 03:39:46PM +0300, Andy Shevchenko wrote:
> On Wed, 2018-04-18 at 15:35 +0530, Amit Pundir wrote:
>
> > if (skb->data[transaction->aid_len + 2] !=
> > - NFC_EVT_TRANSACTION_PARAMS_TAG)
> > + NFC_EVT_TRANSACTION_PARAMS_TAG ||
> > +
On Fri, Apr 20, 2018 at 05:08:23PM +0300, Andrey Ryabinin wrote:
>
>
> On 04/19/2018 06:01 AM, Fengguang Wu wrote:
> > Hello,
> >
> > FYI this happens in mainline kernel 4.17.0-rc1.
> > It at least dates back to v4.8 .
> >
> > [ 25.697463]
> > [ 25.697463] Start testing find_bit() with rand
Quoting Rob Herring (2018-04-18 15:29:05)
> diff --git a/Documentation/devicetree/bindings/example-schema.yaml
> b/Documentation/devicetree/bindings/example-schema.yaml
> new file mode 100644
> index ..fe0a3bd1668e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/example-schem
On Fri, Apr 20, 2018 at 03:28:26PM +0200, Geert Uytterhoeven wrote:
> The first 6 patches can be applied independently by subsystem
> maintainers.
> The last two patches depend on the first 6 patches, and are thus marked
> RFC.
Would it not make sense to try to apply everything en masse rather th
On Fri, 2018-04-20 at 17:50 +0200, Peter Zijlstra wrote:
> On Tue, Apr 10, 2018 at 09:27:50AM -0700, Davidlohr Bueso wrote:
> > By applying well known spin-on-lock-owner techniques, we can avoid the
> > blocking overhead during the process of when the task is trying to take
> > the rtmutex. The ide
On Fri, Mar 30, 2018 at 12:14:53PM -0700, Nick Terrell wrote:
> Adds zstd support to crypto and scompress. Only supports the default
> level.
>
> Previously we held off on this patch, since there weren't any users.
> Now zram is ready for zstd support, but depends on CONFIG_CRYPTO_ZSTD,
> which is
On Fri, Mar 30, 2018 at 09:55:44AM -0700, Kees Cook wrote:
> On the quest to remove all VLAs from the kernel[1], this avoids VLAs
> by just using the maximum allocation size (4 bytes) for stack arrays.
> All the VLAs in ecc were either 3 or 4 bytes (or a multiple), so just
> make it 4 bytes all the
On 04/20/2018 02:35 AM, Viresh Kumar wrote:
> On 20-04-18, 10:15, Sudeep Holla wrote:
>> It still doesn't give the flexibility to switch between the two
>> implementations boot time based on some firmware config(e.g. DT status
>> property).
>
> I agree, but it didn't look like they need flexibilit
On Tue, Apr 03, 2018 at 03:09:12PM -0500, Gustavo A. R. Silva wrote:
> Add null checks on lookup_tid() return value in order to prevent
> null pointer dereferences.
>
> Addresses-Coverity-ID: 1467422 ("Dereference null return value")
> Addresses-Coverity-ID: 1467443 ("Dereference null return value
On Mon, Apr 09, 2018 at 03:54:45PM +0200, Salvatore Mesoraca wrote:
> v2:
> As suggested by Herbert Xu, the blocksize and alignmask checks
> have been moved to crypto_check_alg.
> So, now, all the other separate checks are not necessary.
> Also, the defines have been moved t
On Fri, Apr 06, 2018 at 05:58:47PM +0100, Colin King wrote:
> From: Colin Ian King
>
> There is a double assignment to cdev->ports, the first is redundant
> as it is over-written so remove it.
>
> Detected by CoverityScan, CID#1467432 ("Unused value")
>
> Signed-off-by: Colin Ian King
Patch a
On Fri, 20 Apr 2018, Vince Weaver wrote:
> > AFAICT it works on Power and possibly ARM.
>
> at least some ARMs are a bit more honest about it than x86
>
> ivybridge:
> Performance counter stats for '/bin/ls':
> 1,368,162 instructions
> 1,368,162 instructions:I
>
> pi
On Fri, Apr 20, 2018 at 06:29:07PM +0200, Philipp Klocke wrote:
> The gain is stopping a warning that clutters the output log of clang.
Well, you should not be using clang anyway. It is known to miscompile
the kernel.
> To improve readability, one can drop the ifdef-structure and just keep
> the
On Mon, Apr 09, 2018 at 05:45:49PM +0200, Jan Glauber wrote:
> Some bug fixes for this driver after it stopped working with virtual mapped
> stacks. I think the first two patches qualify for stable.
>
> Jan Glauber (5):
> crypto: thunderx_zip: Fix fallout from CONFIG_VMAP_STACK
> crypto: thund
On Wed, Apr 11, 2018 at 08:28:32PM +0200, Jan Glauber wrote:
> From: Mahipal Challa
>
> The following error is triggered by the ThunderX ZIP driver
> if the testmanager is enabled:
>
> [ 199.069437] ThunderX-ZIP :03:00.0: Found ZIP device 0 177d:a01a on
> Node 0
> [ 199.073573] alg: comp:
On Thu, Apr 05, 2018 at 05:44:03PM +0100, Colin King wrote:
> From: Colin Ian King
>
> The structure crypto_info contains fields that are not initialized and
> only .version is set. The copy_to_user call is hence leaking information
> from the stack to userspace which must be avoided. Fix this b
On Thu, Apr 19, 2018 at 01:58:40PM +0200, Jan Glauber wrote:
>
> Nice idea. Would a crypto_alloc_cipher("deflate", ...) pick the generic
> implementation or how can we select it?
For our ciphers we generally use the -generic suffix in the driver
name. The compression algorithms seem to be all ove
Hello,
syzbot hit the following crash on upstream commit
87ef12027b9b1dd0e0b12cf311fbcb19f9d92539 (Wed Apr 18 19:48:17 2018 +)
Merge tag 'ceph-for-4.17-rc2' of git://github.com/ceph/ceph-client
syzbot dashboard link:
https://syzkaller.appspot.com/bug?extid=7d6d31d3bc702f566ce3
C reproduce
Hello,
syzbot hit the following crash on upstream commit
87ef12027b9b1dd0e0b12cf311fbcb19f9d92539 (Wed Apr 18 19:48:17 2018 +)
Merge tag 'ceph-for-4.17-rc2' of git://github.com/ceph/ceph-client
syzbot dashboard link:
https://syzkaller.appspot.com/bug?extid=0a725420475916460f12
C reproduce
On Thu, Apr 12, 2018 at 08:40:55AM +0200, Stephan Müller wrote:
> Add the Fixes, CC stable tags.
>
> ---8<---
>
> During freeing of the internal buffers used by the DRBG, set the pointer
> to NULL. It is possible that the context with the freed buffers is
> reused. In case of an error during init
As Miklos reported and suggested:
This pattern repeats two times in trace_uprobe.c and in
kernel/events/core.c as well:
ret = kern_path(filename, LOOKUP_FOLLOW, &path);
if (ret)
goto fail_address_parse;
inode = igrab(d_inode(path.dentry));
path_put(&path);
On 20/04/18 17:43, Nick Desaulniers wrote:
> On Fri, Apr 20, 2018 at 9:36 AM Marc Zyngier wrote:
>
>> On 20/04/18 17:30, Nick Desaulniers wrote:
>>> On Fri, Apr 20, 2018 at 1:13 AM Marc Zyngier
> wrote:
Clang isn't
really supported to build the arm64 kernel anyway
>>>
>>> Can you expan
__GFP_NORETRY and __GFP_NOFAIL are combined in gfp_kmemleak_mask now.
But it's a wrong combination. As __GFP_NOFAIL is blockable, but
__GFP_NORETY is not blockable, make it self-contradiction.
__GFP_NOFAIL means 'The VM implementation _must_ retry infinitely'. But
it's not the real intention, as
On Wed, Apr 18, 2018 at 05:29:05PM -0500, Rob Herring wrote:
> The current DT binding documentation format of freeform text is painful
> to write, review, validate and maintain.
>
> This is just an example of what a binding in the schema format looks
> like. It's using jsonschema vocabulary in a Y
On 04/20/18 09:36, Roman Gushchin wrote:
> ---
> Documentation/cgroup-v2.txt | 20 +
> include/linux/memcontrol.h | 15 ++-
> include/linux/page_counter.h | 11 -
> mm/memcontrol.c | 99
>
> mm/page_counter.c
On Fri, Apr 20, 2018 at 5:35 AM, David Howells wrote:
> In do_mount() when the MS_* flags are being converted to MNT_* flags,
> MS_RDONLY got accidentally convered to SB_RDONLY.
Applied.
I guess they have the same value (1). How did you notice? Do you have
some patches that turn the kernel flags
This adds support for the UAC3 insertion controls. The status
is reported as a boolean value in the same way it used to do
for UAC2. Hence, the presence of any connector in the response
will make the control saying the jack is connected.
The UAC2 support for this control has been moved to a dedica
ed verison of [4].
[1]: https://patchwork.kernel.org/patch/10298179/
[2]: https://patchwork.kernel.org/patch/10305847/
[3]: https://patchwork.kernel.org/patch/10340851/
[4]: https://www.spinics.net/lists/alsa-devel/msg71617.html
Based on linux-next tag: next-20180420
Jorge Sanjuan (3):
ALSA:
The patch
ASoC: atmel: simplify getting .drvdata
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus
The patch
ASoC: rt5668: fix incorrect 'and' operator
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Li
Hi Ingo, Jon,
On Sun, Apr 08, 2018 at 06:30:21PM +0200, Andrea Parri wrote:
> Hi,
>
> This series provides the script 'features-refresh.sh', which operates on
> the arch support status files, and it applies this script to refresh the
> status files in place; previous discussions about this series
The patch
regulator: Don't return or expect -errno from of_map_mode()
has been applied to the regulator tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the nex
The patch
regulator: tps6586x: Add support for TPS658624
has been applied to the regulator tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) a
On 04/19/18 23:11, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20180419:
>
> I have added a patch to the arm-current tree to fix build problems
> discovered overnight.
>
> Non-merge commits (relative to Linus' tree): 1278
> 1324 files changed, 47025 insertions(+), 20625 deletions(-)
>
The patch
spi: simplify getting .drvdata
has been applied to the spi tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the
On Fri, 2018-04-20 at 17:45 +0200, Sebastian Reichel wrote:
> Replace magic numbers with IRQ_TYPE_* constants to improve
> DT readability.
>
> Signed-off-by: Sebastian Reichel
> ---
> arch/arm/boot/dts/imx53-ppd.dts | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/
On chromebooks we depend on wakeup count to identify the wakeup source.
But currently USB devices do not increment the wakeup count when they
trigger the remote wake. This patch addresses the same.
Resume condition is reported differently on USB 2.0 and USB 3.0 devices.
On USB 2.0 devices, a wake
On Fri, Apr 13, 2018 at 03:03:03PM +0800, David Wang wrote:
> New Centaur CPU(Family > 6) supprt Random Number Generator, but can't
> support MSR_VIA_RNG. Just like VIA Nano.
>
> Signed-off-by: David Wang
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbe
From: Michael Drake
The channel mapping is defined by bChRelationship, not bChPurpose.
Signed-off-by: Michael Drake
---
sound/usb/stream.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/usb/stream.c b/sound/usb/stream.c
index 6a8f5843334e..956be9f7c72a 100644
--- a/s
bmAtributes offset doesn't exist in the UAC3 CS_EP descriptor.
Hence, checking for pitch control as if it was UAC2 doesn't make
any sense. Use the defined UAC3 offsets instead.
Signed-off-by: Jorge Sanjuan
---
sound/usb/stream.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletio
On Fri, Apr 20, 2018 at 7:12 AM, Alan Stern wrote:
> On Thu, 19 Apr 2018, Ravi Chandra Sadineni wrote:
>
>> On chromebooks we depend on wakeup count to identify the wakeup source.
>> But currently USB devices do not increment the wakeup count when they
>> trigger the remote wake. This patch addres
This adds support for the MIXER UNIT in UAC3. All the information
is obtained from the (HIGH CAPABILITY) Cluster's header. We don't
read the rest of the logical cluster to obtain the channel config
as that wont make any difference in the current mixer behaviour.
The name of the mixer unit is not y
On 2018-03-27 13:01:07 [-0500], Grygorii Strashko wrote:
> Hi Sebastian,
Hi Grygorii,
> I've took this RT version and applied "[RT] kernel/time/posix-timer: avoid
> schedule()
> while holding the RCU lock" [1] on top. Then I run below tests:
…
> no stall or crashes were observed, but I've caught
On Fri, 20 Apr 2018 10:52:41 +0200
Quentin Schulz wrote:
> There's already ECC on NAND pages so there may be no need for one to
> check the CRC of a UBI volume.
That's true that ECC can help detecting corruptions, but I don't think
this is the actual reason for disabling CRC check at volume open
test_find_first_bit() is intentionally sub-optimal,
and may cause soft lockup due to long time of run on some systems.
So decrease length of bitmap to traverse to avoid lockup.
With the change below, time of test execution doesn't exceed 0.2
seconds on my testing system.
Signed-off-by: Yury Norov
Caller of uprobe_register is required to keep the inode and containing
mount point referenced.
Cc: Steven Rostedt
Cc: Ingo Molnar
Cc: Howard McLauchlan
Cc: Josef Bacik
Cc: Srikar Dronamraju
Cc: Miklos Szeredi
Signed-off-by: Song Liu
---
kernel/events/uprobes.c | 6 ++
1 file changed, 2
On 04/20, Thomas Gleixner wrote:
>
> > kernel/signal.c:3457 do_sigaction() warn: potential spectre issue
> > 'p->sighand->action'
>
> This one is correctly detected
Not sure,
k = &p->sighand->action[sig-1];
calculates the addr, although we do '*oact = *k' later. I dunno.
> > kernel/sig
On Fri, Apr 20, 2018 at 08:05:17AM -0700, Kees Cook wrote:
> On Fri, Apr 20, 2018 at 12:34 AM, Pavel Machek wrote:
> > On Sun 2018-04-15 11:00:06, Kees Cook wrote:
> >> On Sun, Apr 15, 2018 at 10:39 AM, Pavel Machek wrote:
> >> > Hi!
> >> >
> >> >> Thanks.
> >> >>
> >> >> Ok, let me try to bisect
On Fri, Apr 20, 2018 at 10:01:04AM -0700, Randy Dunlap wrote:
> On 04/20/18 09:36, Roman Gushchin wrote:
>
> > ---
> > Documentation/cgroup-v2.txt | 20 +
> > include/linux/memcontrol.h | 15 ++-
> > include/linux/page_counter.h | 11 -
> > mm/memcontrol.c | 99
>
The current reset-gpio support triggers an interrupt storm on platforms
using the maxtouch with level based interrupt. The Motorola Droid 4,
which I used for some of the tests is not affected, since it uses a level
based interrupt.
This change avoids the interrupt storm by enabling the device whil
On 04/20/18 09:28, Alexander Duyck wrote:
> This series is meant to add support for SR-IOV on devices when the VFs are
> not managed by the kernel. Examples of recent patches attempting to do this
> include:
> virto - https://patchwork.kernel.org/patch/10241225/
> pci-stub - https://patchwork.kerne
On 4/19/18 8:12 AM, Bartosz Golaszewski wrote:
From: Bartosz Golaszewski
This is a follow-up to the series that contained both changes to the
aemif driver and platform code. It contains only the driver changes.
As the first step in removing duplicate support for aemif from the
kernel we need t
On 04/20/18 10:20, Roman Gushchin wrote:
>
> Hi, Randy!
>
> An updated version below.
>
> Thanks!
OK, looks good now. Thanks.
FWIW:
Reviewed-by: Randy Dunlap # for Documentation/ only.
>
>
>
> From 2225fa0b3400431dd803f206b20a934
This commit adds extension to the dw_mmc driver for Mellanox BlueField
SoC. It updates the UHS_REG_EXT register to bring up the eMMC card on
this SoC.
Signed-off-by: Liming Sun
---
.../devicetree/bindings/mmc/bluefield-dw-mshc.txt | 29 +
drivers/mmc/host/Kconfig
Add a selftest for the sparc64 privileged ADI driver. These
tests verify the read(), pread(), write(), pwrite(), and seek()
functionality of the driver. The tests also report simple
performance statistics:
Syscall CallAvgTime AvgSize
Count (ticks) (bytes)
--
SPARC M7 and newer processors utilize ADI to version and
protect memory. This driver is capable of reading/writing
ADI/MCD versions from privileged user space processes.
Addresses in the adi file are mapped linearly to physical
memory at a ratio of 1:adi_blksz. Thus, a read (or write)
of offset K
ADI is a feature supported on SPARC M7 and newer processors to allow
hardware to catch rogue accesses to memory. ADI is supported for data
fetches only and not instruction fetches. An app can enable ADI on its
data pages, set version tags on them and use versioned addresses to
access the data pages
On Fri, 20 Apr 2018, Ravi Chandra Sadineni wrote:
> On chromebooks we depend on wakeup count to identify the wakeup source.
> But currently USB devices do not increment the wakeup count when they
> trigger the remote wake. This patch addresses the same.
>
> Resume condition is reported differentl
On Fri, Apr 13, 2018 at 11:16:38AM -0700, Jakub Kicinski wrote:
> Currently the pcie_print_link_status() will print PCIe bandwidth
> and link width information but does not mention it is pertaining
> to the PCIe. Since this and related functions are used exclusively
> by networking drivers today u
On 2018-04-16 09:26:00 [+0200], Mike Galbraith wrote:
> On Fri, 2018-04-13 at 23:52 +0200, Sebastian Andrzej Siewior wrote:
> >
> > - Inter-event (latency) fixes by Tom Zanussi.
>
> CC kernel/trace/trace_events_hist.o
> kernel/trace/trace_events_hist.c: In function ‘__update_field_vars’:
This patch updates arm64 defconfig to enable dw_mmc-bluefield,
which is a driver extension of Synopsys Designware MMC for the
Mellanox BlueField Soc.
Signed-off-by: Liming Sun
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch
I noticed a similar problem with the tcon link leak on that (which
Colin and Gustavo pointed out - thank you!) but also in another return
statement, so updated the original patch of Ronnie's merging the fixes
https://git.samba.org/sfrench/cifs-2.6.git/?p=sfrench/cifs-2.6.git;a=commit;h=167bc5de08d
>
> Hi,
> I've attached it here.
>
> thanks,
> --
> ~Randy
Thanks. Darren's patch. It was supposed to be prevented by
32d7b19bad9695c4c9026b0ceb3a384561ddee70
(see comment in Kconfig).
#
# The DELL_SMBIOS driver depends on AC
Hi Sebastian,
On Fri, 2018-04-20 at 19:24 +0200, Sebastian Reichel wrote:
> The current reset-gpio support triggers an interrupt storm on platforms
> using the maxtouch with level based interrupt. The Motorola Droid 4,
> which I used for some of the tests is not affected, since it uses a level
> b
As reported by Randy Dunlap:
>> WARNING: unmet direct dependencies detected for DELL_SMBIOS
>> Depends on [m]: X86 [=y] && X86_PLATFORM_DEVICES [=y]
>> && (DCDBAS [=m] ||
>> DCDBAS [=m]=n) && (ACPI_WMI [=n] || ACPI_WMI [=n]=n)
>> Selected by [y]:
>> - DELL_LAPTOP [=y] && X86 [=y] && X86_
Hi Steve,
On 04/20/2018 12:37 PM, Steve French wrote:
I noticed a similar problem with the tcon link leak on that (which
Colin and Gustavo pointed out - thank you!) but also in another return
statement, so updated the original patch of Ronnie's merging the fixes
https://git.samba.org/sfrench/ci
> From: Jan Kara
> Sent: Friday, April 20, 2018 03:22
> On Thu 19-04-18 21:37:25, Dexuan Cui wrote:
> > > From: Jan Kara
> > > Sent: Thursday, April 19, 2018 13:23
> > > Good news guys, Robert has just spotted a bug which looks like what I'd
> > > expect can cause your lockups / crashes. I've merg
On Sat, Apr 21, 2018 at 12:58:33AM +0800, Chunyu Hu wrote:
> __GFP_NORETRY and __GFP_NOFAIL are combined in gfp_kmemleak_mask now.
> But it's a wrong combination. As __GFP_NOFAIL is blockable, but
> __GFP_NORETY is not blockable, make it self-contradiction.
>
> __GFP_NOFAIL means 'The VM implemen
On Fri, 20 Apr 2018 09:56:25 -0700
Song Liu wrote:
> Caller of uprobe_register is required to keep the inode and containing
> mount point referenced.
I would add a little more background to why this is the case. Also a
possible link to the conversation?
Link:
http://lkml.kernel.org/r/CAELBmZB2
On Fri, Apr 20, 2018 at 7:50 PM, Catalin Marinas
wrote:
> On Sat, Apr 21, 2018 at 12:58:33AM +0800, Chunyu Hu wrote:
>> __GFP_NORETRY and __GFP_NOFAIL are combined in gfp_kmemleak_mask now.
>> But it's a wrong combination. As __GFP_NOFAIL is blockable, but
>> __GFP_NORETY is not blockable, make i
On 04/20/18 10:42, Mario Limonciello wrote:
> As reported by Randy Dunlap:
>>> WARNING: unmet direct dependencies detected for DELL_SMBIOS
>>> Depends on [m]: X86 [=y] && X86_PLATFORM_DEVICES [=y]
>>> && (DCDBAS [=m] ||
>>> DCDBAS [=m]=n) && (ACPI_WMI [=n] || ACPI_WMI [=n]=n)
>>> Selected b
On chromebooks we depend on wakeup count to identify the wakeup source.
But currently USB devices do not increment the wakeup count when they
trigger the remote wake. This patch addresses the same.
Resume condition is reported differently on USB 2.0 and USB 3.0 devices.
On USB 2.0 devices, a wake
601 - 700 of 936 matches
Mail list logo
