On Wed, Jul 16, 2014 at 08:05:08PM +0200, 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
On Wed, Jul 16, 2014 at 08:05:24PM +0200, 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
spin_is_locked() always return false in uniprocessor configuration and
therefore it
would be advise to repalce with assert_spin_locked().
Signed-off-by: Sanjeev Sharma
---
drivers/usb/storage/uas.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/storage/u
On Wed, Jul 16, 2014 at 08:05:10PM +0200, 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
On Sat, Jul 26, 2014 at 09:16:47AM +0100, Alexander Gordeev wrote:
> On Wed, Jul 16, 2014 at 08:05:12PM +0200, Alexander Gordeev wrote:
> > Currently the driver falls back to INTx mode when MSI-X
> > initialization failed. This is a suboptimal behaviour
> > for chips that also support MSI. This upd
On Wed, Jul 16, 2014 at 08:05:14PM +0200, 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
On Sat, Jul 26, 2014 at 09:22:27AM +0100, Alexander Gordeev wrote:
> On Wed, Jul 16, 2014 at 08:05:16PM +0200, 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
On Mon, Jul 28, 2014 at 11:26:13AM +0530, Kashyap Desai wrote:
> > -Original Message-
> > From: Alexander Gordeev [mailto:agord...@redhat.com]
> > Sent: Saturday, July 26, 2014 1:54 PM
> > To: linux-ker...@vger.kernel.org; Neela Syam Kolli
> > Subject: Re: [PATCH v2 RESEND 13/23] megaraid:
On Wed, Jul 16, 2014 at 08:05:18PM +0200, 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
On Wed, Jul 16, 2014 at 08:05:20PM +0200, 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
On Tue, Jul 29, 2014 at 07:24:03AM -0700, Christoph Hellwig wrote:
> On Tue, Jul 29, 2014 at 04:15:45PM +0200, Alexander Gordeev wrote:
> > Hmm.. 18/23 applies with a minor fuzz against
> > git://git.infradead.org/users/hch/scsi-queue.git drivers-for-3.17
>
> Okay, it was just git-am being goofy t
On Mon, Aug 11, 2014 at 01:29:26PM +0530, Sanjeev Sharma wrote:
> spin_is_locked() always return false in uniprocessor configuration
Really? On what processor type? I don't see that being the case on a
few processors, but I didn't check them all, or I might be totally
confused with all of the ar
> -Original Message-
> From: Alexander Gordeev [mailto:agord...@redhat.com]
> Sent: Monday, August 11, 2014 1:40 PM
> To: Kashyap Desai; Neela Syam Kolli
> Cc: linux-scsi@vger.kernel.org; linux-...@vger.kernel.org; linux-
> ker...@vger.kernel.org; Christoph Hellwig
> Subject: Re: [PATCH v2
On Mon, Jul 28, 2014 at 11:47:19AM +, Vikas Chaudhary wrote:
>
> Acked-By: Vikas Chaudhary
Christoph,
This patch seems ready..
> On 26/07/14 2:11 pm, "Alexander Gordeev" wrote:
>
> >On Wed, Jul 16, 2014 at 08:05:26PM +0200, Alexander Gordeev wrote:
> >> As result of deprecation of MSI-X/
On Wed, Jul 16, 2014 at 08:05:25PM +0200, 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
On Mon, Aug 11, 2014 at 10:54:34AM +0200, Alexander Gordeev wrote:
> On Mon, Jul 28, 2014 at 11:47:19AM +, Vikas Chaudhary wrote:
> >
> > Acked-By: Vikas Chaudhary
>
> Christoph,
>
> This patch seems ready..
I will apply all the patches that have gotten reviews once I open
up the queues fo
Any chance to get a review for this once so I can queued it up for 3.17?
On Fri, Aug 08, 2014 at 09:44:00AM +0200, jgr...@suse.com wrote:
> From: Juergen Gross
>
> If a scsi host driver specifies .cmd_len in it's scsi_host_template, a
> driver's
> private command pool is needed. scsi_find_host_
> + BUG_ON(sc->cmd_len > VSCSIIF_MAX_COMMAND_SIZE);
> +
> + if (sc->cmd_len)
I can't see how you can get a zero cmd_len here.
> +static int scsifront_action_handler(struct scsi_cmnd *sc, uint8_t act)
Please add a comment explaining your unusual EH strategy here.
> +static void scsifront
On 08/11/2014 11:54 AM, Christoph Hellwig wrote:
+ BUG_ON(sc->cmd_len > VSCSIIF_MAX_COMMAND_SIZE);
+
+ if (sc->cmd_len)
I can't see how you can get a zero cmd_len here.
Ahh, thanks for spotting this. In a previous version it could be zero
in case of reset.
+static int scsifront_
On 08/11/2014 08:20 AM, Suresh Thiagarajan wrote:
> Instead of using the virt_ptr use request buffer for copying
> back the nvmd response data and use the same in request function also
Patch looks good to me
Reviewed-by: Tomas Henzl
> Signed-off-by: Suresh Thiagarajan
> Reviewed-by: Tomas Henz
Acked-by: Anil Gurumurthy
-Original Message-
From: Alexander Gordeev [mailto:agord...@redhat.com]
Sent: 11 August 2014 13:09
To: linux-kernel
Cc: Anil Gurumurthy; Vijaya Mohan Guvva; linux-scsi; linux-pci; Anil
Gurumurthy; Sudarsana Kalluru
Subject: Re: [PATCH v2 RESEND 04/23] bfa: Use
Yes. 18/18 is obsolete.
Thanks to Tomas's advice.
Ching
On Fri, 2014-08-08 at 16:23 +0200, Tomas Henzl wrote:
> On 08/08/2014 02:05 PM, Ching Huang wrote:
> > From: Ching Huang
> >
> > This patch adds code to support system hibernation.
> >
> > Changes in v2 of 3/17:
> > * merge patch 18/18 to th
Hi Greg,
Please find my comment in line.
-Original Message-
From: Greg KH [mailto:gre...@linuxfoundation.org]
Sent: Monday, August 11, 2014 1:58 PM
To: Sharma, Sanjeev
Cc: hdego...@redhat.com; kra...@redhat.com; mdharm-...@one-eyed-alien.net;
linux-...@vger.kernel.org; linux-ker...@vger
This patch seies introduces support for power managment in the driver
as well as vendor specific initialization - registers, clocks, voltage
regulators etc.
It includes also a rework for the init sequnce and other PM pre-
requisit such as write protection support, well-known LUN, error
handling (r
From: Sujit Reddy Thumma
UFS devices are powered by at most three external power supplies -
- VCC - The flash memory core power supply, 2.7V to 3.6V or 1.70V to 1.95V
- VCCQ - The controller and I/O power supply, 1.1V to 1.3V
- VCCQ2 - Secondary controller and/or I/O power supply, 1.65V to 1.95V
From: Sujit Reddy Thumma
Add generic clock initialization support for UFSHCD platform
driver. The clock info is read from device tree using standard
clock bindings. A generic max-clock-frequency-hz property is
defined to save information on maximum operating clock frequency
the h/w supports.
Sig
From: Sujit Reddy Thumma
Some vendor specific controller versions might need to configure
vendor specific - registers, clocks, voltage regulators etc. to
initialize the host controller UTP layer and Uni-Pro stack.
Provide some common initialization operations that can be used
to configure vendor
From: Sujit Reddy Thumma
In ->hce_enable_notify() callback the vendor specific initialization
may carry out additional DME configuration using UIC commands and
hence the UIC command completion interrupt enable bit should be set
before the post reset notification.
Add retries if the link-startup f
From: Subhash Jadavani
Currently reading query descriptor is more tightened to each
descriptor type. This patch generalize the approach and allows
reading any parameter from any query descriptor.
Signed-off-by: Subhash Jadavani
Signed-off-by: Dolev Raviv
diff --git a/drivers/scsi/ufs/ufs.h b/
From: Yaniv Gardi
The maximum power consumption in active is determined by bActiveICCLevel.
The configuration is done by reading max current supported by the
regulators connected to VCC, VCCQ and VCCQ2 rails on the boards, and
reading the current consumption levels from the device for each rails
From: Subhash Jadavani
REPORT LUNS command has "SELECT REPORT" field which controls what type of
logical units to be reported by device server. According to UFS device
standard, if this field is set to 0, REPORT LUNS would report only report
standard logical units. If it's set to 1 then it would
From: Subhash Jadavani
This patch adds support for UFS device and UniPro link power management
during runtime/system PM.
Main idea is to define multiple UFS low power levels based on UFS device
and UFS link power states. This would allow any specific platform or pci
driver to choose the best sui
From: Sujit Reddy Thumma
The SYNCHRONIZE_CACHE command is a medium write command and hence can
fail when the device is write protected. Avoid sending such commands by
making sure that write-cache-enable is disabled even though the device
claim to support it.
Signed-off-by: Sujit Reddy Thumma
Si
From: Subhash Jadavani
UFS device may have standard LUs and LUN id could be from 0x00 to 0x7F.
UFS device specification use "Peripheral Device Addressing Format"
(SCSI SAM-5) for standard LUs.
UFS device may also have the Well Known LUs (also referred as W-LU) which
again could be from 0x00 to 0
On 07/16/2014 08:05 PM, 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_enabl
On 07/16/2014 08:05 PM, 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_enabl
On Mon, Aug 11, 2014 at 07:09:55PM +0800, Ching Huang wrote:
> Yes. 18/18 is obsolete.
> Thanks to Tomas's advice.
>
There is no way to keep track of all the patches because they aren't
in an email thread. Could you resend everything using git-format-patch
to send them as one thread?
regards,
d
On Mon, Aug 11, 2014 at 04:07:31PM +0300, Dan Carpenter wrote:
> On Mon, Aug 11, 2014 at 07:09:55PM +0800, Ching Huang wrote:
> > Yes. 18/18 is obsolete.
> > Thanks to Tomas's advice.
> >
>
> There is no way to keep track of all the patches because they aren't
> in an email thread. Could you res
On Mon, Aug 04, 2014 at 04:55:12PM +0800, Ching Huang wrote:
> From: Ching Huang
>
> This patch rewrites the arcmsr_define_adapter_type function to precisely
> check Areca adapter's ID.
> This can prevent an unknown adapter being used as a default adapter type by
> driver.
>
> Signed-off-by: C
Hi Martin,
Please let me known any further changes are required so that I can
send this patch once again with git send-email.
Regards,
Sreekanth
On Mon, Aug 11, 2014 at 6:45 PM, Sreekanth Reddy
wrote:
> Hi Martin,
>
> Please let me known any further changes are required so that I can send this
On 2014-08-10 06:54, Guenter Roeck wrote:
The latest kernel fails to boot qemu arm images when using scsi
for disk access. Boot gets stuck after the following messages.
brd: module loaded
sym53c8xx :00:0c.0: enabling device (0100 -> 0103)
sym0: <895a> rev 0x0 at pci :00:0c.0 irq 93
sym0:
At Sun, 10 Aug 2014 16:58:02 +0200,
Luis R. Rodriguez wrote:
>
> On Sun, Aug 10, 2014 at 08:43:31PM +0800, Greg KH wrote:
> > On Sat, Aug 09, 2014 at 06:41:19PM +0200, Luis R. Rodriguez wrote:
> > > On Wed, Jul 30, 2014 at 03:11:07PM -0700, David Miller wrote:
> > > > From: "Luis R. Rodriguez"
>
Should we wrap the sdev->device_busy read and test in a new
scsi_device_busy(), so as to preserve the old polarity?
Reviewed-by: Venkatesh Srinivas
On 8/11/14, Jens Axboe wrote:
> On 2014-08-10 06:54, Guenter Roeck wrote:
>> The latest kernel fails to boot qemu arm images when using scsi
>> for
On 08/11/2014 08:33 AM, Venkatesh Srinivas wrote:
Should we wrap the sdev->device_busy read and test in a new
scsi_device_busy(), so as to preserve the old polarity?
I don't see a difference in polarity, or at least replacing '== 0' with '!'
is not a reverse in polarity for me. Anyway, I don't
> -Original Message-
> From: Alexander Gordeev [mailto:agord...@redhat.com]
> Sent: Monday, August 11, 2014 12:57 AM
> To: intel-linux-scu; Paszkiewicz, Artur; Jiang, Dave
> Cc: Dorau, Lukasz; Patelczyk, Maciej; intel-linux-scu; linux-
> s...@vger.kernel.org; linux-...@vger.kernel.org; Chri
Acked-by: James Smart
-- james s
On 7/31/2014 4:08 PM, Daniel Borkmann wrote:
In prandom we have already reseeding mechanisms that trigger
periodically from a much better entropy source than just
feeding in jiffies through lpfc_mbx_cmpl_fcf_scan_read_fcf_rec()
[what a function name 8-)].
Alexander,
I haven't looked too deeply, but it's clear it doesn't jive with what
we've discussed in the past. Your original patches missed several other
similar sections for revision. I had sent a revised set of patches.
I was also unclear as to the merge path the patches were taking, as it
On Mon, Aug 11, 2014 at 11:27 AM, Takashi Iwai wrote:
> Luis R. Rodriguez wrote:
>>
>> On Sun, Aug 10, 2014 at 08:43:31PM +0800, Greg KH wrote:
>> > On Sat, Aug 09, 2014 at 06:41:19PM +0200, Luis R. Rodriguez wrote:
>> > > On Wed, Jul 30, 2014 at 03:11:07PM -0700, David Miller wrote:
>> > > > From
On Mon, Aug 11, 2014 at 12:27:29PM +0200, Juergen Gross wrote:
> What do you mean with "unusual"? You mean transferring the EH action to
> Dom0?
Yes. Note that hyperv tries something similar and they've run into
timeout issues, you might want to read up the recent thread on that.
> >>+
On Mon, 11 Aug 2014, Alexander Gordeev wrote:
On Wed, Jul 16, 2014 at 08:05:25PM +0200, 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
> +#include
> +#include
> +#include
What do you need these for? Normally target drivers shouldn't need
these.
> +struct vscsibk_emulate {
> + void (*pre_function)(struct vscsibk_pend *, void *);
> + void (*post_function)(struct vscsibk_pend *, void *);
> +};
This doesn't seem to be u
On Mon, Aug 11, 2014 at 01:29:26PM +0530, Sanjeev Sharma wrote:
> spin_is_locked() always return false in uniprocessor configuration and
> therefore it
> would be advise to repalce with assert_spin_locked().
>
> Signed-off-by: Sanjeev Sharma
> ---
> drivers/usb/storage/uas.c | 8
> 1 f
On Mon, Aug 11, 2014 at 01:07:15PM -0400, James Smart wrote:
> Acked-by: James Smart
Can you jsut queue this up (and the pci fix as well) together with
anything else you have pending for 3.18?
I'd really like to move towards a model where maintainers of driver
collect everything for their area
yep. I'll do so.
-- james s
On 8/11/2014 2:18 PM, Christoph Hellwig wrote:
On Mon, Aug 11, 2014 at 01:07:15PM -0400, James Smart wrote:
Acked-by: James Smart
Can you jsut queue this up (and the pci fix as well) together with
anything else you have pending for 3.18?
I'd really like to mov
Hi,
On 08/11/2014 08:19 PM, Guenter Roeck wrote:
> On Mon, Aug 11, 2014 at 01:29:26PM +0530, Sanjeev Sharma wrote:
>> spin_is_locked() always return false in uniprocessor configuration and
>> therefore it
>> would be advise to repalce with assert_spin_locked().
>>
>> Signed-off-by: Sanjeev Sharma
Hi,
On 08/11/2014 09:59 AM, Sanjeev Sharma wrote:
> spin_is_locked() always return false in uniprocessor configuration and
> therefore it
> would be advise to repalce with assert_spin_locked().
>
> Signed-off-by: Sanjeev Sharma
Looks sane / good to me:
Acked-by: Hans de Goede
Regards,
Hans
On Mon, Aug 11, 2014 at 08:55:07PM +0200, Hans de Goede wrote:
> Hi,
>
> On 08/11/2014 08:19 PM, Guenter Roeck wrote:
> > On Mon, Aug 11, 2014 at 01:29:26PM +0530, Sanjeev Sharma wrote:
> >> spin_is_locked() always return false in uniprocessor configuration and
> >> therefore it
> >> would be adv
Hi,
On 08/11/2014 09:08 PM, Guenter Roeck wrote:
> On Mon, Aug 11, 2014 at 08:55:07PM +0200, Hans de Goede wrote:
>> Hi,
>>
>> On 08/11/2014 08:19 PM, Guenter Roeck wrote:
>>> On Mon, Aug 11, 2014 at 01:29:26PM +0530, Sanjeev Sharma wrote:
spin_is_locked() always return false in uniprocessor
On Fri, Jul 18, 2014 at 12:20:56PM +0200, Alexander Gordeev wrote:
> The performance test is not decent, though. I used "fio" random
> read against a "null_blk" device sitting on top of "percpu_tags",
> which is not exactly how "percpu_ida" is used. This is another
> reason I am posting - an advice
(Responding again without gmail, as the last email hit a failure when
responding to the lists..)
On Mon, 2014-08-11 at 16:17 -0400, Alexander Gordeev wrote:
> On Fri, Jul 18, 2014 at 12:20:56PM +0200, Alexander Gordeev wrote:
> > The performance test is not decent, though. I used "fio" random
> >
On Mon, 2014-08-11 at 13:52 -0700, Nicholas A. Bellinger wrote:
> (Responding again without gmail, as the last email hit a failure when
> responding to the lists..)
>
> On Mon, 2014-08-11 at 16:17 -0400, Alexander Gordeev wrote:
> > On Fri, Jul 18, 2014 at 12:20:56PM +0200, Alexander Gordeev wrote
On Mon, Aug 11, 2014 at 11:56:17AM +, Sharma, Sanjeev wrote:
> Hi Greg,
>
> Please find my comment in line.
As it should, but where is it, your quoting is all messed up...
> -Original Message-
> From: Greg KH [mailto:gre...@linuxfoundation.org]
> Sent: Monday, August 11, 2014 1:58 P
> "Sreekanth" == Sreekanth Reddy writes:
Sreekanth> Please let me known any further changes are required so that
Sreekanth> I can send this patch once again with git send-email.
I'm OK with the latest iteration.
--
Martin K. Petersen Oracle Linux Engineering
--
To unsubscribe from thi
spin_is_locked() always return false in uniprocessor configuration and
therefore it
would be advise to replace with lockdep_assert_held().
Signed-off-by: Sanjeev Sharma
---
Changes in v2:
- replaced WARN_ON_ONCE() with lockdep_assert_held() to
avoid runtime overhead instead of assert_spin_lock
Hi,
On 08/12/2014 08:08 AM, Sanjeev Sharma wrote:
> spin_is_locked() always return false in uniprocessor configuration and
> therefore it
> would be advise to replace with lockdep_assert_held().
>
> Signed-off-by: Sanjeev Sharma
> ---
> Changes in v2:
> - replaced WARN_ON_ONCE() with lockdep_a
On Tue, Aug 12, 2014 at 11:38:37AM +0530, Sanjeev Sharma wrote:
> spin_is_locked() always return false in uniprocessor configuration and
> therefore it
> would be advise to replace with lockdep_assert_held().
Add "on some architectures" in here somewhere, as it's not broken on the
large majority
on some architecture spin_is_locked() always return false in
uniprocessor configuration and therefore it would be advise
to replace with lockdep_assert_held().
Signed-off-by: Sanjeev Sharma
---
Changes in v3:
incorporated review comment suggested by Greg
drivers/usb/storage/uas.c | 8
Done !
Thanks
Sanjeev Sharma
-Original Message-
From: Greg KH [mailto:gre...@linuxfoundation.org]
Sent: Tuesday, August 12, 2014 11:32 AM
To: Sharma, Sanjeev
Cc: hdego...@redhat.com; kra...@redhat.com; mdharm-...@one-eyed-alien.net;
linux-...@vger.kernel.org; linux-ker...@vger.kernel.or
Hi,
On 08/12/2014 08:40 AM, Sanjeev Sharma wrote:
> on some architecture spin_is_locked() always return false in
> uniprocessor configuration and therefore it would be advise
> to replace with lockdep_assert_held().
>
> Signed-off-by: Sanjeev Sharma
> ---
> Changes in v3:
> incorporated review
On Tue, Aug 12, 2014 at 02:01:53PM +0800, Greg KH wrote:
> On Tue, Aug 12, 2014 at 11:38:37AM +0530, Sanjeev Sharma wrote:
> > spin_is_locked() always return false in uniprocessor configuration and
> > therefore it
> > would be advise to replace with lockdep_assert_held().
>
> Add "on some archit
Yes I have incorporated review comment from Greg.
Regards
Sanjeev Sharma
-Original Message-
From: Hans de Goede [mailto:hdego...@redhat.com]
Sent: Tuesday, August 12, 2014 11:59 AM
To: Sharma, Sanjeev
Cc: gre...@linuxfoundation.org; kra...@redhat.com;
mdharm-...@one-eyed-alien.net; linu
71 matches
Mail list logo
