Re: issue with uninitialized value used in a comparison in gbcodec_mixer_dapm_ctl_put
On Thu, Jul 30, 2020 at 05:02:22PM +0100, Colin Ian King wrote: > Hi, > > Static analysis with Coverity has detected an uninitialized value being > used in a comparison. The error was detected on a recent change to > drivers/staging/greybus/audio_topology.c however the issue actually > dates back to the original commit: Thanks Colin for reporting the issue. I'll fix the same and share a patch soon. -- Regards, Vaibhav ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v1] staging: fieldbus: Use %pM format specifier for MAC addresses
Hi Andy, thank you for the patch ! See below.
On Thu, Jul 30, 2020 at 11:27 AM Andy Shevchenko
wrote:
>
> -struct msg_mac_addr {
> - u8 addr[6];
> -};
I would prefer to keep this structure. It's conceptually important,
because it describes the binary layout of a message going to a
peripheral.
Perhaps you can still print using %pM by doing:
printf("%pM\n", response.addr) ?
> @@ -59,17 +55,13 @@ static int profi_id_get(struct fieldbus_dev *fbdev, char
> *buf,
> size_t max_size)
> {
> struct profi_priv *priv = container_of(fbdev, struct profi_priv,
> fbdev);
> - struct msg_mac_addr response;
> + u8 mac[ETH_ALEN];
> int ret;
>
> - ret = anybuss_recv_msg(priv->client, 0x0010, ,
> - sizeof(response));
> + ret = anybuss_recv_msg(priv->client, 0x0010, , sizeof(mac));
Should the address-of operator (&) be present in ?
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
BUSINESS PROPOSAL
Hello, Apply for a loan, at a 3% interest rate. Do you need a personal loan? Do you need a business loan? Do you need a consolidation loan? Do you need a secure loan? Do you need an unsecured loan? Do you need a mortgage loan? Do you need a pay off debt loan? Do you need a project loan? Do you need a student loan? Whatever loan that you are looking for, kindly send us a mail: (trustfinance1...@outlook.com) Mr. James kenneth Managing Director -- L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast. https://www.avast.com/antivirus ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/1] staging: android: ashmem: Fix lockdep warning for write operation
On Wed, Jul 29, 2020 at 8:24 PM Joel Fernandes wrote: > > On Wed, Jul 15, 2020 at 10:45 PM Suren Baghdasaryan wrote: > > > > syzbot report [1] describes a deadlock when write operation against an > > ashmem fd executed at the time when ashmem is shrinking its cache results > > in the following lock sequence: > > > > Possible unsafe locking scenario: > > > > CPU0CPU1 > > > >lock(fs_reclaim); > > lock(>s_type->i_mutex_key#13); > > lock(fs_reclaim); > >lock(>s_type->i_mutex_key#13); > > > > kswapd takes fs_reclaim and then inode_lock while generic_perform_write > > takes inode_lock and then fs_reclaim. However ashmem does not support > > writing into backing shmem with a write syscall. The only way to change > > its content is to mmap it and operate on mapped memory. Therefore the race > > that lockdep is warning about is not valid. Resolve this by introducing a > > separate lockdep class for the backing shmem inodes. > > > > [1]: https://lkml.kernel.org/lkml/0b5f9d059aa20...@google.com/ > > > > Signed-off-by: Suren Baghdasaryan > > --- > > Once Eric's nits are resolved: > > Reviewed-by: Joel Fernandes (Google) Thanks Joel! I'm fixing the nits and will report the patch shortly. One note about adding the "Fixes: " tag - this is a fix for a false positive lockdep warning and it's unclear which patch should be quoted here (I could not find a clear cause that started this warning). In similar situations, for example here: https://lkml.org/lkml/2020/6/15/958 developers seem to skip that tag. So I'll do the same. > > Thanks. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[staging:staging-testing] BUILD SUCCESS d8a0f85d394a0cc5dec2b290ebcf8ed3cfdc1a70
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git staging-testing branch HEAD: d8a0f85d394a0cc5dec2b290ebcf8ed3cfdc1a70 staging: qlge: qlge_dbg: removed comment repition elapsed time: 722m configs tested: 66 configs skipped: 1 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 ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig m68k allyesconfig nds32 defconfig nios2allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig arc defconfig sh allmodconfig parisc defconfig s390 allyesconfig parisc allyesconfig s390defconfig nios2 defconfig arc allyesconfig nds32 allnoconfig c6x allyesconfig i386 allyesconfig sparcallyesconfig sparc defconfig i386defconfig mips allyesconfig mips allmodconfig powerpc defconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig x86_64 randconfig-a001-20200730 x86_64 randconfig-a004-20200730 x86_64 randconfig-a002-20200730 x86_64 randconfig-a006-20200730 x86_64 randconfig-a003-20200730 x86_64 randconfig-a005-20200730 i386 randconfig-a005-20200730 i386 randconfig-a004-20200730 i386 randconfig-a006-20200730 i386 randconfig-a002-20200730 i386 randconfig-a001-20200730 i386 randconfig-a003-20200730 i386 randconfig-a016-20200730 i386 randconfig-a012-20200730 i386 randconfig-a014-20200730 i386 randconfig-a015-20200730 i386 randconfig-a011-20200730 i386 randconfig-a013-20200730 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.org ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] sched: Provide USF for the portable equipment.
On Thu, 30 Jul 2020 21:35:43 +0800
Dongdong Yang wrote:
I'll let others decide the value of this, but I have some comments.
>
> Signed-off-by: Dongdong Yang
> Signed-off-by: Jun Tao
> Signed-off-by: Qiwu Huang
> Signed-off-by: Geliang Tang
> Signed-off-by: Peng Wang
Why all the signed-off-bys? All of you worked on it?
> + if (evdata->data && val == FB_EVENT_BLANK) {
> + blank = *(int *)(evdata->data);
> +
> + switch (blank) {
> + case FB_BLANK_POWERDOWN:
> + usf_vdev.is_screen_on = 0;
> + if (usf_vdev.sysctl_sched_usf_non_ux != 0)
> + adjust_task_pred_demand =
> + _task_pred_demand_impl;
> + else
> + adjust_task_pred_demand = NULL;
So sysctl can enable and disable this?
> +
> + break;
> +
> diff --git a/kernel/sched/cpufreq_schedutil.c
> b/kernel/sched/cpufreq_schedutil.c
> index 7fbaee2..7bc3429 100644
> --- a/kernel/sched/cpufreq_schedutil.c
> +++ b/kernel/sched/cpufreq_schedutil.c
> @@ -289,12 +289,21 @@ unsigned long schedutil_cpu_util(int cpu, unsigned long
> util_cfs,
> return min(max, util);
> }
>
> +#ifdef CONFIG_SCHED_USF
> +void (*adjust_task_pred_demand)(int cpuid, unsigned long *util,
> + struct rq *rq) = NULL;
> +EXPORT_SYMBOL(adjust_task_pred_demand);
> +#endif
> +
> static unsigned long sugov_get_util(struct sugov_cpu *sg_cpu)
> {
> struct rq *rq = cpu_rq(sg_cpu->cpu);
> unsigned long util = cpu_util_cfs(rq);
> unsigned long max = arch_scale_cpu_capacity(sg_cpu->cpu);
> -
> +#ifdef CONFIG_SCHED_USF
> + if (adjust_task_pred_demand)
> + adjust_task_pred_demand(sg_cpu->cpu, , rq);
The above is racy. Nothing stops adjust_task_pred_demand from being
non-null at the if condition, then becoming NULL before it is called.
Instead I would have the following:
DEFINE_STATIC_KEY_FALSE(adjust_task_pred_set);
#ifdef CONFIG_SCHED_USF
void adjust_task_pred_demand(int cpuid, unsigned long *util,
struct rq *rq);
#else
static inline void adjust_task_pred_demand(int cpuid,
unsigned long *util, struct rq *rq)
{ }
#endif
if (static_key_unlikely(adjust_task_pred_set))
adjust_task_pred_demand(sg_cpu->cpu, , rq);
And hopefully the compiler will just remove all of it if it's not
enabled.
Then you set the static branch when you want it to be called, and do
not use a racy function pointer.
-- Steve
> +#endif
> sg_cpu->max = max;
> sg_cpu->bw_dl = cpu_bw_dl(rq);
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2] staging: atomisp: move null check to earlier point
`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);
/* v--Dereferenced here */
if (gs->v2p8_gpio >= 0) {
...
}
```
To avoid the issue, null check has been moved to an earlier point
and return semantics has been changed to reflect this exception.
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.
Caught-by: Coverity Static Analyzer CID 1465536
Signed-off-by: Cengiz Can
---
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
Re: [PATCH v9 08/12] device core: Introduce DMA range map, supplanting dma_pfn_offset
On Thu, Jul 30, 2020 at 1:05 PM Nicolas Saenz Julienne
wrote:
>
> Hi Jim,
>
> On Fri, 2020-07-24 at 16:33 -0400, Jim Quinlan wrote:
> > static void __init of_unittest_pci_dma_ranges(void)
> > diff --git a/drivers/pci/controller/pcie-brcmstb.c
> > b/drivers/pci/controller/pcie-brcmstb.c
> > index bfc2542d54a8..8dacb9d3b7b6 100644
> > --- a/drivers/pci/controller/pcie-brcmstb.c
> > +++ b/drivers/pci/controller/pcie-brcmstb.c
> > @@ -1197,6 +1197,7 @@ static int brcm_pcie_probe(struct platform_device
> > *pdev)
> > ret = brcm_phy_start(pcie);
> > if (ret) {
> > dev_err(pcie->dev, "failed to start phy\n");
> > + reset_control_assert(pcie->rescal);
> > return ret;
> > }
>
> I think this sneaked in from another patch.
Thanks Nicolas. BTW, at some point will you be able to test my
patchset on the RP4 to see if I broke anything?
Thanks again,
Jim
>
> Regards,
> Nicolas
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] PCI: Rename d3_delay in the pci_dev struct to align with PCI specification
Rename PCI-related variable "d3_delay" to "d3hot_delay" in the pci_dev
struct to better align with the PCI Firmware specification (see PCI
Firmware Specification, Revision 3.2, Section 4.6.9, p. 73).
The pci_dev struct already contains variable "d3cold_delay", thus
renaming "d3_delay" to "d3hot_delay" reduces ambiguity as PCI devices
support two variants of the D3 power state: D3hot and D3cold.
Also, rename other constants and variables, and updates code comments
and documentation to ensure alignment with the PCI specification.
There is no change to the functionality.
Signed-off-by: Krzysztof Wilczyński
---
Documentation/power/pci.rst | 2 +-
arch/x86/pci/fixup.c | 2 +-
arch/x86/pci/intel_mid_pci.c | 2 +-
drivers/hid/intel-ish-hid/ipc/ipc.c | 2 +-
drivers/net/ethernet/marvell/sky2.c | 2 +-
drivers/pci/pci-acpi.c| 6 +-
drivers/pci/pci.c | 14 ++--
drivers/pci/pci.h | 4 +-
drivers/pci/quirks.c | 68 +--
.../staging/media/atomisp/pci/atomisp_v4l2.c | 2 +-
include/linux/pci.h | 2 +-
include/uapi/linux/pci_regs.h | 2 +-
12 files changed, 54 insertions(+), 54 deletions(-)
diff --git a/Documentation/power/pci.rst b/Documentation/power/pci.rst
index 1831e431f725..b04fb18cc4e2 100644
--- a/Documentation/power/pci.rst
+++ b/Documentation/power/pci.rst
@@ -320,7 +320,7 @@ that these callbacks operate on::
unsigned intd2_support:1; /* Low power state D2 is supported */
unsigned intno_d1d2:1; /* D1 and D2 are forbidden */
unsigned intwakeup_prepared:1; /* Device prepared for wake up */
- unsigned intd3_delay; /* D3->D0 transition time in ms */
+ unsigned intd3hot_delay;/* D3hot->D0 transition time in ms */
...
};
diff --git a/arch/x86/pci/fixup.c b/arch/x86/pci/fixup.c
index 0c67a5a94de3..9e3d9cc6afc4 100644
--- a/arch/x86/pci/fixup.c
+++ b/arch/x86/pci/fixup.c
@@ -587,7 +587,7 @@ DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0xa26d,
pci_invalid_bar);
static void pci_fixup_amd_ehci_pme(struct pci_dev *dev)
{
dev_info(>dev, "PME# does not work under D3, disabling it\n");
- dev->pme_support &= ~((PCI_PM_CAP_PME_D3 | PCI_PM_CAP_PME_D3cold)
+ dev->pme_support &= ~((PCI_PM_CAP_PME_D3hot | PCI_PM_CAP_PME_D3cold)
>> PCI_PM_CAP_PME_SHIFT);
}
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_AMD, 0x7808, pci_fixup_amd_ehci_pme);
diff --git a/arch/x86/pci/intel_mid_pci.c b/arch/x86/pci/intel_mid_pci.c
index 00c62115f39c..979f310b67d4 100644
--- a/arch/x86/pci/intel_mid_pci.c
+++ b/arch/x86/pci/intel_mid_pci.c
@@ -322,7 +322,7 @@ static void pci_d3delay_fixup(struct pci_dev *dev)
*/
if (type1_access_ok(dev->bus->number, dev->devfn, PCI_DEVICE_ID))
return;
- dev->d3_delay = 0;
+ dev->d3hot_delay = 0;
}
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_ANY_ID, pci_d3delay_fixup);
diff --git a/drivers/hid/intel-ish-hid/ipc/ipc.c
b/drivers/hid/intel-ish-hid/ipc/ipc.c
index 8f8dfdf64833..a45ac7fa417b 100644
--- a/drivers/hid/intel-ish-hid/ipc/ipc.c
+++ b/drivers/hid/intel-ish-hid/ipc/ipc.c
@@ -755,7 +755,7 @@ static int _ish_hw_reset(struct ishtp_device *dev)
csr |= PCI_D3hot;
pci_write_config_word(pdev, pdev->pm_cap + PCI_PM_CTRL, csr);
- mdelay(pdev->d3_delay);
+ mdelay(pdev->d3hot_delay);
csr &= ~PCI_PM_CTRL_STATE_MASK;
csr |= PCI_D0;
diff --git a/drivers/net/ethernet/marvell/sky2.c
b/drivers/net/ethernet/marvell/sky2.c
index fe54764caea9..ce7a94060a96 100644
--- a/drivers/net/ethernet/marvell/sky2.c
+++ b/drivers/net/ethernet/marvell/sky2.c
@@ -5104,7 +5104,7 @@ static int sky2_probe(struct pci_dev *pdev, const struct
pci_device_id *ent)
INIT_WORK(>restart_work, sky2_restart);
pci_set_drvdata(pdev, hw);
- pdev->d3_delay = 300;
+ pdev->d3hot_delay = 300;
return 0;
diff --git a/drivers/pci/pci-acpi.c b/drivers/pci/pci-acpi.c
index 7224b1e5f2a8..c54588ad2d9c 100644
--- a/drivers/pci/pci-acpi.c
+++ b/drivers/pci/pci-acpi.c
@@ -1167,7 +1167,7 @@ static struct acpi_device *acpi_pci_find_companion(struct
device *dev)
* @pdev: the PCI device whose delay is to be updated
* @handle: ACPI handle of this device
*
- * Update the d3_delay and d3cold_delay of a PCI device from the ACPI _DSM
+ * Update the d3hot_delay and d3cold_delay of a PCI device from the ACPI _DSM
* control method of either the device itself or the PCI host bridge.
*
* Function 8, "Reset Delay," applies to the entire hierarchy below a PCI
@@ -1206,8 +1206,8 @@ static void pci_acpi_optimize_delay(struct pci_dev *pdev,
}
if (elements[3].type == ACPI_TYPE_INTEGER) {
value =
Re: [PATCH v9 08/12] device core: Introduce DMA range map, supplanting dma_pfn_offset
On Wed, Jul 29, 2020 at 10:28 AM Rob Herring wrote: > > On Wed, Jul 29, 2020 at 12:19 AM Christoph Hellwig wrote: > > > > On Tue, Jul 28, 2020 at 02:24:51PM -0400, Jim Quinlan wrote: > > > I started using devm_kcalloc() but at least two reviewers convinced me > > > to just use kcalloc(). In addition, when I was using devm_kcalloc() > > > it was awkward because 'dev' is not available to this function. > > > > > > It comes down to whether unbind/binding the device N times is actually > > > a reasonable usage. As for my experience I've seen two cases: (1) my > > > overnight "bind/unbind the PCIe RC driver" script, and we have a > > > customer who does an unbind/bind as a hail mary to bring back life to > > > their dead EP device. If the latter case happens repeatedly, there > > > are bigger problems. > > > > We can't just leak the allocations. Do you have a pointer to the > > arguments against managed resources? I'm generally not a huge fan > > of the managed resources, but for a case like this they actually seem > > useful. If we don't use the managed resources we'll at leat need > > to explicitly free the resources when freeing the device. > > The lifetime for devm_kcalloc may not be what we want here. devm > allocs are freed on probe fail or remove, not on freeing the device > (there is a just in case free there too though). What do you suggest doing as an alternative? Jim > > > Rob ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 0/3] Modernize tasklet callback API
[heavily trimmed CC list because I think lkml is ignoring this thread...] On Thu, Jul 30, 2020 at 09:03:55AM +0200, Thomas Gleixner wrote: > Kees, > > Kees Cook writes: > > This is the infrastructure changes to prepare the tasklet API for > > conversion to passing the tasklet struct as the callback argument instead > > of an arbitrary unsigned long. The first patch details why this is useful > > (it's the same rationale as the timer_struct changes from a bit ago: > > less abuse during memory corruption attacks, more in line with existing > > ways of doing things in the kernel, save a little space in struct, > > etc). Notably, the existing tasklet API use is much less messy, so there > > is less to clean up. > > > > It's not clear to me which tree this should go through... Greg since it > > starts with a USB clean-up, -tip for timer or interrupt, or if I should > > just carry it. I'm open to suggestions, but if I don't hear otherwise, > > I'll just carry it. > > > > My goal is to have this merged for v5.9-rc1 so that during the v5.10 > > development cycle the new API will be available. The entire tree of > > changes is here[1] currently, but to split it up by maintainer the > > infrastructure changes need to be landed first. > > > > Review and Acks appreciated! :) > > I'd rather see tasklets vanish from the planet completely, but that's > going to be a daring feat. So, grudgingly: Understood! I will update the comments near the tasklet API. > Acked-by: Thomas Gleixner Thanks! -- Kees Cook ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
MY LOVE,
MY LOVE, My name is Lina Williams There is my email ( linawilliams...@yahoo.com ) I pick interest on you. I will like to establish with you. I will introduce myself better and send you my picture as soon as I receive your reply. I am looking to read from you as soon as possible. Thanks.lL LINA WILLIAMS ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v1] staging: fieldbus: Use %pM format specifier for MAC addresses
Hi Andy,
I love your patch! Yet something to improve:
[auto build test ERROR on staging/staging-testing]
url:
https://github.com/0day-ci/linux/commits/Andy-Shevchenko/staging-fieldbus-Use-pM-format-specifier-for-MAC-addresses/20200730-232835
base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
d8a0f85d394a0cc5dec2b290ebcf8ed3cfdc1a70
config: sh-allmodconfig (attached as .config)
compiler: sh4-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=sh
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All error/warnings (new ones prefixed by >>):
drivers/staging/fieldbus/anybuss/hms-profinet.c: In function 'profi_id_get':
>> drivers/staging/fieldbus/anybuss/hms-profinet.c:58:9: error: 'ETH_ALEN'
>> undeclared (first use in this function)
58 | u8 mac[ETH_ALEN];
| ^~~~
drivers/staging/fieldbus/anybuss/hms-profinet.c:58:9: note: each undeclared
identifier is reported only once for each function it appears in
drivers/staging/fieldbus/anybuss/hms-profinet.c:58:5: warning: unused
variable 'mac' [-Wunused-variable]
58 | u8 mac[ETH_ALEN];
| ^~~
>> drivers/staging/fieldbus/anybuss/hms-profinet.c:65:1: warning: control
>> reaches end of non-void function [-Wreturn-type]
65 | }
| ^
vim +/ETH_ALEN +58 drivers/staging/fieldbus/anybuss/hms-profinet.c
53
54 static int profi_id_get(struct fieldbus_dev *fbdev, char *buf,
55 size_t max_size)
56 {
57 struct profi_priv *priv = container_of(fbdev, struct
profi_priv, fbdev);
> 58 u8 mac[ETH_ALEN];
59 int ret;
60
61 ret = anybuss_recv_msg(priv->client, 0x0010, , sizeof(mac));
62 if (ret < 0)
63 return ret;
64 return snprintf(buf, max_size, "%pM\n", mac);
> 65 }
66
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v9 08/12] device core: Introduce DMA range map, supplanting dma_pfn_offset
On Thu, 2020-07-30 at 13:25 -0400, Jim Quinlan wrote:
> On Thu, Jul 30, 2020 at 1:05 PM Nicolas Saenz Julienne
> wrote:
> > Hi Jim,
> >
> > On Fri, 2020-07-24 at 16:33 -0400, Jim Quinlan wrote:
> > > static void __init of_unittest_pci_dma_ranges(void)
> > > diff --git a/drivers/pci/controller/pcie-brcmstb.c
> > > b/drivers/pci/controller/pcie-brcmstb.c
> > > index bfc2542d54a8..8dacb9d3b7b6 100644
> > > --- a/drivers/pci/controller/pcie-brcmstb.c
> > > +++ b/drivers/pci/controller/pcie-brcmstb.c
> > > @@ -1197,6 +1197,7 @@ static int brcm_pcie_probe(struct platform_device
> > > *pdev)
> > > ret = brcm_phy_start(pcie);
> > > if (ret) {
> > > dev_err(pcie->dev, "failed to start phy\n");
> > > + reset_control_assert(pcie->rescal);
> > > return ret;
> > > }
> >
> > I think this sneaked in from another patch.
> Thanks Nicolas. BTW, at some point will you be able to test my
> patchset on the RP4 to see if I broke anything?
Yes of course, I'll have a go at it tomorrow.
Regards,
Nicolas
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v9 08/12] device core: Introduce DMA range map, supplanting dma_pfn_offset
Hi Jim,
On Fri, 2020-07-24 at 16:33 -0400, Jim Quinlan wrote:
> static void __init of_unittest_pci_dma_ranges(void)
> diff --git a/drivers/pci/controller/pcie-brcmstb.c
> b/drivers/pci/controller/pcie-brcmstb.c
> index bfc2542d54a8..8dacb9d3b7b6 100644
> --- a/drivers/pci/controller/pcie-brcmstb.c
> +++ b/drivers/pci/controller/pcie-brcmstb.c
> @@ -1197,6 +1197,7 @@ static int brcm_pcie_probe(struct platform_device *pdev)
> ret = brcm_phy_start(pcie);
> if (ret) {
> dev_err(pcie->dev, "failed to start phy\n");
> + reset_control_assert(pcie->rescal);
> return ret;
> }
I think this sneaked in from another patch.
Regards,
Nicolas
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v9 08/12] device core: Introduce DMA range map, supplanting dma_pfn_offset
On Thu, 2020-07-30 at 12:44 -0400, Jim Quinlan wrote: > On Wed, Jul 29, 2020 at 10:28 AM Rob Herring wrote: > > On Wed, Jul 29, 2020 at 12:19 AM Christoph Hellwig wrote: > > > On Tue, Jul 28, 2020 at 02:24:51PM -0400, Jim Quinlan wrote: > > > > I started using devm_kcalloc() but at least two reviewers convinced me > > > > to just use kcalloc(). In addition, when I was using devm_kcalloc() > > > > it was awkward because 'dev' is not available to this function. > > > > > > > > It comes down to whether unbind/binding the device N times is actually > > > > a reasonable usage. As for my experience I've seen two cases: (1) my > > > > overnight "bind/unbind the PCIe RC driver" script, and we have a > > > > customer who does an unbind/bind as a hail mary to bring back life to > > > > their dead EP device. If the latter case happens repeatedly, there > > > > are bigger problems. > > > > > > We can't just leak the allocations. Do you have a pointer to the > > > arguments against managed resources? I'm generally not a huge fan > > > of the managed resources, but for a case like this they actually seem > > > useful. If we don't use the managed resources we'll at leat need > > > to explicitly free the resources when freeing the device. > > > > The lifetime for devm_kcalloc may not be what we want here. devm > > allocs are freed on probe fail or remove, not on freeing the device > > (there is a just in case free there too though). > > What do you suggest doing as an alternative? I haven't given the idea much thought, but how about using a kref in the first element of your bus_dma_region array. It should be increased upon assigning it to a device and decreased it upon destroying it (triggering the free once it hits 0). It would take care of this memory leak, but also useful where you're sharing bus_dma_regions between devices. Regards, Nicolas ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v6] drivers: most: add USB adapter driver
This patch adds the USB driver source file most_usb.c and modifies the Makefile and Kconfig accordingly. Signed-off-by: Christian Gromm --- v2: Reported-by: Greg Kroah-Hartman - don't remove usb driver from staging area - don't touch staging/most/Kconfig - remove subdirectory for USB driver and put source file into drivers/most v3: - submitted fixes found during code audit to staging version first to be able to resend single patch that adds the driver v4: Reported-by: Dan Carpenter submitted patch set that fixes issues found during code audit to staging version first to be able to resend single patch that adds the driver. The patch series included: - use function sysfs_streq - add missing put_device calls - use correct error codes - replace code to calculate array index - don't use error path to exit function on success - move allocation of URB out of critical section - return 0 instead of variable - change return value of function drci_rd_reg - don't use expressions that might fail in a declaration - change order of function parameters v5: Reported-by: Dan Carpenter submitted patch set that fixes issues found during code audit to staging version first to be able to resend single patch that adds the driver. The patch series included: - init return value in default path of switch/case expression v6: Reported-by: Randy Dunlap remove dependency to NET in Kconfig file drivers/most/Kconfig | 11 + drivers/most/Makefile |2 + drivers/most/most_usb.c | 1170 + drivers/staging/most/Kconfig |2 - drivers/staging/most/usb/Kconfig | 13 - drivers/staging/most/usb/Makefile |4 - drivers/staging/most/usb/usb.c| 1170 - 7 files changed, 1183 insertions(+), 1189 deletions(-) create mode 100644 drivers/most/most_usb.c delete mode 100644 drivers/staging/most/usb/Kconfig delete mode 100644 drivers/staging/most/usb/Makefile delete mode 100644 drivers/staging/most/usb/usb.c diff --git a/drivers/most/Kconfig b/drivers/most/Kconfig index 58d7999..60fc082 100644 --- a/drivers/most/Kconfig +++ b/drivers/most/Kconfig @@ -13,3 +13,14 @@ menuconfig MOST module will be called most_core. If in doubt, say N here. + +if MOST +config MOST_USB_HDM + tristate "USB" + depends on USB + help + Say Y here if you want to connect via USB to network transceiver. + + To compile this driver as a module, choose M here: the + module will be called most_usb. +endif diff --git a/drivers/most/Makefile b/drivers/most/Makefile index e810cd3..6a3cb90 100644 --- a/drivers/most/Makefile +++ b/drivers/most/Makefile @@ -2,3 +2,5 @@ obj-$(CONFIG_MOST) += most_core.o most_core-y := core.o \ configfs.o + +obj-$(CONFIG_MOST_USB_HDM) += most_usb.o diff --git a/drivers/most/most_usb.c b/drivers/most/most_usb.c new file mode 100644 index 000..2640c5b --- /dev/null +++ b/drivers/most/most_usb.c @@ -0,0 +1,1170 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * usb.c - Hardware dependent module for USB + * + * Copyright (C) 2013-2015 Microchip Technology Germany II GmbH & Co. KG + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define USB_MTU512 +#define NO_ISOCHRONOUS_URB 0 +#define AV_PACKETS_PER_XACT2 +#define BUF_CHAIN_SIZE 0x +#define MAX_NUM_ENDPOINTS 30 +#define MAX_SUFFIX_LEN 10 +#define MAX_STRING_LEN 80 +#define MAX_BUF_SIZE 0x + +#define USB_VENDOR_ID_SMSC 0x0424 /* VID: SMSC */ +#define USB_DEV_ID_BRDG0xC001 /* PID: USB Bridge */ +#define USB_DEV_ID_OS81118 0xCF18 /* PID: USB OS81118 */ +#define USB_DEV_ID_OS81119 0xCF19 /* PID: USB OS81119 */ +#define USB_DEV_ID_OS81210 0xCF30 /* PID: USB OS81210 */ +/* DRCI Addresses */ +#define DRCI_REG_NI_STATE 0x0100 +#define DRCI_REG_PACKET_BW 0x0101 +#define DRCI_REG_NODE_ADDR 0x0102 +#define DRCI_REG_NODE_POS 0x0103 +#define DRCI_REG_MEP_FILTER0x0140 +#define DRCI_REG_HASH_TBL0 0x0141 +#define DRCI_REG_HASH_TBL1 0x0142 +#define DRCI_REG_HASH_TBL2 0x0143 +#define DRCI_REG_HASH_TBL3 0x0144 +#define DRCI_REG_HW_ADDR_HI0x0145 +#define DRCI_REG_HW_ADDR_MI0x0146 +#define DRCI_REG_HW_ADDR_LO0x0147 +#define DRCI_REG_BASE 0x1100 +#define DRCI_COMMAND 0x02 +#define DRCI_READ_REQ 0xA0 +#define DRCI_WRITE_REQ 0xA1 + +/** + * struct most_dci_obj - Direct Communication Interface + * @kobj:position in sysfs + * @usb_device: pointer to the usb device +
issue with uninitialized value used in a comparison in gbcodec_mixer_dapm_ctl_put
Hi,
Static analysis with Coverity has detected an uninitialized value being
used in a comparison. The error was detected on a recent change to
drivers/staging/greybus/audio_topology.c however the issue actually
dates back to the original commit:
commit 6339d2322c47f4b8ebabf9daf0130328ed72648b
Author: Vaibhav Agarwal
Date: Wed Jan 13 14:07:51 2016 -0700
greybus: audio: Add topology parser for GB codec
The analysis is as follows:
425 static int gbcodec_mixer_dapm_ctl_put(struct snd_kcontrol *kcontrol,
426 struct snd_ctl_elem_value
*ucontrol)
427 {
428int ret, wi, max, connect;
429unsigned int mask, val;
430struct gb_audio_ctl_elem_info *info;
431struct gbaudio_ctl_pvt *data;
1. var_decl: Declaring variable gbvalue without initializer.
432struct gb_audio_ctl_elem_value gbvalue;
433struct gbaudio_module_info *module;
434struct snd_soc_dapm_widget_list *wlist =
snd_kcontrol_chip(kcontrol);
435struct snd_soc_dapm_widget *widget = wlist->widgets[0];
436struct device *codec_dev = widget->dapm->dev;
437struct gbaudio_codec_info *gb = dev_get_drvdata(codec_dev);
438struct gb_bundle *bundle;
439
2. Condition 0 /* __builtin_types_compatible_p() */, taking false branch.
3. Condition 1 /* __builtin_types_compatible_p() */, taking true branch.
4. Falling through to end of if statement.
5. Condition !!branch, taking false branch.
6. Condition ({...; !!branch;}), taking false branch.
440dev_dbg(codec_dev, "Entered %s:%s\n", __func__,
kcontrol->id.name);
441module = find_gb_module(gb, kcontrol->id.name);
7. Condition !module, taking false branch.
442if (!module)
443return -EINVAL;
444
445data = (struct gbaudio_ctl_pvt *)kcontrol->private_value;
446info = (struct gb_audio_ctl_elem_info *)data->info;
8. Condition 0 /* !!(!__builtin_types_compatible_p() &&
!__builtin_types_compatible_p()) */, taking false branch.
447bundle = to_gb_bundle(module->dev);
448
9. Condition data->vcount == 2, taking true branch.
449if (data->vcount == 2)
450dev_warn(widget->dapm->dev,
451 "GB: Control '%s' is stereo, which is not
supported\n",
452 kcontrol->id.name);
453
454max = le32_to_cpu(info->value.integer.max);
455mask = (1 << fls(max)) - 1;
456val = ucontrol->value.integer.value[0] & mask;
10. Condition !!val, taking true branch.
457connect = !!val;
458
459/* update ucontrol */
Uninitialized scalar variable (UNINIT)
11. uninit_use: Using uninitialized value gbvalue.value.integer_value[0].
460if (gbvalue.value.integer_value[0] != val) {
The gbvalue.value.integer_value[0] read is bogus since gbvalue was
declared on the stack but was not initialized. There seems to be no
where that sets this data. I'm assuming most of the time that the
comparison works because the garbage value is different from val and so
the code in the if stanza is executed.
Anyhow, I'm unsure what the original intent of the code was, so I've not
attempted to fix this.
Colin
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v1] staging: fieldbus: Use %pM format specifier for MAC addresses
Convert to %pM instead of using custom code.
While here, replace one time use structure by buffer on stack.
Signed-off-by: Andy Shevchenko
---
drivers/staging/fieldbus/anybuss/hms-profinet.c | 14 +++---
1 file changed, 3 insertions(+), 11 deletions(-)
diff --git a/drivers/staging/fieldbus/anybuss/hms-profinet.c
b/drivers/staging/fieldbus/anybuss/hms-profinet.c
index 31c43a0a5776..505480fb281d 100644
--- a/drivers/staging/fieldbus/anybuss/hms-profinet.c
+++ b/drivers/staging/fieldbus/anybuss/hms-profinet.c
@@ -26,10 +26,6 @@
* exactly as advertised.
*/
-struct msg_mac_addr {
- u8 addr[6];
-};
-
struct profi_priv {
struct fieldbus_dev fbdev;
struct anybuss_client *client;
@@ -59,17 +55,13 @@ static int profi_id_get(struct fieldbus_dev *fbdev, char
*buf,
size_t max_size)
{
struct profi_priv *priv = container_of(fbdev, struct profi_priv, fbdev);
- struct msg_mac_addr response;
+ u8 mac[ETH_ALEN];
int ret;
- ret = anybuss_recv_msg(priv->client, 0x0010, ,
- sizeof(response));
+ ret = anybuss_recv_msg(priv->client, 0x0010, , sizeof(mac));
if (ret < 0)
return ret;
- return snprintf(buf, max_size, "%02X:%02X:%02X:%02X:%02X:%02X\n",
- response.addr[0], response.addr[1],
- response.addr[2], response.addr[3],
- response.addr[4], response.addr[5]);
+ return snprintf(buf, max_size, "%pM\n", mac);
}
static bool profi_enable_get(struct fieldbus_dev *fbdev)
--
2.27.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v1] staging: ks7010: Use %pM format specifier for MAC addresses
Convert to %pM instead of using custom code.
Signed-off-by: Andy Shevchenko
---
drivers/staging/ks7010/ks_hostif.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/ks7010/ks_hostif.c
b/drivers/staging/ks7010/ks_hostif.c
index d70b671b06aa..eaaf6a5440a9 100644
--- a/drivers/staging/ks7010/ks_hostif.c
+++ b/drivers/staging/ks7010/ks_hostif.c
@@ -161,7 +161,7 @@ int get_current_ap(struct ks_wlan_private *priv, struct
link_ap_info *ap_info)
wireless_send_event(netdev, SIOCGIWAP, , NULL);
}
netdev_dbg(priv->net_dev, "Link AP\n"
- "- bssid=%02X:%02X:%02X:%02X:%02X:%02X\n"
+ "- bssid=%pM\n"
"- essid=%s\n"
"- rate_set=%02X,%02X,%02X,%02X,%02X,%02X,%02X,%02X\n"
"- channel=%d\n"
@@ -172,8 +172,7 @@ int get_current_ap(struct ks_wlan_private *priv, struct
link_ap_info *ap_info)
"- rsn.size=%d\n"
"- ext_rate_set_size=%d\n"
"- rate_set_size=%d\n",
- ap->bssid[0], ap->bssid[1], ap->bssid[2],
- ap->bssid[3], ap->bssid[4], ap->bssid[5],
+ ap->bssid,
>ssid.body[0],
ap->rate_set.body[0], ap->rate_set.body[1],
ap->rate_set.body[2], ap->rate_set.body[3],
@@ -439,11 +438,7 @@ void hostif_data_indication(struct ks_wlan_private *priv)
/* source address check */
if (ether_addr_equal(>eth_addr[0], eth_hdr->h_source)) {
netdev_err(priv->net_dev, "invalid : source is own mac address
!!\n");
- netdev_err(priv->net_dev,
-
"eth_hdrernet->h_dest=%02X:%02X:%02X:%02X:%02X:%02X\n",
- eth_hdr->h_source[0], eth_hdr->h_source[1],
- eth_hdr->h_source[2], eth_hdr->h_source[3],
- eth_hdr->h_source[4], eth_hdr->h_source[5]);
+ netdev_err(priv->net_dev, "eth_hdrernet->h_dest=%pM\n",
eth_hdr->h_source);
priv->nstats.rx_errors++;
return;
}
--
2.27.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v1] staging: most: Use %pM format specifier for MAC addresses
Convert to %pM instead of using custom code.
Signed-off-by: Andy Shevchenko
---
drivers/staging/most/net/net.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/most/net/net.c b/drivers/staging/most/net/net.c
index 830f089f1a88..b6fecb06a0e6 100644
--- a/drivers/staging/most/net/net.c
+++ b/drivers/staging/most/net/net.c
@@ -564,13 +564,11 @@ static void on_netinfo(struct most_interface *iface,
if (m && is_valid_ether_addr(m)) {
if (!is_valid_ether_addr(dev->dev_addr)) {
- netdev_info(dev, "set mac
%02x-%02x-%02x-%02x-%02x-%02x\n",
- m[0], m[1], m[2], m[3], m[4], m[5]);
+ netdev_info(dev, "set mac %pM\n", m);
ether_addr_copy(dev->dev_addr, m);
netif_dormant_off(dev);
} else if (!ether_addr_equal(dev->dev_addr, m)) {
- netdev_warn(dev, "reject mac
%02x-%02x-%02x-%02x-%02x-%02x\n",
- m[0], m[1], m[2], m[3], m[4], m[5]);
+ netdev_warn(dev, "reject mac %pM\n", m);
}
}
--
2.27.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] sched: Provide USF for the portable equipment.
From: Dongdong Yang The power consumption and UI response are more cared for by the portable equipment users. USF(User Sensitive Feedback factor) auxiliary cpufreq governor is providing more utils adjustment settings to a high level by scenario identification. From the view of portable equipment, screen off status usually stands for no request from the user, however, the kernel is still expected to notify the user in time on modem, network or powerkey events occur. In some scenarios, such as listening to music, low power processors, such as DSP, take more actions and CPU load requirements cut down. It would bring more power consumption benefit if high level have interfaces to adjust utils according to the current scenario and load. In addition, the portable equipment user usually heavy interact with devices by touch, and other peripherals. The boost preemptive counts are marking the load requirement urgent, vice versa. If such feedback factor could be set to high level according to the scenario, it would contribute to the power consumption and UI response. If no USF sysfs inode is set, and no screen on or off event, adjust_task_pred_demand shall not be invoked. Once sched_usf_up_l0_r/down_r/non_ux_r be set, adjust_task_pred_demand_impl shall be called back to update settings according to high level scenario identification. We can get about 17% mean power consumption save at listening to music with speaker on "screen off" scenario, as below statistical data from 7766 XiaoMi devices for two weeks with sched_usf_non_ux_r be set: day1 day2 day3 day4 count 7766.00 7766.00 7766.00 7766.00 mean88.03552585.50028283.82930586.054997 std 111.049980 108.258834 107.562583 108.558240 min 0.099000 0.037000 0.067000 0.045000 25% 34.76550034.02175034.10150034.423000 50% 54.9555.28650054.18950054.248500 75% 95.95400093.94200091.73800094.0592500 80% 114.675000 107.43 106.378000 108.673000 85% 137.851000 129.511000 127.156500 131.750750 90% 179.669000 170.208500 164.027000 172.348000 95% 272.395000 257.845500 247.750500 263.275750 98% 399.034500 412.170400 391.484000 402.835600 day5 day6day7 day8 count 7766.00 7766.0 7766.00 7766.00 mean82.53267779.2192377.61138081.075081 std 104.870079 101.34819 103.140037 97.506221 min 0.051000 0.02900 0.007000 0.068000 25% 32.87300033.4440031.96550033.863500 50% 52.18050051.5655050.80650053.08 75% 90.90575086.8262583.85925089.973000 80% 105.455000 99.6470097.271000104.225000 85% 128.30 118.47825 116.570250 126.648250 90% 166.647500 149.18000 150.649500 161.087000 95% 247.208500 224.36050 226.38 245.291250 98% 393.002000 347.92060 369.791800 378.778600 day9 day10day11day12 count 7766.00 7766.00 7766.00 7766.00 mean79.98917083.85941778.03293077.060542 std 104.226122 108.893043 102.561715 99.844276 min 0.118000 0.017000 0.028000 0.039000 25% 32.05625033.45450031.17625030.897750 50% 51.50600054.05600048.96950049.069000 75% 88.51350092.95350083.50675084.096000 80% 102.876000 107.845000 97.71700098.073000 85% 124.363000 128.288000 118.366500 116.869250 90% 160.557000 167.084000 154.342500 148.187500 95% 231.149000 242.925750 236.759000 228.131250 98% 367.206600 388.619100 385.269100 376.541600 day13day14 count 7766.00 7766.00 mean75.52803673.702878 std 90.75059486.796016 min 0.066000 0.054000 25% 31.17050031.608500 50% 48.75850049.215000 75% 84.52275083.053000 80% 97.87900094.875000 85% 116.680250 113.573750 90% 149.083500 144.089500 95% 226.177750 211.488750 98% 347.011100 331.317100 Signed-off-by: Dongdong Yang Signed-off-by: Jun Tao Signed-off-by: Qiwu Huang Signed-off-by: Geliang Tang Signed-off-by: Peng Wang --- drivers/staging/Kconfig | 2 + drivers/staging/Makefile | 1 + drivers/staging/fbsched/Kconfig | 10 ++ drivers/staging/fbsched/Makefile | 2 + drivers/staging/fbsched/usf.c| 351 +++ kernel/sched/cpufreq_schedutil.c | 11 +- 6 files changed, 376 insertions(+), 1 deletion(-) create mode 100644 drivers/staging/fbsched/Kconfig create mode 100644 drivers/staging/fbsched/Makefile create mode 100644 drivers/staging/fbsched/usf.c diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig index 4ec5528..05b231e 100644 --- a/drivers/staging/Kconfig +++ b/drivers/staging/Kconfig @@ -120,4 +120,6 @@
[PATCH] sched: Provide USF for the portable equipment.
From: Dongdong Yang This patch provides USF(User Sensitive Feedback factor) auxiliary cpufreq governor to support high level layer sysfs inodes setting for utils adjustment purpose from the identified scenario on portable equipment. Because the power consumption and UI response are more cared for by portable equipment users. And the "screen off" status stands for no request from the user, however, the kernel is still expected to notify the user in time on modem, network or powerkey events occur. USF provides "sched_usf_non_ux_r" sysfs inode to cut down the utils from user space tasks according to high level scenario. In addition, it usually hints more cpufreq demand that the preemptive counts of the tasks on the cpu burst and over the user expecting completed time such as the ratio sysctl_sched_latency to sysctl_sched_min_granularity on "screen on" status, which more likely with more UI. The sysfs inodes "sched_usf_up_l0_r" and "sched_usf_down_r" have been provided to adjust the utils according to high level identified scenario to alloc the cpufreq in time. Dongdong Yang (1): sched: Provide USF for portable equipment. drivers/staging/Kconfig | 2 + drivers/staging/Makefile | 1 + drivers/staging/fbsched/Kconfig | 10 ++ drivers/staging/fbsched/Makefile | 2 + drivers/staging/fbsched/usf.c| 351 +++ kernel/sched/cpufreq_schedutil.c | 11 +- 6 files changed, 376 insertions(+), 1 deletion(-) create mode 100644 drivers/staging/fbsched/Kconfig create mode 100644 drivers/staging/fbsched/Makefile create mode 100644 drivers/staging/fbsched/usf.c -- 2.7.4 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] binder: Prevent context manager from incrementing ref 0
Hi
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag
fixing commit: 457b9a6f09f0 ("Staging: android: add binder driver").
The bot has tested the following trees: v5.7.11, v5.4.54, v4.19.135, v4.14.190,
v4.9.231, v4.4.231.
v5.7.11: Build OK!
v5.4.54: Build OK!
v4.19.135: Build OK!
v4.14.190: Build OK!
v4.9.231: Failed to apply! Possible dependencies:
14db31814a9a ("binder: Deal with contexts in debugfs")
19c987241ca1 ("binder: separate out binder_alloc functions")
1b77e9dcc3da ("ANDROID: binder: remove proc waitqueue")
342e5c90b601 ("binder: Support multiple context managers")
408c68b17aea ("ANDROID: binder: push new transactions to waiting threads.")
4bfac80af3a6 ("binder: Add extra size to allocator")
512cf465ee01 ("binder: fix use-after-free in binder_transaction()")
7980240b6d63 ("binder: Add support for scatter-gather")
9630fe8839ba ("binder: introduce locking helper functions")
a056af42032e ("binder: Refactor binder_transact()")
ac4812c5ffbb ("binder: Support multiple /dev instances")
def95c73567d ("binder: Add support for file-descriptor arrays")
fdfb4a99b6ab ("binder: separate binder allocator structure from binder
proc")
feba3900cabb ("binder: Split flat_binder_object")
v4.4.231: Failed to apply! Possible dependencies:
14db31814a9a ("binder: Deal with contexts in debugfs")
19c987241ca1 ("binder: separate out binder_alloc functions")
1b77e9dcc3da ("ANDROID: binder: remove proc waitqueue")
212265e5ad72 ("android: binder: More offset validation")
342e5c90b601 ("binder: Support multiple context managers")
408c68b17aea ("ANDROID: binder: push new transactions to waiting threads.")
4bfac80af3a6 ("binder: Add extra size to allocator")
512cf465ee01 ("binder: fix use-after-free in binder_transaction()")
7980240b6d63 ("binder: Add support for scatter-gather")
83050a4e2197 ("android: drivers: Avoid debugfs race in binder")
9630fe8839ba ("binder: introduce locking helper functions")
a056af42032e ("binder: Refactor binder_transact()")
a906d6931f3c ("android: binder: Sanity check at binder ioctl")
ac4812c5ffbb ("binder: Support multiple /dev instances")
def95c73567d ("binder: Add support for file-descriptor arrays")
feba3900cabb ("binder: Split flat_binder_object")
NOTE: The patch will not be queued to stable trees until it is upstream.
How should we proceed with this patch?
--
Thanks
Sasha
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: most: usb: rename most_usb.ko
On Wed, 2020-07-29 at 19:03 +0200, Greg KH wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you
> know the content is safe
>
> On Wed, Jul 29, 2020 at 06:38:48PM +0200, Christian Gromm wrote:
> > To avoid a name conflict when adding the usb module to the
> > driver's directory in the stable branch, this patch simply
> > renames the kernel object.
> >
> > Signed-off-by: Christian Gromm
> > Reported-by: Greg Kroah-Hartman
> > ---
> > drivers/staging/most/usb/{most_usb.ko => most-usb.ko} | Bin
> > 1 file changed, 0 insertions(+), 0 deletions(-)
> > rename drivers/staging/most/usb/{most_usb.ko => most-usb.ko}
> > (100%)
> >
> > diff --git a/drivers/staging/most/usb/most_usb.ko
> > b/drivers/staging/most/usb/most-usb.ko
> > similarity index 100%
> > rename from drivers/staging/most/usb/most_usb.ko
> > rename to drivers/staging/most/usb/most-usb.ko
>
> You renamed a binary file??? That is not in the source tree?
>
I know. And I was kind of confused that you chose this path (1).
I even had to mess up my git to do that.
>
> No, I mean make the patch move the .c file from staging to the
> drivers/most directory and adjust the Kconfig/Makefiles for that
> movement.
>
Huh, but this is exactly what I wanted to do in the first place.
Add it to the stable branch and change the staging files to
avoid the conflict.
But then you told me to not touch the staging files. Remember?
Anyways, here is what I am going to do now:
add the usb file to the stable branch, change the name of the
.ko inside the stable branch and then once the staging files
are removed, I'll rename it again to get the old name back.
Does this make sense now?
thanks,
Chris
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Hello
I sent you a mesaage,did you receive that?Please let me know. Tony ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
KASAN: slab-out-of-bounds Read in prism2sta_probe_usb
Hello, syzbot found the following issue on: HEAD commit:e3ee0e74 usb: common: usb-conn-gpio: Register charger git tree: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-testing console output: https://syzkaller.appspot.com/x/log.txt?x=14ff152490 kernel config: https://syzkaller.appspot.com/x/.config?x=fb6677a3d4f11788 dashboard link: https://syzkaller.appspot.com/bug?extid=22794221ab96b0bab53a compiler: gcc (GCC) 10.1.0-syz 20200507 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=11319e6c90 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=10ae871290 IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+22794221ab96b0bab...@syzkaller.appspotmail.com usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 usb 1-1: config 0 descriptor?? == BUG: KASAN: slab-out-of-bounds in usb_endpoint_xfer_bulk include/uapi/linux/usb/ch9.h:518 [inline] BUG: KASAN: slab-out-of-bounds in usb_endpoint_is_bulk_out include/uapi/linux/usb/ch9.h:586 [inline] BUG: KASAN: slab-out-of-bounds in prism2sta_probe_usb+0x26c/0x810 drivers/staging/wlan-ng/prism2usb.c:80 Read of size 1 at addr 8881cc0c85a3 by task kworker/0:3/138 CPU: 0 PID: 138 Comm: kworker/0:3 Not tainted 5.8.0-rc7-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: usb_hub_wq hub_event Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0xf6/0x16e lib/dump_stack.c:118 print_address_description.constprop.0+0x1a/0x210 mm/kasan/report.c:383 __kasan_report mm/kasan/report.c:513 [inline] kasan_report.cold+0x37/0x7c mm/kasan/report.c:530 usb_endpoint_xfer_bulk include/uapi/linux/usb/ch9.h:518 [inline] usb_endpoint_is_bulk_out include/uapi/linux/usb/ch9.h:586 [inline] prism2sta_probe_usb+0x26c/0x810 drivers/staging/wlan-ng/prism2usb.c:80 usb_probe_interface+0x315/0x7f0 drivers/usb/core/driver.c:374 really_probe+0x291/0xc90 drivers/base/dd.c:520 driver_probe_device+0x26b/0x3d0 drivers/base/dd.c:696 __device_attach_driver+0x1d1/0x290 drivers/base/dd.c:802 bus_for_each_drv+0x15f/0x1e0 drivers/base/bus.c:431 __device_attach+0x28d/0x430 drivers/base/dd.c:868 bus_probe_device+0x1e4/0x290 drivers/base/bus.c:491 device_add+0xb09/0x1c10 drivers/base/core.c:2700 usb_set_configuration+0xf05/0x18a0 drivers/usb/core/message.c:2032 usb_generic_driver_probe+0xba/0xf2 drivers/usb/core/generic.c:239 usb_probe_device+0xd9/0x250 drivers/usb/core/driver.c:272 really_probe+0x291/0xc90 drivers/base/dd.c:520 driver_probe_device+0x26b/0x3d0 drivers/base/dd.c:696 __device_attach_driver+0x1d1/0x290 drivers/base/dd.c:802 bus_for_each_drv+0x15f/0x1e0 drivers/base/bus.c:431 __device_attach+0x28d/0x430 drivers/base/dd.c:868 bus_probe_device+0x1e4/0x290 drivers/base/bus.c:491 device_add+0xb09/0x1c10 drivers/base/core.c:2700 usb_new_device.cold+0x71d/0xfd4 drivers/usb/core/hub.c:2554 hub_port_connect drivers/usb/core/hub.c:5208 [inline] hub_port_connect_change drivers/usb/core/hub.c:5348 [inline] port_event drivers/usb/core/hub.c:5494 [inline] hub_event+0x2361/0x4390 drivers/usb/core/hub.c:5576 process_one_work+0x94c/0x15f0 kernel/workqueue.c:2269 worker_thread+0x64c/0x1120 kernel/workqueue.c:2415 kthread+0x392/0x470 kernel/kthread.c:291 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293 Allocated by task 138: save_stack+0x1b/0x40 mm/kasan/common.c:48 set_track mm/kasan/common.c:56 [inline] __kasan_kmalloc.constprop.0+0xc2/0xd0 mm/kasan/common.c:494 kmalloc include/linux/slab.h:560 [inline] kzalloc include/linux/slab.h:669 [inline] usb_parse_interface drivers/usb/core/config.c:571 [inline] usb_parse_configuration drivers/usb/core/config.c:795 [inline] usb_get_configuration+0x13d7/0x3a50 drivers/usb/core/config.c:944 usb_enumerate_device drivers/usb/core/hub.c:2387 [inline] usb_new_device+0x42c/0x7a0 drivers/usb/core/hub.c:2523 hub_port_connect drivers/usb/core/hub.c:5208 [inline] hub_port_connect_change drivers/usb/core/hub.c:5348 [inline] port_event drivers/usb/core/hub.c:5494 [inline] hub_event+0x2361/0x4390 drivers/usb/core/hub.c:5576 process_one_work+0x94c/0x15f0 kernel/workqueue.c:2269 worker_thread+0x64c/0x1120 kernel/workqueue.c:2415 kthread+0x392/0x470 kernel/kthread.c:291 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293 Freed by task 16: save_stack+0x1b/0x40 mm/kasan/common.c:48 set_track mm/kasan/common.c:56 [inline] kasan_set_free_info mm/kasan/common.c:316 [inline] __kasan_slab_free+0x116/0x160 mm/kasan/common.c:455 slab_free_hook mm/slub.c:1474 [inline] slab_free_freelist_hook+0x53/0x140 mm/slub.c:1507 slab_free mm/slub.c:3072 [inline] kfree+0xbc/0x2c0 mm/slub.c:4052 seccomp_filter_free kernel/seccomp.c:573 [inline] seccomp_filter_free kernel/seccomp.c:569 [inline] __put_seccomp_filter+0xb3/0xf0 kernel/seccomp.c:583 free_task+0x76/0x110
Re: [PATCH] staging: atomisp: move null check to earlier point
On July 30, 2020 11:48:06 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.
Noted. Sorry. I'm not a native English speaker.
I always feel like this is a pointless requirement. We're turning into
bureaucracts.
diff --git a/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c
b/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c
index 0df46a1af5f0..8e9c5016f299 100644
--- a/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c
+++ b/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c
@@ -871,6 +871,11 @@ static int gmin_v2p8_ctrl(struct v4l2_subdev *subdev,
int on)
int ret;
int value;
+ if (!gs) {
+ pr_err("Unable to find gmin subdevice\n");
+ return -EINVAL;
And here is a change of semantics...
Yeah. The change of semantics should be documented in the commit
message, but it's actually correct. I discussed this with Mauro earlier
but my bug reporting script didn't CC a mailing list and I didn't
catch it. Mauro suggested:
53 > Yet, it could make sense to have something like:
54 >
55 > if (WARN_ON(!gs))
56 > return -ENODEV;
57 >
58 > at the beginning of the functions that call find_gmin_subdev().
I will be updating v2 according to this.
regards,
dan carpenter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: most: usb: rename most_usb.ko
On Thu, Jul 30, 2020 at 08:27:29AM +, christian.gr...@microchip.com wrote:
> On Wed, 2020-07-29 at 19:03 +0200, Greg KH wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you
> > know the content is safe
> >
> > On Wed, Jul 29, 2020 at 06:38:48PM +0200, Christian Gromm wrote:
> > > To avoid a name conflict when adding the usb module to the
> > > driver's directory in the stable branch, this patch simply
> > > renames the kernel object.
> > >
> > > Signed-off-by: Christian Gromm
> > > Reported-by: Greg Kroah-Hartman
> > > ---
> > > drivers/staging/most/usb/{most_usb.ko => most-usb.ko} | Bin
> > > 1 file changed, 0 insertions(+), 0 deletions(-)
> > > rename drivers/staging/most/usb/{most_usb.ko => most-usb.ko}
> > > (100%)
> > >
> > > diff --git a/drivers/staging/most/usb/most_usb.ko
> > > b/drivers/staging/most/usb/most-usb.ko
> > > similarity index 100%
> > > rename from drivers/staging/most/usb/most_usb.ko
> > > rename to drivers/staging/most/usb/most-usb.ko
> >
> > You renamed a binary file??? That is not in the source tree?
> >
>
> I know. And I was kind of confused that you chose this path (1).
> I even had to mess up my git to do that.
>
> >
> > No, I mean make the patch move the .c file from staging to the
> > drivers/most directory and adjust the Kconfig/Makefiles for that
> > movement.
> >
>
> Huh, but this is exactly what I wanted to do in the first place.
> Add it to the stable branch and change the staging files to
> avoid the conflict.
> But then you told me to not touch the staging files. Remember?
Yes, but that would have made it impossible for people to review.
> Anyways, here is what I am going to do now:
> add the usb file to the stable branch, change the name of the
> .ko inside the stable branch and then once the staging files
> are removed, I'll rename it again to get the old name back.
>
> Does this make sense now?
Yes, but I still think that's harder, just do it the original way you
wanted to in the first place. Now that people have had a chance to
review it, no one has objected, so let's just do it the simple way.
thanks,
greg k-h
___
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 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
bureaucracts.
>
> > diff --git a/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c
> > b/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c
> > index 0df46a1af5f0..8e9c5016f299 100644
> > --- a/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c
> > +++ b/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c
> > @@ -871,6 +871,11 @@ static int gmin_v2p8_ctrl(struct v4l2_subdev *subdev,
> > int on)
> > int ret;
> > int value;
> >
> > + if (!gs) {
> > + pr_err("Unable to find gmin subdevice\n");
>
> > + return -EINVAL;
>
> And here is a change of semantics...
Yeah. The change of semantics should be documented in the commit
message, but it's actually correct. I discussed this with Mauro earlier
but my bug reporting script didn't CC a mailing list and I didn't
catch it. Mauro suggested:
53 > Yet, it could make sense to have something like:
54 >
55 > if (WARN_ON(!gs))
56 > return -ENODEV;
57 >
58 > at the beginning of the functions that call find_gmin_subdev().
regards,
dan carpenter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 0/3] Modernize tasklet callback API
Kees, Kees Cook writes: > This is the infrastructure changes to prepare the tasklet API for > conversion to passing the tasklet struct as the callback argument instead > of an arbitrary unsigned long. The first patch details why this is useful > (it's the same rationale as the timer_struct changes from a bit ago: > less abuse during memory corruption attacks, more in line with existing > ways of doing things in the kernel, save a little space in struct, > etc). Notably, the existing tasklet API use is much less messy, so there > is less to clean up. > > It's not clear to me which tree this should go through... Greg since it > starts with a USB clean-up, -tip for timer or interrupt, or if I should > just carry it. I'm open to suggestions, but if I don't hear otherwise, > I'll just carry it. > > My goal is to have this merged for v5.9-rc1 so that during the v5.10 > development cycle the new API will be available. The entire tree of > changes is here[1] currently, but to split it up by maintainer the > infrastructure changes need to be landed first. > > Review and Acks appreciated! :) I'd rather see tasklets vanish from the planet completely, but that's going to be a daring feat. So, grudgingly: Acked-by: Thomas Gleixner ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
