[PATCH] staging: exfat: fix spelling mistake
CHECK: 'propogate' may be misspelled - perhaps 'propagate'?
FILE: drivers/staging/exfat/exfat_super.c:1484
CHECK: 'propogate' may be misspelled - perhaps 'propagate'?
FILE: drivers/staging/exfat/exfat_super.c:1551
Signed-off-by: Susarla Nikhilesh
---
drivers/staging/exfat/exfat_super.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/exfat/exfat_super.c
b/drivers/staging/exfat/exfat_super.c
index 6e481908c59f..d1c1e50fb492 100644
--- a/drivers/staging/exfat/exfat_super.c
+++ b/drivers/staging/exfat/exfat_super.c
@@ -1481,7 +1481,7 @@ static int ffsReadStat(struct inode *inode, struct
dir_entry_t *info)
count = count_dos_name_entries(sb, &dir, TYPE_DIR);
if (count < 0) {
- ret = count; /* propogate error upward */
+ ret = count; /* propagate error upward */
goto out;
}
info->NumSubdirs = count;
@@ -1548,7 +1548,7 @@ static int ffsReadStat(struct inode *inode, struct
dir_entry_t *info)
count = count_dos_name_entries(sb, &dir, TYPE_DIR);
if (count < 0) {
- ret = count; /* propogate error upward */
+ ret = count; /* propagate error upward */
goto out;
}
info->NumSubdirs += count;
--
2.17.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: BUG: unable to handle kernel paging request in ion_heap_clear_pages
syzbot has found a reproducer for the following crash on: HEAD commit:76bb8b05 Merge tag 'kbuild-v5.5' of git://git.kernel.org/p.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=159d0f36e0 kernel config: https://syzkaller.appspot.com/x/.config?x=dd226651cb0f364b dashboard link: https://syzkaller.appspot.com/bug?extid=be6ccf3081ce8afd1b56 compiler: gcc (GCC) 9.0.0 20181231 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=171f677ae0 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=11db659ce0 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+be6ccf3081ce8afd1...@syzkaller.appspotmail.com BUG: unable to handle page fault for address: f5200068 #PF: supervisor read access in kernel mode #PF: error_code(0x) - not-present page PGD 21ffee067 P4D 21ffee067 PUD aa51c067 PMD a8372067 PTE 0 Oops: [#1] PREEMPT SMP KASAN CPU: 1 PID: 3666 Comm: ion_system_heap Not tainted 5.4.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:memory_is_nonzero mm/kasan/generic.c:121 [inline] RIP: 0010:memory_is_poisoned_n mm/kasan/generic.c:135 [inline] RIP: 0010:memory_is_poisoned mm/kasan/generic.c:166 [inline] RIP: 0010:check_memory_region_inline mm/kasan/generic.c:182 [inline] RIP: 0010:check_memory_region+0x9c/0x1a0 mm/kasan/generic.c:192 Code: c9 4d 0f 49 c1 49 c1 f8 03 45 85 c0 0f 84 10 01 00 00 41 83 e8 01 4e 8d 44 c0 08 eb 0d 48 83 c0 08 4c 39 c0 0f 84 a7 00 00 00 <48> 83 38 00 74 ed 4c 8d 40 08 eb 09 48 83 c0 01 49 39 c0 74 53 80 RSP: 0018:c9000cf87ab8 EFLAGS: 00010212 RAX: f5200068 RBX: f52000681600 RCX: 85d95629 RDX: 0001 RSI: b000 RDI: c9000340 RBP: c9000cf87ad0 R08: f52000681600 R09: 1600 R10: f520006815ff R11: c9000340afff R12: f5200068 R13: b000 R14: R15: c9000cf87d08 FS: () GS:8880ae90() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: f5200068 CR3: a6755000 CR4: 001406e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: memset+0x24/0x40 mm/kasan/common.c:107 memset include/linux/string.h:365 [inline] ion_heap_clear_pages+0x49/0x70 drivers/staging/android/ion/ion_heap.c:106 ion_heap_sglist_zero+0x245/0x270 drivers/staging/android/ion/ion_heap.c:130 ion_heap_buffer_zero+0xf5/0x150 drivers/staging/android/ion/ion_heap.c:145 ion_system_heap_free+0x1eb/0x250 drivers/staging/android/ion/ion_system_heap.c:163 ion_buffer_destroy+0x159/0x2d0 drivers/staging/android/ion/ion.c:93 ion_heap_deferred_free+0x29d/0x630 drivers/staging/android/ion/ion_heap.c:239 kthread+0x361/0x430 kernel/kthread.c:255 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352 Modules linked in: CR2: f5200068 ---[ end trace 6d0e26662c48296a ]--- RIP: 0010:memory_is_nonzero mm/kasan/generic.c:121 [inline] RIP: 0010:memory_is_poisoned_n mm/kasan/generic.c:135 [inline] RIP: 0010:memory_is_poisoned mm/kasan/generic.c:166 [inline] RIP: 0010:check_memory_region_inline mm/kasan/generic.c:182 [inline] RIP: 0010:check_memory_region+0x9c/0x1a0 mm/kasan/generic.c:192 Code: c9 4d 0f 49 c1 49 c1 f8 03 45 85 c0 0f 84 10 01 00 00 41 83 e8 01 4e 8d 44 c0 08 eb 0d 48 83 c0 08 4c 39 c0 0f 84 a7 00 00 00 <48> 83 38 00 74 ed 4c 8d 40 08 eb 09 48 83 c0 01 49 39 c0 74 53 80 RSP: 0018:c9000cf87ab8 EFLAGS: 00010212 RAX: f5200068 RBX: f52000681600 RCX: 85d95629 RDX: 0001 RSI: b000 RDI: c9000340 RBP: c9000cf87ad0 R08: f52000681600 R09: 1600 R10: f520006815ff R11: c9000340afff R12: f5200068 R13: b000 R14: R15: c9000cf87d08 FS: () GS:8880ae90() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: f5200068 CR3: a6755000 CR4: 001406e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 ___ 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 Tue, 3 Dec 2019 16:38:50 + Mark Brown wrote: > On Sun, Dec 01, 2019 at 11:40:32AM +, Jonathan Cameron wrote: > > > +CC Mark as we probably need a more general view point on > > the question of whether SPI mode should be enforced by binding > > or in the driver. > > Not sure I see the question here, I think I was missing a bit of > the conversation? It's perfectly fine for a driver to specify a > mode, if the hardware always uses some unusual mode then there's > no sense in forcing every single DT to set the same mode. On the > other hand if there's some configuration for the driver that was > handling some board specific configuration that there's already > some generic SPI support for setting then it seems odd to have a > custom driver specific configuration mechanism. > If the driver picks a mode because that's what it says on the datasheet it prevents odd board configurations from working. The question becomes whether it makes sense in general to assume those odd board conditions don't exist until we actually have one, or to assume that they might and push the burden on to all DT files. Traditionally in IIO at least we've mostly taken the view the DT should be right and complete and had bindings state what normal parameters must be for it to work (assuming no inverters etc) If we encode it in the driver, and we later meet such a board we end up with a custom dance to query the DT parameters again and only override if present. We can't rely on the core SPI handling because I don't think there is any means of specifying a default. We can adopt the view that in general these weird boards with inverters are weird and just handle them when they occur. Sounds like that is your preference, at least for new parts. For old ones we have no idea if there are boards out there using them with inverters so easiest is probably to just carry on putting them in the DT bindings. Jonathan ___ 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 Sun, Dec 01, 2019 at 11:40:32AM +, Jonathan Cameron wrote: > +CC Mark as we probably need a more general view point on > the question of whether SPI mode should be enforced by binding > or in the driver. Not sure I see the question here, I think I was missing a bit of the conversation? It's perfectly fine for a driver to specify a mode, if the hardware always uses some unusual mode then there's no sense in forcing every single DT to set the same mode. On the other hand if there's some configuration for the driver that was handling some board specific configuration that there's already some generic SPI support for setting then it seems odd to have a custom driver specific configuration mechanism. signature.asc Description: PGP signature ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: vchiq: call unregister_chrdev_region() when driver registration fails
On Tue, Dec 03, 2019 at 10:39:21AM -0500, Marcelo Diop-Gonzalez wrote:
> This undoes the previous call to alloc_chrdev_region() on failure,
> and is probably what was meant originally given the label name.
>
> Signed-off-by: Marcelo Diop-Gonzalez
Fixes: 187ac53e590c ("staging: vchiq_arm: rework probe and init functions")
Reviewed-by: Dan Carpenter
Thanks!
regards,
dan carpenter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/2] pi433: Fix indentation according to coding style
Fix indentation so that no line exceeds the 80 character border.
Co-developed-by: Daniel Bauer
Signed-off-by: Daniel Bauer
Signed-off-by: Sven Leykauf
---
drivers/staging/pi433/rf69.c | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/staging/pi433/rf69.c b/drivers/staging/pi433/rf69.c
index 7d86bb8be245..6b13f92028c7 100644
--- a/drivers/staging/pi433/rf69.c
+++ b/drivers/staging/pi433/rf69.c
@@ -176,20 +176,20 @@ int rf69_set_modulation_shaping(struct spi_device *spi,
switch (mod_shaping) {
case SHAPING_OFF:
return rf69_read_mod_write(spi, REG_DATAMODUL,
-
MASK_DATAMODUL_MODULATION_SHAPE,
-
DATAMODUL_MODULATION_SHAPE_NONE);
+ MASK_DATAMODUL_MODULATION_SHAPE,
+ DATAMODUL_MODULATION_SHAPE_NONE);
case SHAPING_1_0:
return rf69_read_mod_write(spi, REG_DATAMODUL,
-
MASK_DATAMODUL_MODULATION_SHAPE,
-
DATAMODUL_MODULATION_SHAPE_1_0);
+ MASK_DATAMODUL_MODULATION_SHAPE,
+ DATAMODUL_MODULATION_SHAPE_1_0);
case SHAPING_0_5:
return rf69_read_mod_write(spi, REG_DATAMODUL,
-
MASK_DATAMODUL_MODULATION_SHAPE,
-
DATAMODUL_MODULATION_SHAPE_0_5);
+ MASK_DATAMODUL_MODULATION_SHAPE,
+ DATAMODUL_MODULATION_SHAPE_0_5);
case SHAPING_0_3:
return rf69_read_mod_write(spi, REG_DATAMODUL,
-
MASK_DATAMODUL_MODULATION_SHAPE,
-
DATAMODUL_MODULATION_SHAPE_0_3);
+ MASK_DATAMODUL_MODULATION_SHAPE,
+ DATAMODUL_MODULATION_SHAPE_0_3);
default:
dev_dbg(&spi->dev, "set: illegal input param");
return -EINVAL;
@@ -198,16 +198,16 @@ int rf69_set_modulation_shaping(struct spi_device *spi,
switch (mod_shaping) {
case SHAPING_OFF:
return rf69_read_mod_write(spi, REG_DATAMODUL,
-
MASK_DATAMODUL_MODULATION_SHAPE,
-
DATAMODUL_MODULATION_SHAPE_NONE);
+ MASK_DATAMODUL_MODULATION_SHAPE,
+ DATAMODUL_MODULATION_SHAPE_NONE);
case SHAPING_BR:
return rf69_read_mod_write(spi, REG_DATAMODUL,
-
MASK_DATAMODUL_MODULATION_SHAPE,
-
DATAMODUL_MODULATION_SHAPE_BR);
+ MASK_DATAMODUL_MODULATION_SHAPE,
+ DATAMODUL_MODULATION_SHAPE_BR);
case SHAPING_2BR:
return rf69_read_mod_write(spi, REG_DATAMODUL,
-
MASK_DATAMODUL_MODULATION_SHAPE,
-
DATAMODUL_MODULATION_SHAPE_2BR);
+ MASK_DATAMODUL_MODULATION_SHAPE,
+ DATAMODUL_MODULATION_SHAPE_2BR);
default:
dev_dbg(&spi->dev, "set: illegal input param");
return -EINVAL;
--
2.20.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 2/2] pi433: Fix indentation according to coding style
Fix indentation so that no line exceeds the 80 character border.
Put the return command one line under the default case, so it looks
better.
Co-developed-by: Daniel Bauer
Signed-off-by: Daniel Bauer
Signed-off-by: Sven Leykauf
---
drivers/staging/pi433/rf69.c | 56
1 file changed, 37 insertions(+), 19 deletions(-)
diff --git a/drivers/staging/pi433/rf69.c b/drivers/staging/pi433/rf69.c
index 6b13f92028c7..6cdd46682aa9 100644
--- a/drivers/staging/pi433/rf69.c
+++ b/drivers/staging/pi433/rf69.c
@@ -596,42 +596,60 @@ bool rf69_get_flag(struct spi_device *spi, enum flag flag)
{
switch (flag) {
case mode_switch_completed:
- return (rf69_read_reg(spi, REG_IRQFLAGS1) &
MASK_IRQFLAGS1_MODE_READY);
+ return (rf69_read_reg(spi, REG_IRQFLAGS1) &
+ MASK_IRQFLAGS1_MODE_READY);
case ready_to_receive:
- return (rf69_read_reg(spi, REG_IRQFLAGS1) &
MASK_IRQFLAGS1_RX_READY);
+ return (rf69_read_reg(spi, REG_IRQFLAGS1) &
+ MASK_IRQFLAGS1_RX_READY);
case ready_to_send:
- return (rf69_read_reg(spi, REG_IRQFLAGS1) &
MASK_IRQFLAGS1_TX_READY);
+ return (rf69_read_reg(spi, REG_IRQFLAGS1) &
+ MASK_IRQFLAGS1_TX_READY);
case pll_locked:
- return (rf69_read_reg(spi, REG_IRQFLAGS1) &
MASK_IRQFLAGS1_PLL_LOCK);
+ return (rf69_read_reg(spi, REG_IRQFLAGS1) &
+ MASK_IRQFLAGS1_PLL_LOCK);
case rssi_exceeded_threshold:
- return (rf69_read_reg(spi, REG_IRQFLAGS1) &
MASK_IRQFLAGS1_RSSI);
+ return (rf69_read_reg(spi, REG_IRQFLAGS1) &
+ MASK_IRQFLAGS1_RSSI);
case timeout:
- return (rf69_read_reg(spi, REG_IRQFLAGS1) &
MASK_IRQFLAGS1_TIMEOUT);
+ return (rf69_read_reg(spi, REG_IRQFLAGS1) &
+ MASK_IRQFLAGS1_TIMEOUT);
case automode:
- return (rf69_read_reg(spi, REG_IRQFLAGS1) &
MASK_IRQFLAGS1_AUTOMODE);
+ return (rf69_read_reg(spi, REG_IRQFLAGS1) &
+ MASK_IRQFLAGS1_AUTOMODE);
case sync_address_match:
- return (rf69_read_reg(spi, REG_IRQFLAGS1) &
MASK_IRQFLAGS1_SYNC_ADDRESS_MATCH);
+ return (rf69_read_reg(spi, REG_IRQFLAGS1) &
+ MASK_IRQFLAGS1_SYNC_ADDRESS_MATCH);
case fifo_full:
- return (rf69_read_reg(spi, REG_IRQFLAGS2) &
MASK_IRQFLAGS2_FIFO_FULL);
+ return (rf69_read_reg(spi, REG_IRQFLAGS2) &
+ MASK_IRQFLAGS2_FIFO_FULL);
/*
* case fifo_not_empty:
- * return (rf69_read_reg(spi, REG_IRQFLAGS2) &
MASK_IRQFLAGS2_FIFO_NOT_EMPTY);
+ * return (rf69_read_reg(spi, REG_IRQFLAGS2) &
+ * MASK_IRQFLAGS2_FIFO_NOT_EMPTY);
*/
case fifo_empty:
- return !(rf69_read_reg(spi, REG_IRQFLAGS2) &
MASK_IRQFLAGS2_FIFO_NOT_EMPTY);
+ return !(rf69_read_reg(spi, REG_IRQFLAGS2) &
+ MASK_IRQFLAGS2_FIFO_NOT_EMPTY);
case fifo_level_below_threshold:
- return (rf69_read_reg(spi, REG_IRQFLAGS2) &
MASK_IRQFLAGS2_FIFO_LEVEL);
+ return (rf69_read_reg(spi, REG_IRQFLAGS2) &
+ MASK_IRQFLAGS2_FIFO_LEVEL);
case fifo_overrun:
- return (rf69_read_reg(spi, REG_IRQFLAGS2) &
MASK_IRQFLAGS2_FIFO_OVERRUN);
+ return (rf69_read_reg(spi, REG_IRQFLAGS2) &
+ MASK_IRQFLAGS2_FIFO_OVERRUN);
case packet_sent:
- return (rf69_read_reg(spi, REG_IRQFLAGS2) &
MASK_IRQFLAGS2_PACKET_SENT);
+ return (rf69_read_reg(spi, REG_IRQFLAGS2) &
+ MASK_IRQFLAGS2_PACKET_SENT);
case payload_ready:
- return (rf69_read_reg(spi, REG_IRQFLAGS2) &
MASK_IRQFLAGS2_PAYLOAD_READY);
+ return (rf69_read_reg(spi, REG_IRQFLAGS2) &
+ MASK_IRQFLAGS2_PAYLOAD_READY);
case crc_ok:
- return (rf69_read_reg(spi, REG_IRQFLAGS2) &
MASK_IRQFLAGS2_CRC_OK);
+ return (rf69_read_reg(spi, REG_IRQFLAGS2) &
+ MASK_IRQFLAGS2_CRC_OK);
case battery_low:
- return (rf69_read_reg(spi, REG_IRQFLAGS2) &
MASK_IRQFLAGS2_LOW_BAT);
- default: return false;
+ return (rf69_read_reg(spi, REG_IRQFLAGS2) &
+ MASK_IRQFLAGS2_LOW_BAT);
+ default:
+ return false;
}
}
@@ -725,7 +743,7 @@ int rf69_set_packet_format(struct spi_device *spi,
MASK_PACKETCONFIG1_PACKET_FORMAT_VARIABLE);
case packet_length_fix:
return
Re: [PATCH 1/2] pi433: Fix indentation according to coding style
On Tue, Dec 03, 2019 at 06:54:47PM +0100, Sven Leykauf wrote:
> Fix indentation so that no line exceeds the 80 character border.
>
> Co-developed-by: Daniel Bauer
> Signed-off-by: Daniel Bauer
> Signed-off-by: Sven Leykauf
> ---
> drivers/staging/pi433/rf69.c | 28 ++--
> 1 file changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/staging/pi433/rf69.c b/drivers/staging/pi433/rf69.c
> index 7d86bb8be245..6b13f92028c7 100644
> --- a/drivers/staging/pi433/rf69.c
> +++ b/drivers/staging/pi433/rf69.c
> @@ -176,20 +176,20 @@ int rf69_set_modulation_shaping(struct spi_device *spi,
> switch (mod_shaping) {
> case SHAPING_OFF:
> return rf69_read_mod_write(spi, REG_DATAMODUL,
> -
> MASK_DATAMODUL_MODULATION_SHAPE,
> -
> DATAMODUL_MODULATION_SHAPE_NONE);
> + MASK_DATAMODUL_MODULATION_SHAPE,
> + DATAMODUL_MODULATION_SHAPE_NONE);
It was a choice to align with the ( or be less than 80 characters and
the original author decided to go over 80 characters... They're both
equally valid options, but we generally let the original author choose
pick which one they prefer. So just leave it as is.
There are better ways to write this function which avoid both problems...
regards,
dan carpenter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 2/2] pi433: Fix indentation according to coding style
You can't have two patches with the same subject.
On Tue, Dec 03, 2019 at 06:54:49PM +0100, Sven Leykauf wrote:
> Fix indentation so that no line exceeds the 80 character border.
>
> Put the return command one line under the default case, so it looks
> better.
>
> Co-developed-by: Daniel Bauer
> Signed-off-by: Daniel Bauer
> Signed-off-by: Sven Leykauf
> ---
> drivers/staging/pi433/rf69.c | 56
> 1 file changed, 37 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/staging/pi433/rf69.c b/drivers/staging/pi433/rf69.c
> index 6b13f92028c7..6cdd46682aa9 100644
> --- a/drivers/staging/pi433/rf69.c
> +++ b/drivers/staging/pi433/rf69.c
> @@ -596,42 +596,60 @@ bool rf69_get_flag(struct spi_device *spi, enum flag
> flag)
> {
> switch (flag) {
> case mode_switch_completed:
> - return (rf69_read_reg(spi, REG_IRQFLAGS1) &
> MASK_IRQFLAGS1_MODE_READY);
> + return (rf69_read_reg(spi, REG_IRQFLAGS1) &
> + MASK_IRQFLAGS1_MODE_READY);
This isn't how we align things. The ( and the next line should match.
return (rf69_read_reg(spi, REG_IRQFLAGS1) &
MASK_IRQFLAGS1_MODE_READY);
But actually the original is probably better than the new version so
lets just leave it as is.
regards,
dan carpenter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 2/2] pi433: Fix indentation according to coding style
On Tue, Dec 03, 2019 at 09:14:17PM +0300, Dan Carpenter wrote:
> You can't have two patches with the same subject.
>
> On Tue, Dec 03, 2019 at 06:54:49PM +0100, Sven Leykauf wrote:
> > Fix indentation so that no line exceeds the 80 character border.
> >
> > Put the return command one line under the default case, so it looks
> > better.
> >
> > Co-developed-by: Daniel Bauer
> > Signed-off-by: Daniel Bauer
> > Signed-off-by: Sven Leykauf
> > ---
> > drivers/staging/pi433/rf69.c | 56
> > 1 file changed, 37 insertions(+), 19 deletions(-)
> >
> > diff --git a/drivers/staging/pi433/rf69.c b/drivers/staging/pi433/rf69.c
> > index 6b13f92028c7..6cdd46682aa9 100644
> > --- a/drivers/staging/pi433/rf69.c
> > +++ b/drivers/staging/pi433/rf69.c
> > @@ -596,42 +596,60 @@ bool rf69_get_flag(struct spi_device *spi, enum flag
> > flag)
> > {
> > switch (flag) {
> > case mode_switch_completed:
> > - return (rf69_read_reg(spi, REG_IRQFLAGS1) &
> > MASK_IRQFLAGS1_MODE_READY);
> > + return (rf69_read_reg(spi, REG_IRQFLAGS1) &
> > + MASK_IRQFLAGS1_MODE_READY);
For patch 1 it would be pretty easy to re-write the function to be
cleaner and under 80 characters. For this function it's quite a bit
trickier. You could sit for a long time thinking about it.
Is MASK_IRQFLAGS1_MODE_READY the exact perfect name? Why does the
"enum flag flag" enum exist? Is it perfectly named? How much of this
function is dead code?
It's probably better to start cleaning up the rest of the driver and
then by the time you get back to this function maybe the answer will
be obvious.
regards,
dan carpenter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/4] staging: wilc1000: use runtime configuration for sdio oob interrupt
On 11/25/19 2:26 AM, Julian Calaby wrote: > Hi Adham, > > The OOB interrupt is a GPIO and this is an SDIO card, so why not just > set the relevant pin in the devicetree and detect it based on that? > > I'm pretty sure that the Broadcom fmac driver does something like this. Thanks Julian and Dan for your feedback. We will go through the fmac driver to see how to improve OOB selection based on that, and send v2 of this patch. Greg, will it be possible to ignore this patch for now and merge the rest of the patch series? Thanks, Adham ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
How do i send these funds to your bank account?
Hi Dear, This is to notify that your over due fund which has been delayed since years ago is now ready for payment but i don't know how i am to explain this to you because what i was able to retrieve from the bank is only but $459,000.00 which i don't know how i am to send these funds across to you. If you really need the funds valued $459,000.00, then do let me know so i can instruct the bank to send you the money. Hope it is safe for you to receive the funds? Remain blessed and healthy. Yours faithfully, Mr. Thomas Dobbs United Nations Payment Officer ___ 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 Tue, 2019-12-03 at 16:51 +, Jonathan Cameron wrote:
> On Tue, 3 Dec 2019 16:38:50 +
> Mark Brown wrote:
>
> > On Sun, Dec 01, 2019 at 11:40:32AM +, Jonathan Cameron wrote:
> >
> > > +CC Mark as we probably need a more general view point on
> > > the question of whether SPI mode should be enforced by binding
> > > or in the driver.
> >
> > Not sure I see the question here, I think I was missing a bit of
> > the conversation? It's perfectly fine for a driver to specify a
> > mode, if the hardware always uses some unusual mode then there's
> > no sense in forcing every single DT to set the same mode. On the
> > other hand if there's some configuration for the driver that was
> > handling some board specific configuration that there's already
> > some generic SPI support for setting then it seems odd to have a
> > custom driver specific configuration mechanism.
> >
>
> If the driver picks a mode because that's what it says on the datasheet
> it prevents odd board configurations from working. The question
> becomes whether it makes sense in general to assume those odd board
> conditions don't exist until we actually have one, or to assume that
> they might and push the burden on to all DT files.
>
> Traditionally in IIO at least we've mostly taken the view the DT
> should be right and complete and had bindings state what normal
> parameters must be for it to work (assuming no inverters etc)
>
> If we encode it in the driver, and we later meet such a board we
> end up with a custom dance to query the DT parameters again and
> only override if present.
>
> We can't rely on the core SPI handling because I don't think
> there is any means of specifying a default.
>
> We can adopt the view that in general these weird boards with inverters
> are weird and just handle them when they occur. Sounds like that is your
> preference, at least for new parts.
>
> For old ones we have no idea if there are boards out there using
> them with inverters so easiest is probably to just carry on putting them
> in the DT bindings.
There might be a few other options, which would require some SPI OF change.
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;
} else
if (of_property_read_bool(nc, "spi-cpha"))
spi->mode |= SPI_CPHA;
Or another option could be:
if (of_property_read_bool(nc, "spi-cpha-override")) {
spi->mode |= SPI_CPHA_OVERRIDE;
if
(of_property_read_bool(nc, "spi-cpha"))
spi->mode |= SPI_CPHA;
Naturally, this would require that spi_setup() checks SPI_CPHA_OVERRIDE and
doesn't set SPI_CPHA if SPI_CPHA_OVERRIDE is set.
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).
An "spi-mode-conv" driver would also handle this 3-wire-4-wire dance, and
the level inversions, and other (similar) things.
Thoughts?
Alex
>
> Jonathan
>
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v5 1/2] staging: iio: accel: adis16240: enforce SPI mode on probe function
On Sun, 2019-12-01 at 11:42 +, Jonathan Cameron wrote:
> [External]
>
> On Mon, 25 Nov 2019 07:55:39 +
> "Ardelean, Alexandru" wrote:
>
> > On Sat, 2019-11-23 at 20:35 -0300, Rodrigo Carvalho wrote:
> > > [External]
> > >
> > > According to the datasheet, this driver supports only SPI mode 3,
> > > so we should enforce it and call spi_setup() on probe function.
> > >
> > > Signed-off-by: Rodrigo Ribeiro Carvalho
> > > ---
> > > V5:
> > > - Add this patch to the patchset
> > >
> > > drivers/staging/iio/accel/adis16240.c | 7 +++
> > > 1 file changed, 7 insertions(+)
> > >
> > > diff --git a/drivers/staging/iio/accel/adis16240.c
> > > b/drivers/staging/iio/accel/adis16240.c
> > > index 82099db4bf0c..77b6b81767b9 100644
> > > --- a/drivers/staging/iio/accel/adis16240.c
> > > +++ b/drivers/staging/iio/accel/adis16240.c
> > > @@ -400,6 +400,13 @@ static int adis16240_probe(struct spi_device
> > > *spi)
> > > indio_dev->num_channels = ARRAY_SIZE(adis16240_channels);
> > > indio_dev->modes = INDIO_DIRECT_MODE;
> > >
> > > + spi->mode = SPI_MODE_3;
> >
> > A generic question from me here, since I am not sure.
> >
> > Would this limit the configurations of this chip on the board?
> > In case there is some level-inverter [for various weird reasons] on the
> > board, this may not work, because the SPI controller would need CPOL to
> > be
> > 0.
> >
> > Not sure if this question is valid, or whether we need to care about
> > such
> > configurations.
>
> It's a good question as this sort of trick is used sometimes. Let's see
> what responses we get to the other branch of this thread before moving
> forwards
> with this.
>
Coming back here.
Apologies to Rodrigo. I do realize that I delayed this a bit too much.
Let's have this series as-is here, and then we can see about a more generic
SPI Mode Converter driver that rounds-up all these weird boards.
Or, if we don't do any SPI mode converter drivers, then we can handle this
on a case-by-case basis/driver.
> Jonathan
>
>
> > Thanks
> > Alex
> >
> > > + ret = spi_setup(spi);
> > > + if (ret) {
> > > + dev_err(&spi->dev, "spi_setup failed!\n");
> > > + return ret;
> > > + }
> > > +
> > > ret = adis_init(st, indio_dev, spi, &adis16240_data);
> > > if (ret)
> > > return ret;
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
