* [PATCH v2] regulator: max8649 Convert max8649 to use regmap api
From: Mark Brown @ 2011-10-24 13:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1319462786-2602-1-git-send-email-jhbird.choi@gmail.com>
On Mon, Oct 24, 2011 at 10:26:26PM +0900, jhbird.choi at gmail.com wrote:
> From: Jonghwan Choi <jhbird.choi@gmail.com>
>
> Signed-off-by: Jonghwan Choi <jhbird.choi@gmail.com>
Looks good!
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Once the merge window is over it might be useful to look at enabling
register cache for the driver, you'll get a performance improvement as
it'll be able to skip the read part of read/modify/write cycles.
^ permalink raw reply
* Re: [PATCH v2] regulator: max8649 Convert max8649 to use regmap api
From: Mark Brown @ 2011-10-24 13:46 UTC (permalink / raw)
To: jhbird.choi; +Cc: linux-arm-kernel, linux-kernel, Liam Girdwood, Haojian Zhuang
In-Reply-To: <1319462786-2602-1-git-send-email-jhbird.choi@gmail.com>
On Mon, Oct 24, 2011 at 10:26:26PM +0900, jhbird.choi@gmail.com wrote:
> From: Jonghwan Choi <jhbird.choi@gmail.com>
>
> Signed-off-by: Jonghwan Choi <jhbird.choi@gmail.com>
Looks good!
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Once the merge window is over it might be useful to look at enabling
register cache for the driver, you'll get a performance improvement as
it'll be able to skip the read part of read/modify/write cycles.
^ permalink raw reply
* Re: Memory leak in isp1760-hcd.c
From: Arvid Brodin @ 2011-10-24 13:46 UTC (permalink / raw)
To: Catalin Marinas; +Cc: linux-usb, linux-kernel
In-Reply-To: <CAHkRjk6VBgFJTCcBp80wuJrGBp=0Nt302+jRw3TELcT1vFwJ7g@mail.gmail.com>
Catalin Marinas wrote:
> On 24 October 2011 14:50, Arvid Brodin <arvid.brodin@enea.com> wrote:
>> Catalin Marinas wrote:
>>> I get the following kmemleak report coming from the ISP1760 driver:
>>>
>> *snip*
>>> Is there a race condition between isp1760_endpoint_disable and
>>> isp1760_irq?
>> Yes, I think there is. Thanks for a great bug report!
>>
>> Please try the patches in following emails.
>
> Thanks. I'll try them next week as I'm at the KS now.
>
> The good news, I'm using this leak as an example in my kmemleak presentations :)
>
Hehe, what can I say... I'm honoured to be made an example of! ;D
--
Arvid Brodin
Enea Services Stockholm AB
^ permalink raw reply
* multipath-tools/multipathd main.c
From: bmarzins @ 2011-10-24 13:46 UTC (permalink / raw)
To: dm-cvs, dm-devel
CVSROOT: /cvs/dm
Module name: multipath-tools
Branch: RHEL5_FC6
Changes by: bmarzins@sourceware.org 2011-10-24 13:46:54
Modified files:
multipathd : main.c
Log message:
fix for bz #741664. setup_multipath frees the multipath device if it fails,
so check the return value, and don't touch the multipath device, it
setup_multipath() has returned 1.
Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/multipath-tools/multipathd/main.c.diff?cvsroot=dm&only_with_tag=RHEL5_FC6&r1=1.69.2.37&r2=1.69.2.38
--- multipath-tools/multipathd/main.c 2011/10/10 04:15:41 1.69.2.37
+++ multipath-tools/multipathd/main.c 2011/10/24 13:46:54 1.69.2.38
@@ -988,7 +988,8 @@
return 1;
}
dm_lib_release();
- setup_multipath(vecs, mpp);
+ if (setup_multipath(vecs, mpp) != 0)
+ return 1;
sync_map_state(mpp);
return 0;
^ permalink raw reply
* Channel-less IIO events
From: Lars-Peter Clausen @ 2011-10-24 13:47 UTC (permalink / raw)
To: Jonathan Cameron; +Cc: linux-iio@vger.kernel.org
Hi,
Some chips generate events which don't really map to a channel, but are
rather chip global. For example over-temperature events.
Do you think this is something we should add support for or should we rather
use a dummy channel, which doesn't report any actual values, for propagating
the event?
My idea for supporting channel-less events is to add a event_mask to struct
iio_info, which would be used just like a channels event_mask, but there
would be no index for the sysfs attributes and for events we would set the
event number to 0xffff.
Thanks
- Lars
^ permalink raw reply
* Re: [PATCH v2 3/5] regulator: helper routine to extract regulator_init_data
From: Shawn Guo @ 2011-10-24 13:47 UTC (permalink / raw)
To: Rajendra Nayak
Cc: Grant Likely, broonie, patches, tony, devicetree-discuss,
linux-kernel, linux-omap, lrg, linux-arm-kernel
In-Reply-To: <4EA52C56.3080908@ti.com>
On Mon, Oct 24, 2011 at 02:43:58PM +0530, Rajendra Nayak wrote:
> Case 2:
> One device for all regulators:
>
> DT nodes look something like this
>
> regulators {
> reg1: reg@1 {
> ...
> ...
> };
>
> reg2: reg@2 {
> ...
> ...
> };
> };
>
> The regulator driver probes only one device and the dev->of_node
> points to the "regulators" node above.
The mc13892 example I put in the reply to Grant demonstrates that
for some case, dev->of_node is NULL (devices are created by mfd core).
> The regulator driver then based on compatible property extracts
> and registers all the child nodes of "regulators" (for ex: reg1, reg2
> above) with each call to regulator_register and passes the child nodes
> as of_node to be associated with the regulator device.
>
I still think the discovery of all the child nodes of "regulators" does
not necessarily need to be done in regulator driver. Instead, it can
be done in regulator core.
--
Regards,
Shawn
^ permalink raw reply
* [PATCH v2 3/5] regulator: helper routine to extract regulator_init_data
From: Shawn Guo @ 2011-10-24 13:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4EA52C56.3080908@ti.com>
On Mon, Oct 24, 2011 at 02:43:58PM +0530, Rajendra Nayak wrote:
> Case 2:
> One device for all regulators:
>
> DT nodes look something like this
>
> regulators {
> reg1: reg at 1 {
> ...
> ...
> };
>
> reg2: reg at 2 {
> ...
> ...
> };
> };
>
> The regulator driver probes only one device and the dev->of_node
> points to the "regulators" node above.
The mc13892 example I put in the reply to Grant demonstrates that
for some case, dev->of_node is NULL (devices are created by mfd core).
> The regulator driver then based on compatible property extracts
> and registers all the child nodes of "regulators" (for ex: reg1, reg2
> above) with each call to regulator_register and passes the child nodes
> as of_node to be associated with the regulator device.
>
I still think the discovery of all the child nodes of "regulators" does
not necessarily need to be done in regulator driver. Instead, it can
be done in regulator core.
--
Regards,
Shawn
^ permalink raw reply
* [U-Boot] Accessing MC13783 RTC registers
From: Stefano Babic @ 2011-10-24 13:48 UTC (permalink / raw)
To: u-boot
In-Reply-To: <CAOMZO5B0uMjJNXOvjt4UOFi1Afvrp1tviJ_-yrunp+9VXcqYaQ@mail.gmail.com>
On 10/24/2011 03:18 PM, Fabio Estevam wrote:
> Hi,
>
> Running U-boot from top of tree imx git I get the following when
> trying to access the MC13783 RTC registers via 'date' command:
>
> MX31PDK U-Boot > date
> <reg num> = 22 is invalid. Should be less than 0
> ## Get date failed
>
> Does anyone else see this same problem on other boards?
>
Hi Fabio,
I did the same on the qong board to check this issue. On the qong board
it works:
date
Date: 1970-01-05 (Monday) Time: 23:32:35
=> pmic dump
PMIC: FSL_PMIC
0x00: 00081000 00e9ffff 00085800 00000801 00ffffff 00004838 00009546
0000009d
0x08: 00000000 00000000 00000000 00000000 00000000 00800040 00000000
00000000
0x10: 00200000 00000000 00000000 00000000 00014b1b 0001ffff 00000004
00007fff
0x18: 0001c71c 0001c71c 00024924 00024924 00221605 001e1605 00063eac
00000b7c
0x20: 00249249 00249240 00018000 00000000 00001000 0000d35a 00420000
00013060
0x28: 00180027 000e0004 00000000 00008000 00000000 00fdffdf 00000080
00000000
0x30: 00000000 000e0060 00000006 00000000 00000000 00000000 00000000
00000000
0x38: 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000
=>
Of course, Helmut's patch (already merged in u-boot-imx) is required.
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
* Re: [PATCH v2 3/5] regulator: helper routine to extract regulator_init_data
From: Mark Brown @ 2011-10-24 13:49 UTC (permalink / raw)
To: Shawn Guo
Cc: Grant Likely, Rajendra Nayak, patches, tony, devicetree-discuss,
linux-kernel, linux-omap, lrg, linux-arm-kernel
In-Reply-To: <20111024134025.GE1755@S2100-06.ap.freescale.net>
On Mon, Oct 24, 2011 at 09:40:26PM +0800, Shawn Guo wrote:
> +++ b/drivers/regulator/core.c
> @@ -2673,7 +2673,8 @@ struct regulator_dev *regulator_register(struct regulator_desc *regulator_desc,
> BLOCKING_INIT_NOTIFIER_HEAD(&rdev->notifier);
>
> /* find device_node and attach it */
> - rdev->dev.of_node = of_find_node_by_name(NULL, regulator_desc->name);
> + rdev->dev.of_node = of_find_node_by_name(dev->parent->of_node,
> + regulator_desc->name);
>
Is that going to do the right thing if you've got a MFD which does
register each regulator as a separate device? Might be best to just
search within dev and get drivers to pass the "real" device in when
registering the regulator rather than the virtual device.
^ permalink raw reply
* [PATCH v2 3/5] regulator: helper routine to extract regulator_init_data
From: Mark Brown @ 2011-10-24 13:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111024134025.GE1755@S2100-06.ap.freescale.net>
On Mon, Oct 24, 2011 at 09:40:26PM +0800, Shawn Guo wrote:
> +++ b/drivers/regulator/core.c
> @@ -2673,7 +2673,8 @@ struct regulator_dev *regulator_register(struct regulator_desc *regulator_desc,
> BLOCKING_INIT_NOTIFIER_HEAD(&rdev->notifier);
>
> /* find device_node and attach it */
> - rdev->dev.of_node = of_find_node_by_name(NULL, regulator_desc->name);
> + rdev->dev.of_node = of_find_node_by_name(dev->parent->of_node,
> + regulator_desc->name);
>
Is that going to do the right thing if you've got a MFD which does
register each regulator as a separate device? Might be best to just
search within dev and get drivers to pass the "real" device in when
registering the regulator rather than the virtual device.
^ permalink raw reply
* [PATCH 0/2] mmc: mmci: Bugfixes for SDIO
From: Ulf Hansson @ 2011-10-24 13:50 UTC (permalink / raw)
To: linux-arm-kernel
This patchserie fixes some SDIO related issues for the mmci host driver.
Previously these patches were included in the patch serie called
"mmc: mmci: Improvements and bugfixes for SDIO", which now has been
split up.
Stefan Nilsson XK (1):
mmc: mmci: Fix incorrect handling of HW flow control for SDIO
Ulf Hansson (1):
mmc: mmci: Prepare for SDIO before setting up DMA job
drivers/mmc/host/mmci.c | 50 ++++++++++++++++++++++++++--------------------
1 files changed, 28 insertions(+), 22 deletions(-)
--
1.7.5.4
^ permalink raw reply
* [PATCH 1/2] mmc: mmci: Prepare for SDIO before setting up DMA job
From: Ulf Hansson @ 2011-10-24 13:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1319464243-16638-1-git-send-email-ulf.hansson@stericsson.com>
Move the SDIO preparation to be done before the DMA job is setup.
This makes it possible to do DMA for SDIO transfers as well as the
earlier supported pio mode.
Signed-off-by: Ulf Hansson <ulf.hansson@stericsson.com>
Signed-off-by: Stefan Nilsson XK <stefan.xk.nilsson@stericsson.com>
---
drivers/mmc/host/mmci.c | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index 50b5f99..1b73177 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -604,6 +604,11 @@ static void mmci_start_data(struct mmci_host *host, struct mmc_data *data)
if (data->flags & MMC_DATA_READ)
datactrl |= MCI_DPSM_DIRECTION;
+ /* The ST Micro variants has a special bit to enable SDIO */
+ if (variant->sdio && host->mmc->card)
+ if (mmc_card_sdio(host->mmc->card))
+ datactrl |= MCI_ST_DPSM_SDIOEN;
+
/*
* Attempt to use DMA operation mode, if this
* should fail, fall back to PIO mode
@@ -632,11 +637,6 @@ static void mmci_start_data(struct mmci_host *host, struct mmc_data *data)
irqmask = MCI_TXFIFOHALFEMPTYMASK;
}
- /* The ST Micro variants has a special bit to enable SDIO */
- if (variant->sdio && host->mmc->card)
- if (mmc_card_sdio(host->mmc->card))
- datactrl |= MCI_ST_DPSM_SDIOEN;
-
writel(datactrl, base + MMCIDATACTRL);
writel(readl(base + MMCIMASK0) & ~MCI_DATAENDMASK, base + MMCIMASK0);
mmci_set_mask1(host, irqmask);
--
1.7.5.4
^ permalink raw reply related
* [PATCH 2/2] mmc: mmci: Fix incorrect handling of HW flow control for SDIO
From: Ulf Hansson @ 2011-10-24 13:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1319464243-16638-1-git-send-email-ulf.hansson@stericsson.com>
From: Stefan Nilsson XK <stefan.xk.nilsson@stericsson.com>
For data writes smaller <= 8 bytes (only SDIO case), HW flow control was
disabled but never re-enabled again. This meant that a following large read
request would randomly give buffer overrun errors.
Moreover HW flow control is not needed for transfers that fits in the
FIFO of PL18x. Thus it is disabled for write operations <= the FIFO size.
Signed-off-by: Ulf Hansson <ulf.hansson@stericsson.com>
Signed-off-by: Stefan Nilsson XK <stefan.xk.nilsson@stericsson.com>
---
drivers/mmc/host/mmci.c | 42 ++++++++++++++++++++++++------------------
1 files changed, 24 insertions(+), 18 deletions(-)
diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index 1b73177..07d1378 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -606,9 +606,32 @@ static void mmci_start_data(struct mmci_host *host, struct mmc_data *data)
/* The ST Micro variants has a special bit to enable SDIO */
if (variant->sdio && host->mmc->card)
- if (mmc_card_sdio(host->mmc->card))
+ if (mmc_card_sdio(host->mmc->card)) {
+ /*
+ * The ST Micro variants has a special bit
+ * to enable SDIO.
+ */
datactrl |= MCI_ST_DPSM_SDIOEN;
+ /*
+ * The ST Micro variant for SDIO transfer sizes
+ * less then or equal to 8 bytes needs to have clock
+ * H/W flow control disabled. Since flow control is
+ * not really needed for anything that fits in the
+ * FIFO, we can disable it for any write smaller
+ * than the FIFO size.
+ */
+ if ((host->size <= variant->fifosize) &&
+ (data->flags & MMC_DATA_WRITE))
+ writel(readl(host->base + MMCICLOCK) &
+ ~variant->clkreg_enable,
+ host->base + MMCICLOCK);
+ else
+ writel(readl(host->base + MMCICLOCK) |
+ variant->clkreg_enable,
+ host->base + MMCICLOCK);
+ }
+
/*
* Attempt to use DMA operation mode, if this
* should fail, fall back to PIO mode
@@ -807,23 +830,6 @@ static int mmci_pio_write(struct mmci_host *host, char *buffer, unsigned int rem
count = min(remain, maxcnt);
/*
- * The ST Micro variant for SDIO transfer sizes
- * less then 8 bytes should have clock H/W flow
- * control disabled.
- */
- if (variant->sdio &&
- mmc_card_sdio(host->mmc->card)) {
- if (count < 8)
- writel(readl(host->base + MMCICLOCK) &
- ~variant->clkreg_enable,
- host->base + MMCICLOCK);
- else
- writel(readl(host->base + MMCICLOCK) |
- variant->clkreg_enable,
- host->base + MMCICLOCK);
- }
-
- /*
* SDIO especially may want to send something that is
* not divisible by 4 (as opposed to card sectors
* etc), and the FIFO only accept full 32-bit writes.
--
1.7.5.4
^ permalink raw reply related
* Re: [PATCH RFC V2 3/5] kvm hypervisor : Add two hypercalls to support pv-ticketlock
From: Srivatsa Vaddagiri @ 2011-10-24 13:50 UTC (permalink / raw)
To: Avi Kivity
Cc: Raghavendra K T, Greg Kroah-Hartman, H. Peter Anvin, Gleb Natapov,
Virtualization, Jeremy Fitzhardinge, x86, KVM, Dave Jiang,
Thomas Gleixner, Stefano Stabellini, Xen, Sedat Dilek, Yinghai Lu,
Marcelo Tosatti, Ingo Molnar, Rik van Riel, Konrad Rzeszutek Wilk,
LKML, Suzuki Poulose, Peter Zijlstra
In-Reply-To: <4EA56385.9040302@redhat.com>
* Avi Kivity <avi@redhat.com> [2011-10-24 15:09:25]:
> > I guess with that change, we can also dropthe need for other hypercall
> > introduced in this patch (kvm_pv_kick_cpu_op()). Essentially a vcpu sleeping
> > because of HLT instruction can be woken up by a IPI issued by vcpu releasing a
> > lock.
>
> Not if interrupts are disabled.
Hmm yes ..so we need a kick hypercall then.
- vatsa
^ permalink raw reply
* [U-Boot] [PATCH 3/3] nds32: asm/io.h: add __iormb and __iowmb support
From: 馬克泡 @ 2011-10-24 13:50 UTC (permalink / raw)
To: u-boot
In-Reply-To: <201110241538.17701.marek.vasut@gmail.com>
Hi Marek,
2011/10/24 Marek Vasut <marek.vasut@gmail.com>
> Hi,
>
> can you possibly implement those as inline functions ? It'd be also great
> if you
> could convert the other macros to inline functions.
>
> Thanks!
>
Thanks for your comment.
I'll try to do it tomorrow (GMT +0800).
--
Best regards,
Macpaul Lin
^ permalink raw reply
* [PATCH 0/2] mmc: mmci: Bugfixes for SDIO
From: Ulf Hansson @ 2011-10-24 13:50 UTC (permalink / raw)
To: linux-mmc, linux-arm-kernel; +Cc: Russell King, Ulf Hansson, Lee Jones
This patchserie fixes some SDIO related issues for the mmci host driver.
Previously these patches were included in the patch serie called
"mmc: mmci: Improvements and bugfixes for SDIO", which now has been
split up.
Stefan Nilsson XK (1):
mmc: mmci: Fix incorrect handling of HW flow control for SDIO
Ulf Hansson (1):
mmc: mmci: Prepare for SDIO before setting up DMA job
drivers/mmc/host/mmci.c | 50 ++++++++++++++++++++++++++--------------------
1 files changed, 28 insertions(+), 22 deletions(-)
--
1.7.5.4
^ permalink raw reply
* [PATCH 1/2] mmc: mmci: Prepare for SDIO before setting up DMA job
From: Ulf Hansson @ 2011-10-24 13:50 UTC (permalink / raw)
To: linux-mmc, linux-arm-kernel
Cc: Russell King, Ulf Hansson, Lee Jones, Stefan Nilsson XK
In-Reply-To: <1319464243-16638-1-git-send-email-ulf.hansson@stericsson.com>
Move the SDIO preparation to be done before the DMA job is setup.
This makes it possible to do DMA for SDIO transfers as well as the
earlier supported pio mode.
Signed-off-by: Ulf Hansson <ulf.hansson@stericsson.com>
Signed-off-by: Stefan Nilsson XK <stefan.xk.nilsson@stericsson.com>
---
drivers/mmc/host/mmci.c | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index 50b5f99..1b73177 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -604,6 +604,11 @@ static void mmci_start_data(struct mmci_host *host, struct mmc_data *data)
if (data->flags & MMC_DATA_READ)
datactrl |= MCI_DPSM_DIRECTION;
+ /* The ST Micro variants has a special bit to enable SDIO */
+ if (variant->sdio && host->mmc->card)
+ if (mmc_card_sdio(host->mmc->card))
+ datactrl |= MCI_ST_DPSM_SDIOEN;
+
/*
* Attempt to use DMA operation mode, if this
* should fail, fall back to PIO mode
@@ -632,11 +637,6 @@ static void mmci_start_data(struct mmci_host *host, struct mmc_data *data)
irqmask = MCI_TXFIFOHALFEMPTYMASK;
}
- /* The ST Micro variants has a special bit to enable SDIO */
- if (variant->sdio && host->mmc->card)
- if (mmc_card_sdio(host->mmc->card))
- datactrl |= MCI_ST_DPSM_SDIOEN;
-
writel(datactrl, base + MMCIDATACTRL);
writel(readl(base + MMCIMASK0) & ~MCI_DATAENDMASK, base + MMCIMASK0);
mmci_set_mask1(host, irqmask);
--
1.7.5.4
^ permalink raw reply related
* Re: [patch net-next V4] net: introduce ethernet teaming device
From: Jiri Pirko @ 2011-10-24 13:50 UTC (permalink / raw)
To: Benjamin Poirier
Cc: netdev, davem, eric.dumazet, bhutchings, shemminger, fubar, andy,
tgraf, ebiederm, mirqus, kaber, greearb, jesse, fbl, jzupka,
Dipankar Sarma, Paul E. McKenney
In-Reply-To: <20111024130918.GB24473@synalogic.ca>
Mon, Oct 24, 2011 at 03:09:19PM CEST, benjamin.poirier@gmail.com wrote:
>On 11/10/24 10:13, Jiri Pirko wrote:
>> This patch introduces new network device called team. It supposes to be
>> very fast, simple, userspace-driven alternative to existing bonding
>> driver.
>>
>> Userspace library called libteam with couple of demo apps is available
>> here:
>> https://github.com/jpirko/libteam
>> Note it's still in its dipers atm.
>>
>> team<->libteam use generic netlink for communication. That and rtnl
>> suppose to be the only way to configure team device, no sysfs etc.
>>
>> Python binding basis for libteam was recently introduced (some need
>> still need to be done on it though). Daemon providing arpmon/miimon
>> active-backup functionality will be introduced shortly.
>> All what's necessary is already implemented in kernel team driver.
>>
>> Signed-off-by: Jiri Pirko <jpirko@redhat.com>
>>
>> v3->v4:
>> - remove redundant synchronize_rcu from __team_change_mode()
>> - revert "set and clear of mode_ops happens per pointer, not per
>> byte"
>> - extend comment of function __team_change_mode()
>>
>> v2->v3:
>> - team_change_mtu() user rcu version of list traversal to unwind
>> - set and clear of mode_ops happens per pointer, not per byte
>> - port hashlist changed to be embedded into team structure
>> - error branch in team_port_enter() does cleanup now
>> - fixed rtln->rtnl
>>
>> v1->v2:
>> - modes are made as modules. Makes team more modular and
>> extendable.
>> - several commenters' nitpicks found on v1 were fixed
>> - several other bugs were fixed.
>> - note I ignored Eric's comment about roundrobin port selector
>> as Eric's way may be easily implemented as another mode (mode
>> "random") in future.
>> ---
>> Documentation/networking/team.txt | 2 +
>> MAINTAINERS | 7 +
>> drivers/net/Kconfig | 2 +
>> drivers/net/Makefile | 1 +
>> drivers/net/team/Kconfig | 38 +
>> drivers/net/team/Makefile | 7 +
>> drivers/net/team/team.c | 1573 +++++++++++++++++++++++++++++
>> drivers/net/team/team_mode_activebackup.c | 152 +++
>> drivers/net/team/team_mode_roundrobin.c | 107 ++
>> include/linux/Kbuild | 1 +
>> include/linux/if.h | 1 +
>> include/linux/if_team.h | 231 +++++
>> include/linux/rculist.h | 14 +
>
>I think you're missing some CC's for the modifications to this file.
>I've taken the liberty of adding Dipankar and Paul to the discussion.
>
>> 13 files changed, 2136 insertions(+), 0 deletions(-)
>> create mode 100644 Documentation/networking/team.txt
>> create mode 100644 drivers/net/team/Kconfig
>> create mode 100644 drivers/net/team/Makefile
>> create mode 100644 drivers/net/team/team.c
>> create mode 100644 drivers/net/team/team_mode_activebackup.c
>> create mode 100644 drivers/net/team/team_mode_roundrobin.c
>> create mode 100644 include/linux/if_team.h
>>
>
>[...]
>
>> diff --git a/drivers/net/team/team.c b/drivers/net/team/team.c
>> new file mode 100644
>> index 0000000..acfef4c
>> --- /dev/null
>> +++ b/drivers/net/team/team.c
>> +
>[...]
>> +static int team_change_mtu(struct net_device *dev, int new_mtu)
>> +{
>> + struct team *team = netdev_priv(dev);
>> + struct team_port *port;
>> + int err;
>> +
>> + rcu_read_lock();
>> + list_for_each_entry_rcu(port, &team->port_list, list) {
>> + err = dev_set_mtu(port->dev, new_mtu);
>> + if (err) {
>> + netdev_err(dev, "Device %s failed to change mtu",
>> + port->dev->name);
>> + goto unwind;
>> + }
>> + }
>> + rcu_read_unlock();
>> +
>> + dev->mtu = new_mtu;
>> +
>> + return 0;
>> +
>> +unwind:
>> + list_for_each_entry_continue_reverse_rcu(port, &team->port_list, list)
>> + dev_set_mtu(port->dev, dev->mtu);
>> +
>> + rcu_read_unlock();
>> + return err;
>> +}
>> +
>> +
>
>[...]
>
>> diff --git a/include/linux/rculist.h b/include/linux/rculist.h
>> index d079290..7586b2c 100644
>> --- a/include/linux/rculist.h
>> +++ b/include/linux/rculist.h
>> @@ -288,6 +288,20 @@ static inline void list_splice_init_rcu(struct list_head *list,
>> pos = list_entry_rcu(pos->member.next, typeof(*pos), member))
>>
>> /**
>> + * list_for_each_entry_continue_reverse_rcu - iterate backwards from the given point
>> + * @pos: the type * to use as a loop cursor.
>> + * @head: the head for your list.
>> + * @member: the name of the list_struct within the struct.
>> + *
>> + * Start to iterate over list of given type backwards, continuing after
>> + * the current position.
>> + */
>> +#define list_for_each_entry_continue_reverse_rcu(pos, head, member) \
>> + for (pos = list_entry_rcu(pos->member.prev, typeof(*pos), member); \
>> + &pos->member != (head); \
>> + pos = list_entry_rcu(pos->member.prev, typeof(*pos), member))
>> +
>
>rcu lists can be modified while they are traversed with *_rcu()
>primitives. This benefit comes with the constraint that they may only be
>traversed forwards. This is implicit in the choice of *_rcu()
>list-traversal primitives: they only go forwards.
>
>You suggest to add a backwards rcu list-traversal primitive. But
>consider what happens in this sequence:
>
>CPU0 CPU1
>list_for_each_entry_continue_reverse_rcu(...)
>pos = list_entry_rcu(pos->member.prev, typeof(*pos), member)
> list_del_rcu(&pos->member)
> { (&pos->member)->prev = LIST_POISON2 }
>pos = list_entry_rcu(pos->member.prev, typeof(*pos), member)
> = container_of(LIST_POISON2, typeof(*pos), member)
>do_something(*pos)
> BAM!
Doh, you are right. :(
>
>Going back to the problem you're trying to solve in team_change_mtu(),
>I think you could either:
>1) take team->lock instead of rcu_read_lock() throughout this particular
>function
>2) save each deleted element in a separate list on the side in case it's
>necessary to roll back
I would go with this one.
>3) remove the rcu double locking, rely on rtnl and add some
>ASSERT_RTNL() if desired. You've said that you don't want to rely on
>rtnl and you want to use separate locking but I fail to see what
>advantage that brings to balance out the extra complexity in code and
>execution? Please clarify this.
I do not want to use rtnl. For example in gennetlink code rtnl is not
held so I need to depend on own lock.
>
>Thanks,
>-Ben
>
>> +/**
>> * hlist_del_rcu - deletes entry from hash list without re-initialization
>> * @n: the element to delete from the hash list.
>> *
>> --
>> 1.7.6
>>
^ permalink raw reply
* [PATCH 2/2] mmc: mmci: Fix incorrect handling of HW flow control for SDIO
From: Ulf Hansson @ 2011-10-24 13:50 UTC (permalink / raw)
To: linux-mmc, linux-arm-kernel
Cc: Russell King, Ulf Hansson, Lee Jones, Stefan Nilsson XK
In-Reply-To: <1319464243-16638-1-git-send-email-ulf.hansson@stericsson.com>
From: Stefan Nilsson XK <stefan.xk.nilsson@stericsson.com>
For data writes smaller <= 8 bytes (only SDIO case), HW flow control was
disabled but never re-enabled again. This meant that a following large read
request would randomly give buffer overrun errors.
Moreover HW flow control is not needed for transfers that fits in the
FIFO of PL18x. Thus it is disabled for write operations <= the FIFO size.
Signed-off-by: Ulf Hansson <ulf.hansson@stericsson.com>
Signed-off-by: Stefan Nilsson XK <stefan.xk.nilsson@stericsson.com>
---
drivers/mmc/host/mmci.c | 42 ++++++++++++++++++++++++------------------
1 files changed, 24 insertions(+), 18 deletions(-)
diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index 1b73177..07d1378 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -606,9 +606,32 @@ static void mmci_start_data(struct mmci_host *host, struct mmc_data *data)
/* The ST Micro variants has a special bit to enable SDIO */
if (variant->sdio && host->mmc->card)
- if (mmc_card_sdio(host->mmc->card))
+ if (mmc_card_sdio(host->mmc->card)) {
+ /*
+ * The ST Micro variants has a special bit
+ * to enable SDIO.
+ */
datactrl |= MCI_ST_DPSM_SDIOEN;
+ /*
+ * The ST Micro variant for SDIO transfer sizes
+ * less then or equal to 8 bytes needs to have clock
+ * H/W flow control disabled. Since flow control is
+ * not really needed for anything that fits in the
+ * FIFO, we can disable it for any write smaller
+ * than the FIFO size.
+ */
+ if ((host->size <= variant->fifosize) &&
+ (data->flags & MMC_DATA_WRITE))
+ writel(readl(host->base + MMCICLOCK) &
+ ~variant->clkreg_enable,
+ host->base + MMCICLOCK);
+ else
+ writel(readl(host->base + MMCICLOCK) |
+ variant->clkreg_enable,
+ host->base + MMCICLOCK);
+ }
+
/*
* Attempt to use DMA operation mode, if this
* should fail, fall back to PIO mode
@@ -807,23 +830,6 @@ static int mmci_pio_write(struct mmci_host *host, char *buffer, unsigned int rem
count = min(remain, maxcnt);
/*
- * The ST Micro variant for SDIO transfer sizes
- * less then 8 bytes should have clock H/W flow
- * control disabled.
- */
- if (variant->sdio &&
- mmc_card_sdio(host->mmc->card)) {
- if (count < 8)
- writel(readl(host->base + MMCICLOCK) &
- ~variant->clkreg_enable,
- host->base + MMCICLOCK);
- else
- writel(readl(host->base + MMCICLOCK) |
- variant->clkreg_enable,
- host->base + MMCICLOCK);
- }
-
- /*
* SDIO especially may want to send something that is
* not divisible by 4 (as opposed to card sectors
* etc), and the FIFO only accept full 32-bit writes.
--
1.7.5.4
^ permalink raw reply related
* [Buildroot] Call For Participation: buildroot + crosstool-NG Developpers' Day
From: Yann E. MORIN @ 2011-10-24 13:52 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20111024134505.GK31607@pengutronix.de>
Robert, All,
On Monday 24 October 2011 154505 Robert Schwebel wrote:
> I just wanted to check if you still plan to have the event,
Yes, the developers' day is maintained.
> as I pushed
> my travel back to sunday in order to have a chance to participate.
OK, will be nice to have you on-board! :-)
See you in Prague!
Regards,
Yann E. MORIN.
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +0/33 662376056 | Software Designer | \ / CAMPAIGN | ^ |
| --==< O_o >==-- '------------.-------: X AGAINST | /e\ There is no |
| http://ymorin.is-a-geek.org/ | (*_*) | / \ HTML MAIL | """ conspiracy. |
'------------------------------'-------'------------------'--------------------'
^ permalink raw reply
* Re: [GIT] Security subsystem updates for 3.2
From: Linus Torvalds @ 2011-10-24 13:52 UTC (permalink / raw)
To: James Morris, Stephen Rothwell; +Cc: linux-security-module, linux-kernel
In-Reply-To: <alpine.LRH.2.00.1110242108540.19271@tundra.namei.org>
On Mon, Oct 24, 2011 at 1:21 PM, James Morris <jmorris@namei.org> wrote:
>
> The most significant item here is the inclusion of EVM:
> https://lkml.org/lkml/2011/6/29/419
>
> There are also enhancements to Smack and Tomoyo, as well as general
> cleanups and fixes across the subsystem.
>
> Please pull.
>
> Jarkko Sakkinen (6):
> Smack: domain transition protections (v3)
So this is reverted in linux-next. I don't know why, but it's a bad
sign. Doesn't compile?
Linus
^ permalink raw reply
* [PATCH] Fix a typo
From: Jeff Liu @ 2011-10-24 13:51 UTC (permalink / raw)
To: linux-kernel; +Cc: axboe
Signed-off-by: Jie Liu <jeff.liu@oracle.com>
---
block/blk-cgroup.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/block/blk-cgroup.h b/block/blk-cgroup.h
index a71d290..6f3ace7 100644
--- a/block/blk-cgroup.h
+++ b/block/blk-cgroup.h
@@ -188,7 +188,7 @@ struct blkio_policy_node {
union {
unsigned int weight;
/*
- * Rate read/write in terms of byptes per second
+ * Rate read/write in terms of bytes per second
* Whether this rate represents read or write is determined
* by file type "fileid".
*/
--
1.7.4.1
^ permalink raw reply related
* Re: [B.A.T.M.A.N.] [PATCHv3 1/3] batman-adv: linearise the tt_response skb only if needed
From: Marek Lindner @ 2011-10-24 13:53 UTC (permalink / raw)
To: The list for a Better Approach To Mobile Ad-hoc Networking
In-Reply-To: <1318789923-29405-1-git-send-email-ordex@autistici.org>
On Sunday, October 16, 2011 20:32:02 Antonio Quartulli wrote:
> The TT_RESPONSE skb has to be linearised only if the node plans to access
> the packet payload (so only if the message is directed to that node). In
> all the other cases the node can avoid this memory operation
Patch was applied in revision 7f1b2a0.
Thanks,
Marek
^ permalink raw reply
* RE: [PATCH 3/5][v2] fsl-rio: Add two ports and rapidio message units support
From: Bounine, Alexandre @ 2011-10-24 13:51 UTC (permalink / raw)
To: Liu Gang-B34182, Kumar Gala, linuxppc-dev, Zang Roy-R61911
Cc: Andrew Morton, linux-kernel
In-Reply-To: <9A1C2A9ACC704641BC472A1588CE164712E48E@039-SN1MPN1-005.039d.mgd.msft.net>
On Sat, Oct 22, 2011 at 1:15 AM, Liu Gang-B34182 <B34182@freescale.com>
wrote:
>=20
> From: Bounine, Alexandre [mailto:Alexandre.Bounine@idt.com]
> Sent: Thursday, October 20, 2011 3:54 AM
> To: Kumar Gala; linuxppc-dev@ozlabs.org
> Cc: Andrew Morton; Liu Gang-B34182; linux-kernel@vger.kernel.org
> Subject: RE: [PATCH 3/5][v2] fsl-rio: Add two ports and rapidio
message
> units support
>=20
> On Thu, Oct 13, 2011 at 10:09 AM, Kumar Gala wrote:
> >
> > From: Liu Gang <Gang.Liu@freescale.com>
> >
> > Usually, freescale rapidio endpoint can support one 1X or two 4X LP-
> > Serial link interfaces, and rapidio message transactions can be
> > implemented
> by
> > two
>=20
> Is the number of 1x ports described correctly?
> Can we have two 1x ports as well?
> [Liu Gang-B34182] Yes you are right. endpoint can also have two 1x
> ports. I'll correct it.
>=20
> > message units. This patch adds the support of two rapidio ports and
> > initializes message unit 0 and message unit 1. And these ports and
> > message
> ... skip ...
> > +
> > + /* Probe the master port phy type */
> > + ccsr =3D in_be32(priv->regs_win + RIO_CCSR + i*0x20);
> > + port->phy_type =3D (ccsr & 1) ? RIO_PHY_SERIAL :
> > RIO_PHY_PARALLEL;
> > + dev_info(&dev->dev, "RapidIO PHY type: %s\n",
> > + (port->phy_type =3D=3D RIO_PHY_PARALLEL) ?
> > + "parallel" :
> > + ((port->phy_type =3D=3D RIO_PHY_SERIAL) ?
> "serial"
> > :
> > + "unknown"));
> > + /* Checking the port training status */
> > + if (in_be32((priv->regs_win + RIO_ESCSR + i*0x20)) & 1)
> {
> > + dev_err(&dev->dev, "Port %d is not ready. "
> > + "Try to restart connection...\n", i);
> > + switch (port->phy_type) {
> > + case RIO_PHY_SERIAL:
> > + /* Disable ports */
> > + out_be32(priv->regs_win
> > + + RIO_CCSR + i*0x20, 0);
> > + /* Set 1x lane */
> > + setbits32(priv->regs_win
> > + + RIO_CCSR + i*0x20,
> 0x02000000);
> > + /* Enable ports */
> > + setbits32(priv->regs_win
> > + + RIO_CCSR + i*0x20,
> 0x00600000);
> > + break;
> > + case RIO_PHY_PARALLEL:
> > + /* Disable ports */
> > + out_be32(priv->regs_win
> > + + RIO_CCSR + i*0x20,
> 0x22000000);
> > + /* Enable ports */
> > + out_be32(priv->regs_win
> > + + RIO_CCSR + i*0x20,
> 0x44000000);
> > + break;
> > + }
>=20
> Probably this may be a good moment to drop the support for parallel
> link.
> Especially after you renamed controller to "srio" in the device tree.
> [Liu Gang-B34182] I'm also considering if we should drop the parallel
> link support and doorbell outbound ATMU configuration.
> I found some older powerpc chips support parallel link, like mpc8540
> and so on. But DTS files of these chips do not support
> Rapidio nodes. For example we can't find rapidio node in
> arch/powerpc/boot/dts/mpc8540ads.dts file. So can we conclude that
> these chips with parallel rapidio link do not need the support for
> rapidio module and the code for parallel link can be removed?
We are not aware about any use of tsi500 P-RIO switches.
I would consider parallel implementation as an early stage
of RapidIO development which may be safely dropped.
I will keep P-RIO related definitions only because they are part of
the spec. I consider removing tsi500 switch driver as well.
>=20
> > + msleep(100);
... skip ...
>=20
> >
> > @@ -340,35 +327,45 @@ fsl_rio_dbell_handler(int irq, void
> > *dev_instance)
> > " sid %2.2x tid %2.2x info %4.4x\n",
> > DBELL_SID(dmsg), DBELL_TID(dmsg),
> DBELL_INF(dmsg));
> >
> > - list_for_each_entry(dbell, &port->dbells, node) {
> > - if ((dbell->res->start <=3D DBELL_INF(dmsg)) &&
> > - (dbell->res->end >=3D DBELL_INF(dmsg))) {
> > - found =3D 1;
> > - break;
> > + for (i =3D 0; i < MAX_PORT_NUM; i++) {
> > + if (fsl_dbell->mport[i]) {
> > + list_for_each_entry(dbell,
> > + &fsl_dbell->mport[i]->dbells,
> node) {
> > + if ((dbell->res->start
> > + <=3D DBELL_INF(dmsg))
> > + && (dbell->res->end
> > + >=3D DBELL_INF(dmsg))) {
> > + found =3D 1;
> > + break;
> > + }
> > + }
> > + if (found && dbell->dinb) {
> > + dbell->dinb(fsl_dbell->mport[i],
> > + dbell->dev_id,
> DBELL_SID(dmsg),
> > + DBELL_TID(dmsg),
> > + DBELL_INF(dmsg));
> > + break;
> > + }
> > }
> > }
>=20
> Do we need to check for matching DBELL_TID and mport destID here and
> scan only doorbell list attached to the right port? Otherwise this may
> call service routine associated with doorbell on a wrong port.
> [Liu Gang-B34182] Do you mean to match DBELL_TID and mport DevID?
Yes.
> Usually this is a reliable method, but for the rapidio module of
> powerpc, will encounter some problem. We set the port's DevID by
> the register "Base Device ID CSR" defined in Rapidio Specification.
The
> rapidio module of powerpc can support two ports but have only one the
> Base Device ID CSR. So these two ports will have the same
> DevID. Although there are two registers "Alternate Device ID CSR" to
> separate deviceIDs for each port, they are specific registers of the
> freescale rapidio and can't be accessed by getting the extended
feature
> space block offset. For this doobell issue, in order to call a right
> service routine, perhaps we should ensure that different ports in
> different "res->start and res->end" configurations.
This gives us an issue that has to be solved at some point.
Splitting doorbell resources may be a way in this case but should be
considered in context of RIO network with different endpoints and
therefore
it will be some device-specific quirk.
Probably the best approach in this case is to keep doorbell handler as
it is now (for purpose of this patchset) and address doorbell resource
assignment during enumeration/discovery. At least this has to be well
commented.=20
>=20
> > - if (found) {
> > - dbell->dinb(port, dbell->dev_id,
> > - DBELL_SID(dmsg),
> > - DBELL_TID(dmsg),
> DBELL_INF(dmsg));
> > - } else {
> > +
> > + if (!found) {
> > pr_debug
> > ("RIO: spurious doorbell,"
> > " sid %2.2x tid %2.2x info %4.4x\n",
> > DBELL_SID(dmsg), DBELL_TID(dmsg),
> > DBELL_INF(dmsg));
> > }
> > - setbits32(&rmu->msg_regs->dmr, DOORBELL_DMR_DI);
> > - out_be32(&rmu->msg_regs->dsr, DOORBELL_DSR_DIQI);
> > + setbits32(&fsl_dbell->dbell_regs->dmr, DOORBELL_DMR_DI);
> > + out_be32(&fsl_dbell->dbell_regs->dsr,
> DOORBELL_DSR_DIQI);
> > }
> >
> > out:
> > return IRQ_HANDLED;
> > }
> >
... skip ...
=20
Regards,
Alex.
^ permalink raw reply
* RE: [PATCH 3/5][v2] fsl-rio: Add two ports and rapidio message units support
From: Bounine, Alexandre @ 2011-10-24 13:51 UTC (permalink / raw)
To: Liu Gang-B34182, Kumar Gala, linuxppc-dev, Zang Roy-R61911
Cc: Andrew Morton, linux-kernel
In-Reply-To: <9A1C2A9ACC704641BC472A1588CE164712E48E@039-SN1MPN1-005.039d.mgd.msft.net>
On Sat, Oct 22, 2011 at 1:15 AM, Liu Gang-B34182 <B34182@freescale.com>
wrote:
>
> From: Bounine, Alexandre [mailto:Alexandre.Bounine@idt.com]
> Sent: Thursday, October 20, 2011 3:54 AM
> To: Kumar Gala; linuxppc-dev@ozlabs.org
> Cc: Andrew Morton; Liu Gang-B34182; linux-kernel@vger.kernel.org
> Subject: RE: [PATCH 3/5][v2] fsl-rio: Add two ports and rapidio
message
> units support
>
> On Thu, Oct 13, 2011 at 10:09 AM, Kumar Gala wrote:
> >
> > From: Liu Gang <Gang.Liu@freescale.com>
> >
> > Usually, freescale rapidio endpoint can support one 1X or two 4X LP-
> > Serial link interfaces, and rapidio message transactions can be
> > implemented
> by
> > two
>
> Is the number of 1x ports described correctly?
> Can we have two 1x ports as well?
> [Liu Gang-B34182] Yes you are right. endpoint can also have two 1x
> ports. I'll correct it.
>
> > message units. This patch adds the support of two rapidio ports and
> > initializes message unit 0 and message unit 1. And these ports and
> > message
> ... skip ...
> > +
> > + /* Probe the master port phy type */
> > + ccsr = in_be32(priv->regs_win + RIO_CCSR + i*0x20);
> > + port->phy_type = (ccsr & 1) ? RIO_PHY_SERIAL :
> > RIO_PHY_PARALLEL;
> > + dev_info(&dev->dev, "RapidIO PHY type: %s\n",
> > + (port->phy_type == RIO_PHY_PARALLEL) ?
> > + "parallel" :
> > + ((port->phy_type == RIO_PHY_SERIAL) ?
> "serial"
> > :
> > + "unknown"));
> > + /* Checking the port training status */
> > + if (in_be32((priv->regs_win + RIO_ESCSR + i*0x20)) & 1)
> {
> > + dev_err(&dev->dev, "Port %d is not ready. "
> > + "Try to restart connection...\n", i);
> > + switch (port->phy_type) {
> > + case RIO_PHY_SERIAL:
> > + /* Disable ports */
> > + out_be32(priv->regs_win
> > + + RIO_CCSR + i*0x20, 0);
> > + /* Set 1x lane */
> > + setbits32(priv->regs_win
> > + + RIO_CCSR + i*0x20,
> 0x02000000);
> > + /* Enable ports */
> > + setbits32(priv->regs_win
> > + + RIO_CCSR + i*0x20,
> 0x00600000);
> > + break;
> > + case RIO_PHY_PARALLEL:
> > + /* Disable ports */
> > + out_be32(priv->regs_win
> > + + RIO_CCSR + i*0x20,
> 0x22000000);
> > + /* Enable ports */
> > + out_be32(priv->regs_win
> > + + RIO_CCSR + i*0x20,
> 0x44000000);
> > + break;
> > + }
>
> Probably this may be a good moment to drop the support for parallel
> link.
> Especially after you renamed controller to "srio" in the device tree.
> [Liu Gang-B34182] I'm also considering if we should drop the parallel
> link support and doorbell outbound ATMU configuration.
> I found some older powerpc chips support parallel link, like mpc8540
> and so on. But DTS files of these chips do not support
> Rapidio nodes. For example we can't find rapidio node in
> arch/powerpc/boot/dts/mpc8540ads.dts file. So can we conclude that
> these chips with parallel rapidio link do not need the support for
> rapidio module and the code for parallel link can be removed?
We are not aware about any use of tsi500 P-RIO switches.
I would consider parallel implementation as an early stage
of RapidIO development which may be safely dropped.
I will keep P-RIO related definitions only because they are part of
the spec. I consider removing tsi500 switch driver as well.
>
> > + msleep(100);
... skip ...
>
> >
> > @@ -340,35 +327,45 @@ fsl_rio_dbell_handler(int irq, void
> > *dev_instance)
> > " sid %2.2x tid %2.2x info %4.4x\n",
> > DBELL_SID(dmsg), DBELL_TID(dmsg),
> DBELL_INF(dmsg));
> >
> > - list_for_each_entry(dbell, &port->dbells, node) {
> > - if ((dbell->res->start <= DBELL_INF(dmsg)) &&
> > - (dbell->res->end >= DBELL_INF(dmsg))) {
> > - found = 1;
> > - break;
> > + for (i = 0; i < MAX_PORT_NUM; i++) {
> > + if (fsl_dbell->mport[i]) {
> > + list_for_each_entry(dbell,
> > + &fsl_dbell->mport[i]->dbells,
> node) {
> > + if ((dbell->res->start
> > + <= DBELL_INF(dmsg))
> > + && (dbell->res->end
> > + >= DBELL_INF(dmsg))) {
> > + found = 1;
> > + break;
> > + }
> > + }
> > + if (found && dbell->dinb) {
> > + dbell->dinb(fsl_dbell->mport[i],
> > + dbell->dev_id,
> DBELL_SID(dmsg),
> > + DBELL_TID(dmsg),
> > + DBELL_INF(dmsg));
> > + break;
> > + }
> > }
> > }
>
> Do we need to check for matching DBELL_TID and mport destID here and
> scan only doorbell list attached to the right port? Otherwise this may
> call service routine associated with doorbell on a wrong port.
> [Liu Gang-B34182] Do you mean to match DBELL_TID and mport DevID?
Yes.
> Usually this is a reliable method, but for the rapidio module of
> powerpc, will encounter some problem. We set the port's DevID by
> the register "Base Device ID CSR" defined in Rapidio Specification.
The
> rapidio module of powerpc can support two ports but have only one the
> Base Device ID CSR. So these two ports will have the same
> DevID. Although there are two registers "Alternate Device ID CSR" to
> separate deviceIDs for each port, they are specific registers of the
> freescale rapidio and can't be accessed by getting the extended
feature
> space block offset. For this doobell issue, in order to call a right
> service routine, perhaps we should ensure that different ports in
> different "res->start and res->end" configurations.
This gives us an issue that has to be solved at some point.
Splitting doorbell resources may be a way in this case but should be
considered in context of RIO network with different endpoints and
therefore
it will be some device-specific quirk.
Probably the best approach in this case is to keep doorbell handler as
it is now (for purpose of this patchset) and address doorbell resource
assignment during enumeration/discovery. At least this has to be well
commented.
>
> > - if (found) {
> > - dbell->dinb(port, dbell->dev_id,
> > - DBELL_SID(dmsg),
> > - DBELL_TID(dmsg),
> DBELL_INF(dmsg));
> > - } else {
> > +
> > + if (!found) {
> > pr_debug
> > ("RIO: spurious doorbell,"
> > " sid %2.2x tid %2.2x info %4.4x\n",
> > DBELL_SID(dmsg), DBELL_TID(dmsg),
> > DBELL_INF(dmsg));
> > }
> > - setbits32(&rmu->msg_regs->dmr, DOORBELL_DMR_DI);
> > - out_be32(&rmu->msg_regs->dsr, DOORBELL_DSR_DIQI);
> > + setbits32(&fsl_dbell->dbell_regs->dmr, DOORBELL_DMR_DI);
> > + out_be32(&fsl_dbell->dbell_regs->dsr,
> DOORBELL_DSR_DIQI);
> > }
> >
> > out:
> > return IRQ_HANDLED;
> > }
> >
... skip ...
Regards,
Alex.
^ 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.