Re: [RFC PATCH v1 25/31] ARC: [plat-arcfpga] Hooking up platform to ARC UART

[Vineet Gupta]

On Wednesday 07 November 2012 07:46 PM, Arnd Bergmann wrote:
> On Wednesday 07 November 2012, Vineet Gupta wrote:
>> +static struct platform_device arc_uart##n##_dev = {\
>> +   .name = "arc-uart", \
>> +   .id = n,\
>> +   .num_resources = ARRAY_SIZE(arc_uart##n##_res), \
>> +   .resource = arc_uart##n##_res,  \
>> +   .dev = {\
>> +   .platform_data = _uart_info,\
>> +   },  \
>> +}
>> +
>> +ARC_UART_DEV(0);
>> +#if CONFIG_SERIAL_ARC_NR_PORTS > 1
>> +ARC_UART_DEV(1);
>> +#endif
>> +
>> +static struct platform_device *fpga_early_devs[] __initdata = {
>> +#if defined(CONFIG_SERIAL_ARC_CONSOLE)
>> +   _uart0_dev,
>> +#endif
>> +};
> 
> statically defining platform devices like this is considered very
> bad style, especially since it prevents you from doing proper
> boot-time configuration. Please get the available devices from
> the boot loader. Normally this is done using a flattened device
> tree blob that gets passed, unless you can probe the hardware
> directly.
> 
>   Arnd
> 

So my strategy for v2 series (based off 3.8-rcx) is to introduce devicetree,
multi-platform-image support (and other key fixes such as syscall restart 
issues)
as slap-on patches on top of old code. This is not to avoid any chop-n-dice of
fixing patches (I've done that in plenty between v1 and v2). Its just that, in
absence of revision history for ARC port (in upstream later on) - it helps 
capture
the evolution of some key features and also for the community it serves as a 
live
documentation of bad designs and how they can be fixed.

Is that a reasonable approach for new port which is non-bisectable anyways ?

Thx,
-Vineet
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Staging: comedi: ni_tio: Fixed whitespace / spacing issue

[Dan Carpenter]

On Wed, Jan 16, 2013 at 08:05:28PM -0500, Jake Champlin wrote:
> Fixed a leading whitespace coding style issue.
> 
> Signed-off-by: Jake Champlin 
> ---
>  drivers/staging/comedi/drivers/ni_tio.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/comedi/drivers/ni_tio.c 
> b/drivers/staging/comedi/drivers/ni_tio.c
> index 98f8789..73e7cbe 100644
> --- a/drivers/staging/comedi/drivers/ni_tio.c
> +++ b/drivers/staging/comedi/drivers/ni_tio.c
> @@ -276,7 +276,7 @@ static inline unsigned 
> NI_660x_RTSI_Second_Gate_Select(unsigned n)
>  }
>  
>  static const unsigned int counter_status_mask =
> -COMEDI_COUNTER_ARMED | COMEDI_COUNTER_COUNTING;
> +COMEDI_COUNTER_ARMED | COMEDI_COUNTER_COUNTING;

No.  It should be intended but just using tabs instead of spaces.

regards,
dan carpenter

>  
>  static int __init ni_tio_init_module(void)
>  {
> -- 
> 1.8.1.1
> 
> 
> -- 
> Jake Champlin
> jake.champlin...@gmail.com
> 8123742937
> 
> ___
> devel mailing list
> de...@linuxdriverproject.org
> http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] regulator: lp8755: Don't show unrelated messags in lp8755_probe error paths

[Mark Brown]

On Sat, Jan 12, 2013 at 02:58:35PM +0800, Axel Lin wrote:
> Signed-off-by: Axel Lin 

Applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] regulator: lp8755: Remove enum bucks

[Mark Brown]

On Mon, Jan 07, 2013 at 10:28:31AM +0800, Axel Lin wrote:
> We already have enum lp8755_bucks in lp8755.h, so it looks pointless adding
> enum bucks in lp8755.c.

Applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] regulator: s5m8767: Remove max_vol parameter from s5m8767_convert_voltage_to_sel

[Mark Brown]

On Sat, Dec 29, 2012 at 09:38:50AM +0800, Axel Lin wrote:
> It looks pointless to pass max_vol to s5m8767_convert_voltage_to_sel().
> Compare selected voltage to desc->max is enough to ensure selected voltage
> is in supported range.

Applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] regulator: lp8788-buck: Remove buck[1|2]_vout_addr array

[Mark Brown]

On Thu, Jan 17, 2013 at 09:57:46AM +0800, Axel Lin wrote:
> The vout address for buck[1|2] can be easily calculated,
> thus remote these arrays.

Applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Redefinition of struct in6_addr in and

[Cong Wang]

- Original Message -
> 
> I see no reason, even although I don't know why it is 46 instead of
> 40.

Ok, for "::::::255.255.255.255".
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v7 3/3] PM: Introduce Intel PowerClamp Driver

[Zhang Rui]

On Wed, 2013-01-16 at 05:11 -0800, Jacob Pan wrote:
> Intel PowerClamp driver performs synchronized idle injection across
> all online CPUs. The goal is to maintain a given package level C-state
> ratio.
> 
> Compared to other throttling methods already exist in the kernel,
> such as ACPI PAD (taking CPUs offline) and clock modulation, this is often
> more efficient in terms of performance per watt.
> 
> Please refer to Documentation/thermal/intel_powerclamp.txt for more details.
> 
> Signed-off-by: Arjan van de Ven 
> Signed-off-by: Jacob Pan 
Reviewed-by: Zhang Rui 

Rafael,
can you take this please? I'm not going to push anything except bug
fixes until next merge window.

thanks,
rui
> ---
>  Documentation/thermal/intel_powerclamp.txt |  307 +++
>  drivers/thermal/Kconfig|   10 +
>  drivers/thermal/Makefile   |2 +
>  drivers/thermal/intel_powerclamp.c |  788 
> 
>  4 files changed, 1107 insertions(+)
>  create mode 100644 Documentation/thermal/intel_powerclamp.txt
>  create mode 100644 drivers/thermal/intel_powerclamp.c
> 
> diff --git a/Documentation/thermal/intel_powerclamp.txt 
> b/Documentation/thermal/intel_powerclamp.txt
> new file mode 100644
> index 000..332de4a
> --- /dev/null
> +++ b/Documentation/thermal/intel_powerclamp.txt
> @@ -0,0 +1,307 @@
> +  ===
> +  INTEL POWERCLAMP DRIVER
> +  ===
> +By: Arjan van de Ven 
> +Jacob Pan 
> +
> +Contents:
> + (*) Introduction
> + - Goals and Objectives
> +
> + (*) Theory of Operation
> + - Idle Injection
> + - Calibration
> +
> + (*) Performance Analysis
> + - Effectiveness and Limitations
> + - Power vs Performance
> + - Scalability
> + - Calibration
> + - Comparison with Alternative Techniques
> +
> + (*) Usage and Interfaces
> + - Generic Thermal Layer (sysfs)
> + - Kernel APIs (TBD)
> +
> +
> +INTRODUCTION
> +
> +
> +Consider the situation where a system’s power consumption must be
> +reduced at runtime, due to power budget, thermal constraint, or noise
> +level, and where active cooling is not preferred. Software managed
> +passive power reduction must be performed to prevent the hardware
> +actions that are designed for catastrophic scenarios.
> +
> +Currently, P-states, T-states (clock modulation), and CPU offlining
> +are used for CPU throttling.
> +
> +On Intel CPUs, C-states provide effective power reduction, but so far
> +they’re only used opportunistically, based on workload. With the
> +development of intel_powerclamp driver, the method of synchronizing
> +idle injection across all online CPU threads was introduced. The goal
> +is to achieve forced and controllable C-state residency.
> +
> +Test/Analysis has been made in the areas of power, performance,
> +scalability, and user experience. In many cases, clear advantage is
> +shown over taking the CPU offline or modulating the CPU clock.
> +
> +
> +===
> +THEORY OF OPERATION
> +===
> +
> +Idle Injection
> +--
> +
> +On modern Intel processors (Nehalem or later), package level C-state
> +residency is available in MSRs, thus also available to the kernel.
> +
> +These MSRs are:
> +  #define MSR_PKG_C2_RESIDENCY   0x60D
> +  #define MSR_PKG_C3_RESIDENCY   0x3F8
> +  #define MSR_PKG_C6_RESIDENCY   0x3F9
> +  #define MSR_PKG_C7_RESIDENCY   0x3FA
> +
> +If the kernel can also inject idle time to the system, then a
> +closed-loop control system can be established that manages package
> +level C-state. The intel_powerclamp driver is conceived as such a
> +control system, where the target set point is a user-selected idle
> +ratio (based on power reduction), and the error is the difference
> +between the actual package level C-state residency ratio and the target idle
> +ratio.
> +
> +Injection is controlled by high priority kernel threads, spawned for
> +each online CPU.
> +
> +These kernel threads, with SCHED_FIFO class, are created to perform
> +clamping actions of controlled duty ratio and duration. Each per-CPU
> +thread synchronizes its idle time and duration, based on the rounding
> +of jiffies, so accumulated errors can be prevented to avoid a jittery
> +effect. Threads are also bound to the CPU such that they cannot be
> +migrated, unless the CPU is taken offline. In this case, threads
> +belong to the offlined CPUs will be terminated immediately.
> +
> +Running as SCHED_FIFO and relatively high priority, also allows such
> +scheme to work for both preemptable and non-preemptable kernels.
> +Alignment of idle time around jiffies ensures scalability for HZ
> +values. This effect can be better visualized using a Perf timechart.
> +The following diagram shows the behavior of kernel thread
> +kidle_inject/cpu. During idle 

Re: Redefinition of struct in6_addr in and

[Cong Wang]

On Thu, 2013-01-17 at 11:55 +0800, Jike Song wrote:
> On Thu, Jan 17, 2013 at 2:59 AM, David Miller  wrote:
> 
> >
> > When GLIBC doesn't provide it's own definition of some networking
> > macros or interfaces that the kernel provides, people include the
> > kernel header.
> >
> 
> Recently I got a problem when copying a structure from kernel to userspace,
> after debugging I found:
> 
> kernel:   include/linux/inet.h
> 
> #define INET6_ADDRSTRLEN(48)
> 
> glibc:  /usr/include/netinet/in.h
> 
> #define INET6_ADDRSTRLEN 46
> 
> 
> Any reason to differentiate them from each other?
> 

I see no reason, even although I don't know why it is 46 instead of 40.

But include/linux/inet.h is not exported to user-space, AFAIK.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mmc: core: disable the cache before suspend only after stopping BKOPS

[Subhash Jadavani]

As Maya is going to fix the commit text,
Acked-by: Subhash Jadavani 

On 1/17/2013 12:18 PM, Seungwon Jeon wrote:

On Thursday, January 17, 2013 , Ulf Hansson wrote:

On 13 January 2013 22:47, Maya Erez  wrote:

-Original Message-
From: Subhash Jadavani [mailto:subha...@codeaurora.org]
Sent: Saturday, January 12, 2013 9:07 AM
To: Maya Erez
Cc: linux-...@vger.kernel.org; linux-arm-...@vger.kernel.org; open list
Subject: Re: [PATCH] mmc: core: disable the cache before suspend only after
stopping BKOPS

On 1/12/2013 2:12 AM, Maya Erez wrote:

mmc_cache_ctrl was called in runtime suspend before MMC interrupted
BKOPS in case it is still running on the card. This caused the cache
disable to timeout.

I guess even if the idle time bkops polling is not implemented, this patch
is good to have. cache control is the eMMC feature and in that sense, it
should have been part of MMC's bus resume (mmc_resume) rather than generic
mmc_suspend_host().

Patch as such is fine and if you agree, you may want to remove the
mentioning of bkops as part of commit text and may just want to mention
above reason as the main motivation for this patch.

Agreed, I will change the commit text in the next uploaded version.


Therefore, mmc_cache_ctrl has to move to mmc_suspend where we are sure
that the card can go into suspend and there is no pending activity.

Signed-off-by: Maya Erez 
---
   drivers/mmc/core/core.c |7 +--
   drivers/mmc/core/mmc.c  |8 +++-
   2 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c index
aaed768..b438bb2 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -2388,6 +2388,7 @@ EXPORT_SYMBOL(mmc_flush_cache);
* Turn the cache ON/OFF.
* Turning the cache OFF shall trigger flushing of the data
* to the non-volatile storage.
+ * This function should be called with host claimed
*/
   int mmc_cache_ctrl(struct mmc_host *host, u8 enable)
   {
@@ -2399,7 +2400,6 @@ int mmc_cache_ctrl(struct mmc_host *host, u8 enable)
   mmc_card_is_removable(host))
   return err;

- mmc_claim_host(host);
   if (card && mmc_card_mmc(card) &&
   (card->ext_csd.cache_size > 0)) {
   enable = !!enable;
@@ -2417,7 +2417,6 @@ int mmc_cache_ctrl(struct mmc_host *host, u8 enable)
   card->ext_csd.cache_ctrl = enable;
   }
   }
- mmc_release_host(host);

   return err;
   }
@@ -2436,10 +2435,6 @@ int mmc_suspend_host(struct mmc_host *host)
   cancel_delayed_work(>detect);
   mmc_flush_scheduled_work();

- err = mmc_cache_ctrl(host, 0);
- if (err)
- goto out;
-
   mmc_bus_get(host);
   if (host->bus_ops && !host->bus_dead) {
   if (host->bus_ops->suspend) {
diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c index
e6e3911..dc17d40 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -1379,6 +1379,11 @@ static int mmc_suspend(struct mmc_host *host)
   BUG_ON(!host->card);

   mmc_claim_host(host);
+
+ err = mmc_cache_ctrl(host, 0);
+ if (err)
+ goto out;
+
   if (mmc_can_poweroff_notify(host->card))
   err = mmc_poweroff_notify(host->card,

EXT_CSD_POWER_OFF_SHORT);

   else if (mmc_card_can_sleep(host))
@@ -1386,8 +1391,9 @@ static int mmc_suspend(struct mmc_host *host)
   else if (!mmc_host_is_spi(host))
   err = mmc_deselect_cards(host);
   host->card->state &= ~(MMC_STATE_HIGHSPEED |

MMC_STATE_HIGHSPEED_200);

- mmc_release_host(host);

+out:
+ mmc_release_host(host);
   return err;
   }


--
QUALCOMM ISRAEL, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

I agree that some update to the commit msg is wanted; since this fixup
is not related to runtime suspend as such.
Anyway, you have my ack!

Acked-by: Ulf Hansson 

Yes, it's reasonable.
Cache feature is closely connected with eMMC.

Acked-by: Seungwon Jeon 

Thanks,
Seungwon Jeon

Kind regards
Ulf Hansson
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH] mmc: core: disable the cache before suspend only after stopping BKOPS

[Seungwon Jeon]

On Thursday, January 17, 2013 , Ulf Hansson wrote:
> On 13 January 2013 22:47, Maya Erez  wrote:
> > -Original Message-
> > From: Subhash Jadavani [mailto:subha...@codeaurora.org]
> > Sent: Saturday, January 12, 2013 9:07 AM
> > To: Maya Erez
> > Cc: linux-...@vger.kernel.org; linux-arm-...@vger.kernel.org; open list
> > Subject: Re: [PATCH] mmc: core: disable the cache before suspend only after
> > stopping BKOPS
> >
> > On 1/12/2013 2:12 AM, Maya Erez wrote:
> >> mmc_cache_ctrl was called in runtime suspend before MMC interrupted
> >> BKOPS in case it is still running on the card. This caused the cache
> >> disable to timeout.
> > I guess even if the idle time bkops polling is not implemented, this patch
> > is good to have. cache control is the eMMC feature and in that sense, it
> > should have been part of MMC's bus resume (mmc_resume) rather than generic
> > mmc_suspend_host().
> >
> > Patch as such is fine and if you agree, you may want to remove the
> > mentioning of bkops as part of commit text and may just want to mention
> > above reason as the main motivation for this patch.
> >
> > Agreed, I will change the commit text in the next uploaded version.
> >
> >> Therefore, mmc_cache_ctrl has to move to mmc_suspend where we are sure
> >> that the card can go into suspend and there is no pending activity.
> >>
> >> Signed-off-by: Maya Erez 
> >> ---
> >>   drivers/mmc/core/core.c |7 +--
> >>   drivers/mmc/core/mmc.c  |8 +++-
> >>   2 files changed, 8 insertions(+), 7 deletions(-)
> >>
> >> diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c index
> >> aaed768..b438bb2 100644
> >> --- a/drivers/mmc/core/core.c
> >> +++ b/drivers/mmc/core/core.c
> >> @@ -2388,6 +2388,7 @@ EXPORT_SYMBOL(mmc_flush_cache);
> >>* Turn the cache ON/OFF.
> >>* Turning the cache OFF shall trigger flushing of the data
> >>* to the non-volatile storage.
> >> + * This function should be called with host claimed
> >>*/
> >>   int mmc_cache_ctrl(struct mmc_host *host, u8 enable)
> >>   {
> >> @@ -2399,7 +2400,6 @@ int mmc_cache_ctrl(struct mmc_host *host, u8 enable)
> >>   mmc_card_is_removable(host))
> >>   return err;
> >>
> >> - mmc_claim_host(host);
> >>   if (card && mmc_card_mmc(card) &&
> >>   (card->ext_csd.cache_size > 0)) {
> >>   enable = !!enable;
> >> @@ -2417,7 +2417,6 @@ int mmc_cache_ctrl(struct mmc_host *host, u8 enable)
> >>   card->ext_csd.cache_ctrl = enable;
> >>   }
> >>   }
> >> - mmc_release_host(host);
> >>
> >>   return err;
> >>   }
> >> @@ -2436,10 +2435,6 @@ int mmc_suspend_host(struct mmc_host *host)
> >>   cancel_delayed_work(>detect);
> >>   mmc_flush_scheduled_work();
> >>
> >> - err = mmc_cache_ctrl(host, 0);
> >> - if (err)
> >> - goto out;
> >> -
> >>   mmc_bus_get(host);
> >>   if (host->bus_ops && !host->bus_dead) {
> >>   if (host->bus_ops->suspend) {
> >> diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c index
> >> e6e3911..dc17d40 100644
> >> --- a/drivers/mmc/core/mmc.c
> >> +++ b/drivers/mmc/core/mmc.c
> >> @@ -1379,6 +1379,11 @@ static int mmc_suspend(struct mmc_host *host)
> >>   BUG_ON(!host->card);
> >>
> >>   mmc_claim_host(host);
> >> +
> >> + err = mmc_cache_ctrl(host, 0);
> >> + if (err)
> >> + goto out;
> >> +
> >>   if (mmc_can_poweroff_notify(host->card))
> >>   err = mmc_poweroff_notify(host->card,
> > EXT_CSD_POWER_OFF_SHORT);
> >>   else if (mmc_card_can_sleep(host))
> >> @@ -1386,8 +1391,9 @@ static int mmc_suspend(struct mmc_host *host)
> >>   else if (!mmc_host_is_spi(host))
> >>   err = mmc_deselect_cards(host);
> >>   host->card->state &= ~(MMC_STATE_HIGHSPEED |
> > MMC_STATE_HIGHSPEED_200);
> >> - mmc_release_host(host);
> >>
> >> +out:
> >> + mmc_release_host(host);
> >>   return err;
> >>   }
> >>
> > --
> > QUALCOMM ISRAEL, on behalf of Qualcomm Innovation Center, Inc. is a member
> > of Code Aurora Forum, hosted by The Linux Foundation
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> I agree that some update to the commit msg is wanted; since this fixup
> is not related to runtime suspend as such.
> Anyway, you have my ack!
> 
> Acked-by: Ulf Hansson 

Yes, it's reasonable.
Cache feature is closely connected with eMMC.

Acked-by: Seungwon Jeon 

Thanks,
Seungwon Jeon
> 
> Kind regards
> Ulf Hansson
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a 

Re: [PATCH v7 3/4] block: implement runtime pm strategy

[Aaron Lu]

On Wed, Jan 16, 2013 at 10:30:45AM -0500, Alan Stern wrote:
> On Wed, 16 Jan 2013, Aaron Lu wrote:
> 
> > From: Lin Ming 
> > 
> > When a request is added:
> > If device is suspended or is suspending and the request is not a
> > PM request, resume the device.
> > 
> > When the last request finishes:
> > Call pm_runtime_mark_last_busy().
> > 
> > When pick a request:
> > If device is resuming/suspending, then only PM request is allowed
> > to go.
> > 
> > Signed-off-by: Lin Ming 
> > Signed-off-by: Aaron Lu 
> 
> Just a couple of minor problems remaining...
> 
> > --- a/block/blk-core.c
> > +++ b/block/blk-core.c
> 
> > @@ -2051,6 +2063,28 @@ static void blk_account_io_done(struct request *req)
> > }
> >  }
> >  
> > +#ifdef CONFIG_PM_RUNTIME
> > +/*
> > + * Don't process normal requests when queue is suspended
> > + * or in the process of suspending/resuming
> > + */
> > +static struct request *blk_pm_peek_request(struct request_queue *q,
> > +  struct request *rq)
> > +{
> > +   if (q->rpm_status == RPM_SUSPENDED ||
> > +   (q->rpm_status != RPM_ACTIVE && !(rq->cmd_flags & REQ_PM)))
> > +   return NULL;
> > +   else
> > +   return rq;
> > +}
> 
> You don't check q->dev here, so the result is indefinite for devices
> that don't use runtime PM.  (Actually it will work out because
> RPM_ACTIVE is defined as 0, but that's a pretty fragile approach.)
> 
> Either do check q->dev here, or else explicitly initialize
> q->rpm_status when the queue is created.
> 
> 
> > --- a/block/elevator.c
> > +++ b/block/elevator.c
> > @@ -34,6 +34,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  
> >  #include 
> >  
> > @@ -515,6 +516,27 @@ void elv_bio_merged(struct request_queue *q, struct 
> > request *rq,
> > e->type->ops.elevator_bio_merged_fn(q, rq, bio);
> >  }
> >  
> > +#ifdef CONFIG_PM_RUNTIME
> > +static void blk_pm_requeue_request(struct request *rq)
> > +{
> > +   if (!(rq->cmd_flags & REQ_PM))
> > +   rq->q->nr_pending--;
> > +}
> 
> You don't check q->dev here.  That's okay, but it means that
> q->nr_pending will be meaningless or wrong if any I/O takes place
> before blk_pm_runtime_init is called.
> 
> Therefore the kerneldoc for blk_pm_runtime_init should mention that it
> must not be called after any requests have been submitted.  Also


> mention that blk_pm_runtime_init enables runtime PM for q->dev, so the 
> caller shouldn't do it.

I may misunderstandd this in last email.

We didn't enable runtime PM for the device in blk_pm_runtime_init, just
some auto suspend related settings.

Thanks,
Aaron

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V2] mips: function tracer: Fix broken function tracing

[Geert Uytterhoeven]

On Thu, Jan 17, 2013 at 12:43 AM, Al Cooper  wrote:
> Part of the sequence is "addiu sp,sp,-8" in the delay slot after every
> call to the trace routine "_mcount" (some legacy thing where 2 arguments
> used to be pushed on the stack). The _mcount routine is expected to
> adjust the sp by +8 before returning.

So when not disabled, the original jalr and addiu will be there, so _mcount has
to adjust sp.

> The problem is that when tracing is disabled for a function, the
> "jalr _mcount" instruction is replaced with a nop, but the
> "addiu sp,sp,-8" is still executed and the stack pointer is left
> trashed. When frame pointers are enabled the problem is masked
> because any access to the stack is done through the frame
> pointer and the stack pointer is restored from the frame pointer when
> the function returns.
>
> This patch writes two nops starting at the address of the "jalr _mcount"
> instruction whenever tracing is disabled. This means that the
> "addiu sp,sp.-8" will be converted to a nop along with the "jalr".

When disabled, there will be two nops.

> This is SMP safe because the first time this happens is during
> ftrace_init() which is before any other processor has been started.
> Subsequent calls to enable/disable tracing when other CPUs ARE running
> will still be safe because the enable will only change the first nop
> to a "jalr" and the disable, while writing 2 nops, will only be changing

When re-enabled, there will be a jalr and a nop, which differs from the initial
case, so _mcount doesn't have to adjust sp?

> @@ -69,7 +68,7 @@ NESTED(ftrace_caller, PT_SIZE, ra)
> .globl _mcount
>  _mcount:
> b   ftrace_stub
> -nop
> +   addiu sp,sp,8
> lw  t1, function_trace_stop
> bnezt1, ftrace_stub
> nop

But _mcount will always adjust the stack pointer?
What am I missing?

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 55/86] drivers/net/wireless/ti/wl1251: remove depends on CONFIG_EXPERIMENTAL

[Luciano Coelho]

Hi Kees,

On Wed, 2013-01-16 at 18:53 -0800, Kees Cook wrote:
> The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
> while now and is almost always enabled by default. As agreed during the
> Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
> 
> Cc: Luciano Coelho 
> Cc: "John W. Linville" 
> Cc: "David S. Miller" 
> Cc: Greg Kroah-Hartman 
> Signed-off-by: Kees Cook 
> ---
>  drivers/net/wireless/ti/wl1251/Kconfig |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/wireless/ti/wl1251/Kconfig 
> b/drivers/net/wireless/ti/wl1251/Kconfig
> index 1fb6584..8fec4ed 100644
> --- a/drivers/net/wireless/ti/wl1251/Kconfig
> +++ b/drivers/net/wireless/ti/wl1251/Kconfig
> @@ -1,6 +1,6 @@
>  menuconfig WL1251
>   tristate "TI wl1251 driver support"
> - depends on MAC80211 && EXPERIMENTAL && GENERIC_HARDIRQS
> + depends on MAC80211 && GENERIC_HARDIRQS
>   select FW_LOADER
>   select CRC7
>   ---help---

This is already in my tree and will be sent up to wireless-next this
week.

--
Cheers,
Luca.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 66/86] drivers/video/console: remove depends on CONFIG_EXPERIMENTAL

[Geert Uytterhoeven]

On Thu, Jan 17, 2013 at 3:53 AM, Kees Cook  wrote:
> The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
> while now and is almost always enabled by default. As agreed during the
> Linux kernel summit, remove it from any "depends on" lines in Kconfigs.

>  config MDA_CONSOLE
> depends on !M68K && !PARISC && ISA
> -   tristate "MDA text console (dual-headed) (EXPERIMENTAL)"
> +   tristate "MDA text console (dual-headed)"

This is not a "depends on" line.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v5 0/5] Add movablecore_map boot option

[H. Peter Anvin]

On 01/16/2013 09:08 PM, Yasuaki Ishimatsu wrote:


I thought about the method of specifying the node. But I think
this method is inconvenience. Node number is decided by OS.
So the number is changed easily.

for example:

o exmaple 1
   System has 3 nodes:
   node0, node1, node2

   When user remove node1, the system has:
   node0, node2

   But after rebooting the system, the system has:
   node0, node1

   So node2 becomes node1.

o example 2:
   System has 2 nodes:
   0x4000 - 0x7fff : node0
   0xc000 - 0x : node1

   When user add a node wchih memory range is [0x8000 - 0xbfff],
   system has:
   0x4000 - 0x7fff : node0
   0xc000 - 0x : node1
   0x8000 - 0xbfff : node2

   But after rebooting the system, the system's node may become:
   0x4000 - 0x7fff : node0
   0x8000 - 0xbfff : node1
   0xc000 - 0x : node2

   So node nunber is changed.

Specifying node number may be easy method than specifying memory
range. But if user uses node number for specifying removable memory,
user always need to care whether node number is changed or not at
every hotplug operation.




Well, there are only two options:

1. The user doesn't care which nodes are movable.  In that case, the 
user may just want to specify a target as a percentage of memory to make 
movable -- effectively a "slider" on the performance vs. reliability 
spectrum.  The kernel can then assign nodes arbitrarily.


2. If the user *does* care which nodes are movable, then the user needs 
to be able to specify that *in a way that makes sense to the user*. 
This may mean involving the DMI information as well as SRAT in order to 
get "silk screen" type information out.


-hpa



--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] drivers/pinctrl: grab default handles from device core

[Simon Horman]

On Wed, Jan 16, 2013 at 10:49:05AM -0700, Stephen Warren wrote:
> On 01/11/2013 01:45 PM, Linus Walleij wrote:
> > On Fri, Jan 11, 2013 at 9:36 PM, Laurent Pinchart
> >  wrote:
> > 
> >> I've sent several patch series for the SH PFC (Pin Function Controller) to 
> >> the
> >> linux-sh mailing list. One of the series included pinctrl core patches for
> >> easier testing, but I made it clear that they should *not* be pushed to
> >> mainline through the SH tree.
> > 
> > No big deal, what fun is linux-next if we don't break it ;-)
> 
> Hmm. It's causing a lot of engineers here a lot of trouble, since they
> all see linux-next won't boot, and haven't been paying enough attention
> to know which commit to revert:-(. Lots of lost productivity:-(
> 
> Simon, the offending commit:
> 
> 6d3ef6b drivers/pinctrl: grab default handles from device core
> 
> is still in next-20130116. Can you please remove it?

I removed the commit yesterday.
Please let me know if it seems to be lingering.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: manual merge of the samsung tree with the arm-soc tree

[Stephen Rothwell]

Hi Kukjin,

On Wed, 16 Jan 2013 21:13:00 -0800 Kukjin Kim  wrote:
>
> One more, following is my preferred resolution when merge conflict happens
> between Samsung tree and arm-soc tree:

Thanks, I will use this resolution tomorrow.  You will still get
notification emails just to double check.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpOeNP6hfLvN.pgp
Description: PGP signature

Re: [RFC PATCH 0/2] sched: simplify the select_task_rq_fair()

[Michael Wang]

Hi, Mike

I've send out the v2, which I suppose it will fix the below BUG and
perform better, please do let me know if it still cause issues on your
arm7 machine.

Regards,
Michael Wang


On 01/14/2013 05:21 PM, Mike Galbraith wrote:
> On Sat, 2013-01-12 at 11:19 +0100, Mike Galbraith wrote:
> 
>> Hm, low end takes a big hit.
> 
> Bah, that's perturbations and knobs.
> 
> aim7 compute, three individual runs + average
> 
> Stock scheduler knobs..
> 
> 3.8-wangavg 3.8-virgin
>   avgvs wang
> Tasksjobs/min  jobs/min   
>  jobs/min
> 1  435.97433.48433.48434.31436.91436.60
> 434.41435.97  1.003
> 5 2108.56   2120.36   2153.52   2127.48   2239.47   2257.82   
> 2285.07   2260.78  1.062
>10 4205.41   4167.81   4294.83   4222.68   4223.00   4199.58   
> 4252.63   4225.07  1.000
>20 8511.24   8434.24   8614.07   8519.85   8523.21   8505.26   
> 8931.47   8653.31  1.015
>4013209.81   6389.04   5308.80   8302.55  13011.27  13131.09  
> 13788.40  13310.25  1.603
>8012239.33  17797.36  20438.45  16825.04  15380.71  14372.96  
> 14080.74  13921.31   .827
>   16052638.44  52609.88  37364.16  47537.49  26644.68  44826.63  
> 41703.23  37724.84   .793
>   320   105162.69 111512.36 105909.34 107528.13 102386.48 106141.22 
> 103424.00 103983.90   .967
>   640   207290.22 207623.13 204556.96 206490.10 196673.43 193243.65 
> 190210.89 193375.99   .936
>  1280   329795.92 326739.68 328399.66 328311.75 305867.51 307931.72 
> 305988.17 306595.80   .933
>  2560   414580.44 418156.33 413035.14 415257.30 404000.00 403894.82 
> 402428.02 403440.94   .971
> 
> Twiddled knobs..
> sched_latency_ns = 24ms
> sched_min_granularity_ns = 8ms
> sched_wakeup_granularity_ns = 10ms
> 
> 3.8-wangavg 3.8-virgin
>   avgvs wang
> Tasksjobs/min  jobs/min   
>  jobs/min
> 1  437.23437.23436.91437.12437.86439.45
> 438.18438.49  1.003
> 5 2102.71   2121.85   2130.80   2118.45   2223.04   2165.83   
> 2314.74   2234.53  1.054
>10 4282.69   4252.63   4378.61   4304.64   4310.10   4303.98   
> 4310.10   4308.06  1.000
>20 8675.73   8650.96   8725.70   8684.13   8595.74   8638.63   
> 8725.70   8653.35   .996
>4016546.08  16512.26  16546.08  16534.80  17022.47  16798.34  
> 16717.24  16846.01  1.018
>8032712.55  32602.56  32493.30  32602.80  33137.39  33137.39  
> 32890.09  33054.95  1.013
>   16063372.55  63125.00  63663.82  63387.12  64510.98  64382.47  
> 64084.60  64326.01  1.014
>   320   121885.61 122656.55 121503.76 122015.30 121124.30 121885.61 
> 121732.58 121580.83   .996
>   640   218010.12 216066.85 217034.14 217037.03 213450.74 212864.98 
> 212282.43 212866.05   .980
>  1280   332339.33 332197.00 332624.36 332386.89 325915.97 325505.67 
> 325232.70 325551.44   .979
>  2560   426901.49 42.67 427254.20 426940.78 424448.70 425263.16 
> 424564.86 424758.90   .994
> 
> Much better, ~no difference between kernels for this load.
> 
> Except patched 3.8-rc3 kernel crashes on reboot. 
> 
> Please stand by while rebooting the system...
> [  123.104064] kvm: exiting hardware virtualization
> [  123.302908] Disabling[  124.729877] BUG: unable to handle kernel NULL 
> pointer dereference at 0040
> [  124.758804] IP: [] wake_affine+0x26/0x2f0
> [  124.785634] PGD e7089b067 PUD e736f7067 PMD 0 
> [  124.810176] Oops:  [#1] SMP 
> [  124.829767] Modules linked in: iptable_filter ip_tables x_tables nfsv3 
> nfs_acl nfs fscache lockd sunrpc autofs4 edd af_packet cpufreq_conservative 
> cpufreq_userspace cpufreq_powersave acpi_cpufreq mperf fuse loop dm_mod 
> coretemp kvm_intel iTCO_wdt kvm iTCO_vendor_support i7core_edac igb ioatdma 
> lpc_ich tpm_tis ptp crc32c_intel ipv6 joydev edac_core mfd_core pps_core dca 
> microcode tpm hid_generic i2c_i801 tpm_bios ehci_pci acpi_memhotplug sr_mod 
> container pcspkr sg cdrom button rtc_cmos ext3 jbd mbcache mgag200 ttm 
> drm_kms_helper drm i2c_algo_bit sysimgblt sysfillrect i2c_core syscopyarea 
> usbhid hid uhci_hcd ehci_hcd usbcore usb_common sd_mod crc_t10dif processor 
> thermal_sys hwmon scsi_dh_alua scsi_dh_rdac scsi_dh_hp_sw scsi_dh_emc scsi_dh 
> ata_generic ata_piix libata megaraid_sas scsi_mod
> [  125.093116] CPU 36 
> [  125.097498] Pid: 0, comm: swapper/36 Not tainted 3.8.0-wang #58 QCI 
> QSSC-S4R/QSSC-S4R
> [  125.148934] RIP: 0010:[]  [] 
> wake_affine+0x26/0x2f0
> [  125.183856] RSP: 0018:88046d9dfc70  EFLAGS: 00010082
> [  125.213390] RAX: 0001 RBX: 0024 RCX: 
> 0046

[RFC PATCH v2 3/3] sched: simplify select_task_rq_fair() with schedule balance map

[Michael Wang]

Since schedule balance map provide the approach to get proper sd directly,
simplify the code of select_task_rq_fair() is possible.

The new code is designed to reserve most of the old logical, but get rid
of those 'for' by using the schedule balance map to locate proper sd
directly.

Signed-off-by: Michael Wang 
---
 kernel/sched/fair.c |  131 +++
 1 files changed, 69 insertions(+), 62 deletions(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 5eea870..d600708 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -3302,100 +3302,107 @@ done:
 }
 
 /*
- * sched_balance_self: balance the current task (running on cpu) in domains
- * that have the 'flag' flag set. In practice, this is SD_BALANCE_FORK and
- * SD_BALANCE_EXEC.
+ * select_task_rq_fair()
+ * select a proper cpu for task to run.
  *
- * Balance, ie. select the least loaded group.
- *
- * Returns the target CPU number, or the same CPU if no balancing is needed.
- *
- * preempt must be disabled.
+ * p   -- the task we are going to select cpu for
+ * sd_flag -- indicate the context, WAKE, EXEC or FORK.
+ * wake_flag   -- we only care about WF_SYNC currently
  */
 static int
 select_task_rq_fair(struct task_struct *p, int sd_flag, int wake_flags)
 {
-   struct sched_domain *tmp, *affine_sd = NULL, *sd = NULL;
+   struct sched_domain *sd = NULL;
int cpu = smp_processor_id();
int prev_cpu = task_cpu(p);
int new_cpu = cpu;
-   int want_affine = 0;
int sync = wake_flags & WF_SYNC;
+   struct sched_balance_map *sbm = NULL;
+   int type = 0;
 
if (p->nr_cpus_allowed == 1)
return prev_cpu;
 
-   if (sd_flag & SD_BALANCE_WAKE) {
-   if (cpumask_test_cpu(cpu, tsk_cpus_allowed(p)))
-   want_affine = 1;
-   new_cpu = prev_cpu;
-   }
+   if (sd_flag & SD_BALANCE_EXEC)
+   type = SBM_EXEC_TYPE;
+   else if (sd_flag & SD_BALANCE_FORK)
+   type = SBM_FORK_TYPE;
+   else if (sd_flag & SD_BALANCE_WAKE)
+   type = SBM_WAKE_TYPE;
 
rcu_read_lock();
-   for_each_domain(cpu, tmp) {
-   if (!(tmp->flags & SD_LOAD_BALANCE))
-   continue;
 
+   sbm = cpu_rq(cpu)->sbm;
+   if (!sbm)
+   goto unlock;
+
+   if (sd_flag & SD_BALANCE_WAKE) {
/*
-* If both cpu and prev_cpu are part of this domain,
-* cpu is a valid SD_WAKE_AFFINE target.
+* Tasks to be waked is special, memory it relied on
+* may has already been cached on prev_cpu, and usually
+* they require low latency.
+*
+* So firstly try to locate an idle cpu shared the cache
+* with prev_cpu, it has the chance to break the load
+* balance, fortunately, select_idle_sibling() will search
+* from top to bottom, which help to reduce the chance in
+* some cases.
 */
-   if (want_affine && (tmp->flags & SD_WAKE_AFFINE) &&
-   cpumask_test_cpu(prev_cpu, sched_domain_span(tmp))) {
-   affine_sd = tmp;
-   break;
-   }
+   new_cpu = select_idle_sibling(p, prev_cpu);
+   if (idle_cpu(new_cpu))
+   goto unlock;
 
-   if (tmp->flags & sd_flag)
-   sd = tmp;
-   }
+   /*
+* No idle cpu could be found in the topology of prev_cpu,
+* before jump into the slow balance_path, try search again
+* in the topology of current cpu if it is the affine of
+* prev_cpu.
+*/
+   if (!sbm->affine_map[prev_cpu] ||
+   !cpumask_test_cpu(cpu, tsk_cpus_allowed(p)))
+   goto balance_path;
 
-   if (affine_sd) {
-   if (cpu != prev_cpu && wake_affine(affine_sd, p, sync))
-   prev_cpu = cpu;
+   new_cpu = select_idle_sibling(p, cpu);
+   if (!idle_cpu(new_cpu))
+   goto balance_path;
 
-   new_cpu = select_idle_sibling(p, prev_cpu);
-   goto unlock;
+   /*
+* Invoke wake_affine() finally since it is no doubt a
+* performance killer.
+*/
+   if (wake_affine(sbm->affine_map[prev_cpu], p, sync))
+   goto unlock;
}
 
+balance_path:
+   new_cpu = (sd_flag & SD_BALANCE_WAKE) ? prev_cpu : cpu;
+   sd = sbm->sd[type][sbm->top_level[type]];
+
while (sd) {
int load_idx = sd->forkexec_idx;
-   struct sched_group *group;
-   int weight;
-
-  

[RFC PATCH v2 2/3] sched: build schedule balance map

[Michael Wang]

This patch will build schedule balance map as designed, now
cpu_sbm->sd[f][l] can directly locate the sd of cpu on level 'l'
with flag 'f' supported.

In order to quickly locate the lower sd while changing the base cpu,
the level with empty sd in map will be filled with the lower sd.

Signed-off-by: Michael Wang 
---
 kernel/sched/core.c |   70 +++
 1 files changed, 70 insertions(+), 0 deletions(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 092c801..0c63303 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -5578,6 +5578,62 @@ static void update_top_cache_domain(int cpu)
 static int sbm_max_level;
 DEFINE_PER_CPU_SHARED_ALIGNED(struct sched_balance_map, sbm_array);
 
+static void build_sched_balance_map(int cpu)
+{
+   struct sched_balance_map *sbm = _cpu(sbm_array, cpu);
+   struct sched_domain *sd = cpu_rq(cpu)->sd;
+   struct sched_domain *top_sd = NULL;
+   int i, type, level = 0;
+
+   memset(sbm->top_level, 0, sizeof((*sbm).top_level));
+   memset(sbm->affine_map, 0, sizeof((*sbm).affine_map));
+   for (type = 0; type < SBM_MAX_TYPE; type++) {
+   memset(sbm->sd[type], 0,
+   sizeof(struct sched_domain *) * sbm_max_level);
+   }
+
+   while (sd) {
+   if (!(sd->flags & SD_LOAD_BALANCE))
+   continue;
+
+   if (sd->flags & SD_BALANCE_EXEC) {
+   sbm->top_level[SBM_EXEC_TYPE] = sd->level;
+   sbm->sd[SBM_EXEC_TYPE][sd->level] = sd;
+   }
+
+   if (sd->flags & SD_BALANCE_FORK) {
+   sbm->top_level[SBM_FORK_TYPE] = sd->level;
+   sbm->sd[SBM_FORK_TYPE][sd->level] = sd;
+   }
+
+   if (sd->flags & SD_BALANCE_WAKE) {
+   sbm->top_level[SBM_WAKE_TYPE] = sd->level;
+   sbm->sd[SBM_WAKE_TYPE][sd->level] = sd;
+   }
+
+   if (sd->flags & SD_WAKE_AFFINE) {
+   for_each_cpu(i, sched_domain_span(sd)) {
+   if (!sbm->affine_map[i])
+   sbm->affine_map[i] = sd;
+   }
+   }
+
+   sd = sd->parent;
+   }
+
+   /*
+* fill the hole to get lower level sd easily.
+*/
+   for (type = 0; type < SBM_MAX_TYPE; type++) {
+   level = sbm->top_level[type];
+   top_sd = sbm->sd[type][level];
+   if ((++level != sbm_max_level) && top_sd) {
+   for (; level < sbm_max_level; level++)
+   sbm->sd[type][level] = top_sd;
+   }
+   }
+}
+
 /*
  * Attach the domain 'sd' to 'cpu' as its base domain. Callers must
  * hold the hotplug lock.
@@ -5587,6 +5643,9 @@ cpu_attach_domain(struct sched_domain *sd, struct 
root_domain *rd, int cpu)
 {
struct rq *rq = cpu_rq(cpu);
struct sched_domain *tmp;
+   struct sched_balance_map *sbm = _cpu(sbm_array, cpu);
+
+   rcu_assign_pointer(rq->sbm, NULL);
 
/* Remove the sched domains which do not contribute to scheduling. */
for (tmp = sd; tmp; ) {
@@ -5619,6 +5678,17 @@ cpu_attach_domain(struct sched_domain *sd, struct 
root_domain *rd, int cpu)
destroy_sched_domains(tmp, cpu);
 
update_top_cache_domain(cpu);
+
+   /* disable sbm if initialization failed or sd detached. */
+   if (!sbm_max_level || !sd)
+   return;
+
+   /*
+* synchronize_rcu() is unnecessary here since
+* destroy_sched_domains() already do the work.
+*/
+   build_sched_balance_map(cpu);
+   rcu_assign_pointer(rq->sbm, sbm);
 }
 
 /* cpus with isolated domains */
-- 
1.7.4.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC PATCH v2 1/3] sched: schedule balance map foundation

[Michael Wang]

In order to get rid of the complex code in select_task_rq_fair(),
approach to directly get sd on each level with proper flag is
required.

Schedule balance map is the solution, which record the sd according
to it's flag and level.

For example, cpu_sbm->sd[wake][l] will locate the sd of cpu which
support wake up on level l.

This patch contain the foundation of schedule balance map in order
to serve the follow patches.

Signed-off-by: Michael Wang 
---
 kernel/sched/core.c  |   44 
 kernel/sched/sched.h |   14 ++
 2 files changed, 58 insertions(+), 0 deletions(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 257002c..092c801 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -5575,6 +5575,9 @@ static void update_top_cache_domain(int cpu)
per_cpu(sd_llc_id, cpu) = id;
 }
 
+static int sbm_max_level;
+DEFINE_PER_CPU_SHARED_ALIGNED(struct sched_balance_map, sbm_array);
+
 /*
  * Attach the domain 'sd' to 'cpu' as its base domain. Callers must
  * hold the hotplug lock.
@@ -6037,6 +6040,46 @@ static struct sched_domain_topology_level 
default_topology[] = {
 
 static struct sched_domain_topology_level *sched_domain_topology = 
default_topology;
 
+static void sched_init_sbm(void)
+{
+   size_t size;
+   int cpu, type, node;
+   struct sched_balance_map *sbm;
+   struct sched_domain_topology_level *tl;
+
+   /*
+* Inelegant method, any good idea?
+*/
+   for (tl = sched_domain_topology; tl->init; tl++, sbm_max_level++)
+   ;
+
+   for_each_possible_cpu(cpu) {
+   sbm = _cpu(sbm_array, cpu);
+   node = cpu_to_node(cpu);
+   size = sizeof(struct sched_domain *) * sbm_max_level;
+
+   for (type = 0; type < SBM_MAX_TYPE; type++) {
+   sbm->sd[type] = kmalloc_node(size, GFP_KERNEL, node);
+   WARN_ON(!sbm->sd[type]);
+   if (!sbm->sd[type])
+   goto failed;
+   }
+   }
+
+   return;
+
+failed:
+   for_each_possible_cpu(cpu) {
+   sbm = _cpu(sbm_array, cpu);
+
+   for (type = 0; type < SBM_MAX_TYPE; type++)
+   kfree(sbm->sd[type]);
+   }
+
+   /* prevent further work */
+   sbm_max_level = 0;
+}
+
 #ifdef CONFIG_NUMA
 
 static int sched_domains_numa_levels;
@@ -6765,6 +6808,7 @@ void __init sched_init_smp(void)
alloc_cpumask_var(_doms, GFP_KERNEL);
 
sched_init_numa();
+   sched_init_sbm();
 
get_online_cpus();
mutex_lock(_domains_mutex);
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index fc88644..d060913 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -349,6 +349,19 @@ struct root_domain {
 
 extern struct root_domain def_root_domain;
 
+enum {
+   SBM_EXEC_TYPE,
+   SBM_FORK_TYPE,
+   SBM_WAKE_TYPE,
+   SBM_MAX_TYPE
+};
+
+struct sched_balance_map {
+   struct sched_domain **sd[SBM_MAX_TYPE];
+   int top_level[SBM_MAX_TYPE];
+   struct sched_domain *affine_map[NR_CPUS];
+};
+
 #endif /* CONFIG_SMP */
 
 /*
@@ -416,6 +429,7 @@ struct rq {
 #ifdef CONFIG_SMP
struct root_domain *rd;
struct sched_domain *sd;
+   struct sched_balance_map *sbm;
 
unsigned long cpu_power;
 
-- 
1.7.4.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 16/22] sched: add power aware scheduling in fork/exec/wake

[Namhyung Kim]

On Wed, 16 Jan 2013 14:27:30 +, Morten Rasmussen wrote:
> On Wed, Jan 16, 2013 at 06:02:21AM +, Alex Shi wrote:
>> On 01/15/2013 12:09 AM, Morten Rasmussen wrote:
>> > On Fri, Jan 11, 2013 at 07:08:45AM +, Alex Shi wrote:
>> >> On 01/10/2013 11:01 PM, Morten Rasmussen wrote:
>> >> For power consideration scenario, it ask task number less than Lcpu
>> >> number, don't care the load weight, since whatever the load weight, the
>> >> task only can burn one LCPU.
>> >>
>> > 
>> > True, but you miss the opportunities for power saving when you have many
>> > light tasks (> LCPU). Currently, the sd_utils < threshold check will go
>> > for SCHED_POLICY_PERFORMANCE if the number tasks (sd_utils) is greater
>> > than the domain weight/capacity irrespective of the actual load caused
>> > by those tasks.
>> > 
>> > If you used tracked task load weight for sd_utils instead you would be
>> > able to go for power saving in scenarios with many light tasks as well.
>> 
>> yes, that's right on power consideration. but for performance consider,
>> it's better to spread tasks on different LCPU to save CS cost. And if
>> the cpu usage is nearly full, we don't know if some tasks real want more
>> cpu time.
>
> If the cpu is nearly full according to its tracked load it should not be
> used for packing more tasks. It is the nearly idle scenario that I am
> more interested in. If you have lots of task with tracked load <10% then
> why not pack them. The performance impact should be minimal.
>
> Furthermore, nr_running is just a snapshot of the current runqueue
> status. The combination of runnable and blocked load should give a
> better overall view of the cpu loads.

I have a feeling that power aware scheduling policy has to deal only
with the utilization.  Of course it only works under a certain threshold
and if it's exceeded must be changed to other policy which cares the
load weight/average.  Just throwing an idea. :)

>
>> Even in the power sched policy, we still want to get better performance
>> if it's possible. :)
>
> I agree if it comes for free in terms of power. In my opinion it is
> acceptable to sacrifice a bit of performance to save power when using a
> power sched policy as long as the performance regression can be
> justified by the power savings. It will of course depend on the system
> and its usage how trade-off power and performance. My point is just that
> with multiple sched policies (performance, balance and power as you
> propose) it should be acceptable to focus on power for the power policy
> and let users that only/mostly care about performance use the balance or
> performance policy.

Agreed.

>
>> > 
>>  +
>>  +   if (sched_policy == SCHED_POLICY_POWERSAVING)
>>  +   threshold = sgs.group_weight;
>>  +   else
>>  +   threshold = sgs.group_capacity;
>> >>>
>> >>> Is group_capacity larger or smaller than group_weight on your platform?
>> >>
>> >> Guess most of your confusing come from the capacity != weight here.
>> >>
>> >> In most of Intel CPU, a cpu core's power(with 2 HT) is usually 1178, it
>> >> just bigger than a normal cpu power - 1024. but the capacity is still 1,
>> >> while the group weight is 2.
>> >>
>> > 
>> > Thanks for clarifying. To the best of my knowledge there are no
>> > guidelines for how to specify cpu power so it may be a bit dangerous to
>> > assume that capacity < weight when capacity is based on cpu power.
>> 
>> Sure. I also just got them from code. and don't know other arch how to
>> different them.
>> but currently, seems this cpu power concept works fine.
>
> Yes, it seems to work fine for your test platform. I just want to
> highlight that the assumption you make might not be valid for other
> architectures. I know that cpu power is not widely used, but that may
> change with the increasing focus on power aware scheduling.

AFAIK on ARM big.LITTLE, a big cpu will have a cpu power more than
1024.  I'm sure Morten knows way more than me on this. :)

Thanks,
Namhyung
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC PATCH v2 0/3] sched: simplify the select_task_rq_fair()

[Michael Wang]

v2 change log:
Fix code style issues.
Fix BUG of NULL affine_sd.
Add the support for NUMA domain.
Other small fix according to the old logical.
Provide more test data with finer granularity.

This patch set is trying to simplify the select_task_rq_fair() with
schedule balance map.

After get rid of the complex code and reorganize the logical, pgbench show
the improvement, more the clients, bigger the improvement.

Prev:   Post:

| db_size | clients |   | tps  ||  tps  | 
+-+-+   +--++---+
| 22 MB   |   1 |   |10794 || 10862 |
| 22 MB   |   2 |   |21567 || 21711 |
| 22 MB   |   4 |   |41621 || 42609 |
| 22 MB   |   8 |   |53883 || 58184 |   +7.98%
| 22 MB   |  12 |   |50818 || 53464 |   +5.21%
| 22 MB   |  16 |   |50463 || 55034 |   +9.06%
| 22 MB   |  24 |   |46698 || 53702 |   +15.00%
| 22 MB   |  32 |   |43404 || 54030 |   +24.48%
| 7484 MB |   1 |   | 7974 ||  8431 |
| 7484 MB |   2 |   |19341 || 19509 |
| 7484 MB |   4 |   |36808 || 38038 |
| 7484 MB |   8 |   |47821 || 50377 |   +5.34%
| 7484 MB |  12 |   |45913 || 49128 |   +7.00%
| 7484 MB |  16 |   |46478 || 49670 |   +6.87%
| 7484 MB |  24 |   |42793 || 48461 |   +13.25%
| 7484 MB |  32 |   |36329 || 48436 |   +33.33%
| 15 GB   |   1 |   | 7636 ||  7852 |
| 15 GB   |   2 |   |19195 || 19369 |
| 15 GB   |   4 |   |35975 || 37323 |
| 15 GB   |   8 |   |47919 || 50246 |   +4.86%
| 15 GB   |  12 |   |45397 || 48608 |   +7.07%
| 15 GB   |  16 |   |45926 || 49192 |   +7.11%
| 15 GB   |  24 |   |42184 || 48007 |   +13.80%
| 15 GB   |  32 |   |35983 || 47955 |   +33.27%

Please check the patch for more details about schedule balance map.

Support the NUMA domain but not tested.
Support the rebuild of domain but not tested.

Comments are very welcomed.

BTW:
Compared with 3.7.0-rc6, 3.8.0-rc3 show big improvement with few
clients, but get some damage with many clients, whatever, this patch
set will help both of them to gain better performance.

Test with:
12 cpu X86 server and linux-next 3.8.0-rc3.

Michael Wang (3):
[RFC PATCH v2 1/3] sched: schedule balance map foundation
[RFC PATCH v2 2/3] sched: build schedule balance map
[RFC PATCH v2 3/3] sched: simplify select_task_rq_fair() with schedule 
balance map

Signed-off-by: Michael Wang 
---
 b/kernel/sched/core.c  |   44 
 b/kernel/sched/fair.c  |  131 +
 b/kernel/sched/sched.h |   14 +
 kernel/sched/core.c|   70 ++
 4 files changed, 197 insertions(+), 62 deletions(-)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] cxgb4i: Remove the scsi host device when removing device

[Mike Christie]

On 01/11/2013 01:12 PM, Thadeu Lima de Souza Cascardo wrote:
> When doing a hotplug remove of a cxgb4 device, there are still dandling
> symlinks at /sys/class/scsi_host/hostX to the removed PCI device. The
> upper layer device may also try to send data, which may crash the
> system.
> 
> The DETACH message from the lower level driver is sent to the ULD when
> the device is removed, when the scsi host should be removed from the
> system, avoiding any problems.
> 
> After this patch, there are no more dangling symlinks and many attempts
> to crash the system while there is SCSI activity and removing the device
> have failed. Adding the device back again works as expected, with the
> scsi hosts showing up again.
> 
> Based on a patch by Karen Xie.
> 
> Cc: Karen Xie 
> Cc: Divy La Rey 
> Signed-off-by: Thadeu Lima de Souza Cascardo 
> ---
>  drivers/scsi/cxgbi/cxgb4i/cxgb4i.c |1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c 
> b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
> index f924b3c..3fecf35 100644
> --- a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
> +++ b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
> @@ -1564,6 +1564,7 @@ static int t4_uld_state_change(void *handle, enum 
> cxgb4_state state)
>   break;
>   case CXGB4_STATE_DETACH:
>   pr_info("cdev 0x%p, DETACH.\n", cdev);
> + cxgbi_device_unregister(cdev);
>   break;
>   default:
>   pr_info("cdev 0x%p, unknown state %d.\n", cdev, state);
> 

Patch looks ok to me.

Reviewed-by: Mike Christie 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] regulator: lp8755: Don't show unrelated messags in lp8755_probe error paths

[gshark]

2013년 01월 12일 15:58, Axel Lin 쓴 글:

Signed-off-by: Axel Lin
---
  drivers/regulator/lp8755.c |   19 ++-
  1 file changed, 10 insertions(+), 9 deletions(-)

diff --git a/drivers/regulator/lp8755.c b/drivers/regulator/lp8755.c
index decb3ad..8c3f3f2 100644
--- a/drivers/regulator/lp8755.c
+++ b/drivers/regulator/lp8755.c
@@ -497,35 +497,36 @@ static int lp8755_probe(struct i2c_client *client,
if (!pchip->pdata)
return -ENOMEM;
ret = lp8755_init_data(pchip);
-   if (ret < 0)
-   goto err_chip_init;
+   if (ret < 0) {
+   dev_err(>dev, "fail to initialize chip\n");
+   return ret;
+   }
}
  
  	ret = lp8755_regulator_init(pchip);

-   if (ret < 0)
+   if (ret < 0) {
+   dev_err(>dev, "fail to initialize regulators\n");
goto err_regulator;
+   }
  
  	pchip->irq = client->irq;

ret = lp8755_int_config(pchip);
-   if (ret < 0)
+   if (ret < 0) {
+   dev_err(>dev, "fail to irq config\n");
goto err_irq;
+   }
  
  	return ret;
  
  err_irq:

-   dev_err(>dev, "fail to irq config\n");
-
for (icnt = 0; icnt < mphase_buck[pchip->mphase].nreg; icnt++)
regulator_unregister(pchip->rdev[icnt]);
  
  err_regulator:

-   dev_err(>dev, "fail to initialize regulators\n");
/* output disable */
for (icnt = 0; icnt < 0x06; icnt++)
lp8755_write(pchip, icnt, 0x00);
  
-err_chip_init:

-   dev_err(>dev, "fail to initialize chip\n");
return ret;
  }
  

It is nice to us also and this patch was tested using a lp8755 board.
Thank you Axel.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: sched: Consequences of integrating the Per Entity Load Tracking Metric into the Load Balancer

[Namhyung Kim]

On Wed, 16 Jan 2013 22:08:21 +0800, Alex Shi wrote:
> On 01/08/2013 04:41 PM, Preeti U Murthy wrote:
>> Hi Mike,
>> 
>> Thank you very much for such a clear and comprehensive explanation.
>> So when I put together the problem and the proposed solution pieces in the 
>> current
>> scheduler scalability,the following was what I found:
>> 
>> 1. select_idle_sibling() is needed as an agent to correctly find the right 
>> cpu for wake
>>up tasks to go to."Correctly" would be to find an idle cpu at the lowest 
>> cost possible.
>> 2."Cost could be lowered" either by optimizing the order of searching for an 
>> idle cpu or
>>restricting the search to a few cpus alone.
>> 3. The former has the problem that it would not prevent bouncing tasks all 
>> over the domain
>>sharing an L3 cache,which could potentially affect the fast moving tasks.
>> 4. The latter has the problem that it is not aggressive enough in finding an 
>> idle cpu.
>> 
>> This is some tangled problem,but I think the solution at best could be 
>> smoothed to a a flowchart.
>> 
>>STEP1   STEP2STEP3
>>  _
>> | |
>> |See if the idle buddy|No_  Yes   
>> |is free at all sched |>| Do we search the|> |Optimized search|
>> |domains  | |sched domains|  ||
>> |_| |for an idle cpu  | |
>>   |Yes  |_|\|/
>>  \|/|No: saturated Return target cpu
>> Return \|/ system
>> cpu buddyReturn prev_cpu
>> 
>
>
>
> I re-written the patch as following. hackbench/aim9 doest show clean 
> performance change.
> Actually we can get some profit. it also will be very slight. :) 
> BTW, it still need another patch before apply this. Just to show the logical.
>
> ===
>> From 145ff27744c8ac04eda056739fe5aa907a00877e Mon Sep 17 00:00:00 2001
> From: Alex Shi 
> Date: Fri, 11 Jan 2013 16:49:03 +0800
> Subject: [PATCH 3/7] sched: select_idle_sibling optimization
>
> Current logical in this function will insist to wake up the task in a
> totally idle group, otherwise it would rather back to previous cpu.

Or current cpu depending on result of wake_affine(), right?

>
> The new logical will try to wake up the task on any idle cpu in the same
> cpu socket (in same sd_llc), while idle cpu in the smaller domain has
> higher priority.

But what about SMT domain?

I mean it seems that the code prefers running a task on a idle cpu which
is a sibling thread in the same core rather than running it on an idle
cpu in another idle core.  I guess we didn't do that before.

>
> It should has some help on burst wake up benchmarks like aim7.
>
> Original-patch-by: Preeti U Murthy 
> Signed-off-by: Alex Shi 
> ---
>  kernel/sched/fair.c |   40 +++-
>  1 files changed, 19 insertions(+), 21 deletions(-)
>
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index e116215..fa40e49 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -3253,13 +3253,13 @@ find_idlest_cpu(struct sched_group *group, struct 
> task_struct *p, int this_cpu)
>  /*
>   * Try and locate an idle CPU in the sched_domain.
>   */
> -static int select_idle_sibling(struct task_struct *p)
> +static int select_idle_sibling(struct task_struct *p,
> + struct sched_domain *affine_sd, int sync)

Where are these arguments used?


>  {
>   int cpu = smp_processor_id();
>   int prev_cpu = task_cpu(p);
>   struct sched_domain *sd;
>   struct sched_group *sg;
> - int i;
>  
>   /*
>* If the task is going to be woken-up on this cpu and if it is
> @@ -3281,27 +3281,25 @@ static int select_idle_sibling(struct task_struct *p)
>   /*
>* Otherwise, iterate the domains and find an elegible idle cpu.
>*/
> - sd = rcu_dereference(per_cpu(sd_llc, prev_cpu));
> - for_each_lower_domain(sd) {
> + for_each_domain(prev_cpu, sd) {

Always start from the prev_cpu?


>   sg = sd->groups;
>   do {
> - if (!cpumask_intersects(sched_group_cpus(sg),
> - tsk_cpus_allowed(p)))
> - goto next;
> -
> - for_each_cpu(i, sched_group_cpus(sg)) {
> - if (!idle_cpu(i))
> - goto next;
> - }
> -
> - prev_cpu = cpumask_first_and(sched_group_cpus(sg),
> - tsk_cpus_allowed(p));
> - goto done;
> -next:
> - sg = sg->next;
> - } while (sg != sd->groups);
> + int nr_busy = atomic_read(>sgp->nr_busy_cpus);
> + int 

Re: [RFC PATCH v1 14/31] ARC: syscall support

[Vineet Gupta]

On Thursday 15 November 2012 06:05 PM, Arnd Bergmann wrote:
> On Thursday 15 November 2012, Vineet Gupta wrote:
>> So the primary concern here is not breaking the userspace ABI - right ?
>>
>> For syscalls I agree that we will indeed need to fix the ABI - by fixing
>> uClibc. And if uClibc doesn't merge the fixes we can stay out of tree
>> for uClibc - as we currently already are.
> 
> I'm sure we can find a solution for uClibc. We already have seven
> architectures using the generic syscalls, including at least one
> (arm64) that is going to run on a large number of installations
> in the future.
> 
>> For gdbserver, the kernel provides the complete regset ABI. However it
>> also provides a very limited version of old ABI - i.e. ptrace with
>> PEEKUSR/POKEUSR. Note that latter is just a shim layer and it reuses the
>> regset callbacks. This allows us to support the legacy gdbserver. If and
>> when gdbserver upgrades it can switch over to new interface. So all
>> along there will be NO ABI breakage at all. The cost is couple extra
>> functions in kernel which we might have to maintain for some foreseeable
>> future. Agree ?
> 
> It's more a question of principle. The rule is that we don't break user
> space, and ptrace is just another user space interface is this. If
> we merge it now, we will keep it around forever, taking it out later
> is not an option IMHO. My preference would be not to merge the backwards
> compatibility layer for ptrace at all, but I'm willing to listen to
> other people that support your view if you want to keep it. In one
> way, ptrace is less critical than the other system calls, and that is
> because it's already architecture specific.
> 
>   Arnd
> 

OK as of now the legacy syscall ABI and ptrace PEEKUSR/POKEUSR are taken out of
submissions tree - we'll carry these out-of-tree for sometime before eventually
moving to newer uClibc/gdbserver which don't need these O-O-T patches.

-Vineet
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: linux-next: manual merge of the samsung tree with the arm-soc tree

[Kukjin Kim]

Kukjin Kim wrote:

[...]

> Hmm, updating timer patches in Samsung tree cause the merge conflicts with
> arm-soc, so for now I dropped them in my tree just now.
> And note that regarding topic branch which are including it will be
re-worked
> soon :-)
> 
> Now to merge Samsung tree for linux-next should be fine.
> 
> Thanks again.
> 
One more, following is my preferred resolution when merge conflict happens
between Samsung tree and arm-soc tree:

8<---

diff --cc arch/arm/common/Makefile
index 55d4182,dc8dd0d..7a5df8b
--- a/arch/arm/common/Makefile
+++ b/arch/arm/common/Makefile
@@@ -2,10 -2,6 +2,8 @@@
  # Makefile for the linux kernel.
  #
  
 +obj-y += firmware.o
 +
- obj-$(CONFIG_ARM_GIC) += gic.o
- obj-$(CONFIG_ARM_VIC) += vic.o
  obj-$(CONFIG_ICST)+= icst.o
  obj-$(CONFIG_SA)  += sa.o
  obj-$(CONFIG_PCI_HOST_VIA82C505) += via82c505.o
diff --cc arch/arm/mach-exynos/mach-exynos4-dt.c
index ab1dacc,112d10e..3ac73ed
--- a/arch/arm/mach-exynos/mach-exynos4-dt.c
+++ b/arch/arm/mach-exynos/mach-exynos4-dt.c
@@@ -107,11 -106,9 +106,10 @@@ DT_MACHINE_START(EXYNOS4210_DT, "Samsun
.smp= smp_ops(exynos_smp_ops),
.init_irq   = exynos4_init_irq,
.map_io = exynos4_dt_map_io,
-   .handle_irq = gic_handle_irq,
 +  .init_early = exynos_firmware_init,
.init_machine   = exynos4_dt_machine_init,
.init_late  = exynos_init_late,
-   .timer  = _timer,
+   .init_time  = exynos4_timer_init,
.dt_compat  = exynos4_dt_compat,
.restart= exynos4_restart,
  MACHINE_END
diff --cc arch/arm/mach-exynos/platsmp.c
index 3226893,60f7c5b..a083e05
--- a/arch/arm/mach-exynos/platsmp.c
+++ b/arch/arm/mach-exynos/platsmp.c
@@@ -20,12 -20,11 +20,12 @@@
  #include 
  #include 
  #include 
+ #include 
  
  #include 
- #include 
  #include 
  #include 
 +#include 
  
  #include 
  #include 
@@@ -146,22 -145,11 +146,22 @@@ static int __cpuinit exynos_boot_second
  
timeout = jiffies + (1 * HZ);
while (time_before(jiffies, timeout)) {
 +  unsigned long boot_addr;
 +
smp_rmb();
  
 -  __raw_writel(virt_to_phys(exynos4_secondary_startup),
 -
cpu_boot_reg(phys_cpu));
 +  boot_addr = virt_to_phys(exynos4_secondary_startup);
 +
 +  /*
 +   * Try to set boot address using firmware first
 +   * and fall back to boot register if it fails.
 +   */
 +  if (call_firmware_op(set_cpu_boot_addr, phys_cpu,
boot_addr))
 +  __raw_writel(boot_addr, cpu_boot_reg(phys_cpu));
 +
 +  call_firmware_op(cpu_boot, phys_cpu);
 +
-   gic_raise_softirq(cpumask_of(cpu), 0);
+   arch_send_wakeup_ipi_mask(cpumask_of(cpu));
  
if (pen_release == -1)
break;

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v7 3/4] block: implement runtime pm strategy

[Aaron Lu]

On Wed, Jan 16, 2013 at 10:30:45AM -0500, Alan Stern wrote:
> On Wed, 16 Jan 2013, Aaron Lu wrote:
> 
> > From: Lin Ming 
> > 
> > When a request is added:
> > If device is suspended or is suspending and the request is not a
> > PM request, resume the device.
> > 
> > When the last request finishes:
> > Call pm_runtime_mark_last_busy().
> > 
> > When pick a request:
> > If device is resuming/suspending, then only PM request is allowed
> > to go.
> > 
> > Signed-off-by: Lin Ming 
> > Signed-off-by: Aaron Lu 
> 
> Just a couple of minor problems remaining...
> 
> > --- a/block/blk-core.c
> > +++ b/block/blk-core.c
> 
> > @@ -2051,6 +2063,28 @@ static void blk_account_io_done(struct request *req)
> > }
> >  }
> >  
> > +#ifdef CONFIG_PM_RUNTIME
> > +/*
> > + * Don't process normal requests when queue is suspended
> > + * or in the process of suspending/resuming
> > + */
> > +static struct request *blk_pm_peek_request(struct request_queue *q,
> > +  struct request *rq)
> > +{
> > +   if (q->rpm_status == RPM_SUSPENDED ||
> > +   (q->rpm_status != RPM_ACTIVE && !(rq->cmd_flags & REQ_PM)))
> > +   return NULL;
> > +   else
> > +   return rq;
> > +}
> 
> You don't check q->dev here, so the result is indefinite for devices
> that don't use runtime PM.  (Actually it will work out because
> RPM_ACTIVE is defined as 0, but that's a pretty fragile approach.)
> 
> Either do check q->dev here, or else explicitly initialize
> q->rpm_status when the queue is created.

I think I'll check q->dev, which is more clear.

> 
> 
> > --- a/block/elevator.c
> > +++ b/block/elevator.c
> > @@ -34,6 +34,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  
> >  #include 
> >  
> > @@ -515,6 +516,27 @@ void elv_bio_merged(struct request_queue *q, struct 
> > request *rq,
> > e->type->ops.elevator_bio_merged_fn(q, rq, bio);
> >  }
> >  
> > +#ifdef CONFIG_PM_RUNTIME
> > +static void blk_pm_requeue_request(struct request *rq)
> > +{
> > +   if (!(rq->cmd_flags & REQ_PM))
> > +   rq->q->nr_pending--;
> > +}
> 
> You don't check q->dev here.  That's okay, but it means that
> q->nr_pending will be meaningless or wrong if any I/O takes place
> before blk_pm_runtime_init is called.

Right, so I had better check q->dev here too.

> 
> Therefore the kerneldoc for blk_pm_runtime_init should mention that it
> must not be called after any requests have been submitted.  Also

So with the q->dev check added above, I believe this is not needed.

> mention that blk_pm_runtime_init enables runtime PM for q->dev, so the 
> caller shouldn't do it.

OK, thanks for the suggestion.

-Aaron

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC Patch v1 52/55] ARC: Support for single cycle Close Coupled Mem (CCM)

[Vineet Gupta]

On Monday 12 November 2012 07:40 PM, Arnd Bergmann wrote:
> On Monday 12 November 2012, vineet.gup...@synopsys.com wrote:
>> +config ARC_DCCM_SZ
>> +   int "DCCM Size in KB"
>> +   default "64"
>> +   depends on ARC_HAS_DCCM
>> +
>> +config ARC_DCCM_BASE
>> +   hex "DCCM map address"
>> +   default "0xA000"
>> +   depends on ARC_HAS_DCCM
>> +
> 
> I suppose these should be configured from the device tree at boot time, not
> during the build process.
> 
> I also wonder if the interface should be unified with what we use for
> accessing the sram on some of the ARM platforms.
> 
>   Arnd
> 

Actually in ARC Port these are used in Linker script to layout the kernel
code/data at the addr where these hardware blocks are wired up. So can't be done
at runtime.

-Vineet
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 0/2] Handle Uncompressed IPv6 on 6LoWPAN

[Alan Ott]

This has been tested by exchanging data with with the Contiki operating
system using a Redwire Econotag.  Contiki had to be set to send uncompressed
data, and had to have a #define modified to enable reception and processing
of header-compressed packets when not set to send compressed data.

Version 2 fixes a format issue pointed out by David Miller.

Alan Ott (2):
  6lowpan: Refactor packet delivery into a function
  6lowpan: Handle uncompressed IPv6 packets over 6LoWPAN

 net/ieee802154/6lowpan.c | 79 ++--
 1 file changed, 56 insertions(+), 23 deletions(-)

-- 
1.7.11.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 1/2] 6lowpan: Refactor packet delivery into a function

[Alan Ott]

Refactor the handing of the skb's to the individual lowpan devices into a
function.

Signed-off-by: Alan Ott 
---
 net/ieee802154/6lowpan.c | 38 --
 1 file changed, 24 insertions(+), 14 deletions(-)

diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
index f651da6..1714cfa 100644
--- a/net/ieee802154/6lowpan.c
+++ b/net/ieee802154/6lowpan.c
@@ -594,10 +594,32 @@ static int lowpan_header_create(struct sk_buff *skb,
}
 }
 
+static int lowpan_give_skb_to_devices(struct sk_buff *skb)
+{
+   struct lowpan_dev_record *entry;
+   struct sk_buff *skb_cp;
+   int stat = NET_RX_SUCCESS;
+
+   rcu_read_lock();
+   list_for_each_entry_rcu(entry, _devices, list)
+   if (lowpan_dev_info(entry->ldev)->real_dev == skb->dev) {
+   skb_cp = skb_copy(skb, GFP_ATOMIC);
+   if (!skb_cp) {
+   stat = -ENOMEM;
+   break;
+   }
+
+   skb_cp->dev = entry->ldev;
+   stat = netif_rx(skb_cp);
+   }
+   rcu_read_unlock();
+
+   return stat;
+}
+
 static int lowpan_skb_deliver(struct sk_buff *skb, struct ipv6hdr *hdr)
 {
struct sk_buff *new;
-   struct lowpan_dev_record *entry;
int stat = NET_RX_SUCCESS;
 
new = skb_copy_expand(skb, sizeof(struct ipv6hdr), skb_tailroom(skb),
@@ -614,19 +636,7 @@ static int lowpan_skb_deliver(struct sk_buff *skb, struct 
ipv6hdr *hdr)
new->protocol = htons(ETH_P_IPV6);
new->pkt_type = PACKET_HOST;
 
-   rcu_read_lock();
-   list_for_each_entry_rcu(entry, _devices, list)
-   if (lowpan_dev_info(entry->ldev)->real_dev == new->dev) {
-   skb = skb_copy(new, GFP_ATOMIC);
-   if (!skb) {
-   stat = -ENOMEM;
-   break;
-   }
-
-   skb->dev = entry->ldev;
-   stat = netif_rx(skb);
-   }
-   rcu_read_unlock();
+   stat = lowpan_give_skb_to_devices(new);
 
kfree_skb(new);
 
-- 
1.7.11.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 2/2] 6lowpan: Handle uncompressed IPv6 packets over 6LoWPAN

[Alan Ott]

Handle the reception of uncompressed packets (dispatch type = IPv6).

Signed-off-by: Alan Ott 
---
 net/ieee802154/6lowpan.c | 41 -
 1 file changed, 32 insertions(+), 9 deletions(-)

diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
index 1714cfa..09cba81 100644
--- a/net/ieee802154/6lowpan.c
+++ b/net/ieee802154/6lowpan.c
@@ -1147,19 +1147,42 @@ static int lowpan_rcv(struct sk_buff *skb, struct 
net_device *dev,
goto drop;
 
/* check that it's our buffer */
-   switch (skb->data[0] & 0xe0) {
-   case LOWPAN_DISPATCH_IPHC:  /* ipv6 datagram */
-   case LOWPAN_DISPATCH_FRAG1: /* first fragment header */
-   case LOWPAN_DISPATCH_FRAGN: /* next fragments headers */
-   local_skb = skb_clone(skb, GFP_ATOMIC);
+   if (skb->data[0] == LOWPAN_DISPATCH_IPV6) {
+   /* Copy the packet so that the IPv6 header is
+* properly aligned.
+*/
+   local_skb = skb_copy_expand(skb, NET_SKB_PAD - 1,
+   skb_tailroom(skb), GFP_ATOMIC);
if (!local_skb)
goto drop;
-   lowpan_process_data(local_skb);
 
+   local_skb->protocol = htons(ETH_P_IPV6);
+   local_skb->pkt_type = PACKET_HOST;
+
+   /* Pull off the 1-byte of 6lowpan header. */
+   skb_pull(local_skb, 1);
+   skb_reset_network_header(local_skb);
+   skb_set_transport_header(local_skb, sizeof(struct ipv6hdr));
+
+   lowpan_give_skb_to_devices(local_skb);
+
+   kfree_skb(local_skb);
kfree_skb(skb);
-   break;
-   default:
-   break;
+   } else {
+   switch (skb->data[0] & 0xe0) {
+   case LOWPAN_DISPATCH_IPHC:  /* ipv6 datagram */
+   case LOWPAN_DISPATCH_FRAG1: /* first fragment header */
+   case LOWPAN_DISPATCH_FRAGN: /* next fragments headers */
+   local_skb = skb_clone(skb, GFP_ATOMIC);
+   if (!local_skb)
+   goto drop;
+   lowpan_process_data(local_skb);
+
+   kfree_skb(skb);
+   break;
+   default:
+   break;
+   }
}
 
return NET_RX_SUCCESS;
-- 
1.7.11.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v5 0/5] Add movablecore_map boot option

[Yasuaki Ishimatsu]

2013/01/17 7:52, H. Peter Anvin wrote:

On 01/16/2013 01:29 PM, Andrew Morton wrote:


Yes. If SRAT support is available, all memory which enabled hotpluggable
bit are managed by ZONEMOVABLE. But performance degradation may
occur by NUMA because we can only allocate anonymous page and page-cache
from these memory.

In this case, if user cannot change SRAT information, user needs a way to
select/set removable memory manually.


If I understand this correctly you mean that once SRAT parsing is
implemented, the user can use movablecore_map to override that SRAT
parsing, yes?  That movablecore_map will take precedence over SRAT?



Yes, but we still need a higher-level user interface which specifies
which nodes, not which memory ranges, should be movable.


I thought about the method of specifying the node. But I think
this method is inconvenience. Node number is decided by OS.
So the number is changed easily.

for example:

o exmaple 1
  System has 3 nodes:
  node0, node1, node2

  When user remove node1, the system has:
  node0, node2

  But after rebooting the system, the system has:
  node0, node1

  So node2 becomes node1.

o example 2:
  System has 2 nodes:
  0x4000 - 0x7fff : node0
  0xc000 - 0x : node1

  When user add a node wchih memory range is [0x8000 - 0xbfff],
  system has:
  0x4000 - 0x7fff : node0
  0xc000 - 0x : node1
  0x8000 - 0xbfff : node2

  But after rebooting the system, the system's node may become:
  0x4000 - 0x7fff : node0
  0x8000 - 0xbfff : node1
  0xc000 - 0x : node2

  So node nunber is changed.

Specifying node number may be easy method than specifying memory
range. But if user uses node number for specifying removable memory,
user always need to care whether node number is changed or not at
every hotplug operation.

Thanks,
Yasuaki Ishimatsu



That is the
policy granularity that is actually appropriate for the administrator
(trading off performance vs reliability.)

-hpa




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC Patch v1 48/55] ARC: [plat-arfpga] BVCI Latency Unit setup

[Vineet Gupta]

On Monday 12 November 2012 07:32 PM, Arnd Bergmann wrote:
> On Monday 12 November 2012, vineet.gup...@synopsys.com wrote:
>> +   /* TBD: rewrite this using I/O macros */
>> +   volatile unsigned int *base = (unsigned int *)BVCI_LAT_UNIT_BASE;
>> +   volatile unsigned int *lat_unit = (unsigned int *)base + 21;
>> +   volatile unsigned int *lat_val = (unsigned int *)base + 22;
> 
> Yes, you should do as the comment says.
> 
>   Arnd
> 

Done.

Thx,
-Vineet
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: BUG at net/sunrpc/svc_xprt.c:921

[Stanislav Kinsbursky]

17.01.2013 02:51, Mark Lord пишет:

On 13-01-16 12:20 AM, Stanislav Kinsbursky wrote:


Mark, could you provide any call traces?


Call traces from where/what?
There's this one, posted earlier in the BUG report:

kernel BUG at net/sunrpc/svc_xprt.c:921!
Call Trace:
  [] ? svc_recv+0xcc/0x338 [sunrpc]
  [] ? nfs_callback_authenticate+0x20/0x20 [nfsv4]
  [] ? nfs4_callback_svc+0x1d/0x3c [nfsv4]
  [] ? kthread+0x81/0x89
  [] ? kthread_freezable_should_stop+0x36/0x36
  [] ? ret_from_fork+0x7c/0xb0
  [] ? kthread_freezable_should_stop+0x36/0x36



Thanks!
I haven't seen the bug report.
Could you provide the link, please?

--
Best regards,
Stanislav Kinsbursky
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 2/9] clk: tegra: Add tegra specific clocks

[Hiroshi Doyu]

Stephen Warren  wrote @ Wed, 16 Jan 2013 21:11:24 +0100:

> >> +static int clk_frac_div_set_rate(struct clk_hw *hw, unsigned long rate,
> >> +   unsigned long parent_rate)
> >> +{
> >> +   struct tegra_clk_frac_div *divider = to_clk_frac_div(hw);
> >> +   int div;
> >> +   unsigned long flags = 0;
> > 
> > nit, is "flags" not needed to initialize here?
> 
> It avoids a compiler warning; the compiler doesn't that the if condition
> that guards the path that uses flags is the same condition as the path
> that initializes it. Or, it may be related to the fact that
> spin_lock_irqsave() writes to the value through a pointer parameter, and
> the compiler doesn't know it's an out-only parameter.

It might be better to append the special comment /* GCC */[1] on that line.

[1] https://lwn.net/Articles/529954/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: linux-next: manual merge of the samsung tree with the arm-soc tree

[Kukjin Kim]

Kukjin Kim wrote:
> 
> Stephen Rothwell wrote:
> >
> > Hi Kukjin,
> >
> Hi,
> 
> > On Fri, 11 Jan 2013 15:32:06 +1100 Stephen Rothwell
> 
> > wrote:
> > >
> > > Today's linux-next merge of the samsung tree got conflicts in
> > > many files with the arm-soc tree.
> > >
> > > I just dropped the samsung tree for today.  Please have a look and try
to
> > > fix this mess up, thanks.
> >
> > Ping?
> 
> Oops, I missed above e-mail. Anyway, really?
> 
> Let me look at it soon and I will fix.
> 
> Thanks for your information.
> 
Hmm, updating timer patches in Samsung tree cause the merge conflicts with
arm-soc, so for now I dropped them in my tree just now.
And note that regarding topic branch which are including it will be
re-worked soon :-)

Now to merge Samsung tree for linux-next should be fine.

Thanks again.

- Kukjin

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] ACPI: add support for CSRT table

[Mika Westerberg]

On Thu, Jan 17, 2013 at 12:27:32AM +0100, Rafael J. Wysocki wrote:
> > +static int __init acpi_csrt_init(void)
> > +{
> > +   struct acpi_csrt_group *grp, *end;
> > +   struct acpi_table_csrt *csrt;
> > +   acpi_status status;
> > +   int ret;
> > +
> > +   status = acpi_get_table(ACPI_SIG_CSRT, 0,
> > +   (struct acpi_table_header **));
> > +   if (ACPI_FAILURE(status)) {
> > +   if (status == AE_NOT_FOUND)
> > +   return -ENOENT;
> > +   return -EINVAL;
> > +   }
> > +
> > +   pr_debug("parsing CSRT table for devices\n");
> > +
> > +   grp = (struct acpi_csrt_group *)(csrt + 1);
> > +   end = (struct acpi_csrt_group *)((void *)csrt + csrt->header.length);
> > +
> > +   while (grp < end) {
> > +   ret = acpi_csrt_parse_resource_group(grp);
> > +   if (ret)
> > +   return ret;
> > +
> > +   grp = (struct acpi_csrt_group *)((void *)grp + grp->length);
> > +   }
> > +
> > +   return 0;
> > +}
> > +subsys_initcall(acpi_csrt_init);
> 
> -> Do we really need a separate initcall for that?  And what if ACPI is
> disabled?

Ah, good point - ACPI can be disabled at runtime as well.

> Perhaps it would be better to call acpi_csrt_init() directly from
> acpi_init() (or from acpi_scan_init() whichever is more suitable)?

Indeed. I'll fix this up and send you a new version soon.

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2.4 0/3] mm/fs: Remove unnecessary waiting for stable pages

[Andrew Morton]

On Wed, 16 Jan 2013 18:49:02 -0800 "Darrick J. Wong"  
wrote:

> > 
> > The problem back in 2001 was that we held lock_page() across the
> > duration of page writeback, so if another thread came in and tried to
> > dirty the page, it would block on lock_page() until IO completion.  I
> > can't remember whether writeback would also block read().  Maybe it did,
> > in which case the effects of this patchset won't be as dramatic as were
> > the effects of splitting PG_lock into PG_lock and PG_writeback.
> 
> Now that you've stirred my memory, I /do/ dimly recall that Linux waited for
> writeback back in the old days.  At least we'll be back to that.

Not really.  2.4 did writeback by walking a standalone list of
buffer_heads, without locking their containing page.  I removed all
that and did writeback of the page instead.  That immediately caused
this problem, because the 2.4 writepage held lock_page() across
writeout.  So I changed that to drop lock_page() immediately after
submission and added PG_writeback to flag the under-writeback state. 
The second change went in pretty much immediately - all within the
same 2.5.x release, probably.

> As a side note, the average latency of a write to a non-DIF disk dropped down
> to nearly nothing.

Some hard numbers in the changelog would be nice.  Did you try dbench-on-ext2?

> > 
> > Do we generate nice kernel messages (at mount or device-probe time)
> > which will permit people to work out which strategy their device/fs is
> > using?
> 
> No.  /sys/devices/virtual/bdi/*/stable_pages_required will tell you
> stable pages are on or not, but so far only ext3 uses snapshots and the rest
> just wait.  Do you think a printk would be useful?

Nope, if we can query the mode under /sys then that should be sufficient.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] ARM: tegra: config: enable SERIAL_TEGRA

[Laxman Dewangan]

On Wednesday 16 January 2013 11:27 PM, Stephen Warren wrote:

On 01/16/2013 06:06 AM, Laxman Dewangan wrote:

Enable high speed serial driver for tegra platform.

Thanks, I've applied patch 1 to Tegra's for-3.9/defconfig branch and
patch 2 to Tegra's for-3.9/dt branch.

Just as an FYI, the dt branch is merged into my for-next branch, and
sent upstream, before the defconfig branch, so your patch order was
reversed relative to that, but it's not an issue here.


Thanks for applying it. There is no issue on the reversing the sequence.



Question: How do I test this; do I just fire up bluez(?) and point it at
the UARTC serial port, or is there more to it?


I tested this in may pieces, not with the bluez.
I tested this in downstream with linux-next dma, this new serial driver, 
some hacks in the board files with bluetooth.


Then I tested this again on linux-next with some hacks in board-dt filew 
with invoking  the driver from cardhu dts file. In this I tested driver 
registration, basic write is wokring or not with some register 
dump/interrupt, Not checked data integrity as not connected the serial 
sniffer. The idea is that nothing should be crash in linux-next. The 
basic driver code is already tested with bluetooth.





--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-next: Tree for Jan 17

[Stephen Rothwell]

Hi all,

Changes since 20130116:

Dropped tree: samung (many conflicts)

The powerpc tree still had a build failure.

The tty tree gained conflicts against Linus' and the tty.current trees.

The staging tree gained a conflict against Linus' tree.

The char-misc tree gained a conflict against the tty tree.

The arm-soc tree gained conflicts against the slave-dma tree.

The tegra tree gained conflicts against the arm-soc tree.



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" as mentioned in the FAQ on the wiki
(see below).

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log files
in the Next directory.  Between each merge, the tree was built with
a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the
final fixups (if any), it is also built with powerpc allnoconfig (32 and
64 bit), ppc44x_defconfig and allyesconfig (minus
CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc,
sparc64 and arm defconfig. These builds also have
CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and
CONFIG_DEBUG_INFO disabled when necessary.

Below is a summary of the state of the merge.

We are up to 211 trees (counting Linus' and 28 trees of patches pending
for Linus' tree), more are welcome (even if they are currently empty).
Thanks to those who have contributed, and to those who haven't, please do.

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

There is a wiki covering stuff to do with linux-next at
http://linux.f-seidel.de/linux-next/pmwiki/ .  Thanks to Frank Seidel.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

$ git checkout master
$ git reset --hard stable
Merging origin/master (309b51e Merge tag 'pm+acpi-for-3.8-rc4' of 
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm)
Merging fixes/master (d287b87 Merge branch 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs)
Merging kbuild-current/rc-fixes (02f3e53 Merge branch 'yem-kconfig-rc-fixes' of 
git://gitorious.org/linux-kconfig/linux-kconfig into kbuild/rc-fixes)
Merging arm-current/fixes (d106de3 ARM: 7614/1: mm: fix wrong branch from 
Cortex-A9 to PJ4b)
Merging m68k-current/for-linus (e7e29b4 m68k: Wire up finit_module)
Merging powerpc-merge/merge (e6449c9 powerpc: Add missing NULL terminator to 
avoid boot panic on PPC40x)
Merging sparc/master (b7c13f7 sparc: remove __devinit, __devexit annotations)
Merging net/master (3022551 net: qmi_wwan: add TP-LINK HSUPA Modem MA180)
Merging sound-current/for-linus (6f54c36 ALSA: hda/hdmi - Work around "alsactl 
restore" errors)
Merging pci-current/for-linus (9e16721 PCI: Allow pcie_aspm=force even when 
FADT indicates it is unsupported)
Merging wireless/master (4668cce ath9k: disable the tasklet before taking the 
PCU lock)
Merging driver-core.current/driver-core-linus (f1688e0 debugfs: convert gid= 
argument from decimal, not octal)
Merging tty.current/tty-linus (5dd070d serial:ifx6x60:Keep word size accordance 
with SPI controller)
Merging usb.current/usb-linus (8cf65dc usb: ftdi_sio: Crucible Technologies 
COMET Caller ID - pid added)
Merging staging.current/staging-linus (397c606 staging: zram: fix invalid 
memory references during disk write)
Merging char-misc.current/char-misc-linus (e6028db mei: fix mismatch in mutex 
unlock-lock in mei_amthif_read())
Merging input-current/for-linus (bec7a4b Input: lm8323 - fix checking PWM 
interrupt status)
Merging md-current/for-linus (a9add5d md/raid5: add blktrace calls)
Merging audit-current/for-linus (c158a35 audit: no leading space in 
audit_log_d_path prefix)
Merging crypto-current/master (a2c0911 crypto: caam - Updated SEC-4.0 device 
tree binding for ERA information.)
Merging ide/master (9974e43 ide: fix generic_ide_suspend/resume Oops)
Merging dwmw2/master (084a0ec x86: add CONFIG_X86_MOVBE option)
CONFLICT (content): Merge conflict in arch/x86/Kconfig
Merging sh-current/sh-fixes-for-linus (4403310 SH: Convert out[bwl] macros to 
inline functions)
Merging irqdomain-current/irqdomain/merge (a0d271c Linux 3.6)
Merging devicetree-current/devicetree/merge (ab28698 of: define struct device 
in of_platform.h if !OF_DEVICE and !OF_ADDRESS)
Merging spi-current/spi/merge (d3601e5 spi/sh-hspi: fix return value check in 
hspi_probe

Re: [PATCH 09/19] list_lru: per-node list infrastructure

[Dave Chinner]

On Wed, Jan 16, 2013 at 04:35:43PM -0800, Glauber Costa wrote:
> 
> >> The superblocks only, are present by the dozens even in a small system,
> >> and I believe the whole goal of this API is to get more users to switch
> >> to it. This can easily use up a respectable bunch of megs.
> >>
> >> Isn't it a bit too much ?
> > 
> > Maybe, but for active superblocks it only takes a handful of cached
> > inodes to make this 16k look like noise, so I didn't care. Indeed, a
> > typical active filesystem could be consuming gigabytes of memory in
> > the slab, so 16k is a tiny amount of overhead to track this amount
> > of memory more efficiently.
> > 
> > Most other LRU/shrinkers are tracking large objects and only have a
> > single LRU instance machine wide. Hence the numbers arguments don't
> > play out well in favour of a more complex, dynamic solution for
> > them, either. Sometimes dumb and simple is the best approach ;)
> > 
> 
> Being dumb and simple myself, I'm of course forced to agree.

:)

> Let me give you more context so you can understand my deepest fears better:
> 
> >> I am wondering if we can't do better in here and at least allocate+grow
> >> according to the actual number of nodes.
> > 
> > We could add hotplug notifiers and grow/shrink the node array as
> > they get hot plugged, but that seems unnecessarily complex given
> > how rare such operations are.
> > 
> > If superblock proliferation is the main concern here, then doing
> > somethign as simple as allowing filesystems to specify they want
> > numa aware LRU lists via a mount_bdev() flag would solve this
> > problem. If the flag is set, then full numa lists are created.
> > Otherwise the LRU list simply has a "single node" and collapses all node
> > IDs down to 0 and ignores all NUMA optimisations...
> > 
> > That way the low item count virtual filesystems like proc, sys,
> > hugetlbfs, etc won't use up memory, but filesytems that actually
> > make use of NUMA awareness still get the more expensive, scalable
> > implementation. Indeed, any subsystem that is not performance or
> > location sensitive can use the simple single list version, so we can
> > avoid overhead in that manner system wide...
> > 
> 
> Deepest fears:
> 
> 1) snakes.

Snakes are merely poisonous. Drop Bears are far more dangerous :P

> 2) It won't surprise you to know that I am adapting your work, which
> provides a very sane and helpful API, to memcg shrinking.
> 
> The dumb and simple approach in there is to copy all lrus that are
> marked memcg aware at memcg creation time. The API is kept the same,
> but when you do something like list_lru_add(lru, obj), for instance, we
> derive the memcg context from obj and relay it to the right list.

At which point, you don't want the overhead of per-node lists.

The problem I see here is that someone might still need the
scalability of the per-node lists. If someone runs a large memcg in terms
of CPU and memory, then we most definitely are going to need to
retain per-node lists regardless of the fact that the workload is
running in a constrained environment. And if you are running a mix
of large and small containers, then one static solution is not going
to cut it for some workload.

This is a problem that superblock contexts don't care about - they
are global by their very nature. Hence I'm wondering if trying to
fit these two very different behaviours into the one LRU list is
the wrong approach.

Consider this: these patches give us a generic LRU list structure.
It currently uses a list_head in each object for indexing, and we
are talking about single LRU lists because of this limitation and
trying to build infrastructure that can support this indexing
mechanism.

I think that all of thses problems go away if we replace the
list_head index in the object with a "struct lru_item" index. To
start with, it's just a s/list_head/lru_item/ changeover, but from
there we can expand.

What I'm getting at is that we want to have multiple axis of
tracking and reclaim, but we only have a single axis for tracking.
If the lru_item grew a second list_head called "memcg_lru", then
suddenly the memcg LRUs can be maintained separately to the global
(per-superblock) LRU. i.e.:

struct lru_item {
struct list_head global_list;
struct list_head memcg_list;
}

And then you can use whatever tracking structure you want for a
memcg LRU list. Indeed, this would allow per-node lists for the
global LRU, and whatever LRU type is appropriate for the memcg using
the object (e.g. single list for small memcgs, per-node for large
memcgs)

i.e. rather than trying to make the infrastructure jump through hoops
to only have one LRU index per object, have a second index that
allows memcg's to have a separate LRU index and a method for the
global LRU structure to find them. This woul dallow memcg specific
shrinker callouts switch to the memcg LRU rather than the global LRU
and operate on that. That way we still only instantiate a single

Re: 3.8-rc2 lockdep complains about console_lock vs. fb_notifier_list.rwsem

[Greg Kroah-Hartman]

On Wed, Jan 16, 2013 at 07:54:16PM -0800, Andrew Morton wrote:
> On Wed, 16 Jan 2013 18:42:46 -0800 Greg Kroah-Hartman 
>  wrote:
> 
> > > FWIW, Andrew took my patch in mm:
> > >   
> > > http://ozlabs.org/~akpm/mmots/broken-out/fb-rework-locking-to-fix-lock-ordering-on-takeover.patch
> > >   
> > > http://ozlabs.org/~akpm/mmots/broken-out/fb-yet-another-band-aid-for-fixing-lockdep-mess.patch
> > 
> > 
> > Ok, so, which one should I take for 3.8?  And ideally the fb maintainer
> > should do this, not I, right?
> 
> Please see http://www.spinics.net/lists/linux-fbdev/msg08954.html
> 
> Tomi might be able to review the above for us.  I think we need both. 
> If nothing else happens I intend to send both Linuswards for 3.8 in a
> week or two.

Ok, that sounds fine with me, thanks for doing that.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: linux-next: manual merge of the samsung tree with the arm-soc tree

[Kukjin Kim]

Stephen Rothwell wrote:
> 
> Hi Kukjin,
> 
Hi,

> On Fri, 11 Jan 2013 15:32:06 +1100 Stephen Rothwell 
> wrote:
> >
> > Today's linux-next merge of the samsung tree got conflicts in
> > many files with the arm-soc tree.
> >
> > I just dropped the samsung tree for today.  Please have a look and try
to
> > fix this mess up, thanks.
> 
> Ping?

Oops, I missed above e-mail. Anyway, really?

Let me look at it soon and I will fix.

Thanks for your information.

- Kukjin

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: linux-next: manual merge of the samsung tree with the arm-soc tree

[Kukjin Kim]

Stephen Rothwell wrote:
> 
> Hi Kukjin,
> 
Hi,

> On Fri, 11 Jan 2013 15:32:06 +1100 Stephen Rothwell 
> wrote:
> >
> > Today's linux-next merge of the samsung tree got conflicts in
> > many files with the arm-soc tree.
> >
> > I just dropped the samsung tree for today.  Please have a look and try
to
> > fix this mess up, thanks.
> 
> Ping?
> 
Oops, I missed above e-mail. Anyway, really?

Let me look at soon and I will fix.

Thanks for your information.

- Kukjin

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] cifs: fix srcip_matches() for ipv6

[Nickolai Zeldovich]

On Wed, Jan 16, 2013 at 10:51 PM, Steve French  wrote:
> How did you discover this - did you have an ipv6 test case or by
> inspection or ...?

By mostly-automated inspection (i.e., with the help of a static
program analysis tool).

Nickolai.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCHSET] workqueue: remove gcwq and make worker_pool the only backend abstraction

[Wanlong Gao]

On 01/17/2013 09:42 AM, Tejun Heo wrote:
> Hello,
> 
> Currently, on the backend side, there are two layers of abstraction.
> For each CPU and the special unbound wq-specific CPU, there's one
> global_cwq.  gcwq in turn hosts two worker_pools - one for normal
> priority, the other for highpri - each of which actually serves the
> work items.
> 
> worker_pool is the later addition to support separate pool of workers
> for highpri workqueues.  Stuff was moved to worker_pool on as-needed
> basis and, as a result, the two pools belonging to the same CPU share
> some stuff in the gcwq - most notably the lock and the hash table for
> work items currently being executed.
> 
> It seems like we'll need to support worker pools with custom
> attributes, which is planned to be implemented as extra worker_pools
> for the unbound CPU.  Removing gcwq and having worker_pool as the top
> level abstraction makes things much simpler for such designs.  Also,
> there's scalability benefit to not sharing locking and busy hash among
> different worker pools as worker pools w/ custom attributes are likely
> to have widely different memory / cpu locality characteristics.
> 
> In retrospect, it might have been less churn if we just converted to
> have multiple gcwqs per CPU when we were adding highpri pool support.
> Oh well, such is life and the name worker_pool fits the role much
> better anyway at this point.
> 
> This patchset moves the remaining stuff in gcwq to worker_pool and
> then removes gcwq entirely making worker_pool the top level and the
> only backend abstraction.  In the process, this patchset also prepares
> for later addition of worker_pools with custom attributes.
> 
> This patchset shouldn't introduce any visible differences outside of
> workqueue proper and contains the following 17 patches.
> 
>  0001-workqueue-unexport-work_cpu.patch
>  0002-workqueue-use-std_-prefix-for-the-standard-per-cpu-p.patch
>  0003-workqueue-make-GCWQ_DISASSOCIATED-a-pool-flag.patch
>  0004-workqueue-make-GCWQ_FREEZING-a-pool-flag.patch
>  0005-workqueue-introduce-WORK_OFFQ_CPU_NONE.patch
>  0006-workqueue-add-worker_pool-id.patch
>  0007-workqueue-record-pool-ID-instead-of-CPU-in-work-data.patch
>  0008-workqueue-move-busy_hash-from-global_cwq-to-worker_p.patch
>  0009-workqueue-move-global_cwq-cpu-to-worker_pool.patch
>  0010-workqueue-move-global_cwq-lock-to-worker_pool.patch
>  0011-workqueue-make-hotplug-processing-per-pool.patch
>  0012-workqueue-make-freezing-thawing-per-pool.patch
>  0013-workqueue-replace-for_each_worker_pool-with-for_each.patch
>  0014-workqueue-remove-worker_pool-gcwq.patch
>  0015-workqueue-remove-global_cwq.patch
>  0016-workqueue-rename-nr_running-variables.patch
>  0017-workqueue-post-global_cwq-removal-cleanups.patch
> 
> 0001-0002 are misc preps.
> 
> 0003-0004 move flags from gcwq to pool.
> 
> 0005-0007 make work->data off-queue backlink point to worker_pools
> instead of CPUs, which is necessary to move busy_hash to pool.
> 
> 0008-0010 move busy_hash, cpu and locking to pool.
> 
> 0011-0014 make operations per-pool and remove gcwq usages.
> 
> 0015-0017 remove gcwq and cleanup afterwards.
> 
> This patchset is on top of wq/for-3.9 023f27d3d6f ("workqueue: fix
> find_worker_executing_work() brekage from hashtable conversion") and
> available in the following git branch.
> 
>  git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq.git for-3.9-remove-gcwq

Forgot to push out this branch?

Thanks,
Wanlong Gao

> 
> Thanks.
> 
>  include/linux/workqueue.h|   17
>  include/trace/events/workqueue.h |2
>  kernel/workqueue.c   |  897 
> +++
>  3 files changed, 461 insertions(+), 455 deletions(-)
> 
> --
> tejun
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: manual merge of the samsung tree with the arm-soc tree

[Stephen Rothwell]

Hi Kukjin,

On Fri, 11 Jan 2013 15:32:06 +1100 Stephen Rothwell  
wrote:
>
> Today's linux-next merge of the samsung tree got conflicts in
> many files with the arm-soc tree.
> 
> I just dropped the samsung tree for today.  Please have a look and try to
> fix this mess up, thanks.

Ping?

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpvx70DbKAyc.pgp
Description: PGP signature

Re: [PATCH] cifs: fix srcip_matches() for ipv6

[Steve French]

Makes sense.

How did you discover this - did you have an ipv6 test case or by
inspection or ...?

On Wed, Jan 16, 2013 at 8:36 PM, Nickolai Zeldovich
 wrote:
> srcip_matches() previously had code like this:
>
>   srcip_matches(..., struct sockaddr *rhs) {
> /* ... */
> struct sockaddr_in6 *vaddr6 = (struct sockaddr_in6 *) 
> return ipv6_addr_equal(..., >sin6_addr);
>   }
>
> which interpreted the values on the stack after the 'rhs' pointer as an
> ipv6 address.  The correct thing to do is to use 'rhs', not ''.
>
> Signed-off-by: Nickolai Zeldovich 
> ---
>  fs/cifs/connect.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/cifs/connect.c b/fs/cifs/connect.c
> index 17c3643..12b3da3 100644
> --- a/fs/cifs/connect.c
> +++ b/fs/cifs/connect.c
> @@ -1917,7 +1917,7 @@ srcip_matches(struct sockaddr *srcaddr, struct sockaddr 
> *rhs)
> }
> case AF_INET6: {
> struct sockaddr_in6 *saddr6 = (struct sockaddr_in6 *)srcaddr;
> -   struct sockaddr_in6 *vaddr6 = (struct sockaddr_in6 *)
> +   struct sockaddr_in6 *vaddr6 = (struct sockaddr_in6 *)rhs;
> return ipv6_addr_equal(>sin6_addr, 
> >sin6_addr);
> }
> default:
> --
> 1.7.10.4
>



-- 
Thanks,

Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 3.8-rc2 lockdep complains about console_lock vs. fb_notifier_list.rwsem

[Andrew Morton]

On Wed, 16 Jan 2013 18:42:46 -0800 Greg Kroah-Hartman 
 wrote:

> > FWIW, Andrew took my patch in mm:
> >   
> > http://ozlabs.org/~akpm/mmots/broken-out/fb-rework-locking-to-fix-lock-ordering-on-takeover.patch
> >   
> > http://ozlabs.org/~akpm/mmots/broken-out/fb-yet-another-band-aid-for-fixing-lockdep-mess.patch
> 
> 
> Ok, so, which one should I take for 3.8?  And ideally the fb maintainer
> should do this, not I, right?

Please see http://www.spinics.net/lists/linux-fbdev/msg08954.html

Tomi might be able to review the above for us.  I think we need both. 
If nothing else happens I intend to send both Linuswards for 3.8 in a
week or two.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Redefinition of struct in6_addr in and

[Cong Wang]

On Wed, 2013-01-16 at 14:22 -0500, Mike Frysinger wrote:
> 
> but this is still too vague.  what headers/definitions do people want to see 
> simultaneously included ?  changes would be needed on both sides (kernel & C 
> library).
> 

Hi, Mike,

Please take a look at my first email in this thread. The user
application includes  and .

 uses struct_in6 but doesn't include 
(this is my bad, sorry), an obvious fix is just including .
But this immediately breaks applications which include
 and , just as what Thomas reported.

And if_bridge.h is kernel-specific, there is no corresponding glibc one,
so you can't blame applications which include both of them.

Thanks.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4/6] block: Optionally snapshot page contents to provide stable pages during write

[Martin K. Petersen]

> "Darrick" == Darrick J Wong  writes:

>> Umm, why did you move this hunk?

Darrick> I moved it so that the integrity data are generated against the
Darrick> contents of the bounce buffer because the write paths don't
Darrick> wait for writeback to finish if the snapshotting mode is
Darrick> enabled, which means (I think) that programs can wander in and
Darrick> scribble on the original page in between bio_integrity_prep and
Darrick> blk_queue_bounce.

It's also important that bio_integrity_prep() is run after partition
remapping has taken place. But it looks like that's still the case after
your change.

-- 
Martin K. Petersen  Oracle Linux Engineering
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Redefinition of struct in6_addr in and

[YOSHIFUJI Hideaki]

Carlos O'Donell wrote:
> diff --git a/include/uapi/linux/in6.h b/include/uapi/linux/in6.h
> index f79c372..a2b16a5 100644
> --- a/include/uapi/linux/in6.h
> +++ b/include/uapi/linux/in6.h
> @@ -23,6 +23,13 @@
>  
>  #include 
>  
> +/* If a glibc-based userspace has already included in.h, then we will not 
> + * define in6_addr (nor the defines), sockaddr_in6, or ipv6_mreq. The
> + * ABI used by the kernel and by glibc match exactly. Neither the kernel
> + * nor glibc should break this ABI without coordination.
> + */
> +#ifndef _NETINET_IN_H
> +
>  /*
>   *   IPv6 address structure
>   */

This should be
#if !defined(__GLIBC__) || !defined(_NETINET_IN_H)

> @@ -30,12 +37,20 @@
>  struct in6_addr {
>   union {
>   __u8u6_addr8[16];
> +#if !defined(__GLIBC__) \
> +|| (defined(__GLIBC__) && (defined(__USE_MISC) || defined(__USE_GNU))) \
> +|| defined(__KERNEL__)
>   __be16  u6_addr16[8];
>   __be32  u6_addr32[4];
> +#endif
>   } in6_u;
> +#if !defined(__GLIBC__) \
> +|| (defined(__GLIBC__) && (defined(__USE_MISC) || defined(__USE_GNU))) \
> +|| defined(__KERNEL__)
>  #define s6_addr  in6_u.u6_addr8
>  #define s6_addr16in6_u.u6_addr16
>  #define s6_addr32in6_u.u6_addr32
> +#endif
>  };

2nd "if" be after s6_addr?

--yoshfuji
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] drm/radeon: fix NULL pointer dereference in UMS mode in radeon_cs_parser_fini()

[Ilija Hadzic]

Actually, the code path affected by your patch is not executed in UMS mode 
at all. Notice that radeon_cs_parser_fini is only called from 
radeon_cs_ioctl which is a KMS-only ioctl (see radeon_kms.c).


The equivalent of the fix you are trying to do is in
a6b7e1a02b77ab8fe8775d20a88c53d8ba55482e (function patched by that one is 
the one used by legacy-CS ioctl), which you should go together 
with ff4bd0827764e10a428a9d39e6814c5478863f94 if you are backporting UMS 
fixes to 3.7. Both are needed to prevent kernel crashes in UMS mode.


-- Ilija

On Wed, 16 Jan 2013, Shuah Khan wrote:


Fix parser->rdev NULL pointer dereference in radeon_cs_parser_fini().
While back-porting drm/radeon: fix NULL pointer dereference in UMS mode
patch (commit-id: ff4bd0827764e10a428a9d39e6814c5478863f94) to 3,7.y, noticed
another instance of NULL pointer dereference in radeon_cs_parser_fini()
function.

Signed-off-by: Shuah Khan 
CC: sta...@vger.kernel.org 3.7
---
drivers/gpu/drm/radeon/radeon_cs.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/radeon_cs.c 
b/drivers/gpu/drm/radeon/radeon_cs.c
index 469661f..d1c282c 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -329,7 +329,7 @@ static void radeon_cs_parser_fini(struct radeon_cs_parser 
*parser, int error)
kfree(parser->relocs_ptr);
for (i = 0; i < parser->nchunks; i++) {
kfree(parser->chunks[i].kdata);
-   if ((parser->rdev->flags & RADEON_IS_AGP)) {
+   if (parser->rdev && (parser->rdev->flags & RADEON_IS_AGP)) {
kfree(parser->chunks[i].kpage[0]);
kfree(parser->chunks[i].kpage[1]);
}
--
1.7.9.5



___
dri-devel mailing list
dri-de...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 05/86] drivers/net/ethernet/seeq: remove depends on CONFIG_EXPERIMENTAL

[Kees Cook]

The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.

Cc: "David S. Miller" 
Cc: Greg Kroah-Hartman 
Signed-off-by: Kees Cook 
---
 drivers/net/ethernet/seeq/Kconfig |4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/seeq/Kconfig 
b/drivers/net/ethernet/seeq/Kconfig
index 29f1853..2366fa0 100644
--- a/drivers/net/ethernet/seeq/Kconfig
+++ b/drivers/net/ethernet/seeq/Kconfig
@@ -6,7 +6,6 @@ config NET_VENDOR_SEEQ
bool "SEEQ devices"
default y
depends on HAS_IOMEM
-   depends on (ARM && ARCH_ACORN) || SGI_HAS_SEEQ || EXPERIMENTAL
---help---
  If you have a network (Ethernet) card belonging to this class, say Y
  and read the Ethernet-HOWTO, available from
@@ -27,8 +26,7 @@ config ARM_ETHER3
  should say Y to this option if you wish to use it with Linux.
 
 config SEEQ8005
-   tristate "SEEQ8005 support (EXPERIMENTAL)"
-   depends on EXPERIMENTAL
+   tristate "SEEQ8005 support"
---help---
  This is a driver for the SEEQ 8005 network (Ethernet) card.  If this
  is for you, read the Ethernet-HOWTO, available from
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 03/86] drivers/net/ethernet/microchip: remove depends on CONFIG_EXPERIMENTAL

[Kees Cook]

The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.

Cc: "David S. Miller" 
Cc: Greg Kroah-Hartman 
Signed-off-by: Kees Cook 
---
 drivers/net/ethernet/microchip/Kconfig |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/microchip/Kconfig 
b/drivers/net/ethernet/microchip/Kconfig
index 8163fd0..afaf0c0 100644
--- a/drivers/net/ethernet/microchip/Kconfig
+++ b/drivers/net/ethernet/microchip/Kconfig
@@ -5,7 +5,7 @@
 config NET_VENDOR_MICROCHIP
bool "Microchip devices"
default y
-   depends on SPI && EXPERIMENTAL
+   depends on SPI
---help---
  If you have a network (Ethernet) card belonging to this class, say Y
  and read the Ethernet-HOWTO, available from
@@ -20,7 +20,7 @@ if NET_VENDOR_MICROCHIP
 
 config ENC28J60
tristate "ENC28J60 support"
-   depends on SPI && EXPERIMENTAL
+   depends on SPI
select CRC32
---help---
  Support for the Microchip EN28J60 ethernet chip.
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 10/86] drivers/net/ppp: remove depends on CONFIG_EXPERIMENTAL

[Kees Cook]

The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.

Cc: "David S. Miller" 
Cc: Greg Kroah-Hartman 
Signed-off-by: Kees Cook 
---
 drivers/net/ppp/Kconfig |   20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/net/ppp/Kconfig b/drivers/net/ppp/Kconfig
index 872df3e..278dea0 100644
--- a/drivers/net/ppp/Kconfig
+++ b/drivers/net/ppp/Kconfig
@@ -82,8 +82,8 @@ config PPP_FILTER
  If unsure, say N.
 
 config PPP_MPPE
-   tristate "PPP MPPE compression (encryption) (EXPERIMENTAL)"
-   depends on PPP && EXPERIMENTAL
+   tristate "PPP MPPE compression (encryption)"
+   depends on PPP
select CRYPTO
select CRYPTO_SHA1
select CRYPTO_ARC4
@@ -96,8 +96,8 @@ config PPP_MPPE
  configuring PPTP clients and servers to utilize this method.
 
 config PPP_MULTILINK
-   bool "PPP multilink support (EXPERIMENTAL)"
-   depends on PPP && EXPERIMENTAL
+   bool "PPP multilink support"
+   depends on PPP
---help---
  PPP multilink is a protocol (defined in RFC 1990) which allows you
  to combine several (logical or physical) lines into one logical PPP
@@ -118,8 +118,8 @@ config PPPOATM
  changes its encapsulation unilaterally.
 
 config PPPOE
-   tristate "PPP over Ethernet (EXPERIMENTAL)"
-   depends on EXPERIMENTAL && PPP
+   tristate "PPP over Ethernet"
+   depends on PPP
---help---
  Support for PPP over Ethernet.
 
@@ -130,8 +130,8 @@ config PPPOE
  the heading "Kernel mode PPPoE").
 
 config PPTP
-   tristate "PPP over IPv4 (PPTP) (EXPERIMENTAL)"
-   depends on EXPERIMENTAL && PPP && NET_IPGRE_DEMUX
+   tristate "PPP over IPv4 (PPTP)"
+   depends on PPP && NET_IPGRE_DEMUX
---help---
  Support for PPP over IPv4.(Point-to-Point Tunneling Protocol)
 
@@ -141,8 +141,8 @@ config PPTP
  utilize this module.
 
 config PPPOL2TP
-   tristate "PPP over L2TP (EXPERIMENTAL)"
-   depends on EXPERIMENTAL && L2TP && PPP
+   tristate "PPP over L2TP"
+   depends on L2TP && PPP
---help---
  Support for PPP-over-L2TP socket family. L2TP is a protocol
  used by ISPs and enterprises to tunnel PPP traffic over UDP
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 21/86] Documentation/networking: remove depends on CONFIG_EXPERIMENTAL

[Kees Cook]

The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.

CC: Rob Landley 
Cc: "David S. Miller" 
Cc: Greg Kroah-Hartman 
Signed-off-by: Kees Cook 
---
 Documentation/networking/cs89x0.txt |8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/Documentation/networking/cs89x0.txt 
b/Documentation/networking/cs89x0.txt
index c725d33..cc91a15 100644
--- a/Documentation/networking/cs89x0.txt
+++ b/Documentation/networking/cs89x0.txt
@@ -386,15 +386,13 @@ tristate 'CS89x0 support' CONFIG_CS89x0
 
 Example:
 
- if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then
-   tristate 'ICL EtherTeam 16i/32 support' CONFIG_ETH16I
- fi
+ tristate 'ICL EtherTeam 16i/32 support' CONFIG_ETH16I
 
  tristate 'CS89x0 support' CONFIG_CS89x0
 
  tristate 'NE2000/NE1000 support' CONFIG_NE2000
- if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then
-   tristate 'NI5210 support' CONFIG_NI52
+
+ tristate 'NI5210 support' CONFIG_NI52
 
 
 b.) In /usr/src/linux/drivers/net/Makefile, add the following lines: 
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/2] Staging: usbip: usbipcommon: Fixed single line bracing issue

[Jake Champlin]

Fixed coding style issue with single line braces.

Signed-off-by: Jake Champlin 
---
 drivers/staging/usbip/usbip_common.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/staging/usbip/usbip_common.c 
b/drivers/staging/usbip/usbip_common.c
index 75189fe..75aa5bf 100644
--- a/drivers/staging/usbip/usbip_common.c
+++ b/drivers/staging/usbip/usbip_common.c
@@ -672,9 +672,8 @@ int usbip_recv_iso(struct usbip_device *ud, struct urb *urb)
return 0;
 
/* my Bluetooth dongle gets ISO URBs which are np = 0 */
-   if (np == 0) {
+   if (np == 0)
return 0;
-   }
 
buff = kzalloc(size, GFP_KERNEL);
if (!buff)
-- 
1.8.1.1


-- 
Jake Champlin
jake.champlin...@gmail.com
8123742937

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Redefinition of struct in6_addr in and

[David Miller]

From: Carlos O'Donell 
Date: Wed, 16 Jan 2013 21:15:03 -0500

> +/* If a glibc-based userspace has already included in.h, then we will not 
> + * define in6_addr (nor the defines), sockaddr_in6, or ipv6_mreq. The
> + * ABI used by the kernel and by glibc match exactly. Neither the kernel
> + * nor glibc should break this ABI without coordination.
> + */
> +#ifndef _NETINET_IN_H
> +

I think we should shoot for a non-glibc-centric solution.

I can't imagine that other libc's won't have the same exact problem
with their netinet/in.h conflicting with the kernel's, redefining
structures like in6_addr, that we'd want to provide a protection
scheme for here as well.

Let's pick some more generic names and themes for the CPP macros and
comments we use to protect the header file blocks and describe that
protection scheme.

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 06/86] drivers/net/ethernet/stmicro/stmmac: remove depends on CONFIG_EXPERIMENTAL

[Kees Cook]

The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.

CC: Giuseppe Cavallaro 
Cc: Greg Kroah-Hartman 
Signed-off-by: Kees Cook 
---
 drivers/net/ethernet/stmicro/stmmac/Kconfig |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/Kconfig 
b/drivers/net/ethernet/stmicro/stmmac/Kconfig
index 1164930..c0ea838 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Kconfig
+++ b/drivers/net/ethernet/stmicro/stmmac/Kconfig
@@ -26,8 +26,8 @@ config STMMAC_PLATFORM
  If unsure, say N.
 
 config STMMAC_PCI
-   bool "STMMAC PCI bus support (EXPERIMENTAL)"
-   depends on STMMAC_ETH && PCI && EXPERIMENTAL
+   bool "STMMAC PCI bus support"
+   depends on STMMAC_ETH && PCI
---help---
  This is to select the Synopsys DWMAC available on PCI devices,
  if you have a controller with this interface, say Y or M here.
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 07/86] drivers/net/ethernet/sun: remove depends on CONFIG_EXPERIMENTAL

[Kees Cook]

The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.

Cc: "David S. Miller" 
Cc: Greg Kroah-Hartman 
Signed-off-by: Kees Cook 
---
 drivers/net/ethernet/sun/Kconfig |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/sun/Kconfig b/drivers/net/ethernet/sun/Kconfig
index 57bfd85..ae3a355 100644
--- a/drivers/net/ethernet/sun/Kconfig
+++ b/drivers/net/ethernet/sun/Kconfig
@@ -32,8 +32,8 @@ config HAPPYMEAL
  will be called sunhme.
 
 config SUNBMAC
-   tristate "Sun BigMAC 10/100baseT support (EXPERIMENTAL)"
-   depends on SBUS && EXPERIMENTAL
+   tristate "Sun BigMAC 10/100baseT support"
+   depends on SBUS
select CRC32
---help---
  This driver supports the "be" interface available as an Sbus option.
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 40/86] drivers/gpio: remove depends on CONFIG_EXPERIMENTAL

[Kees Cook]

The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.

CC: Grant Likely 
Cc: Greg Kroah-Hartman 
Signed-off-by: Kees Cook 
---
 drivers/gpio/Kconfig |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 682de75..4c54586 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -66,7 +66,7 @@ config DEBUG_GPIO
 
 config GPIO_SYSFS
bool "/sys/class/gpio/... (sysfs interface)"
-   depends on SYSFS && EXPERIMENTAL
+   depends on SYSFS
help
  Say Y here to add a sysfs interface for GPIOs.
 
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 02/86] drivers/net/ethernet/icplus: remove depends on CONFIG_EXPERIMENTAL

[Kees Cook]

The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.

Cc: "David S. Miller" 
Cc: Greg Kroah-Hartman 
Signed-off-by: Kees Cook 
---
 drivers/net/ethernet/icplus/Kconfig |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/icplus/Kconfig 
b/drivers/net/ethernet/icplus/Kconfig
index 3aff81d..5119ef1 100644
--- a/drivers/net/ethernet/icplus/Kconfig
+++ b/drivers/net/ethernet/icplus/Kconfig
@@ -4,7 +4,7 @@
 
 config IP1000
tristate "IP1000 Gigabit Ethernet support"
-   depends on PCI && EXPERIMENTAL
+   depends on PCI
select NET_CORE
select MII
---help---
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-next: manual merge of the char-misc tree with the tty tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the char-misc tree got a conflict in
drivers/ipack/devices/ipoctal.c between commit 2e124b4a390c ("TTY: switch
tty_flip_buffer_push") from the tty tree and commits 7e5730d7c222
("ipack/devices/ipoctal: fix kernel bug when using pppd"),
e7e664fd688a ("ipack/devices/ipoctal: protect the channel data processing
with a spinlock") and b06073f963b7 ("ipack/devices/ipoctal: remove
redundant tty_flip_buffer_push()") from the char-misc tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc drivers/ipack/devices/ipoctal.c
index ab20a08,0b3c4b8..000
--- a/drivers/ipack/devices/ipoctal.c
+++ b/drivers/ipack/devices/ipoctal.c
@@@ -133,11 -123,11 +123,11 @@@ static int ipoctal_get_icount(struct tt
return 0;
  }
  
 -static void ipoctal_irq_rx(struct ipoctal_channel *channel,
 - struct tty_struct *tty, u8 sr)
 +static void ipoctal_irq_rx(struct ipoctal_channel *channel, u8 sr)
  {
 +  struct tty_port *port = >tty_port;
unsigned char value;
-   unsigned char flag = TTY_NORMAL;
+   unsigned char flag;
u8 isr;
  
do {
@@@ -208,11 -188,13 +188,8 @@@ static void ipoctal_irq_tx(struct ipoct
  static void ipoctal_irq_channel(struct ipoctal_channel *channel)
  {
u8 isr, sr;
 -  struct tty_struct *tty;
 -
 -  tty = tty_port_tty_get(>tty_port);
 -  if (!tty)
 -  return;
  
-   /* If there is no client, skip the check */
-   if (!atomic_read(>open))
-   return;
- 
+   spin_lock(>lock);
/* The HW is organized in pair of channels.  See which register we need
 * to read from */
isr = ioread8(>block_regs->r.isr);
@@@ -237,7 -218,8 +213,7 @@@
if ((isr & channel->isr_tx_rdy_mask) && (sr & SR_TX_READY))
ipoctal_irq_tx(channel);
  
-   tty_flip_buffer_push(>tty_port);
 -  tty_kref_put(tty);
+   spin_unlock(>lock);
  }
  
  static irqreturn_t ipoctal_irq_handler(void *arg)


pgpZLu3bGWTSg.pgp
Description: PGP signature

[PATCH 26/86] arch/mips/jazz: remove depends on CONFIG_EXPERIMENTAL

[Kees Cook]

The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.

CC: Ralf Baechle 
Cc: Greg Kroah-Hartman 
Signed-off-by: Kees Cook 
---
 arch/mips/jazz/Kconfig |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/mips/jazz/Kconfig b/arch/mips/jazz/Kconfig
index 1f372b0..fb1e072 100644
--- a/arch/mips/jazz/Kconfig
+++ b/arch/mips/jazz/Kconfig
@@ -1,6 +1,6 @@
 config ACER_PICA_61
-   bool "Support for Acer PICA 1 chipset (EXPERIMENTAL)"
-   depends on MACH_JAZZ && EXPERIMENTAL
+   bool "Support for Acer PICA 1 chipset"
+   depends on MACH_JAZZ
select DMA_NONCOHERENT
select SYS_SUPPORTS_LITTLE_ENDIAN
help
@@ -13,7 +13,7 @@ config MIPS_MAGNUM_4000
bool "Support for MIPS Magnum 4000"
depends on MACH_JAZZ
select DMA_NONCOHERENT
-   select SYS_SUPPORTS_BIG_ENDIAN if EXPERIMENTAL
+   select SYS_SUPPORTS_BIG_ENDIAN
select SYS_SUPPORTS_LITTLE_ENDIAN
help
  This is a machine with a R4000 100 MHz CPU. To compile a Linux
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 25/86] arch/microblaze/platform: remove depends on CONFIG_EXPERIMENTAL

[Kees Cook]

The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.

CC: Michal Simek 
Cc: Greg Kroah-Hartman 
Signed-off-by: Kees Cook 
---
 arch/microblaze/platform/Kconfig.platform |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/microblaze/platform/Kconfig.platform 
b/arch/microblaze/platform/Kconfig.platform
index 669c7ee..b174721 100644
--- a/arch/microblaze/platform/Kconfig.platform
+++ b/arch/microblaze/platform/Kconfig.platform
@@ -20,7 +20,7 @@ endchoice
 
 config SELFMOD
bool "Use self modified code for intc/timer"
-   depends on EXPERIMENTAL && NO_MMU
+   depends on NO_MMU
default n
help
  This choice enables self-modified code for interrupt controller
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 38/86] drivers/block/paride: remove depends on CONFIG_EXPERIMENTAL

[Kees Cook]

The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.

CC: Tim Waugh 
Cc: Greg Kroah-Hartman 
Signed-off-by: Kees Cook 
---
 drivers/block/paride/Kconfig |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/block/paride/Kconfig b/drivers/block/paride/Kconfig
index 28cf308..efefb5a 100644
--- a/drivers/block/paride/Kconfig
+++ b/drivers/block/paride/Kconfig
@@ -205,8 +205,8 @@ config PARIDE_EPAT
  support.
 
 config PARIDE_EPATC8
-   bool "Support c7/c8 chips (EXPERIMENTAL)"
-   depends on PARIDE_EPAT && EXPERIMENTAL
+   bool "Support c7/c8 chips"
+   depends on PARIDE_EPAT
help
  This option enables support for the newer Shuttle EP1284 (aka c7 and
  c8) chip. You need this if you are using any recent Imation SuperDisk
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 43/86] drivers/gpu/drm/gma500: remove depends on CONFIG_EXPERIMENTAL

[Kees Cook]

The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.

CC: Dave Airlie 
CC: Alan Cox 
CC: "Kirill A. Shutemov" 
Cc: Greg Kroah-Hartman 
Signed-off-by: Kees Cook 
---
 drivers/gpu/drm/gma500/Kconfig |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/gma500/Kconfig b/drivers/gpu/drm/gma500/Kconfig
index 42e665c..1188f0f 100644
--- a/drivers/gpu/drm/gma500/Kconfig
+++ b/drivers/gpu/drm/gma500/Kconfig
@@ -1,6 +1,6 @@
 config DRM_GMA500
tristate "Intel GMA5/600 KMS Framebuffer"
-   depends on DRM && PCI && X86 && EXPERIMENTAL
+   depends on DRM && PCI && X86
select FB_CFB_COPYAREA
 select FB_CFB_FILLRECT
 select FB_CFB_IMAGEBLIT
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 45/86] drivers/i2c: remove depends on CONFIG_EXPERIMENTAL

[Kees Cook]

The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.

CC: Ralf Baechle 
CC: Manuel Lauss 
Cc: Greg Kroah-Hartman 
Signed-off-by: Kees Cook 
---
 drivers/i2c/Kconfig|2 +-
 drivers/i2c/busses/Kconfig |   16 +++-
 2 files changed, 8 insertions(+), 10 deletions(-)

diff --git a/drivers/i2c/Kconfig b/drivers/i2c/Kconfig
index 2f8c76b..46cde09 100644
--- a/drivers/i2c/Kconfig
+++ b/drivers/i2c/Kconfig
@@ -89,7 +89,7 @@ source drivers/i2c/busses/Kconfig
 
 config I2C_STUB
tristate "I2C/SMBus Test Stub"
-   depends on EXPERIMENTAL && m
+   depends on m
default 'n'
help
  This module may be useful to developers of SMBus client drivers,
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index bdca511..9b94a78 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -22,7 +22,7 @@ config I2C_ALI1535
 
 config I2C_ALI1563
tristate "ALI 1563"
-   depends on PCI && EXPERIMENTAL
+   depends on PCI
help
  If you say yes to this option, support will be included for the SMB
  Host controller on Acer Labs Inc. (ALI) M1563 South Bridges.  The SMB
@@ -56,7 +56,7 @@ config I2C_AMD756
 
 config I2C_AMD756_S4882
tristate "SMBus multiplexing on the Tyan S4882"
-   depends on I2C_AMD756 && X86 && EXPERIMENTAL
+   depends on I2C_AMD756 && X86
help
  Enabling this option will add specific SMBus support for the Tyan
  S4882 motherboard.  On this 4-CPU board, the SMBus is multiplexed
@@ -164,7 +164,7 @@ config I2C_NFORCE2
 
 config I2C_NFORCE2_S4985
tristate "SMBus multiplexing on the Tyan S4985"
-   depends on I2C_NFORCE2 && X86 && EXPERIMENTAL
+   depends on I2C_NFORCE2 && X86
help
  Enabling this option will add specific SMBus support for the Tyan
  S4985 motherboard.  On this 4-CPU board, the SMBus is multiplexed
@@ -215,7 +215,7 @@ config I2C_SIS96X
 
 config I2C_VIA
tristate "VIA VT82C586B"
-   depends on PCI && EXPERIMENTAL
+   depends on PCI
select I2C_ALGOBIT
help
  If you say yes to this option, support will be included for the VIA
@@ -267,7 +267,7 @@ comment "Mac SMBus host controller drivers"
 
 config I2C_HYDRA
tristate "CHRP Apple Hydra Mac I/O I2C interface"
-   depends on PCI && PPC_CHRP && EXPERIMENTAL
+   depends on PCI && PPC_CHRP
select I2C_ALGOBIT
help
  This supports the use of the I2C interface in the Apple Hydra Mac
@@ -293,7 +293,7 @@ comment "I2C system bus drivers (mostly embedded / 
system-on-chip)"
 
 config I2C_AT91
tristate "Atmel AT91 I2C Two-Wire interface (TWI)"
-   depends on ARCH_AT91 && EXPERIMENTAL
+   depends on ARCH_AT91
help
  This supports the use of the I2C interface on Atmel AT91
  processors.
@@ -519,7 +519,6 @@ config I2C_NUC900
 
 config I2C_OCORES
tristate "OpenCores I2C Controller"
-   depends on EXPERIMENTAL
help
  If you say yes to this option, support will be included for the
  OpenCores I2C controller. For details see
@@ -712,7 +711,7 @@ config I2C_OCTEON
 
 config I2C_XILINX
tristate "Xilinx I2C Controller"
-   depends on EXPERIMENTAL && HAS_IOMEM
+   depends on HAS_IOMEM
help
  If you say yes to this option, support will be included for the
  Xilinx I2C controller.
@@ -803,7 +802,6 @@ config I2C_PARPORT_LIGHT
 
 config I2C_TAOS_EVM
tristate "TAOS evaluation module"
-   depends on EXPERIMENTAL
select SERIO
select SERIO_SERPORT
default n
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 56/86] drivers/pci/pcie: remove depends on CONFIG_EXPERIMENTAL

[Kees Cook]

The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.

CC: Bjorn Helgaas 
CC: Jesse Barnes 
CC: Matthew Garrett 
Cc: Greg Kroah-Hartman 
Signed-off-by: Kees Cook 
---
 drivers/pci/pcie/Kconfig |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pci/pcie/Kconfig b/drivers/pci/pcie/Kconfig
index 6c8bc58..fde4a32 100644
--- a/drivers/pci/pcie/Kconfig
+++ b/drivers/pci/pcie/Kconfig
@@ -82,4 +82,4 @@ endchoice
 
 config PCIE_PME
def_bool y
-   depends on PCIEPORTBUS && PM_RUNTIME && EXPERIMENTAL && ACPI
+   depends on PCIEPORTBUS && PM_RUNTIME && ACPI
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 37/86] drivers/ata: remove depends on CONFIG_EXPERIMENTAL

[Kees Cook]

The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.

CC: Jeff Garzik 
Cc: Greg Kroah-Hartman 
Signed-off-by: Kees Cook 
---
 drivers/ata/Kconfig |   24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index e08d322..cdadce2 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -163,7 +163,7 @@ config SATA_QSTOR
 
 config SATA_SX4
tristate "Promise SATA SX4 support (Experimental)"
-   depends on PCI && EXPERIMENTAL
+   depends on PCI
help
  This option enables support for Promise Serial ATA SX4.
 
@@ -390,7 +390,7 @@ config PATA_CS5530
 
 config PATA_CS5535
tristate "CS5535 PATA support (Experimental)"
-   depends on PCI && X86 && !X86_64 && EXPERIMENTAL
+   depends on PCI && X86 && !X86_64
help
  This option enables support for the NatSemi/AMD CS5535
  companion chip used with the Geode processor family.
@@ -408,7 +408,7 @@ config PATA_CS5536
 
 config PATA_CYPRESS
tristate "Cypress CY82C693 PATA support (Very Experimental)"
-   depends on PCI && EXPERIMENTAL
+   depends on PCI
help
  This option enables support for the Cypress/Contaq CY82C693
  chipset found in some Alpha systems
@@ -496,7 +496,7 @@ config PATA_IMX
 
 config PATA_IT8213
tristate "IT8213 PATA support (Experimental)"
-   depends on PCI && EXPERIMENTAL
+   depends on PCI
help
  This option enables support for the ITE 821 PATA
   controllers via the new ATA layer.
@@ -589,7 +589,7 @@ config PATA_OLDPIIX
 
 config PATA_OPTIDMA
tristate "OPTI FireStar PATA support (Very Experimental)"
-   depends on PCI && EXPERIMENTAL
+   depends on PCI
help
  This option enables DMA/PIO support for the later OPTi
  controllers found on some old motherboards and in some
@@ -616,7 +616,7 @@ config PATA_PDC_OLD
 
 config PATA_RADISYS
tristate "RADISYS 82600 PATA support (Experimental)"
-   depends on PCI && EXPERIMENTAL
+   depends on PCI
help
  This option enables support for the RADISYS 82600
  PATA controllers via the new ATA layer
@@ -687,7 +687,7 @@ config PATA_SIS
 
 config PATA_TOSHIBA
tristate "Toshiba Piccolo support (Experimental)"
-   depends on PCI && EXPERIMENTAL
+   depends on PCI
help
  Support for the Toshiba Piccolo controllers. Currently only the
  primary channel is supported by this driver.
@@ -738,7 +738,7 @@ comment "PIO-only SFF controllers"
 
 config PATA_AT32
tristate "Atmel AVR32 PATA support (Experimental)"
-   depends on AVR32 && PLATFORM_AT32AP && EXPERIMENTAL
+   depends on AVR32 && PLATFORM_AT32AP
help
  This option enables support for the IDE devices on the
  Atmel AT32AP platform.
@@ -755,7 +755,7 @@ config PATA_AT91
 
 config PATA_CMD640_PCI
tristate "CMD640 PCI PATA support (Experimental)"
-   depends on PCI && EXPERIMENTAL
+   depends on PCI
help
  This option enables support for the CMD640 PCI IDE
  interface chip. Only the primary channel is currently
@@ -801,7 +801,7 @@ config PATA_NS87410
 
 config PATA_OPTI
tristate "OPTI621/6215 PATA support (Very Experimental)"
-   depends on PCI && EXPERIMENTAL
+   depends on PCI
help
  This option enables full PIO support for the early Opti ATA
  controllers found on some old motherboards.
@@ -881,7 +881,7 @@ config PATA_SAMSUNG_CF
 
 config PATA_WINBOND_VLB
tristate "Winbond W83759A VLB PATA support (Experimental)"
-   depends on ISA && EXPERIMENTAL
+   depends on ISA
select PATA_LEGACY
help
  Support for the Winbond W83759A controller on Vesa Local Bus
@@ -909,7 +909,7 @@ config ATA_GENERIC
 
 config PATA_LEGACY
tristate "Legacy ISA PATA support (Experimental)"
-   depends on (ISA || PCI) && EXPERIMENTAL
+   depends on (ISA || PCI)
help
  This option enables support for ISA/VLB/PCI bus legacy PATA
  ports and allows them to be accessed via the new ATA layer.
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 50/86] drivers/macintosh: remove depends on CONFIG_EXPERIMENTAL

[Kees Cook]

The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.

CC: Benjamin Herrenschmidt 
Cc: Greg Kroah-Hartman 
Signed-off-by: Kees Cook 
---
 drivers/macintosh/Kconfig |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/macintosh/Kconfig b/drivers/macintosh/Kconfig
index a555da6..696238b 100644
--- a/drivers/macintosh/Kconfig
+++ b/drivers/macintosh/Kconfig
@@ -278,7 +278,7 @@ config PMAC_RACKMETER
 
 config SENSORS_AMS
tristate "Apple Motion Sensor driver"
-   depends on PPC_PMAC && !PPC64 && INPUT && ((ADB_PMU && I2C = y) || 
(ADB_PMU && !I2C) || I2C) && EXPERIMENTAL
+   depends on PPC_PMAC && !PPC64 && INPUT && ((ADB_PMU && I2C = y) || 
(ADB_PMU && !I2C) || I2C)
select INPUT_POLLDEV
help
  Support for the motion sensor included in PowerBooks. Includes
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 46/86] drivers/idle: remove depends on CONFIG_EXPERIMENTAL

[Kees Cook]

The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.

Cc: Len Brown 
Cc: Greg Kroah-Hartman 
Signed-off-by: Kees Cook 
---
 drivers/idle/Kconfig |1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/idle/Kconfig b/drivers/idle/Kconfig
index 8489eb5..4732dfc 100644
--- a/drivers/idle/Kconfig
+++ b/drivers/idle/Kconfig
@@ -18,7 +18,6 @@ config I7300_IDLE_IOAT_CHANNEL
 config I7300_IDLE
tristate "Intel chipset idle memory power saving driver"
select I7300_IDLE_IOAT_CHANNEL
-   depends on EXPERIMENTAL
help
  Enable memory power savings when idle with certain Intel server
  chipsets. The chipset must have I/O AT support, such as the
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 01/86] drivers/net/ethernet/fujitsu: remove depends on CONFIG_EXPERIMENTAL

[Kees Cook]

The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.

Cc: "David S. Miller" 
Cc: Greg Kroah-Hartman 
Signed-off-by: Kees Cook 
---
 drivers/net/ethernet/fujitsu/Kconfig |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/fujitsu/Kconfig 
b/drivers/net/ethernet/fujitsu/Kconfig
index dffee9d..80926c1 100644
--- a/drivers/net/ethernet/fujitsu/Kconfig
+++ b/drivers/net/ethernet/fujitsu/Kconfig
@@ -5,7 +5,7 @@
 config NET_VENDOR_FUJITSU
bool "Fujitsu devices"
default y
-   depends on ISA || PCMCIA || ((ISA || MCA_LEGACY) && EXPERIMENTAL)
+   depends on ISA || PCMCIA || MCA_LEGACY
---help---
  If you have a network (Ethernet) card belonging to this class, say Y
  and read the Ethernet-HOWTO, available from
@@ -18,8 +18,8 @@ config NET_VENDOR_FUJITSU
 if NET_VENDOR_FUJITSU
 
 config AT1700
-   tristate "AT1700/1720 support (EXPERIMENTAL)"
-   depends on (ISA || MCA_LEGACY) && EXPERIMENTAL
+   tristate "AT1700/1720 support"
+   depends on (ISA || MCA_LEGACY)
select CRC32
---help---
  If you have a network (Ethernet) card of this type, say Y and read
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 64/86] drivers/vhost: remove depends on CONFIG_EXPERIMENTAL

[Kees Cook]

The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.

CC: "Michael S. Tsirkin" 
Cc: Greg Kroah-Hartman 
Signed-off-by: Kees Cook 
---
 drivers/vhost/Kconfig |4 ++--
 drivers/vhost/Kconfig.tcm |4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/vhost/Kconfig b/drivers/vhost/Kconfig
index 202bba6..bf24317 100644
--- a/drivers/vhost/Kconfig
+++ b/drivers/vhost/Kconfig
@@ -1,6 +1,6 @@
 config VHOST_NET
-   tristate "Host kernel accelerator for virtio net (EXPERIMENTAL)"
-   depends on NET && EVENTFD && (TUN || !TUN) && (MACVTAP || !MACVTAP) && 
EXPERIMENTAL
+   tristate "Host kernel accelerator for virtio net"
+   depends on NET && EVENTFD && (TUN || !TUN) && (MACVTAP || !MACVTAP)
---help---
  This kernel module can be loaded in host kernel to accelerate
  guest networking with virtio_net. Not to be confused with virtio_net
diff --git a/drivers/vhost/Kconfig.tcm b/drivers/vhost/Kconfig.tcm
index a9c6f76..7e3aa28 100644
--- a/drivers/vhost/Kconfig.tcm
+++ b/drivers/vhost/Kconfig.tcm
@@ -1,6 +1,6 @@
 config TCM_VHOST
-   tristate "TCM_VHOST fabric module (EXPERIMENTAL)"
-   depends on TARGET_CORE && EVENTFD && EXPERIMENTAL && m
+   tristate "TCM_VHOST fabric module"
+   depends on TARGET_CORE && EVENTFD && m
default n
---help---
Say M here to enable the TCM_VHOST fabric module for use with 
virtio-scsi guests
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 24/86] arch/blackfin: remove depends on CONFIG_EXPERIMENTAL

[Kees Cook]

The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.

CC: Mike Frysinger 
Cc: Greg Kroah-Hartman 
Signed-off-by: Kees Cook 
---
 arch/blackfin/Kconfig |6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/arch/blackfin/Kconfig b/arch/blackfin/Kconfig
index b6f3ad5..ca33c8d 100644
--- a/arch/blackfin/Kconfig
+++ b/arch/blackfin/Kconfig
@@ -562,8 +562,7 @@ choice
  accurate - This option is therefore marked experimental.
 
 config BFIN_KERNEL_CLOCK_MEMINIT_CALC
-   bool "Calculate Timings (EXPERIMENTAL)"
-   depends on EXPERIMENTAL
+   bool "Calculate Timings"
 
 config BFIN_KERNEL_CLOCK_MEMINIT_SPEC
bool "Provide accurate Timings based on target SCLK"
@@ -1120,7 +1119,7 @@ endchoice
 
 comment "Memory Protection Unit"
 config MPU
-   bool "Enable the memory protection unit (EXPERIMENTAL)"
+   bool "Enable the memory protection unit"
default n
help
  Use the processor's MPU to protect applications from accessing
@@ -1442,7 +1441,6 @@ config BFIN_CPU_FREQ
 
 config CPU_VOLTAGE
bool "CPU Voltage scaling"
-   depends on EXPERIMENTAL
depends on CPU_FREQ
default n
help
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 05/86] drivers/net/ethernet/seeq: remove depends on CONFIG_EXPERIMENTAL

[David Miller]

Partially CC:'ing a mailing list for a subset of patches, without also
CC:'ing that list on your openning "00/xxx" email explaing what you're
doing and why is kind of pointless.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 79/86] fs/hfs: remove depends on CONFIG_EXPERIMENTAL

[Kees Cook]

The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.

Cc: Artem Bityutskiy 
Cc: Al Viro 
Cc: Greg Kroah-Hartman 
Signed-off-by: Kees Cook 
---
 fs/hfs/Kconfig |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/hfs/Kconfig b/fs/hfs/Kconfig
index b77c5bc..998e3a6 100644
--- a/fs/hfs/Kconfig
+++ b/fs/hfs/Kconfig
@@ -1,6 +1,6 @@
 config HFS_FS
-   tristate "Apple Macintosh file system support (EXPERIMENTAL)"
-   depends on BLOCK && EXPERIMENTAL
+   tristate "Apple Macintosh file system support"
+   depends on BLOCK
select NLS
help
  If you say Y here, you will be able to mount Macintosh-formatted
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 72/86] fs/affs: remove depends on CONFIG_EXPERIMENTAL

[Kees Cook]

The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.

Cc: Artem Bityutskiy 
Cc: Al Viro 
Cc: Greg Kroah-Hartman 
Signed-off-by: Kees Cook 
---
 fs/affs/Kconfig |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/affs/Kconfig b/fs/affs/Kconfig
index cfad9af..a04d9e8 100644
--- a/fs/affs/Kconfig
+++ b/fs/affs/Kconfig
@@ -1,6 +1,6 @@
 config AFFS_FS
-   tristate "Amiga FFS file system support (EXPERIMENTAL)"
-   depends on BLOCK && EXPERIMENTAL
+   tristate "Amiga FFS file system support"
+   depends on BLOCK
help
  The Fast File System (FFS) is the common file system used on hard
  disks by Amiga(tm) systems since AmigaOS Version 1.3 (34.20).  Say Y
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 42/86] drivers/gpu/drm/cirrus: remove depends on CONFIG_EXPERIMENTAL

[Kees Cook]

The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.

CC: Dave Airlie 
CC: Adam Jackson 
Cc: Greg Kroah-Hartman 
Signed-off-by: Kees Cook 
---
 drivers/gpu/drm/cirrus/Kconfig |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/cirrus/Kconfig b/drivers/gpu/drm/cirrus/Kconfig
index fc154dd..bf67b22 100644
--- a/drivers/gpu/drm/cirrus/Kconfig
+++ b/drivers/gpu/drm/cirrus/Kconfig
@@ -1,6 +1,6 @@
 config DRM_CIRRUS_QEMU
tristate "Cirrus driver for QEMU emulated device"
-   depends on DRM && PCI && EXPERIMENTAL
+   depends on DRM && PCI
select FB_SYS_FILLRECT
select FB_SYS_COPYAREA
select FB_SYS_IMAGEBLIT
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Redefinition of struct in6_addr in and

[YOSHIFUJI Hideaki]

Carlos O'Donell wrote:
> diff --git a/include/uapi/linux/in6.h b/include/uapi/linux/in6.h
> index f79c372..a2b16a5 100644
> --- a/include/uapi/linux/in6.h
> +++ b/include/uapi/linux/in6.h
:
>  #define IPV6_PRIORITY_14 0x0e00
>  #define IPV6_PRIORITY_15 0x0f00
>  
> +
> +#ifndef _NETINET_IN_H
> +#if defined (__GLIBC__)
> +/* Include all of the other IPPROTO_* defines for userspace. */
> +#include 
> +#endif
>  /*
>   *   IPV6 extension headers

Overall, it looks good, but why including linux/ipproto.h?

--yoshfuji
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 74/86] fs/befs: remove depends on CONFIG_EXPERIMENTAL

[Kees Cook]

The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.

Cc: Al Viro 
Cc: Greg Kroah-Hartman 
Signed-off-by: Kees Cook 
---
 fs/befs/Kconfig |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/befs/Kconfig b/fs/befs/Kconfig
index 7835d30..edc5cc2 100644
--- a/fs/befs/Kconfig
+++ b/fs/befs/Kconfig
@@ -1,6 +1,6 @@
 config BEFS_FS
-   tristate "BeOS file system (BeFS) support (read only) (EXPERIMENTAL)"
-   depends on BLOCK && EXPERIMENTAL
+   tristate "BeOS file system (BeFS) support (read only)"
+   depends on BLOCK
select NLS
help
  The BeOS File System (BeFS) is the native file system of Be, Inc's
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 71/86] fs/adfs: remove depends on CONFIG_EXPERIMENTAL

[Kees Cook]

The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.

Cc: Stuart Swales 
Cc: Russell King 
Cc: Al Viro 
Cc: Greg Kroah-Hartman 
Signed-off-by: Kees Cook 
---
 fs/adfs/Kconfig |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/adfs/Kconfig b/fs/adfs/Kconfig
index e55182a..c5a7787 100644
--- a/fs/adfs/Kconfig
+++ b/fs/adfs/Kconfig
@@ -1,6 +1,6 @@
 config ADFS_FS
-   tristate "ADFS file system support (EXPERIMENTAL)"
-   depends on BLOCK && EXPERIMENTAL
+   tristate "ADFS file system support"
+   depends on BLOCK
help
  The Acorn Disc Filing System is the standard file system of the
  RiscOS operating system which runs on Acorn's ARM-based Risc PC
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 69/86] drivers/vlynq: remove depends on CONFIG_EXPERIMENTAL

[Kees Cook]

The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.

Cc: Florian Fainelli 
Cc: Greg Kroah-Hartman 
Signed-off-by: Kees Cook 
---
 drivers/vlynq/Kconfig |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/vlynq/Kconfig b/drivers/vlynq/Kconfig
index d874b4f..e011620 100644
--- a/drivers/vlynq/Kconfig
+++ b/drivers/vlynq/Kconfig
@@ -1,5 +1,5 @@
 menu "TI VLYNQ"
-   depends on AR7 && EXPERIMENTAL
+   depends on AR7
 
 config VLYNQ
bool "TI VLYNQ bus support"
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 44/86] drivers/gpu/drm/mgag200: remove depends on CONFIG_EXPERIMENTAL

[Kees Cook]

The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.

CC: Dave Airlie 
Cc: Greg Kroah-Hartman 
Signed-off-by: Kees Cook 
---
 drivers/gpu/drm/mgag200/Kconfig |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/mgag200/Kconfig b/drivers/gpu/drm/mgag200/Kconfig
index d630134..b487cde 100644
--- a/drivers/gpu/drm/mgag200/Kconfig
+++ b/drivers/gpu/drm/mgag200/Kconfig
@@ -1,6 +1,6 @@
 config DRM_MGAG200
tristate "Kernel modesetting driver for MGA G200 server engines"
-   depends on DRM && PCI && EXPERIMENTAL
+   depends on DRM && PCI
select FB_SYS_FILLRECT
select FB_SYS_COPYAREA
select FB_SYS_IMAGEBLIT
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 18/86] drivers/net/wireless/rtl818x: remove depends on CONFIG_EXPERIMENTAL

[Kees Cook]

The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.

CC: "John W. Linville" 
Cc: "David S. Miller" 
Cc: Greg Kroah-Hartman 
Signed-off-by: Kees Cook 
---
 drivers/net/wireless/rtl818x/Kconfig |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/rtl818x/Kconfig 
b/drivers/net/wireless/rtl818x/Kconfig
index 17d80fe..3033217 100644
--- a/drivers/net/wireless/rtl818x/Kconfig
+++ b/drivers/net/wireless/rtl818x/Kconfig
@@ -3,7 +3,7 @@
 #
 config RTL8180
tristate "Realtek 8180/8185 PCI support"
-   depends on MAC80211 && PCI && EXPERIMENTAL
+   depends on MAC80211 && PCI
select EEPROM_93CX6
---help---
  This is a driver for RTL8180 and RTL8185 based cards.
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 76/86] fs/btrfs: remove depends on CONFIG_EXPERIMENTAL

[Kees Cook]

The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.

Cc: Chris Mason 
Cc: Al Viro 
Cc: Greg Kroah-Hartman 
Signed-off-by: Kees Cook 
---
 fs/btrfs/Kconfig |3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/fs/btrfs/Kconfig b/fs/btrfs/Kconfig
index d33f01c..ccd25ba 100644
--- a/fs/btrfs/Kconfig
+++ b/fs/btrfs/Kconfig
@@ -1,6 +1,5 @@
 config BTRFS_FS
-   tristate "Btrfs filesystem (EXPERIMENTAL) Unstable disk format"
-   depends on EXPERIMENTAL
+   tristate "Btrfs filesystem Unstable disk format"
select LIBCRC32C
select ZLIB_INFLATE
select ZLIB_DEFLATE
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 86/86] final removal of CONFIG_EXPERIMENTAL

[Kees Cook]

Remove CONFIG_EXPERIMENTAL, now that every mention of it has been removed
from the tree.

Cc: Greg Kroah-Hartman 
Signed-off-by: Kees Cook 
---
 init/Kconfig |4 
 1 file changed, 4 deletions(-)

diff --git a/init/Kconfig b/init/Kconfig
index a966690..fb9f55b 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -32,10 +32,6 @@ config BUILDTIME_EXTABLE_SORT
 
 menu "General setup"
 
-config EXPERIMENTAL
-   bool
-   default y
-
 config BROKEN
bool
 
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 73/86] fs/afs: remove depends on CONFIG_EXPERIMENTAL

[Kees Cook]

The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.

CC: David Howells 
Cc: Al Viro 
Cc: Greg Kroah-Hartman 
Signed-off-by: Kees Cook 
---
 fs/afs/Kconfig |7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/fs/afs/Kconfig b/fs/afs/Kconfig
index 8f975f2..ebba3b1 100644
--- a/fs/afs/Kconfig
+++ b/fs/afs/Kconfig
@@ -1,6 +1,6 @@
 config AFS_FS
-   tristate "Andrew File System support (AFS) (EXPERIMENTAL)"
-   depends on INET && EXPERIMENTAL
+   tristate "Andrew File System support (AFS)"
+   depends on INET
select AF_RXRPC
select DNS_RESOLVER
help
@@ -22,8 +22,7 @@ config AFS_DEBUG
  If unsure, say N.
 
 config AFS_FSCACHE
-   bool "Provide AFS client caching support (EXPERIMENTAL)"
-   depends on EXPERIMENTAL
+   bool "Provide AFS client caching support"
depends on AFS_FS=m && FSCACHE || AFS_FS=y && FSCACHE=y
help
  Say Y here if you want AFS data to be cached locally on disk through
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 67/86] drivers/video/geode: remove depends on CONFIG_EXPERIMENTAL

[Kees Cook]

The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.

CC: Florian Tobias Schandinat 
Cc: Greg Kroah-Hartman 
Signed-off-by: Kees Cook 
---
 drivers/video/geode/Kconfig |   14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/video/geode/Kconfig b/drivers/video/geode/Kconfig
index c5d8ba4..21e351a 100644
--- a/drivers/video/geode/Kconfig
+++ b/drivers/video/geode/Kconfig
@@ -2,14 +2,14 @@
 # Geode family framebuffer configuration
 #
 config FB_GEODE
-   bool "AMD Geode family framebuffer support (EXPERIMENTAL)"
-   depends on FB && PCI && EXPERIMENTAL && X86
+   bool "AMD Geode family framebuffer support"
+   depends on FB && PCI && X86
---help---
  Say 'Y' here to allow you to select framebuffer drivers for
  the AMD Geode family of processors.
 
 config FB_GEODE_LX
-   tristate "AMD Geode LX framebuffer support (EXPERIMENTAL)"
+   tristate "AMD Geode LX framebuffer support"
depends on FB && FB_GEODE
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
@@ -24,8 +24,8 @@ config FB_GEODE_LX
  If unsure, say N.
 
 config FB_GEODE_GX
-   tristate "AMD Geode GX framebuffer support (EXPERIMENTAL)"
-   depends on FB && FB_GEODE && EXPERIMENTAL
+   tristate "AMD Geode GX framebuffer support"
+   depends on FB && FB_GEODE
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
@@ -39,8 +39,8 @@ config FB_GEODE_GX
  If unsure, say N.
 
 config FB_GEODE_GX1
-   tristate "AMD Geode GX1 framebuffer support (EXPERIMENTAL)"
-   depends on FB && FB_GEODE && EXPERIMENTAL
+   tristate "AMD Geode GX1 framebuffer support"
+   depends on FB && FB_GEODE
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 65/86] drivers/video: remove depends on CONFIG_EXPERIMENTAL

[Kees Cook]

The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.

CC: Florian Tobias Schandinat 
Cc: Greg Kroah-Hartman 
Signed-off-by: Kees Cook 
---
 drivers/video/Kconfig |   26 +-
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index e7068c5..e4e1765 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -1112,8 +1112,8 @@ config FB_RIVA_BACKLIGHT
  Say Y here if you want to control the backlight of your display.
 
 config FB_I740
-   tristate "Intel740 support (EXPERIMENTAL)"
-   depends on EXPERIMENTAL && FB && PCI
+   tristate "Intel740 support"
+   depends on FB && PCI
select FB_MODE_HELPERS
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
@@ -1124,8 +1124,8 @@ config FB_I740
  This driver supports graphics cards based on Intel740 chip.
 
 config FB_I810
-   tristate "Intel 810/815 support (EXPERIMENTAL)"
-   depends on EXPERIMENTAL && FB && PCI && X86_32 && AGP_INTEL
+   tristate "Intel 810/815 support"
+   depends on FB && PCI && X86_32 && AGP_INTEL
select FB_MODE_HELPERS
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
@@ -1187,8 +1187,8 @@ config FB_CARILLO_RANCH
  This driver supports the LE80578 (Carillo Ranch) board
 
 config FB_INTEL
-   tristate "Intel 830M/845G/852GM/855GM/865G/915G/945G/945GM/965G/965GM 
support (EXPERIMENTAL)"
-   depends on EXPERIMENTAL && FB && PCI && X86 && AGP_INTEL && EXPERT
+   tristate "Intel 830M/845G/852GM/855GM/865G/915G/945G/945GM/965G/965GM 
support"
+   depends on FB && PCI && X86 && AGP_INTEL && EXPERT
select FB_MODE_HELPERS
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
@@ -1432,7 +1432,7 @@ config FB_ATY_CT
  is at .
 
 config FB_ATY_GENERIC_LCD
-   bool "Mach64 generic LCD support (EXPERIMENTAL)"
+   bool "Mach64 generic LCD support"
depends on FB_ATY_CT
help
  Say Y if you have a laptop with an ATI Rage LT PRO, Rage Mobility,
@@ -1479,7 +1479,7 @@ config FB_S3_DDC
 
 config FB_SAVAGE
tristate "S3 Savage support"
-   depends on FB && PCI && EXPERIMENTAL
+   depends on FB && PCI
select FB_MODE_HELPERS
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
@@ -1633,15 +1633,15 @@ config FB_3DFX
  module will be called tdfxfb.
 
 config FB_3DFX_ACCEL
-   bool "3Dfx Acceleration functions (EXPERIMENTAL)"
-   depends on FB_3DFX && EXPERIMENTAL
+   bool "3Dfx Acceleration functions"
+   depends on FB_3DFX
---help---
This will compile the 3Dfx Banshee/Voodoo3/VSA-100 frame buffer
device driver with acceleration functions.
 
 config FB_3DFX_I2C
bool "Enable DDC/I2C support"
-   depends on FB_3DFX && EXPERIMENTAL
+   depends on FB_3DFX
select FB_DDC
default y
help
@@ -1714,8 +1714,8 @@ config FB_ARK
  and ICS 5342 RAMDAC.
 
 config FB_PM3
-   tristate "Permedia3 support (EXPERIMENTAL)"
-   depends on FB && PCI && EXPERIMENTAL
+   tristate "Permedia3 support"
+   depends on FB && PCI
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 68/86] drivers/video/omap: remove depends on CONFIG_EXPERIMENTAL

[Kees Cook]

The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.

CC: Tomi Valkeinen 
CC: Florian Tobias Schandinat 
Cc: Greg Kroah-Hartman 
Signed-off-by: Kees Cook 
---
 drivers/video/omap/Kconfig |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/omap/Kconfig b/drivers/video/omap/Kconfig
index b48f95f..e512581 100644
--- a/drivers/video/omap/Kconfig
+++ b/drivers/video/omap/Kconfig
@@ -1,5 +1,5 @@
 config FB_OMAP
-   tristate "OMAP frame buffer support (EXPERIMENTAL)"
+   tristate "OMAP frame buffer support"
depends on FB
depends on ARCH_OMAP1
select FB_CFB_FILLRECT
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 82/86] fs/nfsd: remove depends on CONFIG_EXPERIMENTAL

[Kees Cook]

The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.

CC: "J. Bruce Fields" 
Cc: Al Viro 
Cc: Greg Kroah-Hartman 
Signed-off-by: Kees Cook 
---
 fs/nfsd/Kconfig |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/nfsd/Kconfig b/fs/nfsd/Kconfig
index 8df1ea4..430b687 100644
--- a/fs/nfsd/Kconfig
+++ b/fs/nfsd/Kconfig
@@ -65,8 +65,8 @@ config NFSD_V3_ACL
  If unsure, say N.
 
 config NFSD_V4
-   bool "NFS server support for NFS version 4 (EXPERIMENTAL)"
-   depends on NFSD && PROC_FS && EXPERIMENTAL
+   bool "NFS server support for NFS version 4"
+   depends on NFSD && PROC_FS
select NFSD_V3
select FS_POSIX_ACL
select SUNRPC_GSS
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 49/86] drivers/leds: remove depends on CONFIG_EXPERIMENTAL

[Kees Cook]

The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.

CC: Richard Purdie 
Cc: Greg Kroah-Hartman 
Signed-off-by: Kees Cook 
---
 drivers/leds/Kconfig |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index b58bc8a..4469b44 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -154,7 +154,7 @@ config LEDS_HP6XX
 config LEDS_PCA9532
tristate "LED driver for PCA9532 dimmer"
depends on LEDS_CLASS
-   depends on I2C && INPUT && EXPERIMENTAL
+   depends on I2C && INPUT
help
  This option enables support for NXP pca9532
  LED controller. It is generally only useful
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 70/86] fs/9p: remove depends on CONFIG_EXPERIMENTAL

[Kees Cook]

The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.

CC: Eric Van Hensbergen 
CC: Ron Minnich 
CC: Latchesar Ionkov 
Cc: Al Viro 
Cc: Greg Kroah-Hartman 
Signed-off-by: Kees Cook 
---
 fs/9p/Kconfig |3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/fs/9p/Kconfig b/fs/9p/Kconfig
index 0a93dc1..55abfd6 100644
--- a/fs/9p/Kconfig
+++ b/fs/9p/Kconfig
@@ -11,8 +11,7 @@ config 9P_FS
 
 if 9P_FS
 config 9P_FSCACHE
-   bool "Enable 9P client caching support (EXPERIMENTAL)"
-   depends on EXPERIMENTAL
+   bool "Enable 9P client caching support"
depends on 9P_FS=m && FSCACHE || 9P_FS=y && FSCACHE=y
help
  Choose Y here to enable persistent, read-only local
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 75/86] fs/bfs: remove depends on CONFIG_EXPERIMENTAL

[Kees Cook]

The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.

Cc: "Tigran A. Aivazian" 
Cc: Al Viro 
Cc: Greg Kroah-Hartman 
Signed-off-by: Kees Cook 
---
 fs/bfs/Kconfig |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/bfs/Kconfig b/fs/bfs/Kconfig
index c2336c6..3728a64 100644
--- a/fs/bfs/Kconfig
+++ b/fs/bfs/Kconfig
@@ -1,6 +1,6 @@
 config BFS_FS
-   tristate "BFS file system support (EXPERIMENTAL)"
-   depends on BLOCK && EXPERIMENTAL
+   tristate "BFS file system support"
+   depends on BLOCK
help
  Boot File System (BFS) is a file system used under SCO UnixWare to
  allow the bootloader access to the kernel image and other important
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 29/86] arch/parisc: remove depends on CONFIG_EXPERIMENTAL

[Kees Cook]

The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.

CC: "James E.J. Bottomley" 
CC: Helge Deller 
Cc: Greg Kroah-Hartman 
Signed-off-by: Kees Cook 
---
 arch/parisc/Kconfig |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/parisc/Kconfig b/arch/parisc/Kconfig
index b77feff..416309b 100644
--- a/arch/parisc/Kconfig
+++ b/arch/parisc/Kconfig
@@ -194,12 +194,12 @@ config PARISC_PAGE_SIZE_4KB
  If you don't know what to do, choose 4KB.
 
 config PARISC_PAGE_SIZE_16KB
-   bool "16KB (EXPERIMENTAL)"
-   depends on PA8X00 && EXPERIMENTAL
+   bool "16KB"
+   depends on PA8X00
 
 config PARISC_PAGE_SIZE_64KB
-   bool "64KB (EXPERIMENTAL)"
-   depends on PA8X00 && EXPERIMENTAL
+   bool "64KB"
+   depends on PA8X00
 
 endchoice
 
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/