Re: [PATCH 1/5] crypto: sha256 - remove duplicate generic hash init function
Hi Tianjia,
On Mon, Dec 20, 2021 at 8:25 PM Tianjia Zhang
wrote:
>
> crypto_sha256_init() and sha256_base_init() are the same repeated
> implementations, remove the crypto_sha256_init() in generic
> implementation, sha224 is the same process.
>
> Signed-off-by: Tianjia Zhang
> ---
> crypto/sha256_generic.c | 16 ++--
> 1 file changed, 2 insertions(+), 14 deletions(-)
>
> diff --git a/crypto/sha256_generic.c b/crypto/sha256_generic.c
> index 3b377197236e..bf147b01e313 100644
> --- a/crypto/sha256_generic.c
> +++ b/crypto/sha256_generic.c
> @@ -72,7 +60,7 @@ EXPORT_SYMBOL(crypto_sha256_finup);
>
> static struct shash_alg sha256_algs[2] = { {
> .digestsize = SHA256_DIGEST_SIZE,
> - .init = crypto_sha256_init,
> + .init = sha256_base_init,
> .update = crypto_sha256_update,
> .final = crypto_sha256_final,
> .finup = crypto_sha256_finup,
> @@ -86,7 +74,7 @@ static struct shash_alg sha256_algs[2] = { {
> }
> }, {
> .digestsize = SHA224_DIGEST_SIZE,
> - .init = crypto_sha224_init,
> + .init = sha224_base_init,
> .update = crypto_sha256_update,
> .final = crypto_sha256_final,
> .finup = crypto_sha256_finup,
Aren't these two functions defined as static inline functions? It
appears that these crypto_ wrappers were added so there's "actual"
referenceable functions for these structs.
Did this actually compile?
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
Re: [patch V2 11/15] completion: Use simple wait queues
Hi Thomas,
On Thu, Mar 19, 2020 at 7:48 AM Thomas Gleixner wrote:
>
> From: Thomas Gleixner
>
> completion uses a wait_queue_head_t to enqueue waiters.
>
> wait_queue_head_t contains a spinlock_t to protect the list of waiters
> which excludes it from being used in truly atomic context on a PREEMPT_RT
> enabled kernel.
>
> The spinlock in the wait queue head cannot be replaced by a raw_spinlock
> because:
>
> - wait queues can have custom wakeup callbacks, which acquire other
> spinlock_t locks and have potentially long execution times
>
> - wake_up() walks an unbounded number of list entries during the wake up
> and may wake an unbounded number of waiters.
>
> For simplicity and performance reasons complete() should be usable on
> PREEMPT_RT enabled kernels.
>
> completions do not use custom wakeup callbacks and are usually single
> waiter, except for a few corner cases.
>
> Replace the wait queue in the completion with a simple wait queue (swait),
> which uses a raw_spinlock_t for protecting the waiter list and therefore is
> safe to use inside truly atomic regions on PREEMPT_RT.
>
> There is no semantical or functional change:
>
> - completions use the exclusive wait mode which is what swait provides
>
> - complete() wakes one exclusive waiter
>
> - complete_all() wakes all waiters while holding the lock which protects
> the wait queue against newly incoming waiters. The conversion to swait
> preserves this behaviour.
>
> complete_all() might cause unbound latencies with a large number of waiters
> being woken at once, but most complete_all() usage sites are either in
> testing or initialization code or have only a really small number of
> concurrent waiters which for now does not cause a latency problem. Keep it
> simple for now.
>
> The fixup of the warning check in the USB gadget driver is just a straight
> forward conversion of the lockless waiter check from one waitqueue type to
> the other.
>
> Signed-off-by: Thomas Gleixner
> Cc: Arnd Bergmann
> ---
> V2: Split out the orinoco and usb gadget parts and amended change log
> ---
> drivers/usb/gadget/function/f_fs.c |2 +-
> include/linux/completion.h |8
> kernel/sched/completion.c | 36
> +++-
> 3 files changed, 24 insertions(+), 22 deletions(-)
>
> --- a/drivers/usb/gadget/function/f_fs.c
> +++ b/drivers/usb/gadget/function/f_fs.c
> @@ -1703,7 +1703,7 @@ static void ffs_data_put(struct ffs_data
> pr_info("%s(): freeing\n", __func__);
> ffs_data_clear(ffs);
> BUG_ON(waitqueue_active(>ev.waitq) ||
> - waitqueue_active(>ep0req_completion.wait) ||
> + swait_active(>ep0req_completion.wait) ||
This looks like some code is reaching deep into the dirty dark corners
of the completion implementation, should there be some wrapper around
this to hide that?
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
Re: [PATCH 16/67] powerpc: rename dma_direct_ to dma_nommu_
Hi All, On Wed, Jan 3, 2018 at 6:49 PM, Geert Uytterhoeven <ge...@linux-m68k.org> wrote: > Hi Michael, > > On Wed, Jan 3, 2018 at 7:24 AM, Michael Ellerman <m...@ellerman.id.au> wrote: >> Geert Uytterhoeven <ge...@linux-m68k.org> writes: >> >>> On Tue, Jan 2, 2018 at 10:45 AM, Michael Ellerman <m...@ellerman.id.au> >>> wrote: >>>> Christoph Hellwig <h...@lst.de> writes: >>>> >>>>> We want to use the dma_direct_ namespace for a generic implementation, >>>>> so rename powerpc to the second best choice: dma_nommu_. >>>> >>>> I'm not a fan of "nommu". Some of the users of direct ops *are* using an >>>> IOMMU, they're just setting up a 1:1 mapping once at init time, rather >>>> than mapping dynamically. >>>> >>>> Though I don't have a good idea for a better name, maybe "1to1", >>>> "linear", "premapped" ? >>> >>> "identity"? >> >> I think that would be wrong, but thanks for trying to help :) >> >> The address on the device side is sometimes (often?) offset from the CPU >> address. So eg. the device can DMA to RAM address 0x0 using address >> 0x800. >> >> Identity would imply 0 == 0 etc. >> >> I think "bijective" is the correct term, but that's probably a bit >> esoteric. > > OK, didn't know about the offset. > Then "linear" is what we tend to use, right? If this is indeed a linear mapping, can we just remove this and replace it with the new "generic" mapping being introduced by this patchset? Thanks, -- Julian Calaby Email: julian.cal...@gmail.com Profile: http://www.google.com/profiles/julian.calaby/
Re: [PATCH 17/67] microblaze: rename dma_direct to dma_microblaze
Hi Christoph, On Fri, Dec 29, 2017 at 7:18 PM, Christoph Hellwig <h...@lst.de> wrote: > This frees the dma_direct_* namespace for a generic implementation. Don't you mean "dma_nommu" not "dma_microblaze" in the subject line? Thanks, -- Julian Calaby Email: julian.cal...@gmail.com Profile: http://www.google.com/profiles/julian.calaby/
Re: [PATCH 28/44] sparc: remove arch specific dma_supported implementations
Hi Christoph,
On Thu, Jun 8, 2017 at 11:25 PM, Christoph Hellwig <h...@lst.de> wrote:
> Usually dma_supported decisions are done by the dma_map_ops instance.
> Switch sparc to that model by providing a ->dma_supported instance for
> sbus that always returns false, and implementations tailored to the sun4u
> and sun4v cases for sparc64, and leave it unimplemented for PCI on
> sparc32, which means always supported.
>
> Signed-off-by: Christoph Hellwig <h...@lst.de>
> ---
> arch/sparc/include/asm/dma-mapping.h | 3 ---
> arch/sparc/kernel/iommu.c| 40
> +++-
> arch/sparc/kernel/ioport.c | 22 ++--
> arch/sparc/kernel/pci_sun4v.c| 17 +++
> 4 files changed, 39 insertions(+), 43 deletions(-)
>
> diff --git a/arch/sparc/kernel/ioport.c b/arch/sparc/kernel/ioport.c
> index dd081d557609..12894f259bea 100644
> --- a/arch/sparc/kernel/ioport.c
> +++ b/arch/sparc/kernel/ioport.c
> @@ -401,6 +401,11 @@ static void sbus_sync_sg_for_device(struct device *dev,
> struct scatterlist *sg,
> BUG();
> }
>
> +static int sbus_dma_supported(struct device *dev, u64 mask)
> +{
> + return 0;
> +}
> +
I'm guessing there's a few places that have DMA ops but DMA isn't
actually supported. Why not have a common method for this, maybe
"dma_not_supported"?
> static const struct dma_map_ops sbus_dma_ops = {
> .alloc = sbus_alloc_coherent,
> .free = sbus_free_coherent,
> @@ -410,6 +415,7 @@ static const struct dma_map_ops sbus_dma_ops = {
> .unmap_sg = sbus_unmap_sg,
> .sync_sg_for_cpu= sbus_sync_sg_for_cpu,
> .sync_sg_for_device = sbus_sync_sg_for_device,
> + .dma_supported = sbus_dma_supported,
> };
>
> static int __init sparc_register_ioport(void)
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
Re: [PATCH v4 0/3] checkpatch: handling of memory barriers
Hi Michael, On Mon, Jan 11, 2016 at 10:04 PM, Michael S. Tsirkin <m...@redhat.com> wrote: > On Mon, Jan 11, 2016 at 12:59:25PM +0200, Michael S. Tsirkin wrote: >> As part of memory barrier cleanup, this patchset >> extends checkpatch to make it easier to stop >> incorrect memory barrier usage. >> >> This replaces the checkpatch patches in my series >> arch: barrier cleanup + barriers for virt >> and will be included in the pull request including >> the series. >> >> changes from v3: >> rename smp_barrier_stems to barrier_stems >> as suggested by Julian Calaby. > > In fact it was Joe Perches that suggested it. > Sorry about the confusion. I was about to point that out. FWIW this entire series is: Acked-by: Julian Calaby <julian.cal...@gmail.com> Thanks, -- Julian Calaby Email: julian.cal...@gmail.com Profile: http://www.google.com/profiles/julian.calaby/ ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 3/3] checkpatch: add virt barriers
Hi Michael,
On Mon, Jan 11, 2016 at 9:35 PM, Michael S. Tsirkin <m...@redhat.com> wrote:
> On Sun, Jan 10, 2016 at 02:52:16PM -0800, Joe Perches wrote:
>> On Mon, 2016-01-11 at 09:13 +1100, Julian Calaby wrote:
>> > On Mon, Jan 11, 2016 at 6:31 AM, Michael S. Tsirkin <m...@redhat.com>
>> > wrote:
>> > > Add virt_ barriers to list of barriers to check for
>> > > presence of a comment.
>> []
>> > > diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
>> []
>> > > @@ -5133,7 +5133,8 @@ sub process {
>> > > }x;
>> > > my $all_barriers = qr{
>> > > $barriers|
>> > > - smp_(?:$smp_barrier_stems)
>> > > + smp_(?:$smp_barrier_stems)|
>> > > + virt_(?:$smp_barrier_stems)
>> >
>> > Sorry I'm late to the party here, but would it make sense to write this as:
>> >
>> > (?:smp|virt)_(?:$smp_barrier_stems)
>>
>> Yes. Perhaps the name might be better as barrier_stems.
>>
>> Also, ideally this would be longest match first or use \b
>> after the matches so that $all_barriers could work
>> successfully without a following \s*\(
>>
>> my $all_barriers = qr{
>> (?:smp|virt)_(?:barrier_stems)|
>> $barriers)
>> }x;
>>
>> or maybe add separate $smp_barriers and $virt_barriers
>>
>> it doesn't matter much in any case
>
> OK just to clarify - are you OK with merging the patch as is?
> Refactorings can come as patches on top if required.
I don't really care either way, I was just asking if it was possible.
If you don't see any value in that change, then don't make it.
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 3/3] checkpatch: add virt barriers
Hi Michael,
On Mon, Jan 11, 2016 at 6:31 AM, Michael S. Tsirkin <m...@redhat.com> wrote:
> Add virt_ barriers to list of barriers to check for
> presence of a comment.
>
> Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
> ---
> scripts/checkpatch.pl | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index 15cfca4..4466579 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -5133,7 +5133,8 @@ sub process {
> }x;
> my $all_barriers = qr{
> $barriers|
> - smp_(?:$smp_barrier_stems)
> + smp_(?:$smp_barrier_stems)|
> + virt_(?:$smp_barrier_stems)
Sorry I'm late to the party here, but would it make sense to write this as:
(?:smp|virt)_(?:$smp_barrier_stems)
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/5 v3] Fix NVMe driver support on Power with 32-bit DMA
Hi Nishanth, On Wed, Oct 28, 2015 at 9:20 AM, Nishanth Aravamudan <n...@linux.vnet.ibm.com> wrote: > On 26.10.2015 [18:27:46 -0700], David Miller wrote: >> From: Nishanth Aravamudan <n...@linux.vnet.ibm.com> >> Date: Fri, 23 Oct 2015 13:54:20 -0700 >> >> > 1) add a generic dma_get_page_shift implementation that just returns >> > PAGE_SHIFT >> >> I won't object to this patch series, but if I had implemented this I >> would have required the architectures to implement this explicitly, >> one-by-one. I think it is less error prone and more likely to end >> up with all the architectures setting this correctly. > > Well, looks like I should spin up a v4 anyways for the powerpc changes. > So, to make sure I understand your point, should I make the generic > dma_get_page_shift a compile-error kind of thing? It will only fail on > architectures that actually build the NVME driver (as the only caller). > But I'm not sure how exactly to achieve that, if you could give a bit > more detail I'd appreciate it! He's suggesting that you _don't_ put a generic implementation in /include/linux/dma-mapping.h and instead add it to _every_ architecture. Thanks, -- Julian Calaby Email: julian.cal...@gmail.com Profile: http://www.google.com/profiles/julian.calaby/ ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/5 v3] Fix NVMe driver support on Power with 32-bit DMA
Hi Nishanth, On Wed, Oct 28, 2015 at 10:40 AM, Nishanth Aravamudan <n...@linux.vnet.ibm.com> wrote: > On 28.10.2015 [09:57:48 +1100], Julian Calaby wrote: >> Hi Nishanth, >> >> On Wed, Oct 28, 2015 at 9:20 AM, Nishanth Aravamudan >> <n...@linux.vnet.ibm.com> wrote: >> > On 26.10.2015 [18:27:46 -0700], David Miller wrote: >> >> From: Nishanth Aravamudan <n...@linux.vnet.ibm.com> >> >> Date: Fri, 23 Oct 2015 13:54:20 -0700 >> >> >> >> > 1) add a generic dma_get_page_shift implementation that just returns >> >> > PAGE_SHIFT >> >> >> >> I won't object to this patch series, but if I had implemented this I >> >> would have required the architectures to implement this explicitly, >> >> one-by-one. I think it is less error prone and more likely to end >> >> up with all the architectures setting this correctly. >> > >> > Well, looks like I should spin up a v4 anyways for the powerpc changes. >> > So, to make sure I understand your point, should I make the generic >> > dma_get_page_shift a compile-error kind of thing? It will only fail on >> > architectures that actually build the NVME driver (as the only caller). >> > But I'm not sure how exactly to achieve that, if you could give a bit >> > more detail I'd appreciate it! >> >> He's suggesting that you _don't_ put a generic implementation in >> /include/linux/dma-mapping.h and instead add it to _every_ >> architecture. > > Ah, I see! Well, I don't know much about the DMA internals of most > architectures -- and my approach kept things functionally the same > everywhere (using PAGE_SHIFT) except: > > a) Power, where I know it doesn't work as-is > and > b) sparc, where the code implied that a different value than PAGE_SHIFT > should be used. You'll be CCing the maintainers of each architecture on the patches to add the functions, so if they do have specific requirements, I'm sure they'll let you know or provide patches. Thanks, -- Julian Calaby Email: julian.cal...@gmail.com Profile: http://www.google.com/profiles/julian.calaby/ ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: RFC: prepare for struct scatterlist entries without page backing
Hi Christoph, On Fri, Aug 14, 2015 at 12:35 AM, Christoph Hellwig h...@lst.de wrote: On Thu, Aug 13, 2015 at 09:37:37AM +1000, Julian Calaby wrote: I.e. ~90% of this patch set seems to be just mechanically dropping BUG_ON()s and converting open coded stuff to use accessor functions (which should be macros or get inlined, right?) - and the remaining bit is not flushing if we don't have a physical page somewhere. Which is was 90%. By lines changed most actually is the diffs for the cache flushing. I was talking in terms of changes made, not lines changed: by my recollection, about a third of the patches didn't touch flush calls and most of the lines changed looked like refactoring so that making the flush call conditional would be easier. I guess it smelled like you were doing lots of distinct changes in a single patch and I got my numbers wrong. Would it make sense to split this patch set into a few bits: one to drop all the useless BUG_ON()s, one to convert all the open coded stuff to accessor functions, then another to do the actual page-less sg stuff? Without the ifs the BUG_ON() actually are useful to assert we never feed the sort of physical addresses we can't otherwise support, so I don't think that part is doable. My point is that there's a couple of patches that only remove BUG_ON()s, which implies that for that particular driver it doesn't matter if there's a physical page or not, so therefore that code is purely documentation. Thanks, -- Julian Calaby Email: julian.cal...@gmail.com Profile: http://www.google.com/profiles/julian.calaby/ ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: RFC: prepare for struct scatterlist entries without page backing
Hi, On Wed, Aug 12, 2015 at 10:42 PM, Boaz Harrosh b...@plexistor.com wrote: On 08/12/2015 10:05 AM, Christoph Hellwig wrote: It turns out most DMA mapping implementation can handle SGLs without page structures with some fairly simple mechanical work. Most of it is just about consistently using sg_phys. For implementations that need to flush caches we need a new helper that skips these cache flushes if a entry doesn't have a kernel virtual address. However the ccio (parisc) and sba_iommu (parisc ia64) IOMMUs seem to be operate mostly on virtual addresses. It's a fairly odd concept that I don't fully grasp, so I'll need some help with those if we want to bring this forward. Additional this series skips ARM entirely for now. The reason is that most arm implementations of the .map_sg operation just iterate over all entries and call -map_page for it, which means we'd need to convert those to a -map_pfn similar to Dan's previous approach. [snip] It is a bit of work but is worth while, and accelerating tremendously lots of workloads. Not like this abomination which only branches things more and more, and making things fatter and slower. As a random guy reading a big bunch of patches on code I know almost nothing about, parts of this comment really resonated with me: overall, we seem to be adding a lot of if statements to code that appears to be in a hot path. I.e. ~90% of this patch set seems to be just mechanically dropping BUG_ON()s and converting open coded stuff to use accessor functions (which should be macros or get inlined, right?) - and the remaining bit is not flushing if we don't have a physical page somewhere. Would it make sense to split this patch set into a few bits: one to drop all the useless BUG_ON()s, one to convert all the open coded stuff to accessor functions, then another to do the actual page-less sg stuff? Thanks, -- Julian Calaby Email: julian.cal...@gmail.com Profile: http://www.google.com/profiles/julian.calaby/ ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] of: return NUMA_NO_NODE from fallback of_node_to_nid()
Hi Konstantin, On Thu, Apr 9, 2015 at 3:04 AM, Konstantin Khlebnikov khlebni...@yandex-team.ru wrote: On 08.04.2015 19:59, Konstantin Khlebnikov wrote: Node 0 might be offline as well as any other numa node, in this case kernel cannot handle memory allocation and crashes. Example: [0.027133] [ cut here ] [0.027938] kernel BUG at include/linux/gfp.h:322! [0.028000] invalid opcode: [#1] SMP [0.028000] Modules linked in: [0.028000] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.0.0-rc7 #12 [0.028000] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.7.5.1-0-g8936dbb-20141113_115728-nilsson.home.kraxel.org 04/01/2014 [0.028000] task: 88007d3f8000 ti: 88007d3dc000 task.ti: 88007d3dc000 [0.028000] RIP: 0010:[8118574c] [8118574c] new_slab+0x30c/0x3c0 [0.028000] RSP: :88007d3dfc28 EFLAGS: 00010246 [0.028000] RAX: RBX: 88007d001800 RCX: 0001 [0.028000] RDX: RSI: RDI: 002012d0 [0.028000] RBP: 88007d3dfc58 R08: R09: [0.028000] R10: 0001 R11: 88007d02fe40 R12: 00d0 [0.028000] R13: 00c0 R14: 0015 R15: [0.028000] FS: () GS:88007fc0() knlGS: [0.028000] CS: 0010 DS: ES: CR0: 8005003b [0.028000] CR2: CR3: 01e0e000 CR4: 06f0 [0.028000] DR0: DR1: DR2: [0.028000] DR3: DR6: fffe0ff0 DR7: 0400 [0.028000] Stack: [0.028000] 88007fc175d0 ea0001f40bc0 00c0 [0.028000] 88007d001800 80d0 88007d3dfd48 8192da27 [0.028000] 000d 81e27038 [0.028000] Call Trace: [0.028000] [8192da27] __slab_alloc+0x3df/0x55d [0.028000] [8109a92b] ? __lock_acquire+0xc1b/0x1f40 [0.028000] [810b1f2c] ? __irq_domain_add+0x3c/0xe0 [0.028000] [810998f5] ? trace_hardirqs_on_caller+0x105/0x1d0 [0.028000] [813631ab] ? trace_hardirqs_on_thunk+0x3a/0x3f [0.028000] [811890ab] __kmalloc_node+0xab/0x210 [0.028000] [810394df] ? ioapic_read_entry+0x1f/0x50 [0.028000] [810b1f2c] ? __irq_domain_add+0x3c/0xe0 [0.028000] [810b1f2c] __irq_domain_add+0x3c/0xe0 [0.028000] [81039e0e] mp_irqdomain_create+0x9e/0x120 [0.028000] [81f22d49] setup_IO_APIC+0x6b/0x798 [0.028000] [810398a5] ? clear_IO_APIC+0x45/0x70 [0.028000] [81f21f01] apic_bsp_setup+0x87/0x96 [0.028000] [81f1fdb4] native_smp_prepare_cpus+0x237/0x275 [0.028000] [81f131b7] kernel_init_freeable+0x120/0x265 [0.028000] [819271f9] ? kernel_init+0x9/0xf0 [0.028000] [819271f0] ? rest_init+0x130/0x130 [0.028000] [819271f9] kernel_init+0x9/0xf0 [0.028000] [8193b958] ret_from_fork+0x58/0x90 [0.028000] [819271f0] ? rest_init+0x130/0x130 [0.028000] Code: 6b b6 ff ff 49 89 c5 e9 ce fd ff ff 31 c0 90 e9 74 ff ff ff 49 c7 04 04 00 00 00 00 e9 05 ff ff ff 4c 89 e7 ff d0 e9 d9 fe ff ff 0f 0b 4c 8b 73 38 44 89 e7 81 cf 00 00 20 00 4c 89 f6 48 c1 ee [0.028000] RIP [8118574c] new_slab+0x30c/0x3c0 [0.028000] RSP 88007d3dfc28 [0.028039] ---[ end trace f03690e70d7e4be6 ]--- Shouldn't this be in the commit message? Thanks, -- Julian Calaby Email: julian.cal...@gmail.com Profile: http://www.google.com/profiles/julian.calaby/ ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 2/3] kernel/reboot.c: Add orderly_reboot for graceful reboot
Hi Joel, On Wed, Apr 1, 2015 at 6:04 PM, Joel Stanley j...@jms.id.au wrote: The kernel has orderly_poweroff which allows the kernel to initiate a graceful shutdown of userspace, by running /sbin/poweroff. This adds orderly_reboot that will cause userspace to shut itself down by calling /sbin/reboot. This will be used for shutdown initiated by a system controller on platforms that do not use ACPI. orderly_reboot() should be used when the system wants to allow userspace to gracefully shut itself down. For cases where the system may imminently catch on fire, the existing emergency_restart() provides an immediate reboot without involving userspace. Signed-off-by: Joel Stanley j...@jms.id.au --- V2: - remove unused return value from orderly_* - use correct command in orderly_poweroff - the reboot command will not have a proc knob to control it, so it can be made const and static include/linux/reboot.h | 3 ++- kernel/reboot.c| 53 +- 2 files changed, 50 insertions(+), 6 deletions(-) diff --git a/include/linux/reboot.h b/include/linux/reboot.h index 48bf152..dc5e3bd 100644 --- a/include/linux/reboot.h +++ b/include/linux/reboot.h @@ -67,7 +67,8 @@ void ctrl_alt_del(void); #define POWEROFF_CMD_PATH_LEN 256 extern char poweroff_cmd[POWEROFF_CMD_PATH_LEN]; -extern int orderly_poweroff(bool force); +extern void orderly_poweroff(bool force); Should making orderly_poweroff() void be in a separate patch? Thanks, -- Julian Calaby Email: julian.cal...@gmail.com Profile: http://www.google.com/profiles/julian.calaby/ ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [BUG Fix Patch 1/6] Bug fix: Hold spinlock across find|remove /sys/firmware/memmap/X operation.
Hi Tang, One minor point. On Tue, Jan 15, 2013 at 9:54 PM, Tang Chen tangc...@cn.fujitsu.com wrote: It is unsafe to return an entry pointer and release the map_entries_lock. So we should not hold the map_entries_lock separately in firmware_map_find_entry() and firmware_map_remove_entry(). Hold the map_entries_lock across find and remove /sys/firmware/memmap/X operation. And also, users of these two functions need to be careful to hold the lock when using these two functions. The suggestion is from Andrew Morton a...@linux-foundation.org Signed-off-by: Tang Chen tangc...@cn.fujitsu.com --- drivers/firmware/memmap.c | 25 + 1 files changed, 17 insertions(+), 8 deletions(-) diff --git a/drivers/firmware/memmap.c b/drivers/firmware/memmap.c index 4211da5..940c4e9 100644 --- a/drivers/firmware/memmap.c +++ b/drivers/firmware/memmap.c @@ -188,23 +188,28 @@ static inline void remove_sysfs_fw_map_entry(struct firmware_map_entry *entry) } /* - * Search memmap entry + * firmware_map_find_entry: Search memmap entry. + * @start: Start of the memory range. + * @end: End of the memory range (exclusive). + * @type: Type of the memory range. + * + * This function is to find the memmap entey of a given memory range. + * The caller must hold map_entries_lock, and must not release the lock + * until the processing of the returned entry has completed. + * + * Return pointer to the entry to be found on success, or NULL on failure. Why not make this completely kernel-doc compliant as you're already re-writing the comment? Thanks, -- Julian Calaby Email: julian.cal...@gmail.com Profile: http://www.google.com/profiles/julian.calaby/ .Plan: http://sites.google.com/site/juliancalaby/ ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 00/12] Merge common OpenFirmware device tree code
On Wed, Oct 7, 2009 at 14:49, Grant Likely grant.lik...@secretlab.ca wrote: On Tue, Oct 6, 2009 at 10:29 PM, Grant Likely grant.lik...@secretlab.ca wrote: So here goes. I've begun the work to merge and clean up the OF device tree handling code and this is my first set of patches. Not fully tested yet, but I'm getting them out to the lists so that I can start responding to comments and collecting acks. This first batch isn't anything exciting, just a merge of common code Good work, for what it's worth, this all looks good to me. However, I've completely devoted to this work for at least the next two months, so there are plenty more patches to follow. Once I've got all the common code merged between Microblaze, PowerPC and Sparc I'll be fix the endian problems and making it easily usable by other architectures like ARM and MIPS. Lots of work to be done. On the subject of merging code, I know that the SUN3 code in m68k uses a similar prom interface to the sparc32 code. (and I've also considered unifying that and ... well ... see above) Does anyone know if it has an OpenFirmware interface for it's devices? Is OF on SUN3 even remotely useful? Does Linux on SUN3 even work with modern kernels? Another issue is that there is at least one driver in the kernel that depends on both PPC and OF to work around the differences in the implementations of OpenFirmware on Sparc and PowerPC. (I submitted a patch for it, but can't remember the driver's name) Whilst the driver's author assures me that the hardware will never go anywhere near Sparc, it can't hurt to drop the dependency on PPC for additional compile testing coverage - and because it's the Right Thing. (and the reduction of cheap hacks like this can't be bad either.) Other than that, good work, and keep going. Thanks, -- Julian Calaby Email: julian.cal...@gmail.com .Plan: http://sites.google.com/site/juliancalaby/ ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: leds: Add openfirmware platform device support breaks sparc
On Wed, Mar 4, 2009 at 11:29, Sean MacLennan smaclen...@pikatech.com wrote: On Tue, 3 Mar 2009 16:09:06 -0800 Andrew Morton a...@linux-foundation.org wrote: afacit that interface is powerpc-only. Yes it is. You might want a CONFIG_PPC with that. It has been. u carry the two... longer than I want to admit since I worked on a sparc. Would GPIO based LEDS make sense on a sparc platform? Is sparc used much in the embedded world? If yes, the of_register_platform_driver is just a nice wrapper. It would be trivial to either change it to work on sparc, or add the wrapper to the sparc includes. These inconsistencies are causing more problems with PPC drivers depending on the generic infrastructure. See: http://lkml.org/lkml/2009/1/11/376 for a similar issue. Thanks, -- Julian Calaby Email: julian.cal...@gmail.com .Plan: http://sites.google.com/site/juliancalaby/ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] mb862xx: Restrict compliation of platform driver to PPC
Ping? Does anyone maintain this driver? (akpm: Sorry for cc'ing you on this, I'm not sure who else to send it to) On Mon, Jan 12, 2009 at 11:06, Julian Calaby julian.cal...@gmail.com wrote: mb862xx: Restrict compliation of platform driver to PPC The OpenFirmware part of this driver is uncompilable on SPARC due to it's dependance on several PPC specific functions. Restricting this to PPC to prevent these build errors. This was found using randconfig builds. Signed-off-by: Julian Calaby julian.cal...@gmail.com --- A couple of notes: 1. After looking at the includes used by this driver, the OF part may not compile cleanly on PPC either as it doesn't appear to pull in the required headers for all the functions and constants it uses. 2. Also, this bug will *not* show up in allmodconfigs or allyesconfigs as the OF part of this driver is prevented from building when the PCI driver is built, and the PCI driver appears first. 3. This patch is over DaveM's sparc-2.6 git tree as of today. 4. I apologise for the massive cross-posting - I am not sure where exactly to send this patch. 5. Please note that I am not a member of any of these lists, so please keep me CC'd. Thanks, Julian Calaby --- drivers/video/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig index 6372f8b..8f18169 100644 --- a/drivers/video/Kconfig +++ b/drivers/video/Kconfig @@ -2111,6 +2111,7 @@ config FB_MB862XX_LIME bool Lime GDC depends on FB_MB862XX depends on OF !FB_MB862XX_PCI_GDC + depends on PPC select FB_FOREIGN_ENDIAN select FB_LITTLE_ENDIAN ---help--- -- Julian Calaby Email: julian.cal...@gmail.com .Plan: https://sites.google.com/site/juliancalaby/ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] mb862xx: Restrict compliation of platform driver to PPC
On Tue, Jan 20, 2009 at 12:19, Anton Vorontsov avoront...@ru.mvista.com wrote: Should be Anatolij. ;-) Who is the first person on the list, I guess he's missed this or isn't reading his email. But I'm interested in this driver as well. FWIW, the patch looks OK, except for the long lines in the commit log. I don't expect this to be applied as is. There is a better fix out there, but I don't know the hardware so I'm not sure what it is. Also you'd better mention exact build error in the commit log. Essentially it's a huge list of missing definitions for functions which aren't defined for SPARC. I'll reply with it if you really want it, however they look to be PPC specific. If they were generic I would have simply included the correct files so that it compiled, rather than this nasty hack. It also appears that these functions are not defined in the headers that this driver includes. (Btw, we'd better fix the build for sparc instead of adding another depends on. Could anybody point to some recent, working sparc cross toolchain? Last time I googled for it I found only some prehistoric versions that I didn't bother to try...) Before we commit to fixing this properly, is it really worth it? Is this hardware ever likely to be used with SPARC? Given that there are PCI and OF versions of the driver, it seems to me that this is available as a PCI expansion card, and as a graphics chip built into some PPC motherboards. The initial commit says: Lime GDC support is known to work on PPC440EPx based lwmon5 and MPC8544E based socrates embedded boards, both equipped with Lime GDC. so I'm guessing that this graphics chip is designed for embedded boards. I can find references to it's use in embedded automotive applications on Google but I can't find any reference to the Fujitsu LIME (MB86276) and SPARC on Google. Note that the PCI version of this driver compiles fine with both allyesconfig and allmodconfig. If you're sure you want to do this, I'd check out crosstool for a SPARC cross-complier. Two other things: 1. SPARC32 and SPARC64 can be compiled with the same compiler. 2. These two platforms have slightly different OpenFirmware interfaces - so fixing it for both of these will be a pain. Thanks, -- Julian Calaby Email: julian.cal...@gmail.com .Plan: https://sites.google.com/site/juliancalaby/ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] mb862xx: Restrict compliation of platform driver to PPC
mb862xx: Restrict compliation of platform driver to PPC The OpenFirmware part of this driver is uncompilable on SPARC due to it's dependance on several PPC specific functions. Restricting this to PPC to prevent these build errors. This was found using randconfig builds. Signed-off-by: Julian Calaby julian.cal...@gmail.com --- A couple of notes: 1. After looking at the includes used by this driver, the OF part may not compile cleanly on PPC either as it doesn't appear to pull in the required headers for all the functions and constants it uses. 2. Also, this bug will *not* show up in allmodconfigs or allyesconfigs as the OF part of this driver is prevented from building when the PCI driver is built, and the PCI driver appears first. 3. This patch is over DaveM's sparc-2.6 git tree as of today. 4. I apologise for the massive cross-posting - I am not sure where exactly to send this patch. 5. Please note that I am not a member of any of these lists, so please keep me CC'd. Thanks, Julian Calaby --- drivers/video/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig index 6372f8b..8f18169 100644 --- a/drivers/video/Kconfig +++ b/drivers/video/Kconfig @@ -2111,6 +2111,7 @@ config FB_MB862XX_LIME bool Lime GDC depends on FB_MB862XX depends on OF !FB_MB862XX_PCI_GDC + depends on PPC select FB_FOREIGN_ENDIAN select FB_LITTLE_ENDIAN ---help--- ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
