* linux-next: manual merge of the akpm tree with the jc_docs tree
From: Stephen Rothwell @ 2016-11-09 4:19 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-next, linux-kernel, Jani Nikula, Mimi Zohar
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in:
Documentation/admin-guide/kernel-parameters.rst
between commit:
e52347bd66f6 ("Documentation/admin-guide: split the kernel parameter list to a separate file")
from the jc_docs tree and patch:
"ima: define a canonical binary_runtime_measurements list format"
from the akpm tree.
I fixed it up (I moved the change to
Documentation/admin-guide/kernel-parameters.txt) and can carry the fix
as necessary. This is now fixed as far as linux-next is concerned, but
any non trivial conflicts should be mentioned to your upstream
maintainer when your tree is submitted for merging. You may also want
to consider cooperating with the maintainer of the conflicting tree to
minimise any particularly complex conflicts.
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* Re: Configure RAM size on iMX53 board
From: Jose Luis Zabalza @ 2016-11-09 4:23 UTC (permalink / raw)
To: barebox
In-Reply-To: <20161108212434.gvlq5fy6vrbn2en5@pengutronix.de>
There is no form of detection. UBoot (a very old version) don't use
any CS1 address, except with the memtest command.
If memtest command is executed with 512MB version, UBoot hangs, as expected.
I set the mem kernel parameter using a environment variable and kernel
can reach CS1 memory.
2016-11-08 22:24 GMT+01:00 Sascha Hauer <s.hauer@pengutronix.de>:
> On Tue, Nov 08, 2016 at 09:51:36PM +0100, Jose Luis Zabalza wrote:
>> > So you have 512MiB on each chip select, so I assume that on the 512MiB
>> > board variants CS1 is not equipped.
>>
>> Yes, it is.
>>
>> >In that case you can in lowlevel.c
>> > test if you find SDRAM on CS1 and if not, disable the chip select
>> > completely in the SDRAM controller.
>>
>> OK. But how ? I enable CS0 and CS1 on DCD table. Is there any way to
>> tell barebox not to use CS1 ?
>>
>> > I am not sure how you can detect if there's SDRAM on CS1. I've seen
>> > situations in which the board just hangs if you access non existent RAM
>> > areas.
>>
>> I have tried it, but I have not be able to implement a code for
>> autodetect. If the code write or read a value on a position without
>> physical chip, the microcontroller hangs. ????
>>
>> But it's not a problem. A solution is configure both CS and MMU. If
>> bootloader don't access to high positions, there is not problem. After
>> I set a environment variable with memory size and the mem kernel
>> parameter (or ATAG) does the rest.
>
> You said that both board variants work with the same U-Boot binary, how
> does it work there? Is there some detection mechanism or is it only some
> environment variable that you have to set manually?
>
> Sascha
>
> --
> Pengutronix e.K. | |
> Industrial Linux Solutions | http://www.pengutronix.de/ |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
--
jlz.3008 a t gmail.com
Linux Counter 172551
https://linuxcounter.net/cert/172551.png
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply
* Re: [PATCH 1/4] x86/cpufeature: Add User-Mode Instruction Prevention definitions
From: Ricardo Neri @ 2016-11-09 4:25 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Ingo Molnar, Thomas Gleixner, H. Peter Anvin,
linux-kernel@vger.kernel.org, X86 ML, linux-doc@vger.kernel.org,
Andy Lutomirski, Andrew Morton, Borislav Petkov, Brian Gerst,
Chen Yucong, Chris Metcalf, Dave Hansen, Fenghua Yu, Huang Rui,
Jiri Slaby, Jonathan Corbet, Michael S . Tsirkin, Paul Gortmaker,
Peter Zijlstra, Ravi V . Shankar, Shuah Khan, Vlastimil Babka
In-Reply-To: <CALCETrXGFm8pFzn3qCr_k7n=9OUiKtFXRT0bg6TebnrxkTeMRQ@mail.gmail.com>
On Tue, 2016-11-08 at 07:32 -0800, Andy Lutomirski wrote:
> > diff --git a/arch/x86/include/asm/disabled-features.h
> b/arch/x86/include/asm/disabled-features.h
> > index 85599ad..4707445 100644
> > --- a/arch/x86/include/asm/disabled-features.h
> > +++ b/arch/x86/include/asm/disabled-features.h
> > @@ -16,6 +16,12 @@
> > # define DISABLE_MPX (1<<(X86_FEATURE_MPX & 31))
> > #endif
> >
> > +#ifdef CONFIG_X86_INTEL_UMIP
>
> ^^^^^
>
> What's this?
>
> Let's try to do this with a minimum of configuration.
My intention here is put in this file all the #if build configurations
so that I don't have to put them other files by using functions such as
cpu_feature_enable. Isn't this the intention of this file?
Thanks and BR,
Ricardo
^ permalink raw reply
* Re: [PATCH 0/4] x86: enable User-Mode Instruction Prevention
From: Ricardo Neri @ 2016-11-09 4:26 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Andy Lutomirski, Peter Zijlstra, Ingo Molnar, H. Peter Anvin,
linux-kernel@vger.kernel.org, X86 ML, linux-doc@vger.kernel.org,
Andy Lutomirski, Andrew Morton, Borislav Petkov, Brian Gerst,
Chen Yucong, Chris Metcalf, Dave Hansen, Fenghua Yu, Huang Rui,
Jiri Slaby, Jonathan Corbet, Michael S . Tsirkin, Paul Gortmaker,
Ravi V . Shankar, Vlastimil Babka, Shuah Khan
In-Reply-To: <alpine.DEB.2.20.1611081750360.3501@nanos>
On Tue, 2016-11-08 at 17:52 +0100, Thomas Gleixner wrote:
> On Tue, 8 Nov 2016, Andy Lutomirski wrote:
> > On Tue, Nov 8, 2016 at 5:16 AM, Peter Zijlstra <peterz@infradead.org> wrote:
> > > On Mon, Nov 07, 2016 at 10:12:09PM -0800, Ricardo Neri wrote:
> > >> There is a caveat, however. Certain applications running in virtual-8086
> > >> mode, such as DOSEMU[1] and Wine[2], want to utilize the SGDT, SIDT and
> > >> SLDT instructions for legitimate reasons. In order to keep such
> > >> applications working, UMIP must be disabled/enabled when entering/exiting
> > >> virtual-8086 mode.
> > >
> > > Would it not be better to emulate these instructions for them? What way
> > > we can verify they're not malicious.
> >
> > Forget malice -- if they are really needed for some silly vm86-using
> > program, let's trap them and emulate them so they return dummy values.
>
> handle_vm86_fault() already does instruction emulation, so adding the few
> bits there is the right thing to do. Then we just can enable UMIP
> unconditionally and be done with it.
Ah. I didn't think about that. It make sense to me. I will rework this
series with this approach.
>
> Thanks,
>
> tglx
^ permalink raw reply
* RE: [PATCH 1/2] gpio: xilinx: dt-binding: Add clock node
From: Shubhrajyoti Datta @ 2016-11-09 4:25 UTC (permalink / raw)
To: Soren Brinkmann
Cc: linux-gpio@vger.kernel.org, devicetree@vger.kernel.org,
michal.simek@xilinx.com
In-Reply-To: <20161108144846.GQ14444@xsjsorenbubuntu>
Hi Soren,
> -----Original Message-----
> From: Sören Brinkmann [mailto:soren.brinkmann@xilinx.com]
> Sent: Tuesday, November 08, 2016 8:19 PM
<snip>
> > +- clock-names: Input clock name
>
> Clock names are driver specific and must be documented here.
Will do thanks.
>
> >
> >
> > Example:
> > gpio: gpio@40000000 {
> > #gpio-cells = <2>;
> > compatible = "xlnx,xps-gpio-1.00.a";
> > + clocks = <&clkc 15>;
>
> Where are the clock-names?
Will add.
>
> Sören
^ permalink raw reply
* Re: [PATCH 2/4] x86: Prepare vm86 tasks to handle User-Mode Instruction Prevention
From: Ricardo Neri @ 2016-11-09 4:26 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Andy Lutomirski, Ingo Molnar, Thomas Gleixner, H. Peter Anvin,
linux-kernel@vger.kernel.org, X86 ML, linux-doc@vger.kernel.org,
Andy Lutomirski, Andrew Morton, Borislav Petkov, Brian Gerst,
Chen Yucong, Chris Metcalf, Dave Hansen, Fenghua Yu, Huang Rui,
Jiri Slaby, Jonathan Corbet, Michael S . Tsirkin, Paul Gortmaker,
Ravi V . Shankar, Shuah Khan, Vlastimil Babka
In-Reply-To: <20161108170034.GK3117@twins.programming.kicks-ass.net>
On Tue, 2016-11-08 at 18:00 +0100, Peter Zijlstra wrote:
> > > + }
> > > +#endif
> > > +
> >
> > NAK. If this code is going to exist, it needs to be deeply buried
> in
> > some unlikely if statement that already exists. There's no good
> > reason to penalize all context switches to support some nonsensical
> > vm86 use case.
>
> Agreed, now if instead vm86 get to emulate these instructions, this
> all
> magically goes away..
Yes. I agree. I will rework the series and this should not be needed.
Thanks and BR,
Ricardo
^ permalink raw reply
* [PATCH v1 03/11] drivers: soc: hisi: Add support for Hisilicon Djtag driver
From: Anurup M @ 2016-11-09 4:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4657586.c5MJoh65Ux@wuerfel>
On Tuesday 08 November 2016 08:38 PM, Arnd Bergmann wrote:
> On Tuesday, November 8, 2016 7:16:30 PM CET Anurup M wrote:
>>>>>> If these are backwards compatible, just mark them as compatible in DT,
>>>>>> e.g. hip06 can use
>>>>>>
>>>>>> compatible = "hisilicon,hip06-cpu-djtag-v1", "hisilicon,hip05-cpu-djtag-v1";
>>>>>>
>>>>>> so you can tell the difference if you need to, but the driver only has to
>>>>>> list the oldest one here.
>>>>>>
>>>>>> What is the difference between the cpu and io djtag interfaces?
>>>> On some chips like hip06, the djtag version is different for IO die.
>>> In what way? The driver doesn't seem to care about the difference.
>> There is a difference in djtag version of CPU and IO die (in some chips).
>> For ex: in hip06 djtag for CPU is v1 and for IO is v2.
>> so they use different readwrite handlers djtag_readwrite_(v1/2).
>>
>> + /* for hip06(D03) cpu die */
>> + { .compatible = "hisilicon,hip06-cpu-djtag-v1",
>> + .data = (void *)djtag_readwrite_v1 },
>> + /* for hip06(D03) io die */
>> + { .compatible = "hisilicon,hip06-io-djtag-v2",
>> + .data = (void *)djtag_readwrite_v2 },
>>
>>
>> For the same djtag version, there is no difference in handling in the
>> driver.
> Right, but my point was about the compatibility with the older chips
> using the same IP block, marking the ones as compatible that actually
> use the same interface.
>
> I also see that the compatible strings have the version included in
> them, and you can probably drop them by requiring them only in the
> fallback:
>
> compatible = "hisilicon,hip05-cpu-djtag", "hisilicon,djtag-v1";
> compatible = "hisilicon,hip05-io-djtag", "hisilicon,djtag-v1";
> compatible = "hisilicon,hip06-cpu-djtag", "hisilicon,djtag-v1";
> compatible = "hisilicon,hip06-io-djtag", "hisilicon,djtag-v2";
> compatible = "hisilicon,hip07-cpu-djtag", "hisilicon,djtag-v2";
> compatible = "hisilicon,hip07-io-djtag", "hisilicon,djtag-v2";
>
> We want to have the first entry be as specific as possible, but
> the last (second) entry is the one that can be used by the driver
> for matching. When a future hip08/hip09/... chip uses an existing
> interface, you then don't have to update the driver.
Thanks. I had a similar thought on this. So as I have the version string
in the
second entry "-v(1/2)".
I can use it in driver for matching. So i think I will change it as below.
Please correct me if my understanding is wrong.
static const struct of_device_id djtag_of_match[] = {
- /* for hip05(D02) cpu die */
- { .compatible = "hisilicon,hip05-cpu-djtag-v1",
+ /* for hisi djtag-v1 cpu die */
+ { .compatible = "hisilicon,hisi-cpu-djtag-v1",
.data = djtag_readwrite_v1 },
- /* for hip05(D02) io die */
- { .compatible = "hisilicon,hip05-io-djtag-v1",
+ /* for hisi djtag-v1 io die */
+ { .compatible = "hisilicon,hisi-io-djtag-v1",
.data = djtag_readwrite_v1 },
- /* for hip06(D03) cpu die */
- { .compatible = "hisilicon,hip06-cpu-djtag-v1",
- .data = djtag_readwrite_v1 },
- /* for hip06(D03) io die */
- { .compatible = "hisilicon,hip06-io-djtag-v2",
- .data = djtag_readwrite_v2 },
- /* for hip07(D05) cpu die */
- { .compatible = "hisilicon,hip07-cpu-djtag-v2",
+ /* for hisi djtag-v2 cpu die */
+ { .compatible = "hisilicon,hisi-cpu-djtag-v2",
.data = djtag_readwrite_v2 },
- /* for hip07(D05) io die */
- { .compatible = "hisilicon,hip07-io-djtag-v2",
+ /* for hisi djtag-v2 io die */
+ { .compatible = "hisilicon,hisi-io-djtag-v2",
.data = (djtag_readwrite_v2 },
{},
};
Thanks,
Anurup
> Arnd
^ permalink raw reply
* Re: [PATCH v1 03/11] drivers: soc: hisi: Add support for Hisilicon Djtag driver
From: Anurup M @ 2016-11-09 4:28 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel, Tan Xiaojun, anurup.m, linux-kernel,
mark.rutland, shyju.pv, gabriele.paoloni, john.garry, will.deacon,
linuxarm, xuwei5, zhangshaokun, sanil.kumar, shiju.jose
In-Reply-To: <4657586.c5MJoh65Ux@wuerfel>
On Tuesday 08 November 2016 08:38 PM, Arnd Bergmann wrote:
> On Tuesday, November 8, 2016 7:16:30 PM CET Anurup M wrote:
>>>>>> If these are backwards compatible, just mark them as compatible in DT,
>>>>>> e.g. hip06 can use
>>>>>>
>>>>>> compatible = "hisilicon,hip06-cpu-djtag-v1", "hisilicon,hip05-cpu-djtag-v1";
>>>>>>
>>>>>> so you can tell the difference if you need to, but the driver only has to
>>>>>> list the oldest one here.
>>>>>>
>>>>>> What is the difference between the cpu and io djtag interfaces?
>>>> On some chips like hip06, the djtag version is different for IO die.
>>> In what way? The driver doesn't seem to care about the difference.
>> There is a difference in djtag version of CPU and IO die (in some chips).
>> For ex: in hip06 djtag for CPU is v1 and for IO is v2.
>> so they use different readwrite handlers djtag_readwrite_(v1/2).
>>
>> + /* for hip06(D03) cpu die */
>> + { .compatible = "hisilicon,hip06-cpu-djtag-v1",
>> + .data = (void *)djtag_readwrite_v1 },
>> + /* for hip06(D03) io die */
>> + { .compatible = "hisilicon,hip06-io-djtag-v2",
>> + .data = (void *)djtag_readwrite_v2 },
>>
>>
>> For the same djtag version, there is no difference in handling in the
>> driver.
> Right, but my point was about the compatibility with the older chips
> using the same IP block, marking the ones as compatible that actually
> use the same interface.
>
> I also see that the compatible strings have the version included in
> them, and you can probably drop them by requiring them only in the
> fallback:
>
> compatible = "hisilicon,hip05-cpu-djtag", "hisilicon,djtag-v1";
> compatible = "hisilicon,hip05-io-djtag", "hisilicon,djtag-v1";
> compatible = "hisilicon,hip06-cpu-djtag", "hisilicon,djtag-v1";
> compatible = "hisilicon,hip06-io-djtag", "hisilicon,djtag-v2";
> compatible = "hisilicon,hip07-cpu-djtag", "hisilicon,djtag-v2";
> compatible = "hisilicon,hip07-io-djtag", "hisilicon,djtag-v2";
>
> We want to have the first entry be as specific as possible, but
> the last (second) entry is the one that can be used by the driver
> for matching. When a future hip08/hip09/... chip uses an existing
> interface, you then don't have to update the driver.
Thanks. I had a similar thought on this. So as I have the version string
in the
second entry "-v(1/2)".
I can use it in driver for matching. So i think I will change it as below.
Please correct me if my understanding is wrong.
static const struct of_device_id djtag_of_match[] = {
- /* for hip05(D02) cpu die */
- { .compatible = "hisilicon,hip05-cpu-djtag-v1",
+ /* for hisi djtag-v1 cpu die */
+ { .compatible = "hisilicon,hisi-cpu-djtag-v1",
.data = djtag_readwrite_v1 },
- /* for hip05(D02) io die */
- { .compatible = "hisilicon,hip05-io-djtag-v1",
+ /* for hisi djtag-v1 io die */
+ { .compatible = "hisilicon,hisi-io-djtag-v1",
.data = djtag_readwrite_v1 },
- /* for hip06(D03) cpu die */
- { .compatible = "hisilicon,hip06-cpu-djtag-v1",
- .data = djtag_readwrite_v1 },
- /* for hip06(D03) io die */
- { .compatible = "hisilicon,hip06-io-djtag-v2",
- .data = djtag_readwrite_v2 },
- /* for hip07(D05) cpu die */
- { .compatible = "hisilicon,hip07-cpu-djtag-v2",
+ /* for hisi djtag-v2 cpu die */
+ { .compatible = "hisilicon,hisi-cpu-djtag-v2",
.data = djtag_readwrite_v2 },
- /* for hip07(D05) io die */
- { .compatible = "hisilicon,hip07-io-djtag-v2",
+ /* for hisi djtag-v2 io die */
+ { .compatible = "hisilicon,hisi-io-djtag-v2",
.data = (djtag_readwrite_v2 },
{},
};
Thanks,
Anurup
> Arnd
^ permalink raw reply
* [Buildroot] [PATCH 1/1] sdl: fix building on powerpc64 and powerpc64le
From: Sam Bobroff @ 2016-11-09 4:30 UTC (permalink / raw)
To: buildroot
In-Reply-To: <99a8adb3-3fa3-7050-e31f-16d2ee67ea12@mind.be>
On Tue, Nov 08, 2016 at 01:24:04PM +0100, Arnout Vandecappelle wrote:
>
>
> On 08-11-16 06:10, Sam Bobroff wrote:
> > On Tue, Nov 08, 2016 at 02:04:31AM +0100, Arnout Vandecappelle wrote:
> >>
> >>
> >> On 07-11-16 22:51, Thomas Petazzoni wrote:
> >>> Also, are we going to need to patch libtool.m4 in each and every
> >>> package around? libtool.m4 from sdl is from libtool 2.2 which is not
> >>> _that_ old (by the standards of libtool upgrade speed, of course), so
> >>> we're likely to find many other packages in the same situation, aren't
> >>> we?
> >
> > From the libtool git history it looks like the issue is fixed after
> > libtool 2.4.2.418.
> >
> >> Let me rephrase this.
> >>
> >> You should actually update support/libtool/buildroot-libtool-v1.5.patch and
> >> support/libtool/buildroot-libtool-v2.2.patch which will fix all packages in one
> >> fell swoop. (That is, assuming that v2.4 is OK already.)
> >
> > That sounds great, but that system seems to be set up to patch only
> > ltmain.sh, and the code that needs patching isn't there.
> >
> > The change needs to be in aclocal/libtool.m4
>
> Arg, my bad. I didn't look at the patch itself :-)
>
> > but I can't patch that and
> > then propagate the change to configure, because AUTORECONF doesn't work
> > for that package. (Maybe it would work for other packages, but I suspect
> > there would be problems updating a single file on it's own.)
>
> For most packages, AUTORECONF works. But it's really not nice to have to
> autoreconf a large number of packages just because one platform which many
> people don't use is not supported...
Agreed.
> > I suppose I could try auto-patching configure and/or configure.in (or
> > .ac) along the same lines as ltmain.sh... what do you think?
>
> Autopatching configure.in/ac will not work because it's actually libtool.m4,
> right? You could autopatch that, but some packages will not bundly libtool.m4 I
> guess.
Yes, and I've discovered that if you patch libtool.m4, some packages
build systems detect that and launch their own re-autoconf, which
crashes.
It looks like any fix will have to be directly to configure after any
autoreconfig is finished :-(
> Autopatching configure is going to be very hard I expect, because the location
> and context of the hunk to be patched is probably very volatile. But if it does
> work, it's probably the way to go. You would also have to patch libtool.m4 if it
> exists, to keep things consistent. And you'd probably want to ignore errors from
> patch.
>
> Otherwise, I'm afraid I don't see how we can solve this in a generic way...
Right, but it seems that although the hunk moves around a lot it's content
is still a large static chunk that's easily found. Since patch is happy
to patch anywhere (if all the context matches), it looks like patch will
handle that OK. Of course it will always fail on configure scripts that
are already new enough or have already been fixed manually (and it looks
like some packages have done that). And I never like ignoring errors.
I can think of a few ways to implement this in buildroot:
(a) Patch pkg-autotools.mk to find any files named 'configure' and try
to patch them, ignoring failures.
(b) As above but only patch files that match a magic pattern that
indicates they need patching (there does happen to be such a pattern in
this case).
(c) As above but only patch packages that set a package configuration
variable (something like FOO_PATCH_CONFIGURE=YES).
For (b) and (c), I could hard-code it to run a single patch (from
support/libtool/... or support/configure?) or I could make it a bit more
generic.
For (b) we could have a pattern file and a patch file, applying the
patch if configure contains the pattern, or for (c) the variable could
contain the patch file name (relative to support/something/?). For
example, have FOO_PATCH_CONFIGURE=powerpc64.patch. I'm not
aware of any other need for this at the moment but it also seems nice to
keep the arch specific stuff somewhat separated out.
For (c) We (me) would need to tag every package that needed patching,
but that doesn't seem too bad if it's just one line. The package files
would also be a good record of which packages still need fixing.
How do those options sound? Any other suggestions?
Cheers,
Sam.
^ permalink raw reply
* Re: [PATCH 0/4] x86: enable User-Mode Instruction Prevention
From: Ricardo Neri @ 2016-11-09 4:31 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Peter Zijlstra, Ingo Molnar, Thomas Gleixner, H. Peter Anvin,
linux-kernel@vger.kernel.org, X86 ML, linux-doc@vger.kernel.org,
Andy Lutomirski, Andrew Morton, Borislav Petkov, Brian Gerst,
Chen Yucong, Chris Metcalf, Dave Hansen, Fenghua Yu, Huang Rui,
Jiri Slaby, Jonathan Corbet, Michael S . Tsirkin, Paul Gortmaker,
Ravi V . Shankar, Vlastimil Babka, Shuah Khan
In-Reply-To: <CALCETrV+c4Rw9zbB3=Jc2F6jtxib3prxNqMXgnUSyMc5QnU9fA@mail.gmail.com>
On Tue, 2016-11-08 at 07:34 -0800, Andy Lutomirski wrote:
> > Would it not be better to emulate these instructions for them? What
> way
> > we can verify they're not malicious.
>
> Forget malice -- if they are really needed for some silly vm86-using
> program, let's trap them and emulate them so they return dummy values.
>
> Also, keep in mind that vm86 is already effectively gated behind a
> sysctl for non-root. I think the default should be that, if root has
> enabled vm86, it should work.
Then should I keep UMIP enabled by default and still provide an option
to disable it via a kernel parameter?
Also, a third option, umip=novm86 would "disable" UMIP in vm86 tasks.
Under the new approach (of emulating the impacted instructions), this
option, a #GP fault would still be generated but the actual values of
GDT/LDT/IDT/MSW would be passed to user space. Does this make sense?
Thanks and BR,
Ricardo
^ permalink raw reply
* [PATCH 06/11] mtd: nand: denali: remove unused struct member totalblks, blksperchip
From: Masahiro Yamada @ 2016-11-09 4:35 UTC (permalink / raw)
To: linux-mtd
Cc: Alan Cox, David Woodhouse, Jason Roberts, Chuanxiao Dong,
Dinh Nguyen, Masahiro Yamada, linux-kernel, Boris Brezillon,
Marek Vasut, Brian Norris, Richard Weinberger, David Woodhouse,
Cyrille Pitchen
In-Reply-To: <1478666130-13413-1-git-send-email-yamada.masahiro@socionext.com>
The denali->blksperchip is set, but not referenced any more. The
denali->totalblks is used only for calculating denali->blksperchip.
Both of them are unneeded.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
drivers/mtd/nand/denali.c | 8 --------
drivers/mtd/nand/denali.h | 2 --
2 files changed, 10 deletions(-)
diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
index 78d795b..548278b 100644
--- a/drivers/mtd/nand/denali.c
+++ b/drivers/mtd/nand/denali.c
@@ -1573,14 +1573,6 @@ int denali_init(struct denali_nand_info *denali)
denali->nand.ecc.bytes *= denali->devnum;
denali->nand.ecc.strength *= denali->devnum;
- /*
- * Let driver know the total blocks number and how many blocks
- * contained by each nand chip. blksperchip will help driver to
- * know how many blocks is taken by FW.
- */
- denali->totalblks = mtd->size >> denali->nand.phys_erase_shift;
- denali->blksperchip = denali->totalblks / denali->nand.numchips;
-
/* override the default read operations */
denali->nand.ecc.size = ECC_SECTOR_SIZE * denali->devnum;
denali->nand.ecc.read_page = denali_read_page;
diff --git a/drivers/mtd/nand/denali.h b/drivers/mtd/nand/denali.h
index 7c0800d..ea22191 100644
--- a/drivers/mtd/nand/denali.h
+++ b/drivers/mtd/nand/denali.h
@@ -462,8 +462,6 @@ struct denali_nand_info {
int irq;
uint32_t devnum; /* represent how many nands connected */
- uint32_t totalblks;
- uint32_t blksperchip;
uint32_t bbtskipbytes;
uint32_t max_banks;
};
--
1.9.1
^ permalink raw reply related
* [PATCH 03/11] mtd: nand: denali: remove bogus comment about interrupt handler setup
From: Masahiro Yamada @ 2016-11-09 4:35 UTC (permalink / raw)
To: linux-mtd
Cc: Alan Cox, David Woodhouse, Jason Roberts, Chuanxiao Dong,
Dinh Nguyen, Masahiro Yamada, linux-kernel, Boris Brezillon,
Marek Vasut, Brian Norris, Richard Weinberger, David Woodhouse,
Cyrille Pitchen
In-Reply-To: <1478666130-13413-1-git-send-email-yamada.masahiro@socionext.com>
The interrupt handler is setup in denali_init(), not in
denali_drv_init(). This comment is false.
Such a comment adds no value, so just delete it instead of move.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
drivers/mtd/nand/denali.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
index 51ddb84..d6f1b29 100644
--- a/drivers/mtd/nand/denali.c
+++ b/drivers/mtd/nand/denali.c
@@ -1436,7 +1436,6 @@ static int denali_ooblayout_free(struct mtd_info *mtd, int section,
/* initialize driver data structures */
static void denali_drv_init(struct denali_nand_info *denali)
{
- /* setup interrupt handler */
/*
* the completion object will be used to notify
* the callee that the interrupt is done
--
1.9.1
^ permalink raw reply related
* [PATCH 08/11] mtd: nand: denali: return error code from devm_request_irq() on error
From: Masahiro Yamada @ 2016-11-09 4:35 UTC (permalink / raw)
To: linux-mtd
Cc: Alan Cox, David Woodhouse, Jason Roberts, Chuanxiao Dong,
Dinh Nguyen, Masahiro Yamada, linux-kernel, Boris Brezillon,
Marek Vasut, Brian Norris, Richard Weinberger, David Woodhouse,
Cyrille Pitchen
In-Reply-To: <1478666130-13413-1-git-send-email-yamada.masahiro@socionext.com>
The devm_request_irq() returns an appropriate error value when it
fails. Use it instead of the fixed -ENODEV.
While we are here, reword the comment to make it fit in a single
line, fixing the misspelling of "initialization".
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
drivers/mtd/nand/denali.c | 12 +++++-------
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
index 44e075a..f188a48 100644
--- a/drivers/mtd/nand/denali.c
+++ b/drivers/mtd/nand/denali.c
@@ -1451,14 +1451,12 @@ int denali_init(struct denali_nand_info *denali)
denali_hw_init(denali);
denali_drv_init(denali);
- /*
- * denali_isr register is done after all the hardware
- * initilization is finished
- */
- if (devm_request_irq(denali->dev, denali->irq, denali_isr, IRQF_SHARED,
- DENALI_NAND_NAME, denali)) {
+ /* request IRQ after all the hardware initialization is finished */
+ ret = devm_request_irq(denali->dev, denali->irq, denali_isr,
+ IRQF_SHARED, DENALI_NAND_NAME, denali);
+ if (ret) {
dev_err(denali->dev, "Unable to request IRQ\n");
- return -ENODEV;
+ return ret;
}
/* now that our ISR is registered, we can enable interrupts */
--
1.9.1
^ permalink raw reply related
* [PATCH 01/11] mtd: nand: denali: remove unneeded <linux/slab.h> includes
From: Masahiro Yamada @ 2016-11-09 4:35 UTC (permalink / raw)
To: linux-mtd
Cc: Alan Cox, David Woodhouse, Jason Roberts, Chuanxiao Dong,
Dinh Nguyen, Masahiro Yamada, linux-kernel, Boris Brezillon,
Marek Vasut, Brian Norris, Richard Weinberger, David Woodhouse,
Cyrille Pitchen
In-Reply-To: <1478666130-13413-1-git-send-email-yamada.masahiro@socionext.com>
The driver calls devm_kzalloc()/devm_kfree() to allocate/free memory.
They are declared in <linux/device.h>, not in <linux/slab.h>.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
drivers/mtd/nand/denali.c | 1 -
drivers/mtd/nand/denali_dt.c | 1 -
drivers/mtd/nand/denali_pci.c | 1 -
3 files changed, 3 deletions(-)
diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
index 7e2c650..062d5b5 100644
--- a/drivers/mtd/nand/denali.c
+++ b/drivers/mtd/nand/denali.c
@@ -21,7 +21,6 @@
#include <linux/dma-mapping.h>
#include <linux/wait.h>
#include <linux/mutex.h>
-#include <linux/slab.h>
#include <linux/mtd/mtd.h>
#include <linux/module.h>
diff --git a/drivers/mtd/nand/denali_dt.c b/drivers/mtd/nand/denali_dt.c
index f821dc1..5607fcd 100644
--- a/drivers/mtd/nand/denali_dt.c
+++ b/drivers/mtd/nand/denali_dt.c
@@ -21,7 +21,6 @@
#include <linux/platform_device.h>
#include <linux/of.h>
#include <linux/of_device.h>
-#include <linux/slab.h>
#include "denali.h"
diff --git a/drivers/mtd/nand/denali_pci.c b/drivers/mtd/nand/denali_pci.c
index de31514..ac84323 100644
--- a/drivers/mtd/nand/denali_pci.c
+++ b/drivers/mtd/nand/denali_pci.c
@@ -14,7 +14,6 @@
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/pci.h>
-#include <linux/slab.h>
#include "denali.h"
--
1.9.1
^ permalink raw reply related
* [PATCH 07/11] mtd: nand: denali: use managed devm_irq_request()
From: Masahiro Yamada @ 2016-11-09 4:35 UTC (permalink / raw)
To: linux-mtd
Cc: Alan Cox, David Woodhouse, Jason Roberts, Chuanxiao Dong,
Dinh Nguyen, Masahiro Yamada, linux-kernel, Boris Brezillon,
Marek Vasut, Brian Norris, Richard Weinberger, David Woodhouse,
Cyrille Pitchen
In-Reply-To: <1478666130-13413-1-git-send-email-yamada.masahiro@socionext.com>
Use the managed variant instead of request_irq() and free_irq().
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
drivers/mtd/nand/denali.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
index 548278b..44e075a 100644
--- a/drivers/mtd/nand/denali.c
+++ b/drivers/mtd/nand/denali.c
@@ -575,7 +575,6 @@ static void denali_irq_init(struct denali_nand_info *denali)
static void denali_irq_cleanup(int irqnum, struct denali_nand_info *denali)
{
denali_set_intr_modes(denali, false);
- free_irq(irqnum, denali);
}
static void denali_irq_enable(struct denali_nand_info *denali,
@@ -1456,8 +1455,8 @@ int denali_init(struct denali_nand_info *denali)
* denali_isr register is done after all the hardware
* initilization is finished
*/
- if (request_irq(denali->irq, denali_isr, IRQF_SHARED,
- DENALI_NAND_NAME, denali)) {
+ if (devm_request_irq(denali->dev, denali->irq, denali_isr, IRQF_SHARED,
+ DENALI_NAND_NAME, denali)) {
dev_err(denali->dev, "Unable to request IRQ\n");
return -ENODEV;
}
--
1.9.1
^ permalink raw reply related
* [PATCH 02/11] mtd: nand: denali: remove unused struct member denali_nand_info::idx
From: Masahiro Yamada @ 2016-11-09 4:35 UTC (permalink / raw)
To: linux-mtd
Cc: Alan Cox, David Woodhouse, Jason Roberts, Chuanxiao Dong,
Dinh Nguyen, Masahiro Yamada, linux-kernel, Boris Brezillon,
Marek Vasut, Brian Norris, Richard Weinberger, David Woodhouse,
Cyrille Pitchen
In-Reply-To: <1478666130-13413-1-git-send-email-yamada.masahiro@socionext.com>
The struct member "idx" was used as an index for debug_array long
ago, but the DEBUG_DENALI feature was removed by commit 7cfffac06ca0
("nand/denali: use dev_xx debug function to replace nand_dbg_print
and some printk"). Since then, this has been only initialized, but
never referenced.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
drivers/mtd/nand/denali.c | 2 --
drivers/mtd/nand/denali.h | 1 -
2 files changed, 3 deletions(-)
diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
index 062d5b5..51ddb84 100644
--- a/drivers/mtd/nand/denali.c
+++ b/drivers/mtd/nand/denali.c
@@ -1436,8 +1436,6 @@ static int denali_ooblayout_free(struct mtd_info *mtd, int section,
/* initialize driver data structures */
static void denali_drv_init(struct denali_nand_info *denali)
{
- denali->idx = 0;
-
/* setup interrupt handler */
/*
* the completion object will be used to notify
diff --git a/drivers/mtd/nand/denali.h b/drivers/mtd/nand/denali.h
index e7ab486..0ce7344 100644
--- a/drivers/mtd/nand/denali.h
+++ b/drivers/mtd/nand/denali.h
@@ -467,7 +467,6 @@ struct denali_nand_info {
spinlock_t irq_lock;
uint32_t irq_status;
int irq_debug_array[32];
- int idx;
int irq;
uint32_t devnum; /* represent how many nands connected */
--
1.9.1
^ permalink raw reply related
* [PATCH 04/11] mtd: nand: denali: remove detect_partition_feature()
From: Masahiro Yamada @ 2016-11-09 4:35 UTC (permalink / raw)
To: linux-mtd
Cc: Alan Cox, David Woodhouse, Jason Roberts, Chuanxiao Dong,
Dinh Nguyen, Masahiro Yamada, linux-kernel, Boris Brezillon,
Marek Vasut, Brian Norris, Richard Weinberger, David Woodhouse,
Cyrille Pitchen
In-Reply-To: <1478666130-13413-1-git-send-email-yamada.masahiro@socionext.com>
The denali->fwblks is set by detect_partition_feature(), but it is
not referenced from anywhere. That means the struct member fwblks
and the whole of detect_partition_feature() are unneeded.
The comment block implies this function is only for Intel platforms.
I found drivers/staging/spectra used to exist, but it was deleted by
commit be7f39c5ecf5 ("Staging: delete spectra driver") 5 years ago.
So, I guess nobody would need this function any more.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
drivers/mtd/nand/denali.c | 29 -----------------------------
drivers/mtd/nand/denali.h | 9 ---------
2 files changed, 38 deletions(-)
diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
index d6f1b29..80d3e26 100644
--- a/drivers/mtd/nand/denali.c
+++ b/drivers/mtd/nand/denali.c
@@ -473,33 +473,6 @@ static void detect_max_banks(struct denali_nand_info *denali)
denali->max_banks = 1 << (features & FEATURES__N_BANKS);
}
-static void detect_partition_feature(struct denali_nand_info *denali)
-{
- /*
- * For MRST platform, denali->fwblks represent the
- * number of blocks firmware is taken,
- * FW is in protect partition and MTD driver has no
- * permission to access it. So let driver know how many
- * blocks it can't touch.
- */
- if (ioread32(denali->flash_reg + FEATURES) & FEATURES__PARTITION) {
- if ((ioread32(denali->flash_reg + PERM_SRC_ID(1)) &
- PERM_SRC_ID__SRCID) == SPECTRA_PARTITION_ID) {
- denali->fwblks =
- ((ioread32(denali->flash_reg + MIN_MAX_BANK(1)) &
- MIN_MAX_BANK__MIN_VALUE) *
- denali->blksperchip)
- +
- (ioread32(denali->flash_reg + MIN_BLK_ADDR(1)) &
- MIN_BLK_ADDR__VALUE);
- } else {
- denali->fwblks = SPECTRA_START_BLOCK;
- }
- } else {
- denali->fwblks = SPECTRA_START_BLOCK;
- }
-}
-
static uint16_t denali_nand_timing_set(struct denali_nand_info *denali)
{
uint16_t status = PASS;
@@ -551,8 +524,6 @@ static uint16_t denali_nand_timing_set(struct denali_nand_info *denali)
find_valid_banks(denali);
- detect_partition_feature(denali);
-
/*
* If the user specified to override the default timings
* with a specific ONFI mode, we apply those changes here.
diff --git a/drivers/mtd/nand/denali.h b/drivers/mtd/nand/denali.h
index 0ce7344..7c0800d 100644
--- a/drivers/mtd/nand/denali.h
+++ b/drivers/mtd/nand/denali.h
@@ -383,14 +383,6 @@
#define CLK_X 5
#define CLK_MULTI 4
-/* spectraswconfig.h */
-#define CMD_DMA 0
-
-#define SPECTRA_PARTITION_ID 0
-/**** Block Table and Reserved Block Parameters *****/
-#define SPECTRA_START_BLOCK 3
-#define NUM_FREE_BLOCKS_GATE 30
-
/* KBV - Updated to LNW scratch register address */
#define SCRATCH_REG_ADDR CONFIG_MTD_NAND_DENALI_SCRATCH_REG_ADDR
#define SCRATCH_REG_SIZE 64
@@ -470,7 +462,6 @@ struct denali_nand_info {
int irq;
uint32_t devnum; /* represent how many nands connected */
- uint32_t fwblks; /* represent how many blocks FW used */
uint32_t totalblks;
uint32_t blksperchip;
uint32_t bbtskipbytes;
--
1.9.1
^ permalink raw reply related
* [PATCH 05/11] mtd: nand: denali: remove "Spectra:" prefix from printk strings
From: Masahiro Yamada @ 2016-11-09 4:35 UTC (permalink / raw)
To: linux-mtd
Cc: Alan Cox, David Woodhouse, Jason Roberts, Chuanxiao Dong,
Dinh Nguyen, Masahiro Yamada, linux-kernel, Boris Brezillon,
Marek Vasut, Brian Norris, Richard Weinberger, David Woodhouse,
Cyrille Pitchen
In-Reply-To: <1478666130-13413-1-git-send-email-yamada.masahiro@socionext.com>
As far as I understood from the Kconfig menu deleted by commit
be7f39c5ecf5 ("Staging: delete spectra driver"), the "Spectra" is
specific to Intel Moorestown Platform.
The Denali NAND controller IP is used for various SoCs such as
Altera SOCFPGA, Socionext UniPhier, etc. The platform specific
strings are not preferred in this driver.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
As an ARM-SoC developer, I only need denali.c and denali_dt.c.
I see some "Spectra:" in drivers/mtd/nand/denali_pci.c as well.
I was not quite sure if they are needed or not.
If desired, I can update this patch to remove them too.
drivers/mtd/nand/denali.c | 11 +++++------
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
index 80d3e26..78d795b 100644
--- a/drivers/mtd/nand/denali.c
+++ b/drivers/mtd/nand/denali.c
@@ -402,7 +402,7 @@ static void get_hynix_nand_para(struct denali_nand_info *denali,
break;
default:
dev_warn(denali->dev,
- "Spectra: Unknown Hynix NAND (Device ID: 0x%x).\n"
+ "Unknown Hynix NAND (Device ID: 0x%x).\n"
"Will use default parameter values instead.\n",
device_id);
}
@@ -1458,7 +1458,7 @@ int denali_init(struct denali_nand_info *denali)
*/
if (request_irq(denali->irq, denali_isr, IRQF_SHARED,
DENALI_NAND_NAME, denali)) {
- pr_err("Spectra: Unable to allocate IRQ\n");
+ dev_err(denali->dev, "Unable to request IRQ\n");
return -ENODEV;
}
@@ -1495,7 +1495,7 @@ int denali_init(struct denali_nand_info *denali)
/* Is 32-bit DMA supported? */
ret = dma_set_mask(denali->dev, DMA_BIT_MASK(32));
if (ret) {
- pr_err("Spectra: no usable DMA configuration\n");
+ dev_err(denali->dev, "no usable DMA configuration\n");
goto failed_req_irq;
}
@@ -1503,7 +1503,7 @@ int denali_init(struct denali_nand_info *denali)
mtd->writesize + mtd->oobsize,
DMA_BIDIRECTIONAL);
if (dma_mapping_error(denali->dev, denali->buf.dma_buf)) {
- dev_err(denali->dev, "Spectra: failed to map DMA buffer\n");
+ dev_err(denali->dev, "failed to map DMA buffer\n");
ret = -EIO;
goto failed_req_irq;
}
@@ -1598,8 +1598,7 @@ int denali_init(struct denali_nand_info *denali)
ret = mtd_device_register(mtd, NULL, 0);
if (ret) {
- dev_err(denali->dev, "Spectra: Failed to register MTD: %d\n",
- ret);
+ dev_err(denali->dev, "Failed to register MTD: %d\n", ret);
goto failed_req_irq;
}
return 0;
--
1.9.1
^ permalink raw reply related
* [PATCH 00/11] mtd: nand: denali: first round of cleanups of Denali NAND driver
From: Masahiro Yamada @ 2016-11-09 4:35 UTC (permalink / raw)
To: linux-mtd
Cc: Alan Cox, David Woodhouse, Jason Roberts, Chuanxiao Dong,
Dinh Nguyen, Masahiro Yamada, linux-kernel, Boris Brezillon,
Marek Vasut, Brian Norris, Richard Weinberger, David Woodhouse,
Cyrille Pitchen
I am tackling on this driver to use it for my SoCs.
The difficulty is a bunch of platform specific stuff
(more specifically, Intel MRST specific) is hard-coded in this driver.
I need lots of rework to utilize the driver for generic cases,
but at the same time, I found the driver code is really dirty,
lots of unused code, odd comments, etc.
The first thing I needed to do was to clean up the code.
My work is still under the way, but I decided to drop this series
for now. I hope this series is easy to review, so I guess
splitting into a small chunks is better than a one-shot patch bomb.
Masahiro Yamada (11):
mtd: nand: denali: remove unneeded <linux/slab.h> includes
mtd: nand: denali: remove unused struct member denali_nand_info::idx
mtd: nand: denali: remove bogus comment about interrupt handler setup
mtd: nand: denali: remove detect_partition_feature()
mtd: nand: denali: remove "Spectra:" prefix from printk strings
mtd: nand: denali: remove unused struct member totalblks, blksperchip
mtd: nand: denali: use managed devm_irq_request()
mtd: nand: denali: return error code from devm_request_irq() on error
mtd: nand: denali: return error code from nand_scan_ident/tail on
error
mtd: nand: denali: remove unneeded parentheses
mtd: nand: denali: remove debug lines of __FILE__, __LINE__, __func__
drivers/mtd/nand/denali.c | 101 +++++++++---------------------------------
drivers/mtd/nand/denali.h | 12 -----
drivers/mtd/nand/denali_dt.c | 1 -
drivers/mtd/nand/denali_pci.c | 1 -
4 files changed, 21 insertions(+), 94 deletions(-)
--
1.9.1
^ permalink raw reply
* [PATCH 11/11] mtd: nand: denali: remove debug lines of __FILE__, __LINE__, __func__
From: Masahiro Yamada @ 2016-11-09 4:35 UTC (permalink / raw)
To: linux-mtd
Cc: Alan Cox, David Woodhouse, Jason Roberts, Chuanxiao Dong,
Dinh Nguyen, Masahiro Yamada, linux-kernel, Boris Brezillon,
Marek Vasut, Brian Norris, Richard Weinberger, David Woodhouse,
Cyrille Pitchen
In-Reply-To: <1478666130-13413-1-git-send-email-yamada.masahiro@socionext.com>
Such debug lines might be useful when debugging the driver first,
but should be deleted from the upstream code.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
drivers/mtd/nand/denali.c | 12 ------------
1 file changed, 12 deletions(-)
diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
index 14e66ab..e32e13c 100644
--- a/drivers/mtd/nand/denali.c
+++ b/drivers/mtd/nand/denali.c
@@ -181,9 +181,6 @@ static uint16_t denali_nand_reset(struct denali_nand_info *denali)
{
int i;
- dev_dbg(denali->dev, "%s, Line %d, Function: %s\n",
- __FILE__, __LINE__, __func__);
-
for (i = 0; i < denali->max_banks; i++)
iowrite32(INTR_STATUS__RST_COMP | INTR_STATUS__TIME_OUT,
denali->flash_reg + INTR_STATUS(i));
@@ -233,9 +230,6 @@ static void nand_onfi_timing_set(struct denali_nand_info *denali,
uint16_t acc_clks;
uint16_t addr_2_data, re_2_we, re_2_re, we_2_re, cs_cnt;
- dev_dbg(denali->dev, "%s, Line %d, Function: %s\n",
- __FILE__, __LINE__, __func__);
-
en_lo = CEIL_DIV(Trp[mode], CLK_X);
en_hi = CEIL_DIV(Treh[mode], CLK_X);
#if ONFI_BLOOM_TIME
@@ -480,9 +474,6 @@ static uint16_t denali_nand_timing_set(struct denali_nand_info *denali)
uint8_t maf_id, device_id;
int i;
- dev_dbg(denali->dev, "%s, Line %d, Function: %s\n",
- __FILE__, __LINE__, __func__);
-
/*
* Use read id method to get device ID and other params.
* For some NAND chips, controller can't report the correct
@@ -537,9 +528,6 @@ static uint16_t denali_nand_timing_set(struct denali_nand_info *denali)
static void denali_set_intr_modes(struct denali_nand_info *denali,
uint16_t INT_ENABLE)
{
- dev_dbg(denali->dev, "%s, Line %d, Function: %s\n",
- __FILE__, __LINE__, __func__);
-
if (INT_ENABLE)
iowrite32(1, denali->flash_reg + GLOBAL_INT_ENABLE);
else
--
1.9.1
^ permalink raw reply related
* [PATCH 10/11] mtd: nand: denali: remove unneeded parentheses
From: Masahiro Yamada @ 2016-11-09 4:35 UTC (permalink / raw)
To: linux-mtd
Cc: Alan Cox, David Woodhouse, Jason Roberts, Chuanxiao Dong,
Dinh Nguyen, Masahiro Yamada, linux-kernel, Boris Brezillon,
Marek Vasut, Brian Norris, Richard Weinberger, David Woodhouse,
Cyrille Pitchen
In-Reply-To: <1478666130-13413-1-git-send-email-yamada.masahiro@socionext.com>
Remove parentheses surrounding the whole right side of an assignment.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
drivers/mtd/nand/denali.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
index d482d8d..14e66ab 100644
--- a/drivers/mtd/nand/denali.c
+++ b/drivers/mtd/nand/denali.c
@@ -1510,16 +1510,16 @@ int denali_init(struct denali_nand_info *denali)
* the real pagesize and anything necessery
*/
denali->devnum = ioread32(denali->flash_reg + DEVICES_CONNECTED);
- denali->nand.chipsize <<= (denali->devnum - 1);
- denali->nand.page_shift += (denali->devnum - 1);
+ denali->nand.chipsize <<= denali->devnum - 1;
+ denali->nand.page_shift += denali->devnum - 1;
denali->nand.pagemask = (denali->nand.chipsize >>
denali->nand.page_shift) - 1;
- denali->nand.bbt_erase_shift += (denali->devnum - 1);
+ denali->nand.bbt_erase_shift += denali->devnum - 1;
denali->nand.phys_erase_shift = denali->nand.bbt_erase_shift;
- denali->nand.chip_shift += (denali->devnum - 1);
- mtd->writesize <<= (denali->devnum - 1);
- mtd->oobsize <<= (denali->devnum - 1);
- mtd->erasesize <<= (denali->devnum - 1);
+ denali->nand.chip_shift += denali->devnum - 1;
+ mtd->writesize <<= denali->devnum - 1;
+ mtd->oobsize <<= denali->devnum - 1;
+ mtd->erasesize <<= denali->devnum - 1;
mtd->size = denali->nand.numchips * denali->nand.chipsize;
denali->bbtskipbytes *= denali->devnum;
--
1.9.1
^ permalink raw reply related
* [PATCH 09/11] mtd: nand: denali: return error code from nand_scan_ident/tail on error
From: Masahiro Yamada @ 2016-11-09 4:35 UTC (permalink / raw)
To: linux-mtd
Cc: Alan Cox, David Woodhouse, Jason Roberts, Chuanxiao Dong,
Dinh Nguyen, Masahiro Yamada, linux-kernel, Boris Brezillon,
Marek Vasut, Brian Norris, Richard Weinberger, David Woodhouse,
Cyrille Pitchen
In-Reply-To: <1478666130-13413-1-git-send-email-yamada.masahiro@socionext.com>
The nand_scan_ident/tail() returns an appropriate error value when
it fails. Use it instead of the fixed -ENXIO.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
drivers/mtd/nand/denali.c | 10 ++++------
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
index f188a48..d482d8d 100644
--- a/drivers/mtd/nand/denali.c
+++ b/drivers/mtd/nand/denali.c
@@ -1474,10 +1474,9 @@ int denali_init(struct denali_nand_info *denali)
* this is the first stage in a two step process to register
* with the nand subsystem
*/
- if (nand_scan_ident(mtd, denali->max_banks, NULL)) {
- ret = -ENXIO;
+ ret = nand_scan_ident(mtd, denali->max_banks, NULL);
+ if (ret)
goto failed_req_irq;
- }
/* allocate the right size buffer now */
devm_kfree(denali->dev, denali->buf.buf);
@@ -1580,10 +1579,9 @@ int denali_init(struct denali_nand_info *denali)
denali->nand.ecc.write_oob = denali_write_oob;
denali->nand.erase = denali_erase;
- if (nand_scan_tail(mtd)) {
- ret = -ENXIO;
+ ret = nand_scan_tail(mtd);
+ if (ret)
goto failed_req_irq;
- }
ret = mtd_device_register(mtd, NULL, 0);
if (ret) {
--
1.9.1
^ permalink raw reply related
* [PATCH] kbuild: be more careful about matching preprocessed asm ___EXPORT_SYMBOL
From: Nicholas Piggin @ 2016-11-09 4:34 UTC (permalink / raw)
To: Michal Marek
Cc: Nicholas Piggin, Philip Müller, Adam Borowski, linux-kbuild
The CRC code for asm exports grabs the preprocessed asm, finds the
___EXPORT_SYMBOL and turns those into EXPORT_SYMBOL in a C program
that can be preprocessed and parsed to create the CRC signatures from
the type.
The existing regex matching and replacement is too strict, and doesn't
deal well with whitespace among other things. The line
" EXPORT_SYMBOL(sym)" in a .S file would not match due to initial
whitespace, for example, which resulted in x86's ___preempt_schedule
failing to get CRCs.
Reported-by: Philip Müller <philm@manjaro.org>
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
scripts/Makefile.build | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/scripts/Makefile.build b/scripts/Makefile.build
index 3e223c2..7675d11 100644
--- a/scripts/Makefile.build
+++ b/scripts/Makefile.build
@@ -332,8 +332,8 @@ cmd_gensymtypes_S = \
(echo "\#include <linux/kernel.h>" ; \
echo "\#include <asm/asm-prototypes.h>" ; \
$(CPP) $(a_flags) $< | \
- grep ^___EXPORT_SYMBOL | \
- sed 's/___EXPORT_SYMBOL \([a-zA-Z0-9_]*\),.*/EXPORT_SYMBOL(\1);/' ) | \
+ grep "\<___EXPORT_SYMBOL\>" | \
+ sed 's/.*___EXPORT_SYMBOL[[:space:]]*\([a-zA-Z0-9_]*\)[[:space:]]*,.*/EXPORT_SYMBOL(\1);/' ) | \
$(CPP) -D__GENKSYMS__ $(c_flags) -xc - | \
$(GENKSYMS) $(if $(1), -T $(2)) \
$(patsubst y,-s _,$(CONFIG_HAVE_UNDERSCORE_SYMBOL_PREFIX)) \
--
2.10.2
^ permalink raw reply related
* Re: support for partial irq affinity assignment V3
From: Jens Axboe @ 2016-11-09 4:38 UTC (permalink / raw)
To: Christoph Hellwig, tglx; +Cc: linux-block, linux-pci, linux-kernel
In-Reply-To: <1478654107-7384-1-git-send-email-hch@lst.de>
On 11/08/2016 06:15 PM, Christoph Hellwig wrote:
> This series adds support for automatic interrupt assignment to devices
> that have a few vectors that are set aside for admin or config purposes
> and thus should not fall into the general per-cpu assginment pool.
>
> The first patch adds that support to the core IRQ and PCI/msi code,
> and the second is a small tweak to a block layer helper to make use
> of it. I'd love to have both go into the same tree so that consumers
> of this (e.g. the virtio, scsi and rdma trees) only need to pull in
> one of these trees as dependency.
Series looks good to me, you can add my Acked-by to all of them.
--
Jens Axboe
^ permalink raw reply
* cron job: media_tree daily build: ERRORS
From: Hans Verkuil @ 2016-11-09 4:40 UTC (permalink / raw)
To: linux-media
This message is generated daily by a cron job that builds media_tree for
the kernels and architectures in the list below.
Results of the daily build of media_tree:
date: Wed Nov 9 05:00:18 CET 2016
media-tree git hash: bd676c0c04ec94bd830b9192e2c33f2c4532278d
media_build git hash: dac8db4dd7fa3cc87715cb19ace554e080690b39
v4l-utils git hash: 788b674f3827607c09c31be11c91638f816aa6ae
gcc version: i686-linux-gcc (GCC) 6.2.0
sparse version: v0.5.0-3553-g78b2ea6
smatch version: v0.5.0-3553-g78b2ea6
host hardware: x86_64
host os: 4.7.0-164
linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-multi: OK
linux-git-arm-pxa: OK
linux-git-blackfin-bf561: OK
linux-git-i686: OK
linux-git-m32r: OK
linux-git-mips: OK
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: OK
linux-2.6.36.4-i686: ERRORS
linux-2.6.37.6-i686: ERRORS
linux-2.6.38.8-i686: ERRORS
linux-2.6.39.4-i686: ERRORS
linux-3.0.60-i686: ERRORS
linux-3.1.10-i686: ERRORS
linux-3.2.37-i686: ERRORS
linux-3.3.8-i686: ERRORS
linux-3.4.27-i686: ERRORS
linux-3.5.7-i686: ERRORS
linux-3.6.11-i686: ERRORS
linux-3.7.4-i686: ERRORS
linux-3.8-i686: ERRORS
linux-3.9.2-i686: ERRORS
linux-3.10.1-i686: ERRORS
linux-3.11.1-i686: ERRORS
linux-3.13.11-i686: ERRORS
linux-3.14.9-i686: ERRORS
linux-3.15.2-i686: ERRORS
linux-3.16.7-i686: ERRORS
linux-3.17.8-i686: ERRORS
linux-3.18.7-i686: ERRORS
linux-3.19-i686: ERRORS
linux-4.0.9-i686: ERRORS
linux-4.1.33-i686: ERRORS
linux-4.2.8-i686: ERRORS
linux-4.3.6-i686: WARNINGS
linux-4.4.22-i686: WARNINGS
linux-4.5.7-i686: WARNINGS
linux-4.6.7-i686: WARNINGS
linux-4.7.5-i686: WARNINGS
linux-4.8-i686: WARNINGS
linux-4.9-rc1-i686: WARNINGS
linux-2.6.36.4-x86_64: ERRORS
linux-2.6.37.6-x86_64: ERRORS
linux-2.6.38.8-x86_64: ERRORS
linux-2.6.39.4-x86_64: ERRORS
linux-3.0.60-x86_64: ERRORS
linux-3.1.10-x86_64: ERRORS
linux-3.2.37-x86_64: ERRORS
linux-3.3.8-x86_64: ERRORS
linux-3.4.27-x86_64: ERRORS
linux-3.5.7-x86_64: ERRORS
linux-3.6.11-x86_64: ERRORS
linux-3.7.4-x86_64: ERRORS
linux-3.8-x86_64: ERRORS
linux-3.9.2-x86_64: ERRORS
linux-3.10.1-x86_64: ERRORS
linux-3.11.1-x86_64: ERRORS
linux-3.13.11-x86_64: ERRORS
linux-3.14.9-x86_64: ERRORS
linux-3.15.2-x86_64: ERRORS
linux-3.16.7-x86_64: ERRORS
linux-3.17.8-x86_64: ERRORS
linux-3.18.7-x86_64: ERRORS
linux-3.19-x86_64: ERRORS
linux-4.0.9-x86_64: ERRORS
linux-4.1.33-x86_64: ERRORS
linux-4.2.8-x86_64: ERRORS
linux-4.3.6-x86_64: WARNINGS
linux-4.4.22-x86_64: WARNINGS
linux-4.5.7-x86_64: WARNINGS
linux-4.6.7-x86_64: WARNINGS
linux-4.7.5-x86_64: WARNINGS
linux-4.8-x86_64: WARNINGS
linux-4.9-rc1-x86_64: WARNINGS
apps: WARNINGS
spec-git: OK
smatch: ERRORS
sparse: WARNINGS
Detailed results are available here:
http://www.xs4all.nl/~hverkuil/logs/Wednesday.log
Full logs are available here:
http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2
The Media Infrastructure API from this daily build is here:
http://www.xs4all.nl/~hverkuil/spec/index.html
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.