Re: [RESEND][PATCH 1/2] lib/scatterlist: Make ARCH_HAS_SG_CHAIN an actual Kconfig

On Sat, 2014-03-22 at 11:13 -0700, Laura Abbott wrote: > Rather than have architectures #define ARCH_HAS_SG_CHAIN in an architecture > specific scatterlist.h, make it a proper Kconfig option and use that > instead. At same time, remove the header files are are now mostly > useless and just include

Re: [RESEND][PATCH 1/2] lib/scatterlist: Make ARCH_HAS_SG_CHAIN an actual Kconfig

> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index 1594945..8122294 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -82,6 +82,7 @@ config ARM > . > > config ARM_HAS_SG_CHAIN > + select ARCH_HAS_SG_CHAIN > bool > Heh, a sel

Re: [RESEND][PATCH 1/2] lib/scatterlist: Make ARCH_HAS_SG_CHAIN an actual Kconfig

On Sat, 2014-03-22 at 22:52 +, Russell King - ARM Linux wrote: > On Sat, Mar 22, 2014 at 03:37:40PM -0700, James Bottomley wrote: > > On Sat, 2014-03-22 at 22:23 +, Russell King - ARM Linux wrote: > > > On Sat, Mar 22, 2014 at 02:31:21PM -0700, James Bottomley wrote: > > > > Perhaps now mig

Re: [RESEND][PATCH 1/2] lib/scatterlist: Make ARCH_HAS_SG_CHAIN an actual Kconfig

On Sat, Mar 22, 2014 at 03:37:40PM -0700, James Bottomley wrote: > On Sat, 2014-03-22 at 22:23 +, Russell King - ARM Linux wrote: > > On Sat, Mar 22, 2014 at 02:31:21PM -0700, James Bottomley wrote: > > > Perhaps now might be the time to ask which are the remaining > > > architectures that cann

Re: [RESEND][PATCH 1/2] lib/scatterlist: Make ARCH_HAS_SG_CHAIN an actual Kconfig

On Sat, 2014-03-22 at 22:23 +, Russell King - ARM Linux wrote: > On Sat, Mar 22, 2014 at 02:31:21PM -0700, James Bottomley wrote: > > Perhaps now might be the time to ask which are the remaining > > architectures that cannot do SG chaining and then we can fix them and > > pull the whole thing o

Re: [RESEND][PATCH 1/2] lib/scatterlist: Make ARCH_HAS_SG_CHAIN an actual Kconfig

On Sat, Mar 22, 2014 at 02:31:21PM -0700, James Bottomley wrote: > Perhaps now might be the time to ask which are the remaining > architectures that cannot do SG chaining and then we can fix them and > pull the whole thing out. Not quite. You're making the assumption that we can be sure that all

Re: [RESEND][PATCH 1/2] lib/scatterlist: Make ARCH_HAS_SG_CHAIN an actual Kconfig

On Sat, 22 Mar 2014, James Bottomley wrote: > On Sat, 2014-03-22 at 11:13 -0700, Laura Abbott wrote: > > Rather than have architectures #define ARCH_HAS_SG_CHAIN in an architecture > > specific scatterlist.h, make it a proper Kconfig option and use that > > instead. At same time, remove the header

Re: [RESEND][PATCH 1/2] lib/scatterlist: Make ARCH_HAS_SG_CHAIN an actual Kconfig

On Sat, 2014-03-22 at 11:13 -0700, Laura Abbott wrote: > Rather than have architectures #define ARCH_HAS_SG_CHAIN in an architecture > specific scatterlist.h, make it a proper Kconfig option and use that > instead. At same time, remove the header files are are now mostly > useless and just include

Re: [RESEND][PATCH 1/2] lib/scatterlist: Make ARCH_HAS_SG_CHAIN an actual Kconfig

On Sat, 22 Mar 2014, Laura Abbott wrote: > Rather than have architectures #define ARCH_HAS_SG_CHAIN in an architecture > specific scatterlist.h, make it a proper Kconfig option and use that > instead. At same time, remove the header files are are now mostly > useless and just include asm-generic/s

[RESEND][PATCH 1/2] lib/scatterlist: Make ARCH_HAS_SG_CHAIN an actual Kconfig

Rather than have architectures #define ARCH_HAS_SG_CHAIN in an architecture specific scatterlist.h, make it a proper Kconfig option and use that instead. At same time, remove the header files are are now mostly useless and just include asm-generic/scatterlist.h. Cc: Russell King Cc: Tony Luck Cc

[RESEND][PATCH 0/2] Cleanup asm/scatterlist.h

I haven't gotten many responses so I'm going to try sending again (this time with a cover letter which I probably should have done in the first place...) ARCH_HAS_SG_CHAIN is currently defined as needed in asm/scatterlist.h. It was suggested[1] that this should probably be a proper Kconfig. At t

[v3] mtd: m25p80: Modify the name of mtd_info

To specify spi flash layouts by "mtdparts=..." in cmdline, we must give mtd_info a fixed name,because the cmdlinepart's parser will match the name of mtd_info given in cmdline. Now, if use DT, the mtd_info's name will be spi->dev->name. It consists of spi_master->bus_num, and the spi_master->bus_nu

[v2] mtd: m25p80: Modify the name of mtd_info

To specify spi flash layouts by "mtdparts=..." in cmdline, we must give mtd_info a fixed name,because the cmdlinepart's parser will match the name of mtd_info given in cmdline. Now, if use DT, the mtd_info's name will be spi->dev->name. It consists of spi_master->bus_num, and the spi_master->bus_nu

Re: [PATCH v3 5/5] powernv:cpufreq: Implement the driver->get() method

Hi Ben, On Sat, Mar 22, 2014 at 09:56:30AM +1100, Benjamin Herrenschmidt wrote: > On Fri, 2014-03-21 at 16:34 +0530, Gautham R Shenoy wrote: > > > > > > > > > +/* > > > > + * Computes the current frequency on this cpu > > > > + * and stores the result in *ret_freq. > > > > + */ > > > > +static vo

[PATCH] arch/powerpc: Use RCU_INIT_POINTER(x, NULL) in platforms/cell/spu_syscalls.c

Here rcu_assign_pointer() is ensuring that the initialization of a structure is carried out before storing a pointer to that structure. So, rcu_assign_pointer(p, NULL) can always safely be converted to RCU_INIT_POINTER(p, NULL). Signed-off-by: Monam Agarwal --- arch/powerpc/platforms/cell/spu_sy