On Fri, 2013-07-26 at 14:08 -0300, Marcelo Cerri wrote:
> ---
> drivers/crypto/nx/nx-sha256.c | 108 +++-
> drivers/crypto/nx/nx-sha512.c | 113
> --
> 2 files changed, 129 insertions(+), 92 deletions(-)
What about the o
On Fri, 2013-07-26 at 12:54 -0700, Linus Torvalds wrote:
>
> *Some* other 64-bit architectures do 16k stack sizes. But neither
> x86-64 nor powerpc do, afaik. Instead, they do irq stacks, which is
> generally a better idea than having one big stack.
Sadly you over estimated us here :-) We do 16K
On Fri, 2013-07-26 at 08:09 +0530, Preeti U Murthy wrote:
> *The lapic of a broadcast CPU is active always*. Say CPUX, wants the
> broadcast CPU to wake it up at timeX. Since we cannot program the lapic
> of a remote CPU, CPUX will need to send an IPI to the broadcast CPU,
> asking it to program i
On Fri, 2013-07-19 at 20:14 +0200, Sebastian Andrzej Siewior wrote:
> The problem is that platform_device_del() "releases" each ressource in its
> tree. This does not work on platform_devices created by OF becuase they
> were never added via insert_resource(). As a consequence old->parent in
> __re
On Mon, 2013-07-22 at 00:44 +0100, Grant Likely wrote:
> > BTW, it looks like Grant has attempted this already:
>
> Yup, things broke badly. Unfortunately the of_platform_device and
> platform_device history doesn't treat resources in the same way. I
> would like to merge the code, but I haven't b
Hi Linus !
Here is not quite a handful of powerpc fixes for rc3. The windfarm fix is
a regression fix (though not a new one), the PMU interrupt rename is not
a fix per-se but has been submitted a long time ago and I kept forgetting
to put it in (it puts us back in sync with x86), the other perf bi
On Fri, 2013-07-26 at 14:08 -0300, Marcelo Cerri wrote:
> This series of patches fixes two bugs that are triggered when the input data
> is
> too large. The first one is caused by the miscalculation of physical addresses
> and the second one by some limits that the co-processor has to the input da
On Thu, 2013-08-01 at 20:03 -0400, Paul Gortmaker wrote:
> I've added Ben to the CC in case he has a suggestion on
> how best to fix this, even though it is not yet mainline.
Can you exchange with a TIF_ that isn't used in asm ? For example
TIF_PERFMON_* ? Keep all the asm ones below 16 and move u
On Thu, 2013-08-01 at 16:18 -0600, Alex Williamson wrote:
> vfio-pci needs to support an interface to do hot resets (PCI parent
> bridge secondary bus reset). We need this to support reset of
> co-assigned devices where one or more of the devices does not support
> function level reset. In parti
On Fri, 2013-08-02 at 10:19 -0400, Paul Gortmaker wrote:
>
> Yep, 3.8 shuffled TIF_MEMDIE to the end of the queue, but
> in 3.10, mainline commit 22ecbe8dcef has already done that trick.
>
> The list of donor victims that aren't used in asm is getting
> smaller, but TIF_POLLING_NRFLAG seems OK an
On Fri, 2013-08-02 at 10:36 -0600, Alex Williamson wrote:
> > Also in some cases, at least for us, we have a problem where the scope
> > of the reset can be larger than the group ... in this case I think we
> > need to forbid the reset.
>
> Interesting, I would have ventured to guess that resets
[ resent in case you missed it ]
Hi Linus !
Here is not quite a handful of powerpc fixes for rc3. The windfarm fix is
a regression fix (though not a new one), the PMU interrupt rename is not
a fix per-se but has been submitted a long time ago and I kept forgetting
to put it in (it puts us back in
On Fri, 2013-08-02 at 16:49 -0600, Bjorn Helgaas wrote:
> [+cc linux-pci]
>
> On Fri, Aug 2, 2013 at 3:28 PM, Benjamin Herrenschmidt
> wrote:
>
> > Right. Another use case is, I know of devices that need a fundamental
> > reset (PERST) after applying a FW update.
>
On Fri, 2013-08-02 at 17:37 -0600, Alex Williamson wrote:
> > Yes.
> >
> > We have that similar issue with error handling, when the driver doesn't
> > have the right hooks, we simulate an unplug, reset, then replug.
> >
> > Maybe we could provide generic helpers to do that...
>
> Devices going
On Tue, 2013-08-20 at 13:22 +0100, Sudeep KarkadaNagesha wrote:
> Correct, he has reviewed but I am waiting for his ACK before I could
> sent you pull request. Hopefully I should be able to send pull request
> tomorrow with his ACK.
>
> Hi Ben,
>
> If this is patch is fine, can I have your ACK ?
On Wed, 2013-08-14 at 17:26 +0530, Preeti U Murthy wrote:
> -static irqreturn_t unused_action(int irq, void *data)
> +static irqreturn_t timer_action(int irq, void *data)
> {
> - /* This slot is unused and hence available for use, if needed
> */
> + timer_interrupt();
> return
On Wed, 2013-08-14 at 17:26 +0530, Preeti U Murthy wrote:
> static irqreturn_t timer_action(int irq, void *data)
> {
> - timer_interrupt();
> + decrementer_timer_interrupt();
> return IRQ_HANDLED;
> }
I don't completely understand what you are doing here, but ...
> @@ -223,7 +22
On Wed, 2013-08-14 at 17:26 +0530, Preeti U Murthy wrote:
> This patch hooks into the existing broadcast framework along with the support
> that this patchset introduces for ppc, and the cpuidle driver backend
> for powernv(posted out by Deepthi Dharwar:https://lkml.org/lkml/2013/7/23/128)
> to add
powerpc -next,
though it's not a huge deal and not hard to fixup, but expect Linus
to tick unless we sort it out some other way.
Appart from that, it's fine, builds on all my test configs and doesn't
seem to negatively impact things as far as I can tell so far...
Acked-by: Benjami
On Tue, 2013-08-06 at 18:08 -0500, Scott Wood wrote:
> Here's another example. get_lppaca() will only build on book3s -- and
> yet we get requests for e500 code to use this file.
Indeed, Besides there is already accessors afaik for lppaca that compile
to nothing on E (and if not they would be tri
On Wed, 2013-08-07 at 18:15 -0500, Fionnuala Gunter wrote:
> This patch fixes a bug that is triggered when cts(cbc(aes)) is used with
> nx-crypto driver on input larger than 32 bytes.
>
> The chaining value from co-processor was not being saved. This value is
> needed because it is used as the IV
On Tue, 2013-08-06 at 15:44 -0500, Nathan Fontenot wrote:
> I am planning on pulling the first two patches and sending them out
> separate from the patch set since they are really independent of the
> rest of the patch series.
>
> The remaining code I will send out for review and inclusion in
> li
On Mon, 2013-07-22 at 19:53 -0700, Joe Perches wrote:
> Anyway, you cc'd all the right people already.
>
> If no one responds after a couple weeks, either
> send it to Jiri or directly to Linus.
Or I'll just merge it with the rest of the series.
Cheers,
Ben.
--
To unsubscribe from this list: s
Hi Linus !
Here is a series of powerpc fixes. It's a bit big, mostly because of the
series of 11 "EEH" patches from Gavin. The EEH (Our IBM specific
PCI/PCIe Enhanced Error Handling) code had been rotting for a while and
this merge window saw a significant rework & fixing of it by Gavin Shan.
How
On Wed, 2013-07-24 at 15:43 -0700, Andrew Morton wrote:
> For what? The three lines of comment in page-flags.h? ack :)
>
> Manipulating page->_count directly is considered poor form. Don't
> blame us if we break your code ;)
>
> Actually, the manipulation in realmode_get_page() duplicates the
On Thu, 2013-07-25 at 08:34 +1000, Anton Blanchard wrote:
> > Apart from the annoying colors, is there anything specific I should
> > be looking for? Some sort of error message, or output that actually
> > makes sense?
>
> Thanks for testing! Ben, I think the patch is good to go.
Sent it yesterd
Hi Linus !
Here are some powerpc fixes for you.
This includes small series from Michael Neuling to fix a couple of nasty
remaining problems with the new Power8 support, also targeted at stable
3.10, without which some new userspace accessible registers aren't
properly context switched, and in som
On Tue, 2013-08-13 at 16:40 +0100, Sudeep KarkadaNagesha wrote:
> There seems to be conflict in the new function "of_get_cpu_node" added.
> PowerPC also defines the same function name. Further microblaze and
> openrisc declares it(can be removed) but doesn't define it.
> To fix this:
> 1. I can ren
On Tue, 2013-08-13 at 19:29 +0100, Sudeep KarkadaNagesha wrote:
> I don't understand completely the use of ibm,ppc-interrupt-server#s and
> its implications on generic of_get_cpu_node implementation.
> I see the PPC specific definition of of_get_cpu_node uses thread id only
> in 2 instances. Based
On Tue, 2013-08-13 at 13:44 -0500, Rob Herring wrote:
> It is up to Rafael if he is willing/able to rebase his tree, but I
> would drop this series until this is sorted out. I think the new
> common function should be and can be generalized to work for powerpc.
> It would need to make reg property
On Tue, 2013-08-13 at 21:45 +0200, Rafael J. Wysocki wrote:
>
> I'd go for 1 above personally.
Yuck no. Two functions with roughly the same name and the same purpose
differing only by an underscore just because one can't take 5mn to
reconcile the new one with the old one ? No way.
Ben.
--
To u
On Thu, 2013-08-01 at 14:44 +1000, Alexey Kardashevskiy wrote:
> This is to reserve a capablity number for upcoming support
> of H_PUT_TCE_INDIRECT and H_STUFF_TCE pseries hypercalls
> which support mulptiple DMA map/unmap operations per one call.
Gleb, any chance you can put this (and the next on
On Wed, 2013-08-14 at 11:01 +0100, Sudeep KarkadaNagesha wrote:
> Yes this doesn't cover the historical "ibm,ppc-interrupt-server#s",
> for
> which we can have PPC specific wrapper above the generic one i.e. get
> the cpu node and then parse for thread id under custom property.
A wrapper is wrong.
Hi Linus !
Here are a few powerpc bits & fixes for rc1. A couple of str*cpy fixes,
some fixes in handling the FSCR register on Power8 (controls the
enabling of processor features), a 32-bit build fix and a couple more
nits.
Cheers,
Ben.
The following changes since commit 6dbe51c251a327e012439c47
On Mon, 2013-05-13 at 11:18 +1000, Stephen Rothwell wrote:
> 47 powerpc
Oops ;-)
So most of that *was* in -next for at least a day or two afaik just not
before the merge window opened. The reason for that is that I was on
an extended vacation for 5 weeks and was playing catch up until fairly
On Mon, 2013-05-13 at 13:21 +0800, Li Zhong wrote:
> These patches try to support context tracking for Power arch, beginning with
> 64-bit pSeries. The codes are ported from that of the x86_64, and in each
> patch, I listed the corresponding patch for x86.
So that's yet another pile of bloat on al
On Mon, 2013-05-13 at 13:21 +0800, Li Zhong wrote:
> int recover = 0;
> + enum ctx_state prev_state;
> +
> + prev_state = exception_enter();
Please make it nicer:
enum ctx_state prev_state = exception_enter();
int recover = 0;
> __get_cpu_var(irq_stat).mce_ex
On Mon, 2013-05-13 at 16:03 +0800, Li Zhong wrote:
>
> To my understanding, it is used to enable RCU user extended quiescent
> state, so RCU on that cpu doesn't need scheduler ticks. And together
> with some other code(already in 3.10), we are able to remove the ticks
> in some cases (e.g. only 1
On Mon, 2013-05-13 at 16:44 +0800, Li Zhong wrote:
> Yes, the above and hash_page() are two C functions for a same exception.
> And the exception hooks enable RCU usage in those C codes. But for asm
> codes, I think we could assume that there would be no RCU usage there,
> so we don't need wrap the
On Mon, 2013-05-13 at 17:46 +0800, Li Zhong wrote:
> > hash_page() won't start a new RCU, at least not in its current incarnation,
> > the only thing I can see it ever doing would be to take some RCU read locks
> > one
> > day (it doesn't today).
>
> Seems I added the hooks because of the trace p
):
powerpc: Add an in memory udbg console
Aneesh Kumar K.V (2):
powerpc/mm: Use the correct mask value when looking at pgtable address
powerpc: Fix build errors STRICT_MM_TYPECHECKS
Anton Blanchard (1):
powerpc/kexec: Fix kexec when using VMX optimised memcpy
Benjamin Herrenschmidt (5
On Tue, 2013-05-14 at 10:29 -0500, Larry Finger wrote:
> Hi,
>
> When building 3.10-rc1 on a PowerBook G4, I get the following warning:
Thanks. Should be fixed now, let me know if it's not.
Cheers,
Ben.
> cc1: warnings being treated as errors
> arch/powerpc/perf/core-book3s.c: In function ‘powe
erpc hardware nowadays is to use
qemu-system-ppc64 with -M pseries.
You can find cross compilers for the kernel on kernel.org and you can
feed qemu with some distro installer ISO.
Cheers,
Ben.
> Signed-off-by: Jiang Liu
> Cc: Benjamin Herrenschmidt
> Cc: Paul Mackerras
> Cc: linuxppc-
On Wed, 2013-05-15 at 00:51 +0800, Jiang Liu wrote:
> Enhance PPC architecture specific code to use hotplug-safe iterators
> to walk PCI buses.
I was about to ack it but then I saw:
> diff --git a/arch/powerpc/kernel/pci_64.c b/arch/powerpc/kernel/pci_64.c
> index 51a133a..a41c6dd 100644
> --- a/
On Wed, 2013-05-15 at 22:46 +0800, Liu Jiang wrote:
>I don't know any OF exports, could you please help to CC
> some OF experts?
I wrote that code I think. Sorry, I've missed the beginning of the
thread, what is the problem ?
Cheers,
Ben.
--
To unsubscribe from this list: send the line
On Wed, 2013-05-15 at 07:58 -0700, Yinghai Lu wrote:
> Ben,
>
> in drivers/pci/probe.c::pci_scan_device() there is
>
> pci_set_of_node(dev);
>
> if (pci_setup_device(dev)) {
> kfree(dev);
> return NULL;
> }
>
> so if pci_setup_device fail
powerpc/perf: Enable branch stack sampling framework
powerpc: Setup BHRB instructions facility in HFSCR for POWER8
Ben Collins (1):
powerpc/85xx: sgy-cts1000 - Remove __dev* attributes
Benjamin Herrenschmidt (5):
Merge remote-tracking branch 'mpe/master' into nex
On Mon, 2013-04-22 at 11:41 +0100, Andrew Murray wrote:
> The pci_process_bridge_OF_ranges function, used to parse the "ranges"
> property of a PCI host device, is found in both Microblaze and PowerPC
> architectures. These implementations are nearly identical. This patch
> moves this common code t
On Mon, 2013-05-06 at 14:24 -0500, Kent Yoder wrote:
> Hi Ben, just a friendly reminder to please apply.
Oh, I assumed that stuff was going via some drivers/crypto maintainer...
I can apply.
Cheers,
Ben.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
On Mon, 2013-05-06 at 16:15 -0700, Yinghai Lu wrote:
> BenH reported that there is some assign unassigned resource problem
> in powerpc.
>
> It turns out after
> | commit 0c5be0cb0edfe3b5c4b62eac68aa2aa15ec681af
> | Date: Thu Feb 23 19:23:29 2012 -0800
> |
> |PCI: Retry on IORESOURCE_IO type
Anton Blanchard (1):
powerpc: Emulate non privileged DSCR read and write
Benjamin Herrenschmidt (9):
powerpc/powerpnv: Properly handle failure starting CPUs
powerpc/pci: Don't add bogus empty resources to PHBs
powerpc/pnv: Fix "compatible" property
On Tue, 2013-05-07 at 15:17 -0700, Yinghai Lu wrote:
> For x86 8 sockets or 32 sockets system that will have one root bus per socket,
> They may have some root buses do not have mmio non-pref range.
That seems very odd. Most device registers are non-prefetchable. I know
of no adapter today that wo
On Tue, 2013-05-07 at 15:44 -0700, Yinghai Lu wrote:
> x86 32 socket system, we may need to leave more mmiol for only several
> sockets to make them work with cards that does not support mmio 64 bit
> pref.
Ok, while on POWER each root bridge has its own distinct 32-bit space
(mapped elsewhere in
Hi folks !
Do we provide drivers any guarantee to what happen if an MSI is shot
while masked with disable_irq() or while not yet request_irq()'ed ?
Do we guarantee delivery (latched while masked), non-delivery, or
undefined ?
I'm bringing up a piece of HW where if it happened, it won't be
automa
On Thu, 2013-05-09 at 16:03 +0530, Srivatsa S. Bhat wrote:
> Can you check if the patch posted here fixes it?
>
> http://marc.info/?l=linux-kernel&m=136791823608013&w=2
I believe I've already merged a patch for that unless I did something
wrong ...
Cheers,
Ben.
--
To unsubscribe from this list
On Fri, 2013-05-10 at 20:50 +1000, Michael Neuling wrote:
> The buffer is in the core (not main memory) and hence only has limited
> entries. So skipping entries that can hopefully be determined in
> other ways means we can log more branches.
>
> That being said, it's a PITA for the kernel ;-)
I
On Thu, 2013-04-25 at 10:23 -0500, Rob Herring wrote:
> Ben, Can I have your Ack for this? The change is straightforward and
> neither of the 2 drivers used the id parameter that is removed.
Didn't you get my mail about a compile failure caused by this patch ?
Or did you send an update that I mis
On Thu, 2013-04-25 at 14:14 -0500, Rob Herring wrote:
> On 04/25/2013 12:35 PM, Benjamin Herrenschmidt wrote:
> > On Thu, 2013-04-25 at 10:23 -0500, Rob Herring wrote:
> >> Ben, Can I have your Ack for this? The change is straightforward and
> >> neither of the 2 drivers
On Mon, 2013-04-29 at 11:35 +1000, Stephen Rothwell wrote:
> Today's linux-next merge of the vfs tree got a conflict in
> arch/powerpc/kernel/rtas_flash.c between commit ad18a364f186
> ("powerpc/rtas_flash: Free kmem upon module exit"), from the powerpc
> tree and commit 5c0333c00ff6 ("ppc: Clean
On Mon, 2013-04-29 at 15:55 -0700, Tejun Heo wrote:
> Benjamin, can you please pick this up?
>
> Thanks a lot and sorry about the trouble.
Done.
Cheers,
Ben.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More ma
On Mon, 2013-04-15 at 14:17 +1000, Michael Ellerman wrote:
> This patch adds preliminary support for the power8 PMU to perf.
Might be worthwhile to have a small blurb explaining roughly what you
mean by "preliminary" :-)
Cheers,
Ben.
> Signed-off-by: Michael Ellerman
> ---
> arch/powerpc/perf/
On Mon, 2013-04-15 at 14:57 +0200, Thomas Petazzoni wrote:
> Michal, Ben,
>
> Would you have some time to look at this patch and give your comments
> and/or ACK ? Since it touches the PowerPC and Microblaze core code, we
> need your agreement to merge this code, and quite a bit of code pending
> f
On Tue, 2013-04-16 at 11:50 +0530, Aruna Balakrishnaiah wrote:
>
> Sure. I will have one #ifdef for declarations and one for function
> definitions.
Declarations generally don't need #ifdef's
Cheers,
Ben.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body o
On Mon, 2013-04-15 at 20:29 +0200, Linus Walleij wrote:
> > As agreed with Rob Herring, series applied to mvebu/drivers to
> support
> > mvebu pcie driver.
>
> Will this hit ARM SoC soon-ish so I can base a pull request for the
> Integrator on this stuff as well?
Do not send this series upstream
Hi Greg !
Caught that on a console today running some 3.10-almost-rc2
(based on ec50f2a97a4a7098a81b40030e0bfe28bdc43740). Right now I don't
have the bandwidth to investigate but I though you might be
interested :-)
I'll take another peek if it happens again.
On Tue, 2013-05-21 at 11:22 +1000, Benjamin Herrenschmidt wrote:
> Hi Greg !
Adding Jiri...
> Caught that on a console today running some 3.10-almost-rc2
> (based on ec50f2a97a4a7098a81b40030e0bfe28bdc43740). Right now I don't
> have the bandwidth to investigate but I th
On Tue, 2013-05-21 at 16:45 +0200, Alexander Gordeev wrote:
> On Tue, Jan 15, 2013 at 03:38:53PM +0800, Mike Qiu wrote:
> > The test results is shown by 'cat /proc/interrups':
> > CPU0 CPU1 CPU2 CPU3
> > 16: 240458 261601 226310 200425 XICS Le
On Wed, 2013-05-22 at 12:49 +0800, Libo Chen wrote:
> ping...
This is pointless. We routinely avoid adding such crap by having
the various free(...) routines cope with NULL. You just need to make
sure you are indeed NULL in the error case.
Ben.
> On 2013/5/5 16:38, chenlib...@gmail.com wrote:
>
On Wed, 2013-05-22 at 07:26 -0500, Rob Herring wrote:
> Did you have a chance to test this? I want to get this into -next.
Ah sorry, skipped out of my mind, I'll get to it asap...
Cheers,
Ben.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
.git merge
for you to fetch changes up to f1dd153121dcb872ae6cba8d52bec97519eb7d97:
powerpc/pseries: Make 32-bit MSI quirk work on systems lacking firmware
support (2013-05-24 18:16:54 +1000)
----
Benjamin Herrenschmidt (5):
p
nd you have at least build-tested it, then I'm happy.
Acked-by: Benjamin Herrenschmidt
> ---
> arch/powerpc/include/asm/uaccess.h | 16
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/uaccess.h
> b/arch/po
On Sun, 2013-05-26 at 22:06 +0200, Sebastian Hesselbarth wrote:
> good you mention it. I added Grant on Cc and will give a short
> sum-up why I casted the const from property->value away here.
>
> Maybe I overlooked the API for modifying the DT property but as
> far as I've seen - there is no API
On Mon, 2013-05-27 at 02:23 -0700, David Miller wrote:
> Sparc has an of_set_property(), it needs to become generic.
There is an of_update_property(), we could change the name though, yours
is nicer :-)
Cheers,
Ben.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
t
On Mon, 2013-05-27 at 12:24 +0200, Sebastian Hesselbarth wrote:
> > There is an of_update_property(), we could change the name though,
> yours
> > is nicer :-)
>
> Ben, David,
>
> I had a quick look at sparc's of_set_property. Nothing special except
> it
> depends on OF_DYNAMIC at some place. Usi
On Mon, 2013-05-27 at 18:20 +0200, Alexander Gordeev wrote:
> This fix just adds a missed call to a new PAPR function
> which should have been done with commit e61133d ("powerpc/
> pseries: Force 32 bit MSIs for devices that require it")
Arguably, PAPR should allow to disable MSIs using either int
On Mon, 2013-05-27 at 14:47 +0200, Arnd Bergmann wrote:
> On Monday 27 May 2013 21:50:04 Benjamin Herrenschmidt wrote:
> > However, that wouldn't help much with the allocation/leak problem,
> > though at least it would be easier to use. It could also *try* to re-use
> >
On Mon, 2013-05-27 at 13:18 -0700, David Miller wrote:
> From: Benjamin Herrenschmidt
> Date: Mon, 27 May 2013 21:50:04 +1000
>
> > It would be handy to be able to just do something like
> >
> > of_set_property(node, name, ptr, len);
> >
> > Ho
On Tue, 2013-05-28 at 09:20 +0200, Alexander Gordeev wrote:
> On Tue, May 28, 2013 at 07:52:11AM +1000, Benjamin Herrenschmidt wrote:
> > On Mon, 2013-05-27 at 18:20 +0200, Alexander Gordeev wrote:
> > > This fix just adds a missed call to a new PAPR function
> > > which
On Wed, 2013-03-27 at 13:05 +0100, Geert Uytterhoeven wrote:
> On Wed, Mar 27, 2013 at 11:47 AM, Paul Bolle wrote:
> > 3) I removed two files in documentation that are almost entirely PReP
> > specific. The remaining lines looked uninteresting.
>
> > --- a/Documentation/powerpc/sound.txt
> > +++
te: Wed, Mar 20, 2013 at 9:22 AM
> Subject: [PATCH v2] drivers/crypto/nx: fix init race, alignmasks and GCM bug
> To: linux-kernel@vger.kernel.org
> Cc: linux-cry...@vger.kernel.org, Benjamin Herrenschmidt
>
>
>
> Fixes a race on driver init with registering algorithms
Hi Linus !
A couple of weeks ago, David sent an email that went unanswered about a
regression concerning orderly_poweroff(). I think the original patch
causing it should be reverted, here's the actual email with the
explanation:
<<<
Subject: orderly_poweroff() is no longer safe in atomic context
Hi folks !
I stumbled upon this today:
static inline unsigned long iommu_num_pages(unsigned long addr,
unsigned long len,
unsigned long io_page_size)
{
unsigned long size = (addr & (io_page_size - 1))
On Sun, 2012-08-05 at 08:39 +0200, Andreas Schwab wrote:
> addr & (io_page_size - 1) computes the offset into the page pointed to
> by addr. Looks right to me.
>
> addr & ~(io_page_size - 1) would round addr down to the start of the
> page.
Ah that's right, for some reason I'm so used to seeing
On Mon, 2012-08-06 at 22:31 +0100, Russell King wrote:
>
> So, if we made this a numeric index, then we have 32 resource types
> to deal with, and no need to bugger around with re-using an existing
> type for something else.
>
> This makes sense, MEM, IRQ and DMA are all mutually exclusive, as
>
On Tue, 2012-08-07 at 09:47 +0800, Haojian Zhuang wrote:
> > Whoever looks at this would need to do some detective work, it does
> seem
> > like there must have been a reason to use a bitmask here...
>
> Changing bitmask to a value for IORESOURCE type is a risk. I agree on
> Mark
> that someone wi
On Wed, 2012-08-22 at 16:59 +0200, Andrea Arcangeli wrote:
> From: Vaidyanathan Srinivasan
>
> * PMD flaging is not required in powerpc since large pages
> are tracked in ptes.
> * Yet to be tested with large pages
> * This is an initial patch that partially works
> * knuma_
On Thu, 2012-08-23 at 08:01 +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2012-08-22 at 16:59 +0200, Andrea Arcangeli wrote:
> > From: Vaidyanathan Srinivasan
> >
> > * PMD flaging is not required in powerpc since large pages
> > are tracked in ptes.
>
On Thu, 2012-08-23 at 00:35 +0200, Andrea Arcangeli wrote:
> I'm actually surprised you don't already check for PROTNONE
> there. Anyway yes this is necessary, the whole concept of NUMA hinting
> page faults is to make the pte not present, and to set another bit (be
> it a reserved bit or PROTNONE
On Thu, 2012-08-23 at 11:02 +0530, Srikar Dronamraju wrote:
> >
>
> insn is updated/accessed in the arch independent code. Size of
> uprobe_opcode_t could be different for different archs.
> uprobe_opcode_t
> represents the size of the smallest breakpoint instruction for an
> arch.
>
> Hence u8
On Thu, 2012-08-23 at 21:47 +0530, Srikar Dronamraju wrote:
> * Benjamin Herrenschmidt [2012-08-23 20:06:18]:
>
> > On Thu, 2012-08-23 at 11:02 +0530, Srikar Dronamraju wrote:
> > > >
> > >
> > > insn is updated/accessed in the arch independent co
On Thu, 2012-08-23 at 15:11 +1000, Benjamin Herrenschmidt wrote:
> So we don't do protnone, and now that you mention it, I think that
> means
> that some of our embedded stuff is busted :-)
>
> Basically PROT_NONE turns into _PAGE_PRESENT without _PAGE_USER for
> us.
..
On Fri, 2012-08-24 at 11:13 +1000, Michael Ellerman wrote:
>
> Yeah. A NULL regs here is a kernel bug, so I think it's actually
> preferable to crash than silently return.
Or best, if you think there's a remote chance that the bug might hit:
if (WARN(!regs))
return
Chee
08-24 20:55:55 +1000)
Aaro Koskinen (1):
powerpc/dma-iommu: Fix IOMMU window check
Anton Blanchard (2):
powerpc: POWER7 copy_to_user/copy_from_user patch applied twice
powerpc: Fix VMX in interrupt check in POWER7 copy loops
Benjamin Herrenschmidt (1):
Revert "pow
On Thu, 2012-08-23 at 17:46 +0100, Alan Cox wrote:
> > IMO, the driver probing path is allowed to sleep, so looks request
> firmware
> > should be allowed inside .probe().
>
> I'm not convinced about that. It can sleep but its holding various
> locks
> in most cases, and it looks like that can end
> > I think the powerpc port is at fault here.
> >
> > Part of being able to advertise ISA_DMA_API is providing isa_virt_to_bus().
Hrm, that's ancient gunk, I'll have to dig. We potentially can support
ISA devices DMA'ing from an ISA bridge... but via the iommu, which means
isa_virt_to_bus is a
ivers, though it would
be best to have as much conversion as possible done at once still.
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
arch/frv/mb93090-mb00/pci-iomap.c |4 -
arch/powerpc/kernel/iomap.c | 69 --
arch/sparc/
On Mon, 2008-02-18 at 14:35 +1100, Benjamin Herrenschmidt wrote:
> The current iomap stuff (pci_iomap, ioport_map, pcim_iomap, ...) is
> confusing as it returns pointers in the _miomem address space.
>
> However, even if that would work on some architectures, the result
> of tho
also "fixed" the 64bits arch for consistency.
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
arch/alpha/kernel/pci.c |4 ++--
arch/arm/mm/iomap.c |4 ++--
arch/frv/mb93090-mb00/pci-iomap.c |4 ++--
arch/mips/lib/iomap-pci
> Maybe Christian's patch can be improved to not do the check on these?
> As long as /dev/port exists, it seems reasonable that the kernel should
> behave, no matter what I/O ports are accessed from user-space.
nonsense.
/dev/mem exists for example, but you are still not supposed to go
bang all
>
> * Super-I/O chips at 0x2e/0x2f and 0x4e/0x4f.
>
> * Legacy PC hardware monitoring chips at 0x290-0x297.
>
> * IPMI interface at 0x0ca3 and 0x0cab (read-only).
>
> Please tell me which ones should be skipped on PowerPC.
Skip the whole thing. I consider that on a powerpc linux port, the
pla
301 - 400 of 2780 matches
Mail list logo
