>
> Note that the WF200 has no valid SDIO VID/PID. Therefore, we match DT
> rather than on the SDIO VID/PID.
>
> Signed-off-by: Jérôme Pouiller
Reviewed-by: Pali Rohár
> ---
> drivers/mmc/core/quirks.h | 5 +
> drivers/staging/wfx/bus_sdio.c | 3 ---
> 2 f
rely on the DT rather than on
> the SDIO IDs to probe the device).
>
> To avoid any confusion, remove the definitions SDIO_*_ID_SILABS* and use
> raw values.
>
> Signed-off-by: Jérôme Pouiller
Reviewed-by: Pali Rohár
> ---
> drivers/staging/wfx/bus_sdio.c | 5 ++--
On Tuesday 11 January 2022 18:14:05 Jerome Pouiller wrote:
> +/* The device needs data about the antenna configuration. This information in
> + * provided by PDS (Platform Data Set, this is the wording used in WF200
> + * documentation) files. For hardware integrators, the full process to create
>
On Wednesday 12 January 2022 17:45:45 Jérôme Pouiller wrote:
> On Wednesday 12 January 2022 12:43:32 CET Pali Rohár wrote:
> >
> > On Wednesday 12 January 2022 12:18:58 Jérôme Pouiller wrote:
> > > On Wednesday 12 January 2022 11:58:59 CET Pali Rohár wrote:
> > >
On Wednesday 12 January 2022 13:06:17 Greg Kroah-Hartman wrote:
> On Wed, Jan 12, 2022 at 12:43:32PM +0100, Pali Rohár wrote:
> > Btw, is there any project which maintains SDIO ids, like there is
> > pci-ids.ucw.cz for PCI or www.linux-usb.org/usb-ids.html for USB?
>
> Both o
On Wednesday 12 January 2022 12:18:58 Jérôme Pouiller wrote:
> On Wednesday 12 January 2022 11:58:59 CET Pali Rohár wrote:
> > On Tuesday 11 January 2022 18:14:08 Jerome Pouiller wrote:
> > > +static const struct sdio_device_id wfx_sdio_ids[] = {
> > > + { SDIO_D
On Tuesday 11 January 2022 18:14:08 Jerome Pouiller wrote:
> +static const struct sdio_device_id wfx_sdio_ids[] = {
> + { SDIO_DEVICE(SDIO_VENDOR_ID_SILABS, SDIO_DEVICE_ID_SILABS_WF200) },
> + { },
> +};
Hello! Is this table still required?
> +MODULE_DEVICE_TABLE(sdio, wfx_sdio_ids);
> +
Ulf Hansson wrote:
> >> > > On Thu, 30 Sept 2021 at 19:06, Pali Rohár wrote:
> >> > > > On Thursday 30 September 2021 18:51:09 Jérôme Pouiller wrote:
> >> > > > > On Thursday 30 September 2021 12:07:55 CEST Ulf Hanss
Hello Rob! Could you look at issue below to represent antenna (pds)
firmware file requirement for this driver in DTS file?
On Thursday 07 October 2021 11:16:29 Kalle Valo wrote:
> Pali Rohár writes:
>
> > On Friday 01 October 2021 17:09:41 Jérôme Pouiller wrote:
> >> On Fri
On Thursday 07 October 2021 11:19:10 Kalle Valo wrote:
> Jérôme Pouiller writes:
>
> > On Friday 1 October 2021 18:08:32 CEST Pali Rohár wrote:
> >> On Friday 01 October 2021 17:09:41 Jérôme Pouiller wrote:
> >> > On Friday 1 October 2021 13:58:38 CEST Kalle Val
On Friday 01 October 2021 17:17:52 Jérôme Pouiller wrote:
> On Friday 1 October 2021 11:55:33 CEST Kalle Valo wrote:
> > CAUTION: This email originated from outside of the organization. Do not
> > click links or open attachments unless you recognize the sender and know
> > the content is safe.
>
On Friday 01 October 2021 17:09:41 Jérôme Pouiller wrote:
> On Friday 1 October 2021 13:58:38 CEST Kalle Valo wrote:
> > Jerome Pouiller writes:
> >
> > > From: Jérôme Pouiller
> > >
> > > Signed-off-by: Jérôme Pouiller
> >
> > [...]
> >
> > > +static int get_firmware(struct wfx_dev *wdev, u3
On Thursday 30 September 2021 18:51:09 Jérôme Pouiller wrote:
> Hello Ulf,
>
> On Thursday 30 September 2021 12:07:55 CEST Ulf Hansson wrote:
> > On Mon, 20 Sept 2021 at 18:12, Jerome Pouiller
> > wrote:
> > >
> > > From: Jérôme Pouiller
> > >
> > > Signed-off-by: Jérôme Pouiller
> > > ---
> >
; the DT.
>
> Signed-off-by: Jérôme Pouiller
Looks good!
Acked-by: Pali Rohár
> ---
> include/linux/mmc/sdio_ids.h | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/include/linux/mmc/sdio_ids.h b/include/linux/mmc/sdio_ids.h
> index 12036619346c..20a48162f7f
On Wednesday 14 October 2020 13:52:15 Jérôme Pouiller wrote:
> Hello Pali,
>
> On Tuesday 13 October 2020 22:11:56 CEST Pali Rohár wrote:
> > Hello!
> >
> > On Monday 12 October 2020 12:46:32 Jerome Pouiller wrote:
> > > +#define SDIO_VENDOR_ID
Hello!
On Monday 12 October 2020 12:46:32 Jerome Pouiller wrote:
> +#define SDIO_VENDOR_ID_SILABS0x
> +#define SDIO_DEVICE_ID_SILABS_WF200 0x1000
> +static const struct sdio_device_id wfx_sdio_ids[] = {
> + { SDIO_DEVICE(SDIO_VENDOR_ID_SILABS, SDIO_DEVICE_ID_SILABS_WF200) },
Plea
(adding Ulf)
On Wednesday 01 July 2020 09:55:15 Pali Rohár wrote:
> On Tuesday 30 June 2020 03:17:01 ajay.kat...@microchip.com wrote:
> > On 29/06/20 6:56 pm, Pali Rohár wrote:
> > > EXTERNAL EMAIL: Do not click links or open attachments unless you know
> > > the cont
On Tuesday 30 June 2020 03:17:01 ajay.kat...@microchip.com wrote:
> On 29/06/20 6:56 pm, Pali Rohár wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> > content is safe
> >
> > On Tuesday 23 June 2020 11:00:04 ajay.kat...@microchip
On Tuesday 23 June 2020 11:00:04 ajay.kat...@microchip.com wrote:
> This patch series is to review and move wilc1000 driver out of staging.
> Most of the review comments received in [1] & [2] are addressed in the
> latest code.
> Please review and provide your inputs.
Hello Ajay! Could you please
On Monday 27 April 2020 11:49:13 Sasha Levin wrote:
> On Tue, Apr 21, 2020 at 11:30:45PM +0200, Pali Rohár wrote:
> > On Thursday 13 February 2020 16:18:47 Sasha Levin wrote:
> > > On Thu, Feb 13, 2020 at 01:06:56AM +0100, Pali Rohár wrote:
> > > > In released exFA
On Thursday 13 February 2020 16:18:47 Sasha Levin wrote:
> On Thu, Feb 13, 2020 at 01:06:56AM +0100, Pali Rohár wrote:
> > In released exFAT specification is not written how are Unicode code
> > points above U+ represented in exFAT upcase table. Normally in
> > UTF-16 ar
his into the tree in
> the first place, it was greatly appreciated.
>
> Cc: Valdis Kletnieks
> Cc: Pali Rohár
> Cc: Stephen Rothwell
> Cc: Al Viro
> Cc: Namjae Jeon
> Cc: Sungjong Seo
> Cc: Christoph Hellwig
> Signed-off-by: Greg Kroah-Hartman
Acked-by: Pal
circumstances.
Main problem is that we do not know what "full TexFAT support" means as
currently it is secret.
My original question for TexFAT was also because of NumberOfFats set to
2 is according to released exFAT specification possible only for TexFAT
volumes.
And from readi
Hello!
On Thursday 17 October 2019 09:50:08 Pali Rohár wrote:
> On Wednesday 16 October 2019 16:33:17 Sasha Levin wrote:
> > On Wed, Oct 16, 2019 at 06:03:49PM +0200, Pali Rohár wrote:
> > > On Wednesday 16 October 2019 10:31:13 Sasha Levin wrote:
> > > > On Wed, Oc
https://patents.google.com/patent/US20150370821 which
was there publicly available for a while. And similar/same? copy was
available on the following site https://www.ntfs.com/exfat-overview.htm
--
Pali Rohár
pali.ro...@gmail.com
___
devel mailing l
s
first. And all operations are done on Secondary FAT and then is
Secondary FAT copied to Primary. This is backward compatible with
systems which operates only with first primary FAT. And other systems
which see both FATs can benefit from redundancy/recovery.
--
Pali Rohár
pali
On Wednesday 16 October 2019 16:33:17 Sasha Levin wrote:
> On Wed, Oct 16, 2019 at 06:03:49PM +0200, Pali Rohár wrote:
> > On Wednesday 16 October 2019 10:31:13 Sasha Levin wrote:
> > > On Wed, Oct 16, 2019 at 04:03:53PM +0200, Pali Rohár wrote:
> > > > On Friday 30 A
On Wednesday 16 October 2019 09:22:11 Greg Kroah-Hartman wrote:
> On Wed, Oct 16, 2019 at 06:03:49PM +0200, Pali Rohár wrote:
> > > Can I assume you will be implementing TexFAT support once the spec is
> > > available?
> >
> > I cannot promise that I would implem
On Wednesday 16 October 2019 10:31:13 Sasha Levin wrote:
> On Wed, Oct 16, 2019 at 04:03:53PM +0200, Pali Rohár wrote:
> > On Friday 30 August 2019 09:56:47 Pali Rohár wrote:
> > > On Thursday 29 August 2019 19:35:06 Sasha Levin wrote:
> > > > With regards to missing
On Friday 30 August 2019 09:56:47 Pali Rohár wrote:
> On Thursday 29 August 2019 19:35:06 Sasha Levin wrote:
> > With regards to missing specs/docs/whatever - our main concern with this
> > release was that we want full interoperability, which is why the spec
> > was made
On Friday 30 August 2019 08:40:06 Christoph Hellwig wrote:
> On Thu, Aug 29, 2019 at 10:56:31PM +0200, Pali Rohár wrote:
> > In my opinion, proper way should be to implement exFAT support into
> > existing fs/fat/ code instead of replacing whole vfat/msdosfs by this
> >
ive merits
... but is this advantage such big that it should be merged even due to
"horrible" code quality and lot of code/functionality duplication?
In similar way there should be discussion about these pros and cons.
--
Pali Rohár
pali.ro...@gmail.com
e labels and I found more bugs in current implementations
(mtools, dosfstools, util-linux and even in fastfat.sys). Some
references are on: https://www.spinics.net/lists/kernel/msg2640891.html
Fixes for mtools, dosfstools and util-linux were already applied and fix
for MS's fastfat.sys is pe
do not need two different implementation of
VFAT32.
So I'm a bit sceptical about usefulness of this exfat code/driver, if it
makes any sense to have it even in staging.
--
Pali Rohár
pali.ro...@gmail.com
signature.asc
Description: PGP signature
value is only valid
> > for
> > TexFAT volumes
>
> I think we're OK if we just set ActiveFat to 0 and NumberOfFats to 1.
But this degrades whole FS. Even FAT32 uses two FAT tables due to big
factor of brokenness and fsck takes care of it when repairing.
There is not too
xistence of such documentation until
somebody implement it and do some testing against MS own implementation.
--
Pali Rohár
pali.ro...@gmail.com
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
ndex+i] &
> BCM2048_RDS_CRC_MASK) == BCM2048_RDS_CRC_UNRECOVARABLE)
> tmpbuf[i+2] |= 0x80;
Hi! I think that code after this change is less readable as before.
--
Pali Rohár
pali.ro...@gmail.com
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
registration:
> video_unregister_device(&bdev->videodev);
> - skip_release = 1;
> free_irq:
> if (client->irq)
> free_irq(client->irq, bdev);
Looks good to me, so
Acked-by: Pali Rohár
--
Pali Rohár
pali.ro...@gmail.com
__
changed, 1 insertion(+), 3 deletions(-)
>
Looks good,
Acked-by: Pali Rohár
--
Pali Rohár
pali.ro...@gmail.com
signature.asc
Description: This is a digitally signed message part.
___
devel mailing list
de...@linuxdriverproject.org
http://driverde
39 matches
Mail list logo
