- 25 Jun, 2022 3 commits
-
-
Frank Jungclaus authored
Each occurrence of the term "usb2" within variables, function names, comments, etc. is changed to "usb" where it is shared for all esd CAN/USB devices. Link: https://lore.kernel.org/all/20220624190517.2299701-4-frank.jungclaus@esd.euSigned-off-by:
Frank Jungclaus <frank.jungclaus@esd.eu> Signed-off-by:
Marc Kleine-Budde <mkl@pengutronix.de>
-
Frank Jungclaus authored
As suggested by Marc, I added an entry for ESD CAN/USB Drivers to the MAINTAINERS file Link: https://lore.kernel.org/all/20220624190517.2299701-3-frank.jungclaus@esd.euSigned-off-by:
-
Frank Jungclaus authored
As suggested by Vincent, renaming of esd_usb2.c to esd_usb.c and according to that, adaption of Kconfig and Makfile, too. Link: https://lore.kernel.org/all/20220624190517.2299701-2-frank.jungclaus@esd.euSigned-off-by:
-
- 13 Jun, 2022 4 commits
-
-
Marc Kleine-Budde authored
can: netlink: allow configuring of fixed data bit rates without need for do_set_data_bittiming callback This patch is similar to 7e193a42 ("can: netlink: allow configuring of fixed bit rates without need for do_set_bittiming callback") but for data bit rates instead of bit rates. Usually CAN devices support configurable data bit rates. The limits are defined by struct can_priv::data_bittiming_const. Another way is to implement the struct can_priv::do_set_data_bittiming callback. If the bit rate is configured via netlink, the can_changelink() function checks that either can_priv::data_bittiming_const or struct can_priv::do_set_data_bittiming is implemented. In commit 431af779 ("can: dev: add CAN interface API for fixed bitrates") an API for configuring bit rates on CAN interfaces that only support fixed bit rates was added. The supported bit rates are defined by struct can_priv::bitrate_const. However the above mentioned commit forgot to add the struct can_priv::data_bitrate_const to the check in can_changelink(). In order to avoid to implement a no-op can_priv::do_set_data_bittiming callback on devices with fixed data bit rates, extend the check in can_changelink() accordingly. Link: https://lore.kernel.org/all/20220613143633.4151884-1-mkl@pengutronix.de Fixes: 431af779 ("can: dev: add CAN interface API for fixed bitrates") Acked-by:
Max Staudt <max@enpas.org> Signed-off-by:
-
Marc Kleine-Budde authored
Conor Dooley says: ==================== When adding the dts for PolarFire SoC, the can controllers were omitted, so here they are... ==================== Link: https://lore.kernel.org/all/20220607065459.2035746-1-conor.dooley@microchip.comSigned-off-by:
-
Conor Dooley authored
PolarFire SoC has a pair of CAN controllers, but as they were undocumented there were omitted from the device tree. Add them. Link: https://lore.kernel.org/all/20220607065459.2035746-3-conor.dooley@microchip.comSigned-off-by:
Conor Dooley <conor.dooley@microchip.com> Signed-off-by:
-
Conor Dooley authored
Add a binding for the CAN controller on PolarFire SoC (MPFS). A data sheet and a register map can be downloaded at: | https://www.microsemi.com/document-portal/doc_download/1245725-polarfire-soc-fpga-mss-technical-reference-manual | https://www.microsemi.com/document-portal/doc_download/1244581-polarfire-soc-register-map An alternative location for the register map is: | http://web.archive.org/web/20220403030214/https://www.microsemi.com/document-portal/doc_download/1244581-polarfire-soc-register-map Link: https://lore.kernel.org/all/20220607065459.2035746-2-conor.dooley@microchip.comSigned-off-by:
Rob Herring <robh@kernel.org> [mkl: add link to data sheet and register map] Signed-off-by:
-
- 11 Jun, 2022 19 commits
-
-
Marc Kleine-Budde authored
Vincent Mailhol says: ==================== This series contains two clean up patches toward struct es58x_device of the CAN etas_es58x driver. The first one removes the field rx_max_packet_size which value can actually be retrieved from the helper function usb_maxpacket(). The second one fixes the signedness of the TX and RX pipes. No functional changes. ==================== Link: https://lore.kernel.org/all/20220611162037.1507-1-mailhol.vincent@wanadoo.frSigned-off-by:
-
Vincent Mailhol authored
USB pipes are meant to be unsigned int (c.f. [1]). However, fields rx_pipe and tx_pipe of struct es58x_device are both signed integers. Change the type of those two fields from int to unsigned int. [1] https://elixir.bootlin.com/linux/v5.18/source/include/linux/usb.h#L1571 Link: https://lore.kernel.org/all/20220611162037.1507-3-mailhol.vincent@wanadoo.frSigned-off-by:
Vincent Mailhol <mailhol.vincent@wanadoo.fr> Signed-off-by:
-
Vincent Mailhol authored
The field rx_max_packet_size of struct es58x_device in nothing else than usb_endpoint_descriptor::wMaxPacketSize and can be easily retrieved using usb_maxpacket(). Also, rx_max_packet_size being used a single time, there is no merit to cache it locally. Remove es58x_device::rx_max_packet_size and rely on usb_maxpacket() instead. Link: https://lore.kernel.org/all/20220611162037.1507-2-mailhol.vincent@wanadoo.frSigned-off-by:
-
Max Staudt authored
There are two sections called "Local Loopback of Sent Frames". One was meant to link to the other, but pointed at itself instead. Link: https://lore.kernel.org/all/20220611171155.9090-1-max@enpas.org Fixes: 7d597739 ("can: migrate documentation to restructured text") Signed-off-by:
-
Marc Kleine-Budde authored
Vincent Mailhol says ==================== Aside of calc_bittiming.o which can be configured with CAN_CALC_BITTIMING, all objects from drivers/net/can/dev/ get linked unconditionally to can-dev.o even if not needed by the user. This series first goal it to split the can-dev modules so that the only the needed features get built in during compilation. Additionally, the CAN Device Drivers menu is moved from the "Networking support" category to the "Device Drivers" category (where all drivers are supposed to be). * menu before this series * CAN bus subsystem support symbol: CONFIG_CAN | +-> CAN Device Drivers (no symbol) | +-> software/virtual CAN device drivers | (at time of writing: slcan, vcan, vxcan) | +-> Platform CAN drivers with Netlink support symbol: CONFIG_CAN_DEV | +-> CAN bit-timing calculation (optional for hardware drivers) | symbol: CONFIG_CAN_CALC_BITTIMING | +-> All other CAN devices drivers * menu after this series * Network device support symbol: CONFIG_NETDEVICES | +-> CAN Device Drivers symbol: CONFIG_CAN_DEV | +-> software/virtual CAN device drivers | (at time of writing: slcan, vcan, vxcan) | +-> CAN device drivers with Netlink support symbol: CONFIG_CAN_NETLINK (matches previous CONFIG_CAN_DEV) | +-> CAN bit-timing calculation (optional for all drivers) | symbol: CONFIG_CAN_CALC_BITTIMING | +-> All other CAN devices drivers (some may select CONFIG_CAN_RX_OFFLOAD) | +-> CAN rx offload (automatically selected by some drivers) (hidden symbol: CONFIG_CAN_RX_OFFLOAD) Patches 1 to 5 of this series do above modification. The last two patches add a check toward CAN_CTRLMODE_LISTENONLY in can_dropped_invalid_skb() to discard tx skb (such skb can potentially reach the driver if injected via the packet socket). In more details, patch 6 moves can_dropped_invalid_skb() from skb.h to skb.o and patch 7 is the actual change. Those last two patches are actually connected to the first five ones: because slcan and v(x)can requires can_dropped_invalid_skb(), it was necessary to add those three devices to the scope of can-dev before moving the function to skb.o. This design results from the lengthy discussion in [1]. [1] https://lore.kernel.org/linux-can/20220514141650.1109542-1-mailhol.vincent@wanadoo.fr/ ** Changelog ** v5 -> v6: * fix typo in patch #1's title: Kbuild -> Kconfig. * make CONFIG_RX_CAN an hidden config symbol and modify the diagram in the cover letter accordingly. @Oliver, with CONFIG_CAN_RX_OFFLOAD now being an hidden config, that option fully depends on the drivers. So contrary to your suggestion, I put CONFIG_CAN_RX_OFFLOAD below the device drivers in the diagram. * fix typo in cover letter: CONFIG_CAN_BITTIMING -> CONFIG_CAN_CALC_BITTIMING. v4 -> v5: * m_can is also requires RX offload. Add the "select CAN_RX_OFFLOAD" to its Makefile. * Reorder the lines of drivers/net/can/dev/Makefile. * Remove duplicated rx-offload.o target in drivers/net/can/dev/Makefile * Remove the Nota Bene in the cover letter. v3 -> v4: * Five additional patches added to split can-dev module and refactor Kbuild. c.f. below (lengthy) thread: https://lore.kernel.org/linux-can/20220514141650.1109542-1-mailhol.vincent@wanadoo.fr/ v2 -> v3: * Apply can_dropped_invalid_skb() to slcan. * Make vcan, vxcan and slcan dependent of CONFIG_CAN_DEV by modifying Kbuild. * fix small typos. v1 -> v2: * move can_dropped_invalid_skb() to skb.c instead of dev.h * also move can_skb_headroom_valid() to skb.c ==================== Link: https://lore.kernel.org/all/20220610143009.323579-1-mailhol.vincent@wanadoo.frSigned-off-by: -
Vincent Mailhol authored
Frames can be directly injected to a can driver via the packet socket. By doing so, it is possible to reach the net_device_ops::ndo_start_xmit function even if the driver is configured in listen only mode. Add a check in can_dropped_invalid_skb() to discard the skb if CAN_CTRLMODE_LISTENONLY is set. Link: https://lore.kernel.org/all/20220610143009.323579-8-mailhol.vincent@wanadoo.frSigned-off-by:
Oliver Hartkopp <socketcan@hartkopp.net> Signed-off-by:
-
Vincent Mailhol authored
The functions can_dropped_invalid_skb() and can_skb_headroom_valid() grew a lot over the years to a point which it does not make much sense to have them defined as static inline in header files. Move those two functions to the .c counterpart of skb.h. can_skb_headroom_valid()'s only caller being can_dropped_invalid_skb(), the declaration is removed from the header. Only can_dropped_invalid_skb() gets its symbol exported. While doing so, do a small cleanup: add brackets around the else block in can_dropped_invalid_skb(). Link: https://lore.kernel.org/all/20220610143009.323579-7-mailhol.vincent@wanadoo.frSigned-off-by:
kernel test robot <lkp@intel.com> Acked-by:
-
Vincent Mailhol authored
The devices are meant to be under the "Device Drivers" category of the menuconfig. The CAN subsystem is currently one of the rare exception with all of its devices under the "Networking support" category. The CAN_DEV menuentry gets moved to fix this discrepancy. The CAN menu is added just before MCTP in order to be consistent with the current order under the "Networking support" menu. A dependency on CAN is added to CAN_DEV so that the CAN devices only show up if the CAN subsystem is enabled. Link: https://lore.kernel.org/all/20220610143009.323579-6-mailhol.vincent@wanadoo.frSigned-off-by:
-
Vincent Mailhol authored
Only a few drivers rely on the CAN rx offload framework (as of the writing of this patch, only four: flexcan, m_can, mcp251xfd and ti_hecc). Split it out of can-dev and add a new config symbol: CAN_RX_OFFLOAD. The drivers relying on CAN rx offload are in different sub folders. Make CAN_RX_OFFLOAD an hidden option and tag all the drivers depending on that feature with "select CAN_RX_OFFLOAD" so that the option gets automatically enabled if and only if one of those drivers is chosen. Link: https://lore.kernel.org/all/20220610143009.323579-5-mailhol.vincent@wanadoo.frSuggested-by:
Geert Uytterhoeven <geert@linux-m68k.org> Suggested-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
-
Vincent Mailhol authored
The canonical way to select or deselect an object during compilation is to use this pattern in the relevant Makefile: bar-$(CONFIG_FOO) := foo.o bittiming.c instead uses some #ifdef CONFIG_CAN_CALC_BITTIMG. Create a new file named calc_bittiming.c with all the functions which are conditionally compiled with CONFIG_CAN_CALC_BITTIMG and modify the Makefile according to above pattern. Link: https://lore.kernel.org/all/20220610143009.323579-4-mailhol.vincent@wanadoo.frSigned-off-by:
-
Vincent Mailhol authored
In the next patches, the software/virtual drivers (slcan, v(x)can) will depend on drivers/net/can/dev/skb.o. This patch changes the scope of the can-dev module to include the above mentioned drivers. To do so, we reuse the menu "CAN Device Drivers" and turn it into a configmenu using the config symbol CAN_DEV (which we released in previous patch). Also, add a description to this new CAN_DEV menuconfig. The symbol CAN_DEV now only triggers the build of skb.o. For this reasons, all the macros from linux/module.h are deported from drivers/net/can/dev/dev.c to drivers/net/can/dev/skb.c. Finally, drivers/net/can/dev/Makefile is adjusted accordingly. Link: https://lore.kernel.org/all/20220610143009.323579-3-mailhol.vincent@wanadoo.frSuggested-by:
-
Vincent Mailhol authored
In the next patches, the scope of the can-dev module will grow to engloble the software/virtual drivers (slcan, v(x)can). To this extent, release CAN_DEV by renaming it into CAN_NETLINK. The config symbol CAN_DEV will be reused to cover this extended scope. The rationale for the name CAN_NETLINK is that netlink is the predominant feature added here. The current description only mentions platform drivers despite the fact that this symbol is also required by "normal" devices (e.g. USB or PCI) which do not fall under the platform devices category. The description is updated accordingly to fix this gap. Link: https://lore.kernel.org/all/20220610143009.323579-2-mailhol.vincent@wanadoo.frSigned-off-by:
-
Marc Kleine-Budde authored
Usually CAN devices support configurable bit rates. The limits are defined by struct can_priv::bittiming_const. Another way is to implement the struct can_priv::do_set_bittiming callback. If the bit rate is configured via netlink, the can_changelink() function checks that either can_priv::bittiming_const or struct can_priv::do_set_bittiming is implemented. In commit 431af779 ("can: dev: add CAN interface API for fixed bitrates") an API for configuring bit rates on CAN interfaces that only support fixed bit rates was added. The supported bit rates are defined by struct can_priv::bitrate_const. However the above mentioned commit forgot to add the struct can_priv::bitrate_const to the check in can_changelink(). In order to avoid to implement a no-op can_priv::do_set_bittiming callback on devices with fixed bit rates, extend the check in can_changelink() accordingly. Link: https://lore.kernel.org/all/20220611144248.3924903-1-mkl@pengutronix.de Fixes: 431af779 ("can: dev: add CAN interface API for fixed bitrates") Reported-by:
-
Marc Kleine-Budde authored
This patch fixes the typo prescalar -> prescaler. Link: https://lore.kernel.org/all/20220610112037.3857192-1-mkl@pengutronix.deReviewed-by:
Chandrasekar Ramakrishnan <rcsekar@samsung.com> Signed-off-by:
-
Marc Kleine-Budde authored
This patch fixes the typo prescalar -> prescaler. Link: https://lore.kernel.org/all/20220609111424.3819039-1-mkl@pengutronix.deReported-by:
-
Srinivas Neeli authored
This patch adds Transmitter Delay Compensation (TDC) feature support. In the case of higher measured loop delay with higher bit rates, bit stuff errors are observed. Enabling the TDC feature in CAN-FD controllers will compensate for the measured loop delay in the receive path. Link: https://lore.kernel.org/all/20220609103157.1425730-1-srinivas.neeli@xilinx.comSigned-off-by:
Srinivas Neeli <srinivas.neeli@xilinx.com> Reviewed-by:
-
Yinjun Zhang authored
Previously the traffic class field is ignored while firmware has already supported to pedit flowinfo fields, including traffic class and flow label, now add it back. Signed-off-by:
Yinjun Zhang <yinjun.zhang@corigine.com> Link: https://lore.kernel.org/r/20220609080136.151830-1-simon.horman@corigine.comSigned-off-by:
-
Bin Chen authored
The commit a14857c2 ("rtnetlink: verify rate parameters for calls to ndo_set_vf_rate") has been merged to master, so we can to remove the now-duplicate checks in drivers. Signed-off-by:
Bin Chen <bin.chen@corigine.com> Signed-off-by:
Baowen Zheng <baowen.zheng@corigine.com> Signed-off-by:
Simon Horman <simon.horman@corigine.com> Link: https://lore.kernel.org/r/20220609084717.155154-1-simon.horman@corigine.comSigned-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queueJakub Kicinski authored
Tony Nguyen says: ==================== 10GbE Intel Wired LAN Driver Updates 2022-06-09 Maximilian Heyne adds reporting of VF statistics on ixgbe via iproute2 interface. Kai-Heng Feng removes duplicate defines from igb. Jiaqing Zhao fixes typos in e1000, ixgb, and ixgbe drivers. Julia Lawall fixes typos for fm10k, ixgbe, and ice drivers. * '10GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue: drivers/net/ethernet/intel: fix typos in comments ixgbe: Fix typos in comments ixgb: Fix typos in comments e1000: Fix typos in comments igb: Remove duplicate defines drivers, ixgbe: export vf statistics ==================== Link: https://lore.kernel.org/r/20220609171257.2727150-1-anthony.l.nguyen@intel.comSigned-off-by:
-
- 10 Jun, 2022 14 commits
-
-
Jakub Kicinski authored
Eric Dumazet says: ==================== net: reduce tcp_memory_allocated inflation Hosts with a lot of sockets tend to hit so called TCP memory pressure, leading to very bad TCP performance and/or OOM. The problem is that some TCP sockets can hold up to 2MB of 'forward allocations' in their per-socket cache (sk->sk_forward_alloc), and there is no mechanism to make them relinquish their share under mem pressure. Only under some potentially rare events their share is reclaimed, one socket at a time. In this series, I implemented a per-cpu cache instead of a per-socket one. Each CPU has a +1/-1 MB (256 pages on x86) forward alloc cache, in order to not dirty tcp_memory_allocated shared cache line too often. We keep sk->sk_forward_alloc values as small as possible, to meet memcg page granularity constraint. Note that memcg already has a per-cpu cache, although MEMCG_CHARGE_BATCH is defined to 32 pages, which seems a bit small. Note that while this cover letter mentions TCP, this work is generic and supports TCP, UDP, DECNET, SCTP. ==================== Link: https://lore.kernel.org/r/20220609063412.2205738-1-eric.dumazet@gmail.comSigned-off-by:
-
Eric Dumazet authored
These two helpers are only used from core networking. Signed-off-by:
Eric Dumazet <edumazet@google.com> Reviewed-by:
Shakeel Butt <shakeelb@google.com> Acked-by:
Soheil Hassas Yeganeh <soheil@google.com> Signed-off-by:
-
Eric Dumazet authored
Currently, tcp_memory_allocated can hit tcp_mem[] limits quite fast. Each TCP socket can forward allocate up to 2 MB of memory, even after flow became less active. 10,000 sockets can have reserved 20 GB of memory, and we have no shrinker in place to reclaim that. Instead of trying to reclaim the extra allocations in some places, just keep sk->sk_forward_alloc values as small as possible. This should not impact performance too much now we have per-cpu reserves: Changes to tcp_memory_allocated should not be too frequent. For sockets not using SO_RESERVE_MEM: - idle sockets (no packets in tx/rx queues) have zero forward alloc. - non idle sockets have a forward alloc smaller than one page. Note: - Removal of SK_RECLAIM_CHUNK and SK_RECLAIM_THRESHOLD is left to MPTCP maintainers as a follow up. Signed-off-by:
-
Eric Dumazet authored
If sk->sk_forward_alloc is 150000, and we need to schedule 150001 bytes, we want to allocate 1 byte more (rounded up to one page), instead of 150001 :/ Fixes: 1da177e4 ("Linux-2.6.12-rc2") Signed-off-by:
-
Eric Dumazet authored
We plan keeping sk->sk_forward_alloc as small as possible in future patches. This means we are going to call sk_memory_allocated_add() and sk_memory_allocated_sub() more often. Implement a per-cpu cache of +1/-1 MB, to reduce number of changes to sk->sk_prot->memory_allocated, which would otherwise be cause of false sharing. Signed-off-by:
-
Eric Dumazet authored
Each protocol having a ->memory_allocated pointer gets a corresponding per-cpu reserve, that following patches will use. Instead of having reserved bytes per socket, we want to have per-cpu reserves. Signed-off-by:
-
Eric Dumazet authored
Due to memcg interface, SK_MEM_QUANTUM is effectively PAGE_SIZE. This might change in the future, but it seems better to avoid the confusion. Signed-off-by:
-
Eric Dumazet authored
This reverts commit bd68a2a8. This change broke memcg on arches with PAGE_SIZE != 4096 Later, commit 2bb2f5fb ("net: add new socket option SO_RESERVE_MEM") also assumed PAGE_SIZE==SK_MEM_QUANTUM Following patches in the series will greatly reduce the over allocations problem. Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski authored
No conflicts. Signed-off-by: -
git://git.kernel.org/pub/scm/linux/kernel/git/robh/linuxLinus Torvalds authored
Pull more devicetree fixes from Rob Herring: - More DT meta-schema check fixes from new bindings in merge window - Fix stale DT binding references from Mauro - Update various binding maintainers - Fix in arm,malidp properties to match reality - Add deprecated 'atheros' vendor prefix * tag 'devicetree-fixes-for-5.19-2' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux: dt-bindings: display: arm,malidp: remove bogus RQOS property dt-bindings: pinctrl: ralink: Fix 'enum' lists with duplicate entries dt-bindings: Drop more redundant 'maxItems/minItems' in if/then schemas dt-bindings: nvme: apple,nvme-ans: Drop 'maxItems' from 'apple,sart' MAINTAINERS: rectify entries for ARM DRM DRIVERS after dt conversion MAINTAINERS: update snps,axs10x-reset.yaml reference MAINTAINERS: update dongwoon,dw9807-vcm.yaml reference MAINTAINERS: update cortina,gemini-ethernet.yaml reference dt-bindings: mfd: rk808: update rockchip,rk808.yaml reference dt-bindings: reset: update st,stih407-powerdown.yaml references dt-bindings: arm: update vexpress-config.yaml references dt-bindings: interrupt-controller: update brcm,l2-intc.yaml reference dt-bindings: mfd: bd9571mwv: update rohm,bd9571mwv.yaml reference dt-bindings: update Luca Ceresoli's e-mail address dt-bindings: msm: update maintainers list with proper id dt-bindings: vendor-prefixes: document deprecated Atheros dt-bindings: Update QCOM USB subsystem maintainer information
-
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pmLinus Torvalds authored
Pull power management fixes from Rafael Wysocki: "These fix an intel_idle issue introduced during the 5.16 development cycle and two recent regressions in the system reboot/poweroff code. Specifics: - Fix CPUIDLE_FLAG_IRQ_ENABLE handling in intel_idle (Peter Zijlstra) - Allow all platforms to use the global poweroff handler and make non-syscall poweroff code paths work again (Dmitry Osipenko)" * tag 'pm-5.19-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: cpuidle,intel_idle: Fix CPUIDLE_FLAG_IRQ_ENABLE kernel/reboot: Fix powering off using a non-syscall code paths kernel/reboot: Use static handler for register_platform_power_off() -
David Howells authored
There's a rule in certs/Makefile for which the command begins with eight spaces. This results in: ../certs/Makefile:21: FORCE prerequisite is missing ../certs/Makefile:21: *** missing separator. Stop. Fix this by turning the spaces into a tab. Fixes: addf4663 ("certs: Check that builtin blacklist hashes are valid") Signed-off-by:David Howells <dhowells@redhat.com> Reviewed-by:
Jarkko Sakkinen <jarkko@kernel.org> Reviewed-by:
Mickaël Salaün <mic@linux.microsoft.com> cc: keyrings@vger.kernel.org Link: https://lore.kernel.org/r/486b1b80-9932-aab6-138d-434c541c934a@digikod.net/ # v1 Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Andre Przywara authored
As Liviu pointed out, the arm,malidp-arqos-high-level property mentioned in the original .txt binding was a mistake, and arm,malidp-arqos-value needs to take its place. The binding commit ce6eb025 ("dt/bindings: display: Add optional property node define for Mali DP500") mentions the right name in the commit message, but has the wrong name in the diff. Commit d298e6a2 ("drm/arm/mali-dp: Add display QoS interface configuration for Mali DP500") uses the property in the driver, but uses the shorter name. Remove the wrong property from the binding, and use the proper name in the example. The actual property was already documented properly. Fixes: 2c8b082a ("dt-bindings: display: convert Arm Mali-DP to DT schema") Link: https://lore.kernel.org/linux-arm-kernel/YnumGEilUblhBx8E@e110455-lin.cambridge.arm.com/Signed-off-by:
Andre Przywara <andre.przywara@arm.com> Reported-by:
Liviu Dudau <liviu.dudau@arm.com> Reviewed-by:
-
Rafael J. Wysocki authored
Merge fixes for regressions introduced by the recent rework of the system reboot/poweroff code. * pm-sysoff: kernel/reboot: Fix powering off using a non-syscall code paths kernel/reboot: Use static handler for register_platform_power_off()
-
