Am 24.01.2015 um 12:37 schrieb Alexander Holler:
Am 24.01.2015 um 11:45 schrieb Alexander Holler:
It uses shred, in the hope it will somedays learn how to shred stuff on
FLASH based devices securely too, once that has become possible.
BTW: This is a good example where technology failed to
Am 24.01.2015 um 11:45 schrieb Alexander Holler:
It uses shred, in the hope it will somedays learn how to shred stuff on
FLASH based devices securely too, once that has become possible.
BTW: This is a good example where technology failed to keep the needs of
users in mind.
It should be
This is for the more paranoid people, also it's
questionable what paranoid nowadays means.
It uses shred, in the hope it will somedays learn how to shred stuff on
FLASH based devices securely too, once that has become possible.
Signed-off-by: Alexander Holler
---
Makefile | 2 +-
1
Am 24.01.2015 um 00:58 schrieb David Howells:
> Alexander Holler wrote:
>
>> This is for the more paranoid people, also it's
>> questionable what paranoid nowadays means.
>
> shred?
Seems to do the same like when using dd, just that it does it moultiple
times.
And
Am 23.01.2015 um 23:06 schrieb Richard Weinberger:
> On Fri, Jan 23, 2015 at 10:57 PM, Alexander Holler
> wrote:
>> This is for the more paranoid people, also it's
>> questionable what paranoid nowadays means.
>
> Isn't this complete useless when modern f
This is for the more paranoid people, also it's
questionable what paranoid nowadays means.
Signed-off-by: Alexander Holler
---
Makefile | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Makefile b/Makefile
index 7ad66de..590ff53 100644
--- a/Makefile
+++ b/Makefile
@@ -1132,7 +1
Am 23.01.2015 um 13:34 schrieb Alexander Holler:
4. With some scripting it should be possible to extract the public key
out of an existing binary kernel. So there is no real need to change the
already complicated build process which might make it even more
complicated.
BTW: With "
Sorry, either I type too fast or I think too slow, so here is another
comment:
Am 23.01.2015 um 14:27 schrieb Alexander Holler:
Am 23.01.2015 um 13:56 schrieb David Howells:
One thing that you have to be careful of with your patch is that if
you turn
it on during development, this will drain
me (as my kernel build directories (and
thus the private keys) are usually residing on the machine the kernel is
deployed afterwards).
Regards,
Alexander Holler
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kerne
Am 23.01.2015 um 12:54 schrieb Alexander Holler:
Am 23.01.2015 um 12:43 schrieb Alexander Holler:
Am 23.01.2015 um 11:55 schrieb Michal Marek:
The .x509 file contains a certificate signed by the private key, but not
the private key. With some scripting, it can be used to verify the
module
Am 23.01.2015 um 12:43 schrieb Alexander Holler:
Am 23.01.2015 um 11:55 schrieb Michal Marek:
The .x509 file contains a certificate signed by the private key, but not
the private key. With some scripting, it can be used to verify the
module signatures.
Assuming that doesn't c
Am 23.01.2015 um 11:55 schrieb Michal Marek:
On 2015-01-23 11:15, Alexander Holler wrote:
Am 23.01.2015 um 10:39 schrieb Alexander Holler:
Am 23.01.2015 um 10:24 schrieb Michal Marek:
+ @rm ./signing_key.priv
+ @rm ./signing_key.x509
Why do you need to delete the certificate
Am 23.01.2015 um 10:39 schrieb Alexander Holler:
Am 23.01.2015 um 10:24 schrieb Michal Marek:
+ @rm ./signing_key.priv
+ @rm ./signing_key.x509
Why do you need to delete the certificate?
No special reason.
I'm just not sure (and too lazy to look it up) if it might contai
#x27;s possible in pem files), so I've deleted it too.
Regards,
Alexander Holler
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
rm -fr pkg/ kills /usr/, etc.
>>>
>>
>>> I'm puzzled. any thoughts?
>>
>> Try to bisect, perhaps?
>>
There are some weird pieces in the kernel buildsysten which are
generating Makefile content based on some filenames and might brake or
confuse futur
publish kernel patches, it rested in my private
chest of patches until I've seen the keynote of Linux.conf.au 2015. It made
me aware that this patch might have a chance to become included. ;)
Signed-off-by: Alexander Holler
---
Makefile | 7 +++
init/Kconfig | 12
2
Am 21.12.2014 um 18:09 schrieb Joe Perches:
On Sun, 2014-12-21 at 11:23 +0100, Alexander Holler wrote:
Am 19.12.2014 um 14:36 schrieb Alexander Holler:
In times where things like checkpatch do exist and are mandated to be used,
it would be easy to warn if too many levels of indentation are
Am 21.12.2014 um 11:23 schrieb Alexander Holler:
Uups, there is maximum of 8 levels of intendation (not 9, the first tab
And, please, no words about my broken english. Turn on your human fuzzy
and do s/intendation/indentation/ ;)
Regards,
Alexander Holler
--
To unsubscribe from this list
Am 19.12.2014 um 14:36 schrieb Alexander Holler:
In times where things like checkpatch do exist and are mandated to be used,
it would be easy to warn if too many levels of indentation are used (e.g.
by counting leading tabs).
The paragraph before already says that more than 3 levels of
only smells like an additional
excuse or polemic (because you still could use an unholy number of e.g.
7 indentations, even within the limit of 80 chars).
Signed-off-by: Alexander Holler
---
Documentation/CodingStyle | 4
1 file changed, 4 deletions(-)
diff --git a/Documentation/CodingStyle b
roken dependency list too.
Avoid that by not including this dependency list for make goals (dist)clean.
Signed-off-by: Alexander Holler
Cc:
---
Changes to v3: none
usr/Makefile | 2 ++
1 file changed, 2 insertions(+)
diff --git a/usr/Makefile b/usr/Makefile
index e767f01..5d5b6aa 100644
---
The initramfs generation is broken for file and directory names which contain
colons, spaces and other unusual characters which can't be included in names
for dependencies in traditional Makefiles (which gen_initramfs_list.sh
generates). Print an error for the most common unsupported characters (co
Am 17.10.2014 um 12:53 schrieb Frans Klaver:
On Thu, Oct 16, 2014 at 8:37 AM, Alexander Holler wrote:
I wonder if anyone else will fix this in a maintainer-approved style which
doesn't use these evil leftovers from C666 called functions.
I'll pick this up then.
Thanks.
Still
Am 16.10.2014 08:37, schrieb Alexander Holler:
Hello,
I wonder if anyone else will fix this in a maintainer-approved style
which doesn't use these evil leftovers from C666 called functions.
Or will the sysfs for most NAND drivers be knowingly broken forever?
To explain that a bit mor
Hello,
I wonder if anyone else will fix this in a maintainer-approved style
which doesn't use these evil leftovers from C666 called functions.
Or will the sysfs for most NAND drivers be knowingly broken forever?
Regards,
Alexander Holler
Am 27.05.2014 00:12, schrieb Alexander Holle
Am 17.09.2014 10:51, schrieb Robin Gong:
On Tue, Sep 16, 2014 at 11:41:55AM +0200, Alexander Holler wrote:
Am 16.09.2014 05:52, schrieb Robin Gong:
On Mon, Sep 15, 2014 at 01:50:02PM +0200, Alexander Holler wrote:
Am 10.09.2014 07:30, schrieb Robin Gong:
There is one weird data in rxfifo
Am 16.09.2014 05:52, schrieb Robin Gong:
On Mon, Sep 15, 2014 at 01:50:02PM +0200, Alexander Holler wrote:
Am 10.09.2014 07:30, schrieb Robin Gong:
There is one weird data in rxfifo after one full rx/tx transfer
done sometimes. It looks a design issue and hard to workaround
totally, so disable
in the DMA-engine which not only effects SPI. Or
both drivers contain the same error in handling DMA (maybe through c&p).
But that's just specualtion from me, I haven't looked further into that
problem.
Regards,
Alexander Holler
--
To unsubscribe from this list: send the line "
st are the compilers/interpreters? How are they maintained?
What happens if you find a bug in the compiler/interpreter?
But, as said above, I don't have to provide a solution because I'm not
the one who has gone out to change PID 1 into something more complicated. ;)
Regards,
Alexande
Am 05.09.2014 08:31, schrieb Alexander Holler:
Am 04.09.2014 21:18, schrieb Rob Landley:
What's actually wrong with C++ at a language design level.
Short version:
OMG.
It's better than C. In almost every aspect. Stop. Nothing else. Of
course, if you want to write something like
;t have to understand how templates do work to use e.g.
std::string. Other people do hard stuff for you. So don't panic.
Alexander Holler
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo i
Am 04.09.2014 20:27, schrieb Rogelio Serrano:
On Mon, Aug 18, 2014 at 7:15 PM, Alexander Holler wrote:
Am 13.08.2014 11:00, schrieb Borislav Petkov:
On Wed, Aug 13, 2014 at 10:27:56AM +0200, Peter Zijlstra wrote:
And the thing is; we're all very busy so we tend to take the 'eas
Am 04.09.2014 19:58, schrieb Austin S Hemmelgarn:
On 2014-09-04 13:29, Alexander Holler wrote:
Am 04.09.2014 16:36, schrieb Austin S Hemmelgarn:
On 2014-09-04 06:16, Alexander Holler wrote:
It's a myth that C++ ends up in bigger code than C. At least in my
experience. Especially whe
Am 04.09.2014 16:36, schrieb Austin S Hemmelgarn:
On 2014-09-04 06:16, Alexander Holler wrote:
It's a myth that C++ ends up in bigger code than C. At least in my
experience. Especially when the latest additions to C++ are in effect
(like the move-semantics in C++11 I like quiet a lot and
Am 04.09.2014 09:54, schrieb Peter Zijlstra:
On Mon, Aug 18, 2014 at 08:15:45PM +0200, Alexander Holler wrote:
Hmm, a sane and maintainable solution would use C++ with which people don't
have to manually build lists or hashes for every structure like in the
kernel (generic programming
Am 28.08.2014 11:23, schrieb Catalin Marinas:
On Thu, Aug 28, 2014 at 07:50:36AM +0100, Alexander Holler wrote:
And I wonder how the ACPI world solves that problem. My guess would be
hardcoded stuff in the firmware-blob (BIOS), just like it happened with
board files, but I've never seen
ady 2 years ago.
And I wonder how the ACPI world solves that problem. My guess would be
hardcoded stuff in the firmware-blob (BIOS), just like it happened with
board files, but I've never seen BIOS code and my knowledge about ACPI
is almost zero. ;)
Regards,
Alexander Holler
--
To unsubs
their HW. And they don't care if they have to change the DT if they
finally are able to use their board, which happens seldom enough. (I'm
not speaking about companies which are able to spend many man-years to
fix one kernel version for use with one specific HW).
Regards,
Alexander
Am 27.08.2014 18:37, schrieb Stephen Warren:
On 08/27/2014 10:30 AM, Alexander Holler wrote:
Am 27.08.2014 18:22, schrieb Stephen Warren:
On 08/27/2014 08:44 AM, Catalin Marinas wrote:
It's not just optimisation but an important feature for new arm64 SoCs.
Given some Tegra discus
Am 27.08.2014 18:22, schrieb Stephen Warren:
On 08/27/2014 08:44 AM, Catalin Marinas wrote:
It's not just optimisation but an important feature for new arm64 SoCs.
Given some Tegra discussions recently, in many cases the machine_desc
use on arm is primarily to initialise devices in the right o
Am 27.08.2014 09:16, schrieb Alexander Holler:
Why should I? I've posted patches along with a lot of comments and
explanations, and e.g. you are just talking that it should be made like
my patches already did. And others do talk too like my patches and the
accompanying comments from me
y won't spend
the time to post another patch (they still might fix other bugs, but
just for themself).
Regards,
Alexander Holler
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Am 26.08.2014 13:47, schrieb Thierry Reding:
On Tue, Aug 26, 2014 at 01:23:54PM +0200, Alexander Holler wrote:
Am 26.08.2014 13:08, schrieb Thierry Reding:
On Tue, Aug 26, 2014 at 12:44:35PM +0200, Alexander Holler wrote:
Am 26.08.2014 12:25, schrieb Thierry Reding:
On Tue, Aug 26, 2014 at
Am 26.08.2014 13:08, schrieb Thierry Reding:
On Tue, Aug 26, 2014 at 12:44:35PM +0200, Alexander Holler wrote:
Am 26.08.2014 12:25, schrieb Thierry Reding:
On Tue, Aug 26, 2014 at 11:42:04AM +0200, Alexander Holler wrote:
You need either the type information in the DTB (that's why I&#
Am 26.08.2014 12:44, schrieb Alexander Holler:
Am 26.08.2014 12:25, schrieb Thierry Reding:
On Tue, Aug 26, 2014 at 11:42:04AM +0200, Alexander Holler wrote:
You need either the type information in the DTB (that's why I've add
those
"dependencies" to identify phandles),
Am 26.08.2014 12:25, schrieb Thierry Reding:
On Tue, Aug 26, 2014 at 11:42:04AM +0200, Alexander Holler wrote:
You need either the type information in the DTB (that's why I've add those
"dependencies" to identify phandles), or you need to know every binding (at
"de
re).
Anyway, I've not looked further into that problem (with devices, not
drivers) as it already seems quiet impossible to get the other necessary
stuff into the kernel in a reasonable time (before 32bit-HW which does
use DT will not be available anymore).
Regards,
Alexander Holler
--
To u
f that
type. And those which aren't can be either just used like before (if it
works) or they can be changed.
Changing them can be done per board (only enable dependency based order
for a board if necessary drivers have changed).
Regards,
Alexander Holler
--
To unsubscribe from thi
ve-time" to identify phandles. The latter
is impracticable to implement in a generic way (for use with every
possible binding).
Regards,
Alexander Holler
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.
lity problems.
None in my approach. The DT just includes an additional binding to
circumvent the missing but needed type information for phandles.
Regards,
Alexander Holler
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@v
Am 22.08.2014 15:19, schrieb Mark Rutland:
On Thu, Aug 21, 2014 at 08:19:00PM +0100, Alexander Holler wrote:
Am 21.08.2014 16:02, schrieb Thierry Reding:
Anyway, those are all fairly standard reasons for where deferred probe
triggers, and since I do like deferred probe for it's simplicit
eaten me without cooking.
Regards,
Alexander Holler
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Am 20.08.2014 11:47, schrieb Alexander Holler:
Am 20.08.2014 11:28, schrieb Hagen Paul Pfeifer:
On 20 August 2014 11:07, Alexander Holler wrote:
For sure it could be better, but I'm already happy with the current
imperfect solution which I can use now and not some perfect solution
Am 20.08.2014 11:28, schrieb Hagen Paul Pfeifer:
On 20 August 2014 11:07, Alexander Holler wrote:
For sure it could be better, but I'm already happy with the current
imperfect solution which I can use now and not some perfect solution which
might be available in some years.
Alexande
Am 20.08.2014 10:24, schrieb Hagen Paul Pfeifer:
On 19 August 2014 21:36, Alexander Holler wrote:
It doesn't have to work in every environment and it doesn't have to solve
all existing problems in the world. ;)
But it enables people to protect a bit more against malicious
t can be used even easier with preloading
libknockify.so.
There can be found much more useless options in the kernel. At least I
like it and it fits my needs too.
Regards,
Alexander Holler
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a m
right). So you won't find much
kernel developers there. ;)
Regards,
Alexander Holler
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordom
me with.
Regards,
Alexander Holler
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
't care if your machine
comes up in 5 or 10 seconds, it is a no-brainer.
Regards,
Alexander Holler
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/maj
Am 07.07.2014 13:50, schrieb Roman Fietze:
Hello list members,
And here the second part.
From e523006a34db26c274d3b71de5b914f476fb029e Mon Sep 17 00:00:00 2001
From: Roman Fietze
Date: Fri, 4 Jul 2014 10:05:08 +0200
Subject: [PATCH 2/2] rtc: add kernel parameter hctosys, use it instead of
rwrite when
> starting the kernel or system was the RTC used to initialize the
> system clock.
You might have a look at a year old thread with working patches which
does a bit more too:
https://lkml.org/lkml/2014/6/13/6
Regards,
Alexander Holler
--
To unsubscribe from this list: send the line
for if someone would really
design such a system, he should solve this problem himself.
Alexander Holler
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo
Am 28.06.2014 20:54, schrieb Marc Dietrich:
On Sat, 28 Jun 2014 09:32:50 +0200
Alexander Holler wrote:
Am 28.06.2014 09:18, schrieb Alexander Holler:
Am 27.06.2014 19:27, schrieb John Stultz:
Its been pointed out that the RTC hctosys functionality doesn't
work well with RTC modules,
Am 28.06.2014 09:18, schrieb Alexander Holler:
Am 27.06.2014 19:27, schrieb John Stultz:
Its been pointed out that the RTC hctosys functionality doesn't
work well with RTC modules, which may not be loaded until after
late_init().
While there have been other attempts to sovle this,
Am 27.06.2014 19:27, schrieb John Stultz:
Its been pointed out that the RTC hctosys functionality doesn't
work well with RTC modules, which may not be loaded until after
late_init().
While there have been other attempts to sovle this, this patchset
is a very quick 10 minute effort to show how I'
Am 23.06.2014 23:36, schrieb John Stultz:
On Sat, Jun 21, 2014 at 6:08 AM, Alexander Holler wrote:
Am 12.06.2014 01:53, schrieb John Stultz:
You can read some of the previous discussion here:
https://lkml.org/lkml/2013/6/17/533
I'd be very interested in patches to resolve this!
An
t say that "looks good but doesn't work" is a high standard,
but maybe I'm old school.
Regards,
Alexander Holler
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info a
ch do expect other people have to play remote
keyboard and have to take responsibility for changes maintainers don't
want to be responsible for themself.
So the above quoted sentence is just another "marketing" verbiage, at
least in my point of view.
Alexander Holler
--
To
do "persistent"
clocks might have two instances, this shouldn't be a problem at all.
Signed-off-by: Alexander Holler
---
I've based these patches on 3.15, an older version can be found at LKML,
Besides discussing possible *real* bugs, I don't care what any person
(includ
ht be
handled by the driver named rtc_cmos too).
This will replace the existent driver/mechanism hctosys and the kernel
config options CONFIG_RTC_HCTOSYS and CONFIG_RTC_HCTOSYS_DEVICE (done
with one of the following patches)
Signed-off-by: Alexander Holler
---
I've based these patches on 3
-off-by: Alexander Holler
---
I've based these patches on 3.15, an older version can be found at LKML,
Besides discussing possible *real* bugs, I don't care what any person
(including maintainers) will request. I'm fine with these patches (I'm
using them since a year) and
But if someone wants these
patches based on 3.15, feel free to notice me.
To get rid of hctosys, I have 3 patches, and 2 more to implement
rtc_read_timeval() for higher resolution clocks.
Regards,
Alexander Holler
--
To unsubscribe from this list: send the line "unsubscribe linux-kern
Am 10.06.2014 00:40, schrieb Jiri Kosina:
> On Tue, 10 Jun 2014, Alexander Holler wrote:
>
>> Hello,
>>
>> while rebasing the dozens (currently around 60) of refused, ignored or
>> similiar bugfixes and patches I need to use a Linux kernel, I've noticed that
>
liar patch from Srinivas Pandruvada
named like the topic ended up in the kernel.
Looking at the differences, I wonder if not all spin_lock() calls in
hid-sensor-hub.c should be changed into spin_lock_irqsave() like the
patch from Jiri Kosina did.
Regards,
Alexander Holler
(sorry for the du
Am 31.05.2014 08:45, schrieb Alexander Holler:
Am 31.05.2014 07:28, schrieb Marcel Holtmann:
so I actually wonder if we should move away from timer and move to a delayed
work item to handle the timeout and if that would actually fix this issue.
The problem is that I have absolutely no clue
is hard to specify a value
>> reasonable for all possible systems (-configurations, -loads).
>>
>> Furthermore, if the timeout includes local processing of HCI command
>> responses, in-kernel errors like hung tasks might be masked by the
>> timeout, because the hung
e bootloader, which might have confused the dongle
>> such that it needs a bit more time, but I'm not sure.
>>
>> Together with the patch which limits the timeout only to the actual time the
>> dongle needs to process an HCI command (and doesn't include the time the
&
Am 29.05.2014 08:17, schrieb Artem Bityutskiy:
On Wed, 2014-05-28 at 23:09 +0200, Alexander Holler wrote:
I'm very sorry, but I find such discussions extremly tiresome.
Why discussing then at all, just go ahead and to something else.
Agreed. In order to maintain psychical health it
Am 28.05.2014 23:49, schrieb Brian Norris:
On Wed, May 28, 2014 at 11:09:05PM +0200, Alexander Holler wrote:
I'm very sorry, but I find such discussions extremly tiresome.
If you just would have suggested that one if to prevent that someone who
doesn't c&p existing code would
Am 28.05.2014 22:10, schrieb Brian Norris:
> On Wed, May 28, 2014 at 08:52:06PM +0200, Alexander Holler wrote:
>> Am 28.05.2014 10:43, schrieb Brian Norris:
>>> On Tue, May 27, 2014 at 12:12:26AM +0200, Alexander Holler wrote:
>>>> +{
>>>> + mtd->
Am 28.05.2014 10:43, schrieb Brian Norris:
On Tue, May 27, 2014 at 12:12:26AM +0200, Alexander Holler wrote:
--- a/include/linux/mtd/mtd.h
+++ b/include/linux/mtd/mtd.h
@@ -23,7 +23,7 @@
#include
#include
#include
-#include
+#include
#include
@@ -366,6 +366,15 @@ static inline
Am 27.05.2014 22:02, schrieb Grant Likely:
> On Mon, 19 May 2014 14:35:49 +0200, Alexander Holler
> wrote:
>> What's still questionable about the patches for dtc is if dependencies
>> to devices and not just drivers should be included in the new property
>>
Am 16.05.2014 07:35, schrieb Alexander Holler:
Am 15.05.2014 17:19, schrieb Alexander Holler:
Am 15.05.2014 16:50, schrieb Alexander Holler:
Am 15.05.2014 14:54, schrieb Luiz Augusto von Dentz:
This timeout seems arbitrary so I suppose we can increase it if we
feel it is necessary but we
Fix a common error in nand-drivers which do not set up a parent device for
the mtd-device by using a new inline function.
Signed-off-by: Alexander Holler
---
Changes to v1: add owner to module
drivers/mtd/nand/pxa3xx_nand.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
Fix a common error in nand-drivers which do not set up a parent device for
the mtd-device by using a new inline function.
Signed-off-by: Alexander Holler
---
Changes to v1: add owner to module
drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions
Am 27.05.2014 05:12, schrieb Alexander Shiyan:
Tue, 27 May 2014 00:12:34 +0200 от Alexander Holler :
Fix a common error in nand-drivers which do not set up a parent devicefor
the mtd-device by using a new inline function.
Signed-off-by: Alexander Holler
---
drivers/mtd/nand/pxa3xx_nand.c
Use the new common function mtd_setup_common_members()
Signed-off-by: Alexander Holler
---
drivers/mtd/nand/lpc32xx_slc.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/mtd/nand/lpc32xx_slc.c b/drivers/mtd/nand/lpc32xx_slc.c
index 53a6742..c8fb46b 100644
--- a
Fix a common error in nand-drivers which do not set up a parent device for
the mtd-device by using a new inline function.
Signed-off-by: Alexander Holler
---
drivers/mtd/nand/fsl_upm.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/mtd/nand/fsl_upm.c b/drivers
Fix a common error in nand-drivers which do not set up a parent device for
the mtd-device by using a new inline function.
Signed-off-by: Alexander Holler
---
drivers/mtd/nand/txx9ndfmc.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/mtd/nand/txx9ndfmc.c b
Fix a common error in nand-drivers which do not set up a parent device for
the mtd-device by using a new inline function.
Signed-off-by: Alexander Holler
---
drivers/mtd/nand/mpc5121_nfc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mtd/nand/mpc5121_nfc.c b
Fix a common error in nand-drivers which do not set up a parent device for
the mtd-device by using a new inline function.
Signed-off-by: Alexander Holler
---
drivers/mtd/nand/fsl_ifc_nand.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/mtd/nand/fsl_ifc_nand.c b
Fix a common error in nand-drivers which do not set up a parent device for
the mtd-device by using a new inline function.
Signed-off-by: Alexander Holler
---
drivers/mtd/nand/ndfc.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/mtd/nand/ndfc.c b/drivers/mtd/nand
Fix a common error in nand-drivers which do not set up a parent device for
the mtd-device by using a new inline function.
Signed-off-by: Alexander Holler
---
drivers/mtd/nand/jz4740_nand.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/mtd/nand/jz4740_nand.c b
Fix a common error in nand-drivers which do not set up a parent device for
the mtd-device by using a new inline function.
Signed-off-by: Alexander Holler
---
drivers/mtd/nand/fsl_elbc_nand.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/mtd/nand/fsl_elbc_nand.c
Fix a common error in nand-drivers which do not set up a parent device for
the mtd-device by using a new inline function.
Signed-off-by: Alexander Holler
---
drivers/mtd/nand/bcm47xxnflash/main.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/mtd/nand
Use the new common function mtd_setup_common_members().
Signed-off-by: Alexander Holler
---
drivers/mtd/nand/socrates_nand.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/mtd/nand/socrates_nand.c b/drivers/mtd/nand/socrates_nand.c
index fe8058a..0b87be2 100644
Use the new common function mtd_setup_common_members()
Signed-off-by: Alexander Holler
---
drivers/mtd/nand/lpc32xx_mlc.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/mtd/nand/lpc32xx_mlc.c b/drivers/mtd/nand/lpc32xx_mlc.c
index 687478c..4fa7b13 100644
--- a
Fix a common error in nand-drivers which do not set up a parent device for
the mtd-device by using a new inline function.
Signed-off-by: Alexander Holler
---
drivers/mtd/nand/docg4.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/mtd/nand/docg4.c b/drivers/mtd
Use the new common function mtd_setup_common_members()
Signed-off-by: Alexander Holler
---
drivers/mtd/nand/mxc_nand.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/mtd/nand/mxc_nand.c b/drivers/mtd/nand/mxc_nand.c
index dba262b..31114db4 100644
--- a/drivers
Use the new common function mtd_setup_common_members()
Signed-off-by: Alexander Holler
---
drivers/mtd/nand/davinci_nand.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/mtd/nand/davinci_nand.c b/drivers/mtd/nand/davinci_nand.c
index b922c8e..ce409fc 100644
201 - 300 of 723 matches
Mail list logo
