Re: [PATCH 2/4] pinmux: Add TB10x pinmux driver
On 07/16/2013 02:47 AM, Christian Ruppert wrote:
> On Wed, Jul 10, 2013 at 01:27:52PM -0600, Stephen Warren wrote:
>> On 07/08/2013 07:02 AM, Christian Ruppert wrote:
>> ...
>>> OK, a small drawing of our hardware should make this clear, let's take
>>> an imaginary example of one port with 10 pins, one i2c interface, one
>>> spi interface and one GPIO bank:
>>>
>>> | mux N-1|
>>> ++
>>> || 2
>>> |+--/-- i2c
>>> ||
>>>10 || 4
>>>Pins --/--+ mux N +--/-- spi
>>> ||
>>> || 10
>>> |+--/-- GPIO
>>> ||
>>> ++
>>> | mux N+1|
>>>
>>> This example shows the mux N inside the pin controller. It controls
>>> all pins associated to port N through a single register value M. Let's
>>> assume the pins are configured as follows in function of the register
>>> value:
>>>
>>> pin M=0 M=1 M=2 M=3
>>> 0 GPIO0 SPI_MISO GPIO0 SPI_MISO
>>> 1 GPIO1 SPI_MOSI GPIO1 SPI_MOSI
>>> 2 GPIO2SPI_CK GPIO2SPI_CK
>>> 3 GPIO3SPI_CS GPIO3SPI_CS
>>> 4 GPIO4GPIO4GPIO4GPIO4
>>> 5 GPIO5GPIO5GPIO5GPIO5
>>> 6 GPIO6GPIO6GPIO6GPIO6
>>> 7 GPIO7GPIO7GPIO7GPIO7
>>> 8 GPIO8GPIO8 I2C_SDA I2C_SDA
>>> 9 GPIO9GPIO9 I2C_SCL I2C_SCL
>>
>>
>> In that scenario, in the language of Linux's pinctrl subsystem, what you
>> have is:
>>
>> 10 pins, named 0..9
>> 1 pin group, named perhaps "mux N".
>> 4 different functions; values M==0, 1, 2, 3.
>>
>>> We now have three pin groups defined, corresponding to the chip-side
>>> ports of the pin controller:
>>> GPIO = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9}
>>> SPI = {0, 1, 2, 3}
>>> I2C = {8, 9}
>>
>> You would usually only define pin groups for the pin/ball/package side
>> of the pinmux HW. IIRC, you're also wanting to define pin groups for the
>> intra-chip side of the pinmux HW. However, you're not muxing functions
>> onto those pingroups; they're just there to help with naming the
>> GPIO<->pinmux mapping. You only mux functions onto the pin/ball/package
>> side pins/pingroups.
>
> Well, the GPIO<->pinmux mapping is not the only reason for defining
> these groups wrt. the chip-side of the pin controller. The other reasons
> are:
> - Make different interfaces on the same MUX orthogonal wrt. each
> other, i.e. make it possible to request one independently of the
> other. In the example above, SPI and I2C can be requested completely
> independently and the pin controller driver decides which mode to
> use.
But the pinctrl subsystem and bindings don't have any concept of that;
what gets requested is the pins on the chip, or the "outer" side of the
pin controller. There's no concept of resource management for the
"inside" of the pin controller.
> - Make pin allocation more fine-grained (in the example above, only
> pins 0-4 are "allocated" in case SPI is requested). This makes
> GPIO<->interface pin conflict management more natural.
I think you'd want to either:
a) Just deal with this in the driver; it knows the HW, and it knows
which mux function is selected for each mux, and hence knows exactly
which pins can be requested as GPIOs for each combination, and can
therefore allow/disallow any GPIO request or mux function change.
b) Extend the pinctrl core to know about this explicitly, and pass
information to the pinctrl core. Presumably, for each combination of
(pingroup, mux function), you'd need a list or bitmask indicating which
pins within the pingroup are actually used. Then, the pinctrl core can
perform all the validation. If you do this, you don't need to invent new
pinctrl groups in order to try and shoe-horn this into pinctrl.
--
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: [alsa-devel] [BUG] 3.10.[01] modprobe snd-... hangs
On Tue, Jul 16, 2013 at 5:28 AM, Philipp Hahn wrote:
> Hello,
>
> Am Dienstag 16 Juli 2013, 08:43:36 schrieb Takashi Iwai:
>> At Tue, 16 Jul 2013 15:11:51 +0930, Rusty Russell wrote:
>> > Philipp Matthias Hahn writes:
>> > > My x86_64 systems has some trouble loading some ALSA snd-* modules since
>> > > the upgrade to 3.10.[01]: Several automatic modprobe calls hang, but
>> > > loading snd-intel-hda and snd-audio-usb by hand still works.
>> >
>> > Not a known problem to me, at least. Perhaps it's a dep loop somehow.
>>
>> I remember that someone reported it being Debian specific snd-seq-oss
>> loading stuff.
>
> FYI: "oss-compat" is installed.
>
>> > > ...
>> > > 1071 ?S 0:00 sh -c /sbin/modprobe --ignore-install snd &&
>> > > { /sbin/modprobe --quiet snd
>> > > 1080 ?D 0:00 \_ /sbin/modprobe --quiet snd-seq
>> >
>> > This was first, and it's waiting. Which means it must be doing
>> > something weird, because snd_seq_oss is loading now:
>> >
>> > > snd_seq_oss 33717 1 - Loading 0xa041b000
>> >
>> > Perhaps in the tangle of modprobe install commands somewhere this gets
>> > invoked?
>>
>> Likely, but I wonder what triggered a bug suddenly on 3.10.
>> There is absolutely no change in sound/core/seq/*, and through a quick
>> look, I couldn't find any suspicious change in kernel/module.c that
>> may lead to this problem between 3.9 and 3.10.
>>
>> Philipp, can you get a sysrq-T trace while the stall?
>
> I've finally been able to reducte the number of processes to get a full
> trace; see attached file.
>
> Please note that in this case the proprietary "nvidia" module was loaded,
> since I currently onyl have remove access to the machine.
> The original trace from yesterday happend without the nvidia module ever
> being loaded.
>
> Am Dienstag 16 Juli 2013, 08:42:35 schrieb Lucas De Marchi:
>> On Tue, Jul 16, 2013 at 2:41 AM, Rusty Russell wrote:
>> First thing to check is the /etc/modprobe.d/*.conf file that contains
>> these install commands. Did they change besides the kernel upgrade?
>
> Not that I know of: Booting 3.9.9 works fine, 3.10.x shows the problem.
Then one possible explanation is that in 3.9.9 you don't have some of
the modules causing this problem
>
> ...
>> Philipp, which kernel are you upgrading from?
> I just upgraded from 3.9.9 to 3.10.0; also tried 3.10.1 which did not improve
> the situation.
>
>> I don't see anything to
>> blame in the changes for the past releases. Any chance a bad entry in
>> your .conf was added too? You may want to paste the output of modprobe
>> -c, at least until "# End of configuration files. Dumping indexes
>> now:"
>
> blacklist snd_pcsp
> blacklist arkfb
> blacklist aty128fb
> blacklist atyfb
> blacklist radeonfb
> blacklist cirrusfb
> blacklist cyber2000fb
> blacklist gx1fb
> blacklist gxfb
> blacklist kyrofb
> blacklist matroxfb_base
> blacklist mb862xxfb
> blacklist neofb
> blacklist nvidiafb
> blacklist pm2fb
> blacklist pm3fb
> blacklist s3fb
> blacklist savagefb
> blacklist sisfb
> blacklist tdfxfb
> blacklist tridentfb
> blacklist viafb
> blacklist vt8623fb
> blacklist garmin_gps
> blacklist nouveau
> install binfmt_ /bin/true
> install sound_slot_0 /sbin/modprobe snd-card-0
> install sound_slot_1 /sbin/modprobe snd-card-1
> install sound_slot_2 /sbin/modprobe snd-card-2
> install sound_slot_3 /sbin/modprobe snd-card-3
> install sound_slot_4 /sbin/modprobe snd-card-4
> install sound_slot_5 /sbin/modprobe snd-card-5
> install sound_slot_6 /sbin/modprobe snd-card-6
> install sound_slot_7 /sbin/modprobe snd-card-7
> install snd /sbin/modprobe --ignore-install snd && { /sbin/modprobe --quiet
> snd-ioctl32 ; /sbin/modprobe --quiet snd-seq ; : ; }
> install snd_rawmidi /sbin/modprobe --ignore-install snd-rawmidi && {
> /sbin/modprobe --quiet snd-seq-midi ; : ; }
> install snd_emu10k1 /sbin/modprobe --ignore-install snd-emu10k1 && {
> /sbin/modprobe --quiet snd-emu10k1-synth ; : ; }
> alias net_pf_16_proto_1 wire
> alias net_pf_16_proto_3 ip_queue
> alias net_pf_16_proto_8 scsi_transport_iscsi
> alias net_pf_16_proto_9 audit
> alias net_pf_16_proto_11 cn
> alias net_pf_16_proto_13 ip6_queue
> alias binfmt_204 binfmt_aout
> alias binfmt_263 binfmt_aout
> alias binfmt_264 binfmt_aout
> alias binfmt_267 binfmt_aout
> alias binfmt_387 binfmt_aout
> alias block_major_3_* ide_generic
> alias block_major_22_* ide_generic
> alias block_major_33_* ide_generic
> alias block_major_34_* ide_generic
> alias block_major_37_* ide_tape
> alias block_major_44_* ftl
> alias block_major_46_* pcd
> alias block_major_47_* pf
> alias block_major_56_* ide_generic
> alias block_major_57_* ide_generic
> alias block_major_58_* lvm_mod
> alias block_major_88_* ide_generic
> alias block_major_89_* ide_generic
> alias block_major_90_* ide_generic
> alias block_major_91_* ide_generic
> alias block_major_93_* nftl
> alias block_major_97_* pg
> alias char_major_10_1 psmouse
> alias char_major_10_139 openprom
> alias char_major_10_157 appl
Re: [QUERY] User-Mode Linux and /dev/tty*
Am 16.07.2013 18:03, schrieb Ramkumar Ramachandra: > Richard Weinberger wrote: >> UML does not have CONFIG_VT. > > Not sure what this means. UML does not have virtual consoles. >> But recent systemd versions can deal with that. > > Nope, running systemd HEAD. I only recently figured out how to detect > that um Linux is running [1]. > > [1]: https://github.com/systemd/systemd/commit/7080ea16 > I'm not running HEAD, but opensuse 12.3 (with systemd) works on UML. Thanks, //richard -- 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 5/5] iio: add configuration option for debug support
Lars-Peter Clausen wrote: >On 07/16/2013 02:01 PM, Otavio Salvador wrote: >> On Tue, Jul 16, 2013 at 7:26 AM, Lars-Peter Clausen >wrote: >>> On 07/16/2013 11:58 AM, Jonathan Cameron wrote: On 07/15/2013 03:22 PM, Otavio Salvador wrote: > Signed-off-by: Otavio Salvador seems a sensible facility to have available. Applied to the togreg branch of iio.git >>> >>> Can you update the Kconfig help text? >> >> Sure I can. Jonathan seem to have applied it so should I send a v2 or >> a new patch? >> > >He hasn't pushed things out yet, I think a v2 will be fine. > Yup a v2 is fine. Actually I regularly rebase this tree and it may eat babies! All work more or less should be against Greg's staging/staging-next tree as that is nice and non debasing. > --- > drivers/iio/Kconfig | 7 +++ > drivers/iio/Makefile | 2 ++ > 2 files changed, 9 insertions(+) > > diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig > index 9af763a..d1f06f2 100644 > --- a/drivers/iio/Kconfig > +++ b/drivers/iio/Kconfig > @@ -12,6 +12,13 @@ menuconfig IIO > > if IIO > > +config IIO_DEBUG > +boolean "Debug support for Industrial I/O" > +depends on DEBUG_KERNEL > +help > + Say "yes" to enable debug messaging (like dev_dbg and >pr_debug), > + sysfs, and debugfs support in Industrial I/O subsystem and >drivers. >>> >>> This has nothing to do with either sysfs or debugfs support. >> >> Say "yes" to enable debug messaging (like dev_dbg and pr_debug) >> support in Industrial I/O subsystem and drivers. >> >> ? >> >> -- >> Otavio Salvador O.S. Systems >> http://www.ossystems.com.brhttp://projetos.ossystems.com.br >> Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 >> > >-- >To unsubscribe from this list: send the line "unsubscribe linux-iio" in >the body of a message to majord...@vger.kernel.org >More majordomo info at http://vger.kernel.org/majordomo-info.html -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- 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] nohz: Do not warn about unstable tsc unless user uses nohz_full
On Tue, Jul 16, 2013 at 10:22:12AM -0400, Steven Rostedt wrote: > If the user enables CONFIG_NO_HZ_FULL and runs the kernel on a machine > with an unstable TSC, it will produce a WARN_ON dump as well as taint > the kernel. This is a bit extreme for a kernel that just enables a > feature but doesn't use it. > > The warning should only happen if the user tries to use the feature by > either adding nohz_full to the kernel command line, or by enabling > CONFIG_NO_HZ_FULL_ALL that makes nohz used on all CPUs at boot up. Note, > this second feature should not (yet) be used by distros or anyone that > doesn't care if NO_HZ is used or not. > > Signed-off-by: Steven Rostedt > > diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c > index 6960172..6f47049 100644 > --- a/kernel/time/tick-sched.c > +++ b/kernel/time/tick-sched.c > @@ -182,7 +182,8 @@ static bool can_stop_full_tick(void) >* Don't allow the user to think they can get >* full NO_HZ with this machine. >*/ > - WARN_ONCE(1, "NO_HZ FULL will not work with unstable sched > clock"); > + WARN_ONCE(have_nohz_full_mask, > + "NO_HZ FULL will not work with unstable sched clock"); Seems good, indeed the warning and taint can be justified if the user filled the nohz_full mask. Ok I'll apply this and let the last word to Ingo in a pull request. Thanks. > return false; > } > #endif > > -- 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] nohz: fix compile warning in tick_nohz_init()
On Tue, Jul 16, 2013 at 12:18:47PM +0800, Li Zhong wrote:
> cpu is not used after commit 5b8621a68fdcd2baf1d3b413726f913a5254d46a
>
> Signed-off-by: Li Zhong
Applied, thanks!
> ---
> kernel/time/tick-sched.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
> index e80183f..8145860 100644
> --- a/kernel/time/tick-sched.c
> +++ b/kernel/time/tick-sched.c
> @@ -343,8 +343,6 @@ static int tick_nohz_init_all(void)
>
> void __init tick_nohz_init(void)
> {
> - int cpu;
> -
> if (!have_nohz_full_mask) {
> if (tick_nohz_init_all() < 0)
> return;
>
>
--
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: [fuse-devel] [PATCH] fuse: fix occasional dentry leak when readdirplus is used
On Tue, Jul 16, 2013 at 09:15:16AM -0400, Brian Foster wrote:
> I'm not sure why it would need to have a valid inode. A dentry with a
> NULL inode is valid, no?
It is valid, yes. It's called a "negative" dentry, which caches the information
that the file does not exist.
> I think the question is whether the above state (multiple, hashed dentries)
> can be valid for whatever reason. It certainly looks suspicious.
That state is not valid. So we certainly need to unhash the negative dentry
first, before hashing a new one. We could also reuse the old dentry, but that
is just an optimization.
Below patch fixes several issues with that function. Could you please give it a
go?
Thanks,
Miklos
diff --git a/fs/fuse/dir.c b/fs/fuse/dir.c
index 0eda527..a8208c5 100644
--- a/fs/fuse/dir.c
+++ b/fs/fuse/dir.c
@@ -1223,28 +1223,45 @@ static int fuse_direntplus_link(struct file *file,
if (name.name[1] == '.' && name.len == 2)
return 0;
}
+
+ if (invalid_nodeid(o->nodeid))
+ return -EIO;
+ if (!fuse_valid_type(o->attr.mode))
+ return -EIO;
+
fc = get_fuse_conn(dir);
name.hash = full_name_hash(name.name, name.len);
dentry = d_lookup(parent, &name);
- if (dentry && dentry->d_inode) {
+ if (dentry) {
inode = dentry->d_inode;
- if (get_node_id(inode) == o->nodeid) {
+ if (!inode) {
+ d_drop(dentry);
+ } else if (get_node_id(inode) != o->nodeid ||
+ ((o->attr.mode ^ inode->i_mode) & S_IFMT)) {
+ err = d_invalidate(dentry);
+ if (err)
+ goto out;
+ } else if (is_bad_inode(inode)) {
+ err = -EIO;
+ goto out;
+ } else {
struct fuse_inode *fi;
fi = get_fuse_inode(inode);
spin_lock(&fc->lock);
fi->nlookup++;
spin_unlock(&fc->lock);
+ fuse_change_attributes(inode, &o->attr,
+ entry_attr_timeout(o),
+ attr_version);
+
/*
* The other branch to 'found' comes via fuse_iget()
* which bumps nlookup inside
*/
goto found;
}
- err = d_invalidate(dentry);
- if (err)
- goto out;
dput(dentry);
dentry = NULL;
}
@@ -1259,25 +1276,30 @@ static int fuse_direntplus_link(struct file *file,
if (!inode)
goto out;
- alias = d_materialise_unique(dentry, inode);
- err = PTR_ERR(alias);
- if (IS_ERR(alias))
- goto out;
+ if (S_ISDIR(inode->i_mode)) {
+ mutex_lock(&fc->inst_mutex);
+ alias = fuse_d_add_directory(dentry, inode);
+ mutex_unlock(&fc->inst_mutex);
+ err = PTR_ERR(alias);
+ if (IS_ERR(alias)) {
+ iput(inode);
+ goto out;
+ }
+ } else {
+ alias = d_splice_alias(inode, dentry);
+ }
+
if (alias) {
dput(dentry);
dentry = alias;
}
found:
- fuse_change_attributes(inode, &o->attr, entry_attr_timeout(o),
- attr_version);
-
fuse_change_entry_timeout(dentry, o);
err = 0;
out:
- if (dentry)
- dput(dentry);
+ dput(dentry);
return err;
}
--
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: [ATTEND] How to act on LKML
On Tue, 2013-07-16 at 16:49 +0100, Stefano Stabellini wrote: > I have been hacking in several different Open Source communities during > the last few years, including qemu-devel, xen-devel, linux-arm and the > lkml of course. > > The etiquette on the lkml is by far the roughest of them all. It's the It's also the largest of them all. > "bad neighborhood with guns" of the Open Source world. You never know > when you are going to get a bullet, but sooner or later you'll get one. It just seems that way as it is so large. LKML has the most people and will also have the biggest conflict in personalities. It just goes with the territory. > > I think that it's hurting Linux and in particular it's hurting > attracting new talents. Then why do we have the largest # of developers than any other Open Source project? > Not just devs for hire but people passionate > about what they do and eager to become more involved in the project. > I met more than one good ex-Linux hacker that decided to move to do > other things because of this. Honestly, I think LKML over the years has become more tame. Yeah, back in 2005 it was rather harsh, but I don't really see that anymore. I don't see the nasty flame wars going on. Everything seems to be focused more on the technical side, and there's really very little personal attacks out there. Sure, with 15,000 emails a month, you get a few. And Linus will get fed up and burst. But they are really few and far between. And sometimes, a Linus burst gets things moving along much faster than being "professional". You think ARM would have gotten their act together as quick as they did if Linus didn't curse them out and threaten to stop pulling their crap? -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 5/5] s390/vmcore: Use vmcore for zfcpdump
This patch modifies the s390 copy_oldmem_page() and remap_oldmem_pfn_range()
function for zfcpdump to read from the HSA memory if memory below HSA_SIZE
bytes is requested. Otherwise real memory is used.
Signed-off-by: Michael Holzheu
---
arch/s390/Kconfig | 3 +-
arch/s390/include/asm/sclp.h | 1 +
arch/s390/kernel/crash_dump.c | 129 +++---
drivers/s390/char/zcore.c | 6 +-
4 files changed, 114 insertions(+), 25 deletions(-)
diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index 22f75b5..f88bdac 100644
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -514,6 +514,7 @@ config CRASH_DUMP
bool "kernel crash dumps"
depends on 64BIT && SMP
select KEXEC
+ select ZFCPDUMP
help
Generate crash dump after being started by kexec.
Crash dump kernels are loaded in the main kernel with kexec-tools
@@ -524,7 +525,7 @@ config CRASH_DUMP
config ZFCPDUMP
def_bool n
prompt "zfcpdump support"
- select SMP
+ depends on SMP
help
Select this option if you want to build an zfcpdump enabled kernel.
Refer to for more details on
this.
diff --git a/arch/s390/include/asm/sclp.h b/arch/s390/include/asm/sclp.h
index 06a1361..7dc7f9c 100644
--- a/arch/s390/include/asm/sclp.h
+++ b/arch/s390/include/asm/sclp.h
@@ -56,5 +56,6 @@ bool sclp_has_linemode(void);
bool sclp_has_vt220(void);
int sclp_pci_configure(u32 fid);
int sclp_pci_deconfigure(u32 fid);
+int memcpy_hsa(void *dest, unsigned long src, size_t count, int mode);
#endif /* _ASM_S390_SCLP_H */
diff --git a/arch/s390/kernel/crash_dump.c b/arch/s390/kernel/crash_dump.c
index 9769aa3..9a56989 100644
--- a/arch/s390/kernel/crash_dump.c
+++ b/arch/s390/kernel/crash_dump.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#define PTR_ADD(x, y) (((char *) (x)) + ((unsigned long) (y)))
#define PTR_SUB(x, y) (((char *) (x)) - ((unsigned long) (y)))
@@ -27,42 +28,80 @@
static void *elfcorehdr_newmem;
/*
- * Copy one page from "oldmem"
+ * Copy one page from zfcpdump "oldmem"
+ *
+ * For pages below ZFCPDUMP_HSA_SIZE memory from the HSA is copied. Otherwise
+ * real memory copy is used.
+ */
+static ssize_t copy_oldmem_page_zfcpdump(char *buf, size_t csize,
+unsigned long src, int userbuf)
+{
+ int rc;
+
+ if (src < ZFCPDUMP_HSA_SIZE) {
+ rc = memcpy_hsa(buf, src, csize, userbuf);
+ } else {
+ if (userbuf)
+ rc = copy_to_user_real((void __force __user *) buf,
+ (void *) src, csize);
+ else
+ rc = memcpy_real(buf, (void *) src, csize);
+ }
+ return rc ? rc : csize;
+}
+
+/*
+ * Copy one page from kdump "oldmem"
*
* For the kdump reserved memory this functions performs a swap operation:
* - [OLDMEM_BASE - OLDMEM_BASE + OLDMEM_SIZE] is mapped to [0 - OLDMEM_SIZE].
* - [0 - OLDMEM_SIZE] is mapped to [OLDMEM_BASE - OLDMEM_BASE + OLDMEM_SIZE]
*/
-ssize_t copy_oldmem_page(unsigned long pfn, char *buf,
-size_t csize, unsigned long offset, int userbuf)
-{
- unsigned long src;
+static ssize_t copy_oldmem_page_kdump(char *buf, size_t csize,
+ unsigned long src, int userbuf)
- if (!csize)
- return 0;
+{
+ int rc;
- src = (pfn << PAGE_SHIFT) + offset;
if (src < OLDMEM_SIZE)
src += OLDMEM_BASE;
else if (src > OLDMEM_BASE &&
src < OLDMEM_BASE + OLDMEM_SIZE)
src -= OLDMEM_BASE;
if (userbuf)
- copy_to_user_real((void __force __user *) buf, (void *) src,
- csize);
+ rc = copy_to_user_real((void __force __user *) buf,
+ (void *) src, csize);
+ else
+ rc = memcpy_real(buf, (void *) src, csize);
+ return rc ? rc : csize;
+}
+
+/*
+ * Copy one page from "oldmem"
+ */
+ssize_t copy_oldmem_page(unsigned long pfn, char *buf, size_t csize,
+unsigned long offset, int userbuf)
+{
+ unsigned long src;
+
+ if (!csize)
+ return 0;
+ src = (pfn << PAGE_SHIFT) + offset;
+ if (OLDMEM_BASE)
+ return copy_oldmem_page_kdump(buf, csize, src, userbuf);
else
- memcpy_real(buf, (void *) src, csize);
- return csize;
+ return copy_oldmem_page_zfcpdump(buf, csize, src, userbuf);
}
/*
- * Remap "oldmem"
+ * Remap "oldmem" for kdump
*
* For the kdump reserved memory this functions performs a swap operation:
* [0 - OLDMEM_SIZE] is mapped to [OLDMEM_BASE - OLDMEM_BASE + OLDMEM_SIZE]
*/
-int remap_oldmem_pfn_range(struct vm_area_struct *vma, unsigned long from,
- unsigned long pfn,
[PATCH v7 1/5] vmcore: Introduce ELF header in new memory feature
Currently for s390 we create the ELF core header in the 2nd kernel
with a small trick. We relocate the addresses in the ELF header in
a way that for the /proc/vmcore code it seems to be in the 1st kernel
(old) memory and the read_from_oldmem() returns the correct data.
This allows the /proc/vmcore code to use the ELF header in the
2nd kernel.
This patch now exchanges the old mechanism with the new and much
cleaner function call override feature that now offcially allows to
create the ELF core header in the 2nd kernel.
To use the new feature the following function have to be defined
by the architecture backend code to read from new memory:
* elfcorehdr_alloc: Allocate ELF header
* elfcorehdr_free: Free the memory of the ELF header
* elfcorehdr_read: Read from ELF header
* elfcorehdr_read_notes: Read from ELF notes
Signed-off-by: Michael Holzheu
Acked-by: Vivek Goyal
---
fs/proc/vmcore.c | 61 ++
include/linux/crash_dump.h | 6 +
2 files changed, 57 insertions(+), 10 deletions(-)
diff --git a/fs/proc/vmcore.c b/fs/proc/vmcore.c
index 2850317..d2036df 100644
--- a/fs/proc/vmcore.c
+++ b/fs/proc/vmcore.c
@@ -123,6 +123,36 @@ static ssize_t read_from_oldmem(char *buf, size_t count,
return read;
}
+/*
+ * Architectures may override this function to allocate ELF header in 2nd
kernel
+ */
+int __weak elfcorehdr_alloc(unsigned long long *addr, unsigned long long *size)
+{
+ return 0;
+}
+
+/*
+ * Architectures may override this function to free header
+ */
+void __weak elfcorehdr_free(unsigned long long addr)
+{}
+
+/*
+ * Architectures may override this function to read from ELF header
+ */
+ssize_t __weak elfcorehdr_read(char *buf, size_t count, u64 *ppos)
+{
+ return read_from_oldmem(buf, count, ppos, 0);
+}
+
+/*
+ * Architectures may override this function to read from notes sections
+ */
+ssize_t __weak elfcorehdr_read_notes(char *buf, size_t count, u64 *ppos)
+{
+ return read_from_oldmem(buf, count, ppos, 0);
+}
+
/* Read from the ELF header and then the crash dump. On error, negative value
is
* returned otherwise number of bytes read are returned.
*/
@@ -357,7 +387,7 @@ static int __init update_note_header_size_elf64(const
Elf64_Ehdr *ehdr_ptr)
notes_section = kmalloc(max_sz, GFP_KERNEL);
if (!notes_section)
return -ENOMEM;
- rc = read_from_oldmem(notes_section, max_sz, &offset, 0);
+ rc = elfcorehdr_read_notes(notes_section, max_sz, &offset);
if (rc < 0) {
kfree(notes_section);
return rc;
@@ -444,7 +474,8 @@ static int __init copy_notes_elf64(const Elf64_Ehdr
*ehdr_ptr, char *notes_buf)
if (phdr_ptr->p_type != PT_NOTE)
continue;
offset = phdr_ptr->p_offset;
- rc = read_from_oldmem(notes_buf, phdr_ptr->p_memsz, &offset, 0);
+ rc = elfcorehdr_read_notes(notes_buf, phdr_ptr->p_memsz,
+ &offset);
if (rc < 0)
return rc;
notes_buf += phdr_ptr->p_memsz;
@@ -536,7 +567,7 @@ static int __init update_note_header_size_elf32(const
Elf32_Ehdr *ehdr_ptr)
notes_section = kmalloc(max_sz, GFP_KERNEL);
if (!notes_section)
return -ENOMEM;
- rc = read_from_oldmem(notes_section, max_sz, &offset, 0);
+ rc = elfcorehdr_read_notes(notes_section, max_sz, &offset);
if (rc < 0) {
kfree(notes_section);
return rc;
@@ -623,7 +654,8 @@ static int __init copy_notes_elf32(const Elf32_Ehdr
*ehdr_ptr, char *notes_buf)
if (phdr_ptr->p_type != PT_NOTE)
continue;
offset = phdr_ptr->p_offset;
- rc = read_from_oldmem(notes_buf, phdr_ptr->p_memsz, &offset, 0);
+ rc = elfcorehdr_read_notes(notes_buf, phdr_ptr->p_memsz,
+ &offset);
if (rc < 0)
return rc;
notes_buf += phdr_ptr->p_memsz;
@@ -810,7 +842,7 @@ static int __init parse_crash_elf64_headers(void)
addr = elfcorehdr_addr;
/* Read Elf header */
- rc = read_from_oldmem((char*)&ehdr, sizeof(Elf64_Ehdr), &addr, 0);
+ rc = elfcorehdr_read((char *)&ehdr, sizeof(Elf64_Ehdr), &addr);
if (rc < 0)
return rc;
@@ -837,7 +869,7 @@ static int __init parse_crash_elf64_headers(void)
if (!elfcorebuf)
return -ENOMEM;
addr = elfcorehdr_addr;
- rc = read_from_oldmem(elfcorebuf, elfcorebuf_sz_orig, &addr, 0);
+ rc = elfcorehdr_read(elfcorebuf, elfcorebuf_sz_orig, &addr);
if (rc < 0)
goto fail;
@@ -866,7 +898,7 @@ static int __init pars
[PATCH v7 3/5] vmcore: Introduce remap_oldmem_pfn_range()
For zfcpdump we can't map the HSA storage because it is only available
via a read interface. Therefore, for the new vmcore mmap feature we have
introduce a new mechanism to create mappings on demand.
This patch introduces a new architecture function remap_oldmem_pfn_range()
that should be used to create mappings with remap_pfn_range() for oldmem
areas that can be directly mapped. For zfcpdump this is everything besides
of the HSA memory. For the areas that are not mapped by remap_oldmem_pfn_range()
a generic vmcore a new generic vmcore fault handler mmap_vmcore_fault()
is called.
This handler works as follows:
* Get already available or new page from page cache (find_or_create_page)
* Check if /proc/vmcore page is filled with data (PageUptodate)
* If yes:
Return that page
* If no:
Fill page using __vmcore_read(), set PageUptodate, and return page
Signed-off-by: Michael Holzheu
Acked-by: Vivek Goyal
cc: HATAYAMA Daisuke
---
fs/proc/vmcore.c | 91 ++
include/linux/crash_dump.h | 3 ++
2 files changed, 86 insertions(+), 8 deletions(-)
diff --git a/fs/proc/vmcore.c b/fs/proc/vmcore.c
index d2036df..532808e 100644
--- a/fs/proc/vmcore.c
+++ b/fs/proc/vmcore.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#include
#include
#include "internal.h"
@@ -153,11 +154,35 @@ ssize_t __weak elfcorehdr_read_notes(char *buf, size_t
count, u64 *ppos)
return read_from_oldmem(buf, count, ppos, 0);
}
+/*
+ * Architectures may override this function to map oldmem
+ */
+int __weak remap_oldmem_pfn_range(struct vm_area_struct *vma,
+ unsigned long from, unsigned long pfn,
+ unsigned long size, pgprot_t prot)
+{
+ return remap_pfn_range(vma, from, pfn, size, prot);
+}
+
+/*
+ * Copy to either kernel or user space
+ */
+static int copy_to(void *target, void *src, size_t size, int userbuf)
+{
+ if (userbuf) {
+ if (copy_to_user(target, src, size))
+ return -EFAULT;
+ } else {
+ memcpy(target, src, size);
+ }
+ return 0;
+}
+
/* Read from the ELF header and then the crash dump. On error, negative value
is
* returned otherwise number of bytes read are returned.
*/
-static ssize_t read_vmcore(struct file *file, char __user *buffer,
- size_t buflen, loff_t *fpos)
+static ssize_t __read_vmcore(char *buffer, size_t buflen, loff_t *fpos,
+int userbuf)
{
ssize_t acc = 0, tmp;
size_t tsz;
@@ -174,7 +199,7 @@ static ssize_t read_vmcore(struct file *file, char __user
*buffer,
/* Read ELF core header */
if (*fpos < elfcorebuf_sz) {
tsz = min(elfcorebuf_sz - (size_t)*fpos, buflen);
- if (copy_to_user(buffer, elfcorebuf + *fpos, tsz))
+ if (copy_to(buffer, elfcorebuf + *fpos, tsz, userbuf))
return -EFAULT;
buflen -= tsz;
*fpos += tsz;
@@ -192,7 +217,7 @@ static ssize_t read_vmcore(struct file *file, char __user
*buffer,
tsz = min(elfcorebuf_sz + elfnotes_sz - (size_t)*fpos, buflen);
kaddr = elfnotes_buf + *fpos - elfcorebuf_sz;
- if (copy_to_user(buffer, kaddr, tsz))
+ if (copy_to(buffer, kaddr, tsz, userbuf))
return -EFAULT;
buflen -= tsz;
*fpos += tsz;
@@ -208,7 +233,7 @@ static ssize_t read_vmcore(struct file *file, char __user
*buffer,
if (*fpos < m->offset + m->size) {
tsz = min_t(size_t, m->offset + m->size - *fpos,
buflen);
start = m->paddr + *fpos - m->offset;
- tmp = read_from_oldmem(buffer, tsz, &start, 1);
+ tmp = read_from_oldmem(buffer, tsz, &start, userbuf);
if (tmp < 0)
return tmp;
buflen -= tsz;
@@ -225,6 +250,55 @@ static ssize_t read_vmcore(struct file *file, char __user
*buffer,
return acc;
}
+static ssize_t read_vmcore(struct file *file, char __user *buffer,
+ size_t buflen, loff_t *fpos)
+{
+ return __read_vmcore(buffer, buflen, fpos, 1);
+}
+
+/*
+ * The vmcore fault handler uses the page cache and fills data using the
+ * standard __vmcore_read() function.
+ *
+ * On s390 the fault handler is used for memory regions that can't be mapped
+ * directly with remap_pfn_range().
+ */
+static int mmap_vmcore_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
+{
+#ifdef CONFIG_S390
+ struct address_space *mapping = vma->vm_file->f_mapping;
+ pgoff_t index = vmf->pgoff;
+ struct page *page;
+ loff_t offset;
+ char *buf;
+ int rc;
+
+ page = find_or_create_page(mapping, index, GFP_KERNEL);
+ if (!page)
[PATCH v7 0/5] kdump: Allow ELF header creation in new kernel
Hello Andrew, Here a new kdump patch series that we have discussed with Vivek and Hatayama during the last months. Besides of the feature described below, this patch series also fixes a regression on s390 that was introduced with the mmap patches for /proc/vmcore (git commit 83086978c63afd7c73e1c). See also: http://lists.infradead.org/pipermail/kexec/2013-July/009287.html Is it somehow possible to integrate this patch series into 3.11? ChangeLog = v6 => v7) - Rebase to v3.11-rc1 - Return VM_FAULT_SIGBUS in fault handler for non s390 - Use __va() for buffer in fault handler v5 => v6) - Set elfcorehdr_addr to ELFCORE_ADDR_ERR after elfcorehdr_free() - Fix OLDMEM_SIZE/ZFCPDUMP_HSA_SIZE confusion - Remove return VM_FAULT_MAJOR/MINOR - Use find_or_create_page() in mmap_vmcore_fault() - Use kfree instead of vfree in elfcorehdr_free() v4 => v5) - Add weak function elfcorehdr_read_notes() to read ELF notes - Rename weak functions for ELF header access and use "vmcorehdr_" prefix - Generic vmcore code calls elfcorehdr_alloc() if elfcorehdr= is not specified - Add vmcore fault handler for mmap of non-resident memory regions - Add weak function remap_oldmem_pfn_range() to be used by zfcpdump for mmap v3 => v4) - Rebase to 3.10-rc2 + vmcore mmap patches v8 v2 => v3) - Get rid of ELFCORE_ADDR_NEWMEM - Make read_from_crash_header() only read from kernel - Move read_from_crash_header() to weak function arch_read_from_crash_header() - Implement read_from_crash_header() strong function for s390 - Set elfcorehdr_addr to address of new ELF header v1 => v2) - Rebase 3.10-rc2 + vmcore mmap patches - Introduced arch_get/free_crash_header() and ELFCORE_ADDR_NEWMEM Feature Description === For s390 we want to use /proc/vmcore for our SCSI stand-alone dump (zfcpdump). We have support where the first HSA_SIZE bytes are saved into a hypervisor owned memory area (HSA) before the kdump kernel is booted. When the kdump kernel starts, it is restricted to use only HSA_SIZE bytes. The advantages of this mechanism are: * No crashkernel memory has to be defined in the old kernel. * Early boot problems (before kexec_load has been done) can be dumped * Non-Linux systems can be dumped. We modify the s390 copy_oldmem_page() function to read from the HSA memory if memory below HSA_SIZE bytes is requested. Since we cannot use the kexec tool to load the kernel in this scenario, we have to build the ELF header in the 2nd (kdump/new) kernel. So with the following patch set we would like to introduce the new function that the ELF header for /proc/vmcore can be created in the 2nd kernel memory. The following steps are done during zfcpdump execution: 1. Production system crashes 2. User boots a SCSI disk that has been prepared with the zfcpdump tool 3. Hypervisor saves CPU state of boot CPU and HSA_SIZE bytes of memory into HSA 4. Boot loader loads kernel into low memory area 5. Kernel boots and uses only HSA_SIZE bytes of memory 6. Kernel saves registers of non-boot CPUs 7. Kernel does memory detection for dump memory map 8. Kernel creates ELF header for /proc/vmcore 9. /proc/vmcore uses this header for initialization 10. The zfcpdump user space reads /proc/vmcore to write dump to SCSI disk - copy_oldmem_page() copies from HSA for memory below HSA_SIZE - copy_oldmem_page() copies from real memory for memory above HSA_SIZE --- Jan Willeke (1): s390/vmcore: Implement remap_oldmem_pfn_range for s390 Michael Holzheu (4): vmcore: Introduce ELF header in new memory feature s390/vmcore: Use ELF header in new memory feature vmcore: Introduce remap_oldmem_pfn_range() s390/vmcore: Use vmcore for zfcpdump arch/s390/Kconfig | 3 +- arch/s390/include/asm/sclp.h | 1 + arch/s390/kernel/crash_dump.c | 228 ++ drivers/s390/char/zcore.c | 6 +- fs/proc/vmcore.c | 152 include/linux/crash_dump.h| 9 ++ 6 files changed, 333 insertions(+), 66 deletions(-) -- 1.8.2.3 -- 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 v7 2/5] s390/vmcore: Use ELF header in new memory feature
This patch now exchanges the old relocate mechanism with the new
arch function call override mechanism that allows to create the ELF
core header in the 2nd kernel.
Signed-off-by: Michael Holzheu
---
arch/s390/kernel/crash_dump.c | 81 ---
1 file changed, 54 insertions(+), 27 deletions(-)
diff --git a/arch/s390/kernel/crash_dump.c b/arch/s390/kernel/crash_dump.c
index f703d91..bfb9cda 100644
--- a/arch/s390/kernel/crash_dump.c
+++ b/arch/s390/kernel/crash_dump.c
@@ -22,6 +22,11 @@
#define PTR_DIFF(x, y) ((unsigned long)(((char *) (x)) - ((unsigned long)
(y
/*
+ * Pointer to ELF header in new kernel
+ */
+static void *elfcorehdr_newmem;
+
+/*
* Copy one page from "oldmem"
*
* For the kdump reserved memory this functions performs a swap operation:
@@ -325,14 +330,6 @@ static int get_mem_chunk_cnt(void)
}
/*
- * Relocate pointer in order to allow vmcore code access the data
- */
-static inline unsigned long relocate(unsigned long addr)
-{
- return OLDMEM_BASE + addr;
-}
-
-/*
* Initialize ELF loads (new kernel)
*/
static int loads_init(Elf64_Phdr *phdr, u64 loads_offset)
@@ -383,7 +380,7 @@ static void *notes_init(Elf64_Phdr *phdr, void *ptr, u64
notes_offset)
ptr = nt_vmcoreinfo(ptr);
memset(phdr, 0, sizeof(*phdr));
phdr->p_type = PT_NOTE;
- phdr->p_offset = relocate(notes_offset);
+ phdr->p_offset = notes_offset;
phdr->p_filesz = (unsigned long) PTR_SUB(ptr, ptr_start);
phdr->p_memsz = phdr->p_filesz;
return ptr;
@@ -392,7 +389,7 @@ static void *notes_init(Elf64_Phdr *phdr, void *ptr, u64
notes_offset)
/*
* Create ELF core header (new kernel)
*/
-static void s390_elf_corehdr_create(char **elfcorebuf, size_t *elfcorebuf_sz)
+int elfcorehdr_alloc(unsigned long long *addr, unsigned long long *size)
{
Elf64_Phdr *phdr_notes, *phdr_loads;
int mem_chunk_cnt;
@@ -400,6 +397,11 @@ static void s390_elf_corehdr_create(char **elfcorebuf,
size_t *elfcorebuf_sz)
u32 alloc_size;
u64 hdr_off;
+ if (!OLDMEM_BASE)
+ return 0;
+ /* If elfcorehdr= has been passed via cmdline, we use that one */
+ if (elfcorehdr_addr != ELFCORE_ADDR_MAX)
+ return 0;
mem_chunk_cnt = get_mem_chunk_cnt();
alloc_size = 0x1000 + get_cpu_cnt() * 0x300 +
@@ -417,27 +419,52 @@ static void s390_elf_corehdr_create(char **elfcorebuf,
size_t *elfcorebuf_sz)
ptr = notes_init(phdr_notes, ptr, ((unsigned long) hdr) + hdr_off);
/* Init loads */
hdr_off = PTR_DIFF(ptr, hdr);
- loads_init(phdr_loads, ((unsigned long) hdr) + hdr_off);
- *elfcorebuf_sz = hdr_off;
- *elfcorebuf = (void *) relocate((unsigned long) hdr);
- BUG_ON(*elfcorebuf_sz > alloc_size);
+ loads_init(phdr_loads, hdr_off);
+ *addr = (unsigned long long) hdr;
+ elfcorehdr_newmem = hdr;
+ *size = (unsigned long long) hdr_off;
+ BUG_ON(elfcorehdr_size > alloc_size);
+ return 0;
}
/*
- * Create kdump ELF core header in new kernel, if it has not been passed via
- * the "elfcorehdr" kernel parameter
+ * Free ELF core header (new kernel)
*/
-static int setup_kdump_elfcorehdr(void)
+void elfcorehdr_free(unsigned long long addr)
{
- size_t elfcorebuf_sz;
- char *elfcorebuf;
-
- if (!OLDMEM_BASE || is_kdump_kernel())
- return -EINVAL;
- s390_elf_corehdr_create(&elfcorebuf, &elfcorebuf_sz);
- elfcorehdr_addr = (unsigned long long) elfcorebuf;
- elfcorehdr_size = elfcorebuf_sz;
- return 0;
+ if (!elfcorehdr_newmem)
+ return;
+ kfree((void *)(unsigned long)addr);
}
-subsys_initcall(setup_kdump_elfcorehdr);
+/*
+ * Read from ELF header
+ */
+ssize_t elfcorehdr_read(char *buf, size_t count, u64 *ppos)
+{
+ void *src = (void *)(unsigned long)*ppos;
+
+ src = elfcorehdr_newmem ? src : src - OLDMEM_BASE;
+ memcpy(buf, src, count);
+ *ppos += count;
+ return count;
+}
+
+/*
+ * Read from ELF notes data
+ */
+ssize_t elfcorehdr_read_notes(char *buf, size_t count, u64 *ppos)
+{
+ void *src = (void *)(unsigned long)*ppos;
+ int rc;
+
+ if (elfcorehdr_newmem) {
+ memcpy(buf, src, count);
+ } else {
+ rc = copy_from_oldmem(buf, src, count);
+ if (rc)
+ return rc;
+ }
+ *ppos += count;
+ return count;
+}
--
1.8.2.3
--
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 0/2] regulator: palmas-pmic: doc: update device tree bindings
On Tue, Jul 16, 2013 at 09:27:10AM -0500, Nishanth Menon wrote: > On 09:23-20130716, Nishanth Menon wrote: > > We seem to have a few missing updates to device tree bindings with the > > latest set of changes getting merged in. > Oops.. seems like I have an old mailID for Mark :( I'll need the actual patches as well... signature.asc Description: Digital signature
[PATCH v7 4/5] s390/vmcore: Implement remap_oldmem_pfn_range for s390
From: Jan Willeke
This patch introduces the s390 specific way to map pages from oldmem.
The memory area below OLDMEM_SIZE is mapped with offset OLDMEM_BASE.
The other old memory is mapped directly.
Signed-off-by: Jan Willeke
Signed-off-by: Michael Holzheu
---
arch/s390/kernel/crash_dump.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/arch/s390/kernel/crash_dump.c b/arch/s390/kernel/crash_dump.c
index bfb9cda..9769aa3 100644
--- a/arch/s390/kernel/crash_dump.c
+++ b/arch/s390/kernel/crash_dump.c
@@ -56,6 +56,32 @@ ssize_t copy_oldmem_page(unsigned long pfn, char *buf,
}
/*
+ * Remap "oldmem"
+ *
+ * For the kdump reserved memory this functions performs a swap operation:
+ * [0 - OLDMEM_SIZE] is mapped to [OLDMEM_BASE - OLDMEM_BASE + OLDMEM_SIZE]
+ */
+int remap_oldmem_pfn_range(struct vm_area_struct *vma, unsigned long from,
+ unsigned long pfn, unsigned long size, pgprot_t prot)
+{
+ unsigned long size_old;
+ int rc;
+
+ if (pfn < OLDMEM_SIZE >> PAGE_SHIFT) {
+ size_old = min(size, OLDMEM_SIZE - (pfn << PAGE_SHIFT));
+ rc = remap_pfn_range(vma, from,
+pfn + (OLDMEM_BASE >> PAGE_SHIFT),
+size_old, prot);
+ if (rc || size == size_old)
+ return rc;
+ size -= size_old;
+ from += size_old;
+ pfn += size_old >> PAGE_SHIFT;
+ }
+ return remap_pfn_range(vma, from, pfn, size, prot);
+}
+
+/*
* Copy memory from old kernel
*/
int copy_from_oldmem(void *dest, void *src, size_t count)
--
1.8.2.3
--
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] i2c-omap: always send stop after nack
Hi Grygorii, Filipe, On 7/16/2013 9:00 PM, Felipe Balbi wrote: > On Tue, Jul 16, 2013 at 03:08:04PM +0300, Grygorii Strashko wrote: >> Hi Felipe, >> On 07/16/2013 02:27 PM, Felipe Balbi wrote: >>> Hi, >>> >>> On Tue, Jul 16, 2013 at 02:01:11PM +0300, Grygorii Strashko wrote: On a OMAP4460, i2c-bus-3: A driver (lm75) is causing many 'timeout waiting for bus ready' errors. SDA remains high (as it should), but SCL remains low after a NACK. The bus becomes _unusable for other clients_. While probing, "lm75" writes a command, followed by a read + stop, but the write command is NACK'd. The chip does accept other writes/reads, it just refuses to ack invalid commands. In case the NACK may not be ignored, I believe it is correct to break out of the loop and send a stop for 2 reasons: 1. all chips, including the target chip, will know that the current transaction is finished 2. to set CLK high again, which prevents numerous timeouts on subsequent transactions As a test I've set 'I2C_M_IGNORE_NAK' for all .detect messages sent by the lm75 driver. Now the chip (tmp105) will provide read data as expected after the _repeated start_, even though it NACK'd the preceding WR command. And also the detection trick does work now, addresses 4,5,6,7 return the same read data as was returned from the last valid address 2. Felipe: > Which means your original patch starts to make a lot more sense. I > wonder is this is really what we should be doing though - breaking out > of the loop, I mean. So yes, we have to break the loop as the caller is not interested in processing any further commands. In i2c/algos/i2c-algo-bit.c, bit_xfer() works exactly the same way: break the loop (unless IGNORE_NAK) and call unconditionally i2c_stop(). It looks like TI's i2c-davinci will have the same problem as i2c-omap, and will need the same change. Grygorii, if you submit the patch, please add my Signed-off-by: Hein Tibosch cause you were earlier to notice and fix this problem. Hein -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-sunxi] Re: [PATCH 1/2] Initial support for Allwinner's Security ID fuses
On Mon, Jul 15, 2013 at 11:16:19PM +0200, Oliver Schinagl wrote:
>
> With your latest patches for binary attributes and your blog post, I
> thought that you want to create your binary attributes before the probe
> function, to avoid the userspace race. To do that, we have two options,
> create them in init (ugly?) or fill the .group member if available so it
> gets automatically created from the register function.
Yes, the .group thing should be what is needed here.
> Well in my case, I'm using the module_platform_driver() macro which
> expects the struct platform_driver. Platform_driver has a device_driver
> member .driver where the .groups is located. Great, using that works and
> we should have the sysfs entry race-free. However I don't know hot to
> exchange data between that and the rest of my driver.
>
> Before I used to_platform_device(kobj_to_dev(kobj)) as passed via the
> .read function to obtain a platform_device where i could use
> platform_get_drvdata on. All was good, but that doesn't fly now and my
> knowledge is a bit short as to why.
I don't understand, why not use the platform device that was passed to
the binary attribute write function?
> The second method is finding some other shared structure given that we
> get a platform_device in the probe function, yet I couldn't find
> anything and this platform_device isn't the same as the one from the .read.
It should be, why isn't it?
> Of course using a global var bypasses this issue, but I'm sure it won't
> pass review ;)
The platform device structure should have what you need, right?
> So using these new patches for binary attributes, how can I pass data
> between my driver and the sysfs files using a platform_driver? Or are
> other 'hacks' needed and using the .groups attribute from
> platform_driver->device_driver->groups is really the wrong approach.
>
> I did ask around and still haven't figured it out so far, so I do
> apologize if you feel I'm wasting your precious time.
How is the platform device not the same thing that was passed to your
probe function?
>
> Oliver
> /*
> * Copyright (c) 2013 Oliver Schinagl
> * http://www.linux-sunxi.org
> *
> * Oliver Schinagl
> *
> * This program is free software; you can redistribute it and/or modify
> * it under the terms of the GNU General Public License as published by
> * the Free Software Foundation; either version 2 of the License, or
> * (at your option) any later version.
> *
> * This program is distributed in the hope that it will be useful,
> * but WITHOUT ANY WARRANTY; without even the implied warranty of
> * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> * GNU General Public License for more details.
> *
> * This driver exposes the Allwinner security ID, a 128 bit eeprom, in byte
> * sized chunks.
> */
>
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
>
> #define DRV_NAME "sunxi-sid"
>
> /* There are 4 32-bit keys */
> #define SID_KEYS 4
> /* Each key is 4 bytes long */
> #define SID_SIZE (SID_KEYS * 4)
>
> /* We read the entire key, due to a 32 bit read alignment requirement. Since
> we
> * want to return the requested byte, this resuls in somewhat slower code and
> * uses 4 times more reads as needed but keeps code simpler. Since the SID is
> * only very rarly probed, this is not really an issue.
> */
> static u8 sunxi_sid_read_byte(const void __iomem *sid_reg_base,
> const unsigned int offset)
> {
> u32 sid_key;
>
> if (offset >= SID_SIZE)
> return 0;
>
> sid_key = ioread32be(sid_reg_base + round_down(offset, 4));
> sid_key >>= (offset % 4) * 8;
>
> return sid_key; /* Only return the last byte */
> }
>
> static ssize_t eeprom_read(struct file *fd, struct kobject *kobj,
> struct bin_attribute *attr, char *buf,
> loff_t pos, size_t size)
> {
> struct platform_device *pdev;
> void __iomem *sid_reg_base;
> int i;
>
> pdev = to_platform_device(kobj_to_dev(kobj));
> sid_reg_base = (void __iomem *)platform_get_drvdata(pdev);
Great, isn't that what you need?
> printk("0x%x, 0x%x 0x%x 0x%x\n", kobj, kobj_to_dev(kobj), pdev,
> sid_reg_base);
>
> if (pos < 0 || pos >= SID_SIZE)
> return 0;
> if (size > SID_SIZE - pos)
> size = SID_SIZE - pos;
>
> for (i = 0; i < size; i++)
> buf[i] = sunxi_sid_read_byte(sid_reg_base, pos + i);
>
> return i;
> }
What are you missing in this function that you have in your probe
function?
This driver looks fine, what is not working properly?
totally confused,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/
Re: [PATCH] usb: udc: add gadget state kobject uevent
On Tue, Jul 16, 2013 at 11:49:07AM +0800, Rong Wang wrote: > Hi Greg, > > The USB on our platform can change roles between HOST and GADGET, but > it is not capable of OTG. That kind of sounds like the definition of OTG :) > When the USB changes between roles the udev will run some scripts > automatically according to the udev rules. What exactly does udev/userspace see when the roles change? And what can trigger the change in roles? > The default role is GADGET, and we bind the g_mass_storage to the USB > GADGET role. > > We should secure the back end file storage between the device and the > host PC connecting to our device. > We need to know when the GADGET is really connect to a host PC, then > we can umount the file on the device > and export it to the g_mass_storage. I thought you already get an event for this, otherwise no one would be able to properly deal with this. > The question is since we default GADGET, so the g_mass_storage.ko is > installed early but connecting to a host PC > is randomly, But the udev has no idea when a host PC connects our device. > > So we consider it's reasonable to let the udev know the GADGET device state. > Is there any alternative to our question? I thought we already export events for gadget device states, have you looked for them? I can't dig through the code at the moment, but this seems like a pretty common issue... Felipe, any ideas? greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH-v3 00/17] staging/lustre: fix various build issues
On Tue, Jul 16, 2013 at 10:21:23AM +0800, Peng Tao wrote: > On Tue, Jul 16, 2013 at 8:07 AM, Greg Kroah-Hartman > wrote: > > On Mon, Jul 15, 2013 at 12:13:57PM -0700, Andrew Morton wrote: > >> On Mon, 15 Jul 2013 11:40:30 -0700 Greg Kroah-Hartman > >> wrote: > >> > >> > On Mon, Jul 15, 2013 at 10:16:29AM -0700, Joe Perches wrote: > >> > > On Mon, 2013-07-15 at 22:27 +0800, Peng Tao wrote: > >> > > > Hi Greg, > >> > > > > >> > > > Now that 3.11-rc1 is out, please consider queuing following patches > >> > > > to > >> > > > fix various Lustre client build issues. I've verified that we can now > >> > > > pass build on sparc/mips/s390/powerpc/x86, both 32bits and 64bits. > >> > > > >> > > These patches apply to linus' current, but not to -next > >> > > where other lustre patches have already been applied. > >> > > >> > What trees are those in? I have nothing in my staging-next branch right > >> > now, so they didn't come from there, which is where I will be applying > >> > this to. > >> > >> See the five patches I sent you on July 8 ;) > >> > >> I'll resend. > > > > I got them, I couldn't apply them until after -rc1 is out, so I'll queue > > them up later this week. > > > Hi Greg and Andrew, > > One issue with the five patches is that the shrinker API change is not > in Linus' tree. So if Greg merges them in staging tree, Lustre cannot > build there. Is it OK to break in staging tree and just to make sure > -next can build? lustre can't build anyway, so what's the issue? :) I'll not apply those patches, don't worry, the shrinker stuff needs to stay in Andrew's tree until it hits Linus's. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.11-rc1] crypto: Fix boot failure due to moduledependency.
On Tue, 2013-07-16 at 22:49 +0900, Tetsuo Handa wrote: > Herbert Xu wrote: > > Looks like a bug in whatever is creating the initrd as it isn't > > including modules necessary for the boot. > > It turned out that it is already wrong as of creating modules.dep. > > # grep crc /lib/modules/3.11.0-rc1/modules.dep > kernel/crypto/crct10dif.ko: > kernel/drivers/scsi/sd_mod.ko: kernel/lib/crc-t10dif.ko > kernel/lib/crc-t10dif.ko: > > modules.dep says > > (1) sd_mod.ko depends on crc-t10dif.ko > (2) crc-t10dif.ko does not depend on crct10dif.ko Yes, the generator of modules.dep does not seem to pick up the right dependency. > > but commit 2d31e518 made crc-t10dif.ko depend on crct10dif.ko , didn't it? > > crct10dif.ko need to be loaded before crc-t10dif.ko is loaded, but doing > > diff --git a/lib/Kconfig b/lib/Kconfig > index 35da513..53ee0fd 100644 > --- a/lib/Kconfig > +++ b/lib/Kconfig > @@ -68,6 +68,7 @@ config CRC_T10DIF > tristate "CRC calculation for the T10 Data Integrity Field" > select CRYPTO > select CRYPTO_CRCT10DIF > + depends on CRYPTO_CRCT10DIF Herbert, seems like modules.dep generator wants explicit - select CRYPTO_CRCT10DIF + depends on CRYPTO_CRCT10DIF But it seems to me like it should have known CRC_T10DIF needs CRYPTO_CRCT10DIF when we do select CRYPTO_CRCT10DIF Your thoughts? Thanks. Tim > help > This option is only needed if a module that's not in the > kernel tree needs to calculate CRC checks for use with the > > causes below warning. > > crypto/Kconfig:379: symbol CRYPTO_CRCT10DIF is selected by CRC_T10DIF > warning: (BLK_DEV_SD && SCSI_LPFC && SCSI_DEBUG) selects CRC_T10DIF which > has unmet direct dependencies (CRYPTO_CRCT10DIF) -- 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: [QUERY] User-Mode Linux and /dev/tty*
Richard Weinberger wrote: > UML does not have virtual consoles. Then why do I see this on my UML box? # ls /dev/tty* | wc -l 113 Why is it creating unusable devices? Is drivers/tty.c responsible for this? What is it exactly? > I'm not running HEAD, but opensuse 12.3 (with systemd) works on UML. Also, what's with all the xterm_open : run_helper failed, errno = 2 messages? (I installed xterm, but it wasn't very enlightening) How is drivers/xterm.c supposed to work? And what is mconsole? -- 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/
driver model, duplicate names question
Hi Greg, I would like to create tree like structure using device model (struct device, device_register/device_unregister) using parent/child relationship while creation. I want to be able to create duplicate names, when their parents are different, similar to a directory structure. I see that I can't create devices with duplicate names (device names), even when their parents are different. How can I allow duplicate names when their parents are different devices? I want to avoid flat model as I have parent child relationship and there will be too many devices using flat model. Why, I need? I am going to publish RFC for a new power cap class driver. We have a multiple controllers under power cap class (they are devices). Under which there are multiple power zones, with parent/child relationships. Currently I have to use kobject_init_and_add, which I want to avoid and just use device_register. Other places, wherever such relationships are required, kobjects are used like cpufreq. Thanks, Srinivas Pandruvada Open Source Technology Center, Intel Corp. -- 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 RFC V10 15/18] kvm : Paravirtual ticketlocks support for linux guests running on KVM hypervisor
On Tue, Jul 16, 2013 at 05:48:52PM +0200, Peter Zijlstra wrote: > On Tue, Jul 16, 2013 at 09:02:15AM +0300, Gleb Natapov wrote: > > BTW can NMI handler take spinlocks? > > No -- that is, yes you can using trylock, but you still shouldn't. > Great news for this code. Thanks. -- Gleb. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH-v3 00/17] staging/lustre: fix various build issues
On Mon, 2013-07-15 at 23:32 -0700, Greg Kroah-Hartman wrote: > I'll not apply those patches, don't worry, the shrinker stuff needs to > stay in Andrew's tree until it hits Linus's. To clarify, are you going to apply these 17 patches but not those 5 patches in Andrew's tree? -- 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: [QUERY] User-Mode Linux and /dev/tty*
Am 16.07.2013 18:26, schrieb Ramkumar Ramachandra: > Richard Weinberger wrote: >> UML does not have virtual consoles. > > Then why do I see this on my UML box? > > # ls /dev/tty* | wc -l > 113 > > Why is it creating unusable devices? Is drivers/tty.c responsible for > this? What is it exactly? This is not UML specific. Are you using devtmpfs? >> I'm not running HEAD, but opensuse 12.3 (with systemd) works on UML. > > Also, what's with all the > >xterm_open : run_helper failed, errno = 2 2 is ENOENT. Do you have uml-utils installed? > messages? (I installed xterm, but it wasn't very enlightening) > How is drivers/xterm.c supposed to work? And what is mconsole? the xterm drivers opens a xterm on the host side using port-helper. Mconsole is the management console. Please read the documentation. Thanks, //richard -- 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: [Ksummit-2013-discuss] When to push bug fixes to mainline
At Tue, 16 Jul 2013 00:19:16 -0700 (PDT), David Lang wrote: > > On Fri, 12 Jul 2013, Willy Tarreau wrote: > > > And maybe in the end, having 1/10 patch cause a regression is not *that* > > dramatic, and probably less than not fixing the 9 other bugs. In one case > > we rely on -stable to merge the 10 fixes, and on the other case we'd rely > > on -stable to just revert one of them. > > Apologies for the late post, I'm catching up on things, but this jumped out > at > me. > > We went through a LOT of pain several years ago when people got into the > mindset > that a patch was acceptable if it fixed more people than it broke. > eliminating > that mindset did wonders for kernel stability. > > Regressions are a lot more of a negative than bugfixes are a positive, a 10:1 > ratio of fixes to regressions is _not_ good enough. IMO, one of the reasons is the nature of stable-release: the stable tree is released soon after reviews of patches, so no actual regression tests can be done before the release. For finding a regression, patch reviews won't be enough; all patches have been already reviewed, thus essentially they must be all positive/good fixes. And the compile is OK. So what's the problem? Maybe some QA period before the release might help, but who would care? (Especially under the situation where everybody has own x.y stable tree?) Takashi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2 2/2] regulator: palmas-pmic: doc: remove ti,tstep
commit 28d1e8cd671a53d6b4f967abbbc2a55f7bd333f6
(regulator: palma: add ramp delay support through regulator constraints)
Removed the regulator's ti,step option from driver without updating the
documentation.
So, remove from documentation and example as well.
Signed-off-by: Nishanth Menon
---
.../devicetree/bindings/regulator/palmas-pmic.txt |2 --
1 file changed, 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/regulator/palmas-pmic.txt
b/Documentation/devicetree/bindings/regulator/palmas-pmic.txt
index 04d67f0..30b0581 100644
--- a/Documentation/devicetree/bindings/regulator/palmas-pmic.txt
+++ b/Documentation/devicetree/bindings/regulator/palmas-pmic.txt
@@ -33,7 +33,6 @@ Optional nodes:
ti,roof-floor - control voltage selection by pin(boolean)
ti,mode-sleep - mode to adopt in pmic sleep 0 - off, 1 - auto,
2 - eco, 3 - forced pwm
- ti,tstep - slope control 0 - Jump, 1 10mV/us, 2 5mV/us, 3
2.5mV/us
ti,smps-range - OTP has the wrong range set for the hardware so
override
0 - low range, 1 - high range.
@@ -59,7 +58,6 @@ pmic {
ti,warm-reset;
ti,roof-floor;
ti,mode-sleep = <0>;
- ti,tstep = <0>;
ti,smps-range = <1>;
};
--
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: [Ksummit-2013-discuss] KS Topic request: Handling the Stable kernel, let's dump the cc: stable tag
On Tue, Jul 16, 2013 at 11:11:24AM +0200, Jiri Kosina wrote: > On Mon, 15 Jul 2013, Greg KH wrote: > > > > Anything that's being reviewed on the stable list is public. I know > > > this is an old argument, but if you point out a fix you *know* has a > > > security impact then you'll help general distribution maintainers and > > > users a lot more than you help the black-hats who are quite capable of > > > recognising such a fix (if they haven't already spotted and exploited > > > the bug). > > > > I'm sorry, but you know I will not do that, so asking about it isn't > > going to change this behavior. > > I just followed up in the other thread, where Ted was explaining why the > huge /dev/random rework was a -stable material. > > Why specifically would it be wrong to be open about this being security > related, and providing the necessary data (i.e. at least reference to > http://factorable.net/) publically? > > I fail to see what the point behind hiding this would be. I'm not "hiding" anything, all I'm doing is using the exact same changelog comments that are in Linus's tree, and nothing else. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2 1/2] regulator: palmas-pmic: doc: fix typo for sleep-mode
commit 3c870e3f9d9d98f1ab98614b3b1fd5c79287d361 (regulator: palmas: Change the DT node property names to follow the convention) Missed updating mode-sleep from sleep-mode. Fix the same. Documentation example seems proper for this property. Signed-off-by: Nishanth Menon --- .../devicetree/bindings/regulator/palmas-pmic.txt |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/regulator/palmas-pmic.txt b/Documentation/devicetree/bindings/regulator/palmas-pmic.txt index d5a3086..04d67f0 100644 --- a/Documentation/devicetree/bindings/regulator/palmas-pmic.txt +++ b/Documentation/devicetree/bindings/regulator/palmas-pmic.txt @@ -31,7 +31,7 @@ Optional nodes: Optional sub-node properties: ti,warm-reset - maintain voltage during warm reset(boolean) ti,roof-floor - control voltage selection by pin(boolean) - ti,sleep-mode - mode to adopt in pmic sleep 0 - off, 1 - auto, + ti,mode-sleep - mode to adopt in pmic sleep 0 - off, 1 - auto, 2 - eco, 3 - forced pwm ti,tstep - slope control 0 - Jump, 1 10mV/us, 2 5mV/us, 3 2.5mV/us ti,smps-range - OTP has the wrong range set for the hardware so override -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH-v3 00/17] staging/lustre: fix various build issues
On Tue, Jul 16, 2013 at 09:34:15AM -0700, Joe Perches wrote: > On Mon, 2013-07-15 at 23:32 -0700, Greg Kroah-Hartman wrote: > > I'll not apply those patches, don't worry, the shrinker stuff needs to > > stay in Andrew's tree until it hits Linus's. > > To clarify, are you going to apply these 17 patches but not > those 5 patches in Andrew's tree? > Give me some time to catch up, I have 1555 patches in my "to-apply" mbox to dig through in the next 5 days, and I will deal with it then. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2 0/2] regulator: palmas-pmic: doc: update device tree bindings
We seem to have a few missing updates to device tree bindings with the latest set of changes getting merged in. Changes since V1: Apologies on the spam, looks like I got the wrong mail ID first time around :( minor commit message cleanups V1: http://marc.info/?l=linux-doc&m=137398467901450&w=2 Based on v3.11-rc1 tag Nishanth Menon (2): regulator: palmas-pmic: doc: fix typo for sleep-mode regulator: palmas-pmic: doc: remove ti,tstep .../devicetree/bindings/regulator/palmas-pmic.txt |4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) -- 1.7.9.5 Regards, Nishanth Menon -- 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: [Ksummit-2013-discuss] KS Topic request: Handling the Stable kernel, let's dump the cc: stable tag
On Tue, Jul 16, 2013 at 11:46:05AM +0200, Jiri Kosina wrote: > On Tue, 16 Jul 2013, James Bottomley wrote: > > > > But I need, from the distros, specific examples of what they object to. > > > So far all I've gotten is one security patch (that was needed), and one > > > patch for sysfs that I backported too far in the version numbers (my > > > fault.) > > > > > > Given the huge number of stable patches over the past few years, only > > > having 2 patches be an issue sounds like things are working well for > > > people here. > > > > > > If I don't get pushback, with specifics, from the distros, I will not > > > know what to change, so if people can provide me that, it will help out > > > a lot. > > > > I agree ... I think Ji?? and his Red Hat equivalent need to pipe up and > > give us more examples of the problems they've been having. > > I am still continuing with my pushback against the /dev/random revamp that > happened in -stable; at least in the form it happened. I still strongly > believe it's something that's not a stable material. But that's happening > in parallel in a different thread already. > > Okay, if you want another example: > > commit a6aa749906b92eaec6ca0469f90f35de26044d90 > Author: Zhenzhong Duan > Date: Thu Dec 20 15:05:14 2012 -0800 > > drivers/firmware/dmi_scan.c: fetch dmi version from SMBIOS if it > exists > > While this is a correct fix for major kernel release, as it achieves > correctness by checking SMBIOS version properly and behaving according to > the spec, it actually causes an userspace ABI regression in some sense, as > it just changes byte order of /sys/class/dmi/id/product_uuid on certain > systems. > > Which is something I absolutely *do not* expect from a minor release of > branch which is called "stable". As you pointed out, your definition of "stable" is one that the enterprise distros have created, and might be totally different from my view of what "stable" is :) And also, as Ben pointed out, this was probably wrong, and someone should have told me about this, so I could have reverted it. Please do so the next time. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Ksummit-2013-discuss] When to push bug fixes to mainline
On Tue, 16 Jul 2013, Takashi Iwai wrote: At Tue, 16 Jul 2013 00:19:16 -0700 (PDT), David Lang wrote: On Fri, 12 Jul 2013, Willy Tarreau wrote: And maybe in the end, having 1/10 patch cause a regression is not *that* dramatic, and probably less than not fixing the 9 other bugs. In one case we rely on -stable to merge the 10 fixes, and on the other case we'd rely on -stable to just revert one of them. Apologies for the late post, I'm catching up on things, but this jumped out at me. We went through a LOT of pain several years ago when people got into the mindset that a patch was acceptable if it fixed more people than it broke. eliminating that mindset did wonders for kernel stability. Regressions are a lot more of a negative than bugfixes are a positive, a 10:1 ratio of fixes to regressions is _not_ good enough. IMO, one of the reasons is the nature of stable-release: the stable tree is released soon after reviews of patches, so no actual regression tests can be done before the release. For finding a regression, patch reviews won't be enough; all patches have been already reviewed, thus essentially they must be all positive/good fixes. And the compile is OK. So what's the problem? Maybe some QA period before the release might help, but who would care? (Especially under the situation where everybody has own x.y stable tree?) I am not saying that no regressions will happen (for exactly the reasons that you are giving). what I am complaining about is the attitude that a few regressions are Ok, as long as there are more fixes than there are regressions. David Lang -- 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 0/4] tracing/kprobes/uprobes: Fix race between opening probe event files and deleting probe
On 07/15, Oleg Nesterov wrote: > > So. As Masami pointed out, this is not enough. Probably we can add more > hacks, but I'd like to discuss the alternative approach. > > Note also that this ref count has the unfortunate property, if someone > keeps the file opened we can't remove an event. And please correct me, but afaics there are similar problems with rmdir instances/xxx. > What this patch does: > > - add the new "topmost" rw_semaphore, file_sem. probably unneeded... > - trace_remove_event_call() takes this sem for writing and > cleares enable/id/format/filter->i_private > > - removes tracing_open_generic_file/tracing_release_generic_file, > we do not use file->f_private any longer > > - changes event_enable_read/event_enable_write to read > ftrace_event_file = i_private under read_lock(file_sem) and > abort if it is null. > > Question: why event_enable_write() needs trace_array_get() ? probably it doesn't... > Steven, Masami, do you think this can make any sense? Oleg. -- 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: [Ksummit-2013-discuss] KS Topic request: Handling the Stable kernel, let's dump the cc: stable tag
On Mon, 2013-07-15 at 23:24 -0700, David Lang wrote: > Just because some crazy person ;-) decides to maintain 2.4 for many years > doesn't mean that every subsystem maintainer needs to worry about backporting > patches from 3.11 all the way back to 2.4. The fact that they are as willing > as > they are to review the results of the backports for problems in amazing. Any "process" that we come up with for maintainers with respect to the stable tree, should only matter to the official ones "last release" and "last release-1". All others are the responsibility of those maintaining it. Long term stable trees shouldn't burden the maintainer unless they want to help. I don't expect much help from maintainers for the 3.6 stable I maintain. Any help I do get I'm greatly appreciated of. I also love it when maintainers add which versions of the kernel a bug fix goes back too. That is, I love seeing Cc: sta...@vger.kernel.org # 3.2+ instead of just: Cc: sta...@vger.kernel.org But even that, I'm glad to see and don't expect to. The maintainers don't need that burden as well. I'll read the change log and try to figure out if it's required or not. And if it applies, I add it, otherwise, I skip it. -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: driver model, duplicate names question
On Tue, Jul 16, 2013 at 09:34:57AM -0700, Srinivas Pandruvada wrote: > Hi Greg, > > I would like to create tree like structure using device model (struct > device, device_register/device_unregister) using parent/child > relationship while creation. I want to be able to create duplicate > names, when their parents are different, similar to a directory structure. > I see that I can't create devices with duplicate names (device names), > even when their parents are different. We actually check that? Nice, I didn't realize that :) > How can I allow duplicate names when their parents are different devices? > I want to avoid flat model as I have parent child relationship and there > will be too many devices using flat model. Devices on the same bus shouldn't have the same name, but if they are in a "tree", it should be ok. What check is erroring out? > Why, I need? > I am going to publish RFC for a new power cap class driver. We have a > multiple controllers under power cap class (they are devices). Under > which there are multiple power zones, with parent/child relationships. > Currently I have to use kobject_init_and_add, which I want to avoid and > just use device_register. Other places, wherever such relationships are > required, kobjects are used like cpufreq. Yes, you shouldn't use "raw" kobject calls at all, so we should fix this. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 6/7] USB: ohci-at91: add usb_clk for transition to common clk framework
On Tue, 16 Jul 2013, Boris BREZILLON wrote:
> The AT91 PMC (Power Management Controller) provides an USB clock used by
> USB Full Speed host (ohci) and USB Full Speed device (udc).
> The usb drivers (ohci and udc) must configure this clock to 48Mhz.
> This configuration was formely done in mach-at91/clock.c, but this
> implementation will be removed when moving to common clk framework.
>
> This patch add support for usb clock retrieval and configuration, and is
> backward compatible with the current at91 clk implementation (if usb clk
> is not found, it does not configure/enable the usb clk).
But it does print a warning in the system log, right?
> @@ -144,6 +150,11 @@ static int usb_hcd_at91_probe(const struct hc_driver
> *driver,
> goto err2;
> }
>
> + uclk = clk_get(&pdev->dev, "usb_clk");
> + if (IS_ERR(uclk)) {
> + uclk = NULL;
> + dev_warn(&pdev->dev, "failed to get usb_clk\n");
> + }
Is this really what you want for backward compatibility?
Alan Stern
--
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 for 3.2] memcg: do not trap chargers with full callstack on OOM
On Tue, Jul 16, 2013 at 06:09:05PM +0200, Michal Hocko wrote: > On Tue 16-07-13 11:35:44, Johannes Weiner wrote: > > On Mon, Jul 15, 2013 at 06:00:06PM +0200, Michal Hocko wrote: > > > On Mon 15-07-13 17:41:19, Michal Hocko wrote: > > > > On Sun 14-07-13 01:51:12, azurIt wrote: > > > > > > CC: "Johannes Weiner" , > > > > > > linux-kernel@vger.kernel.org, linux...@kvack.org, "cgroups > > > > > > mailinglist" , "KAMEZAWA Hiroyuki" > > > > > > , righi.and...@gmail.com > > > > > >> CC: "Johannes Weiner" , > > > > > >> linux-kernel@vger.kernel.org, linux...@kvack.org, "cgroups > > > > > >> mailinglist" , "KAMEZAWA Hiroyuki" > > > > > >> , righi.and...@gmail.com > > > > > >>On Wed 10-07-13 18:25:06, azurIt wrote: > > > > > >>> >> Now i realized that i forgot to remove UID from that cgroup > > > > > >>> >> before > > > > > >>> >> trying to remove it, so cgroup cannot be removed anyway (we > > > > > >>> >> are using > > > > > >>> >> third party cgroup called cgroup-uid from Andrea Righi, which > > > > > >>> >> is able > > > > > >>> >> to associate all user's processes with target cgroup). Look > > > > > >>> >> here for > > > > > >>> >> cgroup-uid patch: > > > > > >>> >> https://www.develer.com/~arighi/linux/patches/cgroup-uid/cgroup-uid-v8.patch > > > > > >>> >> > > > > > >>> >> ANYWAY, i'm 101% sure that 'tasks' file was empty and > > > > > >>> >> 'under_oom' was > > > > > >>> >> permanently '1'. > > > > > >>> > > > > > > >>> >This is really strange. Could you post the whole diff against > > > > > >>> >stable > > > > > >>> >tree you are using (except for grsecurity stuff and the above > > > > > >>> >cgroup-uid > > > > > >>> >patch)? > > > > > >>> > > > > > >>> > > > > > >>> Here are all patches which i applied to kernel 3.2.48 in my last > > > > > >>> test: > > > > > >>> http://watchdog.sk/lkml/patches3/ > > > > > >> > > > > > >>The two patches from Johannes seem correct. > > > > > >> > > > > > >>From a quick look even grsecurity patchset shouldn't interfere as it > > > > > >>doesn't seem to put any code between handle_mm_fault and > > > > > >>mm_fault_error > > > > > >>and there also doesn't seem to be any new handle_mm_fault call > > > > > >>sites. > > > > > >> > > > > > >>But I cannot tell there aren't other code paths which would lead to > > > > > >>a > > > > > >>memcg charge, thus oom, without proper FAULT_FLAG_KERNEL handling. > > > > > > > > > > > > > > > > > >Michal, > > > > > > > > > > > >now i can definitely confirm that problem with unremovable cgroups > > > > > >persists. What info do you need from me? I applied also your little > > > > > >'WARN_ON' patch. > > > > > > > > > > Ok, i think you want this: > > > > > http://watchdog.sk/lkml/kern4.log > > > > > > > > Jul 14 01:11:39 server01 kernel: [ 593.589087] [ pid ] uid tgid > > > > total_vm rss cpu oom_adj oom_score_adj name > > > > Jul 14 01:11:39 server01 kernel: [ 593.589451] [12021] 1333 12021 > > > > 17202764723 4 0 0 apache2 > > > > Jul 14 01:11:39 server01 kernel: [ 593.589647] [12030] 1333 12030 > > > > 17203064748 2 0 0 apache2 > > > > Jul 14 01:11:39 server01 kernel: [ 593.589836] [12031] 1333 12031 > > > > 17203064749 3 0 0 apache2 > > > > Jul 14 01:11:39 server01 kernel: [ 593.590025] [12032] 1333 12032 > > > > 17061963428 3 0 0 apache2 > > > > Jul 14 01:11:39 server01 kernel: [ 593.590213] [12033] 1333 12033 > > > > 16793460524 2 0 0 apache2 > > > > Jul 14 01:11:39 server01 kernel: [ 593.590401] [12034] 1333 12034 > > > > 17074763496 4 0 0 apache2 > > > > Jul 14 01:11:39 server01 kernel: [ 593.590588] [12035] 1333 12035 > > > > 16965962451 1 0 0 apache2 > > > > Jul 14 01:11:39 server01 kernel: [ 593.590776] [12036] 1333 12036 > > > > 16761460384 3 0 0 apache2 > > > > Jul 14 01:11:39 server01 kernel: [ 593.590984] [12037] 1333 12037 > > > > 16634258964 3 0 0 apache2 > > > > Jul 14 01:11:39 server01 kernel: [ 593.591178] Memory cgroup out of > > > > memory: Kill process 12021 (apache2) score 847 or sacrifice child > > > > Jul 14 01:11:39 server01 kernel: [ 593.591370] Killed process 12021 > > > > (apache2) total-vm:688108kB, anon-rss:255472kB, file-rss:3420kB > > > > Jul 14 01:11:41 server01 kernel: [ 595.392920] [ cut here > > > > ] > > > > Jul 14 01:11:41 server01 kernel: [ 595.393096] WARNING: at > > > > kernel/exit.c:888 do_exit+0x7d0/0x870() > > > > Jul 14 01:11:41 server01 kernel: [ 595.393256] Hardware name: S5000VSA > > > > Jul 14 01:11:41 server01 kernel: [ 595.393415] Pid: 12037, comm: > > > > apache2 Not tainted 3.2.48-grsec #1 > > > > Jul 14 01:11:41 server01 kernel: [ 595.393577] Call Trace: > > > > Jul 14 01:11:41 server01 kernel: [ 595.393737] [] > > > > warn_slowpath_common+0x7a/0xb0 > > > > Jul 14
Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML (was: [ 00/19] 3.10.1-stable review)
Linus Torvalds wrote: > A small panel discussion with a few people (fiveish?) that have very > different viewpoints, along with baskets of rotten fruit set out on > the tables? That could be fun. And I'm serious, although we might want > to limit the size of the fruit to smaller berries ;) I think that smuggling one of these: http://www.kropserkel.com/horse_head_pillow.htm into Linus's bed might make the point;-). 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 v2 4/4] iio: add configuration option for debug support
On 07/16/2013 01:56 PM, Otavio Salvador wrote: > Signed-off-by: Otavio Salvador Applied to the togreg branch of iio.git in place of v1 > --- > Changes in v2: > - Rework Kconfig help (Lars-Peter Clausen) > > drivers/iio/Kconfig | 7 +++ > drivers/iio/Makefile | 2 ++ > 2 files changed, 9 insertions(+) > > diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig > index 9af763a..e5d1cfc 100644 > --- a/drivers/iio/Kconfig > +++ b/drivers/iio/Kconfig > @@ -12,6 +12,13 @@ menuconfig IIO > > if IIO > > +config IIO_DEBUG > + boolean "Debug support for Industrial I/O" > + depends on DEBUG_KERNEL > + help > + Say "yes" to enable debug messaging (like dev_dbg and pr_debug) > + support in Industrial I/O subsystem and drivers. > + > config IIO_BUFFER > bool "Enable buffer support within IIO" > help > diff --git a/drivers/iio/Makefile b/drivers/iio/Makefile > index 7a3866c..6e43e5b 100644 > --- a/drivers/iio/Makefile > +++ b/drivers/iio/Makefile > @@ -2,6 +2,8 @@ > # Makefile for the industrial I/O core. > # > > +ccflags-$(CONFIG_IIO_DEBUG) := -DDEBUG > + > obj-$(CONFIG_IIO) += industrialio.o > industrialio-y := industrialio-core.o industrialio-event.o inkern.o > industrialio-$(CONFIG_IIO_BUFFER) += industrialio-buffer.o > -- 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] um/configs: don't use devtmpfs in defconfig
Avoid creating lots of bogus devices nodes like /dev/tty* (since User-Mode Linux does not have virtual consoles. Cc: Richard Weinberger Cc: Jeff Dike Signed-off-by: Ramkumar Ramachandra --- Applies on top of the patch I posted earlier. arch/um/configs/i386_defconfig | 3 +-- arch/um/configs/x86_64_defconfig | 3 +-- 2 files changed, 2 insertions(+), 4 deletions(-) diff --git a/arch/um/configs/i386_defconfig b/arch/um/configs/i386_defconfig index 995aecd..93f4f97 100644 --- a/arch/um/configs/i386_defconfig +++ b/arch/um/configs/i386_defconfig @@ -293,8 +293,7 @@ CONFIG_HOSTAUDIO=m # Generic Driver Options # CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug" -CONFIG_DEVTMPFS=y -CONFIG_DEVTMPFS_MOUNT=y +# CONFIG_DEVTMPFS is not set CONFIG_STANDALONE=y CONFIG_PREVENT_FIRMWARE_BUILD=y CONFIG_FW_LOADER=y diff --git a/arch/um/configs/x86_64_defconfig b/arch/um/configs/x86_64_defconfig index f2c6123..17650a6 100644 --- a/arch/um/configs/x86_64_defconfig +++ b/arch/um/configs/x86_64_defconfig @@ -285,8 +285,7 @@ CONFIG_HOSTAUDIO=m # Generic Driver Options # CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug" -CONFIG_DEVTMPFS=y -CONFIG_DEVTMPFS_MOUNT=y +# CONFIG_DEVTMPFS is not set CONFIG_STANDALONE=y CONFIG_PREVENT_FIRMWARE_BUILD=y CONFIG_FW_LOADER=y -- 1.8.3.3.754.g9c3c367 -- 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: [ATTEND] How to act on LKML
On Tue, 16 Jul 2013, Steven Rostedt wrote: > On Tue, 2013-07-16 at 16:49 +0100, Stefano Stabellini wrote: > > > I have been hacking in several different Open Source communities during > > the last few years, including qemu-devel, xen-devel, linux-arm and the > > lkml of course. > > > > The etiquette on the lkml is by far the roughest of them all. It's the > > It's also the largest of them all. > > > "bad neighborhood with guns" of the Open Source world. You never know > > when you are going to get a bullet, but sooner or later you'll get one. > > It just seems that way as it is so large. LKML has the most people and > will also have the biggest conflict in personalities. It just goes with > the territory. Even though the LKML is probably the largest Open Source community, there are other groups out there of similar size. I don't believe that in order to scale up we need to be like this. > > I think that it's hurting Linux and in particular it's hurting > > attracting new talents. > > Then why do we have the largest # of developers than any other Open > Source project? Because Linux is the most widely used kernel, it's everywhere from embedded devices to supercomputers. Many different companies make a business on Linux and pay people to work on it (not FreeBSD or NetBSD). But that's different from what I was saying below. Also not all the sub-groups within the kernel development circles work this way. Or maybe there are just enough brilliant kernel developers that don't care. > > Not just devs for hire but people passionate > > about what they do and eager to become more involved in the project. > > I met more than one good ex-Linux hacker that decided to move to do > > other things because of this. > > Honestly, I think LKML over the years has become more tame. Yeah, back > in 2005 it was rather harsh, but I don't really see that anymore. I > don't see the nasty flame wars going on. Everything seems to be focused > more on the technical side, and there's really very little personal > attacks out there. Sure, with 15,000 emails a month, you get a few. And > Linus will get fed up and burst. But they are really few and far > between. And sometimes, a Linus burst gets things moving along much > faster than being "professional". You think ARM would have gotten their > act together as quick as they did if Linus didn't curse them out and > threaten to stop pulling their crap? I think there is a way to get the point across without cursing. One can be clear and decisive without "bursting". It's easy to mistake cursing on the quality of the code for a personal attack. When HPA wrote "I find it utterly impossible to be offended by it", that might be true for Linus' rants and I also find them humorous sometimes. But unfortunately this kind of behavior is by no means limited to Linus and it's easy to misunderstand, especially when you don't know the person. -- 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: [Ksummit-2013-discuss] When to push bug fixes to mainline
On Tue, Jul 16, 2013 at 06:40:39PM +0200, Takashi Iwai wrote: > Maybe some QA period before the release might help, but who would > care? (Especially under the situation where everybody has own x.y > stable tree?) Hopefully people tracking the upstream stable trees would be throwing any pre-release stuff into their QA processes before it was officially released upstream, though I'd not count on it. signature.asc Description: Digital signature
Re: [PATCH] um/configs: don't use devtmpfs in defconfig
Am 16.07.2013 18:52, schrieb Ramkumar Ramachandra: > Avoid creating lots of bogus devices nodes like /dev/tty* (since > User-Mode Linux does not have virtual consoles. > > Cc: Richard Weinberger > Cc: Jeff Dike > Signed-off-by: Ramkumar Ramachandra > --- NAK. If you don't want devtmpfs, just disable it in your config. Thanks, //richard -- 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: early microcode on amd is broken when no initramfs provided
On Thu, Jul 11, 2013 at 11:05:25PM +0200, Johannes Hirte wrote: > config is attached Ok, I can reproduce the hang with your config but even with: $ grep MICROCODE .config # CONFIG_MICROCODE is not set # CONFIG_MICROCODE_INTEL_EARLY is not set # CONFIG_MICROCODE_AMD_EARLY is not set which means, it cannot be microcode-related. And I'd bet if you wait a minute (yep, it should be exactly 60 seconds) the boot would probably continue. And if so, this is that 60 sec delay where the kernel tries to find firmware. Hmm... -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- 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 7/7] alpha: Fix type compatibility warning for marvel_map_irq
Signed-off-by: Richard Henderson
---
arch/alpha/kernel/sys_marvel.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/alpha/kernel/sys_marvel.c b/arch/alpha/kernel/sys_marvel.c
index 407accc..53d6e4a 100644
--- a/arch/alpha/kernel/sys_marvel.c
+++ b/arch/alpha/kernel/sys_marvel.c
@@ -317,8 +317,9 @@ marvel_init_irq(void)
}
static int
-marvel_map_irq(struct pci_dev *dev, u8 slot, u8 pin)
+marvel_map_irq(const struct pci_dev *cdev, u8 slot, u8 pin)
{
+ struct pci_dev *dev = (struct pci_dev *)dev;
struct pci_controller *hose = dev->sysdata;
struct io7_port *io7_port = hose->sysdata;
struct io7 *io7 = io7_port->io7;
--
1.8.1.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/
[PATCH 2/7] alpha: Eliminate compiler warning from memset macro
Compiling with GCC 4.8 yields several instances of
crypto/vmac.c: In function ‘vmac_final’:
crypto/vmac.c:616:9: warning: value computed is not used [-Wunused-value]
memset(&mac, 0, sizeof(vmac_t));
^
arch/alpha/include/asm/string.h:31:25: note: in definition of macro ‘memset’
? __builtin_memset((s),0,(n)) \
^
Converting the macro to an inline function eliminates this problem.
Signed-off-by: Richard Henderson
---
arch/alpha/include/asm/string.h | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/arch/alpha/include/asm/string.h b/arch/alpha/include/asm/string.h
index b02b8a2..8b478ae 100644
--- a/arch/alpha/include/asm/string.h
+++ b/arch/alpha/include/asm/string.h
@@ -25,12 +25,18 @@ extern void * __constant_c_memset(void *, unsigned long,
size_t);
extern void * __memset(void *, int, size_t);
extern void * memset(void *, int, size_t);
-#define memset(s, c, n)
\
-(__builtin_constant_p(c) \
- ? (__builtin_constant_p(n) && (c) == 0
\
-? __builtin_memset((s),0,(n)) \
-: __constant_c_memset((s),0x0101010101010101UL*(unsigned char)(c),(n))) \
- : __memset((s),(c),(n)))
+extern inline void *memset(void *s, int c, size_t n)
+{
+ if (__builtin_constant_p(c)) {
+ if (__builtin_constant_p(n)) {
+ return __builtin_memset(s, c, n);
+ } else {
+ unsigned long c8 = (c & 0xff) * 0x0101010101010101UL;
+ return __constant_c_memset(s, c8, n);
+ }
+ }
+ return __memset(s, c, n);
+}
#define __HAVE_ARCH_STRCPY
extern char * strcpy(char *,const char *);
--
1.8.1.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/
[PATCH 4/7] alpha: Improve atomic_add_unless
Use ll/sc loops instead of C loops around cmpxchg.
Update the atomic64_add_unless block comment to match the code.
Signed-off-by: Richard Henderson
---
arch/alpha/include/asm/atomic.h | 60 +
1 file changed, 37 insertions(+), 23 deletions(-)
diff --git a/arch/alpha/include/asm/atomic.h b/arch/alpha/include/asm/atomic.h
index c2cbe4f..0dc18fc 100644
--- a/arch/alpha/include/asm/atomic.h
+++ b/arch/alpha/include/asm/atomic.h
@@ -186,17 +186,24 @@ static __inline__ long atomic64_sub_return(long i,
atomic64_t * v)
*/
static __inline__ int __atomic_add_unless(atomic_t *v, int a, int u)
{
- int c, old;
- c = atomic_read(v);
- for (;;) {
- if (unlikely(c == (u)))
- break;
- old = atomic_cmpxchg((v), c, c + (a));
- if (likely(old == c))
- break;
- c = old;
- }
- return c;
+ int c, new, old;
+ smp_mb();
+ __asm__ __volatile__(
+ "1: ldl_l %[old],%[mem]\n"
+ " cmpeq %[old],%[u],%[c]\n"
+ " addl%[old],%[a],%[new]\n"
+ " bne %[c],2f\n"
+ " stl_c %[new],%[mem]\n"
+ " beq %[new],3f\n"
+ "2:\n"
+ ".subsection 2\n"
+ "3: br 1b\n"
+ ".previous"
+ : [old] "=&r"(old), [new] "=&r"(new), [c] "=&r"(c)
+ : [mem] "m"(*v), [a] "rI"(a), [u] "rI"((long)u)
+ : "memory");
+ smp_mb();
+ return old;
}
@@ -207,21 +214,28 @@ static __inline__ int __atomic_add_unless(atomic_t *v,
int a, int u)
* @u: ...unless v is equal to u.
*
* Atomically adds @a to @v, so long as it was not @u.
- * Returns the old value of @v.
+ * Returns true iff @v was not @u.
*/
static __inline__ int atomic64_add_unless(atomic64_t *v, long a, long u)
{
- long c, old;
- c = atomic64_read(v);
- for (;;) {
- if (unlikely(c == (u)))
- break;
- old = atomic64_cmpxchg((v), c, c + (a));
- if (likely(old == c))
- break;
- c = old;
- }
- return c != (u);
+ long c, tmp;
+ smp_mb();
+ __asm__ __volatile__(
+ "1: ldq_l %[tmp],%[mem]\n"
+ " cmpeq %[tmp],%[u],%[c]\n"
+ " addq%[tmp],%[a],%[tmp]\n"
+ " bne %[c],2f\n"
+ " stq_c %[tmp],%[mem]\n"
+ " beq %[tmp],3f\n"
+ "2:\n"
+ ".subsection 2\n"
+ "3: br 1b\n"
+ ".previous"
+ : [tmp] "=&r"(tmp), [c] "=&r"(c)
+ : [mem] "m"(*v), [a] "rI"(a), [u] "rI"(u)
+ : "memory");
+ smp_mb();
+ return !c;
}
#define atomic64_inc_not_zero(v) atomic64_add_unless((v), 1, 0)
--
1.8.1.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/
[PATCH 5/7] alpha: Implement atomic64_dec_if_positive
Signed-off-by: Richard Henderson
---
arch/alpha/Kconfig | 1 +
arch/alpha/include/asm/atomic.h | 28
2 files changed, 29 insertions(+)
diff --git a/arch/alpha/Kconfig b/arch/alpha/Kconfig
index 837a1f2..082d9b4 100644
--- a/arch/alpha/Kconfig
+++ b/arch/alpha/Kconfig
@@ -15,6 +15,7 @@ config ALPHA
select ARCH_WANT_OPTIONAL_GPIOLIB
select ARCH_WANT_IPC_PARSE_VERSION
select ARCH_HAVE_NMI_SAFE_CMPXCHG
+ select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
select GENERIC_SMP_IDLE_THREAD
select GENERIC_CMOS_UPDATE
select GENERIC_STRNCPY_FROM_USER
diff --git a/arch/alpha/include/asm/atomic.h b/arch/alpha/include/asm/atomic.h
index 0dc18fc..78b03ef 100644
--- a/arch/alpha/include/asm/atomic.h
+++ b/arch/alpha/include/asm/atomic.h
@@ -238,6 +238,34 @@ static __inline__ int atomic64_add_unless(atomic64_t *v,
long a, long u)
return !c;
}
+/*
+ * atomic64_dec_if_positive - decrement by 1 if old value positive
+ * @v: pointer of type atomic_t
+ *
+ * The function returns the old value of *v minus 1, even if
+ * the atomic variable, v, was not decremented.
+ */
+static inline long atomic64_dec_if_positive(atomic64_t *v)
+{
+ long old, tmp;
+ smp_mb();
+ __asm__ __volatile__(
+ "1: ldq_l %[old],%[mem]\n"
+ " subq%[old],1,%[tmp]\n"
+ " ble %[old],2f\n"
+ " stq_c %[tmp],%[mem]\n"
+ " beq %[tmp],3f\n"
+ "2:\n"
+ ".subsection 2\n"
+ "3: br 1b\n"
+ ".previous"
+ : [old] "=&r"(old), [tmp] "=&r"(tmp)
+ : [mem] "m"(*v)
+ : "memory");
+ smp_mb();
+ return old - 1;
+}
+
#define atomic64_inc_not_zero(v) atomic64_add_unless((v), 1, 0)
#define atomic_add_negative(a, v) (atomic_add_return((a), (v)) < 0)
--
1.8.1.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/
[PATCH 6/7] alpha: Generate dwarf2 unwind info for various kernel entry points.
Having unwind info past the PALcode generated stack frame makes debugging the kernel significantly easier. Signed-off-by: Richard Henderson --- arch/alpha/kernel/entry.S | 399 +- 1 file changed, 288 insertions(+), 111 deletions(-) diff --git a/arch/alpha/kernel/entry.S b/arch/alpha/kernel/entry.S index f62a994..a969b95 100644 --- a/arch/alpha/kernel/entry.S +++ b/arch/alpha/kernel/entry.S @@ -12,11 +12,32 @@ .text .set noat + .cfi_sections .debug_frame /* Stack offsets. */ #define SP_OFF 184 #define SWITCH_STACK_SIZE 320 +.macro CFI_START_OSF_FRAME func + .align 4 + .globl \func + .type \func,@function +\func: + .cfi_startproc simple + .cfi_return_column 64 + .cfi_def_cfa$sp, 48 + .cfi_rel_offset 64, 8 + .cfi_rel_offset $gp, 16 + .cfi_rel_offset $16, 24 + .cfi_rel_offset $17, 32 + .cfi_rel_offset $18, 40 +.endm + +.macro CFI_END_OSF_FRAME func + .cfi_endproc + .size \func, . - \func +.endm + /* * This defines the normal kernel pt-regs layout. * @@ -27,100 +48,158 @@ * the palcode-provided values are available to the signal handler. */ -#define SAVE_ALL \ - subq$sp, SP_OFF, $sp; \ - stq $0, 0($sp); \ - stq $1, 8($sp); \ - stq $2, 16($sp);\ - stq $3, 24($sp);\ - stq $4, 32($sp);\ - stq $28, 144($sp); \ - lda $2, alpha_mv; \ - stq $5, 40($sp);\ - stq $6, 48($sp);\ - stq $7, 56($sp);\ - stq $8, 64($sp);\ - stq $19, 72($sp); \ - stq $20, 80($sp); \ - stq $21, 88($sp); \ - ldq $2, HAE_CACHE($2); \ - stq $22, 96($sp); \ - stq $23, 104($sp); \ - stq $24, 112($sp); \ - stq $25, 120($sp); \ - stq $26, 128($sp); \ - stq $27, 136($sp); \ - stq $2, 152($sp); \ - stq $16, 160($sp); \ - stq $17, 168($sp); \ +.macro SAVE_ALL + subq$sp, SP_OFF, $sp + .cfi_adjust_cfa_offset SP_OFF + stq $0, 0($sp) + stq $1, 8($sp) + stq $2, 16($sp) + stq $3, 24($sp) + stq $4, 32($sp) + stq $28, 144($sp) + .cfi_rel_offset $0, 0 + .cfi_rel_offset $1, 8 + .cfi_rel_offset $2, 16 + .cfi_rel_offset $3, 24 + .cfi_rel_offset $4, 32 + .cfi_rel_offset $28, 144 + lda $2, alpha_mv + stq $5, 40($sp) + stq $6, 48($sp) + stq $7, 56($sp) + stq $8, 64($sp) + stq $19, 72($sp) + stq $20, 80($sp) + stq $21, 88($sp) + ldq $2, HAE_CACHE($2) + stq $22, 96($sp) + stq $23, 104($sp) + stq $24, 112($sp) + stq $25, 120($sp) + stq $26, 128($sp) + stq $27, 136($sp) + stq $2, 152($sp) + stq $16, 160($sp) + stq $17, 168($sp) stq $18, 176($sp) + .cfi_rel_offset $5, 40 + .cfi_rel_offset $6, 48 + .cfi_rel_offset $7, 56 + .cfi_rel_offset $8, 64 + .cfi_rel_offset $19, 72 + .cfi_rel_offset $20, 80 + .cfi_rel_offset $21, 88 + .cfi_rel_offset $22, 96 + .cfi_rel_offset $23, 104 + .cfi_rel_offset $24, 112 + .cfi_rel_offset $25, 120 + .cfi_rel_offset $26, 128 + .cfi_rel_offset $27, 136 +.endm -#define RESTORE_ALL\ - lda $19, alpha_mv; \ - ldq $0, 0($sp); \ - ldq $1, 8($sp); \ - ldq $2, 16($sp);\ - ldq $3, 24($sp);\ - ldq $21, 152($sp); \ - ldq $20, HAE_CACHE($19);\ - ldq $4, 32($sp);\ - ldq $5, 40($sp);\ - ldq $6, 48($sp);\ - ldq $7, 56($sp);\ - subq$20, $21, $20; \ - ldq $8, 64($sp);\ - beq $20, 99f; \ - ldq $20, HAE_REG($19); \ - stq $21, HAE_CACHE($19);\ - stq $21, 0($20);\ -99:; \ - ldq $19, 72($sp); \ - ldq $20, 80($sp); \ - ldq $21, 88($sp); \ - ldq $22, 96($sp); \ - ldq $23, 104($sp); \ - ldq $24, 112($sp); \ - ldq $25, 120($sp); \ - ldq $26, 128($sp); \ - ldq $27, 136($sp); \ - ldq $28, 144($sp);
[PATCH 3/7] alpha: Modernize lib/mpi/longlong.h
Remove the compile warning for __udiv_qrnnd not having a prototype.
Use the __builtin_alpha_umulh introduced in gcc 4.0.
Signed-off-by: Richard Henderson
---
lib/mpi/longlong.h | 17 +++--
1 file changed, 7 insertions(+), 10 deletions(-)
diff --git a/lib/mpi/longlong.h b/lib/mpi/longlong.h
index d411355..aac5114 100644
--- a/lib/mpi/longlong.h
+++ b/lib/mpi/longlong.h
@@ -151,15 +151,12 @@ do { \
#endif /* __a29k__ */
#if defined(__alpha) && W_TYPE_SIZE == 64
-#define umul_ppmm(ph, pl, m0, m1) \
-do { \
- UDItype __m0 = (m0), __m1 = (m1); \
- __asm__ ("umulh %r1,%2,%0" \
- : "=r" ((UDItype) ph) \
- : "%rJ" (__m0), \
- "rI" (__m1)); \
- (pl) = __m0 * __m1; \
- } while (0)
+#define umul_ppmm(ph, pl, m0, m1) \
+do { \
+ UDItype __m0 = (m0), __m1 = (m1); \
+ (ph) = __builtin_alpha_umulh(__m0, __m1); \
+ (pl) = __m0 * __m1; \
+} while (0)
#define UMUL_TIME 46
#ifndef LONGLONG_STANDALONE
#define udiv_qrnnd(q, r, n1, n0, d) \
@@ -167,7 +164,7 @@ do { UDItype __r; \
(q) = __udiv_qrnnd(&__r, (n1), (n0), (d)); \
(r) = __r; \
} while (0)
-extern UDItype __udiv_qrnnd();
+extern UDItype __udiv_qrnnd(UDItype *, UDItype, UDItype, UDItype);
#define UDIV_TIME 220
#endif /* LONGLONG_STANDALONE */
#endif /* __alpha */
--
1.8.1.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/
[PATCH 1/7] alpha: Add kcmp and finit_module syscalls
Signed-off-by: Richard Henderson --- arch/alpha/include/asm/unistd.h | 3 +-- arch/alpha/include/uapi/asm/unistd.h | 2 ++ arch/alpha/kernel/systbls.S | 2 ++ 3 files changed, 5 insertions(+), 2 deletions(-) diff --git a/arch/alpha/include/asm/unistd.h b/arch/alpha/include/asm/unistd.h index 43baee1..f2c9440 100644 --- a/arch/alpha/include/asm/unistd.h +++ b/arch/alpha/include/asm/unistd.h @@ -3,8 +3,7 @@ #include - -#define NR_SYSCALLS506 +#define NR_SYSCALLS508 #define __ARCH_WANT_OLD_READDIR #define __ARCH_WANT_STAT64 diff --git a/arch/alpha/include/uapi/asm/unistd.h b/arch/alpha/include/uapi/asm/unistd.h index 801d28b..53ae7bb 100644 --- a/arch/alpha/include/uapi/asm/unistd.h +++ b/arch/alpha/include/uapi/asm/unistd.h @@ -467,5 +467,7 @@ #define __NR_sendmmsg 503 #define __NR_process_vm_readv 504 #define __NR_process_vm_writev 505 +#define __NR_kcmp 506 +#define __NR_finit_module 507 #endif /* _UAPI_ALPHA_UNISTD_H */ diff --git a/arch/alpha/kernel/systbls.S b/arch/alpha/kernel/systbls.S index 4284ec7..dca9b3f 100644 --- a/arch/alpha/kernel/systbls.S +++ b/arch/alpha/kernel/systbls.S @@ -524,6 +524,8 @@ sys_call_table: .quad sys_sendmmsg .quad sys_process_vm_readv .quad sys_process_vm_writev /* 505 */ + .quad sys_kcmp + .quad sys_finit_module .size sys_call_table, . - sys_call_table .type sys_call_table, @object -- 1.8.1.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/
[PATCH 0/7] Minor Alpha updates for 3.11
Here's a set of minor updates for arch/alpha that should not be controversial. r~ The following changes since commit 47188d39b5deeebf41f87a02af1b3935866364cf: Merge tag 'ext4_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4 (2013-07-14 21:47:51 -0700) are available in the git repository at: git://github.com/rth7680/linux.git axp-next for you to fetch changes up to fd60fe7052eceab1b1e7c8691263ec2b2634ace0: alpha: Fix type compatibility warning for marvel_map_irq (2013-07-16 09:55:06 -0700) Richard Henderson (7): alpha: Add kcmp and finit_module syscalls alpha: Eliminate compiler warning from memset macro alpha: Modernize lib/mpi/longlong.h alpha: Improve atomic_add_unless alpha: Implement atomic64_dec_if_positive alpha: Generate dwarf2 unwind info for various kernel entry points. alpha: Fix type compatibility warning for marvel_map_irq arch/alpha/Kconfig | 1 + arch/alpha/include/asm/atomic.h | 88 ++-- arch/alpha/include/asm/string.h | 18 +- arch/alpha/include/asm/unistd.h | 3 +- arch/alpha/include/uapi/asm/unistd.h | 2 + arch/alpha/kernel/entry.S| 399 +-- arch/alpha/kernel/sys_marvel.c | 3 +- arch/alpha/kernel/systbls.S | 2 + lib/mpi/longlong.h | 17 +- 9 files changed, 380 insertions(+), 153 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH RFC] lib: Make radix_tree_node_alloc() irq safe
With users of radix_tree_preload() run from interrupt (CFQ is one such
possible user), the following race can happen:
radix_tree_preload()
...
radix_tree_insert()
radix_tree_node_alloc()
if (rtp->nr) {
ret = rtp->nodes[rtp->nr - 1];
...
radix_tree_preload()
...
radix_tree_insert()
radix_tree_node_alloc()
if (rtp->nr) {
ret = rtp->nodes[rtp->nr - 1];
And we give out one radix tree node twice. That clearly results in radix
tree corruption with different results (usually OOPS) depending on which
two users of radix tree race.
Fix the problem by disabling interrupts when working with rtp variable.
In-interrupt user can still deplete our preloaded nodes but at least we
won't corrupt radix trees.
Signed-off-by: Jan Kara
---
lib/radix-tree.c | 19 ---
1 file changed, 16 insertions(+), 3 deletions(-)
There are some questions regarding this patch:
Do we really want to allow in-interrupt users of radix_tree_preload()? CFQ
could certainly do this in older kernels but that particular call site where I
saw the bug hit isn't there anymore so I'm not sure this can really happen with
recent kernels.
Also it is actually harmful to do preloading if you are in interrupt context
anyway. The disadvantage of disallowing radix_tree_preload() in interrupt is
that we would need to tweak radix_tree_node_alloc() to somehow recognize
whether the caller wants it to use preloaded nodes or not and that callers
would have to get it right (although maybe some magic in radix_tree_preload()
could handle that).
Opinions?
diff --git a/lib/radix-tree.c b/lib/radix-tree.c
index e796429..6f1045d 100644
--- a/lib/radix-tree.c
+++ b/lib/radix-tree.c
@@ -209,18 +209,26 @@ radix_tree_node_alloc(struct radix_tree_root *root)
if (!(gfp_mask & __GFP_WAIT)) {
struct radix_tree_preload *rtp;
+ unsigned long flags;
/*
* Provided the caller has preloaded here, we will always
* succeed in getting a node here (and never reach
-* kmem_cache_alloc)
+* kmem_cache_alloc)... unless we race with interrupt also
+* consuming preloaded nodes.
*/
rtp = &__get_cpu_var(radix_tree_preloads);
+ /*
+* Disable interrupts to make sure radix_tree_node_alloc()
+* called from interrupt cannot return the same node as we do.
+*/
+ local_irq_save(flags);
if (rtp->nr) {
ret = rtp->nodes[rtp->nr - 1];
rtp->nodes[rtp->nr - 1] = NULL;
rtp->nr--;
}
+ local_irq_restore(flags);
}
if (ret == NULL)
ret = kmem_cache_alloc(radix_tree_node_cachep, gfp_mask);
@@ -269,6 +277,7 @@ int radix_tree_preload(gfp_t gfp_mask)
struct radix_tree_preload *rtp;
struct radix_tree_node *node;
int ret = -ENOMEM;
+ unsigned long flags;
preempt_disable();
rtp = &__get_cpu_var(radix_tree_preloads);
@@ -278,11 +287,15 @@ int radix_tree_preload(gfp_t gfp_mask)
if (node == NULL)
goto out;
preempt_disable();
+ local_irq_save(flags);
rtp = &__get_cpu_var(radix_tree_preloads);
- if (rtp->nr < ARRAY_SIZE(rtp->nodes))
+ if (rtp->nr < ARRAY_SIZE(rtp->nodes)) {
rtp->nodes[rtp->nr++] = node;
- else
+ local_irq_restore(flags);
+ } else {
+ local_irq_restore(flags);
kmem_cache_free(radix_tree_node_cachep, node);
+ }
}
ret = 0;
out:
--
1.8.1.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] um/configs: don't use devtmpfs in defconfig
Richard Weinberger wrote: > If you don't want devtmpfs, just disable it in your config. I don't understand: is this not a good default? Why is creating bogus devices, confusing systemd, and making um Linux hard to boot desirable? -- 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: [Intel-gfx] [PATCH] drm/i915: fix long-standing SNB regression in power consumption after resume
On Tue, 16 Jul 2013 11:34:25 +0400
Konstantin Khlebnikov wrote:
> I've tested that patch and it really works for me. If you want change
> something for other hardware or
> extend range where forcewake is held prease do it in a separate patch.
> This will be good for bisecting new bugs in the future.
Thanks a ton for finding this Konstantin, it puts us on the right
track.
Can I ask you to test this patch? The theory is that having RC6
enabled messes with the initial programming sequence, so it's probably
best to just shut it off at init until we're done, rather than trying
to forcewake around everywhere we need it.
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_d
index 12ea1a9..9152cba 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9648,6 +9648,9 @@ static void i915_disable_vga(struct drm_device *dev)
void intel_modeset_init_hw(struct drm_device *dev)
{
+ /* BIOS often leaves RC6 enabled, but disable it for hw init */
+ intel_disable_gt_powersave(dev);
+
intel_init_power_well(dev);
intel_prepare_ddi(dev);
--
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] um/configs: don't use devtmpfs in defconfig
Am 16.07.2013 19:06, schrieb Ramkumar Ramachandra: > Richard Weinberger wrote: >> If you don't want devtmpfs, just disable it in your config. > > I don't understand: is this not a good default? Why is creating bogus > devices, confusing systemd, and making um Linux hard to boot > desirable? > Why does this confuse systemd? systemd has also a dependency on devtmpfs. Thanks, //richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 6/7] USB: ohci-at91: add usb_clk for transition to common clk framework
On Tue, Jul 16, 2013 at 05:22:15PM +0200, Boris BREZILLON wrote:
> @@ -41,6 +41,10 @@ extern int usb_disabled(void);
>
> static void at91_start_clock(void)
> {
> + if (uclk) {
if (!IS_ERR(uclk)) {
> + clk_set_rate(uclk, 4800);
> + clk_prepare_enable(uclk);
> + }
> clk_prepare_enable(hclk);
> clk_prepare_enable(iclk);
> clk_prepare_enable(fclk);
> @@ -52,6 +56,8 @@ static void at91_stop_clock(void)
> clk_disable_unprepare(fclk);
> clk_disable_unprepare(iclk);
> clk_disable_unprepare(hclk);
> + if (uclk)
if (!IS_ERR(uclk))
> + clk_disable_unprepare(uclk);
> clocked = 0;
> }
>
> @@ -144,6 +150,11 @@ static int usb_hcd_at91_probe(const struct hc_driver
> *driver,
> goto err2;
> }
>
> + uclk = clk_get(&pdev->dev, "usb_clk");
> + if (IS_ERR(uclk)) {
> + uclk = NULL;
Remove this line.
> + dev_warn(&pdev->dev, "failed to get usb_clk\n");
> + }
> iclk = clk_get(&pdev->dev, "ohci_clk");
> if (IS_ERR(iclk)) {
> dev_err(&pdev->dev, "failed to get ohci_clk\n");
> @@ -212,10 +223,11 @@ static void usb_hcd_at91_remove(struct usb_hcd *hcd,
> release_mem_region(hcd->rsrc_start, hcd->rsrc_len);
> usb_put_hcd(hcd);
>
What if uclk is NULL here?
if (!IS_ERR(uclk))
> + clk_put(uclk);
> clk_put(hclk);
> clk_put(fclk);
> clk_put(iclk);
> - fclk = iclk = hclk = NULL;
> + fclk = iclk = hclk = uclk = NULL;
Don't.
Range of invalid struct clk pointers: those which IS_ERR(clk) returns true.
Therefore, the range of valid struct clk pointers is: _
(answer on a post card, stamped and addressed to...)
--
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: [Update][PATCH] ACPI / video / i915: Remove ACPI backlight if firmware expects Windows 8
On Tue, 2013-07-16 at 17:32 +0400, Igor Gnatenko wrote:
> Hmm. I found regression in user-space. In GNOME (maybe and other DEs) we no
> longer see switch status of backlight.
Yeah, I can duplicate that. Rafael, we have to call
acpi_video_init_brightness() even if we're not going to initialise the
backlight - Thinkpads seem to use this as the trigger for enabling ACPI
notifications rather than handling it in firmware. This seems to do the
job:
diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
index 01b1a25..71865f7 100644
--- a/drivers/acpi/video.c
+++ b/drivers/acpi/video.c
@@ -900,6 +900,9 @@ static void acpi_video_device_find_cap(struct
acpi_video_device *device)
device->cap._DDC = 1;
}
+ if (acpi_video_init_brightness(device))
+ return;
+
if (acpi_video_verify_backlight_support()) {
struct backlight_properties props;
struct pci_dev *pdev;
@@ -909,9 +912,6 @@ static void acpi_video_device_find_cap(struct
acpi_video_device *device)
static int count = 0;
char *name;
- result = acpi_video_init_brightness(device);
- if (result)
- return;
name = kasprintf(GFP_KERNEL, "acpi_video%d", count);
if (!name)
return;
--
Matthew Garrett | mj...@srcf.ucam.org
Re: [PATCH v3 6/7] USB: ohci-at91: add usb_clk for transition to common clk framework
Hello Alan,
On 16/07/2013 18:48, Alan Stern wrote:
On Tue, 16 Jul 2013, Boris BREZILLON wrote:
The AT91 PMC (Power Management Controller) provides an USB clock used by
USB Full Speed host (ohci) and USB Full Speed device (udc).
The usb drivers (ohci and udc) must configure this clock to 48Mhz.
This configuration was formely done in mach-at91/clock.c, but this
implementation will be removed when moving to common clk framework.
This patch add support for usb clock retrieval and configuration, and is
backward compatible with the current at91 clk implementation (if usb clk
is not found, it does not configure/enable the usb clk).
But it does print a warning in the system log, right?
Yes it does.
@@ -144,6 +150,11 @@ static int usb_hcd_at91_probe(const struct hc_driver
*driver,
goto err2;
}
+ uclk = clk_get(&pdev->dev, "usb_clk");
+ if (IS_ERR(uclk)) {
+ uclk = NULL;
+ dev_warn(&pdev->dev, "failed to get usb_clk\n");
+ }
Is this really what you want for backward compatibility?
Here are some proposition to remove the warning message:
1) replace it with a dev_info and change the message:
dev_info(&pdev->dev, "failed to get usb_clk (most likely using old
at91 clk implementation)\n");
2) drop the log and silently ignore the missing clk (I'm not a big fan
of this solution
as it may lead to some errors if we're using new clk implem and the
clock is really missing)
3) rework the current clk_set_rate function to accept clk_set_rate on
usb clk and add clk_lookup entries
for the usb clk (I'm not a big fan of this solution neither as this
modifications will only be used for a short time
until the transition to common clk framework is completed).
Alan Stern
Thanks for your review.
Best Regards,
Boris
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/7] mmc: atmel-mci: prepare clk before calling enable
On Tue, Jul 16, 2013 at 05:06:48PM +0200, Boris BREZILLON wrote:
> @@ -389,9 +391,13 @@ static int atmci_regs_show(struct seq_file *s, void *v)
>* consistent.
>*/
> spin_lock_bh(&host->lock);
> - clk_enable(host->mck);
> + ret = clk_prepare_enable(host->mck);
> + if (ret) {
> + spin_unlock_bh(&host->lock);
> + goto out;
> + }
NAK. This is buggy. clk_prepare() can sleep. Calling clk_prepare()
even via clk_prepare_enable() is a blatent bug.
> memcpy_fromio(buf, host->regs, ATMCI_REGS_SIZE);
> - clk_disable(host->mck);
> + clk_disable_unprepare(host->mck);
> spin_unlock_bh(&host->lock);
Now, given that the CLK API counts enables/disables, having the spin lock
around the clk API calls is utterly pointless. This should be:
ret = clk_prepare_enable(host->mck);
if (ret)
goto out;
spin_lock_bh(&host->lock);
memcpy_fromio(buf, host->regs, ATMCI_REGS_SIZE);
spin_unlock_bh(&host->lock);
clk_disable_unprepare(host->mclk);
or, if you really need to have the clock enabled/disabled within the
spinlock (very very very unlikely):
ret = clk_prepare(host->mck);
if (ret)
goto out;
spin_lock_bh(&host->lock);
ret = clk_enable(host->mck);
if (ret == 0) {
memcpy_fromio(buf, host->regs, ATMCI_REGS_SIZE);
clk_disable(host->mck);
}
spin_unlock_bh(&host->lock);
clk_unprepare(host->mclk);
if (ret)
goto out;
> @@ -1279,7 +1286,7 @@ static void atmci_set_ios(struct mmc_host *mmc, struct
> mmc_ios *ios)
>
> spin_lock_bh(&host->lock);
> if (!host->mode_reg) {
> - clk_enable(host->mck);
> + clk_prepare_enable(host->mck);
Again, buggy - calling clk_prepare beneath a spinlock is illegal.
--
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: [ATTEND] How to act on LKML
On Tue, 2013-07-16 at 17:58 +0100, Stefano Stabellini wrote: > > I think there is a way to get the point across without cursing. > One can be clear and decisive without "bursting". It's easy to mistake > cursing on the quality of the code for a personal attack. What's wrong with cursing? It's just words. The more you curse, the less effect it has. I seldom curse, but when I do, people jump and listen. That's because I seldom curse. I have two teenage daughters. I've never heard them curse at all, and I'm not sure my oldest ever has. From a young age, I taught them that I don't care what they hear, it's what they say that counts. I never sheltered them from "curse" words. I taught them that curse words are for when you really need to make a point and want everyone to listen to you because you are really upset. The less you use them, the more impact they have when you do. They took this to heart, and are saving it up for when something big happens, because I can't get them to curse even when I try :-) -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] um/configs: don't use devtmpfs in defconfig
Richard Weinberger wrote:
> Why does this confuse systemd? systemd has also a dependency on devtmpfs.
See getty@.service, which is a dependency of getty.target:
# On systems without virtual consoles, don't start any getty. (Note
# that serial gettys are covered by serial-getty@.service, not this
# unit
ConditionPathExists=/dev/tty0
No, systemd does not have a hard dependency on devtmpfs. See
src/getty-generator/getty-generator.c:
if (detect_container(NULL) > 0) {
log_debug("Automatically adding console shell.");
if (add_symlink("console-getty.service", "console-getty.service") < 0)
r = EXIT_FAILURE;
/* Don't add any further magic if we are in a container */
goto finish;
}
I can add a rule for detect_vm() and id = "uml" here, so that um Linux
runs console-getty.service out-of-the-box. After I do that,
systemd-vconsole-setup.service will fail precisely because systemd
sees a /dev/tty0 and gets confused.
--
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/
[ANNOUNCE] iproute2 3.10
This is update for iproute2 tools for 3.10 kernel. In addition to the usual array of bug fixes and documentation changes, this release also fixes some important bugs relating to rate control at higher speeds. The 3.10 kernel added a number of new networking features as well for VXLAN and bridging. Iproute2 package is available at: http://kernel.org/pub/linux/utils/net/iproute2/iproute2-3.10.0.tar.gz You can download the source from: git://git.kernel.org/pub/scm/linux/kernel/git/shemminger/iproute2.git --- Adam Borowski (1): ip: fix build failure if time_t is not long int Alexander Duyck (1): iproute2: act_ipt fix xtables breakage on older versions. Amerigo Wang (1): iptunnel: check SIT_ISATAP flag only for SIT tunnel Andreas Henriksson (1): iproute2: fix build failure on sparc due to -Wformat and tv_usec Andrey Vagin (5): ip: set the close-on-exec flag for descriptors ss: handle socket diag request in a separate function ss: create a function to print info about netlink sockets ss: show destination address for netlink sockets ss: Get netlink sockets info via sock-diag (v2) Daniel Borkmann (1): ip: ipv6: add tokenized interface identifier support David L Stevens (1): iproute2: support NTF_ROUTER flag in VXLAN fdb entries David Stevens (1): iproute2: generalize VXLAN forwarding tables Eric Dumazet (4): ss: add fastopen support htb: report overhead attribute get_rate: detect 32bit overflows ss: add more TCP_INFO components John Fastabend (1): iproute2: bridge: fix 'bridge link' setlink/getlink parsing JunweiZhang (1): ipbatch: fix use of 'ip netns exec' Kamil Rytarowski (1): iproute2 patch against GCC 4.8.0 Nicolas Dichtel (5): ip: add missing help about mode argument ip/xfrm: all to set flag XFRM_SA_XFLAG_DONT_ENCAP_DSCP ipnetconf: by default dump all entries ss: allow to retrieve AF_PACKET info via netlink man: describe --bpf option of ss Patric McHardy (1): ip: iplink_vlan: add 802.1ad support Pavel Emelyanov (1): ss: Show inet and unix sockets' shutdown state Rami Rosen (1): ss: replace bfp with bpf in usage(). Sriram Narasimhan (1): iptuntap: allow creation of multi-queue tun/tap device Stephen Hemminger (11): Update headers to 3.10 Add vxlan destination port option vxlan: nag user to set port value add BPF header files vxlan: remove dstport option man: get rid of useless reference to GNU style options htb: fix indentation netns: follow return value conventions of the rest of the code ip: add batch mode to man page Make tc and ip batch mode consistent v3.10.0 Thomas Richter (2): iproute2 vxlan documentation update for bridge command iproute2 vxlan documentation update for ip command Eric S. Raymond (4): First set of manpage markup fixes tc-stab.8: Fix synopsis errors, an invalid escape, and incorrect English usge. In tc-ematch.8, remove no-op .ti requests to prevent translation warnings ip-rule.8: Fix presentational use of .SS. -- 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 3/7] alpha: Modernize lib/mpi/longlong.h
On Tue, 2013-07-16 at 10:04 -0700, Richard Henderson wrote:
> Remove the compile warning for __udiv_qrnnd not having a prototype.
> Use the __builtin_alpha_umulh introduced in gcc 4.0.
Isn't gcc 3.x still a supported compiler?
> diff --git a/lib/mpi/longlong.h b/lib/mpi/longlong.h
[]
> @@ -151,15 +151,12 @@ do { \
> #endif /* __a29k__ */
>
> #if defined(__alpha) && W_TYPE_SIZE == 64
> -#define umul_ppmm(ph, pl, m0, m1) \
> -do { \
> - UDItype __m0 = (m0), __m1 = (m1); \
> - __asm__ ("umulh %r1,%2,%0" \
> - : "=r" ((UDItype) ph) \
> - : "%rJ" (__m0), \
> - "rI" (__m1)); \
> - (pl) = __m0 * __m1; \
> - } while (0)
> +#define umul_ppmm(ph, pl, m0, m1)\
> +do { \
> + UDItype __m0 = (m0), __m1 = (m1); \
> + (ph) = __builtin_alpha_umulh(__m0, __m1); \
> + (pl) = __m0 * __m1; \
> +} while (0)
> #define UMUL_TIME 46
> #ifndef LONGLONG_STANDALONE
> #define udiv_qrnnd(q, r, n1, n0, d) \
> @@ -167,7 +164,7 @@ do { UDItype __r; \
> (q) = __udiv_qrnnd(&__r, (n1), (n0), (d)); \
> (r) = __r; \
> } while (0)
> -extern UDItype __udiv_qrnnd();
> +extern UDItype __udiv_qrnnd(UDItype *, UDItype, UDItype, UDItype);
> #define UDIV_TIME 220
> #endif /* LONGLONG_STANDALONE */
> #endif /* __alpha */
--
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 RFC v4] media: OF: add "sync-on-green-active" property
From: "Lad, Prabhakar" This patch adds 'sync-on-green-active' property as part of endpoint property. Signed-off-by: Lad, Prabhakar --- Changes for v4: 1: Fixed review comments pointed by Sylwester. Changes for v3: 1: Fixed review comments pointed by Laurent and Sylwester. RFC v2 https://patchwork.kernel.org/patch/2578091/ RFC V1 https://patchwork.kernel.org/patch/2572341/ .../devicetree/bindings/media/video-interfaces.txt |3 +++ drivers/media/v4l2-core/v4l2-of.c |4 include/media/v4l2-mediabus.h |2 ++ 3 files changed, 9 insertions(+) diff --git a/Documentation/devicetree/bindings/media/video-interfaces.txt b/Documentation/devicetree/bindings/media/video-interfaces.txt index e022d2d..5186c7e 100644 --- a/Documentation/devicetree/bindings/media/video-interfaces.txt +++ b/Documentation/devicetree/bindings/media/video-interfaces.txt @@ -101,6 +101,9 @@ Optional endpoint properties array contains only one entry. - clock-noncontinuous: a boolean property to allow MIPI CSI-2 non-continuous clock mode. +- sync-on-green-active: polarity field when video synchronization is + Sync-On-Green. When set the driver determines whether it's a normal operation + or inverted operation. Example diff --git a/drivers/media/v4l2-core/v4l2-of.c b/drivers/media/v4l2-core/v4l2-of.c index aa59639..5c4c9f0 100644 --- a/drivers/media/v4l2-core/v4l2-of.c +++ b/drivers/media/v4l2-core/v4l2-of.c @@ -100,6 +100,10 @@ static void v4l2_of_parse_parallel_bus(const struct device_node *node, if (!of_property_read_u32(node, "data-shift", &v)) bus->data_shift = v; + if (!of_property_read_u32(node, "sync-on-green-active", &v)) + flags |= v ? V4L2_MBUS_VIDEO_SOG_ACTIVE_HIGH : + V4L2_MBUS_VIDEO_SOG_ACTIVE_LOW; + bus->flags = flags; } diff --git a/include/media/v4l2-mediabus.h b/include/media/v4l2-mediabus.h index 83ae07e..d47eb81 100644 --- a/include/media/v4l2-mediabus.h +++ b/include/media/v4l2-mediabus.h @@ -40,6 +40,8 @@ #define V4L2_MBUS_FIELD_EVEN_HIGH (1 << 10) /* FIELD = 1/0 - Field1 (odd)/Field2 (even) */ #define V4L2_MBUS_FIELD_EVEN_LOW (1 << 11) +#define V4L2_MBUS_VIDEO_SOG_ACTIVE_HIGH(1 << 12) +#define V4L2_MBUS_VIDEO_SOG_ACTIVE_LOW (1 << 13) /* Serial flags */ /* How many lanes the client can use */ -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] um/configs: don't use devtmpfs in defconfig
Ramkumar Ramachandra wrote: > No, systemd does not have a hard dependency on devtmpfs. Wait, let me double-check that. -- 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 1/2] uio: provide vm access to UIO_MEM_PHYS maps
This makes it possible to let gdb access mappings of the process that is
being debugged.
uio_mmap_logical was moved and uio_vm_ops renamed to group related code
and differentiate to new stuff.
Signed-off-by: Uwe Kleine-König
---
drivers/uio/uio.c | 24 +++-
1 file changed, 15 insertions(+), 9 deletions(-)
diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
index 3b96f18..159cfb3 100644
--- a/drivers/uio/uio.c
+++ b/drivers/uio/uio.c
@@ -630,12 +630,24 @@ static int uio_vma_fault(struct vm_area_struct *vma,
struct vm_fault *vmf)
return 0;
}
-static const struct vm_operations_struct uio_vm_ops = {
+static const struct vm_operations_struct uio_logical_vm_ops = {
.open = uio_vma_open,
.close = uio_vma_close,
.fault = uio_vma_fault,
};
+static int uio_mmap_logical(struct vm_area_struct *vma)
+{
+ vma->vm_flags |= VM_DONTEXPAND | VM_DONTDUMP;
+ vma->vm_ops = &uio_vm_ops;
+ uio_vma_open(vma);
+ return 0;
+}
+
+static const struct vm_operations_struct uio_physical_vm_ops = {
+ .access = generic_access_phys,
+};
+
static int uio_mmap_physical(struct vm_area_struct *vma)
{
struct uio_device *idev = vma->vm_private_data;
@@ -643,6 +655,8 @@ static int uio_mmap_physical(struct vm_area_struct *vma)
if (mi < 0)
return -EINVAL;
+ vma->vm_ops = &uio_physical_vm_ops;
+
vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
return remap_pfn_range(vma,
@@ -652,14 +666,6 @@ static int uio_mmap_physical(struct vm_area_struct *vma)
vma->vm_page_prot);
}
-static int uio_mmap_logical(struct vm_area_struct *vma)
-{
- vma->vm_flags |= VM_DONTEXPAND | VM_DONTDUMP;
- vma->vm_ops = &uio_vm_ops;
- uio_vma_open(vma);
- return 0;
-}
-
static int uio_mmap(struct file *filep, struct vm_area_struct *vma)
{
struct uio_listener *listener = filep->private_data;
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] uio: drop unused vma_count member in uio_device struct
vma_count is used write-only and so fails to be useful. So remove it.
Signed-off-by: Uwe Kleine-König
---
drivers/uio/uio.c | 16
1 file changed, 16 deletions(-)
diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
index 159cfb3..af24bda 100644
--- a/drivers/uio/uio.c
+++ b/drivers/uio/uio.c
@@ -35,7 +35,6 @@ struct uio_device {
atomic_tevent;
struct fasync_struct*async_queue;
wait_queue_head_t wait;
- int vma_count;
struct uio_info *info;
struct kobject *map_dir;
struct kobject *portio_dir;
@@ -593,18 +592,6 @@ static int uio_find_mem_index(struct vm_area_struct *vma)
return -1;
}
-static void uio_vma_open(struct vm_area_struct *vma)
-{
- struct uio_device *idev = vma->vm_private_data;
- idev->vma_count++;
-}
-
-static void uio_vma_close(struct vm_area_struct *vma)
-{
- struct uio_device *idev = vma->vm_private_data;
- idev->vma_count--;
-}
-
static int uio_vma_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
{
struct uio_device *idev = vma->vm_private_data;
@@ -631,8 +618,6 @@ static int uio_vma_fault(struct vm_area_struct *vma, struct
vm_fault *vmf)
}
static const struct vm_operations_struct uio_logical_vm_ops = {
- .open = uio_vma_open,
- .close = uio_vma_close,
.fault = uio_vma_fault,
};
@@ -640,7 +625,6 @@ static int uio_mmap_logical(struct vm_area_struct *vma)
{
vma->vm_flags |= VM_DONTEXPAND | VM_DONTDUMP;
vma->vm_ops = &uio_vm_ops;
- uio_vma_open(vma);
return 0;
}
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/2] Resend of two uio patches
Hello, these two patches were already sent back in April but fell through the cracks. They are not really related, but send in a series because they fail to apply in reverse order. Patch 1 is useful for debugging with gdb, patch 2 is a cleanup. Note that patch 2 is only compile-tested because I don't have an uio driver that uses a non-physical map. Best regards Uwe Uwe Kleine-König (2): uio: provide vm access to UIO_MEM_PHYS maps uio: drop unused vma_count member in uio_device struct drivers/uio/uio.c | 38 ++ 1 file changed, 14 insertions(+), 24 deletions(-) -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/7] perf completion: modernize style
Arnaldo Carvalho de Melo wrote: > Huh? Why would this be more "modern", if both are equivalent, I think > applying the same rules as we have for C code applies here. It's the prevalent style in git.git, and I figured that it was picked up from linux.git but didn't check. Drop this part otherwise. Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] um/configs: don't use devtmpfs in defconfig
Am 16.07.2013 19:20, schrieb Ramkumar Ramachandra: > Ramkumar Ramachandra wrote: >> No, systemd does not have a hard dependency on devtmpfs. > > Wait, let me double-check that. > BTW: I'll not apply any patch to the kernel if the issue can easily fixed in user space, that's the major reason for my NAK. Thanks, //richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 0/5] kdump: Allow ELF header creation in new kernel
On Tue, Jul 16, 2013 at 06:18:10PM +0200, Michael Holzheu wrote: > Hello Andrew, > > Here a new kdump patch series that we have discussed with Vivek and > Hatayama during the last months. > > Besides of the feature described below, this patch series also fixes a > regression on s390 that was introduced with the mmap patches for > /proc/vmcore (git commit 83086978c63afd7c73e1c). > > See also: > http://lists.infradead.org/pipermail/kexec/2013-July/009287.html > > Is it somehow possible to integrate this patch series into 3.11? Hi Andrew, Now /proc/vmcore mmap() patches are in but looks like they will break s390 kdump. mmap() patches use vmalloc() to allocate memory for elf notes and then use read_from_oldmem() to copy notes data from old memory to this newly allocated buffer. read_from_oldmem() in turn uses arch dependent copy_from_oldmem() function. Look like on s390, copy_from_oldmem() can not copy data to vmalloc() space as they drop to real mode. As allocating elf notes code is common both for mmap() and read() path, it will break kdump on s390. Michael has done some cleanups to cope with that but in the process he has also stuffed in the support for zfcpdump and how to deal with HSA region etc. (I am not very happy about it though now. s390 seems to be having so may special case modes and swap logic etc that it is becoming hard to keep track what they are doing. I wished s390 first did some cleanup w.r.t swap logic and deal with mmap() in pure kdump mode and then worry about taking care of zfcpdump). Is it possible to push this series in 3.11 now? I suspect it is late now. Otherwise we might have to revert mmap() patches as in current form they will break s390 kdump. Michael, Hatayama, in case this series can't go in 3.11, do you have other ideas where a small hack fix will allow kdump to work on s390 and we don't have to revert the mmap() patches. Thanks Vivek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/7] perf completion: modernize style
Em Thu, Jul 04, 2013 at 06:11:28PM +0530, Ramkumar Ramachandra escreveu:
> Signed-off-by: Ramkumar Ramachandra
> ---
> tools/perf/bash_completion | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/tools/perf/bash_completion b/tools/perf/bash_completion
> index d2598be..8c04f5d 100644
> --- a/tools/perf/bash_completion
> +++ b/tools/perf/bash_completion
> @@ -7,7 +7,7 @@ function_exists()
> }
>
> function_exists __ltrim_colon_completions ||
> -__ltrim_colon_completions()
> +__ltrim_colon_completions ()
Huh? Why would this be more "modern", if both are equivalent, I think
applying the same rules as we have for C code applies here.
- Arnaldo
> {
> if [[ "$1" == *:* && "$COMP_WORDBREAKS" == *:* ]]; then
> # Remove colon-word prefix from COMPREPLY items
> @@ -20,7 +20,7 @@ __ltrim_colon_completions()
> }
>
> type perf &>/dev/null &&
> -_perf()
> +_perf ()
> {
> local cur prev cmd
>
> --
> 1.8.3.1.643.gebeea52.dirty
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: v3.11-rc1 USB regressions
Hi,
On Tue, Jul 16, 2013 at 08:33:06AM +0200, Daniel Mack wrote:
> > fe4cb0912f8e737f8e4b8b38b9e692f8062f5423
> > usb: musb: gadget: remove hcd initialization
> > (Reverting this fixes error "cdc_ether: probe of 4-1:1.0 failed
> > with error -110" seen on the host side.)
>
> Which role does your musb-based hardware have in this case, and which
> MUSB_* config symbols do you set? You should have USB_MUSB_GADGET.
I have USB_MUSB_DUAL_ROLE set. But also with USB_MUSB_GADGET the result
is the same.
The N900/RX-51 board file sets mode to MUSB_PERIPHERAL (see
mach-omap2/board-rx51.c).
> From 5f33d42f2dffb82d22b83a030f14fe2331a935b7 Mon Sep 17 00:00:00 2001
> From: Daniel Mack
> Date: Tue, 16 Jul 2013 08:19:49 +0200
> Subject: [PATCH] ARM: omap2: fix musb usage for n8x0
>
> Commit b7e2e75a8c ("usb: gadget: drop unused USB_GADGET_MUSB_HDRC")
> dropped a config symbol that was unused by the musb core, but it turns
> out that board support code still had references to it.
>
> As the core now handles both dual role and host-only modes, we can just
> pass MUSB_OTG as mode from board files.
This looks fine, however, I currently cannot test the host mode.
A.
> Signed-off-by: Daniel Mack
> ---
> arch/arm/mach-omap2/board-n8x0.c | 4
> arch/arm/mach-omap2/usb-musb.c | 5 +
> 2 files changed, 1 insertion(+), 8 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/board-n8x0.c
> b/arch/arm/mach-omap2/board-n8x0.c
> index f6eeb87..827d150 100644
> --- a/arch/arm/mach-omap2/board-n8x0.c
> +++ b/arch/arm/mach-omap2/board-n8x0.c
> @@ -122,11 +122,7 @@ static struct musb_hdrc_config musb_config = {
> };
>
> static struct musb_hdrc_platform_data tusb_data = {
> -#ifdef CONFIG_USB_GADGET_MUSB_HDRC
> .mode = MUSB_OTG,
> -#else
> - .mode = MUSB_HOST,
> -#endif
> .set_power = tusb_set_power,
> .min_power = 25, /* x2 = 50 mA drawn from VBUS as peripheral */
> .power = 100, /* Max 100 mA VBUS for host mode */
> diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
> index 8c4de27..bc89723 100644
> --- a/arch/arm/mach-omap2/usb-musb.c
> +++ b/arch/arm/mach-omap2/usb-musb.c
> @@ -38,11 +38,8 @@ static struct musb_hdrc_config musb_config = {
> };
>
> static struct musb_hdrc_platform_data musb_plat = {
> -#ifdef CONFIG_USB_GADGET_MUSB_HDRC
> .mode = MUSB_OTG,
> -#else
> - .mode = MUSB_HOST,
> -#endif
> +
> /* .clock is set dynamically */
> .config = &musb_config,
>
> --
> 1.8.1.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: arm: Only load TLS values when needed
Hi André,
On 15/07/13 18:14, André Hentschel wrote:
From: André Hentschel
This patch intents to reduce loading instructions when the resulting value is
not used.
It's a follow up on a4780adeefd042482f624f5e0d577bf9cdcbb760
Have you done any benchmarking to see that this has any real impact? Or
tested on a !Vv6k system? It looks possible that the only case where
this will perform better is where we're using switch_tls_none or
switch_tls_software (both rare cases, I think) and there's some change
it will make things worse in other cases?
One of the reasons for Russell's suggestion of placing the ldrd (which
became the two ldr instructions you've removed from __switch_to, in
order to maintain building for older cores) where it is was in order to
reduce the chance of pipeline stalls.
As I've pointed out below, there is some risk that changing that has
implications for the v6 only case below (and the v6k case is now more
prone to stalls with !CONFIG_CPU_USE_DOMAINS, but newer cores should
have more advanced scheduling to avoid such issues anyway...)
Signed-off-by: André Hentschel
---
This patch is against Linux 3.11-rc1 (ad81f0545ef01ea651886dddac4bef6cec930092)
Thanks to everyone who helped me with a4780adeefd042482f624f5e0d577bf9cdcbb760
diff --git a/arch/arm/include/asm/tls.h b/arch/arm/include/asm/tls.h
index 83259b8..3742722 100644
--- a/arch/arm/include/asm/tls.h
+++ b/arch/arm/include/asm/tls.h
@@ -3,29 +3,32 @@
#ifdef __ASSEMBLY__
#include
- .macro switch_tls_none, base, tp, tpuser, tmp1, tmp2
+ .macro switch_tls_none, prev, next, tp, tpuser, tmp1, tmp2
.endm
- .macro switch_tls_v6k, base, tp, tpuser, tmp1, tmp2
+ .macro switch_tls_v6k, prev, next, tp, tpuser, tmp1, tmp2
+ ldrd\tp, \tpuser, [\next, #TI_TP_VALUE] @ get the next TLS and
user r/w register
mrc p15, 0, \tmp2, c13, c0, 2 @ get the user r/w register
mcr p15, 0, \tp, c13, c0, 3 @ set TLS register
mcr p15, 0, \tpuser, c13, c0, 2 @ and the user r/w register
- str \tmp2, [\base, #TI_TP_VALUE + 4] @ save it
+ str \tmp2, [\prev, #TI_TP_VALUE + 4] @ save it
.endm
- .macro switch_tls_v6, base, tp, tpuser, tmp1, tmp2
+ .macro switch_tls_v6, prev, next, tp, tpuser, tmp1, tmp2
ldr \tmp1, =elf_hwcap
ldr \tmp1, [\tmp1, #0]
mov \tmp2, #0x0fff
+ ldr \tp, [\next, #TI_TP_VALUE] @ get the next TLS register
tst \tmp1, #HWCAP_TLS @ hardware TLS available?
streq \tp, [\tmp2, #-15] @ set TLS value at 0x0ff0
- mrcne p15, 0, \tmp2, c13, c0, 2 @ get the user r/w register
+ mrcne p15, 0, \tmp2, c13, c0, 2 @ get the previous user r/w
register
+ ldrne \tpuser, [\next, #TI_TP_VALUE + 4] @ get the next user r/w
register
mcrne p15, 0, \tp, c13, c0, 3 @ yes, set TLS register
mcrne p15, 0, \tpuser, c13, c0, 2 @ set user r/w register
Now we've only got one instruction between the store and the load and
risk stalling the pipeline...
Dave M cautiously says "The ancient advice was that one instruction was
enough" but this is very core dependent... I wonder if anyone has a good
idea about whether this is an issue here...?
- strne \tmp2, [\base, #TI_TP_VALUE + 4] @ save it
+ strne \tmp2, [\prev, #TI_TP_VALUE + 4] @ save it
.endm
- .macro switch_tls_software, base, tp, tpuser, tmp1, tmp2
+ .macro switch_tls_software, prev, next, tp, tpuser, tmp1, tmp2
mov \tmp1, #0x0fff
str \tp, [\tmp1, #-15] @ set TLS value at 0x0ff0
.endm
diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
index a39cfc2a1..1484b59 100644
--- a/arch/arm/kernel/entry-armv.S
+++ b/arch/arm/kernel/entry-armv.S
@@ -689,12 +689,10 @@ ENTRY(__switch_to)
THUMB( stmia ip!, {r4 - sl, fp} )@ Store most regs on
stack
THUMB( str sp, [ip], #4 )
THUMB( str lr, [ip], #4 )
- ldr r4, [r2, #TI_TP_VALUE]
- ldr r5, [r2, #TI_TP_VALUE + 4]
#ifdef CONFIG_CPU_USE_DOMAINS
ldr r6, [r2, #TI_CPU_DOMAIN]
#endif
- switch_tls r1, r4, r5, r3, r7
+ switch_tls r1, r2, r4, r5, r3, r7
#if defined(CONFIG_CC_STACKPROTECTOR) && !defined(CONFIG_SMP)
ldr r7, [r2, #TI_TASK]
ldr r8, =__stack_chk_guard
Jonny
--
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] um/configs: don't use devtmpfs in defconfig
Ramkumar Ramachandra wrote: > Ramkumar Ramachandra wrote: >> No, systemd does not have a hard dependency on devtmpfs. > > Wait, let me double-check that. Sorry about the stupidity; devtmpfs is very much a hard dependency. I just realized that CONFIG_VT is on, and can't be turned off (!). See drivers/tty/Kconfig: config VT bool "Virtual terminal" if EXPERT depends on !S390 && !UML Wait, shouldn't it be always off then? *scratches head* -- 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] Documentation: update references to v2.6.x in development-process
On Mon, 15 Jul 2013 19:34:44 -0400 Paul Gortmaker wrote: > The last mainline release of a v2.6.x kernel was back in May 2011. > Here we update references to be 3.x based, which also means updating > some dates and statistics. Ccing the author of the document never hurts :) I actually went through this exercise a while back, but somehow never got around to sending the changes out into the world. Easily distracted, I guess. Anyway, you can put my Acked-by on your changes if you like. > On a similar note, I was thinking about the recent thread on linux-next > where we were indicating that people shouldn't rebase linux-next content > on a whim, and that new devel (vs. bugfix) content shouldn't appear in > the linux-next content during the merge window. There is no question > that the linux-next process is integral to the main flow of patches to > mainline, so I think Documentation/development-process/2.Process (the > same file) should also capture those points in the linux-next section. > Do you have some pre-canned text we can insert there, or should I draft > something up for you to review? Seems useful, I could also try to help with this if you run out of steam. I'd be more inclined to put it into section 7, though, since it's the sort of thing early-stage developers don't normally need to worry about. Thanks, jon -- 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] um/configs: don't use devtmpfs in defconfig
Am 16.07.2013 19:31, schrieb Ramkumar Ramachandra: > Ramkumar Ramachandra wrote: >> Ramkumar Ramachandra wrote: >>> No, systemd does not have a hard dependency on devtmpfs. >> >> Wait, let me double-check that. > > Sorry about the stupidity; devtmpfs is very much a hard dependency. I > just realized that CONFIG_VT is on, and can't be turned off (!). See > drivers/tty/Kconfig: > > config VT > bool "Virtual terminal" if EXPERT > depends on !S390 && !UML > > Wait, shouldn't it be always off then? /me hands you a fresh cup of coffee over. :-) Please note the depends on !UML. Thanks, //richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 08/10] alpha: Always enable the rpcc clocksource for single processor
Don't depend on SMP, just check the number of processors online.
This allows a single distribution kernel to use the clocksource
when run on a single processor machine.
Signed-off-by: Richard Henderson
---
arch/alpha/kernel/time.c | 58 +++-
1 file changed, 28 insertions(+), 30 deletions(-)
diff --git a/arch/alpha/kernel/time.c b/arch/alpha/kernel/time.c
index dbd56ec..cadb82b 100644
--- a/arch/alpha/kernel/time.c
+++ b/arch/alpha/kernel/time.c
@@ -186,6 +186,31 @@ common_init_rtc(void)
init_rtc_irq();
}
+
+/*
+ * The RPCC as a clocksource primitive.
+ *
+ * While we have free-running timecounters running on all CPUs, and we make
+ * a half-hearted attempt in init_rtc_rpcc_info to sync the timecounter
+ * with the wall clock, that initialization isn't kept up-to-date across
+ * different time counters in SMP mode. Therefore we can only use this
+ * method when there's only one CPU enabled.
+ */
+
+static cycle_t read_rpcc(struct clocksource *cs)
+{
+ return rpcc();
+}
+
+static struct clocksource clocksource_rpcc = {
+ .name = "rpcc",
+ .rating = 300,
+ .read = read_rpcc,
+ .mask = CLOCKSOURCE_MASK(32),
+ .flags = CLOCK_SOURCE_IS_CONTINUOUS
+};
+
+
/* Validate a computed cycle counter result against the known bounds for
the given processor core. There's too much brokenness in the way of
timing hardware for any one method to work everywhere. :-(
@@ -296,33 +321,6 @@ rpcc_after_update_in_progress(void)
return rpcc();
}
-#ifndef CONFIG_SMP
-/* Until and unless we figure out how to get cpu cycle counters
- in sync and keep them there, we can't use the rpcc. */
-static cycle_t read_rpcc(struct clocksource *cs)
-{
- cycle_t ret = (cycle_t)rpcc();
- return ret;
-}
-
-static struct clocksource clocksource_rpcc = {
- .name = "rpcc",
- .rating = 300,
- .read = read_rpcc,
- .mask = CLOCKSOURCE_MASK(32),
- .flags = CLOCK_SOURCE_IS_CONTINUOUS
-};
-
-static inline void register_rpcc_clocksource(long cycle_freq)
-{
- clocksource_register_hz(&clocksource_rpcc, cycle_freq);
-}
-#else /* !CONFIG_SMP */
-static inline void register_rpcc_clocksource(long cycle_freq)
-{
-}
-#endif /* !CONFIG_SMP */
-
void __init
time_init(void)
{
@@ -364,20 +362,20 @@ time_init(void)
"and unable to estimate a proper value!\n");
}
+ if (hwrpb->nr_processors == 1)
+ clocksource_register_hz(&clocksource_rpcc, cycle_freq);
+
/* From John Bowman : allow the values
to settle, as the Update-In-Progress bit going low isn't good
enough on some hardware. 2ms is our guess; we haven't found
bogomips yet, but this is close on a 500Mhz box. */
__delay(100);
-
if (HZ > (1<<16)) {
extern void __you_loose (void);
__you_loose();
}
- register_rpcc_clocksource(cycle_freq);
-
state.last_time = cc1;
state.scaled_ticks_per_cycle
= ((unsigned long) HZ << FIX_SHIFT) / cycle_freq;
--
1.8.1.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/
[RFC PATCH 04/10] alpha: Allow HZ to be configured
With the 1024Hz default, we spend 50% of QEMU emulation
processing timer interrupts.
Signed-off-by: Richard Henderson
---
arch/alpha/Kconfig| 36 ++--
arch/alpha/kernel/setup.c | 10 --
arch/alpha/kernel/time.c | 24 +---
3 files changed, 59 insertions(+), 11 deletions(-)
diff --git a/arch/alpha/Kconfig b/arch/alpha/Kconfig
index 2053f215..5991a99 100644
--- a/arch/alpha/Kconfig
+++ b/arch/alpha/Kconfig
@@ -628,9 +628,41 @@ config VERBOSE_MCHECK_ON
Take the default (1) unless you want more control or more info.
+choice
+ prompt "Timer interrupt frequency (HZ)?"
+ default HZ_128 if ALPHA_QEMU
+ default HZ_1200 if ALPHA_RAWHIDE
+ default HZ_1024
+ ---help---
+ The frequency at which timer interrupts occur. A high frequency
+ minimizes latency, whereas a low frequency minimizes overhead of
+ process accounting. The later effect is especially significant
+ when being run under QEMU.
+
+ Note that some Alpha hardware cannot change the interrupt frequency
+ of the timer. If unsure, say 1024 (or 1200 for Rawhide).
+
+ config HZ_32
+ bool "32 Hz"
+ config HZ_64
+ bool "64 Hz"
+ config HZ_128
+ bool "128 Hz"
+ config HZ_256
+ bool "256 Hz"
+ config HZ_1024
+ bool "1024 Hz"
+ config HZ_1200
+ bool "1200 Hz"
+endchoice
+
config HZ
- int
- default 1200 if ALPHA_RAWHIDE
+ int
+ default 32 if HZ_32
+ default 64 if HZ_64
+ default 128 if HZ_128
+ default 256 if HZ_256
+ default 1200 if HZ_1200
default 1024
source "drivers/pci/Kconfig"
diff --git a/arch/alpha/kernel/setup.c b/arch/alpha/kernel/setup.c
index c38d6a1..b20af76 100644
--- a/arch/alpha/kernel/setup.c
+++ b/arch/alpha/kernel/setup.c
@@ -1218,6 +1218,7 @@ show_cpuinfo(struct seq_file *f, void *slot)
char *systype_name;
char *sysvariation_name;
int nr_processors;
+ unsigned long timer_freq;
cpu_index = (unsigned) (cpu->type - 1);
cpu_name = "Unknown";
@@ -1229,6 +1230,12 @@ show_cpuinfo(struct seq_file *f, void *slot)
nr_processors = get_nr_processors(cpu, hwrpb->nr_processors);
+#if CONFIG_HZ == 1024 || CONFIG_HZ == 1200
+ timer_freq = (100UL * hwrpb->intr_freq) / 4096;
+#else
+ timer_freq = 100UL * CONFIG_HZ;
+#endif
+
seq_printf(f, "cpu\t\t\t: Alpha\n"
"cpu model\t\t: %s\n"
"cpu variation\t\t: %ld\n"
@@ -1254,8 +1261,7 @@ show_cpuinfo(struct seq_file *f, void *slot)
(char*)hwrpb->ssn,
est_cycle_freq ? : hwrpb->cycle_freq,
est_cycle_freq ? "est." : "",
- hwrpb->intr_freq / 4096,
- (100 * hwrpb->intr_freq / 4096) % 100,
+ timer_freq / 100, timer_freq % 100,
hwrpb->pagesize,
hwrpb->pa_bits,
hwrpb->max_asn,
diff --git a/arch/alpha/kernel/time.c b/arch/alpha/kernel/time.c
index e336694..7938bf9 100644
--- a/arch/alpha/kernel/time.c
+++ b/arch/alpha/kernel/time.c
@@ -203,16 +203,26 @@ irqreturn_t timer_interrupt(int irq, void *dev)
void __init
common_init_rtc(void)
{
- unsigned char x;
+ unsigned char x, sel = 0;
/* Reset periodic interrupt frequency. */
- x = CMOS_READ(RTC_FREQ_SELECT) & 0x3f;
-/* Test includes known working values on various platforms
- where 0x26 is wrong; we refuse to change those. */
- if (x != 0x26 && x != 0x25 && x != 0x19 && x != 0x06) {
- printk("Setting RTC_FREQ to 1024 Hz (%x)\n", x);
- CMOS_WRITE(0x26, RTC_FREQ_SELECT);
+#if CONFIG_HZ == 1024 || CONFIG_HZ == 1200
+ x = CMOS_READ(RTC_FREQ_SELECT) & 0x3f;
+ /* Test includes known working values on various platforms
+ where 0x26 is wrong; we refuse to change those. */
+ if (x != 0x26 && x != 0x25 && x != 0x19 && x != 0x06) {
+ sel = RTC_REF_CLCK_32KHZ + 6;
}
+#elif CONFIG_HZ == 256 || CONFIG_HZ == 128 || CONFIG_HZ == 64 || CONFIG_HZ ==
32
+ sel = RTC_REF_CLCK_32KHZ + __builtin_ffs(32768 / CONFIG_HZ);
+#else
+# error "Unknown HZ from arch/alpha/Kconfig"
+#endif
+ if (sel) {
+ printk(KERN_INFO "Setting RTC_FREQ to %d Hz (%x)\n",
+ CONFIG_HZ, sel);
+ CMOS_WRITE(sel, RTC_FREQ_SELECT);
+ }
/* Turn on periodic interrupts. */
x = CMOS_READ(RTC_CONTROL);
--
1.8.1.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/
[RFC PATCH 10/10] alpha: Use qemu+cserve provided high-res clock and alarm.
QEMU provides a high-resolution timer and alarm; use this for
a clock source and clock event source when available.
Cc: Thomas Gleixner
Signed-off-by: Richard Henderson
---
arch/alpha/include/asm/pal.h | 14 ++
arch/alpha/kernel/irq_alpha.c | 2 +-
arch/alpha/kernel/proto.h | 2 +-
arch/alpha/kernel/time.c | 106 --
4 files changed, 117 insertions(+), 7 deletions(-)
diff --git a/arch/alpha/include/asm/pal.h b/arch/alpha/include/asm/pal.h
index ccaa49a..5422a47 100644
--- a/arch/alpha/include/asm/pal.h
+++ b/arch/alpha/include/asm/pal.h
@@ -168,5 +168,19 @@ qemu_set_alarm_abs(unsigned long expire)
: "$0", "$18", "$19", "$20", "$21");
}
+static inline unsigned long
+qemu_get_vmtime(void)
+{
+ register unsigned long v0 __asm__("$0");
+ register unsigned long a0 __asm__("$16") = 7;
+
+ asm("call_pal %2 # cserve get_time"
+ : "=r"(v0), "+r"(a0)
+ : "i"(PAL_cserve)
+ : "$17", "$18", "$19", "$20", "$21");
+
+ return v0;
+}
+
#endif /* !__ASSEMBLY__ */
#endif /* __ALPHA_PAL_H */
diff --git a/arch/alpha/kernel/irq_alpha.c b/arch/alpha/kernel/irq_alpha.c
index 49d50e2..00add72 100644
--- a/arch/alpha/kernel/irq_alpha.c
+++ b/arch/alpha/kernel/irq_alpha.c
@@ -214,7 +214,7 @@ process_mcheck_info(unsigned long vector, unsigned long
la_ptr,
*/
struct irqaction timer_irqaction = {
- .handler= timer_interrupt,
+ .handler= rtc_timer_interrupt,
.name = "timer",
};
diff --git a/arch/alpha/kernel/proto.h b/arch/alpha/kernel/proto.h
index 175f7a4..db31ffb 100644
--- a/arch/alpha/kernel/proto.h
+++ b/arch/alpha/kernel/proto.h
@@ -140,7 +140,7 @@ extern void handle_ipi(struct pt_regs *);
/* extern void reset_for_srm(void); */
/* time.c */
-extern irqreturn_t timer_interrupt(int irq, void *dev);
+extern irqreturn_t rtc_timer_interrupt(int irq, void *dev);
extern void init_clockevent(void);
extern void common_init_rtc(void);
extern unsigned long est_cycle_freq;
diff --git a/arch/alpha/kernel/time.c b/arch/alpha/kernel/time.c
index ec45001..3b7601e 100644
--- a/arch/alpha/kernel/time.c
+++ b/arch/alpha/kernel/time.c
@@ -89,7 +89,7 @@ static inline __u32 rpcc(void)
static DEFINE_PER_CPU(struct clock_event_device, cpu_ce);
irqreturn_t
-timer_interrupt(int irq, void *dev)
+rtc_timer_interrupt(int irq, void *dev)
{
int cpu = smp_processor_id();
struct clock_event_device *ce = &per_cpu(cpu_ce, cpu);
@@ -119,8 +119,8 @@ rtc_ce_set_next_event(unsigned long evt, struct
clock_event_device *ce)
return -EINVAL;
}
-void __init
-init_clockevent(void)
+static void __init
+init_rtc_clockevent(void)
{
int cpu = smp_processor_id();
struct clock_event_device *ce = &per_cpu(cpu_ce, cpu);
@@ -137,6 +137,83 @@ init_clockevent(void)
clockevents_config_and_register(ce, CONFIG_HZ, 0, 0);
}
+
+/*
+ * The QEMU clock as a clocksource primitive.
+ */
+
+static cycle_t
+qemu_cs_read(struct clocksource *cs)
+{
+ return qemu_get_vmtime();
+}
+
+static struct clocksource qemu_cs = {
+ .name = "qemu",
+ .rating = 400,
+ .read = qemu_cs_read,
+ .mask = CLOCKSOURCE_MASK(64),
+ .flags = CLOCK_SOURCE_IS_CONTINUOUS,
+ .mult = 1,
+ .shift = 0,
+ .max_idle_ns= LONG_MAX
+};
+
+/*
+ * The QEMU clock and alarm as a clock_event_device primitive.
+ */
+
+
+static void
+qemu_ce_set_mode(enum clock_event_mode mode, struct clock_event_device *ce)
+{
+ /* The mode member of CE is updated for us in generic code.
+ Just make sure that the event is disabled. */
+ qemu_set_alarm_abs(0);
+}
+
+static int
+qemu_ce_set_next_event(unsigned long evt, struct clock_event_device *ce)
+{
+ qemu_set_alarm_rel(evt);
+ return 0;
+}
+
+static irqreturn_t
+qemu_timer_interrupt(int irq, void *dev)
+{
+ int cpu = smp_processor_id();
+ struct clock_event_device *ce = &per_cpu(cpu_ce, cpu);
+
+ ce->event_handler(ce);
+ return IRQ_HANDLED;
+}
+
+static void __init
+init_qemu_clockevent(void)
+{
+ int cpu = smp_processor_id();
+ struct clock_event_device *ce = &per_cpu(cpu_ce, cpu);
+
+ *ce = (struct clock_event_device){
+ .name = "qemu",
+ .features = CLOCK_EVT_FEAT_ONESHOT,
+ .min_delta_ns = 1000,
+ .min_delta_ticks = 1000,
+ .max_delta_ns = LONG_MAX,
+ .max_delta_ticks = LONG_MAX,
+ .mult = 1,
+ .shift = 0,
+ .rating = 400,
+ .cpumask = cpumask_of(cpu),
+ .set_mode = qemu_ce_set_mode,
+ .set_next_event = qemu_ce_set_next_event,
+ };
+
+ clockevents_register_device(ce);
+}
+
+
void __init
common_init
[RFC PATCH 06/10] alpha: Reorganize rtc handling
Discontinue use of GENERIC_CMOS_UPDATE; rely on the RTC subsystem. The marvel platform requires that the rtc only be touched from the boot cpu. This had been partially implemented with hooks for get/set_rtc_time, but read/update_persistent_clock were not handled. Fixed by adding an rtc_set_mmss hook along the way. We had read_persistent_clock managing the epoch against which the rtc hw is based, but this didn't apply to get_rtc_time or set_rtc_time. This resulted in incorrect values when hwclock(8) gets involved. Allow the epoch to be set from the kernel command-line, overriding the autodetection, which is doomed to fail in 2028. Further, by implementing the rtc ioctl function, we can expose this epoch to userland. Elide the alarm functions that RTC_DRV_CMOS implements. This was highly questionable on Alpha, since the interrupt is used by the system timer. Cc: rtc-li...@googlegroups.com Signed-off-by: Richard Henderson --- arch/alpha/Kconfig | 1 - arch/alpha/include/asm/machvec.h | 4 +- arch/alpha/include/asm/rtc.h | 11 -- arch/alpha/kernel/Makefile | 1 + arch/alpha/kernel/machvec_impl.h | 5 +- arch/alpha/kernel/proto.h| 9 ++ arch/alpha/kernel/rtc.c | 323 +++ arch/alpha/kernel/sys_jensen.c | 2 - arch/alpha/kernel/sys_marvel.c | 55 +-- arch/alpha/kernel/time.c | 146 +- drivers/rtc/Kconfig | 10 +- 11 files changed, 346 insertions(+), 221 deletions(-) create mode 100644 arch/alpha/kernel/rtc.c diff --git a/arch/alpha/Kconfig b/arch/alpha/Kconfig index 5991a99..7e268cf 100644 --- a/arch/alpha/Kconfig +++ b/arch/alpha/Kconfig @@ -17,7 +17,6 @@ config ALPHA select ARCH_HAVE_NMI_SAFE_CMPXCHG select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE select GENERIC_SMP_IDLE_THREAD - select GENERIC_CMOS_UPDATE select GENERIC_STRNCPY_FROM_USER select GENERIC_STRNLEN_USER select HAVE_MOD_ARCH_SPECIFIC diff --git a/arch/alpha/include/asm/machvec.h b/arch/alpha/include/asm/machvec.h index 4ac9016..75cb364 100644 --- a/arch/alpha/include/asm/machvec.h +++ b/arch/alpha/include/asm/machvec.h @@ -33,6 +33,7 @@ struct alpha_machine_vector int nr_irqs; int rtc_port; + int rtc_boot_cpu_only; unsigned int max_asn; unsigned long max_isa_dma_address; unsigned long irq_probe_mask; @@ -95,9 +96,6 @@ struct alpha_machine_vector struct _alpha_agp_info *(*agp_info)(void); - unsigned int (*rtc_get_time)(struct rtc_time *); - int (*rtc_set_time)(struct rtc_time *); - const char *vector_name; /* NUMA information */ diff --git a/arch/alpha/include/asm/rtc.h b/arch/alpha/include/asm/rtc.h index d70408d..f71c3b0 100644 --- a/arch/alpha/include/asm/rtc.h +++ b/arch/alpha/include/asm/rtc.h @@ -1,12 +1 @@ -#ifndef _ALPHA_RTC_H -#define _ALPHA_RTC_H - -#if defined(CONFIG_ALPHA_MARVEL) && defined(CONFIG_SMP) \ - || defined(CONFIG_ALPHA_GENERIC) -# define get_rtc_time alpha_mv.rtc_get_time -# define set_rtc_time alpha_mv.rtc_set_time -#endif - #include - -#endif diff --git a/arch/alpha/kernel/Makefile b/arch/alpha/kernel/Makefile index 84ec46b..0d54650 100644 --- a/arch/alpha/kernel/Makefile +++ b/arch/alpha/kernel/Makefile @@ -16,6 +16,7 @@ obj-$(CONFIG_PCI) += pci.o pci_iommu.o pci-sysfs.o obj-$(CONFIG_SRM_ENV) += srm_env.o obj-$(CONFIG_MODULES) += module.o obj-$(CONFIG_PERF_EVENTS) += perf_event.o +obj-$(CONFIG_RTC_DRV_ALPHA) += rtc.o ifdef CONFIG_ALPHA_GENERIC diff --git a/arch/alpha/kernel/machvec_impl.h b/arch/alpha/kernel/machvec_impl.h index 7fa6248..f54bdf6 100644 --- a/arch/alpha/kernel/machvec_impl.h +++ b/arch/alpha/kernel/machvec_impl.h @@ -43,10 +43,7 @@ #define CAT1(x,y) x##y #define CAT(x,y) CAT1(x,y) -#define DO_DEFAULT_RTC \ - .rtc_port = 0x70, \ - .rtc_get_time = common_get_rtc_time, \ - .rtc_set_time = common_set_rtc_time +#define DO_DEFAULT_RTC .rtc_port = 0x70 #define DO_EV4_MMU \ .max_asn = EV4_MAX_ASN,\ diff --git a/arch/alpha/kernel/proto.h b/arch/alpha/kernel/proto.h index d3e52d3..b0c8498 100644 --- a/arch/alpha/kernel/proto.h +++ b/arch/alpha/kernel/proto.h @@ -144,8 +144,17 @@ extern void smp_percpu_timer_interrupt(struct pt_regs *); extern irqreturn_t timer_interrupt(int irq, void *dev); extern void common_init_rtc(void); extern unsigned long est_cycle_freq; + +/* rtc.c */ +#ifdef CONFIG_RTC_DRV_ALPHA extern unsigned int common_get_rtc_time(struct rtc_time *time); extern int common_set_rtc_time(struct rtc_time *time); +extern int common_set_rtc_mmss(unsigned long); +#else +# define common_get_rtc_time NULL +# define common_set_rtc_time NULL +# define common_set_rtc_mmss NULL +#endif /* smc37c93x.c */ extern void SMC93x_Init(void); diff --git a/a
[RFC PATCH 02/10] alpha: Notice if we're being run under QEMU
When building a generic kernel, do a run-time check on the serial number, like we do for MILO. When building a custom kernel, make this a configure-time check. Signed-off-by: Richard Henderson --- arch/alpha/Kconfig | 14 ++ arch/alpha/include/asm/machvec.h | 18 -- arch/alpha/kernel/setup.c| 13 - 3 files changed, 38 insertions(+), 7 deletions(-) diff --git a/arch/alpha/Kconfig b/arch/alpha/Kconfig index 082d9b4..2053f215 100644 --- a/arch/alpha/Kconfig +++ b/arch/alpha/Kconfig @@ -488,6 +488,20 @@ config VGA_HOSE which always have multiple hoses, and whose consoles support it. +config ALPHA_QEMU + bool "Run under QEMU emulation" + depends on !ALPHA_GENERIC + ---help--- + Assume the presence of special features supported by QEMU PALcode + that reduce the overhead of system emulation. + + Generic kernels will auto-detect QEMU. But when building a + system-specific kernel, the assumption is that we want to + elimiate as many runtime tests as possible. + + If unsure, say N. + + config ALPHA_SRM bool "Use SRM as bootloader" if ALPHA_CABRIOLET || ALPHA_AVANTI_CH || ALPHA_EB64P || ALPHA_PC164 || ALPHA_TAKARA || ALPHA_EB164 || ALPHA_ALCOR || ALPHA_MIATA || ALPHA_LX164 || ALPHA_SX164 || ALPHA_NAUTILUS || ALPHA_NONAME depends on TTY diff --git a/arch/alpha/include/asm/machvec.h b/arch/alpha/include/asm/machvec.h index 72dbf23..4ac9016 100644 --- a/arch/alpha/include/asm/machvec.h +++ b/arch/alpha/include/asm/machvec.h @@ -126,13 +126,19 @@ extern struct alpha_machine_vector alpha_mv; #ifdef CONFIG_ALPHA_GENERIC extern int alpha_using_srm; +extern int alpha_using_qemu; #else -#ifdef CONFIG_ALPHA_SRM -#define alpha_using_srm 1 -#else -#define alpha_using_srm 0 -#endif +# ifdef CONFIG_ALPHA_SRM +# define alpha_using_srm 1 +# else +# define alpha_using_srm 0 +# endif +# ifdef CONFIG_ALPHA_QEMU +# define alpha_using_qemu 1 +# else +# define alpha_using_qemu 0 +# endif #endif /* GENERIC */ -#endif +#endif /* __KERNEL__ */ #endif /* __ALPHA_MACHVEC_H */ diff --git a/arch/alpha/kernel/setup.c b/arch/alpha/kernel/setup.c index 9e3107cc5..c38d6a1 100644 --- a/arch/alpha/kernel/setup.c +++ b/arch/alpha/kernel/setup.c @@ -115,10 +115,17 @@ unsigned long alpha_agpgart_size = DEFAULT_AGP_APER_SIZE; #ifdef CONFIG_ALPHA_GENERIC struct alpha_machine_vector alpha_mv; +#endif + +#ifndef alpha_using_srm int alpha_using_srm; EXPORT_SYMBOL(alpha_using_srm); #endif +#ifndef alpha_using_qemu +int alpha_using_qemu; +#endif + static struct alpha_machine_vector *get_sysvec(unsigned long, unsigned long, unsigned long); static struct alpha_machine_vector *get_sysvec_byname(const char *); @@ -529,11 +536,15 @@ setup_arch(char **cmdline_p) atomic_notifier_chain_register(&panic_notifier_list, &alpha_panic_block); -#ifdef CONFIG_ALPHA_GENERIC +#ifndef alpha_using_srm /* Assume that we've booted from SRM if we haven't booted from MILO. Detect the later by looking for "MILO" in the system serial nr. */ alpha_using_srm = strncmp((const char *)hwrpb->ssn, "MILO", 4) != 0; #endif +#ifndef alpha_using_qemu + /* Similarly, look for QEMU. */ + alpha_using_qemu = strstr((const char *)hwrpb->ssn, "QEMU") != 0; +#endif /* If we are using SRM, we want to allow callbacks as early as possible, so do this NOW, and then -- 1.8.1.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/
[RFC PATCH 00/10] Alpha support for QEMU
While there are 3 patches in this series that are specifically related to QEMU, there are 3 more that significantly re-architect generic parts of arch/alpha that hopefully bring them more into line with current linux-kernel design, and 2 more that seem like they ought to work generically, but ought to be tested on real hardware. In particular: 1/10: Ought to have no effect on real hw, since the "interrupt handling" was a printk. 5/10: Ought to work, and result in cooler cpus, on real hardware. That said, excersising parts of random PALcodes on misc machines is surely doomed to failure. I can well imagine that we'll need some sort of black/white-list for the various machines. 6/10: Ought to work better for Marvel, since more accesses to the RTC are now being vectored across the smp-call. OTOH, I could have introduced a silly typo somewhere. 9/10: Probably the most significant cleanup, and the one most likely to have something subtle go wrong on the various machines. The series seems pretty stable under QEMU, but I have no real hardware on which to test -- the whole reason I'm interested in QEMU of course. So I'm hoping that someone will notice this and help me out with testing. In addition, if folks more familiar with the various kernel/time or driver/rtc interfaces spot anything I'm doing wrong in the rewrite, please let me know. r~ Richard Henderson (10): alpha: Don't if-out dp264_device_interrupt. alpha: Notice if we're being run under QEMU alpha: Force the user-visible HZ to a constant 1024. alpha: Allow HZ to be configured alpha: Primitive support for CPU power down. alpha: Reorganize rtc handling alpha: Add an rtc driver for the qemu wallclock PALcall alpha: Always enable the rpcc clocksource for single processor alpha: Switch to GENERIC_CLOCKEVENTS alpha: Use qemu+cserve provided high-res clock and alarm. arch/alpha/Kconfig | 52 - arch/alpha/include/asm/machvec.h| 22 +- arch/alpha/include/asm/pal.h| 71 +++ arch/alpha/include/asm/param.h | 8 +- arch/alpha/include/asm/rtc.h| 11 - arch/alpha/include/uapi/asm/pal.h | 1 + arch/alpha/include/uapi/asm/param.h | 7 - arch/alpha/kernel/Makefile | 2 +- arch/alpha/kernel/irq_alpha.c | 16 +- arch/alpha/kernel/machvec_impl.h| 5 +- arch/alpha/kernel/process.c | 15 ++ arch/alpha/kernel/proto.h | 13 +- arch/alpha/kernel/rtc.c | 374 + arch/alpha/kernel/setup.c | 23 +- arch/alpha/kernel/smp.c | 33 +-- arch/alpha/kernel/sys_dp264.c | 8 - arch/alpha/kernel/sys_jensen.c | 2 - arch/alpha/kernel/sys_marvel.c | 55 + arch/alpha/kernel/time.c| 403 arch/alpha/kernel/traps.c | 12 ++ drivers/rtc/Kconfig | 17 +- 21 files changed, 767 insertions(+), 383 deletions(-) create mode 100644 arch/alpha/kernel/rtc.c -- 1.8.1.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/
[RFC PATCH 05/10] alpha: Primitive support for CPU power down.
Use WTINT to wait for the next interrupt. Squash the WTINT call
if the PALcode doesn't support it (e.g. MILO). No attempt is yet
made to skip clock ticks during normal scheduling in order to stay
in power down mode longer.
Signed-off-by: Richard Henderson
---
arch/alpha/include/asm/pal.h | 1 +
arch/alpha/include/uapi/asm/pal.h | 1 +
arch/alpha/kernel/process.c | 15 +++
arch/alpha/kernel/traps.c | 12
4 files changed, 29 insertions(+)
diff --git a/arch/alpha/include/asm/pal.h b/arch/alpha/include/asm/pal.h
index 6fcd2b5..e78ec9b 100644
--- a/arch/alpha/include/asm/pal.h
+++ b/arch/alpha/include/asm/pal.h
@@ -89,6 +89,7 @@ __CALL_PAL_W1(wrmces, unsigned long);
__CALL_PAL_RW2(wrperfmon, unsigned long, unsigned long, unsigned long);
__CALL_PAL_W1(wrusp, unsigned long);
__CALL_PAL_W1(wrvptptr, unsigned long);
+__CALL_PAL_RW1(wtint, unsigned long, unsigned long);
/*
* TB routines..
diff --git a/arch/alpha/include/uapi/asm/pal.h
b/arch/alpha/include/uapi/asm/pal.h
index 3c0ce08..dfc8140 100644
--- a/arch/alpha/include/uapi/asm/pal.h
+++ b/arch/alpha/include/uapi/asm/pal.h
@@ -46,6 +46,7 @@
#define PAL_rdusp 58
#define PAL_whami 60
#define PAL_retsys 61
+#define PAL_wtint 62
#define PAL_rti63
diff --git a/arch/alpha/kernel/process.c b/arch/alpha/kernel/process.c
index f2360a7..3130f13 100644
--- a/arch/alpha/kernel/process.c
+++ b/arch/alpha/kernel/process.c
@@ -46,6 +46,21 @@
void (*pm_power_off)(void) = machine_power_off;
EXPORT_SYMBOL(pm_power_off);
+/*
+ * Sleep the CPU.
+ * EV6, LCA45 and QEMU know how to power down, skipping N timer interrupts.
+ */
+void arch_cpu_idle(void)
+{
+ wtint(0);
+ local_irq_enable();
+}
+
+void arch_cpu_idle_dead(void)
+{
+ wtint(INT_MAX);
+}
+
struct halt_info {
int mode;
char *restart_cmd;
diff --git a/arch/alpha/kernel/traps.c b/arch/alpha/kernel/traps.c
index affccb9..991f6c3 100644
--- a/arch/alpha/kernel/traps.c
+++ b/arch/alpha/kernel/traps.c
@@ -243,6 +243,18 @@ do_entIF(unsigned long type, struct pt_regs *regs)
(const char *)(data[1] | (long)data[2] << 32),
data[0]);
}
+ if (type == 4) {
+ /* If CALL_PAL WTINT is not supported by the PALcode,
+ "emulate" it by overwriting the insn. */
+ unsigned int *pinsn
+ = (unsigned int *) regs->pc - 1;
+ if (*pinsn == PAL_wtint) {
+ *pinsn = 0x47e01400; /* mov 0,$0 */
+ imb();
+ regs->r0 = 0;
+ return;
+ }
+ }
die_if_kernel((type == 1 ? "Kernel Bug" : "Instruction fault"),
regs, type, NULL);
}
--
1.8.1.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/
[RFC PATCH 09/10] alpha: Switch to GENERIC_CLOCKEVENTS
This allows us to get rid of some hacky code for SMP. Get rid of
some cycle counter hackery that's now handled by generic code via
clocksource + clock_event_device objects.
Cc: Thomas Gleixner
Signed-off-by: Richard Henderson
---
arch/alpha/Kconfig| 1 +
arch/alpha/kernel/irq_alpha.c | 14 --
arch/alpha/kernel/proto.h | 2 +-
arch/alpha/kernel/smp.c | 33 ++---
arch/alpha/kernel/time.c | 111 ++
5 files changed, 52 insertions(+), 109 deletions(-)
diff --git a/arch/alpha/Kconfig b/arch/alpha/Kconfig
index 7e268cf..5b57618 100644
--- a/arch/alpha/Kconfig
+++ b/arch/alpha/Kconfig
@@ -16,6 +16,7 @@ config ALPHA
select ARCH_WANT_IPC_PARSE_VERSION
select ARCH_HAVE_NMI_SAFE_CMPXCHG
select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
+ select GENERIC_CLOCKEVENTS
select GENERIC_SMP_IDLE_THREAD
select GENERIC_STRNCPY_FROM_USER
select GENERIC_STRNLEN_USER
diff --git a/arch/alpha/kernel/irq_alpha.c b/arch/alpha/kernel/irq_alpha.c
index f433fc1..49d50e2 100644
--- a/arch/alpha/kernel/irq_alpha.c
+++ b/arch/alpha/kernel/irq_alpha.c
@@ -66,21 +66,7 @@ do_entInt(unsigned long type, unsigned long vector,
break;
case 1:
old_regs = set_irq_regs(regs);
-#ifdef CONFIG_SMP
- {
- long cpu;
-
- smp_percpu_timer_interrupt(regs);
- cpu = smp_processor_id();
- if (cpu != boot_cpuid) {
- kstat_incr_irqs_this_cpu(RTC_IRQ, irq_to_desc(RTC_IRQ));
- } else {
- handle_irq(RTC_IRQ);
- }
- }
-#else
handle_irq(RTC_IRQ);
-#endif
set_irq_regs(old_regs);
return;
case 2:
diff --git a/arch/alpha/kernel/proto.h b/arch/alpha/kernel/proto.h
index b0c8498..175f7a4 100644
--- a/arch/alpha/kernel/proto.h
+++ b/arch/alpha/kernel/proto.h
@@ -135,13 +135,13 @@ extern void unregister_srm_console(void);
/* smp.c */
extern void setup_smp(void);
extern void handle_ipi(struct pt_regs *);
-extern void smp_percpu_timer_interrupt(struct pt_regs *);
/* bios32.c */
/* extern void reset_for_srm(void); */
/* time.c */
extern irqreturn_t timer_interrupt(int irq, void *dev);
+extern void init_clockevent(void);
extern void common_init_rtc(void);
extern unsigned long est_cycle_freq;
diff --git a/arch/alpha/kernel/smp.c b/arch/alpha/kernel/smp.c
index 7b60834..1a8a10e 100644
--- a/arch/alpha/kernel/smp.c
+++ b/arch/alpha/kernel/smp.c
@@ -138,9 +138,11 @@ smp_callin(void)
/* Get our local ticker going. */
smp_setup_percpu_timer(cpuid);
+ init_clockevent();
/* Call platform-specific callin, if specified */
- if (alpha_mv.smp_callin) alpha_mv.smp_callin();
+ if (alpha_mv.smp_callin)
+ alpha_mv.smp_callin();
/* All kernel threads share the same mm context. */
atomic_inc(&init_mm.mm_count);
@@ -497,35 +499,6 @@ smp_cpus_done(unsigned int max_cpus)
((bogosum + 2500) / (5000/HZ)) % 100);
}
-
-void
-smp_percpu_timer_interrupt(struct pt_regs *regs)
-{
- struct pt_regs *old_regs;
- int cpu = smp_processor_id();
- unsigned long user = user_mode(regs);
- struct cpuinfo_alpha *data = &cpu_data[cpu];
-
- old_regs = set_irq_regs(regs);
-
- /* Record kernel PC. */
- profile_tick(CPU_PROFILING);
-
- if (!--data->prof_counter) {
- /* We need to make like a normal interrupt -- otherwise
- timer interrupts ignore the global interrupt lock,
- which would be a Bad Thing. */
- irq_enter();
-
- update_process_times(user);
-
- data->prof_counter = data->prof_multiplier;
-
- irq_exit();
- }
- set_irq_regs(old_regs);
-}
-
int
setup_profiling_timer(unsigned int multiplier)
{
diff --git a/arch/alpha/kernel/time.c b/arch/alpha/kernel/time.c
index cadb82b..ec45001 100644
--- a/arch/alpha/kernel/time.c
+++ b/arch/alpha/kernel/time.c
@@ -42,6 +42,7 @@
#include
#include
#include
+#include
#include "proto.h"
#include "irq_impl.h"
@@ -49,25 +50,6 @@
DEFINE_SPINLOCK(rtc_lock);
EXPORT_SYMBOL(rtc_lock);
-#define TICK_SIZE (tick_nsec / 1000)
-
-/*
- * Shift amount by which scaled_ticks_per_cycle is scaled. Shifting
- * by 48 gives us 16 bits for HZ while keeping the accuracy good even
- * for large CPU clock rates.
- */
-#define FIX_SHIFT 48
-
-/* lump static variables together for more efficient access: */
-static struct {
- /* cycle counter last time it got invoked */
- __u32 last_time;
- /* ticks/cycle * 2^48 */
- unsigned long scaled_ticks_per_cycle;
- /* partial unused tick */
- unsigned long partial_tick;
-} state;
-
unsigned long est_cycle_freq;
#ifdef CONFIG_IRQ_WORK
@@ -98,49 +80,63 @@ static inline
[RFC PATCH 03/10] alpha: Force the user-visible HZ to a constant 1024.
This kernel/user split was done long ago for other architectures. Signed-off-by: Richard Henderson --- arch/alpha/include/asm/param.h | 8 +--- arch/alpha/include/uapi/asm/param.h | 7 --- 2 files changed, 5 insertions(+), 10 deletions(-) diff --git a/arch/alpha/include/asm/param.h b/arch/alpha/include/asm/param.h index bf46af5..a5b68b2 100644 --- a/arch/alpha/include/asm/param.h +++ b/arch/alpha/include/asm/param.h @@ -3,7 +3,9 @@ #include -#define HZ CONFIG_HZ -#define USER_HZHZ -# define CLOCKS_PER_SECHZ /* frequency at which times() counts */ +# undef HZ +# define HZCONFIG_HZ +# define USER_HZ 1024 +# define CLOCKS_PER_SECUSER_HZ /* frequency at which times() counts */ + #endif /* _ASM_ALPHA_PARAM_H */ diff --git a/arch/alpha/include/uapi/asm/param.h b/arch/alpha/include/uapi/asm/param.h index 29daed8..dbcd983 100644 --- a/arch/alpha/include/uapi/asm/param.h +++ b/arch/alpha/include/uapi/asm/param.h @@ -1,13 +1,7 @@ #ifndef _UAPI_ASM_ALPHA_PARAM_H #define _UAPI_ASM_ALPHA_PARAM_H -/* ??? Gross. I don't want to parameterize this, and supposedly the - hardware ignores reprogramming. We also need userland buy-in to the - change in HZ, since this is visible in the wait4 resources etc. */ - -#ifndef __KERNEL__ #define HZ 1024 -#endif #define EXEC_PAGESIZE 8192 @@ -17,5 +11,4 @@ #define MAXHOSTNAMELEN 64 /* max length of hostname */ - #endif /* _UAPI_ASM_ALPHA_PARAM_H */ -- 1.8.1.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/
[RFC PATCH 01/10] alpha: Don't if-out dp264_device_interrupt.
The code as written is correct, and will be used by QEMU emulation.
Signed-off-by: Richard Henderson
---
arch/alpha/kernel/sys_dp264.c | 8
1 file changed, 8 deletions(-)
diff --git a/arch/alpha/kernel/sys_dp264.c b/arch/alpha/kernel/sys_dp264.c
index 5bf401f..6c35159 100644
--- a/arch/alpha/kernel/sys_dp264.c
+++ b/arch/alpha/kernel/sys_dp264.c
@@ -190,9 +190,6 @@ static struct irq_chip clipper_irq_type = {
static void
dp264_device_interrupt(unsigned long vector)
{
-#if 1
- printk("dp264_device_interrupt: NOT IMPLEMENTED YET!!\n");
-#else
unsigned long pld;
unsigned int i;
@@ -210,12 +207,7 @@ dp264_device_interrupt(unsigned long vector)
isa_device_interrupt(vector);
else
handle_irq(16 + i);
-#if 0
- TSUNAMI_cchip->dir0.csr = 1UL << i; mb();
- tmp = TSUNAMI_cchip->dir0.csr;
-#endif
}
-#endif
}
static void
--
1.8.1.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] um/configs: don't use devtmpfs in defconfig
Am 16.07.2013 19:36, schrieb Ramkumar Ramachandra: > Richard Weinberger wrote: >> BTW: I'll not apply any patch to the kernel if the issue can easily >> fixed in user space, that's the major reason for my NAK. > > I was just asking for good defaults; I want um Linux to work > out-of-the-box. There's really no point in creating bogus devices in > /dev, and make life unnecessarily hard for user-space applications: > instead of checking for existence, they'd have to check that all the > devices work. I doubt systemd will accept such a patch, just to bend > over backwards and support um. Out of the box wont work in all cases. But you can easily adjust some systemd units. Like any visualization technology UML comes with some trade-offs. Thanks, //richard -- 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 0/9] sched: Power scheduler design proposal
On Mon, Jul 15, 2013 at 03:52:32PM -0700, Arjan van de Ven wrote: > yeah ondemand does this, but ondemand is actually a pretty bad governor. > not because of the sampling, but because of its algorithm. Is it good for any class of hardware still out there? Or should the thing be shot in the head? You saying AMD patched the thing makes me confused; why would they patch a piece of crap? > HOWEVER, on modern CPUs, even many of the ARM ones, the frequency > when you're idle is zero anyway regardless of what you as OS ask for. Right, entire cores are power gated. So power wise the voltage you run at is important; so for hardware where lower frequencies allow lower voltage, does it still make sense to run the lowest possible voltage such that there is still some idle time? Or is the fact that you're running so much longer negating the power save from the lower voltage? > Every 10 (or 100) milliseconds, ondemand makes a new P state decision. > It does this by asking the scheduler the time used, does a delta and > ends up at a utilization %age which then goes into a formula. > It's not that ondemand samples inbetween decision moments to see if the system > is busy or not; the microaccounting that the scheduler does is used instead, > and only at decision moments. OK.. So up to now you've mostly said what you want of the scheduler to make a better governor for the new Intel chips. However a power aware scheduler/balancer needs to interact with the policy as a whole; and I got confused by the fact that you never talked about raising/lowering speeds. As said there's already a very 'fine' problem where the cpufreq interacts with the utilization/runnable accounting we now do. So we very much need to consider the entire stack; not just new hooks you want to make it go fastest. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 07/10] alpha: Add an rtc driver for the qemu wallclock PALcall
In the normal case, one wants the guest to follow the host time.
QEMU has a cserve call that retrieves the wall clock.
Signed-off-by: Richard Henderson
---
arch/alpha/include/asm/pal.h | 56 ++
arch/alpha/kernel/Makefile | 3 +-
arch/alpha/kernel/rtc.c | 65 +++-
drivers/rtc/Kconfig | 7 +
4 files changed, 122 insertions(+), 9 deletions(-)
diff --git a/arch/alpha/include/asm/pal.h b/arch/alpha/include/asm/pal.h
index e78ec9b..ccaa49a 100644
--- a/arch/alpha/include/asm/pal.h
+++ b/arch/alpha/include/asm/pal.h
@@ -112,5 +112,61 @@ __CALL_PAL_RW1(wtint, unsigned long, unsigned long);
#define tbiap()__tbi(-1, /* no second argument */)
#define tbia() __tbi(-2, /* no second argument */)
+/*
+ * QEMU Cserv routines..
+ */
+
+static inline unsigned long
+qemu_get_walltime(void)
+{
+ register unsigned long v0 __asm__("$0");
+ register unsigned long a0 __asm__("$16") = 3;
+
+ asm("call_pal %2 # cserve get_time"
+ : "=r"(v0), "+r"(a0)
+ : "i"(PAL_cserve)
+ : "$17", "$18", "$19", "$20", "$21");
+
+ return v0;
+}
+
+static inline unsigned long
+qemu_get_alarm(void)
+{
+ register unsigned long v0 __asm__("$0");
+ register unsigned long a0 __asm__("$16") = 4;
+
+ asm("call_pal %2 # cserve get_alarm"
+ : "=r"(v0), "+r"(a0)
+ : "i"(PAL_cserve)
+ : "$17", "$18", "$19", "$20", "$21");
+
+ return v0;
+}
+
+static inline void
+qemu_set_alarm_rel(unsigned long expire)
+{
+ register unsigned long a0 __asm__("$16") = 5;
+ register unsigned long a1 __asm__("$17") = expire;
+
+ asm volatile("call_pal %2 # cserve set_alarm_rel"
+: "+r"(a0), "+r"(a1)
+: "i"(PAL_cserve)
+: "$0", "$18", "$19", "$20", "$21");
+}
+
+static inline void
+qemu_set_alarm_abs(unsigned long expire)
+{
+ register unsigned long a0 __asm__("$16") = 6;
+ register unsigned long a1 __asm__("$17") = expire;
+
+ asm volatile("call_pal %2 # cserve set_alarm_abs"
+: "+r"(a0), "+r"(a1)
+: "i"(PAL_cserve)
+: "$0", "$18", "$19", "$20", "$21");
+}
+
#endif /* !__ASSEMBLY__ */
#endif /* __ALPHA_PAL_H */
diff --git a/arch/alpha/kernel/Makefile b/arch/alpha/kernel/Makefile
index 0d54650..bf04ee8 100644
--- a/arch/alpha/kernel/Makefile
+++ b/arch/alpha/kernel/Makefile
@@ -8,7 +8,7 @@ ccflags-y := -Wno-sign-compare
obj-y:= entry.o traps.o process.o osf_sys.o irq.o \
irq_alpha.o signal.o setup.o ptrace.o time.o \
- alpha_ksyms.o systbls.o err_common.o io.o
+ alpha_ksyms.o systbls.o err_common.o io.o rtc.o
obj-$(CONFIG_VGA_HOSE) += console.o
obj-$(CONFIG_SMP) += smp.o
@@ -16,7 +16,6 @@ obj-$(CONFIG_PCI) += pci.o pci_iommu.o pci-sysfs.o
obj-$(CONFIG_SRM_ENV) += srm_env.o
obj-$(CONFIG_MODULES) += module.o
obj-$(CONFIG_PERF_EVENTS) += perf_event.o
-obj-$(CONFIG_RTC_DRV_ALPHA) += rtc.o
ifdef CONFIG_ALPHA_GENERIC
diff --git a/arch/alpha/kernel/rtc.c b/arch/alpha/kernel/rtc.c
index c8d284d..fd910ff 100644
--- a/arch/alpha/kernel/rtc.c
+++ b/arch/alpha/kernel/rtc.c
@@ -16,10 +16,12 @@
#include
#include
+#include
#include "proto.h"
+#ifdef CONFIG_RTC_DRV_ALPHA
/*
* Support for the RTC device.
*
@@ -293,20 +295,68 @@ static const struct rtc_class_ops remote_rtc_ops = {
.set_mmss = remote_set_mmss,
.ioctl = alpha_rtc_ioctl,
};
-#endif
+#endif /* HAVE_REMOTE_RTC */
+#endif /* CONFIG_RTC_DRV_ALPHA */
+
+#ifdef CONFIG_RTC_DRV_ALPHA_QEMU
+/*
+ * Support for the QEMU wall clock as an RTC device.
+ */
+
+static int
+qemu_rtc_read_time(struct device *dev, struct rtc_time *tm)
+{
+ unsigned long nsec = qemu_get_walltime();
+ unsigned long sec = nsec / NSEC_PER_SEC;
+ rtc_time_to_tm(sec, tm);
+ return 0;
+}
+
+static int
+qemu_rtc_set_time(struct device *dev, struct rtc_time *tm)
+{
+ return -EOPNOTSUPP;
+}
+
+static int
+qemu_rtc_set_mmss(struct device *dev, unsigned long sec)
+{
+ return -EOPNOTSUPP;
+}
+
+static const struct rtc_class_ops qemu_rtc_ops = {
+ .read_time = qemu_rtc_read_time,
+ .set_time = qemu_rtc_set_time,
+ .set_mmss = qemu_rtc_set_mmss,
+};
+#endif /* CONFIG_RTC_DRV_ALPHA_QEMU */
+
+#if defined(CONFIG_RTC_DRV_ALPHA) || defined(CONFIG_RTC_DRV_ALPHA_QEMU)
static int __init
-alpha_rtc_init(void)
+rtc_init(void)
{
const struct rtc_class_ops *ops;
struct platform_device *pdev;
struct rtc_device *rtc;
const char *name;
+#ifdef CONFIG_RTC_DRV_ALPHA_QEMU
+ if (alpha_using_qemu) {
+ name = "rtc-qemu";
+ ops = &qemu_rtc_ops;
+
+ pdev = platform_device_register_simple(name, -1, NULL, 0);
+ rtc = devm_rtc_device_register(&pdev->dev, name, ops, NULL
Re: [PATCH] um/configs: don't use devtmpfs in defconfig
On Tue, Jul 16, 2013 at 10:36:25PM +0530, Ramkumar Ramachandra wrote: > Richard Weinberger wrote: > > If you don't want devtmpfs, just disable it in your config. > > I don't understand: is this not a good default? Why is creating bogus > devices, confusing systemd, and making um Linux hard to boot > desirable? As for the devices, they are *not* bogus. RTFM, already. Documentation/virtual/uml/UserModeLinux-HOWTO.txt, if you can't be bothered to say git grep UML Documentation/ and find where it on your own. The relevant section is called "Setting up serial lines and consoles". Seriously, it's not as if the documentation didn't exist or had been hard to find... FWIW, default config is rather annoying - 6 xterms spawned and associated with /dev/tty[1-6]. con0=fd:0,fd:1 con=pts mentioned in the HOWTO would, IMO, make for much saner default. No comments on systemd behaviour - take that with LP and his crowd. They may or may not be confused by /dev/tty1 not being a virtual console. One practical issue is the lack of VT102 emulation; TERM=linux when logged in on those is not right - you want either TERM=xterm (for xterms) or TERM=screen (when accessing pts-associated ones with screen /dev/pts/n), etc. In any case, it's a dumb serial line as far as the guest kernel is concerned - all terminal emulation is going to happen elsewhere (xterms running on host and interpreting escape sequences from guest userland, etc.) -- 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: [fuse-devel] [PATCH] fuse: fix occasional dentry leak when readdirplus is used
On 07/16/2013 12:14 PM, Miklos Szeredi wrote:
> On Tue, Jul 16, 2013 at 09:15:16AM -0400, Brian Foster wrote:
>
>> I'm not sure why it would need to have a valid inode. A dentry with a
>> NULL inode is valid, no?
>
> It is valid, yes. It's called a "negative" dentry, which caches the
> information
> that the file does not exist.
>
>> I think the question is whether the above state (multiple, hashed dentries)
>> can be valid for whatever reason. It certainly looks suspicious.
>
> That state is not valid. So we certainly need to unhash the negative dentry
> first, before hashing a new one. We could also reuse the old dentry, but that
> is just an optimization.
>
Thanks Miklos.
> Below patch fixes several issues with that function. Could you please give
> it a
> go?
>
This patch looks good and fixes the issue for me. It might be good to
give Neils a chance to beat on it as well, but otherwise:
Tested-by: Brian Foster
Brian
> Thanks,
> Miklos
>
>
> diff --git a/fs/fuse/dir.c b/fs/fuse/dir.c
> index 0eda527..a8208c5 100644
> --- a/fs/fuse/dir.c
> +++ b/fs/fuse/dir.c
> @@ -1223,28 +1223,45 @@ static int fuse_direntplus_link(struct file *file,
> if (name.name[1] == '.' && name.len == 2)
> return 0;
> }
> +
> + if (invalid_nodeid(o->nodeid))
> + return -EIO;
> + if (!fuse_valid_type(o->attr.mode))
> + return -EIO;
> +
> fc = get_fuse_conn(dir);
>
> name.hash = full_name_hash(name.name, name.len);
> dentry = d_lookup(parent, &name);
> - if (dentry && dentry->d_inode) {
> + if (dentry) {
> inode = dentry->d_inode;
> - if (get_node_id(inode) == o->nodeid) {
> + if (!inode) {
> + d_drop(dentry);
> + } else if (get_node_id(inode) != o->nodeid ||
> +((o->attr.mode ^ inode->i_mode) & S_IFMT)) {
> + err = d_invalidate(dentry);
> + if (err)
> + goto out;
> + } else if (is_bad_inode(inode)) {
> + err = -EIO;
> + goto out;
> + } else {
> struct fuse_inode *fi;
> fi = get_fuse_inode(inode);
> spin_lock(&fc->lock);
> fi->nlookup++;
> spin_unlock(&fc->lock);
>
> + fuse_change_attributes(inode, &o->attr,
> +entry_attr_timeout(o),
> +attr_version);
> +
> /*
>* The other branch to 'found' comes via fuse_iget()
>* which bumps nlookup inside
>*/
> goto found;
> }
> - err = d_invalidate(dentry);
> - if (err)
> - goto out;
> dput(dentry);
> dentry = NULL;
> }
> @@ -1259,25 +1276,30 @@ static int fuse_direntplus_link(struct file *file,
> if (!inode)
> goto out;
>
> - alias = d_materialise_unique(dentry, inode);
> - err = PTR_ERR(alias);
> - if (IS_ERR(alias))
> - goto out;
> + if (S_ISDIR(inode->i_mode)) {
> + mutex_lock(&fc->inst_mutex);
> + alias = fuse_d_add_directory(dentry, inode);
> + mutex_unlock(&fc->inst_mutex);
> + err = PTR_ERR(alias);
> + if (IS_ERR(alias)) {
> + iput(inode);
> + goto out;
> + }
> + } else {
> + alias = d_splice_alias(inode, dentry);
> + }
> +
> if (alias) {
> dput(dentry);
> dentry = alias;
> }
>
> found:
> - fuse_change_attributes(inode, &o->attr, entry_attr_timeout(o),
> -attr_version);
> -
> fuse_change_entry_timeout(dentry, o);
>
> err = 0;
> out:
> - if (dentry)
> - dput(dentry);
> + dput(dentry);
> return err;
> }
>
>
--
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] um/configs: don't use devtmpfs in defconfig
Richard Weinberger wrote: > BTW: I'll not apply any patch to the kernel if the issue can easily > fixed in user space, that's the major reason for my NAK. I was just asking for good defaults; I want um Linux to work out-of-the-box. There's really no point in creating bogus devices in /dev, and make life unnecessarily hard for user-space applications: instead of checking for existence, they'd have to check that all the devices work. I doubt systemd will accept such a patch, just to bend over backwards and support um. -- 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: Performance regression from switching lock to rw-sem for anon-vma tree
On Tue, 2013-07-02 at 08:45 +0200, Ingo Molnar wrote: > * Tim Chen wrote: > > > On Sat, 2013-06-29 at 09:12 +0200, Ingo Molnar wrote: > > > * Tim Chen wrote: > > > > > > > > If my analysis is correct so far then it might be useful to add two > > > > > more stats: did rwsem_spin_on_owner() fail because lock->owner == > > > > > NULL > > > > > [owner released the rwsem], or because owner_running() failed [owner > > > > > went to sleep]? > > > > > > > > Ingo, > > > > > > > > I tabulated the cases where rwsem_spin_on_owner returns false and > > > > causes > > > > us to stop spinning. > > > > > > > > 97.12% was due to lock's owner switching to another writer > > > > 0.01% was due to the owner of the lock sleeping > > > > 2.87% was due to need_resched() > > > > > > > > I made a change to allow us to continue to spin even when lock's owner > > > > switch to another writer. I did get the lock to be acquired now mostly > > > > (98%) via optimistic spin and lock stealing, but my benchmark's > > > > throughput actually got reduced by 30% (too many cycles spent on > > > > useless > > > > spinning?). > > > > > > Hm, I'm running out of quick ideas :-/ The writer-ends-spinning sequence > > > is pretty similar in the rwsem and in the mutex case. I'd have a look at > > > one more detail: is the wakeup of another writer in the rwsem case > > > singular, is only a single writer woken? I suspect the answer is yes ... > > > > Ingo, we can only wake one writer, right? In __rwsem_do_wake, that is > > indeed the case. Or you are talking about something else? > > Yeah, I was talking about that, and my understanding and reading of the > code says that too - I just wanted to make sure :-) > > > > > > > A quick glance suggests that the ordering of wakeups of waiters is the > > > same for mutexes and rwsems: FIFO, single waiter woken on > > > slowpath-unlock. So that shouldn't make a big difference. > > Ingo, I tried MCS locking to order the writers but it didn't make much difference on my particular workload. After thinking about this some more, a likely explanation of the performance difference between mutex and rwsem performance is: 1) Jobs acquiring mutex put itself on the wait list only after optimistic spinning. That's only 2% of the time on my test workload so they access the wait list rarely. 2) Jobs acquiring rw-sem for write *always* put itself on the wait list first before trying lock stealing and optimistic spinning. This creates a bottleneck at the wait list, and also more cache bouncing. One possible optimization is to delay putting the writer on the wait list till after optimistic spinning, but we may need to keep track of the number of writers waiting. We could add a WAIT_BIAS to count for each write waiter and remove the WAIT_BIAS each time a writer job completes. This is tricky as I'm changing the semantics of the count field and likely will require a number of changes to rwsem code. Your thoughts on a better way to do this? Thanks. Tim -- 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 0/2] Resend of two uio patches
On Tue, Jul 16, 2013 at 07:21:02PM +0200, Uwe Kleine-König wrote: > Hello, > > these two patches were already sent back in April but fell through the > cracks. They are not really related, but send in a series because they > fail to apply in reverse order. > > Patch 1 is useful for debugging with gdb, patch 2 is a cleanup. Note > that patch 2 is only compile-tested because I don't have an uio driver > that uses a non-physical map. > > Best regards > Uwe Thanks, I'll go through these later this week. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [Ksummit-2013-discuss] When to push bug fixes to mainline
>> Maybe some QA period before the release might help, but who would >> care? (Especially under the situation where everybody has own x.y >> stable tree?) > > Hopefully people tracking the upstream stable trees would be throwing > any pre-release stuff into their QA processes before it was officially > released upstream, though I'd not count on it. Linux testing is (realistically) done by inflicting changes on gradually wider sets of end users. We go through these stages (possibly a couple of extra steps where maintainer trees are nested) 1) Author of a patch tests on their own machine (and perhaps a few others) 2) Patch is posted. A few more people grab and test. 3) Patch is applied to a maintainer tree, which is slurped into linux-next. A few hundred brave folks now have this patch in their binary, but most extra testing is purely accidental. These users aren't running focused tests on the area touched by the patch. 4) Patch is pulled by Linus. Pretty large jump in the number of users running the code so we start to get good breadth of testing on different machines with different sets of CONFIG options under varying workloads. 5) Linus releases a final 3.x version - another substantial bump in the number of testers because there are lots of people who wait for "release" quality kernels. 6) Fedora, Ubuntu etc. use this 3.x kernel as basis for a release. Probably two or three orders of magnitude more users (but only a fraction of their problems are reported back to LKML). Thus code does get more and more QA - the longer you wait before taking a patch the lower the risk that it has some unintended side-effect or outright bug . But of course you are vulnerable in this whole period to whatever issue the patch was actually trying to fix. So you have a classic tradeoff. -Tony -- 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] Thermal: Fix lockup of cpu_down()
Commit f1a18a105 "Thermal: CPU Package temperature thermal" had code that did a get_online_cpus(), run a loop and then do a put_online_cpus(). The problem is that the loop had an error exit that would skip the put_online_cpus() part. In the error exit part of the function, it also did a get_online_cpus(), run a loop and then put_online_cpus(). The only way to get to the error exit part is with get_online_cpus() already performed. If this error condition is hit, the system will be prevented from taking CPUs offline. The process taking the CPU offline will lock up hard. Removing the get_online_cpus() removes the lockup as the hotplug CPU refcount is back to zero. This was bisected with ktest. Signed-off-by: Steven Rostedt diff --git a/drivers/thermal/x86_pkg_temp_thermal.c b/drivers/thermal/x86_pkg_temp_thermal.c index 5de56f6..d47624c 100644 --- a/drivers/thermal/x86_pkg_temp_thermal.c +++ b/drivers/thermal/x86_pkg_temp_thermal.c @@ -592,7 +592,6 @@ static int __init pkg_temp_thermal_init(void) return 0; err_ret: - get_online_cpus(); for_each_online_cpu(i) put_core_offline(i); put_online_cpus(); -- 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 -next 2/2] kbuild: fix for updated LZ4 tool with the new streaming format
On Tue, Jul 16, 2013 at 10:08:07AM +0200, Yann E. MORIN wrote: > Andrew, All, > > On Tuesday 16 July 2013 09:56:11 Andrew Morton wrote: > > On Tue, 16 Jul 2013 00:47:27 -0700 Andrew Morton > > wrote: > > > On Mon, 15 Jul 2013 15:08:20 -0700 "H. Peter Anvin" > > > wrote: > > > > On 07/15/2013 03:03 PM, Andrew Morton wrote: > [--SNIP--] > > > > We keep running over the need to be able to have kconfig run tests on > > > > the build system (for toolchain support or for optional tools needed); > > > > running them in the Makefiles (i.e. at Kbuild time) is simply too late. > > > > > > > > > > Would it make sense to extend Kconfig's `depends'? > > > > > > depends on $(shell-command) > > > > > > I don't know how practical that would be to implement... > > I'm afraid this will get rather ugly and not trivial. > > Can we mix 'depends on SYMBOL' and 'depends on $(command)' ? > Can we mix both in a boolean expression such as 'depends on SYMBOL > && $(command)' ? > > What would be the condition for evaluating the dependency rule? Evaluation > at Kconfig read-time might not be enough, given this construct: > > config FOO > depends on $(foo) > comment "'foo' is missing, please install it" > depends on !$(foo) > > Also, I believe Kconfig should stay a config-only language, without > much esoteric features. We could extend the symbol option part to retreive values from a binary. Something like this: config FOOBAR bool option exec="true" FOOBAR would assume the value "y" if the command true has exit code == 0, otherwise "n". And similar conversions for other types. This only extendt Kconfig slightly - using an already present method to import external values. The drawback I see with this approach is that we may execute a lot of small programs where the value is never used. Implementing lazy evaluation of a symbol value will not be easy I think. Sam -- 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/
