On Fri, 2017-07-28 at 08:25 -0600, Jens Axboe wrote:
> On 07/28/2017 12:19 AM, Michael Ellerman wrote:
> > OK, so the resolution is "fix it in IPR" ?
>
> I'll leave that to the SCSI crew. But at least one bug is in IPR, if you
> look at the call trace:
>
> - timer function triggers, runs
On Fri, 2017-07-28 at 08:25 -0600, Jens Axboe wrote:
> On 07/28/2017 12:19 AM, Michael Ellerman wrote:
> > OK, so the resolution is "fix it in IPR" ?
>
> I'll leave that to the SCSI crew. But at least one bug is in IPR, if you
> look at the call trace:
>
> - timer function triggers, runs
Indirect access (PMI) to phy register only work in I2C mode. In
MDIO mode phy registers must be accessed directly. Introduced
struct lan9303_phy_ops to handle the two modes.
Signed-off-by: Egil Hjelmeland
---
drivers/net/dsa/lan9303-core.c | 20 +---
Indirect access (PMI) to phy register only work in I2C mode. In
MDIO mode phy registers must be accessed directly. Introduced
struct lan9303_phy_ops to handle the two modes.
Signed-off-by: Egil Hjelmeland
---
drivers/net/dsa/lan9303-core.c | 20 +---
drivers/net/dsa/lan9303.h
Preparing for the following fix of MDIO phy access:
Renamed functions that access PHY 1 and 2 indirectly through PMI
registers.
lan9303_port_phy_reg_wait_for_completion() to
lan9303_indirect_phy_wait_for_completion()
lan9303_port_phy_reg_read() to
lan9303_indirect_phy_read()
Preparing for the following fix of MDIO phy access:
Renamed functions that access PHY 1 and 2 indirectly through PMI
registers.
lan9303_port_phy_reg_wait_for_completion() to
lan9303_indirect_phy_wait_for_completion()
lan9303_port_phy_reg_read() to
lan9303_indirect_phy_read()
On 07/28/2017 10:53 AM, Juergen Gross wrote:
> When starting the xenwatch thread a theoretical deadlock situation is
> possible:
>
> xs_init() contains:
>
> task = kthread_run(xenwatch_thread, NULL, "xenwatch");
> if (IS_ERR(task))
> return PTR_ERR(task);
> xenwatch_pid =
On 07/28/2017 10:53 AM, Juergen Gross wrote:
> When starting the xenwatch thread a theoretical deadlock situation is
> possible:
>
> xs_init() contains:
>
> task = kthread_run(xenwatch_thread, NULL, "xenwatch");
> if (IS_ERR(task))
> return PTR_ERR(task);
> xenwatch_pid =
Handle that MDIO read with no response return 0x.
Signed-off-by: Egil Hjelmeland
---
drivers/net/dsa/lan9303-core.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/dsa/lan9303-core.c b/drivers/net/dsa/lan9303-core.c
index
Handle that MDIO read with no response return 0x.
Signed-off-by: Egil Hjelmeland
---
drivers/net/dsa/lan9303-core.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/dsa/lan9303-core.c b/drivers/net/dsa/lan9303-core.c
index cd76e61f1fca..9d0ab77edb4a 100644
This series fix the MDIO interface for the lan9303 DSA driver.
Bugs found after testing on actual HW.
This series is extracted from the first patch of my first large
series. Significant changes from that version are:
- use mdiobus_write_nested, mdiobus_read_nested.
- EXPORT
This series fix the MDIO interface for the lan9303 DSA driver.
Bugs found after testing on actual HW.
This series is extracted from the first patch of my first large
series. Significant changes from that version are:
- use mdiobus_write_nested, mdiobus_read_nested.
- EXPORT
On Fri, Jul 28, 2017 at 7:30 AM, Yujuan Qi wrote:
> From: "yujuan.qi"
>
> in for(),if((optlen > 0) && (optptr[1] == 0)), enter infinite loop.
>
> Test: receive a packet which the ip length > 20 and the first byte of ip
> option is 0, produce this
On Fri, Jul 28, 2017 at 7:30 AM, Yujuan Qi wrote:
> From: "yujuan.qi"
>
> in for(),if((optlen > 0) && (optptr[1] == 0)), enter infinite loop.
>
> Test: receive a packet which the ip length > 20 and the first byte of ip
> option is 0, produce this issue
>
> Signed-off-by: yujuan.qi
> ---
>
On Fri, Jul 28, 2017 at 09:46:34AM +0100, Mel Gorman wrote:
> On Fri, Jul 28, 2017 at 03:41:51PM +0900, Minchan Kim wrote:
> > Nadav reported parallel MADV_DONTNEED on same range has a stale TLB
> > problem and Mel fixed it[1] and found same problem on MADV_FREE[2].
> >
> > Quote from Mel Gorman
On Fri, Jul 28, 2017 at 09:46:34AM +0100, Mel Gorman wrote:
> On Fri, Jul 28, 2017 at 03:41:51PM +0900, Minchan Kim wrote:
> > Nadav reported parallel MADV_DONTNEED on same range has a stale TLB
> > problem and Mel fixed it[1] and found same problem on MADV_FREE[2].
> >
> > Quote from Mel Gorman
On 07/28/2017 05:46 AM, Michael S. Tsirkin wrote:
On Fri, Jul 28, 2017 at 11:28:54AM +0800, Jason Wang wrote:
+ old_prog = rtnl_dereference(tun->xdp_prog);
+ if (old_prog)
+ bpf_prog_put(old_prog);
+ rcu_assign_pointer(tun->xdp_prog, prog);
Is this OK? Could
On 07/28/2017 05:46 AM, Michael S. Tsirkin wrote:
On Fri, Jul 28, 2017 at 11:28:54AM +0800, Jason Wang wrote:
+ old_prog = rtnl_dereference(tun->xdp_prog);
+ if (old_prog)
+ bpf_prog_put(old_prog);
+ rcu_assign_pointer(tun->xdp_prog, prog);
Is this OK? Could
On 28/07/17 14:32, Mark Brown wrote:
On Wed, Jul 26, 2017 at 01:48:22AM +0200, srinivas.kandaga...@linaro.org wrote:
From: Srinivas Kandagatla
This patch fixes a missing selection of DMIC in CIC filter source path.
Without this patch dmic is not functional.
On 28/07/17 14:32, Mark Brown wrote:
On Wed, Jul 26, 2017 at 01:48:22AM +0200, srinivas.kandaga...@linaro.org wrote:
From: Srinivas Kandagatla
This patch fixes a missing selection of DMIC in CIC filter source path.
Without this patch dmic is not functional.
What happens when someone needs
Hello,
On Fri, Jul 28, 2017 at 02:01:55PM +0100, Roman Gushchin wrote:
> > > + nr_dying_descendants
> > > + Total number of dying descendant cgroups.
> >
> > Can you please go into more detail on what's going on with dying
> > descendants here?
>
> Sure.
> Don't we plan do describe
Hello,
On Fri, Jul 28, 2017 at 02:01:55PM +0100, Roman Gushchin wrote:
> > > + nr_dying_descendants
> > > + Total number of dying descendant cgroups.
> >
> > Can you please go into more detail on what's going on with dying
> > descendants here?
>
> Sure.
> Don't we plan do describe
Ok,
here's a working version. It looks pretty straight-forward (to me, at
least) and it does what it is supposed to when I inject an MCE:
# tracer: nop
#
# _-=> irqs-off
# / _=> need-resched
#| / _---=>
Ok,
here's a working version. It looks pretty straight-forward (to me, at
least) and it does what it is supposed to when I inject an MCE:
# tracer: nop
#
# _-=> irqs-off
# / _=> need-resched
#| / _---=>
On Thu, Jul 27, 2017 at 04:27:14PM -0500, Michael Bringmann wrote:
>
> There is an underlying assumption/trade-off in many layers of the Linux
> system that CPU <-> node mapping is static. This is despite the presence
> of features like NUMA and 'hotplug' that support the dynamic addition/
>
On Thu, Jul 27, 2017 at 04:27:14PM -0500, Michael Bringmann wrote:
>
> There is an underlying assumption/trade-off in many layers of the Linux
> system that CPU <-> node mapping is static. This is despite the presence
> of features like NUMA and 'hotplug' that support the dynamic addition/
>
Kalle Valo writes:
> Arvind Yadav wrote:
>
>> attribute_group are not supposed to change at runtime. All functions
>> working with attribute_group provided by work
>> with const attribute_group. So mark the non-const structs as const.
>>
>>
Kalle Valo writes:
> Arvind Yadav wrote:
>
>> attribute_group are not supposed to change at runtime. All functions
>> working with attribute_group provided by work
>> with const attribute_group. So mark the non-const structs as const.
>>
>> Signed-off-by: Arvind Yadav
>
> 4 patches applied
Colin Ian King wrote:
> From: Colin Ian King
>
> Trivial fix to spelling mistake in printk message
>
> Signed-off-by: Colin Ian King
Patch applied to wireless-drivers-next.git, thanks.
fcc870d76a2c wl3501_cs: fix
Colin Ian King wrote:
> From: Colin Ian King
>
> Trivial fix to spelling mistake in printk message
>
> Signed-off-by: Colin Ian King
Patch applied to wireless-drivers-next.git, thanks.
fcc870d76a2c wl3501_cs: fix spelling mistake: "Insupported" -> "Unsupported"
--
Arvind Yadav wrote:
> attribute_group are not supposed to change at runtime. All functions
> working with attribute_group provided by work
> with const attribute_group. So mark the non-const structs as const.
>
> Signed-off-by: Arvind Yadav
Arvind Yadav wrote:
> attribute_group are not supposed to change at runtime. All functions
> working with attribute_group provided by work
> with const attribute_group. So mark the non-const structs as const.
>
> Signed-off-by: Arvind Yadav
4 patches applied to wireless-drivers-next.git,
Arvind Yadav wrote:
> pci_device_id are not supposed to change at runtime. All functions
> working with pci_device_id provided by work with
> const pci_device_id. So mark the non-const structs as const.
>
> Signed-off-by: Arvind Yadav
>
Arvind Yadav wrote:
> pci_device_id are not supposed to change at runtime. All functions
> working with pci_device_id provided by work with
> const pci_device_id. So mark the non-const structs as const.
>
> Signed-off-by: Arvind Yadav
> Acked-by: Arend van Spriel
Patch applied to
Colin Ian King wrote:
> From: Colin Ian King
>
> Trivial fix to spelling mistake in PDEBUG debug message.
>
> Signed-off-by: Colin Ian King
Patch applied to wireless-drivers-next.git, thanks.
af643fe9bbe0
Colin Ian King wrote:
> From: Colin Ian King
>
> Trivial fix to spelling mistake in PDEBUG debug message.
>
> Signed-off-by: Colin Ian King
Patch applied to wireless-drivers-next.git, thanks.
af643fe9bbe0 zd1211rw: fix spelling mistake 'hybernate' -> 'hibernate'
--
On Fri, Jul 28, 2017 at 09:52:57PM +0800, Herbert Xu wrote:
> On Fri, Jul 14, 2017 at 01:15:36PM +0200, Corentin Labbe wrote:
> > On Fri, Jun 23, 2017 at 02:48:37PM +0800, Herbert Xu wrote:
> > > On Mon, Jun 19, 2017 at 09:55:24AM +0200, Corentin Labbe wrote:
> > > >
> > > > Since there are two
On Fri, Jul 28, 2017 at 09:52:57PM +0800, Herbert Xu wrote:
> On Fri, Jul 14, 2017 at 01:15:36PM +0200, Corentin Labbe wrote:
> > On Fri, Jun 23, 2017 at 02:48:37PM +0800, Herbert Xu wrote:
> > > On Mon, Jun 19, 2017 at 09:55:24AM +0200, Corentin Labbe wrote:
> > > >
> > > > Since there are two
On 07/25/2017 09:00 AM, Peter Zijlstra wrote:
> On Tue, Jul 25, 2017 at 08:17:27AM -0400, Prarit Bhargava wrote:
>> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
>> index 5b1662ec546f..6cd38a25f8ea 100644
>> --- a/lib/Kconfig.debug
>> +++ b/lib/Kconfig.debug
>> @@ -1,8 +1,8 @@
>> menu
On 07/25/2017 09:00 AM, Peter Zijlstra wrote:
> On Tue, Jul 25, 2017 at 08:17:27AM -0400, Prarit Bhargava wrote:
>> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
>> index 5b1662ec546f..6cd38a25f8ea 100644
>> --- a/lib/Kconfig.debug
>> +++ b/lib/Kconfig.debug
>> @@ -1,8 +1,8 @@
>> menu
Em Fri, Jul 28, 2017 at 11:25:50AM +0200, Jiri Olsa escreveu:
> On Thu, Jul 27, 2017 at 02:12:03PM -0400, Geneviève Bastien wrote:
> > The field perf_callchain, if available, is added to the sampling
> > events during the CTF conversion. It is an array of u64 values.
> > The perf_callchain_size
Em Fri, Jul 28, 2017 at 11:25:50AM +0200, Jiri Olsa escreveu:
> On Thu, Jul 27, 2017 at 02:12:03PM -0400, Geneviève Bastien wrote:
> > The field perf_callchain, if available, is added to the sampling
> > events during the CTF conversion. It is an array of u64 values.
> > The perf_callchain_size
On 28/07/17 17:50, Thomas Gleixner wrote:
On Fri, 28 Jul 2017, Tomi Sarvela wrote:
On 28/07/17 17:13, Thomas Gleixner wrote:
On Fri, 28 Jul 2017, Tomi Sarvela wrote:
On 28/07/17 16:15, Thomas Gleixner wrote:
Another question. Is the machine completely dead or not?
Completely dead. Powerled
On 28/07/17 17:50, Thomas Gleixner wrote:
On Fri, 28 Jul 2017, Tomi Sarvela wrote:
On 28/07/17 17:13, Thomas Gleixner wrote:
On Fri, 28 Jul 2017, Tomi Sarvela wrote:
On 28/07/17 16:15, Thomas Gleixner wrote:
Another question. Is the machine completely dead or not?
Completely dead. Powerled
Colin Ian King wrote:
> From: Colin Ian King
>
> Trivial fix to spelling mistake in mwifiex_dbg debug message
>
> Signed-off-by: Colin Ian King
Patch applied to wireless-drivers-next.git, thanks.
17830147c40a
Colin Ian King wrote:
> From: Colin Ian King
>
> Trivial fix to spelling mistake in mwifiex_dbg debug message
>
> Signed-off-by: Colin Ian King
Patch applied to wireless-drivers-next.git, thanks.
17830147c40a mwifiex: fix spelling mistake: "Insuffient" -> "Insufficient"
--
When starting the xenwatch thread a theoretical deadlock situation is
possible:
xs_init() contains:
task = kthread_run(xenwatch_thread, NULL, "xenwatch");
if (IS_ERR(task))
return PTR_ERR(task);
xenwatch_pid = task->pid;
And xenwatch_thread() does:
mutex_lock(_mutex);
When starting the xenwatch thread a theoretical deadlock situation is
possible:
xs_init() contains:
task = kthread_run(xenwatch_thread, NULL, "xenwatch");
if (IS_ERR(task))
return PTR_ERR(task);
xenwatch_pid = task->pid;
And xenwatch_thread() does:
mutex_lock(_mutex);
The synchronization type that was used earlier to guard the loop that
deletes unused log buffers may have lead to a situation that prevents
any thread from going through the loop.
The patch deletes previously used synchronization mechanism and moves
the loop under the spin_lock so the similar
The synchronization type that was used earlier to guard the loop that
deletes unused log buffers may have lead to a situation that prevents
any thread from going through the loop.
The patch deletes previously used synchronization mechanism and moves
the loop under the spin_lock so the similar
Colin Ian King wrote:
> From: Colin Ian King
>
> Trivial fix to spelling mistake in aggr_ctrl module parameter
> message text.
>
> Signed-off-by: Colin Ian King
Patch applied to wireless-drivers-next.git, thanks.
Colin Ian King wrote:
> From: Colin Ian King
>
> Trivial fix to spelling mistake in aggr_ctrl module parameter
> message text.
>
> Signed-off-by: Colin Ian King
Patch applied to wireless-drivers-next.git, thanks.
c55971726c40 mwifiex: usb: fix spelling mistake: "aggreataon"-> "aggregation"
> It is too late when we know the PHY ID.
> We need to set a syscon for choosing external/internal PHY.
> So we can rely only on DT.
The point is, its not a property of the PHY. It is a syscon or a MAC
property. Having it as a MAC property would be more generic.
Andrew
> It is too late when we know the PHY ID.
> We need to set a syscon for choosing external/internal PHY.
> So we can rely only on DT.
The point is, its not a property of the PHY. It is a syscon or a MAC
property. Having it as a MAC property would be more generic.
Andrew
On Fri, 28 Jul 2017, Tomi Sarvela wrote:
> On 28/07/17 17:13, Thomas Gleixner wrote:
> > On Fri, 28 Jul 2017, Tomi Sarvela wrote:
> > > On 28/07/17 16:15, Thomas Gleixner wrote:
> > > > Another question. Is the machine completely dead or not?
> > >
> > > Completely dead. Powerled is on, so host
On Fri, 28 Jul 2017, Tomi Sarvela wrote:
> On 28/07/17 17:13, Thomas Gleixner wrote:
> > On Fri, 28 Jul 2017, Tomi Sarvela wrote:
> > > On 28/07/17 16:15, Thomas Gleixner wrote:
> > > > Another question. Is the machine completely dead or not?
> > >
> > > Completely dead. Powerled is on, so host
Hi Dan,
Thanks for the hint.
I don't get, what went wrong. If I take the mail from my outbox and view it, it
looks nice.
Seems, I really need to look for another mailtool. But for several reasons,
that's not possible at the moment (slow move of 20 domains with someting arround
80 mail adresses
Jeffy Chen wrote:
> We inited wakeup info at the beginning of mwifiex_add_card, so we need
> to uninit it in the error handling.
>
> It's much the same as what we did in:
> 36908c4 mwifiex: uninit wakeup info when removing device
>
> Signed-off-by: Jeffy Chen
Hi Dan,
Thanks for the hint.
I don't get, what went wrong. If I take the mail from my outbox and view it, it
looks nice.
Seems, I really need to look for another mailtool. But for several reasons,
that's not possible at the moment (slow move of 20 domains with someting arround
80 mail adresses
Jeffy Chen wrote:
> We inited wakeup info at the beginning of mwifiex_add_card, so we need
> to uninit it in the error handling.
>
> It's much the same as what we did in:
> 36908c4 mwifiex: uninit wakeup info when removing device
>
> Signed-off-by: Jeffy Chen
> Reviewed-by: Brian Norris
Brian Norris wrote:
> When PCIe FLR code was added, it explicitly copy-and-pasted much of
> mwifiex_remove_card() into mwifiex_shutdown_sw(). This is unnecessary,
> as almost all of the code should be reused.
>
> Let's reunite what we can for now.
>
> The only
Brian Norris wrote:
> When PCIe FLR code was added, it explicitly copy-and-pasted much of
> mwifiex_remove_card() into mwifiex_shutdown_sw(). This is unnecessary,
> as almost all of the code should be reused.
>
> Let's reunite what we can for now.
>
> The only functional changes for now:
>
>
On 28/07/17 17:13, Thomas Gleixner wrote:
On Fri, 28 Jul 2017, Tomi Sarvela wrote:
On 28/07/17 16:15, Thomas Gleixner wrote:
Another question. Is the machine completely dead or not?
Completely dead. Powerled is on, so host isn't shut down.
So that means it does not even power the machine
On 28/07/17 17:13, Thomas Gleixner wrote:
On Fri, 28 Jul 2017, Tomi Sarvela wrote:
On 28/07/17 16:15, Thomas Gleixner wrote:
Another question. Is the machine completely dead or not?
Completely dead. Powerled is on, so host isn't shut down.
So that means it does not even power the machine
Linus,
Please git pull the following tag:
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
for-linus-4.13b-rc3-tag
xen: fixes for 4.13-rc3
It contains three minor cleanups for xen related drivers.
Thanks.
Juergen
drivers/xen/events/events_base.c | 13 +++--
Linus,
Please git pull the following tag:
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
for-linus-4.13b-rc3-tag
xen: fixes for 4.13-rc3
It contains three minor cleanups for xen related drivers.
Thanks.
Juergen
drivers/xen/events/events_base.c | 13 +++--
On 07/28/2017 09:27 AM, Corey Minyard wrote:
I missed this until now, and I see it hasn't been applied yet. It's
queued for the next release.
Well, never mind, I see the main update didn't go in.
-corey
Thanks,
-corey
On 01/30/2017 12:47 PM, Fabian Frederick wrote:
instead of
On 07/28/2017 09:27 AM, Corey Minyard wrote:
I missed this until now, and I see it hasn't been applied yet. It's
queued for the next release.
Well, never mind, I see the main update didn't go in.
-corey
Thanks,
-corey
On 01/30/2017 12:47 PM, Fabian Frederick wrote:
instead of
On 28/07/17 15:01, Mark Brown wrote:
On Fri, Jul 28, 2017 at 02:54:59PM +0100, Srinivas Kandagatla wrote:
On 28/07/17 14:40, Mark Brown wrote:
On Wed, Jul 26, 2017 at 02:35:10AM +0200, srinivas.kandaga...@linaro.org wrote:
From: Srinivas Kandagatla
This
On 28/07/17 15:01, Mark Brown wrote:
On Fri, Jul 28, 2017 at 02:54:59PM +0100, Srinivas Kandagatla wrote:
On 28/07/17 14:40, Mark Brown wrote:
On Wed, Jul 26, 2017 at 02:35:10AM +0200, srinivas.kandaga...@linaro.org wrote:
From: Srinivas Kandagatla
This patch sets the default internal
On Fri, Jul 28, 2017 at 04:36:00PM +0200, Andrew Lunn wrote:
> > > I've probably asked this before: Does the internal PHY use a different
> > > PHY ID in registers 2 and 3?
> > >
> >
> > yes
> >
> > reg2: 0x0044
> > reg3: 0X1500
Copy/paste error, its 1400
>
> So this is not about loading the
On Fri, Jul 28, 2017 at 04:36:00PM +0200, Andrew Lunn wrote:
> > > I've probably asked this before: Does the internal PHY use a different
> > > PHY ID in registers 2 and 3?
> > >
> >
> > yes
> >
> > reg2: 0x0044
> > reg3: 0X1500
Copy/paste error, its 1400
>
> So this is not about loading the
When using CONFIG_UBSAN_SANITIZE_ALL, the TCP code produces a
false-positive warning:
net/ipv4/tcp_output.c: In function 'tcp_connect':
net/ipv4/tcp_output.c:2207:40: error: array subscript is below array bounds
[-Werror=array-bounds]
tp->chrono_stat[tp->chrono_type - 1] += now -
When using CONFIG_UBSAN_SANITIZE_ALL, the TCP code produces a
false-positive warning:
net/ipv4/tcp_output.c: In function 'tcp_connect':
net/ipv4/tcp_output.c:2207:40: error: array subscript is below array bounds
[-Werror=array-bounds]
tp->chrono_stat[tp->chrono_type - 1] += now -
Hi Florian,
Could you please pick up PATCH 1/2 of this series below and drop PATCH 2/2 ?
On 17-07-19 10:05 AM, Scott Branden wrote:
Separate Broadcom boards per SoC to assist in cleaner management of boards.
This has already been done for Stingray and is done here for RPI and NS2.
If this is
Hi Florian,
Could you please pick up PATCH 1/2 of this series below and drop PATCH 2/2 ?
On 17-07-19 10:05 AM, Scott Branden wrote:
Separate Broadcom boards per SoC to assist in cleaner management of boards.
This has already been done for Stingray and is done here for RPI and NS2.
If this is
> > I've probably asked this before: Does the internal PHY use a different
> > PHY ID in registers 2 and 3?
> >
>
> yes
>
> reg2: 0x0044
> reg3: 0X1500
So this is not about loading the correct PHY driver. You can already
do this based on the PHY IDs...
This is about selecting which PHY to
> > I've probably asked this before: Does the internal PHY use a different
> > PHY ID in registers 2 and 3?
> >
>
> yes
>
> reg2: 0x0044
> reg3: 0X1500
So this is not about loading the correct PHY driver. You can already
do this based on the PHY IDs...
This is about selecting which PHY to
On Fri, Jul 28, 2017 at 4:24 PM, Jason Gerecke wrote:
> On Fri, Jul 28, 2017 at 7:18 AM, Arnd Bergmann wrote:
>> On Fri, Jul 28, 2017 at 4:07 PM, Jason Gerecke wrote:
>> #ifdef CONFIG_USB_HID
>> extern bool
On Fri, Jul 28, 2017 at 4:24 PM, Jason Gerecke wrote:
> On Fri, Jul 28, 2017 at 7:18 AM, Arnd Bergmann wrote:
>> On Fri, Jul 28, 2017 at 4:07 PM, Jason Gerecke wrote:
>> #ifdef CONFIG_USB_HID
>> extern bool hid_is_using_usb_driver(struct hid_device *hdev)
>> #else
>> static inline bool
Add a driver for RAVE Supervisory Processor, an MCU implementing
varoius bits of housekeeping functionality (watchdoging, backlight
control, LED control, etc) on RAVE family of products by Zodiac
Inflight Innovations.
This driver implementes core MFD/serdev device as well as
communication
Cc: cphe...@gmail.com
Cc: Lucas Stach
Cc: Nikita Yushchenko
Cc: Rob Herring
Cc: Mark Rutland
Cc: devicet...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Acked-by: Rob Herring
I missed this until now, and I see it hasn't been applied yet. It's
queued for the next release.
Thanks,
-corey
On 01/30/2017 12:47 PM, Fabian Frederick wrote:
instead of atomic_add_unless(value, -1, 0)
Signed-off-by: Fabian Frederick
---
Add a driver for RAVE Supervisory Processor, an MCU implementing
varoius bits of housekeeping functionality (watchdoging, backlight
control, LED control, etc) on RAVE family of products by Zodiac
Inflight Innovations.
This driver implementes core MFD/serdev device as well as
communication
Cc: cphe...@gmail.com
Cc: Lucas Stach
Cc: Nikita Yushchenko
Cc: Rob Herring
Cc: Mark Rutland
Cc: devicet...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Acked-by: Rob Herring
Acked-for-MFD-by: Lee Jones
Signed-off-by: Andrey Smirnov
---
.../devicetree/bindings/mfd/zii,rave-sp.txt
I missed this until now, and I see it hasn't been applied yet. It's
queued for the next release.
Thanks,
-corey
On 01/30/2017 12:47 PM, Fabian Frederick wrote:
instead of atomic_add_unless(value, -1, 0)
Signed-off-by: Fabian Frederick
---
drivers/char/ipmi/ipmi_msghandler.c | 2 +-
1
Greg,
I am not sure if you are the right person to send these to, if you are
not, please let me know who would be the appropriate recepient and sorry for
the noise.
Thanks!
The orginal conver letter text follows:
Hi everyone,
This patch series is v4 of the driver for supervisory processor
Greg,
I am not sure if you are the right person to send these to, if you are
not, please let me know who would be the appropriate recepient and sorry for
the noise.
Thanks!
The orginal conver letter text follows:
Hi everyone,
This patch series is v4 of the driver for supervisory processor
On Fri, Jul 28, 2017 at 04:21:05PM +0200, Marcus Wolf wrote:
> Hi Arnd,
>
> we already have a patch for this:
> [PATCH 1/1] staging: pi433: fix problem with division in rf69_set_deviation
> from 20.07.2017
https://patchwork.kernel.org/patch/9855261/
>
> Maybe I did something wrong, but my
On Fri, Jul 28, 2017 at 04:21:05PM +0200, Marcus Wolf wrote:
> Hi Arnd,
>
> we already have a patch for this:
> [PATCH 1/1] staging: pi433: fix problem with division in rf69_set_deviation
> from 20.07.2017
https://patchwork.kernel.org/patch/9855261/
>
> Maybe I did something wrong, but my
On Fri, Jul 28, 2017 at 4:21 PM, Marcus Wolf
wrote:
> Hi Arnd,
>
> we already have a patch for this:
> [PATCH 1/1] staging: pi433: fix problem with division in rf69_set_deviation
> from 20.07.2017
>
> Maybe I did something wrong, but my first solution was
On Fri, Jul 28, 2017 at 4:21 PM, Marcus Wolf
wrote:
> Hi Arnd,
>
> we already have a patch for this:
> [PATCH 1/1] staging: pi433: fix problem with division in rf69_set_deviation
> from 20.07.2017
>
> Maybe I did something wrong, but my first solution was exactly like your
> proposal. As far as
On 07/28/2017 12:19 AM, Michael Ellerman wrote:
> Jens Axboe writes:
>> On 07/27/2017 08:47 AM, Bart Van Assche wrote:
>>> On Thu, 2017-07-27 at 08:02 -0600, Jens Axboe wrote:
The bug looks like SCSI running the queue inline from IRQ
context, that's not a good idea.
>
On 07/28/2017 12:19 AM, Michael Ellerman wrote:
> Jens Axboe writes:
>> On 07/27/2017 08:47 AM, Bart Van Assche wrote:
>>> On Thu, 2017-07-27 at 08:02 -0600, Jens Axboe wrote:
The bug looks like SCSI running the queue inline from IRQ
context, that's not a good idea.
> ...
>>>
>>>
On Fri, Jul 28, 2017 at 7:18 AM, Arnd Bergmann wrote:
> On Fri, Jul 28, 2017 at 4:07 PM, Jason Gerecke wrote:
>> On July 28, 2017 6:18:00 AM PDT, Arnd Bergmann wrote:
>>>The driver has gained a compile-time dependency that we should
>>>express
On Fri, Jul 28, 2017 at 7:18 AM, Arnd Bergmann wrote:
> On Fri, Jul 28, 2017 at 4:07 PM, Jason Gerecke wrote:
>> On July 28, 2017 6:18:00 AM PDT, Arnd Bergmann wrote:
>>>The driver has gained a compile-time dependency that we should
>>>express in Kconfig to avoid this link error:
>>>
>>
>>
On Fri, Jul 28, 2017 at 03:55:44PM +0200, Andrew Lunn wrote:
> On Fri, Jul 28, 2017 at 11:28:15AM +0200, Corentin Labbe wrote:
> > Hello
> >
> > The current way to find if the phy is internal is to compare DT phy-mode
> > and emac_variant/internal_phy.
> > But it will negate a possible future SoC
On Fri, Jul 28, 2017 at 03:55:44PM +0200, Andrew Lunn wrote:
> On Fri, Jul 28, 2017 at 11:28:15AM +0200, Corentin Labbe wrote:
> > Hello
> >
> > The current way to find if the phy is internal is to compare DT phy-mode
> > and emac_variant/internal_phy.
> > But it will negate a possible future SoC
From: Jeff Layton
This patch converts most of the in-kernel filesystems that do writeback
out of the pagecache to report errors using the errseq_t-based
infrastructure that was recently added. This allows them to report
errors once for each open file description.
Most
From: Jeff Layton
This patch converts most of the in-kernel filesystems that do writeback
out of the pagecache to report errors using the errseq_t-based
infrastructure that was recently added. This allows them to report
errors once for each open file description.
Most filesystems have a fairly
701 - 800 of 1540 matches
Mail list logo