IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Now that the driver core allows for struct class to be in read-only
memory, making all 'class' structures to be declared at build time
placing them into read-only memory, instead of having to be dynamically
allocated at load time.
Cc: Alex Elder <elder@kernel.org>
Cc: greybus-dev@lists.linaro.org
Reviewed-by: Johan Hovold <johan@kernel.org>
Link: https://lore.kernel.org/r/2023100534-showoff-alright-6c95@gregkh
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Now that the driver core allows for struct class to be in read-only
memory, making all 'class' structures to be declared at build time
placing them into read-only memory, instead of having to be dynamically
allocated at load time.
Cc: Alex Elder <elder@kernel.org>
Cc: greybus-dev@lists.linaro.org
Reviewed-by: Johan Hovold <johan@kernel.org>
Link: https://lore.kernel.org/r/2023100533-broadband-hunk-9e91@gregkh
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Now that the driver core allows for struct class to be in read-only
memory, making all 'class' structures to be declared at build time
placing them into read-only memory, instead of having to be dynamically
allocated at load time.
Link: https://lore.kernel.org/r/2023100512-sweat-abruptly-2445@gregkh
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Now that the driver core allows for struct class to be in read-only
memory, making all 'class' structures to be declared at build time
placing them into read-only memory, instead of having to be dynamically
allocated at load time.
Link: https://lore.kernel.org/r/2023100523-throwback-oak-a164@gregkh
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Now that the driver core allows for struct class to be in read-only
memory, making all 'class' structures to be declared at build time
placing them into read-only memory, instead of having to be dynamically
allocated at load time.
Cc: Sven Van Asbroeck <TheSven73@gmail.com>
Link: https://lore.kernel.org/r/2023100552-entrench-dingbat-093a@gregkh
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Similar to how bcm2385-camera device is registered, register the
bcm2835-audio with vchiq_bus_type as well.
Since we moved away bcm2835-audio from platform driver/device,
we have to set the DMA mask explicitly. Set the DMA mask at probe
time.
Meanwhile at it, change the name and module alias from "bcm2835_audio"
to "bcm2835-audio" to be consistent with bcm2835-camera device. This
does not brings any functional change as '-' and '_' are
interchangeable as per modprobe man pages.
Also, drop vchiq_register_child() helper which is no longer
needed after this patch.
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Link: https://lore.kernel.org/r/20230923143200.268063-7-umang.jain@ideasonboard.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Register the bcm2835-camera with the vchiq_bus_type instead of using
platform driver/device.
Since we moved away bcm2835-camera from platform driver/device,
we have to set the DMA mask explicitly. Set the DMA mask at probe
time.
Also the VCHIQ firmware doesn't support device enumeration, hence
one has to maintain a list of devices to be registered in the interface.
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Link: https://lore.kernel.org/r/20230923143200.268063-6-umang.jain@ideasonboard.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Register the vchiq_bus_type bus with the vchiq interface.
The bcm2835-camera and bcm2835_audio will be registered to this bus type
going ahead.
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Link: https://lore.kernel.org/r/20230923143200.268063-5-umang.jain@ideasonboard.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The devices that the vchiq interface registers (bcm2835-audio,
bcm2835-camera) are implemented and exposed by the VC04 firmware.
The device tree describes the VC04 itself with the resources required
to communicate with it through a mailbox interface. However, the
vchiq interface registers these devices as platform devices. This
also means the specific drivers for these devices are getting
registered as platform drivers. This is not correct and a blatant
abuse of platform device/driver.
Add a new bus type, vchiq_bus_type and device type (struct vchiq_device)
which will be used to migrate child devices that the vchiq interfaces
creates/registers from the platform device/driver.
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Link: https://lore.kernel.org/r/20230923143200.268063-4-umang.jain@ideasonboard.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In the following patches, vchiq_arm will be migrated to create and use
its own bus and all the vchiq drivers (bcm2835-camera, bcm2835-audio)
will be registered to it. Since the platform driver/device model
internally sets the DMA mask for its registered devices, we would have
to do it ourself when we remove the platform driver/device registration
for vchiq devices.
This patch explicitly sets the DMA mask to bcm2835-audio so as not
to introduce a regression when we move away from platform
device/driver model.
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Link: https://lore.kernel.org/r/20230923143200.268063-3-umang.jain@ideasonboard.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In the following patches, vchiq_arm will be migrated to create and use
its own bus and all the vchiq drivers (bcm2835-camera, bcm2835-audio)
will be registered to it. Since the platform driver/device model
internally sets the DMA mask for its registered devices, we would have
to do it ourself when we remove the platform driver/device registration
for vchiq devices.
This patch explicitly sets the DMA mask to bcm2835-camera so as not
to introduce a regression when we move away from platform
device/driver model.
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Link: https://lore.kernel.org/r/20230923143200.268063-2-umang.jain@ideasonboard.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When the function _rtl92e_if_silent_reset() is called the variable
priv->rst_progress is set to RESET_TYPE_SILENT.
Since priv->up is always true the function is left at "if (priv->up) {"
without resetting. Now the function _rtl92e_if_silent_reset() is like
deactivated because the equation at the very beginning is false:
"if (priv->rst_progress == RESET_TYPE_NORESET) {"
This leads to a state where the driver hangs in the reset state and
cannot go forward.
In 30% of the cases the wlan is disconnected and cannot reconnect. The
rest of the time it continues working but no reset is done at all.
Further requests for reset are ignored. Remove broken function
_rtl92e_if_silent_reset() and remove return value of
_rtl92e_if_check_reset() to avoid compiler warnings.
Signed-off-by: Philipp Hortmann <philipp.g.hortmann@gmail.com>
Link: https://lore.kernel.org/r/8b1b04b512b5691968a49308fdc052973fbe5032.1696165351.git.philipp.g.hortmann@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The return value of _rtl92e_tx_check_stuck() and _rtl92e_rx_check_stuck()
can only be RESET_TYPE_SILENT or RESET_TYPE_NORESET. This functions are
only used in _rtl92e_if_check_reset(). In _rtl92e_if_check_reset() the
return values are checked for RESET_TYPE_NORMAL which cannot occur.
Signed-off-by: Philipp Hortmann <philipp.g.hortmann@gmail.com>
Link: https://lore.kernel.org/r/5f29332205dd76896e981fa627925d62a6bf7f63.1696165351.git.philipp.g.hortmann@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
As &priv->tx_dev.tx_dev_lock is also acquired by xmit callback which
could be call from timer under softirq context, use spin_lock_bh()
on it to prevent potential deadlock.
hostif_sme_work()
--> hostif_sme_set_pmksa()
--> hostif_mib_set_request()
--> ks_wlan_hw_tx()
--> spin_lock(&priv->tx_dev.tx_dev_lock)
ks_wlan_start_xmit()
--> hostif_data_request()
--> ks_wlan_hw_tx()
--> spin_lock(&priv->tx_dev.tx_dev_lock)
Signed-off-by: Chengfeng Ye <dg573847474@gmail.com>
Link: https://lore.kernel.org/r/20230926161323.41928-1-dg573847474@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
variable name "byRFType" updated like below:
a.type encoding info dropped from name
b.camelcase name replaced by snakecase
Issue found by checkpatch
Signed-off-by: Pavan Bobba <opensource206@gmail.com>
Tested-by: Philipp Hortmann <philipp.g.hortmann@gmail.com>
Link: https://lore.kernel.org/r/ZQwyRXFHA9hTLcyv@ubuntu.myguest.virtualbox.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The rtllib_rxb structure contains a pointer, so this is not a hardware
structure but could benefit from loading the pointer in a single
instruction rather than assembling it from four or eight individual
bytes.
Both structures are allocated as part of larger structure that
already enforce at least a 4-byte alignment, so there is no
reason to ever have to deal with misaligned definitions.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20230925155413.471287-2-arnd@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The following command uses the mutex ieee->wx_mutex:
cancel_delayed_work_sync(&ieee->associate_retry_wq)
Therefore it cannot be canceled with ieee->wx_mutex locked.
rtllib_stop_protocol() is always called with ieee->wx_mutex locked so
according line can be unlocked.
Signed-off-by: Philipp Hortmann <philipp.g.hortmann@gmail.com>
Link: https://lore.kernel.org/r/ffe60e8f6e29197f331e239ab38154da97c743be.1695582999.git.philipp.g.hortmann@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The following commands use the mutex ieee->wx_mutex:
cancel_delayed_work_sync(&ieee->associate_retry_wq)
cancel_delayed_work_sync(&ieee->associate_procedure_wq)
cancel_work_sync(&ieee->wx_sync_scan_wq)
Therefore they cannot be canceled with ieee->wx_mutex locked. As the
work functions are executed time shifted during normal operation of the
driver, proper locking can only be done inside the functions.
Signed-off-by: Philipp Hortmann <philipp.g.hortmann@gmail.com>
Link: https://lore.kernel.org/r/a5308876bd8fabcb5f8b25d14dbad2c1f68ce59f.1695582999.git.philipp.g.hortmann@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
