[PATCH] staging: rts5208: add missed pci_release_regions
The driver forgets to call pci_release_regions() in probe failure
and remove.
Add the missed calls to fix it.
Signed-off-by: Chuhong Yuan
---
drivers/staging/rts5208/rtsx.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/rts5208/rtsx.c b/drivers/staging/rts5208/rtsx.c
index cb95ad6fa4f9..15fc96b42032 100644
--- a/drivers/staging/rts5208/rtsx.c
+++ b/drivers/staging/rts5208/rtsx.c
@@ -831,7 +831,8 @@ static int rtsx_probe(struct pci_dev *pci,
host = scsi_host_alloc(&rtsx_host_template, sizeof(*dev));
if (!host) {
dev_err(&pci->dev, "Unable to allocate the scsi host\n");
- return -ENOMEM;
+ err = -ENOMEM;
+ goto scsi_host_alloc_fail;
}
dev = host_to_rtsx(host);
@@ -971,7 +972,8 @@ static int rtsx_probe(struct pci_dev *pci,
kfree(dev->chip);
chip_alloc_fail:
dev_err(&pci->dev, "%s failed\n", __func__);
-
+scsi_host_alloc_fail:
+ pci_release_regions(pci);
return err;
}
@@ -983,6 +985,7 @@ static void rtsx_remove(struct pci_dev *pci)
quiesce_and_remove_host(dev);
release_everything(dev);
+ pci_release_regions(pci);
}
/* PCI IDs */
--
2.24.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re. Guten Tag
Liebste Geliebte, Ich bin David Raymon. Ein portugiesischer Staatsbьrger. Ich habe gesucht und Ihre E-Mail gesehen. Also habe ich beschlossen, Ihnen zu schreiben, ob Ihre E-Mail echt ist. Bei mir wurde Speiserцhrenkrebs diagnostiziert. Es hat alle Formen der medizinischen Behandlung verunreinigt, und jetzt habe ich nur noch ein paar Monate zu leben. Ich bin sehr reich, war aber nie groЯzьgig; Ich habe den grцЯten Teil meines Vermцgens meinen unmittelbaren Familienmitgliedern gegeben. Ich habe beschlossen, Almosen an Wohltдtigkeitsorganisationen zu spenden. Ich kann das aus gesundheitlichen Grьnden nicht mehr selbst machen. Ich habe einmal Familienmitglieder gebeten, etwas Geld an Wohltдtigkeitsorganisationen zu spenden. Sie haben dies abgelehnt und das Geld behalten. Ich habe eine riesige Bareinlage von achtzehn Millionen Dollar bei einer Sicherheitsfirma in Amerika. Ich mцchte, dass Sie mir helfen, diese Kaution zu sammeln und an Wohltдtigkeitsorganisationen zu senden. Sie werden 30% dieser Mittel fьr Ihre Unterstьtzung in Anspruch nehmen. Ich mцchte Sie bitten, den Erhalt dieser E-Mail so bald wie mцglich zu bestдtigen und sie mit absoluter Vertraulichkeit und Aufrichtigkeit zu behandeln. Bitte antworten Sie aus Sicherheitsgrьnden auf meine private E-Mail-Adresse fabiano.ron5...@gmail.com David Raymon ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re. Guten Tag
Liebste Geliebte, Ich bin David Raymon. Ein portugiesischer Staatsbьrger. Ich habe gesucht und Ihre E-Mail gesehen. Also habe ich beschlossen, Ihnen zu schreiben, ob Ihre E-Mail echt ist. Bei mir wurde Speiserцhrenkrebs diagnostiziert. Es hat alle Formen der medizinischen Behandlung verunreinigt, und jetzt habe ich nur noch ein paar Monate zu leben. Ich bin sehr reich, war aber nie groЯzьgig; Ich habe den grцЯten Teil meines Vermцgens meinen unmittelbaren Familienmitgliedern gegeben. Ich habe beschlossen, Almosen an Wohltдtigkeitsorganisationen zu spenden. Ich kann das aus gesundheitlichen Grьnden nicht mehr selbst machen. Ich habe einmal Familienmitglieder gebeten, etwas Geld an Wohltдtigkeitsorganisationen zu spenden. Sie haben dies abgelehnt und das Geld behalten. Ich habe eine riesige Bareinlage von achtzehn Millionen Dollar bei einer Sicherheitsfirma in Amerika. Ich mцchte, dass Sie mir helfen, diese Kaution zu sammeln und an Wohltдtigkeitsorganisationen zu senden. Sie werden 30% dieser Mittel fьr Ihre Unterstьtzung in Anspruch nehmen. Ich mцchte Sie bitten, den Erhalt dieser E-Mail so bald wie mцglich zu bestдtigen und sie mit absoluter Vertraulichkeit und Aufrichtigkeit zu behandeln. Bitte antworten Sie aus Sicherheitsgrьnden auf meine private E-Mail-Adresse fabiano.ron5...@gmail.com David Raymon ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v1] staging: exfat: fix multiple definition error of `rename_file'
On Wed, Dec 4, 2019 at 3:46 PM Brendan Higgins wrote: > > `rename_file' was exported but not properly namespaced causing a > multiple definition error because `rename_file' is already defined in > fs/hostfs/hostfs_user.c: > > ld: drivers/staging/exfat/exfat_core.o: in function `rename_file': > drivers/staging/exfat/exfat_core.c:2327: multiple definition of > `rename_file'; fs/hostfs/hostfs_user.o:fs/hostfs/hostfs_user.c:350: > first defined here > make: *** [Makefile:1077: vmlinux] Error 1 > > This error can be reproduced on ARCH=um by selecting: > > CONFIG_EXFAT_FS=y > CONFIG_HOSTFS=y > > Add a namespace prefix exfat_* to fix this error. > > Reported-by: Brendan Higgins > Signed-off-by: Brendan Higgins > Cc: Valdis Kletnieks > Cc: Greg Kroah-Hartman Tested-by: David Gow Reviewed-by: David Gow This works for me: I was able to reproduce the compile error without this patch, and successfully compile a UML kernel and mount an exfat fs after applying it. > --- > drivers/staging/exfat/exfat.h | 4 ++-- > drivers/staging/exfat/exfat_core.c | 4 ++-- > drivers/staging/exfat/exfat_super.c | 4 ++-- > 3 files changed, 6 insertions(+), 6 deletions(-) > > diff --git a/drivers/staging/exfat/exfat.h b/drivers/staging/exfat/exfat.h > index 2aac1e000977e..51c665a924b76 100644 > --- a/drivers/staging/exfat/exfat.h > +++ b/drivers/staging/exfat/exfat.h > @@ -805,8 +805,8 @@ s32 create_dir(struct inode *inode, struct chain_t *p_dir, > s32 create_file(struct inode *inode, struct chain_t *p_dir, > struct uni_name_t *p_uniname, u8 mode, struct file_id_t *fid); > void remove_file(struct inode *inode, struct chain_t *p_dir, s32 entry); > -s32 rename_file(struct inode *inode, struct chain_t *p_dir, s32 old_entry, > - struct uni_name_t *p_uniname, struct file_id_t *fid); > +s32 exfat_rename_file(struct inode *inode, struct chain_t *p_dir, s32 > old_entry, > + struct uni_name_t *p_uniname, struct file_id_t *fid); > s32 move_file(struct inode *inode, struct chain_t *p_olddir, s32 oldentry, > struct chain_t *p_newdir, struct uni_name_t *p_uniname, > struct file_id_t *fid); It seems a bit ugly to add the exfat_ prefix to just rename_file, rather than all of the above functions (e.g., create_dir, remove_file, etc). It doesn't look like any of the others are causing any issues though (while, for example, there is another remove_file in drivers/infiniband/hw/qib/qib_fs.c, it's static, so shouldn't be a problem). -- David ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: wfx: fix reset GPIO polarity
On Thursday 5 December 2019 15:49:55 CET Michał Mirosław wrote:
> On Thu, Dec 05, 2019 at 02:08:23PM +, Jérôme Pouiller wrote:
> > On Wednesday 4 December 2019 17:59:46 CET Michał Mirosław wrote:
> > > Driver inverts meaning of GPIO_ACTIVE_LOW/HIGH. Fix it to prevent
> > > confusion.
> > >
> > > Signed-off-by: Michał Mirosław
> > > ---
> > > drivers/staging/wfx/bus_spi.c | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/staging/wfx/bus_spi.c b/drivers/staging/wfx/bus_spi.c
> > > index ab0cda1e124f..73d0157a86ba 100644
> > > --- a/drivers/staging/wfx/bus_spi.c
> > > +++ b/drivers/staging/wfx/bus_spi.c
> > > @@ -199,9 +199,9 @@ static int wfx_spi_probe(struct spi_device *func)
> > > if (!bus->gpio_reset) {
> > > dev_warn(&func->dev, "try to load firmware anyway\n");
> > > } else {
> > > - gpiod_set_value(bus->gpio_reset, 0);
> > > - udelay(100);
> > > gpiod_set_value(bus->gpio_reset, 1);
> > > + udelay(100);
> > > + gpiod_set_value(bus->gpio_reset, 0);
> > > udelay(2000);
> > > }
> > Hello Michał,
> >
> > I did not find real consensus in kernel code. My personal taste would
> > be to keep this gpio "ACTIVE_HIGH" and rename it gpio_nreset. What do
> > you think about it?
> >
> > (in add, this solution would explicitly change the name of the DT
> > attribute instead of changing the semantic of the existing attribute)
>
> As a user (board developer) I would expect that DT describes the
> GPIO meaning directly: so when I specify GPIO_ACTIVE_HIGH flag I also
> wire up the board so that outputing 1 would match the active state of
> the chip's signal (that might be inverted for some reason). I think we
> should stick to what is said in Documentation/devicetree/bindings/gpio.txt
> (section 1.1).
>
> Since this is a new driver in kernel I would prefer to fix it at the start.
> Changing the name of the GPIO would also be ok, but since there is no DT
> binding yet, I guess there will come up an issue of 'compatible' string
> format that does not match 'vendor,chip' now, so we can use the difference
> for backwards compatibility with out-of-tree driver if needed.
Current 'compatible' string is "silabs,wfx-spi" (for now, it is the
same for out-of-tree and in-tree driver). And indeed, "wfx" does not
names a chip.
The three chips currently supported are wf200, wf200s and wfm200. Since
the driver provides DT bindings for SPI and SDIO buses, I think we
have to keep the "-spi" suffix. So compatible strings should be
"silabs,wf200-spi", "silabs,wf200s-spi" and "silabs,wfm200-spi", right?
So we could fix the semantic of gpios-reset and keep the backward
compatibility. Looks perfect.
I can make this change in my next pull-request (but if you submit a
patch, it will probably go faster :) ).
--
Jérôme Pouiller
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: exfat: properly support discard in clr_alloc_bitmap()
Currently the discard code in clr_alloc_bitmap() is just dead code.
Move code around so that the discard operation is properly attempted
when enabled.
Signed-off-by: Andrea Righi
---
drivers/staging/exfat/exfat_core.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/exfat/exfat_core.c
b/drivers/staging/exfat/exfat_core.c
index d2d3447083c7..463eb89c676a 100644
--- a/drivers/staging/exfat/exfat_core.c
+++ b/drivers/staging/exfat/exfat_core.c
@@ -192,8 +192,6 @@ static s32 clr_alloc_bitmap(struct super_block *sb, u32 clu)
exfat_bitmap_clear((u8 *)p_fs->vol_amap[i]->b_data, b);
- return sector_write(sb, sector, p_fs->vol_amap[i], 0);
-
#ifdef CONFIG_EXFAT_DISCARD
if (opts->discard) {
ret = sb_issue_discard(sb, START_SECTOR(clu),
@@ -202,9 +200,13 @@ static s32 clr_alloc_bitmap(struct super_block *sb, u32
clu)
if (ret == -EOPNOTSUPP) {
pr_warn("discard not supported by device, disabling");
opts->discard = 0;
+ } else {
+ return ret;
}
}
#endif /* CONFIG_EXFAT_DISCARD */
+
+ return sector_write(sb, sector, p_fs->vol_amap[i], 0);
}
static u32 test_alloc_bitmap(struct super_block *sb, u32 clu)
--
2.20.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v5 2/2] dt-bindings: iio: accel: add binding documentation for ADIS16240
On Sat, Nov 23, 2019 at 08:35:10PM -0300, Rodrigo Carvalho wrote:
> This patch add device tree binding documentation for ADIS16240.
>
> Signed-off-by: Rodrigo Ribeiro Carvalho
checkpatch.pl complains about a mismatch between the author and S-o-b.
> ---
> V5:
> - None
>
> .../bindings/iio/accel/adi,adis16240.yaml | 49 +++
> 1 file changed, 49 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/iio/accel/adi,adis16240.yaml
>
> diff --git a/Documentation/devicetree/bindings/iio/accel/adi,adis16240.yaml
> b/Documentation/devicetree/bindings/iio/accel/adi,adis16240.yaml
> new file mode 100644
> index ..8e902f7c49e6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/accel/adi,adis16240.yaml
> @@ -0,0 +1,49 @@
> +# SPDX-License-Identifier: GPL-2.0
Dual license new bindings please: (GPL-2.0-only OR BSD-2-Clause)
With that,
Reviewed-by: Rob Herring
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/iio/accel/adi,adis16240.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: ADIS16240 Programmable Impact Sensor and Recorder driver
> +
> +maintainers:
> + - Alexandru Ardelean
> +
> +description: |
> + ADIS16240 Programmable Impact Sensor and Recorder driver that supports
> + SPI interface.
> +https://www.analog.com/en/products/adis16240.html
> +
> +properties:
> + compatible:
> +enum:
> + - adi,adis16240
> +
> + reg:
> +maxItems: 1
> +
> + interrupts:
> +maxItems: 1
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> +
> +examples:
> + - |
> +#include
> +#include
> +spi0 {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +/* Example for a SPI device node */
> +accelerometer@0 {
> +compatible = "adi,adis16240";
> +reg = <0>;
> +spi-max-frequency = <250>;
> +interrupt-parent = <&gpio0>;
> +interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
> +};
> +};
> --
> 2.24.0
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: wfx: fix reset GPIO polarity
On Thu, Dec 05, 2019 at 02:08:23PM +, Jérôme Pouiller wrote:
> On Wednesday 4 December 2019 17:59:46 CET Michał Mirosław wrote:
> > Driver inverts meaning of GPIO_ACTIVE_LOW/HIGH. Fix it to prevent
> > confusion.
> >
> > Signed-off-by: Michał Mirosław
> > ---
> > drivers/staging/wfx/bus_spi.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/staging/wfx/bus_spi.c b/drivers/staging/wfx/bus_spi.c
> > index ab0cda1e124f..73d0157a86ba 100644
> > --- a/drivers/staging/wfx/bus_spi.c
> > +++ b/drivers/staging/wfx/bus_spi.c
> > @@ -199,9 +199,9 @@ static int wfx_spi_probe(struct spi_device *func)
> > if (!bus->gpio_reset) {
> > dev_warn(&func->dev, "try to load firmware anyway\n");
> > } else {
> > - gpiod_set_value(bus->gpio_reset, 0);
> > - udelay(100);
> > gpiod_set_value(bus->gpio_reset, 1);
> > + udelay(100);
> > + gpiod_set_value(bus->gpio_reset, 0);
> > udelay(2000);
> > }
> Hello Michał,
>
> I did not find real consensus in kernel code. My personal taste would
> be to keep this gpio "ACTIVE_HIGH" and rename it gpio_nreset. What do
> you think about it?
>
> (in add, this solution would explicitly change the name of the DT
> attribute instead of changing the semantic of the existing attribute)
As a user (board developer) I would expect that DT describes the
GPIO meaning directly: so when I specify GPIO_ACTIVE_HIGH flag I also
wire up the board so that outputing 1 would match the active state of
the chip's signal (that might be inverted for some reason). I think we
should stick to what is said in Documentation/devicetree/bindings/gpio.txt
(section 1.1).
Since this is a new driver in kernel I would prefer to fix it at the start.
Changing the name of the GPIO would also be ok, but since there is no DT
binding yet, I guess there will come up an issue of 'compatible' string
format that does not match 'vendor,chip' now, so we can use the difference
for backwards compatibility with out-of-tree driver if needed.
Best Regards,
Michał Mirosław
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: wfx: fix reset GPIO polarity
On Wednesday 4 December 2019 17:59:46 CET Michał Mirosław wrote:
> Driver inverts meaning of GPIO_ACTIVE_LOW/HIGH. Fix it to prevent
> confusion.
>
> Signed-off-by: Michał Mirosław
> ---
> drivers/staging/wfx/bus_spi.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/wfx/bus_spi.c b/drivers/staging/wfx/bus_spi.c
> index ab0cda1e124f..73d0157a86ba 100644
> --- a/drivers/staging/wfx/bus_spi.c
> +++ b/drivers/staging/wfx/bus_spi.c
> @@ -199,9 +199,9 @@ static int wfx_spi_probe(struct spi_device *func)
> if (!bus->gpio_reset) {
> dev_warn(&func->dev, "try to load firmware anyway\n");
> } else {
> - gpiod_set_value(bus->gpio_reset, 0);
> - udelay(100);
> gpiod_set_value(bus->gpio_reset, 1);
> + udelay(100);
> + gpiod_set_value(bus->gpio_reset, 0);
> udelay(2000);
> }
Hello Michał,
I did not find real consensus in kernel code. My personal taste would
be to keep this gpio "ACTIVE_HIGH" and rename it gpio_nreset. What do
you think about it?
(in add, this solution would explicitly change the name of the DT
attribute instead of changing the semantic of the existing attribute)
--
Jérôme Pouiller
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[no subject]
help Tim Magee Software Engineer Tel: +44 1223 723723 nCipher Security One Station Square Cambridge CB1 2GA United Kingdom ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4] dt-bindings: iio: accel: add binding documentation for ADIS16240
On Wed, 2019-12-04 at 17:00 +, Mark Brown wrote:
> On Wed, Dec 04, 2019 at 07:18:15AM +, Ardelean, Alexandru wrote:
>
> > One example (for spi-cpha):
> > if (of_property_read_u32(nc, "spi-cpha", &tmp) == 0) {
> > spi->mode |= SPI_CPHA_OVERRIDE;
> > if (tmp)
> > spi->mode |= SPI_CPHA;
>
> We could also do this with a separate flag saying that the wire
> format is forced from DT rather than having one per setting.
>
I will admit that [since you seem to incline towards this approach], I am
also inclined to consider it over the spi-mode-conv driver.
And also since you're saying that the driver would be harder to achieve.
I'll see about an implementation for this flag and come back for a review
[on it].
[Until then] I also owe you some more "delay_usecs" cleanup in other
subsystems.
Thanks
Alex
> > Or maybe, a more complete solution would be an "spi-mode-conv" driver.
> > Similar to the fixed-factor-clock clk driver, which just does a
> > computation
> > based on values from the DT.
> > To tell the truth, this would be a great idea, because we have
> > something
> > like a passive 3-wire-to-4-wire HDL converter. This requires that the
> > driver be configured in 3-wire mode, the SPI controller in normal 4-
> > wire.
> > That's because the SPI framework does a validation of the supported
> > modes
> > (for the SPI controller) and invalidates what the device wants (which
> > is
> > very reasonable).
>
> This is harder to achieve here because we don't have drivers for
> random bits of the wire format...
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] media: meson: add missing allocation failure check on new_buf
On (19/12/04 14:11), Colin King wrote: [..] > diff --git a/drivers/staging/media/meson/vdec/vdec.c > b/drivers/staging/media/meson/vdec/vdec.c > index 0a1a04fd5d13..8dd1396909d7 100644 > --- a/drivers/staging/media/meson/vdec/vdec.c > +++ b/drivers/staging/media/meson/vdec/vdec.c > @@ -133,6 +133,8 @@ vdec_queue_recycle(struct amvdec_session *sess, struct > vb2_buffer *vb) > struct amvdec_buffer *new_buf; > > new_buf = kmalloc(sizeof(*new_buf), GFP_KERNEL); > + if (!new_buf) > + return; > new_buf->vb = vb; So the buffer is not getting recycled? IOW is leaked? -ss ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
