<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git, branch v3.18.90</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v3.18.90</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v3.18.90'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2017-12-25T13:20:09+00:00</updated>
<entry>
<title>Linux 3.18.90</title>
<updated>2017-12-25T13:20:09+00:00</updated>
<author>
<name>Greg Kroah-Hartman</name>
<email>gregkh@linuxfoundation.org</email>
</author>
<published>2017-12-25T13:20:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=8da23652fa4353a2e5281f444aeaa639b452630a'/>
<id>urn:sha1:8da23652fa4353a2e5281f444aeaa639b452630a</id>
<content type='text'>
</content>
</entry>
<entry>
<title>fm10k: ensure we process SM mbx when processing VF mbx</title>
<updated>2017-12-25T13:20:09+00:00</updated>
<author>
<name>Jacob Keller</name>
<email>jacob.e.keller@intel.com</email>
</author>
<published>2017-10-02T14:17:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=510f29192b5514cea135581f1b64dda71f8de6a2'/>
<id>urn:sha1:510f29192b5514cea135581f1b64dda71f8de6a2</id>
<content type='text'>
[ Upstream commit 17a91809942ca32c70026d2d5ba3348a2c4fdf8f ]

When we process VF mailboxes, the driver is likely going to also queue
up messages to the switch manager. This process merely queues up the
FIFO, but doesn't actually begin the transmission process. Because we
hold the mailbox lock during this VF processing, the PF&lt;-&gt;SM mailbox is
not getting processed at this time. Ensure that we actually process the
PF&lt;-&gt;SM mailbox in between each PF&lt;-&gt;VF mailbox.

This should ensure prompt transmission of the messages queued up after
each VF message is received and handled.

Signed-off-by: Jacob Keller &lt;jacob.e.keller@intel.com&gt;
Tested-by: Krishneil Singh &lt;krishneil.k.singh@intel.com&gt;
Signed-off-by: Jeff Kirsher &lt;jeffrey.t.kirsher@intel.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>scsi: lpfc: PLOGI failures during NPIV testing</title>
<updated>2017-12-25T13:20:09+00:00</updated>
<author>
<name>Dick Kennedy</name>
<email>dick.kennedy@broadcom.com</email>
</author>
<published>2017-09-30T00:34:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a6af431eb78989e1965feb4934eeadec0064526e'/>
<id>urn:sha1:a6af431eb78989e1965feb4934eeadec0064526e</id>
<content type='text'>
[ Upstream commit e8bcf0ae4c0346fdc78ebefe0eefcaa6a6622d38 ]

Local Reject/Invalid RPI errors seen during discovery.

Temporary RPI cleanup was occurring regardless of SLI rev. It's only
necessary on SLI-4.

Adjust the test for whether cleanup is necessary.

Signed-off-by: Dick Kennedy &lt;dick.kennedy@broadcom.com&gt;
Signed-off-by: James Smart &lt;james.smart@broadcom.com&gt;
Reviewed-by: Johannes Thumshirn &lt;jthumshirn@suse.de&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>scsi: lpfc: Fix secure firmware updates</title>
<updated>2017-12-25T13:20:09+00:00</updated>
<author>
<name>Dick Kennedy</name>
<email>dick.kennedy@broadcom.com</email>
</author>
<published>2017-09-30T00:34:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=6ea3e1c5114cc07dc1c637e053c5c83e22ca25ae'/>
<id>urn:sha1:6ea3e1c5114cc07dc1c637e053c5c83e22ca25ae</id>
<content type='text'>
[ Upstream commit 184fc2b9a8bcbda9c14d0a1e7fbecfc028c7702e ]

Firmware update fails with: status x17 add_status x56 on the final write

If multiple DMA buffers are used for the download, some firmware revs
have difficulty with signatures and crcs split across the dma buffer
boundaries.  Resolve by making all writes be a single 4k page in length.

Signed-off-by: Dick Kennedy &lt;dick.kennedy@broadcom.com&gt;
Signed-off-by: James Smart &lt;james.smart@broadcom.com&gt;
Reviewed-by: Johannes Thumshirn &lt;jthumshirn@suse.de&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>PCI/AER: Report non-fatal errors only to the affected endpoint</title>
<updated>2017-12-25T13:20:09+00:00</updated>
<author>
<name>Gabriele Paoloni</name>
<email>gabriele.paoloni@huawei.com</email>
</author>
<published>2017-09-28T14:33:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ca6f17da0b134bbc71d143dc5e059f20809c11dd'/>
<id>urn:sha1:ca6f17da0b134bbc71d143dc5e059f20809c11dd</id>
<content type='text'>
[ Upstream commit 86acc790717fb60fb51ea3095084e331d8711c74 ]

Previously, if an non-fatal error was reported by an endpoint, we
called report_error_detected() for the endpoint, every sibling on the
bus, and their descendents.  If any of them did not implement the
.error_detected() method, do_recovery() failed, leaving all these
devices unrecovered.

For example, the system described in the bugzilla below has two devices:

  0000:74:02.0 [19e5:a230] SAS controller, driver has .error_detected()
  0000:74:03.0 [19e5:a235] SATA controller, driver lacks .error_detected()

When a device such as 74:02.0 reported a non-fatal error, do_recovery()
failed because 74:03.0 lacked an .error_detected() method.  But per PCIe
r3.1, sec 6.2.2.2.2, such an error does not compromise the Link and
does not affect 74:03.0:

  Non-fatal errors are uncorrectable errors which cause a particular
  transaction to be unreliable but the Link is otherwise fully functional.
  Isolating Non-fatal from Fatal errors provides Requester/Receiver logic
  in a device or system management software the opportunity to recover from
  the error without resetting the components on the Link and disturbing
  other transactions in progress.  Devices not associated with the
  transaction in error are not impacted by the error.

Report non-fatal errors only to the endpoint that reported them.  We really
want to check for AER_NONFATAL here, but the current code structure doesn't
allow that.  Looking for pci_channel_io_normal is the best we can do now.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=197055
Fixes: 6c2b374d7485 ("PCI-Express AER implemetation: AER core and aerdriver")
Signed-off-by: Gabriele Paoloni &lt;gabriele.paoloni@huawei.com&gt;
Signed-off-by: Dongdong Liu &lt;liudongdong3@huawei.com&gt;
[bhelgaas: changelog]
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;

Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>igb: check memory allocation failure</title>
<updated>2017-12-25T13:20:09+00:00</updated>
<author>
<name>Christophe JAILLET</name>
<email>christophe.jaillet@wanadoo.fr</email>
</author>
<published>2017-08-27T06:39:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=6d117334cea2f10bec8023520e50fc3de49631b7'/>
<id>urn:sha1:6d117334cea2f10bec8023520e50fc3de49631b7</id>
<content type='text'>
[ Upstream commit 18eb86362a52f0af933cc0fd5e37027317eb2d1c ]

Check memory allocation failures and return -ENOMEM in such cases, as
already done for other memory allocations in this function.

This avoids NULL pointers dereference.

Signed-off-by: Christophe JAILLET &lt;christophe.jaillet@wanadoo.fr&gt;
Tested-by: Aaron Brown &lt;aaron.f.brown@intel.com
Acked-by: PJ Waskiewicz &lt;peter.waskiewicz.jr@intel.com&gt;
Signed-off-by: Jeff Kirsher &lt;jeffrey.t.kirsher@intel.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>PCI: Create SR-IOV virtfn/physfn links before attaching driver</title>
<updated>2017-12-25T13:20:09+00:00</updated>
<author>
<name>Stuart Hayes</name>
<email>stuart.w.hayes@gmail.com</email>
</author>
<published>2017-10-04T15:57:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=9e2dfe98004a67b9d0450bc41777d2a8e0cb326c'/>
<id>urn:sha1:9e2dfe98004a67b9d0450bc41777d2a8e0cb326c</id>
<content type='text'>
[ Upstream commit 27d6162944b9b34c32cd5841acd21786637ee743 ]

When creating virtual functions, create the "virtfn%u" and "physfn" links
in sysfs *before* attaching the driver instead of after.  When we attach
the driver to the new virtual network interface first, there is a race when
the driver attaches to the new sends out an "add" udev event, and the
network interface naming software (biosdevname or systemd, for example)
tries to look at these links.

Signed-off-by: Stuart Hayes &lt;stuart.w.hayes@gmail.com&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>scsi: cxgb4i: fix Tx skb leak</title>
<updated>2017-12-25T13:20:09+00:00</updated>
<author>
<name>Varun Prakash</name>
<email>varun@chelsio.com</email>
</author>
<published>2017-10-11T14:03:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=98c3d06cbff5a943f9c2d135092f8177262fbfcf'/>
<id>urn:sha1:98c3d06cbff5a943f9c2d135092f8177262fbfcf</id>
<content type='text'>
[ Upstream commit 9b3a081fb62158b50bcc90522ca2423017544367 ]

In case of connection reset Tx skb queue can have some skbs which are
not transmitted so purge Tx skb queue in release_offload_resources() to
avoid skb leak.

Signed-off-by: Varun Prakash &lt;varun@chelsio.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>PCI: Avoid bus reset if bridge itself is broken</title>
<updated>2017-12-25T13:20:09+00:00</updated>
<author>
<name>David Daney</name>
<email>david.daney@cavium.com</email>
</author>
<published>2017-09-08T08:10:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ac8283db32cb8a24846ae157a329d2949dde5f66'/>
<id>urn:sha1:ac8283db32cb8a24846ae157a329d2949dde5f66</id>
<content type='text'>
[ Upstream commit 357027786f3523d26f42391aa4c075b8495e5d28 ]

When checking to see if a PCI bus can safely be reset, we previously
checked to see if any of the children had their PCI_DEV_FLAGS_NO_BUS_RESET
flag set.  Children marked with that flag are known not to behave well
after a bus reset.

Some PCIe root port bridges also do not behave well after a bus reset,
sometimes causing the devices behind the bridge to become unusable.

Add a check for PCI_DEV_FLAGS_NO_BUS_RESET being set in the bridge device
to allow these bridges to be flagged, and prevent their secondary buses
from being reset.

Signed-off-by: David Daney &lt;david.daney@cavium.com&gt;
[jglauber@cavium.com: fixed typo]
Signed-off-by: Jan Glauber &lt;jglauber@cavium.com&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Reviewed-by: Alex Williamson &lt;alex.williamson@redhat.com&gt;

Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>net: phy: at803x: Change error to EINVAL for invalid MAC</title>
<updated>2017-12-25T13:20:09+00:00</updated>
<author>
<name>Dan Murphy</name>
<email>dmurphy@ti.com</email>
</author>
<published>2017-10-10T17:42:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=8a58da6d17db972f17870afabee9b0e607382793'/>
<id>urn:sha1:8a58da6d17db972f17870afabee9b0e607382793</id>
<content type='text'>
[ Upstream commit fc7556877d1748ac00958822a0a3bba1d4bd9e0d ]

Change the return error code to EINVAL if the MAC
address is not valid in the set_wol function.

Signed-off-by: Dan Murphy &lt;dmurphy@ti.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
</feed>
