RTL8723BS driver doesn't work for,me but I can help testing
Hello Community I was referred to you by Martin. I have an older Android TV box that runs for over 3 years with Armbian Linux (Debian Jessie Headless Kernel 3.10.99). I'm looking forward to the new kernels and I'm glad that older hardware is still supported. Together with Oleg(balbes150) and Martin(xdarklight) I am testing the new kernel 5.x for ARM ( Amlogic S812 / Meson8m2 ) . Martin has written a patch for the SDIO controller in the last days so that also Wifi module and MMC are recognized. I could now successfully load the driver module RTLWIFI from the kernel. But unfortunately the card is only listed on the desktop as "not ready" or in the terminal (iwlist) as "no scan result". In the dmesg/lsmod RTLWIFI->RTL8723bs is loaded and the module is loaded with version v4.3.5.5_12290.20140916_BTCOEX20140507-4E40 . I would like to ask you to check the driver because even in kernel 3.10.99 a newer version (v4.3.16_13854.20150410_BTCOEX20150119-5844) is loaded and also at github are hard kernels ( version 2017 Kernel 4.9>) and ap17 and thirdyouth (v5.2.17.1_26955.20180307_COEX20180201-6f52). More recent ones can also be found - these have already been successfully tested with Debian 10. i hope that this may solve the problem with my Linux box. I would appreciate feedback on this request or information about debugging . My Linux box is also available for testing purposes Kindly Tobias Baumann (RaptorSDS) -- Diese E-Mail wurde von AVG auf Viren geprüft. http://www.avg.com ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: iio: ad5933: rework probe to use devm_ function variants
On Sat, May 02, 2020 at 07:25:42PM +0100, Jonathan Cameron wrote:
> On Tue, 28 Apr 2020 12:31:28 +0300
> Alexandru Ardelean wrote:
> > +static void ad5933_cleanup(void *data)
> > +{
> > + struct ad5933_state *st = data;
> > +
> > + clk_disable_unprepare(st->mclk);
> > + regulator_disable(st->reg);
>
> Please do two separate callbacks so that these can be handled
> in the correct places. I.e. you do something then immediately
> register the handler to undo it.
>
> Currently you can end up disabling a clock you haven't enabled
> (which I am fairly sure will give you an error message).
Yeah. It does.
It feels like we should just make a devm_ version of regulator_enable().
Or potentially this is more complicated than it seems, but in that case
probably adding devm_add_action_or_reset() is more complicated than it
seems as well.
regards,
dan carpenter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC] mm/gup.c: Updated return value of {get|pin}_user_pages_fast()
On Wed 06-05-20 21:38:40, Souptick Joarder wrote:
> On Wed, May 6, 2020 at 6:29 PM Jan Kara wrote:
> >
> > On Wed 06-05-20 17:51:39, Souptick Joarder wrote:
> > > On Wed, May 6, 2020 at 3:36 PM Jan Kara wrote:
> > > >
> > > > On Wed 06-05-20 02:06:56, Souptick Joarder wrote:
> > > > > On Wed, May 6, 2020 at 1:08 AM John Hubbard
> > > > > wrote:
> > > > > >
> > > > > > On 2020-05-05 12:14, Souptick Joarder wrote:
> > > > > > > Currently {get|pin}_user_pages_fast() have 3 return value 0,
> > > > > > > -errno
> > > > > > > and no of pinned pages. The only case where these two functions
> > > > > > > will
> > > > > > > return 0, is for nr_pages <= 0, which doesn't find a valid use
> > > > > > > case.
> > > > > > > But if at all any, then a -ERRNO will be returned instead of 0,
> > > > > > > which
> > > > > > > means {get|pin}_user_pages_fast() will have 2 return values
> > > > > > > -errno &
> > > > > > > no of pinned pages.
> > > > > > >
> > > > > > > Update all the callers which deals with return value 0
> > > > > > > accordingly.
> > > > > >
> > > > > > Hmmm, seems a little shaky. In order to do this safely, I'd
> > > > > > recommend
> > > > > > first changing gup_fast/pup_fast so so that they return -EINVAL if
> > > > > > the caller specified nr_pages==0, and of course auditing all
> > > > > > callers,
> > > > > > to ensure that this won't cause problems.
> > > > >
> > > > > While auditing it was figured out, there are 5 callers which cares for
> > > > > return value
> > > > > 0 of gup_fast/pup_fast. What problem it might cause if we change
> > > > > gup_fast/pup_fast
> > > > > to return -EINVAL and update all the callers in a single commit ?
> > > >
> > > > Well, first I'd ask a different question: Why do you want to change the
> > > > current behavior? It's not like the current behavior is confusing.
> > > > Callers
> > > > that pass >0 pages can happily rely on the simple behavior of < 0
> > > > return on
> > > > error or > 0 return if we mapped some pages. Callers that can possibly
> > > > ask
> > > > to map 0 pages can get 0 pages back - kind of expected - and I don't see
> > > > any benefit in trying to rewrite these callers to handle -EINVAL
> > > > instead...
> > >
> > > Callers with a request to map 0 pages doesn't have a valid use case. But
> > > if any
> > > caller end up doing it mistakenly, -errno should be returned to caller
> > > rather than 0
> > > which will indicate more precisely that map 0 pages is not a valid
> > > request from caller.
> >
> > Well, I believe this depends on the point of view. Similarly as reading 0
> > bytes is successful, we could consider mapping 0 pages successful as well.
> > And there can be valid cases where number of pages to map is computed from
> > some input and when 0 pages should be mapped, it is not a problem and your
> > change would force such callers to special case this with explicitely
> > checking for 0 pages to map and not calling GUP in that case at all.
> >
> > I'm not saying what you propose is necessarily bad, I just say I don't find
> > it any better than the current behavior and so IMO it's not worth the
> > churn. Now if you can come up with some examples of current in-kernel users
> > who indeed do get the handling of the return value wrong, I could be
> > convinced otherwise.
>
> There are 5 callers of {get|pin}_user_pages_fast().
Oh, there are *much* more callers that 5. It's more like 70. Just grep the
source... And then you have all other {get|pin}_user_pages() variants that
need to be kept consistent. So overall we have over 200 calls to some
variant of GUP.
> arch/ia64/kernel/err_inject.c#L145
> staging/gasket/gasket_page_table.c#L489
>
> Checking return value 0 doesn't make sense for above 2.
>
> drivers/platform/goldfish/goldfish_pipe.c#L277
> net/rds/rdma.c#L165
> drivers/tee/tee_shm.c#L262
>
> These 3 callers have calculated the no of pages value before passing it to
> {get|pin}_user_pages_fast(). But if they end up passing nr_pages <= 0, a
> return
> value of either 0 or -EINVAL doesn't going to harm any existing
> behavior of callers.
>
> IMO, it is safe to return -errno for nr_pages <= 0, for
> {get|pin}_user_pages_fast().
OK, so no real problem with any of these callers. I still don't see a
justification for the churn you suggest... Auditting all those code sites
is going to be pretty tedious.
Honza
--
Jan Kara
SUSE Labs, CR
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC] mm/gup.c: Updated return value of {get|pin}_user_pages_fast()
On Thu, May 7, 2020 at 3:43 PM Jan Kara wrote:
>
> On Wed 06-05-20 21:38:40, Souptick Joarder wrote:
> > On Wed, May 6, 2020 at 6:29 PM Jan Kara wrote:
> > >
> > > On Wed 06-05-20 17:51:39, Souptick Joarder wrote:
> > > > On Wed, May 6, 2020 at 3:36 PM Jan Kara wrote:
> > > > >
> > > > > On Wed 06-05-20 02:06:56, Souptick Joarder wrote:
> > > > > > On Wed, May 6, 2020 at 1:08 AM John Hubbard
> > > > > > wrote:
> > > > > > >
> > > > > > > On 2020-05-05 12:14, Souptick Joarder wrote:
> > > > > > > > Currently {get|pin}_user_pages_fast() have 3 return value 0,
> > > > > > > > -errno
> > > > > > > > and no of pinned pages. The only case where these two functions
> > > > > > > > will
> > > > > > > > return 0, is for nr_pages <= 0, which doesn't find a valid use
> > > > > > > > case.
> > > > > > > > But if at all any, then a -ERRNO will be returned instead of 0,
> > > > > > > > which
> > > > > > > > means {get|pin}_user_pages_fast() will have 2 return values
> > > > > > > > -errno &
> > > > > > > > no of pinned pages.
> > > > > > > >
> > > > > > > > Update all the callers which deals with return value 0
> > > > > > > > accordingly.
> > > > > > >
> > > > > > > Hmmm, seems a little shaky. In order to do this safely, I'd
> > > > > > > recommend
> > > > > > > first changing gup_fast/pup_fast so so that they return -EINVAL if
> > > > > > > the caller specified nr_pages==0, and of course auditing all
> > > > > > > callers,
> > > > > > > to ensure that this won't cause problems.
> > > > > >
> > > > > > While auditing it was figured out, there are 5 callers which cares
> > > > > > for
> > > > > > return value
> > > > > > 0 of gup_fast/pup_fast. What problem it might cause if we change
> > > > > > gup_fast/pup_fast
> > > > > > to return -EINVAL and update all the callers in a single commit ?
> > > > >
> > > > > Well, first I'd ask a different question: Why do you want to change
> > > > > the
> > > > > current behavior? It's not like the current behavior is confusing.
> > > > > Callers
> > > > > that pass >0 pages can happily rely on the simple behavior of < 0
> > > > > return on
> > > > > error or > 0 return if we mapped some pages. Callers that can
> > > > > possibly ask
> > > > > to map 0 pages can get 0 pages back - kind of expected - and I don't
> > > > > see
> > > > > any benefit in trying to rewrite these callers to handle -EINVAL
> > > > > instead...
> > > >
> > > > Callers with a request to map 0 pages doesn't have a valid use case.
> > > > But if any
> > > > caller end up doing it mistakenly, -errno should be returned to caller
> > > > rather than 0
> > > > which will indicate more precisely that map 0 pages is not a valid
> > > > request from caller.
> > >
> > > Well, I believe this depends on the point of view. Similarly as reading 0
> > > bytes is successful, we could consider mapping 0 pages successful as well.
> > > And there can be valid cases where number of pages to map is computed from
> > > some input and when 0 pages should be mapped, it is not a problem and your
> > > change would force such callers to special case this with explicitely
> > > checking for 0 pages to map and not calling GUP in that case at all.
> > >
> > > I'm not saying what you propose is necessarily bad, I just say I don't
> > > find
> > > it any better than the current behavior and so IMO it's not worth the
> > > churn. Now if you can come up with some examples of current in-kernel
> > > users
> > > who indeed do get the handling of the return value wrong, I could be
> > > convinced otherwise.
> >
> > There are 5 callers of {get|pin}_user_pages_fast().
>
> Oh, there are *much* more callers that 5. It's more like 70. Just grep the
> source... And then you have all other {get|pin}_user_pages() variants that
> need to be kept consistent. So overall we have over 200 calls to some
> variant of GUP.
Sorry, I mean, there are 5 callers of {get|pin}_user_pages_fast() who
have interest in
return value 0, out of total 42.
>
> > arch/ia64/kernel/err_inject.c#L145
> > staging/gasket/gasket_page_table.c#L489
> >
> > Checking return value 0 doesn't make sense for above 2.
> >
> > drivers/platform/goldfish/goldfish_pipe.c#L277
> > net/rds/rdma.c#L165
> > drivers/tee/tee_shm.c#L262
> >
> > These 3 callers have calculated the no of pages value before passing it to
> > {get|pin}_user_pages_fast(). But if they end up passing nr_pages <= 0, a
> > return
> > value of either 0 or -EINVAL doesn't going to harm any existing
> > behavior of callers.
> >
> > IMO, it is safe to return -errno for nr_pages <= 0, for
> > {get|pin}_user_pages_fast().
>
> OK, so no real problem with any of these callers. I still don't see a
> justification for the churn you suggest... Auditting all those code sites
> is going to be pretty tedious.
I try to audit all 42 callers of {get|pin}_user_pages_fast() and
figure out these 5 callers
which need to be updated and I think, other callers of
{get|pin}_user_pages_fast() will not be
effected.
But I didn
[PATCH][next] staging: most: usb: sanity check channel before using it as an index into arrays
From: Colin Ian King
Currently channel is being sanity checked after it has been used as
an index into some arrays. Fix this by moving the sanity check of
channel before the arrays are indexed with it.
Addresses-Coverity: ("Negative array index read")
Fixes: 59ed0480b950 ("Staging: most: replace pr_*() functions by dev_*()")
Signed-off-by: Colin Ian King
---
drivers/staging/most/usb/usb.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/most/usb/usb.c b/drivers/staging/most/usb/usb.c
index b31a49c37f7f..24ebd3071380 100644
--- a/drivers/staging/most/usb/usb.c
+++ b/drivers/staging/most/usb/usb.c
@@ -664,11 +664,6 @@ static int hdm_configure_channel(struct most_interface
*iface, int channel,
struct most_dev *mdev = to_mdev(iface);
struct device *dev = &mdev->usb_device->dev;
- mdev->is_channel_healthy[channel] = true;
- mdev->clear_work[channel].channel = channel;
- mdev->clear_work[channel].mdev = mdev;
- INIT_WORK(&mdev->clear_work[channel].ws, wq_clear_halt);
-
if (!conf) {
dev_err(dev, "Bad config pointer.\n");
return -EINVAL;
@@ -677,6 +672,12 @@ static int hdm_configure_channel(struct most_interface
*iface, int channel,
dev_err(dev, "Channel ID out of range.\n");
return -EINVAL;
}
+
+ mdev->is_channel_healthy[channel] = true;
+ mdev->clear_work[channel].channel = channel;
+ mdev->clear_work[channel].mdev = mdev;
+ INIT_WORK(&mdev->clear_work[channel].ws, wq_clear_halt);
+
if (!conf->num_buffers || !conf->buffer_size) {
dev_err(dev, "Misconfig: buffer size or #buffers zero.\n");
return -EINVAL;
--
2.25.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC] mm/gup.c: Updated return value of {get|pin}_user_pages_fast()
On 2020-05-07 03:32, Souptick Joarder wrote:
...
OK, so no real problem with any of these callers. I still don't see a
justification for the churn you suggest... Auditting all those code sites
is going to be pretty tedious.
I try to audit all 42 callers of {get|pin}_user_pages_fast() and
figure out these 5 callers
which need to be updated and I think, other callers of
{get|pin}_user_pages_fast() will not be
effected.
But I didn't go through other variants of gup/pup except
{get|pin}_user_pages_fast().
I feel the need to apologize for suggesting that a change to -EINVAL
would help. :)
If you change what the return value means, but only apply it the
gup/pup _fast() variants of this API set, that would make
the API significantly *worse*.
Also, no one has been able to come up with a scenario in which the call
sites actually have a problem handling return values of zero. In fact,
on the contrary: there are call site where returning 0 after being
requested to pin zero pages, helps simplify the code. For example, if
they're just doing math such as "if(nr_expected != nr_pages_pinned) ...".
This looks like a complete dead end, sorry.
thanks,
--
John Hubbard
NVIDIA
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] greybus: audio: remove unused code
GREYBUS_AUDIO_MSM8994 is not an existing configuration option and as
reported in September 2016, it depends on an "out-of-tree qualcomm audio
driver". This driver never made it upstream.
https://lore.kernel.org/lkml/20160921073905.ga31...@kroah.com/
Moreover, there doesn't seem to be any interest in actually fixing the
driver as it uses ASoC APIs that have been removed from the kernel in 2018
as shown by its use of snd_soc_register_codec and
snd_soc_codec_get_drvdata, removed in commit 999f7f5af8eb ("ASoC: remove
Codec related code").
Signed-off-by: Alexandre Belloni
---
drivers/staging/greybus/Makefile |4 -
drivers/staging/greybus/audio_codec.c| 1103
drivers/staging/greybus/audio_module.c | 478 ---
drivers/staging/greybus/audio_topology.c | 1448 --
4 files changed, 3033 deletions(-)
delete mode 100644 drivers/staging/greybus/audio_codec.c
delete mode 100644 drivers/staging/greybus/audio_module.c
delete mode 100644 drivers/staging/greybus/audio_topology.c
diff --git a/drivers/staging/greybus/Makefile b/drivers/staging/greybus/Makefile
index 627e44f2a983..af88583cdc20 100644
--- a/drivers/staging/greybus/Makefile
+++ b/drivers/staging/greybus/Makefile
@@ -27,8 +27,6 @@ obj-$(CONFIG_GREYBUS_RAW) += gb-raw.o
obj-$(CONFIG_GREYBUS_VIBRATOR) += gb-vibrator.o
# Greybus Audio is a bunch of modules
-gb-audio-module-y := audio_module.o audio_topology.o
-gb-audio-codec-y := audio_codec.o
gb-audio-gb-y := audio_gb.o
gb-audio-apbridgea-y := audio_apbridgea.o
gb-audio-manager-y := audio_manager.o audio_manager_module.o
@@ -40,8 +38,6 @@ gb-audio-manager-y:= audio_manager.o
audio_manager_module.o
#ccflags-y += -DGB_AUDIO_MANAGER_SYSFS
#endif
-obj-$(CONFIG_GREYBUS_AUDIO_MSM8994)+= gb-audio-codec.o
-obj-$(CONFIG_GREYBUS_AUDIO_MSM8994)+= gb-audio-module.o
obj-$(CONFIG_GREYBUS_AUDIO)+= gb-audio-gb.o
obj-$(CONFIG_GREYBUS_AUDIO)+= gb-audio-apbridgea.o
obj-$(CONFIG_GREYBUS_AUDIO)+= gb-audio-manager.o
diff --git a/drivers/staging/greybus/audio_codec.c
b/drivers/staging/greybus/audio_codec.c
deleted file mode 100644
index 08746c85dea6..
--- a/drivers/staging/greybus/audio_codec.c
+++ /dev/null
@@ -1,1103 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0
-/*
- * APBridge ALSA SoC dummy codec driver
- * Copyright 2016 Google Inc.
- * Copyright 2016 Linaro Ltd.
- */
-#include
-#include
-#include
-#include
-#include
-#include
-
-#include "audio_codec.h"
-#include "audio_apbridgea.h"
-#include "audio_manager.h"
-
-static struct gbaudio_codec_info *gbcodec;
-
-static struct gbaudio_data_connection *
-find_data(struct gbaudio_module_info *module, int id)
-{
- struct gbaudio_data_connection *data;
-
- list_for_each_entry(data, &module->data_list, list) {
- if (id == data->id)
- return data;
- }
- return NULL;
-}
-
-static struct gbaudio_stream_params *
-find_dai_stream_params(struct gbaudio_codec_info *codec, int id, int stream)
-{
- struct gbaudio_codec_dai *dai;
-
- list_for_each_entry(dai, &codec->dai_list, list) {
- if (dai->id == id)
- return &dai->params[stream];
- }
- return NULL;
-}
-
-static int gbaudio_module_enable_tx(struct gbaudio_codec_info *codec,
- struct gbaudio_module_info *module, int id)
-{
- int module_state, ret = 0;
- u16 data_cport, i2s_port, cportid;
- u8 sig_bits, channels;
- u32 format, rate;
- struct gbaudio_data_connection *data;
- struct gbaudio_stream_params *params;
-
- /* find the dai */
- data = find_data(module, id);
- if (!data) {
- dev_err(module->dev, "%d:DATA connection missing\n", id);
- return -ENODEV;
- }
- module_state = data->state[SNDRV_PCM_STREAM_PLAYBACK];
-
- params = find_dai_stream_params(codec, id, SNDRV_PCM_STREAM_PLAYBACK);
- if (!params) {
- dev_err(codec->dev, "Failed to fetch dai_stream pointer\n");
- return -EINVAL;
- }
-
- /* register cport */
- if (module_state < GBAUDIO_CODEC_STARTUP) {
- i2s_port = 0; /* fixed for now */
- cportid = data->connection->hd_cport_id;
- ret = gb_audio_apbridgea_register_cport(data->connection,
- i2s_port, cportid,
- AUDIO_APBRIDGEA_DIRECTION_TX);
- if (ret) {
- dev_err_ratelimited(module->dev,
- "reg_cport failed:%d\n", ret);
- return ret;
- }
- data->state[SNDRV_PCM_STREAM_PLAYBACK] =
- GBAUDIO_CODEC_STARTUP;
- dev_dbg(module->dev, "Dynamic Register %d DAI\n", cportid);
-
