Re: [PATCH v3] m68k/amiga - Amiga Zorro NCR53C9x boards: new zorro_esp.c
On Fri, 16 Mar 2018, Michael Schmitz wrote: > Hi Finn, Geert, > > 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? > OK. > Placing the two macros in a suitable header in arch/m68k/include/asm/ so > Mac and Amiga can share the same code without duplicating it in two > files would be another option (that forces use of addr and fifo as > parameters), but let's not overengineer things. Yes, deduplication would be nice but I'd like to extend that to the entire PIO implementation. We should be using the portable IO routines but I'd want to do some timings first. Inline assembly was unavoidable for the PDMA loops. Later when I came to write the PIO versions, I just re-used the existing code without benchmarking. So there's a slim chance that insb/outsb are not slower. It might be sufficient to unroll the m68k raw_insb() and raw_outsb() loops, just as raw_insw() and raw_outsw() have been unrolled. But again, I'd want to measure that. -- > I don't expect any other driver would need to share this code, or the > PDMA macros also in the Mac driver... > > Other than that, I've implemented and tested all the suggested changes > and could post v4 of this patch now. > > Cheers, > > ??? Michael
[PATCH v4] m68k/amiga - Amiga Zorro NCR53C9x boards: new zorro_esp.c
From: Michael Schmitz New combined SCSI driver for all ESP based Zorro SCSI boards for m68k Amiga. Code largely based on board specific parts of the old drivers (blz1230.c, blz2060.c, cyberstorm.c, cyberstormII.c, fastlane.c which were removed after the 2.6 kernel series for lack of maintenance) with contributions by Tuomas Vainikka (TCQ bug tests and workaround) and Finn Thain (TCQ bugfix by use of PIO in extended message in transfer). New Kconfig option and Makefile entries for new Amiga Zorro ESP SCSI driver included in this patch. Use DMA transfers wherever possible, with board-specific DMA set-up functions copied from the old driver code. Three byte reselection messages do appear to cause DMA timeouts. So wire up a PIO transfer routine for these instead. esp_reselect_with_tag explicitly sets esp->cmd_block_dma as target address for the message bytes but PIO requires a virtual address. Substiute kernel virtual address esp->cmd_block in PIO transfer call if DMA address is esp->cmd_block_dma and phase is message in. PIO code taken from mac_esp.c where the reselection timeout issue was debugged and fixed first, with minor macro and function rename. Signed-off-by: Michael Schmitz Reviewed-by: Finn Thain --- Changes since v1: Fixed issues raised by Finn Thain in initial code review: - use KBUILD_MODNAME for driver name string. - use pr_fmt() for pr_* format prefix. - clean up DMA error reporting: clear error flag before each DMA operation, set error flag on PIO error. Don't test phase in dma_err hook. - change confusing comment about semantics of read flag, add comments indicating DMA direction to DMA setup hooks. - drop spurious braces around switch clauses. - lift cfreq setting out of ID switch clauses. - fix indentation. - fix error codes on probe fail. - drop check for board ID when unmapping DMA regs in error handling: the ioaddr > 0xff test already catches all cases where the DMA registers were ioremapped. - dynamically alloc zorro_private_data. - fix use of driver_data field (don't mix host and zorro_esp_priv pointers). Note: require esp pointer in zorro_esp_priv to find host pointer! - back out phase bits changes to pio_cmd !write branch introduced to cope with ESP SELAS command. We don't use that code so keep it in sync with Finn's version. - use esp_ops.dma_length_limit() to limit transfer size. After review of old driver code, use 0xff max transfer size throughout. Fixed issues raised by Geert Uytterhoven: - dynamically alloc zorro_private_data, store as device drvdata. - store ctrl_data for CyberStormI in driver private data. - use dma_sync_single_for_device() instead of cache_push/clear. - handle case of duplicate board identity - check whether board is Zorro III or Zorro II (use ROM resource data for this). Also fix up DMA mask for Zorro II boards to 32 bits (these are really CPU expansion slot boards). - remove zorro3 field from driver_data struct (now in private data). - add braces around ambiguous if - else construct. - use named structs instead of array for board config data. - use scsi_option driver data flag for boards with optional ESP. Other improvements and bugfixes - fix Zorro device table error (duplicate ID used, also raised by Kars de Jong). - error code fixup in error handling path. - add separate DMA setup for Blizzard 1230 II board. - add support for Cyberstorm II board. - add register structs and DMA setup for Zorro III Fastlane board, following logic from old fastlane.c driver. Wire up Fastlane DMA and interrupt status routines, map the necessary low 24 bit board address space used for DMA target address setting. Clean up DMA register space ioremap() branch for Zorro III boards (currently Fastlane only) to end confusion about what to do in error recovery. - use esp_ops.fastlane_esp_dma_invalidate() on Fastlane (and skip fastlane_esp_reset_dma() in DMA setup). - credit Tuomas Vainikka for contributing Blizzard 1230 code (and testing). - clarify comment about unsupported Oktagon SCSI board. - remove unused const definitions carried over from old driver. Changes since v2: - add SPDX-License-Identifier. - remove unused ratelimit.h. - drop phys_to_virt() in PIO transfer routine, after ensuring PIO is only used for message in transfers to esp->command_block. This obviates any need for finding the virtual address corresponding to a DMA handle. - drop BUG_ON(!(cmd & ESP_CMD_DMA)) assertion in DMA setup. Short of changes to the core ESP driver, this can never trigger. - make ioremap() of DMA address range conditional on zep->zorro3 and use that same condition to unmap in error handling and driver exit. Omit board ID test as we only support a single Zorro III board, and add comment on what to do when adding support for more boards. - free driver private data in driver exit. - various whitespace related cleanup. Changes since v3: Finn Thain: - substitute esp->command_block for transfer address in each board
Re: [PATCH] [RFC] target/file: add support of direct and async I/O
Hi Christoph, Thank you for the review. All comments look reasonable. I will fix and set a final version soon. Pls, answer on one inline question. On Fri, Mar 16, 2018 at 12:50:27AM -0700, Christoph Hellwig wrote: > > DIF (PI) emulation doesn't work when a target uses async I/O, because > > DIF metadata is saved in a separate file, and it is another non-trivial > > task how to synchronize writing in two files, so that a following read > > operation always returns a consisten metadata for a specified block. > > There literally is no way to do that, even without aio. The file > DIF implementation should probably regarded as an early bringup / > prototype tool, not something really usable. > > > +static void cmd_rw_aio_do_completion(struct target_core_file_cmd *cmd) > > +{ > > + if (!atomic_dec_and_test(&cmd->ref)) > > + return; > > There is no need for reference counting. If the read_iter/write iter > method returns -EIOCBQUEUED the completion callback needs to complete > the I/O and free the structure, else the method caller. > > > + if (!(fd_dev->fbd_flags & FDBD_HAS_BUFFERED_IO_WCE)) > > + aio_cmd->iocb.ki_flags |= IOCB_DIRECT; > > aio without IOCB_DIRECT doesn't make any sense. But the WCE flag > really has nothing to do with buffers vs direct I/O anyway. > > > + if (is_write) > > + ret = call_write_iter(file, &aio_cmd->iocb, &iter); > > + else > > + ret = call_read_iter(file, &aio_cmd->iocb, &iter); > > Please call the methods directly instead of through the wrappers. Do you mean to call file->f_op->write_iter(kio, iter) instead of call_write_iter()? What is wrong with these wrappers? Thanks, Andrei > > > + > > static int fd_do_rw(struct se_cmd *cmd, struct file *fd, > > u32 block_size, struct scatterlist *sgl, > > u32 sgl_nents, u32 data_length, int is_write) > > @@ -536,6 +626,7 @@ fd_execute_rw(struct se_cmd *cmd, struct scatterlist > > *sgl, u32 sgl_nents, > > struct file *pfile = fd_dev->fd_prot_file; > > sense_reason_t rc; > > int ret = 0; > > + int aio = fd_dev->fbd_flags & FDBD_HAS_ASYNC_IO; > > /* > > * We are currently limited by the number of iovecs (2048) per > > * single vfs_[writev,readv] call. > > @@ -550,7 +641,11 @@ fd_execute_rw(struct se_cmd *cmd, struct scatterlist > > *sgl, u32 sgl_nents, > > * Call vectorized fileio functions to map struct scatterlist > > * physical memory addresses to struct iovec virtual memory. > > */ > > - if (data_direction == DMA_FROM_DEVICE) { > > + if (aio) { > > fd_execute_rw shares basically no code with the aio case. I'd rather > have a very high level wrapper here: > > static sense_reason_t > fd_execute_rw(struct se_cmd *cmd, struct scatterlist *sgl, u32 sgl_nents, > enum dma_data_direction data_direction) > { > if (FD_DEV(cmd->se_dev)->fbd_flags & FDBD_HAS_ASYNC_IO) > return fd_execute_rw_aio(cmd, sgl, sgl_nents, dma_direction); > return fd_execute_rw_buffered(cmd, sgl, sgl_nents, dma_direction); > } > > and keep the code separate. >
Re: [PATCH v2] scsi: Avoid that .queuecommand() gets called for a quiesced SCSI device
On Fri, 2018-03-16 at 15:49 -0700, James Bottomley wrote: > In your new code you have > > + if (sdev->sdev_state != SDEV_QUIESCE) > + rtn = shost->hostt->queuecommand(shost, scmd); > + else > + rtn = SCSI_MLQUEUE_DEVICE_BUSY; > > That sets rtn instead of calling queuecommand > > Then you drop through to this code below: > > if (rtn) { > if (timeleft > stall_for) { > scsi_eh_restore_cmnd(scmd, &ses); > timeleft -= stall_for; > msleep(jiffies_to_msecs(stall_for)); > goto retry; > } > > Which causes a msleep which is equivalent to the while loop. Hello James, Thanks for the clarification - apparently we were each looking at another part of the code. If the "rtn = SCSI_MLQUEUE_DEVICE_BUSY" statement is executed that means that the if-statement that controls that statement noticed that sdev->sdev_state == SDEV_QUIESCE. Since the while loop above that statement only finishes if either sdev->sdev_state != SDEV_QUIESCE or timeleft <= 0, if the "rtn = SCSI_MLQUEUE_DEVICE_BUSY" statement is executed that implies that timeleft <= 0. Since stall_for > 0, the expression timeleft > stall_for will evaluate to false. In other words, the msleep() shown in your e-mail will be skipped. Bart.
Re: [PATCH v2] scsi: Avoid that .queuecommand() gets called for a quiesced SCSI device
On Fri, 2018-03-16 at 22:40 +, Bart Van Assche wrote: > On Fri, 2018-03-16 at 15:31 -0700, James Bottomley wrote: > > > > On Fri, 2018-03-16 at 22:21 +, Bart Van Assche wrote: > > > > > > On Fri, 2018-03-16 at 15:00 -0700, James Bottomley wrote: > > > > > > > > > > > > On Fri, 2018-03-16 at 10:40 -0700, Bart Van Assche wrote: > > > > > > > > > > > > > > > @@ -1050,7 +1050,22 @@ static int scsi_send_eh_cmnd(struct > > > > > scsi_cmnd > > > > > *scmd, unsigned char *cmnd, > > > > > > > > > > scsi_log_send(scmd); > > > > > scmd->scsi_done = scsi_eh_done; > > > > > - rtn = shost->hostt->queuecommand(shost, scmd); > > > > > + mutex_lock(&sdev->state_mutex); > > > > > + while (sdev->sdev_state == SDEV_QUIESCE && timeleft > > > > > > 0) > > > > > { > > > > > + mutex_unlock(&sdev->state_mutex); > > > > > + SCSI_LOG_ERROR_RECOVERY(5, > > > > > sdev_printk(KERN_DEBUG, > > > > > sdev, > > > > > + "%s: state %d <> %d\n", __func__, > > > > > sdev- > > > > > > > > > > > > > > > > > > sdev_state, > > > > > > > > > > + SDEV_QUIESCE)); > > > > > + delay = min(timeleft, stall_for); > > > > > + timeleft -= delay; > > > > > + msleep(jiffies_to_msecs(delay)); > > > > > + mutex_lock(&sdev->state_mutex); > > > > > + } > > > > > > > > What's the point of this loop? if you eliminate it, you still > > > > get > > > > exactly the same msleep from the stall_for retry processing. > > > > > > Hello James, > > > > > > The purpose of that loop is to check the SCSI device state every > > > "stall_for" jiffies and to avoid that more than "timeleft" > > > jiffies is > > > spent on waiting. > > > > I know what the loop does; the the question I was asking is doesn't > > setting rtn instead of calling ->queuecommand() achieve the same > > thing? > > Sorry but I don't understand that last question. How could setting > rtn be an alternative for calling ->queuecommand() since we really > want to call ->queuecommand if the SCSI device leaves the quiesced > state before the timeout has expired? Can you rephrase that last > question? In your new code you have + if (sdev->sdev_state != SDEV_QUIESCE) + rtn = shost->hostt->queuecommand(shost, scmd); + else + rtn = SCSI_MLQUEUE_DEVICE_BUSY; That sets rtn instead of calling queuecommand Then you drop through to this code below: if (rtn) { if (timeleft > stall_for) { scsi_eh_restore_cmnd(scmd, &ses); timeleft -= stall_for; msleep(jiffies_to_msecs(stall_for)); goto retry; } Which causes a msleep which is equivalent to the while loop. James
Re: [PATCH v2] scsi: Avoid that .queuecommand() gets called for a quiesced SCSI device
On Fri, 2018-03-16 at 15:31 -0700, James Bottomley wrote: > On Fri, 2018-03-16 at 22:21 +, Bart Van Assche wrote: > > On Fri, 2018-03-16 at 15:00 -0700, James Bottomley wrote: > > > > > > On Fri, 2018-03-16 at 10:40 -0700, Bart Van Assche wrote: > > > > > > > > @@ -1050,7 +1050,22 @@ static int scsi_send_eh_cmnd(struct > > > > scsi_cmnd > > > > *scmd, unsigned char *cmnd, > > > > > > > > scsi_log_send(scmd); > > > > scmd->scsi_done = scsi_eh_done; > > > > - rtn = shost->hostt->queuecommand(shost, scmd); > > > > + mutex_lock(&sdev->state_mutex); > > > > + while (sdev->sdev_state == SDEV_QUIESCE && timeleft > 0) > > > > { > > > > + mutex_unlock(&sdev->state_mutex); > > > > + SCSI_LOG_ERROR_RECOVERY(5, > > > > sdev_printk(KERN_DEBUG, > > > > sdev, > > > > + "%s: state %d <> %d\n", __func__, sdev- > > > > > > > > > > sdev_state, > > > > > > > > + SDEV_QUIESCE)); > > > > + delay = min(timeleft, stall_for); > > > > + timeleft -= delay; > > > > + msleep(jiffies_to_msecs(delay)); > > > > + mutex_lock(&sdev->state_mutex); > > > > + } > > > > > > What's the point of this loop? if you eliminate it, you still get > > > exactly the same msleep from the stall_for retry processing. > > > > Hello James, > > > > The purpose of that loop is to check the SCSI device state every > > "stall_for" jiffies and to avoid that more than "timeleft" jiffies is > > spent on waiting. > > I know what the loop does; the the question I was asking is doesn't > setting rtn instead of calling ->queuecommand() achieve the same thing? Sorry but I don't understand that last question. How could setting rtn be an alternative for calling ->queuecommand() since we really want to call ->queuecommand if the SCSI device leaves the quiesced state before the timeout has expired? Can you rephrase that last question? Thanks, Bart.
Re: [PATCH v2] scsi: Avoid that .queuecommand() gets called for a quiesced SCSI device
On Fri, 2018-03-16 at 22:21 +, Bart Van Assche wrote: > On Fri, 2018-03-16 at 15:00 -0700, James Bottomley wrote: > > > > On Fri, 2018-03-16 at 10:40 -0700, Bart Van Assche wrote: > > > > > > @@ -1050,7 +1050,22 @@ static int scsi_send_eh_cmnd(struct > > > scsi_cmnd > > > *scmd, unsigned char *cmnd, > > > > > > scsi_log_send(scmd); > > > scmd->scsi_done = scsi_eh_done; > > > - rtn = shost->hostt->queuecommand(shost, scmd); > > > + mutex_lock(&sdev->state_mutex); > > > + while (sdev->sdev_state == SDEV_QUIESCE && timeleft > 0) > > > { > > > + mutex_unlock(&sdev->state_mutex); > > > + SCSI_LOG_ERROR_RECOVERY(5, > > > sdev_printk(KERN_DEBUG, > > > sdev, > > > + "%s: state %d <> %d\n", __func__, sdev- > > > > > > > > sdev_state, > > > > > > + SDEV_QUIESCE)); > > > + delay = min(timeleft, stall_for); > > > + timeleft -= delay; > > > + msleep(jiffies_to_msecs(delay)); > > > + mutex_lock(&sdev->state_mutex); > > > + } > > > > What's the point of this loop? if you eliminate it, you still get > > exactly the same msleep from the stall_for retry processing. > > Hello James, > > The purpose of that loop is to check the SCSI device state every > "stall_for" jiffies and to avoid that more than "timeleft" jiffies is > spent on waiting. I know what the loop does; the the question I was asking is doesn't setting rtn instead of calling ->queuecommand() achieve the same thing? James
Re: [PATCH v2] scsi: Avoid that .queuecommand() gets called for a quiesced SCSI device
On Fri, 2018-03-16 at 15:00 -0700, James Bottomley wrote: > On Fri, 2018-03-16 at 10:40 -0700, Bart Van Assche wrote: > > @@ -1050,7 +1050,22 @@ static int scsi_send_eh_cmnd(struct scsi_cmnd > > *scmd, unsigned char *cmnd, > > > > scsi_log_send(scmd); > > scmd->scsi_done = scsi_eh_done; > > - rtn = shost->hostt->queuecommand(shost, scmd); > > + mutex_lock(&sdev->state_mutex); > > + while (sdev->sdev_state == SDEV_QUIESCE && timeleft > 0) { > > + mutex_unlock(&sdev->state_mutex); > > + SCSI_LOG_ERROR_RECOVERY(5, sdev_printk(KERN_DEBUG, > > sdev, > > + "%s: state %d <> %d\n", __func__, sdev- > > > sdev_state, > > > > + SDEV_QUIESCE)); > > + delay = min(timeleft, stall_for); > > + timeleft -= delay; > > + msleep(jiffies_to_msecs(delay)); > > + mutex_lock(&sdev->state_mutex); > > + } > > What's the point of this loop? if you eliminate it, you still get > exactly the same msleep from the stall_for retry processing. Hello James, The purpose of that loop is to check the SCSI device state every "stall_for" jiffies and to avoid that more than "timeleft" jiffies is spent on waiting. > Plus I really don't think you want to call ->queuecommand() with the > state mutex held. Since .queuecommand() is not allowed to sleep I think that holding the SCSI device state mutex does not introduce the possibility of a new deadlock. What makes you think that calling ->queuecommand() with that mutex held wouldn't be safe? > You don't even need to hold the state mutex to read sdev->state because > the read is atomic and the mutex doesn't mediate anything. The check to > queuecommand race is the same for every consumer. Since both scsi_device_quiesce() and scsi_device_resume() acquire and release the SCSI device .state_mutex, obtaining that mutex realizes serialization of the above code against scsi_device_quiesce() and scsi_device_resume(). If the above code would not obtain .state_mutex then the following race would be possible: * scsi_send_eh_cmnd() sees that .sdev_state == SDEV_QUIESCE and decides that it is safe to call .queuecommand(). * Another thread calls scsi_device_quiesce() and removes some of the resources needed by .queuecommand(). * scsi_send_eh_cmnd() calls .queuecommand(), resulting in a kernel oops. Please let me know if you need more information. Thanks, Bart.
Re: [PATCH v2] scsi: Avoid that .queuecommand() gets called for a quiesced SCSI device
On Fri, 2018-03-16 at 10:40 -0700, Bart Van Assche wrote: > @@ -1050,7 +1050,22 @@ static int scsi_send_eh_cmnd(struct scsi_cmnd > *scmd, unsigned char *cmnd, > > scsi_log_send(scmd); > scmd->scsi_done = scsi_eh_done; > - rtn = shost->hostt->queuecommand(shost, scmd); > + mutex_lock(&sdev->state_mutex); > + while (sdev->sdev_state == SDEV_QUIESCE && timeleft > 0) { > + mutex_unlock(&sdev->state_mutex); > + SCSI_LOG_ERROR_RECOVERY(5, sdev_printk(KERN_DEBUG, > sdev, > + "%s: state %d <> %d\n", __func__, sdev- > >sdev_state, > + SDEV_QUIESCE)); > + delay = min(timeleft, stall_for); > + timeleft -= delay; > + msleep(jiffies_to_msecs(delay)); > + mutex_lock(&sdev->state_mutex); > + } What's the point of this loop? if you eliminate it, you still get exactly the same msleep from the stall_for retry processing. Plus I really don't think you want to call ->queuecommand() with the state mutex held. You don't even need to hold the state mutex to read sdev->state because the read is atomic and the mutex doesn't mediate anything. The check to queuecommand race is the same for every consumer. James
Re: [PATCH] Change synchronize_rcu() in scsi_device_quiesce() into synchronize_sched()
On 03/16/18 14:42, Martin Steigerwald wrote: What is this one about? Fix for the regression I (and others?) reported?¹ [1] [Bug 199077] [Possible REGRESSION, 4.16-rc4] Error updating SMART data during runtime and boot failures with blk_mq_terminate_expired in backtrace https://bugzilla.kernel.org/show_bug.cgi?id=199077 Hello Martin, This patch is a fix for the fix for the bug that you and others had reported. See also "I/O hangs after resuming from suspend-to-ram" (https://marc.info/?l=linux-block&m=150340235201348). This patch fixes an API violation. For those users for which suspend and resume works fine with commit 3a0a529971ec applied it should still work fine with this patch applied since this patch may cause scsi_device_quiesce() to wait longer. Bart.
Re: [PATCH] Change synchronize_rcu() in scsi_device_quiesce() into synchronize_sched()
Hello Bart. What is this one about? Fix for the regression I (and others?) reported?¹ [1] [Bug 199077] [Possible REGRESSION, 4.16-rc4] Error updating SMART data during runtime and boot failures with blk_mq_terminate_expired in backtrace https://bugzilla.kernel.org/show_bug.cgi?id=199077 Thanks, Martin Bart Van Assche - 16.03.18, 18:35: > Since blk_queue_enter() uses rcu_read_lock_sched() scsi_device_quiesce() > must use synchronize_sched(). > > Reported-by: Tejun Heo > Fixes: 3a0a529971ec ("block, scsi: Make SCSI quiesce and resume work > reliably") Signed-off-by: Bart Van Assche > Cc: Hannes Reinecke > Cc: Ming Lei > Cc: Christoph Hellwig > Cc: Johannes Thumshirn > Cc: Tejun Heo > Cc: Oleksandr Natalenko > Cc: Martin Steigerwald > Cc: sta...@vger.kernel.org # v4.15 > --- > drivers/scsi/scsi_lib.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c > index 1d83f29aee74..0b99ee2fbbb5 100644 > --- a/drivers/scsi/scsi_lib.c > +++ b/drivers/scsi/scsi_lib.c > @@ -3014,7 +3014,7 @@ scsi_device_quiesce(struct scsi_device *sdev) >* unfreeze even if the queue was already frozen before this function >* was called. See also https://lwn.net/Articles/573497/. >*/ > - synchronize_rcu(); > + synchronize_sched(); > blk_mq_unfreeze_queue(q); > > mutex_lock(&sdev->state_mutex); -- Martin
[Bug 198861] Regression causes kernel OOPS and hang in SCSI error report
https://bugzilla.kernel.org/show_bug.cgi?id=198861 Dennis Busch (dennis-bu...@gmx.net) changed: What|Removed |Added CC||dennis-bu...@gmx.net --- Comment #7 from Dennis Busch (dennis-bu...@gmx.net) --- Many thanks for the updates. I upgraded to 4.15.10 now and the issue I had before (as reported in the closed duplicate) appears to be fixed with that patch. -- You are receiving this mail because: You are the assignee for the bug.
Re: [PATCH v2 0/5] Allow compile-testing NO_DMA (core)
Thanks Geert, applied to the dma-mapping tree for 4.17.
RE: [PATCH] storvsc: Set up correct queue depth values for IDE devices
> > Subject: [PATCH] storvsc: Set up correct queue depth values for IDE > > devices > > > > From: Long Li > > > > Unlike SCSI and FC, we don't use multiple channels for IDE. So set > > queue depth correctly for IDE. > > > > Also set the correct cmd_per_lun for all devices. > > > > Signed-off-by: Long Li > > --- > > drivers/scsi/storvsc_drv.c | 8 ++-- > > 1 file changed, 6 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c > > index 8c51d628b52e..fba170640e9c 100644 > > --- a/drivers/scsi/storvsc_drv.c > > +++ b/drivers/scsi/storvsc_drv.c > > @@ -1722,15 +1722,19 @@ static int storvsc_probe(struct hv_device > *device, > > max_targets = STORVSC_MAX_TARGETS; > > max_channels = STORVSC_MAX_CHANNELS; > > /* > > -* On Windows8 and above, we support sub-channels for > storage. > > +* On Windows8 and above, we support sub-channels for > storage > > +* on SCSI and FC controllers. > > * The number of sub-channels offerred is based on the > number of > > * VCPUs in the guest. > > */ > > - max_sub_channels = (num_cpus / > storvsc_vcpus_per_sub_channel); > > + if (!dev_is_ide) > > + max_sub_channels = > > + num_cpus / storvsc_vcpus_per_sub_channel; > > This calculation of the # of sub-channels doesn't get the right answer (and it > didn't before this patch either). storvsc_vcpus_per_sub_channel defaults to > 4. > If num_cpus is 8, max_sub_channels will be 2, but it should be 1. The sub- > channel count should not include the main channel since we add 1 to the > sub-channel count below when calculating can_queue. This is a good point. I will fix the code calculating can_queue. > > Furthermore, this is calculation is just a guess, in the sense that we're > replicating the algorithm we think Hyper-V is using to determine the number > of sub-channels to offer. It turns out Hyper-V is changing that algorithm > for > particular devices in an upcoming new Azure VM size. But the only use of > max_sub_channels is in the calculation of can_queue below, so the impact is > minimal. > > > } > > > > scsi_driver.can_queue = (max_outstanding_req_per_channel * > > (max_sub_channels + 1)); > > + scsi_driver.cmd_per_lun = scsi_driver.can_queue; > > can_queue is defined as "int", while cmd_per_lun is defined as "short". > The calculated value of can_queue could easily be over 32,767 with > 15 sub-channels and max_outstanding_req_per_channel being 3036 for the > default 1 Mbyte ring buffer. So the assignment to cmd_per_lun could > produce truncation and even a negative number. This is a good catch. I think I should try calling blk_set_queue_depth() and pass the correct value. > > More broadly, since max_outstanding_req_per_channel is based on the ring > buffer size, these calculations imply that Hyper-V storvsp's queuing capacity > is based on the ring buffer size. I don't think that's the case. From > conversations with the storvsp folks, I think Hyper-V always removes entries > from the guest->host ring buffer and then > lets storvsp queue them separately. So we don't want to be linking > cmd_per_lun (or even can_queue, for that matter) to the ring buffer size. > The current default ring buffer size of 1 Mbyte is probably 10x bigger than > needed, and we want to be able to adjust that without ending up with > can_queue and cmd_per_lun values that are too small. cmd_per_lun needs to reflect the device capacity. What value do you propose? It's not a good idea to leave them constant. Setting those values are also important because we don't' want to return BUSY on writing to ring buffer on full, that will slow down the SCSI stack. Historically we use ring buffer size to calculate device properties (e.g. can_queue for SCSI host). I agree this doesn't need to be based on the exact queuing capacity of ring buffer, maybe we can do 2X of that value (e.g. look at how block uses nr_request in MQ). Setting those values smaller is more conservative and I don't see an ill effect. > > We would probably do better to set can_queue to a constant, and > leave cmd_per_lun at its current value of 2048. The can_queue > value is already capped at 10240 in the blk-mq layer, so maybe that's a > reasonable constant to use. Actually this is not a good idea for smaller ring buffers. You'll see the problem when setting both ring buffer sizes to 10 pages. > > Thoughts? > > > > > host = scsi_host_alloc(&scsi_driver, > >sizeof(struct hv_host_device)); > > -- > > 2.14.1
[PATCH v2] scsi: Avoid that .queuecommand() gets called for a quiesced SCSI device
Several SCSI transport and LLD drivers surround code that does not tolerate concurrent calls of .queuecommand() with scsi_target_block() / scsi_target_unblock(). These last two functions use blk_mq_quiesce_queue() / blk_mq_unquiesce_queue() for scsi-mq request queues to prevent concurrent .queuecommand() calls. However, that is not sufficient to prevent .queuecommand() calls from scsi_send_eh_cmnd(). Hence surround the .queuecommand() call from the SCSI error handler with code that avoids that .queuecommand() gets called in the quiesced state. Notes: - Converting the .queuecommand() call in scsi_send_eh_cmnd() into code that calls blk_get_request() + blk_execute_rq() is not an option since scsi_send_eh_cmnd() must be able to make forward progress even if all requests are allocated. - Converting the .queuecommand() call in scsi_send_eh_cmnd() into a blk_execute_rq() or blk_mq_requeue_request() call is not an option either because that would require to change every individual function in the I/O path. Each function in the I/O path would have to be modified such that it handles requests received from the block layer core and request received from the SCSI EH differently. Since struct scsi_cmnd is not initialized by the block layer for filesystem requests, it is not possible to determine in scsi_queue_rq() whether or not a request has been submitted by the SCSI EH without modifying the block layer. Signed-off-by: Bart Van Assche Cc: Hannes Reinecke Cc: Johannes Thumshirn --- Changes compared to v1: - As requested by James, removed the wait queue again that was added to the SCSI device structure. drivers/scsi/scsi_error.c | 19 +-- 1 file changed, 17 insertions(+), 2 deletions(-) diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c index 946039117bf4..71d7d2b893ab 100644 --- a/drivers/scsi/scsi_error.c +++ b/drivers/scsi/scsi_error.c @@ -1039,7 +1039,7 @@ static int scsi_send_eh_cmnd(struct scsi_cmnd *scmd, unsigned char *cmnd, struct scsi_device *sdev = scmd->device; struct Scsi_Host *shost = sdev->host; DECLARE_COMPLETION_ONSTACK(done); - unsigned long timeleft = timeout; + unsigned long timeleft = timeout, delay; struct scsi_eh_save ses; const unsigned long stall_for = msecs_to_jiffies(100); int rtn; @@ -1050,7 +1050,22 @@ static int scsi_send_eh_cmnd(struct scsi_cmnd *scmd, unsigned char *cmnd, scsi_log_send(scmd); scmd->scsi_done = scsi_eh_done; - rtn = shost->hostt->queuecommand(shost, scmd); + mutex_lock(&sdev->state_mutex); + while (sdev->sdev_state == SDEV_QUIESCE && timeleft > 0) { + mutex_unlock(&sdev->state_mutex); + SCSI_LOG_ERROR_RECOVERY(5, sdev_printk(KERN_DEBUG, sdev, + "%s: state %d <> %d\n", __func__, sdev->sdev_state, + SDEV_QUIESCE)); + delay = min(timeleft, stall_for); + timeleft -= delay; + msleep(jiffies_to_msecs(delay)); + mutex_lock(&sdev->state_mutex); + } + if (sdev->sdev_state != SDEV_QUIESCE) + rtn = shost->hostt->queuecommand(shost, scmd); + else + rtn = SCSI_MLQUEUE_DEVICE_BUSY; + mutex_unlock(&sdev->state_mutex); if (rtn) { if (timeleft > stall_for) { scsi_eh_restore_cmnd(scmd, &ses); -- 2.16.2
[PATCH] Change synchronize_rcu() in scsi_device_quiesce() into synchronize_sched()
Since blk_queue_enter() uses rcu_read_lock_sched() scsi_device_quiesce() must use synchronize_sched(). Reported-by: Tejun Heo Fixes: 3a0a529971ec ("block, scsi: Make SCSI quiesce and resume work reliably") Signed-off-by: Bart Van Assche Cc: Hannes Reinecke Cc: Ming Lei Cc: Christoph Hellwig Cc: Johannes Thumshirn Cc: Tejun Heo Cc: Oleksandr Natalenko Cc: Martin Steigerwald Cc: sta...@vger.kernel.org # v4.15 --- drivers/scsi/scsi_lib.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c index 1d83f29aee74..0b99ee2fbbb5 100644 --- a/drivers/scsi/scsi_lib.c +++ b/drivers/scsi/scsi_lib.c @@ -3014,7 +3014,7 @@ scsi_device_quiesce(struct scsi_device *sdev) * unfreeze even if the queue was already frozen before this function * was called. See also https://lwn.net/Articles/573497/. */ - synchronize_rcu(); + synchronize_sched(); blk_mq_unfreeze_queue(q); mutex_lock(&sdev->state_mutex); -- 2.16.2
[PATCH 4.14 084/109] scsi: dh: add new rdac devices
4.14-stable review patch. If anyone has any objections, please let me know. -- From: Xose Vazquez Perez [ Upstream commit 4b3aec2bbbce1c35f50e7475a9fd78d24b9ea4ea ] Add IBM 3542 and 3552, arrays: FAStT200 and FAStT500. Add full STK OPENstorage family, arrays: 9176, D173, D178, D210, D220, D240 and D280. Add STK BladeCtlr family, arrays: B210, B220, B240 and B280. These changes were done in multipath-tools time ago. Cc: NetApp RDAC team Cc: Hannes Reinecke Cc: Christophe Varoqui Cc: Martin K. Petersen Cc: James E.J. Bottomley Cc: SCSI ML Cc: device-mapper development Signed-off-by: Xose Vazquez Perez Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman --- drivers/scsi/scsi_dh.c |5 - 1 file changed, 4 insertions(+), 1 deletion(-) --- a/drivers/scsi/scsi_dh.c +++ b/drivers/scsi/scsi_dh.c @@ -56,10 +56,13 @@ static const struct scsi_dh_blist scsi_d {"IBM", "1815", "rdac", }, {"IBM", "1818", "rdac", }, {"IBM", "3526", "rdac", }, + {"IBM", "3542", "rdac", }, + {"IBM", "3552", "rdac", }, {"SGI", "TP9", "rdac", }, {"SGI", "IS", "rdac", }, - {"STK", "OPENstorage D280", "rdac", }, + {"STK", "OPENstorage", "rdac", }, {"STK", "FLEXLINE 380", "rdac", }, + {"STK", "BladeCtlr","rdac", }, {"SUN", "CSM", "rdac", }, {"SUN", "LCSM100", "rdac", }, {"SUN", "STK6580_6780", "rdac", },
[PATCH v3 08/18] scsi: hpsa: Eliminate duplicate barriers on weakly-ordered archs
Code includes wmb() followed by writel(). writel() already has a barrier on some architectures like arm64. This ends up CPU observing two barriers back to back before executing the register write. Since code already has an explicit barrier call, changing writel() to writel_relaxed(). Signed-off-by: Sinan Kaya --- drivers/scsi/hpsa.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/scsi/hpsa.h b/drivers/scsi/hpsa.h index 018f980..c7d7e6a 100644 --- a/drivers/scsi/hpsa.h +++ b/drivers/scsi/hpsa.h @@ -599,7 +599,7 @@ static unsigned long SA5_ioaccel_mode1_completed(struct ctlr_info *h, u8 q) * but with current driver design this is easiest. */ wmb(); - writel((q << 24) | rq->current_entry, h->vaddr + + writel_relaxed((q << 24) | rq->current_entry, h->vaddr + IOACCEL_MODE1_CONSUMER_INDEX); atomic_dec(&h->commands_outstanding); } -- 2.7.4
[PATCH 4.15 100/128] scsi: devinfo: apply to HP XP the same flags as Hitachi VSP
4.15-stable review patch. If anyone has any objections, please let me know. -- From: Xose Vazquez Perez [ Upstream commit b369a0471503130cfc74f9f62071db97f48948c3 ] Commit 56f3d383f37b ("scsi: scsi_devinfo: Add TRY_VPD_PAGES to HITACHI OPEN-V blacklist entry") modified some Hitachi entries: HITACHI is always supporting VPD pages, even though it's claiming to support SCSI Revision 3 only. The same should have been done also for HP-rebranded. [mkp: checkpatch and tweaked commit message] Cc: Hannes Reinecke Cc: Takahiro Yasui Cc: Matthias Rudolph Cc: Martin K. Petersen Cc: James E.J. Bottomley Cc: SCSI ML Signed-off-by: Xose Vazquez Perez Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman --- drivers/scsi/scsi_devinfo.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/scsi/scsi_devinfo.c +++ b/drivers/scsi/scsi_devinfo.c @@ -181,7 +181,7 @@ static struct { {"HITACHI", "6586-", "*", BLIST_SPARSELUN | BLIST_LARGELUN}, {"HITACHI", "6588-", "*", BLIST_SPARSELUN | BLIST_LARGELUN}, {"HP", "A6189A", NULL, BLIST_SPARSELUN | BLIST_LARGELUN}, /* HP VA7400 */ - {"HP", "OPEN-", "*", BLIST_REPORTLUN2}, /* HP XP Arrays */ + {"HP", "OPEN-", "*", BLIST_REPORTLUN2 | BLIST_TRY_VPD_PAGES}, /* HP XP Arrays */ {"HP", "NetRAID-4M", NULL, BLIST_FORCELUN}, {"HP", "HSV100", NULL, BLIST_REPORTLUN2 | BLIST_NOSTARTONADD}, {"HP", "C1557A", NULL, BLIST_FORCELUN},
[PATCH 4.15 101/128] scsi: dh: add new rdac devices
4.15-stable review patch. If anyone has any objections, please let me know. -- From: Xose Vazquez Perez [ Upstream commit 4b3aec2bbbce1c35f50e7475a9fd78d24b9ea4ea ] Add IBM 3542 and 3552, arrays: FAStT200 and FAStT500. Add full STK OPENstorage family, arrays: 9176, D173, D178, D210, D220, D240 and D280. Add STK BladeCtlr family, arrays: B210, B220, B240 and B280. These changes were done in multipath-tools time ago. Cc: NetApp RDAC team Cc: Hannes Reinecke Cc: Christophe Varoqui Cc: Martin K. Petersen Cc: James E.J. Bottomley Cc: SCSI ML Cc: device-mapper development Signed-off-by: Xose Vazquez Perez Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman --- drivers/scsi/scsi_dh.c |5 - 1 file changed, 4 insertions(+), 1 deletion(-) --- a/drivers/scsi/scsi_dh.c +++ b/drivers/scsi/scsi_dh.c @@ -56,10 +56,13 @@ static const struct scsi_dh_blist scsi_d {"IBM", "1815", "rdac", }, {"IBM", "1818", "rdac", }, {"IBM", "3526", "rdac", }, + {"IBM", "3542", "rdac", }, + {"IBM", "3552", "rdac", }, {"SGI", "TP9", "rdac", }, {"SGI", "IS", "rdac", }, - {"STK", "OPENstorage D280", "rdac", }, + {"STK", "OPENstorage", "rdac", }, {"STK", "FLEXLINE 380", "rdac", }, + {"STK", "BladeCtlr","rdac", }, {"SUN", "CSM", "rdac", }, {"SUN", "LCSM100", "rdac", }, {"SUN", "STK6580_6780", "rdac", },
RE: [PATCH] storvsc: Set up correct queue depth values for IDE devices
> -Original Message- > From: linux-kernel-ow...@vger.kernel.org > On Behalf > Of Long Li > Sent: Thursday, March 15, 2018 4:52 PM > To: KY Srinivasan ; Haiyang Zhang > ; Stephen > Hemminger ; James E . J . Bottomley > ; > Martin K . Petersen ; > de...@linuxdriverproject.org; linux- > s...@vger.kernel.org; linux-ker...@vger.kernel.org > Cc: Long Li > Subject: [PATCH] storvsc: Set up correct queue depth values for IDE devices > > From: Long Li > > Unlike SCSI and FC, we don't use multiple channels for IDE. So set queue depth > correctly for IDE. > > Also set the correct cmd_per_lun for all devices. > > Signed-off-by: Long Li > --- > drivers/scsi/storvsc_drv.c | 8 ++-- > 1 file changed, 6 insertions(+), 2 deletions(-) > > diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c > index 8c51d628b52e..fba170640e9c 100644 > --- a/drivers/scsi/storvsc_drv.c > +++ b/drivers/scsi/storvsc_drv.c > @@ -1722,15 +1722,19 @@ static int storvsc_probe(struct hv_device *device, > max_targets = STORVSC_MAX_TARGETS; > max_channels = STORVSC_MAX_CHANNELS; > /* > - * On Windows8 and above, we support sub-channels for storage. > + * On Windows8 and above, we support sub-channels for storage > + * on SCSI and FC controllers. >* The number of sub-channels offerred is based on the number of >* VCPUs in the guest. >*/ > - max_sub_channels = (num_cpus / storvsc_vcpus_per_sub_channel); > + if (!dev_is_ide) > + max_sub_channels = > + num_cpus / storvsc_vcpus_per_sub_channel; This calculation of the # of sub-channels doesn't get the right answer (and it didn't before this patch either). storvsc_vcpus_per_sub_channel defaults to 4. If num_cpus is 8, max_sub_channels will be 2, but it should be 1. The sub-channel count should not include the main channel since we add 1 to the sub-channel count below when calculating can_queue. Furthermore, this is calculation is just a guess, in the sense that we're replicating the algorithm we think Hyper-V is using to determine the number of sub-channels to offer. It turns out Hyper-V is changing that algorithm for particular devices in an upcoming new Azure VM size. But the only use of max_sub_channels is in the calculation of can_queue below, so the impact is minimal. > } > > scsi_driver.can_queue = (max_outstanding_req_per_channel * >(max_sub_channels + 1)); > + scsi_driver.cmd_per_lun = scsi_driver.can_queue; can_queue is defined as "int", while cmd_per_lun is defined as "short". The calculated value of can_queue could easily be over 32,767 with 15 sub-channels and max_outstanding_req_per_channel being 3036 for the default 1 Mbyte ring buffer. So the assignment to cmd_per_lun could produce truncation and even a negative number. More broadly, since max_outstanding_req_per_channel is based on the ring buffer size, these calculations imply that Hyper-V storvsp's queuing capacity is based on the ring buffer size. I don't think that's the case. From conversations with the storvsp folks, I think Hyper-V always removes entries from the guest->host ring buffer and then lets storvsp queue them separately. So we don't want to be linking cmd_per_lun (or even can_queue, for that matter) to the ring buffer size. The current default ring buffer size of 1 Mbyte is probably 10x bigger than needed, and we want to be able to adjust that without ending up with can_queue and cmd_per_lun values that are too small. We would probably do better to set can_queue to a constant, and leave cmd_per_lun at its current value of 2048. The can_queue value is already capped at 10240 in the blk-mq layer, so maybe that's a reasonable constant to use. Thoughts? > > host = scsi_host_alloc(&scsi_driver, > sizeof(struct hv_host_device)); > -- > 2.14.1
[PATCH 4.14 083/109] scsi: devinfo: apply to HP XP the same flags as Hitachi VSP
4.14-stable review patch. If anyone has any objections, please let me know. -- From: Xose Vazquez Perez [ Upstream commit b369a0471503130cfc74f9f62071db97f48948c3 ] Commit 56f3d383f37b ("scsi: scsi_devinfo: Add TRY_VPD_PAGES to HITACHI OPEN-V blacklist entry") modified some Hitachi entries: HITACHI is always supporting VPD pages, even though it's claiming to support SCSI Revision 3 only. The same should have been done also for HP-rebranded. [mkp: checkpatch and tweaked commit message] Cc: Hannes Reinecke Cc: Takahiro Yasui Cc: Matthias Rudolph Cc: Martin K. Petersen Cc: James E.J. Bottomley Cc: SCSI ML Signed-off-by: Xose Vazquez Perez Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman --- drivers/scsi/scsi_devinfo.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/scsi/scsi_devinfo.c +++ b/drivers/scsi/scsi_devinfo.c @@ -181,7 +181,7 @@ static struct { {"HITACHI", "6586-", "*", BLIST_SPARSELUN | BLIST_LARGELUN}, {"HITACHI", "6588-", "*", BLIST_SPARSELUN | BLIST_LARGELUN}, {"HP", "A6189A", NULL, BLIST_SPARSELUN | BLIST_LARGELUN}, /* HP VA7400 */ - {"HP", "OPEN-", "*", BLIST_REPORTLUN2}, /* HP XP Arrays */ + {"HP", "OPEN-", "*", BLIST_REPORTLUN2 | BLIST_TRY_VPD_PAGES}, /* HP XP Arrays */ {"HP", "NetRAID-4M", NULL, BLIST_FORCELUN}, {"HP", "HSV100", NULL, BLIST_REPORTLUN2 | BLIST_NOSTARTONADD}, {"HP", "C1557A", NULL, BLIST_FORCELUN},
[PATCH v2 04/21] fbdev: Remove depends on HAS_DMA in case of platform dependency
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
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 RFC] scsi: devinfo: remove dasd devices from the scsi subsystem
Only present through ccw bus. Cc: Matthias Rudolph Cc: Takahiro Yasui Cc: Anthony Cheung Cc: Mike Christie Cc: Martin K. Petersen Cc: James E.J. Bottomley Cc: s390 ML Cc: SCSI ML Cc: device-mapper development Signed-off-by: Xose Vazquez Perez --- drivers/scsi/scsi_devinfo.c | 10 -- 1 file changed, 10 deletions(-) diff --git a/drivers/scsi/scsi_devinfo.c b/drivers/scsi/scsi_devinfo.c index b119b5bfb4d3..31985dd3f4b6 100644 --- a/drivers/scsi/scsi_devinfo.c +++ b/drivers/scsi/scsi_devinfo.c @@ -175,11 +175,6 @@ static struct { {"HITACHI", "DISK-SUBSYSTEM", "*", BLIST_REPORTLUN2}, {"HITACHI", "HUS1530", "*", BLIST_NO_DIF}, {"HITACHI", "OPEN-", "*", BLIST_REPORTLUN2 | BLIST_TRY_VPD_PAGES}, - {"HITACHI", "OP-C-", "*", BLIST_SPARSELUN | BLIST_LARGELUN}, - {"HITACHI", "3380-", "*", BLIST_SPARSELUN | BLIST_LARGELUN}, - {"HITACHI", "3390-", "*", BLIST_SPARSELUN | BLIST_LARGELUN}, - {"HITACHI", "6586-", "*", BLIST_SPARSELUN | BLIST_LARGELUN}, - {"HITACHI", "6588-", "*", BLIST_SPARSELUN | BLIST_LARGELUN}, {"HP", "A6189A", NULL, BLIST_SPARSELUN | BLIST_LARGELUN}, /* HP VA7400 */ {"HP", "OPEN-", "*", BLIST_REPORTLUN2 | BLIST_TRY_VPD_PAGES}, /* HP XP Arrays */ {"HP", "NetRAID-4M", NULL, BLIST_FORCELUN}, @@ -187,11 +182,6 @@ static struct { {"HP", "C1557A", NULL, BLIST_FORCELUN}, {"HP", "C3323-300", "4269", BLIST_NOTQ}, {"HP", "C5713A", NULL, BLIST_NOREPORTLUN}, - {"HP", "OP-C-", "*", BLIST_SPARSELUN | BLIST_LARGELUN}, - {"HP", "3380-", "*", BLIST_SPARSELUN | BLIST_LARGELUN}, - {"HP", "3390-", "*", BLIST_SPARSELUN | BLIST_LARGELUN}, - {"HP", "6586-", "*", BLIST_SPARSELUN | BLIST_LARGELUN}, - {"HP", "6588-", "*", BLIST_SPARSELUN | BLIST_LARGELUN}, {"IBM", "AuSaV1S2", NULL, BLIST_FORCELUN}, {"IBM", "ProFibre 4000R", "*", BLIST_SPARSELUN | BLIST_LARGELUN}, {"IBM", "2105", NULL, BLIST_RETRY_HWERROR}, -- 2.14.3
[PATCH v2 10/21] lightnvm: Remove depends on HAS_DMA in case of platform dependency
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)
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/host/Kconfig| 10
[PATCH v2 03/21] crypto: Remove depends on HAS_DMA in case of platform dependency
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
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
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
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 "scsi: devinfo: apply to HP XP the same flags as Hitachi VSP" has been added to the 4.14-stable tree
This is a note to let you know that I've just added the patch titled scsi: devinfo: apply to HP XP the same flags as Hitachi VSP to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is: scsi-devinfo-apply-to-hp-xp-the-same-flags-as-hitachi-vsp.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let know about it. >From foo@baz Fri Mar 16 15:43:17 CET 2018 From: Xose Vazquez Perez Date: Fri, 17 Nov 2017 21:31:36 +0100 Subject: scsi: devinfo: apply to HP XP the same flags as Hitachi VSP From: Xose Vazquez Perez [ Upstream commit b369a0471503130cfc74f9f62071db97f48948c3 ] Commit 56f3d383f37b ("scsi: scsi_devinfo: Add TRY_VPD_PAGES to HITACHI OPEN-V blacklist entry") modified some Hitachi entries: HITACHI is always supporting VPD pages, even though it's claiming to support SCSI Revision 3 only. The same should have been done also for HP-rebranded. [mkp: checkpatch and tweaked commit message] Cc: Hannes Reinecke Cc: Takahiro Yasui Cc: Matthias Rudolph Cc: Martin K. Petersen Cc: James E.J. Bottomley Cc: SCSI ML Signed-off-by: Xose Vazquez Perez Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman --- drivers/scsi/scsi_devinfo.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/scsi/scsi_devinfo.c +++ b/drivers/scsi/scsi_devinfo.c @@ -181,7 +181,7 @@ static struct { {"HITACHI", "6586-", "*", BLIST_SPARSELUN | BLIST_LARGELUN}, {"HITACHI", "6588-", "*", BLIST_SPARSELUN | BLIST_LARGELUN}, {"HP", "A6189A", NULL, BLIST_SPARSELUN | BLIST_LARGELUN}, /* HP VA7400 */ - {"HP", "OPEN-", "*", BLIST_REPORTLUN2}, /* HP XP Arrays */ + {"HP", "OPEN-", "*", BLIST_REPORTLUN2 | BLIST_TRY_VPD_PAGES}, /* HP XP Arrays */ {"HP", "NetRAID-4M", NULL, BLIST_FORCELUN}, {"HP", "HSV100", NULL, BLIST_REPORTLUN2 | BLIST_NOSTARTONADD}, {"HP", "C1557A", NULL, BLIST_FORCELUN}, Patches currently in stable-queue which might be from xose.vazq...@gmail.com are queue-4.14/scsi-devinfo-apply-to-hp-xp-the-same-flags-as-hitachi-vsp.patch queue-4.14/scsi-dh-add-new-rdac-devices.patch
Patch "scsi: dh: add new rdac devices" has been added to the 4.14-stable tree
This is a note to let you know that I've just added the patch titled scsi: dh: add new rdac devices to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is: scsi-dh-add-new-rdac-devices.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let know about it. >From foo@baz Fri Mar 16 15:43:17 CET 2018 From: Xose Vazquez Perez Date: Fri, 17 Nov 2017 22:05:13 +0100 Subject: scsi: dh: add new rdac devices From: Xose Vazquez Perez [ Upstream commit 4b3aec2bbbce1c35f50e7475a9fd78d24b9ea4ea ] Add IBM 3542 and 3552, arrays: FAStT200 and FAStT500. Add full STK OPENstorage family, arrays: 9176, D173, D178, D210, D220, D240 and D280. Add STK BladeCtlr family, arrays: B210, B220, B240 and B280. These changes were done in multipath-tools time ago. Cc: NetApp RDAC team Cc: Hannes Reinecke Cc: Christophe Varoqui Cc: Martin K. Petersen Cc: James E.J. Bottomley Cc: SCSI ML Cc: device-mapper development Signed-off-by: Xose Vazquez Perez Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman --- drivers/scsi/scsi_dh.c |5 - 1 file changed, 4 insertions(+), 1 deletion(-) --- a/drivers/scsi/scsi_dh.c +++ b/drivers/scsi/scsi_dh.c @@ -56,10 +56,13 @@ static const struct scsi_dh_blist scsi_d {"IBM", "1815", "rdac", }, {"IBM", "1818", "rdac", }, {"IBM", "3526", "rdac", }, + {"IBM", "3542", "rdac", }, + {"IBM", "3552", "rdac", }, {"SGI", "TP9", "rdac", }, {"SGI", "IS", "rdac", }, - {"STK", "OPENstorage D280", "rdac", }, + {"STK", "OPENstorage", "rdac", }, {"STK", "FLEXLINE 380", "rdac", }, + {"STK", "BladeCtlr","rdac", }, {"SUN", "CSM", "rdac", }, {"SUN", "LCSM100", "rdac", }, {"SUN", "STK6580_6780", "rdac", }, Patches currently in stable-queue which might be from xose.vazq...@gmail.com are queue-4.14/scsi-devinfo-apply-to-hp-xp-the-same-flags-as-hitachi-vsp.patch queue-4.14/scsi-dh-add-new-rdac-devices.patch
Re: [PATCH v2 17/21] scsi: hisi_sas: Remove depends on HAS_DMA in case of platform dependency
On 16/03/2018 13:51, Geert Uytterhoeven wrote: 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: John Garry
Re: [PATCH v2 3/5] usb: gadget: Add NO_DMA dummies for DMA mapping API
On Fri, Mar 16, 2018 at 02:25:42PM +0100, Geert Uytterhoeven wrote: > 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 Acked-by: Greg Kroah-Hartman
Re: [PATCH 3/5] scsi_io_completion: add _action helper function
Apart from the commit message, Reviewed-by: Johannes Thumshirn -- Johannes Thumshirn Storage jthumsh...@suse.de+49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
Re: [PATCH 2/5] scsi_io_completion: add _nz_result helper
On Tue, Mar 06, 2018 at 10:21:31PM -0500, Douglas Gilbert wrote: > ChangeLog: > - break out several interwined paths when cmd->result is non zero > and place them in scsi_io_completion_nz_result helper function > - after a review comment that proposed reducing the helper's > former 2 return values to a single return value, use > BLK_STS_NOTSUPP as a marker that the helper did not change > the blk_status. This is cleaned up just after its invocation > in scsi_io_completion. Comment about changelog applies here as well. [...] > + if (sense_valid && (sshdr.sense_key == RECOVERED_ERROR)) { > + /* > + * if ATA PASS-THROUGH INFORMATION AVAILABLE skip > + * print since caller wants ATA registers. Only occurs > + * on SCSI ATA PASS_THROUGH commands when CK_COND=1 > + */ > + if ((sshdr.asc == 0x0) && (sshdr.ascq == 0x1d)) > + ; > + else if (!(req->rq_flags & RQF_QUIET)) > + scsi_print_sense(cmd); > + /* for passthrough, blk_stat may be set */ > + blk_stat = BLK_STS_OK; I see this is just copied over but it isn't really intuitive to the reader. OTOH if (!(sshdr.asc == 0x0 && sshdr.ascq == 0x1d) && !(req->rq_flags & RQF_QUIET)) scsi_print_sense(cmd); isn't either... Maybe someone else has an idea -- Johannes Thumshirn Storage jthumsh...@suse.de+49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
[PATCH v2 09/21] iommu: Remove depends on HAS_DMA in case of platform dependency
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
Re: [PATCH] scsi: ufs: sysfs: reworking of the rpm_lvl and spm_lvl entries
On 01/03/18 12:48, Stanislav Nijnikov wrote: > Read from these files will return the integed value of the chosen power > management level now. Separate entries were added to show the target > UFS device and UIC link states. The description of the possible power > managements levels was added to the ABI file. The on-write behaviour of > these entries wasn't changed. > > Signed-off-by: Stanislav Nijnikov Acked-by: Adrian Hunter > --- > Documentation/ABI/testing/sysfs-driver-ufs | 67 ++ > drivers/scsi/ufs/ufs-sysfs.c | 92 > +++--- > 2 files changed, 114 insertions(+), 45 deletions(-) > > diff --git a/Documentation/ABI/testing/sysfs-driver-ufs > b/Documentation/ABI/testing/sysfs-driver-ufs > index 07f1c2f..83735f7 100644 > --- a/Documentation/ABI/testing/sysfs-driver-ufs > +++ b/Documentation/ABI/testing/sysfs-driver-ufs > @@ -802,3 +802,70 @@ Description: This file shows the The amount of > physical memory needed > the particular logical unit. The full information about > the attribute could be found at UFS specifications 2.1. > The file is read only. > + > + > +What:/sys/bus/platform/drivers/ufshcd/*/rpm_lvl > +Date:September 2014 > +Contact: Subhash Jadavani > +Description: This entry could be used to set or show the UFS device > + runtime power management level. The current driver > + implementation supports 6 levels with next target states: > + 0 - an UFS device will stay active, an UIC link will > + stay active > + 1 - an UFS device will stay active, an UIC link will > + hibernate > + 2 - an UFS device will moved to sleep, an UIC link will > + stay active > + 3 - an UFS device will moved to sleep, an UIC link will > + hibernate > + 4 - an UFS device will be powered off, an UIC link will > + hibernate > + 5 - an UFS device will be powered off, an UIC link will > + be powered off > + > +What:/sys/bus/platform/drivers/ufshcd/*/rpm_target_dev_state > +Date:February 2018 > +Contact: Subhash Jadavani > +Description: This entry shows the target power mode of an UFS device > + for the chosen runtime power management level. > + The file is read only. > + > +What:/sys/bus/platform/drivers/ufshcd/*/rpm_target_link_state > +Date:February 2018 > +Contact: Subhash Jadavani > +Description: This entry shows the target state of an UFS UIC link > + for the chosen runtime power management level. > + The file is read only. > + > +What:/sys/bus/platform/drivers/ufshcd/*/spm_lvl > +Date:September 2014 > +Contact: Subhash Jadavani > +Description: This entry could be used to set or show the UFS device > + system power management level. The current driver > + implementation supports 6 levels with next target states: > + 0 - an UFS device will stay active, an UIC link will > + stay active > + 1 - an UFS device will stay active, an UIC link will > + hibernate > + 2 - an UFS device will moved to sleep, an UIC link will > + stay active > + 3 - an UFS device will moved to sleep, an UIC link will > + hibernate > + 4 - an UFS device will be powered off, an UIC link will > + hibernate > + 5 - an UFS device will be powered off, an UIC link will > + be powered off > + > +What:/sys/bus/platform/drivers/ufshcd/*/spm_target_dev_state > +Date:February 2018 > +Contact: Subhash Jadavani > +Description: This entry shows the target power mode of an UFS device > + for the chosen system power management level. > + The file is read only. > + > +What:/sys/bus/platform/drivers/ufshcd/*/spm_target_link_state > +Date:February 2018 > +Contact: Subhash Jadavani > +Description: This entry shows the target state of an UFS UIC link > + for the chosen system power management level. > + The file is read only. > diff --git a/drivers/scsi/ufs/ufs-sysfs.c b/drivers/scsi/ufs/ufs-sysfs.c > index cd7174d..4ff9e0b 100644 > --- a/drivers/scsi/ufs/ufs-sysfs.c > +++ b/drivers/scsi/ufs/ufs-sysfs.c > @@ -57,29 +57,8 @@ static ssize_t rpm_lvl_show(struct device *dev, > struct device_attribute *attr, char *buf) > { > struct ufs_hba *hba = dev_get_drvdata(dev); > - int curr_len; > - u8 lvl; > - > - curr_len = snprintf(buf, PAGE_SIZE, > - "\nCurrent Runtime PM level [%d] => dev_state [%s] > link_state [%s]\n", > - hba->rpm_lvl, > -
Patch "scsi: dh: add new rdac devices" has been added to the 4.15-stable tree
This is a note to let you know that I've just added the patch titled scsi: dh: add new rdac devices to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is: scsi-dh-add-new-rdac-devices.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let know about it. >From foo@baz Fri Mar 16 15:11:08 CET 2018 From: Xose Vazquez Perez Date: Fri, 17 Nov 2017 22:05:13 +0100 Subject: scsi: dh: add new rdac devices From: Xose Vazquez Perez [ Upstream commit 4b3aec2bbbce1c35f50e7475a9fd78d24b9ea4ea ] Add IBM 3542 and 3552, arrays: FAStT200 and FAStT500. Add full STK OPENstorage family, arrays: 9176, D173, D178, D210, D220, D240 and D280. Add STK BladeCtlr family, arrays: B210, B220, B240 and B280. These changes were done in multipath-tools time ago. Cc: NetApp RDAC team Cc: Hannes Reinecke Cc: Christophe Varoqui Cc: Martin K. Petersen Cc: James E.J. Bottomley Cc: SCSI ML Cc: device-mapper development Signed-off-by: Xose Vazquez Perez Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman --- drivers/scsi/scsi_dh.c |5 - 1 file changed, 4 insertions(+), 1 deletion(-) --- a/drivers/scsi/scsi_dh.c +++ b/drivers/scsi/scsi_dh.c @@ -56,10 +56,13 @@ static const struct scsi_dh_blist scsi_d {"IBM", "1815", "rdac", }, {"IBM", "1818", "rdac", }, {"IBM", "3526", "rdac", }, + {"IBM", "3542", "rdac", }, + {"IBM", "3552", "rdac", }, {"SGI", "TP9", "rdac", }, {"SGI", "IS", "rdac", }, - {"STK", "OPENstorage D280", "rdac", }, + {"STK", "OPENstorage", "rdac", }, {"STK", "FLEXLINE 380", "rdac", }, + {"STK", "BladeCtlr","rdac", }, {"SUN", "CSM", "rdac", }, {"SUN", "LCSM100", "rdac", }, {"SUN", "STK6580_6780", "rdac", }, Patches currently in stable-queue which might be from xose.vazq...@gmail.com are queue-4.15/scsi-devinfo-apply-to-hp-xp-the-same-flags-as-hitachi-vsp.patch queue-4.15/scsi-dh-add-new-rdac-devices.patch
Patch "scsi: devinfo: apply to HP XP the same flags as Hitachi VSP" has been added to the 4.15-stable tree
This is a note to let you know that I've just added the patch titled scsi: devinfo: apply to HP XP the same flags as Hitachi VSP to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is: scsi-devinfo-apply-to-hp-xp-the-same-flags-as-hitachi-vsp.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let know about it. >From foo@baz Fri Mar 16 15:11:08 CET 2018 From: Xose Vazquez Perez Date: Fri, 17 Nov 2017 21:31:36 +0100 Subject: scsi: devinfo: apply to HP XP the same flags as Hitachi VSP From: Xose Vazquez Perez [ Upstream commit b369a0471503130cfc74f9f62071db97f48948c3 ] Commit 56f3d383f37b ("scsi: scsi_devinfo: Add TRY_VPD_PAGES to HITACHI OPEN-V blacklist entry") modified some Hitachi entries: HITACHI is always supporting VPD pages, even though it's claiming to support SCSI Revision 3 only. The same should have been done also for HP-rebranded. [mkp: checkpatch and tweaked commit message] Cc: Hannes Reinecke Cc: Takahiro Yasui Cc: Matthias Rudolph Cc: Martin K. Petersen Cc: James E.J. Bottomley Cc: SCSI ML Signed-off-by: Xose Vazquez Perez Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman --- drivers/scsi/scsi_devinfo.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/scsi/scsi_devinfo.c +++ b/drivers/scsi/scsi_devinfo.c @@ -181,7 +181,7 @@ static struct { {"HITACHI", "6586-", "*", BLIST_SPARSELUN | BLIST_LARGELUN}, {"HITACHI", "6588-", "*", BLIST_SPARSELUN | BLIST_LARGELUN}, {"HP", "A6189A", NULL, BLIST_SPARSELUN | BLIST_LARGELUN}, /* HP VA7400 */ - {"HP", "OPEN-", "*", BLIST_REPORTLUN2}, /* HP XP Arrays */ + {"HP", "OPEN-", "*", BLIST_REPORTLUN2 | BLIST_TRY_VPD_PAGES}, /* HP XP Arrays */ {"HP", "NetRAID-4M", NULL, BLIST_FORCELUN}, {"HP", "HSV100", NULL, BLIST_REPORTLUN2 | BLIST_NOSTARTONADD}, {"HP", "C1557A", NULL, BLIST_FORCELUN}, Patches currently in stable-queue which might be from xose.vazq...@gmail.com are queue-4.15/scsi-devinfo-apply-to-hp-xp-the-same-flags-as-hitachi-vsp.patch queue-4.15/scsi-dh-add-new-rdac-devices.patch
Re: [PATCH 1/5] scsi_io_completion: rename variables and comments
On Tue, Mar 06, 2018 at 10:21:30PM -0500, Douglas Gilbert wrote: > ChangeLog: > - add comments to scsi_end_request() noting what its bool return > value means > - change some variable names in scsi_io_completion() > - reword some inline comments; move some comments that seemed to be > separated from the code they referred to For the commit message, please don't write your changelog as a list of bullet points, but as flowing text. The above changelog as well suggest you did three differnet things, which means three different patches. For the code itself, Reviewed-by: Johannes Thumshirn -- Johannes Thumshirn Storage jthumsh...@suse.de+49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
[PATCH v2 18/21] serial: Remove depends on HAS_DMA in case of platform dependency
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
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
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
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
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
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 VIDEO_DEV && PCI && VIDEO_V4L2 - depends on HAS_DMA select VIDEOBUF2_DMA_CONTIG ---help---
[PATCH v2 19/21] spi: Remove depends on HAS_DMA in case of platform dependency
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
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
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
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
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" - depends on HAS_DMA depends on ARCH_BCM_IPROC || COMPILE_TEST depends on OF select BGMAC diff --git a/drivers/net/ethernet/calxeda/Kconfig b/drivers/net/ethernet/calxeda/Kconfig index 07d
[PATCH v2 11/21] mailbox: Remove depends on HAS_DMA in case of platform dependency
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
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
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)
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
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
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
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
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 10/12] scsi: remove the mvme147 driver
On Wed, 14 Mar 2018 11:58:25 -0400 "Martin K. Petersen" wrote: > 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 own a MVME147, so if needed I could get it out of the closet and fix the driver for it. Thomas. -- SUSE Linux GmbH GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg)
CONTACT DHL OFFICE IMMEDIATELY FOR DELIVERY OF YOUR ATM MASTERCARD
Attention; Beneficiary, This is to official inform you that we have been having meetings for the past three (3) weeks which ended two days ago with MR. JIM YONG KIM the Former world bank president and other seven continent presidents on the congress we treated on solution to scam victim problems. Note: we have decided to contact you following the reports we received from anti-fraud international monitoring group your name/email has been submitted to us therefore the united nations have agreed to compensate you with the sum of (USD$1.5 Million) this compensation is also including international business that failed you in past due to government problems etc. We have arranged your payment through our ATM MasterCard and deposited it in DHL Office to deliver it to you which is the latest instruction from the Former World Bank president MR. JIM YONG KIM, For your information’s, the delivery charges already paid by U.N treasury, the only money you will send to DHL office Benin Republic is $225 dollars for security keeping fee, U.N coordinator already paid for others charges fees for delivery except the security keeping fee, the director of DHL refused to collect the security keeping fee from U.N treasury because Direct of DHL office said they don’t know exactly time you will contact them to reconfirm your details to avoid counting demurrage. Therefore be advice to contact DHL Office agent Benin. Rev:Tony harries who is in position to post your ATM MasterCard, contact DHL Office immediately with the bellow email & phone number as listed below. Contact name: Rev:Tony HARRIES Email:(post.dhlbenin.serv...@outlook.com ) Tell: +229-98787436 Make sure you reconfirmed DHL Office your details ASAP as stated below to avoid wrong delivery. Your full name.. Home address:. Your country... Your city.. Telephone.. Occupation:... Age:…….. Let us know as soon as possible you receive your ATM MasterCard for proper verifications. Regards, MR Paul Ogie. DEPUTY SECRETARY-GENERAL (U.N) Benin Republic.
Re: [PATCH v3] m68k/amiga - Amiga Zorro NCR53C9x boards: new zorro_esp.c
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
CONTACT DHL OFFICE IMMEDIATELY FOR DELIVERY OF YOUR ATM MASTERCARD
Attention; Beneficiary, This is to official inform you that we have been having meetings for the past three (3) weeks which ended two days ago with MR. JIM YONG KIM the Former world bank president and other seven continent presidents on the congress we treated on solution to scam victim problems. Note: we have decided to contact you following the reports we received from anti-fraud international monitoring group your name/email has been submitted to us therefore the united nations have agreed to compensate you with the sum of (USD$1.5 Million) this compensation is also including international business that failed you in past due to government problems etc. We have arranged your payment through our ATM MasterCard and deposited it in DHL Office to deliver it to you which is the latest instruction from the Former World Bank president MR. JIM YONG KIM, For your information’s, the delivery charges already paid by U.N treasury, the only money you will send to DHL office Benin Republic is $225 dollars for security keeping fee, U.N coordinator already paid for others charges fees for delivery except the security keeping fee, the director of DHL refused to collect the security keeping fee from U.N treasury because Direct of DHL office said they don’t know exactly time you will contact them to reconfirm your details to avoid counting demurrage. Therefore be advice to contact DHL Office agent Benin. Rev:Tony harries who is in position to post your ATM MasterCard, contact DHL Office immediately with the bellow email & phone number as listed below. Contact name: Rev:Tony HARRIES Email:(post.dhlbenin.serv...@outlook.com ) Tell: +229-98787436 Make sure you reconfirmed DHL Office your details ASAP as stated below to avoid wrong delivery. Your full name.. Home address:. Your country... Your city.. Telephone.. Occupation:... Age:…….. Let us know as soon as possible you receive your ATM MasterCard for proper verifications. Regards, MR Paul Ogie. DEPUTY SECRETARY-GENERAL (U.N) Benin Republic.
Re: [PATCH] [RFC] target/file: add support of direct and async I/O
> DIF (PI) emulation doesn't work when a target uses async I/O, because > DIF metadata is saved in a separate file, and it is another non-trivial > task how to synchronize writing in two files, so that a following read > operation always returns a consisten metadata for a specified block. There literally is no way to do that, even without aio. The file DIF implementation should probably regarded as an early bringup / prototype tool, not something really usable. > +static void cmd_rw_aio_do_completion(struct target_core_file_cmd *cmd) > +{ > + if (!atomic_dec_and_test(&cmd->ref)) > + return; There is no need for reference counting. If the read_iter/write iter method returns -EIOCBQUEUED the completion callback needs to complete the I/O and free the structure, else the method caller. > + if (!(fd_dev->fbd_flags & FDBD_HAS_BUFFERED_IO_WCE)) > + aio_cmd->iocb.ki_flags |= IOCB_DIRECT; aio without IOCB_DIRECT doesn't make any sense. But the WCE flag really has nothing to do with buffers vs direct I/O anyway. > + if (is_write) > + ret = call_write_iter(file, &aio_cmd->iocb, &iter); > + else > + ret = call_read_iter(file, &aio_cmd->iocb, &iter); Please call the methods directly instead of through the wrappers. > + > static int fd_do_rw(struct se_cmd *cmd, struct file *fd, > u32 block_size, struct scatterlist *sgl, > u32 sgl_nents, u32 data_length, int is_write) > @@ -536,6 +626,7 @@ fd_execute_rw(struct se_cmd *cmd, struct scatterlist > *sgl, u32 sgl_nents, > struct file *pfile = fd_dev->fd_prot_file; > sense_reason_t rc; > int ret = 0; > + int aio = fd_dev->fbd_flags & FDBD_HAS_ASYNC_IO; > /* >* We are currently limited by the number of iovecs (2048) per >* single vfs_[writev,readv] call. > @@ -550,7 +641,11 @@ fd_execute_rw(struct se_cmd *cmd, struct scatterlist > *sgl, u32 sgl_nents, >* Call vectorized fileio functions to map struct scatterlist >* physical memory addresses to struct iovec virtual memory. >*/ > - if (data_direction == DMA_FROM_DEVICE) { > + if (aio) { fd_execute_rw shares basically no code with the aio case. I'd rather have a very high level wrapper here: static sense_reason_t fd_execute_rw(struct se_cmd *cmd, struct scatterlist *sgl, u32 sgl_nents, enum dma_data_direction data_direction) { if (FD_DEV(cmd->se_dev)->fbd_flags & FDBD_HAS_ASYNC_IO) return fd_execute_rw_aio(cmd, sgl, sgl_nents, dma_direction); return fd_execute_rw_buffered(cmd, sgl, sgl_nents, dma_direction); } and keep the code separate.
Re: [PATCH v3] m68k/amiga - Amiga Zorro NCR53C9x boards: new zorro_esp.c
Hi Finn, Geert, 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? Placing the two macros in a suitable header in arch/m68k/include/asm/ so Mac and Amiga can share the same code without duplicating it in two files would be another option (that forces use of addr and fifo as parameters), but let's not overengineer things. I don't expect any other driver would need to share this code, or the PDMA macros also in the Mac driver... Other than that, I've implemented and tested all the suggested changes and could post v4 of this patch now. Cheers, Michael Am 16.03.18 um 00:17 schrieb Finn Thain: > On Wed, 14 Mar 2018, Michael Schmitz wrote: > >>> Please pass "addr" and "fifo" as macro parameters, too, so it's easier >>> for the reviewer to notice they are used. >> Yes, I can do that (meaning Finn would need to make the same change to >> keep our versions in sync). > Personally, I wouldn't want to change it. This wasn't an oversight. Maybe > if you (Geert) take a look at MAC_ESP_PDMA_LOOP, etc. this style might > make more sense. > > These are not macros in a header file that might get used in any random > scope. There is exactly one scope in which the macro appears, and the > variables that appear in the macro are simply the variables from that > scope. > > If you apply the rule, "the macro's parameters should exhaustively list > all the macro's symbols", then (in this case) you'd violate the rule > "Don't Repeat Yourself". And if you'd adhere to the latter rule then you'd > violate the former. So I chose the more readable option. > > The preprocessor allows us to pretend we are doing symbolic code > transformation, but that's not needed here. This was meant to be a textual > device. >