summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2023-02-06spi: spidev: Fix double unlock in spidev_sync()Dan Carpenter
This unlocks twice due to a merge issue. Fixes: 35bba23e6732 ("Merge remote-tracking branch 'spi/for-6.2' into spi-6.2") Signed-off-by: Dan Carpenter <error27@gmail.com> Link: https://lore.kernel.org/r/Y+ETCk7XKfAy8yWQ@kili Signed-off-by: Mark Brown <broonie@kernel.org>
2023-02-06spi: Merge fixesMark Brown
The automated merge for the spidev locking fixes is going wrong and merging the unlock twice.
2023-02-06vduse: Remove include of rwlock.hSebastian Andrzej Siewior
rwlock.h should not be included directly. Instead linux/splinlock.h should be included. Including it directly will break the RT build. Remove the rwlock.h include. Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Michael S. Tsirkin <mst@redhat.com>
2023-02-06watchdog: diag288_wdt: unify lpar and zvm diag288 helpersAlexander Egorenkov
Change naming of the internal diag288 helper functions to improve overall readability and reduce confusion: * Rename __diag288() to diag288(). * Get rid of the misnamed helper __diag288_lpar() that was used not only on LPARs but also zVM and KVM systems. * Rename __diag288_vm() to diag288_str(). Reviewed-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/20230203073958.1585738-6-egorenar@linux.ibm.com Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2023-02-06watchdog: diag288_wdt: de-duplicate diag_stat_inc() callsAlexander Egorenkov
Call diag_stat_inc() from __diag288() to reduce code duplication. Reviewed-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/20230203073958.1585738-5-egorenar@linux.ibm.com Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2023-02-06watchdog: diag288_wdt: unify command buffer handling for diag288 zvmAlexander Egorenkov
Simplify and de-duplicate code by introducing a common single command buffer allocated once at initialization. Moreover, simplify the interface of __diag288_vm() by accepting ASCII strings as the command parameter and converting it to the EBCDIC format within the function itself. Reviewed-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/20230203073958.1585738-4-egorenar@linux.ibm.com Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2023-02-06watchdog: diag288_wdt: remove power managementAlexander Egorenkov
Remove power management because s390 no longer supports hibernation since commit 394216275c7d ("s390: remove broken hibernate / power management support"). Reviewed-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/20230203073958.1585738-3-egorenar@linux.ibm.com Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2023-02-06watchdog: diag288_wdt: get rid of register asmAlexander Egorenkov
Using register asm statements has been proven to be very error prone, especially when using code instrumentation where gcc may add function calls, which clobbers register contents in an unexpected way. Therefore, get rid of register asm statements in watchdog code, and make sure this bug class cannot happen. Moreover, remove the register r1 from the clobber list because this register is not changed by DIAG 288. Reviewed-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/20230203073958.1585738-2-egorenar@linux.ibm.com Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2023-02-06Merge branch 'fixes' into featuresHeiko Carstens
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2023-02-06HID: use standard debug APIsThomas Weißschuh
The custom "debug" module parameter is fairly inflexible. It can only manage debugging for all calls dbg_hid() at the same time. Furthermore it creates a mismatch between calls to hid_dbg() which can be managed by CONFIG_DYNAMIC_DEBUG and dbg_hid() which is managed by the module parameter. Furthermore the change to pr_debug() allows the debugging statements to be completely compiled-out if desired. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Tested-by: Bastien Nocera <hadess@hadess.net> Link: https://lore.kernel.org/r/20221223-hid-dbg-v1-1-5dcf8794f7f9@weissschuh.net Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
2023-02-06staging: greybus: hid: Constify lowlevel HID driverThomas Weißschuh
Since commit 52d225346904 ("HID: Make lowlevel driver structs const") the lowlevel HID drivers are only exposed as const. Take advantage of this to constify the underlying structure, too. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20230130-hid-const-ll-driver-v1-9-3fc282b3b1d0@weissschuh.net Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
2023-02-06platform/x86: asus-tf103c-dock: Constify toprow keymapThomas Weißschuh
This structure is never modified, make it const. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20230130-hid-const-ll-driver-v1-8-3fc282b3b1d0@weissschuh.net Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
2023-02-06platform/x86: asus-tf103c-dock: Constify lowlevel HID driverThomas Weißschuh
Since commit 52d225346904 ("HID: Make lowlevel driver structs const") the lowlevel HID drivers are only exposed as const. Take advantage of this to constify the underlying structure, too. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20230130-hid-const-ll-driver-v1-7-3fc282b3b1d0@weissschuh.net Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
2023-02-06HID: surface-hid: Constify lowlevel HID driverThomas Weißschuh
Since commit 52d225346904 ("HID: Make lowlevel driver structs const") the lowlevel HID drivers are only exposed as const. Take advantage of this to constify the underlying structure, too. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Reviewed-by: Maximilian Luz <luzmaximilian@gmail.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20230130-hid-const-ll-driver-v1-6-3fc282b3b1d0@weissschuh.net Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
2023-02-06HID: intel-ish-hid: Constify lowlevel HID driverThomas Weißschuh
Since commit 52d225346904 ("HID: Make lowlevel driver structs const") the lowlevel HID drivers are only exposed as const. Take advantage of this to constify the underlying structure, too. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20230130-hid-const-ll-driver-v1-5-3fc282b3b1d0@weissschuh.net Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
2023-02-06HID: steam: Constify lowlevel HID driverThomas Weißschuh
Since commit 52d225346904 ("HID: Make lowlevel driver structs const") the lowlevel HID drivers are only exposed as const. Take advantage of this to constify the underlying structure, too. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20230130-hid-const-ll-driver-v1-4-3fc282b3b1d0@weissschuh.net Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
2023-02-06HID: logitech-dj: Constify lowlevel HID driverThomas Weißschuh
Since commit 52d225346904 ("HID: Make lowlevel driver structs const") the lowlevel HID drivers are only exposed as const. Take advantage of this to constify the underlying structure, too. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20230130-hid-const-ll-driver-v1-3-3fc282b3b1d0@weissschuh.net Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
2023-02-06HID: hyperv: Constify lowlevel HID driverThomas Weißschuh
Since commit 52d225346904 ("HID: Make lowlevel driver structs const") the lowlevel HID drivers are only exposed as const. Take advantage of this to constify the underlying structure, too. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Acked-by: Wei Liu <wei.liu@kernel.org> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20230130-hid-const-ll-driver-v1-2-3fc282b3b1d0@weissschuh.net Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
2023-02-06HID: amd_sfh: Constify lowlevel HID driverThomas Weißschuh
Since commit 52d225346904 ("HID: Make lowlevel driver structs const") the lowlevel HID drivers are only exposed as const. Take advantage of this to constify the underlying structure, too. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20230130-hid-const-ll-driver-v1-1-3fc282b3b1d0@weissschuh.net Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
2023-02-06RDMA/cxgb4: Fix potential null-ptr-deref in pass_establish()Nikita Zhandarovich
If get_ep_from_tid() fails to lookup non-NULL value for ep, ep is dereferenced later regardless of whether it is empty. This patch adds a simple sanity check to fix the issue. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 944661dd97f4 ("RDMA/iw_cxgb4: atomically lookup ep and get a reference") Signed-off-by: Nikita Zhandarovich <n.zhandarovich@fintech.ru> Link: https://lore.kernel.org/r/20230202184850.29882-1-n.zhandarovich@fintech.ru Signed-off-by: Leon Romanovsky <leon@kernel.org>
2023-02-06platform/x86: int3472/discrete: Drop unnecessary obj->type == string checkHans de Goede
acpi_evaluate_dsm_typed() already verifies the type is the requested type, so this error check is a no-op, drop it. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20230204110223.54625-1-hdegoede@redhat.com
2023-02-06RDMA/mlx5: Remove impossible check of mkey cache cleanup failureLeon Romanovsky
mlx5_mkey_cache_cleanup() can't fail and can be changed to be void. Link: https://lore.kernel.org/r/1acd9528995d083114e7dec2a2afc59436406583.1675328463.git.leon@kernel.org Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
2023-02-06RDMA/mlx5: Fix MR cache debugfs error in IB representors modeLeon Romanovsky
Block MR cache debugfs creation for IB representor flow as MR cache shouldn't be used at all in that mode. As part of this change, add missing debugfs cleanup in error path too. This change fixes the following debugfs errors: bond0: (slave enp8s0f1): Enslaving as a backup interface with an up link mlx5_core 0000:08:00.0: lag map: port 1:1 port 2:1 mlx5_core 0000:08:00.0: shared_fdb:1 mode:queue_affinity mlx5_core 0000:08:00.0: Operation mode is single FDB debugfs: Directory '2' with parent '/' already present! ... debugfs: Directory '22' with parent '/' already present! Fixes: 73d09b2fe833 ("RDMA/mlx5: Introduce mlx5r_cache_rb_key") Signed-off-by: Michael Guralnik <michaelgur@nvidia.com> Link: https://lore.kernel.org/r/482a78c54acbcfa1742a0e06a452546428900ffa.1675328463.git.leon@kernel.org Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
2023-02-06platform/x86/intel/vsec: Add support for Meteor LakeGayatri Kammela
Add Meteor Lake PMT telemetry support. Signed-off-by: Gayatri Kammela <gayatri.kammela@linux.intel.com> Signed-off-by: David E. Box <david.e.box@linux.intel.com> Link: https://lore.kernel.org/r/20230203011716.1078003-1-david.e.box@linux.intel.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-02-06Merge branch 'icc-sa8775p' into icc-nextGeorgi Djakov
* icc-sa8775p dt-bindings: interconnect: qcom: document the interconnects for sa8775p interconnect: qcom: add a driver for sa8775p dt-bindings: interconnect: qcom,sa8775p-rpmh: fix a typo Link: https://lore.kernel.org/r/20230118140825.242544-2-brgl@bgdev.pl Signed-off-by: Georgi Djakov <djakov@kernel.org>
2023-02-06Merge branch 'icc-sdm670' into icc-nextGeorgi Djakov
* icc-sdm670 dt-bindings: interconnect: add sdm670 interconnects interconnect: qcom: add sdm670 interconnects Link: https://lore.kernel.org/r/20230111005155.50452-1-mailingradian@gmail.com Signed-off-by: Georgi Djakov <djakov@kernel.org>
2023-02-06Merge branch 'icc-ip0-migration' into icc-nextGeorgi Djakov
Commits 2f3724930eb4 ("interconnect: qcom: sc7180: Drop IP0 interconnects") and 2fb251c26560 ("interconnect: qcom: sdx55: Drop IP0 interconnects") removed IP0 interconnects (and ipa-virt devices support) in favour of the RPMH clocks. Follow this example for other platforms defining IP0 RPMH resource. While we are at it, remove several leftover from the mentioned patches. * icc-ip0-migration: interconnect: qcom: sdx55: drop IP0 remnants interconnect: qcom: sc7180: drop IP0 remnants interconnect: move ignore_list out of of_count_icc_providers() interconnect: qcom: sm8150: Drop IP0 interconnects interconnect: qcom: sm8250: Drop IP0 interconnects interconnect: qcom: sc8180x: Drop IP0 interconnects interconnect: qcom: sc8280xp: Drop IP0 interconnects dt-bindings: interconnect: qcom: Remove ipa-virt compatibles dt-bindings: interconnect: qcom: drop IPA_CORE related defines Link: https://lore.kernel.org/r/20230109002935.244320-1-dmitry.baryshkov@linaro.org Signed-off-by: Georgi Djakov <djakov@kernel.org>
2023-02-06drm/i915: Initialize the obj flags for shmem objectsAravind Iddamsetty
Obj flags for shmem objects is not being set correctly. Fixes in setting BO_ALLOC_USER flag which applies to shmem objs as well. v2: Add fixes tag (Tvrtko, Matt A) Fixes: 13d29c823738 ("drm/i915/ehl: unconditionally flush the pages on acquire") Cc: <stable@vger.kernel.org> # v5.15+ Cc: Matthew Auld <matthew.auld@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Aravind Iddamsetty <aravind.iddamsetty@intel.com> Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> [tursulin: Grouped all tags together.] Link: https://patchwork.freedesktop.org/patch/msgid/20230203135205.4051149-1-aravind.iddamsetty@intel.com (cherry picked from commit bca0d1d3ceeb07be45a51c0fa4d57a0ce31b6aed) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-02-06drm/i915: Move fd_install after last use of fenceRob Clark
Because eb_composite_fence_create() drops the fence_array reference after creation of the sync_file, only the sync_file holds a ref to the fence. But fd_install() makes that reference visable to userspace, so it must be the last thing we do with the fence. Signed-off-by: Rob Clark <robdclark@chromium.org> Fixes: 00dae4d3d35d ("drm/i915: Implement SINGLE_TIMELINE with a syncobj (v4)") Cc: <stable@vger.kernel.org> # v5.15+ [tursulin: Added stable tag.] Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230203164937.4035503-1-robdclark@gmail.com (cherry picked from commit 960dafa30455450d318756a9896a02727f2639e0) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-02-06drm/i915/fbdev: Implement fb_dirty for intel custom fb helperJouni Högander
After disconnecting damage worker from update logic it's left to fbdev emulation implementation to have fb_dirty function. Currently intel fbdev doesn't have it. This is causing problems to features (PSR, FBC, DRRS) relying on dirty callback. Implement simple fb_dirty callback to deliver notifications about updates in fb console. v4: Add proper Fixes tag and modify commit message v3: Check damage clip v2: Improved commit message and added Fixes tag Fixes: f231af498c29 ("drm/fb-helper: Disconnect damage worker from update logic") Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230123074437.475103-1-jouni.hogander@intel.com (cherry picked from commit 1af546c2cec6e28b6bbe01a4ad0c38e96e54fcb4) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-02-06drm/i915: Don't do the WM0->WM1 copy w/a if WM1 is already enabledVille Syrjälä
Due to a workaround we have to make sure the WM1 watermarks block/lines values are sensible even when WM1 is disabled. To that end we copy those values from WM0. However since we now keep each wm level enabled on a per-plane basis it doesn't seem necessary to do that copy when we already have an enabled WM1 on the current plane. That is, we might be in a situation where another plane can only do WM0 (and thus needs the copy) but the current plane's WM1 is still perfectly valid (ie. fits into the current DDB allocation). Skipping the copy could avoid reprogramming the plane's registers needlessly in some cases. Fixes: a301cb0fca2d ("drm/i915: Keep plane watermarks enabled more aggressively") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230131002127.29305-1-ville.syrjala@linux.intel.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> (cherry picked from commit c580c2d27ac8754cc6f01da1d715b7272f5f9cbb) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-02-06can: bittiming: can_validate_bitrate(): report error via netlinkMarc Kleine-Budde
Report an error to user space via netlink if the requested bit rate is not supported by the device. Link: https://lore.kernel.org/all/20230202110854.2318594-18-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-02-06can: bittiming: can_calc_bittiming(): convert from netdev_err() to ↵Marc Kleine-Budde
NL_SET_ERR_MSG_FMT() Replace the netdev_err() by NL_SET_ERR_MSG_FMT() to better inform the user about the problem. While there, use %u to print unsigned values and improve error message a bit. In case of an error, return -EINVAL instead of -EDOM, this corresponds better to the actual meaning of the error value. Link: https://lore.kernel.org/all/20230202110854.2318594-17-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-02-06can: bittiming: can_calc_bittiming(): clean up SJW handlingMarc Kleine-Budde
In the current code, if the user configures a bitrate, a default SJW value of 1 is used. If the user configures both a bitrate and a SJW value, can_calc_bittiming() silently limits the SJW value to SJW max and TSEG2. We came to the conclusion that if the user provided an invalid SJW value, it's best to bail out and inform the user [1]. [1] https://lore.kernel.org/all/CAMZ6RqKqhmTgUZiwe5uqUjBDnhhC2iOjZ791+Y845btJYwVDKg@mail.gmail.com Further the ISO 11898-1:2015 standard mandates that "SJW shall be less than or equal to the minimum of these two items: Phase_Seg1 and Phase_Seg2." [2] The current code is missing that check. [2] https://lore.kernel.org/all/BL3PR11MB64844E3FC13C55433CDD0B3DFB449@BL3PR11MB6484.namprd11.prod.outlook.com The previous patches introduced 1) can_sjw_set_default() - sets a default value for SJW if unset 2) can_sjw_check() - implements a SJW check against SJW max, Phase Seg1 and Phase Seg2. In the error case this function reports the error to user space via netlink. Replace both the open-coded SJW default setting and the open-coded and insufficient checks of SJW with the helper functions can_sjw_set_default() and can_sjw_check(). Link: https://lore.kernel.org/all/20230202110854.2318594-16-mkl@pengutronix.de Link: https://lore.kernel.org/all/CAMZ6RqKqhmTgUZiwe5uqUjBDnhhC2iOjZ791+Y845btJYwVDKg@mail.gmail.com Link: https://lore.kernel.org/all/BL3PR11MB64844E3FC13C55433CDD0B3DFB449@BL3PR11MB6484.namprd11.prod.outlook.com Suggested-by: Thomas Kopp <Thomas.Kopp@microchip.com> Suggested-by: Vincent Mailhol <vincent.mailhol@gmail.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-02-06can: bittiming: can_sjw_set_default(): use Phase Seg2 / 2 as default for SJWMarc Kleine-Budde
"The (Re-)Synchronization Jump Width (SJW) defines how far a resynchronization may move the Sample Point inside the limits defined by the Phase Buffer Segments to compensate for edge phase errors." [1] In other words, this means that the SJW parameter controls the tolerance of the CAN controller to frequency errors compared to other CAN controllers. If the user space does not provide an SJW parameter, the kernel chooses a default value of 1. This has proven to be a good default value for classic CAN controllers, but no longer for modern CAN-FD controllers. In the past there were CAN controllers like the sja1000 with a rather limited range of bit timing parameters. For the standard bit rates this results in the following bit timing parameters: | Bit timing parameters for sja1000 with 8.000000 MHz ref clock | _----+--------------=> tseg1: 1 … 16 | / / _---------=> tseg2: 1 … 8 | | | / _-----=> sjw: 1 … 4 | | | | / _-=> brp: 1 … 64 (inc: 1) | | | | | / | nominal | | | | | real Bitrt nom real SampP | Bitrate TQ[ns] PrS PhS1 PhS2 SJW BRP Bitrate Error SampP SampP Error BTR0 BTR1 | 1000000 125 2 3 2 1 1 1000000 0.0% 75.0% 75.0% 0.0% 0x00 0x14 | 800000 125 3 4 2 1 1 800000 0.0% 80.0% 80.0% 0.0% 0x00 0x16 | 666666 125 4 4 3 1 1 666666 0.0% 80.0% 75.0% 6.2% 0x00 0x27 | 500000 125 6 7 2 1 1 500000 0.0% 87.5% 87.5% 0.0% 0x00 0x1c | 250000 250 6 7 2 1 2 250000 0.0% 87.5% 87.5% 0.0% 0x01 0x1c | 125000 500 6 7 2 1 4 125000 0.0% 87.5% 87.5% 0.0% 0x03 0x1c | 100000 625 6 7 2 1 5 100000 0.0% 87.5% 87.5% 0.0% 0x04 0x1c | 83333 750 6 7 2 1 6 83333 0.0% 87.5% 87.5% 0.0% 0x05 0x1c | 50000 1250 6 7 2 1 10 50000 0.0% 87.5% 87.5% 0.0% 0x09 0x1c | 33333 1875 6 7 2 1 15 33333 0.0% 87.5% 87.5% 0.0% 0x0e 0x1c | 20000 3125 6 7 2 1 25 20000 0.0% 87.5% 87.5% 0.0% 0x18 0x1c | 10000 6250 6 7 2 1 50 10000 0.0% 87.5% 87.5% 0.0% 0x31 0x1c The attentive reader will notice that the SJW is 1 in most cases, while the Seg2 phase is 2. Both values are given in TQ units, which in turn is a duration in nanoseconds. For example the 500 kbit/s configuration: | nominal real Bitrt nom real SampP | Bitrate TQ[ns] PrS PhS1 PhS2 SJW BRP Bitrate Error SampP SampP Error BTR0 BTR1 | 500000 125 6 7 2 1 1 500000 0.0% 87.5% 87.5% 0.0% 0x00 0x1c the TQ is 125ns, the Phase Seg2 is "2" (== 250ns), the SJW is "1" (== 125 ns). Looking at a more modern CAN controller like a mcp2518fd, it has wider bit timing registers. | Bit timing parameters for mcp251xfd with 40.000000 MHz ref clock | _----+--------------=> tseg1: 2 … 256 | / / _---------=> tseg2: 1 … 128 | | | / _-----=> sjw: 1 … 128 | | | | / _-=> brp: 1 … 256 (inc: 1) | | | | | / | nominal | | | | | real Bitrt nom real SampP | Bitrate TQ[ns] PrS PhS1 PhS2 SJW BRP Bitrate Error SampP SampP Error NBTCFG | 500000 25 34 35 10 1 1 500000 0.0% 87.5% 87.5% 0.0% 0x00440900 The TQ is 25ns, the Phase Seg 2 is "10" (== 250ns), the SJW is "1" (== 25ns). Since the kernel chooses a default SJW of 1 regardless of the TQ, this leads to a much smaller SJW and thus much smaller tolerances to frequency errors. To maintain the same oscillator tolerances on controllers with wide bit timing registers, select a default SJW value of Phase Seg2 / 2 unless Phase Seg 1 is less. This results in the following bit timing parameters: | Bit timing parameters for mcp251xfd with 40.000000 MHz ref clock | _----+--------------=> tseg1: 2 … 256 | / / _---------=> tseg2: 1 … 128 | | | / _-----=> sjw: 1 … 128 | | | | / _-=> brp: 1 … 256 (inc: 1) | | | | | / | nominal | | | | | real Bitrt nom real SampP | Bitrate TQ[ns] PrS PhS1 PhS2 SJW BRP Bitrate Error SampP SampP Error NBTCFG | 500000 25 34 35 10 5 1 500000 0.0% 87.5% 87.5% 0.0% 0x00440904 The TQ is 25ns, the Phase Seg 2 is "10" (== 250ns), the SJW is "5" (== 125ns). Which is the same as on the sja1000 controller. [1] http://web.archive.org/http://www.oertel-halle.de/files/cia99paper.pdf Link: https://lore.kernel.org/all/20230202110854.2318594-15-mkl@pengutronix.de Cc: Mark Bath <mark@baggywrinkle.co.uk> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-02-06can: bittiming: can_sjw_check(): check that SJW is not longer than either ↵Marc Kleine-Budde
Phase Buffer Segment According to "The Configuration of the CAN Bit Timing" [1] the SJW "may not be longer than either Phase Buffer Segment". Check SJW against length of both Phase buffers. In case the SJW is greater, report an error via netlink to user space and bail out. [1] http://web.archive.org/http://www.oertel-halle.de/files/cia99paper.pdf Link: https://lore.kernel.org/all/20230202110854.2318594-14-mkl@pengutronix.de Suggested-by: Vincent Mailhol <vincent.mailhol@gmail.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-02-06can: bittiming: can_sjw_check(): report error via netlink and harmonize ↵Marc Kleine-Budde
error value If the user space has supplied an invalid SJW value (greater than the maximum SJW value), report -EINVAL instead of -ERANGE, this better matches the actual meaning of the error value. Additionally report an error message via netlink to the user space. Link: https://lore.kernel.org/all/20230202110854.2318594-13-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-02-06can: bittiming: can_fixup_bittiming(): report error via netlink and ↵Marc Kleine-Budde
harmonize error value Check each bit timing parameter first individually against their limits and report a meaningful error message via netlink to the user space. In case of an error, return -EINVAL instead of -ERANGE, this corresponds better to the actual meaning of the error value. Link: https://lore.kernel.org/all/20230202110854.2318594-12-mkl@pengutronix.de Suggested-by: Vincent Mailhol <vincent.mailhol@gmail.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-02-06can: bittiming: factor out can_sjw_set_default() and can_sjw_check()Marc Kleine-Budde
Factor out the functionality of assigning a SJW default value into can_sjw_set_default() and the checking the SJW limits into can_sjw_check(). This functions will be improved and called from a different function in the following patches. Link: https://lore.kernel.org/all/20230202110854.2318594-11-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-02-06can: bittiming: can_changelink() pass extack down callstackMarc Kleine-Budde
This is a preparation patch. In order to pass warning/error messages during netlink calls back to user space, pass the extack struct down the callstack of can_changelink(), the actual error messages will be added in the following ptaches. Link: https://lore.kernel.org/all/20230202110854.2318594-10-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-02-06can: netlink: can_changelink(): convert from netdev_err() to ↵Marc Kleine-Budde
NL_SET_ERR_MSG_FMT() Since commit 51c352bdbcd2 ("netlink: add support for formatted extack messages") formatted extack messages are supported to inform the user space or warnings/errors during netlink calls. Replace the netdev_err() by NL_SET_ERR_MSG_FMT() to better inform the user about the problem. While there, use %u to print unsigned values and improve error message a bit. Link: https://lore.kernel.org/all/20230202110854.2318594-9-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-02-06can: netlink: can_validate(): validate sample point for CAN and CAN-FDMarc Kleine-Budde
The sample point is a value in tenths of a percent. Meaningful values are between 0 and 1000. Invalid values are rejected and an error message is returned to user space via netlink. Link: https://lore.kernel.org/all/20230202110854.2318594-8-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-02-06can: dev: register_candev(): bail out if both fixed bit rates and bit timing ↵Marc Kleine-Budde
constants are provided The CAN driver framework supports either fixed bit rates or bit timing constants. Bail out during driver registration if both are given. Link: https://lore.kernel.org/all/20230202110854.2318594-7-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-02-06can: dev: register_candev(): ensure that bittiming const are validMarc Kleine-Budde
Implement the function can_bittiming_const_valid() to check the validity of the specified bit timing constant. Call this function from register_candev() to check the bit timing constants during the registration of the CAN interface. Link: https://lore.kernel.org/all/20230202110854.2318594-6-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-02-06can: bittiming: can_get_bittiming(): use direct return and remove unneeded elseMarc Kleine-Budde
Clean up the code flow a bit, don't assign err variable but directly return. Remove the unneeded else, too. Link: https://lore.kernel.org/all/20230202110854.2318594-5-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-02-06can: bittiming: can_fixup_bittiming(): set effective tqMarc Kleine-Budde
The can_fixup_bittiming() function is used to validate the user-supplied low-level bit timing parameters and calculate the bitrate prescaler (brp) from the requested time quanta (tq) and the CAN clock of the controller. can_fixup_bittiming() selects the best matching integer bit rate prescaler, which may result in a different time quantum than the value specified by the user. Calculate the resulting time quantum and assign it so that the user sees the effective time quantum. Link: https://lore.kernel.org/all/20230202110854.2318594-4-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-02-06can: bittiming: can_fixup_bittiming(): use CAN_SYNC_SEG instead of 1Marc Kleine-Budde
Commit 1c47fa6b31c2 ("can: dev: add a helper function to calculate the duration of one bit") made the constant CAN_SYNC_SEG available in a header file. The magic number 1 in can_fixup_bittiming() represents the width of the sync segment, replace it by CAN_SYNC_SEG to make the code more readable. Link: https://lore.kernel.org/all/20230202110854.2318594-3-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-02-06can: bittiming(): replace open coded variants of can_bit_time()Marc Kleine-Budde
Commit 1c47fa6b31c2 ("can: dev: add a helper function to calculate the duration of one bit") added the helper function can_bit_time(). Replace open coded variants of can_bit_time() by the helper function. Link: https://lore.kernel.org/all/20230202110854.2318594-2-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-02-06platform/x86/intel/tpmi: ADD tpmi external interface for tpmi feature driversSrinivas Pandruvada
Add interface to get resources and platform data. This will avoid code duplication. These interfaces includes: - Get resource count - Get resource at an index Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://lore.kernel.org/r/20230202010738.2186174-7-srinivas.pandruvada@linux.intel.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-02-06platform/x86/intel/tpmi: Process CPU package mappingSrinivas Pandruvada
There is one Intel Out-of-Band (OOB) PCI device per CPU package. Since TPMI feature is exposed via OOB PCI device, there will be multiple TPMI device instances on a multi CPU package system. There are several PM features, which needs to associate APIC based CPU package ID information to a TPMI instance. For example if Intel Speed Select feature requires control of a CPU package, it needs to identify right TPMI device instance. There is one special TPMI ID (ID = 0x81) in the PFS. The MMIO region of this TPMI ID points to a mapping table: - PCI Bus ID - PCI Device ID - APIC based Package ID This mapping information can be used by any PM feature driver which requires mapping from a CPU package to a TPMI device instance. Unlike other TPMI features, device node is not created for this feature ID (0x81). Instead store the mapping information as platform data, which is part of the per PCI device TPMI instance (struct intel_tpmi_info). Later the TPMI feature drivers can get the mapping information using an interface "tpmi_get_platform_data()" Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://lore.kernel.org/r/20230202010738.2186174-6-srinivas.pandruvada@linux.intel.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
generated by cgit (git 2.34.1) at 2025-09-22 22:10:15 +0000