* [Bug 44852] 3D Acceleration initialization failed for Fusion Wrestler 9808
From: bugzilla-daemon @ 2012-01-17 9:31 UTC (permalink / raw)
To: dri-devel
In-Reply-To: <bug-44852-502@http.bugs.freedesktop.org/>
https://bugs.freedesktop.org/show_bug.cgi?id=44852
--- Comment #5 from Michel Dänzer <michel@daenzer.net> 2012-01-17 01:31:54 PST ---
(In reply to comment #3)
> Created attachment 55665 [details]
> dmesg
There's no trace of the radeon kernel module being loaded. Does the kernel have
the fix from bug 43739?
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* [PATCH] mac80211: fix debugfs key->station symlink
From: Johannes Berg @ 2012-01-17 9:32 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless
From: Johannes Berg <johannes.berg@intel.com>
Since stations moved into a virtual interface
subdirectory, this link has been broken. Fix it.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/mac80211/debugfs_key.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
--- a/net/mac80211/debugfs_key.c 2012-01-17 10:30:35.000000000 +0100
+++ b/net/mac80211/debugfs_key.c 2012-01-17 10:30:38.000000000 +0100
@@ -225,9 +225,9 @@ KEY_OPS(key);
key, &key_##name##_ops);
void ieee80211_debugfs_key_add(struct ieee80211_key *key)
- {
+{
static int keycount;
- char buf[50];
+ char buf[100];
struct sta_info *sta;
if (!key->local->debugfs.keys)
@@ -244,7 +244,8 @@ void ieee80211_debugfs_key_add(struct ie
sta = key->sta;
if (sta) {
- sprintf(buf, "../../stations/%pM", sta->sta.addr);
+ sprintf(buf, "../../netdev:%s/stations/%pM",
+ sta->sdata->name, sta->sta.addr);
key->debugfs.stalink =
debugfs_create_symlink("station", key->debugfs.dir, buf);
}
^ permalink raw reply
* [U-Boot] [PATCH 3/3] imximage: Sort bootops alphabetically
From: Stefano Babic @ 2012-01-17 9:32 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1326360512-5569-3-git-send-email-dirk.behme@de.bosch.com>
On 12/01/2012 10:28, Dirk Behme wrote:
> Signed-off-by: Dirk Behme <dirk.behme@de.bosch.com>
> CC: Fabio Estevam <festevam@gmail.com>
> CC: Stefano Babic <sbabic@denx.de>
> CC: Jason Liu <jason.hui@linaro.org>
> ---
Applied to u-boot-imx, thanks.
Best regards,
Stefano Babic
--
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office at denx.de
=====================================================================
^ permalink raw reply
* [U-Boot] [PATCH 1/3] imximage: Add MX53 to the documentation
From: Stefano Babic @ 2012-01-17 9:32 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1326360512-5569-1-git-send-email-dirk.behme@de.bosch.com>
On 12/01/2012 10:28, Dirk Behme wrote:
> i.MX53 is supported, too. Add this to the introduction of the
> documentation.
>
> Signed-off-by: Dirk Behme <dirk.behme@de.bosch.com>
> CC: Fabio Estevam <festevam@gmail.com>
> CC: Stefano Babic <sbabic@denx.de>
> CC: Jason Liu <jason.hui@linaro.org>
> ---
Applied to u-boot-imx, thanks.
Best regards,
Stefano Babic
--
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office at denx.de
=====================================================================
^ permalink raw reply
* [U-Boot] [PATCH 2/3] imximage: Add support for i.MX6
From: Stefano Babic @ 2012-01-17 9:32 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1326360512-5569-2-git-send-email-dirk.behme@de.bosch.com>
On 12/01/2012 10:28, Dirk Behme wrote:
> The i.MX6 processor can boot from NOR flash and SATA disks,
> additionally. Add the flash offsets for these additional
> boot modes.
>
> Signed-off-by: Dirk Behme <dirk.behme@de.bosch.com>
> Signed-off-by: Fabio Estevam <festevam@gmail.com>
> CC: Stefano Babic <sbabic@denx.de>
> CC: Jason Liu <jason.hui@linaro.org>
> ---
Applied to u-boot-imx, thanks.
Best regards,
Stefano Babic
--
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office at denx.de
=====================================================================
^ permalink raw reply
* [PATCH] mac80211: clean up rate control code
From: Johannes Berg @ 2012-01-17 9:33 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless
From: Johannes Berg <johannes.berg@intel.com>
It seems exceedingly unlikely that we'll ever
support swapping rate control algorithms at
runtime, so remove the unused refcounting code.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/mac80211/rate.c | 27 ++++-----------------------
net/mac80211/rate.h | 4 ----
net/mac80211/sta_info.c | 10 +++-------
3 files changed, 7 insertions(+), 34 deletions(-)
--- a/net/mac80211/rate.c 2012-01-17 10:32:36.000000000 +0100
+++ b/net/mac80211/rate.c 2012-01-17 10:32:41.000000000 +0100
@@ -159,7 +159,6 @@ static struct rate_control_ref *rate_con
ref = kmalloc(sizeof(struct rate_control_ref), GFP_KERNEL);
if (!ref)
goto fail_ref;
- kref_init(&ref->kref);
ref->local = local;
ref->ops = ieee80211_rate_control_ops_get(name);
if (!ref->ops)
@@ -184,11 +183,8 @@ fail_ref:
return NULL;
}
-static void rate_control_release(struct kref *kref)
+static void rate_control_free(struct rate_control_ref *ctrl_ref)
{
- struct rate_control_ref *ctrl_ref;
-
- ctrl_ref = container_of(kref, struct rate_control_ref, kref);
ctrl_ref->ops->free(ctrl_ref->priv);
#ifdef CONFIG_MAC80211_DEBUGFS
@@ -383,21 +379,10 @@ void rate_control_get_rate(struct ieee80
BUG_ON(info->control.rates[0].idx < 0);
}
-struct rate_control_ref *rate_control_get(struct rate_control_ref *ref)
-{
- kref_get(&ref->kref);
- return ref;
-}
-
-void rate_control_put(struct rate_control_ref *ref)
-{
- kref_put(&ref->kref, rate_control_release);
-}
-
int ieee80211_init_rate_ctrl_alg(struct ieee80211_local *local,
const char *name)
{
- struct rate_control_ref *ref, *old;
+ struct rate_control_ref *ref;
ASSERT_RTNL();
@@ -417,12 +402,8 @@ int ieee80211_init_rate_ctrl_alg(struct
return -ENOENT;
}
- old = local->rate_ctrl;
+ WARN_ON(local->rate_ctrl);
local->rate_ctrl = ref;
- if (old) {
- rate_control_put(old);
- sta_info_flush(local, NULL);
- }
wiphy_debug(local->hw.wiphy, "Selected rate control algorithm '%s'\n",
ref->ops->name);
@@ -440,6 +421,6 @@ void rate_control_deinitialize(struct ie
return;
local->rate_ctrl = NULL;
- rate_control_put(ref);
+ rate_control_free(ref);
}
--- a/net/mac80211/rate.h 2012-01-17 10:32:36.000000000 +0100
+++ b/net/mac80211/rate.h 2012-01-17 10:32:41.000000000 +0100
@@ -14,7 +14,6 @@
#include <linux/netdevice.h>
#include <linux/skbuff.h>
#include <linux/types.h>
-#include <linux/kref.h>
#include <net/mac80211.h>
#include "ieee80211_i.h"
#include "sta_info.h"
@@ -23,14 +22,11 @@ struct rate_control_ref {
struct ieee80211_local *local;
struct rate_control_ops *ops;
void *priv;
- struct kref kref;
};
void rate_control_get_rate(struct ieee80211_sub_if_data *sdata,
struct sta_info *sta,
struct ieee80211_tx_rate_control *txrc);
-struct rate_control_ref *rate_control_get(struct rate_control_ref *ref);
-void rate_control_put(struct rate_control_ref *ref);
static inline void rate_control_tx_status(struct ieee80211_local *local,
struct ieee80211_supported_band *sband,
--- a/net/mac80211/sta_info.c 2012-01-17 10:32:37.000000000 +0100
+++ b/net/mac80211/sta_info.c 2012-01-17 10:32:41.000000000 +0100
@@ -208,10 +208,8 @@ struct sta_info *sta_info_get_by_idx(str
*/
void sta_info_free(struct ieee80211_local *local, struct sta_info *sta)
{
- if (sta->rate_ctrl) {
+ if (sta->rate_ctrl)
rate_control_free_sta(sta);
- rate_control_put(sta->rate_ctrl);
- }
#ifdef CONFIG_MAC80211_VERBOSE_DEBUG
wiphy_debug(local->hw.wiphy, "Destroyed STA %pM\n", sta->sta.addr);
@@ -262,13 +260,11 @@ static int sta_prepare_rate_control(stru
if (local->hw.flags & IEEE80211_HW_HAS_RATE_CONTROL)
return 0;
- sta->rate_ctrl = rate_control_get(local->rate_ctrl);
+ sta->rate_ctrl = local->rate_ctrl;
sta->rate_ctrl_priv = rate_control_alloc_sta(sta->rate_ctrl,
&sta->sta, gfp);
- if (!sta->rate_ctrl_priv) {
- rate_control_put(sta->rate_ctrl);
+ if (!sta->rate_ctrl_priv)
return -ENOMEM;
- }
return 0;
}
^ permalink raw reply
* Re: [RFC] mmc: core: add the capability for broken voltage
From: Adrian Hunter @ 2012-01-17 9:37 UTC (permalink / raw)
To: Kyungmin Park; +Cc: Jaehoon Chung, linux-mmc, Chris Ball, Mark Brown
In-Reply-To: <CAH9JG2W2wF7a+eM_zXPBWn7XXuWDQkgwCOggJH4cEgKaCe3HMA@mail.gmail.com>
On 17/01/12 11:05, Kyungmin Park wrote:
> On 1/17/12, Adrian Hunter <adrian.hunter@intel.com> wrote:
>> On 16/01/12 10:49, Jaehoon Chung wrote:
>>> This patch is added the MMC_CAP2_BROKEN_VOLTAGE.
>>>
>>> if the voltage didn't satisfy between min_uV and max_uV,
>>
>> Why is the fixed voltage not in the acceptable range for the card?
>> Doesn't that risk breaking the card?
> Hi Adrian,
>
> I don't know, they uses the not supported voltage. but it's worked
> properly for long time.
I wonder if there is a generic problem here that this fix hides.
It would be nice to have an explanation. Do you know:
- what is the fixed voltage?
- is it supplying VCC or VCCQ?
- what is the contents of the OCR register?
> Galaxy S2 also uses the same voltage as ours.
>
> I also think the modify the regulator framework to support voltage
> change at fixed regulator. but it's not good idea and doesn't match
> the regulator concept. so modify the sdhci codes to support our
> boards.
>
> Thank you,
> Kyungmin Park
>>
>>> try to change the voltage in core.c.
>>> When change the voltage, maybe use the regulator_set_voltage().
>>>
>>> In regulator_set_voltage(), check the below condition.
>>>
>>> /* sanity check */
>>> if (!rdev->desc->ops->set_voltage &&
>>> !rdev->desc->ops->set_voltage_sel) {
>>> ret = -EINVAL;
>>> goto out;
>>> }
>>>
>>> If Some-board should use the fixed-regulator, always return -EINVAL.
>>> Then, eMMC didn't initialize always.
>>>
>>> So if use the fixed-regulator or etc, we need to add the
>>> MMC_CAP2_BROKEN_VOLTAGE.
>>>
>>> Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
>>> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
>>> ---
>>> drivers/mmc/core/core.c | 4 ++++
>>> include/linux/mmc/host.h | 1 +
>>> 2 files changed, 5 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
>>> index bec0bf2..6848789 100644
>>> --- a/drivers/mmc/core/core.c
>>> +++ b/drivers/mmc/core/core.c
>>> @@ -1121,6 +1121,10 @@ int mmc_regulator_set_ocr(struct mmc_host *mmc,
>>> * might not allow this operation
>>> */
>>> voltage = regulator_get_voltage(supply);
>>> +
>>> + if (mmc->caps2 & MMC_CAP2_BROKEN_VOLTAGE)
>>> + min_uV = max_uV = voltage;
>>> +
>>> if (voltage < 0)
>>> result = voltage;
>>> else if (voltage < min_uV || voltage > max_uV)
>>> diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
>>> index dd13e05..5659aee 100644
>>> --- a/include/linux/mmc/host.h
>>> +++ b/include/linux/mmc/host.h
>>> @@ -257,6 +257,7 @@ struct mmc_host {
>>> #define MMC_CAP2_HS200_1_2V_SDR (1 << 6) /* can support */
>>> #define MMC_CAP2_HS200 (MMC_CAP2_HS200_1_8V_SDR | \
>>> MMC_CAP2_HS200_1_2V_SDR)
>>> +#define MMC_CAP2_BROKEN_VOLTAGE (1 << 7) /* Use the broken voltage */
>>>
>>> mmc_pm_flag_t pm_caps; /* supported pm features */
>>> unsigned int power_notify_type;
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-mmc" 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 v9 3.2 0/9] Uprobes patchset with perf probe support
From: Ingo Molnar @ 2012-01-17 9:39 UTC (permalink / raw)
To: Srikar Dronamraju
Cc: Andrew Morton, Arnaldo Carvalho de Melo, Peter Zijlstra,
Linus Torvalds, Oleg Nesterov, LKML, Linux-mm, Andi Kleen,
Christoph Hellwig, Steven Rostedt, Roland McGrath,
Thomas Gleixner, Masami Hiramatsu, Arnaldo Carvalho de Melo,
Anton Arapov, Ananth N Mavinakayanahalli, Jim Keniston,
Stephen Rothwell
In-Reply-To: <20120116151755.GH10189@linux.vnet.ibm.com>
* Srikar Dronamraju <srikar@linux.vnet.ibm.com> wrote:
> > We already have some other vma tracking goodies in perf
> > itself (see perf_event_mmap() et al) - would it make sense
> > to merge the two vma instrumentation facilities and not
> > burden mm/ with two separate sets of callbacks?
>
> Atleast for file backed vmas, perf_event_mmap seems to be
> interested in just the new vma creations. Uprobes would also
> be interested in the size changes like the vma
> growing/shrinking/remap. Is perf_event_mmap interested in such
> changes? From what i could see, perf_event_mmap seems to be
> interested in stack vma size changes but not file vma size
> changes.
I don't think perf_event_mmap() would be hurt from getting more
callbacks, as long as there's enough metadata to differentiate
the various events from each other.
( In the long run we really want all such callbacks to be
tracepoints so that we can make them even less intrusive via
jump label patching optimizations, etc. - but we are not there
yet. )
> Also mmap_uprobe gets called in fork path. Currently we have a
> hook in copy_mm/dup_mm so that we get to know the context of
> each vma that gets added to the child and add its breakpoints.
> At dup_mm/dup_mmap we would have taken mmap_sem for both
> parent and child so there is no way we could have missed a
> register/unregister in the parent not reflected in the child.
>
> I see the perf_event_fork but that would have to enhanced to
> do a lot more to help us do a mmap_uprobe.
Andrew's call i guess.
I did not suggest anything complex or intrusive: just basically
unify the namespace, have a single set of callbacks, and call
into the uprobes and perf code from those callbacks - out of the
sight of MM code.
That unified namespace could be called:
event_mmap(...);
event_fork(...);
etc. - and from event_mmap() you could do a simple:
perf_event_mmap(...)
uprobes_event_mmap(...)
[ Once all this is updated to use tracepoints it would turn into
a notification callback chain kind of thing. ]
> > If all such issues are resolved then i guess we could queue
> > up uprobes in -tip, conditional on it remaining sufficiently
> > regression-, problem- and NAK-free.
>
> Okay. Accepting uprobes into tip, would provide more
> testing/feedback.
>
> > Also, it would be nice to hear Arnaldo's opinion about the
> > tools/perf/ bits.
>
> Whatever comments Arnaldo/Masami have given till now have been
> resolved.
Please see the probe installation syntax feedback i've sent in
the previous mail - that needs to be addressed too.
You should think with the head of an ordinary user-space
developer who wants to say debug a library and wants to use
uprobes for that. What would he have to type to achieve that and
is what he types the minimum number of characters to reasonably
achieve that goal?
Thanks,
Ingo
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH v9 3.2 0/9] Uprobes patchset with perf probe support
From: Ingo Molnar @ 2012-01-17 9:39 UTC (permalink / raw)
To: Srikar Dronamraju
Cc: Andrew Morton, Arnaldo Carvalho de Melo, Peter Zijlstra,
Linus Torvalds, Oleg Nesterov, LKML, Linux-mm, Andi Kleen,
Christoph Hellwig, Steven Rostedt, Roland McGrath,
Thomas Gleixner, Masami Hiramatsu, Arnaldo Carvalho de Melo,
Anton Arapov, Ananth N Mavinakayanahalli, Jim Keniston,
Stephen Rothwell
In-Reply-To: <20120116151755.GH10189@linux.vnet.ibm.com>
* Srikar Dronamraju <srikar@linux.vnet.ibm.com> wrote:
> > We already have some other vma tracking goodies in perf
> > itself (see perf_event_mmap() et al) - would it make sense
> > to merge the two vma instrumentation facilities and not
> > burden mm/ with two separate sets of callbacks?
>
> Atleast for file backed vmas, perf_event_mmap seems to be
> interested in just the new vma creations. Uprobes would also
> be interested in the size changes like the vma
> growing/shrinking/remap. Is perf_event_mmap interested in such
> changes? From what i could see, perf_event_mmap seems to be
> interested in stack vma size changes but not file vma size
> changes.
I don't think perf_event_mmap() would be hurt from getting more
callbacks, as long as there's enough metadata to differentiate
the various events from each other.
( In the long run we really want all such callbacks to be
tracepoints so that we can make them even less intrusive via
jump label patching optimizations, etc. - but we are not there
yet. )
> Also mmap_uprobe gets called in fork path. Currently we have a
> hook in copy_mm/dup_mm so that we get to know the context of
> each vma that gets added to the child and add its breakpoints.
> At dup_mm/dup_mmap we would have taken mmap_sem for both
> parent and child so there is no way we could have missed a
> register/unregister in the parent not reflected in the child.
>
> I see the perf_event_fork but that would have to enhanced to
> do a lot more to help us do a mmap_uprobe.
Andrew's call i guess.
I did not suggest anything complex or intrusive: just basically
unify the namespace, have a single set of callbacks, and call
into the uprobes and perf code from those callbacks - out of the
sight of MM code.
That unified namespace could be called:
event_mmap(...);
event_fork(...);
etc. - and from event_mmap() you could do a simple:
perf_event_mmap(...)
uprobes_event_mmap(...)
[ Once all this is updated to use tracepoints it would turn into
a notification callback chain kind of thing. ]
> > If all such issues are resolved then i guess we could queue
> > up uprobes in -tip, conditional on it remaining sufficiently
> > regression-, problem- and NAK-free.
>
> Okay. Accepting uprobes into tip, would provide more
> testing/feedback.
>
> > Also, it would be nice to hear Arnaldo's opinion about the
> > tools/perf/ bits.
>
> Whatever comments Arnaldo/Masami have given till now have been
> resolved.
Please see the probe installation syntax feedback i've sent in
the previous mail - that needs to be addressed too.
You should think with the head of an ordinary user-space
developer who wants to say debug a library and wants to use
uprobes for that. What would he have to type to achieve that and
is what he types the minimum number of characters to reasonably
achieve that goal?
Thanks,
Ingo
^ permalink raw reply
* Re: Driver domains and hotplug scripts, redux
From: Roger Pau Monné @ 2012-01-17 9:40 UTC (permalink / raw)
To: Ian Campbell
Cc: xen-devel@lists.xensource.com, Ian Jackson, Stefano Stabellini
In-Reply-To: <1326791863.14689.52.camel@zakaz.uk.xensource.com>
2012/1/17 Ian Campbell <Ian.Campbell@citrix.com>:
> However xend should not be transition to this new scheme but should
> continue to use its existing scripts in the current manner.
>
> There was a conversation last year[0] about how a toolstack could
> opt-in/out of the use of the hotplug scripts. We decided that toolstacks
> should have to opt into the use of these scripts, by touching a stamp
> file.
>
> Although this wasn't implemented yet (unless I missed it) I guess the
> same scheme would apply to this work if that sort of thing turns out to
> be necessary.
Sorry for replying so many times, this is a big maybe, and possibly
it's too drastic, but after this changes xl and xend will not be
compatible anymore, so why don't we disable xend by default, and only
build xl?
When the new configure script is in, it will be trivial to select if
you want xl or xend, and only install one of those. Adding the option
--enable-xend should disable xl and only build and install xend
(printing a very big warning that xend is deprecated).
> Ian.
>
> [0] http://lists.xen.org/archives/html/xen-devel/2011-06/msg00952.html
>
^ permalink raw reply
* [PATCH 2/2] ARM: sa1100: Refactor mcp-sa11x0 to use platform resources.
From: Jochen Friedrich @ 2012-01-17 9:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20120114092129.GO1068@n2100.arm.linux.org.uk>
Hi Russell,
On 14.01.2012 10:21, Russell King - ARM Linux wrote:
> I should have spotted this patch earlier.
Sorry for my late response as well.
> This is the obviously wrong approach - if you're having to add the same
> code to almost every board, then you're doing something wrong.
Accessing some random SoC registers and in the assabet case even board
specific registers from device drivers is even worse IMHO. We don't get
a clean solution until we have a pinmux/pinctrl device driver owning
these peripheral control registers. At least having the setup in the
board files avoids a potential race condition accessing PPDR and PPSR
registers from multiple drivers.
>
> Not only that, but...
>
>> static struct resource sa11x0mcp_resources[] = {
>> [0] = {
>> .start = __PREG(Ser4MCCR0),
>> - .end = __PREG(Ser4MCCR0) + 0xffff,
>> + .end = __PREG(Ser4MCCR0) + 0x1C - 1,
>
> Please leave this as +0xffff - we treat all devices has having 64K
> resources on sa11x0 platforms. (It's possible that the registers
> repeat throughout the memory space.)
OK, but...
>> .flags = IORESOURCE_MEM,
>> },
>> [1] = {
>> + .start = __PREG(Ser4MCCR1),
>> + .end = __PREG(Ser4MCCR1) + 0x4 - 1,
>> + .flags = IORESOURCE_MEM,
>> + },
How to treat this case then? Here one register is "borrowed" from a
different 64K block.
The old driver version didn't even register access to this memory space.
> void __iomem *
>
> Note the '__iomem'. That must stay with the cookie. Check your code
> with sparse.
OK, will do.
>> + __raw_writel(priv->mccr0, priv->mccr0_base + MCCR0);
>
> writel? writel_relaxed?
writel_relaxed should be fine. The old version didn't use any barriers,
so I assume that's OK. I'll check if reorders would cause any problem.
>> + size0 = res_mem0->end - res_mem0->start + 1;
>
> resource_size() ?
Jamie pointed me to this already. I'll change this.
>> + priv->mccr0_base = ioremap(res_mem0->start, size0);
>> + priv->mccr1_base = ioremap(res_mem1->start, size1);
>
> You want to oops the kernel? Where's the error checking?
Good catch!
Thanks for the review,
Jochen
^ permalink raw reply
* RE: [PATCH] NFC: Increase NCI deactivate timeout
From: Elias, Ilan @ 2012-01-17 9:42 UTC (permalink / raw)
To: Samuel Ortiz
Cc: aloisio.almeida@openbossa.org, lauro.venancio@openbossa.org,
linville@tuxdriver.com, linux-wireless@vger.kernel.org
In-Reply-To: <1326745622.22824.12.camel@sortiz-mobl>
Hi Samuel,
> > Increase NCI deactivate timeout from 5 sec to 30 sec.
> > NCI deactivate procedure might take a long time,
> > depending on the local and remote parameters.
> 30 seconds sounds like a huge delay for receiving a reply to
> such command.
> Would you care explaining how we can get that long of a timeout ?
The controller in the Reader side uses a value called nRETRY (see NFC Forum Digital spec).
This value is an internal implementation, valid range is 2 to 5.
This value determines the number of re-transmissions.
The controller in the Tag side uses a value called FWI - Frame Waiting time Integer (see NFC Forum Digital spec).
This value is an internal implementation, valid range is 1 to 14.
This value determines (via some formula) the FWT - Frame Waiting Time, which is a timout.
Max FWT value can be almost 5sec.
So, the total max timeout can be 5sec for the first packet + 5sec for each of the 5 re-transmissions = 5 + 5x5 = 30 sec.
> Cheers,
> Samuel.
Thanks & BR,
Ilan
^ permalink raw reply
* Re: Driver domains and hotplug scripts, redux
From: Ian Campbell @ 2012-01-17 9:43 UTC (permalink / raw)
To: Roger Pau Monné
Cc: xen-devel@lists.xensource.com, Ian Jackson, Stefano Stabellini
In-Reply-To: <CAPLaKK4XbdEVYC41mwtYkf2Y7883oWK38t8cAYfFufeKs2THsQ@mail.gmail.com>
On Tue, 2012-01-17 at 09:30 +0000, Roger Pau Monné wrote:
> 2012/1/17 Ian Campbell <Ian.Campbell@citrix.com>:
> > On Mon, 2012-01-16 at 17:58 +0000, Ian Jackson wrote:
> >> Roger Pau Monné writes ("Re: [Xen-devel] Driver domains and hotplug scripts, redux"):
> >> > 2012/1/12 Ian Jackson <Ian.Jackson@eu.citrix.com>:
> >> > > Ian Campbell writes ("Re: [Xen-devel] Driver domains and hotplug scripts, redux"):
> >> > >> The forceful destroy case is different, it is effectively:
> >> > >> 1. rm backend dir in xenstore.
> >> > >
> >> > > That's (iii). We want a way to do (ii) as well.
> >> >
> >> > From my point of view, (iii) should only happen after (i) or (ii) has
> >> > failed (timeout or error trying to unplug devices).
> >>
> >> There has to be a user option to ask for a "very forceful" detach.
> >>
> >> > What should we do with xend? Are we keeping it on 4.2? I'm asking this
> >> > because the changes I'm introducing disables some udev rules that are
> >> > needed for xend. The other option is to update xend to talk to
> >> > xenbackendd also.
> >>
> >> I think xend is not going to go away in 4.2, unfortunately.
> >
> > However xend should not be transition to this new scheme but should
> > continue to use its existing scripts in the current manner.
> >
> > There was a conversation last year[0] about how a toolstack could
> > opt-in/out of the use of the hotplug scripts. We decided that toolstacks
> > should have to opt into the use of these scripts, by touching a stamp
> > file.
>
> I'm not sure this solves our problems, since this doesn't disable udev
> exactly, it disables hotplug scripts entirely, but they are needed
> from libxl also (my approach uses the current hotplug scripts).
Sure, I wasn't sure exactly what approach was being planned.
> Also, if both xl and xend are running,
That is not a supported configuration so I don't think we should concern
ourselves unduly with it.
Lets fix xl to work how we want it and then we can look at ways of
making sure that nothing changes if you are using xend.
> there are a lot of chances of
> getting a mess, since machines started from xl (using the new xenstore
> protocol /hotplug/...) could not be stopped successfully from xend,
> and the other way around.
>
> > Although this wasn't implemented yet (unless I missed it) I guess the
> > same scheme would apply to this work if that sort of thing turns out to
> > be necessary.
> >
> > Ian.
> >
> > [0] http://lists.xen.org/archives/html/xen-devel/2011-06/msg00952.html
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply
* Re: [RFC PATCH 1/1] self-hosted-image: generate the .hdddirect and .vmdk image files
From: Cui, Dexuan @ 2012-01-17 9:35 UTC (permalink / raw)
To: Darren Hart, Patches and discussions about the oe-core layer
In-Reply-To: <4F0F0AE5.4040009@linux.intel.com>
Darren Hart wrote on 2012-01-13:
> Hi Dexuan,
>
> Please include a complete patch header. Much of your 0/1 content can
> go here.
(Sorry for the late reply! I overlooked the mails...)
Ok, I'll pay attention to this in future.
> Comments below...
>
> On 01/10/2012 10:53 AM, Dexuan Cui wrote:
>> Signed-off-by: Dexuan Cui <dexuan.cui@intel.com>
>> ---
>> meta/classes/boot-directdisk.bbclass | 10 +++++++++-
>> meta/recipes-core/images/self-hosted-image.bb | 11 +++++++++--
>> 2 files changed, 18 insertions(+), 3 deletions(-)
>> diff --git a/meta/classes/boot-directdisk.bbclass
>> b/meta/classes/boot-directdisk.bbclass index 8879ba8..83ec929 100644
>> --- a/meta/classes/boot-directdisk.bbclass +++
>> b/meta/classes/boot-directdisk.bbclass @@ -24,6 +24,7 @@
>> do_bootdirectdisk[depends] += "dosfstools-native:do_populate_sysroot \
>>
>> syslinux-native:do_populate_sysroot \
>>
>> parted-native:do_populate_sysroot \
>>
>> mtools-native:do_populate_sysroot " +do_bootdirectdisk[depends] +=
>> "qemu-native:do_populate_sysroot"
>>
>> PACKAGES = " "
>> EXCLUDE_FROM_WORLD = "1"
>> @@ -38,7 +39,7 @@ BOOTDD_EXTRA_SPACE ?= "16384"
>>
>> AUTO_SYSLINUXCFG = "1"
>> LABELS = "boot"
>> -APPEND = "root=/dev/sda2"
>> +APPEND = "root=/dev/hda2"
>
> This seems like it had the potential to break other uses of hdddirect.
> Qemu may use hda2, but other hdddirect users (external layers for
Hi Darren, thanks for pointing this out!
I thought it's ok since now I'm the only user ofhdddirect, but I didn't realize I might break external layers...
> example) may not. This feels like a MACHINE config to me. In fact,
> machine's do already set APPEND for things like the console.
I agree.
So, I think here we should change the = to ?= like the below
-APPEND = "root=/dev/sda2"
+APPEND ?= "root=/dev/sda2"
And in meta/conf/machine/include/qemu.inc, I can add a line
APPEND = "root=/dev/hda2".
Does this sound ok?
>
>> TIMEOUT = "10"
>> SYSLINUXCFG = "${HDDDIR}/syslinux.cfg"
>> SYSLINUXMENU = "${HDDDIR}/menu"
>> @@ -50,6 +51,7 @@ build_boot_dd() {
>>
>> install -d ${HDDDIR}
>> install -m 0644 ${STAGING_DIR_HOST}/kernel/bzImage
> ${HDDDIR}/vmlinuz
>> + install -m 0644 ${S}/syslinux.cfg ${HDDDIR}/syslinux.cfg
>
> Hrm... syslinux.cfg wasn't installed before at all?
I'm not very clear about the history, but according to syslinux.bbclass,
iso and hddimg do invoke syslinux_populate, but hdddirect doesn't -- I suppose hdddirect doesn't need all the functionality of build_syslinux_menu, so it tries to install the files itself, and unluckily it misses syslinux.cfg. Now there is no user of .hdddirect in poky, and I don't know there is any actual external user. This may explain why nobody complains. :-)
>
>> install -m 444 ${STAGING_LIBDIR}/syslinux/ldlinux.sys
>> ${HDDDIR}/ldlinux.sys
>>
>> BLOCKS=`du -bks ${HDDDIR} | cut -f 1` @@ -83,6 +85,12 @@
>> build_boot_dd() { cd ${DEPLOY_DIR_IMAGE} rm -f
>> ${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.hdddirect ln -s
>> ${IMAGE_NAME}.hdddirect
>> ${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.hdddirect
>> +
>> + if [ "${NOVMDK}" != "1" ] ; then
>> + ${STAGING_BINDIR_NATIVE}/qemu-img convert -O vmdk \
>
> You've added a dependency on qemu-img, please add the appropriate
> DEPENDS above.
I have added the line in my patch:
do_bootdirectdisk[depends] += "qemu-native:do_populate_sysroot"
I think this is enough?
Need I add "DEPENDS += "qemu-native", too?
>
>> + ${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.hdddirect \
>> + ${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.vmdk
>> + fi
>> }
>>
>> python do_bootdirectdisk() {
> Darren Hart wrote on 2012-01-13:
> On 01/10/2012 10:53 AM, Dexuan Cui wrote:
>
> A couple additional thoughts about the boot-directdisk class in general:
>
> So build_boot_dd needs a careful audit to ensure the various dd
> commands do not stomp on eachother iirc, the dd of syslinux/mbr.bin
> was stomping on the partition table or some such.
Hi Darren,
The dd-ing of mbr.bin actually writes only the first 440 bytes of $IMAGE -- please note
the size of mbr.bin(generated by the recipe syslinux, I think) is 440 bytes rather than 512 bytes. :-)
I think 440 is safe enough because it's even smaller than 512-16*4=448 bytes.
> Also note that it uses "mkdosfs -d" which we have purged (and it aint
> coming back if my NACK is worth anything ;-). Sounds like we need to
> abstract building msdos images into an msdosfs.bbclass. No reason to
Would you volunteer to make a msdosfs.bbclass? :-)
> duplicate all the fatfs overhead calculations I did yesterday (See the
> patch I sent yesterday to bootimg.bbclass).
I agree.
I see your patch has been in poky master now.
If you could help to make msdosfs.bbclass, I would appreciate that a lot.
Now I'm stick in something else and I'm afraid I can't start to work on this immediately. :-(
Thanks,
-- Dexuan
^ permalink raw reply
* Re: [RFC 1/3] /dev/low_mem_notify
From: Pekka Enberg @ 2012-01-17 9:45 UTC (permalink / raw)
To: Minchan Kim
Cc: linux-mm, LKML, leonid.moiseichuk, kamezawa.hiroyu, Rik van Riel,
mel, rientjes, KOSAKI Motohiro, Johannes Weiner, Marcelo Tosatti,
Andrew Morton, Ronen Hod, KOSAKI Motohiro
In-Reply-To: <1326788038-29141-2-git-send-email-minchan@kernel.org>
On Tue, Jan 17, 2012 at 10:13 AM, Minchan Kim <minchan@kernel.org> wrote:
> This patch makes new device file "/dev/low_mem_notify".
> If application polls it, it can receive event when system
> memory pressure happens.
>
> This patch is based on KOSAKI and Marcelo's long time ago work.
> http://lwn.net/Articles/268732/
I'm not loving the ABI. Alternative solutions:
- SIGDANGER + signalfd() for poll
- sys_eventfd()
- sys_mem_notify_open() similar to sys_perf_event_open()
Pekka
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [RFC 1/3] /dev/low_mem_notify
From: Pekka Enberg @ 2012-01-17 9:45 UTC (permalink / raw)
To: Minchan Kim
Cc: linux-mm, LKML, leonid.moiseichuk, kamezawa.hiroyu, Rik van Riel,
mel, rientjes, KOSAKI Motohiro, Johannes Weiner, Marcelo Tosatti,
Andrew Morton, Ronen Hod, KOSAKI Motohiro
In-Reply-To: <1326788038-29141-2-git-send-email-minchan@kernel.org>
On Tue, Jan 17, 2012 at 10:13 AM, Minchan Kim <minchan@kernel.org> wrote:
> This patch makes new device file "/dev/low_mem_notify".
> If application polls it, it can receive event when system
> memory pressure happens.
>
> This patch is based on KOSAKI and Marcelo's long time ago work.
> http://lwn.net/Articles/268732/
I'm not loving the ABI. Alternative solutions:
- SIGDANGER + signalfd() for poll
- sys_eventfd()
- sys_mem_notify_open() similar to sys_perf_event_open()
Pekka
^ permalink raw reply
* [U-Boot] [PATCH] i.mx6q: configs: Add fdt_high and initrd_high variables
From: Stefano Babic @ 2012-01-17 9:45 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1326448165-24041-2-git-send-email-dirk.behme@de.bosch.com>
On 13/01/2012 10:49, Dirk Behme wrote:
> To be able to load the device tree and initrd correctly, set
> the fdt_high and initrd_high environment variables.
>
> Using 0xffffffff implies that the device tree and the initrd
> are initially copied to working addresses. This will avoid an
> additional copy.
>
> Loading the device tree to 0x30000000 and the initrd to 0x3c000000
> should work for both boards, the ARM2 and SabreLite.
>
> Example (SabreLite):
>
> fatload mmc 0:2 0x10000000 uImage
> fatload mmc 0:2 0x3c000000 uInitrd
> fatload mmc 0:2 0x30000000 board.dtb
> bootm 0x10000000 0x3c000000 0x30000000
>
> Note: This requires that the kernel has CONFIG_HIGHMEM enabled.
>
> Signed-off-by: Dirk Behme <dirk.behme@de.bosch.com>
> CC: Jason Liu <jason.hui@linaro.org>
> CC: Stefano Babic <sbabic@denx.de>
> ---
Applied to u-boot-imx, thanks.
Best regards,
Stefano Babic
--
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office at denx.de
=====================================================================
^ permalink raw reply
* [U-Boot] [PATCH] i.mx6q: mx6qsabrelite: Setup uart1 pinmux
From: Stefano Babic @ 2012-01-17 9:45 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1326448165-24041-3-git-send-email-dirk.behme@de.bosch.com>
On 13/01/2012 10:49, Dirk Behme wrote:
> From: Troy Kisky <troy.kisky@boundarydevices.com>
>
> This allows the Linux kernel to use UART1 before pinmux
> support is added for UART1
>
> Signed-off-by: Troy Kisky <troy.kisky@boundarydevices.com>
> CC: Troy Kisky <troy.kisky@boundarydevices.com>
> CC: Jason Liu <jason.hui@linaro.org>
> CC: Stefano Babic <sbabic@denx.de>
> ---
Applied to u-boot-imx, thanks.
Best regards,
Stefano Babic
--
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office at denx.de
=====================================================================
^ permalink raw reply
* Pinmux bindings proposal
From: Dong Aisheng-B29396 @ 2012-01-17 9:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20120117082334.GA31295@S2101-09.ap.freescale.net>
> -----Original Message-----
> From: Shawn Guo [mailto:shawn.guo at linaro.org]
> Sent: Tuesday, January 17, 2012 4:24 PM
> To: Dong Aisheng-B29396
> Cc: Stephen Warren; linus.walleij at stericsson.com; s.hauer at pengutronix.de;
> rob.herring at calxeda.com; kernel at pengutronix.de; cjb at laptop.org; Simon Glass
> (sjg at chromium.org); Dong Aisheng; linux-kernel at vger.kernel.org; linux-arm-
> kernel at lists.infradead.org; devicetree-discuss at lists.ozlabs.org
> Subject: Re: Pinmux bindings proposal
> Importance: High
>
> On Mon, Jan 16, 2012 at 12:50:02PM +0000, Dong Aisheng-B29396 wrote:
> ...
> > > /*
> > > * The actual definition of the complete state of the
> > > * pinmux as required by some driver.
> > > *
> > > * These can be either directly in the device node, or
> > > * somewhere in tegra20.dtsi in order to provide pre-
> > > * selected/common configurations. Hence, they're referred
> > > * to by phandle above.
> > > */
> > > pmx_sdhci_active: {
> > > /*
> > > * Pin mux settings. Mandatory?
> > Mandatory for what?
> >
> > > * Not mandatory if the 1:1 mentioned above is
> > > * extended to 1:n.
> > > *
> > > * Format is <&pmx_controller_phandle
> muxable_entity_id
> > > * selected_function>.
> > > *
> > > * The pmx phandle is required since there may be
> more
> > > * than one pinmux controller in the system. Even if
> > > * this node is inside the pinmux controller itself,
> I
> > > * think it's simpler to just always have this field
> > > * present in the binding for consistency.
> > > *
> > > * Alternative: Format is <&pmx_controller_phandle
> > > * pmx_controller_specific_data>. In this case, the
> > > * pmx controller needs to define #pinmux-mux-cells,
> > > * and provide the pinctrl core with a mapping
> > > * function to handle the rest of the data in the
> > > * property. This is how GPIOs and interrupts work.
> > > * However, this will probably interact badly with
> > > * wanting to parse the entire pinmux map early in
> > > * boot, when perhaps the pinctrl core is
> initialized,
> > > * but the pinctrl driver itself is not.
> > > */
> > > mux =
> > > <&tegra_pmx TEGRA_PMX_PG_DTA TEGRA_PMX_MUX_1>
> > > <&tegra_pmx TEGRA_PMX_PG_DTD TEGRA_PMX_MUX_1>
> > > /* Syntax example */
> > > <&foo_pmx FOO_PMX_PG_X
> > > FOO_PMX_MUX_0>;
> > I'm still think how do we construct the pinmux map for such binding.
> > The format you're using is:
> > <&pmx_controller_phandle muxable_entity_id selected_function> For
> > contruct pinmux map, we need to know at least 3 things for a device:
> > a) pinctrl device b) function name c) group name.
> > For a, we can get it from this binding.
> > But for b and c, since they are constants, how to convert to name string?
> >
> I guess, for function name, it should be retrieved from the client device node,
> and for the group name, it should be retrieved from the node here.
>
I guess Stephen's idea is to retrieving the function name and group name
>From the pinctrl driver since Tagre prefers to define those things in driver
Rather than in board file or soc.dts file.
But it does not fit for IMX since we define it in soc.dts.
> For above example, the function name can be picked from sdhci device node
> pinctr-names property I proposed,
If I understand correctly, the pinctrl-names property you proposed represents
The pin group state.
> and the group name can just be
> 'pmx_sdhci_active', which is not a very nice name here and reminds me the
> following point.
>
No, I don't think it's suitable for group name since pmx_sdhci_active is not a
group node (actually it includes many groups).
> Considering the different pinctrl configurations for the same client device
> usually share the same pinmux and only pinconf varies.
I have the same doubts before.
Is there a real case that device has the different pinmux in different state?
Stephen?
> It may worth introducing
> another level phandle reference. Something like the following:
>
> pinmux_sdhci: pinmux-sdhci {
> mux =
> <&tegra_pmx TEGRA_PMX_PG_DTA TEGRA_PMX_MUX_1>
> <&tegra_pmx TEGRA_PMX_PG_DTD TEGRA_PMX_MUX_1>;
> };
>
> pinconf_sdhci_active: pinconf-sdhci-active {
> config =
> <&tegra_pmx TEGRA_PMX_PG_DTA TEGRA_PMX_CONF_DRIVE_STRENGTH 5>
> <&tegra_pmx TEGRA_PMX_PG_DTD TEGRA_PMX_CONF_DRIVE_STRENGTH 5>
> <&tegra_pmx TEGRA_PMX_PG_DTA TEGRA_PMX_CONF_SLEW_RATE 4>
> <&tegra_pmx TEGRA_PMX_PG_DTD TEGRA_PMX_CONF_SLEW_RATE 8>;
> };
>
> pinconf_sdhci_suspend: pinconf-sdhci-suspend {
> config =
> <&tegra_pmx TEGRA_PMX_PG_DTA TEGRA_PMX_CONF_TRISTATE 1>
> <&tegra_pmx TEGRA_PMX_PG_DTD TEGRA_PMX_CONF_TRISTATE 1>
> <&tegra_pmx TEGRA_PMX_PG_DTA TEGRA_PMX_CONF_DRIVE_STRENGTH 5>
> <&tegra_pmx TEGRA_PMX_PG_DTD TEGRA_PMX_CONF_DRIVE_STRENGTH 5>
> <&tegra_pmx TEGRA_PMX_PG_DTA TEGRA_PMX_CONF_SLEW_RATE 4>
> <&tegra_pmx TEGRA_PMX_PG_DTD TEGRA_PMX_CONF_SLEW_RATE 8>;
> };
>
The config makes sense to me.
The only question is how to get group name to match with the predefined groups.
Besides per pin group configuration support, we may also want per pin configuration
Support as the latest patch sent by Linus.
http://www.spinics.net/lists/arm-kernel/msg155712.html
> pinctrl_sdhci_active: pinctrl-sdhci-active {
> pinmux = <&pinmux_sdhci>;
> pinconf = <&pinconf_sdhci_active>;
> };
>
> pinctrl_sdhci_suspend: pinctrl-sdhci-suspend {
> pinmux = <&pinmux_sdhci>;
> pinconf = <&pinconf_sdhci_suspend>;
> };
>
> sdhci at c8000200 {
> ...
> pinctrl = <&pinctrl_sdhci_active> <&pinctrl_sdhci_suspend>;
> pinctrl-names = "active", "suspend";
> };
>
> This will be pretty useful for imx6 usdhc case, which will have 3 pinctrl
> configuration for each usdhc device (imx6 has 4 usdhc devices), pinctrl-50mhz,
> pinctrl-100mhz and pinctrl-200mhz. All these 3 states have the exactly same
> pinmux settings, and only varies on pinconf.
>
> > > /*
> > > * Pin configuration settings. Optional.
> > > *
> > > * Format is <&pmx_controller_phandle
> muxable_entity_id
> > > * configuration_option configuration_value>.
> > > */
> > > config =
> > > <&tegra_pmx TEGRA_PMX_PG_DTA
> > > TEGRA_PMX_CONF_DRIVE_STRENGTH 5>
> > > <&tegra_pmx TEGRA_PMX_PG_DTD
> > > TEGRA_PMX_CONF_DRIVE_STRENGTH 5>
> > > <&tegra_pmx TEGRA_PMX_PG_DTA
> > > TEGRA_PMX_CONF_SLEW_RATE 4>
> > > <&tegra_pmx TEGRA_PMX_PG_DTD
> > > TEGRA_PMX_CONF_SLEW_RATE 8>;
> > > /*
> > > * Perhaps allow additional custom properties here
> to
> > > * express things we haven't thought of. The pinctrl
> > > * drivers would be responsible for parsing them.
> > > */
> > > };
> > > pmx_sdhci_standby: {
> > > mux =
> > > <&tegra_pmx TEGRA_PMX_PG_DTA TEGRA_PMX_MUX_1>
> > > <&tegra_pmx TEGRA_PMX_PG_DTD
> TEGRA_PMX_MUX_1>;
> > > config =
> > > <&tegra_pmx TEGRA_PMX_PG_DTA
> > > TEGRA_PMX_CONF_TRISTATE 1>
> > > <&tegra_pmx TEGRA_PMX_PG_DTD
> > > TEGRA_PMX_CONF_TRISTATE 1>
> > > <&tegra_pmx TEGRA_PMX_PG_DTA
> > > TEGRA_PMX_CONF_DRIVE_STRENGTH 5>
> > > <&tegra_pmx TEGRA_PMX_PG_DTD
> > > TEGRA_PMX_CONF_DRIVE_STRENGTH 5>
> > > <&tegra_pmx TEGRA_PMX_PG_DTA
> > > TEGRA_PMX_CONF_SLEW_RATE 4>
> > > <&tegra_pmx TEGRA_PMX_PG_DTD
> > > TEGRA_PMX_CONF_SLEW_RATE 8>;
> > > };
> > > };
> > > };
> > >
> > > Integer IDs for "muxable entities": Pins on IMX, pin groups on Tegra:
> > >
> > If "muxable entities" is pins on IMX, I'm wondering how we define the
> > predefined Functions and groups or if we still need to do that.
> >
> Let's put this in the example below.
>
> pinmux_usdhc1: pinmux-usdhc1 {
> mux = <IMX6Q_PAD_SD1_DAT1 0>
> <IMX6Q_PAD_SD1_DAT2 0>
> ...
> };
>
Yes, I agree.
And in this way we're still using virtual groups.
It has no big difference as we did before like:
pinmux-groups {
uart4grp: group at 0 {
grp-name = "uart4grp";
grp-pins = <107 108>;
grp-mux = <4 4>;
};
sd4grp: group at 1 {
grp-name = "sd4grp";
grp-pins = <170 171 180 181 182 183 184 185 186 187>;
grp-mux = <0 0 1 1 1 1 1 1 1 1>;
};
};
The real problem is do we need to support individual pin mux
Or still using virtual pin group?
For the way Stephen proposed, we can only support individual pin mux
Since IMX pins are not grouped together in HW.
> pinconf_usdhc1_50mhz: pinconf-usdhc1-50mhz {
> config = <IMX6Q_PAD_SD1_DAT1 IMX6Q_PAD_CONF_ALL 0x834>
> <IMX6Q_PAD_SD1_DAT2 IMX6Q_PAD_CONF_ALL 0x834>
> ...
> };
>
> pinconf_usdhc1_100mhz: pinconf-usdhc1-100mhz {
> config = <IMX6Q_PAD_SD1_DAT1 IMX6Q_PAD_CONF_ALL 0x330>
> <IMX6Q_PAD_SD1_DAT2 IMX6Q_PAD_CONF_ALL 0x330>
> ...
> };
>
> pinconf_usdhc1_200mhz: pinconf-usdhc1-200mhz {
> config = <IMX6Q_PAD_SD1_DAT1 IMX6Q_PAD_CONF_ALL 0x334>
> <IMX6Q_PAD_SD1_DAT2 IMX6Q_PAD_CONF_ALL 0x334>
> ...
> };
>
> pinctrl_usdhc1_50mhz: pinctrl-usdhc1-50mhz {
> pinmux = <&pinmux_usdhc1>;
> pinconf = <&pinconf_usdhc1_50mhz>;
> };
>
> pinctrl_usdhc1_100mhz: pinctrl-usdhc1-100mhz {
> pinmux = <&pinmux_usdhc1>;
> pinconf = <&pinconf_usdhc1_100mhz>;
> };
>
> pinctrl_usdhc1_200mhz: pinctrl-usdhc1-200mhz {
> pinmux = <&pinmux_usdhc1>;
> pinconf = <&pinconf_usdhc1_200mhz>;
> };
>
> usdhc at 02190000 { /* uSDHC1 */
> ...
> pinctrl = <&usdhc1_50mhz>, <&usdhc1_100mhz>, <&usdhc1_200mhz>;
> pinctrl-names = "usdhc1-50mhz", "usdhc1-100mhz", "usdhc1-200mhz";
> };
>
> In this example, we have 3 functions/states for client device usdhc1, "usdhc1-
> 50mhz", "usdhc1-100mhz", and "usdhc1-200mhz". The group is being defined by
> enumerating the pins in property 'mux' of node pinmux_usdhc1.
>
Yes, It's still under development by Linus.
The last patch Linus sent still does not support state change for specific device.
But the method is ok to me.
> > > TEGRA_PMX_PG_DTA
> > > TEGRA_PMX_PG_DTD
> > >
> > > Each individual pinmux driver's bindings needs to define what each
> > > integer ID represents.
> > >
> > Does it mean both pinmux driver and soc.dtsi file need define those
> > macros if dtc Supports constants?
> >
> Yes, I think it does. But we should try to work out some way letting dts and
> linux driver include the same header file to avoid maintaining two copies of the
> same data.
>
I'm also care about the potential consistent issue.
Regards
Dong Aisheng
^ permalink raw reply
* RE: Pinmux bindings proposal
From: Dong Aisheng-B29396 @ 2012-01-17 9:46 UTC (permalink / raw)
To: Shawn Guo
Cc: linus.walleij-0IS4wlFg1OjSUeElwK9/Pw@public.gmane.org,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org,
kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org,
cjb-2X9k7bc8m7Mdnm+yROfE0A@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Dong Aisheng
In-Reply-To: <20120117082334.GA31295-rvtDTF3kK1ictlrPMvKcciBecyulp+rMXqFh9Ls21Oc@public.gmane.org>
> -----Original Message-----
> From: Shawn Guo [mailto:shawn.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org]
> Sent: Tuesday, January 17, 2012 4:24 PM
> To: Dong Aisheng-B29396
> Cc: Stephen Warren; linus.walleij-0IS4wlFg1OjSUeElwK9/Pw@public.gmane.org; s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org;
> rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org; kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org; cjb-2X9k7bc8m7Mdnm+yROfE0A@public.gmane.org; Simon Glass
> (sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org); Dong Aisheng; linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-arm-
> kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org; devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
> Subject: Re: Pinmux bindings proposal
> Importance: High
>
> On Mon, Jan 16, 2012 at 12:50:02PM +0000, Dong Aisheng-B29396 wrote:
> ...
> > > /*
> > > * The actual definition of the complete state of the
> > > * pinmux as required by some driver.
> > > *
> > > * These can be either directly in the device node, or
> > > * somewhere in tegra20.dtsi in order to provide pre-
> > > * selected/common configurations. Hence, they're referred
> > > * to by phandle above.
> > > */
> > > pmx_sdhci_active: {
> > > /*
> > > * Pin mux settings. Mandatory?
> > Mandatory for what?
> >
> > > * Not mandatory if the 1:1 mentioned above is
> > > * extended to 1:n.
> > > *
> > > * Format is <&pmx_controller_phandle
> muxable_entity_id
> > > * selected_function>.
> > > *
> > > * The pmx phandle is required since there may be
> more
> > > * than one pinmux controller in the system. Even if
> > > * this node is inside the pinmux controller itself,
> I
> > > * think it's simpler to just always have this field
> > > * present in the binding for consistency.
> > > *
> > > * Alternative: Format is <&pmx_controller_phandle
> > > * pmx_controller_specific_data>. In this case, the
> > > * pmx controller needs to define #pinmux-mux-cells,
> > > * and provide the pinctrl core with a mapping
> > > * function to handle the rest of the data in the
> > > * property. This is how GPIOs and interrupts work.
> > > * However, this will probably interact badly with
> > > * wanting to parse the entire pinmux map early in
> > > * boot, when perhaps the pinctrl core is
> initialized,
> > > * but the pinctrl driver itself is not.
> > > */
> > > mux =
> > > <&tegra_pmx TEGRA_PMX_PG_DTA TEGRA_PMX_MUX_1>
> > > <&tegra_pmx TEGRA_PMX_PG_DTD TEGRA_PMX_MUX_1>
> > > /* Syntax example */
> > > <&foo_pmx FOO_PMX_PG_X
> > > FOO_PMX_MUX_0>;
> > I'm still think how do we construct the pinmux map for such binding.
> > The format you're using is:
> > <&pmx_controller_phandle muxable_entity_id selected_function> For
> > contruct pinmux map, we need to know at least 3 things for a device:
> > a) pinctrl device b) function name c) group name.
> > For a, we can get it from this binding.
> > But for b and c, since they are constants, how to convert to name string?
> >
> I guess, for function name, it should be retrieved from the client device node,
> and for the group name, it should be retrieved from the node here.
>
I guess Stephen's idea is to retrieving the function name and group name
>From the pinctrl driver since Tagre prefers to define those things in driver
Rather than in board file or soc.dts file.
But it does not fit for IMX since we define it in soc.dts.
> For above example, the function name can be picked from sdhci device node
> pinctr-names property I proposed,
If I understand correctly, the pinctrl-names property you proposed represents
The pin group state.
> and the group name can just be
> 'pmx_sdhci_active', which is not a very nice name here and reminds me the
> following point.
>
No, I don't think it's suitable for group name since pmx_sdhci_active is not a
group node (actually it includes many groups).
> Considering the different pinctrl configurations for the same client device
> usually share the same pinmux and only pinconf varies.
I have the same doubts before.
Is there a real case that device has the different pinmux in different state?
Stephen?
> It may worth introducing
> another level phandle reference. Something like the following:
>
> pinmux_sdhci: pinmux-sdhci {
> mux =
> <&tegra_pmx TEGRA_PMX_PG_DTA TEGRA_PMX_MUX_1>
> <&tegra_pmx TEGRA_PMX_PG_DTD TEGRA_PMX_MUX_1>;
> };
>
> pinconf_sdhci_active: pinconf-sdhci-active {
> config =
> <&tegra_pmx TEGRA_PMX_PG_DTA TEGRA_PMX_CONF_DRIVE_STRENGTH 5>
> <&tegra_pmx TEGRA_PMX_PG_DTD TEGRA_PMX_CONF_DRIVE_STRENGTH 5>
> <&tegra_pmx TEGRA_PMX_PG_DTA TEGRA_PMX_CONF_SLEW_RATE 4>
> <&tegra_pmx TEGRA_PMX_PG_DTD TEGRA_PMX_CONF_SLEW_RATE 8>;
> };
>
> pinconf_sdhci_suspend: pinconf-sdhci-suspend {
> config =
> <&tegra_pmx TEGRA_PMX_PG_DTA TEGRA_PMX_CONF_TRISTATE 1>
> <&tegra_pmx TEGRA_PMX_PG_DTD TEGRA_PMX_CONF_TRISTATE 1>
> <&tegra_pmx TEGRA_PMX_PG_DTA TEGRA_PMX_CONF_DRIVE_STRENGTH 5>
> <&tegra_pmx TEGRA_PMX_PG_DTD TEGRA_PMX_CONF_DRIVE_STRENGTH 5>
> <&tegra_pmx TEGRA_PMX_PG_DTA TEGRA_PMX_CONF_SLEW_RATE 4>
> <&tegra_pmx TEGRA_PMX_PG_DTD TEGRA_PMX_CONF_SLEW_RATE 8>;
> };
>
The config makes sense to me.
The only question is how to get group name to match with the predefined groups.
Besides per pin group configuration support, we may also want per pin configuration
Support as the latest patch sent by Linus.
http://www.spinics.net/lists/arm-kernel/msg155712.html
> pinctrl_sdhci_active: pinctrl-sdhci-active {
> pinmux = <&pinmux_sdhci>;
> pinconf = <&pinconf_sdhci_active>;
> };
>
> pinctrl_sdhci_suspend: pinctrl-sdhci-suspend {
> pinmux = <&pinmux_sdhci>;
> pinconf = <&pinconf_sdhci_suspend>;
> };
>
> sdhci@c8000200 {
> ...
> pinctrl = <&pinctrl_sdhci_active> <&pinctrl_sdhci_suspend>;
> pinctrl-names = "active", "suspend";
> };
>
> This will be pretty useful for imx6 usdhc case, which will have 3 pinctrl
> configuration for each usdhc device (imx6 has 4 usdhc devices), pinctrl-50mhz,
> pinctrl-100mhz and pinctrl-200mhz. All these 3 states have the exactly same
> pinmux settings, and only varies on pinconf.
>
> > > /*
> > > * Pin configuration settings. Optional.
> > > *
> > > * Format is <&pmx_controller_phandle
> muxable_entity_id
> > > * configuration_option configuration_value>.
> > > */
> > > config =
> > > <&tegra_pmx TEGRA_PMX_PG_DTA
> > > TEGRA_PMX_CONF_DRIVE_STRENGTH 5>
> > > <&tegra_pmx TEGRA_PMX_PG_DTD
> > > TEGRA_PMX_CONF_DRIVE_STRENGTH 5>
> > > <&tegra_pmx TEGRA_PMX_PG_DTA
> > > TEGRA_PMX_CONF_SLEW_RATE 4>
> > > <&tegra_pmx TEGRA_PMX_PG_DTD
> > > TEGRA_PMX_CONF_SLEW_RATE 8>;
> > > /*
> > > * Perhaps allow additional custom properties here
> to
> > > * express things we haven't thought of. The pinctrl
> > > * drivers would be responsible for parsing them.
> > > */
> > > };
> > > pmx_sdhci_standby: {
> > > mux =
> > > <&tegra_pmx TEGRA_PMX_PG_DTA TEGRA_PMX_MUX_1>
> > > <&tegra_pmx TEGRA_PMX_PG_DTD
> TEGRA_PMX_MUX_1>;
> > > config =
> > > <&tegra_pmx TEGRA_PMX_PG_DTA
> > > TEGRA_PMX_CONF_TRISTATE 1>
> > > <&tegra_pmx TEGRA_PMX_PG_DTD
> > > TEGRA_PMX_CONF_TRISTATE 1>
> > > <&tegra_pmx TEGRA_PMX_PG_DTA
> > > TEGRA_PMX_CONF_DRIVE_STRENGTH 5>
> > > <&tegra_pmx TEGRA_PMX_PG_DTD
> > > TEGRA_PMX_CONF_DRIVE_STRENGTH 5>
> > > <&tegra_pmx TEGRA_PMX_PG_DTA
> > > TEGRA_PMX_CONF_SLEW_RATE 4>
> > > <&tegra_pmx TEGRA_PMX_PG_DTD
> > > TEGRA_PMX_CONF_SLEW_RATE 8>;
> > > };
> > > };
> > > };
> > >
> > > Integer IDs for "muxable entities": Pins on IMX, pin groups on Tegra:
> > >
> > If "muxable entities" is pins on IMX, I'm wondering how we define the
> > predefined Functions and groups or if we still need to do that.
> >
> Let's put this in the example below.
>
> pinmux_usdhc1: pinmux-usdhc1 {
> mux = <IMX6Q_PAD_SD1_DAT1 0>
> <IMX6Q_PAD_SD1_DAT2 0>
> ...
> };
>
Yes, I agree.
And in this way we're still using virtual groups.
It has no big difference as we did before like:
pinmux-groups {
uart4grp: group@0 {
grp-name = "uart4grp";
grp-pins = <107 108>;
grp-mux = <4 4>;
};
sd4grp: group@1 {
grp-name = "sd4grp";
grp-pins = <170 171 180 181 182 183 184 185 186 187>;
grp-mux = <0 0 1 1 1 1 1 1 1 1>;
};
};
The real problem is do we need to support individual pin mux
Or still using virtual pin group?
For the way Stephen proposed, we can only support individual pin mux
Since IMX pins are not grouped together in HW.
> pinconf_usdhc1_50mhz: pinconf-usdhc1-50mhz {
> config = <IMX6Q_PAD_SD1_DAT1 IMX6Q_PAD_CONF_ALL 0x834>
> <IMX6Q_PAD_SD1_DAT2 IMX6Q_PAD_CONF_ALL 0x834>
> ...
> };
>
> pinconf_usdhc1_100mhz: pinconf-usdhc1-100mhz {
> config = <IMX6Q_PAD_SD1_DAT1 IMX6Q_PAD_CONF_ALL 0x330>
> <IMX6Q_PAD_SD1_DAT2 IMX6Q_PAD_CONF_ALL 0x330>
> ...
> };
>
> pinconf_usdhc1_200mhz: pinconf-usdhc1-200mhz {
> config = <IMX6Q_PAD_SD1_DAT1 IMX6Q_PAD_CONF_ALL 0x334>
> <IMX6Q_PAD_SD1_DAT2 IMX6Q_PAD_CONF_ALL 0x334>
> ...
> };
>
> pinctrl_usdhc1_50mhz: pinctrl-usdhc1-50mhz {
> pinmux = <&pinmux_usdhc1>;
> pinconf = <&pinconf_usdhc1_50mhz>;
> };
>
> pinctrl_usdhc1_100mhz: pinctrl-usdhc1-100mhz {
> pinmux = <&pinmux_usdhc1>;
> pinconf = <&pinconf_usdhc1_100mhz>;
> };
>
> pinctrl_usdhc1_200mhz: pinctrl-usdhc1-200mhz {
> pinmux = <&pinmux_usdhc1>;
> pinconf = <&pinconf_usdhc1_200mhz>;
> };
>
> usdhc@02190000 { /* uSDHC1 */
> ...
> pinctrl = <&usdhc1_50mhz>, <&usdhc1_100mhz>, <&usdhc1_200mhz>;
> pinctrl-names = "usdhc1-50mhz", "usdhc1-100mhz", "usdhc1-200mhz";
> };
>
> In this example, we have 3 functions/states for client device usdhc1, "usdhc1-
> 50mhz", "usdhc1-100mhz", and "usdhc1-200mhz". The group is being defined by
> enumerating the pins in property 'mux' of node pinmux_usdhc1.
>
Yes, It's still under development by Linus.
The last patch Linus sent still does not support state change for specific device.
But the method is ok to me.
> > > TEGRA_PMX_PG_DTA
> > > TEGRA_PMX_PG_DTD
> > >
> > > Each individual pinmux driver's bindings needs to define what each
> > > integer ID represents.
> > >
> > Does it mean both pinmux driver and soc.dtsi file need define those
> > macros if dtc Supports constants?
> >
> Yes, I think it does. But we should try to work out some way letting dts and
> linux driver include the same header file to avoid maintaining two copies of the
> same data.
>
I'm also care about the potential consistent issue.
Regards
Dong Aisheng
^ permalink raw reply
* [Qemu-devel] [PATCH v2] lm32: Fix mixup of uint32 and uint32_t
From: Andreas Färber @ 2012-01-17 9:44 UTC (permalink / raw)
To: qemu-devel
Cc: qemu-trivial, Peter Maydell, Michael Walle, Andreas Färber,
Edgar E. Iglesias
In-Reply-To: <1326674823-13069-2-git-send-email-afaerber@suse.de>
Commit d23948b15a9920fb7f6374b55a6db1ecff81f3ee (lm32: add Milkymist
VGAFB support) introduced a stray usage of the softfloat uint32 type.
Use uint32_t instead.
Signed-off-by: Andreas Färber <afaerber@suse.de>
Acked-by: Michael Walle <michael@walle.cc>
Cc: Peter Maydell <peter.maydell@linaro.org>
---
hw/milkymist-vgafb_template.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/hw/milkymist-vgafb_template.h b/hw/milkymist-vgafb_template.h
index 69af9ef..1d33ee8 100644
--- a/hw/milkymist-vgafb_template.h
+++ b/hw/milkymist-vgafb_template.h
@@ -39,7 +39,7 @@
#elif BITS == 24
#define COPY_PIXEL(to, r, g, b) \
do { \
- uint32 tmp = rgb_to_pixel24(r, g, b); \
+ uint32_t tmp = rgb_to_pixel24(r, g, b); \
*(to++) = tmp & 0xff; \
*(to++) = (tmp >> 8) & 0xff; \
*(to++) = (tmp >> 16) & 0xff; \
--
1.7.7
^ permalink raw reply related
* Re: ecryptfs doesn´t like noauto and noatime
From: Jakob Unterwurzacher @ 2012-01-17 9:46 UTC (permalink / raw)
To: Martin Steigerwald; +Cc: ecryptfs
In-Reply-To: <201201170937.10613.Martin@lichtvoll.de>
On 17.01.2012 09:37, Martin Steigerwald wrote:
> Am Dienstag, 17. Januar 2012 schrieb Jakob Unterwurzacher:
>> On 16.01.2012 10:44, Martin Steigerwald wrote:
>>> Hi!
>>>
>>> I have
>>>
>>> merkaba:~> grep ecrypt /etc/fstab
>>> /home/.ms /home/ms ecryptfs
>>> noatime,noauto 0 0
>>>
>>> And get:
>>>
>>> merkaba:~> mount /home/ms
>>> Passphrase:
> […]
>>> Error mounting eCryptfs: [-5] Input/output error
> […]
>>> Still it works.
>>>
>>>
>>> In dmesg I see:
>>>
>>> [ 2657.888355] ecryptfs_parse_options: eCryptfs: unrecognized option
>>> [noauto]
>>> [ 2657.888359] ecryptfs_parse_options: eCryptfs: unrecognized option
>>> [noatime]
>>> [ 2657.913215] alg: No test for __gcm-aes-aesni
>>> (__driver-gcm-aes-aesni)
>>>
>>>
>>> Thus I removed at least noatime, but then I still see:
>>>
>>> [ 2839.460200] ecryptfs_parse_options: eCryptfs: unrecognized option
>>> [noauto]
> […]
>>> Without noatime it would ask me the passwort upon boot, but I do not
>>> like that since I do not use that user everytime.
>
> noauto that is.
>
>>> I could use mounting via pam, but I like to have a different password
>>> for the user stored in /etc/shadow than the password from the
>>> filesystem itself.
>>
>> Note that this should work by creating ~/.ecryptfs/wrapping-independent
>> . Pam will ask for the ecryptfs password explicitely then.
>
> Thanks.
>
> Would that also work within a display manager like kdm?
>
> Ciao,
Yes! It will ask for two passwords on login.
Jakob
^ permalink raw reply
* Re: [PATCH 0/8] ipset patches
From: Pablo Neira Ayuso @ 2012-01-17 9:46 UTC (permalink / raw)
To: Jozsef Kadlecsik; +Cc: netfilter-devel, Patrick McHardy
In-Reply-To: <alpine.DEB.2.00.1201170913450.2015@blackhole.kfki.hu>
On Tue, Jan 17, 2012 at 09:18:51AM +0100, Jozsef Kadlecsik wrote:
> On Tue, 17 Jan 2012, Pablo Neira Ayuso wrote:
>
> > On Mon, Jan 16, 2012 at 01:45:59PM +0100, Pablo Neira Ayuso wrote:
> > > > Jan Engelhardt (3):
> > > > netfilter: ipset: use NFPROTO_ constants
> > > > netfilter: ipset: avoid use of kernel-only types
> > > > netfilter: ipset: expose userspace-relevant parts in ip_set.h
> > > >
> > > > Jozsef Kadlecsik (5):
> > > > netfilter: ipset: Autoload set type modules safely
> > > > netfilter: ipset: Dumping error triggered removing references twice
> > > > netfilter: ipset: Log warning when a hash type of set gets full
> > > > netfilter: ipset: Exceptions support added to hash:*net* types
> > > > netfilter: ipset: hash:net,iface timeout bug fixed
> >
> > If you tell me what patches are bugfixes, we can still pass them to
> > get them included into 3.3-rc.
>
> Then please cherry-pick at least these two patches:
>
> netfilter: ipset: Autoload set type modules safely
> netfilter: ipset: Dumping error triggered removing references twice
Thanks. I've scheduled these two for 3.2-rc.
^ permalink raw reply
* [Qemu-trivial] [PATCH v2] lm32: Fix mixup of uint32 and uint32_t
From: Andreas Färber @ 2012-01-17 9:44 UTC (permalink / raw)
To: qemu-devel
Cc: qemu-trivial, Peter Maydell, Michael Walle, Andreas Färber,
Edgar E. Iglesias
In-Reply-To: <1326674823-13069-2-git-send-email-afaerber@suse.de>
Commit d23948b15a9920fb7f6374b55a6db1ecff81f3ee (lm32: add Milkymist
VGAFB support) introduced a stray usage of the softfloat uint32 type.
Use uint32_t instead.
Signed-off-by: Andreas Färber <afaerber@suse.de>
Acked-by: Michael Walle <michael@walle.cc>
Cc: Peter Maydell <peter.maydell@linaro.org>
---
hw/milkymist-vgafb_template.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/hw/milkymist-vgafb_template.h b/hw/milkymist-vgafb_template.h
index 69af9ef..1d33ee8 100644
--- a/hw/milkymist-vgafb_template.h
+++ b/hw/milkymist-vgafb_template.h
@@ -39,7 +39,7 @@
#elif BITS == 24
#define COPY_PIXEL(to, r, g, b) \
do { \
- uint32 tmp = rgb_to_pixel24(r, g, b); \
+ uint32_t tmp = rgb_to_pixel24(r, g, b); \
*(to++) = tmp & 0xff; \
*(to++) = (tmp >> 8) & 0xff; \
*(to++) = (tmp >> 16) & 0xff; \
--
1.7.7
^ permalink raw reply related
* Re: [PATCH] libxl_pci: check that host device is assignable before adding to the domain
From: Ian Campbell @ 2012-01-17 9:47 UTC (permalink / raw)
To: Doug Magee; +Cc: xen-devel@lists.xensource.com, Ian Jackson, Stefano Stabellini
In-Reply-To: <301cc006677f645bf4cb.1326753363@mnetdjm4.mageenet.host>
On Mon, 2012-01-16 at 22:36 +0000, Doug Magee wrote:
> Previously, on ..._pci_add, libxl only checks that a device is not assigned to another domain. This quick patch checks that the device is also owned by pciback, otherwise the call fails.
>
> Signed-off-by: Doug Magee <djmagee@mageenet.net>
Thanks Doug. Would this be better done by adding a call to
libxl_device_pci_list_assignable and looking for the device in it? In
fact from the looks of things this could replace the existing call to
get_all_assigned_devices from .._pci_add since
libxl_device_pci_list_assignable already omits devices which are
assigned to another domain.
Ian.
>
> diff -r 5b2676ac1321 -r 301cc006677f tools/libxl/libxl_pci.c
> --- a/tools/libxl/libxl_pci.c Mon Jan 09 16:01:44 2012 +0100
> +++ b/tools/libxl/libxl_pci.c Mon Jan 16 17:31:25 2012 -0500
> @@ -796,6 +796,9 @@ int libxl__device_pci_add(libxl__gc *gc,
> libxl_device_pci *assigned;
> int num_assigned, i, rc;
> int stubdomid = 0;
> + struct dirent *de;
> + DIR *dir;
> + int assignable = 0;
>
> rc = get_all_assigned_devices(gc, &assigned, &num_assigned);
> if ( rc ) {
> @@ -809,6 +812,35 @@ int libxl__device_pci_add(libxl__gc *gc,
> goto out;
> }
>
> + dir = opendir(SYSFS_PCIBACK_DRIVER);
> + if ( NULL == dir ) {
> + if ( errno == ENOENT ) {
> + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Looks like pciback driver not loaded");
> + }else{
> + LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Couldn't open %s", SYSFS_PCIBACK_DRIVER);
> + }
> + rc = ERROR_FAIL;
> + goto out_closedir;
> + }
> +
> + while( (de = readdir(dir)) ) {
> + unsigned dom, bus, dev, func;
> + if ( sscanf(de->d_name, PCI_BDF, &dom, &bus, &dev, &func) != 4 )
> + continue;
> + if ( dom == pcidev->domain && bus == pcidev->bus &&
> + dev == pcidev->dev && func == pcidev->func ) {
> + assignable = 1;
> + break;
> + }
> + }
> +
> + if ( !assignable ) {
> + rc = ERROR_FAIL;
> + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "PCI device not owned by pciback");
> + goto out_closedir;
> + }
> +
> +
> libxl__device_pci_reset(gc, pcidev->domain, pcidev->bus, pcidev->dev, pcidev->func);
>
> stubdomid = libxl_get_stubdom_id(ctx, domid);
> @@ -817,7 +849,7 @@ int libxl__device_pci_add(libxl__gc *gc,
> /* stubdomain is always running by now, even at create time */
> rc = do_pci_add(gc, stubdomid, &pcidev_s, 0);
> if ( rc )
> - goto out;
> + goto out_closedir;
> }
>
> orig_vdev = pcidev->vdevfn & ~7U;
> @@ -826,11 +858,11 @@ int libxl__device_pci_add(libxl__gc *gc,
> if ( !(pcidev->vdevfn >> 3) ) {
> LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Must specify a v-slot for multi-function devices");
> rc = ERROR_INVAL;
> - goto out;
> + goto out_closedir;
> }
> if ( pci_multifunction_check(gc, pcidev, &pfunc_mask) ) {
> rc = ERROR_FAIL;
> - goto out;
> + goto out_closedir;
> }
> pcidev->vfunc_mask &= pfunc_mask;
> /* so now vfunc_mask == pfunc_mask */
> @@ -855,6 +887,8 @@ int libxl__device_pci_add(libxl__gc *gc,
> }
> }
>
> +out_closedir:
> + closedir(dir);
> out:
> return rc;
> }
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
^ 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.