On Sun, Sep 15, 2019 at 12:31:42PM -0700, Linus Torvalds wrote:
> On Sun, Sep 15, 2019 at 12:18 PM Willy Tarreau wrote:
> >
> > Oh no I definitely don't want this behavior at all for urandom, what
> > I'm saying is that as long as getrandom() will have a lower quality
> > of service than
On 9/15/19 9:39 AM, Al Viro wrote:
> On Sun, Sep 15, 2019 at 09:34:37AM -0700, Randy Dunlap wrote:
>> Kernel is 5.3-rc8 on x86_64.
>>
>> Loading and removing the pci-epf-test module causes a BUG.
>
> Ugh... Could you try to reproduce it on earlier kernels?
>
Sure... will get back to you.
--
Hi all,
Today's linux-next merge of the jc_docs tree got a conflict in:
Documentation/riscv/boot-image-header.rst
between commit:
474efecb65dceb15f ("riscv: modify the Image header to improve compatibility
with the ARM64 header")
from the riscv tree and commit:
638b642f82bb8ee81
On 9/15/19 2:40 AM, KP Singh wrote:
> On 15-Sep 00:33, Yonghong Song wrote:
>>
>>
>> On 9/10/19 12:55 PM, KP Singh wrote:
>>> From: KP Singh
>>>
>>> Adds a callback which is called when a new program is attached
>>> to a hook. The callback registered by the process_exection hook
>>> checks if a
'pih' is known to be non-NULL at this point, so the test can be removed.
Signed-off-by: Christophe JAILLET
---
drivers/net/wireless/broadcom/brcm80211/brcmsmac/main.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/main.c
On Sun, Sep 15, 2019 at 12:18 PM Willy Tarreau wrote:
>
> Oh no I definitely don't want this behavior at all for urandom, what
> I'm saying is that as long as getrandom() will have a lower quality
> of service than /dev/urandom for non-important randoms
Ahh, here you're talking about the fact
On 9/6/19 11:42 PM, Shuah Khan wrote:
> If vimc module is removed while streaming is in progress, sensor subdev
> unregister runs into general protection fault when it tries to unregister
> media entities. This is a common subdev problem related to releasing
> pads from
On 9/6/19 11:42 PM, Shuah Khan wrote:
> vimc driver is now a monolithic driver. Update the module parameter
> usage information to reflect that.
>
> Signed-off-by: Shuah Khan
Acked-by: Helen Koike
> ---
> Documentation/media/v4l-drivers/vimc.rst | 12 ++--
> 1 file changed, 6
Hi Shuah,
Thanks for the patch.
On 9/6/19 11:42 PM, Shuah Khan wrote:
> vimc uses Component API to split the driver into functional components.
> The real hardware resembles a monolith structure than component and
> component structure added a level of complexity making it hard to
> maintain
Hi Shuah,
On 9/6/19 11:42 PM, Shuah Khan wrote:
> Move duplicated IS_SRC and IS_SINK dfines to common header. Rename
> them to VIMC_IS_SRC and VIM_IS_SINK.
>
> Signed-off-by: Shuah Khan
> ---
> drivers/media/platform/vimc/vimc-common.h | 4
> drivers/media/platform/vimc/vimc-debayer.c |
On 9/6/19 11:42 PM, Shuah Khan wrote:
> After practically re-writing the driver to collpase it into a monolith,
> I am adding myself as a reviewer for vimc driver.
Thank you!
>
> Signed-off-by: Shuah Khan
Acked-by: Helen Koike
> ---
> MAINTAINERS | 1 +
> 1 file changed, 1 insertion(+)
On Sun, Sep 15, 2019 at 12:08:31PM -0700, Linus Torvalds wrote:
> My suggested patch left the /dev/random blocking behavior, because
> hopefully people *know* about the problems there.
>
> And hopefully people understand that getrandom(GRND_RANDOM) has all
> the same issues.
I think this one
Hi, RMS and Bruce Perens;
I noticed that recently Grsecurity's Brad Spengler (who sued you, Bruce,
for speaking the truth), decided to "Flex" and basically advertise while
chastising the linux community:
news.ycombinator.com/item?id=20874470
Another poster then pointed out the history of
On Sun, Sep 15, 2019 at 11:59:41AM -0700, Linus Torvalds wrote:
> > In addition, since you're leaving the door open to bikeshed around
> > the timeout valeue, I'd say that while 30s is usually not huge in a
> > desktop system's life, it actually is a lot in network environments
> > when it delays
On Sun, Sep 15, 2019 at 11:37 AM Willy Tarreau wrote:
>
> I also wanted to ask, are we going to enforce the same strategy on
> /dev/urandom ?
Right now the strategy for /dev/urandom is "print a one-line warning,
then do the read".
I don't see why we should change that. The whole point of
On Fri 2019-09-13 14:04:58, Greg Kroah-Hartman wrote:
> [ Upstream commit 72bbf9358c3676bd89dc4bd8fb0b1f2a11c288fc ]
>
> The state related to the VP assist page is still managed by the LAPIC
> code in the pv_eoi field.
I don't get it.
>
> +bool kvm_hv_assist_page_enabled(struct kvm_vcpu
On Sun, Sep 15, 2019 at 11:32 AM Willy Tarreau wrote:
>
> I think that the exponential decay will either not be used or
> be totally used, so in practice you'll always end up with 0 or
> 30s depending on the entropy situation
According to the systemd random-seed source snippet that Ahmed posted,
From: zhong jiang
Date: Fri, 13 Sep 2019 00:59:02 +0800
> mlx5_unload_one do not need local variable to store different value,
> Hence just remove it.
>
> Signed-off-by: zhong jiang
Saeed, just take this directly via one of your trees.
Thank you.
From: Alexandru Ardelean
Date: Thu, 12 Sep 2019 16:28:50 +0300
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
> b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
> index c141fe783e87..5b6213207c43 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
> +++
On Sun, Sep 15, 2019 at 01:25:02PM -0500, Eric W. Biederman wrote:
> ebied...@xmission.com (Eric W. Biederman) writes:
>
> > "Paul E. McKenney" writes:
> >
> >> So this looks good in and of itself, but I still do not see what prevents
> >> the unfortunate sequence of events called out in my
On Sun, Sep 15, 2019 at 10:07:24AM -0700, Linus Torvalds wrote:
> On Sun, Sep 15, 2019 at 7:32 AM Paul E. McKenney wrote:
> >
> > First, what am I looking for?
> >
> > I am looking for something that prevents the following:
> >
> > o Task A acquires a reference to Task B's task_struct while
From: Lucas A. M. Magalhaes
Add a virtual subdevice to simulate the flash control API.
Those are the supported controls:
v4l2-ctl -d /dev/v4l-subdev6 -L
Flash Controls
led_mode 0x009c0901 (menu) : min=0 max=2 default=0
value=0
0: Off
On Sun, Sep 15, 2019 at 2:43 PM Greg Kroah-Hartman
wrote:
>
> On Sat, Sep 14, 2019 at 10:08:35PM +0100, Okash Khawaja wrote:
> > On Mon, Sep 9, 2019 at 3:55 AM Gregory Nowak wrote:
> > >
> > > On Sun, Sep 08, 2019 at 10:43:02AM +0100, Okash Khawaja wrote:
> > > > Sorry, I have only now got round
I also wanted to ask, are we going to enforce the same strategy on
/dev/urandom ? If we don't because we fear application breakage or
whatever, then there will always be some incentive against migrating
to getrandom(). And if we do it, we know we have to take a reasonable
approach making the
On Fri, Sep 06, 2019 at 04:17:59PM +0100, Russell King - ARM Linux admin wrote:
> On Mon, Sep 02, 2019 at 12:36:56PM -0500, Eric W. Biederman wrote:
> > Russell King - ARM Linux admin writes:
> >
> > > On Fri, Aug 30, 2019 at 04:02:48PM -0500, Eric W. Biederman wrote:
> > >> Russell King - ARM
On Sun, Sep 15, 2019 at 10:32:15AM -0700, Linus Torvalds wrote:
> * We will block for at most 15 seconds at a time, and if called
> * sequentially will decrease the blocking amount so that we'll
> * block for at most 30s total - and if people continue to ask
> * for blocking, at that point
On Fri, Sep 13, 2019 at 1:26 AM Joe Perches wrote:
>
> Not every project is going to use only the clang-format tool.
Why? The end goal would be to enforce all code to be running under the
same formatting rules (which, in practice, means the same tool at the
moment).
Note that you can use
ebied...@xmission.com (Eric W. Biederman) writes:
> "Paul E. McKenney" writes:
>
>> So this looks good in and of itself, but I still do not see what prevents
>> the unfortunate sequence of events called out in my previous email.
>> On the other hand, if ->rcu and ->rcu_users were not allocated
On Fri, Sep 13, 2019 at 5:21 PM Greg Kroah-Hartman
wrote:
>
> Feel free to also take that patch through any tree, it's "obviously
> correct" :)
OK :) Picked all 6 in compiler-attributes:
https://github.com/ojeda/linux/commits/compiler-attributes
I added Ingo's Acks and fixed a minor typo
On Sun, 15 Sep 2019 18:31:33 +0100,
Palmer Dabbelt wrote:
Hi Palmer,
>
> On Sun, 15 Sep 2019 07:24:20 PDT (-0700), m...@kernel.org wrote:
> > On Thu, 12 Sep 2019 22:40:34 +0100,
> > Darius Rad wrote:
> >
> > Hi Darius,
> >
> >>
> >> As per the existing comment, irq_mask and irq_unmask do
"Michael Kerrisk (man-pages)" writes:
> Hello Eric,
>
> On 9/11/19 1:06 AM, Eric W. Biederman wrote:
>> "Michael Kerrisk (man-pages)" writes:
>>
>>> Hello Christian,
>>>
> All: I plan to add the following text to the manual page:
>
>new_root and put_old may be the same
"Paul E. McKenney" writes:
> So this looks good in and of itself, but I still do not see what prevents
> the unfortunate sequence of events called out in my previous email.
> On the other hand, if ->rcu and ->rcu_users were not allocated on top
> of each other by a union, I would be happy to
On Sun, Sep 15, 2019 at 10:53:00AM +0100, Jonathan Cameron wrote:
> On Sat, 14 Sep 2019 02:06:27 +0530
> Rohit Sarkar wrote:
>
> > Bcc:
> > Subject: [PATCH] staging: iio: adis16240: remove unused include
> > Reply-To:
> Something odd happened here with patch formatting. I fixed it up and
>
Hi all,
Today's linux-next merge of the s390 tree got a conflict in:
arch/s390/configs/debug_defconfig
between commit:
3361f3193c747e8b ("s390: update configs")
from the s390-fixes tree and commit:
3c2eb6b76cabb7d9 ("s390/crypto: Support for SHA3 via CPACF (MSA6)")
from the s390 tree.
On 9/4/19 9:06 AM, David Dai wrote:
> For high speed adapter like Mellanox CX-5 card, it can reach upto
> 100 Gbits per second bandwidth. Currently htb already supports 64bit rate
> in tc utility. However police action rate and peakrate are still limited
> to 32bit value (upto 32 Gbits per
[ Added Lennart, who was active in the other thread ]
On Sat, Sep 14, 2019 at 10:22 PM Theodore Y. Ts'o wrote:
>
> Thus, add an optional configuration option which stops getrandom(2)
> from blocking, but instead returns "best efforts" randomness, which
> might not be random or secure at all.
So
On Sun, 15 Sep 2019 07:24:20 PDT (-0700), m...@kernel.org wrote:
On Thu, 12 Sep 2019 22:40:34 +0100,
Darius Rad wrote:
Hi Darius,
As per the existing comment, irq_mask and irq_unmask do not need
to do anything for the PLIC. However, the functions must exist
(the pointers cannot be NULL) as
Hello,
syzbot found the following crash on:
HEAD commit:3120b9a6 Merge tag 'ipc-fixes' of git://git.kernel.org/pub..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=16b5c7fa60
kernel config: https://syzkaller.appspot.com/x/.config?x=861a6f31647968de
Hi all,
Today's linux-next merge of the mips tree got a conflict in:
drivers/video/fbdev/Makefile
between commit:
c7b46e0c33c5946 ("fbdev: remove w90x900/nuc900 platform drivers")
from the arm-soc tree and commit:
e305bff3a706f58 ("video/fbdev: Drop JZ4740 driver")
from the mips tree.
On Sat, 2019-09-14 at 18:51 +0200, Christophe Leroy wrote:
>
> Le 14/09/2019 à 16:34, Scott Wood a écrit :
> > On Fri, 2019-08-23 at 12:50 +, Christophe Leroy wrote:
> > > On mpc83xx with a QE, IMMR is 2Mbytes.
> > > On mpc83xx without a QE, IMMR is 1Mbytes.
> > > Each driver will map a part
Currently, kmalloc_cache[] is not sorted by size, kmalloc_cache[0]
is kmalloc-96, kmalloc_cache[1] is kmalloc-192 (when ARCH_DMA_MINALIGN
is not defined).
As suggested by Vlastimil Babka,
"Since you're doing these cleanups, have you considered reordering
kmalloc_info, size_index, kmalloc_index()
KMALLOC_NORMAL is the most frequently accessed, and kmalloc_caches[]
is initialized by different types of the same size.
So modifying kmalloc_caches[type][idx] to kmalloc_caches[idx][type]
will benefit performance.
$ ./scripts/bloat-o-meter vmlinux.patch_1-6 vmlinux.patch_1-7
add/remove: 0/0
The type of local variable *type* of new_kmalloc_cache() should
be enum kmalloc_cache_type instead of int, so correct it.
Signed-off-by: Pengfei Li
Acked-by: Vlastimil Babka
Acked-by: Roman Gushchin
---
mm/slab_common.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git
This is a preparation patch, just replace 0 with ZERO_SIZE_ALLOC
as the return value of zero sized requests.
Signed-off-by: Pengfei Li
---
include/linux/slab.h | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/include/linux/slab.h b/include/linux/slab.h
index
In the current implementation, KMALLOC_RECLAIM is not initialized
until all the KMALLOC_NORMAL sizes have been initialized.
But for a particular size, create_kmalloc_caches() can be executed
faster by initializing different types of kmalloc in order.
$ ./scripts/bloat-o-meter vmlinux.old
The size of kmalloc can be obtained from kmalloc_info[],
so remove kmalloc_size() that will not be used anymore.
Signed-off-by: Pengfei Li
Acked-by: Vlastimil Babka
Acked-by: Roman Gushchin
---
include/linux/slab.h | 20
mm/slab.c| 5 +++--
mm/slab_common.c
From: Sanjay R Mehta
The AMD new hardware uses BAR23 and BAR45 as memory windows
as compared to previos where BAR1, BAR23 and BAR45 is used
for memory windows.
This patch add support for both AMD hardwares.
Signed-off-by: Sanjay R Mehta
---
drivers/ntb/hw/amd/ntb_hw_amd.c | 23
There are three types of kmalloc, KMALLOC_NORMAL, KMALLOC_RECLAIM
and KMALLOC_DMA.
The name of KMALLOC_NORMAL is contained in kmalloc_info[].name,
but the names of KMALLOC_RECLAIM and KMALLOC_DMA are dynamically
generated by kmalloc_cache_name().
This patch predefines the names of all types of
Changes in v4
--
1. [old] abandon patch 4/4
2. [new] patch 4/7:
- return ZERO_SIZE_ALLOC instead 0 for zero sized requests
3. [new] patch 5/7:
- reorder kmalloc_info[], kmalloc_caches[] (in order of size)
- hard to split, so slightly larger
4. [new] patch 6/7:
- initialize
On Sun, Sep 15, 2019 at 7:32 AM Paul E. McKenney wrote:
>
> First, what am I looking for?
>
> I am looking for something that prevents the following:
>
> o Task A acquires a reference to Task B's task_struct while
> protected only by RCU, and is just about to increment ->rcu_users
>
From: Sanjay R Mehta
Signed-off-by: Sanjay R Mehta
---
drivers/ntb/hw/amd/ntb_hw_amd.c | 3 ++-
drivers/ntb/hw/amd/ntb_hw_amd.h | 1 -
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/ntb/hw/amd/ntb_hw_amd.c b/drivers/ntb/hw/amd/ntb_hw_amd.c
index 2859cc9..e9286cf 100644
Hi all,
Today's linux-next merge of the ia64 tree got a conflict in:
arch/ia64/hp/common/sba_iommu.c
between commit:
f9f3232a7d0ab73 ("dma-mapping: explicitly wire up ->mmap and ->get_sgtable")
from the dma-mapping tree and commit:
974f83ec1e5afee ("ia64: rework iommu probing")
On Sat, Sep 14, 2019 at 11:56 PM Lennart Poettering
wrote:
>
> I am not expecting the kernel to guarantee entropy. I just expecting
> the kernel to not give me garbage knowingly. It's OK if it gives me
> garbage unknowingly, but I have a problem if it gives me trash all the
> time.
So
On 15/09/2019 04:07, shikemeng wrote:
> From:
>
> reason: migration to invalid cpu in __set_cpus_allowed_ptr
> archive path: patches/euleros/sched
>
> Oops occur when running qemu on arm64:
> Unable to handle kernel paging request at virtual address 08effe40
> Internal error: Oops:
On Sun, Sep 15, 2019 at 09:34:37AM -0700, Randy Dunlap wrote:
> Kernel is 5.3-rc8 on x86_64.
>
> Loading and removing the pci-epf-test module causes a BUG.
Ugh... Could you try to reproduce it on earlier kernels?
On Fri 2019-09-13 14:04:57, Greg Kroah-Hartman wrote:
> [ Upstream commit 87ee613d076351950b74383215437f841ebbeb75 ]
>
> In most common cases VP index of a vcpu matches its vcpu index. Userspace is,
> however,
> free to set any mapping it wishes and we need to account for that when we
> need
KMALLOC_NORMAL is the most frequently accessed, and kmalloc_caches[]
is initialized by different types of the same size.
So modifying kmalloc_caches[type][idx] to kmalloc_caches[idx][type]
will benefit performance.
$ ./scripts/bloat-o-meter vmlinux.patch_1-6 vmlinux.patch_1-7
add/remove: 0/0
KMALLOC_NORMAL is the most frequently accessed, and kmalloc_caches[]
is initialized by different types of the same size.
So modifying kmalloc_caches[type][idx] to kmalloc_caches[idx][type]
will benefit performance.
$ ./scripts/bloat-o-meter vmlinux.patch_1-6 vmlinux.patch_1-7
add/remove: 0/0
In the current implementation, KMALLOC_RECLAIM is not initialized
until all the KMALLOC_NORMAL sizes have been initialized.
But for a particular size, create_kmalloc_caches() can be executed
faster by initializing different types of kmalloc in order.
$ ./scripts/bloat-o-meter vmlinux.old
This is a preparation patch, just replace 0 with ZERO_SIZE_ALLOC
as the return value of zero sized requests.
Signed-off-by: Pengfei Li
---
include/linux/slab.h | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/include/linux/slab.h b/include/linux/slab.h
index
This is a preparation patch, just replace 0 with ZERO_SIZE_ALLOC
as the return value of zero sized requests.
Signed-off-by: Pengfei Li
---
include/linux/slab.h | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/include/linux/slab.h b/include/linux/slab.h
index
In the current implementation, KMALLOC_RECLAIM is not initialized
until all the KMALLOC_NORMAL sizes have been initialized.
But for a particular size, create_kmalloc_caches() can be executed
faster by initializing different types of kmalloc in order.
$ ./scripts/bloat-o-meter vmlinux.old
Currently, kmalloc_cache[] is not sorted by size, kmalloc_cache[0]
is kmalloc-96, kmalloc_cache[1] is kmalloc-192 (when ARCH_DMA_MINALIGN
is not defined).
As suggested by Vlastimil Babka,
"Since you're doing these cleanups, have you considered reordering
kmalloc_info, size_index, kmalloc_index()
Currently, kmalloc_cache[] is not sorted by size, kmalloc_cache[0]
is kmalloc-96, kmalloc_cache[1] is kmalloc-192 (when ARCH_DMA_MINALIGN
is not defined).
As suggested by Vlastimil Babka,
"Since you're doing these cleanups, have you considered reordering
kmalloc_info, size_index, kmalloc_index()
The type of local variable *type* of new_kmalloc_cache() should
be enum kmalloc_cache_type instead of int, so correct it.
Signed-off-by: Pengfei Li
Acked-by: Vlastimil Babka
Acked-by: Roman Gushchin
---
mm/slab_common.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git
The size of kmalloc can be obtained from kmalloc_info[],
so remove kmalloc_size() that will not be used anymore.
Signed-off-by: Pengfei Li
Acked-by: Vlastimil Babka
Acked-by: Roman Gushchin
---
include/linux/slab.h | 20
mm/slab.c| 5 +++--
mm/slab_common.c
The type of local variable *type* of new_kmalloc_cache() should
be enum kmalloc_cache_type instead of int, so correct it.
Signed-off-by: Pengfei Li
Acked-by: Vlastimil Babka
Acked-by: Roman Gushchin
---
mm/slab_common.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git
Changes in v4
--
1. [old] abandon patch 4/4
2. [new] patch 4/7:
- return ZERO_SIZE_ALLOC instead 0 for zero sized requests
3. [new] patch 5/7:
- reorder kmalloc_info[], kmalloc_caches[] (in order of size)
- hard to split, so slightly larger
4. [new] patch 6/7:
- initialize
There are three types of kmalloc, KMALLOC_NORMAL, KMALLOC_RECLAIM
and KMALLOC_DMA.
The name of KMALLOC_NORMAL is contained in kmalloc_info[].name,
but the names of KMALLOC_RECLAIM and KMALLOC_DMA are dynamically
generated by kmalloc_cache_name().
This patch predefines the names of all types of
Since add_probe_trace_event() can reuse tf->tevs[i] after
calling clear_probe_trace_event(), this can make perf-probe
crash if the 1st attempt of probe event finding fails to find
an event argument, and the 2nd attempt fails to find probe point.
E.g.
$ perf probe -D "task_pid_nr tsk"
Failed
Kernel is 5.3-rc8 on x86_64.
Loading and removing the pci-epf-test module causes a BUG.
[40928.435755] calling pci_epf_test_init+0x0/0x1000 [pci_epf_test] @ 12132
[40928.436717] initcall pci_epf_test_init+0x0/0x1000 [pci_epf_test] returned 0
after 891 usecs
[40936.996081]
On Sat, Sep 14, 2019 at 11:51 PM Lennart Poettering
wrote:
>
> Oh man. Just spend 5min to understand the situation, before claiming
> this was garbage or that was garbage. The code above does not block
> boot.
Yes it does. You clearly didn't read the thread.
> It blocks startup of services that
Hi Dan,
On 9/11/19 8:01 PM, Dan Murphy wrote:
> Update the lp5523 to use the multi color framework.
>
> Signed-off-by: Dan Murphy
> ---
> drivers/leds/leds-lp5523.c| 13 +++
> drivers/leds/leds-lp55xx-common.c | 131 ++
>
Dan,
On 9/11/19 8:01 PM, Dan Murphy wrote:
> Introduce a multicolor class that groups colored LEDs
> within a LED node.
>
> The framework allows for dynamically setting individual LEDs
> or setting brightness levels of LEDs and updating them virtually
> simultaneously.
>
> Signed-off-by: Dan
Hi Greg,
On Sun, Sep 15, 2019 at 10:54 PM Greg KH wrote:
> Note, this just showed up publically on August 12, where were you with
> all of this new code before then? :)
My sdFAT port, exfat-nofuse and the one on the staging tree, were all
made by Samsung.
And unless you guys had a chance to
On 9/15/19 5:58 AM, Greg Kroah-Hartman wrote:
On Sat, Sep 14, 2019 at 05:49:32PM -0700, Guenter Roeck wrote:
Hi Greg,
On 9/14/19 1:31 AM, Greg Kroah-Hartman wrote:
On Sat, Sep 14, 2019 at 01:28:39AM -0700, Guenter Roeck wrote:
On 9/13/19 6:06 AM, Greg Kroah-Hartman wrote:
This is the start
On Sun, 15 Sep 2019 15:54:16 +0200,
Stefan Wahren wrote:
>
> Hi Takashi,
>
> Am 14.09.19 um 17:24 schrieb Takashi Iwai:
> > The PCM draining behavior got broken since the recent refactoring, and
> > this turned out to be the incorrect expectation of the firmware
> > behavior regarding
On Mon, Sep 09, 2019 at 05:28:08PM +0100, Jarkko Sakkinen wrote:
> On Sat, Sep 07, 2019 at 06:04:48PM -0400, Sasha Levin wrote:
> > On Sat, Sep 07, 2019 at 09:55:18PM +0300, Jarkko Sakkinen wrote:
> > > On Tue, 2019-09-03 at 15:43 -0400, Sasha Levin wrote:
> > > > Right. I gave a go at backporting
On 9/14/2019 8:29 AM, Andrew Lunn wrote:
> On Thu, Sep 12, 2019 at 07:28:12PM +0300, Alexandru Ardelean wrote:
>
>> +static int adin_set_edpd(struct phy_device *phydev, u16 tx_interval)
>> +{
>> +u16 val;
>> +
>> +if (tx_interval == ETHTOOL_PHY_EDPD_DISABLE)
>> +return
On 9/12/2019 9:28 AM, Alexandru Ardelean wrote:
> The `phy_tunable_id` has been named `ETHTOOL_PHY_EDPD` since it looks like
> this feature is common across other PHYs (like EEE), and defining
> `ETHTOOL_PHY_ENERGY_DETECT_POWER_DOWN` seems too long.
>
> The way EDPD works, is that the RX block
Hi David, [+Peter]
I have a few drive-by comments on the ordering side of things. See below.
On Fri, Sep 13, 2019 at 02:00:39PM +0100, David Howells wrote:
> Convert pipes to use head and tail pointers for the buffer ring rather than
> pointer and length as the latter requires two atomic ops to
On Sun, Sep 15, 2019 at 04:42:52PM +0200, Andrew Lunn wrote:
> > > OF: fdt: Machine model: SolidRun HummingBoard Solo/DualLite
> > > ...
> > > # ethtool eth0
> > > Settings for eth0:
> > > Supported ports: [ TP MII ]
> > > Supported link modes: 10baseT/Half 10baseT/Full
> > >
--
Hi , can we talk about this please?
> > OF: fdt: Machine model: SolidRun HummingBoard Solo/DualLite
> > ...
> > # ethtool eth0
> > Settings for eth0:
> > Supported ports: [ TP MII ]
> > Supported link modes: 10baseT/Half 10baseT/Full
> > 100baseT/Half 100baseT/Full
> >
On Sat, Sep 14, 2019 at 07:35:02AM -0500, Eric W. Biederman wrote:
>
> The current task on the runqueue is currently read with rcu_dereference().
>
> To obtain ordinary rcu semantics for an rcu_dereference of rq->curr it needs
> to be paird with rcu_assign_pointer of rq->curr. Which provides
On 15/09/2019 09:21, shikemeng wrote:
>> It's more thoughtful to add check in cpumask_test_cpu.It can solve this
>> problem and can prevent other potential bugs.I will test it and resend
>> a new patch.
>>
>
> Think again and again. As cpumask_check will fire a warning if cpu >=
> nr_cpu_ids,
On Sat, Sep 14, 2019 at 07:34:30AM -0500, Eric W. Biederman wrote:
>
> Remove work arounds that were written before there was a grace period
> after tasks left the runqueue in finish_task_switch.
>
> In particular now that there tasks exiting the runqueue exprience
> a rcu grace period none of
On Thu, 12 Sep 2019 22:40:34 +0100,
Darius Rad wrote:
Hi Darius,
>
> As per the existing comment, irq_mask and irq_unmask do not need
> to do anything for the PLIC. However, the functions must exist
> (the pointers cannot be NULL) as they are not optional, based on
> the documentation
On Sun, Sep 15, 2019 at 03:06:39PM +0100, Russell King - ARM Linux admin wrote:
> On Sun, Sep 15, 2019 at 03:56:52PM +0200, Andrew Lunn wrote:
> > > Tinywrkb confirmed to me in private communication that revert of
> > > 5502b218e001 fixes Ethernet for him on effected system.
> > >
> > > He also
On Fri, Sep 13, 2019 at 07:12:52AM +0800, Aubrey Li wrote:
> On Thu, Sep 12, 2019 at 8:04 PM Aaron Lu wrote:
> >
> > On Wed, Sep 11, 2019 at 09:19:02AM -0700, Tim Chen wrote:
> > > On 9/11/19 7:02 AM, Aaron Lu wrote:
> > > I think Julien's result show that my patches did not do as well as
> > >
On Sun, Sep 15, 2019 at 07:07:52AM -0700, Paul E. McKenney wrote:
> On Sat, Sep 14, 2019 at 07:33:58AM -0500, Eric W. Biederman wrote:
> >
> > In the ordinary case today the rcu grace period for a task_struct is
> > triggered when another process wait's for it's zombine and causes the
Oh, and
On Sat, Sep 14, 2019 at 07:33:58AM -0500, Eric W. Biederman wrote:
>
> In the ordinary case today the rcu grace period for a task_struct is
> triggered when another process wait's for it's zombine and causes the
> kernel to call release_task(). As the waiting task has to receive a
> signal and
On Sun, Sep 15, 2019 at 03:56:52PM +0200, Andrew Lunn wrote:
> > Tinywrkb confirmed to me in private communication that revert of
> > 5502b218e001 fixes Ethernet for him on effected system.
> >
> > He also referred me to an old Cubox-i spec that lists 10/100 Ethernet
> > only for i.MX6
If the return value of vhci_init_attr_group and
sysfs_create_group is non-zero, which mean they failed
to init attr_group and create sysfs group, so it would
better add 'failed' message to indicate that.
This patch also change pr_err to dev_err to trace which
device is failed.
Fixes: 0775a9cbc694
Dan,
This patch has the same issues I mentioned in the v4 review [0].
On 9/11/19 8:01 PM, Dan Murphy wrote:
> Add DT bindings for the LEDs multicolor class framework.
>
> Signed-off-by: Dan Murphy
> ---
> .../bindings/leds/leds-class-multicolor.txt | 96 +++
> 1 file
On Sun, Sep 15, 2019 at 02:47:00PM +0100, Jonathan Cameron wrote:
> On Sun, 15 Sep 2019 14:39:17 +0100
> Jonathan Cameron wrote:
>
> > On Sun, 15 Sep 2019 14:57:56 +0900
> > William Breathitt Gray wrote:
> >
> > > The count_read and count_write callbacks are simplified to pass val as
> > >
Hi Dan,
On 9/11/19 8:01 PM, Dan Murphy wrote:
> Add a documentation of LED Multicolor LED class specific
> sysfs attributes.
>
> Signed-off-by: Dan Murphy
> ---
> .../ABI/testing/sysfs-class-led-multicolor| 73 +++
> 1 file changed, 73 insertions(+)
> create mode 100644
> Tinywrkb confirmed to me in private communication that revert of
> 5502b218e001 fixes Ethernet for him on effected system.
>
> He also referred me to an old Cubox-i spec that lists 10/100 Ethernet
> only for i.MX6 Solo/DualLite variants of Cubox-i. It turns out that
> there was a plan to use a
On Sat, Sep 14, 2019 at 07:33:34AM -0500, Eric W. Biederman wrote:
>
> Add a count of the number of rcu users (currently 1) of the task
> struct so that we can later add the scheduler case and get rid of the
> very subtle task_rcu_dereference, and just use rcu_dereference.
>
> As suggested by
Hi Takashi,
Am 14.09.19 um 17:24 schrieb Takashi Iwai:
> The PCM draining behavior got broken since the recent refactoring, and
> this turned out to be the incorrect expectation of the firmware
> behavior regarding "draining". While I expected the "drain" flag at
> the stop operation would do
101 - 200 of 281 matches
Mail list logo
