On Mon, May 06, 2019 at 04:40:29PM +0200, Nicolas Saenz Julienne wrote:
> The killable version of wait_for_completion() is meant to be used on
> situations where it should not fail at all costs, but still have the
> convenience of being able to kill it if really necessary. VCHIQ doesn't
> fit this
From: Lubomir Rintel
[ Upstream commit 33f49571d75024b1044cd02689ad2bdb4924cc80 ]
WARNING: unmet direct dependencies detected for BACKLIGHT_CLASS_DEVICE
Depends on [n]: HAS_IOMEM [=y] && BACKLIGHT_LCD_SUPPORT [=n]
Selected by [y]:
- FB_OLPC_DCON [=y] && STAGING [=y] && X86 [=y] &&
This is a complete low memory killer solution for Android that is small
and simple. Processes are killed according to the priorities that
Android gives them, so that the least important processes are always
killed first. Processes are killed until memory deficits are satisfied,
as observed from
On 2019/5/6 19:01, Chengguang Xu wrote:
> Set sb->s_root to NULL when failing from __getname(),
> so that we can avoid double dput and unnecessary operations
> in generic_shutdown_super().
>
> Signed-off-by: Chengguang Xu
Reviewed-by: Chao Yu
Thanks,
> This patch fixes following warning reported by kbuild test robot:
>
> In function ‘memcpy’,
> inlined from ‘smsc75xx_init_mac_address’ at
> drivers/net/usb/smsc75xx.c:778:3,
> inlined from ‘smsc75xx_bind’ at drivers/net/usb/smsc75xx.c:1501:2:
> ./include/linux/string.h:355:9:
This patch fixes following warning reported by kbuild test robot:
In function ‘memcpy’,
inlined from ‘smsc75xx_init_mac_address’ at
drivers/net/usb/smsc75xx.c:778:3,
inlined from ‘smsc75xx_bind’ at drivers/net/usb/smsc75xx.c:1501:2:
./include/linux/string.h:355:9: warning: argument 2
There was NVMEM support added to of_get_mac_address, so it could now
return ERR_PTR encoded error values, so we need to adjust all current
users of of_get_mac_address to this new fact.
While at it, remove superfluous is_valid_ether_addr as the MAC address
returned from of_get_mac_address is
Commit 284eb160681c ("staging: octeon-ethernet: support
of_get_mac_address new ERR_PTR error") has introduced checking for
ERR_PTR encoded error value from of_get_mac_address with IS_ERR macro,
which is not sufficient in this case, as the mac variable is set to NULL
initialy and if the kernel is
There was NVMEM support added to of_get_mac_address, so it could now
return ERR_PTR encoded error values, so we need to adjust all current
users of of_get_mac_address to this new fact.
While at it, remove superfluous is_valid_ether_addr as the MAC address
returned from of_get_mac_address is
Hi,
this patch series is an attempt to fix the mess, I've somehow managed to
introduce.
First patch in this series is defacto v5 of the previous 05/10 patch in the
series, but since the v4 of this 05/10 patch wasn't picked up by the
patchwork for some unknown reason, this patch wasn't applied
On Mon, 2019-05-06 at 20:12 +0200, Stefan Wahren wrote:
> Hi Nicolas,
>
> Am 06.05.19 um 16:40 schrieb Nicolas Saenz Julienne:
> > Hi,
> > ...
> >
> > Regards,
> > Nicolas
> >
> > [1] https://github.com/raspberrypi/linux/issues/2881
> > [2]
Hi Nicolas,
Am 06.05.19 um 16:40 schrieb Nicolas Saenz Julienne:
> Hi,
> ...
>
> Regards,
> Nicolas
>
> [1] https://github.com/raspberrypi/linux/issues/2881
> [2] https://archlinuxarm.org/forum/viewtopic.php?f=65=13485
> [3]
>
Hi Nicolas,
Am 06.05.19 um 17:59 schrieb Nicolas Saenz Julienne:
> Hi Dan, thanks for reviewing.
>
> On Mon, 2019-05-06 at 18:20 +0300, Dan Carpenter wrote:
>> On Mon, May 06, 2019 at 04:40:29PM +0200, Nicolas Saenz Julienne wrote:
>>> @@ -1740,7 +1740,8 @@ parse_rx_slots(struct vchiq_state
Commit 284eb160681c ("staging: octeon-ethernet: support
of_get_mac_address new ERR_PTR error") has introduced checking for
ERR_PTR encoded error value from of_get_mac_address with IS_ERR macro,
which is not sufficient in this case, as the mac variable is set to NULL
initialy and if the kernel is
There was NVMEM support added to of_get_mac_address, so it could now return
ERR_PTR encoded error values, so we need to adjust all current users of
of_get_mac_address to this new fact.
While at it, remove superfluous is_valid_ether_addr as the MAC address
returned from of_get_mac_address is
There was NVMEM support added to of_get_mac_address, so it could now
return ERR_PTR encoded error values, so we need to adjust all current
users of of_get_mac_address to this new fact.
While at it, remove superfluous is_valid_ether_addr as the MAC address
returned from of_get_mac_address is
Hi,
this patch series is an attempt to fix the mess, I've somehow managed to
introduce.
First patch in this series is defacto v5 of the previous 05/10 patch in the
series, but since the v4 of this 05/10 patch wasn't picked up by the
patchwork for some unknown reason, this patch wasn't applied
Hi Dan, thanks for reviewing.
On Mon, 2019-05-06 at 18:20 +0300, Dan Carpenter wrote:
> On Mon, May 06, 2019 at 04:40:29PM +0200, Nicolas Saenz Julienne wrote:
> > @@ -1740,7 +1740,8 @@ parse_rx_slots(struct vchiq_state *state)
> > >bulk_rx : >bulk_tx;
> >
>
>-Original Message-
>From: 'gre...@linuxfoundation.org'
>On Sun, May 05, 2019 at 10:14:17PM +, Matt Sickler wrote:
>> The I2C and SPI drivers don't depend on anything other than the I2C
>> and SPI subsystems. Actually, they might be depending on the kp2000
>> driver having the PCIe
On Mon, May 06, 2019 at 04:40:29PM +0200, Nicolas Saenz Julienne wrote:
> @@ -1740,7 +1740,8 @@ parse_rx_slots(struct vchiq_state *state)
> >bulk_rx : >bulk_tx;
>
> DEBUG_TRACE(PARSE_LINE);
> - if
On Mon, May 06, 2019 at 02:38:16PM +, Matt Sickler wrote:
> >-Original Message-
> >From: 'gre...@linuxfoundation.org'
> >On Sun, May 05, 2019 at 10:14:17PM +, Matt Sickler wrote:
> >> The I2C and SPI drivers don't depend on anything other than the I2C
> >> and SPI subsystems.
On Mon, May 06, 2019 at 11:58:35AM +0200, Petr Štetiar wrote:
> There was NVMEM support added to of_get_mac_address, so it could now return
> ERR_PTR encoded error values, so we need to adjust all current users of
> of_get_mac_address to this new fact.
We need a Fixes tag so we can look at the
The killable version of wait_event() is meant to be used on situations
where it should not fail at all costs, but still have the convenience of
being able to kill it if really necessary. Wait events in VCHIQ doesn't
fit this criteria, as it's mainly used as an interface to V4L2 and ALSA
devices.
The killable version of wait_for_completion() is meant to be used on
situations where it should not fail at all costs, but still have the
convenience of being able to kill it if really necessary. VCHIQ doesn't
fit this criteria, as it's mainly used as an interface to V4L2 and ALSA
devices.
Fixes:
The killable version of down() is meant to be used on situations where
it should not fail at all costs, but still have the convenience of being
able to kill it if really necessary. VCHIQ doesn't fit this criteria, as
it's mainly used as an interface to V4L2 and ALSA devices.
Fixes: ff5979ad8636
Hi,
this series tries to address an issue that came up in Raspbian's kernel
tree [1] and upstream distros [2][3].
We adopted some changes that moved wait calls from a custom
implementation to the more standard killable family of functions. Users
complained that all the VCHIQ threads showed up in
On Sat, 2019-05-04 at 13:43 +0300, Alexandru Ardelean wrote:
> [External]
>
>
> On Sat, May 4, 2019 at 1:25 AM Melissa Wen wrote:
> >
> > Use the bitfield macro FIELD_GET, and GENMASK to do the shift and mask
> > in
> > one go. This makes the code more readable than explicit masking
> >
Hi Chengguang,
On 2019/5/6 ??7:01, Chengguang Xu wrote:
> Set sb->s_root to NULL when failing from __getname(),
> so that we can avoid double dput and unnecessary operations
> in generic_shutdown_super().
>
> Signed-off-by: Chengguang Xu
Thanks for catching this issue and it makes sense.
Set sb->s_root to NULL when failing from __getname(),
so that we can avoid double dput and unnecessary operations
in generic_shutdown_super().
Signed-off-by: Chengguang Xu
---
drivers/staging/erofs/super.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/erofs/super.c
There was NVMEM support added to of_get_mac_address, so it could now return
ERR_PTR encoded error values, so we need to adjust all current users of
of_get_mac_address to this new fact.
While at it, remove superfluous is_valid_ether_addr as the MAC address
returned from of_get_mac_address is
There was NVMEM support added to of_get_mac_address, so it could now
return ERR_PTR encoded error values, so we need to adjust all current
users of of_get_mac_address to this new fact.
While at it, remove superfluous is_valid_ether_addr as the MAC address
returned from of_get_mac_address is
Commit 284eb160681c ("staging: octeon-ethernet: support
of_get_mac_address new ERR_PTR error") has introduced checking for
ERR_PTR encoded error value from of_get_mac_address with IS_ERR macro,
which is not sufficient in this case, as the mac variable is set to NULL
initialy and if the kernel is
Hi,
this patch series is an attempt to fix the mess, I've somehow managed to
introduce.
First patch in this series is defacto v5 of the previous 05/10 patch in the
series, but since the v4 of this 05/10 patch wasn't picked up by the
patchwork for some unknown reason, this patch wasn't applied
On Tue, Apr 16, 2019 at 11:23 PM Arnd Bergmann wrote:
>
> Hi Al,
>
> It took me way longer than I had hoped to revisit this series, see
> https://lore.kernel.org/lkml/20180912150142.157913-1-a...@arndb.de/
> for the previously posted version.
>
> I've come to the point where all conversion
On Sun, May 05, 2019 at 10:14:17PM +, Matt Sickler wrote:
>
> >-Original Message-
> >From: 'gre...@linuxfoundation.org'
> >On Fri, May 03, 2019 at 10:24:00PM +, Matt Sickler wrote:
> >> Hello,
> >>
> >> Recently Greg KH posted the first set of drivers for our PCIe device
>
35 matches
Mail list logo
