Re: [PATCH 0/4] Minor fixes and improvements for kexec

2013-12-16 Thread WANG Chao
On 12/12/13 at 12:18am, Geoff Levand wrote:
> Hi Eric,
> 
> Here are a few minor fixes and improvements for kexec.  Please consider.
> 
> -Geoff
> 
> The following changes since commit 374b105797c3d4f29c685f3be535c35f5689b30e:
> 
>   Linux 3.13-rc3 (2013-12-06 09:34:04 -0800)
> 
> are available in the git repository at:
> 
>   git://git.linaro.org/people/geoff.levand/linux-kexec.git for-kexec
> 
> for you to fetch changes up to 594a3d26aac66e9668edc81d7bfb4e801575514f:
> 
>   sh/kexec: Fix kexec build warning (2013-12-11 16:03:27 -0800)
> 
> 
> Geoff Levand (4):
>   kexec: Simplify conditional
>   kexec: Add IND_FLAGS macro
>   powerpc/kexec: Use global IND_FLAGS macro
>   sh/kexec: Fix kexec build warning

For this series (besides 4/4 v2):

Acked-by: WANG Chao 

> 
>  arch/powerpc/kernel/machine_kexec_64.c |  2 --
>  arch/sh/kernel/machine_kexec.c |  2 +-
>  include/linux/kexec.h  |  1 +
>  kernel/kexec.c | 17 ++---
>  4 files changed, 12 insertions(+), 10 deletions(-)
> 
> -- 
> 1.8.1.2
> 
> 
> ___
> kexec mailing list
> ke...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH v2] powerpc 8xx: Loading kernels over 8Mbytes without CONFIG_PIN_TLB

2013-12-16 Thread leroy christophe

Le 16/12/2013 23:57, Scott Wood a écrit :

On Wed, 2013-12-11 at 00:36 +0100, leroy christophe wrote:

Le 11/12/2013 00:18, Scott Wood a écrit :

There wasn't previously an ifdef specifically around the setting of
SPRN_MD_CTR.  That's new.  There was an ifdef around the entire block,
which has gone away because you are now trying to map more than 8M
regardless of CONFIG_PIN_TLB, but that has nothing to do with whether
there should be an ifdef around SPRN_MD_CTR.



Euh, ok, but then we have to fix it in the whole function, not only in
this block. Do you think it is worth doing it ?

Fix what in the whole function?  I was asking what harm there would be
if you just remove all the CONFIG_PIN_TLB ifdefs except around the
actual RSV4I setting -- do we really care what value goes in MD_CTR for
the non-pinned case, as long as it's different for each entry?



MD_CTR is decremented after each entry added.
However, the function populates entry 28, then 29, then 30, then 31. At 
the end MD_CTR has then value 30, ready to overide entry 30 then 29 then 
28 then 27 .


So I will remove all the CONFIG_PIN_TLB, but I'll also have to fix the 
value set in MD_CTR to start from 31, won't I ?


Do you have any comment/recommendation on my tentative v3 patch where I 
have tried to implement based on the use of r7 as you recommended ?


Christophe
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 6/9] powerpc/pci: Use dev_is_pci() to check whether it is pci device

2013-12-16 Thread Wei Yang
On Mon, Dec 16, 2013 at 05:05:05PM +0800, Yijing Wang wrote:
>On 2013/12/16 15:13, Wei Yang wrote:
>> Yijing,
>> 
>> This one looks good.
>> 
>> While I take a look at the source code, there are around 20 places with
>> similar style. Do you think it would be good to change all these places
>> in one patch?
>
>I sent the other similar changes to related maillist, some of them (David, 
>Greg )has been accepted,
>and other is not. :)
>
>eg.
>http://article.gmane.org/gmane.linux.kernel/1608341/match=dev_is_pci

Ah, I see. Thanks :-)

>
>Thanks!
>Yijing.
>
>> 
>> On Thu, Dec 05, 2013 at 08:01:20PM +0800, Yijing Wang wrote:
>>> Use PCI standard marco dev_is_pci() instead of directly compare
>>> pci_bus_type to check whether it is pci device.
>>>
>>> Signed-off-by: Yijing Wang 
>>> ---
>>> arch/powerpc/sysdev/fsl_pci.c |2 +-
>>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
>>> index 4dfd61d..7066e52 100644
>>> --- a/arch/powerpc/sysdev/fsl_pci.c
>>> +++ b/arch/powerpc/sysdev/fsl_pci.c
>>> @@ -122,7 +122,7 @@ static int fsl_pci_dma_set_mask(struct device *dev, u64 
>>> dma_mask)
>>>  * address width of the SoC such that we can address any internal
>>>  * SoC address from across PCI if needed
>>>  */
>>> -   if ((dev->bus == &pci_bus_type) &&
>>> +   if ((dev_is_pci(dev)) &&
>>> dma_mask >= DMA_BIT_MASK(MAX_PHYS_ADDR_BITS)) {
>>> set_dma_ops(dev, &dma_direct_ops);
>>> set_dma_offset(dev, pci64_dma_offset);
>>> -- 
>>> 1.7.1
>>>
>>>
>>> ___
>>> Linuxppc-dev mailing list
>>> Linuxppc-dev@lists.ozlabs.org
>>> https://lists.ozlabs.org/listinfo/linuxppc-dev
>> 
>
>
>-- 
>Thanks!
>Yijing

-- 
Richard Yang
Help you, Help me

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH 2/8] IBM Akebono: Add a SDHCI platform driver

2013-12-16 Thread Alistair Popple
Hi,

I originally sent this to the linuxppc-dev list thinking Ben H might take it, 
however it should go through the appropriate subsystem. Can someone please 
merge it into the appropriate tree (unless the are problems with it)?

Thanks.

Regards,

Alistair

On Fri, 22 Nov 2013 13:08:30 Alistair Popple wrote:
> This patch adds a SDHCI platform driver for the new IBM PPC476GTR SoC
> which is on the Akebono board.
> 
> Signed-off-by: Alistair Popple 
> Cc: Chris Ball 
> Cc: linux-...@vger.kernel.org
> ---
>  drivers/mmc/host/Kconfig   |   12 
>  drivers/mmc/host/Makefile  |1 +
>  drivers/mmc/host/sdhci-of-476gtr.c |   60
>  3 files changed, 73 insertions(+)
>  create mode 100644 drivers/mmc/host/sdhci-of-476gtr.c
> 
> diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
> index 7fc5099..14210df 100644
> --- a/drivers/mmc/host/Kconfig
> +++ b/drivers/mmc/host/Kconfig
> @@ -130,6 +130,18 @@ config MMC_SDHCI_OF_HLWD
> 
> If unsure, say N.
> 
> +config MMC_SDHCI_OF_476GTR
> + tristate "SDHCI OF support for the IBM PPC476GTR SoC"
> + depends on MMC_SDHCI_PLTFM
> + depends on PPC_OF
> + help
> +   This selects the Secure Digital Host Controller Interface (SDHCI)
> +   found on the PPC476GTR SoC.
> +
> +   If you have a controller with this interface, say Y or M here.
> +
> +   If unsure, say N.
> +
>  config MMC_SDHCI_CNS3XXX
>   tristate "SDHCI support on the Cavium Networks CNS3xxx SoC"
>   depends on ARCH_CNS3XXX
> diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
> index c41d0c3..92beff3 100644
> --- a/drivers/mmc/host/Makefile
> +++ b/drivers/mmc/host/Makefile
> @@ -59,6 +59,7 @@ obj-$(CONFIG_MMC_SDHCI_DOVE)+= sdhci-dove.o
>  obj-$(CONFIG_MMC_SDHCI_TEGRA)+= sdhci-tegra.o
>  obj-$(CONFIG_MMC_SDHCI_OF_ESDHC) += sdhci-of-esdhc.o
>  obj-$(CONFIG_MMC_SDHCI_OF_HLWD)  += sdhci-of-hlwd.o
> +obj-$(CONFIG_MMC_SDHCI_OF_476GTR)+= sdhci-of-476gtr.o
>  obj-$(CONFIG_MMC_SDHCI_BCM_KONA) += sdhci-bcm-kona.o
>  obj-$(CONFIG_MMC_SDHCI_BCM2835)  += sdhci-bcm2835.o
> 
> diff --git a/drivers/mmc/host/sdhci-of-476gtr.c
> b/drivers/mmc/host/sdhci-of-476gtr.c new file mode 100644
> index 000..1310f8c
> --- /dev/null
> +++ b/drivers/mmc/host/sdhci-of-476gtr.c
> @@ -0,0 +1,60 @@
> +/*
> + * drivers/mmc/host/sdhci-of-476gtr.c
> + *
> + * Copyright © 2013 Alistair Popple  IBM Corporation
> + *
> + * Based on sdhci-of-hlwd.c
> + *
> + * Copyright (C) 2009 The GameCube Linux Team
> + * Copyright (C) 2009 Albert Herranz
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or (at
> + * your option) any later version.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include "sdhci-pltfm.h"
> +
> +static const struct sdhci_ops sdhci_476gtr_ops = {
> +};
> +
> +static const struct sdhci_pltfm_data sdhci_476gtr_pdata = {
> + .ops = &sdhci_476gtr_ops,
> +};
> +
> +static int sdhci_476gtr_probe(struct platform_device *pdev)
> +{
> + return sdhci_pltfm_register(pdev, &sdhci_476gtr_pdata, 0);
> +}
> +
> +static int sdhci_476gtr_remove(struct platform_device *pdev)
> +{
> + return sdhci_pltfm_unregister(pdev);
> +}
> +
> +static const struct of_device_id sdhci_476gtr_of_match[] = {
> + { .compatible = "ibm,476gtr-sdhci" },
> + { }
> +};
> +MODULE_DEVICE_TABLE(of, sdhci_476gtr_of_match);
> +
> +static struct platform_driver sdhci_476gtr_driver = {
> + .driver = {
> + .name = "sdhci-476gtr",
> + .owner = THIS_MODULE,
> + .of_match_table = sdhci_476gtr_of_match,
> + .pm = SDHCI_PLTFM_PMOPS,
> + },
> + .probe = sdhci_476gtr_probe,
> + .remove = sdhci_476gtr_remove,
> +};
> +
> +module_platform_driver(sdhci_476gtr_driver);
> +
> +MODULE_DESCRIPTION("PPC476GTR SDHCI OF driver");
> +MODULE_AUTHOR("Alistair Popple");
> +MODULE_LICENSE("GPL v2");
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH v2] powerpc 8xx: Loading kernels over 8Mbytes without CONFIG_PIN_TLB

2013-12-16 Thread Scott Wood
On Wed, 2013-12-11 at 00:36 +0100, leroy christophe wrote:
> Le 11/12/2013 00:18, Scott Wood a écrit :
> > There wasn't previously an ifdef specifically around the setting of
> > SPRN_MD_CTR.  That's new.  There was an ifdef around the entire block,
> > which has gone away because you are now trying to map more than 8M
> > regardless of CONFIG_PIN_TLB, but that has nothing to do with whether
> > there should be an ifdef around SPRN_MD_CTR.
> >
> >
> Euh, ok, but then we have to fix it in the whole function, not only in 
> this block. Do you think it is worth doing it ?

Fix what in the whole function?  I was asking what harm there would be
if you just remove all the CONFIG_PIN_TLB ifdefs except around the
actual RSV4I setting -- do we really care what value goes in MD_CTR for
the non-pinned case, as long as it's different for each entry?

-Scott


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 1/5] powerpc/85xx/dts: add third elo3 dma component

2013-12-16 Thread Scott Wood
On Mon, 2013-12-16 at 17:12 +0800, Hongbo Zhang wrote:
> On 12/13/2013 01:43 PM, Liu Shengzhou-B36685 wrote:
> >
> >> -Original Message-
> >> From: Hongbo Zhang [mailto:hongbo.zh...@freescale.com]
> >> Sent: Thursday, December 12, 2013 5:57 PM
> >> To: Liu Shengzhou-B36685; linuxppc-dev@lists.ozlabs.org; Wood Scott-
> >> B07421
> >> Subject: Re: [PATCH 1/5] powerpc/85xx/dts: add third elo3 dma component
> >>
> >> Shengzhou,
> >> I canceled my patch http://patchwork.ozlabs.org/patch/295157/ because the
> >> original wrong elo3-dma-2.dtsi hadn't been merged.
> >> But please pay attention to comments from Scott about my changes of
> >> adding 208 for some interrupts, and take some actions if needed, or
> >> further discussions.
> >>
> >> Below comments form Scott:
> >> "The FSL MPIC binding should be updated to point out how this works.
> >> Technically it's not a change to the binding itself, since it's defined
> >> in terms of register offset, but the explanatory text says "So interrupt
> >> 0 is at offset 0x0, interrupt 1 is at offset 0x20, and so on." which is
> >> not accurate for these new high interrupt numbers."
> >>
> > Hongbo,
> > Could you update FSL MPIC binding as Scott pointed out?
> 
> We only need to add more explanatory text after the sentence Scott 
> pointed out, like:
> "But for some hardwares, the MPIC registers for interrupts are not 
> continuous in address,  in such cases, an offset can be added to the 
> interrupt number to skip the registers which is not for interrupts."
> 
> Scott, is that OK?

Actually, I misread what that sentence actually says, and it's correct
as is -- but not as helpful as it could be.

I'd add this new paragraph instead:

For example, internal interrupt 0 is at offset 0x200 and thus is
interrupt 16 in the device tree.  MSI bank A interrupt 0 is at offset
0x1c00, and thus is interrupt 224.  MPIC v4.3 adds a new discontiguous
address range for internal interrupts, so internal interrupt 160 is at
offset 0x3000, and thus is interrupt 384.

-Scott


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle

2013-12-16 Thread Scott Wood
On Sun, 2013-12-15 at 23:53 -0600, Wang Dongsheng-B40534 wrote:
> 
> > -Original Message-
> > From: Bhushan Bharat-R65777
> > Sent: Monday, November 11, 2013 12:11 PM
> > To: Wang Dongsheng-B40534; Wood Scott-B07421
> > Cc: linuxppc-dev@lists.ozlabs.org
> > Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and 
> > altivec
> > idle
> > 
> > > > Those codes just for discuss with Bharat. He want to make one flow at
> > > > "show_pw20_wait_time"/" show_altivec_idle_wait_time" function. If we
> > > > do that, we need to initialize pw20_wt/altivec_idle_wt.
> > > >
> > > I will keep this stuff at 
> > > "show_pw20_wait_time"/"show_altivec_idle_wait_time"
> > > and add a comment before our discussion.
> > >
> > > /*
> > >  * If the "value" less than 10, this will overflow.
> > >  * From benchmark test, the default wait bit will not be set less than 
> > > 10bit.
> > >  * Because 10 bit corresponds to the wait entry time is 
> > > 439375573401999609(ns),
> > >  * for wait-entry-idle time this value looks too long, and we cannot use 
> > > those
> > >  * "long" time as a default wait-entry time. So overflow could not have
> > happened
> > >  * and we use this calculation method to get wait-entry-idle time.
> > >  */
> > 
> > I think now we will use same calculation code for default value and user set
> > value, so adding the comment is not sufficient, we should error out from the
> > code if value is less than 10. As default value is not less than 10 so this 
> > will
> > always work with default value but if user tries to set less than 10 then 
> > error
> > out and ask user to try more than 9.
> > 
> Again, once the user has set up a time, the code will go to another branch.
> 
> else {
>   time = pw20_wt;
> }
> 
> We do so much for this a little function processing is not worth it. If we 
> can't
> agree on this sys interface. I will change this sys interface to 
> show_pw20_wait_bit. :)

Please don't change it.

-Scott


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH 10/10] Kconfig: cleanup SERIO_I8042 dependencies

2013-12-16 Thread Ralf Baechle
On Sat, Dec 14, 2013 at 11:59:36AM -0500, Mark Salter wrote:

> - depends on !PARISC && (!ARM || FOOTBRIDGE_HOST) && \
> -(!SUPERH || SH_CAYMAN) && !M68K && !BLACKFIN && !S390 && \
> -!ARC
> + depends on ARCH_MIGHT_HAVE_PC_SERIO

Most dependencies on an architecture's kconfig symbol outside arch/
should probably be treated as a bug.

Acked-by: Ralf Baechle 

  Ralf
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH v2] powerpc/powernv: Framework to log critical errors on powernv.

2013-12-16 Thread Deepthi Dharwar

This patch provides error logging interfaces to report critical
powernv error to FSP.
All the required information to dump the error is collected
at POWERNV level through error log interfaces
and then pushed on to FSP.

This also supports synchronous error logging in cases of
PANIC, by passing OPAL_ERROR_PANIC as severity in
elog_create() call.

Signed-off-by: Deepthi Dharwar 
---
 arch/powerpc/include/asm/opal.h|  125 
 arch/powerpc/platforms/powernv/opal-elog.c |   60 +++-
 arch/powerpc/platforms/powernv/opal-wrappers.S |1 
 3 files changed, 185 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index 0f01308..1c5440a 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -168,6 +168,7 @@ extern int opal_enter_rtas(struct rtas_args *args,
 #define OPAL_GET_MSG   85
 #define OPAL_CHECK_ASYNC_COMPLETION86
 #define OPAL_SYNC_HOST_REBOOT  87
+#define OPAL_ELOG_SEND 88
 
 #ifndef __ASSEMBLY__
 
@@ -260,6 +261,122 @@ enum OpalMessageType {
OPAL_MSG_TYPE_MAX,
 };
 
+/* Classification of Error/Events reporting type classification
+ * Platform Events/Errors: Report Machine Check Interrupt
+ * INPUT_OUTPUT: Report all I/O related events/errors
+ * RESOURCE_DEALLOC: Hotplug events and errors
+ * MISC: Miscellanous error
+ * Field: error_events_type
+ */
+enum error_events {
+   OPAL_PLATFORM,
+   OPAL_INPUT_OUTPUT,
+   OPAL_RESOURCE_DEALLOC,
+   OPAL_MISC,
+};
+
+/* OPAL Subsystem IDs listed for reporting events/errors
+ * Field: subsystem_id
+ */
+
+#define OPAL_PROCESSOR_SUBSYSTEM0x10
+#define OPAL_MEMORY_SUBSYSTEM   0x20
+#define OPAL_IO_SUBSYSTEM   0x30
+#define OPAL_IO_DEVICES 0x40
+#define OPAL_CEC_HARDWARE   0x50
+#define OPAL_POWER_COOLING  0x60
+#define OPAL_MISC_SUBSYSTEM 0x70
+#define OPAL_SURVEILLANCE_ERR   0x7A
+#define OPAL_PLATFORM_FIRMWARE  0x80
+#define OPAL_SOFTWARE   0x90
+#define OPAL_EXTERNAL_ENV   0xA0
+
+/* During reporting an event/error the following represents
+ * how serious the logged event/error is. (Severity)
+ * Field: event_sev
+ */
+#define OPAL_INFO   0x00
+#define OPAL_RECOVERED_ERR_GENERAL  0x10
+
+/* 0x2X series is to denote set of Predictive Error
+ * 0x20 Generic predictive error
+ * 0x21 Predictive error, degraded performance
+ * 0x22 Predictive error, fault may be corrected after reboot
+ * 0x23 Predictive error, fault may be corrected after reboot,
+ * degraded performance
+ * 0x24 Predictive error, loss of redundancy
+ */
+#define OPAL_PREDICTIVE_ERR_GENERAL 0x20
+#define OPAL_PREDICTIVE_ERR_DEGRADED_PERF   0x21
+#define OPAL_PREDICTIVE_ERR_FAULT_RECTIFY_REBOOT0x22
+#define OPAL_PREDICTIVE_ERR_FAULT_RECTIFY_BOOT_DEGRADE_PERF 0x23
+#define OPAL_PREDICTIVE_ERR_LOSS_OF_REDUNDANCY  0x24
+
+/* 0x4X series for Unrecoverable Error
+ * 0x40 Generic Unrecoverable error
+ * 0x41 Unrecoverable error bypassed with degraded performance
+ * 0x44 Unrecoverable error bypassed with loss of redundancy
+ * 0x45 Unrecoverable error bypassed with loss of redundancy and performance
+ * 0x48 Unrecoverable error bypassed with loss of function
+ */
+#define OPAL_UNRECOVERABLE_ERR_GENERAL  0x40
+#define OPAL_UNRECOVERABLE_ERR_DEGRADE_PERF 0x41
+#define OPAL_UNRECOVERABLE_ERR_LOSS_REDUNDANCY  0x44
+#define OPAL_UNRECOVERABLE_ERR_LOSS_REDUNDANCY_PERF 0x45
+#define OPAL_UNRECOVERABLE_ERR_LOSS_OF_FUNCTION 0x48
+#define OPAL_ERROR_PANIC0x50
+
+/* Event Sub-type
+ * This field provides additional information on the non-error
+ * event type
+ * Field: event_subtype
+ */
+#define OPAL_NA 0x00
+#define OPAL_MISCELLANEOUS_INFO_ONLY0x01
+#define OPAL_PREV_REPORTED_ERR_RECTIFIED0x10
+#define OPAL_SYS_RESOURCES_DECONFIG_BY_USER 0x20
+#define OPAL_SYS_RESOURCE_DECONFIG_PRIOR_ERR0x21
+#define OPAL_RESOURCE_DEALLOC_EVENT_NOTIFY  0x22
+#define OPAL_CONCURRENT_MAINTENANCE_EVENT   0x40
+#define OPAL_CAPACITY_UPGRADE_EVENT 0x60
+#define OPAL_RESOURCE_SPARING_EVENT 0x70
+#define OPAL_DYNAMIC_RECONFIG_EVENT 0x80
+#define OPAL_NORMAL_SYS_PLATFORM_SHUTDOWN   0xD0
+#define OPAL_ABNORMAL_POWER_OFF 0xE0
+
+/* Max user dump size is 14K*/
+#define OPAL_LOG_MAX_DUMP   14336
+
+/* Multiple user data sections */
+struct opal_usr_data_scn {
+   uint32_t tag;
+   uint16_t size;
+   uint16_t component_id;
+   char data

[PATCH 2/2] drivers: tty: Mark the function hvc_poll_init() as static in hvc_console.c

2013-12-16 Thread Rashika Kheria
Mark the function hvc_poll_init() as static in hvc/hvc_console.c because
it is not used outside this file.

This eliminates the following warning in hvc/hvc_console.c:
drivers/tty/hvc/hvc_console.c:791:5: warning: no previous prototype for 
‘hvc_poll_init’ [-Wmissing-prototypes]

Signed-off-by: Rashika Kheria 
---
 drivers/tty/hvc/hvc_console.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c
index 9eba119..50b4688 100644
--- a/drivers/tty/hvc/hvc_console.c
+++ b/drivers/tty/hvc/hvc_console.c
@@ -788,7 +788,7 @@ static int hvc_tiocmset(struct tty_struct *tty,
 }
 
 #ifdef CONFIG_CONSOLE_POLL
-int hvc_poll_init(struct tty_driver *driver, int line, char *options)
+static int hvc_poll_init(struct tty_driver *driver, int line, char *options)
 {
return 0;
 }
-- 
1.7.9.5

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 2/2] drivers: tty: Mark the function hvc_poll_init() as static in hvc_console.c

2013-12-16 Thread Josh Triplett
On Mon, Dec 16, 2013 at 04:31:28PM +0530, Rashika Kheria wrote:
> Mark the function hvc_poll_init() as static in hvc/hvc_console.c because
> it is not used outside this file.
> 
> This eliminates the following warning in hvc/hvc_console.c:
> drivers/tty/hvc/hvc_console.c:791:5: warning: no previous prototype for 
> ‘hvc_poll_init’ [-Wmissing-prototypes]
> 
> Signed-off-by: Rashika Kheria 

Reviewed-by: Josh Triplett 

>  drivers/tty/hvc/hvc_console.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c
> index 9eba119..50b4688 100644
> --- a/drivers/tty/hvc/hvc_console.c
> +++ b/drivers/tty/hvc/hvc_console.c
> @@ -788,7 +788,7 @@ static int hvc_tiocmset(struct tty_struct *tty,
>  }
>  
>  #ifdef CONFIG_CONSOLE_POLL
> -int hvc_poll_init(struct tty_driver *driver, int line, char *options)
> +static int hvc_poll_init(struct tty_driver *driver, int line, char *options)
>  {
>   return 0;
>  }
> -- 
> 1.7.9.5
> 
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH] powerpc/powernv: Read opal error log and export it through sysfs interface.

2013-12-16 Thread Mahesh J Salgaonkar
From: Mahesh Salgaonkar 

This patch adds support to read error logs from OPAL and export them
to userspace through sysfs interface /sys/firmware/opa/opal-elog.

This patch buffers 128 error log records until it is consumed by userspace
tool. This patch provides an sysfs interface '/sys/firmware/opa/opal-elog-ack'
to user to receive an acknowledgement of successful log consumption.

This is what user space tool would do:
- Read error log from /sys/firmware/opa/opal-elog.
- Save it to the disk.
- Send an acknowledgement on successful consumption by writing error log
  id to /sys/firmware/opa/opal-elog-ack.

Signed-off-by: Mamatha Inamdar 
Signed-off-by: Mahesh Salgaonkar 
Signed-off-by: Vasant Hegde 
---
 arch/powerpc/include/asm/opal.h|   11 +
 arch/powerpc/platforms/powernv/Makefile|2 
 arch/powerpc/platforms/powernv/opal-elog.c |  309 
 arch/powerpc/platforms/powernv/opal-wrappers.S |5 
 arch/powerpc/platforms/powernv/opal.c  |2 
 5 files changed, 328 insertions(+), 1 deletion(-)
 create mode 100644 arch/powerpc/platforms/powernv/opal-elog.c

diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index 5462fa7..723a7db 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -129,6 +129,11 @@ extern int opal_enter_rtas(struct rtas_args *args,
 #define OPAL_LPC_READ  67
 #define OPAL_LPC_WRITE 68
 #define OPAL_RETURN_CPU69
+#define OPAL_ELOG_READ 71
+#define OPAL_ELOG_WRITE72
+#define OPAL_ELOG_ACK  73
+#define OPAL_ELOG_RESEND   74
+#define OPAL_ELOG_SIZE 75
 #define OPAL_FLASH_VALIDATE76
 #define OPAL_FLASH_MANAGE  77
 #define OPAL_FLASH_UPDATE  78
@@ -727,6 +732,11 @@ int64_t opal_lpc_write(uint32_t chip_id, enum 
OpalLPCAddressType addr_type,
   uint32_t addr, uint32_t data, uint32_t sz);
 int64_t opal_lpc_read(uint32_t chip_id, enum OpalLPCAddressType addr_type,
  uint32_t addr, uint32_t *data, uint32_t sz);
+int64_t opal_read_elog(uint64_t buffer, size_t size, uint64_t log_id);
+int64_t opal_get_elog_size(uint64_t *log_id, size_t *size, uint64_t 
*elog_type);
+int64_t opal_write_elog(uint64_t buffer, uint64_t size, uint64_t offset);
+int64_t opal_send_ack_elog(uint64_t log_id);
+void opal_resend_pending_logs(void);
 int64_t opal_validate_flash(uint64_t buffer, uint32_t *size, uint32_t *result);
 int64_t opal_manage_flash(uint8_t op);
 int64_t opal_update_flash(uint64_t blk_list);
@@ -761,6 +771,7 @@ extern void opal_get_rtc_time(struct rtc_time *tm);
 extern unsigned long opal_get_boot_time(void);
 extern void opal_nvram_init(void);
 extern void opal_flash_init(void);
+extern int opal_elog_init(void);
 
 extern int opal_machine_check(struct pt_regs *regs);
 extern bool opal_mce_check_early_recovery(struct pt_regs *regs);
diff --git a/arch/powerpc/platforms/powernv/Makefile 
b/arch/powerpc/platforms/powernv/Makefile
index 873fa13..0f692eb 100644
--- a/arch/powerpc/platforms/powernv/Makefile
+++ b/arch/powerpc/platforms/powernv/Makefile
@@ -1,6 +1,6 @@
 obj-y  += setup.o opal-takeover.o opal-wrappers.o opal.o
 obj-y  += opal-rtc.o opal-nvram.o opal-lpc.o opal-flash.o
-obj-y  += rng.o
+obj-y  += rng.o opal-elog.o
 
 obj-$(CONFIG_SMP)  += smp.o
 obj-$(CONFIG_PCI)  += pci.o pci-p5ioc2.o pci-ioda.o
diff --git a/arch/powerpc/platforms/powernv/opal-elog.c 
b/arch/powerpc/platforms/powernv/opal-elog.c
new file mode 100644
index 000..fc891ae
--- /dev/null
+++ b/arch/powerpc/platforms/powernv/opal-elog.c
@@ -0,0 +1,309 @@
+/*
+ * Error log support on PowerNV.
+ *
+ * Copyright 2013 IBM Corp.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Maximum size of a single log on FSP is 16KB */
+#define OPAL_MAX_ERRLOG_SIZE   16384
+
+/* maximu number of records powernv can hold */
+#define MAX_NUM_RECORD 128
+
+struct opal_err_log {
+   struct list_head link;
+   uint64_t opal_log_id;
+   size_t opal_log_size;
+   uint8_t data[OPAL_MAX_ERRLOG_SIZE];
+};
+
+/* Pre-allocated temp buffer to pull error log from opal. */
+static uint8_t err_log_data[OPAL_MAX_ERRLOG_SIZE];
+/* Protect err_log_data buf */
+static DEFINE_MUTEX(err_log_data_mutex);
+
+static uint64_t total_log_size;
+static bool opal_log_available;
+static LIST_HEAD(elog_list);
+static LIST_HEAD(elog_ack_list);
+
+/* lock t

Re: [PATCH] This patch adds support to read error logs from OPAL and export them

2013-12-16 Thread Mahesh Jagannath Salgaonkar
On 12/16/2013 10:47 AM, Mahesh J Salgaonkar wrote:
> From: Mahesh Salgaonkar 
> 
> to userspace through sysfs interface /sys/firmware/opa/opal-elog.
> 
> This patch buffers 128 error log records until it is consumed by userspace
> tool. This patch provides an sysfs interface '/sys/firmware/opa/opal-elog-ack'
> to user to receive an acknowledgement of successful log consumption.
> 
> This is what user space tool would do:
> - Read error log from /sys/firmware/opa/opal-elog.
> - Save it to the disk.
> - Send an acknowledgement on successful consumption by writing error log
>   id to /sys/firmware/opa/opal-elog-ack.
> 
> Signed-off-by: Mamatha Inamdar 
> Signed-off-by: Mahesh Salgaonkar 
> Signed-off-by: Vasant Hegde 

Please ignore this patch. I messed up the subject line, I dunno how.. My
bad. I will resend this patch with correct subject.

Thanks,
-Mahesh.

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH 1/5] powerpc/85xx/dts: add third elo3 dma component

2013-12-16 Thread Hongbo Zhang


On 12/13/2013 01:43 PM, Liu Shengzhou-B36685 wrote:



-Original Message-
From: Hongbo Zhang [mailto:hongbo.zh...@freescale.com]
Sent: Thursday, December 12, 2013 5:57 PM
To: Liu Shengzhou-B36685; linuxppc-dev@lists.ozlabs.org; Wood Scott-
B07421
Subject: Re: [PATCH 1/5] powerpc/85xx/dts: add third elo3 dma component

Shengzhou,
I canceled my patch http://patchwork.ozlabs.org/patch/295157/ because the
original wrong elo3-dma-2.dtsi hadn't been merged.
But please pay attention to comments from Scott about my changes of
adding 208 for some interrupts, and take some actions if needed, or
further discussions.

Below comments form Scott:
"The FSL MPIC binding should be updated to point out how this works.
Technically it's not a change to the binding itself, since it's defined
in terms of register offset, but the explanatory text says "So interrupt
0 is at offset 0x0, interrupt 1 is at offset 0x20, and so on." which is
not accurate for these new high interrupt numbers."


Hongbo,
Could you update FSL MPIC binding as Scott pointed out?


We only need to add more explanatory text after the sentence Scott 
pointed out, like:
"But for some hardwares, the MPIC registers for interrupts are not 
continuous in address,  in such cases, an offset can be added to the 
interrupt number to skip the registers which is not for interrupts."


Scott, is that OK?

Thanks.


thanks,
Shengzhou




___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH 6/9] powerpc/pci: Use dev_is_pci() to check whether it is pci device

2013-12-16 Thread Yijing Wang
On 2013/12/16 15:13, Wei Yang wrote:
> Yijing,
> 
> This one looks good.
> 
> While I take a look at the source code, there are around 20 places with
> similar style. Do you think it would be good to change all these places
> in one patch?

I sent the other similar changes to related maillist, some of them (David, Greg 
)has been accepted,
and other is not. :)

eg.
http://article.gmane.org/gmane.linux.kernel/1608341/match=dev_is_pci

Thanks!
Yijing.

> 
> On Thu, Dec 05, 2013 at 08:01:20PM +0800, Yijing Wang wrote:
>> Use PCI standard marco dev_is_pci() instead of directly compare
>> pci_bus_type to check whether it is pci device.
>>
>> Signed-off-by: Yijing Wang 
>> ---
>> arch/powerpc/sysdev/fsl_pci.c |2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
>> index 4dfd61d..7066e52 100644
>> --- a/arch/powerpc/sysdev/fsl_pci.c
>> +++ b/arch/powerpc/sysdev/fsl_pci.c
>> @@ -122,7 +122,7 @@ static int fsl_pci_dma_set_mask(struct device *dev, u64 
>> dma_mask)
>>   * address width of the SoC such that we can address any internal
>>   * SoC address from across PCI if needed
>>   */
>> -if ((dev->bus == &pci_bus_type) &&
>> +if ((dev_is_pci(dev)) &&
>>  dma_mask >= DMA_BIT_MASK(MAX_PHYS_ADDR_BITS)) {
>>  set_dma_ops(dev, &dma_direct_ops);
>>  set_dma_offset(dev, pci64_dma_offset);
>> -- 
>> 1.7.1
>>
>>
>> ___
>> Linuxppc-dev mailing list
>> Linuxppc-dev@lists.ozlabs.org
>> https://lists.ozlabs.org/listinfo/linuxppc-dev
> 


-- 
Thanks!
Yijing

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev