[PATCH 0/2] mmc: rtsx: fix incorrect last byte in R2 response
From: Roger Tseng
(The original patch for PCI and USB was splitted here to make it easier for
stable tree.)
Current code erroneously fill the last byte of R2 response with an undefined
value. In addition, the controller actually 'offloads' the last byte
(CRC7, end bit) while receiving R2 response and thus it's impossible to get the
actual value. This could cause mmc stack to obtain inconsistent CID from the
same card after resume and misidentify it as a different card.
Fix by assigning dummy CRC and end bit: {7'b0, 1} = 0x1 to the last byte of R2.
Roger Tseng (2):
mmc: rtsx_pci_sdmmc: fix incorrect last byte in R2 response
mmc: rtsx_usb_sdmmc: fix incorrect last byte in R2 response
drivers/mmc/host/rtsx_pci_sdmmc.c |7 +++
drivers/mmc/host/rtsx_usb_sdmmc.c |7 +++
2 files changed, 14 insertions(+)
--
1.7.10.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 2/2] mmc: rtsx_usb_sdmmc: fix incorrect last byte in R2 response
From: Roger Tseng
Current code erroneously fill the last byte of R2 response with an undefined
value. In addition, the controller actually 'offloads' the last byte
(CRC7, end bit) while receiving R2 response and thus it's impossible to get the
actual value. This could cause mmc stack to obtain inconsistent CID from the
same card after resume and misidentify it as a different card.
Fix by assigning dummy CRC and end bit: {7'b0, 1} = 0x1 to the last byte of R2.
Cc: # v3.16+
Fixes: c7f6558d84af ("mmc: Add realtek USB sdmmc host driver")
Signed-off-by: Roger Tseng
---
drivers/mmc/host/rtsx_usb_sdmmc.c |7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/mmc/host/rtsx_usb_sdmmc.c
b/drivers/mmc/host/rtsx_usb_sdmmc.c
index 5d3766e792f0..d9153a7d160d 100644
--- a/drivers/mmc/host/rtsx_usb_sdmmc.c
+++ b/drivers/mmc/host/rtsx_usb_sdmmc.c
@@ -435,6 +435,13 @@ static void sd_send_cmd_get_rsp(struct rtsx_usb_sdmmc
*host,
}
if (rsp_type == SD_RSP_TYPE_R2) {
+ /*
+* The controller offloads the last byte {CRC-7, end bit 1'b1}
+* of response type R2. Assign dummy CRC, 0, and end bit to the
+* byte(ptr[16], goes into the LSB of resp[3] later).
+*/
+ ptr[16] = 1;
+
for (i = 0; i < 4; i++) {
cmd->resp[i] = get_unaligned_be32(ptr + 1 + i * 4);
dev_dbg(sdmmc_dev(host), "cmd->resp[%d] = 0x%08x\n",
--
1.7.10.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/2] mmc: rtsx_pci_sdmmc: fix incorrect last byte in R2 response
From: Roger Tseng
Current code erroneously fill the last byte of R2 response with an undefined
value. In addition, the controller actually 'offloads' the last byte
(CRC7, end bit) while receiving R2 response and thus it's impossible to get the
actual value. This could cause mmc stack to obtain inconsistent CID from the
same card after resume and misidentify it as a different card.
Fix by assigning dummy CRC and end bit: {7'b0, 1} = 0x1 to the last byte of R2.
Cc: # v3.8+
Fixes: ff984e57d36e ("mmc: Add realtek pcie sdmmc host driver")
Signed-off-by: Roger Tseng
---
drivers/mmc/host/rtsx_pci_sdmmc.c |7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/mmc/host/rtsx_pci_sdmmc.c
b/drivers/mmc/host/rtsx_pci_sdmmc.c
index dfde4a210238..b2537e2f26b1 100644
--- a/drivers/mmc/host/rtsx_pci_sdmmc.c
+++ b/drivers/mmc/host/rtsx_pci_sdmmc.c
@@ -412,6 +412,13 @@ static void sd_send_cmd_get_rsp(struct realtek_pci_sdmmc
*host,
}
if (rsp_type == SD_RSP_TYPE_R2) {
+ /*
+* The controller offloads the last byte {CRC-7, end bit 1'b1}
+* of response type R2. Assign dummy CRC, 0, and end bit to the
+* byte(ptr[16], goes into the LSB of resp[3] later).
+*/
+ ptr[16] = 1;
+
for (i = 0; i < 4; i++) {
cmd->resp[i] = get_unaligned_be32(ptr + 1 + i * 4);
dev_dbg(sdmmc_dev(host), "cmd->resp[%d] = 0x%08x\n",
--
1.7.10.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [GIT PULL] Staging driver patches for 3.17-rc1
Hi, late reply due to fatal environment failure, sorry. On Mon, Aug 04, 2014 at 09:31:43PM -0700, Greg KH wrote: > On Tue, Aug 05, 2014 at 06:13:25AM +0200, Andreas Mohr wrote: > > Oh well, yet another driver where it became more difficult rather than > > easier to make forward progress. > > If you are willing to do the work, I will gladly revert the patch and > look forward to patches to fix the remaining changes. I've now done further device/driver research and it looks like this course of action was actually best: the keucr driver was duplicate/improved functionality of the ene_ub6250.c driver, with some extended card type support then relocated into ene_ub6250.c. The card type relocation work that's still missing is SmartMedia, but then I do have SM cards and would thus be able to test it. Thus the duplicated keucr driver could probably stay removed, with the penalty of having SM support lost at the moment (since one had to switch drivers anyway it's uncertain whether that's much of a loss). The driver also seems to be missing several USB IDs, as seen from IDs in keucr and Windows .inf file. Also, firmware files are very old compared to content in current Windows driver (but it remains to be seen whether new binaries remained compatible with an old unchanged driver handling, especially given that on Windows the firmware data is usefully(?) shipped right next to it, within the same binary). I'd like to definitely mention here that this particular device might be well worth improving, since as opposed to many other USB-based readers it has a custom programming interface plus external firmware data, which could mean that we might be able to add support for CompactFlash SMART readout and/or SD card Card Information Struct readout, on an external USB-based(!) reader. I will have more time in the near future, thus I should be able to work on some of these items - after having completed some other pending driver submissions that is :-P Andreas Mohr -- GNU/Linux. It's not the software that's free, it's you. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/1] staging: dgnc: brace checkpatch fixes
Bring braces in line with CodingStyle
Signed-off-by: Aaron Brice
---
Applies to next-20140814
drivers/staging/dgnc/dgnc_neo.c | 10 --
drivers/staging/dgnc/dgnc_sysfs.c | 6 ++
drivers/staging/dgnc/dgnc_tty.c | 38 +++---
3 files changed, 17 insertions(+), 37 deletions(-)
diff --git a/drivers/staging/dgnc/dgnc_neo.c b/drivers/staging/dgnc/dgnc_neo.c
index 68ff116..8fd6c2d 100644
--- a/drivers/staging/dgnc/dgnc_neo.c
+++ b/drivers/staging/dgnc/dgnc_neo.c
@@ -1800,9 +1800,8 @@ static uint neo_get_uart_bytes_left(struct channel_t *ch)
/* Determine whether the Transmitter is empty or not */
if (!(lsr & UART_LSR_TEMT)) {
- if (ch->ch_flags & CH_TX_FIFO_EMPTY) {
+ if (ch->ch_flags & CH_TX_FIFO_EMPTY)
tasklet_schedule(&ch->ch_bd->helper_tasklet);
- }
left = 1;
} else {
ch->ch_flags |= (CH_TX_FIFO_EMPTY | CH_TX_FIFO_LWM);
@@ -1927,10 +1926,9 @@ static void neo_vpd(struct dgnc_board *brd)
brd->vpd[(i*2)+1] = (a >> 8) & 0xff;
}
- if (((brd->vpd[0x08] != 0x82) /* long resource name tag */
- && (brd->vpd[0x10] != 0x82)) /* long resource name tag
(PCI-66 files)*/
- || (brd->vpd[0x7F] != 0x78)) /* small resource end tag */
- {
+ if (((brd->vpd[0x08] != 0x82) /* long resource name tag */
+ && (brd->vpd[0x10] != 0x82)) /* long resource name
tag (PCI-66 files)*/
+ || (brd->vpd[0x7F] != 0x78)) { /* small resource end
tag */
memset(brd->vpd, '\0', NEO_VPD_IMAGESIZE);
} else {
/* Search for the serial number */
diff --git a/drivers/staging/dgnc/dgnc_sysfs.c
b/drivers/staging/dgnc/dgnc_sysfs.c
index 3f321bb..9fdca39 100644
--- a/drivers/staging/dgnc/dgnc_sysfs.c
+++ b/drivers/staging/dgnc/dgnc_sysfs.c
@@ -130,9 +130,8 @@ void dgnc_create_driver_sysfiles(struct pci_driver
*dgnc_driver)
rc |= driver_create_file(driverfs, &driver_attr_pollrate);
rc |= driver_create_file(driverfs, &driver_attr_pollcounter);
rc |= driver_create_file(driverfs, &driver_attr_state);
- if (rc) {
+ if (rc)
printk(KERN_ERR "DGNC: sysfs driver_create_file failed!\n");
- }
}
@@ -403,9 +402,8 @@ void dgnc_create_ports_sysfiles(struct dgnc_board *bd)
rc |= device_create_file(&(bd->pdev->dev), &dev_attr_ports_txcount);
rc |= device_create_file(&(bd->pdev->dev), &dev_attr_vpd);
rc |= device_create_file(&(bd->pdev->dev), &dev_attr_serial_number);
- if (rc) {
+ if (rc)
printk(KERN_ERR "DGNC: sysfs device_create_file failed!\n");
- }
}
diff --git a/drivers/staging/dgnc/dgnc_tty.c b/drivers/staging/dgnc/dgnc_tty.c
index c712b43..1485110 100644
--- a/drivers/staging/dgnc/dgnc_tty.c
+++ b/drivers/staging/dgnc/dgnc_tty.c
@@ -92,8 +92,7 @@ static struct digi_t dgnc_digi_init = {
* This defines a raw port at 9600 baud, 8 data bits, no parity,
* 1 stop bit.
*/
-static struct ktermios DgncDefaultTermios =
-{
+static struct ktermios DgncDefaultTermios = {
.c_iflag = (DEFAULT_IFLAGS), /* iflags */
.c_oflag = (DEFAULT_OFLAGS), /* oflags */
.c_cflag = (DEFAULT_CFLAGS), /* cflags */
@@ -895,8 +894,7 @@ void dgnc_carrier(struct channel_t *ch)
* "make pretend that carrier is there".
*/
if ((virt_carrier == 0) && ((ch->ch_flags & CH_CD) != 0) &&
- (phys_carrier == 0))
- {
+ (phys_carrier == 0)) {
/*
* When carrier drops:
@@ -1043,10 +1041,7 @@ void dgnc_check_queue_flow_control(struct channel_t *ch)
DPR_READ(("Sending stop char! Times sent:
%x\n", ch->ch_stops_sent));
}
}
- /* No FLOW */
- else {
- /* Empty... Can't do anything about the impending
overflow... */
- }
+ /* No FLOW -- Empty... Can't do anything about the impending
overflow... */
}
/*
@@ -1080,10 +1075,7 @@ void dgnc_check_queue_flow_control(struct channel_t *ch)
ch->ch_bd->bd_ops->send_start_character(ch);
DPR_READ(("Sending start char!\n"));
}
- /* No FLOW */
- else {
- /* Nothing needed. */
- }
+ /* No FLOW -- Nothing needed. */
}
}
@@ -1112,8 +1104,7 @@ void dgnc_wakeup_writes(struct channel_t *ch)
if (ch->ch_
Thu, Aug 14, 2014
Greetings, I am a Financial Consultant with the HFC Bank Limited in Ghana I am in control of privately owned funds placed for long term investments. Our interest is to fund projects in form of Loan. Viable projects ranging from 1-500 Million USD would be funded at a guaranteed 3% Fixed Interest Rate per annum. If you have credible projects for investments or business clients in need of funds to expand existing projects, we would be obliged to work with you. Regards, Asare Akuffo ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH net-next,v2] hyperv: Increase the buffer length for netvsc_channel_cb()
> -Original Message- > From: David Miller [mailto:da...@redhat.com] > Sent: Thursday, August 14, 2014 5:29 PM > To: Haiyang Zhang > Cc: net...@vger.kernel.org; KY Srinivasan; o...@aepfle.de; > jasow...@redhat.com; linux-ker...@vger.kernel.org; driverdev- > de...@linuxdriverproject.org > Subject: Re: [PATCH net-next,v2] hyperv: Increase the buffer length for > netvsc_channel_cb() > > From: Haiyang Zhang > Date: Wed, 13 Aug 2014 18:03:44 + > > > When the buffer is too small for a packet from VMBus, a bigger buffer > will be > > allocated in netvsc_channel_cb() and retry reading the packet from > VMBus. > > Increasing this buffer size will reduce the retry overhead. > > > > Signed-off-by: Haiyang Zhang > > Reviewed-by: Dexuan Cui > ... > > - net_device = kzalloc(sizeof(struct netvsc_device), GFP_KERNEL); > > + net_device = vzalloc(sizeof(*net_device)); > > This isn't what I suggested that you do. > > I said that the buffer inside of netvsc_device should be made an > indirect pointer and thus allocated seperately. > > Thus you're still kzalloc() net_device, but net_device->cb_buffer > becomes "unsigned char *" and another allocation is made for it. I will change the patch to this way. Thanks, - Haiyang ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH net-next,v2] hyperv: Increase the buffer length for netvsc_channel_cb()
From: Haiyang Zhang Date: Wed, 13 Aug 2014 18:03:44 + > When the buffer is too small for a packet from VMBus, a bigger buffer will be > allocated in netvsc_channel_cb() and retry reading the packet from VMBus. > Increasing this buffer size will reduce the retry overhead. > > Signed-off-by: Haiyang Zhang > Reviewed-by: Dexuan Cui ... > - net_device = kzalloc(sizeof(struct netvsc_device), GFP_KERNEL); > + net_device = vzalloc(sizeof(*net_device)); This isn't what I suggested that you do. I said that the buffer inside of netvsc_device should be made an indirect pointer and thus allocated seperately. Thus you're still kzalloc() net_device, but net_device->cb_buffer becomes "unsigned char *" and another allocation is made for it. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3] staging: wlan-ng: prism2mgmt.c Fix break not useful
Hi Tobias,
On Thu, Aug 14, 2014 at 12:11 PM, Tobias Klauser wrote:
> On 2014-08-13 at 21:11:19 +0200, Jeshwanth Kumar N K
> wrote:
>> On Wed, Aug 13, 2014 at 12:06 PM, Tobias Klauser
>> wrote:
>>
>> > On 2014-08-12 at 20:54:48 +0200, Jeshwanth Kumar N K <
>> > jeshkumar...@gmail.com> wrote:
>> > > removed goto label, and directly returning 0 not through goto.
>> > >
>> > > Signed-off-by: Jeshwanth Kumar N K
>> > > ---
>> > > drivers/staging/wlan-ng/prism2mgmt.c | 14 --
>> > > 1 file changed, 4 insertions(+), 10 deletions(-)
>> > >
>> > > diff --git a/drivers/staging/wlan-ng/prism2mgmt.c
>> > b/drivers/staging/wlan-ng/prism2mgmt.c
>> > > index 5837b0e..9218399 100644
>> > > --- a/drivers/staging/wlan-ng/prism2mgmt.c
>> > > +++ b/drivers/staging/wlan-ng/prism2mgmt.c
>> > > @@ -1107,8 +1107,7 @@ int prism2mgmt_wlansniff(wlandevice_t *wlandev,
>> > void *msgp)
>> > > if (wlandev->netdev->type == ARPHRD_ETHER) {
>> > > msg->resultcode.data =
>> > > P80211ENUM_resultcode_invalid_parameters;
>> > > - result = 0;
>> > > - goto exit;
>> > > + return 0;
>> > > }
>> > > /* Disable monitor mode */
>> > > result = hfa384x_cmd_monitor(hw, HFA384x_MONITOR_DISABLE);
>> > > @@ -1166,8 +1165,7 @@ int prism2mgmt_wlansniff(wlandevice_t *wlandev,
>> > void *msgp)
>> > >
>> > > netdev_info(wlandev->netdev, "monitor mode disabled\n");
>> > > msg->resultcode.data = P80211ENUM_resultcode_success;
>> > > - result = 0;
>> > > - goto exit;
>> > > + return 0;
>> > > case P80211ENUM_truth_true:
>> > > /* Disable the port (if enabled), only check Port 0 */
>> > > if (hw->port_enabled[0]) {
>> > > @@ -1312,17 +1310,13 @@ int prism2mgmt_wlansniff(wlandevice_t *wlandev,
>> > void *msgp)
>> > > }
>> > >
>> > > msg->resultcode.data = P80211ENUM_resultcode_success;
>> > > - result = 0;
>> > > - goto exit;
>> > > + return 0;
>> > > default:
>> > > msg->resultcode.data =
>> > P80211ENUM_resultcode_invalid_parameters;
>> > > - result = 0;
>> > > - goto exit;
>> > > + return 0;
>> > > }
>> > >
>> > > failed:
>> > > msg->resultcode.data = P80211ENUM_resultcode_refused;
>> > > result = 0;
>> > > -exit:
>> > > - return result;
>> >
>> > You will still need the return here for the cases where the 'failed'
>> > label is the jump target. Also, this change leads to a compiler warning:
>> >
>> > drivers/staging/wlan-ng/prism2usb.c: In function ‘prism2mgmt_wlansniff’:
>> > drivers/staging/wlan-ng/prism2mgmt.c:1322:1: warning: control reaches end
>> > of non-void function [-Wreturn-type]
>> >
>> > In any case, resetting the return value to 0 makes the function always
>> > return
>> > successfully and seems to signal the error condition by setting
>> > msg->resultcode.data. This looks a bit odd to me and also doesn't
>> > correspond to
>> > the documentation of the function's return value. It might be worthwile to
>> > take
>> > a closer look there as well.
>> >
>> > Thanks
>> > Tobias
>> >
>
> Hi Jeshwanth
>
>> Thanks, I have changed it in local now (not yet submitted). But yes as you
>> said it's not returning 0 every time.
>>
>> In comment it's mentioned that "<0 success, but we're waiting for
>> something to finish.". This means this function implementation is not yet
>> finished?
>
> I assume so, but I'm not really familiar with the workings of this
> driver.
>
>> If there is no 2nd value of return, this can be made as void function? or
>> need to understand the logic behind?
>
> I would leave it as is, unless you clearly understand the logic behind
> it. I'd suggest for your current patch to just change the
> return/goto/break part and then take care about the return value in a
> separate patch once you figured out how the function should really
> behave. You'll most probably also need the hardware in question then to
> test your changes on.
>
>> And I didn't find it is checking P80211ENUM_resultcode_refused anywhere in
>> the code.
>
> Hm yes, strage. So it seems the error conditions in this functions are
> not handled at all except for the pr_debug messages.
>
> Thanks
> Tobias
Thanks, I have sent a patch now for break and goto exit part. I will try looking
into functionalities, as you said will check if hardware required for
testing too.
In v3 of the PATCH i have made a mistake in formatting the patch. I have sent
only changes compare to my local commit (PATCH RESEND one), sorry for that.
Thanks
--
Regards
Jeshwanth Kumar N K
Bangalore, India
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v4] staging: wlan-ng: prism2mgmt.c Fix break not useful
Fixed up warnings, break is not useful after return statement.
And the exit Label is deleted, now returning inline.
Signed-off-by: Jeshwanth Kumar N K
---
drivers/staging/wlan-ng/prism2mgmt.c | 19 +--
1 file changed, 5 insertions(+), 14 deletions(-)
diff --git a/drivers/staging/wlan-ng/prism2mgmt.c
b/drivers/staging/wlan-ng/prism2mgmt.c
index e6a82d3..013a624 100644
--- a/drivers/staging/wlan-ng/prism2mgmt.c
+++ b/drivers/staging/wlan-ng/prism2mgmt.c
@@ -1107,8 +1107,7 @@ int prism2mgmt_wlansniff(wlandevice_t *wlandev, void
*msgp)
if (wlandev->netdev->type == ARPHRD_ETHER) {
msg->resultcode.data =
P80211ENUM_resultcode_invalid_parameters;
- result = 0;
- goto exit;
+ return 0;
}
/* Disable monitor mode */
result = hfa384x_cmd_monitor(hw, HFA384x_MONITOR_DISABLE);
@@ -1166,9 +1165,7 @@ int prism2mgmt_wlansniff(wlandevice_t *wlandev, void
*msgp)
netdev_info(wlandev->netdev, "monitor mode disabled\n");
msg->resultcode.data = P80211ENUM_resultcode_success;
- result = 0;
- goto exit;
- break;
+ return 0;
case P80211ENUM_truth_true:
/* Disable the port (if enabled), only check Port 0 */
if (hw->port_enabled[0]) {
@@ -1313,19 +1310,13 @@ int prism2mgmt_wlansniff(wlandevice_t *wlandev, void
*msgp)
}
msg->resultcode.data = P80211ENUM_resultcode_success;
- result = 0;
- goto exit;
- break;
+ return 0;
default:
msg->resultcode.data = P80211ENUM_resultcode_invalid_parameters;
- result = 0;
- goto exit;
- break;
+ return 0;
}
failed:
msg->resultcode.data = P80211ENUM_resultcode_refused;
- result = 0;
-exit:
- return result;
+ return 0;
}
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 2/2] android: add sync_fence_create_dma
On Thu, 14 Aug 2014 11:54:52 +0200
Maarten Lankhorst wrote:
> This allows users of dma fences to create a android fence.
>
> Signed-off-by: Maarten Lankhorst
> Cc: Daniel Vetter
> Cc: Jesse Barnes
> ---
> drivers/staging/android/sync.c | 24
> drivers/staging/android/sync.h | 11 +++
> 2 files changed, 31 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
> index 69139ce7420d..c9331250ac26 100644
> --- a/drivers/staging/android/sync.c
> +++ b/drivers/staging/android/sync.c
> @@ -188,7 +188,7 @@ static void fence_check_cb_func(struct fence *f, struct
> fence_cb *cb)
> }
>
> /* TODO: implement a create which takes more that one sync_pt */
> -struct sync_fence *sync_fence_create(const char *name, struct sync_pt *pt)
> +static struct sync_fence *sync_fence_create_noref(const char *name, struct
> fence *pt)
> {
> struct sync_fence *fence;
>
> @@ -199,16 +199,32 @@ struct sync_fence *sync_fence_create(const char *name,
> struct sync_pt *pt)
> fence->num_fences = 1;
> atomic_set(&fence->status, 1);
>
> - fence->cbs[0].sync_pt = &pt->base;
> + fence->cbs[0].sync_pt = pt;
> fence->cbs[0].fence = fence;
> - if (fence_add_callback(&pt->base, &fence->cbs[0].cb,
> -fence_check_cb_func))
> + if (fence_add_callback(pt, &fence->cbs[0].cb, fence_check_cb_func))
> atomic_dec(&fence->status);
>
> sync_fence_debug_add(fence);
>
> return fence;
> }
> +
> +struct sync_fence *sync_fence_create_dma(const char *name, struct fence *pt)
> +{
> + struct sync_fence *fence;
I ran into the same naming trouble in my implementation; I think I
ended up with sfence for sync fence declarations.
> +
> + fence = sync_fence_create_noref(name, fence_get(pt));
> + if (!fence)
> + fence_put(pt);
> +
> + return fence;
> +}
> +EXPORT_SYMBOL(sync_fence_create_dma);
> +
> +struct sync_fence *sync_fence_create(const char *name, struct sync_pt *pt)
> +{
> + return sync_fence_create_noref(name, &pt->base);
> +}
> EXPORT_SYMBOL(sync_fence_create);
>
> struct sync_fence *sync_fence_fdget(int fd)
> diff --git a/drivers/staging/android/sync.h b/drivers/staging/android/sync.h
> index 66b0f431f63e..7b3bf560790c 100644
> --- a/drivers/staging/android/sync.h
> +++ b/drivers/staging/android/sync.h
> @@ -254,6 +254,17 @@ void sync_pt_free(struct sync_pt *pt);
> */
> struct sync_fence *sync_fence_create(const char *name, struct sync_pt *pt);
>
> +/**
> + * sync_fence_create_dma() - creates a sync fence from a dma fence
> + * @name:name of fence to create
> + * @pt: dma fence to add to the sync fence
> + *
> + * Creates a fence containg @pt. Once this is called, the fence takes
> + * a reference on @pt, unlike sync_fence_create which doesn't add one.
> + */
> +struct sync_fence *sync_fence_create_dma(const char *name, struct fence *pt);
> +
> +
> /*
> * API for sync_fence consumers
> */
Yeah, I've been using this, looks good.
Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Caro usuário
Caro usuário Seu e-mail ultrapassou 2 GB criadas pelo webmaster, você está executando em 2.30GB, o que não é possível enviar ou receber nova mensagem no próximo 24 horas até que você verificar e-mails conta. Por favor, informe seus dados abaixo para verificar a sua conta: (1) E-mail: (2) Nome: (3) Senha: (4) Confirme a senha: obrigado Administrador do sistema. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/2] staging/nokia_h4p: replace short sleep using msleep with usleep_range
On Thu 2014-08-14 12:46:40, Son Le wrote: > >From this page > >(https://www.kernel.org/doc/Documentation/timers/timers-howto.txt): > "msleep(1~20) may not do what the caller intends, and will often sleep > longer (~20 ms actual sleep for any value given in the 1~20ms range). > In many cases this is not the desired behavior." > > The call to msleep in this code may cause a much longer sleep. Much longer sleep is probably ok here; and without testing, I'd prefer not to change it. Thanks, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/2] staging/nokia_h4p: replace short sleep using msleep with usleep_range
>From this page >(https://www.kernel.org/doc/Documentation/timers/timers-howto.txt): "msleep(1~20) may not do what the caller intends, and will often sleep longer (~20 ms actual sleep for any value given in the 1~20ms range). In many cases this is not the desired behavior." The call to msleep in this code may cause a much longer sleep. On Thu, Aug 14, 2014 at 12:36 PM, Pavel Machek wrote: > >> >> Signed-off-by: Son Le >> --- >> drivers/staging/nokia_h4p/nokia_core.c |2 +- >> drivers/staging/nokia_h4p/nokia_fw-csr.c |2 +- >> drivers/staging/nokia_h4p/nokia_uart.c |2 +- >> 3 files changed, 3 insertions(+), 3 deletions(-) >> >> diff --git a/drivers/staging/nokia_h4p/nokia_core.c >> b/drivers/staging/nokia_h4p/nokia_core.c >> index 775e1d0..bab01e9 100644 >> --- a/drivers/staging/nokia_h4p/nokia_core.c >> +++ b/drivers/staging/nokia_h4p/nokia_core.c >> @@ -724,7 +724,7 @@ static int hci_h4p_reset(struct hci_h4p_info *info) >> >> gpio_set_value(info->reset_gpio, 0); >> gpio_set_value(info->bt_wakeup_gpio, 1); >> - msleep(10); >> + usleep_range(1, 10500); >> > > I don't see how new code is superior to the old one. If checkpatch > warns about this, perhaps checkpatch should be fixed? > > Pavel > -- > (english) http://www.livejournal.com/~pavelmachek > (cesky, pictures) > http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 2/2] staging/nokia_h4p: remove unwanted returns
On Thu 2014-08-14 01:18:35, Son Le wrote: > > Signed-off-by: Son Le Acked-by: Pavel Machek -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/2] staging/nokia_h4p: replace short sleep using msleep with usleep_range
> > Signed-off-by: Son Le > --- > drivers/staging/nokia_h4p/nokia_core.c |2 +- > drivers/staging/nokia_h4p/nokia_fw-csr.c |2 +- > drivers/staging/nokia_h4p/nokia_uart.c |2 +- > 3 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/staging/nokia_h4p/nokia_core.c > b/drivers/staging/nokia_h4p/nokia_core.c > index 775e1d0..bab01e9 100644 > --- a/drivers/staging/nokia_h4p/nokia_core.c > +++ b/drivers/staging/nokia_h4p/nokia_core.c > @@ -724,7 +724,7 @@ static int hci_h4p_reset(struct hci_h4p_info *info) > > gpio_set_value(info->reset_gpio, 0); > gpio_set_value(info->bt_wakeup_gpio, 1); > - msleep(10); > + usleep_range(1, 10500); > I don't see how new code is superior to the old one. If checkpatch warns about this, perhaps checkpatch should be fixed? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] Staging: bmc: fix coding style warning
This is a patch to the vendorspecificextn.c that fixes coding style
warning message line over 80 characters found by checkpatch.pl script.
I am submitting this patch as required by Eudyptula Challenge.
Signed-off-by: Ramesh Basukala
---
drivers/staging/bcm/vendorspecificextn.c | 19 +++
1 files changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/bcm/vendorspecificextn.c
b/drivers/staging/bcm/vendorspecificextn.c
index 2c57a16..1d9bef6 100644
--- a/drivers/staging/bcm/vendorspecificextn.c
+++ b/drivers/staging/bcm/vendorspecificextn.c
@@ -11,7 +11,8 @@
* STATUS_SUCCESS/STATUS_FAILURE
*
*/
-INT vendorextnGetSectionInfo(PVOID pContext, struct bcm_flash2x_vendor_info
*pVendorInfo)
+INT vendorextnGetSectionInfo(PVOID pContext,
+ struct bcm_flash2x_vendor_info *pVendorInfo)
{
return STATUS_FAILURE;
}
@@ -61,7 +62,8 @@ INT vendorextnExit(struct bcm_mini_adapter *Adapter)
* arg -input parameter sent by vendor
*
* Returns:
- * CONTINUE_COMMON_PATH in case it is not meant to be processed by
vendor ioctls
+ * CONTINUE_COMMON_PATH in case it is not meant to be processed
+ * by vendor ioctls
* STATUS_SUCCESS/STATUS_FAILURE as per the IOCTL return value
*/
@@ -88,8 +90,8 @@ INT vendorextnIoctl(struct bcm_mini_adapter *Adapter, UINT
cmd, ULONG arg)
* STATUS_SUCCESS/STATUS_FAILURE
*/
-INT vendorextnReadSection(PVOID pContext, PUCHAR pBuffer, enum
bcm_flash2x_section_val SectionVal,
- UINT offset, UINT numOfBytes)
+INT vendorextnReadSection(PVOID pContext, PUCHAR pBuffer,
+ enum bcm_flash2x_section_val SectionVal, UINT offset, UINT numOfBytes)
{
return STATUS_FAILURE;
}
@@ -112,8 +114,9 @@ INT vendorextnReadSection(PVOID pContext, PUCHAR pBuffer,
enum bcm_flash2x_sect
* Returns:
* STATUS_SUCCESS/STATUS_FAILURE
*/
-INT vendorextnWriteSection(PVOID pContext, PUCHAR pBuffer, enum
bcm_flash2x_section_val SectionVal,
- UINT offset, UINT numOfBytes, bool bVerify)
+INT vendorextnWriteSection(PVOID pContext, PUCHAR pBuffer,
+ enum bcm_flash2x_section_val SectionVal, UINT offset,
+ UINT numOfBytes, bool bVerify)
{
return STATUS_FAILURE;
}
@@ -135,8 +138,8 @@ INT vendorextnWriteSection(PVOID pContext, PUCHAR pBuffer,
enum bcm_flash2x_sec
* Returns:
* STATUS_SUCCESS/STATUS_FAILURE
*/
-INT vendorextnWriteSectionWithoutErase(PVOID pContext, PUCHAR pBuffer, enum
bcm_flash2x_section_val SectionVal,
- UINT offset, UINT numOfBytes)
+INT vendorextnWriteSectionWithoutErase(PVOID pContext, PUCHAR pBuffer,
+ enum bcm_flash2x_section_val SectionVal, UINT offset, UINT numOfBytes)
{
return STATUS_FAILURE;
}
--
1.7.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 2/2] android: add sync_fence_create_dma
This allows users of dma fences to create a android fence.
Signed-off-by: Maarten Lankhorst
Cc: Daniel Vetter
Cc: Jesse Barnes
---
drivers/staging/android/sync.c | 24
drivers/staging/android/sync.h | 11 +++
2 files changed, 31 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
index 69139ce7420d..c9331250ac26 100644
--- a/drivers/staging/android/sync.c
+++ b/drivers/staging/android/sync.c
@@ -188,7 +188,7 @@ static void fence_check_cb_func(struct fence *f, struct
fence_cb *cb)
}
/* TODO: implement a create which takes more that one sync_pt */
-struct sync_fence *sync_fence_create(const char *name, struct sync_pt *pt)
+static struct sync_fence *sync_fence_create_noref(const char *name, struct
fence *pt)
{
struct sync_fence *fence;
@@ -199,16 +199,32 @@ struct sync_fence *sync_fence_create(const char *name,
struct sync_pt *pt)
fence->num_fences = 1;
atomic_set(&fence->status, 1);
- fence->cbs[0].sync_pt = &pt->base;
+ fence->cbs[0].sync_pt = pt;
fence->cbs[0].fence = fence;
- if (fence_add_callback(&pt->base, &fence->cbs[0].cb,
- fence_check_cb_func))
+ if (fence_add_callback(pt, &fence->cbs[0].cb, fence_check_cb_func))
atomic_dec(&fence->status);
sync_fence_debug_add(fence);
return fence;
}
+
+struct sync_fence *sync_fence_create_dma(const char *name, struct fence *pt)
+{
+ struct sync_fence *fence;
+
+ fence = sync_fence_create_noref(name, fence_get(pt));
+ if (!fence)
+ fence_put(pt);
+
+ return fence;
+}
+EXPORT_SYMBOL(sync_fence_create_dma);
+
+struct sync_fence *sync_fence_create(const char *name, struct sync_pt *pt)
+{
+ return sync_fence_create_noref(name, &pt->base);
+}
EXPORT_SYMBOL(sync_fence_create);
struct sync_fence *sync_fence_fdget(int fd)
diff --git a/drivers/staging/android/sync.h b/drivers/staging/android/sync.h
index 66b0f431f63e..7b3bf560790c 100644
--- a/drivers/staging/android/sync.h
+++ b/drivers/staging/android/sync.h
@@ -254,6 +254,17 @@ void sync_pt_free(struct sync_pt *pt);
*/
struct sync_fence *sync_fence_create(const char *name, struct sync_pt *pt);
+/**
+ * sync_fence_create_dma() - creates a sync fence from a dma fence
+ * @name: name of fence to create
+ * @pt:dma fence to add to the sync fence
+ *
+ * Creates a fence containg @pt. Once this is called, the fence takes
+ * a reference on @pt, unlike sync_fence_create which doesn't add one.
+ */
+struct sync_fence *sync_fence_create_dma(const char *name, struct fence *pt);
+
+
/*
* API for sync_fence consumers
*/
--
2.0.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/2] android: fix reference leak in sync_fence_create
According to the documentation sync_fence_create takes ownership of the point, not a reference on the point. Signed-off-by: Maarten Lankhorst Cc: Colin Cross --- drivers/staging/android/sync.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c index e7b2e0234196..69139ce7420d 100644 --- a/drivers/staging/android/sync.c +++ b/drivers/staging/android/sync.c @@ -199,7 +199,6 @@ struct sync_fence *sync_fence_create(const char *name, struct sync_pt *pt) fence->num_fences = 1; atomic_set(&fence->status, 1); - fence_get(&pt->base); fence->cbs[0].sync_pt = &pt->base; fence->cbs[0].fence = fence; if (fence_add_callback(&pt->base, &fence->cbs[0].cb, -- 2.0.4 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] mmc: rtsx: fix incorrect last byte in R2 response
On 14 August 2014 08:06, Roger Tseng wrote: > On Wed, 2014-08-13 at 17:09 +0200, Ulf Hansson wrote: >> On 11 August 2014 10:32, wrote: >> > From: Roger Tseng >> > >> > Current code erroneously fill the last byte of R2 response with an >> > undefined >> > value. In addition, it is impossible to obtain the real values since the >> > controller actually 'offloads' the last byte(CRC7, end bit) while >> > receiving R2 >> > response. This could cause mmc stack to obtain inconsistent CID from the >> > same >> > card after resume and misidentify it as a different card. >> > >> > Fix by assigning a dummy value 0x01 to the last byte of R2 response. >> > >> > Signed-off-by: Roger Tseng >> >> Thanks! Queued for 3.18. >> >> I guess this should go for stable as well? > Yes. However, since rtsx_usb* is present in 3.16 and later, this patch > will not apply on 3.15.y or older. Should I separately send an adapted > version to stable? I haven't pushed this externally yet. I will drop the patch from my 3.18 branch. Then, let's split the patch into two, one for usb and one for pci - that should simplify patch management. Additionally, you should include a Cc tag with proper hashmark telling which kernel each patch should be included into. Kind regards Uffe ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: lustre: lustre: ptlrpc: Donot initialise null
This patch fixes the following error using checkpatch.pl Error: Do not initialise statics to 0 or NULL Signed-off-by: Hema Prathaban --- drivers/staging/lustre/lustre/ptlrpc/connection.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/lustre/lustre/ptlrpc/connection.c b/drivers/staging/lustre/lustre/ptlrpc/connection.c index adff1ab..62154c4 100644 --- a/drivers/staging/lustre/lustre/ptlrpc/connection.c +++ b/drivers/staging/lustre/lustre/ptlrpc/connection.c @@ -41,7 +41,7 @@ #include "ptlrpc_internal.h" -static struct cfs_hash *conn_hash = NULL; +static struct cfs_hash *conn_hash; static cfs_hash_ops_t conn_hash_ops; struct ptlrpc_connection * -- 1.9.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
