Re: [PATCH v1] scsi: isci: Don't use PCI helper functions
On 11/7/20 11:04 AM, Vaibhav Gupta wrote: > PCI helper functions such as pci_enable/disable_device(), > pci_save/restore_state(), pci_set_power_state(), etc. were used by the > legacy framework to perform standard operations related to PCI PM. > > This driver is using the generic framework and thus calls for those > functions should be dropped as those tasks are now performed by the PCI > core. > > Signed-off-by: Vaibhav Gupta > --- Acked-by: Artur Paszkiewicz
Re: [PATCH] drivers/md.c: Make bio_alloc_mddev return bio_alloc_bioset
On 12/22/18 11:08 AM, Marcos Paulo de Souza wrote: > bio_alloc_bioset return a bio pointer or NULL, so we can avoid storing > the returned data into a new variable. > > Signed-off-by: Marcos Paulo de Souza Acked-by: Artur Paszkiewicz
Re: [PATCH 19/41] scsi: isci: remote_node_context: mark expected switch fall-throughs
On 11/28/18 5:30 AM, Gustavo A. R. Silva wrote: > In preparation to enabling -Wimplicit-fallthrough, mark switch cases > where we are expecting to fall through. > > Notice that, in this particular case, a dash is added as a token in > order to separate the "Fall through" annotations from the rest of > the comment on the same line, which is what GCC is expecting to find. > > Signed-off-by: Gustavo A. R. Silva Acked-by: Artur Paszkiewicz
Re: [PATCH 17/41] scsi: isci: phy: Mark expected switch fall-through
On 11/28/18 5:29 AM, Gustavo A. R. Silva wrote:
> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
> where we are expecting to fall through.
>
> Addresses-Coverity-ID: 703127 ("Missing break in switch")
> Signed-off-by: Gustavo A. R. Silva
Acked-by: Artur Paszkiewicz
Re: [PATCH 18/41] scsi: isci: remote_device: Mark expected switch fall-throughs
On 11/28/18 5:30 AM, Gustavo A. R. Silva wrote: > In preparation to enabling -Wimplicit-fallthrough, mark switch cases > where we are expecting to fall through. > > Notice that, in this particular case, a dash is added as a token in > order to separate the "fall through" annotations from the rest of > the comment on the same line, which is what GCC is expecting to find. > > Signed-off-by: Gustavo A. R. Silva Acked-by: Artur Paszkiewicz
Re: [PATCH 20/41] scsi: isci: request: mark expected switch fall-through
On 11/28/18 5:30 AM, Gustavo A. R. Silva wrote: > In preparation to enabling -Wimplicit-fallthrough, mark switch cases > where we are expecting to fall through. > > Notice that, in this particular case, a dash is added as a token in > order to separate the "Fall through" annotation from the rest of the > comment on the same line, which is what GCC is expecting to find. > > Signed-off-by: Gustavo A. R. Silva Acked-by: Artur Paszkiewicz
Re: [PATCH] scsi: isci: Convert timers to use timer_setup()
On 10/05/2017 02:48 AM, Kees Cook wrote: > In preparation for unconditionally passing the struct timer_list pointer to > all timer callbacks, switch to using the new timer_setup() and from_timer() > to pass the timer pointer explicitly. > > Cc: Intel SCU Linux support > Cc: Artur Paszkiewicz > Cc: "James E.J. Bottomley" > Cc: "Martin K. Petersen" > Cc: linux-s...@vger.kernel.org > Cc: Thomas Gleixner > Signed-off-by: Kees Cook Reviewed-by: Artur Paszkiewicz
Re: [PATCH] isci: fix two comment typos
On 10/04/2015 10:53 AM, Geliang Tang wrote:
> Just fix two typos in the code comment.
>
> Signed-off-by: Geliang Tang
> ---
> drivers/scsi/isci/request.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/scsi/isci/request.c b/drivers/scsi/isci/request.c
> index cfd0084..8fe106f 100644
> --- a/drivers/scsi/isci/request.c
> +++ b/drivers/scsi/isci/request.c
> @@ -3306,7 +3306,7 @@ sci_io_request_construct_smp(struct device *dev,
> * @ireq: This parameter points to the isci_request allocated in the
> *request construct function.
> *
> - * SCI_SUCCESS on successfull completion, or specific failure code.
> + * SCI_SUCCESS on successful completion, or specific failure code.
> */
> static enum sci_status isci_smp_request_build(struct isci_request *ireq)
> {
> @@ -3332,7 +3332,7 @@ static enum sci_status isci_smp_request_build(struct
> isci_request *ireq)
> * @sci_device: This parameter is the handle for the sci core's remote device
> *object that is the destination for this request.
> *
> - * SCI_SUCCESS on successfull completion, or specific failure code.
> + * SCI_SUCCESS on successful completion, or specific failure code.
> */
> static enum sci_status isci_io_request_build(struct isci_host *ihost,
> struct isci_request *request,
>
Acked-by: Artur Paszkiewicz
Thanks,
Artur
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: isci, INTx mode, race condition
On 08/19/2015 06:01 PM, Stefan Fausser wrote: > Dear all, > > attached are two patches for the "isci" module (CONFIG_SCSI_ISCI). > > Both patches apply to the current Linux kernel, retrieved by GIT (4.2.0-rc7). > > The first patch (init.patch) is for reproducing the problem with the > "Intel(R) C600 SAS Controller" in INTx Mode, see below. The second patch > (host.patch) is for fixing this problem. > > The problem: > > By applying the first patch "init.patch", the "Intel(R) C600 SAS Controller" > (now abbreviated by SAS) generates level-triggered INTx Interrupts instead of > (edge-triggered) MSI-X Interrupts. > > In the ISR (isci_intx_isr), the controller determines if the interrupt is due > to a normal operation (normal interrrupt) or an error. In the case of a > normal interrupt, a tasklet is scheduled that should handle the normal > interrupt. However, in the ISR, the interrupts are left unmasked and the SAS > device may trigger the next interrupt after the ISR has left and before the > tasklet has been scheduled. > > Thus, with this patch "init.patch" and on my system (Intel C600 chipset > series), the SAS device repeatedly level-triggers the interrupt and the > tasklet to handle the interrupt never gets scheduled. This will result in a > soft-lockup on the executing core. > > In my investigations, the above described problem occurs in all Linux kernel > version starting from 3.5 and up to to-day. > > The fix: > > By applying the second patch "host.patch", the interrupts are masked in the > INTx ISR in case of a normal interrupt. Thus, the scheduler has enough time > to schedule the handling tasklet. In the tasklet (see > sci_controller_completion_handler), the interrupts are unmasked again. > > Please let me know if you need any other information. > > Kind Regards, > > Stefan > Hi Stefan, I tried to reproduce this issue using just the init.patch and I had no soft lockups, but they started occuring after I added some delays in isci_intx_isr(). The host.patch fixed this and I think the solution is correct. Acked-by: Artur Paszkiewicz Thanks, Artur -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 RESEND 08/23] isci: Use pci_enable_msix_exact() instead of pci_enable_msix()
On 04/14/2014 10:05 AM, Alexander Gordeev wrote: > As result of deprecation of MSI-X/MSI enablement functions > pci_enable_msix() and pci_enable_msi_block() all drivers > using these two interfaces need to be updated to use the > new pci_enable_msi_range() or pci_enable_msi_exact() > and pci_enable_msix_range() or pci_enable_msix_exact() > interfaces. > > Signed-off-by: Alexander Gordeev > Cc: Lukasz Dorau > Cc: Maciej Patelczyk > Cc: Dave Jiang > Cc: intel-linux-...@intel.com > Cc: linux-s...@vger.kernel.org > Cc: linux-...@vger.kernel.org > --- > drivers/scsi/isci/init.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/drivers/scsi/isci/init.c b/drivers/scsi/isci/init.c > index 695b34e..4198e45 100644 > --- a/drivers/scsi/isci/init.c > +++ b/drivers/scsi/isci/init.c > @@ -356,7 +356,7 @@ static int isci_setup_interrupts(struct pci_dev *pdev) > for (i = 0; i < num_msix; i++) > pci_info->msix_entries[i].entry = i; > > - err = pci_enable_msix(pdev, pci_info->msix_entries, num_msix); > + err = pci_enable_msix_exact(pdev, pci_info->msix_entries, num_msix); > if (err) > goto intx; > > Looks good. Acked-by: Artur Paszkiewicz Thanks, Artur -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
