Re: [PATCH v3 10/10] clocksource: import ARC timer driver

2016-11-10 Thread Daniel Lezcano 
On Thu, Nov 03, 2016 at 04:33:35PM -0700, Vineet Gupta wrote:
> This adds support for
> 
>  - CONFIG_ARC_TIMERS : legacy 32-bit TIMER0 and TIMER1 which count UP
>from @CNT to @LIMIT, before optionally triggering an interrupt.
>These are programmed using ARC auxiliary register interface.
>These are present in all ARC cores (ARC700 and ARC HS38)
>TIMER0 serves as clockevent for all ARC linux builds.
>TIMER1 is used for clocksource in arc700 builds.
> 
>  - CONFIG_ARC_TIMERS_64BIT: 64-bit counters, RTC and GFRC found in
>ARC HS38 cores. These are independnet IP blocks with different
>programming model respectively.
> 
> Signed-off-by: Vineet Gupta 
> ---

[ ... ]

>  config ARC
>   def_bool y
> + select ARC_TIMERS
>   select ARCH_SUPPORTS_ATOMIC_RMW if ARC_HAS_LLSC
>   select BUILDTIME_EXTABLE_SORT
> - select CLKSRC_OF
>   select CLONE_BACKWARDS
>   select COMMON_CLK
>   select GENERIC_ATOMIC64 if !ISA_ARCV2 || !(ARC_HAS_LL64 && ARC_HAS_LLSC)
> @@ -115,6 +115,7 @@ config ISA_ARCOMPACT
>  
>  config ISA_ARCV2
>   bool "ARC ISA v2"
> + select ARC_TIMERS_64BIT
>   help
> ISA for the Next Generation ARC-HS cores
>  
> @@ -410,10 +411,6 @@ config ARC_HAS_DIV_REM
>   bool "Insn: div, divu, rem, remu"
>   default y
>  
> -config ARC_TIMERS_64BIT
> - bool "64-bit r/o cycle counters RTC (up) and GFRC (smp)"
> - default y
> -
>  config ARC_NUMBER_OF_INTERRUPTS
>   int "Number of interrupts"
>   range 8 240
> diff --git a/arch/arc/kernel/Makefile b/arch/arc/kernel/Makefile
> index cfcdedf52ff8..8942c5c3b4c5 100644
> --- a/arch/arc/kernel/Makefile
> +++ b/arch/arc/kernel/Makefile
> @@ -8,7 +8,7 @@
>  # Pass UTS_MACHINE for user_regset definition
>  CFLAGS_ptrace.o  += -DUTS_MACHINE='"$(UTS_MACHINE)"'
>  
> -obj-y:= arcksyms.o setup.o irq.o time.o reset.o ptrace.o process.o 
> devtree.o
> +obj-y:= arcksyms.o setup.o irq.o reset.o ptrace.o process.o devtree.o
>  obj-y+= signal.o traps.o sys.o troubleshoot.o stacktrace.o disasm.o
>  obj-$(CONFIG_ISA_ARCOMPACT)  += entry-compact.o intc-compact.o
>  obj-$(CONFIG_ISA_ARCV2)  += entry-arcv2.o intc-arcv2.o
> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
> index e2c6e43cf8ca..a53bd50164e7 100644
> --- a/drivers/clocksource/Kconfig
> +++ b/drivers/clocksource/Kconfig
> @@ -282,6 +282,25 @@ config CLKSRC_MPS2
>   select CLKSRC_MMIO
>   select CLKSRC_OF
>  
> +config ARC_TIMERS
> + bool "Support for 32-bit TIMERn counters in ARC Cores" if COMPILE_TEST
> + depends on GENERIC_CLOCKEVENTS
> + select CLKSRC_OF
> + help
> +   These are legacy 32-bit TIMER0 and TIMER1 counters found on all ARC 
> cores
> +   (ARC700 as well as ARC HS38).
> +   TIMER0 serves as clockevent while TIMER1 provides clocksource
> +
> +config ARC_TIMERS_64BIT
> + bool "Support for 64-bit counters in ARC HS38 cores" if COMPILE_TEST
> + depends on GENERIC_CLOCKEVENTS
> + select CLKSRC_OF
> + help
> +   This enables 2 different 64-bit timers: RTC (for UP) and GFRC (for 
> SMP)
> +   RTC is implemented inside the core, while GFRC sits outside the core 
> in
> +   ARConnect IP block. Driver automatically picks one of them for 
> clocksource
> +   as appropriate.
> +
>  config ARM_ARCH_TIMER
>   bool
>   select CLKSRC_OF if OF
> diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
> index cf87f407f1ad..a14111e1f087 100644
> --- a/drivers/clocksource/Makefile
> +++ b/drivers/clocksource/Makefile
> @@ -51,6 +51,7 @@ obj-$(CONFIG_CLKSRC_TI_32K) += timer-ti-32k.o
>  obj-$(CONFIG_CLKSRC_NPS) += timer-nps.o
>  obj-$(CONFIG_OXNAS_RPS_TIMER)+= timer-oxnas-rps.o
>  
> +obj-$(CONFIG_ARC_TIMERS) += arc_timer.o

I don't see arc_timer.o compiled if ARC_TIMERS_64BIT only is set.

Wouldn't make sense to fold ARC_TIMERS and ARC_TIMERS_64BIT ?


___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH v2] drm/arcpgu: Accommodate adv7511 switch to DRM bridge

2016-11-10 Thread Alexey Brodkin 
Hi Daniel, David,

On Wed, 2016-11-02 at 12:23 +, Alexey Brodkin wrote:
> Hi Daniel, David,
> 
> On Mon, 2016-10-24 at 18:33 +, Alexey Brodkin wrote:
> > 
> > Hi Daniel,
> > 
> > > 
> > > 
> > > -Original Message-
> > > From: linux-snps-arc [mailto:linux-snps-arc-boun...@lists.infradead.org] 
> > > On Behalf Of Alexey Brodkin
> > > Sent: 19 октября 2016 г. 12:33
> > > To: dri-de...@lists.freedesktop.org; arch...@codeaurora.org; 
> > > eugeniy.palt...@synopsys.com
> > > Cc: linux-snps-arc@lists.infradead.org; linux-ker...@vger.kernel.org
> > > Subject: Re: [PATCH v2] drm/arcpgu: Accommodate adv7511 switch to DRM 
> > > bridge
> > > 
> > > Hi Archit, all,
> > > 
> > > On Wed, 2016-10-19 at 14:43 +0530, Archit Taneja wrote:
> > > > 
> > > > 
> > > > 
> > > > On 10/19/2016 01:16 PM, Eugeniy Paltsev wrote:
> > > > > 
> > > > > 
> > > > > 
> > > > > ARC PGU driver starts crashing on initialization after
> > > > > 'commit e12c2f645557 ("drm/i2c: adv7511: Convert to drm_bridge")'
> > > > > This happenes because in "arcpgu_drm_hdmi_init" function we get 
> > > > > pointer
> > > > > of "drm_i2c_encoder_driver" structure, which doesn't exist after
> > > > > adv7511 hdmi encoder interface changed from slave encoder to drm 
> > > > > bridge.
> > > > > So, when we call "encoder_init" function from this structure driver
> > > > > crashes.
> > > 
> > > [snip]
> > > 
> > > > 
> > > > 
> > > > Looks good now.
> > > > 
> > > > Reviewed-by: Archit Taneja 
> > > 
> > > And IMHO it would be really good to get this one back-ported to 4.8
> > > because it really fixes kernel crash if ARC PGU driver is used.
> > > 
> > > It might be a bit of a problem because patch itself a little-bit larger
> > > than formal requirement for stable backports but let's see if it gets 
> > > accepted.
> > 
> > Could you please pick this one up?
> > I may alternatively send a pull-request to David but not sure if 1 patch 
> > worth it.
> > 
> > Also if that's not really too late it would be good to get this one in 4.9 
> > since the patch
> > In question fixes a real driver crash on its instantiation.
> > Actually driver crash happens since 4.8 but I failed to notice it earlier 
> > and given amount
> > of changes I think there's barely a chance for it it to be accepted in 
> > stable branches...
> > which in its turn makes at least 4.9 very desirable.
> 
> Any chance this one gets accepted anytime soon?

Please treat this as another polite reminder to apply this patch.
If you prefer I may send a pull-request otherwise.

Regards,
Alexey
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH v3 0/3] dmaengine: DW DMAC: split pdata to hardware properties

2016-11-10 Thread Eugeniy Paltsev 
On Tue, 2016-11-08 at 15:36 +0200, Andy Shevchenko wrote:
> On Tue, 2016-11-08 at 12:22 +, Eugeniy Paltsev wrote:
> > 
> > On Mon, 2016-11-07 at 15:55 +0200, Andy Shevchenko wrote:
>  
> > 
> > > 
> > > > 
> > > > + * @only_quirks_used: Only read quirks (like "is_private" or
> > > > "is_memcpy") from
> > > > + * platform data structure. Read other parameters from
> > > > device
> > > > tree
> > > > + * node (if exists) or from hardware autoconfig
> > > > registers.
> > > Can you somehow be more clear that all listed quirks will be
> > > copied
> > > from
> > > platform data.
> > See comment below.
> > 
> > > 
> > >  
> > > > 
> > > >  
> > > >    * @is_nollp: The device channels does not support multi
> > > > block
> > > > transfers.
> > > >    * @chan_allocation_order: Allocate channels starting from 0
> > > > or
> > > > 7
> > > >    * @chan_priority: Set channel priority increasing from 0 to
> > > > 7
> > > > or
> > > > 7
> > > > to 0.
> > > > @@ -52,6 +55,7 @@ struct dw_dma_platform_data {
> > > >     unsigned intnr_channels;
> > > >     boolis_private;
> > > >     boolis_memcpy;
> > > >  
> > > > +   boolonly_quirks_used;
> > > Perhaps add if at the end of quirk list and name just 
> > >  
> > > > 
> > > >  
> > > >     boolis_nollp;
> > > ...here
> > >  
> > > bool use_quirks;
> What do think about shorten name?
> 
I don't know better short and understandable name for "use_quirks"
variable. You can suggest your ideas if you want.

> > 
> > I don't treat "is_nollp" as quirks like "is_private" or
> > "is_memcpy".
> > It is like general pdata field: we can easily read it from
> > autoconfig
> > registers (and we don't have any problem with that) in case of
> > pdata/device-tree absence (as opposed to quirks like "is_private"
> > or
> > "is_memcpy")
> > 
> > So, in PATCH v3 series "is_nollp" used as regular pdata field.
> I still would consider is_nollp as a quirk since nothing prevents to
> override the hardware value (see Intel Quark case).
> 
Do you mean this issue:
http://www.spinics.net/lists/linux-serial/msg22948.html
?

As I remember, we had problems with next code:
>8--
channel_writel(dwc, LLP, DWC_LLP_LOC(0x));
dwc->nollp = DWC_LLP_LOC(channel_readl(dwc, LLP)) == 0;
channel_writel(dwc, LLP, 0);
>8--
which was executed if we didn't use autoconfig registers.
This code doesn't used anymore.

And we don't have any problems with autoconfig registers!

So in case of Intel Quark we will read "nollp" parameter from pdata or
from autoconfig registers (in case of pdata absence). It should work
fine in both cases.
Please correct me if I'm wrong.

So, in my opinion, "is_nollp" should be used as regular pdata field.
-- 
 Paltsev Eugeniy
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

[PATCH v2 10/11] pcmcia: fix return value of soc_pcmcia_regulator_set

2016-11-10 Thread Arnd Bergmann 
The newly introduced soc_pcmcia_regulator_set() function sometimes returns
without setting its return code, as shown by this warning:

drivers/pcmcia/soc_common.c: In function 'soc_pcmcia_regulator_set':
drivers/pcmcia/soc_common.c:112:5: error: 'ret' may be used uninitialized in 
this function [-Werror=maybe-uninitialized]

This changes it to propagate the regulator_disable() result instead.

Fixes: ac61b6001a63 ("pcmcia: soc_common: add support for Vcc and Vpp 
regulators")
Signed-off-by: Arnd Bergmann 
---
 drivers/pcmcia/soc_common.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pcmcia/soc_common.c b/drivers/pcmcia/soc_common.c
index 153f312..b6b316d 100644
--- a/drivers/pcmcia/soc_common.c
+++ b/drivers/pcmcia/soc_common.c
@@ -107,7 +107,7 @@ int soc_pcmcia_regulator_set(struct soc_pcmcia_socket *skt,
 
ret = regulator_enable(r->reg);
} else {
-   regulator_disable(r->reg);
+   ret = regulator_disable(r->reg);
}
if (ret == 0)
r->on = on;
-- 
2.9.0


___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

[PATCH v2 05/11] s390: pci: don't print uninitialized data for debugging

2016-11-10 Thread Arnd Bergmann 
gcc correctly warns about an incorrect use of the 'pa' variable
in case we pass an empty scatterlist to __s390_dma_map_sg:

arch/s390/pci/pci_dma.c: In function '__s390_dma_map_sg':
arch/s390/pci/pci_dma.c:309:13: warning: 'pa' may be used uninitialized in this 
function [-Wmaybe-uninitialized]

This adds a bogus initialization to the function to sanitize
the debug output.  I would have preferred a solution without
the initialization, but I only got the report from the
kbuild bot after turning on the warning again, and didn't
manage to reproduce it myself.

Signed-off-by: Arnd Bergmann 
Acked-by: Sebastian Ott 
Acked-by: Martin Schwidefsky 
---
 arch/s390/pci/pci_dma.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/s390/pci/pci_dma.c b/arch/s390/pci/pci_dma.c
index 7350c8b..6b2f72f 100644
--- a/arch/s390/pci/pci_dma.c
+++ b/arch/s390/pci/pci_dma.c
@@ -423,7 +423,7 @@ static int __s390_dma_map_sg(struct device *dev, struct 
scatterlist *sg,
dma_addr_t dma_addr_base, dma_addr;
int flags = ZPCI_PTE_VALID;
struct scatterlist *s;
-   unsigned long pa;
+   unsigned long pa = 0;
int ret;
 
size = PAGE_ALIGN(size);
-- 
2.9.0


___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

[PATCH v2 01/11] Kbuild: enable -Wmaybe-uninitialized warning for "make W=1"

2016-11-10 Thread Arnd Bergmann 
Traditionally, we have always had warnings about uninitialized variables
enabled, as this is part of -Wall, and generally a good idea [1], but it
also always produced false positives, mainly because this is a variation
of the halting problem and provably impossible to get right in all cases
[2].

Various people have identified cases that are particularly bad for false
positives, and in commit e74fc973b6e5 ("Turn off -Wmaybe-uninitialized
when building with -Os"), I turned off the warning for any build that
was done with CC_OPTIMIZE_FOR_SIZE.  This drastically reduced the number
of false positive warnings in the default build but unfortunately had
the side effect of turning the warning off completely in 'allmodconfig'
builds, which in turn led to a lot of warnings (both actual bugs, and
remaining false positives) to go in unnoticed.

With commit 877417e6ffb9 ("Kbuild: change CC_OPTIMIZE_FOR_SIZE
definition") enabled the warning again for allmodconfig builds in v4.7
and in v4.8-rc1, I had finally managed to address all warnings I get in
an ARM allmodconfig build and most other maybe-uninitialized warnings
for ARM randconfig builds.

However, commit 6e8d666e9253 ("Disable "maybe-uninitialized" warning
globally") was merged at the same time and disabled it completely for
all configurations, because of false-positive warnings on x86 that I had
not addressed until then. This caused a lot of actual bugs to get merged
into mainline, and I sent several dozen patches for these during the v4.9
development cycle. Most of these are actual bugs, some are for correct
code that is safe because it is only called under external constraints
that make it impossible to run into the case that gcc sees, and in a
few cases gcc is just stupid and finds something that can obviously
never happen.

I have now done a few thousand randconfig builds on x86 and collected all
patches that I needed to address every single warning I got (I can provide
the combined patch for the other warnings if anyone is interested),
so I hope we can get the warning back and let people catch the actual
bugs earlier.

This reverts the change to disable the warning completely and for
now brings it back at the "make W=1" level, so we can get it merged
into mainline without introducing false positives. A follow-up
patch enables it on all levels unless some configuration option
turns it off because of false-positives.

Link: https://rusty.ozlabs.org/?p=232 [1]
Link: https://gcc.gnu.org/wiki/Better_Uninitialized_Warnings [2]
Signed-off-by: Arnd Bergmann 
---
 Makefile   | 10 ++
 arch/arc/Makefile  |  4 +++-
 scripts/Makefile.extrawarn |  3 +++
 scripts/Makefile.ubsan |  4 
 4 files changed, 16 insertions(+), 5 deletions(-)

diff --git a/Makefile b/Makefile
index f97f786..06e2b73 100644
--- a/Makefile
+++ b/Makefile
@@ -370,7 +370,7 @@ LDFLAGS_MODULE  =
 CFLAGS_KERNEL  =
 AFLAGS_KERNEL  =
 LDFLAGS_vmlinux =
-CFLAGS_GCOV= -fprofile-arcs -ftest-coverage -fno-tree-loop-im
+CFLAGS_GCOV= -fprofile-arcs -ftest-coverage -fno-tree-loop-im 
-Wno-maybe-uninitialized
 CFLAGS_KCOV:= $(call cc-option,-fsanitize-coverage=trace-pc,)
 
 
@@ -620,7 +620,6 @@ ARCH_CFLAGS :=
 include arch/$(SRCARCH)/Makefile
 
 KBUILD_CFLAGS  += $(call cc-option,-fno-delete-null-pointer-checks,)
-KBUILD_CFLAGS  += $(call cc-disable-warning,maybe-uninitialized,)
 KBUILD_CFLAGS  += $(call cc-disable-warning,frame-address,)
 
 ifdef CONFIG_LD_DEAD_CODE_DATA_ELIMINATION
@@ -629,15 +628,18 @@ KBUILD_CFLAGS += $(call cc-option,-fdata-sections,)
 endif
 
 ifdef CONFIG_CC_OPTIMIZE_FOR_SIZE
-KBUILD_CFLAGS  += -Os
+KBUILD_CFLAGS  += -Os $(call cc-disable-warning,maybe-uninitialized,)
 else
 ifdef CONFIG_PROFILE_ALL_BRANCHES
-KBUILD_CFLAGS  += -O2
+KBUILD_CFLAGS  += -O2 $(call cc-disable-warning,maybe-uninitialized,)
 else
 KBUILD_CFLAGS   += -O2
 endif
 endif
 
+KBUILD_CFLAGS += $(call cc-ifversion, -lt, 0409, \
+   $(call cc-disable-warning,maybe-uninitialized,))
+
 # Tell gcc to never replace conditional load with a non-conditional one
 KBUILD_CFLAGS  += $(call cc-option,--param=allow-store-data-races=0)
 
diff --git a/arch/arc/Makefile b/arch/arc/Makefile
index 864adad..25f81a1 100644
--- a/arch/arc/Makefile
+++ b/arch/arc/Makefile
@@ -68,7 +68,9 @@ cflags-$(CONFIG_ARC_DW2_UNWIND)   += 
-fasynchronous-unwind-tables $(cfi)
 ifndef CONFIG_CC_OPTIMIZE_FOR_SIZE
 # Generic build system uses -O2, we want -O3
 # Note: No need to add to cflags-y as that happens anyways
-ARCH_CFLAGS += -O3
+#
+# Disable the false maybe-uninitialized warings gcc spits out at -O3
+ARCH_CFLAGS += -O3 $(call cc-disable-warning,maybe-uninitialized,)
 endif
 
 # small data is default for elf32 tool-chain. If not usable, disable it
diff --git a/scripts/Makefile.extrawarn b/scripts/Makefile.extrawarn
index 53449a6..7fc2c5a 100644
--- a/scripts/Makefile.extrawarn
+++ b/scripts/Makefile.extrawarn
@@ -36,6 +36,7 @@ warning-2 += -Wshadow
 warning-2 += $(ca

[PATCH v2 06/11] [media] dib0700: fix nec repeat handling

2016-11-10 Thread Arnd Bergmann 
From: Sean Young 

When receiving a nec repeat, ensure the correct scancode is repeated
rather than a random value from the stack. This removes the need
for the bogus uninitialized_var() and also fixes the warnings:

drivers/media/usb/dvb-usb/dib0700_core.c: In function 
‘dib0700_rc_urb_completion’:
drivers/media/usb/dvb-usb/dib0700_core.c:679: warning: ‘protocol’ may be 
used uninitialized in this function

[sean addon: So after writing the patch and submitting it, I've bought the
 hardware on ebay. Without this patch you get random scancodes
 on nec repeats, which the patch indeed fixes.]

Signed-off-by: Sean Young 
Tested-by: Sean Young 
Cc: sta...@vger.kernel.org
Signed-off-by: Arnd Bergmann 
---
 drivers/media/usb/dvb-usb/dib0700_core.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/media/usb/dvb-usb/dib0700_core.c 
b/drivers/media/usb/dvb-usb/dib0700_core.c
index 92d5408..47ce9d5 100644
--- a/drivers/media/usb/dvb-usb/dib0700_core.c
+++ b/drivers/media/usb/dvb-usb/dib0700_core.c
@@ -704,7 +704,7 @@ static void dib0700_rc_urb_completion(struct urb *purb)
struct dvb_usb_device *d = purb->context;
struct dib0700_rc_response *poll_reply;
enum rc_type protocol;
-   u32 uninitialized_var(keycode);
+   u32 keycode;
u8 toggle;
 
deb_info("%s()\n", __func__);
@@ -745,7 +745,8 @@ static void dib0700_rc_urb_completion(struct urb *purb)
poll_reply->nec.data   == 0x00 &&
poll_reply->nec.not_data   == 0xff) {
poll_reply->data_state = 2;
-   break;
+   rc_repeat(d->rc_dev);
+   goto resubmit;
}
 
if ((poll_reply->nec.data ^ poll_reply->nec.not_data) != 0xff) {
-- 
2.9.0


___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

[PATCH v2 07/11] [media] rc: print correct variable for z8f0811

2016-11-10 Thread Arnd Bergmann 
A recent rework accidentally left a debugging printk untouched
while changing the meaning of the variables, leading to an
uninitialized variable being printed:

drivers/media/i2c/ir-kbd-i2c.c: In function 'get_key_haup_common':
drivers/media/i2c/ir-kbd-i2c.c:62:2: error: 'toggle' may be used uninitialized 
in this function [-Werror=maybe-uninitialized]

This prints the correct one instead, as we did before the patch.

Fixes: 00bb820755ed ("[media] rc: Hauppauge z8f0811 can decode RC6")
Signed-off-by: Arnd Bergmann 
---
 drivers/media/i2c/ir-kbd-i2c.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

I submitted this repeatedly as it is a v4.9 regression, but
I never saw a reply for it.

diff --git a/drivers/media/i2c/ir-kbd-i2c.c b/drivers/media/i2c/ir-kbd-i2c.c
index f95a6bc..cede397 100644
--- a/drivers/media/i2c/ir-kbd-i2c.c
+++ b/drivers/media/i2c/ir-kbd-i2c.c
@@ -118,7 +118,7 @@ static int get_key_haup_common(struct IR_i2c *ir, enum 
rc_type *protocol,
*protocol = RC_TYPE_RC6_MCE;
dev &= 0x7f;
dprintk(1, "ir hauppauge (rc6-mce): t%d vendor=%d 
dev=%d code=%d\n",
-   toggle, vendor, dev, code);
+   *ptoggle, vendor, dev, code);
} else {
*ptoggle = 0;
*protocol = RC_TYPE_RC6_6A_32;
-- 
2.9.0


___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

[PATCH v2 00/11] getting back -Wmaybe-uninitialized

2016-11-10 Thread Arnd Bergmann 
Hi Linus,

It took a while for some patches to make it into mainline through
maintainer trees, but the 28-patch series is now reduced to 10, with
one tiny patch added at the end.  I hope this can still make it into
v4.9. Aside from patches that are no longer required, I did these changes
compared to version 1:

- Dropped "iio: maxim_thermocouple: detect invalid storage size in
  read()", which is currently in linux-next as commit 32cb7d27e65d.
  This is the only remaining warning I see for a couple of corner
  cases (kbuild bot reports it on blackfin, kernelci bot and
  arm-soc bot both report it on arm64)

- Dropped "brcmfmac: avoid maybe-uninitialized warning in
  brcmf_cfg80211_start_ap", which is currently in net/master
  merge pending.

- Dropped two x86 patches, "x86: math-emu: possible uninitialized
  variable use" and "x86: mark target address as output in 'insb' asm"
  as they do not seem to trigger for a default build, and I got
  no feedback on them. Both of these are ancient issues and seem
  harmless, I will send them again to the x86 maintainers once
  the rest is merged.
  
- Dropped "rbd: false-postive gcc-4.9 -Wmaybe-uninitialized" based on
  feedback from Ilya Dryomov, who already has a different fix queued up
  for v4.10. The kbuild bot reports this as a warning for xtensa.
 
- Replaced "crypto: aesni: avoid -Wmaybe-uninitialized warning" with a
  simpler patch, this one always triggers but my first solution would not
  be safe for linux-4.9 any more at this point. I'll follow up with
  the larger patch as a cleanup for 4.10.
  
- Replaced "dib0700: fix nec repeat handling" with a better one,
  contributed by Sean Young.

Please merge these directly if you are happy with the result.

As the minimum, I'd hope to see the first patch get in soon,
but the individual bugfixes are hopefully now all appropriate
as well. If you see any regressions with the final patch, just
leave that one out and let me know what problems remain.

Arnd

Arnd Bergmann (10):
  Kbuild: enable -Wmaybe-uninitialized warning for "make W=1"
  NFSv4.1: work around -Wmaybe-uninitialized warning
  x86: apm: avoid uninitialized data
  nios2: fix timer initcall return value
  s390: pci: don't print uninitialized data for debugging
  [media] rc: print correct variable for z8f0811
  crypto: aesni: shut up -Wmaybe-uninitialized warning
  infiniband: shut up a maybe-uninitialized warning
  pcmcia: fix return value of soc_pcmcia_regulator_set
  Kbuild: enable -Wmaybe-uninitialized warnings by default

Sean Young (1):
  [media] dib0700: fix nec repeat handling

 Makefile | 10 +++---
 arch/arc/Makefile|  4 ++-
 arch/nios2/kernel/time.c |  1 +
 arch/s390/pci/pci_dma.c  |  2 +-
 arch/x86/crypto/aesni-intel_glue.c   |  4 +--
 arch/x86/kernel/apm_32.c |  5 ++-
 drivers/infiniband/core/cma.c| 54 +---
 drivers/media/i2c/ir-kbd-i2c.c   |  2 +-
 drivers/media/usb/dvb-usb/dib0700_core.c |  5 +--
 drivers/pcmcia/soc_common.c  |  2 +-
 fs/nfs/nfs4session.c | 10 +++---
 scripts/Makefile.extrawarn   |  1 +
 scripts/Makefile.ubsan   |  4 +++
 13 files changed, 61 insertions(+), 43 deletions(-)

-- 
2.9.0

Cc: Anna Schumaker 
Cc: "David S. Miller" 
Cc: Herbert Xu 
Cc: Ilya Dryomov 
Cc: Javier Martinez Canillas 
Cc: Jiri Kosina 
Cc: Jonathan Cameron 
Cc: Ley Foon Tan 
Cc: Luis R. Rodriguez 
Cc: Martin Schwidefsky 
Cc: Mauro Carvalho Chehab 
Cc: Michal Marek 
Cc: Russell King 
Cc: Sean Young 
Cc: Sebastian Ott 
Cc: Trond Myklebust 
Cc: x...@kernel.org
Cc: linux-kbu...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: linux-snps-arc@lists.infradead.org
Cc: nios2-...@lists.rocketboards.org
Cc: linux-s...@vger.kernel.org
Cc: linux-cry...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Cc: linux-...@vger.kernel.org



___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

[PATCH v2 02/11] NFSv4.1: work around -Wmaybe-uninitialized warning

2016-11-10 Thread Arnd Bergmann 
A bugfix introduced a harmless gcc warning in nfs4_slot_seqid_in_use
if we enable -Wmaybe-uninitialized again:

fs/nfs/nfs4session.c:203:54: error: 'cur_seq' may be used uninitialized in this 
function [-Werror=maybe-uninitialized]

gcc is not smart enough to conclude that the IS_ERR/PTR_ERR pair
results in a nonzero return value here. Using PTR_ERR_OR_ZERO()
instead makes this clear to the compiler.

Fixes: e09c978aae5b ("NFSv4.1: Fix Oopsable condition in server callback races")
Signed-off-by: Arnd Bergmann 
---
First submitted on Aug 31, but ended up not getting applied then
as the warning was disabled in v4.8-rc

Anna Schumaker said at the kernel summit that she had applied
it and would send it for 4.9, but as of 2016-11-09 it has not
made it into linux-next.

 fs/nfs/nfs4session.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/fs/nfs/nfs4session.c b/fs/nfs/nfs4session.c
index b629730..150c5a1 100644
--- a/fs/nfs/nfs4session.c
+++ b/fs/nfs/nfs4session.c
@@ -178,12 +178,14 @@ static int nfs4_slot_get_seqid(struct nfs4_slot_table  
*tbl, u32 slotid,
__must_hold(&tbl->slot_tbl_lock)
 {
struct nfs4_slot *slot;
+   int ret;
 
slot = nfs4_lookup_slot(tbl, slotid);
-   if (IS_ERR(slot))
-   return PTR_ERR(slot);
-   *seq_nr = slot->seq_nr;
-   return 0;
+   ret = PTR_ERR_OR_ZERO(slot);
+   if (!ret)
+   *seq_nr = slot->seq_nr;
+
+   return ret;
 }
 
 /*
-- 
2.9.0


___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

[PATCH v2 11/11] Kbuild: enable -Wmaybe-uninitialized warnings by default

2016-11-10 Thread Arnd Bergmann 
Previously the warnings were added back at the W=1 level and above,
this now turns them on again by default, assuming that we have addressed
all warnings and again have a clean build for v4.10.

I found a number of new warnings in linux-next already and submitted
bugfixes for those. Hopefully they are caught by the 0day builder
in the future as soon as this patch is merged.

Signed-off-by: Arnd Bergmann 
---
Please check if there are any remaining warnings with this
patch before applying.

The one known issue right now is commit 32cb7d27e65d ("iio:
maxim_thermocouple: detect invalid storage size in read()"), which
is currently in linux-next but not yet in mainline.

There are a couple of warnings that I get with randconfig builds,
and I have submitted patches for all of them at some point and
will follow up on them to make sure they get addressed eventually.
---
 scripts/Makefile.extrawarn | 2 --
 1 file changed, 2 deletions(-)

diff --git a/scripts/Makefile.extrawarn b/scripts/Makefile.extrawarn
index 7fc2c5a..7c321a6 100644
--- a/scripts/Makefile.extrawarn
+++ b/scripts/Makefile.extrawarn
@@ -60,8 +60,6 @@ endif
 KBUILD_CFLAGS += $(warning)
 else
 
-KBUILD_CFLAGS += $(call cc-disable-warning, maybe-uninitialized)
-
 ifeq ($(cc-name),clang)
 KBUILD_CFLAGS += $(call cc-disable-warning, initializer-overrides)
 KBUILD_CFLAGS += $(call cc-disable-warning, unused-value)
-- 
2.9.0


___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

[PATCH v2 09/11] [v3] infiniband: shut up a maybe-uninitialized warning

2016-11-10 Thread Arnd Bergmann 
Some configurations produce this harmless warning when built with
gcc -Wmaybe-uninitialized:

infiniband/core/cma.c: In function 'cma_get_net_dev':
infiniband/core/cma.c:1242:12: warning: 'src_addr_storage.sin_addr.s_addr' may 
be used uninitialized in this function [-Wmaybe-uninitialized]

I previously reported this for the powerpc64 defconfig, but have now
reproduced the same thing for x86 as well, using gcc-5 or higher.

The code looks correct to me, and this change just rearranges it
by making sure we alway initialize the entire address structure
to make the warning disappear. My first approach added an
initialization at the time of the declaration, which Doug commented
may be too costly, so I hope this version doesn't add overhead.

Link: 
http://arm-soc.lixom.net/buildlogs/mainline/v4.7-rc6/buildall.powerpc.ppc64_defconfig.log.passed
Link: https://patchwork.kernel.org/patch/9212825/
Acked-by: Haggai Eran 
Signed-off-by: Arnd Bergmann 

---
This is marked v2 as the rest of the series but is actually version
three of the patch as I had to do some other changes already.

v3: remove accidental leftover change of the original patch

 drivers/infiniband/core/cma.c | 54 ++-
 1 file changed, 28 insertions(+), 26 deletions(-)

diff --git a/drivers/infiniband/core/cma.c b/drivers/infiniband/core/cma.c
index 36bf50e..89a6b05 100644
--- a/drivers/infiniband/core/cma.c
+++ b/drivers/infiniband/core/cma.c
@@ -1094,47 +1094,47 @@ static void cma_save_ib_info(struct sockaddr *src_addr,
}
 }
 
-static void cma_save_ip4_info(struct sockaddr *src_addr,
- struct sockaddr *dst_addr,
+static void cma_save_ip4_info(struct sockaddr_in *src_addr,
+ struct sockaddr_in *dst_addr,
  struct cma_hdr *hdr,
  __be16 local_port)
 {
-   struct sockaddr_in *ip4;
-
if (src_addr) {
-   ip4 = (struct sockaddr_in *)src_addr;
-   ip4->sin_family = AF_INET;
-   ip4->sin_addr.s_addr = hdr->dst_addr.ip4.addr;
-   ip4->sin_port = local_port;
+   *src_addr = (struct sockaddr_in) {
+   .sin_family = AF_INET,
+   .sin_addr.s_addr = hdr->dst_addr.ip4.addr,
+   .sin_port = local_port,
+   };
}
 
if (dst_addr) {
-   ip4 = (struct sockaddr_in *)dst_addr;
-   ip4->sin_family = AF_INET;
-   ip4->sin_addr.s_addr = hdr->src_addr.ip4.addr;
-   ip4->sin_port = hdr->port;
+   *dst_addr = (struct sockaddr_in) {
+   .sin_family = AF_INET,
+   .sin_addr.s_addr = hdr->src_addr.ip4.addr,
+   .sin_port = hdr->port,
+   };
}
 }
 
-static void cma_save_ip6_info(struct sockaddr *src_addr,
- struct sockaddr *dst_addr,
+static void cma_save_ip6_info(struct sockaddr_in6 *src_addr,
+ struct sockaddr_in6 *dst_addr,
  struct cma_hdr *hdr,
  __be16 local_port)
 {
-   struct sockaddr_in6 *ip6;
-
if (src_addr) {
-   ip6 = (struct sockaddr_in6 *)src_addr;
-   ip6->sin6_family = AF_INET6;
-   ip6->sin6_addr = hdr->dst_addr.ip6;
-   ip6->sin6_port = local_port;
+   *src_addr = (struct sockaddr_in6) {
+   .sin6_family = AF_INET6,
+   .sin6_addr = hdr->dst_addr.ip6,
+   .sin6_port = local_port,
+   };
}
 
if (dst_addr) {
-   ip6 = (struct sockaddr_in6 *)dst_addr;
-   ip6->sin6_family = AF_INET6;
-   ip6->sin6_addr = hdr->src_addr.ip6;
-   ip6->sin6_port = hdr->port;
+   *dst_addr = (struct sockaddr_in6) {
+   .sin6_family = AF_INET6,
+   .sin6_addr = hdr->src_addr.ip6,
+   .sin6_port = hdr->port,
+   };
}
 }
 
@@ -1159,10 +1159,12 @@ static int cma_save_ip_info(struct sockaddr *src_addr,
 
switch (cma_get_ip_ver(hdr)) {
case 4:
-   cma_save_ip4_info(src_addr, dst_addr, hdr, port);
+   cma_save_ip4_info((struct sockaddr_in *)src_addr,
+ (struct sockaddr_in *)dst_addr, hdr, port);
break;
case 6:
-   cma_save_ip6_info(src_addr, dst_addr, hdr, port);
+   cma_save_ip6_info((struct sockaddr_in6 *)src_addr,
+ (struct sockaddr_in6 *)dst_addr, hdr, port);
break;
default:
return -EAFNOSUPPORT;
-- 
2.9.0


___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailm

[PATCH v2 04/11] nios2: fix timer initcall return value

2016-11-10 Thread Arnd Bergmann 
When called more than twice, the nios2_time_init() function
return an uninitialized value, as detected by gcc -Wmaybe-uninitialized

arch/nios2/kernel/time.c: warning: 'ret' may be used uninitialized in this 
function

This makes it return '0' here, matching the comment above the
function.

Acked-by: Ley Foon Tan 
Signed-off-by: Arnd Bergmann 
---
 arch/nios2/kernel/time.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/nios2/kernel/time.c b/arch/nios2/kernel/time.c
index d9563dd..746bf5c 100644
--- a/arch/nios2/kernel/time.c
+++ b/arch/nios2/kernel/time.c
@@ -324,6 +324,7 @@ static int __init nios2_time_init(struct device_node *timer)
ret = nios2_clocksource_init(timer);
break;
default:
+   ret = 0;
break;
}
 
-- 
2.9.0


___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

[PATCH v2 08/11] crypto: aesni: shut up -Wmaybe-uninitialized warning

2016-11-10 Thread Arnd Bergmann 
The rfc4106 encrypy/decrypt helper functions cause an annoying
false-positive warning in allmodconfig if we turn on
-Wmaybe-uninitialized warnings again:

arch/x86/crypto/aesni-intel_glue.c: In function ‘helper_rfc4106_decrypt’:
include/linux/scatterlist.h:67:31: warning: ‘dst_sg_walk.sg’ may be used 
uninitialized in this function [-Wmaybe-uninitialized]

The problem seems to be that the compiler doesn't track the state of the
'one_entry_in_sg' variable across the kernel_fpu_begin/kernel_fpu_end
section.

This takes the easy way out by adding a bogus initialization, which
should be harmless enough to get the patch into v4.9 so we can turn
on this warning again by default without producing useless output.
A follow-up patch for v4.10 rearranges the code to make the warning
go away.

Signed-off-by: Arnd Bergmann 
---
 arch/x86/crypto/aesni-intel_glue.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/crypto/aesni-intel_glue.c 
b/arch/x86/crypto/aesni-intel_glue.c
index 0ab5ee1..aa8b067 100644
--- a/arch/x86/crypto/aesni-intel_glue.c
+++ b/arch/x86/crypto/aesni-intel_glue.c
@@ -888,7 +888,7 @@ static int helper_rfc4106_encrypt(struct aead_request *req)
unsigned long auth_tag_len = crypto_aead_authsize(tfm);
u8 iv[16] __attribute__ ((__aligned__(AESNI_ALIGN)));
struct scatter_walk src_sg_walk;
-   struct scatter_walk dst_sg_walk;
+   struct scatter_walk dst_sg_walk = {};
unsigned int i;
 
/* Assuming we are supporting rfc4106 64-bit extended */
@@ -968,7 +968,7 @@ static int helper_rfc4106_decrypt(struct aead_request *req)
u8 iv[16] __attribute__ ((__aligned__(AESNI_ALIGN)));
u8 authTag[16];
struct scatter_walk src_sg_walk;
-   struct scatter_walk dst_sg_walk;
+   struct scatter_walk dst_sg_walk = {};
unsigned int i;
 
if (unlikely(req->assoclen != 16 && req->assoclen != 20))
-- 
2.9.0


___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

[PATCH v2 03/11] x86: apm: avoid uninitialized data

2016-11-10 Thread Arnd Bergmann 
apm_bios_call() can fail, and return a status in its argument
structure. If that status however is zero during a call from
apm_get_power_status(), we end up using data that may have
never been set, as reported by "gcc -Wmaybe-uninitialized":

arch/x86/kernel/apm_32.c: In function ‘apm’:
arch/x86/kernel/apm_32.c:1729:17: error: ‘bx’ may be used uninitialized in this 
function [-Werror=maybe-uninitialized]
arch/x86/kernel/apm_32.c:1835:5: error: ‘cx’ may be used uninitialized in this 
function [-Werror=maybe-uninitialized]
arch/x86/kernel/apm_32.c:1730:17: note: ‘cx’ was declared here
arch/x86/kernel/apm_32.c:1842:27: error: ‘dx’ may be used uninitialized in this 
function [-Werror=maybe-uninitialized]
arch/x86/kernel/apm_32.c:1731:17: note: ‘dx’ was declared here

This changes the function to return "APM_NO_ERROR" here, which
makes the code more robust to broken BIOS versions, and avoids
the warning.

Signed-off-by: Arnd Bergmann 
Reviewed-by: Jiri Kosina 
Reviewed-by: Luis R. Rodriguez 
---
 arch/x86/kernel/apm_32.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kernel/apm_32.c b/arch/x86/kernel/apm_32.c
index c7364bd..51287cd 100644
--- a/arch/x86/kernel/apm_32.c
+++ b/arch/x86/kernel/apm_32.c
@@ -1042,8 +1042,11 @@ static int apm_get_power_status(u_short *status, u_short 
*bat, u_short *life)
 
if (apm_info.get_power_status_broken)
return APM_32_UNSUPPORTED;
-   if (apm_bios_call(&call))
+   if (apm_bios_call(&call)) {
+   if (!call.err)
+   return APM_NO_ERROR;
return call.err;
+   }
*status = call.ebx;
*bat = call.ecx;
if (apm_info.get_power_status_swabinminutes) {
-- 
2.9.0


___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH v3 10/10] clocksource: import ARC timer driver

2016-11-10 Thread Vineet Gupta 
On 11/10/2016 02:49 AM, Daniel Lezcano wrote:
> On Thu, Nov 03, 2016 at 04:33:35PM -0700, Vineet Gupta wrote:
>> This adds support for
>>
>>  - CONFIG_ARC_TIMERS : legacy 32-bit TIMER0 and TIMER1 which count UP
>>from @CNT to @LIMIT, before optionally triggering an interrupt.
>>These are programmed using ARC auxiliary register interface.
>>These are present in all ARC cores (ARC700 and ARC HS38)
>>TIMER0 serves as clockevent for all ARC linux builds.
>>TIMER1 is used for clocksource in arc700 builds.
>>
>>  - CONFIG_ARC_TIMERS_64BIT: 64-bit counters, RTC and GFRC found in
>>ARC HS38 cores. These are independnet IP blocks with different
>>programming model respectively.
>>
>> Signed-off-by: Vineet Gupta 
>> ---
> 
> [ ... ]
> 
>>  config ARC
>>  def_bool y
>> +select ARC_TIMERS
>>  select ARCH_SUPPORTS_ATOMIC_RMW if ARC_HAS_LLSC
>>  select BUILDTIME_EXTABLE_SORT
>> -select CLKSRC_OF
>>  select CLONE_BACKWARDS
>>  select COMMON_CLK
>>  select GENERIC_ATOMIC64 if !ISA_ARCV2 || !(ARC_HAS_LL64 && ARC_HAS_LLSC)
>> @@ -115,6 +115,7 @@ config ISA_ARCOMPACT
>>  
>>  config ISA_ARCV2
>>  bool "ARC ISA v2"
>> +select ARC_TIMERS_64BIT
>>  help
>>ISA for the Next Generation ARC-HS cores
>>  
>> @@ -410,10 +411,6 @@ config ARC_HAS_DIV_REM
>>  bool "Insn: div, divu, rem, remu"
>>  default y
>>  
>> -config ARC_TIMERS_64BIT
>> -bool "64-bit r/o cycle counters RTC (up) and GFRC (smp)"
>> -default y
>> -
>>  config ARC_NUMBER_OF_INTERRUPTS
>>  int "Number of interrupts"
>>  range 8 240
>> diff --git a/arch/arc/kernel/Makefile b/arch/arc/kernel/Makefile
>> index cfcdedf52ff8..8942c5c3b4c5 100644
>> --- a/arch/arc/kernel/Makefile
>> +++ b/arch/arc/kernel/Makefile
>> @@ -8,7 +8,7 @@
>>  # Pass UTS_MACHINE for user_regset definition
>>  CFLAGS_ptrace.o += -DUTS_MACHINE='"$(UTS_MACHINE)"'
>>  
>> -obj-y   := arcksyms.o setup.o irq.o time.o reset.o ptrace.o process.o 
>> devtree.o
>> +obj-y   := arcksyms.o setup.o irq.o reset.o ptrace.o process.o devtree.o
>>  obj-y   += signal.o traps.o sys.o troubleshoot.o stacktrace.o disasm.o
>>  obj-$(CONFIG_ISA_ARCOMPACT) += entry-compact.o intc-compact.o
>>  obj-$(CONFIG_ISA_ARCV2) += entry-arcv2.o intc-arcv2.o
>> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
>> index e2c6e43cf8ca..a53bd50164e7 100644
>> --- a/drivers/clocksource/Kconfig
>> +++ b/drivers/clocksource/Kconfig
>> @@ -282,6 +282,25 @@ config CLKSRC_MPS2
>>  select CLKSRC_MMIO
>>  select CLKSRC_OF
>>  
>> +config ARC_TIMERS
>> +bool "Support for 32-bit TIMERn counters in ARC Cores" if COMPILE_TEST
>> +depends on GENERIC_CLOCKEVENTS
>> +select CLKSRC_OF
>> +help
>> +  These are legacy 32-bit TIMER0 and TIMER1 counters found on all ARC 
>> cores
>> +  (ARC700 as well as ARC HS38).
>> +  TIMER0 serves as clockevent while TIMER1 provides clocksource
>> +
>> +config ARC_TIMERS_64BIT
>> +bool "Support for 64-bit counters in ARC HS38 cores" if COMPILE_TEST
>> +depends on GENERIC_CLOCKEVENTS
>> +select CLKSRC_OF
>> +help
>> +  This enables 2 different 64-bit timers: RTC (for UP) and GFRC (for 
>> SMP)
>> +  RTC is implemented inside the core, while GFRC sits outside the core 
>> in
>> +  ARConnect IP block. Driver automatically picks one of them for 
>> clocksource
>> +  as appropriate.
>> +
>>  config ARM_ARCH_TIMER
>>  bool
>>  select CLKSRC_OF if OF
>> diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
>> index cf87f407f1ad..a14111e1f087 100644
>> --- a/drivers/clocksource/Makefile
>> +++ b/drivers/clocksource/Makefile
>> @@ -51,6 +51,7 @@ obj-$(CONFIG_CLKSRC_TI_32K)+= timer-ti-32k.o
>>  obj-$(CONFIG_CLKSRC_NPS)+= timer-nps.o
>>  obj-$(CONFIG_OXNAS_RPS_TIMER)   += timer-oxnas-rps.o
>>  
>> +obj-$(CONFIG_ARC_TIMERS)+= arc_timer.o
> 
> I don't see arc_timer.o compiled if ARC_TIMERS_64BIT only is set.
> 
> Wouldn't make sense to fold ARC_TIMERS and ARC_TIMERS_64BIT ?

>From ARC point of view that would be an invalid configuration as the base 
>TIMER0
is set up as clockevent in all configurations and cores and is needed 
independent
of 64 timers being there or not. So better to add that as explicit dependency 
here
which would also address the build issue you raise.

Thx,
-Vineet

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH v2] drm/arcpgu: Accommodate adv7511 switch to DRM bridge

2016-11-10 Thread Dave Airlie 
On 10 November 2016 at 21:06, Alexey Brodkin
 wrote:
> Hi Daniel, David,
>
> On Wed, 2016-11-02 at 12:23 +, Alexey Brodkin wrote:
>> Hi Daniel, David,
>>
>> On Mon, 2016-10-24 at 18:33 +, Alexey Brodkin wrote:
>> >
>> > Hi Daniel,
>> >
>> > >
>> > >
>> > > -Original Message-
>> > > From: linux-snps-arc [mailto:linux-snps-arc-boun...@lists.infradead.org] 
>> > > On Behalf Of Alexey Brodkin
>> > > Sent: 19 октября 2016 г. 12:33
>> > > To: dri-de...@lists.freedesktop.org; arch...@codeaurora.org; 
>> > > eugeniy.palt...@synopsys.com
>> > > Cc: linux-snps-arc@lists.infradead.org; linux-ker...@vger.kernel.org
>> > > Subject: Re: [PATCH v2] drm/arcpgu: Accommodate adv7511 switch to DRM 
>> > > bridge
>> > >
>> > > Hi Archit, all,
>> > >
>> > > On Wed, 2016-10-19 at 14:43 +0530, Archit Taneja wrote:
>> > > >
>> > > >
>> > > >
>> > > > On 10/19/2016 01:16 PM, Eugeniy Paltsev wrote:
>> > > > >
>> > > > >
>> > > > >
>> > > > > ARC PGU driver starts crashing on initialization after
>> > > > > 'commit e12c2f645557 ("drm/i2c: adv7511: Convert to drm_bridge")'
>> > > > > This happenes because in "arcpgu_drm_hdmi_init" function we get 
>> > > > > pointer
>> > > > > of "drm_i2c_encoder_driver" structure, which doesn't exist after
>> > > > > adv7511 hdmi encoder interface changed from slave encoder to drm 
>> > > > > bridge.
>> > > > > So, when we call "encoder_init" function from this structure driver
>> > > > > crashes.
>> > >
>> > > [snip]
>> > >
>> > > >
>> > > >
>> > > > Looks good now.
>> > > >
>> > > > Reviewed-by: Archit Taneja 
>> > >
>> > > And IMHO it would be really good to get this one back-ported to 4.8
>> > > because it really fixes kernel crash if ARC PGU driver is used.
>> > >
>> > > It might be a bit of a problem because patch itself a little-bit larger
>> > > than formal requirement for stable backports but let's see if it gets 
>> > > accepted.
>> >
>> > Could you please pick this one up?
>> > I may alternatively send a pull-request to David but not sure if 1 patch 
>> > worth it.
>> >
>> > Also if that's not really too late it would be good to get this one in 4.9 
>> > since the patch
>> > In question fixes a real driver crash on its instantiation.
>> > Actually driver crash happens since 4.8 but I failed to notice it earlier 
>> > and given amount
>> > of changes I think there's barely a chance for it it to be accepted in 
>> > stable branches...
>> > which in its turn makes at least 4.9 very desirable.
>>
>> Any chance this one gets accepted anytime soon?
>
> Please treat this as another polite reminder to apply this patch.
> If you prefer I may send a pull-request otherwise.

Please send a pull request for -fixes.

For everyone else, pull requests for single patches is not overkill,
it fits into my workflow a lot better.

Dave.

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

[GIT PULL] drm/arcpgu: Accommodate adv7511 switch to DRM bridge

2016-11-10 Thread Алексей Бродкин 
Hi Dave,

Please pull that change for ARC PGU that fixes driver instantiation on
AXS 10x boards.
The patch was published for review here:
https://lists.freedesktop.org/archives/dri-devel/2016-October/121245.html

It is based on today's "drm-next" branch.

Probably it's already too late for 4.9 but if there's a chance to
squeeze it there it will
be super nice because it's a fix for inevitable driver crash right on start.

Best regards,
Alexey

The following changes since commit fa860a1751e388385a7f249dd3f24a6c76db0ba9:

  drm: Print device information again in debugfs (2016-10-17 16:20:53 +1000)

are available in the git repository at:

  https://github.com/foss-for-synopsys-dwc-arc-processors/linux.git
topic-arcpgu-fixes

for you to fetch changes up to 7bc61cc5df808008b77a3b72cf814960c675518b:

  drm/arcpgu: Accommodate adv7511 switch to DRM bridge (2016-11-11
04:31:35 +0300)


Eugeniy Paltsev (1):
  drm/arcpgu: Accommodate adv7511 switch to DRM bridge

 drivers/gpu/drm/arc/arcpgu_hdmi.c | 159
+---
 1 file changed, 17 insertions(+), 142 deletions(-)

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc