As a basic check that the SVE signal frame is being set up correctly
verify that the vector length in the signal frame is the vector length
that the process has.
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20210819134245.13935-4-broonie@kernel.org
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
A signal frame with SVE may validly either be a bare struct sve_context or
a struct sve_context followed by vector length dependent register data.
Support either in the generic helpers for the signal tests, and while we're
at it validate the SVE vector length reported.
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20210819134245.13935-3-broonie@kernel.org
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Allow testcases for SVE signal handling to flag the dependency and be
skipped on systems without SVE support.
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20210819134245.13935-2-broonie@kernel.org
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
The helper to send IRQ notification for regulator errors had still
old description mentioning calling BUG() as a last resort when
error status reading has kept failing for more times than a given
threshold.
The impementation calling BUG() did never end-up in-tree but was
replaced by hopefully more sophisticated handler trying to power-off
the system.
Fix the documentation to reflect actual behaviour.
Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
Link: https://lore.kernel.org/r/20210823075651.GA3717293@localhost.localdomain
Signed-off-by: Mark Brown <broonie@kernel.org>
Now we have everything we need, just provide a proper sysdata type for
the bus to use on ARM64 and everything else works.
Link: https://lore.kernel.org/r/20210726180657.142727-9-boqun.feng@gmail.com
Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Since PCI_HYPERV depends on PCI_MSI_IRQ_DOMAIN which selects
GENERIC_MSI_IRQ_DOMAIN, we can use dev_set_msi_domain() to set up the
MSI domain at probing time, and this works for both x86 and ARM64.
Therefore use it as the preparation for ARM64 Hyper-V PCI support.
As a result, no longer need to maintain ->fwnode in x86 specific
pci_sysdata, and make hv_pcibus_device own it instead.
Link: https://lore.kernel.org/r/20210726180657.142727-8-boqun.feng@gmail.com
Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
No functional change, just store and maintain the PCI domain number in
the ->domain_nr of pci_host_bridge. Note that we still need to keep
the copy of domain number in x86-specific pci_sysdata, because x86 is
not a PCI_DOMAINS_GENERIC=y architecture, so the ->domain_nr of
pci_host_bridge doesn't work for it yet.
Link: https://lore.kernel.org/r/20210726180657.142727-7-boqun.feng@gmail.com
Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
In order to support ARM64 Hyper-V PCI, we need to set up the bridge at
probing time because ARM64 is a PCI_DOMAIN_GENERIC=y arch and we don't
have pci_config_window (ARM64 sysdata) for a PCI root bus on Hyper-V, so
it's impossible to retrieve the information (e.g. PCI domains, MSI
domains) from bus sysdata on ARM64 after creation.
Originally in create_root_hv_pci_bus(), pci_create_root_bus() is used to
create the root bus and the corresponding bridge based on x86 sysdata.
Now we create a bridge first and then call pci_scan_root_bus_bridge(),
which allows us to do the necessary set-ups for the bridge.
Link: https://lore.kernel.org/r/20210726180657.142727-6-boqun.feng@gmail.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Currently at root bridge preparation, the corresponding ACPI device will
be set as the companion, however for a Hyper-V virtual PCI root bridge,
there is no corresponding ACPI device, because a Hyper-V virtual PCI
root bridge is discovered via VMBus rather than ACPI table. In order to
support this, we need to make pcibios_root_bridge_prepare() work with
cfg->parent being NULL.
Use a NULL pointer as the ACPI device if there is no corresponding ACPI
device, and this is fine because: 1) ACPI_COMPANION_SET() can work with
the second parameter being NULL, 2) semantically, if a NULL pointer is
set via ACPI_COMPANION_SET(), ACPI_COMPANION() (the read API for this
field) will return NULL, and since ACPI_COMPANION() may return NULL, so
users must have handled the cases where it returns NULL, and 3) since
there is no corresponding ACPI device, it would be wrong to use any
other value here.
Link: https://lore.kernel.org/r/20210726180657.142727-5-boqun.feng@gmail.com
Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Restructure the pcibios_root_bridge_prepare() as the preparation for
supporting cases when no real ACPI device is related to the PCI host
bridge.
No functional change.
Link: https://lore.kernel.org/r/20210726180657.142727-4-boqun.feng@gmail.com
Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Currently, at probing time, the MSI domains of root buses are populated
if either the information of MSI domain is available from firmware (DT
or ACPI), or arch-specific sysdata is used to pass the fwnode of the MSI
domain. These two conditions don't cover all, e.g. Hyper-V virtual PCI
on ARM64, which doesn't have the MSI information in the firmware and
couldn't use arch-specific sysdata because running on an architecture
with PCI_DOMAINS_GENERIC=y.
To support populating MSI domains of the root buses at the probing when
neither of the above condition is true, the ->msi_domain of the
corresponding bridge device is used: in pci_host_bridge_msi_domain(),
which should return the MSI domain of the root bus, the ->msi_domain of
the corresponding bridge is fetched first as a potential value of the
MSI domain of the root bus.
In order to use the approach to populate MSI domains, the driver needs
to dev_set_msi_domain() on the bridge before calling
pci_register_host_bridge(), and makes sure GENERIC_MSI_IRQ_DOMAIN=y.
Another advantage of this new approach is providing an arch-independent
way to populate MSI domains, which allows sharing the driver code as
much as possible between architectures.
Originally-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20210726180657.142727-3-boqun.feng@gmail.com
Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Currently we retrieve the PCI domain number of the host bridge from the
bus sysdata (or pci_config_window if PCI_DOMAINS_GENERIC=y). Actually
we have the information at PCI host bridge probing time, and it makes
sense that we store it into pci_host_bridge. One benefit of doing so is
the requirement for supporting PCI on Hyper-V for ARM64, because the
host bridge of Hyper-V doesn't have pci_config_window, whereas ARM64 is
a PCI_DOMAINS_GENERIC=y arch, so we cannot retrieve the PCI domain
number from pci_config_window on ARM64 Hyper-V guest.
As the preparation for ARM64 Hyper-V PCI support, we introduce the
domain_nr in pci_host_bridge and a sentinel value to allow drivers to
set domain numbers properly at probing time. Currently
CONFIG_PCI_DOMAINS_GENERIC=y archs are only users of this
newly-introduced field.
Link: https://lore.kernel.org/r/20210726180657.142727-2-boqun.feng@gmail.com
Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
This fixes a compile error with W=1.
arch/powerpc/kernel/prom.c: In function ‘early_reserve_mem’:
arch/powerpc/kernel/prom.c:625:10: error: variable ‘reserve_map’ set but not used [-Werror=unused-but-set-variable]
__be64 *reserve_map;
^~~~~~~~~~~
cc1: all warnings being treated as errors
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20210823090039.166120-2-clg@kaod.org
__NR__exit is nowhere used. On most architectures it was removed by
commit 135ab6ec8f ("[PATCH] remove remaining errno and
__KERNEL_SYSCALLS__ references") but not on powerpc.
powerpc removed __KERNEL_SYSCALLS__ in commit 3db03b4afb ("[PATCH]
rename the provided execve functions to kernel_execve"), but __NR__exit
was left over.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/6457eb4f327313323ed1f70e540bbb4ddc9178fa.1629701106.git.christophe.leroy@csgroup.eu
The previous patch allowed user to specify the aliasing of SSID via
model option for applying a quirk. Update the documentation
accordingly.
Link: https://lore.kernel.org/r/20210823073722.14873-4-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
There are tons of quirks for HD-audio and many of them are without
model string, hence it's not trivial to apply the same quirk for a new
device. This patch makes it easier: namely, the model string accepts
a form as "XXXX:YYYY" (a pair of hex numbers of the subsystem-vendor
and subsystem-device IDs), to specify the alias of PCI (or codec)
SSID. e.g. passing model=1234:abcd would apply the quirk that matches
with the given SSID 1234:abcd instead of the actual SSID.
Link: https://lore.kernel.org/r/20210823073722.14873-3-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This contains a slight code refactoring of snd_hda_pick_fixup():
- Unify the ID setup
- Unify the debug print message
- Use snd_pci_quirk_lookup_id() for the codec SSID matching
Mostly for simplifying the code flow but also it makes easier to add
the codec alias handling in the upcoming patch.
Link: https://lore.kernel.org/r/20210823073722.14873-2-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Mark of the Unicorn (MOTU) shipped 896HD 2003 as one of models in second
generation of its FireWire series, and already discontinued it. The model
consists of below ICs:
* Texas Instruments TSB41AB2
* Phillips Semiconductors PDI1394L40
* Altera cyclone EP1C3
* Texas Instruments TMS320VC5402
It supports sampling transmission frequency up to 192.0 kHz. The packet
format differs depending on both of sampling transfer frequency and enabling
ADAT channels. The model doesn't support MIDI message transmission.
This commit adds support for it.
$ python3 crpp < /sys/bus/firewire/devices/fw1/config_rom
ROM header and bus information block
-----------------------------------------------------------------
400 04101b66 bus_info_length 4, crc_length 16, crc 7014
404 31333934 bus_name "1394"
408 20001000 irmc 0, cmc 0, isc 1, bmc 0, cyc_clk_acc 0, max_rec 1 (4)
40c 0001f200 company_id 0001f2 |
410 0001dbce device_id 000001dbce | EUI-64 0001f2000001dbce
root directory
-----------------------------------------------------------------
414 0004c65c directory_length 4, crc 50780
418 030001f2 vendor
41c 0c0083c0 node capabilities per IEEE 1394
420 8d000006 --> eui-64 leaf at 438
424 d1000001 --> unit directory at 428
unit directory at 428
-----------------------------------------------------------------
428 0003dcc1 directory_length 3, crc 56513
42c 120001f2 specifier id
430 13000005 version
434 17102800 model
eui-64 leaf at 438
-----------------------------------------------------------------
438 000264f2 leaf_length 2, crc 25842
43c 0001f200 company_id 0001f2 |
440 0001dbce device_id 000001dbce | EUI-64 0001f2000001dbce
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210823085741.33864-1-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
A successful 'init_rs_non_canonical()' call should be balanced by a
corresponding 'free_rs()' call in the error handling path of the probe, as
already done in the remove function.
Update the error handling path accordingly.
Fixes: 8c61b7a7f4 ("[MTD] [NAND] Use rslib for CAFÉ ECC")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/fd313d3fb787458bcc73189e349f481133a2cdc9.1629532640.git.christophe.jaillet@wanadoo.fr
* irq/qcom-pdc-nowake-cleanup:
: Fix the QCOM PDC mishandling of the interrupt hierarchy by trimming
: it when necessary.
: Export irq_domain_disconnect_hierarchy as a consequence of it.
irqchip/qcom-pdc: Trim unused levels of the interrupt hierarchy
irqdomain: Export irq_domain_disconnect_hierarchy()
Signed-off-by: Marc Zyngier <maz@kernel.org>
The QCOM PDC driver creates a bunch of unnecessary levels in
the interrupt hierarchy when dealing with non-wakeup-capable
interrupts. By definition, these lines are terminated at the
PDC level, and everything below this is completely fake.
This also results in additional complexity as most of the
callbacks have to check for the validity of the parent level.
Needless to say, this doesn't look very good.
Solve this by disconnecting the interrupt hierarchy below
the last valid level, and considerably simplify the handling
of all the other interrupts by avoiding now unnecessary cheks.
In most cases, the standard irq_*_parent() handlers are directly
used.
This also cures an issue reporting by Maulik where gpio_to_irq()
returns an error after having observed a set of invalid levels.
Signed-off-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Maulik Shah <mkshah@codeaurora.org>
Tested-by: Maulik Shah <mkshah@codeaurora.org>
Link: https://lore.kernel.org/r/1629705880-27877-3-git-send-email-mkshah@codeaurora.org
Always grab a reference to the mtd_blktrans_dev in ->open instead of
just on the first open, and do away with the additional temporary
references in ->open and ->release.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20210823073359.705281-9-hch@lst.de
No need to grab a mtd_blktrans_dev given that ->open already holds one
and ->getgeo can only be called on an open disk.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20210823073359.705281-8-hch@lst.de
blktrans_ref_mutex is not actually needed. The kref is serialized
internally, and devnum assignment in add_mtd_blktrans_dev happens before
the disk is added and thus any of the block_device_operations methods
otherwise using it are called. It is also already serialized by the
global mtd_table_mutex.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20210823073359.705281-7-hch@lst.de
->private_data is set before the disk is added and never cleared, so don't
bother trying to handle a NULL pointer there.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20210823073359.705281-6-hch@lst.de
There is nothing that this protects against except for slightly reducing
the window when new opens can appear just before calling del_gendisk.
Reported-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Tested-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20210823073359.705281-2-hch@lst.de
<linux/spi/max7301.h> despite the placement of the header, is
used by drivers/gpio/gpio-max730*.
The include needs struct gpio_chip and needs to include
<linux/gpio/driver.h> not the legacy <linux/gpio.h> include.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
This patch adds a new driver for Virtio based GPIO devices.
This allows a guest VM running Linux to access GPIO lines provided by
the host. It supports all basic operations, except interrupts for the
GPIO lines.
Based on the initial work posted by:
"Enrico Weigelt, metux IT consult" <lkml@metux.net>.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Fix kernel-doc warnings reported by the kernel test robot:
drivers/platform/mellanox/mlxbf-pmc.c:82: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst
* Structure to hold attribute and block info for each sysfs entry
drivers/platform/mellanox/mlxbf-pmc.c:94: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst
* Structure to hold info for each HW block
drivers/platform/mellanox/mlxbf-pmc.c:121: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst
* Structure to hold PMC context info
drivers/platform/mellanox/mlxbf-pmc.c:148: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst
* Structure to hold supported events for each block
Also fix typos in a few struct member names.
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Reported-by: kernel test robot <lkp@intel.com>
Cc: Aditya Srivastava <yashsri421@gmail.com>
Cc: Hans de Goede <hdegoede@redhat.com>
Cc: Mark Gross <mgross@linux.intel.com>
Cc: Vadim Pasternak <vadimp@nvidia.com>
Cc: platform-driver-x86@vger.kernel.org
Link: https://lore.kernel.org/r/20210822171742.26921-1-rdunlap@infradead.org
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Convert the OPP v1 and v2 bindings to DT schema format. As the OPPv2 binding
can be extended by vendors, we need to split the common part out from the
"operating-points-v2" conforming compatible.
Cc: Yangtao Li <tiny.windzz@gmail.com>
Cc: Nishanth Menon <nm@ti.com>
Cc: Stephen Boyd <sboyd@kernel.org>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Chen-Yu Tsai <wens@csie.org>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rob Herring <robh@kernel.org>
Acked-by: Maxime Ripard <maxime@cerno.tech>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Commit 4fa82a87ba ("opp: Allow required-opps to be used for non genpd
use cases") dereferences the pointers in required_opp_tables but these
might be set to an ERR_PTR if the list still has lazy links pending,
resulting in segfaults. Prior to this patch IS_ERR was also checked on
required_opp_tables[i] before reading ->is_genpd inside
_opp_table_alloc_required_tables, which is at the same time the
predicate to add this table to the lazy list. This segfault is solved
by reordering the checks to bail on lazy pending tables before reading
->is_genpd.
Fixes: 4fa82a87ba ("opp: Allow required-opps to be used for non genpd use cases")
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org>
Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
In preparation to convert OPP bindings to DT schema, clean-up a few OPP
binding node names in the binding examples.
Cc: Georgi Djakov <djakov@kernel.org>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Leonard Crestez <leonard.crestez@nxp.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rob Herring <robh@kernel.org>
Acked-by: Georgi Djakov <djakov@kernel.org>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
opp.txt is getting removed with the OPP binding converted to DT schema.
As it is unusual to reference a binding doc from a dts file, let's just
remove the reference.
Cc: "Benoît Cousson" <bcousson@baylibre.com>
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
ASUS ROG Strix G17 has the very same PCI and codec SSID (1043:103f) as
ASUS TX300, and unfortunately, the existing quirk for TX300 is broken
on ASUS ROG. Actually the device works without the quirk, so we'll
need to clear the quirk before applying for this device.
Since ASUS ROG has a different codec (ALC294 - while TX300 has
ALC282), this patch adds a workaround for the device, just clearing
the codec->fixup_id by checking the codec vendor_id.
It's a bit ugly to add such a workaround there, but it seems to be the
simplest way.
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=214101
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20210820143214.3654-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Add the tables and constants for init sequences for UFS QMP phy found in
SM4250/6115 SoC. The phy is a variation of the v2 phy, but is mistakenly
labeled as v3-660 in downstream sources.
QSERDES COM, RX, TX registers match fully existing v2 registers, with
a few additions. PCS registers don't have much in common, but there are
no clashes with existing ones so new registers were added to existing v2
PCS pack.
Signed-off-by: Iskren Chernev <iskren.chernev@gmail.com>
Link: https://lore.kernel.org/r/20210821155657.893165-3-iskren.chernev@gmail.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
