From: Joel Granados
This commit comes at the tail end of a greater effort to remove the
empty elements at the end of the ctl_table arrays (sentinels) which
will reduce the overall build time size of the kernel and run time
memory bloat by ~64 bytes per sentinel (further information Link :
https:/
From: Joel Granados
This commit comes at the tail end of a greater effort to remove the
empty elements at the end of the ctl_table arrays (sentinels) which
will reduce the overall build time size of the kernel and run time
memory bloat by ~64 bytes per sentinel (further information Link :
https:/
On 4/28/20 10:35 AM, Thomas Falcon wrote:
> On 4/27/20 12:33 PM, Juliet Kim wrote:
>> The maximum entries for H_SEND_SUB_CRQ_INDIRECT has increased on
>> some platforms from 16 to 128. If Live Partition Mobility is used
>> to migrate a running OS image from a newer source platform to an
>> older
On 4/27/20 12:33 PM, Juliet Kim wrote:
The maximum entries for H_SEND_SUB_CRQ_INDIRECT has increased on
some platforms from 16 to 128. If Live Partition Mobility is used
to migrate a running OS image from a newer source platform to an
older target platform, then H_SEND_SUB_CRQ_INDIRECT will fail
The maximum entries for H_SEND_SUB_CRQ_INDIRECT has increased on
some platforms from 16 to 128. If Live Partition Mobility is used
to migrate a running OS image from a newer source platform to an
older target platform, then H_SEND_SUB_CRQ_INDIRECT will fail with
H_PARAMETER if 128 entries are queue
From: Leon Romanovsky
Date: Sun, 1 Mar 2020 16:44:33 +0200
> From: Leon Romanovsky
>
> Hi,
>
> This is second batch of the series which removes various static versions
> in favour of globaly defined Linux kernel version.
>
> The first part with better cover letter can be found here
> https:/
> -Original Message-
> From: David Miller
> Sent: Monday, March 2, 2020 5:02 AM
> To: l...@kernel.org
> Subject: Re: [PATCH net-next 00/23] Clean driver, module and FW versions
>
> From: Leon Romanovsky
> Date: Sun, 1 Mar 2020 16:44:33 +0200
>
> > T
From: Leon Romanovsky
Date: Sun, 1 Mar 2020 16:44:33 +0200
> This is second batch of the series which removes various static versions
> in favour of globaly defined Linux kernel version.
This generally looks fine to me but I'll let it sit for a few days so that
others can review.
From: Leon Romanovsky
Rely on ethtool to properly present the fact that FW is not
available for the ucc_geth driver.
Signed-off-by: Leon Romanovsky
---
drivers/net/ethernet/freescale/ucc_geth_ethtool.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/ethernet/freescale
based on
68e2c37690b0 ("Merge branch 'hsr-several-code-cleanup-for-hsr-module'")
and WIP branch is
https://git.kernel.org/pub/scm/linux/kernel/git/leon/linux-rdma.git/log/?h=ethtool
Thanks
Leon Romanovsky (23):
net/broadcom: Clean broadcom code from driver versions
net/broadc
Allow switching from the pnv_php module to the standard pciehp driver for
PowerNV, if the platform supports it: it can be a server working on top of
the skiboot with the [1] patchset applied.
Add the ability to discover hot-added devices which weren't added to the
Device Tree (by the pnv_php via a
On Thu, Mar 28, 2019 at 1:10 AM Bjorn Helgaas wrote:
>
> Hi Sergey,
>
> Since this doesn't touch drivers/pci, I assume powerpc folks will
> handle this series. Let me know if otherwise.
I've been looking at it and reviewed the last spin. I'll have another
look next week.
> On Mon, Mar 11, 2019
Hi Sergey,
Since this doesn't touch drivers/pci, I assume powerpc folks will
handle this series. Let me know if otherwise.
On Mon, Mar 11, 2019 at 02:52:25PM +0300, Sergey Miroshnichenko wrote:
> This patchset allows switching from the pnv_php module to the standard
> pciehp driver for PCIe hotp
This patchset allows switching from the pnv_php module to the standard
pciehp driver for PCIe hotplug functionality, if the platform supports it:
PowerNV working on on top of the skiboot with the "core/pci: Sync VFs and
the changes of bdfns between the firmware and the OS" [1] patch serie
applied.
On Sat, Mar 2, 2019 at 3:04 AM Sergey Miroshnichenko
wrote:
>
> This patchset allows switching from the pnv_php module to the standard
> pciehp driver for PCIe hotplug functionality, if the platform supports it:
> PowerNV working on on top of the skiboot with the "core/pci: Sync VFs and
> the chan
This patchset allows switching from the pnv_php module to the standard
pciehp driver for PCIe hotplug functionality, if the platform supports it:
PowerNV working on on top of the skiboot with the "core/pci: Sync VFs and
the changes of bdfns between the firmware and the OS" patch serie applied.
The
: Fix AST2400 POST failure without BMC FW or VBIOS
From: "Y.C. Chen"
The current POST code for the AST2300/2400 family doesn't work properly if the
chip hasn't been initialized previously by either the BMC own FW or the VBIOS.
This fixes it.
Signed-off-by: Y.C. Chen
Sig
On Fri, Feb 24, 2017 at 9:23 AM, Benjamin Herrenschmidt
wrote:
> From: "Y.C. Chen"
>
> The current POST code for the AST2300/2400 family doesn't work properly
> if the chip hasn't been initialized previously by either the BMC own FW
> or the VBIOS. This fix
Note: The whole series with the fixed cset comment for patch 11
can be also found there:
https://github.com/ozbenh/linux-ast/commits/master
Cheers,
Ben.
From: "Y.C. Chen"
The current POST code for the AST2300/2400 family doesn't work properly
if the chip hasn't been initialized previously by either the BMC own FW
or the VBIOS. This fixes it.
Signed-off-by: Y.C. Chen
Signed-off-by: Benjamin Herrenschmidt
---
drivers/gp
Thou shalt not make firmware calls early on init or probe.
systemd already ripped support out for the usermode helper
a while ago, there are still users that require the usermode helper,
however systemd's use of the usermode helper exacerbated a long
lasting issue of the fact that we have many dri
On Thu, Aug 25, 2016 at 09:41:33PM +0200, Luis R. Rodriguez wrote:
> On Thu, Aug 25, 2016 at 01:05:44PM +0200, Daniel Vetter wrote:
> > On Wed, Aug 24, 2016 at 10:39 PM, Luis R. Rodriguez
> > wrote:
> > Some users want a fully running gfx stack 2s after power-on. There's
> > not even enough time
On Wed, Aug 24, 2016 at 10:17:38AM +0200, Gabriel Paubert wrote:
> On Tue, Aug 23, 2016 at 05:45:04PM -0700, mcg...@kernel.org wrote:
>
> [snip]
> > ---
> > Documentation/firmware_class/README| 20
> > drivers/base/Kconfig | 2 +-
> > .../requ
On Thu, Aug 25, 2016 at 12:41 PM, Luis R. Rodriguez wrote:
> On Thu, Aug 25, 2016 at 01:05:44PM +0200, Daniel Vetter wrote:
>> On Wed, Aug 24, 2016 at 10:39 PM, Luis R. Rodriguez
>> wrote:
>> > Can they use initramfs for this ?
>>
>> Apparently that's also uncool with the embedded folks.
>
> Wh
On Thu, Aug 25, 2016 at 10:10:52PM +0200, Daniel Vetter wrote:
> Cutting down since a lot of this is probably better discussed at
> ks/lpc. Aside, if you want to check out Chris Wilson's work on our new
> depency handling, it's called kfence.
>
> https://lkml.org/lkml/2016/7/17/37
Thanks more rea
Cutting down since a lot of this is probably better discussed at
ks/lpc. Aside, if you want to check out Chris Wilson's work on our new
depency handling, it's called kfence.
https://lkml.org/lkml/2016/7/17/37
On Thu, Aug 25, 2016 at 9:41 PM, Luis R. Rodriguez wrote:
>> > So .. I agree, let's avo
Summoning Felix for the embedded aspect on initramfs below.
Jörg might be interested in the async facilities you speak of as well.
On Thu, Aug 25, 2016 at 01:05:44PM +0200, Daniel Vetter wrote:
> On Wed, Aug 24, 2016 at 10:39 PM, Luis R. Rodriguez wrote:
> > On Wed, Aug 24, 2016 at 08:55:55AM +02
On Wed, Aug 24, 2016 at 10:39 PM, Luis R. Rodriguez wrote:
> On Wed, Aug 24, 2016 at 08:55:55AM +0200, Daniel Vetter wrote:
>> On Fri, Jun 17, 2016 at 12:54 AM, Luis R. Rodriguez
>> wrote:
>> > Thou shalt not make firmware calls early on init or probe.
>
> <-- snip -->
>
>> > There are 4 offende
On Wed, Aug 24, 2016 at 08:55:55AM +0200, Daniel Vetter wrote:
> On Fri, Jun 17, 2016 at 12:54 AM, Luis R. Rodriguez wrote:
> > Thou shalt not make firmware calls early on init or probe.
<-- snip -->
> > There are 4 offenders at this time:
> >
> > mcgrof@ergon ~/linux-next (git::20160609)$ expor
On Tue, Aug 23, 2016 at 05:45:04PM -0700, mcg...@kernel.org wrote:
[snip]
> ---
> Documentation/firmware_class/README| 20
> drivers/base/Kconfig | 2 +-
> .../request_firmware-avoid-init-probe-init.cocci | 130
> +
> 3
On Fri, Jun 17, 2016 at 12:54 AM, Luis R. Rodriguez wrote:
> Thou shalt not make firmware calls early on init or probe.
>
> systemd already ripped support out for the usermode helper
> a while ago, there are still users that require the usermode helper,
> however systemd's use of the usermode help
From: "Luis R. Rodriguez"
Thou shalt not make firmware calls early on init or probe.
systemd already ripped support out for the usermode helper
a while ago, there are still users that require the usermode helper,
however systemd's use of the usermode helper exacerbated a long
lasting issue of th
On Tue, 2016-05-07 at 05:03:48 UTC, Benjamin Herrenschmidt wrote:
> We move the function itself to pseries/firmware.c and call it along
> with almost all other flat device-tree parsers from early_init_devtree()
>
> Signed-off-by: Benjamin Herrenschmidt
Applied to powerpc next, thanks.
https://g
We move the function itself to pseries/firmware.c and call it along
with almost all other flat device-tree parsers from early_init_devtree()
Signed-off-by: Benjamin Herrenschmidt
---
arch/powerpc/include/asm/firmware.h | 4 +++
arch/powerpc/kernel/prom.c| 6 +
arch/po
We move the function itself to pseries/firmware.c and call it along
with almost all other flat device-tree parsers from early_init_devtree()
Signed-off-by: Benjamin Herrenschmidt
---
arch/powerpc/include/asm/firmware.h | 4 +++
arch/powerpc/kernel/prom.c| 6 +
arch/po
Thou shalt not make firmware calls early on init or probe.
systemd already ripped support out for the usermode helper
a while ago, there are still users that require the usermode helper,
however systemd's use of the usermode helper exacerbated a long
lasting issue of the fact that we have many dri
just need to share to developer the success we face today
the Tursk is running in full 2D and 3D on Linux PPC (lubuntu 14.04.2 kernel
4.0.0-rc3) on Quad G5
Need to say a big thankyou to Christian (Xeno74) Zigotzky
I share a video for the community
https://www.youtube.com/watch?v=MYgFfRLYhLU
"Helps debug funky firmware issues".
After:
Starting Linux PPC64 #108 SMP Wed Aug 6 19:04:51 EST 2014
-
ppc64_pft_size= 0x1a
phys_mem_size = 0x2
cpu_features = 0x17fc7a6c18500249
possible= 0x1fff1870
Helps debug funky firmware issues
Signed-off-by: Benjamin Herrenschmidt
---
arch/powerpc/kernel/setup_64.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index 93991ed..a06edf6 100644
--- a/arch/powerpc/kernel/setup_64.c
+
On 04/09/2014 10:48 PM, Vasant Hegde wrote:
Firmware update on PowerNV platform takes several minutes. During
this time one CPU is stuck in FW and the kernel complains about "soft
lockups".
Ben,
Sorry for the confusion in subject line.. Its just 1 patch.. not 1/60 .
-Vasant
Firmware update on PowerNV platform takes several minutes. During
this time one CPU is stuck in FW and the kernel complains about "soft
lockups".
This patch returns all secondary CPUs to firmware before starting
firmware update process.
[ Reworked a bit and cleaned up -- BenH ]
Sig
At present we assume candidate image is <= 256MB. But in P8,
candidate image size can go up to 750MB. Hence increasing
candidate image max size to 1GB.
Signed-off-by: Vasant Hegde
---
arch/powerpc/platforms/powernv/opal-flash.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff -
Hi
Could you help to confirm:
Kexec-tools 2.0.4 + Linux 2.6.33 on MPC8541(PPC32) can work or not?
If not, how to make it? Thanks a lot.
-Original Message-
From: ext Simon Horman [mailto:ho...@verge.net.au]
Sent: Friday, June 28, 2013 4:17 PM
To: Xia, Zhao (NSN - CN/Shanghai)
Subject: Re
http://www.hazelnuts.it/1cr5if.php
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Add new return code to rtas_flash to indicate firmware entitlement
expiry. Strictly we don't need this update. But to keep it in sync
with PAPR, this was added.
Signed-off-by: Ananth N Mavinakayanahalli
Signed-off-by: Vasant Hegde
---
arch/powerpc/kernel/rtas_flash.c |5 +
1 file change
On Tue, Apr 23, 2013 at 03:32:30PM +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2013-04-23 at 10:35 +0530, Ananth N Mavinakayanahalli wrote:
> > On Tue, Apr 23, 2013 at 10:40:10AM +1000, Benjamin Herrenschmidt wrote:
> > > On Fri, 2013-04-19 at 17:14 +0530, Vasant Hegde wrote:
> > > > Add new ret
On Tue, 2013-04-23 at 10:35 +0530, Ananth N Mavinakayanahalli wrote:
> On Tue, Apr 23, 2013 at 10:40:10AM +1000, Benjamin Herrenschmidt wrote:
> > On Fri, 2013-04-19 at 17:14 +0530, Vasant Hegde wrote:
> > > Add new return code to rtas_flash to indicate firmware entitlement
> > > expiry. This will
On 04/23/2013 06:10 AM, Benjamin Herrenschmidt wrote:
On Fri, 2013-04-19 at 17:14 +0530, Vasant Hegde wrote:
Add new return code to rtas_flash to indicate firmware entitlement
expiry. This will be used by the update_flash script to return
appropriate message to the user.
What's the point of th
On Tue, Apr 23, 2013 at 10:40:10AM +1000, Benjamin Herrenschmidt wrote:
> On Fri, 2013-04-19 at 17:14 +0530, Vasant Hegde wrote:
> > Add new return code to rtas_flash to indicate firmware entitlement
> > expiry. This will be used by the update_flash script to return
> > appropriate message to the u
On Fri, 2013-04-19 at 17:14 +0530, Vasant Hegde wrote:
> Add new return code to rtas_flash to indicate firmware entitlement
> expiry. This will be used by the update_flash script to return
> appropriate message to the user.
What's the point of that patch ? It adds a definition to a private .c
file
Add new return code to rtas_flash to indicate firmware entitlement
expiry. This will be used by the update_flash script to return
appropriate message to the user.
Signed-off-by: Ananth N Mavinakayanahalli
Signed-off-by: Vasant Hegde
---
arch/powerpc/kernel/rtas_flash.c |1 +
1 file changed,
Hi Kumar,
If possible could you please review this patch set.
Regards
Varun
> -Original Message-
> From: Sethi Varun-B16395
> Sent: Sunday, June 03, 2012 1:11 PM
> To: linuxppc-dev@lists.ozlabs.org
> Cc: Sethi Varun-B16395
> Subject: [PATCH 0/3] powerpc/mpic: Enhancements for FSL MPIC.
>
Hi Robert,
On Tue, Oct 18, 2011 at 11:38 PM, Robert Sciuk wrote:
>
>
> [snip]
>
>>
>> How and what type of packets are you sending? Raw MAC frames, IP? Are
>> you using custom code, or can you try things like ping?
>> If you are using IP, I trust you checked the Linux configuration (like
>> assig
[snip]
>
> How and what type of packets are you sending? Raw MAC frames, IP? Are
> you using custom code, or can you try things like ping?
> If you are using IP, I trust you checked the Linux configuration (like
> assigning a valid IP address to the interface and making sure the
> routing table
To: Robert Sciuk
>> Cc: linuxppc-dev@lists.ozlabs.org
>> Subject: Re: FW: P4080 device tree problems with fsl dpaa ...
>>
>> Hi Robert,
>
> [my stuff snipped]
>>
>> > I have no idea what an OH binding is, what it might look like, and
>> what it en
> -Original Message-
> From: patrickdeping...@gmail.com [mailto:patrickdeping...@gmail.com] On
> Behalf Of Thomas De Schampheleire
> Sent: Monday, October 17, 2011 5:01 AM
> To: Robert Sciuk
> Cc: linuxppc-dev@lists.ozlabs.org
> Subject: Re: FW: P4080 device tree p
Hi Robert,
On Fri, Oct 14, 2011 at 11:57 PM, Robert Sciuk wrote:
>
>
> -Original Message-
> From: Robert Sciuk
> Sent: Friday, October 14, 2011 5:27 PM
> To: 'devicetree-disc...@lists.ozlabs.org'
> Subject: P4080 device tree problems with fsl dpaa ...
>
> I've just joined the list, and I
-Original Message-
From: Robert Sciuk
Sent: Friday, October 14, 2011 5:27 PM
To: 'devicetree-disc...@lists.ozlabs.org'
Subject: P4080 device tree problems with fsl dpaa ...
I've just joined the list, and I hope that this is not an inappropriate
question, but I'm looking for some direct
On 08/09/2011 12:46 AM, smitha.va...@wipro.com wrote:
> Thank Scott. I am working on a legacy project Which is using 2.6.21
> linux kernel so the device tree is based on that.
Your original e-mail said you were using 2.6.38 ("I have bringup WR
linux 2.6.38 on a custom mpc8247 board").
> Can you l
.
Thanks & Regards,
Smitha
-Original Message-
From: Scott Wood [mailto:scottw...@freescale.com]
Sent: Tuesday, August 09, 2011 2:25 AM
To: Smitha Vanga (WT01 - GMT-Telecom Equipment)
Cc: linuxppc-dev@lists.ozlabs.org
Subject: Re: FW: Ethernet driver WR linux
On 08/08/2011 12:53 AM, smith
On 08/08/2011 12:53 AM, smitha.va...@wipro.com wrote:
>
> Hi Scott,
>
> Below is the .dts file. My board is based on mpc8247. Currently using
> FCC1.
This device tree is based on something very short-lived when 82xx
support was first being worked on for 82xx, around 2.6.24 or so. Please
redo i
Hi Scott,
Below is the .dts file. My board is based on mpc8247. Currently using
FCC1.
/*
* MPC8272 EPN412 Device Tree Source
*
* Copyright 2005 Freescale Semiconductor Inc.
*
* This program is free software; you can redistribute it and/or modify
it
* under the terms of the GNU General
On 08/05/2011 12:31 AM, smitha.va...@wipro.com wrote:
> Hi
>
> I have bringup WR linux 2.6.38 on a custom mpc8247 board. Not able to
> configure the ipaddress. When I boot my linux kernel I get the below
> message.
> Also I am using the fec 1. The fec is not getting initialized.
> fs_enet.c:v1
Hi
I have bringup WR linux 2.6.38 on a custom mpc8247 board. Not able to
configure the ipaddress. When I boot my linux kernel I get the below
message.
Also I am using the fec 1. The fec is not getting initialized.
fs_enet.c:v1.0 (Aug 8, 2005)
BB MII Bus: Cannot register as MDIO bus
fsl-bb-mdio:
> memcpy_toio() works fine, the data is written correctly. After
> DMA, the correct data appears at offsets 0xC, 0x1C, 0x2C, etc.
> of the destination buffer. I have 12 bytes of junk, 4 bytes of
> correct data, then again 12 bytes of junk and so on.
Does your Avalon MM slave decode the 4 byte enab
On Mon, Nov 9, 2009 at 8:36 PM, Ravi Shekhar wrote:
>
>
> I'm attempting to get SPI to work on my embedded design
> that is based on the mpc8313erbd reference board wiht a
> 2.6.27 kernel.
Are you able to use a more recent kernel? A lot of work has gone into
SPI drivers in the last 5 releases
I'm attempting to get SPI to work on my embedded design
that is based on the mpc8313erbd reference board wiht a
2.6.27 kernel. I cannot open the SPI device.
Tracing through the kernel code, it looks like the device is
not being found in the DTB file. However there is a
SPI node in there alr
On Thu, 2009-09-24 at 17:05 -0700, Andrew Morton wrote:
>
> Begin forwarded message:
Thanks. I'll pick it up.
Cheers,
Ben.
> Date: Wed, 16 Sep 009 11:58:15 +0300
> From: Dragos Tatulea
> To: pau...@samba.org, linux-ker...@vger.kernel.org
> Cc: Octavian Purdila
> Subject: [PATCH] ppc: add ppc7
Begin forwarded message:
Date: Wed, 16 Sep 2009 11:58:15 +0300
From: Dragos Tatulea
To: pau...@samba.org, linux-ker...@vger.kernel.org
Cc: Octavian Purdila
Subject: [PATCH] ppc: add ppc750 CL as supported by oprofile
Hi,
Here's a patch that adds the ppc750 CL cpu as supported by opr
, per Jinag-An's request, what is the procedure for cleaning this
up before releasing to Linux community ?
Regards, Samuel
-Original Message-
From: support_re...@amcc.com [mailto:support_re...@amcc.com]
Sent: Fri 8/7/2009 9:24 AM
To: Samuel Wang
Subject: FW: need help getting SPI controlle
Hi,
Is there any changes on PCI Device tree binding has happened? Because i
am trying to port linux 2.6.30 to my MPC7448 based custom board. The
target is getting hanged at ethernet initialization. Also i have seen on
the debug message of kernel that the PCI MEM/IO resources are not getting
[Forgot the cc]
Begin forwarded message:
Date: Wed, 25 Mar 2009 15:08:17 +1100
From: Stephen Rothwell
To: Rusty Russell
Cc: linux-n...@vger.kernel.org
Subject: linux-next: manual merge of the rr tree with the powerpc tree
Hi Rusty,
Today's linux-next merge of the rr tree got a conflict in
ar
Anton Vorontsov wrote on 20/03/2009 21:07:40:
>
> On Fri, Mar 20, 2009 at 08:43:56PM +0100, Joakim Tjernlund wrote:
> > hmm, this mail didn't seem to reach the lists. Resending
> >
> > Jocke
> > - Forwarded by Joakim Tjernlund/Transmode on 20/03/2009 20:42
-
> >
> > From:
> > Joakim T
On Fri, Mar 20, 2009 at 08:43:56PM +0100, Joakim Tjernlund wrote:
> hmm, this mail didn't seem to reach the lists. Resending
>
> Jocke
> - Forwarded by Joakim Tjernlund/Transmode on 20/03/2009 20:42 -
>
> From:
> Joakim Tjernlund
> To:
> le...@freescale.com, net...@vger.kernel.org, linu
hmm, this mail didn't seem to reach the lists. Resending
Jocke
- Forwarded by Joakim Tjernlund/Transmode on 20/03/2009 20:42 -
From:
Joakim Tjernlund
To:
le...@freescale.com, net...@vger.kernel.org, linuxppc-dev@ozlabs.org
Cc:
Joakim Tjernlund
Date:
20/03/2009 18:01
Subject:
[PATCH] uc
> Right, but then you need to set that in the VMA's, and thus gone is your
> nice fast g_u_p() that doesn't touch VMAs :-)
Registering memory is a slow path thing in the RDMA world. Speeding it
up is nice, so we make userspace do the madvise(VM_DONTCOPY) if it cares
but if it doesn't it can lea
On Wed, 2009-02-04 at 21:10 -0800, Roland Dreier wrote:
> > Note that g_u_p() has all sort of shortcommings... we were discussing
> > some of that recently due to bugs reported from the field.
> >
> > The problem mostly is that you cannot guarantee that the physical page
> > will remain mapped
> Note that g_u_p() has all sort of shortcommings... we were discussing
> some of that recently due to bugs reported from the field.
>
> The problem mostly is that you cannot guarantee that the physical page
> will remain mapped to that virtual address in the process. For example,
> if your
> get_user_pages() also gives us the vma back, and we can see from
> is_vm_hugetlb_page() (-- BTW can I just say that a function
> is_xxx_page() that operates on vmas is horribly misnamed --) that these
> pages all come from a hugetlb mapping, but figuring out the size of that
> mapping is I guess
> You should be able to find the head of a compound page using the
> compound_head() inline, so try
> PAGE_SIZE << compound_order(compound_head(page))
Thanks! Looks like that should be exactly what we need.
- R.
___
Linuxppc-dev mailing list
On Wed, 04 Feb 2009 11:11:22 -0800
Roland Dreier wrote:
> > > > huge_page_size(page_hstate(page))
>
> > > That would suit. I assume the intention is for that to be usable by
> > > driver modules on any architecture?
>
> > erm, you overestimate the amount of planning and forethought
On Wed, Feb 04, 2009 at 11:11:22AM -0800, Roland Dreier wrote:
> Heh. Looking into the implementation, it seems that I could actually do
> PAGE_SIZE << compound_order(page)
> directly (since there's no reason to go from size to hstate and back to
> size. I don't know all the details of thes
> > > huge_page_size(page_hstate(page))
> > That would suit. I assume the intention is for that to be usable by
> > driver modules on any architecture?
> erm, you overestimate the amount of planning and forethought which goes
> into these things ;)
> The lack of any EXPORT_SYMBOL
On Wed, 04 Feb 2009 12:50:48 +1100 Benjamin Herrenschmidt
>>> Do the generic hugetlbfs code provides such an API ? If not, we may need
>>> to add one.
On Wednesday 04 February 2009 16:13:29 Andrew Morton wrote:
>> I think it's something like
>> huge_page_size(page_hstate(page))
On Wed, Feb
On Tue, 03 Feb 2009 22:16:08 -0800 Roland Dreier wrote:
> > I think it's something like
> >
> >huge_page_size(page_hstate(page))
>
> That would suit. I assume the intention is for that to be usable by
> driver modules on any architecture?
>
erm, you overestimate the amount of planning
> I think it's something like
>
> huge_page_size(page_hstate(page))
That would suit. I assume the intention is for that to be usable by
driver modules on any architecture?
- R.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozl
On Wednesday 04 February 2009 16:13:29 Andrew Morton wrote:
> On Wed, 04 Feb 2009 12:50:48 +1100 Benjamin Herrenschmidt
> > Do the generic hugetlbfs code provides such an API ? If not, we may need
> > to add one.
>
> I think it's something like
>
> huge_page_size(page_hstate(page))
That wou
On Wed, 04 Feb 2009 12:50:48 +1100 Benjamin Herrenschmidt
wrote:
> On Tue, 2009-02-03 at 17:08 -0800, Roland Dreier wrote:
> > Forwarding Eli's patch below, since PowerPC guys may have missed it. I
> > guess the question for Ben et al is whether there is any issue with
> > exporting HPAGE_SHIFT
On Tue, 2009-02-03 at 17:08 -0800, Roland Dreier wrote:
> Forwarding Eli's patch below, since PowerPC guys may have missed it. I
> guess the question for Ben et al is whether there is any issue with
> exporting HPAGE_SHIFT for modules (can be EXPORT_SYMBOL_GPL if you feel
> it's an internal detail
Forwarding Eli's patch below, since PowerPC guys may have missed it. I
guess the question for Ben et al is whether there is any issue with
exporting HPAGE_SHIFT for modules (can be EXPORT_SYMBOL_GPL if you feel
it's an internal detail). It would probably make sense to roll this
change into the ml
On Fri, 2008-08-08 at 15:05 -0700, Benjamin Herrenschmidt wrote:
> On Fri, 2008-08-08 at 11:43 -0700, Matt Carlson wrote:
> > We really shouldn't be displaying any error messages in the event of a
> > timeout though. Earlier versions of the UMP firmware did not support
> > the link update interfa
On Fri, 2008-08-08 at 11:43 -0700, Matt Carlson wrote:
>
> Segher is right. The code should be 2.5 milliseconds but is actually
> much longer. This fix is actually already in my patch queue and needs
> to be sent upstream.
>
> We really shouldn't be displaying any error messages in the event of
Benjamin Herrenschmidt wrote:
> On Fri, 2008-08-08 at 10:58 +0200, Segher Boessenkool wrote:
> > > I don't know yet for sure what happens, but a quick look at the commit
> > > seems to show that the driver synchronously spin-waits for up to 2.5ms
> >
> > That's what the comment says, but the code
On Fri, 2008-08-08 at 11:43 -0700, Matthew Carlson wrote:
> Segher is right. The code should be 2.5 milliseconds but is actually
> much longer. This fix is actually already in my patch queue and needs
> to be sent upstream.
>
Matt, I think we can optimize this a little more. The heart beat ev
On Fri, Aug 08, 2008 at 07:18:31PM +1000, Benjamin Herrenschmidt wrote:
> On Fri, 2008-08-08 at 10:58 +0200, Segher Boessenkool wrote:
> > > I don't know yet for sure what happens, but a quick look at the commit
> > > seems to show that the driver synchronously spin-waits for up to 2.5ms
> >
> > T
On Friday 08 August 2008, Segher Boessenkool wrote:
> > I don't know yet for sure what happens, but a quick look at the commit
> > seems to show that the driver synchronously spin-waits for up to 2.5ms
>
> That's what the comment says, but the code says 2.5 _seconds_:
>
> + /* Wait for up t
On Fri, 2008-08-08 at 10:58 +0200, Segher Boessenkool wrote:
> > I don't know yet for sure what happens, but a quick look at the commit
> > seems to show that the driver synchronously spin-waits for up to 2.5ms
>
> That's what the comment says, but the code says 2.5 _seconds_:
>
> + /* Wait
I don't know yet for sure what happens, but a quick look at the commit
seems to show that the driver synchronously spin-waits for up to 2.5ms
That's what the comment says, but the code says 2.5 _seconds_:
+ /* Wait for up to 2.5 milliseconds */
+ for (i = 0; i < 25; i++) {
+
but a quick look at the commit
seems to show that the driver synchronously spin-waits for up to 2.5ms
with a lock held multiple times from a timer interrupt. I don't know
yet if that's where the problem comes from, or if it's an issue with
the FW going nuts and the chip hogging t
Hi John.
Oops, you had also posted this patch to the list later, so I'm also
forwarding my comments to the list.
Cheers,
g.
On Sat, Jun 28, 2008 at 3:56 PM, Grant Likely <[EMAIL PROTECTED]> wrote:
> Sorry for the late reply on this one, I had gotten rather busy.
>
> On Wed, Jun 18, 2008 at 03:09
1 - 100 of 126 matches
Mail list logo
