[PATCH] memstick: fix unreachable state in h_msb_read_page() in ms_block.c
From: Roger Tseng In h_msb_read_page() in ms_block.c, flow never reaches case MSB_RP_RECIVE_STATUS_REG. This causes error when MEMSTICK_INT_ERR is encountered and status error bits are going to be examined, but the status will never be copied back. Fix it by transiting to MSB_RP_RECIVE_STATUS_REG right after MSB_RP_SEND_READ_STATUS_REG. Signed-off-by: Roger Tseng --- drivers/memstick/core/ms_block.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/memstick/core/ms_block.c b/drivers/memstick/core/ms_block.c index 08e7023..9188ef5 100644 --- a/drivers/memstick/core/ms_block.c +++ b/drivers/memstick/core/ms_block.c @@ -401,7 +401,7 @@ again: sizeof(struct ms_status_register))) return 0; - msb->state = MSB_RP_RECEIVE_OOB_READ; + msb->state = MSB_RP_RECIVE_STATUS_REG; return 0; case MSB_RP_RECIVE_STATUS_REG: -- 1.8.2 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 0/8] staging: bcm: Clean up user defined data types
You and Kevin are treading on each other's patches. CC each other for bcm work. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 6/8] staging: bcm: Replace TRUE with true
On Tue, Oct 29, 2013 at 10:06:34PM -0700, Lisa Nguyen wrote:
> --- a/drivers/staging/bcm/Bcmchar.c
> +++ b/drivers/staging/bcm/Bcmchar.c
> @@ -287,9 +287,9 @@ static long bcm_char_ioctl(struct file *filp, UINT cmd,
> ULONG arg)
> struct bcm_rdm_buffer sRdmBuffer = {0};
> PCHAR temp_buff = NULL;
> UINT uiTempVar = 0;
> - if ((Adapter->IdleMode == TRUE) ||
> - (Adapter->bShutStatus == TRUE) ||
> - (Adapter->bPreparingForLowPowerMode == TRUE)) {
> + if ((Adapter->IdleMode == true) ||
> + (Adapter->bShutStatus == true) ||
> + (Adapter->bPreparingForLowPowerMode == true)) {
Your patch is fine but these variable names suck. How is "Mode" or
"Status" true or false? It should be something like:
if (adapter->idle || adapter->shutdown ||
addapter->preparing_for_low_power) {
(I assume that's what the code is trying to say).
regards,
dan carpenter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/1] staging: Add NULL checks to return value of skb_clone() and dev_alloc_skb()
On Mon, Oct 28, 2013 at 12:37:26PM +0800, RUC_SoftSec wrote: > Function skb_clone() and dev_alloc_skb() may return NULL pointers if there is > no enough memroy, their return values should be checked against NULL before > used. > This bug is found by a static tool developed by RUC_SoftSec, supported by > China.X.Orion. > Run your patches through scripts/checkpatch.pl. It should complain about the printks. Really, my feeling is that you can just leave the printks out. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/1] staging: check return value of dev_alloc_skb() against NULL
On Mon, Oct 28, 2013 at 01:08:19PM +0800, RUC_SoftSec wrote:
> Function dev_alloc_skb() may return a NULL pointer if there is no enough
> memory, it should be checked against NULL before used.
> This bug is found by a static analysis tool developed by RUC_SoftSec,
> supported by China.X.Orion.
>
> Signed-off-by: RUC_SoftSec
> ---
> drivers/staging/rtl8192u/r819xU_firmware.c |8
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/staging/rtl8192u/r819xU_firmware.c
> b/drivers/staging/rtl8192u/r819xU_firmware.c
> index bb924ac..045e48c 100644
> --- a/drivers/staging/rtl8192u/r819xU_firmware.c
> +++ b/drivers/staging/rtl8192u/r819xU_firmware.c
> @@ -66,6 +66,10 @@ bool fw_download_code(struct net_device *dev, u8
> *code_virtual_address, u32 buff
> #else
> skb = dev_alloc_skb(frag_length + 4);
> #endif
> + if (skb == NULL) {
> + rt_status = false;
> + break;
> + }
> memcpy((unsigned char *)(skb->cb),&dev,sizeof(dev));
> tcb_desc = (cb_desc *)(skb->cb + MAX_DEV_ADDR_SIZE);
> tcb_desc->queue_index = TXCMD_QUEUE;
> @@ -124,6 +128,10 @@ fwSendNullPacket(
>
> //Get TCB and local buffer from common pool. (It is shared by CmdQ,
> MgntQ, and USB coalesce DataQ)
> skb = dev_alloc_skb(Length+ 4);
> + if (skb == NULL) {
> + rtStatus = false;
> + return rtStatus;
Just do:
if (!skb)
return false;
regards,
dan carpenter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 0/8] staging: bcm: Clean up user defined data types
On Wed, Oct 30, 2013 at 1:55 AM, Dan Carpenter wrote: > You and Kevin are treading on each other's patches. CC each other for > bcm work. > > regards, > dan carpenter > Ah, I wasn't aware of this. Huge part of the problem would probably be is that I'm not currently subscribed to the devel@driverdev mailing list, so I'm not as mindful about other people's patch submissions. Whoops. I will take care of this when I get back later this week. Oh and hi Kevin! ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 6/8] staging: bcm: Replace TRUE with true
On Wed, Oct 30, 2013 at 2:01 AM, Dan Carpenter wrote:
> On Tue, Oct 29, 2013 at 10:06:34PM -0700, Lisa Nguyen wrote:
>> --- a/drivers/staging/bcm/Bcmchar.c
>> +++ b/drivers/staging/bcm/Bcmchar.c
>> @@ -287,9 +287,9 @@ static long bcm_char_ioctl(struct file *filp, UINT cmd,
>> ULONG arg)
>> struct bcm_rdm_buffer sRdmBuffer = {0};
>> PCHAR temp_buff = NULL;
>> UINT uiTempVar = 0;
>> - if ((Adapter->IdleMode == TRUE) ||
>> - (Adapter->bShutStatus == TRUE) ||
>> - (Adapter->bPreparingForLowPowerMode == TRUE)) {
>> + if ((Adapter->IdleMode == true) ||
>> + (Adapter->bShutStatus == true) ||
>> + (Adapter->bPreparingForLowPowerMode == true)) {
>
> Your patch is fine but these variable names suck. How is "Mode" or
> "Status" true or false? It should be something like:
>
> if (adapter->idle || adapter->shutdown ||
> addapter->preparing_for_low_power) {
>
> (I assume that's what the code is trying to say).
A big chunk of the bcm driver code is ugly to begin with.
I was focused on cleaning up pointless typedefs before attempting to
rewrite the conditionals as they are an eyesore. I haven't read too
much into the code yet.
I'd agree with your assumption.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/2] staging: media: davinci_vpfe: Rewrite return statement in vpfe_video.c
On Mon, Oct 28, 2013 at 01:19:29PM -0700, Lisa Nguyen wrote: > --- a/drivers/staging/media/davinci_vpfe/vpfe_video.c > +++ b/drivers/staging/media/davinci_vpfe/vpfe_video.c > @@ -346,7 +346,10 @@ static int vpfe_pipeline_disable(struct vpfe_pipeline > *pipe) > } > mutex_unlock(&mdev->graph_mutex); > > - return (ret == 0) ? ret : -ETIMEDOUT ; > + if (ret == 0) > + return ret; > + else > + return -ETIMEDOUT; > } Since everyone has an opinion on this return format my prefered is: if (ret) return -ETIMEDOUT; return 0; I like a clear "return 0;" instead of a "return ret;" where ret is always zero. I also like to keep my error path and my success path as separate as possible. Handle the errors right away and move them out of the success path. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 6/8] staging: bcm: Replace TRUE with true
On Wed, Oct 30, 2013 at 02:51:45AM -0700, Lisa Nguyen wrote:
> On Wed, Oct 30, 2013 at 2:01 AM, Dan Carpenter
> wrote:
> > On Tue, Oct 29, 2013 at 10:06:34PM -0700, Lisa Nguyen wrote:
> >> --- a/drivers/staging/bcm/Bcmchar.c
> >> +++ b/drivers/staging/bcm/Bcmchar.c
> >> @@ -287,9 +287,9 @@ static long bcm_char_ioctl(struct file *filp, UINT
> >> cmd, ULONG arg)
> >> struct bcm_rdm_buffer sRdmBuffer = {0};
> >> PCHAR temp_buff = NULL;
> >> UINT uiTempVar = 0;
> >> - if ((Adapter->IdleMode == TRUE) ||
> >> - (Adapter->bShutStatus == TRUE) ||
> >> - (Adapter->bPreparingForLowPowerMode == TRUE)) {
> >> + if ((Adapter->IdleMode == true) ||
> >> + (Adapter->bShutStatus == true) ||
> >> + (Adapter->bPreparingForLowPowerMode == true)) {
> >
> > Your patch is fine but these variable names suck. How is "Mode" or
> > "Status" true or false? It should be something like:
> >
> > if (adapter->idle || adapter->shutdown ||
> > addapter->preparing_for_low_power) {
> >
> > (I assume that's what the code is trying to say).
>
> A big chunk of the bcm driver code is ugly to begin with.
>
> I was focused on cleaning up pointless typedefs before attempting to
> rewrite the conditionals as they are an eyesore. I haven't read too
> much into the code yet.
>
Yes. Yes. I understand. These are just bonus comments I throw out for
free. They don't require a response.
regards,
dan carpenter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 6/8] staging: bcm: Replace TRUE with true
On Wed, Oct 30, 2013 at 2:56 AM, Dan Carpenter wrote:
> On Wed, Oct 30, 2013 at 02:51:45AM -0700, Lisa Nguyen wrote:
>> On Wed, Oct 30, 2013 at 2:01 AM, Dan Carpenter
>> wrote:
>> > On Tue, Oct 29, 2013 at 10:06:34PM -0700, Lisa Nguyen wrote:
>> >> --- a/drivers/staging/bcm/Bcmchar.c
>> >> +++ b/drivers/staging/bcm/Bcmchar.c
>> >> @@ -287,9 +287,9 @@ static long bcm_char_ioctl(struct file *filp, UINT
>> >> cmd, ULONG arg)
>> >> struct bcm_rdm_buffer sRdmBuffer = {0};
>> >> PCHAR temp_buff = NULL;
>> >> UINT uiTempVar = 0;
>> >> - if ((Adapter->IdleMode == TRUE) ||
>> >> - (Adapter->bShutStatus == TRUE) ||
>> >> - (Adapter->bPreparingForLowPowerMode == TRUE)) {
>> >> + if ((Adapter->IdleMode == true) ||
>> >> + (Adapter->bShutStatus == true) ||
>> >> + (Adapter->bPreparingForLowPowerMode == true)) {
>> >
>> > Your patch is fine but these variable names suck. How is "Mode" or
>> > "Status" true or false? It should be something like:
>> >
>> > if (adapter->idle || adapter->shutdown ||
>> > addapter->preparing_for_low_power) {
>> >
>> > (I assume that's what the code is trying to say).
>>
>> A big chunk of the bcm driver code is ugly to begin with.
>>
>> I was focused on cleaning up pointless typedefs before attempting to
>> rewrite the conditionals as they are an eyesore. I haven't read too
>> much into the code yet.
>>
>
> Yes. Yes. I understand. These are just bonus comments I throw out for
> free. They don't require a response.
I know I didn't have to respond back to this, but I wanted to let you
know that I like those free bonus comments :)
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 0/8] staging: bcm: Clean up user defined data types
On Wed, Oct 30, 2013 at 02:46:27AM -0700, Lisa Nguyen wrote: > On Wed, Oct 30, 2013 at 1:55 AM, Dan Carpenter > wrote: > > You and Kevin are treading on each other's patches. CC each other for > > bcm work. > > > > regards, > > dan carpenter > > > > Ah, I wasn't aware of this. Huge part of the problem would probably be > is that I'm not currently subscribed to the devel@driverdev mailing > list, so I'm not as mindful about other people's patch submissions. > Whoops. I will take care of this when I get back later this week. You should subscribe. It's great fun reviewing newbie commits. 1) does the patch apply? 2) is the changelog clear? 3) is there a signed of by? Most patches are simple to review. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 01/12 V3] Staging: bcm: Fix WARNING: space prohibited before semicolon.
On Tue, Oct 29, 2013 at 10:16:49PM -0400, Kevin McKinney wrote:
> This patch removes a space before semicolon as
> specified by checkpatch.pl.
>
> Signed-off-by: Kevin McKinney
> ---
> drivers/staging/bcm/Adapter.h |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/bcm/Adapter.h b/drivers/staging/bcm/Adapter.h
> index d6c9630..11fd7f1 100644
> --- a/drivers/staging/bcm/Adapter.h
> +++ b/drivers/staging/bcm/Adapter.h
> @@ -267,7 +267,7 @@ struct bcm_mini_adapter {
> boolfw_download_done;
>
> char*txctlpacket[MAX_CNTRL_PKTS];
> - atomic_tcntrlpktCnt ;
> + atomic_tcntrlpktCnt;
This is already in my tree.
thanks,
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 0/8] staging: bcm: Clean up user defined data types
Lisa and Kevin, you both keep stomping on each others patches, making my merges a pain :( My tree is now closed for 3.13 stuff like this, so I recommend doing something else for a few weeks until 3.13-rc1 is out, as I can't take any more patches for this type of cleanups until that is released by Linus. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
USB, TTY, char/misc, and Staging trees now closed for 3.13
Hi all, Given that 3.12 will be out in a few days, it's time to close my trees for new patches until 3.13-rc1 is out. The merge window for 3.13-rc1 is going to be a bit longer than normal as Linus has pointed out, due to travel and conferences. I'll also be traveling for 2 weeks, so my response time to patches is going to be _hugely_ delayed. So much delayed, that I would _really_ appreciate people not sending patches until 3.13-rc1 is out, just so that I can not have a ton of pending patches to dig through when that happens. If patches are sent before 3.13-rc1 is out, I will queue them up, but note that it will be delayed. Due to travel, conferences, and other stuff I want to work on (i.e. stable releases and xen kexec work), my response time to email is going to be really slow for a few weeks. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 29/51] DMA-API: ata: pata_octeon_cf: convert to use dma_coerce_mask_and_coherent()
On Thu, Sep 19, 2013 at 11:54 PM, Russell King
wrote:
> diff --git a/drivers/ata/pata_octeon_cf.c b/drivers/ata/pata_octeon_cf.c
> index c51bbb9..6231d43 100644
> --- a/drivers/ata/pata_octeon_cf.c
> +++ b/drivers/ata/pata_octeon_cf.c
> @@ -1014,8 +1014,9 @@ static int octeon_cf_probe(struct platform_device *pdev)
> }
> cf_port->c0 = ap->ioaddr.ctl_addr;
>
> - pdev->dev.coherent_dma_mask = DMA_BIT_MASK(64);
> - pdev->dev.dma_mask = &pdev->dev.coherent_dma_mask;
> + rv = dma_coerce_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64));
> + if (rv)
> + return ret;
return rv;
http://kisskb.ellerman.id.au/kisskb/buildresult/9959184/
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3] imx-drm: Add mx6 hdmi transmitter support
On Mon, Oct 28, 2013 at 06:26:49PM -0200, Fabio Estevam wrote:
> + /*Wait for PHY PLL lock */
> + msec = 4;
> + val = hdmi_readb(hdmi, HDMI_PHY_STAT0) & HDMI_PHY_TX_PHY_LOCK;
> + while (!val) {
> + udelay(1000);
> + if (msec-- == 0) {
> + dev_dbg(hdmi->dev, "PHY PLL not locked\n");
> + return -EINVAL;
> + }
> + val = hdmi_readb(hdmi, HDMI_PHY_STAT0) & HDMI_PHY_TX_PHY_LOCK;
> + }
This loop is not always sufficient for the PLL to always lock. It's also
buggy because it behaves like this:
msec = 4
read register
check bit - still one?
yes - wait 1ms
msec == 0?
no - msec = 3
read register
... msec eventually msec = 0
read register
check bit - still one
yes - wait 1ms
msec == 0?
yes - print debug and exit
So the last wait for 1ms performs no real function other than to delay
the inevitable exit. If we really want to wait 5ms for the condition
we're testing to become true, then do it like this:
msec = 5;
do {
val = hdmi_readb(hdmi, HDMI_PHY_STAT0) & HDMI_PHY_TX_PHY_LOCK;
if (!val)
break;
if (msec == 0) {
dev_err(hdmi->dev, "PHY PLL not locked\n");
return -EINVAL;
}
udelay(1000);
msec--;
} while (1);
This way, we check for the success condition immediately before checking
for the failure condition, and only waiting after that.
I'd also suggest making it a dev_err() so that it's obvious when it
doesn't lock - the current dev_dbg() remains hidden and causes
failures which don't seem to be visible to the user via the logs.
Hence why this issue has been overlooked...
> +static void hdmi_av_composer(struct imx_hdmi *hdmi,
> + const struct drm_display_mode *mode)
> +{
> + u8 inv_val;
> + struct hdmi_vmode *vmode = &hdmi->hdmi_data.video_mode;
> + int hblank, vblank, h_de_hs, v_de_vs, hsync_len, vsync_len;
> +
> + vmode->mhsyncpolarity = !!(mode->flags & DRM_MODE_FLAG_PHSYNC);
> + vmode->mvsyncpolarity = !!(mode->flags & DRM_MODE_FLAG_PVSYNC);
> + vmode->minterlaced = !!(mode->flags & DRM_MODE_FLAG_INTERLACE);
> + vmode->mpixelclock = mode->htotal * mode->vtotal *
> + drm_mode_vrefresh(mode);
We can do better here:
vmode->mpixelclock = mode->clock * 1000;
as the above is not quite correct when considering all the
possibilities. Since we're given the pixel clock in the mode structure,
we might as well make use it.
> + /* Set up VSYNC active edge delay (in pixel clks) */
> + vsync_len = mode->vsync_end - mode->vsync_start;
> + hdmi_writeb(hdmi, vsync_len, HDMI_FC_VSYNCINWIDTH);
Commentry - vsync len is in lines not pixel clocks.
Other than that, it seems to work here on the Carrier-1. Thanks.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 0/8] staging: bcm: Clean up user defined data types
On Wed, Oct 30, 2013 at 02:46:27AM -0700, Lisa Nguyen wrote: > On Wed, Oct 30, 2013 at 1:55 AM, Dan Carpenter > wrote: > > You and Kevin are treading on each other's patches. CC each other for > > bcm work. > > > > regards, > > dan carpenter > > > > Ah, I wasn't aware of this. Huge part of the problem would probably be > is that I'm not currently subscribed to the devel@driverdev mailing > list, so I'm not as mindful about other people's patch submissions. > Whoops. I will take care of this when I get back later this week. > > Oh and hi Kevin! Hi Lisa, nice to meet you!! I apologize for all of this confusion. I will make sure to apply all of your patches before changing any bcm code. I will also copy you on any patches I submit. Hopefully we can get this driver cleaned up and fully functional! Are you able to test this driver? I am still trying, I have been for a while now. The problem is, I use to live in an area where WiMax was not supported, but now I think I can finally get WiMax. Anyway, I hope to have the hardware functioning soon. Thanks, Kevin ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 0/8] staging: bcm: Clean up user defined data types
On Wed, Oct 30, 2013 at 09:40:10AM -0700, Greg KH wrote: > Lisa and Kevin, you both keep stomping on each others patches, making my > merges a pain :( Sorry about this. I will make sure this does not happen again. > My tree is now closed for 3.13 stuff like this, so I recommend doing > something else for a few weeks until 3.13-rc1 is out, as I can't take > any more patches for this type of cleanups until that is released by > Linus. Okay, sounds good. > thanks, > > greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] drivers: staging: speakup: serialio: delay initializing 'old_serial_port.baud_base'
On 10/26/2013 09:18 PM, Chen Gang wrote:
> On 10/25/2013 01:29 PM, Greg KH wrote:
>> No, just use the platform-specific SERIAL_PORT_DNFS, instead of having a
>> copy of it here in this driver, which is just wrong. So please remove
>> this, and just rely on the system version of this, defining it to
>> "nothing" if it isn't present, like the 8250 serial driver does it.
>>
>
> Hmm... excuse me, I am not quite familiar with it, I will consult
> related member.
>
> Hello Vineet, I have 2 questions to consult you, please help check:
>
> - can arc support this driver? ("drivers/staging/speakup/serialio.c")
>
> - if arc supports the driver, can arc let it be initialized statically?
> (not dynamically, e.g. BASE_BAUD).
>
> Thanks
>
After scan "arch" and "drivers" sub-directory:
- arc and openrisc define BASE_BAUD as non-constant number, and like most of
architectures, neither of them provide SERIAL_PORT_DFNS.
- frv and parisc define SERIAL_PORT_DFNS as empty, for all other architectures
who already define SERIAL_PORT_DFNS, they also use BASE_BAUD on it.
- for all drivers, they treat SERIAL_PORT_DFNS as 'constant' to initialize
static variables statically.
So for me, we need defind SERIAL_PORT_DFNS as empty for arc and
openrisc, since they can not treate BASE_BAUD as constant number.
Welcome any suggestions and completions.
Thanks.
--
Chen Gang
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] arc: include: asm: define empty SERIAL_PORT_DFNS in serial.h
For some architectures (e.g. arc, openrisc), BASE_BAUD isn't constant And SERIAL_PORT_DFNS always use BASE_BAUND, and also all drivers use SERIAL_PORT_DFNS to initialize static variables, statically. So need define SERIAL_PORT_DFNS as empty to tell drivers they don't support SERIAL_PORT_DFNS (mostly like frv and parisc did), or can not pass compiling The related error (allmodconfig for arc with gcc-4.8.0): CC [M] drivers/staging/speakup/serialio.o drivers/staging/speakup/serialio.c:12:2: error: initializer element is not constant SERIAL_PORT_DFNS ^ drivers/staging/speakup/serialio.c:12:2: error: (near initialization for 'rs_table[0].baud_base') drivers/staging/speakup/serialio.c:12:2: error: initializer element is not constant drivers/staging/speakup/serialio.c:12:2: error: (near initialization for 'rs_table[1].baud_base') drivers/staging/speakup/serialio.c:12:2: error: initializer element is not constant drivers/staging/speakup/serialio.c:12:2: error: (near initialization for 'rs_table[2].baud_base') drivers/staging/speakup/serialio.c:12:2: error: initializer element is not constant drivers/staging/speakup/serialio.c:12:2: error: (near initialization for 'rs_table[3].baud_base') Signed-off-by: Chen Gang --- arch/arc/include/asm/serial.h |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/arc/include/asm/serial.h b/arch/arc/include/asm/serial.h index 602b097..f18b772 100644 --- a/arch/arc/include/asm/serial.h +++ b/arch/arc/include/asm/serial.h @@ -32,4 +32,6 @@ #define BASE_BAUD (arc_get_core_freq() / 16 / 3) #endif +#defineSERIAL_PORT_DFNS + #endif /* _ASM_ARC_SERIAL_H */ -- 1.7.7.6 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: android: Fix typo in android/sync.h
Correct spelling typo in android/sync.h
Signed-off-by: Masanari Iida
---
drivers/staging/android/sync.h | 50 +-
1 file changed, 25 insertions(+), 25 deletions(-)
diff --git a/drivers/staging/android/sync.h b/drivers/staging/android/sync.h
index 38ea986..753c199 100644
--- a/drivers/staging/android/sync.h
+++ b/drivers/staging/android/sync.h
@@ -28,7 +28,7 @@ struct sync_fence;
/**
* struct sync_timeline_ops - sync object implementation ops
- * @driver_name: name of the implentation
+ * @driver_name: name of the implementation
* @dup: duplicate a sync_pt
* @has_signaled: returns:
* 1 if pt has signaled
@@ -37,12 +37,12 @@ struct sync_fence;
* @compare: returns:
* 1 if b will signal before a
* 0 if a and b will signal at the same time
- * -1 if a will signabl before b
+ * -1 if a will signal before b
* @free_pt: called before sync_pt is freed
* @release_obj: called before sync_timeline is freed
* @print_obj: deprecated
* @print_pt: deprecated
- * @fill_driver_data: write implmentation specific driver data to data.
+ * @fill_driver_data: write implementation specific driver data to data.
* should return an error if there is not enough room
* as specified by size. This information is returned
* to userspace by SYNC_IOC_FENCE_INFO.
@@ -88,9 +88,9 @@ struct sync_timeline_ops {
/**
* struct sync_timeline - sync object
* @kref: reference count on fence.
- * @ops: ops that define the implementaiton of the sync_timeline
+ * @ops: ops that define the implementation of the sync_timeline
* @name: name of the sync_timeline. Useful for debugging
- * @destoryed: set when sync_timeline is destroyed
+ * @destroyed: set when sync_timeline is destroyed
* @child_list_head: list of children sync_pts for this sync_timeline
* @child_list_lock: lock protecting @child_list_head, destroyed, and
* sync_pt.status
@@ -119,12 +119,12 @@ struct sync_timeline {
* @parent:sync_timeline to which this sync_pt belongs
* @child_list:membership in sync_timeline.child_list_head
* @active_list: membership in sync_timeline.active_list_head
- * @signaled_list: membership in temorary signaled_list on stack
+ * @signaled_list: membership in temporary signaled_list on stack
* @fence: sync_fence to which the sync_pt belongs
* @pt_list: membership in sync_fence.pt_list_head
* @status:1: signaled, 0:active, <0: error
* @timestamp: time which sync_pt status transitioned from active to
- * singaled or error.
+ * signaled or error.
*/
struct sync_pt {
struct sync_timeline*parent;
@@ -145,9 +145,9 @@ struct sync_pt {
/**
* struct sync_fence - sync fence
* @file: file representing this fence
- * @kref: referenace count on fence.
+ * @kref: reference count on fence.
* @name: name of sync_fence. Useful for debugging
- * @pt_list_head: list of sync_pts in ths fence. immutable once fence
+ * @pt_list_head: list of sync_pts in the fence. immutable once fence
* is created
* @waiter_list_head: list of asynchronous waiters on this fence
* @waiter_list_lock: lock protecting @waiter_list_head and @status
@@ -201,23 +201,23 @@ static inline void sync_fence_waiter_init(struct
sync_fence_waiter *waiter,
/**
* sync_timeline_create() - creates a sync object
- * @ops: specifies the implemention ops for the object
+ * @ops: specifies the implementation ops for the object
* @size: size to allocate for this obj
* @name: sync_timeline name
*
- * Creates a new sync_timeline which will use the implemetation specified by
- * @ops. @size bytes will be allocated allowing for implemntation specific
- * data to be kept after the generic sync_timeline stuct.
+ * Creates a new sync_timeline which will use the implementation specified by
+ * @ops. @size bytes will be allocated allowing for implementation specific
+ * data to be kept after the generic sync_timeline struct.
*/
struct sync_timeline *sync_timeline_create(const struct sync_timeline_ops *ops,
int size, const char *name);
/**
- * sync_timeline_destory() - destorys a sync object
+ * sync_timeline_destroy() - destroys a sync object
* @obj: sync_timeline to destroy
*
- * A sync implemntation should call this when the @obj is going away
- * (i.e. module unload.) @obj won't actually be freed until all its childern
+ * A sync implementation should cal
Re: [PATCH] drivers: staging: speakup: serialio: delay initializing 'old_serial_port.baud_base'
On 10/31/2013 06:57 AM, Chen Gang wrote:
> On 10/26/2013 09:18 PM, Chen Gang wrote:
>> On 10/25/2013 01:29 PM, Greg KH wrote:
>>> No, just use the platform-specific SERIAL_PORT_DNFS, instead of having a
>>> copy of it here in this driver, which is just wrong. So please remove
>>> this, and just rely on the system version of this, defining it to
>>> "nothing" if it isn't present, like the 8250 serial driver does it.
>>>
>> Hmm... excuse me, I am not quite familiar with it, I will consult
>> related member.
>>
>> Hello Vineet, I have 2 questions to consult you, please help check:
>>
>> - can arc support this driver? ("drivers/staging/speakup/serialio.c")
No I don' think it is relevant for ARC - but nevertheless as a general rule, it
should still build for ARC.
>> - if arc supports the driver, can arc let it be initialized statically?
>> (not dynamically, e.g. BASE_BAUD).
Like Greg said it needs to be fixed in the driver, just like 8250 does.
If this driver needs a specific definition of SERIAL_PORT_DFNS, that needs to
come
from platform's asm/serial.h w/o littering all other arches with an irrelevant
ifdef.
> After scan "arch" and "drivers" sub-directory:
>
> - arc and openrisc define BASE_BAUD as non-constant number, and like most of
> architectures, neither of them provide SERIAL_PORT_DFNS.
>
> - frv and parisc define SERIAL_PORT_DFNS as empty, for all other
> architectures who already define SERIAL_PORT_DFNS, they also use BASE_BAUD on
> it.
>
> - for all drivers, they treat SERIAL_PORT_DFNS as 'constant' to initialize
> static variables statically.
>
> So for me, we need defind SERIAL_PORT_DFNS as empty for arc and
> openrisc, since they can not treate BASE_BAUD as constant number.
No, please fix the driver instead.
-Vineet
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] arc: include: asm: define empty SERIAL_PORT_DFNS in serial.h
On 10/31/2013 07:15 AM, Chen Gang wrote: > For some architectures (e.g. arc, openrisc), BASE_BAUD isn't constant > And SERIAL_PORT_DFNS always use BASE_BAUND, and also all drivers use > SERIAL_PORT_DFNS to initialize static variables, statically. > > So need define SERIAL_PORT_DFNS as empty to tell drivers they don't > support SERIAL_PORT_DFNS (mostly like frv and parisc did), or can not > pass compiling > > The related error (allmodconfig for arc with gcc-4.8.0): > > CC [M] drivers/staging/speakup/serialio.o > drivers/staging/speakup/serialio.c:12:2: error: initializer element is not > constant > SERIAL_PORT_DFNS > ^ > drivers/staging/speakup/serialio.c:12:2: error: (near initialization for > 'rs_table[0].baud_base') > drivers/staging/speakup/serialio.c:12:2: error: initializer element is not > constant > drivers/staging/speakup/serialio.c:12:2: error: (near initialization for > 'rs_table[1].baud_base') > drivers/staging/speakup/serialio.c:12:2: error: initializer element is not > constant > drivers/staging/speakup/serialio.c:12:2: error: (near initialization for > 'rs_table[2].baud_base') > drivers/staging/speakup/serialio.c:12:2: error: initializer element is not > constant > drivers/staging/speakup/serialio.c:12:2: error: (near initialization for > 'rs_table[3].baud_base') > > > Signed-off-by: Chen Gang NAK - as mentioned in prev email please fix the driver. -Vineet ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
