While in this particular case (*) it would not be an issue,
the pattern itself is bad and error prone in case somebody
blindly copies to their code.
Don't cast parameter to unsigned long pointer in the bit
operations. Note, new compilers might warn on this line for
potential outbound access.
*) it seems a dead code, so remove it all for good
Fixes: 13d19498b0 ("GRU Driver: driver internal header files")
Acked-by: Dimitri Sivanich <sivanich@hpe.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20220214153958.9721-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The family and device comparisons were using memcmp(), but this could
lead to Out-of-bounds reads when the length was larger than the
buffers being compared. Since these appear to always be NUL-terminated
strings, just use strcmp() instead.
This was found with Clang under LTO:
[ 92.405851][ T1] kernel BUG at lib/string_helpers.c:980!
...
[ 92.409141][ T1] RIP: 0010:fortify_panic (fbdev.c:?)
...
[ 92.410056][ T1] ni_assign_device_routes (fbdev.c:?)
[ 92.410056][ T1] ? unittest_enter (fbdev.c:?)
[ 92.410056][ T1] ni_routes_unittest (ni_routes_test.c:?)
[ 92.410056][ T1] ? unittest_enter (fbdev.c:?)
[ 92.410056][ T1] __initstub__kmod_ni_routes_test__505_604_ni_routes_unittest6 (fbdev.c:?)
[ 92.410056][ T1] do_one_initcall (fbdev.c:?)
Link: https://lore.kernel.org/lkml/20220210072821.GD4074@xsang-OptiPlex-9020
Fixes: 4bb90c87ab ("staging: comedi: add interface to ni routing table information")
Cc: Ian Abbott <abbotti@mev.co.uk>
Cc: H Hartley Sweeten <hsweeten@visionengravers.com>
Cc: Spencer E. Olson <olsonse@umich.edu>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Masahiro Yamada <masahiroy@kernel.org>
Cc: Lee Jones <lee.jones@linaro.org>
Reported-by: kernel test robot <oliver.sang@intel.com>
Reviewed-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20220215171017.1247291-1-keescook@chromium.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sukadev Bhattiprolu says:
====================
ibmvnic: Fix a race in ibmvnic_probe()
If we get a transport (reset) event right after a successful CRQ_INIT
during ibmvnic_probe() but before we set the adapter state to VNIC_PROBED,
we will throw away the reset assuming that the adapter is still in the
probing state. But since the adapter has completed the CRQ_INIT any
subsequent CRQs the we send will be ignored by the vnicserver until
we release/init the CRQ again. This can leave the adapter unconfigured.
While here fix a couple of other bugs that were observed (Patches 1,2,4).
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
We currently don't allow queuing resets when adapter is in VNIC_PROBING
state - instead we throw away the reset and return EBUSY. The reasoning
is probably that during ibmvnic_probe() the ibmvnic_adapter itself is
being initialized so performing a reset during this time can lead us to
accessing fields in the ibmvnic_adapter that are not fully initialized.
A review of the code shows that all the adapter state neede to process a
reset is initialized before registering the CRQ so that should no longer
be a concern.
Further the expectation is that if we do get a reset (transport event)
during probe, the do..while() loop in ibmvnic_probe() will handle this
by reinitializing the CRQ.
While that is true to some extent, it is possible that the reset might
occur _after_ the CRQ is registered and CRQ_INIT message was exchanged
but _before_ the adapter state is set to VNIC_PROBED. As mentioned above,
such a reset will be thrown away. While the client assumes that the
adapter is functional, the vnic server will wait for the client to reinit
the adapter. This disconnect between the two leaves the adapter down
needing manual intervention.
Because ibmvnic_probe() has other work to do after initializing the CRQ
(such as registering the netdev at a minimum) and because the reset event
can occur at any instant after the CRQ is initialized, there will always
be a window between initializing the CRQ and considering the adapter
ready for resets (ie state == PROBED).
So rather than discarding resets during this window, allow queueing them
- but only process them after the adapter is fully initialized.
To do this, introduce a new completion state ->probe_done and have the
reset worker thread wait on this before processing resets.
This change brings up two new situations in or just after ibmvnic_probe().
First after one or more resets were queued, we encounter an error and
decide to retry the initialization. At that point the queued resets are
no longer relevant since we could be talking to a new vnic server. So we
must purge/flush the queued resets before restarting the initialization.
As a side note, since we are still in the probing stage and we have not
registered the netdev, it will not be CHANGE_PARAM reset.
Second this change opens up a potential race between the worker thread
in __ibmvnic_reset(), the tasklet and the ibmvnic_open() due to the
following sequence of events:
1. Register CRQ
2. Get transport event before CRQ_INIT completes.
3. Tasklet schedules reset:
a) add rwi to list
b) schedule_work() to start worker thread which runs
and waits for ->probe_done.
4. ibmvnic_probe() decides to retry, purges rwi_list
5. Re-register crq and this time rest of probe succeeds - register
netdev and complete(->probe_done).
6. Worker thread resumes in __ibmvnic_reset() from 3b.
7. Worker thread sets ->resetting bit
8. ibmvnic_open() comes in, notices ->resetting bit, sets state
to IBMVNIC_OPEN and returns early expecting worker thread to
finish the open.
9. Worker thread finds rwi_list empty and returns without
opening the interface.
If this happens, the ->ndo_open() call is effectively lost and the
interface remains down. To address this, ensure that ->rwi_list is
not empty before setting the ->resetting bit. See also comments in
__ibmvnic_reset().
Fixes: 6a2fb0e99f ("ibmvnic: driver initialization for kdump/kexec")
Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Clear ->failover_pending flag that may have been set in the previous
pass of registering CRQ. If we don't clear, a subsequent ibmvnic_open()
call would be misled into thinking a failover is pending and assuming
that the reset worker thread would open the adapter. If this pass of
registering the CRQ succeeds (i.e there is no transport event), there
wouldn't be a reset worker thread.
This would leave the adapter unconfigured and require manual intervention
to bring it up during boot.
Fixes: 5a18e1e0c1 ("ibmvnic: Fix failover case for non-redundant configuration")
Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
We currently initialize the ->init_done completion/return code fields
before issuing a CRQ_INIT command. But if we get a transport event soon
after registering the CRQ the taskslet may already have recorded the
completion and error code. If we initialize here, we might overwrite/
lose that and end up issuing the CRQ_INIT only to timeout later.
If that timeout happens during probe, we will leave the adapter in the
DOWN state rather than retrying to register/init the CRQ.
Initialize the completion before registering the CRQ so we don't lose
the notification.
Fixes: 032c5e8284 ("Driver for IBM System i/p VNIC protocol")
Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Finish initializing the adapter before registering netdev so state
is consistent.
Fixes: c26eba03e4 ("ibmvnic: Update reset infrastructure to support tunable parameters")
Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
If we get a transport event, set the error and mark the init as
complete so the attempt to send crq-init or login fail sooner
rather than wait for the timeout.
Fixes: bbd669a868 ("ibmvnic: Fix completion structure initialization")
Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Define and use a helper to flush the reset queue.
Fixes: 2770a7984d ("ibmvnic: Introduce hard reset recovery")
Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
We should initialize ->init_done_rc before calling complete(). Otherwise
the waiting thread may see ->init_done_rc as 0 before we have updated it
and may assume that the CRQ was successful.
Fixes: 6b278c0cb3 ("ibmvnic delay complete()")
Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Fix a tiny memory leak when flushing the reset work queue.
Fixes: 2770a7984d ("ibmvnic: Introduce hard reset recovery")
Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
As talked about in commit b792e64021 ("drm: no need to check return
value of debugfs_create functions"), in many cases we can get away
with totally skipping checking the errors of debugfs functions. Let's
document that so people don't add new code that needlessly checks
these errors.
Probably this note could be added to a boatload of functions, but
that's a lot of duplication. Let's just add it to the two most
frequent ones and hope people will get the idea.
Suggested-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20220222154555.1.I26d364db7a007f8995e8f0dac978673bc8e9f5e2@changeid
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The 'err_remove_vmci_dev_g' error label is not at the right place.
This could lead to un-released resource.
There is also a missing label. If pci_alloc_irq_vectors() fails, the
previous vmci_event_subscribe() call must be undone.
Acked-by: Vishnu Dasa <vdasa@vmware.com>
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://lore.kernel.org/r/959218ce3b135197946d85cd9453551cd04fa5da.1645734041.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
w1_seq was failing due to several devices responding to the
CHAIN_DONE at the same time. Now properly selects the current
device in the chain with MATCH_ROM. Also acknowledgment was
read twice.
Signed-off-by: Lucas Denefle <lucas.denefle@converge.io>
Link: https://lore.kernel.org/r/20220223113558.232750-1-lucas.denefle@converge.io
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Extend Intel service layer driver to get the firmware version running at
FPGA device. Therefore FPGA manager driver, one of Intel service layer
driver's client, can decide whether to handle the newly added bitstream
authentication function based on the retrieved firmware version.
Link: https://lore.kernel.org/lkml/1617114785-22211-2-git-send-email-richard.gong@linux.intel.com
Acked-by: Moritz Fischr <mdf@kernel.org>
Signed-off-by: Richard Gong <richard.gong@intel.com>
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
Link: https://lore.kernel.org/r/20220223144908.399522-2-dinguyen@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
It has been proven on practice that at least Windows Server 2019 tries
using HVCALL_SEND_IPI_EX in 'XMM fast' mode when it has more than 64 vCPUs
and it needs to send an IPI to a vCPU > 63. Similarly to other XMM Fast
hypercalls (HVCALL_FLUSH_VIRTUAL_ADDRESS_{LIST,SPACE}{,_EX}), this
information is missing in TLFS as of 6.0b. Currently, KVM returns an error
(HV_STATUS_INVALID_HYPERCALL_INPUT) and Windows crashes.
Note, HVCALL_SEND_IPI is a 'standard' fast hypercall (not 'XMM fast') as
all its parameters fit into RDX:R8 and this is handled by KVM correctly.
Cc: stable@vger.kernel.org # 5.14.x: 3244867af8: KVM: x86: Ignore sparse banks size for an "all CPUs", non-sparse IPI req
Cc: stable@vger.kernel.org # 5.14.x
Fixes: d8f5537a88 ("KVM: hyper-v: Advertise support for fast XMM hypercalls")
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Message-Id: <20220222154642.684285-5-vkuznets@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
When TLB flush hypercalls (HVCALL_FLUSH_VIRTUAL_ADDRESS_{LIST,SPACE}_EX are
issued in 'XMM fast' mode, the maximum number of allowed sparse_banks is
not 'HV_HYPERCALL_MAX_XMM_REGISTERS - 1' (5) but twice as many (10) as each
XMM register is 128 bit long and can hold two 64 bit long banks.
Cc: stable@vger.kernel.org # 5.14.x
Fixes: 5974565bc2 ("KVM: x86: kvm_hv_flush_tlb use inputs from XMM registers")
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Message-Id: <20220222154642.684285-4-vkuznets@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
'struct kvm_hv_hcall' has all the required information already,
there's no need to pass 'ex' additionally.
No functional change intended.
Cc: stable@vger.kernel.org # 5.14.x
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Message-Id: <20220222154642.684285-3-vkuznets@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
'struct kvm_hv_hcall' has all the required information already,
there's no need to pass 'ex' additionally.
No functional change intended.
Cc: stable@vger.kernel.org # 5.14.x
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Message-Id: <20220222154642.684285-2-vkuznets@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
sc7180 blow fuses got slightly chances to hit qfprom_reg_write timeout.
Current timeout is simply too low. Since blowing fuses is a
very rare operation, so the risk associated with overestimating this
number is low.
Increase fuse blow timeout from 1ms to 10ms.
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Knox Chiou <knoxchiou@chromium.org>
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Link: https://lore.kernel.org/r/20220223223502.29454-2-srinivas.kandagatla@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Steffen Klassert says:
====================
1) Fix PMTU for IPv6 if the reported MTU minus the ESP overhead is
smaller than 1280. From Jiri Bohac.
2) Fix xfrm interface ID and inter address family tunneling when
migrating xfrm states. From Yan Yan.
3) Add missing xfrm intrerface ID initialization on xfrmi_changelink.
From Antony Antony.
4) Enforce validity of xfrm offload input flags so that userspace can't
send undefined flags to the offload driver.
From Leon Romanovsky.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
If I'm not mistaken (and I don't think I am), the way in which the
dcbnl_ops work is that drivers call dcb_ieee_setapp() and this populates
the application table with dynamically allocated struct dcb_app_type
entries that are kept in the module-global dcb_app_list.
However, nobody keeps exact track of these entries, and although
dcb_ieee_delapp() is supposed to remove them, nobody does so when the
interface goes away (example: driver unbinds from device). So the
dcb_app_list will contain lingering entries with an ifindex that no
longer matches any device in dcb_app_lookup().
Reclaim the lost memory by listening for the NETDEV_UNREGISTER event and
flushing the app table entries of interfaces that are now gone.
In fact something like this used to be done as part of the initial
commit (blamed below), but it was done in dcbnl_exit() -> dcb_flushapp(),
essentially at module_exit time. That became dead code after commit
7a6b6f515f ("DCB: fix kconfig option") which essentially merged
"tristate config DCB" and "bool config DCBNL" into a single "bool config
DCB", so net/dcb/dcbnl.c could not be built as a module anymore.
Commit 36b9ad8084 ("net/dcb: make dcbnl.c explicitly non-modular")
recognized this and deleted dcbnl_exit() and dcb_flushapp() altogether,
leaving us with the version we have today.
Since flushing application table entries can and should be done as soon
as the netdevice disappears, fundamentally the commit that is to blame
is the one that introduced the design of this API.
Fixes: 9ab933ab2c ("dcbnl: add appliction tlv handlers")
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
There's a potential leak issue under following execution sequence :
smc_release smc_connect_work
if (sk->sk_state == SMC_INIT)
send_clc_confirim
tcp_abort();
...
sk.sk_state = SMC_ACTIVE
smc_close_active
switch(sk->sk_state) {
...
case SMC_ACTIVE:
smc_close_final()
// then wait peer closed
Unfortunately, tcp_abort() may discard CLC CONFIRM messages that are
still in the tcp send buffer, in which case our connection token cannot
be delivered to the server side, which means that we cannot get a
passive close message at all. Therefore, it is impossible for the to be
disconnected at all.
This patch tries a very simple way to avoid this issue, once the state
has changed to SMC_ACTIVE after tcp_abort(), we can actively abort the
smc connection, considering that the state is SMC_INIT before
tcp_abort(), abandoning the complete disconnection process should not
cause too much problem.
In fact, this problem may exist as long as the CLC CONFIRM message is
not received by the server. Whether a timer should be added after
smc_close_final() needs to be discussed in the future. But even so, this
patch provides a faster release for connection in above case, it should
also be valuable.
Fixes: 39f41f367b ("net/smc: common release code for non-accepted sockets")
Signed-off-by: D. Wythe <alibuda@linux.alibaba.com>
Acked-by: Karsten Graul <kgraul@linux.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
In this driver's ->ndo_open() callback, it enables DMA interrupts,
starts the DMA channels, then requests interrupts with request_irq(),
and then finally enables napi.
If RX DMA interrupts are received before napi is enabled, no processing
is done because napi_schedule_prep() will return false. If the network
has a lot of broadcast/multicast traffic, then the RX ring could fill up
completely before napi is enabled. When this happens, no further RX
interrupts will be delivered, and the driver will fail to receive any
packets.
Fix this by only enabling DMA interrupts after all other initialization
is complete.
Fixes: 523f11b5d4 ("net: stmmac: move hardware setup for stmmac_open to new function")
Reported-by: Lars Persson <larper@axis.com>
Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This change adds a new OpenFlow field OFPXMT_OFB_IPV6_EXTHDR and
packets can be filtered using ipv6_ext flag.
Signed-off-by: Toms Atteka <cpp.code.lv@gmail.com>
Acked-by: Pravin B Shelar <pshelar@ovn.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Set regulator voltages for standby state to avoid wrong behavior of
system while in standby. The CPU voltage has been chosen as being the
one corresponding to OPP=600MHz. Next commit will set the 600MHz OPP
as the suspend OPP.
Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Link: https://lore.kernel.org/r/20220113144900.906370-8-claudiu.beznea@microchip.com
Fix low limit for CPU regulator. Otherwise setting voltages lower than
1.125V will not be allowed (CPUFreq will not be allowed to set proper
voltages on proper frequencies).
Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Link: https://lore.kernel.org/r/20220113144900.906370-7-claudiu.beznea@microchip.com
Add support for all the six CAN controllers of sama7g5.The internal SRAM of 128KB
is split among the CAN controllers for the message RAM elements leaving a small
portion reserved for power management. The SRAM split up is as below.
Lower 64K:
PM 13K
can-0 17K
can-1 17K
can-2 17K
Higher 64K:
can-3 17K
can-4 17K
can-5 17K
Signed-off-by: Hari Prasath <Hari.PrasathGE@microchip.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Link: https://lore.kernel.org/r/20220222113924.25799-2-Hari.PrasathGE@microchip.com
Describe and enable the AES, SHA and TDES crypto IPs. Tested with the
extra run-time self tests of the registered crypto algorithms.
Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Reviewed-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Link: https://lore.kernel.org/r/20220208105646.226623-1-tudor.ambarus@microchip.com
Christoph Hellwig and a few others spent a huge effort on removing
set_fs() from most of the important architectures, but about half the
other architectures were never completed even though most of them don't
actually use set_fs() at all.
I did a patch for microblaze at some point, which turned out to be fairly
generic, and now ported it to most other architectures, using new generic
implementations of access_ok() and __{get,put}_kernel_nocheck().
Three architectures (sparc64, ia64, and sh) needed some extra work,
which I also completed.
* 'set_fs-4' of git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic:
uaccess: remove CONFIG_SET_FS
ia64: remove CONFIG_SET_FS support
sh: remove CONFIG_SET_FS support
sparc64: remove CONFIG_SET_FS support
lib/test_lockup: fix kernel pointer check for separate address spaces
uaccess: generalize access_ok()
uaccess: fix type mismatch warnings from access_ok()
arm64: simplify access_ok()
m68k: fix access_ok for coldfire
MIPS: use simpler access_ok()
MIPS: Handle address errors for accesses above CPU max virtual user address
uaccess: add generic __{get,put}_kernel_nofault
nios2: drop access_ok() check from __put_user()
x86: use more conventional access_ok() definition
x86: remove __range_not_ok()
sparc64: add __{get,put}_kernel_nofault()
nds32: fix access_ok() checks in get/put_user
uaccess: fix nios2 and microblaze get_user_8()
uaccess: fix integer overflow on access_ok()
Fixes for devkit8000 timer regression. Similar to the earlier beagleboard
fixes, we must not configure the clocksource drivers to use an alternative
timer configuration. It causes unnecessary issues with power management.
Only some old designs based on early beagleboard revisions with a miswired
timer need to use the alternative timer.
-----BEGIN PGP SIGNATURE-----
iQJFBAABCAAvFiEEkgNvrZJU/QSQYIcQG9Q+yVyrpXMFAmIV9gMRHHRvbnlAYXRv
bWlkZS5jb20ACgkQG9Q+yVyrpXPSuRAA0CZo5VgXNkSijbwEB0vQ827nWtcC2iYu
9YISo+M/z2RWj2sevJTQVBHFFeNreOqWky0Ged2PndABoJRar7Uu7rNdhoLv99qI
guYv0s3pTPLB+5IzmU1kXdQDf5HCuqcNErBitIA2l12RXzUbAmdOW8EjA13wMIxu
2rQt1IsZMopWX94WSKclgO7XP5eWpA2MGR8r6OOHm1sFqI0bub2yd0n7V1GjM5jP
KiFXD53b0TPskRyB4F4zszqCCCR2Lz61Wwn13WdG++IkOzk+fIoFYLVJ/q1RMAKW
y8v+7iUJZBeusyN7C+602ibTPnDY8Ul15GH7+6kw11qxsIKa74UnB4qQupVN/7tt
2BbKKESiLI6wZtkCelXNlj7TC+w5Q5sj6YlOMuNbJrdyAAj3TjyiF3ndFLkDw5fv
Q5AQaQRfnYdKn2FBDUrgLnJ8Di1UUQUnnMPlPxlcmdDSHmpuFeggy1azVJRm1a7B
EFP9ot2KAYNdwHUwH3EMWdLOvSLC2hMNTKg5n9ACSoAXlJVDUmpq9vIvWNQeV0Al
Ncq2fwpFHt0p6JFk9ADARpaxaivaOA9MHF7XT2YacwDT0RoGs9cWfbVL7i5N4EEp
F7fu3mP8Oj3PZ9uVReRt3CI2EAf2oLpvM0+qs9hT06CWF0+Kgsr8zvZ9SPejcp/K
B7+wCtPZjpg=
=wzWV
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmIYq/8ACgkQmmx57+YA
GNmLSw/9F+h0hz1JaD1w6fU6Ke4/Wx8wipSBlbX+odKQpCzsp5510aGXfoWHoCfk
El0ZW1J6YkdHUN3CnN5AR/iFm3CBcNOjRVF/feq4OvrqQxMMIqKwbynF6F7J/46E
UykZlv2NMNh2b9riD188nA3hCp4be+A4JUEpt3BI7mmlycjoeOvXKBshZGHTuBtR
Shsp43l7hBHADjxhQmGNVAfQCDdhD0+CP7vMBNN2i8L576dzvzL9K9R+qMqVDCix
i8TFqlNTkW3N7AFiAMceLMVuRUEgTSguFgY+WAuv6KuyLC+MfElp5uXoI1RFXa4p
JDCfpsJ4RHGt9jBx+ha7kp+ulAekZv5rtkl9YB30Hd2VXjH8TP1D7SvpOmHA5I5T
fKNjkTs1HwvKfcZvR8N/Og+9f0bs7OlayYssTBYzFEMBYW0DYZV4eKNBco4vCsjF
3oaZmYF9eZZboHMIeyOqK9MpKsO9nvaooOZFKJOGGaKd3Gel09y33tKrPOmFCGuA
YjWUTIsTMcco+m/FV2DBjbToF92zbNx0vUPlev4JML9g3++QFkRwcdsgJ7IGbyYL
Y3rAhwPM0tvHaBS/UaTzr138QMaKQaZCwi8O7Ut7NrOCEmuEs4vOLiDVSf5JD4qT
24J8Z5qkyKQbbIyd3UuOYHqOBGcIO6nz9/V6A+x77xVM2paVrBk=
=6KSb
-----END PGP SIGNATURE-----
Merge tag 'omap-for-v5.17/fixes-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into arm/fixes
Fixes for omaps
Fixes for devkit8000 timer regression. Similar to the earlier beagleboard
fixes, we must not configure the clocksource drivers to use an alternative
timer configuration. It causes unnecessary issues with power management.
Only some old designs based on early beagleboard revisions with a miswired
timer need to use the alternative timer.
* tag 'omap-for-v5.17/fixes-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
ARM: dts: Use 32KiHz oscillator on devkit8000
ARM: dts: switch timer config to common devkit8000 devicetree
Link: https://lore.kernel.org/r/pull-1645606483-876944@atomide.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Using GIC_CPU_MASK_SIMPLE(x), x should reflect the number of CPUs.
STM32MP151 is a single A7.
STM32MP153/157 is a dual A7.
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
Acked-by: Marc Zyngier <maz@kernel.org>
Using GIC_CPU_MASK_SIMPLE(x), x should reflect the number of CPUs.
STM32MP13 is a single core A7.
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
Acked-by: Marc Zyngier <maz@kernel.org>
Remove the following warnings seen when building with W=1.
Warning (unique_unit_address): /soc/timer@40000c00: duplicate unit-address
(also used in node /soc/timers@40000c00)
This approach is based on some discussions[1], to restructure the dtsi
and dts files.
Timer5 is enabled by default on stm32f7 series, to act as clockevent. In
order to get rid of the W=1 warning, and be compliant with dt-schemas
(e.g. dtbs_check):
- In stm32f746.dtsi:
. Keep the more complete timers5 description
. Remove the most simple timer5 node that is duplicate
- In each board:
. adopt "st,stm32-timer" compatible for timers5, also add the interrupt
. use /delete-property/ and /delete-node/ so the it matches the
clockevent bindings
Note: all this is done in one shot (e.g. not split) to keep clockevent
functionality.
[1] https://lore.kernel.org/linux-arm-kernel/Yaf4jiZIp8+ndaXs@robh.at.kernel.org/
Signed-off-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com>
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
Several unused "timer" are duplicate nodes of "timers" nodes.
There are two dt-schemas:
- timer/st,stm32-timer.yaml: A timer is needed on STM32F7 series, on all
boards, to act as clockevent.
- mfd/st,stm32-timers.yaml: Timers can be used for other purpose.
By default, timer5 is left enabled to be used as clockevent. Remove all
other timer clockevent nodes that are currently unused and duplicated.
This removes several messages: Warning (unique_unit_address): /soc/timer@..
duplicate unit-address (also used in node /soc/timers@...)
Signed-off-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com>
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
As EXTI/GIC mapping has changed between STM32MP15 and STM32MP13, a new
compatible is needed to choose mp13 mapping table in stm32-exti driver.
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
DMA configuration is added to uart nodes in stm32mp15x device tree.
Delete uart4 DMA property in stm32mp15xx-dhcor-avenger96 board device
tree to keep console in irq mode, as DMA support for console has been
removed from the driver by commit e359b4411c ("serial: stm32: fix
threaded interrupt handling").
Delete also usart2 and uart7 DMA property to keep current behavior.
Signed-off-by: Erwan Le Ray <erwan.leray@foss.st.com>
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
DMA configuration is added to uart nodes in stm32mp15x device tree.
Delete uart4 DMA property in stm32mp15xx-dhcom-som board device tree
to keep console in irq mode, as DMA support for console has been
removed from the driver by commit e359b4411c ("serial: stm32: fix
threaded interrupt handling").
Signed-off-by: Erwan Le Ray <erwan.leray@foss.st.com>
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
DMA configuration is added to uart nodes in stm32mp15x device tree.
Delete usart3 and uart8 nodes DMA property in stm32mp15xx-dhcom-picoitx
board device tree to keep current behavior.
Signed-off-by: Erwan Le Ray <erwan.leray@foss.st.com>
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
DMA configuration is added to uart nodes in stm32mp15x device tree.
Delete usart3 and uart8 DMA property in stm32mp15xx-dhcom-pdk2 board
device tree to keep current behavior.
Signed-off-by: Erwan Le Ray <erwan.leray@foss.st.com>
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
DMA configuration is added to uart nodes in stm32mp15x device tree.
Delete usart3 and uart8 nodes DMA property in stm32mp15xx-dhcom-drc02
board device tree to keep current behavior.
Signed-off-by: Erwan Le Ray <erwan.leray@foss.st.com>
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
