Two fixes here, one from Johan which fixes error handling when we
attempt to create duplicate debugfs files and one for an incorrect
specification of ramp_delay with the rtq2208.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmY+C2IACgkQJNaLcl1U
h9BkKAf+Jf9Xu7YMB66E4+6bn7T95+9Fn0U8u3pjdjpNXn6Z70Kf+Tpr2mCFwJbV
DNoMuFZzav1+TK/aKQaB1iEXIKgZck3VjsFTRjEwAH4jtjOnEwuvMBnXlrNXZGBb
/nHOf8y3GAyrYJ0I6E/4BwyHq+WfzK1Dp61dkv91B5W3Cmz/sfuzpZ5uRJpAP33v
OyGfrUl12F5H3HkqmSPGMmUvyCpt+vzi+Fc/haltEsGVM8TmvyDy/qBML7K2sr2d
K7ESqCw/0kZ0YlOCSnU8SbMClYj8awGXtWVBLSNWA+51qGvcwgVrOhcX/320x0J8
Qvug1DZ/dm4DvzwgjD2p013/SQykww==
=V0Kh
-----END PGP SIGNATURE-----
Merge tag 'regulator-fix-v6.9-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator
Pull regulator fixes from Mark Brown:
"Two fixes here, one from Johan which fixes error handling when we
attempt to create duplicate debugfs files and one for an incorrect
specification of ramp_delay with the rtq2208"
* tag 'regulator-fix-v6.9-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator:
regulator: core: fix debugfs creation regression
regulator: rtq2208: Fix the BUCK ramp_delay range to maximum of 16mVstep/us
In the case of SEV-SNP, whether or not a 2MB page can be mapped via a
2MB mapping in the guest's nested page table depends on whether or not
any subpages within the range have already been initialized as private
in the RMP table. The existing mixed-attribute tracking in KVM is
insufficient here, for instance:
- gmem allocates 2MB page
- guest issues PVALIDATE on 2MB page
- guest later converts a subpage to shared
- SNP host code issues PSMASH to split 2MB RMP mapping to 4K
- KVM MMU splits NPT mapping to 4K
- guest later converts that shared page back to private
At this point there are no mixed attributes, and KVM would normally
allow for 2MB NPT mappings again, but this is actually not allowed
because the RMP table mappings are 4K and cannot be promoted on the
hypervisor side, so the NPT mappings must still be limited to 4K to
match this.
Add a hook to determine the max NPT mapping size in situations like
this.
Suggested-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Michael Roth <michael.roth@amd.com>
Reviewed-by: Isaku Yamahata <isaku.yamahata@intel.com>
Message-ID: <20240501085210.2213060-3-michael.roth@amd.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
In some cases, like with SEV-SNP, guest memory needs to be updated in a
platform-specific manner before it can be safely freed back to the host.
Wire up arch-defined hooks to the .free_folio kvm_gmem_aops callback to
allow for special handling of this sort when freeing memory in response
to FALLOC_FL_PUNCH_HOLE operations and when releasing the inode, and go
ahead and define an arch-specific hook for x86 since it will be needed
for handling memory used for SEV-SNP guests.
Signed-off-by: Michael Roth <michael.roth@amd.com>
Message-Id: <20231230172351.574091-6-michael.roth@amd.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
During guest run-time, kvm_arch_gmem_prepare() is issued as needed to
prepare newly-allocated gmem pages prior to mapping them into the guest.
In the case of SEV-SNP, this mainly involves setting the pages to
private in the RMP table.
However, for the GPA ranges comprising the initial guest payload, which
are encrypted/measured prior to starting the guest, the gmem pages need
to be accessed prior to setting them to private in the RMP table so they
can be initialized with the userspace-provided data. Additionally, an
SNP firmware call is needed afterward to encrypt them in-place and
measure the contents into the guest's launch digest.
While it is possible to bypass the kvm_arch_gmem_prepare() hooks so that
this handling can be done in an open-coded/vendor-specific manner, this
may expose more gmem-internal state/dependencies to external callers
than necessary. Try to avoid this by implementing an interface that
tries to handle as much of the common functionality inside gmem as
possible, while also making it generic enough to potentially be
usable/extensible for TDX as well.
Suggested-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Michael Roth <michael.roth@amd.com>
Co-developed-by: Michael Roth <michael.roth@amd.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
In preparation for adding a function that walks a set of pages
provided by userspace and populates them in a guest_memfd,
add a version of kvm_gmem_get_pfn() that has a "bool prepare"
argument and passes it down to kvm_gmem_get_folio().
Populating guest memory has to call repeatedly __kvm_gmem_get_pfn()
on the same file, so make the new function take struct file*.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
guest_memfd pages are generally expected to be in some arch-defined
initial state prior to using them for guest memory. For SEV-SNP this
initial state is 'private', or 'guest-owned', and requires additional
operations to move these pages into a 'private' state by updating the
corresponding entries the RMP table.
Allow for an arch-defined hook to handle updates of this sort, and go
ahead and implement one for x86 so KVM implementations like AMD SVM can
register a kvm_x86_ops callback to handle these updates for SEV-SNP
guests.
The preparation callback is always called when allocating/grabbing
folios via gmem, and it is up to the architecture to keep track of
whether or not the pages are already in the expected state (e.g. the RMP
table in the case of SEV-SNP).
In some cases, it is necessary to defer the preparation of the pages to
handle things like in-place encryption of initial guest memory payloads
before marking these pages as 'private'/'guest-owned'. Add an argument
(always true for now) to kvm_gmem_get_folio() that allows for the
preparation callback to be bypassed. To detect possible issues in
the way userspace initializes memory, it is only possible to add an
unprepared page if it is not already included in the filemap.
Link: https://lore.kernel.org/lkml/ZLqVdvsF11Ddo7Dq@google.com/
Co-developed-by: Michael Roth <michael.roth@amd.com>
Signed-off-by: Michael Roth <michael.roth@amd.com>
Message-Id: <20231230172351.574091-5-michael.roth@amd.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Because kvm_gmem_get_pfn() is called from the page fault path without
any of the slots_lock, filemap lock or mmu_lock taken, it is
possible for it to race with kvm_gmem_unbind(). This is not a
problem, as any PTE that is installed temporarily will be zapped
before the guest has the occasion to run.
However, it is not possible to have a complete unbind+bind
racing with the page fault, because deleting the memslot
will call synchronize_srcu_expedited() and wait for the
page fault to be resolved. Thus, we can still warn if
the file is there and is not the one we expect.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Some SNP ioctls will require the page not to be in the pagecache, and as such they
will want to return EEXIST to userspace. Start by passing the error up from
filemap_grab_folio.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
truncate_inode_pages_range() may attempt to zero pages before truncating
them, and this will occur before arch-specific invalidations can be
triggered via .invalidate_folio/.free_folio hooks via kvm_gmem_aops. For
AMD SEV-SNP this would result in an RMP #PF being generated by the
hardware, which is currently treated as fatal (and even if specifically
allowed for, would not result in anything other than garbage being
written to guest pages due to encryption). On Intel TDX this would also
result in undesirable behavior.
Set the AS_INACCESSIBLE flag to prevent the MM from attempting
unexpected accesses of this sort during operations like truncation.
This may also in some cases yield a decent performance improvement for
guest_memfd userspace implementations that hole-punch ranges immediately
after private->shared conversions via KVM_SET_MEMORY_ATTRIBUTES, since
the current implementation of truncate_inode_pages_range() always ends
up zero'ing an entire 4K range if it is backing by a 2M folio.
Link: https://lore.kernel.org/lkml/ZR9LYhpxTaTk6PJX@google.com/
Suggested-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Michael Roth <michael.roth@amd.com>
Message-ID: <20240329212444.395559-6-michael.roth@amd.com>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
filemap users like guest_memfd may use page cache pages to
allocate/manage memory that is only intended to be accessed by guests
via hardware protections like encryption. Writes to memory of this sort
in common paths like truncation may cause unexpected behavior such as
writing garbage instead of zeros when attempting to zero pages, or
worse, triggering hardware protections that are considered fatal as far
as the kernel is concerned.
Introduce a new address_space flag, AS_INACCESSIBLE, and use this
initially to prevent zero'ing of pages during truncation, with the
understanding that it is up to the owner of the mapping to handle this
specially if needed.
This is admittedly a rather blunt solution, but it seems like
there are no other places that should take into account the
flag to keep its promise.
Link: https://lore.kernel.org/lkml/ZR9LYhpxTaTk6PJX@google.com/
Cc: Matthew Wilcox <willy@infradead.org>
Suggested-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Michael Roth <michael.roth@amd.com>
Message-ID: <20240329212444.395559-5-michael.roth@amd.com>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Including:
- Fix offset miscalculation on ARM-SMMU driver
- AMD IOMMU fix for initializing state of untrusted devices
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEr9jSbILcajRFYWYyK/BELZcBGuMFAmY9+5wACgkQK/BELZcB
GuPzQg/9EwElcc9Vtdcnoiyl0VgdmlAF3IxLIL8LbM+WEm/PXMK+LnYDBdclLQIo
lW9v4ZGzm+DKqRF1ksC78/yKWcbfJ31rzkE7Ztf57yzHkVxB1qWe7/ksrpkn0Fjx
32Y6lhhaw6WACXA1gSvz/TXiL+Zr8F/T++R5Cxc1gCFo11W1A/jrXOKjNgNtNx/U
O9/uDpIFHdQvvOBmAPpFQi43P7TPb4PylEjPzsJQP239ZTFT7h25vZZHdA3PfyPU
+nSisgibpOMfyMbqY25q4Qg4+Ek0BvdG3yi8+mlUK9MRKwvebCIBhIsSh2HWSSGu
jyq0xzPc5Av7ufWNKA9L3jbxgAtnODrc8cUlUQ7lXNNB7hPz10QiDfvMmVXrvcwW
B8K4agYf2wfK64lJuMpbjbh3qFXbAoWKjQMx7xwji7LVhukdA0ndbERg1YKN3nLO
39KLatEDgTLqHsKclIbCdwwd8FfYQTFrUTT4nHsVW4YFhtUd8yNuh4bdmOFgHaNg
/9VhII864BAwWy6P4pYur921rRBorHAQ20PyeOsNOMESFtA7VQOX504zbCayiknf
dYeoQGUnS202a1gjicpMMWMF5IzZE681Z8YLbndrNyjpiQ5pi8IWDDGstdHqmhtX
vcc0S0WIMHBlZPbkAATu/A7A3bwymImmbJ1n9y7S6RHbtu/mKGo=
=zdMj
-----END PGP SIGNATURE-----
Merge tag 'iommu-fixes-v6.9-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu
Pull iommu fixes from Joerg Roedel:
- Fix offset miscalculation on ARM-SMMU driver
- AMD IOMMU fix for initializing state of untrusted devices
* tag 'iommu-fixes-v6.9-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu:
iommu/arm-smmu: Use the correct type in nvidia_smmu_context_fault()
iommu/amd: Enhance def_domain_type to handle untrusted device
It incorrectly claimed a resource isn't CPU visible if it's located at
the very end of CPU visible VRAM.
Fixes: a6ff969fe9 ("drm/amdgpu: fix visible VRAM handling during faults")
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3343
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reported-and-Tested-by: Jeremy Day <jsday@noreason.ca>
Signed-off-by: Michel Dänzer <mdaenzer@redhat.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
CC: stable@vger.kernel.org
We don't get the right offset in that case. The GPU has
an unused 4K area of the register BAR space into which you can
remap registers. We remap the HDP flush registers into this
space to allow userspace (CPU or GPU) to flush the HDP when it
updates VRAM. However, on systems with >4K pages, we end up
exposing PAGE_SIZE of MMIO space.
Fixes: d8e408a827 ("drm/amdkfd: Expose HDP registers to user space")
Reviewed-by: Felix Kuehling <felix.kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Be a bit more consistent in our use of integer types in
the fb related calculatiosn. u32 we generally only use
for ggtt offsets and such, and everything else can be regular
(unsigned) ints.
There's also an overabundance of consts for local variables
in skl_check_main_surface() which is not something we generally
do. So get rid of those while at it.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240506125718.26001-6-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Plane .max_stride() is already a vfunc so having one made
up of two branches based on the display version is silly.
Split i9xx_plane_max_stride() into gen2 vs. gen3 variants
so that we get rid of said check.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240506125718.26001-2-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Fix the typo in the function documentation to please kernel doc
warnings.
Signed-off-by: Christian Göttsche <cgzones@googlemail.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: John Johansen <john.johansen@canonical.com>
The inlined function is_deleted is redundant, it is not called at all
from any function in security/apparmor/file.c and so it can be removed.
Cleans up clang scan build warning:
security/apparmor/file.c:153:20: warning: unused function
'is_deleted' [-Wunused-function]
Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
Signed-off-by: John Johansen <john.johansen@canonical.com>
The original topology evaluation code initialized cpu_data::topo::llc_id
with the die ID initialy and then eventually overwrite it with information
gathered from a CPUID leaf.
The conversion analysis failed to spot that particular detail and omitted
this initial assignment under the assumption that each topology evaluation
path will set it up. That assumption is mostly correct, but turns out to be
wrong in case that the CPUID leaf 0x80000006 does not provide a LLC ID.
In that case, LLC ID is invalid and as a consequence the setup of the
scheduling domain CPU masks is incorrect which subsequently causes the
scheduler core to complain about it during CPU hotplug:
BUG: arch topology borken
the CLS domain not a subset of the MC domain
Cure it by reusing legacy_set_llc() and assigning the die ID if the LLC ID
is invalid after all possible parsers have been tried.
Fixes: f7fb3b2dd9 ("x86/cpu: Provide an AMD/HYGON specific topology parser")
Reported-by: Yuezhang Mo <Yuezhang.Mo@sony.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Tested-by: Yuezhang Mo <Yuezhang.Mo@sony.com>
Link: https://lore.kernel.org/r/PUZPR04MB63168AC442C12627E827368581292@PUZPR04MB6316.apcprd04.prod.outlook.com
Inside unpack_profile() data->data is allocated using kvmemdup() so it
should be freed with the corresponding kvfree_sensitive().
Also add missing data->data release for rhashtable insertion failure path
in unpack_profile().
Found by Linux Verification Center (linuxtesting.org).
Fixes: e025be0f26 ("apparmor: support querying extended trusted helper extra data")
Cc: stable@vger.kernel.org
Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru>
Signed-off-by: John Johansen <john.johansen@canonical.com>
`dev->of_node` already has a reference to the device_node and calling
of_node_get on it is unnecessary. All conresponding calls to
of_node_put are also removed.
Signed-off-by: Shresth Prasad <shresthprasad7@gmail.com>
Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>
Link: https://lore.kernel.org/r/20240502172121.8695-2-shresthprasad7@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
The mp3309 has two configuration registers, named according to their
address (0x00 and 0x01).
In the second register (0x01), the bit DIMS (Dimming Mode Select) must
be always 0 (zero), in both analog (via I2C commands) and PWM dimming
mode.
In the initial driver version, the DIMS bit was set in PWM mode and
reset in analog mode.
But if the DIMS bit is set in pwm dimming mode and other devices are
connected on the same I2C bus, every I2C commands on the bus generates a
flickering on the LEDs powered by the mp3309c.
This change concerns the chip initialization and does not impact any
existing device-tree configuration.
Signed-off-by: Flavio Suligoi <f.suligoi@asem.it>
Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>
Link: https://lore.kernel.org/r/20240417153105.1794134-2-f.suligoi@asem.it
Signed-off-by: Lee Jones <lee@kernel.org>
Core in spi_register_driver() already sets the .owner, so driver
does not need to.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>
Link: https://lore.kernel.org/r/20240327174714.519577-1-krzysztof.kozlowski@linaro.org
Signed-off-by: Lee Jones <lee@kernel.org>
The backlight driver supports getting passed platform data. However this
isn't used. This allows to remove quite some dead code from the driver
because bl->pdata is always NULL, and so bl->mode is always
LP8788_BL_REGISTER_ONLY.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>
Link: https://lore.kernel.org/r/20240329133839.550065-2-u.kleine-koenig@pengutronix.de
Signed-off-by: Lee Jones <lee@kernel.org>
Since commit 43a7206b09 ("driver core: class: make class_register() take
a const *"), the driver core allows for struct class to be in read-only
memory, so move the lcd_class structure to be declared at build time
placing it into read-only memory, instead of having to be dynamically
allocated at boot time.
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ricardo B. Marliere <ricardo@marliere.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>
Link: https://lore.kernel.org/r/2024032809-enchanted-conducive-3677@gregkh
Signed-off-by: Lee Jones <lee@kernel.org>
Since commit 43a7206b09 ("driver core: class: make class_register() take
a const *"), the driver core allows for struct class to be in read-only
memory, so move the backlight_class structure to be declared at build time
placing it into read-only memory, instead of having to be dynamically
allocated at boot time.
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ricardo B. Marliere <ricardo@marliere.net>
Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>
Link: https://lore.kernel.org/r/20240305-class_cleanup-backlight-v1-1-c0e15cc25be1@marliere.net
Signed-off-by: Lee Jones <lee@kernel.org>
The "num_levels" variable is used to store error codes from
device_property_count_u32() so it needs to be signed. This doesn't
cause an issue at runtime because devm_kcalloc() won't allocate negative
sizes. However, it's still worth fixing.
Fixes: b54c828bdb ("backlight: mp3309c: Make use of device properties")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>
Tested-by: Flavio Suligoi <f.suligoi@asem.it>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/74347f67-360d-4513-8939-595e3c4764fa@moroto.mountain
Signed-off-by: Lee Jones <lee@kernel.org>
When referencing other schema, it is preferred to use an absolute path
(/schemas/....), which allows also an seamless move of particular schema
out of Linux kernel to dtschema.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Reviewed-by: Matti Vaittinen <mazziesaccount@gmail.com>
Link: https://lore.kernel.org/r/20240503072116.12430-1-krzysztof.kozlowski@linaro.org
Signed-off-by: Lee Jones <lee@kernel.org>
Convert the lp873x binding to DT schema format. The gpio-controller
and #gpio-cells properties were removed from required because using
the device as a GPIO controller is optional.
Signed-off-by: Nathan Morrisson <nmorrisson@phytec.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20240429195830.4027250-1-nmorrisson@phytec.com
Signed-off-by: Lee Jones <lee@kernel.org>
The use of 'oneOf' to include 1 of 3 possible child node schemas results
in error messages containing the actual error message(s) for the correct
SoC buried in the tons of error messages from the 2 schemas that don't
apply. It also causes the pinctrl schema to be applied twice as it will
be applied when the compatible matches.
All that's really needed in the parent schema is to ensure one of the
possible compatible strings is present in the pinctrl node so that its
schema will be applied separately.
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Reviewed-by: Andrew Jeffery <andrew@codeconstruct.com.au>
Link: https://lore.kernel.org/r/20240430172520.535179-1-robh@kernel.org
Signed-off-by: Lee Jones <lee@kernel.org>
Underscores should not be used in node names (dtc with W=2 warns about
them), so replace them with hyphens. This should have no impact on
known users: Linux MFD driver does not care about children node names.
DTS was already adjusted in commit 0f47ef3ff1 ("arm: dts: allwinner: drop
underscore in node names"), so without this change, we observe
dtbs_check warnings:
sun6i-a31s-colorfly-e708-q1.dtb: prcm@1f01400: 'ahb0-clk', 'apb0-clk', 'apb0-gates-clk', 'apb0-rst', 'ar100-clk', 'ir-clk' do not match any of the regexes: '^.*_(clk|rst)$', 'pinctrl-[0-9]+'
Reported-by: Rob Herring <robh@kernel.org>
Closes: https://lore.kernel.org/all/CAL_JsqJfT-jui5P56CO4Fr37kr5iNN8dpxt8ecKeFmdVGnRYbA@mail.gmail.com/
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://lore.kernel.org/r/20240424045521.31857-1-krzysztof.kozlowski@linaro.org
Signed-off-by: Lee Jones <lee@kernel.org>
The ->init() open codes the functionality of DMI matching code.
Moreover, all DMI quirks are using the same callback and driver_data.
With this in mind, refactor the DMI matching code.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20240423210706.3709568-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Lee Jones <lee@kernel.org>
The firmware can only be patched once. The current code checks if the
firmware supports the features required by the driver and then patches
if it does not. This could lead to the device being patched twice if
the device was patched before the driver took control, but with a
firmware that doesn't support the features the driver requires. This
would fail but potentially in unpredictable ways.
The check should actually check the device is at the ROM version, and
patch the device if it is. Then a separate later check should error out
if the devices firmware is still too old to be supported. This will at
least fail in a clean way with a nice error message.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20240423102339.2363400-1-ckeepax@opensource.cirrus.com
Signed-off-by: Lee Jones <lee@kernel.org>
Add missing compatible for the pm8901 model used in msm8660
such as (HP TouchPad (tenderloin).
Signed-off-by: Herman van Hazendonk <github.com@herrie.org>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://lore.kernel.org/r/20240415123038.1526386-1-github.com@herrie.org
Signed-off-by: Lee Jones <lee@kernel.org>
The variable err is being assigned -ENODEV and then err is being
re-assigned the same error value via the error exit label err_mfd.
The assignment is redundant and can be removed.
Cleans up clang scan build warning:
drivers/mfd/timberdale.c:768:3: warning: Value stored to 'err' is
never read [deadcode.DeadStores]
Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
Link: https://lore.kernel.org/r/20240415102632.484411-1-colin.i.king@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
Add the PBS (Programmable Boot Sequencer) to the list of devices.
Reviewed-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20240412-pmi632-ppg-v2-1-8ac892b1bb61@fairphone.com
Signed-off-by: Lee Jones <lee@kernel.org>
The CTRLMMR_MAC_IDx registers within the CTRL_MMR space of TI's AM62p SoC
contain the MAC Address programmed in the eFuse. Add compatible for
allowing the CPSW driver to obtain a regmap for the CTRLMMR_MAC_IDx
registers within the System Controller device-tree node. The default MAC
Address for the interface corresponding to the first MAC port will be set
to the value programmed in the eFuse.
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20240402105708.4114146-1-s-vadapalli@ti.com
Signed-off-by: Lee Jones <lee@kernel.org>
The maple tree register cache is based on a much more modern data structure
than the rbtree cache and makes optimisation choices which are probably
more appropriate for modern systems than those made by the rbtree cache.
Signed-off-by: wangkaiyuan <wangkaiyuan@inspur.com>
Link: https://lore.kernel.org/r/20240429024547.27724-1-wangkaiyuan@inspur.com
Signed-off-by: Lee Jones <lee@kernel.org>
The secure update driver does a sanity-check of the image size in
comparison to the size of the staging area in FLASH. Instead of
hard-wiring M10BMC_STAGING_SIZE, move the staging size to the
m10bmc_csr_map structure to make the size assignment more flexible.
Co-developed-by: Russ Weight <russell.h.weight@intel.com>
Signed-off-by: Russ Weight <russell.h.weight@intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Peter Colberg <peter.colberg@intel.com>
Reviewed-by: Xu Yilun <yilun.xu@intel.com>
Link: https://lore.kernel.org/r/20240402184925.1065932-1-peter.colberg@intel.com
Signed-off-by: Lee Jones <lee@kernel.org>
As this chip was seen in several devices in the wild, add it.
Suggested-by: Matti Vaittinen <mazziesaccount@gmail.com>
Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Acked-by: Matti Vaittinen <mazziesaccount@gmail.com>
Link: https://lore.kernel.org/r/20240404195423.666446-2-andreas@kemnade.info
Signed-off-by: Lee Jones <lee@kernel.org>
