[PATCH] aic7xxx: fix firmware build with O=path

Building firmware with O=path was apparently broken in aic7 for ever. Message of the previous commit to the Makefile (from 2008) mentions this unfortunate state of affairs already. Fix this, mostly to make randconfig builds more reliable. Signed-off-by: Jakub Kicinski

Re: [PATCH] aic7xxx: fix firmware build with O=path

On Tue, 18 Jul 2017 21:45:49 -0400, Martin K. Petersen wrote: > Jakub, > > > I just noticed this patch got marked as "Deferred, archived" in > > patchwork. I'm not entirely sure by whom and why? Could someone > > explain what is the issue? I would really appreciate if we could > > merge this

Re: [PATCH] aic7xxx: fix firmware build with O=path

Jakub, > I just noticed this patch got marked as "Deferred, archived" in > patchwork. I'm not entirely sure by whom and why? Could someone > explain what is the issue? I would really appreciate if we could > merge this patch and have this driver not break builds randomly... It's an

Re: [PATCH] aic7xxx: fix firmware build with O=path

On Wed, 28 Jun 2017 21:17:16 -0700, Jakub Kicinski wrote: > Building firmware with O=path was apparently broken in aic7 for ever. > Message of the previous commit to the Makefile (from 2008) mentions > this unfortunate state of affairs already. Fix this, mostly to make > randconfig builds more

[PATCH] scsi: Convert to using %pOF instead of full_name

Now that we have a custom printf format specifier, convert users of full_name to use %pOF instead. This is preparation to remove storing of the full path string for each node. Signed-off-by: Rob Herring Cc: "James E.J. Bottomley" Cc: "Martin K.

Re: [REGRESSION] 28676d869bbb (scsi: sg: check for valid direction before starting the request) breaks mtx tape library control

I have verified that building a clean v4.12 with 68c59fcea1f2c6a54c62aa896cc623c1b5bc9b47 cherry picked on top still shows the problem: [root@backup2 ~]# mtx -f /dev/sg7 next 0 Unloading drive 0 into Storage Element 45...mtx: Request Sense: Long Report=yes mtx: Request Sense: Valid Residual=no

Re: [REGRESSION] 28676d869bbb (scsi: sg: check for valid direction before starting the request) breaks mtx tape library control

> "JT" == Johannes Thumshirn writes: JT> This is fixed with: commit 68c59fcea1f2c6a54c62aa896cc623c1b5bc9b47 Hmm, well, I just pulled and built mainline, which does appear to contain that patch (though it wasn't there when I first started investigating this last week)

Re: [PATCH] scsi: default to scsi-mq

On Tue, 18 Jul 2017 23:58:03 +0800 Jonathan Cameron wrote: > On Fri, 14 Jul 2017 14:45:39 +0200 > "h...@lst.de" wrote: > > > On Fri, Jul 14, 2017 at 05:56:41PM +0800, Jonathan Cameron wrote: > > > Just wondering if you had any thoughts on how we can

Re: [PATCH] scsi: default to scsi-mq

On Fri, 14 Jul 2017 14:45:39 +0200 "h...@lst.de" wrote: > On Fri, Jul 14, 2017 at 05:56:41PM +0800, Jonathan Cameron wrote: > > Just wondering if you had any thoughts on how we can proceed with tracking > > down this regression? > > > > I'm not familiar enough with the multiqueue

Attention To me and get back to me urgent

Attention:Beneficiary I am Meliana Trump, and I am writing to inform you about your Bank Check Draft brought back 16/07/2017 by the United Embassy Mr John Moore from the government of Benin Republic in the white house Washington DC been mandated to be deliver to your home address once you

Re: [PATCH 20/22] sound: pci: avoid string overflow warnings

On Fri, Jul 14, 2017 at 2:28 PM, Takashi Iwai wrote: > On Fri, 14 Jul 2017 14:07:12 +0200, > > Thanks for the patch. I have seen it but ignored, so far, as not sure > which action is the best. An alternative solution is to use > snprintf() blindly, for example. > > For mixart,

Re: [PATCH v2 08/15] megaraid_sas: Use SMID for Task abort case only

On 5.7.2017 14:00, Shivasharan S wrote: > Fix - In TM code, smid_task is valid only in case of task aborts. > > Signed-off-by: Kashyap Desai > Signed-off-by: Shivasharan S > Reviewed-by: Hannes Reinecke > --- >

Re: [PATCH v10 00/15] Replace PCI pool by DMA pool API

Hello, Le 09/07/2017 à 23:30, Doug Ledford a écrit : > On Thu, 2017-07-06 at 10:12 +0200, Romain Perier wrote: >> The current PCI pool API are simple macro functions direct expanded >> to >> the appropriate dma pool functions. The prototypes are almost the >> same >> and semantically, they are

RE: [PATCH v2 08/15] megaraid_sas: Use SMID for Task abort case only

> -Original Message- > From: Shivasharan S [mailto:shivasharan.srikanteshw...@broadcom.com] > Sent: Wednesday, July 05, 2017 5:30 PM > To: linux-scsi@vger.kernel.org > Cc: martin.peter...@oracle.com; the...@redhat.com; > j...@linux.vnet.ibm.com; kashyap.de...@broadcom.com; >

Re: [PATCH 1/1] scsi: ufs: changing maintainer

Hello Greg and Prabu, Às 10:31 AM de 7/18/2017, Greg Kroah-Hartman (gre...@linuxfoundation.org) escreveu: > On Tue, Jul 18, 2017 at 09:15:58AM +, Prabu Thangamuthu wrote: >> As per internal decision, Joao Pinto will be maintainer for DWC UFS driver. > > That's "odd", does Joao want this?

Re: [PATCH 1/1] scsi: ufs: changing maintainer

On Tue, Jul 18, 2017 at 09:15:58AM +, Prabu Thangamuthu wrote: > As per internal decision, Joao Pinto will be maintainer for DWC UFS driver. That's "odd", does Joao want this? Do you want this? thanks, greg k-h

[PATCH 1/1] scsi: ufs: changing maintainer

As per internal decision, Joao Pinto will be maintainer for DWC UFS driver. Signed-off-by: Prabu Thangamuthu --- MAINTAINERS |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 8a99f6b..2122e93 100644 --- a/MAINTAINERS

Re: Hello ...

Attn: Sir/Madam, Greetings to you. I Got your contact details through a Database. I have an important business discussion I wish to share with you which I believe will interest you, because it is in connection with your last name “”, and you are going to benefit from it. I am a bank officer

Re: [REGRESSION] 28676d869bbb (scsi: sg: check for valid direction before starting the request) breaks mtx tape library control

On Mon, Jul 17, 2017 at 07:44:50PM -0500, Jason L Tibbitts III wrote: > and confirmed that clean unpatched 4.12 shows the problem, while > reverting just that patch fixes the issue. Unfortunately I don't know > enough to actually fix this, but I can easily test patches. This is fixed with: