Re: [PATCH 07/12] drm: drm_display_mode: add signal polarity flags
Hi,
Laurent Pinchart wrote:
> Hi Lothar,
>
> On Monday 17 March 2014 16:14:36 Lothar Waßmann wrote:
> > Laurent Pinchart wrote:
> > > On Monday 17 March 2014 14:41:09 Andrzej Hajda wrote:
> > > > On 03/13/2014 06:17 PM, Denis Carikli wrote:
> > > > > We need a way to pass signal polarity informations
> > > > > between DRM panels, and the display drivers.
> > > > >
> > > > > To do that, a pol_flags field was added to drm_display_mode.
> > > > >
> > > > > Signed-off-by: Denis Carikli
> > > > > ---
> > > > > ChangeLog v10->v11:
> > > > > - Since the imx-drm won't be able to retrive its regulators
> > > > >
> > > > > from the device tree when using display-timings nodes,
> > > > > and that I was told that the drm simple-panel driver
> > > > > already supported that, I then, instead, added what was
> > > > > lacking to make the eukrea displays work with the
> > > > > drm-simple-panel driver.
> > > > >
> > > > > That required a way to get back the display polarity
> > > > > informations from the imx-drm driver without affecting
> > > > > userspace.
> > > > >
> > > > > ---
> > > > >
> > > > > include/drm/drm_crtc.h |8
> > > > > 1 file changed, 8 insertions(+)
> > > > >
> > > > > diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> > > > > index f764654..61a4fe1 100644
> > > > > --- a/include/drm/drm_crtc.h
> > > > > +++ b/include/drm/drm_crtc.h
> > > > > @@ -131,6 +131,13 @@ enum drm_mode_status {
> > > > >
> > > > > #define DRM_MODE_FLAG_3D_MAX DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF
> > > > >
> > > > > +#define DRM_MODE_FLAG_POL_PIXDATA_NEGEDGEBIT(1)
> > > > > +#define DRM_MODE_FLAG_POL_PIXDATA_POSEDGEBIT(2)
> > > > > +#define DRM_MODE_FLAG_POL_PIXDATA_PRESERVE BIT(3)
> > > > > +#define DRM_MODE_FLAG_POL_DE_NEGEDGE BIT(4)
> > > > > +#define DRM_MODE_FLAG_POL_DE_POSEDGE BIT(5)
> > > > > +#define DRM_MODE_FLAG_POL_DE_PRESERVEBIT(6)
> > > >
> > > > Could you add some description to these flags.
> > > > What are *_PRESERVE flags for?
> > > > Are those flags 1:1 compatible with respective 'videomode:flags'?
> > > > I guess DE flags should be rather DRM_MODE_FLAG_POL_DE_(LOW|HIGH), am I
> > > > right?
> > >
> > > Possibly nitpicking, I wouldn't call the clock edge on which data signals
> > > are generated/sampled "data polarity". This is clock polarity
> > > information.
> > >
> > > Have you seen cases where pixel data and DE are geenrated or need to be
> > > sampled on different edges ?
> >
> > DE is not a clock signal, but an 'Enable' signal whose value (high or
> > low) defines the window in which the pixel data is valid.
> > The flag defines whether data is valid during the HIGH or LOW period of
> > DE.
>
> The DRM_MODE_FLAG_POL_DE_(LOW|HIGH) do, by my impression of the proposed new
> DRM_MODE_FLAG_POL_DE_*EDGE flags is that they define sampling clock edges,
> not
> active levels.
>
The current naming of the flags gives the impression that they describe
the sampling edges of a clock signal. But the DE signal in fact is not
a clock signal but a level sensitive gating signal.
Lothar Waßmann
--
___
Ka-Ro electronics GmbH | Pascalstraße 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Geschäftsführer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996
www.karo-electronics.de | i...@karo-electronics.de
___
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: unisys: use kzalloc instead of kmalloc/memset 0
2014-03-18 9:37 GMT+09:00 Greg KH : > On Tue, Mar 18, 2014 at 09:26:07AM +0900, DaeSeok Youn wrote: >> I think vmalloc/kmalloc in uislib_malloc() can be removed and just use >> vmalloc/kmalloc directly. > > Yes. Actually, just use kmalloc, I don't knwo why vmalloc is being > used, but cc: the driver maintainers just to be sure. It try to allocate 128KiB(131072byte) with vmalloc(). I think if it trying to allocate with kmalloc() it has a possibility to fail because of memory fragmentation even if system has enough memory to use. Just my opinion. If I'm wrong, let me know. > >> (UISMALLOC() macro is also removed.) > > Yes. > >> And uislib_malloc() is renamed to "uislib_trace_buffer_status()" which >> is just tracing buffer status(Malloc_FailuresAlloc, Malloc_BytesInUse >> ...) for info_proc_read_helper(). > > The whole tracing stuff needs to be ripped out, so no problem deleting > it here as well. OK. I will remove that information in info_proc_read_helper(). > >> If this change is accepted, it also need to change uislib_free(). > > Drop it and just use kfree(). OK. replace kfree() with uislib_free(). > > thanks, > > greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 07/12] drm: drm_display_mode: add signal polarity flags
On Tue, Mar 18, 2014 at 08:50:30AM +0100, Lothar Waßmann wrote: > Hi, > > Laurent Pinchart wrote: > > Hi Lothar, > > > > On Monday 17 March 2014 16:14:36 Lothar Waßmann wrote: > > > DE is not a clock signal, but an 'Enable' signal whose value (high or > > > low) defines the window in which the pixel data is valid. > > > The flag defines whether data is valid during the HIGH or LOW period of > > > DE. > > > > The DRM_MODE_FLAG_POL_DE_(LOW|HIGH) do, by my impression of the proposed > > new > > DRM_MODE_FLAG_POL_DE_*EDGE flags is that they define sampling clock edges, > > not > > active levels. > > > The current naming of the flags gives the impression that they describe > the sampling edges of a clock signal. But the DE signal in fact is not > a clock signal but a level sensitive gating signal. +1 -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Melhore a sua conta de e-mail
Caro E-mail de Conta de Usuário , Devido aos e-mails de lixo / spam que você recebe diariamente , estamos atualizando tudo contas de email filtro de spam para limitar todos os e-mails não solicitados para razões de segurança e para melhorar a nossa conta de e-mail novo e melhorado recursos e melhorias , para garantir que você não experimenta o serviço interrupção . Por favor, você deve responder a este e-mail imediatamente e entrar tanto o seu usuário nome e senha no espaço fornecido para que possamos atualizar a sua conta. Temos temporariamente limitado todo o acesso a recursos de conta sensíveis, restaurar o acesso à conta , você deve responder a este e-mail imediatamente e entrar na sua conta de e-mail Nome de Usuário aqui : ( .. ) e senha aqui: ( ... ) Website ( . .. ) Um link de confirmação será enviado a você para a reativação de sua e-mail da conta, assim que recebeu a sua resposta e você deve Clique no link "Confirmar E- mail" na sua caixa de correio da conta e , em seguida, entrar neste número de confirmação : 1265-6778-8250-8393-5727 Seu fracasso em fornecer os seus dados de e-mail de login da conta levará a uma desativada temporária de sua conta de e -mail ou vamos imediatamente desativar a sua conta de e -mail de nosso banco de dados. Obrigado pela sua compreensão . Equipe de Suporte . Administrador webmail ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH RESEND] x86, hyperv: bypass the timer_irq_works() check
> -Original Message-
> From: Jason Wang [mailto:jasow...@redhat.com]
> Sent: Thursday, February 27, 2014 7:30 PM
> To: KY Srinivasan; Haiyang Zhang; t...@linutronix.de; mi...@redhat.com;
> h...@zytor.com; x...@kernel.org; de...@linuxdriverproject.org; linux-
> ker...@vger.kernel.org
> Cc: Jason Wang; sta...@vger.kernel.org
> Subject: [PATCH RESEND] x86, hyperv: bypass the timer_irq_works() check
>
> This patch bypass the timer_irq_works() check for hyperv guest since:
>
> - It was guaranteed to work.
> - timer_irq_works() may fail sometime due to the lpj calibration were
> inaccurate
> in a hyperv guest or a buggy host.
>
> In the future, we should get the tsc frequency from hypervisor and use
> preset lpj instead.
>
> Cc: K. Y. Srinivasan
> Cc: Haiyang Zhang
> Cc: sta...@vger.kernel.org
> Acked-by: K. Y. Srinivasan
> Signed-off-by: Jason Wang
> ---
> arch/x86/kernel/cpu/mshyperv.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/arch/x86/kernel/cpu/mshyperv.c
> b/arch/x86/kernel/cpu/mshyperv.c index 9f7ca26..832d05a 100644
> --- a/arch/x86/kernel/cpu/mshyperv.c
> +++ b/arch/x86/kernel/cpu/mshyperv.c
> @@ -26,6 +26,7 @@
> #include
> #include
> #include
> +#include
>
> struct ms_hyperv_info ms_hyperv;
> EXPORT_SYMBOL_GPL(ms_hyperv);
> @@ -105,6 +106,11 @@ static void __init ms_hyperv_init_platform(void)
>
> if (ms_hyperv.features &
> HV_X64_MSR_TIME_REF_COUNT_AVAILABLE)
> clocksource_register_hz(&hyperv_cs, NSEC_PER_SEC/100);
> +
> +#ifdef CONFIG_X86_IO_APIC
> + no_timer_check = 1;
> +#endif
> +
> }
>
> const __refconst struct hypervisor_x86 x86_hyper_ms_hyperv = {
Peter,
Please let us know if you have any issues with this patch.
Regards,
K. Y
> --
> 1.8.3.2
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 07/12] drm: drm_display_mode: add signal polarity flags
Hi Lothar,
On Tuesday 18 March 2014 08:50:30 Lothar Waßmann wrote:
> Laurent Pinchart wrote:
> > On Monday 17 March 2014 16:14:36 Lothar Waßmann wrote:
> > > Laurent Pinchart wrote:
> > > > On Monday 17 March 2014 14:41:09 Andrzej Hajda wrote:
> > > > > On 03/13/2014 06:17 PM, Denis Carikli wrote:
> > > > > > We need a way to pass signal polarity informations
> > > > > > between DRM panels, and the display drivers.
> > > > > >
> > > > > > To do that, a pol_flags field was added to drm_display_mode.
> > > > > >
> > > > > > Signed-off-by: Denis Carikli
> > > > > > ---
> > > > > > ChangeLog v10->v11:
> > > > > > - Since the imx-drm won't be able to retrive its regulators
> > > > > >
> > > > > > from the device tree when using display-timings nodes,
> > > > > > and that I was told that the drm simple-panel driver
> > > > > > already supported that, I then, instead, added what was
> > > > > > lacking to make the eukrea displays work with the
> > > > > > drm-simple-panel driver.
> > > > > >
> > > > > > That required a way to get back the display polarity
> > > > > > informations from the imx-drm driver without affecting
> > > > > > userspace.
> > > > > >
> > > > > > ---
> > > > > >
> > > > > > include/drm/drm_crtc.h |8
> > > > > > 1 file changed, 8 insertions(+)
> > > > > >
> > > > > > diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> > > > > > index f764654..61a4fe1 100644
> > > > > > --- a/include/drm/drm_crtc.h
> > > > > > +++ b/include/drm/drm_crtc.h
> > > > > > @@ -131,6 +131,13 @@ enum drm_mode_status {
> > > > > >
> > > > > > #define DRM_MODE_FLAG_3D_MAX
> > > > > > DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF
> > > > > >
> > > > > > +#define DRM_MODE_FLAG_POL_PIXDATA_NEGEDGE BIT(1)
> > > > > > +#define DRM_MODE_FLAG_POL_PIXDATA_POSEDGE BIT(2)
> > > > > > +#define DRM_MODE_FLAG_POL_PIXDATA_PRESERVE BIT(3)
> > > > > > +#define DRM_MODE_FLAG_POL_DE_NEGEDGE BIT(4)
> > > > > > +#define DRM_MODE_FLAG_POL_DE_POSEDGE BIT(5)
> > > > > > +#define DRM_MODE_FLAG_POL_DE_PRESERVE BIT(6)
> > > > >
> > > > > Could you add some description to these flags.
> > > > > What are *_PRESERVE flags for?
> > > > > Are those flags 1:1 compatible with respective 'videomode:flags'?
> > > > > I guess DE flags should be rather DRM_MODE_FLAG_POL_DE_(LOW|HIGH),
> > > > > am I right?
> > > >
> > > > Possibly nitpicking, I wouldn't call the clock edge on which data
> > > > signals are generated/sampled "data polarity". This is clock polarity
> > > > information.
> > > >
> > > > Have you seen cases where pixel data and DE are geenrated or need to
> > > > be sampled on different edges ?
> > >
> > > DE is not a clock signal, but an 'Enable' signal whose value (high or
> > > low) defines the window in which the pixel data is valid.
> > > The flag defines whether data is valid during the HIGH or LOW period of
> > > DE.
> >
> > The DRM_MODE_FLAG_POL_DE_(LOW|HIGH) do, by my impression of the proposed
> > new DRM_MODE_FLAG_POL_DE_*EDGE flags is that they define sampling clock
> > edges, not active levels.
>
> The current naming of the flags gives the impression that they describe
> the sampling edges of a clock signal. But the DE signal in fact is not
> a clock signal but a level sensitive gating signal.
That's not my point. I *know* that DE is a data gating signal with a polarity
already defined by the DRM_MODE_FLAG_POL_DE_(LOW|HIGH) flags. Like all other
signals it gets generated on a clock edge and is sampled on a clock edge. The
DRM_MODE_FLAG_POL_DE_*EDGE flags proposed above describe seem to describe just
that, *not* the signal polarity. I thus want to know whether there are systems
where the data signals and the DE signal need to be sampled on different edges
of the pixel clock.
--
Regards,
Laurent Pinchart
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 07/12] drm: drm_display_mode: add signal polarity flags
On Tue, Mar 18, 2014 at 01:41:54PM +0100, Laurent Pinchart wrote: > Hi Lothar, > > That's not my point. I *know* that DE is a data gating signal with a polarity > already defined by the DRM_MODE_FLAG_POL_DE_(LOW|HIGH) flags. Like all other > signals it gets generated on a clock edge and is sampled on a clock edge. The > DRM_MODE_FLAG_POL_DE_*EDGE flags proposed above describe seem to describe > just > that, *not* the signal polarity. I thus want to know whether there are > systems > where the data signals and the DE signal need to be sampled on different > edges > of the pixel clock. That's not relevant to this patch series though. This patch series is about adding configuration which will allow iMX6 SoCs to be properly configured for their displays. iMX has the ability to: - define the polarity of the clock signal - define the polarity of the other signals It does not have the ability to define which clock edge individual signals like vsync (frame clock), hsync (line clock), disable enable change on independently. So, it doesn't make sense _here_ for the display enable to be defined by an edge - it's not something that can be changed here. What can only be changed is it's active level. Of course, there may be some which can do this, and that's a separate problem that would need to be addressed when there's hardware that does support it. The objection which Lothar is raising is that _this_ definition does not match the _hardware_ capabilities which it is intended to be used with, which is a very valid objection. -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC PATCH 03/22] staging: crypto: skein: allow building statically
On Mon, Mar 17, 2014 at 02:52:52PM -0700, Greg KH wrote: > On Tue, Mar 11, 2014 at 09:32:35PM +, Jason Cooper wrote: > > These are the minimum changes required to get the code to build > > statically in the kernel. It's necessary to do this first so that we > > can empirically determine that future cleanup patches aren't changing > > the generated object code. > > > > Signed-off-by: Jason Cooper > > This doesn't apply to my latest tree :( Ah, ok. I'll rebase this series on the staging tree. > > --- a/drivers/staging/Makefile > > +++ b/drivers/staging/Makefile > > @@ -65,3 +65,4 @@ obj-$(CONFIG_XILLYBUS)+= xillybus/ > > obj-$(CONFIG_DGNC) += dgnc/ > > obj-$(CONFIG_DGAP) += dgap/ > > obj-$(CONFIG_MTD_SPINAND_MT29F)+= mt29f_spinand/ > > +obj-$(CONFIG_CRYPTO_SKEIN) += skein/ > > Care to align these up with the way this file is formatted? Of course, not sure what happened there (well, other than the obvious :-P) > And I have no objection to taking the drivers/staging/ patches, the > script looks useful, but I can't take it through the staging tree, > sorry. Ok, I'll pull that out as a separate branch. Do you mind taking a series that depends on a topic branch from another tree? We do it a lot in arm-soc, but I'm not sure how popular that is elsewhere. It's purely an audit/testing dependency, but it would be nice to have it available in the history if someone wants to audit the changes. I have one change I'd like to do to the objdiff script. I'd like it to assume 'HEAD^ HEAD' when the user executes './scripts/objdiff diff'. I'll respin both and submit a v1. Thanks for the review. thx, Jason. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: unisys: use kzalloc instead of kmalloc/memset 0
On 03/17/2014 07:26 PM, DaeSeok Youn wrote:
I think vmalloc/kmalloc in uislib_malloc() can be removed and just use
vmalloc/kmalloc directly.
(UISMALLOC() macro is also removed.)
And uislib_malloc() is renamed to "uislib_trace_buffer_status()" which
is just tracing buffer status(Malloc_FailuresAlloc, Malloc_BytesInUse
...) for info_proc_read_helper().
If this change is accepted, it also need to change uislib_free().
Is it fine to change like this?
This change is fine with me. It makes the logic easier to follow.
Thanks.
Daeseok Youn.
2014-03-18 6:41 GMT+09:00 Greg KH :
On Wed, Mar 12, 2014 at 07:37:50PM +0900, Daeseok Youn wrote:
Signed-off-by: Daeseok Youn
---
drivers/staging/unisys/uislib/uislib.c |5 +
drivers/staging/unisys/uislib/uisutils.c |2 +-
2 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/unisys/uislib/uislib.c
b/drivers/staging/unisys/uislib/uislib.c
index d77df9a..9748fcb 100644
--- a/drivers/staging/unisys/uislib/uislib.c
+++ b/drivers/staging/unisys/uislib/uislib.c
@@ -339,8 +339,6 @@ create_bus(CONTROLVM_MESSAGE *msg, char *buf)
return CONTROLVM_RESP_ERROR_KMALLOC_FAILED;
}
- memset(bus, 0, size);
-
/* Currently by default, the bus Number is the GuestHandle.
* Configure Bus message can override this.
*/
@@ -530,7 +528,6 @@ create_device(CONTROLVM_MESSAGE *msg, char *buf)
return CONTROLVM_RESP_ERROR_KMALLOC_FAILED;
}
- memset(dev, 0, sizeof(struct device_info));
dev->channelTypeGuid = msg->cmd.createDevice.dataTypeGuid;
dev->intr = msg->cmd.createDevice.intr;
dev->channelAddr = msg->cmd.createDevice.channelAddr;
@@ -1437,7 +1434,7 @@ uislib_malloc(size_t siz, gfp_t gfp, U8 contiguous, char
*fn, int ln)
* get memory for you (like, invoke oom killer), which
* will probably cripple the system.
*/
- p = kmalloc(siz, gfp | __GFP_NORETRY);
+ p = kzalloc(siz, gfp | __GFP_NORETRY);
}
if (p == NULL) {
LOGERR("uislib_malloc failed to alloc %d bytes @%s:%d",
diff --git a/drivers/staging/unisys/uislib/uisutils.c
b/drivers/staging/unisys/uislib/uisutils.c
index 208b7ea..2f05be1 100644
--- a/drivers/staging/unisys/uislib/uisutils.c
+++ b/drivers/staging/unisys/uislib/uisutils.c
@@ -294,7 +294,7 @@ ReqHandlerAdd(GUID switchTypeGuid,
rc = UISMALLOC(sizeof(*rc), GFP_ATOMIC);
if (!rc)
return NULL;
- memset(rc, 0, sizeof(*rc));
+
rc->switchTypeGuid = switchTypeGuid;
rc->controlfunc = controlfunc;
rc->min_channel_bytes = min_channel_bytes;
Can you just remove the UISMALLOC() macro completly, so that it's easier
to verify that changes like this are actually correct?
thanks,
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 07/12] drm: drm_display_mode: add signal polarity flags
Hi Russell, On Tuesday 18 March 2014 12:56:23 Russell King - ARM Linux wrote: > On Tue, Mar 18, 2014 at 01:41:54PM +0100, Laurent Pinchart wrote: > > Hi Lothar, > > > > That's not my point. I *know* that DE is a data gating signal with a > > polarity already defined by the DRM_MODE_FLAG_POL_DE_(LOW|HIGH) flags. > > Like all other signals it gets generated on a clock edge and is sampled > > on a clock edge. The DRM_MODE_FLAG_POL_DE_*EDGE flags proposed above > > describe seem to describe just that, *not* the signal polarity. I thus > > want to know whether there are systems where the data signals and the DE > > signal need to be sampled on different edges of the pixel clock. > > That's not relevant to this patch series though. This patch series is > about adding configuration which will allow iMX6 SoCs to be properly > configured for their displays. > > iMX has the ability to: > > - define the polarity of the clock signal > - define the polarity of the other signals > > It does not have the ability to define which clock edge individual signals > like vsync (frame clock), hsync (line clock), disable enable change on > independently. > > So, it doesn't make sense _here_ for the display enable to be defined by > an edge - it's not something that can be changed here. What can only be > changed is it's active level. > > Of course, there may be some which can do this, and that's a separate > problem that would need to be addressed when there's hardware that does > support it. > > The objection which Lothar is raising is that _this_ definition does not > match the _hardware_ capabilities which it is intended to be used with, > which is a very valid objection. Thank you for the clarification. That absolutely makes sense. -- Regards, Laurent Pinchart ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 07/12] drm: drm_display_mode: add signal polarity flags
Hi,
Laurent Pinchart wrote:
> Hi Lothar,
>
> On Tuesday 18 March 2014 08:50:30 Lothar Waßmann wrote:
> > Laurent Pinchart wrote:
> > > On Monday 17 March 2014 16:14:36 Lothar Waßmann wrote:
> > > > Laurent Pinchart wrote:
> > > > > On Monday 17 March 2014 14:41:09 Andrzej Hajda wrote:
> > > > > > On 03/13/2014 06:17 PM, Denis Carikli wrote:
> > > > > > > We need a way to pass signal polarity informations
> > > > > > > between DRM panels, and the display drivers.
> > > > > > >
> > > > > > > To do that, a pol_flags field was added to drm_display_mode.
> > > > > > >
> > > > > > > Signed-off-by: Denis Carikli
> > > > > > > ---
> > > > > > > ChangeLog v10->v11:
> > > > > > > - Since the imx-drm won't be able to retrive its regulators
> > > > > > >
> > > > > > > from the device tree when using display-timings nodes,
> > > > > > > and that I was told that the drm simple-panel driver
> > > > > > > already supported that, I then, instead, added what was
> > > > > > > lacking to make the eukrea displays work with the
> > > > > > > drm-simple-panel driver.
> > > > > > >
> > > > > > > That required a way to get back the display polarity
> > > > > > > informations from the imx-drm driver without affecting
> > > > > > > userspace.
> > > > > > >
> > > > > > > ---
> > > > > > >
> > > > > > > include/drm/drm_crtc.h |8
> > > > > > > 1 file changed, 8 insertions(+)
> > > > > > >
> > > > > > > diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> > > > > > > index f764654..61a4fe1 100644
> > > > > > > --- a/include/drm/drm_crtc.h
> > > > > > > +++ b/include/drm/drm_crtc.h
> > > > > > > @@ -131,6 +131,13 @@ enum drm_mode_status {
> > > > > > >
> > > > > > > #define DRM_MODE_FLAG_3D_MAX
> > > > > > > DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF
> > > > > > >
> > > > > > > +#define DRM_MODE_FLAG_POL_PIXDATA_NEGEDGEBIT(1)
> > > > > > > +#define DRM_MODE_FLAG_POL_PIXDATA_POSEDGEBIT(2)
> > > > > > > +#define DRM_MODE_FLAG_POL_PIXDATA_PRESERVE BIT(3)
> > > > > > > +#define DRM_MODE_FLAG_POL_DE_NEGEDGE BIT(4)
> > > > > > > +#define DRM_MODE_FLAG_POL_DE_POSEDGE BIT(5)
> > > > > > > +#define DRM_MODE_FLAG_POL_DE_PRESERVEBIT(6)
> > > > > >
> > > > > > Could you add some description to these flags.
> > > > > > What are *_PRESERVE flags for?
> > > > > > Are those flags 1:1 compatible with respective 'videomode:flags'?
> > > > > > I guess DE flags should be rather DRM_MODE_FLAG_POL_DE_(LOW|HIGH),
> > > > > > am I right?
> > > > >
> > > > > Possibly nitpicking, I wouldn't call the clock edge on which data
> > > > > signals are generated/sampled "data polarity". This is clock polarity
> > > > > information.
> > > > >
> > > > > Have you seen cases where pixel data and DE are geenrated or need to
> > > > > be sampled on different edges ?
> > > >
> > > > DE is not a clock signal, but an 'Enable' signal whose value (high or
> > > > low) defines the window in which the pixel data is valid.
> > > > The flag defines whether data is valid during the HIGH or LOW period of
> > > > DE.
> > >
> > > The DRM_MODE_FLAG_POL_DE_(LOW|HIGH) do, by my impression of the proposed
> > > new DRM_MODE_FLAG_POL_DE_*EDGE flags is that they define sampling clock
> > > edges, not active levels.
> >
> > The current naming of the flags gives the impression that they describe
> > the sampling edges of a clock signal. But the DE signal in fact is not
> > a clock signal but a level sensitive gating signal.
>
> That's not my point. I *know* that DE is a data gating signal with a polarity
> already defined by the DRM_MODE_FLAG_POL_DE_(LOW|HIGH) flags. Like all other
> signals it gets generated on a clock edge and is sampled on a clock edge. The
> DRM_MODE_FLAG_POL_DE_*EDGE flags proposed above describe seem to describe
> just
>
The important word here is 'seem'.
Lothar Waßann
--
___
Ka-Ro electronics GmbH | Pascalstraße 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Geschäftsführer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996
www.karo-electronics.de | i...@karo-electronics.de
___
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 08/12] imx-drm: Use drm_display_mode timings flags.
Hi,
Denis Carikli wrote:
> The previous hardware behaviour was kept if the
> flags are not set.
>
> Signed-off-by: Denis Carikli
> ---
> ChangeLog v10->v11:
> - This patch was splitted-out and adapted from:
> "Prepare imx-drm for extra display-timings retrival."
> - The display-timings dt specific part was removed.
> - The flags names were changed to use the DRM ones from:
> "drm: drm_display_mode: add signal polarity flags"
> ---
> drivers/staging/imx-drm/imx-drm-core.c | 10 ++
> drivers/staging/imx-drm/imx-drm.h |6 ++
> drivers/staging/imx-drm/imx-hdmi.c |3 +++
> drivers/staging/imx-drm/imx-ldb.c |3 +++
> drivers/staging/imx-drm/imx-tve.c |3 +++
> drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h |6 --
> drivers/staging/imx-drm/ipu-v3/ipu-di.c |7 ++-
> drivers/staging/imx-drm/ipuv3-crtc.c| 21 +++--
> 3 files changed, 29 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h
> b/drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h
> index b95cba1..3abeea3 100644
> --- a/drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h
> +++ b/drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h
> @@ -29,9 +29,11 @@ enum ipuv3_type {
>
> #define CLK_POL_ACTIVE_LOW 0
> #define CLK_POL_ACTIVE_HIGH 1
> +#define CLK_POL_PRESERVE 2
>
> #define ENABLE_POL_NEGEDGE 0
> #define ENABLE_POL_POSEDGE 1
> +#define ENABLE_POL_PRESERVE 2
>
> /*
> * Bitfield of Display Interface signal polarities.
> @@ -43,10 +45,10 @@ struct ipu_di_signal_cfg {
> unsigned clksel_en:1;
> unsigned clkidle_en:1;
> unsigned data_pol:1;/* true = inverted */
> - unsigned clk_pol:1;
> - unsigned enable_pol:1;
> unsigned Hsync_pol:1; /* true = active high */
> unsigned Vsync_pol:1;
> + u8 clk_pol;
> + u8 enable_pol;
>
> u16 width;
> u16 height;
> diff --git a/drivers/staging/imx-drm/ipu-v3/ipu-di.c
> b/drivers/staging/imx-drm/ipu-v3/ipu-di.c
> index 53646aa..791080b 100644
> --- a/drivers/staging/imx-drm/ipu-v3/ipu-di.c
> +++ b/drivers/staging/imx-drm/ipu-v3/ipu-di.c
> @@ -597,6 +597,8 @@ int ipu_di_init_sync_panel(struct ipu_di *di, struct
> ipu_di_signal_cfg *sig)
>
> if (sig->clk_pol == CLK_POL_ACTIVE_HIGH)
> di_gen |= DI_GEN_POLARITY_DISP_CLK;
> + else if (sig->clk_pol == CLK_POL_ACTIVE_LOW)
> + di_gen &= ~DI_GEN_POLARITY_DISP_CLK;
>
> ipu_di_write(di, di_gen, DI_GENERAL);
>
> @@ -604,10 +606,13 @@ int ipu_di_init_sync_panel(struct ipu_di *di, struct
> ipu_di_signal_cfg *sig)
>DI_SYNC_AS_GEN);
>
> reg = ipu_di_read(di, DI_POL);
> - reg &= ~(DI_POL_DRDY_DATA_POLARITY | DI_POL_DRDY_POLARITY_15);
> + reg &= ~(DI_POL_DRDY_DATA_POLARITY);
>
> if (sig->enable_pol == ENABLE_POL_POSEDGE)
> reg |= DI_POL_DRDY_POLARITY_15;
> + else if (sig->enable_pol == ENABLE_POL_NEGEDGE)
> + reg &= ~DI_POL_DRDY_POLARITY_15;
> +
> if (sig->data_pol)
> reg |= DI_POL_DRDY_DATA_POLARITY;
>
> diff --git a/drivers/staging/imx-drm/ipuv3-crtc.c
> b/drivers/staging/imx-drm/ipuv3-crtc.c
> index 8cfeb47..c75034e 100644
> --- a/drivers/staging/imx-drm/ipuv3-crtc.c
> +++ b/drivers/staging/imx-drm/ipuv3-crtc.c
> @@ -157,8 +157,25 @@ static int ipu_crtc_mode_set(struct drm_crtc *crtc,
> if (mode->flags & DRM_MODE_FLAG_PVSYNC)
> sig_cfg.Vsync_pol = 1;
>
> - sig_cfg.enable_pol = ENABLE_POL_POSEDGE;
> - sig_cfg.clk_pol = CLK_POL_ACTIVE_LOW;
> + if (mode->pol_flags & DRM_MODE_FLAG_POL_PIXDATA_POSEDGE)
> + sig_cfg.enable_pol = ENABLE_POL_POSEDGE;
> + else if (mode->pol_flags & DRM_MODE_FLAG_POL_DE_NEGEDGE)
> + sig_cfg.enable_pol = ENABLE_POL_NEGEDGE;
> + else if (mode->pol_flags & DRM_MODE_FLAG_POL_PIXDATA_PRESERVE)
> + sig_cfg.enable_pol = ENABLE_POL_PRESERVE;
> + else
> + sig_cfg.enable_pol = ENABLE_POL_POSEDGE;
> +
> + if (mode->private_flags & DRM_MODE_FLAG_POL_DE_POSEDGE)
> + sig_cfg.clk_pol = CLK_POL_ACTIVE_HIGH;
> + else if (mode->private_flags & DRM_MODE_FLAG_POL_DE_NEGEDGE)
> + sig_cfg.clk_pol = CLK_POL_ACTIVE_LOW;
> + else if (mode->private_flags & DRM_MODE_FLAG_POL_DE_PRESERVE)
> + sig_cfg.clk_pol = CLK_POL_PRESERVE;
> + else
> + sig_cfg.clk_pol = CLK_POL_ACTIVE_LOW;
>
This is completely messed up. POL_PIXDATA should obviously define the
clock edge at which the pixel data is sampled and thus should determine
the value of sig_cfg.clk_pol and POL_DE should determine the value of
sig_cfg.enable_pol.
Lothar Waßmann
--
___
Ka-Ro electronics GmbH | Pascalstraße 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Geschäftsführer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen,
Re: [PATCH 1/6] Staging: unisys: channels: Cleanup sparse warnings
On 03/17/2014 04:43 PM, Mark Einon wrote: Clean up multiple sparse warnings mostly due to different address spaces when accessing I/O memory. Also, remove SignalRemoveAll(), SignalQueueHasOneElement(), SignalQueueIsFull(), because they were never called. Signed-off-by: Ken Cox diff --git a/drivers/staging/unisys/include/commontypes.h b/drivers/staging/unisys/include/commontypes.h index ae46bed..ef12af4 100644 --- a/drivers/staging/unisys/include/commontypes.h +++ b/drivers/staging/unisys/include/commontypes.h @@ -23,6 +23,7 @@ #ifdef __KERNEL__ #include #include +#include #else #include #include @@ -72,6 +73,7 @@ typedef U64 GUEST_PHYSICAL_ADDRESS; #define MEMSET(ptr, val, len) memset(ptr, val, len) #define MEMCMP(m1, m2, len) memcmp(m1, m2, len) +#define MEMCMP_IO(m1, m2, len) memcmp((void __force *)m1, m2, len) #define STRLEN(s) ((UINTN)strlen((const char *)s)) #define STRCPY(d, s) (strcpy((char *)d, (const char *)s)) @@ -81,6 +83,8 @@ typedef U64 GUEST_PHYSICAL_ADDRESS; #ifdef __KERNEL__ #define MEMORYBARRIER mb() #define MEMCPY(dest, src, len) memcpy(dest, src, len) +#define MEMCPY_TOIO(dest, src, len) memcpy_toio(dest, src, len) +#define MEMCPY_FROMIO(dest, src, len) memcpy_fromio(dest, src, len) We know we're in the kernel, so there's no need for this #ifdef - also why not get rid of the define altogether, and use the memcpy_toio() function call direct? ...similarly for the other defines here. Agreed. I'll make that change in an upcoming patch. Cheers, Mark #define CHANNEL_GUID_MISMATCH(chType, chName, field, expected, actual, fil, \ lin, logCtx)\ -- ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: omap24xx: fix coding style
Fix missing parentheses in macros Errors found by checkpatch.pl Signed-off-by: Ioana Ileana --- drivers/staging/media/omap24xx/tcm825x.h |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/media/omap24xx/tcm825x.h b/drivers/staging/media/omap24xx/tcm825x.h index e2d1bcd..bfb72ee 100644 --- a/drivers/staging/media/omap24xx/tcm825x.h +++ b/drivers/staging/media/omap24xx/tcm825x.h @@ -21,8 +21,8 @@ #define TCM825X_NAME "tcm825x" -#define TCM825X_MASK(x) x & 0x00ff -#define TCM825X_ADDR(x) (x & 0xff00) >> 8 +#define TCM825X_MASK(x) (x & 0x00ff) +#define TCM825X_ADDR(x) ((x & 0xff00) >> 8) /* The TCM825X I2C sensor chip has a fixed slave address of 0x3d. */ #define TCM825X_I2C_ADDR 0x3d -- 1.7.9.5 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC PATCH 03/22] staging: crypto: skein: allow building statically
On Tue, Mar 18, 2014 at 08:58:49AM -0400, Jason Cooper wrote: > On Mon, Mar 17, 2014 at 02:52:52PM -0700, Greg KH wrote: > > On Tue, Mar 11, 2014 at 09:32:35PM +, Jason Cooper wrote: > > > These are the minimum changes required to get the code to build > > > statically in the kernel. It's necessary to do this first so that we > > > can empirically determine that future cleanup patches aren't changing > > > the generated object code. > > > > > > Signed-off-by: Jason Cooper > > > > This doesn't apply to my latest tree :( > > Ah, ok. I'll rebase this series on the staging tree. > > > > --- a/drivers/staging/Makefile > > > +++ b/drivers/staging/Makefile > > > @@ -65,3 +65,4 @@ obj-$(CONFIG_XILLYBUS) += xillybus/ > > > obj-$(CONFIG_DGNC) += dgnc/ > > > obj-$(CONFIG_DGAP) += dgap/ > > > obj-$(CONFIG_MTD_SPINAND_MT29F) += mt29f_spinand/ > > > +obj-$(CONFIG_CRYPTO_SKEIN) += skein/ > > > > Care to align these up with the way this file is formatted? > > Of course, not sure what happened there (well, other than the obvious > :-P) > > > And I have no objection to taking the drivers/staging/ patches, the > > script looks useful, but I can't take it through the staging tree, > > sorry. > > Ok, I'll pull that out as a separate branch. Do you mind taking a > series that depends on a topic branch from another tree? We do it a lot > in arm-soc, but I'm not sure how popular that is elsewhere. It's not a dependancy at all, and I don't take git pull requests for the staging tree, just email patches, sorry. So just resend these patches thanks. greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Staging: bcm: CmHost: moved and removed declarations and tmp bracing.
On Mon, Mar 17, 2014 at 08:21:34PM -0400, Gary Rookard wrote: > Firstly, some background is needed to confirm the validity of > this patch as error fixing. It seems the developer when writing > this driver from scratch, used what are known to me as error > suppressors in the form of extra tmp bracing added to the case labels. > They aid during construction time, but are not intended to remain. > > In this scenario there are declarations occupying space only > reserved for statements. If these tmp braces were to be removed > before the declarations in question were reassigned to there > proper place in the funtion, compile time errors would result. > > So, having that said, I moved the declarations, > UINT uiSearchRuleIndex = 0; and ULONG ulSFID;, > and also deleted the duplicates thereof from > the switch/case statement. > > Removed temporary bracing from case labels. > > Removed new lines as needed. > > Properly indented case breaks. > > Signed-off-by: Gary Rookard > > --- > On branch staging-next > drivers/staging/bcm/CmHost.c | 38 -- > 1 file changed, 8 insertions(+), 30 deletions(-) > > diff --git a/drivers/staging/bcm/CmHost.c b/drivers/staging/bcm/CmHost.c > index cc82588..8d46b38 100644 > --- a/drivers/staging/bcm/CmHost.c > +++ b/drivers/staging/bcm/CmHost.c > @@ -1635,7 +1635,8 @@ bool CmControlResponseMessage(struct bcm_mini_adapter > *Adapter, /*struct bcm_add_indication_alt *pstAddIndication = NULL; > struct bcm_change_indication *pstChangeIndication = NULL; > struct bcm_leader *pLeader = NULL; > - > + UINT uiSearchRuleIndex = 0; > + ULONG ulSFID; > /* For the 3rd (or is it 4th?) time, please put a new line after the variable definition and before the comment. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: r8188eu: memory leak in rtw_free_cmd_obj if command is (_Set_Drv_Extra)
On Tue, Mar 18, 2014 at 10:25:27AM -0400, Wang, Xiaoming wrote:
> pcmd->parmbuf->pbuf has been allocated if command is
> GEN_CMD_CODE(_Set_Drv_Extra),
> and it enqueued by rtw_enqueue_cmd. rtw_cmd_thread dequeue pcmd by
> rtw_dequeue_cmd.
> The memory leak happened on this branch "if( _FAIL ==
> rtw_cmd_filter(pcmdpriv, pcmd) )"
> which goto post_process directly against freeing pcmd->parmbuf->pbuf in
> rtw_drvextra_cmd_hdl which is the cmd_hdl if command is (_Set_Drv_Extra).
> This patch free pcmd->parmbuf->pbuf on the forgotten branch to avoid memory
> leak.
>
> Signed-off-by: Zhang Dongxing
> Signed-off-by: xiaoming wang
You obviously didn't test this as it breaks the build :(
{sigh}
Please retry after 3.15-rc1 is out.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: dgap: Fixed sparse error: same symbol redeclared with different type
On Thu, Mar 13, 2014 at 03:02:59AM -0700, Masood Mehmood wrote: > sparse reported dgap_do_fep_load is redeclared with different type. while > fixing, I noticed __user attribute is used incorrectly in declaration. > There is no need to define __user for firware->data. > > Replaced the __user with 'const uchar *' from function dgap_do_fep_load and > did the same for function dgap_do_bios_load > > patch generated against: next-20140317 > > Signed-off-by: Masood Mehmood > --- > drivers/staging/dgap/dgap.c | 13 ++--- > 1 file changed, 6 insertions(+), 7 deletions(-) This patch does not apply to my staging-next branch, sorry. Please redo it and resend. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: slicoss: Fix prefer ether_addr_copy over memcpy
On Mon, Mar 17, 2014 at 09:17:35PM -0600, Joel Pelaez Jorge wrote: > This patch fixes the following checkpatch.pl issues caused by the new > function: ether_addr_copy > > Signed-off-by: Joel Pelaez Jorge > --- > diff --git a/drivers/staging/slicoss/slicoss.c > b/drivers/staging/slicoss/slicoss.c > index 12aafe3..4ff39aa 100644 > --- a/drivers/staging/slicoss/slicoss.c > +++ b/drivers/staging/slicoss/slicoss.c > @@ -2313,7 +2313,7 @@ static int slic_mcast_add_list(struct adapter > *adapter, char *address) > if (mcaddr == NULL) > return 1; > > -memcpy(mcaddr->address, address, ETH_ALEN); > +ether_addr_copy(mcaddr->address, address); > > mcaddr->next = adapter->mcastaddrs; > adapter->mcastaddrs = mcaddr; The patch is line-wrapped, and tabs converted to spaces, making it impossible to apply the patch. Please fix your email client and try again. greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] Staging: bcm: CmHost: moved and removed declarations and tmp bracing.
Firstly, some background is needed to confirm the validity of
this patch as error fixing. It seems the developer when writing
this driver from scratch, used what are known to me as error
suppressors in the form of extra tmp bracing added to the case labels.
They aid during construction time, but are not intended to remain.
In this scenario there are declarations occupying space only
reserved for statements. If these tmp braces were to be removed
before the declarations in question were reassigned to there
proper place in the funtion, compile time errors would result.
So, having that said, I moved the declarations,
UINT uiSearchRuleIndex = 0; and ULONG ulSFID;,
and also deleted the duplicates thereof from
the switch/case statement.
Removed temporary bracing from case labels.
Removed new lines as needed.
Properly indented case breaks.
Added /* FALLTHROUGH */ comments to switch/case.
Signed-off-by: Gary Rookard
---
drivers/staging/bcm/CmHost.c | 39 ++-
1 file changed, 10 insertions(+), 29 deletions(-)
diff --git a/drivers/staging/bcm/CmHost.c b/drivers/staging/bcm/CmHost.c
index cc82588..632f81a 100644
--- a/drivers/staging/bcm/CmHost.c
+++ b/drivers/staging/bcm/CmHost.c
@@ -1635,6 +1635,8 @@ bool CmControlResponseMessage(struct bcm_mini_adapter
*Adapter, /* u16TID);
switch (pstAddIndication->u8Type) {
case DSA_REQ:
- {
pLeader->PLength = sizeof(struct bcm_add_indication_alt);
BCM_DEBUG_PRINT(Adapter, DBG_TYPE_OTHERS, CONN_MSG,
DBG_LVL_ALL, "Sending DSA Response\n");
BCM_DEBUG_PRINT(Adapter, DBG_TYPE_OTHERS, CONN_MSG,
DBG_LVL_ALL, "SENDING DSA RESPONSE TO MAC %d", pLeader->PLength);
@@ -1669,22 +1670,16 @@ bool CmControlResponseMessage(struct bcm_mini_adapter
*Adapter, /* u16VCID));
CopyBufferToControlPacket(Adapter,
(PVOID)Adapter->caDsxReqResp);
kfree(pstAddIndication);
- }
- break;
+ break;
case DSA_RSP:
- {
pLeader->PLength = sizeof(struct bcm_add_indication_alt);
BCM_DEBUG_PRINT(Adapter, DBG_TYPE_OTHERS, CONN_MSG,
DBG_LVL_ALL, "SENDING DSA ACK TO MAC %d",
pLeader->PLength);
*((struct bcm_add_indication_alt
*)&(Adapter->caDsxReqResp[LEADER_SIZE]))
= *pstAddIndication;
((struct bcm_add_indication_alt
*)&(Adapter->caDsxReqResp[LEADER_SIZE]))->u8Type = DSA_ACK;
-
- } /* no break here..we should go down. */
+ /* FALLTHROUGH */
case DSA_ACK:
- {
- UINT uiSearchRuleIndex = 0;
-
BCM_DEBUG_PRINT(Adapter, DBG_TYPE_OTHERS, CONN_MSG,
DBG_LVL_ALL, "VCID:0x%X",
ntohs(pstAddIndication->u16VCID));
uiSearchRuleIndex = SearchFreeSfid(Adapter);
@@ -1767,10 +1762,8 @@ bool CmControlResponseMessage(struct bcm_mini_adapter
*Adapter, /* PLength = sizeof(struct bcm_change_indication);
pstChangeIndication = (struct bcm_change_indication
*)pstAddIndication;
BCM_DEBUG_PRINT(Adapter, DBG_TYPE_OTHERS, CONN_MSG,
DBG_LVL_ALL, "SENDING DSC RESPONSE TO MAC %d", pLeader->PLength);
@@ -1780,20 +1773,15 @@ bool CmControlResponseMessage(struct bcm_mini_adapter
*Adapter, /* caDsxReqResp);
kfree(pstAddIndication);
- }
- break;
+ break;
case DSC_RSP:
- {
pLeader->PLength = sizeof(struct bcm_change_indication);
pstChangeIndication = (struct bcm_change_indication
*)pstAddIndication;
BCM_DEBUG_PRINT(Adapter, DBG_TYPE_OTHERS, CONN_MSG,
DBG_LVL_ALL, "SENDING DSC ACK TO MAC %d", pLeader->PLength);
*((struct bcm_change_indication
*)&(Adapter->caDsxReqResp[LEADER_SIZE])) = *pstChangeIndication;
((struct bcm_change_indication
*)&(Adapter->caDsxReqResp[LEADER_SIZE]))->u8Type = DSC_ACK;
- }
+ /* FALLTHROUGH */
case DSC_ACK:
- {
- UINT uiSearchRuleIndex = 0;
-
pstChangeIndication = (struct bcm_change_indication
*)pstAddIndication;
uiSearchRuleIndex = SearchSfid(Adapter,
ntohl(pstChangeIndication->sfActiveSet.u32SFID));
if (uiSearchRuleIndex > NO_OF_QUEUES-1)
@@ -1847,13 +1835,8 @@ bool CmControlResponseMessage(struct bcm_mini_adapter
*Adapter, /* PLength = sizeof(struct bcm_del_indication);
*((struct bcm_del_indication
*)&(Adapter->caDsxReqResp[LEADER_SIZE])) = *((struct bcm_del_indication
*)pstAddIndication);
@@ -1870,12 +1853,10 @@ bool CmControlResponseMessage(struct bcm_mini_adapter
*Adapter, /* caDsxReqResp[LEADER_SIZE]))->u8Type = DSD_RSP;
CopyBufferToControlPacket(Adapter,
(PVOID)Adapter->caDsxReqResp);
- }
+ /* FALLTHROUGH */
case DSD_RSP:
- {
/* Do nothing a
[patch][wip] staging: unisys: kmalloc/memset move to kzalloc
Hi, I have followed this thread and have seen that not all parts was kcalloc'ized. Please review this patch and maybe include it. This patch is WIP because I have no hardware and can only do a compile test. version 2: * remove ALLOC_CMDRSP define Bye, Silvio ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: unisys: kmalloc/memset to kzalloc conversation
This patch solves the Coccinelle warning: "kzalloc should be used
instead of kmalloc/memset"
This patch is a fixup for
linux-next: 97a84f1203786985856a0d4b49b1d7cc387238ce
"Staging: unisys: Replace kmalloc/memset with kzalloc"
The ALLOC_CMDRSP #define is after transformation to kzalloc only a
rename for kzalloc and was completly removed.
Signed-off-by: Silvio F
---
drivers/staging/unisys/include/uisutils.h | 7 ---
drivers/staging/unisys/virthba/virthba.c| 9 -
drivers/staging/unisys/virtpci/virtpci.c| 3 +--
drivers/staging/unisys/visorutil/memregion_direct.c | 5 ++---
drivers/staging/unisys/visorutil/periodic_work.c| 5 ++---
5 files changed, 9 insertions(+), 20 deletions(-)
diff --git a/drivers/staging/unisys/include/uisutils.h
b/drivers/staging/unisys/include/uisutils.h
index 81b5d9b..effd893 100644
--- a/drivers/staging/unisys/include/uisutils.h
+++ b/drivers/staging/unisys/include/uisutils.h
@@ -189,13 +189,6 @@ struct chaninfo {
schedule_timeout((x)*HZ); \
}
-#define ALLOC_CMDRSP(cmdrsp) { \
- cmdrsp = kmalloc(SIZEOF_CMDRSP, GFP_ATOMIC); \
- if (cmdrsp != NULL) { \
- memset(cmdrsp, 0, SIZEOF_CMDRSP); \
- } \
-}
-
/* This is a hack until we fix IOVM to initialize the channel header
* correctly at DEVICE_CREATE time, INSTEAD OF waiting until
* DEVICE_CONFIGURE time.
diff --git a/drivers/staging/unisys/virthba/virthba.c
b/drivers/staging/unisys/virthba/virthba.c
index 8aefaa8..817b11d 100644
--- a/drivers/staging/unisys/virthba/virthba.c
+++ b/drivers/staging/unisys/virthba/virthba.c
@@ -402,9 +402,8 @@ process_disk_notify(struct Scsi_Host *shost, struct
uiscmdrsp *cmdrsp)
struct diskaddremove *dar;
unsigned long flags;
- dar = kmalloc(sizeof(struct diskaddremove), GFP_ATOMIC);
+ dar = kzalloc(sizeof(struct diskaddremove), GFP_ATOMIC);
if (dar) {
- memset(dar, 0, sizeof(struct diskaddremove));
dar->add = cmdrsp->disknotify.add;
dar->shost = shost;
dar->channel = cmdrsp->disknotify.channel;
@@ -697,7 +696,7 @@ forward_vdiskmgmt_command(VDISK_MGMT_TYPES vdiskcmdtype,
return FAILED;
}
- ALLOC_CMDRSP(cmdrsp);
+ cmdrsp = kzalloc(SIZEOF_CMDRSP, GFP_ATOMIC);
if (cmdrsp == NULL) {
LOGERR("kmalloc of cmdrsp failed.\n");
return FAILED; /* reject */
@@ -759,7 +758,7 @@ forward_taskmgmt_command(TASK_MGMT_TYPES tasktype, struct
scsi_device *scsidev)
return FAILED;
}
- ALLOC_CMDRSP(cmdrsp);
+ cmdrsp = kzalloc(SIZEOF_CMDRSP, GFP_ATOMIC);
if (cmdrsp == NULL) {
LOGERR("kmalloc of cmdrsp failed.\n");
return FAILED; /* reject */
@@ -930,7 +929,7 @@ virthba_queue_command_lck(struct scsi_cmnd *scsicmd,
return SCSI_MLQUEUE_DEVICE_BUSY;
}
- ALLOC_CMDRSP(cmdrsp);
+ cmdrsp = kzalloc(SIZEOF_CMDRSP, GFP_ATOMIC);
if (cmdrsp == NULL) {
LOGERR("kmalloc of cmdrsp failed.\n");
return 1; /* reject the command */
diff --git a/drivers/staging/unisys/virtpci/virtpci.c
b/drivers/staging/unisys/virtpci/virtpci.c
index 1b64632..8e34650 100644
--- a/drivers/staging/unisys/virtpci/virtpci.c
+++ b/drivers/staging/unisys/virtpci/virtpci.c
@@ -254,13 +254,12 @@ static int add_vbus(struct add_vbus_guestpart *addparams)
{
int ret;
struct device *vbus;
- vbus = kmalloc(sizeof(struct device), GFP_ATOMIC);
+ vbus = kzalloc(sizeof(struct device), GFP_ATOMIC);
POSTCODE_LINUX_2(VPCI_CREATE_ENTRY_PC, POSTCODE_SEVERITY_INFO);
if (!vbus)
return 0;
- memset(vbus, 0, sizeof(struct device));
dev_set_name(vbus, "vbus%d", addparams->busNo);
vbus->release = virtpci_bus_release;
vbus->parent = &virtpci_rootbus_device; /* root bus is parent */
diff --git a/drivers/staging/unisys/visorutil/memregion_direct.c
b/drivers/staging/unisys/visorutil/memregion_direct.c
index 82c651d..b9b61e8 100644
--- a/drivers/staging/unisys/visorutil/memregion_direct.c
+++ b/drivers/staging/unisys/visorutil/memregion_direct.c
@@ -41,13 +41,12 @@ MEMREGION *
visor_memregion_create(HOSTADDRESS physaddr, ulong nbytes)
{
MEMREGION *rc = NULL;
- MEMREGION *memregion = kmalloc(sizeof(MEMREGION),
- GFP_KERNEL|__GFP_NORETRY);
+ MEMREGION *memregion = kzalloc(sizeof(MEMREGION),
+ GFP_KERNEL | __GFP_NORETRY);
if (memregion == NULL) {
ERRDRV("visor_memregion_create allocation failed");
return NULL;
}
- memset(memregion, 0, sizeof(MEMREGION));
memregion->physaddr = physaddr;
memregion->nbytes = nbytes;
memregion->overlapped = FALSE;
diff --git a/drivers/staging/unisys/visor
[PATCH net-next, v3] hyperv: Add support for virtual Receive Side Scaling (vRSS)
This feature allows multiple channels to be used by each virtual NIC.
It is available on Hyper-V host 2012 R2.
Signed-off-by: Haiyang Zhang
Reviewed-by: K. Y. Srinivasan
---
drivers/net/hyperv/hyperv_net.h | 112 ++-
drivers/net/hyperv/netvsc.c | 134 +-
drivers/net/hyperv/netvsc_drv.c | 102 +++-
drivers/net/hyperv/rndis_filter.c | 187 -
4 files changed, 503 insertions(+), 32 deletions(-)
diff --git a/drivers/net/hyperv/hyperv_net.h b/drivers/net/hyperv/hyperv_net.h
index 13010b4..c2d72f6 100644
--- a/drivers/net/hyperv/hyperv_net.h
+++ b/drivers/net/hyperv/hyperv_net.h
@@ -28,6 +28,98 @@
#include
#include
+/* RSS related */
+#define OID_GEN_RECEIVE_SCALE_CAPABILITIES 0x00010203 /* query only */
+#define OID_GEN_RECEIVE_SCALE_PARAMETERS 0x00010204 /* query and set */
+
+#define NDIS_OBJECT_TYPE_RSS_CAPABILITIES 0x88
+#define NDIS_OBJECT_TYPE_RSS_PARAMETERS 0x89
+
+#define NDIS_RECEIVE_SCALE_CAPABILITIES_REVISION_2 2
+#define NDIS_RECEIVE_SCALE_PARAMETERS_REVISION_2 2
+
+struct ndis_obj_header {
+ u8 type;
+ u8 rev;
+ u16 size;
+} __packed;
+
+
+/* ndis_recv_scale_cap/cap_flag */
+#define NDIS_RSS_CAPS_MESSAGE_SIGNALED_INTERRUPTS 0x0100
+#define NDIS_RSS_CAPS_CLASSIFICATION_AT_ISR 0x0200
+#define NDIS_RSS_CAPS_CLASSIFICATION_AT_DPC 0x0400
+#define NDIS_RSS_CAPS_USING_MSI_X 0x0800
+#define NDIS_RSS_CAPS_RSS_AVAILABLE_ON_PORTS 0x1000
+#define NDIS_RSS_CAPS_SUPPORTS_MSI_X 0x2000
+#define NDIS_RSS_CAPS_HASH_TYPE_TCP_IPV4 0x0100
+#define NDIS_RSS_CAPS_HASH_TYPE_TCP_IPV6 0x0200
+#define NDIS_RSS_CAPS_HASH_TYPE_TCP_IPV6_EX 0x0400
+
+struct ndis_recv_scale_cap { /* NDIS_RECEIVE_SCALE_CAPABILITIES */
+ struct ndis_obj_header hdr;
+ u32 cap_flag;
+ u32 num_int_msg;
+ u32 num_recv_que;
+ u16 num_indirect_tabent;
+} __packed;
+
+
+/* ndis_recv_scale_param flags */
+#define NDIS_RSS_PARAM_FLAG_BASE_CPU_UNCHANGED 0x0001
+#define NDIS_RSS_PARAM_FLAG_HASH_INFO_UNCHANGED0x0002
+#define NDIS_RSS_PARAM_FLAG_ITABLE_UNCHANGED 0x0004
+#define NDIS_RSS_PARAM_FLAG_HASH_KEY_UNCHANGED 0x0008
+#define NDIS_RSS_PARAM_FLAG_DISABLE_RSS0x0010
+
+/* Hash info bits */
+#define NDIS_HASH_FUNC_TOEPLITZ 0x0001
+#define NDIS_HASH_IPV4 0x0100
+#define NDIS_HASH_TCP_IPV4 0x0200
+#define NDIS_HASH_IPV6 0x0400
+#define NDIS_HASH_IPV6_EX 0x0800
+#define NDIS_HASH_TCP_IPV6 0x1000
+#define NDIS_HASH_TCP_IPV6_EX 0x2000
+
+#define NDIS_RSS_INDIRECTION_TABLE_MAX_SIZE_REVISION_2 (128 * 4)
+#define NDIS_RSS_HASH_SECRET_KEY_MAX_SIZE_REVISION_2 40
+
+#define ITAB_NUM 128
+#define HASH_KEYLEN NDIS_RSS_HASH_SECRET_KEY_MAX_SIZE_REVISION_2
+extern u8 netvsc_hash_key[];
+
+struct ndis_recv_scale_param { /* NDIS_RECEIVE_SCALE_PARAMETERS */
+ struct ndis_obj_header hdr;
+
+ /* Qualifies the rest of the information */
+ u16 flag;
+
+ /* The base CPU number to do receive processing. not used */
+ u16 base_cpu_number;
+
+ /* This describes the hash function and type being enabled */
+ u32 hashinfo;
+
+ /* The size of indirection table array */
+ u16 indirect_tabsize;
+
+ /* The offset of the indirection table from the beginning of this
+* structure
+*/
+ u32 indirect_taboffset;
+
+ /* The size of the hash secret key */
+ u16 hashkey_size;
+
+ /* The offset of the secret key from the beginning of this structure */
+ u32 kashkey_offset;
+
+ u32 processor_masks_offset;
+ u32 num_processor_masks;
+ u32 processor_masks_entry_size;
+};
+
+
/* Fwd declaration */
struct hv_netvsc_packet;
struct ndis_tcp_ip_checksum_info;
@@ -39,6 +131,8 @@ struct xferpage_packet {
/* # of netvsc packets this xfer packet contains */
u32 count;
+
+ struct vmbus_channel *channel;
};
/*
@@ -54,6 +148,9 @@ struct hv_netvsc_packet {
bool is_data_pkt;
u16 vlan_tci;
+ u16 q_idx;
+ struct vmbus_channel *channel;
+
/*
* Valid only for receives when we break a xfer page packet
* into multiple netvsc packets
@@ -120,6 +217,7 @@ void netvsc_linkstatus_callback(struct hv_device
*device_obj,
int netvsc_recv_callback(struct hv_device *device_obj,
struct hv_netvsc_packet *packet,
struct ndis_tcp_ip_checksum_info *csum_info);
+extern void netvsc_channel_cb(void *context);
int rndis_filter_open(struct hv_device *dev);
int rndis_filter_close(struct hv_device *dev);
int rndis_filter_device_add(struct hv_device *dev,
@@ -522,6 +620,8 @@ struct nvsp_message {
#define NETVSC_PACKET_SIZE 2048
+#define VRSS_SEND_TAB_SIZE 16
+
/* Per netvsc channel-specific */
str
Re: [PATCH] Staging: bcm: CmHost: moved and removed declarations and tmp bracing.
On Tue, 18 Mar 2014, Greg KH wrote: On Mon, Mar 17, 2014 at 08:21:34PM -0400, Gary Rookard wrote: Firstly, some background is needed to confirm the validity of this patch as error fixing. It seems the developer when writing this driver from scratch, used what are known to me as error suppressors in the form of extra tmp bracing added to the case labels. They aid during construction time, but are not intended to remain. In this scenario there are declarations occupying space only reserved for statements. If these tmp braces were to be removed before the declarations in question were reassigned to there proper place in the funtion, compile time errors would result. So, having that said, I moved the declarations, UINT uiSearchRuleIndex = 0; and ULONG ulSFID;, and also deleted the duplicates thereof from the switch/case statement. Removed temporary bracing from case labels. Removed new lines as needed. Properly indented case breaks. Signed-off-by: Gary Rookard --- On branch staging-next drivers/staging/bcm/CmHost.c | 38 -- 1 file changed, 8 insertions(+), 30 deletions(-) diff --git a/drivers/staging/bcm/CmHost.c b/drivers/staging/bcm/CmHost.c index cc82588..8d46b38 100644 --- a/drivers/staging/bcm/CmHost.c +++ b/drivers/staging/bcm/CmHost.c @@ -1635,7 +1635,8 @@ bool CmControlResponseMessage(struct bcm_mini_adapter *Adapter, /* For the 3rd (or is it 4th?) time, please put a new line after the variable definition and before the comment. -- Yes, I'm a little dyslexic. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: line6: Fix coding style problem
From: Mikhail Boiko
Fix style issue for eudyptula challenge
Signed-off-by: Mikhail Boiko
---
--- a/drivers/staging/line6/capture.c.orig 2014-03-18 23:35:36.440486308 +0200
+++ a/drivers/staging/line6/capture.c 2014-03-18 23:35:40.660486377 +0200
@@ -157,6 +157,7 @@ void line6_capture_copy(struct snd_line6
copy two separate chunks.
*/
int len;
+
len = runtime->buffer_size - line6pcm->pos_in_done;
if (len > 0) {
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: cxt1e1: hwprobe: Fix sparse warning
This fixes the following sparse warning:
* drivers/staging/cxt1e1/hwprobe.c:43:19:
warning: symbol 'hdw_info' was not declared. Should it be static?
* drivers/staging/cxt1e1/hwprobe.c:47:1:
warning: symbol 'show_two' was not declared. Should it be static?
* drivers/staging/cxt1e1/hwprobe.c:99:1:
warning: symbol 'hdw_sn_get' was not declared. Should it be static?
*drivers/staging/cxt1e1/hwprobe.c:149:1:
warning: symbol 'prep_hdw_info' was not declared. Should it be static?
* drivers/staging/cxt1e1/hwprobe.c:169:1:
warning: symbol 'cleanup_ioremap' was not declared. Should it be static?
* drivers/staging/cxt1e1/hwprobe.c:195:1:
warning: symbol 'cleanup_devs' was not declared. Should it be static?
drivers/staging/cxt1e1/hwprobe.c:293:1:
* warning: symbol 'c4hw_attach_all' was not declared. Should it be static?
Signed-off-by: Matei Oprea
Cc: ROSEdu Kernel Community
---
drivers/staging/cxt1e1/hwprobe.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/cxt1e1/hwprobe.c b/drivers/staging/cxt1e1/hwprobe.c
index 02b4f8f..694047a 100644
--- a/drivers/staging/cxt1e1/hwprobe.c
+++ b/drivers/staging/cxt1e1/hwprobe.c
@@ -40,10 +40,10 @@ voidc4_stopwd (ci_t *);
struct net_device * __init c4_add_dev (hdw_info_t *, int, unsigned long,
unsigned long, int, int);
-struct s_hdw_info hdw_info[MAX_BOARDS];
+static struct s_hdw_info hdw_info[MAX_BOARDS];
-void__init
+static void__init
show_two (hdw_info_t *hi, int brdno)
{
ci_t *ci;
@@ -95,7 +95,7 @@ show_two (hdw_info_t *hi, int brdno)
}
-void__init
+static void__init
hdw_sn_get (hdw_info_t *hi, int brdno)
{
/* obtain hardware EEPROM information */
@@ -145,7 +145,7 @@ hdw_sn_get (hdw_info_t *hi, int brdno)
}
-void__init
+static void__init
prep_hdw_info (void)
{
hdw_info_t *hi;
@@ -165,7 +165,7 @@ prep_hdw_info (void)
}
}
-void
+static void
cleanup_ioremap (void)
{
hdw_info_t *hi;
@@ -191,7 +191,7 @@ cleanup_ioremap (void)
}
-void
+static void
cleanup_devs (void)
{
hdw_info_t *hi;
@@ -289,7 +289,7 @@ c4_hdw_init (struct pci_dev *pdev, int found)
}
-status_t__init
+static status_t__init
c4hw_attach_all (void)
{
hdw_info_t *hi;
--
1.7.9.5
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging/xillybus: Handle OOM in xillybus_init()
alloc_workqueue() can fail and returns NULL in case of
OOM.
Handle this case and undo class_create().
Signed-off-by: Richard Weinberger
---
drivers/staging/xillybus/xillybus_core.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/xillybus/xillybus_core.c
b/drivers/staging/xillybus/xillybus_core.c
index 2ebaf16..b0a6696 100644
--- a/drivers/staging/xillybus/xillybus_core.c
+++ b/drivers/staging/xillybus/xillybus_core.c
@@ -2318,8 +2318,12 @@ static int __init xillybus_init(void)
}
xillybus_wq = alloc_workqueue(xillyname, 0, 0);
+ if (!xillybus_wq) {
+ class_destroy(xillybus_class);
+ rc = -ENOMEM;
+ }
- return 0; /* Success */
+ return rc;
}
static void __exit xillybus_exit(void)
--
1.8.1.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: slicoss: Fix prefer ether_addr_copy over memcpy
El 17/03/14 23:49, Jingoo Han escribió: On Tuesday, March 18, 2014 2:04 PM, Joel Pelaez Jorge wrote: @@ -810,8 +810,8 @@ static int slic_mac_set_address(struct net_device *dev, void *ptr) if (!is_valid_ether_addr(addr->sa_data)) return -EINVAL; - memcpy(dev->dev_addr, addr->sa_data, dev->addr_len); - memcpy(adapter->currmacaddr, addr->sa_data, dev->addr_len); + ether_addr_copy(dev->dev_addr, addr->sa_data); + ether_addr_copy(adapter->currmacaddr, addr->sa_data); By the way, I am wondering if 'dev->addr_len' is 6 bytes. Is there anyone who can confirm it? If nobody can confirm 'dev->addr_len' is 6 bytes, it should not be changed to 'ether_addr_copy()'. Best regards, Jingoo Han In the first case, is necessary use memcpy for copy te ethernet address to dev->dev_addr because this is a pointer, uses dev->addr_len for define size. But in the second, adapter->currmacaddr is fixed to 6 size, so that here one can use ether_addr_copy without issues. -- Best regards, Joel Pelaez Jorge Joel Pelaez Jorge ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: cxt1e1: hwprobe: Fix sparse warning
On Wed, Mar 19, 2014 at 12:33:19AM +0200, Matei Oprea wrote: > This fixes the following sparse warning: > * drivers/staging/cxt1e1/hwprobe.c:43:19: > warning: symbol 'hdw_info' was not declared. Should it be static? > * drivers/staging/cxt1e1/hwprobe.c:47:1: > warning: symbol 'show_two' was not declared. Should it be static? > * drivers/staging/cxt1e1/hwprobe.c:99:1: > warning: symbol 'hdw_sn_get' was not declared. Should it be static? > *drivers/staging/cxt1e1/hwprobe.c:149:1: > warning: symbol 'prep_hdw_info' was not declared. Should it be static? > * drivers/staging/cxt1e1/hwprobe.c:169:1: > warning: symbol 'cleanup_ioremap' was not declared. Should it be static? > * drivers/staging/cxt1e1/hwprobe.c:195:1: > warning: symbol 'cleanup_devs' was not declared. Should it be static? > drivers/staging/cxt1e1/hwprobe.c:293:1: > * warning: symbol 'c4hw_attach_all' was not declared. Should it be static? > > Signed-off-by: Matei Oprea > Cc: ROSEdu Kernel Community Why the cc: for a non-maintainer / person? curious, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: cxt1e1: hwprobe: Fix sparse warning
On Wed, Mar 19, 2014 at 12:33:19AM +0200, Matei Oprea wrote: > This fixes the following sparse warning: > * drivers/staging/cxt1e1/hwprobe.c:43:19: > warning: symbol 'hdw_info' was not declared. Should it be static? > * drivers/staging/cxt1e1/hwprobe.c:47:1: > warning: symbol 'show_two' was not declared. Should it be static? > * drivers/staging/cxt1e1/hwprobe.c:99:1: > warning: symbol 'hdw_sn_get' was not declared. Should it be static? > *drivers/staging/cxt1e1/hwprobe.c:149:1: > warning: symbol 'prep_hdw_info' was not declared. Should it be static? > * drivers/staging/cxt1e1/hwprobe.c:169:1: > warning: symbol 'cleanup_ioremap' was not declared. Should it be static? > * drivers/staging/cxt1e1/hwprobe.c:195:1: > warning: symbol 'cleanup_devs' was not declared. Should it be static? > drivers/staging/cxt1e1/hwprobe.c:293:1: > * warning: symbol 'c4hw_attach_all' was not declared. Should it be static? Please don't line-wrap sparse or compiler warnings, it just looks messy. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: cxt1e1: hwprobe: Fix sparse warning
On Wed, Mar 19, 2014 at 12:33:19AM +0200, Matei Oprea wrote:
> This fixes the following sparse warning:
> * drivers/staging/cxt1e1/hwprobe.c:43:19:
> warning: symbol 'hdw_info' was not declared. Should it be static?
> * drivers/staging/cxt1e1/hwprobe.c:47:1:
> warning: symbol 'show_two' was not declared. Should it be static?
> * drivers/staging/cxt1e1/hwprobe.c:99:1:
> warning: symbol 'hdw_sn_get' was not declared. Should it be static?
> *drivers/staging/cxt1e1/hwprobe.c:149:1:
> warning: symbol 'prep_hdw_info' was not declared. Should it be static?
> * drivers/staging/cxt1e1/hwprobe.c:169:1:
> warning: symbol 'cleanup_ioremap' was not declared. Should it be static?
> * drivers/staging/cxt1e1/hwprobe.c:195:1:
> warning: symbol 'cleanup_devs' was not declared. Should it be static?
> drivers/staging/cxt1e1/hwprobe.c:293:1:
> * warning: symbol 'c4hw_attach_all' was not declared. Should it be static?
>
> Signed-off-by: Matei Oprea
> Cc: ROSEdu Kernel Community
> ---
> drivers/staging/cxt1e1/hwprobe.c | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/staging/cxt1e1/hwprobe.c
> b/drivers/staging/cxt1e1/hwprobe.c
> index 02b4f8f..694047a 100644
> --- a/drivers/staging/cxt1e1/hwprobe.c
> +++ b/drivers/staging/cxt1e1/hwprobe.c
> @@ -40,10 +40,10 @@ voidc4_stopwd (ci_t *);
> struct net_device * __init c4_add_dev (hdw_info_t *, int, unsigned long,
> unsigned long, int, int);
>
>
> -struct s_hdw_info hdw_info[MAX_BOARDS];
> +static struct s_hdw_info hdw_info[MAX_BOARDS];
>
>
> -void__init
> +static void__init
> show_two (hdw_info_t *hi, int brdno)
> {
> ci_t *ci;
> @@ -95,7 +95,7 @@ show_two (hdw_info_t *hi, int brdno)
This patch doesn't apply at all, did you do it against my staging-next
branch of staging.git or linux-next? Or did you do it against Linus's
tree? If Linus's tree, that's quite "old" for development stuff, always
work against linux-next to avoid making the same changes others already
have in the past.
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging/xillybus: Handle OOM in xillybus_init()
Hi,
I stand (shamefully) corrected. Thanks.
Eli
On 19/03/14 01:07, Richard Weinberger wrote:
alloc_workqueue() can fail and returns NULL in case of
OOM.
Handle this case and undo class_create().
Signed-off-by: Richard Weinberger
---
drivers/staging/xillybus/xillybus_core.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/xillybus/xillybus_core.c
b/drivers/staging/xillybus/xillybus_core.c
index 2ebaf16..b0a6696 100644
--- a/drivers/staging/xillybus/xillybus_core.c
+++ b/drivers/staging/xillybus/xillybus_core.c
@@ -2318,8 +2318,12 @@ static int __init xillybus_init(void)
}
xillybus_wq = alloc_workqueue(xillyname, 0, 0);
+ if (!xillybus_wq) {
+ class_destroy(xillybus_class);
+ rc = -ENOMEM;
+ }
- return 0; /* Success */
+ return rc;
}
static void __exit xillybus_exit(void)
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: unisys: use kzalloc instead of kmalloc/memset 0
Hi, greg. Review my comment below. Thanks. Daeseok Youn. 2014-03-18 17:11 GMT+09:00 DaeSeok Youn : > 2014-03-18 9:37 GMT+09:00 Greg KH : >> On Tue, Mar 18, 2014 at 09:26:07AM +0900, DaeSeok Youn wrote: >>> I think vmalloc/kmalloc in uislib_malloc() can be removed and just use >>> vmalloc/kmalloc directly. >> >> Yes. Actually, just use kmalloc, I don't knwo why vmalloc is being >> used, but cc: the driver maintainers just to be sure. > > It try to allocate 128KiB(131072byte) with vmalloc(). I think if it > trying to allocate with kmalloc() > it has a possibility to fail because of memory fragmentation even if > system has enough memory to use. > Just my opinion. If I'm wrong, let me know. > >> >>> (UISMALLOC() macro is also removed.) >> >> Yes. >> >>> And uislib_malloc() is renamed to "uislib_trace_buffer_status()" which >>> is just tracing buffer status(Malloc_FailuresAlloc, Malloc_BytesInUse >>> ...) for info_proc_read_helper(). >> >> The whole tracing stuff needs to be ripped out, so no problem deleting >> it here as well. > > OK. I will remove that information in info_proc_read_helper(). > >> >>> If this change is accepted, it also need to change uislib_free(). >> >> Drop it and just use kfree(). > OK. replace kfree() with uislib_free(). > >> >> thanks, >> >> greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: unisys: use kzalloc instead of kmalloc/memset 0
Hi, Ken
Thanks for review.
But I have a question, I wan to know why tracing buffer
status(Malloc_FailuresAlloc, Malloc_BytesInUse...) for
info_proc_read_helper() are needed.
If it doesn't need, whole tracing stuff for memory can be removed.
After getting a reply from you and greg, I will make a patch.
Regards,
Daeseok Youn.
2014-03-18 22:00 GMT+09:00 Ken Cox :
>
> On 03/17/2014 07:26 PM, DaeSeok Youn wrote:
>>
>> I think vmalloc/kmalloc in uislib_malloc() can be removed and just use
>> vmalloc/kmalloc directly.
>> (UISMALLOC() macro is also removed.)
>> And uislib_malloc() is renamed to "uislib_trace_buffer_status()" which
>> is just tracing buffer status(Malloc_FailuresAlloc, Malloc_BytesInUse
>> ...) for info_proc_read_helper().
>>
>> If this change is accepted, it also need to change uislib_free().
>>
>> Is it fine to change like this?
>
> This change is fine with me. It makes the logic easier to follow.
>
>>
>> Thanks.
>> Daeseok Youn.
>>
>> 2014-03-18 6:41 GMT+09:00 Greg KH :
>>>
>>> On Wed, Mar 12, 2014 at 07:37:50PM +0900, Daeseok Youn wrote:
Signed-off-by: Daeseok Youn
---
drivers/staging/unisys/uislib/uislib.c |5 +
drivers/staging/unisys/uislib/uisutils.c |2 +-
2 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/unisys/uislib/uislib.c
b/drivers/staging/unisys/uislib/uislib.c
index d77df9a..9748fcb 100644
--- a/drivers/staging/unisys/uislib/uislib.c
+++ b/drivers/staging/unisys/uislib/uislib.c
@@ -339,8 +339,6 @@ create_bus(CONTROLVM_MESSAGE *msg, char *buf)
return CONTROLVM_RESP_ERROR_KMALLOC_FAILED;
}
- memset(bus, 0, size);
-
/* Currently by default, the bus Number is the GuestHandle.
* Configure Bus message can override this.
*/
@@ -530,7 +528,6 @@ create_device(CONTROLVM_MESSAGE *msg, char *buf)
return CONTROLVM_RESP_ERROR_KMALLOC_FAILED;
}
- memset(dev, 0, sizeof(struct device_info));
dev->channelTypeGuid = msg->cmd.createDevice.dataTypeGuid;
dev->intr = msg->cmd.createDevice.intr;
dev->channelAddr = msg->cmd.createDevice.channelAddr;
@@ -1437,7 +1434,7 @@ uislib_malloc(size_t siz, gfp_t gfp, U8
contiguous, char *fn, int ln)
* get memory for you (like, invoke oom killer), which
* will probably cripple the system.
*/
- p = kmalloc(siz, gfp | __GFP_NORETRY);
+ p = kzalloc(siz, gfp | __GFP_NORETRY);
}
if (p == NULL) {
LOGERR("uislib_malloc failed to alloc %d bytes @%s:%d",
diff --git a/drivers/staging/unisys/uislib/uisutils.c
b/drivers/staging/unisys/uislib/uisutils.c
index 208b7ea..2f05be1 100644
--- a/drivers/staging/unisys/uislib/uisutils.c
+++ b/drivers/staging/unisys/uislib/uisutils.c
@@ -294,7 +294,7 @@ ReqHandlerAdd(GUID switchTypeGuid,
rc = UISMALLOC(sizeof(*rc), GFP_ATOMIC);
if (!rc)
return NULL;
- memset(rc, 0, sizeof(*rc));
+
rc->switchTypeGuid = switchTypeGuid;
rc->controlfunc = controlfunc;
rc->min_channel_bytes = min_channel_bytes;
>>>
>>> Can you just remove the UISMALLOC() macro completly, so that it's easier
>>> to verify that changes like this are actually correct?
>>>
>>> thanks,
>>>
>>> greg k-h
>
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: unisys: use kzalloc instead of kmalloc/memset 0
A: No. Q: Should I include quotations after my reply? http://daringfireball.net/2007/07/on_top On Wed, Mar 19, 2014 at 09:09:59AM +0900, DaeSeok Youn wrote: > Hi, Ken > Thanks for review. > > But I have a question, I wan to know why tracing buffer > status(Malloc_FailuresAlloc, Malloc_BytesInUse...) for > info_proc_read_helper() are needed. > If it doesn't need, whole tracing stuff for memory can be removed. Yes, that is something that also should be removed. greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: unisys: use kzalloc instead of kmalloc/memset 0
On Wed, Mar 19, 2014 at 09:03:49AM +0900, DaeSeok Youn wrote: > Hi, greg. > > Review my comment below. What comment? confused, greg k-h- ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: wlags49_h2: Coding style correction
On Wed, Mar 19, 2014 at 01:52:09AM +0100, Mathieu Maret wrote: > As the file was mixing tab and space, reindent the file > Mainly correct use of C99 comments, > space between parenthesis, > remove commented code > > Signed-off-by: Mathieu Maret > --- > drivers/staging/wlags49_h2/wl_netdev.c | 1990 > > 1 file changed, 1007 insertions(+), 983 deletions(-) That's way too big to review easily, can you do that? :) Please break it up into "do one thing at a time" type patch, so that it can be reviewed and applied properly. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: unisys: use kzalloc instead of kmalloc/memset 0
oh... You didn't get my reply about vmalloc usage. My replay attach again, below. > 2014-03-18 9:37 GMT+09:00 Greg KH : >> On Tue, Mar 18, 2014 at 09:26:07AM +0900, DaeSeok Youn wrote: >>> I think vmalloc/kmalloc in uislib_malloc() can be removed and just use >>> vmalloc/kmalloc directly. >> >> Yes. Actually, just use kmalloc, I don't knwo why vmalloc is being >> used, but cc: the driver maintainers just to be sure. > Here, need to check by you. > It try to allocate 128KiB(131072byte) with vmalloc(). I think if it > trying to allocate with kmalloc() > it has a possibility to fail because of memory fragmentation even if > system has enough memory to use. > Just my opinion. If I'm wrong, let me know. > >> >>> (UISMALLOC() macro is also removed.) >> >> Yes. >> >>> And uislib_malloc() is renamed to "uislib_trace_buffer_status()" which >>> is just tracing buffer status(Malloc_FailuresAlloc, Malloc_BytesInUse >>> ...) for info_proc_read_helper(). >> >> The whole tracing stuff needs to be ripped out, so no problem deleting >> it here as well. > > OK. I will remove that information in info_proc_read_helper(). > >> >>> If this change is accepted, it also need to change uislib_free(). >> >> Drop it and just use kfree(). > OK. replace kfree() with uislib_free(). > >> >> thanks, >> >> greg k-h 2014-03-19 9:58 GMT+09:00 Greg KH : > On Wed, Mar 19, 2014 at 09:03:49AM +0900, DaeSeok Youn wrote: >> Hi, greg. >> >> Review my comment below. > > What comment? > > confused, > > greg k-h- ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: unisys: use kzalloc instead of kmalloc/memset 0
On Wed, Mar 19, 2014 at 10:04:40AM +0900, DaeSeok Youn wrote: > oh... > You didn't get my reply about vmalloc usage. > > My replay attach again, below. > > > 2014-03-18 9:37 GMT+09:00 Greg KH : > >> On Tue, Mar 18, 2014 at 09:26:07AM +0900, DaeSeok Youn wrote: > >>> I think vmalloc/kmalloc in uislib_malloc() can be removed and just use > >>> vmalloc/kmalloc directly. > >> > >> Yes. Actually, just use kmalloc, I don't knwo why vmalloc is being > >> used, but cc: the driver maintainers just to be sure. > > > Here, need to check by you. > > It try to allocate 128KiB(131072byte) with vmalloc(). I think if it > > trying to allocate with kmalloc() > > it has a possibility to fail because of memory fragmentation even if > > system has enough memory to use. > > Just my opinion. If I'm wrong, let me know. Check to see just how big you are allocating, you should know based on the flags which code path happened uislib_malloc(). Just keep the logic the same and you should be fine. greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] STAGING: comedi: title block update
Follow up patch for "STAGING: comedi: style and checkpatch fixes". Removes the file name in the comment block per suggestions. Signed-off-by: Michael Welling --- diff --git a/drivers/staging/comedi/proc.c b/drivers/staging/comedi/proc.c index 7a5bf5b..91dea25 100644 --- a/drivers/staging/comedi/proc.c +++ b/drivers/staging/comedi/proc.c @@ -1,5 +1,4 @@ /* - * module/proc.c * /proc interface for comedi * * COMEDI - Linux Control and Measurement Device Interface ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: unisys: use kzalloc instead of kmalloc/memset 0
Thanks for reply. I will do that. Regards, Daeseok Youn. 2014-03-19 11:31 GMT+09:00 Greg KH : > On Wed, Mar 19, 2014 at 10:04:40AM +0900, DaeSeok Youn wrote: >> oh... >> You didn't get my reply about vmalloc usage. >> >> My replay attach again, below. >> >> > 2014-03-18 9:37 GMT+09:00 Greg KH : >> >> On Tue, Mar 18, 2014 at 09:26:07AM +0900, DaeSeok Youn wrote: >> >>> I think vmalloc/kmalloc in uislib_malloc() can be removed and just use >> >>> vmalloc/kmalloc directly. >> >> >> >> Yes. Actually, just use kmalloc, I don't knwo why vmalloc is being >> >> used, but cc: the driver maintainers just to be sure. >> > >> Here, need to check by you. >> > It try to allocate 128KiB(131072byte) with vmalloc(). I think if it >> > trying to allocate with kmalloc() >> > it has a possibility to fail because of memory fragmentation even if >> > system has enough memory to use. >> > Just my opinion. If I'm wrong, let me know. > > Check to see just how big you are allocating, you should know based on > the flags which code path happened uislib_malloc(). > > Just keep the logic the same and you should be fine. > > greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] STAGING: comedi: title block update
On Tue, Mar 18, 2014 at 11:24:31PM -0500, michael wrote: > Follow up patch for "STAGING: comedi: style and checkpatch fixes". > Removes the file name in the comment block per suggestions. > > Signed-off-by: Michael Welling Minor problem for future patches, your "From:" line doesn't match your "Signed-off-by:" line. You can either fix your email client, or you can add the "From:" line to the patch body itself, as described in Documentation/SubmittingPatches. Don't worry about it this time, I'll just edit it by hand. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [firefly] [PATCH] staging: cxt1e1: hwprobe: Fix sparse warning
>> Signed-off-by: Matei Oprea >> Cc: ROSEdu Kernel Community > > Why the cc: for a non-maintainer / person? We try to keep track of student's contributions in this way. Also, patches are internally reviewed on this mailing list before sending them to maintainers. thanks, Daniel. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
