On Sat, Aug 17, 2019 at 02:54:26AM -0400, Matthew Hanzelik wrote:
> Fixed an unnamed parameter style issue.
>
> Signed-off-by: Matthew Hanzelik
> ---
> drivers/staging/speakup/spk_types.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/speakup/spk_types.
* Adam Ford [190816 23:02]:
> On Wed, Aug 14, 2019 at 8:16 AM Tony Lindgren wrote:
> > Well I just posted some sgx interconnect target module patches. We might
> > still have them in v5.4 assuming people manage to review and test them.
>
> Nikolaus,
>
> I tested Tony's change and I can confirm
In cx24117_load_firmware(), 'buf' is allocated through kmalloc() to hold
the firmware. However, if i2c_transfer() fails, it is not deallocated,
leading to a memory leak bug.
Signed-off-by: Wenwen Wang
---
drivers/media/dvb-frontends/cx24117.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion
On 16-08-19, 09:55, Srinivas Kandagatla wrote:
>
>
> On 16/08/2019 01:10, syzbot wrote:
> > syzbot has bisected this bug to:
> >
> > commit 2aeac95d1a4cc85aae57ab842d5c3340df0f817f
> > Author: Srinivas Kandagatla
> > Date: Tue Jun 11 10:40:41 2019 +
> >
> > soundwire: add module_sdw
Hi.
I just found the following error in the output from dmesg.
[ 4023.460058] iwlwifi :02:00.0: Microcode SW error detected. Restarting
0x0.
[ 4023.460178] iwlwifi :02:00.0: Start IWL Error Log Dump:
[ 4023.460179] iwlwifi :02:00.0: Status: 0x0080, count: 6
[ 4023.460180] iwlwifi
On Sat, 2019-08-17 at 12:05 +0530, Rishi Gupta wrote:
> An extra 'for' word is grammatically incorrect in the comment
> 'verifying ops for multi-parent clks'. This commit removes
> this extra for word.
A few other repeated word typos in comments are
common in the kernel and most could be changed.
On Fri, Aug 16, 2019 at 11:41 PM Stephen Rothwell wrote:
>
> I certainly prefer that method of API change :-)
> (see the current "keys: Replace uid/gid/perm permissions checking with
> an ACL" in linux-next
Side note: I will *not* be pulling that again.
It was broken last time, and without more
On Fri, Aug 16, 2019, 18:36 Mathieu Desnoyers
wrote:
>
> If WRITE_ONCE has any use at all (protecting against store tearing and
> invented stores), it should be used even with a lock held in this
> scenario, because the lock does not prevent READ_ONCE() from observing
> transient states caused by
Commit-ID: 12ece2d53d3e8f827e972caf497c165f7729c717
Gitweb: https://git.kernel.org/tip/12ece2d53d3e8f827e972caf497c165f7729c717
Author: Tony Luck
AuthorDate: Thu, 15 Aug 2019 11:16:24 -0700
Committer: Borislav Petkov
CommitDate: Sat, 17 Aug 2019 10:06:32 +0200
x86/cpu: Explain Intel mo
On 12/08/2019 19:56, Eric Dumazet wrote:
>
>
> On 8/12/19 2:50 PM, Sander Eikelenboom wrote:
>> L.S.,
>>
>> While testing a somewhere-after-5.3-rc3 kernel (which included the latest
>> net merge (33920f1ec5bf47c5c0a1d2113989bdd9dfb3fae9),
>> one of my Xen VM's (which gets quite some network load
In pinctrl-spmi-gpio.c there is a switch case which is obviously
intended to fall through to the next label. Add a comment to suppress
-Wimplicit-fallthrough warning.
Signed-off-by: Alex Dewar
---
drivers/pinctrl/qcom/pinctrl-spmi-gpio.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/driver
On Sat, Aug 17, 2019 at 02:04:34AM +0200, Marek Behun wrote:
> On Fri, 16 Aug 2019 23:41:06 +0100
> Colin King wrote:
>
> > From: Colin Ian King
> >
> > Currently the size_t variable res is being checked for
> > an error failure however the unsigned variable is never
> > less than zero so this
On Fri, Aug 16, 2019 at 9:52 PM Paul E. McKenney wrote:
>
> > I'd love to have a flag that says "all undefined behavior is treated
> > as implementation-defined". There's a somewhat subtle - but very
> > important - difference there.
>
> It would also be nice to downgrade some of the undefined beh
Commit-ID: bba10c5cab4ddd8725a7998e064fc72c9770c667
Gitweb: https://git.kernel.org/tip/bba10c5cab4ddd8725a7998e064fc72c9770c667
Author: Rahul Tanwar
AuthorDate: Fri, 16 Aug 2019 16:18:57 +0800
Committer: Borislav Petkov
CommitDate: Sat, 17 Aug 2019 10:34:09 +0200
x86/cpu: Use constant
On Sat, Aug 17, 2019 at 1:28 AM Linus Torvalds
wrote:
>
>unsigned int bits = some_global_value;
>...test different bits in in 'bits' ...
>
> can easily cause multiple reads (particularly on a CPU that has a
> "test bits in memory" instruction and a lack of registers.
>
> So then doing it a
On Sat, Aug 17, 2019 at 11:00:13AM +0800, Zhaoyang Huang wrote:
> From: Zhaoyang Huang
>
> pfn_valid can be wrong while the MSB of physical address be trimed as pfn
> larger than the max_pfn.
How the overflow of __pfn_to_phys() is related to max_pfn?
Where is the guarantee that __pfn_to_phys(max
Hi Adam,
> Am 17.08.2019 um 01:01 schrieb Adam Ford :
>
>
> Nikolaus,
>
> I tested Tony's change and I can confirm that I can read the value
> when enabled. Should I apply his patches to your branch before I
> test, or is it go too to go as-is?
My branch is currently as-is and not aware of To
Unlike BUG_ON(x), WARN_ON(x) uses !!(x) as the trigger
of the t(d/w)nei instruction instead of using directly the
value of x.
This leads to GCC adding unnecessary pair of addic/subfe. This was
revealed after adding a WARN_ON() on top of clear_page() in order
to detect misaligned destination:
@@ -
> I am on an Intel(R) Core(TM) i7-7500U CPU @ 2.70GHz running Linux
> x86_64 (Slackware), with a custom-compiled 5.3.0-rc4 (.config
> attached).
>
> I am using the Intel wifi adapter on this machine:
>
> 02:00.0 Network controller: Intel Corporation Device 24fb (rev 10)
>
> with the iwlwifi drive
On Sat, Aug 17, 2019 at 5:00 PM Mike Rapoport wrote:
>
> On Sat, Aug 17, 2019 at 11:00:13AM +0800, Zhaoyang Huang wrote:
> > From: Zhaoyang Huang
> >
> > pfn_valid can be wrong while the MSB of physical address be trimed as pfn
> > larger than the max_pfn.
>
> How the overflow of __pfn_to_phys()
3.16.73-rc1 review patch. If anyone has any objections, please let me know.
--
From: "zhangyi (F)"
commit 5e86bdda41534e17621d5a071b294943cae4376e upstream.
Currently, we are releasing the indirect buffer where we are done with
it in ext4_ind_remove_space(), so we can see the
3.16.73-rc1 review patch. If anyone has any objections, please let me know.
--
From: Ben Hutchings
Denis Andzakovic discovered a potential use-after-free in older kernel
versions, using syzkaller. tcp_write_queue_purge() frees all skbs in
the TCP write queue and can leave sk->
3.16.73-rc1 review patch. If anyone has any objections, please let me know.
--
From: "Jason A. Donenfeld"
commit 1ae2324f732c9c4e2fa4ebd885fa1001b70d52e1 upstream.
HalfSipHash, or hsiphash, is a shortened version of SipHash, which
generates 32-bit outputs using a weaker 64-bit
This is the start of the stable review cycle for the 3.16.73 release.
There are 4 patches in this series, which will be posted as responses
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Mon Aug 19 20:00:00 UTC 2019.
Anything receiv
3.16.73-rc1 review patch. If anyone has any objections, please let me know.
--
From: "zhangyi (F)"
commit 674a2b27234d1b7afcb0a9162e81b2e53aeef217 upstream.
All indirect buffers get by ext4_find_shared() should be released no
mater the branch should be freed or not. But now, w
This patch cleans up the if(page).
No functional change.
Signed-off-by: Pengfei Li
---
mm/page_alloc.c | 28
1 file changed, 16 insertions(+), 12 deletions(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 272c6de1bf4e..51f056ac09f5 100644
--- a/mm/page_alloc
> On Aug 16, 2019, at 11:57 PM, Dan Williams wrote:
>
> On Fri, Aug 16, 2019 at 8:34 PM Qian Cai wrote:
>>
>>
>>
>>> On Aug 16, 2019, at 5:48 PM, Dan Williams wrote:
>>>
>>> On Fri, Aug 16, 2019 at 2:36 PM Qian Cai wrote:
Every so often recently, booting Intel CPU server on l
On 8/17/19 3:35 AM, Ben Hutchings wrote:
This is the start of the stable review cycle for the 3.16.73 release.
There are 4 patches in this series, which will be posted as responses
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Mo
In vfio_pci_enable(), save the device's initial configuration information
and then restore the configuration in vfio_pci_disable(). However, the
execution result is not the same. Since the pci_try_reset_function()
function saves the current state before resetting, the configuration
information rest
Greetings to you,
I am Mrs.Margaret Ko May-Yee Leung Managing and Executive Director of Chong
Hing Bank Limited. I contact you briefly in regard of a profitable business
proposal i have to share with you, your collaboration is needed in a
multi-million transaction with good return for us on
Hello, I am an America Jackpot winner, I have a donation of $7,800,000.00 for
you to assist your community. Kindly contact me for more information at :
(jbasson...@aol.com)
David.
On Sat, Aug 17, 2019 at 11:59:59AM +0300, Serge Belyshev wrote:
> It looks like that:
>
> commit 4fd445a2c855bbcab81fbe06d110e78dbd974a5b
> Author: Haim Dreyfuss
> Date: Thu May 2 11:45:02 2019 +0300
>
> iwlwifi: mvm: Add log information about SAR status
>
> Inform users when SAR
On Fri 2019-08-16 14:27:28, Matthias Kaehlcke wrote:
> On Fri, Aug 16, 2019 at 10:13:42PM +0200, Pavel Machek wrote:
> > On Tue 2019-08-13 12:11:47, Matthias Kaehlcke wrote:
> > > Add a .config_led hook which is called by the PHY core when
> > > configuration data for a PHY LED is available. Each L
Reading the sched_cmdline_ref and sched_tgid_ref initial state within
tracing_start_sched_switch without holding the sched_register_mutex is
racy against concurrent updates, which can lead to tracepoint probes
being registered more than once (and thus trigger warnings within
tracepoint.c).
[ Compi
Linus,
I2C has one revert because of a regression, two fixes for tiny race
windows (which we were not able to trigger), a MAINTAINERS addition, and
a SPDX fix.
Please pull.
Thanks,
Wolfram
The following changes since commit d45331b00ddb179e291766617259261c112db872:
Linux 5.3-rc4 (2019-0
- On Aug 16, 2019, at 3:15 PM, rostedt rost...@goodmis.org wrote:
> On Fri, 16 Aug 2019 13:19:20 -0400 (EDT)
> Mathieu Desnoyers wrote:
>
>> - On Aug 16, 2019, at 12:25 PM, rostedt rost...@goodmis.org wrote:
>>
>> > On Fri, 16 Aug 2019 10:26:43 -0400 Mathieu Desnoyers
>> > wrote:
>> >
- On Aug 16, 2019, at 10:13 PM, rostedt rost...@goodmis.org wrote:
> On Fri, 16 Aug 2019 21:36:49 -0400 (EDT)
> Mathieu Desnoyers wrote:
>
>> - On Aug 16, 2019, at 5:04 PM, Linus Torvalds
>> torva...@linux-foundation.org
>> wrote:
>>
>> > On Fri, Aug 16, 2019 at 1:49 PM Thomas Gleixner
Hi!
On Tue, Aug 13, 2019 at 11:51 PM Rob Herring wrote:
> [...]
> > +Example:
> > + pll {
> > + compatible = "mediatek,mt7621-pll";
>
> You didn't answer Stephen's question on v1.
I thought he was asking why there's a syscon in compatible string. I
noticed that the syscon in my p
Thanks Joe for higlighting this. I am going
to send patches for them as well soon.
- On Aug 17, 2019, at 4:44 AM, Linus Torvalds torva...@linux-foundation.org
wrote:
>
> But I'm seeing a lot of WRITE_ONCE(x, constantvalue) kind of things
> and don't seem to find a lot of reason to think that they are any
> inherently better than "x = constantvalue".
If the only states tha
On Sat, 17 Aug 2019 10:40:31 -0400 (EDT)
Mathieu Desnoyers wrote:
> > I'm now even more against adding the READ_ONCE() or WRITE_ONCE().
>
> I'm not convinced by your arguments.
Prove to me that there's an issue here beyond theoretical analysis,
then I'll consider that patch.
Show me a compil
syzbot has bisected this bug to:
commit bc389fd101e57b36aacfaec2df8fe479eabb44ea
Author: David S. Miller
Date: Tue Jul 2 21:12:30 2019 +
Merge branch 'macsec-fix-some-bugs-in-the-receive-path'
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=125c5c4c60
start commit:
Hi,
Am 17.08.19 um 16:42 schrieb Chuanhong Guo:
Hi!
On Tue, Aug 13, 2019 at 11:51 PM Rob Herring wrote:
[...]
+Example:
+ pll {
+ compatible = "mediatek,mt7621-pll";
You didn't answer Stephen's question on v1.
I thought he was asking why there's a syscon in compatible str
Hi,
Am 17.08.19 um 16:42 schrieb Chuanhong Guo:
Hi!
On Tue, Aug 13, 2019 at 11:51 PM Rob Herring wrote:
[...]
+Example:
+ pll {
+ compatible = "mediatek,mt7621-pll";
You didn't answer Stephen's question on v1.
I thought he was asking why there's a syscon in compatible str
On Sat, 17 Aug 2019 10:27:39 -0400 (EDT)
Mathieu Desnoyers wrote:
> I get your point wrt WRITE_ONCE(): since it's a cache it should not have
> user-visible effects if a temporary incorrect value is observed. Well in
> reality, it's not a cache: if the lookup fails, it returns "<...>" instead,
> s
- On Aug 17, 2019, at 11:42 AM, rostedt rost...@goodmis.org wrote:
> On Sat, 17 Aug 2019 10:27:39 -0400 (EDT)
> Mathieu Desnoyers wrote:
>
>> I get your point wrt WRITE_ONCE(): since it's a cache it should not have
>> user-visible effects if a temporary incorrect value is observed. Well in
>
- On Aug 17, 2019, at 11:26 AM, rostedt rost...@goodmis.org wrote:
> On Sat, 17 Aug 2019 10:40:31 -0400 (EDT)
> Mathieu Desnoyers wrote:
>
>> > I'm now even more against adding the READ_ONCE() or WRITE_ONCE().
>>
>> I'm not convinced by your arguments.
>
> Prove to me that there's an issue
On Wed, Aug 14, 2019 at 10:47:11AM +0300, Felipe Balbi wrote:
> The current version of the IOCTL have a small problem which prevents us
> from extending the API by making use of reserved fields. In these new
> IOCTLs, we are now making sure that flags and rsv fields are zero which
> will allow us t
On Wed, Aug 14, 2019 at 10:47:12AM +0300, Felipe Balbi wrote:
> diff --git a/include/uapi/linux/ptp_clock.h b/include/uapi/linux/ptp_clock.h
> index 039cd62ec706..9412b16cc8ed 100644
> --- a/include/uapi/linux/ptp_clock.h
> +++ b/include/uapi/linux/ptp_clock.h
> @@ -67,7 +67,9 @@ struct ptp_perout_
On Sat, 2019-08-17 at 08:59 -0700, Richard Cochran wrote:
> On Wed, Aug 14, 2019 at 10:47:11AM +0300, Felipe Balbi wrote:
> > The current version of the IOCTL have a small problem which prevents us
> > from extending the API by making use of reserved fields. In these new
> > IOCTLs, we are now maki
On Sat, 17 Aug 2019 17:57:38 +0200,
Hui Peng wrote:
>
> Looking around, there are other suspicious codes. E.g., in the following
> function, it seems to be the same as `uac_mixer_unit_bmControls`, but it is
> accessing `desc->bNrInPins + 5`, in case of UAC_VERSION_1.
> Is this intended?
Yes, this
Hi!
On Sat, Aug 17, 2019 at 11:40 PM Oleksij Rempel wrote:
> In provided link [0] the ralink_clk_init function is reading
> SYSC_REG_CPLL_CLKCFG0 R/W register.
> This register is used to determine clock source, clock freq and CPU or bus
> clocks.
This register should only be changed by boot
On 8/17/19 10:24 AM, Sander Eikelenboom wrote:
> On 12/08/2019 19:56, Eric Dumazet wrote:
>>
>>
>> On 8/12/19 2:50 PM, Sander Eikelenboom wrote:
>>> L.S.,
>>>
>>> While testing a somewhere-after-5.3-rc3 kernel (which included the latest
>>> net merge (33920f1ec5bf47c5c0a1d2113989bdd9dfb3fae9),
Hello,
I've added a pipe file descriptor (fd1) to an epoll (fd3) with
EPOLLOUT in edge-triggered mode, and then added the fd3 to another
epoll (fd4) with EPOLLIN in edge-triggered too.
Next, waiting for fd4 without timeout. When fd1 to be writable, i
think epoll_wait(fd4, ...) only return once,
On Sat, 17 Aug 2019 11:55:17 -0400 (EDT)
Mathieu Desnoyers wrote:
> - On Aug 17, 2019, at 11:26 AM, rostedt rost...@goodmis.org wrote:
>
> > On Sat, 17 Aug 2019 10:40:31 -0400 (EDT)
> > Mathieu Desnoyers wrote:
> >
> >> > I'm now even more against adding the READ_ONCE() or WRITE_ONCE().
On Sat, 17 Aug 2019 11:53:41 -0400 (EDT)
Mathieu Desnoyers wrote:
> kernel/trace/trace.c:tracing_record_taskinfo_sched_switch()
> kernel/trace/trace.c:tracing_record_taskinfo()
>
> where @flags is used to control a few branches. I don't think any of those
> would end up causing corruption if the
On Sat, Aug 17, 2019 at 4:13 AM Qian Cai wrote:
>
>
>
> > On Aug 16, 2019, at 11:57 PM, Dan Williams wrote:
> >
> > On Fri, Aug 16, 2019 at 8:34 PM Qian Cai wrote:
> >>
> >>
> >>
> >>> On Aug 16, 2019, at 5:48 PM, Dan Williams
> >>> wrote:
> >>>
> >>> On Fri, Aug 16, 2019 at 2:36 PM Qian Cai
/commits/Matthew-Hanzelik/Staging-speakup-spk_types-fixed-an-unnamed-parameter-style-issue/20190817-235230
config: x86_64-allyesconfig (attached as .config)
compiler: gcc-7 (Debian 7.4.0-10) 7.4.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
If you fix
The pull request you sent on Fri, 16 Aug 2019 18:25:40 -0700 (PDT):
> git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git
> tags/riscv/for-v5.3-rc5
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/2f478b60118f48bf66eaddcca0d23e80f87a682d
Thank you!
--
Deet-
The pull request you sent on Sat, 17 Aug 2019 16:12:32 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/for-current
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/05c525326957b504561d271f669d3b315930422f
Thank you!
--
Deet-doot-dot, I am a bo
On Sat, 17 Aug 2019 18:47:05 +0200,
Hui Peng wrote:
>
> No, there was not triggering. I found it accidentally when I was going through
> the code.
>
> Yeah, you are right. it is handled in the last check. Is it defined in the
> spec that the descriptor needs to have 4/6/2 additional bytes for the
Am 17.08.19 um 18:22 schrieb Chuanhong Guo:
> Hi!
>
> On Sat, Aug 17, 2019 at 11:40 PM Oleksij Rempel wrote:
>
>> In provided link [0] the ralink_clk_init function is reading
>> SYSC_REG_CPLL_CLKCFG0 R/W register.
>> This register is used to determine clock source, clock freq and CPU or bus
>>
On Fri, 16 Aug 2019 20:41:22 +0200
Lubomir Rintel wrote:
> On Fri, 2019-08-09 at 13:12 +0100, Marc Zyngier wrote:
> > On 09/08/2019 10:31, Lubomir Rintel wrote:
> > > The "regs" property of the "mrvl,mmp2-mux-intc" devices are silly. They
> > > are offsets from intc's base, not addresses on the
On Sat, Aug 17, 2019 at 11:00:13AM +0800, Zhaoyang Huang wrote:
> From: Zhaoyang Huang
>
> pfn_valid can be wrong while the MSB of physical address be trimed as pfn
> larger than the max_pfn.
What scenario are you addressing here? At a guess, you're addressing
the non-LPAE case with PFNs that c
Remove fixed clock and source common clock for UART controllers.
Signed-off-by: Manivannan Sadhasivam
---
arch/arm64/boot/dts/bitmain/bm1880-sophon-edge.dts | 9 -
arch/arm64/boot/dts/bitmain/bm1880.dtsi| 12
2 files changed, 12 insertions(+), 9 deletions(-)
di
Add clock controller support for Bitmain BM1880 SoC.
Signed-off-by: Manivannan Sadhasivam
---
arch/arm64/boot/dts/bitmain/bm1880.dtsi | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm64/boot/dts/bitmain/bm1880.dtsi
b/arch/arm64/boot/dts/bitmain/bm1880.dtsi
index d65
Hello,
This patchset adds common clock driver for Bitmain BM1880 SoC clock
controller. The clock controller consists of gate, divider, mux
and pll clocks with different compositions. Hence, the driver uses
composite clock structure in place where multiple clocking units are
combined together.
Thi
Add YAML devicetree binding for Bitmain BM1880 SoC.
Signed-off-by: Manivannan Sadhasivam
---
.../bindings/clock/bitmain,bm1880-clk.yaml| 83 +++
include/dt-bindings/clock/bm1880-clock.h | 82 ++
2 files changed, 165 insertions(+)
create mode 100644
Docu
Add common clock driver for Bitmain BM1880 SoC. The clock controller on
BM1880 has supplies clocks to all peripherals in the form of gate clocks
and composite clocks (fixed factor + gate).
Signed-off-by: Manivannan Sadhasivam
---
drivers/clk/Kconfig | 6 +
drivers/clk/Makefile | 1 +
The new implementation for determining parent map uses multiple ways
to pass parent info. The order in which it gets processed depends on
the first available member. Hence, it is necessary to zero init the
clk_init_data struct so that the expected member gets processed correctly.
So, add a warning
The clk_init_data struct needs to be initialized to zero for the new
parent_map implementation to work correctly. Otherwise, the member which
is available first will get processed.
Signed-off-by: Manivannan Sadhasivam
---
drivers/clk/clk-composite.c | 2 +-
drivers/clk/clk-divider.c| 2 +-
Add MAINTAINERS entry for Bitmain BM1880 SoC clock driver.
Signed-off-by: Manivannan Sadhasivam
---
MAINTAINERS | 2 ++
1 file changed, 2 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 997a4f8fe88e..280defec35b2 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1503,8 +1503,10 @@ M:
The below exemples of use of WARN_ON() show that the result
is sub-optimal in regard of the capabilities of powerpc.
void test_warn1(unsigned long long a)
{
WARN_ON(a);
}
void test_warn2(unsigned long a)
{
WARN_ON(a);
}
void test_warn3(unsigned long a, unsigned long b)
{
Return the correct value when RX descriptor is not the last one.
Signed-off-by: Jose Abreu
---
Cc: Giuseppe Cavallaro
Cc: Alexandre Torgue
Cc: Jose Abreu
Cc: "David S. Miller"
Cc: Maxime Coquelin
Cc: net...@vger.kernel.org
Cc: linux-st...@st-md-mailman.stormreply.com
Cc: linux-arm-ker...@li
Adds the logic to insert a given VLAN ID in a packet. This is offloaded
to HW and its descriptor based. For now, only XGMAC implements the
necessary callbacks.
Signed-off-by: Jose Abreu
---
Cc: Giuseppe Cavallaro
Cc: Alexandre Torgue
Cc: Jose Abreu
Cc: "David S. Miller"
Cc: Maxime Coquelin
Couple of improvements for -next tree. More info in commit logs.
---
Cc: Giuseppe Cavallaro
Cc: Alexandre Torgue
Cc: Jose Abreu
Cc: "David S. Miller"
Cc: Maxime Coquelin
Cc: net...@vger.kernel.org
Cc: linux-st...@st-md-mailman.stormreply.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-
Add the support for Split Header feature in the RX path and enable it in
XGMAC cores.
This does not impact neither beneficts bandwidth but it does reduces CPU
usage because without the feature all the entire packet is memcpy'ed,
while that with the feature only the header is.
With Split Header di
Add the support for Flexible PPS in XGMAC cores.
Signed-off-by: Jose Abreu
---
Cc: Giuseppe Cavallaro
Cc: Alexandre Torgue
Cc: Jose Abreu
Cc: "David S. Miller"
Cc: Maxime Coquelin
Cc: net...@vger.kernel.org
Cc: linux-st...@st-md-mailman.stormreply.com
Cc: linux-arm-ker...@lists.infradead.or
Add a counter that increments each time a packet with split header is
received.
Signed-off-by: Jose Abreu
---
Cc: Giuseppe Cavallaro
Cc: Alexandre Torgue
Cc: Jose Abreu
Cc: "David S. Miller"
Cc: Maxime Coquelin
Cc: net...@vger.kernel.org
Cc: linux-st...@st-md-mailman.stormreply.com
Cc: linu
Add the support for Source Address Insertion and Replacement in XGMAC
cores. Two methods are supported: Descriptor based and register based.
Signed-off-by: Jose Abreu
---
Cc: Giuseppe Cavallaro
Cc: Alexandre Torgue
Cc: Jose Abreu
Cc: "David S. Miller"
Cc: Maxime Coquelin
Cc: net...@vger.ker
Add support for EEE in XGMAC cores by implementing the necessary
callbacks.
Signed-off-by: Jose Abreu
---
Cc: Giuseppe Cavallaro
Cc: Alexandre Torgue
Cc: Jose Abreu
Cc: "David S. Miller"
Cc: Maxime Coquelin
Cc: net...@vger.kernel.org
Cc: linux-st...@st-md-mailman.stormreply.com
Cc: linux-ar
Add 2 new selftests for VLAN Insertion offloading. Tests are for inner
and outer VLAN offloading.
Signed-off-by: Jose Abreu
---
Cc: Giuseppe Cavallaro
Cc: Alexandre Torgue
Cc: Jose Abreu
Cc: "David S. Miller"
Cc: Maxime Coquelin
Cc: net...@vger.kernel.org
Cc: linux-st...@st-md-mailman.storm
Add the ethtool interface to dump the register map in XGMAC cores.
Changes from v2:
- Remove uneeded memset (Jakub)
Signed-off-by: Jose Abreu
---
Cc: Giuseppe Cavallaro
Cc: Alexandre Torgue
Cc: Jose Abreu
Cc: "David S. Miller"
Cc: Maxime Coquelin
Cc: net...@vger.kernel.org
Cc: linu
TX Timestamp in XGMAC comes from MAC instead of descriptors. Implement
this in a new callback.
Also, RX Timestamp in XGMAC must be cheked against corruption and we need
a barrier to make sure that descriptor fields are read correctly.
Changes from v2:
- Rework return code check (Jakub)
Ch
In order to add Split Header support, stmmac_rx() needs to take into
account that packet may be split accross multiple descriptors.
Refactor the logic of this function in order to support this scenario.
Changes from v2:
- Fixup if condition detection (Jakub)
- Don't stop NAPI with
Add 4 new tests:
- SA Insertion (register based)
- SA Insertion (descriptor based)
- SA Replacament (register based)
- SA Replacement (descriptor based)
Signed-off-by: Jose Abreu
---
Cc: Giuseppe Cavallaro
Cc: Alexandre Torgue
Cc: Jose Abreu
Cc: "David S. Mille
On Sat, Aug 17, 2019 at 11:33:57AM +0800, Yafang Shao wrote:
> On Sat, Aug 17, 2019 at 8:47 AM Roman Gushchin wrote:
> >
> > Commit 766a4c19d880 ("mm/memcontrol.c: keep local VM counters in sync
> > with the hierarchical ones") effectively decreased the precision of
> > per-memcg vmstats_local and
On Sat, Aug 17, 2019 at 08:36:16AM +0200, Greg KH wrote:
> On Fri, Aug 16, 2019 at 05:47:26PM -0700, Roman Gushchin wrote:
> > Commit 766a4c19d880 ("mm/memcontrol.c: keep local VM counters in sync
> > with the hierarchical ones") effectively decreased the precision of
> > per-memcg vmstats_local an
Arul,
On Sat, 17 Aug 2019, Arul Jeniston wrote:
> Do you agree the possibility of returning zero value from timerfd_read()?
Obviosuly it happens.
> > That has absolutely nothing to do with CLOCK_REALTIME. Your machines
> > TSC is either going backwards or not synchronized between cores.
> >
>
On Fri, Aug 16, 2019 at 5:02 PM Amit Kucheria wrote:
>
> On Sat, Aug 17, 2019 at 3:06 AM Rob Herring wrote:
> >
> > On Fri, Jul 26, 2019 at 03:48:42AM +0530, Amit Kucheria wrote:
> > > Define two new required properties to define interrupts and
> > > interrupt-names for tsens.
> > >
> > > Signed-
From: Jose Abreu
Date: Sat, 17 Aug 2019 20:54:39 +0200
> Couple of improvements for -next tree. More info in commit logs.
Series applied.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b:
Linus 5.3-rc1 (2019-07-21 14:05:38 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux.git
tags/hyperv-fixes-si
Apologies to Steve for continuing this thread when all he wanted was moving
an operation inside a mutex...
On 17/08/2019 16:02, Mathieu Desnoyers wrote:
[...]
> However, if the state of "x" can be any pointer value, or a reference
> count value, then not using "WRITE_ONCE()" to store a constant le
On Fri, 16 Aug 2019, Guenter Roeck wrote:
> On Fri, Aug 16, 2019 at 12:22:22PM +0200, Thomas Gleixner wrote:
> > diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
> > index 75fea0d48c0e..625627b1457c 100644
> > --- a/arch/x86/kernel/process.c
> > +++ b/arch/x86/kernel/process.c
> >
Thomas Gleixner,
Alright. Then I guess I am wasting everyone's time and everything is as
it should be according to you.
I will unsubscribe from this mailing list because it is flooding my
mail box with so many messages and I don't know of any way to subscribe
only to this particular thread.
Plea
This patch removes the todo for the ion chunk and
carveout device tree bindings.
Signed-off-by: Donald Yandt
---
drivers/staging/android/TODO | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/staging/android/TODO b/drivers/staging/android/TODO
index fbf015cc6..767dd98fd 100644
--- a/d
On Sat, Aug 17, 2019 at 12:43:08AM -0400, Joel Fernandes wrote:
> On Fri, Aug 16, 2019 at 09:38:54PM -0700, Paul Walmsley wrote:
> > On Sat, 17 Aug 2019, Joel Fernandes (Google) wrote:
> >
> > > xchg() on a bool is causing issues on riscv and arm32.
> >
> > Indeed, it seems best not to use xchg()
After some private coaching from Serge Belyshev on git-revert I can confirm
that reverting that commit atop the current tree resolves the issue (the wifi
card scans for and finds networks just fine, no dmesg errors reported, etc.).
On Sat, Aug 17, 2019 at 11:59:59AM +0300, Serge Belyshev wrote:
On Sat, Aug 17, 2019 at 01:53:29AM -0400, Joel Fernandes wrote:
> On Fri, Aug 16, 2019 at 10:20:23PM -0700, Paul E. McKenney wrote:
> > On Sat, Aug 17, 2019 at 12:30:24AM -0400, Joel Fernandes wrote:
> > > On Fri, Aug 16, 2019 at 08:56:37PM -0700, Paul E. McKenney wrote:
> > > > On Fri, Aug 16, 201
On Sat, Aug 17, 2019 at 12:40:40PM -0400, Steven Rostedt wrote:
> On Sat, 17 Aug 2019 11:55:17 -0400 (EDT)
> Mathieu Desnoyers wrote:
>
> > - On Aug 17, 2019, at 11:26 AM, rostedt rost...@goodmis.org wrote:
> >
> > > On Sat, 17 Aug 2019 10:40:31 -0400 (EDT)
> > > Mathieu Desnoyers wrote:
>
1 - 100 of 153 matches
Mail list logo
