Here is the big set of char and misc and other tiny driver subsystem
updates for 5.16-rc1.
Loads of things in here, all of which have been in linux-next for a
while with no reported problems (except for one called out below.)
Included are:
- habanana labs driver updates, including dma_buf usage,
reviewed and acked by the dma_buf maintainers
- iio driver update (going through this tree not staging as they
really do not belong going through that tree anymore)
- counter driver updates
- hwmon driver updates that the counter drivers needed, acked by
the hwmon maintainer
- xillybus driver updates
- binder driver updates
- extcon driver updates
- dma_buf module namespaces added (will cause a build error in
arm64 for allmodconfig, but that change is on its way through
the drm tree)
- lkdtm driver updates
- pvpanic driver updates
- phy driver updates
- virt acrn and nitr_enclaves driver updates
- smaller char and misc driver updates
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
iG0EABECAC0WIQT0tgzFv3jCIUoxPcsxR9QN2y37KQUCYYPX2A8cZ3JlZ0Brcm9h
aC5jb20ACgkQMUfUDdst+ymUUgCbB4EKysgLuXYdjUalZDx+vvZO4k0AniS14O4k
F+2dVSZ5WX6wumUzCaA6
=bXQM
-----END PGP SIGNATURE-----
Merge tag 'char-misc-5.16-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc
Pull char/misc driver updates from Greg KH:
"Here is the big set of char and misc and other tiny driver subsystem
updates for 5.16-rc1.
Loads of things in here, all of which have been in linux-next for a
while with no reported problems (except for one called out below.)
Included are:
- habanana labs driver updates, including dma_buf usage, reviewed and
acked by the dma_buf maintainers
- iio driver update (going through this tree not staging as they
really do not belong going through that tree anymore)
- counter driver updates
- hwmon driver updates that the counter drivers needed, acked by the
hwmon maintainer
- xillybus driver updates
- binder driver updates
- extcon driver updates
- dma_buf module namespaces added (will cause a build error in arm64
for allmodconfig, but that change is on its way through the drm
tree)
- lkdtm driver updates
- pvpanic driver updates
- phy driver updates
- virt acrn and nitr_enclaves driver updates
- smaller char and misc driver updates"
* tag 'char-misc-5.16-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (386 commits)
comedi: dt9812: fix DMA buffers on stack
comedi: ni_usb6501: fix NULL-deref in command paths
arm64: errata: Enable TRBE workaround for write to out-of-range address
arm64: errata: Enable workaround for TRBE overwrite in FILL mode
coresight: trbe: Work around write to out of range
coresight: trbe: Make sure we have enough space
coresight: trbe: Add a helper to determine the minimum buffer size
coresight: trbe: Workaround TRBE errata overwrite in FILL mode
coresight: trbe: Add infrastructure for Errata handling
coresight: trbe: Allow driver to choose a different alignment
coresight: trbe: Decouple buffer base from the hardware base
coresight: trbe: Add a helper to pad a given buffer area
coresight: trbe: Add a helper to calculate the trace generated
coresight: trbe: Defer the probe on offline CPUs
coresight: trbe: Fix incorrect access of the sink specific data
coresight: etm4x: Add ETM PID for Kryo-5XX
coresight: trbe: Prohibit trace before disabling TRBE
coresight: trbe: End the AUX handle on truncation
coresight: trbe: Do not truncate buffer on IRQ
coresight: trbe: Fix handling of spurious interrupts
...
Here is the big set of USB and Thunderbolt driver updates for 5.16-rc1.
Nothing major in here, just lots of little cleanups and additions for
new hardware, all of which have been in linux-next for a while with no
reported problems.
Included in here are:
- tiny Thunderbolt driver updates
- USB typec driver updates
- USB serial driver updates
- USB gadget driver updates
- dwc2 and dwc3 controller driver updates
- tiny USB host driver updates
- minor USB driver fixes and updates
- USB dts updates for various platforms
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
iG0EABECAC0WIQT0tgzFv3jCIUoxPcsxR9QN2y37KQUCYYPaPA8cZ3JlZ0Brcm9h
aC5jb20ACgkQMUfUDdst+ylH3wCghhRCsLl5axOKdbkJO2ZUApR71DwAn2Vjwo2Y
Jgo6v3bVWWhL43YwCkf6
=UNgI
-----END PGP SIGNATURE-----
Merge tag 'usb-5.16-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
Pull USB / Thunderbolt updates from Greg KH:
"Here is the big set of USB and Thunderbolt driver updates for
5.16-rc1.
Nothing major in here, just lots of little cleanups and additions for
new hardware, all of which have been in linux-next for a while with no
reported problems.
Included in here are:
- tiny Thunderbolt driver updates
- USB typec driver updates
- USB serial driver updates
- USB gadget driver updates
- dwc2 and dwc3 controller driver updates
- tiny USB host driver updates
- minor USB driver fixes and updates
- USB dts updates for various platforms"
* tag 'usb-5.16-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (123 commits)
usb: gadget: Mark USB_FSL_QE broken on 64-bit
usb: gadget: f_mass_storage: Disable eps during disconnect
usb: gadget: udc: core: Revise comments for USB ep enable/disable
USB: serial: keyspan: fix memleak on probe errors
USB: serial: cp210x: use usb_control_msg_recv() and usb_control_msg_send()
USB: serial: ch314: use usb_control_msg_recv()
USB: iowarrior: fix control-message timeouts
Documentation: USB: fix example bulk-message timeout
usb: dwc2: stm32mp15: set otg_rev
usb: dwc2: add otg_rev and otg_caps information for gadget driver
dt-bindings: usb: dwc2: adopt otg properties defined in usb-drd.yaml
dt-bindings: usb: dwc2: Add reference to usb-drd.yaml
usb: gadget: uvc: implement dwPresentationTime and scrSourceClock
usb: gadget: uvc: use on returned header len in video_encode_isoc_sg
usb:gadget: f_uac1: fixed sync playback
Docs: usb: remove :c:func: for usb_register and usb_deregister
Docs: usb: update struct usb_driver
usb: gadget: configfs: change config attributes file operation
usb: gadget: configfs: add cfg_to_gadget_info() helper
usb: dwc3: Align DWC3_EP_* flag macros
...
Users on darp6 that do not have Open EC firmware have reported crashes
on boot. Correct the error handling for the input device to fix it.
Managed devices do not need to be explicitly unregistered or freed, as
this is handled by devres. Drop the call to input_free_device.
Fixes: 0de30fc684b3 ("platform/x86: system76_acpi: Replace Fn+F2 function for OLED models")
Signed-off-by: Tim Crawford <tcrawford@system76.com>
Link: https://lore.kernel.org/r/20211030154213.2515-1-tcrawford@system76.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Add support for new system type, which is a water-cooling flavor
of the VMOD001 system class, equipped with 48xSFP28 and 8xQSFP28
100G Ethernet ports.
System is recognized by "DMI_BOARD_NAME" and " DMI_PRODUCT_SKU"
matches, when these fields are set respectively to "VMOD001" and
"HI138".
Signed-off-by: Vadim Pasternak <vadimp@nvidia.com>
Reviewed-by: Oleksandr Shamray <oleksandrs@nvidia.com>
Link: https://lore.kernel.org/r/20211023094022.4193813-4-vadimp@nvidia.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Extend systems of class VMOD0010 equipped with CoffeeLake COMEx module
with BIOS related attributes to represent various BIOS statuses.
These attributes "bios_active_image", "bios_auth_fail",
"bios_upgrade_fail", "bios_safe_mode" has been already added to modular
system. This all of them are already documented.
- "bios_active_image" - location of current active BIOS image (0: Top,
1: Bottom. The reported value should correspond to value expected by
OS in case of BIOS safe mode is 0. This bit is related to Intel
top-swap feature of DualBios on the same flash.
- "bios_auth_fail": BIOS upgrade is failed because provided BIOS image
is not signed correctly.
- "bios_upgrade_fail" BIOS upgrade is failed by some reason not related
to authentication. For example, due to physical SPI flash problem.
- "bios_safe_mod": - 0 : if BIOS is booted from a supposed active image;
1 : BIOS safe mechanism was enforced by hardware (CPLD).
Signed-off-by: Vadim Pasternak <vadimp@nvidia.com>
Reviewed-by: Oleksandr Shamray <oleksandrs@nvidia.com>
Link: https://lore.kernel.org/r/20211023094022.4193813-3-vadimp@nvidia.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Add support for new system types "MQM97xx", which is based on Mellanox
Quantum-2 ASIC. It provides up to 64x400GB/s (IB) full bidirectional
bandwidth per port using PAM-4 modulation. The system support 32 OSFP
cages that can provide 64x400GB/s per port (two ports/cage). The system
fits standard 1U racks.
System is equipped with seven fan drawers and with per fan drawer LED
on backport panel and uses two-bytes for exposing CPLD Part Number
versions.
System is recognized by "DMI_BOARD_NAME" match, when this field is set
to "VMOD0010".
Signed-off-by: Vadim Pasternak <vadimp@nvidia.com>
Reviewed-by: Oleksandr Shamray <oleksandrs@nvidia.com>
Link: https://lore.kernel.org/r/20211023094022.4193813-2-vadimp@nvidia.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
An upcoming change to platform profiles will export `platform_profile_get`
as a symbol that can be used by other drivers. Avoid the collision.
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Link: https://lore.kernel.org/r/20211026190835.10697-3-mario.limonciello@amd.com
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
An upcoming change to platform profiles will export `platform_profile_get`
as a symbol that can be used by other drivers. Avoid the collision.
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Link: https://lore.kernel.org/r/20211026190835.10697-2-mario.limonciello@amd.com
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
This is already checked when calling rtc_read_alarm.
Suggested-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Link: https://lore.kernel.org/r/20211026171443.289-3-mario.limonciello@amd.com
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
For the majority of users this information will not be informative
as they've chosen to program the RTC before going to sleep.
Suggested-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Link: https://lore.kernel.org/r/20211026171443.289-2-mario.limonciello@amd.com
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Just hardcode the RTC to "rtc0" which is the default for
CONFIG_RTC_SYSTOHC_DEVICE and used by all standard x86 distros.
Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
Suggested-by: Hans de Goede <hdegoede@redhat.com>
Fixes: 59348401ebed ("platform/x86: amd-pmc: Add special handling for timer based S0i3 wakeup")
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Link: https://lore.kernel.org/r/20211026171443.289-1-mario.limonciello@amd.com
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
When CONFIG_INPUT is disabled, this driver now fails to link:
ld.lld: error: undefined symbol: devm_input_allocate_device
>>> referenced by system76_acpi.c
>>> platform/x86/system76_acpi.o:(system76_add) in archive drivers/built-in.a
ld.lld: error: undefined symbol: input_set_capability
>>> referenced by system76_acpi.c
>>> platform/x86/system76_acpi.o:(system76_add) in archive drivers/built-in.a
ld.lld: error: undefined symbol: devm_hwmon_device_register_with_info
>>> referenced by system76_acpi.c
>>> platform/x86/system76_acpi.o:(system76_add) in archive drivers/built-in.a
ld.lld: error: undefined symbol: battery_hook_unregister
>>> referenced by system76_acpi.c
>>> platform/x86/system76_acpi.o:(system76_remove) in archive drivers/built-in.a
Add Kconfig dependencies for each of these three.
Fixes: 0de30fc684b3 ("platform/x86: system76_acpi: Replace Fn+F2 function for OLED models")
Fixes: 95563d45b5da ("platform/x86: system76_acpi: Report temperature and fan speed")
Fixes: 76f7eba3e0a2 ("platform/x86: system76_acpi: Add battery charging thresholds")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20211022154901.904984-1-arnd@kernel.org
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
It turns out that systemd-logind by default listens for KEY_RESTART input
events and reboots the machine, which isn't great - So use KEY_VENDOR for
the vendor specific identify button instead to not conflict.
Signed-off-by: Peter Korsgaard <peter.korsgaard@barco.com>
Link: https://lore.kernel.org/r/20211022124612.19780-1-peter@korsgaard.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
coccicheck complains about the use of snprintf() in sysfs show
functions:
WARNING use scnprintf or sprintf
Use sysfs_emit instead of scnprintf or sprintf makes more sense.
Reported-by: Zeal Robot <zealci@zte.com.cn>
Signed-off-by: Ye Guojin <ye.guojin@zte.com.cn>
Link: https://lore.kernel.org/r/20211022090851.1065538-1-ye.guojin@zte.com.cn
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
coccicheck complains about the use of snprintf() in sysfs show
functions:
WARNING use scnprintf or sprintf
Use sysfs_emit instead of scnprintf or sprintf makes more sense.
Reported-by: Zeal Robot <zealci@zte.com.cn>
Signed-off-by: Ye Guojin <ye.guojin@zte.com.cn>
Link: https://lore.kernel.org/r/20211022090722.1065457-1-ye.guojin@zte.com.cn
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Since AML code on some Xiaomi laptops notifies the WMI hotkey with
0x20 event, we need ACPI_ALL_NOTIFY here to be able to handle it.
Signed-off-by: Mikalai Ramanovich <nikolay.romanovich.00@gmail.com>
Link: https://lore.kernel.org/r/20211015191322.73388-1-nikolay.romanovich.00@gmail.com
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
RTC based wakeup from s0i3 doesn't work properly on some Green Sardine
platforms. Because of this, a newer SMU for Green Sardine has the ability
to pass wakeup time as argument of the upper 16 bits of OS_HINT message.
With older firmware setting the timer value in OS_HINT will cause firmware
to reject the hint, so only run this path on:
1) Green Sardine
2) Minimum SMU FW
3) RTC alarm armed during s0i3 entry
Using this method has some limitations that the s0i3 wakeup will need to
be between 4 seconds and 18 hours, so check those boundary conditions as
well and abort the suspend if RTC is armed for too short or too long of a
duration.
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Link: https://lore.kernel.org/r/20211020162946.10537-2-mario.limonciello@amd.com
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Currently the "argument" for the "message" is listed as a boolean
value. This works well for the commands used currently, but an
additional upcoming command will pass more data in the message.
Expand it to be a full 32 bit value.
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Link: https://lore.kernel.org/r/20211020162946.10537-1-mario.limonciello@amd.com
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
This reverts commit 9bba96275576da0cf78ede62aeb2fc975ed8a32d.
The above commit was added to prevent the tipd driver from loading
in devices which have INT3515 ACPI nodes since high CPU load was
reported in these devices due to interrupt flood. Now that the issue
of interrupt flood in the tipd driver is fixed, re-enable the creation
of platform device for INT3515 ACPI nodes.
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Saranya Gopal <saranya.gopal@intel.com>
Link: https://lore.kernel.org/r/20211020022620.21012-3-saranya.gopal@intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add a driver providing access to the GPIOs for the identify button and led
present on Barco P50 board, based on the pcengines-apuv2.c driver.
There is unfortunately no suitable ACPI entry for the EC communication
interface, so instead bind to boards with "P50" as their DMI product family
and hard code the I/O port number (0x299).
The driver also hooks up the leds-gpio and gpio-keys-polled drivers to the
GPIOs, so they are finally exposed as:
LED:
/sys/class/leds/identify
Button: (/proc/bus/input/devices)
I: Bus=0019 Vendor=0001 Product=0001 Version=0100
N: Name="identify"
P: Phys=gpio-keys-polled/input0
S: Sysfs=/devices/platform/barco-p50-gpio/gpio-keys-polled/input/input10
U: Uniq=
H: Handlers=event10
B: PROP=0
B: EV=3
B: KEY=1000000 0 0 0 0 0 0
Signed-off-by: Santosh Kumar Yadav <santoshkumar.yadav@barco.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Link: https://lore.kernel.org/r/20211020123634.2638-1-peter@korsgaard.com
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
A new warning in clang points out a use of bitwise OR with boolean
expressions in this driver:
drivers/platform/x86/thinkpad_acpi.c:9061:11: error: use of bitwise '|' with boolean operands [-Werror,-Wbitwise-instead-of-logical]
else if ((strlencmp(cmd, "level disengaged") == 0) |
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
||
drivers/platform/x86/thinkpad_acpi.c:9061:11: note: cast one or both operands to int to silence this warning
1 error generated.
This should clearly be a logical OR so change it to fix the warning.
Fixes: fe98a52ce754 ("ACPI: thinkpad-acpi: add sysfs support to fan subdriver")
Link: https://github.com/ClangBuiltLinux/linux/issues/1476
Reported-by: Tor Vic <torvic9@mailbox.org>
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Link: https://lore.kernel.org/r/20211018182537.2316800-1-nathan@kernel.org
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
coccicheck complains about the use of snprintf() in sysfs show
functions:
WARNING use scnprintf or sprintf
Use sysfs_emit instead of scnprintf or sprintf makes more sense.
Reported-by: Zeal Robot <zealci@zte.com.cn>
Signed-off-by: Ye Guojin <ye.guojin@zte.com.cn>
Link: https://lore.kernel.org/r/20211018091750.858826-1-ye.guojin@zte.com.cn
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
show() must not use snprintf() when formatting the value to be
returned to user space.
Fix the coccicheck warnings:
WARNING: use scnprintf or sprintf.
Use sysfs_emit instead of scnprintf or sprintf makes more sense.
Signed-off-by: Qing Wang <wangqing@vivo.com>
Link: https://lore.kernel.org/r/1634280641-4862-1-git-send-email-wangqing@vivo.com
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
The ACPI_HANDLE() macro is a wrapper arond the ACPI_COMPANION()
macro and the ACPI handle produced by the former comes from the
ACPI device object produced by the latter, so it is way more
straightforward to evaluate the latter directly instead of passing
the handle produced by the former to acpi_bus_get_device().
Modify ideapad_acpi_add() accordingly (no intentional functional
impact).
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://lore.kernel.org/r/8000884.T7Z3S40VBb@kreacher
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Create the attribute groups for kb_led_color and set the `groups` field
in kb_led. While touching it, also change its show method to use
sysfs_emit() instead of sprintf().
Signed-off-by: Tim Crawford <tcrawford@system76.com>
Link: https://lore.kernel.org/r/20211006202202.7479-5-tcrawford@system76.com
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
System76 laptops running open source EC firmware support configuring
charging thresholds through ACPI methods. Expose this functionality
through the standard sysfs entries charge_control_{start,end}_threshold.
Signed-off-by: Tim Crawford <tcrawford@system76.com>
Link: https://lore.kernel.org/r/20211006202202.7479-4-tcrawford@system76.com
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
System76 laptops models with OLED displays do not support the default
Fn+F2 behavior of turning the embedded display on and off. Some models
instead introduce a new notify event that is used to lock the screen so
the OS will put the display in a low power state.
Signed-off-by: Jeremy Soller <jeremy@system76.com>
Signed-off-by: Tim Crawford <tcrawford@system76.com>
Link: https://lore.kernel.org/r/20211006202202.7479-3-tcrawford@system76.com
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Add a hwmon interface to report CPU/GPU temperature and fan speed.
sensors now reports an ACPI interface with the entries:
system76_acpi-acpi-0
Adapter: ACPI interface
CPU fan: 0 RPM
GPU fan: 0 RPM
CPU temp: +47.0°C
GPU temp: +0.0°C
Signed-off-by: Jeremy Soller <jeremy@system76.com>
Signed-off-by: Tim Crawford <tcrawford@system76.com>
Link: https://lore.kernel.org/r/20211006202202.7479-2-tcrawford@system76.com
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Add new registers to support systems with multiply cooling devices.
Modular systems support up-to four cooling devices. This capability
is detected according to the registers initial setting.
Signed-off-by: Vadim Pasternak <vadimp@nvidia.com>
Reviewed-by: Michael <michaelsh@nvidia.com>
Link: https://lore.kernel.org/r/20211002093609.3771576-1-vadimp@nvidia.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Add event notifier callbacks for modular system line cards. These
callbacks are to be passed to "mlxreg-hotplug" driver by line card
driver during probing. Then, when any line card related hotplug event
is received (insertion ,power, synch, ready), hotplug driver will
invoke callback for the relevant line card.
Signed-off-by: Vadim Pasternak <vadimp@nvidia.com>
Reviewed-by: Michael Shych <michaelsh@nvidia.com>
Link: https://lore.kernel.org/r/20211002093238.3771419-5-vadimp@nvidia.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Add initial chassis management support for Nvidia modular Ethernet
switch systems MSN4800, providing a high performance switching solution
for Enterprise Data Centers (EDC) for building Ethernet based clusters,
High-Performance Computing (HPC) and embedded environments.
This system could be equipped with the different types of replaceable
line cards and management board. The first system flavor will support
the line card type MSN4800-C16 equipped with Lattice CPLD devices aimed
for system and ASIC control, one Nvidia FPGA for gearboxes (PHYs)
management, and four Nvidia gearboxes for the port control and with
16x100GbE QSFP28 ports and also with various devices for electrical
control.
The system is equipped with eight slots for line cards, four slots for
power supplies and six slots for fans. It could be configured as fully
populated or with even only one line card. The line cards are
hot-pluggable.
In the future when more line card flavors are to be available (for
example line cards with 8x200Gb Eth port, with 4x400 Eth ports, or with
some kind of smart cards for offloading purpose), any type of line card
could be inserted at any slot.
The system is based on Nvidia Spectrum-3 ASIC. The switch height is
4U and it fits standard rack size.
System could be configured as fully populated or with even only one
line card. The line cards are hot-pluggable.
Line cards are connected to the chassis through I2C interface for the
chassis management operations and through PCIe for the networking
operations. Future line cards could be connected to the chassis through
InfiniBand fabric, instead of PCIe.
The first type of line card supports 16x100GbE QSFP28 Ethernet ports.
Those line cards equipped with the programmable devices aimed for
system control of Nvidia Ethernet switch ASIC control, Nvidia FPGA,
Nvidia gearboxes (PHYs).
The next coming card generations are supposed to support:
- Line cards with 8x200Gbe QSFP28 Ethernet ports.
- Line cards with 4x400Gbe QSFP-DD Ethernet ports.
- Smart cards equipped with Nvidia ARM CPU for offloading and for fast
access to the storage (EBoF).
- Fabric cards for inter-connection.
The basic system initialization flow with input signals from the
programmable device to kernel hotplug driver and with OS response
to some of these signals is depicted below.
lc#n_prsnt *-> Input: line card presence in/out events.
Informational event. Required action - 'udev' event
generation for logging.
lc#n_verified *-> Input: line card verification status events coming
after line card security signature validation by
hardware. Required action - connect line card
driver and initialized line card devices feeding
from system auxiliary power domain.
lc#n_pwr <-* Output: line card power on / off from OS. Action
should be performed by platform power management
driver.
lc#n_powered *-> Input: line card power on/off events coming after
line card "power good" on/off events, mean that
line card power up sequence has been successfully
completed or line card "power good" status has been
dropped. Required action - connect line card
devices feeding from system main power domain.
lc#n_synced *-> Input: line card synchronization events, coming
after hardware-firmware synchronization handshake.
Required action - to enable line card, in case
lc#n_ready has been received before.
lc#n_ready *-> Input: line card ready events, indicating line card
PHYs ready / unready states. Required action -
enable line card, in case lc#n_synced has been
received before.
lc#n_enable <-* Output: line card enable from OS - release FPGA and
PHYs line card devices from reset state. Action
should be performed by platform power management
driver.
lc#n_active *-> Input: when line card "active event" is received
for particular line card, its network, hardware
monitoring and thermal interfaces should be
configured according to the configuration obtained
from the firmware. When opposite "inactive event"
is received all the above interfaces should be
teared down. Required action - connect / disconnect
the above line card interfaces through ASIC I2C
chassis management driver.
For initial support:
- Define new system type 'VMOD0011' to support new modular system.
- Provide initial platform configuration for new system type.
- Extend the registers definitions.
- Add support for modular system registers related to line card
specific events - insertion/removal, power on/off, verification
and activation.
- Add hotplug configuration for the above events.
- Add configurations for hotplug actions for the modular system.
Signed-off-by: Vadim Pasternak <vadimp@nvidia.com>
Reviewed-by: Michael Shych <michaelsh@nvidia.com>
Link: https://lore.kernel.org/r/20211002093238.3771419-3-vadimp@nvidia.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Up to now lis3lv02d_remove_fs() returns zero unconditionally. Make it return
void instead which makes it easier to see in the callers that there is
no error to handle.
Also the return value of i2c and spi remove callbacks is ignored anyway.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20211012153945.2651412-13-u.kleine-koenig@pengutronix.de
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
SAR information from BIOS may come in non sequential pattern.
To overcome the issue, a check is made to extract the right SAR
information using the device mode which is currently being used.
Remove .owner field if calls are used which set it automatically.
Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci
Signed-off-by: Shravan S <s.shravan@intel.com>
Link: https://lore.kernel.org/r/20211006073525.1332925-1-s.shravan@intel.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
SAR information from BIOS may come in non sequential pattern.
To overcome the issue, a check is made to extract the right SAR
information using the device mode which is currently being used.
Remove .owner field if calls are used which set it automatically.
Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci
Signed-off-by: Shravan S <s.shravan@intel.com>
Link: https://lore.kernel.org/r/20211006073525.1332925-1-s.shravan@intel.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The int3472-discrete driver can enter an error path after initialising
int3472->clock.ena_gpio, but before it has registered the clock. This will
cause a NULL pointer dereference, because clkdev_drop() is not null aware.
Instead of guarding the call to skl_int3472_unregister_clock() by checking
for .ena_gpio, check specifically for the presence of the clk_lookup, which
will guarantee clkdev_create() has already been called.
Bug: https://bugzilla.kernel.org/show_bug.cgi?id=214453
Fixes: 7540599a5ef1 ("platform/x86: intel_skl_int3472: Provide skl_int3472_unregister_clock()")
Signed-off-by: Daniel Scally <djrscally@gmail.com>
Link: https://lore.kernel.org/r/20211008224608.415949-1-djrscally@gmail.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
The int3472-discrete driver can enter an error path after initialising
int3472->clock.ena_gpio, but before it has registered the clock. This will
cause a NULL pointer dereference, because clkdev_drop() is not null aware.
Instead of guarding the call to skl_int3472_unregister_clock() by checking
for .ena_gpio, check specifically for the presence of the clk_lookup, which
will guarantee clkdev_create() has already been called.
Bug: https://bugzilla.kernel.org/show_bug.cgi?id=214453
Fixes: 7540599a5ef1 ("platform/x86: intel_skl_int3472: Provide skl_int3472_unregister_clock()")
Signed-off-by: Daniel Scally <djrscally@gmail.com>
Link: https://lore.kernel.org/r/20211008224608.415949-1-djrscally@gmail.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
The comment decribing the IPC timeout hadn't been updated when the
actual timeout was changed from 3 to 5 seconds in
commit a7d53dbbc70a ("platform/x86: intel_scu_ipc: Increase virtual
timeout from 3 to 5 seconds") .
Since the value is anyway updated to 10s now, take this opportunity to
update the value in the comment too.
Signed-off-by: Prashant Malani <pmalani@chromium.org>
Cc: Benson Leung <bleung@chromium.org>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Link: https://lore.kernel.org/r/20210928101932.2543937-4-pmalani@chromium.org
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Commit a7d53dbbc70a ("platform/x86: intel_scu_ipc: Increase virtual
timeout from 3 to 5 seconds") states that the recommended timeout range
is 5-10 seconds. Adjust the timeout value to the higher of those i.e 10
seconds, to account for situations where the 5 seconds is insufficient
for disconnect command success.
Signed-off-by: Prashant Malani <pmalani@chromium.org>
Cc: Benson Leung <bleung@chromium.org>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Link: https://lore.kernel.org/r/20210928101932.2543937-3-pmalani@chromium.org
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
The macro IPC_TIMEOUT is already in jiffies (it is also used like that
elsewhere in the file when calling wait_for_completion_timeout()). Don’t
convert it using helper functions for the purposes of calculating the
busy loop expiry time.
Fixes: e7b7ab3847c9 (“platform/x86: intel_scu_ipc: Sleeping is fine when polling”)
Signed-off-by: Prashant Malani <pmalani@chromium.org>
Cc: Benson Leung <bleung@chromium.org>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Link: https://lore.kernel.org/r/20210928101932.2543937-2-pmalani@chromium.org
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
The comment decribing the IPC timeout hadn't been updated when the
actual timeout was changed from 3 to 5 seconds in
commit a7d53dbbc70a ("platform/x86: intel_scu_ipc: Increase virtual
timeout from 3 to 5 seconds") .
Since the value is anyway updated to 10s now, take this opportunity to
update the value in the comment too.
Signed-off-by: Prashant Malani <pmalani@chromium.org>
Cc: Benson Leung <bleung@chromium.org>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Link: https://lore.kernel.org/r/20210928101932.2543937-4-pmalani@chromium.org
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Commit a7d53dbbc70a ("platform/x86: intel_scu_ipc: Increase virtual
timeout from 3 to 5 seconds") states that the recommended timeout range
is 5-10 seconds. Adjust the timeout value to the higher of those i.e 10
seconds, to account for situations where the 5 seconds is insufficient
for disconnect command success.
Signed-off-by: Prashant Malani <pmalani@chromium.org>
Cc: Benson Leung <bleung@chromium.org>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Link: https://lore.kernel.org/r/20210928101932.2543937-3-pmalani@chromium.org
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
The macro IPC_TIMEOUT is already in jiffies (it is also used like that
elsewhere in the file when calling wait_for_completion_timeout()). Don’t
convert it using helper functions for the purposes of calculating the
busy loop expiry time.
Fixes: e7b7ab3847c9 (“platform/x86: intel_scu_ipc: Sleeping is fine when polling”)
Signed-off-by: Prashant Malani <pmalani@chromium.org>
Cc: Benson Leung <bleung@chromium.org>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Link: https://lore.kernel.org/r/20210928101932.2543937-2-pmalani@chromium.org
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
DELL_WMI_PRIVACY is a feature toggle for the main dell-wmi driver,
so it must depend on the Kconfig option which enables the main
dell-wmi driver.
Fixes: 8af9fa37b8a3 ("platform/x86: dell-privacy: Add support for Dell hardware privacy")
Reported-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20211011132338.407571-1-hdegoede@redhat.com
