Some properties were parsed from the device tree and then ignored by the
driver. Some would return an error if absent from the device tree, then
return an error if they were found because they are unsupported by the
driver.
Avoid parsing unused properties and clearly explain in the documentation
t
Request device's resources (memory, interrupt...) using managed
function.
Signed-off-by: Quentin Deslandes
---
drivers/staging/axis-fifo/axis-fifo.c | 45 ---
1 file changed, 13 insertions(+), 32 deletions(-)
diff --git a/drivers/staging/axis-fifo/axis-fifo.c
b/drivers/
Remove unused resource pointer from the device's internal structure.
Signed-off-by: Quentin Deslandes
---
drivers/staging/axis-fifo/axis-fifo.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/axis-fifo/axis-fifo.c
b/drivers/staging/axis-fifo/axis-
Avoid parsing unused device tree properties and add a note on ignored /
unsupported properties inside the joined documentation instead.
Also use managed functions to claim the device's resources and remove unused
resource pointer from the device's internal structure.
Quentin Deslandes (3):
stag
On Fri, Nov 01, 2019 at 09:57:31PM +0100, Geert Uytterhoeven wrote:
> Hi Valdis,
>
> On Thu, Oct 31, 2019 at 2:11 AM Valdis Kletnieks
> wrote:
> > Three questions: (a) ACK/NAK on this patch, (b) should it be all in one
> > patch, or one to add to errno.h and 6 patches for 6 filesystems?), and
> >
Hi Valdis,
On Thu, Oct 31, 2019 at 2:11 AM Valdis Kletnieks
wrote:
> Three questions: (a) ACK/NAK on this patch, (b) should it be all in one
> patch, or one to add to errno.h and 6 patches for 6 filesystems?), and
> (c) if one patch, who gets to shepherd it through?
>
> There's currently 6 filesy
On 24.10.19 14:09, David Hildenbrand wrote:
This is the result of a recent discussion with Michal ([1], [2]). Right
now we set all pages PG_reserved when initializing hotplugged memmaps. This
includes ZONE_DEVICE memory. In case of system memory, PG_reserved is
cleared again when onlining the mem
At a slight footprint cost (24 vs 32 bytes), mutexes are more optimal
than semaphores; it's also a nicer interface for mutual exclusion,
which is why they are encouraged over binary semaphores, when possible.
There is also lockdep support.
For both f_sem and b_sem, their semantics imply traditiona
There is no need to be using a semaphore, or a sleeping lock
in the first place: critical region is extremely short, does not
call into any blocking calls and furthermore lock and unlocking
operations occur in the same context.
Get rid of another semaphore user by replacing it with a spinlock.
Si
The current code is a no-op, because all it can do is 'dev_kfree_skb(NULL)'
Revert the test to free skb, if not NULL.
Signed-off-by: Christophe JAILLET
---
This patch is purely speculative.
The 'if (...)' could also be removed completely if we refactor the code
and return directly at the beginn
Attn Dear,Funds Beneficiary.
Contact Money Gram international service-Benin to receive your payment
funds US$2.500,000 Million approved this morning through the UN
payment settlement organization.
Contact Person, Mr. John Dave.
Official Director.Money Gram-Benin
Email: moneygram.1...@outlook.fr
Tel
Attn Dear,Funds Beneficiary.
Contact Money Gram international service-Benin to receive your payment
funds US$2.500,000 Million approved this morning through the UN
payment settlement organization.
Contact Person, Mr. John Dave.
Official Director.Money Gram-Benin
Email: moneygram.1...@outlook.fr
Tel
On Fri, Nov 01, 2019 at 02:26:04PM +, Colin King wrote:
> From: Colin Ian King
>
> Currently the for-loop counter i is a u8 however it is being checked
> against a maximum value priv->ieee80211->LinkDetectInfo.SlotNum which is a
> u16. Hence there is a potential wrap-around of counter i back
From: Colin Ian King
Currently the for-loop counter i is a u8 however it is being checked
against a maximum value priv->ieee80211->LinkDetectInfo.SlotNum which is a
u16. Hence there is a potential wrap-around of counter i back to zero if
priv->ieee80211->LinkDetectInfo.SlotNum is greater than 255
On Thu, Oct 31, 2019 at 05:03:56PM +0100, Roi Martin wrote:
> > > diff --git a/drivers/staging/exfat/exfat_core.c
> > > b/drivers/staging/exfat/exfat_core.c
> > > index f71235c6a338..f4f82aecc05d 100644
> > > --- a/drivers/staging/exfat/exfat_core.c
> > > +++ b/drivers/staging/exfat/exfat_core.c
>
On Mon, Oct 28, 2019 at 04:39:50AM -0700, Christoph Hellwig wrote:
> On Mon, Oct 28, 2019 at 12:17:43PM +0100, Hans de Goede wrote:
> > Hi Greg,
> >
> > As discussed previously can you please take vboxsf upstream through
> > drivers/staging?
> >
> > It has seen many revisions on the fsdevel list,
16 matches
Mail list logo
