* RE: [PATCH 2/2] davinci: Platform support for OMAP-L137/AM17x NOR flash driver
From: Nori, Sekhar @ 2010-10-08 6:50 UTC (permalink / raw)
To: Vitaly Wool
Cc: davinci-linux-open-source@linux.davincidsp.com, Sergei Shtylyov,
Aleksey Makarov, David Griego, linux-mtd@lists.infradead.org,
Dharmappa, Savinay
In-Reply-To: <AANLkTi=P8DcjCn_mozmvaNue2d_jn6meBzvXDbk3gpd3@mail.gmail.com>
On Fri, Oct 08, 2010 at 12:14:33, Vitaly Wool wrote:
> On Fri, Oct 8, 2010 at 5:54 AM, Nori, Sekhar <nsekhar@ti.com> wrote:
> > Hi Sergei,
> >
> > On Thu, Oct 07, 2010 at 20:35:28, Sergei Shtylyov wrote:
> >
> >> > +static void da830_evm_nor_done(void *data)
> >> > +{
> >> > + clk_disable(da830_evm_nor.clk);
> >> > + clk_put(da830_evm_nor.clk);
> >> > + iounmap(da830_evm_nor.latch.addr);
> >> > + release_mem_region(DA8XX_AEMIF_CS3_BASE, PAGE_SIZE);
> >> > + iounmap(da830_evm_nor.aemif.addr);
> >> > + release_mem_region(DA8XX_AEMIF_CTL_BASE, SZ_32K);
> >> > +}
> >>
> >> Why you've changed this function which was useful also for the error cleanup
> >> before?
> >
> > The issues down below aside, I think goto based error handling
> > is clearer to follow. Any objections to using goto based
> > error handing per-se?
>
> What you're saying just doesn't make sense in this context. Whatever
> way of error handling is chosen, it first needs to be correct which is
> absolutely not the case here.
Yes, agreed. It needs to be correct first.
Thanks,
Sekhar
^ permalink raw reply
* missing definition of 's3c_gpio_getpull' function in 'plat-samsung'
From: Kukjin Kim @ 2010-10-08 6:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <000301cb66af$276b8960$76429c20$@com>
Daein Moon wrote:
>
> Hi Ben Dooks and Kukjin,
>
> I found an issue about s3c_gpio_getpull API.
>
> The 'plat-samsung' provides 's3c_gpio_setpull' and 's3c_gpio_getpull'
> to set and get pull-{none|up|down} of GPIO. But there is no
> 's3c_gpio_getpull' definition in 'arch/arm/plat-samsung/gpio-config.c',
> and there is only declaration in the corresponding header file.
>
> 's3c_gpio_getpull' isn't supported/used. So if providing this api, its
> definition should be inserted.
>
> Otherwise, code that is used to provide s3c_gpio_getpull including
> following code should be removed.
>
> arch/arm/plat-samsung/include/plat/gpio-cfg.h:
> extern s3c_gpio_pull_t s3c_gpio_getpull(unsigned int pin);
>
> arch/arm/mach-{s3c*|s5p*}/gpiolib.c:
> .get_pull = s3c_gpio_getpull_updown,
>
>
> What do you think about that?
>
Oh...you mean s3c_gpio_getpull()?
Yes right..there is no it in gpio-config.c..maybe missed.
Anyway...in this case, I think to add missed function is better.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
^ permalink raw reply
* RE: missing definition of 's3c_gpio_getpull' function in 'plat-samsung'
From: Kukjin Kim @ 2010-10-08 6:50 UTC (permalink / raw)
To: 'Daein Moon', ben-linux; +Cc: linux-arm-kernel, linux-samsung-soc
In-Reply-To: <000301cb66af$276b8960$76429c20$@com>
Daein Moon wrote:
>
> Hi Ben Dooks and Kukjin,
>
> I found an issue about s3c_gpio_getpull API.
>
> The 'plat-samsung' provides 's3c_gpio_setpull' and 's3c_gpio_getpull'
> to set and get pull-{none|up|down} of GPIO. But there is no
> 's3c_gpio_getpull' definition in 'arch/arm/plat-samsung/gpio-config.c',
> and there is only declaration in the corresponding header file.
>
> 's3c_gpio_getpull' isn't supported/used. So if providing this api, its
> definition should be inserted.
>
> Otherwise, code that is used to provide s3c_gpio_getpull including
> following code should be removed.
>
> arch/arm/plat-samsung/include/plat/gpio-cfg.h:
> extern s3c_gpio_pull_t s3c_gpio_getpull(unsigned int pin);
>
> arch/arm/mach-{s3c*|s5p*}/gpiolib.c:
> .get_pull = s3c_gpio_getpull_updown,
>
>
> What do you think about that?
>
Oh...you mean s3c_gpio_getpull()?
Yes right..there is no it in gpio-config.c..maybe missed.
Anyway...in this case, I think to add missed function is better.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
^ permalink raw reply
* Re: [PATCH] Documentation: update-index: -z applies also to --index-info
From: Bert Wesarg @ 2010-10-08 6:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Štěpán Němec, git
In-Reply-To: <7viq1dwg8v.fsf@alter.siamese.dyndns.org>
On Fri, Oct 8, 2010 at 04:49, Junio C Hamano <gitster@pobox.com> wrote:
> Bert Wesarg <bert.wesarg@googlemail.com> writes:
>
>> diff --git a/Documentation/git-update-index.txt b/Documentation/git-update-index.txt
>> index 74d1d49..0999950 100644 Documentation/git-update-index.txt
>> --- a/Documentation/git-update-index.txt
>> +++ b/Documentation/git-update-index.txt
>> @@ -18,9 +18,9 @@ SYNOPSIS
>> [--skip-worktree | --no-skip-worktree]
>> [--ignore-submodules]
>> [--really-refresh] [--unresolve] [--again | -g]
>> - [--info-only] [--index-info]
>> - [-z] [--stdin]
>> + [--info-only]
>> [--verbose]
>> + [[-z] --stdin | --index-info]
>
> Hmm, this requires | to bind tighter than [] around -z, but that is a bit
> counterintuitive.
>
> Also, you can put -z much earlier, e.g. "update-index -z --add --stdin",
> and your version gives a false impression that we do not allow that.
>
> Writing it as "[-z] [--stdin | --index-info]" would be much easier to
> read, even though it won't convey that -z will be no-op unless we are
> reading from the standard input, either with --stdin or --index-info.
>
> I actually think we can easily lift the "must be at the end" limitation
> from both codepaths.
>
> Move the --stdin codepath to a separate helper like read_index_info(),
> remove the limitation, and add a new limitation that --stdin/--index-info
> can be given only once (as the reader will read thru EOF and the second
> call to the reader won't help us). And do the reading after processing
> all the command line stuff (i.e. move read_index_info() call after the
> option parsing loop), to allow "update-index --stdin --add hello.c" to add
> new paths read from standard input and also hello.c was given from the
> command line.
>
> Wouldn't it make much more sense to spend brain cycles to write and review
> such a patch, rather than documenting an unnecessary limitation?
>
> Hmm?
As the subject suspects, the main intention was to document that -z
applies also to --index-info. The reminder is only falloff while
fixing this inconsistency in the documentation.
So, yes we should have spend more time to remove this limitation that
they need to be the last option.
I will prepare a patch which handles only the -z/--index-info
documentation issue.
Bert
^ permalink raw reply
* [PATCH] i.MX35: Add mx35_revision function to query the silicon revision
From: Sascha Hauer @ 2010-10-08 6:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20101007182137.GU29673@pengutronix.de>
On Thu, Oct 07, 2010 at 08:21:37PM +0200, Uwe Kleine-K?nig wrote:
> Hallo Sascha,
>
> I put you patch in my (still private) tree and suggest the following on
> top of the two. If you're OK I'd squash the hunks into the respective
> patches and send them to you.
Yes, I'm ok.
Here's another one I would like to put ontop of it.
SAscha
[PATCH] ARM i.MX31: use MX3x_ prefixed version of CHIP_REV_x
Also, remove the depreacated symbols from arch/arm/mach-mx3/cpu.c
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
arch/arm/mach-mx3/Makefile | 1 -
arch/arm/mach-mx3/cpu.c | 20 ++++++++++----------
arch/arm/plat-mxc/include/mach/mx3x.h | 15 +--------------
3 files changed, 11 insertions(+), 25 deletions(-)
diff --git a/arch/arm/mach-mx3/Makefile b/arch/arm/mach-mx3/Makefile
index 2bd7bec..8a182d0a 100644
--- a/arch/arm/mach-mx3/Makefile
+++ b/arch/arm/mach-mx3/Makefile
@@ -7,7 +7,6 @@
obj-y := mm.o devices.o cpu.o
CFLAGS_mm.o = -DIMX_NEEDS_DEPRECATED_SYMBOLS
CFLAGS_devices.o = -DIMX_NEEDS_DEPRECATED_SYMBOLS
-CFLAGS_cpu.o = -DIMX_NEEDS_DEPRECATED_SYMBOLS
obj-$(CONFIG_ARCH_MX31) += clock-imx31.o iomux-imx31.o
obj-$(CONFIG_ARCH_MX35) += clock-imx35.o
obj-$(CONFIG_MACH_MX31ADS) += mach-mx31ads.o
diff --git a/arch/arm/mach-mx3/cpu.c b/arch/arm/mach-mx3/cpu.c
index 161dfff..db7af50 100644
--- a/arch/arm/mach-mx3/cpu.c
+++ b/arch/arm/mach-mx3/cpu.c
@@ -25,15 +25,15 @@ struct mx3_cpu_type {
};
static struct mx3_cpu_type mx31_cpu_type[] __initdata = {
- { .srev = 0x00, .name = "i.MX31(L)", .v = "1.0", .rev = CHIP_REV_1_0 },
- { .srev = 0x10, .name = "i.MX31", .v = "1.1", .rev = CHIP_REV_1_1 },
- { .srev = 0x11, .name = "i.MX31L", .v = "1.1", .rev = CHIP_REV_1_1 },
- { .srev = 0x12, .name = "i.MX31", .v = "1.15", .rev = CHIP_REV_1_1 },
- { .srev = 0x13, .name = "i.MX31L", .v = "1.15", .rev = CHIP_REV_1_1 },
- { .srev = 0x14, .name = "i.MX31", .v = "1.2", .rev = CHIP_REV_1_2 },
- { .srev = 0x15, .name = "i.MX31L", .v = "1.2", .rev = CHIP_REV_1_2 },
- { .srev = 0x28, .name = "i.MX31", .v = "2.0", .rev = CHIP_REV_2_0 },
- { .srev = 0x29, .name = "i.MX31L", .v = "2.0", .rev = CHIP_REV_2_0 },
+ { .srev = 0x00, .name = "i.MX31(L)", .v = "1.0", .rev = MX3x_CHIP_REV_1_0 },
+ { .srev = 0x10, .name = "i.MX31", .v = "1.1", .rev = MX3x_CHIP_REV_1_1 },
+ { .srev = 0x11, .name = "i.MX31L", .v = "1.1", .rev = MX3x_CHIP_REV_1_1 },
+ { .srev = 0x12, .name = "i.MX31", .v = "1.15", .rev = MX3x_CHIP_REV_1_1 },
+ { .srev = 0x13, .name = "i.MX31L", .v = "1.15", .rev = MX3x_CHIP_REV_1_1 },
+ { .srev = 0x14, .name = "i.MX31", .v = "1.2", .rev = MX3x_CHIP_REV_1_2 },
+ { .srev = 0x15, .name = "i.MX31L", .v = "1.2", .rev = MX3x_CHIP_REV_1_2 },
+ { .srev = 0x28, .name = "i.MX31", .v = "2.0", .rev = MX3x_CHIP_REV_2_0 },
+ { .srev = 0x29, .name = "i.MX31L", .v = "2.0", .rev = MX3x_CHIP_REV_2_0 },
};
void __init mx31_read_cpu_rev(void)
@@ -41,7 +41,7 @@ void __init mx31_read_cpu_rev(void)
u32 i, srev;
/* read SREV register from IIM module */
- srev = __raw_readl(IO_ADDRESS(IIM_BASE_ADDR + MXC_IIMSREV));
+ srev = __raw_readl(MX31_IO_ADDRESS(MX31_IIM_BASE_ADDR + MXC_IIMSREV));
for (i = 0; i < ARRAY_SIZE(mx31_cpu_type); i++)
if (srev == mx31_cpu_type[i].srev) {
diff --git a/arch/arm/plat-mxc/include/mach/mx3x.h b/arch/arm/plat-mxc/include/mach/mx3x.h
index 581db46..d1bd26d 100644
--- a/arch/arm/plat-mxc/include/mach/mx3x.h
+++ b/arch/arm/plat-mxc/include/mach/mx3x.h
@@ -240,7 +240,7 @@
#define MX3x_PROD_SIGNATURE 0x1 /* For MX31 */
-/* silicon revisions specific to i.MX31 */
+/* silicon revisions specific to i.MX31 and i.MX35 */
#define MX3x_CHIP_REV_1_0 0x10
#define MX3x_CHIP_REV_1_1 0x11
#define MX3x_CHIP_REV_1_2 0x12
@@ -397,19 +397,6 @@ static inline int mx35_revision(void)
#define MXC_INT_EXT_WDOG MX3x_INT_EXT_WDOG
#define MXC_INT_EXT_TV MX3x_INT_EXT_TV
#define PROD_SIGNATURE MX3x_PROD_SIGNATURE
-#define CHIP_REV_1_0 MX3x_CHIP_REV_1_0
-#define CHIP_REV_1_1 MX3x_CHIP_REV_1_1
-#define CHIP_REV_1_2 MX3x_CHIP_REV_1_2
-#define CHIP_REV_1_3 MX3x_CHIP_REV_1_3
-#define CHIP_REV_2_0 MX3x_CHIP_REV_2_0
-#define CHIP_REV_2_1 MX3x_CHIP_REV_2_1
-#define CHIP_REV_2_2 MX3x_CHIP_REV_2_2
-#define CHIP_REV_2_3 MX3x_CHIP_REV_2_3
-#define CHIP_REV_3_0 MX3x_CHIP_REV_3_0
-#define CHIP_REV_3_1 MX3x_CHIP_REV_3_1
-#define CHIP_REV_3_2 MX3x_CHIP_REV_3_2
-#define SYSTEM_REV_MIN MX3x_SYSTEM_REV_MIN
-#define SYSTEM_REV_NUM MX3x_SYSTEM_REV_NUM
#endif
#endif /* ifndef __MACH_MX3x_H__ */
--
1.7.2.3
--
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 |
^ permalink raw reply related
* [PATCH v6 3/3] OMAP: DSS2: OMAPFB: Allow usage of def_vrfb only for omap2,3
From: Guruswamy Senthilvadivu @ 2010-10-08 6:44 UTC (permalink / raw)
To: tomi.valkeinen, hvaibhav, linux-omap, linux-fbdev; +Cc: Senthilvadivu Guruswamy
In-Reply-To: <1286520273-4892-3-git-send-email-svadivu@ti.com>
From: Senthilvadivu Guruswamy <svadivu@ti.com>
VRFB is supported only on OMAP2 and OMAP3 platforms. If VRFB rotation is
not supported by the hardware and the user requests VRFB rotation,
print a warning and ignore the request from the user.
Signed-off-by: Senthilvadivu Guruswamy <svadivu@ti.com>
---
drivers/video/omap2/omapfb/omapfb-main.c | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap2/omapfb/omapfb-main.c b/drivers/video/omap2/omapfb/omapfb-main.c
index bddfca6..fcd9038 100644
--- a/drivers/video/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/omap2/omapfb/omapfb-main.c
@@ -2198,6 +2198,16 @@ static int omapfb_probe(struct platform_device *pdev)
goto err0;
}
+ /* TODO : Replace cpu check with omap_has_vrfb once HAS_FEATURE
+ * available for OMAP2 and OMAP3
+ */
+ if (def_vrfb && !cpu_is_omap24xx() && !cpu_is_omap34xx()) {
+ def_vrfb = 0;
+ dev_warn(&pdev->dev, "VRFB is not supported in this hardware,"
+ "ignoring the module parameter vrfb=y\n");
+ }
+
+
mutex_init(&fbdev->mtx);
fbdev->dev = &pdev->dev;
--
1.6.3.3
^ permalink raw reply related
* [PATCH v6 2/3] OMAP: DSS2: OMAPFB: make VRFB depends on OMAP2,3
From: Guruswamy Senthilvadivu @ 2010-10-08 6:44 UTC (permalink / raw)
To: tomi.valkeinen, hvaibhav, linux-omap, linux-fbdev; +Cc: Senthilvadivu Guruswamy
In-Reply-To: <1286520273-4892-2-git-send-email-svadivu@ti.com>
From: Senthilvadivu Guruswamy <svadivu@ti.com>
config VRFB should depend on ARCH_OMAP2 or ARCH_OMAP3.
Signed-off-by: Senthilvadivu Guruswamy <svadivu@ti.com>
---
drivers/video/omap2/omapfb/Kconfig | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/video/omap2/omapfb/Kconfig b/drivers/video/omap2/omapfb/Kconfig
index 43496d6..65149b2 100644
--- a/drivers/video/omap2/omapfb/Kconfig
+++ b/drivers/video/omap2/omapfb/Kconfig
@@ -3,7 +3,7 @@ menuconfig FB_OMAP2
depends on FB && OMAP2_DSS
select OMAP2_VRAM
- select OMAP2_VRFB
+ select OMAP2_VRFB if ARCH_OMAP2 || ARCH_OMAP3
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
--
1.6.3.3
^ permalink raw reply related
* [PATCH v6 1/3] OMAP: DSS2: OMAPFB: Allow FB_OMAP2 to build without VRFB
From: Guruswamy Senthilvadivu @ 2010-10-08 6:44 UTC (permalink / raw)
To: tomi.valkeinen, hvaibhav, linux-omap, linux-fbdev; +Cc: Senthilvadivu Guruswamy
In-Reply-To: <1286520273-4892-1-git-send-email-svadivu@ti.com>
From: Senthilvadivu Guruswamy <svadivu@ti.com>
FB_OMAP2 can work without VRFB, but currently does not build. Fix this.
Signed-off-by: Senthilvadivu Guruswamy <svadivu@ti.com>
---
arch/arm/plat-omap/include/plat/vrfb.h | 16 ++++++++++++++++
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/vrfb.h b/arch/arm/plat-omap/include/plat/vrfb.h
index d8a03ce..3792bde 100644
--- a/arch/arm/plat-omap/include/plat/vrfb.h
+++ b/arch/arm/plat-omap/include/plat/vrfb.h
@@ -35,6 +35,7 @@ struct vrfb {
bool yuv_mode;
};
+#ifdef CONFIG_OMAP2_VRFB
extern int omap_vrfb_request_ctx(struct vrfb *vrfb);
extern void omap_vrfb_release_ctx(struct vrfb *vrfb);
extern void omap_vrfb_adjust_size(u16 *width, u16 *height,
@@ -47,4 +48,19 @@ extern void omap_vrfb_setup(struct vrfb *vrfb, unsigned long paddr,
extern int omap_vrfb_map_angle(struct vrfb *vrfb, u16 height, u8 rot);
extern void omap_vrfb_restore_context(void);
+#else
+static inline int omap_vrfb_request_ctx(struct vrfb *vrfb) { return 0; }
+static inline void omap_vrfb_release_ctx(struct vrfb *vrfb) {}
+static inline void omap_vrfb_adjust_size(u16 *width, u16 *height,
+ u8 bytespp) {}
+static inline u32 omap_vrfb_min_phys_size(u16 width, u16 height, u8 bytespp)
+ { return 0; }
+static inline u16 omap_vrfb_max_height(u32 phys_size, u16 width, u8 bytespp)
+ { return 0; }
+static inline void omap_vrfb_setup(struct vrfb *vrfb, unsigned long paddr,
+ u16 width, u16 height, unsigned bytespp, bool yuv_mode) {}
+static inline int omap_vrfb_map_angle(struct vrfb *vrfb, u16 height, u8 rot)
+ { return 0; }
+static inline void omap_vrfb_restore_context(void) {}
+#endif
#endif /* __VRFB_H */
--
1.6.3.3
^ permalink raw reply related
* [PATCH v6 0/3] OMAP: DSS2: OMAPFB: Allow FB_OMAP2 to build without VRFB
From: Guruswamy Senthilvadivu @ 2010-10-08 6:44 UTC (permalink / raw)
To: tomi.valkeinen, hvaibhav, linux-omap, linux-fbdev; +Cc: Senthilvadivu Guruswamy
From: Senthilvadivu Guruswamy <svadivu@ti.com>
The changelog till v6 are:
- Address Multi-omap build issue
- Added a check to warn the wrong usage of vrfb
in non-vrfb omap devices.
- The patch subject is as per the naming conventions
- patch 2/3 now has the changes in omap2/omapfb/Kconfig
instead of omap2/Kconfig. The functional effect remains
the same, and the place of implementation is more appropriate.
- Provide details of non-vrfb devices in commit description in patch 3/3
- Removed extra paranthesis in cpu checks
Senthilvadivu Guruswamy (3):
OMAP: DSS2: OMAPFB: Allow FB_OMAP2 to build without VRFB
OMAP: DSS2: OMAPFB: make VRFB depends on OMAP2,3
OMAP: DSS2: OMAPFB: Allow usage of def_vrfb only for omap2,3
arch/arm/plat-omap/include/plat/vrfb.h | 16 ++++++++++++++++
drivers/video/omap2/omapfb/Kconfig | 2 +-
drivers/video/omap2/omapfb/omapfb-main.c | 10 ++++++++++
3 files changed, 27 insertions(+), 1 deletions(-)
^ permalink raw reply
* Re: [PATCH 2/2] davinci: Platform support for OMAP-L137/AM17x NOR flash driver
From: Vitaly Wool @ 2010-10-08 6:44 UTC (permalink / raw)
To: Nori, Sekhar
Cc: davinci-linux-open-source@linux.davincidsp.com, Sergei Shtylyov,
Aleksey Makarov, David Griego, linux-mtd@lists.infradead.org,
Dharmappa, Savinay
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB59302342ADE9D@dbde02.ent.ti.com>
On Fri, Oct 8, 2010 at 5:54 AM, Nori, Sekhar <nsekhar@ti.com> wrote:
> Hi Sergei,
>
> On Thu, Oct 07, 2010 at 20:35:28, Sergei Shtylyov wrote:
>
>> > +static void da830_evm_nor_done(void *data)
>> > +{
>> > + clk_disable(da830_evm_nor.clk);
>> > + clk_put(da830_evm_nor.clk);
>> > + iounmap(da830_evm_nor.latch.addr);
>> > + release_mem_region(DA8XX_AEMIF_CS3_BASE, PAGE_SIZE);
>> > + iounmap(da830_evm_nor.aemif.addr);
>> > + release_mem_region(DA8XX_AEMIF_CTL_BASE, SZ_32K);
>> > +}
>>
>> Why you've changed this function which was useful also for the error cleanup
>> before?
>
> The issues down below aside, I think goto based error handling
> is clearer to follow. Any objections to using goto based
> error handing per-se?
What you're saying just doesn't make sense in this context. Whatever
way of error handling is chosen, it first needs to be correct which is
absolutely not the case here.
~Vitaly
^ permalink raw reply
* Re: system crash at mounting of btrfs
From: Tomasz Chmielewski @ 2010-10-08 6:43 UTC (permalink / raw)
To: linux-btrfs
> I tried it with 3 kernels from the 2.5.35 series.
> My system is a AMD64, so I put one SSD disk as an external drive (USB) to a
> laptop running a 32bit system, it crashed the same at my wanting to mount the
> partition.
>
> This is my config:
> $uname -a
> Linux ubuntu 2.6.35-22-generic #33-Ubuntu SMP Sun Sep 19 20:34:50 UTC 2010 i686
> GNU/Linux
You could try:
http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.36-rc7-maverick/
--
Tomasz Chmielewski
http://wpkg.org
^ permalink raw reply
* RE: [PATCH v3 2/7] spi/mpc8xxx: refactor the common code for SPI/eSPI controller
From: Hu Mingkai-B21284 @ 2010-10-08 6:37 UTC (permalink / raw)
To: Anton Vorontsov
Cc: linuxppc-dev, Gala Kumar-B11780, linux-mtd, Zang Roy-R61911,
spi-devel-general
In-Reply-To: <20101001112212.GA17505@oksana.dev.rtsoft.ru>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQW50b24gVm9yb250c292
IFttYWlsdG86Y2JvdWF0bWFpbHJ1QGdtYWlsLmNvbV0NCj4gU2VudDogRnJpZGF5LCBPY3RvYmVy
IDAxLCAyMDEwIDc6MjIgUE0NCj4gVG86IEh1IE1pbmdrYWktQjIxMjg0DQo+IENjOiBsaW51eHBw
Yy1kZXZAb3psYWJzLm9yZzsgc3BpLWRldmVsLWdlbmVyYWxAbGlzdHMuc291cmNlZm9yZ2UubmV0
OyBsaW51eC0NCj4gbXRkQGxpc3RzLmluZnJhZGVhZC5vcmc7IEdhbGEgS3VtYXItQjExNzgwOyBa
YW5nIFJveS1SNjE5MTENCj4gU3ViamVjdDogUmU6IFtQQVRDSCB2MyAyLzddIHNwaS9tcGM4eHh4
OiByZWZhY3RvciB0aGUgY29tbW9uIGNvZGUgZm9yIFNQSS9lU1BJDQo+IGNvbnRyb2xsZXINCj4g
DQo+IE9uIFRodSwgU2VwIDMwLCAyMDEwIGF0IDA0OjAwOjQxUE0gKzA4MDAsIE1pbmdrYWkgSHUg
d3JvdGU6DQo+IFsuLi5dDQo+ID4gLXN0YXRpYyB2b2lkIG1wYzh4eHhfc3BpX2NoYW5nZV9tb2Rl
KHN0cnVjdCBzcGlfZGV2aWNlICpzcGkpDQo+ID4gK3N0YXRpYyB2b2lkIGZzbF9zcGlfY2hhbmdl
X21vZGUoc3RydWN0IHNwaV9kZXZpY2UgKnNwaSkNCj4gPiAgew0KPiA+ICAJc3RydWN0IG1wYzh4
eHhfc3BpICptc3BpID0gc3BpX21hc3Rlcl9nZXRfZGV2ZGF0YShzcGktPm1hc3Rlcik7DQo+ID4g
IAlzdHJ1Y3Qgc3BpX21wYzh4eHhfY3MgKmNzID0gc3BpLT5jb250cm9sbGVyX3N0YXRlOw0KPiA+
IC0JX19iZTMyIF9faW9tZW0gKm1vZGUgPSAmbXNwaS0+YmFzZS0+bW9kZTsNCj4gPiArCXN0cnVj
dCBmc2xfc3BpX3JlZyAqcmVnX2Jhc2UgPSAoc3RydWN0IGZzbF9zcGlfcmVnICopbXNwaS0+cmVn
X2Jhc2U7DQo+IA0KPiBObyBuZWVkIGZvciB0aGVzZSB0eXBlIGNhc3RzICh0aGUgc2FtZSBpcyBm
b3IgdGhlIHdob2xlIHBhdGNoKS4NCj4gDQoNCkZpeCBpdC4NCg0KVGhhbmtzLA0KTWluZ2thaQ0K
^ permalink raw reply
* RE: [PATCH v3 2/7] spi/mpc8xxx: refactor the common code for SPI/eSPI controller
From: Hu Mingkai-B21284 @ 2010-10-08 6:37 UTC (permalink / raw)
To: Anton Vorontsov
Cc: linuxppc-dev, Gala Kumar-B11780, linux-mtd, Zang Roy-R61911,
spi-devel-general
In-Reply-To: <20101001112212.GA17505@oksana.dev.rtsoft.ru>
> -----Original Message-----
> From: Anton Vorontsov [mailto:cbouatmailru@gmail.com]
> Sent: Friday, October 01, 2010 7:22 PM
> To: Hu Mingkai-B21284
> Cc: linuxppc-dev@ozlabs.org; spi-devel-general@lists.sourceforge.net; linux-
> mtd@lists.infradead.org; Gala Kumar-B11780; Zang Roy-R61911
> Subject: Re: [PATCH v3 2/7] spi/mpc8xxx: refactor the common code for SPI/eSPI
> controller
>
> On Thu, Sep 30, 2010 at 04:00:41PM +0800, Mingkai Hu wrote:
> [...]
> > -static void mpc8xxx_spi_change_mode(struct spi_device *spi)
> > +static void fsl_spi_change_mode(struct spi_device *spi)
> > {
> > struct mpc8xxx_spi *mspi = spi_master_get_devdata(spi->master);
> > struct spi_mpc8xxx_cs *cs = spi->controller_state;
> > - __be32 __iomem *mode = &mspi->base->mode;
> > + struct fsl_spi_reg *reg_base = (struct fsl_spi_reg *)mspi->reg_base;
>
> No need for these type casts (the same is for the whole patch).
>
Fix it.
Thanks,
Mingkai
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply
* RE: [PATCH v3 2/7] spi/mpc8xxx: refactor the common code for SPI/eSPI controller
From: Hu Mingkai-B21284 @ 2010-10-08 6:37 UTC (permalink / raw)
To: Anton Vorontsov
Cc: linuxppc-dev, Gala Kumar-B11780, linux-mtd, Zang Roy-R61911,
spi-devel-general
In-Reply-To: <20101001112212.GA17505@oksana.dev.rtsoft.ru>
> -----Original Message-----
> From: Anton Vorontsov [mailto:cbouatmailru@gmail.com]
> Sent: Friday, October 01, 2010 7:22 PM
> To: Hu Mingkai-B21284
> Cc: linuxppc-dev@ozlabs.org; spi-devel-general@lists.sourceforge.net; linux-
> mtd@lists.infradead.org; Gala Kumar-B11780; Zang Roy-R61911
> Subject: Re: [PATCH v3 2/7] spi/mpc8xxx: refactor the common code for SPI/eSPI
> controller
>
> On Thu, Sep 30, 2010 at 04:00:41PM +0800, Mingkai Hu wrote:
> [...]
> > -static void mpc8xxx_spi_change_mode(struct spi_device *spi)
> > +static void fsl_spi_change_mode(struct spi_device *spi)
> > {
> > struct mpc8xxx_spi *mspi = spi_master_get_devdata(spi->master);
> > struct spi_mpc8xxx_cs *cs = spi->controller_state;
> > - __be32 __iomem *mode = &mspi->base->mode;
> > + struct fsl_spi_reg *reg_base = (struct fsl_spi_reg *)mspi->reg_base;
>
> No need for these type casts (the same is for the whole patch).
>
Fix it.
Thanks,
Mingkai
^ permalink raw reply
* Re: How to modify /etc/network/interfaces file in a OE recipe
From: Frans Meulenbroeks @ 2010-10-08 6:36 UTC (permalink / raw)
To: openembedded-devel
In-Reply-To: <AANLkTinDviTOfaSFktW0iKJPrjsT3QSHWiYLaw4WrX5K@mail.gmail.com>
2010/10/8 Khem Raj <raj.khem@gmail.com>:
> On Thu, Oct 7, 2010 at 3:54 PM, Gary Thomas <gary@mlbassoc.com> wrote:
>> On 10/07/2010 03:11 PM, Elvis Dowson wrote:
>>>
>>> Hi,
>>> Would someone be able to help me with modifying an
>>> omap3-console-image recipe, such that in the final image, the
>>> /etc/network/interfaces file gets edited as follows
>>>
>>> #auto eth0 <- remove # sign ( auto eth0 )
>>> #iface eth0 inet dhcp <- remove # sign ( iface eth0 inet dhcp )
>>> #iface eth1 inet dhcp
>>>
>>> I am using a Gumstix Overo + Chestnut43 expansion board, which has an
>>> inbuilt wired ethernet interface. I have to make this modification manually,
>>> to enable this interface each time. However, if I can modify the OE recipe
>>> somehow to do this it would be great. I know it can be done, but I don't
>>> know where to start and which file to modify.
>>
>> Add the file the way you like it to
>> .../openembedded/recipes/netbase/netbase/overo
>> and rebuild netbase. Use the beagleboard as an example.
>
> or use bblayers and bbappend.
Actually if you use an overlay you can just put your patch file in the
files dir of your overlay.
If I recall correctly files will be first fetched in the FILESPATHPKG
in the overlay before looking in the oe dir (assuming your layer
priorities are ok)
Have fun! Frans
^ permalink raw reply
* Re: [PATCH] cairo_1.10.0: add `glib-2.0-native` to `DEPENDS`
From: Frans Meulenbroeks @ 2010-10-08 6:28 UTC (permalink / raw)
To: openembedded-devel
In-Reply-To: <1286499432.3659.37.camel@mattotaupa>
2010/10/8 Paul Menzel <paulepanter@users.sourceforge.net>:
> Date: Thu, 7 Oct 2010 13:38:44 +0200
>
> `do_compile()` of `cairo_1.10.0.bb` fails with the following error.
>
> […]
> make[4]: Entering directory `/oe/build/angstrom-dev/work/armv7a-angstrom-linux-gnueabi/cairo-1.10.0-r0/cairo-1.10.0/util/cairo-gobject'
> CC libcairo_gobject_la-cairo-gobject-enums.lo
> In file included from cairo-gobject-enums.c:8:
> cairo-gobject.h:44:25: error: glib-object.h: No such file or directory
> In file included from cairo-gobject-enums.c:8:
> cairo-gobject.h:52: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'cairo_gobject_context_get_type'
> cairo-gobject.h:56: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'cairo_gobject_device_get_type'
> cairo-gobject.h:60: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'cairo_gobject_pattern_get_type'
> […]
>
> `glib-object.h` is only in sysroot of the build host.
>
> $ find angstrom-dev/ -name glib-object.h
> angstrom-dev/sysroots/i686-linux/usr/include/glib-2.0/glib-object.h
>
> `cairo_1.8.8.bb` builds fine.
>
> Adding `glib-2.0-native` to `DEPENDS` puts `glib-object.h` also into the sysroot of the target machine and fixes the build.
>
> $ find angstrom-dev/ -name glib-object.h
> angstrom-dev/sysroots/i686-linux/usr/include/glib-2.0/glib-object.h
> angstrom-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/include/glib-2.0/glib-object.h
>
> Build tested with `angstrom-2008.1` for `MACHINE = "beagleboard"`.
>
> Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
> ---
> recipes/cairo/cairo_1.10.0.bb | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/recipes/cairo/cairo_1.10.0.bb b/recipes/cairo/cairo_1.10.0.bb
> index 7530cd1..9859b9c 100644
> --- a/recipes/cairo/cairo_1.10.0.bb
> +++ b/recipes/cairo/cairo_1.10.0.bb
> @@ -1,5 +1,7 @@
> require cairo.inc
>
> +DEPENDS += "glib-2.0-native"
> +
> SRC_URI = "http://cairographics.org/releases/cairo-${PV}.tar.gz;name=cairo \
> "
>
> --
Hm. Personally I'd say glib should put the include file in
angstrom-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/include/glib-2.0
I'd say you need a depend on glib-2.0 not on glib-2.0-native
As i see it, dependencies on native packages should only be needed if
you need a binary from another package to build your package (unless
ofc you are a binary package yourself, in which case you need native
headers)
(and yeah, I know there are several exceptions).
Frans
^ permalink raw reply
* RE: [PATCH v3 3/7] eSPI: add eSPI controller support
From: Hu Mingkai-B21284 @ 2010-10-08 6:35 UTC (permalink / raw)
To: Anton Vorontsov
Cc: linuxppc-dev, Gala Kumar-B11780, linux-mtd, spi-devel-general
In-Reply-To: <20101001112204.GA16783@oksana.dev.rtsoft.ru>
> -----Original Message-----
> From: Anton Vorontsov [mailto:cbouatmailru@gmail.com]
> Sent: Friday, October 01, 2010 7:22 PM
> To: Hu Mingkai-B21284
> Cc: linuxppc-dev@ozlabs.org; spi-devel-general@lists.sourceforge.net; linux-
> mtd@lists.infradead.org; Gala Kumar-B11780
> Subject: Re: [PATCH v3 3/7] eSPI: add eSPI controller support
>
> Hello Mingkai,
>
> There are mostly cosmetic comments down below.
>
> > + /* spin until TX is done */
> > + while (((events = mpc8xxx_spi_read_reg(®_base->event))
> > + & SPIE_NF) == 0)
> > + cpu_relax();
>
> This is dangerous. There's a handy spin_event_timeout() in asm/delay.h.
>
When timeout, can I use return in the interrupt function directly like this?
if (!(events & SPIE_NF)) {
int ret;
/* spin until TX is done */
ret = spin_event_timeout(((events = mpc8xxx_spi_read_reg(
®_base->event)) & SPIE_NF) == 0, 1000, 0);
if (!ret) {
dev_err(mspi->dev, "tired waiting for SPIE_NF\n");
return;
}
}
> > +}
> > +
> > +static const struct of_device_id of_fsl_espi_match[] = {
> > + { .compatible = "fsl,mpc8536-espi" },
> > + {}
> > +};
> > +MODULE_DEVICE_TABLE(of, of_fsl_espi_match);
> > +
> > +static struct of_platform_driver fsl_espi_driver = {
> > + .driver = {
> > + .name = "fsl_espi",
> > + .owner = THIS_MODULE,
> > + .of_match_table = of_fsl_espi_match,
> > + },
> > + .probe = of_fsl_espi_probe,
> > + .remove = __devexit_p(of_fsl_espi_remove),
> > +};
> > +
> > +static int __init fsl_espi_init(void) {
> > + return of_register_platform_driver(&fsl_espi_driver);
> > +}
> > +module_init(fsl_espi_init);
> > +
> > +static void __exit fsl_espi_exit(void) {
> > + of_unregister_platform_driver(&fsl_espi_driver);
> > +}
> > +module_exit(fsl_espi_exit);
> > +
> > +MODULE_AUTHOR("Mingkai Hu");
> > +MODULE_DESCRIPTION("Enhanced Freescale SPI Driver");
>
> This sounds like that this is an enhanced version of the Freescale SPI driver,
> which it is not. ;-)
>
I quoted from the UM, maybe the enhancement is the controller takes over the
CS signal from the HW point view.
I changed all the other code according to your comments.
Thanks,
Mingkai
^ permalink raw reply
* RE: [PATCH v3 3/7] eSPI: add eSPI controller support
From: Hu Mingkai-B21284 @ 2010-10-08 6:35 UTC (permalink / raw)
To: Anton Vorontsov
Cc: linuxppc-dev, Gala Kumar-B11780, linux-mtd, spi-devel-general
In-Reply-To: <20101001112204.GA16783@oksana.dev.rtsoft.ru>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQW50b24gVm9yb250c292
IFttYWlsdG86Y2JvdWF0bWFpbHJ1QGdtYWlsLmNvbV0NCj4gU2VudDogRnJpZGF5LCBPY3RvYmVy
IDAxLCAyMDEwIDc6MjIgUE0NCj4gVG86IEh1IE1pbmdrYWktQjIxMjg0DQo+IENjOiBsaW51eHBw
Yy1kZXZAb3psYWJzLm9yZzsgc3BpLWRldmVsLWdlbmVyYWxAbGlzdHMuc291cmNlZm9yZ2UubmV0
OyBsaW51eC0NCj4gbXRkQGxpc3RzLmluZnJhZGVhZC5vcmc7IEdhbGEgS3VtYXItQjExNzgwDQo+
IFN1YmplY3Q6IFJlOiBbUEFUQ0ggdjMgMy83XSBlU1BJOiBhZGQgZVNQSSBjb250cm9sbGVyIHN1
cHBvcnQNCj4gDQo+IEhlbGxvIE1pbmdrYWksDQo+IA0KPiBUaGVyZSBhcmUgbW9zdGx5IGNvc21l
dGljIGNvbW1lbnRzIGRvd24gYmVsb3cuDQo+IA0KPiA+ICsJCS8qIHNwaW4gdW50aWwgVFggaXMg
ZG9uZSAqLw0KPiA+ICsJCXdoaWxlICgoKGV2ZW50cyA9IG1wYzh4eHhfc3BpX3JlYWRfcmVnKCZy
ZWdfYmFzZS0+ZXZlbnQpKQ0KPiA+ICsJCQkJCSYgU1BJRV9ORikgPT0gMCkNCj4gPiArCQkJY3B1
X3JlbGF4KCk7DQo+IA0KPiBUaGlzIGlzIGRhbmdlcm91cy4gVGhlcmUncyBhIGhhbmR5IHNwaW5f
ZXZlbnRfdGltZW91dCgpIGluIGFzbS9kZWxheS5oLg0KPiANCg0KV2hlbiB0aW1lb3V0LCBjYW4g
SSB1c2UgcmV0dXJuIGluIHRoZSBpbnRlcnJ1cHQgZnVuY3Rpb24gZGlyZWN0bHkgbGlrZSB0aGlz
Pw0KDQppZiAoIShldmVudHMgJiBTUElFX05GKSkgew0KICAgICAgICBpbnQgcmV0Ow0KICAgICAg
ICAvKiBzcGluIHVudGlsIFRYIGlzIGRvbmUgKi8NCiAgICAgICAgcmV0ID0gc3Bpbl9ldmVudF90
aW1lb3V0KCgoZXZlbnRzID0gbXBjOHh4eF9zcGlfcmVhZF9yZWcoDQogICAgICAgICAgICAgICAg
ICAgICAgICAmcmVnX2Jhc2UtPmV2ZW50KSkgJiBTUElFX05GKSA9PSAwLCAxMDAwLCAwKTsNCiAg
ICAgICAgaWYgKCFyZXQpIHsNCiAgICAgICAgICAgICAgICBkZXZfZXJyKG1zcGktPmRldiwgInRp
cmVkIHdhaXRpbmcgZm9yIFNQSUVfTkZcbiIpOw0KICAgICAgICAgICAgICAgIHJldHVybjsNCiAg
ICAgICAgfQ0KfQ0KDQo+ID4gK30NCj4gPiArDQo+ID4gK3N0YXRpYyBjb25zdCBzdHJ1Y3Qgb2Zf
ZGV2aWNlX2lkIG9mX2ZzbF9lc3BpX21hdGNoW10gPSB7DQo+ID4gKwl7IC5jb21wYXRpYmxlID0g
ImZzbCxtcGM4NTM2LWVzcGkiIH0sDQo+ID4gKwl7fQ0KPiA+ICt9Ow0KPiA+ICtNT0RVTEVfREVW
SUNFX1RBQkxFKG9mLCBvZl9mc2xfZXNwaV9tYXRjaCk7DQo+ID4gKw0KPiA+ICtzdGF0aWMgc3Ry
dWN0IG9mX3BsYXRmb3JtX2RyaXZlciBmc2xfZXNwaV9kcml2ZXIgPSB7DQo+ID4gKwkuZHJpdmVy
ID0gew0KPiA+ICsJCS5uYW1lID0gImZzbF9lc3BpIiwNCj4gPiArCQkub3duZXIgPSBUSElTX01P
RFVMRSwNCj4gPiArCQkub2ZfbWF0Y2hfdGFibGUgPSBvZl9mc2xfZXNwaV9tYXRjaCwNCj4gPiAr
CX0sDQo+ID4gKwkucHJvYmUJCT0gb2ZfZnNsX2VzcGlfcHJvYmUsDQo+ID4gKwkucmVtb3ZlCQk9
IF9fZGV2ZXhpdF9wKG9mX2ZzbF9lc3BpX3JlbW92ZSksDQo+ID4gK307DQo+ID4gKw0KPiA+ICtz
dGF0aWMgaW50IF9faW5pdCBmc2xfZXNwaV9pbml0KHZvaWQpIHsNCj4gPiArCXJldHVybiBvZl9y
ZWdpc3Rlcl9wbGF0Zm9ybV9kcml2ZXIoJmZzbF9lc3BpX2RyaXZlcik7DQo+ID4gK30NCj4gPiAr
bW9kdWxlX2luaXQoZnNsX2VzcGlfaW5pdCk7DQo+ID4gKw0KPiA+ICtzdGF0aWMgdm9pZCBfX2V4
aXQgZnNsX2VzcGlfZXhpdCh2b2lkKSB7DQo+ID4gKwlvZl91bnJlZ2lzdGVyX3BsYXRmb3JtX2Ry
aXZlcigmZnNsX2VzcGlfZHJpdmVyKTsNCj4gPiArfQ0KPiA+ICttb2R1bGVfZXhpdChmc2xfZXNw
aV9leGl0KTsNCj4gPiArDQo+ID4gK01PRFVMRV9BVVRIT1IoIk1pbmdrYWkgSHUiKTsNCj4gPiAr
TU9EVUxFX0RFU0NSSVBUSU9OKCJFbmhhbmNlZCBGcmVlc2NhbGUgU1BJIERyaXZlciIpOw0KPiAN
Cj4gVGhpcyBzb3VuZHMgbGlrZSB0aGF0IHRoaXMgaXMgYW4gZW5oYW5jZWQgdmVyc2lvbiBvZiB0
aGUgRnJlZXNjYWxlIFNQSSBkcml2ZXIsDQo+IHdoaWNoIGl0IGlzIG5vdC4gOy0pDQo+IA0KDQpJ
IHF1b3RlZCBmcm9tIHRoZSBVTSwgbWF5YmUgdGhlIGVuaGFuY2VtZW50IGlzIHRoZSBjb250cm9s
bGVyIHRha2VzIG92ZXIgdGhlDQpDUyBzaWduYWwgZnJvbSB0aGUgSFcgcG9pbnQgdmlldy4NCg0K
SSBjaGFuZ2VkIGFsbCB0aGUgb3RoZXIgY29kZSBhY2NvcmRpbmcgdG8geW91ciBjb21tZW50cy4N
Cg0KVGhhbmtzLA0KTWluZ2thaQ0KDQo=
^ permalink raw reply
* Re: system crash at mounting of btrfs
From: Gerhard Kulzer @ 2010-10-08 6:32 UTC (permalink / raw)
To: linux-btrfs
In-Reply-To: <loom.20101007T155351-932@post.gmane.org>
I did an btrfs-image -c 9 dump on one partition, but it generated 142MB of data.
How can I send this?
^ permalink raw reply
* Re: [PATCH 1/4] RDEPENDS -> RDEPENDS_${PN}
From: Frans Meulenbroeks @ 2010-10-08 6:32 UTC (permalink / raw)
To: openembedded-devel
In-Reply-To: <1286399340-15927-2-git-send-email-fransmeulenbroeks@gmail.com>
2010/10/6 Frans Meulenbroeks <fransmeulenbroeks@gmail.com>:
> Signed-off-by: Frans Meulenbroeks <fransmeulenbroeks@gmail.com>
> ---
> classes/cpan-base.bbclass | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/classes/cpan-base.bbclass b/classes/cpan-base.bbclass
> index 379defa..a04f61c 100644
> --- a/classes/cpan-base.bbclass
> +++ b/classes/cpan-base.bbclass
> @@ -5,7 +5,7 @@
> FILES_${PN} += "${libdir}/perl5 ${datadir}/perl5"
>
> DEPENDS += "${@["perl", "perl-native"][(bb.data.inherits_class('native', d))]}"
> -RDEPENDS += "${@["perl", ""][(bb.data.inherits_class('native', d))]}"
> +RDEPENDS_${PN} += "${@["perl", ""][(bb.data.inherits_class('native', d))]}"
>
> # Determine the staged version of perl from the perl configuration file
> def get_perl_version(d):
Aargh. Accidently pushed this patch yesterday with another one.
Thought I'd removed it from my git, but apparently it wasn't.
Propose to keep it like that (and no revert). Let me know if a PR bump
of recipes inheriting this is needed.
Frans.
^ permalink raw reply
* [U-Boot] [PATCH] board/mpl: Remove mpl-specific memory test command
From: "David Müller (ELSOFT AG)" @ 2010-10-08 6:32 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1286509157.20901.13.camel@ptyser-laptop>
Peter Tyser schrieb:
> On Wed, 2010-10-06 at 22:27 +0200, Wolfgang Denk wrote:
>> I think you are right. If you have tiome, please submit patches to
>> remove these, then we will see if anybody cares.
>
> Will do.
I'm currently trying to bring the VCMA9 port in sync with the recently
introduced "ARM relocation support" feature.
Dave
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
Url : http://lists.denx.de/pipermail/u-boot/attachments/20101008/11c0c3bd/attachment.pgp
^ permalink raw reply
* Re: 2.6.36-rc7: kernel panic with SECURITY_TOMOYO=y
From: KOSAKI Motohiro @ 2010-10-08 6:30 UTC (permalink / raw)
To: Tetsuo Handa
Cc: kosaki.motohiro, linux-kernel, takedakn, lists, kawime, jkosina,
linux-security-module
In-Reply-To: <201010080626.o986QJX4002281@www262.sakura.ne.jp>
> From cc7601c18982909987bbb48971acb86a69a3317a Mon Sep 17 00:00:00 2001
> From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> Date: Fri, 8 Oct 2010 14:43:22 +0900
> Subject: [PATCH] TOMOYO: Print URL information before panic().
>
> Configuration files for TOMOYO 2.3 are not compatible with TOMOYO 2.2.
> But current panic() message is too unfriendly and is confusing users.
>
> Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> ---
> security/tomoyo/common.c | 11 ++++++++++-
> 1 files changed, 10 insertions(+), 1 deletions(-)
>
> diff --git a/security/tomoyo/common.c b/security/tomoyo/common.c
> index c668b44..1f0d45a 100644
> --- a/security/tomoyo/common.c
> +++ b/security/tomoyo/common.c
> @@ -2051,13 +2051,22 @@ void tomoyo_check_profile(void)
> const u8 profile = domain->profile;
> if (tomoyo_profile_ptr[profile])
> continue;
> + printk(KERN_ERR "You need to define profile %u before using it.\n",
> + profile);
> + printk(KERN_ERR "Please see http://tomoyo.sourceforge.jp/2.3/ "
> + "for more information.\n");
> panic("Profile %u (used by '%s') not defined.\n",
> profile, domain->domainname->name);
> }
> tomoyo_read_unlock(idx);
> - if (tomoyo_profile_version != 20090903)
> + if (tomoyo_profile_version != 20090903) {
> + printk(KERN_ERR "You need to install userland programs for "
> + "TOMOYO 2.3 and initialize policy configuration.\n");
> + printk(KERN_ERR "Please see http://tomoyo.sourceforge.jp/2.3/ "
> + "for more information.\n");
> panic("Profile version %u is not supported.\n",
> tomoyo_profile_version);
> + }
> printk(KERN_INFO "TOMOYO: 2.3.0\n");
> printk(KERN_INFO "Mandatory Access Control activated.\n");
> }
> --
> 1.7.1
Looks good to me. thanks.
Reviewed-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
^ permalink raw reply
* [U-Boot] [PATCH] include/compiler.h: remove uint typedef for __MACH__
From: Andreas Bießmann @ 2010-10-08 6:30 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20101006211012.49CD6153A7E@gemini.denx.de>
Dear Wolfgang Denk,
Am 06.10.2010 um 23:10 schrieb Wolfgang Denk:
> Dear =?UTF-8?q?Andreas=20Bie=C3=9Fmann?=,
>
> In message <1285429559-44573-1-git-send-email-andreas.devel@googlemail.com> you wrote:
>> ---
>> include/compiler.h | 1 -
>> 1 files changed, 0 insertions(+), 1 deletions(-)
>
> Applied, thanks.
>
> Best regards,
>
> Wolfgang Denk
couldn't find this patch mainline. Where did it go?
regards
Andreas Bie?mann
^ permalink raw reply
* [U-Boot] [PATCH v2] lib/hashtable.c: add CONFIG_ENV_MIN_ENTRIES
From: Andreas Bießmann @ 2010-10-08 6:28 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20101006204731.C597E153A7E@gemini.denx.de>
Dear Wolfgang Denk,
Am 06.10.2010 um 22:47 schrieb Wolfgang Denk:
> Dear =?UTF-8?q?Andreas=20Bie=C3=9Fmann?=,
>
> In message <1285966262-73388-1-git-send-email-andreas.devel@googlemail.com> you wrote:
>> lib/hashtable.c | 12 ++++++++----
>> 1 files changed, 8 insertions(+), 4 deletions(-)
>
> Applied, thanks.
>
> Best regards,
>
> Wolfgang Denk
couldn't find this patch mainline. Where did it go?
regards
Andreas Bie?mann
^ permalink raw reply
* [Buildroot] [Bug 2677] introducing util-linux-ng as replacement for util-linux
From: bugzilla at busybox.net @ 2010-10-08 6:28 UTC (permalink / raw)
To: buildroot
In-Reply-To: <bug-2677-163@https.bugs.busybox.net/>
https://bugs.busybox.net/show_bug.cgi?id=2677
Ossy <marcus.osdoba@googlemail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|unassigned at buildroot.uclibc |marcus.osdoba at googlemail.co
|.org |m
--
Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
^ 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.