unction instead of reaching deep into the structure
to grab the "of_node" property.
That said, in this case and probably a few others this is a driver for
an OF device so I'm still not sure this actually makes sense.
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
p,
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/
pr_info("%s(): freeing\n", __func__);
> ffs_data_clear(ffs);
> BUG_ON(waitqueue_active(&ffs->ev.waitq) ||
> - waitqueue_active(&ffs->ep0req_completion.wait) ||
> + swait_active(&am
evice 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/
Hi Christoph,
On Fri, Dec 29, 2017 at 7:18 PM, Christoph Hellwig 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.ca
_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/
.
>>
>> 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
Hi Michael,
On Mon, Jan 11, 2016 at 9:35 PM, Michael S. Tsirkin 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
>> > wrote:
&
ers = 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
Hi Nishanth,
On Wed, Oct 28, 2015 at 10:40 AM, Nishanth Aravamudan
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
>> wrote:
>> > On 26.10.2015 [18:27:46 -0700], Davi
at 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
Hi Christoph,
On Fri, Aug 14, 2015 at 12:35 AM, Christoph Hellwig 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
&
t 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
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 [] new_slab+0x30c/0x3c0
>
rderly_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
d.
> + *
> + * 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.ca
itted 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
, 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...@gma
7;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: jul
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 wrote:
> mb862xx: Restrict compliation of platform driver to PPC
>
> The OpenFirmware part of this driver is uncomp
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
21 matches
Mail list logo
