From: Colin Ian King
There is a spelling mistake in a DBG_871X error message. Fix it.
Signed-off-by: Colin Ian King
---
drivers/staging/rtl8723bs/os_dep/ioctl_linux.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8723bs/os_dep/ioctl_linux.c
b/drivers/s
Okash Khawaja, le dim. 15 sept. 2019 19:41:30 +0100, a ecrit:
> I have attached the descriptions.
Attachment is missing :)
Samuel
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-deve
On Mon, Sep 16, 2019 at 03:47:28PM +0200, Samuel Thibault wrote:
> Okash Khawaja, le dim. 15 sept. 2019 19:41:30 +0100, a ecrit:
> > I have attached the descriptions.
>
> Attachment is missing :)
I saw it :)
Anyway, please put the Description: lines without a blank after that,
with the descripti
From: Adham Abozaeid
If rtc_clk is provided from DT, use it and enable it.
This is optional.
The signal may be hardcoded and no need to be requested,
but if DT provides it, use it.
Signed-off-by: Adham Abozaeid
---
drivers/staging/wilc1000/wilc_spi.c | 11 +++
1 file changed, 11 insert
On Mon, Sep 16, 2019 at 03:47:28PM +0200, Samuel Thibault wrote:
> Okash Khawaja, le dim. 15 sept. 2019 19:41:30 +0100, a ecrit:
> > I have attached the descriptions.
>
> Attachment is missing :)
>
> Samuel
Samuel, check the message that came to you directly, and it should be
there. The speakup
Code that iterates over all standard PCI BARs typically uses
PCI_STD_RESOURCE_END, but this is error-prone because it requires
"i <= PCI_STD_RESOURCE_END" rather than something like
"i < PCI_STD_NUM_BARS". We could add such a definition and use it the same
way PCI_SRIOV_NUM_BARS is used. The patchs
Remove local definition GASKET_NUM_BARS for the number of PCI BARs and use
global one PCI_STD_NUM_BARS instead.
Cc: Rob Springer
Cc: Todd Poynor
Cc: Ben Chan
Signed-off-by: Denis Efremov
---
drivers/staging/gasket/gasket_constants.h | 3 ---
drivers/staging/gasket/gasket_core.c | 12 +++
On Mon, Sep 16, 2019 at 04:11:00PM +0200, Greg Kroah-Hartman wrote:
> On Mon, Sep 16, 2019 at 03:47:28PM +0200, Samuel Thibault wrote:
> > Okash Khawaja, le dim. 15 sept. 2019 19:41:30 +0100, a ecrit:
> > > I have attached the descriptions.
> >
> > Attachment is missing :)
>
> I saw it :)
>
> An
Hi,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[cannot apply to v5.3 next-20190916]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Adham-Abozaeid
On 9/16/19 5:49 PM, kbuild test robot wrote:
>
> [auto build test ERROR on linus/master]
> [cannot apply to v5.3 next-20190916]
> [if your patch is applied to the wrong git tree, please drop us a note to
> help improve the system]
This patch applies for staging-testing, n
In das1800_attach, the buffer allocated via kmalloc_array needs to be
released if an error happens.
Signed-off-by: Navid Emamdoost
---
drivers/staging/comedi/drivers/das1800.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/comedi/drivers/das1800.
We are excited to see this happening and would like to state that we appreciate
time and
effort which people put into upstreaming exfat. Thank you!
However, if possible, can we step back a little bit and re-consider it? We
would prefer to
see upstream the code which we are currently using in our p
On Tue, 17 Sep 2019 12:02:01 +0900, "Namjae Jeon" said:
> We are excited to see this happening and would like to state that we
> appreciate time and
> effort which people put into upstreaming exfat. Thank you!
The hard part - getting Microsoft to OK merging an exfat driver - is done.
All we need
On Tue, Sep 17, 2019 at 12:02:01PM +0900, Namjae Jeon wrote:
> We are excited to see this happening and would like to state that we
> appreciate
> time and
> effort which people put into upstreaming exfat. Thank you!
>
> However, if possible, can we step back a little bit and re-consider it? We
>
Hi,
On Tue, Sep 17, 2019 at 12:02:01PM +0900, Namjae Jeon wrote:
> We are excited to see this happening and would like to state that we
> appreciate
> time and
> effort which people put into upstreaming exfat. Thank you!
>
> However, if possible, can we step back a little bit and re-consider it?
On Tue, 17 Sep 2019 00:19:36 -0400, "Valdis Klētnieks" said:
> I'm working off a somewhat cleaned up copy of Samsung's original driver,
> because that's what I had knowledge of. If the sdfat driver is closer to
> being
> mergeable, I'd not object if that got merged instead.
Greg, as Valdis menti
On Tue, Sep 17, 2019 at 02:31:34PM +0900, Park Ju Hyung wrote:
> On Tue, 17 Sep 2019 00:19:36 -0400, "Valdis Klētnieks" said:
> > I'm working off a somewhat cleaned up copy of Samsung's original driver,
> > because that's what I had knowledge of. If the sdfat driver is closer to
> > being
> > mer
On Tue, Sep 17, 2019 at 2:47 PM Greg KH wrote:
> It's the fact that it actually was in a form that could be merged, no
> one has done that with the sdfat code :)
Well, I'm more than happy to help if you guys are happy with merging
the new base.
> What fixes? That's what I'm asking here.
I gave
On Mon, Sep 16, 2019 at 09:41:43PM -0500, Navid Emamdoost wrote:
> In das1800_attach, the buffer allocated via kmalloc_array needs to be
> released if an error happens.
>
> Signed-off-by: Navid Emamdoost
Commedit calls ->detach() if the ->attach() fails so this patch would
lead to a double free.
19 matches
Mail list logo
