* RE: [PATCH 02/14] dwc/otg: Structure declaration for shared data
From: Tirumala Marri @ 2011-08-30 15:29 UTC (permalink / raw)
To: Pratyush Anand, linux-usb
Cc: viresh.kumar, vipulkumar.samar, bhupesh.sharma, vipin.kumar,
shiraz.hashim, Amit.VIRDI, rajeev-dlh.kumar, Mark Miesfeld,
deepak.sikri, linuxppc-dev, Fushen Chen
In-Reply-To: <d10bbf1498af371e41907fa07624456d981e56af.1314704557.git.pratyush.anand@st.com>
<-----Original Message-----
<From: Pratyush Anand [mailto:pratyush.anand@st.com]
<Sent: Tuesday, August 30, 2011 4:58 AM
<To: linux-usb@vger.kernel.org
<Cc: tmarri@apm.com; linuxppc-dev@lists.ozlabs.org; fchen@apm.com;
<mmiesfeld@apm.com; shiraz.hashim@st.com; deepak.sikri@st.com;
<vipulkumar.samar@st.com; rajeev-dlh.kumar@st.com; vipin.kumar@st.com;
<bhupesh.sharma@st.com; viresh.kumar@st.com; Amit.VIRDI@st.com; Pratyush
<Anand
<Subject: [PATCH 02/14] dwc/otg: Structure declaration for shared data
<
<There are some DWC OTG parameters which might be passed by a platform.
<Declaration for structure of those parameters have been provided in this
<include file.
<
<Signed-off-by: Pratyush Anand <pratyush.anand@st.com>
<---
< include/linux/usb/dwc_otg.h | 274
[Tirumala Marri] I am not sure how to separate your changes. But we need
More time as our initial patches are still pending.
--marri
^ permalink raw reply
* Re: [PATCH 11/14] dwc/otg: Driver enable gadget support
From: Pratyush Anand @ 2011-08-30 15:40 UTC (permalink / raw)
To: Sergei Shtylyov, tmarri
Cc: Pratyush Anand, viresh.kumar, vipulkumar.samar, bhupesh.sharma,
linux-usb, vipin.kumar, shiraz.hashim, Amit.VIRDI,
rajeev-dlh.kumar, mmiesfeld, deepak.sikri, linuxppc-dev, fchen
In-Reply-To: <4E5CDF2C.8030400@ru.mvista.com>
On Tue, Aug 30, 2011 at 6:31 PM, Sergei Shtylyov <sshtylyov@mvista.com> wro=
te:
>
> Hello.
>
> On 08/30/2011 03:57 PM, Pratyush Anand wrote:
>
>> From: Tirumala Marri<tmarri@apm.com>
>
>> Enable gadget support
>
>> Signed-off-by: Tirumala R Marri<tmarri@apm.com>
>> Signed-off-by: Fushen Chen<fchen@apm.com>
>> Signed-off-by: Mark Miesfeld<mmiesfeld@apm.com>
>> Signed-off-by: Pratyush Anand<pratyush.anand@st.com>
>> ---
>> =A0drivers/usb/gadget/gadget_chips.h | =A0 18 +++++++++++++++++-
>> =A01 files changed, 17 insertions(+), 1 deletions(-)
>
>> diff --git a/drivers/usb/gadget/gadget_chips.h b/drivers/usb/gadget/gadg=
et_chips.h
>> index 0978103..66b8018 100644
>> --- a/drivers/usb/gadget/gadget_chips.h
>> +++ b/drivers/usb/gadget/gadget_chips.h
>> @@ -148,6 +148,19 @@
>> =A0#define gadget_is_s3c_hsotg(g) =A0 =A00
>> =A0#endif
>>
>> +#if defined(CONFIG_DWC_OTG_MODE) || defined(CONFIG_DWC_DEVICE_ONLY)
>> +#define gadget_is_dwc_otg_pcd(g) =A0 =A0 =A0 (!strcmp("dwc_otg_pcd", (g=
)->name))
>> +#else
>> +#define gadget_is_dwc_otg_pcd(g) =A0 =A0 =A0 0
>> +#endif
>> +
>> +#ifdef CONFIG_USB_GADGET_CI13XXX_MSM
>> +#define gadget_is_ci13xxx_msm(g) =A0 =A0 =A0 (!strcmp("ci13xxx_msm", (g=
)->name))
>> +#else
>> +#define gadget_is_ci13xxx_msm(g) =A0 =A0 =A0 0
>> +#endif
>> +
>> +
>
> =A0 Too many newlines.
>
will correct it.
>>
>> =A0/**
>> =A0 * usb_gadget_controller_number - support bcdDevice id convention
>> @@ -208,10 +221,13 @@ static inline int usb_gadget_controller_number(str=
uct usb_gadget *gadget)
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return 0x26;
>> =A0 =A0 =A0 =A0else if (gadget_is_designware(gadget))
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return 0x27;
>> + =A0 =A0 =A0 else if (gadget_is_ci13xxx_msm(gadget))
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return 0x28;
>> + =A0 =A0 =A0 else if (gadget_is_dwc_otg_pcd(gadget))
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return 0x29;
>
> =A0 Hm, why are you adding 2 gadgets?
Yes, I also do not see reason for ci13xxx_msm.
This was added by original auther Tirumala.
@Tirumala , Please reply.
>
>> =A0 =A0 =A0 =A0return -ENOENT;
>> =A0}
>>
>> -
>
> =A0 Unrelated white space change.
will correct.
>
>> =A0/**
>> =A0 * gadget_supports_altsettings - return true if altsettings work
>> =A0 * @gadget: the gadget in question
>
> WBR, Sergei
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at =A0http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 02/14] dwc/otg: Structure declaration for shared data
From: Pratyush Anand @ 2011-08-30 15:43 UTC (permalink / raw)
To: Tirumala Marri
Cc: Pratyush Anand, viresh.kumar, vipulkumar.samar, bhupesh.sharma,
linux-usb, vipin.kumar, shiraz.hashim, Amit.VIRDI,
rajeev-dlh.kumar, Mark Miesfeld, deepak.sikri, linuxppc-dev,
Fushen Chen
In-Reply-To: <9183dc7afa5b8cde400e9f37f5679d4f@mail.gmail.com>
On Tue, Aug 30, 2011 at 8:59 PM, Tirumala Marri <tmarri@apm.com> wrote:
> <-----Original Message-----
> <From: Pratyush Anand [mailto:pratyush.anand@st.com]
> <Sent: Tuesday, August 30, 2011 4:58 AM
> <To: linux-usb@vger.kernel.org
> <Cc: tmarri@apm.com; linuxppc-dev@lists.ozlabs.org; fchen@apm.com;
> <mmiesfeld@apm.com; shiraz.hashim@st.com; deepak.sikri@st.com;
> <vipulkumar.samar@st.com; rajeev-dlh.kumar@st.com; vipin.kumar@st.com;
> <bhupesh.sharma@st.com; viresh.kumar@st.com; Amit.VIRDI@st.com; Pratyush
> <Anand
> <Subject: [PATCH 02/14] dwc/otg: Structure declaration for shared data
> <
> <There are some DWC OTG parameters which might be passed by a platform.
> <Declaration for structure of those parameters have been provided in this
> <include file.
> <
> <Signed-off-by: Pratyush Anand <pratyush.anand@st.com>
> <---
> < include/linux/usb/dwc_otg.h | =A0274
>
> [Tirumala Marri] I am not sure how to separate your changes. But we need
> More time as our initial patches are still pending.
> --marri
Tirumala,
If you agree , then I can send you modifications which I did over your
patches(v13) separately,
and then you can decide the final inclusion of only these modifications.
Regards
Pratyush
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at =A0http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH 00/14] Modifications for DWC OTG since v13
From: Pratyush Anand @ 2011-08-30 15:46 UTC (permalink / raw)
To: Tirumala Marri
Cc: Pratyush Anand, viresh.kumar, vipulkumar.samar, bhupesh.sharma,
linux-usb, vipin.kumar, shiraz.hashim, Amit.VIRDI,
rajeev-dlh.kumar, Mark Miesfeld, deepak.sikri, linuxppc-dev,
Fushen Chen
In-Reply-To: <bff62861217ab3d8dbf8041e2c4d1c8c@mail.gmail.com>
On Tue, Aug 30, 2011 at 8:57 PM, Tirumala Marri <tmarri@apm.com> wrote:
> <-----Original Message-----
> <From: Pratyush Anand [mailto:pratyush.anand@st.com]
> <Sent: Tuesday, August 30, 2011 4:58 AM
> <To: linux-usb@vger.kernel.org
> <Cc: tmarri@apm.com; linuxppc-dev@lists.ozlabs.org; fchen@apm.com;
> <mmiesfeld@apm.com; shiraz.hashim@st.com; deepak.sikri@st.com;
> <vipulkumar.samar@st.com; rajeev-dlh.kumar@st.com; vipin.kumar@st.com;
> <bhupesh.sharma@st.com; viresh.kumar@st.com; Amit.VIRDI@st.com; Pratyush
> <Anand
> <Subject: [PATCH 00/14] Modifications for DWC OTG since v13
> <
> <These patches are based on:http://patchwork.ozlabs.org/patch/89560/
> <After not getting any reply from developers, I started to do
> <modifications for my platform (SPEAr1340).
> <I have done modifications in such a way that all the code in
> <driver/usb/dwc/ would be platform independent.
> <I have tested this code for host/device/dma/slave mode.
> <My fifo configuration is dedicated and dynamic.
>
> [Tirumala Marri] We are working on our next release of patches. They
> should be coming out soon.
Oh, thats great !!
Actually, I did not get any reply of my previous mail on your patch release=
.
I thought no one is maintaining., and so I sent them with my modifications,
after testing them in all dev/host/otg mode.
Regards
Pratyush
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at =A0http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: kvm PCI assignment & VFIO ramblings
From: Joerg Roedel @ 2011-08-30 16:13 UTC (permalink / raw)
To: Alex Williamson
Cc: chrisw, Alexey Kardashevskiy, kvm@vger.kernel.org, Paul Mackerras,
Roedel, Joerg, linux-pci@vger.kernel.org, qemu-devel,
Aaron Fabbri, iommu, Avi Kivity, Anthony Liguori, linuxppc-dev,
benve@cisco.com
In-Reply-To: <1314381863.2859.312.camel@bling.home>
On Fri, Aug 26, 2011 at 12:04:22PM -0600, Alex Williamson wrote:
> On Thu, 2011-08-25 at 20:05 +0200, Joerg Roedel wrote:
> > If we really expect segment numbers that need the full 16 bit then this
> > would be the way to go. Otherwise I would prefer returning the group-id
> > directly and partition the group-id space for the error values (s32 with
> > negative numbers being errors).
>
> It's unlikely to have segments using the top bit, but it would be broken
> for an iommu driver to define it's group numbers using pci s:b:d.f if we
> don't have that bit available. Ben/David, do PEs have an identifier of
> a convenient size? I'd guess any hardware based identifier is going to
> use a full unsigned bit width.
Okay, if we want to go the secure way I am fine with the "int *group"
parameter. Another option is to just return u64 and use the extended
number space for errors. But that is even worse as an interface, I
think.
Joerg
^ permalink raw reply
* Re: kvm PCI assignment & VFIO ramblings
From: Joerg Roedel @ 2011-08-30 16:14 UTC (permalink / raw)
To: Avi Kivity
Cc: Alex Williamson, Alexey Kardashevskiy, kvm@vger.kernel.org,
Paul Mackerras, Roedel, Joerg, qemu-devel, Alexander Graf, chrisw,
iommu, Anthony Liguori, linux-pci@vger.kernel.org, linuxppc-dev,
benve@cisco.com
In-Reply-To: <4E5A4AF0.20707@redhat.com>
On Sun, Aug 28, 2011 at 05:04:32PM +0300, Avi Kivity wrote:
> On 08/28/2011 04:56 PM, Joerg Roedel wrote:
>> This can't be secured by a lock, because it introduces potential
>> A->B<-->B->A lock problem when two processes try to take each others mm.
>> It could probably be solved by a task->real_mm pointer, havn't thought
>> about this yet...
>>
>
> Or a workqueue - you get a kernel thread context with a bit of boilerplate.
Right, a workqueue might do the trick. We'll evaluate that. Thanks for
the idea :)
Joerg
^ permalink raw reply
* Re: [PATCH] powerpc: Fix xmon for systems without MSR[RI]
From: Scott Wood @ 2011-08-30 18:08 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1314684670.2488.82.camel@pasglop>
On 08/30/2011 01:11 AM, Benjamin Herrenschmidt wrote:
> On Mon, 2011-08-08 at 16:25 -0500, Jimi Xenidis wrote:
>> From: David Gibson <dwg@au1.ibm.com>
>>
>> Based on patch by David Gibson <dwg@au1.ibm.com>
>>
>> xmon has a longstanding bug on systems which are SMP-capable but lack
>> the MSR[RI] bit. In these cases, xmon invoked by IPI on secondary
>> CPUs will not properly keep quiet, but will print stuff, thereby
>> garbling the primary xmon's output. This patch fixes it, by ignoring
>> the RI bit if the processor does not support it.
>>
>> There's already a version of this for 4xx upstream, which we'll need
>> to extend to other RI-lacking CPUs at some point. For now this adds
>> BookE processors to the mix.
>
> Don't freescale one have RI ?
e500mc does.
e500v2 doesn't -- if a machine check happens while MSR[ME]=0, it causes
a checkstop.
-Scott
^ permalink raw reply
* [PATCH] Implement CONFIG_STRICT_DEVMEM support for Powerpc
From: Sukadev Bhattiprolu @ 2011-08-30 19:19 UTC (permalink / raw)
To: benh; +Cc: scottwood, linuxppc-dev, sbest, paulus
>From 9d899c6bcb685afc58245f1fcfe5de1e8b499856 Mon Sep 17 00:00:00 2001
From: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
Date: Mon, 29 Aug 2011 14:12:08 -0700
Subject: [PATCH 1/1] Implement CONFIG_STRICT_DEVMEM support for Powerpc.
As described in the help text in the patch, this token restricts general
access to /dev/mem as a way of increasing the security. Specifically, access
to exclusive IOMEM and kernel RAM is denied unless CONFIG_STRICT_DEVMEM is
set to 'n'.
Implement the 'devmem_is_allowed()' interface for Powerpc. It will be
called from range_is_allowed() when userpsace attempts to access /dev/mem.
This patch is based on an earlier patch from Steve Best and with input from
Paul Mackerras and Scott Wood.
Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
---
arch/powerpc/Kconfig.debug | 12 ++++++++++++
arch/powerpc/include/asm/page.h | 1 +
arch/powerpc/mm/mem.c | 16 ++++++++++++++++
drivers/char/mem.c | 4 ++--
4 files changed, 31 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/Kconfig.debug b/arch/powerpc/Kconfig.debug
index 067cb84..1cf1b00 100644
--- a/arch/powerpc/Kconfig.debug
+++ b/arch/powerpc/Kconfig.debug
@@ -298,4 +298,16 @@ config PPC_EARLY_DEBUG_CPM_ADDR
platform probing is done, all platforms selected must
share the same address.
+config STRICT_DEVMEM
+ def_bool y
+ prompt "Filter access to /dev/mem"
+ help
+ This option restricts access to /dev/mem. If this option is
+ disabled, you allow userspace access to all memory, including
+ kernel and userspace memory. Accidental memory access is likely
+ to be disastrous.
+ Memory access is required for experts who want to debug the kernel.
+
+ If you are unsure, say Y.
+
endmenu
diff --git a/arch/powerpc/include/asm/page.h b/arch/powerpc/include/asm/page.h
index 2cd664e..9eac49e 100644
--- a/arch/powerpc/include/asm/page.h
+++ b/arch/powerpc/include/asm/page.h
@@ -261,6 +261,7 @@ extern void clear_user_page(void *page, unsigned long vaddr, struct page *pg);
extern void copy_user_page(void *to, void *from, unsigned long vaddr,
struct page *p);
extern int page_is_ram(unsigned long pfn);
+extern int devmem_is_allowd(unsigned long pfn);
#ifdef CONFIG_PPC_SMLPAR
void arch_free_page(struct page *page, int order);
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index c781bbc..bb7537d 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -549,3 +549,19 @@ void update_mmu_cache(struct vm_area_struct *vma, unsigned long address,
hash_preload(vma->vm_mm, address, access, trap);
#endif /* CONFIG_PPC_STD_MMU */
}
+
+/*
+ * devmem_is_allowed(): check to see if /dev/mem access to a certain address
+ * is valid. The argument is a physical page number.
+ *
+ * Access has to be given to non-kernel-ram areas as well, these contain the
+ * PCI mmio resources as well as potential bios/acpi data regions.
+ */
+int devmem_is_allowed(unsigned long pfn)
+{
+ if (iomem_is_exclusive(pfn << PAGE_SHIFT))
+ return 0;
+ if (!page_is_ram(pfn))
+ return 1;
+ return 0;
+}
diff --git a/drivers/char/mem.c b/drivers/char/mem.c
index 8fc04b4..0fb542c 100644
--- a/drivers/char/mem.c
+++ b/drivers/char/mem.c
@@ -66,8 +66,8 @@ static inline int range_is_allowed(unsigned long pfn, unsigned long size)
while (cursor < to) {
if (!devmem_is_allowed(pfn)) {
printk(KERN_INFO
- "Program %s tried to access /dev/mem between %Lx->%Lx.\n",
- current->comm, from, to);
+ "Program %s tried to access /dev/mem between %Lx->%Lx and "
+ "pfn %lu.\n", current->comm, from, to, pfn);
return 0;
}
cursor += PAGE_SIZE;
--
1.7.0.4
^ permalink raw reply related
* Virtual addresses in arch/powerpc/boot/dts/tqm8548*.dts ?
From: Paul Walmsley @ 2011-08-30 21:43 UTC (permalink / raw)
To: Dmitry Eremin-Solenikov, Kumar Gala, Wolfgang Grandegger
Cc: devicetree-discuss, linuxppc-dev
Hi,
Looking at some of the PPC DTS files in arch/powerpc/boot/dts, there are
some files that are mostly identical, except for some strange
differences.
For example, tqm8548.dts and tqm8548-bigflash.dts differ mostly in that
the former file claims that the SoC registers start at 0xe0000000[1], but
the latter file claims that the SoC registers start at 0xa0000000[2].
Commit 02b8a3d1eb2ae6353cfbce627ded22e299cf1989 ("powerpc/85xx: support
for the TQM8548 module using the big Flash") claims that:
Some TQM85xx boards could be equipped with up to 1 GiB (NOR) flash
memory and therefore a modified memory map is required and setup by
the board loader. This patch adds an appropriate DTS file.
So are these addresses virtual? My (perhaps incorrect) understanding of
the device tree files was that they were intended to describe the physical
memory map, rather than the virtual memory map. Or does this PowerPC
variant have the ability to dynamically change its own physical address
decoding? Or is something else going on?
thanks for any clarification,
- Paul
1. arch/powerpc/boot/dts/tqm8548.dts line 53, as of Linux v3.1-rc3:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=arch/powerpc/boot/dts/tqm8548.dts;h=619776f72c904c611e9507d44db4bee1200e6688;hb=HEAD#l53
2. arch/powerpc/boot/dts/tqm8548-bigflash.dts line 53, as of Linux
v3.1-rc3:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=arch/powerpc/boot/dts/tqm8548-bigflash.dts;h=9452c3c05114e523033eebb278d7f78811890a87;hb=HEAD#l53
^ permalink raw reply
* Re: [PATCH] powerpc/fsl_msi: clean up and document calculation of MSIIR address
From: Tabi Timur-B04825 @ 2011-08-30 22:24 UTC (permalink / raw)
To: Gala Kumar-B11780; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1314404912-6947-1-git-send-email-timur@freescale.com>
Timur Tabi wrote:
> Commit 3da34aae (powerpc/fsl: Support unique MSI addresses per PCIe Root
> Complex) redefined the meanings of msi->msi_addr_hi and msi->msi_addr_lo =
to be
> an offset rather than an address. To help clarify the code, we make the
> following changes:
Kumar, I'm going to merge this patch into a bigger patch that makes a=20
bunch of other fixes.=
^ permalink raw reply
* Re: Virtual addresses in arch/powerpc/boot/dts/tqm8548*.dts ?
From: Gary Thomas @ 2011-08-30 22:39 UTC (permalink / raw)
To: Paul Walmsley; +Cc: Dmitry Eremin-Solenikov, devicetree-discuss, linuxppc-dev
In-Reply-To: <alpine.DEB.2.00.1108301508130.26173@utopia.booyaka.com>
On 2011-08-30 15:43, Paul Walmsley wrote:
>
> Hi,
>
> Looking at some of the PPC DTS files in arch/powerpc/boot/dts, there are
> some files that are mostly identical, except for some strange
> differences.
>
> For example, tqm8548.dts and tqm8548-bigflash.dts differ mostly in that
> the former file claims that the SoC registers start at 0xe0000000[1], but
> the latter file claims that the SoC registers start at 0xa0000000[2].
>
> Commit 02b8a3d1eb2ae6353cfbce627ded22e299cf1989 ("powerpc/85xx: support
> for the TQM8548 module using the big Flash") claims that:
>
> Some TQM85xx boards could be equipped with up to 1 GiB (NOR) flash
> memory and therefore a modified memory map is required and setup by
> the board loader. This patch adds an appropriate DTS file.
>
> So are these addresses virtual? My (perhaps incorrect) understanding of
> the device tree files was that they were intended to describe the physical
> memory map, rather than the virtual memory map. Or does this PowerPC
> variant have the ability to dynamically change its own physical address
> decoding? Or is something else going on?
These addresses correspond to the internal registers which can be moved.
The default address is set by hardware at reset time (check out the documentation
on the hardware reset word). Obviously one board is strapped for the IMMR
at one address, another board at a different address. I almost always configure
my boards to use 0xF0000000 for the IMMR.
>
>
> thanks for any clarification,
>
> - Paul
>
> 1. arch/powerpc/boot/dts/tqm8548.dts line 53, as of Linux v3.1-rc3:
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=arch/powerpc/boot/dts/tqm8548.dts;h=619776f72c904c611e9507d44db4bee1200e6688;hb=HEAD#l53
>
> 2. arch/powerpc/boot/dts/tqm8548-bigflash.dts line 53, as of Linux
> v3.1-rc3:
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=arch/powerpc/boot/dts/tqm8548-bigflash.dts;h=9452c3c05114e523033eebb278d7f78811890a87;hb=HEAD#l53
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply
* Re: [PATCH 2/2] [PowerPC Book3E] Introduce new ptrace debug feature flag
From: Thiago Jung Bauermann @ 2011-08-31 0:27 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, K.Prasad, Edjunior Barbosa Machado
In-Reply-To: <20110826044123.GI2308@yookeroo.fritz.box>
On Fri, 2011-08-26 at 14:41 +1000, David Gibson wrote:
> On Wed, Aug 24, 2011 at 09:41:43PM -0300, Thiago Jung Bauermann wrote:
> > On Wed, 2011-08-24 at 14:00 +1000, David Gibson wrote:
> > > On Tue, Aug 23, 2011 at 02:57:56PM +0530, K.Prasad wrote:
> > > > On Tue, Aug 23, 2011 at 03:09:31PM +1000, David Gibson wrote:
> > > > > On Fri, Aug 19, 2011 at 01:23:38PM +0530, K.Prasad wrote:
> > > > > >
> > > > > > While PPC_PTRACE_SETHWDEBUG ptrace flag in PowerPC accepts
> > > > > > PPC_BREAKPOINT_MODE_EXACT mode of breakpoint, the same is not intimated to the
> > > > > > user-space debuggers (like GDB) who may want to use it. Hence we introduce a
> > > > > > new PPC_DEBUG_FEATURE_DATA_BP_EXACT flag which will be populated on the
> > > > > > "features" member of "struct ppc_debug_info" to advertise support for the
> > > > > > same on Book3E PowerPC processors.
> > > > >
> > > > > I thought the idea was that the BP_EXACT mode was the default - if the
> > > > > new interface was supported at all, then BP_EXACT was always
> > > > > supported. So, why do you need a new flag?
> > > > >
> > > >
> > > > Yes, BP_EXACT was always supported but not advertised through
> > > > PPC_PTRACE_GETHWDBGINFO. We're now doing that.
> > >
> > > I can see that. But you haven't answered why.
> >
> > BookS doesn't support BP_EXACT, that's why I suggested this flag.
>
> Surely you can support it with exactly the same sort of filtering
> you're using for the 8-byte ranges now?
Yes, but to detect that the processor doesn't support BP_EXACT in
hardware I'd have to send a ptrace request, and have it rejected. Only
then I'd step back and simulate one with ranges. Considering that it's
easy and backwards compatible to add a new flag to signal that BP_EXACT
is not supported, I don't know why it would be better to go with the
more convoluted process.
--
[]'s
Thiago Jung Bauermann
IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCH 00/14] Modifications for DWC OTG since v13
From: Kyungmin Park @ 2011-08-31 1:18 UTC (permalink / raw)
To: Pratyush Anand
Cc: Pratyush Anand, viresh.kumar, vipulkumar.samar, bhupesh.sharma,
Tirumala Marri, linux-usb, vipin.kumar, shiraz.hashim, Amit.VIRDI,
rajeev-dlh.kumar, Mark Miesfeld, deepak.sikri, linuxppc-dev,
Fushen Chen
In-Reply-To: <CAHM4w1nWTxfMTSTbmt4vnWAKhj4JisJf1f0SjirOt7Z9vjORoA@mail.gmail.com>
On Wed, Aug 31, 2011 at 12:46 AM, Pratyush Anand
<pratyush.anand@gmail.com> wrote:
> On Tue, Aug 30, 2011 at 8:57 PM, Tirumala Marri <tmarri@apm.com> wrote:
>> <-----Original Message-----
>> <From: Pratyush Anand [mailto:pratyush.anand@st.com]
>> <Sent: Tuesday, August 30, 2011 4:58 AM
>> <To: linux-usb@vger.kernel.org
>> <Cc: tmarri@apm.com; linuxppc-dev@lists.ozlabs.org; fchen@apm.com;
>> <mmiesfeld@apm.com; shiraz.hashim@st.com; deepak.sikri@st.com;
>> <vipulkumar.samar@st.com; rajeev-dlh.kumar@st.com; vipin.kumar@st.com;
>> <bhupesh.sharma@st.com; viresh.kumar@st.com; Amit.VIRDI@st.com; Pratyush
>> <Anand
>> <Subject: [PATCH 00/14] Modifications for DWC OTG since v13
>> <
>> <These patches are based on:http://patchwork.ozlabs.org/patch/89560/
>> <After not getting any reply from developers, I started to do
>> <modifications for my platform (SPEAr1340).
>> <I have done modifications in such a way that all the code in
>> <driver/usb/dwc/ would be platform independent.
>> <I have tested this code for host/device/dma/slave mode.
>> <My fifo configuration is dedicated and dynamic.
>>
>> [Tirumala Marri] We are working on our next release of patches. They
>> should be coming out soon.
>
> Oh, thats great !!
> Actually, I did not get any reply of my previous mail on your patch relea=
se.
> I thought no one is maintaining., and so I sent them with my modification=
s,
> after testing them in all dev/host/otg mode.
>
> Regards
> Pratyush
Hi,
Can you provide the git repo to test?
and I wonder what's the difference between dwc (from you) and dwc3
(from Felipe Balbi). I think it's dwc targets for usb 2.0 and dwc3 for
usb 3.0.
Thank you,
Kyungmin Park
>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at =A0http://vger.kernel.org/majordomo-info.html
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at =A0http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: Virtual addresses in arch/powerpc/boot/dts/tqm8548*.dts ?
From: Paul Walmsley @ 2011-08-31 1:55 UTC (permalink / raw)
To: Gary Thomas; +Cc: Dmitry Eremin-Solenikov, devicetree-discuss, linuxppc-dev
In-Reply-To: <4E5D668B.1060609@mlbassoc.com>
On Tue, 30 Aug 2011, Gary Thomas wrote:
> On 2011-08-30 15:43, Paul Walmsley wrote:
>
> > So are these addresses virtual? My (perhaps incorrect) understanding of
> > the device tree files was that they were intended to describe the physical
> > memory map, rather than the virtual memory map. Or does this PowerPC
> > variant have the ability to dynamically change its own physical address
> > decoding? Or is something else going on?
>
> These addresses correspond to the internal registers which can be moved.
> The default address is set by hardware at reset time (check out the
> documentation on the hardware reset word). Obviously one board is
> strapped for the IMMR at one address, another board at a different
> address. I almost always configure my boards to use 0xF0000000 for the
> IMMR.
Got it. Thanks Gary.
- Paul
^ permalink raw reply
* Re: [PATCH] powerpc/85xx: clean up FPGA device tree nodes for Freecsale QorIQ boards
From: Kumar Gala @ 2011-08-31 2:26 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, devicetree-discuss
In-Reply-To: <1314644999-16955-1-git-send-email-timur@freescale.com>
On Aug 29, 2011, at 2:09 PM, Timur Tabi wrote:
> Standarize and document the FPGA nodes used on Freescale QorIQ =
reference
> boards. There are three kinds of FPGAs used on the boards: pixis, =
qixis, and
> cpld. Although their are minor differences among the boards that have =
one
> kind of FPGA, most of the functionality is the same, so it makes sense
> to create common compatibility strings.
>=20
> Signed-off-by: Timur Tabi <timur@freescale.com>
> ---
>=20
> Changes for other Freescale boards will be made in future patches.
>=20
> .../devicetree/bindings/powerpc/fsl/board.txt | 30 =
++++++++++++--------
> arch/powerpc/boot/dts/p1010rdb.dts | 10 ++----
> arch/powerpc/boot/dts/p1020rdb.dts | 7 ++++-
> arch/powerpc/boot/dts/p1022ds.dts | 2 +-
> arch/powerpc/boot/dts/p2020ds.dts | 5 +++
> arch/powerpc/boot/dts/p2020rdb.dts | 4 ++
> arch/powerpc/boot/dts/p2040rdb.dts | 8 ++++-
> arch/powerpc/boot/dts/p3041ds.dts | 4 +-
> arch/powerpc/boot/dts/p4080ds.dts | 8 ++++-
> arch/powerpc/boot/dts/p5020ds.dts | 4 +-
> 10 files changed, 55 insertions(+), 27 deletions(-)
Do we really want the generic "fsl,fpga-cpld" & "fsl,fpga-pixis"? This =
seems to vague. Also you need "pixis" on MPC8544DS, MPC8572DS, =
MPC8536DS.
Also fpga-cpld makes no sense if we keep this. You are either a CPLD or =
FPGA not both.
- k=
^ permalink raw reply
* Re: [PATCH] powerpc/85xx: clean up FPGA device tree nodes for Freecsale QorIQ boards
From: Tabi Timur-B04825 @ 2011-08-31 2:51 UTC (permalink / raw)
To: Gala Kumar-B11780
Cc: linuxppc-dev@ozlabs.org, devicetree-discuss@lists.ozlabs.org
In-Reply-To: <3F34FBCD-3F0B-4D59-A947-C16CC812B42E@freescale.com>
Kumar Gala wrote:
> Do we really want the generic "fsl,fpga-cpld"& "fsl,fpga-pixis"? This s=
eems to vague.
Yes, the PIXIS is generally register compatible across all boards. There=20
may be some minor differences, but the OCM driver can work with all PIXIS=20
boards that have an PIXIS.
> Also you need "pixis" on MPC8544DS, MPC8572DS, MPC8536DS.
Ok.
> Also fpga-cpld makes no sense if we keep this. You are either a CPLD or =
FPGA not both.
Then I don't understand what the CPLD is.
--=20
Timur Tabi
Linux kernel developer at Freescale=
^ permalink raw reply
* Re: [PATCH] powerpc/85xx: clean up FPGA device tree nodes for Freecsale QorIQ boards
From: Kumar Gala @ 2011-08-31 2:54 UTC (permalink / raw)
To: Tabi Timur-B04825
Cc: linuxppc-dev@ozlabs.org, Gala Kumar-B11780,
devicetree-discuss@lists.ozlabs.org
In-Reply-To: <4E5DA1CC.1020808@freescale.com>
On Aug 30, 2011, at 9:51 PM, Tabi Timur-B04825 wrote:
> Kumar Gala wrote:
>> Do we really want the generic "fsl,fpga-cpld"& "fsl,fpga-pixis"? =
This seems to vague.
>=20
> Yes, the PIXIS is generally register compatible across all boards. =
There=20
> may be some minor differences, but the OCM driver can work with all =
PIXIS=20
> boards that have an PIXIS.
Is this true? Don't we have pixis and ngpixis in u-boot?
>> Also you need "pixis" on MPC8544DS, MPC8572DS, MPC8536DS.
>=20
> Ok.
>=20
>> Also fpga-cpld makes no sense if we keep this. You are either a CPLD =
or FPGA not both.
>=20
> Then I don't understand what the CPLD is.
http://en.wikipedia.org/wiki/Complex_programmable_logic_device
- k=
^ permalink raw reply
* Re: [PATCH] powerpc/85xx: clean up FPGA device tree nodes for Freecsale QorIQ boards
From: Tabi Timur-B04825 @ 2011-08-31 3:01 UTC (permalink / raw)
To: Gala Kumar-B11780
Cc: linuxppc-dev@ozlabs.org, Gala Kumar-B11780,
devicetree-discuss@lists.ozlabs.org
In-Reply-To: <DBF3606B-8F59-4E5F-9B47-C3E0235665C4@freescale.com>
Kumar Gala wrote:
>
> On Aug 30, 2011, at 9:51 PM, Tabi Timur-B04825 wrote:
>
>> Kumar Gala wrote:
>>> Do we really want the generic "fsl,fpga-cpld"& "fsl,fpga-pixis"? Thi=
s seems to vague.
>>
>> Yes, the PIXIS is generally register compatible across all boards. Ther=
e
>> may be some minor differences, but the OCM driver can work with all PIXI=
S
>> boards that have an PIXIS.
>
> Is this true? Don't we have pixis and ngpixis in u-boot?
I forgot about that. Well, everything I said is true about the ngpixis,=20
so I guess I should use "ngpixis" instead of just "pixis" here. I'll have=
=20
to check if the old pixis can be used this way.
>
>>> Also you need "pixis" on MPC8544DS, MPC8572DS, MPC8536DS.
>>
>> Ok.
>>
>>> Also fpga-cpld makes no sense if we keep this. You are either a CPLD o=
r FPGA not both.
>>
>> Then I don't understand what the CPLD is.
>
> http://en.wikipedia.org/wiki/Complex_programmable_logic_device
Ok, I get it now. Is there a name for the CPLD we use on these chips?=20
I'm having a hard time getting proper documentation on the CPLD. York=20
expressed similar frustration.
Perhaps these should be called board-control devices. How about
fsl,boardcontrol-cpld
fsl,boardcontrol-ngpixis
fsl,boardcontrol-qixis
--=20
Timur Tabi
Linux kernel developer at Freescale=
^ permalink raw reply
* Re: [PATCH] powerpc/85xx: clean up FPGA device tree nodes for Freecsale QorIQ boards
From: Kumar Gala @ 2011-08-31 3:05 UTC (permalink / raw)
To: Tabi Timur-B04825
Cc: linuxppc-dev@ozlabs.org, Gala Kumar-B11780,
devicetree-discuss@lists.ozlabs.org
In-Reply-To: <4E5DA412.5020300@freescale.com>
On Aug 30, 2011, at 10:01 PM, Tabi Timur-B04825 wrote:
> Kumar Gala wrote:
>>=20
>> On Aug 30, 2011, at 9:51 PM, Tabi Timur-B04825 wrote:
>>=20
>>> Kumar Gala wrote:
>>>> Do we really want the generic "fsl,fpga-cpld"& "fsl,fpga-pixis"? =
This seems to vague.
>>>=20
>>> Yes, the PIXIS is generally register compatible across all boards. =
There
>>> may be some minor differences, but the OCM driver can work with all =
PIXIS
>>> boards that have an PIXIS.
>>=20
>> Is this true? Don't we have pixis and ngpixis in u-boot?
>=20
> I forgot about that. Well, everything I said is true about the =
ngpixis,=20
> so I guess I should use "ngpixis" instead of just "pixis" here. I'll =
have=20
> to check if the old pixis can be used this way.
>=20
>>=20
>>>> Also you need "pixis" on MPC8544DS, MPC8572DS, MPC8536DS.
>>>=20
>>> Ok.
>>>=20
>>>> Also fpga-cpld makes no sense if we keep this. You are either a =
CPLD or FPGA not both.
>>>=20
>>> Then I don't understand what the CPLD is.
>>=20
>> http://en.wikipedia.org/wiki/Complex_programmable_logic_device
>=20
> Ok, I get it now. Is there a name for the CPLD we use on these chips?=20=
> I'm having a hard time getting proper documentation on the CPLD. York=20=
> expressed similar frustration.
>=20
> Perhaps these should be called board-control devices. How about
>=20
> fsl,boardcontrol-cpld
> fsl,boardcontrol-ngpixis
> fsl,boardcontrol-qixis
For the CPLD based boards I think:
<BOARDNAME>-cpld is best as there isn't really much consistent right =
now.
- k=
^ permalink raw reply
* [git pull] Please pull powerpc.git merge branch
From: Kumar Gala @ 2011-08-31 3:14 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
Ben,
A few minor defconfig updates and a dts fix to send up to Linus for 3.1
- k
The following changes since commit c6a389f123b9f68d605bb7e0f9b32ec1e3e14132:
Linux 3.1-rc4 (2011-08-28 21:16:01 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git merge
Chunhe Lan (1):
powerpc/p1023rds: Fix the error of bank-width of nor flash
Kim Phillips (1):
powerpc/85xx: enable caam crypto driver by default
Timur Tabi (1):
powerpc/85xx: enable the audio drivers in the defconfigs
arch/powerpc/boot/dts/p1023rds.dts | 2 +-
arch/powerpc/configs/85xx/p1023rds_defconfig | 1 +
arch/powerpc/configs/corenet32_smp_defconfig | 1 +
arch/powerpc/configs/corenet64_smp_defconfig | 5 ++++-
arch/powerpc/configs/mpc85xx_defconfig | 1 +
arch/powerpc/configs/mpc85xx_smp_defconfig | 1 +
6 files changed, 9 insertions(+), 2 deletions(-)
^ permalink raw reply
* Re: [PATCH v2] powerpc/85xx: enable caam crypto driver by default
From: Kumar Gala @ 2011-08-31 3:18 UTC (permalink / raw)
To: Kim Phillips; +Cc: linuxppc-dev
In-Reply-To: <20110722154808.a9cabea2.kim.phillips@freescale.com>
On Jul 22, 2011, at 3:48 PM, Kim Phillips wrote:
> corenet based SoCs have SEC4 h/w, so enable the SEC4 driver,
> caam, and the algorithms it supports, and disable the
> SEC2/3 driver, talitos.
>
> Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
> ---
> v2: rebase from old e55xx_smp_defconfig file to new corenet & p1023
> defconfigs
>
> arch/powerpc/configs/85xx/p1023rds_defconfig | 1 +
> arch/powerpc/configs/corenet32_smp_defconfig | 1 +
> arch/powerpc/configs/corenet64_smp_defconfig | 5 ++++-
> 3 files changed, 6 insertions(+), 1 deletions(-)
applied to merge
- k
^ permalink raw reply
* Re: [PATCH] [v2] powerpc/85xx: enable the audio drivers in the defconfigs
From: Kumar Gala @ 2011-08-31 3:19 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <1313534679-7523-1-git-send-email-timur@freescale.com>
On Aug 16, 2011, at 5:44 PM, Timur Tabi wrote:
> Enable the audio drivers in the non-corenet 85xx defconfigs so that audio
> is enabled on the Freescale P1022DS reference board.
>
> Signed-off-by: Timur Tabi <timur@freescale.com>
> ---
> arch/powerpc/configs/mpc85xx_defconfig | 1 +
> arch/powerpc/configs/mpc85xx_smp_defconfig | 1 +
> 2 files changed, 2 insertions(+), 0 deletions(-)
applied to merge
- k
^ permalink raw reply
* Re: [PATCH] powerpc/p1023rds: Fix the error of bank-width of nor flash
From: Kumar Gala @ 2011-08-31 3:18 UTC (permalink / raw)
To: Chunhe Lan; +Cc: linuxppc-dev
In-Reply-To: <1313146809-13686-1-git-send-email-Chunhe.Lan@freescale.com>
On Aug 12, 2011, at 6:00 AM, Chunhe Lan wrote:
> In the p1023rds, a physical bus of nor flash is 16 bits width.
> The bank-width is width (in bytes) of the bus width. So, the
> value of bank-width of nor flash is not one, and it should be
> two.
>
> Signed-off-by: Chunhe Lan <Chunhe.Lan@freescale.com>
> ---
> arch/powerpc/boot/dts/p1023rds.dts | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
applied to merge
- k
^ permalink raw reply
* Re: [RFC PATCH 02/10] fadump: Reserve the memory for firmware assisted dump.
From: Anton Blanchard @ 2011-08-31 4:11 UTC (permalink / raw)
To: Mahesh J Salgaonkar
Cc: Linux Kernel, Milton Miller, Michael Ellerman, Eric W. Biederman,
linuxppc-dev
In-Reply-To: <20110713180648.6210.39530.stgit@mars.in.ibm.com>
Hi Mahesh,
Just a few comments.
> +#define RMR_START 0x0
> +#define RMR_END (0x1UL << 28) /* 256 MB */
What if the RMO is bigger than 256MB? Should we be using ppc64_rma_size?
> +#ifdef DEBUG
> +#define PREFIX "fadump: "
> +#define DBG(fmt...) printk(KERN_ERR PREFIX fmt)
> +#else
> +#define DBG(fmt...)
> +#endif
We should use the standard debug macros (pr_debug etc).
> +/* Global variable to hold firmware assisted dump configuration info. */
> +static struct fw_dump fw_dump;
You can remove this comment, especially because the variable isn't global :)
> + sections = of_get_flat_dt_prop(node, "ibm,configure-kernel-dump-sizes",
> + NULL);
> +
> + if (!sections)
> + return 0;
> +
> + for (i = 0; i < FW_DUMP_NUM_SECTIONS; i++) {
> + switch (sections[i].dump_section) {
> + case FADUMP_CPU_STATE_DATA:
> + fw_dump.cpu_state_data_size =
> sections[i].section_size;
> + break;
> + case FADUMP_HPTE_REGION:
> + fw_dump.hpte_region_size =
> sections[i].section_size;
> + break;
> + }
> + }
> + return 1;
> +}
This makes me a bit nervous. We should really get the size of the property
and use it to iterate through the array. I saw no requirement in the PAPR
that the array had to be 2 entries long.
> +static inline unsigned long calculate_reserve_size(void)
> +{
> + unsigned long size;
> +
> + /* divide by 20 to get 5% of value */
> + size = memblock_end_of_DRAM();
> + do_div(size, 20);
> +
> + /* round it down in multiples of 256 */
> + size = size & ~0x0FFFFFFFUL;
> +
> + /* Truncate to memory_limit. We don't want to over reserve
> the memory.*/
> + if (memory_limit && size > memory_limit)
> + size = memory_limit;
> +
> + return (size > RMR_END ? size : RMR_END);
> +}
5% is pretty aribitrary, that's 400GB on an 8TB box. Also our experience
with kdump is that 256MB is too small. Is there any reason to scale it
with memory size? Can we do what kdump does and set it to a single
value (eg 512MB)?
We could override the default with a boot option, which is similar to
how kdump specifies the region to reserve.
Anton
^ permalink raw reply
* Re: [RFC PATCH 03/10] fadump: Register for firmware assisted dump.
From: Anton Blanchard @ 2011-08-31 4:20 UTC (permalink / raw)
To: Mahesh J Salgaonkar
Cc: Linux Kernel, Milton Miller, Michael Ellerman, Eric W. Biederman,
linuxppc-dev
In-Reply-To: <20110713180705.6210.44160.stgit@mars.in.ibm.com>
Hi,
> +static void fadump_show_config(void)
> +{
> + DBG("Support for firmware-assisted dump (fadump): %s\n",
> + (fw_dump.fadump_supported ? "present" : "no support"));
> +
> + if (!fw_dump.fadump_supported)
> + return;
> +
> + DBG("Fadump enabled : %s\n",
> + (fw_dump.fadump_enabled ? "yes" : "no"));
> + DBG("Dump Active : %s\n", (fw_dump.dump_active ? "yes" : "no"));
> + DBG("Dump section sizes:\n");
> + DBG(" CPU state data size: %lx\n", fw_dump.cpu_state_data_size);
> + DBG(" HPTE region size : %lx\n", fw_dump.hpte_region_size);
> + DBG("Boot memory size : %lx\n", fw_dump.boot_memory_size);
> + DBG("Reserve area start: %lx\n", fw_dump.reserve_dump_area_start);
> + DBG("Reserve area size : %lx\n", fw_dump.reserve_dump_area_size);
> +}
> +
> +static void show_fadump_mem_struct(const struct fadump_mem_struct *fdm)
> +{
> + if (!fdm)
> + return;
> +
> + DBG("--------Firmware-assisted dump memory structure---------\n");
> + DBG("header.dump_format_version : 0x%08x\n",
> + fdm->header.dump_format_version);
> + DBG("header.dump_num_sections : %d\n",
> + fdm->header.dump_num_sections);
> + DBG("header.dump_status_flag : 0x%04x\n",
> + fdm->header.dump_status_flag);
> + DBG("header.offset_first_dump_section : 0x%x\n",
> + fdm->header.offset_first_dump_section);
> +
> + DBG("header.dd_block_size : %d\n",
> + fdm->header.dd_block_size);
> + DBG("header.dd_block_offset : 0x%Lx\n",
> + fdm->header.dd_block_offset);
> + DBG("header.dd_num_blocks : %Lx\n",
> + fdm->header.dd_num_blocks);
> + DBG("header.dd_offset_disk_path : 0x%x\n",
> + fdm->header.dd_offset_disk_path);
> +
> + DBG("header.max_time_auto : %d\n",
> + fdm->header.max_time_auto);
> +
> + /* Kernel dump sections */
> + DBG("cpu_state_data.request_flag : 0x%08x\n",
> + fdm->cpu_state_data.request_flag);
> + DBG("cpu_state_data.source_data_type : 0x%04x\n",
> + fdm->cpu_state_data.source_data_type);
> + DBG("cpu_state_data.error_flags : 0x%04x\n",
> + fdm->cpu_state_data.error_flags);
> + DBG("cpu_state_data.source_address : 0x%016Lx\n",
> + fdm->cpu_state_data.source_address);
> + DBG("cpu_state_data.source_len : 0x%Lx\n",
> + fdm->cpu_state_data.source_len);
> + DBG("cpu_state_data.bytes_dumped : 0x%Lx\n",
> + fdm->cpu_state_data.bytes_dumped);
> + DBG("cpu_state_data.destination_address: 0x%016Lx\n",
> + fdm->cpu_state_data.destination_address);
> +
> + DBG("hpte_region.request_flag : 0x%08x\n",
> + fdm->hpte_region.request_flag);
> + DBG("hpte_region.source_data_type : 0x%04x\n",
> + fdm->hpte_region.source_data_type);
> + DBG("hpte_region.error_flags : 0x%04x\n",
> + fdm->hpte_region.error_flags);
> + DBG("hpte_region.source_address : 0x%016Lx\n",
> + fdm->hpte_region.source_address);
> + DBG("hpte_region.source_len : 0x%Lx\n",
> + fdm->hpte_region.source_len);
> + DBG("hpte_region.bytes_dumped : 0x%Lx\n",
> + fdm->hpte_region.bytes_dumped);
> + DBG("hpte_region.destination_address : 0x%016Lx\n",
> + fdm->hpte_region.destination_address);
> +
> + DBG("rmr_region.request_flag : 0x%08x\n",
> + fdm->rmr_region.request_flag);
> + DBG("rmr_region.source_data_type : 0x%04x\n",
> + fdm->rmr_region.source_data_type);
> + DBG("rmr_region.error_flags : 0x%04x\n",
> + fdm->rmr_region.error_flags);
> + DBG("rmr_region.source_address : 0x%016Lx\n",
> + fdm->rmr_region.source_address);
> + DBG("rmr_region.source_len : 0x%Lx\n",
> + fdm->rmr_region.source_len);
> + DBG("rmr_region.bytes_dumped : 0x%Lx\n",
> + fdm->rmr_region.bytes_dumped);
> + DBG("rmr_region.destination_address : 0x%016Lx\n",
> + fdm->rmr_region.destination_address);
> +
> + DBG("--------Firmware-assisted dump memory structure---------\n");
> +}
> +
That's an awful lot of debug information. I don't think we need to carry
this around in the kernel once the feature is working.
> +static ssize_t fadump_enabled_show(struct kobject *kobj,
> + struct kobj_attribute *attr,
> + char *buf)
> +{
> + return sprintf(buf, "%d\n", fw_dump.fadump_enabled);
> +}
> +
> +static ssize_t fadump_region_show(struct kobject *kobj,
> + struct kobj_attribute *attr,
> + char *buf)
> +{
> + const struct fadump_mem_struct *fdm_ptr;
> + ssize_t n = 0;
> +
> + if (!fw_dump.fadump_enabled)
> + return n;
> +
> + if (fdm_active)
> + fdm_ptr = fdm_active;
> + else
> + fdm_ptr = &fdm;
> +
> + n += sprintf(buf,
> + "CPU : [%#016llx-%#016llx] %#llx bytes, "
> + "Dumped: %#llx\n",
> + fdm_ptr->cpu_state_data.destination_address,
> + fdm_ptr->cpu_state_data.destination_address +
> + fdm_ptr->cpu_state_data.source_len - 1,
> + fdm_ptr->cpu_state_data.source_len,
> + fdm_ptr->cpu_state_data.bytes_dumped);
> + n += sprintf(buf + n,
> + "HPTE: [%#016llx-%#016llx] %#llx bytes, "
> + "Dumped: %#llx\n",
> + fdm_ptr->hpte_region.destination_address,
> + fdm_ptr->hpte_region.destination_address +
> + fdm_ptr->hpte_region.source_len - 1,
> + fdm_ptr->hpte_region.source_len,
> + fdm_ptr->hpte_region.bytes_dumped);
> + n += sprintf(buf + n,
> + "DUMP: [%#016llx-%#016llx] %#llx bytes, "
> + "Dumped: %#llx\n",
> + fdm_ptr->rmr_region.destination_address,
> + fdm_ptr->rmr_region.destination_address +
> + fdm_ptr->rmr_region.source_len - 1,
> + fdm_ptr->rmr_region.source_len,
> + fdm_ptr->rmr_region.bytes_dumped);
> +
> + if (!fdm_active ||
> + (fw_dump.reserve_dump_area_start ==
> + fdm_ptr->cpu_state_data.destination_address))
> + return n;
> +
> + /* Dump is active. Show reserved memory region. */
> + n += sprintf(buf + n,
> + " : [%#016llx-%#016llx] %#llx bytes, "
> + "Dumped: %#llx\n",
> + (unsigned long long)fw_dump.reserve_dump_area_start,
> + fdm_ptr->cpu_state_data.destination_address - 1,
> + fdm_ptr->cpu_state_data.destination_address -
> + fw_dump.reserve_dump_area_start,
> + fdm_ptr->cpu_state_data.destination_address -
> + fw_dump.reserve_dump_area_start);
> + return n;
> +}
> +
> +static struct kobj_attribute fadump_attr = __ATTR(fadump_enabled,
> + 0444, fadump_enabled_show,
> + NULL);
> +static struct kobj_attribute fadump_region_attr = __ATTR(fadump_region,
> + 0444, fadump_region_show, NULL);
> +
> +static int fadump_init_sysfs(void)
> +{
> + int rc = 0;
> +
> + rc = sysfs_create_file(kernel_kobj, &fadump_attr.attr);
> + if (rc)
> + printk(KERN_ERR "fadump: unable to create sysfs file"
> + " (%d)\n", rc);
> +
> + rc = sysfs_create_file(kernel_kobj, &fadump_region_attr.attr);
> + if (rc)
> + printk(KERN_ERR "fadump: unable to create sysfs file"
> + " (%d)\n", rc);
> + return rc;
> +}
> +subsys_initcall(fadump_init_sysfs);
Do we need to dump this all out via sysfs? Will tools depend on this,
or is it just for debug? It might be better to place in debugfs.
Anton
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox