[PATCH 1/2] staging: vt6656: fix sign of rx_dbm to bb_pre_ed_rssi.
bb_pre_ed_rssi is an u8 rx_dm always returns negative signed values add minus operator to always yield positive. fixes issue where rx sensitivity is always set to maximum because the unsigned numbers were always greater then 100. Cc: stable Signed-off-by: Malcolm Priestley --- drivers/staging/vt6656/dpc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/vt6656/dpc.c b/drivers/staging/vt6656/dpc.c index 821aae8ca402..a0b60e7d1086 100644 --- a/drivers/staging/vt6656/dpc.c +++ b/drivers/staging/vt6656/dpc.c @@ -98,7 +98,7 @@ int vnt_rx_data(struct vnt_private *priv, struct vnt_rcb *ptr_rcb, vnt_rf_rssi_to_dbm(priv, tail->rssi, &rx_dbm); - priv->bb_pre_ed_rssi = (u8)rx_dbm + 1; + priv->bb_pre_ed_rssi = (u8)-rx_dbm + 1; priv->current_rssi = priv->bb_pre_ed_rssi; skb_pull(skb, sizeof(*head)); -- 2.25.0 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 2/2] staging: vt6656: Fix return for unsupported cipher modes.
mac80211 expect to see -EOPNOTSUPP on unsupported ciphers so
these can be done on stack.
correct all the returns to do this.
Signed-off-by: Malcolm Priestley
---
drivers/staging/vt6656/key.c | 5 -
drivers/staging/vt6656/main_usb.c | 4 +---
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/vt6656/key.c b/drivers/staging/vt6656/key.c
index dcd933a6b66e..41b73f9670e2 100644
--- a/drivers/staging/vt6656/key.c
+++ b/drivers/staging/vt6656/key.c
@@ -144,11 +144,14 @@ int vnt_set_keys(struct ieee80211_hw *hw, struct
ieee80211_sta *sta,
break;
case WLAN_CIPHER_SUITE_CCMP:
if (priv->local_id <= MAC_REVISION_A1)
- return -EINVAL;
+ return -EOPNOTSUPP;
key_dec_mode = KEY_CTL_CCMP;
key->flags |= IEEE80211_KEY_FLAG_GENERATE_IV;
+ break;
+ default:
+ return -EOPNOTSUPP;
}
if (key->flags & IEEE80211_KEY_FLAG_PAIRWISE) {
diff --git a/drivers/staging/vt6656/main_usb.c
b/drivers/staging/vt6656/main_usb.c
index 5e48b3ddb94c..6e5963adb501 100644
--- a/drivers/staging/vt6656/main_usb.c
+++ b/drivers/staging/vt6656/main_usb.c
@@ -862,9 +862,7 @@ static int vnt_set_key(struct ieee80211_hw *hw, enum
set_key_cmd cmd,
switch (cmd) {
case SET_KEY:
- if (vnt_set_keys(hw, sta, vif, key))
- return -EOPNOTSUPP;
- break;
+ return vnt_set_keys(hw, sta, vif, key);
case DISABLE_KEY:
if (test_bit(key->hw_key_idx, &priv->key_entry_inuse))
clear_bit(key->hw_key_idx, &priv->key_entry_inuse);
--
2.25.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: fbtft: 5 years in staging
Den 02.02.2020 16.41, skrev Noralf Trønnes: > Hi, > > Since I'm the original author of fbtft I thought I'd highlight a couple > of issues that's probably not well known. > > Right after fbtft was added, fbdev was closed for new drivers[1] and > the fbdev maintainer wanted to remove fbtft as a consequence of that > decision, but Greg KH said he'd keep fbtft drivers in staging > "until a matching DRM driver is present in the tree"[2]. > > There are 2 issues wrt the goal of making a matching DRM driver > (strictly speaking). One is impossible to do (policy), the other is > unlikely to happen: > > 1. Device Tree 'init' property > > All fbtft drivers have controller setup code that matches one > particular display panel. From the start of fbtft it was possible to > override this using platform data. Later when Device Tree support was > added, an 'init=' property to do the same was added. > > Example: > init = <0x1e5 0x78F0 > 0x101 0x0100 > 0x232 > 0x107 0x0133>; > > This translates to: > register_write(0x00e5, 0x78F0); > register_write(0x0001, 0x0100); > mdelay(32); > register_write(0x0007, 0x0133); > > AFAIU setting register values from DT is a no-go, so this functionality > can't be replicated in a DRM driver. Many displays are made to work > using this mechanism, in particular ili9341 based ones. > > 2. Parallel bus interface > > All fbtft drivers support both a SPI and a parallel bus interface > through the fbtft helper module. Many (not all) controllers support more > than one interface. The parallel bus support was added to fbtft in its > early days when not many SPI displays were available (nowadays there's > lots to choose from). fbtft uses bitbanging to drive the parallel > interface so it's really slow, even more slow than SPI and SPI with DMA > beats it thoroughly. I know there are people that use the paralell bus > support, but I don't see much point in it unless we get a parallel bus > subsystem that can use the dedicated hw on certain SoC's (Beaglebone, > Pi). And those SOC's most likely have a parallel video/RGB bus as well, > which IMO is a much better option for a panel. > > > The following drivers have DRM counterparts that have the same panel > setup code: > > - fb_hx8357d.c: drivers/gpu/drm/tiny/hx8357d.c > - fb_ili9341.c: drivers/gpu/drm/tiny/mi0283qt.c > - fb_st7735r.c: drivers/gpu/drm/tiny/st7735r.c > - fb_ili9486.c: Patches are posted on dri-devel[3] > > But they don't support all panels based on that controller and they > don't have parallel bus support. > > There is actually also another obstacle for conversion and that is, some > of the displays (for which there is builtin driver support) might be > impossible to source except as second hand. And it's not always obvious > which panel is supported by a certain driver. > At least the displays supported by these drivers are listed as > discontinued on the fbtft wiki[4]: > - fb_hx8340bn.c > - fb_hx8347d.c > - fb_ili9320 > > This one never made it from a prototype to an actual product, because > it was too slow: > - fb_watterott.c > > I have no plans to convert fbtft drivers myself, but I figured a 5 year > anniversary was a good excuse for a status update. Some info for anyone wanting to convert fbtft drivers: The following drivers are MIPI DBI compatible (like the ones already converted) which means they have the same protocol and share certain commands. They are very easy to port over for anyone with access to such a display. - fb_hx8340bn.c - fb_hx8353d.c - fb_ili9340.c - fb_ili9481.c - fb_s6d02a1.c - fb_st7789v.c - fb_tinylcd.c (probably has an ili9486 chip) - fb_ili9163.c (library: drivers/gpu/drm/drm_mipi_dbi.c) There is also an out-of-tree ili9325 driver that supports the protocol used by fb_ili9320 and fb_ili9325, but it doesn't support their panels (at least the register values differ): https://github.com/notro/tinydrm/blob/master/ili9325.c > > Noralf. > > [1] https://lkml.org/lkml/2015/9/24/253 > [2] https://lkml.org/lkml/2016/11/23/146 > [3] https://patchwork.freedesktop.org/series/72645/ > [4] https://github.com/notro/fbtft/wiki/LCD-Modules#discontinued-products > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
fbtft: 5 years in staging
Hi, Since I'm the original author of fbtft I thought I'd highlight a couple of issues that's probably not well known. Right after fbtft was added, fbdev was closed for new drivers[1] and the fbdev maintainer wanted to remove fbtft as a consequence of that decision, but Greg KH said he'd keep fbtft drivers in staging "until a matching DRM driver is present in the tree"[2]. There are 2 issues wrt the goal of making a matching DRM driver (strictly speaking). One is impossible to do (policy), the other is unlikely to happen: 1. Device Tree 'init' property All fbtft drivers have controller setup code that matches one particular display panel. From the start of fbtft it was possible to override this using platform data. Later when Device Tree support was added, an 'init=' property to do the same was added. Example: init = <0x1e5 0x78F0 0x101 0x0100 0x232 0x107 0x0133>; This translates to: register_write(0x00e5, 0x78F0); register_write(0x0001, 0x0100); mdelay(32); register_write(0x0007, 0x0133); AFAIU setting register values from DT is a no-go, so this functionality can't be replicated in a DRM driver. Many displays are made to work using this mechanism, in particular ili9341 based ones. 2. Parallel bus interface All fbtft drivers support both a SPI and a parallel bus interface through the fbtft helper module. Many (not all) controllers support more than one interface. The parallel bus support was added to fbtft in its early days when not many SPI displays were available (nowadays there's lots to choose from). fbtft uses bitbanging to drive the parallel interface so it's really slow, even more slow than SPI and SPI with DMA beats it thoroughly. I know there are people that use the paralell bus support, but I don't see much point in it unless we get a parallel bus subsystem that can use the dedicated hw on certain SoC's (Beaglebone, Pi). And those SOC's most likely have a parallel video/RGB bus as well, which IMO is a much better option for a panel. The following drivers have DRM counterparts that have the same panel setup code: - fb_hx8357d.c: drivers/gpu/drm/tiny/hx8357d.c - fb_ili9341.c: drivers/gpu/drm/tiny/mi0283qt.c - fb_st7735r.c: drivers/gpu/drm/tiny/st7735r.c - fb_ili9486.c: Patches are posted on dri-devel[3] But they don't support all panels based on that controller and they don't have parallel bus support. There is actually also another obstacle for conversion and that is, some of the displays (for which there is builtin driver support) might be impossible to source except as second hand. And it's not always obvious which panel is supported by a certain driver. At least the displays supported by these drivers are listed as discontinued on the fbtft wiki[4]: - fb_hx8340bn.c - fb_hx8347d.c - fb_ili9320 This one never made it from a prototype to an actual product, because it was too slow: - fb_watterott.c I have no plans to convert fbtft drivers myself, but I figured a 5 year anniversary was a good excuse for a status update. Noralf. [1] https://lkml.org/lkml/2015/9/24/253 [2] https://lkml.org/lkml/2016/11/23/146 [3] https://patchwork.freedesktop.org/series/72645/ [4] https://github.com/notro/fbtft/wiki/LCD-Modules#discontinued-products ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: fbtft: 5 years in staging
Hi Noralf On Sun, Feb 02, 2020 at 04:41:54PM +0100, Noralf Trønnes wrote: > Hi, > > Since I'm the original author of fbtft I thought I'd highlight a couple > of issues that's probably not well known. > > Right after fbtft was added, fbdev was closed for new drivers[1] and > the fbdev maintainer wanted to remove fbtft as a consequence of that > decision, but Greg KH said he'd keep fbtft drivers in staging > "until a matching DRM driver is present in the tree"[2]. > > There are 2 issues wrt the goal of making a matching DRM driver > (strictly speaking). One is impossible to do (policy), the other is > unlikely to happen: > > 1. Device Tree 'init' property > > All fbtft drivers have controller setup code that matches one > particular display panel. From the start of fbtft it was possible to > override this using platform data. Later when Device Tree support was > added, an 'init=' property to do the same was added. > > Example: > init = <0x1e5 0x78F0 > 0x101 0x0100 > 0x232 > 0x107 0x0133>; > > This translates to: > register_write(0x00e5, 0x78F0); > register_write(0x0001, 0x0100); > mdelay(32); > register_write(0x0007, 0x0133); > > AFAIU setting register values from DT is a no-go, so this functionality > can't be replicated in a DRM driver. Many displays are made to work > using this mechanism, in particular ili9341 based ones. > > 2. Parallel bus interface > > All fbtft drivers support both a SPI and a parallel bus interface > through the fbtft helper module. Many (not all) controllers support more > than one interface. The parallel bus support was added to fbtft in its > early days when not many SPI displays were available (nowadays there's > lots to choose from). fbtft uses bitbanging to drive the parallel > interface so it's really slow, even more slow than SPI and SPI with DMA > beats it thoroughly. I know there are people that use the paralell bus > support, but I don't see much point in it unless we get a parallel bus > subsystem that can use the dedicated hw on certain SoC's (Beaglebone, > Pi). And those SOC's most likely have a parallel video/RGB bus as well, > which IMO is a much better option for a panel. > > > The following drivers have DRM counterparts that have the same panel > setup code: > > - fb_hx8357d.c: drivers/gpu/drm/tiny/hx8357d.c > - fb_ili9341.c: drivers/gpu/drm/tiny/mi0283qt.c > - fb_st7735r.c: drivers/gpu/drm/tiny/st7735r.c > - fb_ili9486.c: Patches are posted on dri-devel[3] > > But they don't support all panels based on that controller and they > don't have parallel bus support. > > There is actually also another obstacle for conversion and that is, some > of the displays (for which there is builtin driver support) might be > impossible to source except as second hand. And it's not always obvious > which panel is supported by a certain driver. > At least the displays supported by these drivers are listed as > discontinued on the fbtft wiki[4]: > - fb_hx8340bn.c > - fb_hx8347d.c > - fb_ili9320 > > This one never made it from a prototype to an actual product, because > it was too slow: > - fb_watterott.c > > I have no plans to convert fbtft drivers myself, but I figured a 5 year > anniversary was a good excuse for a status update. Thanks for the history lesson and the status update, a very informative and interesting read. Thanks for all your work in this area! Sam > > Noralf. > > [1] https://lkml.org/lkml/2015/9/24/253 > [2] https://lkml.org/lkml/2016/11/23/146 > [3] https://patchwork.freedesktop.org/series/72645/ > [4] https://github.com/notro/fbtft/wiki/LCD-Modules#discontinued-products > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/2] staging: vt6656: Disable and remove fall back rates from driver.
The fall back rates are not properly implemented in driver and
form part of the legacy driver.
mac80211 has no indication that this is happening and it
does appear the driver does function considerably better
without them so remove them.
Signed-off-by: Malcolm Priestley
---
drivers/staging/vt6656/int.c | 38 ---
drivers/staging/vt6656/main_usb.c | 4
drivers/staging/vt6656/rxtx.c | 29 +--
3 files changed, 1 insertion(+), 70 deletions(-)
diff --git a/drivers/staging/vt6656/int.c b/drivers/staging/vt6656/int.c
index af215860be4c..3fa61c368464 100644
--- a/drivers/staging/vt6656/int.c
+++ b/drivers/staging/vt6656/int.c
@@ -23,22 +23,6 @@
#include "power.h"
#include "usbpipe.h"
-static const u8 fallback_rate0[5][5] = {
- {RATE_18M, RATE_18M, RATE_12M, RATE_12M, RATE_12M},
- {RATE_24M, RATE_24M, RATE_18M, RATE_12M, RATE_12M},
- {RATE_36M, RATE_36M, RATE_24M, RATE_18M, RATE_18M},
- {RATE_48M, RATE_48M, RATE_36M, RATE_24M, RATE_24M},
- {RATE_54M, RATE_54M, RATE_48M, RATE_36M, RATE_36M}
-};
-
-static const u8 fallback_rate1[5][5] = {
- {RATE_18M, RATE_18M, RATE_12M, RATE_6M, RATE_6M},
- {RATE_24M, RATE_24M, RATE_18M, RATE_6M, RATE_6M},
- {RATE_36M, RATE_36M, RATE_24M, RATE_12M, RATE_12M},
- {RATE_48M, RATE_48M, RATE_24M, RATE_12M, RATE_12M},
- {RATE_54M, RATE_54M, RATE_36M, RATE_18M, RATE_18M}
-};
-
int vnt_int_start_interrupt(struct vnt_private *priv)
{
int ret = 0;
@@ -59,7 +43,6 @@ static int vnt_int_report_rate(struct vnt_private *priv, u8
pkt_no, u8 tsr)
{
struct vnt_usb_send_context *context;
struct ieee80211_tx_info *info;
- struct ieee80211_rate *rate;
u8 tx_retry = (tsr & 0xf0) >> 4;
s8 idx;
@@ -74,27 +57,6 @@ static int vnt_int_report_rate(struct vnt_private *priv, u8
pkt_no, u8 tsr)
info = IEEE80211_SKB_CB(context->skb);
idx = info->control.rates[0].idx;
- if (context->fb_option && !(tsr & (TSR_TMO | TSR_RETRYTMO))) {
- u8 tx_rate;
- u8 retry = tx_retry;
-
- rate = ieee80211_get_tx_rate(priv->hw, info);
- tx_rate = rate->hw_value - RATE_18M;
-
- if (retry > 4)
- retry = 4;
-
- if (context->fb_option == AUTO_FB_0)
- tx_rate = fallback_rate0[tx_rate][retry];
- else if (context->fb_option == AUTO_FB_1)
- tx_rate = fallback_rate1[tx_rate][retry];
-
- if (info->band == NL80211_BAND_5GHZ)
- idx = tx_rate - RATE_6M;
- else
- idx = tx_rate;
- }
-
ieee80211_tx_info_clear_status(info);
info->status.rates[0].count = tx_retry;
diff --git a/drivers/staging/vt6656/main_usb.c
b/drivers/staging/vt6656/main_usb.c
index 6e5963adb501..9135aad0863d 100644
--- a/drivers/staging/vt6656/main_usb.c
+++ b/drivers/staging/vt6656/main_usb.c
@@ -99,7 +99,6 @@ static void vnt_set_options(struct vnt_private *priv)
priv->op_mode = NL80211_IFTYPE_UNSPECIFIED;
priv->bb_type = BBP_TYPE_DEF;
priv->packet_type = priv->bb_type;
- priv->auto_fb_ctrl = AUTO_FB_0;
priv->preamble_type = 0;
priv->exist_sw_net_addr = false;
}
@@ -261,9 +260,6 @@ static int vnt_init_registers(struct vnt_private *priv)
if (ret)
goto end;
- /* get Auto Fall Back type */
- priv->auto_fb_ctrl = AUTO_FB_0;
-
/* default Auto Mode */
priv->bb_type = BB_TYPE_11G;
diff --git a/drivers/staging/vt6656/rxtx.c b/drivers/staging/vt6656/rxtx.c
index 29caba728906..0fabeb396563 100644
--- a/drivers/staging/vt6656/rxtx.c
+++ b/drivers/staging/vt6656/rxtx.c
@@ -792,7 +792,7 @@ int vnt_tx_packet(struct vnt_private *priv, struct sk_buff
*skb)
struct vnt_usb_send_context *tx_context;
unsigned long flags;
u16 tx_bytes, tx_header_size, tx_body_size, current_rate, duration_id;
- u8 pkt_type, fb_option = AUTO_FB_NONE;
+ u8 pkt_type;
bool need_rts = false;
bool need_mic = false;
@@ -912,33 +912,6 @@ int vnt_tx_packet(struct vnt_private *priv, struct sk_buff
*skb)
tx_buffer_head->current_rate = cpu_to_le16(current_rate);
- /* legacy rates TODO use ieee80211_tx_rate */
- if (current_rate >= RATE_18M && ieee80211_is_data(hdr->frame_control)) {
- if (priv->auto_fb_ctrl == AUTO_FB_0) {
- tx_buffer_head->fifo_ctl |=
- cpu_to_le16(FIFOCTL_AUTO_FB_0);
-
- priv->tx_rate_fb0 =
- vnt_fb_opt0[FB_RATE0][current_rate - RATE_18M];
- priv->tx_rate_fb1 =
- vnt_fb_opt0[FB_RATE1][current_rate - RATE_18M];
-
- fb_option = AUTO_FB_0;
- } else if (priv
[PATCH 2/2] staging: vt6656: Remove fall back functions and headers.
Fall back is no longer used in driver so remove all
functions and headers.
Signed-off-by: Malcolm Priestley
---
drivers/staging/vt6656/device.h | 1 -
drivers/staging/vt6656/rxtx.c | 206
drivers/staging/vt6656/rxtx.h | 60 --
3 files changed, 267 deletions(-)
diff --git a/drivers/staging/vt6656/device.h b/drivers/staging/vt6656/device.h
index fe6c11266123..da868adba7c9 100644
--- a/drivers/staging/vt6656/device.h
+++ b/drivers/staging/vt6656/device.h
@@ -244,7 +244,6 @@ struct vnt_usb_send_context {
u8 pkt_no;
u8 pkt_type;
u8 need_ack;
- u8 fb_option;
bool in_use;
unsigned char data[MAX_TOTAL_SIZE_WITH_ALL_HEADERS];
};
diff --git a/drivers/staging/vt6656/rxtx.c b/drivers/staging/vt6656/rxtx.c
index 0fabeb396563..74c1062dbaaa 100644
--- a/drivers/staging/vt6656/rxtx.c
+++ b/drivers/staging/vt6656/rxtx.c
@@ -39,30 +39,12 @@ static const u16 vnt_time_stampoff[2][MAX_RATE] = {
{384, 192, 130, 113, 54, 43, 37, 31, 28, 25, 24, 23},
};
-static const u16 vnt_fb_opt0[2][5] = {
- {RATE_12M, RATE_18M, RATE_24M, RATE_36M, RATE_48M}, /* fallback_rate0 */
- {RATE_12M, RATE_12M, RATE_18M, RATE_24M, RATE_36M}, /* fallback_rate1 */
-};
-
-static const u16 vnt_fb_opt1[2][5] = {
- {RATE_12M, RATE_18M, RATE_24M, RATE_24M, RATE_36M}, /* fallback_rate0 */
- {RATE_6M, RATE_6M, RATE_12M, RATE_12M, RATE_18M}, /* fallback_rate1 */
-};
-
#define RTSDUR_BB 0
#define RTSDUR_BA 1
#define RTSDUR_AA 2
#define CTSDUR_BA 3
-#define RTSDUR_BA_F04
-#define RTSDUR_AA_F05
-#define RTSDUR_BA_F16
-#define RTSDUR_AA_F17
-#define CTSDUR_BA_F08
-#define CTSDUR_BA_F19
#define DATADUR_B 10
#define DATADUR_A 11
-#define DATADUR_A_F012
-#define DATADUR_A_F113
static struct vnt_usb_send_context
*vnt_get_free_context(struct vnt_private *priv)
@@ -216,8 +198,6 @@ static __le16 vnt_get_rtscts_duration_le(struct
vnt_usb_send_context *context,
switch (dur_type) {
case RTSDUR_BB:
case RTSDUR_BA:
- case RTSDUR_BA_F0:
- case RTSDUR_BA_F1:
cts_time = vnt_get_frame_time(priv->preamble_type, pkt_type,
14, priv->top_cck_basic_rate);
dur_time = cts_time + 2 * priv->sifs +
@@ -226,8 +206,6 @@ static __le16 vnt_get_rtscts_duration_le(struct
vnt_usb_send_context *context,
break;
case RTSDUR_AA:
- case RTSDUR_AA_F0:
- case RTSDUR_AA_F1:
cts_time = vnt_get_frame_time(priv->preamble_type, pkt_type,
14, priv->top_ofdm_basic_rate);
dur_time = cts_time + 2 * priv->sifs +
@@ -236,8 +214,6 @@ static __le16 vnt_get_rtscts_duration_le(struct
vnt_usb_send_context *context,
break;
case CTSDUR_BA:
- case CTSDUR_BA_F0:
- case CTSDUR_BA_F1:
dur_time = priv->sifs + vnt_get_rsvtime(priv,
pkt_type, frame_length, rate, need_ack);
break;
@@ -297,63 +273,6 @@ static u16 vnt_rxtx_datahead_g(struct vnt_usb_send_context
*tx_context,
return le16_to_cpu(buf->duration_a);
}
-static u16 vnt_rxtx_datahead_g_fb(struct vnt_usb_send_context *tx_context,
- struct vnt_tx_datahead_g_fb *buf)
-{
- struct vnt_private *priv = tx_context->priv;
- u32 frame_len = tx_context->frame_len;
- u16 rate = tx_context->tx_rate;
- u8 need_ack = tx_context->need_ack;
-
- /* Get SignalField,ServiceField,Length */
- vnt_get_phy_field(priv, frame_len, rate, tx_context->pkt_type, &buf->a);
-
- vnt_get_phy_field(priv, frame_len, priv->top_cck_basic_rate,
- PK_TYPE_11B, &buf->b);
-
- /* Get Duration and TimeStamp */
- buf->duration_a = vnt_get_duration_le(priv, tx_context->pkt_type,
- need_ack);
- buf->duration_b = vnt_get_duration_le(priv, PK_TYPE_11B, need_ack);
-
- buf->duration_a_f0 = vnt_get_duration_le(priv, tx_context->pkt_type,
-need_ack);
- buf->duration_a_f1 = vnt_get_duration_le(priv, tx_context->pkt_type,
-need_ack);
-
- buf->time_stamp_off_a = vnt_time_stamp_off(priv, rate);
- buf->time_stamp_off_b = vnt_time_stamp_off(priv,
- priv->top_cck_basic_rate);
-
- tx_context->tx_hdr_size = vnt_mac_hdr_pos(tx_context, &buf->hdr);
-
- return le16_to_cpu(buf->duration_a);
-}
-
-static u16 vnt_rxtx_datahead_a_fb(struct vnt_usb_send_context *tx_context,
- struct vnt_tx_datahead_a_fb *buf)
-{
- struct vnt_private *priv = tx_context->priv;
- u16 rate = tx_context->tx_rate;
- u8 pkt_ty
[PATCH] staging: android: Delete the 'vsoc' driver
The 'vsoc' driver was required for an early iteration of the Android 'cuttlefish' virtual platform, but this platform has been wholly converted to use virtio drivers instead. Delete this old driver. Cc: Greg Kroah-Hartman Cc: Joel Fernandes Cc: Greg Hartman Cc: kernel-t...@android.com Cc: de...@driverdev.osuosl.org Signed-off-by: Alistair Delva --- drivers/staging/android/Kconfig |8 - drivers/staging/android/Makefile|1 - drivers/staging/android/TODO|9 - drivers/staging/android/uapi/vsoc_shm.h | 295 -- drivers/staging/android/vsoc.c | 1149 --- 5 files changed, 1462 deletions(-) delete mode 100644 drivers/staging/android/uapi/vsoc_shm.h delete mode 100644 drivers/staging/android/vsoc.c diff --git a/drivers/staging/android/Kconfig b/drivers/staging/android/Kconfig index d6d605d5cbde..8d8fd5c29349 100644 --- a/drivers/staging/android/Kconfig +++ b/drivers/staging/android/Kconfig @@ -14,14 +14,6 @@ config ASHMEM It is, in theory, a good memory allocator for low-memory devices, because it can discard shared memory units when under memory pressure. -config ANDROID_VSOC - tristate "Android Virtual SoC support" - depends on PCI_MSI - help - This option adds support for the Virtual SoC driver needed to boot - a 'cuttlefish' Android image inside QEmu. The driver interacts with - a QEmu ivshmem device. If built as a module, it will be called vsoc. - source "drivers/staging/android/ion/Kconfig" endif # if ANDROID diff --git a/drivers/staging/android/Makefile b/drivers/staging/android/Makefile index 14bd9c6ce10d..3b66cd0b0ec5 100644 --- a/drivers/staging/android/Makefile +++ b/drivers/staging/android/Makefile @@ -4,4 +4,3 @@ ccflags-y += -I$(src) # needed for trace events obj-y += ion/ obj-$(CONFIG_ASHMEM) += ashmem.o -obj-$(CONFIG_ANDROID_VSOC) += vsoc.o diff --git a/drivers/staging/android/TODO b/drivers/staging/android/TODO index 767dd98fd92d..80eccfaf6db5 100644 --- a/drivers/staging/android/TODO +++ b/drivers/staging/android/TODO @@ -9,14 +9,5 @@ ion/ - Split /dev/ion up into multiple nodes (e.g. /dev/ion/heap0) - Better test framework (integration with VGEM was suggested) -vsoc.c, uapi/vsoc_shm.h - - The current driver uses the same wait queue for all of the futexes in a - region. This will cause false wakeups in regions with a large number of - waiting threads. We should eventually use multiple queues and select the - queue based on the region. - - Add debugfs support for examining the permissions of regions. - - Remove VSOC_WAIT_FOR_INCOMING_INTERRUPT ioctl. This functionality has been - superseded by the futex and is there for legacy reasons. - Please send patches to Greg Kroah-Hartman and Cc: Arve Hjønnevåg and Riley Andrews diff --git a/drivers/staging/android/uapi/vsoc_shm.h b/drivers/staging/android/uapi/vsoc_shm.h deleted file mode 100644 index 6291fb24efb2.. --- a/drivers/staging/android/uapi/vsoc_shm.h +++ /dev/null @@ -1,295 +0,0 @@ -/* SPDX-License-Identifier: GPL-2.0 */ -/* - * Copyright (C) 2017 Google, Inc. - * - */ - -#ifndef _UAPI_LINUX_VSOC_SHM_H -#define _UAPI_LINUX_VSOC_SHM_H - -#include - -/** - * A permission is a token that permits a receiver to read and/or write an area - * of memory within a Vsoc region. - * - * An fd_scoped permission grants both read and write access, and can be - * attached to a file description (see open(2)). - * Ownership of the area can then be shared by passing a file descriptor - * among processes. - * - * begin_offset and end_offset define the area of memory that is controlled by - * the permission. owner_offset points to a word, also in shared memory, that - * controls ownership of the area. - * - * ownership of the region expires when the associated file description is - * released. - * - * At most one permission can be attached to each file description. - * - * This is useful when implementing HALs like gralloc that scope and pass - * ownership of shared resources via file descriptors. - * - * The caller is responsibe for doing any fencing. - * - * The calling process will normally identify a currently free area of - * memory. It will construct a proposed fd_scoped_permission_arg structure: - * - * begin_offset and end_offset describe the area being claimed - * - * owner_offset points to the location in shared memory that indicates the - * owner of the area. - * - * owned_value is the value that will be stored in owner_offset iff the - * permission can be granted. It must be different than VSOC_REGION_FREE. - * - * Two fd_scoped_permission structures are compatible if they vary only by - * their owned_value fields. - * - * The driver ensures that, for any group of simultaneous callers proposing - * compatible fd_scoped_permissions, it will accept exactly one of the - * propopsals.
