Forest Bond contributed this driver in 2009.
The following reasons lead to the removal:
- This driver generates maintenance workload
- This driver has a maximum 54MBit/s as it supports only 802.11 b/g.
Peak throughput is 3MBytes/s but this lasts only for a second.
Typically throughput is 1.7MBytes/s.
- Depending on the number of devices on the channel the device looses
connection and cannot reconnect for 5-60 seconds. Watching a youtube
video is OK because of the buffer. But surfing can then be really a
pain.
- Its form factor is mini PCI (not miniPCIe) that is old and large.
- Hardly not to buy.
Link: https://lore.kernel.org/linux-staging/2024100923-player-directive-ffa8@gregkh/T/#t
Signed-off-by: Philipp Hortmann <philipp.g.hortmann@gmail.com>
Link: https://lore.kernel.org/r/20241010164221.13392-1-philipp.g.hortmann@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
It breaks the build so disable that option for now.
It shouldn't be needed anyway, the normal in-kernel debugging facilities
should be used instead.
Cc: Dave Penkler <dpenkler@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bulk transfers core logic lives in vchiq_core.c, hence move all
the preparatory bulk data allocation helpers to vchiq_core.c (from
vchiq_arm).
The discrepancy was noticed when vchiq_prepare_bulk_data() and
vchiq_complete_bulk() are being used vchiq_core.c but are defined
in vchiq_arm. Now that they are now confined to vchiq_core.c,
they can be made static and their signatures from vchiq_core header
can be dropped.
vchiq_prepare_bulk_data() and vchiq_complete_bulk() depends on
struct vchiq_pagelist_info, cleanup_pagelist(), free_pagelist() and
create_pagelist() hence they are pulled in from vchiq_arm as well,
as part of this commit.
No functional changes intended in this patch.
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Dan Carpenter <dan.carpenter@linaro.org>
Link: https://lore.kernel.org/r/20240919142130.1331495-3-umang.jain@ideasonboard.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The function remote_event_signal() is declared in vchiq_core.h while
defined in vchiq_arm.c and used only in vchiq_core.c. Move the
definition to vchiq_core.c as it is only used in this file.
Also convert it to static and drop the function signature from
vchiq_core.h header. BELL2 doorbell macro is also moved from vchiq_arm
to vchiq_core as part of this change.
No functional changes intended in this patch.
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Dan Carpenter <dan.carpenter@linaro.org>
Link: https://lore.kernel.org/r/20240919142130.1331495-2-umang.jain@ideasonboard.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bulk transfers for various VCHIQ modes use mutex_lock_killable() and
wait_for_completion_killable() variations. Currently, -EAGAIN is
returned if these are interrupted by a fatal signal.
-EAGAIN may mislead the caller into thinking the operation can be
retried, while in reality, the process has received a fatal signal
and is terminating. Therefore, we should update the return value to
align with what these killable functions would return, specifically
-EINTR (Interrupted system call).
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Link: https://lore.kernel.org/r/20240918163100.870596-5-umang.jain@ideasonboard.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
queue_message() uses mutex_lock_killable() and
wait_for_completion_killable() variations of locking and wait event
completions respectively. These functions return either 0 (on success)
or -EINTR, if interrupted by a fatal signal (as documented in the
kernel).
However, queue_message() is currently returning -EAGAIN if these
killable functions are interrupted by fatal signals. Bubbling up
-EAGAIN might give a sense to the caller, that the code path can
be re-tried however, in actual sense, a fatal signal has been
received by the process and the process is going away.
Hence, we should align the return value with what these killable
versions will return i.e. -EINTR (Interrupted system call).
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Link: https://lore.kernel.org/r/20240918163100.870596-4-umang.jain@ideasonboard.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f27e47bc6b ("staging: vchiq: use completions instead of
semaphores") introduced completions for events in vchiq interface.
It introduced _interruptible() version of completions for waiting
on events. However, it missed a subtle down_interruptible() macro
override in vchiq_killable.h, which used to mask most of the signals
and only interrupt on fatal ones.
The above issue was fixed in commit a772f11670 ("staging: vchiq: switch
to wait_for_completion_killable"). Given the override logic of
down_interruptible() that existed in vchiq_killable.h, that commit
fixed the completions with the correct variation i.e. killable() family
of functions.
However, commit a772f11670 ("staging: vchiq: switch to
wait_for_completion_killable") later got reverted [1] due to high CPU
load noticed by various downstream and upstream distributions [2].
Reverting the commit solved this problem but the root cause was never
diagonsed and the entire commit was reverted.
This patch brings back killable version of wait events but only for
bulk transfers and queue_message() transfer code paths.
The idea is to bring back killable versions for various event
completions in a phased manner so that we do not re-regress again as
noticed in [2]. Hence, no other wait events are converted from
interruptible -> killable in this patch.
Since the bulk transfers are no longer interruptible (but killable),
drop the "_interruptible" suffix from all vchiq_bulk_xfer_* functions.
[1]: commit 086efbabdc ("staging: vchiq: revert "switch to wait_for_completion_killable"")
[2]: https://patchwork.kernel.org/project/linux-arm-kernel/cover/20190509143137.31254-1-nsaenzjulienne@suse.de/
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Link: https://lore.kernel.org/r/20240918163100.870596-2-umang.jain@ideasonboard.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
After commit 0edb555a65 ("platform: Make platform_driver::remove()
return void") .remove() is (again) the right callback to implement for
platform drivers.
Convert all staging drivers to use .remove(), with the eventual goal to
drop struct platform_driver::remove_new(). As .remove() and .remove_new()
have the same prototypes, conversion is done by just changing the structure
member name in the driver initializer.
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Link: https://lore.kernel.org/r/20241001085751.282113-1-sergio.paracuellos@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
These drivers don't use the driver_data member of struct i2c_device_id,
so don't explicitly initialize this member.
This prepares putting driver_data in an anonymous union which requires
either no initialization or named designators. But it's also a nice
cleanup on its own.
While touching the initializer, also remove the comma after the sentinel
entry.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Link: https://lore.kernel.org/r/20240920153430.503212-15-u.kleine-koenig@baylibre.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
