[PATCH] staging: mt7621-pci: Fix compiler error 'slot' may be used uninitialized
In commit 802a2f7b2fe3 ("staging: mt7621-pci: factor out
'mt7621_pcie_enable_port' function"), slot = port->slot; line was removed.
Also other dev_err() print parameter was changed from slot to port->slot.
So the same should be done here.
This also fixes compiler error:
drivers/staging/mt7621-pci/pci-mt7621.c: In function 'mt7621_pci_probe':
./include/linux/device.h:1490:2: warning: 'slot' may be used uninitialized in
this function [-Wmaybe-uninitialized]
_dev_info(dev, dev_fmt(fmt), ##__VA_ARGS__)
^
drivers/staging/mt7621-pci/pci-mt7621.c:504:6: note: 'slot' was declared here
u32 slot;
^~~~
Fixes: 802a2f7b2fe3 ("staging: mt7621-pci: factor out 'mt7621_pcie_enable_port'
function")
Signed-off-by: René van Dorst
---
drivers/staging/mt7621-pci/pci-mt7621.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/mt7621-pci/pci-mt7621.c
b/drivers/staging/mt7621-pci/pci-mt7621.c
index 03d919a94552..81600c03cae1 100644
--- a/drivers/staging/mt7621-pci/pci-mt7621.c
+++ b/drivers/staging/mt7621-pci/pci-mt7621.c
@@ -511,7 +511,7 @@ static void mt7621_pcie_enable_ports(struct mt7621_pcie
*pcie)
port->slot);
continue;
}
- dev_info(dev, "PCIE%d enabled\n", slot);
+ dev_info(dev, "PCIE%d enabled\n", port->slot);
num_slots_enabled++;
}
}
--
2.20.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 0/4] staging: mt7621-pci: Handle minor issues
On Wed, Jun 26, 2019 at 7:45 AM Sergio Paracuellos wrote: > No problem, I also miss them rewritting code. That is bad :((. > > BTW, I applied that on top of your other recent fixes (that ones > > you pushed to gregkh for staging). So I tested with the > > updated GPIO reset code. > Ok, anyway.. I have just sent the change jus to have the same code behaviour > that was being there before. FWIW, I have the same results as Greg -- the 4.2 driver works every time, staging-next frequently hangs. Out of curiosity, if it's not too complex an answer to go into, what's the benefit of the staging-next driver? Is there a reason to prefer it to the 4.2 driver? -- Brett Neumeier (bneume...@gmail.com) ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] PCI: hv: Fix a use-after-free bug in hv_eject_device_work()
On Fri, Jun 21, 2019 at 11:45:23PM +, Dexuan Cui wrote:
>
> The commit 05f151a73ec2 itself is correct, but it exposes this
> use-after-free bug, which is caught by some memory debug options.
>
> Add a Fixes tag to indicate the dependency.
>
> Fixes: 05f151a73ec2 ("PCI: hv: Fix a memory leak in hv_eject_device_work()")
> Signed-off-by: Dexuan Cui
> Cc: sta...@vger.kernel.org
> ---
>
> In v2:
> Replaced "hpdev->hbus" with "hbus", since we have the new "hbus" variable.
> [Michael Kelley]
>
> drivers/pci/controller/pci-hyperv.c | 15 +--
> 1 file changed, 9 insertions(+), 6 deletions(-)
Applied to pci/hv for v5.3, thanks.
Lorenzo
> diff --git a/drivers/pci/controller/pci-hyperv.c
> b/drivers/pci/controller/pci-hyperv.c
> index 808a182830e5..5dadc964ad3b 100644
> --- a/drivers/pci/controller/pci-hyperv.c
> +++ b/drivers/pci/controller/pci-hyperv.c
> @@ -1880,6 +1880,7 @@ static void hv_pci_devices_present(struct
> hv_pcibus_device *hbus,
> static void hv_eject_device_work(struct work_struct *work)
> {
> struct pci_eject_response *ejct_pkt;
> + struct hv_pcibus_device *hbus;
> struct hv_pci_dev *hpdev;
> struct pci_dev *pdev;
> unsigned long flags;
> @@ -1890,6 +1891,7 @@ static void hv_eject_device_work(struct work_struct
> *work)
> } ctxt;
>
> hpdev = container_of(work, struct hv_pci_dev, wrk);
> + hbus = hpdev->hbus;
>
> WARN_ON(hpdev->state != hv_pcichild_ejecting);
>
> @@ -1900,8 +1902,7 @@ static void hv_eject_device_work(struct work_struct
> *work)
>* because hbus->pci_bus may not exist yet.
>*/
> wslot = wslot_to_devfn(hpdev->desc.win_slot.slot);
> - pdev = pci_get_domain_bus_and_slot(hpdev->hbus->sysdata.domain, 0,
> -wslot);
> + pdev = pci_get_domain_bus_and_slot(hbus->sysdata.domain, 0, wslot);
> if (pdev) {
> pci_lock_rescan_remove();
> pci_stop_and_remove_bus_device(pdev);
> @@ -1909,9 +1910,9 @@ static void hv_eject_device_work(struct work_struct
> *work)
> pci_unlock_rescan_remove();
> }
>
> - spin_lock_irqsave(&hpdev->hbus->device_list_lock, flags);
> + spin_lock_irqsave(&hbus->device_list_lock, flags);
> list_del(&hpdev->list_entry);
> - spin_unlock_irqrestore(&hpdev->hbus->device_list_lock, flags);
> + spin_unlock_irqrestore(&hbus->device_list_lock, flags);
>
> if (hpdev->pci_slot)
> pci_destroy_slot(hpdev->pci_slot);
> @@ -1920,7 +1921,7 @@ static void hv_eject_device_work(struct work_struct
> *work)
> ejct_pkt = (struct pci_eject_response *)&ctxt.pkt.message;
> ejct_pkt->message_type.type = PCI_EJECTION_COMPLETE;
> ejct_pkt->wslot.slot = hpdev->desc.win_slot.slot;
> - vmbus_sendpacket(hpdev->hbus->hdev->channel, ejct_pkt,
> + vmbus_sendpacket(hbus->hdev->channel, ejct_pkt,
>sizeof(*ejct_pkt), (unsigned long)&ctxt.pkt,
>VM_PKT_DATA_INBAND, 0);
>
> @@ -1929,7 +1930,9 @@ static void hv_eject_device_work(struct work_struct
> *work)
> /* For the two refs got in new_pcichild_device() */
> put_pcichild(hpdev);
> put_pcichild(hpdev);
> - put_hvpcibus(hpdev->hbus);
> + /* hpdev has been freed. Do not use it any more. */
> +
> + put_hvpcibus(hbus);
> }
>
> /**
> --
> 2.17.1
>
[PATCH] staging: greybus: Replace function gb_i2c_device_setup()
Remove function gb_i2c_device_setup as all it does is call
gb_i2c_functionality_operation.
Rename gb_i2c_functionality_operation to gb_i2c_device_setup to maintain
compatibility with call sites.
Issue found with Coccinelle.
Signed-off-by: Nishka Dasgupta
---
drivers/staging/greybus/i2c.c | 22 --
1 file changed, 8 insertions(+), 14 deletions(-)
diff --git a/drivers/staging/greybus/i2c.c b/drivers/staging/greybus/i2c.c
index 7bb85a75d3b1..b2522043a1a4 100644
--- a/drivers/staging/greybus/i2c.c
+++ b/drivers/staging/greybus/i2c.c
@@ -31,7 +31,14 @@ static u32 gb_i2c_functionality_map(u32 gb_i2c_functionality)
return gb_i2c_functionality;/* All bits the same for now */
}
-static int gb_i2c_functionality_operation(struct gb_i2c_device *gb_i2c_dev)
+/*
+ * Do initial setup of the i2c device. This includes verifying we
+ * can support it (based on the protocol version it advertises).
+ * If that's OK, we get and cached its functionality bits.
+ *
+ * Note: gb_i2c_dev->connection is assumed to have been valid.
+ */
+static int gb_i2c_device_setup(struct gb_i2c_device *gb_i2c_dev)
{
struct gb_i2c_functionality_response response;
u32 functionality;
@@ -235,19 +242,6 @@ static const struct i2c_algorithm gb_i2c_algorithm = {
.functionality = gb_i2c_functionality,
};
-/*
- * Do initial setup of the i2c device. This includes verifying we
- * can support it (based on the protocol version it advertises).
- * If that's OK, we get and cached its functionality bits.
- *
- * Note: gb_i2c_dev->connection is assumed to have been valid.
- */
-static int gb_i2c_device_setup(struct gb_i2c_device *gb_i2c_dev)
-{
- /* Assume the functionality never changes, just get it once */
- return gb_i2c_functionality_operation(gb_i2c_dev);
-}
-
static int gb_i2c_probe(struct gbphy_device *gbphy_dev,
const struct gbphy_device_id *id)
{
--
2.19.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 2/2] staging: media: sunxi: Replace function cedrus_check_format()
On 05/07/19 3:56 PM, Paul Kocialkowski wrote:
Hi,
On Wed 03 Jul 19, 13:43, Nishka Dasgupta wrote:
Remove function cedrus_check_format as all it does is call
cedrus_find_format.
Rename cedrus_find_format to cedrus_check_format to maintain
compatibility with call sites.
Issue found with Coccinelle.
Maybe we could have a !! or a bool cast to make coccinelle happy here?
Coccinelle didn't flag the type mismatch, just the single-line
functions. I could add the bool cast then?
Thanking you,
Nishka
Cheers,
Paul
Signed-off-by: Nishka Dasgupta
---
drivers/staging/media/sunxi/cedrus/cedrus_video.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_video.c
b/drivers/staging/media/sunxi/cedrus/cedrus_video.c
index 0ec31b9e0aea..d5cc9ed04fd2 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus_video.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus_video.c
@@ -55,8 +55,8 @@ static inline struct cedrus_ctx *cedrus_file2ctx(struct file
*file)
return container_of(file->private_data, struct cedrus_ctx, fh);
}
-static bool cedrus_find_format(u32 pixelformat, u32 directions,
- unsigned int capabilities)
+static bool cedrus_check_format(u32 pixelformat, u32 directions,
+ unsigned int capabilities)
{
struct cedrus_format *fmt;
unsigned int i;
@@ -76,12 +76,6 @@ static bool cedrus_find_format(u32 pixelformat, u32
directions,
return false;
}
-static bool cedrus_check_format(u32 pixelformat, u32 directions,
- unsigned int capabilities)
-{
- return cedrus_find_format(pixelformat, directions, capabilities);
-}
-
static void cedrus_prepare_format(struct v4l2_pix_format *pix_fmt)
{
unsigned int width = pix_fmt->width;
--
2.19.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/2] staging: media: sunxi: Change return type of cedrus_find_format()
On 05/07/19 3:56 PM, Paul Kocialkowski wrote:
Hi,
On Wed 03 Jul 19, 13:43, Nishka Dasgupta wrote:
Change return type of cedrus_find_format to bool as it is only called
once, by a function whose return value is bool, and the return value of
cedrus_find_format is returned as-is at the call-site.
Issue found with Coccinelle.
The purpose of this function (although definitely under-used at this point),
was to return the pointer to the element structure, not to indicate whether
the format format is part of the list or not.
In spite of that, this change reduces the use case for the function, so I do
not think it is beneficial, sorry.
Okay, thank you for the clarification.
Nishka
Cheers,
Paul
Signed-off-by: Nishka Dasgupta
---
drivers/staging/media/sunxi/cedrus/cedrus_video.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_video.c
b/drivers/staging/media/sunxi/cedrus/cedrus_video.c
index 9673874ece10..0ec31b9e0aea 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus_video.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus_video.c
@@ -55,8 +55,8 @@ static inline struct cedrus_ctx *cedrus_file2ctx(struct file
*file)
return container_of(file->private_data, struct cedrus_ctx, fh);
}
-static struct cedrus_format *cedrus_find_format(u32 pixelformat, u32 directions,
- unsigned int capabilities)
+static bool cedrus_find_format(u32 pixelformat, u32 directions,
+ unsigned int capabilities)
{
struct cedrus_format *fmt;
unsigned int i;
@@ -70,13 +70,10 @@ static struct cedrus_format *cedrus_find_format(u32
pixelformat, u32 directions,
if (fmt->pixelformat == pixelformat &&
(fmt->directions & directions) != 0)
- break;
+ return true;
}
- if (i == CEDRUS_FORMATS_COUNT)
- return NULL;
-
- return &cedrus_formats[i];
+ return false;
}
static bool cedrus_check_format(u32 pixelformat, u32 directions,
--
2.19.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[driver-core:debugfs_cleanup 185/194] drivers//iommu/omap-iommu-debug.c:254:44: error: 'rtlb_fops' undeclared; did you mean 'tlb_fops'?
tree:
https://kernel.googlesource.com/pub/scm/linux/kernel/git/gregkh/driver-core.git
debugfs_cleanup
head: 8c54807642d011014627c0187798950d30c3abf4
commit: aab8ab1a5aaec133532b9fba30b1da24c08dbac3 [185/194] omap-iommu: no need
to check return value of debugfs_create functions
config: arm-allmodconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (GCC) 7.4.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout aab8ab1a5aaec133532b9fba30b1da24c08dbac3
# save the attached .config to linux build tree
GCC_VERSION=7.4.0 make.cross ARCH=arm
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
drivers//iommu/omap-iommu-debug.c: In function 'omap_iommu_debugfs_add':
>> drivers//iommu/omap-iommu-debug.c:254:44: error: 'rtlb_fops' undeclared
>> (first use in this function); did you mean 'tlb_fops'?
debugfs_create_file("tlb", 0400, d, obj, &rtlb_fops);
^
tlb_fops
drivers//iommu/omap-iommu-debug.c:254:44: note: each undeclared identifier
is reported only once for each function it appears in
vim +254 drivers//iommu/omap-iommu-debug.c
241
242 void omap_iommu_debugfs_add(struct omap_iommu *obj)
243 {
244 struct dentry *d;
245
246 if (!iommu_debug_root)
247 return;
248
249 d = debugfs_create_dir(obj->name, iommu_debug_root);
250 obj->debug_dir = d;
251
252 debugfs_create_u32("nr_tlb_entries", 0400, d,
&obj->nr_tlb_entries);
253 debugfs_create_file("regs", 0400, d, obj, ®s_fops);
> 254 debugfs_create_file("tlb", 0400, d, obj, &rtlb_fops);
255 debugfs_create_file("pagetable", 0400, d, obj, &pagetable_fops);
256 }
257
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 2/2] staging: media: sunxi: Replace function cedrus_check_format()
Hi,
On Wed 03 Jul 19, 13:43, Nishka Dasgupta wrote:
> Remove function cedrus_check_format as all it does is call
> cedrus_find_format.
> Rename cedrus_find_format to cedrus_check_format to maintain
> compatibility with call sites.
> Issue found with Coccinelle.
Maybe we could have a !! or a bool cast to make coccinelle happy here?
Cheers,
Paul
> Signed-off-by: Nishka Dasgupta
> ---
> drivers/staging/media/sunxi/cedrus/cedrus_video.c | 10 ++
> 1 file changed, 2 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_video.c
> b/drivers/staging/media/sunxi/cedrus/cedrus_video.c
> index 0ec31b9e0aea..d5cc9ed04fd2 100644
> --- a/drivers/staging/media/sunxi/cedrus/cedrus_video.c
> +++ b/drivers/staging/media/sunxi/cedrus/cedrus_video.c
> @@ -55,8 +55,8 @@ static inline struct cedrus_ctx *cedrus_file2ctx(struct
> file *file)
> return container_of(file->private_data, struct cedrus_ctx, fh);
> }
>
> -static bool cedrus_find_format(u32 pixelformat, u32 directions,
> -unsigned int capabilities)
> +static bool cedrus_check_format(u32 pixelformat, u32 directions,
> + unsigned int capabilities)
> {
> struct cedrus_format *fmt;
> unsigned int i;
> @@ -76,12 +76,6 @@ static bool cedrus_find_format(u32 pixelformat, u32
> directions,
> return false;
> }
>
> -static bool cedrus_check_format(u32 pixelformat, u32 directions,
> - unsigned int capabilities)
> -{
> - return cedrus_find_format(pixelformat, directions, capabilities);
> -}
> -
> static void cedrus_prepare_format(struct v4l2_pix_format *pix_fmt)
> {
> unsigned int width = pix_fmt->width;
> --
> 2.19.1
>
--
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/2] staging: media: sunxi: Change return type of cedrus_find_format()
Hi,
On Wed 03 Jul 19, 13:43, Nishka Dasgupta wrote:
> Change return type of cedrus_find_format to bool as it is only called
> once, by a function whose return value is bool, and the return value of
> cedrus_find_format is returned as-is at the call-site.
> Issue found with Coccinelle.
The purpose of this function (although definitely under-used at this point),
was to return the pointer to the element structure, not to indicate whether
the format format is part of the list or not.
In spite of that, this change reduces the use case for the function, so I do
not think it is beneficial, sorry.
Cheers,
Paul
> Signed-off-by: Nishka Dasgupta
> ---
> drivers/staging/media/sunxi/cedrus/cedrus_video.c | 11 ---
> 1 file changed, 4 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_video.c
> b/drivers/staging/media/sunxi/cedrus/cedrus_video.c
> index 9673874ece10..0ec31b9e0aea 100644
> --- a/drivers/staging/media/sunxi/cedrus/cedrus_video.c
> +++ b/drivers/staging/media/sunxi/cedrus/cedrus_video.c
> @@ -55,8 +55,8 @@ static inline struct cedrus_ctx *cedrus_file2ctx(struct
> file *file)
> return container_of(file->private_data, struct cedrus_ctx, fh);
> }
>
> -static struct cedrus_format *cedrus_find_format(u32 pixelformat, u32
> directions,
> - unsigned int capabilities)
> +static bool cedrus_find_format(u32 pixelformat, u32 directions,
> +unsigned int capabilities)
> {
> struct cedrus_format *fmt;
> unsigned int i;
> @@ -70,13 +70,10 @@ static struct cedrus_format *cedrus_find_format(u32
> pixelformat, u32 directions,
>
> if (fmt->pixelformat == pixelformat &&
> (fmt->directions & directions) != 0)
> - break;
> + return true;
> }
>
> - if (i == CEDRUS_FORMATS_COUNT)
> - return NULL;
> -
> - return &cedrus_formats[i];
> + return false;
> }
>
> static bool cedrus_check_format(u32 pixelformat, u32 directions,
> --
> 2.19.1
>
--
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: rtl8712: remove redundant assignment to variable res
From: Colin Ian King
The variable res is being initialized with a value that is never
read and it is being updated later with a new value. The
initialization is redundant and can be removed.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King
---
drivers/staging/rtl8712/rtl8712_xmit.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8712/rtl8712_xmit.c
b/drivers/staging/rtl8712/rtl8712_xmit.c
index 307b0e292976..dac79e6dcdcb 100644
--- a/drivers/staging/rtl8712/rtl8712_xmit.c
+++ b/drivers/staging/rtl8712/rtl8712_xmit.c
@@ -739,7 +739,7 @@ static void dump_xframe(struct _adapter *padapter,
int r8712_xmit_direct(struct _adapter *padapter, struct xmit_frame *pxmitframe)
{
- int res = _SUCCESS;
+ int res;
res = r8712_xmitframe_coalesce(padapter, pxmitframe->pkt, pxmitframe);
pxmitframe->pkt = NULL;
--
2.20.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [OSSNA] Intro to kernel hacking tutorial
Hi, On Fri, Jul 5, 2019 at 4:51 AM Tobin C. Harding wrote: > > Hi, > > I am doing a tutorial at OSSNA in San Diego on getting into kernel > hacking. I'm only a couple of years deep into kernel hacking so I > wanted to reach out to those more experienced than myself (and those > less experienced). > > Is there any thing that you would really like to see covered in this > tutorial? > I'm not involved in kernel hacking, but I've tried several times to start writing patches. Because of time sharing issue I haven't get to the end but a tutorial will be great. The question I've asked me during my several tries is where can I be useful (which topics, what I'm confident enough in to play with...). Looking in drivers/staging wasn't any help in my case and making kernel janitor is useful but not very well viewed as I've heard. So I think that digging further in your tutorial on several ways to start kernel hacking may be interesting. > Current format/content: the tutorial will attempt to bridge the gap in > the learning process between the 'first patch' page on kernelnewbies.org > wiki and being 'comfortable' patching the kernel via LKML. Outcome will > (hopefully) be a small patch set into drivers/staging/. (Don't worry > Greg only one group got to this stage last time, you won't get flooded > with patches :) > HTH and very enthusiast to read this tutorial. Loïc > Thanks, > Tobin. > > ___ > Kernelnewbies mailing list > kernelnewb...@kernelnewbies.org > https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
