* [PATCH] virt: Revert only update macaddr cache when capture dhcp ACK pkt
From: Lucas Meneghel Rodrigues @ 2011-10-24 16:54 UTC (permalink / raw)
To: autotest; +Cc: kvm
Revert commit d9bab5bef598b4b415d004eb62e9cd32c3243565, that changes
how the macaddr cache is updated. This patch brought a lot of
regressions on our internal tests, so it'll be dropped until a possibly
safer version of the fix is proposed.
Signed-off-by: Lucas Meneghel Rodrigues <lmr@redhat.com>
---
client/virt/virt_env_process.py | 10 ++--------
1 files changed, 2 insertions(+), 8 deletions(-)
diff --git a/client/virt/virt_env_process.py b/client/virt/virt_env_process.py
index a1ec07a..25285b8 100644
--- a/client/virt/virt_env_process.py
+++ b/client/virt/virt_env_process.py
@@ -403,20 +403,14 @@ def _update_address_cache(address_cache, line):
address_cache["last_seen"] = matches[0]
if re.search("Client.Ethernet.Address", line, re.IGNORECASE):
matches = re.findall(r"\w*:\w*:\w*:\w*:\w*:\w*", line)
- if matches:
- address_cache["last_mac"] = matches[0]
- if re.search("DHCP-Message", line, re.IGNORECASE):
- matches = re.findall(r"ACK", line)
- if matches and (address_cache.get("last_seen") and
- address_cache.get("last_mac")):
- mac_address = address_cache.get("last_mac").lower()
+ if matches and address_cache.get("last_seen"):
+ mac_address = matches[0].lower()
if time.time() - address_cache.get("time_%s" % mac_address, 0) > 5:
logging.debug("(address cache) Adding cache entry: %s ---> %s",
mac_address, address_cache.get("last_seen"))
address_cache[mac_address] = address_cache.get("last_seen")
address_cache["time_%s" % mac_address] = time.time()
del address_cache["last_seen"]
- del address_cache["last_mac"]
def _take_screendumps(test, params, env):
--
1.7.7
^ permalink raw reply related
* Re: BUG at fs/inode.c
From: Yehuda Sadeh Weinraub @ 2011-10-24 16:51 UTC (permalink / raw)
To: Amon Ott; +Cc: ceph-devel@vger.kernel.org
In-Reply-To: <201110241239.13157.a.ott@m-privacy.de>
On Mon, Oct 24, 2011 at 3:39 AM, Amon Ott <a.ott@m-privacy.de> wrote:
> Hi folks,
>
> we have hit a kernel bug with current ceph-client master (commit
> a2742a09568f81315e0f30021f29f14e7cd3924b), which I assume to be a Ceph bug.
Is it easily reproducible? What's the scenario?
>
> Kernel is x86-32, Ceph is running on a two node cluster over ext4. The kernel
> traces are attached, the system dies shortly after these messages. The bug is
> reproducable. I have not found anything useful in ceph bug tracker when
> searching for "fs/inode.c".
How many mds servers?
>
> Around fs/inode.c line 1375 mentioned in the trace is the iput() function:
> void iput(struct inode *inode)
> {
> if (inode) {
> BUG_ON(inode->i_state & I_CLEAR);
>
> if (atomic_dec_and_lock(&inode->i_count, &inode->i_lock))
> iput_final(inode);
> }
> }
>
> So inode->i_state seems to be incorrect when iput() is called, maybe a double
> call to iput() or a missing iget() somewhere. Is this really a Ceph bug or
> have I messed up our kernel code when merging patches?
>
What patches?
Also, the client logs could help shedding a light on the issue. You
should have dynamic debugging turned on (CONFIG_DYNAMIC_DEBUG), and
something along the lines of:
# mount -t debugfs none /sys/kernel/debug
# echo 'module ceph +p' > /sys/kernel/debug/dynamic_debug/control
# echo 'module libceph +p' > /sys/kernel/debug/dynamic_debug/control
Thanks,
Yehuda
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/2] drm/ttm: add a way to bo_wait for either the last read or last write
From: Thomas Hellstrom @ 2011-10-24 16:47 UTC (permalink / raw)
To: Marek Olšák; +Cc: dri-devel
In-Reply-To: <CAAxE2A6c5KoHDrpJcMPbZvvMSbFA9tkQ4yCHfbsoo8NntoOgPQ@mail.gmail.com>
On 10/24/2011 06:42 PM, Marek Olšák wrote:
> On Sat, Oct 8, 2011 at 1:32 PM, Thomas Hellstrom<thomas@shipmail.org> wrote:
>
>> On 10/08/2011 01:27 PM, Ville Syrjälä wrote:
>>
>>> On Sat, Oct 08, 2011 at 01:10:13PM +0200, Thomas Hellstrom wrote:
>>>
>>>
>>>> On 10/08/2011 12:26 PM, Ville Syrjälä wrote:
>>>>
>>>>
>>>>> On Fri, Oct 07, 2011 at 10:58:13AM +0200, Thomas Hellstrom wrote:
>>>>>
>>>>>
>>>>>
>>>>>> Oh, and one more style comment below:
>>>>>>
>>>>>> On 08/07/2011 10:39 PM, Marek Olšák wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> +enum ttm_buffer_usage {
>>>>>>> + TTM_USAGE_READ = 1,
>>>>>>> + TTM_USAGE_WRITE = 2,
>>>>>>> + TTM_USAGE_READWRITE = TTM_USAGE_READ | TTM_USAGE_WRITE
>>>>>>> +};
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> Please don't use enums for bit operations.
>>>>>>
>>>>>>
>>>>>>
>>>>> Now I'm curious. Why not?
>>>>>
>>>>>
>>>>>
>>>>>
>>>> Because it's inconsistent with how flags are defined in the rest of the
>>>> TTM module.
>>>>
>>>>
>>> Ah OK. I was wondering if there's some subtle technical issue involved.
>>> I've recently gotten to the habit of using enums for pretty much all
>>> constants. Just easier on the eye IMHO, and avoids cpp output from
>>> looking like number soup.
>>>
>>>
>>>
>> Yes, there are a number of advantages, including symbolic debugger output.
>> If we had flag enums that enumerated 1, 2, 4, 8 etc. I'd feel motivated to
>> move
>> all TTM definitions over.
>>
> I don't think that how it is enumerated matters in any way. What I
> like about enums, besides what has already been mentioned, is that it
> adds a self-documentation in the code. Compare:
>
> void ttm_set_bo_flags(unsigned flags);
>
> And:
>
> void ttm_set_bo_flags(enum ttm_bo_flags flags);
>
> The latter is way easier to understand for somebody who doesn't know
> the code and wants to implement his first patch. With the latter, it's
> clear at first glance what are the valid values for "flags", because
> you can just search for "enum ttm_bo_flags".
>
> I will change the enum to defines for the sake of following your code
> style convention, but it's an unreasonable convention to say the
> least.
>
> Marek
>
I'm not going to argue against this, because you're probably right.
The important thing is that we get the fix in with or without enums.
Thanks,
Thomas
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Time for a release of 1.14.0?
From: Richard Purdie @ 2011-10-24 16:40 UTC (permalink / raw)
To: bitbake-devel
Hi,
This is just a heads up that I think its time we had a release. Various
factors (including but not limited to my push access to the repo being
broken atm) have meant I've run out of time before ELC-E so this will
likely happen at the start of next week unless there are major
objections.
Cheers,
Richard
^ permalink raw reply
* [U-Boot] [PATCH 4/5] serial: reduce include platform file for marvell chip
From: Albert ARIBAUD @ 2011-10-24 16:46 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1317565013-22438-5-git-send-email-leiwen@marvell.com>
Hi all,
Le 02/10/2011 16:16, Lei Wen a ?crit :
> Build pass with following config:
> dkb_config
> aspenite_config
> edminiv2_config
> openrd_ultimate_config
> sheevaplug_config
> mv88f6281gtw_ge_config
> rd6281a_config
> guruplug_config
> km_kirkwood_config
>
> Signed-off-by: Lei Wen<leiwen@marvell.com>
> ---
> drivers/serial/serial.c | 9 ---------
> 1 files changed, 0 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/serial/serial.c b/drivers/serial/serial.c
> index 0d56e78..0d6ad62 100644
> --- a/drivers/serial/serial.c
> +++ b/drivers/serial/serial.c
> @@ -28,15 +28,6 @@
> #ifdef CONFIG_NS87308
> #include<ns87308.h>
> #endif
> -#ifdef CONFIG_KIRKWOOD
> -#include<asm/arch/kirkwood.h>
> -#elif defined(CONFIG_ORION5X)
> -#include<asm/arch/orion5x.h>
> -#elif defined(CONFIG_ARMADA100)
> -#include<asm/arch/armada100.h>
> -#elif defined(CONFIG_PANTHEON)
> -#include<asm/arch/pantheon.h>
> -#endif
>
> #if defined (CONFIG_SERIAL_MULTI)
> #include<serial.h>
This breaks ED Mini V2 (orion5x) with the following message:
serial.c:65: error: 'ORION5X_UART0_BASE' undeclared here (not in a function)
serial.c: In function 'calc_divisor':
serial.c:152: error: 'CONFIG_SYS_TCLK' undeclared (first use in this
function)
serial.c:152: error: (Each undeclared identifier is reported only once
serial.c:152: error: for each function it appears in.)
Lei Wen, please provide a patch for orion5x as you provided for armada,
pantheon and kirkwood.
Amicalement,
--
Albert.
^ permalink raw reply
* Re: 2.6.38.8 kernel bug in XFS or megaraid driver with heavy I/O load
From: Michael Monnerie @ 2011-10-24 16:45 UTC (permalink / raw)
To: xfs; +Cc: Christoph Hellwig, aradford, linux-kernel, jesper
In-Reply-To: <e78a7c38af135cee4b742c99ecd1c011.squirrel@shrek.krogh.cc>
[-- Attachment #1.1: Type: Text/Plain, Size: 853 bytes --]
On Montag, 17. Oktober 2011 jesper@krogh.cc wrote:
> Over the weekend, we have run memtest for 4 hours (50% of the
> complete tests according to memtest) and it didnt find anything.
This is a bit OT, but you *must* run at least one full loop of memtest
in order to have significant output. I've had PCs that only broke on
test 7, and sometimes even a PC could run 2-3 loops before a bad bit was
found on the 4th loop or so. Only if there's a nasty error, like a
physically broken mainboard, you'll gets errors quickly.
Despite that, I think your problem is not memory based, as you said you
use ECC, and I'd believe you've turned on background scrubbing.
--
mit freundlichen Grüssen,
Michael Monnerie, Ing. BSc
it-management Internet Services: Protéger
http://proteger.at [gesprochen: Prot-e-schee]
Tel: +43 660 / 415 6531
[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
[-- Attachment #2: Type: text/plain, Size: 121 bytes --]
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply
* [U-Boot] [PATCH] mmc: access mxcmmc from mx31 boards
From: Helmut Raiger @ 2011-10-24 16:45 UTC (permalink / raw)
To: u-boot
This patch modifies mxcmmc.c to be used
not only by i.MX27 but also by i.MX31 boards.
Both use the same SD controller, but have different
clock set-ups.
The clock access was renamed to imx_get_mmcclk() to
allow both architectures to provide their respective
clock. Pins, base address and prototypes for board_init_mmc()
are provided.
Signed-off-by: Helmut Raiger <helmut.raiger@hale.at>
---
arch/arm/cpu/arm1136/mx31/generic.c | 5 +++++
arch/arm/include/asm/arch-mx27/clock.h | 1 +
arch/arm/include/asm/arch-mx31/clock.h | 1 +
arch/arm/include/asm/arch-mx31/imx-regs.h | 11 +++++++++++
arch/arm/include/asm/arch-mx31/sys_proto.h | 3 ++-
drivers/mmc/mxcmmc.c | 8 +++-----
6 files changed, 23 insertions(+), 6 deletions(-)
diff --git a/arch/arm/cpu/arm1136/mx31/generic.c b/arch/arm/cpu/arm1136/mx31/generic.c
index 7ab5631..3008099 100644
--- a/arch/arm/cpu/arm1136/mx31/generic.c
+++ b/arch/arm/cpu/arm1136/mx31/generic.c
@@ -99,6 +99,11 @@ u32 imx_get_uartclk(void)
return mxc_get_clock(MXC_UART_CLK);
}
+u32 imx_get_mmcclk(void)
+{
+ return mxc_get_clock(MXC_IPG_PERCLK);
+}
+
void mx31_gpio_mux(unsigned long mode)
{
unsigned long reg, shift, tmp;
diff --git a/arch/arm/include/asm/arch-mx27/clock.h b/arch/arm/include/asm/arch-mx27/clock.h
index 7e9c7aa..2c078d5 100644
--- a/arch/arm/include/asm/arch-mx27/clock.h
+++ b/arch/arm/include/asm/arch-mx27/clock.h
@@ -38,5 +38,6 @@ ulong imx_get_ahbclk(void);
#define imx_get_uartclk imx_get_perclk1
#define imx_get_fecclk imx_get_ahbclk
+#define imx_get_mmcclk imx_get_perclk2
#endif /* __ASM_ARCH_CLOCK_H */
diff --git a/arch/arm/include/asm/arch-mx31/clock.h b/arch/arm/include/asm/arch-mx31/clock.h
index 0270d96..c420d63 100644
--- a/arch/arm/include/asm/arch-mx31/clock.h
+++ b/arch/arm/include/asm/arch-mx31/clock.h
@@ -34,6 +34,7 @@ enum mxc_clock {
unsigned int mxc_get_clock(enum mxc_clock clk);
extern u32 imx_get_uartclk(void);
+extern u32 imx_get_mmcclk(void);
extern void mx31_gpio_mux(unsigned long mode);
extern void mx31_set_pad(enum iomux_pins pin, u32 config);
diff --git a/arch/arm/include/asm/arch-mx31/imx-regs.h b/arch/arm/include/asm/arch-mx31/imx-regs.h
index f7a39f1..448a2c8 100644
--- a/arch/arm/include/asm/arch-mx31/imx-regs.h
+++ b/arch/arm/include/asm/arch-mx31/imx-regs.h
@@ -646,6 +646,13 @@ struct esdc_regs {
#define MUX_CTL_CSPI3_SPI_RDY 0x0e
#define MUX_CTL_CSPI3_MOSI 0x13
+#define MUX_CTL_SD1_DATA1 0x18
+#define MUX_CTL_SD1_DATA2 0x19
+#define MUX_CTL_SD1_DATA3 0x1a
+#define MUX_CTL_SD1_CMD 0x1d
+#define MUX_CTL_SD1_CLK 0x1e
+#define MUX_CTL_SD1_DATA0 0x1f
+
#define MUX_CTL_USBH2_DATA1 0x40
#define MUX_CTL_USBH2_DIR 0x44
#define MUX_CTL_USBH2_STP 0x45
@@ -792,6 +799,10 @@ struct esdc_regs {
*/
#define NFC_BASE_ADDR 0xB8000000
+/* SD card controller */
+#define SDHC1_BASE_ADDR 0x50004000
+#define SDHC2_BASE_ADDR 0x50008000
+
/*
* Internal RAM (16KB)
*/
diff --git a/arch/arm/include/asm/arch-mx31/sys_proto.h b/arch/arm/include/asm/arch-mx31/sys_proto.h
index 7600303..bdce074 100644
--- a/arch/arm/include/asm/arch-mx31/sys_proto.h
+++ b/arch/arm/include/asm/arch-mx31/sys_proto.h
@@ -31,5 +31,6 @@ struct mxc_weimcs {
};
void mxc_setup_weimcs(int cs, const struct mxc_weimcs *weimcs);
-
+/* for mx27 in mxcmmc.h, but another file for a single prototype ? */
+int mxc_mmc_init(bd_t *bis);
#endif
diff --git a/drivers/mmc/mxcmmc.c b/drivers/mmc/mxcmmc.c
index ab1fc82..fbceb46 100644
--- a/drivers/mmc/mxcmmc.c
+++ b/drivers/mmc/mxcmmc.c
@@ -25,9 +25,7 @@
#include <mmc.h>
#include <asm/errno.h>
#include <asm/io.h>
-#ifdef CONFIG_MX27
#include <asm/arch/clock.h>
-#endif
#define DRIVER_NAME "mxc-mmc"
@@ -422,7 +420,7 @@ static void mxcmci_set_clk_rate(struct mxcmci_host *host, unsigned int clk_ios)
{
unsigned int divider;
int prescaler = 0;
- unsigned long clk_in = imx_get_perclk2();
+ unsigned long clk_in = imx_get_mmcclk();
while (prescaler <= 0x800) {
for (divider = 1; divider <= 0xF; divider++) {
@@ -508,8 +506,8 @@ static int mxcmci_initialize(bd_t *bis)
mmc->voltages = MMC_VDD_32_33 | MMC_VDD_33_34;
- mmc->f_min = imx_get_perclk2() >> 7;
- mmc->f_max = imx_get_perclk2() >> 1;
+ mmc->f_min = imx_get_mmcclk() >> 7;
+ mmc->f_max = imx_get_mmcclk() >> 1;
mmc->b_max = 0;
--
1.7.4.4
--
Scanned by MailScanner.
^ permalink raw reply related
* Re: [PATCH-v2] ib_srpt: Initial SRP Target merge for v3.2-rc1
From: Bart Van Assche @ 2011-10-24 16:45 UTC (permalink / raw)
To: Nicholas A. Bellinger
Cc: linux-rdma, Roland Dreier, Christoph Hellwig, Vu Pham,
David Dillow
In-Reply-To: <1319435841-19046-1-git-send-email-nab-IzHhD5pYlfBP7FQvKIMDCQ@public.gmane.org>
On Mon, Oct 24, 2011 at 7:57 AM, Nicholas A. Bellinger
<nab-IzHhD5pYlfBP7FQvKIMDCQ@public.gmane.org> wrote:
> This v2 patch adds the kernel module ib_srpt SCSI RDMA Protocol (SRP) target
> implementation conforming to the SRP r16a specification for the mainline
> drivers/target infrastructure.
>
> This driver was originally developed by Vu Pham and has been optimized by
> Bart Van Assche and merged into upstream LIO based on his srpt-lio-4.1 branch.
> This patch is made against the current pending target-core changes for
> v3.2-rc1, the full tree is available here:
Maybe you remember that the reason why I developed this patch was to
be able to run performance measurements ? The following changes are
necessary to convert this patch into a robust kernel driver:
- Handle the case where the last WQE event arrives before the
corresponding queue pair is reset (r3870 in the SCST SVN repo).
- Handle IB completion timeouts. Although the InfiniBand Architecture
Manual specifies that a HCA must generate an error completion for each
pending work item when a queue pair reset is issued, an important
class of HCAs doesn't do this (that includes the HCA in your test
setup). In the SCST version of this driver such timeouts are handled
by the function srpt_pending_cmd_timeout().
Both issues mentioned above can lead to sessions not being cleaned up
properly and hence all future logins from the initiator associated
with that session to be blocked.
Bart.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 0/2] Improve usability of checksums
From: Richard Purdie @ 2011-10-24 16:38 UTC (permalink / raw)
To: Joshua Lock; +Cc: bitbake-devel
In-Reply-To: <cover.1318352470.git.josh@linux.intel.com>
On Tue, 2011-10-11 at 10:07 -0700, Joshua Lock wrote:
> I'd heard some complaints around the usability of checksums and, having done
> some recipe work recently, must agree with them.
> This series ams to make using checksums less intrusive by:
>
> a) Removing the requirement that if one type of checksum is defined the other
> must be too.
> b) Reporting all sum mismatches at once
> c) Enabling sums to be defined as a parameter of a SRC_URI
>
> Regards,
> Joshua
>
> The following changes since commit dca46cc2e1c75b6add2c4801e2994a4812745f5b:
>
> fetch2: Export additional variables to the fetchers (2011-10-05 14:23:16 +0100)
>
> are available in the git repository at:
> git://github.com/incandescant/bitbake checksum
> https://github.com/incandescant/bitbake/tree/checksum
>
> Joshua Lock (2):
> fetch2: improve usability of checksums
> fetch2: enable checksum definition as SRC_URI parameter
Merged to master (or will be when I can actually push the changes).
Cheers,
Richard
^ permalink raw reply
* [U-Boot] [PATCH v2 2/2] mx51evk: Add RTC support
From: Fabio Estevam @ 2011-10-24 16:44 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1319474656-12172-1-git-send-email-fabio.estevam@freescale.com>
MX51EVK has a MC13892 PMIC. Add RTC support.
Tested via 'date' command that reads the PMIC RTC registers:
MX51EVK U-Boot > date
Date: 1970-01-01 (Thursday) Time: 0:40:35
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
---
Changes since v1:
- No changes
include/configs/mx51evk.h | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/include/configs/mx51evk.h b/include/configs/mx51evk.h
index 2c449b8..67b5f0b 100644
--- a/include/configs/mx51evk.h
+++ b/include/configs/mx51evk.h
@@ -79,6 +79,7 @@
#define CONFIG_FSL_PMIC_CLK 2500000
#define CONFIG_FSL_PMIC_MODE (SPI_MODE_0 | SPI_CS_HIGH)
#define CONFIG_FSL_PMIC_BITLEN 32
+#define CONFIG_RTC_MC13XXX
/*
* MMC Configs
@@ -124,6 +125,8 @@
#undef CONFIG_CMD_IMLS
+#define CONFIG_CMD_DATE
+
#define CONFIG_BOOTDELAY 3
#define CONFIG_ETHPRIME "FEC0"
--
1.6.0.4
^ permalink raw reply related
* [U-Boot] [PATCH v2 1/2] rtc: Make mc13783-rtc driver generic
From: Fabio Estevam @ 2011-10-24 16:44 UTC (permalink / raw)
To: u-boot
Rename mc13783-rtc so that it can be used for both MC13783 and MC13892 PMICs.
efikamx board, for example, does use a MC13892 PMIC, but the RTC selection is currently made as:
#define CONFIG_RTC_MC13783
,which is not very obvious.
Let the MC13783 and MC13892 RTC be selected by:
#define CONFIG_RTC_MC13XXX
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
---
Changes since v1:
- Properly handle the file rename via git.
README | 2 +-
drivers/rtc/Makefile | 2 +-
drivers/rtc/{mc13783-rtc.c => mc13xxx-rtc.c} | 0
include/configs/efikamx.h | 2 +-
include/configs/imx31_litekit.h | 2 +-
include/configs/mx31ads.h | 2 +-
include/configs/mx31pdk.h | 2 +-
include/configs/qong.h | 2 +-
include/configs/vision2.h | 2 +-
9 files changed, 8 insertions(+), 8 deletions(-)
rename drivers/rtc/{mc13783-rtc.c => mc13xxx-rtc.c} (100%)
diff --git a/README b/README
index eb9ade9..1e20452 100644
--- a/README
+++ b/README
@@ -841,7 +841,7 @@ The following options need to be configured:
CONFIG_RTC_MPC8xx - use internal RTC of MPC8xx
CONFIG_RTC_PCF8563 - use Philips PCF8563 RTC
- CONFIG_RTC_MC13783 - use MC13783 RTC
+ CONFIG_RTC_MC13XXX - use MC13783 or MC13892 RTC
CONFIG_RTC_MC146818 - use MC146818 RTC
CONFIG_RTC_DS1307 - use Maxim, Inc. DS1307 RTC
CONFIG_RTC_DS1337 - use Maxim, Inc. DS1337 RTC
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index df440c6..a16f590 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -50,7 +50,7 @@ COBJS-$(CONFIG_RTC_M41T62) += m41t62.o
COBJS-$(CONFIG_RTC_M41T94) += m41t94.o
COBJS-$(CONFIG_RTC_M48T35A) += m48t35ax.o
COBJS-$(CONFIG_RTC_MAX6900) += max6900.o
-COBJS-$(CONFIG_RTC_MC13783) += mc13783-rtc.o
+COBJS-$(CONFIG_RTC_MC13XXX) += mc13xxx-rtc.o
COBJS-$(CONFIG_RTC_MC146818) += mc146818.o
COBJS-$(CONFIG_MCFRTC) += mcfrtc.o
COBJS-$(CONFIG_RTC_MK48T59) += mk48t59.o
diff --git a/drivers/rtc/mc13783-rtc.c b/drivers/rtc/mc13xxx-rtc.c
similarity index 100%
rename from drivers/rtc/mc13783-rtc.c
rename to drivers/rtc/mc13xxx-rtc.c
diff --git a/include/configs/efikamx.h b/include/configs/efikamx.h
index 7e4b424..68bede9 100644
--- a/include/configs/efikamx.h
+++ b/include/configs/efikamx.h
@@ -132,7 +132,7 @@
#define CONFIG_FSL_PMIC_CLK 25000000
#define CONFIG_FSL_PMIC_MODE (SPI_MODE_0 | SPI_CS_HIGH)
#define CONFIG_FSL_PMIC_BITLEN 32
-#define CONFIG_RTC_MC13783
+#define CONFIG_RTC_MC13XXX
#endif
/*
diff --git a/include/configs/imx31_litekit.h b/include/configs/imx31_litekit.h
index 89e71c0..1455ea2 100644
--- a/include/configs/imx31_litekit.h
+++ b/include/configs/imx31_litekit.h
@@ -81,7 +81,7 @@
#define CONFIG_FSL_PMIC_CLK 1000000
#define CONFIG_FSL_PMIC_MODE (SPI_MODE_0 | SPI_CS_HIGH)
#define CONFIG_FSL_PMIC_BITLEN 32
-#define CONFIG_RTC_MC13783
+#define CONFIG_RTC_MC13XXX
/* allow to overwrite serial and ethaddr */
#define CONFIG_ENV_OVERWRITE
diff --git a/include/configs/mx31ads.h b/include/configs/mx31ads.h
index c9d80ef..7e011ae 100644
--- a/include/configs/mx31ads.h
+++ b/include/configs/mx31ads.h
@@ -78,7 +78,7 @@
#define CONFIG_FSL_PMIC_CLK 1000000
#define CONFIG_FSL_PMIC_MODE (SPI_MODE_0 | SPI_CS_HIGH)
#define CONFIG_FSL_PMIC_BITLEN 32
-#define CONFIG_RTC_MC13783
+#define CONFIG_RTC_MC13XXX
/* allow to overwrite serial and ethaddr */
#define CONFIG_ENV_OVERWRITE
diff --git a/include/configs/mx31pdk.h b/include/configs/mx31pdk.h
index b72f30b..9d64827 100644
--- a/include/configs/mx31pdk.h
+++ b/include/configs/mx31pdk.h
@@ -79,7 +79,7 @@
#define CONFIG_FSL_PMIC_CLK 1000000
#define CONFIG_FSL_PMIC_MODE (SPI_MODE_0 | SPI_CS_HIGH)
#define CONFIG_FSL_PMIC_BITLEN 32
-#define CONFIG_RTC_MC13783
+#define CONFIG_RTC_MC13XXX
/* allow to overwrite serial and ethaddr */
#define CONFIG_ENV_OVERWRITE
diff --git a/include/configs/qong.h b/include/configs/qong.h
index 4820914..4409186 100644
--- a/include/configs/qong.h
+++ b/include/configs/qong.h
@@ -58,7 +58,7 @@
#define CONFIG_MXC_SPI
#define CONFIG_DEFAULT_SPI_BUS 1
#define CONFIG_DEFAULT_SPI_MODE (SPI_MODE_0 | SPI_CS_HIGH)
-#define CONFIG_RTC_MC13783
+#define CONFIG_RTC_MC13XXX
#define CONFIG_PMIC
#define CONFIG_PMIC_SPI
diff --git a/include/configs/vision2.h b/include/configs/vision2.h
index a2a9f3f..5a4cd66 100644
--- a/include/configs/vision2.h
+++ b/include/configs/vision2.h
@@ -95,7 +95,7 @@
#define CONFIG_FSL_PMIC_CLK 2500000
#define CONFIG_FSL_PMIC_MODE SPI_MODE_0
#define CONFIG_FSL_PMIC_BITLEN 32
-#define CONFIG_RTC_MC13783
+#define CONFIG_RTC_MC13XXX
/*
* MMC Configs
--
1.6.0.4
^ permalink raw reply related
* Re: [PATCH 1/2] drm/ttm: add a way to bo_wait for either the last read or last write
From: Marek Olšák @ 2011-10-24 16:42 UTC (permalink / raw)
To: Thomas Hellstrom; +Cc: dri-devel
In-Reply-To: <4E9034E7.8070701@shipmail.org>
On Sat, Oct 8, 2011 at 1:32 PM, Thomas Hellstrom <thomas@shipmail.org> wrote:
> On 10/08/2011 01:27 PM, Ville Syrjälä wrote:
>>
>> On Sat, Oct 08, 2011 at 01:10:13PM +0200, Thomas Hellstrom wrote:
>>
>>>
>>> On 10/08/2011 12:26 PM, Ville Syrjälä wrote:
>>>
>>>>
>>>> On Fri, Oct 07, 2011 at 10:58:13AM +0200, Thomas Hellstrom wrote:
>>>>
>>>>
>>>>>
>>>>> Oh, and one more style comment below:
>>>>>
>>>>> On 08/07/2011 10:39 PM, Marek Olšák wrote:
>>>>>
>>>>>
>>>>>>
>>>>>> +enum ttm_buffer_usage {
>>>>>> + TTM_USAGE_READ = 1,
>>>>>> + TTM_USAGE_WRITE = 2,
>>>>>> + TTM_USAGE_READWRITE = TTM_USAGE_READ | TTM_USAGE_WRITE
>>>>>> +};
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> Please don't use enums for bit operations.
>>>>>
>>>>>
>>>>
>>>> Now I'm curious. Why not?
>>>>
>>>>
>>>>
>>>
>>> Because it's inconsistent with how flags are defined in the rest of the
>>> TTM module.
>>>
>>
>> Ah OK. I was wondering if there's some subtle technical issue involved.
>> I've recently gotten to the habit of using enums for pretty much all
>> constants. Just easier on the eye IMHO, and avoids cpp output from
>> looking like number soup.
>>
>>
>
> Yes, there are a number of advantages, including symbolic debugger output.
> If we had flag enums that enumerated 1, 2, 4, 8 etc. I'd feel motivated to
> move
> all TTM definitions over.
I don't think that how it is enumerated matters in any way. What I
like about enums, besides what has already been mentioned, is that it
adds a self-documentation in the code. Compare:
void ttm_set_bo_flags(unsigned flags);
And:
void ttm_set_bo_flags(enum ttm_bo_flags flags);
The latter is way easier to understand for somebody who doesn't know
the code and wants to implement his first patch. With the latter, it's
clear at first glance what are the valid values for "flags", because
you can just search for "enum ttm_bo_flags".
I will change the enum to defines for the sake of following your code
style convention, but it's an unreasonable convention to say the
least.
Marek
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* [Buildroot] [RFC] Slides "Using Buildroot for real projects"
From: Yann E. MORIN @ 2011-10-24 16:42 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20111024173250.7e598d6f@skate>
Thomas, All,
On Monday 24 October 2011 17:32:50 Thomas Petazzoni wrote:
> Le Sun, 23 Oct 2011 14:37:55 +0200,
> Baruch Siach <baruch@tkos.co.il> a ?crit :
>
> > 1. Slide 23: missing -e in the 'echo' command
> >
> > $ echo "/dev/mtdblock7\t\t/applog\tjffs2\tdefaults\t\t0\t0"
> > /dev/mtdblock7\t\t/applog\tjffs2\tdefaults\t\t0\t0
> >
> > $ echo -e "/dev/mtdblock7\t\t/applog\tjffs2\tdefaults\t\t0\t0"
> > /dev/mtdblock7 /applog jffs2 defaults 0 0
>
> -e is not needed with sh:
The problem is that /bin/sh might be whatever. With a POSIX-conformant
/bin/sh (eg. dash), this is true. With bash, it is not. Alas, many
systems still have bash as /bin/sh.
$ ls -l /bin/sh
lrwxrwxrwx 1 root root 4 May 17 23:53 /bin/sh -> bash
$ echo "bli\nbla"
bli\nbla
$ /bin/bash
$ echo "bli\nbla"
bli\nbla
$ exit
$ /bin/dash
$ echo "bli\nbla"
bli
bla
The answer it to use printf [0].
I now use printf as much as I can. printf is in POSIX and does not suffer
from all the discrepancies there are in the many echo implementations.
> $ echo "bla\nbli"
> bla
> bli
> $ echo -e "bla\nbli"
> -e bla
> bli
[0] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/printf.html
Regards,
Yann E. MORIN.
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
^ permalink raw reply
* Re: A question on IOCTL interface for MMC
From: Chris Ball @ 2011-10-24 16:39 UTC (permalink / raw)
To: Shashidhar Hiremath; +Cc: Arnd Bergmann, J Freyensee, John Calixto, linux-mmc
In-Reply-To: <CANYdXnoS31GLnbFcwj76SUoyVhcti8Q-4_5fmyRy3DUJGbSRjg@mail.gmail.com>
Hi,
On Mon, Oct 24 2011, Shashidhar Hiremath wrote:
> As explained in previous mail, the IOCTL is actually an inteface to
> block layer and it is only expecting read/write commands to be sent
> through the interface.The prrof of it can be seen in write_flag
> present in the IOCTL structure which indicates the either the command
> can be read or a write command.
Please just try it, using an arbitrary write_flag.
Thanks,
- Chris.
--
Chris Ball <cjb@laptop.org> <http://printf.net/>
One Laptop Per Child
^ permalink raw reply
* Re: Linux USB HID should ignore values outside Logical Minimum/Maximum range
From: Denilson Figueiredo de Sá @ 2011-10-24 16:39 UTC (permalink / raw)
To: Chris Friesen; +Cc: linux-kernel, Jiri Kosina, linux-input, linux-usb
In-Reply-To: <4EA5913D.7090004@genband.com>
On Mon, Oct 24, 2011 at 14:24, Chris Friesen <chris.friesen@genband.com> wrote:
> On 10/22/2011 05:42 AM, Denilson Figueiredo de Sá wrote:
>
>> It may even happen to send an out-of-range value for one axis, but a
>> valid value for another axis. The code should be prepared for that
>> (ignore one, but keep the other).
>
> In this case what should be used for the "invalid" axis value? The previous
> value?
If that's an absolute pointing device, can we supply only one axis? I
mean, can we do this: "move the pointer to this X position, but leave
the Y position where it currently is". (note that the pointer might
have moved since last input from this device, due to other devices
also being present)
If that's not possible, then I'm not sure about what should be the
correct behavior. Should we ignore both axes if one of them is
invalid? Should we use the last good value from the other axis? (note
that relative pointing devices like proper mice shouldn't have this
issue, as we can just use zero for invalid values, which means "no
movement")
I haven't tested that on Windows (yet), so I don't know how it
behaves. If I test it, I'll post my results here.
I know, this is a corner case difficult to decide about.
By the way, my report was about absolute pointing devices, but I
haven't tested how Linux USB HID behaves for other kinds of devices
(keyboards, gamepads, anything else).
--
Denilson Figueiredo de Sá
Rio de Janeiro - Brasil
^ permalink raw reply
* Re: Linux USB HID should ignore values outside Logical Minimum/Maximum range
From: Denilson Figueiredo de Sá @ 2011-10-24 16:39 UTC (permalink / raw)
To: Chris Friesen; +Cc: linux-kernel, Jiri Kosina, linux-input, linux-usb
In-Reply-To: <4EA5913D.7090004@genband.com>
On Mon, Oct 24, 2011 at 14:24, Chris Friesen <chris.friesen@genband.com> wrote:
> On 10/22/2011 05:42 AM, Denilson Figueiredo de Sá wrote:
>
>> It may even happen to send an out-of-range value for one axis, but a
>> valid value for another axis. The code should be prepared for that
>> (ignore one, but keep the other).
>
> In this case what should be used for the "invalid" axis value? The previous
> value?
If that's an absolute pointing device, can we supply only one axis? I
mean, can we do this: "move the pointer to this X position, but leave
the Y position where it currently is". (note that the pointer might
have moved since last input from this device, due to other devices
also being present)
If that's not possible, then I'm not sure about what should be the
correct behavior. Should we ignore both axes if one of them is
invalid? Should we use the last good value from the other axis? (note
that relative pointing devices like proper mice shouldn't have this
issue, as we can just use zero for invalid values, which means "no
movement")
I haven't tested that on Windows (yet), so I don't know how it
behaves. If I test it, I'll post my results here.
I know, this is a corner case difficult to decide about.
By the way, my report was about absolute pointing devices, but I
haven't tested how Linux USB HID behaves for other kinds of devices
(keyboards, gamepads, anything else).
--
Denilson Figueiredo de Sá
Rio de Janeiro - Brasil
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/1] hob: fix backtrace when dismissing open dialog
From: Richard Purdie @ 2011-10-24 16:32 UTC (permalink / raw)
To: Joshua Lock; +Cc: bitbake-devel
In-Reply-To: <db59297aa1861614ffaea4295b9b054baa8a12b9.1318353511.git.josh@linux.intel.com>
On Tue, 2011-10-11 at 10:20 -0700, Joshua Lock wrote:
> Clearly a logic/indentation error - we should only try and load the recipe
> should the file-chooser return OK.
>
> Fixes [YOCTO #1668]
>
> Signed-off-by: Joshua Lock <josh@linux.intel.com>
> ---
> lib/bb/ui/hob.py | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
Merged to master, thanks.
Richard
^ permalink raw reply
* Re: [PATCH v0] fast-import: Add drop command
From: Vitor Antunes @ 2011-10-24 16:37 UTC (permalink / raw)
To: Dmitry Ivankov, Jonathan Nieder; +Cc: git, Sverre Rabbelier, David Barr
In-Reply-To: <CAOpHH-WSyD23GKtZ2nLiSsJfLU-+7ibyGhGccyvtAhKQ-jffBw@mail.gmail.com>
Hi,
This thread did not receive any updates for a long time.
Could someone provide some feedback?
Is this feasible? Does it make sense to add this command? If not, why?
Thanks,
Vitor
On Tue, Sep 27, 2011 at 9:57 AM, Vitor Antunes <vitor.hda@gmail.com> wrote:
> On Sat, Sep 24, 2011 at 10:19 PM, Dmitry Ivankov <divanorama@gmail.com> wrote:
>> On Sun, Sep 25, 2011 at 1:37 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
>>> Thanks. I must have missed the earlier discussion. What are the
>>> semantics of this command and its intended purpose?
>> My guess is that if fast-import is used to manage a set of "remote"
>> branches, it should be able to delete branches. Then, it should
>> be allowed to do non-fastforward updates too (--force). Why can't
>> it just ignore branches deletion (considering --force)?
>
> I started by using --force, but I did not want to completely disable
> these checks. The idea of the drop command is to add support to the
> exceptions that require non-fastforward updates.
>
>> Random thoughts:
>> 1. once 'drop' is executed, fast-import can't tell if the branch was
>> actually deleted. And moreover any attempt to read this branch
>> head becomes illegal (either it's missing in .git or fast-import is
>> instructed to use a dropped branch).
>> 2. 'reset' command is a bit like proposed 'drop' but it never deletes
>> a branch ref. Consider following imports:
>> 1) import branch topic
>> 2) reset topic
>> 3) import branch topic2 starting at topic (incorrect import)
>> If 1-3) is done in one fast-import process, the error is reported.
>> If 3) is done separately, it succeeds but the result is strange:
>> topic2 isn't started from scratch but from old "erased" topic.
>> So, maybe, reset should be fixed to erase branches on --force.
>
> I think you are not considering the possibility that checkpoints could
> have been done along the way. I use them frequently to be able to
> analyse branches with diff-tree. As soon as a checkpoint is done,
> update-branches will issue an error (commit A is not part of branch A').
>
>> One more scenario is:
>> 1) import topic
>> 2) reset topic
>> 3) import topic
>> If 1-3) go together - no error
>> If 3) goes separate - no error, but non-fastforward update.
>> Much more harmless, but still may look strange.
>
> Not exactly true if there is a checkpoint done after step 1.
>
> My scenario is:
>
> 1) import topic
> 2) checkpoint
> 3) diff-tree and processing
> 4) exit if processing returns ok
> 5) reset topic to another HEAD
> 6) goto 1)
^ permalink raw reply
* [U-Boot] [PATCH 2/2] mx51evk: Add RTC support
From: Fabio Estevam @ 2011-10-24 16:37 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1319474257-11851-1-git-send-email-fabio.estevam@freescale.com>
MX51EVK has a MC13892 PMIC. Add RTC support.
Tested via 'date' command that reads the PMIC RTC registers:
MX51EVK U-Boot > date
Date: 1970-01-01 (Thursday) Time: 0:40:35
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
---
include/configs/mx51evk.h | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/include/configs/mx51evk.h b/include/configs/mx51evk.h
index 2c449b8..67b5f0b 100644
--- a/include/configs/mx51evk.h
+++ b/include/configs/mx51evk.h
@@ -79,6 +79,7 @@
#define CONFIG_FSL_PMIC_CLK 2500000
#define CONFIG_FSL_PMIC_MODE (SPI_MODE_0 | SPI_CS_HIGH)
#define CONFIG_FSL_PMIC_BITLEN 32
+#define CONFIG_RTC_MC13XXX
/*
* MMC Configs
@@ -124,6 +125,8 @@
#undef CONFIG_CMD_IMLS
+#define CONFIG_CMD_DATE
+
#define CONFIG_BOOTDELAY 3
#define CONFIG_ETHPRIME "FEC0"
--
1.6.0.4
^ permalink raw reply related
* [U-Boot] [PATCH 1/2] rtc: Make mc13783-rtc driver generic
From: Fabio Estevam @ 2011-10-24 16:37 UTC (permalink / raw)
To: u-boot
Rename mc13783-rtc so that it can be used for both MC13783 and MC13892 PMICs.
efikamx board, for example, does use a MC13892 PMIC, but the RTC selection is currently made as:
#define CONFIG_RTC_MC13783
,which is not very obvious.
Let the MC13783 and MC13892 RTC be selected by:
#define CONFIG_RTC_MC13XXX
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
---
README | 2 +-
drivers/rtc/Makefile | 2 +-
include/configs/efikamx.h | 2 +-
include/configs/imx31_litekit.h | 2 +-
include/configs/mx31ads.h | 2 +-
include/configs/mx31pdk.h | 2 +-
include/configs/qong.h | 2 +-
include/configs/vision2.h | 2 +-
8 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/README b/README
index eb9ade9..1e20452 100644
--- a/README
+++ b/README
@@ -841,7 +841,7 @@ The following options need to be configured:
CONFIG_RTC_MPC8xx - use internal RTC of MPC8xx
CONFIG_RTC_PCF8563 - use Philips PCF8563 RTC
- CONFIG_RTC_MC13783 - use MC13783 RTC
+ CONFIG_RTC_MC13XXX - use MC13783 or MC13892 RTC
CONFIG_RTC_MC146818 - use MC146818 RTC
CONFIG_RTC_DS1307 - use Maxim, Inc. DS1307 RTC
CONFIG_RTC_DS1337 - use Maxim, Inc. DS1337 RTC
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index df440c6..a16f590 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -50,7 +50,7 @@ COBJS-$(CONFIG_RTC_M41T62) += m41t62.o
COBJS-$(CONFIG_RTC_M41T94) += m41t94.o
COBJS-$(CONFIG_RTC_M48T35A) += m48t35ax.o
COBJS-$(CONFIG_RTC_MAX6900) += max6900.o
-COBJS-$(CONFIG_RTC_MC13783) += mc13783-rtc.o
+COBJS-$(CONFIG_RTC_MC13XXX) += mc13xxx-rtc.o
COBJS-$(CONFIG_RTC_MC146818) += mc146818.o
COBJS-$(CONFIG_MCFRTC) += mcfrtc.o
COBJS-$(CONFIG_RTC_MK48T59) += mk48t59.o
diff --git a/include/configs/efikamx.h b/include/configs/efikamx.h
index 7e4b424..68bede9 100644
--- a/include/configs/efikamx.h
+++ b/include/configs/efikamx.h
@@ -132,7 +132,7 @@
#define CONFIG_FSL_PMIC_CLK 25000000
#define CONFIG_FSL_PMIC_MODE (SPI_MODE_0 | SPI_CS_HIGH)
#define CONFIG_FSL_PMIC_BITLEN 32
-#define CONFIG_RTC_MC13783
+#define CONFIG_RTC_MC13XXX
#endif
/*
diff --git a/include/configs/imx31_litekit.h b/include/configs/imx31_litekit.h
index 89e71c0..1455ea2 100644
--- a/include/configs/imx31_litekit.h
+++ b/include/configs/imx31_litekit.h
@@ -81,7 +81,7 @@
#define CONFIG_FSL_PMIC_CLK 1000000
#define CONFIG_FSL_PMIC_MODE (SPI_MODE_0 | SPI_CS_HIGH)
#define CONFIG_FSL_PMIC_BITLEN 32
-#define CONFIG_RTC_MC13783
+#define CONFIG_RTC_MC13XXX
/* allow to overwrite serial and ethaddr */
#define CONFIG_ENV_OVERWRITE
diff --git a/include/configs/mx31ads.h b/include/configs/mx31ads.h
index c9d80ef..7e011ae 100644
--- a/include/configs/mx31ads.h
+++ b/include/configs/mx31ads.h
@@ -78,7 +78,7 @@
#define CONFIG_FSL_PMIC_CLK 1000000
#define CONFIG_FSL_PMIC_MODE (SPI_MODE_0 | SPI_CS_HIGH)
#define CONFIG_FSL_PMIC_BITLEN 32
-#define CONFIG_RTC_MC13783
+#define CONFIG_RTC_MC13XXX
/* allow to overwrite serial and ethaddr */
#define CONFIG_ENV_OVERWRITE
diff --git a/include/configs/mx31pdk.h b/include/configs/mx31pdk.h
index b72f30b..9d64827 100644
--- a/include/configs/mx31pdk.h
+++ b/include/configs/mx31pdk.h
@@ -79,7 +79,7 @@
#define CONFIG_FSL_PMIC_CLK 1000000
#define CONFIG_FSL_PMIC_MODE (SPI_MODE_0 | SPI_CS_HIGH)
#define CONFIG_FSL_PMIC_BITLEN 32
-#define CONFIG_RTC_MC13783
+#define CONFIG_RTC_MC13XXX
/* allow to overwrite serial and ethaddr */
#define CONFIG_ENV_OVERWRITE
diff --git a/include/configs/qong.h b/include/configs/qong.h
index 4820914..4409186 100644
--- a/include/configs/qong.h
+++ b/include/configs/qong.h
@@ -58,7 +58,7 @@
#define CONFIG_MXC_SPI
#define CONFIG_DEFAULT_SPI_BUS 1
#define CONFIG_DEFAULT_SPI_MODE (SPI_MODE_0 | SPI_CS_HIGH)
-#define CONFIG_RTC_MC13783
+#define CONFIG_RTC_MC13XXX
#define CONFIG_PMIC
#define CONFIG_PMIC_SPI
diff --git a/include/configs/vision2.h b/include/configs/vision2.h
index a2a9f3f..5a4cd66 100644
--- a/include/configs/vision2.h
+++ b/include/configs/vision2.h
@@ -95,7 +95,7 @@
#define CONFIG_FSL_PMIC_CLK 2500000
#define CONFIG_FSL_PMIC_MODE SPI_MODE_0
#define CONFIG_FSL_PMIC_BITLEN 32
-#define CONFIG_RTC_MC13783
+#define CONFIG_RTC_MC13XXX
/*
* MMC Configs
--
1.6.0.4
^ permalink raw reply related
* Re: [PATCH 7/9] ib_srpt: Convert srp_max_rdma_size into per port configfs attribute
From: Bart Van Assche @ 2011-10-24 16:34 UTC (permalink / raw)
To: Nicholas A. Bellinger; +Cc: linux-rdma, Roland Dreier, Christoph Hellwig
In-Reply-To: <1319434422-15354-8-git-send-email-nab-IzHhD5pYlfBP7FQvKIMDCQ@public.gmane.org>
On Mon, Oct 24, 2011 at 7:33 AM, Nicholas A. Bellinger
<nab-IzHhD5pYlfBP7FQvKIMDCQ@public.gmane.org> wrote:
> This patch converts the srp_max_rdma_size module parameter into a per
> endpoint configfs attribute. This includes adding the necessary bits
> for show + store attributes w/ min/max bounds checking, and updating
> srpt_get_ioc() to accept a struct srpt_port parameter.
>
> [ ... ]
>
> -static void srpt_get_ioc(struct srpt_device *sdev, u32 slot,
> +static void srpt_get_ioc(struct srpt_port *sport, u32 slot,
> struct ib_dm_mad *mad)
The SRP spec says that there should be only one value for
iocp->rdma_size per I/O controller. This patch breaks that rule. I'm
not sure it's a good idea to introduce such behavior changes.
Bart.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Converting from Raid 5 to 6
From: Michael Busby @ 2011-10-24 16:34 UTC (permalink / raw)
To: Mathias Burén; +Cc: linux-raid
In-Reply-To: <CADNH=7GEL2SabyRM_FYJHyGEJ5eibobwzmH=iKzibF-Tkt25kw@mail.gmail.com>
On 24 October 2011 17:27, Mathias Burén <mathias.buren@gmail.com> wrote:
> On 24 October 2011 17:03, Michael Busby <michael.a.busby@gmail.com> wrote:
>> should the speed be very slow when doing this progress, its a lot
>> slower than a normal grow
>>
>> reshape = 1.2% (25006080/1953513984) finish=12481.8min speed=2574K/sec
>>
>> On 24 October 2011 15:11, Mathias Burén <mathias.buren@gmail.com> wrote:
>>> On 24 October 2011 14:11, Michael Busby <michael.a.busby@gmail.com> wrote:
>>>> At the moment i have a raid5 setup with 5 disks, i am looking to add a
>>>> 6th disk and change from raid 5 to raid 6
>>>>
>>>> having looked at Neil's site i have found the following command, and
>>>> just want to double check this is still the recommend way of
>>>> converting
>>>>
>>>> mdadm --grow /dev/md0 --level=6 --raid-disks=6 --backup-file=/home/md.backup
>>>>
>>>> also would i need to add the extra disk before or after the command?
>>>>
>>>> cheers
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>
>>>
>>> Hi,
>>>
>>> I grew my 6 disk RAID5 to a 7 disk RAID6. First, add the drive. Then
>>> partition it as required. Then add the drive to the array (I think
>>> it'll become a spare?). Then you can grow it.
>>>
>>> Make sure you're using the latest mdadm tools available.
>>>
>>> Regards,
>>> Mathias
>>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
> (please reply to the bottom of the email)
>
> What CPU are you using? What are the min/max kbps settings on the md
> device? What does top (or htop) show you?
>
> /M
>
Its a AMD 1.3ghz, in a HP microserver
max = 2000000
min = 200000
top - 17:33:49 up 4 days, 18:57, 2 users, load average: 1.19, 1.32, 1.34
Tasks: 102 total, 1 running, 101 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.3%us, 4.8%sy, 0.0%ni, 61.6%id, 32.9%wa, 0.0%hi, 0.3%si, 0.0%st
Mem: 2958840k total, 2519944k used, 438896k free, 140868k buffers
Swap: 3143676k total, 376112k used, 2767564k free, 1122084k cached
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [GIT PULL] 9p changes fro merge window
From: Eric Van Hensbergen @ 2011-10-24 16:28 UTC (permalink / raw)
To: Linus Torvalds, V9FS Developers, linux-kernel
The following changes since commit c3b92c8787367a8bb53d57d9789b558f1295cc96:
Linux 3.1 (2011-10-24 09:10:05 +0200)
are available in the git repository at:
git://github.com/ericvh/linux.git for-next
Aneesh Kumar K.V (4):
fs/9p: Update zero-copy implementation in 9p
fs/9p: inode file operation is properly initialized init_special_inode
fs/9p: Cleanup option parsing in 9p
net/9p: Convert net/9p protocol dumps to tracepoints
Dan Carpenter (2):
9p: move dereference after NULL check
fs/9p: change an int to unsigned int
Nicolae Mogoreanu (1):
9p: fix 9p.txt to advertise msize instead of maxdata
Documentation/filesystems/9p.txt | 2 +-
fs/9p/v9fs.c | 33 ++-
fs/9p/vfs_dir.c | 14 +-
fs/9p/vfs_inode.c | 2 -
include/net/9p/9p.h | 14 +-
include/net/9p/client.h | 8 +-
include/net/9p/transport.h | 10 +-
include/trace/events/9p.h | 176 ++++++++++++++
net/9p/client.c | 469 +++++++++++++++++++++++++++-----------
net/9p/protocol.c | 99 +-------
net/9p/protocol.h | 4 +-
net/9p/trans_common.c | 53 ++---
net/9p/trans_common.h | 21 +--
net/9p/trans_virtio.c | 319 +++++++++++++++-----------
14 files changed, 772 insertions(+), 452 deletions(-)
create mode 100644 include/trace/events/9p.h
^ permalink raw reply
* Re: [PATCH 1/2] LSM: Do not apply mmap_min_addr check to PROT_NONE mappings
From: Roland McGrath @ 2011-10-24 16:28 UTC (permalink / raw)
To: Eric Paris
Cc: Linus Torvalds, Andrew Morton, James Morris, Stephen Smalley,
selinux, John Johansen, linux-security-module, linux-kernel
In-Reply-To: <1319468868.3280.9.camel@localhost>
> I feel like, and it's just a very vague feeling, that the PROT bits
> didn't matter to the kernel. It would still happily execute stuff on
> page 0 even without PROT_EXEC at some point in the past. I'm probably
> totally off base, and I could test it, but I sort of feel like I
> remember something like that....
Saying that PROT_EXEC might not be enforced is quite a different thing than
saying "PROT bits don't matter". It's certainly the case that in some past
kernel versions, some hardware (older x86 chips), some configurations (x86
non-PAE), and some modes (READ_IMPLIES_EXEC personality stuff), what you
can read, you can execute. I sincerely doubt it's ever been the case that
anything mapped as PROT_NONE could be accessed in any manner.
Thanks,
Roland
^ permalink raw reply
* [U-Boot] [PATCH] [BUG] arm, lib: fix compile breakage
From: Albert ARIBAUD @ 2011-10-24 16:28 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1319434952-10971-1-git-send-email-hs@denx.de>
Hi Heiko,
Le 24/10/2011 07:42, Heiko Schocher a ?crit :
> since commit dc8bbea0170eb2aca428ea221c91fc2e5e11f199 building
> arch/arm/lib/board.c breaks if CONFIG_CMD_NET is defined.
> Fix this.
>
> Signed-off-by: Heiko Schocher<hs@denx.de>
> Cc: Albert ARIBAUD<albert.u.boot@aribaud.net>
> Cc: Simon Glass<sjg@chromium.org>
> ---
> arch/arm/lib/board.c | 3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c
> index ad02dbd..c1a3f2c 100644
> --- a/arch/arm/lib/board.c
> +++ b/arch/arm/lib/board.c
> @@ -440,6 +440,9 @@ void board_init_r(gd_t *id, ulong dest_addr)
> #if !defined(CONFIG_SYS_NO_FLASH)
> ulong flash_size;
> #endif
> +#if defined(CONFIG_CMD_NET)
> + char *s;
> +#endif
>
> gd = id;
>
Applied to u-boot-arm/master, thanks.
Amicalement,
--
Albert.
^ 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.