* Re: [PATCH] kbuild: Enable building defconfigs from Kconfig files
From: Linus Torvalds @ 2010-07-14 4:04 UTC (permalink / raw)
To: Grant Likely
Cc: Michal Marek, Stephen Rothwell, Catalin Marinas, LKML,
Russell King, Andrew Morton, ppc-dev, linux-arm-kernel
In-Reply-To: <AANLkTimC_vXCAOrfTSndZyk8lgkjTlILVSYVYeIg6cUt@mail.gmail.com>
On Tue, Jul 13, 2010 at 7:26 PM, Grant Likely <grant.likely@secretlab.ca> w=
rote:
>
> I chose to use -D /dev/null (defconfig from an empty file) instead of
> -n (allnoconfig) so that default values in Kconfig would get
> respected. =A0For the benefit of everyone else, here's an excerpt from
> our IRC conversation this afternoon:
>
> 19:49 < gcl> sfr: [...] Your patch and my patch are
> =A0 =A0 =A0 =A0 =A0 =A0 essentially doing exactly the same thing, except =
that I used '-d'
> =A0 =A0 =A0 =A0 =A0 =A0 and you used '-n'.
> 19:50 < gcl> s/-d/-D/
> 19:55 < sfr> right
> 19:55 < sfr> Linus wanted us to use -n
Just a note: Linus doesn't really care.
IOW, I used -n not because of any fundamental belief that it is
correct, but just because ti happened to be how I happened to decide
to solve it. It's entirely possible that starting from the Kconfig
defaults (rather than "no") is the right way to go.
I think either approach is likely fine. The -D /dev/null approach
would presumably give smaller Kconfig.xyz files, assuming our defaults
are sane (an maybe that could be at least a partial validation of the
defaults we do have). While the -n approach is in some ways more
stable, in that the resulting Kconfig.xyz entires would presumably be
more stand-alone, and there wouldn't be any subtle interactions when
somebody changes a default value int he Kconfig file.
So I can see advantages to either model. And either model clearly
would want the improvements to "select" that are independent (ie warn
about unsatisfied 'depends on' constraints, and select recursively.
Maybe we already fixed the recursive select thing, I forget).
I also think we need to allow setting of actual values. I don't know
what the syntax would be. A "set" statement that overrides a default
in the Kconfig file, so that you can do
set NODES_SHIFT 10
which would basically be equivalent to a "select" of a tristate
variable, but instead set the actual value? I dunno.
And quite frankly, maybe somebody comes up with a better model
entirely. I like the Kconfig.xyz model, in that it should be
human-readable/writable and shouldn't introduce any fundamentally new
concepts (except the fairly simple extensions to the Kconfig
language), but maybe there are better models.
Regardless, I don't have anything against either set of patches
(Grant's or Stephen's).
Linus
^ permalink raw reply
* Re: [PATCH v2 2/2] Crypto: Talitos: Support for Async_tx XOR offload
From: hank peng @ 2010-07-14 3:58 UTC (permalink / raw)
To: Vishnu Suresh
Cc: herbert, B04825, linux-kernel, linux-raid, linuxppc-dev,
linux-crypto, dan.j.williams, Maneesh Gupta, R58472
In-Reply-To: <1260977698-4076-1-git-send-email-Vishnu@freescale.com>
Hi:
I used your patch and test it on MPC8548 board. Today, I found a
problem when doing raid5 recovering.
talitos e0030000.crypto: master data transfer error
talitos e0030000.crypto: xor operation: talitos error -22
------------[ cut here ]------------
Kernel BUG at c02dcb6c [verbose debug info unavailable]
Oops: Exception in kernel mode, sig: 5 [#1]
MPC85xx CDS
Modules linked in: iscsi_trgt
NIP: c02dcb6c LR: c02dcb6c CTR: c023e7a8
REGS: e8b8d820 TRAP: 0700 Not tainted (2.6.31.6)
MSR: 00029000 <EE,ME,CE> CR: 22008022 XER: 20000000
TASK =3D ef8cb2e0[1897] 'md2_raid5' THREAD: e8b8c000
GPR00: c02dcb6c e8b8d8d0 ef8cb2e0 00000040 00007c99 ffffffff c023bccc 00007=
c5f
GPR08: c04a5c60 c049b5fc 00007c99 00004000 80008022 00000000 3fff5700 c3374=
754
GPR16: c337474c 00000000 00000000 ffffffea 00000001 00000000 000186a0 00000=
000
GPR24: ffffffea ffffffea ef81f850 0000000c 00029000 ffffffea ef81f850 efb1d=
580
NIP [c02dcb6c] talitos_release_xor+0xfc/0x104
LR [c02dcb6c] talitos_release_xor+0xfc/0x104
Call Trace:
[e8b8d8d0] [c02dcb6c] talitos_release_xor+0xfc/0x104 (unreliable)
[e8b8d8f0] [c02db928] flush_channel+0x11c/0x178
[e8b8d920] [c02dd344] talitos_interrupt+0x320/0x9e8
[e8b8d970] [c0060b3c] handle_IRQ_event+0x5c/0x140
[e8b8d990] [c006280c] handle_fasteoi_irq+0x68/0x118
[e8b8d9a0] [c0004f08] do_IRQ+0x94/0xb0
[e8b8d9c0] [c000fe00] ret_from_except+0x0/0x18
[e8b8da80] [c02b47a0] release_stripe+0x24/0x3c
[e8b8da90] [c02ba4ec] raid5_end_read_request+0x160/0x3f8
[e8b8dae0] [c00ba36c] bio_endio+0x48/0x6c
[e8b8daf0] [c01f80e0] req_bio_endio+0xa4/0x128
[e8b8db10] [c01f81f0] blk_update_request+0x8c/0x43c
[e8b8db40] [c01f85c0] blk_update_bidi_request+0x20/0x88
[e8b8db60] [c01f92c4] blk_end_bidi_request+0x1c/0x58
[e8b8db80] [c01f9314] blk_end_request+0x14/0x24
[e8b8db90] [c025ece0] scsi_io_completion+0x8c/0x4ac
[e8b8dbd0] [c0257fd0] scsi_finish_command+0xd0/0xf4
[e8b8dbf0] [c025f1c8] scsi_softirq_done+0xc8/0x150
[e8b8dc10] [c01fe114] blk_done_softirq+0x80/0xa0
[e8b8dc30] [c003a0d8] __do_softirq+0xa8/0x128
[e8b8dc70] [c0004e70] do_softirq+0x54/0x58
[e8b8dc80] [c0039f4c] irq_exit+0x94/0x98
[e8b8dc90] [c0004f0c] do_IRQ+0x98/0xb0
[e8b8dcb0] [c000fe00] ret_from_except+0x0/0x18
[e8b8dd70] [c00679c8] mempool_alloc_slab+0x1c/0x2c
[e8b8ddb0] [c02b6814] ops_run_io+0x1ac/0x2b8
[e8b8ddf0] [c02b93e4] handle_stripe5+0xa80/0x15c0
[e8b8de70] [c02bb408] handle_stripe+0x34/0x12d4
[e8b8df10] [c02bc8ec] raid5d+0x244/0x458
[e8b8df70] [c02c9624] md_thread+0x5c/0x124
[e8b8dfc0] [c004ab24] kthread+0x78/0x7c
[e8b8dff0] [c000f52c] kernel_thread+0x4c/0x68
Instruction dump:
bb61000c 38210020 7c0803a6 4bffefac 4bf63bc9 80be0008 7c641b78 3c60c042
7fa6eb78 38631ccc 4cc63182 4bd58b9d <0fe00000> 48000000 9421ffd0 7c0802a6
Kernel panic - not syncing: Fatal exception in interrupt
Rebooting in 1 seconds..
------------[ cut here ]------------
Badness at c0223124 [verbose debug info unavailable]
NIP: c0223124 LR: c0223308 CTR: 00000000
REGS: e8b8d580 TRAP: 0700 Tainted: G D (2.6.31.6)
MSR: 00021000 <ME,CE> CR: 82008088 XER: 20000000
TASK =3D ef8cb2e0[1897] 'md2_raid5' THREAD: e8b8c000
GPR00: 00000001 e8b8d630 ef8cb2e0 e84f1d60 00000000 e84f1d60 e84f1d7c c04a1=
364
GPR08: c04a5c60 e8b8c000 0000873b e8b8d650 82008088 00000000 3fff5700 c3374=
754
GPR16: c337474c 00000000 00000000 ffffffea 00000001 00000000 000186a0 00000=
000
GPR24: ffffffea ffffffea 00000000 ffffffff ffffffff 00000000 00001106 e84f1=
d60
NIP [c0223124] pci_get_dev_by_id+0x34/0x98
LR [c0223308] pci_get_subsys+0x64/0xa4
Call Trace:
[e8b8d630] [c021e378] no_pci_devices+0x34/0x50 (unreliable)
[e8b8d650] [c0223308] pci_get_subsys+0x64/0xa4
[e8b8d670] [c0017be0] mpc85xx_cds_restart+0x24/0x90
[e8b8d690] [c000e7d0] machine_restart+0x34/0x4c
[e8b8d6a0] [c00447e0] emergency_restart+0x14/0x24
[e8b8d6b0] [c003473c] panic+0x118/0x158
[e8b8d700] [c000cf24] die+0x160/0x16c
[e8b8d720] [c000d1b0] _exception+0x12c/0x154
[e8b8d810] [c000fdb4] ret_from_except_full+0x0/0x4c
[e8b8d8d0] [c02dcb6c] talitos_release_xor+0xfc/0x104
[e8b8d8f0] [c02db928] flush_channel+0x11c/0x178
[e8b8d920] [c02dd344] talitos_interrupt+0x320/0x9e8
[e8b8d970] [c0060b3c] handle_IRQ_event+0x5c/0x140
[e8b8d990] [c006280c] handle_fasteoi_irq+0x68/0x118
[e8b8d9a0] [c0004f08] do_IRQ+0x94/0xb0
[e8b8d9c0] [c000fe00] ret_from_except+0x0/0x18
[e8b8da80] [c02b47a0] release_stripe+0x24/0x3c
[e8b8da90] [c02ba4ec] raid5_end_read_request+0x160/0x3f8
[e8b8dae0] [c00ba36c] bio_endio+0x48/0x6c
[e8b8daf0] [c01f80e0] req_bio_endio+0xa4/0x128
[e8b8db10] [c01f81f0] blk_update_request+0x8c/0x43c
[e8b8db40] [c01f85c0] blk_update_bidi_request+0x20/0x88
[e8b8db60] [c01f92c4] blk_end_bidi_request+0x1c/0x58
[e8b8db80] [c01f9314] blk_end_request+0x14/0x24
[e8b8db90] [c025ece0] scsi_io_completion+0x8c/0x4ac
[e8b8dbd0] [c0257fd0] scsi_finish_command+0xd0/0xf4
[e8b8dbf0] [c025f1c8] scsi_softirq_done+0xc8/0x150
[e8b8dc10] [c01fe114] blk_done_softirq+0x80/0xa0
[e8b8dc30] [c003a0d8] __do_softirq+0xa8/0x128
[e8b8dc70] [c0004e70] do_softirq+0x54/0x58
[e8b8dc80] [c0039f4c] irq_exit+0x94/0x98
[e8b8dc90] [c0004f0c] do_IRQ+0x98/0xb0
[e8b8dcb0] [c000fe00] ret_from_except+0x0/0x18
[e8b8dd70] [c00679c8] mempool_alloc_slab+0x1c/0x2c
[e8b8ddb0] [c02b6814] ops_run_io+0x1ac/0x2b8
[e8b8ddf0] [c02b93e4] handle_stripe5+0xa80/0x15c0
[e8b8de70] [c02bb408] handle_stripe+0x34/0x12d4
[e8b8df10] [c02bc8ec] raid5d+0x244/0x458
[e8b8df70] [c02c9624] md_thread+0x5c/0x124
[e8b8dfc0] [c004ab24] kthread+0x78/0x7c
[e8b8dff0] [c000f52c] kernel_thread+0x4c/0x68
Instruction dump:
7c0802a6 7d800026 7c651b78 bf810010 54290024 90010024 7c9d2378 9181000c
8009000c 5400016e 7c0000d0 54000ffe <0f000000> 3b800000 2e040000 3cc0c022
This oops is invoked by the following code:
static void talitos_release_xor(struct device *dev, struct talitos_desc *hw=
desc,
void *context, int error)
{
struct talitos_xor_desc *desc =3D context;
struct talitos_xor_chan *xor_chan;
dma_async_tx_callback callback;
void *callback_param;
if (unlikely(error)) {
dev_err(dev, "xor operation: talitos error %d\n", error);
BUG();
<-----------------------------------------------------------------
here
}
I wonder here why a tailitos error occured, BUG is invoked? I think we
can do something to error recovery other than invoking BUG.
2009/12/16 Vishnu Suresh <Vishnu@freescale.com>:
> Expose Talitos's XOR functionality to be used for
> RAID Parity calculation via the Async_tx layer.
>
> Known Issue:
> When used with fsldma, random crashes are observed
> on some platforms. Hence, inter-operability with fsldma
> is currently disabled
>
> Thanks to Surender Kumar and Lee Nipper for their help in
> realising this driver
>
> Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
> Signed-off-by: Dipen Dudhat <Dipen.Dudhat@freescale.com>
> Signed-off-by: Maneesh Gupta <Maneesh.Gupta@freescale.com>
> Signed-off-by: Vishnu Suresh <Vishnu@freescale.com>
> ---
> Changes with respect to v1 as per comments received
> o. Rebased to linux-next as of 20091216
> o. The selection is based exclusive of fsldma
> o. Intoduced a new Kernel Configuration variable
> =C2=A0 *. This enables selecting the Cryptographic functionality
> =C2=A0 =C2=A0 =C2=A0of Talitos along with fsldma.
> =C2=A0 *. Disables the XOR parity calculation offload, if fsldma enabled
> =C2=A0 =C2=A0 =C2=A0either as kernel in-built or as a module
> =C2=A0 *. Once the inter-operability with fsldma is resolved, this option
> =C2=A0 =C2=A0 =C2=A0can be removed
>
> =C2=A0drivers/crypto/Kconfig =C2=A0 | =C2=A0 =C2=A09 +
> =C2=A0drivers/crypto/talitos.c | =C2=A0402 ++++++++++++++++++++++++++++++=
+++++++++++++++-
> =C2=A0drivers/crypto/talitos.h | =C2=A0 =C2=A02 +
> =C2=A03 files changed, 412 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
> index b08403d..f8a6376 100644
> --- a/drivers/crypto/Kconfig
> +++ b/drivers/crypto/Kconfig
> @@ -203,6 +203,15 @@ config CRYPTO_DEV_TALITOS
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0To compile this driver as a module, cho=
ose M here: the module
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0will be called talitos.
>
> +config CRYPTO_DEV_TALITOS_RAIDXOR
> + =C2=A0 =C2=A0 =C2=A0 bool "Talitos RAID5 XOR Calculation Offload"
> + =C2=A0 =C2=A0 =C2=A0 select DMA_ENGINE
> + =C2=A0 =C2=A0 =C2=A0 depends on CRYPTO_DEV_TALITOS
> + =C2=A0 =C2=A0 =C2=A0 depends on FSL_DMA=3Dn
> + =C2=A0 =C2=A0 =C2=A0 help
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 Say 'Y' here to use the Freescale Security =
Engine (SEC) to
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 offload RAID XOR parity Calculation
> +
> =C2=A0config CRYPTO_DEV_IXP4XX
> =C2=A0 =C2=A0 =C2=A0 =C2=A0tristate "Driver for IXP4xx crypto hardware ac=
celeration"
> =C2=A0 =C2=A0 =C2=A0 =C2=A0depends on ARCH_IXP4XX
> diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
> index c47ffe8..e63b25a 100644
> --- a/drivers/crypto/talitos.c
> +++ b/drivers/crypto/talitos.c
> @@ -1,7 +1,7 @@
> =C2=A0/*
> =C2=A0* talitos - Freescale Integrated Security Engine (SEC) device drive=
r
> =C2=A0*
> - * Copyright (c) 2008 Freescale Semiconductor, Inc.
> + * Copyright (c) 2008-2009 Freescale Semiconductor, Inc.
> =C2=A0*
> =C2=A0* Scatterlist Crypto API glue code copied from files with the follo=
wing:
> =C2=A0* Copyright (c) 2006-2007 Herbert Xu <herbert@gondor.apana.org.au>
> @@ -37,6 +37,8 @@
> =C2=A0#include <linux/io.h>
> =C2=A0#include <linux/spinlock.h>
> =C2=A0#include <linux/rtnetlink.h>
> +#include <linux/dmaengine.h>
> +#include <linux/raid/xor.h>
>
> =C2=A0#include <crypto/algapi.h>
> =C2=A0#include <crypto/aes.h>
> @@ -140,6 +142,10 @@ struct talitos_private {
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0/* hwrng device */
> =C2=A0 =C2=A0 =C2=A0 =C2=A0struct hwrng rng;
> +#ifdef CONFIG_CRYPTO_DEV_TALITOS_RAIDXOR
> + =C2=A0 =C2=A0 =C2=A0 /* XOR Device */
> + =C2=A0 =C2=A0 =C2=A0 struct dma_device dma_dev_common;
> +#endif /* CONFIG_CRYPTO_DEV_TALITOS_RAIDXOR */
> =C2=A0};
>
> =C2=A0/* .features flag */
> @@ -684,6 +690,375 @@ static void talitos_unregister_rng(struct device *d=
ev)
> =C2=A0 =C2=A0 =C2=A0 =C2=A0hwrng_unregister(&priv->rng);
> =C2=A0}
>
> +#ifdef CONFIG_CRYPTO_DEV_TALITOS_RAIDXOR
> +/*
> + * async_tx interface for XOR-capable SECs
> + *
> + * Dipen Dudhat <Dipen.Dudhat@freescale.com>
> + * Maneesh Gupta <Maneesh.Gupta@freescale.com>
> + * Vishnu Suresh <Vishnu@freescale.com>
> + */
> +
> +/**
> + * talitos_xor_chan - context management for the async_tx channel
> + * @completed_cookie: the last completed cookie
> + * @desc_lock: lock for tx queue
> + * @total_desc: number of descriptors allocated
> + * @submit_q: queue of submitted descriptors
> + * @pending_q: queue of pending descriptors
> + * @in_progress_q: queue of descriptors in progress
> + * @free_desc: queue of unused descriptors
> + * @dev: talitos device implementing this channel
> + * @common: the corresponding xor channel in async_tx
> + */
> +struct talitos_xor_chan {
> + =C2=A0 =C2=A0 =C2=A0 dma_cookie_t completed_cookie;
> + =C2=A0 =C2=A0 =C2=A0 spinlock_t desc_lock;
> + =C2=A0 =C2=A0 =C2=A0 unsigned int total_desc;
> + =C2=A0 =C2=A0 =C2=A0 struct list_head submit_q;
> + =C2=A0 =C2=A0 =C2=A0 struct list_head pending_q;
> + =C2=A0 =C2=A0 =C2=A0 struct list_head in_progress_q;
> + =C2=A0 =C2=A0 =C2=A0 struct list_head free_desc;
> + =C2=A0 =C2=A0 =C2=A0 struct device *dev;
> + =C2=A0 =C2=A0 =C2=A0 struct dma_chan common;
> +};
> +
> +/**
> + * talitos_xor_desc - software xor descriptor
> + * @async_tx: the referring async_tx descriptor
> + * @node:
> + * @hwdesc: h/w descriptor
> + */
> +struct talitos_xor_desc {
> + =C2=A0 =C2=A0 =C2=A0 struct dma_async_tx_descriptor async_tx;
> + =C2=A0 =C2=A0 =C2=A0 struct list_head tx_list;
> + =C2=A0 =C2=A0 =C2=A0 struct list_head node;
> + =C2=A0 =C2=A0 =C2=A0 struct talitos_desc hwdesc;
> +};
> +
> +static enum dma_status talitos_is_tx_complete(struct dma_chan *chan,
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 dma_cookie_t cookie,
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 dma_cookie_t *done,
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 dma_cookie_t *used)
> +{
> + =C2=A0 =C2=A0 =C2=A0 struct talitos_xor_chan *xor_chan;
> + =C2=A0 =C2=A0 =C2=A0 dma_cookie_t last_used;
> + =C2=A0 =C2=A0 =C2=A0 dma_cookie_t last_complete;
> +
> + =C2=A0 =C2=A0 =C2=A0 xor_chan =3D container_of(chan, struct talitos_xor=
_chan, common);
> +
> + =C2=A0 =C2=A0 =C2=A0 last_used =3D chan->cookie;
> + =C2=A0 =C2=A0 =C2=A0 last_complete =3D xor_chan->completed_cookie;
> +
> + =C2=A0 =C2=A0 =C2=A0 if (done)
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 *done =3D last_complet=
e;
> +
> + =C2=A0 =C2=A0 =C2=A0 if (used)
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 *used =3D last_used;
> +
> + =C2=A0 =C2=A0 =C2=A0 return dma_async_is_complete(cookie, last_complete=
, last_used);
> +}
> +
> +static void talitos_release_xor(struct device *dev, struct talitos_desc =
*hwdesc,
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 void *context, int error)
> +{
> + =C2=A0 =C2=A0 =C2=A0 struct talitos_xor_desc *desc =3D context;
> + =C2=A0 =C2=A0 =C2=A0 struct talitos_xor_chan *xor_chan;
> + =C2=A0 =C2=A0 =C2=A0 dma_async_tx_callback callback;
> + =C2=A0 =C2=A0 =C2=A0 void *callback_param;
> +
> + =C2=A0 =C2=A0 =C2=A0 if (unlikely(error)) {
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 dev_err(dev, "xor oper=
ation: talitos error %d\n", error);
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 BUG();
> + =C2=A0 =C2=A0 =C2=A0 }
> +
> + =C2=A0 =C2=A0 =C2=A0 xor_chan =3D container_of(desc->async_tx.chan, str=
uct talitos_xor_chan,
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 common);
> + =C2=A0 =C2=A0 =C2=A0 spin_lock_bh(&xor_chan->desc_lock);
> + =C2=A0 =C2=A0 =C2=A0 if (xor_chan->completed_cookie < desc->async_tx.co=
okie)
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 xor_chan->completed_co=
okie =3D desc->async_tx.cookie;
> +
> + =C2=A0 =C2=A0 =C2=A0 callback =3D desc->async_tx.callback;
> + =C2=A0 =C2=A0 =C2=A0 callback_param =3D desc->async_tx.callback_param;
> + =C2=A0 =C2=A0 =C2=A0 list_del(&desc->node);
> + =C2=A0 =C2=A0 =C2=A0 list_add_tail(&desc->node, &xor_chan->free_desc);
> + =C2=A0 =C2=A0 =C2=A0 spin_unlock_bh(&xor_chan->desc_lock);
> +
> + =C2=A0 =C2=A0 =C2=A0 if (callback)
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 callback(callback_para=
m);
> +
> + =C2=A0 =C2=A0 =C2=A0 /* run dependent operations */
> + =C2=A0 =C2=A0 =C2=A0 dma_run_dependencies(&desc->async_tx);
> +}
> +
> +static void talitos_process_pending(struct talitos_xor_chan *xor_chan)
> +{
> + =C2=A0 =C2=A0 =C2=A0 struct talitos_xor_desc *desc, *_desc;
> +
> + =C2=A0 =C2=A0 =C2=A0 spin_lock_bh(&xor_chan->desc_lock);
> + =C2=A0 =C2=A0 =C2=A0 list_for_each_entry_safe(desc, _desc, &xor_chan->p=
ending_q, node) {
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (talitos_submit(xor=
_chan->dev, &desc->hwdesc,
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0talitos_release_xor, desc) =
!=3D -EINPROGRESS)
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 break;
> +
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 list_del(&desc->node);
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 list_add_tail(&desc->n=
ode, &xor_chan->in_progress_q);
> + =C2=A0 =C2=A0 =C2=A0 }
> + =C2=A0 =C2=A0 =C2=A0 spin_unlock_bh(&xor_chan->desc_lock);
> +}
> +
> +/**
> + * talitos_issue_pending - move the descriptors in submit
> + * queue to pending queue and submit them for processing
> + * @chan: DMA channel
> + */
> +static void talitos_issue_pending(struct dma_chan *chan)
> +{
> + =C2=A0 =C2=A0 =C2=A0 struct talitos_xor_chan *xor_chan;
> +
> + =C2=A0 =C2=A0 =C2=A0 xor_chan =3D container_of(chan, struct talitos_xor=
_chan, common);
> + =C2=A0 =C2=A0 =C2=A0 spin_lock_bh(&xor_chan->desc_lock);
> + =C2=A0 =C2=A0 =C2=A0 list_splice_tail_init(&xor_chan->submit_q,
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&xor_chan->pending_q);
> + =C2=A0 =C2=A0 =C2=A0 spin_unlock_bh(&xor_chan->desc_lock);
> + =C2=A0 =C2=A0 =C2=A0 talitos_process_pending(xor_chan);
> +}
> +
> +static dma_cookie_t talitos_async_tx_submit(struct dma_async_tx_descript=
or *tx)
> +{
> + =C2=A0 =C2=A0 =C2=A0 struct talitos_xor_desc *desc;
> + =C2=A0 =C2=A0 =C2=A0 struct talitos_xor_chan *xor_chan;
> + =C2=A0 =C2=A0 =C2=A0 dma_cookie_t cookie;
> +
> + =C2=A0 =C2=A0 =C2=A0 desc =3D container_of(tx, struct talitos_xor_desc,=
async_tx);
> + =C2=A0 =C2=A0 =C2=A0 xor_chan =3D container_of(tx->chan, struct talitos=
_xor_chan, common);
> +
> + =C2=A0 =C2=A0 =C2=A0 cookie =3D xor_chan->common.cookie + 1;
> + =C2=A0 =C2=A0 =C2=A0 if (cookie < 0)
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 cookie =3D 1;
> +
> + =C2=A0 =C2=A0 =C2=A0 desc->async_tx.cookie =3D cookie;
> + =C2=A0 =C2=A0 =C2=A0 xor_chan->common.cookie =3D desc->async_tx.cookie;
> +
> + =C2=A0 =C2=A0 =C2=A0 list_splice_tail_init(&desc->tx_list,
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&xor_chan->submit_q);
> +
> + =C2=A0 =C2=A0 =C2=A0 return cookie;
> +}
> +
> +static struct talitos_xor_desc *talitos_xor_alloc_descriptor(
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 struct talitos_xor_chan *xor_chan, gfp_t=
flags)
> +{
> + =C2=A0 =C2=A0 =C2=A0 struct talitos_xor_desc *desc;
> +
> + =C2=A0 =C2=A0 =C2=A0 desc =3D kmalloc(sizeof(*desc), flags);
> + =C2=A0 =C2=A0 =C2=A0 if (desc) {
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 xor_chan->total_desc++=
;
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 memset(desc, 0, sizeof=
(*desc));
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 dma_async_tx_descripto=
r_init(&desc->async_tx, &xor_chan->common);
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 desc->async_tx.tx_subm=
it =3D talitos_async_tx_submit;
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 INIT_LIST_HEAD(&desc->=
node);
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 INIT_LIST_HEAD(&desc->=
tx_list);
> + =C2=A0 =C2=A0 =C2=A0 }
> +
> + =C2=A0 =C2=A0 =C2=A0 return desc;
> +}
> +
> +static void talitos_free_chan_resources(struct dma_chan *chan)
> +{
> + =C2=A0 =C2=A0 =C2=A0 struct talitos_xor_chan *xor_chan;
> + =C2=A0 =C2=A0 =C2=A0 struct talitos_xor_desc *desc, *_desc;
> +
> + =C2=A0 =C2=A0 =C2=A0 xor_chan =3D container_of(chan, struct talitos_xor=
_chan, common);
> +
> + =C2=A0 =C2=A0 =C2=A0 list_for_each_entry_safe(desc, _desc, &xor_chan->s=
ubmit_q, node) {
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 list_del(&desc->node);
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 xor_chan->total_desc--=
;
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 kfree(desc);
> + =C2=A0 =C2=A0 =C2=A0 }
> + =C2=A0 =C2=A0 =C2=A0 list_for_each_entry_safe(desc, _desc, &xor_chan->p=
ending_q, node) {
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 list_del(&desc->node);
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 xor_chan->total_desc--=
;
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 kfree(desc);
> + =C2=A0 =C2=A0 =C2=A0 }
> + =C2=A0 =C2=A0 =C2=A0 list_for_each_entry_safe(desc, _desc, &xor_chan->i=
n_progress_q, node) {
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 list_del(&desc->node);
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 xor_chan->total_desc--=
;
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 kfree(desc);
> + =C2=A0 =C2=A0 =C2=A0 }
> + =C2=A0 =C2=A0 =C2=A0 list_for_each_entry_safe(desc, _desc, &xor_chan->f=
ree_desc, node) {
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 list_del(&desc->node);
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 xor_chan->total_desc--=
;
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 kfree(desc);
> + =C2=A0 =C2=A0 =C2=A0 }
> + =C2=A0 =C2=A0 =C2=A0 BUG_ON(unlikely(xor_chan->total_desc)); /* Some de=
scriptor not freed? */
> +}
> +
> +static int talitos_alloc_chan_resources(struct dma_chan *chan)
> +{
> + =C2=A0 =C2=A0 =C2=A0 struct talitos_xor_chan *xor_chan;
> + =C2=A0 =C2=A0 =C2=A0 struct talitos_xor_desc *desc;
> + =C2=A0 =C2=A0 =C2=A0 LIST_HEAD(tmp_list);
> + =C2=A0 =C2=A0 =C2=A0 int i;
> +
> + =C2=A0 =C2=A0 =C2=A0 xor_chan =3D container_of(chan, struct talitos_xor=
_chan, common);
> +
> + =C2=A0 =C2=A0 =C2=A0 if (!list_empty(&xor_chan->free_desc))
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return xor_chan->total=
_desc;
> +
> + =C2=A0 =C2=A0 =C2=A0 /* 256 initial descriptors */
> + =C2=A0 =C2=A0 =C2=A0 for (i =3D 0; i < 256; i++) {
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 desc =3D talitos_xor_a=
lloc_descriptor(xor_chan, GFP_KERNEL);
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (!desc) {
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 dev_err(xor_chan->common.device->dev,
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "Only %d initial descriptors\n", i);
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 break;
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 list_add_tail(&desc->n=
ode, &tmp_list);
> + =C2=A0 =C2=A0 =C2=A0 }
> +
> + =C2=A0 =C2=A0 =C2=A0 if (!i)
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return -ENOMEM;
> +
> + =C2=A0 =C2=A0 =C2=A0 /* At least one desc is allocated */
> + =C2=A0 =C2=A0 =C2=A0 list_splice_init(&tmp_list, &xor_chan->free_desc);
> +
> + =C2=A0 =C2=A0 =C2=A0 return xor_chan->total_desc;
> +}
> +
> +static struct dma_async_tx_descriptor * talitos_prep_dma_xor(
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 struct dma_chan *chan, dma_addr_t dest, dma_addr_t *src,
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 unsigned int src_cnt, size_t len, unsigned long flags)
> +{
> + =C2=A0 =C2=A0 =C2=A0 struct talitos_xor_chan *xor_chan;
> + =C2=A0 =C2=A0 =C2=A0 struct talitos_xor_desc *new;
> + =C2=A0 =C2=A0 =C2=A0 struct talitos_desc *desc;
> + =C2=A0 =C2=A0 =C2=A0 int i, j;
> +
> + =C2=A0 =C2=A0 =C2=A0 BUG_ON(unlikely(len > TALITOS_MAX_DATA_LEN));
> +
> + =C2=A0 =C2=A0 =C2=A0 xor_chan =3D container_of(chan, struct talitos_xor=
_chan, common);
> +
> + =C2=A0 =C2=A0 =C2=A0 if (!list_empty(&xor_chan->free_desc)) {
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 new =3D container_of(x=
or_chan->free_desc.next,
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0struct talitos_xor_desc, no=
de);
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 list_del(&new->node);
> + =C2=A0 =C2=A0 =C2=A0 } else {
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 new =3D talitos_xor_al=
loc_descriptor(xor_chan, GFP_KERNEL);
> + =C2=A0 =C2=A0 =C2=A0 }
> +
> + =C2=A0 =C2=A0 =C2=A0 if (!new) {
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 dev_err(xor_chan->comm=
on.device->dev,
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 "No free memory for XOR DMA descriptor\n");
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return NULL;
> + =C2=A0 =C2=A0 =C2=A0 }
> +
> + =C2=A0 =C2=A0 =C2=A0 desc =3D &new->hwdesc;
> + =C2=A0 =C2=A0 =C2=A0 /* Set destination: Last pointer pair */
> + =C2=A0 =C2=A0 =C2=A0 to_talitos_ptr(&desc->ptr[6], dest);
> + =C2=A0 =C2=A0 =C2=A0 desc->ptr[6].len =3D cpu_to_be16(len);
> + =C2=A0 =C2=A0 =C2=A0 desc->ptr[6].j_extent =3D 0;
> +
> + =C2=A0 =C2=A0 =C2=A0 /* Set Sources: End loading from second-last point=
er pair */
> + =C2=A0 =C2=A0 =C2=A0 for (i =3D 5, j =3D 0; (j < src_cnt) && (i > 0); i=
--, j++) {
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 to_talitos_ptr(&desc->=
ptr[i], src[j]);
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 desc->ptr[i].len =3D c=
pu_to_be16(len);
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 desc->ptr[i].j_extent =
=3D 0;
> + =C2=A0 =C2=A0 =C2=A0 }
> +
> + =C2=A0 =C2=A0 =C2=A0 /*
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0* documentation states first 0 ptr/len combo=
marks end of sources
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0* yet device produces scatter boundary error=
unless all subsequent
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0* sources are zeroed out
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0*/
> + =C2=A0 =C2=A0 =C2=A0 for (; i >=3D 0; i--) {
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 to_talitos_ptr(&desc->=
ptr[i], 0);
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 desc->ptr[i].len =3D 0=
;
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 desc->ptr[i].j_extent =
=3D 0;
> + =C2=A0 =C2=A0 =C2=A0 }
> +
> + =C2=A0 =C2=A0 =C2=A0 desc->hdr =3D DESC_HDR_SEL0_AESU | DESC_HDR_MODE0_=
AESU_XOR
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | DESC_H=
DR_TYPE_RAID_XOR;
> +
> + =C2=A0 =C2=A0 =C2=A0 list_add_tail(&new->node, &new->tx_list);
> +
> + =C2=A0 =C2=A0 =C2=A0 new->async_tx.flags =3D flags;
> + =C2=A0 =C2=A0 =C2=A0 new->async_tx.cookie =3D -EBUSY;
> +
> + =C2=A0 =C2=A0 =C2=A0 return &new->async_tx;
> +}
> +
> +static void talitos_unregister_async_xor(struct device *dev)
> +{
> + =C2=A0 =C2=A0 =C2=A0 struct talitos_private *priv =3D dev_get_drvdata(d=
ev);
> + =C2=A0 =C2=A0 =C2=A0 struct talitos_xor_chan *xor_chan;
> + =C2=A0 =C2=A0 =C2=A0 struct dma_chan *chan;
> +
> + =C2=A0 =C2=A0 =C2=A0 if (priv->dma_dev_common.chancnt)
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 dma_async_device_unreg=
ister(&priv->dma_dev_common);
> +
> + =C2=A0 =C2=A0 =C2=A0 list_for_each_entry(chan, &priv->dma_dev_common.ch=
annels, device_node) {
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 xor_chan =3D container=
_of(chan, struct talitos_xor_chan, common);
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 list_del(&chan->device=
_node);
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 priv->dma_dev_common.c=
hancnt--;
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 kfree(xor_chan);
> + =C2=A0 =C2=A0 =C2=A0 }
> +}
> +
> +/**
> + * talitos_register_dma_async - Initialize the Freescale XOR ADMA device
> + * It is registered as a DMA device with the capability to perform
> + * XOR operation with the Async_tx layer.
> + * The various queues and channel resources are also allocated.
> + */
> +static int talitos_register_async_tx(struct device *dev, int max_xor_src=
s)
> +{
> + =C2=A0 =C2=A0 =C2=A0 struct talitos_private *priv =3D dev_get_drvdata(d=
ev);
> + =C2=A0 =C2=A0 =C2=A0 struct dma_device *dma_dev =3D &priv->dma_dev_comm=
on;
> + =C2=A0 =C2=A0 =C2=A0 struct talitos_xor_chan *xor_chan;
> + =C2=A0 =C2=A0 =C2=A0 int err;
> +
> + =C2=A0 =C2=A0 =C2=A0 xor_chan =3D kzalloc(sizeof(struct talitos_xor_cha=
n), GFP_KERNEL);
> + =C2=A0 =C2=A0 =C2=A0 if (!xor_chan) {
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 dev_err(dev, "unable t=
o allocate xor channel\n");
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return -ENOMEM;
> + =C2=A0 =C2=A0 =C2=A0 }
> +
> + =C2=A0 =C2=A0 =C2=A0 dma_dev->dev =3D dev;
> + =C2=A0 =C2=A0 =C2=A0 dma_dev->device_alloc_chan_resources =3D talitos_a=
lloc_chan_resources;
> + =C2=A0 =C2=A0 =C2=A0 dma_dev->device_free_chan_resources =3D talitos_fr=
ee_chan_resources;
> + =C2=A0 =C2=A0 =C2=A0 dma_dev->device_prep_dma_xor =3D talitos_prep_dma_=
xor;
> + =C2=A0 =C2=A0 =C2=A0 dma_dev->max_xor =3D max_xor_srcs;
> + =C2=A0 =C2=A0 =C2=A0 dma_dev->device_is_tx_complete =3D talitos_is_tx_c=
omplete;
> + =C2=A0 =C2=A0 =C2=A0 dma_dev->device_issue_pending =3D talitos_issue_pe=
nding;
> + =C2=A0 =C2=A0 =C2=A0 INIT_LIST_HEAD(&dma_dev->channels);
> + =C2=A0 =C2=A0 =C2=A0 dma_cap_set(DMA_XOR, dma_dev->cap_mask);
> +
> + =C2=A0 =C2=A0 =C2=A0 xor_chan->dev =3D dev;
> + =C2=A0 =C2=A0 =C2=A0 xor_chan->common.device =3D dma_dev;
> + =C2=A0 =C2=A0 =C2=A0 xor_chan->total_desc =3D 0;
> + =C2=A0 =C2=A0 =C2=A0 INIT_LIST_HEAD(&xor_chan->submit_q);
> + =C2=A0 =C2=A0 =C2=A0 INIT_LIST_HEAD(&xor_chan->pending_q);
> + =C2=A0 =C2=A0 =C2=A0 INIT_LIST_HEAD(&xor_chan->in_progress_q);
> + =C2=A0 =C2=A0 =C2=A0 INIT_LIST_HEAD(&xor_chan->free_desc);
> + =C2=A0 =C2=A0 =C2=A0 spin_lock_init(&xor_chan->desc_lock);
> +
> + =C2=A0 =C2=A0 =C2=A0 list_add_tail(&xor_chan->common.device_node, &dma_=
dev->channels);
> + =C2=A0 =C2=A0 =C2=A0 dma_dev->chancnt++;
> +
> + =C2=A0 =C2=A0 =C2=A0 err =3D dma_async_device_register(dma_dev);
> + =C2=A0 =C2=A0 =C2=A0 if (err) {
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 dev_err(dev, "Unable t=
o register XOR with Async_tx\n");
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 goto err_out;
> + =C2=A0 =C2=A0 =C2=A0 }
> +
> + =C2=A0 =C2=A0 =C2=A0 return err;
> +
> +err_out:
> + =C2=A0 =C2=A0 =C2=A0 talitos_unregister_async_xor(dev);
> + =C2=A0 =C2=A0 =C2=A0 return err;
> +}
> +#endif /* CONFIG_CRYPTO_DEV_TALITOS_RAIDXOR */
> =C2=A0/*
> =C2=A0* crypto alg
> =C2=A0*/
> @@ -1768,6 +2143,10 @@ static int talitos_remove(struct of_device *ofdev)
> =C2=A0 =C2=A0 =C2=A0 =C2=A0tasklet_kill(&priv->done_task);
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0iounmap(priv->reg);
> +#ifdef CONFIG_CRYPTO_DEV_TALITOS_RAIDXOR
> + =C2=A0 =C2=A0 =C2=A0 if (priv->dma_dev_common.chancnt)
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 talitos_unregister_asy=
nc_xor(dev);
> +#endif /* CONFIG_CRYPTO_DEV_TALITOS_RAIDXOR */
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0dev_set_drvdata(dev, NULL);
>
> @@ -1926,6 +2305,27 @@ static int talitos_probe(struct of_device *ofdev,
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0dev_info(dev, "hwrng\n");
> =C2=A0 =C2=A0 =C2=A0 =C2=A0}
>
> +#ifdef CONFIG_CRYPTO_DEV_TALITOS_RAIDXOR
> + =C2=A0 =C2=A0 =C2=A0 /*
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0* register with async_tx xor, if capable
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0* SEC 2.x support up to 3 RAID sources,
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0* SEC 3.x support up to 6
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0*/
> + =C2=A0 =C2=A0 =C2=A0 if (hw_supports(dev, DESC_HDR_SEL0_AESU | DESC_HDR=
_TYPE_RAID_XOR)) {
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 int max_xor_srcs =3D 3=
;
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (of_device_is_compa=
tible(np, "fsl,sec3.0"))
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 max_xor_srcs =3D 6;
> +
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 err =3D talitos_regist=
er_async_tx(dev, max_xor_srcs);
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (err) {
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 dev_err(dev, "failed to register async_tx xor: %d\n",
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 err);
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 goto err_out;
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 dev_info(dev, "max_xor=
_srcs %d\n", max_xor_srcs);
> + =C2=A0 =C2=A0 =C2=A0 }
> +#endif /* CONFIG_CRYPTO_DEV_TALITOS_RAIDXOR */
> +
> =C2=A0 =C2=A0 =C2=A0 =C2=A0/* register crypto algorithms the device suppo=
rts */
> =C2=A0 =C2=A0 =C2=A0 =C2=A0for (i =3D 0; i < ARRAY_SIZE(driver_algs); i++=
) {
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if (hw_supports(de=
v, driver_algs[i].desc_hdr_template)) {
> diff --git a/drivers/crypto/talitos.h b/drivers/crypto/talitos.h
> index ff5a145..b6197bc 100644
> --- a/drivers/crypto/talitos.h
> +++ b/drivers/crypto/talitos.h
> @@ -155,6 +155,7 @@
> =C2=A0/* primary execution unit mode (MODE0) and derivatives */
> =C2=A0#define =C2=A0 =C2=A0 =C2=A0 =C2=A0DESC_HDR_MODE0_ENCRYPT =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0cpu_to_be32(0x00100000)
> =C2=A0#define =C2=A0 =C2=A0 =C2=A0 =C2=A0DESC_HDR_MODE0_AESU_CBC =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 cpu_to_be32(0x00200000)
> +#define =C2=A0 =C2=A0 =C2=A0 =C2=A0DESC_HDR_MODE0_AESU_XOR =C2=A0 =C2=A0=
=C2=A0 =C2=A0 cpu_to_be32(0x0c600000)
> =C2=A0#define =C2=A0 =C2=A0 =C2=A0 =C2=A0DESC_HDR_MODE0_DEU_CBC =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0cpu_to_be32(0x00400000)
> =C2=A0#define =C2=A0 =C2=A0 =C2=A0 =C2=A0DESC_HDR_MODE0_DEU_3DES =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 cpu_to_be32(0x00200000)
> =C2=A0#define =C2=A0 =C2=A0 =C2=A0 =C2=A0DESC_HDR_MODE0_MDEU_INIT =C2=A0 =
=C2=A0 =C2=A0 =C2=A0cpu_to_be32(0x01000000)
> @@ -202,6 +203,7 @@
> =C2=A0#define DESC_HDR_TYPE_IPSEC_ESP =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0cpu_to_be32(1 << 3)
> =C2=A0#define DESC_HDR_TYPE_COMMON_NONSNOOP_NO_AFEU =C2=A0cpu_to_be32(2 <=
< 3)
> =C2=A0#define DESC_HDR_TYPE_HMAC_SNOOP_NO_AFEU =C2=A0 =C2=A0 =C2=A0 cpu_t=
o_be32(4 << 3)
> +#define DESC_HDR_TYPE_RAID_XOR =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
=C2=A0 =C2=A0 cpu_to_be32(21 << 3)
>
> =C2=A0/* link table extent field bits */
> =C2=A0#define DESC_PTR_LNKTBL_JUMP =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 0x80
> --
> 1.6.4.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at =C2=A0http://vger.kernel.org/majordomo-info.html
>
--=20
The simplest is not all best but the best is surely the simplest!
^ permalink raw reply
* Re: [PATCH 4/7] Allow sysfs memory directories to be split
From: KAMEZAWA Hiroyuki @ 2010-07-14 3:25 UTC (permalink / raw)
To: Nathan Fontenot; +Cc: linuxppc-dev, linux-kernel, Dave Hansen
In-Reply-To: <4C3D2C6B.3050203@austin.ibm.com>
On Tue, 13 Jul 2010 22:18:03 -0500
Nathan Fontenot <nfont@austin.ibm.com> wrote:
> On 07/13/2010 07:35 PM, KAMEZAWA Hiroyuki wrote:
> > On Tue, 13 Jul 2010 10:51:58 -0500
> > Nathan Fontenot <nfont@austin.ibm.com> wrote:
> >
> >>>
> >>> And for what purpose this interface is ? Does this split memory block into 2 pieces
> >>> of the same size ?? sounds __very__ strange interface to me.
> >>
> >> Yes, this splits the memory_block into two blocks of the same size. This was
> >> suggested as something we may want to do. From ppc perspective I am not sure we
> >> would use this.
> >>
> >> The split functionality is not required. The main goal of the patch set is to
> >> reduce the number of memory sysfs directories created. From a ppc perspective
> >> the split functionality is not really needed.
> >>
> >
> > Okay, this is an offer from me.
> >
> > 1. I think you can add an boot option as "don't create memory sysfs".
> > please do.
>
> I posted a patch to do that a week or so ago, it didn't go over very well.
>
> >
> > 2. I'd like to write a configfs module for handling memory hotplug even when
> > sysfs directroy is not created.
> > Because configfs support rmdir/mkdir, the user (ppc's daemon?) has to do
> >
> > When offlining section X.
> > # insmod configfs_memory.ko
> > # mount -t configfs none /configfs
> > # mkdir /configfs/memoryX
> > # echo offline > /configfs/memoryX/state
> > # rmdir /configfs/memoryX
> >
> > And making this operation as the default bahavior for all arch's memory hotplug may
> > be better...
> >
> > Dave, how do you think ? Because ppc guys uses "probe" interface already,
> > this can be handled... no ?
>
> ppc would still require the existance of the 'probe' interface.
>
> Are you objecting to the 'split' functionality?
yes.
> If so I do not see any reason from ppc
> perspective that it is needed. This was something Dave suggested, unless I am missing
> something.
>
> Since ppc needs the 'probe' interface in sysfs, and for ppc having mutliple
> memory_block_sections reside under a single memory_block makes memory hotplug
> simpler. On ppc we do emory hotplug operations on an LMB size basis. With my
> patches this now lets us set each memory_block to span an LMB's worth of
> memory. Now we could do emory hotplug in a single operation instead of multiple
> operations to offline/online all of the memory sections in an LMB.
>
Why per-section memory offlining is provided is for allowing good success-rate of
memory offlining. Because memory-hotplug has to "migrate or free" all used page
under a section, possibility of memory unplug depends on usage of memory.
If a section contains unmovable page(kernel page), we can't offline sectin.
For example, comparing
1. offlining 128MB of memory at once
2. offlining 8 chunks of 16MB memory
"2" can get very good possibility and system-busy time can be much reduced.
IIUC, ppc's 1st requirement is "resizing" not "hot-removing some memory device",
"2" is much welcomed. So, some fine-grained interface to section_size is
appreciated. So, "multiple operations" is much better than single operation.
As I posted show/hide patch, I'm writing it in configfs. I think it meets IBM's
requirements.
_But_, it's IBM's issue not Fujitsu's. So, final decistion will depend on you guys.
Anyway, I don't like a too fancy interface as "split".
Thanks,
-Kame
^ permalink raw reply
* Re: [PATCH 4/7] Allow sysfs memory directories to be split
From: Dave Hansen @ 2010-07-14 3:26 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20100714093550.40036034.kamezawa.hiroyu@jp.fujitsu.com>
On Wed, 2010-07-14 at 09:35 +0900, KAMEZAWA Hiroyuki wrote:
> 2. I'd like to write a configfs module for handling memory hotplug even when
> sysfs directroy is not created.
> Because configfs support rmdir/mkdir, the user (ppc's daemon?) has to do
>
> When offlining section X.
> # insmod configfs_memory.ko
> # mount -t configfs none /configfs
> # mkdir /configfs/memoryX
> # echo offline > /configfs/memoryX/state
> # rmdir /configfs/memoryX
>
> And making this operation as the default bahavior for all arch's memory hotplug may
> be better...
>
> Dave, how do you think ? Because ppc guys uses "probe" interface already,
> this can be handled... no ?
I think creating a interface to duplicate the existing sysfs one is a
bad idea. I also think removing the existing sysfs one isn't feasible
since there are users, and it's truly part of the ABI. So, I'm not
really a fan on the configfs interface. :(
I really do think the sysfs interface is fixable. We should at least
give it a good shot before largely duplicating its functionality.
-- Dave
^ permalink raw reply
* Re: [PATCH 4/7] Allow sysfs memory directories to be split
From: Nathan Fontenot @ 2010-07-14 3:18 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki; +Cc: linuxppc-dev, linux-kernel, Dave Hansen
In-Reply-To: <20100714093550.40036034.kamezawa.hiroyu@jp.fujitsu.com>
On 07/13/2010 07:35 PM, KAMEZAWA Hiroyuki wrote:
> On Tue, 13 Jul 2010 10:51:58 -0500
> Nathan Fontenot <nfont@austin.ibm.com> wrote:
>
>>>
>>> And for what purpose this interface is ? Does this split memory block into 2 pieces
>>> of the same size ?? sounds __very__ strange interface to me.
>>
>> Yes, this splits the memory_block into two blocks of the same size. This was
>> suggested as something we may want to do. From ppc perspective I am not sure we
>> would use this.
>>
>> The split functionality is not required. The main goal of the patch set is to
>> reduce the number of memory sysfs directories created. From a ppc perspective
>> the split functionality is not really needed.
>>
>
> Okay, this is an offer from me.
>
> 1. I think you can add an boot option as "don't create memory sysfs".
> please do.
I posted a patch to do that a week or so ago, it didn't go over very well.
>
> 2. I'd like to write a configfs module for handling memory hotplug even when
> sysfs directroy is not created.
> Because configfs support rmdir/mkdir, the user (ppc's daemon?) has to do
>
> When offlining section X.
> # insmod configfs_memory.ko
> # mount -t configfs none /configfs
> # mkdir /configfs/memoryX
> # echo offline > /configfs/memoryX/state
> # rmdir /configfs/memoryX
>
> And making this operation as the default bahavior for all arch's memory hotplug may
> be better...
>
> Dave, how do you think ? Because ppc guys uses "probe" interface already,
> this can be handled... no ?
ppc would still require the existance of the 'probe' interface.
Are you objecting to the 'split' functionality? If so I do not see any reason from ppc
perspective that it is needed. This was something Dave suggested, unless I am missing
something.
Since ppc needs the 'probe' interface in sysfs, and for ppc having mutliple
memory_block_sections reside under a single memory_block makes memory hotplug
simpler. On ppc we do emory hotplug operations on an LMB size basis. With my
patches this now lets us set each memory_block to span an LMB's worth of
memory. Now we could do emory hotplug in a single operation instead of multiple
operations to offline/online all of the memory sections in an LMB.
Of course the easy solution would be to increase SECTION_SIZE_BITS, but we need
support hardware that can have LMB's from 16 MB to 256 MB in size so the
SECTION_SIZE_BITS value has to remain small.
>
> One problem is that I don't have enough knowledge about configfs..it seems complex.
Me neither, thoug I will take a look at it.
-Nathan
^ permalink raw reply
* Re: [PATCH] kbuild: Enable building defconfigs from Kconfig files
From: Grant Likely @ 2010-07-14 2:26 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Michal Marek, Linus, LKML, Russell King, Catalin Marinas,
Andrew Morton, ppc-dev, linux-arm-kernel
In-Reply-To: <20100713114322.57c8b166.sfr@canb.auug.org.au>
[cc'ing rmk and linux-arm-kernel]
On Mon, Jul 12, 2010 at 7:43 PM, Stephen Rothwell <sfr@canb.auug.org.au> wr=
ote:
> After this change, doing a "make xxx_defconfig" will check first for
> a file called arch/<arch>/configs/Kconfig.xxx and use that to generate
> the .config (effectively starting from an allnoconfig). =A0If that file
> doesn't exist, it will use arch/<ARCH>/configs/xxx_defconfig as now.
Oops, I hadn't seen this patch when I wrote mine this afternoon[1].
:-) A few minor differences, but essentially the same solution.
[1] http://patchwork.ozlabs.org/patch/58823/
I chose to use -D /dev/null (defconfig from an empty file) instead of
-n (allnoconfig) so that default values in Kconfig would get
respected. For the benefit of everyone else, here's an excerpt from
our IRC conversation this afternoon:
19:49 < gcl> sfr: [...] Your patch and my patch are
essentially doing exactly the same thing, except that I used '=
-d'
and you used '-n'.
19:50 < gcl> s/-d/-D/
19:55 < sfr> right
19:55 < sfr> Linus wanted us to use -n
19:55 < sfr> because that way you get what you asked for, not what the defa=
ults
say ...
19:58 < gcl> I suppose we don't currently have a way to say "select FOO=3Dn=
", so
I suppose that makes sense
19:58 < gcl> although I think using the defaults unless told not to is a be=
tter
approach in the long run
19:59 < gcl> most of the time I *don't want* to ask for something in the
defconfig. :-)
20:00 < gcl> I just want TheBestOrCorrectAnswer to be chosen for me
20:04 < sfr> gcl: go read Linus' vision :-)
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> =A0scripts/kconfig/Makefile | =A0 14 +++++++++++++-
> =A01 files changed, 13 insertions(+), 1 deletions(-)
>
> Hi Linus,
>
> Is this more the direction you want to take?
>
> There are still 2 main problems with is approach:
>
> =A0 =A0 =A0 =A0- there are some config options that are globally and
> unconditionally enabled that some platforms may not want. =A0The only way
> currently to turn them off is to reproduce the config entry with the
> different default. =A0I am not sure if we need a wa to turn them off or t=
o
> just change them to being neede to be selected by those that do want them=
.
> =A0 =A0 =A0 =A0- we have no way to select options that are neither bool o=
r
> tristate to suitable values. =A0Again the only way to do that currently i=
s
> to reproduce the config entry with a different default value.
For both of the above problems, what if we added syntax like the
following to Kconfig?
config FOO
bool
select BAR =3D n
select FOO_VALUE =3D 54
> I am currently working towards using this to recreate the PowerPC
> defconfigs, but it is a slow process as they have some much stuff enabled
> in them and some of it is probably actually not relevant.
If the trimmed configs are merged, then there is no rush on this. We
can keep them around and switch them over as people want to make
changes.
> This process is made easier by the recent commit "kbuild: Warn on
> selecting symbols with unmet direct dependencies" that is in the kbuild
> tree (and linux-next).
Ah, I didn't know that change was being merged. That indeed makes
things easier, and eliminates the post-test that I do to make sure
that the resulting config is actually valid.
> diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
> index 7ea649d..1ab8f45 100644
> --- a/scripts/kconfig/Makefile
> +++ b/scripts/kconfig/Makefile
> @@ -117,9 +117,21 @@ else
> =A0 =A0 =A0 =A0$(Q)$< -D arch/$(SRCARCH)/configs/$(KBUILD_DEFCONFIG) $(Kc=
onfig)
> =A0endif
>
> -%_defconfig: $(obj)/conf
> +configs_dir :=3D $(srctree)/arch/$(SRCARCH)/configs
> +# We check a level of sub directories because arch/powerpc
> +# has its defconfig files arranged that way
> +old_defconfigs :=3D $(patsubst $(configs_dir)/%,%,\
> + =A0 =A0 =A0 $(wildcard $(configs_dir)/*_defconfig) \
> + =A0 =A0 =A0 $(wildcard $(configs_dir)/*/*_defconfig))
> +defconfigs :=3D $(patsubst $(configs_dir)/Kconfig.%,%_defconfig,\
> + =A0 =A0 =A0 $(wildcard $(configs_dir)/Kconfig.*))
> +
Ugh. My first impression is that all this shouldn't be necessary, and
it should be okay to just make the two following rules include a
pattern dependency for the source file. However, as I play with it, I
cannot seem to get the rules right to handle the sub directories. The
$(defconfigs) patsubst at least could be done solely with dependencies
on the target rule if the files were named *.Kconfig instead of
Kconfig.* (because subdirectories are not handled in that case). For
example:
%_defconfig: $(obj)/conf arch/$(SRCARCH)/configs/%.Kconfig
$(Q)$< -n arch/$(SRCARCH)/configs/$*.Kconfig
> +$(old_defconfigs): %_defconfig: $(obj)/conf
> =A0 =A0 =A0 =A0$(Q)$< -D arch/$(SRCARCH)/configs/$@ $(Kconfig)
>
> +$(defconfigs): %_defconfig: $(obj)/conf
> + =A0 =A0 =A0 $(Q)$< -n arch/$(SRCARCH)/configs/Kconfig.$*
> +
> =A0# Help text used by make help
> =A0help:
> =A0 =A0 =A0 =A0@echo =A0' =A0config =A0 =A0 =A0 =A0 =A0- Update current c=
onfig utilising a line-oriented program'
Cheers,
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 4/7] Allow sysfs memory directories to be split
From: KAMEZAWA Hiroyuki @ 2010-07-14 0:35 UTC (permalink / raw)
To: Nathan Fontenot; +Cc: linuxppc-dev, linux-kernel, Dave Hansen
In-Reply-To: <4C3C8B9E.7000208@austin.ibm.com>
On Tue, 13 Jul 2010 10:51:58 -0500
Nathan Fontenot <nfont@austin.ibm.com> wrote:
> >
> > And for what purpose this interface is ? Does this split memory block into 2 pieces
> > of the same size ?? sounds __very__ strange interface to me.
>
> Yes, this splits the memory_block into two blocks of the same size. This was
> suggested as something we may want to do. From ppc perspective I am not sure we
> would use this.
>
> The split functionality is not required. The main goal of the patch set is to
> reduce the number of memory sysfs directories created. From a ppc perspective
> the split functionality is not really needed.
>
Okay, this is an offer from me.
1. I think you can add an boot option as "don't create memory sysfs".
please do.
2. I'd like to write a configfs module for handling memory hotplug even when
sysfs directroy is not created.
Because configfs support rmdir/mkdir, the user (ppc's daemon?) has to do
When offlining section X.
# insmod configfs_memory.ko
# mount -t configfs none /configfs
# mkdir /configfs/memoryX
# echo offline > /configfs/memoryX/state
# rmdir /configfs/memoryX
And making this operation as the default bahavior for all arch's memory hotplug may
be better...
Dave, how do you think ? Because ppc guys uses "probe" interface already,
this can be handled... no ?
One problem is that I don't have enough knowledge about configfs..it seems complex.
Thanks,
-Kame
^ permalink raw reply
* Re: optimized script [Was: ARM defconfig files]
From: Nicolas Pitre @ 2010-07-13 23:39 UTC (permalink / raw)
To: Olof Johansson
Cc: Stephen Rothwell, Daniel Walker, Russell King - ARM Linux,
Kevin Hilman, linux-arm-msm, linuxppc-dev,
Linux Kernel Mailing List, Eric Miao, Uwe Kleine-König,
linux-omap, Linus Torvalds, linux-arm-kernel
In-Reply-To: <20100713180402.GA1422@lixom.net>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2203 bytes --]
On Tue, 13 Jul 2010, Olof Johansson wrote:
> On Tue, Jul 13, 2010 at 10:07:05AM +0200, Uwe Kleine-König wrote:
> > Hello,
> >
> > On Tue, Jul 13, 2010 at 09:07:41AM +0200, Uwe Kleine-König wrote:
> > > Hi
> > >
> > > On Mon, Jul 12, 2010 at 01:50:47PM -0600, Grant Likely wrote:
> > > > On Mon, Jul 12, 2010 at 1:34 PM, Linus Torvalds
> > > > <torvalds@linux-foundation.org> wrote:
> > > > > On Mon, Jul 12, 2010 at 12:17 PM, Nicolas Pitre <nico@fluxnic.net> wrote:
> > > > >> I think Uwe could provide his script and add it to the kernel tree.
> > > > >> Then all architectures could benefit from it. Having the defconfig
> > > > >> files contain only those options which are different from the defaults
> > > > >> is certainly more readable, even on x86.
> > > > >
> > > > > Quite possible. But maintainers would need to be on the lookout of
> > > > > people actually using the script, and refusing to apply patches that
> > > > > re-introduce the whole big thing.
> > > >
> > > > I can (partially) speak for powerpc. If ARM uses this approach, then
> > > > I think we can do the same. After the defconfigs are trimmed, I
> > > > certainly won't pick up any more full defconfigs.
> > > I just restarted my script on the powerpc defconfigs basing on rc5, I
> > > assume they complete in a few days time.
> > So Stephen was faster than me. I don't know yet how he optimised my
> > script, meanwhile I put some efforts into it, too by just checking lines
> > that match "^(# )?CONFIG_".
> >
> > Find it attached.
> >
> > I will start to reduce the remaining configs (i.e. all but arm and
> > powerpc).
>
> I added just a simple heuristic: If I could remove a line, I attempted
> to remove twice the amount next time around (and fall back to 1 if it failed).
>
[...]
>
> While this script is great, it is somewhat painful to run given that it
> attempts one config per line. Even on a fast machine that tends to take
> a while.
The optimal solution is to add that .config reduction ability straight
into the Kconfig parser (scripts/kconfig/*). There you can find out
right away what are the non default state for each config option without
actually trying them out one by one.
Nicolas
^ permalink raw reply
* Re: [RFC PATCH] Kconfig: Enable Kconfig fragments to be used for defconfig
From: Nicolas Pitre @ 2010-07-14 0:07 UTC (permalink / raw)
To: Daniel Walker
Cc: linux-kbuild, Tony Lindgren, linux-kernel, Linus Torvalds,
Russell King, Uwe Kleine-König, linuxppc-dev,
linux-arm-kernel
In-Reply-To: <1279064008.4609.48.camel@c-dwalke-linux.qualcomm.com>
On Tue, 13 Jul 2010, Daniel Walker wrote:
> On Tue, 2010-07-13 at 17:21 -0600, Grant Likely wrote:
> > On Tue, Jul 13, 2010 at 5:14 PM, Daniel Walker <dwalker@codeaurora.org> wrote:
> > > It just doesn't feel like Kconfig was meant to do this, it feel like
> > > somewhat of an abuse ..
> >
> > Why? It uses the Kconfig language itself to specify additional
> > constraints on the final configuration. Seems to be the essence of
> > elegance to me. :-)
>
> To my mind the only problem with the current defconfig formatting is the
> size of the files. If those files are 5-10 lines instead of 2000 lines,
> then I think the readability problem isn't really an issue any more..
That's one issue indeed.
But there is another issue that is somewhat related, which is to be able
to categorize config options.
Currently the defconfig files carry information about the proper driver
to enable in order to support devices soldered on the board and
therefore which are not "optional". That might be a particular RTC
chip, or a particular ethernet block integrated into a SOC, etc. Of
course we want to preserve the ability to disable support for those
things, but by default people want to have all the right drivers
selected for all the built-in hardware when selecting a target
machine/board without having to dig into a datasheet for that target.
The defconfig files also carry config options that are totally
arbitrary. What type of filesystem, what kind of network protocol, what
USB device drivers (not host controller driver), what amount of
debugging options, all those are unrelated to the actual hardware and
may vary from one user to another.
Furthermore, in order to reduce the number of defconfig files, we tried
to combine as many targets into a single kernel image. That increases
build test coverage with fewer builds which is good, but then the info
about specific drivers required for a specific target but not for
another target in the same defconfig is now lost. It is therefore quite
hard to produce a highly optimized configuration for a single target
without doing some digging again.
So it is really in the Kconfig file that all those hardware specific
options can be expressed in a clear and readable way. When BOARD_XYZ is
selected and STD_CONFIG is selected, then automatically select RTC_FOO,
select ETH_BAR, select LED_BAZ, etc. Of course we would want required
dependencies to be automatically selected as well.
But all the rest is arbitrary and could be part of common shared
profiles or the like in defconfig format.
Nicolas
^ permalink raw reply
* Re: [RFC PATCH] Kconfig: Enable Kconfig fragments to be used for defconfig
From: Daniel Walker @ 2010-07-13 23:33 UTC (permalink / raw)
To: Grant Likely
Cc: linux-kbuild, Tony Lindgren, Nicolas Pitre, linux-kernel,
Linus Torvalds, Russell King, Uwe Kleine-König, linuxppc-dev,
linux-arm-kernel
In-Reply-To: <AANLkTin69tN3NQHD2wvkA0G-lj3f9tSZEnhzdyJdTh9m@mail.gmail.com>
On Tue, 2010-07-13 at 17:21 -0600, Grant Likely wrote:
> On Tue, Jul 13, 2010 at 5:14 PM, Daniel Walker <dwalker@codeaurora.org> wrote:
> > On Tue, 2010-07-13 at 17:04 -0600, Grant Likely wrote:
> >
> >> - I haven't figured out a way for the fragment to force an option to
> >> be "n", or to set a value, for example "CONFIG_LOG_BUF_SHIFT=16".
> >> This may require changing the syntax.
> >> - It still doesn't resolve dependencies. A solver would help with this.
> >> For the time being I work around the problem by running the generated
> >> config through 'oldconfig' and looking for differences. If the files
> >> differ (ignoring comments and generateconfig_* options) after oldconfig,
> >> then the <board>_defconfig target returns a failure. (but leaves the
> >> new .config intact so the user can resolve it with menuconfig). This
> >> way at least the user is told when a Kconfig fragment is invalid.
> >
> > The solver would fix the whole issues with the defconfigs , we wouldn't
> > need this Kconfig change .. From my perspective we shouldn't be fooling
> > around with anything but the solver approach ..
>
> The solver would complement Kconfig fragments, but it doesn't
> implement all the functionality. For instance, it doesn't help a
> board config picking up a bunch of options from an SoC or Architecture
> config file, especially things that are developer/maintainer choices
> as opposed to hard requirements). Solver on its own is an incremental
> improvement over what we currently have, but it doesn't solve the
> whole problem.
I don't understand what your saying here.. Imagine a defconfig that you
have now only drastically smaller. The solver picks the stuff that
doesn't exist already in the defconfig. You would just apply the solver
to whatever is in the defconfig.
Then that allows us to keep the current defconfig format without mass
converting to something else. It's would also be built on a solver that
helps with other issues within Kconfig.
> > It just doesn't feel like Kconfig was meant to do this, it feel like
> > somewhat of an abuse ..
>
> Why? It uses the Kconfig language itself to specify additional
> constraints on the final configuration. Seems to be the essence of
> elegance to me. :-)
To my mind the only problem with the current defconfig formatting is the
size of the files. If those files are 5-10 lines instead of 2000 lines,
then I think the readability problem isn't really an issue any more..
The point of using Kconfig was the readability..
Daniel
--
Sent by an consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* Re: [RFC PATCH] Kconfig: Enable Kconfig fragments to be used for defconfig
From: Daniel Walker @ 2010-07-13 23:14 UTC (permalink / raw)
To: Grant Likely
Cc: linux-kbuild, Tony Lindgren, Nicolas Pitre, linux-kernel,
Linus Torvalds, Russell King, Uwe Kleine-König, linuxppc-dev,
linux-arm-kernel
In-Reply-To: <20100713230352.6781.18644.stgit@angua>
On Tue, 2010-07-13 at 17:04 -0600, Grant Likely wrote:
> - I haven't figured out a way for the fragment to force an option to
> be "n", or to set a value, for example "CONFIG_LOG_BUF_SHIFT=16".
> This may require changing the syntax.
> - It still doesn't resolve dependencies. A solver would help with this.
> For the time being I work around the problem by running the generated
> config through 'oldconfig' and looking for differences. If the files
> differ (ignoring comments and generateconfig_* options) after oldconfig,
> then the <board>_defconfig target returns a failure. (but leaves the
> new .config intact so the user can resolve it with menuconfig). This
> way at least the user is told when a Kconfig fragment is invalid.
The solver would fix the whole issues with the defconfigs , we wouldn't
need this Kconfig change .. From my perspective we shouldn't be fooling
around with anything but the solver approach ..
It just doesn't feel like Kconfig was meant to do this, it feel like
somewhat of an abuse ..
Daniel
--
Sent by an consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* Re: [RFC PATCH] Kconfig: Enable Kconfig fragments to be used for defconfig
From: Grant Likely @ 2010-07-13 23:21 UTC (permalink / raw)
To: Daniel Walker
Cc: linux-kbuild, Tony Lindgren, Nicolas Pitre, linux-kernel,
Linus Torvalds, Russell King, Uwe Kleine-König, linuxppc-dev,
linux-arm-kernel
In-Reply-To: <1279062881.4609.34.camel@c-dwalke-linux.qualcomm.com>
On Tue, Jul 13, 2010 at 5:14 PM, Daniel Walker <dwalker@codeaurora.org> wro=
te:
> On Tue, 2010-07-13 at 17:04 -0600, Grant Likely wrote:
>
>> - I haven't figured out a way for the fragment to force an option to
>> =A0 be "n", or to set a value, for example "CONFIG_LOG_BUF_SHIFT=3D16".
>> =A0 This may require changing the syntax.
>> - It still doesn't resolve dependencies. =A0A solver would help with thi=
s.
>> =A0 For the time being I work around the problem by running the generate=
d
>> =A0 config through 'oldconfig' and looking for differences. =A0If the fi=
les
>> =A0 differ (ignoring comments and generateconfig_* options) after oldcon=
fig,
>> =A0 then the <board>_defconfig target returns a failure. =A0(but leaves =
the
>> =A0 new .config intact so the user can resolve it with menuconfig). =A0T=
his
>> =A0 way at least the user is told when a Kconfig fragment is invalid.
>
> The solver would fix the whole issues with the defconfigs , we wouldn't
> need this Kconfig change .. From my perspective we shouldn't be fooling
> around with anything but the solver approach ..
The solver would complement Kconfig fragments, but it doesn't
implement all the functionality. For instance, it doesn't help a
board config picking up a bunch of options from an SoC or Architecture
config file, especially things that are developer/maintainer choices
as opposed to hard requirements). Solver on its own is an incremental
improvement over what we currently have, but it doesn't solve the
whole problem.
> It just doesn't feel like Kconfig was meant to do this, it feel like
> somewhat of an abuse ..
Why? It uses the Kconfig language itself to specify additional
constraints on the final configuration. Seems to be the essence of
elegance to me. :-)
g.
^ permalink raw reply
* Re: [RFC PATCH] Kconfig: Enable Kconfig fragments to be used for defconfig
From: Grant Likely @ 2010-07-13 23:11 UTC (permalink / raw)
To: linuxppc-dev, Nicolas Pitre, Benjamin Herrenschmidt, linux-kbuild,
linux-kernel, linux-arm-kernel, Linus Torvalds, Russell King
Cc: Tony Lindgren, Daniel Walker, Uwe Kleine-König
In-Reply-To: <20100713230352.6781.18644.stgit@angua>
Typo correction:
2010/7/13 Grant Likely <grant.likely@secretlab.ca>:
[...]
> <board>.Kconfig defines new board specific config items (prefixed with
> "generateconfig_" which default to 'y' or 'm' and select the options
> that the platform cares about. =A0It also then either the architecture
s/either the/either includes the/
> default Kconfig, or another Kconfig fragment that includes the default
> one (therefore the fragments can be 'stacked' to include, say, default
> options for the architecture, or particular chipset).
[...]
^ permalink raw reply
* Re: [PATCH 1/9 v1.01] Add Synopsys DesignWare HS USB OTG Controller driver.
From: Feng Kan @ 2010-07-13 23:02 UTC (permalink / raw)
To: Chuck Meade; +Cc: linuxppc-dev, linux-usb, Mark Miesfeld, gregkh, Fushen Chen
In-Reply-To: <4C3CE5BA.5060302@ThePTRGroup.com>
[-- Attachment #1: Type: text/plain, Size: 2069 bytes --]
Chuck:
Thanks for the information. Sorry that we missed the patch. It was not done
out of specific reason.
As you have commented, it is a very large patch with alot of changes. We
wanted to submit
the patch to make sure the fundamental structure of the driver align with
the kernel. Once that
is in place, additional patch will be easier. Fushen will make sure this
change is in place on
the next submission.
Thanks
Feng Kan
On Tue, Jul 13, 2010 at 3:16 PM, Chuck Meade <chuck@theptrgroup.com> wrote:
> On 07/12/2010 07:16 PM, Fushen Chen wrote:
> > The DWC OTG driver module provides the initialization and cleanup
> > entry points for the DWC OTG USB driver.
> >
> > Signed-off-by: Fushen Chen <fchen@apm.com>
> > Signed-off-by: Mark Miesfeld <mmiesfeld@apm.com>
> > ---
>
> This reply is to the patch series, not just this 1/9 patch section.
>
> Fushen, why did you pick and choose which fixes to incorporate from the
> Denx
> tree's version of the dwc_otg driver?
>
> I'm not taking the time here to go through this multipart patch and check
> that
> you incorporated every fix, but I *did* randomly pick one fix that I made
> to that
> driver, to see if you incorporated it, and it appears you did not.
> I would have expected that you would have incorporated the fixes that were
> made
> to this driver in the Denx tree.
>
> The one that I checked is in the data toggle error interrupt handling, in
> handle_hc_chhltd_intr_dma() (see your 5/9 email in this patch series). It
> looks
> like you left out the fix I made to this logic that averts an interrupt
> storm.
>
> I assume that since I checked one particular fix, and it was missing from
> your
> patch series, that there are likely more fixes you omitted. Can you
> explain why
> you would leave this out, after Stefan asked you to incorporate the code
> changes
> made in the Denx tree's version of the driver?
>
> Chuck
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
--
Feng Kan
[-- Attachment #2: Type: text/html, Size: 2865 bytes --]
^ permalink raw reply
* [RFC PATCH] Kconfig: Enable Kconfig fragments to be used for defconfig
From: Grant Likely @ 2010-07-13 23:04 UTC (permalink / raw)
To: linuxppc-dev, Nicolas Pitre, Benjamin Herrenschmidt, linux-kbuild,
linux-kernel, linux-arm-kernel, Linus Torvalds, Russell King
Cc: Tony Lindgren, Daniel Walker, Uwe Kleine-König
This is a proof of concept at the moment, but if the corner cases
can be sorted out, then this might be the best way to replace
the defconfig functionality. This patch implements Linus' idea
for using Kconfig fragments to replicate the *_defconfig functionality
Essentially, this patch adds a new <board>_defconfig target that is
processed if a <board>.Kconfig file is present in the $(ARCH)/configs
directory instead of the current <board>_defconfig file. The target
works by passing the $(ARCH)/configs/<board>.Kconfig to Kconfig
instead of the architecture's default $(ARCH)/Kconfig file.
<board>.Kconfig defines new board specific config items (prefixed with
"generateconfig_" which default to 'y' or 'm' and select the options
that the platform cares about. It also then either the architecture
default Kconfig, or another Kconfig fragment that includes the default
one (therefore the fragments can be 'stacked' to include, say, default
options for the architecture, or particular chipset).
This patch includes sample Kconfig fragments for the PowerPC 83xx and
5200 platforms to demonstrate the concept, but it should work in exactly
the same way for ARM or any other architecture. With the sample,
'mpc5200_defconfig', 'mpc83xx_defconfig' and even 'ppc32_defconfig' are
all valid targets (although the ppc32_defconfig won't actually include
any particular board support).
An interesting side effect of this approach is that it can be used to
'overlay' the configuration for a board over top of the existing config.
I went ahead and added the %_oldconfig option to do this which could
be useful for building a kernel that supports multiple boards, or for
adding in a set of debug options.
Another advantage of this approach is that it doesn't immediately
eliminate the old defconfig files so that platforms can be migrated to
this new method one at a time.
Current problems:
- I haven't figured out a way for the fragment to force an option to
be "n", or to set a value, for example "CONFIG_LOG_BUF_SHIFT=16".
This may require changing the syntax.
- It still doesn't resolve dependencies. A solver would help with this.
For the time being I work around the problem by running the generated
config through 'oldconfig' and looking for differences. If the files
differ (ignoring comments and generateconfig_* options) after oldconfig,
then the <board>_defconfig target returns a failure. (but leaves the
new .config intact so the user can resolve it with menuconfig). This
way at least the user is told when a Kconfig fragment is invalid.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
arch/powerpc/configs/mpc5200.Kconfig | 24 +++++++++++++++++++++
arch/powerpc/configs/mpc83xx.Kconfig | 35 +++++++++++++++++++++++++++++++
arch/powerpc/configs/ppc32.Kconfig | 39 ++++++++++++++++++++++++++++++++++
scripts/kconfig/Makefile | 18 +++++++++++++++-
4 files changed, 115 insertions(+), 1 deletions(-)
create mode 100644 arch/powerpc/configs/mpc5200.Kconfig
create mode 100644 arch/powerpc/configs/mpc83xx.Kconfig
create mode 100644 arch/powerpc/configs/ppc32.Kconfig
diff --git a/arch/powerpc/configs/mpc5200.Kconfig b/arch/powerpc/configs/mpc5200.Kconfig
new file mode 100644
index 0000000..1281dd1
--- /dev/null
+++ b/arch/powerpc/configs/mpc5200.Kconfig
@@ -0,0 +1,24 @@
+config generateconfig_MPC5200_YES
+ def_bool y
+ select PPC_MPC52xx
+ select PPC_MPC5200_SIMPLE
+ select PPC_EFIKA
+ select PPC_LITE5200
+ select PPC_MEDIA5200
+ select PPC_MPC5200_BUGFIX
+ select PPC_MPC5200_GPIO
+ select PPC_MPC5200_LPBFIFO
+ select PPC_BESTCOMM
+ select SIMPLE_GPIO
+ select SERIAL_MPC52xx
+ select SERIAL_MPC52xx_CONSOLE
+ select MTD
+ select PATA_MPC52xx
+ select SPI_MPC52xx
+ select SPI_MPC52xx_PSC
+ select I2C_MPC
+ select FEC_MPC52xx
+ select LXT_PHY
+ select WATCHDOG
+
+source arch/powerpc/configs/ppc32.Kconfig
diff --git a/arch/powerpc/configs/mpc83xx.Kconfig b/arch/powerpc/configs/mpc83xx.Kconfig
new file mode 100644
index 0000000..818fdec
--- /dev/null
+++ b/arch/powerpc/configs/mpc83xx.Kconfig
@@ -0,0 +1,35 @@
+config generateconfig_MPC83xx_YES
+ def_bool y
+ select PPC_83xx
+ select EMBEDDED
+ select MPC831x_RDB
+ select MPC832x_MDS
+ select MPC832x_RDB
+ select MPC834x_MDS
+ select MPC834x_ITX
+ select MPC836x_MDS
+ select MPC836x_RDK
+ select MPC837x_MDS
+ select MPC837x_RDB
+ select SBC834x
+ select ASP834x
+ select QUICC_ENGINE
+ select OE_GPIO
+ select MATH_EMULATION
+ select SATA_FSL
+ select SATA_SIL
+ select MARVELL_PHY
+ select DAVICOM_PHY
+ select VITESSE_PHY
+ select ICPLUS_PHY
+ select FIXED_PHY
+ select FSL_PQ_MDIO
+ select GIANFAR
+ select UCC_GETH
+ select SERIAL_8250
+ select SERIAL_8250_CONSOLE
+ select I2C_MPC
+ select GPIOLIB
+ select WATCHDOG
+
+source arch/powerpc/configs/ppc32.Kconfig
diff --git a/arch/powerpc/configs/ppc32.Kconfig b/arch/powerpc/configs/ppc32.Kconfig
new file mode 100644
index 0000000..66e39f0
--- /dev/null
+++ b/arch/powerpc/configs/ppc32.Kconfig
@@ -0,0 +1,39 @@
+config generateconfig_PPC32_YES
+ def_bool y
+ select EXPERIMENTAL
+ select DEVTMPFS
+ select PPC32
+ select SYSVIPC
+ select BLK_DEV_INITRD
+ select NO_HZ
+ select HIGH_RES_TIMERS
+ select GPIO
+ select SPI
+ select SPI_SPIDEV
+ select I2C
+ select I2C_CHARDEV
+ select USB
+ select NET
+ select SCSI
+ select BLK_DEV_SD
+ select ATA
+ select PACKET
+ select UNIX
+ select INET
+ select IP_MULTICAST
+ select IP_PNP
+ select IP_PNP_DHCP
+ select NETDEVICES
+ select NET_ETHERNET
+ select PROC_DEVICETREE
+ select INOTIFY
+ select TMPFS
+ select NFS_FS
+ select ROOT_NFS
+ select PRINTK_TIME
+
+config generateconfig_PPC32_MODULE
+ def_tristate m
+
+source arch/powerpc/Kconfig
+
diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
index 7ea649d..4e9afd9 100644
--- a/scripts/kconfig/Makefile
+++ b/scripts/kconfig/Makefile
@@ -117,7 +117,23 @@ else
$(Q)$< -D arch/$(SRCARCH)/configs/$(KBUILD_DEFCONFIG) $(Kconfig)
endif
-%_defconfig: $(obj)/conf
+# New-style defconfig using Kconfig fragments
+%_defconfig: $(obj)/conf arch/$(SRCARCH)/configs/%.Kconfig
+ $(Q)$< -D /dev/null arch/$(SRCARCH)/configs/$*.Kconfig
+ $(Q)sed '/^#/d;/^CONFIG_generateconfig_/d' $(objtree)/.config > $(objtree)/.config-diff1
+ $(Q)$< -o $(Kconfig) > /dev/null # oldconfig test to make sure it doesn't change
+ $(Q)sed '/^#/d' $(objtree)/.config > $(objtree)/.config-diff2
+ $(Q)diff -u $(objtree)/.config-diff1 $(objtree)/.config-diff2
+
+# This is kind of useful. The new-style defconfig using Kconfig fragments
+# can also be used to successively pull in the options a defconfig cares
+# about overtop of the current config.
+%_oldconfig: $(obj)/conf arch/$(SRCARCH)/configs/%.Kconfig
+ $(Q)$< -o arch/$(SRCARCH)/configs/$*.Kconfig
+ $(Q)$< -o $(Kconfig) > /dev/null # oldconfig to clear out the temporary items
+
+# Old-style defconfig using full (or trimmed) .config files.
+%_defconfig: $(obj)/conf arch/$(SRCARCH)/configs/%_defconfig
$(Q)$< -D arch/$(SRCARCH)/configs/$@ $(Kconfig)
# Help text used by make help
^ permalink raw reply related
* Re: [PATCH 1/9 v1.01] Add Synopsys DesignWare HS USB OTG Controller driver.
From: David Brownell @ 2010-07-13 22:50 UTC (permalink / raw)
To: fushen chen; +Cc: linuxppc-dev, chuck, linux-usb, Mark Miesfeld, gregkh
In-Reply-To: <1279059214.29212.13.camel@localhost.localdomain>
> > and make the OTG functionality
> > key on the generic OTG symbol, not a DW-specific one.
> >
> >
> Use "drivers/usb/otg/otg.c and include/linux/usb/otg.h"?
Maybe; CONFIG_USB_OTG specifically, though
(or whatever that generic symbol is) ...
^ permalink raw reply
* Re: [PATCH 1/9 v1.01] Add Synopsys DesignWare HS USB OTG Controller driver.
From: Chuck Meade @ 2010-07-13 22:16 UTC (permalink / raw)
To: Fushen Chen; +Cc: linuxppc-dev, chuck, linux-usb, Mark Miesfeld, gregkh
In-Reply-To: <12789766042434-git-send-email-fchen@apm.com>
On 07/12/2010 07:16 PM, Fushen Chen wrote:
> The DWC OTG driver module provides the initialization and cleanup
> entry points for the DWC OTG USB driver.
>
> Signed-off-by: Fushen Chen <fchen@apm.com>
> Signed-off-by: Mark Miesfeld <mmiesfeld@apm.com>
> ---
This reply is to the patch series, not just this 1/9 patch section.
Fushen, why did you pick and choose which fixes to incorporate from the Denx
tree's version of the dwc_otg driver?
I'm not taking the time here to go through this multipart patch and check that
you incorporated every fix, but I *did* randomly pick one fix that I made to that
driver, to see if you incorporated it, and it appears you did not.
I would have expected that you would have incorporated the fixes that were made
to this driver in the Denx tree.
The one that I checked is in the data toggle error interrupt handling, in
handle_hc_chhltd_intr_dma() (see your 5/9 email in this patch series). It looks
like you left out the fix I made to this logic that averts an interrupt storm.
I assume that since I checked one particular fix, and it was missing from your
patch series, that there are likely more fixes you omitted. Can you explain why
you would leave this out, after Stefan asked you to incorporate the code changes
made in the Denx tree's version of the driver?
Chuck
^ permalink raw reply
* Re: [PATCH 1/9 v1.01] Add Synopsys DesignWare HS USB OTG Controller driver.
From: fushen chen @ 2010-07-13 22:13 UTC (permalink / raw)
To: David Brownell; +Cc: linuxppc-dev, chuck, linux-usb, Mark Miesfeld, gregkh
In-Reply-To: <582531.52335.qm@web180310.mail.gq1.yahoo.com>
On Mon, 2010-07-12 at 16:55 -0700, David Brownell wrote:
> Please remove all the changes not related to
> this Synopsis IP ...
Could you clarify what is not Synopsis IP related in the patch?
> and make the OTG functionality
> key on the generic OTG symbol, not a DW-specific one.
>
>
Use "drivers/usb/otg/otg.c and include/linux/usb/otg.h"?
Thanks,
Fushen
^ permalink raw reply
* Re: [PATCH] kbuild: Enable building defconfigs from Kconfig files
From: Michal Marek @ 2010-07-13 20:22 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: ppc-dev, Andrew Morton, Linus, LKML, Catalin Marinas
In-Reply-To: <20100713114322.57c8b166.sfr@canb.auug.org.au>
On 07/13/2010 03:43 AM, Stephen Rothwell wrote:
> After this change, doing a "make xxx_defconfig" will check first for
> a file called arch/<arch>/configs/Kconfig.xxx and use that to generate
> the .config (effectively starting from an allnoconfig). If that file
> doesn't exist, it will use arch/<ARCH>/configs/xxx_defconfig as now.
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> scripts/kconfig/Makefile | 14 +++++++++++++-
> 1 files changed, 13 insertions(+), 1 deletions(-)
>
> Hi Linus,
>
> Is this more the direction you want to take?
>
> There are still 2 main problems with is approach:
>
> - there are some config options that are globally and
> unconditionally enabled that some platforms may not want. The only way
> currently to turn them off is to reproduce the config entry with the
> different default. I am not sure if we need a wa to turn them off or to
> just change them to being neede to be selected by those that do want them.
> - we have no way to select options that are neither bool or
> tristate to suitable values. Again the only way to do that currently is
> to reproduce the config entry with a different default value.
Hi Stephen,
how are these Kconfig.xxx files going look like? A list of 'select FOO'
and 'include "Kconfig.other"' statements?
What about adding support for an include statement to the .config file
format and using that in the defconfigs instead? The VARIABLE=VALUE
grammar seems much more suitable for this than the kconfig language.
Michal
^ permalink raw reply
* [PATCH V3] powerpc:prom Export device tree physical address via proc
From: Matthew McClintock @ 2010-07-13 19:21 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Matthew McClintock, Kumar Gala
To build a proper flat device tree for kexec we need to know which
memreserve region was used for the device tree for the currently
running kernel, so we can remove it and replace it with the new
memreserve for the kexec'ed kernel
Signed-off-by: Matthew McClintock <msm@freescale.com>
---
V3: Remove unneeded cast, and fixed indentation screw up
V2: messed up changes
arch/powerpc/kernel/prom.c | 45 ++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 45 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index fd9359a..79c1f35 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -32,6 +32,7 @@
#include <linux/debugfs.h>
#include <linux/irq.h>
#include <linux/lmb.h>
+#include <linux/bootmem.h>
#include <asm/prom.h>
#include <asm/rtas.h>
@@ -911,3 +912,47 @@ static int __init export_flat_device_tree(void)
}
__initcall(export_flat_device_tree);
#endif
+
+#ifdef CONFIG_KEXEC
+static phys_addr_t flat_dt_start;
+static phys_addr_t flat_dt_end;
+
+static struct property flat_dt_start_prop = {
+ .name = "linux,devicetree-start",
+ .length = sizeof(phys_addr_t),
+ .value = &flat_dt_start,
+};
+
+static struct property flat_dt_end_prop = {
+ .name = "linux,devicetree-end",
+ .length = sizeof(phys_addr_t),
+ .value = &flat_dt_end,
+};
+
+static int __init export_flat_device_tree_phys_addr(void)
+{
+ struct property *prop;
+ struct device_node *node;
+
+ node = of_find_node_by_path("/chosen");
+ if (!node)
+ return -ENOENT;
+
+ prop = of_find_property(node, "linux,devicetree-start", NULL);
+ if (prop)
+ prom_remove_property(node, prop);
+
+ prop = of_find_property(node, "linux,devietree-end", NULL);
+ if (prop)
+ prom_remove_property(node, prop);
+
+ flat_dt_start = virt_to_phys(initial_boot_params);
+ flat_dt_end = virt_to_phys(initial_boot_params)
+ + initial_boot_params->totalsize;
+ prom_add_property(node, &flat_dt_start_prop);
+ prom_add_property(node, &flat_dt_end_prop);
+
+ return 0;
+}
+__initcall(export_flat_device_tree_phys_addr);
+#endif
--
1.6.6.1
^ permalink raw reply related
* [PATCH V2] powerpc:prom Export device tree physical address via proc
From: Matthew McClintock @ 2010-07-13 19:14 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Matthew McClintock, Kumar Gala
To build a proper flat device tree for kexec we need to know which
memreserve region was used for the device tree for the currently
running kernel, so we can remove it and replace it with the new
memreserve for the kexec'ed kernel
Signed-off-by: Matthew McClintock <msm@freescale.com>
---
Removed unneeded cast, and fixed indentation screwup
arch/powerpc/kernel/prom.c | 44 ++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 44 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index fd9359a..6a8400e 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -32,6 +32,7 @@
#include <linux/debugfs.h>
#include <linux/irq.h>
#include <linux/lmb.h>
+#include <linux/bootmem.h>
#include <asm/prom.h>
#include <asm/rtas.h>
@@ -911,3 +912,46 @@ static int __init export_flat_device_tree(void)
}
__initcall(export_flat_device_tree);
#endif
+
+#ifdef CONFIG_KEXEC
+static phys_addr_t flat_dt_start;
+static phys_addr_t flat_dt_end;
+
+static struct property flat_dt_start_prop = {
+ .name = "linux,devicetree-start",
+ .length = sizeof(phys_addr_t),
+ .value = &flat_dt_start,
+};
+
+static struct property flat_dt_end_prop = {
+ .name = "linux,devicetree-end",
+ .length = sizeof(phys_addr_t),
+ .value = &flat_dt_end,
+};
+
+static int __init export_flat_device_tree_phys_addr(void)
+{
+ struct property *prop;
+ struct device_node *node;
+
+ node = of_find_node_by_path("/chosen");
+ if (!node)
+ return -ENOENT;
+
+ prop = of_find_property(node, "linux,devicetree-start", NULL);
+ if (prop)
+ prom_remove_property(node, prop);
+ prop = of_find_property(node, "linux,devietree-end", NULL);
+ if (prop)
+ prom_remove_property(node, prop);
+
+ flat_dt_start = (unsigned long)virt_to_phys(initial_boot_params);
+ flat_dt_end = (unsigned long)virt_to_phys(initial_boot_params)
+ + initial_boot_params->totalsize;
+ prom_add_property(node, &flat_dt_start_prop);
+ prom_add_property(node, &flat_dt_end_prop);
+
+ return 0;
+}
+__initcall(export_flat_device_tree_phys_addr);
+#endif
--
1.6.6.1
^ permalink raw reply related
* Re: [PATCH] powerpc:prom Export device tree physical address via proc
From: Timur Tabi @ 2010-07-13 18:55 UTC (permalink / raw)
To: Matthew McClintock; +Cc: linuxppc-dev
In-Reply-To: <1279047011-28989-1-git-send-email-msm@freescale.com>
Matthew McClintock wrote:
> + if (prop)
> + prom_remove_property(node, prop);
> + prop = of_find_property(node, "linux,devietree-end", NULL);
Either the indentation is wrong, or you're missing some braces here.
> + if (prop)
> + prom_remove_property(node, prop);
> +
> + flat_dt_start = (unsigned long)virt_to_phys(initial_boot_params);
> + flat_dt_end = (unsigned long)virt_to_phys(initial_boot_params)
> + + initial_boot_params->totalsize;
I think these should be u64, not unsigned long, to ensure support for 64-bit
physical addresses.
^ permalink raw reply
* [PATCH] powerpc:prom Export device tree physical address via proc
From: Matthew McClintock @ 2010-07-13 18:50 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Matthew McClintock, Kumar Gala
To build a proper flat device tree for kexec we need to know which
memreserve region was used for the device tree for the currently
running kernel, so we can remove it and replace it with the new
memreserve for the kexec'ed kernel
Signed-off-by: Matthew McClintock <msm@freescale.com>
---
arch/powerpc/kernel/prom.c | 44 ++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 44 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index fd9359a..6a8400e 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -32,6 +32,7 @@
#include <linux/debugfs.h>
#include <linux/irq.h>
#include <linux/lmb.h>
+#include <linux/bootmem.h>
#include <asm/prom.h>
#include <asm/rtas.h>
@@ -911,3 +912,46 @@ static int __init export_flat_device_tree(void)
}
__initcall(export_flat_device_tree);
#endif
+
+#ifdef CONFIG_KEXEC
+static phys_addr_t flat_dt_start;
+static phys_addr_t flat_dt_end;
+
+static struct property flat_dt_start_prop = {
+ .name = "linux,devicetree-start",
+ .length = sizeof(phys_addr_t),
+ .value = &flat_dt_start,
+};
+
+static struct property flat_dt_end_prop = {
+ .name = "linux,devicetree-end",
+ .length = sizeof(phys_addr_t),
+ .value = &flat_dt_end,
+};
+
+static int __init export_flat_device_tree_phys_addr(void)
+{
+ struct property *prop;
+ struct device_node *node;
+
+ node = of_find_node_by_path("/chosen");
+ if (!node)
+ return -ENOENT;
+
+ prop = of_find_property(node, "linux,devicetree-start", NULL);
+ if (prop)
+ prom_remove_property(node, prop);
+ prop = of_find_property(node, "linux,devietree-end", NULL);
+ if (prop)
+ prom_remove_property(node, prop);
+
+ flat_dt_start = (unsigned long)virt_to_phys(initial_boot_params);
+ flat_dt_end = (unsigned long)virt_to_phys(initial_boot_params)
+ + initial_boot_params->totalsize;
+ prom_add_property(node, &flat_dt_start_prop);
+ prom_add_property(node, &flat_dt_end_prop);
+
+ return 0;
+}
+__initcall(export_flat_device_tree_phys_addr);
+#endif
--
1.6.6.1
^ permalink raw reply related
* Re: optimized script [Was: ARM defconfig files]
From: Olof Johansson @ 2010-07-13 18:04 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Stephen Rothwell, Daniel Walker, Russell King - ARM Linux,
Nicolas Pitre, Kevin Hilman, linux-arm-msm, linuxppc-dev,
Linux Kernel Mailing List, Eric Miao, linux-omap, Linus Torvalds,
linux-arm-kernel
In-Reply-To: <20100713080705.GA20978@pengutronix.de>
On Tue, Jul 13, 2010 at 10:07:05AM +0200, Uwe Kleine-König wrote:
> Hello,
>
> On Tue, Jul 13, 2010 at 09:07:41AM +0200, Uwe Kleine-König wrote:
> > Hi
> >
> > On Mon, Jul 12, 2010 at 01:50:47PM -0600, Grant Likely wrote:
> > > On Mon, Jul 12, 2010 at 1:34 PM, Linus Torvalds
> > > <torvalds@linux-foundation.org> wrote:
> > > > On Mon, Jul 12, 2010 at 12:17 PM, Nicolas Pitre <nico@fluxnic.net> wrote:
> > > >> I think Uwe could provide his script and add it to the kernel tree.
> > > >> Then all architectures could benefit from it. Having the defconfig
> > > >> files contain only those options which are different from the defaults
> > > >> is certainly more readable, even on x86.
> > > >
> > > > Quite possible. But maintainers would need to be on the lookout of
> > > > people actually using the script, and refusing to apply patches that
> > > > re-introduce the whole big thing.
> > >
> > > I can (partially) speak for powerpc. If ARM uses this approach, then
> > > I think we can do the same. After the defconfigs are trimmed, I
> > > certainly won't pick up any more full defconfigs.
> > I just restarted my script on the powerpc defconfigs basing on rc5, I
> > assume they complete in a few days time.
> So Stephen was faster than me. I don't know yet how he optimised my
> script, meanwhile I put some efforts into it, too by just checking lines
> that match "^(# )?CONFIG_".
>
> Find it attached.
>
> I will start to reduce the remaining configs (i.e. all but arm and
> powerpc).
I added just a simple heuristic: If I could remove a line, I attempted
to remove twice the amount next time around (and fall back to 1 if it failed).
I.e. main loop:
i = 0
lines = 1
while i < len(config):
print 'test for %r + %d' % (config[i], lines)
defconfig = open(defconfig_src, 'w')
defconfig.writelines(config[:i])
defconfig.writelines(config[i + lines:])
defconfig.close()
subprocess.check_call(['make', '-s', 'ARCH=%s' % arch, target])
if os.stat('.config').st_size == config_size and list(open('.config')) == origconfig:
del config[i:i+lines]
lines *= 2
else:
if lines > 1:
lines = 1
else:
i += 1
I didn't measure what the actual improvement was, but I saw a fair amount
of 2/4/8-attempts passing, so I let it run. Stephen beat me to posting
the resulting patch though. :P
While this script is great, it is somewhat painful to run given that it
attempts one config per line. Even on a fast machine that tends to take
a while.
-Olof
^ permalink raw reply
* Re: 2.6.35-rc4 ppc crash when loading radeon modeset=1
From: Michel Dänzer @ 2010-07-13 17:22 UTC (permalink / raw)
To: jjDaNiMoTh; +Cc: linuxppc-dev, xorg-driver-ati
In-Reply-To: <AANLkTikR0HRoBawbUJyS_cEkhEu9Sj6q8hR2F0v6CLDK@mail.gmail.com>
On Die, 2010-07-13 at 19:05 +0200, jjDaNiMoTh wrote:=20
>=20
> So, I've now the acceleration. The main problem was radeon.agpmode,
> setting it to -1 (and removing all files in xorg.conf.d related to
> radeon) fixes all issue (also the freeze on glxgears). Now I have
> ~1500 FPS, and I'm fine with it (before I got 100 FPS).
>=20
> I get the acceleration also with a non-KMS capable kernel, so I think
> we got the point. I will add the option to modprobe.conf for archPPC.
Note that e.g. on my PowerBook agpmode=3D1 works (mostly) stable, and if
AGP works it performs significantly better than PCI.
> I tried a program which use a lot opengl, the only thing I see is
> ERROR: GL error 1282
> ERROR: Ignoring 1 openGL errors
Something the app does causes Mesa to raise a GL_INVALID_OPERATION
error. This may be a bug in the app or in Mesa.
--=20
Earthling Michel D=C3=A4nzer | http://www.vmware.c=
om
Libre software enthusiast | Debian, X and DRI developer
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox