Re: [PATCH v1 RESEND] mpt3sas: Swap I/O memory read value back to cpu endianness

[David Miller]

From: Sreekanth Reddy 
Date: Fri, 3 Aug 2018 16:04:15 +0530

> On Fri, Aug 3, 2018 at 3:07 PM, Andy Shevchenko
>  wrote:
>> On Thu, 2018-08-02 at 16:16 -0400, Martin K. Petersen wrote:
>>> Andy,
>>>
>>> Please review the changes Sreekanth made to address your feedback.
>>
>> From my point of view they look good.
>>
>> I assume Sreekanth tested them on real hardware and as I remember davem@
>> actually the one who possesses sparc machine with this hardware.
> 
> Yes I have tested this patch changes on SPARC64 system and it is working fine.

I don't have access to my sparc64 hardware at the moment, so please don't
wait for my testing in order to merge this fix.

Thanks!

Re: [PATCH] mpt3sas: Fix for regression caused due to cf6bf9710c patch

[David Miller]

From: Sreekanth Reddy 
Date: Mon, 9 Jul 2018 17:12:51 +0530

> This is a shared structure between the host drivers and HBA device.
> HBA Firmware sends the information though this structures which are
> defined in the MPI headers. Now we can't change the order of these u8
> objects.
> 
> typedef struct _MPI2_DEFAULT_REPLY {
> U16 FunctionDependent1; /*0x00 */
> U8 MsgLength;   /*0x02 */
> U8 Function;/*0x03 */
> U16 FunctionDependent2; /*0x04 */

When a big-endian cpu stores a 16-bit or 32-bit value into a piece of
"cpu memory", which is what you are doing before interpreting the u8
values, you must define the u8 components in the endianness order
they will be stored in.

Alternatively, you must extract the 8-bit values by hand using
shifts and masks in a local variable.

The huge problem is that you are mixing and matching I/O memory
accessors which do endianness swaps for you, and normal cpu
loads and stores into a data structure in cpu memory, then
reading smaller sized components back and expects this all to
work out properly.

In fact, if you want to keep the structure definition above
as-is, you should swap the I/O memory read value _BACK_ to
cpu endianness before storing it.

And in fact that is what the code is doing now, which you broke by
trying to "fix" it.

Meanwhile, this discussion has been drawn out way way way too long,
and the fact is that your change broke big endian instead of fixing
any real problem whatsoever.  You did not test your change on any real
big endian system.

Therefore, as requested from the very beginning, would you please
revert this change which broke big endian and for which you do not
have a satisfactory resolution for at this time.

This is how regressions are handled, if a fix cannot be procured in a
short amount of time, we revert.

Thank you.

Re: [PATCH] mpt3sas: Fix for regression caused due to cf6bf9710c patch

[David Miller]

From: Sreekanth Reddy 
Date: Wed, 4 Jul 2018 16:54:05 +0530

> 
> Also I tried replacing readl() API with readw()API (as HBA FW will
> send 16 bit data at a time) as shown below and still I see same issue,
> 
> MPI2DefaultReply_t *default_reply = (MPI2DefaultReply_t *)reply;
> u16 reply1;
> reply1 = readw(>chip->Doorbell);
> reply[1] = reply1;
> 
> printk("LSI debug.. 0x%x, 0x%x, 0x%x \n", reply1, reply[1]);
> writel(0, >chip->HostInterruptStatus);
> 
> printk("LSI MsgLength :%d\n", default_reply->MsgLength);
> 
> And I got below output where message length is wrong, when I execute
> above code on SPARC64 machine,

It's the ordering of the u8 objects in the structure that is the problem,
on big endian they need to be swapped.

Re: [PATCH] mpt3sas: Fix for regression caused due to cf6bf9710c patch

[David Miller]

From: Sreekanth Reddy 
Date: Tue, 3 Jul 2018 17:48:49 +0530

> Any suggestion/update over my previous mail. I am using 4.13 kernel.

I think the issue is that if you are reading a 32-bit word and then
interpreting it as a struct full of individual bytes, you have to
order the bytes in the structure appropriately for the cpu endianness.

Look at the 32-bit value read, it is identical in both the x86 and
sparc cases.

Re: [PATCH] mpt3sas: Fix for regression caused due to cf6bf9710c patch

[David Miller]

From: Andy Shevchenko 
Date: Fri, 29 Jun 2018 18:42:30 +0300

> On Fri, Jun 29, 2018 at 5:58 PM, Chaitra P B
>  wrote:
>>  "scsi: mpt3sas: Bug fix for big endian systems"
>>
>> Above patch with commit id "cf6bf9710cabba1fe94a4349f4eb8db623c77ebc" was
>> posted to fix sparse warnings. While posting this patch it was assumed that
>> readl() & writel() APIs internally calls le32_to_cpu() & cpu_to_le32() APIs
>> respectively.
> 
>> Looks like it is not true for all architecture

Sparc does.  It uses endianness translating stores and loads for the MMIO
accesses.

For example, readl() does:

__asm__ __volatile__("lduwa\t[%1] %2, %0\t/* pci_readl */"
 : "=r" (ret)
 : "r" (addr), "i" (ASI_PHYS_BYPASS_EC_E_L)
 : "memory");

That "_L" at the end of the ASI_* value means "little-endian".

So if your understanding and basis for this bug fix is that sparc64
does not endian translate, it is a false one.

>> this patch is reverting back only those hunks which removed le32_to_cpu()
>> API call while using readl() API & cpu_to_le32() API call while using
>> writel() API.
> 
> Can't you move to raw variants at the same time to be more clear with
> intentions?
> It would work on all architectures in the same way and won't trigger
> sparse warnings.

If you move to the raw variants you lose the memory barriers, it doesn't
just change the endianness of the access.

Re: mpt3sas regression...

[David Miller]

From: Chaitra Basappa 
Date: Wed, 27 Jun 2018 19:58:34 +0530

>  Please let us know what is the issue faced and  if its recreating then
> share the driver logs with logging_level=0x3f8.

The driver cannot even probe successfully to start scanning for disks
because some busy bit never clears.  I think it was in one of the
firmware status registers or the doorbell register.

mpt3sas regression...

[David Miller]

Commit:


commit cf6bf9710cabba1fe94a4349f4eb8db623c77ebc
Author: Chaitra P B 
Date:   Tue Apr 24 05:28:30 2018 -0400

scsi: mpt3sas: Bug fix for big endian systems.


actually breaks big-endian.  This driver has been working perfectly
fine for more a decade or so on my sparc64 test systems up until this
point.

If you are just responding to sparse warnings, please do not do that.
What big-endian system did you test this change on?

Meanwhile, I'd like to ask that this change be reverted.

Thank you.

Re: [PATCH net-next 1/2] cxgb4: change the port capability bits definition

[David Miller]

From: Ganesh Goudar 
Date: Wed, 23 May 2018 20:02:58 +0530

> MDI Port Capabilities bit definitions were inconsistent with
> regard to the MDI enum values. 2 bits used to define MDI in
> the port capabilities are not really separable, it's a 2-bit
> field with 4 different values. Change the port capability bit
> definitions to be "AUTO" and "STRAIGHT" in order to get them
> to line up with the enum's.
> 
> Signed-off-by: Casey Leedom 
> Signed-off-by: Ganesh Goudar 

Applied.

Re: [PATCH net-next 2/2] cxgb4: do L1 config when module is inserted

[David Miller]

From: Ganesh Goudar 
Date: Wed, 23 May 2018 20:03:33 +0530

> trigger an L1 configure operation when a transceiver module
> is inserted in order to cause current "sticky" options like
> Requested Forward Error Correction to be reapplied.
> 
> Signed-off-by: Casey Leedom 
> Signed-off-by: Ganesh Goudar 

Applied.

Vmbus series...

[David Miller]

Please feel free put it in via the scsi tree:

Acked-by: David S. Miller 

Re: [PATCH v2 net-next] qed*: Utilize FW 8.33.11.0

[David Miller]

From: Michal Kalderon 
Date: Wed, 28 Mar 2018 11:42:16 +0300

> This FW contains several fixes and features
> 
> RDMA Features
> - SRQ support
> - XRC support
> - Memory window support
> - RDMA low latency queue support
> - RDMA bonding support
> 
> RDMA bug fixes
> - RDMA remote invalidate during retransmit fix
> - iWARP MPA connect interop issue with RTR fix
> - iWARP Legacy DPM support
> - Fix MPA reject flow
> - iWARP error handling
> - RQ WQE validation checks
> 
> MISC
> - Fix some HSI types endianity
> - New Restriction: vlan insertion in core_tx_bd_data can't be set
>   for LB packets
> 
> ETH
> - HW QoS offload support
> - Fix vlan, dcb and sriov flow of VF sending a packet with
>   inband VLAN tag instead of default VLAN
> - Allow GRE version 1 offloads in RX flow
> - Allow VXLAN steering
> 
> iSCSI / FcoE
> - Fix bd availability checking flow
> - Support 256th sge proerly in iscsi/fcoe retransmit
> - Performance improvement
> - Fix handle iSCSI command arrival with AHS and with immediate
> - Fix ipv6 traffic class configuration
> 
> DEBUG
> - Update debug utilities
> 
> Signed-off-by: Michal Kalderon 
> Signed-off-by: Tomer Tayar 
> Signed-off-by: Manish Rangankar 
> Signed-off-by: Ariel Elior 
> ---
> Changes from v1
>   Remove version bump and qedr module version addition

Applied.

Re: [PATCH v4 net-next 0/4] qed*: Advance to FW 8.33.1.0

[David Miller]

From: Tomer Tayar 
Date: Wed, 27 Dec 2017 19:30:04 +0200

> This series advances all qed* drivers to use firmware 8.33.1.0 which brings
> new capabilities and initial support of new HW. The changes are mostly in
> qed, and include changes in the FW interface files, as well as updating the
> FW initialization and debug collection code. The protocol drivers have
> minor functional changes for this firmware.
> 
> Patch 1 Rearranges and refactors the FW interface files in preparation of
> the new FW (no functional change).
> Patch 2 Prepares the code for support of new HW (no functional change).
> Patch 3 Actual utilization of the new FW.
> Patch 4 Advances drivers' version.
> 
> v3->v4:
> Fix a compilation issue which was reported by krobot (dependency on CRC8).
> 
> v2->v3:
> Resend the series with a fixed title in the cover letter.
> 
> v1->v2:
> - Break the previous single patch into several patches.
> - Fix compilation issues which were reported by krobot.

I'm going to apply this, however

These firmware update changes are rediculously invasive.

Backporting patches through these updates will be a giant task if not
impossible for anyone who tries to do something like this.

Who reviewed these changes outside of Cavium to look for clerical
and typographical errors?  I be nobody did.  I personally scanned
them for about 20 minutes.

Therefore, it is my judgment that the way firmware support updates are
done in the QED driver is detrimental to it's long term
maintainability.

Thank you.

Re: [PATCH v2 net-next 0/3] qed*: Advance to FW 8.33.1.0

[David Miller]

This says "0/3" and then a 4 patch series shows up...

Re: [PATCH net-next] qed*: Utilize FW 8.33.1.0

[David Miller]

From: Jakub Kicinski 
Date: Tue, 19 Dec 2017 15:46:51 -0800

> On Tue, 19 Dec 2017 16:05:23 +0200, Tomer Tayar wrote:
>> Sorry for the very long patch.
>> The firmware changes are spread all over w/o a good modularity.
> 
> Rings false.  Significant portion of this patch is just whitespace 
> and comment changes.

Totally agreed.

This thing is beyond huge already, adding unrelated whitespace and
comment changes make reviewing it even more impossible.

Re: [PATCH v16 2/4] net: e100: Replace PCI pool old API

[David Miller]

From: Romain Perier 
Date: Fri, 15 Dec 2017 20:31:21 +0100

> From: Romain Perier 
> 
> The PCI pool API is deprecated. This commit replaces the PCI pool old
> API by the appropriate function with the DMA pool API.
> 
> Signed-off-by: Romain Perier 
> Acked-by: Peter Senna Tschudin 
> Acked-by: Jeff Kirsher 
> Tested-by: Peter Senna Tschudin 

Acked-by: David S. Miller 

Re: [PATCH v16 3/4] hinic: Replace PCI pool old API

[David Miller]

From: Romain Perier 
Date: Fri, 15 Dec 2017 20:31:22 +0100

> From: Romain Perier 
> 
> The PCI pool API is deprecated. This commit replaces the PCI pool old
> API by the appropriate function with the DMA pool API.
> 
> Signed-off-by: Romain Perier 

Acked-by: David S. Miller 

Re: [PATCH 10/13] timer: Remove expires and data arguments from DEFINE_TIMER

[David Miller]

From: Kees Cook 
Date: Wed,  4 Oct 2017 16:27:04 -0700

> Drop the arguments from the macro and adjust all callers with the
> following script:
> 
>   perl -pi -e 's/DEFINE_TIMER\((.*), 0, 0\);/DEFINE_TIMER($1);/g;' \
> $(git grep DEFINE_TIMER | cut -d: -f1 | sort -u | grep -v timer.h)
> 
> Signed-off-by: Kees Cook 
> Acked-by: Geert Uytterhoeven  # for m68k parts

For networking:

Acked-by: David S. Miller 

Re: [PATCH 04/13] timer: Remove init_timer_pinned() in favor of timer_setup()

[David Miller]

From: Kees Cook 
Date: Wed,  4 Oct 2017 16:26:58 -0700

> This refactors the only users of init_timer_pinned() to use
> the new timer_setup() and from_timer(). Drops the definition of
> init_timer_pinned().
> 
> Cc: Chris Metcalf 
> Cc: Thomas Gleixner 
> Cc: net...@vger.kernel.org
> Signed-off-by: Kees Cook 

For networking:

Acked-by: David S. Miller 

Re: [PATCH 05/13] timer: Remove init_timer_deferrable() in favor of timer_setup()

[David Miller]

From: Kees Cook 
Date: Wed,  4 Oct 2017 16:26:59 -0700

> This refactors the only users of init_timer_deferrable() to use
> the new timer_setup() and from_timer(). Removes definition of
> init_timer_deferrable().
> 
> Cc: Benjamin Herrenschmidt 
> Cc: Michael Ellerman 
> Cc: Sebastian Reichel 
> Cc: Harish Patil 
> Cc: Manish Chopra 
> Cc: Kalle Valo 
> Cc: linuxppc-...@lists.ozlabs.org
> Cc: net...@vger.kernel.org
> Cc: linux-wirel...@vger.kernel.org
> Signed-off-by: Kees Cook 

For networking:

Acked-by: David S. Miller 

Re: [PATCH 06/10] drivers:ethernet: return -ENOMEM on allocation failure.

[David Miller]

From: Allen Pais 
Date: Wed, 13 Sep 2017 13:02:15 +0530

> Signed-off-by: Allen Pais 

This is quite pointless as the caller doesn't do anything with
the value, it just tests whether a negative value is returned
or not.

Re: [PATCH 08/22] isdn: divert: fix sprintf buffer overflow warning

[David Miller]

From: Arnd Bergmann 
Date: Fri, 14 Jul 2017 14:07:00 +0200

> One string we pass into the cs->info buffer might be too long,
> as pointed out by gcc:
> 
> drivers/isdn/divert/isdn_divert.c: In function 'll_callback':
> drivers/isdn/divert/isdn_divert.c:488:22: error: '%d' directive writing 
> between 1 and 3 bytes into a region of size between 1 and 69 
> [-Werror=format-overflow=]
>  sprintf(cs->info, "%d 0x%lx %s %s %s %s 0x%x 0x%x %d %d %s\n",
>^~~
> drivers/isdn/divert/isdn_divert.c:488:22: note: directive argument in the 
> range [0, 255]
> drivers/isdn/divert/isdn_divert.c:488:4: note: 'sprintf' output 25 or more 
> bytes (assuming 129) into a destination of size 90
> 
> This is unlikely to actually cause problems, so let's use snprintf
> as a simple workaround to shut  up the warning and truncate the
> buffer instead.
> 
> Signed-off-by: Arnd Bergmann 

Applied.

Re: [PATCH 09/22] net: niu: fix format string overflow warning:

[David Miller]

From: Arnd Bergmann 
Date: Fri, 14 Jul 2017 14:07:01 +0200

> We get a warning for the port_name string that might be longer than
> six characters if we had more than 10 ports:
> 
> drivers/net/ethernet/sun/niu.c: In function 'niu_put_parent':
> drivers/net/ethernet/sun/niu.c:9563:21: error: '%d' directive writing between 
> 1 and 3 bytes into a region of size 2 [-Werror=format-overflow=]
>   sprintf(port_name, "port%d", port);
>  ^~~~
> drivers/net/ethernet/sun/niu.c:9563:21: note: directive argument in the range 
> [0, 255]
> drivers/net/ethernet/sun/niu.c:9563:2: note: 'sprintf' output between 6 and 8 
> bytes into a destination of size 6
>   sprintf(port_name, "port%d", port);
>   ^~
> drivers/net/ethernet/sun/niu.c: In function 'niu_pci_init_one':
> drivers/net/ethernet/sun/niu.c:9538:22: error: '%d' directive writing between 
> 1 and 3 bytes into a region of size 2 [-Werror=format-overflow=]
>sprintf(port_name, "port%d", port);
>   ^~~~
> drivers/net/ethernet/sun/niu.c:9538:22: note: directive argument in the range 
> [0, 255]
> drivers/net/ethernet/sun/niu.c:9538:3: note: 'sprintf' output between 6 and 8 
> bytes into a destination of size 6
> 
> While we know that the port number is small, there is no harm in
> making the format string two bytes longer to avoid the warning.
> 
> Signed-off-by: Arnd Bergmann 

Applied.

Re: [PATCH 10/22] bnx2x: fix format overflow warning

[David Miller]

From: Arnd Bergmann 
Date: Fri, 14 Jul 2017 14:07:02 +0200

> gcc notices that large queue numbers would overflow the queue name
> string:
> 
> drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c: In function 
> 'bnx2x_get_strings':
> drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c:3165:25: error: '%d' 
> directive writing between 1 and 10 bytes into a region of size 5 
> [-Werror=format-overflow=]
> drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c:3165:25: note: directive 
> argument in the range [0, 2147483647]
> drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c:3165:5: note: 'sprintf' 
> output between 2 and 11 bytes into a destination of size 5
> 
> There is a hard limit in place that makes the number at most two
> digits, so the code is fine. This changes it to use snprintf()
> to truncate instead of overflowing, which shuts up that warning.
> 
> Signed-off-by: Arnd Bergmann 

Applied.

Re: [PATCH 11/22] net: thunder_bgx: avoid format string overflow warning

[David Miller]

From: Arnd Bergmann 
Date: Fri, 14 Jul 2017 14:07:03 +0200

> gcc warns that the temporary buffer might be too small here:
> 
> drivers/net/ethernet/cavium/thunder/thunder_bgx.c: In function 'bgx_probe':
> drivers/net/ethernet/cavium/thunder/thunder_bgx.c:1020:16: error: '%d' 
> directive writing between 1 and 10 bytes into a region of size between 9 and 
> 11 [-Werror=format-overflow=]
> sprintf(str, "BGX%d LMAC%d mode", bgx->bgx_id, lmacid);
>  ^~~
> drivers/net/ethernet/cavium/thunder/thunder_bgx.c:1020:16: note: directive 
> argument in the range [0, 2147483647]
> drivers/net/ethernet/cavium/thunder/thunder_bgx.c:1020:3: note: 'sprintf' 
> output between 16 and 27 bytes into a destination of size 20
> 
> This probably can't happen, but it can't hurt to make it long
> enough for the theoretical limit.
> 
> Signed-off-by: Arnd Bergmann 

Applied.

Re: [PATCH 13/22] liquidio: fix possible eeprom format string overflow

[David Miller]

From: Arnd Bergmann 
Date: Fri, 14 Jul 2017 14:07:05 +0200

> gcc reports that the temporary buffer for computing the
> string length may be too small here:
> 
> drivers/net/ethernet/cavium/liquidio/lio_ethtool.c: In function 
> 'lio_get_eeprom_len':
> /drivers/net/ethernet/cavium/liquidio/lio_ethtool.c:345:21: error: 'sprintf' 
> may write a terminating nul past the end of the destination 
> [-Werror=format-overflow=]
>   len = sprintf(buf, "boardname:%s serialnum:%s maj:%lld min:%lld\n",
>  ^~~
> drivers/net/ethernet/cavium/liquidio/lio_ethtool.c:345:6: note: 'sprintf' 
> output between 35 and 167 bytes into a destination of size 128
>   len = sprintf(buf, "boardname:%s serialnum:%s maj:%lld min:%lld\n",
> 
> This extends it to 192 bytes, which is certainly enough. As far
> as I could tell, there are no other constraints that require a specific
> maximum size.
> 
> Signed-off-by: Arnd Bergmann 

Applied.

Re: [PATCH 12/22] vmxnet3: avoid format strint overflow warning

[David Miller]

From: Arnd Bergmann 
Date: Fri, 14 Jul 2017 14:07:04 +0200

> gcc-7 notices that "-event-%d" could be more than 11 characters long
> if we had larger 'vector' numbers:
> 
> drivers/net/vmxnet3/vmxnet3_drv.c: In function 'vmxnet3_activate_dev':
> drivers/net/vmxnet3/vmxnet3_drv.c:2095:40: error: 'sprintf' may write a 
> terminating nul past the end of the destination [-Werror=format-overflow=]
> sprintf(intr->event_msi_vector_name, "%s-event-%d",
>  ^
> drivers/net/vmxnet3/vmxnet3_drv.c:2095:3: note: 'sprintf' output between 9 
> and 33 bytes into a destination of size 32
> 
> The current code is safe, but making the string a little longer
> is harmless and lets gcc see that it's ok.
> 
> Signed-off-by: Arnd Bergmann 

Applied.

Re: [PATCH net-next] cxgb4: Fix tids count for ipv6 offload connection

[David Miller]

From: Ganesh Goudar 
Date: Wed,  7 Jun 2017 15:04:51 +0530

> the adapter consumes two tids for every ipv6 offload
> connection be it active or passive, calculate tid usage
> count accordingly.
> 
> Also change the signatures of relevant functions to get
> the address family.
> 
> Signed-off-by: Rizwan Ansari 
> Signed-off-by: Varun Prakash 
> Signed-off-by: Ganesh Goudar 

Applied, thanks.

Re: [PATCH net-next 0/4] qed: Enhance storage APIs

[David Miller]

From: Yuval Mintz 
Date: Fri, 2 Jun 2017 08:58:29 +0300

> This series is intended to add additional information and features
> to the API between qed and its storage protocol drivers [qedi, qedf].
> 
> Patch #2 adds some information stored on device such as wwpn & wwnn
> to allow qedf utilize it; #1 fixes an issue with the reading of those
> values [which were unused until now].
> 
> Patch #3 would allow the protocol drivers access to images on persistent
> storage which is a prerequirement for adding boot from SAN support.
> 
> Patch #4 adds infrastrucutre to a future feature for qedi.

Series applied.

Re: [PATCH v9 06/15] mlx5: Replace PCI pool old API

[David Miller]

From: Romain Perier 
Date: Tue, 23 May 2017 10:53:36 +0200

> Hello,
> 
> 
> Le 23/05/2017 à 09:27, Leon Romanovsky a écrit :
>> On Mon, May 22, 2017 at 06:48:58PM +0200, Romain Perier wrote:
>>> The PCI pool API is deprecated. This commit replaces the PCI pool old
>>> API by the appropriate function with the DMA pool API.
>>>
>>> Signed-off-by: Romain Perier 
>>> Reviewed-by: Peter Senna Tschudin 
>>> Acked-by: Doug Ledford 
>>> Tested-by: Doug Ledford 
>>> ---
>>>  drivers/net/ethernet/mellanox/mlx5/core/cmd.c | 11 ++-
>>>  include/linux/mlx5/driver.h   |  2 +-
>>>  2 files changed, 7 insertions(+), 6 deletions(-)
>>>
>> Who is supposed to merge this patch series?
>>
>> Acked-by: Leon Romanovsky 
> Each maintainer of the corresponding subsystem, can take a patch, I
> guess. No ?

It might be easier to accumulate acks and you submit them as a series,
in my opinion.

Re: [PATCH v2 net-next] qed: Utilize FW 8.20.0.0

[David Miller]

From: Yuval Mintz 
Date: Thu, 18 May 2017 19:41:04 +0300

> This pushes qed [and as result, all qed* drivers] into using 8.20.0.0
> firmware. The changes are mostly contained in qed with minor changes
> to qedi due to some HSI changes.
> 
> Content-wise, the firmware contains fixes to various issues exposed
> since the release of the previous firmware, including:
>  - Corrects iSCSI fast retransmit when data digest is enabled.
>  - Stop draining packets when receiving several consecutive PFCs.
>  - Prevent possible assertion when consecutively opening/closing
>many connections.
>  - Prevent possible assertion due to too long BDQ fetch time.
> 
> In addition, the new firmware would allow us to later add iWARP support
> in qed and qedr.
> 
> Changes from previous version
> -
>  - V2: Fix warning in qed_debug.c 
> 
> Signed-off-by: Chad Dupuis 
> Signed-off-by: Ram Amrani 
> Signed-off-by: Tomer Tayar 
> Signed-off-by: Manish Rangankar 
> Signed-off-by: Yuval Mintz 

Applied, hopefully this one goes more smoothly.

Thanks.

Re: [PATCH net-next] qed: Utilize FW 8.20.0.0

[David Miller]

From: David Miller <da...@davemloft.net>
Date: Thu, 18 May 2017 10:34:28 -0400 (EDT)

> From: Yuval Mintz <yuval.mi...@cavium.com>
> Date: Wed, 17 May 2017 22:38:40 +0300
> 
>> This pushes qed [and as result, all qed* drivers] into using 8.20.0.0
>> firmware. The changes are mostly contained in qed with minor changes
>> to qedi due to some HSI changes.
>> 
>> Content-wise, the firmware contains fixes to various issues exposed
>> since the release of the previous firmware, including:
>>  - Corrects iSCSI fast retransmit when data digest is enabled.
>>  - Stop draining packets when receiving several consecutive PFCs.
>>  - Prevent possible assertion when consecutively opening/closing
>>many connections.
>>  - Prevent possible assertion due to too long BDQ fetch time.
>> 
>> In addition, the new firmware would allow us to later add iWARP support
>> in qed and qedr.
>> 
>> Signed-off-by: Chad Dupuis <chad.dup...@cavium.com>
>> Signed-off-by: Ram Amrani <ram.amr...@cavium.com>
>> Signed-off-by: Tomer Tayar <tomer.ta...@cavium.com>
>> Signed-off-by: Manish Rangankar <manish.rangan...@cavium.com>
>> Signed-off-by: Yuval Mintz <yuval.mi...@cavium.com>
> 
> Applied.

Actually I had to revert.  Please look at the compiler output before
submitting changes:

drivers/net/ethernet/qlogic/qed/qed_debug.c: In function ‘qed_grc_dump’:
drivers/net/ethernet/qlogic/qed/qed_debug.c:2425:6: warning: ‘addr’ may be used 
uninitialized in this function [-Wmaybe-uninitialized]
  u32 byte_addr = DWORDS_TO_BYTES(addr), offset = 0, i;
  ^
drivers/net/ethernet/qlogic/qed/qed_debug.c:3534:7: note: ‘addr’ was declared 
here
   u32 addr, size = RSS_REG_RSS_RAM_DATA_SIZE;
   ^

'addr' is never, ever, assigned a value, yet it is passed into a function as an
argument.

Re: [PATCH net-next] qed: Utilize FW 8.20.0.0

[David Miller]

From: Yuval Mintz 
Date: Wed, 17 May 2017 22:38:40 +0300

> This pushes qed [and as result, all qed* drivers] into using 8.20.0.0
> firmware. The changes are mostly contained in qed with minor changes
> to qedi due to some HSI changes.
> 
> Content-wise, the firmware contains fixes to various issues exposed
> since the release of the previous firmware, including:
>  - Corrects iSCSI fast retransmit when data digest is enabled.
>  - Stop draining packets when receiving several consecutive PFCs.
>  - Prevent possible assertion when consecutively opening/closing
>many connections.
>  - Prevent possible assertion due to too long BDQ fetch time.
> 
> In addition, the new firmware would allow us to later add iWARP support
> in qed and qedr.
> 
> Signed-off-by: Chad Dupuis 
> Signed-off-by: Ram Amrani 
> Signed-off-by: Tomer Tayar 
> Signed-off-by: Manish Rangankar 
> Signed-off-by: Yuval Mintz 

Applied.

Re: [PATCH 3/3] ide-pm: always pass 0 error to ide_complete_rq in ide_do_devset

[David Miller]

From: Christoph Hellwig 
Date: Wed, 26 Apr 2017 09:34:22 +0200

> The caller only looks at the scsi_request result field anyway.
> 
> Signed-off-by: Christoph Hellwig 

Acked-by: David S. Miller 

Re: [PATCH 2/3] ide-pm: always pass 0 error to __blk_end_request_all

[David Miller]

From: Christoph Hellwig 
Date: Wed, 26 Apr 2017 09:34:21 +0200

> ide_pm_execute_rq exectures a PM request synchronously, and in the failure
> case where it calls __blk_end_request_all it never checks the error field
> passed to the end_io callback, so don't bother setting it.
> 
> Signed-off-by: Christoph Hellwig 

Acked-by: David S. Miller 

Re: [PATCH] qedf: fix wrong le16 conversion

[David Miller]

From: "Martin K. Petersen" 
Date: Thu, 23 Mar 2017 10:19:03 -0400

> Arnd Bergmann  writes:
> 
>> gcc points out that we are converting a 16-bit integer into a 32-bit
>> little-endian type and assigning that to 16-bit little-endian
>> will end up with a zero:
>>
>> drivers/scsi/qedf/drv_fcoe_fw_funcs.c: In function 
>> 'init_initiator_rw_fcoe_task':
>> include/uapi/linux/byteorder/big_endian.h:32:26: error: large integer 
>> implicitly truncated to unsigned type [-Werror=overflow]
>>   t_st_ctx->read_write.rx_id = cpu_to_le32(FCOE_RX_ID);
>>
>> The correct solution appears to be to just use a 16-bit byte swap instead.
>>
>> Fixes: be086e7c53f1 ("qed*: Utilize Firmware 8.15.3.0")
>> Signed-off-by: Arnd Bergmann 
>> ---
>>  drivers/scsi/qedf/drv_fcoe_fw_funcs.c | 6 +++---
>>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> Dave: Since you queued the firmware patch, mind taking this fix through
> your tree?

Ok, applied to net-next, thanks.

Re: [PATCH v2 net-next] qed*: Utilize Firmware 8.15.3.0

[David Miller]

From: Christoph Hellwig <h...@infradead.org>
Date: Mon, 13 Mar 2017 16:19:47 -0700

> On Mon, Mar 13, 2017 at 03:33:47PM -0700, David Miller wrote:
>> Applied, thanks.
> 
> So everyone who doesn't have the very latests linux-firmware will now
> have a non-working card after upgrading the kernel?

I deeply regret that you've missed more than a decade of precedence on
this matter.

Re: [PATCH v2 net-next] qed*: Utilize Firmware 8.15.3.0

[David Miller]

From: Yuval Mintz 
Date: Sat, 11 Mar 2017 18:39:18 +0200

> This patch advances the qed* drivers into using the newer firmware -
> This solves several firmware bugs, mostly related [but not limited to]
> various init/deinit issues in various offloaded protocols.
> 
> It also introduces a major 4-Cached SGE change in firmware, which can be
> seen in the storage drivers' changes.
> 
> In addition, this firmware is required for supporting the new QL41xxx
> series of adapters; While this patch doesn't add the actual support,
> the firmware contains the necessary initialization & firmware logic to
> operate such adapters [actual support would be added later on].
> 
> Changes from Previous versions:
> ---
>  - V2 - fix kbuild-test robot warnings
> 
> Signed-off-by: Tomer Tayar 
> Signed-off-by: Ram Amrani 
> Signed-off-by: Manish Rangankar 
> Signed-off-by: Chad Dupuis 
> Signed-off-by: Yuval Mintz 

Applied, thanks.

Re: [PATCH V5 net-next 1/2] qed: Add support for hardware offloaded FCoE.

[David Miller]

Applied to net-next, thanks.

Re: [PATCH V4 net-next 1/2] qed: Add support for hardware offloaded FCoE.

[David Miller]

From: "Dupuis, Chad" 
Date: Mon, 13 Feb 2017 11:17:00 -0800

> @@ -255,6 +259,10 @@ struct qed_hw_info {
>   u32 part_num[4];
>  
>   unsigned char   hw_mac_addr[ETH_ALEN];
> + u64 node_wwn;
> + u64 port_wwn;
> +
> + u16 num_fcoe_conns;

This new num_fcoe_conns member should be indented just like the rest of them.

> +static int
> +qed_sp_fcoe_func_start(struct qed_hwfn *p_hwfn,
> +enum spq_mode comp_mode,
> +struct qed_spq_comp_cb *p_comp_addr)
> +{
> + struct qed_fcoe_pf_params *fcoe_pf_params = NULL;
> + struct fcoe_init_ramrod_params *p_ramrod = NULL;
> + struct fcoe_conn_context *p_cxt = NULL;
> + struct qed_spq_entry *p_ent = NULL;
> + struct fcoe_init_func_ramrod_data *p_data;
> + int rc = 0;
> + struct qed_sp_init_data init_data;
> + struct qed_cxt_info cxt_info;
> + u32 dummy_cid;
> + u16 tmp;
> + u8 i;

Please order local variable declarations from larget the smallest line.

> +#else /* CONFIG_QED_FCOE */
> +static inline struct qed_fcoe_info *
> +qed_fcoe_alloc(struct qed_hwfn *p_hwfn) { return NULL; }
> +static inline void
> +qed_fcoe_setup(struct qed_hwfn *p_hwfn, struct qed_fcoe_info *p_fcoe_info) {}
> +static inline void
> +qed_fcoe_free(struct qed_hwfn *p_hwfn, struct qed_fcoe_info *p_fcoe_info) {}
> +static inline void
> +qed_get_protocol_stats_fcoe(struct qed_dev *cdev,
> + struct qed_mcp_fcoe_stats *stats) {}

Please do not format these functions so compactly, they are very difficult to
read.  Format them just like normal functions.

Re: [PATCH] cdrom: Make device operations read-only

[David Miller]

From: Kees Cook 
Date: Mon, 13 Feb 2017 16:25:26 -0800

> diff --git a/drivers/ide/ide-cd.c b/drivers/ide/ide-cd.c
> index 9cbd217bc0c9..ab9232e1e16f 100644
> --- a/drivers/ide/ide-cd.c
> +++ b/drivers/ide/ide-cd.c
> @@ -1166,7 +1166,7 @@ void ide_cdrom_update_speed(ide_drive_t *drive, u8 *buf)
>CDC_CD_RW | CDC_DVD | CDC_DVD_R | CDC_DVD_RAM | CDC_GENERIC_PACKET | \
>CDC_MO_DRIVE | CDC_MRW | CDC_MRW_W | CDC_RAM)
>  
> -static struct cdrom_device_ops ide_cdrom_dops = {
> +static const struct cdrom_device_ops ide_cdrom_dops = {
>   .open   = ide_cdrom_open_real,
>   .release= ide_cdrom_release_real,
>   .drive_status   = ide_cdrom_drive_status,

Acked-by: David S. Miller 

Re: [PATCH net-next v2 00/12] net: dsa: remove unnecessary phy.h include

[David Miller]

From: Kalle Valo 
Date: Thu, 09 Feb 2017 16:10:06 +0200

> Florian Fainelli  writes:
> 
 If not, for something like this it's a must:

 drivers/net/wireless/ath/wil6210/cfg80211.c:24:30: error: expected ‘)’ 
 before ‘bool’
  module_param(disable_ap_sme, bool, 0444);
   ^
 drivers/net/wireless/ath/wil6210/cfg80211.c:25:34: error: expected ‘)’ 
 before string constant
  MODULE_PARM_DESC(disable_ap_sme, " let user space handle AP mode SME");
   ^
 Like like that file needs linux/module.h included.
>>> 
>>> Johannes already fixed a similar (or same) problem in my tree:
>>> 
>>> wil6210: include moduleparam.h
>>> 
>>> https://git.kernel.org/cgit/linux/kernel/git/kvalo/wireless-drivers-next.git/commit/?id=949c2d0096753d518ef6e0bd8418c8086747196b
>>> 
>>> I'm planning to send you a pull request tomorrow which contains that
>>> one.
>>
>> Thanks Kalle!
>>
>> David, can you hold on this series until Kalle's pull request gets
>> submitted? Past this error, allmodconfig builds fine with this patch
>> series (just tested). Thanks!
> 
> Just submitted the pull request:
> 
> https://patchwork.ozlabs.org/patch/726133/

I've retried this patch series, and will push it out assuming the build
completes properly.

Re: [PATCH net-next v2 00/12] net: dsa: remove unnecessary phy.h include

[David Miller]

From: Florian Fainelli 
Date: Tue,  7 Feb 2017 15:02:53 -0800

> I'm hoping this doesn't conflict with what's already in net-next...
> 
> David, this should probably go via your tree considering the diffstat.

I think you need one more respin.  Are you doing an allmodconfig build?
If not, for something like this it's a must:

drivers/net/wireless/ath/wil6210/cfg80211.c:24:30: error: expected ‘)’ before 
‘bool’
 module_param(disable_ap_sme, bool, 0444);
  ^
drivers/net/wireless/ath/wil6210/cfg80211.c:25:34: error: expected ‘)’ before 
string constant
 MODULE_PARM_DESC(disable_ap_sme, " let user space handle AP mode SME");
  ^
Like like that file needs linux/module.h included.

Thanks.

Re: [PATCHv1] net-next: treewide use is_vlan_dev() helper function.

[David Miller]

From: Parav Pandit 
Date: Sat,  4 Feb 2017 11:00:49 -0600

> This patch makes use of is_vlan_dev() function instead of flag
> comparison which is exactly done by is_vlan_dev() helper function.
> 
> Signed-off-by: Parav Pandit 
> Reviewed-by: Daniel Jurgens 

Applied.

Re: [PATCH 1/2] qed: Add support for hardware offloaded FCoE.

[David Miller]

From: Chad Dupuis 
Date: Mon, 16 Jan 2017 16:47:52 -0500

> I forgot to add netdev-next to the subject line.  Is a repost needed
> here?

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

Re: [PATCH] scsi: mpt3sas: fix hang on ata passthru commands

[David Miller]

From: Bart Van Assche 
Date: Sun, 1 Jan 2017 14:22:11 +

> My recommendation is to revert commit 18f6084a989b ("scsi: mpt3sas: Fix
> secure erase premature termination"). Since the mpt3sas driver uses the
> single-queue approach and since the SCSI core unlocks the block layer
> request queue lock before the .queuecommand callback function is called,
> multiple threads can execute that callback function (scsih_qcmd() in this
> case) simultaneously. This means that using scsi_internal_device_block()
> from inside .queuecommand to serialize SCSI command execution is wrong.

But this causes a regression for the thing being fixed by that commit.

Why don't we figure out what that semantics that commit was trying to
achieve and implement that properly?
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] scsi: mpt3sas: fix hang on ata passthru commands

[David Miller]

From: Jason Baron 
Date: Wed, 28 Dec 2016 23:30:24 -0500

> On ata passthru commands scsih_qcmd() ends up spinning in
> scsi_wait_for_queuecommand() indefinitely. scsih_qcmd() is called from
> __blk_run_queue_uncond() which first increments request_fn_active to a
> non-zero value. Thus, scsi_wait_for_queuecommand() never completes because
> its spinning waiting for request_fn_active to become 0.
> 
> Two patches interact here. The first:
> 
> commit 18f6084a989b ("scsi: mpt3sas: Fix secure erase premature
> termination") calls scsi_internal_device_block() for ata passthru commands.
> 
> The second patch:
> 
> commit 669f044170d8 ("scsi: srp_transport: Move queuecommand() wait code
> to SCSI core") adds a call to scsi_wait_for_queuecommand() from
> scsi_internal_device_block().
> 
> Add a new parameter to scsi_internal_device_block() to decide whether
> or not to invoke scsi_wait_for_queuecommand().
> 
> Signed-off-by: Jason Baron 

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

Bootup regression from srp_transport queuecommand() change...

[David Miller]

Commit 669f044170d8933c3d66d231b69ea97cb8447338 ("scsi: srp_transport:
Move queuecommand() wait code to SCSI core") causes my sparc64 T4-2
machine to stop booting properly.

It gets past mounting root but then the disk seems to wedge and scsi
command resets don't seem to improve the situation.

The controller on this machine is an mpt2sas:

[  988.085192] mpt3sas version 14.101.00.00 loaded
[  988.094440] mpt2sas_cm0: 32 BIT PCI BUS DMA ADDRESSING SUPPORTED, total mem 
(265775888 kB)
[  988.165492] mpt2sas_cm0: MSI-X vectors supported: 1, no of cores: 128, 
max_msix_vectors: -1
[  988.182124] mpt2sas0-msix0: PCI-MSI-X enabled: IRQ 166
[  988.192152] mpt2sas_cm0: iomem(0x08400120), 
mapped(0x08400120), size(16384)
[  988.208816] mpt2sas_cm0: ioport(0x08512000), size(256)
[  988.305669] mpt2sas_cm0: Allocated physical memory: size(2324 kB)
[  988.317563] mpt2sas_cm0: Current Controller Queue Depth(1529),Max Controller 
Queue Depth(1600)
[  988.334753] mpt2sas_cm0: Scatter Gather Elements per IO(128)
[  988.396240] mpt2sas_cm0: LSISAS2008: FWVersion(09.00.00.00), 
ChipRevision(0x03), BiosVersion(00.00.00.00)
[  988.415087] mpt2sas_cm0: Protocol=(
[  988.415089] Initiator
[  988.422032] ,Target
[  988.426532] ), 
[  988.430707] Capabilities=(
[  988.434167] Raid
[  988.439558] ,TLR
[  988.443212] ,EEDP
[  988.446853] ,Snapshot Buffer
[  988.450676] ,Diag Trace Buffer
[  988.456409] ,Task Set Full
[  988.462487] ,NCQ
[  988.467874] )
[  988.474803] scsi host0: Fusion MPT SAS Host
[  988.484310] mpt2sas_cm0: sending port enable !!
[  990.014651] mpt2sas_cm0: host_add: handle(0x0001), 
sas_addr(0x508002f7b908), phys(8)
[  996.139132] mpt2sas_cm0: port enable: SUCCESS
[  996.170653] scsi 0:0:0:0: Direct-Access ATA  INTEL SSDSC2CW48 400i 
PQ: 0 ANSI: 5
[  996.186607] scsi 0:0:0:0: SATA: handle(0x0009), 
sas_addr(0x44332211), phy(0), device_name(0x517b5001f9f6b27f)
[  996.207728] scsi 0:0:0:0: SATA: enclosure_logical_id(0x508002f7b908), 
slot(0)
[  996.222818] scsi 0:0:0:0: atapi(n), ncq(y), asyn_notify(n), smart(y), 
fua(y), sw_preserve(y)
[  996.344371] scsi 0:0:1:0: CD-ROMTEAC DV-W28SS-R   1.0C 
PQ: 0 ANSI: 0
[  996.360272] scsi 0:0:1:0: SATA: handle(0x000a), 
sas_addr(0x443322110700), phy(7), device_name(0x)
[  996.381442] scsi 0:0:1:0: SATA: enclosure_logical_id(0x508002f7b908), 
slot(7)

It was not easy to track this down.

Initial bisect hit the scsi-misc merge itself, bisecting within the
merge doesn't find the commit mentioned above.

So I went throught the commits in the scsi-misc merge one by one,
adding them on top of vanilla v4.9 until I hit the problem.

This means the above commit doesn't introduce the regression in the
context in which it was made.

The commit message mentions blockability.  So I tried to look at
mpt3sas driver changes that happened in mainline meanwhile.  And
I came upon commit 18f6084a989ba1b38702f9af37a2e4049a924be6
("scsi: mpt3sas: Fix secure erase premature termination")

And this, indeed, adds a new call to scsi_internal_device_block()
inside of the queuecommand() method of the mpt3sas driver.

This seems to invalidate the analysis done in the commit message of
669f044170d8933c3d66d231b69ea97cb8447338 ("scsi: srp_transport: Move
queuecommand() wait code to SCSI core").

I guess some userland information gathering tool, udev, or similar is
doing the passthru ATA command to the devices behind my mpt2sas host,
triggering the logic there to call scsi_internal_device_block().

I'm happy to test any changes, and would really like to see this bug
fixed.

Thanks!

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

Re: [PATCH v3 0/3] Add QLogic FastLinQ iSCSI (qedi) driver.

[David Miller]

From: "Rangankar, Manish" 
Date: Fri, 2 Dec 2016 07:00:39 +

> Please consider applying the qed patches 1 & 2 to net-next.

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

Re: [PATCH v2] qlogicpti: Fix compiler warnings

[David Miller]

From: Tushar Dave 
Date: Wed, 23 Nov 2016 18:28:04 -0800

> qlogicpti uses '__u32' for dma handle while invoking kernel DMA APIs,
> instead of using dma_addr_t. This hasn't caused any 'incompatible
> pointer type' warning on SPARC because until now dma_addr_t is of
> type u32. However, recent changes in SPARC ATU (iommu) enabled 64bit
> DMA and therefore dma_addr_t became of type u64. This makes
> 'incompatible pointer type' warnings inevitable.
> 
> e.g.
> drivers/scsi/qlogicpti.c: In function ‘qpti_map_queues’:
> drivers/scsi/qlogicpti.c:813: warning: passing argument 3 of 
> ‘dma_alloc_coherent’ from incompatible pointer type
> ./include/linux/dma-mapping.h:445: note: expected ‘dma_addr_t *’ but argument 
> is of type ‘__u32 *’
> drivers/scsi/qlogicpti.c:822: warning: passing argument 3 of 
> ‘dma_alloc_coherent’ from incompatible pointer type
> ./include/linux/dma-mapping.h:445: note: expected ‘dma_addr_t *’ but argument 
> is of type ‘__u32 *’
> 
> For the record, qlogicpti never executes on sun4v. Therefore even
> though 64bit DMA is enabled on SPARC, qlogicpti continues to use
> legacy iommu that guarantees DMA address is always in 32bit range.
> 
> This patch resolves aforementioned compiler warnings.
> 
> Signed-off-by: Tushar Dave 
> Reviewed-by: thomas tai 

Applied.
N‹§²ζμrΈ›yϊθšΨb²X¬ΆΗ§vΨ^–)ήΊ{.nΗ+‰·₯Š{±±Λ"Š{ayΊΚ‡Ϊ™λ,j­’f£’·hš‹ΰzΉ�w₯’Έ
’·¦j:+v‰¨ŠwθjΨmΆŸ�Ύ«‘κηzZ+ƒωšŽŠέ’j"ϊ!Άi

Re: [PATCH] qlogicpti: Fix compiler warnings

[David Miller]

From: tndave 
Date: Wed, 23 Nov 2016 17:08:23 -0800

> As per my understanding, I think, all DMA map/unmap go through
> ATU (iommu) in sun4v sparc. To guarantee that driver doesn't get DMA
> address beyond its addressable range , driver must set dma mask before
> requesting any DMA mapping!
> 
> I will investigate further and send v2.
> 
> Thanks for the review.

This is an SBUS driver, it's not going to execute on any sun4v
system.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] qlogicpti: Fix compiler warnings

[David Miller]

From: James Bottomley 
Date: Wed, 23 Nov 2016 14:57:39 -0800

> What's the guarantee, since the device descriptors only cope with 32
> bits of physical address, that this driver never gets any dma address
> beyond its addressable range?  Is it that the sbus can never be
> attached to this ATU type IOMMU?  If so, saying that in the log would
> be useful.

SBUS hasn't changed for 20 years and is a 32-bit bus.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH net-next] cxgb4: Allocate Tx queues dynamically

[David Miller]

From: Atul Gupta 
Date: Fri, 18 Nov 2016 16:37:40 +0530

> From: Hariprasad Shenai 
> 
> Allocate resources dynamically for Upper layer driver's (ULD) like
> cxgbit, iw_cxgb4, cxgb4i and chcr. The resources allocated include Tx
> queues which are allocated when ULD register with cxgb4 driver and freed
> while un-registering. The Tx queues which are shared by ULD shall be
> allocated by first registering driver and un-allocated by last
> unregistering driver.
> 
> Signed-off-by: Atul Gupta 

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

Re: [PATCH net-next] chcr/cxgb4i/cxgbit/RDMA/cxgb4: Allocate resources dynamically for all cxgb4 ULD's

[David Miller]

From: Hariprasad Shenai 
Date: Sat, 17 Sep 2016 08:12:39 +0530

> Allocate resources dynamically to cxgb4's Upper layer driver's(ULD) like
> cxgbit, iw_cxgb4 and cxgb4i. Allocate resources when they register with
> cxgb4 driver and free them while unregistering. All the queues and the
> interrupts for them will be allocated during ULD probe only and freed
> during remove.
> 
> Signed-off-by: Hariprasad Shenai 

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

Re: [net-next v3 0/6] common library for Chelsio drivers.

[David Miller]

From: Varun Prakash 
Date: Thu, 21 Jul 2016 22:57:13 +0530

> Hi,
> 
>  This patch series adds common library module(libcxgb.ko)
>  for Chelsio drivers to remove duplicate code.
> 
>  This series moves common iSCSI DDP Page Pod manager
>  code from cxgb4.ko to libcxgb.ko, earlier this code
>  was used by only cxgbit.ko now it is used by
>  three Chelsio iSCSI drivers cxgb3i, cxgb4i, cxgbit.
> 
>  In future this module will have common connection
>  management and hardware specific code that can
>  be shared by multiple Chelsio drivers(cxgb4,
>  csiostor, iw_cxgb4, cxgb4i, cxgbit).
> 
>  Please review.
> 
>  Thanks
> 
> -v3
> - removed unused module init and exit functions.

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

Re: [net-next v2 0/6] common library for Chelsio drivers

[David Miller]

From: "Nicholas A. Bellinger" 
Date: Wed, 20 Jul 2016 14:13:55 -0700

> DaveM, if you'd prefer to pick it up, I'm happy to drop it.

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

Re: [net-next v2 1/6] libcxgb: add library module for Chelsio drivers

[David Miller]

From: Varun Prakash 
Date: Sat, 16 Jul 2016 22:49:15 +0530

>  }
> +
> +static int __init libcxgb_init(void)
> +{
> + return 0;
> +}
> +
> +static void __exit libcxgb_exit(void)
> +{
> +}
> +
> +module_init(libcxgb_init);
> +module_exit(libcxgb_exit);

If these functions don't have to do anything, you can remove this
entire sequence entirely.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [net-next 0/6] common library for Chelsio drivers

[David Miller]

From: Varun Prakash 
Date: Fri,  8 Jul 2016 23:03:53 +0530

> Hi,
> 
>  This patch series adds common library module(libcxgb.ko)
> for Chelsio drivers to remove duplicate code.
> 
> This series moves common iSCSI DDP Page Pod manager
> code from cxgb4.ko to libcxgb.ko, earlier this code
> was used by only cxgbit.ko now it is used by
> three Chelsio iSCSI drivers cxgb3i, cxgb4i, cxgbit.
> 
> In future this module will have common connection
> management and hardware specific code that can
> be shared by multiple Chelsio drivers(cxgb4,
> csiostor, iw_cxgb4, cxgb4i, cxgbit).
> 
> Please review.

As currently implemented the user is prompted for the Kconfig symbol
for the library.  That really needs to be hidden from the user and
they should be able to select these drivers without having to know
about this implementation detail at all.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] cxgbi: fix uninitialized flowi6

[David Miller]

From: Jiri Benc 
Date: Fri, 22 Apr 2016 13:09:13 +0200

> ip6_route_output looks into different fields in the passed flowi6 structure,
> yet cxgbi passes garbage in nearly all those fields. Zero the structure out
> first.
> 
> Fixes: fc8d0590d9142 ("libcxgbi: Add ipv6 api to driver")
> Signed-off-by: Jiri Benc 

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

Re: [PATCH net] bnx2x: Prevent false warning for lack of FC NPIV

[David Miller]

From: Yuval Mintz 
Date: Tue, 15 Mar 2016 19:52:04 +0200

> Not all adapters have FC-NPIV configured. If bnx2fc is used with such an
> adapter, driver would read irrelevant data from the the nvram and log
> "FC-NPIV table with bad length..." In system logs.
> 
> Simply accept that reading '0' as the feature offset in nvram indicates
> the feature isn't there and return.
> 
> Reported-by: Andrew Patterson 
> Signed-off-by: Yuval Mintz 

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

Re: [PATCH net-next v3 0/4] uapi: consolidate DIV_ROUND_UP definition

[David Miller]

From: Nicolas Dichtel 
Date: Fri,  4 Mar 2016 11:52:15 +0100

> The inital goal was to consolidate ethtool.h uapi header. But I took the
> opportunity to remove all duplicate definitions of DIV_ROUND_UP.
> 
> v3: add patch #2 and #3
> 
> v2: split the patch
> define DIV_ROUND_UP in uapi

Series applied, thanks for so thoroughly taking care of this.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH net-next] cxgb4i: Increased the value of MAX_IMM_TX_PKT_LEN from 128 to 256 bytes

[David Miller]

From: Karen Xie 
Date: Tue, 13 Oct 2015 17:13:59 -0700

> This helps improving the latency of small packets.
> 
> Signed-off-by: Rakesh Ranjan 
> Signed-off-by: Karen Xie 

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

Re: [RFC][PATCH] x86: remove vmalloc.h from asm/io.h

[David Miller]

From: Stephen Rothwell s...@canb.auug.org.au
Date: Fri, 29 May 2015 19:18:47 +1000

 Nothing in asm/io.h uses anything from vmalloc.h, so remove the include
 and fix up the build problems in an allmodconfig (64 bit and 32 bit)
 build.
 
 This may be the place where x86 builds get vmalloc.h implicitly included
 and that tends to hide places where vmalloc() et al are added to files
 but the include of vmalloc.h is forgotten.
 
 ...
 Suggested-by: David Miller da...@davemloft.net
 Signed-off-by: Stephen Rothwell s...@canb.auug.org.au

With the follow-on allnoconfig fixes:

Acked-by: David S. Miller da...@davemloft.net

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

Re: [PATCH net-next] qla4xxx: add a missing include

[David Miller]

From: Eric Dumazet eric.duma...@gmail.com
Date: Tue, 26 May 2015 21:43:44 -0700

 From: Eric Dumazet edum...@google.com
 
 vmalloc.h used to be included from include/net/inet_hashtables.h
 but it is no longer the case.
 
 Fixes: 095dc8e0c368 (tcp: fix/cleanup inet_ehash_locks_alloc())
 Reported-by: kbuild test robot fengguang...@intel.com
 Signed-off-by: Eric Dumazet edum...@google.com
 ---
 Given its broken in David net-next tree, its probably simpler
 that David merges this fix directly ? Thanks !

Yeah it's easiest if I just apply this to net-next, which I've just done,
thanks Eric.
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH net-next v2 3/4] cxgb4: add DDP support for FCoE target

[David Miller]

From: Varun Prakash va...@chelsio.com
Date: Mon, 13 Apr 2015 19:34:25 +0530

 diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_fcoe.c 
 b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_fcoe.c
 index 6c8a62e..f78d632 100644
 --- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_fcoe.c
 +++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_fcoe.c
...
 + */
 +static inline unsigned int pages2ppods(unsigned int pages)
 +{
 + return (pages + PPOD_PAGES - 1) / PPOD_PAGES +

Please do not ever use inline in foo.c file function definitions.  Let
the compiler decide on it's own.

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

Re: [PATCH net-next 0/3] cxgb4: add FCoE DDP and RSS

[David Miller]

From: David Miller da...@davemloft.net
Date: Tue, 31 Mar 2015 12:04:13 -0400 (EDT)

 From: Varun Prakash va...@chelsio.com
 Date: Fri, 27 Mar 2015 20:29:36 +0530
 
 This patch series enables RSS for FCoE frames and adds
 DDP support for FCoE target.
 
 Series applied, thanks Varun.

I have to revert, this series breaks the build:

[davem@localhost net-next]$ make -s -j8
In file included from drivers/infiniband/hw/cxgb4/t4.h:37:0,
 from drivers/infiniband/hw/cxgb4/iw_cxgb4.h:73,
 from drivers/infiniband/hw/cxgb4/device.c:40:
drivers/infiniband/hw/cxgb4/t4fw_ri_api.h:821:8: error: redefinition of ‘struct 
ulptx_idata’
 struct ulptx_idata {
^
In file included from drivers/infiniband/hw/cxgb4/t4.h:36:0,
 from drivers/infiniband/hw/cxgb4/iw_cxgb4.h:73,
 from drivers/infiniband/hw/cxgb4/device.c:40:
drivers/net/ethernet/chelsio/cxgb4/t4_msg.h:1110:8: note: originally defined 
here
 struct ulptx_idata {
^
scripts/Makefile.build:258: recipe for target 
'drivers/infiniband/hw/cxgb4/device.o' failed
make[4]: *** [drivers/infiniband/hw/cxgb4/device.o] Error 1
make[4]: *** Waiting for unfinished jobs
In file included from drivers/infiniband/hw/cxgb4/t4.h:37:0,
 from drivers/infiniband/hw/cxgb4/iw_cxgb4.h:73,
 from drivers/infiniband/hw/cxgb4/cm.c:52:
drivers/infiniband/hw/cxgb4/t4fw_ri_api.h:821:8: error: redefinition of ‘struct 
ulptx_idata’
 struct ulptx_idata {
^
In file included from drivers/infiniband/hw/cxgb4/t4.h:36:0,
 from drivers/infiniband/hw/cxgb4/iw_cxgb4.h:73,
 from drivers/infiniband/hw/cxgb4/cm.c:52:
drivers/net/ethernet/chelsio/cxgb4/t4_msg.h:1110:8: note: originally defined 
here
 struct ulptx_idata {
^
scripts/Makefile.build:258: recipe for target 
'drivers/infiniband/hw/cxgb4/cm.o' failed
make[4]: *** [drivers/infiniband/hw/cxgb4/cm.o] Error 1
scripts/Makefile.build:403: recipe for target 'drivers/infiniband/hw/cxgb4' 
failed
make[3]: *** [drivers/infiniband/hw/cxgb4] Error 2
make[3]: *** Waiting for unfinished jobs
scripts/Makefile.build:403: recipe for target 'drivers/infiniband/hw' failed
make[2]: *** [drivers/infiniband/hw] Error 2
make[2]: *** Waiting for unfinished jobs
scripts/Makefile.build:403: recipe for target 'drivers/infiniband' failed
make[1]: *** [drivers/infiniband] Error 2
make[1]: *** Waiting for unfinished jobs
Makefile:947: recipe for target 'drivers' failed
make: *** [drivers] Error 2
make: *** Waiting for unfinished jobs
[davem@localhost net-next]$ 
N‹§²ζμrΈ›yϊθšΨb²X¬ΆΗ§vΨ^–)ήΊ{.nΗ+‰·₯Š{±±ΛŠ{ayΊΚ‡Ϊ™λ,j­’f£’·hš‹ΰzΉ�w₯’Έ
’·¦j:+v‰¨ŠwθjΨmΆŸ�Ύ«‘κηzZ+ƒωšŽŠέ’jϊ!Άi

Re: [PATCH net-next 0/3] cxgb4: add FCoE DDP and RSS

[David Miller]

From: Varun Prakash va...@chelsio.com
Date: Fri, 27 Mar 2015 20:29:36 +0530

 This patch series enables RSS for FCoE frames and adds
 DDP support for FCoE target.

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

Re: [PATCH 0/3] FCoE support in cxgb4 driver

[David Miller]

From: Varun Prakash va...@chelsio.com
Date: Tue, 24 Mar 2015 19:14:44 +0530

 This patch series enables FCoE support in cxgb4 driver, it enables
 FCOE_CRC and FCOE_MTU net device features.
 
 This series is created against net-next tree.

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

Re: [PATCH] csiostor:Use firmware version from cxgb4/t4fw_version.h

[David Miller]

From: Praveen Madhavan prave...@chelsio.com
Date: Tue,  3 Feb 2015 17:18:26 +0530

 This patch is to use firmware version macros from t4fw_version.h
 and also enables 40g T5 adapter.
 
 Signed-off-by: Praveen Madhavan prave...@chelsio.com

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

Re: [PATCH] csiostor:T5 Firmware fix and cleanup.

[David Miller]

From: Praveen Madhavan prave...@chelsio.com
Date: Tue, 27 Jan 2015 19:46:37 +0530

 This patch fix is to use default firmware configuration files
 present in the adapter incase if not available in standard
 /lib/firmware/* dir. Additional cleanup is done to reuse flash
 related defines from cxgb4 header file.
 
 Please apply over net-next since it depends on previous commit.
 
 Signed-off-by: Praveen Madhavan prave...@chelsio.com

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

Re: [PATCH v2 0/2] csiostor:Remove T4 FCoE support

[David Miller]

From: Praveen Madhavan prave...@chelsio.com
Date: Fri, 16 Jan 2015 21:30:18 +0530

 We found a subtle issue with FCoE on T4 very late in the game
 and decided not to productize FCoE on T4 and therefore there
 are no customers that will be impacted by this change. FCoE is
 supported on T5 cards.
 
 Please apply on net-next since depends on previous commits.
 
 Changes in v2:
   - Make the commit message more clearer.

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

Re: [PATCH 0/2] Remove T4 FCoE support

[David Miller]

From: Praveen Madhavan prave...@chelsio.com
Date: Thu, 15 Jan 2015 19:15:50 +0530

 These patches removes FCoE support for chelsio T4 adapter.
 Please apply on net-next since depends on previous commits.

Why is it being removed?  You have to state this in the
commit log messages at a minimum.
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH net-next 0/2] All Chelsio drivers : Cleanup CPL messages macros

[David Miller]

From: Anish Bhatt an...@chelsio.com
Date: Thu,  8 Jan 2015 21:38:14 -0800

 This patch series cleans up all register defines/MACROS defined in t4_msg.h 
 and
 affected files as part of the continuing cleanup effort
 
 The patches series is created against 'net-next' tree and  includes patches 
 to the cxgb4, cxgb4vf, iw_cxgb4, cxgb4i and csiostor drivers.
 
 We have included all the maintainers of respective drivers. Kindly review the
 change and let us know in case of any review comments.

Looks fine, applied to net-next, thanks.
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 4/4] scsi: esp_scsi: adjust module reference for scsi host

[David Miller]

From: Akinobu Mita akinobu.m...@gmail.com
Date: Sun, 11 Jan 2015 22:50:06 +0900

 While accessing a scsi device on host adapter supported by sub driver for
 the ESP chip (mac_esp, am53c974, sun_esp, jazz_esp, sun3x_esp), the module
 reference count is not incremented.  Because these drivers allocate scsi
 hosts with scsi_esp_template defined in ESP SCSI driver core module.  So
 these drivers always can be unloaded.
 
 This fixes it by passing correct module reference to newly introduced
 scsi_esp_host_alloc() so that .module field in struct Scsi_Host can be
 adjusted.
 
 Signed-off-by: Akinobu Mita akinobu.m...@gmail.com

Looks fine to me, thanks for fixing this:

Acked-by: David S. Miller da...@davemloft.net
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/1] csiostor:fix sparse warnings

[David Miller]

From: Praveen Madhavan prave...@chelsio.com
Date: Fri,  9 Jan 2015 21:25:16 +0530

 This patch fixes sparse warning reported by kbuild.
 Apply this on net-next since it depends on previous commit.
 
 drivers/scsi/csiostor/csio_hw.c:259:17: sparse: cast to restricted __le32
 drivers/scsi/csiostor/csio_hw.c:536:31: sparse: incorrect type in assignment
 (different base types)
 drivers/scsi/csiostor/csio_hw.c:536:31:expected unsigned int [unsigned]
 [usertype] noident
 drivers/scsi/csiostor/csio_hw.c:536:31:got restricted __be32 [usertype]
 noident
 drivers/scsi/csiostor/csio_hw.c:2012:5: sparse: symbol 'csio_hw_prep_fw' was
 not declared. Should it be static?
 
 Signed-off-by: Praveen Madhavan prave...@chelsio.com

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

Re: [PATCH] csiostor:firmware upgrade fix

[David Miller]

From: Praveen Madhavan prave...@chelsio.com
Date: Wed,  7 Jan 2015 19:16:28 +0530

 This patch fixes removes older means of upgrading Firmware using MAJOR version
 and adds newer interface version checking mechanism.
 
 Please apply this patch on net-next since it depends on previous commits.
 
 Signed-off-by: Praveen Madhavan prave...@chelsio.com

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

Re: [PATCH net-next 0/5] RDMA/cxgb4/cxgb4vf/csiostor: Cleanup register defines

[David Miller]

From: Hariprasad Shenai haripra...@chelsio.com
Date: Mon,  5 Jan 2015 16:30:42 +0530

 This series continues to cleanup all the macros/register defines related to
 SGE, PCIE, MC, MA, TCAM, MAC, etc that are defined in t4_regs.h and the
 affected files.
 
 Will post another 1 or 2 series so that we can cover all the macros so that
 they all follow the same style to be consistent.
 
 The patches series is created against 'net-next' tree.
 And includes patches on cxgb4, cxgb4vf, iw_cxgb4 and csiostor driver.
 
 We have included all the maintainers of respective drivers. Kindly review the
 change and let us know in case of any review comments.

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

Re: [PATCH net-next v10 0/7] cxgb4/cxgbi: misc. fixes for cxgb4i

[David Miller]

From: Karen Xie k...@chelsio.com
Date: Thu, 11 Dec 2014 19:13:26 -0800

 This patch set fixes cxgb4i's tx credit calculation and adds handling of
 additional rx message and negative advice types. It also removes the duplicate
 code in cxgb4i to set the outgoing queues of a packet. 

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

Re: [PATCH] cxgb4/csiostor: Don't use MASTER_MUST for fw_hello call

[David Miller]

From: Hariprasad Shenai haripra...@chelsio.com
Date: Thu, 11 Dec 2014 11:11:43 +0530

 Remove use of calls into t4_fw_hello() with MASTER_MUST, which results in
 FW_HELLO_CMD_MASTERFORCE being set. The firmware doesn't support this and of
 course any existing PF Drivers will totally go for a toss.
 
 Signed-off-by: Hariprasad Shenai haripra...@chelsio.com

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

Re: [PATCH net v9 0/7] cxgb4/cxgbi: misc. fixes for cxgb4i

[David Miller]

From: Karen Xie k...@chelsio.com
Date: Thu, 11 Dec 2014 07:25:37 -0800

 This patch set fixes cxgb4i's tx credit calculation and adds handling of
 additional rx message and negative advice types. It also removes the duplicate
 code in cxgb4i to set the outgoing queues of a packet. 

This series does not apply cleanly at all to net-next, it gets many
rejects.
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH net v9 0/7] cxgb4/cxgbi: misc. fixes for cxgb4i

[David Miller]

From: Anish Bhatt an...@chelsio.com
Date: Thu, 11 Dec 2014 20:24:48 +

 This series does not apply cleanly at all to net-next, it gets many
 rejects.
 
 Hey Dave, this patchset was mostly bugfixes and hence meant for net where it
 applies cleanly. not net-next. We can rebase to net-next and send if you're 
 still
  willing to take it before net-next closes.

You absolutely must rebase it on net-next.
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH net v7 3/7] cxgb4/cxgb4i: set the max. pdu length in firmware

[David Miller]

From: Karen Xie k...@chelsio.com
Date: Wed, 10 Dec 2014 12:24:09 -0800

 [PATCH net v7 3/7] cxgb4/cxgb4i: set the max. pdu length in firmware.

Please listen to the feedback you have been given.

Again, you should not duplicate the Subject line in your message
body, that makes more work for the people integrating your patches
as we have to remove all of these things by hand.
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH net v6 7/7] libcxgbi: free skb after debug prints

[David Miller]

From: Karen Xie k...@chelsio.com
Date: Wed, 10 Dec 2014 20:26:59 +

 Thanks, v7 has been submitted to address your comment. Please review.

Sorry, you did not actually address his comments.

He said to not duplicate your Subject lines in your message bodies,
and you did not fix that.
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH net v7 3/7] cxgb4/cxgb4i: set the max. pdu length in firmware

[David Miller]

From: James Bottomley james.bottom...@hansenpartnership.com
Date: Wed, 10 Dec 2014 23:41:29 +0300

 On Wed, 2014-12-10 at 15:31 -0500, David Miller wrote:
 From: Karen Xie k...@chelsio.com
 Date: Wed, 10 Dec 2014 12:24:09 -0800
 
  [PATCH net v7 3/7] cxgb4/cxgb4i: set the max. pdu length in firmware.
 
 Please listen to the feedback you have been given.
 
 Again, you should not duplicate the Subject line in your message
 body, that makes more work for the people integrating your patches
 as we have to remove all of these things by hand.
 
 While we're on the subject of making life easier for maintainers, could
 I put in a plea for threading your patch set?  It really does make it
 easier to find and apply all the patches, especially on a high traffic
 list where they otherwise get interspersed with other messages.

With patchwork I never need to even think about this issue.
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH net v6 7/7] libcxgbi: free skb after debug prints

[David Miller]

From: Karen Xie k...@chelsio.com
Date: Wed, 10 Dec 2014 21:02:34 +

 Sorry, misread the comment, will resubmit. Thanks.

Please do not top-post.

Quote the relevant material, then provide your own content
after the quoted material, not before.
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH net v8 1/7] cxgb4i: fix tx immediate data credit check

[David Miller]

From: Karen Xie k...@chelsio.com
Date: Wed, 10 Dec 2014 13:11:06 -0800

 From: Karen Xie k...@chelsio.com
 
 Only data skbs need the wr header added while control skbs do not. Make sure 
 they are treated differently.
 
 Signed-off-by: Karen Xie k...@chelsio.com

Please text format your commit messages to 80 characters or less per
line.

People are going to read your commits using text tools, not
necessarily GUI tools which will auto-format your commit message.

I know this seems like we are being difficult, but you are making many
fundamental mistakes in your efforts to merge in these changes.
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [hch-scsi-queue:drivers-for-3.19 174/180] drivers/scsi/wd719x.c:247:2: error: implicit declaration of function 'dma_cache_sync'

[David Miller]

From: Christoph Hellwig h...@lst.de
Date: Wed, 26 Nov 2014 20:13:09 +0100

 On Wed, Nov 26, 2014 at 06:32:48PM +0100, Ondrej Zary wrote:
 wd819x should probably depend on VIRT_TO_BUS? But that means it will not 
 work 
 on sparc. Is there a way to make it work? I have a sparc machine but haven't 
 tested it.
 
 The explanation from Arnd in the other thread makes more sense -
 dma_cache_sync only is for non-coherent allocations so we should be
 able to remove it entirely.  Can you prepare and test a patch to just remove
 it for me?

Since dma_alloc_noncoherent is simply dma_alloc_coherent on sparc, I can
simply implement dma_cache_sync() as a nop.

I'll do that right now.

I also agree that if wd719x is not using dma_alloc_noncoherent(), it
should not be calling dma_cache_sync().
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH net-next] cxgb4/cxgb4vf/csiostor: Add T4/T5 PCI ID Table

[David Miller]

From: Hariprasad Shenai haripra...@chelsio.com
Date: Tue, 25 Nov 2014 08:33:58 +0530

 Add a new file t4_pci_id_tbl.h that contains T4/T5 PCI ID Table so that for 
 all
 drivers that uses T4/T5 PCI functions changes can be done in one place.
 
 checkpatch.pl script reports following error, which if tried to fix ends up in
 compilation error.
...
 Signed-off-by: Hariprasad Shenai haripra...@chelsio.com

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

Re: Another (ESP?) scsi blk-mq problem on sparc64

[David Miller]

From: Jens Axboe ax...@kernel.dk
Date: Mon, 24 Nov 2014 10:16:15 -0700

 How about this one?

The num in num_possible_cpus() means a count, as in how many are
there.

It doesn't mean largest ID of members of set X, which is what you
are asking for.

Even worse, having num_online_cpus() and num_possible_cpus() count
from a different perspective is really confusing.

Usually when people want a per-cpu thing they allocate percpu
memory which hides all of these details, why don't you allocate
the map as dynamic per-cpu memory?

It will also do the NUMA node local allocations for you as well.
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Another (ESP?) scsi blk-mq problem on sparc64

[David Miller]

From: Jens Axboe ax...@kernel.dk
Date: Mon, 24 Nov 2014 15:01:55 -0700

 I'll just updated blk-mq to use nr_cpu_ids and be done with it.

Wow, a grep on nr_cpu_ids gets a lot of hits on people allocating just
these kinds of tables :)
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Another (ESP?) scsi blk-mq problem on sparc64

[David Miller]

From: mr...@linux.ee
Date: Tue, 25 Nov 2014 00:23:20 +0200 (EET)

Yes, that does look like the case.  Do you have a good trick on how
to allocate a map for the highest possible cpu number without first
iterating the cpu map?  I couldn't find something that looks like a
highest_possible_cpu() helper.
  
   Honestly I think that num_posible_cpus() should return the max of
   number of CPUs (weigt), and the highest numbered CPU. It's a pain in
   the butt to handle this otherwise.
 
  Hear, hear!!!  That would make my life easier, and would make this sort
  of problem much less likely to occur!
 
 How about this one?
 
 It make the machine work.

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

Re: [PATCH 12/12] Replace tmscsim by am53c974

[David Miller]

Please do not _EVER_ quote an entire huge patch just to add a signoff
or ACK.

This wastes tons of mailing list resources because it means that
the entire huge patch is sent once again to every single recipient
on the mailing list.

Instead, just at most quote the commit message, then add your
ACK, and remove the patch from the quoted material entirely.

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

Re: [PATCH net-next 0/5] RDMA/cxgb4,cxgb4vf,csiostor: Cleanup macros

[David Miller]

From: Hariprasad Shenai haripra...@chelsio.com
Date: Fri, 21 Nov 2014 12:52:00 +0530

 This series continues to cleanup all the macros/register defines related to
 filter, port, VI, queue, RSS, LDST, firmware, etc that are defined in 
 t4fw_api.h
 and the affected files.
 
 Will post few more series so that we can cover all the macros so that they all
 follow the same style to be consistent.
 
 The patches series is created against 'net-next' tree.
 And includes patches on cxgb4, cxgb4vf, iw_cxgb4 and csiostor driver.
 
 We have included all the maintainers of respective drivers. Kindly review the
 change and let us know in case of any review comments.

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

Re: [PATCH 06/12] esp_scsi: use FIFO for command submission

[David Miller]

From: Hannes Reinecke h...@suse.de
Date: Fri, 21 Nov 2014 13:41:50 +0100

 Using DMA for command submission has the drawback that it might
 generate additional DMA completion interrupts after the command
 has been submitted to the device.
 Additionally the am53c974 has a design flaw causing it
 to generate spurious interrupts even though DMA completion
 interrupts are not enabled.
 This can be avoided by using the FIFO for command submission.
 
 Signed-off-by: Hannes Reinecke h...@suse.de

Acked-by: David S. Miller da...@davemloft.net
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 01/12] esp_scsi: spellcheck 'driver'

[David Miller]

From: Hannes Reinecke h...@suse.de
Date: Fri, 21 Nov 2014 13:41:45 +0100

 Reviewed-by: Paolo Bonzini pbonz...@redhat.com
 Signed-off-by: Hannes Reinecke h...@suse.de

Acked-by: David S. Miller da...@davemloft.net
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 02/12] esp_scsi: make number of tags configurable

[David Miller]

From: Hannes Reinecke h...@suse.de
Date: Fri, 21 Nov 2014 13:41:46 +0100

 Add a field 'num_tags' to the esp structure to allow drivers
 to overwrite the number of avialable tags if required.
 Default is ESP_DEFAULT_TAGS.
 
 Reviewed-by: Paolo Bonzini pbonz...@redhat.com
 Signed-off-by: Hannes Reinecke h...@suse.de

Acked-by: David S. Miller da...@davemloft.net
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 03/12] esp_scsi: convert to dev_printk

[David Miller]

From: Hannes Reinecke h...@suse.de
Date: Fri, 21 Nov 2014 13:41:47 +0100

 Use dev_printk functions for correct device annotations.
 
 Reviewed-by: Paolo Bonzini pbonz...@redhat.com
 Signed-off-by: Hannes Reinecke h...@suse.de

Acked-by: David S. Miller da...@davemloft.net
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 05/12] esp_scsi: read status registers

[David Miller]

From: Hannes Reinecke h...@suse.de
Date: Fri, 21 Nov 2014 13:41:49 +0100

 A read to ESP_INTRPT will clear ESP_STATUS and ESP_SSTEP. So read
 all status registers in one go to avoid losing information.
 
 Reviewed-by: Paolo Bonzini pbonz...@redhat.com
 Signed-off-by: Hannes Reinecke h...@suse.de

Acked-by: David S. Miller da...@davemloft.net
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 08/12] am53c974: BLAST residual handling

[David Miller]

From: Hannes Reinecke h...@suse.de
Date: Fri, 21 Nov 2014 13:41:52 +0100

 The am53c974 has an design issue where a single byte might be
 left in the SCSI FIFO after a DMA transfer.
 As the handling code is currently untested add a WARN_ON()
 statement here.
 
 Signed-off-by: Hannes Reinecke h...@suse.de

Acked-by: David S. Miller da...@davemloft.net
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 09/12] esp: correctly detect am53c974

[David Miller]

From: Hannes Reinecke h...@suse.de
Date: Fri, 21 Nov 2014 13:41:53 +0100

 + if ((config4  ESP_CONFIG4_GE1) == ESP_CONFIG4_GE1) {

Please condense this down to the more simple and straightforward:

if (x  BIT(N))

because this is always equivalent to the expression you have used:

if ((x  BIT(N)) == BIT(N))

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

Re: Another (ESP?) scsi blk-mq problem on sparc64

[David Miller]

From: Christoph Hellwig h...@infradead.org
Date: Wed, 19 Nov 2014 22:01:35 -0800

 On Sat, Nov 15, 2014 at 08:31:00AM -0700, Jens Axboe wrote:
 My next move would be to add more debug to the CPU map setup and teardown,
 so that we can verify that the map that is being used above has indeed been
 setup. Unless Christoph has any ideas on what is going on here?
 
 No good idea, but I'd sugges to debug cpu_to_queue_index how it could
 return such an out of bounds value.

I would suggest looking into the possibility that we allocate the memory
using the count of valid cpus, rather than the largest cpu number.

That's a common error that runs into problems with discontiguous
cpu numbering like Sparc sometimes has.
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html