Re: [PATCH 03/16] f2fs: add superblock and major in-memory structures
On Tue, Oct 09, 2012 at 02:13:29PM +0900, Chul Lee wrote:
> > > + block_t data_blkaddr;
> > > +};
> > > +
> > > +struct f2fs_sb_info {
> > > + struct super_block *sb; /* Pointer to VFS super
> > block */
> > > + int s_dirty;
> >
> > Is s_dirty actually used? I can see it only set and reset at checkpoint,
> > not eg. synced with an on-disk block to signalize a dirty status.
>
> The s_dirty is checked, when sync_fs is called.
I've checked again, you're right, I did not see it before.
> > > + struct mutex gc_mutex; /* mutex for GC */
> > > + struct mutex fs_lock[NR_LOCK_TYPE]; /* mutex for GP */
> > > + struct mutex write_inode; /* mutex for write inode */
> > > + struct mutex writepages;/* mutex for writepages() */
> >
> > wow, thats 1+8+2 = 11 mutexes in a row! The ones hidden under
> > NR_LOCK_TYPE may hurt, as they seem to protect various and common file
> > opterations (guesed from the lock_type names).
>
> Yes, they protect global variables shared by various operations and
> checkpoint.
> Could you tell me what you recommend? Each fs_lock's under NR_LOCK_TYPE
> would have had different lock names?
I think this was too eager from me to point out the perf problems with
the mutexes, this sure would be a problem with spinlocks but mutexes can
sleep and I can see that there are IO operations enclosed in the mutex
section almost always. There may be a subset of operations that are
both frequent and lightweight.
Seems to me that DATA_NEW, NODE_NEW and DATA_WRITE are candidates for
profiling and subject to futher optimizations (ie. split the locks from
the same cacheline).
(This is not something that would prevent inclusion of F2FS into kernel)
Also, if you target only embedded devices, the scaling problems are not
critical, however a NAND device are not limited to embedded world.
david
--
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] firmware: Don't attempt to allocate zero bytes with vmalloc()
On Tue, Oct 9, 2012 at 3:52 PM, Mark Brown wrote: > The point is that there's some firmware which the driver wants to load > but where it's happy to continue if the user didn't provide one and > doesn't want to introduce needless delays. OK, I got it, thank you for sharing the use case. If loading directly, the patch isn't needed because filp_open() can return failure on non-existent file. If loading via user space, timeout or not depends on userspace, at least udev won't timeout on non-existent firmware image. Also looks request_firmware_nowait() is better for the case, _nowait() can avoid unnecessary delay and speedup firmware loading if there are more than one firmware to load. Thanks, -- Ming Lei -- 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 2/2] regulator: add device tree support for max8997
Hi Thomas, Thomas Abraham wrote: > Add device tree based discovery support for max8997. > > Cc: Karol Lewandowski > Cc: Rajendra Nayak > Cc: Rob Herring > Cc: Grant Likely > Signed-off-by: Thomas Abraham > Acked-by: MyungJoo Ham Are there any plans for merging this patch? It is a dependency of Samsung Trats board device tree support. Best regards, -- Tomasz Figa Samsung Poland R Center -- 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 00/16] f2fs: introduce flash-friendly file system
> -Original Message- > From: Lukáš Czerner [mailto:lczer...@redhat.com] > Sent: Tuesday, October 09, 2012 8:01 PM > To: Jaegeuk Kim > Cc: 'Lukáš Czerner'; 'Namjae Jeon'; 'Vyacheslav Dubeyko'; 'Marco Stornelli'; > 'Jaegeuk Kim'; 'Al Viro'; > ty...@mit.edu; gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; > chur@samsung.com; > cm224@samsung.com; jooyoung.hw...@samsung.com; > linux-fsde...@vger.kernel.org > Subject: RE: [PATCH 00/16] f2fs: introduce flash-friendly file system > > On Tue, 9 Oct 2012, Jaegeuk Kim wrote: > > > Date: Tue, 09 Oct 2012 19:45:57 +0900 > > From: Jaegeuk Kim > > To: 'Lukáš Czerner' > > Cc: 'Namjae Jeon' , > > 'Vyacheslav Dubeyko' , > > 'Marco Stornelli' , > > 'Jaegeuk Kim' , > > 'Al Viro' , ty...@mit.edu, > > gre...@linuxfoundation.org, linux-kernel@vger.kernel.org, > > chur@samsung.com, cm224@samsung.com, jooyoung.hw...@samsung.com, > > linux-fsde...@vger.kernel.org > > Subject: RE: [PATCH 00/16] f2fs: introduce flash-friendly file system > > > > > -Original Message- > > > From: linux-fsdevel-ow...@vger.kernel.org > > > [mailto:linux-fsdevel-ow...@vger.kernel.org] On Behalf > Of > > > Luka? Czerner > > > Sent: Tuesday, October 09, 2012 5:32 PM > > > To: Jaegeuk Kim > > > Cc: 'Namjae Jeon'; 'Vyacheslav Dubeyko'; 'Marco Stornelli'; 'Jaegeuk > > > Kim'; 'Al Viro'; > ty...@mit.edu; > > > gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; > > > chur@samsung.com; > cm224@samsung.com; > > > jooyoung.hw...@samsung.com; linux-fsde...@vger.kernel.org > > > Subject: RE: [PATCH 00/16] f2fs: introduce flash-friendly file system > > > > > > On Mon, 8 Oct 2012, Jaegeuk Kim wrote: > > > > > > > Date: Mon, 08 Oct 2012 19:52:03 +0900 > > > > From: Jaegeuk Kim > > > > To: 'Namjae Jeon' > > > > Cc: 'Vyacheslav Dubeyko' , > > > > 'Marco Stornelli' , > > > > 'Jaegeuk Kim' , > > > > 'Al Viro' , ty...@mit.edu, > > > > gre...@linuxfoundation.org, linux-kernel@vger.kernel.org, > > > > chur@samsung.com, cm224@samsung.com, > > > > jooyoung.hw...@samsung.com, > > > > linux-fsde...@vger.kernel.org > > > > Subject: RE: [PATCH 00/16] f2fs: introduce flash-friendly file system > > > > > > > > > -Original Message- > > > > > From: Namjae Jeon [mailto:linkinj...@gmail.com] > > > > > Sent: Monday, October 08, 2012 7:00 PM > > > > > To: Jaegeuk Kim > > > > > Cc: Vyacheslav Dubeyko; Marco Stornelli; Jaegeuk Kim; Al Viro; > > > > > ty...@mit.edu; > > > > > gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; > > > > > chur@samsung.com; > > > cm224@samsung.com; > > > > > jooyoung.hw...@samsung.com; linux-fsde...@vger.kernel.org > > > > > Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file system > > > > > > > > > > 2012/10/8, Jaegeuk Kim : > > > > > >> -Original Message- > > > > > >> From: Vyacheslav Dubeyko [mailto:sl...@dubeyko.com] > > > > > >> Sent: Sunday, October 07, 2012 9:09 PM > > > > > >> To: Jaegeuk Kim > > > > > >> Cc: 'Marco Stornelli'; 'Jaegeuk Kim'; 'Al Viro'; ty...@mit.edu; > > > > > >> gre...@linuxfoundation.org; linux- > > > > > >> ker...@vger.kernel.org; chur@samsung.com; > > > > > >> cm224@samsung.com; > > > > > >> jooyoung.hw...@samsung.com; > > > > > >> linux-fsde...@vger.kernel.org > > > > > >> Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file > > > > > >> system > > > > > >> > > > > > >> Hi, > > > > > >> > > > > > >> On Oct 7, 2012, at 1:31 PM, Jaegeuk Kim wrote: > > > > > >> > > > > > >> >> -Original Message- > > > > > >> >> From: Marco Stornelli [mailto:marco.storne...@gmail.com] > > > > > >> >> Sent: Sunday, October 07, 2012 4:10 PM > > > > > >> >> To: Jaegeuk Kim > > > > > >> >> Cc: Vyacheslav Dubeyko; jaegeuk@samsung.com; Al Viro; > > > > > >> >> ty...@mit.edu; gre...@linuxfoundation.org; > > > > > >> >> linux-kernel@vger.kernel.org; chur@samsung.com; > > > > > >> >> cm224@samsung.com; > > > > > >> jooyoung.hw...@samsung.com; > > > > > >> >> linux-fsde...@vger.kernel.org > > > > > >> >> Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file > > > > > >> >> system > > > > > >> >> > > > > > >> >> Il 06/10/2012 22:06, Jaegeuk Kim ha scritto: > > > > > >> >>> 2012-10-06 (토), 17:54 +0400, Vyacheslav Dubeyko: > > > > > >> Hi Jaegeuk, > > > > > >> >>> > > > > > >> >>> Hi. > > > > > >> >>> We know each other, right? :) > > > > > >> >>> > > > > > >> > > > > > >> > From:김재극 > > > > > >> > To: v...@zeniv.linux.org.uk, 'Theodore Ts'o' > > > > > >> > , > > > > > >> >> gre...@linuxfoundation.org, linux-kernel@vger.kernel.org, > > > > > >> >> chur@samsung.com, > > > > > >> cm224@samsung.com, > > > > > >> >> jaegeuk@samsung.com, jooyoung.hw...@samsung.com > > > > > >> > Subject: [PATCH 00/16] f2fs: introduce > > > > > >> > flash-friendly file system > > > > > >> > Date:Fri, 05 Oct 2012
Re: [PATCH][GPIO] Add IRQ edge setter to gpiolib
On Fri, Oct 5, 2012 at 3:16 PM, Drasko DRASKOVIC wrote: > [Me] >> If I understand correctly the below more or less exports >> struct irq_chip to userspace, >> trying to hide it by instead exposing a property of the >> containing struct gpio_chip and it worries me. > > No, it should not. You are exporting all of the defines from irq.h, IRQ_TYPE_NONE, IRQ_TYPE_EDGE_FALLING, etc to userspace. These are defined in and that file has this comment on top: /* * Please do not include this file in generic code. There is currently * no requirement for any architecture to implement anything held * within this file. * * Thanks. --rmk */ And that comment is even only about generic *KERNEL* code, userspace is way, way more than that. > It operates only on already exported gpiochip > (similar to gpio_export_link()). > It just helps exported GPIO be configured in "interrupt" and not in > "normal" mode. So can you explain exactly why userspace want to configure GPIO pins in interrupt mode, when there is no way whatsoever for userspace to handle these IRQs? Yours, Linus Walleij -- 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: [remoteproc:for-next 6/9] remoteproc_virtio.c:(.text+0x238e7e): undefined reference to `vring_transport_features'
Hi Sjur, On Tue, Oct 9, 2012 at 12:30 PM, Sjur BRENDELAND wrote: > Sorry for not responding sooner, but I thought this issue was solved with > your patch "remoteproc: fix (again) the virtio-related build breakage" > (https://lkml.org/lkml/2012/10/6/85). > > I'm not sure I understand why you would want to add a dependency to ARM. > But if you're uncomfortable by having STE_MODEM_RPROC directly selectable, > perhaps we could let it be selected by arch specific Kconfig files, e.g. > mach-ux500? I would just like the Kconfig dependencies to reflect the "real world": E.g., if there's no chance the STE modem is going to be used on x86, then let's not ask x86 folks about it. Does limiting the STE modem to certain platform/architectures make sense ? (if not, that's ok) Thanks, Ohad. -- 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.6.0+ (GIT) -- BUG: sleeping function called from invalid context at kernel/mutex.c:269 in_atomic(): 0, irqs_disabled(): 1, pid: 3561, name: pm-suspend
On Mon, Oct 8, 2012 at 12:07 AM, Rafael J. Wysocki wrote:
> On Wednesday 03 of October 2012 21:26:17 Miles Lane wrote:
>> ACPI: Preparing to enter system sleep state S3
>> PM: Saving platform NVS memory
>> Disabling non-boot CPUs ...
>> numa_remove_cpu cpu 1 node 0: mask now 0
>> Broke affinity for irq 46
>> smpboot: CPU 1 is now offline
>> BUG: sleeping function called from invalid context at kernel/mutex.c:269
>> in_atomic(): 0, irqs_disabled(): 1, pid: 3561, name: pm-suspend
>> 4 locks held by pm-suspend/3561:
>> #0: (>mutex){+.+.+.}, at: []
>> sysfs_write_file+0x37/0x121
>> #1: (s_active#98){.+.+.+}, at: []
>> sysfs_write_file+0xd1/0x121
>> #2: (autosleep_lock){+.+.+.}, at: []
>> pm_autosleep_lock+0x12/0x14
>> #3: (pm_mutex){+.+.+.}, at: [] pm_suspend+0x38/0x1b8
>> irq event stamp: 103458
>> hardirqs last enabled at (103457): []
>> __mutex_unlock_slowpath+0x101/0x125
>> hardirqs last disabled at (103458): []
>> arch_suspend_disable_irqs+0xa/0xc
>> softirqs last enabled at (103196): []
>> __do_softirq+0x12a/0x155
>> softirqs last disabled at (103171): []
>> call_softirq+0x1c/0x30
>> Pid: 3561, comm: pm-suspend Not tainted 3.6.0+ #26
>> Call Trace:
>> [] ? print_irqtrace_events+0x9d/0xa1
>> [] __might_sleep+0x19f/0x1a8
>> [] mutex_lock_nested+0x20/0x3b
>> [] ledtrig_cpu+0x3b/0x7b
>> [] ledtrig_cpu_syscore_suspend+0xe/0x15
>> [] syscore_suspend+0x78/0xfd
>> [] suspend_devices_and_enter+0x10f/0x201
>> [] pm_suspend+0xff/0x1b8
>> [] state_store+0x43/0x6c
>> [] kobj_attr_store+0xf/0x1b
>> [] sysfs_write_file+0xe9/0x121
>> [] vfs_write+0x9b/0xfd
>> [] ? trace_hardirqs_on+0xd/0xf
>> [] sys_write+0x4d/0x7a
>> [] tracesys+0xdd/0xe2
>
> Well, this most likely has been introduced by commit:
>
> commit 8f88731d052d2b14f332249a9332690ac1b365ac
> Author: Bryan Wu
> Date: Sat Jun 25 18:33:50 2011 +0800
>
> led-triggers: create a trigger for CPU activity
>
> because ledtrig_cpu_syscore_suspend() is run in atomic context, which kind of
> doesn't play well with mutexes.
>
> Linus, Bryan, care to fix this?
I haven't worked on this patch for ages, the only reason my SoB
is in there is that I think an early patch of mine was used as starting
point...
Bryan can you look at this?
Yours,
Linus Walleij
--
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/4] regulator: tps65090: add external control support for DCDC
On Tuesday 09 October 2012 04:41 PM, Venu Byravarasu wrote:
On Tuesday 09 October 2012 03:32 PM, Laxman Dewangan wrote:
On Tuesday 09 October 2012 04:03 PM, Venu Byravarasu wrote:
+static struct regulator_ops tps65090_ext_control_ops = {
+};
What is the purpose of adding empty structure?
We will not able to register regulator if there is no ops.
In regulator register:
if (regulator_desc->name == NULL || regulator_desc->ops == NULL)
return ERR_PTR(-EINVAL);
If tps65090_ops would be left as is, without renaming it, hope this empty
structure can be removed.
When we enabled the external control, the control signal can driver
either from gpio or some other mechanism like in our tegra3, the
control signal come from PMC controller which does not go via GPIO.
The core regulator first check for the gpio and if it is there then it
will go via the gpiolib to enable/disable. If not then it ask for the
ops->enable and if I provide these apis then it will endup in the
regulator driver. I do not want to provide the enable() when external
control is enabled and no gpios. So in this case:
- External control should be enabled on device registers.
- No enable() and disable() should success.
- is_regualtor_enabled() return true always.
--
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/5] arcmsr: Re-name the HBA Type
On Wed, 2012-10-03 at 20:39 +0800, NickCheng wrote:
> From: Nick Cheng
>
> Replace the nameing, hba, hbb and hbc, with hbaA, hbaB abd hbaC respectively
> Signed-off-by: Nick Cheng
> ---
> diff -uprN -X linux-vanilla/Documentation/dontdiff
> linux-vanilla//drivers/scsi/arcmsr/arcmsr.h
> linux-development//drivers/scsi/arcmsr/arcmsr.h
> --- linux-vanilla//drivers/scsi/arcmsr/arcmsr.h 2012-10-03
> 18:29:18.030657090 +0800
> +++ linux-development//drivers/scsi/arcmsr/arcmsr.h 2012-10-03
> 18:43:58.542648536 +0800
This patch is linebroken and can't be applied. Whatever mail tool
you're using must have broken the lines. Please see
Documentation/email-clients.txt
About how to fix this and resubmit.
Thanks,
James
> @@ -51,7 +51,7 @@ struct device_attribute;
> #else
> #define ARCMSR_MAX_FREECCB_NUM 320
> #endif
> -#define ARCMSR_DRIVER_VERSION "Driver Version 1.20.00.15
> 2010/08/05"
> +#define ARCMSR_DRIVER_VERSION "Driver Version 1.20.00.15
> 2012/09/30"
> #define ARCMSR_SCSI_INITIATOR_ID
> 255
> #define ARCMSR_MAX_XFER_SECTORS
> 512
> #define ARCMSR_MAX_XFER_SECTORS_B
> 4096
> diff -uprN -X linux-vanilla/Documentation/dontdiff
> linux-vanilla//drivers/scsi/arcmsr/arcmsr_hba.c
> linux-development//drivers/scsi/arcmsr/arcmsr_hba.c
> --- linux-vanilla//drivers/scsi/arcmsr/arcmsr_hba.c 2012-10-03
> 18:29:18.030657090 +0800
> +++ linux-development//drivers/scsi/arcmsr/arcmsr_hba.c 2012-10-03
> 18:43:58.542648536 +0800
> @@ -61,6 +61,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -95,16 +96,16 @@ static void arcmsr_iop_init(struct Adapt
> static void arcmsr_free_ccb_pool(struct AdapterControlBlock *acb);
> static u32 arcmsr_disable_outbound_ints(struct AdapterControlBlock *acb);
> static void arcmsr_stop_adapter_bgrb(struct AdapterControlBlock *acb);
> -static void arcmsr_flush_hba_cache(struct AdapterControlBlock *acb);
> -static void arcmsr_flush_hbb_cache(struct AdapterControlBlock *acb);
> +static void arcmsr_hbaA_flush_cache(struct AdapterControlBlock *acb);
> +static void arcmsr_hbaB_flush_cache(struct AdapterControlBlock *acb);
> static void arcmsr_request_device_map(unsigned long pacb);
> -static void arcmsr_request_hba_device_map(struct AdapterControlBlock *acb);
> -static void arcmsr_request_hbb_device_map(struct AdapterControlBlock *acb);
> -static void arcmsr_request_hbc_device_map(struct AdapterControlBlock *acb);
> +static void arcmsr_hbaA_request_device_map(struct AdapterControlBlock
> *acb);
> +static void arcmsr_hbaB_request_device_map(struct AdapterControlBlock
> *acb);
> +static void arcmsr_hbaC_request_device_map(struct AdapterControlBlock
> *acb);
> static void arcmsr_message_isr_bh_fn(struct work_struct *work);
> static bool arcmsr_get_firmware_spec(struct AdapterControlBlock *acb);
> static void arcmsr_start_adapter_bgrb(struct AdapterControlBlock *acb);
> -static void arcmsr_hbc_message_isr(struct AdapterControlBlock *pACB);
> +static void arcmsr_hbaC_message_isr(struct AdapterControlBlock *pACB);
> static void arcmsr_hardware_reset(struct AdapterControlBlock *acb);
> static const char *arcmsr_info(struct Scsi_Host *);
> static irqreturn_t arcmsr_interrupt(struct AdapterControlBlock *acb);
> @@ -308,7 +309,7 @@ static void arcmsr_define_adapter_type(s
> }
> }
>
> -static uint8_t arcmsr_hba_wait_msgint_ready(struct AdapterControlBlock
> *acb)
> +static uint8_t arcmsr_hbaA_wait_msgint_ready(struct AdapterControlBlock
> *acb)
> {
> struct MessageUnit_A __iomem *reg = acb->pmuA;
> int i;
> @@ -326,7 +327,7 @@ static uint8_t arcmsr_hba_wait_msgint_re
> return false;
> }
>
> -static uint8_t arcmsr_hbb_wait_msgint_ready(struct AdapterControlBlock
> *acb)
> +static uint8_t arcmsr_hbaB_wait_msgint_ready(struct AdapterControlBlock
> *acb)
> {
> struct MessageUnit_B *reg = acb->pmuB;
> int i;
> @@ -346,7 +347,7 @@ static uint8_t arcmsr_hbb_wait_msgint_re
> return false;
> }
>
> -static uint8_t arcmsr_hbc_wait_msgint_ready(struct AdapterControlBlock
> *pACB)
> +static uint8_t arcmsr_hbaC_wait_msgint_ready(struct AdapterControlBlock
> *pACB)
> {
> struct MessageUnit_C *phbcmu = (struct MessageUnit_C *)pACB->pmuC;
> int i;
> @@ -364,13 +365,13 @@ static uint8_t arcmsr_hbc_wait_msgint_re
> return false;
> }
>
> -static void arcmsr_flush_hba_cache(struct AdapterControlBlock *acb)
> +static void arcmsr_hbaA_flush_cache(struct AdapterControlBlock *acb)
> {
> struct MessageUnit_A __iomem *reg = acb->pmuA;
> int retry_count = 30;
> writel(ARCMSR_INBOUND_MESG0_FLUSH_CACHE, >inbound_msgaddr0);
> do {
> - if (arcmsr_hba_wait_msgint_ready(acb))
> + if (arcmsr_hbaA_wait_msgint_ready(acb))
> break;
> else {
> retry_count--;
> @@ -380,13 +381,13 @@ static void arcmsr_flush_hba_cache(struc
> }
Re: [PATCH 1/1] Drivers: scsi: storvsc: Account for in-transit packets in the RESET path
On Mon, 2012-10-08 at 15:51 +, KY Srinivasan wrote: > > > -Original Message- > > From: K. Y. Srinivasan [mailto:k...@microsoft.com] > > Sent: Tuesday, October 02, 2012 2:04 PM > > To: gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; > > de...@linuxdriverproject.org; oher...@suse.com; jbottom...@parallels.com; > > h...@infradead.org; linux-s...@vger.kernel.org > > Cc: KY Srinivasan; sta...@vger.kernel.org > > Subject: [PATCH 1/1] Drivers: scsi: storvsc: Account for in-transit packets > > in the > > RESET path > > > > Properly account for I/O in transit before returning from the RESET call. > > In the absense of this patch, we could have a situation where the host may > > respond to a command that was issued prior to the issuance of the RESET > > command at some arbitrary time after responding to the RESET command. > > Currently, the host does not do anything with the RESET command. > > > > Signed-off-by: K. Y. Srinivasan > > Cc: sta...@vger.kernel.org > > --- > > drivers/scsi/storvsc_drv.c |5 + > > 1 files changed, 5 insertions(+), 0 deletions(-) > > > > diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c > > index 528d52b..0144078 100644 > > --- a/drivers/scsi/storvsc_drv.c > > +++ b/drivers/scsi/storvsc_drv.c > > @@ -1221,7 +1221,12 @@ static int storvsc_host_reset_handler(struct > > scsi_cmnd > > *scmnd) > > /* > > * At this point, all outstanding requests in the adapter > > * should have been flushed out and return to us > > +* There is a potential race here where the host may be in > > +* the process of responding when we return from here. > > +* Just wait for all in-transit packets to be accounted for > > +* before we return from here. > > */ > > + storvsc_wait_to_drain(stor_device); > > > > return SUCCESS; > > } > > -- > > 1.7.4.1 > > James, > > This patch is critical for running Linux based workloads on our Cloud > infrastructure - Azure. > Please let me know if there are any issues. So just for next time: it's a bit hard to work out this is a critical issue from the change log. If I had to guess, I'd say the response to a command killed by reset causes some type of use after free and a potential oops (all of which would have been very nice in the change log)? James -- 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: CMA broken in next-20120926
On Tue, Oct 09, 2012 at 01:08:30PM +0200, Bartlomiej Zolnierkiewicz wrote:
> On Tuesday 09 October 2012 12:11:43 Mel Gorman wrote:
> > On Tue, Oct 09, 2012 at 10:40:10AM +0200, Bartlomiej Zolnierkiewicz wrote:
> > > I also need following patch to make CONFIG_CMA=y && CONFIG_COMPACTION=y
> > > case
> > > work:
> > >
> > > From: Bartlomiej Zolnierkiewicz
> > > Subject: [PATCH] mm: compaction: cache if a pageblock was scanned and no
> > > pages were isolated - cma fix
> > >
> > > Patch "mm: compaction: cache if a pageblock was scanned and no pages
> > > were isolated" needs a following fix to successfully boot next-20121002
> > > kernel (same with next-20121008) with CONFIG_CMA=y and CONFIG_COMPACTION=y
> > > (with applied -fix1, -fix2, -fix3 patches from Mel Gorman and also with
> > > cmatest module from Thierry Reding compiled in).
> > >
> >
> > Why is it needed to make it boot? CMA should not care about the
>
> It boots without Thierry's cmatest module but then fails on CMA
> allocation attempt (I used out-of-tree /dev/cma_test interface to
> generate CMA allocation request from user-space).
>
> > PG_migrate_skip hint being set because it should always ignore it in
> > alloc_contig_range() due to cc->ignore_skip_hint. It's not obvious to
> > me why this fixes a boot failure and I wonder if it's papering over some
> > underlying problem. Can you provide more details please?
>
> I just compared CONFIG_COMPACTION=n and =y cases initially, figured
> out the difference and did the change. However on a closer look it
> seems that {get,clear,set}_pageblock_skip() use incorrect bit ranges
> (please compare to bit ranges used by {get,set}_pageblock_flags()
> used for migration types) and can overwrite pageblock migratetype of
> the next pageblock in the bitmap (I wonder how could this code ever
> worked before?).
>
> > > Signed-off-by: Bartlomiej Zolnierkiewicz
> > > Signed-off-by: Kyungmin Park
> > > ---
> > > mm/compaction.c |3 ++-
> > > 1 file changed, 2 insertions(+), 1 deletion(-)
> > >
> > > Index: b/mm/compaction.c
> > > ===
> > > --- a/mm/compaction.c 2012-10-08 18:10:53.491679716 +0200
> > > +++ b/mm/compaction.c 2012-10-08 18:11:33.615679713 +0200
> > > @@ -117,7 +117,8 @@ static void update_pageblock_skip(struct
> > > bool migrate_scanner)
> > > {
> > > struct zone *zone = cc->zone;
> > > - if (!page)
> > > +
> > > + if (!page || cc->ignore_skip_hint)
> > > return;
> > >
> > > if (!nr_isolated) {
>
> The patch below also fixes the issue for me:
>
> From: Bartlomiej Zolnierkiewicz
> Subject: [PATCH] mm: compaction: fix bit ranges in
> {get,clear,set}_pageblock_skip()
>
> {get,clear,set}_pageblock_skip() use incorrect bit ranges (please compare
> to bit ranges used by {get,set}_pageblock_flags() used for migration types)
> and can overwrite pageblock migratetype of the next pageblock in the bitmap.
>
> Signed-off-by: Bartlomiej Zolnierkiewicz
> Signed-off-by: Kyungmin Park
> ---
> include/linux/pageblock-flags.h |6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> Index: b/include/linux/pageblock-flags.h
> ===
> --- a/include/linux/pageblock-flags.h 2012-10-09 12:50:20.366340001 +0200
> +++ b/include/linux/pageblock-flags.h 2012-10-09 12:50:31.794339996 +0200
> @@ -71,13 +71,13 @@ void set_pageblock_flags_group(struct pa
> #ifdef CONFIG_COMPACTION
> #define get_pageblock_skip(page) \
> get_pageblock_flags_group(page, PB_migrate_skip, \
> - PB_migrate_skip + 1)
> + PB_migrate_skip)
> #define clear_pageblock_skip(page) \
> set_pageblock_flags_group(page, 0, PB_migrate_skip, \
> - PB_migrate_skip + 1)
> + PB_migrate_skip)
> #define set_pageblock_skip(page) \
> set_pageblock_flags_group(page, 1, PB_migrate_skip, \
> - PB_migrate_skip + 1)
> + PB_migrate_skip)
> #endif /* CONFIG_COMPACTION */
>
> #define get_pageblock_flags(page) \
Tested-by: Thierry Reding
pgpn8EWeymIUR.pgp
Description: PGP signature
Re: [PATCH 1/1] spi:clk: preparation for switch to common clock framework
On 9/17/2012 10:12 PM, Murali Karicheri wrote: > As a first step towards migrating davinci platforms to use common clock > framework, replace all instances of clk_enable() with clk_prepare_enable() > and clk_disable() with clk_disable_unprepare(). Until the platform is > switched to use the CONFIG_HAVE_CLK_PREPARE Kconfig variable, this just > adds a might_sleep() call and would work without any issues. > > This will make it easy later to switch to common clk based implementation > of clk driver from DaVinci specific driver. > > Signed-off-by: Murali Karicheri > Reviewed-by: Mike Turquette This patch had to be applied manually and with some fuzz when I applied it to latest linus/master. There were no conflicts though and once I applied it, I was able to test SPI flash on DA850 EVM successfully using it. Acked-by: Sekhar Nori I am hoping this patch can still go in v3.7. I realize we are in the middle of the merge window though. Thanks, Sekhar -- 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: CMA broken in next-20120926
On Tue, Oct 09, 2012 at 01:08:30PM +0200, Bartlomiej Zolnierkiewicz wrote:
> On Tuesday 09 October 2012 12:11:43 Mel Gorman wrote:
> > On Tue, Oct 09, 2012 at 10:40:10AM +0200, Bartlomiej Zolnierkiewicz wrote:
> > > I also need following patch to make CONFIG_CMA=y && CONFIG_COMPACTION=y
> > > case
> > > work:
> > >
> > > From: Bartlomiej Zolnierkiewicz
> > > Subject: [PATCH] mm: compaction: cache if a pageblock was scanned and no
> > > pages were isolated - cma fix
> > >
> > > Patch "mm: compaction: cache if a pageblock was scanned and no pages
> > > were isolated" needs a following fix to successfully boot next-20121002
> > > kernel (same with next-20121008) with CONFIG_CMA=y and CONFIG_COMPACTION=y
> > > (with applied -fix1, -fix2, -fix3 patches from Mel Gorman and also with
> > > cmatest module from Thierry Reding compiled in).
> > >
> >
> > Why is it needed to make it boot? CMA should not care about the
>
> It boots without Thierry's cmatest module but then fails on CMA
> allocation attempt (I used out-of-tree /dev/cma_test interface to
> generate CMA allocation request from user-space).
>
I see.
> > PG_migrate_skip hint being set because it should always ignore it in
> > alloc_contig_range() due to cc->ignore_skip_hint. It's not obvious to
> > me why this fixes a boot failure and I wonder if it's papering over some
> > underlying problem. Can you provide more details please?
>
> I just compared CONFIG_COMPACTION=n and =y cases initially, figured
> out the difference and did the change. However on a closer look it
> seems that {get,clear,set}_pageblock_skip() use incorrect bit ranges
> (please compare to bit ranges used by {get,set}_pageblock_flags()
> used for migration types) and can overwrite pageblock migratetype of
> the next pageblock in the bitmap
You're right.
> (I wonder how could this code ever
> worked before?).
>
Because it would corrupt the adjacent block and muck up the migratetype.
This would hurt fragmentation avoidance but it would not be obvious for
a long time. When I was checking this, I only checked that the values of
the block being set were correct, I missed that I was corrupting the
adjacent blocks.
> > > Signed-off-by: Bartlomiej Zolnierkiewicz
> > > Signed-off-by: Kyungmin Park
> > > ---
> > > mm/compaction.c |3 ++-
> > > 1 file changed, 2 insertions(+), 1 deletion(-)
> > >
> > > Index: b/mm/compaction.c
> > > ===
> > > --- a/mm/compaction.c 2012-10-08 18:10:53.491679716 +0200
> > > +++ b/mm/compaction.c 2012-10-08 18:11:33.615679713 +0200
> > > @@ -117,7 +117,8 @@ static void update_pageblock_skip(struct
> > > bool migrate_scanner)
> > > {
> > > struct zone *zone = cc->zone;
> > > - if (!page)
> > > +
> > > + if (!page || cc->ignore_skip_hint)
> > > return;
> > >
> > > if (!nr_isolated) {
>
> The patch below also fixes the issue for me:
>
> From: Bartlomiej Zolnierkiewicz
> Subject: [PATCH] mm: compaction: fix bit ranges in
> {get,clear,set}_pageblock_skip()
>
> {get,clear,set}_pageblock_skip() use incorrect bit ranges (please compare
> to bit ranges used by {get,set}_pageblock_flags() used for migration types)
> and can overwrite pageblock migratetype of the next pageblock in the bitmap.
>
> Signed-off-by: Bartlomiej Zolnierkiewicz
> Signed-off-by: Kyungmin Park
Acked-by: Mel Gorman
Can you resend this patch on its own to Andrew asking for it to be picked
up please? This thread is quite long and could easily get lost in the
noise. Thanks
--
Mel Gorman
SUSE Labs
--
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/
[REPOST] RFC: sched: Prevent wakeup to enter critical section needlessly
Check the waitqueue task list to be non empty before entering the critical
section. This prevents locking the spin lock needlessly in case the queue
was empty, and therefor also prevent scheduling overhead on a PREEMPT_RT
system.
Signed-off-by: Ivo Sieben
---
REPOST:
Request for comments:
- Does this make any sense?
- I assume that I can safely use the list_empty_careful() function here, but is
that correct?
Background to this patch:
Testing on a PREEMPT_RT system with TTY serial communication. Each time the TTY
line discipline is dereferenced the Idle handling wait queue is woken up (see
function put_ldisc in /drivers/tty/tty_ldisc.c)
However line discipline idle handling is not used very often so the wait queue
is empty most of the time. But still the wake_up() function enters the critical
section guarded by spin locks. This causes additional scheduling overhead when
a lower priority thread has control of that same lock.
kernel/sched/core.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index c177472..c1667c4 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -3090,9 +3090,19 @@ void __wake_up(wait_queue_head_t *q, unsigned int mode,
{
unsigned long flags;
- spin_lock_irqsave(>lock, flags);
- __wake_up_common(q, mode, nr_exclusive, 0, key);
- spin_unlock_irqrestore(>lock, flags);
+ /*
+* We can check for list emptiness outside the lock by using the
+* "careful" check that verifies both the next and prev pointers, so
+* that there cannot be any half-pending updates in progress.
+*
+* This prevents the wake up to enter the critical section needlessly
+* when the task list is empty.
+*/
+ if (!list_empty_careful(>task_list)) {
+ spin_lock_irqsave(>lock, flags);
+ __wake_up_common(q, mode, nr_exclusive, 0, key);
+ spin_unlock_irqrestore(>lock, flags);
+ }
}
EXPORT_SYMBOL(__wake_up);
--
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: [3.6-rc7] switcheroo race with Intel HDA...
On 9 October 2012 18:07, Takashi Iwai wrote: > At Tue, 09 Oct 2012 12:04:08 +0200, > Takashi Iwai wrote: >> >> At Tue, 9 Oct 2012 00:34:09 +0800, >> Daniel J Blueman wrote: >> > >> > On 8 October 2012 20:58, Takashi Iwai wrote: >> > > At Tue, 25 Sep 2012 13:20:05 +0800, >> > > Daniel J Blueman wrote: >> > >> On my Macbook with a discrete Nvidia GPU, there is a race between >> > >> selecting the integrated GPU and putting the discrete GPU into D3 [1], >> > >> reliably causing a kernel oops [2]. >> > >> >> > >> Introducing a delay of ~1s between the calls prevents this. When the >> > >> second 'OFF' write path executes, it looks like struct azx at >> > >> card->private_data hasn't yet been allocated yet [3], so there is >> > >> likely some locking missing. >> > > >> > > It's rather pci_get_drvdata() returning NULL (i.e. card is NULL, thus >> > > card->private_data causes Oops). Could you check the patch like below >> > > and see whether you get a kernel warning (but no Oops) or the problem >> > > gets fixed by shifting the assignment of pci drvdata? >> > [...] >> > >> > Good patching. Calling pci_set_drvdata later prevents the oops in HDA, >> > though we see unexpected 0x0 responses in the response ring buffer >> > [1], which we don't see when there's a >~1.5s delay between IGD and >> > OFF. >> >> If the previous patch fixed, it means that the switching occurred >> during the device was being probed. Maybe a better approach to >> register the VGA switcheroo after the proper initialization. >> >> The patch below is a revised one. Please give it a try. > > Also, it's not clear which card spews the spurious response. > Apply the patch below in addition. [...] hda-intel: :01:00.1: spurious response 0x0:0x0, last cmd=0x1f0004 $ lspci -s :1:0.1 01:00.1 Audio device: NVIDIA Corporation Device 0e1b (rev ff) It's the NVIDIA device which presumably hasn't completed it's transition to D3 at the time the OFF is executed. Thanks, Daniel -- Daniel J Blueman -- 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/4] regulator: tps65090: add external control support for DCDC
On Tuesday 09 October 2012 03:32 PM, Laxman Dewangan wrote:
On Tuesday 09 October 2012 04:03 PM, Venu Byravarasu wrote:
+static struct regulator_ops tps65090_ext_control_ops = {
+};
What is the purpose of adding empty structure?
We will not able to register regulator if there is no ops.
In regulator register:
if (regulator_desc->name == NULL || regulator_desc->ops == NULL)
return ERR_PTR(-EINVAL);
If tps65090_ops would be left as is, without renaming it, hope this empty
structure can be removed.
--
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: CMA broken in next-20120926
On Tuesday 09 October 2012 12:11:43 Mel Gorman wrote:
> On Tue, Oct 09, 2012 at 10:40:10AM +0200, Bartlomiej Zolnierkiewicz wrote:
> > I also need following patch to make CONFIG_CMA=y && CONFIG_COMPACTION=y case
> > work:
> >
> > From: Bartlomiej Zolnierkiewicz
> > Subject: [PATCH] mm: compaction: cache if a pageblock was scanned and no
> > pages were isolated - cma fix
> >
> > Patch "mm: compaction: cache if a pageblock was scanned and no pages
> > were isolated" needs a following fix to successfully boot next-20121002
> > kernel (same with next-20121008) with CONFIG_CMA=y and CONFIG_COMPACTION=y
> > (with applied -fix1, -fix2, -fix3 patches from Mel Gorman and also with
> > cmatest module from Thierry Reding compiled in).
> >
>
> Why is it needed to make it boot? CMA should not care about the
It boots without Thierry's cmatest module but then fails on CMA
allocation attempt (I used out-of-tree /dev/cma_test interface to
generate CMA allocation request from user-space).
> PG_migrate_skip hint being set because it should always ignore it in
> alloc_contig_range() due to cc->ignore_skip_hint. It's not obvious to
> me why this fixes a boot failure and I wonder if it's papering over some
> underlying problem. Can you provide more details please?
I just compared CONFIG_COMPACTION=n and =y cases initially, figured
out the difference and did the change. However on a closer look it
seems that {get,clear,set}_pageblock_skip() use incorrect bit ranges
(please compare to bit ranges used by {get,set}_pageblock_flags()
used for migration types) and can overwrite pageblock migratetype of
the next pageblock in the bitmap (I wonder how could this code ever
worked before?).
> > Signed-off-by: Bartlomiej Zolnierkiewicz
> > Signed-off-by: Kyungmin Park
> > ---
> > mm/compaction.c |3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > Index: b/mm/compaction.c
> > ===
> > --- a/mm/compaction.c 2012-10-08 18:10:53.491679716 +0200
> > +++ b/mm/compaction.c 2012-10-08 18:11:33.615679713 +0200
> > @@ -117,7 +117,8 @@ static void update_pageblock_skip(struct
> > bool migrate_scanner)
> > {
> > struct zone *zone = cc->zone;
> > - if (!page)
> > +
> > + if (!page || cc->ignore_skip_hint)
> > return;
> >
> > if (!nr_isolated) {
The patch below also fixes the issue for me:
From: Bartlomiej Zolnierkiewicz
Subject: [PATCH] mm: compaction: fix bit ranges in
{get,clear,set}_pageblock_skip()
{get,clear,set}_pageblock_skip() use incorrect bit ranges (please compare
to bit ranges used by {get,set}_pageblock_flags() used for migration types)
and can overwrite pageblock migratetype of the next pageblock in the bitmap.
Signed-off-by: Bartlomiej Zolnierkiewicz
Signed-off-by: Kyungmin Park
---
include/linux/pageblock-flags.h |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
Index: b/include/linux/pageblock-flags.h
===
--- a/include/linux/pageblock-flags.h 2012-10-09 12:50:20.366340001 +0200
+++ b/include/linux/pageblock-flags.h 2012-10-09 12:50:31.794339996 +0200
@@ -71,13 +71,13 @@ void set_pageblock_flags_group(struct pa
#ifdef CONFIG_COMPACTION
#define get_pageblock_skip(page) \
get_pageblock_flags_group(page, PB_migrate_skip, \
- PB_migrate_skip + 1)
+ PB_migrate_skip)
#define clear_pageblock_skip(page) \
set_pageblock_flags_group(page, 0, PB_migrate_skip, \
- PB_migrate_skip + 1)
+ PB_migrate_skip)
#define set_pageblock_skip(page) \
set_pageblock_flags_group(page, 1, PB_migrate_skip, \
- PB_migrate_skip + 1)
+ PB_migrate_skip)
#endif /* CONFIG_COMPACTION */
#define get_pageblock_flags(page) \
--
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] mm: Fix XFS oops due to dirty pages without buffers on s390
On Mon, 8 Oct 2012 21:24:40 -0700 (PDT)
Hugh Dickins wrote:
> On Mon, 1 Oct 2012, Jan Kara wrote:
>
> > On s390 any write to a page (even from kernel itself) sets architecture
> > specific page dirty bit. Thus when a page is written to via standard write,
> > HW
> > dirty bit gets set and when we later map and unmap the page,
> > page_remove_rmap()
> > finds the dirty bit and calls set_page_dirty().
> >
> > Dirtying of a page which shouldn't be dirty can cause all sorts of problems
> > to
> > filesystems. The bug we observed in practice is that buffers from the page
> > get
> > freed, so when the page gets later marked as dirty and writeback writes it,
> > XFS
> > crashes due to an assertion BUG_ON(!PagePrivate(page)) in page_buffers()
> > called
> > from xfs_count_page_state().
>
> What changed recently? Was XFS hardly used on s390 until now?
One thing that changed is that the zero_user_segment for the remaining bytes
between
i_size and the end of the page has been moved to block_write_full_page_endio,
see
git commit eebd2aa355692afa. That changed the timing of the race window in
regard
to map/unmap of the page by user space. And yes XFS is in use on s390.
> >
> > Similar problem can also happen when zero_user_segment() call from
> > xfs_vm_writepage() (or block_write_full_page() for that matter) set the
> > hardware dirty bit during writeback, later buffers get freed, and then page
> > unmapped.
> >
> > Fix the issue by ignoring s390 HW dirty bit for page cache pages in
> > page_mkclean() and page_remove_rmap(). This is safe because when a page gets
> > marked as writeable in PTE it is also marked dirty in do_wp_page() or
> > do_page_fault(). When the dirty bit is cleared by clear_page_dirty_for_io(),
> > the page gets writeprotected in page_mkclean(). So pagecache page is
> > writeable
> > if and only if it is dirty.
>
> Very interesting patch...
Yes, it is an interesting idea. I really like the part that we'll use less
storage
key operations, as these are freaking expensive.
> >
> > CC: Martin Schwidefsky
>
> which I'd very much like Martin's opinion on...
Until you pointed out the short-comings of the patch I really liked it ..
> > ---
> > mm/rmap.c | 16 ++--
> > 1 files changed, 14 insertions(+), 2 deletions(-)
> >
> > diff --git a/mm/rmap.c b/mm/rmap.c
> > index 0f3b7cd..6ce8ddb 100644
> > --- a/mm/rmap.c
> > +++ b/mm/rmap.c
> > @@ -973,7 +973,15 @@ int page_mkclean(struct page *page)
> > struct address_space *mapping = page_mapping(page);
> > if (mapping) {
> > ret = page_mkclean_file(mapping, page);
> > - if (page_test_and_clear_dirty(page_to_pfn(page), 1))
> > + /*
> > +* We ignore dirty bit for pagecache pages. It is safe
> > +* as page is marked dirty iff it is writeable (page is
> > +* marked as dirty when it is made writeable and
> > +* clear_page_dirty_for_io() writeprotects the page
> > +* again).
> > +*/
> > + if (PageSwapCache(page) &&
> > + page_test_and_clear_dirty(page_to_pfn(page), 1))
> > ret = 1;
>
> This part you could cut out: page_mkclean() is not used on SwapCache pages.
> I believe you are safe to remove the page_test_and_clear_dirty() from here.
Hmm, who guarantees that page_mkclean won't be used for SwapCache in the
future? At least we should add a comment there.
> > }
> > }
> > @@ -1183,8 +1191,12 @@ void page_remove_rmap(struct page *page)
> > * this if the page is anon, so about to be freed; but perhaps
> > * not if it's in swapcache - there might be another pte slot
> > * containing the swap entry, but page not yet written to swap.
> > +* For pagecache pages, we don't care about dirty bit in storage
> > +* key because the page is writeable iff it is dirty (page is marked
> > +* as dirty when it is made writeable and clear_page_dirty_for_io()
> > +* writeprotects the page again).
> > */
> > - if ((!anon || PageSwapCache(page)) &&
> > + if (PageSwapCache(page) &&
> > page_test_and_clear_dirty(page_to_pfn(page), 1))
> > set_page_dirty(page);
>
> But here's where I think the problem is. You're assuming that all
> filesystems go the same mapping_cap_account_writeback_dirty() (yeah,
> there's no such function, just a confusing maze of three) route as XFS.
>
> But filesystems like tmpfs and ramfs (perhaps they're the only two
> that matter here) don't participate in that, and wait for an mmap'ed
> page to be seen modified by the user (usually via pte_dirty, but that's
> a no-op on s390) before page is marked dirty; and page reclaim throws
> away undirtied pages.
>
> So, if I'm understanding right, with this change s390 would be in danger
> of discarding shm, and mmap'ed tmpfs and ramfs
Re: [PATCH] ntp, add debugfs entries for time_status and time_state
On 10/08/2012 09:47 PM, John Stultz wrote: > On 10/04/2012 06:48 AM, Prarit Bhargava wrote: >> Add debugfs entries for ntp time_status and time_state. These are useful >> for debugging ntp issues. > Aren't these easily fetched from adjtimex()? How does having them in debugfs > help? > They are, however, there have been circumstances in the past when I've been monitoring things from kernel-side that I've found it useful to have them in debugfs. P. > thanks > -john > -- 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] task_work: avoid unneeded cmpxchg() in task_work_run()
On Mon, 2012-10-08 at 14:38 +0200, Oleg Nesterov wrote: > But the code looks more complex, and the only advantage is that > non-exiting task does xchg() instead of cmpxchg(). Not sure this > worth the trouble, in this case task_work_run() will likey run > the callbacks (the caller checks ->task_works != NULL), I do not > think this can add any noticeable speedup. Yeah, I agree, the patch doesn't seem worth the trouble. It makes tricky code unreadable at best. -- 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: CMA broken in next-20120926
On Tue, Oct 09, 2012 at 11:11:43AM +0100, Mel Gorman wrote: > On Tue, Oct 09, 2012 at 10:40:10AM +0200, Bartlomiej Zolnierkiewicz wrote: > > I also need following patch to make CONFIG_CMA=y && CONFIG_COMPACTION=y case > > work: > > > > From: Bartlomiej Zolnierkiewicz > > Subject: [PATCH] mm: compaction: cache if a pageblock was scanned and no > > pages were isolated - cma fix > > > > Patch "mm: compaction: cache if a pageblock was scanned and no pages > > were isolated" needs a following fix to successfully boot next-20121002 > > kernel (same with next-20121008) with CONFIG_CMA=y and CONFIG_COMPACTION=y > > (with applied -fix1, -fix2, -fix3 patches from Mel Gorman and also with > > cmatest module from Thierry Reding compiled in). > > > > Why is it needed to make it boot? CMA should not care about the > PG_migrate_skip hint being set because it should always ignore it in > alloc_contig_range() due to cc->ignore_skip_hint. It's not obvious to > me why this fixes a boot failure and I wonder if it's papering over some > underlying problem. Can you provide more details please? I can confirm that on top of next-20121009 this fixes all the remaining issues with CMA that I've been seeing. By the way, would it be useful to add the CMA test module to the mainline tree as a tool to test for this kind of regressions? It could probably be enhanced to perform more checks or use random allocation sizes for better coverage. Thierry pgpcriYCv54RN.pgp Description: PGP signature
RE: [PATCH 00/16] f2fs: introduce flash-friendly file system
On Tue, 9 Oct 2012, Jaegeuk Kim wrote: > Date: Tue, 09 Oct 2012 19:45:57 +0900 > From: Jaegeuk Kim > To: 'Lukáš Czerner' > Cc: 'Namjae Jeon' , > 'Vyacheslav Dubeyko' , > 'Marco Stornelli' , > 'Jaegeuk Kim' , > 'Al Viro' , ty...@mit.edu, > gre...@linuxfoundation.org, linux-kernel@vger.kernel.org, > chur@samsung.com, cm224@samsung.com, jooyoung.hw...@samsung.com, > linux-fsde...@vger.kernel.org > Subject: RE: [PATCH 00/16] f2fs: introduce flash-friendly file system > > > -Original Message- > > From: linux-fsdevel-ow...@vger.kernel.org > > [mailto:linux-fsdevel-ow...@vger.kernel.org] On Behalf Of > > Luka? Czerner > > Sent: Tuesday, October 09, 2012 5:32 PM > > To: Jaegeuk Kim > > Cc: 'Namjae Jeon'; 'Vyacheslav Dubeyko'; 'Marco Stornelli'; 'Jaegeuk Kim'; > > 'Al Viro'; ty...@mit.edu; > > gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; > > chur@samsung.com; cm224@samsung.com; > > jooyoung.hw...@samsung.com; linux-fsde...@vger.kernel.org > > Subject: RE: [PATCH 00/16] f2fs: introduce flash-friendly file system > > > > On Mon, 8 Oct 2012, Jaegeuk Kim wrote: > > > > > Date: Mon, 08 Oct 2012 19:52:03 +0900 > > > From: Jaegeuk Kim > > > To: 'Namjae Jeon' > > > Cc: 'Vyacheslav Dubeyko' , > > > 'Marco Stornelli' , > > > 'Jaegeuk Kim' , > > > 'Al Viro' , ty...@mit.edu, > > > gre...@linuxfoundation.org, linux-kernel@vger.kernel.org, > > > chur@samsung.com, cm224@samsung.com, > > > jooyoung.hw...@samsung.com, > > > linux-fsde...@vger.kernel.org > > > Subject: RE: [PATCH 00/16] f2fs: introduce flash-friendly file system > > > > > > > -Original Message- > > > > From: Namjae Jeon [mailto:linkinj...@gmail.com] > > > > Sent: Monday, October 08, 2012 7:00 PM > > > > To: Jaegeuk Kim > > > > Cc: Vyacheslav Dubeyko; Marco Stornelli; Jaegeuk Kim; Al Viro; > > > > ty...@mit.edu; > > > > gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; > > > > chur@samsung.com; > > cm224@samsung.com; > > > > jooyoung.hw...@samsung.com; linux-fsde...@vger.kernel.org > > > > Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file system > > > > > > > > 2012/10/8, Jaegeuk Kim : > > > > >> -Original Message- > > > > >> From: Vyacheslav Dubeyko [mailto:sl...@dubeyko.com] > > > > >> Sent: Sunday, October 07, 2012 9:09 PM > > > > >> To: Jaegeuk Kim > > > > >> Cc: 'Marco Stornelli'; 'Jaegeuk Kim'; 'Al Viro'; ty...@mit.edu; > > > > >> gre...@linuxfoundation.org; linux- > > > > >> ker...@vger.kernel.org; chur@samsung.com; cm224@samsung.com; > > > > >> jooyoung.hw...@samsung.com; > > > > >> linux-fsde...@vger.kernel.org > > > > >> Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file system > > > > >> > > > > >> Hi, > > > > >> > > > > >> On Oct 7, 2012, at 1:31 PM, Jaegeuk Kim wrote: > > > > >> > > > > >> >> -Original Message- > > > > >> >> From: Marco Stornelli [mailto:marco.storne...@gmail.com] > > > > >> >> Sent: Sunday, October 07, 2012 4:10 PM > > > > >> >> To: Jaegeuk Kim > > > > >> >> Cc: Vyacheslav Dubeyko; jaegeuk@samsung.com; Al Viro; > > > > >> >> ty...@mit.edu; gre...@linuxfoundation.org; > > > > >> >> linux-kernel@vger.kernel.org; chur@samsung.com; > > > > >> >> cm224@samsung.com; > > > > >> jooyoung.hw...@samsung.com; > > > > >> >> linux-fsde...@vger.kernel.org > > > > >> >> Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file > > > > >> >> system > > > > >> >> > > > > >> >> Il 06/10/2012 22:06, Jaegeuk Kim ha scritto: > > > > >> >>> 2012-10-06 (토), 17:54 +0400, Vyacheslav Dubeyko: > > > > >> Hi Jaegeuk, > > > > >> >>> > > > > >> >>> Hi. > > > > >> >>> We know each other, right? :) > > > > >> >>> > > > > >> > > > > >> > From: 김재극 > > > > >> > To:v...@zeniv.linux.org.uk, 'Theodore Ts'o' > > > > >> > , > > > > >> >> gre...@linuxfoundation.org, linux-kernel@vger.kernel.org, > > > > >> >> chur@samsung.com, > > > > >> cm224@samsung.com, > > > > >> >> jaegeuk@samsung.com, jooyoung.hw...@samsung.com > > > > >> > Subject: [PATCH 00/16] f2fs: introduce > > > > >> > flash-friendly file system > > > > >> > Date: Fri, 05 Oct 2012 20:55:07 +0900 > > > > >> > > > > > >> > This is a new patch set for the f2fs file system. > > > > >> > > > > > >> > What is F2FS? > > > > >> > = > > > > >> > > > > > >> > NAND flash memory-based storage devices, such as SSD, eMMC, > > > > >> > and SD > > > > >> > cards, have > > > > >> > been widely being used for ranging from mobile to server > > > > >> > systems. > > > > >> > Since they are > > > > >> > known to have different characteristics from the conventional > > > > >> > rotational disks, > > > > >> > a file system, an upper layer to the storage device, should > > > > >> > adapt to > > > > >> > the changes > > > > >> > from the sketch. > > > > >> >
Re: [PATCH] Do not use cpu_to_node() to find an offlined cpu's node.
On Mon, 2012-10-08 at 10:59 +0800, Tang Chen wrote: > If a cpu is offline, its nid will be set to -1, and cpu_to_node(cpu) will > return -1. As a result, cpumask_of_node(nid) will return NULL. In this case, > find_next_bit() in for_each_cpu will get a NULL pointer and cause panic. Hurm,. this is new, right? Who is changing all these semantics without auditing the tree and informing all affected people? -- 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: [GIT PULL] Asymmetric keys and module signing
On Thu, Oct 4, 2012 at 2:22 AM, Rusty Russell wrote: > David Howells writes: > >> Rusty Russell wrote: >> >>> Right. I think we need to use different names for generated vs supplied >>> files >> >> The problem with supplied files is people who do allyesconfig, allmodconfig >> and randconfig just to test things finding that their builds break. The >> kernel build magic is not really set up to handle external files like this. >> I >> suppose make logic can be used to conditionally include stuff that might not >> exist. >> >>> BTW, you missed a Signed-off-by: on your "MODSIGN: Use the same digest >>> for the autogen key sig as for the module sig" patch. Please update. >> >> Done. >> >> I've also added a patch to convert the system clock to a struct tm and to >> produce a struct tm within the ASN.1 decode and then compare those rather >> than >> time_t values as a way to deal with the validity time overflow problem. We >> may have to be able to handle certificates that we haven't generated that >> stretch beyond 2038 (I wonder if we might find such in the UEFI key database >> for example. > > OK, cherry-picked to replace my hack. > > It's in linux-next, and I will push in the next two days. > http://git.kernel.org/?p=linux/kernel/git/rusty/linux.git;a=commit;h=a15e196c5543d1d2d7f0cd70e62351aeb1f8b871 It breaks bisect.. CC kernel/module_signing.o kernel/module_signing.c: In function ‘mod_verify_sig’: kernel/module_signing.c:21:10: error: ‘ENOKEY’ undeclared (first use in this function) kernel/module_signing.c:21:10: note: each undeclared identifier is reported only once for each function it appears in kernel/module_signing.c:22:1: warning: control reaches end of non-void function [-Wreturn-type] make[1]: *** [kernel/module_signing.o] Error 1 make: *** [kernel] Error 2 make: *** Waiting for unfinished jobs > Thanks, > Rusty. > -- > To unsubscribe from this list: send the line "unsubscribe linux-crypto" 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 v2 2/7] Regulator: DA9055 Regulator driver
On Tue, 2012-10-09 at 15:37 +0530, Mark Brown wrote:
> On Mon, Oct 08, 2012 at 07:00:39PM +0530, Ashish Jangam wrote:
>
> Mostly OK, but there's a few issues including yet more reimplementation
> of framework features.
>
> > +static int da9055_list_voltage(struct regulator_dev *rdev,
> > + unsigned int selector)
> > +{
> > + struct da9055_regulator *regulator = rdev_get_drvdata(rdev);
> > + struct da9055_regulator_info *info = regulator->info;
> > + int volt_uV;
> > +
> > + volt_uV = (selector * info->step_uV) + info->min_uV;
> > +
> > + if (volt_uV > info->max_uV)
> > + return -EINVAL;
> > +
> > + return volt_uV;
> > +}
>
> This is regulator_list_voltage_linear()
Agree.
>
> > +static int da9055_map_voltage(struct regulator_dev *rdev,
> > + int min_uV, int max_uV)
> > +{
> > + struct da9055_regulator *regulator = rdev_get_drvdata(rdev);
> > + struct da9055_regulator_info *info = regulator->info;
> > + int ret, sel;
> > +
> > + ret = verify_range(info, min_uV, max_uV);
> > + if (ret < 0)
> > + return ret;
> > +
> > + if (min_uV < info->min_uV)
> > + min_uV = info->min_uV;
> > +
> > + sel = DIV_ROUND_UP(min_uV - info->min_uV, info->step_uV);
> > +
> > + ret = da9055_list_voltage(rdev, sel);
> > + if (ret < 0)
> > + return ret;
> > +
> > + return sel;
> > +}
>
> This is regulator_map_voltage_linear().
Agree.
>
> > + int gpio = pdata->gpio_base + pdata->gpio_ren[id];
>
> > + sprintf(name, "DA9055 REG %d STATE", id);
>
> snprintf().
>
> > + /* Set the GPIO I/P pin for controlling the regulator state. */
> > + ret = devm_gpio_request_one(config->dev, gpio, GPIOF_DIR_IN,
> > + name);
> > + if (ret < 0)
> > + goto err;
>
> We never actually appear to use this GPIO anywhere... why are we
> requesting it?
DA9055 regulator changes its state by detecting the rising/failing edge at
GPI DA9055. Therefore we just need to set the DA9055 GPIO direction to input.
> Also, why is the ability to read the regulator state via
> a GPIO associated with controlling it via a GPIO, it's unusual for these
> things to be tied together.
>
There is no connection between state just to differentiate between two
strings/labels.
If required I can change the string.
--
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 00/16] f2fs: introduce flash-friendly file system
> -Original Message- > From: linux-fsdevel-ow...@vger.kernel.org > [mailto:linux-fsdevel-ow...@vger.kernel.org] On Behalf Of > Luka? Czerner > Sent: Tuesday, October 09, 2012 5:32 PM > To: Jaegeuk Kim > Cc: 'Namjae Jeon'; 'Vyacheslav Dubeyko'; 'Marco Stornelli'; 'Jaegeuk Kim'; > 'Al Viro'; ty...@mit.edu; > gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; > chur@samsung.com; cm224@samsung.com; > jooyoung.hw...@samsung.com; linux-fsde...@vger.kernel.org > Subject: RE: [PATCH 00/16] f2fs: introduce flash-friendly file system > > On Mon, 8 Oct 2012, Jaegeuk Kim wrote: > > > Date: Mon, 08 Oct 2012 19:52:03 +0900 > > From: Jaegeuk Kim > > To: 'Namjae Jeon' > > Cc: 'Vyacheslav Dubeyko' , > > 'Marco Stornelli' , > > 'Jaegeuk Kim' , > > 'Al Viro' , ty...@mit.edu, > > gre...@linuxfoundation.org, linux-kernel@vger.kernel.org, > > chur@samsung.com, cm224@samsung.com, jooyoung.hw...@samsung.com, > > linux-fsde...@vger.kernel.org > > Subject: RE: [PATCH 00/16] f2fs: introduce flash-friendly file system > > > > > -Original Message- > > > From: Namjae Jeon [mailto:linkinj...@gmail.com] > > > Sent: Monday, October 08, 2012 7:00 PM > > > To: Jaegeuk Kim > > > Cc: Vyacheslav Dubeyko; Marco Stornelli; Jaegeuk Kim; Al Viro; > > > ty...@mit.edu; > > > gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; > > > chur@samsung.com; > cm224@samsung.com; > > > jooyoung.hw...@samsung.com; linux-fsde...@vger.kernel.org > > > Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file system > > > > > > 2012/10/8, Jaegeuk Kim : > > > >> -Original Message- > > > >> From: Vyacheslav Dubeyko [mailto:sl...@dubeyko.com] > > > >> Sent: Sunday, October 07, 2012 9:09 PM > > > >> To: Jaegeuk Kim > > > >> Cc: 'Marco Stornelli'; 'Jaegeuk Kim'; 'Al Viro'; ty...@mit.edu; > > > >> gre...@linuxfoundation.org; linux- > > > >> ker...@vger.kernel.org; chur@samsung.com; cm224@samsung.com; > > > >> jooyoung.hw...@samsung.com; > > > >> linux-fsde...@vger.kernel.org > > > >> Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file system > > > >> > > > >> Hi, > > > >> > > > >> On Oct 7, 2012, at 1:31 PM, Jaegeuk Kim wrote: > > > >> > > > >> >> -Original Message- > > > >> >> From: Marco Stornelli [mailto:marco.storne...@gmail.com] > > > >> >> Sent: Sunday, October 07, 2012 4:10 PM > > > >> >> To: Jaegeuk Kim > > > >> >> Cc: Vyacheslav Dubeyko; jaegeuk@samsung.com; Al Viro; > > > >> >> ty...@mit.edu; gre...@linuxfoundation.org; > > > >> >> linux-kernel@vger.kernel.org; chur@samsung.com; > > > >> >> cm224@samsung.com; > > > >> jooyoung.hw...@samsung.com; > > > >> >> linux-fsde...@vger.kernel.org > > > >> >> Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file > > > >> >> system > > > >> >> > > > >> >> Il 06/10/2012 22:06, Jaegeuk Kim ha scritto: > > > >> >>> 2012-10-06 (토), 17:54 +0400, Vyacheslav Dubeyko: > > > >> Hi Jaegeuk, > > > >> >>> > > > >> >>> Hi. > > > >> >>> We know each other, right? :) > > > >> >>> > > > >> > > > >> > From:김재극 > > > >> > To: v...@zeniv.linux.org.uk, 'Theodore Ts'o' > > > >> > , > > > >> >> gre...@linuxfoundation.org, linux-kernel@vger.kernel.org, > > > >> >> chur@samsung.com, > > > >> cm224@samsung.com, > > > >> >> jaegeuk@samsung.com, jooyoung.hw...@samsung.com > > > >> > Subject: [PATCH 00/16] f2fs: introduce flash-friendly > > > >> > file system > > > >> > Date:Fri, 05 Oct 2012 20:55:07 +0900 > > > >> > > > > >> > This is a new patch set for the f2fs file system. > > > >> > > > > >> > What is F2FS? > > > >> > = > > > >> > > > > >> > NAND flash memory-based storage devices, such as SSD, eMMC, and > > > >> > SD > > > >> > cards, have > > > >> > been widely being used for ranging from mobile to server systems. > > > >> > Since they are > > > >> > known to have different characteristics from the conventional > > > >> > rotational disks, > > > >> > a file system, an upper layer to the storage device, should > > > >> > adapt to > > > >> > the changes > > > >> > from the sketch. > > > >> > > > > >> > F2FS is a new file system carefully designed for the NAND flash > > > >> > memory-based storage > > > >> > devices. We chose a log structure file system approach, but we > > > >> > tried > > > >> > to adapt it > > > >> > to the new form of storage. Also we remedy some known issues of > > > >> > the > > > >> > very old log > > > >> > structured file system, such as snowball effect of wandering tree > > > >> > and high cleaning > > > >> > overhead. > > > >> > > > > >> > Because a NAND-based storage device shows different > > > >> > characteristics > > > >> > according to > > > >> > its internal geometry or flash memory management scheme aka FTL, > > > >>
Re: [PATCH V2 4/4] regulator: tps65090: add external control support for DCDC
On Tuesday 09 October 2012 04:03 PM, Venu Byravarasu wrote:
+static struct regulator_ops tps65090_ext_control_ops = {
+};
What is the purpose of adding empty structure?
We will not able to register regulator if there is no ops.
In regulator register:
if (regulator_desc->name == NULL || regulator_desc->ops == NULL)
return ERR_PTR(-EINVAL);
--
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/4] regulator: tps65090: add external control support for DCDC
On Tue, Oct 09, 2012 at 04:03:19PM +0530, Venu Byravarasu wrote: > > -Original Message- > > From: Laxman Dewangan > > Sent: Tuesday, October 09, 2012 3:19 PM Please, when replying to mails delete irrelevant text - only quote the bits of text you're replying to. This is very helpful to people reading your reply, it makes it much easier to find the new text especially for people on mobile devices. -- 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/4] regulator: tps65090: add external control support for DCDC
> -Original Message-
> From: Laxman Dewangan
> Sent: Tuesday, October 09, 2012 3:19 PM
> To: broo...@opensource.wolfsonmicro.com; l...@ti.com
> Cc: sa...@linux.intel.com; Venu Byravarasu; linux-kernel@vger.kernel.org;
> Laxman Dewangan
> Subject: [PATCH V2 4/4] regulator: tps65090: add external control support for
> DCDC
>
> The TPS65090's DCDC output can also be enable/disable through the
> external digital input signal. Add support for enable/disable
> either through register access via I2C or through external
> control inputs. The external control inputs can be driven through
> GPIOs also and hence adding support for passing the GPIO number.
>
> Signed-off-by: Laxman Dewangan
> ---
> Changes from V1:
> Simplify external control implemetation.
>
> -static struct regulator_ops tps65090_ops = {
> - .enable = regulator_enable_regmap,
> - .disable = regulator_disable_regmap,
> - .is_enabled = regulator_is_enabled_regmap,
> +static struct regulator_ops tps65090_ext_control_ops = {
> +};
What is the purpose of adding empty structure?
> +
> +static struct regulator_ops tps65090_reg_contol_ops = {
> + .enable = regulator_enable_regmap,
> + .disable= regulator_disable_regmap,
> + .is_enabled = regulator_is_enabled_regmap,
> };
>
> static struct regulator_ops tps65090_ldo_ops = {
> @@ -53,16 +57,16 @@ static struct regulator_ops tps65090_ldo_ops = {
> }
>
> static struct regulator_desc tps65090_regulator_desc[] = {
> - tps65090_REG_DESC(DCDC1, "vsys1", 0x0C, tps65090_ops),
> - tps65090_REG_DESC(DCDC2, "vsys2", 0x0D, tps65090_ops),
> - tps65090_REG_DESC(DCDC3, "vsys3", 0x0E, tps65090_ops),
> - tps65090_REG_DESC(FET1, "infet1", 0x0F, tps65090_ops),
> - tps65090_REG_DESC(FET2, "infet2", 0x10, tps65090_ops),
> - tps65090_REG_DESC(FET3, "infet3", 0x11, tps65090_ops),
> - tps65090_REG_DESC(FET4, "infet4", 0x12, tps65090_ops),
> - tps65090_REG_DESC(FET5, "infet5", 0x13, tps65090_ops),
> - tps65090_REG_DESC(FET6, "infet6", 0x14, tps65090_ops),
> - tps65090_REG_DESC(FET7, "infet7", 0x15, tps65090_ops),
> + tps65090_REG_DESC(DCDC1, "vsys1", 0x0C,
> tps65090_reg_contol_ops),
> + tps65090_REG_DESC(DCDC2, "vsys2", 0x0D,
> tps65090_reg_contol_ops),
> + tps65090_REG_DESC(DCDC3, "vsys3", 0x0E,
> tps65090_reg_contol_ops),
> + tps65090_REG_DESC(FET1, "infet1", 0x0F,
> tps65090_reg_contol_ops),
> + tps65090_REG_DESC(FET2, "infet2", 0x10,
> tps65090_reg_contol_ops),
> + tps65090_REG_DESC(FET3, "infet3", 0x11,
> tps65090_reg_contol_ops),
> + tps65090_REG_DESC(FET4, "infet4", 0x12,
> tps65090_reg_contol_ops),
> + tps65090_REG_DESC(FET5, "infet5", 0x13,
> tps65090_reg_contol_ops),
> + tps65090_REG_DESC(FET6, "infet6", 0x14,
> tps65090_reg_contol_ops),
> + tps65090_REG_DESC(FET7, "infet7", 0x15,
> tps65090_reg_contol_ops),
> tps65090_REG_DESC(LDO1, "vsys_l1", 0,tps65090_ldo_ops),
> tps65090_REG_DESC(LDO2, "vsys_l2", 0,tps65090_ldo_ops),
> };
> @@ -118,6 +122,22 @@ static int __devinit
> tps65090_regulator_disable_ext_control(
> return tps65090_config_ext_control(ri, false);
> }
>
> +static void __devinit tps65090_configure_regulator_config(
> + struct tps65090_regulator_plat_data *tps_pdata,
> + struct regulator_config *config)
> +{
> + if (gpio_is_valid(tps_pdata->gpio)) {
> + int gpio_flag = GPIOF_OUT_INIT_LOW;
> +
> + if (tps_pdata->reg_init_data->constraints.always_on ||
> + tps_pdata->reg_init_data-
> >constraints.boot_on)
> + gpio_flag = GPIOF_OUT_INIT_HIGH;
> +
> + config->ena_gpio = tps_pdata->gpio;
> + config->ena_gpio_flags = gpio_flag;
> + }
> +}
> +
> static int __devinit tps65090_regulator_probe(struct platform_device *pdev)
> {
> struct tps65090 *tps65090_mfd = dev_get_drvdata(pdev-
> >dev.parent);
> @@ -154,18 +174,24 @@ static int __devinit
> tps65090_regulator_probe(struct platform_device *pdev)
>
> /*
>* TPS5090 DCDC support the control from external digital
> input.
> - * It may be possible that during boot, the external control is
> - * enabled. Disabling external control for DCDC.
> + * Configure it as per platform data.
>*/
> if (tps_pdata && is_dcdc(num) && tps_pdata->reg_init_data)
> {
> - ret = tps65090_regulator_disable_ext_control(
> + if (tps_pdata->enable_ext_control) {
> + tps65090_configure_regulator_config(
> + tps_pdata, );
> + ri->desc->ops = _ext_control_ops;
> + } else {
> + ret =
> tps65090_regulator_disable_ext_control(
> ri,
RE: [remoteproc:for-next 6/9] remoteproc_virtio.c:(.text+0x238e7e): undefined reference to `vring_transport_features'
Hi Ohad, > On Tue, Oct 2, 2012 at 10:24 AM, Ohad Ben-Cohen > wrote: > > On Mon, Oct 1, 2012 at 4:45 AM, Fengguang Wu > wrote: > >> Hi Ohad, > >> > >> FYI, kernel build failed on > >> > >> tree: git://git.kernel.org/pub/scm/linux/kernel/git/ohad/remoteproc.git > for-next > >> head: bec109a430e8c67bae1743f7e71898283234a77f > >> commit: ec4d02d9180f407c41f8310a13b34e473c671fbb [6/9] remoteproc: > Add STE modem driver > >> config: i386-randconfig-b102 (attached as .config) > >> > >> It should be an old bug. The commit happen to be the one to trigger > >> the errors because it selects CONFIG_EMOTEPROC. > > > > Thanks Fengguang. > > > > This should be fixed by a patch I pushed today to remoteproc's for-next > branch. > > > > Though I wonder, Sjur, do we want to limit the architectures/platforms > > where the STE modem driver can be selected on ? Is it ARM only perhaps ? > > Can you please address the above question ? Sorry for not responding sooner, but I thought this issue was solved with your patch "remoteproc: fix (again) the virtio-related build breakage" (https://lkml.org/lkml/2012/10/6/85). I'm not sure I understand why you would want to add a dependency to ARM. But if you're uncomfortable by having STE_MODEM_RPROC directly selectable, perhaps we could let it be selected by arch specific Kconfig files, e.g. mach-ux500? Regards, Sjur -- 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 RESEND] vfs: re-implement writeback_inodes_sb(_nr)_if_idle() and rename them
On Wed, Sep 05, 2012 at 05:54:04PM +0200, David Sterba wrote: > > Many users who use btrfs met the deadlock problem caused by > > writeback_inodes_sb(_nr)_if_idle(), > > so I send this patch again and hope it will be received as soon as possible > > if nobody objects. > > Yes please, this makes testing of the 'autodefrag' mount option hard as > the deadlock occurs frequently upon umount (when there's a background > snapshot cleanup in progress). We have another report of the deadlock and it's without 'autodefrag' mount, triggered by snapshot cleaning under low space conditions. I have added the patch to SLES kernel some time ago and haven't observed the deadlock since. Please queue the patch for 3.7, we cannot fix it locally within btrfs. Thanks, david -- 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/4] regulator; tps65090: Register all regulators in single probe call
MFD driver registers the regulator driver once per device and
hence it is require to register all regulators in single probe
call.
Following are details of changes done to achieve this:
- Move the regulator enums to mfd header and remove the
tps65090-regulator.h as it does not contain more info.
- Add max regulator and register all regulators even if there
is no regulator init data from platform.
- Convert regulator init data to pointer type in platform data.
- Add input supply name in regulator desc to provide input supply.
- Separate desc information from driver information.
- Disable external control bit to have control through register write.
Signed-off-by: Laxman Dewangan
---
Changes from V1:
- Move this change to Patch1 from older patch2.
- Disable external control on init sequence.
- Move content of tps65090-regualtor.h to mfd/tps65090.h.
drivers/regulator/tps65090-regulator.c | 195 ++
include/linux/mfd/tps65090.h | 28
include/linux/regulator/tps65090-regulator.h | 50 ---
3 files changed, 165 insertions(+), 108 deletions(-)
delete mode 100644 include/linux/regulator/tps65090-regulator.h
diff --git a/drivers/regulator/tps65090-regulator.c
b/drivers/regulator/tps65090-regulator.c
index 001ad55..5f7f931 100644
--- a/drivers/regulator/tps65090-regulator.c
+++ b/drivers/regulator/tps65090-regulator.c
@@ -24,15 +24,11 @@
#include
#include
#include
-#include
struct tps65090_regulator {
- int id;
- /* used by regulator core */
- struct regulator_desc desc;
-
- /* Device */
struct device *dev;
+ struct regulator_desc *desc;
+ struct regulator_dev*rdev;
};
static struct regulator_ops tps65090_ops = {
@@ -41,44 +37,80 @@ static struct regulator_ops tps65090_ops = {
.is_enabled = regulator_is_enabled_regmap,
};
-#define tps65090_REG(_id) \
+#define tps65090_REG_DESC(_id, _sname, _en_reg, _ops) \
{ \
- .id = TPS65090_ID_##_id,\
- .desc = { \
- .name = tps65090_rails(_id),\
- .id = TPS65090_ID_##_id,\
- .ops = _ops, \
- .type = REGULATOR_VOLTAGE, \
- .owner = THIS_MODULE, \
- .enable_reg = (TPS65090_ID_##_id) + 12, \
- .enable_mask = BIT(0), \
- }, \
+ .name = "TPS65090_RAILS"#_id, \
+ .supply_name = _sname, \
+ .id = TPS65090_ID_##_id,\
+ .ops = &_ops, \
+ .enable_reg = _en_reg, \
+ .enable_mask = BIT(0), \
+ .type = REGULATOR_VOLTAGE, \
+ .owner = THIS_MODULE, \
}
-static struct tps65090_regulator TPS65090_regulator[] = {
- tps65090_REG(DCDC1),
- tps65090_REG(DCDC2),
- tps65090_REG(DCDC3),
- tps65090_REG(FET1),
- tps65090_REG(FET2),
- tps65090_REG(FET3),
- tps65090_REG(FET4),
- tps65090_REG(FET5),
- tps65090_REG(FET6),
- tps65090_REG(FET7),
+static struct regulator_desc tps65090_regulator_desc[] = {
+ tps65090_REG_DESC(DCDC1, "vsys1", 0x0C, tps65090_ops),
+ tps65090_REG_DESC(DCDC2, "vsys2", 0x0D, tps65090_ops),
+ tps65090_REG_DESC(DCDC3, "vsys3", 0x0E, tps65090_ops),
+ tps65090_REG_DESC(FET1, "infet1", 0x0F, tps65090_ops),
+ tps65090_REG_DESC(FET2, "infet2", 0x10, tps65090_ops),
+ tps65090_REG_DESC(FET3, "infet3", 0x11, tps65090_ops),
+ tps65090_REG_DESC(FET4, "infet4", 0x12, tps65090_ops),
+ tps65090_REG_DESC(FET5, "infet5", 0x13, tps65090_ops),
+ tps65090_REG_DESC(FET6, "infet6", 0x14, tps65090_ops),
+ tps65090_REG_DESC(FET7, "infet7", 0x15, tps65090_ops),
};
-static inline struct tps65090_regulator *find_regulator_info(int id)
+static inline bool is_dcdc(int id)
{
- struct tps65090_regulator *ri;
- int i;
+ switch (id) {
+ case TPS65090_ID_DCDC1:
+ case TPS65090_ID_DCDC2:
+ case TPS65090_ID_DCDC3:
+ return true;
+ default:
+ return false;
+ }
+}
- for (i = 0; i < ARRAY_SIZE(TPS65090_regulator); i++) {
- ri = _regulator[i];
- if (ri->desc.id == id)
- return ri;
+static int __devinit tps65090_config_ext_control(
+ struct tps65090_regulator *ri, bool enable)
+{
+ int ret;
+ struct device *parent = ri->dev->parent;
+ unsigned int reg_en_reg = ri->desc->enable_reg;
+
+ if (enable)
+ ret =
[PATCH V2 0/4] regulator: tps65090: fix regulator registration and add external control support
This patch series fixes the regulator registration issue and add support for external control. Patch 1: It renames the driver name and regulators to more appropriate. Patch 2: Fix the issue with regulator registration. Patch 3: Add LDO support. Patch 4: Add voltage output level information. Patch 5: Add support for extenal control for DCDC. Changes from V1: - Shuffle patch 1 and 2 to make patch2 to patch1. - Remove patch 4 for output voltage level. - Move some of implementation from patch 5 to new patch1 for patch1 completion. - Move the content of tps65090-regulator.h to mfd/tps65090.h and remove this file. Laxman Dewangan (4): regulator; tps65090: Register all regulators in single probe call regulator: tps65090: rename driver name and regulator name regulator: tps65090: Add support for LDO regulators regulator: tps65090: add external control support for DCDC drivers/regulator/tps65090-regulator.c | 245 +++--- include/linux/mfd/tps65090.h | 35 include/linux/regulator/tps65090-regulator.h | 50 -- 3 files changed, 218 insertions(+), 112 deletions(-) delete mode 100644 include/linux/regulator/tps65090-regulator.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/
[PATCH V2 3/4] regulator: tps65090: Add support for LDO regulators
TPS65090 supports the two LDOs, LDO1 and LDO2. These are
always ON regulators. The output on these LDOs are available
once the input voltage available for these LDOs.
Add support for these LDOs regulators.
Signed-off-by: Laxman Dewangan
---
Changes from V1:
No change from older patch.
drivers/regulator/tps65090-regulator.c |5 +
include/linux/mfd/tps65090.h |2 ++
2 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/drivers/regulator/tps65090-regulator.c
b/drivers/regulator/tps65090-regulator.c
index 584a185..0732d9b 100644
--- a/drivers/regulator/tps65090-regulator.c
+++ b/drivers/regulator/tps65090-regulator.c
@@ -37,6 +37,9 @@ static struct regulator_ops tps65090_ops = {
.is_enabled = regulator_is_enabled_regmap,
};
+static struct regulator_ops tps65090_ldo_ops = {
+};
+
#define tps65090_REG_DESC(_id, _sname, _en_reg, _ops) \
{ \
.name = "TPS65090_RAILS"#_id, \
@@ -60,6 +63,8 @@ static struct regulator_desc tps65090_regulator_desc[] = {
tps65090_REG_DESC(FET5, "infet5", 0x13, tps65090_ops),
tps65090_REG_DESC(FET6, "infet6", 0x14, tps65090_ops),
tps65090_REG_DESC(FET7, "infet7", 0x15, tps65090_ops),
+ tps65090_REG_DESC(LDO1, "vsys_l1", 0,tps65090_ldo_ops),
+ tps65090_REG_DESC(LDO2, "vsys_l2", 0,tps65090_ldo_ops),
};
static inline bool is_dcdc(int id)
diff --git a/include/linux/mfd/tps65090.h b/include/linux/mfd/tps65090.h
index 958bf15..5989212 100644
--- a/include/linux/mfd/tps65090.h
+++ b/include/linux/mfd/tps65090.h
@@ -36,6 +36,8 @@ enum {
TPS65090_REGULATOR_FET5,
TPS65090_REGULATOR_FET6,
TPS65090_REGULATOR_FET7,
+ TPS65090_REGULATOR_LDO1,
+ TPS65090_REGULATOR_LDO2,
/* Last entry for maximum ID */
TPS65090_REGULATOR_MAX,
--
1.7.1.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/
[PATCH V2 4/4] regulator: tps65090: add external control support for DCDC
The TPS65090's DCDC output can also be enable/disable through the
external digital input signal. Add support for enable/disable
either through register access via I2C or through external
control inputs. The external control inputs can be driven through
GPIOs also and hence adding support for passing the GPIO number.
Signed-off-by: Laxman Dewangan
---
Changes from V1:
Simplify external control implemetation.
drivers/regulator/tps65090-regulator.c | 77 +++
include/linux/mfd/tps65090.h |7 +++-
2 files changed, 63 insertions(+), 21 deletions(-)
diff --git a/drivers/regulator/tps65090-regulator.c
b/drivers/regulator/tps65090-regulator.c
index 0732d9b..4124138 100644
--- a/drivers/regulator/tps65090-regulator.c
+++ b/drivers/regulator/tps65090-regulator.c
@@ -18,6 +18,7 @@
#include
#include
+#include
#include
#include
#include
@@ -31,10 +32,13 @@ struct tps65090_regulator {
struct regulator_dev*rdev;
};
-static struct regulator_ops tps65090_ops = {
- .enable = regulator_enable_regmap,
- .disable = regulator_disable_regmap,
- .is_enabled = regulator_is_enabled_regmap,
+static struct regulator_ops tps65090_ext_control_ops = {
+};
+
+static struct regulator_ops tps65090_reg_contol_ops = {
+ .enable = regulator_enable_regmap,
+ .disable= regulator_disable_regmap,
+ .is_enabled = regulator_is_enabled_regmap,
};
static struct regulator_ops tps65090_ldo_ops = {
@@ -53,16 +57,16 @@ static struct regulator_ops tps65090_ldo_ops = {
}
static struct regulator_desc tps65090_regulator_desc[] = {
- tps65090_REG_DESC(DCDC1, "vsys1", 0x0C, tps65090_ops),
- tps65090_REG_DESC(DCDC2, "vsys2", 0x0D, tps65090_ops),
- tps65090_REG_DESC(DCDC3, "vsys3", 0x0E, tps65090_ops),
- tps65090_REG_DESC(FET1, "infet1", 0x0F, tps65090_ops),
- tps65090_REG_DESC(FET2, "infet2", 0x10, tps65090_ops),
- tps65090_REG_DESC(FET3, "infet3", 0x11, tps65090_ops),
- tps65090_REG_DESC(FET4, "infet4", 0x12, tps65090_ops),
- tps65090_REG_DESC(FET5, "infet5", 0x13, tps65090_ops),
- tps65090_REG_DESC(FET6, "infet6", 0x14, tps65090_ops),
- tps65090_REG_DESC(FET7, "infet7", 0x15, tps65090_ops),
+ tps65090_REG_DESC(DCDC1, "vsys1", 0x0C, tps65090_reg_contol_ops),
+ tps65090_REG_DESC(DCDC2, "vsys2", 0x0D, tps65090_reg_contol_ops),
+ tps65090_REG_DESC(DCDC3, "vsys3", 0x0E, tps65090_reg_contol_ops),
+ tps65090_REG_DESC(FET1, "infet1", 0x0F, tps65090_reg_contol_ops),
+ tps65090_REG_DESC(FET2, "infet2", 0x10, tps65090_reg_contol_ops),
+ tps65090_REG_DESC(FET3, "infet3", 0x11, tps65090_reg_contol_ops),
+ tps65090_REG_DESC(FET4, "infet4", 0x12, tps65090_reg_contol_ops),
+ tps65090_REG_DESC(FET5, "infet5", 0x13, tps65090_reg_contol_ops),
+ tps65090_REG_DESC(FET6, "infet6", 0x14, tps65090_reg_contol_ops),
+ tps65090_REG_DESC(FET7, "infet7", 0x15, tps65090_reg_contol_ops),
tps65090_REG_DESC(LDO1, "vsys_l1", 0,tps65090_ldo_ops),
tps65090_REG_DESC(LDO2, "vsys_l2", 0,tps65090_ldo_ops),
};
@@ -118,6 +122,22 @@ static int __devinit
tps65090_regulator_disable_ext_control(
return tps65090_config_ext_control(ri, false);
}
+static void __devinit tps65090_configure_regulator_config(
+ struct tps65090_regulator_plat_data *tps_pdata,
+ struct regulator_config *config)
+{
+ if (gpio_is_valid(tps_pdata->gpio)) {
+ int gpio_flag = GPIOF_OUT_INIT_LOW;
+
+ if (tps_pdata->reg_init_data->constraints.always_on ||
+ tps_pdata->reg_init_data->constraints.boot_on)
+ gpio_flag = GPIOF_OUT_INIT_HIGH;
+
+ config->ena_gpio = tps_pdata->gpio;
+ config->ena_gpio_flags = gpio_flag;
+ }
+}
+
static int __devinit tps65090_regulator_probe(struct platform_device *pdev)
{
struct tps65090 *tps65090_mfd = dev_get_drvdata(pdev->dev.parent);
@@ -154,18 +174,24 @@ static int __devinit tps65090_regulator_probe(struct
platform_device *pdev)
/*
* TPS5090 DCDC support the control from external digital input.
-* It may be possible that during boot, the external control is
-* enabled. Disabling external control for DCDC.
+* Configure it as per platform data.
*/
if (tps_pdata && is_dcdc(num) && tps_pdata->reg_init_data) {
- ret = tps65090_regulator_disable_ext_control(
+ if (tps_pdata->enable_ext_control) {
+ tps65090_configure_regulator_config(
+ tps_pdata, );
+ ri->desc->ops = _ext_control_ops;
+ } else {
+ ret =
[PATCH V2 2/4] regulator: tps65090: rename driver name and regulator name
To make the names proper and more appropriate:
Rename the driver name from tps65090-regulator to tps65090-pmic.
Rename the regulators from TPS65090_ID_* to TPS65090_REGULATOR_*
Signed-off-by: Laxman Dewangan
---
Changes from V1:
Make this as patch2 from older patch1.
drivers/regulator/tps65090-regulator.c | 16
include/linux/mfd/tps65090.h | 24
2 files changed, 20 insertions(+), 20 deletions(-)
diff --git a/drivers/regulator/tps65090-regulator.c
b/drivers/regulator/tps65090-regulator.c
index 5f7f931..584a185 100644
--- a/drivers/regulator/tps65090-regulator.c
+++ b/drivers/regulator/tps65090-regulator.c
@@ -41,7 +41,7 @@ static struct regulator_ops tps65090_ops = {
{ \
.name = "TPS65090_RAILS"#_id, \
.supply_name = _sname, \
- .id = TPS65090_ID_##_id,\
+ .id = TPS65090_REGULATOR_##_id, \
.ops = &_ops, \
.enable_reg = _en_reg, \
.enable_mask = BIT(0), \
@@ -65,9 +65,9 @@ static struct regulator_desc tps65090_regulator_desc[] = {
static inline bool is_dcdc(int id)
{
switch (id) {
- case TPS65090_ID_DCDC1:
- case TPS65090_ID_DCDC2:
- case TPS65090_ID_DCDC3:
+ case TPS65090_REGULATOR_DCDC1:
+ case TPS65090_REGULATOR_DCDC2:
+ case TPS65090_REGULATOR_DCDC3:
return true;
default:
return false;
@@ -133,14 +133,14 @@ static int __devinit tps65090_regulator_probe(struct
platform_device *pdev)
return -EINVAL;
}
- pmic = devm_kzalloc(>dev, TPS65090_ID_MAX * sizeof(*pmic),
+ pmic = devm_kzalloc(>dev, TPS65090_REGULATOR_MAX * sizeof(*pmic),
GFP_KERNEL);
if (!pmic) {
dev_err(>dev, "mem alloc for pmic failed\n");
return -ENOMEM;
}
- for (num = 0; num < TPS65090_ID_MAX; num++) {
+ for (num = 0; num < TPS65090_REGULATOR_MAX; num++) {
tps_pdata = tps65090_pdata->reg_pdata[num];
ri = [num];
@@ -196,7 +196,7 @@ static int __devexit tps65090_regulator_remove(struct
platform_device *pdev)
struct tps65090_regulator *ri;
int num;
- for (num = 0; num < TPS65090_ID_MAX; ++num) {
+ for (num = 0; num < TPS65090_REGULATOR_MAX; ++num) {
ri = [num];
regulator_unregister(ri->rdev);
}
@@ -205,7 +205,7 @@ static int __devexit tps65090_regulator_remove(struct
platform_device *pdev)
static struct platform_driver tps65090_regulator_driver = {
.driver = {
- .name = "tps65090-regulator",
+ .name = "tps65090-pmic",
.owner = THIS_MODULE,
},
.probe = tps65090_regulator_probe,
diff --git a/include/linux/mfd/tps65090.h b/include/linux/mfd/tps65090.h
index d06c633..958bf15 100644
--- a/include/linux/mfd/tps65090.h
+++ b/include/linux/mfd/tps65090.h
@@ -26,19 +26,19 @@
/* TPS65090 Regulator ID */
enum {
- TPS65090_ID_DCDC1,
- TPS65090_ID_DCDC2,
- TPS65090_ID_DCDC3,
- TPS65090_ID_FET1,
- TPS65090_ID_FET2,
- TPS65090_ID_FET3,
- TPS65090_ID_FET4,
- TPS65090_ID_FET5,
- TPS65090_ID_FET6,
- TPS65090_ID_FET7,
+ TPS65090_REGULATOR_DCDC1,
+ TPS65090_REGULATOR_DCDC2,
+ TPS65090_REGULATOR_DCDC3,
+ TPS65090_REGULATOR_FET1,
+ TPS65090_REGULATOR_FET2,
+ TPS65090_REGULATOR_FET3,
+ TPS65090_REGULATOR_FET4,
+ TPS65090_REGULATOR_FET5,
+ TPS65090_REGULATOR_FET6,
+ TPS65090_REGULATOR_FET7,
/* Last entry for maximum ID */
- TPS65090_ID_MAX,
+ TPS65090_REGULATOR_MAX,
};
struct tps65090 {
@@ -72,7 +72,7 @@ struct tps65090_platform_data {
int irq_base;
int num_subdevs;
struct tps65090_subdev_info *subdevs;
- struct tps65090_regulator_plat_data *reg_pdata[TPS65090_ID_MAX];
+ struct tps65090_regulator_plat_data *reg_pdata[TPS65090_REGULATOR_MAX];
};
/*
--
1.7.1.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: [uclinux-dist-devel] [GIT PULL] Disintegrate UAPI for blackfin [ver #2]
Bob Liu wrote: > Merged into my git tree: > git://git.kernel.org/pub/scm/linux/kernel/git/lliubbo/blackfin.git for-linus > > And what time i need to ask linus to pull? Next merge window? That's up to you now. There aren't any dependencies on the blackfin branch in my tree. Feel free to defer to next merge window if you prefer. David -- 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 RESEND] umc-bus.c: fix usage of device_trylock
Hi all. I've not received any feedback about this patch, so I'm resending just to check if someone is going to take care of it. The patch fixes the usage of device_trylock inside the driver umc-bus.c: device_trylock has the same semantics of mutex_trylock, so it returns 1 if the lock has been acquired successfully. Best regards, Claudio Subject: umc-bus.c: fix usage of device_trylock From: Claudio Scordino Fix usage of device_trylock. It has the same semantics of mutex_trylock, so it returns 1 if the lock has been acquired successfully. Signed-off-by: Claudio Scordino Signed-off-by: Bruno Morelli --- drivers/uwb/umc-bus.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/uwb/umc-bus.c b/drivers/uwb/umc-bus.c index 82a84d5..5c5b3fc 100644 --- a/drivers/uwb/umc-bus.c +++ b/drivers/uwb/umc-bus.c @@ -63,7 +63,7 @@ int umc_controller_reset(struct umc_dev *umc) struct device *parent = umc->dev.parent; int ret = 0; - if (device_trylock(parent)) + if (!device_trylock(parent)) return -EAGAIN; ret = device_for_each_child(parent, parent, umc_bus_pre_reset_helper); if (ret >= 0) -- 1.7.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: [RFC] vmevent: Implement pressure attribute
On Mon, Oct 08, 2012 at 06:42:16PM -0700, John Stultz wrote: > On 10/08/2012 02:46 AM, Mel Gorman wrote: > >On Sun, Oct 07, 2012 at 01:14:17AM -0700, Anton Vorontsov wrote: > >>And here we just try to let userland to assist, userland can tell "oh, > >>don't bother with swapping or draining caches, I can just free some > >>memory". > >> > >>Quite interesting, this also very much resembles volatile mmap ranges > >>(i.e. the work that John Stultz is leading in parallel). > >> > >Agreed. I haven't been paying close attention to those patches but it > >seems to me that one possiblity is that a listener for a vmevent would > >set volatile ranges in response. > > I don't have too much to comment on the rest of this mail, but just > wanted to pipe in here, as the volatile ranges have caused some > confusion. > > While your suggestion would be possible, with volatile ranges, I've > been promoting a more hands off-approach from the application > perspective, where the application always would mark data that could > be regenerated as volatile, unmarking it when accessing it. > > This way the application doesn't need to be responsive to memory > pressure, the kernel just takes what it needs from what the > application made available. > > Only when the application needs the data again, would it mark it > non-volatile (or alternatively with the new SIGBUS semantics, access > the purged volatile data and catch a SIGBUS), find the data was > purged and regenerate it. > Ok understood. > That said, hybrid approaches like you suggested would be possible, > but at a certain point, if we're waiting for a notification to take > action, it might be better just to directly free that memory, rather > then just setting it as volatile, and leaving it to the kernel then > reclaim it for you. > That's fine. I did not mean to suggest that volatile and vmevents on memory pressure should be related or depending on each other in any way. -- Mel Gorman SUSE Labs -- 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] Do not use cpu_to_node() to find an offlined cpu's node.
At 10/09/2012 06:04 PM, David Rientjes Wrote:
> On Tue, 9 Oct 2012, Tang Chen wrote:
>
Eek, the nid shouldn't be -1 yet, though, for cpu hotplug since this
should be called at CPU_DYING level and migrate_tasks() still sees a valid
cpu.
>>
>> As Wen said below, nid is now set to -1 when cpu is hotremoved.
>> I reproduce this problem in this situation:
>>
>> all cpus are online, and hot remove a system board directorily, without
>> offlining any cpu.
>>
>> As a result, the removed cpu's nid is set to -1, and this causes
>> problems.
>>
>
> Let's add Andrew to the cc list then, because I'm nacking
> cpu_hotplug-unmap-cpu2node-when-the-cpu-is-hotremoved.patch in the -mm
> tree for this reason.
>
> We can only clear a cpu-to-node mapping when the cpu is completely
> offline, not before or during the CPU_DYING stage. Kernel code, such as
I clear cpu-to-node mapping when the cpu is hotremoved. If the cpu is onlined,
it will be offlined before clearing cpu-to-node mapping.
Here is the code in driver/acpi/processor_driver.c:
=
static int acpi_processor_handle_eject(struct acpi_processor *pr)
{
if (cpu_online(pr->id))
cpu_down(pr->id); <== cpu is offlined here.
arch_unregister_cpu(pr->id);
acpi_unmap_lsapic(pr->id); <== I clear the mapping here.
return (0);
}
=
The real problem is that: we don't migrate this task to another cpu when
the cpu is offlined. I guess this task is not in running state, and it
is not in the cpu's runqueue.
Thanks
Wen Congyang
> the sched code that you are now trying to "fix", depends on this mapping
> to work correctly; obviously no audit was done of cpu hotplug code
> depending on it before the patch was proposed.
>
> I say "fix" because even this workaround isn't a good solution since it
> would be much better to pick another cpu on the same node as the offlining
> cpu for the runqueue before falling back to the set of all allowed nodes.
> We lose all NUMA affinity information with that patch. There's no reason
> why we shouldn't know the node of a cpu that is being offlined.
>
> So nack to cpu_hotplug-unmap-cpu2node-when-the-cpu-is-hotremoved.patch.
> After it's removed because it's buggy, this "fix" will no longer be
> necessary.
>
This patch is try to fix a bug: the kernel will be panicked after removing a
node.
--
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/1] HID: Fix missing Unifying device issue
Hello Apostolos, Your problem is unrelated to hid-logitech-dj. This seems an usb driver issue. It seems that your motherboard has different usb controllers for the rear and front ports. There may be an issue with the usb drivers for the xhci controllers. Cheers, Nestor. On Mon, Oct 8, 2012 at 9:42 PM, Apostolos Bartziokas wrote: > > Nestor hello > > Sorry for bringing this up again but i tested the patch now that it > reached the stable kernels and when i connect it to the rear panel of my > motherboard i get: > > Oct 08 22:11:43 mainland kernel: usb 3-2: >USB disconnect, device number 2 > Oct 08 22:12:04 mainland kernel: usb 1-2: >new full-speed USB device > number 3 using xhci_hcd > Oct 08 22:12:05 mainland kernel: logitech-djreceiver 0003:046D:C52B.0009: > >hiddev0,hidraw2: USB HID v1.11 Device [Logitech USB Receiver] on > usb-:00:14.0-2/input2 > Oct 08 22:12:05 mainland kernel: logitech-djreceiver 0003:046D:C52B.0009: > >logi_dj_probe:logi_dj_recv_query_paired_devices error:-32 > Oct 08 22:12:05 mainland kernel: logitech-djreceiver: probe of > 0003:046D:C52B.0009 failed with error -32 > Oct 08 22:13:50 mainland kernel: usb 1-2: >USB disconnect, device number 3 > Oct 08 22:13:57 mainland kernel: usb 5-1.6: >new full-speed USB device > number 3 using ehci_hcd > Oct 08 22:13:58 mainland kernel: logitech-djreceiver 0003:046D:C52B.000C: > >hiddev0,hidraw2: USB HID v1.11 Device [Logitech USB Receiver] on > usb-:00:1a.0-1.6/input2 > Oct 08 22:14:01 mainland kernel: input: Logitech Unifying Device. Wireless > PID:101a as > /devices/pci:00/:00:1a.0/usb5/5-1/5-1.6/5-1.6:1.2/0003:046D:C52B.000C/input/input15 > Oct 08 22:14:01 mainland kernel: logitech-djdevice 0003:046D:C52B.000D: > >input,hidraw3: USB HID v1.11 Mouse [Logitech Unifying Device. Wireless > PID:101a] on usb-:00:1a.0-1.6:1 > Oct 08 22:14:17 mainland kernel: usb 5-1.6: >USB disconnect, device number > 3 > Oct 08 22:14:20 mainland kernel: usb 1-2: >new full-speed USB device > number 4 using xhci_hcd > Oct 08 22:14:20 mainland kernel: logitech-djreceiver 0003:046D:C52B.0010: > >hiddev0,hidraw2: USB HID v1.11 Device [Logitech USB Receiver] on > usb-:00:14.0-2/input2 > Oct 08 22:14:20 mainland kernel: logitech-djreceiver 0003:046D:C52B.0010: > >logi_dj_probe:logi_dj_recv_query_paired_devices error:-32 > Oct 08 22:14:20 mainland kernel: logitech-djreceiver: probe of > 0003:046D:C52B.0010 failed with error -32 > > When i use a usb3 port it doesn't move at all and if i use a usb2 port its > slow. When i use the front panel it works flawlessly. Could this be related > to my POS Intel motherboard? > > Kind regards and apologies if i raise a false alarm. > > Apostolos B. > On 09/28/2012 10:57 AM, Nestor Lopez Casado wrote: > > Hello Josip, > > This really looks like a different problem from the one addressed with > this patch. > > I'll try to work on it as soon as I find some time for that. > > Thanks, > Nestor. > > On Thu, Sep 27, 2012 at 8:56 PM, Josip Rodin > wrote: >> >> On Thu, Sep 27, 2012 at 09:04:26AM +0200, Josip Rodin wrote: >> > On Mon, Sep 24, 2012 at 11:30:28AM +0200, Nestor Lopez Casado wrote: >> > > Josip, this is a different issue from the one addressed with the >> > > patch. >> > > >> > > 1) Can you try it on a 3.2 kernel ? >> > >> > I can try that too, I'll let you know how it went. >> >> Same thing, it doesn't work. >> >> -- >> 2. That which causes joy or happiness. >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-input" 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: [uclinux-dist-devel] [GIT PULL] Disintegrate UAPI for blackfin [ver #2]
On Tue, Oct 9, 2012 at 5:15 PM, David Howells wrote:
> Can you merge the following branch into the blackfin tree please.
>
Merged into my git tree:
git://git.kernel.org/pub/scm/linux/kernel/git/lliubbo/blackfin.git for-linus
And what time i need to ask linus to pull? Next merge window?
> This is to complete part of the UAPI disintegration for which the preparatory
> patches were pulled recently.
>
> Now that the fixups and the asm-generic chunk have been merged, I've
> regenerated the patches to get rid of those dependencies and to take account
> of
> any changes made so far in the merge window. If you have already pulled the
> older version of the branch aimed at you, then please feel free to ignore this
> request.
>
> The following changes since commit 9e2d8656f5e8aa214e66b462680cf86b210b74a8:
>
> Merge branch 'akpm' (Andrew's patch-bomb) (2012-10-09 16:23:15 +0900)
>
> are available in the git repository at:
>
>
> git://git.infradead.org/users/dhowells/linux-headers.git
> tags/disintegrate-blackfin-20121009
>
> for you to fetch changes up to ac3a050e89f2e6b8025e4176a36ed34de470fcad:
>
> UAPI: (Scripted) Disintegrate arch/blackfin/include/asm (2012-10-09
> 09:46:39 +0100)
>
>
> UAPI Disintegration 2012-10-09
>
>
> David Howells (1):
> UAPI: (Scripted) Disintegrate arch/blackfin/include/asm
>
> arch/blackfin/include/asm/Kbuild | 5 -
> arch/blackfin/include/asm/bfin_sport.h | 128 +-
> arch/blackfin/include/asm/fixed_code.h | 30 +-
> arch/blackfin/include/asm/ptrace.h | 161 +---
> arch/blackfin/include/asm/unistd.h | 430 +---
> arch/blackfin/include/uapi/asm/Kbuild | 16 +
> arch/blackfin/include/uapi/asm/bfin_sport.h| 136 +++
> arch/blackfin/include/{ => uapi}/asm/byteorder.h | 0
> arch/blackfin/include/{ => uapi}/asm/cachectl.h| 0
> arch/blackfin/include/{ => uapi}/asm/fcntl.h | 0
> arch/blackfin/include/uapi/asm/fixed_code.h| 38 ++
> arch/blackfin/include/{ => uapi}/asm/ioctls.h | 0
> arch/blackfin/include/{ => uapi}/asm/kvm_para.h| 0
> arch/blackfin/include/{ => uapi}/asm/poll.h| 0
> arch/blackfin/include/{ => uapi}/asm/posix_types.h | 0
> arch/blackfin/include/uapi/asm/ptrace.h| 170
> arch/blackfin/include/{ => uapi}/asm/sigcontext.h | 0
> arch/blackfin/include/{ => uapi}/asm/siginfo.h | 0
> arch/blackfin/include/{ => uapi}/asm/signal.h | 0
> arch/blackfin/include/{ => uapi}/asm/stat.h| 0
> arch/blackfin/include/{ => uapi}/asm/swab.h| 0
> arch/blackfin/include/uapi/asm/unistd.h| 437
> +
> 22 files changed, 802 insertions(+), 749 deletions(-)
> create mode 100644 arch/blackfin/include/uapi/asm/bfin_sport.h
> rename arch/blackfin/include/{ => uapi}/asm/byteorder.h (100%)
> rename arch/blackfin/include/{ => uapi}/asm/cachectl.h (100%)
> rename arch/blackfin/include/{ => uapi}/asm/fcntl.h (100%)
> create mode 100644 arch/blackfin/include/uapi/asm/fixed_code.h
> rename arch/blackfin/include/{ => uapi}/asm/ioctls.h (100%)
> rename arch/blackfin/include/{ => uapi}/asm/kvm_para.h (100%)
> rename arch/blackfin/include/{ => uapi}/asm/poll.h (100%)
> rename arch/blackfin/include/{ => uapi}/asm/posix_types.h (100%)
> create mode 100644 arch/blackfin/include/uapi/asm/ptrace.h
> rename arch/blackfin/include/{ => uapi}/asm/sigcontext.h (100%)
> rename arch/blackfin/include/{ => uapi}/asm/siginfo.h (100%)
> rename arch/blackfin/include/{ => uapi}/asm/signal.h (100%)
> rename arch/blackfin/include/{ => uapi}/asm/stat.h (100%)
> rename arch/blackfin/include/{ => uapi}/asm/swab.h (100%)
> create mode 100644 arch/blackfin/include/uapi/asm/unistd.h
> .
> ___
> Uclinux-dist-devel mailing list
> uclinux-dist-de...@blackfin.uclinux.org
> https://blackfin.uclinux.org/mailman/listinfo/uclinux-dist-devel
--
Regards,
--Bob
--
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: CMA broken in next-20120926
On Tue, Oct 09, 2012 at 10:40:10AM +0200, Bartlomiej Zolnierkiewicz wrote:
> I also need following patch to make CONFIG_CMA=y && CONFIG_COMPACTION=y case
> work:
>
> From: Bartlomiej Zolnierkiewicz
> Subject: [PATCH] mm: compaction: cache if a pageblock was scanned and no
> pages were isolated - cma fix
>
> Patch "mm: compaction: cache if a pageblock was scanned and no pages
> were isolated" needs a following fix to successfully boot next-20121002
> kernel (same with next-20121008) with CONFIG_CMA=y and CONFIG_COMPACTION=y
> (with applied -fix1, -fix2, -fix3 patches from Mel Gorman and also with
> cmatest module from Thierry Reding compiled in).
>
Why is it needed to make it boot? CMA should not care about the
PG_migrate_skip hint being set because it should always ignore it in
alloc_contig_range() due to cc->ignore_skip_hint. It's not obvious to
me why this fixes a boot failure and I wonder if it's papering over some
underlying problem. Can you provide more details please?
> Signed-off-by: Bartlomiej Zolnierkiewicz
> Signed-off-by: Kyungmin Park
> ---
> mm/compaction.c |3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> Index: b/mm/compaction.c
> ===
> --- a/mm/compaction.c 2012-10-08 18:10:53.491679716 +0200
> +++ b/mm/compaction.c 2012-10-08 18:11:33.615679713 +0200
> @@ -117,7 +117,8 @@ static void update_pageblock_skip(struct
> bool migrate_scanner)
> {
> struct zone *zone = cc->zone;
> - if (!page)
> +
> + if (!page || cc->ignore_skip_hint)
> return;
>
> if (!nr_isolated) {
--
Mel Gorman
SUSE Labs
--
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.6-rc7] switcheroo race with Intel HDA...
At Tue, 09 Oct 2012 12:04:08 +0200, Takashi Iwai wrote: > > At Tue, 9 Oct 2012 00:34:09 +0800, > Daniel J Blueman wrote: > > > > On 8 October 2012 20:58, Takashi Iwai wrote: > > > At Tue, 25 Sep 2012 13:20:05 +0800, > > > Daniel J Blueman wrote: > > >> On my Macbook with a discrete Nvidia GPU, there is a race between > > >> selecting the integrated GPU and putting the discrete GPU into D3 [1], > > >> reliably causing a kernel oops [2]. > > >> > > >> Introducing a delay of ~1s between the calls prevents this. When the > > >> second 'OFF' write path executes, it looks like struct azx at > > >> card->private_data hasn't yet been allocated yet [3], so there is > > >> likely some locking missing. > > > > > > It's rather pci_get_drvdata() returning NULL (i.e. card is NULL, thus > > > card->private_data causes Oops). Could you check the patch like below > > > and see whether you get a kernel warning (but no Oops) or the problem > > > gets fixed by shifting the assignment of pci drvdata? > > [...] > > > > Good patching. Calling pci_set_drvdata later prevents the oops in HDA, > > though we see unexpected 0x0 responses in the response ring buffer > > [1], which we don't see when there's a >~1.5s delay between IGD and > > OFF. > > If the previous patch fixed, it means that the switching occurred > during the device was being probed. Maybe a better approach to > register the VGA switcheroo after the proper initialization. > > The patch below is a revised one. Please give it a try. Also, it's not clear which card spews the spurious response. Apply the patch below in addition. thanks, Takashi --- diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c index f09ff6c..9a0a29d 100644 --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -829,8 +829,9 @@ static void azx_update_rirb(struct azx *chip) smp_wmb(); chip->rirb.cmds[addr]--; } else - snd_printk(KERN_ERR SFX "spurious response %#x:%#x, " + snd_printk(KERN_ERR SFX "%s: spurious response %#x:%#x, " "last cmd=%#08x\n", + pci_name(chip->pci), res, res_ex, chip->last_cmd[addr]); } -- 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: [GIT PULL] Disintegrate UAPI for avr32 [ver #2]
Around Tue 09 Oct 2012 10:37:20 +0100 or thereabout, David Howells wrote: > Hans-Christian Egtvedt wrote: > >> Neither Haavard or me have a GIT tree at kernel.org anymore, I hope to get my >> key signed in Barcelona during ELCE. Could you ask Linus to pull directly, or >> pass it through Andrew. > > I can ask Linus directly. Can I add your Acked-by to it? > Acked-by: Hans-Christian Egtvedt -- mvh Hans-Christian Egtvedt -- 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] Do not use cpu_to_node() to find an offlined cpu's node.
On Tue, 9 Oct 2012, Tang Chen wrote: > > > Eek, the nid shouldn't be -1 yet, though, for cpu hotplug since this > > > should be called at CPU_DYING level and migrate_tasks() still sees a valid > > > cpu. > > As Wen said below, nid is now set to -1 when cpu is hotremoved. > I reproduce this problem in this situation: > > all cpus are online, and hot remove a system board directorily, without > offlining any cpu. > > As a result, the removed cpu's nid is set to -1, and this causes > problems. > Let's add Andrew to the cc list then, because I'm nacking cpu_hotplug-unmap-cpu2node-when-the-cpu-is-hotremoved.patch in the -mm tree for this reason. We can only clear a cpu-to-node mapping when the cpu is completely offline, not before or during the CPU_DYING stage. Kernel code, such as the sched code that you are now trying to "fix", depends on this mapping to work correctly; obviously no audit was done of cpu hotplug code depending on it before the patch was proposed. I say "fix" because even this workaround isn't a good solution since it would be much better to pick another cpu on the same node as the offlining cpu for the runqueue before falling back to the set of all allowed nodes. We lose all NUMA affinity information with that patch. There's no reason why we shouldn't know the node of a cpu that is being offlined. So nack to cpu_hotplug-unmap-cpu2node-when-the-cpu-is-hotremoved.patch. After it's removed because it's buggy, this "fix" will no longer be necessary. -- 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.6-rc7] switcheroo race with Intel HDA...
At Tue, 9 Oct 2012 00:34:09 +0800,
Daniel J Blueman wrote:
>
> On 8 October 2012 20:58, Takashi Iwai wrote:
> > At Tue, 25 Sep 2012 13:20:05 +0800,
> > Daniel J Blueman wrote:
> >> On my Macbook with a discrete Nvidia GPU, there is a race between
> >> selecting the integrated GPU and putting the discrete GPU into D3 [1],
> >> reliably causing a kernel oops [2].
> >>
> >> Introducing a delay of ~1s between the calls prevents this. When the
> >> second 'OFF' write path executes, it looks like struct azx at
> >> card->private_data hasn't yet been allocated yet [3], so there is
> >> likely some locking missing.
> >
> > It's rather pci_get_drvdata() returning NULL (i.e. card is NULL, thus
> > card->private_data causes Oops). Could you check the patch like below
> > and see whether you get a kernel warning (but no Oops) or the problem
> > gets fixed by shifting the assignment of pci drvdata?
> [...]
>
> Good patching. Calling pci_set_drvdata later prevents the oops in HDA,
> though we see unexpected 0x0 responses in the response ring buffer
> [1], which we don't see when there's a >~1.5s delay between IGD and
> OFF.
If the previous patch fixed, it means that the switching occurred
during the device was being probed. Maybe a better approach to
register the VGA switcheroo after the proper initialization.
The patch below is a revised one. Please give it a try.
Takashi
---
diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index f09ff6c..dcbfd29 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -501,6 +501,7 @@ struct azx {
/* VGA-switcheroo setup */
unsigned int use_vga_switcheroo:1;
+ unsigned int vga_switcheroo_registered:1;
unsigned int init_failed:1; /* delayed init failed */
unsigned int disabled:1; /* disabled by VGA-switcher */
@@ -2684,14 +2685,20 @@ static const struct vga_switcheroo_client_ops
azx_vs_ops = {
static int __devinit register_vga_switcheroo(struct azx *chip)
{
+ int err;
+
if (!chip->use_vga_switcheroo)
return 0;
/* FIXME: currently only handling DIS controller
* is there any machine with two switchable HDMI audio controllers?
*/
- return vga_switcheroo_register_audio_client(chip->pci, _vs_ops,
+ err = vga_switcheroo_register_audio_client(chip->pci, _vs_ops,
VGA_SWITCHEROO_DIS,
chip->bus != NULL);
+ if (err < 0)
+ return err;
+ chip->vga_switcheroo_registered = 1;
+ return 0;
}
#else
#define init_vga_switcheroo(chip) /* NOP */
@@ -2713,7 +2720,8 @@ static int azx_free(struct azx *chip)
if (use_vga_switcheroo(chip)) {
if (chip->disabled && chip->bus)
snd_hda_unlock_devices(chip->bus);
- vga_switcheroo_unregister_client(chip->pci);
+ if (chip->vga_switcheroo_registered)
+ vga_switcheroo_unregister_client(chip->pci);
}
if (chip->initialized) {
@@ -3067,14 +3075,6 @@ static int __devinit azx_create(struct snd_card *card,
struct pci_dev *pci,
}
ok:
- err = register_vga_switcheroo(chip);
- if (err < 0) {
- snd_printk(KERN_ERR SFX
- "Error registering VGA-switcheroo client\n");
- azx_free(chip);
- return err;
- }
-
err = snd_device_new(card, SNDRV_DEV_LOWLEVEL, chip, );
if (err < 0) {
snd_printk(KERN_ERR SFX "Error creating device [card]!\n");
@@ -3345,6 +3345,13 @@ static int __devinit azx_probe(struct pci_dev *pci,
if (pci_dev_run_wake(pci))
pm_runtime_put_noidle(>dev);
+ err = register_vga_switcheroo(chip);
+ if (err < 0) {
+ snd_printk(KERN_ERR SFX
+ "Error registering VGA-switcheroo client\n");
+ goto out_free;
+ }
+
dev++;
return 0;
--
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 06/06] input/rmi4: F11 - 2D touch interface
On Sat, Oct 6, 2012 at 6:10 AM, Christopher Heiny wrote:
So looking closer at this one since we will use it. Maybe it's in such a
good shape now that I should be able to actually test it with the hardware?
(...)
> diff --git a/drivers/input/rmi4/rmi_f11.c b/drivers/input/rmi4/rmi_f11.c
(...)
> +#ifdef CONFIG_RMI4_DEBUG
> +#include
> +#include
> +#include
> +#endif
Skip the #ifdef
> +#define F11_CTRL_SENSOR_MAX_X_POS_OFFSET 6
> +#define F11_CTRL_SENSOR_MAX_Y_POS_OFFSET 8
> +
> +#define F11_CEIL(x, y) (((x) + ((y)-1)) / (y))
Use existing kernel macros in
In this case:
#define F11_CEIL(x, y) DIV_ROUND_UP(x, y)
Or just use DIV_ROUND_UP() directly in the code, your choice.
> +#define MAX_NAME_LENGTH 256
Really? Are you sure there is not a null terminator or length byte
included so it's actually 255?
(...)
> +static int sensor_debug_open(struct inode *inodep, struct file *filp)
> +{
> + struct sensor_debugfs_data *data;
> + struct f11_2d_sensor *sensor = inodep->i_private;
> + struct rmi_function_container *fc = sensor->fc;
> +
> + data = devm_kzalloc(>dev, sizeof(struct sensor_debugfs_data),
> + GFP_KERNEL);
Again I may have lead you astray. Check if this leaks memory, in that
case use kzalloc()/kfree(). Sorry :-(
(...)
> +static int f11_debug_open(struct inode *inodep, struct file *filp)
> +{
> + struct f11_debugfs_data *data;
> + struct rmi_function_container *fc = inodep->i_private;
> +
> + data = devm_kzalloc(>dev, sizeof(struct f11_debugfs_data),
> + GFP_KERNEL);
Dito. :-(
(...)
> +static void rmi_f11_abs_pos_report(struct f11_data *f11,
> + struct f11_2d_sensor *sensor,
> + u8 finger_state, u8 n_finger)
(...)
> + if (axis_align->flip_y)
> + y = max(sensor->max_y - y, 0);
> +
> + /*
> + ** here checking if X offset or y offset are specified is
> + ** redundant. We just add the offsets or, clip the values
> + **
> + ** note: offsets need to be done before clipping occurs,
> + ** or we could get funny values that are outside
> + ** clipping boundaries.
> + */
This is a weird commenting style, what's wrong with a single star?
(No big deal but it stands out...)
(...)
> +static int f11_allocate_control_regs(struct rmi_device *rmi_dev,
> + struct f11_2d_device_query *device_query,
> + struct f11_2d_sensor_query *sensor_query,
> + struct f11_2d_ctrl *ctrl,
> + u16 ctrl_base_addr) {
> +
> + struct rmi_driver_data *driver_data = dev_get_drvdata(_dev->dev);
> + struct rmi_function_container *fc = driver_data->f01_container;
> +
> + ctrl->ctrl0_9 = devm_kzalloc(>dev, sizeof(union f11_2d_ctrl0_9),
> + GFP_KERNEL);
If this is called from .probe() only, this is correct.
So the rule is: use devm_* for anything that is allocated at .probe()
and released on .remove(). Any other dynamic buffers etc need to
use common kzalloc()/kfree().
> + if (!ctrl->ctrl0_9)
> + return -ENOMEM;
> + if (sensor_query->f11_2d_query7__8[0]) {
> + ctrl->ctrl10 = devm_kzalloc(>dev,
> + sizeof(union f11_2d_ctrl10), GFP_KERNEL);
> + if (!ctrl->ctrl10)
> + return -ENOMEM;
> + }
> +
> + if (sensor_query->f11_2d_query7__8[1]) {
> + ctrl->ctrl11 = devm_kzalloc(>dev,
> + sizeof(union f11_2d_ctrl11), GFP_KERNEL);
> + if (!ctrl->ctrl11)
> + return -ENOMEM;
> + }
> +
> + if (device_query->has_query9 && sensor_query->query9.has_pen) {
> + ctrl->ctrl20_21 = devm_kzalloc(>dev,
> + sizeof(union f11_2d_ctrl20_21), GFP_KERNEL);
> + if (!ctrl->ctrl20_21)
> + return -ENOMEM;
> + }
> +
> + if (device_query->has_query9 && sensor_query->query9.has_proximity) {
> + ctrl->ctrl22_26 = devm_kzalloc(>dev,
> + sizeof(union f11_2d_ctrl22_26), GFP_KERNEL);
> + if (!ctrl->ctrl22_26)
> + return -ENOMEM;
> + }
> +
> + if (device_query->has_query9 &&
> + (sensor_query->query9.has_palm_det_sensitivity ||
> + sensor_query->query9.has_suppress_on_palm_detect)) {
> + ctrl->ctrl27 = devm_kzalloc(>dev,
> + sizeof(union f11_2d_ctrl27), GFP_KERNEL);
> + if (!ctrl->ctrl27)
> + return -ENOMEM;
> + }
> +
> + if (sensor_query->has_multi_finger_scroll) {
> + ctrl->ctrl28 = devm_kzalloc(>dev,
> +
Re: [PATCH v3 10/10] mm: kill vma flag VM_RESERVED and mm->reserved_vm counter
On Tue, 2012-07-31 at 14:42 +0400, Konstantin Khlebnikov wrote: > A long time ago, in v2.4, VM_RESERVED kept swapout process off VMA, > currently it lost original meaning but still has some effects: > > | effect | alternative flags > -++- > 1| account as reserved_vm | VM_IO > 2| skip in core dump | VM_IO, VM_DONTDUMP > 3| do not merge or expand | VM_IO, VM_DONTEXPAND, VM_HUGETLB, VM_PFNMAP > 4| do not mlock | VM_IO, VM_DONTEXPAND, VM_HUGETLB, VM_PFNMAP > > This patch removes reserved_vm counter from mm_struct. > Seems like nobody cares about it, it does not exported into userspace > directly, > it only reduces total_vm showed in proc. > > Thus VM_RESERVED can be replaced with VM_IO or pair VM_DONTEXPAND | > VM_DONTDUMP. > > remap_pfn_range() and io_remap_pfn_range() set > VM_IO|VM_DONTEXPAND|VM_DONTDUMP. > remap_vmalloc_range() set VM_DONTEXPAND | VM_DONTDUMP. > > Signed-off-by: Konstantin Khlebnikov > Cc: Nick Piggin > Cc: Hugh Dickins > --- > Documentation/vm/unevictable-lru.txt |4 ++-- > arch/alpha/kernel/pci-sysfs.c|2 +- > arch/ia64/kernel/perfmon.c |2 +- > arch/ia64/mm/init.c |3 ++- > arch/powerpc/kvm/book3s_hv.c |2 +- > arch/sparc/kernel/pci.c |2 +- > arch/unicore32/kernel/process.c |2 +- > arch/x86/xen/mmu.c |3 +-- > drivers/char/mbcs.c |2 +- > drivers/char/mem.c |2 +- > drivers/char/mspec.c |2 +- > drivers/gpu/drm/drm_gem.c|2 +- > drivers/gpu/drm/drm_vm.c | 10 ++ > drivers/gpu/drm/exynos/exynos_drm_gem.c |2 +- > drivers/gpu/drm/gma500/framebuffer.c |3 +-- > drivers/gpu/drm/ttm/ttm_bo_vm.c |4 ++-- > drivers/gpu/drm/udl/udl_fb.c |2 +- > drivers/infiniband/hw/ehca/ehca_uverbs.c |4 ++-- > drivers/infiniband/hw/ipath/ipath_file_ops.c |2 +- > drivers/infiniband/hw/qib/qib_file_ops.c |2 +- > drivers/media/video/meye.c |2 +- > drivers/media/video/omap/omap_vout.c |2 +- > drivers/media/video/sn9c102/sn9c102_core.c |3 +-- > drivers/media/video/usbvision/usbvision-video.c |3 +-- > drivers/media/video/videobuf-dma-sg.c|2 +- > drivers/media/video/videobuf-vmalloc.c |2 +- > drivers/media/video/videobuf2-memops.c |2 +- > drivers/media/video/vino.c |2 +- > drivers/misc/carma/carma-fpga.c |2 -- > drivers/misc/sgi-gru/grufile.c |5 ++--- > drivers/mtd/mtdchar.c|2 +- > drivers/scsi/sg.c|2 +- > drivers/staging/media/easycap/easycap_main.c |2 +- > drivers/staging/omapdrm/omap_gem_dmabuf.c|2 +- > drivers/staging/tidspbridge/rmgr/drv_interface.c |2 +- > drivers/uio/uio.c|4 +--- > drivers/usb/mon/mon_bin.c|2 +- > drivers/video/68328fb.c |2 +- > drivers/video/aty/atyfb_base.c |3 +-- > drivers/video/fb-puv3.c |3 +-- > drivers/video/fb_defio.c |2 +- > drivers/video/fbmem.c|3 +-- > drivers/video/gbefb.c|2 +- > drivers/video/omap2/omapfb/omapfb-main.c |2 +- > drivers/video/sbuslib.c |5 ++--- > drivers/video/smscufx.c |1 - > drivers/video/udlfb.c|1 - > drivers/video/vermilion/vermilion.c |1 - > drivers/video/vfb.c |1 - > drivers/xen/gntalloc.c |2 +- > drivers/xen/gntdev.c |2 +- > drivers/xen/privcmd.c|3 ++- > fs/binfmt_elf.c |2 +- > fs/binfmt_elf_fdpic.c|2 +- > fs/hugetlbfs/inode.c |2 +- > fs/proc/task_mmu.c |2 +- > include/linux/mempolicy.h|2 +- > include/linux/mm.h |3 +-- > include/linux/mm_types.h |1 - > kernel/events/core.c |2 +- > mm/ksm.c |3 +-- > mm/memory.c | 11 +-- > mm/mlock.c
Re: [remoteproc:for-next 6/9] remoteproc_virtio.c:(.text+0x238e7e): undefined reference to `vring_transport_features'
Hi Sjur, On Tue, Oct 2, 2012 at 10:24 AM, Ohad Ben-Cohen wrote: > On Mon, Oct 1, 2012 at 4:45 AM, Fengguang Wu wrote: >> Hi Ohad, >> >> FYI, kernel build failed on >> >> tree: git://git.kernel.org/pub/scm/linux/kernel/git/ohad/remoteproc.git >> for-next >> head: bec109a430e8c67bae1743f7e71898283234a77f >> commit: ec4d02d9180f407c41f8310a13b34e473c671fbb [6/9] remoteproc: Add STE >> modem driver >> config: i386-randconfig-b102 (attached as .config) >> >> It should be an old bug. The commit happen to be the one to trigger >> the errors because it selects CONFIG_EMOTEPROC. > > Thanks Fengguang. > > This should be fixed by a patch I pushed today to remoteproc's for-next > branch. > > Though I wonder, Sjur, do we want to limit the architectures/platforms > where the STE modem driver can be selected on ? Is it ARM only perhaps ? Can you please address the above question ? Thanks, Ohad. -- 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 1/6] Add header files and Kbuild plumbing for SI476x MFD core
On Mon 8 October 2012 20:38:01 Andrey Smirnov wrote:
> On 10/08/2012 01:43 AM, Hans Verkuil wrote:
> > On Sat October 6 2012 03:54:57 Andrey Smirnov wrote:
> >> This patch adds all necessary header files and Kbuild plumbing for the
> >> core driver for Silicon Laboratories Si476x series of AM/FM tuner
> >> chips.
> >>
> >> The driver as a whole is implemented as an MFD device and this patch
> >> adds a core portion of it that provides all the necessary
> >> functionality to the two other drivers that represent radio and audio
> >> codec subsystems of the chip.
> >>
> >> Signed-off-by: Andrey Smirnov
> >> ---
> >> drivers/mfd/Kconfig | 14 ++
> >> drivers/mfd/Makefile|3 +
> >> include/linux/mfd/si476x-core.h | 529
> >> +++
> >> include/media/si476x.h | 449 +
> >> 4 files changed, 995 insertions(+)
> >> create mode 100644 include/linux/mfd/si476x-core.h
> >> create mode 100644 include/media/si476x.h
> >>
> >> diff --git a/include/linux/mfd/si476x-core.h
> >> b/include/linux/mfd/si476x-core.h
> >> new file mode 100644
> >> index 000..eb6f52a
> >> --- /dev/null
> >> +++ b/include/linux/mfd/si476x-core.h
> >> +#define SI476X_IOC_GET_RSQ_IOWR('V', BASE_VIDIOC_PRIVATE
> >> + 0, \
> >> +struct si476x_rsq_status_report)
> >> +
> >> +#define SI476X_IOC_SET_PHDIV_MODE _IOW('V', BASE_VIDIOC_PRIVATE + 1, \
> >> + enum si476x_phase_diversity_mode)
> >> +
> >> +#define SI476X_IOC_GET_PHDIV_STATUS _IOWR('V', BASE_VIDIOC_PRIVATE
> >> + 2, \
> >> +int)
> >> +
> >> +#define SI476X_IOC_GET_RSQ_PRIMARY_IOWR('V', BASE_VIDIOC_PRIVATE
> >> + 3, \
> >> +struct si476x_rsq_status_report)
> >> +
> >> +#define SI476X_IOC_GET_ACF_IOWR('V', BASE_VIDIOC_PRIVATE
> >> + 4, \
> >> +struct si476x_acf_status_report)
> >> +
> >> +#define SI476X_IOC_GET_AGC_IOWR('V', BASE_VIDIOC_PRIVATE
> >> + 5, \
> >> +struct si476x_agc_status_report)
> >> +
> >> +#define SI476X_IOC_GET_RDS_BLKCNT _IOWR('V', BASE_VIDIOC_PRIVATE + 6, \
> >> + struct si476x_rds_blockcount_report)
> > There is no documentation at all for these private ioctls. At the very least
> > these should be documentated (both the ioctl and the structs they receive).
> >
> > More importantly, are these ioctls really needed?
>
> I apologize for not writing the documentation for those ioctls. I
> thought I at least did so for all data structures returned by those
> calls, I guess I never got around to doing it. I'll document all the
> ioctls in the next version of the patch.
>
> SI476X_IOC_SET_PHDIV_MODE, SI476X_IOC_GET_PHDIV_STATUS are definitely
> needed since they are used to control antenna phase diversity modes of
> the tuners. In that mode two Si4764 chips connected to different
> antennas can act as a single tuner and use both signal to improve
> sensibility.
Interesting. But I wonder if this can be implemented as controls? That seems
to me to be a better fit.
> The rest is useful to get different radio signal parameters from the
> chip. We used it for during RF performance evaluation of the
> boards(probably using it in EOL testing).
>
> > If the purpose is to return
> > status information for debugging, then you should consider implementing
> > VIDIOC_LOG_STATUS instead.
>
> For me, the problem with using VIDIOC_LOG_STATUS is that it dumps all
> the debugging information in kernel log buffer, meaning that if one
> wants to pass that information to some other application they would have
> to resort to screen-scraping of the output of dmesg. Unfortunately the
> people who were using this driver/as a part of a software suite during
> aforementioned RF performance testing are not Linux-savvy enough to be
> asked to use dmesg and they want a GUI solution. That small test utility
> was written and it uses those those ioctls to gather and display all
> signal related information. I guess the other solution for that problem
> would be to create corresponding files in sysfs, but I'm not sure if
> creating multitude of files in sysfs tree is a better option.
Definitely not, although using debugfs might be a good idea.
> Since this version of the driver has not been integrated into our
> software package the we install on laptops to do all the board testing I
> guess I can remove those 'ioctl', but I would love to find acceptable
> solution so that later I would be able to integrate upstream driver int
> our package and not use "special" version of the driver for our purposes.
Can you split off the implementation of these ioctls from the rest of the
driver? And I think you should look into debugfs to see if that isn't a
Linux 3.0+ Disk performance problem - wrong pdflush behaviour
Hello,
Since Kernel version 3.0 pdflush blocks writes even the dirty bytes are
well below /proc/sys/vm/dirty_bytes or /proc/sys/vm/dirty_ratio.
The kernel 2.6.39 works nice.
How this hurt us in the real life: We have a very high performance game
server where the MySQL have to do many writes along the reads. All
writes and reads are very simple and have to be very quick. If we run
the system with Linux 3.2 we get unacceptable performance. Now we are
stuck with 2.6.32 kernel here because this problem.
I attach the test program wrote by me which shows the problem. The
program just writes blocks continously to random position to a given big
file. The write rate limited to 100 MByte/s. In a well-working kernel it
have to run with constant 100 MBit/s speed for indefinite long. The test
have to be run on a simple HDD.
Test steps:
1. You have to use an XFS, EXT2 or ReiserFS partition for the test, Ext4
forces flushes periodically. I recommend to use XFS.
2. create a big file on the test partiton. For 8 GByte RAM you can
create a 2 GByte file. For 2 GB RAM I recommend to create 500MByte file.
File creation can be done with this command: dd if=/dev/zero
of=bigfile2048M.bin bs=1M count=2048
3. compile pdflushtest.c: (gcc -o pdflushtest pdflushtest.c)
4. run pdflushtest: ./pdflushtest --file=/where/is/the/bigfile2048M.bin
In the beginning there can be some slowness even on well-working
kernels. If you create the bigfile in the same run then it runs usually
smootly from the beginning.
I don't know a setting of /proc/sys/vm variables which runs this test
smootly on a 3.2.29 (3.0+) kernel. I think this is a kernel bug, because
if I have much more "/proc/sys/vm/dirty_bytes" than the testfile size
the test program should never be blocked.
A sample result:
11:20:05: speed: 99.994 MiB/s, time usage: 4.60 %, avg. block
time:1.8 us, max. block time: 18 us
11:20:06: speed: 99.994 MiB/s, time usage: 4.60 %, avg. block
time:1.8 us, max. block time: 10 us
11:20:07: speed: 99.994 MiB/s, time usage: 4.62 %, avg. block
time:1.8 us, max. block time: 11 us
11:20:08: speed: 99.989 MiB/s, time usage: 4.59 %, avg. block
time:1.8 us, max. block time: 58 us
11:20:09: speed: 99.997 MiB/s, time usage: 4.55 %, avg. block
time:1.8 us, max. block time: 13 us
11:20:10: speed: 28.840 MiB/s, time usage: 96.47 %, avg. block time:
130.7 us, max. block time: 114076 us
11:20:11: speed: 30.505 MiB/s, time usage: 98.14 %, avg. block time:
125.7 us, max. block time: 135008 us
11:20:12: speed: 25.956 MiB/s, time usage: 99.71 %, avg. block time:
150.1 us, max. block time: 129839 us
11:20:13: speed: 25.088 MiB/s, time usage: 96.43 %, avg. block time:
150.1 us, max. block time: 149649 us
11:20:14: speed: 32.438 MiB/s, time usage: 98.64 %, avg. block time:
118.8 us, max. block time: 145649 us
11:20:15: speed: 22.765 MiB/s, time usage: 99.11 %, avg. block time:
170.1 us, max. block time: 159749 us
At 11:20:10 the pdflush started its work, based on the
"dirty_expire_centisecs". The test file was 2GByte, the
/proc/sys/vm/dirty_bytes/dirty_bytes was 40. The system (i5-3.4
GHz, 8G RAM, Kernel 3.2.29-amd64) was booted to run this test only so it
had 2,2 GByte RAM for cache, and 5.1 GByte RAM free (totally unused).
Sorry if I not found the right place to report this, please advise me
were to send.
Best regards
Viktor Nagy
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
// parameters
char * filename = NULL;
enum testermode {READ, WRITE} mode = WRITE;
float speedlimit = 100; // MiB / s
int burstcount = 10;
// internals
int blocksize = 4096;
int blockcount = 0;
int fh = 0;
char filebuffer[65536];
static struct option long_options[] =
{
{"mode", required_argument, 0, 0 },
{"m", required_argument, 0, 0 },
{"file",required_argument, 0, 0 },
{"f",required_argument, 0, 0 },
{"limit",required_argument, 0, 0 },
{"l",required_argument, 0, 0 },
{"burst",required_argument, 0, 0 },
{"b",required_argument, 0, 0 },
{0, 0, 0, 0 }
};
void parse_commandline(int argc, char **argv)
{
int r;
int option_index = 0;
while (0 <= (r = getopt_long_only(argc, argv, "", long_options, _index)))
{
const char * optname = long_options[option_index].name;
if (r == 0)
{
if (strcmp("file", optname) == 0 || strcmp("f", optname) == 0)
{
filename = strdup(optarg);
}
else if (strcmp("mode", optname) == 0 || strcmp("m", optname) == 0)
{
if (strcmp("reader", optarg) == 0 || strcmp("read", optarg) == 0)
{
mode = READ;
}
else if (strcmp("writer", optarg) == 0 || strcmp("write", optarg) == 0)
{
mode = WRITE;
}
else
{
printf("Invalid mode: \"%s\"\n", optarg);
}
}
else if (strcmp("burst", optname) == 0 || strcmp("b", optname) == 0)
{
burstcount =
[PATCH] pch_gbe: Fix build error by selecting all the possible dependencies.
Fengguang reported a kernel build failure as following: drivers/built-in.o: In function `pch_gbe_ioctl': pch_gbe_main.c:(.text+0x510370): undefined reference to `pch_ch_control_write' pch_gbe_main.c:(.text+0x510393): undefined reference to `pch_ch_control_write' pch_gbe_main.c:(.text+0x5103b3): undefined reference to `pch_ch_control_write' ... It's a regression by commit da1586461. The root cause is that the CONFIG_PPS is not set there, consequently CONFIG_PTP_1588_CLOCK can not be set anyway, which finally causes ptp_pch and pch_gbe_main build failures. As David prefers to use *select* to fix such module co-dependency issues, this patch explicitly selects all the possible dependencies of PCH_PTP. Reported-by: Fengguang Wu Reviewed-by: David S. Miller Signed-off-by: Haicheng Li --- drivers/net/ethernet/oki-semi/pch_gbe/Kconfig |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/drivers/net/ethernet/oki-semi/pch_gbe/Kconfig b/drivers/net/ethernet/oki-semi/pch_gbe/Kconfig index 9730241..5296cc8 100644 --- a/drivers/net/ethernet/oki-semi/pch_gbe/Kconfig +++ b/drivers/net/ethernet/oki-semi/pch_gbe/Kconfig @@ -26,6 +26,9 @@ if PCH_GBE config PCH_PTP bool "PCH PTP clock support" default n + depends on EXPERIMENTAL + select PPS + select PTP_1588_CLOCK select PTP_1588_CLOCK_PCH ---help--- Say Y here if you want to use Precision Time Protocol (PTP) in the -- 1.7.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: [GIT PULL] Disintegrate UAPI for avr32 [ver #2]
Around Tue 09 Oct 2012 10:15:15 +0100 or thereabout, David Howells wrote:
> Can you merge the following branch into the avr32 tree please.
>
Neither Haavard or me have a GIT tree at kernel.org anymore, I hope to get my
key signed in Barcelona during ELCE. Could you ask Linus to pull directly, or
pass it through Andrew.
> This is to complete part of the UAPI disintegration for which the preparatory
> patches were pulled recently.
>
> Now that the fixups and the asm-generic chunk have been merged, I've
> regenerated the patches to get rid of those dependencies and to take account
> of
> any changes made so far in the merge window. If you have already pulled the
> older version of the branch aimed at you, then please feel free to ignore this
> request.
>
> The following changes since commit 9e2d8656f5e8aa214e66b462680cf86b210b74a8:
>
> Merge branch 'akpm' (Andrew's patch-bomb) (2012-10-09 16:23:15 +0900)
>
> are available in the git repository at:
>
>
> git://git.infradead.org/users/dhowells/linux-headers.git
> tags/disintegrate-avr32-20121009
>
> for you to fetch changes up to b9ba6b52cfb7f564c205bc42fed3297d623fc50f:
>
> UAPI: (Scripted) Disintegrate arch/avr32/include/asm (2012-10-09 09:46:37
> +0100)
>
>
> UAPI Disintegration 2012-10-09
>
>
> David Howells (1):
> UAPI: (Scripted) Disintegrate arch/avr32/include/asm
>
> arch/avr32/include/asm/Kbuild | 3 -
> arch/avr32/include/asm/param.h | 18 +-
> arch/avr32/include/asm/ptrace.h | 115 +
> arch/avr32/include/asm/setup.h | 5 +-
> arch/avr32/include/asm/signal.h | 121 +-
> arch/avr32/include/asm/termios.h| 41 +---
> arch/avr32/include/asm/types.h | 6 +-
> arch/avr32/include/asm/unistd.h | 296 +--
> arch/avr32/include/uapi/asm/Kbuild | 32 +++
> arch/avr32/include/{ => uapi}/asm/auxvec.h | 0
> arch/avr32/include/{ => uapi}/asm/bitsperlong.h | 0
> arch/avr32/include/{ => uapi}/asm/byteorder.h | 0
> arch/avr32/include/{ => uapi}/asm/cachectl.h| 0
> arch/avr32/include/{ => uapi}/asm/errno.h | 0
> arch/avr32/include/{ => uapi}/asm/fcntl.h | 0
> arch/avr32/include/{ => uapi}/asm/ioctl.h | 0
> arch/avr32/include/{ => uapi}/asm/ioctls.h | 0
> arch/avr32/include/{ => uapi}/asm/ipcbuf.h | 0
> arch/avr32/include/{ => uapi}/asm/kvm_para.h| 0
> arch/avr32/include/{ => uapi}/asm/mman.h| 0
> arch/avr32/include/{ => uapi}/asm/msgbuf.h | 0
> arch/avr32/include/uapi/asm/param.h | 18 ++
> arch/avr32/include/{ => uapi}/asm/poll.h| 0
> arch/avr32/include/{ => uapi}/asm/posix_types.h | 0
> arch/avr32/include/uapi/asm/ptrace.h| 126 ++
> arch/avr32/include/{ => uapi}/asm/resource.h| 0
> arch/avr32/include/{ => uapi}/asm/sembuf.h | 0
> arch/avr32/include/uapi/asm/setup.h | 17 ++
> arch/avr32/include/{ => uapi}/asm/shmbuf.h | 0
> arch/avr32/include/{ => uapi}/asm/sigcontext.h | 0
> arch/avr32/include/{ => uapi}/asm/siginfo.h | 0
> arch/avr32/include/uapi/asm/signal.h| 128 ++
> arch/avr32/include/{ => uapi}/asm/socket.h | 0
> arch/avr32/include/{ => uapi}/asm/sockios.h | 0
> arch/avr32/include/{ => uapi}/asm/stat.h| 0
> arch/avr32/include/{ => uapi}/asm/statfs.h | 0
> arch/avr32/include/{ => uapi}/asm/swab.h| 0
> arch/avr32/include/{ => uapi}/asm/termbits.h| 0
> arch/avr32/include/uapi/asm/termios.h | 50
> arch/avr32/include/uapi/asm/types.h | 8 +
> arch/avr32/include/uapi/asm/unistd.h| 305
>
> 41 files changed, 692 insertions(+), 597 deletions(-)
> rename arch/avr32/include/{ => uapi}/asm/auxvec.h (100%)
> rename arch/avr32/include/{ => uapi}/asm/bitsperlong.h (100%)
> rename arch/avr32/include/{ => uapi}/asm/byteorder.h (100%)
> rename arch/avr32/include/{ => uapi}/asm/cachectl.h (100%)
> rename arch/avr32/include/{ => uapi}/asm/errno.h (100%)
> rename arch/avr32/include/{ => uapi}/asm/fcntl.h (100%)
> rename arch/avr32/include/{ => uapi}/asm/ioctl.h (100%)
> rename arch/avr32/include/{ => uapi}/asm/ioctls.h (100%)
> rename arch/avr32/include/{ => uapi}/asm/ipcbuf.h (100%)
> rename arch/avr32/include/{ => uapi}/asm/kvm_para.h (100%)
&
Linux 2.6.32.60
I've just released Linux 2.6.32.60. This release contains, among others, a number of fixes for random and NTP, including for the NTP leap second bug. Users should upgrade. The patch and changelog will appear soon at the following locations: ftp://ftp.all.kernel.org/pub/linux/kernel/v2.6/longterm/v2.6.32/ ftp://ftp.all.kernel.org/pub/linux/kernel/v2.6/longterm/v2.6.32/patch-2.6.32.60.bz2 ftp://ftp.all.kernel.org/pub/linux/kernel/v2.6/longterm/v2.6.32/patch-2.6.32.60.xz ftp://ftp.all.kernel.org/pub/linux/kernel/v2.6/longterm/v2.6.32/patch-2.6.32.60.gz ftp://ftp.all.kernel.org/pub/linux/kernel/v2.6/longterm/v2.6.32/ChangeLog-2.6.32.60 The updated 2.6.32.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-2.6.32.y http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-2.6.32.y The tree can be browsed on the gitweb interface: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=shortlog;h=refs/heads/linux-2.6.32.y Testing status (build/boot, OK/FAIL, otherwise not tested) : ARCH | CONFIGURATION +--- | allmodconfig other-config arm |build:OK- x86_64 |build:OK- i386 |build:OK boot:OK Thanks to all reviewers, especially Ben for his long careful review, and to Greg for the final packaging. Willy - Documentation/kernel-parameters.txt | 5 + Documentation/stable_kernel_rules.txt | 6 + MAINTAINERS | 2 +- Makefile| 2 +- arch/arm/kernel/sys_arm.c | 2 +- arch/ia64/include/asm/unistd.h | 3 +- arch/ia64/kernel/entry.S| 13 ++ arch/ia64/kernel/irq_ia64.c | 1 - arch/ia64/kvm/kvm-ia64.c| 5 + arch/mips/include/asm/thread_info.h | 4 +- arch/mips/kernel/vmlinux.lds.S | 3 +- arch/parisc/include/asm/atomic.h| 4 +- arch/powerpc/include/asm/reg.h | 3 +- arch/powerpc/kernel/ftrace.c| 12 +- arch/powerpc/kernel/module_32.c | 11 +- arch/powerpc/platforms/powermac/smp.c | 2 +- arch/sparc/Makefile | 2 +- arch/sparc/kernel/ds.c | 2 +- arch/sparc/kernel/rtrap_64.S| 7 - arch/x86/Kconfig| 9 + arch/x86/include/asm/archrandom.h | 75 +++ arch/x86/include/asm/cpufeature.h | 2 + arch/x86/include/asm/k8.h | 2 + arch/x86/include/asm/kvm_emulate.h | 15 ++ arch/x86/include/asm/timer.h| 8 +- arch/x86/kernel/cpu/Makefile| 1 + arch/x86/kernel/cpu/common.c| 2 + arch/x86/kernel/cpu/rdrand.c| 73 +++ arch/x86/kernel/k8.c| 31 +++ arch/x86/kernel/tls.c | 4 +- arch/x86/kernel/tsc.c | 3 +- arch/x86/kvm/emulate.c | 57 - arch/x86/kvm/i8254.c| 10 +- arch/x86/kvm/irq.h | 6 +- arch/x86/kvm/x86.c | 61 +- arch/x86/lib/delay.c| 4 +- arch/x86/mm/fault.c | 10 +- arch/x86/mm/pageattr.c | 18 +- arch/x86/mm/pgtable.c | 11 +- arch/x86/oprofile/backtrace.c | 4 +- arch/x86/pci/amd_bus.c | 43 +--- arch/x86/xen/enlighten.c| 3 + arch/x86/xen/mmu.c | 10 +- arch/x86/xen/xen-asm.S | 2 +- block/blk-ioc.c | 12 +- crypto/sha512_generic.c | 2 +- drivers/acpi/ac.c | 4 +- drivers/block/cciss_scsi.c | 12 +- drivers/block/sx8.c | 2 +- drivers/bluetooth/btusb.c | 9 +- drivers/bluetooth/hci_ldisc.c | 6 +- drivers/char/random.c | 375 +--- drivers/char/tty_audit.c| 4 +- drivers/dma/ioat/dma_v2.c | 34 +-- drivers/dma/ioat/dma_v2.h | 2 - drivers/firmware/dmi_scan.c | 3 + drivers/firmware/pcdp.c | 4 +- drivers/gpu/drm/i915/intel_display.c| 11 +- drivers/mfd/wm831x-otp.c| 8 + drivers/mtd/nand/cafe_nand.c| 2 +- drivers/net/atlx/atl1.c | 12 +- drivers/net/atlx/atl1.h | 3 +- drivers/net/atlx/atlx.c | 2 +- drivers/net/bonding/bond_3ad.c | 7 +- drivers/net/dl2k.c | 157 + drivers/net/dl2k.h | 117 +- drivers/net/ks8851_mll.c| 2 +- drivers/net/netxen/netxen_nic.h | 7 +- drivers/net/netxen/netxen_nic_ctx.c |
Re: [PATCH v2 3/6] Add commands abstraction layer for SI476X MFD
On Mon 8 October 2012 22:06:29 Andrey Smirnov wrote:
> On 10/08/2012 01:56 AM, Hans Verkuil wrote:
> > On Sat October 6 2012 03:54:59 Andrey Smirnov wrote:
> >> This patch adds all the functions used for exchanging commands with
> >> the chip.
> >>
> >> Signed-off-by: Andrey Smirnov
> >> ---
> >> drivers/mfd/si476x-cmd.c | 1493
> >> ++
> >> 1 file changed, 1493 insertions(+)
> >> create mode 100644 drivers/mfd/si476x-cmd.c
> >>
> >> diff --git a/drivers/mfd/si476x-cmd.c b/drivers/mfd/si476x-cmd.c
> >> new file mode 100644
> >> index 000..f11cf58
> >> --- /dev/null
> >> +++ b/drivers/mfd/si476x-cmd.c
> >> +/**
> >> + * si476x_cmd_am_rsq_status - send 'FM_TUNE_FREQ' command to the
> >> + * device
> >> + * @core - device to send the command to
> >> + * @rsqack - if set command clears RSQINT, SNRINT, SNRLINT, RSSIHINT,
> >> + * RSSSILINT, BLENDINT, MULTHINT and MULTLINT
> >> + * @attune - when set the values in the status report are the values
> >> + * that were calculated at tune
> >> + * @cancel - abort ongoing seek/tune opertation
> >> + * @stcack - clear the STCINT bin in status register
> >> + * @report - all signal quality information retured by the command
> >> + * (if NULL then the output of the command is ignored)
I've just noticed that this comment block does not correspond at all to
the code. It's a good idea to check the other comment blocks for similar
copy/paste errors.
> >> + *
> >> + * Function returns 0 on success and negative error code on failure
> >> + */
> >> +int si476x_core_cmd_am_rsq_status(struct si476x_core *core,
> >> +struct si476x_rsq_status_args *rsqargs,
> >> +struct si476x_rsq_status_report *report)
> >> +{
> >> + int err;
> >> + u8 resp[CMD_AM_RSQ_STATUS_NRESP];
> >> + const u8 args[CMD_AM_RSQ_STATUS_NARGS] = {
> >> + rsqargs->rsqack << 3 | rsqargs->attune << 2 |
> >> + rsqargs->cancel << 1 | rsqargs->stcack,
> >> + };
> >> +
> >> + err = CORE_SEND_COMMAND(core, CMD_AM_RSQ_STATUS,
> >> + args, resp,
> >> + atomic_read(>timeouts.command));
> >> +
> >> + if (report) {
> > Do you really need to test 'report'? Does it ever make sense if this is
> > called with a NULL report pointer?
>
> Unfortunately yes. This command is also used to acknowledge and
> STC(seek-tune completed)
> interrupt.
A comment would be welcome here, and in similar cases. It's not obvious.
Regards,
Hans
--
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 5/6] Add a V4L2 driver for SI476X MFD
Note: I'm CC-ing Halli. Halli, can you take a look at the proposed controls?
On Mon 8 October 2012 19:57:17 Andrey Smirnov wrote:
> On 10/08/2012 02:30 AM, Hans Verkuil wrote:
> > On Sat October 6 2012 03:55:01 Andrey Smirnov wrote:
> >> This commit adds a driver that exposes all the radio related
> >> functionality of the Si476x series of chips via the V4L2 subsystem.
> >>
> >> Signed-off-by: Andrey Smirnov
> >> ---
> >> drivers/media/radio/Kconfig| 17 +
> >> drivers/media/radio/Makefile |1 +
> >> drivers/media/radio/radio-si476x.c | 1153
> >>
> >> 3 files changed, 1171 insertions(+)
> >> create mode 100644 drivers/media/radio/radio-si476x.c
> >>
> >> diff --git a/drivers/media/radio/Kconfig b/drivers/media/radio/Kconfig
> >> index 8090b87..3c79d09 100644
> >> --- a/drivers/media/radio/Kconfig
> >> +++ b/drivers/media/radio/Kconfig
> >> +static const struct v4l2_ctrl_config si476x_ctrls[] = {
> >> + /*
> >> + Tuning parameters
> >> + 'max tune errors' is shared for both AM/FM mode of operation
> >> + */
> >> + {
> >> + .ops= _ctrl_ops,
> >> + .id = SI476X_CID_RSSI_THRESHOLD,
> >> + .name = "valid rssi threshold",
> >> + .type = V4L2_CTRL_TYPE_INTEGER,
> >> + .min= -128,
> >> + .max= 127,
> >> + .step = 1,
> >> + },
> >> + {
> >> + .ops= _ctrl_ops,
> >> + .id = SI476X_CID_SNR_THRESHOLD,
> >> + .type = V4L2_CTRL_TYPE_INTEGER,
> >> + .name = "valid snr threshold",
> >> + .min= -128,
> >> + .max= 127,
> >> + .step = 1,
> >> + },
> >> + {
> >> + .ops= _ctrl_ops,
> >> + .id = SI476X_CID_MAX_TUNE_ERROR,
> >> + .type = V4L2_CTRL_TYPE_INTEGER,
> >> + .name = "max tune errors",
> >> + .min= 0,
> >> + .max= 126 * 2,
> >> + .step = 2,
> >> + },
> >> + /*
> >> + Region specific parameters
> >> + */
> >> + {
> >> + .ops= _ctrl_ops,
> >> + .id = SI476X_CID_HARMONICS_COUNT,
> >> + .type = V4L2_CTRL_TYPE_INTEGER,
> >> + .name = "count of harmonics to reject",
> >> + .min= 0,
> >> + .max= 20,
> >> + .step = 1,
> >> + },
> >> + {
> >> + .ops= _ctrl_ops,
> >> + .id = SI476X_CID_DEEMPHASIS,
> >> + .type = V4L2_CTRL_TYPE_MENU,
> >> + .name = "de-emphassis",
> >> + .qmenu = deemphasis,
> >> + .min= 0,
> >> + .max= ARRAY_SIZE(deemphasis) - 1,
> >> + .def= 0,
> >> + },
> > I think most if not all of the controls above are candidates for turning
> > into
> > standardized controls. I recommend that you make a proposal (RFC) for this.
> >
> > This may be useful as well:
> >
> > http://lists-archives.com/linux-kernel/27641304-radio-fixes-and-new-features-for-fm.html
> >
> > This patch series contains a standardized DEEMPHASIS control.
> > Note that this patch series is outdated, but patch 2/5 is OK.
>
> So do you want me to take that patch and make it the part of this patch
> set or do you want me to create a separate RFC with a patch set that
> contains all those controls?
No, that was just FYI. I've asked Halli Manjunatha, the author of that patch
series to make a new version that can be upstreamed. The reason it was stalled
was due to a long discussion at the time how to implement multiple frequency
bands, but now that that has been resolved this patch series can move forward
as well.
>
> Just to give some description:
>
> SI476X_CID_RSSI_THRESHOLD, SI476X_CID_SNR_THRESHOLD,
> SI476X_CID_MAX_TUNE_ERROR are used to determine at which level of SNR,
> RSSI the station station should be considered valid and what margin of
> error is to be used(SI476X_CID_MAX_TUNE_ERROR) for those parameters.
I know that other devices (wl128x) also have similar SNR, RSSI functionality.
Halli, can you check if it would make sense to have generic controls for this?
> SI476X_CID_HARMONICS_COUNT is the amount of AC grid noise harmonics
> build-in hardware(or maybe FW) will try to filter out in AM mode.
I don't really know whether this is chip specific or not. Halli, do you
have any input on this?
> It seems to me that the controls described above are quite chip specific
> should I also include them in the RFC?
Let's wait what Halli says, but yes, it should be included in the RFC: we
want to know if this should be standardized or not, so it's good to
mention it so people are aware of this.
> >> + {
> >> + .ops= _ctrl_ops,
> >> + .id = SI476X_CID_RDS_RECEPTION,
> >> + .type = V4L2_CTRL_TYPE_BOOLEAN,
> >> + .name = "rds",
> >> + .min= 0,
> >> + .max= 1,
> >> + .step = 1,
> >> + },
> > If this control returns whether or not RDS is detected,
Re: [GIT PULL] Disintegrate UAPI for microblaze
Michal Simek wrote: > I expect your intention is to merge this to mainline in current merge > window, right? It is preferred that it go through the maintainer's tree if possible. Note that I've posted a new version that doesn't have the dependencies any more as they've been merged upstream. David -- 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: [GIT PULL] Disintegrate UAPI for avr32 [ver #2]
Hans-Christian Egtvedt wrote: > Neither Haavard or me have a GIT tree at kernel.org anymore, I hope to get my > key signed in Barcelona during ELCE. Could you ask Linus to pull directly, or > pass it through Andrew. I can ask Linus directly. Can I add your Acked-by to it? David -- 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] driver/char/tpm: fix regression causesd by ppi
From: Gang Wei
This patch try to fix the S3 regression https://lkml.org/lkml/2012/10/5/433,
which includes below line:
[ 1554.684638] sysfs: cannot create duplicate filename '/devices/pnp0/00:0c/ppi'
The root cause is that ppi sysfs teardown code is MIA, so while S3 resume,
the ppi kobject will be created again upon existing one.
To make the tear down code simple, change the ppi subfolder creation from
using kobject_create_and_add to just using a named ppi attribute_group. Then
ppi sysfs teardown could be done with a simple sysfs_remove_group call.
Adjusted the name & return type for ppi sysfs init function.
Reported-by: Ben Guthro
Signed-off-by: Gang Wei
---
drivers/char/tpm/tpm.c |3 ++-
drivers/char/tpm/tpm.h |9 +++--
drivers/char/tpm/tpm_ppi.c | 18 ++
3 files changed, 19 insertions(+), 11 deletions(-)
diff --git a/drivers/char/tpm/tpm.c b/drivers/char/tpm/tpm.c
index f26afdb..b429f1e 100644
--- a/drivers/char/tpm/tpm.c
+++ b/drivers/char/tpm/tpm.c
@@ -1259,6 +1259,7 @@ void tpm_remove_hardware(struct device *dev)
misc_deregister(>vendor.miscdev);
sysfs_remove_group(>kobj, chip->vendor.attr_group);
+ tpm_remove_ppi(>kobj);
tpm_bios_log_teardown(chip->bios_dir);
/* write it this way to be explicit (chip->dev == dev) */
@@ -1476,7 +1477,7 @@ struct tpm_chip *tpm_register_hardware(struct device *dev,
goto put_device;
}
- if (sys_add_ppi(>kobj)) {
+ if (tpm_add_ppi(>kobj)) {
misc_deregister(>vendor.miscdev);
goto put_device;
}
diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
index 02c266a..8ef7649 100644
--- a/drivers/char/tpm/tpm.h
+++ b/drivers/char/tpm/tpm.h
@@ -329,10 +329,15 @@ extern int wait_for_tpm_stat(struct tpm_chip *, u8,
unsigned long,
wait_queue_head_t *);
#ifdef CONFIG_ACPI
-extern ssize_t sys_add_ppi(struct kobject *parent);
+extern int tpm_add_ppi(struct kobject *);
+extern void tpm_remove_ppi(struct kobject *);
#else
-static inline ssize_t sys_add_ppi(struct kobject *parent)
+static inline int tpm_add_ppi(struct kobject *parent)
{
return 0;
}
+
+static inline void tpm_remove_ppi(struct kobject *parent)
+{
+}
#endif
diff --git a/drivers/char/tpm/tpm_ppi.c b/drivers/char/tpm/tpm_ppi.c
index f27b58c..720ebcf 100644
--- a/drivers/char/tpm/tpm_ppi.c
+++ b/drivers/char/tpm/tpm_ppi.c
@@ -444,18 +444,20 @@ static struct attribute *ppi_attrs[] = {
_attr_vs_operations.attr, NULL,
};
static struct attribute_group ppi_attr_grp = {
+ .name = "ppi",
.attrs = ppi_attrs
};
-ssize_t sys_add_ppi(struct kobject *parent)
+int tpm_add_ppi(struct kobject *parent)
{
- struct kobject *ppi;
- ppi = kobject_create_and_add("ppi", parent);
- if (sysfs_create_group(ppi, _attr_grp))
- return -EFAULT;
- else
- return 0;
+ return sysfs_create_group(parent, _attr_grp);
+}
+EXPORT_SYMBOL_GPL(tpm_add_ppi);
+
+void tpm_remove_ppi(struct kobject *parent)
+{
+ sysfs_remove_group(parent, _attr_grp);
}
-EXPORT_SYMBOL_GPL(sys_add_ppi);
+EXPORT_SYMBOL_GPL(tpm_remove_ppi);
MODULE_LICENSE("GPL");
--
1.7.7.6
--
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] mm: Fix XFS oops due to dirty pages without buffers on s390
On Mon, Oct 08, 2012 at 09:24:40PM -0700, Hugh Dickins wrote:
> >
> > CC: Mel Gorman
>
> and I'm grateful to Mel's ack for reawakening me to it...
>
> > CC: linux-s...@vger.kernel.org
> > Signed-off-by: Jan Kara
>
> but I think it's wrong.
>
Dang.
> > ---
> > mm/rmap.c | 16 ++--
> > 1 files changed, 14 insertions(+), 2 deletions(-)
> >
> > diff --git a/mm/rmap.c b/mm/rmap.c
> > index 0f3b7cd..6ce8ddb 100644
> > --- a/mm/rmap.c
> > +++ b/mm/rmap.c
> > @@ -973,7 +973,15 @@ int page_mkclean(struct page *page)
> > struct address_space *mapping = page_mapping(page);
> > if (mapping) {
> > ret = page_mkclean_file(mapping, page);
> > - if (page_test_and_clear_dirty(page_to_pfn(page), 1))
> > + /*
> > +* We ignore dirty bit for pagecache pages. It is safe
> > +* as page is marked dirty iff it is writeable (page is
> > +* marked as dirty when it is made writeable and
> > +* clear_page_dirty_for_io() writeprotects the page
> > +* again).
> > +*/
> > + if (PageSwapCache(page) &&
> > + page_test_and_clear_dirty(page_to_pfn(page), 1))
> > ret = 1;
>
> This part you could cut out: page_mkclean() is not used on SwapCache pages.
> I believe you are safe to remove the page_test_and_clear_dirty() from here.
>
> > }
> > }
> > @@ -1183,8 +1191,12 @@ void page_remove_rmap(struct page *page)
> > * this if the page is anon, so about to be freed; but perhaps
> > * not if it's in swapcache - there might be another pte slot
> > * containing the swap entry, but page not yet written to swap.
> > +* For pagecache pages, we don't care about dirty bit in storage
> > +* key because the page is writeable iff it is dirty (page is marked
> > +* as dirty when it is made writeable and clear_page_dirty_for_io()
> > +* writeprotects the page again).
> > */
> > - if ((!anon || PageSwapCache(page)) &&
> > + if (PageSwapCache(page) &&
> > page_test_and_clear_dirty(page_to_pfn(page), 1))
> > set_page_dirty(page);
>
> But here's where I think the problem is. You're assuming that all
> filesystems go the same mapping_cap_account_writeback_dirty() (yeah,
> there's no such function, just a confusing maze of three) route as XFS.
>
> But filesystems like tmpfs and ramfs (perhaps they're the only two
> that matter here) don't participate in that, and wait for an mmap'ed
> page to be seen modified by the user (usually via pte_dirty, but that's
> a no-op on s390) before page is marked dirty; and page reclaim throws
> away undirtied pages.
>
> So, if I'm understanding right, with this change s390 would be in danger
> of discarding shm, and mmap'ed tmpfs and ramfs pages - whereas pages
> written with the write system call would already be PageDirty and secure.
>
In the case of ramfs, what marks the page clean so it could be discarded? It
does not participate in dirty accounting so it's not going to clear the
dirty flag in clear_page_dirty_for_io(). It doesn't have a writepage
handler that would use an end_io handler to clear the page after "IO"
completes. I am not seeing how a ramfs page can get discarded at the moment.
shm and tmpfs are indeed different and I did not take them into account
(ba dum tisch) when reviewing. For those pages would it be sufficient to
check the following?
PageSwapCache(page) || (page->mapping && !bdi_cap_account_dirty(page->mapping)
The problem the patch dealt with involved buffers associated with the page
and that shouldn't be a problem for tmpfs, right? I recognise that this
might work just because of co-incidence and set off your "Yuck" detector
and you'll prefer the proposed solution below.
> You mention above that even the kernel writing to the page would mark
> the s390 storage key dirty. I think that means that these shm and
> tmpfs and ramfs pages would all have dirty storage keys just from the
> clear_highpage() used to prepare them originally, and so would have
> been found dirty anyway by the existing code here in page_remove_rmap(),
> even though other architectures would regard them as clean and removable.
>
> If that's the case, then maybe we'd do better just to mark them dirty
> when faulted in the s390 case. Then your patch above should (I think)
> be safe. Though I'd then be VERY tempted to adjust the SwapCache case
> too (I've not thought through exactly what that patch would be, just
> one or two suitably placed SetPageDirtys, I think), and eliminate
> page_test_and_clear_dirty() altogether - no tears shed by any of us!
>
Do you mean something like this?
diff --git a/mm/memory.c b/mm/memory.c
index 5736170..c66166f 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -3316,7 +3316,20 @@ static int __do_fault(struct mm_struct *mm, struct
Re: [RFC PATCH 05/06] input/rmi4: F01 - device control
On Sat, Oct 6, 2012 at 6:10 AM, Christopher Heiny wrote:
> RMI Function 01 implements basic device control and power management
> behaviors for the RMI4 sensor. Since the last patch, we've decoupled
> rmi_f01.c
> implementation from rmi_driver.c, so rmi_f01.c acts as a standard driver
> module to handle F01 devices on the RMI bus.
>
> Like other modules, a number of attributes have been moved from sysfs to
> debugfs, depending on their expected use.
>
>
> rmi_f01.h exports definitions that we expect to be used by other functionality
> in the future (such as firmware reflash).
>
>
> Signed-off-by: Christopher Heiny
>
> Cc: Dmitry Torokhov
> Cc: Linus Walleij
> Cc: Naveen Kumar Gaddipati
> Cc: Joeri de Gram
>
> ---
There is liberal whitespacing above. (No big deal, but anyway.)
(...)
> +/**
> + * @reset - set this bit to force a firmware reset of the sensor.
> + */
> +union f01_device_commands {
> + struct {
> + bool reset:1;
> + u8 reserved:7;
> + } __attribute__((__packed__));
> + u8 reg;
> +};
I'm still scared by these unions. I see what you're doing but my
preferred style of driver writing is to use a simple u8 if you just treat
it the right way with some |= and &= ...
#include
#define F01_RESET BIT(0)
u8 my_command = F01_RESET;
send(_command);
I will not insist on this because it's a bit about programming style.
For memory-mapped devices we usually do it my way, but this
is more like some protocol and I know protocols like to do things
with structs and stuff so no big deal.
> +#ifdef CONFIG_RMI4_DEBUG
> +struct f01_debugfs_data {
> + bool done;
> + struct rmi_function_container *fc;
> +};
> +
> +static int f01_debug_open(struct inode *inodep, struct file *filp)
> +{
> + struct f01_debugfs_data *data;
> + struct rmi_function_container *fc = inodep->i_private;
> +
> + data = devm_kzalloc(>dev, sizeof(struct f01_debugfs_data),
> + GFP_KERNEL);
Wait, you probably did this because I requested it, but I was maybe
wrong?
Will this not re-allocate a chunk every time you look at a debugfs
file? So it leaks memory?
In that case common kzalloc() and kfree() is the way to go, as it
is for dynamic buffers. Sorry for screwing things up for you. :-(
> + for (i = 0; i < f01->irq_count && *local_buf != 0;
> +i++, local_buf += 2) {
> + int irq_shift;
> + int interrupt_enable;
> + int result;
> +
> + irq_reg = i / 8;
> + irq_shift = i % 8;
Please stop doing these arithmetics-turned-maths things.
irq_reg = i >> 8;
irq_shift = i & 0xFF;
(...)
> +static ssize_t rmi_fn_01_interrupt_enable_show(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + struct rmi_function_container *fc;
> + struct f01_data *data;
> + int i, len, total_len = 0;
> + char *current_buf = buf;
> +
> + fc = to_rmi_function_container(dev);
> + data = fc->data;
> + /* loop through each irq value and copy its
> +* string representation into buf */
> + for (i = 0; i < data->irq_count; i++) {
> + int irq_reg;
> + int irq_shift;
> + int interrupt_enable;
> +
> + irq_reg = i / 8;
> + irq_shift = i % 8;
Dito.
(...)
> +static int f01_probe(struct device *dev);
Do you really need to forward-declare this?
(...)
> +static struct rmi_function_handler function_handler = {
> + .driver = {
> + .owner = THIS_MODULE,
> + .name = "rmi_f01",
> + .bus = _bus_type,
> + .probe = f01_probe,
> + .remove = f01_remove_device,
> + },
> + .func = 0x01,
> + .config = rmi_f01_config,
> + .attention = rmi_f01_attention,
> +
> +#ifdef CONFIG_PM
> + .suspend = rmi_f01_suspend,
> + .resume = rmi_f01_resume,
> +#endif /* CONFIG_PM */
> +};
Just move this block of struct *below* the probe function...
> +static __devinit int f01_probe(struct device *dev)
Header file looks OK (if these unions is the way to go...)
Yours,
Linus Walleij
--
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 2/2] i2c: busses: i2c-ocores: switch to devm_request_and_ioremap
> "Maxin" == Maxin B John writes: Maxin> Hi Peter, Maxin> This drops a few lines of code and allows common APIs to handle Maxin> those for us. Maxin> Signed-off-by: Maxin B. John >> Acked-by: Peter Korsgaard Maxin> Is there any update on this ? I'm expecting Wolfram to pick it up. -- Bye, Peter Korsgaard -- 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/
[GIT PULL] Disintegrate UAPI for cris [ver #2]
Can you merge the following branch into the cris tree please.
This is to complete part of the UAPI disintegration for which the preparatory
patches were pulled recently.
Now that the fixups and the asm-generic chunk have been merged, I've
regenerated the patches to get rid of those dependencies and to take account of
any changes made so far in the merge window. If you have already pulled the
older version of the branch aimed at you, then please feel free to ignore this
request.
The following changes since commit 9e2d8656f5e8aa214e66b462680cf86b210b74a8:
Merge branch 'akpm' (Andrew's patch-bomb) (2012-10-09 16:23:15 +0900)
are available in the git repository at:
git://git.infradead.org/users/dhowells/linux-headers.git
tags/disintegrate-cris-20121009
for you to fetch changes up to e717abac8a9f65eee6de3bb37e10c6916bced483:
UAPI: (Scripted) Disintegrate arch/cris/include/asm (2012-10-09 09:46:45
+0100)
UAPI Disintegration 2012-10-09
David Howells (3):
UAPI: (Scripted) Disintegrate arch/cris/include/arch-v10/arch
UAPI: (Scripted) Disintegrate arch/cris/include/arch-v32/arch
UAPI: (Scripted) Disintegrate arch/cris/include/asm
arch/cris/include/arch-v10/arch/Kbuild | 4 -
arch/cris/include/arch-v32/arch/Kbuild | 2 -
arch/cris/include/arch-v32/arch/cryptocop.h| 116 +--
arch/cris/include/asm/Kbuild | 5 -
arch/cris/include/asm/ptrace.h | 5 +-
arch/cris/include/asm/signal.h | 122 +---
arch/cris/include/asm/swab.h | 3 +-
arch/cris/include/asm/termios.h| 43 +--
arch/cris/include/asm/types.h | 5 +-
arch/cris/include/asm/unistd.h | 342 +---
arch/cris/include/uapi/arch-v10/arch/Kbuild| 4 +
.../include/{ => uapi}/arch-v10/arch/sv_addr.agh | 0
.../include/{ => uapi}/arch-v10/arch/sv_addr_ag.h | 0
.../cris/include/{ => uapi}/arch-v10/arch/svinto.h | 0
arch/cris/include/{ => uapi}/arch-v10/arch/user.h | 0
arch/cris/include/uapi/arch-v32/arch/Kbuild| 2 +
arch/cris/include/uapi/arch-v32/arch/cryptocop.h | 122
arch/cris/include/{ => uapi}/arch-v32/arch/user.h | 0
arch/cris/include/uapi/asm/Kbuild | 34 ++
arch/cris/include/{ => uapi}/asm/auxvec.h | 0
arch/cris/include/{ => uapi}/asm/bitsperlong.h | 0
arch/cris/include/{ => uapi}/asm/byteorder.h | 0
arch/cris/include/{ => uapi}/asm/errno.h | 0
arch/cris/include/{ => uapi}/asm/ethernet.h| 0
arch/cris/include/{ => uapi}/asm/etraxgpio.h | 0
arch/cris/include/{ => uapi}/asm/fcntl.h | 0
arch/cris/include/{ => uapi}/asm/ioctl.h | 0
arch/cris/include/{ => uapi}/asm/ioctls.h | 0
arch/cris/include/{ => uapi}/asm/ipcbuf.h | 0
arch/cris/include/{ => uapi}/asm/mman.h| 0
arch/cris/include/{ => uapi}/asm/msgbuf.h | 0
arch/cris/include/{ => uapi}/asm/param.h | 0
arch/cris/include/{ => uapi}/asm/poll.h| 0
arch/cris/include/{ => uapi}/asm/posix_types.h | 0
arch/cris/include/uapi/asm/ptrace.h| 1 +
arch/cris/include/{ => uapi}/asm/resource.h| 0
arch/cris/include/{ => uapi}/asm/rs485.h | 0
arch/cris/include/{ => uapi}/asm/sembuf.h | 0
arch/cris/include/{ => uapi}/asm/setup.h | 0
arch/cris/include/{ => uapi}/asm/shmbuf.h | 0
arch/cris/include/{ => uapi}/asm/sigcontext.h | 0
arch/cris/include/{ => uapi}/asm/siginfo.h | 0
arch/cris/include/uapi/asm/signal.h| 122
arch/cris/include/{ => uapi}/asm/socket.h | 0
arch/cris/include/{ => uapi}/asm/sockios.h | 0
arch/cris/include/{ => uapi}/asm/stat.h| 0
arch/cris/include/{ => uapi}/asm/statfs.h | 0
arch/cris/include/{ => uapi}/asm/sync_serial.h | 0
arch/cris/include/{ => uapi}/asm/termbits.h| 0
arch/cris/include/uapi/asm/termios.h | 45 +++
arch/cris/include/uapi/asm/types.h | 1 +
arch/cris/include/uapi/asm/unistd.h| 344 +
52 files changed, 682 insertions(+), 640 deletions(-)
rename arch/cris/include/{ => uapi}/arch-v10/arch/sv_addr.agh (100%)
rename arch/cris/include/{ => uapi}/arch-v10/arch/sv_addr_ag.h (100%)
rename arch/cris/include/{ => uapi}/arch-v10/arch/svinto.h (100%)
rename arch/cris/include/{ => uapi}/arch-v10/arch/user.h (100%)
create mode 100644 arch/cris/include/uapi/arch-v32/arch/cryptocop.h
rename arch/cris/include/{ => uapi}/arch-v32/ar
[GIT PULL] Disintegrate UAPI for blackfin [ver #2]
Can you merge the following branch into the blackfin tree please.
This is to complete part of the UAPI disintegration for which the preparatory
patches were pulled recently.
Now that the fixups and the asm-generic chunk have been merged, I've
regenerated the patches to get rid of those dependencies and to take account of
any changes made so far in the merge window. If you have already pulled the
older version of the branch aimed at you, then please feel free to ignore this
request.
The following changes since commit 9e2d8656f5e8aa214e66b462680cf86b210b74a8:
Merge branch 'akpm' (Andrew's patch-bomb) (2012-10-09 16:23:15 +0900)
are available in the git repository at:
git://git.infradead.org/users/dhowells/linux-headers.git
tags/disintegrate-blackfin-20121009
for you to fetch changes up to ac3a050e89f2e6b8025e4176a36ed34de470fcad:
UAPI: (Scripted) Disintegrate arch/blackfin/include/asm (2012-10-09 09:46:39
+0100)
UAPI Disintegration 2012-10-09
David Howells (1):
UAPI: (Scripted) Disintegrate arch/blackfin/include/asm
arch/blackfin/include/asm/Kbuild | 5 -
arch/blackfin/include/asm/bfin_sport.h | 128 +-
arch/blackfin/include/asm/fixed_code.h | 30 +-
arch/blackfin/include/asm/ptrace.h | 161 +---
arch/blackfin/include/asm/unistd.h | 430 +---
arch/blackfin/include/uapi/asm/Kbuild | 16 +
arch/blackfin/include/uapi/asm/bfin_sport.h| 136 +++
arch/blackfin/include/{ => uapi}/asm/byteorder.h | 0
arch/blackfin/include/{ => uapi}/asm/cachectl.h| 0
arch/blackfin/include/{ => uapi}/asm/fcntl.h | 0
arch/blackfin/include/uapi/asm/fixed_code.h| 38 ++
arch/blackfin/include/{ => uapi}/asm/ioctls.h | 0
arch/blackfin/include/{ => uapi}/asm/kvm_para.h| 0
arch/blackfin/include/{ => uapi}/asm/poll.h| 0
arch/blackfin/include/{ => uapi}/asm/posix_types.h | 0
arch/blackfin/include/uapi/asm/ptrace.h| 170
arch/blackfin/include/{ => uapi}/asm/sigcontext.h | 0
arch/blackfin/include/{ => uapi}/asm/siginfo.h | 0
arch/blackfin/include/{ => uapi}/asm/signal.h | 0
arch/blackfin/include/{ => uapi}/asm/stat.h| 0
arch/blackfin/include/{ => uapi}/asm/swab.h| 0
arch/blackfin/include/uapi/asm/unistd.h| 437 +
22 files changed, 802 insertions(+), 749 deletions(-)
create mode 100644 arch/blackfin/include/uapi/asm/bfin_sport.h
rename arch/blackfin/include/{ => uapi}/asm/byteorder.h (100%)
rename arch/blackfin/include/{ => uapi}/asm/cachectl.h (100%)
rename arch/blackfin/include/{ => uapi}/asm/fcntl.h (100%)
create mode 100644 arch/blackfin/include/uapi/asm/fixed_code.h
rename arch/blackfin/include/{ => uapi}/asm/ioctls.h (100%)
rename arch/blackfin/include/{ => uapi}/asm/kvm_para.h (100%)
rename arch/blackfin/include/{ => uapi}/asm/poll.h (100%)
rename arch/blackfin/include/{ => uapi}/asm/posix_types.h (100%)
create mode 100644 arch/blackfin/include/uapi/asm/ptrace.h
rename arch/blackfin/include/{ => uapi}/asm/sigcontext.h (100%)
rename arch/blackfin/include/{ => uapi}/asm/siginfo.h (100%)
rename arch/blackfin/include/{ => uapi}/asm/signal.h (100%)
rename arch/blackfin/include/{ => uapi}/asm/stat.h (100%)
rename arch/blackfin/include/{ => uapi}/asm/swab.h (100%)
create mode 100644 arch/blackfin/include/uapi/asm/unistd.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/
[GIT PULL] Disintegrate UAPI for arm [ver #2]
Can you merge the following branch into the arm tree please.
This is to complete part of the UAPI disintegration for which the preparatory
patches were pulled recently.
Now that the fixups and the asm-generic chunk have been merged, I've
regenerated the patches to get rid of those dependencies and to take account of
any changes made so far in the merge window. If you have already pulled the
older version of the branch aimed at you, then please feel free to ignore this
request.
The following changes since commit 9e2d8656f5e8aa214e66b462680cf86b210b74a8:
Merge branch 'akpm' (Andrew's patch-bomb) (2012-10-09 16:23:15 +0900)
are available in the git repository at:
git://git.infradead.org/users/dhowells/linux-headers.git
tags/disintegrate-arm-20121009
for you to fetch changes up to 86418cab1bb1aa591d48ea51d67aeb54f30732d1:
UAPI: (Scripted) Disintegrate arch/arm/include/asm (2012-10-09 09:46:32 +0100)
UAPI Disintegration 2012-10-09
David Howells (1):
UAPI: (Scripted) Disintegrate arch/arm/include/asm
arch/arm/include/asm/Kbuild | 2 -
arch/arm/include/asm/hwcap.h | 27 +-
arch/arm/include/asm/ptrace.h | 126 +---
arch/arm/include/asm/setup.h | 172 +-
arch/arm/include/asm/signal.h | 127 +---
arch/arm/include/asm/swab.h | 37 +--
arch/arm/include/asm/unistd.h | 440 +
arch/arm/include/uapi/asm/Kbuild | 16 +
arch/arm/include/{ => uapi}/asm/a.out.h | 0
arch/arm/include/{ => uapi}/asm/byteorder.h | 0
arch/arm/include/{ => uapi}/asm/fcntl.h | 0
arch/arm/include/uapi/asm/hwcap.h | 29 ++
arch/arm/include/{ => uapi}/asm/ioctls.h | 0
arch/arm/include/{ => uapi}/asm/kvm_para.h| 0
arch/arm/include/{ => uapi}/asm/mman.h| 0
arch/arm/include/{ => uapi}/asm/posix_types.h | 0
arch/arm/include/uapi/asm/ptrace.h| 137
arch/arm/include/uapi/asm/setup.h | 187 +++
arch/arm/include/{ => uapi}/asm/sigcontext.h | 0
arch/arm/include/uapi/asm/signal.h| 127
arch/arm/include/{ => uapi}/asm/stat.h| 0
arch/arm/include/{ => uapi}/asm/statfs.h | 0
arch/arm/include/uapi/asm/swab.h | 53 +++
arch/arm/include/uapi/asm/unistd.h| 450 ++
24 files changed, 1005 insertions(+), 925 deletions(-)
rename arch/arm/include/{ => uapi}/asm/a.out.h (100%)
rename arch/arm/include/{ => uapi}/asm/byteorder.h (100%)
rename arch/arm/include/{ => uapi}/asm/fcntl.h (100%)
create mode 100644 arch/arm/include/uapi/asm/hwcap.h
rename arch/arm/include/{ => uapi}/asm/ioctls.h (100%)
rename arch/arm/include/{ => uapi}/asm/kvm_para.h (100%)
rename arch/arm/include/{ => uapi}/asm/mman.h (100%)
rename arch/arm/include/{ => uapi}/asm/posix_types.h (100%)
create mode 100644 arch/arm/include/uapi/asm/ptrace.h
create mode 100644 arch/arm/include/uapi/asm/setup.h
rename arch/arm/include/{ => uapi}/asm/sigcontext.h (100%)
create mode 100644 arch/arm/include/uapi/asm/signal.h
rename arch/arm/include/{ => uapi}/asm/stat.h (100%)
rename arch/arm/include/{ => uapi}/asm/statfs.h (100%)
create mode 100644 arch/arm/include/uapi/asm/swab.h
create mode 100644 arch/arm/include/uapi/asm/unistd.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/
[GIT PULL] Disintegrate UAPI for hexagon [ver #2]
Can you merge the following branch into the hexagon tree please.
This is to complete part of the UAPI disintegration for which the preparatory
patches were pulled recently.
Now that the fixups and the asm-generic chunk have been merged, I've
regenerated the patches to get rid of those dependencies and to take account of
any changes made so far in the merge window. If you have already pulled the
older version of the branch aimed at you, then please feel free to ignore this
request.
The following changes since commit 9e2d8656f5e8aa214e66b462680cf86b210b74a8:
Merge branch 'akpm' (Andrew's patch-bomb) (2012-10-09 16:23:15 +0900)
are available in the git repository at:
git://git.infradead.org/users/dhowells/linux-headers.git
tags/disintegrate-hexagon-20121009
for you to fetch changes up to 044819a598469f603df5cfc8abfed766c9a9444a:
UAPI: (Scripted) Disintegrate arch/hexagon/include/asm (2012-10-09 09:46:55
+0100)
UAPI Disintegration 2012-10-09
David Howells (1):
UAPI: (Scripted) Disintegrate arch/hexagon/include/asm
arch/hexagon/include/asm/Kbuild | 3 ---
arch/hexagon/include/uapi/asm/Kbuild | 12
arch/hexagon/include/{ => uapi}/asm/bitsperlong.h | 0
arch/hexagon/include/{ => uapi}/asm/byteorder.h | 0
arch/hexagon/include/{ => uapi}/asm/kvm_para.h| 0
arch/hexagon/include/{ => uapi}/asm/param.h | 0
arch/hexagon/include/{ => uapi}/asm/ptrace.h | 0
arch/hexagon/include/{ => uapi}/asm/registers.h | 0
arch/hexagon/include/{ => uapi}/asm/setup.h | 0
arch/hexagon/include/{ => uapi}/asm/sigcontext.h | 0
arch/hexagon/include/{ => uapi}/asm/signal.h | 0
arch/hexagon/include/{ => uapi}/asm/swab.h| 0
arch/hexagon/include/{ => uapi}/asm/unistd.h | 0
arch/hexagon/include/{ => uapi}/asm/user.h| 0
14 files changed, 12 insertions(+), 3 deletions(-)
rename arch/hexagon/include/{ => uapi}/asm/bitsperlong.h (100%)
rename arch/hexagon/include/{ => uapi}/asm/byteorder.h (100%)
rename arch/hexagon/include/{ => uapi}/asm/kvm_para.h (100%)
rename arch/hexagon/include/{ => uapi}/asm/param.h (100%)
rename arch/hexagon/include/{ => uapi}/asm/ptrace.h (100%)
rename arch/hexagon/include/{ => uapi}/asm/registers.h (100%)
rename arch/hexagon/include/{ => uapi}/asm/setup.h (100%)
rename arch/hexagon/include/{ => uapi}/asm/sigcontext.h (100%)
rename arch/hexagon/include/{ => uapi}/asm/signal.h (100%)
rename arch/hexagon/include/{ => uapi}/asm/swab.h (100%)
rename arch/hexagon/include/{ => uapi}/asm/unistd.h (100%)
rename arch/hexagon/include/{ => uapi}/asm/user.h (100%)
.
--
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/
[GIT PULL] Disintegrate UAPI for c6x [ver #2]
Can you merge the following branch into the c6x tree please.
This is to complete part of the UAPI disintegration for which the preparatory
patches were pulled recently.
Now that the fixups and the asm-generic chunk have been merged, I've
regenerated the patches to get rid of those dependencies and to take account of
any changes made so far in the merge window. If you have already pulled the
older version of the branch aimed at you, then please feel free to ignore this
request.
The following changes since commit 9e2d8656f5e8aa214e66b462680cf86b210b74a8:
Merge branch 'akpm' (Andrew's patch-bomb) (2012-10-09 16:23:15 +0900)
are available in the git repository at:
git://git.infradead.org/users/dhowells/linux-headers.git
tags/disintegrate-c6x-20121009
for you to fetch changes up to 41e3f8a642842a137833de40cec447d35d6a8196:
UAPI: (Scripted) Disintegrate arch/c6x/include/asm (2012-10-09 09:46:40 +0100)
UAPI Disintegration 2012-10-09
David Howells (1):
UAPI: (Scripted) Disintegrate arch/c6x/include/asm
arch/c6x/include/asm/Kbuild | 1 -
arch/c6x/include/asm/ptrace.h| 146 +---
arch/c6x/include/uapi/asm/Kbuild | 7 ++
arch/c6x/include/{ => uapi}/asm/byteorder.h | 0
arch/c6x/include/{ => uapi}/asm/kvm_para.h | 0
arch/c6x/include/uapi/asm/ptrace.h | 163 +++
arch/c6x/include/{ => uapi}/asm/setup.h | 0
arch/c6x/include/{ => uapi}/asm/sigcontext.h | 0
arch/c6x/include/{ => uapi}/asm/swab.h | 0
arch/c6x/include/{ => uapi}/asm/unistd.h | 0
10 files changed, 171 insertions(+), 146 deletions(-)
rename arch/c6x/include/{ => uapi}/asm/byteorder.h (100%)
rename arch/c6x/include/{ => uapi}/asm/kvm_para.h (100%)
create mode 100644 arch/c6x/include/uapi/asm/ptrace.h
rename arch/c6x/include/{ => uapi}/asm/setup.h (100%)
rename arch/c6x/include/{ => uapi}/asm/sigcontext.h (100%)
rename arch/c6x/include/{ => uapi}/asm/swab.h (100%)
rename arch/c6x/include/{ => uapi}/asm/unistd.h (100%)
.
--
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/
[GIT PULL] Disintegrate UAPI for avr32 [ver #2]
Can you merge the following branch into the avr32 tree please.
This is to complete part of the UAPI disintegration for which the preparatory
patches were pulled recently.
Now that the fixups and the asm-generic chunk have been merged, I've
regenerated the patches to get rid of those dependencies and to take account of
any changes made so far in the merge window. If you have already pulled the
older version of the branch aimed at you, then please feel free to ignore this
request.
The following changes since commit 9e2d8656f5e8aa214e66b462680cf86b210b74a8:
Merge branch 'akpm' (Andrew's patch-bomb) (2012-10-09 16:23:15 +0900)
are available in the git repository at:
git://git.infradead.org/users/dhowells/linux-headers.git
tags/disintegrate-avr32-20121009
for you to fetch changes up to b9ba6b52cfb7f564c205bc42fed3297d623fc50f:
UAPI: (Scripted) Disintegrate arch/avr32/include/asm (2012-10-09 09:46:37
+0100)
UAPI Disintegration 2012-10-09
David Howells (1):
UAPI: (Scripted) Disintegrate arch/avr32/include/asm
arch/avr32/include/asm/Kbuild | 3 -
arch/avr32/include/asm/param.h | 18 +-
arch/avr32/include/asm/ptrace.h | 115 +
arch/avr32/include/asm/setup.h | 5 +-
arch/avr32/include/asm/signal.h | 121 +-
arch/avr32/include/asm/termios.h| 41 +---
arch/avr32/include/asm/types.h | 6 +-
arch/avr32/include/asm/unistd.h | 296 +--
arch/avr32/include/uapi/asm/Kbuild | 32 +++
arch/avr32/include/{ => uapi}/asm/auxvec.h | 0
arch/avr32/include/{ => uapi}/asm/bitsperlong.h | 0
arch/avr32/include/{ => uapi}/asm/byteorder.h | 0
arch/avr32/include/{ => uapi}/asm/cachectl.h| 0
arch/avr32/include/{ => uapi}/asm/errno.h | 0
arch/avr32/include/{ => uapi}/asm/fcntl.h | 0
arch/avr32/include/{ => uapi}/asm/ioctl.h | 0
arch/avr32/include/{ => uapi}/asm/ioctls.h | 0
arch/avr32/include/{ => uapi}/asm/ipcbuf.h | 0
arch/avr32/include/{ => uapi}/asm/kvm_para.h| 0
arch/avr32/include/{ => uapi}/asm/mman.h| 0
arch/avr32/include/{ => uapi}/asm/msgbuf.h | 0
arch/avr32/include/uapi/asm/param.h | 18 ++
arch/avr32/include/{ => uapi}/asm/poll.h| 0
arch/avr32/include/{ => uapi}/asm/posix_types.h | 0
arch/avr32/include/uapi/asm/ptrace.h| 126 ++
arch/avr32/include/{ => uapi}/asm/resource.h| 0
arch/avr32/include/{ => uapi}/asm/sembuf.h | 0
arch/avr32/include/uapi/asm/setup.h | 17 ++
arch/avr32/include/{ => uapi}/asm/shmbuf.h | 0
arch/avr32/include/{ => uapi}/asm/sigcontext.h | 0
arch/avr32/include/{ => uapi}/asm/siginfo.h | 0
arch/avr32/include/uapi/asm/signal.h| 128 ++
arch/avr32/include/{ => uapi}/asm/socket.h | 0
arch/avr32/include/{ => uapi}/asm/sockios.h | 0
arch/avr32/include/{ => uapi}/asm/stat.h| 0
arch/avr32/include/{ => uapi}/asm/statfs.h | 0
arch/avr32/include/{ => uapi}/asm/swab.h| 0
arch/avr32/include/{ => uapi}/asm/termbits.h| 0
arch/avr32/include/uapi/asm/termios.h | 50
arch/avr32/include/uapi/asm/types.h | 8 +
arch/avr32/include/uapi/asm/unistd.h| 305
41 files changed, 692 insertions(+), 597 deletions(-)
rename arch/avr32/include/{ => uapi}/asm/auxvec.h (100%)
rename arch/avr32/include/{ => uapi}/asm/bitsperlong.h (100%)
rename arch/avr32/include/{ => uapi}/asm/byteorder.h (100%)
rename arch/avr32/include/{ => uapi}/asm/cachectl.h (100%)
rename arch/avr32/include/{ => uapi}/asm/errno.h (100%)
rename arch/avr32/include/{ => uapi}/asm/fcntl.h (100%)
rename arch/avr32/include/{ => uapi}/asm/ioctl.h (100%)
rename arch/avr32/include/{ => uapi}/asm/ioctls.h (100%)
rename arch/avr32/include/{ => uapi}/asm/ipcbuf.h (100%)
rename arch/avr32/include/{ => uapi}/asm/kvm_para.h (100%)
rename arch/avr32/include/{ => uapi}/asm/mman.h (100%)
rename arch/avr32/include/{ => uapi}/asm/msgbuf.h (100%)
create mode 100644 arch/avr32/include/uapi/asm/param.h
rename arch/avr32/include/{ => uapi}/asm/poll.h (100%)
rename arch/avr32/include/{ => uapi}/asm/posix_types.h (100%)
create mode 100644 arch/avr32/include/uapi/asm/ptrace.h
rename arch/avr32/include/{ => uapi}/asm/resource.h (100%)
rename arch/avr32/include/{ => uapi}/asm/sembuf.h (100%)
create mode 100644 arch/avr32/include/uapi/asm/setup.h
rename arch/avr32/include/{ => uapi}/asm/shmbuf.h (100%)
rename arch/avr32/include/{ => uapi}/asm/sigcontext.h (100%)
rename arch/avr32/include/{
[GIT PULL] Disintegrate UAPI for arm64 [ver #2]
Can you merge the following branch into the arm64 tree please.
This is to complete part of the UAPI disintegration for which the preparatory
patches were pulled recently.
Now that the fixups and the asm-generic chunk have been merged, I've
regenerated the patches to get rid of those dependencies and to take account of
any changes made so far in the merge window. If you have already pulled the
older version of the branch aimed at you, then please feel free to ignore this
request.
The following changes since commit 9e2d8656f5e8aa214e66b462680cf86b210b74a8:
Merge branch 'akpm' (Andrew's patch-bomb) (2012-10-09 16:23:15 +0900)
are available in the git repository at:
git://git.infradead.org/users/dhowells/linux-headers.git
tags/disintegrate-arm64-20121009
for you to fetch changes up to a24b2da6de9a44f395c67219d300de21f66d0da3:
UAPI: (Scripted) Disintegrate arch/arm64/include/asm (2012-10-09 09:46:34
+0100)
UAPI Disintegration 2012-10-09
David Howells (1):
UAPI: (Scripted) Disintegrate arch/arm64/include/asm
arch/arm64/include/asm/Kbuild | 2 -
arch/arm64/include/asm/hwcap.h | 22 +
arch/arm64/include/asm/ptrace.h | 88 +--
arch/arm64/include/asm/sigcontext.h | 40 +
arch/arm64/include/asm/stat.h | 5 +-
arch/arm64/include/asm/unistd.h | 8 +-
arch/arm64/include/uapi/asm/Kbuild | 14 +++
arch/arm64/include/{ => uapi}/asm/auxvec.h | 0
arch/arm64/include/{ => uapi}/asm/bitsperlong.h | 0
arch/arm64/include/{ => uapi}/asm/byteorder.h | 0
arch/arm64/include/{ => uapi}/asm/fcntl.h | 0
arch/arm64/include/uapi/asm/hwcap.h | 39 +
arch/arm64/include/{ => uapi}/asm/param.h | 0
arch/arm64/include/uapi/asm/ptrace.h| 110
arch/arm64/include/{ => uapi}/asm/setup.h | 0
arch/arm64/include/uapi/asm/sigcontext.h| 57
arch/arm64/include/{ => uapi}/asm/siginfo.h | 0
arch/arm64/include/{ => uapi}/asm/signal.h | 0
arch/arm64/include/uapi/asm/stat.h | 16
arch/arm64/include/{ => uapi}/asm/statfs.h | 0
arch/arm64/include/uapi/asm/unistd.h| 16
21 files changed, 257 insertions(+), 160 deletions(-)
rename arch/arm64/include/{ => uapi}/asm/auxvec.h (100%)
rename arch/arm64/include/{ => uapi}/asm/bitsperlong.h (100%)
rename arch/arm64/include/{ => uapi}/asm/byteorder.h (100%)
rename arch/arm64/include/{ => uapi}/asm/fcntl.h (100%)
create mode 100644 arch/arm64/include/uapi/asm/hwcap.h
rename arch/arm64/include/{ => uapi}/asm/param.h (100%)
create mode 100644 arch/arm64/include/uapi/asm/ptrace.h
rename arch/arm64/include/{ => uapi}/asm/setup.h (100%)
create mode 100644 arch/arm64/include/uapi/asm/sigcontext.h
rename arch/arm64/include/{ => uapi}/asm/siginfo.h (100%)
rename arch/arm64/include/{ => uapi}/asm/signal.h (100%)
create mode 100644 arch/arm64/include/uapi/asm/stat.h
rename arch/arm64/include/{ => uapi}/asm/statfs.h (100%)
create mode 100644 arch/arm64/include/uapi/asm/unistd.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/
[GIT PULL] Disintegrate UAPI for mips [ver #2]
Can you merge the following branch into the mips tree please.
This is to complete part of the UAPI disintegration for which the preparatory
patches were pulled recently.
Now that the fixups and the asm-generic chunk have been merged, I've
regenerated the patches to get rid of those dependencies and to take account of
any changes made so far in the merge window. If you have already pulled the
older version of the branch aimed at you, then please feel free to ignore this
request.
The following changes since commit 9e2d8656f5e8aa214e66b462680cf86b210b74a8:
Merge branch 'akpm' (Andrew's patch-bomb) (2012-10-09 16:23:15 +0900)
are available in the git repository at:
git://git.infradead.org/users/dhowells/linux-headers.git
tags/disintegrate-mips-20121009
for you to fetch changes up to 61730c538f8281efa7ac12596da9f3f9a31b9272:
UAPI: (Scripted) Disintegrate arch/mips/include/asm (2012-10-09 09:47:14
+0100)
UAPI Disintegration 2012-10-09
David Howells (1):
UAPI: (Scripted) Disintegrate arch/mips/include/asm
arch/mips/include/asm/Kbuild |5 -
arch/mips/include/asm/errno.h | 120 +--
arch/mips/include/asm/ptrace.h | 107 +--
arch/mips/include/asm/setup.h |5 +-
arch/mips/include/asm/sigcontext.h | 66 +-
arch/mips/include/asm/siginfo.h| 104 +--
arch/mips/include/asm/signal.h | 115 +--
arch/mips/include/asm/socket.h | 83 +-
arch/mips/include/asm/termios.h| 73 +-
arch/mips/include/asm/types.h | 16 +-
arch/mips/include/asm/unistd.h | 1022 +--
arch/mips/include/uapi/asm/Kbuild | 34 +
arch/mips/include/{ => uapi}/asm/auxvec.h |0
arch/mips/include/{ => uapi}/asm/bitsperlong.h |0
arch/mips/include/{ => uapi}/asm/byteorder.h |0
arch/mips/include/{ => uapi}/asm/cachectl.h|0
arch/mips/include/uapi/asm/errno.h | 129 +++
arch/mips/include/{ => uapi}/asm/fcntl.h |0
arch/mips/include/{ => uapi}/asm/ioctl.h |0
arch/mips/include/{ => uapi}/asm/ioctls.h |0
arch/mips/include/{ => uapi}/asm/ipcbuf.h |0
arch/mips/include/{ => uapi}/asm/kvm_para.h|0
arch/mips/include/{ => uapi}/asm/mman.h|0
arch/mips/include/{ => uapi}/asm/msgbuf.h |0
arch/mips/include/{ => uapi}/asm/param.h |0
arch/mips/include/{ => uapi}/asm/poll.h|0
arch/mips/include/{ => uapi}/asm/posix_types.h |0
arch/mips/include/uapi/asm/ptrace.h| 116 +++
arch/mips/include/{ => uapi}/asm/resource.h|0
arch/mips/include/{ => uapi}/asm/sembuf.h |0
arch/mips/include/uapi/asm/setup.h |7 +
arch/mips/include/{ => uapi}/asm/sgidefs.h |0
arch/mips/include/{ => uapi}/asm/shmbuf.h |0
arch/mips/include/uapi/asm/sigcontext.h| 78 ++
arch/mips/include/uapi/asm/siginfo.h | 114 +++
arch/mips/include/uapi/asm/signal.h| 123 +++
arch/mips/include/uapi/asm/socket.h| 93 +++
arch/mips/include/{ => uapi}/asm/sockios.h |0
arch/mips/include/{ => uapi}/asm/stat.h|0
arch/mips/include/{ => uapi}/asm/statfs.h |0
arch/mips/include/{ => uapi}/asm/swab.h|0
arch/mips/include/{ => uapi}/asm/sysmips.h |0
arch/mips/include/{ => uapi}/asm/termbits.h|0
arch/mips/include/uapi/asm/termios.h | 80 ++
arch/mips/include/uapi/asm/types.h | 27 +
arch/mips/include/uapi/asm/unistd.h| 1035
46 files changed, 1846 insertions(+), 1706 deletions(-)
rename arch/mips/include/{ => uapi}/asm/auxvec.h (100%)
rename arch/mips/include/{ => uapi}/asm/bitsperlong.h (100%)
rename arch/mips/include/{ => uapi}/asm/byteorder.h (100%)
rename arch/mips/include/{ => uapi}/asm/cachectl.h (100%)
create mode 100644 arch/mips/include/uapi/asm/errno.h
rename arch/mips/include/{ => uapi}/asm/fcntl.h (100%)
rename arch/mips/include/{ => uapi}/asm/ioctl.h (100%)
rename arch/mips/include/{ => uapi}/asm/ioctls.h (100%)
rename arch/mips/include/{ => uapi}/asm/ipcbuf.h (100%)
rename arch/mips/include/{ => uapi}/asm/kvm_para.h (100%)
rename arch/mips/include/{ => uapi}/asm/mman.h (100%)
rename arch/mips/include/{ => uapi}/asm/msgbuf.h (100%)
rename arch/mips/include/{ => uapi}/asm/param.h (100%)
rename arch/mips/include/{ => uapi}/asm/poll.h (100%)
rename arch/mips/include/{ => uapi}/asm/posix_types.h (100%)
create mode 100644 arch/mips/include/uapi/asm/ptrace.h
rename arch/mips/include/{ => uapi}/asm/resource.h (100%)
rename arch/mips/include/{ =&
[GIT PULL] Disintegrate UAPI for sparc [ver #2]
Can you merge the following branch into the sparc tree please.
This is to complete part of the UAPI disintegration for which the preparatory
patches were pulled recently.
Now that the fixups and the asm-generic chunk have been merged, I've
regenerated the patches to get rid of those dependencies and to take account of
any changes made so far in the merge window. If you have already pulled the
older version of the branch aimed at you, then please feel free to ignore this
request.
The following changes since commit 9e2d8656f5e8aa214e66b462680cf86b210b74a8:
Merge branch 'akpm' (Andrew's patch-bomb) (2012-10-09 16:23:15 +0900)
are available in the git repository at:
git://git.infradead.org/users/dhowells/linux-headers.git
tags/disintegrate-sparc-20121009
for you to fetch changes up to 5457982641fb3f5fb08ce22a853dd5474645c66d:
UAPI: (Scripted) Disintegrate arch/sparc/include/asm (2012-10-09 09:47:43
+0100)
UAPI Disintegration 2012-10-09
David Howells (1):
UAPI: (Scripted) Disintegrate arch/sparc/include/asm
arch/sparc/include/asm/Kbuild | 16 -
arch/sparc/include/asm/fbio.h | 260 +--
arch/sparc/include/asm/ioctls.h | 129 +---
arch/sparc/include/asm/mman.h | 25 +-
arch/sparc/include/asm/psr.h| 36 +-
arch/sparc/include/asm/ptrace.h | 347 +--
arch/sparc/include/asm/setup.h | 10 +-
arch/sparc/include/asm/sigcontext.h | 4 +-
arch/sparc/include/asm/siginfo.h| 23 +-
arch/sparc/include/asm/signal.h | 185 +--
arch/sparc/include/asm/termbits.h | 260 +--
arch/sparc/include/asm/termios.h| 41 +--
arch/sparc/include/asm/traps.h | 111 +--
arch/sparc/include/asm/unistd.h | 412 +--
arch/sparc/include/uapi/asm/Kbuild | 46 +++
arch/sparc/include/{ => uapi}/asm/apc.h | 0
arch/sparc/include/{ => uapi}/asm/asi.h | 0
arch/sparc/include/{ => uapi}/asm/auxvec.h | 0
arch/sparc/include/{ => uapi}/asm/bitsperlong.h | 0
arch/sparc/include/{ => uapi}/asm/byteorder.h | 0
arch/sparc/include/{ => uapi}/asm/display7seg.h | 0
arch/sparc/include/{ => uapi}/asm/envctrl.h | 0
arch/sparc/include/{ => uapi}/asm/errno.h | 0
arch/sparc/include/uapi/asm/fbio.h | 259 +++
arch/sparc/include/{ => uapi}/asm/fcntl.h | 0
arch/sparc/include/{ => uapi}/asm/ioctl.h | 0
arch/sparc/include/uapi/asm/ioctls.h| 131
arch/sparc/include/{ => uapi}/asm/ipcbuf.h | 0
arch/sparc/include/{ => uapi}/asm/jsflash.h | 0
arch/sparc/include/{ => uapi}/asm/kvm_para.h| 0
arch/sparc/include/uapi/asm/mman.h | 27 ++
arch/sparc/include/{ => uapi}/asm/msgbuf.h | 0
arch/sparc/include/{ => uapi}/asm/openpromio.h | 0
arch/sparc/include/{ => uapi}/asm/param.h | 0
arch/sparc/include/{ => uapi}/asm/perfctr.h | 0
arch/sparc/include/{ => uapi}/asm/poll.h| 0
arch/sparc/include/{ => uapi}/asm/posix_types.h | 0
arch/sparc/include/uapi/asm/psr.h | 47 +++
arch/sparc/include/{ => uapi}/asm/psrcompat.h | 0
arch/sparc/include/{ => uapi}/asm/pstate.h | 0
arch/sparc/include/uapi/asm/ptrace.h| 352
arch/sparc/include/{ => uapi}/asm/resource.h| 0
arch/sparc/include/{ => uapi}/asm/sembuf.h | 0
arch/sparc/include/uapi/asm/setup.h | 15 +
arch/sparc/include/{ => uapi}/asm/shmbuf.h | 0
arch/sparc/include/uapi/asm/siginfo.h | 25 ++
arch/sparc/include/uapi/asm/signal.h| 185 +++
arch/sparc/include/{ => uapi}/asm/socket.h | 0
arch/sparc/include/{ => uapi}/asm/sockios.h | 0
arch/sparc/include/{ => uapi}/asm/stat.h| 0
arch/sparc/include/{ => uapi}/asm/statfs.h | 0
arch/sparc/include/{ => uapi}/asm/swab.h| 0
arch/sparc/include/uapi/asm/termbits.h | 263 +++
arch/sparc/include/uapi/asm/termios.h | 43 +++
arch/sparc/include/uapi/asm/traps.h | 120 +++
arch/sparc/include/{ => uapi}/asm/types.h | 0
arch/sparc/include/{ => uapi}/asm/uctx.h| 0
arch/sparc/include/uapi/asm/unistd.h| 422
arch/sparc/include/{ => uapi}/asm/utrap.h | 0
arch/sparc/include/{ => uapi}/asm/watchdog.h| 0
60 files changed, 1951 insertions(+), 1843 deletions(-)
rename arch/sparc/include/{ => uapi}/asm/apc.h (100%)
rename arch/sparc/include/{ => uapi}/asm/asi.h (
[m68k,powerpc,dma,ethernet,freescale RFA] Coldfire m54xx FEC ethernet driver
[CCing lkml, linux-ppc, netdev, linux-m68k] Hello kernel sources architects I have a working driver for the m54xx FEC ethernet driver that I would like to integrate in the kernel tree. Problems are that - this driver needs an associated DMA driver (provided by FreeScale) wich is not dma-engine enabled - they're are already many fec drivers in the kernel tree, and at least one, fec_mpc52xx.c, seems to be very similar (information below), to the one for the mcf54xx, except it uses a differently named associated DMA driver (BestComm/SmartDma/SDMA) which is also not dma-engine enabled, and even kept hidden in /arch/powerpc where it is inaccessible when compiling for m68k. The underlying DMA part from Freescale however seems similar to the one used in the m54xx. (again, see information below) So, now I am lost, what should I do ? The current state of my patches [http://mailman.uclinux.org/pipermail/uclinux-dev/2012-September/052147.html] is pushing the freescale provided MCD_DMA dma driver to /drivers/dma, without adding the dma-engine compatibility layer, and adding the specific fec_m54xx ethernet driver to /drivers/net/ethernet/freescale Best regards Philippe On Tue, Oct 09, 2012 at 04:12:44PM +1000, Greg Ungerer wrote: > Hi Philippe, > > On 05/10/12 01:03, Philippe De Muyter wrote: >> On Thu, Oct 04, 2012 at 04:56:01PM +0200, Philippe De Muyter wrote: >>> On Thu, Oct 04, 2012 at 11:33:32PM +1000, Greg Ungerer wrote: My biggest concern is the amount of MCD/DMA support code. And it is all done quite differently to everything else in the kernel. We may get a bit of push back from kernel folk who look after DMA. >>> >>> Actually, there is already a similar code in arch/powerpc/sysdev/bestcomm >>> (also from freescale, maybe an identical part, but I did not find any >>> usable doc), but the powerpc folks kept that hidden in the arch/powerpc >>> tree, instead of installing it in drivers/dma. >> >> The MCD DMA or DMA FEC code from freescale has a comment implying that >> this >> was first used in the MPC8220 part. And Montavista has a MPC8220 port, >> but >> I did not find it, so I do not know where they installed the MCD DMA >> driver. > > Ok, looks like there is a bit a variance in all this. I also began to read the mpc5200 user's guide parts about the fec and BestComm/SmartDma/SDMA (not sure which one is the official FreeScale name) and they look very similar, but not identical, to their m54xx counterparts. It seems possible to make the fec_mpc52xx.c driver work for the m54xx but that needs at least: - moving some files or part of them from /arch/powerpc/sysdev and /arch/powerpc/include/asm to /drivers/dma and /include/linux, - renaming the fec_mpc52xx files to a more sensible name, - providing out_be32 and in_be32 in /arch/m68k/include/asm/io.h, - and then unifying the interface to BestComm/SmartDma/SDMA and MCD_DMA in mcf_52xx.c. An additional problem is that the freescale docs for powerpcs and for coldfires do not use the same mnemonics for the same registers. e.g. FEC registers offset MPC5200 MCF5484 == === === 000 FEC_ID n/a 004 IEVENT EIR 008 IMASK EIMR 010 R_DES_ACTIVEn/a 014 X_DES_ACTIVEn/a 024 ECNTRL ECR 040 MII_DATAMDATA 044 MII_SPEED MSCR 064 MIB_CONTROL MIBC 084 R_CNTRL RCR 088 R_HASH RHR 0C4 X_CNTRL TCR 0E4 PADDR1 PALR 0E8 PADDR2 PAHR 0EC OP_PAUSEOPD 118 IADDR1 IAUR 11C IADDR1 IALR 120 GADDR1 GAUR 124 GADDR2 GALR 144 X_WMRK FECTFWR 184 RFIFO_DATA FECRFDR 188 RFIFO_STATUSFECRFSR 18C RFIFO_CONTROL FECRFCR 190 RFIFO_LRF_PTR FECRLRFP 194 RFIFO_LWF_PTR FECRLWFP 198 RFIFO_ALARM FECRFAR 19C RFIFO_RDPTR FECRFRP 1A0 RFIFO_WRPTR FECRFWP 1A4 TFIFO_DATA FECTFDR 1A8 TFIFO_STATUSFECTFSR 1AC TFIFO_CONTROL FECTFCR 1B0 TFIFO_LRF_PTR FECTLRFP 1B4 TFIFO_LWF_PTR FECTLWFP 1B8 TFIFO_ALARM FECTFAR 1BC TFIFO_RDPTR FECTFRP 1C0 TFIFO_WRPTR FECTFWP 1C4 RESET_CNTRL FECFRST 1C8 XMIT_FSMFECCTCWR > Probably the best thing to do is post the patches on the linux kernel > mailing list then, asking for direction on a dma driver. > > I have no problem with it going into the arch/m68k area. So that is > always an option. For the dma engines, the similarity is also obvious. For example, find below side by side mpc52xx and m54xx definitions for the main DMA registers : from
[GIT PULL] Disintegrate UAPI for sh [ver #2]
Can you merge the following branch into the sh tree please.
This is to complete part of the UAPI disintegration for which the preparatory
patches were pulled recently.
Now that the fixups and the asm-generic chunk have been merged, I've
regenerated the patches to get rid of those dependencies and to take account of
any changes made so far in the merge window. If you have already pulled the
older version of the branch aimed at you, then please feel free to ignore this
request.
The following changes since commit 9e2d8656f5e8aa214e66b462680cf86b210b74a8:
Merge branch 'akpm' (Andrew's patch-bomb) (2012-10-09 16:23:15 +0900)
are available in the git repository at:
git://git.infradead.org/users/dhowells/linux-headers.git
tags/disintegrate-sh-20121009
for you to fetch changes up to 0a9426df1858f71ac84eb7eef500b4247de5e3bb:
UAPI: (Scripted) Disintegrate arch/sh/include/asm (2012-10-09 09:47:37 +0100)
UAPI Disintegration 2012-10-09
David Howells (1):
UAPI: (Scripted) Disintegrate arch/sh/include/asm
arch/sh/include/asm/Kbuild | 11
arch/sh/include/asm/hw_breakpoint.h | 4 +-
arch/sh/include/asm/posix_types.h | 8 ---
arch/sh/include/asm/ptrace.h| 34 +--
arch/sh/include/asm/ptrace_32.h | 75 +---
arch/sh/include/asm/ptrace_64.h | 12 +---
arch/sh/include/asm/setup.h | 5 +-
arch/sh/include/asm/types.h | 5 +-
arch/sh/include/asm/unistd.h| 9 +--
arch/sh/include/uapi/asm/Kbuild | 22 +++
arch/sh/include/{ => uapi}/asm/auxvec.h | 0
arch/sh/include/{ => uapi}/asm/byteorder.h | 0
arch/sh/include/{ => uapi}/asm/cachectl.h | 0
arch/sh/include/{ => uapi}/asm/cpu-features.h | 0
arch/sh/include/{ => uapi}/asm/ioctls.h | 0
arch/sh/include/uapi/asm/posix_types.h | 7 +++
arch/sh/include/{ => uapi}/asm/posix_types_32.h | 0
arch/sh/include/{ => uapi}/asm/posix_types_64.h | 0
arch/sh/include/uapi/asm/ptrace.h | 34 +++
arch/sh/include/uapi/asm/ptrace_32.h| 77 +
arch/sh/include/uapi/asm/ptrace_64.h| 14 +
arch/sh/include/uapi/asm/setup.h| 1 +
arch/sh/include/{ => uapi}/asm/sigcontext.h | 0
arch/sh/include/{ => uapi}/asm/signal.h | 0
arch/sh/include/{ => uapi}/asm/sockios.h| 0
arch/sh/include/{ => uapi}/asm/stat.h | 0
arch/sh/include/{ => uapi}/asm/swab.h | 0
arch/sh/include/uapi/asm/types.h| 1 +
arch/sh/include/uapi/asm/unistd.h | 7 +++
arch/sh/include/{ => uapi}/asm/unistd_32.h | 0
arch/sh/include/{ => uapi}/asm/unistd_64.h | 0
31 files changed, 173 insertions(+), 153 deletions(-)
rename arch/sh/include/{ => uapi}/asm/auxvec.h (100%)
rename arch/sh/include/{ => uapi}/asm/byteorder.h (100%)
rename arch/sh/include/{ => uapi}/asm/cachectl.h (100%)
rename arch/sh/include/{ => uapi}/asm/cpu-features.h (100%)
create mode 100644 arch/sh/include/uapi/asm/hw_breakpoint.h
rename arch/sh/include/{ => uapi}/asm/ioctls.h (100%)
create mode 100644 arch/sh/include/uapi/asm/posix_types.h
rename arch/sh/include/{ => uapi}/asm/posix_types_32.h (100%)
rename arch/sh/include/{ => uapi}/asm/posix_types_64.h (100%)
create mode 100644 arch/sh/include/uapi/asm/ptrace.h
create mode 100644 arch/sh/include/uapi/asm/ptrace_32.h
create mode 100644 arch/sh/include/uapi/asm/ptrace_64.h
create mode 100644 arch/sh/include/uapi/asm/setup.h
rename arch/sh/include/{ => uapi}/asm/sigcontext.h (100%)
rename arch/sh/include/{ => uapi}/asm/signal.h (100%)
rename arch/sh/include/{ => uapi}/asm/sockios.h (100%)
rename arch/sh/include/{ => uapi}/asm/stat.h (100%)
rename arch/sh/include/{ => uapi}/asm/swab.h (100%)
create mode 100644 arch/sh/include/uapi/asm/types.h
create mode 100644 arch/sh/include/uapi/asm/unistd.h
rename arch/sh/include/{ => uapi}/asm/unistd_32.h (100%)
rename arch/sh/include/{ => uapi}/asm/unistd_64.h (100%)
.
--
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/
2nd CfP World Congress The Frontiers in Intelligent Data and Signal Analysis DSA 2013
* World Congress 2nd Call for Papers The Frontiers in Intelligent Data and Signal Analysis DSA 2013 New York, USA July, 13th - July, 25th 2013 www.worldcongressdsa.com ** Dear Colleagues, Ladies and Gentlemens, We like to invite you to contribute to the World Congress "The Frontiers in Intelligent Data and Signal Analysis DSA 2013" in New York, USA on July, 13th - July 25th, 2013. We are looking forward to your contributions. Sincerely yours, Prof. Dr. Petra Perner Congress Chair *** The Congress will feature three International Conferences: * International Conference on Machine Learning and Data Mining, MLDM 2013 July 19th - July 25th, 2013 http://www.mldm.de * Industrial Conference on Data Mining, ICDM 2013 July 16th - July 21st, 2013 http://www.data-mining-forum.de * International Conference on Mass Data Analysis of Images and Signals in Medicine, Biotechnology, Chemistry, and Food Industry, MDA 2013 July 13th - July 16th, 2013 http://www.mda-signals.de. *** Paper submission deadline will be Dezember, 18th 2012. *** *** Besides that five workshops will be held: * Intern. Workshop Case-Based Reasoning, CBR-MD 2013 http://www.data-mining-forum.de/w_casebased.php * Intern. Workshop Data Mining in Agriculture, DMA 2013 http://www.data-mining-forum.de/w_agriculture.php * Intern. Workshop on Data Mining in the Life Sciences, DMLS 2013 http://www.data-mining-forum.de/w_life_sciences.php * Intern. Workshop on Data Mining in Marketing, DMM 2013 http://www.data-mining-forum.de/w_marketing.php * Intern. Workshop on Intelligent Pattern Recognition and Applications, WIPRA2013 http://www.mldm.de/w_pattern_recognition.php *** Five Tutorials will be given: * Data Mining http://www.data-mining-tutorial.de/ * Case-Based Reasoning http://www.data-mining-forum.de/t_cbr.php * Intelligent Signal and Image Analysis http://www.mda-signals.de * Standardization in Immunofluorescence http://www.imageinterpret.de/ * Big Data & Text Analytics http://www.data-mining-forum.de/t_bdta.php *** Special Sessions * Industry Session http://www.data-mining-forum.de/industry_session.php * Special Session on Discrete Event Formalisms Applied on Medical Data Analysis http://www.mda-signals.de/specialsession.php *** Publications Papers are published by Springer Verlag http://www.springer.de and by ibai-publishing house http://www.ibai-publishing.org. *** Industrial Exhibition, Book and Job Fair We like to invite you to present your company or publishing house at the Industrial Exhibition ieda 2013. http://www.iedaexhibition.de *** Social Events Party in New York *** Sponsors ibai solutions http://www.ibai-solutions.de ImageInterpret GmbH http://www.imageinterpret.de *** New York Di, 9.Okt.2012 If you do not wish to receive this newsletter please press unsubscribe here http://ibai-institut-newsletter.de/cgi-bin/mail/manager.cgi?action=delete=linux-kernel%40vger.kernel.org=mldm2. You will be automatically deleted from the data base. -- 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/
[GIT PULL] Disintegrate UAPI for tile [ver #2]
Can you merge the following branch into the tile tree please.
This is to complete part of the UAPI disintegration for which the preparatory
patches were pulled recently.
Now that the fixups and the asm-generic chunk have been merged, I've
regenerated the patches to get rid of those dependencies and to take account of
any changes made so far in the merge window. If you have already pulled the
older version of the branch aimed at you, then please feel free to ignore this
request.
The following changes since commit 9e2d8656f5e8aa214e66b462680cf86b210b74a8:
Merge branch 'akpm' (Andrew's patch-bomb) (2012-10-09 16:23:15 +0900)
are available in the git repository at:
git://git.infradead.org/users/dhowells/linux-headers.git
tags/disintegrate-tile-20121009
for you to fetch changes up to df842f79f0e2aed9092a73f611f41f03630a3823:
UAPI: (Scripted) Disintegrate arch/tile/include/asm (2012-10-09 09:47:47
+0100)
UAPI Disintegration 2012-10-09
David Howells (2):
UAPI: (Scripted) Disintegrate arch/tile/include/arch
UAPI: (Scripted) Disintegrate arch/tile/include/asm
arch/tile/include/arch/Kbuild | 17 -
arch/tile/include/arch/spr_def.h | 12 +--
arch/tile/include/asm/Kbuild | 3 -
arch/tile/include/asm/hardwall.h | 33 +---
arch/tile/include/asm/ptrace.h | 72 +-
arch/tile/include/asm/setup.h | 7 +-
arch/tile/include/asm/signal.h | 12 +--
arch/tile/include/asm/unistd.h | 25 +-
arch/tile/include/uapi/arch/Kbuild | 17 +
arch/tile/include/{ => uapi}/arch/abi.h| 0
arch/tile/include/{ => uapi}/arch/chip.h | 0
arch/tile/include/{ => uapi}/arch/chip_tile64.h| 0
arch/tile/include/{ => uapi}/arch/chip_tilegx.h| 0
arch/tile/include/{ => uapi}/arch/chip_tilepro.h | 0
arch/tile/include/{ => uapi}/arch/icache.h | 0
arch/tile/include/{ => uapi}/arch/interrupts.h | 0
arch/tile/include/{ => uapi}/arch/interrupts_32.h | 0
arch/tile/include/{ => uapi}/arch/interrupts_64.h | 0
arch/tile/include/{ => uapi}/arch/opcode.h | 0
arch/tile/include/{ => uapi}/arch/opcode_tilegx.h | 0
arch/tile/include/{ => uapi}/arch/opcode_tilepro.h | 0
arch/tile/include/{ => uapi}/arch/sim.h| 0
arch/tile/include/{ => uapi}/arch/sim_def.h| 0
arch/tile/include/uapi/arch/spr_def.h | 26 +++
arch/tile/include/{ => uapi}/arch/spr_def_32.h | 6 +-
arch/tile/include/{ => uapi}/arch/spr_def_64.h | 6 +-
arch/tile/include/uapi/asm/Kbuild | 15
arch/tile/include/{ => uapi}/asm/auxvec.h | 0
arch/tile/include/{ => uapi}/asm/bitsperlong.h | 0
arch/tile/include/{ => uapi}/asm/byteorder.h | 0
arch/tile/include/{ => uapi}/asm/cachectl.h| 0
arch/tile/include/uapi/asm/hardwall.h | 51 +
arch/tile/include/{ => uapi}/asm/kvm_para.h| 0
arch/tile/include/{ => uapi}/asm/mman.h| 0
arch/tile/include/uapi/asm/ptrace.h| 88 ++
arch/tile/include/uapi/asm/setup.h | 21 ++
arch/tile/include/{ => uapi}/asm/sigcontext.h | 0
arch/tile/include/{ => uapi}/asm/siginfo.h | 0
arch/tile/include/uapi/asm/signal.h| 27 +++
arch/tile/include/{ => uapi}/asm/stat.h| 0
arch/tile/include/{ => uapi}/asm/swab.h| 0
arch/tile/include/uapi/asm/unistd.h| 34 +
42 files changed, 295 insertions(+), 177 deletions(-)
rename arch/tile/include/{ => uapi}/arch/abi.h (100%)
rename arch/tile/include/{ => uapi}/arch/chip.h (100%)
rename arch/tile/include/{ => uapi}/arch/chip_tile64.h (100%)
rename arch/tile/include/{ => uapi}/arch/chip_tilegx.h (100%)
rename arch/tile/include/{ => uapi}/arch/chip_tilepro.h (100%)
rename arch/tile/include/{ => uapi}/arch/icache.h (100%)
rename arch/tile/include/{ => uapi}/arch/interrupts.h (100%)
rename arch/tile/include/{ => uapi}/arch/interrupts_32.h (100%)
rename arch/tile/include/{ => uapi}/arch/interrupts_64.h (100%)
rename arch/tile/include/{ => uapi}/arch/opcode.h (100%)
rename arch/tile/include/{ => uapi}/arch/opcode_tilegx.h (100%)
rename arch/tile/include/{ => uapi}/arch/opcode_tilepro.h (100%)
rename arch/tile/include/{ => uapi}/arch/sim.h (100%)
rename arch/tile/include/{ => uapi}/arch/sim_def.h (100%)
create mode 100644 arch/tile/include/uapi/arch/spr_def.h
rename arch/tile/include/{ => uapi}/arch/spr_def_32.h (98%)
rename arch/tile/include/{ => uapi}/arch/spr_def_64.h (98%)
rename arch/tile/
[GIT PULL] Disintegrate UAPI for powerpc [ver #2]
Can you merge the following branch into the powerpc tree please.
This is to complete part of the UAPI disintegration for which the preparatory
patches were pulled recently.
Now that the fixups and the asm-generic chunk have been merged, I've
regenerated the patches to get rid of those dependencies and to take account of
any changes made so far in the merge window. If you have already pulled the
older version of the branch aimed at you, then please feel free to ignore this
request.
The following changes since commit 9e2d8656f5e8aa214e66b462680cf86b210b74a8:
Merge branch 'akpm' (Andrew's patch-bomb) (2012-10-09 16:23:15 +0900)
are available in the git repository at:
git://git.infradead.org/users/dhowells/linux-headers.git
tags/disintegrate-powerpc-20121009
for you to fetch changes up to c3617f72036c909e1f6086b5b9e364e0ef90a6da:
UAPI: (Scripted) Disintegrate arch/powerpc/include/asm (2012-10-09 09:47:26
+0100)
UAPI Disintegration 2012-10-09
David Howells (1):
UAPI: (Scripted) Disintegrate arch/powerpc/include/asm
arch/powerpc/include/asm/Kbuild | 35 --
arch/powerpc/include/asm/bootx.h | 123 +--
arch/powerpc/include/asm/cputable.h | 35 +-
arch/powerpc/include/asm/elf.h| 311 +-
arch/powerpc/include/asm/kvm_para.h | 70 +---
arch/powerpc/include/asm/mman.h | 27 +-
arch/powerpc/include/asm/nvram.h | 55 +---
arch/powerpc/include/asm/ptrace.h | 242 +-
arch/powerpc/include/asm/signal.h | 143 +---
arch/powerpc/include/asm/spu_info.h | 29 +-
arch/powerpc/include/asm/swab.h | 15 +-
arch/powerpc/include/asm/termios.h| 69 +---
arch/powerpc/include/asm/types.h | 30 +-
arch/powerpc/include/asm/unistd.h | 374 +
arch/powerpc/include/uapi/asm/Kbuild | 41 +++
arch/powerpc/include/{ => uapi}/asm/auxvec.h | 0
arch/powerpc/include/{ => uapi}/asm/bitsperlong.h | 0
arch/powerpc/include/uapi/asm/bootx.h | 132
arch/powerpc/include/{ => uapi}/asm/byteorder.h | 0
arch/powerpc/include/uapi/asm/cputable.h | 36 ++
arch/powerpc/include/uapi/asm/elf.h | 307 +
arch/powerpc/include/{ => uapi}/asm/errno.h | 0
arch/powerpc/include/{ => uapi}/asm/fcntl.h | 0
arch/powerpc/include/{ => uapi}/asm/ioctl.h | 0
arch/powerpc/include/{ => uapi}/asm/ioctls.h | 0
arch/powerpc/include/{ => uapi}/asm/ipcbuf.h | 0
arch/powerpc/include/{ => uapi}/asm/kvm.h | 0
arch/powerpc/include/uapi/asm/kvm_para.h | 90 +
arch/powerpc/include/{ => uapi}/asm/linkage.h | 0
arch/powerpc/include/uapi/asm/mman.h | 31 ++
arch/powerpc/include/{ => uapi}/asm/msgbuf.h | 0
arch/powerpc/include/uapi/asm/nvram.h | 62
arch/powerpc/include/{ => uapi}/asm/param.h | 0
arch/powerpc/include/{ => uapi}/asm/poll.h| 0
arch/powerpc/include/{ => uapi}/asm/posix_types.h | 0
arch/powerpc/include/{ => uapi}/asm/ps3fb.h | 0
arch/powerpc/include/uapi/asm/ptrace.h| 259 +++
arch/powerpc/include/{ => uapi}/asm/resource.h| 0
arch/powerpc/include/{ => uapi}/asm/seccomp.h | 0
arch/powerpc/include/{ => uapi}/asm/sembuf.h | 0
arch/powerpc/include/{ => uapi}/asm/setup.h | 0
arch/powerpc/include/{ => uapi}/asm/shmbuf.h | 0
arch/powerpc/include/{ => uapi}/asm/sigcontext.h | 0
arch/powerpc/include/{ => uapi}/asm/siginfo.h | 0
arch/powerpc/include/uapi/asm/signal.h| 145 +
arch/powerpc/include/{ => uapi}/asm/socket.h | 0
arch/powerpc/include/{ => uapi}/asm/sockios.h | 0
arch/powerpc/include/uapi/asm/spu_info.h | 53 +++
arch/powerpc/include/{ => uapi}/asm/stat.h| 0
arch/powerpc/include/{ => uapi}/asm/statfs.h | 0
arch/powerpc/include/uapi/asm/swab.h | 23 ++
arch/powerpc/include/{ => uapi}/asm/termbits.h| 0
arch/powerpc/include/uapi/asm/termios.h | 76 +
arch/powerpc/include/uapi/asm/types.h | 40 +++
arch/powerpc/include/{ => uapi}/asm/ucontext.h| 0
arch/powerpc/include/uapi/asm/unistd.h| 380 ++
56 files changed, 1705 insertions(+), 1528 deletions(-)
rename arch/powerpc/include/{ => uapi}/asm/auxvec.h (100%)
rename arch/powerpc/include/{ => uapi}/asm/bitsperlong.h (100%)
create mode 100644 arch/powerpc/include/uapi/asm/bootx.h
rename arch/powerpc/include/{ => uapi}/asm/byteorder.h (100%)
[GIT PULL] Disintegrate UAPI for m32r [ver #2]
Can you merge the following branch into the m32r tree please.
This is to complete part of the UAPI disintegration for which the preparatory
patches were pulled recently.
Now that the fixups and the asm-generic chunk have been merged, I've
regenerated the patches to get rid of those dependencies and to take account of
any changes made so far in the merge window. If you have already pulled the
older version of the branch aimed at you, then please feel free to ignore this
request.
The following changes since commit 9e2d8656f5e8aa214e66b462680cf86b210b74a8:
Merge branch 'akpm' (Andrew's patch-bomb) (2012-10-09 16:23:15 +0900)
are available in the git repository at:
git://git.infradead.org/users/dhowells/linux-headers.git
tags/disintegrate-m32r-20121009
for you to fetch changes up to 90fc366ea41f3595286f18e15b49d3cef8b85ceb:
UAPI: (Scripted) Disintegrate arch/m32r/include/asm (2012-10-09 09:47:03
+0100)
UAPI Disintegration 2012-10-09
David Howells (1):
UAPI: (Scripted) Disintegrate arch/m32r/include/asm
arch/m32r/include/asm/Kbuild | 1 -
arch/m32r/include/asm/ptrace.h | 110 +---
arch/m32r/include/asm/setup.h | 9 +-
arch/m32r/include/asm/signal.h | 123 +
arch/m32r/include/asm/termios.h| 42 +---
arch/m32r/include/asm/types.h | 5 +-
arch/m32r/include/asm/unistd.h | 333 +---
arch/m32r/include/uapi/asm/Kbuild | 30 +++
arch/m32r/include/{ => uapi}/asm/auxvec.h | 0
arch/m32r/include/{ => uapi}/asm/bitsperlong.h | 0
arch/m32r/include/{ => uapi}/asm/byteorder.h | 0
arch/m32r/include/{ => uapi}/asm/errno.h | 0
arch/m32r/include/{ => uapi}/asm/fcntl.h | 0
arch/m32r/include/{ => uapi}/asm/ioctl.h | 0
arch/m32r/include/{ => uapi}/asm/ioctls.h | 0
arch/m32r/include/{ => uapi}/asm/ipcbuf.h | 0
arch/m32r/include/{ => uapi}/asm/mman.h| 0
arch/m32r/include/{ => uapi}/asm/msgbuf.h | 0
arch/m32r/include/{ => uapi}/asm/param.h | 0
arch/m32r/include/{ => uapi}/asm/poll.h| 0
arch/m32r/include/{ => uapi}/asm/posix_types.h | 0
arch/m32r/include/uapi/asm/ptrace.h| 117 +
arch/m32r/include/{ => uapi}/asm/resource.h| 0
arch/m32r/include/{ => uapi}/asm/sembuf.h | 0
arch/m32r/include/uapi/asm/setup.h | 11 +
arch/m32r/include/{ => uapi}/asm/shmbuf.h | 0
arch/m32r/include/{ => uapi}/asm/sigcontext.h | 0
arch/m32r/include/{ => uapi}/asm/siginfo.h | 0
arch/m32r/include/uapi/asm/signal.h| 123 +
arch/m32r/include/{ => uapi}/asm/socket.h | 0
arch/m32r/include/{ => uapi}/asm/sockios.h | 0
arch/m32r/include/{ => uapi}/asm/stat.h| 0
arch/m32r/include/{ => uapi}/asm/statfs.h | 0
arch/m32r/include/{ => uapi}/asm/swab.h| 0
arch/m32r/include/{ => uapi}/asm/termbits.h| 0
arch/m32r/include/uapi/asm/termios.h | 43
arch/m32r/include/uapi/asm/types.h | 1 +
arch/m32r/include/uapi/asm/unistd.h| 335 +
38 files changed, 668 insertions(+), 615 deletions(-)
rename arch/m32r/include/{ => uapi}/asm/auxvec.h (100%)
rename arch/m32r/include/{ => uapi}/asm/bitsperlong.h (100%)
rename arch/m32r/include/{ => uapi}/asm/byteorder.h (100%)
rename arch/m32r/include/{ => uapi}/asm/errno.h (100%)
rename arch/m32r/include/{ => uapi}/asm/fcntl.h (100%)
rename arch/m32r/include/{ => uapi}/asm/ioctl.h (100%)
rename arch/m32r/include/{ => uapi}/asm/ioctls.h (100%)
rename arch/m32r/include/{ => uapi}/asm/ipcbuf.h (100%)
rename arch/m32r/include/{ => uapi}/asm/mman.h (100%)
rename arch/m32r/include/{ => uapi}/asm/msgbuf.h (100%)
rename arch/m32r/include/{ => uapi}/asm/param.h (100%)
rename arch/m32r/include/{ => uapi}/asm/poll.h (100%)
rename arch/m32r/include/{ => uapi}/asm/posix_types.h (100%)
create mode 100644 arch/m32r/include/uapi/asm/ptrace.h
rename arch/m32r/include/{ => uapi}/asm/resource.h (100%)
rename arch/m32r/include/{ => uapi}/asm/sembuf.h (100%)
create mode 100644 arch/m32r/include/uapi/asm/setup.h
rename arch/m32r/include/{ => uapi}/asm/shmbuf.h (100%)
rename arch/m32r/include/{ => uapi}/asm/sigcontext.h (100%)
rename arch/m32r/include/{ => uapi}/asm/siginfo.h (100%)
create mode 100644 arch/m32r/include/uapi/asm/signal.h
rename arch/m32r/include/{ => uapi}/asm/socket.h (100%)
rename arch/m32r/include/{ => uapi}/asm/sockios.h (100%)
rename arch/m32r/include/{ => uapi}/asm/stat.h (100%)
rename arch/m32r/include/{ => uapi}/asm/statfs.h (100%)
rename arch/m32r/include/{ =>
[GIT PULL] Disintegrate UAPI for openrisc [ver #2]
Can you merge the following branch into the openrisc tree please.
This is to complete part of the UAPI disintegration for which the preparatory
patches were pulled recently.
Now that the fixups and the asm-generic chunk have been merged, I've
regenerated the patches to get rid of those dependencies and to take account of
any changes made so far in the merge window. If you have already pulled the
older version of the branch aimed at you, then please feel free to ignore this
request.
The following changes since commit 9e2d8656f5e8aa214e66b462680cf86b210b74a8:
Merge branch 'akpm' (Andrew's patch-bomb) (2012-10-09 16:23:15 +0900)
are available in the git repository at:
git://git.infradead.org/users/dhowells/linux-headers.git
tags/disintegrate-openrisc-20121009
for you to fetch changes up to 913c230200ceea66dda3fda325af8365b3fdc670:
UAPI: (Scripted) Disintegrate arch/openrisc/include/asm (2012-10-09 09:47:18
+0100)
UAPI Disintegration 2012-10-09
David Howells (1):
UAPI: (Scripted) Disintegrate arch/openrisc/include/asm
arch/openrisc/include/asm/Kbuild | 2 -
arch/openrisc/include/asm/elf.h | 51 +
arch/openrisc/include/asm/ptrace.h| 17 +-
arch/openrisc/include/uapi/asm/Kbuild | 7 +++
arch/openrisc/include/{ => uapi}/asm/byteorder.h | 0
arch/openrisc/include/uapi/asm/elf.h | 69 +++
arch/openrisc/include/{ => uapi}/asm/kvm_para.h | 0
arch/openrisc/include/{ => uapi}/asm/param.h | 0
arch/openrisc/include/uapi/asm/ptrace.h | 35
arch/openrisc/include/{ => uapi}/asm/sigcontext.h | 0
arch/openrisc/include/{ => uapi}/asm/unistd.h | 0
11 files changed, 113 insertions(+), 68 deletions(-)
rename arch/openrisc/include/{ => uapi}/asm/byteorder.h (100%)
create mode 100644 arch/openrisc/include/uapi/asm/elf.h
rename arch/openrisc/include/{ => uapi}/asm/kvm_para.h (100%)
rename arch/openrisc/include/{ => uapi}/asm/param.h (100%)
create mode 100644 arch/openrisc/include/uapi/asm/ptrace.h
rename arch/openrisc/include/{ => uapi}/asm/sigcontext.h (100%)
rename arch/openrisc/include/{ => uapi}/asm/unistd.h (100%)
.
--
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/
[GIT PULL] Disintegrate UAPI for h8300 [ver #2]
Can you merge the following branch into the h8300 tree please.
This is to complete part of the UAPI disintegration for which the preparatory
patches were pulled recently.
Now that the fixups and the asm-generic chunk have been merged, I've
regenerated the patches to get rid of those dependencies and to take account of
any changes made so far in the merge window. If you have already pulled the
older version of the branch aimed at you, then please feel free to ignore this
request.
The following changes since commit 9e2d8656f5e8aa214e66b462680cf86b210b74a8:
Merge branch 'akpm' (Andrew's patch-bomb) (2012-10-09 16:23:15 +0900)
are available in the git repository at:
git://git.infradead.org/users/dhowells/linux-headers.git
tags/disintegrate-h8300-20121009
for you to fetch changes up to c0c32782cbbd986aa2b309bca1dc6eb418ef1014:
UAPI: (Scripted) Disintegrate arch/h8300/include/asm (2012-10-09 09:46:54
+0100)
UAPI Disintegration 2012-10-09
David Howells (1):
UAPI: (Scripted) Disintegrate arch/h8300/include/asm
arch/h8300/include/asm/Kbuild | 1 -
arch/h8300/include/asm/param.h | 15 +-
arch/h8300/include/asm/ptrace.h | 40 +--
arch/h8300/include/asm/signal.h | 121 +
arch/h8300/include/asm/termios.h| 44 +---
arch/h8300/include/asm/types.h | 5 +-
arch/h8300/include/asm/unistd.h | 328 +--
arch/h8300/include/uapi/asm/Kbuild | 31 +++
arch/h8300/include/{ => uapi}/asm/auxvec.h | 0
arch/h8300/include/{ => uapi}/asm/bitsperlong.h | 0
arch/h8300/include/{ => uapi}/asm/byteorder.h | 0
arch/h8300/include/{ => uapi}/asm/errno.h | 0
arch/h8300/include/{ => uapi}/asm/fcntl.h | 0
arch/h8300/include/{ => uapi}/asm/ioctl.h | 0
arch/h8300/include/{ => uapi}/asm/ioctls.h | 0
arch/h8300/include/{ => uapi}/asm/ipcbuf.h | 0
arch/h8300/include/{ => uapi}/asm/kvm_para.h| 0
arch/h8300/include/{ => uapi}/asm/mman.h| 0
arch/h8300/include/{ => uapi}/asm/msgbuf.h | 0
arch/h8300/include/uapi/asm/param.h | 16 ++
arch/h8300/include/{ => uapi}/asm/poll.h| 0
arch/h8300/include/{ => uapi}/asm/posix_types.h | 0
arch/h8300/include/uapi/asm/ptrace.h| 44
arch/h8300/include/{ => uapi}/asm/resource.h| 0
arch/h8300/include/{ => uapi}/asm/sembuf.h | 0
arch/h8300/include/{ => uapi}/asm/setup.h | 0
arch/h8300/include/{ => uapi}/asm/shmbuf.h | 0
arch/h8300/include/{ => uapi}/asm/sigcontext.h | 0
arch/h8300/include/{ => uapi}/asm/siginfo.h | 0
arch/h8300/include/uapi/asm/signal.h| 121 +
arch/h8300/include/{ => uapi}/asm/socket.h | 0
arch/h8300/include/{ => uapi}/asm/sockios.h | 0
arch/h8300/include/{ => uapi}/asm/stat.h| 0
arch/h8300/include/{ => uapi}/asm/statfs.h | 0
arch/h8300/include/{ => uapi}/asm/swab.h| 0
arch/h8300/include/{ => uapi}/asm/termbits.h| 0
arch/h8300/include/uapi/asm/termios.h | 44
arch/h8300/include/uapi/asm/types.h | 1 +
arch/h8300/include/uapi/asm/unistd.h| 330
39 files changed, 595 insertions(+), 546 deletions(-)
rename arch/h8300/include/{ => uapi}/asm/auxvec.h (100%)
rename arch/h8300/include/{ => uapi}/asm/bitsperlong.h (100%)
rename arch/h8300/include/{ => uapi}/asm/byteorder.h (100%)
rename arch/h8300/include/{ => uapi}/asm/errno.h (100%)
rename arch/h8300/include/{ => uapi}/asm/fcntl.h (100%)
rename arch/h8300/include/{ => uapi}/asm/ioctl.h (100%)
rename arch/h8300/include/{ => uapi}/asm/ioctls.h (100%)
rename arch/h8300/include/{ => uapi}/asm/ipcbuf.h (100%)
rename arch/h8300/include/{ => uapi}/asm/kvm_para.h (100%)
rename arch/h8300/include/{ => uapi}/asm/mman.h (100%)
rename arch/h8300/include/{ => uapi}/asm/msgbuf.h (100%)
create mode 100644 arch/h8300/include/uapi/asm/param.h
rename arch/h8300/include/{ => uapi}/asm/poll.h (100%)
rename arch/h8300/include/{ => uapi}/asm/posix_types.h (100%)
create mode 100644 arch/h8300/include/uapi/asm/ptrace.h
rename arch/h8300/include/{ => uapi}/asm/resource.h (100%)
rename arch/h8300/include/{ => uapi}/asm/sembuf.h (100%)
rename arch/h8300/include/{ => uapi}/asm/setup.h (100%)
rename arch/h8300/include/{ => uapi}/asm/shmbuf.h (100%)
rename arch/h8300/include/{ => uapi}/asm/sigcontext.h (100%)
rename arch/h8300/include/{ => uapi}/asm/siginfo.h (100%)
create mode 100644 arch/h8300/include/uapi/asm/signal.h
rename arch/h8300/include/{ => uapi}/asm/socket.h (100%)
rename arch/h8300/include/{ =>
[GIT PULL] Disintegrate UAPI for x86 [ver #2]
Can you merge the following branch into the x86 tree please.
This is to complete part of the UAPI disintegration for which the preparatory
patches were pulled recently.
Now that the fixups and the asm-generic chunk have been merged, I've
regenerated the patches to get rid of those dependencies and to take account of
any changes made so far in the merge window. If you have already pulled the
older version of the branch aimed at you, then please feel free to ignore this
request.
The following changes since commit 9e2d8656f5e8aa214e66b462680cf86b210b74a8:
Merge branch 'akpm' (Andrew's patch-bomb) (2012-10-09 16:23:15 +0900)
are available in the git repository at:
git://git.infradead.org/users/dhowells/linux-headers.git
tags/disintegrate-x86-20121009
for you to fetch changes up to 8d2c63c2b664bae1fb0f386661ea5f635330e570:
UAPI: (Scripted) Disintegrate arch/x86/include/asm (2012-10-09 09:47:54 +0100)
UAPI Disintegration 2012-10-09
David Howells (1):
UAPI: (Scripted) Disintegrate arch/x86/include/asm
arch/x86/include/asm/Kbuild | 23 ---
arch/x86/include/asm/boot.h | 9 +-
arch/x86/include/asm/debugreg.h | 79 +---
arch/x86/include/asm/e820.h | 74 +---
arch/x86/include/asm/hw_breakpoint.h | 5 +-
arch/x86/include/asm/ist.h| 17 +-
arch/x86/include/asm/kvm_para.h | 99 +-
arch/x86/include/asm/mce.h| 119 +---
arch/x86/include/asm/msr.h| 11 +-
arch/x86/include/asm/mtrr.h | 93 +
arch/x86/include/asm/posix_types.h| 10 -
arch/x86/include/asm/processor-flags.h| 97 +-
arch/x86/include/asm/ptrace.h | 75 +---
arch/x86/include/asm/setup.h | 5 +-
arch/x86/include/asm/sigcontext.h | 216 +
arch/x86/include/asm/signal.h | 140 +-
arch/x86/include/asm/unistd.h | 14 +-
arch/x86/include/asm/vm86.h | 128 +
arch/x86/include/asm/vsyscall.h | 16 +-
arch/x86/include/uapi/asm/Kbuild | 55 ++
arch/x86/include/{ => uapi}/asm/a.out.h | 0
arch/x86/include/{ => uapi}/asm/auxvec.h | 0
arch/x86/include/{ => uapi}/asm/bitsperlong.h | 0
arch/x86/include/uapi/asm/boot.h | 10 +
arch/x86/include/{ => uapi}/asm/bootparam.h | 0
arch/x86/include/{ => uapi}/asm/byteorder.h | 0
arch/x86/include/uapi/asm/debugreg.h | 80
arch/x86/include/uapi/asm/e820.h | 75
arch/x86/include/{ => uapi}/asm/errno.h | 0
arch/x86/include/{ => uapi}/asm/fcntl.h | 0
arch/x86/include/{ => uapi}/asm/hyperv.h | 0
arch/x86/include/{ => uapi}/asm/ioctl.h | 0
arch/x86/include/{ => uapi}/asm/ioctls.h | 0
arch/x86/include/{ => uapi}/asm/ipcbuf.h | 0
arch/x86/include/uapi/asm/ist.h | 29 +++
arch/x86/include/{ => uapi}/asm/kvm.h | 0
arch/x86/include/uapi/asm/kvm_para.h | 100 ++
arch/x86/include/{ => uapi}/asm/ldt.h | 0
arch/x86/include/uapi/asm/mce.h | 121
arch/x86/include/{ => uapi}/asm/mman.h| 0
arch/x86/include/{ => uapi}/asm/msgbuf.h | 0
arch/x86/include/{ => uapi}/asm/msr-index.h | 0
arch/x86/include/uapi/asm/msr.h | 15 ++
arch/x86/include/uapi/asm/mtrr.h | 117
arch/x86/include/{ => uapi}/asm/param.h | 0
arch/x86/include/{ => uapi}/asm/poll.h| 0
arch/x86/include/uapi/asm/posix_types.h | 9 +
arch/x86/include/{ => uapi}/asm/posix_types_32.h | 0
arch/x86/include/{ => uapi}/asm/posix_types_64.h | 0
arch/x86/include/{ => uapi}/asm/posix_types_x32.h | 0
arch/x86/include/{ => uapi}/asm/prctl.h | 0
arch/x86/include/uapi/asm/processor-flags.h | 99 ++
arch/x86/include/{ => uapi}/asm/ptrace-abi.h | 0
arch/x86/include/uapi/asm/ptrace.h| 78
arch/x86/include/{ => uapi}/asm/resource.h| 0
arch/x86/include/{ => uapi}/asm/sembuf.h | 0
arch/x86/include/{ => uapi}/asm/shmbuf.h | 0
arch/x86/include/uapi/asm/sigcontext.h| 221 ++
arch/x86/include/{ => uapi}/asm/sigcontext32.h| 0
arch/x86/include/{ => uapi}/asm/siginfo.h | 0
arch/x86/include/uapi/asm/signal.h| 145 +
[GIT PULL] Disintegrate UAPI for score [ver #2]
Can you merge the following branch into the score tree please.
This is to complete part of the UAPI disintegration for which the preparatory
patches were pulled recently.
Now that the fixups and the asm-generic chunk have been merged, I've
regenerated the patches to get rid of those dependencies and to take account of
any changes made so far in the merge window. If you have already pulled the
older version of the branch aimed at you, then please feel free to ignore this
request.
The following changes since commit 9e2d8656f5e8aa214e66b462680cf86b210b74a8:
Merge branch 'akpm' (Andrew's patch-bomb) (2012-10-09 16:23:15 +0900)
are available in the git repository at:
git://git.infradead.org/users/dhowells/linux-headers.git
tags/disintegrate-score-20121009
for you to fetch changes up to f2f8f65349ca712d47d50c58f37fb76bc56992e3:
UAPI: (Scripted) Disintegrate arch/score/include/asm (2012-10-09 09:47:35
+0100)
UAPI Disintegration 2012-10-09
David Howells (1):
UAPI: (Scripted) Disintegrate arch/score/include/asm
arch/score/include/asm/Kbuild | 1 -
arch/score/include/asm/ptrace.h | 74 +---
arch/score/include/asm/setup.h | 7 +--
arch/score/include/uapi/asm/Kbuild | 31 ++
arch/score/include/{ => uapi}/asm/auxvec.h | 0
arch/score/include/{ => uapi}/asm/bitsperlong.h | 0
arch/score/include/{ => uapi}/asm/byteorder.h | 0
arch/score/include/{ => uapi}/asm/errno.h | 0
arch/score/include/{ => uapi}/asm/fcntl.h | 0
arch/score/include/{ => uapi}/asm/ioctl.h | 0
arch/score/include/{ => uapi}/asm/ioctls.h | 0
arch/score/include/{ => uapi}/asm/ipcbuf.h | 0
arch/score/include/{ => uapi}/asm/kvm_para.h| 0
arch/score/include/{ => uapi}/asm/mman.h| 0
arch/score/include/{ => uapi}/asm/msgbuf.h | 0
arch/score/include/{ => uapi}/asm/param.h | 0
arch/score/include/{ => uapi}/asm/poll.h| 0
arch/score/include/{ => uapi}/asm/posix_types.h | 0
arch/score/include/uapi/asm/ptrace.h| 76 +
arch/score/include/{ => uapi}/asm/resource.h| 0
arch/score/include/{ => uapi}/asm/sembuf.h | 0
arch/score/include/uapi/asm/setup.h | 9 +++
arch/score/include/{ => uapi}/asm/shmbuf.h | 0
arch/score/include/{ => uapi}/asm/sigcontext.h | 0
arch/score/include/{ => uapi}/asm/siginfo.h | 0
arch/score/include/{ => uapi}/asm/signal.h | 0
arch/score/include/{ => uapi}/asm/socket.h | 0
arch/score/include/{ => uapi}/asm/sockios.h | 0
arch/score/include/{ => uapi}/asm/stat.h| 0
arch/score/include/{ => uapi}/asm/statfs.h | 0
arch/score/include/{ => uapi}/asm/swab.h| 0
arch/score/include/{ => uapi}/asm/termbits.h| 0
arch/score/include/{ => uapi}/asm/termios.h | 0
arch/score/include/{ => uapi}/asm/types.h | 0
arch/score/include/{ => uapi}/asm/unistd.h | 0
35 files changed, 118 insertions(+), 80 deletions(-)
rename arch/score/include/{ => uapi}/asm/auxvec.h (100%)
rename arch/score/include/{ => uapi}/asm/bitsperlong.h (100%)
rename arch/score/include/{ => uapi}/asm/byteorder.h (100%)
rename arch/score/include/{ => uapi}/asm/errno.h (100%)
rename arch/score/include/{ => uapi}/asm/fcntl.h (100%)
rename arch/score/include/{ => uapi}/asm/ioctl.h (100%)
rename arch/score/include/{ => uapi}/asm/ioctls.h (100%)
rename arch/score/include/{ => uapi}/asm/ipcbuf.h (100%)
rename arch/score/include/{ => uapi}/asm/kvm_para.h (100%)
rename arch/score/include/{ => uapi}/asm/mman.h (100%)
rename arch/score/include/{ => uapi}/asm/msgbuf.h (100%)
rename arch/score/include/{ => uapi}/asm/param.h (100%)
rename arch/score/include/{ => uapi}/asm/poll.h (100%)
rename arch/score/include/{ => uapi}/asm/posix_types.h (100%)
create mode 100644 arch/score/include/uapi/asm/ptrace.h
rename arch/score/include/{ => uapi}/asm/resource.h (100%)
rename arch/score/include/{ => uapi}/asm/sembuf.h (100%)
create mode 100644 arch/score/include/uapi/asm/setup.h
rename arch/score/include/{ => uapi}/asm/shmbuf.h (100%)
rename arch/score/include/{ => uapi}/asm/sigcontext.h (100%)
rename arch/score/include/{ => uapi}/asm/siginfo.h (100%)
rename arch/score/include/{ => uapi}/asm/signal.h (100%)
rename arch/score/include/{ => uapi}/asm/socket.h (100%)
rename arch/score/include/{ => uapi}/asm/sockios.h (100%)
rename arch/score/include/{ => uapi}/asm/stat.h (100%)
rename arch/score/include/{ => uapi}/asm/statfs.h (100%)
rename arch/score/include/{ => uapi}/asm/swab.h (100%)
rename arch/score/include/{ => uapi}/asm/termbits.h (100%)
renam
[GIT PULL] Disintegrate UAPI for unicore32 [ver #2]
Can you merge the following branch into the unicore32 tree please.
This is to complete part of the UAPI disintegration for which the preparatory
patches were pulled recently.
Now that the fixups and the asm-generic chunk have been merged, I've
regenerated the patches to get rid of those dependencies and to take account of
any changes made so far in the merge window. If you have already pulled the
older version of the branch aimed at you, then please feel free to ignore this
request.
The following changes since commit 9e2d8656f5e8aa214e66b462680cf86b210b74a8:
Merge branch 'akpm' (Andrew's patch-bomb) (2012-10-09 16:23:15 +0900)
are available in the git repository at:
git://git.infradead.org/users/dhowells/linux-headers.git
tags/disintegrate-unicore32-20121009
for you to fetch changes up to 2a0a9522d64a73b8c5b37a375cd0d46c2abc18fb:
UAPI: (Scripted) Disintegrate arch/unicore32/include/asm (2012-10-09 09:47:48
+0100)
UAPI Disintegration 2012-10-09
David Howells (1):
UAPI: (Scripted) Disintegrate arch/unicore32/include/asm
arch/unicore32/include/asm/Kbuild | 1 -
arch/unicore32/include/asm/ptrace.h| 76 +-
arch/unicore32/include/uapi/asm/Kbuild | 5 ++
arch/unicore32/include/{ => uapi}/asm/byteorder.h | 0
arch/unicore32/include/{ => uapi}/asm/kvm_para.h | 0
arch/unicore32/include/uapi/asm/ptrace.h | 90 ++
arch/unicore32/include/{ => uapi}/asm/sigcontext.h | 0
arch/unicore32/include/{ => uapi}/asm/unistd.h | 0
8 files changed, 96 insertions(+), 76 deletions(-)
rename arch/unicore32/include/{ => uapi}/asm/byteorder.h (100%)
rename arch/unicore32/include/{ => uapi}/asm/kvm_para.h (100%)
create mode 100644 arch/unicore32/include/uapi/asm/ptrace.h
rename arch/unicore32/include/{ => uapi}/asm/sigcontext.h (100%)
rename arch/unicore32/include/{ => uapi}/asm/unistd.h (100%)
.
--
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/
[GIT PULL] Disintegrate UAPI for parisc [ver #2]
Can you merge the following branch into the parisc tree please.
This is to complete part of the UAPI disintegration for which the preparatory
patches were pulled recently.
Now that the fixups and the asm-generic chunk have been merged, I've
regenerated the patches to get rid of those dependencies and to take account of
any changes made so far in the merge window. If you have already pulled the
older version of the branch aimed at you, then please feel free to ignore this
request.
The following changes since commit 9e2d8656f5e8aa214e66b462680cf86b210b74a8:
Merge branch 'akpm' (Andrew's patch-bomb) (2012-10-09 16:23:15 +0900)
are available in the git repository at:
git://git.infradead.org/users/dhowells/linux-headers.git
tags/disintegrate-parisc-20121009
for you to fetch changes up to 7869b46c99d8de719f7543d6ba432a7fcc3c78b3:
UAPI: (Scripted) Disintegrate arch/parisc/include/asm (2012-10-09 09:47:22
+0100)
UAPI Disintegration 2012-10-09
David Howells (1):
UAPI: (Scripted) Disintegrate arch/parisc/include/asm
arch/parisc/include/asm/Kbuild | 2 -
arch/parisc/include/asm/pdc.h| 423 +---
arch/parisc/include/asm/ptrace.h | 46 +-
arch/parisc/include/asm/signal.h | 113 +--
arch/parisc/include/asm/termios.h| 41 +-
arch/parisc/include/asm/unistd.h | 835 +-
arch/parisc/include/uapi/asm/Kbuild | 32 +
arch/parisc/include/{ => uapi}/asm/auxvec.h | 0
arch/parisc/include/{ => uapi}/asm/bitsperlong.h | 0
arch/parisc/include/{ => uapi}/asm/byteorder.h | 0
arch/parisc/include/{ => uapi}/asm/errno.h | 0
arch/parisc/include/{ => uapi}/asm/fcntl.h | 0
arch/parisc/include/{ => uapi}/asm/ioctl.h | 0
arch/parisc/include/{ => uapi}/asm/ioctls.h | 0
arch/parisc/include/{ => uapi}/asm/ipcbuf.h | 0
arch/parisc/include/{ => uapi}/asm/kvm_para.h| 0
arch/parisc/include/{ => uapi}/asm/mman.h| 0
arch/parisc/include/{ => uapi}/asm/msgbuf.h | 0
arch/parisc/include/{ => uapi}/asm/param.h | 0
arch/parisc/include/uapi/asm/pdc.h | 427
arch/parisc/include/{ => uapi}/asm/poll.h| 0
arch/parisc/include/{ => uapi}/asm/posix_types.h | 0
arch/parisc/include/uapi/asm/ptrace.h| 47 ++
arch/parisc/include/{ => uapi}/asm/resource.h| 0
arch/parisc/include/{ => uapi}/asm/sembuf.h | 0
arch/parisc/include/{ => uapi}/asm/setup.h | 0
arch/parisc/include/{ => uapi}/asm/shmbuf.h | 0
arch/parisc/include/{ => uapi}/asm/sigcontext.h | 0
arch/parisc/include/{ => uapi}/asm/siginfo.h | 0
arch/parisc/include/uapi/asm/signal.h| 118
arch/parisc/include/{ => uapi}/asm/socket.h | 0
arch/parisc/include/{ => uapi}/asm/sockios.h | 0
arch/parisc/include/{ => uapi}/asm/stat.h| 0
arch/parisc/include/{ => uapi}/asm/statfs.h | 0
arch/parisc/include/{ => uapi}/asm/swab.h| 0
arch/parisc/include/{ => uapi}/asm/termbits.h| 0
arch/parisc/include/uapi/asm/termios.h | 43 ++
arch/parisc/include/{ => uapi}/asm/types.h | 0
arch/parisc/include/uapi/asm/unistd.h| 837 +++
39 files changed, 1511 insertions(+), 1453 deletions(-)
rename arch/parisc/include/{ => uapi}/asm/auxvec.h (100%)
rename arch/parisc/include/{ => uapi}/asm/bitsperlong.h (100%)
rename arch/parisc/include/{ => uapi}/asm/byteorder.h (100%)
rename arch/parisc/include/{ => uapi}/asm/errno.h (100%)
rename arch/parisc/include/{ => uapi}/asm/fcntl.h (100%)
rename arch/parisc/include/{ => uapi}/asm/ioctl.h (100%)
rename arch/parisc/include/{ => uapi}/asm/ioctls.h (100%)
rename arch/parisc/include/{ => uapi}/asm/ipcbuf.h (100%)
rename arch/parisc/include/{ => uapi}/asm/kvm_para.h (100%)
rename arch/parisc/include/{ => uapi}/asm/mman.h (100%)
rename arch/parisc/include/{ => uapi}/asm/msgbuf.h (100%)
rename arch/parisc/include/{ => uapi}/asm/param.h (100%)
create mode 100644 arch/parisc/include/uapi/asm/pdc.h
rename arch/parisc/include/{ => uapi}/asm/poll.h (100%)
rename arch/parisc/include/{ => uapi}/asm/posix_types.h (100%)
create mode 100644 arch/parisc/include/uapi/asm/ptrace.h
rename arch/parisc/include/{ => uapi}/asm/resource.h (100%)
rename arch/parisc/include/{ => uapi}/asm/sembuf.h (100%)
rename arch/parisc/include/{ => uapi}/asm/setup.h (100%)
rename arch/parisc/include/{ => uapi}/asm/shmbuf.h (100%)
rename arch/parisc/include/{ => uapi}/asm/sigcontext.h (100%)
rename arch/parisc/include/{ => uapi}/asm/siginfo.h (100%)
create mode 100644 arch/parisc/i
[GIT PULL] Disintegrate UAPI for xtensa [ver #2]
Can you merge the following branch into the xtensa tree please.
This is to complete part of the UAPI disintegration for which the preparatory
patches were pulled recently.
Now that the fixups and the asm-generic chunk have been merged, I've
regenerated the patches to get rid of those dependencies and to take account of
any changes made so far in the merge window. If you have already pulled the
older version of the branch aimed at you, then please feel free to ignore this
request.
The following changes since commit 9e2d8656f5e8aa214e66b462680cf86b210b74a8:
Merge branch 'akpm' (Andrew's patch-bomb) (2012-10-09 16:23:15 +0900)
are available in the git repository at:
git://git.infradead.org/users/dhowells/linux-headers.git
tags/disintegrate-xtensa-20121009
for you to fetch changes up to 91a0696e40414e9f1554cd91060f6b404d545cb3:
UAPI: (Scripted) Disintegrate arch/xtensa/include/asm (2012-10-09 09:47:57
+0100)
UAPI Disintegration 2012-10-09
David Howells (1):
UAPI: (Scripted) Disintegrate arch/xtensa/include/asm
arch/xtensa/include/asm/Kbuild | 1 -
arch/xtensa/include/asm/param.h | 20 +-
arch/xtensa/include/asm/ptrace.h | 66 +--
arch/xtensa/include/asm/signal.h | 134 +
arch/xtensa/include/asm/termios.h| 43 +-
arch/xtensa/include/asm/types.h | 15 +-
arch/xtensa/include/asm/unistd.h | 698 +-
arch/xtensa/include/uapi/asm/Kbuild | 31 +
arch/xtensa/include/{ => uapi}/asm/auxvec.h | 0
arch/xtensa/include/{ => uapi}/asm/bitsperlong.h | 0
arch/xtensa/include/{ => uapi}/asm/byteorder.h | 0
arch/xtensa/include/{ => uapi}/asm/errno.h | 0
arch/xtensa/include/{ => uapi}/asm/fcntl.h | 0
arch/xtensa/include/{ => uapi}/asm/ioctl.h | 0
arch/xtensa/include/{ => uapi}/asm/ioctls.h | 0
arch/xtensa/include/{ => uapi}/asm/ipcbuf.h | 0
arch/xtensa/include/{ => uapi}/asm/kvm_para.h| 0
arch/xtensa/include/{ => uapi}/asm/mman.h| 0
arch/xtensa/include/{ => uapi}/asm/msgbuf.h | 0
arch/xtensa/include/uapi/asm/param.h | 30 +
arch/xtensa/include/{ => uapi}/asm/poll.h| 0
arch/xtensa/include/{ => uapi}/asm/posix_types.h | 0
arch/xtensa/include/uapi/asm/ptrace.h| 77 +++
arch/xtensa/include/{ => uapi}/asm/resource.h| 0
arch/xtensa/include/{ => uapi}/asm/sembuf.h | 0
arch/xtensa/include/{ => uapi}/asm/setup.h | 0
arch/xtensa/include/{ => uapi}/asm/shmbuf.h | 0
arch/xtensa/include/{ => uapi}/asm/sigcontext.h | 0
arch/xtensa/include/{ => uapi}/asm/siginfo.h | 0
arch/xtensa/include/uapi/asm/signal.h| 148 +
arch/xtensa/include/{ => uapi}/asm/socket.h | 0
arch/xtensa/include/{ => uapi}/asm/sockios.h | 0
arch/xtensa/include/{ => uapi}/asm/stat.h| 0
arch/xtensa/include/{ => uapi}/asm/statfs.h | 0
arch/xtensa/include/{ => uapi}/asm/swab.h| 0
arch/xtensa/include/{ => uapi}/asm/termbits.h| 0
arch/xtensa/include/uapi/asm/termios.h | 56 ++
arch/xtensa/include/uapi/asm/types.h | 28 +
arch/xtensa/include/uapi/asm/unistd.h| 709 +++
39 files changed, 1086 insertions(+), 970 deletions(-)
rename arch/xtensa/include/{ => uapi}/asm/auxvec.h (100%)
rename arch/xtensa/include/{ => uapi}/asm/bitsperlong.h (100%)
rename arch/xtensa/include/{ => uapi}/asm/byteorder.h (100%)
rename arch/xtensa/include/{ => uapi}/asm/errno.h (100%)
rename arch/xtensa/include/{ => uapi}/asm/fcntl.h (100%)
rename arch/xtensa/include/{ => uapi}/asm/ioctl.h (100%)
rename arch/xtensa/include/{ => uapi}/asm/ioctls.h (100%)
rename arch/xtensa/include/{ => uapi}/asm/ipcbuf.h (100%)
rename arch/xtensa/include/{ => uapi}/asm/kvm_para.h (100%)
rename arch/xtensa/include/{ => uapi}/asm/mman.h (100%)
rename arch/xtensa/include/{ => uapi}/asm/msgbuf.h (100%)
create mode 100644 arch/xtensa/include/uapi/asm/param.h
rename arch/xtensa/include/{ => uapi}/asm/poll.h (100%)
rename arch/xtensa/include/{ => uapi}/asm/posix_types.h (100%)
create mode 100644 arch/xtensa/include/uapi/asm/ptrace.h
rename arch/xtensa/include/{ => uapi}/asm/resource.h (100%)
rename arch/xtensa/include/{ => uapi}/asm/sembuf.h (100%)
rename arch/xtensa/include/{ => uapi}/asm/setup.h (100%)
rename arch/xtensa/include/{ => uapi}/asm/shmbuf.h (100%)
rename arch/xtensa/include/{ => uapi}/asm/sigcontext.h (100%)
rename arch/xtensa/include/{ => uapi}/asm/siginfo.h (100%)
create mode 100644 arch/xtensa/include/uapi/asm/signal.h
rename arch/xtensa/include/{ => uapi}/asm/socke
[GIT PULL] Disintegrate UAPI for s390 [ver #2]
Can you merge the following branch into the s390 tree please.
This is to complete part of the UAPI disintegration for which the preparatory
patches were pulled recently.
Now that the fixups and the asm-generic chunk have been merged, I've
regenerated the patches to get rid of those dependencies and to take account of
any changes made so far in the merge window. If you have already pulled the
older version of the branch aimed at you, then please feel free to ignore this
request.
The following changes since commit 9e2d8656f5e8aa214e66b462680cf86b210b74a8:
Merge branch 'akpm' (Andrew's patch-bomb) (2012-10-09 16:23:15 +0900)
are available in the git repository at:
git://git.infradead.org/users/dhowells/linux-headers.git
tags/disintegrate-s390-20121009
for you to fetch changes up to 9807f75955ea7f1877981056755284481873115c:
UAPI: (Scripted) Disintegrate arch/s390/include/asm (2012-10-09 09:47:31
+0100)
UAPI Disintegration 2012-10-09
David Howells (1):
UAPI: (Scripted) Disintegrate arch/s390/include/asm
arch/s390/include/asm/Kbuild | 14 -
arch/s390/include/asm/chpid.h | 17 +-
arch/s390/include/asm/cmb.h| 51 +--
arch/s390/include/asm/debug.h | 28 +-
arch/s390/include/asm/kvm_para.h | 14 +-
arch/s390/include/asm/mman.h | 6 +-
arch/s390/include/asm/ptrace.h | 462 +---
arch/s390/include/asm/schid.h | 15 +-
arch/s390/include/asm/setup.h | 7 +-
arch/s390/include/asm/signal.h | 128 +--
arch/s390/include/asm/termios.h| 42 +--
arch/s390/include/asm/types.h | 15 +-
arch/s390/include/asm/unistd.h | 367 +--
arch/s390/include/uapi/asm/Kbuild | 45 +++
arch/s390/include/{ => uapi}/asm/auxvec.h | 0
arch/s390/include/{ => uapi}/asm/bitsperlong.h | 0
arch/s390/include/{ => uapi}/asm/byteorder.h | 0
arch/s390/include/uapi/asm/chpid.h | 22 ++
arch/s390/include/{ => uapi}/asm/chsc.h| 0
arch/s390/include/uapi/asm/cmb.h | 53 +++
arch/s390/include/{ => uapi}/asm/dasd.h| 0
arch/s390/include/uapi/asm/debug.h | 34 ++
arch/s390/include/{ => uapi}/asm/errno.h | 0
arch/s390/include/{ => uapi}/asm/fcntl.h | 0
arch/s390/include/{ => uapi}/asm/ioctl.h | 0
arch/s390/include/{ => uapi}/asm/ioctls.h | 0
arch/s390/include/{ => uapi}/asm/ipcbuf.h | 0
arch/s390/include/{ => uapi}/asm/kvm.h | 0
arch/s390/include/{ => uapi}/asm/kvm_virtio.h | 0
arch/s390/include/uapi/asm/mman.h | 6 +
arch/s390/include/{ => uapi}/asm/monwriter.h | 0
arch/s390/include/{ => uapi}/asm/msgbuf.h | 0
arch/s390/include/{ => uapi}/asm/param.h | 0
arch/s390/include/{ => uapi}/asm/poll.h| 0
arch/s390/include/{ => uapi}/asm/posix_types.h | 0
arch/s390/include/uapi/asm/ptrace.h| 472 +
arch/s390/include/{ => uapi}/asm/qeth.h| 0
arch/s390/include/{ => uapi}/asm/resource.h| 0
arch/s390/include/uapi/asm/schid.h | 16 +
arch/s390/include/{ => uapi}/asm/sembuf.h | 0
arch/s390/include/uapi/asm/setup.h | 13 +
arch/s390/include/{ => uapi}/asm/shmbuf.h | 0
arch/s390/include/{ => uapi}/asm/sigcontext.h | 0
arch/s390/include/{ => uapi}/asm/siginfo.h | 0
arch/s390/include/uapi/asm/signal.h| 135 +++
arch/s390/include/{ => uapi}/asm/socket.h | 0
arch/s390/include/{ => uapi}/asm/sockios.h | 0
arch/s390/include/{ => uapi}/asm/stat.h| 0
arch/s390/include/{ => uapi}/asm/statfs.h | 0
arch/s390/include/{ => uapi}/asm/swab.h| 0
arch/s390/include/{ => uapi}/asm/tape390.h | 0
arch/s390/include/{ => uapi}/asm/termbits.h| 0
arch/s390/include/uapi/asm/termios.h | 49 +++
arch/s390/include/uapi/asm/types.h | 22 ++
arch/s390/include/{ => uapi}/asm/ucontext.h| 0
arch/s390/include/uapi/asm/unistd.h| 374
arch/s390/include/{ => uapi}/asm/vtoc.h| 0
arch/s390/include/{ => uapi}/asm/zcrypt.h | 0
58 files changed, 1258 insertions(+), 1149 deletions(-)
rename arch/s390/include/{ => uapi}/asm/auxvec.h (100%)
rename arch/s390/include/{ => uapi}/asm/bitsperlong.h (100%)
rename arch/s390/include/{ => uapi}/asm/byteorder.h (100%)
create mode 100644 arch/s390/include/uapi/asm/chpid.h
rename arch/s390/include/{ => uapi}/asm/chsc.h (100%)
create mode 100644 arch/s390/include/uapi/asm/cmb.h
rename arch/s39
[GIT PULL] Disintegrate UAPI for microblaze [ver #2]
Can you merge the following branch into the microblaze tree please.
This is to complete part of the UAPI disintegration for which the preparatory
patches were pulled recently.
Now that the fixups and the asm-generic chunk have been merged, I've
regenerated the patches to get rid of those dependencies and to take account of
any changes made so far in the merge window. If you have already pulled the
older version of the branch aimed at you, then please feel free to ignore this
request.
The following changes since commit 9e2d8656f5e8aa214e66b462680cf86b210b74a8:
Merge branch 'akpm' (Andrew's patch-bomb) (2012-10-09 16:23:15 +0900)
are available in the git repository at:
git://git.infradead.org/users/dhowells/linux-headers.git
tags/disintegrate-microblaze-20121009
for you to fetch changes up to 1883baaa2ea07d83228d5a83a3133cd02bab7fc6:
UAPI: (Scripted) Disintegrate arch/microblaze/include/asm (2012-10-09
09:47:10 +0100)
UAPI Disintegration 2012-10-09
David Howells (1):
UAPI: (Scripted) Disintegrate arch/microblaze/include/asm
arch/microblaze/include/asm/Kbuild | 2 -
arch/microblaze/include/asm/elf.h | 97 +
arch/microblaze/include/asm/ptrace.h | 62 +---
arch/microblaze/include/asm/setup.h| 6 +-
arch/microblaze/include/asm/unistd.h | 390 +---
arch/microblaze/include/uapi/asm/Kbuild| 32 ++
arch/microblaze/include/{ => uapi}/asm/auxvec.h| 0
.../include/{ => uapi}/asm/bitsperlong.h | 0
arch/microblaze/include/{ => uapi}/asm/byteorder.h | 0
arch/microblaze/include/uapi/asm/elf.h | 121 +++
arch/microblaze/include/{ => uapi}/asm/errno.h | 0
arch/microblaze/include/{ => uapi}/asm/fcntl.h | 0
arch/microblaze/include/{ => uapi}/asm/ioctl.h | 0
arch/microblaze/include/{ => uapi}/asm/ioctls.h| 0
arch/microblaze/include/{ => uapi}/asm/ipcbuf.h| 0
arch/microblaze/include/{ => uapi}/asm/kvm_para.h | 0
arch/microblaze/include/{ => uapi}/asm/mman.h | 0
arch/microblaze/include/{ => uapi}/asm/msgbuf.h| 0
arch/microblaze/include/{ => uapi}/asm/param.h | 0
arch/microblaze/include/{ => uapi}/asm/poll.h | 0
.../include/{ => uapi}/asm/posix_types.h | 0
arch/microblaze/include/uapi/asm/ptrace.h | 72
arch/microblaze/include/{ => uapi}/asm/resource.h | 0
arch/microblaze/include/{ => uapi}/asm/sembuf.h| 0
arch/microblaze/include/uapi/asm/setup.h | 19 +
arch/microblaze/include/{ => uapi}/asm/shmbuf.h| 0
.../microblaze/include/{ => uapi}/asm/sigcontext.h | 0
arch/microblaze/include/{ => uapi}/asm/siginfo.h | 0
arch/microblaze/include/{ => uapi}/asm/signal.h| 0
arch/microblaze/include/{ => uapi}/asm/socket.h| 0
arch/microblaze/include/{ => uapi}/asm/sockios.h | 0
arch/microblaze/include/{ => uapi}/asm/stat.h | 0
arch/microblaze/include/{ => uapi}/asm/statfs.h| 0
arch/microblaze/include/{ => uapi}/asm/swab.h | 0
arch/microblaze/include/{ => uapi}/asm/termbits.h | 0
arch/microblaze/include/{ => uapi}/asm/termios.h | 0
arch/microblaze/include/{ => uapi}/asm/types.h | 0
arch/microblaze/include/uapi/asm/unistd.h | 400 +
38 files changed, 649 insertions(+), 552 deletions(-)
rename arch/microblaze/include/{ => uapi}/asm/auxvec.h (100%)
rename arch/microblaze/include/{ => uapi}/asm/bitsperlong.h (100%)
rename arch/microblaze/include/{ => uapi}/asm/byteorder.h (100%)
create mode 100644 arch/microblaze/include/uapi/asm/elf.h
rename arch/microblaze/include/{ => uapi}/asm/errno.h (100%)
rename arch/microblaze/include/{ => uapi}/asm/fcntl.h (100%)
rename arch/microblaze/include/{ => uapi}/asm/ioctl.h (100%)
rename arch/microblaze/include/{ => uapi}/asm/ioctls.h (100%)
rename arch/microblaze/include/{ => uapi}/asm/ipcbuf.h (100%)
rename arch/microblaze/include/{ => uapi}/asm/kvm_para.h (100%)
rename arch/microblaze/include/{ => uapi}/asm/mman.h (100%)
rename arch/microblaze/include/{ => uapi}/asm/msgbuf.h (100%)
rename arch/microblaze/include/{ => uapi}/asm/param.h (100%)
rename arch/microblaze/include/{ => uapi}/asm/poll.h (100%)
rename arch/microblaze/include/{ => uapi}/asm/posix_types.h (100%)
create mode 100644 arch/microblaze/include/uapi/asm/ptrace.h
rename arch/microblaze/include/{ => uapi}/asm/resource.h (100%)
rename arch/microblaze/include/{ => uapi}/asm/sembuf.h (100%)
create mode 100644 arch/microblaze/include/uapi/asm/setup.h
rename arch/microblaze/include/{ => uapi}/asm/shmbuf.h (100%)
rename arch/microblaze/include/{ => uapi}/asm/sigcontext.h (10
[GIT PULL] Disintegrate UAPI for m68k [ver #2]
Can you merge the following branch into the m68k tree please.
This is to complete part of the UAPI disintegration for which the preparatory
patches were pulled recently.
Now that the fixups and the asm-generic chunk have been merged, I've
regenerated the patches to get rid of those dependencies and to take account of
any changes made so far in the merge window. If you have already pulled the
older version of the branch aimed at you, then please feel free to ignore this
request.
The following changes since commit 9e2d8656f5e8aa214e66b462680cf86b210b74a8:
Merge branch 'akpm' (Andrew's patch-bomb) (2012-10-09 16:23:15 +0900)
are available in the git repository at:
git://git.infradead.org/users/dhowells/linux-headers.git
tags/disintegrate-m68k-20121009
for you to fetch changes up to 10b3a979347d4aba7de19e8d33eb8b87fe2a11dd:
UAPI: (Scripted) Disintegrate arch/m68k/include/asm (2012-10-09 09:47:06
+0100)
UAPI Disintegration 2012-10-09
David Howells (1):
UAPI: (Scripted) Disintegrate arch/m68k/include/asm
arch/m68k/include/asm/Kbuild | 2 -
arch/m68k/include/asm/ptrace.h | 72 +
arch/m68k/include/asm/setup.h | 82 +-
arch/m68k/include/asm/signal.h | 118 +---
arch/m68k/include/asm/termios.h| 44 +--
arch/m68k/include/asm/unistd.h | 354 +---
arch/m68k/include/uapi/asm/Kbuild | 23 ++
arch/m68k/include/{ => uapi}/asm/a.out.h | 0
arch/m68k/include/{ => uapi}/asm/auxvec.h | 0
arch/m68k/include/{ => uapi}/asm/byteorder.h | 0
arch/m68k/include/{ => uapi}/asm/cachectl.h| 0
arch/m68k/include/{ => uapi}/asm/fcntl.h | 0
arch/m68k/include/{ => uapi}/asm/ioctls.h | 0
arch/m68k/include/{ => uapi}/asm/msgbuf.h | 0
arch/m68k/include/{ => uapi}/asm/param.h | 0
arch/m68k/include/{ => uapi}/asm/poll.h| 0
arch/m68k/include/{ => uapi}/asm/posix_types.h | 0
arch/m68k/include/uapi/asm/ptrace.h| 79 ++
arch/m68k/include/{ => uapi}/asm/sembuf.h | 0
arch/m68k/include/uapi/asm/setup.h | 103 +++
arch/m68k/include/{ => uapi}/asm/shmbuf.h | 0
arch/m68k/include/{ => uapi}/asm/sigcontext.h | 0
arch/m68k/include/uapi/asm/signal.h| 118
arch/m68k/include/{ => uapi}/asm/socket.h | 0
arch/m68k/include/{ => uapi}/asm/sockios.h | 0
arch/m68k/include/{ => uapi}/asm/stat.h| 0
arch/m68k/include/{ => uapi}/asm/swab.h| 0
arch/m68k/include/{ => uapi}/asm/termbits.h| 0
arch/m68k/include/uapi/asm/termios.h | 44 +++
arch/m68k/include/uapi/asm/unistd.h| 356 +
30 files changed, 728 insertions(+), 667 deletions(-)
rename arch/m68k/include/{ => uapi}/asm/a.out.h (100%)
rename arch/m68k/include/{ => uapi}/asm/auxvec.h (100%)
rename arch/m68k/include/{ => uapi}/asm/byteorder.h (100%)
rename arch/m68k/include/{ => uapi}/asm/cachectl.h (100%)
rename arch/m68k/include/{ => uapi}/asm/fcntl.h (100%)
rename arch/m68k/include/{ => uapi}/asm/ioctls.h (100%)
rename arch/m68k/include/{ => uapi}/asm/msgbuf.h (100%)
rename arch/m68k/include/{ => uapi}/asm/param.h (100%)
rename arch/m68k/include/{ => uapi}/asm/poll.h (100%)
rename arch/m68k/include/{ => uapi}/asm/posix_types.h (100%)
create mode 100644 arch/m68k/include/uapi/asm/ptrace.h
rename arch/m68k/include/{ => uapi}/asm/sembuf.h (100%)
create mode 100644 arch/m68k/include/uapi/asm/setup.h
rename arch/m68k/include/{ => uapi}/asm/shmbuf.h (100%)
rename arch/m68k/include/{ => uapi}/asm/sigcontext.h (100%)
create mode 100644 arch/m68k/include/uapi/asm/signal.h
rename arch/m68k/include/{ => uapi}/asm/socket.h (100%)
rename arch/m68k/include/{ => uapi}/asm/sockios.h (100%)
rename arch/m68k/include/{ => uapi}/asm/stat.h (100%)
rename arch/m68k/include/{ => uapi}/asm/swab.h (100%)
rename arch/m68k/include/{ => uapi}/asm/termbits.h (100%)
create mode 100644 arch/m68k/include/uapi/asm/termios.h
create mode 100644 arch/m68k/include/uapi/asm/unistd.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/
[GIT PULL] Disintegrate UAPI for ia64 [ver #2]
Can you merge the following branch into the ia64 tree please.
This is to complete part of the UAPI disintegration for which the preparatory
patches were pulled recently.
Now that the fixups and the asm-generic chunk have been merged, I've
regenerated the patches to get rid of those dependencies and to take account of
any changes made so far in the merge window. If you have already pulled the
older version of the branch aimed at you, then please feel free to ignore this
request.
The following changes since commit 9e2d8656f5e8aa214e66b462680cf86b210b74a8:
Merge branch 'akpm' (Andrew's patch-bomb) (2012-10-09 16:23:15 +0900)
are available in the git repository at:
git://git.infradead.org/users/dhowells/linux-headers.git
tags/disintegrate-ia64-20121009
for you to fetch changes up to 43e40f25d2c090392fc36cb900b42972e88cc2e2:
UAPI: (Scripted) Disintegrate arch/ia64/include/asm (2012-10-09 09:47:00
+0100)
UAPI Disintegration 2012-10-09
David Howells (1):
UAPI: (Scripted) Disintegrate arch/ia64/include/asm
arch/ia64/include/asm/Kbuild | 14 -
arch/ia64/include/asm/gcc_intrin.h | 615 +---
arch/ia64/include/asm/intrinsics.h | 120 +---
arch/ia64/include/asm/kvm_para.h | 10 +-
arch/ia64/include/asm/mman.h | 12 +-
arch/ia64/include/asm/param.h | 22 +-
arch/ia64/include/asm/perfmon.h| 171 +-
arch/ia64/include/asm/ptrace.h | 236 +---
arch/ia64/include/asm/siginfo.h| 118 +---
arch/ia64/include/asm/signal.h | 122 +---
arch/ia64/include/asm/termios.h| 46 +-
arch/ia64/include/asm/types.h | 19 +-
arch/ia64/include/asm/unistd.h | 324 +--
arch/ia64/include/asm/ustack.h | 11 +-
arch/ia64/include/uapi/asm/Kbuild | 45 ++
arch/ia64/include/{ => uapi}/asm/auxvec.h | 0
arch/ia64/include/{ => uapi}/asm/bitsperlong.h | 0
arch/ia64/include/{ => uapi}/asm/break.h | 0
arch/ia64/include/{ => uapi}/asm/byteorder.h | 0
arch/ia64/include/{ => uapi}/asm/cmpxchg.h | 0
arch/ia64/include/{ => uapi}/asm/errno.h | 0
arch/ia64/include/{ => uapi}/asm/fcntl.h | 0
arch/ia64/include/{ => uapi}/asm/fpu.h | 0
arch/ia64/include/uapi/asm/gcc_intrin.h| 618 +
arch/ia64/include/{ => uapi}/asm/ia64regs.h| 0
arch/ia64/include/{ => uapi}/asm/intel_intrin.h| 0
arch/ia64/include/uapi/asm/intrinsics.h| 124 +
arch/ia64/include/{ => uapi}/asm/ioctl.h | 0
arch/ia64/include/{ => uapi}/asm/ioctls.h | 0
arch/ia64/include/{ => uapi}/asm/ipcbuf.h | 0
arch/ia64/include/{ => uapi}/asm/kvm.h | 0
arch/ia64/include/uapi/asm/mman.h | 16 +
arch/ia64/include/{ => uapi}/asm/msgbuf.h | 0
arch/ia64/include/uapi/asm/param.h | 29 +
arch/ia64/include/uapi/asm/perfmon.h | 177 ++
.../include/{ => uapi}/asm/perfmon_default_smpl.h | 0
arch/ia64/include/{ => uapi}/asm/poll.h| 0
arch/ia64/include/{ => uapi}/asm/posix_types.h | 0
arch/ia64/include/uapi/asm/ptrace.h| 247
arch/ia64/include/{ => uapi}/asm/ptrace_offsets.h | 0
arch/ia64/include/{ => uapi}/asm/resource.h| 0
arch/ia64/include/{ => uapi}/asm/rse.h | 0
arch/ia64/include/{ => uapi}/asm/sembuf.h | 0
arch/ia64/include/{ => uapi}/asm/setup.h | 0
arch/ia64/include/{ => uapi}/asm/shmbuf.h | 0
arch/ia64/include/{ => uapi}/asm/sigcontext.h | 0
arch/ia64/include/uapi/asm/siginfo.h | 121
arch/ia64/include/uapi/asm/signal.h| 127 +
arch/ia64/include/{ => uapi}/asm/socket.h | 0
arch/ia64/include/{ => uapi}/asm/sockios.h | 0
arch/ia64/include/{ => uapi}/asm/stat.h| 0
arch/ia64/include/{ => uapi}/asm/statfs.h | 0
arch/ia64/include/{ => uapi}/asm/swab.h| 0
arch/ia64/include/{ => uapi}/asm/termbits.h| 0
arch/ia64/include/uapi/asm/termios.h | 50 ++
arch/ia64/include/uapi/asm/types.h | 31 ++
arch/ia64/include/{ => uapi}/asm/ucontext.h| 0
arch/ia64/include/uapi/asm/unistd.h| 328 +++
arch/ia64/include/uapi/asm/ustack.h| 12 +
59 files changed, 1961 insertions(+), 1804 deletions(-)
rename arch/ia64/include/{ => uapi}/asm/auxvec.h (100%)
rename arch/ia64/include/
[GIT PULL] Disintegrate UAPI for alpha [ver #2]
Can you merge the following branch into the alpha tree please.
This is to complete part of the UAPI disintegration for which the preparatory
patches were pulled recently.
Now that the fixups and the asm-generic chunk have been merged, I've
regenerated the patches to get rid of those dependencies and to take account of
any changes made so far in the merge window. If you have already pulled the
older version of the branch aimed at you, then please feel free to ignore this
request.
The following changes since commit 9e2d8656f5e8aa214e66b462680cf86b210b74a8:
Merge branch 'akpm' (Andrew's patch-bomb) (2012-10-09 16:23:15 +0900)
are available in the git repository at:
git://git.infradead.org/users/dhowells/linux-headers.git
tags/disintegrate-alpha-20121009
for you to fetch changes up to 55492254705f10d67f4225a0840156f856971519:
UAPI: (Scripted) Disintegrate arch/alpha/include/asm (2012-10-09 09:46:29
+0100)
UAPI Disintegration 2012-10-09
David Howells (1):
UAPI: (Scripted) Disintegrate arch/alpha/include/asm
arch/alpha/include/asm/Kbuild | 10 -
arch/alpha/include/asm/a.out.h | 89 +
arch/alpha/include/asm/compiler.h | 115 +-
arch/alpha/include/asm/console.h| 48 +--
arch/alpha/include/asm/fpu.h| 124 +--
arch/alpha/include/asm/pal.h| 50 +--
arch/alpha/include/asm/param.h | 20 +-
arch/alpha/include/asm/ptrace.h | 68 +---
arch/alpha/include/asm/signal.h | 135 +--
arch/alpha/include/asm/socket.h | 78 +---
arch/alpha/include/asm/termios.h| 68 +---
arch/alpha/include/asm/types.h | 13 +-
arch/alpha/include/asm/unistd.h | 469 +--
arch/alpha/include/uapi/asm/Kbuild | 40 ++
arch/alpha/include/uapi/asm/a.out.h | 91 +
arch/alpha/include/{ => uapi}/asm/auxvec.h | 0
arch/alpha/include/{ => uapi}/asm/bitsperlong.h | 0
arch/alpha/include/{ => uapi}/asm/byteorder.h | 0
arch/alpha/include/uapi/asm/compiler.h | 117 ++
arch/alpha/include/uapi/asm/console.h | 50 +++
arch/alpha/include/{ => uapi}/asm/errno.h | 0
arch/alpha/include/{ => uapi}/asm/fcntl.h | 0
arch/alpha/include/uapi/asm/fpu.h | 123 +++
arch/alpha/include/{ => uapi}/asm/gentrap.h | 0
arch/alpha/include/{ => uapi}/asm/ioctl.h | 0
arch/alpha/include/{ => uapi}/asm/ioctls.h | 0
arch/alpha/include/{ => uapi}/asm/ipcbuf.h | 0
arch/alpha/include/{ => uapi}/asm/kvm_para.h| 0
arch/alpha/include/{ => uapi}/asm/mman.h| 0
arch/alpha/include/{ => uapi}/asm/msgbuf.h | 0
arch/alpha/include/uapi/asm/pal.h | 52 +++
arch/alpha/include/uapi/asm/param.h | 21 ++
arch/alpha/include/{ => uapi}/asm/poll.h| 0
arch/alpha/include/{ => uapi}/asm/posix_types.h | 0
arch/alpha/include/uapi/asm/ptrace.h| 70
arch/alpha/include/{ => uapi}/asm/reg.h | 0
arch/alpha/include/{ => uapi}/asm/regdef.h | 0
arch/alpha/include/{ => uapi}/asm/resource.h| 0
arch/alpha/include/{ => uapi}/asm/sembuf.h | 0
arch/alpha/include/{ => uapi}/asm/setup.h | 0
arch/alpha/include/{ => uapi}/asm/shmbuf.h | 0
arch/alpha/include/{ => uapi}/asm/sigcontext.h | 0
arch/alpha/include/{ => uapi}/asm/siginfo.h | 0
arch/alpha/include/uapi/asm/signal.h| 135 +++
arch/alpha/include/uapi/asm/socket.h| 80
arch/alpha/include/{ => uapi}/asm/sockios.h | 0
arch/alpha/include/{ => uapi}/asm/stat.h| 0
arch/alpha/include/{ => uapi}/asm/statfs.h | 0
arch/alpha/include/{ => uapi}/asm/swab.h| 0
arch/alpha/include/{ => uapi}/asm/sysinfo.h | 0
arch/alpha/include/{ => uapi}/asm/termbits.h| 0
arch/alpha/include/uapi/asm/termios.h | 70
arch/alpha/include/uapi/asm/types.h | 16 +
arch/alpha/include/uapi/asm/unistd.h| 471
54 files changed, 1348 insertions(+), 1275 deletions(-)
create mode 100644 arch/alpha/include/uapi/asm/a.out.h
rename arch/alpha/include/{ => uapi}/asm/auxvec.h (100%)
rename arch/alpha/include/{ => uapi}/asm/bitsperlong.h (100%)
rename arch/alpha/include/{ => uapi}/asm/byteorder.h (100%)
create mode 100644 arch/alpha/include/uapi/asm/compiler.h
create mode 100644 arch/alpha/include/uapi/asm/console.h
rename arch/alpha/include/{ => uapi}/asm/errno.h (100%)
rename arch/alpha/include/{ => uapi}/asm/fcntl.h (100%)
create mode 100644 arch/alpha/include/uapi/asm/fpu.h
Re: [PATCH 2/2] i2c: busses: i2c-ocores: switch to devm_request_and_ioremap
Hi Peter, On Sun, Sep 23, 2012 at 2:22 PM, Peter Korsgaard wrote: >> "Maxin" == Maxin B John writes: > > Maxin> This drops a few lines of code and allows common APIs to handle > Maxin> those for us. > > Maxin> Signed-off-by: Maxin B. John > > Acked-by: Peter Korsgaard Is there any update on this ? > -- > Bye, Peter Korsgaard Best Regards, Maxin B. John -- 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 04/06] input/rmi4: Config files and makefiles
On Sat, Oct 6, 2012 at 6:10 AM, Christopher Heiny wrote: (...) > diff --git a/drivers/input/rmi4/Kconfig b/drivers/input/rmi4/Kconfig (...) > +config RMI4_DEBUG > + bool "RMI4 Debugging" > + depends on RMI4_BUS select DEBUG_FS This has been illustrated many times in the review. You definatley have code depending on debugfs when this is selected. Yours, Linus Walleij -- 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 0/2] Reset PCIe devices to address DMA problem on kdump with iommu
(2012/10/03 22:23), Don Dutile wrote: On 10/02/2012 03:49 AM, Takao Indoh wrote: These patches reset PCIe devices at boot time to address DMA problem on kdump with iommu. When "reset_devices" is specified, a hot reset is triggered on each PCIe root port and downstream port to reset its downstream endpoint. Background: A kdump problem about DMA has been discussed for a long time. That is, when a kernel is switched to the kdump kernel DMA derived from first kernel affects second kernel. Recently this problem surfaces when iommu is used for PCI passthrough on KVM guest. In the case of the machine I use, when intel_iommu=on is specified, DMAR error is detected in kdump kernel and PCI SERR is also detected. Finally kdump fails because some devices does not work correctly. The root cause is that ongoing DMA from first kernel causes DMAR fault because page table of DMAR is initialized while kdump kernel is booting up. Therefore to address this problem DMA needs to be stopped before DMAR is initialized at kdump kernel boot time. By these patches, PCIe devices are reset by hot reset and its DMA is stopped when reset_devices is specified. One problem of this solution is that the monitor blacks out when VGA controller is reset. So this patch does not reset the port whose child endpoint is VGA device. v2: Reset devices in setup_arch() because reset need to be done before interrupt remapping is initialized. v1: https://lkml.org/lkml/2012/8/3/160 Thanks, Takao Indoh -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Maybe you've tried the following, and I missed a thread on it, but instead of a somewhat-large, reset hammer, did any one try just reading all the endpoint-only device CMD register, flip the MasterEnable bit off, and write it back? that would stop all DMA (should stop all MSI writes as well since they are just another DMA), and then restart the system? May also have to do PCI INT Disable as well... and note, that's a PCI 2.3 optional feature so devices using INT signalling vs MSI is just borked on IOMMU/intr-remapping systems... which I would expect are few. Then again, if this is foolishly done, then reset legacy PCI busses as the fallback. Just clearing bus master bit and INTx disable bit in setup_arch() did not solve this problem. I still got DMAR error on devices(for exmaple, igb and megaraid_sas). Clearing bus master in setup_arch() and resetting devices in fixup_final like v1 patch is better, DMAR error was not detected. But on certain machine kdump kernel hung up when resetting devices. It seems to be a problem specific to the platform. And, resetting devices in setup_arch() like v2 patch solves all problems I found so far. Thanks, Takao Indoh -- 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 11/11] net: xilinx: Show csum in bootlog
On 10/05/2012 03:51 PM, Ben Hutchings wrote:
On Fri, 2012-10-05 at 11:35 +0200, Michal Simek wrote:
On 10/04/2012 09:15 PM, Ben Hutchings wrote:
On Thu, 2012-10-04 at 20:14 +0200, Michal Simek wrote:
Just show current setting in bootlog.
[...]
--- a/drivers/net/ethernet/xilinx/ll_temac_main.c
+++ b/drivers/net/ethernet/xilinx/ll_temac_main.c
@@ -1052,12 +1052,14 @@ static int __devinit temac_of_probe(struct
platform_device *op)
/* Setup checksum offload, but default to off if not specified */
lp->temac_features = 0;
p = (__be32 *)of_get_property(op->dev.of_node, "xlnx,txcsum", NULL);
+ dev_info(>dev, "TX_CSUM %d\n", be32_to_cpup(p));
if (p && be32_to_cpu(*p)) {
lp->temac_features |= TEMAC_FEATURE_TX_CSUM;
/* Can checksum TCP/UDP over IPv4. */
ndev->features |= NETIF_F_IP_CSUM;
}
p = (__be32 *)of_get_property(op->dev.of_node, "xlnx,rxcsum", NULL);
+ dev_info(>dev, "RX_CSUM %d\n", be32_to_cpup(p));
[...]
Is there any particular reason you think this needs to be logged by
default, rather than letting users run ethtool -k? I suggest using
dev_dbg() instead.
Ok. I have looked at it and there are missing some bits in ndev->features.
Can you please check that my setting is correct?
It is SG DMA ip/driver.
ndev->features = NETIF_F_FRAGLIST | NETIF_F_SG
NETIF_F_SG only; NETIF_F_FRAGLIST means you can handle skbs chained
through the frag_list pointer.
The driver is able to handle skb fragments too. temac_start_xmit
With two options for csum on RX/TX. They can be selected independently.
tx Partial csum over IPv4. -> NETIF_F_IP_CSUM
tx Full csum. -> NETIF_F_HW_CSUM
NETIF_F_IP_CSUM means you have hardware checksum generation for TCP/IPv4
and UDP/IPv4 only (XAE_FEATURE_FULL_TX_CSUM).
NETIF_F_HW_CSUM means you have generic TCP-style checksum generation
using the csum_start and csum_offset fields of the skb
(XAE_FEATURE_PARTIAL_TX_CSUM). By the way, you're actually testing
XAE_FEATURE_PARTIAL_RX_CSUM in axienet_start_xmit()...
We have used non mainline ll_temac driver for a long time but we will
move to this mainline version soon. It is on my todo list to clean this
driver and test all these options.
Also performance tests will be necessary to do.
rx Full csum -> NETIF_F_RXCSUM
Is there any option to support partial csum?
There is no need to differentiate these in the device features. For TX
the stack needs to know whether to use a software fallback before
passing the skb to you, but on RX it looks at the ip_summed field of
each skb you pass up.
Hardware can be setup asymmetrically. It means enable CSUM only on RX or TX.
All combination are valid.
The point here is if Linux is not able to handle this then we have to
create logic in the driver to support these options too.
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
--
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 03/06] input/rmi4: I2C physical interface
On Sat, Oct 6, 2012 at 6:10 AM, Christopher Heiny wrote:
> The I2C physical driver is not extensively changed in terms of functionality
> since the previous patch. Management of the attention GPIO has been moved to
> rmi_driver.c (see previous email), and most of the debug related interfaces
> have been moved from sysfs to debugfs. Control of the debug features has been
> moved from compile-time to runtime switches available via debugfs.
>
> The core I2C functionality was previously ACKed by Jean Delvare. I don't
> believe that portion of the code has changed much since then, but we'd
> appreciate a second glance at this.
The above commit blurb looks more like a changelog than a description
of the actual patch. Nothing wrong with that but begin by describing
the patch first.
(...)
> +#ifdef CONFIG_RMI4_DEBUG
> +
> +#include
> +#include
Just move these up to the common includes. It doesn't matter
that they get included even when debug is not enabled.
> +static int setup_debugfs(struct rmi_device *rmi_dev, struct rmi_i2c_data
> *data);
> +static void teardown_debugfs(struct rmi_i2c_data *data);
Why do you need to forward-declare these? Can't you just move them
up above the functions using them?
> +struct i2c_debugfs_data {
> + bool done;
Done with what? ... needs some doc.
> + struct rmi_i2c_data *i2c_data;
> +};
(...)
> +static int __devinit rmi_i2c_probe(struct i2c_client *client,
> + const struct i2c_device_id *id)
(...)
> + rmi_phys = kzalloc(sizeof(struct rmi_phys_device), GFP_KERNEL);
(...)
> + data = kzalloc(sizeof(struct rmi_i2c_data), GFP_KERNEL);
Can you use devm_kzalloc(>dev, ...) for these so you don't
need to free() them explicitly?
(...)
> +static int __devexit rmi_i2c_remove(struct i2c_client *client)
> +{
> + struct rmi_phys_device *phys = i2c_get_clientdata(client);
> + struct rmi_device_platform_data *pd = client->dev.platform_data;
> +
> + /* Can I remove this disable_device */
> + /*disable_device(phys); */
So just delete these two lines then?
Yours,
Linus Walleij
--
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/
[PULL REQUEST] i2c-embedded for 3.7
Hi Linus,
please pull the changes for i2c-embedded for the 3.7 kernel. They include:
- massive rework of the omap driver
- massive rework of the at91 driver. In fact, the old driver gets removed; I am
okay with this approach since the old driver was depending on BROKEN
and its limitations made it practically unusable, so people used bitbanging
instead. But even if there are users, there is no platform_data or module
parameter which would need to be converted. It is just another driver doing
I2C transfers, just way better. Modifications of arch/arm/at91 related files
have proper acks from the maintainer.
- new driver for R-Car I2C
- devicetree and generic_clock conversions and fixes
- ususal driver fixes and changes.
The rework patches have come a long way and lots of people have been involved
in creating/testing them. Most patches have been in linux-next at least since
3.6-rc5. A few have been added in the last week, I have to admit. An unexpected
(but welcome :)) peak in private life is the cause for that. The "late" patches
shouldn't cause any merge conflicts and I will have a special eye on them
during the stabilization phase. This is an exception and I want to have the
patches in place properly in time again for the next kernels. So, please pull.
Regards,
Wolfram
The following changes since commit 979570e02981d4a8fc20b3cc8fd651856c98ee9d:
Linux 3.6-rc7 (2012-09-23 18:10:57 -0700)
are available in the git repository at:
git://git.pengutronix.de/git/wsa/linux.git i2c-embedded/for-next
for you to fetch changes up to 62885f59a26195d9f6a3f8c795225dfbab62a110:
MXS: Implement DMA support into mxs-i2c (2012-10-08 12:47:33 +0200)
Fabio Estevam (2):
i2c: imx: Use dev_info to indicate that i2c driver was succesfully
registered
i2c: imx: Use dev_dbg logging style
Felipe Balbi (21):
i2c: omap: switch to devm_* API
i2c: omap: simplify num_bytes handling
i2c: omap: decrease indentation level on data handling
i2c: omap: add blank lines
i2c: omap: simplify omap_i2c_ack_stat()
i2c: omap: split out [XR]DR and [XR]RDY
i2c: omap: improve i462 errata handling
i2c: omap: re-factor receive/transmit data loop
i2c: omap: switch over to do {} while loop
i2c: omap: ack IRQ in parts
i2c: omap: switch to platform_get_irq()
i2c: omap: bus: add a receiver flag
i2c: omap: simplify errata check
i2c: omap: always return IRQ_HANDLED
i2c: omap: simplify IRQ exit path
i2c: omap: resize fifos before each message
i2c: omap: get rid of the "complete" label
i2c: omap: switch to threaded IRQ support
i2c: omap: remove unnecessary pm_runtime_suspended check
i2c: omap: switch over to autosuspend API
i2c: omap: sanitize exit path
Florian Vaussard (1):
omap-i2c: fix incorrect log message when using a device tree
Heiko Schocher (1):
i2c: davinci: add OF support
Jean Pihet (1):
ARM: OMAP: convert I2C driver to PM QoS for MPU latency constraints
Joakim Tjernlund (1):
i2c: mpc: Wait for STOP to hit the bus
Kuninori Morimoto (1):
i2c: add Renesas R-Car I2C driver
Lee Jones (1):
i2c: nomadik: Add Device Tree support to the Nomadik I2C driver
Linus Walleij (1):
i2c: nomadik: stop fetching the regulator
Ludovic Desroches (5):
ARM: at91: do not configure at91sam9g10 twi pio as open-drain
i2c: at91: add dt support to i2c-at91
ARM: at91: add clocks for I2C DT entries
ARM: dts: add twi nodes for atmel SoCs
ARM: dts: add twi nodes for atmel boards
Marek Vasut (1):
MXS: Implement DMA support into mxs-i2c
Murali Karicheri (1):
i2c: davinci: preparation for switch to common clock framework
Nikolaus Voss (4):
Replace clk_lookup.con_id with clk_lookup.dev_id entries for twi clk
i2c: at91: remove old polling driver
i2c: at91: add new driver
arm: at91: G45 TWI: remove open drain setting for twi function gpios
Shubhrajyoti D (1):
i2c: omap: remove redundant status read
Thomas Abraham (1):
i2c: s3c2410: use clk_prepare_enable and clk_disable_unprepare
Thomas Kavanagh (1):
i2c: algo: pca: Fix chip reset function for PCA9665
Wolfram Sang (1):
Merge tag 'v3.6-rc7' into i2c-embedded/for-next
.../devicetree/bindings/i2c/atmel-i2c.txt | 30 +
Documentation/devicetree/bindings/i2c/davinci.txt | 28 +
Documentation/devicetree/bindings/i2c/i2c-mxs.txt |2 +
Documentation/devicetree/bindings/i2c/nomadik.txt | 23 +
arch/arm/boot/dts/at91sam9260.dtsi | 10 +
arch/arm/boot/dts/at91sam9263.dtsi | 10 +
arch/arm/boot/dts/at91sam9g20.dtsi |4 +
arch/arm/boot/dts/at91sam9g25ek.dts| 12 +
arch/arm/boot/dts/at91sam9g45.dtsi | 20 +
arch/arm/boot/dts/at91sam9m10g45ek.dts |8 +
Re: [PATCH 1/2] ARM: OMAP: Trivial driver changes to remove include plat/cpu.h
On 10/08/2012 07:35 PM, Tony Lindgren wrote: > - omap-dma.c and omap-pcm.c can test the arch locally as > omap1 and omap2 cannot be compiled together because of > conflicting compiler flags > sound/soc/omap/omap-pcm.c |9 +++-- Tony: is this going to be included in 3.7? Acked-by: Peter Ujfalusi -- 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] ARM: OMAP2+: gpmc: Fix kernel BUG for DT boot mode
With recent changes in omap gpmc driver code, in case of DT
boot mode, where bootloader does not configure gpmc cs space
will result into kernel BUG() inside gpmc_mem_init() function,
as gpmc cs0 gpmc_config7[0].csvalid bit is set to '1' and
gpmc_config7[0].baseaddress is set to '0' on reset.
This use-case is applicable for any board/EVM which doesn't have
any peripheral connected to gpmc cs0, for example BeagleXM and
BeagleBone, so DT boot mode fails.
This patch adds of_have_populated_dt() check before creating
device, so that for DT boot mode, gpmc probe will not be called
which is expected behavior, as gpmc is not supported yet from DT.
Signed-off-by: Vaibhav Hiremath
Cc: Afzal Mohammed
Cc: Tony Lindgren
Cc Paul Walmsley
---
This should go in for rc1, as this breaks AM33xx boot.
arch/arm/mach-omap2/gpmc.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 8ab1e1b..c68f9e1 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -981,6 +981,10 @@ static int __init omap_gpmc_init(void)
struct platform_device *pdev;
char *oh_name = "gpmc";
+ /* If dtb is there, the devices will be created dynamically */
+ if (of_have_populated_dt())
+ return -ENODEV;
+
oh = omap_hwmod_lookup(oh_name);
if (!oh) {
pr_err("Could not look up %s\n", oh_name);
--
1.7.0.4
--
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 resend] net, bluetooth: don't attempt to free a channel that wasn't created
Hi Sasha,
* Sasha Levin [2012-10-08 16:48:32 -0400]:
> We may currently attempt to free a channel which wasn't created due to
> an error in the initialization path, this would cause a NULL ptr deref.
>
> This would cause the following oops:
>
> [ 12.919073] BUG: unable to handle kernel NULL pointer dereference at
> 0010
> [ 12.919131] IP: [] l2cap_chan_put+0x34/0x50
> [ 12.919135] PGD 0
> [ 12.919138] Oops: 0002 [#1] PREEMPT SMP DEBUG_PAGEALLOC
> [ 12.919193] Dumping ftrace buffer:
> [ 12.919242](ftrace buffer empty)
> [ 12.919314] Modules linked in:
> [ 12.919318] CPU 1
> [ 12.919319] Pid: 6210, comm: krfcommd Tainted: GW
> 3.6.0-next-20121004-sasha-5-gb010653-dirty #30
> [ 12.919374] RIP: 0010:[] []
> l2cap_chan_put+0x34/0x50
> [ 12.919377] RSP: :880066933c38 EFLAGS: 00010246
> [ 12.919378] RAX: 8366c780 RBX: RCX:
> 6667
> [ 12.919379] RDX: 0fa0 RSI: 84d3f79e RDI:
> 0010
> [ 12.919381] RBP: 880066933c48 R08: 859989f8 R09:
> 0001
> [ 12.919382] R10: R11: 7fff R12:
>
> [ 12.919383] R13: 88009b00a200 R14: 88009b00a200 R15:
> 0001
> [ 12.919385] FS: () GS:88003360()
> knlGS:
> [ 12.919437] CS: 0010 DS: ES: CR0: 80050033
> [ 12.919440] CR2: 0010 CR3: 05026000 CR4:
> 000406e0
> [ 12.919446] DR0: DR1: DR2:
>
> [ 12.919451] DR3: DR6: 0ff0 DR7:
> 0400
> [ 12.919504] Process krfcommd (pid: 6210, threadinfo 880066932000, task
> 880065c4b000)
> [ 12.919506] Stack:
> [ 12.919510] 88009b00a200 880032084000 880066933c68
> 8366c7bc
> [ 12.919513] 7fff 880032084000 880066933c98
> 833ae0ae
> [ 12.919516] 880066933ca8
> 88009b00a200
> [ 12.919517] Call Trace:
> [ 12.919522] [] l2cap_sock_destruct+0x3c/0x80
> [ 12.919527] [] __sk_free+0x1e/0x1f0
> [ 12.919530] [] sk_free+0x17/0x20
> [ 12.919585] [] l2cap_sock_alloc.constprop.5+0x9e/0xd0
> [ 12.919591] [] l2cap_sock_create+0x7e/0x100
> [ 12.919652] [] ? _raw_read_lock+0x6a/0x80
> [ 12.919658] [] ? bt_sock_create+0x74/0x110
> [ 12.919660] [] bt_sock_create+0xb8/0x110
> [ 12.919664] [] __sock_create+0x282/0x3b0
> [ 12.919720] [] ? __sock_create+0x100/0x3b0
> [ 12.919725] [] ? rfcomm_process_sessions+0x17e0/0x17e0
> [ 12.919779] [] sock_create_kern+0x1f/0x30
> [ 12.919784] [] rfcomm_l2sock_create+0x44/0x70
> [ 12.919787] [] ? rfcomm_process_sessions+0x17e0/0x17e0
> [ 12.919790] [] rfcomm_run+0x4e/0x1f0
> [ 12.919846] [] ? rfcomm_process_sessions+0x17e0/0x17e0
> [ 12.919852] [] kthread+0xe3/0xf0
> [ 12.919908] [] ? put_lock_stats.isra.14+0xe/0x40
> [ 12.919914] [] ? flush_kthread_work+0x1f0/0x1f0
> [ 12.919968] [] ret_from_fork+0x7c/0x90
> [ 12.919973] [] ? flush_kthread_work+0x1f0/0x1f0
> [ 12.920161] Code: 83 ec 08 f6 05 ff 58 44 02 04 74 1b 8b 4f 10 48 89 fa 48
> c7 c6 d9 d7 d4 84 48 c7 c7 80 9e aa 85 31 c0 e8 80
> ac 3a fe 48 8d 7b 10 83 6b 10 01 0f 94 c0 84 c0 74 05 e8 8b e0 ff ff 48
> 83 c4 08
> [ 12.920165] RIP [] l2cap_chan_put+0x34/0x50
> [ 12.920166] RSP
> [ 12.920167] CR2: 0010
> [ 12.920417] ---[ end trace 5a9114e8a158ab84 ]---
>
> Introduced in commit 61d6ef3e ("Bluetooth: Make better use of l2cap_chan
> reference counting").
>
> Signed-off-by: Sasha Levin
> ---
> net/bluetooth/l2cap_sock.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
Patch has been applied to bluetooth-next. Thanks.
Gustavo
--
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 RESEND] x86/fixup_irq: Clean the offlining CPU from the irq affinity mask
One suggestion below, thanks.
> -Original Message-
> From: Siddha, Suresh B
> Sent: Thursday, September 27, 2012 6:46 AM
> To: Srivatsa S. Bhat
> Cc: Liu, Chuansheng; t...@linutronix.de; mi...@redhat.com; x...@kernel.org;
> linux-kernel@vger.kernel.org; yanmin_zh...@linux.intel.com; Paul E.
> McKenney; Peter Zijlstra; ru...@rustcorp.com.au
> Subject: Re: [PATCH RESEND] x86/fixup_irq: Clean the offlining CPU from the
> irq
> affinity mask
>
> On Wed, 2012-09-26 at 23:00 +0530, Srivatsa S. Bhat wrote:
> > On 09/26/2012 10:36 PM, Suresh Siddha wrote:
> > > On Wed, 2012-09-26 at 21:33 +0530, Srivatsa S. Bhat wrote:
> > >> I have some fundamental questions here:
> > >> 1. Why was the CPU never removed from the affinity masks in the original
> > >> code? I find it hard to believe that it was just an oversight, because
> > >> the
> > >> whole point of fixup_irqs() is to affine the interrupts to other CPUs,
> > >> IIUC.
> > >> So, is that really a bug or is the existing code correct for some reason
> > >> which I don't know of?
> > >
> > > I am not aware of the history but my guess is that the affinity mask
> > > which is coming from the user-space wants to be preserved. And
> > > fixup_irqs() is fixing the underlying interrupt routing when the cpu
> > > goes down
> >
> > and the code that corresponds to that is:
> > irq_force_complete_move(irq); is it?
>
> No. irq_set_affinity()
>
> > > with a hope that things will be corrected when the cpu comes
> > > back online. But as Liu noted, we are not correcting the underlying
> > > routing when the cpu comes back online. I think we should fix that
> > > rather than modifying the user-specified affinity.
> > >
> >
> > Hmm, I didn't entirely get your suggestion. Are you saying that we should
> change
> > data->affinity (by calling ->irq_set_affinity()) during offline but
> > maintain a
> > copy of the original affinity mask somewhere, so that we can try to match it
> > when possible (ie., when CPU comes back online)?
>
> Don't change the data->affinity in the fixup_irqs() and shortly after a
> cpu is online, call irq_chip's irq_set_affinity() for those irq's who
> affinity included this cpu (now that the cpu is back online,
> irq_set_affinity() will setup the HW routing tables correctly).
>
> This presumes that across the suspend/resume, cpu offline/online
> operations, we don't want to break the irq affinity setup by the
> user-level entity like irqbalance etc...
>
In fixup_irqs(), could we untouch the data->affinity, but calling
->irq_set_affinity() without offlined CPU.
If so, the better affinity is set, and user-space can use the data->affinity
correctly, also new affinity setting
will and online cpus.
> > > That happens only if the irq chip doesn't have the irq_set_affinity()
> > > setup.
> >
> > That is my other point of concern : setting irq affinity can fail even if
> > we have ->irq_set_affinity(). (If __ioapic_set_affinity() fails, for
> > example).
> > Why don't we complain in that case? I think we should... and if its serious
> > enough, abort the hotplug operation or atleast indicate that offline
> > failed..
>
> yes if there is a failure then we are in trouble, as the cpu is already
> disappeared from the online-masks etc. For platforms with
> interrupt-remapping, interrupts can be migrated from the process context
> and as such this all can be done much before.
>
> And for legacy platforms we have done quite a few changes in the recent
> past like using eoi_ioapic_irq() for level triggered interrupts etc,
> that makes it as safe as it can be. Perhaps we can move most of the
> fixup_irqs() code much ahead and the lost section of the current
> fixup_irqs() (which check IRR bits and use the retrigger function to
> trigger the interrupt on another cpu) can still be done late just like
> now.
>
> thanks,
> suresh
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
