[driver-core:readfile] BUILD SUCCESS 68b2d084a9af04c5b98108f9b7fc5fb77509ef1a
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git readfile branch HEAD: 68b2d084a9af04c5b98108f9b7fc5fb77509ef1a readfile.2: new page describing readfile(2) elapsed time: 723m configs tested: 117 configs skipped: 5 The following configs have been built successfully. More configs may be tested in the coming days. arm defconfig arm64allyesconfig arm64 defconfig arm allyesconfig arm allmodconfig arm mainstone_defconfig sh sh7770_generic_defconfig mips rbtx49xx_defconfig ia64 bigsur_defconfig arm simpad_defconfig arm axm55xx_defconfig xtensaxip_kc705_defconfig m68k m5475evb_defconfig powerpc holly_defconfig mips pnx8335_stb225_defconfig arm aspeed_g5_defconfig mips bmips_stb_defconfig powerpcamigaone_defconfig sh se7712_defconfig arc tb10x_defconfig sh se7780_defconfig mips sb1250_swarm_defconfig mips tb0287_defconfig shdreamcast_defconfig m68k m5249evb_defconfig alpha defconfig powerpc pasemi_defconfig arm rpc_defconfig m68kmvme147_defconfig m68k multi_defconfig mips loongson1b_defconfig sh apsh4a3a_defconfig mipsbcm47xx_defconfig arm colibri_pxa270_defconfig xtensa defconfig s390 debug_defconfig powerpc powernv_defconfig armspear6xx_defconfig mips db1xxx_defconfig mipsgpr_defconfig arm imx_v4_v5_defconfig arm eseries_pxa_defconfig armpleb_defconfig armkeystone_defconfig arm collie_defconfig ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig m68k allyesconfig nds32 defconfig nios2allyesconfig cskydefconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig arc defconfig sh allmodconfig nios2 defconfig arc allyesconfig nds32 allnoconfig c6x allyesconfig parisc defconfig s390 allyesconfig parisc allyesconfig s390defconfig i386 allyesconfig sparcallyesconfig sparc defconfig i386defconfig mips allyesconfig mips allmodconfig powerpc defconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig x86_64 randconfig-a006-20200806 x86_64 randconfig-a001-20200806 x86_64 randconfig-a004-20200806 x86_64 randconfig-a005-20200806 x86_64 randconfig-a003-20200806 x86_64 randconfig-a002-20200806 i386 randconfig-a005-20200806 i386 randconfig-a004-20200806 i386 randconfig-a001-20200806 i386 randconfig-a002-20200806 i386 randconfig-a003-20200806 i386 randconfig-a006-20200806 i386 randconfig-a005-20200805 i386 randconfig-a004-20200805 i386 randconfig-a001-20200805 i386 randconfig-a003-20200805 i386 randconfig-a002-20200805 i386 randconfig-a006-20200805 x86_64 randconfig-a013-20200805 x86_64 randconfig-a011-20200805 x86_64 randconfig-a012-20200805 x86_64 randconfig-a016-20200805 x86_64 randconfig-a015-20200805 x86_64 randconfig-a014
[driver-core:debugfs_cleanup] BUILD SUCCESS 386703cdbd092acbc66a1f2f4f0406574aaa7d5e
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git debugfs_cleanup branch HEAD: 386703cdbd092acbc66a1f2f4f0406574aaa7d5e debugfs: remove return value of debugfs_create_devm_seqfile() elapsed time: 723m configs tested: 98 configs skipped: 4 The following configs have been built successfully. More configs may be tested in the coming days. arm defconfig arm64allyesconfig arm64 defconfig arm allyesconfig arm allmodconfig arm axm55xx_defconfig xtensaxip_kc705_defconfig m68k m5475evb_defconfig powerpc holly_defconfig mips tb0287_defconfig shdreamcast_defconfig sh r7780mp_defconfig armrealview_defconfig arm sunxi_defconfig microblazenommu_defconfig m68k m5249evb_defconfig powerpcamigaone_defconfig powerpc pasemi_defconfig arm rpc_defconfig m68kmvme147_defconfig m68k multi_defconfig powerpc mpc885_ads_defconfig mips fuloong2e_defconfig sh secureedge5410_defconfig ia64 tiger_defconfig arm mv78xx0_defconfig microblaze mmu_defconfig mips bmips_stb_defconfig mipsbcm47xx_defconfig arm colibri_pxa270_defconfig xtensa defconfig ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig m68k allyesconfig nds32 defconfig nios2allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig arc defconfig sh allmodconfig nios2 defconfig arc allyesconfig nds32 allnoconfig c6x allyesconfig parisc defconfig s390 allyesconfig parisc allyesconfig s390defconfig i386 allyesconfig sparcallyesconfig sparc defconfig i386defconfig mips allyesconfig mips allmodconfig powerpc defconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig i386 randconfig-a005-20200806 i386 randconfig-a004-20200806 i386 randconfig-a001-20200806 i386 randconfig-a002-20200806 i386 randconfig-a003-20200806 i386 randconfig-a006-20200806 i386 randconfig-a005-20200805 i386 randconfig-a004-20200805 i386 randconfig-a001-20200805 i386 randconfig-a003-20200805 i386 randconfig-a002-20200805 i386 randconfig-a006-20200805 i386 randconfig-a011-20200805 i386 randconfig-a012-20200805 i386 randconfig-a013-20200805 i386 randconfig-a014-20200805 i386 randconfig-a015-20200805 i386 randconfig-a016-20200805 x86_64 randconfig-a006-20200806 x86_64 randconfig-a001-20200806 x86_64 randconfig-a004-20200806 x86_64 randconfig-a005-20200806 x86_64 randconfig-a003-20200806 x86_64 randconfig-a002-20200806 riscvallyesconfig riscv allnoconfig riscv defconfig riscvallmodconfig x86_64 rhel x86_64 allyesconfig x86_64rhel-7.6-kselftests x86_64 defconfig x86_64 rhel-8.3 x86_64 kexec --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01
Re: [RESEND PATCH] media: atomisp: Replace trace_printk by pr_info
On Fri, Jul 24, 2020 at 8:41 PM Nicolas Boichat wrote: > > On Fri, Jul 10, 2020 at 3:03 PM Greg Kroah-Hartman > wrote: > > > > On Fri, Jul 10, 2020 at 02:45:29PM +0800, Nicolas Boichat wrote: > > > trace_printk should not be used in production code, replace it > > > call with pr_info. > > > > > > Signed-off-by: Nicolas Boichat > > > --- > > > Sent this before as part of a series (whose 4th patch was a > > > change that allows to detect such trace_printk), but maybe it's > > > easier to get individual maintainer attention by splitting it. > > > > Mauro should take this soon: > > > > Acked-by: Greg Kroah-Hartman > > Mauro: did you get a chance to look at this? (and the other similar > patch "media: camss: vfe: Use trace_printk for debugging only") Mauro: Another gentle ping. Thanks. > Thanks! ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: atomisp: move null check to earlier point
On Thu, Jul 30, 2020 at 11:45:45AM +0300, Dan Carpenter wrote:
> On Wed, Jul 29, 2020 at 06:13:44PM +0300, Andy Shevchenko wrote:
> > On Wed, Jul 29, 2020 at 5:00 PM Cengiz Can wrote:
> > >
> > > `find_gmin_subdev` function that returns a pointer to `struct
> > > gmin_subdev` can return NULL.
> > >
> > > In `gmin_v2p8_ctrl` there's a call to this function but the possibility
> > > of a NULL was not checked before its being dereferenced. ie:
> > >
> > > ```
> > > /* Acquired here v */
> > > struct gmin_subdev *gs = find_gmin_subdev(subdev);
> > > int ret;
> > > int value;
> > >
> > > /* v--Dereferenced here */
> > > if (gs->v2p8_gpio >= 0) {
> > > pr_info("atomisp_gmin_platform: 2.8v power on GPIO %d\n",
> > > gs->v2p8_gpio);
> > > ret = gpio_request(gs->v2p8_gpio, "camera_v2p8");
> > > if (!ret)
> > > ret = gpio_direction_output(gs->v2p8_gpio, 0);
> > > if (ret)
> > > pr_err("V2P8 GPIO initialization failed\n");
> > > }
> > > ```
> > >
> > > I have moved the NULL check before deref point.
> >
> > "Move the NULL check..."
> > See Submitting Patches documentation how to avoid "This patch", "I", "we",
> > etc.
>
> I always feel like this is a pointless requirement. We're turning
> into bureaucrats.
There is a danger of that, and I'm more guilty than most. But I do
think there's value in consistent style because it allows readers to
focus on the content instead of being distracted by different margins,
grammar ("move vs. moved"), paragraph styles, quoting conventions,
etc.
Ideally we would scan previous commit logs (and the existing code!)
and make new changes fit seamlessly so it looks like everything was
done at the same time by the same person.
But often that doesn't happen. Sometimes I take the liberty to tweak
things as I apply them to try to avoid trivial rework.
Bjorn
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [GIT PULL] Staging/IIO driver patches for 5.9-rc1
The pull request you sent on Thu, 6 Aug 2020 14:30:47 +0200: > git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git > tags/staging-5.9-rc1 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/c0c419c04557117258d184876d94091d29bbd9a6 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v6] staging: atomisp: move null check to earlier point
On August 6, 2020 21:39:21 Greg KH wrote: On Thu, Aug 06, 2020 at 09:34:22PM +0300, Cengiz Can wrote: Hello Andy, Can I get some feedback on v6 please? It's been 4 days, in the middle of a merge window, please give people a chance to catch up on other things... I wasn't aware of that we're currently in a merge window. Sorry for my impatience. and do not top post please. Sorry. I was tricked by my mobile email client. thanks, greg k-h Thanks again and I wish a smooth merge window to all maintainers. Cengiz Can ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Reply...
Hello,
My name is Ms. Reem Ebrahim Al-Hashimi, I am the "Minister of state and
Petroleum" also "Minister of
State for International Cooperation" in UAE. I write to you on behalf of my
other "three (3)
colleagues" who has approved me to solicit for your "partnership in claiming of
{us$90=Million}"
from a Financial Home in Cambodia on their behalf and for our "Mutual Benefits".
The Fund {us$90=Million} is our "outstanding share from the Over-invoiced"
Oil/Gas deal with
Cambodian/Vietnam Government within 2013/2014, however, We don't want our
government to know about
the fund. If this proposal interests you, let me know, by sending me an email
and I will send to you
detailed information on how this business would be successfully transacted. Be
informed that nobody
knows about the secret of this fund except us, and we know how to carry out the
entire transaction.
So I am compelled to ask, that you will stand on our behalf and receive this
fund into any account
that is solely controlled by you.
We will compensate you with 30% of the total amount involved as gratification
for being our partner
in this transaction. Reply to my private email as stated:
reemal-hash...@yandex.com
Regards,
Ms. Reem Ebrahim Al-Hashimi.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v6] staging: atomisp: move null check to earlier point
On Thu, Aug 06, 2020 at 09:34:22PM +0300, Cengiz Can wrote: > Hello Andy, > > Can I get some feedback on v6 please? It's been 4 days, in the middle of a merge window, please give people a chance to catch up on other things... and do not top post please. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v6] staging: atomisp: move null check to earlier point
Hello Andy,
Can I get some feedback on v6 please?
I hope it suits your standards this time.
Thank you
On August 2, 2020 01:02:22 Cengiz Can wrote:
`find_gmin_subdev()` that returns a pointer to `struct
gmin_subdev` can return NULL.
In `gmin_v2p8_ctrl()` there's a call to this function but the
possibility of a NULL was not checked before its being dereferenced,
i.e.:
/* Acquired here v */
struct gmin_subdev *gs = find_gmin_subdev(subdev);
/* v--Dereferenced here */
if (gs->v2p8_gpio >= 0) {
...
}
With this change we're null checking `find_gmin_subdev()` result
and we return an error if that's the case. We also WARN()
for the sake of debugging.
Signed-off-by: Cengiz Can
Reported-by: Coverity Static Analyzer CID 1465536
Suggested-by: Mauro Carvalho Chehab
---
Please do note that this change introduces a new return value to
`gmin_v2p8_ctrl()`.
[NEW] - raise a WARN and return -ENODEV if there are no subdevices.
- return result of `gpio_request` or `gpio_direction_output`.
- return 0 if GPIO is ON.
- return results of `regulator_enable` or `regulator_disable`.
- according to PMIC type, return result of `axp_regulator_set`
or `gmin_i2c_write`.
- return -EINVAL if unknown PMIC type.
Patch Changelog:
v4: Fix minor typo in commit message
v5: Remove typo from email subject
v6: Remove duplicate Signed-off-by tag
drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c
b/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c
index 0df46a1af5f0..1ad0246764a6 100644
--- a/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c
+++ b/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c
@@ -871,6 +871,9 @@ static int gmin_v2p8_ctrl(struct v4l2_subdev *subdev,
int on)
int ret;
int value;
+ if (WARN_ON(!gs))
+ return -ENODEV;
+
if (gs->v2p8_gpio >= 0) {
pr_info("atomisp_gmin_platform: 2.8v power on GPIO %d\n",
gs->v2p8_gpio);
@@ -881,7 +884,7 @@ static int gmin_v2p8_ctrl(struct v4l2_subdev *subdev,
int on)
pr_err("V2P8 GPIO initialization failed\n");
}
- if (!gs || gs->v2p8_on == on)
+ if (gs->v2p8_on == on)
return 0;
gs->v2p8_on = on;
--
2.27.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
CONTACT OUR INTERNATIONAL DIPLOMATIC AGENT, MR. JOHN BENDER TO RECEIVE YOUR ATM CARD WORTH $12.8MILLION US DOLLARS, This delivery was approved today, 06/08/2020
Attn,Dear. GOODNEWS FOR YOU. CONTACT OUR INTERNATIONAL DIPLOMATIC AGENT, MR. JOHN BENDER TO RECEIVE YOUR ATM CARD WORTH $12.8MILLION US DOLLARS, This delivery was approved today, 06/08/2020 Contact Person, AGENT, MR. JOHN BENDER Email: john.b...@yahoo.com Phone number (408) 650-6103, call or Text Him once you receive this message. Remember to send to MR. JOHN BENDER your house address i listed below Your Full Name House Address Your Phone Numbers___ Let me know once you receive your delivery ok. Delivery fee to your address is $75.00, ask where to send the fee to Him today. Thanks and may God bless you. David Mark ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v1] staging: greybus: audio: fix uninitialized value issue
The current implementation for gbcodec_mixer_dapm_ctl_put() uses
uninitialized gbvalue for comparison with updated value. This was found
using static analysis with coverity.
Uninitialized scalar variable (UNINIT)
11. uninit_use: Using uninitialized value
gbvalue.value.integer_value[0].
460if (gbvalue.value.integer_value[0] != val) {
This patch fixes the issue with fetching the gbvalue before using it for
comparision.
Fixes: 6339d2322c47 ("greybus: audio: Add topology parser for GB codec")
Reported-by: Colin Ian King
Signed-off-by: Vaibhav Agarwal
---
drivers/staging/greybus/audio_topology.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/greybus/audio_topology.c
b/drivers/staging/greybus/audio_topology.c
index 2f9fdbdcd547..4b914d0edef2 100644
--- a/drivers/staging/greybus/audio_topology.c
+++ b/drivers/staging/greybus/audio_topology.c
@@ -456,6 +456,13 @@ static int gbcodec_mixer_dapm_ctl_put(struct snd_kcontrol
*kcontrol,
val = ucontrol->value.integer.value[0] & mask;
connect = !!val;
+ ret = gb_pm_runtime_get_sync(bundle);
+ if (ret)
+ return ret;
+
+ ret = gb_audio_gb_get_control(module->mgmt_connection, data->ctl_id,
+ GB_AUDIO_INVALID_INDEX, );
+
/* update ucontrol */
if (gbvalue.value.integer_value[0] != val) {
for (wi = 0; wi < wlist->num_widgets; wi++) {
@@ -466,16 +473,10 @@ static int gbcodec_mixer_dapm_ctl_put(struct snd_kcontrol
*kcontrol,
gbvalue.value.integer_value[0] =
cpu_to_le32(ucontrol->value.integer.value[0]);
- ret = gb_pm_runtime_get_sync(bundle);
- if (ret)
- return ret;
-
ret = gb_audio_gb_set_control(module->mgmt_connection,
data->ctl_id,
GB_AUDIO_INVALID_INDEX, );
- gb_pm_runtime_put_autosuspend(bundle);
-
if (ret) {
dev_err_ratelimited(codec_dev,
"%d:Error in %s for %s\n", ret,
@@ -483,6 +484,7 @@ static int gbcodec_mixer_dapm_ctl_put(struct snd_kcontrol
*kcontrol,
return ret;
}
}
+ gb_pm_runtime_put_autosuspend(bundle);
return 0;
}
base-commit: 5bbd90550da8f7bdac769b5825597e67183c9411
prerequisite-patch-id: 2b8901339222ff7b94f10cf2341734c0fb82591c
prerequisite-patch-id: 38dad8879a2b73bce6e89481973c7c5b82bd7145
prerequisite-patch-id: 5f0042ccedae292395ec617789be6bf465463c1c
prerequisite-patch-id: 35d001c366dfa4b567e59abbb37bd691a18f5e14
prerequisite-patch-id: f13ce918ebc3796cd3c81716a7b2adf4519e7387
prerequisite-patch-id: 0fcc6d38699a9b72ca94280d7a4dc18f0823b6f7
prerequisite-patch-id: 8074e935bdc3dd7b114245b0648552d0ff6871c9
--
2.27.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: issue with uninitialized value used in a comparison in gbcodec_mixer_dapm_ctl_put
On Wed, Aug 05, 2020 at 08:35:15AM -0500, Alex Elder wrote: > > I think the fix is to add a call to this: > > ret = gb_audio_gb_get_control(module->mgmt_connection, data->ctl_id, > GB_AUDIO_INVALID_INDEX, ); > > before the field within gbvalue is used. > > Looking at gbcodec_mixer_dapm_ctl_get() defined just above that, it > seems that the call to gb_audio_gb_get_control() should be preceded > by a call to gb_pm_runtime_get_sync(). And given that duplication, > I suggest this call and the PM runtime wrapper functions should be > placed in a new helper function. > > I know that Vaibhav said he would be fixing this, so I guess my > comments are directed at him. Thanks for sending the patch Colin. > > -Alex Thanks Alex. I'll share a patch with the proposed fix. -- vaibhav > > > > Colin > > > > > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH][next][V2] staging: wfx: fix a handful of spelling mistakes
On 8/6/20 3:47 AM, Colin King wrote:
> From: Colin Ian King
>
> There are various spelling mistakes in comments and error messages.
> Fix these.
>
> Signed-off-by: Colin Ian King
> ---
>
> V2: add in some more fixes as spotted by Randy Dunlap
>
> ---
> drivers/staging/wfx/data_rx.c | 2 +-
> drivers/staging/wfx/data_tx.c | 2 +-
> drivers/staging/wfx/debug.c | 6 +++---
> drivers/staging/wfx/hif_rx.c | 2 +-
> drivers/staging/wfx/hif_tx.c | 4 ++--
> drivers/staging/wfx/main.c| 2 +-
> drivers/staging/wfx/main.h| 2 +-
> drivers/staging/wfx/sta.c | 2 +-
> 8 files changed, 11 insertions(+), 11 deletions(-)
> diff --git a/drivers/staging/wfx/main.c b/drivers/staging/wfx/main.c
> index 11dfa088fc86..4263f912760b 100644
> --- a/drivers/staging/wfx/main.c
> +++ b/drivers/staging/wfx/main.c
> @@ -384,7 +384,7 @@ int wfx_probe(struct wfx_dev *wdev)
> err = wfx_sl_init(wdev);
> if (err && wdev->hw_caps.capabilities.link_mode == SEC_LINK_ENFORCED) {
> dev_err(wdev->dev,
> - "chip require secure_link, but can't negociate it\n");
> + "chip require secure_link, but can't negotiate it\n");
requires
> goto err0;
> }
Acked-by: Randy Dunlap
Thanks.
--
~Randy
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[GIT PULL] Staging/IIO driver patches for 5.9-rc1
The following changes since commit 92ed301919932f13b9172e525674157e983d: Linux 5.8-rc7 (2020-07-26 14:14:06 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git tags/staging-5.9-rc1 for you to fetch changes up to 5bbd90550da8f7bdac769b5825597e67183c9411: staging: most: fix up movement of USB driver (2020-08-02 12:47:40 +0200) Staging/IIO driver patches for 5.9-rc1 Here is the large set of Staging and IIO driver patches for 5.9-rc1. Lots of churn here, but overall the size increase in lines added is small, while adding a load of new IIO drivers. Major things in here: - lots and lots of IIO new drivers and frameworks added - IIO driver fixes and updates - lots of tiny coding style cleanups for staging drivers - vc04_services major reworks and cleanups We had 3 set of drivers move out of staging in this round as well: - wilc1000 wireless driver moved out of staging - speakup moved out of staging - most USB driver moved out of staging Full details are in the shortlog. All of these have been in linux-next with no reported issues. The last few changes here were to resolve reported linux-next issues, and they seem to have resolved the problems. Signed-off-by: Greg Kroah-Hartman Aditya Jain (3): staging: rtl8723bs: Fix coding style errors staging: rtl8723bs: Clean up function declations staging: rtl8723bs: Align macro definitions Ajay Singh (1): wilc1000: move wilc driver out of staging Alexander A. Klimov (16): Staging: nvec: Replace HTTP links with HTTPS ones Staging: speakup: Replace HTTP links with HTTPS ones Replace HTTP links with HTTPS ones: Documentation/devicetree/bindings/iio Replace HTTP links with HTTPS ones: drivers/iio staging: Replace HTTP links with HTTPS ones staging: comedi: Replace HTTP links with HTTPS ones staging: comedi: cb: Replace HTTP links with HTTPS ones staging: comedi: adv: Replace HTTP links with HTTPS ones staging: comedi: adl: Replace HTTP links with HTTPS ones staging: comedi: pcm: Replace HTTP links with HTTPS ones staging: comedi: pcl: Replace HTTP links with HTTPS ones staging: comedi: ni: Replace HTTP links with HTTPS ones staging: comedi: dt: Replace HTTP links with HTTPS ones staging: comedi: das: Replace HTTP links with HTTPS ones staging: comedi: amplc: Replace HTTP links with HTTPS ones staging: comedi: addi: Replace HTTP links with HTTPS ones Alexandre Belloni (2): dt-bindings: atmel-tcb: convert bindings to json-schema dt-bindings: microchip: atmel,at91rm9200-tcb: add sama5d2 compatible Alexandru Ardelean (30): iio: light: tsl2563: pass iio device as i2c_client private data iio: light: iqs621: remove usage of iio_priv_to_dev() iio: position: iqs624: remove usage of iio_priv_to_dev() iio: humidity: hts221: remove usage of iio_priv_to_dev() iio: dac: ad5592r: remove usage of iio_priv_to_dev() helper iio: stm32-adc: remove usage of iio_priv_to_dev() helper iio: Kconfig: at91_adc: add COMPILE_TEST dependency to driver iio: core: pass parent device as parameter during allocation iio: core: add iio_device_set_parent() helper iio: remove explicit IIO device parent assignment iio: remove left-over comments about parent assignment iio: light: lm3533-als: use iio_device_set_parent() to assign parent iio: remove left-over parent assignments iio: stm32-dfsdm-adc: remove usage of iio_priv_to_dev() helper iio: at91_adc: remove usage of iio_priv_to_dev() helper iio: at91-sama5d2_adc: remove usage of iio_priv_to_dev() helper iio: core: wrap IIO device into an iio_dev_opaque object iio: core: remove padding from private information iio: core: move debugfs data on the private iio dev info iio: core: move channel list & group to private iio device object iio: core: move iio_dev's buffer_list to the private iio device object iio: core: move event interface on the opaque struct iio: adc: ti_am335x_adc: alloc channels via devm_kcalloc() iio: adc: ti_am335x_adc: alloc kfifo & IRQ via devm_ functions iio: core: remove iio_priv_to_dev() helper iio: buffer: fix attach/detach pollfunc order iio: adc: ad7192: move ad7192_of_match table closer to the end of the file iio: adc: ad7124: move chip ID & name on the chip_info table iio: core: fix/re-introduce back parent assignment iio: dac: ad5592r: fix unbalanced mutex unlocks in ad5592r_read_raw() Anant Thazhemadam (1): STAGING - REALTEK RTL8188EU DRIVERS: Fix Coding Style Error Andy Shevchenko (3): iio: imu: inv_mpu6050: Drop double check for ACPI companion
[PATCH] media: atomisp: fix spelling mistake "unsupport" -> "unsupported"
From: Colin Ian King
There are spelling mistakes in some dev_err messages. Fix these.
Signed-off-by: Colin Ian King
---
drivers/staging/media/atomisp/pci/atomisp_ioctl.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/media/atomisp/pci/atomisp_ioctl.c
b/drivers/staging/media/atomisp/pci/atomisp_ioctl.c
index f8d616f08b51..25312903f27e 100644
--- a/drivers/staging/media/atomisp/pci/atomisp_ioctl.c
+++ b/drivers/staging/media/atomisp/pci/atomisp_ioctl.c
@@ -2588,7 +2588,7 @@ static int atomisp_g_parm(struct file *file, void *fh,
struct atomisp_device *isp = video_get_drvdata(vdev);
if (parm->type != V4L2_BUF_TYPE_VIDEO_CAPTURE) {
- dev_err(isp->dev, "unsupport v4l2 buf type\n");
+ dev_err(isp->dev, "unsupported v4l2 buf type\n");
return -EINVAL;
}
@@ -2610,7 +2610,7 @@ static int atomisp_s_parm(struct file *file, void *fh,
int fps;
if (parm->type != V4L2_BUF_TYPE_VIDEO_CAPTURE) {
- dev_err(isp->dev, "unsupport v4l2 buf type\n");
+ dev_err(isp->dev, "unsupported v4l2 buf type\n");
return -EINVAL;
}
@@ -2668,7 +2668,7 @@ static int atomisp_s_parm_file(struct file *file, void
*fh,
struct atomisp_device *isp = video_get_drvdata(vdev);
if (parm->type != V4L2_BUF_TYPE_VIDEO_OUTPUT) {
- dev_err(isp->dev, "unsupport v4l2 buf type for output\n");
+ dev_err(isp->dev, "unsupported v4l2 buf type for output\n");
return -EINVAL;
}
--
2.27.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: WARNING in binder_transaction_buffer_release (2)
syzbot suspects this issue was fixed by commit: commit 4b836a1426cb0f1ef2a6e211d7e553221594f8fc Author: Jann Horn Date: Mon Jul 27 12:04:24 2020 + binder: Prevent context manager from incrementing ref 0 bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=10c84dec90 start commit: 9cb1fd0e Linux 5.7-rc7 git tree: upstream kernel config: https://syzkaller.appspot.com/x/.config?x=cca7550d53ffa599 dashboard link: https://syzkaller.appspot.com/bug?extid=e113a0b970b7b3f394ba syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1230353c10 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17fd535e10 If the result looks correct, please mark the issue as fixed by replying with: #syz fix: binder: Prevent context manager from incrementing ref 0 For information about bisection process see: https://goo.gl/tpsmEJ#bisection ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: Add Mediatek High Frequency Manager Framework
On Thu, Aug 06, 2020 at 04:32:28PM +0800, hongxu.zhao wrote: > On Tue, 2020-08-04 at 10:11 +0200, Greg Kroah-Hartman wrote: > > On Tue, Aug 04, 2020 at 03:52:49PM +0800, hongxu.zhao wrote: > > > Add a new sensor framework into linux kernel which can support multi > > > client request sensor data. > > > There are the following features: > > > 1.Ringbuffer between manager and client; > > > 2.Kernel space user interface; > > > 3.User space user interface with syscall; > > > 4.Each client hang detect mechanism; > > > 5.Polling timer management in framework no need driver concern; > > > 6.Polling kthread work intergrated into a single kthread > > > worker to save system resources in framework no need driver concern; > > > 7.Proc file system to show manager device and client details; > > > 8.Compitable with android and widely used in many mediatek platform > > > products; > > > > > > Change-Id: I6361cdc2d51de50f66eede7df099c4575e7ec473 > > > > Did you not run checkpatch.pl on this? :) > > > > No need for change-id here. > > > > But, most importantly, why is this in drivers/staging? What keeps it > > from being in the "real" part of the kernel? I need a TODO file in the > > directory of the driver listing what remains to be done and who is > > responsible for doing this work and reviewing patches. > > > > Can you resend this with that file added and the Change-id removed? > > > > Also, why not just use the IIO interface, why are you creating > > yet-another api for sensors? We already have 2, making a third seems > > like something that guarantees this will never be mergable to the > > correct part of the kernel. > > > > And finally, /proc/ is not for devices, that is what sysfs is for, > > please use that. > > I have modified checkpatch issue, but blocked by ARCH=alpha build error > and I can't reproduce this build error in mediatek environment. I need > spend some time setting up an environment to solve this problem and will > send you the latest patch together after solving the problem of alpha > build error. If you can't easily fix the alpha issue, you can just mark the driver as not able to be built there for now. > Firstly I want keep it in the real part of kernel and I send mail to > community to find the right maintainer, unfortunately, several emails > were not answered. Pointers to those emails on lore.kernel.org? > Secondly I found iio upstream history it also started from staging at > the beginning, maybe staging is the best start until it become mature we > can move it to the real part of kernel. iio started in staging, but now that the infrastructure is out of it, there should not be any reason that new drivers be forced to go into staging too. You only want to do it this way if for some reason you can not get the work done on your own. > Actually, we have already assessed IIO subsystem, but the conclusion is > that it doesn't meet our requirement: > 1. iio doesn't have sensor manager in kernel space. What exactly do you mean by this? Who needs to be a "manager" here? > 2. each driver under the iio subsystem needs to create workqueue or > kthread by itself, waste system resources. workqueues are very light, how many sensors and what type of resources are you referring to here? And adding a whole new user api is not exactly "tiny" either :) > 3. iio doesn't have hang detect mechanism to detect polling thread hang. That's userspace's issue, right? > We need a sensor manager architecture in kernel space to select the best > delay and latency that multi-client(user space or kernel space user) > requested at the same time, and finally dispatch data to each client. Why does that have to be in the kernel? > We need lower resource comsumption, each driver can poll data by kthread > work which intergrated into a single kthread worker to save system > resources in framework. Again, how many resources are you really saving here with a whole new framework? > We need detect polling thread hang to decide whether to send data to > him. Data to where? > About proc, proc is only for High Frequency Manager Framework to show > manager details and client details, is not for device drivers. Then it is not needed :) > we recommend device driver(like test/test_app.c) use sysfs which under > High Frequency Manager Framework. Then you need to document it really well as to what you are doing here. But again, please try working with the IIO framework as that is what we have today. Any improvements you make to it will help everyone out. Adding a third way to handle sensor data to the kernel is probably not going to work well for anyone... thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH][next][V2] staging: wfx: fix a handful of spelling mistakes
From: Colin Ian King
There are various spelling mistakes in comments and error messages.
Fix these.
Signed-off-by: Colin Ian King
---
V2: add in some more fixes as spotted by Randy Dunlap
---
drivers/staging/wfx/data_rx.c | 2 +-
drivers/staging/wfx/data_tx.c | 2 +-
drivers/staging/wfx/debug.c | 6 +++---
drivers/staging/wfx/hif_rx.c | 2 +-
drivers/staging/wfx/hif_tx.c | 4 ++--
drivers/staging/wfx/main.c| 2 +-
drivers/staging/wfx/main.h| 2 +-
drivers/staging/wfx/sta.c | 2 +-
8 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/staging/wfx/data_rx.c b/drivers/staging/wfx/data_rx.c
index 6fb078880742..7fcbbfc53416 100644
--- a/drivers/staging/wfx/data_rx.c
+++ b/drivers/staging/wfx/data_rx.c
@@ -73,7 +73,7 @@ void wfx_rx_cb(struct wfx_vif *wvif,
if (arg->rx_flags.encryp)
hdr->flag |= RX_FLAG_DECRYPTED;
- // Block ack negociation is offloaded by the firmware. However,
+ // Block ack negotiation is offloaded by the firmware. However,
// re-ordering must be done by the mac80211.
if (ieee80211_is_action(frame->frame_control) &&
mgmt->u.action.category == WLAN_CATEGORY_BACK &&
diff --git a/drivers/staging/wfx/data_tx.c b/drivers/staging/wfx/data_tx.c
index 3acf4eb0214d..41f9afd41e14 100644
--- a/drivers/staging/wfx/data_tx.c
+++ b/drivers/staging/wfx/data_tx.c
@@ -234,7 +234,7 @@ static void wfx_tx_fixup_rates(struct ieee80211_tx_rate
*rates)
int i;
bool finished;
- // Firmware is not able to mix rates with differents flags
+ // Firmware is not able to mix rates with different flags
for (i = 0; i < IEEE80211_TX_MAX_RATES; i++) {
if (rates[0].flags & IEEE80211_TX_RC_SHORT_GI)
rates[i].flags |= IEEE80211_TX_RC_SHORT_GI;
diff --git a/drivers/staging/wfx/debug.c b/drivers/staging/wfx/debug.c
index 3f1712b7c919..99c53e1afece 100644
--- a/drivers/staging/wfx/debug.c
+++ b/drivers/staging/wfx/debug.c
@@ -267,7 +267,7 @@ static ssize_t wfx_send_hif_msg_write(struct file *file,
if (count < sizeof(struct hif_msg))
return -EINVAL;
- // wfx_cmd_send() chekc that reply buffer is wide enough, but do not
+ // wfx_cmd_send() checks that reply buffer is wide enough, but does not
// return precise length read. User have to know how many bytes should
// be read. Filling reply buffer with a memory pattern may help user.
memset(context->reply, 0xFF, sizeof(context->reply));
@@ -299,8 +299,8 @@ static ssize_t wfx_send_hif_msg_read(struct file *file,
char __user *user_buf,
return ret;
if (context->ret < 0)
return context->ret;
- // Be carefull, write() is waiting for a full message while read()
- // only return a payload
+ // Be careful, write() is waiting for a full message while read()
+ // only returns a payload
if (copy_to_user(user_buf, context->reply, count))
return -EFAULT;
diff --git a/drivers/staging/wfx/hif_rx.c b/drivers/staging/wfx/hif_rx.c
index cc7c0cf226ba..1d32973d8ec1 100644
--- a/drivers/staging/wfx/hif_rx.c
+++ b/drivers/staging/wfx/hif_rx.c
@@ -118,7 +118,7 @@ static int hif_keys_indication(struct wfx_dev *wdev,
// SL_PUB_KEY_EXCHANGE_STATUS_SUCCESS is used by legacy secure link
if (body->status && body->status != HIF_STATUS_SLK_NEGO_SUCCESS)
- dev_warn(wdev->dev, "secure link negociation error\n");
+ dev_warn(wdev->dev, "secure link negotiation error\n");
memcpy(pubkey, body->ncp_pub_key, sizeof(pubkey));
memreverse(pubkey, sizeof(pubkey));
wfx_sl_check_pubkey(wdev, pubkey, body->ncp_pub_key_mac);
diff --git a/drivers/staging/wfx/hif_tx.c b/drivers/staging/wfx/hif_tx.c
index 5110f9b93762..3b5f4dcc469c 100644
--- a/drivers/staging/wfx/hif_tx.c
+++ b/drivers/staging/wfx/hif_tx.c
@@ -78,7 +78,7 @@ int wfx_cmd_send(struct wfx_dev *wdev, struct hif_msg
*request,
wfx_bh_request_tx(wdev);
- // NOTE: no timeout is catched async is enabled
+ // NOTE: no timeout is caught async is enabled
if (async)
return 0;
@@ -125,7 +125,7 @@ int wfx_cmd_send(struct wfx_dev *wdev, struct hif_msg
*request,
// This function is special. After HIF_REQ_ID_SHUT_DOWN, chip won't reply to
any
// request anymore. We need to slightly hack struct wfx_hif_cmd for that job.
Be
-// carefull to only call this funcion during device unregister.
+// careful to only call this function during device unregister.
int hif_shutdown(struct wfx_dev *wdev)
{
int ret;
diff --git a/drivers/staging/wfx/main.c b/drivers/staging/wfx/main.c
index 11dfa088fc86..4263f912760b 100644
--- a/drivers/staging/wfx/main.c
+++ b/drivers/staging/wfx/main.c
@@ -384,7 +384,7 @@ int wfx_probe(struct wfx_dev *wdev)
err = wfx_sl_init(wdev);
if (err && wdev->hw_caps.capabilities.link_mode ==
Re: [PATCH] staging: Add Mediatek High Frequency Manager Framework
On Tue, 2020-08-04 at 10:11 +0200, Greg Kroah-Hartman wrote: > On Tue, Aug 04, 2020 at 03:52:49PM +0800, hongxu.zhao wrote: > > Add a new sensor framework into linux kernel which can support multi client > > request sensor data. > > There are the following features: > > 1.Ringbuffer between manager and client; > > 2.Kernel space user interface; > > 3.User space user interface with syscall; > > 4.Each client hang detect mechanism; > > 5.Polling timer management in framework no need driver concern; > > 6.Polling kthread work intergrated into a single kthread > > worker to save system resources in framework no need driver concern; > > 7.Proc file system to show manager device and client details; > > 8.Compitable with android and widely used in many mediatek platform > > products; > > > > Change-Id: I6361cdc2d51de50f66eede7df099c4575e7ec473 > > Did you not run checkpatch.pl on this? :) > > No need for change-id here. > > But, most importantly, why is this in drivers/staging? What keeps it > from being in the "real" part of the kernel? I need a TODO file in the > directory of the driver listing what remains to be done and who is > responsible for doing this work and reviewing patches. > > Can you resend this with that file added and the Change-id removed? > > Also, why not just use the IIO interface, why are you creating > yet-another api for sensors? We already have 2, making a third seems > like something that guarantees this will never be mergable to the > correct part of the kernel. > > And finally, /proc/ is not for devices, that is what sysfs is for, > please use that. I have modified checkpatch issue, but blocked by ARCH=alpha build error and I can't reproduce this build error in mediatek environment. I need spend some time setting up an environment to solve this problem and will send you the latest patch together after solving the problem of alpha build error. Firstly I want keep it in the real part of kernel and I send mail to community to find the right maintainer, unfortunately, several emails were not answered. Secondly I found iio upstream history it also started from staging at the beginning, maybe staging is the best start until it become mature we can move it to the real part of kernel. Actually, we have already assessed IIO subsystem, but the conclusion is that it doesn't meet our requirement: 1. iio doesn't have sensor manager in kernel space. 2. each driver under the iio subsystem needs to create workqueue or kthread by itself, waste system resources. 3. iio doesn't have hang detect mechanism to detect polling thread hang. We need a sensor manager architecture in kernel space to select the best delay and latency that multi-client(user space or kernel space user) requested at the same time, and finally dispatch data to each client. We need lower resource comsumption, each driver can poll data by kthread work which intergrated into a single kthread worker to save system resources in framework. We need detect polling thread hang to decide whether to send data to him. About proc, proc is only for High Frequency Manager Framework to show manager details and client details, is not for device drivers. we recommend device driver(like test/test_app.c) use sysfs which under High Frequency Manager Framework. Thanks. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
