_bits() & bpf_internal_load_pointer_neg_helper()).
In order to do that we need to leave space after the bl for the
linker
to insert a reload of our TOC pointer.
Signed-off-by: Michael Ellerman
Oops, x2, and
Acked-by: Matt Evans
:-)
---
arch/powerpc/net/bpf_jit_64.S |2 ++
1 file changed, 2 insertions(+)
dif
pace after the bl for the
linker
to insert a reload of our TOC pointer.
Signed-off-by: Michael Ellerman
Oops..!
Acked-by: Matt Evans
---
arch/powerpc/net/bpf_jit_64.S |2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/powerpc/net/bpf_jit_64.S
b/arch/powerpc/net/bpf_jit_64.S
i
On Sun, Jun 23, 2013 at 6:45 AM, Srivatsa S. Bhat
wrote:
> Once stop_machine() is gone from the CPU offline path, we won't be able
> to depend on disabling preemption to prevent CPUs from going offline
> from under us.
>
> Use the get/put_online_cpus_atomic() APIs to prevent CPUs from going
> offl
}
>
> + /*
> + * If we support a HW FPU, we need to ensure the FP state
> + * if flushed into the thread_struct before attempting
As long as you're moving the comment you could fix up the spelling
error: s/if/is/
Cheers,
-Matt Helsley
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
>
> This looks like it's in only used in the BPF JIT code.
>
> Matt, any chance you an ACK/NACK this?
Sure, that looks sensible, thanks Vladimir.
Acked-by: Matt Evans
>
> Mikey
>
>>
>> Signed-off-by: Vladimir Murzin
>> ---
>> a
Wed, Aug 28, 2013 at 02:49:52AM +0400, Vladimir Murzin wrote:
>>> commit b6069a9570 (filter: add MOD operation) added generic
>>> support for modulus operation in BPF.
>>>
> Sorry, nobody got a chance to review that yet. Unfortunately Matt
> doesn't work for us a
Hi Vladimir,
On 21 Sep 2013, at 17:25, Vladimir Murzin wrote:
> commit b6069a9570 (filter: add MOD operation) added generic
> support for modulus operation in BPF.
>
> This patch brings JIT support for PPC64
>
> Signed-off-by: Vladimir Murzin
> Acked-by: Matt Evans
Not
lect GENERIC_STRNCPY_FROM_USER
> select GENERIC_STRNLEN_USER
> + select HAVE_ARCH_AUDITSYSCALL
> select HAVE_MOD_ARCH_SPECIFIC
> select MODULES_USE_ELF_RELA
> select ODD_RT_SIGACTION
Thanks.
Acked-by: Matt Turner
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On Wed, Mar 19, 2014 at 3:04 PM, Eric Paris wrote:
> For all arches which support audit implement syscall_get_arch()
support audit -- is that AUDIT_ARCH? If so, alpha gained support
recently, so I think this patch needs to handle alpha too?
___
Linuxppc
A couple of minor nits below...
> On Mar 7, 2016, at 12:59 PM, Ian Munsie wrote:
>
> @@ -346,7 +350,7 @@ ssize_t afu_read(struct file *file, char __user *buf,
> size_t count,
>
> for (;;) {
> prepare_to_wait(&ctx->wq, &wait, TASK_INTERRUPTIBLE);
> - if (ctx_even
> On Mar 7, 2016, at 12:59 PM, Ian Munsie wrote:
>
> From: Michael Neuling
>
> This provides AFU drivers a means to associate private data with a cxl
> context. This is particularly intended for make the new callbacks for
> driver specific events easier for AFU drivers to use, as they can easil
> On Mar 7, 2016, at 7:48 PM, Ian Munsie wrote:
>
> From: Ian Munsie
>
> This adds an afu_driver_ops structure with event_pending and
> deliver_event callbacks. An AFU driver such as cxlflash can fill these
> out and associate it with a context to enable passing custom AFU
> specific events to
> On Mar 9, 2016, at 8:37 AM, Vaibhav Jain wrote:
>> +/*
>> + * AFU driver ops allows an AFU driver to create their own events to pass to
>> + * userspace through the file descriptor as a simpler alternative to
>> overriding
>> + * the read() and poll() calls that works with the generic cxl event
. For that reason, native S32_LE format is
handled by the codec. While the codec only uses the 24 MSBs, the I2S bus
is 32 bit.
Matt
On 1/3/19 3:50 pm, Nicolin Chen wrote:
Hi Shengjiu,
On Thu, Feb 28, 2019 at 05:56:31AM +, S.j. Wang wrote:
cs42xx8 is a 24-bit A/D and 24-bit D/A device, s
ut these pages are normal system RAM,
typically HugePages (but not always).
>
>Cc: Greg Kroah-Hartman
>Cc: Vandana BN
>Cc: "Simon Sandström"
>Cc: Dan Carpenter
>Cc: Nishka Dasgupta
>Cc: Madhumitha Prabakaran
>Cc: Fabio Estevam
>Cc: Matt Sickler
>Cc:
, at 06:50, Aneesh Kumar K.V wrote:
>
> Matt Corallo writes:
>
>> .config follows. I have not tested with 64K pages as, sadly, I have a
>> large BTRFS volume that was formatted on x86, and am thus stuck with 4K
>> pages. Note that this is roughly the Debian kernel, s
Hey, sorry for the delay on this. I had some apparently-unrelated hangs that I
believe were due to mpt3sas instability, and at the risk of speaking too soon
for a bug I couldn't reliably reproduce, this patch appears to have resolved
it, thanks!
> On Jan 21, 2019, at 07:35, Aneesh Kumar K.V
>
t,
if defined, int-ll64.h is included instead.
Signed-off-by: Matt Evans
---
arch/powerpc/include/asm/types.h |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/include/asm/types.h b/arch/powerpc/include/asm/types.h
index 8947b98..d82e94e 100644
--- a
From: Matt Fleming
As described in e6fa16ab ("signal: sigprocmask() should do
retarget_shared_pending()") the modification of current->blocked is
incorrect as we need to check whether the signal we're about to block
is pending in the shared queue.
Also, use the new helper func
t_mask(struct device *dev, u64
> mask)
> }
>
> struct dma_map_ops alpha_pci_ops = {
> - .alloc_coherent = alpha_pci_alloc_coherent,
> - .free_coherent = alpha_pci_free_coherent,
> + .alloc = alpha_pci_alloc_coherent,
> +
Unnecessary cast from void* in assignment.
Signed-off-by: matt mooney
---
arch/powerpc/platforms/pseries/hvCall_inst.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/hvCall_inst.c
b/arch/powerpc/platforms/pseries/hvCall_inst.c
index
rsive nature of the event
handling, plus the addition of some debug.
This should apply to 2.6.38/Linus' tree.
Thanks!
Matt
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Add more debug to print queued transfers, show control intentions and
modify an existing message to hexify address output.
Signed-off-by: Matt Evans
---
drivers/usb/host/xhci-dbg.c |2 +-
drivers/usb/host/xhci-hub.c |3 +++
drivers/usb/host/xhci-ring.c |5 +
3 files changed, 9
On weakly-ordered systems, the reading of an event's content must occur
after reading the event's validity.
Signed-off-by: Matt Evans
---
drivers/usb/host/xhci-ring.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb
During a "plug-unplug" stress test on an NEC xHCI card, a null pointer
dereference was observed. xhci_address_device() dereferenced a null
virt_dev (possibly an erroneous udev->slot_id?); this patch adds a WARN_ON &
message to aid debug if it can be recreated.
Signed-o
Make the caller loop while there are events to handle, instead.
Signed-off-by: Matt Evans
---
drivers/usb/host/xhci-ring.c | 16 +---
1 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index b46efd9..97bedd6
On weakly-ordered systems, the reading of an event's content must occur
after reading the event's validity.
Signed-off-by: Matt Evans
---
Segher, thanks for the comment; explanation added.
drivers/usb/host/xhci-ring.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
di
Make the caller loop while there are events to handle, instead.
Signed-off-by: Matt Evans
---
1 byte smaller after Sergei's suggestion.
drivers/usb/host/xhci-ring.c | 16 +---
1 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/dr
On 29/03/11 09:16, Sarah Sharp wrote:
> On Fri, Mar 25, 2011 at 06:43:44PM +1100, Matt Evans wrote:
>> Hi Sarah,
>>
>>
>> This series addresses the endian issues with the xHCI driver, and has brought
>> lovely USB 3 to PPC. :-) I've tested various types
Hi,
On 29/03/11 09:19, Sarah Sharp wrote:
> On Fri, Mar 25, 2011 at 06:43:59PM +1100, Matt Evans wrote:
>> Add more debug to print queued transfers, show control intentions and
>> modify an existing message to hexify address output.
>
> Are these new debug messages really ne
riables and comment the return value
of xhci_handle_event().
Cheers,
Matt
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On weakly-ordered systems, the reading of an event's content must occur
after reading the event's validity.
Signed-off-by: Matt Evans
---
drivers/usb/host/xhci-ring.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/driver
During a "plug-unplug" stress test on an NEC xHCI card, a null pointer
dereference was observed. xhci_address_device() dereferenced a null
virt_dev (possibly an erroneous udev->slot_id?); this patch adds a WARN_ON &
message to aid debug if it can be recreated.
Signed-o
Make the caller loop while there are events to handle, instead.
Signed-off-by: Matt Evans
---
Added a comment on the return value, defining <0 to be 'bad'.
drivers/usb/host/xhci-ring.c | 18 +++---
1 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/dri
On 30/03/11 07:00, Dmitry Torokhov wrote:
> On Sunday, March 27, 2011 09:53:00 pm Matt Evans wrote:
>> @@ -2282,7 +2284,7 @@ hw_died:
>> /* FIXME this should be a delayed service routine
>> * that clears the EHB.
>> */
>> -xhci_
On Wed, Feb 4, 2009 at 2:14 PM, Alan Nishioka wrote:
> request_firmware uses the hotplug code so the kernel doesn't have any
> sourceless binaries compiled into it. on init, the driver requests the
> firmware, user mode hotplug daemon loads the firmware from disk and gives
> the driver a pointer
eth0_pd.rx_sram_size = 0;
> -
> - eth1_pd.tx_sram_addr = 0;
> - eth1_pd.tx_sram_size = 0;
> - eth1_pd.rx_sram_addr = 0;
> - eth1_pd.rx_sram_size = 0;
> + eth_po
there something like a direct ioread32le() or so, which will
not change behaviour across architectures, is present on ARM and PPC,
and will handle both PCI address space, and "normal" "ioremapped"
memory?
--
Matt Sealey
Genesi, Manager, Developer Relations
__
On Fri, Feb 20, 2009 at 1:11 PM, Ira Snyder wrote:
> On Fri, Feb 20, 2009 at 12:57:36PM -0600, Matt Sealey wrote:
>
> I'm pretty sure memcpy_fromio() and memcpy_toio() will get you what you
> want. They don't change byte ordering.
Are they guaranteed to only do 32-bit, ali
On Fri, Feb 20, 2009 at 3:07 PM, Ira Snyder wrote:
> On Fri, Feb 20, 2009 at 02:05:08PM -0600, Matt Sealey wrote:
>> On Fri, Feb 20, 2009 at 1:11 PM, Ira Snyder wrote:
>> > On Fri, Feb 20, 2009 at 12:57:36PM -0600, Matt Sealey wrote:
>> >
>> > I'm pr
On Mon, Feb 23, 2009 at 8:03 AM, sumedh tirodkar
wrote:
> I am using PowerPC 7447A...I am trying to port SA-RTL on PowerPC...
What I said earlier was: You need to tell people what cpu you're using, what
linux kernel, etc etc etc.
Fine, we know the CPU. What kernel are you using? Is it ancient
ain.
I'm thinking we'll just provide URLs to git trees or quilt series
if subdividing is impossible and/or anyone needs wider context than
the 10 or so we post at a time.
Sorry again,
-Matt Helsley
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
ff-by: Matt Evans
---
kexec/arch/ppc64/fs2dt.c | 66 +
1 files changed, 54 insertions(+), 12 deletions(-)
diff --git a/kexec/arch/ppc64/fs2dt.c b/kexec/arch/ppc64/fs2dt.c
index 762bf04..7470132 100644
--- a/kexec/arch/ppc64/fs2dt.c
+++ b/kexec/arch/
Some of the 64bit PPC CPU features are MMU-related, so this patch moves
them to MMU_FTR_ bits. All cpu_has_feature()-style tests are moved to
mmu_has_feature(), and seven feature bits are freed as a result.
Signed-off-by: Matt Evans
---
Boot-tested on pseries and G5.
arch/powerpc/include/asm
On 07/04/11 17:06, Kumar Gala wrote:
>
> On Apr 7, 2011, at 12:48 AM, Matt Evans wrote:
>
>> diff --git a/arch/powerpc/include/asm/cputable.h
>> b/arch/powerpc/include/asm/cputable.h
>> index be3cdf9..7b0fe7c 100644
>> --- a/arch/powerpc/include/asm/cputable.h
clude/asm/local.h
> @@ -79,6 +79,7 @@ static __inline__ long local_sub_return(long i, local_t * l)
> c != (u); \
> })
> #define local_inc_not_zero(l) local_add_unless((l), 1, 0)
> +#define local_dec_not_zero(l) local_add_unless((l), -1,
smp_release_cpus() waits for all cpus (including the bootcpu) due to an
off-by-one count on boot_cpu_count (which is all CPUs). This patch replaces
that with spinning_secondaries (which is all secondary CPUs).
Signed-off-by: Matt Evans
---
arch/powerpc/include/asm/smp.h |2 +-
arch/powerpc
On Tue, 2011-06-21 at 08:19 -0400, Josh Boyer wrote:
> Various PowerPC 4xx SoCs contain a TRNG embedded in the Security function.
> This adds a device driver for that TRNG.
>
> Signed-off-by: Josh Boyer
Looks good.
Acked-by: Matt Mackall
> ---
> drivers/char/hw_random/K
On Tue, 2011-06-21 at 11:38 -0500, Kim Phillips wrote:
> [adding linux-crypto]
>
> On Tue, 21 Jun 2011 10:56:02 -0500
> Matt Mackall wrote:
>
> > On Tue, 2011-06-21 at 08:19 -0400, Josh Boyer wrote:
> > > +static struct hwrng ppc4xx_rng = {
> > > + .na
(tcpdump with varying complexity filters) and with a random BPF
generator; I haven't verified loads from the fall back skb_copy_bits path. Bug
reports/testing would be very welcome.
Cheers,
Matt
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
+obj-$(CONFIG_BPF_JIT) += bpf_jit.o bpf_jit_comp.o
diff --git a/arch/powerpc/net/bpf_jit.S b/arch/powerpc/net/bpf_jit.S
new file mode 100644
index 000..ce2225e
--- /dev/null
+++ b/arch/powerpc/net/bpf_jit.S
@@ -0,0 +1,138 @@
+/* bpf_jit.S: Packet/header access helper functions
+ * for PPC64 BPF compi
On 25/06/11 11:58, Ben Hutchings wrote:
> On Fri, 2011-06-24 at 16:02 +1000, Matt Evans wrote:
> [...]
>> +case BPF_S_ALU_ADD_K: /* A += K; */
>> +if (!K)
>> +break;
>> +
On 25/06/11 17:33, Andreas Schwab wrote:
> Matt Evans writes:
>
>> +stdur1, -128(r1); \
>
>> +addir5, r1, 128+BPF_PPC_STACK_BASIC+(2*8); \
>
>
Hi Eric,
On 25/06/11 17:49, Eric Dumazet wrote:
> Le samedi 25 juin 2011 à 09:33 +0200, Andreas Schwab a écrit :
>> Matt Evans writes:
>>
>>> + stdur1, -128(r1); \
>>
>>> + addir5, r1, 128+BPF_PPC_STACK_BASIC+
ame way as x86-64:
echo 1 > /proc/sys/net/core/bpf_jit_enable
Or, enabled with extra debug output:
echo 2 > /proc/sys/net/core/bpf_jit_enable
Signed-off-by: Matt Evans
---
Since the RFC post, this has incorporated the bugfixes/tidies from review plus a
couple more found in fu
On 19/07/11 05:42, David Miller wrote:
> From: Eric Dumazet
> Date: Mon, 18 Jul 2011 10:39:35 +0200
>
>> So in PPC SEEN_XREG only is to be set of X is read, not if written.
>>
>> So you dont have to set SEEN_XREG bit in this part :
>
> Matt, do you want to in
ame way as x86-64:
echo 1 > /proc/sys/net/core/bpf_jit_enable
Or, enabled with extra debug output:
echo 2 > /proc/sys/net/core/bpf_jit_enable
Signed-off-by: Matt Evans
---
V2: Removed some cut/paste woe in setting SEEN_X even on writes.
Merci for le review, Eric!
arch
On 19/07/11 16:59, Kumar Gala wrote:
>
> On Jul 18, 2011, at 9:13 PM, Matt Evans wrote:
>
>> An implementation of a code generator for BPF programs to speed up packet
>> filtering on PPC64, inspired by Eric Dumazet's x86-64 version.
>>
>> Filter code is gen
On 19/07/11 17:17, Kumar Gala wrote:
>
> On Jul 19, 2011, at 2:06 AM, Matt Evans wrote:
>
>> On 19/07/11 16:59, Kumar Gala wrote:
>>>
>>> On Jul 18, 2011, at 9:13 PM, Matt Evans wrote:
>>>
>>>> [snip]
>>>>
>>>> V2: Re
ame way as x86-64:
echo 1 > /proc/sys/net/core/bpf_jit_enable
Or, enabled with extra debug output:
echo 2 > /proc/sys/net/core/bpf_jit_enable
Signed-off-by: Matt Evans
---
V3: Added BUILD_BUG_ON to assert PACA CPU ID is 16bits, made a comment (in
LD_MSH) a bit clearer
fixed-sized arrays from
add_dyn_reconf_usable_mem_property() and add_usable_mem_property(), in lieu of
malloc/realloc/free.
Signed-off-by: Matt Evans
---
kexec/arch/ppc64/fs2dt.c | 82 +++---
1 files changed, 70 insertions(+), 12 deletions(-)
diff --git a
dware
execution. There are other more directed test strategies (e.g. handwritten
tests, random code) but these would be a good start.
Cheers,
Matt
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
ult. This patch iterates for_each_online_cpu so stays
within the bounds of paca[] -- and every CPU is now 'possible'.
Signed-off-by: Matt Evans
---
arch/powerpc/kernel/machine_kexec_64.c | 18 +-
1 files changed, 1 insertions(+), 17 deletions(-)
diff --git a
s_feature(KVM_FEATURE_MAGIC_PAGE))
> + kvm_use_magic_page();
> +
> + printk(KERN_INFO "KVM: Live patching for a fast VM %s\n",
> + kvm_patching_worked ? "worked" : "failed");
> +
> + return 0;
> +}
> +
> +postcore_initcall(kvm_guest_init);
Cheers,
Matt
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
heavy test:
perf record -e L1-dcache-load-misses -e L1-dcache-store-misses ./misstest
Signed-off-by: Matt Evans
---
arch/powerpc/kernel/perf_event.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/perf_event.c b/arch/powerpc/kernel/perf_event.c
ind
With dynamic PACAs, the kexecing CPU's PACA won't lie within the kernel
static data and there is a chance that something may stomp it when preparing
to kexec. This patch switches this final CPU to a static PACA just before
we pull the switch.
Signed-off-by: Matt Evans
---
arch/powe
With dynamic PACAs, the kexecing CPU's PACA won't lie within the kernel
static data and there is a chance that something may stomp it when preparing
to kexec. This patch switches this final CPU to a static PACA just before
we pull the switch.
Signed-off-by: Matt Evans
---
v2: Ch
On Wed, 14 Jul 2010 17:07:28 +0400, Anton Vorontsov
wrote:
> Hi all,
>
> Currently the sdhci driver does everything in the atomic context.
> And what is worse, PIO transfers are made from the IRQ handler.
>
> This causes huge latencies (up to 120 ms). On some P2020 SOCs,
> DMA and card detectio
s the kexeced kernel
may ask RTAS if they're online -- and RTAS would say they are. Again, stuck.
This patch kicks each present offline CPU awake before the kexec, so that
none are lost to these assumptions in the subsequent kernel.
Signed-off-by: Matt Evans
---
arch/powerpc/kernel/machine_
s the kexeced kernel
may ask RTAS if they're online -- and RTAS would say they are. Again, stuck.
This patch kicks each present offline CPU awake before the kexec, so that
none are lost to these assumptions in the subsequent kernel.
Signed-off-by: Matt Evans
---
v2: Added FIXME commen
f
your present CPUs are started up. When you reboot, any CPUs you offlined for
fun are restarted. Kexec is (in this non-crash sense) a user-initiated 'quick
reboot', so I reasoned that it should look the same as a 'hard reboot' and your
new invocation would have all available
Separated tidyup comments & debug away from the fix of restarting offline
available CPUs before waiting for them on kexec.
Matt Evans (2):
powerpc/kexec: Add to and tidy debug/comments in machine_kexec64.c
powerpc/kexec: Fix orphaned offline CPUs across kexec
arch/powerpc/ke
Tidies some typos, KERN_INFO-ise an info msg, and add a debug msg showing
when the final sequence starts.
Also adds a comment to kexec_prepare_cpus_wait() to make note of a possible
problem; the need for kexec to deal with CPUs that failed to originally start
up.
Signed-off-by: Matt Evans
ons in the subsequent kernel.
Now, the behaviour is that all available CPUs that were offlined are now
online & usable after the kexec. This mimics the behaviour of a full reboot
(on which all CPUs will be restarted).
Signed-off-by: Matt Evans
---
arch/powerpc/kernel/machine_kex
;
> Signed-off-by: Anton Blanchard
Looks like a sensible idea!
Acked-by: Matt Evans
> ---
>
> Index: powerpc.git/arch/powerpc/kernel/crash.c
> ===
> --- powerpc.git.orig/arch/powerpc/kernel/crash.c 2010-
On Tue, Aug 03, 2010 at 04:43:46PM -0700, Andrew Morton wrote:
> On Tue, 3 Aug 2010 11:11:10 +0800
> Roy Zang wrote:
>
> > --- a/drivers/mmc/host/sdhci.h
> > +++ b/drivers/mmc/host/sdhci.h
> > @@ -240,6 +240,8 @@ struct sdhci_host {
> > #define SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN (1<<25)
f secondaries.
Signed-off-by: Matt Evans
Cc: stable
---
arch/powerpc/kernel/head_64.S |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S
index 844a44b..4d6681d 100644
--- a/arch/powerpc/kernel/head_64.S
+++ b/
Unnecessary cast from void* in assignment.
Signed-off-by: matt mooney
---
arch/powerpc/platforms/pseries/hvCall_inst.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/hvCall_inst.c
b/arch/powerpc/platforms/pseries/hvCall_inst.c
index
Replace EXTRA_CFLAGS with ccflags-y and EXTRA_AFLAGS with asflags-y.
Signed-off-by: matt mooney
---
arch/powerpc/kernel/vdso32/Makefile |6 +++---
arch/powerpc/kernel/vdso64/Makefile |6 +++---
arch/powerpc/kvm/Makefile |2 +-
arch/powerpc/lib/Makefile
On 20:19 Thu 23 Sep , Stephen Rothwell wrote:
> Hi Matt,
>
> On Wed, 22 Sep 2010 23:51:09 -0700 matt mooney wrote:
> >
> > Replace EXTRA_CFLAGS with ccflags-y and EXTRA_AFLAGS with asflags-y.
>
> This looks good. One comment below ...
>
> > --- a/arc
ted sys_clk node).
"non-removable" has a typo, though I'm not sure we want non-removable anyway?
Most devices have a SD or microSD socket, and eMMC needs other driver litemmc
changes.
Cheers,
Matt
> Signed-off-by: Joel Stanley
> ---
> arch/powerpc/boot/dts/microwatt.dts |
NO.
--
Matt Sealey <[EMAIL PROTECTED]>
Genesi, Manager, Developer Relations
Sven Luther wrote:
> On Wed, Jan 09, 2008 at 07:44:58AM -0700, Grant Likely wrote:
>> Woo! Thanks Olaf. I was just about to sit down and write something
>> like this myself. Looks good to me. I
hy. And, since nobody seems to give a
shit, it will stay as bad as it is right now (a quick hack) whether
in the wild or mainlined..
--
Matt Sealey <[EMAIL PROTECTED]>
Genesi, Manager, Developer Relations
Sven Luther wrote:
> On Wed, Jan 09, 2008 at 07:50:14AM -0700, Grant Likely wrote:
>
plement for users, please feel free... save
these guys from having to maintain support for a broken device
tree by providing a correct one :D
--
Matt Sealey <[EMAIL PROTECTED]>
Genesi, Manager, Developer Relations
Olaf Hering wrote:
> The new network driver fec_mpc52xx will not work on efika
mware releases, and the Linux team will not have
the burden of maintaining tiny fixes for things which may always be fixed.
After all, there is no profit or benefit in fixing something 5 times just
in case the user only has 4 of them installed.
--
Matt S
Grant Likely wrote:
> On 1/9/08, Matt Sealey <[EMAIL PROTECTED]> wrote:
>> Please let's keep the nature of our firmware and the Linux codebase
>> independant, and move the burden of support to Genesi, and not the
>> Linux PowerPC team. After all, what is next, af
compile test code for it so I will not venture to submit a patch..
do we want to work on a comprehensive, required efika.forth release
that fixes these things together, or is it just my job for now?
--
Matt Sealey <[EMAIL PROTECTED]>
Genesi, Manager, Developer Relations
Grant Likely wrote:
&
Sven Luther wrote:
> On Wed, Jan 09, 2008 at 04:36:19PM +0000, Matt Sealey wrote:
>> The link that Olaf presented, www.powerdeveloper.org/asset/by-id/46 *is*
>> the upstream support for now. What his patch does is say, the upstream
>> support exists, but we don't like
Sven Luther wrote:
> On Wed, Jan 09, 2008 at 04:30:13PM +0000, Matt Sealey wrote:
>> Sven Luther wrote:
>>> Let's just fix this in the kernel, until we get a fixed efika firmware,
>>> then we can drop it easily enough. But until this happens, we need to be
>>
David Woodhouse wrote:
> On Wed, 2008-01-09 at 15:26 +0000, Matt Sealey wrote:
>> If anyone wants to help/assist/suggest any updates to efika.forth,
>> create binary tools which assist the installation of the script for
>> users and for placement on Linux distro CDs
rds and some ancient bad decision, and saying
"to use a new Efika you must use a brand new Linux kernel" is the kind of
insanity in embedded development which made us choose SmartFirmware over
U-Boot and FDT in the first place..
I am not happy that we are being dragged into this model of
kind of
tree standard I should be looking at, or some patch I missed which has
a driver which implements something that looks at a compatible tree?
--
Matt Sealey <[EMAIL PROTECTED]>
Genesi, Manager, Developer Relations
___
Linuxppc-dev mailin
On Thu, 2008-01-17 at 14:51 -0800, Andrew Morton wrote:
> > proc_loop: /proc/3731/task/3731/pagemap
> > kernel: BUG: sleeping function called from invalid context at
> > fs/proc/task_mmu.c:554
> > kernel: in_atomic():1, irqs_disabled():0
> > kernel: Call Trace:
> > kernel: [cf1cddf0] [c000840c] s
On Thu, 2008-01-17 at 16:05 -0800, Andrew Morton wrote:
> On Thu, 17 Jan 2008 17:39:54 -0600
> Matt Mackall <[EMAIL PROTECTED]> wrote:
>
> >
> > On Thu, 2008-01-17 at 14:51 -0800, Andrew Morton wrote:
> > > > proc_loop: /proc/3731/task/3731/pagemap
> &
On Thu, 2008-01-17 at 16:29 -0800, Andrew Morton wrote:
> Do we need `offset' at all?
Looks like no.
I wonder if there's a good argument for adding a pte_offset_val() which
would let us do:
pteval = pte_offset_val(pmd, addr);
and shrink the map/unmap window and overhead here and possibly
elsew
On Thu, 2008-01-17 at 17:07 -0800, Andrew Morton wrote:
> That worked out nicely.
Cool, feel free to add:
Signed-off-by: Matt Mackall <[EMAIL PROTECTED]>
> Wasn't the old code potentially pte_unmap()ping the wrong address? If we
> enter with addr==end?
Yes, that was bust
On Fri, 2008-01-18 at 18:23 +0100, Mariusz Kozlowski wrote:
> Hello,
>
> > > Do we need `offset' at all?
> >
> > Looks like no.
> >
> > I wonder if there's a good argument for adding a pte_offset_val() which
> > would let us do:
> >
> > pteval = pte_offset_val(pmd, addr);
> >
> > and shrink t
sitivity, but the stock ticker
thing was always a good idea.. it gives a sort of grounding in reality
for the manufacturer names.
Are we still following this convention or are the names of devices
simply arbitrarily defined by Linux kernel developers now?
--
Matt Sealey <[EMAIL PROTECTED]>
Genesi, Manager, Developer Relations
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
ler is target.
Right, the RapidIO subsystem itself has had the concept of multiple
master ports from the beginning. However, when I did the MPC85xx
support I chose to just implement it for the known silicon available
at the time. I'm not surprised there's new silicon with multiple
controllers now.
-Matt
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
ints
in a single RapidIO network fabric space. The reason one would do this
is to provide optimized paths to some endpoints in the system.
If possible, there should never be a policy assumption like this in
kernel space. It's much better to assume that one m
1 - 100 of 360 matches
Mail list logo
