Arnd Bergmann writes:
> Both writes leave the CPU core within the spinlock but are not serialized
> with anything else, so there is no ordering between the CPUs when they
> enter the shared bus, other than having address before data. You'd
> expect to see address0, data0, address1, data1, but it
Kefeng Wang writes:
> Use helper of_platform_default_populate() in linux/of_platform
> when possible, instead of calling of_platform_populate() with
> the default match table.
> --- a/arch/arm/mach-cns3xxx/core.c
> +++ b/arch/arm/mach-cns3xxx/core.c
> @@ -395,8 +395,7
Kefeng Wang writes:
> Use helper of_platform_default_populate() in linux/of_platform
> when possible, instead of calling of_platform_populate() with
> the default match table.
> --- a/arch/arm/mach-cns3xxx/core.c
> +++ b/arch/arm/mach-cns3xxx/core.c
> @@ -395,8 +395,7 @@ static void __init
Arnd Bergmann writes:
> The barriers on a spinlock synchronize between CPUs but not an external
> bus, so (on some architectures) a spinlock protecting an MMIO register
> does not guarantee that two CPUs doing
>
> spin_lock();
> __raw_writel(address);
>
Arnd Bergmann writes:
> The barriers on a spinlock synchronize between CPUs but not an external
> bus, so (on some architectures) a spinlock protecting an MMIO register
> does not guarantee that two CPUs doing
>
> spin_lock();
> __raw_writel(address);
> __raw_writel(data);
>
Arnd Bergmann writes:
> I consider the use of __raw_* accessors a bug, I don't think we should
> ever do that because it hides how the hardware actually works, it doesn't
> work with spinlocks, and it can lead to the compiler splitting up accesses
> into byte sized ones (not on
Arnd Bergmann writes:
> I consider the use of __raw_* accessors a bug, I don't think we should
> ever do that because it hides how the hardware actually works, it doesn't
> work with spinlocks, and it can lead to the compiler splitting up accesses
> into byte sized ones (not on ARM with the
Arnd Bergmann writes:
>> Anyway, I think readl()/writel() do the right thing: in BE mode they
>> swap PCI accesses and don't swap normal registers, in LE mode nothing is
>> swapped.
>
> This seems to be true when CONFIG_IXP4XX_INDIRECT_PCI is set, but
> not otherwise. For the
Arnd Bergmann writes:
>> Anyway, I think readl()/writel() do the right thing: in BE mode they
>> swap PCI accesses and don't swap normal registers, in LE mode nothing is
>> swapped.
>
> This seems to be true when CONFIG_IXP4XX_INDIRECT_PCI is set, but
> not otherwise. For the indirect variant,
h/io.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Acked-by: Krzysztof Hałasa <khal...@piap.pl>
--
Krzysztof Halasa
Industrial Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, Poland
.de>
> ---
> arch/arm/mach-ixp4xx/common-pci.c | 98
> ++
> arch/arm/mach-ixp4xx/include/mach/io.h | 95 +++-
> 2 files changed, 104 insertions(+), 89 deletions(-)
Acked-by: Krzysztof Hałasa <khal...@piap.pl>
--
Krzysztof Halasa
Industrial Rese
und '+' in operand of '&' [-Wparentheses]
> io_mem = ioport_map(ioport & ~3, NETCARD_IO_EXTENT);
>
> Simply adding parentheses in the macro avoids the warning
>
> Signed-off-by: Arnd Bergmann
> ---
> arch/arm/mach-ixp4xx/include/mach/io.h | 2 +-
> 1 file changed, 1 inser
+
> arch/arm/mach-ixp4xx/include/mach/io.h | 95 +++-
> 2 files changed, 104 insertions(+), 89 deletions(-)
Acked-by: Krzysztof Hałasa
--
Krzysztof Halasa
Industrial Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, Poland
her definitions of the same functions pass void pointers,
> so doing the same here avoids the warnings.
>
> Signed-off-by: Arnd Bergmann <a...@arndb.de>
> ---
> arch/arm/mach-ixp4xx/include/mach/io.h | 23 +--
> 1 file changed, 17 insertions(+), 6 deleti
he same functions pass void pointers,
> so doing the same here avoids the warnings.
>
> Signed-off-by: Arnd Bergmann
> ---
> arch/arm/mach-ixp4xx/include/mach/io.h | 23 +--
> 1 file changed, 17 insertions(+), 6 deletions(-)
Acked-by: Krzysztof Hałas
arch/arm/mach-cns3xxx/Makefile.boot| 3 ---
Acked-by: Krzysztof Hałasa <khal...@piap.pl>
--
Krzysztof Halasa
Industrial Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, Poland
Masahiro Yamada writes:
> The variable "MACHINE" is empty if CONFIG_ARCH_MULTIPLATFORM=y,
> so these Makefile.boot files are never included.
>
> Signed-off-by: Masahiro Yamada
> ---
>
> arch/arm/mach-cns3xxx/Makefile.boot | 3 ---
Acked-by: Krzysztof Hałasa
-
Arnd Bergmann writes:
> The unclear part here is for IXP4xx, which supports both big-endian
> and little-endian configurations. So far, the driver has done
> no byteswap in either case. I suspect that is wrong and it would
> actually need to swap in one or the other case, but I don't know
>
Arnd Bergmann writes:
> This addresses both issues by moving all the definitions into the
> pxa25x_udc driver itself. It turns out the only difference between
> them was 'UDCCS_IO_ROF', and that could well be a mistake when it
> was incorrectly copied from pxa25x to ixp4xx.
>
> Signed-off-by:
Arnd Bergmann writes:
> The unclear part here is for IXP4xx, which supports both big-endian
> and little-endian configurations. So far, the driver has done
> no byteswap in either case. I suspect that is wrong and it would
> actually need to swap in one or the other case, but I
Arnd Bergmann writes:
> This addresses both issues by moving all the definitions into the
> pxa25x_udc driver itself. It turns out the only difference between
> them was 'UDCCS_IO_ROF', and that could well be a mistake when it
> was incorrectly copied from pxa25x to ixp4xx.
>
>
Arnd Bergmann writes:
> On ixp4xx, the readl() function returns an 'unsigned long' output
> when indirect I/O is used. This is unlike any other platform, and
> it causes lots of harmless compiler warnings, such as:
>
> drivers/ata/libahci.c: In function 'ahci_show_host_version':
>
SF Markus Elfring writes:
> The dma_pool_destroy() function tests whether its argument is NULL
> and then returns immediately. Thus the test around the call is not needed.
>
> This issue was detected by using the Coccinelle software.
> --- a/drivers/net/ethernet/xscale/ixp4xx_eth.c
> +++
SF Markus Elfring writes:
> The dma_pool_destroy() function tests whether its argument is NULL
> and then returns immediately. Thus the test around the call is not needed.
>
> This issue was detected by using the Coccinelle software.
> --- a/drivers/net/wan/ixp4xx_hss.c
> +++
SF Markus Elfring writes:
> The dma_pool_destroy() function tests whether its argument is NULL
> and then returns immediately. Thus the test around the call is not needed.
>
> This issue was detected by using the Coccinelle software.
> ---
SF Markus Elfring writes:
> The dma_pool_destroy() function tests whether its argument is NULL
> and then returns immediately. Thus the test around the call is not needed.
>
> This issue was detected by using the Coccinelle software.
> ---
Arnd Bergmann writes:
> On ixp4xx, the readl() function returns an 'unsigned long' output
> when indirect I/O is used. This is unlike any other platform, and
> it causes lots of harmless compiler warnings, such as:
>
> drivers/ata/libahci.c: In function 'ahci_show_host_version':
>
/pcie.c | 71
> +
I'm ATM unable to test this change, but will do that at some point.
Meanwhile, I guess there is nothing I can say against this patch.
Thanks.
Acked-by: Krzysztof Hałasa
--
Krzysztof Halasa
Industrial Research Institute for Automation and Measurements PIAP
Al. Jerozo
ns3xxx/pcie.c | 71
> +
I'm ATM unable to test this change, but will do that at some point.
Meanwhile, I guess there is nothing I can say against this patch.
Thanks.
Acked-by: Krzysztof Hałasa <khal...@piap.pl>
--
Krzysztof Halasa
Industrial Research Institute for
Andrey Utkin writes:
[H.264 headers]
> I guess that one acceptable way is to pre-generate all headers for all
> needed cases and ship them inlined; for correctness checking purpose,
> it is possible to ship also a script or additional source code file
> which is able to generate same headers.
I
Andrey Utkin writes:
[H.264 headers]
> I guess that one acceptable way is to pre-generate all headers for all
> needed cases and ship them inlined; for correctness checking purpose,
> it is possible to ship also a script or additional source code file
> which is
Joe Perches writes:
>> So, could we have the localized readability when it makes sense,
>> and the default rules when nothing else applies?
>
> Then the question becomes how local.
The answer seems easy to me: as much as it's needed to get the best
readability.
If that means 4 or 2 custom
Joe Perches writes:
> Nah, you're not an extremist, you're just preferring narrowly
> localized readability over global consistency.
>
> That's fine and all, until you come up to LCONSOLE_ERROR_MSG
> type use which blows the nice old formatting up.
>
> So what I suggested is just a simple
Joe Perches j...@perches.com writes:
So, could we have the localized readability when it makes sense,
and the default rules when nothing else applies?
Then the question becomes how local.
The answer seems easy to me: as much as it's needed to get the best
readability.
If that means 4 or 2
Joe Perches j...@perches.com writes:
Nah, you're not an extremist, you're just preferring narrowly
localized readability over global consistency.
That's fine and all, until you come up to LCONSOLE_ERROR_MSG
type use which blows the nice old formatting up.
So what I suggested is just a
Joe Perches writes:
> -#define LCONSOLE(mask, format, ...) CDEBUG(D_CONSOLE | (mask), format, ##
> __VA_ARGS__)
> -#define LCONSOLE_INFO(format, ...) CDEBUG_LIMIT(D_CONSOLE, format, ##
> __VA_ARGS__)
> -#define LCONSOLE_WARN(format, ...) CDEBUG_LIMIT(D_CONSOLE | D_WARNING,
> format, ##
Joe Perches j...@perches.com writes:
-#define LCONSOLE(mask, format, ...) CDEBUG(D_CONSOLE | (mask), format, ##
__VA_ARGS__)
-#define LCONSOLE_INFO(format, ...) CDEBUG_LIMIT(D_CONSOLE, format, ##
__VA_ARGS__)
-#define LCONSOLE_WARN(format, ...) CDEBUG_LIMIT(D_CONSOLE | D_WARNING,
Mario Bambagini writes:
> Defines have been written in more than one line to match the 80-character
> rule. This error has been fixed 6 times in this file.
> The file is fully compliant with respect to the coding rules now.
Rules, maybe. But is it better, i.e., more readable?
> ---
Mario Bambagini mario.bambag...@gmail.com writes:
Defines have been written in more than one line to match the 80-character
rule. This error has been fixed 6 times in this file.
The file is fully compliant with respect to the coding rules now.
Rules, maybe. But is it better, i.e., more
Joe Perches writes:
> #define VDREG8(a0) ((const u16[]){\
> a0 + 0x000, a0 + 0x010, a0 +0x020, a0 + 0x030, \
> a0 + 0x100, a0 + 0x110, a0 +0x120, a0 + 0x130})
>
> as "const u16[]" is a $Type but "const u16[]" is not.
>
> Still, as written, the code seems fragile
Joe Perches writes:
> It might be better to use some base + index macro
> as it could be smaller object code.
>
> Something like:
>
> #define REG_NO(base, multiplier, index) (base + (multiplier * index))
>
> reg_write(vc->dev, REG_NO(0x10, 1, vc->ch), dma_cfg);
> or
>
> #define
Joe Perches j...@perches.com writes:
It might be better to use some base + index macro
as it could be smaller object code.
Something like:
#define REG_NO(base, multiplier, index) (base + (multiplier * index))
reg_write(vc-dev, REG_NO(0x10, 1, vc-ch), dma_cfg);
or
#define
Joe Perches j...@perches.com writes:
#define VDREG8(a0) ((const u16[]){\
a0 + 0x000, a0 + 0x010, a0 +0x020, a0 + 0x030, \
a0 + 0x100, a0 + 0x110, a0 +0x120, a0 + 0x130})
as const u16[] is a $Type but const u16[digits] is not.
Still, as written, the code
Bjorn Helgaas writes:
>> Intersil/Techwell TW686[4589]-based video capture cards have an empty
>> (zero) class code. Fix it.
>>
> Applied to pci/misc for v4.2, with minor tweak as below to use
> PCI_CLASS_MULTIMEDIA_OTHER instead of a bare number. Let me know
> if you see any issues with this.
Joe Perches writes:
> How is the macro used?
> #define REG8_1(a0) ((const u16[8]){a0, a0 + 1, a0 + 2, a0 + 3})
#define REG8_1(a0) ((const u16[8]){a0, a0 + 1, a0 + 2, a0 + 3, a0 + 4, a0 + 5,
a0 + 6, a0 + 7})
#define REG8_2(a0) ((const u16[8]){a0, a0 + 2, a0 + 4, a0 + 6, a0 + 8, a0 +
0xA, a0 +
Joe Perches j...@perches.com writes:
How is the macro used?
#define REG8_1(a0) ((const u16[8]){a0, a0 + 1, a0 + 2, a0 + 3})
#define REG8_1(a0) ((const u16[8]){a0, a0 + 1, a0 + 2, a0 + 3, a0 + 4, a0 + 5,
a0 + 6, a0 + 7})
#define REG8_2(a0) ((const u16[8]){a0, a0 + 2, a0 + 4, a0 + 6, a0 + 8, a0
Bjorn Helgaas bhelg...@google.com writes:
Intersil/Techwell TW686[4589]-based video capture cards have an empty
(zero) class code. Fix it.
Applied to pci/misc for v4.2, with minor tweak as below to use
PCI_CLASS_MULTIMEDIA_OTHER instead of a bare number. Let me know
if you see any issues
Frans Klaver writes:
> Ah, right. One might say that this is a false positive, but that's up
> to Joe or Andy I guess.
>
> It may be valid C code, but I think this construction is slightly
> funky to begin with.
>
> Which file is this?
A new file, not yet sent anywhere.
--
Krzysztof Halasa
Frans Klaver writes:
>> #define REG8_1(a0) ((const u16[8]){a0, a0 + 1, a0 + 2, a0 + 3})
>>
>> vs
>>
>> #define REG8_1(a0) ((const u16[8]) {a0, a0 + 1, a0 + 2, a0 + 3})
>> ^
>
> The prescribed style is to have no space between cast and castee. So,
> the top
eal camera in a laptop) but it at least doesn't select the
TUNERs.
Perhaps the following patch would make sense.
Signed-off-by: Krzysztof Hałasa
--- a/drivers/media/pci/Kconfig
+++ b/drivers/media/pci/Kconfig
@@ -11,16 +11,16 @@ if MEDIA_PCI_SUPPORT
if MEDIA_CAMERA_SUPPORT
comment "Media
Hi,
a simple question: which style is preferred?
#define REG8_1(a0) ((const u16[8]){a0, a0 + 1, a0 + 2, a0 + 3})
vs
#define REG8_1(a0) ((const u16[8]) {a0, a0 + 1, a0 + 2, a0 + 3})
^
--
Krzysztof Halasa
Industrial Research Institute for Automation and
Intersil/Techwell TW686[4589]-based video capture cards have an empty
(zero) class code. Fix it.
Signed-off-by: Krzysztof Hałasa
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -3662,6 +3662,26 @@ DECLARE_PCI_FIXUP_HEADER(0x1283, 0x8892,
quirk_use_pcie_bridge_dma_alias
) but it at least doesn't select the
TUNERs.
Perhaps the following patch would make sense.
Signed-off-by: Krzysztof Hałasa khal...@piap.pl
--- a/drivers/media/pci/Kconfig
+++ b/drivers/media/pci/Kconfig
@@ -11,16 +11,16 @@ if MEDIA_PCI_SUPPORT
if MEDIA_CAMERA_SUPPORT
comment Media
Frans Klaver franskla...@gmail.com writes:
Ah, right. One might say that this is a false positive, but that's up
to Joe or Andy I guess.
It may be valid C code, but I think this construction is slightly
funky to begin with.
Which file is this?
A new file, not yet sent anywhere.
--
Intersil/Techwell TW686[4589]-based video capture cards have an empty
(zero) class code. Fix it.
Signed-off-by: Krzysztof Hałasa khal...@piap.pl
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -3662,6 +3662,26 @@ DECLARE_PCI_FIXUP_HEADER(0x1283, 0x8892,
quirk_use_pcie_bridge_dma_alias
Frans Klaver franskla...@gmail.com writes:
#define REG8_1(a0) ((const u16[8]){a0, a0 + 1, a0 + 2, a0 + 3})
vs
#define REG8_1(a0) ((const u16[8]) {a0, a0 + 1, a0 + 2, a0 + 3})
^
The prescribed style is to have no space between cast and castee. So,
the
Hi,
a simple question: which style is preferred?
#define REG8_1(a0) ((const u16[8]){a0, a0 + 1, a0 + 2, a0 + 3})
vs
#define REG8_1(a0) ((const u16[8]) {a0, a0 + 1, a0 + 2, a0 + 3})
^
--
Krzysztof Halasa
Industrial Research Institute for Automation and
Arnd Bergmann writes:
> The cns3xxx_pcie_hw_init function uses excessive kernel
> stack space because of a hack that puts a fake struct
> pci_sys_data and struct pci_bus on the stack in order to
> call the generic pci_bus_read_config accessors, which causes
> a warning in ARM allmodconfig
Arnd Bergmann a...@arndb.de writes:
The cns3xxx_pcie_hw_init function uses excessive kernel
stack space because of a hack that puts a fake struct
pci_sys_data and struct pci_bus on the stack in order to
call the generic pci_bus_read_config accessors, which causes
a warning in ARM
Andrey Utkin writes:
> Please check first digit. I mean _5_864, in your post there's 6869.
Ok, I just thought it may be a typo. I can now see 5864 is a H.264
encoder, while 686x are simpler frame-grabbers only.
Sorry for the noise.
--
Krzysztof Halasa
Research Institute for Automation and
Andrey Utkin writes:
> I am starting a work on driver for techwell tw5864 media grabber
If this is tw6864 then I have a driver mostly completed.
Actually I'm using tw6869 but I think this is very similar (4 channels
instead of 8 and PCI instead of PCIe). I have 6864s but haven't yet
tried using
Andrey Utkin andrey.ut...@corp.bluecherry.net writes:
I am starting a work on driver for techwell tw5864 media grabberencoder.
If this is tw6864 then I have a driver mostly completed.
Actually I'm using tw6869 but I think this is very similar (4 channels
instead of 8 and PCI instead of PCIe). I
Andrey Utkin andrey.ut...@corp.bluecherry.net writes:
Please check first digit. I mean _5_864, in your post there's 6869.
Ok, I just thought it may be a typo. I can now see 5864 is a H.264
encoder, while 686x are simpler frame-grabbers only.
Sorry for the noise.
--
Krzysztof Halasa
Research
Arnd Bergmann writes:
> Looks good. Krzysztof, do you want to pick this up and send me a
> pull request together with other patches, or should I apply this
> to the arm-soc fixes directly?
The latter, please.
Acked-by: Krzysztof Hałasa
--
Krzysztof Halasa
Research Institute for A
Arnd Bergmann a...@arndb.de writes:
Looks good. Krzysztof, do you want to pick this up and send me a
pull request together with other patches, or should I apply this
to the arm-soc fixes directly?
The latter, please.
Acked-by: Krzysztof Hałasa khal...@piap.pl
--
Krzysztof Halasa
Research
Arnd Bergmann writes:
> Most platforms use void pointer arguments in these functions, but
> ixp4xx does not, which triggers lots of warnings in device drivers like:
>
> net/ethernet/8390/ne2k-pci.c: In function 'ne2k_pci_get_8390_hdr':
> net/ethernet/8390/ne2k-pci.c:503:3: warning: passing
Arnd Bergmann a...@arndb.de writes:
Most platforms use void pointer arguments in these functions, but
ixp4xx does not, which triggers lots of warnings in device drivers like:
net/ethernet/8390/ne2k-pci.c: In function 'ne2k_pci_get_8390_hdr':
net/ethernet/8390/ne2k-pci.c:503:3: warning:
Nicholas Krause writes:
> This changes the location of the printk for montioring if the stucture pointer
> desc of type structure desc has a error count due to failing in the switch
> statement for checking it's status from the default switch case in this switch
> to the area of the function for
Rob Herring writes:
> Convert the cns3xxx PCI driver to use the generic config access functions.
>
> This changes accesses from __raw_readl/__raw_writel to readl/writel.
>
> arch/arm/mach-cns3xxx/pcie.c | 52
> +---
This looks fine:
A
-by: Krzysztof Hałasa khal...@piap.pl
--
Krzysztof Halasa
Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, Poland
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo
Nicholas Krause xerofo...@gmail.com writes:
This changes the location of the printk for montioring if the stucture pointer
desc of type structure desc has a error count due to failing in the switch
statement for checking it's status from the default switch case in this switch
to the area of
dma_pool_create() needs to unlock the mutex in error case.
The bug has been present starting with v3.16-rc1 (cc6b664a).
Signed-off-by: Krzysztof Hałasa
Cc: sta...@vger.kernel.org
--- a/mm/dmapool.c
+++ b/mm/dmapool.c
@@ -174,11 +174,11 @@ struct dma_pool *dma_pool_create(const char *name
dma_pool_create() needs to unlock the mutex in error case.
The bug has been present starting with v3.16-rc1 (cc6b664a).
Signed-off-by: Krzysztof Hałasa k...@piap.pl
Cc: sta...@vger.kernel.org
--- a/mm/dmapool.c
+++ b/mm/dmapool.c
@@ -174,11 +174,11 @@ struct dma_pool *dma_pool_create(const char
Arnd Bergmann writes:
> Applied to next/fixes-non-critical.
>
> Since the problem is not new and you didn't mark the patch as 'stable',
> this seems to be the right place. Let us know if you need backports
> to stable kernels, also fo the other patch.
Sure, BTW there is also that problem with
Arnd Bergmann a...@arndb.de writes:
Applied to next/fixes-non-critical.
Since the problem is not new and you didn't mark the patch as 'stable',
this seems to be the right place. Let us know if you need backports
to stable kernels, also fo the other patch.
Sure, BTW there is also that
off-by: Krzysztof Hałasa
--- a/arch/arm/mach-cns3xxx/cns3420vb.c
+++ b/arch/arm/mach-cns3xxx/cns3420vb.c
@@ -246,7 +246,6 @@ static void __init cns3420_map_io(void)
MACHINE_START(CNS3420VB, "Cavium Networks CNS3420 Validation Board")
.atag_offset= 0x100,
-
off-by: Krzysztof Hałasa
--
Krzysztof Halasa
Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, Poland
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More m
khal...@piap.pl (Krzysztof Hałasa) writes:
> This patch fixes the following BUG:
>
>> kernel BUG at mm/vmalloc.c:1132!
>> PC is at vm_area_add_early+0x20/0x84
>> LR is at add_static_vm_early+0xc/0x60
>>
>> The problem is cns3xxx_pcie_init() (device_initcal
khal...@piap.pl (Krzysztof Hałasa) writes:
This patch fixes the following BUG:
kernel BUG at mm/vmalloc.c:1132!
PC is at vm_area_add_early+0x20/0x84
LR is at add_static_vm_early+0xc/0x60
The problem is cns3xxx_pcie_init() (device_initcall) calls the early
iotable_init().
That's obviously
-by: Krzysztof Hałasa khal...@piap.pl
--
Krzysztof Halasa
Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, Poland
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More
-by: Krzysztof Hałasa khal...@piap.pl
--- a/arch/arm/mach-cns3xxx/cns3420vb.c
+++ b/arch/arm/mach-cns3xxx/cns3420vb.c
@@ -246,7 +246,6 @@ static void __init cns3420_map_io(void)
MACHINE_START(CNS3420VB, Cavium Networks CNS3420 Validation Board)
.atag_offset= 0x100,
- .nr_irqs
This patch fixes the following BUG:
> kernel BUG at mm/vmalloc.c:1132!
> PC is at vm_area_add_early+0x20/0x84
> LR is at add_static_vm_early+0xc/0x60
>
> The problem is cns3xxx_pcie_init() (device_initcall) calls the "early"
> iotable_init().
Instead of merely calling the PCIe iotable_init()
Arnd Bergmann writes:
> Patch looks good, but please add the changeset description from
> your first patch.
I wonder if another approach would be better. I don't like the .pfn
messing and the bugs that function introduces.
--
Krzysztof Halasa
Research Institute for Automation and Measurements
DaeSeok Youn writes:
>>> - * match with board's first found interface, otherwise this
>>> is first
>>> - * found
>>> + * match with board's first found interface, otherwise this is
>>> + * fisrt found
>>^
>> I wonder
DaeSeok Youn daeseok.y...@gmail.com writes:
- * match with board's first found interface, otherwise this
is first
- * found
+ * match with board's first found interface, otherwise this is
+ * fisrt found
^
I wonder
Arnd Bergmann a...@arndb.de writes:
Patch looks good, but please add the changeset description from
your first patch.
I wonder if another approach would be better. I don't like the .pfn
messing and the bugs that function introduces.
--
Krzysztof Halasa
Research Institute for Automation and
This patch fixes the following BUG:
kernel BUG at mm/vmalloc.c:1132!
PC is at vm_area_add_early+0x20/0x84
LR is at add_static_vm_early+0xc/0x60
The problem is cns3xxx_pcie_init() (device_initcall) calls the early
iotable_init().
Instead of merely calling the PCIe iotable_init() from
Daeseok Youn writes:
> clean up checkpatch.pl warnings:
> WARNING: Line length over 80 characters
This warning should be long gone IMHO. It does more harm than good.
> unsigned char *ucp = (unsigned char *) >mfg_info.data;
>
> pr_info("eeprom[00]: %02x %02x %02x
Daeseok Youn daeseok.y...@gmail.com writes:
clean up checkpatch.pl warnings:
WARNING: Line length over 80 characters
This warning should be long gone IMHO. It does more harm than good.
unsigned char *ucp = (unsigned char *) hi-mfg_info.data;
Signed-off-by: Krzysztof Hałasa
--- a/arch/arm/mach-cns3xxx/cns3420vb.c
+++ b/arch/arm/mach-cns3xxx/cns3420vb.c
@@ -240,7 +240,7 @@ static void __init cns3420_map_io(void)
{
cns3xxx_map_io();
iotable_init(cns3420_io_desc, ARRAY_SIZE(cns3420_io_desc
Hello,
Linux version 3.14.0-rc4+ (current tip, no extra patches), CPU is Cavium
Econa CNS3420, board is Gateworks Laguna GW2388-4 (masqueraded as
CNS3420VB).
Issue #1 ###
kernel BUG at mm/vmalloc.c:1132!
PC is at vm_area_add_early+0x20/0x84
LR is
Hello,
Linux version 3.14.0-rc4+ (current tip, no extra patches), CPU is Cavium
Econa CNS3420, board is Gateworks Laguna GW2388-4 (masqueraded as
CNS3420VB).
Issue #1 ###
kernel BUG at mm/vmalloc.c:1132!
PC is at vm_area_add_early+0x20/0x84
LR is
Signed-off-by: Krzysztof Hałasa khal...@piap.pl
--- a/arch/arm/mach-cns3xxx/cns3420vb.c
+++ b/arch/arm/mach-cns3xxx/cns3420vb.c
@@ -240,7 +240,7 @@ static void __init cns3420_map_io(void)
{
cns3xxx_map_io();
iotable_init(cns3420_io_desc, ARRAY_SIZE(cns3420_io_desc
Russell King - ARM Linux writes:
> Okay, reverted.
Thanks.
--
Krzysztof Halasa
Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, Poland
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Russell King - ARM Linux li...@arm.linux.org.uk writes:
Okay, reverted.
Thanks.
--
Krzysztof Halasa
Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, Poland
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a
Santosh Shilimkar writes:
> I am afraid you didn't understood what the fix is if you say above.
> arm_dma_limit is broken without this fix for LPAE machines with
> memory starting 4 GB physical boundary.
I wonder what CONFIG_ARM_PATCH_PHYS_VIRT and CONFIG_ZONE_DMA do they
use?
Of course,
masks.
Now, devices will have 32-bit default DMA masks (0x) as per DMA API.
Signed-off-by: Krzysztof Hałasa
diff --git a/arch/arm/mach-ixp4xx/common-pci.c
b/arch/arm/mach-ixp4xx/common-pci.c
index 6d6bde3..cefb80b 100644
--- a/arch/arm/mach-ixp4xx/common-pci.c
+++ b/arch/arm/mach-ixp4xx
Russell, Santosh,
the unneeded commit causing regression is still in place. Please try to
compile an ARM kernel without CONFIG_ARM_PATCH_PHYS_VIRT and with
CONFIG_ZONE_DMA and see for yourself, if you don't believe me.
Please be aware that this commit fixes nothing, its only function is
causing
Russell, Santosh,
the unneeded commit causing regression is still in place. Please try to
compile an ARM kernel without CONFIG_ARM_PATCH_PHYS_VIRT and with
CONFIG_ZONE_DMA and see for yourself, if you don't believe me.
Please be aware that this commit fixes nothing, its only function is
causing
masks.
Now, devices will have 32-bit default DMA masks (0x) as per DMA API.
Signed-off-by: Krzysztof Hałasa khal...@piap.pl
diff --git a/arch/arm/mach-ixp4xx/common-pci.c
b/arch/arm/mach-ixp4xx/common-pci.c
index 6d6bde3..cefb80b 100644
--- a/arch/arm/mach-ixp4xx/common-pci.c
+++ b/arch
101 - 200 of 227 matches
Mail list logo