Re: [PATCH 1/2] powerpc: export ppc_tb_freq so that modules can reference it
On Sep 18, 2010, at 9:36 AM, Tabi Timur-B04825 wrote: On Sep 17, 2010, at 10:14 PM, Benjamin Herrenschmidt b...@kernel.crashing.org wrote: On Fri, 2010-09-17 at 20:20 -0500, Timur Tabi wrote: I don't see any reason to limit it to GPL drivers. Not only that, but then we'll have this: I do Can you elaborate on that, or are you just going to pull rank on me? EXPORT_SYMBOL(ppc_proc_freq); EXPORT_SYMBOL_GPL(ppc_tb_freq); That just looks dumb. Right, so send a patch to fix the first one too :-) I don't think either of these should be EXPORT_SYMBOL_GPL. Why shouldn't a binary module be allowed to know these frequencies? My view is why preclude anyone from using this how they want. If they want to live in the gray area so be it. Who am I to say they shouldn't have that choice. Then why doesn't someone post a patch to change all EXPORT_SYMBOL to EXPORT_SYMBOL_GPL? And why do we consider EXPORT_SYMBOL to be broken? I'm not trying to be a troll, but I see a lot of inconsistency with respect to EXPORT_SYMBOL and EXPORT_SYMBOL_GPL. I'm in agreement with the lack of clarity, it seems to be developer whim. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] powerpc: export ppc_tb_freq so that modules can reference it
On Sat, Sep 18, 2010 at 5:34 PM, Kumar Gala kumar.g...@freescale.com wrote: I don't think either of these should be EXPORT_SYMBOL_GPL. Why shouldn't a binary module be allowed to know these frequencies? My view is why preclude anyone from using this how they want. If they want to live in the gray area so be it. Who am I to say they shouldn't have that choice. W00t, binary modules again... No, please. No binary modules in kernelspace. Thanks, Vitaly ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] powerpc: export ppc_tb_freq so that modules can reference it
On Sat, Sep 18, 2010 at 11:34 AM, Kumar Gala kumar.g...@freescale.com wrote: On Sep 18, 2010, at 9:36 AM, Tabi Timur-B04825 wrote: On Sep 17, 2010, at 10:14 PM, Benjamin Herrenschmidt b...@kernel.crashing.org wrote: On Fri, 2010-09-17 at 20:20 -0500, Timur Tabi wrote: I don't see any reason to limit it to GPL drivers. Not only that, but then we'll have this: I do Can you elaborate on that, or are you just going to pull rank on me? EXPORT_SYMBOL(ppc_proc_freq); EXPORT_SYMBOL_GPL(ppc_tb_freq); That just looks dumb. Right, so send a patch to fix the first one too :-) I don't think either of these should be EXPORT_SYMBOL_GPL. Why shouldn't a binary module be allowed to know these frequencies? My view is why preclude anyone from using this how they want. If they want to live in the gray area so be it. Who am I to say they shouldn't have that choice. It is not, in my opinion, about what is technically possible and what isn't. The kernel is licensed under the GPL. This is a Linux kernel only symbol. One would be hard pressed to claim they have a driver that wasn't written for Linux that happens to need that symbol. As a member of the Linux kernel community, I find it important to encourage the contribution of code back to the kernel, and this is one way to help that. This isn't BSD. Besides, a developer is free to export it however they wish in their own kernel tree. They can deviate from mainline if they so choose. josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] powerpc: export ppc_tb_freq so that modules can reference it
On Sat, Sep 18, 2010 at 1:36 PM, Tabi Timur-B04825 b04...@freescale.com wrote: Josh Boyer wrote: It is not, in my opinion, about what is technically possible and what isn't. The kernel is licensed under the GPL. This is a Linux kernel only symbol. One would be hard pressed to claim they have a driver that wasn't written for Linux that happens to need that symbol. As a member of the Linux kernel community, I find it important to encourage the contribution of code back to the kernel, and this is one way to help that. This isn't BSD. Fine, but this goes back to my original question -- if this is how the community feels, then why hasn't someone posted a patch that converts all EXPORT_SYMBOL into EXPORT_SYMBOL_GPL? Because of history in a lot of cases, and like all communities, opinions vary. I did say this was my opinion, not a mandate of some sort. Either we allow non-GPL drivers, or we don't. If we don't, then we need to eliminate EXPORT_SYMBOL once and for all. Otherwise, the message is hypocritical. I'd be all for it. I don't think it is as black and white as that though, as nothing rarely is. (we can't even get all the code to adhere to the 80 column rule ). I also don't think it is necessarily hypocritical. This is a new symbol being exported, not one that has been exported for years. josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] powerpc: export ppc_tb_freq so that modules can reference it
On Sat, Sep 18, 2010 at 1:55 PM, Tabi Timur-B04825 b04...@freescale.com wrote: Josh Boyer wrote: This is a new symbol being exported, not one that has been exported for years. Except that Ben says that I should change ppc_proc_freq from EXPORT_SYMBOL to EXPORT_SYMBOL_GPL as well. In a sense, we're in a catch-22. We have three choices: 1. We *arbitrarily* change ppc_proc_freq from EXPORT_SYMBOL to EXPORT_SYMBOL_GPL, so that the two symbols are exported the same way 2. We GPL-export only ppc_tb_freq and leave ppc_proc_freq as-is, but then it looks dumb. I dunno. I don't think it looks dumb. It could mean nothing more than we were paying closer attention this time. 3. We export ppc_tb_freq the same way we're exporting ppc_proc_freq, providing the most options and maintaining consistency. I just don't see how options #1 or #2 are better than #3, and so far the only explanations I've heard are along the lines of we just like it that way. Now I think I've been a bit more detailed than that. I at least explained why I prefer it that way. If you disagree, that's fine but don't make me sound like some kind of petulant child. Obviously, Linus thinks it's okay to allow some non-GPL modules, otherwise he would have long ago changed all EXPORT_SYMBOLs to EXPORT_SYMBOL_GPL. I'm just capitalizing on that mindset. Capitalizing? The patch you posted that uses this symbol is for a GPL driver so you gain or lose nothing by having this symbol be EXPORT_SYMBOL_GPL. Are you somehow advocating and getting some sort of gain by allowing non-GPL modules? If so, I find that unfortunate. If not, then I guess I don't understand what you mean by capitalizing. josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] powerpc: export ppc_tb_freq so that modules can reference it
On Sep 18, 2010, at 11:56 AM, Josh Boyer wrote: On Sat, Sep 18, 2010 at 11:34 AM, Kumar Gala kumar.g...@freescale.com wrote: On Sep 18, 2010, at 9:36 AM, Tabi Timur-B04825 wrote: On Sep 17, 2010, at 10:14 PM, Benjamin Herrenschmidt b...@kernel.crashing.org wrote: On Fri, 2010-09-17 at 20:20 -0500, Timur Tabi wrote: I don't see any reason to limit it to GPL drivers. Not only that, but then we'll have this: I do Can you elaborate on that, or are you just going to pull rank on me? EXPORT_SYMBOL(ppc_proc_freq); EXPORT_SYMBOL_GPL(ppc_tb_freq); That just looks dumb. Right, so send a patch to fix the first one too :-) I don't think either of these should be EXPORT_SYMBOL_GPL. Why shouldn't a binary module be allowed to know these frequencies? My view is why preclude anyone from using this how they want. If they want to live in the gray area so be it. Who am I to say they shouldn't have that choice. It is not, in my opinion, about what is technically possible and what isn't. The kernel is licensed under the GPL. This is a Linux kernel only symbol. One would be hard pressed to claim they have a driver that wasn't written for Linux that happens to need that symbol. As a member of the Linux kernel community, I find it important to encourage the contribution of code back to the kernel, and this is one way to help that. This isn't BSD. Besides, a developer is free to export it however they wish in their own kernel tree. They can deviate from mainline if they so choose. I'll buy this argument as a reason to make both EXPORT_SYMBOL_GPL. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] PPC4xx: Generelizing drivers/dma/ppc4xx/adma.c
Dear tma...@apm.com, In message 1284774145-14543-1-git-send-email-tma...@apm.com you wrote: This patch generalizes the existing drver/dma/ppc4xx/adma.c, so that common code can be shared between different similar DMA engine drivers in other SoCs. ... * This driver supports the asynchrounous DMA copy and RAID engines available - * on the AMCC PPC440SPe Processors. + * on the AMCC PPC4XX Processors. Will this driver ever include any 40x processors? If not, you probably should use 44x instead (here and everywhere in the rest of the code). diff --git a/drivers/dma/ppc4xx/ppc4xx-adma.h b/drivers/dma/ppc4xx/ppc4xx-adma.h new file mode 100644 index 000..7457237 --- /dev/null +++ b/drivers/dma/ppc4xx/ppc4xx-adma.h ... +#include linux/of.h +#include linux/of_platform.h +#include asm/dcr.h +#include asm/dcr-regs.h +#include adma.h +#include ppc440spe-dma.h + +/* Default polynomial (for 440SP is only available) */ +#define PPC4XX_DEFAULT_POLY 0x4d Should this go into ppc440spe-dma.h? +/* The list of channels exported by ppc440spe ADMA */ +struct list_head + ppc4xx_adma_chan_list = LIST_HEAD_INIT(ppc4xx_adma_chan_list); + +/* This flag is set when want to refetch the xor chain in the interrupt + * handler + */ +static u32 do_xor_refetch; + +/* Pointer to DMA0, DMA1 CP/CS FIFO */ +static void *ppc440spe_dma_fifo_buf; Seems this should go into ppc440spe-dma.h? +/* This array is used in data-check operations for storing a pattern */ +static char ppc440spe_qword[16]; + +static atomic_t ppc4xx_adma_err_irq_ref; +static dcr_host_t ppc440spe_mq_dcr_host; +static unsigned int ppc440spe_mq_dcr_len; Ditto? +static unsigned long ppc440spe_rxor_state; + +static struct page *ppc440spe_rxor_srcs[32]; And here again - please check globally! +/** + * ppc440spe_can_rxor - check if the operands may be processed with RXOR + */ +static int ppc440spe_can_rxor(struct page **srcs, int src_cnt, size_t len) Again, should this then not be in ppc440spe specific files? It seems the split / generalization is highly incomplete yet. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de What can it profit a man to gain the whole world and to come to his property with a gastric ulcer, a blown prostate, and bifocals? -- John Steinbeck, _Cannery Row_ ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] PPC4xx: Merge xor.h and dma.h into onefile ppc440spe-dma.h
Dear tma...@apm.com, In message 1284774162-14652-1-git-send-email-tma...@apm.com you wrote: From: Tirumala Marri tma...@apm.com This patch combines drivers/dma/ppc4xx/xor.h and driver/dma/dma/ppc4xx/dma.h into drivers/dma/ppc4xx/ppx440spe-dma.h . Signed-off-by: Tirumala R Marri tma...@apm.com --- drivers/dma/ppc4xx/dma.h | 223 - drivers/dma/ppc4xx/ppc440spe-dma.h | 318 drivers/dma/ppc4xx/xor.h | 110 - 3 files changed, 318 insertions(+), 333 deletions(-) Please use -M with git format-patch so it detects renames (here we should probably see a rename from dma.h into ppc440spe-dma.h [plus some changes]) instead of a remove plus add file. That would make it much easier to review your changes. Thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de It's a small world, but I wouldn't want to paint it. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] powerpc: export ppc_tb_freq so that modules can reference it
Josh Boyer wrote: It is not, in my opinion, about what is technically possible and what isn't. The kernel is licensed under the GPL. This is a Linux kernel only symbol. One would be hard pressed to claim they have a driver that wasn't written for Linux that happens to need that symbol. As a member of the Linux kernel community, I find it important to encourage the contribution of code back to the kernel, and this is one way to help that. This isn't BSD. Fine, but this goes back to my original question -- if this is how the community feels, then why hasn't someone posted a patch that converts all EXPORT_SYMBOL into EXPORT_SYMBOL_GPL? Either we allow non-GPL drivers, or we don't. If we don't, then we need to eliminate EXPORT_SYMBOL once and for all. Otherwise, the message is hypocritical. -- Timur Tabi Linux kernel developer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] powerpc: export ppc_tb_freq so that modules can reference it
Josh Boyer wrote: This is a new symbol being exported, not one that has been exported for years. Except that Ben says that I should change ppc_proc_freq from EXPORT_SYMBOL to EXPORT_SYMBOL_GPL as well. In a sense, we're in a catch-22. We have three choices: 1. We *arbitrarily* change ppc_proc_freq from EXPORT_SYMBOL to EXPORT_SYMBOL_GPL, so that the two symbols are exported the same way 2. We GPL-export only ppc_tb_freq and leave ppc_proc_freq as-is, but then it looks dumb. 3. We export ppc_tb_freq the same way we're exporting ppc_proc_freq, providing the most options and maintaining consistency. I just don't see how options #1 or #2 are better than #3, and so far the only explanations I've heard are along the lines of we just like it that way. Obviously, Linus thinks it's okay to allow some non-GPL modules, otherwise he would have long ago changed all EXPORT_SYMBOLs to EXPORT_SYMBOL_GPL. I'm just capitalizing on that mindset. -- Timur Tabi Linux kernel developer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Generating elf kernel ?
Scott Wood wrote: On Fri, 17 Sep 2010 09:58:41 +0800 tiejun.chen tiejun.c...@windriver.com wrote: Scott Wood wrote: The guest OS *is* the same as native Linux, as far as TLB handling is concerned. Looks you means the TLB exception handler should be same between the native and the guest OS. Right? Yes. I don't think so. The HY should assist the guest OS on MMU since I already point the guest OS have no authority to create a real TLB directly as I previously said. Here I assume we're talking about e500mc since as far as I know for Freescale only e500mc is designed to support virtual machine based on ISA 2.0.6. Yes, though there's nothing preventing virtualization on cores without category E.HV (KVM supports this) -- it's just slower. Absolutely. I also know all TLB exceptions can direct to the guest OS when we enable EPCR[DTLBGS|ITLBGS|DSIGS|ISIGS]. But some TLB instructions (i.e. tlbwe )are the privileged instructions. So the guest OS always trap into the hypervisor and then the hypervisor should complete the real action with appropriate physical address. Yes, of course. But that's not the point. I was just using it as a convenient example because that's what I've recently done ELF loading with... There's no reason U-Boot couldn't do the same if its ELF loader were updated to support device trees. Currently U-Boot loads bootwrapperless uImages to physical address zero. I never doubt the U-boot can do this for uImage. But I think we're always talking about vmlinux, a bare Image. Here you already assume so many conditions for vmlinux before we were discussing. Such as bootwrapperlee uImage, its ELF loader can update/support dtb, the HY... I think this is just why I say we cannot boot vmlinux based on common boot loader if only change entry point of vmlinux. And FWIW, we have run setups where our hv loads Linux to true physical zero (with the hv living elsewhere), not just guest physical. That's true. The HY should be allowed to access any address. Best Regards Tiejun -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] powerpc: export ppc_tb_freq so that modules can reference it
On Sat, 2010-09-18 at 10:34 -0500, Kumar Gala wrote: On Sep 18, 2010, at 9:36 AM, Tabi Timur-B04825 wrote: On Sep 17, 2010, at 10:14 PM, Benjamin Herrenschmidt b...@kernel.crashing.org wrote: On Fri, 2010-09-17 at 20:20 -0500, Timur Tabi wrote: I don't see any reason to limit it to GPL drivers. Not only that, but then we'll have this: I do Can you elaborate on that, or are you just going to pull rank on me? EXPORT_SYMBOL(ppc_proc_freq); EXPORT_SYMBOL_GPL(ppc_tb_freq); That just looks dumb. Right, so send a patch to fix the first one too :-) I don't think either of these should be EXPORT_SYMBOL_GPL. Why shouldn't a binary module be allowed to know these frequencies? My view is why preclude anyone from using this how they want. If they want to live in the gray area so be it. Who am I to say they shouldn't have that choice. Well, I'm all for making binary modules life as hard as possible just for the sake of it :-) Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
