max597x is hot swap controller.
This regulator driver controls the same & also configures fault
protection features supported by the chip.
Signed-off-by: NPatrick Rudolph <patrick.rudolph@9elements.com>
Signed-off-by: NMarcello Sylvester Bauer <sylv@sylv.io>
Signed-off-by: NNaresh Solanki <Naresh.Solanki@9elements.com>
Link: https://lore.kernel.org/r/20220705122244.472894-4-Naresh.Solanki@9elements.comSigned-off-by: NMark Brown <broonie@kernel.org>

In scmi_regulator_probe(), of_find_node_by_name() will decrease
the refcount of its first argument and we need a of_node_get()
to keep reference balance.
Signed-off-by: NLiang He <windhl@126.com>
Reviewed-by: NCristian Marussi <cristian.marussi@arm.com>
Link: https://lore.kernel.org/r/20220622034816.4094043-1-windhl@126.comSigned-off-by: NMark Brown <broonie@kernel.org>

The set of regulators available in the PM8909 PMIC is similar to PM8916
which is already supported by the driver. s3, s4 and l16 are missing.
However, probing the SPMI hardware identification registers using the
qcom_spmi-regulator driver reveals that the regulators in PM8909 are
actually some kind of mixture between PM8916 and PM8226:

  - ult_lo_smps (= pm8916_buck_lvo_smps): s1
  - ult_ho_smps (= pm8916_buck_hvo_smps): s2
  - ult_nldo (= pm8916_nldo): l1, l2, l3, l10
  - ult_pldo (= pm8916_pldo): l4, l8, l9, l12-l15, l17, l18
  - pldo (= pm8226_pldo): l5, l6, l7, l11

Use this mapping to add the rpm_regulator_data for PM8909 by reusing
the existing regulator definitions.
Signed-off-by: NStephan Gerhold <stephan.gerhold@kernkonzept.com>
Link: https://lore.kernel.org/r/20220623094614.1410180-4-stephan.gerhold@kernkonzept.comSigned-off-by: NMark Brown <broonie@kernel.org>

The PM8916 device specification [1] documents a programmable range of
1.75V to 3.337V with 12.5mV steps for the PMOS LDOs in PM8916. This
range is also used when controlling the regulator directly using the
qcom_spmi-regulator driver ("ult_pldo" there).

However, for some reason the qcom_smd-regulator driver allows a much
larger range for the same hardware component. This could be simply a
typo, since the start of the range is essentially just missing a '1'.

In practice this does not cause any major problems, since the driver
just sends the actual voltage to the RPM firmware instead of making use
of the incorrect voltage selector. Still, having the wrong range there
is confusing and prevents the regulator core from validating requests
correctly.

[1]: https://developer.qualcomm.com/download/sd410/pm8916pm8916-1-power-management-ic-device-specification.pdf

Fixes: 57d65676 ("regulator: qcom-smd: Add PM8916 support")
Signed-off-by: NStephan Gerhold <stephan.gerhold@kernkonzept.com>
Link: https://lore.kernel.org/r/20220623094614.1410180-2-stephan.gerhold@kernkonzept.comSigned-off-by: NMark Brown <broonie@kernel.org>

'platform_device_id' struct is defined in 'mod_devicetable.h'.
Even 'of.h' also includes this header usage. The 'of.h' cannot be removed
due to 'of_match_ptr' function.
Signed-off-by: NChiYuan Huang <cy_huang@richtek.com>
Reviewed-by: NAngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/1656466861-7737-2-git-send-email-u0084500@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

From the common binding, 'enable-gpio' or 'enable-gpios' are all well
for external 'enable' gpio.

'gpiod_get_from_of_node' only parse the 'enable' property, it need to
add the gpio suffix. It's more convenient to use fwnode_gpiod_get_index.
Although fwnode parsing is not preferred, but 'of_parse_cb' already can
guarantee the callback will only be used by regulator of_node parsing.
Signed-off-by: NChiYuan Huang <cy_huang@richtek.com>
Link: https://lore.kernel.org/r/1656466861-7737-1-git-send-email-u0084500@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

Add mt6370 DisplayBias and VibLDO support.
Signed-off-by: NChiYuan Huang <cy_huang@richtek.com>
Link: https://lore.kernel.org/r/20220623115631.22209-10-peterwu.pub@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

Add RT5120 PMIC regulator support.

It integrates 4 buck convertes, 1 LDO voltage regulator, 1 external
enable signal to control the external power source.
Signed-off-by: NChiYuan Huang <cy_huang@richtek.com>
Link: https://lore.kernel.org/r/1655892104-10874-4-git-send-email-u0084500@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

backlight_properties.fb_blank is deprecated. The states it represents
are handled by other properties; but instead of accessing those
properties directly, drivers should use the helpers provided by
backlight.h.

Instead of retrieving the backlight brightness in struct
backlight_properties manually, and then checking whether the backlight
should be on at all, use backlight_get_brightness() which does all
this and insulates this from future changes.
Signed-off-by: NStephen Kitt <steve@sk2.org>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20220607185304.1128962-1-steve@sk2.orgSigned-off-by: NMark Brown <broonie@kernel.org>

Add the get_voltage OP to MP5496 ops using the generic rpm_reg_get_voltage.
Signed-off-by: NRobert Marko <robimarko@gmail.com>
Link: https://lore.kernel.org/r/20220604193300.125758-1-robimarko@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

Currently set MP5496 Buck and LDO ranges dont match its datasheet[1].
According to the datasheet:
Buck range is 0.6-2.1875V with a 12.5mV step
LDO range is 0.8-3.975V with a 25mV step.

So, correct the ranges according to the datasheet[1].

[1] https://www.monolithicpower.com/en/documentview/productdocument/index/version/2/document_type/Datasheet/lang/en/sku/MP5496GR/document_id/6906/Signed-off-by: NRobert Marko <robimarko@gmail.com>
Link: https://lore.kernel.org/r/20220604193300.125758-2-robimarko@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

Driver does not seem to utilize anything from the kernel.h, compiles
and works fine for me without it.

So remove kernel.h include as it pulls in a lot of unused stuff.
Signed-off-by: NRobert Marko <robimarko@gmail.com>
Cc: christophe.jaillet@wanadoo.fr
Link: https://lore.kernel.org/r/20220607124759.775133-1-robimarko@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

If the node for the match name cannot be found, 'of_regulator_match' will
returns init_data as NULL for this regulator.

Add the check for the init_data. If it's NULL, make 'rt5190a_of_parse_cb'
function directly return.
Signed-off-by: NChiYuan Huang <cy_huang@richtek.com>
Link: https://lore.kernel.org/r/1654148646-12182-1-git-send-email-u0084500@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

MP5496 is the updated version of MP5416 with the only difference being
that now all Buck regulators have the same 0.6-2.1875V range with a 12.5mV
step.
Signed-off-by: NRobert Marko <robimarko@gmail.com>
Acked-by: NSaravanan Sekar <sravanhome@gmail.com>
Link: https://lore.kernel.org/r/20220604145816.47576-4-robimarko@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

In preparation for adding support for MP5496 which slightly differs from
MP5416 convert the driver to use OF match data instead of always using the
MP5416 regulator_desc for regulator registration.
Signed-off-by: NRobert Marko <robimarko@gmail.com>
Acked-by: NSaravanan Sekar <sravanhome@gmail.com>
Link: https://lore.kernel.org/r/20220604145816.47576-3-robimarko@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

Sort the header include list alphabetically.
Signed-off-by: NRobert Marko <robimarko@gmail.com>
Link: https://lore.kernel.org/r/20220604145816.47576-2-robimarko@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

It used to grab an extra reference to struct file rather than
just transferring to caller the one it had removed from descriptor
table.  New variant doesn't, and callers need to be adjusted.

Reported-and-tested-by: syzbot+47dd250f527cb7bebf24@syzkaller.appspotmail.com
Fixes: 6319194e ("Unify the primitives for file descriptor closing")
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

Keep the pa_path (hardware path) of the graphics card in sti_struct and use
this info to give more useful info which card is currently being used.
Signed-off-by: NHelge Deller <deller@gmx.de>
Cc: stable@vger.kernel.org   # v5.10+

Implement fb_is_primary_device() function, so that fbcon detects if this
framebuffer belongs to the default graphics card which was used to start
the system.
Signed-off-by: NHelge Deller <deller@gmx.de>
Cc: stable@vger.kernel.org   # v5.10+

Commit 23cfbc6e ("firmware: Add the support for ZSTD-compressed
firmware files") added support for ZSTD compression, but in the process
also made the previously default XZ compression a config option.

That means that anybody who upgrades their kernel and does a

    make oldconfig

to update their configuration, will end up without the XZ compression
that the configuration used to have.

Add the 'default y' to make sure this doesn't happen.

The whole compression question should probably be improved upon, since
it is now possible to "enable" compression in the kernel config but not
enable any actual compression algorithm, which makes it all very
useless.  It makes no sense to ask Kconfig questions that enable
situations that are nonsensical like that.

This at least fixes the immediate problem of a kernel update resulting
in a nonbootable machine because of a missed option.

Fixes: 23cfbc6e ("firmware: Add the support for ZSTD-compressed  firmware files")
Cc: Takashi Iwai <tiwai@suse.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Since we had to effectively reverted
commit 35a67236 ("driver core: Ensure wait_for_device_probe() waits
until the deferred_probe_timeout fires") in an earlier patch, a non-zero
deferred_probe_timeout will break NFS rootfs mounting [1] again. So, set
the default back to zero until we can fix that.

[1] - https://lore.kernel.org/lkml/TYAPR01MB45443DF63B9EF29054F7C41FD8C60@TYAPR01MB4544.jpnprd01.prod.outlook.com/

Fixes: 2b28a1a8 ("driver core: Extend deferred probe timeout on driver registration")
Cc: Mark Brown <broonie@kernel.org>
Cc: Rob Herring <robh@kernel.org>
Reported-by: NNathan Chancellor <nathan@kernel.org>
Reported-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Tested-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NSaravana Kannan <saravanak@google.com>
Link: https://lore.kernel.org/r/20220526034609.480766-3-saravanak@google.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Mounting NFS rootfs was timing out when deferred_probe_timeout was
non-zero [1].  This was because ip_auto_config() initcall times out
waiting for the network interfaces to show up when
deferred_probe_timeout was non-zero. While ip_auto_config() calls
wait_for_device_probe() to make sure any currently running deferred
probe work or asynchronous probe finishes, that wasn't sufficient to
account for devices being deferred until deferred_probe_timeout.

Commit 35a67236 ("driver core: Ensure wait_for_device_probe() waits
until the deferred_probe_timeout fires") tried to fix that by making
sure wait_for_device_probe() waits for deferred_probe_timeout to expire
before returning.

However, if wait_for_device_probe() is called from the kernel_init()
context:

- Before deferred_probe_initcall() [2], it causes the boot process to
  hang due to a deadlock.

- After deferred_probe_initcall() [3], it blocks kernel_init() from
  continuing till deferred_probe_timeout expires and beats the point of
  deferred_probe_timeout that's trying to wait for userspace to load
  modules.

Neither of this is good. So revert the changes to
wait_for_device_probe().

[1] - https://lore.kernel.org/lkml/TYAPR01MB45443DF63B9EF29054F7C41FD8C60@TYAPR01MB4544.jpnprd01.prod.outlook.com/
[2] - https://lore.kernel.org/lkml/YowHNo4sBjr9ijZr@dev-arch.thelio-3990X/
[3] - https://lore.kernel.org/lkml/Yo3WvGnNk3LvLb7R@linutronix.de/

Fixes: 35a67236 ("driver core: Ensure wait_for_device_probe() waits until the deferred_probe_timeout fires")
Cc: John Stultz <jstultz@google.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: Rob Herring <robh@kernel.org>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Cc: Robin Murphy <robin.murphy@arm.com>
Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Sudeep Holla <sudeep.holla@arm.com>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Naresh Kamboju <naresh.kamboju@linaro.org>
Cc: Basil Eljuse <Basil.Eljuse@arm.com>
Cc: Ferry Toth <fntoth@gmail.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Anders Roxell <anders.roxell@linaro.org>
Cc: linux-pm@vger.kernel.org
Reported-by: NNathan Chancellor <nathan@kernel.org>
Reported-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Tested-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Acked-by: NJohn Stultz <jstultz@google.com>
Signed-off-by: NSaravana Kannan <saravanak@google.com>
Link: https://lore.kernel.org/r/20220526034609.480766-2-saravanak@google.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: NRafael J. Wysocki <rafael@kernel.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The smu_v1X_0_set_allowed_mask() uses bitmap_copy() to convert
bitmap to 32-bit array. This may be wrong due to endiannes issues.
Fix it by switching to bitmap_{from,to}_arr32.

CC: Alexander Gordeev <agordeev@linux.ibm.com>
CC: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
CC: Christian Borntraeger <borntraeger@linux.ibm.com>
CC: Claudio Imbrenda <imbrenda@linux.ibm.com>
CC: David Hildenbrand <david@redhat.com>
CC: Heiko Carstens <hca@linux.ibm.com>
CC: Janosch Frank <frankja@linux.ibm.com>
CC: Rasmus Villemoes <linux@rasmusvillemoes.dk>
CC: Sven Schnelle <svens@linux.ibm.com>
CC: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: NYury Norov <yury.norov@gmail.com>

bcm6345_l1_of_init() calls cpumask_weight() to check if any bit of a given
cpumask is set. We can do it more efficiently with cpumask_empty() because
cpumask_empty() stops traversing the cpumask as soon as it finds first set
bit, while cpumask_weight() counts all bits unconditionally.
Signed-off-by: NYury Norov <yury.norov@gmail.com>
Acked-by: NFlorian Fainelli <f.fainelli@gmail.com>

i915_pmu_cpu_online() calls cpumask_weight() to check if any bit of a
given cpumask is set. We can do it more efficiently with cpumask_empty()
because cpumask_empty() stops traversing the cpumask as soon as it finds
first set bit, while cpumask_weight() counts all bits unconditionally.
Signed-off-by: NYury Norov <yury.norov@gmail.com>
Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>

LoongArch maintains cache coherency in hardware, but its WUC attribute
(Weak-ordered UnCached, which is similar to WC) is out of the scope of
cache coherency machanism. This means WUC can only used for write-only
memory regions.

Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: NWANG Xuerui <git@xen0n.name>
Reviewed-by: NJiaxun Yang <jiaxun.yang@flygoat.com>
Signed-off-by: NHuacai Chen <chenhuacai@loongson.cn>

liointc driver is shared by MIPS and LoongArch, this patch adjust the
code to fix build error for LoongArch.
Acked-by: NMarc Zyngier <maz@kernel.org>
Reviewed-by: NWANG Xuerui <git@xen0n.name>
Reviewed-by: NJiaxun Yang <jiaxun.yang@flygoat.com>
Signed-off-by: NHuacai Chen <chenhuacai@loongson.cn>

HTVEC will be shared by both MIPS-based and LoongArch-based Loongson
processors (not only Loongson-3), so we adjust its description. HTPIC is
only used by MIPS-based Loongson, so we add a MIPS dependency.
Acked-by: NMarc Zyngier <maz@kernel.org>
Reviewed-by: NWANG Xuerui <git@xen0n.name>
Reviewed-by: NJiaxun Yang <jiaxun.yang@flygoat.com>
Signed-off-by: NHuacai Chen <chenhuacai@loongson.cn>

Add PCI ID for Ethernet TSN Controller on RPL-P.
Signed-off-by: NMichael Sit Wei Hong <michael.wei.hong.sit@intel.com>
Link: https://lore.kernel.org/r/20220602073507.3955721-1-michael.wei.hong.sit@intel.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>

I have a board where these two lines are always printed during boot:

   imx-dwmac 30bf0000.ethernet: Cannot register the MDIO bus
   imx-dwmac 30bf0000.ethernet: stmmac_dvr_probe: MDIO bus (id: 1) registration failed

It's perfectly fine, and the device is successfully (and silently, as
far as the console goes) probed later.

Use dev_err_probe() instead, which will demote these messages to debug
level (thus removing the alarming messages from the console) when the
error is -EPROBE_DEFER, and also has the advantage of including the
error code if/when it happens to be something other than -EPROBE_DEFER.

While here, add the missing \n to one of the format strings.
Signed-off-by: NRasmus Villemoes <linux@rasmusvillemoes.dk>
Link: https://lore.kernel.org/r/20220602074840.1143360-1-linux@rasmusvillemoes.dkSigned-off-by: NJakub Kicinski <kuba@kernel.org>

The "data->block[0]" variable comes from the user and is a number
between 0-255.  It needs to be capped to prevent writing beyond the end
of dma_buffer[].

Fixes: 5e9a97b1 ("i2c: ismt: Adding support for I2C_SMBUS_BLOCK_PROC_CALL")
Reported-and-tested-by: NZheyu Ma <zheyuma97@gmail.com>
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The bio and rq fields of struct nullb_cmd are now overlapping in a
union. So we cannot use a test on ->bio being non-NULL to detect the
NULL_Q_BIO queue mode. null_zone_write() use such broken test to set the
sector position of a zone append write in the command bio or request.
When the null_blk device uses the NULL_Q_MQ queue mode,
null_zone_write() wrongly end up setting the bio sector position,
resulting in the command request to be broken and random crashes
following.

Fix this by testing the device queue mode directly.

Fixes: 8ba816b2 ("null-blk: save memory footprint for struct nullb_cmd")
Signed-off-by: NDamien Le Moal <damien.lemoal@opensource.wdc.com>
Reviewed-by: NJohannes Thumshirn <johannes.thumshirn@wdc.com>
Link: https://lore.kernel.org/r/20220602120344.1365329-1-damien.lemoal@opensource.wdc.comSigned-off-by: NJens Axboe <axboe@kernel.dk>

Global `-Warray-bounds` enablement revealed some problems, one of
which is the way we define and use AQC rules messages.
In fact, they have a shared header, followed by the actual message,
which can be of one of several different formats. So it is
straightforward enough to define that header as a separate struct
and then embed it into message structures as needed, but currently
all the formats reside in one union coupled with the header. Then,
the code allocates only the memory needed for a particular message
format, leaving the union potentially incomplete.
There are no actual reads or writes beyond the end of an allocated
chunk, but at the same time, the whole implementation is fragile and
backed by an equilibrium rather than strong type and memory checks.

Define the structures the other way around: one for the common
header and the rest for the actual formats with the header embedded.
There are no places where several union members would be used at the
same time anyway. This allows to use proper struct_size() and let
the compiler know what is going to be done.
Finally, unsilence `-Warray-bounds` back for ice_switch.c.

Other little things worth mentioning:
* &ice_sw_rule_vsi_list_query is not used anywhere, remove it. It's
  weird anyway to talk to hardware with purely kernel types
  (bitmaps);
* expand the ICE_SW_RULE_*_SIZE() macros to pass a structure
  variable name to struct_size() to let it do strict typechecking;
* rename ice_sw_rule_lkup_rx_tx::hdr to ::hdr_data to keep ::hdr
  for the header structure to have the same name for it constistenly
  everywhere;
* drop the duplicate of %ICE_SW_RULE_RX_TX_NO_HDR_SIZE residing in
  ice_switch.h.

Fixes: 9daf8208 ("ice: Add support for switch filter programming")
Fixes: 66486d89 ("ice: replace single-element array used for C struct hack")
Signed-off-by: NAlexander Lobakin <alexandr.lobakin@intel.com>
Reviewed-by: NMarcin Szycik <marcin.szycik@linux.intel.com>
Acked-by: NTony Nguyen <anthony.l.nguyen@intel.com>
Link: https://lore.kernel.org/r/20220601105924.2841410-1-alexandr.lobakin@intel.comSigned-off-by: NPaolo Abeni <pabeni@redhat.com>

NFDK firmware supports 48-bit dma addressing and
parses 16 high bits of dma addresses.

In nfp_nfdk_tx_desc, dma related structure and tso
related structure are union. When "mss" be filled
with nonzero value due to enable tso, the memory used
by "padding" may be also filled. Then, firmware may
parse wrong dma addresses which causes TX watchdog
timeout problem.

This patch removes padding and unifies the dma_addr_hi
bits with the one in firmware. nfp_nfdk_tx_desc_set_dma_addr
is also added to match this change.

Fixes: c10d12e3 ("nfp: add support for NFDK data path")
Signed-off-by: NFei Qin <fei.qin@corigine.com>
Signed-off-by: NYinjun Zhang <yinjun.zhang@corigine.com>
Signed-off-by: NLouis Peens <louis.peens@corigine.com>
Signed-off-by: NSimon Horman <simon.horman@corigine.com>
Link: https://lore.kernel.org/r/20220601083449.50556-1-simon.horman@corigine.comSigned-off-by: NPaolo Abeni <pabeni@redhat.com>

If the teardown callback failed in the gpio driver, it fails to free the
irq (if there is one). The device is removed anyhow. If later on the irq
triggers, all sorts of unpleasant things might happen (e.g. accessing
the struct adp5588_gpio which is already freed in the meantime or starting
i2c bus transfers for an unregistered device). Even before irq support was
added to this driver, exiting early was wrong; back then it failed to
unregister the gpiochip.

Fortunately these callbacks aren't used any more since at least blackfin
was removed in 2018. So just drop them.

Note that they are not removed from struct adp5588_gpio_platform_data
because the keyboard driver adp5588-keys.c also makes use of them.
(I didn't check if the callbacks might have been called twice, maybe there
is another reason hidden to better not call these functions.)

This patch is a preparation for making i2c remove callbacks return void.

Fixes: 80884094 ("gpio: adp5588-gpio: new driver for ADP5588 GPIO expanders")
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Acked-by: NMichael Hennerich <michael.hennerich@analog.com>
Signed-off-by: NBartosz Golaszewski <brgl@bgdev.pl>

The ql_dm_tgt_ex_pct parameter was introduced in commit ead03855
("qla2xxx: Add Dual mode support in the driver"). Then the use of this
parameter was dropped in commit 99e1b683 ("scsi: qla2xxx: Add
ql2xiniexchg parameter").

Thus, remove ql_dm_tgt_ex_pct since it is no longer used.

Link: https://lore.kernel.org/r/AM9PR10MB41185ADE95B92B4E6926BE639DD49@AM9PR10MB4118.EURPRD10.PROD.OUTLOOK.COMReviewed-by: NHimanshu Madhani <himanshu.madhani@oracle.com>
Signed-off-by: NGleb Chesnokov <Chesnokov.G@raidix.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

cppcheck reports
[drivers/scsi/qla2xxx/qla_mid.c:594]: (warning) Assignment of function parameter has no effect outside the function. Did you forget dereferencing it?
[drivers/scsi/qla2xxx/qla_mid.c:620]: (warning) Assignment of function parameter has no effect outside the function. Did you forget dereferencing it?

The functions qla25xx_free_req_que() and qla25xx_free_rsp_que() are
similar.  They free a 'req' and a 'rsp' parameter respectively. The last
statement of both functions is setting the parameter to NULL. This has no
effect and can be removed.

Link: https://lore.kernel.org/r/20220521201607.4145298-1-trix@redhat.comReviewed-by: NHimanshu Madhani <himanshu.madhani@oracle.com>
Signed-off-by: NTom Rix <trix@redhat.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

Fix the following W=1 kernel warnings:

drivers/scsi/mpi3mr/mpi3mr_app.c:1706: warning: expecting prototype for
adapter_state_show(). Prototype was for adp_state_show() instead.

Link: https://lore.kernel.org/r/20220525093514.55467-1-jiapeng.chong@linux.alibaba.comReported-by: NAbaci Robot <abaci@linux.alibaba.com>
Signed-off-by: NJiapeng Chong <jiapeng.chong@linux.alibaba.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

Update pci_device_id table and generate reporting strings for ATTO Celerity
and ThunderLink Fibre Channel devices.

Link: https://lore.kernel.org/r/20220524125621.47102-1-bgrove@attotech.comReviewed-by: NHannes Reinecke <hare@suse.de>
Reviewed-by: NJames Smart <jsmart2021@gmail.com>
Co-developed-by: NJason Seba <jseba@attotech.com>
Signed-off-by: NJason Seba <jseba@attotech.com>
Signed-off-by: NBradley Grove <bgrove@attotech.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

When the 'ALUA state transitioning' sense code is returned we cannot use
BLK_STS_AGAIN, as this has a very specific use-case.  So return
BLK_STS_TRANSPORT here.

Link: https://lore.kernel.org/r/20220524055631.85480-3-hare@suse.deReviewed-by: NChaitanya Kulkarni <kch@nvidia.com>
Signed-off-by: NHannes Reinecke <hare@suse.de>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>