This fixes the following CHECKs, WARNINGs, and ERRORs reported in
hci_intel.c
Reported by checkpatch.pl:
-----------
hci_intel.c
-----------
WARNING: Prefer using '"%s...", __func__' to using 'intel_setup', this
function's name, in a string
+ bt_dev_dbg(hdev, "start intel_setup");
ERROR: code indent should use tabs where possible
+ /* Check for supported iBT hardware variants of this firmware$
ERROR: code indent should use tabs where possible
+ * loading method.$
ERROR: code indent should use tabs where possible
+ *$
ERROR: code indent should use tabs where possible
+ * This check has been put in place to ensure correct forward$
ERROR: code indent should use tabs where possible
+ * compatibility options when newer hardware variants come along.$
ERROR: code indent should use tabs where possible
+ */$
CHECK: No space is necessary after a cast
+ duration = (unsigned long long) ktime_to_ns(delta) >> 10;
CHECK: No space is necessary after a cast
+ duration = (unsigned long long) ktime_to_ns(delta) >> 10;
WARNING: Missing a blank line after declarations
+ int err = PTR_ERR(intel->rx_skb);
+ bt_dev_err(hu->hdev, "Frame reassembly failed (%d)", err);
Signed-off-by: Uri Arev <me@wantyapps.xyz>
Suggested-by: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
In case of a Broadcast Source that has PA enabled but no active BIG,
a Broadcast Sink needs to establish PA sync and parse BASE from PA
reports.
This commit moves the allocation of a PA sync hcon from the BIGInfo
advertising report event to the PA sync established event. After the
first complete PA report, the hcon is notified to the ISO layer. A
child socket is allocated and enqueued in the parent's accept queue.
BIGInfo reports also need to be processed, to extract the encryption
field and inform userspace. After the first BIGInfo report is received,
the PA sync hcon is notified again to the ISO layer. Since a socket will
be found this time, the socket state will transition to BT_CONNECTED and
the userspace will be woken up using sk_state_change.
Signed-off-by: Iulia Tanasescu <iulia.tanasescu@nxp.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
This makes iso_get_sock_listen more generic, to return matching socket
in the state provided as argument.
Signed-off-by: Iulia Tanasescu <iulia.tanasescu@nxp.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
This makes sure that discovery state is properly synchronized otherwise
reports may not generate MGMT DeviceFound events as it would be assumed
that it was not initiated by a discovery session.
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
This adds proper definitions for scan interval and window and then make
use of them instead their values.
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Use macro for image type instead of using hard code number.
Signed-off-by: Kiran K <kiran.k@intel.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
This is the last use of the tristate choice.
This choice was introduced a decade ago by commit a11650e110
("rapidio: make enumeration/discovery configurable"). Since then,
RAPIDIO_ENUM_BASIC has always been the sole member.
There was no need to have this choice block.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Previously, optional bool choices met the following conditions
simultaneously:
- sym_is_choice(sym)
- sym_is_changeable(sym)
- type == S_BOOLEAN
It no longer occurs since 6a1215888e ("kconfig: remove 'optional'
property support"). Remove the dead code.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
This code previously displayed child symbols of the selected choice
member.
Since commit 7e3465f63a ("kconfig: do not reparent the menu inside
a choice block"), choice members never have child symbols, therefore
this is dead code.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Currently, bool choices have a checkbox, but tristate choices do not.
It is opposite.
Bool choices should not have a checkbox, as they are fixed to 'y' since
commit 6a1215888e ("kconfig: remove 'optional' property support").
Tristate choices, however, should have a checkbox to allow users to
toggle the value.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Instead of filtering out the GCOV and KCSAN flags, let's set GCOV_PROFILE
and KCSAN_SANITIZE to 'n', as in other Makefiles.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
Tested-by: Roberto Sassu <roberto.sassu@huawei.com>
Now Kbuild provides reasonable defaults for objtool, sanitizers, and
profilers.
Remove redundant variables.
Note:
This commit changes the coverage for some objects:
- include arch/mips/vdso/vdso-image.o into UBSAN, GCOV, KCOV
- include arch/sparc/vdso/vdso-image-*.o into UBSAN
- include arch/sparc/vdso/vma.o into UBSAN
- include arch/x86/entry/vdso/extable.o into KASAN, KCSAN, UBSAN, GCOV, KCOV
- include arch/x86/entry/vdso/vdso-image-*.o into KASAN, KCSAN, UBSAN, GCOV, KCOV
- include arch/x86/entry/vdso/vdso32-setup.o into KASAN, KCSAN, UBSAN, GCOV, KCOV
- include arch/x86/entry/vdso/vma.o into GCOV, KCOV
- include arch/x86/um/vdso/vma.o into KASAN, GCOV, KCOV
I believe these are positive effects because all of them are kernel
space objects.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
Tested-by: Roberto Sassu <roberto.sassu@huawei.com>
The objtool, sanitizers (KASAN, UBSAN, etc.), and profilers (GCOV, etc.)
are intended only for kernel space objects.
For instance, the following are not kernel objects, and therefore should
opt out of coverage:
- vDSO
- purgatory
- bootloader (arch/*/boot/)
However, to exclude these from coverage, you need to explicitly set
OBJECT_FILES_NON_STNDARD=y, KASAN_SANITIZE=n, etc.
Kbuild can achieve this without relying on such variables because
objects not directly linked to vmlinux or modules are considered
"non-standard objects".
Detecting standard objects is straightforward:
- objects added to obj-y or lib-y are linked to vmlinux
- objects added to obj-m are linked to modules
There are some exceptional Makefiles (e.g., arch/s390/boot/Makefile,
arch/xtensa/boot/lib/Makefile) that use obj-y or lib-y for non-kernel
space objects, but they can be fixed later if necessary.
Going forward, objects that are not listed in obj-y, lib-y, or obj-m
will opt out of objtool, sanitizers, and profilers by default.
You can still override the Kbuild decision by explicitly specifying
OBJECT_FILES_NON_STANDARD, KASAN_SANITIZE, etc. but most of such Make
variables can be removed.
The next commit will clean up redundant variables.
Note:
This commit changes the coverage for some objects:
- exclude .vmlinux.export.o from UBSAN, KCOV
- exclude arch/csky/kernel/vdso/vgettimeofday.o from UBSAN
- exclude arch/parisc/kernel/vdso32/vdso32.so from UBSAN
- exclude arch/parisc/kernel/vdso64/vdso64.so from UBSAN
- exclude arch/x86/um/vdso/um_vdso.o from UBSAN
- exclude drivers/misc/lkdtm/rodata.o from UBSAN, KCOV
- exclude init/version-timestamp.o from UBSAN, KCOV
- exclude lib/test_fortify/*.o from all santizers and profilers
I believe these are positive effects.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
Tested-by: Roberto Sassu <roberto.sassu@huawei.com>
The blamed commit started to use the ptp workqueue to get the second
part of the timestamp. And when the port was set down, then this
workqueue is stopped. But if the config option NETWORK_PHY_TIMESTAMPING
is not enabled, then the ptp_clock is not initialized so then it would
crash when it would try to access the delayed work.
So then basically by setting up and then down the port, it would crash.
The fix consists in checking if the ptp_clock is initialized and only
then cancel the delayed work.
Fixes: cc75549548 ("net: micrel: Change to receive timestamp in the frame for lan8841")
Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
- updates to HID-BPF infrastructure, with some of the specific
fixes (e.g. rdesc fixups) abstracted into separate BPF programs
for consumption by libevdev/udev-hid-bpf (Benjamin Tissoires)
Dell All In One (AIO) models released after 2017 use a backlight controller
board connected to an UART.
Add a small emulator to allow development and testing of
the drivers/platform/x86/dell/dell-uart-backlight.c driver for
this board, without requiring access to an actual Dell All In One.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20240513144603.93874-3-hdegoede@redhat.com
Dell All In One (AIO) models released after 2017 use a backlight controller
board connected to an UART.
In DSDT this uart port will be defined as:
Name (_HID, "DELL0501")
Name (_CID, EisaId ("PNP0501")
Instead of having a separate ACPI device with an UartSerialBusV2() resource
to model the backlight-controller, which would be the standard way to do
this.
The acpi_quirk_skip_serdev_enumeration() has special handling for this
and it will make the serial port code create a serdev controller device
for the UART instead of a /dev/ttyS0 char-dev. It will also create
a dell-uart-backlight driver platform device for this driver to bind too.
This new kernel module contains 2 drivers for this:
1. A simple platform driver which creates the actual serdev device
(with the serdev controller device as parent)
2. A serdev driver for the created serdev device which exports
the backlight functionality uses a standard backlight class device.
Reported-by: Roman Bogoyev <roman@computercheck.com.au>
Tested-by: Roman Bogoyev <roman@computercheck.com.au>
Tested-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Co-developed-by: AceLan Kao <acelan.kao@canonical.com>
Signed-off-by: AceLan Kao <acelan.kao@canonical.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20240513144603.93874-2-hdegoede@redhat.com
The Xiaomi [Mi]Pad 2 has 3 menu / home / back capacitive touch-buttons
on its bottom bezel. These are backlit by LEDs attached to a TPS61158 LED
controller which is controlled by the "pwm_soc_lpss_2" PWM output.
Create a LED class device for this, using the new input-events trigger
as default trigger so that the buttons automatically light up on any
input activity.
Note alternatively a "leds_pwm" platform device could be created together
with the necessary fwnode_s_ and a fwnode link to the PWM controller.
There are 2 downsides to this approach:
1. The code would still need to pwm_get() the PWM controller to get/attach
a fwnode for the PWM controller fwnode link and setting up the necessary
fwnodes is non-trivial. So this would likely require more code then simply
registering the LED class device directly.
2. Currently the leds_pwm driver and its devicetree bindings do not support
limiting the maximum dutycycle to less then 100% which is required in this
case (the leds_pwm driver can probably be extended to allow this).
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20240509141207.63570-2-hdegoede@redhat.com
Xiaomi pad2 RGB LED fwnode updates:
1. Set "label" instead "function" to change the LED classdev name from
"rgb:indicator" to "mipad2:rgb:indicator" to match the usual
triplet name format for LED classdevs.
2. Set the trigger to the new "bq27520-0-charging-orange-full-green"
powersupply trigger type for multi-color LEDs.
3. Put the fwnode link for red before green in ktd2026_node_group[] so that
multi_index becomes "red green blue".
Signed-off-by: Kate Hsuan <hpa@redhat.com>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Co-developed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20240504164105.114017-8-hdegoede@redhat.com
Pass a struct device pointer for x86_android_tablet_device to the board
specific init() functions, so that these functions can use this for
e.g. devm_*() functions.
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20240509141207.63570-1-hdegoede@redhat.com
The P2SB could get an invalid BAR from the BIOS, and that won't be fixed
up until pcibios_assign_resources(), which is an fs_initcall().
- Move p2sb_fs_init() to an fs_initcall_sync(). This is still early
enough to avoid a race with any dependent drivers.
- Add a check for IORESOURCE_UNSET in p2sb_valid_resource() to catch
unset BARs going forward.
- Return error values from p2sb_fs_init() so that the 'initcall_debug'
cmdline arg provides useful data.
Signed-off-by: Ben Fradella <bfradell@netapp.com>
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Tested-by: Klara Modin <klarasmodin@gmail.com>
Reviewed-by: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
Link: https://lore.kernel.org/r/20240509164905.41016-1-bcfradella@proton.me
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Emits messages upon errors during probing of SAM. Hopefully this could
provide useful context to user for the purpose of diagnosis when
something miserable happen.
Reviewed-by: Maximilian Luz <luzmaximilian@gmail.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Weifeng Liu <weifeng.liu.z@gmail.com>
Link: https://lore.kernel.org/r/20240505130800.2546640-3-weifeng.liu.z@gmail.com
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
BPF just-in-time compiler depended on CONFIG_MODULES because it used
module_alloc() to allocate memory for the generated code.
Since code allocations are now implemented with execmem, drop dependency of
CONFIG_BPF_JIT on CONFIG_MODULES and make it select CONFIG_EXECMEM.
Suggested-by: Björn Töpel <bjorn@kernel.org>
Signed-off-by: Mike Rapoport (IBM) <rppt@kernel.org>
Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
kprobes depended on CONFIG_MODULES because it has to allocate memory for
code.
Since code allocations are now implemented with execmem, kprobes can be
enabled in non-modular kernels.
Add #ifdef CONFIG_MODULE guards for the code dealing with kprobes inside
modules, make CONFIG_KPROBES select CONFIG_EXECMEM and drop the
dependency of CONFIG_KPROBES on CONFIG_MODULES.
Signed-off-by: Mike Rapoport (IBM) <rppt@kernel.org>
Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
[mcgrof: rebase in light of NEED_TASKS_RCU ]
Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
There are places where CONFIG_MODULES guards the code that depends on
memory allocation being done with module_alloc().
Replace CONFIG_MODULES with CONFIG_EXECMEM in such places.
Signed-off-by: Mike Rapoport (IBM) <rppt@kernel.org>
Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
Dynamic ftrace must allocate memory for code and this was impossible
without CONFIG_MODULES.
With execmem separated from the modules code, execmem_text_alloc() is
available regardless of CONFIG_MODULES.
Remove dependency of dynamic ftrace on CONFIG_MODULES and make
CONFIG_DYNAMIC_FTRACE select CONFIG_EXECMEM in Kconfig.
Signed-off-by: Mike Rapoport (IBM) <rppt@kernel.org>
Reviewed-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
