| Age | Commit message (Collapse) | Author |
|---|
|
It is not reliable to check for CON_ENABLED in order to identify if a
console is registered. Use console_is_registered() instead.
Signed-off-by: John Ogness <john.ogness@linutronix.de>
Reviewed-by: Petr Mladek <pmladek@suse.com>
Signed-off-by: Petr Mladek <pmladek@suse.com>
Link: https://lore.kernel.org/r/20221116162152.193147-27-john.ogness@linutronix.de
|
|
It is not reliable to check for CON_ENABLED in order to identify if a
console is registered. Use console_is_registered() instead.
Signed-off-by: John Ogness <john.ogness@linutronix.de>
Reviewed-by: Petr Mladek <pmladek@suse.com>
Signed-off-by: Petr Mladek <pmladek@suse.com>
Link: https://lore.kernel.org/r/20221116162152.193147-26-john.ogness@linutronix.de
|
|
The CON_ENABLED status of a console is a runtime setting that does not
involve the console driver. Drivers must not assume that if the console
is disabled then proper hardware management is not needed. For the EFI
earlycon case, it is about remapping/unmapping memory for the
framebuffer.
Use console_is_registered() instead of checking CON_ENABLED.
Signed-off-by: John Ogness <john.ogness@linutronix.de>
Reviewed-by: Petr Mladek <pmladek@suse.com>
Signed-off-by: Petr Mladek <pmladek@suse.com>
Link: https://lore.kernel.org/r/20221116162152.193147-25-john.ogness@linutronix.de
|
|
All users of uart_console_enabled() really want to know if a console
is registered. It is not reliable to check for CON_ENABLED in order
to identify if a console is registered. Use console_is_registered()
instead.
A _locked() variant is provided because uart_set_options() is always
called with the console_list_lock held and must check if a console
is registered in order to synchronize with kgdboc.
Signed-off-by: John Ogness <john.ogness@linutronix.de>
Reviewed-by: Petr Mladek <pmladek@suse.com>
Signed-off-by: Petr Mladek <pmladek@suse.com>
Link: https://lore.kernel.org/r/20221116162152.193147-23-john.ogness@linutronix.de
|
|
show_cons_active() uses the console_lock to gather information
on registered consoles. Since the console_lock is being used for
multiple reasons, explicitly document these reasons. This will
be useful when the console_lock is split into fine-grained
locking.
Signed-off-by: John Ogness <john.ogness@linutronix.de>
Reviewed-by: Petr Mladek <pmladek@suse.com>
Signed-off-by: Petr Mladek <pmladek@suse.com>
Link: https://lore.kernel.org/r/20221116162152.193147-10-john.ogness@linutronix.de
|
|
kgdboc_earlycon_init() uses the console_lock to ensure that no consoles
are unregistered until the kgdboc_earlycon is setup. This is necessary
because the trapping of the exit() callback assumes that the exit()
callback is not called before the trap is setup.
Explicitly document this non-typical console_lock usage.
Signed-off-by: John Ogness <john.ogness@linutronix.de>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>
Reviewed-by: Petr Mladek <pmladek@suse.com>
Signed-off-by: Petr Mladek <pmladek@suse.com>
Link: https://lore.kernel.org/r/20221116162152.193147-9-john.ogness@linutronix.de
|
|
Unprotected list walks are not necessarily safe.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: John Ogness <john.ogness@linutronix.de>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Sergey Senozhatsky <senozhatsky@chromium.org>
Reviewed-by: Petr Mladek <pmladek@suse.com>
Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>
Signed-off-by: Petr Mladek <pmladek@suse.com>
Link: https://lore.kernel.org/r/20221116162152.193147-2-john.ogness@linutronix.de
|
|
__hw_perf_event_init() already calls armpmu->map_event() callback, and also
returns its error code including -ENOENT, along with a debug callout. Hence
an additional armpmu->map_event() check for -ENOENT is redundant.
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Acked-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
Link: https://lore.kernel.org/r/20221202015611.338499-1-anshuman.khandual@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue
Tony Nguyen says:
====================
Intel Wired LAN Driver Updates 2022-11-30 (e1000e, igb)
This series contains updates to e1000e and igb drivers.
Akihiko Odaki fixes calculation for checking whether space for next
frame exists for e1000e and properly sets MSI-X vector to fix failing
ethtool interrupt test for igb.
* '1GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue:
igb: Allocate MSI-X vector when testing
e1000e: Fix TX dispatch condition
====================
Link: https://lore.kernel.org/r/20221130194228.3257787-1-anthony.l.nguyen@intel.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
The 'struct cxl_nvdimm_bridge' object advertises platform CXL PMEM
resources. It coordinates with libnvdimm to attach nvdimm devices and
regions for each corresponding CXL object. That coordination is
complicated, i.e. difficult to reason about, and it turns out redundant.
It is already the case that the CXL core knows how to tear down a
cxl_region when a cxl_memdev goes through ->remove(), so that pathway
can be extended to directly cleanup cxl_nvdimm and cxl_pmem_region
objects.
Towards the goal of ripping out the cxl_nvdimm_bridge state machine,
arrange for cxl_acpi to optionally pre-load the cxl_pmem driver so that
the nvdimm bridge is active synchronously with
devm_cxl_add_nvdimm_bridge(), and remove all the bind attributes for the
cxl_nvdimm* objects since the cxl root device and cxl_memdev bind
attributes are sufficient.
Tested-by: Robert Richter <rrichter@amd.com>
Link: https://lore.kernel.org/r/166993040668.1882361.7450361097265836752.stgit@dwillia2-xfh.jf.intel.com
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
|
|
Add Global Clock controller (GCC) driver for SM8550 SoC,
which includes the gcc resets and gdsc.
This patch is based on an initial downstream driver.
Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221130112852.2977816-6-abel.vesa@linaro.org
|
|
Add a LUCID_OLE PLL type for SM8550 SoC from Qualcomm.
Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221130112852.2977816-5-abel.vesa@linaro.org
|
|
The SM8550 GCC GDSCs need a higher timeout value when polling for status,
so increase it to 1500us, while leaving the delay between disable-enable
sequence for votable gdscs to stay the same.
Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221130112852.2977816-4-abel.vesa@linaro.org
|
|
Similar to msm8916, msm8939 has (at least) 6 "General Purpose" clocks that
can be muxed to SoC pins. These clocks are:
GP_CLK{0, 1} : GPIO_{31, 32} (Belongs to CAMSS according to Linux)
GP_CLK_{1-3}{A, B} : GPIO_{49-51, 97, 12, 13} (Belongs to GCC itself)
GP_MN : GPIO_110 (Doesn't seem to be described in gcc,
ignored in this patch)
Those clocks may be used as e.g. PWM sources for external peripherals.
Add more frequencies to the table for those clocks so it's possible
for arbitrary peripherals to make use of them.
Reference: https://lore.kernel.org/r/20220612145955.385787-5-nikita@trvn.ru
Signed-off-by: Lin, Meng-Bo <linmengbo0689@protonmail.com>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221117171343.24216-1-linmengbo0689@protonmail.com
|
|
Convert platform_get_resource(), devm_ioremap_resource() to a single
call to devm_platform_get_and_ioremap_resource(), as this is exactly
what this function does.
Signed-off-by: Minghao Chi <chi.minghao@zte.com.cn>
Signed-off-by: ye xingchen <ye.xingchen@zte.com.cn>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/202211171403340042731@zte.com.cn
|
|
It appears that having only .name populated in parent_data for clocks
which are only globally searchable currently will not work as the clk core
won't copy that name if there is no .fw_name present as well.
So, populate .fw_name for all parent clocks in parent_data.
Fixes: ae55ad32e273 ("clk: qcom: ipq8074: convert to parent data")
Co-developed-by: Christian Marangi <ansuelsmth@gmail.com>
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Signed-off-by: Robert Marko <robimarko@gmail.com>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221116214655.1116467-1-robimarko@gmail.com
|
|
Modernize the krait-cc driver to parent-data API and refactor to drop
any use of parent_names. From Documentation all the required clocks should
be declared in DTS so fw_name can be correctly used to get the parents
for all the muxes. .name is also declared to save compatibility with old
DT.
While at it also drop some hardcoded index and introduce an enum to make
index values more clear.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221109005631.3189-5-ansuelsmth@gmail.com
|
|
clk_register is now deprecated. Convert the driver to devm_clk_hw_register.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221109005631.3189-4-ansuelsmth@gmail.com
|
|
Some bootloader may leave the system in an even more undefined state
with the secondary mux of L2 or other cores sourcing out of the acpu_aux
parent. This results in the clk set to the PXO rate or a PLL8 rate.
The current logic to reset the mux and set them to a defined state only
handle if the mux are configured to source out of QSB. Change this and
force a new and defined state if the current clk is lower than the aux
rate. This way we can handle any wrong configuration where the mux is
sourcing out of QSB (rate 225MHz, currently set to a virtual rate of 1),
PXO rate (rate 25MHz) or PLL8 (needs to be configured to run at 384Mhz).
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221109005631.3189-3-ansuelsmth@gmail.com
|
|
clk-krait ignore any rate change if clk is not flagged as enabled.
Correctly enable the secondary mux and div clk to correctly change rate
instead of silently ignoring the request.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221109005631.3189-2-ansuelsmth@gmail.com
|
|
The secondary mux parent order is swapped.
This currently doesn't cause problems as the secondary mux is used for idle
clk and as a safe clk source while reprogramming the hfpll.
Each mux have 2 or more output but he always have a safe source to
switch while reprogramming the connected pll. We use a clk notifier to
switch to the correct parent before clk core can apply the correct rate.
The parent to switch is hardcoded in the mux struct.
For the secondary mux the safe source to use is the qsb parent as it's
the only fixed clk as the acpus_aux is a pll that can source from pxo or
from pll8.
The hardcoded safe parent for the secondary mux is set to index 0 that
in the secondary mux map is set to 2.
But the index 0 is actually acpu_aux in the parent list.
Fix the swapped parents to correctly handle idle frequency and output a
sane clk_summary report.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221109005631.3189-1-ansuelsmth@gmail.com
|
|
Use devm variant for clk notifier register and correctly handle free
resource on driver remove.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221108215827.30475-1-ansuelsmth@gmail.com
|
|
Currently div2 value is applied to the wrong bits. This is caused by a
bug in the code where the shift is done only for lpl, for anything
else the mask is not shifted to the correct bits.
Fix this by correctly shift if lpl is not supported.
Fixes: 4d7dc77babfe ("clk: qcom: Add support for Krait clocks")
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221108215625.30186-1-ansuelsmth@gmail.com
|
|
krait-cc use this driver for the secondary mux. Register it as a clk
provider to correctly use this clk in other drivers.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221108211734.3707-1-ansuelsmth@gmail.com
|
|
Downstream QCA 5.4 kernel defines networking resets which are not present
in the mainline kernel but are required for the networking drivers.
So, port the downstream resets and avoid using magic values for mask,
construct mask for resets which require multiple bits to be set/cleared.
Signed-off-by: Robert Marko <robimarko@gmail.com>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221107132901.489240-3-robimarko@gmail.com
|
|
This patch adds the support for giving the complete bitmask
in reset structure and reset operation will use this bitmask
for all reset operations.
Currently, reset structure only takes a single bit for each reset
and then calculates the bitmask by using the BIT() macro.
However, this is not sufficient anymore for newer SoC-s like IPQ8074,
IPQ6018 and more, since their networking resets require multiple bits
to be asserted in order to properly reset the HW block completely.
So, in order to allow asserting multiple bits add "bitmask" field to
qcom_reset_map, and then use that bitmask value if its populated in the
driver, if its not populated, then we just default to existing behaviour
and calculate the bitmask on the fly.
Signed-off-by: Robert Marko <robimarko@gmail.com>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221107132901.489240-1-robimarko@gmail.com
|
|
The two devices managed by lpasscorecc-sc7180.c each had their own
"struct dev_pm_ops". This is not needed. They are exactly the same and
the structure is "static const" so it can't possible change. combine
the two. This matches what's done for sc7280.
This should be a noop other than saving a few bytes.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221104064055.3.I90ba14a47683a484f26531a08f7b46ace7f0a8a9@changeid
|
|
The sc7180 lpass clock controller's pm_runtime usage wasn't broken
quite as spectacularly as the sc7280's pm_runtime usage, but it was
still broken. Putting some printouts in at boot showed me this (with
serial console enabled, which makes the prints slow and thus changes
timing):
[ 3.109951] DOUG: my_pm_clk_resume, usage=1
[ 3.114767] DOUG: my_pm_clk_resume, usage=1
[ 3.664443] DOUG: my_pm_clk_suspend, usage=0
[ 3.897566] DOUG: my_pm_clk_suspend, usage=0
[ 3.910137] DOUG: my_pm_clk_resume, usage=1
[ 3.923217] DOUG: my_pm_clk_resume, usage=0
[ 4.440116] DOUG: my_pm_clk_suspend, usage=-1
[ 4.444982] DOUG: my_pm_clk_suspend, usage=0
[ 14.170501] DOUG: my_pm_clk_resume, usage=1
[ 14.176245] DOUG: my_pm_clk_resume, usage=0
...or this w/out serial console:
[ 0.556139] DOUG: my_pm_clk_resume, usage=1
[ 0.556279] DOUG: my_pm_clk_resume, usage=1
[ 1.058422] DOUG: my_pm_clk_suspend, usage=-1
[ 1.058464] DOUG: my_pm_clk_suspend, usage=0
[ 1.186250] DOUG: my_pm_clk_resume, usage=1
[ 1.186292] DOUG: my_pm_clk_resume, usage=0
[ 1.731536] DOUG: my_pm_clk_suspend, usage=-1
[ 1.731557] DOUG: my_pm_clk_suspend, usage=0
[ 10.288910] DOUG: my_pm_clk_resume, usage=1
[ 10.289496] DOUG: my_pm_clk_resume, usage=0
It seems to be doing roughly the right sequence of calls, but just
like with sc7280 this is more by luck than anything. Having a usage of
-1 is just not OK.
Let's fix this like we did with sc7280.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Fixes: ce8c195e652f ("clk: qcom: lpasscc: Introduce pm autosuspend for SC7180")
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221104064055.2.I49b25b9bda9430fc7ea21e5a708ca5a0aced2798@changeid
|
|
The pm_runtime usage in lpass-sc7280 was broken in quite a few
ways. Specifically:
1. At the end of probe it called "put" twice. This is a no-no and will
end us up with a negative usage count. Even worse than calling
"put" twice, it never called "get" once. Thus after bootup it could
be seen that the runtime usage of the devices managed by this
driver was -2.
2. In some error cases it manually called pm_runtime_disable() even
though it had previously used devm_add_action_or_reset() to set
this up to be called automatically. This meant that in these error
cases we'd double-call pm_runtime_disable().
3. It forgot to call undo pm_runtime_use_autosuspend(), which can
sometimes have subtle problems (and the docs specifically mention
that you need to undo this function).
Overall the above seriously calls into question how this driver is
working. It seems like a combination of "it doesn't", "by luck", and
"because of the weirdness of runtime_pm". Specifically I put a
printout to the serial console every time the runtime suspend/resume
was called for the two devices created by this driver (I wrapped the
pm_clk calls). When I had serial console enabled, I found that the
calls got resumed at bootup (when the clk core probed and before our
double-put) and then never touched again. That's no good.
[ 0.829997] DOUG: my_pm_clk_resume, usage=1
[ 0.835487] DOUG: my_pm_clk_resume, usage=1
When I disabled serial console (speeding up boot), I got a different
pattern, which I guess (?) is better:
[ 0.089767] DOUG: my_pm_clk_resume, usage=1
[ 0.090507] DOUG: my_pm_clk_resume, usage=1
[ 0.151885] DOUG: my_pm_clk_suspend, usage=-2
[ 0.151914] DOUG: my_pm_clk_suspend, usage=-2
[ 1.825747] DOUG: my_pm_clk_resume, usage=-1
[ 1.825774] DOUG: my_pm_clk_resume, usage=-1
[ 1.888269] DOUG: my_pm_clk_suspend, usage=-2
[ 1.888282] DOUG: my_pm_clk_suspend, usage=-2
These different patterns have to do with the fact that the core PM
Runtime code really isn't designed to be robust to negative usage
counts and sometimes may happen to stumble upon a behavior that
happens to "work". For instance, you can see that
__pm_runtime_suspend() will treat any non-zero value (including
negative numbers) as if the device is in use.
In any case, let's fix the driver to be correct. We'll hold a
pm_runtime reference for the whole probe and then drop it (once!) at
the end. We'll get rid of manual pm_runtime_disable() calls in the
error handling. We'll also switch to devm_pm_runtime_enable(), which
magically handles undoing pm_runtime_use_autosuspend() as of commit
b4060db9251f ("PM: runtime: Have devm_pm_runtime_enable() handle
pm_runtime_dont_use_autosuspend()").
While we're at this, let's also use devm_pm_clk_create() instead of
rolling it ourselves.
Note that the above changes make it obvious that
lpassaudio_create_pm_clks() was doing more than just creating
clocks. It was also setting up pm_runtime parameters. Let's rename it.
All of these problems were found by code inspection. I started looking
at this driver because it was involved in a deadlock that I reported a
while ago [1]. Though I bisected the deadlock to commit 1b771839de05
("clk: qcom: gdsc: enable optional power domain support"), it was
never really clear why that patch affected it other than a luck of
timing changes. I'll also note that by fixing the timing (as done in
this change) we also seem to aboid the deadlock, which is a nice
benefit.
Also note that some of the fixes here are much the same type of stuff
that Dmitry did in commit 72cfc73f4663 ("clk: qcom: use
devm_pm_runtime_enable and devm_pm_clk_create"), but I guess
lpassaudiocc-sc7280.c didn't exist then.
[1] https://lore.kernel.org/r/20220922154354.2486595-1-dianders@chromium.org
Fixes: a9dd26639d05 ("clk: qcom: lpass: Add support for LPASS clock controller for SC7280")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221104064055.1.I00a0e4564a25489e85328ec41636497775627564@changeid
|
|
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes
amd-drm-fixes-6.1-2022-12-01:
amdgpu:
- VCN fix for vangogh
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Alex Deucher <alexander.deucher@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221201202015.5931-1-alexander.deucher@amd.com
|
|
Recent changes to the DMA code has resulting in the IMX driver failing
I2C transfers when the buffer has been vmalloc. Only perform DMA
transfers if the message has the I2C_M_DMA_SAFE flag set, indicating
the client is providing a buffer which is DMA safe.
This is a minimal fix for stable. The I2C core provides helpers to
allocate a bounce buffer. For a fuller fix the master should make use
of these helpers.
Fixes: 4544b9f25e70 ("dma-mapping: Add vmap checks to dma_map_single()")
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Acked-by: Oleksij Rempel <o.rempel@pengutronix.de>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
|
|
Fix to return a negative error code from the gi2c->err instead of
0.
Fixes: d8703554f4de ("i2c: qcom-geni: Add support for GPI DMA")
Signed-off-by: Wang Yufen <wangyufen@huawei.com>
Reviewed-by: Tommaso Merciai <tommaso.merciai@amarulasoluitons.com>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
|
|
Commit "i2c: cadence: Add standard bus recovery support" breaks for i2c
devices that have no pinctrl defined. There is no requirement for this
to exist in the DT. This has worked perfectly well without this before in
at least 1 real usage case on hardware (Mali Komeda DPU, Cadence i2c to
talk to a tda99xx phy). Adding the requirement to have pinctrl set up in
the device tree (or otherwise be found) is a regression where the whole
i2c device is lost entirely (in this case dropping entire devices which
then leads to the drm display stack unable to find the phy for display
output, thus having no drm display device and so on down the chain).
This converts the above commit to an enhancement if pinctrl can be found
for the i2c device, providing a timeout on read with recovery, but if not,
do what used to be done rather than a fatal loss of a device.
This restores the mentioned display devices to their working state again.
Fixes: 58b924241d0a ("i2c: cadence: Add standard bus recovery support")
Signed-off-by: Carsten Haitzler <carsten.haitzler@arm.com>
Reviewed-by: Shubhrajyoti Datta <shubhrajyoti.datta@amd.com>
Reviewed-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
Acked-by: Michal Simek <michal.simek@amd.com>
[wsa: added braces to else-branch]
Signed-off-by: Wolfram Sang <wsa@kernel.org>
|
|
In zoned mode, zones with write pointers can have conditions "read-only"
or "offline". In read-only condition, zones can not be written. In
offline condition, the zones can be neither written nor read. These
conditions are intended for zones with media failures, then it is
difficult to set those conditions to zones on real devices.
To test handling of zones in the conditions, add a feature to null_blk
to set up zones in read-only or offline condition. Add new configuration
attributes "zone_readonly" and "zone_offline". Write a sector to the
attribute files to specify the target zone to set the zone conditions.
For example, following command lines do it:
echo 0 > nullb1/zone_readonly
echo 524288 > nullb1/zone_offline
When the specified zones are already in read-only or offline condition,
normal empty condition is restored to the zones. These condition changes
can be done only after the null_blk device get powered, since status
area of each zone is not yet allocated before power-on.
Also improve zone condition checks to inhibit all commands for zones in
offline conditions. In same manner, inhibit write and zone management
commands for zones in read-only condition.
Signed-off-by: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
Reviewed-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
Link: https://lore.kernel.org/r/20221201061036.2342206-1-shinichiro.kawasaki@wdc.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
|
|
nfit_test overrode the security_show() sysfs attribute function in nvdimm
dimm_devs in order to allow testing of security unlock. With the
introduction of CXL security commands, the trick to override
security_show() becomes significantly more complicated. By introdcing a
security flag CONFIG_NVDIMM_SECURITY_TEST, libnvdimm can just toggle the
check via a compile option. In addition the original override can can be
removed from tools/testing/nvdimm/.
The flag will also be used to bypass cpu_cache_invalidate_memregion() when
set in a different commit. This allows testing on QEMU with nfit_test or
cxl_test since cpu_cache_has_invalidate_memregion() checks whether
X86_FEATURE_HYPERVISOR cpu feature flag is set on x86.
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
Link: https://lore.kernel.org/r/166983618758.2734609.18031639517065867138.stgit@djiang5-desk3.ch.intel.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
|
|
Add provider name in order to associate cxl test dimm from cxl_test to the
cxl pmem device when going through sysfs for security testing.
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
Link: https://lore.kernel.org/r/166983618174.2734609.15600031015423828810.stgit@djiang5-desk3.ch.intel.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
|
|
Add an id group attribute for CXL based nvdimm object. The addition allows
ndctl to display the "unique id" for the nvdimm. The serial number for the
CXL memory device will be used for this id.
[
{
"dev":"nmem10",
"id":"0x4",
"security":"disabled"
},
]
The id attribute is needed by the ndctl security key management to setup a
keyblob with a unique file name tied to the mem device.
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
Link: https://lore.kernel.org/r/166983617029.2734609.8251308562882142281.stgit@djiang5-desk3.ch.intel.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
|
|
The original nvdimm_security_ops ->disable() only supports user passphrase
for security disable. The CXL spec introduced the disabling of master
passphrase. Add a ->disable_master() callback to support this new operation
and leaving the old ->disable() mechanism alone. A "disable_master" command
is added for the sysfs attribute in order to allow command to be issued
from userspace. ndctl will need enabling in order to utilize this new
operation.
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
Link: https://lore.kernel.org/r/166983616454.2734609.14204031148234398086.stgit@djiang5-desk3.ch.intel.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
|
|
Create callback function to support the nvdimm_security_ops() ->erase()
callback. Translate the operation to send "Passphrase Secure Erase"
security command for CXL memory device.
When the mem device is secure erased, cpu_cache_invalidate_memregion() is
called in order to invalidate all CPU caches before attempting to access
the mem device again.
See CXL 3.0 spec section 8.2.9.8.6.6 for reference.
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
Link: https://lore.kernel.org/r/166983615293.2734609.10358657600295932156.stgit@djiang5-desk3.ch.intel.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
|
|
Create callback function to support the nvdimm_security_ops() ->unlock()
callback. Translate the operation to send "Unlock" security command for CXL
mem device.
When the mem device is unlocked, cpu_cache_invalidate_memregion() is called
in order to invalidate all CPU caches before attempting to access the mem
device.
See CXL rev3.0 spec section 8.2.9.8.6.4 for reference.
Reviewed-by: Davidlohr Bueso <dave@stgolabs.net>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
Link: https://lore.kernel.org/r/166983614167.2734609.15124543712487741176.stgit@djiang5-desk3.ch.intel.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
|
|
Create callback function to support the nvdimm_security_ops() ->freeze()
callback. Translate the operation to send "Freeze Security State" security
command for CXL memory device.
See CXL rev3.0 spec section 8.2.9.8.6.5 for reference.
Reviewed-by: Davidlohr Bueso <dave@stgolabs.net>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
Link: https://lore.kernel.org/r/166983613019.2734609.10645754779802492122.stgit@djiang5-desk3.ch.intel.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
|
|
Create callback function to support the nvdimm_security_ops ->disable()
callback. Translate the operation to send "Disable Passphrase" security
command for CXL memory device. The operation supports disabling a
passphrase for the CXL persistent memory device. In the original
implementation of nvdimm_security_ops, this operation only supports
disabling of the user passphrase. This is due to the NFIT version of
disable passphrase only supported disabling of user passphrase. The CXL
spec allows disabling of the master passphrase as well which
nvidmm_security_ops does not support yet. In this commit, the callback
function will only support user passphrase.
See CXL rev3.0 spec section 8.2.9.8.6.3 for reference.
Reviewed-by: Davidlohr Bueso <dave@stgolabs.net>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
Link: https://lore.kernel.org/r/166983611878.2734609.10602135274526390127.stgit@djiang5-desk3.ch.intel.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
|
|
Create callback function to support the nvdimm_security_ops ->change_key()
callback. Translate the operation to send "Set Passphrase" security command
for CXL memory device. The operation supports setting a passphrase for the
CXL persistent memory device. It also supports the changing of the
currently set passphrase. The operation allows manipulation of a user
passphrase or a master passphrase.
See CXL rev3.0 spec section 8.2.9.8.6.2 for reference.
However, the spec leaves a gap WRT master passphrase usages. The spec does
not define any ways to retrieve the status of if the support of master
passphrase is available for the device, nor does the commands that utilize
master passphrase will return a specific error that indicates master
passphrase is not supported. If using a device does not support master
passphrase and a command is issued with a master passphrase, the error
message returned by the device will be ambiguous.
Reviewed-by: Davidlohr Bueso <dave@stgolabs.net>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
Link: https://lore.kernel.org/r/166983610751.2734609.4445075071552032091.stgit@djiang5-desk3.ch.intel.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
|
|
Document difference between amdgpu.gartsize and amdgpu.gttsize
module parameters, as initially explained by Alex Deucher here:
https://lists.freedesktop.org/archives/dri-devel/2022-October/375358.html
v2: minor cleanups (Alex)
Signed-off-by: Peter Maucher <bellosilicio@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Replace the open-code with sysfs_emit() to simplify the code.
Reviewed-by: Luben Tuikov <luben.tuikov@amd.com>
Signed-off-by: ye xingchen <ye.xingchen@zte.com.cn>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
This fixes DMCU initialization in APU GPU passthrough. The
DMCU needs the GPU physical address, not the CPU physical
address. This ends up working out on bare metal because
we always use the physical address, but doesn't work in
passthrough because the addresses are different.
Reviewed-by: Huang Rui <ray.huang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Under virtualization guest needs to receive notification from host to
perform reset in some cases. Add nv mailbox irq in soc21.
Signed-off-by: YuBiao Wang <YuBiao.Wang@amd.com>
Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
So that uses PSP to initialize HW.
Fixes: 0c2c02b66c672e ("drm/amdgpu/vcn: add firmware support for dimgrey_cavefish")
Signed-off-by: Leo Liu <leo.liu@amd.com>
Reviewed-by: James Zhu <James.Zhu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
So that uses PSP to initialize HW.
Fixes: 0c2c02b66c672e ("drm/amdgpu/vcn: add firmware support for dimgrey_cavefish")
Signed-off-by: Leo Liu <leo.liu@amd.com>
Reviewed-by: James Zhu <James.Zhu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging
Pull hwmon fixes from Guenter Roeck:
- Fix refcount leak and NULL pointer access in coretemp driver
- Fix UAF in ibmpex driver
- Add missing pci_disable_device() to i5500_temp driver
- Fix calculation in ina3221 driver
- Fix temperature scaling in ltc2947 driver
- Check result of devm_kcalloc call in asus-ec-sensors driver
* tag 'hwmon-for-v6.1-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging:
hwmon: (asus-ec-sensors) Add checks for devm_kcalloc
hwmon: (coretemp) fix pci device refcount leak in nv1a_ram_new()
hwmon: (coretemp) Check for null before removing sysfs attrs
hwmon: (ibmpex) Fix possible UAF when ibmpex_register_bmc() fails
hwmon: (i5500_temp) fix missing pci_disable_device()
hwmon: (ina3221) Fix shunt sum critical calculation
hwmon: (ltc2947) fix temperature scaling
|
