Commit Graph

872924 Commits

Author SHA1 Message Date
David S. Miller
63158ac0ba Merge branch 'net-bcmgenet-restore-internal-EPHY-support'
Doug Berger says:

====================
net: bcmgenet: restore internal EPHY support

I managed to get my hands on an old BCM97435SVMB board to do some
testing with the latest kernel and uncovered a number of things
that managed to get broken over the years (some by me ;).

This commit set attempts to correct the errors I observed in my
testing.

The first commit applies to all internal PHYs to restore proper
reporting of link status when a link comes up.

The second commit restores the soft reset to the initialization of
the older internal EPHYs used by 40nm Set-Top Box devices.

The third corrects a bug I introduced when removing excessive soft
resets by altering the initialization sequence in a way that keeps
the GENETv3 MAC interface happy.

Finally, I observed a number of issues when manually configuring
the network interface of the older EPHYs that appear to be resolved
by the fourth commit.
====================

Signed-off-by: David S. Miller <davem@davemloft.net>
2019-10-18 10:00:07 -07:00
Doug Berger
25382b991d net: bcmgenet: reset 40nm EPHY on energy detect
The EPHY integrated into the 40nm Set-Top Box devices can falsely
detect energy when connected to a disabled peer interface. When the
peer interface is enabled the EPHY will detect and report the link
as active, but on occasion may get into a state where it is not
able to exchange data with the connected GENET MAC. This issue has
not been observed when the link parameters are auto-negotiated;
however, it has been observed with a manually configured link.

It has been empirically determined that issuing a soft reset to the
EPHY when energy is detected prevents it from getting into this bad
state.

Fixes: 1c1008c793 ("net: bcmgenet: add main driver file")
Signed-off-by: Doug Berger <opendmb@gmail.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-10-18 10:00:07 -07:00
Doug Berger
1f51548627 net: bcmgenet: soft reset 40nm EPHYs before MAC init
It turns out that the "Workaround for putting the PHY in IDDQ mode"
used by the internal EPHYs on 40nm Set-Top Box chips when powering
down puts the interface to the GENET MAC in a state that can cause
subsequent MAC resets to be incomplete.

Rather than restore the forced soft reset when powering up internal
PHYs, this commit moves the invocation of phy_init_hw earlier in
the MAC initialization sequence to just before the MAC reset in the
open and resume functions. This allows the interface to be stable
and allows the MAC resets to be successful.

The bcmgenet_mii_probe() function is split in two to accommodate
this. The new function bcmgenet_mii_connect() handles the first
half of the functionality before the MAC initialization, and the
bcmgenet_mii_config() function is extended to provide the remaining
PHY configuration following the MAC initialization.

Fixes: 484bfa1507 ("Revert "net: bcmgenet: Software reset EPHY after power on"")
Signed-off-by: Doug Berger <opendmb@gmail.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-10-18 10:00:07 -07:00
Doug Berger
fe586b8233 net: phy: bcm7xxx: define soft_reset for 40nm EPHY
The internal 40nm EPHYs use a "Workaround for putting the PHY in
IDDQ mode." These PHYs require a soft reset to restore functionality
after they are powered back up.

This commit defines the soft_reset function to use genphy_soft_reset
during phy_init_hw to accommodate this.

Fixes: 6e2d85ec05 ("net: phy: Stop with excessive soft reset")
Signed-off-by: Doug Berger <opendmb@gmail.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-10-18 10:00:07 -07:00
Doug Berger
7de48402fa net: bcmgenet: don't set phydev->link from MAC
When commit 28b2e0d2cd ("net: phy: remove parameter new_link from
phy_mac_interrupt()") removed the new_link parameter it set the
phydev->link state from the MAC before invoking phy_mac_interrupt().

However, once commit 88d6272aca ("net: phy: avoid unneeded MDIO
reads in genphy_read_status") was added this initialization prevents
the proper determination of the connection parameters by the function
genphy_read_status().

This commit removes that initialization to restore the proper
functionality.

Fixes: 88d6272aca ("net: phy: avoid unneeded MDIO reads in genphy_read_status")
Signed-off-by: Doug Berger <opendmb@gmail.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-10-18 10:00:07 -07:00
Vivek Kasireddy
e83c467358 drm/i915: Correct the PCH type in irq postinstall
JasperLake PCH (JSP) has DDI HPD pin mappings similar to TGP and not
MCC. Also add the correct HPD pin mappings for the MCC PCH.

Cc: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191016183514.11128-1-vivek.kasireddy@intel.com
2019-10-18 09:28:53 -07:00
Linus Torvalds
5f93393a15 sound fixes for 5.4-rc4
Just a few small fixes for the usual suspect, HD- and USB-audio:
 enablement of runtime PM for Nvidia due to the recent PCI
 changes, a fix for potential hangs with recent HD-audio platforms,
 and the rest device-specific quirks.
 -----BEGIN PGP SIGNATURE-----
 
 iQJCBAABCAAsFiEEIXTw5fNLNI7mMiVaLtJE4w1nLE8FAl2pI44OHHRpd2FpQHN1
 c2UuZGUACgkQLtJE4w1nLE+40g/9GzM/iU9fqWcz6zVY44z7YIhsvsfe+En+3gsF
 uTyKcd60V0lKVmFEEp+pysIj7VbmF3arYsQTrlkwO3hCx1/S90V6FxSJ9a1/U3XN
 2PVPTBgHig8QEaR7tgefiRhdb7beJtgeu+1wHC0HJCRplPQI3k7D4fqDnCcsqzvA
 p/dCBB6z0nMaeqhWN4mEg+YnFW20mRQg840xcCggGI61gKET8h/56RQqQkKIUZPg
 Ocpt02wwnghsyanKeSbguAKI3ZMOaslLXPXhp2KDlBUCkw7CHRftt9L49P0c0ZlN
 dLHlfLnYCG/oqDg/MXxqyw3l97hTRSKVDlh6mfnlmP4onJkwg3RJT3Yqq7LW2lEr
 cr5y/JNFjkiEAicspmZEsbA4JxYqNnwp8yDPLtxZw+vFEAfygyS5M/5P7wV7gG5J
 fhEhAWVSycbSusjIzngmgFadzmbxqTrmoiTG1fM9oyYja5OhwhERNch//Uid33PC
 2kZSy+MVuDmovhZxbPNAAD7sDg1f/qewRs67efm6nzAouTv3PBu0bwNPwWJe8oIy
 pFI633CC1CCjmGsHmVAQEGBx0wSLlUC4yoDZirE+ypzcf4vkKjJnTLRgCWl2MJw1
 hjwMKGKK7um5OWrl+yZW5x8KxlcMj4JQyDHZ3fqH9SdDoNTuVYjWgOD6cmPzSlvE
 2n0NYoE=
 =qL+y
 -----END PGP SIGNATURE-----

Merge tag 'sound-5.4-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound

Pull sound fixes from Takashi Iwai:
 "Just a few small fixes for the usual suspect, HD- and USB-audio:
  enablement of runtime PM for Nvidia due to the recent PCI changes, a
  fix for potential hangs with recent HD-audio platforms, and the rest
  device-specific quirks"

* tag 'sound-5.4-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
  ALSA: hda - Force runtime PM on Nvidia HDMI codecs
  ALSA: hda/realtek - Enable headset mic on Asus MJ401TA
  ALSA: usb-audio: Disable quirks for BOSS Katana amplifiers
  ALSA: hdac: clear link output stream mapping
  ALSA: hda/realtek: Reduce the Headphone static noise on XPS 9350/9360
2019-10-18 09:21:13 -07:00
Linus Torvalds
adca4ce32f ACPI fixes for 5.4-rc4
Fix possible use-after-free in the ACPI CPPC support code (John Garry)
 and prevent the ACPI HMAT parsing code from using possibly incorrect
 data coming from the platform firmware (Daniel Black).
 -----BEGIN PGP SIGNATURE-----
 
 iQJGBAABCAAwFiEE4fcc61cGeeHD/fCwgsRv/nhiVHEFAl2pgMoSHHJqd0Byand5
 c29ja2kubmV0AAoJEILEb/54YlRxoagP/iV98NGjJ9T7qrXYRavUN5PTKg7EesdD
 NpWsPp6QVM9w6inZd7LbuYNR1neqCR7dtfHopEMy443TSk/TlNDUi33qolTYuC7p
 rdYORKA4uYmR2ndh5x9ayE5lw+Qk5EzPhYQxXlKAoV9KFGDFl0OclQNlbIjjt+sr
 MmXzUeF3fu0sDITR9QHqBLggy4WU8Kae40cOakjHPriua9YBWQBa/CfZ1il9LcL4
 1GkGltQ6QRHmvTHhGDqEvzBv8IVpGvhpCAy19DrQFxTkz13haig+rO5vTy+iSk49
 eU9Wq9ycEH8EJy8+LeX17C0fzspQ39gfW7iqGMmX+fTgkMUxWjw20erVzgOKtN6P
 L/jydnarvBlubNEZmcC/9AWj3XwbfJf70DbzWcfZRSCBOo+2yLqK9XOtDWVQlC/Q
 YEfN6cZOUgTwSY5rJJXNqtJ34R5ih/07vI8oNu05VaxVZ40h6oKpvwgqcRffOjGU
 1rP0SmyY3QHgs5M8omgXSkvgtTX1f6RbDrZut4Kph4jPSWcHPzHnanvjFTJQ1PJK
 9QT3dRwyxPqFn7LLtSytdw/UmrzWx4QMoE6FlC5T2S/jrMNKmwtScY3W85yrgBe4
 ouGPErNr6O66hY5hEv/YG2ftLxvhca2AM1Wliw0wAbtB4k6siyRflnslVhuyCK4P
 M+EtmQkO5T7w
 =X05s
 -----END PGP SIGNATURE-----

Merge tag 'acpi-5.4-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm

Pull ACPI fixes from Rafael Wysocki:
 "Fix possible use-after-free in the ACPI CPPC support code (John Garry)
  and prevent the ACPI HMAT parsing code from using possibly incorrect
  data coming from the platform firmware (Daniel Black)"

* tag 'acpi-5.4-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
  ACPI: CPPC: Set pcc_data[pcc_ss_id] to NULL in acpi_cppc_processor_exit()
  ACPI: HMAT: ACPI_HMAT_MEMORY_PD_VALID is deprecated since ACPI-6.3
2019-10-18 08:38:26 -07:00
Linus Torvalds
e59b76ff67 Power management fixes for 5.4-rc4
- Fix possible NULL pointer dereference in the ACPI processor
    scaling initialization code introduced by a recent cpufreq
    update (Rafael Wysocki).
 
  - Fix possible deadlock due to suspending cpufreq too late during
    system shutdown (Rafael Wysocki).
 
  - Make the PCI device system resume code path be more consistent
    with its PM-runtime counterpart to fix an issue with missing
    delay on transitions from D3cold to D0 during system resume from
    suspend-to-idle on some systems (Rafael Wysocki).
 
  - Drop Dell XPS13 9360 from the LPS0 Idle _DSM blacklist to make it
    use suspend-to-idle by default (Mario Limonciello).
 
  - Fix build warning in the core system suspend support code (Ben
    Dooks).
 -----BEGIN PGP SIGNATURE-----
 
 iQJGBAABCAAwFiEE4fcc61cGeeHD/fCwgsRv/nhiVHEFAl2pgDcSHHJqd0Byand5
 c29ja2kubmV0AAoJEILEb/54YlRxsCQQAJ6L+CC5kEmjfkFeUvCR7xe37wEdeCYc
 NL13rDuKAKQDK6ayJtHp6LUPpSiotOzvjohFplLyn8dAZ7x8V0/KOOGeoL35GSlN
 u18AxkRXT79AzrW1SoDm2TnCCZYV0aW5RupGzPd4vso+E5Q5S3e9Ugk3PBxQfTYH
 YKOr7SpBBICma8ZgplR4tUTLb8brhR/NUAIOVyze52gUKh366kZbDD5tn8eHUxXq
 CBj4ryyV88aeQH2sM1sfvdIlDgFgHrO5GOzcDCCKrEtddqP/hSZyHU+OCH35Vu1v
 it96AEx58IEmd8I18tNZtu5rm1b89YkHeuoh/UF92zCYvk4RVg+Dw3AF0NZVjMQo
 vO7xyO93H48TClHcCwxIOhdI16bXidYfVR1JTeTINvaR7mNZtUddSCEFVKwCazbP
 FC55pVPeUx+HbC6TBQJ9gOSxO2yc2f+uLUXfnKgOpeFZpQuX/WhzuWqUlXgBF2QK
 FHOdfVvX1p1tE9U+3sMLyx1Sln+gqtd2P6GnGzewqIAl43LyJBC4l1s+nkE1b5fc
 7pa0rEqLu4NtGj5O+YQvp+luTQ9FcVL9K5tTuqV4V1Kt+/bzjfIvaEJpwHs44yrZ
 tP2/YCCiA84Hy8SqS4Txk+D14XVYuRguTMBzcmWj2POKFTbDsIhC9bAEZgfJZJNK
 /S2jf5CTnZtl
 =67IL
 -----END PGP SIGNATURE-----

Merge tag 'pm-5.4-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm

Pull power management fixes from Rafael Wysocki:
 "These include a fix for a recent regression in the ACPI CPU
performance scaling code, a PCI device power management fix,
a system shutdown fix related to cpufreq, a removal of an ACPI
suspend-to-idle blacklist entry and a build warning fix.

Specifics:

   - Fix possible NULL pointer dereference in the ACPI processor scaling
     initialization code introduced by a recent cpufreq update (Rafael
     Wysocki).

   - Fix possible deadlock due to suspending cpufreq too late during
     system shutdown (Rafael Wysocki).

   - Make the PCI device system resume code path be more consistent with
     its PM-runtime counterpart to fix an issue with missing delay on
     transitions from D3cold to D0 during system resume from
     suspend-to-idle on some systems (Rafael Wysocki).

   - Drop Dell XPS13 9360 from the LPS0 Idle _DSM blacklist to make it
     use suspend-to-idle by default (Mario Limonciello).

   - Fix build warning in the core system suspend support code (Ben
     Dooks)"

* tag 'pm-5.4-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
  ACPI: processor: Avoid NULL pointer dereferences at init time
  PCI: PM: Fix pci_power_up()
  PM: sleep: include <linux/pm_runtime.h> for pm_wq
  cpufreq: Avoid cpufreq_suspend() deadlock on system shutdown
  ACPI: PM: Drop Dell XPS13 9360 from LPS0 Idle _DSM blacklist
2019-10-18 08:34:04 -07:00
Linus Torvalds
c3419fd6d3 Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
-----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCAAdFiEEZOpW2gUwxXeCmhkh7ulgGnXF3j0FAl2PeYQACgkQ7ulgGnXF
 3j3Zow/7BD/9Vai5zqDOFXSFnR5cFfcLoL2aYu13B5GjIYKZlhUW8ePC0jo0p0sV
 TSsIrOxv3RaeDLC5ISi+njsSJMspW5qGv8jrZb7xBn1zE2gcJ9YeVhb+tboW2rrr
 R03i7HInSQhdyKFMQS05IonRi8LphmTYKy3p8LifiiPoy4TsGcpw2tjQKicp0GxZ
 gWMOcMnx4sfUiivo0tys6UwUIACVqKOysXn4HGs8COFF4cdBHXJVkddZ5ZUO6hP+
 JInRdiKqDwycZyE6X/6Mj1B7tbmLVGH5mOX2Mx6dwUQkBIpsgJGGIxHRd9sUKv3r
 ltfZADn7CJGcTgwEFF1Fnn61pYXgx/m5M9ECop+w89CLNjWBVsRW1rLjIqiDIY6a
 pCmZQE/P95iHxLtAn6s1IkZoiXzU44tGQZaS3/8uGFxizx/ktWosokUdzC3PJee3
 1eHIXOGwJlu9dTSTR7YDid4s3pXHovlMlu1OTNp1ap8jHX7L5D2AM6xxlLJaXPhN
 zOJz6vcP5ZdVWqNq55jsB0dXDa76hrN2SUkpcwgJYKeU7qnRuGRq/jzjetSuRLvI
 jyaLY0VyKxHWk0/YgmU2gfW/sBYccJg6ONCPJ80R3KuO8VoMxUPZZiWWTb6bwVXn
 Mj2M6dWRIySVI1D8MR7sahGfeCqk7LkCE88DdTDoyaBHasbUSAk=
 =LmPS
 -----END PGP SIGNATURE-----

Merge tag 'mkp-scsi-postmerge' of git://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi

Pull scsi fixes from Martin Petersen:
 "These two commits were in a separate postmerge branch due to a
  dependency on changes merged for 5.4 in the block tree.

  They fix two issues in the intersection of the request cleanup changes
  from block (b7e9e1fb7a) and the request batching changes
  (8930a6c207) that were made to SCSI during the 5.4 cycle"

* tag 'mkp-scsi-postmerge' of git://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi:
  scsi: core: fix dh and multipathing for SCSI hosts without request batching
  scsi: core: fix missing .cleanup_rq for SCSI hosts without request batching
2019-10-18 08:08:53 -07:00
Joerg Roedel
46ac18c347 iommu/amd: Check PM_LEVEL_SIZE() condition in locked section
The increase_address_space() function has to check the PM_LEVEL_SIZE()
condition again under the domain->lock to avoid a false trigger of the
WARN_ON_ONCE() and to avoid that the address space is increase more
often than necessary.

Reported-by: Qian Cai <cai@lca.pw>
Fixes: 754265bcab ("iommu/amd: Fix race in increase_address_space()")
Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
2019-10-18 16:52:37 +02:00
Jens Axboe
b55f0097ae Merge branch 'nvme-5.4' of git://git.infradead.org/nvme into for-linus
Pull NVMe updates from Keith:

"This is a collection of bug fixes committed since the previous pull
 request that address deadlocks, double resets, memory leaks, and other
 regression."

* 'nvme-5.4' of git://git.infradead.org/nvme:
  nvme-pci: Set the prp2 correctly when using more than 4k page
  nvme-tcp: fix possible leakage during error flow
  nvmet-loop: fix possible leakage during error flow
  nvme-tcp: Initialize sk->sk_ll_usec only with NET_RX_BUSY_POLL
  nvme: Wait for reset state when required
  nvme: Prevent resets during paused controller state
  nvme: Restart request timers in resetting state
  nvme: Remove ADMIN_ONLY state
  nvme-pci: Free tagset if no IO queues
  nvme: retain split access workaround for capability reads
  nvme: fix possible deadlock when nvme_update_formats fails
2019-10-18 08:49:25 -06:00
Ville Syrjälä
0b7b696640 drm/i915: Make hdcp2_msg_timeout.timeout u16
All the timeout values fit in u16, so let's shrink the structure
a bit.

This ends up actually increasing the .text size a bit due to
some changes in instructions (constant imul+small jmps replaced
with mov+bigger jmpqs). Seems pretty arbitrary to me so I'll
just pretend I didn't see it.

    text	   data	    bss	    dec	    hex	filename
-  34521	    360	      0	  34881	   8841	intel_hdmi.o
+  34537	    360	      0	  34897	   8851	intel_hdmi.o

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191010145127.7487-5-ville.syrjala@linux.intel.com
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
2019-10-18 17:10:19 +03:00
Ville Syrjälä
eac03efdc8 drm/i915: Remove hdcp2_hdmi_msg_timeout.timeout2
The only reason for the timeout2 value in the array is the
HDCP_2_2_AKE_SEND_HPRIME message. But that one still needs
special casing inside the loop, and so just ends up making
the code harder to read. Let's just remove this leaky
timeout2 abstraction and special case that one command
in a way that is easy to understand. We can then remove the
timeout2 member from struct entirely.

    text	   data	    bss	    dec	    hex	filename
-  34633	    360	      0	  34993	   88b1	intel_hdmi.o
+  34521	    360	      0	  34881	   8841	intel_hdmi.o

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191010145127.7487-4-ville.syrjala@linux.intel.com
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
2019-10-18 17:10:19 +03:00
Ville Syrjälä
770ce5a071 drm/i915: Remove dead weight from hdcp2_msg_timeout[]
The .read_2_2() hooks is never called for any of the message
types with a zero timeout. So it's all just dead weight which
we can chuck.

    text	   data	    bss	    dec	    hex	filename
-  34701	    360	      0	  35061	   88f5	intel_hdmi.o
+  34633	    360	      0	  34993	   88b1	intel_hdmi.o

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191010145127.7487-3-ville.syrjala@linux.intel.com
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
2019-10-18 17:10:13 +03:00
Kevin Hao
a4f40484e7 nvme-pci: Set the prp2 correctly when using more than 4k page
In the current code, the nvme is using a fixed 4k PRP entry size,
but if the kernel use a page size which is more than 4k, we should
consider the situation that the bv_offset may be larger than the
dev->ctrl.page_size. Otherwise we may miss setting the prp2 and then
cause the command can't be executed correctly.

Fixes: dff824b2aa ("nvme-pci: optimize mapping of small single segment requests")
Cc: stable@vger.kernel.org
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Kevin Hao <haokexin@gmail.com>
Signed-off-by: Keith Busch <kbusch@kernel.org>
2019-10-18 23:09:41 +09:00
Ville Syrjälä
67fdd8ea53 drm/i915: s/hdcp2_hdmi_msg_data/hdcp2_hdmi_msg_timeout/
The array is there only for timeout, "data" doesn't mean anything
so let's rename the thing to be more descriptive.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191010145127.7487-2-ville.syrjala@linux.intel.com
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
2019-10-18 17:04:35 +03:00
Ville Syrjälä
2edb3de9e5 drm/i915: Shrink eDRAM ways/sets arrays
Make the ways/sets arrays static cosnt u8 to shrink things a bit.

    text	   data	    bss	    dec	    hex	filename
-  23935	    629	    128	  24692	   6074	i915_drv.o
+  23818	    629	    128	  24575	   5fff	i915_drv.o

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191010145127.7487-1-ville.syrjala@linux.intel.com
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
2019-10-18 17:04:35 +03:00
Ville Syrjälä
36b53a291b drm/i915: Make dirty_pipes refer to pipes
Despite the its name dirty_pipes refers to crtc indexes. Let's
change its behaviout to match the name.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191011200949.7839-4-ville.syrjala@linux.intel.com
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
2019-10-18 17:04:35 +03:00
Ville Syrjälä
49e0ed3848 drm/i915: Nuke 'realloc_pipes'
The 'realloc_pipes' bitmask is pointless. It is either:
a) the set of pipes which are already part of the state,
   in which case adding them again is entirely redundant
b) the set of all pipes which we then add to the state

Also the fact that 'realloc_pipes' uses the crtc indexes is
going to bite is at some point so best get rid of it quick.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191011200949.7839-3-ville.syrjala@linux.intel.com
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
2019-10-18 17:04:35 +03:00
Ville Syrjälä
d7a145849b drm/i915: Nuke the useless changed param from skl_ddb_add_affected_pipes()
changed==true just means we have some crtcs in the state. All the
stuff following this only operates on crtcs in the state anyway so
there is no point in having this bool.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191011200949.7839-2-ville.syrjala@linux.intel.com
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
2019-10-18 17:04:35 +03:00
Ville Syrjälä
98c93394ba drm/i915: Refuse modes with hdisplay==4096 on pre-HSW DP
The DP port/pipe goes wonky if we try to use timings with
hdisplay==4096 on pre-HSW platforms. The link fails to train
and the pipe may not signal vblank interrupts. On HDMI such at
mode works just fine (tested on ELK/SNB/CHV). So let's refuse
such modes on DP on older platforms.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190718144340.1114-1-ville.syrjala@linux.intel.com
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
2019-10-18 17:04:34 +03:00
Ville Syrjälä
c08f995a28 drm/i915: Polish possible_clones setup
Replace the hand rolled stuff with drm_encoder_mask() when populating
possible_clones, and rename the function to
intel_encoder_possible_clones() to make it clear what it's used for.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191002162505.30716-1-ville.syrjala@linux.intel.com
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
2019-10-18 17:04:34 +03:00
Ville Syrjälä
30a027dccc drm/i915: Move the cursor rotation handling into intel_cursor_check_surface()
Unlike other planes the cursor currently handles 180 degree rotation
adjustment during the hardware programming phase. Let's move that
stuff into intel_cursor_check_surface() to match how we do things
with other plane types.

And while at we'll plop in the final src x/y coordinates (which will
actually always be zero) into the src rect and color_plane[0].x/y,
just for some extra consistency.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191015152757.12231-1-ville.syrjala@linux.intel.com
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
2019-10-18 17:04:34 +03:00
Chris Wilson
c6e07ada8e drm/i915/gt: Convert the leftover for_each_engine(gt)
Use the local gt for iterating over the available set of engines.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191018115331.8980-1-chris@chris-wilson.co.uk
2019-10-18 14:53:48 +01:00
Chris Wilson
bcce7d90d1 drm/i915/selftests: Add the mock engine to the gt->engine[]
Remember to include the newly created mock engine in the list of
available engines inside the gt.

Fixes: a50134b198 ("drm/i915: Make for_each_engine_masked work on intel_gt")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191018130703.31125-1-chris@chris-wilson.co.uk
2019-10-18 14:53:48 +01:00
Matthew Auld
72405c3d78 drm/i915: treat stolen as a region
Convert stolen memory over to a region object. Still leaves open the
question with what to do with pre-allocated objects...

Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Abdiel Janulgue <abdiel.janulgue@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20191018090751.28295-3-matthew.auld@intel.com
2019-10-18 12:41:05 +01:00
Matthew Auld
da1184cd41 drm/i915: treat shmem as a region
Convert shmem to an intel_memory_region.

Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Abdiel Janulgue <abdiel.janulgue@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20191018090751.28295-2-matthew.auld@intel.com
2019-10-18 12:41:03 +01:00
Abdiel Janulgue
3aae9d0853 drm/i915: enumerate and init each supported region
Nothing to enumerate yet...

Signed-off-by: Abdiel Janulgue <abdiel.janulgue@linux.intel.com>
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20191018090751.28295-1-matthew.auld@intel.com
2019-10-18 12:41:02 +01:00
Zhenzhong Duan
228d120051 x86/boot/acpi: Move get_cmdline_acpi_rsdp() under #ifdef guard
When building with "EXTRA_CFLAGS=-Wall" gcc warns:

arch/x86/boot/compressed/acpi.c:29:30: warning: get_cmdline_acpi_rsdp defined but not used [-Wunused-function]

get_cmdline_acpi_rsdp() is only used when CONFIG_RANDOMIZE_BASE and
CONFIG_MEMORY_HOTREMOVE are both enabled, so any build where one of these
config options is disabled has this issue.

Move the function under the same ifdef guard as the call site.

[ tglx: Add context to the changelog so it becomes useful ]

Fixes: 41fa1ee9c6 ("acpi: Ignore acpi_rsdp kernel param when the kernel has been locked down")
Signed-off-by: Zhenzhong Duan <zhenzhong.duan@oracle.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lkml.kernel.org/r/1569719633-32164-1-git-send-email-zhenzhong.duan@oracle.com
2019-10-18 13:33:38 +02:00
Andrea Parri
f7c0f50f18 x86/hyperv: Set pv_info.name to "Hyper-V"
Michael reported that the x86/hyperv initialization code prints the
following dmesg when running in a VM on Hyper-V:

  [    0.000738] Booting paravirtualized kernel on bare hardware

Let the x86/hyperv initialization code set pv_info.name to "Hyper-V" so
dmesg reports correctly:

  [    0.000172] Booting paravirtualized kernel on Hyper-V

[ tglx: Folded build fix provided by Yue ]

Reported-by: Michael Kelley <mikelley@microsoft.com>
Signed-off-by: Andrea Parri <parri.andrea@gmail.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Wei Liu <wei.liu@kernel.org>
Reviewed-by: Michael Kelley <mikelley@microsoft.com>
Cc: YueHaibing <yuehaibing@huawei.com>
Link: https://lkml.kernel.org/r/20191015103502.13156-1-parri.andrea@gmail.com
2019-10-18 13:33:38 +02:00
Chunming Zhou
2093dea3de drm/syncobj: extend syncobj query ability v3
user space needs a flexiable query ability.
So that umd can get last signaled or submitted point.
v2:
add sanitizer checking.
v3:
rebase

Change-Id: I6512b430524ebabe715e602a2bf5abb0a7e780ea
Signed-off-by: Chunming Zhou <david1.zhou@amd.com>
Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: Christian König <Christian.Koenig@amd.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
Link: https://patchwork.freedesktop.org/series/64044/
2019-10-18 12:24:56 +02:00
Chris Wilson
253a774bb0 drm/i915/execlists: Don't merely skip submission if maybe timeslicing
Normally, we try and skip submission if ELSP[1] is filled. However, we
may desire to enable timeslicing due to the queue priority, even if
ELSP[1] itself does not require timeslicing. That is the queue is equal
priority to ELSP[0] and higher priority then ELSP[1]. Previously, we
would wait until the context switch to preempt the current ELSP[1], but
with timeslicing, we want to preempt ELSP[0] and replace it with the
queue.

In writing the test case, it become quickly apparent that we were also
suppressing the tasklet during promotion and so failing to notice when
the queue started requiring timeslicing.

Fixes: 2229adc813 ("drm/i915/execlist: Trim immediate timeslice expiry")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191018072027.31948-1-chris@chris-wilson.co.uk
2019-10-18 11:23:26 +01:00
Tvrtko Ursulin
fb26eee060 drm/i915/pmu: Fix uninitialized variable on error path
If name allocation failed the log message will contain an uninitialized
error code which can be confusing.

Fixes: 05488673a4 ("drm/i915/pmu: Support multiple GPUs")
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20191018090514.1818-1-tvrtko.ursulin@linux.intel.com
[tursulin: Commit message spelling fix.]
2019-10-18 11:16:41 +01:00
Ben Dooks (Codethink)
be428f2451 drm/arm: make undeclared items static
Make the following items static to avoid clashes with
other parts of the kernel (dev_attr_core_id) or just
silence the following sparse warning:

drivers/gpu/drm/arm/malidp_drv.c:371:24: warning: symbol 'malidp_fb_create' was not declared. Should it be static?
drivers/gpu/drm/arm/malidp_drv.c:494:6: warning: symbol 'malidp_error_stats_dump' was not declared. Should it be static?
drivers/gpu/drm/arm/malidp_drv.c:668:1: warning: symbol 'dev_attr_core_id' was not declared. Should it be static?

Signed-off-by: Ben Dooks (Codethink) <ben.dooks@codethink.co.uk>
Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191017111756.12861-1-ben.dooks@codethink.co.uk
2019-10-18 10:52:37 +01:00
Rafael J. Wysocki
ffba17bb33 Merge branch 'acpi-tables'
* acpi-tables:
  ACPI: HMAT: ACPI_HMAT_MEMORY_PD_VALID is deprecated since ACPI-6.3
2019-10-18 10:39:21 +02:00
John Garry
56a0b978d4 ACPI: CPPC: Set pcc_data[pcc_ss_id] to NULL in acpi_cppc_processor_exit()
When enabling KASAN and DEBUG_TEST_DRIVER_REMOVE, I find this KASAN
warning:

[   20.872057] BUG: KASAN: use-after-free in pcc_data_alloc+0x40/0xb8
[   20.878226] Read of size 4 at addr ffff00236cdeb684 by task swapper/0/1
[   20.884826]
[   20.886309] CPU: 19 PID: 1 Comm: swapper/0 Not tainted 5.4.0-rc1-00009-ge7f7df3db5bf-dirty #289
[   20.894994] Hardware name: Huawei D06 /D06, BIOS Hisilicon D06 UEFI RC0 - V1.16.01 03/15/2019
[   20.903505] Call trace:
[   20.905942]  dump_backtrace+0x0/0x200
[   20.909593]  show_stack+0x14/0x20
[   20.912899]  dump_stack+0xd4/0x130
[   20.916291]  print_address_description.isra.9+0x6c/0x3b8
[   20.921592]  __kasan_report+0x12c/0x23c
[   20.925417]  kasan_report+0xc/0x18
[   20.928808]  __asan_load4+0x94/0xb8
[   20.932286]  pcc_data_alloc+0x40/0xb8
[   20.935938]  acpi_cppc_processor_probe+0x4e8/0xb08
[   20.940717]  __acpi_processor_start+0x48/0xb0
[   20.945062]  acpi_processor_start+0x40/0x60
[   20.949235]  really_probe+0x118/0x548
[   20.952887]  driver_probe_device+0x7c/0x148
[   20.957059]  device_driver_attach+0x94/0xa0
[   20.961231]  __driver_attach+0xa4/0x110
[   20.965055]  bus_for_each_dev+0xe8/0x158
[   20.968966]  driver_attach+0x30/0x40
[   20.972531]  bus_add_driver+0x234/0x2f0
[   20.976356]  driver_register+0xbc/0x1d0
[   20.980182]  acpi_processor_driver_init+0x40/0xe4
[   20.984875]  do_one_initcall+0xb4/0x254
[   20.988700]  kernel_init_freeable+0x24c/0x2f8
[   20.993047]  kernel_init+0x10/0x118
[   20.996524]  ret_from_fork+0x10/0x18
[   21.000087]
[   21.001567] Allocated by task 1:
[   21.004785]  save_stack+0x28/0xc8
[   21.008089]  __kasan_kmalloc.isra.9+0xbc/0xd8
[   21.012435]  kasan_kmalloc+0xc/0x18
[   21.015913]  pcc_data_alloc+0x94/0xb8
[   21.019564]  acpi_cppc_processor_probe+0x4e8/0xb08
[   21.024343]  __acpi_processor_start+0x48/0xb0
[   21.028689]  acpi_processor_start+0x40/0x60
[   21.032860]  really_probe+0x118/0x548
[   21.036512]  driver_probe_device+0x7c/0x148
[   21.040684]  device_driver_attach+0x94/0xa0
[   21.044855]  __driver_attach+0xa4/0x110
[   21.048680]  bus_for_each_dev+0xe8/0x158
[   21.052591]  driver_attach+0x30/0x40
[   21.056155]  bus_add_driver+0x234/0x2f0
[   21.059980]  driver_register+0xbc/0x1d0
[   21.063805]  acpi_processor_driver_init+0x40/0xe4
[   21.068497]  do_one_initcall+0xb4/0x254
[   21.072322]  kernel_init_freeable+0x24c/0x2f8
[   21.076667]  kernel_init+0x10/0x118
[   21.080144]  ret_from_fork+0x10/0x18
[   21.083707]
[   21.085186] Freed by task 1:
[   21.088056]  save_stack+0x28/0xc8
[   21.091360]  __kasan_slab_free+0x118/0x180
[   21.095445]  kasan_slab_free+0x10/0x18
[   21.099183]  kfree+0x80/0x268
[   21.102139]  acpi_cppc_processor_exit+0x1a8/0x1b8
[   21.106832]  acpi_processor_stop+0x70/0x80
[   21.110917]  really_probe+0x174/0x548
[   21.114568]  driver_probe_device+0x7c/0x148
[   21.118740]  device_driver_attach+0x94/0xa0
[   21.122912]  __driver_attach+0xa4/0x110
[   21.126736]  bus_for_each_dev+0xe8/0x158
[   21.130648]  driver_attach+0x30/0x40
[   21.134212]  bus_add_driver+0x234/0x2f0
[   21.0x10/0x18
[   21.161764]
[   21.163244] The buggy address belongs to the object at ffff00236cdeb600
[   21.163244]  which belongs to the cache kmalloc-256 of size 256
[   21.175750] The buggy address is located 132 bytes inside of
[   21.175750]  256-byte region [ffff00236cdeb600, ffff00236cdeb700)
[   21.187473] The buggy address belongs to the page:
[   21.192254] page:fffffe008d937a00 refcount:1 mapcount:0 mapping:ffff002370c0fa00 index:0x0 compound_mapcount: 0
[   21.202331] flags: 0x1ffff00000010200(slab|head)
[   21.206940] raw: 1ffff00000010200 dead000000000100 dead000000000122 ffff002370c0fa00
[   21.214671] raw: 0000000000000000 00000000802a002a 00000001ffffffff 0000000000000000
[   21.222400] page dumped because: kasan: bad access detected
[   21.227959]
[   21.229438] Memory state around the buggy address:
[   21.234218]  ffff00236cdeb580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[   21.241427]  ffff00236cdeb600: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[   21.248637] >ffff00236cdeb680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[   21.255845]                    ^
[   21.259062]  ffff00236cdeb700: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[   21.266272]  ffff00236cdeb780: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[   21.273480] ==================================================================

It seems that global pcc_data[pcc_ss_id] can be freed in
acpi_cppc_processor_exit(), but we may later reference this value, so
NULLify it when freed.

Also remove the useless setting of data "pcc_channel_acquired", which
we're about to free.

Fixes: 85b1407bf6 ("ACPI / CPPC: Make CPPC ACPI driver aware of PCC subspace IDs")
Signed-off-by: John Garry <john.garry@huawei.com>
Cc: 4.15+ <stable@vger.kernel.org> # 4.15+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2019-10-18 10:36:37 +02:00
Rafael J. Wysocki
b23eb5c74e Merge branches 'pm-cpufreq' and 'pm-sleep'
* pm-cpufreq:
  ACPI: processor: Avoid NULL pointer dereferences at init time
  cpufreq: Avoid cpufreq_suspend() deadlock on system shutdown

* pm-sleep:
  PM: sleep: include <linux/pm_runtime.h> for pm_wq
  ACPI: PM: Drop Dell XPS13 9360 from LPS0 Idle _DSM blacklist
2019-10-18 10:27:55 +02:00
Sean Wang
0cc76d2b14 net: Update address for MediaTek ethernet driver in MAINTAINERS
Update maintainers for MediaTek ethernet driver with Mark Lee.
He is familiar with MediaTek mt762x series ethernet devices and
will keep following maintenance from the vendor side.

Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Signed-off-by: Mark Lee <Mark-MC.Lee@mediatek.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-10-17 17:00:30 -07:00
Linus Torvalds
0e2adab6cf arm64 fixes for -rc4
- Work around Cavium/Marvell ThunderX2 erratum #219
 
 - Fix regression in mlock() ABI caused by sign-extension of TTBR1 addresses
 
 - More fixes to the spurious kernel fault detection logic
 
 - Fix pathological preemption race when enabling some CPU features at boot
 
 - Drop broken kcore macros in favour of generic implementations
 
 - Fix userspace view of ID_AA64ZFR0_EL1 when SVE is disabled
 
 - Avoid NULL dereference on allocation failure during hibernation
 -----BEGIN PGP SIGNATURE-----
 
 iQFEBAABCgAuFiEEPxTL6PPUbjXGY88ct6xw3ITBYzQFAl2o1IsQHHdpbGxAa2Vy
 bmVsLm9yZwAKCRC3rHDchMFjNEzXCACi8bK3PWUJ9R6DcUeDNFuSMT0d2C/8CRNj
 mKnYkHx/GSChLBe3ZsNYbH5wnh70ItKzUUyMwMlwKevpr0kvLn0AN+WuSpP77Thk
 qFuaO5EC10V039SXoAjOPs4Jxwoi6NaShDJYkLmr2kwp0g7dEol+8C80V1fQVqgx
 oSmFcrYlqki1qhz8e1qCY4K8fAt6VdMt8OcouXs58ETFqsUFBFy/xx9Vsa0AQKkN
 ZU8lzGIYNVLtA1G7wei7IuoKgYQ0t7XMynsve9P9i+RXmLrIbeyLpeZyn+3GW0jO
 r3Epj0lYqKe8IZ+eTUDu3KvKHHdICHIDBDxP2c66hfgkw0prn/vU
 =9E3e
 -----END PGP SIGNATURE-----

Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux

Pull arm64 fixes from Will Deacon:
 "The main thing here is a long-awaited workaround for a CPU erratum on
  ThunderX2 which we have developed in conjunction with engineers from
  Cavium/Marvell.

  At the moment, the workaround is unconditionally enabled for affected
  CPUs at runtime but we may add a command-line option to disable it in
  future if performance numbers show up indicating a significant cost
  for real workloads.

  Summary:

   - Work around Cavium/Marvell ThunderX2 erratum #219

   - Fix regression in mlock() ABI caused by sign-extension of TTBR1 addresses

   - More fixes to the spurious kernel fault detection logic

   - Fix pathological preemption race when enabling some CPU features at boot

   - Drop broken kcore macros in favour of generic implementations

   - Fix userspace view of ID_AA64ZFR0_EL1 when SVE is disabled

   - Avoid NULL dereference on allocation failure during hibernation"

* tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
  arm64: tags: Preserve tags for addresses translated via TTBR1
  arm64: mm: fix inverted PAR_EL1.F check
  arm64: sysreg: fix incorrect definition of SYS_PAR_EL1_F
  arm64: entry.S: Do not preempt from IRQ before all cpufeatures are enabled
  arm64: hibernate: check pgd table allocation
  arm64: cpufeature: Treat ID_AA64ZFR0_EL1 as RAZ when SVE is not enabled
  arm64: Fix kcore macros after 52-bit virtual addressing fallout
  arm64: Allow CAVIUM_TX2_ERRATUM_219 to be selected
  arm64: Avoid Cavium TX2 erratum 219 when switching TTBR
  arm64: Enable workaround for Cavium TX2 erratum 219 when running SMT
  arm64: KVM: Trap VM ops when ARM64_WORKAROUND_CAVIUM_TX2_219_TVM is set
2019-10-17 17:00:14 -07:00
Wei Wang
5018c59607 ipv4: fix race condition between route lookup and invalidation
Jesse and Ido reported the following race condition:
<CPU A, t0> - Received packet A is forwarded and cached dst entry is
taken from the nexthop ('nhc->nhc_rth_input'). Calls skb_dst_set()

<t1> - Given Jesse has busy routers ("ingesting full BGP routing tables
from multiple ISPs"), route is added / deleted and rt_cache_flush() is
called

<CPU B, t2> - Received packet B tries to use the same cached dst entry
from t0, but rt_cache_valid() is no longer true and it is replaced in
rt_cache_route() by the newer one. This calls dst_dev_put() on the
original dst entry which assigns the blackhole netdev to 'dst->dev'

<CPU A, t3> - dst_input(skb) is called on packet A and it is dropped due
to 'dst->dev' being the blackhole netdev

There are 2 issues in the v4 routing code:
1. A per-netns counter is used to do the validation of the route. That
means whenever a route is changed in the netns, users of all routes in
the netns needs to redo lookup. v6 has an implementation of only
updating fn_sernum for routes that are affected.
2. When rt_cache_valid() returns false, rt_cache_route() is called to
throw away the current cache, and create a new one. This seems
unnecessary because as long as this route does not change, the route
cache does not need to be recreated.

To fully solve the above 2 issues, it probably needs quite some code
changes and requires careful testing, and does not suite for net branch.

So this patch only tries to add the deleted cached rt into the uncached
list, so user could still be able to use it to receive packets until
it's done.

Fixes: 95c47f9cf5 ("ipv4: call dst_dev_put() properly")
Signed-off-by: Wei Wang <weiwan@google.com>
Reported-by: Ido Schimmel <idosch@idosch.org>
Reported-by: Jesse Hathaway <jesse@mbuki-mvuki.org>
Tested-by: Jesse Hathaway <jesse@mbuki-mvuki.org>
Acked-by: Martin KaFai Lau <kafai@fb.com>
Cc: David Ahern <dsahern@gmail.com>
Reviewed-by: Ido Schimmel <idosch@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-10-17 16:44:03 -07:00
Linus Torvalds
ad32fd7426 Xtensa fixes for v5.4:
- fix {get,put}_user() for 64bit values;
 - fix warning about static EXPORT_SYMBOL from modpost;
 - fix PCI IO ports mapping for the virt board;
 - fix pasto in change_bit for exclusive access option.
 -----BEGIN PGP SIGNATURE-----
 
 iQJHBAABCgAxFiEEK2eFS5jlMn3N6xfYUfnMkfg/oEQFAl2o7kQTHGpjbXZia2Jj
 QGdtYWlsLmNvbQAKCRBR+cyR+D+gRFpPD/98Tk1QIOoNxsUbxq6ugLfs5m7ReysJ
 XAhwFf2XkCxDJOOOFCYElaiXPpiPD7PIfzY/fnPMQZxaBsMMLZArEsqXAk1J+u0i
 /7rZdXE7q+CIjSUj67xiF7HxQFcFcH+/TIRJeSOsIXAELKY6EMaXZieFK3kITDXo
 I72G7ozsdDOsC4ZtTqa/f/YZDrgqp6y+2f5lBcWCVgrrtPsR+IidD+mJN146t+rh
 wK2J3CI3FS1AfyXp/W077YejNesZS0iIXJ2YyMQO2eUXaMvYb4S1ochp7XSpfJBE
 nlk1jL+R2PdhdvX2RdPJ+sds3Ael2G9b+FVc0oD0IgVRNYH1Eky9eYcRll94cVwL
 rLnrw0lJ4mLDk6zQE1IZBdMFFEDhteQBVP9duvvimJKd8OfFWU+xqSb6Q+kzUrk7
 0K7gBrTZo3GwYXdt03drK532wU0oaJVf0MhfkTJQhyIJH8vkdsxw7wqa1AfEP7I/
 LdEJqeWMMVbQ8X6B1OvgikA9Eela+QjFLFdFKGAchcAHfmfa9YUz4Mcs49UQwSYY
 KkrSk6GcLov/NINKzm+pJZ7pVr7MXWi1fe/xGmZU94Vd9S0efKEoGxZfdsPGfU+P
 Akdg/0SP/h5ZmptrHhGXFDClMvGTI1g/IRUO+rXD1KjoGl4vRtjI1Yp9NzMDQ8PF
 qBOW4OfKZ5JeqQ==
 =Jv0A
 -----END PGP SIGNATURE-----

Merge tag 'xtensa-20191017' of git://github.com/jcmvbkbc/linux-xtensa

Pull Xtensa fixes from Max Filippov:

 - fix {get,put}_user() for 64bit values

 - fix warning about static EXPORT_SYMBOL from modpost

 - fix PCI IO ports mapping for the virt board

 - fix pasto in change_bit for exclusive access option

* tag 'xtensa-20191017' of git://github.com/jcmvbkbc/linux-xtensa:
  xtensa: fix change_bit in exclusive access option
  xtensa: virt: fix PCI IO ports mapping
  xtensa: drop EXPORT_SYMBOL for outs*/ins*
  xtensa: fix type conversion in __get_user_[no]check
  xtensa: clean up assembly arguments in uaccess macros
  xtensa: fix {get,put}_user() for 64bit values
2019-10-17 16:42:50 -07:00
Stefano Brivio
595e0651d0 ipv4: Return -ENETUNREACH if we can't create route but saddr is valid
...instead of -EINVAL. An issue was found with older kernel versions
while unplugging a NFS client with pending RPCs, and the wrong error
code here prevented it from recovering once link is back up with a
configured address.

Incidentally, this is not an issue anymore since commit 4f8943f808
("SUNRPC: Replace direct task wakeups from softirq context"), included
in 5.2-rc7, had the effect of decoupling the forwarding of this error
by using SO_ERROR in xs_wake_error(), as pointed out by Benjamin
Coddington.

To the best of my knowledge, this isn't currently causing any further
issue, but the error code doesn't look appropriate anyway, and we
might hit this in other paths as well.

In detail, as analysed by Gonzalo Siero, once the route is deleted
because the interface is down, and can't be resolved and we return
-EINVAL here, this ends up, courtesy of inet_sk_rebuild_header(),
as the socket error seen by tcp_write_err(), called by
tcp_retransmit_timer().

In turn, tcp_write_err() indirectly calls xs_error_report(), which
wakes up the RPC pending tasks with a status of -EINVAL. This is then
seen by call_status() in the SUN RPC implementation, which aborts the
RPC call calling rpc_exit(), instead of handling this as a
potentially temporary condition, i.e. as a timeout.

Return -EINVAL only if the input parameters passed to
ip_route_output_key_hash_rcu() are actually invalid (this is the case
if the specified source address is multicast, limited broadcast or
all zeroes), but return -ENETUNREACH in all cases where, at the given
moment, the given source address doesn't allow resolving the route.

While at it, drop the initialisation of err to -ENETUNREACH, which
was added to __ip_route_output_key() back then by commit
0315e38270 ("net: Fix behaviour of unreachable, blackhole and
prohibit routes"), but actually had no effect, as it was, and is,
overwritten by the fib_lookup() return code assignment, and anyway
ignored in all other branches, including the if (fl4->saddr) one:
I find this rather confusing, as it would look like -ENETUNREACH is
the "default" error, while that statement has no effect.

Also note that after commit fc75fc8339 ("ipv4: dont create routes
on down devices"), we would get -ENETUNREACH if the device is down,
but -EINVAL if the source address is specified and we can't resolve
the route, and this appears to be rather inconsistent.

Reported-by: Stefan Walter <walteste@inf.ethz.ch>
Analysed-by: Benjamin Coddington <bcodding@redhat.com>
Analysed-by: Gonzalo Siero <gsierohu@redhat.com>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-10-17 16:36:17 -07:00
Marek Vasut
1d951ba3da net: phy: micrel: Update KSZ87xx PHY name
The KSZ8795 PHY ID is in fact used by KSZ8794/KSZ8795/KSZ8765 switches.
Update the PHY ID and name to reflect that, as this family of switches
is commonly refered to as KSZ87xx

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: David S. Miller <davem@davemloft.net>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: George McCollister <george.mccollister@gmail.com>
Cc: Heiner Kallweit <hkallweit1@gmail.com>
Cc: Sean Nyekjaer <sean.nyekjaer@prevas.dk>
Cc: Tristram Ha <Tristram.Ha@microchip.com>
Cc: Woojung Huh <woojung.huh@microchip.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-10-17 16:31:52 -07:00
Marek Vasut
8b95599c55 net: phy: micrel: Discern KSZ8051 and KSZ8795 PHYs
The KSZ8051 PHY and the KSZ8794/KSZ8795/KSZ8765 switch share exactly the
same PHY ID. Since KSZ8051 is higher in the ksphy_driver[] list of PHYs
in the micrel PHY driver, it is used even with the KSZ87xx switch. This
is wrong, since the KSZ8051 configures registers of the PHY which are
not present on the simplified KSZ87xx switch PHYs and misconfigures
other registers of the KSZ87xx switch PHYs.

Fortunatelly, it is possible to tell apart the KSZ8051 PHY from the
KSZ87xx switch by checking the Basic Status register Bit 0, which is
read-only and indicates presence of the Extended Capability Registers.
The KSZ8051 PHY has those registers while the KSZ87xx switch does not.

This patch implements simple check for the presence of this bit for
both the KSZ8051 PHY and KSZ87xx switch, to let both use the correct
PHY driver instance.

Fixes: 9d162ed69f ("net: phy: micrel: add support for KSZ8795")
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: David S. Miller <davem@davemloft.net>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: George McCollister <george.mccollister@gmail.com>
Cc: Heiner Kallweit <hkallweit1@gmail.com>
Cc: Sean Nyekjaer <sean.nyekjaer@prevas.dk>
Cc: Tristram Ha <Tristram.Ha@microchip.com>
Cc: Woojung Huh <woojung.huh@microchip.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-10-17 16:31:51 -07:00
Tvrtko Ursulin
5d904e3c5d drm/i915: Pass in intel_gt at some for_each_engine sites
Where the function, or code segment, operates on intel_gt, we need to
start passing it instead of i915 to for_each_engine(_masked).

This is another partial step in migration of i915->engines[] to
gt->engines[].

Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20191017094500.21831-2-tvrtko.ursulin@linux.intel.com
2019-10-18 00:06:27 +01:00
Tvrtko Ursulin
a50134b198 drm/i915: Make for_each_engine_masked work on intel_gt
Medium term goal is to eliminate the i915->engine[] array and to get there
we have recently introduced equivalent array in intel_gt. Now we need to
migrate the code further towards this state.

This next step is to eliminate usage of i915->engines[] from the
for_each_engine_masked iterator.

For this to work we also need to use engine->id as index when populating
the gt->engine[] array and adjust the default engine set indexing to use
engine->legacy_idx instead of assuming gt->engines[] indexing.

v2:
  * Populate gt->engine[] earlier.
  * Check that we don't duplicate engine->legacy_idx

v3:
  * Work around the initialization order issue between default_engines()
    and intel_engines_driver_register() which sets engine->legacy_idx for
    now. It will be fixed properly later.

v4:
  * Merge with forgotten v2.5.

Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20191017161852.8836-1-tvrtko.ursulin@linux.intel.com
2019-10-18 00:06:25 +01:00
yangerkun
8b07a65ad3 io_uring: fix logic error in io_timeout
If ctx->cached_sq_head < nxt_sq_head, we should add UINT_MAX to tmp, not
tmp_nxt.

Fixes: 5da0fb1ab3 ("io_uring: consider the overflow of sequence for timeout req")
Signed-off-by: yangerkun <yangerkun@huawei.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2019-10-17 15:49:15 -06:00
Jens Axboe
491381ce07 io_uring: fix up O_NONBLOCK handling for sockets
We've got two issues with the non-regular file handling for non-blocking
IO:

1) We don't want to re-do a short read in full for a non-regular file,
   as we can't just read the data again.
2) For non-regular files that don't support non-blocking IO attempts,
   we need to punt to async context even if the file is opened as
   non-blocking. Otherwise the caller always gets -EAGAIN.

Add two new request flags to handle these cases. One is just a cache
of the inode S_ISREG() status, the other tells io_uring that we always
need to punt this request to async context, even if REQ_F_NOWAIT is set.

Cc: stable@vger.kernel.org
Reported-by: Hrvoje Zeba <zeba.hrvoje@gmail.com>
Tested-by: Hrvoje Zeba <zeba.hrvoje@gmail.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2019-10-17 15:49:11 -06:00
Linus Torvalds
6e8ba0098e Changes since last update:
- Fix a timestamp signedness problem in the new bulkstat ioctl.
 -----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCgAdFiEEUzaAxoMeQq6m2jMV+H93GTRKtOsFAl2l7R8ACgkQ+H93GTRK
 tOtFnw/9GyBxDqODfne2puAb3nISogzVDVRxzo2Ip4fH+djQ8XF0nZgaVmdK45xm
 lD0VNCMT7tb7YA9rIKb+G8WdZDfq5XUs2QOR8RCqg2rCy5Kxww8B0e83ziJ/hz8C
 ebmfuBpNoV3Ul8I4vPN2Qb2nN2wHo8LqMi3GgK3nmv92xuL7Fignh3AxForHSFRz
 VUQF+canS5IQo2KkbKsP92X1r+nwTG/8GL3WNicm4BgeFHcZbMKJn32OSpZHUSGb
 RPEpWD1TAROhjOejFpEqEXmU8x8o0BtErgo3dBgGQTntrq9gOPgOuoot3cyweHZK
 JEtxglnIIbJs0B0sru9ZuN7RkoXZYJjDaTOU8uLst8dwVaoX2kw8siWjQimadKI4
 aI323yHpTTjuzZa2PQRU682fNyVNwcDfQnOss28xQG1wG9Pjxo39AZqhpgR1GtX4
 kgYBVr6oJ/5HrZ5KFghBnjE1+jx4F4axAhgKqmbsg712mZcr1EM4TlFfd/yX6+Sd
 ihHlgSeIiZk+2fthnUwRvPuGSYIimtUAXY5wgRzXnqmCFxy3rPafLo41pPkCcYV4
 wCHdh6YR1H0/wJ9K2iUMxKKrSdu4PcdaprlD7aX7j3u727gybqOqIhaK6GdlxQg8
 zyUZIGQEyR6uTpbtC4xNttZ3OcR5w5u7JjIn6TR3xIws4TkVMwU=
 =WVUx
 -----END PGP SIGNATURE-----

Merge tag 'xfs-5.4-fixes-4' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux

Pull xfs fix from Darrick Wong:
 "The single fix converts the seconds field in the recently added XFS
  bulkstat structure to a signed 64-bit quantity.

  The structure layout doesn't change and so far there are no users of
  the ioctl to break because we only publish xfs ioctl interfaces
  through the XFS userspace development libraries, and we're still
  working on a 5.3 release"

* tag 'xfs-5.4-fixes-4' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux:
  xfs: change the seconds fields in xfs_bulkstat to signed
2019-10-17 14:19:52 -07:00