[PATCH] staging: rtl8723bs: remove some variables in hal_btcoex.c
Fix the following gcc warning:
drivers/staging/rtl8723bs/hal/hal_btcoex.c:45:26: warning: ‘ioStaString’
defined but not used [-Wunused-const-variable=]
static const char *const ioStaString[] = {
^~~
drivers/staging/rtl8723bs/hal/hal_btcoex.c:38:26: warning:
‘h2cStaString’ defined but not used [-Wunused-const-variable=]
static const char *const h2cStaString[] = {
^~~~
drivers/staging/rtl8723bs/hal/hal_btcoex.c:33:26: warning:
‘BtLinkRoleString’ defined but not used [-Wunused-const-variable=]
static const char *const BtLinkRoleString[] = {
^~~~
drivers/staging/rtl8723bs/hal/hal_btcoex.c:23:26: warning:
‘BtSpecString’ defined but not used [-Wunused-const-variable=]
static const char *const BtSpecString[] = {
^~~~
drivers/staging/rtl8723bs/hal/hal_btcoex.c:15:26: warning:
‘BtProfileString’ defined but not used [-Wunused-const-variable=]
static const char *const BtProfileString[] = {
^~~
Reported-by: Hulk Robot
Signed-off-by: Jason Yan
---
drivers/staging/rtl8723bs/hal/hal_btcoex.c | 43 --
1 file changed, 43 deletions(-)
diff --git a/drivers/staging/rtl8723bs/hal/hal_btcoex.c
b/drivers/staging/rtl8723bs/hal/hal_btcoex.c
index d5793e4614bf..a6ed1bb9945e 100644
--- a/drivers/staging/rtl8723bs/hal/hal_btcoex.c
+++ b/drivers/staging/rtl8723bs/hal/hal_btcoex.c
@@ -12,49 +12,6 @@
#include
/* Global variables */
-static const char *const BtProfileString[] = {
- "NONE",
- "A2DP",
- "PAN",
- "HID",
- "SCO",
-};
-
-static const char *const BtSpecString[] = {
- "1.0b",
- "1.1",
- "1.2",
- "2.0+EDR",
- "2.1+EDR",
- "3.0+HS",
- "4.0",
-};
-
-static const char *const BtLinkRoleString[] = {
- "Master",
- "Slave",
-};
-
-static const char *const h2cStaString[] = {
- "successful",
- "h2c busy",
- "rf off",
- "fw not read",
-};
-
-static const char *const ioStaString[] = {
- "success",
- "can not IO",
- "rf off",
- "fw not read",
- "wait io timeout",
- "invalid len",
- "idle Q empty",
- "insert waitQ fail",
- "unknown fail",
- "wrong level",
- "h2c stopped",
-};
BTC_COEXIST GLBtCoexist;
static u8 GLBtcWiFiInScanState;
--
2.21.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: rtl8723bs: remove defined but not used 'dB_Invert_Table'
Fix the following gcc warning:
drivers/staging/rtl8723bs/hal/odm.c:10:18: warning: ‘dB_Invert_Table’
defined but not used [-Wunused-const-variable=]
static const u16 dB_Invert_Table[8][12] = {
^~~
Reported-by: Hulk Robot
Signed-off-by: Jason Yan
---
drivers/staging/rtl8723bs/hal/odm.c | 13 -
1 file changed, 13 deletions(-)
diff --git a/drivers/staging/rtl8723bs/hal/odm.c
b/drivers/staging/rtl8723bs/hal/odm.c
index aa6631ee4ea7..f2a9e95a1563 100644
--- a/drivers/staging/rtl8723bs/hal/odm.c
+++ b/drivers/staging/rtl8723bs/hal/odm.c
@@ -7,19 +7,6 @@
#include "odm_precomp.h"
-static const u16 dB_Invert_Table[8][12] = {
- {1, 1, 1, 2, 2, 2, 2, 3, 3, 3, 4, 4},
- {4, 5, 6, 6, 7, 8, 9, 10, 11, 13, 14, 16},
- {18, 20, 22, 25, 28, 32, 35, 40, 45, 50, 56, 63},
- {71, 79, 89, 100, 112, 126, 141, 158, 178, 200, 224, 251},
- {282, 316, 355, 398, 447, 501, 562, 631, 708, 794, 891, 1000},
- {1122, 1259, 1413, 1585, 1778, 1995, 2239, 2512, 2818, 3162, 3548,
3981},
- {4467, 5012, 5623, 6310, 7079, 7943, 8913, 1, 11220, 12589, 14125,
-15849},
- {17783, 19953, 22387, 25119, 28184, 31623, 35481, 39811, 44668, 50119,
-56234, 65535}
- };
-
/* Global var */
u32 OFDMSwingTable[OFDM_TABLE_SIZE] = {
--
2.21.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 7/9] media: MAINTAINERS: rkisp1: add path to dt-bindings
On 03/04/2020 18:15, Helen Koike wrote: > The Rockchip ISP bindings was moved out of staging. > Update MAINTAINERS file with the new path. Shouldn't there be a reference to Documentation/devicetree/bindings/phy/rockchip-mipi-dphy-rx0.yaml as well in MAINTAINERS? Regards, Hans > > Suggested-by: Johan Jonker > Signed-off-by: Helen Koike > --- > > V2: > - This is a new patch in the series > --- > MAINTAINERS | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index d66ac41ef5872..726044b84cf23 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -14303,6 +14303,7 @@ M:Helen Koike > L: linux-me...@vger.kernel.org > S: Maintained > F: drivers/staging/media/rkisp1/ > +F: Documentation/devicetree/bindings/media/rockchip-isp1.yaml > > ROCKCHIP RASTER 2D GRAPHIC ACCELERATION UNIT DRIVER > M: Jacob Chen > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 7/9] media: MAINTAINERS: rkisp1: add path to dt-bindings
On Fri, 2020-04-17 at 09:18 +0200, Hans Verkuil wrote: > On 03/04/2020 18:15, Helen Koike wrote: > > The Rockchip ISP bindings was moved out of staging. > > Update MAINTAINERS file with the new path. > > Shouldn't there be a reference to > Documentation/devicetree/bindings/phy/rockchip-mipi-dphy-rx0.yaml > as well in MAINTAINERS? And please keep the file references F: fields in alphabetic order. > > diff --git a/MAINTAINERS b/MAINTAINERS [] > > @@ -14303,6 +14303,7 @@ M: Helen Koike > > L: linux-me...@vger.kernel.org > > S: Maintained > > F: drivers/staging/media/rkisp1/ > > +F: Documentation/devicetree/bindings/media/rockchip-isp1.yaml > > > > ROCKCHIP RASTER 2D GRAPHIC ACCELERATION UNIT DRIVER > > M: Jacob Chen > > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
INQUIRY
Hello I am Ms. evangeline mulay from Rej888 Int'l Trading Inc.I am the Commercial Manager. We are glad to see that you are a dealer in some of the products we are interested on and we are looking to get a new supplier who can be able to meet up with our current buying demands but first we need answers to the questions below if 1.You Can ship to Phillipines 2.Product list 3. Advice on payment terms warranty. 4. The Minimum Order Quantity (M.O.Q) and Delivery time for F.O.B. I would appreciate your response about the above questions so we can proceed with the items needed. Expecting your urgent immediate feedback. Thanks. contact person :Ms. evangeline mulay Commercial Manager of Rej888 Int'l Trading Inc. 10th st. mabalacat pampanga Zip Code:2010 Philippines T:63-815-6316562 F:63-8013-802091 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
INQUIRY
Hello I am Ms. evangeline mulay from Rej888 Int'l Trading Inc.I am the Commercial Manager. We are glad to see that you are a dealer in some of the products we are interested on and we are looking to get a new supplier who can be able to meet up with our current buying demands but first we need answers to the questions below if 1.You Can ship to Phillipines 2.Product list 3. Advice on payment terms warranty. 4. The Minimum Order Quantity (M.O.Q) and Delivery time for F.O.B. I would appreciate your response about the above questions so we can proceed with the items needed. Expecting your urgent immediate feedback. Thanks. contact person :Ms. evangeline mulay Commercial Manager of Rej888 Int'l Trading Inc. 10th st. mabalacat pampanga Zip Code:2010 Philippines T:63-815-6316562 F:63-8013-802091 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
INQUIRY
Hello I am Ms. evangeline mulay from Rej888 Int'l Trading Inc.I am the Commercial Manager. We are glad to see that you are a dealer in some of the products we are interested on and we are looking to get a new supplier who can be able to meet up with our current buying demands but first we need answers to the questions below if 1.You Can ship to Phillipines 2.Product list 3. Advice on payment terms warranty. 4. The Minimum Order Quantity (M.O.Q) and Delivery time for F.O.B. I would appreciate your response about the above questions so we can proceed with the items needed. Expecting your urgent immediate feedback. Thanks. contact person :Ms. evangeline mulay Commercial Manager of Rej888 Int'l Trading Inc. 10th st. mabalacat pampanga Zip Code:2010 Philippines T:63-815-6316562 F:63-8013-802091 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: android: ion: Skip sync if not mapped
On Thu, Apr 16, 2020 at 12:25:08PM +0200, Greg Kroah-Hartman wrote:
> On Tue, Apr 14, 2020 at 09:41:31PM -0700, John Stultz wrote:
> > On Tue, Apr 14, 2020 at 7:28 AM Greg Kroah-Hartman
> > wrote:
> > >
> > > On Tue, Apr 14, 2020 at 04:18:47PM +0200, Ørjan Eide wrote:
> > > > Only sync the sg-list of an Ion dma-buf attachment when the attachment
> > > > is actually mapped on the device.
> > > >
> > > > dma-bufs may be synced at any time. It can be reached from user space
> > > > via DMA_BUF_IOCTL_SYNC, so there are no guarantees from callers on when
> > > > syncs may be attempted, and dma_buf_end_cpu_access() and
> > > > dma_buf_begin_cpu_access() may not be paired.
> > > >
> > > > Since the sg_list's dma_address isn't set up until the buffer is used
> > > > on the device, and dma_map_sg() is called on it, the dma_address will be
> > > > NULL if sync is attempted on the dma-buf before it's mapped on a device.
> > > >
> > > > Before v5.0 (commit 55897af63091 ("dma-direct: merge swiotlb_dma_ops
> > > > into the dma_direct code")) this was a problem as the dma-api (at least
> > > > the swiotlb_dma_ops on arm64) would use the potentially invalid
> > > > dma_address. How that failed depended on how the device handled physical
> > > > address 0. If 0 was a valid address to physical ram, that page would get
> > > > flushed a lot, while the actual pages in the buffer would not get synced
> > > > correctly. While if 0 is an invalid physical address it may cause a
> > > > fault and trigger a crash.
> > > >
> > > > In v5.0 this was incidentally fixed by commit 55897af63091 ("dma-direct:
> > > > merge swiotlb_dma_ops into the dma_direct code"), as this moved the
> > > > dma-api to use the page pointer in the sg_list, and (for Ion buffers at
> > > > least) this will always be valid if the sg_list exists at all.
> > > >
> > > > But, this issue is re-introduced in v5.3 with
> > > > commit 449fa54d6815 ("dma-direct: correct the physical addr in
> > > > dma_direct_sync_sg_for_cpu/device") moves the dma-api back to the old
> > > > behaviour and picks the dma_address that may be invalid.
> > > >
> > > > dma-buf core doesn't ensure that the buffer is mapped on the device, and
> > > > thus have a valid sg_list, before calling the exporter's
> > > > begin_cpu_access.
> > > >
> > > > Signed-off-by: Ørjan Eide
> > > > ---
> > > > drivers/staging/android/ion/ion.c | 12
> > > > 1 file changed, 12 insertions(+)
> > > >
> > > > Resubmit without disclaimer, sorry about that.
> > > >
> > > > This seems to be part of a bigger issue where dma-buf exporters assume
> > > > that their dma-buf begin_cpu_access and end_cpu_access callbacks have a
> > > > certain guaranteed behavior, which isn't ensured by dma-buf core.
> > > >
> > > > This patch fixes this in ion only, but it also needs to be fixed for
> > > > other exporters, either handled like this in each exporter, or in
> > > > dma-buf core before calling into the exporters.
> > > >
> > > > diff --git a/drivers/staging/android/ion/ion.c
> > > > b/drivers/staging/android/ion/ion.c
> > > > index 38b51eace4f9..7b752ba0cb6d 100644
> > > > --- a/drivers/staging/android/ion/ion.c
> > > > +++ b/drivers/staging/android/ion/ion.c
> > >
> > > Now that we have the dma-buff stuff in the tree, do we even need the
> > > ion code in the kernel anymore? Can't we delete it now?
> > >
> >
> > I agree that we shouldn't be taking further (non-security/cleanup)
> > patches to the ION code.
> >
> > I'd like to give developers a little bit of a transition period (I was
> > thinking a year, but really just one LTS release that has both would
> > do) where they can move their ION heaps over to dmabuf heaps and test
> > both against the same tree.
> >
> > But I do think we can mark it as deprecated and let folks know that
> > around the end of the year it will be deleted.
>
> No one ever notices "depreciated" things, they only notice if the code
> is no longer there :)
>
> So I'm all for just deleting it and seeing who even notices...
+1 on just deleting ion and watching if anyone notices. In case you're
typing that patch, here's my:
Acked-by: Daniel Vetter
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
