Re: [PATCH v2 3/7] lib/hexdump.c: Optionally suppress lines of repeated bytes

2019-05-13 Thread Geert Uytterhoeven
Hi Alastair,

Thanks for your patch!

On Wed, May 8, 2019 at 9:04 AM Alastair D'Silva  wrote:
> From: Alastair D'Silva 
>
> Some buffers may only be partially filled with useful data, while the rest
> is padded (typically with 0x00 or 0xff).
>
> This patch introduces a flag to allow the supression of lines of repeated
> bytes,

Given print_hex_dump() operates on entities of groupsize (1, 2, 4, or 8)
bytes, wouldn't it make more sense to consider repeated groups instead
of repeated bytes?

> which are replaced with '** Skipped %u bytes of value 0x%x **'

Using a custom message instead of just "*", like "hexdump" uses, will
require preprocessing the output when recovering the original binary
data by feeding it to e.g. "xxd".
This may sound worse than it is, though, as I never got "xxd" to work
without preprocessing anyway ;-)

$ cat $(type -p unhexdump)
#!/bin/sh
sed 's/^[0-9a-f]*//' $1 | xxd -r -p | dd conv=swab

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds


Re: [PATCH RFC 00/15] Zero ****s, hugload of hugs <3

2018-12-01 Thread Geert Uytterhoeven
Hi Jon,

On Fri, Nov 30, 2018 at 11:15 PM Jonathan Corbet  wrote:
> On Fri, 30 Nov 2018 14:12:19 -0800
> Jarkko Sakkinen  wrote:
>
> > As a maintainer myself (and based on somewhat disturbed feedback from
> > other maintainers) I can only make the conclusion that nobody knows what
> > the responsibility part here means.
> >
> > I would interpret, if I read it like at lawyer at least, that even for
> > existing code you would need to do the changes postmorterm.
> >
> > Is this wrong interpretation?  Should I conclude that I made a mistake
> > by reading the CoC and trying to understand what it *actually* says?
> > After this discussion, I can say that I understand it less than before.
>
> Have you read Documentation/process/code-of-conduct-interpretation.rst?
> As has been pointed out, it contains a clear answer to how things should
> be interpreted here.

Indeed:

| Contributions submitted for the kernel should use appropriate language.
| Content that already exists predating the Code of Conduct will not be
| addressed now as a violation.

However:

| Inappropriate language can be seen as a
| bug, though; such bugs will be fixed more quickly if any interested
| parties submit patches to that effect.

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds


Re: move bus (PCI, PCMCIA, EISA, rapdio) config to drivers/ v2

2018-10-19 Thread Geert Uytterhoeven
Hi Christoph,

On Fri, Oct 19, 2018 at 9:10 AM Christoph Hellwig  wrote:
> On Fri, Oct 19, 2018 at 09:07:51AM +0200, Geert Uytterhoeven wrote:
> > Without this:
> >   - It's hard to visually match your untagged cover letter with the
> > actual patches,
> >   - Your individual patches lack the version info, so people cannot see 
> > which
> > version review comments in an email reply apply to.
>
> All of that is trivially solved by mail threading.

You forgot to answer this question:

| Can you please clarify what exactly that would mess up?

Thanks!

Gr{oetje,eeting}s,

    Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds


Re: move bus (PCI, PCMCIA, EISA, rapdio) config to drivers/ v2

2018-10-19 Thread Geert Uytterhoeven
Hi Christoph,

On Fri, Oct 19, 2018 at 9:00 AM Christoph Hellwig  wrote:
> On Wed, Oct 17, 2018 at 10:30:49AM +0200, Geert Uytterhoeven wrote:
> > Please use "git format-patch -v --cover" to prepare patch series
> > for sending with git-send-email.
> >
> >   "-v" to prefix all patches with version number ,
> >   "--cover" to have a "[PATCH 0/]" prefix in the cover letter.
>
> We had that discussion before and I strongly disagree with messing
> up the subject lines like that.  The git-send-email defaults are
> perfectly fine.

Can you please clarify what exactly that would mess up?
Documentation/process/submitting-patches.rst even mentions the tags
to put in "[PATCH ]"?

Without this:
  - It's hard to visually match your untagged cover letter with the
actual patches,
  - Your individual patches lack the version info, so people cannot see which
version review comments in an email reply apply to.

Thanks!

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds


Re: move bus (PCI, PCMCIA, EISA, rapdio) config to drivers/ v2

2018-10-17 Thread Geert Uytterhoeven
Hi Christoph,

On Wed, Oct 17, 2018 at 10:03 AM Christoph Hellwig  wrote:
> currently every architecture that wants to provide on of the common
> periphal busses needs to add some boilerplate code and include the
> right Kconfig files.   This series instead just selects the presence
> (when needed) and then handles everything in the bus-specific
> Kconfig file under drivers/.
>
> Changes since v1:
>  - rename all HAS_* Kconfig symbols to HAVE_*
>  - drop the CONFIG_PCI_QSPAN option entirely
>  - drop duplicate select from powerpc
>  - restore missing selection of PCI_MSI for riscv
>  - update x86 and riscv defconfigs to include PCI
>  - actually inclue drivers/eisa/Kconfig
>  - adjust some captilizations

Thanks for the update!

Please use "git format-patch -v --cover" to prepare patch series
for sending with git-send-email.

  "-v" to prefix all patches with version number ,
  "--cover" to have a "[PATCH 0/]" prefix in the cover letter.

Thanks!

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds


Re: [PATCH v2 5/6] esp_scsi: De-duplicate PIO routines

2018-10-14 Thread Geert Uytterhoeven
Hi Finn,

On Sun, Oct 14, 2018 at 8:35 AM Finn Thain  wrote:
> As a temporary measure, the code to implement PIO transfers was
> duplicated in zorro_esp and mac_esp. Now that it has stabilized
> move the common code into the core driver but don't build it unless
> needed.
>
> This replaces the inline assembler with more portable writesb() calls.
> Optimizing the m68k writesb() implementation is a separate patch.
>
> Tested-by: Stan Johnson 
> Signed-off-by: Finn Thain 
> Tested-by: Michael Schmitz 

Thanks for your patch!

> --- a/drivers/scsi/Kconfig
> +++ b/drivers/scsi/Kconfig
> @@ -42,6 +42,10 @@ config SCSI_DMA
> bool
> default n
>
> +config SCSI_ESP_PIO
> +   bool
> +   default n

"default n" is the default, so please drop this line.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds


Re: [PATCH v2 2/6] esp_scsi: Track residual for PIO transfers

2018-10-14 Thread Geert Uytterhoeven
Hi Finn,

On Sun, Oct 14, 2018 at 8:36 AM Finn Thain  wrote:
> If a target disconnects during a PIO data transfer the command may
> fail when the target reconnects:
>
> scsi host1: DMA length is zero!
> scsi host1: cur adr[0438] len[]
>
> The scsi bus is then reset. This happens because the residual reached
> zero before the transfer was completed.
>
> The usual residual calculation relies on the Transfer Count registers
> which works for DMA transfers but not for PIO transfers. Fix the problem
> by storing the PIO transfer residual and using that to correctly
> calculate bytes_sent.

Thanks for yur patch!

> Fixes: 6fe07aaffbf0

Fixes: 6fe07aaffbf0 ("[SCSI] m68k: new mac_esp scsi driver")

> Tested-by: Stan Johnson 
> Signed-off-by: Finn Thain 
> Tested-by: Michael Schmitz 

> --- a/drivers/scsi/esp_scsi.h
> +++ b/drivers/scsi/esp_scsi.h
> @@ -540,6 +540,8 @@ struct esp {
>
> void*dma;
> int dmarev;
> +
> +   int send_cmd_residual;

unsigned int?

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds


Re: [PATCH v2 1/6] zorro_esp: Limit DMA transfers to 65535 bytes

2018-10-14 Thread Geert Uytterhoeven
Hi Finn,

On Sun, Oct 14, 2018 at 8:36 AM Finn Thain  wrote:
> The core driver, esp_scsi, does not use the ESP_CONFIG2_FENAB bit, so
> the chip's Transfer Counter register is only 16 bits wide (not 24).
> A larger transfer cannot work and will theoretically result in a failed
> command and a "DMA length is zero" error.

Thanks for your patch!

> Fixes: 3109e5ae0311

Fixes: 3109e5ae0311 ("scsi: zorro_esp: New driver for Amiga Zorro
NCR53C9x boards")

$ git help fixes
'fixes' is aliased to 'show --format='Fixes: %h ("%s")' -s'

BTW, if you use vim, add

noremap ;gs "zyiw:exe "new \| setlocal buftype=nofile
bufhidden=hide noswapfile syntax=git \| 0r ! git show ".@z."" \|
:0

to .vimrc, and type ";gs" when the cursor is positioned on a commit ID.

> Signed-off-by: Finn Thain 
> Cc: Michael Schmitz 
> Tested-by: Michael Schmitz 

> --- a/drivers/scsi/zorro_esp.c
> +++ b/drivers/scsi/zorro_esp.c
> @@ -245,7 +245,7 @@ static int fastlane_esp_irq_pending(struct esp *esp)
>  static u32 zorro_esp_dma_length_limit(struct esp *esp, u32 dma_addr,
> u32 dma_len)
>  {
> -   return dma_len > 0xFF ? 0xFF : dma_len;
> +   return dma_len > 0x ? 0x : dma_len;
>  }
>
>  static void zorro_esp_reset_dma(struct esp *esp)
> @@ -484,7 +484,6 @@ static void zorro_esp_send_blz1230_dma_cmd(struct esp 
> *esp, u32 addr,
> scsi_esp_cmd(esp, ESP_CMD_DMA);
> zorro_esp_write8(esp, (esp_count >> 0) & 0xff, ESP_TCLOW);
> zorro_esp_write8(esp, (esp_count >> 8) & 0xff, ESP_TCMED);
> -   zorro_esp_write8(esp, (esp_count >> 16) & 0xff, ESP_TCHI);

Since all these sub-drivers seem to support 24-bit transfers, perhaps this is
something to be fixed in the esp_scsi core?

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds


Re: [LSF/MM TOPIC NOTES] x86 ZONE_DMA love

2018-05-03 Thread Geert Uytterhoeven
Hi Luis,

On Thu, Apr 26, 2018 at 11:54 PM, Luis R. Rodriguez  wrote:
> x86 implicit and explicit ZONE_DMA users
> -
>
> We list below all x86 implicit and explicit ZONE_DMA users.
>
> # Explicit x86 users of GFP_DMA or __GFP_DMA
>
>   * drivers/iio/common/ssp_sensors - wonder if enabling this on x86 was a 
> mistake.
> Note that this needs SPI and SPI needs HAS_IOMEM. I only see HAS_IOMEM on
> s390 ? But I do think the Intel Minnowboard has SPI, but doubt it has
>the ssp sensor stuff.
>
>  * drivers/input/rmi4/rmi_spi.c - same SPI question
>  * drivers/media/common/siano/ - make allyesconfig yields it enabled, but
>not sure if this should ever be on x86
>  * drivers/media/platform/sti/bdisp/ - likewise
>   * drivers/media/platform/sti/hva/ - likewise
>   * drivers/media/usb/gspca/ - likewise
>   * drivers/mmc/host/wbsd.c - likewise
>   * drivers/mtd/nand/gpmi-nand/ - likewise
>   * drivers/net/can/spi/hi311x.c - likewise
>   * drivers/net/can/spi/mcp251x.c - likewise
>   * drivers/net/ethernet/agere/ - likewise
>   * drivers/net/ethernet/neterion/vxge/ - likewise
>   * drivers/net/ethernet/rocker/ - likewise
>   * drivers/net/usb/kalmia.c - likewise
>   * drivers/net/ethernet/neterion/vxge/ - likewise
>   * drivers/spi/spi-pic32-sqi.c - likewise
>   * drivers/spi/spi-sh-msiof.c - likewise

depends on ARCH_SHMOBILE || ARCH_RENESAS || COMPILE_TEST

>   * drivers/spi/spi-ti-qspi.c - likewise

I haven't checked the others, but probably you want to disable COMPILE_TEST
to make more educated guesses about driver usage on x86.

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds


Re: [PATCH v8] scsi: new zorro_esp.c for Amiga Zorro NCR53C9x boards

2018-04-11 Thread Geert Uytterhoeven
Hi Michael,

On Wed, Apr 11, 2018 at 10:36 AM, Michael Schmitz  wrote:
> From: Michael Schmitz 
>
> New combined SCSI driver for all ESP based Zorro SCSI boards for
> m68k Amiga.

Thanks a lot!

> --- /dev/null
> +++ b/drivers/scsi/zorro_esp.c

> +static const struct zorro_device_id zorro_esp_zorro_tbl[] = {
> +   {   /* Blizzard 1230 IV */
> +   .id = ZORRO_ID(PHASE5, 0x11, 0),
> +   .driver_data = (unsigned long)ZORRO_BLZ1230,

These casts are not needed if ZORRO_BLZ1230 is an enum.

> +static int zorro_esp_probe(struct zorro_dev *z,
> +  const struct zorro_device_id *ent)
> +{
> +   struct scsi_host_template *tpnt = &scsi_esp_template;
> +   struct Scsi_Host *host;
> +   struct esp *esp;
> +   const struct zorro_driver_data *zdd;
> +   struct zorro_esp_priv *zep;
> +   unsigned long board, ioaddr, dmaaddr;
> +   int err;
> +
> +   board = zorro_resource_start(z);
> +   zdd = &zorro_esp_boards[(unsigned long)ent->driver_data];

likewise

> +   if (zep->zorro3 && ent->driver_data == (unsigned 
> long)ZORRO_BLZ1230II) {

likewise

> +   if (zep->zorro3 && ent->driver_data == (unsigned 
> long)ZORRO_BLZ1230II) {

one more

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds


Re: [PATCH v7] scsi: new zorro_esp.c for Amiga Zorro NCR53C9x boards

2018-04-11 Thread Geert Uytterhoeven
Hi Christoph,

On Wed, Apr 11, 2018 at 10:11 AM, Christoph Hellwig  wrote:
> On Wed, Apr 11, 2018 at 10:03:12AM +0200, Geert Uytterhoeven wrote:
>> > That would be cool. Would that still be in time for the 4.17 merge?
>>
>> Nope, as new drivers need to be in linux-next before the merge window opens.
>
> I always throught that entirely new drivers were an exception to that.

Aren't you confusing this with the new device ID rules for stable?

It's debatable, and thus up to the maintainer...

Gr{oetje,eeting}s,

    Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds


Re: [PATCH v7] scsi: new zorro_esp.c for Amiga Zorro NCR53C9x boards

2018-04-11 Thread Geert Uytterhoeven
Hi Adrian,

On Wed, Apr 11, 2018 at 9:59 AM, John Paul Adrian Glaubitz
 wrote:
> On 04/11/2018 08:51 AM, Geert Uytterhoeven wrote:
>> I don't have a preference. If you think it makes the driver easier to
>> read,
>> go for it.
>
> That would be cool. Would that still be in time for the 4.17 merge?

Nope, as new drivers need to be in linux-next before the merge window opens.

Gr{oetje,eeting}s,

        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds


Re: [PATCH v7] scsi: new zorro_esp.c for Amiga Zorro NCR53C9x boards

2018-04-10 Thread Geert Uytterhoeven
Hi Michael,

On Tue, Apr 10, 2018 at 11:50 PM, Michael Schmitz  wrote:
> On Tue, Apr 10, 2018 at 8:18 PM, Geert Uytterhoeven
>  wrote:
>> On Tue, Apr 10, 2018 at 4:16 AM, Michael Schmitz  
>> wrote:
>>> On Mon, Apr 9, 2018 at 7:50 PM, Christoph Hellwig  
>>> wrote:
>>>> On Sun, Apr 08, 2018 at 02:45:32PM +1200, Michael Schmitz wrote:
>>>>> New combined SCSI driver for all ESP based Zorro SCSI boards for
>>>>> m68k Amiga.
>>>>> + {
>>>>> + .id = 
>>>>> ZORRO_PROD_PHASE5_BLIZZARD_1230_II_FASTLANE_Z3_CYBERSCSI_CYBERSTORM060,
>>>>
>>>> In PCI Land we've usually stopped using PCI IDs unless they are used
>>>> in multiple
>>
>> (missing "places"?)
>>
>>> Short of a complete rewrite of the Zorro driver support code to be
>>> closer to what PCI does, I don' see what can be done about the use of
>>> Zorro IDs. I don't think such a rewrite is planned in the near future,
>>> Geert?
>>
>> I think what Christoph means is the use of the define
>> ZORRO_PROD_PHASE5_BLIZZARD_1230_II_FASTLANE_Z3_CYBERSCSI_CYBERSTORM060
>> versus hardcoded numbers, or ZORRO_ID(PHASE5, 0x0B, 0).
>>
>> We have a long list of ZORRO_PROD_* definitions in
>> include/uapi/linux/zorro_ids.h because of historical reasons.  The list
>> isn't really changing (no new IDs in git history) due to almost no new
>> Zorro boards being made, unlike for PCI, where keeping an in-kernel list
>> is a lot of work, and not desirable.
>
> now I see, thanks.
>
> I could change the device table to use ZORRO_ID(PHASE5, ...) style IDs
> instead of the longish defines if you're OK with that.

I don't have a preference. If you think it makes the driver easier to read,
go for it.

Note that we can't get rid of the longish defines anyway, as they're in a
uapi header file, so you're free to keep on using it.

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds


Re: [PATCH v7] scsi: new zorro_esp.c for Amiga Zorro NCR53C9x boards

2018-04-10 Thread Geert Uytterhoeven
Hi Michael,

On Tue, Apr 10, 2018 at 4:16 AM, Michael Schmitz  wrote:
> On Mon, Apr 9, 2018 at 7:50 PM, Christoph Hellwig  wrote:
>> On Sun, Apr 08, 2018 at 02:45:32PM +1200, Michael Schmitz wrote:
>>> New combined SCSI driver for all ESP based Zorro SCSI boards for
>>> m68k Amiga.
>>> + {
>>> + .id = 
>>> ZORRO_PROD_PHASE5_BLIZZARD_1230_II_FASTLANE_Z3_CYBERSCSI_CYBERSTORM060,
>>
>> In PCI Land we've usually stopped using PCI IDs unless they are used
>> in multiple

(missing "places"?)

> Short of a complete rewrite of the Zorro driver support code to be
> closer to what PCI does, I don' see what can be done about the use of
> Zorro IDs. I don't think such a rewrite is planned in the near future,
> Geert?

I think what Christoph means is the use of the define
ZORRO_PROD_PHASE5_BLIZZARD_1230_II_FASTLANE_Z3_CYBERSCSI_CYBERSTORM060
versus hardcoded numbers, or ZORRO_ID(PHASE5, 0x0B, 0).

We have a long list of ZORRO_PROD_* definitions in
include/uapi/linux/zorro_ids.h because of historical reasons.  The list
isn't really changing (no new IDs in git history) due to almost no new
Zorro boards being made, unlike for PCI, where keeping an in-kernel list
is a lot of work, and not desirable.

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds


Re: [PATCH v7] scsi: new zorro_esp.c for Amiga Zorro NCR53C9x boards

2018-04-09 Thread Geert Uytterhoeven
Hi Christoph,

On Mon, Apr 9, 2018 at 9:50 AM, Christoph Hellwig  wrote:
> On Sun, Apr 08, 2018 at 02:45:32PM +1200, Michael Schmitz wrote:
>> --- /dev/null
>> +++ b/drivers/scsi/zorro_esp.c

>> + .driver_data = (unsigned long)&blizzard1230II_data,
>
> What most (or at least many) drivers do in PCI land is to just use
> an enum of types in the driver_Data field and use that as an index for
> for decisions later.  It seems like that might be the cleaner method
> here as well.

That may work fine for a small number of differences.
For more differences, the pointer to the feature struct is what most DT
drivers use (of_device_id.data is a const void *).

Gr{oetje,eeting}s,

    Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds


[PATCH v2 04/21] fbdev: Remove depends on HAS_DMA in case of platform dependency

2018-03-16 Thread Geert Uytterhoeven
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Mark Brown 
Acked-by: Robin Murphy 
---
v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Split per subsystem.
---
 drivers/video/fbdev/Kconfig | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 11e699f1062b78ea..abee481f5fb778dd 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -2174,7 +2174,8 @@ config FB_XILINX
 
 config FB_GOLDFISH
tristate "Goldfish Framebuffer"
-   depends on FB && HAS_DMA && (GOLDFISH || COMPILE_TEST)
+   depends on FB
+   depends on GOLDFISH || COMPILE_TEST
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
-- 
2.7.4



[PATCH v2 01/21] ASoC: Remove depends on HAS_DMA in case of platform dependency

2018-03-16 Thread Geert Uytterhoeven
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Note:
  - The various SND_SOC_LPASS_* symbols had to loose their dependencies
on HAS_DMA, as they are selected by SND_SOC_STORM and/or
SND_SOC_APQ8016_SBC.

Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Mark Brown 
Acked-by: Robin Murphy 
---
v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Drop dependency of SND_SOC_LPASS_IPQ806X on HAS_DMA,
  - Split per subsystem.
---
 sound/soc/bcm/Kconfig  | 3 +--
 sound/soc/kirkwood/Kconfig | 1 -
 sound/soc/pxa/Kconfig  | 1 -
 sound/soc/qcom/Kconfig | 7 ++-
 4 files changed, 3 insertions(+), 9 deletions(-)

diff --git a/sound/soc/bcm/Kconfig b/sound/soc/bcm/Kconfig
index edf367100ebd2f17..02f50b7a966ff262 100644
--- a/sound/soc/bcm/Kconfig
+++ b/sound/soc/bcm/Kconfig
@@ -11,9 +11,8 @@ config SND_BCM2835_SOC_I2S
 config SND_SOC_CYGNUS
tristate "SoC platform audio for Broadcom Cygnus chips"
depends on ARCH_BCM_CYGNUS || COMPILE_TEST
-   depends on HAS_DMA
help
  Say Y if you want to add support for ASoC audio on Broadcom
  Cygnus chips (bcm958300, bcm958305, bcm911360)
 
- If you don't know what to do here, say N.
\ No newline at end of file
+ If you don't know what to do here, say N.
diff --git a/sound/soc/kirkwood/Kconfig b/sound/soc/kirkwood/Kconfig
index bc3c7b5ac752e471..132bb83f8e99aff3 100644
--- a/sound/soc/kirkwood/Kconfig
+++ b/sound/soc/kirkwood/Kconfig
@@ -1,7 +1,6 @@
 config SND_KIRKWOOD_SOC
tristate "SoC Audio for the Marvell Kirkwood and Dove chips"
depends on ARCH_DOVE || ARCH_MVEBU || COMPILE_TEST
-   depends on HAS_DMA
help
  Say Y or M if you want to add support for codecs attached to
  the Kirkwood I2S interface. You will also need to select the
diff --git a/sound/soc/pxa/Kconfig b/sound/soc/pxa/Kconfig
index 484ab3c2ad672fc8..960744e46edc0549 100644
--- a/sound/soc/pxa/Kconfig
+++ b/sound/soc/pxa/Kconfig
@@ -1,7 +1,6 @@
 config SND_PXA2XX_SOC
tristate "SoC Audio for the Intel PXA2xx chip"
depends on ARCH_PXA || COMPILE_TEST
-   depends on HAS_DMA
select SND_PXA2XX_LIB
help
  Say Y or M if you want to add support for codecs attached to
diff --git a/sound/soc/qcom/Kconfig b/sound/soc/qcom/Kconfig
index 8ec9a074b38bd702..3cc252e55468eaab 100644
--- a/sound/soc/qcom/Kconfig
+++ b/sound/soc/qcom/Kconfig
@@ -11,24 +11,21 @@ config SND_SOC_LPASS_CPU
 
 config SND_SOC_LPASS_PLATFORM
tristate
-   depends on HAS_DMA
select REGMAP_MMIO
 
 config SND_SOC_LPASS_IPQ806X
tristate
-   depends on HAS_DMA
select SND_SOC_LPASS_CPU
select SND_SOC_LPASS_PLATFORM
 
 config SND_SOC_LPASS_APQ8016
tristate
-   depends on HAS_DMA
select SND_SOC_LPASS_CPU
select SND_SOC_LPASS_PLATFORM
 
 config SND_SOC_STORM
tristate "ASoC I2S support for Storm boards"
-   depends on SND_SOC_QCOM && HAS_DMA
+   depends on SND_SOC_QCOM
select SND_SOC_LPASS_IPQ806X
select SND_SOC_MAX98357A
help
@@ -37,7 +34,7 @@ config SND_SOC_STORM
 
 config SND_SOC_APQ8016_SBC
tristate "SoC Audio support for APQ8016 SBC platforms"
-   depends on SND_SOC_QCOM && HAS_DMA
+   depends on SND_SOC_QCOM
select SND_SOC_LPASS_APQ8016
help
   Support for Qualcomm Technologies LPASS audio block in
-- 
2.7.4



[PATCH v2 10/21] lightnvm: Remove depends on HAS_DMA in case of platform dependency

2018-03-16 Thread Geert Uytterhoeven
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Notes:
  - FSL_FMAN keeps its dependency on HAS_DMA, as it calls set_dma_ops(),
which does not exist if HAS_DMA=n (Do we need a dummy? The use of
set_dma_ops() in this driver is questionable),
  - SND_SOC_LPASS_IPQ806X and SND_SOC_LPASS_PLATFORM loose their
dependency on HAS_DMA, as they are selected from
SND_SOC_APQ8016_SBC.

Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Mark Brown 
Acked-by: Robin Murphy 
---
v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Split per subsystem.
---
 drivers/lightnvm/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/lightnvm/Kconfig b/drivers/lightnvm/Kconfig
index 10c08982185a572f..9c03f35d9df113c6 100644
--- a/drivers/lightnvm/Kconfig
+++ b/drivers/lightnvm/Kconfig
@@ -4,7 +4,7 @@
 
 menuconfig NVM
bool "Open-Channel SSD target support"
-   depends on BLOCK && HAS_DMA && PCI
+   depends on BLOCK && PCI
select BLK_DEV_NVME
help
  Say Y here to get to enable Open-channel SSDs.
-- 
2.7.4



[PATCH v2 00/21] Allow compile-testing NO_DMA (drivers)

2018-03-16 Thread Geert Uytterhoeven
Hi all,

If NO_DMA=y, get_dma_ops() returns a reference to the non-existing
symbol bad_dma_ops, thus causing a link failure if it is ever used.

The intention of this is twofold:
  1. To catch users of the DMA API on systems that do no support the DMA
 mapping API,
  2. To avoid building drivers that cannot work on such systems anyway.

However, the disadvantage is that we have to keep on adding dependencies
on HAS_DMA all over the place.

Thanks to the COMPILE_TEST symbol, lots of drivers now depend on one or
more platform dependencies (that imply HAS_DMA) || COMPILE_TEST, thus
already covering intention #2.  Having to add an explicit dependency on
HAS_DMA here is cumbersome, and hinders compile-testing.

Hence I think the time is ripe to reconsider the link failure.
Patch series "[PATCH v2 0/5] Allow compile-testing NO_DMA (core)"
(https://lkml.org/lkml/2018/3/16/435) already:
  - Changed get_dma_ops() to return NULL instead,
  - Added a few more dummies to enable compile-testing.

This patch series:
  - Removes dependencies on HAS_DMA for symbols that already have
platform dependencies implying HAS_DMA.

To avoid allmodconfig/allyesconfig regressions on NO_DMA=y platforms,
this (drivers) series should be applied after the previous (core)
series (but not many people may notice/care ;-)

Changes compared to v1:
  - Add Reviewed-by, Acked-by,
  - Drop dependency of SND_SOC_LPASS_IPQ806X on HAS_DMA,
  - Drop dependency of VIDEOBUF{,2}_DMA_{CONTIG,SG} on HAS_DMA,
  - Drop new dependencies of VIDEO_IPU3_CIO2, DVB_C8SECTPFE, and
MTD_NAND_MARVELL on HAS_DMA,
  - Split in per-subsystem patches,
  - Split-off the core part in a separate series.

This series is against v4.16-rc5. It can also be found at
https://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git/log/?h=no-dma-compile-testing-v2

It has been compile-tested with allmodconfig and allyesconfig for
m68k/sun3, and has received attention from the kbuild test robot.

Thanks!

Geert Uytterhoeven (21):
  ASoC: Remove depends on HAS_DMA in case of platform dependency
  ata: Remove depends on HAS_DMA in case of platform dependency
  crypto: Remove depends on HAS_DMA in case of platform dependency
  fbdev: Remove depends on HAS_DMA in case of platform dependency
  firewire: Remove depends on HAS_DMA in case of platform dependency
  fpga: Remove depends on HAS_DMA in case of platform dependency
  i2c: Remove depends on HAS_DMA in case of platform dependency
  iio: adc: Remove depends on HAS_DMA in case of platform dependency
  iommu: Remove depends on HAS_DMA in case of platform dependency
  lightnvm: Remove depends on HAS_DMA in case of platform dependency
  mailbox: Remove depends on HAS_DMA in case of platform dependency
  media: Remove depends on HAS_DMA in case of platform dependency
  mmc: Remove depends on HAS_DMA in case of platform dependency
  mtd: Remove depends on HAS_DMA in case of platform dependency
  net: Remove depends on HAS_DMA in case of platform dependency
  remoteproc: Remove depends on HAS_DMA in case of platform dependency
  scsi: hisi_sas: Remove depends on HAS_DMA in case of platform
dependency
  serial: Remove depends on HAS_DMA in case of platform dependency
  spi: Remove depends on HAS_DMA in case of platform dependency
  staging: vc04_services: Remove depends on HAS_DMA in case of platform
dependency
  usb: Remove depends on HAS_DMA in case of platform dependency

 drivers/ata/Kconfig |  2 --
 drivers/crypto/Kconfig  | 14 +++--
 drivers/firewire/Kconfig|  1 -
 drivers/fpga/Kconfig|  1 -
 drivers/i2c/busses/Kconfig  |  3 --
 drivers/iio/adc/Kconfig |  2 --
 drivers/iommu/Kconfig   |  5 ++--
 drivers/lightnvm/Kconfig|  2 +-
 drivers/mailbox/Kconfig |  2 --
 drivers/media/common/videobuf2/Kconfig  |  2 --
 drivers/media/pci/dt3155/Kconfig|  1 -
 drivers/media/pci/intel/ipu3/Kconfig|  1 -
 drivers/media/pci/solo6x10/Kconfig  |  1 -
 drivers/media/pci/sta2x11/Kconfig   |  1 -
 drivers/media/pci/tw5864/Kconfig|  1 -
 drivers/media/pci/tw686x/Kconfig|  1 -
 drivers/media/platform/Kconfig  | 40 -
 drivers/media/platform/am437x/Kconfig   |  2 +-
 drivers/media/platform/atmel/Kconfig|  4 +--
 drivers/media/platform/blackfin/Kconfig |  1 -
 drivers/media/platform/davinci/Kconfig  |  6 
 drivers/media/platform/marvell-ccic/Kconfig |  3 +-
 drivers/media/platform/rcar-vin/Kconfig |  2 +-
 drivers/media/platform/soc_camera/Kconfig   |  3 +-
 drivers/media/platform/sti/c8sectpfe/Kconfig|  2 +-
 drivers/media/v4l2-core/Kconfig |  2 --
 drivers/mmc/ho

[PATCH v2 03/21] crypto: Remove depends on HAS_DMA in case of platform dependency

2018-03-16 Thread Geert Uytterhoeven
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Mark Brown 
Acked-by: Robin Murphy 
---
v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Split per subsystem.
---
 drivers/crypto/Kconfig | 14 --
 1 file changed, 4 insertions(+), 10 deletions(-)

diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index 4b741b83e23ff4de..3d27da7a430c0bc2 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -419,7 +419,7 @@ config CRYPTO_DEV_EXYNOS_RNG
 config CRYPTO_DEV_S5P
tristate "Support for Samsung S5PV210/Exynos crypto accelerator"
depends on ARCH_S5PV210 || ARCH_EXYNOS || COMPILE_TEST
-   depends on HAS_IOMEM && HAS_DMA
+   depends on HAS_IOMEM
select CRYPTO_AES
select CRYPTO_BLKCIPHER
help
@@ -473,7 +473,6 @@ config CRYPTO_DEV_BFIN_CRC
 
 config CRYPTO_DEV_ATMEL_AUTHENC
tristate "Support for Atmel IPSEC/SSL hw accelerator"
-   depends on HAS_DMA
depends on ARCH_AT91 || COMPILE_TEST
select CRYPTO_AUTHENC
select CRYPTO_DEV_ATMEL_AES
@@ -486,7 +485,6 @@ config CRYPTO_DEV_ATMEL_AUTHENC
 
 config CRYPTO_DEV_ATMEL_AES
tristate "Support for Atmel AES hw accelerator"
-   depends on HAS_DMA
depends on ARCH_AT91 || COMPILE_TEST
select CRYPTO_AES
select CRYPTO_AEAD
@@ -501,7 +499,6 @@ config CRYPTO_DEV_ATMEL_AES
 
 config CRYPTO_DEV_ATMEL_TDES
tristate "Support for Atmel DES/TDES hw accelerator"
-   depends on HAS_DMA
depends on ARCH_AT91 || COMPILE_TEST
select CRYPTO_DES
select CRYPTO_BLKCIPHER
@@ -515,7 +512,6 @@ config CRYPTO_DEV_ATMEL_TDES
 
 config CRYPTO_DEV_ATMEL_SHA
tristate "Support for Atmel SHA hw accelerator"
-   depends on HAS_DMA
depends on ARCH_AT91 || COMPILE_TEST
select CRYPTO_HASH
help
@@ -581,7 +577,8 @@ config CRYPTO_DEV_CAVIUM_ZIP
 
 config CRYPTO_DEV_QCE
tristate "Qualcomm crypto engine accelerator"
-   depends on (ARCH_QCOM || COMPILE_TEST) && HAS_DMA && HAS_IOMEM
+   depends on ARCH_QCOM || COMPILE_TEST
+   depends on HAS_IOMEM
select CRYPTO_AES
select CRYPTO_DES
select CRYPTO_ECB
@@ -605,7 +602,6 @@ source "drivers/crypto/vmx/Kconfig"
 config CRYPTO_DEV_IMGTEC_HASH
tristate "Imagination Technologies hardware hash accelerator"
depends on MIPS || COMPILE_TEST
-   depends on HAS_DMA
select CRYPTO_MD5
select CRYPTO_SHA1
select CRYPTO_SHA256
@@ -657,7 +653,6 @@ config CRYPTO_DEV_ROCKCHIP
 
 config CRYPTO_DEV_MEDIATEK
tristate "MediaTek's EIP97 Cryptographic Engine driver"
-   depends on HAS_DMA
depends on (ARM && ARCH_MEDIATEK) || COMPILE_TEST
select CRYPTO_AES
select CRYPTO_AEAD
@@ -695,7 +690,7 @@ source "drivers/crypto/stm32/Kconfig"
 
 config CRYPTO_DEV_SAFEXCEL
tristate "Inside Secure's SafeXcel cryptographic engine driver"
-   depends on HAS_DMA && OF
+   depends on OF
depends on (ARM64 && ARCH_MVEBU) || (COMPILE_TEST && 64BIT)
select CRYPTO_AES
select CRYPTO_BLKCIPHER
@@ -713,7 +708,6 @@ config CRYPTO_DEV_SAFEXCEL
 config CRYPTO_DEV_ARTPEC6
tristate "Support for Axis ARTPEC-6/7 hardware crypto acceleration."
depends on ARM && (ARCH_ARTPEC || COMPILE_TEST)
-   depends on HAS_DMA
depends on OF
select CRYPTO_AEAD
select CRYPTO_AES
-- 
2.7.4



[PATCH v2 08/21] iio: adc: Remove depends on HAS_DMA in case of platform dependency

2018-03-16 Thread Geert Uytterhoeven
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Mark Brown 
Acked-by: Robin Murphy 
---
v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Split per subsystem.
---
 drivers/iio/adc/Kconfig | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index 72bc2b71765ae2ff..57f46e88f5c2536e 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -158,7 +158,6 @@ config AT91_SAMA5D2_ADC
tristate "Atmel AT91 SAMA5D2 ADC"
depends on ARCH_AT91 || COMPILE_TEST
depends on HAS_IOMEM
-   depends on HAS_DMA
select IIO_TRIGGERED_BUFFER
help
  Say yes here to build support for Atmel SAMA5D2 ADC which is
@@ -647,7 +646,6 @@ config SD_ADC_MODULATOR
 config STM32_ADC_CORE
tristate "STMicroelectronics STM32 adc core"
depends on ARCH_STM32 || COMPILE_TEST
-   depends on HAS_DMA
depends on OF
depends on REGULATOR
select IIO_BUFFER
-- 
2.7.4



[PATCH v2 07/21] i2c: Remove depends on HAS_DMA in case of platform dependency

2018-03-16 Thread Geert Uytterhoeven
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Mark Brown 
Acked-by: Robin Murphy 
---
v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Split per subsystem.
---
 drivers/i2c/busses/Kconfig | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index e2954fb86d659f36..2ce9bbd5d56ed06a 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -725,7 +725,6 @@ config I2C_MPC
 config I2C_MT65XX
tristate "MediaTek I2C adapter"
depends on ARCH_MEDIATEK || COMPILE_TEST
-   depends on HAS_DMA
help
  This selects the MediaTek(R) Integrated Inter Circuit bus driver
  for MT65xx and MT81xx.
@@ -903,7 +902,6 @@ config I2C_SH7760
 
 config I2C_SH_MOBILE
tristate "SuperH Mobile I2C Controller"
-   depends on HAS_DMA
depends on ARCH_SHMOBILE || ARCH_RENESAS || COMPILE_TEST
help
  If you say yes to this option, support will be included for the
@@ -1106,7 +1104,6 @@ config I2C_XLP9XX
 
 config I2C_RCAR
tristate "Renesas R-Car I2C Controller"
-   depends on HAS_DMA
depends on ARCH_RENESAS || COMPILE_TEST
select I2C_SLAVE
help
-- 
2.7.4



[PATCH v2 16/21] remoteproc: Remove depends on HAS_DMA in case of platform dependency

2018-03-16 Thread Geert Uytterhoeven
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Mark Brown 
Acked-by: Robin Murphy 
---
v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Split per subsystem.
---
 drivers/remoteproc/Kconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index b609e1d3654ba65f..b60d8132113de0f7 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -23,7 +23,6 @@ config IMX_REMOTEPROC
 
 config OMAP_REMOTEPROC
tristate "OMAP remoteproc support"
-   depends on HAS_DMA
depends on ARCH_OMAP4 || SOC_OMAP5
depends on OMAP_IOMMU
select MAILBOX
-- 
2.7.4



[PATCH v2 09/21] iommu: Remove depends on HAS_DMA in case of platform dependency

2018-03-16 Thread Geert Uytterhoeven
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Mark Brown 
Acked-by: Robin Murphy 
---
v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Split per subsystem.
---
 drivers/iommu/Kconfig | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index f3a21343e636a8f2..32e91398c0555272 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -23,7 +23,7 @@ config IOMMU_IO_PGTABLE
 config IOMMU_IO_PGTABLE_LPAE
bool "ARMv7/v8 Long Descriptor Format"
select IOMMU_IO_PGTABLE
-   depends on HAS_DMA && (ARM || ARM64 || (COMPILE_TEST && 
!GENERIC_ATOMIC64))
+   depends on ARM || ARM64 || (COMPILE_TEST && !GENERIC_ATOMIC64)
help
  Enable support for the ARM long descriptor pagetable format.
  This allocator supports 4K/2M/1G, 16K/32M and 64K/512M page
@@ -42,7 +42,7 @@ config IOMMU_IO_PGTABLE_LPAE_SELFTEST
 config IOMMU_IO_PGTABLE_ARMV7S
bool "ARMv7/v8 Short Descriptor Format"
select IOMMU_IO_PGTABLE
-   depends on HAS_DMA && (ARM || ARM64 || COMPILE_TEST)
+   depends on ARM || ARM64 || COMPILE_TEST
help
  Enable support for the ARM Short-descriptor pagetable format.
  This supports 32-bit virtual and physical addresses mapped using
@@ -374,7 +374,6 @@ config QCOM_IOMMU
# Note: iommu drivers cannot (yet?) be built as modules
bool "Qualcomm IOMMU Support"
depends on ARCH_QCOM || (COMPILE_TEST && !GENERIC_ATOMIC64)
-   depends on HAS_DMA
select IOMMU_API
select IOMMU_IO_PGTABLE_LPAE
select ARM_DMA_USE_IOMMU
-- 
2.7.4



[PATCH v2 18/21] serial: Remove depends on HAS_DMA in case of platform dependency

2018-03-16 Thread Geert Uytterhoeven
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Mark Brown 
Acked-by: Robin Murphy 
---
v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Split per subsystem.
---
 drivers/tty/serial/Kconfig | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index 3682fd3e960cbd64..a0ea146a2ef5af53 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -115,7 +115,6 @@ config SERIAL_SB1250_DUART_CONSOLE
 
 config SERIAL_ATMEL
bool "AT91 on-chip serial port support"
-   depends on HAS_DMA
depends on ARCH_AT91 || COMPILE_TEST
select SERIAL_CORE
select SERIAL_MCTRL_GPIO if GPIOLIB
@@ -586,7 +585,6 @@ config BFIN_UART3_CTSRTS
 
 config SERIAL_IMX
tristate "IMX serial port support"
-   depends on HAS_DMA
depends on ARCH_MXC || COMPILE_TEST
select SERIAL_CORE
select RATIONAL
@@ -1436,7 +1434,6 @@ config SERIAL_PCH_UART_CONSOLE
 
 config SERIAL_MXS_AUART
tristate "MXS AUART support"
-   depends on HAS_DMA
depends on ARCH_MXS || MACH_ASM9260 || COMPILE_TEST
select SERIAL_CORE
select SERIAL_MCTRL_GPIO if GPIOLIB
@@ -1656,7 +1653,6 @@ config SERIAL_SPRD_CONSOLE
 config SERIAL_STM32
tristate "STMicroelectronics STM32 serial port support"
select SERIAL_CORE
-   depends on HAS_DMA
depends on ARCH_STM32 || COMPILE_TEST
help
  This driver is for the on-chip Serial Controller on
-- 
2.7.4



[PATCH v2 20/21] staging: vc04_services: Remove depends on HAS_DMA in case of platform dependency

2018-03-16 Thread Geert Uytterhoeven
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Mark Brown 
Acked-by: Robin Murphy 
---
v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Split per subsystem.
---
 drivers/staging/vc04_services/Kconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/staging/vc04_services/Kconfig 
b/drivers/staging/vc04_services/Kconfig
index f5aaf7d629f0fae9..98064ce2c2b47c7f 100644
--- a/drivers/staging/vc04_services/Kconfig
+++ b/drivers/staging/vc04_services/Kconfig
@@ -1,6 +1,5 @@
 menuconfig BCM_VIDEOCORE
tristate "Broadcom VideoCore support"
-   depends on HAS_DMA
depends on OF
depends on RASPBERRYPI_FIRMWARE || (COMPILE_TEST && 
!RASPBERRYPI_FIRMWARE)
default y
-- 
2.7.4



[PATCH v2 13/21] mmc: Remove depends on HAS_DMA in case of platform dependency

2018-03-16 Thread Geert Uytterhoeven
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Mark Brown 
Acked-by: Robin Murphy 
---
v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Split per subsystem.
---
 drivers/mmc/host/Kconfig | 10 ++
 1 file changed, 2 insertions(+), 8 deletions(-)

diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 620c2d90a646f387..f6d43348b4a3e5d4 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -358,7 +358,6 @@ config MMC_MESON_MX_SDIO
tristate "Amlogic Meson6/Meson8/Meson8b SD/MMC Host Controller support"
depends on ARCH_MESON || COMPILE_TEST
depends on COMMON_CLK
-   depends on HAS_DMA
depends on OF
help
  This selects support for the SD/MMC Host Controller on
@@ -401,7 +400,6 @@ config MMC_OMAP
 
 config MMC_OMAP_HS
tristate "TI OMAP High Speed Multimedia Card Interface support"
-   depends on HAS_DMA
depends on ARCH_OMAP2PLUS || ARCH_KEYSTONE || COMPILE_TEST
help
  This selects the TI OMAP High Speed Multimedia card Interface.
@@ -511,7 +509,6 @@ config MMC_DAVINCI
 
 config MMC_GOLDFISH
tristate "goldfish qemu Multimedia Card Interface support"
-   depends on HAS_DMA
depends on GOLDFISH || COMPILE_TEST
help
  This selects the Goldfish Multimedia card Interface emulation
@@ -605,7 +602,7 @@ config MMC_SDHI
 
 config MMC_SDHI_SYS_DMAC
tristate "DMA for SDHI SD/SDIO controllers using SYS-DMAC"
-   depends on MMC_SDHI && HAS_DMA
+   depends on MMC_SDHI
default MMC_SDHI if (SUPERH || ARM)
help
  This provides DMA support for SDHI SD/SDIO controllers
@@ -615,7 +612,7 @@ config MMC_SDHI_SYS_DMAC
 config MMC_SDHI_INTERNAL_DMAC
tristate "DMA for SDHI SD/SDIO controllers using on-chip bus mastering"
depends on ARM64 || COMPILE_TEST
-   depends on MMC_SDHI && HAS_DMA
+   depends on MMC_SDHI
default MMC_SDHI if ARM64
help
  This provides DMA support for SDHI SD/SDIO controllers
@@ -688,7 +685,6 @@ config MMC_CAVIUM_THUNDERX
 
 config MMC_DW
tristate "Synopsys DesignWare Memory Card Interface"
-   depends on HAS_DMA
depends on ARC || ARM || ARM64 || MIPS || COMPILE_TEST
help
  This selects support for the Synopsys DesignWare Mobile Storage IP
@@ -758,7 +754,6 @@ config MMC_DW_ZX
 
 config MMC_SH_MMCIF
tristate "SuperH Internal MMCIF support"
-   depends on HAS_DMA
depends on SUPERH || ARCH_RENESAS || COMPILE_TEST
help
  This selects the MMC Host Interface controller (MMCIF) found in 
various
@@ -878,7 +873,6 @@ config MMC_TOSHIBA_PCI
 config MMC_BCM2835
tristate "Broadcom BCM2835 SDHOST MMC Controller support"
depends on ARCH_BCM2835 || COMPILE_TEST
-   depends on HAS_DMA
help
  This selects the BCM2835 SDHOST MMC controller. If you have
  a BCM2835 platform with SD or MMC devices, say Y or M here.
-- 
2.7.4



[PATCH v2 05/21] firewire: Remove depends on HAS_DMA in case of platform dependency

2018-03-16 Thread Geert Uytterhoeven
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Mark Brown 
Acked-by: Robin Murphy 
---
v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Split per subsystem.
---
 drivers/firewire/Kconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/firewire/Kconfig b/drivers/firewire/Kconfig
index 145974f9662b63e6..4199849e37585181 100644
--- a/drivers/firewire/Kconfig
+++ b/drivers/firewire/Kconfig
@@ -1,5 +1,4 @@
 menu "IEEE 1394 (FireWire) support"
-   depends on HAS_DMA
depends on PCI || COMPILE_TEST
# firewire-core does not depend on PCI but is
# not useful without PCI controller driver
-- 
2.7.4



[PATCH v2 21/21] usb: Remove depends on HAS_DMA in case of platform dependency

2018-03-16 Thread Geert Uytterhoeven
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Mark Brown 
Acked-by: Robin Murphy 
Acked-by: Felipe Balbi  [drivers/usb/gadget/]
---
v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Split per subsystem.
---
 drivers/usb/gadget/udc/Kconfig | 4 ++--
 drivers/usb/mtu3/Kconfig   | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/gadget/udc/Kconfig b/drivers/usb/gadget/udc/Kconfig
index 0875d38476ee9395..9c3b4f86965e80c7 100644
--- a/drivers/usb/gadget/udc/Kconfig
+++ b/drivers/usb/gadget/udc/Kconfig
@@ -179,7 +179,7 @@ config USB_R8A66597
 
 config USB_RENESAS_USBHS_UDC
tristate 'Renesas USBHS controller'
-   depends on USB_RENESAS_USBHS && HAS_DMA
+   depends on USB_RENESAS_USBHS
help
   Renesas USBHS is a discrete USB host and peripheral controller chip
   that supports both full and high speed USB 2.0 data transfers.
@@ -192,7 +192,7 @@ config USB_RENESAS_USBHS_UDC
 config USB_RENESAS_USB3
tristate 'Renesas USB3.0 Peripheral controller'
depends on ARCH_RENESAS || COMPILE_TEST
-   depends on EXTCON && HAS_DMA
+   depends on EXTCON
help
   Renesas USB3.0 Peripheral controller is a USB peripheral controller
   that supports super, high, and full speed USB 3.0 data transfers.
diff --git a/drivers/usb/mtu3/Kconfig b/drivers/usb/mtu3/Kconfig
index 25cd61947beea51e..c0c0eb88e5eafc74 100644
--- a/drivers/usb/mtu3/Kconfig
+++ b/drivers/usb/mtu3/Kconfig
@@ -2,7 +2,7 @@
 
 config USB_MTU3
tristate "MediaTek USB3 Dual Role controller"
-   depends on EXTCON && (USB || USB_GADGET) && HAS_DMA
+   depends on EXTCON && (USB || USB_GADGET)
depends on ARCH_MEDIATEK || COMPILE_TEST
select USB_XHCI_MTK if USB_SUPPORT && USB_XHCI_HCD
help
-- 
2.7.4



[PATCH v2 12/21] media: Remove depends on HAS_DMA in case of platform dependency

2018-03-16 Thread Geert Uytterhoeven
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Note:
  - The various VIDEOBUF*DMA* symbols had to loose their dependencies on
HAS_DMA, as they are selected by several individual drivers.

Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Mark Brown 
Acked-by: Robin Murphy 
---
v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Drop dependency of VIDEOBUF{,2}_DMA_{CONTIG,SG} on HAS_DMA,
  - Drop new dependencies of VIDEO_IPU3_CIO2 and DVB_C8SECTPFE on
HAS_DMA,
  - Split per subsystem.
---
 drivers/media/common/videobuf2/Kconfig   |  2 --
 drivers/media/pci/dt3155/Kconfig |  1 -
 drivers/media/pci/intel/ipu3/Kconfig |  1 -
 drivers/media/pci/solo6x10/Kconfig   |  1 -
 drivers/media/pci/sta2x11/Kconfig|  1 -
 drivers/media/pci/tw5864/Kconfig |  1 -
 drivers/media/pci/tw686x/Kconfig |  1 -
 drivers/media/platform/Kconfig   | 40 +---
 drivers/media/platform/am437x/Kconfig|  2 +-
 drivers/media/platform/atmel/Kconfig |  4 +--
 drivers/media/platform/blackfin/Kconfig  |  1 -
 drivers/media/platform/davinci/Kconfig   |  6 -
 drivers/media/platform/marvell-ccic/Kconfig  |  3 +--
 drivers/media/platform/rcar-vin/Kconfig  |  2 +-
 drivers/media/platform/soc_camera/Kconfig|  3 +--
 drivers/media/platform/sti/c8sectpfe/Kconfig |  2 +-
 drivers/media/v4l2-core/Kconfig  |  2 --
 drivers/staging/media/davinci_vpfe/Kconfig   |  1 -
 drivers/staging/media/omap4iss/Kconfig   |  1 -
 19 files changed, 20 insertions(+), 55 deletions(-)

diff --git a/drivers/media/common/videobuf2/Kconfig 
b/drivers/media/common/videobuf2/Kconfig
index 17c32ea58395d78f..4ed11b46676ac4d0 100644
--- a/drivers/media/common/videobuf2/Kconfig
+++ b/drivers/media/common/videobuf2/Kconfig
@@ -12,7 +12,6 @@ config VIDEOBUF2_MEMOPS
 
 config VIDEOBUF2_DMA_CONTIG
tristate
-   depends on HAS_DMA
select VIDEOBUF2_CORE
select VIDEOBUF2_MEMOPS
select DMA_SHARED_BUFFER
@@ -25,7 +24,6 @@ config VIDEOBUF2_VMALLOC
 
 config VIDEOBUF2_DMA_SG
tristate
-   depends on HAS_DMA
select VIDEOBUF2_CORE
select VIDEOBUF2_MEMOPS
 
diff --git a/drivers/media/pci/dt3155/Kconfig b/drivers/media/pci/dt3155/Kconfig
index 5145e0dfa2aa9e12..858b0f2f15bef9c8 100644
--- a/drivers/media/pci/dt3155/Kconfig
+++ b/drivers/media/pci/dt3155/Kconfig
@@ -1,7 +1,6 @@
 config VIDEO_DT3155
tristate "DT3155 frame grabber"
depends on PCI && VIDEO_DEV && VIDEO_V4L2
-   depends on HAS_DMA
select VIDEOBUF2_DMA_CONTIG
default n
---help---
diff --git a/drivers/media/pci/intel/ipu3/Kconfig 
b/drivers/media/pci/intel/ipu3/Kconfig
index a82d3fe277d2cdec..2533ec1cb1177715 100644
--- a/drivers/media/pci/intel/ipu3/Kconfig
+++ b/drivers/media/pci/intel/ipu3/Kconfig
@@ -4,7 +4,6 @@ config VIDEO_IPU3_CIO2
depends on VIDEO_V4L2_SUBDEV_API
depends on X86 || COMPILE_TEST
depends on MEDIA_CONTROLLER
-   depends on HAS_DMA
depends on ACPI
select V4L2_FWNODE
select VIDEOBUF2_DMA_SG
diff --git a/drivers/media/pci/solo6x10/Kconfig 
b/drivers/media/pci/solo6x10/Kconfig
index 0fb91dc7ca73529e..d9e06a6bf1ebc1a7 100644
--- a/drivers/media/pci/solo6x10/Kconfig
+++ b/drivers/media/pci/solo6x10/Kconfig
@@ -1,7 +1,6 @@
 config VIDEO_SOLO6X10
tristate "Bluecherry / Softlogic 6x10 capture cards (MPEG-4/H.264)"
depends on PCI && VIDEO_DEV && SND && I2C
-   depends on HAS_DMA
select BITREVERSE
select FONT_SUPPORT
select FONT_8x16
diff --git a/drivers/media/pci/sta2x11/Kconfig 
b/drivers/media/pci/sta2x11/Kconfig
index e03587b1af714199..7b856395ede9295c 100644
--- a/drivers/media/pci/sta2x11/Kconfig
+++ b/drivers/media/pci/sta2x11/Kconfig
@@ -1,7 +1,6 @@
 config STA2X11_VIP
tristate "STA2X11 VIP Video For Linux"
depends on STA2X11
-   depends on HAS_DMA
select VIDEO_ADV7180 if MEDIA_SUBDRV_AUTOSELECT
select VIDEOBUF2_DMA_CONTIG
depends on PCI && VIDEO_V4L2 && VIRT_TO_BUS
diff --git a/drivers/media/pci/tw5864/Kconfig b/drivers/media/pci/tw5864/Kconfig
index 87c8f327e2d49dfa..760fb11dfeaef47b 100644
--- a/drivers/media/pci/tw5864/Kconfig
+++ b/drivers/media/pci/tw5864/Kconfig
@@ -1,7 +1,6 @@
 config VIDEO_TW5864
tristate "Techwell TW5864 video/audio grabber and encoder"
depends on VID

[PATCH v2 19/21] spi: Remove depends on HAS_DMA in case of platform dependency

2018-03-16 Thread Geert Uytterhoeven
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Mark Brown 
Acked-by: Robin Murphy 
---
v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Split per subsystem.
---
 drivers/spi/Kconfig | 12 +++-
 1 file changed, 3 insertions(+), 9 deletions(-)

diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 603783976b8152d4..7bd3a94f58511c41 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -71,7 +71,6 @@ config SPI_ARMADA_3700
 
 config SPI_ATMEL
tristate "Atmel SPI Controller"
-   depends on HAS_DMA
depends on (ARCH_AT91 || AVR32 || COMPILE_TEST)
help
  This selects a driver for the Atmel SPI Controller, present on
@@ -252,7 +251,6 @@ config SPI_EFM32
 
 config SPI_EP93XX
tristate "Cirrus Logic EP93xx SPI controller"
-   depends on HAS_DMA
depends on ARCH_EP93XX || COMPILE_TEST
help
  This enables using the Cirrus EP93xx SPI controller in master
@@ -374,7 +372,6 @@ config SPI_FSL_SPI
 config SPI_FSL_DSPI
tristate "Freescale DSPI controller"
select REGMAP_MMIO
-   depends on HAS_DMA
depends on SOC_VF610 || SOC_LS1021A || ARCH_LAYERSCAPE || M5441x || 
COMPILE_TEST
help
  This enables support for the Freescale DSPI controller in master
@@ -450,7 +447,6 @@ config SPI_OMAP_UWIRE
 
 config SPI_OMAP24XX
tristate "McSPI driver for OMAP"
-   depends on HAS_DMA
depends on ARCH_OMAP2PLUS || COMPILE_TEST
select SG_SPLIT
help
@@ -459,7 +455,6 @@ config SPI_OMAP24XX
 
 config SPI_TI_QSPI
tristate "DRA7xxx QSPI controller support"
-   depends on HAS_DMA
depends on ARCH_OMAP2PLUS || COMPILE_TEST
help
  QSPI master controller for DRA7xxx used for flash devices.
@@ -488,7 +483,6 @@ config SPI_PIC32
 config SPI_PIC32_SQI
tristate "Microchip PIC32 Quad SPI driver"
depends on MACH_PIC32 || COMPILE_TEST
-   depends on HAS_DMA
help
  SPI driver for PIC32 Quad SPI controller.
 
@@ -591,7 +585,7 @@ config SPI_SC18IS602
 
 config SPI_SH_MSIOF
tristate "SuperH MSIOF SPI controller"
-   depends on HAVE_CLK && HAS_DMA
+   depends on HAVE_CLK
depends on ARCH_SHMOBILE || ARCH_RENESAS || COMPILE_TEST
help
  SPI driver for SuperH and SH Mobile MSIOF blocks.
@@ -669,7 +663,7 @@ config SPI_MXS
 config SPI_TEGRA114
tristate "NVIDIA Tegra114 SPI Controller"
depends on (ARCH_TEGRA && TEGRA20_APB_DMA) || COMPILE_TEST
-   depends on RESET_CONTROLLER && HAS_DMA
+   depends on RESET_CONTROLLER
help
  SPI driver for NVIDIA Tegra114 SPI Controller interface. This 
controller
  is different than the older SoCs SPI controller and also register 
interface
@@ -687,7 +681,7 @@ config SPI_TEGRA20_SFLASH
 config SPI_TEGRA20_SLINK
tristate "Nvidia Tegra20/Tegra30 SLINK Controller"
depends on (ARCH_TEGRA && TEGRA20_APB_DMA) || COMPILE_TEST
-   depends on RESET_CONTROLLER && HAS_DMA
+   depends on RESET_CONTROLLER
help
  SPI driver for Nvidia Tegra20/Tegra30 SLINK Controller interface.
 
-- 
2.7.4



[PATCH v2 02/21] ata: Remove depends on HAS_DMA in case of platform dependency

2018-03-16 Thread Geert Uytterhoeven
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Mark Brown 
Acked-by: Robin Murphy 
---
v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Split per subsystem.
---
 drivers/ata/Kconfig | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index a7120d6211546949..9eaeed1fb237fa33 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -398,7 +398,6 @@ config SATA_DWC_VDEBUG
 
 config SATA_HIGHBANK
tristate "Calxeda Highbank SATA support"
-   depends on HAS_DMA
depends on ARCH_HIGHBANK || COMPILE_TEST
help
  This option enables support for the Calxeda Highbank SoC's
@@ -408,7 +407,6 @@ config SATA_HIGHBANK
 
 config SATA_MV
tristate "Marvell SATA support"
-   depends on HAS_DMA
depends on PCI || ARCH_DOVE || ARCH_MV78XX0 || \
   ARCH_MVEBU || ARCH_ORION5X || COMPILE_TEST
select GENERIC_PHY
-- 
2.7.4



[PATCH v2 14/21] mtd: Remove depends on HAS_DMA in case of platform dependency

2018-03-16 Thread Geert Uytterhoeven
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Mark Brown 
Acked-by: Robin Murphy 
---
v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Drop new dependency of MTD_NAND_MARVELL on HAS_DMA,
  - Split per subsystem.
---
 drivers/mtd/nand/Kconfig| 8 ++--
 drivers/mtd/spi-nor/Kconfig | 2 +-
 2 files changed, 3 insertions(+), 7 deletions(-)

diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 736ac887303c88ba..55a2f8a2fa90cd87 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -46,7 +46,7 @@ config MTD_NAND_DENALI
 config MTD_NAND_DENALI_PCI
 tristate "Support Denali NAND controller on Intel Moorestown"
select MTD_NAND_DENALI
-   depends on HAS_DMA && PCI
+   depends on PCI
 help
   Enable the driver for NAND flash on Intel Moorestown, using the
   Denali NAND controller core.
@@ -184,7 +184,6 @@ config MTD_NAND_S3C2410_CLKSTOP
 config MTD_NAND_TANGO
tristate "NAND Flash support for Tango chips"
depends on ARCH_TANGO || COMPILE_TEST
-   depends on HAS_DMA
help
  Enables the NAND Flash controller on Tango chips.
 
@@ -328,7 +327,7 @@ config MTD_NAND_MARVELL
tristate "NAND controller support on Marvell boards"
depends on PXA3xx || ARCH_MMP || PLAT_ORION || ARCH_MVEBU || \
   COMPILE_TEST
-   depends on HAS_IOMEM && HAS_DMA
+   depends on HAS_IOMEM
help
  This enables the NAND flash controller driver for Marvell boards,
  including:
@@ -490,7 +489,6 @@ config MTD_NAND_SH_FLCTL
tristate "Support for NAND on Renesas SuperH FLCTL"
depends on SUPERH || COMPILE_TEST
depends on HAS_IOMEM
-   depends on HAS_DMA
help
  Several Renesas SuperH CPU has FLCTL. This option enables support
  for NAND Flash using FLCTL.
@@ -558,7 +556,6 @@ config MTD_NAND_SUNXI
 config MTD_NAND_HISI504
tristate "Support for NAND controller on Hisilicon SoC Hip04"
depends on ARCH_HISI || COMPILE_TEST
-   depends on HAS_DMA
help
  Enables support for NAND controller on Hisilicon SoC Hip04.
 
@@ -572,7 +569,6 @@ config MTD_NAND_QCOM
 config MTD_NAND_MTK
tristate "Support for NAND controller on MTK SoCs"
depends on ARCH_MEDIATEK || COMPILE_TEST
-   depends on HAS_DMA
help
  Enables support for NAND controller on MTK SoCs.
  This controller is found on mt27xx, mt81xx, mt65xx SoCs.
diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig
index 89da88e591215db1..c493b8230a38c059 100644
--- a/drivers/mtd/spi-nor/Kconfig
+++ b/drivers/mtd/spi-nor/Kconfig
@@ -71,7 +71,7 @@ config SPI_FSL_QUADSPI
 config SPI_HISI_SFC
tristate "Hisilicon SPI-NOR Flash Controller(SFC)"
depends on ARCH_HISI || COMPILE_TEST
-   depends on HAS_IOMEM && HAS_DMA
+   depends on HAS_IOMEM
help
  This enables support for hisilicon SPI-NOR flash controller.
 
-- 
2.7.4



[PATCH v2 06/21] fpga: Remove depends on HAS_DMA in case of platform dependency

2018-03-16 Thread Geert Uytterhoeven
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Mark Brown 
Acked-by: Robin Murphy 
---
v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Split per subsystem.
---
 drivers/fpga/Kconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
index f47ef848bcd056d5..fd539132542e30ee 100644
--- a/drivers/fpga/Kconfig
+++ b/drivers/fpga/Kconfig
@@ -53,7 +53,6 @@ config FPGA_MGR_ALTERA_CVP
 config FPGA_MGR_ZYNQ_FPGA
tristate "Xilinx Zynq FPGA"
depends on ARCH_ZYNQ || COMPILE_TEST
-   depends on HAS_DMA
help
  FPGA manager driver support for Xilinx Zynq FPGAs.
 
-- 
2.7.4



[PATCH v2 15/21] net: Remove depends on HAS_DMA in case of platform dependency

2018-03-16 Thread Geert Uytterhoeven
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Note:
  - FSL_FMAN keeps its dependency on HAS_DMA, as it calls set_dma_ops().
set_dma_ops() does not exist if NO_DMA=y, and its use in this driver
is questionable.

Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Mark Brown 
Acked-by: Robin Murphy 
---
v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Split per subsystem.
---
 drivers/net/ethernet/amd/Kconfig| 2 +-
 drivers/net/ethernet/apm/xgene-v2/Kconfig   | 1 -
 drivers/net/ethernet/apm/xgene/Kconfig  | 1 -
 drivers/net/ethernet/arc/Kconfig| 6 --
 drivers/net/ethernet/broadcom/Kconfig   | 2 --
 drivers/net/ethernet/calxeda/Kconfig| 2 +-
 drivers/net/ethernet/hisilicon/Kconfig  | 2 +-
 drivers/net/ethernet/marvell/Kconfig| 8 +++-
 drivers/net/ethernet/mellanox/mlxsw/Kconfig | 2 +-
 drivers/net/ethernet/renesas/Kconfig| 2 --
 drivers/net/wireless/broadcom/brcm80211/Kconfig | 1 -
 drivers/net/wireless/quantenna/qtnfmac/Kconfig  | 2 +-
 12 files changed, 12 insertions(+), 19 deletions(-)

diff --git a/drivers/net/ethernet/amd/Kconfig b/drivers/net/ethernet/amd/Kconfig
index d5c15e8bb3de706b..f273af136fc7c995 100644
--- a/drivers/net/ethernet/amd/Kconfig
+++ b/drivers/net/ethernet/amd/Kconfig
@@ -173,7 +173,7 @@ config SUNLANCE
 
 config AMD_XGBE
tristate "AMD 10GbE Ethernet driver"
-   depends on ((OF_NET && OF_ADDRESS) || ACPI || PCI) && HAS_IOMEM && 
HAS_DMA
+   depends on ((OF_NET && OF_ADDRESS) || ACPI || PCI) && HAS_IOMEM
depends on X86 || ARM64 || COMPILE_TEST
select BITREVERSE
select CRC32
diff --git a/drivers/net/ethernet/apm/xgene-v2/Kconfig 
b/drivers/net/ethernet/apm/xgene-v2/Kconfig
index 1205861b631896a0..eedd3f3dd22e2201 100644
--- a/drivers/net/ethernet/apm/xgene-v2/Kconfig
+++ b/drivers/net/ethernet/apm/xgene-v2/Kconfig
@@ -1,6 +1,5 @@
 config NET_XGENE_V2
tristate "APM X-Gene SoC Ethernet-v2 Driver"
-   depends on HAS_DMA
depends on ARCH_XGENE || COMPILE_TEST
help
  This is the Ethernet driver for the on-chip ethernet interface
diff --git a/drivers/net/ethernet/apm/xgene/Kconfig 
b/drivers/net/ethernet/apm/xgene/Kconfig
index afccb033177b3923..e4e33c900b577161 100644
--- a/drivers/net/ethernet/apm/xgene/Kconfig
+++ b/drivers/net/ethernet/apm/xgene/Kconfig
@@ -1,6 +1,5 @@
 config NET_XGENE
tristate "APM X-Gene SoC Ethernet Driver"
-   depends on HAS_DMA
depends on ARCH_XGENE || COMPILE_TEST
select PHYLIB
select MDIO_XGENE
diff --git a/drivers/net/ethernet/arc/Kconfig b/drivers/net/ethernet/arc/Kconfig
index e743ddf46343302f..5d0ab8e74b680cc6 100644
--- a/drivers/net/ethernet/arc/Kconfig
+++ b/drivers/net/ethernet/arc/Kconfig
@@ -24,7 +24,8 @@ config ARC_EMAC_CORE
 config ARC_EMAC
tristate "ARC EMAC support"
select ARC_EMAC_CORE
-   depends on OF_IRQ && OF_NET && HAS_DMA && (ARC || COMPILE_TEST)
+   depends on OF_IRQ && OF_NET
+   depends on ARC || COMPILE_TEST
---help---
  On some legacy ARC (Synopsys) FPGA boards such as ARCAngel4/ML50x
  non-standard on-chip ethernet device ARC EMAC 10/100 is used.
@@ -33,7 +34,8 @@ config ARC_EMAC
 config EMAC_ROCKCHIP
tristate "Rockchip EMAC support"
select ARC_EMAC_CORE
-   depends on OF_IRQ && OF_NET && REGULATOR && HAS_DMA && (ARCH_ROCKCHIP 
|| COMPILE_TEST)
+   depends on OF_IRQ && OF_NET && REGULATOR
+   depends on ARCH_ROCKCHIP || COMPILE_TEST
---help---
  Support for Rockchip RK3036/RK3066/RK3188 EMAC ethernet controllers.
  This selects Rockchip SoC glue layer support for the
diff --git a/drivers/net/ethernet/broadcom/Kconfig 
b/drivers/net/ethernet/broadcom/Kconfig
index af75156919edfead..4c3bfde6e8de00f2 100644
--- a/drivers/net/ethernet/broadcom/Kconfig
+++ b/drivers/net/ethernet/broadcom/Kconfig
@@ -157,7 +157,6 @@ config BGMAC
 config BGMAC_BCMA
tristate "Broadcom iProc GBit BCMA support"
depends on BCMA && BCMA_HOST_SOC
-   depends on HAS_DMA
depends on BCM47XX || ARCH_BCM_5301X || COMPILE_TEST
select BGMAC
select PHYLIB
@@ -170,7 +169,6 @@ config BGMAC_BCMA
 
 config BGMAC_PLATFORM
tristate "Broadcom iProc GBit platform support"
-  

[PATCH v2 11/21] mailbox: Remove depends on HAS_DMA in case of platform dependency

2018-03-16 Thread Geert Uytterhoeven
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Notes:
  - FSL_FMAN keeps its dependency on HAS_DMA, as it calls set_dma_ops(),
which does not exist if HAS_DMA=n (Do we need a dummy? The use of
set_dma_ops() in this driver is questionable),
  - SND_SOC_LPASS_IPQ806X and SND_SOC_LPASS_PLATFORM loose their
dependency on HAS_DMA, as they are selected from
SND_SOC_APQ8016_SBC.

Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Mark Brown 
Acked-by: Robin Murphy 
---
v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Split per subsystem.
---
 drivers/mailbox/Kconfig | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index ba2f1525f4eef454..f3c68fe15180d035 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -154,7 +154,6 @@ config XGENE_SLIMPRO_MBOX
 config BCM_PDC_MBOX
tristate "Broadcom FlexSparx DMA Mailbox"
depends on ARCH_BCM_IPROC || COMPILE_TEST
-   depends on HAS_DMA
help
  Mailbox implementation for the Broadcom FlexSparx DMA ring manager,
  which provides access to various offload engines on Broadcom
@@ -164,7 +163,6 @@ config BCM_FLEXRM_MBOX
tristate "Broadcom FlexRM Mailbox"
depends on ARM64
depends on ARCH_BCM_IPROC || COMPILE_TEST
-   depends on HAS_DMA
select GENERIC_MSI_IRQ_DOMAIN
default m if ARCH_BCM_IPROC
help
-- 
2.7.4



[PATCH v2 17/21] scsi: hisi_sas: Remove depends on HAS_DMA in case of platform dependency

2018-03-16 Thread Geert Uytterhoeven
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Mark Brown 
Acked-by: Robin Murphy 
---
v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Split per subsystem.
---
 drivers/scsi/hisi_sas/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/hisi_sas/Kconfig b/drivers/scsi/hisi_sas/Kconfig
index d42f29a5eb65046d..57183fce70fb6355 100644
--- a/drivers/scsi/hisi_sas/Kconfig
+++ b/drivers/scsi/hisi_sas/Kconfig
@@ -1,6 +1,6 @@
 config SCSI_HISI_SAS
tristate "HiSilicon SAS"
-   depends on HAS_DMA && HAS_IOMEM
+   depends on HAS_IOMEM
depends on ARM64 || COMPILE_TEST
select SCSI_SAS_LIBSAS
select BLK_DEV_INTEGRITY
-- 
2.7.4



[PATCH v2 4/5] mm: Add NO_DMA dummies for DMA pool API

2018-03-16 Thread Geert Uytterhoeven
Add dummies for dma{,m}_pool_{create,destroy,alloc,free}(), to allow
compile-testing if NO_DMA=y.

This prevents the following from showing up later:

ERROR: "dma_pool_destroy" [drivers/usb/mtu3/mtu3.ko] undefined!
ERROR: "dma_pool_free" [drivers/usb/mtu3/mtu3.ko] undefined!
ERROR: "dma_pool_alloc" [drivers/usb/mtu3/mtu3.ko] undefined!
ERROR: "dma_pool_create" [drivers/usb/mtu3/mtu3.ko] undefined!
ERROR: "dma_pool_destroy" [drivers/scsi/hisi_sas/hisi_sas_main.ko] 
undefined!
ERROR: "dma_pool_free" [drivers/scsi/hisi_sas/hisi_sas_main.ko] undefined!
ERROR: "dma_pool_alloc" [drivers/scsi/hisi_sas/hisi_sas_main.ko] undefined!
ERROR: "dma_pool_create" [drivers/scsi/hisi_sas/hisi_sas_main.ko] undefined!
ERROR: "dma_pool_alloc" [drivers/mailbox/bcm-pdc-mailbox.ko] undefined!
ERROR: "dma_pool_free" [drivers/mailbox/bcm-pdc-mailbox.ko] undefined!
ERROR: "dma_pool_create" [drivers/mailbox/bcm-pdc-mailbox.ko] undefined!
    ERROR: "dma_pool_destroy" [drivers/mailbox/bcm-pdc-mailbox.ko] undefined!

Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Mark Brown 
Acked-by: Robin Murphy 
---
v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Group NO_DMA-stubs under a single #ifdef,
  - Move dma_pool_zalloc() definition down.
---
 include/linux/dmapool.h | 30 +++---
 1 file changed, 23 insertions(+), 7 deletions(-)

diff --git a/include/linux/dmapool.h b/include/linux/dmapool.h
index 53ba737505df31c7..f632ecfb4238404e 100644
--- a/include/linux/dmapool.h
+++ b/include/linux/dmapool.h
@@ -16,6 +16,8 @@
 
 struct device;
 
+#ifdef CONFIG_HAS_DMA
+
 struct dma_pool *dma_pool_create(const char *name, struct device *dev, 
size_t size, size_t align, size_t allocation);
 
@@ -23,13 +25,6 @@ void dma_pool_destroy(struct dma_pool *pool);
 
 void *dma_pool_alloc(struct dma_pool *pool, gfp_t mem_flags,
 dma_addr_t *handle);
-
-static inline void *dma_pool_zalloc(struct dma_pool *pool, gfp_t mem_flags,
-   dma_addr_t *handle)
-{
-   return dma_pool_alloc(pool, mem_flags | __GFP_ZERO, handle);
-}
-
 void dma_pool_free(struct dma_pool *pool, void *vaddr, dma_addr_t addr);
 
 /*
@@ -39,5 +34,26 @@ struct dma_pool *dmam_pool_create(const char *name, struct 
device *dev,
  size_t size, size_t align, size_t allocation);
 void dmam_pool_destroy(struct dma_pool *pool);
 
+#else /* !CONFIG_HAS_DMA */
+static inline struct dma_pool *dma_pool_create(const char *name,
+   struct device *dev, size_t size, size_t align, size_t allocation)
+{ return NULL; }
+static inline void dma_pool_destroy(struct dma_pool *pool) { }
+static inline void *dma_pool_alloc(struct dma_pool *pool, gfp_t mem_flags,
+  dma_addr_t *handle) { return NULL; }
+static inline void dma_pool_free(struct dma_pool *pool, void *vaddr,
+dma_addr_t addr) { }
+static inline struct dma_pool *dmam_pool_create(const char *name,
+   struct device *dev, size_t size, size_t align, size_t allocation)
+{ return NULL; }
+static inline void dmam_pool_destroy(struct dma_pool *pool) { }
+#endif /* !CONFIG_HAS_DMA */
+
+static inline void *dma_pool_zalloc(struct dma_pool *pool, gfp_t mem_flags,
+   dma_addr_t *handle)
+{
+   return dma_pool_alloc(pool, mem_flags | __GFP_ZERO, handle);
+}
+
 #endif
 
-- 
2.7.4



[PATCH v2 0/5] Allow compile-testing NO_DMA (core)

2018-03-16 Thread Geert Uytterhoeven
Hi all,

If NO_DMA=y, get_dma_ops() returns a reference to the non-existing
symbol bad_dma_ops, thus causing a link failure if it is ever used.

The intention of this is twofold:
  1. To catch users of the DMA API on systems that do no support the DMA
 mapping API,
  2. To avoid building drivers that cannot work on such systems anyway.

However, the disadvantage is that we have to keep on adding dependencies
on HAS_DMA all over the place.

Thanks to the COMPILE_TEST symbol, lots of drivers now depend on one or
more platform dependencies (that imply HAS_DMA) || COMPILE_TEST, thus
already covering intention #2.  Having to add an explicit dependency on
HAS_DMA here is cumbersome, and hinders compile-testing.

Hence I think the time is ripe to reconsider the link failure.
This patch series:
  - Changes get_dma_ops() to return NULL instead,
  - Adds a few more dummies to enable compile-testing.

A follow-up patch series will:
  - Remove dependencies on HAS_DMA for symbols that already have
platform dependencies implying HAS_DMA.

Changes compared to v1:
  - Add Reviewed-by, Acked-by,
  - Group NO_DMA-stubs for the DMA pool API under a single #ifdef,
  - Split the big Kconfig patch in per-subsystem patches, split-off in a
follow-up series.

This series is against v4.16-rc5. It can also be found at
https://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git/log/?h=no-dma-compile-testing-v2

It has been compile-tested with allmodconfig and allyesconfig for
m68k/sun3, and has received attention from the kbuild test robot.

Thanks!

Geert Uytterhoeven (5):
  dma-mapping: Convert NO_DMA get_dma_ops() into a real dummy
  dma-coherent: Add NO_DMA dummies for managed DMA API
  usb: gadget: Add NO_DMA dummies for DMA mapping API
  mm: Add NO_DMA dummies for DMA pool API
  scsi: Add NO_DMA dummies for SCSI DMA mapping API

 include/linux/dma-mapping.h | 19 ++-
 include/linux/dmapool.h | 30 +++---
 include/linux/usb/gadget.h  | 12 
 include/scsi/scsi_cmnd.h|  5 +
 4 files changed, 54 insertions(+), 12 deletions(-)

-- 
2.7.4

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds


[PATCH v2 2/5] dma-coherent: Add NO_DMA dummies for managed DMA API

2018-03-16 Thread Geert Uytterhoeven
Add dummies for dmam_{alloc,free}_coherent(), to allow compile-testing
if NO_DMA=y.

This prevents the following from showing up later:

ERROR: "dmam_alloc_coherent" [drivers/net/ethernet/arc/arc_emac.ko] 
undefined!
ERROR: "dmam_free_coherent" [drivers/net/ethernet/apm/xgene/xgene-enet.ko] 
undefined!
ERROR: "dmam_alloc_coherent" [drivers/net/ethernet/apm/xgene/xgene-enet.ko] 
undefined!
ERROR: "dmam_alloc_coherent" [drivers/mtd/nand/hisi504_nand.ko] undefined!
ERROR: "dmam_alloc_coherent" [drivers/mmc/host/dw_mmc.ko] undefined!

Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Mark Brown 
Acked-by: Robin Murphy 
---
v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state.
---
 include/linux/dma-mapping.h | 9 +
 1 file changed, 9 insertions(+)

diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 5ea7eec83c0fbb82..94f41846b933fca7 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -776,10 +776,19 @@ static inline void dma_deconfigure(struct device *dev) {}
 /*
  * Managed DMA API
  */
+#ifdef CONFIG_HAS_DMA
 extern void *dmam_alloc_coherent(struct device *dev, size_t size,
 dma_addr_t *dma_handle, gfp_t gfp);
 extern void dmam_free_coherent(struct device *dev, size_t size, void *vaddr,
   dma_addr_t dma_handle);
+#else /* !CONFIG_HAS_DMA */
+static inline void *dmam_alloc_coherent(struct device *dev, size_t size,
+   dma_addr_t *dma_handle, gfp_t gfp)
+{ return NULL; }
+static inline void dmam_free_coherent(struct device *dev, size_t size,
+ void *vaddr, dma_addr_t dma_handle) { }
+#endif /* !CONFIG_HAS_DMA */
+
 extern void *dmam_alloc_attrs(struct device *dev, size_t size,
  dma_addr_t *dma_handle, gfp_t gfp,
  unsigned long attrs);
-- 
2.7.4



[PATCH v2 1/5] dma-mapping: Convert NO_DMA get_dma_ops() into a real dummy

2018-03-16 Thread Geert Uytterhoeven
If NO_DMA=y, get_dma_ops() returns a reference to the
non-existing symbol bad_dma_ops, thus causing a link failure if it is
ever used.

Make get_dma_ops() return NULL instead, to avoid the link failure.
This allows to improve compile-testing, and limits the need to keep on
sprinkling dependencies on HAS_DMA all over the place.

Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Mark Brown 
Acked-by: Robin Murphy 
---
v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state.
---
 include/linux/dma-mapping.h | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index eb9eab4ecd6d7a05..5ea7eec83c0fbb82 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -212,14 +212,14 @@ static inline void set_dma_ops(struct device *dev,
 }
 #else
 /*
- * Define the dma api to allow compilation but not linking of
- * dma dependent code.  Code that depends on the dma-mapping
- * API needs to set 'depends on HAS_DMA' in its Kconfig
+ * Define the dma api to allow compilation of dma dependent code.
+ * Code that depends on the dma-mapping API needs to set 'depends on HAS_DMA'
+ * in its Kconfig, unless it already depends on  || COMPILE_TEST,
+ * where  guarantuees the availability of the dma-mapping API.
  */
-extern const struct dma_map_ops bad_dma_ops;
 static inline const struct dma_map_ops *get_dma_ops(struct device *dev)
 {
-   return &bad_dma_ops;
+   return NULL;
 }
 #endif
 
-- 
2.7.4



[PATCH v2 3/5] usb: gadget: Add NO_DMA dummies for DMA mapping API

2018-03-16 Thread Geert Uytterhoeven
Add dummies for usb_gadget_{,un}map_request{,_by_dev}(), to allow
compile-testing if NO_DMA=y.

This prevents the following from showing up later:

ERROR: "usb_gadget_unmap_request_by_dev" 
[drivers/usb/renesas_usbhs/renesas_usbhs.ko] undefined!
ERROR: "usb_gadget_map_request_by_dev" 
[drivers/usb/renesas_usbhs/renesas_usbhs.ko] undefined!
ERROR: "usb_gadget_map_request" [drivers/usb/mtu3/mtu3.ko] undefined!
ERROR: "usb_gadget_unmap_request" [drivers/usb/mtu3/mtu3.ko] undefined!
ERROR: "usb_gadget_map_request" [drivers/usb/gadget/udc/renesas_usb3.ko] 
undefined!
ERROR: "usb_gadget_unmap_request" [drivers/usb/gadget/udc/renesas_usb3.ko] 
undefined!

Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Mark Brown 
Acked-by: Robin Murphy 
Acked-by: Felipe Balbi 
---
v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state.
---
 include/linux/usb/gadget.h | 12 
 1 file changed, 12 insertions(+)

diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index 66a5cff7ee142d6a..b68e7f9b210be122 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -805,6 +805,7 @@ int usb_otg_descriptor_init(struct usb_gadget *gadget,
 
 /* utility to simplify map/unmap of usb_requests to/from DMA */
 
+#ifdef CONFIG_HAS_DMA
 extern int usb_gadget_map_request_by_dev(struct device *dev,
struct usb_request *req, int is_in);
 extern int usb_gadget_map_request(struct usb_gadget *gadget,
@@ -814,6 +815,17 @@ extern void usb_gadget_unmap_request_by_dev(struct device 
*dev,
struct usb_request *req, int is_in);
 extern void usb_gadget_unmap_request(struct usb_gadget *gadget,
struct usb_request *req, int is_in);
+#else /* !CONFIG_HAS_DMA */
+static inline int usb_gadget_map_request_by_dev(struct device *dev,
+   struct usb_request *req, int is_in) { return -ENOSYS; }
+static inline int usb_gadget_map_request(struct usb_gadget *gadget,
+   struct usb_request *req, int is_in) { return -ENOSYS; }
+
+static inline void usb_gadget_unmap_request_by_dev(struct device *dev,
+   struct usb_request *req, int is_in) { }
+static inline void usb_gadget_unmap_request(struct usb_gadget *gadget,
+   struct usb_request *req, int is_in) { }
+#endif /* !CONFIG_HAS_DMA */
 
 /*-*/
 
-- 
2.7.4



[PATCH v2 5/5] scsi: Add NO_DMA dummies for SCSI DMA mapping API

2018-03-16 Thread Geert Uytterhoeven
Add dummies for scsi_dma_{,un}map(), to allow compile-testing if
NO_DMA=y.

This prevents the following from showing up later:

ERROR: "scsi_dma_unmap" [drivers/firewire/firewire-sbp2.ko] undefined!
ERROR: "scsi_dma_map" [drivers/firewire/firewire-sbp2.ko] undefined!

Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Mark Brown 
Acked-by: Robin Murphy 
---
v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state.
---
 include/scsi/scsi_cmnd.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/include/scsi/scsi_cmnd.h b/include/scsi/scsi_cmnd.h
index 2280b2351739572c..aaf1e971c6a368d1 100644
--- a/include/scsi/scsi_cmnd.h
+++ b/include/scsi/scsi_cmnd.h
@@ -174,8 +174,13 @@ extern void scsi_kunmap_atomic_sg(void *virt);
 
 extern int scsi_init_io(struct scsi_cmnd *cmd);
 
+#ifdef CONFIG_SCSI_DMA
 extern int scsi_dma_map(struct scsi_cmnd *cmd);
 extern void scsi_dma_unmap(struct scsi_cmnd *cmd);
+#else /* !CONFIG_SCSI_DMA */
+static inline int scsi_dma_map(struct scsi_cmnd *cmd) { return -ENOSYS; }
+static inline void scsi_dma_unmap(struct scsi_cmnd *cmd) { }
+#endif /* !CONFIG_SCSI_DMA */
 
 static inline unsigned scsi_sg_count(struct scsi_cmnd *cmd)
 {
-- 
2.7.4



Re: [PATCH v3] m68k/amiga - Amiga Zorro NCR53C9x boards: new zorro_esp.c

2018-03-16 Thread Geert Uytterhoeven
Hi Michael,

On Fri, Mar 16, 2018 at 8:26 AM, Michael Schmitz  wrote:
> In the interest of making minimal changes between the Mac and Amiga
> versions, I'd leave the macros as they are, and add a comment to the
> macro definitions stating that both addr and fifo are local-scope
> variables in the only scope the macro is used in, to address reviewer's
> concerns. Can you both live with that?

Yes I can. Thanks!

Gr{oetje,eeting}s,

    Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds


Re: [PATCH 10/12] scsi: remove the mvme147 driver

2018-03-14 Thread Geert Uytterhoeven
Hi Martin,

On Wed, Mar 14, 2018 at 4:58 PM, Martin K. Petersen
 wrote:
>>>> IIRC, the Australian Navy may keep their MVME boxes running until
>>>> close to Y2038.
>>>>
>>> But surely not updating them to 4.17 or later?
>>
>> I don't know. Perhaps to prolong life until after Y2038 ;-)
>
> I'm happy to keep things in the tree if they are:
>
>   1) maintained and tested
>   2) actively used
>   3) not blocking removal of legacy interfaces

I'm aware and I do understand.

Lets wait for Adrian...

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds


Re: [PATCH 10/12] scsi: remove the mvme147 driver

2018-03-14 Thread Geert Uytterhoeven
Hi Hannes,

On Wed, Mar 14, 2018 at 4:26 PM, Hannes Reinecke  wrote:
> On 03/14/2018 02:25 PM, Geert Uytterhoeven wrote:
>> On Wed, Mar 14, 2018 at 2:16 PM, Christoph Hellwig  wrote:
>>> On Wed, Mar 14, 2018 at 12:56:31PM +0100, John Paul Adrian Glaubitz wrote:
>>>> Ah, bummer. I wanted to keep the MVME drivers but I never managed to get 
>>>> them ported to the new SCSI layer.
>>>>
>>>> Anyone out there who could help me with that?
>>>
>>> Here is how a trivial conversion should look like.  Probably doesn't
>>> even compile as-is but might be a good starting point:
>>
>> Thanks a lot!
>> IIRC, the Australian Navy may keep their MVME boxes running until close to
>> Y2038.
>>
> But surely not updating them to 4.17 or later?

I don't know. Perhaps to prolong life until after Y2038 ;-)

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds


Re: [PATCH 10/12] scsi: remove the mvme147 driver

2018-03-14 Thread Geert Uytterhoeven
Hi Christoph,

On Wed, Mar 14, 2018 at 2:16 PM, Christoph Hellwig  wrote:
> On Wed, Mar 14, 2018 at 12:56:31PM +0100, John Paul Adrian Glaubitz wrote:
>> Ah, bummer. I wanted to keep the MVME drivers but I never managed to get 
>> them ported to the new SCSI layer.
>>
>> Anyone out there who could help me with that?
>
> Here is how a trivial conversion should look like.  Probably doesn't
> even compile as-is but might be a good starting point:

Thanks a lot!
IIRC, the Australian Navy may keep their MVME boxes running until close to
Y2038.

Adrian: Do you have hardware to test this?

Gr{oetje,eeting}s,

    Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds


Re: [PATCH v3] m68k/amiga - Amiga Zorro NCR53C9x boards: new zorro_esp.c

2018-03-14 Thread Geert Uytterhoeven
Hi Michael,

On Wed, Mar 14, 2018 at 9:23 AM, Michael Schmitz  wrote:
> thanks for the review - largely uncontroversial except for the volatile...

The presence of volatile in drivers is always considered controversial ;-)

> Am 14.03.2018 um 20:49 schrieb Geert Uytterhoeven:
>>> +/* Blizzard 1230 DMA interface */
>>> +
>>> +struct blz1230_dma_registers {
>>> +   volatile unsigned char dma_addr;/* DMA address  
>>> [0x] */
>>
>> volatile considered harmful.
>
> Yes, I saw that. I also saw gcc miscompile the DMA set-up (in
> particular, the case where three bytes of the transfer address are
> stuffed consecutively into the same DMA address register).
>
>> If you would use proper *{read,write}*() accessors instead of direct
>> assignments,
>> you can drop the volatile's here.
>
> Meaning writeb(val, reg) instead of reg = val?
>
> #define out_8(addr,b) (void)((*(__force volatile u8 *) (addr)) = (b))
>
> nicely hides the 'volatile' but suggests I also need to pass it a
> pointer, so
>
> writeb((addr >> 24) & 0xff, &dregs->dma_addr)

Yes, you have to pass it an (__iomem) pointer.

> would do the same as
>
> dregs->dma_addr  = (addr >> 24) & 0xff; ??

Right.

> I'll have to compare the assembly generated by the two versions before I
> dare test that, but I'll give that a try. Liberal use of wmb() did fix
> the miscompile but that just looked too ugly.

Using the macros should have the same effect due to the embedded volatile.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds


Re: [PATCH v3] m68k/amiga - Amiga Zorro NCR53C9x boards: new zorro_esp.c

2018-03-14 Thread Geert Uytterhoeven
 moveb " operands "\n" \
> +"   moveb " operands "\n" \
> +"   moveb " operands "\n" \
> +"   moveb " operands "\n" \
> +"   moveb " operands "\n" \
> +"   moveb " operands "\n" \
> +"   moveb " operands "\n" \
> +"   moveb " operands "\n" \
> +"   moveb " operands "\n" \
> +"   moveb " operands "\n" \
> +"   subqw #8,%1   \n" \
> +"   subqw #8,%1   \n" \
> +: "+a" (addr), "+r" (reg1) \
> +: "a" (fifo)); \
> +   }

Likewise.

> +static int zorro_esp_probe(struct zorro_dev *z,
> +  const struct zorro_device_id *ent)
> +{
> +   struct scsi_host_template *tpnt = &scsi_esp_template;
> +   struct Scsi_Host *host;
> +   struct esp *esp;
> +   struct zorro_driver_data *zdd;
> +   struct zorro_esp_priv *zep;
> +   unsigned long board, ioaddr, dmaaddr;
> +   int err;
> +
> +   board = zorro_resource_start(z);
> +   zdd = (struct zorro_driver_data *)ent->driver_data;
> +
> +   pr_info("%s found at address 0x%lx.\n", zdd->name, board);
> +
> +   zep = kmalloc(sizeof(*zep), GFP_KERNEL);
> +   if (!zep) {
> +   pr_err("Can't allocate device private data!\n");
> +   return -ENOMEM;
> +   }
> +
> +   /* let's figure out whether we have a Zorro II or Zorro III board */
> +   if ((z->rom.er_Type & ERT_TYPEMASK) == ERT_ZORROIII) {
> +   /* note this is a Zorro III board */
> +   if (board > 0xff)
> +   zep->zorro3 = 1;
> +   } else

} else {

> +   /* Even though most of these boards identify as Zorro II,
> +* they are in fact CPU expansion slot boards and have full
> +* access to all of memory. Fix up DMA bitmask here.
> +*/
> +   z->dev.coherent_dma_mask = DMA_BIT_MASK(32);

}

> +   /* Switch to the correct the DMA routine and clock frequency. */
> +   switch (ent->id) {
> +   case ZORRO_PROD_PHASE5_BLIZZARD_2060:
> +   zorro_esp_ops.send_dma_cmd = zorro_esp_send_blz2060_dma_cmd;

Please use function pointers in struct zorro_driver_data, so you don't need
a switch() here (except for Fastlane vs. B1230II).

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds


Re: [PATCH 2/2] m68k/amiga - Zorro ESP: new zorro_esp.c

2018-03-07 Thread Geert Uytterhoeven
Hi Michael,

On Wed, Mar 7, 2018 at 8:55 AM, Michael Schmitz  wrote:
> OK, in that case I'll need to work out something similar to the test for
> optional SCSI function on the Blizzard 1230/1260 to find out what board
> I have when dealing with the duplicate Fastlane/Blizzard1230II ID.
>
> Is the board base address as returned by zorro_resource_start() reliable
> to distinguish between Zorro II and Zorro III boards?

The board base address is assigned by AmigaOS based on the values in the
Expansion ROM (mainly ExpansionRom.er_Type) on the board.
More specifically, AmigaOS creates struct ConfigDev from struct ExpansionRom.
So yes, it must be reliable.

> Am 06.03.2018 um 20:43 schrieb Geert Uytterhoeven:
>> On Tue, Mar 6, 2018 at 2:11 AM, Michael Schmitz  wrote:
>>> Index 1 should have been ZORRO_PROD_PHASE5_CYBERSTORM_MK_II, I've
>>> corrected that in the meantime.
>>>
>>> Fastlane / Blizzard 1230_II distinction is something I an not quite
>>> sure about - does the probe function get called twice if the device
>>> table contains the same ID twice but with different driver_data
>>> contents?
>>
>> No, the probe function gets called on the first match only.
>> Cfr. drivers/zorro/zorro-driver.c:zorro_device_probe().

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds


Re: [PATCH 2/2] m68k/amiga - Zorro ESP: new zorro_esp.c

2018-03-05 Thread Geert Uytterhoeven
Hi Michael,

On Tue, Mar 6, 2018 at 2:33 AM, Michael Schmitz  wrote:
> On Tue, Mar 6, 2018 at 12:29 AM, Geert Uytterhoeven
>  wrote:

>>> +static unsigned char ctrl_data;/* Keep backup of the stuff written
>>> +* to ctrl_reg. Always write a copy
>>> +* to this register when writing to
>>> +* the hardware register!
>>> +*/
>>
>> This should be part of the device's zorro_esp_priv.
>
> It's only used in the cyber_dma_setup, and I not actually read
> anywhere else. Might as well be on the stack instead of static...

OK, I missed that. Yes, local variable is better.

>>> +static int zorro_esp_init_one(struct zorro_dev *z,
>>> +  const struct zorro_device_id *ent)

BTW, please call the probe/remove functions zorro_esp_probe() resp.
zorro_esp_remove().

>>> +{
>>> +   struct scsi_host_template *tpnt = &scsi_esp_template;
>>> +   struct Scsi_Host *host;
>>> +   struct esp *esp;
>>> +   struct zorro_driver_data *zdd;
>>> +   struct zorro_esp_priv *zep;
>>> +   unsigned long board, ioaddr, dmaaddr;
>>> +   int err = -ENOMEM;
>>
>> Initialization not needed.
>
> The initialized err variable is used when bailing out ..
>
>>> +
>>> +   board = zorro_resource_start(z);
>>> +   zdd = (struct zorro_driver_data *)ent->driver_data;
>>> +
>>> +   pr_info(PFX "%s found at address 0x%lx.\n", zdd->name, board);
>>> +
>>> +   if (zdd->absolute) {
>>> +   ioaddr  = zdd->offset;
>>> +   dmaaddr = zdd->dma_offset;
>>> +   } else {
>>> +   ioaddr  = board + zdd->offset;
>>> +   dmaaddr = board + zdd->dma_offset;
>>> +   }
>>> +
>>> +   if (!zorro_request_device(z, zdd->name)) {
>>> +   pr_err(PFX "cannot reserve region 0x%lx, abort\n",
>>> +  board);
>>> +   return -EBUSY;
>>> +   }
>>> +
>>> +   /* Fill in the required pieces of hostdata */
>>> +
>>> +   host = scsi_host_alloc(tpnt, sizeof(struct esp));
>>> +
>>> +   if (!host) {
>>> +   pr_err(PFX "No host detected; board configuration 
>>> problem?\n");
>>> +   goto out_free;
>>> +   }
>
> here. But I can add the err=-NOMEM here.

After out_free it returns fixed -ENODEV ;-)

Doing "err = -ENOMEM" here, and returning err at the end is better, as
it propagates meaningful error codes.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds


Re: [PATCH 2/2] m68k/amiga - Zorro ESP: new zorro_esp.c

2018-03-05 Thread Geert Uytterhoeven
Hi Michael,

On Tue, Mar 6, 2018 at 2:11 AM, Michael Schmitz  wrote:
> Index 1 should have been ZORRO_PROD_PHASE5_CYBERSTORM_MK_II, I've
> corrected that in the meantime.
>
> Fastlane / Blizzard 1230_II distinction is something I an not quite
> sure about - does the probe function get called twice if the device
> table contains the same ID twice but with different driver_data
> contents?

No, the probe function gets called on the first match only.
Cfr. drivers/zorro/zorro-driver.c:zorro_device_probe().

Gr{oetje,eeting}s,

    Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds


Re: [PATCH 2/2] m68k/amiga - Zorro ESP: new zorro_esp.c

2018-03-05 Thread Geert Uytterhoeven
host;
> +   struct esp *esp;
> +   struct zorro_driver_data *zdd;
> +   struct zorro_esp_priv *zep;
> +   unsigned long board, ioaddr, dmaaddr;
> +   int err = -ENOMEM;

Initialization not needed.

> +
> +   board = zorro_resource_start(z);
> +   zdd = (struct zorro_driver_data *)ent->driver_data;
> +
> +   pr_info(PFX "%s found at address 0x%lx.\n", zdd->name, board);
> +
> +   if (zdd->absolute) {
> +   ioaddr  = zdd->offset;
> +   dmaaddr = zdd->dma_offset;
> +   } else {
> +   ioaddr  = board + zdd->offset;
> +   dmaaddr = board + zdd->dma_offset;
> +   }
> +
> +   if (!zorro_request_device(z, zdd->name)) {
> +   pr_err(PFX "cannot reserve region 0x%lx, abort\n",
> +  board);
> +   return -EBUSY;
> +   }
> +
> +   /* Fill in the required pieces of hostdata */
> +
> +   host = scsi_host_alloc(tpnt, sizeof(struct esp));
> +
> +   if (!host) {
> +   pr_err(PFX "No host detected; board configuration 
> problem?\n");
> +   goto out_free;
> +   }
> +
> +   host->base  = ioaddr;
> +   host->this_id   = 7;
> +
> +   esp = shost_priv(host);
> +   esp->host   = host;
> +   esp->dev= &z->dev;
> +
> +   esp->scsi_id= host->this_id;
> +   esp->scsi_id_mask   = (1 << esp->scsi_id);
> +
> +   /* Switch to the correct the DMA routine and clock frequency. */
> +   switch (ent->id) {
> +   case ZORRO_PROD_PHASE5_BLIZZARD_2060: {
> +   zorro_esp_ops.send_dma_cmd = zorro_esp_send_blz2060_dma_cmd;
> +   esp->cfreq = 4000;
> +   break;
> +   }
> +   case ZORRO_PROD_PHASE5_BLIZZARD_1230_IV_1260: {
> +   zorro_esp_ops.send_dma_cmd = zorro_esp_send_blz1230_dma_cmd;
> +   esp->cfreq = 4000;
> +   break;
> +   }
> +   case ZORRO_PROD_PHASE5_BLIZZARD_1220_CYBERSTORM: {
> +   zorro_esp_ops.send_dma_cmd = zorro_esp_send_cyber_dma_cmd;
> +   zorro_esp_ops.irq_pending  = cyber_esp_irq_pending;
> +   esp->cfreq = 4000;
> +   break;

Store send_dma_cmd and cfreq in zorro_driver_data?

> +   }
> +   default: {
> +   /* Oh noes */
> +   pr_err(PFX "Unsupported board!\n");
> +   goto fail_free_host;
> +   }
> +   }
> +
> +   esp->ops = &zorro_esp_ops;
> +
> +   if (ioaddr > 0xff)
> +   esp->regs = ioremap_nocache(ioaddr, 0x20);
> +   else
> +   esp->regs = (void __iomem *)ZTWO_VADDR(ioaddr);
> +
> +   if (!esp->regs)
> +   goto fail_free_host;
> +
> +   /* Let's check whether a Blizzard 12x0 really has SCSI */
> +   if ((ent->id == ZORRO_PROD_PHASE5_BLIZZARD_1230_IV_1260) ||
> +  (ent->id == 
> ZORRO_PROD_PHASE5_BLIZZARD_1230_II_FASTLANE_Z3_CYBERSCSI_CYBERSTORM060)) {

Add a flag to zorro_driver_data (optional_scsi?) instead of checking
for IDs here.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds


[PATCH/RFC 2/6] dma-coherent: Add NO_DMA dummies for managed DMA API

2018-02-06 Thread Geert Uytterhoeven
Add dummies for dmam_{alloc,free}_coherent(), to allow compile-testing
if NO_DMA=y.

This prevents the following from showing up later:

ERROR: "dmam_alloc_coherent" [drivers/net/ethernet/arc/arc_emac.ko] 
undefined!
ERROR: "dmam_free_coherent" [drivers/net/ethernet/apm/xgene/xgene-enet.ko] 
undefined!
ERROR: "dmam_alloc_coherent" [drivers/net/ethernet/apm/xgene/xgene-enet.ko] 
undefined!
ERROR: "dmam_alloc_coherent" [drivers/mtd/nand/hisi504_nand.ko] undefined!
ERROR: "dmam_alloc_coherent" [drivers/mmc/host/dw_mmc.ko] undefined!

Signed-off-by: Geert Uytterhoeven 
---
 include/linux/dma-mapping.h | 9 +
 1 file changed, 9 insertions(+)

diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index d78d7541f784875b..4d92956a4ddb8a5c 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -776,10 +776,19 @@ static inline void dma_deconfigure(struct device *dev) {}
 /*
  * Managed DMA API
  */
+#ifdef CONFIG_HAS_DMA
 extern void *dmam_alloc_coherent(struct device *dev, size_t size,
 dma_addr_t *dma_handle, gfp_t gfp);
 extern void dmam_free_coherent(struct device *dev, size_t size, void *vaddr,
   dma_addr_t dma_handle);
+#else /* !CONFIG_HAS_DMA */
+static inline void *dmam_alloc_coherent(struct device *dev, size_t size,
+   dma_addr_t *dma_handle, gfp_t gfp)
+{ return NULL; }
+static inline void dmam_free_coherent(struct device *dev, size_t size,
+ void *vaddr, dma_addr_t dma_handle) { }
+#endif /* !CONFIG_HAS_DMA */
+
 extern void *dmam_alloc_attrs(struct device *dev, size_t size,
  dma_addr_t *dma_handle, gfp_t gfp,
  unsigned long attrs);
-- 
2.7.4



[PATCH/RFC 0/6] Allow compile-testing NO_DMA

2018-02-06 Thread Geert Uytterhoeven
Hi all,

If NO_DMA=y, get_dma_ops() returns a reference to the non-existing
symbol bad_dma_ops, thus causing a link failure if it is ever used.

The intention of this is twofold:
  1. To catch users of the DMA API on systems that do no support the DMA
 mapping API,
  2. To avoid building drivers that cannot work on such systems anyway.

However, the disadvantage is that we have to keep on adding dependencies
on HAS_DMA all over the place.

Thanks to the COMPILE_TEST symbol, lots of drivers now depend on one or
more platform dependencies (that imply HAS_DMA) || COMPILE_TEST, thus
already covering intention #2.  Having to add an explicit dependency on
HAS_DMA here is cumbersome, and hinders compile-testing.

Hence I think the time is ripe to reconsider the link failure.
This patch series:
  - Changes get_dma_ops() to return NULL instead,
  - Adds a few more dummies to enable compile-testing,
  - Removes dependencies on HAS_DMA for symbols that already have
platform dependencies implying HAS_DMA.

Note that adding more platform dependencies and/or dependencies on
COMPILE_TEST is encouraged!

This may make life harder for UML, though, as UML usually satisfies all
other platform dependencies for HAS_DMA.  Similarly, HAS_IOMEM is even
more complicated.  Can/do we want to do something similar for
HAS_IOMEM?

This series is against my current local tree, which has a few more
"depends on HAS_DMA" than upstream.  Of course I will rebase, and split
the last patch per subsystem, if this RFC is welcomed positively.

Compile-tested with allmodconfig and allyesconfig for m68k/sun3.

Thanks for your comments!

Geert Uytterhoeven (6):
  [RFC] dma-mapping: Convert NO_DMA get_dma_ops() into a real dummy
  [RFC] dma-coherent: Add NO_DMA dummies for managed DMA API
  [RFC] usb: gadget: Add NO_DMA dummies for DMA mapping API
  [RFC] mm: Add NO_DMA dummies for DMA pool API
  [RFC] scsi: Add NO_DMA dummies for SCSI DMA mapping API
  [RFC] Treewide: Remove depends on HAS_DMA in case of platform
dependency

 drivers/ata/Kconfig |  2 --
 drivers/crypto/Kconfig  | 14 +++--
 drivers/firewire/Kconfig|  1 -
 drivers/fpga/Kconfig|  1 -
 drivers/gpu/ipu-v3/Kconfig  |  1 -
 drivers/i2c/busses/Kconfig  |  3 --
 drivers/iio/adc/Kconfig |  3 --
 drivers/iommu/Kconfig   |  5 ++--
 drivers/lightnvm/Kconfig|  2 +-
 drivers/mailbox/Kconfig |  2 --
 drivers/media/pci/dt3155/Kconfig|  1 -
 drivers/media/pci/solo6x10/Kconfig  |  1 -
 drivers/media/pci/sta2x11/Kconfig   |  1 -
 drivers/media/pci/tw5864/Kconfig|  1 -
 drivers/media/pci/tw686x/Kconfig|  1 -
 drivers/media/platform/Kconfig  | 40 -
 drivers/media/platform/am437x/Kconfig   |  2 +-
 drivers/media/platform/atmel/Kconfig|  4 +--
 drivers/media/platform/blackfin/Kconfig |  1 -
 drivers/media/platform/davinci/Kconfig  |  6 
 drivers/media/platform/marvell-ccic/Kconfig |  3 +-
 drivers/media/platform/rcar-vin/Kconfig |  2 +-
 drivers/media/platform/soc_camera/Kconfig   |  3 +-
 drivers/media/platform/sti/c8sectpfe/Kconfig|  2 +-
 drivers/mmc/host/Kconfig| 10 ++-
 drivers/mtd/nand/Kconfig|  8 ++---
 drivers/mtd/spi-nor/Kconfig |  2 +-
 drivers/net/ethernet/amd/Kconfig|  2 +-
 drivers/net/ethernet/apm/xgene-v2/Kconfig   |  1 -
 drivers/net/ethernet/apm/xgene/Kconfig  |  1 -
 drivers/net/ethernet/arc/Kconfig|  6 ++--
 drivers/net/ethernet/broadcom/Kconfig   |  2 --
 drivers/net/ethernet/calxeda/Kconfig|  2 +-
 drivers/net/ethernet/hisilicon/Kconfig  |  2 +-
 drivers/net/ethernet/marvell/Kconfig|  8 ++---
 drivers/net/ethernet/mellanox/mlxsw/Kconfig |  2 +-
 drivers/net/ethernet/renesas/Kconfig|  2 --
 drivers/net/ethernet/socionext/Kconfig  |  4 +--
 drivers/net/wireless/broadcom/brcm80211/Kconfig |  1 -
 drivers/net/wireless/quantenna/qtnfmac/Kconfig  |  2 +-
 drivers/remoteproc/Kconfig  |  1 -
 drivers/scsi/hisi_sas/Kconfig   |  2 +-
 drivers/spi/Kconfig | 12 ++--
 drivers/staging/media/davinci_vpfe/Kconfig  |  1 -
 drivers/staging/media/omap4iss/Kconfig  |  1 -
 drivers/staging/vc04_services/Kconfig   |  1 -
 drivers/tty/serial/Kconfig  |  4 ---
 drivers/usb/gadget/udc/Kconfig  |  4 +--
 drivers/usb/mtu3/Kconfig|  2 +-
 drivers/video/fbdev/Kconfig |  3 +-
 include/linux/dma-mapping.h   

[PATCH/RFC 1/6] dma-mapping: Convert NO_DMA get_dma_ops() into a real dummy

2018-02-06 Thread Geert Uytterhoeven
If NO_DMA=y, get_dma_ops() returns a reference to the
non-existing symbol bad_dma_ops, thus causing a link failure if it is
ever used.

Make get_dma_ops() return NULL instead, to avoid the link failure.
This allows to improve compile-testing, and limits the need to keep on
sprinkling dependencies on HAS_DMA all over the place.

Signed-off-by: Geert Uytterhoeven 
---
 include/linux/dma-mapping.h | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 34fe8463d10ea3be..d78d7541f784875b 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -212,14 +212,14 @@ static inline void set_dma_ops(struct device *dev,
 }
 #else
 /*
- * Define the dma api to allow compilation but not linking of
- * dma dependent code.  Code that depends on the dma-mapping
- * API needs to set 'depends on HAS_DMA' in its Kconfig
+ * Define the dma api to allow compilation of dma dependent code.
+ * Code that depends on the dma-mapping API needs to set 'depends on HAS_DMA'
+ * in its Kconfig, unless it already depends on  || COMPILE_TEST,
+ * where  guarantuees the availability of the dma-mapping API.
  */
-extern const struct dma_map_ops bad_dma_ops;
 static inline const struct dma_map_ops *get_dma_ops(struct device *dev)
 {
-   return &bad_dma_ops;
+   return NULL;
 }
 #endif
 
-- 
2.7.4



[PATCH/RFC 6/6] Treewide: Remove depends on HAS_DMA in case of platform dependency

2018-02-06 Thread Geert Uytterhoeven
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Notes:
  - FSL_FMAN keeps its dependency on HAS_DMA, as it calls set_dma_ops(),
which does not exist if HAS_DMA=n (Do we need a dummy? The use of
set_dma_ops() in this driver is questionable),
  - SND_SOC_LPASS_IPQ806X and SND_SOC_LPASS_PLATFORM loose their
dependency on HAS_DMA, as they are selected from
SND_SOC_APQ8016_SBC.

Signed-off-by: Geert Uytterhoeven 
---
 drivers/ata/Kconfig |  2 --
 drivers/crypto/Kconfig  | 14 +++--
 drivers/firewire/Kconfig|  1 -
 drivers/fpga/Kconfig|  1 -
 drivers/gpu/ipu-v3/Kconfig  |  1 -
 drivers/i2c/busses/Kconfig  |  3 --
 drivers/iio/adc/Kconfig |  3 --
 drivers/iommu/Kconfig   |  5 ++--
 drivers/lightnvm/Kconfig|  2 +-
 drivers/mailbox/Kconfig |  2 --
 drivers/media/pci/dt3155/Kconfig|  1 -
 drivers/media/pci/solo6x10/Kconfig  |  1 -
 drivers/media/pci/sta2x11/Kconfig   |  1 -
 drivers/media/pci/tw5864/Kconfig|  1 -
 drivers/media/pci/tw686x/Kconfig|  1 -
 drivers/media/platform/Kconfig  | 40 -
 drivers/media/platform/am437x/Kconfig   |  2 +-
 drivers/media/platform/atmel/Kconfig|  4 +--
 drivers/media/platform/blackfin/Kconfig |  1 -
 drivers/media/platform/davinci/Kconfig  |  6 
 drivers/media/platform/marvell-ccic/Kconfig |  3 +-
 drivers/media/platform/rcar-vin/Kconfig |  2 +-
 drivers/media/platform/soc_camera/Kconfig   |  3 +-
 drivers/media/platform/sti/c8sectpfe/Kconfig|  2 +-
 drivers/mmc/host/Kconfig| 10 ++-
 drivers/mtd/nand/Kconfig|  8 ++---
 drivers/mtd/spi-nor/Kconfig |  2 +-
 drivers/net/ethernet/amd/Kconfig|  2 +-
 drivers/net/ethernet/apm/xgene-v2/Kconfig   |  1 -
 drivers/net/ethernet/apm/xgene/Kconfig  |  1 -
 drivers/net/ethernet/arc/Kconfig|  6 ++--
 drivers/net/ethernet/broadcom/Kconfig   |  2 --
 drivers/net/ethernet/calxeda/Kconfig|  2 +-
 drivers/net/ethernet/hisilicon/Kconfig  |  2 +-
 drivers/net/ethernet/marvell/Kconfig|  8 ++---
 drivers/net/ethernet/mellanox/mlxsw/Kconfig |  2 +-
 drivers/net/ethernet/renesas/Kconfig|  2 --
 drivers/net/ethernet/socionext/Kconfig  |  4 +--
 drivers/net/wireless/broadcom/brcm80211/Kconfig |  1 -
 drivers/net/wireless/quantenna/qtnfmac/Kconfig  |  2 +-
 drivers/remoteproc/Kconfig  |  1 -
 drivers/scsi/hisi_sas/Kconfig   |  2 +-
 drivers/spi/Kconfig | 12 ++--
 drivers/staging/media/davinci_vpfe/Kconfig  |  1 -
 drivers/staging/media/omap4iss/Kconfig  |  1 -
 drivers/staging/vc04_services/Kconfig   |  1 -
 drivers/tty/serial/Kconfig  |  4 ---
 drivers/usb/gadget/udc/Kconfig  |  4 +--
 drivers/usb/mtu3/Kconfig|  2 +-
 drivers/video/fbdev/Kconfig |  3 +-
 sound/soc/bcm/Kconfig   |  3 +-
 sound/soc/kirkwood/Kconfig  |  1 -
 sound/soc/pxa/Kconfig   |  1 -
 sound/soc/qcom/Kconfig  |  6 ++--
 54 files changed, 58 insertions(+), 141 deletions(-)

diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index a7120d6211546949..9eaeed1fb237fa33 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -398,7 +398,6 @@ config SATA_DWC_VDEBUG
 
 config SATA_HIGHBANK
tristate "Calxeda Highbank SATA support"
-   depends on HAS_DMA
depends on ARCH_HIGHBANK || COMPILE_TEST
help
  This option enables support for the Calxeda Highbank SoC's
@@ -408,7 +407,6 @@ config SATA_HIGHBANK
 
 config SATA_MV
tristate "Marvell SATA support"
-   depends on HAS_DMA
depends on PCI || ARCH_DOVE || ARCH_MV78XX0 || \
   ARCH_MVEBU || ARCH_ORION5X || COMPILE_TEST
select GENERIC_PHY
diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index 4b741b83e23ff4de..3d27da7a430c0bc2 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -419,7 +419,7 @@ config CRYPTO_DEV_EXYNOS_RNG
 config CRYPTO_DE

[PATCH/RFC 4/6] mm: Add NO_DMA dummies for DMA pool API

2018-02-06 Thread Geert Uytterhoeven
Add dummies for dma{,m}_pool_{create,destroy,alloc,free}(), to allow
compile-testing if NO_DMA=y.

This prevents the following from showing up later:

ERROR: "dma_pool_destroy" [drivers/usb/mtu3/mtu3.ko] undefined!
ERROR: "dma_pool_free" [drivers/usb/mtu3/mtu3.ko] undefined!
ERROR: "dma_pool_alloc" [drivers/usb/mtu3/mtu3.ko] undefined!
ERROR: "dma_pool_create" [drivers/usb/mtu3/mtu3.ko] undefined!
ERROR: "dma_pool_destroy" [drivers/scsi/hisi_sas/hisi_sas_main.ko] 
undefined!
ERROR: "dma_pool_free" [drivers/scsi/hisi_sas/hisi_sas_main.ko] undefined!
ERROR: "dma_pool_alloc" [drivers/scsi/hisi_sas/hisi_sas_main.ko] undefined!
ERROR: "dma_pool_create" [drivers/scsi/hisi_sas/hisi_sas_main.ko] undefined!
ERROR: "dma_pool_alloc" [drivers/mailbox/bcm-pdc-mailbox.ko] undefined!
ERROR: "dma_pool_free" [drivers/mailbox/bcm-pdc-mailbox.ko] undefined!
ERROR: "dma_pool_create" [drivers/mailbox/bcm-pdc-mailbox.ko] undefined!
    ERROR: "dma_pool_destroy" [drivers/mailbox/bcm-pdc-mailbox.ko] undefined!

Signed-off-by: Geert Uytterhoeven 
---
 include/linux/dmapool.h | 21 +++--
 1 file changed, 19 insertions(+), 2 deletions(-)

diff --git a/include/linux/dmapool.h b/include/linux/dmapool.h
index 53ba737505df31c7..adeb5e56c3ad73a8 100644
--- a/include/linux/dmapool.h
+++ b/include/linux/dmapool.h
@@ -16,6 +16,7 @@
 
 struct device;
 
+#ifdef CONFIG_HAS_DMA
 struct dma_pool *dma_pool_create(const char *name, struct device *dev, 
size_t size, size_t align, size_t allocation);
 
@@ -23,6 +24,17 @@ void dma_pool_destroy(struct dma_pool *pool);
 
 void *dma_pool_alloc(struct dma_pool *pool, gfp_t mem_flags,
 dma_addr_t *handle);
+void dma_pool_free(struct dma_pool *pool, void *vaddr, dma_addr_t addr);
+#else /* !CONFIG_HAS_DMA */
+static inline struct dma_pool *dma_pool_create(const char *name,
+   struct device *dev, size_t size, size_t align, size_t allocation)
+{ return NULL; }
+static inline void dma_pool_destroy(struct dma_pool *pool) { }
+static inline void *dma_pool_alloc(struct dma_pool *pool, gfp_t mem_flags,
+  dma_addr_t *handle) { return NULL; }
+static inline void dma_pool_free(struct dma_pool *pool, void *vaddr,
+dma_addr_t addr) { }
+#endif /* !CONFIG_HAS_DMA */
 
 static inline void *dma_pool_zalloc(struct dma_pool *pool, gfp_t mem_flags,
dma_addr_t *handle)
@@ -30,14 +42,19 @@ static inline void *dma_pool_zalloc(struct dma_pool *pool, 
gfp_t mem_flags,
return dma_pool_alloc(pool, mem_flags | __GFP_ZERO, handle);
 }
 
-void dma_pool_free(struct dma_pool *pool, void *vaddr, dma_addr_t addr);
-
 /*
  * Managed DMA pool
  */
+#ifdef CONFIG_HAS_DMA
 struct dma_pool *dmam_pool_create(const char *name, struct device *dev,
  size_t size, size_t align, size_t allocation);
 void dmam_pool_destroy(struct dma_pool *pool);
+#else /* !CONFIG_HAS_DMA */
+static inline struct dma_pool *dmam_pool_create(const char *name,
+   struct device *dev, size_t size, size_t align, size_t allocation)
+{ return NULL; }
+static inline void dmam_pool_destroy(struct dma_pool *pool) { }
+#endif /* !CONFIG_HAS_DMA */
 
 #endif
 
-- 
2.7.4



[PATCH/RFC 5/6] scsi: Add NO_DMA dummies for SCSI DMA mapping API

2018-02-06 Thread Geert Uytterhoeven
Add dummies for scsi_dma_{,un}map(), to allow compile-testing if
NO_DMA=y.

This prevents the following from showing up later:

ERROR: "scsi_dma_unmap" [drivers/firewire/firewire-sbp2.ko] undefined!
ERROR: "scsi_dma_map" [drivers/firewire/firewire-sbp2.ko] undefined!

Signed-off-by: Geert Uytterhoeven 
---
 include/scsi/scsi_cmnd.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/include/scsi/scsi_cmnd.h b/include/scsi/scsi_cmnd.h
index d8d4a902a88dedbc..6a123d1dd2f80624 100644
--- a/include/scsi/scsi_cmnd.h
+++ b/include/scsi/scsi_cmnd.h
@@ -171,8 +171,13 @@ extern void scsi_kunmap_atomic_sg(void *virt);
 
 extern int scsi_init_io(struct scsi_cmnd *cmd);
 
+#ifdef CONFIG_SCSI_DMA
 extern int scsi_dma_map(struct scsi_cmnd *cmd);
 extern void scsi_dma_unmap(struct scsi_cmnd *cmd);
+#else /* !CONFIG_SCSI_DMA */
+static inline int scsi_dma_map(struct scsi_cmnd *cmd) { return -ENOSYS; }
+static inline void scsi_dma_unmap(struct scsi_cmnd *cmd) { }
+#endif /* !CONFIG_SCSI_DMA */
 
 static inline unsigned scsi_sg_count(struct scsi_cmnd *cmd)
 {
-- 
2.7.4



[PATCH/RFC 3/6] usb: gadget: Add NO_DMA dummies for DMA mapping API

2018-02-06 Thread Geert Uytterhoeven
Add dummies for usb_gadget_{,un}map_request{,_by_dev}(), to allow
compile-testing if NO_DMA=y.

This prevents the following from showing up later:

ERROR: "usb_gadget_unmap_request_by_dev" 
[drivers/usb/renesas_usbhs/renesas_usbhs.ko] undefined!
ERROR: "usb_gadget_map_request_by_dev" 
[drivers/usb/renesas_usbhs/renesas_usbhs.ko] undefined!
ERROR: "usb_gadget_map_request" [drivers/usb/mtu3/mtu3.ko] undefined!
ERROR: "usb_gadget_unmap_request" [drivers/usb/mtu3/mtu3.ko] undefined!
ERROR: "usb_gadget_map_request" [drivers/usb/gadget/udc/renesas_usb3.ko] 
undefined!
ERROR: "usb_gadget_unmap_request" [drivers/usb/gadget/udc/renesas_usb3.ko] 
undefined!

Signed-off-by: Geert Uytterhoeven 
---
 include/linux/usb/gadget.h | 12 
 1 file changed, 12 insertions(+)

diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index 66a5cff7ee142d6a..b68e7f9b210be122 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -805,6 +805,7 @@ int usb_otg_descriptor_init(struct usb_gadget *gadget,
 
 /* utility to simplify map/unmap of usb_requests to/from DMA */
 
+#ifdef CONFIG_HAS_DMA
 extern int usb_gadget_map_request_by_dev(struct device *dev,
struct usb_request *req, int is_in);
 extern int usb_gadget_map_request(struct usb_gadget *gadget,
@@ -814,6 +815,17 @@ extern void usb_gadget_unmap_request_by_dev(struct device 
*dev,
struct usb_request *req, int is_in);
 extern void usb_gadget_unmap_request(struct usb_gadget *gadget,
struct usb_request *req, int is_in);
+#else /* !CONFIG_HAS_DMA */
+static inline int usb_gadget_map_request_by_dev(struct device *dev,
+   struct usb_request *req, int is_in) { return -ENOSYS; }
+static inline int usb_gadget_map_request(struct usb_gadget *gadget,
+   struct usb_request *req, int is_in) { return -ENOSYS; }
+
+static inline void usb_gadget_unmap_request_by_dev(struct device *dev,
+   struct usb_request *req, int is_in) { }
+static inline void usb_gadget_unmap_request(struct usb_gadget *gadget,
+   struct usb_request *req, int is_in) { }
+#endif /* !CONFIG_HAS_DMA */
 
 /*-*/
 
-- 
2.7.4



Re: [PATCH] scsi: remove dead makefile about oktagon files

2018-01-29 Thread Geert Uytterhoeven
On Mon, Jan 29, 2018 at 1:30 PM, Corentin Labbe  wrote:
> Remove line using inexistant files which were removed in
> commit 642978beb483 ("[SCSI] remove m68k NCR53C9x based drivers")
>
> Signed-off-by: Corentin Labbe 

Acked-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

    Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds


Re: [PATCH 00/26] constify local structures

2016-09-12 Thread Geert Uytterhoeven
On Mon, Sep 12, 2016 at 3:43 PM, Felipe Balbi
 wrote:
> Jarkko Sakkinen  writes:
>> On Mon, Sep 12, 2016 at 10:54:07AM +0200, Julia Lawall wrote:
>>> On Sun, 11 Sep 2016, Jarkko Sakkinen wrote:
>>> > On Sun, Sep 11, 2016 at 03:05:42PM +0200, Julia Lawall wrote:
>>> > > Constify local structures.
>>> > >
>>> > > The semantic patch that makes this change is as follows:
>>> > > (http://coccinelle.lip6.fr/)
>>> >
>>> > Just my two cents but:
>>> >
>>> > 1. You *can* use a static analysis too to find bugs or other issues.
>>> > 2. However, you should manually do the commits and proper commit
>>> >messages to subsystems based on your findings. And I generally think
>>> >that if one contributes code one should also at least smoke test 
>>> > changes
>>> >somehow.
>>> >
>>> > I don't know if I'm alone with my opinion. I just think that one should
>>> > also do the analysis part and not blindly create and submit patches.
>>>
>>> All of the patches are compile tested.  And the individual patches are
>>
>> Compile-testing is not testing. If you are not able to test a commit,
>> you should explain why.
>
> Dude, Julia has been doing semantic patching for years already and
> nobody has raised any concerns so far. There's already an expectation
> that Coccinelle *works* and Julia's sematic patches are sound.

+1

> Besides, adding 'const' is something that causes virtually no functional
> changes to the point that build-testing is really all you need. Any
> problems caused by adding 'const' to a definition will be seen by build
> errors or warnings.

Unfortunately in this particular case they could lead to failures that can only
be detected at runtime, when failing o write to a read-only piece of memory,
due to the casting away of the constness of the pointers later.
Fortunately this was detected during code review (doh...).

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 3/3] scsi/ncr5380: Improve interrupt latency during PIO tranfers

2016-09-09 Thread Geert Uytterhoeven
On Fri, Sep 9, 2016 at 1:28 PM, Martin K. Petersen
 wrote:
>>>>>> "Finn" == Finn Thain  writes:
>
> Finn> Large PIO transfers are broken up into chunks to try to avoid
> Finn> disabling local IRQs for long periods. But IRQs are still disabled
> Finn> for too long and this causes SCC FIFO overruns during serial port
> Finn> transfers.
>
> Finn> This patch reduces the PIO chunk size to reduce interrupt latency
> Finn> to something on the order of milliseconds, at the expense of
> Finn> additional CPU overhead from extra iterations of the
> Finn> NCR5380_main() loop.
>
> Finn> That CPU overhead is a problem for slow machines (e.g. mac_scsi on
> Finn> 25 MHz
> Finn> 68030) but these machines generally use PDMA not PIO. This patch
> Finn>doesn't
> Finn> make the overhead any worse on my Mac LC III (because it only gets
> Finn> about 510 accesses per ms).
>
> Finn> This patch decreases disk performance by a fraction of one percent
> Finn> for dmx3191d on my 333 MHz PowerPC 750. Other affected hardware
> Finn> (such as g_NCR5380 on x86) was not tested but 5380 ISA cards
> Finn> generally use PDMA and not PIO.
>
> Geert?

No comments from my side.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 2/3] scsi/ncr5380: Avoid a compiler warning

2016-08-28 Thread Geert Uytterhoeven
On Sat, Aug 27, 2016 at 4:30 AM, Finn Thain  wrote:
> With commit 3a0f64bfa907 ("mac_scsi: Fix pseudo DMA implementation")
> some versions of gcc now warn:
>
> In file included from drivers/scsi/mac_scsi.c:335:
> drivers/scsi/NCR5380.h:295: warning: `NCR5380_poll_politely' declared inline 
> after being called
> drivers/scsi/NCR5380.h:295: warning: previous declaration of 
> `NCR5380_poll_politely' was here
>
> Avoid this by defining NCR5380_poll_politely() in NCR5380.h.
>
> Suggested-by: Geert Uytterhoeven 
> Signed-off-by: Finn Thain 

Tested-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 3/3] scsi/ncr5380: Improve interrupt latency during PIO tranfers

2016-08-28 Thread Geert Uytterhoeven
Hi Finn,

On Sat, Aug 27, 2016 at 4:30 AM, Finn Thain  wrote:
> Large PIO transfers are broken up into chunks to try to avoid disabling
> local IRQs for long periods. But IRQs are still disabled for too long
> and this causes SCC FIFO overruns during serial port transfers. This
> patch fixes the problem by halving the PIO chunk size.
>
> Testing with mac_scsi shows that the extra NCR5380_main() loop iterations
> have negligible performance impact on SCSI transfers (about 1% slower).
> On a faster system (using the dmx3191d module) transfers showed no
> measurable change.
>
> Signed-off-by: Finn Thain 
>
> ---
>  drivers/scsi/NCR5380.c |6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> Index: linux/drivers/scsi/NCR5380.c
> ===
> --- linux.orig/drivers/scsi/NCR5380.c   2016-08-27 12:29:57.0 +1000
> +++ linux/drivers/scsi/NCR5380.c2016-08-27 12:29:58.0 +1000
> @@ -1847,11 +1847,11 @@ static void NCR5380_information_transfer
> /* XXX - need to source or 
> sink data here, as appropriate */
> }
> } else {
> -   /* Break up transfer into 3 ms chunks,
> -* presuming 6 accesses per handshake.
> +   /* Transfer a small chunk so that the
> +* irq mode lock is not held too long.
>  */
> transfersize = min((unsigned 
> long)cmd->SCp.this_residual,
> -  
> hostdata->accesses_per_ms / 2);
> +  
> hostdata->accesses_per_ms >> 2);

I think it's easier to read if you use "/ 4".

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 1/3] documentation/scsi: Remove nodisconnect parameter

2016-08-28 Thread Geert Uytterhoeven
On Sat, Aug 27, 2016 at 4:29 AM, Finn Thain  wrote:
> The driver that used the 'nodisconnect' parameter was removed in
> commit 565bae6a4a8f ("[SCSI] 53c7xx: kill driver"). Related documentation
> was cleaned up in commit f37a7238d379 ("[SCSI] 53c7xx: fix removal
> fallout"), except for the remaining two mentions that are removed here.
>
> Signed-off-by: Finn Thain 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 42/54] MAINTAINERS: Add file patterns for scsi device tree bindings

2016-05-22 Thread Geert Uytterhoeven
Submitters of device tree binding documentation may forget to CC
the subsystem maintainer if this is missing.

Signed-off-by: Geert Uytterhoeven 
Cc: James E.J. Bottomley 
Cc: Martin K. Petersen 
Cc: linux-scsi@vger.kernel.org
---
Please apply this patch directly if you want to be involved in device
tree binding documentation for your subsystem.
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 327e1d5a501340ac..139824579fa97c2c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10141,6 +10141,7 @@ M:  "Martin K. Petersen" 

 T: git git://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git
 L: linux-scsi@vger.kernel.org
 S: Maintained
+F: Documentation/devicetree/bindings/scsi/
 F: drivers/scsi/
 F: include/scsi/
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v4 22/23] mac_scsi: Fix pseudo DMA implementation

2016-05-19 Thread Geert Uytterhoeven
Hi Finn,

On Thu, May 19, 2016 at 2:02 PM, Finn Thain  wrote:
> On Thu, 19 May 2016, Geert Uytterhoeven wrote:
>> In file included from drivers/scsi/mac_scsi.c:335:
>> drivers/scsi/NCR5380.h:295: warning: `NCR5380_poll_politely' declared inline 
>> after being called
>> drivers/scsi/NCR5380.h:295: warning: previous declaration of 
>> `NCR5380_poll_politely' was here
>
> Thanks for letting me know. My compiler (v4.4.6) doesn't warn about this.
> What GCC version are you using? Does this (untested) patch help?

The venerable gcc version 4.1.2 20061115 (prerelease) (Ubuntu 4.1.1-21).
Which seems to disobey __attribute__((unused)):

 drivers/scsi/NCR5380.c:385: warning: ‘NCR5380_probe_irq’ defined
but not used

> Index: linux/drivers/scsi/NCR5380.c
> ===
> --- linux.orig/drivers/scsi/NCR5380.c   2016-05-19 21:31:05.0 +1000
> +++ linux/drivers/scsi/NCR5380.c2016-05-19 21:39:08.0 +1000
> @@ -230,13 +230,6 @@ static int NCR5380_poll_politely2(struct
> return -ETIMEDOUT;
>  }
>
> -static inline int NCR5380_poll_politely(struct Scsi_Host *instance,
> -int reg, int bit, int val, int wait)
> -{
> -   return NCR5380_poll_politely2(instance, reg, bit, val,
> -   reg, bit, val, wait);
> -}
> -
>  #if NDEBUG
>  static struct {
> unsigned char mask;
> Index: linux/drivers/scsi/NCR5380.h
> ===
> --- linux.orig/drivers/scsi/NCR5380.h   2016-05-19 19:47:06.0 +1000
> +++ linux/drivers/scsi/NCR5380.h2016-05-19 21:40:15.0 +1000
> @@ -292,8 +292,10 @@ static void NCR5380_reselect(struct Scsi
>  static struct scsi_cmnd *NCR5380_select(struct Scsi_Host *, struct scsi_cmnd 
> *);
>  static int NCR5380_transfer_dma(struct Scsi_Host *instance, unsigned char 
> *phase, int *count, unsigned char **data);
>  static int NCR5380_transfer_pio(struct Scsi_Host *instance, unsigned char 
> *phase, int *count, unsigned char **data);
> -static int NCR5380_poll_politely(struct Scsi_Host *, int, int, int, int);
>  static int NCR5380_poll_politely2(struct Scsi_Host *, int, int, int, int, 
> int, int, int);
>
> +#define NCR5380_poll_politely(instance, reg, bit, val, wait) \
> +NCR5380_poll_politely2(instance, reg, bit, val, reg, bit, val, wait)

Thanks, that silences the warning.

BTW, what about using the static inline variant here? That works, too.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v4 22/23] mac_scsi: Fix pseudo DMA implementation

2016-05-19 Thread Geert Uytterhoeven
Hi Finn,

On Wed, Mar 23, 2016 at 11:10 AM, Finn Thain  wrote:
> Fix various issues: Comments about bus errors are incorrect. The
> PDMA asm must return the size of the memory access that faulted so the
> transfer count can be adjusted accordingly. A phase change may cause a
> bus error but should not be treated as failure. A bus error does not
> always imply a phase change and generally the transfer may continue.
> Scatter/gather doesn't seem to work with PDMA due to overruns. This is
> a pity because peak throughput seems to double with SG_ALL.
> Tested on a Mac LC III and a PowerBook 520.
>
> Signed-off-by: Finn Thain 
> Reviewed-by: Hannes Reinecke 

> --- linux.orig/drivers/scsi/mac_scsi.c  2016-03-23 21:09:53.0 +1100
> +++ linux/drivers/scsi/mac_scsi.c   2016-03-23 21:10:05.0 +1100

> @@ -104,18 +105,9 @@ static int __init mac_scsi_setup(char *s

>  static int macscsi_pread(struct Scsi_Host *instance,
>   unsigned char *dst, int len)
>  {
> struct NCR5380_hostdata *hostdata = shost_priv(instance);
> -   unsigned char *d;
> -   unsigned char *s;
> -
> -   s = hostdata->pdma_base + (INPUT_DATA_REG << 4);
> -   d = dst;
> -
> -   /* These conditions are derived from MacOS */
> -
> -   while (!(NCR5380_read(BUS_AND_STATUS_REG) & BASR_DRQ) &&
> -  !(NCR5380_read(STATUS_REG) & SR_REQ))
> -   ;
> -
> -   if (!(NCR5380_read(BUS_AND_STATUS_REG) & BASR_DRQ) &&
> -   (NCR5380_read(BUS_AND_STATUS_REG) & BASR_PHASE_MATCH)) {
> -   pr_err("Error in macscsi_pread\n");
> -   return -1;
> -   }
> -
> -   CP_IO_TO_MEM(s, d, len);
> -
> -   if (len != 0) {
> -   pr_notice("Bus error in macscsi_pread\n");
> -   return -1;
> +   unsigned char *s = hostdata->pdma_base + (INPUT_DATA_REG << 4);
> +   unsigned char *d = dst;
> +   int n = len;
> +   int transferred;
> +
> +   while (!NCR5380_poll_politely(instance, BUS_AND_STATUS_REG,
> + BASR_DRQ | BASR_PHASE_MATCH,
> + BASR_DRQ | BASR_PHASE_MATCH, HZ / 64)) {
> +   CP_IO_TO_MEM(s, d, n);

This is now before the inclusion of NCR5380.c, causing

In file included from drivers/scsi/mac_scsi.c:335:
drivers/scsi/NCR5380.h:295: warning: ‘NCR5380_poll_politely’ declared
inline after being called
drivers/scsi/NCR5380.h:295: warning: previous declaration of
‘NCR5380_poll_politely’ was here

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v4 34/78] atari_NCR5380: Use arbitration timeout

2016-01-26 Thread Geert Uytterhoeven
Hi Finn,

On Tue, Jan 26, 2016 at 1:18 AM, Finn Thain  wrote:
> On Mon, 25 Jan 2016, Geert Uytterhoeven wrote:
>> > In principle I think that Linux drivers should not carry workarounds
>> > for emulators.
>>
>> Please consider ARAnyM is the current m68k workhorse, so it would be
>> nice to handle this someway.
>
> AFAICT atari_scsi on aranym never did anything useful. Those aranym users
> who need to run Linux 4.5 can set CONFIG_ATARI_SCSI=n or blacklist the
> atari_scsi module (up until aranym can be patched).

FTR. adding "initcall_blacklist=atari_scsi_driver_init" to the kernel command
line makes it boot again.

>> Alternatively, we need to fix ARAnyM,
>
> I'll look into writing a patch for the emulator after I've finished
> testing the exception handling fixes for the driver.

Thank you!

>> or can make the creation of the atari_scsi platform device conditional
>> on not running under ARAnyM.
>
> Fixing the emulator is the only sensible approach. If S operating systems
> have to carry workarounds for B emulator bugs, the cost is (at least)
> proportional to S * B.

Sure.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v4 34/78] atari_NCR5380: Use arbitration timeout

2016-01-25 Thread Geert Uytterhoeven
Hi Finn,

On Mon, Jan 25, 2016 at 3:45 AM, Finn Thain  wrote:
> On Sun, 24 Jan 2016, Geert Uytterhoeven wrote:
>> On Sun, Jan 3, 2016 at 6:05 AM, Finn Thain  
>> wrote:
>> > Allow target selection to fail with a timeout instead of waiting in
>> > infinite loops. This gets rid of the unused NCR_TIMEOUT macro, it is more
>> > defensive and has proved helpful in debugging.
>> >
>> > Signed-off-by: Finn Thain 
>> > Reviewed-by: Hannes Reinecke 
>> > Tested-by: Ondrej Zary 
>> > Tested-by: Michael Schmitz 
>>
>> This patch (commit 55500d9b08295e3b6016b53879dea1cb7787f1b0) causes a hang
>> on ARAnyM with atari_defconfig after:
>>
>> scsi host0: Atari native SCSI, io_port 0x0, n_io_port 0, base 0x0,
>> irq 15, can_queue 8, cmd_per_lun 1, sg_tablesize 0, this_id 7, flags {
>> }, options { REAL_DMA SUPPORT_TAGS }
>> blk_queue_max_segments: set to minimum 1
>>
>> > --- linux.orig/drivers/scsi/atari_NCR5380.c 2016-01-03 
>> > 16:03:43.0 +1100
>> > +++ linux/drivers/scsi/atari_NCR5380.c  2016-01-03 16:03:44.0 +1100
>> > @@ -1436,42 +1437,28 @@ static int NCR5380_select(struct Scsi_Ho
>> > NCR5380_write(OUTPUT_DATA_REG, hostdata->id_mask);
>> > NCR5380_write(MODE_REG, MR_ARBITRATE);
>> >
>> > -   local_irq_restore(flags);
>> > +   /* The chip now waits for BUS FREE phase. Then after the 800 ns
>> > +* Bus Free Delay, arbitration will begin.
>> > +*/
>> >
>> > -   /* Wait for arbitration logic to complete */
>> > -#if defined(NCR_TIMEOUT)
>> > -   {
>> > -   unsigned long timeout = jiffies + 2*NCR_TIMEOUT;
>> > -
>> > -   while (!(NCR5380_read(INITIATOR_COMMAND_REG) & 
>> > ICR_ARBITRATION_PROGRESS) &&
>> > -  time_before(jiffies, timeout) && 
>> > !hostdata->connected)
>> > -   ;
>> > -   if (time_after_eq(jiffies, timeout)) {
>> > -   printk("scsi : arbitration timeout at %d\n", 
>> > __LINE__);
>> > +   local_irq_restore(flags);
>> > +   timeout = jiffies + HZ;
>> > +   while (1) {
>> > +   if (time_is_before_jiffies(timeout)) {
>> > NCR5380_write(MODE_REG, MR_BASE);
>> > -   NCR5380_write(SELECT_ENABLE_REG, 
>> > hostdata->id_mask);
>> > +   shost_printk(KERN_ERR, instance,
>> > +"select: arbitration timeout\n");
>> > return -1;
>> > }
>> > +   if (!(NCR5380_read(MODE_REG) & MR_ARBITRATE)) {
>>
>> This newly added check always triggers, causing an infinite loop calling
>> NCR5380_select().
>
> If you bisected and got a failure here, it would not be surprising because
> some of the remaining patches fix bugs in the exception handlers.
>
> But if you test the entire patch series and get a hang (after waiting for
> the command to timeout and abort etc) it could be caused by a known bug in
> the abort handler. I will be sending a patch for that.

Yes, this was bisected. The issue was originally noticed after merging in
upstream, though.

Awaiting your patch for testing...

>> Perhaps this is an ARAnyM quirk?
>
> I'd say this is an ARAnyM bug. atari_scsi has been tested on an actual
> Atari Falcon, hence Michael's tested-by tag.
>
>> If not, does it trigger (on some hardware) with drivers/scsi/NCR5380.c,
>> too?
>
> For the arbitration and selection phases, there is no difference between
> NCR5380.c and atari_NCR5380.c. That's one of the benefits of my patches.
>
> That means this code was tested on silicon from NCR (53C400), Symbios
> Logic (53C400A), AMD (Am85C80), Domex Technology Corp (DTC-536, DTC-436)
> and LOGIC Devices (L5380).

> The MR_ARBITRATE bit should remain set until the driver clears it (or the
> reset logic clears it). But it looks like aranym simply discards writes to
> the mode register, such that reads always return 0.
>
> Compare
>   http://sourceforge.net/p/aranym/code/ci/master/tree/src/ncr5380.cpp
> with the MAME/MESS emulated device
>   https://github.com/mamedev/mame/blob/master/src/devices/machine/ncr5380.cpp
>
> I don't know what the Hatari emulator does.
>
> In principle I think that Linux drivers should not carry workarounds for
> emulators.

Please consider ARAnyM is the current m

Re: [PATCH v4 34/78] atari_NCR5380: Use arbitration timeout

2016-01-24 Thread Geert Uytterhoeven
Hi Finn,

On Sun, Jan 3, 2016 at 6:05 AM, Finn Thain  wrote:
> Allow target selection to fail with a timeout instead of waiting in
> infinite loops. This gets rid of the unused NCR_TIMEOUT macro, it is more
> defensive and has proved helpful in debugging.
>
> Signed-off-by: Finn Thain 
> Reviewed-by: Hannes Reinecke 
> Tested-by: Ondrej Zary 
> Tested-by: Michael Schmitz 

This patch (commit 55500d9b08295e3b6016b53879dea1cb7787f1b0) causes a hang
on ARAnyM with atari_defconfig after:

scsi host0: Atari native SCSI, io_port 0x0, n_io_port 0, base 0x0,
irq 15, can_queue 8, cmd_per_lun 1, sg_tablesize 0, this_id 7, flags {
}, options { REAL_DMA SUPPORT_TAGS }
blk_queue_max_segments: set to minimum 1

> --- linux.orig/drivers/scsi/atari_NCR5380.c 2016-01-03 16:03:43.0 
> +1100
> +++ linux/drivers/scsi/atari_NCR5380.c  2016-01-03 16:03:44.0 +1100
> @@ -1436,42 +1437,28 @@ static int NCR5380_select(struct Scsi_Ho
> NCR5380_write(OUTPUT_DATA_REG, hostdata->id_mask);
> NCR5380_write(MODE_REG, MR_ARBITRATE);
>
> -   local_irq_restore(flags);
> +   /* The chip now waits for BUS FREE phase. Then after the 800 ns
> +* Bus Free Delay, arbitration will begin.
> +*/
>
> -   /* Wait for arbitration logic to complete */
> -#if defined(NCR_TIMEOUT)
> -   {
> -   unsigned long timeout = jiffies + 2*NCR_TIMEOUT;
> -
> -   while (!(NCR5380_read(INITIATOR_COMMAND_REG) & 
> ICR_ARBITRATION_PROGRESS) &&
> -  time_before(jiffies, timeout) && !hostdata->connected)
> -   ;
> -   if (time_after_eq(jiffies, timeout)) {
> -   printk("scsi : arbitration timeout at %d\n", 
> __LINE__);
> +   local_irq_restore(flags);
> +   timeout = jiffies + HZ;
> +   while (1) {
> +   if (time_is_before_jiffies(timeout)) {
> NCR5380_write(MODE_REG, MR_BASE);
> -   NCR5380_write(SELECT_ENABLE_REG, hostdata->id_mask);
> +   shost_printk(KERN_ERR, instance,
> +"select: arbitration timeout\n");
> return -1;
> }
> +   if (!(NCR5380_read(MODE_REG) & MR_ARBITRATE)) {

This newly added check always triggers, causing an infinite loop calling
NCR5380_select().
Perhaps this is an ARAnyM quirk?
If not, does it trigger (on some hardware) with drivers/scsi/NCR5380.c, too?

> +   /* Reselection interrupt */
> +   return -1;
> +   }
> +   if (NCR5380_read(INITIATOR_COMMAND_REG) & 
> ICR_ARBITRATION_PROGRESS)
> +   break;
> }
> -#else /* NCR_TIMEOUT */
> -   while (!(NCR5380_read(INITIATOR_COMMAND_REG) & 
> ICR_ARBITRATION_PROGRESS) &&
> -  !hostdata->connected)
> -   ;
> -#endif
> -
> -   dprintk(NDEBUG_ARBITRATION, "scsi%d: arbitration complete\n", HOSTNO);
> -
> -   if (hostdata->connected) {
> -   NCR5380_write(MODE_REG, MR_BASE);
> -   return -1;
> -   }
> -   /*
> -* The arbitration delay is 2.2us, but this is a minimum and there is
> -* no maximum so we can safely sleep for ceil(2.2) usecs to 
> accommodate
> -* the integral nature of udelay().
> -*
> -*/
>
> +   /* The SCSI-2 arbitration delay is 2.4 us */
> udelay(3);
>
> /* Check for lost arbitration */

On current mainline, this (whitespace-damaged) patch fixed the issue for me:

--- a/drivers/scsi/atari_NCR5380.c
+++ b/drivers/scsi/atari_NCR5380.c
@@ -1253,10 +1253,6 @@ static struct scsi_cmnd *NCR5380_select(struct
Scsi_Host *instance,
INITIATOR_COMMAND_REG, ICR_ARBITRATION_PROGRESS,
   ICR_ARBITRATION_PROGRESS, HZ);
spin_lock_irq(&hostdata->lock);
-   if (!(NCR5380_read(MODE_REG) & MR_ARBITRATE)) {
-   /* Reselection interrupt */
-   goto out;
-   }
if (err < 0) {
NCR5380_write(MODE_REG, MR_BASE);
shost_printk(KERN_ERR, instance,
@@ -1297,10 +1293,6 @@ static struct scsi_cmnd *NCR5380_select(struct
Scsi_Host *instance,

spin_lock_irq(&hostdata->lock);

-   /* NCR5380_reselect() clears MODE_REG after a reselection interrupt */
-   if (!(NCR5380_read(MODE_REG) & MR_ARBITRATE))
-   goto out;
-
if (!hostdata->selecting) {
NCR5380_write(MODE_REG, MR_BASE);
NCR5380_write(INITIATOR_COMMAND_REG, ICR_BASE);

Gr{

Re: [PATCH v2 21/72] ncr5380: Sleep when polling, if possible

2015-12-06 Thread Geert Uytterhoeven
Hi Finn,

On Sun, Dec 6, 2015 at 2:31 AM, Finn Thain  wrote:
> When in process context, sleep during polling if doing so won't add
> significant latency. In interrupt context or if the lock is held, poll
> briefly then give up. Keep both core drivers in sync.
>
> Calibrate busy-wait iterations to allow for variation in chip register
> access times between different 5380 hardware implementations.
>
> Signed-off-by: Finn Thain 
>
> ---
>
> Changed since v1:
> - Don't rely on loops_per_jiffy to estimate register access speed, measure
>   it instead.
>
> ---
>  drivers/scsi/NCR5380.c   |   77 
> +--
>  drivers/scsi/NCR5380.h   |1
>  drivers/scsi/atari_NCR5380.c |   59 
>  3 files changed, 84 insertions(+), 53 deletions(-)
>
> Index: linux/drivers/scsi/NCR5380.c
> ===
> --- linux.orig/drivers/scsi/NCR5380.c   2015-12-06 12:29:51.0 +1100
> +++ linux/drivers/scsi/NCR5380.c2015-12-06 12:29:54.0 +1100
> @@ -293,44 +293,48 @@ static inline void initialize_SCp(struct
>  }
>
>  /**
> - * NCR5380_poll_politely   -   wait for NCR5380 status bits
> - * @instance: controller to poll
> - * @reg: 5380 register to poll
> - * @bit: Bitmask to check
> - * @val: Value required to exit
> - *
> - * Polls the NCR5380 in a reasonably efficient manner waiting for
> - * an event to occur, after a short quick poll we begin giving the
> - * CPU back in non IRQ contexts
> + * NCR5380_poll_politely - wait for chip register value
> + * @instance: controller to poll
> + * @reg: 5380 register to poll
> + * @bit: Bitmask to check
> + * @val: Value required to exit
> + * @wait: Time-out in jiffies
> + *
> + * Polls the chip in a reasonably efficient manner waiting for an
> + * event to occur. After a short quick poll we begin to yield the CPU
> + * (if possible). In irq contexts the time-out is arbitrarily limited.
> + * Callers may hold locks as long as they are held in irq mode.
>   *
> - * Returns the value of the register or a negative error code.
> + * Returns 0 if event occurred otherwise -ETIMEDOUT.
>   */
> -
> -static int NCR5380_poll_politely(struct Scsi_Host *instance, int reg, int 
> bit, int val, int t)
> +
> +static int NCR5380_poll_politely(struct Scsi_Host *instance,
> + int reg, int bit, int val, int wait)
>  {
> -   int n = 500;/* At about 8uS a cycle for the cpu access */
> -   unsigned long end = jiffies + t;
> -   int r;
> -
> -   while( n-- > 0)
> -   {
> -   r = NCR5380_read(reg);
> -   if((r & bit) == val)
> +   struct NCR5380_hostdata *hostdata = shost_priv(instance);
> +   unsigned long deadline = jiffies + wait;
> +   unsigned long n;
> +
> +   /* Busy-wait for up to 10 ms */
> +   n = min(1U, jiffies_to_usecs(wait));
> +   n *= hostdata->accesses_per_ms;
> +   n /= 1000;
> +   do {
> +   if ((NCR5380_read(reg) & bit) == val)
> return 0;
> cpu_relax();
> -   }

> @@ -773,6 +777,7 @@ static int NCR5380_init(struct Scsi_Host
>  {
> int i;
> struct NCR5380_hostdata *hostdata = (struct NCR5380_hostdata *) 
> instance->hostdata;
> +   unsigned long deadline;
>
> if(in_interrupt())
> printk(KERN_ERR "NCR5380_init called with interrupts off!\n");
> @@ -812,6 +817,16 @@ static int NCR5380_init(struct Scsi_Host
> NCR5380_write(MODE_REG, MR_BASE);
> NCR5380_write(TARGET_COMMAND_REG, 0);
> NCR5380_write(SELECT_ENABLE_REG, 0);
> +
> +   /* Calibrate register polling loop */
> +   i = 0;
> +   deadline = jiffies + msecs_to_jiffies(100) + 1;
> +   do {
> +   NCR5380_read(STATUS_REG);
> +   ++i;
> +   } while (time_is_after_jiffies(deadline));
> +   hostdata->accesses_per_ms = i / 100;

As the caller of NCR5380_poll_politely() passes a timeout value in jiffies,
calculations may become simpler if you store the number of accesses per jiffy
instead of per ms.

Unlike the historical calibrating-delay-loop code, you don't wait for a jiffy
change before starting the calibration. At first I thought that was OK, but on
some platforms, HZ can be as low as 24, which means the result can vary by 33%
(based on 100 ms -> 3 jiffies).

The same change is made to atari_NCR5380.c.
I guess you plan to deduplicate this code when merging the drivers, i.e.
after this series?

Gr{oetje,eeting}s,


Re: [PATCH 73/71] ncr5380: Use runtime register mapping

2015-12-06 Thread Geert Uytterhoeven
On Sun, Dec 6, 2015 at 4:39 AM, Finn Thain  wrote:
>> - while (NCR5380_read(C400_CONTROL_STATUS_REG) & 
>> CSR_HOST_BUF_NOT_RDY);
>> + while (NCR5380_read(hostdata->c400_ctl_status) & 
>> CSR_HOST_BUF_NOT_RDY);
>
> The semicolon should appear on the next line where it is more visible.

And adding a cpu_relax() to the empty loop body is another good visual cue.

Gr{oetje,eeting}s,

    Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 22/71] ncr5380: Eliminate selecting state

2015-11-29 Thread Geert Uytterhoeven
Hi Finn,

On Sun, Nov 29, 2015 at 11:25 AM, Finn Thain  wrote:
> On Sun, 29 Nov 2015, Geert Uytterhoeven wrote:
>> This still heavily depends on the processing time spent in
>> NCR5380_read(). You should never use a value derived from
>> loops_per_jiffy for a non-empty loop,
>
> Sure but the time-out condition isn't supposed to be precise.
> Plus/minus a jiffy is no problem. Plus/minus a second is no good.

If an ISA access takes 8 µs, while the CPU runs at 1 GHz, i.e. 500M loops/s,
the difference will be huge.

>> as it may take much longer. Always compare with an maximum end time
>> instead.
>
> That can't work with interrupts disabled, which was the problem I was
> trying to solve by use of loops_per_jiffy.

Then you indeed can't use jiffies.
Perhaps you can calibrate an NCR5380_read() loop at driver init time,
and use the calibration value later?

> NCR5380_poll_politely() in mainline doesn't work with interrupts disabled
> either, hence patch 21.
>
>> E.g.:
>>
>> end = jiffies + 2;/* 1 jiffie + 1 safeguard */
>> do {
>>  if ((NCR5380_read(reg1) & bit1) == val1)
>>  return 0;
>>  cpu_relax();
>> } while (time_before(jiffies, end);
>>
>> And a similar loop for "Busy-wait for up to 20 ms".
>
> Interrupts may be disabled during that loop also. Please refer to (and/or
> respond to) patch 21, "ncr5380: Sleep when polling, if possible", in which
> these changes were made.

So the above loop may never terminate. Oops...

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 22/71] ncr5380: Eliminate selecting state

2015-11-29 Thread Geert Uytterhoeven
Hi Finn,

On Thu, Nov 26, 2015 at 11:32 PM, Finn Thain  wrote:
>> The timekeeping warning does not appear when all 71 patches are applied.
>> Reverse-bisected it - the warning disappears after:
>> [PATCH 50/71] ncr5380: Change instance->host_lock to hostdata->lock
>>
>
> Makes sense. I think that this should solve the problem:
>
> Index: linux/drivers/scsi/NCR5380.c
> ===
> --- linux.orig/drivers/scsi/NCR5380.c   2015-11-27 09:21:40.0 +1100
> +++ linux/drivers/scsi/NCR5380.c2015-11-27 09:25:36.0 +1100
> @@ -230,7 +230,7 @@ static int NCR5380_poll_politely2(struct
> unsigned long n;
>
> /* Busy-wait for up to 1 jiffy */
> -   n = loops_per_jiffy;
> +   n = 1 + loops_per_jiffy / 10;
> do {
> if ((NCR5380_read(reg1) & bit1) == val1)
> return 0;

This still heavily depends on the processing time spent in NCR5380_read().
You should never use a value derived from loops_per_jiffy for a non-empty loop,
as it may take much longer. Always compare with an maximum end time instead.

E.g.:

end = jiffies + 2;/* 1 jiffie + 1 safeguard */
do {
 if ((NCR5380_read(reg1) & bit1) == val1)
 return 0;
 cpu_relax();
} while (time_before(jiffies, end);

And a similar loop for "Busy-wait for up to 20 ms".

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers

2015-11-20 Thread Geert Uytterhoeven
On Fri, Nov 20, 2015 at 12:40 PM, Ondrej Zary
 wrote:
> Working ISA means more testing possibilities. It's much easier to get an ISA 
> card than a Sun or Atari. Also faster CPU (such as 1 GHz P3) means quicker 
> testing.

Faster PCs without ISA slots? ;-)

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH, resend] scsi: advansys: fix big-endian builds

2015-11-16 Thread Geert Uytterhoeven
On Mon, Nov 16, 2015 at 7:20 PM, Russell King - ARM Linux
 wrote:
> On Mon, Nov 16, 2015 at 05:49:23PM +0100, Arnd Bergmann wrote:
>> It turns out that the commit that introduced this used the cpu_to_le32()
>> incorrectly on an 8-bit field, which results in the sense_len to always
>> be set to zero, as the SCSI_SENSE_BUFFERSIZE value gets moved to upper
>> byte of the 32-bit intermediate.
>
> More people need to run the sparse checker with -D__CHECK_ENDIAN__ and
> have proper endian annotations?

Sure.

But in this case, it shows up as a normal compiler warning on all big endian
platforms.

Gr{oetje,eeting}s,

    Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] [SCSI] st: Remove obsolete scsi_tape.max_pfn

2015-11-15 Thread Geert Uytterhoeven
Its last user was removed 10 years ago, in commit
8b05b773b6030de5 ("[SCSI] convert st to use scsi_execute_async").

Signed-off-by: Geert Uytterhoeven 
---
 drivers/scsi/st.h | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/scsi/st.h b/drivers/scsi/st.h
index b6486b5d86811227..8c732c8de0153eb1 100644
--- a/drivers/scsi/st.h
+++ b/drivers/scsi/st.h
@@ -148,8 +148,6 @@ struct scsi_tape {
int tape_type;
int long_timeout;   /* timeout for commands known to take long time 
*/
 
-   unsigned long max_pfn;  /* the maximum page number reachable by the HBA 
*/
-
/* Mode characteristics */
struct st_modedef modes[ST_NBR_MODES];
int current_mode;
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Build regressions/improvements in v4.3

2015-11-02 Thread Geert Uytterhoeven
On Mon, Nov 2, 2015 at 12:26 PM, Geert Uytterhoeven
 wrote:
> JFYI, when comparing v4.3[1] to v4.3-rc7[3], the summaries are:
>   - build errors: +4/-7

  + /home/kisskb/slave/src/drivers/scsi/advansys.c: error: implicit
declaration of function 'free_dma'
[-Werror=implicit-function-declaration]:  => 11384:3
  + /home/kisskb/slave/src/drivers/scsi/advansys.c: error: implicit
declaration of function 'request_dma'
[-Werror=implicit-function-declaration]:  => 11300:4

arm-randconfig

> [1] http://kisskb.ellerman.id.au/kisskb/head/9535/ (256 out of 254 configs)
> [3] http://kisskb.ellerman.id.au/kisskb/head/9511/ (255 out of 254 configs)

Gr{oetje,eeting}s,

    Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 2/2] advansys: Make sure ret and share_irq are initialized

2015-06-24 Thread Geert Uytterhoeven
If CONFIG_PCI=n:

drivers/scsi/advansys.c: In function ‘advansys_board_found’:
drivers/scsi/advansys.c:11037: warning: ‘ret’ is used uninitialized in this 
function
drivers/scsi/advansys.c:10929: warning: ‘share_irq’ may be used 
uninitialized in this function

If CONFIG_PCI=n, ret and share_irq are indeed not initialized.
Pre-initialize them to zero, and drop the now superfluous setting of
share_irq to zero.

Note that this is sort-of a false positive, as apparently
ASC_NARROW_BOARD(boardp) can only be false for PCI boards, e.g. if
CONFIG_PCI=y.

Signed-off-by: Geert Uytterhoeven 
---
 drivers/scsi/advansys.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/scsi/advansys.c b/drivers/scsi/advansys.c
index 1c1cd657c380c2e0..a056226d3f35e863 100644
--- a/drivers/scsi/advansys.c
+++ b/drivers/scsi/advansys.c
@@ -10926,7 +10926,7 @@ static int advansys_board_found(struct Scsi_Host 
*shost, unsigned int iop,
struct asc_board *boardp = shost_priv(shost);
ASC_DVC_VAR *asc_dvc_varp = NULL;
ADV_DVC_VAR *adv_dvc_varp = NULL;
-   int share_irq, warn_code, ret;
+   int share_irq = 0, warn_code, ret = 0;
 
pdev = (bus_type == ASC_IS_PCI) ? to_pci_dev(boardp->dev) : NULL;
 
@@ -10987,11 +10987,9 @@ static int advansys_board_found(struct Scsi_Host 
*shost, unsigned int iop,
 #ifdef CONFIG_ISA
case ASC_IS_ISA:
shost->unchecked_isa_dma = true;
-   share_irq = 0;
break;
case ASC_IS_VL:
shost->unchecked_isa_dma = false;
-   share_irq = 0;
break;
case ASC_IS_EISA:
shost->unchecked_isa_dma = false;
@@ -11008,7 +11006,6 @@ static int advansys_board_found(struct Scsi_Host 
*shost, unsigned int iop,
shost_printk(KERN_ERR, shost, "unknown adapter type: "
"%d\n", asc_dvc_varp->bus_type);
shost->unchecked_isa_dma = false;
-   share_irq = 0;
break;
}
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 1/2] advansys: Do not byteswap sense_len on big endian

2015-06-24 Thread Geert Uytterhoeven
On big endian (e.g. m68k):

drivers/scsi/advansys.c: In function ‘adv_build_req’:
drivers/scsi/advansys.c:7806: warning: large integer implicitly truncated 
to unsigned type

Indeed, adv_scsi_req_q.sense_len is uchar, not __le32, and must never be
byteswapped.

Fixes: 811ddc057aac7228 ("advansys: use DMA-API for mapping sense buffer")
Signed-off-by: Geert Uytterhoeven 
---
 drivers/scsi/advansys.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/advansys.c b/drivers/scsi/advansys.c
index 4305178e4e0147ba..1c1cd657c380c2e0 100644
--- a/drivers/scsi/advansys.c
+++ b/drivers/scsi/advansys.c
@@ -7803,7 +7803,7 @@ adv_build_req(struct asc_board *boardp, struct scsi_cmnd 
*scp,
return ASC_BUSY;
}
scsiqp->sense_addr = cpu_to_le32(sense_addr);
-   scsiqp->sense_len = cpu_to_le32(SCSI_SENSE_BUFFERSIZE);
+   scsiqp->sense_len = SCSI_SENSE_BUFFERSIZE;
 
/* Build ADV_SCSI_REQ_Q */
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Patch "sd: Disable support for 256 byte/sector disks" has been added to the 4.0-stable tree

2015-06-03 Thread Geert Uytterhoeven
On Wed, Jun 3, 2015 at 3:54 PM, James Bottomley
 wrote:
> On Wed, 2015-06-03 at 13:37 +, James Bottomley wrote:
>> On Wed, 2015-06-03 at 11:29 +0200, Jiri Slaby wrote:
>> > On 06/03/2015, 08:35 AM, gre...@linuxfoundation.org wrote:
>> > > From 74856fbf441929918c49ff262ace9835048e4e6a Mon Sep 17 00:00:00 2001
>> > > From: Mark Hounschell 
>> > > Date: Wed, 13 May 2015 10:49:09 +0200
>> > > Subject: sd: Disable support for 256 byte/sector disks
>> > >
>> > > From: Mark Hounschell 
>> > >
>> > > commit 74856fbf441929918c49ff262ace9835048e4e6a upstream.
>> > >
>> > > 256 bytes per sector support has been broken since 2.6.X,
>> > > and no-one stepped up to fix this.
>> > > So disable support for it.
>> > >
>> > > Signed-off-by: Mark Hounschell 
>> > > Signed-off-by: Hannes Reinecke 
>> > > Signed-off-by: James Bottomley 
>> > > Signed-off-by: Greg Kroah-Hartman 
>> > >
>> > > ---
>> > >  drivers/scsi/sd.c |   19 +--
>> > >  1 file changed, 5 insertions(+), 14 deletions(-)
>> > >
>> > > --- a/drivers/scsi/sd.c
>> > > +++ b/drivers/scsi/sd.c
>> > > @@ -1624,6 +1624,7 @@ static unsigned int sd_completed_bytes(s
>> > >  {
>> > >   u64 start_lba = blk_rq_pos(scmd->request);
>> > >   u64 end_lba = blk_rq_pos(scmd->request) + (scsi_bufflen(scmd) / 512);
>> > > + u64 factor = scmd->device->sector_size / 512;
>> > >   u64 bad_lba;
>> > >   int info_valid;
>> > >   /*
>> > > @@ -1645,16 +1646,9 @@ static unsigned int sd_completed_bytes(s
>> > >   if (scsi_bufflen(scmd) <= scmd->device->sector_size)
>> > >   return 0;
>> > >
>> > > - if (scmd->device->sector_size < 512) {
>> > > - /* only legitimate sector_size here is 256 */
>> > > - start_lba <<= 1;
>> > > - end_lba <<= 1;
>> > > - } else {
>> > > - /* be careful ... don't want any overflows */
>> > > - unsigned int factor = scmd->device->sector_size / 512;
>> > > - do_div(start_lba, factor);
>> > > - do_div(end_lba, factor);
>> > > - }
>> >
>> > Hmm, you do 'unsigned int' -> 'u64' switch of factor type here. But this
>> > commit:
>> > commit ef80d1e18b014af08741cf688e3fdda1fb71363f
>> > Author: Geert Uytterhoeven 
>> > Date:   Mon Nov 4 10:21:05 2013 +0100
>> >
>> > [SCSI] sd: Do not call do_div() with a 64-bit divisor
>> >
>> > did the switch in the opposite direction deliberately.
>> >
>> > So why did you do the change, given sector_size is uint?
>>
>> Primarily because no-one spotted the reversal and none of the static
>> checkers warns about it.
>>
>> This is the trivial fix, but we should do something about the checkers.
>
> Actually, I think there's no problem: all the architectures now have the
> correct conversion of the base argument.
>
> Author: Andreas Schwab 
> Date:   Fri Aug 9 15:14:08 2013 +0200
>
> m68k: Truncate base in do_div()
>
> Fixed this in m68k, which was the last one, so it looks like there's no
> issue and ef80d1e18b014af08741cf688e3fdda1fb71363f was pointless.

FWIW, "[PATCH] mn10300: Truncate base in do_div()"
(http://lkml.iu.edu/hypermail/linux/kernel/1308.2/03544.html)
hasn't been applied yet. But as mn10300 is little endian, it shouldn't
suffer from the bug like m68k did.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH trivial] lpfc: Grammar s/an negative/a negative/

2015-05-21 Thread Geert Uytterhoeven
Signed-off-by: Geert Uytterhoeven 
---
 drivers/scsi/lpfc/lpfc_debugfs.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/scsi/lpfc/lpfc_debugfs.c b/drivers/scsi/lpfc/lpfc_debugfs.c
index 513edcb0c2dae379..25aa9b98d53aa345 100644
--- a/drivers/scsi/lpfc/lpfc_debugfs.c
+++ b/drivers/scsi/lpfc/lpfc_debugfs.c
@@ -710,7 +710,7 @@ lpfc_debugfs_slow_ring_trc(struct lpfc_hba *phba, char *fmt,
  * returns a pointer to that log in the private_data field in @file.
  *
  * Returns:
- * This function returns zero if successful. On error it will return an 
negative
+ * This function returns zero if successful. On error it will return a negative
  * error value.
  **/
 static int
@@ -760,7 +760,7 @@ out:
  * returns a pointer to that log in the private_data field in @file.
  *
  * Returns:
- * This function returns zero if successful. On error it will return an 
negative
+ * This function returns zero if successful. On error it will return a negative
  * error value.
  **/
 static int
@@ -810,7 +810,7 @@ out:
  * returns a pointer to that log in the private_data field in @file.
  *
  * Returns:
- * This function returns zero if successful. On error it will return an 
negative
+ * This function returns zero if successful. On error it will return a negative
  * error value.
  **/
 static int
@@ -852,7 +852,7 @@ out:
  * returns a pointer to that log in the private_data field in @file.
  *
  * Returns:
- * This function returns zero if successful. On error it will return an 
negative
+ * This function returns zero if successful. On error it will return a negative
  * error value.
  **/
 static int
@@ -894,7 +894,7 @@ out:
  * returns a pointer to that log in the private_data field in @file.
  *
  * Returns:
- * This function returns zero if successful. On error it will return an 
negative
+ * This function returns zero if successful. On error it will return a negative
  * error value.
  **/
 static int
@@ -1115,7 +1115,7 @@ lpfc_debugfs_dif_err_release(struct inode *inode, struct 
file *file)
  * returns a pointer to that log in the private_data field in @file.
  *
  * Returns:
- * This function returns zero if successful. On error it will return an 
negative
+ * This function returns zero if successful. On error it will return a negative
  * error value.
  **/
 static int
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: scsi: Implement per-cpu logging buffer

2015-02-14 Thread Geert Uytterhoeven
Hi Hannes,

On Sat, Feb 14, 2015 at 3:29 PM, Hannes Reinecke  wrote:
> @jejb, hch: should I do a new patch or update the existing one?

As the existing one is already upstream, you should send a new patch.

Thanks!

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: scsi: Implement per-cpu logging buffer

2015-02-12 Thread Geert Uytterhoeven
On Wed, Feb 11, 2015 at 8:16 PM, Linux Kernel Mailing List
 wrote:
> Gitweb: 
> http://git.kernel.org/linus/;a=commit;h=ded85c193a391a84076d5c6a7a5668fe164a490e
> Commit: ded85c193a391a84076d5c6a7a5668fe164a490e
> Parent: b0a93d96b2814c725161f91a4e35d0c29ec0f95b
> Refname:refs/heads/master
> Author: Hannes Reinecke 
> AuthorDate: Thu Jan 8 07:43:42 2015 +0100
> Committer:  Christoph Hellwig 
> CommitDate: Fri Jan 9 15:44:28 2015 +0100
>
> scsi: Implement per-cpu logging buffer
>
> Implement a per-cpu buffer for formatting messages to avoid line breaks
> up under high load.  This patch implements scmd_printk() and
> sdev_prefix_printk() using the per-cpu buffer and makes sdev_printk() a
> wrapper for sdev_prefix_printk().
>
> Tested-by: Robert Elliott 
> Reviewed-by: Robert Elliott 
> Signed-off-by: Hannes Reinecke 
> Signed-off-by: Christoph Hellwig 

> --- /dev/null
> +++ b/drivers/scsi/scsi_logging.c

> +#define SCSI_LOG_SPOOLSIZE 4096
> +#define SCSI_LOG_BUFSIZE 128
> +
> +#if (SCSI_LOG_SPOOLSIZE / SCSI_LOG_BUFSIZE) > BITS_PER_LONG
> +#warning SCSI logging bitmask too large
> +#endif
> +
> +struct scsi_log_buf {
> +   char buffer[SCSI_LOG_SPOOLSIZE];
> +   unsigned long map;
> +};
> +
> +static DEFINE_PER_CPU(struct scsi_log_buf, scsi_format_log);

Do we really need a static 4 KiB per-CPU buffer?

bloat-o-meter:

add/remove: 183/94 grow/shrink: 314/211 up/down: 33467/-21291 (12176)
function old new   delta
scsi_format_log-4100   +4100
handle_mm_fault 17942750+956
scsi_log_print_sense_hdr   - 774+774
proc_keys_show - 770+770

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] g_NCR5380: Kill compiler warning if builtin

2015-01-03 Thread Geert Uytterhoeven
If CONFIG_SCSI_GENERIC_NCR5380=y:

drivers/scsi/g_NCR5380.c:727: warning: ‘id_table’ defined but not used

In the non-modular case, MODULE_DEVICE_TABLE() expands to nothing, and
id_table is not referenced.

Correct the existing #ifdef to fix this.

Signed-off-by: Geert Uytterhoeven 
---
 drivers/scsi/g_NCR5380.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/g_NCR5380.c b/drivers/scsi/g_NCR5380.c
index f35792f7051c0884..74ec2f5669aba5f5 100644
--- a/drivers/scsi/g_NCR5380.c
+++ b/drivers/scsi/g_NCR5380.c
@@ -723,7 +723,7 @@ module_param(ncr_53c400a, int, 0);
 module_param(dtc_3181e, int, 0);
 MODULE_LICENSE("GPL");
 
-#ifndef SCSI_G_NCR5380_MEM
+#if !defined(SCSI_G_NCR5380_MEM) && defined(MODULE)
 static struct isapnp_device_id id_table[] = {
{
 ISAPNP_ANY_ID, ISAPNP_ANY_ID,
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: esp_scsi: make number of tags configurable

2014-12-10 Thread Geert Uytterhoeven
On Tue, Dec 9, 2014 at 6:36 AM, Linux Kernel Mailing List
 wrote:
> Gitweb: 
> http://git.kernel.org/linus/;a=commit;h=3707a186c8970e3c4f3c8d9ccf4230b8657e919f
> Commit: 3707a186c8970e3c4f3c8d9ccf4230b8657e919f
> Parent: a87bf29362c763cf35faa17154b699471a8b902e
> Refname:refs/heads/master
> Author: Hannes Reinecke 
> AuthorDate: Mon Nov 24 15:37:20 2014 +0100
> Committer:  Christoph Hellwig 
> CommitDate: Mon Nov 24 16:10:23 2014 +0100
>
> esp_scsi: make number of tags configurable
>
> Add a field 'num_tags' to the esp structure to allow drivers
> to overwrite the number of avialable tags if required.
> Default is ESP_DEFAULT_TAGS.
>
> Reviewed-by: Paolo Bonzini 
> Acked-by: David S. Miller 
> Signed-off-by: Hannes Reinecke 
> Signed-off-by: Christoph Hellwig 
> ---
>  drivers/scsi/esp_scsi.c | 12 ++--
>  drivers/scsi/esp_scsi.h |  3 +--
>  2 files changed, 7 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/scsi/esp_scsi.c b/drivers/scsi/esp_scsi.c
> index 7e7687f..57ccb14 100644
> --- a/drivers/scsi/esp_scsi.c
> +++ b/drivers/scsi/esp_scsi.c
> @@ -2317,6 +2317,10 @@ int scsi_esp_register(struct esp *esp, struct device 
> *dev)
> static int instance;
> int err;
>
> +   if (!esp->num_tags)
> +   esp->num_tags = ESP_DEFAULT_TAGS;
> +   else if (esp->num_tags >= ESP_MAX_TAG)

drivers/scsi/esp_scsi.c: In function ‘scsi_esp_register’:
drivers/scsi/esp_scsi.c:2399: warning: comparison is always false due
to limited range of data type

ESP_MAX_TAG is 256, num_tags is u8.

> +   esp->num_tags = ESP_MAX_TAG - 1;

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH/TRIVIAL 3/4] [SCSI] aic7xxx: Grammar s/if ... if/if ... is/

2014-11-27 Thread Geert Uytterhoeven
Signed-off-by: Geert Uytterhoeven 
Cc: Hannes Reinecke 
Cc: linux-scsi@vger.kernel.org
---
 drivers/scsi/aic7xxx/aic79xx_core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/aic7xxx/aic79xx_core.c 
b/drivers/scsi/aic7xxx/aic79xx_core.c
index 0bcacf71aef814fe..97f2accd3dbb48ac 100644
--- a/drivers/scsi/aic7xxx/aic79xx_core.c
+++ b/drivers/scsi/aic7xxx/aic79xx_core.c
@@ -1298,7 +1298,7 @@ rescan_fifos:
 
/*
 * Wait for any inprogress DMA to complete and clear DMA state
-* if this if for an SCB in the qinfifo.
+* if this is for an SCB in the qinfifo.
 */
while (((ccscbctl = ahd_inb(ahd, CCSCBCTL)) & (CCARREN|CCSCBEN)) != 0) {
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v3 25/37] sun3_scsi: Convert to platform device

2014-11-12 Thread Geert Uytterhoeven
Hi Finn,

On Wed, Nov 12, 2014 at 6:12 AM, Finn Thain  wrote:
> Changes since v2:
> - Give more precise addresses in platform resource initializers and

Thanks!

>   move PAGE_SIZE back to ioremap() arguments.

Sorry, I think I didn't make myself clear, and you thus misunderstood.
I meant PAGE_SIZE makes sense when ioremap()ing a small region
at a hardcoded address, where you don't care about the exact size, as it
will be rounded up to PAGE_SIZE anyway.

When ioremap()ing resources, please use the size provided by the resource.

> +static int __init sun3_scsi_probe(struct platform_device *pdev)
> +{
> +   struct Scsi_Host *instance;
> +   int error;
> +   struct resource *irq, *mem;
> +   unsigned char *ioaddr;
> +#ifdef SUN3_SCSI_VME
> +   int i;
> +#endif
> +
> +   if (setup_can_queue > 0)
> +   sun3_scsi_template.can_queue = setup_can_queue;
> +   if (setup_cmd_per_lun > 0)
> +   sun3_scsi_template.cmd_per_lun = setup_cmd_per_lun;
> +   if (setup_sg_tablesize >= 0)
> +   sun3_scsi_template.sg_tablesize = setup_sg_tablesize;
> +   if (setup_hostid >= 0)
> +   sun3_scsi_template.this_id = setup_hostid & 7;
> +
> +#ifdef SUPPORT_TAGS
> +   if (setup_use_tagged_queuing < 0)
> +   setup_use_tagged_queuing = 1;
> +#endif
> +
> +#ifdef SUN3_SCSI_VME
> +   ioaddr = NULL;
> +   for (i = 0; i < 2; i++) {
> +   unsigned char x;
> +
> +   irq = platform_get_resource(pdev, IORESOURCE_IRQ, i);
> +   mem = platform_get_resource(pdev, IORESOURCE_MEM, i);
> +   if (!irq || !mem)
> +   break;
> +
> +   ioaddr = sun3_ioremap(mem->start, PAGE_SIZE,

Here ...

> + SUN3_PAGE_TYPE_VME16);
> +   dregs = (struct sun3_dma_regs *)(ioaddr + 8);
> +
> +   if (sun3_map_test((unsigned long)dregs, &x)) {
> +   unsigned short oldcsr;
> +
> +   oldcsr = dregs->csr;
> +   dregs->csr = 0;
> +   udelay(SUN3_DMA_DELAY);
> +   if (dregs->csr == 0x1400)
> +   break;
> +
> +   dregs->csr = oldcsr;
> +   }
> +
> +   iounmap(ioaddr);
> +   ioaddr = NULL;
> +   }
> +   if (!ioaddr)
> +   return -ENODEV;
> +#else
> +   irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
> +   mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +   if (!irq || !mem)
> +   return -ENODEV;
> +
> +   ioaddr = ioremap(mem->start, PAGE_SIZE);

and here.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 25/36] sun3_scsi: Convert to platform device

2014-11-09 Thread Geert Uytterhoeven
On Sun, Nov 9, 2014 at 1:12 PM, Finn Thain  wrote:
>> According to the Sun-3 Architecture Manual v2.0 (May 1985), end should
>> be 0x0014001f.
>
> OK. Where did you find that, BTW?

In my local collection of hardware docs I downloaded eons ago ;-)
Fortunately it hasn't disappeared from the Internet, unlike many others docs
I've collected over the years:

https://www.google.be/search?q=Sun-3_Architecture_Manual_Ver_2.0_May85.pdf

>> I guess the resource length is 0x20 for VME SCSI, too?
>
> For VME SCSI it would need to be 8 + sizeof(struct sun3_dma_regs) which I
> think equals 0x22:

IC.

Gr{oetje,eeting}s,

    Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 00/36] Fixes, cleanups and modernization for NCR5380 drivers

2014-11-09 Thread Geert Uytterhoeven
Hi Finn,

On Fri, Nov 7, 2014 at 3:34 AM, Finn Thain  wrote:
>> it's probably not Geert but James who needs to give the go-ahead.
>
> Given Geert's objections to the changes under arch/m68k in v1, I'm hoping
> for an acked-by from Geert for v2...

I'm happy with the arch/m68k changes in v2 (modulo the PAGE_SIZE
comment on Sun-3), so please add my
Acked-by: Geert Uytterhoeven 
after fixing that one.
As I'm not afraid of merge conflicts, I think this can go in through the SCSI
tree? James?

Note that there's still room for improvement in the individual drivers, using
more modern infrastructure (e.g. using devm_*() calls, and getting rid of the
multiple ATARIHW_PRESENT() checks using e.g. platform_data or regmap).
But this is already a giant step forward.

Thanks a lot for doing this cleanup!
Removing ca. 3700 LoC deserves you a spot in the LoC removal Hall of Fame!

Gr{oetje,eeting}s,

    Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 25/36] sun3_scsi: Convert to platform device

2014-11-09 Thread Geert Uytterhoeven
On Mon, Oct 27, 2014 at 6:26 AM, Finn Thain  wrote:
> --- linux.orig/arch/m68k/sun3/config.c  2014-10-27 16:17:59.0 +1100
> +++ linux/arch/m68k/sun3/config.c   2014-10-27 16:25:50.0 +1100

> @@ -169,3 +171,61 @@ static void __init sun3_sched_init(irq_h
>  intersil_clear();
>  }
>
> +#ifdef CONFIG_SUN3_SCSI
> +
> +static const struct resource sun3_scsi_vme_rsrc[] __initconst = {
> +   {
> +   .flags = IORESOURCE_IRQ,
> +   .start = SUN3_VEC_VMESCSI0,
> +   .end   = SUN3_VEC_VMESCSI0,
> +   }, {
> +   .flags = IORESOURCE_MEM,
> +   .start = 0xff20,
> +   .end   = 0xff20 + PAGE_SIZE - 1,

PAGE_SIZE is a software kernel configuration option, not a hardware
property. It makes sense to use it in an ioremap() call, but not in a
platform device's resource, which describes the hardware.

> +   }, {
> +   .flags = IORESOURCE_IRQ,
> +   .start = SUN3_VEC_VMESCSI1,
> +   .end   = SUN3_VEC_VMESCSI1,
> +   }, {
> +   .flags = IORESOURCE_MEM,
> +   .start = 0xff204000,
> +   .end   = 0xff204000 + PAGE_SIZE - 1,

Likewise

> +   },
> +};
> +
> +/*
> + * Int: level 2 autovector
> + * IO: type 1, base 0x0014, 5 bits phys space: A<4..0>
> + */
> +static const struct resource sun3_scsi_rsrc[] __initconst = {
> +   {
> +   .flags = IORESOURCE_IRQ,
> +   .start = 2,
> +   .end   = 2,
> +   }, {
> +   .flags = IORESOURCE_MEM,
> +   .start = 0x0014,
> +   .end   = 0x0014 + PAGE_SIZE - 1,

Likewise

According to the Sun-3 Architecture Manual v2.0 (May 1985), end should
be 0x0014001f.

I guess the resource length is 0x20 for VME SCSI, too?

> +   },

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 00/36] Fixes, cleanups and modernization for NCR5380 drivers

2014-11-05 Thread Geert Uytterhoeven
On Wed, Nov 5, 2014 at 8:56 AM, David Gálvez  wrote:
> Do you know about the Falcon's disturbance in the SDMA clock signal
> hardware problem?
> Most Falcons, specially those used in music studios, have a hardware
> patch to fix this, it's normally called SCSI patch.
>
> Some more info:
>
> http://didierm.pagesperso-orange.fr/doc/eng/c_0a.htm

So this adds additional buffering to the clock.

Note that input pins 3 and 5 of the 74HC04 are left floating!
I recommend tying them to either GND (pin 7) or VCC (pin 14), to avoid
them picking up high-frequency signals and consuming power.

Gr{oetje,eeting}s,

    Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: bisected regression: qla2xxx endianness on sparc64

2014-11-03 Thread Geert Uytterhoeven
On Sun, Nov 2, 2014 at 7:10 PM, Meelis Roos  wrote:
> Between 3.17 and 3.18-rc2, qla2xxx is broken on my sparc64 machines. It
> fails to boot (hangs in firmware rings init).
>
> This is the result of bisect:
>
> 98aee70d19a7e3203649fa2078464e4f402a0ad8 is the first bad commit
> commit 98aee70d19a7e3203649fa2078464e4f402a0ad8
> Author: Joe Carnuccio 
> Date:   Thu Sep 25 05:16:38 2014 -0400
>
> qla2xxx: Add endianizer to max_payload_size modifier.
>
> Signed-off-by: Joe Carnuccio 
> Signed-off-by: Saurav Kashyap 
> Signed-off-by: Christoph Hellwig 
>
> :04 04 041c1a26dc2a7988900acc982e3bd65d3cf7e751
> 9700d09c3226fc352d44352f22b84f1be632d324 M  s
>
> This may not be the only problem - when bisecting, I also came to commits
> that got past this step but hang after about 165 seconds of uptime while
> running userspace startup scripts. But let that be another issue at the
> moment.

Switching from uint16_t to __le16 but _removing_ cpu_to_le16() operations
looks indeed very fishy.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 23/29] atari_scsi: Convert to platform device

2014-10-06 Thread Geert Uytterhoeven
On Mon, Oct 6, 2014 at 9:05 AM, Finn Thain  wrote:
>> > > > +   if (IS_A_TT())
>> > > > +   instance->irq = IRQ_TT_MFP_SCSI;
>> > > > +   else
>> > > > +   instance->irq = IRQ_NONE;
>> > > >
>> > > platform_device resource?
>> > >
>> >
>> > If I thought it possible to parameterize the driver such that it never
>> > had to test IS_A_TT(), I'd probably agree that this would be more
>> > elegant.
>> >
>> > Otherwise I'd prefer not to have parts of the logic separated off into
>> > the platform resources while the remaining logic remains in the driver
>> > itself.
>> >
>> > While I don't think platform resources are desirable in this driver, I
>> > would like to hear Michael's views.
>> >
>>
>> The IRQ is a good candidate to be passed via platform data.
>
> Geert didn't say so, but after thinking about his review comments I
> imagine that he wants all the Atari IRQ numbers kept in one place and all
> the Mac IRQ numbers in a different place, and so on. Makes sense.

In the end, it's the same SCSI chip.

The "only" differences are resources, interrupts, DMA, and glue logic.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 19/29] mac_scsi: Add module option to Kconfig

2014-10-03 Thread Geert Uytterhoeven
On Fri, Oct 3, 2014 at 12:49 PM, Finn Thain  wrote:
> On Fri, 3 Oct 2014, Geert Uytterhoeven wrote:
>> On Thu, Oct 2, 2014 at 8:56 AM, Finn Thain  
>> wrote:
>> > Allow mac_scsi to be built as a module. Replace the old validation of
>> > __setup options with code that validates both module and __setup options.
>>
>> > --- linux.orig/drivers/scsi/mac_scsi.c  2014-10-02 16:56:17.0 +1000
>> > +++ linux/drivers/scsi/mac_scsi.c   2014-10-02 16:56:17.0 +1000
>>
>> > @@ -219,15 +179,15 @@ int __init macscsi_detect(struct scsi_ho
>> > return 0;
>> >
>> >  if (macintosh_config->ident == MAC_MODEL_IIFX) {
>> > -   mac_scsi_regp  = via1+0x8000;
>> > -   mac_scsi_drq   = via1+0xE000;
>> > -   mac_scsi_nodrq = via1+0xC000;
>> > +   mac_scsi_regp  = (unsigned char *) VIA1_BASE + 0x8000;
>> > +   mac_scsi_drq   = (unsigned char *) VIA1_BASE + 0xE000;
>> > +   mac_scsi_nodrq = (unsigned char *) VIA1_BASE + 0xC000;
>> > /* The IIFX should be able to do true DMA, but pseudo-dma doesn't 
>> > work */
>> > flags = FLAG_NO_PSEUDO_DMA;
>> >  } else {
>> > -   mac_scsi_regp  = via1+0x1;
>> > -   mac_scsi_drq   = via1+0x6000;
>> > -   mac_scsi_nodrq = via1+0x12000;
>> > +   mac_scsi_regp  = (unsigned char *) VIA1_BASE + 0x1;
>> > +   mac_scsi_drq   = (unsigned char *) VIA1_BASE + 0x6000;
>> > +   mac_scsi_nodrq = (unsigned char *) VIA1_BASE + 0x12000;
>> >  }
>> >
>> >  if (! setup_use_pdma)
>>
>> I don't think the above chunk belongs in this patch.
>
> via1 is not an exported symbol, so this allows mac_scsi to be linked as a
> module.

OK.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 23/29] atari_scsi: Convert to platform device

2014-10-03 Thread Geert Uytterhoeven
  * In principle it should be sufficient to do max. 1 byte with
> +* PIO, but there is another problem on the Medusa with the 
> DMA
> +* rest data register. So 'atari_read_overruns' is currently 
> set
> +* to 4 to avoid having transfers that aren't a multiple of 4.
> +* If the rest data bug is fixed, this can be lowered to 1.
> +*/
> +   if (MACH_IS_MEDUSA)
> +   atari_read_overruns = 4;
> +#endif
> +   } else {
> +       /* Nothing to do for the interrupt: the ST-DMA is initialized
> +* already.
> +*/
> +#ifdef REAL_DMA
> +   atari_dma_residual = 0;
> +   atari_dma_active = 0;
> +   atari_dma_stram_mask = (ATARIHW_PRESENT(EXTD_DMA) ? 0x
> +   : 0xff00);
> +#endif
> +   }

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 22/29] atari_scsi: Fix atari_scsi deadlocks on Falcon

2014-10-03 Thread Geert Uytterhoeven
On Thu, Oct 2, 2014 at 8:56 AM, Finn Thain  wrote:
> --- linux.orig/arch/m68k/atari/stdma.c  2014-10-02 16:55:28.0 +1000
> +++ linux/arch/m68k/atari/stdma.c   2014-10-02 16:56:20.0 +1000

> -int stdma_others_waiting(void)
> +int stdma_is_locked_by(irq_handler_t handler)
>  {
> -   return waitqueue_active(&stdma_wait);
> +   unsigned long flags;
> +
> +   local_irq_save(flags);
> +   if (stdma_locked && (stdma_isr == handler)) {
> +   local_irq_restore(flags);
> +   return 1;
> +   }
> +   local_irq_restore(flags);
> +   return 0;
>  }

This can be written shorter:

int stdma_is_locked_by(irq_handler_t handler)
{
unsigned long flags;
int res;

local_irq_save(flags);
res = stdma_locked && (stdma_isr == handler);
local_irq_restore(flags);

return res;
}

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 21/29] mac_scsi: Convert to platform device

2014-10-03 Thread Geert Uytterhoeven
On Thu, Oct 2, 2014 at 8:56 AM, Finn Thain  wrote:
> Convert mac_scsi to platform device and eliminate scsi_register().
>
> Platform resources for chip registers now follow the documentation. This
> should fix issues with the Mac IIci (and possibly other models too).
>
> Signed-off-by: Finn Thain 
>
> ---
>
> The new hwreg_present() call is not protected by local_irq_save/restore.
> This assumes Geert's patch, "Disable/restore interrupts in
> hwreg_present()/hwreg_write()":
> http://marc.info/?l=linux-kernel&m=141189640826704&w=2

OK, so this cannot go in before v3.18-rc1.

> --- linux.orig/drivers/scsi/mac_scsi.c  2014-10-02 16:56:18.0 +1000
> +++ linux/drivers/scsi/mac_scsi.c   2014-10-02 16:56:19.0 +1000

> @@ -480,7 +380,117 @@ static struct scsi_host_template driver_
> .use_clustering = DISABLE_CLUSTERING
>  };
>
> +static int __init mac_scsi_probe(struct platform_device *pdev)
> +{
> +   struct Scsi_Host *instance;
> +   int error;
> +   int host_flags = 0;
> +   struct resource *irq, *pio_mem, *pdma_mem = NULL;
> +
> +   if (!MACH_IS_MAC)
> +   return -ENODEV;

This check is not needed, asuming you'll only instantiate the platform
device when running on a Mac.

> --- linux.orig/arch/m68k/mac/config.c   2014-10-02 16:55:28.0 +1000
> +++ linux/arch/m68k/mac/config.c2014-10-02 16:56:19.0 +1000

> @@ -929,6 +929,36 @@ static struct platform_device swim_pdev
> .resource   = &swim_rsrc,
>  };
>
> +static struct resource mac_scsi_0_rsrc[] = {
> +   {
> +   .flags = IORESOURCE_IRQ,
> +   .start = IRQ_MAC_SCSI,
> +   .end   = IRQ_MAC_SCSI,
> +   },
> +   { .flags = IORESOURCE_MEM },
> +   { .flags = IORESOURCE_MEM },
> +};
> +
> +static struct resource mac_scsi_1_rsrc[] = {
> +   /* IRQ_NUBUS_E maybe? */
> +   { .flags = IORESOURCE_MEM },
> +   { .flags = IORESOURCE_MEM },
> +};
> +
> +static struct platform_device mac_scsi_0_pdev = {
> +   .name   = "mac_scsi",
> +   .id = 0,
> +   .resource   = mac_scsi_0_rsrc,
> +   .num_resources  = ARRAY_SIZE(mac_scsi_0_rsrc),
> +};
> +
> +static struct platform_device mac_scsi_1_pdev = {
> +   .name   = "mac_scsi",
> +   .id = 1,
> +   .resource   = mac_scsi_1_rsrc,
> +   .num_resources  = ARRAY_SIZE(mac_scsi_1_rsrc),
> +};
> +
>  static struct platform_device esp_0_pdev = {
> .name   = "mac_esp",
> .id = 0,
> @@ -1000,6 +1030,53 @@ int __init mac_platform_init(void)
> (macintosh_config->ident == MAC_MODEL_Q950))
> platform_device_register(&esp_1_pdev);
> break;
> +   case MAC_SCSI_IIFX:
> +   /* Addresses from The Guide to Mac Family Hardware. */
> +   mac_scsi_0_rsrc[1].start = 0x50008000; /* SCSI DMA */
> +   mac_scsi_0_rsrc[1].end = mac_scsi_0_rsrc[1].start + 0x1FFF;
> +   /* $5000 E000 - $5000 : Alternate SCSI (Hsk) */
> +   /* $5000 C000 - $5000 DFFF: Alternate SCSI (DMA) */
> +   /* The SCSI DMA custom IC embeds the 53C80 core. mac_scsi does
> +* not make use of its DMA or hardware handshaking logic.
> +*/
> +   mac_scsi_0_pdev.num_resources--;
> +   platform_device_register(&mac_scsi_0_pdev);

What about removing the static mac_scsi_0_pdev and mac_scsi_1_pdev,
and calling platform_device_register_simple() instead?
That way you
(a) don't have to fiddle with mac_scsi_0_pdev.num_resources, and
(b) the resources can become const and __initconst, as a copy will be
allocated dynamically.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


  1   2   3   >