Re: [PATCH 1/4] staging: OMAP4+: thermal: introduce bandgap temperature sensor
Hello Greg, On Sat, Jul 7, 2012 at 2:27 AM, Greg Kroah-Hartman wrote: > On Wed, Jul 04, 2012 at 01:37:07AM +0300, Eduardo Valentin wrote: >> In the System Control Module, OMAP supplies a voltage reference >> and a temperature sensor feature that are gathered in the band >> gap voltage and temperature sensor (VBGAPTS) module. The band >> gap provides current and voltage reference for its internal >> circuits and other analog IP blocks. The analog-to-digital >> converter (ADC) produces an output value that is proportional >> to the silicon temperature. >> >> This patch provides a platform driver which expose this feature. >> It is moduled as a MFD child of the System Control Module core >> MFD driver. >> >> This driver provides only APIs to access the device properties, >> like temperature, thresholds and update rate. >> >> Signed-off-by: Eduardo Valentin >> Signed-off-by: Keerthy >> --- >> drivers/staging/Kconfig |2 + >> drivers/staging/Makefile |1 + > > By not including the files these files "include" you just broke the > build at this point in the patch series, which isn't good. > > Care to redo this series, so that it can build at each step of the way > (you might do this by just adding the Kconfig and Makefile entries as > the last patch), and then I will be glad to apply it to the tree. Yeah. Indeed. My bad. I will resend the worked series. > > Oh, and yes, this implies that I have no problem taking this driver for > the staging tree :) Cool! > > thanks, > > greg k-h -- Eduardo Valentin -- 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/5] ubi: Fix bad PEBs reserve caclulation
Hi Richard, On Fri, 6 Jul 2012 17:27:59 +0200 Richard Genoud wrote: > I've got an oops... > this is my dev-kernel in 3.5-rc5 + some work to be able to boot on my board > NB: If I use ubi_format it's ok. > the mtd1 device has 1984 PEB > the 4 last are UBI reserved + BBT > > I didn't test without your patch, but anyway something is wrong there. Many thanks for testing. Could you please verify the crash only occurs with the patch? Can you provide the vmlinux matching this oops, so I may analyze the exact null dereferencing point? It seems to be somewhere in ubi_wl_init, however the patch seems not to affect these parts of ubi... Also, what's your CONFIG_MTD_UBI_BEB_LIMIT? Regards, Shmulik -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] staging/rts_pstor: fix single statements block warning
The following warning is fixed up.
drivers/staging/rts_pstor/sd.c:190: WARNING: braces {} are not necessary for
single statement blocks
Signed-off-by: Devendra Naga
---
drivers/staging/rts_pstor/sd.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/rts_pstor/sd.c b/drivers/staging/rts_pstor/sd.c
index ff9bf0f..3cc9a48 100644
--- a/drivers/staging/rts_pstor/sd.c
+++ b/drivers/staging/rts_pstor/sd.c
@@ -187,9 +187,9 @@ RTY_SEND_CMD:
SD_TRANSFER_END | SD_STAT_IDLE, SD_TRANSFER_END |
SD_STAT_IDLE);
if (rsp_type == SD_RSP_TYPE_R2) {
- for (reg_addr = PPBUF_BASE2; reg_addr < PPBUF_BASE2 + 16;
reg_addr++) {
+ for (reg_addr = PPBUF_BASE2; reg_addr < PPBUF_BASE2 + 16;
reg_addr++)
rtsx_add_cmd(chip, READ_REG_CMD, reg_addr, 0, 0);
- }
+
stat_idx = 16;
} else if (rsp_type != SD_RSP_TYPE_R0) {
for (reg_addr = REG_SD_CMD0; reg_addr <= REG_SD_CMD4;
reg_addr++) {
--
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 2/2] fat (exportfs): reconnect file handles to evicted inodes/dentries
"Steven J. Magnani" writes: > On Sat, 2012-07-07 at 06:07 +0900, OGAWA Hirofumi wrote: >> "Steven J. Magnani" writes: >> >> > On Wed, 2012-07-04 at 20:07 +0900, OGAWA Hirofumi wrote: >> >> Please don't add new lock_super() usage if it is not necessary. Almost >> >> all of lock_super() just replaced lock_kernel() usage. It rather should >> >> be removed in future. Probably, this should use inode->i_mutex instead. >> >> >> >> BTW, the above issue is same with all of directory read. >> > >> > I don't think there's really an alternative here. The cases addressed by >> > this patch all involve walking on-disk structures via >> > unofficial/temporary inodes created from information in the NFS handle >> > (i.e., outside the normal inode creation paths). When this process is >> > successful we end up with "official" connected inodes/dentries, but >> > getting there is really a "bottom up" strategy instead of the usual "top >> > down" approach. >> > >> > Because the "bottom up" method is lacking guarantees that "top down" >> > takes for granted - i.e., that a cluster on disk that's supposed to be a >> > directory actually *is* a directory - I am adding some defensive code >> > in the next spin of the patch. >> >> I'm not sure what you meant. Where is the problem? ->get_name()? If so, >> it has parent dentry parameter. What is the wrong if we take >> mutex_lock(parent->d_inode)? > > The temporary/"unofficial" inodes are unhashed and thus not visible > outside of the functions using them. They exist only to support access > to directory contents when we can't gain that access via other means > (because we only have "bottom up" information, about an object and > perhaps its parent, in a form that can't be used to look up hashed > inodes/dentries). Hashing them wouldn't help, because they don't have > the correct key (for instance, in the case of a ".." entry). > > Am I missing something? You mean the unhashed inode is created by ->get_parent()? If so, the root cause sounds like ->get_parent() itself. If not, I'm not understanding the meaning of the temporary/unofficial inode here. -- OGAWA Hirofumi -- 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] staging/rts_pstor: fix the no brace needed warning
for if else statements having single block no braces are needed
fixed the following checkpatch warning
drivers/staging/rts_pstor/sd.c:140: WARNING: braces {} are not necessary for
any arm of this statement
Signed-off-by: Devendra Naga
---
drivers/staging/rts_pstor/sd.c |5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/rts_pstor/sd.c b/drivers/staging/rts_pstor/sd.c
index b9474a8..ff9bf0f 100644
--- a/drivers/staging/rts_pstor/sd.c
+++ b/drivers/staging/rts_pstor/sd.c
@@ -137,11 +137,10 @@ static int sd_check_data0_status(struct rtsx_chip *chip)
{
u8 stat;
- if (CHECK_PID(chip, 0x5209)) {
+ if (CHECK_PID(chip, 0x5209))
RTSX_READ_REG(chip, REG_SD_BUS_STAT, &stat);
- } else {
+ else
RTSX_READ_REG(chip, REG_SD_STAT1, &stat);
- }
if (!(stat & SD_DAT0_STATUS)) {
sd_set_err_code(chip, SD_BUSY);
--
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 07/36] AArch64: Assembly macros and definitions
On Fri, Jul 06, 2012 at 10:05:48PM +0100, Catalin Marinas wrote: > +++ b/arch/aarch64/include/asm/assembler.h > @@ -0,0 +1,143 @@ > +/* > + * Based on arch/arm/include/asm/assembler.h > + * > + * Copyright (C) 1996-2000 Russell King > + * Copyright (C) 2012 ARM Ltd. > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License version 2 as > + * published by the Free Software Foundation. > + * > + * 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. > + * > + * You should have received a copy of the GNU General Public License > + * along with this program; if not, write to the Free Software > + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA You do this in all of your new files, and I have to ask, are you really willing to keep up with the office location of the FSF for the next 40+ years? I suggest dropping this last paragraph if at all possible. 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/
[Question] sched/rt_mutex: re-enqueue_task on rt_mutex_setprio()
Hi,
I have a question on the code below:
void rt_mutex_setprio(struct task_struct *p, int prio)
{
...
if (on_rq)
enqueue_task(rq, p, oldprio < prio ? ENQUEUE_HEAD : 0);
When enqueueing @p with new @prio, it seems put @p at the head of a
rq if appropriate. I guess it's the case of boosting @p with higher
priority, right? So Should the conditional be a reverse form (provided
that less number means higher priority)? Please shed some light on me.
Thanks,
Namhyung
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [RFC] nfsd: fix possible dereference of static NULL nfsd_serv pointer
06.07.2012 21:26, J. Bruce Fields пишет:
On Fri, Jul 06, 2012 at 05:45:56PM +0400, Stanislav Kinsbursky wrote:
This is a bug fix for 3.5 kernel.
In case on NFSd service start failure svc_shutdown_net() will call svc_destroy
callback and zeroize global nfsd_serv pointer, this in turn will lead to Oops
in svc_destroy().
This patch is marked as RFC, because to many lines were changed. It can be
easely simplified if requested.
Moreover, NFSd service shutdown is going to be converted into csomething on
per-net basis.
Doesn't this leave error paths in e.g. __write_ports_addfd() and
__write_ports_addxprt() unfixed?
Yes, sure it does...
I'm inclined to just submit your original fix (split up as in the last
version I sent) for 3.5 if you don't object.
Not at all.
Thanks, Bruce.
--b.
Signed-off-by: Stanislav Kinsbursky
---
fs/nfsd/nfssvc.c | 14 --
1 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/fs/nfsd/nfssvc.c b/fs/nfsd/nfssvc.c
index ee709fc..526a4aa 100644
--- a/fs/nfsd/nfssvc.c
+++ b/fs/nfsd/nfssvc.c
@@ -446,6 +446,7 @@ nfsd_svc(unsigned short port, int nrservs)
int error;
boolnfsd_up_before;
struct net *net = &init_net;
+ struct svc_serv *serv = nfsd_serv;
mutex_lock(&nfsd_mutex);
dprintk("nfsd: creating service\n");
@@ -454,7 +455,7 @@ nfsd_svc(unsigned short port, int nrservs)
if (nrservs > NFSD_MAXSERVS)
nrservs = NFSD_MAXSERVS;
error = 0;
- if (nrservs == 0 && nfsd_serv == NULL)
+ if (nrservs == 0 && serv == NULL)
goto out;
error = nfsd_create_serv();
@@ -464,23 +465,24 @@ nfsd_svc(unsigned short port, int nrservs)
nfsd_up_before = nfsd_up;
error = nfsd_startup(port, nrservs);
+ error = -EINVAL;
if (error)
goto out_destroy;
- error = svc_set_num_threads(nfsd_serv, NULL, nrservs);
+ error = svc_set_num_threads(serv, NULL, nrservs);
if (error)
goto out_shutdown;
/* We are holding a reference to nfsd_serv which
* we don't want to count in the return value,
* so subtract 1
*/
- error = nfsd_serv->sv_nrthreads - 1;
+ error = serv->sv_nrthreads - 1;
out_shutdown:
if (error < 0 && !nfsd_up_before)
nfsd_shutdown();
out_destroy:
- if (nfsd_serv->sv_nrthreads == 1)
- svc_shutdown_net(nfsd_serv, net);
- svc_destroy(nfsd_serv); /* Release server */
+ if (serv->sv_nrthreads == 1)
+ svc_shutdown_net(serv, net);
+ svc_destroy(serv); /* Release server */
out:
mutex_unlock(&nfsd_mutex);
return error;
--
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: "Inconsistent kallsyms data" error
On Fri, Jul 6, 2012 at 7:17 AM, Paulo Marques wrote:
[...]
>
> There was a recent thread from David Brown on the arm linux mailing list
> ("ARM: two possible fixes for the KALLSYMS build problem"). He tracked
> down the problem to having empty per_cpu sections on a non-smp build.
Actually rmk diagnosed it as the empty per_cpu sections. See it here:
http://marc.info/?l=linux-next&m=133267456809502&w=2
Paul.
--
> The alignment of these sections made the symbols jump around and change
> from one build to the next. This particular problem might be ARM
> specific, though.
>
> --
> Paulo Marques - www.grupopie.com
>
> "I used to be indecisive, but now I'm not so sure."
> --
> 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: [PATCH] x86/mce: Need to let kill_proc() send signal to doomed process
On Fri, Jul 06, 2012 at 02:33:15PM -0700, Tony Luck wrote:
> In commit dad1743e5993f19b3d7e7bd0fb35dc45b5326626
> x86/mce: Only restart instruction after machine check recovery if it is safe
> we fixed mce_notify_process() to force a signal to the current process
> if it was not restartable (RIPV bit not set in MCG_STATUS). But doing
> it here means that the process doesn't get told the virtual address of
> the fault via siginfo_t->si_addr. This would prevent application level
> recovery from the fault.
Ok, this makes sense, we want to kill all the processes mapping that
page.
> Make a new MF_MUST_KILL flag bit for memory_failure() et. al. to use
> so that we will provide the right information with the signal.
>
> Signed-off-by: Tony Luck
> ---
> arch/x86/kernel/cpu/mcheck/mce.c | 4 ++--
> include/linux/mm.h | 1 +
> mm/memory-failure.c | 8 +---
> 3 files changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/arch/x86/kernel/cpu/mcheck/mce.c
> b/arch/x86/kernel/cpu/mcheck/mce.c
> index da27c5d..43f918d 100644
> --- a/arch/x86/kernel/cpu/mcheck/mce.c
> +++ b/arch/x86/kernel/cpu/mcheck/mce.c
> @@ -1200,8 +1200,8 @@ void mce_notify_process(void)
>* doomed. We still need to mark the page as poisoned and alert any
>* other users of the page.
>*/
> - if (memory_failure(pfn, MCE_VECTOR, MF_ACTION_REQUIRED) < 0 ||
> -mi->restartable == 0) {
> + if (memory_failure(pfn, MCE_VECTOR,
> +MF_ACTION_REQUIRED|MF_MUST_KILL) < 0) {
This makes mi->restartable unused?
And more specifically, we're not looking at RIPV anymore. I'm guessing
when we've reached this point, we always MUST_KILL?
> pr_err("Memory error not recovered");
> force_sig(SIGBUS, current);
> }
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index b36d08c..f9f279c 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -1591,6 +1591,7 @@ void vmemmap_populate_print_last(void);
> enum mf_flags {
> MF_COUNT_INCREASED = 1 << 0,
> MF_ACTION_REQUIRED = 1 << 1,
> + MF_MUST_KILL = 1 << 2,
> };
> extern int memory_failure(unsigned long pfn, int trapno, int flags);
> extern void memory_failure_queue(unsigned long pfn, int trapno, int flags);
> diff --git a/mm/memory-failure.c b/mm/memory-failure.c
> index ab1e714..e3e0045 100644
> --- a/mm/memory-failure.c
> +++ b/mm/memory-failure.c
> @@ -858,7 +858,7 @@ static int hwpoison_user_mappings(struct page *p,
> unsigned long pfn,
> struct address_space *mapping;
> LIST_HEAD(tokill);
> int ret;
> - int kill = 1;
> + int kill = 1, doit;
> struct page *hpage = compound_head(p);
> struct page *ppage;
>
> @@ -965,12 +965,14 @@ static int hwpoison_user_mappings(struct page *p,
> unsigned long pfn,
>* Now that the dirty bit has been propagated to the
>* struct page and all unmaps done we can decide if
>* killing is needed or not. Only kill when the page
> - * was dirty, otherwise the tokill list is merely
> + * was dirty or the process is not restartable,
> + * otherwise the tokill list is merely
>* freed. When there was a problem unmapping earlier
>* use a more force-full uncatchable kill to prevent
>* any accesses to the poisoned memory.
>*/
> - kill_procs(&tokill, !!PageDirty(ppage), trapno,
> + doit = !!PageDirty(ppage) || (flags & MF_MUST_KILL) != 0;
Maybe
!!(flags & MF_MUST_KILL)
?
> + kill_procs(&tokill, doit, trapno,
> ret != SWAP_SUCCESS, p, pfn, flags);
>
> return ret;
> --
Thanks.
--
Regards/Gruss,
Boris.
Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/36] AArch64 Linux kernel port
Catalin, On Fri, Jul 6, 2012 at 2:05 PM, Catalin Marinas wrote: > This set of patches implements the core Linux support for the AArch64 > (64-bit ARM) architecture. Hmm. I didn't see a cc to current ARM maintainer (Russell), nor did you cc the topic list that you list in the MAINTAINERS entry. It's probably considered appropriate to do both. Also, linux-a...@vger.kernel.org usually has a cc of new architectures. > ARM introduced AArch64 as part of the ARMv8 architecture With the risk of bikeshedding here, but I find the name awkward. How about just naming the arch port arm64 instead? It's considerably more descriptive in the context of the kernel. For reference, we didn't name ppc64, nor powerpc, after what the IBM/power.org marketing people were currently calling the architecture at the time either. [...] > There is no hardware platform available at this point. From a kernel > perspective, the aim is to minimise (or even completely remove) the > platform code from the architecture specific directory. FDT is currently > mandated and there are ongoing discussions for ACPI support. This will be interesting to see how it plays out over time, and how many vendors will drop in arm64 cores on their existing designs and thus need to pull over infrastructure from arch/arm for their platform type. A lot of the drivers have moved out to common code so much of it should be possible to do cleanly, but there is still some risk for duplication. I guess it's a good chance to clean up some of it and start from a clean slate, if you can avoid the temptation of just moving over code. -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/36] AArch64 Linux kernel port
On Fri, Jul 06, 2012 at 10:05:41PM +0100, Catalin Marinas wrote: > There is no hardware platform available at this point. From a kernel > perspective, the aim is to minimise (or even completely remove) the > platform code from the architecture specific directory. FDT is currently > mandated and there are ongoing discussions for ACPI support. While mandating FDT is a massive advance over arm32, if there's a chance that ACPI-based AArch64 platforms will ship in a similar timeframe to FDT then I think we should ensure that ACPI and FDT are merged beforehand - the alternative is that people are going to end up writing the same hardware driver twice for different firmware implementations. I don't think anyone benefits from introducing a platform that has multiple device representations[1] [1] Yeah x86 has the same problem with PNP and ACPI and PCI and given how much pain that's caused me I wish someone had complained at the time -- Matthew Garrett | mj...@srcf.ucam.org -- 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: Fwd: Re: [linux-next-20120706] x86/mm: incompatible pointer typewarning.
On 07/07/2012 08:43 AM, Tetsuo Handa wrote: > Alex Shi wrote: >> Thanks for your report, mm should means mm_struct. no vma. My fault. >> Could you like try this patch. > > Builds OK. Thank you. Uh, seems the allnoconfig setting is different on different tree. I need to tired it other tree no just Linus' tree. :( > >> From 97781231b130e7f7fced12244653ed9b9946c944 Mon Sep 17 00:00:00 2001 >> From: Alex Shi >> Date: Fri, 6 Jul 2012 20:49:25 +0800 >> Subject: [PATCH] x86/tlb: fix allnoconfig building warning >> >> The incompatible parameter of flush_tlb_mm_range cause build warning. >> Fix it by correct parameter. -- Thanks Alex -- 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: [Resend PATCH] media: rc: ati_remote.c: code style and compile warning fixing
Em 06-07-2012 22:49, Du Changbin escreveu: >>> diff --git a/drivers/media/rc/ati_remote.c > b/drivers/media/rc/ati_remote.c >>> index 7be377f..0df66ac 100644 >>> --- a/drivers/media/rc/ati_remote.c >>> +++ b/drivers/media/rc/ati_remote.c >>> @@ -23,6 +23,8 @@ >>> *Vincent Vanackere >>> *Added support for the "Lola" remote contributed by: >>> *Seth Cohn >>> + * Jul 2012: Du, Changbin >>> + *Code style and compile warning fixing >> >> You shouldn't be changing the driver's authorship just due to codingstyle >> and warning fixes. Btw, Please split Coding Style form Compilation > warnings, >> as they're two different matters. > > Sorry, I didn't know this rule. I just want to make a track for me. OK, I > will resend this patch and remove me from it. > BTW, I am looking for something to learn these basic rules when sending > patches. Could you tell me where I can find it? There are some rules at linuxtv wiki pages, others at the Kernel Documentation dir and other not so explicit rules like the above that you'll get as you continue contributing ;) In opposite to other open source projects, the contribution history is the git logs, and not inside the comments at the source code. > Many thanks! > [Du, Changbin] Thanks, Mauro -- 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: Contact Me For The Project Via: elizza_ett...@hotmail.com
From: Ostrowski, Anthony Paul Sent: Friday, July 06, 2012 9:43 PM Subject: Contact Me For The Project Via: elizza_ett...@hotmail.com I am Elizabeth.Etters, a devoted christian. I am setting up a charity foundation but due to my health condition I would need somebody to help me finish it.So please reply to my email address for more details: elizza_ett...@hotmail.com -- 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: general protection fault on ttm_init()
On Fri, Jul 06, 2012 at 06:09:20PM +0100, Dave Airlie wrote: > On Fri, Jul 6, 2012 at 5:49 PM, Dave Airlie wrote: > > On Fri, Jul 6, 2012 at 3:48 PM, Fengguang Wu wrote: > >> ... The missed kconfig. > >> > >> On Fri, Jul 06, 2012 at 10:46:22PM +0800, Fengguang Wu wrote: > >>> Hi Thomas, > > > > Wierd, I'm sorta tempted to just depend drm on CONFIG_PROC_FS, but it > > looks like the error path is failing to dtrt. > > I've attached a patch that should fix it, let me know if it works. It does not work.. The dmesg (attached) remains the same. > though since the drm fails on proc not being there I wonder should we > just enforce proc being there if you pick drm. Yeah, enabling PROC_FS does fix the error :) Thanks, Fengguang [0.00] Linux version 3.5.0-rc2-00059-gc5fb75a-dirty (wfg@wfg-t420) (gcc version 4.7.0 (Debian 4.7.0-10) ) #3 PREEMPT Sat Jul 7 09:42:37 CST 2012 [0.00] Command line: console=ttyS0,115200 console=tty nokeymap root=/dev/ram0 rw [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009f3ff] usable [0.00] BIOS-e820: [mem 0x0009f400-0x0009] reserved [0.00] BIOS-e820: [mem 0x000f-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0x1fffcfff] usable [0.00] BIOS-e820: [mem 0x1fffd000-0x1fff] reserved [0.00] BIOS-e820: [mem 0xfeffc000-0xfeff] reserved [0.00] BIOS-e820: [mem 0xfffc-0x] reserved [0.00] NX (Execute Disable) protection: active [0.00] DMI 2.4 present. [0.00] e820: last_pfn = 0x1fffd max_arch_pfn = 0x4 [0.00] x86 PAT enabled: cpu 0, old 0x70406, new 0x7010600070106 [0.00] init_memory_mapping: [mem 0x-0x1fffcfff] [0.00] RAMDISK: [mem 0x1e8d6000-0x1ffe] [0.00] ACPI: RSDP 000fd9a0 00014 (v00 BOCHS ) [0.00] ACPI: RSDT 1fffd7b0 00034 (v01 BOCHS BXPCRSDT 0001 BXPC 0001) [0.00] ACPI: FACP 1f80 00074 (v01 BOCHS BXPCFACP 0001 BXPC 0001) [0.00] ACPI: DSDT 1fffd9b0 02589 (v01 BXPC BXDSDT 0001 INTL 20100528) [0.00] ACPI: FACS 1f40 00040 [0.00] ACPI: SSDT 1fffd910 0009E (v01 BOCHS BXPCSSDT 0001 BXPC 0001) [0.00] ACPI: APIC 1fffd830 00072 (v01 BOCHS BXPCAPIC 0001 BXPC 0001) [0.00] ACPI: HPET 1fffd7f0 00038 (v01 BOCHS BXPCHPET 0001 BXPC 0001) [0.00] kvm-clock: Using msrs 4b564d01 and 4b564d00 [0.00] kvm-clock: cpu 0, msr 0:1a2cc81, boot clock [0.00] Zone ranges: [0.00] DMA32[mem 0x0001-0x] [0.00] Normal empty [0.00] Movable zone start for each node [0.00] Early memory node ranges [0.00] node 0: [mem 0x0001-0x0009efff] [0.00] node 0: [mem 0x0010-0x1fffcfff] [0.00] ACPI: PM-Timer IO Port: 0xb008 [0.00] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) [0.00] ACPI: IOAPIC (id[0x01] address[0xfec0] gsi_base[0]) [0.00] IOAPIC[0]: apic_id 1, version 17, address 0xfec0, GSI 0-23 [0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) [0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 5 global_irq 5 high level) [0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) [0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 10 global_irq 10 high level) [0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 11 global_irq 11 high level) [0.00] Using ACPI (MADT) for SMP configuration information [0.00] ACPI: HPET id: 0x8086a201 base: 0xfed0 [0.00] KVM setup async PF for cpu 0 [0.00] kvm-stealtime: cpu 0, msr 1a2cc00 [0.00] e820: [mem 0x2000-0xfeffbfff] available for PCI devices [0.00] Booting paravirtualized kernel on KVM [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 128902 [0.00] Kernel command line: [0.00] PID hash table entries: 2048 (order: 2, 16384 bytes) [0.00] Dentry cache hash table entries: 65536 (order: 7, 524288 bytes) [0.00] Inode-cache hash table entries: 32768 (order: 6, 262144 bytes) [0.00] __ex_table already sorted, skipping sort [0.00] Memory: 469120k/524276k available (5504k kernel code, 452k absent, 54704k reserved, 7636k data, 820k init) [0.00] SLUB: Genslabs=15, HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 [0.00] NR_IRQS:4352 nr_irqs:256 16 [0.00] console [ttyS0] enabled [0.00] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar [0.00] ... MAX_LOCKDEP_SUBCLASSES: 8 [0.00] ... MAX_LOCK_DEPTH: 48 [0.00] ... MAX_LOCKDEP_KEYS:8191 [0.00] ... CLASSHASH_SIZE: 409
[ANNOUNCE] 3.2.22-rt34
Dear RT Folks, I'm pleased to announce the 3.2.22-rt34 stable release. This release is just an update to the new stable 3.2.22 version and no RT specific changes have been made. You can get this release via the git tree at: git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git Head SHA1: af3e91ebefe263747fd12212491d1a2dc3ef9ccc Or to build 3.2.22-rt34 directly, the following patches should be applied: http://www.kernel.org/pub/linux/kernel/v3.x/linux-3.2.tar.xz http://www.kernel.org/pub/linux/kernel/v3.x/patch-3.2.22.xz http://www.kernel.org/pub/linux/kernel/projects/rt/3.2/patch-3.2.22-rt34.patch.xz Enjoy, -- 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 1/2] block: add partition resize function to blkpg ioctl
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 What's the status of this patch? Forgotten, or are there still any outstanding concerns? On 03/02/2012 01:54 PM, Vivek Goyal wrote: > Hi Jens, > > Do you have concerns about this patch? If no, can you please consider > merging it. > > Thanks > Vivek -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJP95YUAAoJEJrBOlT6nu75A/kIAIEWs+MlA8Me05jjBGpSFQsn VigiYTF4UdWjA3bG0CNB41eqpzOKVl/B4vTBAy1YezuUXMamBRp1OD6hatEL/blO ps/M2S2NNPgFOzDmZBgfWIib6tnbCJvTowLdt4n4NnP0DoQRn+5bXopL/jcm4lwU XWheiqFFX1xSB5YgP+GMl4zVWZhyrHYcynqK/25EimbEXtjgTyR3Cy4wMfGgMdnI HkY7D0Kn420n+X6uRLXZW8hV3apATZCz3PGsxg7FI83gFi7Tc9rneOhwgRkAXHxq FcJ2NABK83dACAYOU0fhVTmxoumxuHNCmp7iRGiavnbNCBJWxLV2x1WhceX23lc= =1FUQ -END PGP SIGNATURE- -- 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: [Resend PATCH] media: rc: ati_remote.c: code style and compile warning fixing
> > diff --git a/drivers/media/rc/ati_remote.c b/drivers/media/rc/ati_remote.c > > index 7be377f..0df66ac 100644 > > --- a/drivers/media/rc/ati_remote.c > > +++ b/drivers/media/rc/ati_remote.c > > @@ -23,6 +23,8 @@ > >*Vincent Vanackere > >*Added support for the "Lola" remote contributed by: > >*Seth Cohn > > + * Jul 2012: Du, Changbin > > + *Code style and compile warning fixing > > You shouldn't be changing the driver's authorship just due to codingstyle > and warning fixes. Btw, Please split Coding Style form Compilation warnings, > as they're two different matters. Sorry, I didn't know this rule. I just want to make a track for me. OK, I will resend this patch and remove me from it. BTW, I am looking for something to learn these basic rules when sending patches. Could you tell me where I can find it? Many thanks! [Du, Changbin] > > Thanks! > Mauro -- 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] regulator: da9052: Use for_each_child_of_node() macro
Signed-off-by: Axel Lin
---
drivers/regulator/da9052-regulator.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/regulator/da9052-regulator.c
b/drivers/regulator/da9052-regulator.c
index 88976d8..5f8f71a 100644
--- a/drivers/regulator/da9052-regulator.c
+++ b/drivers/regulator/da9052-regulator.c
@@ -405,8 +405,7 @@ static int __devinit da9052_regulator_probe(struct
platform_device *pdev)
if (!nproot)
return -ENODEV;
- for (np = of_get_next_child(nproot, NULL); np;
-np = of_get_next_child(nproot, np)) {
+ for_each_child_of_node(nproot, np) {
if (!of_node_cmp(np->name,
regulator->info->reg_desc.name)) {
config.init_data = of_get_regulator_init_data(
--
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: New Defect found by Coverity Scan based on code change in last 1.5 week
On Sat, Jul 7, 2012 at 1:32 AM, Scan Subscription
wrote:
>
> CID 200075: Free of array-typed value (BAD_FREE.array)
>
> /linux/fs/splice.c: 317 ( array_assign)
>311 struct page *pages[PIPE_DEF_BUFFERS];
>312 struct partial_page partial[PIPE_DEF_BUFFERS];
> ...
>316 int error, page_nr;
CID 200075: Free of array-typed value (BAD_FREE.array)
Assigning: "spd.pages" = "pages".
>317 struct splice_pipe_desc spd = {
>318 .pages = pages,
>319 .partial = partial,
>320 .nr_pages_max = PIPE_DEF_BUFFERS,
>321 .flags = flags,
>
> /linux/fs/splice.c: 503 ( incorrect_free)
>500 if (spd.nr_pages)
>501 error = splice_to_pipe(pipe, &spd);
>502
"splice_shrink_spd" frees incorrect pointer "spd.pages".
>503 splice_shrink_spd(&spd);
>504 return error;
>505}
>506
>507/**
This one should be bogus, splice_shrink_spd() only
frees it when spd->nr_pages_max > PIPE_DEF_BUFFERS
because splice_grow_spd() only allocates memory
in that case. Otherwise, the array allocated on stack is
used.
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 2/2] fat (exportfs): reconnect file handles to evicted inodes/dentries
On Sat, 2012-07-07 at 06:07 +0900, OGAWA Hirofumi wrote: > "Steven J. Magnani" writes: > > > On Wed, 2012-07-04 at 20:07 +0900, OGAWA Hirofumi wrote: > >> Please don't add new lock_super() usage if it is not necessary. Almost > >> all of lock_super() just replaced lock_kernel() usage. It rather should > >> be removed in future. Probably, this should use inode->i_mutex instead. > >> > >> BTW, the above issue is same with all of directory read. > > > > I don't think there's really an alternative here. The cases addressed by > > this patch all involve walking on-disk structures via > > unofficial/temporary inodes created from information in the NFS handle > > (i.e., outside the normal inode creation paths). When this process is > > successful we end up with "official" connected inodes/dentries, but > > getting there is really a "bottom up" strategy instead of the usual "top > > down" approach. > > > > Because the "bottom up" method is lacking guarantees that "top down" > > takes for granted - i.e., that a cluster on disk that's supposed to be a > > directory actually *is* a directory - I am adding some defensive code > > in the next spin of the patch. > > I'm not sure what you meant. Where is the problem? ->get_name()? If so, > it has parent dentry parameter. What is the wrong if we take > mutex_lock(parent->d_inode)? The temporary/"unofficial" inodes are unhashed and thus not visible outside of the functions using them. They exist only to support access to directory contents when we can't gain that access via other means (because we only have "bottom up" information, about an object and perhaps its parent, in a form that can't be used to look up hashed inodes/dentries). Hashing them wouldn't help, because they don't have the correct key (for instance, in the case of a ".." entry). Am I missing something? Steve Steven J. Magnani "I claim this network for MARS! www.digidescorp.com Earthling, return my space modulator!" #include -- 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: perf lock record fails
Hi, David On Fri, 06 Jul 2012 11:27:39 -0600, David Ahern wrote: > What config options need to be enabled for 'perf lock record' to work? > I tried a number of custom builds and stock Fedora kernels. I always > get: > > $ perf lock record -- sleep 1 > invalid or unsupported event: 'lock:lock_acquire' > > Though trace_lock_acquire exists, CONFIG_LOCKDEP is set, and ftrace is > enabled. > > What am I missing? > Weird. AFAICS lock_acquire and lock_release depend on CONFIG_LOCKDEP, and lock_acquired and lock_contented depend on CONFIG_LOCK_STAT (I guess it should be warned/commented somewhere?). Maybe CONFIG_EVENT_TRACING? Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 05/12] usb: feed USB device information to the /dev/random driver
Hi, Theodore Ts'o wrote: > On Fri, Jul 06, 2012 at 06:02:18PM -0500, Jonathan Nieder wrote: >> Why cc: stable@? Does this fix a build error, oops, hang, data >> corruption, real security issue, or other critical "oh, that's not >> good" bug? > > All of the /dev/random patches in this patch series that were marked > for the stable backports are to address a security issue. See: > https://factorable.net/ Thanks for explaining. If there's occasion for a reroll (I'm guessing there won't be) then it would be nice to mention this in the commit messages. [...] > While these patches are designed to do as much as we can without > assuming any fixes in userspace, and the weak kea vulnerabilities are > much more obviously detectable in embedded devices with close to zero > available entropy, ideally there are improvements that can and should > be done in upstream userspace packages as well as in the packaging and > installation scripts for more general-purpose server and workstation > distributions. > > For example, ssh key generation should happen as late as possible; > ideally, some time *after* the networking has been brought up. [...] > The same is true for the generation of remote > administration keys for ntpd and bind. Very much agreed. These patches look like an improvement but on diskless systems without a hardware RNG it still seems possible for someone with knowledge of the hardware configuration to predict the generator state. Except that patch 2 improves matters a lot. Thanks for your work and kindness, Jonathan -- 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] Staging: android: fix pr_info and pr_err coding style issues in ashmem.c
This is a patch to the ashmem.c file that fixes up several pr_info and pr_err
warnings found by the checkpath.pl tool
Signed-off-by: Pablo Vazquez Rodriguez
---
drivers/staging/android/ashmem.c | 13 +++--
1 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/android/ashmem.c b/drivers/staging/android/ashmem.c
index e84dbec..71eb63b 100644
--- a/drivers/staging/android/ashmem.c
+++ b/drivers/staging/android/ashmem.c
@@ -15,6 +15,7 @@
** MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
** GNU General Public License for more details.
*/
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
#include
#include
@@ -707,7 +708,7 @@ static int __init ashmem_init(void)
sizeof(struct ashmem_area),
0, 0, NULL);
if (unlikely(!ashmem_area_cachep)) {
- printk(KERN_ERR "ashmem: failed to create slab cache\n");
+ pr_err("failed to create slab cache\n");
return -ENOMEM;
}
@@ -715,19 +716,19 @@ static int __init ashmem_init(void)
sizeof(struct ashmem_range),
0, 0, NULL);
if (unlikely(!ashmem_range_cachep)) {
- printk(KERN_ERR "ashmem: failed to create slab cache\n");
+ pr_err("failed to create slab cache\n");
return -ENOMEM;
}
ret = misc_register(&ashmem_misc);
if (unlikely(ret)) {
- printk(KERN_ERR "ashmem: failed to register misc device!\n");
+ pr_err("failed to register misc device!\n");
return ret;
}
register_shrinker(&ashmem_shrinker);
- printk(KERN_INFO "ashmem: initialized\n");
+ pr_info("initialized\n");
return 0;
}
@@ -740,12 +741,12 @@ static void __exit ashmem_exit(void)
ret = misc_deregister(&ashmem_misc);
if (unlikely(ret))
- printk(KERN_ERR "ashmem: failed to unregister misc device!\n");
+ pr_err("failed to unregister misc device!\n");
kmem_cache_destroy(ashmem_range_cachep);
kmem_cache_destroy(ashmem_area_cachep);
- printk(KERN_INFO "ashmem: unloaded\n");
+ pr_info("unloaded\n");
}
module_init(ashmem_init);
--
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Bug 43331] Re: Bug on bootup of Linux kernel on Panasonic Toughbook S10
On Fri, Jul 6, 2012 at 4:37 PM, Bill Unruh wrote: > On Fri, 6 Jul 2012, Bjorn Helgaas wrote: > >> On Sat, Jun 02, 2012 at 11:30:23AM +0800, Jiang Liu wrote: >>> >>> ... address range 0xfed98000-0xfed9 has been reserved by motherboard >>> device(PNP0C02). No, pnp resource reservation is after pci bar reservation. >>>I guess that BIOS has assigned address "0xfed98000" to >>> :00:04.0 for thermal management functionality. The BAR0 of >>> :00:04.0 may be locked down (can't be changed by OS) because the ACPI >>> BIOS may have dependency on the assigned address ranges. >> >> >> I don't think the BAR can be completely read-only. If it were, we >> wouldn't >> have any way to determine its size. We believe it is 32K in size: >> >>pci :00:04.0: reg 10: [mem 0xfed98000-0xfed9 64bit] >> >> so we should have written 0x to the low 32 bits of the BAR and >> read >> back 0x8004 (32K = 2^15, so the low-order 15 bits should be read-only, >> including the prefetchable bit (0), the type bits (10 for 64-bit), and the >> memory space indicator (0)). because it is locked down by BIOS to chipset, readback should be 0xfed98004. and pci_size will return 32k for 0xfed98000. >> >> Can you experiment with setting that BAR manually, e.g., by running these >> commands as root: >> >># setpci -s 00:04.0 COMMAND BASE_ADDRESS_0 BASE_ADDRESS_1 >># setpci -s 00:04.0 BASE_ADDRESS_0=0xdfa0 >># setpci -s 00:04.0 BASE_ADDRESS_0 BASE_ADDRESS_1 > > > > planet:0[root]>setpci -s 00:04.0 COMMAND BASE_ADDRESS_0 BASE_ADDRESS_1 > 0006 > fed98004 > > planet:0[root]>setpci -s 00:04.0 BASE_ADDRESS_0=0xdfa0 > planet:0[root]>setpci -s 00:04.0 BASE_ADDRESS_0 BASE_ADDRESS_1 > fed98004 > > planet:0[root] BIOS _CRS [1.956431] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug [1.956921] ACPI: PCI Root Bridge [PCI0] (domain [bus 00-3e]) [1.957225] pci_root PNP0A08:00: host bridge window [io 0x-0x0cf7] [1.957227] pci_root PNP0A08:00: host bridge window [io 0x0d00-0x] [1.957229] pci_root PNP0A08:00: host bridge window [mem 0x000a-0x000b] [1.957232] pci_root PNP0A08:00: host bridge window [mem 0x000d4000-0x000d7fff] [1.957234] pci_root PNP0A08:00: host bridge window [mem 0x000d8000-0x000dbfff] [1.957235] pci_root PNP0A08:00: host bridge window [mem 0x000dc000-0x000d] [1.957237] pci_root PNP0A08:00: host bridge window [mem 0xdfa0-0xfeaf] [1.957239] pci_root PNP0A08:00: host bridge window [mem 0xfed4-0xfed44fff] and it does not include 0xfed98000 for the 00:04.0, so kernel can not reserve it, and kernel will reject it and try to get new range for 00:04.0 but bios lock down that in chipset setting register. so try get one update bios that could return resource for root bus. or you could try to live with booting with pci=nocrs before your get new BIOS. Thanks Yinghai -- 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: Fwd: Re: [linux-next-20120706] x86/mm: incompatible pointer typewarning.
Alex Shi wrote: > Thanks for your report, mm should means mm_struct. no vma. My fault. > Could you like try this patch. Builds OK. Thank you. > From 97781231b130e7f7fced12244653ed9b9946c944 Mon Sep 17 00:00:00 2001 > From: Alex Shi > Date: Fri, 6 Jul 2012 20:49:25 +0800 > Subject: [PATCH] x86/tlb: fix allnoconfig building warning > > The incompatible parameter of flush_tlb_mm_range cause build warning. > Fix it by correct parameter. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: don't invoke __alloc_pages_direct_compact when order 0
On Sat, Jul 07, 2012 at 01:58:24AM +0900, JoonSoo Kim wrote: > 2012/7/7 Minchan Kim : > > Hi Joonsoo, > > > > On Sat, Jul 07, 2012 at 12:28:41AM +0900, Joonsoo Kim wrote: > >> __alloc_pages_direct_compact has many arguments so invoking it is very > >> costly. > > > > It's already slow path so it's pointless for such optimization. > > I know this is so minor optimization. > But why don't we do such a one? > Is there any weak point? Let's think about it. You are adding *new rule* for minor optimization. If new users uses __alloc_pages_direct_compact in future, they always have to check whether order is zero not not. So it could increase code size as well as bad for readbility. Even, I'm not sure adding branch is always win than just passing the some arguement in all architecures. > > >> And in almost invoking case, order is 0, so return immediately. > > > > You can't make sure it. > > Okay. > > >> > >> Let's not invoke it when order 0 > > > > Let's not ruin git blame. > > Hmm... > When I do git blame, I can't find anything related to this. I mean if we merge the pointless patch, it could be showed firstly instead of meaningful patch when we do git blame. It makes us bothering when we find blame-patch. > > Thanks for comments -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: vt6656: iwctl: mop up a few remaining obvious style issues
On Fri, 6 Jul 2012, Greg Kroah-Hartman wrote: > On Wed, Jun 27, 2012 at 09:19:15PM +0200, Jesper Juhl wrote: > > My previous 14 patch series to vt6656 missed a few bits and > > pieces. This mops up the last few obvious style issues. > > It is quite short and completely trivial - simply deletes a few blank > > lines, does some whitespace cleanup around operators and adds a few > > curly braces. > > > > Signed-off-by: Jesper Juhl > > Again, one patch per thing please. Please break this up into different > patches so it can be accepted. > Ok, ok :-) I really thought that this one was so short and trivial that it would be OK - but I'll break it up and submit a tiny series against linux-next some time during the weekend (as a reply to this mail). > greg k-h > -- Jesper Juhlhttp://www.chaosbits.net/ Don't top-post http://www.catb.org/jargon/html/T/top-post.html Plain text mails only, please. -- 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] regulator: tps62360: Convert to devm_gpio_request_one
Use devm_gpio_request_one to save a few error handling code.
Also remove trivial comment for tps62360_remove.
Signed-off-by: Axel Lin
---
drivers/regulator/tps62360-regulator.c | 38 +++-
1 file changed, 8 insertions(+), 30 deletions(-)
diff --git a/drivers/regulator/tps62360-regulator.c
b/drivers/regulator/tps62360-regulator.c
index 103bb62..062a9cf 100644
--- a/drivers/regulator/tps62360-regulator.c
+++ b/drivers/regulator/tps62360-regulator.c
@@ -428,24 +428,24 @@ static int __devinit tps62360_probe(struct i2c_client
*client,
int gpio_flags;
gpio_flags = (pdata->vsel0_def_state) ?
GPIOF_OUT_INIT_HIGH : GPIOF_OUT_INIT_LOW;
- ret = gpio_request_one(tps->vsel0_gpio,
- gpio_flags, "tps62360-vsel0");
+ ret = devm_gpio_request_one(&client->dev, tps->vsel0_gpio,
+ gpio_flags, "tps62360-vsel0");
if (ret) {
dev_err(&client->dev,
"%s(): Could not obtain vsel0 GPIO %d: %d\n",
__func__, tps->vsel0_gpio, ret);
- goto err_gpio0;
+ return ret;
}
gpio_flags = (pdata->vsel1_def_state) ?
GPIOF_OUT_INIT_HIGH : GPIOF_OUT_INIT_LOW;
- ret = gpio_request_one(tps->vsel1_gpio,
- gpio_flags, "tps62360-vsel1");
+ ret = devm_gpio_request_one(&client->dev, tps->vsel1_gpio,
+ gpio_flags, "tps62360-vsel1");
if (ret) {
dev_err(&client->dev,
"%s(): Could not obtain vsel1 GPIO %d: %d\n",
__func__, tps->vsel1_gpio, ret);
- goto err_gpio1;
+ return ret;
}
tps->valid_gpios = true;
@@ -463,7 +463,7 @@ static int __devinit tps62360_probe(struct i2c_client
*client,
if (ret < 0) {
dev_err(tps->dev, "%s(): Init failed with err = %d\n",
__func__, ret);
- goto err_init;
+ return ret;
}
config.dev = &client->dev;
@@ -477,39 +477,17 @@ static int __devinit tps62360_probe(struct i2c_client
*client,
dev_err(tps->dev,
"%s(): regulator register failed with err %s\n",
__func__, id->name);
- ret = PTR_ERR(rdev);
- goto err_init;
+ return PTR_ERR(rdev);
}
tps->rdev = rdev;
return 0;
-
-err_init:
- if (gpio_is_valid(tps->vsel1_gpio))
- gpio_free(tps->vsel1_gpio);
-err_gpio1:
- if (gpio_is_valid(tps->vsel0_gpio))
- gpio_free(tps->vsel0_gpio);
-err_gpio0:
- return ret;
}
-/**
- * tps62360_remove - tps62360 driver i2c remove handler
- * @client: i2c driver client device structure
- *
- * Unregister TPS driver as an i2c client device driver
- */
static int __devexit tps62360_remove(struct i2c_client *client)
{
struct tps62360_chip *tps = i2c_get_clientdata(client);
- if (gpio_is_valid(tps->vsel1_gpio))
- gpio_free(tps->vsel1_gpio);
-
- if (gpio_is_valid(tps->vsel0_gpio))
- gpio_free(tps->vsel0_gpio);
-
regulator_unregister(tps->rdev);
return 0;
}
--
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 net,1/1] hyperv: Add support for setting MAC from within guests
On Fri, 2012-07-06 at 14:25 -0700, Haiyang Zhang wrote:
> This adds support for setting synthetic NIC MAC address from within Linux
> guests. Before using this feature, the option "spoofing of MAC address"
> should be enabled at the Hyper-V manager / Settings of the synthetic
> NIC.
[...]
> +int rndis_filter_set_device_mac(struct hv_device *hdev, char *mac)
> +{
[...]
> + t = wait_for_completion_timeout(&request->wait_event, 5*HZ);
> + if (t == 0) {
> + netdev_err(ndev, "timeout before we got a set response...\n");
> + /*
> + * can't put_rndis_request, since we may still receive a
> + * send-completion.
> + */
> + return -EBUSY;
> + } else {
> + set_complete = &request->response_msg.msg.set_complete;
> + if (set_complete->status != RNDIS_STATUS_SUCCESS)
> + ret = -EINVAL;
[...]
Is there a specific error code that indicates the hypervisor is
configured not to allow MAC address changes? If so, shouldn't that be
translated to return EPERM rather than EINVAL?
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Bug 43331] Re: Bug on bootup of Linux kernel on Panasonic Toughbook S10
On Fri, 6 Jul 2012, Bjorn Helgaas wrote: On Sat, Jun 02, 2012 at 11:30:23AM +0800, Jiang Liu wrote: ... address range 0xfed98000-0xfed9 has been reserved by motherboard device(PNP0C02). I guess that BIOS has assigned address "0xfed98000" to :00:04.0 for thermal management functionality. The BAR0 of :00:04.0 may be locked down (can't be changed by OS) because the ACPI BIOS may have dependency on the assigned address ranges. I don't think the BAR can be completely read-only. If it were, we wouldn't have any way to determine its size. We believe it is 32K in size: pci :00:04.0: reg 10: [mem 0xfed98000-0xfed9 64bit] so we should have written 0x to the low 32 bits of the BAR and read back 0x8004 (32K = 2^15, so the low-order 15 bits should be read-only, including the prefetchable bit (0), the type bits (10 for 64-bit), and the memory space indicator (0)). Can you experiment with setting that BAR manually, e.g., by running these commands as root: # setpci -s 00:04.0 COMMAND BASE_ADDRESS_0 BASE_ADDRESS_1 # setpci -s 00:04.0 BASE_ADDRESS_0=0xdfa0 # setpci -s 00:04.0 BASE_ADDRESS_0 BASE_ADDRESS_1 planet:0[root]>setpci -s 00:04.0 COMMAND BASE_ADDRESS_0 BASE_ADDRESS_1 0006 fed98004 planet:0[root]>setpci -s 00:04.0 BASE_ADDRESS_0=0xdfa0 planet:0[root]>setpci -s 00:04.0 BASE_ADDRESS_0 BASE_ADDRESS_1 fed98004 planet:0[root] So it seems to work but does not change the base address (or was that what you meant by "does not work") That's basically what the kernel does in pci_update_resource(), so this will likely fail, too. In __pci_read_base(), where we size the BAR, we disable decoding first, which we *don't* do in pci_update_resource(). So if the above doesn't work, can you try this: # setpci -s 00:04.0 COMMAND BASE_ADDRESS_0 BASE_ADDRESS_1 # setpci -s 00:04.0 COMMAND=0 # setpci -s 00:04.0 BASE_ADDRESS_0=0xdfa0 # setpci -s 00:04.0 BASE_ADDRESS_0 BASE_ADDRESS_1 planet:0[root]>setpci -s 00:04.0 COMMAND BASE_ADDRESS_0 BASE_ADDRESS_1 0006 fed98004 planet:0[root]>setpci -s 00:04.0 COMMAND=0 planet:0[root]>setpci -s 00:04.0 BASE_ADDRESS_0=0xdfa0 planet:0[root]>setpci -s 00:04.0 BASE_ADDRESS_0 BASE_ADDRESS_1 fed98004 planet:0[root]> Ie, same thing-- no change in the address. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] staging: OMAP4+: thermal: introduce bandgap temperature sensor
On Wed, Jul 04, 2012 at 01:37:07AM +0300, Eduardo Valentin wrote: > In the System Control Module, OMAP supplies a voltage reference > and a temperature sensor feature that are gathered in the band > gap voltage and temperature sensor (VBGAPTS) module. The band > gap provides current and voltage reference for its internal > circuits and other analog IP blocks. The analog-to-digital > converter (ADC) produces an output value that is proportional > to the silicon temperature. > > This patch provides a platform driver which expose this feature. > It is moduled as a MFD child of the System Control Module core > MFD driver. > > This driver provides only APIs to access the device properties, > like temperature, thresholds and update rate. > > Signed-off-by: Eduardo Valentin > Signed-off-by: Keerthy > --- > drivers/staging/Kconfig |2 + > drivers/staging/Makefile |1 + By not including the files these files "include" you just broke the build at this point in the patch series, which isn't good. Care to redo this series, so that it can build at each step of the way (you might do this by just adding the Kconfig and Makefile entries as the last patch), and then I will be glad to apply it to the tree. Oh, and yes, this implies that I have no problem taking this driver for the staging tree :) 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 05/12] usb: feed USB device information to the /dev/random driver
On Fri, Jul 06, 2012 at 06:02:18PM -0500, Jonathan Nieder wrote: > > Why cc: stable@? Does this fix a build error, oops, hang, data > corruption, real security issue, or other critical "oh, that's not > good" bug? All of the /dev/random patches in this patch series that were marked for the stable backports are to address a security issue. See: https://factorable.net/ The main hope is that we can get the embedded device manufacturers to grab these patches sooner rather than later, so getting them into the stable backport trees is just as important, if not more so, than getting them into v3.5. While these patches are designed to do as much as we can without assuming any fixes in userspace, and the weak kea vulnerabilities are much more obviously detectable in embedded devices with close to zero available entropy, ideally there are improvements that can and should be done in upstream userspace packages as well as in the packaging and installation scripts for more general-purpose server and workstation distributions. For example, ssh key generation should happen as late as possible; ideally, some time *after* the networking has been brought up. If the ssh keys get generated while the installer is running, before the kernel has a chance to collect entropy --- especially if the user chooses to do this with the machine off the network --- well, that's unfortunate. The same is true for the generation of remote administration keys for ntpd and bind. See the extended version of the research paper for more discussion on remediation possibilities up and down the OS stack. Regards, - Ted P.S. This vulnerability was blogged about a few months ago, and it's about to be presented at the upcoming Usenix Security Symposium next month. Hence, nothing discussed here or in the patch set is a secret. Please feel free to forward this to any distribution security teams you think appropriate. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] ARM: add PROC_DEVICETREE support in Kconfig
On Fri, Jul 6, 2012 at 4:15 PM, Xiao Jiang wrote: > 2012/7/6 Rob Herring >> >> On 07/06/2012 05:38 AM, jgq...@gmail.com wrote: >> > From: Xiao Jiang >> > >> > Since more and more arm chips support device tree, it'd be better add >> > PROC_DEVICETREE >> > in arch/arm/Kconfig to avoid duplicate code. >> >> I think this should remain user choice. If its going to be selected, >> then you might as well just remove the option altogether. Perhaps just >> make the option default to yes. >> > Hmm, sounds reasonable from your point. So the better choice is to set the > option default to Y if the board has dt support just like tegra_defconfig > and at91_dt_defconfig, right? thanks. Why bother? If the defconfigs select it then most users basing their config from that will be just fine. PROC_DEVICETREE is 100% optional, it's useful to get runtime access to the contents of the device tree but it's not required for the kernel to boot. -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 05/12] usb: feed USB device information to the /dev/random driver
On Fri, Jul 06, 2012 at 06:02:18PM -0500, Jonathan Nieder wrote: > Hi, > > Theodore Ts'o wrote: > > > Send the USB device's serial, product, and manufacturer strings to the > > /dev/random driver to help seed its pools. > > > > Cc: Linus Torvalds > > Acked-by: Greg KH > > Signed-off-by: "Theodore Ts'o" > > Cc: sta...@vger.kernel.org > > Why cc: stable@? Does this fix a build error, oops, hang, data > corruption, real security issue, or other critical "oh, that's not > good" bug? > > (I can imagine some reasons but I'm asking because it's not spelled > out.) It's part of the larger series that resolves issues with the random number generator at boot time. You want these patches backported, read the original report for why. hope this helps, 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] Staging: android: fix pr_info and pr_err coding style issues in ashmem.c
On Fri, Jun 29, 2012 at 07:48:45PM +0200, Pablo Vázquez wrote: > Ok, added the #define pr_fmt(fmt) ... You sent this in HTML format, makeing it impossible to apply :( Care to try it again? 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] staging: vt6656: iwctl: mop up a few remaining obvious style issues
On Wed, Jun 27, 2012 at 09:19:15PM +0200, Jesper Juhl wrote: > My previous 14 patch series to vt6656 missed a few bits and > pieces. This mops up the last few obvious style issues. > It is quite short and completely trivial - simply deletes a few blank > lines, does some whitespace cleanup around operators and adds a few > curly braces. > > Signed-off-by: Jesper Juhl Again, one patch per thing please. Please break this up into different patches so it can be accepted. 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 2/2] staging: sm7xxfb: erase hardcode cast between smtcfb_info and fb_info
On Wed, Jun 27, 2012 at 02:10:15PM +0200, Javier M. Mellid wrote: > From: "Javier M. Mellid" > > This patch erases hardcode cast between smtcfb_info and fb_info in order > to get a more robust and less rigid smtcfb_info structure. fb_info > doesn't need to be the first field in smtcfb_info after this patch. Nice job, stuff like this is always appreciated. 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 RFC] swiotlb: Remove SWIOTLB overflow buffer support
Remove SWIOTLB overflow buffer support and return DMA_ERROR_CODE
(a value of zero) to make it consistent with iommu implementation
on Intel, AMD, and swiotlb-xen.
Tested only on x86.
Signed-off-by: Shuah Khan
---
lib/swiotlb.c | 44
1 file changed, 8 insertions(+), 36 deletions(-)
diff --git a/lib/swiotlb.c b/lib/swiotlb.c
index 45bc1f8..7f0a5d1 100644
--- a/lib/swiotlb.c
+++ b/lib/swiotlb.c
@@ -15,6 +15,7 @@
* 05/09/10 linville Add support for syncing ranges, support syncing for
* DMA_BIDIRECTIONAL mappings, miscellaneous cleanup.
* 08/12/11 beckyb Add highmem support
+ * 06/12shuahkhan Remove io tlb overflow support
*/
#include
@@ -66,13 +67,6 @@ static char *io_tlb_start, *io_tlb_end;
static unsigned long io_tlb_nslabs;
/*
- * When the IOMMU overflows we return a fallback buffer. This sets the size.
- */
-static unsigned long io_tlb_overflow = 32*1024;
-
-static void *io_tlb_overflow_buffer;
-
-/*
* This is a free list describing the number of free entries available from
* each index
*/
@@ -108,7 +102,6 @@ setup_io_tlb_npages(char *str)
return 1;
}
__setup("swiotlb=", setup_io_tlb_npages);
-/* make io_tlb_overflow tunable too? */
unsigned long swiotlb_nr_tbl(void)
{
@@ -156,12 +149,6 @@ void __init swiotlb_init_with_tbl(char *tlb, unsigned long
nslabs, int verbose)
io_tlb_index = 0;
io_tlb_orig_addr = alloc_bootmem_pages(PAGE_ALIGN(io_tlb_nslabs *
sizeof(phys_addr_t)));
- /*
-* Get the overflow emergency buffer
-*/
- io_tlb_overflow_buffer =
alloc_bootmem_low_pages(PAGE_ALIGN(io_tlb_overflow));
- if (!io_tlb_overflow_buffer)
- panic("Cannot allocate SWIOTLB overflow buffer!\n");
if (verbose)
swiotlb_print_info();
}
@@ -195,7 +182,8 @@ swiotlb_init_with_default_size(size_t default_size, int
verbose)
void __init
swiotlb_init(int verbose)
{
- swiotlb_init_with_default_size(64 * (1<<20), verbose); /* default to
64MB */
+ /* default to 64MB */
+ swiotlb_init_with_default_size(64 * (1<<20), verbose);
}
/*
@@ -264,24 +252,12 @@ swiotlb_late_init_with_default_size(size_t default_size)
memset(io_tlb_orig_addr, 0, io_tlb_nslabs * sizeof(phys_addr_t));
- /*
-* Get the overflow emergency buffer
-*/
- io_tlb_overflow_buffer = (void *)__get_free_pages(GFP_DMA,
- get_order(io_tlb_overflow));
- if (!io_tlb_overflow_buffer)
- goto cleanup4;
-
swiotlb_print_info();
late_alloc = 1;
return 0;
-cleanup4:
- free_pages((unsigned long)io_tlb_orig_addr,
- get_order(io_tlb_nslabs * sizeof(phys_addr_t)));
- io_tlb_orig_addr = NULL;
cleanup3:
free_pages((unsigned long)io_tlb_list, get_order(io_tlb_nslabs *
sizeof(int)));
@@ -297,12 +273,10 @@ cleanup1:
void __init swiotlb_free(void)
{
- if (!io_tlb_overflow_buffer)
+ if (!io_tlb_orig_addr)
return;
if (late_alloc) {
- free_pages((unsigned long)io_tlb_overflow_buffer,
- get_order(io_tlb_overflow));
free_pages((unsigned long)io_tlb_orig_addr,
get_order(io_tlb_nslabs * sizeof(phys_addr_t)));
free_pages((unsigned long)io_tlb_list, get_order(io_tlb_nslabs *
@@ -310,8 +284,6 @@ void __init swiotlb_free(void)
free_pages((unsigned long)io_tlb_start,
get_order(io_tlb_nslabs << IO_TLB_SHIFT));
} else {
- free_bootmem_late(__pa(io_tlb_overflow_buffer),
- PAGE_ALIGN(io_tlb_overflow));
free_bootmem_late(__pa(io_tlb_orig_addr),
PAGE_ALIGN(io_tlb_nslabs *
sizeof(phys_addr_t)));
free_bootmem_late(__pa(io_tlb_list),
@@ -639,7 +611,7 @@ swiotlb_full(struct device *dev, size_t size, enum
dma_data_direction dir,
printk(KERN_ERR "DMA: Out of SW-IOMMU space for %zu bytes at "
"device %s\n", size, dev ? dev_name(dev) : "?");
- if (size <= io_tlb_overflow || !do_panic)
+ if (!do_panic)
return;
if (dir == DMA_BIDIRECTIONAL)
@@ -681,7 +653,7 @@ dma_addr_t swiotlb_map_page(struct device *dev, struct page
*page,
map = map_single(dev, phys, size, dir);
if (!map) {
swiotlb_full(dev, size, dir, 1);
- map = io_tlb_overflow_buffer;
+ return DMA_ERROR_CODE;
}
dev_addr = swiotlb_virt_to_bus(dev, map);
@@ -691,7 +663,7 @@ dma_addr_t swiotlb_map_page(struct device *dev, struct page
*page,
*/
if (!dma_capable(dev, dev_addr, size)) {
swiotlb_tbl_unmap_single(dev, map, size, dir);
-
Re: [PATCH 05/12] usb: feed USB device information to the /dev/random driver
Hi, Theodore Ts'o wrote: > Send the USB device's serial, product, and manufacturer strings to the > /dev/random driver to help seed its pools. > > Cc: Linus Torvalds > Acked-by: Greg KH > Signed-off-by: "Theodore Ts'o" > Cc: sta...@vger.kernel.org Why cc: stable@? Does this fix a build error, oops, hang, data corruption, real security issue, or other critical "oh, that's not good" bug? (I can imagine some reasons but I'm asking because it's not spelled out.) Thanks, Jonathan -- 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] Staging: comedi: usbduxsigma: Syntax issue fixes
On Thu, Jun 28, 2012 at 02:01:00AM -0300, Sebastian Benvenuti wrote:
> fixed "many quoted string split across lines" issues,
> replaced "printk(KERN_ERR" for "pr_err("
> and replaced "printk(KERN_INFO" for "pr_info("
>
> Signed-off-by: Sebastian Benvenuti
Where was...
Ok, you get the idea now.
Please fix up your patch numbering and resend these properly, in a
format that makes sense (hint, your current numbering made no sense...)
Also, stop doing:
> this_usbduxsub->dux_commands, SIZEOFDUXBUFFER,
> &nsent, BULK_TIMEOUT);
> if (result < 0)
> - dev_err(&this_usbduxsub->interface->dev, "comedi%d: "
> - "could not transmit dux_command to the usb-device, "
> + dev_err(&this_usbduxsub->interface->dev, "comedi%d: " \
> + "could not transmit dux_command to the usb-device, " \
> "err=%d\n", this_usbduxsub->comedidev->minor, result);
The '\' stuff is pointless and wrong.
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 4/4] Staging: comedi: drivers: usbduxfast: fixed several syntax issues
On Thu, Jun 28, 2012 at 01:47:09AM -0300, Sebastian Benvenuti wrote:
> Fixed +40 "quoted string split across lines" issues
> plus some lines that were over 80 chars
> and a "pr_info(" function replaced "printk(KERN_INFO"
>
> Signed-off-by: Sebastian Benvenuti
Where was patches 1/4, 2/4, and 3/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 00/36] AArch64 Linux kernel port
> arch/x86/include/asm/atomic64_32.h |1 + > arch/x86/include/asm/atomic64_64.h |1 + > arch/xtensa/kernel/syscall.c|2 +- This looks odd to say the least ? The only other question I'd ask is given that ppc and x86 have both done 32/64bit separate architectures and then gone the other way is that something ARM 64bit needs to think about ? Alan -- 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/3] Staging: comedi: drivers: usbduxfast: changed "printk(KERN_DEBUG ..." for "pr_debug(..."
On Thu, Jun 28, 2012 at 01:28:20AM -0300, Sebastian Benvenuti wrote: > changed 41 instances of printk(KERN_DEBUG for the prefered pr_debug( > > Signed-off-by: Sebastian Benvenuti Where was patches 1/3 and 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 2/2] Staging: comedi: drivers: usbduxfast: changed "printk(KERN_ERR ..." for "pr_err(..."
On Thu, Jun 28, 2012 at 01:23:47AM -0300, Sebastian Benvenuti wrote: > changed 3 instances of printk(KERN_ERR for the prefered pr_err( > > Signed-off-by: Sebastian Benvenuti Where was patch 1/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] Staging: comedi: vmk80xx: All syntax issues fixed
On Thu, Jun 28, 2012 at 10:28:57PM -0300, Sebastian Benvenuti wrote:
> @@ -1462,7 +1461,7 @@ static int __init vmk80xx_init(void)
> {
> int retval;
>
> - printk(KERN_INFO "vmk80xx: version 0.8.01 "
> + pr_info("vmk80xx: version 0.8.01 " \
> "Manuel Gebele \n");
What's with the crazy '\' usage here? That does nothing :(
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 02/12] random: make 'add_interrupt_randomness()' do something sane
We've been moving away from add_interrupt_randomness() for various
reasons: it's too expensive to do on every interrupt, and flooding the
CPU with interrupts could theoretically cause bogus floods of entropy
from a somewhat externally controllable source.
This solves both problems by limiting the actual randomness addition
to just once a second or after 128 interrupts, whicever comes first.
During that time, the interrupt cycle data is buffered up in a per-cpu
pool. Also, we make sure the the nonblocking pool used by urandom is
initialized before we start feeding the normal input pool. This
assures that /dev/urandom is returning unpredictable data as soon as
possible.
(Based on an original patch by Linus, but significantly modified by
tytso.)
Tested-by: Eric Wustrow
Reported-by: Eric Wustrow
Reported-by: Nadia Heninger
Reported-by: Zakir Durumeric
Reported-by: J. Alex Halderman .
Signed-off-by: Linus Torvalds
Signed-off-by: "Theodore Ts'o"
Cc: sta...@vger.kernel.org
---
drivers/char/random.c | 103 ++
drivers/mfd/ab3100-core.c | 2 -
include/linux/random.h| 2 +-
kernel/irq/handle.c | 7 ++--
4 files changed, 90 insertions(+), 24 deletions(-)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index cb541b9..556088b 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -127,19 +127,15 @@
*
* void add_input_randomness(unsigned int type, unsigned int code,
*unsigned int value);
- * void add_interrupt_randomness(int irq);
+ * void add_interrupt_randomness(int irq, int irq_flags);
* void add_disk_randomness(struct gendisk *disk);
*
* add_input_randomness() uses the input layer interrupt timing, as well as
* the event type information from the hardware.
*
- * add_interrupt_randomness() uses the inter-interrupt timing as random
- * inputs to the entropy pool. Note that not all interrupts are good
- * sources of randomness! For example, the timer interrupts is not a
- * good choice, because the periodicity of the interrupts is too
- * regular, and hence predictable to an attacker. Network Interface
- * Controller interrupts are a better measure, since the timing of the
- * NIC interrupts are more unpredictable.
+ * add_interrupt_randomness() uses the interrupt timing as random
+ * inputs to the entropy pool. Using the cycle counters and the irq source
+ * as inputs, it feeds the randomness roughly once a second.
*
* add_disk_randomness() uses what amounts to the seek time of block
* layer request events, on a per-disk_devt basis, as input to the
@@ -248,6 +244,7 @@
#include
#include
#include
+#include
#ifdef CONFIG_GENERIC_HARDIRQS
# include
@@ -256,6 +253,7 @@
#include
#include
#include
+#include
#include
/*
@@ -421,7 +419,9 @@ struct entropy_store {
spinlock_t lock;
unsigned add_ptr;
int entropy_count;
+ int entropy_total;
int input_rotate;
+ unsigned int initialized:1;
__u8 last_data[EXTRACT_SIZE];
};
@@ -454,6 +454,10 @@ static struct entropy_store nonblocking_pool = {
.pool = nonblocking_pool_data
};
+static __u32 const twist_table[8] = {
+ 0x, 0x3b6e20c8, 0x76dc4190, 0x4db26158,
+ 0xedb88320, 0xd6d6a3e8, 0x9b64c2b0, 0xa00ae278 };
+
/*
* This function adds bytes into the entropy "pool". It does not
* update the entropy estimate. The caller should call
@@ -467,9 +471,6 @@ static struct entropy_store nonblocking_pool = {
static void mix_pool_bytes_extract(struct entropy_store *r, const void *in,
int nbytes, __u8 out[64])
{
- static __u32 const twist_table[8] = {
- 0x, 0x3b6e20c8, 0x76dc4190, 0x4db26158,
- 0xedb88320, 0xd6d6a3e8, 0x9b64c2b0, 0xa00ae278 };
unsigned long i, j, tap1, tap2, tap3, tap4, tap5;
int input_rotate;
int wordmask = r->poolinfo->poolwords - 1;
@@ -528,6 +529,36 @@ static void mix_pool_bytes(struct entropy_store *r, const
void *in, int bytes)
mix_pool_bytes_extract(r, in, bytes, NULL);
}
+struct fast_pool {
+ __u32 pool[4];
+ unsigned long last;
+ unsigned short count;
+ unsigned char rotate;
+ unsigned char last_timer_intr;
+};
+
+/*
+ * This is a fast mixing routine used by the interrupt randomness
+ * collector. It's hardcoded for an 128 bit pool and assumes that any
+ * locks that might be needed are taken by the caller.
+ */
+static void fast_mix(struct fast_pool *f, const void *in, int nbytes)
+{
+ const char *bytes = in;
+ __u32 w;
+ unsignedi = f->count;
+ unsignedinput_rotate = f->rotate;
+
+ while (nbytes--) {
+ w = rol32(*bytes++, input_rotate & 31) ^ f->pool[i & 3] ^
+ f->pool[(i + 1) & 3];
+ f->pool[i & 3] = (w >> 3) ^ twist_tabl
[PATCH 12/12] mfd: wm831x: Feed the device UUID into device_add_randomness()
From: Mark Brown
wm831x devices contain a unique ID value. Feed this into the newly added
device_add_randomness() to add some per device seed data to the pool.
Signed-off-by: Mark Brown
Signed-off-by: Theodore Ts'o
Cc: sta...@vger.kernel.org
---
drivers/mfd/wm831x-otp.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/mfd/wm831x-otp.c b/drivers/mfd/wm831x-otp.c
index f742745..b90f3e0 100644
--- a/drivers/mfd/wm831x-otp.c
+++ b/drivers/mfd/wm831x-otp.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include
#include
@@ -66,6 +67,7 @@ static DEVICE_ATTR(unique_id, 0444, wm831x_unique_id_show,
NULL);
int wm831x_otp_init(struct wm831x *wm831x)
{
+ char uuid[WM831X_UNIQUE_ID_LEN];
int ret;
ret = device_create_file(wm831x->dev, &dev_attr_unique_id);
@@ -73,6 +75,12 @@ int wm831x_otp_init(struct wm831x *wm831x)
dev_err(wm831x->dev, "Unique ID attribute not created: %d\n",
ret);
+ ret = wm831x_unique_id_read(wm831x, uuid);
+ if (ret == 0)
+ add_device_randomness(uuid, sizeof(uuid));
+ else
+ dev_err(wm831x->dev, "Failed to read UUID: %d\n", ret);
+
return ret;
}
--
1.7.11.1.108.gb129051
--
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] MFD: twl-core: move device_init_wakeup to after platform_device_add.
device_init_wakeup uses the dev_name() of the device to set the
name of the wakeup_source which appears in
/sys/kernel/debug/wakeup_sources.
For a platform device, that name is not set until platform_device_add
calls dev_set_name.
So the call to device_init_wakeup() must be after the call to
platform_device_add().
Making this change causes correct names to appear in the
wakeup_sources file.
Signed-off-by: NeilBrown
diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
index 6fc90be..b012efd 100644
--- a/drivers/mfd/twl-core.c
+++ b/drivers/mfd/twl-core.c
@@ -568,7 +568,6 @@ add_numbered_child(unsigned chip, const char *name, int num,
goto err;
}
- device_init_wakeup(&pdev->dev, can_wakeup);
pdev->dev.parent = &twl->client->dev;
if (pdata) {
@@ -593,6 +592,8 @@ add_numbered_child(unsigned chip, const char *name, int num,
}
status = platform_device_add(pdev);
+ if (status == 0)
+ device_init_wakeup(&pdev->dev, can_wakeup);
err:
if (status < 0) {
signature.asc
Description: PGP signature
[PATCH 00/12] /dev/random fixups
This version fixes some sparse complaints; reduces stack usage in xfer_secondary_pool; fixes a lockdep complaint caused by get_random_bytes() getting called from interrupt context; and other minor updates as requested by patch reviewers. - Ted Linus Torvalds (1): random: create add_device_randomness() interface Mark Brown (2): rtc: wm831x: Feed the write counter into device_add_randomness() mfd: wm831x: Feed the device UUID into device_add_randomness() Theodore Ts'o (9): random: fix up sparse warnings random: make 'add_interrupt_randomness()' do something sane random: use lockless techniques in the interrupt path usb: feed USB device information to the /dev/random driver net: feed /dev/random with the MAC address when registering a device random: use the arch-specific rng in xfer_secondary_pool random: add new get_random_bytes_arch() function random: add tracepoints for easier debugging and verification MAINTAINERS: Theodore Ts'o is taking over the random driver MAINTAINERS | 4 +- drivers/char/random.c | 274 +++--- drivers/mfd/ab3100-core.c | 2 - drivers/mfd/wm831x-otp.c | 8 ++ drivers/rtc/rtc-wm831x.c | 24 +++- drivers/usb/core/hub.c| 9 ++ include/linux/random.h| 4 +- include/trace/events/random.h | 134 + kernel/irq/handle.c | 7 +- net/core/dev.c| 3 + net/core/rtnetlink.c | 1 + 11 files changed, 393 insertions(+), 77 deletions(-) create mode 100644 include/trace/events/random.h -- 1.7.11.1.108.gb129051 -- 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 08/12] random: add new get_random_bytes_arch() function
Create a new function, get_random_bytes_arch() which will use the
architecture-specific hardware random number generator if it is
present. Change get_random_bytes() to not use the HW RNG, even if it
is avaiable.
The reason for this is that the hw random number generator is fast (if
it is present), but it requires that we trust the hardware
manufacturer to have not put in a back door. (For example, an
increasing counter encrypted by an AES key known to the NSA.)
It's unlikely that Intel (for example) was paid off by the US
Government to do this, but it's impossible for them to prove otherwise
--- especially since Bull Mountain is documented to use AES as a
whitener. Hence, the output of an evil, trojan-horse version of
RDRAND is statistically indistinguishable from an RDRAND implemented
to the specifications claimed by Intel. Short of using a tunnelling
electronic microscope to reverse engineer an Ivy Bridge chip and
disassembling and analyzing the CPU microcode, there's no way for us
to tell for sure.
Since users of get_random_bytes() in the Linux kernel need to be able
to support hardware systems where the HW RNG is not present, most
time-sensitive users of this interface have already created their own
cryptographic RNG interface which uses get_random_bytes() as a seed.
So it's much better to use the HW RNG to improve the existing random
number generator, by mixing in any entropy returned by the HW RNG into
/dev/random's entropy pool, but to always _use_ /dev/random's entropy
pool.
This way we get almost of the benefits of the HW RNG without any
potential liabilities. The only benefits we forgo is the
speed/performance enhancements --- and generic kernel code can't
depend on depend on get_random_bytes() having the speed of a HW RNG
anyway.
For those places that really want access to the arch-specific HW RNG,
if it is available, we provide get_random_bytes_arch().
Signed-off-by: "Theodore Ts'o"
Cc: sta...@vger.kernel.org
---
drivers/char/random.c | 29 -
include/linux/random.h | 1 +
2 files changed, 25 insertions(+), 5 deletions(-)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index c39bdc4..79c105a 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -1036,17 +1036,34 @@ static ssize_t extract_entropy_user(struct
entropy_store *r, void __user *buf,
/*
* This function is the exported kernel interface. It returns some
- * number of good random numbers, suitable for seeding TCP sequence
- * numbers, etc.
+ * number of good random numbers, suitable for key generation, seeding
+ * TCP sequence numbers, etc. It does not use the hw random number
+ * generator, if available; use get_random_bytes_arch() for that.
*/
void get_random_bytes(void *buf, int nbytes)
{
+ extract_entropy(&nonblocking_pool, buf, nbytes, 0, 0);
+}
+EXPORT_SYMBOL(get_random_bytes);
+
+/*
+ * This function will use the architecture-specific hardware random
+ * number generator if it is available. The arch-specific hw RNG will
+ * almost certainly be faster than what we can do in software, but it
+ * is impossible to verify that it is implemented securely (as
+ * opposed, to, say, the AES encryption of a sequence number using a
+ * key known by the NSA). So it's useful if we need the speed, but
+ * only if we're willing to trust the hardware manufacturer not to
+ * have put in a back door.
+ */
+void get_random_bytes_arch(void *buf, int nbytes)
+{
char *p = buf;
while (nbytes) {
unsigned long v;
int chunk = min(nbytes, (int)sizeof(unsigned long));
-
+
if (!arch_get_random_long(&v))
break;
@@ -1055,9 +1072,11 @@ void get_random_bytes(void *buf, int nbytes)
nbytes -= chunk;
}
- extract_entropy(&nonblocking_pool, p, nbytes, 0, 0);
+ if (nbytes)
+ extract_entropy(&nonblocking_pool, p, nbytes, 0, 0);
}
-EXPORT_SYMBOL(get_random_bytes);
+EXPORT_SYMBOL(get_random_bytes_arch);
+
/*
* init_std_data - initialize pool with system data
diff --git a/include/linux/random.h b/include/linux/random.h
index e14b438..29e217a 100644
--- a/include/linux/random.h
+++ b/include/linux/random.h
@@ -56,6 +56,7 @@ extern void add_input_randomness(unsigned int type, unsigned
int code,
extern void add_interrupt_randomness(int irq, int irq_flags);
extern void get_random_bytes(void *buf, int nbytes);
+extern void get_random_bytes_arch(void *buf, int nbytes);
void generate_random_uuid(unsigned char uuid_out[16]);
#ifndef MODULE
--
1.7.11.1.108.gb129051
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 01/12] random: fix up sparse warnings
Add extern and static declarations to suppress sparse warnings
Signed-off-by: "Theodore Ts'o"
---
drivers/char/random.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index 4ec04a7..cb541b9 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -1279,6 +1279,7 @@ static int proc_do_uuid(ctl_table *table, int write,
}
static int sysctl_poolsize = INPUT_POOL_WORDS * 32;
+extern ctl_table random_table[];
ctl_table random_table[] = {
{
.procname = "poolsize",
@@ -1344,7 +1345,7 @@ late_initcall(random_int_secret_init);
* value is not cryptographically secure but for several uses the cost of
* depleting entropy is too high
*/
-DEFINE_PER_CPU(__u32 [MD5_DIGEST_WORDS], get_random_int_hash);
+static DEFINE_PER_CPU(__u32 [MD5_DIGEST_WORDS], get_random_int_hash);
unsigned int get_random_int(void)
{
__u32 *hash;
--
1.7.11.1.108.gb129051
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 03/12] random: use lockless techniques in the interrupt path
The real-time Linux folks don't like add_interrupt_randomness() taking
a spinlock since it is called in the low-level interrupt routine.
This also allows us to reduce the overhead in the fast path, for the
random driver, which is the interrupt collection path.
Signed-off-by: "Theodore Ts'o"
Cc: sta...@vger.kernel.org
---
drivers/char/random.c | 78 +--
1 file changed, 39 insertions(+), 39 deletions(-)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index 556088b..09a11d8 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -418,9 +418,9 @@ struct entropy_store {
/* read-write data: */
spinlock_t lock;
unsigned add_ptr;
+ unsigned input_rotate;
int entropy_count;
int entropy_total;
- int input_rotate;
unsigned int initialized:1;
__u8 last_data[EXTRACT_SIZE];
};
@@ -468,26 +468,24 @@ static __u32 const twist_table[8] = {
* it's cheap to do so and helps slightly in the expected case where
* the entropy is concentrated in the low-order bits.
*/
-static void mix_pool_bytes_extract(struct entropy_store *r, const void *in,
- int nbytes, __u8 out[64])
+static void __mix_pool_bytes(struct entropy_store *r, const void *in,
+int nbytes, __u8 out[64])
{
unsigned long i, j, tap1, tap2, tap3, tap4, tap5;
int input_rotate;
int wordmask = r->poolinfo->poolwords - 1;
const char *bytes = in;
__u32 w;
- unsigned long flags;
- /* Taps are constant, so we can load them without holding r->lock. */
tap1 = r->poolinfo->tap1;
tap2 = r->poolinfo->tap2;
tap3 = r->poolinfo->tap3;
tap4 = r->poolinfo->tap4;
tap5 = r->poolinfo->tap5;
- spin_lock_irqsave(&r->lock, flags);
- input_rotate = r->input_rotate;
- i = r->add_ptr;
+ smp_rmb();
+ input_rotate = ACCESS_ONCE(r->input_rotate);
+ i = ACCESS_ONCE(r->add_ptr);
/* mix one byte at a time to simplify size handling and churn faster */
while (nbytes--) {
@@ -514,19 +512,23 @@ static void mix_pool_bytes_extract(struct entropy_store
*r, const void *in,
input_rotate += i ? 7 : 14;
}
- r->input_rotate = input_rotate;
- r->add_ptr = i;
+ ACCESS_ONCE(r->input_rotate) = input_rotate;
+ ACCESS_ONCE(r->add_ptr) = i;
+ smp_wmb();
if (out)
for (j = 0; j < 16; j++)
((__u32 *)out)[j] = r->pool[(i - j) & wordmask];
-
- spin_unlock_irqrestore(&r->lock, flags);
}
-static void mix_pool_bytes(struct entropy_store *r, const void *in, int bytes)
+static void mix_pool_bytes(struct entropy_store *r, const void *in,
+int nbytes, __u8 out[64])
{
- mix_pool_bytes_extract(r, in, bytes, NULL);
+ unsigned long flags;
+
+ spin_lock_irqsave(&r->lock, flags);
+ __mix_pool_bytes(r, in, nbytes, out);
+ spin_unlock_irqrestore(&r->lock, flags);
}
struct fast_pool {
@@ -564,23 +566,22 @@ static void fast_mix(struct fast_pool *f, const void *in,
int nbytes)
*/
static void credit_entropy_bits(struct entropy_store *r, int nbits)
{
- unsigned long flags;
- int entropy_count;
+ int entropy_count, orig;
if (!nbits)
return;
- spin_lock_irqsave(&r->lock, flags);
-
DEBUG_ENT("added %d entropy credits to %s\n", nbits, r->name);
- entropy_count = r->entropy_count;
+retry:
+ entropy_count = orig = ACCESS_ONCE(r->entropy_count);
entropy_count += nbits;
if (entropy_count < 0) {
DEBUG_ENT("negative entropy/overflow\n");
entropy_count = 0;
} else if (entropy_count > r->poolinfo->POOLBITS)
entropy_count = r->poolinfo->POOLBITS;
- r->entropy_count = entropy_count;
+ if (cmpxchg(&r->entropy_count, orig, entropy_count) != orig)
+ goto retry;
if (!r->initialized && nbits > 0) {
r->entropy_total += nbits;
@@ -593,7 +594,6 @@ static void credit_entropy_bits(struct entropy_store *r,
int nbits)
wake_up_interruptible(&random_read_wait);
kill_fasync(&fasync, SIGIO, POLL_IN);
}
- spin_unlock_irqrestore(&r->lock, flags);
}
/*
@@ -680,7 +680,7 @@ static void add_timer_randomness(struct timer_rand_state
*state, unsigned num)
sample.cycles = get_cycles();
sample.num = num;
- mix_pool_bytes(&input_pool, &sample, sizeof(sample));
+ mix_pool_bytes(&input_pool, &sample, sizeof(sample), NULL);
/*
* Calculate number of bits of randomness we probably added.
@@ -764,7 +764,7 @@ void add_interrupt_randomness(int irq, int irq_flags)
fast_pool->last = now;
[PATCH 10/12] MAINTAINERS: Theodore Ts'o is taking over the random driver
Matt Mackall stepped down as the /dev/random driver maintainer last year, so Theodore Ts'o is taking back the /dev/random driver. Cc: Matt Mackall Signed-off-by: "Theodore Ts'o" --- MAINTAINERS | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index eb22272..808cceb 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3159,9 +3159,9 @@ F:drivers/hwmon/ F: include/linux/hwmon*.h HARDWARE RANDOM NUMBER GENERATOR CORE -M: Matt Mackall +M: Theodore Ts'o" M: Herbert Xu -S: Odd fixes +S: Maintained F: Documentation/hw_random.txt F: drivers/char/hw_random/ F: include/linux/hw_random.h -- 1.7.11.1.108.gb129051 -- 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 09/12] random: add tracepoints for easier debugging and verification
Signed-off-by: "Theodore Ts'o"
---
drivers/char/random.c | 26 ++--
include/trace/events/random.h | 134 ++
2 files changed, 156 insertions(+), 4 deletions(-)
create mode 100644 include/trace/events/random.h
diff --git a/drivers/char/random.c b/drivers/char/random.c
index 79c105a..aaf4629 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -265,6 +265,9 @@
#include
#include
+#define CREATE_TRACE_POINTS
+#include
+
/*
* Configuration information
*/
@@ -477,8 +480,8 @@ static __u32 const twist_table[8] = {
* it's cheap to do so and helps slightly in the expected case where
* the entropy is concentrated in the low-order bits.
*/
-static void __mix_pool_bytes(struct entropy_store *r, const void *in,
-int nbytes, __u8 out[64])
+static void _mix_pool_bytes(struct entropy_store *r, const void *in,
+ int nbytes, __u8 out[64])
{
unsigned long i, j, tap1, tap2, tap3, tap4, tap5;
int input_rotate;
@@ -530,13 +533,21 @@ static void __mix_pool_bytes(struct entropy_store *r,
const void *in,
((__u32 *)out)[j] = r->pool[(i - j) & wordmask];
}
-static void mix_pool_bytes(struct entropy_store *r, const void *in,
+static void __mix_pool_bytes(struct entropy_store *r, const void *in,
int nbytes, __u8 out[64])
{
+ trace_mix_pool_bytes_nolock(r->name, nbytes, _RET_IP_);
+ _mix_pool_bytes(r, in, nbytes, out);
+}
+
+static void mix_pool_bytes(struct entropy_store *r, const void *in,
+ int nbytes, __u8 out[64])
+{
unsigned long flags;
+ trace_mix_pool_bytes(r->name, nbytes, _RET_IP_);
spin_lock_irqsave(&r->lock, flags);
- __mix_pool_bytes(r, in, nbytes, out);
+ _mix_pool_bytes(r, in, nbytes, out);
spin_unlock_irqrestore(&r->lock, flags);
}
@@ -584,6 +595,7 @@ static void credit_entropy_bits(struct entropy_store *r,
int nbits)
retry:
entropy_count = orig = ACCESS_ONCE(r->entropy_count);
entropy_count += nbits;
+
if (entropy_count < 0) {
DEBUG_ENT("negative entropy/overflow\n");
entropy_count = 0;
@@ -598,6 +610,9 @@ retry:
r->initialized = 1;
}
+ trace_credit_entropy_bits(r->name, nbits, entropy_count,
+ r->entropy_total, _RET_IP_);
+
/* should we wake readers? */
if (r == &input_pool && entropy_count >= random_read_wakeup_thresh) {
wake_up_interruptible(&random_read_wait);
@@ -969,6 +984,7 @@ static ssize_t extract_entropy(struct entropy_store *r,
void *buf,
ssize_t ret = 0, i;
__u8 tmp[EXTRACT_SIZE];
+ trace_extract_entropy(r->name, nbytes, r->entropy_count, _RET_IP_);
xfer_secondary_pool(r, nbytes);
nbytes = account(r, nbytes, min, reserved);
@@ -1003,6 +1019,7 @@ static ssize_t extract_entropy_user(struct entropy_store
*r, void __user *buf,
ssize_t ret = 0, i;
__u8 tmp[EXTRACT_SIZE];
+ trace_extract_entropy_user(r->name, nbytes, r->entropy_count, _RET_IP_);
xfer_secondary_pool(r, nbytes);
nbytes = account(r, nbytes, 0, 0);
@@ -1060,6 +1077,7 @@ void get_random_bytes_arch(void *buf, int nbytes)
{
char *p = buf;
+ trace_get_random_bytes(nbytes, _RET_IP_);
while (nbytes) {
unsigned long v;
int chunk = min(nbytes, (int)sizeof(unsigned long));
diff --git a/include/trace/events/random.h b/include/trace/events/random.h
new file mode 100644
index 000..422df19
--- /dev/null
+++ b/include/trace/events/random.h
@@ -0,0 +1,134 @@
+#undef TRACE_SYSTEM
+#define TRACE_SYSTEM random
+
+#if !defined(_TRACE_RANDOM_H) || defined(TRACE_HEADER_MULTI_READ)
+#define _TRACE_RANDOM_H
+
+#include
+#include
+
+DECLARE_EVENT_CLASS(random__mix_pool_bytes,
+ TP_PROTO(const char *pool_name, int bytes, unsigned long IP),
+
+ TP_ARGS(pool_name, bytes, IP),
+
+ TP_STRUCT__entry(
+ __field( const char *, pool_name )
+ __field( int, bytes )
+ __field(unsigned long, IP )
+ ),
+
+ TP_fast_assign(
+ __entry->pool_name = pool_name;
+ __entry->bytes = bytes;
+ __entry->IP = IP;
+ ),
+
+ TP_printk("%s pool: bytes %d caller %pF",
+ __entry->pool_name, __entry->bytes, (void *)__entry->IP)
+);
+
+DEFINE_EVENT(random__mix_pool_bytes, mix_pool_bytes,
+ TP_PROTO(const char *pool_name, int bytes, unsigned long IP),
+
+ TP_ARGS(pool_name, bytes, IP)
+);
+
+DEFINE_EVENT(random__mix_pool_bytes, mix_pool_bytes_nolock,
+ TP_PROTO(const char *pool_name, int bytes, unsigned long IP),
+
+ TP_ARGS(pool_name, bytes, IP)
+);
+
+TRACE
[PATCH 06/12] net: feed /dev/random with the MAC address when registering a device
Cc: David Miller
Cc: Linus Torvalds
Signed-off-by: "Theodore Ts'o"
Cc: sta...@vger.kernel.org
---
net/core/dev.c | 3 +++
net/core/rtnetlink.c | 1 +
2 files changed, 4 insertions(+)
diff --git a/net/core/dev.c b/net/core/dev.c
index 6df2140..bdd1e88 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1172,6 +1172,7 @@ static int __dev_open(struct net_device *dev)
net_dmaengine_get();
dev_set_rx_mode(dev);
dev_activate(dev);
+ add_device_randomness(dev->dev_addr, dev->addr_len);
}
return ret;
@@ -4763,6 +4764,7 @@ int dev_set_mac_address(struct net_device *dev, struct
sockaddr *sa)
err = ops->ndo_set_mac_address(dev, sa);
if (!err)
call_netdevice_notifiers(NETDEV_CHANGEADDR, dev);
+ add_device_randomness(dev->dev_addr, dev->addr_len);
return err;
}
EXPORT_SYMBOL(dev_set_mac_address);
@@ -5541,6 +5543,7 @@ int register_netdevice(struct net_device *dev)
dev_init_scheduler(dev);
dev_hold(dev);
list_netdevice(dev);
+ add_device_randomness(dev->dev_addr, dev->addr_len);
/* Notify protocols, that a new device appeared. */
ret = call_netdevice_notifiers(NETDEV_REGISTER, dev);
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index 21318d1..f058e59 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -1378,6 +1378,7 @@ static int do_setlink(struct net_device *dev, struct
ifinfomsg *ifm,
goto errout;
send_addr_notify = 1;
modified = 1;
+ add_device_randomness(dev->dev_addr, dev->addr_len);
}
if (tb[IFLA_MTU]) {
--
1.7.11.1.108.gb129051
--
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 11/12] rtc: wm831x: Feed the write counter into device_add_randomness()
From: Mark Brown
The tamper evident features of the RTC include the "write counter" which
is a pseudo-random number regenerated whenever we set the RTC. Since this
value is unpredictable it should provide some useful seeding to the random
number generator.
Only do this on boot since the goal is to seed the pool rather than add
useful entropy.
Signed-off-by: Mark Brown
Signed-off-by: Theodore Ts'o
Cc: sta...@vger.kernel.org
---
drivers/rtc/rtc-wm831x.c | 24 +++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git a/drivers/rtc/rtc-wm831x.c b/drivers/rtc/rtc-wm831x.c
index 59c6245..ea5c6f8 100644
--- a/drivers/rtc/rtc-wm831x.c
+++ b/drivers/rtc/rtc-wm831x.c
@@ -24,7 +24,7 @@
#include
#include
#include
-
+#include
/*
* R16416 (0x4020) - RTC Write Counter
@@ -96,6 +96,26 @@ struct wm831x_rtc {
unsigned int alarm_enabled:1;
};
+static void wm831x_rtc_add_randomness(struct wm831x *wm831x)
+{
+ int ret;
+ u16 reg;
+
+ /*
+* The write counter contains a pseudo-random number which is
+* regenerated every time we set the RTC so it should be a
+* useful per-system source of entropy.
+*/
+ ret = wm831x_reg_read(wm831x, WM831X_RTC_WRITE_COUNTER);
+ if (ret >= 0) {
+ reg = ret;
+ add_device_randomness(®, sizeof(reg));
+ } else {
+ dev_warn(wm831x->dev, "Failed to read RTC write counter: %d\n",
+ret);
+ }
+}
+
/*
* Read current time and date in RTC
*/
@@ -431,6 +451,8 @@ static int wm831x_rtc_probe(struct platform_device *pdev)
alm_irq, ret);
}
+ wm831x_rtc_add_randomness(wm831x);
+
return 0;
err:
--
1.7.11.1.108.gb129051
--
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 04/12] random: create add_device_randomness() interface
From: Linus Torvalds
Add a new interface, add_device_randomness() for adding data to the
random pool that is likely to differ between two devices (or possibly
even per boot). This would be things like MAC addresses or serial
numbers, or the read-out of the RTC. This does *not* add any actual
entropy to the pool, but it initializes the pool to different values
for devices that might otherwise be identical and have very little
entropy available to them (particularly common in the embedded world).
[ Modified by tytso to mix in a timestamp, since there may be some
variability caused by the time needed to detect/configure the hardware
in question. ]
Signed-off-by: Linus Torvalds
Signed-off-by: "Theodore Ts'o"
Cc: sta...@vger.kernel.org
---
drivers/char/random.c | 28
include/linux/random.h | 1 +
2 files changed, 29 insertions(+)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index 09a11d8..e867409 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -125,11 +125,20 @@
* The current exported interfaces for gathering environmental noise
* from the devices are:
*
+ * void add_device_randomness(const void *buf, unsigned int size);
* void add_input_randomness(unsigned int type, unsigned int code,
*unsigned int value);
* void add_interrupt_randomness(int irq, int irq_flags);
* void add_disk_randomness(struct gendisk *disk);
*
+ * add_device_randomness() is for adding data to the random pool that
+ * is likely to differ between two devices (or possibly even per boot).
+ * This would be things like MAC addresses or serial numbers, or the
+ * read-out of the RTC. This does *not* add any actual entropy to the
+ * pool, but it initializes the pool to different values for devices
+ * that might otherwise be identical and have very little entropy
+ * available to them (particularly common in the embedded world).
+ *
* add_input_randomness() uses the input layer interrupt timing, as well as
* the event type information from the hardware.
*
@@ -646,6 +655,25 @@ static void set_timer_rand_state(unsigned int irq,
}
#endif
+/*
+ * Add device- or boot-specific data to the input and nonblocking
+ * pools to help initialize them to unique values.
+ *
+ * None of this adds any entropy, it is meant to avoid the
+ * problem of the nonblocking pool having similar initial state
+ * across largely identical devices.
+ */
+void add_device_randomness(const void *buf, unsigned int size)
+{
+ unsigned long time = get_cycles() ^ jiffies;
+
+ mix_pool_bytes(&input_pool, buf, size, NULL);
+ mix_pool_bytes(&input_pool, &time, sizeof(time), NULL);
+ mix_pool_bytes(&nonblocking_pool, buf, size, NULL);
+ mix_pool_bytes(&nonblocking_pool, &time, sizeof(time), NULL);
+}
+EXPORT_SYMBOL(add_device_randomness);
+
static struct timer_rand_state input_timer_state;
/*
diff --git a/include/linux/random.h b/include/linux/random.h
index 6ef39d7..e14b438 100644
--- a/include/linux/random.h
+++ b/include/linux/random.h
@@ -50,6 +50,7 @@ struct rnd_state {
extern void rand_initialize_irq(int irq);
+extern void add_device_randomness(const void *, unsigned int);
extern void add_input_randomness(unsigned int type, unsigned int code,
unsigned int value);
extern void add_interrupt_randomness(int irq, int irq_flags);
--
1.7.11.1.108.gb129051
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 07/12] random: use the arch-specific rng in xfer_secondary_pool
If the CPU supports a hardware random number generator, use it in
xfer_secondary_pool(), where it will significantly improve things and
where we can afford it.
Also, remove the use of the arch-specific rng in
add_timer_randomness(), since the call is significantly slower than
get_cycles(), and we're much better off using it in
xfer_secondary_pool() anyway.
Signed-off-by: "Theodore Ts'o"
Cc: sta...@vger.kernel.org
---
drivers/char/random.c | 23 ++-
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index e867409..c39bdc4 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -702,11 +702,7 @@ static void add_timer_randomness(struct timer_rand_state
*state, unsigned num)
goto out;
sample.jiffies = jiffies;
-
- /* Use arch random value, fall back to cycles */
- if (!arch_get_random_int(&sample.cycles))
- sample.cycles = get_cycles();
-
+ sample.cycles = get_cycles();
sample.num = num;
mix_pool_bytes(&input_pool, &sample, sizeof(sample), NULL);
@@ -838,7 +834,11 @@ static ssize_t extract_entropy(struct entropy_store *r,
void *buf,
*/
static void xfer_secondary_pool(struct entropy_store *r, size_t nbytes)
{
- __u32 tmp[OUTPUT_POOL_WORDS];
+ union {
+ __u32 tmp[OUTPUT_POOL_WORDS];
+ longhwrand[4];
+ } u;
+ int i;
if (r->pull && r->entropy_count < nbytes * 8 &&
r->entropy_count < r->poolinfo->POOLBITS) {
@@ -849,17 +849,22 @@ static void xfer_secondary_pool(struct entropy_store *r,
size_t nbytes)
/* pull at least as many as BYTES as wakeup BITS */
bytes = max_t(int, bytes, random_read_wakeup_thresh / 8);
/* but never more than the buffer size */
- bytes = min_t(int, bytes, sizeof(tmp));
+ bytes = min_t(int, bytes, sizeof(u.tmp));
DEBUG_ENT("going to reseed %s with %d bits "
"(%d of %d requested)\n",
r->name, bytes * 8, nbytes * 8, r->entropy_count);
- bytes = extract_entropy(r->pull, tmp, bytes,
+ bytes = extract_entropy(r->pull, u.tmp, bytes,
random_read_wakeup_thresh / 8, rsvd);
- mix_pool_bytes(r, tmp, bytes, NULL);
+ mix_pool_bytes(r, u.tmp, bytes, NULL);
credit_entropy_bits(r, bytes*8);
}
+ for (i = 0; i < 4; i++)
+ if (arch_get_random_long(&u.hwrand[i]))
+ break;
+ if (i)
+ mix_pool_bytes(r, &u.hwrand, sizeof(u.hwrand), 0);
}
/*
--
1.7.11.1.108.gb129051
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 05/12] usb: feed USB device information to the /dev/random driver
Send the USB device's serial, product, and manufacturer strings to the /dev/random driver to help seed its pools. Cc: Linus Torvalds Acked-by: Greg KH Signed-off-by: "Theodore Ts'o" Cc: sta...@vger.kernel.org --- drivers/usb/core/hub.c | 9 + 1 file changed, 9 insertions(+) diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c index 25a7422..7f380ff 100644 --- a/drivers/usb/core/hub.c +++ b/drivers/usb/core/hub.c @@ -24,6 +24,7 @@ #include #include #include +#include #include #include @@ -2173,6 +2174,14 @@ int usb_new_device(struct usb_device *udev) /* Tell the world! */ announce_device(udev); + if (udev->serial) + add_device_randomness(udev->serial, strlen(udev->serial)); + if (udev->product) + add_device_randomness(udev->product, strlen(udev->product)); + if (udev->manufacturer) + add_device_randomness(udev->manufacturer, + strlen(udev->manufacturer)); + device_enable_async_suspend(&udev->dev); /* -- 1.7.11.1.108.gb129051 -- 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 2/4] NET ethernet introduce mac_platform helper
On Thu, 2012-07-05 at 10:44 +0800, Andy Green wrote:
[...]
> To make use of this safely you also need to make sure that any drivers that
> may compete for the bus ordinal you are using (eg, mUSB and ehci in Panda
> case) are loaded in a deterministic order.
[...]
This seems very restrictive... would it be practical to also allow a
driver name as a path component?
[...]
> --- /dev/null
> +++ b/include/net/mac-platform.h
> @@ -0,0 +1,39 @@
> +/*
> + * mac-platform.h: Enforces platform-defined MAC for Async probed devices
> + */
> +
> +#ifndef __NET_MAC_PLATFORM_H__
> +#define __NET_MAC_PLATFORM_H__
> +
> +#include
> +
> +/**
> + * struct mac_platform - associates asynchronously probed device path with
> + *MAC address to be assigned to the device when it
> + *is created
A kernel-doc summary is strictly limited to one line. The longer
explanation can go in a paragraph under the field descriptions.
> + * @device_path: device path name of network device
> + * @mac: MAC address to assign to network device matching device path
> + * @list: can be left uninitialized when passing from platform
> + */
> +
> +struct mac_platform {
> + char *device_path;
> + u8 mac[ETH_ALEN];
> + struct list_head list; /* unused in platform data usage */
> +};
[...]
> --- /dev/null
> +++ b/net/ethernet/mac-platform.c
[...]
> +static struct mac_platform *__mac_platform_check(struct device *dev)
> +{
> + const char *path;
> + const char *p;
> + const char *try;
> + int len;
> + struct device *devn;
> + struct mac_platform *tmp;
> + struct list_head *pos;
> +
> + list_for_each(pos, &mac_platform_list) {
> +
> + tmp = list_entry(pos, struct mac_platform, list);
> +
> + try = tmp->device_path;
> +
> + p = try + strlen(try);
> + devn = dev;
> +
> + while (devn) {
> +
> + path = dev_name(devn);
> + len = strlen(path);
> +
> + if ((p - try) < len) {
> + devn = NULL;
> + continue;
> + }
> +
> + p -= len;
[...]
There are so many blank lines here, it's hard to see much code at once.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
--
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/
Infinite looping in omap2430.c USB driver
Hello `./scripts/get_maintainer.pl -f drivers/usb/musb/omap2430.c`
omap2430_musb_set_vbus in omap2430.c contains:
while (musb_readb(musb->mregs, MUSB_DEVCTL) & 0x80) {
cpu_relax();
if (time_after(jiffies, timeout)) {
dev_err(musb->controller,
"configured as A device timeout");
ret = -EINVAL;
break;
}
}
having set
unsigned long timeout = jiffies + msecs_to_jiffies(1000);
so it can busy-loop for up to 1 second. Probably not ideal, but if it works
I wouldn't complain.
The
if (int_usb & MUSB_INTR_SESSREQ) {
branch of musb_stage0_irq() called from musb_interrupt (from
generic_interrupt) calls this:
if (musb->int_usb)
retval |= musb_stage0_irq(musb, musb->int_usb,
devctl, power);
so the busy loop can happen in an interrupt handler (not a threaded interrupt
handler), which is probably less ideal.
However this can be called with interrupt disabled, as happens at least
during resume when resume_irqs() calls:
raw_spin_lock_irqsave(&desc->lock, flags);
__enable_irq(desc, irq, true);
raw_spin_unlock_irqrestore(&desc->lock, flags);
and an interrupt is found to be IRQS_PENDING.
In this case interrupts are disabled so 'jiffies' never changes so this loop
can continue forever.
This happens on my (GTA04) phone fairly regularly - between 1 in 10 and 1 in
30 resumes. The musb-hdrc interrupt is pending and reports
[ 4957.624176] musb-hdrc musb-hdrc: ** IRQ peripheral usb0040 tx rx
'usb0040' is MUSB_INTR_SESSREQ. I think this is triggered by detecting a
voltage change on the USB ID pin - is that right? A short-to-earth would be
a request to switch to host mode, which is why it tries to enable VBUS.
Maybe there is some electrical noise which is being picked up?
In any case I get the interrupt despite nothing being plugged in, and the 0x80
bit of MUSB_DEVCTL never gets cleared.
I've added a simple loop counter which aborts the loop after 1000 loops -
this takes about 5 seconds, but includes some printks which probably slow it
down.
In 2 out of 2 cases, subsequent messages show that the hsmmc driver for the
uSD card that holds my root filesystem is messed up. It seems to be waiting
for a request that is never going to complete.
So maybe the hsmmc is causing the noise that triggers the musb issue.
I can send a patch which add a loop count if you like, but I suspect you can
come up with a much better approach.
Thanks,
NeilBrown
signature.asc
Description: PGP signature
[GIT PULL] eCryptfs fixes for 3.5-rc6
Hi Linus, The following changes since commit ff826b2b5b269ad440afa686ede879ccabfda387: Merge tag 'sound-3.5' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound (2012-07-03 11:10:18 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tyhicks/ecryptfs.git tags/ecryptfs-3.5-rc6-fixes for you to fetch changes up to 8dc6780587c99286c0d3de747a2946a76989414a: eCryptfs: Gracefully refuse miscdev file ops on inherited/passed files (2012-07-06 15:51:12 -0500) Fixes an incorrect access mode check when preparing to open a file in the lower filesystem. This isn't an urgent fix, but it is simple and the check was obviously incorrect. Also fixes a couple important bugs in the eCryptfs miscdev interface. These changes are low risk due to the small number of users that use the miscdev interface. I was able to keep the changes minimal and I have some cleaner, more complete changes queued up for the next merge window that will build on these patches. Tyler Hicks (3): eCryptfs: Properly check for O_RDONLY flag before doing privileged open eCryptfs: Fix lockdep warning in miscdev operations eCryptfs: Gracefully refuse miscdev file ops on inherited/passed files fs/ecryptfs/kthread.c |2 +- fs/ecryptfs/miscdev.c | 48 +--- 2 files changed, 30 insertions(+), 20 deletions(-) signature.asc Description: Digital signature
Re: Regression - /proc/kmsg does not (always) block for 1-byte reads
On Fri, Jul 6, 2012 at 3:05 PM, Jukka Ollila wrote: > > Now this got me wondering if Debian _unstable_ actually qualifies as a > standard distro userspace. Oh, if the kernel breaks some standard user space, that counts. Tons of people run Debian unstable (and from my limited interactions with it, for damn good reasons: -stable tends to run so old versions of everything that you have to sometimes deal with cuneiform writing when using it) Linus -- 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: Regression - /proc/kmsg does not (always) block for 1-byte reads
On Fri, Jul 6, 2012 at 10:38 PM, Alan Cox wrote: > On Fri, 6 Jul 2012 20:45:44 +0300 > Jukka Ollila wrote: >> A few days ago I filed a kernel regression report concerning a change >> in /proc/kmsg behaviour with short reads: >> >> https://bugzilla.kernel.org/show_bug.cgi?id=44211 >> I don't know what other distros do. Is it just Debian being the odd one out? > > If this is observed on an actual standard distro userspace and breaks it > then its a regression and it needs fixing or reverting. Now this got me wondering if Debian _unstable_ actually qualifies as a standard distro userspace. And I did a little digging. According to the Debian package tracking system[1] it would seem that the _stable_ distro carries a version that doesn't do the dd shuffling at all and probably runs its klogd as root, reading /proc/kmsg directly. That may or may not work with 3.5-rc kernels, depending on how big its reads are. I'm CCing the listed maintainer just in case. The unstable version does the problematic dd bs=1 trick. Also the Ubuntu diff in the PTS has the dd. But I have no idea how Ubuntu does it's release management. Not to mention other derivatives. So it might not be too late to fix this in userspace, in case the kernel wants to move on. Some real distro people might want to chime in. Thanks, -J [1] http://packages.debian.org/search?keywords=sysklogd -- 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] x86: simplify mtrr_bp_init()
On Fri, Jul 6, 2012 at 7:18 AM, Jan Beulich wrote:
> Now that the x86_phys_bits cpuinfo field is uniformly available on
> 32- and 64-bit, the function no longer needs to determine this anew.
>
> Additionally, both size_or_mask and size_and_mask can be set once at
> the end of the function instead of individually in each special case,
> as their value solely depends on the physical address size determined
> to be used here.
>
> Signed-off-by: Jan Beulich
>
> ---
> arch/x86/kernel/cpu/mtrr/main.c | 47
> ++--
> 1 file changed, 12 insertions(+), 35 deletions(-)
>
> --- 3.5-rc5/arch/x86/kernel/cpu/mtrr/main.c
> +++ 3.5-rc5-x86-mtrr-init-simplify/arch/x86/kernel/cpu/mtrr/main.c
> @@ -592,67 +592,41 @@ int __initdata changed_by_mtrr_cleanup;
> */
> void __init mtrr_bp_init(void)
> {
> - u32 phys_addr;
> + unsigned int phys_addr = boot_cpu_data.x86_phys_bits;
>
> init_ifs();
>
> - phys_addr = 32;
> -
> if (cpu_has_mtrr) {
> mtrr_if = &generic_mtrr_ops;
> - size_or_mask = 0xff00; /* 36 bits */
> - size_and_mask = 0x00f0;
> - phys_addr = 36;
> -
> - /*
> -* This is an AMD specific MSR, but we assume(hope?) that
> -* Intel will implement it to when they extend the address
> -* bus of the Xeon.
> -*/
> - if (cpuid_eax(0x8000) >= 0x8008) {
> - phys_addr = cpuid_eax(0x8008) & 0xff;
> - /* CPUID workaround for Intel 0F33/0F34 CPU */
> - if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL &&
> - boot_cpu_data.x86 == 0xF &&
> - boot_cpu_data.x86_model == 0x3 &&
> - (boot_cpu_data.x86_mask == 0x3 ||
> -boot_cpu_data.x86_mask == 0x4))
> - phys_addr = 36;
> -
> - size_or_mask = ~((1ULL << (phys_addr - PAGE_SHIFT)) -
> 1);
> - size_and_mask = ~size_or_mask & 0xf0ULL;
> - } else if (boot_cpu_data.x86_vendor == X86_VENDOR_CENTAUR &&
> - boot_cpu_data.x86 == 6) {
> +
> + if (boot_cpu_data.x86_vendor == X86_VENDOR_CENTAUR &&
> + boot_cpu_data.x86 == 6) {
> /*
> * VIA C* family have Intel style MTRRs,
> * but don't support PAE
> */
> - size_or_mask = 0xfff0; /* 32 bits */
> - size_and_mask = 0;
> phys_addr = 32;
> - }
> + } else if (phys_addr < 36)
> + phys_addr = 36;
> } else {
> switch (boot_cpu_data.x86_vendor) {
> case X86_VENDOR_AMD:
> if (cpu_has_k6_mtrr) {
> /* Pre-Athlon (K6) AMD CPU MTRRs */
> mtrr_if = mtrr_ops[X86_VENDOR_AMD];
> - size_or_mask = 0xfff0; /* 32 bits */
> - size_and_mask = 0;
> + phys_addr = 32;
> }
> break;
> case X86_VENDOR_CENTAUR:
> if (cpu_has_centaur_mcr) {
> mtrr_if = mtrr_ops[X86_VENDOR_CENTAUR];
> - size_or_mask = 0xfff0; /* 32 bits */
> - size_and_mask = 0;
> + phys_addr = 32;
> }
> break;
> case X86_VENDOR_CYRIX:
> if (cpu_has_cyrix_arr) {
> mtrr_if = mtrr_ops[X86_VENDOR_CYRIX];
> - size_or_mask = 0xfff0; /* 32 bits */
> - size_and_mask = 0;
> + phys_addr = 32;
should drop all phys_addr assignment in this function.
x86_phys_bits should have all correct value?
Yinghai
--
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] x86/mce: Need to let kill_proc() send signal to doomed process
In commit dad1743e5993f19b3d7e7bd0fb35dc45b5326626
x86/mce: Only restart instruction after machine check recovery if it is safe
we fixed mce_notify_process() to force a signal to the current process
if it was not restartable (RIPV bit not set in MCG_STATUS). But doing
it here means that the process doesn't get told the virtual address of
the fault via siginfo_t->si_addr. This would prevent application level
recovery from the fault.
Make a new MF_MUST_KILL flag bit for memory_failure() et. al. to use
so that we will provide the right information with the signal.
Signed-off-by: Tony Luck
---
arch/x86/kernel/cpu/mcheck/mce.c | 4 ++--
include/linux/mm.h | 1 +
mm/memory-failure.c | 8 +---
3 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index da27c5d..43f918d 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -1200,8 +1200,8 @@ void mce_notify_process(void)
* doomed. We still need to mark the page as poisoned and alert any
* other users of the page.
*/
- if (memory_failure(pfn, MCE_VECTOR, MF_ACTION_REQUIRED) < 0 ||
- mi->restartable == 0) {
+ if (memory_failure(pfn, MCE_VECTOR,
+ MF_ACTION_REQUIRED|MF_MUST_KILL) < 0) {
pr_err("Memory error not recovered");
force_sig(SIGBUS, current);
}
diff --git a/include/linux/mm.h b/include/linux/mm.h
index b36d08c..f9f279c 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1591,6 +1591,7 @@ void vmemmap_populate_print_last(void);
enum mf_flags {
MF_COUNT_INCREASED = 1 << 0,
MF_ACTION_REQUIRED = 1 << 1,
+ MF_MUST_KILL = 1 << 2,
};
extern int memory_failure(unsigned long pfn, int trapno, int flags);
extern void memory_failure_queue(unsigned long pfn, int trapno, int flags);
diff --git a/mm/memory-failure.c b/mm/memory-failure.c
index ab1e714..e3e0045 100644
--- a/mm/memory-failure.c
+++ b/mm/memory-failure.c
@@ -858,7 +858,7 @@ static int hwpoison_user_mappings(struct page *p, unsigned
long pfn,
struct address_space *mapping;
LIST_HEAD(tokill);
int ret;
- int kill = 1;
+ int kill = 1, doit;
struct page *hpage = compound_head(p);
struct page *ppage;
@@ -965,12 +965,14 @@ static int hwpoison_user_mappings(struct page *p,
unsigned long pfn,
* Now that the dirty bit has been propagated to the
* struct page and all unmaps done we can decide if
* killing is needed or not. Only kill when the page
-* was dirty, otherwise the tokill list is merely
+* was dirty or the process is not restartable,
+* otherwise the tokill list is merely
* freed. When there was a problem unmapping earlier
* use a more force-full uncatchable kill to prevent
* any accesses to the poisoned memory.
*/
- kill_procs(&tokill, !!PageDirty(ppage), trapno,
+ doit = !!PageDirty(ppage) || (flags & MF_MUST_KILL) != 0;
+ kill_procs(&tokill, doit, trapno,
ret != SWAP_SUCCESS, p, pfn, flags);
return ret;
--
1.7.10.2.552.gaa3bb87
--
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: talk about "Cc: sta...@vger.kernel.org"
On Sat, Jul 07, 2012 at 12:59:44AM +0300, Aaro Koskinen wrote: > Hi, > > On Fri, Jul 06, 2012 at 05:38:50PM -0400, Theodore Ts'o wrote: > > I couldn't remember whether the canonical marking is sta...@kernel.org > > or sta...@vger.kernel.org, so I went looking, and discovered that it > > wasn't mentioned in the kernel sources. You can find mention of it in > > Greg K-H's blog, but not everyone would necessarily find this blog > > entry. > > It's documented in Documentation/stable_kernel_rules.txt. Ah, so it is. I don't know how I missed that! - Ted -- 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 01/10] random: make 'add_interrupt_randomness()' do something sane
On Thu, Jul 05, 2012 at 03:01:12PM -0400, Eric Wustrow wrote: > Will this do the long path in add_interrupt_randomness every 16 interrupts > instead of 128? Yes, but given that benchmarks didn't show any performance degradation even under a worst case scenario (i.e., no interrupt mitigation, and a crazy number of interrupts/second), I decided to leave things as they are. - Ted -- 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: talk about "Cc: sta...@vger.kernel.org"
Hi, On Fri, Jul 06, 2012 at 05:38:50PM -0400, Theodore Ts'o wrote: > I couldn't remember whether the canonical marking is sta...@kernel.org > or sta...@vger.kernel.org, so I went looking, and discovered that it > wasn't mentioned in the kernel sources. You can find mention of it in > Greg K-H's blog, but not everyone would necessarily find this blog > entry. It's documented in Documentation/stable_kernel_rules.txt. A. -- 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] checkpatch: Add check for use of sizeof without parenthesis
Kernel style uses parenthesis around sizeof.
Signed-off-by: Joe Perches
---
scripts/checkpatch.pl |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 7190f95..a743622 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -3265,6 +3265,12 @@ sub process {
"sizeof(& should be avoided\n" . $herecurr);
}
+# check for sizeof without parenthesis
+ if ($line =~ /\bsizeof\s+($Lval)/) {
+ WARN("SIZEOF_PARENTHESIS",
+"sizeof $1 should be sizeof($1)\n" . $herecurr);
+ }
+
# check for line continuations in quoted strings with odd counts of "
if ($rawline =~ /\\$/ && $rawline =~ tr/"/"/ % 2) {
WARN("LINE_CONTINUATIONS",
--
1.7.8.111.gad25c.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/
Unusual power consumption of ethernet device r8169 and backlight
I am seeing somewhat very high power consumption usage of the network device and backlight Here is what report powertop, network can go as high as 9W 8.03 W100.0% Device Display backlight 5.19 W 23.1 pkts/sDevice Network interface: p20p1 (r8169) When turning off backlight , it effectively vanish and reflect in power usage, i can't turn off the network device. So question is this backlight consumption expected ? And am i right assuming that the network driver is doing something horribly wrong that the consumption is so high (i must stress that it doesn't matter if there is network activities or not, plug or unplugged it doesn't change). Cheers, Jerome Glisse r8169 :01:00.0: eth0: RTL8168evl/8111evl at 0xc9052000, e8:03:9a:b4:a3:90, XID 0c900800 IRQ 45 lspci -vv -s 01:00.0 01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 06) Subsystem: Samsung Electronics Co Ltd Device c660 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Documentation: talk about "Cc: sta...@vger.kernel.org"
I couldn't remember whether the canonical marking is sta...@kernel.org or sta...@vger.kernel.org, so I went looking, and discovered that it wasn't mentioned in the kernel sources. You can find mention of it in Greg K-H's blog, but not everyone would necessarily find this blog entry. Signed-off-by: "Theodore Ts'o" --- Documentation/SubmittingPatches | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches index c379a2a..d802ee2 100644 --- a/Documentation/SubmittingPatches +++ b/Documentation/SubmittingPatches @@ -418,7 +418,13 @@ If a person has had the opportunity to comment on a patch, but has not provided such comments, you may optionally add a "Cc:" tag to the patch. This is the only tag which might be added without an explicit action by the person it names. This tag documents that potentially interested parties -have been included in the discussion +have been included in the discussion. + +If a patch is a bug fix which you believe should be backported to the +stable kernel trees, you should add a simple "Cc: sta...@vger.kernel.org>" +marking in the Signed-off-by: area. Once the patch hits Linus's tree, +the patch will be automatically applied to the currently active stable +trees if possible. If it does not apply, you will be notified of that fact. 14) Using Reported-by:, Tested-by: and Reviewed-by: -- 1.7.11.1.108.gb129051 -- 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] x86: adjust generic_get_mtrr() for 64-bit
On Fri, Jul 6, 2012 at 7:14 AM, Jan Beulich wrote:
> Needing to deal with potentially large memory configurations, the
> variables here should be "unsigned long" instead of "unsigned int".
>
> Signed-off-by: Jan Beulich
>
> ---
> arch/x86/kernel/cpu/mtrr/generic.c |8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> --- 3.5-rc5/arch/x86/kernel/cpu/mtrr/generic.c
> +++ 3.5-rc5-x86-mtrr-generic-types/arch/x86/kernel/cpu/mtrr/generic.c
> @@ -514,8 +514,8 @@ generic_get_free_region(unsigned long ba
> static void generic_get_mtrr(unsigned int reg, unsigned long *base,
> unsigned long *size, mtrr_type *type)
> {
> - unsigned int mask_lo, mask_hi, base_lo, base_hi;
> - unsigned int tmp, hi;
> + unsigned long mask_lo, mask_hi, base_lo, base_hi, tmp;
> + unsigned int hi;
_lo, _hi means we want it as 32bit.
or we just change them to u32 to make it more clear ?
Thanks
Yinghai
--
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: Initializing iwl3945 error
On Fri, Jul 6, 2012 at 1:38 PM, Bjorn Helgaas wrote: > pci :0b:00.0: reg 10: [mem 0xf1eff000-0xf1ef] > -pci :00:1c.1: BAR 15: assigned [mem 0xf020-0xf03f 64bit pref] > +pci :00:1c.1: bridge window [io 0x1000-0x0fff] to [bus 0b-0b] > add_size 1000 > +pci :00:1c.1: bridge window [mem 0x0010-0x000f 64bit pref] to > [bus > 0b-0b] add_size 20 > +pci :00:1c.1: res[15]=[mem 0x0010-0x000f 64bit pref] > get_res_add_size add_size 20 > +pci :00:1c.1: res[13]=[io 0x1000-0x0fff] get_res_add_size add_size 1000 > +pci :00:1c.1: BAR 15: assigned [mem 0xf040-0xf05f 64bit pref] > pci_bus :0b: resource 1 [mem 0xf1e0-0xf1ef] > -pci_bus :0b: resource 2 [mem 0xf020-0xf03f 64bit pref] > +pci_bus :0b: resource 2 [mem 0xf040-0xf05f 64bit pref] Those wild print out about add_size is used to double check if the option size is passed correctly. diff between 3.3 and 3.4: in kernel 3.4, 1c.0 pref mem64 get allocated before 1c.1 pref mem64. that should be caused by: We replaced local version resource list with generic list. But that should not be reason for why 3.3 does not work on Kamil's setup. I would suspect that pci pm change fixes the problem. Thanks Yinghai -- 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 08/36] AArch64: Kernel booting and initialisation
On 07/06/2012 03:05 PM, Catalin Marinas wrote: > The patch adds the kernel booting and the initial setup code. > Documentation/aarch64/booting.txt describes the booting protocol on the > AArch64 Linux kernel. This is subject to change following the work on > boot standardisation, ACPI. > diff --git a/Documentation/aarch64/booting.txt > b/Documentation/aarch64/booting.txt > +3. Decompress the kernel image > +-- > + > +Requirement: OPTIONAL > + > +The AArch64 kernel does not provide a decompressor and therefore > +requires gzip decompression to be performed by the boot loader if the > +default Image.gz target is used. For bootloaders that do not implement > +this requirement, the larger Image target is available instead. I'm curious why a decompressor isn't provided. The reason I ask is that this change will cause differences in the way e.g. a U-Boot script boots the kernel; the filename would be different, you'd need to use a uImage in order for U-Boot to decompress the kernel instead of a raw zImage, etc. This makes things on AArch64 work just a little bit different from existing systems, and differences between systems make for more things for everyone to understand and remember; more mistakes will be made. U-Boot has recently grown a "bootz" command to simplify booting a zImage directly for example, and now it seems that won't be useful moving forward. Also, on Tegra at least and perhaps OMAP too, there are a few parts of earlyprintk serial port setup (i.e. port selection) which happen as part of the decompressor rather than the main kernel image, so we'd have to re-jig that too. > +4. Call the kernel image > + > + > +Requirement: MANDATORY > + > +The decompressed kernel image contains a 32-byte header as follows: > + > + u32 magic = 0x1408; /* branch to stext, little-endian */ > + u32 res0 = 0;/* reserved */ > + u64 text_offset; /* Image load offset */ > + u64 res1 = 0;/* reserved */ > + u64 res2 = 0;/* reserved */ > + > +The image must be placed at the specified offset (currently 0x8) > +from the start of the system RAM (aligned to 2MB) and called there. Is "0x8" meant to have an extra "0"; 0x8 isn't aligned to 2MB unless I'm really missing too much sleep today. -- 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: [Resend PATCH] media: rc: ati_remote.c: code style and compile warning fixing
Em 04-07-2012 05:08, Du, Changbin escreveu:
> changes:
> 1. break some lines that are longer than 80 characters.
> 2. remove local function prototype declarations which do not
> need.
> 3. replace TAB character with a space character in function
> comments.
> 4. change the types of array init1[] and init2[] to
> "unsigned char" to avoid compile warning.
>
> Signed-off-by: Du, Changbin
> ---
> drivers/media/rc/ati_remote.c | 139
> +
> 1 file changed, 84 insertions(+), 55 deletions(-)
>
> diff --git a/drivers/media/rc/ati_remote.c b/drivers/media/rc/ati_remote.c
> index 7be377f..0df66ac 100644
> --- a/drivers/media/rc/ati_remote.c
> +++ b/drivers/media/rc/ati_remote.c
> @@ -23,6 +23,8 @@
>*Vincent Vanackere
>*Added support for the "Lola" remote contributed by:
>*Seth Cohn
> + * Jul 2012: Du, Changbin
> + *Code style and compile warning fixing
You shouldn't be changing the driver's authorship just due to codingstyle
and warning fixes. Btw, Please split Coding Style form Compilation warnings,
as they're two different matters.
Thanks!
Mauro
>*
>* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
> *
>*
> @@ -147,7 +149,8 @@ static bool mouse = true;
> module_param(mouse, bool, 0444);
> MODULE_PARM_DESC(mouse, "Enable mouse device, default = yes");
>
> -#define dbginfo(dev, format, arg...) do { if (debug) dev_info(dev , format
> , ## arg); } while (0)
> +#define dbginfo(dev, format, arg...) \
> + do { if (debug) dev_info(dev , format , ## arg); } while (0)
> #undef err
> #define err(format, arg...) printk(KERN_ERR format , ## arg)
>
> @@ -191,17 +194,41 @@ static const char *get_medion_keymap(struct
> usb_interface *interface)
> return RC_MAP_MEDION_X10;
> }
>
> -static const struct ati_receiver_type type_ati = {
> .default_keymap
> = RC_MAP_ATI_X10 };
> -static const struct ati_receiver_type type_medion= {
> .get_default_keymap = get_medion_keymap };
> -static const struct ati_receiver_type type_firefly = { .default_keymap
> = RC_MAP_SNAPSTREAM_FIREFLY };
> +static const struct ati_receiver_type type_ati = {
> + .default_keymap = RC_MAP_ATI_X10
> +};
> +static const struct ati_receiver_type type_medion= {
> + .get_default_keymap = get_medion_keymap
> +};
> +static const struct ati_receiver_type type_firefly = {
> + .default_keymap = RC_MAP_SNAPSTREAM_FIREFLY
> +};
>
> static struct usb_device_id ati_remote_table[] = {
> - { USB_DEVICE(ATI_REMOTE_VENDOR_ID, LOLA_REMOTE_PRODUCT_ID),
> .driver_info = (unsigned long)&type_ati },
> - { USB_DEVICE(ATI_REMOTE_VENDOR_ID, LOLA2_REMOTE_PRODUCT_ID),
> .driver_info = (unsigned long)&type_ati },
> - { USB_DEVICE(ATI_REMOTE_VENDOR_ID, ATI_REMOTE_PRODUCT_ID),
> .driver_info = (unsigned long)&type_ati },
> - { USB_DEVICE(ATI_REMOTE_VENDOR_ID, NVIDIA_REMOTE_PRODUCT_ID),
> .driver_info = (unsigned long)&type_ati },
> - { USB_DEVICE(ATI_REMOTE_VENDOR_ID, MEDION_REMOTE_PRODUCT_ID),
> .driver_info = (unsigned long)&type_medion },
> - { USB_DEVICE(ATI_REMOTE_VENDOR_ID, FIREFLY_REMOTE_PRODUCT_ID),
> .driver_info = (unsigned long)&type_firefly },
> + {
> + USB_DEVICE(ATI_REMOTE_VENDOR_ID, LOLA_REMOTE_PRODUCT_ID),
> + .driver_info = (unsigned long)&type_ati
> + },
> + {
> + USB_DEVICE(ATI_REMOTE_VENDOR_ID, LOLA2_REMOTE_PRODUCT_ID),
> + .driver_info = (unsigned long)&type_ati
> + },
> + {
> + USB_DEVICE(ATI_REMOTE_VENDOR_ID, ATI_REMOTE_PRODUCT_ID),
> + .driver_info = (unsigned long)&type_ati
> + },
> + {
> + USB_DEVICE(ATI_REMOTE_VENDOR_ID, NVIDIA_REMOTE_PRODUCT_ID),
> + .driver_info = (unsigned long)&type_ati
> + },
> + {
> + USB_DEVICE(ATI_REMOTE_VENDOR_ID, MEDION_REMOTE_PRODUCT_ID),
> + .driver_info = (unsigned long)&type_medion
> + },
> + {
> + USB_DEVICE(ATI_REMOTE_VENDOR_ID, FIREFLY_REMOTE_PRODUCT_ID),
> + .driver_info = (unsigned long)&type_firefly
> + },
> {} /* Terminating entry */
> };
>
> @@ -215,8 +242,8 @@ MODULE_DEVICE_TABLE(usb, ati_remote_table);
> #define SEND_FLAG_COMPLETE 2
>
> /* Device initialization strings */
> -static char init1[] = { 0x01, 0x00, 0x20, 0x14 };
> -static char init2[] = { 0x01, 0x00, 0x20, 0x14, 0x20, 0x20, 0x20 };
> +static unsigned char init1[] = { 0x01, 0x00, 0x20, 0x14 };
> +static unsigned char init2[] = { 0x01, 0x00, 0x20, 0x14, 0x20, 0x20, 0x20
> };
>
> struct ati_remote {
> struct input_dev *idev;
> @@ -296,25 +323,8 @@ static const struct {
> {KIND_END, 0x00, EV_MAX + 1, 0, 0}
> };
>
> -/* Local function prototypes */
> -static int ati_remote_sendpacket (struct ati_remote *ati_remote, u16
Re: [RESEND AGAIN][PATCH] pcmcia: move unbind/rebind into dev_pm_ops.complete
On Fri, Jul 06, 2012 at 11:23:52PM +0200, Christian Lamparter wrote: > The idea of moving rebind procedure into pm.complete > was taken from the usb-subsystem, which has similar > problems with reattaching devices during/after > resume. > > Signed-off-by: Christian Lamparter > --- > To Greg: > > I have submitted this patch back in March and again in May. > As far as I can tell it was neither rejected nor was it > accepted into linux-pcmcia.git since. So I'm asking you, > if you could take the patch instead... please. There is a PCMCIA "team" who should be taking these types of patches. Why are they not doing so? 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/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/1] media: gpio-ir-recv: add allowed_protos for platform data
Em 04-07-2012 00:11, Du, Changbin escreveu:
> Make it possible to specify allowed RC protocols through the device's
> platform data.
>
> Signed-off-by: Du, Changbin
Gah, you trapped me: you've resent it, without using the original message ID.
Too late. I'll keep the version where I've fixed the merge
conflict, as it does the same thing.
Regards,
Mauro.
> ---
> For v2:
> Keymap has already done by another patch.
> ---
> drivers/media/rc/gpio-ir-recv.c |2 +-
> include/media/gpio-ir-recv.h|7 ---
> 2 files changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/media/rc/gpio-ir-recv.c
> b/drivers/media/rc/gpio-ir-recv.c
> index 59fe60c..38da91e 100644
> --- a/drivers/media/rc/gpio-ir-recv.c
> +++ b/drivers/media/rc/gpio-ir-recv.c
> @@ -84,7 +84,7 @@ static int __devinit gpio_ir_recv_probe(struct
> platform_device *pdev)
>
> rcdev->priv = gpio_dev;
> rcdev->driver_type = RC_DRIVER_IR_RAW;
> - rcdev->allowed_protos = RC_TYPE_ALL;
> + rcdev->allowed_protos = pdata->allowed_protos ?: RC_TYPE_ALL;
> rcdev->input_name = GPIO_IR_DEVICE_NAME;
> rcdev->input_phys = GPIO_IR_DEVICE_NAME "/input0";
> rcdev->input_id.bustype = BUS_HOST;
> diff --git a/include/media/gpio-ir-recv.h b/include/media/gpio-ir-recv.h
> index 91546f3..0142736 100644
> --- a/include/media/gpio-ir-recv.h
> +++ b/include/media/gpio-ir-recv.h
> @@ -14,9 +14,10 @@
> #define __GPIO_IR_RECV_H__
>
> struct gpio_ir_recv_platform_data {
> - int gpio_nr;
> - bool active_low;
> - const char *map_name;
> + int gpio_nr;
> + boolactive_low;
> + u64 allowed_protos;
> + const char *map_name;
> };
>
> #endif /* __GPIO_IR_RECV_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: Subject: [PATCH] tty ldisc: Close/Reopen race prevention should check the proper flag
On Sun, Jul 01, 2012 at 09:53:19AM +0300, Shachar Shemesh wrote:
> From: Shachar Shemesh
>
> Commit acfa747b introduced the TTY_HUPPING flag to distinguish
> closed TTY from currently closing ones. The test in tty_set_ldisc
> still remained pointing at the old flag. This causes pppd to
> sometimes lapse into uninterruptible sleep when killed and
> restarted.
>
> Signed-off-by: Shachar Shemesh
> ---
> Tested with 3.2.20 kernel.
>
> diff --git a/drivers/tty/tty_ldisc.c b/drivers/tty/tty_ldisc.c
> index 24b95db..a662a24 100644
> --- a/drivers/tty/tty_ldisc.c
> +++ b/drivers/tty/tty_ldisc.c
> @@ -658,7 +658,7 @@ int tty_set_ldisc(struct tty_struct *tty, int ldisc)
> goto enable;
> }
>
> -if (test_bit(TTY_HUPPED, &tty->flags)) {
> +if (test_bit(TTY_HUPPING, &tty->flags)) {
All tabs are converted to spaces and make this patch impossible to apply
:(
Care to try again?
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/
[RESEND AGAIN][PATCH] pcmcia: move unbind/rebind into dev_pm_ops.complete
The idea of moving rebind procedure into pm.complete
was taken from the usb-subsystem, which has similar
problems with reattaching devices during/after
resume.
Signed-off-by: Christian Lamparter
---
To Greg:
I have submitted this patch back in March and again in May.
As far as I can tell it was neither rejected nor was it
accepted into linux-pcmcia.git since. So I'm asking you,
if you could take the patch instead... please.
Regards,
Christian
PS: I'm not on the pcmcia/kernel list, so please keep the
'CC'.
---
drivers/pcmcia/cs.c | 22 ++
1 files changed, 18 insertions(+), 4 deletions(-)
diff --git a/drivers/pcmcia/cs.c b/drivers/pcmcia/cs.c
index d9ea192..503596f 100644
--- a/drivers/pcmcia/cs.c
+++ b/drivers/pcmcia/cs.c
@@ -512,6 +512,13 @@ static int socket_late_resume(struct pcmcia_socket *skt)
return socket_insert(skt);
}
+ if (!(skt->state & SOCKET_CARDBUS) && (skt->callback))
+ skt->callback->early_resume(skt);
+ return 0;
+}
+
+static int socket_complete_resume(struct pcmcia_socket *skt)
+{
#ifdef CONFIG_CARDBUS
if (skt->state & SOCKET_CARDBUS) {
/* We can't be sure the CardBus card is the same
@@ -519,11 +526,8 @@ static int socket_late_resume(struct pcmcia_socket *skt)
* and re-add... */
cb_free(skt);
cb_alloc(skt);
- return 0;
}
#endif
- if (!(skt->state & SOCKET_CARDBUS) && (skt->callback))
- skt->callback->early_resume(skt);
return 0;
}
@@ -534,11 +538,15 @@ static int socket_late_resume(struct pcmcia_socket *skt)
*/
static int socket_resume(struct pcmcia_socket *skt)
{
+ int err;
if (!(skt->state & SOCKET_SUSPEND))
return -EBUSY;
socket_early_resume(skt);
- return socket_late_resume(skt);
+ err = socket_late_resume(skt);
+ if (!err)
+ socket_complete_resume(skt);
+ return err;
}
static void socket_remove(struct pcmcia_socket *skt)
@@ -849,6 +857,11 @@ static int __used pcmcia_socket_dev_resume(struct device
*dev)
return __pcmcia_pm_op(dev, socket_late_resume);
}
+static void __used pcmcia_socket_dev_complete(struct device *dev)
+{
+ __pcmcia_pm_op(dev, socket_complete_resume);
+}
+
static const struct dev_pm_ops pcmcia_socket_pm_ops = {
/* dev_resume may be called with IRQs enabled */
SET_SYSTEM_SLEEP_PM_OPS(NULL,
@@ -863,6 +876,7 @@ static const struct dev_pm_ops pcmcia_socket_pm_ops = {
.resume_noirq = pcmcia_socket_dev_resume_noirq,
.thaw_noirq = pcmcia_socket_dev_resume_noirq,
.restore_noirq = pcmcia_socket_dev_resume_noirq,
+ .complete = pcmcia_socket_dev_complete,
};
#define PCMCIA_SOCKET_CLASS_PM_OPS (&pcmcia_socket_pm_ops)
--
1.7.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] media: gpio-ir-recv: add allowed_protos and map_name for platform data
Em 03-07-2012 08:19, Benoît Thébaudeau escreveu:
> Hi Changbin,
>
> On Tue, Jul 3, 2012 at 12:27:19PM +0200, Changbin Du wrote:
>> It's better to give platform code a chance to specify the allowed
>> protocols and which keymap to use.
>
> Already half done here:
> http://git.linuxtv.org/media_tree.git?a=commitdiff;h=2bd237b
OK. Applied just the other half of the change.
Regards,
Mauro
-
[media] media: gpio-ir-recv: add allowed_protos for platform data
From: Du, Changbin
It's better to give platform code a chance to specify the allowed
protocols to use.
[mche...@redhat.com: fix merge conflict with a patch that made
half of this change]
Signed-off-by: Du, Changbin
Signed-off-by: Mauro Carvalho Chehab
diff --git a/drivers/media/rc/gpio-ir-recv.c b/drivers/media/rc/gpio-ir-recv.c
index 59fe60c..04cb272 100644
--- a/drivers/media/rc/gpio-ir-recv.c
+++ b/drivers/media/rc/gpio-ir-recv.c
@@ -84,7 +84,6 @@ static int __devinit gpio_ir_recv_probe(struct
platform_device *pdev)
rcdev->priv = gpio_dev;
rcdev->driver_type = RC_DRIVER_IR_RAW;
- rcdev->allowed_protos = RC_TYPE_ALL;
rcdev->input_name = GPIO_IR_DEVICE_NAME;
rcdev->input_phys = GPIO_IR_DEVICE_NAME "/input0";
rcdev->input_id.bustype = BUS_HOST;
@@ -93,6 +92,10 @@ static int __devinit gpio_ir_recv_probe(struct
platform_device *pdev)
rcdev->input_id.version = 0x0100;
rcdev->dev.parent = &pdev->dev;
rcdev->driver_name = GPIO_IR_DRIVER_NAME;
+ if (pdata->allowed_protos)
+ rcdev->allowed_protos = pdata->allowed_protos;
+ else
+ rcdev->allowed_protos = RC_TYPE_ALL;
rcdev->map_name = pdata->map_name ?: RC_MAP_EMPTY;
gpio_dev->rcdev = rcdev;
diff --git a/include/media/gpio-ir-recv.h b/include/media/gpio-ir-recv.h
index 91546f3..0142736 100644
--- a/include/media/gpio-ir-recv.h
+++ b/include/media/gpio-ir-recv.h
@@ -14,9 +14,10 @@
#define __GPIO_IR_RECV_H__
struct gpio_ir_recv_platform_data {
- int gpio_nr;
- bool active_low;
- const char *map_name;
+ int gpio_nr;
+ boolactive_low;
+ u64 allowed_protos;
+ const char *map_name;
};
#endif /* __GPIO_IR_RECV_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: mfd: wm831x: Feed the device UUID into device_add_randomness()
On Thu, Jul 05, 2012 at 08:23:21PM -, Mark Brown wrote: > wm831x devices contain a unique ID value. Feed this into the newly added > device_add_randomness() to add some per device seed data to the pool. > > Signed-off-by: Mark Brown > > add_device_randomness() has only just been added in -next, this will > need to either wait until after the merge window or be merged along with > the patch adding it. Thanks, I've added this to the /dev/random git tree. - Ted -- 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: rtc: wm831x: Feed the write counter into device_add_randomness()
On Thu, Jul 05, 2012 at 08:19:17PM -, Mark Brown wrote: > The tamper evident features of the RTC include the "write counter" which > is a pseudo-random number regenerated whenever we set the RTC. Since this > value is unpredictable it should provide some useful seeding to the random > number generator. > > Only do this on boot since the goal is to seed the pool rather than add > useful entropy. > > Signed-off-by: Mark Brown > add_device_randomness() has only just been added in -next, this will > need to either wait until after the merge window or be merged along with > the patch adding it. Thanks, I've added this to the /dev/random git tree. - Ted -- 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 00/36] AArch64 Linux kernel port
This set of patches implements the core Linux support for the AArch64 (64-bit ARM) architecture. ARM introduced AArch64 as part of the ARMv8 architecture and consists of a substantially revised exception model (with 4 exception levels: EL0 - user, EL1 - kernel, EL2 - hypervisor, EL3 - secure monitor), new A64 instruction set based on larger register file, new FP/SIMD instructions. The new ABI is LP64 and takes advantage of the larger register file and mandates FP. AArch64 documentation currently available (publicly, though click-through agreement required): - Instruction Set Overview: http://infocenter.arm.com/help/topic/com.arm.doc.genc010197a/index.html - ABI (PCS, ELF, DWARF, C++): http://infocenter.arm.com/help/topic/com.arm.doc.ihi0059a/index.html The AArch64 Linux port follows the guidance for new architecture ports using generic headers (including unistd.h) and as much generic code as possible (some library functions may be later optimised, based on benchmarking results). There is no hardware platform available at this point. From a kernel perspective, the aim is to minimise (or even completely remove) the platform code from the architecture specific directory. FDT is currently mandated and there are ongoing discussions for ACPI support. In terms of MMU, it currently supports 39-bit address space for user and kernel (each) with 3-level page table and 4KB pages or 2-level page table and 64KB pages (see Documentation/aarch64/memory.txt). The virtual address space can be extended to 48-bit. Compat (32-bit) user applications (ARM EABI only) are supported with the 4KB page configuration. There is no interworking between AArch32 and AArch64 code (the architecture requires an exception entry/exit to change the mode). Linux Test Project (LTP) and LAMP stack have been used to test and validate this code against ARM simulation model throughout the development. Compilation requires a new aarch64-none-linux-gnu- toolchain (http://gcc.gnu.org/ml/gcc-patches/2012-05/msg01694.html). These patches are also available on this branch: git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-aarch64.git upstream Regards, Catalin Catalin Marinas (25): atomic64_test: Simplify the #ifdef for atomic64_dec_if_positive() test fs: Build sys_stat64() and friends if __ARCH_WANT_COMPAT_STAT64 fdt: Add generic dt_memblock_reserve() function AArch64: Assembly macros and definitions AArch64: Kernel booting and initialisation AArch64: Exception handling AArch64: MMU definitions AArch64: MMU initialisation AArch64: MMU fault handling and page table management AArch64: Process management AArch64: CPU support AArch64: Cache maintenance routines AArch64: TLB maintenance functionality AArch64: Atomic operations AArch64: Device specific operations AArch64: DMA mapping API AArch64: SMP support AArch64: ELF definitions AArch64: System calls handling AArch64: Signal handling support AArch64: User access library functions AArch64: Floating point and SIMD AArch64: Miscellaneous header files AArch64: Build infrastructure AArch64: MAINTAINERS update Marc Zyngier (3): AArch64: IRQ handling AArch64: Miscellaneous library functions AArch64: Generic timers support Will Deacon (8): ipc: Add COMPAT_SHMLBA support ipc: allow compat IPC version field parsing if !ARCH_WANT_OLD_COMPAT_IPC ipc: compat: use signed size_t types for msgsnd and msgrcv AArch64: VDSO support AArch64: 32-bit (compat) applications support AArch64: Debugging support AArch64: Performance counters support AArch64: Loadable modules Documentation/aarch64/booting.txt | 139 +++ Documentation/aarch64/memory.txt| 69 ++ MAINTAINERS |6 + arch/aarch64/Kconfig| 263 + arch/aarch64/Kconfig.debug | 44 + arch/aarch64/Makefile | 71 ++ arch/aarch64/boot/.gitignore|2 + arch/aarch64/boot/Makefile | 38 + arch/aarch64/boot/install.sh| 52 + arch/aarch64/include/asm/Kbuild | 50 + arch/aarch64/include/asm/asm-offsets.h |1 + arch/aarch64/include/asm/assembler.h| 143 +++ arch/aarch64/include/asm/atomic.h | 307 + arch/aarch64/include/asm/auxvec.h | 23 + arch/aarch64/include/asm/barrier.h | 53 + arch/aarch64/include/asm/bitops.h | 75 ++ arch/aarch64/include/asm/bitsperlong.h | 24 + arch/aarch64/include/asm/byteorder.h| 22 + arch/aarch64/include/asm/cache.h| 33 + arch/aarch64/include/asm/cacheflush.h | 210 arch/aarch64/include/asm/cachetype.h| 49 + arch/aarch64/include/asm/cmpxchg.h | 181 +++ arch/aarch64/include/asm/compat.h | 233 arch/aarch64/inc
[PATCH 06/36] fdt: Add generic dt_memblock_reserve() function
This function reserves initial_boot_params total size and reserve map.
Signed-off-by: Catalin Marinas
Cc: Grant Likely
---
drivers/of/fdt.c | 28
include/linux/of_fdt.h |1 +
2 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 91a375f..7e9b5b0 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include /* for COMMAND_LINE_SIZE */
#ifdef CONFIG_PPC
@@ -436,6 +437,33 @@ int __initdata dt_root_size_cells;
struct boot_param_header *initial_boot_params;
+void __init dt_memblock_reserve(void)
+{
+ u64 *reserve_map, base, size;
+
+ if (!initial_boot_params)
+ return;
+
+ /* Reserve the dtb region */
+ memblock_reserve(virt_to_phys(initial_boot_params),
+be32_to_cpu(initial_boot_params->totalsize));
+
+ /*
+* Process the reserve map. This will probably overlap the initrd
+* and dtb locations which are already reserved, but overlapping
+* doesn't hurt anything
+*/
+ reserve_map = ((void*)initial_boot_params) +
+ be32_to_cpu(initial_boot_params->off_mem_rsvmap);
+ while (1) {
+ base = be64_to_cpup(reserve_map++);
+ size = be64_to_cpup(reserve_map++);
+ if (!size)
+ break;
+ memblock_reserve(base, size);
+ }
+}
+
#ifdef CONFIG_OF_EARLY_FLATTREE
/**
diff --git a/include/linux/of_fdt.h b/include/linux/of_fdt.h
index ed136ad..bf4fe1e 100644
--- a/include/linux/of_fdt.h
+++ b/include/linux/of_fdt.h
@@ -117,6 +117,7 @@ extern int early_init_dt_scan_root(unsigned long node,
const char *uname,
/* Other Prototypes */
extern void unflatten_device_tree(void);
extern void early_init_devtree(void *);
+extern void dt_memblock_reserve(void);
#else /* CONFIG_OF_FLATTREE */
static inline void unflatten_device_tree(void) {}
#endif /* CONFIG_OF_FLATTREE */
--
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 12/36] AArch64: MMU fault handling and page table management
This patch adds support for the handling of the MMU faults (exception
entry code introduced by a previous patch) and page table management.
The user translation table is pointed to by TTBR0 and the kernel one
(swapper_pg_dir) by TTBR1. There is no translation information shared or
address space overlapping between user and kernel page tables.
Signed-off-by: Will Deacon
Signed-off-by: Catalin Marinas
---
arch/aarch64/include/asm/page.h| 68 +
arch/aarch64/include/asm/pgalloc.h | 114
arch/aarch64/mm/copypage.c | 35 +++
arch/aarch64/mm/extable.c | 17 ++
arch/aarch64/mm/fault.c| 537
arch/aarch64/mm/mm.h | 15 +
arch/aarch64/mm/mmap.c | 145 ++
arch/aarch64/mm/pgd.c | 50
8 files changed, 981 insertions(+), 0 deletions(-)
create mode 100644 arch/aarch64/include/asm/page.h
create mode 100644 arch/aarch64/include/asm/pgalloc.h
create mode 100644 arch/aarch64/mm/copypage.c
create mode 100644 arch/aarch64/mm/extable.c
create mode 100644 arch/aarch64/mm/fault.c
create mode 100644 arch/aarch64/mm/mm.h
create mode 100644 arch/aarch64/mm/mmap.c
create mode 100644 arch/aarch64/mm/pgd.c
diff --git a/arch/aarch64/include/asm/page.h b/arch/aarch64/include/asm/page.h
new file mode 100644
index 000..0739f48
--- /dev/null
+++ b/arch/aarch64/include/asm/page.h
@@ -0,0 +1,68 @@
+/*
+ * Based on arch/arm/include/asm/page.h
+ *
+ * Copyright (C) 1995-2003 Russell King
+ * Copyright (C) 2012 ARM Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+#ifndef __ASM_PAGE_H
+#define __ASM_PAGE_H
+
+/* PAGE_SHIFT determines the page size */
+#ifdef CONFIG_AARCH64_64K_PAGES
+#define PAGE_SHIFT 16
+#else
+#define PAGE_SHIFT 12
+#endif
+#define PAGE_SIZE (_AC(1,UL) << PAGE_SHIFT)
+#define PAGE_MASK (~(PAGE_SIZE-1))
+
+/* We do define AT_SYSINFO_EHDR but don't use the gate mechanism */
+#define __HAVE_ARCH_GATE_AREA 1
+
+#ifndef __ASSEMBLY__
+
+#ifdef CONFIG_AARCH64_64K_PAGES
+#include
+#else
+#include
+#endif
+
+extern void __cpu_clear_user_page(void *p, unsigned long user);
+extern void __cpu_copy_user_page(void *to, const void *from,
+unsigned long user);
+extern void copy_page(void *to, const void *from);
+extern void clear_page(void *to);
+
+#define clear_user_page(addr,vaddr,pg) __cpu_clear_user_page(addr, vaddr)
+#define copy_user_page(to,from,vaddr,pg) __cpu_copy_user_page(to, from, vaddr)
+
+typedef struct page *pgtable_t;
+
+#ifdef CONFIG_HAVE_ARCH_PFN_VALID
+extern int pfn_valid(unsigned long);
+#endif
+
+#include
+
+#endif /* !__ASSEMBLY__ */
+
+#define VM_DATA_DEFAULT_FLAGS \
+ (((current->personality & READ_IMPLIES_EXEC) ? VM_EXEC : 0) | \
+VM_READ | VM_WRITE | VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC)
+
+#include
+
+#endif
diff --git a/arch/aarch64/include/asm/pgalloc.h
b/arch/aarch64/include/asm/pgalloc.h
new file mode 100644
index 000..29bdd06
--- /dev/null
+++ b/arch/aarch64/include/asm/pgalloc.h
@@ -0,0 +1,114 @@
+/*
+ * Based on arch/arm/include/asm/pgalloc.h
+ *
+ * Copyright (C) 2000-2001 Russell King
+ * Copyright (C) 2012 ARM Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+#ifndef __ASM_PGALLOC_H
+#define __ASM_PGALLOC_H
+
+#include
+#include
+#include
+#include
+
+#define check_pgt_cache() do { } while (0)
+
+#ifndef CONFIG_AARCH64_64K_PAGES
+
+static inline pmd_t *pmd_alloc_one(struct mm_struct *mm, unsigned long addr)
+{
+ return (pmd_t *)get_zeroed_page(GFP_KERNEL | __GFP_REPEAT);
+}
+
+static inline void pmd_free(struct mm_struct *mm, pmd_t *pmd)
+{
+ BUG_ON((unsigned long)pmd & (PAGE_SI
[PATCH 13/36] AArch64: Process management
The patch adds support for thread creation and context switching. The
context switching CPU specific code is introduced with the CPU support
patch (part of the arch/aarch64/mm/proc.S file). AArch64 supports
ASID-tagged TLBs and the ASID can be either 8 or 16-bit wide (detectable
via the ID_AA64AFR0_EL1 register).
Signed-off-by: Will Deacon
Signed-off-by: Catalin Marinas
---
arch/aarch64/include/asm/mmu_context.h | 153
arch/aarch64/include/asm/thread_info.h | 125 ++
arch/aarch64/kernel/process.c | 417
arch/aarch64/mm/context.c | 160
4 files changed, 855 insertions(+), 0 deletions(-)
create mode 100644 arch/aarch64/include/asm/mmu_context.h
create mode 100644 arch/aarch64/include/asm/thread_info.h
create mode 100644 arch/aarch64/kernel/process.c
create mode 100644 arch/aarch64/mm/context.c
diff --git a/arch/aarch64/include/asm/mmu_context.h
b/arch/aarch64/include/asm/mmu_context.h
new file mode 100644
index 000..876f06f
--- /dev/null
+++ b/arch/aarch64/include/asm/mmu_context.h
@@ -0,0 +1,153 @@
+/*
+ * Based on arch/arm/include/asm/mmu_context.h
+ *
+ * Copyright (C) 1996 Russell King.
+ * Copyright (C) 2012 ARM Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+#ifndef __ASM_MMU_CONTEXT_H
+#define __ASM_MMU_CONTEXT_H
+
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+#define MAX_ASID_BITS 16
+
+extern unsigned int cpu_last_asid;
+
+void __init_new_context(struct task_struct *tsk, struct mm_struct *mm);
+void __new_context(struct mm_struct *mm);
+
+/*
+ * Set TTBR0 to empty_zero_page. No translations will be possible via TTBR0.
+ */
+static inline void cpu_set_reserved_ttbr0(void)
+{
+ unsigned long ttbr = page_to_phys(empty_zero_page);
+
+ asm(
+ " msr ttbr0_el1, %0 // set TTBR0\n"
+ " isb"
+ :
+ : "r" (ttbr));
+}
+
+static inline void switch_new_context(struct mm_struct *mm)
+{
+ unsigned long flags;
+
+ __new_context(mm);
+
+ local_irq_save(flags);
+ cpu_switch_mm(mm->pgd, mm);
+ local_irq_restore(flags);
+}
+
+static inline void check_and_switch_context(struct mm_struct *mm,
+ struct task_struct *tsk)
+{
+ /*
+* Required during context switch to avoid speculative page table
+* walking with the wrong TTBR.
+*/
+ cpu_set_reserved_ttbr0();
+
+ if (!((mm->context.id ^ cpu_last_asid) >> MAX_ASID_BITS))
+ /*
+* The ASID is from the current generation, just switch to the
+* new pgd. This condition is only true for calls from
+* context_switch() and interrupts are already disabled.
+*/
+ cpu_switch_mm(mm->pgd, mm);
+ else if (irqs_disabled())
+ /*
+* Defer the new ASID allocation until after the context
+* switch critical region since __new_context() cannot be
+* called with interrupts disabled.
+*/
+ set_ti_thread_flag(task_thread_info(tsk), TIF_SWITCH_MM);
+ else
+ /*
+* That is a direct call to switch_mm() or activate_mm() with
+* interrupts enabled and a new context.
+*/
+ switch_new_context(mm);
+}
+
+#define init_new_context(tsk,mm) (__init_new_context(tsk,mm),0)
+#define destroy_context(mm)do { } while(0)
+
+#define finish_arch_post_lock_switch \
+ finish_arch_post_lock_switch
+static inline void finish_arch_post_lock_switch(void)
+{
+ if (test_and_clear_thread_flag(TIF_SWITCH_MM)) {
+ struct mm_struct *mm = current->mm;
+ unsigned long flags;
+
+ __new_context(mm);
+
+ local_irq_save(flags);
+ cpu_switch_mm(mm->pgd, mm);
+ local_irq_restore(flags);
+ }
+}
+
+/*
+ * This is called when "tsk" is about to enter lazy TLB mode.
+ *
+ * mm: describes the currently active mm context
+ * tsk: task which is entering lazy tlb
+ * cpu: cpu number which is entering lazy tlb
+ *
+ * tsk->mm will be NULL
+ */
+static inline void
+enter_lazy_tlb(struct mm_struct *mm, struct task_struct *tsk)
+{
+}
+
[PATCH 14/36] AArch64: CPU support
This patch adds AArch64 CPU specific functionality. It assumes that the
implementation is generic to AArch64 and does not require specific
identification. Different CPU implementations may require the setting of
various ACTLR_EL1 bits but such information is not currently available
and it should ideally be pushed to firmware.
Signed-off-by: Will Deacon
Signed-off-by: Catalin Marinas
---
arch/aarch64/include/asm/cputype.h | 50 +
arch/aarch64/include/asm/proc-fns.h | 52 +
arch/aarch64/include/asm/processor.h | 175 ++
arch/aarch64/include/asm/procinfo.h | 45
arch/aarch64/mm/proc-syms.c | 32 ++
arch/aarch64/mm/proc.S | 194 ++
6 files changed, 548 insertions(+), 0 deletions(-)
create mode 100644 arch/aarch64/include/asm/cputype.h
create mode 100644 arch/aarch64/include/asm/proc-fns.h
create mode 100644 arch/aarch64/include/asm/processor.h
create mode 100644 arch/aarch64/include/asm/procinfo.h
create mode 100644 arch/aarch64/mm/proc-syms.c
create mode 100644 arch/aarch64/mm/proc.S
diff --git a/arch/aarch64/include/asm/cputype.h
b/arch/aarch64/include/asm/cputype.h
new file mode 100644
index 000..bf5dbe7
--- /dev/null
+++ b/arch/aarch64/include/asm/cputype.h
@@ -0,0 +1,50 @@
+/*
+ * Copyright (C) 2012 ARM Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+#ifndef __ASM_CPUTYPE_H
+#define __ASM_CPUTYPE_H
+
+#define ID_MIDR_EL1"midr_el1"
+#define ID_CTR_EL0 "ctr_el0"
+
+#define ID_AA64PFR0_EL1"id_aa64pfr0_el1"
+#define ID_AA64DFR0_EL1"id_aa64dfr0_el1"
+#define ID_AA64AFR0_EL1"id_aa64afr0_el1"
+#define ID_AA64ISAR0_EL1 "id_aa64isar0_el1"
+#define ID_AA64MMFR0_EL1 "id_aa64mmfr0_el1"
+
+#define read_cpuid(reg) ({ \
+ u64 __val; \
+ asm("mrs%0, " reg : "=r" (__val)); \
+ __val; \
+})
+
+/*
+ * The CPU ID never changes at run time, so we might as well tell the
+ * compiler that it's constant. Use this function to read the CPU ID
+ * rather than directly reading processor_id or read_cpuid() directly.
+ */
+static inline u32 __attribute_const__ read_cpuid_id(void)
+{
+ return read_cpuid(ID_MIDR_EL1);
+}
+
+static inline u32 __attribute_const__ read_cpuid_cachetype(void)
+{
+ return read_cpuid(ID_CTR_EL0);
+}
+
+#endif
diff --git a/arch/aarch64/include/asm/proc-fns.h
b/arch/aarch64/include/asm/proc-fns.h
new file mode 100644
index 000..0e07dbb
--- /dev/null
+++ b/arch/aarch64/include/asm/proc-fns.h
@@ -0,0 +1,52 @@
+/*
+ * Based on arch/arm/include/asm/proc-fns.h
+ *
+ * Copyright (C) 1997-1999 Russell King
+ * Copyright (C) 2000 Deep Blue Solutions Ltd
+ * Copyright (C) 2012 ARM Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+#ifndef __ASM_PROCFNS_H
+#define __ASM_PROCFNS_H
+
+#ifdef __KERNEL__
+#ifndef __ASSEMBLY__
+
+#include
+
+struct mm_struct;
+
+extern void cpu_proc_init(void);
+extern void cpu_proc_fin(void);
+extern void cpu_do_idle(void);
+extern void cpu_do_switch_mm(unsigned long pgd_phys, struct mm_struct *mm);
+extern void cpu_reset(unsigned long addr) __attribute__((noreturn));
+
+#include
+
+#define cpu_switch_mm(pgd,mm) cpu_do_switch_mm(virt_to_phys(pgd),mm)
+
+#define cpu_get_pgd() \
+({ \
+ unsigned long pg; \
+ asm("mrs%0, ttbr0_el1\n"\
+ : "=r" (pg));
[PATCH 15/36] AArch64: Cache maintenance routines
The patch adds functionality required for cache maintenance. The AArch64 architecture mandates non-aliasing VIPT or PIPT D-cache and VIPT (may have aliases) or ASID-tagged VIVT I-cache. Cache maintenance operations are automatically broadcast in hardware between CPUs. Signed-off-by: Will Deacon Signed-off-by: Catalin Marinas --- arch/aarch64/include/asm/cache.h | 33 arch/aarch64/include/asm/cacheflush.h | 210 arch/aarch64/include/asm/cachetype.h | 49 ++ arch/aarch64/mm/cache.S | 280 + arch/aarch64/mm/flush.c | 133 5 files changed, 705 insertions(+), 0 deletions(-) create mode 100644 arch/aarch64/include/asm/cache.h create mode 100644 arch/aarch64/include/asm/cacheflush.h create mode 100644 arch/aarch64/include/asm/cachetype.h create mode 100644 arch/aarch64/mm/cache.S create mode 100644 arch/aarch64/mm/flush.c diff --git a/arch/aarch64/include/asm/cache.h b/arch/aarch64/include/asm/cache.h new file mode 100644 index 000..ceaed39 --- /dev/null +++ b/arch/aarch64/include/asm/cache.h @@ -0,0 +1,33 @@ +/* + * Copyright (C) 2012 ARM Ltd. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * 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. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ +#ifndef __ASM_CACHE_H +#define __ASM_CACHE_H + +#define L1_CACHE_SHIFT 6 +#define L1_CACHE_BYTES (1 << L1_CACHE_SHIFT) + +/* + * Memory returned by kmalloc() may be used for DMA, so we must make + * sure that all such allocations are cache aligned. Otherwise, + * unrelated code may cause parts of the buffer to be read into the + * cache before the transfer is done, causing old data to be seen by + * the CPU. + */ +#define ARCH_DMA_MINALIGN L1_CACHE_BYTES +#define ARCH_SLAB_MINALIGN 8 + +#endif diff --git a/arch/aarch64/include/asm/cacheflush.h b/arch/aarch64/include/asm/cacheflush.h new file mode 100644 index 000..cb3e9ac --- /dev/null +++ b/arch/aarch64/include/asm/cacheflush.h @@ -0,0 +1,210 @@ +/* + * Based on arch/arm/include/asm/cacheflush.h + * + * Copyright (C) 1999-2002 Russell King. + * Copyright (C) 2012 ARM Ltd. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * 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. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ +#ifndef __ASM_CACHEFLUSH_H +#define __ASM_CACHEFLUSH_H + +#include + +/* + * This flag is used to indicate that the page pointed to by a pte is clean + * and does not require cleaning before returning it to the user. + */ +#define PG_dcache_clean PG_arch_1 + +/* + * MM Cache Management + * === + * + * The arch/arm/mm/cache-*.S and arch/arm/mm/proc-*.S files + * implement these methods. + * + * Start addresses are inclusive and end addresses are exclusive; + * start addresses should be rounded down, end addresses up. + * + * See Documentation/cachetlb.txt for more information. + * Please note that the implementation of these, and the required + * effects are cache-type (VIVT/VIPT/PIPT) specific. + * + * flush_cache_kern_all() + * + * Unconditionally clean and invalidate the entire cache. + * + * flush_cache_user_mm(mm) + * + * Clean and invalidate all user space cache entries + * before a change of page tables. + * + * flush_cache_user_range(start, end, flags) + * + * Clean and invalidate a range of cache entries in the + * specified address space before a change of page tables. + * - start - user start address (inclusive, page aligned) + * - end - user end address (exclusive, page aligned) + * - flags - vma->vm_flags field + * + * coherent_kern_range(start, end) + * + * Ensure coherency between the Icache and the Dcache in the + * region described by start, end. If you have non-snooping +
[PATCH 16/36] AArch64: TLB maintenance functionality
This patch adds the TLB maintenance functions. There is no distinction
made between the I and D TLBs. TLB maintenance operations are
automatically broadcast between CPUs in hardware. The inner-shareable
operations are always present, even on UP systems.
NOTE: Large part of this patch to be dropped once Peter Z's generic
mmu_gather patches are merged.
Signed-off-by: Will Deacon
Signed-off-by: Catalin Marinas
---
arch/aarch64/include/asm/tlb.h | 191 +++
arch/aarch64/include/asm/tlbflush.h | 124 +++
arch/aarch64/mm/tlb.S | 72 +
3 files changed, 387 insertions(+), 0 deletions(-)
create mode 100644 arch/aarch64/include/asm/tlb.h
create mode 100644 arch/aarch64/include/asm/tlbflush.h
create mode 100644 arch/aarch64/mm/tlb.S
diff --git a/arch/aarch64/include/asm/tlb.h b/arch/aarch64/include/asm/tlb.h
new file mode 100644
index 000..bebf674
--- /dev/null
+++ b/arch/aarch64/include/asm/tlb.h
@@ -0,0 +1,191 @@
+/*
+ * Based on arch/arm/include/asm/tlb.h
+ *
+ * Copyright (C) 2002 Russell King
+ * Copyright (C) 2012 ARM Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+#ifndef __ASM_TLB_H
+#define __ASM_TLB_H
+
+#include
+#include
+
+#include
+#include
+
+#define MMU_GATHER_BUNDLE 8
+
+/*
+ * TLB handling. This allows us to remove pages from the page
+ * tables, and efficiently handle the TLB issues.
+ */
+struct mmu_gather {
+ struct mm_struct*mm;
+ unsigned intfullmm;
+ struct vm_area_struct *vma;
+ unsigned long range_start;
+ unsigned long range_end;
+ unsigned intnr;
+ unsigned intmax;
+ struct page **pages;
+ struct page *local[MMU_GATHER_BUNDLE];
+};
+
+/*
+ * This is unnecessarily complex. There's three ways the TLB shootdown
+ * code is used:
+ * 1. Unmapping a range of vmas. See zap_page_range(), unmap_region().
+ * tlb->fullmm = 0, and tlb_start_vma/tlb_end_vma will be called.
+ * tlb->vma will be non-NULL.
+ * 2. Unmapping all vmas. See exit_mmap().
+ * tlb->fullmm = 1, and tlb_start_vma/tlb_end_vma will be called.
+ * tlb->vma will be non-NULL. Additionally, page tables will be freed.
+ * 3. Unmapping argument pages. See shift_arg_pages().
+ * tlb->fullmm = 0, but tlb_start_vma/tlb_end_vma will not be called.
+ * tlb->vma will be NULL.
+ */
+static inline void tlb_flush(struct mmu_gather *tlb)
+{
+ if (tlb->fullmm || !tlb->vma)
+ flush_tlb_mm(tlb->mm);
+ else if (tlb->range_end > 0) {
+ flush_tlb_range(tlb->vma, tlb->range_start, tlb->range_end);
+ tlb->range_start = TASK_SIZE;
+ tlb->range_end = 0;
+ }
+}
+
+static inline void tlb_add_flush(struct mmu_gather *tlb, unsigned long addr)
+{
+ if (!tlb->fullmm) {
+ if (addr < tlb->range_start)
+ tlb->range_start = addr;
+ if (addr + PAGE_SIZE > tlb->range_end)
+ tlb->range_end = addr + PAGE_SIZE;
+ }
+}
+
+static inline void __tlb_alloc_page(struct mmu_gather *tlb)
+{
+ unsigned long addr = __get_free_pages(GFP_NOWAIT | __GFP_NOWARN, 0);
+
+ if (addr) {
+ tlb->pages = (void *)addr;
+ tlb->max = PAGE_SIZE / sizeof(struct page *);
+ }
+}
+
+static inline void tlb_flush_mmu(struct mmu_gather *tlb)
+{
+ tlb_flush(tlb);
+ free_pages_and_swap_cache(tlb->pages, tlb->nr);
+ tlb->nr = 0;
+ if (tlb->pages == tlb->local)
+ __tlb_alloc_page(tlb);
+}
+
+static inline void
+tlb_gather_mmu(struct mmu_gather *tlb, struct mm_struct *mm, unsigned int
fullmm)
+{
+ tlb->mm = mm;
+ tlb->fullmm = fullmm;
+ tlb->vma = NULL;
+ tlb->max = ARRAY_SIZE(tlb->local);
+ tlb->pages = tlb->local;
+ tlb->nr = 0;
+ __tlb_alloc_page(tlb);
+}
+
+static inline void
+tlb_finish_mmu(struct mmu_gather *tlb, unsigned long start, unsigned long end)
+{
+ tlb_flush_mmu(tlb);
+
+ /* keep the page table cache within bounds */
+ check_pgt_cache();
+
+ if (tlb->pages != tlb->local)
+ free_pages((unsigned long)tlb->pages, 0);
+}
+
+/*
+ * Memorize the range for the TLB flush.
+ */
+static inline
[PATCH 17/36] AArch64: IRQ handling
From: Marc Zyngier
This patch adds the support for IRQ handling. The actual interrupt
controller will be part of a separate patch (going into
drivers/irqchip/).
Signed-off-by: Marc Zyngier
Signed-off-by: Will Deacon
Signed-off-by: Catalin Marinas
---
arch/aarch64/include/asm/hardirq.h | 48 ++
arch/aarch64/include/asm/irq.h |8 +++
arch/aarch64/include/asm/irqflags.h | 92 +++
arch/aarch64/kernel/irq.c | 85
4 files changed, 233 insertions(+), 0 deletions(-)
create mode 100644 arch/aarch64/include/asm/hardirq.h
create mode 100644 arch/aarch64/include/asm/irq.h
create mode 100644 arch/aarch64/include/asm/irqflags.h
create mode 100644 arch/aarch64/kernel/irq.c
diff --git a/arch/aarch64/include/asm/hardirq.h
b/arch/aarch64/include/asm/hardirq.h
new file mode 100644
index 000..00e25c0
--- /dev/null
+++ b/arch/aarch64/include/asm/hardirq.h
@@ -0,0 +1,48 @@
+/*
+ * Copyright (C) 2012 ARM Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+#ifndef __ASM_HARDIRQ_H
+#define __ASM_HARDIRQ_H
+
+#include
+#include
+#include
+
+typedef struct {
+ unsigned int __softirq_pending;
+} cacheline_aligned irq_cpustat_t;
+
+#include /* Standard mappings for irq_cpustat_t above */
+
+#define __inc_irq_stat(cpu, member)__IRQ_STAT(cpu, member)++
+#define __get_irq_stat(cpu, member)__IRQ_STAT(cpu, member)
+
+#ifdef CONFIG_SMP
+u64 smp_irq_stat_cpu(unsigned int cpu);
+#define arch_irq_stat_cpu smp_irq_stat_cpu
+#endif
+
+#define __ARCH_IRQ_EXIT_IRQS_DISABLED 1
+
+static inline void ack_bad_irq(unsigned int irq)
+{
+ extern unsigned long irq_err_count;
+ irq_err_count++;
+}
+
+extern void handle_IRQ(unsigned int, struct pt_regs *);
+
+#endif /* __ASM_HARDIRQ_H */
diff --git a/arch/aarch64/include/asm/irq.h b/arch/aarch64/include/asm/irq.h
new file mode 100644
index 000..a4e1cad
--- /dev/null
+++ b/arch/aarch64/include/asm/irq.h
@@ -0,0 +1,8 @@
+#ifndef __ASM_IRQ_H
+#define __ASM_IRQ_H
+
+#include
+
+extern void (*handle_arch_irq)(struct pt_regs *);
+
+#endif
diff --git a/arch/aarch64/include/asm/irqflags.h
b/arch/aarch64/include/asm/irqflags.h
new file mode 100644
index 000..6f075a9
--- /dev/null
+++ b/arch/aarch64/include/asm/irqflags.h
@@ -0,0 +1,92 @@
+/*
+ * Copyright (C) 2012 ARM Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+#ifndef __ASM_IRQFLAGS_H
+#define __ASM_IRQFLAGS_H
+
+#ifdef __KERNEL__
+
+#include
+
+/*
+ * CPU interrupt mask handling.
+ */
+static inline unsigned long arch_local_irq_save(void)
+{
+ unsigned long flags;
+ asm volatile(
+ "mrs%0, daif// arch_local_irq_save\n"
+ "msrdaifset, #2"
+ : "=r" (flags)
+ :
+ : "memory");
+ return flags;
+}
+
+static inline void arch_local_irq_enable(void)
+{
+ asm volatile(
+ "msrdaifclr, #2 // arch_local_irq_enable"
+ :
+ :
+ : "memory");
+}
+
+static inline void arch_local_irq_disable(void)
+{
+ asm volatile(
+ "msrdaifset, #2 // arch_local_irq_disable"
+ :
+ :
+ : "memory");
+}
+
+#define local_fiq_enable() asm("msrdaifclr, #1" : : : "memory")
+#define local_fiq_disable()asm("msrdaifset, #1" : : : "memory")
+
+/*
+ * Save the current interrupt enable state.
+ */
+static inline unsigned long arch_local_save_flags(void)
+{
+ unsigned long flags;
+ asm volatile(
+ "mrs%0, daif// arch_local_save_flags"
+ : "=r" (flags)
+ :
[PATCH 04/36] ipc: compat: use signed size_t types for msgsnd and msgrcv
From: Will Deacon
The msgsnd and msgrcv system calls use size_t to represent the size of
the message being transferred. POSIX states that values of msgsz greater
than SSIZE_MAX cause the result to be implementation-defined. On Linux,
this equates to returning -EINVAL if (long) msgsz < 0.
For compat tasks where !CONFIG_ARCH_WANT_OLD_COMPAT_IPC and
compat_size_t is smaller than size_t, negative size values passed from
userspace will be interpreted as positive values by do_msg{rcv,snd} and
will fail to exit early with -EINVAL.
This patch changes the compat prototypes for msg{rcv,snd} so that the
message size is represented as a compat_ssize_t, which we cast to the
native ssize_t type for the core IPC code.
Signed-off-by: Will Deacon
Signed-off-by: Catalin Marinas
---
include/linux/compat.h |4 ++--
ipc/compat.c |8
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/include/linux/compat.h b/include/linux/compat.h
index 9f68e90..f2b8fe2 100644
--- a/include/linux/compat.h
+++ b/include/linux/compat.h
@@ -266,9 +266,9 @@ long compat_sys_shmat(int first, int second, compat_uptr_t
third, int version,
#else
long compat_sys_semctl(int semid, int semnum, int cmd, int arg);
long compat_sys_msgsnd(int msqid, struct compat_msgbuf __user *msgp,
- size_t msgsz, int msgflg);
+ compat_ssize_t msgsz, int msgflg);
long compat_sys_msgrcv(int msqid, struct compat_msgbuf __user *msgp,
- size_t msgsz, long msgtyp, int msgflg);
+ compat_ssize_t msgsz, long msgtyp, int msgflg);
long compat_sys_shmat(int shmid, compat_uptr_t shmaddr, int shmflg);
#endif
long compat_sys_msgctl(int first, int second, void __user *uptr);
diff --git a/ipc/compat.c b/ipc/compat.c
index a41600f..20f92b2 100644
--- a/ipc/compat.c
+++ b/ipc/compat.c
@@ -373,21 +373,21 @@ long compat_sys_semctl(int semid, int semnum, int cmd,
int arg)
}
long compat_sys_msgsnd(int msqid, struct compat_msgbuf __user *msgp,
- size_t msgsz, int msgflg)
+ compat_ssize_t msgsz, int msgflg)
{
compat_long_t mtype;
if (get_user(mtype, &msgp->mtype))
return -EFAULT;
- return do_msgsnd(msqid, mtype, msgp->mtext, msgsz, msgflg);
+ return do_msgsnd(msqid, mtype, msgp->mtext, (ssize_t)msgsz, msgflg);
}
long compat_sys_msgrcv(int msqid, struct compat_msgbuf __user *msgp,
- size_t msgsz, long msgtyp, int msgflg)
+ compat_ssize_t msgsz, long msgtyp, int msgflg)
{
long err, mtype;
- err = do_msgrcv(msqid, &mtype, msgp->mtext, msgsz, msgtyp, msgflg);
+ err = do_msgrcv(msqid, &mtype, msgp->mtext, (ssize_t)msgsz, msgtyp,
msgflg);
if (err < 0)
goto out;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 03/36] ipc: allow compat IPC version field parsing if !ARCH_WANT_OLD_COMPAT_IPC
From: Will Deacon
Commit 48b25c43 ("[PATCH v3] ipc: provide generic compat versions of IPC
syscalls") added a new ARCH_WANT_OLD_COMPAT_IPC config option for
architectures to select if their compat target requires the old IPC
syscall interface.
For architectures that do not require the internal calling conventions
provided by this option, but have a compat target where the C library
passes the IPC_64 flag explicitly, compat_ipc_parse_version no longer
strips out the flag before calling the native system call
implementation, resulting in unknown SHM/IPC commands and -EINVAL being
returned to userspace.
This patch separates the selection of the internal calling conventions
for the IPC syscalls from the version parsing, allowing architectures to
select __ARCH_WANT_COMPAT_IPC_PARSE_VERSION if they want to use version
parsing whilst retaining the newer syscall calling conventions.
Signed-off-by: Will Deacon
Signed-off-by: Catalin Marinas
---
include/linux/compat.h |1 +
ipc/compat.c |2 +-
2 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/include/linux/compat.h b/include/linux/compat.h
index 4e89039..9f68e90 100644
--- a/include/linux/compat.h
+++ b/include/linux/compat.h
@@ -256,6 +256,7 @@ compat_sys_get_robust_list(int pid, compat_uptr_t __user
*head_ptr,
compat_size_t __user *len_ptr);
#ifdef CONFIG_ARCH_WANT_OLD_COMPAT_IPC
+#define __ARCH_WANT_COMPAT_IPC_PARSE_VERSION
long compat_sys_semctl(int first, int second, int third, void __user *uptr);
long compat_sys_msgsnd(int first, int second, int third, void __user *uptr);
long compat_sys_msgrcv(int first, int second, int msgtyp, int third,
diff --git a/ipc/compat.c b/ipc/compat.c
index 53cebdf..a41600f 100644
--- a/ipc/compat.c
+++ b/ipc/compat.c
@@ -118,7 +118,7 @@ extern int sem_ctls[];
static inline int compat_ipc_parse_version(int *cmd)
{
-#ifdef CONFIG_ARCH_WANT_OLD_COMPAT_IPC
+#ifdef __ARCH_WANT_COMPAT_IPC_PARSE_VERSION
int version = *cmd & IPC_64;
/* this is tricky: architectures that have support for the old
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 18/36] AArch64: Atomic operations
This patch introduces the atomic, mutex and futex operations. Many
atomic operations use the load-acquire and store-release operations
which imply barriers, avoiding the need for explicit DMB.
Signed-off-by: Will Deacon
Signed-off-by: Catalin Marinas
---
arch/aarch64/include/asm/atomic.h | 307 +
arch/aarch64/include/asm/futex.h | 135
arch/aarch64/include/asm/mutex.h | 132
3 files changed, 574 insertions(+), 0 deletions(-)
create mode 100644 arch/aarch64/include/asm/atomic.h
create mode 100644 arch/aarch64/include/asm/futex.h
create mode 100644 arch/aarch64/include/asm/mutex.h
diff --git a/arch/aarch64/include/asm/atomic.h
b/arch/aarch64/include/asm/atomic.h
new file mode 100644
index 000..a26675b
--- /dev/null
+++ b/arch/aarch64/include/asm/atomic.h
@@ -0,0 +1,307 @@
+/*
+ * Based on arch/arm/include/asm/atomic.h
+ *
+ * Copyright (C) 1996 Russell King.
+ * Copyright (C) 2002 Deep Blue Solutions Ltd.
+ * Copyright (C) 2012 ARM Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+#ifndef __ASM_ATOMIC_H
+#define __ASM_ATOMIC_H
+
+#include
+#include
+
+#include
+#include
+
+#define ATOMIC_INIT(i) { (i) }
+
+#ifdef __KERNEL__
+
+/*
+ * On ARM, ordinary assignment (str instruction) doesn't clear the local
+ * strex/ldrex monitor on some implementations. The reason we can use it for
+ * atomic_set() is the clrex or dummy strex done on every exception return.
+ */
+#define atomic_read(v) (*(volatile int *)&(v)->counter)
+#define atomic_set(v,i)(((v)->counter) = (i))
+
+/*
+ * AArch64 UP and SMP safe atomic ops. We use load exclusive and
+ * store exclusive to ensure that these are atomic. We may loop
+ * to ensure that the update happens.
+ */
+static inline void atomic_add(int i, atomic_t *v)
+{
+ unsigned long tmp;
+ int result;
+
+ asm volatile("// atomic_add\n"
+"1:ldxr%w0, [%3]\n"
+" add %w0, %w0, %w4\n"
+" stxr%w1, %w0, [%3]\n"
+" cbnz%w1,1b"
+ : "=&r" (result), "=&r" (tmp), "+o" (v->counter)
+ : "r" (&v->counter), "Ir" (i)
+ : "cc");
+}
+
+static inline int atomic_add_return(int i, atomic_t *v)
+{
+ unsigned long tmp;
+ int result;
+
+ asm volatile("// atomic_add_return\n"
+"1:ldaxr %w0, [%3]\n"
+" add %w0, %w0, %w4\n"
+" stlxr %w1, %w0, [%3]\n"
+" cbnz%w1, 1b"
+ : "=&r" (result), "=&r" (tmp), "+o" (v->counter)
+ : "r" (&v->counter), "Ir" (i)
+ : "cc");
+
+ return result;
+}
+
+static inline void atomic_sub(int i, atomic_t *v)
+{
+ unsigned long tmp;
+ int result;
+
+ asm volatile("// atomic_sub\n"
+"1:ldxr%w0, [%3]\n"
+" sub %w0, %w0, %w4\n"
+" stxr%w1, %w0, [%3]\n"
+" cbnz%w1, 1b"
+ : "=&r" (result), "=&r" (tmp), "+o" (v->counter)
+ : "r" (&v->counter), "Ir" (i)
+ : "cc");
+}
+
+static inline int atomic_sub_return(int i, atomic_t *v)
+{
+ unsigned long tmp;
+ int result;
+
+ asm volatile("// atomic_sub_return\n"
+"1:ldaxr %w0, [%3]\n"
+" sub %w0, %w0, %w4\n"
+" stlxr %w1, %w0, [%3]\n"
+" cbnz%w1, 1b"
+ : "=&r" (result), "=&r" (tmp), "+o" (v->counter)
+ : "r" (&v->counter), "Ir" (i)
+ : "cc");
+
+ return result;
+}
+
+static inline int atomic_cmpxchg(atomic_t *ptr, int old, int new)
+{
+ unsigned long tmp;
+ int oldval;
+
+ asm volatile("// atomic_cmpxchg\n"
+"1:ldaxr %w1, [%3]\n"
+" cmp %w1, %w4\n"
+" b.ne2f\n"
+" stlxr %w0, %w5, [%3]\n"
+" cbnz%w0, 1b\n"
+"2:"
+ : "=&r" (tmp), "=&r" (oldval), "+o" (ptr->counter)
+ : "r" (&ptr->counter), "Ir" (old), "r" (new)
+ : "cc");
+
+ return oldval;
+}
+
+static inline void atomic_clear_mask(unsigned long mask, unsigned long *addr)
+{
+ unsigned long tmp, tmp2;
+
+ asm volatile("// atomic_clear_mask\n"
+"1:ldxr%0, [%3]\n"
+" bic %0, %0, %4\n"
+" stxr%w1, %0, [%3]\n"
+" cbnz%w1, 1b"
+ : "=&r" (tmp), "=&r" (tmp2), "+o" (*addr)
+ : "r" (addr), "Ir" (mask)
+ : "cc");
+}
+
+#define atomic_xchg(v, new) (xchg(&((v)->counter), new))
+
+static inline int __atomic_add_unless(atomic_t *v, int a, int u)
+{
+ int c, old;
+
+ c =
[PATCH 20/36] AArch64: DMA mapping API
This patch adds support for the DMA mapping API. It uses dma_map_ops for
flexibility and it currently supports swiotlb. This patch could be
simplified further if the DMA accesses are coherent (not mandated by the
architecture) or if corresponding hooks are placed in the generic
swiotlb code to deal with cache maintenance.
Signed-off-by: Catalin Marinas
---
arch/aarch64/include/asm/dma-mapping.h | 134
arch/aarch64/mm/dma-mapping.c | 209
2 files changed, 343 insertions(+), 0 deletions(-)
create mode 100644 arch/aarch64/include/asm/dma-mapping.h
create mode 100644 arch/aarch64/mm/dma-mapping.c
diff --git a/arch/aarch64/include/asm/dma-mapping.h
b/arch/aarch64/include/asm/dma-mapping.h
new file mode 100644
index 000..1896880
--- /dev/null
+++ b/arch/aarch64/include/asm/dma-mapping.h
@@ -0,0 +1,134 @@
+/*
+ * Copyright (C) 2012 ARM Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+#ifndef __ASM_DMA_MAPPING_H
+#define __ASM_DMA_MAPPING_H
+
+#ifdef __KERNEL__
+
+#include
+#include
+
+#include
+
+#define ARCH_HAS_DMA_GET_REQUIRED_MASK
+
+extern struct dma_map_ops *dma_ops;
+
+static inline struct dma_map_ops *get_dma_ops(struct device *dev)
+{
+ if (unlikely(!dev) || !dev->archdata.dma_ops)
+ return dma_ops;
+ else
+ return dev->archdata.dma_ops;
+}
+
+#include
+
+static inline dma_addr_t phys_to_dma(struct device *dev, phys_addr_t paddr)
+{
+ return (dma_addr_t)paddr;
+}
+
+static inline phys_addr_t dma_to_phys(struct device *dev, dma_addr_t dev_addr)
+{
+ return (phys_addr_t)dev_addr;
+}
+
+static inline int dma_mapping_error(struct device *dev, dma_addr_t dev_addr)
+{
+ struct dma_map_ops *ops = get_dma_ops(dev);
+ return ops->mapping_error(dev, dev_addr);
+}
+
+static inline int dma_supported(struct device *dev, u64 mask)
+{
+ struct dma_map_ops *ops = get_dma_ops(dev);
+ return ops->dma_supported(dev, mask);
+}
+
+static inline int dma_set_mask(struct device *dev, u64 mask)
+{
+ if (!dev->dma_mask || !dma_supported(dev, mask))
+ return -EIO;
+ *dev->dma_mask = mask;
+
+ return 0;
+}
+
+static inline bool dma_capable(struct device *dev, dma_addr_t addr, size_t
size)
+{
+ if (!dev->dma_mask)
+ return 0;
+
+ return addr + size - 1 <= *dev->dma_mask;
+}
+
+static inline void dma_mark_clean(void *addr, size_t size)
+{
+}
+
+static inline void *dma_alloc_coherent(struct device *dev, size_t size,
+ dma_addr_t *dma_handle, gfp_t flags)
+{
+ struct dma_map_ops *ops = get_dma_ops(dev);
+ void *vaddr;
+
+ if (dma_alloc_from_coherent(dev, size, dma_handle, &vaddr))
+ return vaddr;
+
+ vaddr = ops->alloc(dev, size, dma_handle, flags, NULL);
+ debug_dma_alloc_coherent(dev, size, *dma_handle, vaddr);
+ return vaddr;
+}
+
+static inline void dma_free_coherent(struct device *dev, size_t size,
+void *vaddr, dma_addr_t dev_addr)
+{
+ struct dma_map_ops *ops = get_dma_ops(dev);
+
+ if (dma_release_from_coherent(dev, get_order(size), vaddr))
+ return;
+
+ debug_dma_free_coherent(dev, size, vaddr, dev_addr);
+ ops->free(dev, size, vaddr, dev_addr, NULL);
+}
+
+static inline int dma_mmap_coherent(struct device *dev,
+ struct vm_area_struct *vma,
+ void *cpu_addr, dma_addr_t dev_addr,
+ size_t size)
+{
+ vma->vm_page_prot = pgprot_dmacoherent(vma->vm_page_prot);
+ return remap_vmalloc_range(vma, cpu_addr, vma->vm_pgoff);
+}
+
+/*
+ * There is no dma_cache_sync() implementation, so just return NULL here.
+ */
+static inline void *dma_alloc_noncoherent(struct device *dev, size_t size,
+ dma_addr_t *handle, gfp_t flags)
+{
+ return NULL;
+}
+
+static inline void dma_free_noncoherent(struct device *dev, size_t size,
+ void *cpu_addr, dma_addr_t handle)
+{
+}
+
+#endif /* __KERNEL__ */
+#endif /* __ASM_DMA_MAPPING_H */
diff --git a/arch/aarch64/mm/dma-mapping.c b/arch/aarch64/mm/dma-mapping.c
new file mode 100644
index 000..2ef7a76
--- /dev/null
+++ b/arch/a
[PATCH 19/36] AArch64: Device specific operations
This patch adds several definitions for device communication, including
I/O accessors and ioremap(). The __raw_* accessors are implemented as
inline asm to avoid compiler generation of post-indexed accesses (less
efficient to emulate in a virtualised environment).
Signed-off-by: Will Deacon
Signed-off-by: Catalin Marinas
---
arch/aarch64/include/asm/device.h | 27
arch/aarch64/include/asm/fb.h | 35 +
arch/aarch64/include/asm/io.h | 260 +
arch/aarch64/kernel/io.c | 65 +
arch/aarch64/mm/ioremap.c | 102 +++
5 files changed, 489 insertions(+), 0 deletions(-)
create mode 100644 arch/aarch64/include/asm/device.h
create mode 100644 arch/aarch64/include/asm/fb.h
create mode 100644 arch/aarch64/include/asm/io.h
create mode 100644 arch/aarch64/kernel/io.c
create mode 100644 arch/aarch64/mm/ioremap.c
diff --git a/arch/aarch64/include/asm/device.h
b/arch/aarch64/include/asm/device.h
new file mode 100644
index 000..0fc1008
--- /dev/null
+++ b/arch/aarch64/include/asm/device.h
@@ -0,0 +1,27 @@
+/*
+ * Copyright (C) 2012 ARM Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+#ifndef __ASM_DEVICE_H
+#define __ASM_DEVICE_H
+
+struct dev_archdata {
+ struct dma_map_ops *dma_ops;
+};
+
+struct pdev_archdata {
+};
+
+#endif
diff --git a/arch/aarch64/include/asm/fb.h b/arch/aarch64/include/asm/fb.h
new file mode 100644
index 000..be9167e
--- /dev/null
+++ b/arch/aarch64/include/asm/fb.h
@@ -0,0 +1,35 @@
+/*
+ * Copyright (C) 2012 ARM Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+#ifndef __ASM_FB_H_
+#define __ASM_FB_H_
+
+#include
+#include
+#include
+
+static inline void fb_pgprotect(struct file *file, struct vm_area_struct *vma,
+ unsigned long off)
+{
+ vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot);
+}
+
+static inline int fb_is_primary_device(struct fb_info *info)
+{
+ return 0;
+}
+
+#endif /* __ASM_FB_H_ */
diff --git a/arch/aarch64/include/asm/io.h b/arch/aarch64/include/asm/io.h
new file mode 100644
index 000..958cb7c
--- /dev/null
+++ b/arch/aarch64/include/asm/io.h
@@ -0,0 +1,260 @@
+/*
+ * Based on arch/arm/include/asm/io.h
+ *
+ * Copyright (C) 1996-2000 Russell King
+ * Copyright (C) 2012 ARM Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+#ifndef __ASM_IO_H
+#define __ASM_IO_H
+
+#ifdef __KERNEL__
+
+#include
+
+#include
+#include
+
+/*
+ * Generic IO read/write. These perform native-endian accesses.
+ */
+static inline void __raw_writeb(u8 val, volatile void __iomem *addr)
+{
+ asm volatile("strb %w0, [%1]" : : "r" (val), "r" (addr));
+}
+
+static inline void __raw_writew(u16 val, volatile void __iomem *addr)
+{
+ asm volatile("strh %w0, [%1]" : : "r" (val), "r" (addr));
+}
+
+static inline void __raw_writel(u32 val, volatile void __iomem *addr)
+{
+ asm volatile("str %w0, [%1]" : : "r" (val), "r" (addr));
+}
+
+static inline void __raw_writeq(u64 val, volatile void __iomem *addr)
+{
+ asm volatile("str %0, [%1]" : : "r" (val), "r" (addr));
+}
+
+static inline u
[PATCH 21/36] AArch64: SMP support
This patch adds SMP initialisation and spinlocks implementation for
AArch64. The spinlock support uses the new load-acquire/store-release
instructions to avoid explicit barriers. The architecture also specifies
that an event is automatically generated when clearing the exclusive
monitor state to wake up processors in WFE, so there is no need for an
explicit DSB/SEV instruction sequence. The SEVL instruction is used to
set the exclusive monitor locally as there is no conditional WFE and a
branch is more expensive.
For the SMP booting protocol, see Documentation/aarch64/booting.txt.
Signed-off-by: Will Deacon
Signed-off-by: Marc Zyngier
Signed-off-by: Catalin Marinas
---
arch/aarch64/include/asm/hardirq.h|5 +
arch/aarch64/include/asm/smp.h| 70 +
arch/aarch64/include/asm/spinlock.h | 200
arch/aarch64/include/asm/spinlock_types.h | 39 +++
arch/aarch64/kernel/smp.c | 471 +
5 files changed, 785 insertions(+), 0 deletions(-)
create mode 100644 arch/aarch64/include/asm/smp.h
create mode 100644 arch/aarch64/include/asm/spinlock.h
create mode 100644 arch/aarch64/include/asm/spinlock_types.h
create mode 100644 arch/aarch64/kernel/smp.c
diff --git a/arch/aarch64/include/asm/hardirq.h
b/arch/aarch64/include/asm/hardirq.h
index 00e25c0..6d063f1 100644
--- a/arch/aarch64/include/asm/hardirq.h
+++ b/arch/aarch64/include/asm/hardirq.h
@@ -21,8 +21,13 @@
#include
#include
+#define NR_IPI 4
+
typedef struct {
unsigned int __softirq_pending;
+#ifdef CONFIG_SMP
+ unsigned int ipi_irqs[NR_IPI];
+#endif
} cacheline_aligned irq_cpustat_t;
#include /* Standard mappings for irq_cpustat_t above */
diff --git a/arch/aarch64/include/asm/smp.h b/arch/aarch64/include/asm/smp.h
new file mode 100644
index 000..5067cc6
--- /dev/null
+++ b/arch/aarch64/include/asm/smp.h
@@ -0,0 +1,70 @@
+/*
+ * Copyright (C) 2012 ARM Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+#ifndef __ASM_SMP_H
+#define __ASM_SMP_H
+
+#include
+#include
+#include
+
+#ifndef CONFIG_SMP
+# error " included in non-SMP build"
+#endif
+
+#define raw_smp_processor_id() (current_thread_info()->cpu)
+
+struct seq_file;
+
+/*
+ * generate IPI list text
+ */
+extern void show_ipi_list(struct seq_file *p, int prec);
+
+/*
+ * Called from C code, this handles an IPI.
+ */
+extern void handle_IPI(int ipinr, struct pt_regs *regs);
+
+/*
+ * Setup the set of possible CPUs (via set_cpu_possible)
+ */
+extern void smp_init_cpus(void);
+
+/*
+ * Provide a function to raise an IPI cross call on CPUs in callmap.
+ */
+extern void set_smp_cross_call(void (*)(const struct cpumask *, unsigned int));
+
+/*
+ * Called from the secondary holding pen, this is the secondary CPU entry
point.
+ */
+asmlinkage void secondary_start_kernel(void);
+
+/*
+ * Initial data for bringing up a secondary CPU.
+ */
+struct secondary_data {
+ void *stack;
+};
+extern struct secondary_data secondary_data;
+extern void secondary_holding_pen(void);
+extern volatile unsigned long secondary_holding_pen_release;
+
+extern void arch_send_call_function_single_ipi(int cpu);
+extern void arch_send_call_function_ipi_mask(const struct cpumask *mask);
+
+#endif /* ifndef __ASM_SMP_H */
diff --git a/arch/aarch64/include/asm/spinlock.h
b/arch/aarch64/include/asm/spinlock.h
new file mode 100644
index 000..6206a6e
--- /dev/null
+++ b/arch/aarch64/include/asm/spinlock.h
@@ -0,0 +1,200 @@
+/*
+ * Copyright (C) 2012 ARM Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+#ifndef __ASM_SPINLOCK_H
+#define __ASM_SPINLOCK_H
+
+#include
+#include
+
+/*
+ * AArch64 Spin-locking.
+ *
+ * We exclusively read the old value. If it is zero, we may have
+
[PATCH net,1/1] hyperv: Add support for setting MAC from within guests
This adds support for setting synthetic NIC MAC address from within Linux
guests. Before using this feature, the option "spoofing of MAC address"
should be enabled at the Hyper-V manager / Settings of the synthetic
NIC.
Thanks to Kin Cho for the initial implementation and
tests. And, thanks to Long Li for the debugging
works.
Reported-and-tested-by: Kin Cho
Reported-by: Long Li
Signed-off-by: Haiyang Zhang
Reviewed-by: K. Y. Srinivasan
---
drivers/net/hyperv/hyperv_net.h |1 +
drivers/net/hyperv/netvsc_drv.c | 30 +-
drivers/net/hyperv/rndis_filter.c | 79 +
3 files changed, 109 insertions(+), 1 deletions(-)
diff --git a/drivers/net/hyperv/hyperv_net.h b/drivers/net/hyperv/hyperv_net.h
index 2857ab0..95ceb35 100644
--- a/drivers/net/hyperv/hyperv_net.h
+++ b/drivers/net/hyperv/hyperv_net.h
@@ -131,6 +131,7 @@ int rndis_filter_send(struct hv_device *dev,
struct hv_netvsc_packet *pkt);
int rndis_filter_set_packet_filter(struct rndis_device *dev, u32 new_filter);
+int rndis_filter_set_device_mac(struct hv_device *hdev, char *mac);
#define NVSP_INVALID_PROTOCOL_VERSION ((u32)0x)
diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
index 8f8ed33..8e23c08 100644
--- a/drivers/net/hyperv/netvsc_drv.c
+++ b/drivers/net/hyperv/netvsc_drv.c
@@ -341,6 +341,34 @@ static int netvsc_change_mtu(struct net_device *ndev, int
mtu)
return 0;
}
+
+static int netvsc_set_mac_addr(struct net_device *ndev, void *p)
+{
+ struct net_device_context *ndevctx = netdev_priv(ndev);
+ struct hv_device *hdev = ndevctx->device_ctx;
+ struct sockaddr *addr = p;
+ char save_adr[14];
+ unsigned char save_aatype;
+ int err;
+
+ memcpy(save_adr, ndev->dev_addr, ETH_ALEN);
+ save_aatype = ndev->addr_assign_type;
+
+ err = eth_mac_addr(ndev, p);
+ if (err != 0)
+ return err;
+
+ err = rndis_filter_set_device_mac(hdev, addr->sa_data);
+ if (err != 0) {
+ /* roll back to saved MAC */
+ memcpy(ndev->dev_addr, save_adr, ETH_ALEN);
+ ndev->addr_assign_type = save_aatype;
+ }
+
+ return err;
+}
+
+
static const struct ethtool_ops ethtool_ops = {
.get_drvinfo= netvsc_get_drvinfo,
.get_link = ethtool_op_get_link,
@@ -353,7 +381,7 @@ static const struct net_device_ops device_ops = {
.ndo_set_rx_mode = netvsc_set_multicast_list,
.ndo_change_mtu = netvsc_change_mtu,
.ndo_validate_addr =eth_validate_addr,
- .ndo_set_mac_address = eth_mac_addr,
+ .ndo_set_mac_address = netvsc_set_mac_addr,
};
/*
diff --git a/drivers/net/hyperv/rndis_filter.c
b/drivers/net/hyperv/rndis_filter.c
index 981ebb1..fbf5394 100644
--- a/drivers/net/hyperv/rndis_filter.c
+++ b/drivers/net/hyperv/rndis_filter.c
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
#include "hyperv_net.h"
@@ -47,6 +48,7 @@ struct rndis_request {
struct hv_page_buffer buf;
/* FIXME: We assumed a fixed size request here. */
struct rndis_message request_msg;
+ u8 ext[100];
};
static void rndis_filter_send_completion(void *ctx);
@@ -511,6 +513,83 @@ static int rndis_filter_query_device_mac(struct
rndis_device *dev)
dev->hw_mac_adr, &size);
}
+#define NWADR_STR "NetworkAddress"
+#define NWADR_STRLEN 14
+
+int rndis_filter_set_device_mac(struct hv_device *hdev, char *mac)
+{
+ struct netvsc_device *nvdev = hv_get_drvdata(hdev);
+ struct rndis_device *rdev = nvdev->extension;
+ struct net_device *ndev = nvdev->ndev;
+ struct rndis_request *request;
+ struct rndis_set_request *set;
+ struct rndis_config_parameter_info *cpi;
+ wchar_t *cfg_nwadr, *cfg_mac;
+ struct rndis_set_complete *set_complete;
+ char macstr[2*ETH_ALEN+1];
+ u32 extlen = sizeof(struct rndis_config_parameter_info) +
+ 2*NWADR_STRLEN + 4*ETH_ALEN;
+ int ret, t;
+
+ request = get_rndis_request(rdev, RNDIS_MSG_SET,
+ RNDIS_MESSAGE_SIZE(struct rndis_set_request) + extlen);
+ if (!request)
+ return -ENOMEM;
+
+ set = &request->request_msg.msg.set_req;
+ set->oid = RNDIS_OID_GEN_RNDIS_CONFIG_PARAMETER;
+ set->info_buflen = extlen;
+ set->info_buf_offset = sizeof(struct rndis_set_request);
+ set->dev_vc_handle = 0;
+
+ cpi = (struct rndis_config_parameter_info *)((ulong)set +
+ set->info_buf_offset);
+ cpi->parameter_name_offset =
+ sizeof(struct rndis_config_parameter_info);
+ /* Multiply by 2 because host needs 2 bytes (utf16) for each char */
+ cpi->parameter_name_length = 2*NWADR_STRLEN;
+ cpi->parameter_type = RNDIS_CONFIG_PARAM_TYPE_STRING;
+
