* [PATCH v5 1/4] iommu/shmobile: Add iommu driver for Renesas IPMMU modules
From: Joerg Roedel @ 2013-01-10 18:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1586668.MmWlG9A4gq@avalon>
Hi,
On Mon, Jan 07, 2013 at 07:11:58PM +0100, Laurent Pinchart wrote:
> > + l2index = (iova >> 12) & 0xff;
> > + spin_lock(&sh_domain->map_lock);
> > + ret = l2alloc(sh_domain, l1index);
>
> l2alloc calls dma_pool_alloc(GFP_KERNEL), that not safe in a non-sleepable
> context. Do we need a spinlock here, or could a mutex do ?
iommu_map should work in any context, so a mutex will not work. Also the
memory allocations in that path should be GFP_ATOMIC instead of
GFP_KERNEL.
Other than that this driver looks good from an IOMMU-API perspective.
Please Cc me on future versions of this patch-set directly.
Thanks,
Joerg
^ permalink raw reply
* Re: [PATCH v5 1/4] iommu/shmobile: Add iommu driver for Renesas IPMMU modules
From: Joerg Roedel @ 2013-01-10 18:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1586668.MmWlG9A4gq@avalon>
Hi,
On Mon, Jan 07, 2013 at 07:11:58PM +0100, Laurent Pinchart wrote:
> > + l2index = (iova >> 12) & 0xff;
> > + spin_lock(&sh_domain->map_lock);
> > + ret = l2alloc(sh_domain, l1index);
>
> l2alloc calls dma_pool_alloc(GFP_KERNEL), that not safe in a non-sleepable
> context. Do we need a spinlock here, or could a mutex do ?
iommu_map should work in any context, so a mutex will not work. Also the
memory allocations in that path should be GFP_ATOMIC instead of
GFP_KERNEL.
Other than that this driver looks good from an IOMMU-API perspective.
Please Cc me on future versions of this patch-set directly.
Thanks,
Joerg
^ permalink raw reply
* Re: [PATCH v5 1/4] iommu/shmobile: Add iommu driver for Renesas IPMMU modules
From: Joerg Roedel @ 2013-01-10 18:32 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Katsuya MATSUBARA, Hideki EIRAKU, linux-sh-u79uwXL29TY76Z2rM5mHXA,
Paul Mundt, Magnus Damm, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, Simon Horman,
Russell King, Damian Hobson-Garcia,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1586668.MmWlG9A4gq@avalon>
Hi,
On Mon, Jan 07, 2013 at 07:11:58PM +0100, Laurent Pinchart wrote:
> > + l2index = (iova >> 12) & 0xff;
> > + spin_lock(&sh_domain->map_lock);
> > + ret = l2alloc(sh_domain, l1index);
>
> l2alloc calls dma_pool_alloc(GFP_KERNEL), that not safe in a non-sleepable
> context. Do we need a spinlock here, or could a mutex do ?
iommu_map should work in any context, so a mutex will not work. Also the
memory allocations in that path should be GFP_ATOMIC instead of
GFP_KERNEL.
Other than that this driver looks good from an IOMMU-API perspective.
Please Cc me on future versions of this patch-set directly.
Thanks,
Joerg
^ permalink raw reply
* [PATCH 1/4] arm: vt8500: Add support for Wondermedia WM8750/WM8850
From: Tony Prisk @ 2013-01-10 18:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201301101021.44238.arnd@arndb.de>
On Thu, 2013-01-10 at 10:21 +0000, Arnd Bergmann wrote:
> On Thursday 10 January 2013, Tony Prisk wrote:
> > On Wed, 2013-01-09 at 21:27 +0000, Arnd Bergmann wrote:
> > >
> > > > Should patches in pull-requests have Ack'd lines already?
> >
> > This is what I thought - and the reason I haven't sent a pull-request
> > for the patch's - I haven't had any Ack's :)
> >
>
> Sorry, I think I misunderstood the question then. I meant that if
> you received an Acked-by statement, it should be part of the
> changeset comment by the time you send a pull request.
>
> There is also the rule that patches need to be reviewed on the
> mailing list before you submit them for inclusion. Like all
> rules, this can be bent a little for patches that are obvious
> correct bug fixes, especially when you are the platform
> maintainer. What you can do here is send the patches out to the
> mailing list without any additional Acks and send the pull
> request as the [PATCH 0/X] mail. We can then look at the
> patches if necessary or just pull in the branch straight away.
>
> Arnd
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
All makes sense now - thanks.
Regards
Tony P
^ permalink raw reply
* Re: osd down (for 2 about 2 minutes) error after adding a new host to my cluster
From: Gregory Farnum @ 2013-01-10 18:32 UTC (permalink / raw)
To: Isaac Otsiabah; +Cc: ceph-devel@vger.kernel.org
In-Reply-To: <1357680673.72602.YahooMailNeo@web121904.mail.ne1.yahoo.com>
On Tue, Jan 8, 2013 at 1:31 PM, Isaac Otsiabah <zmoo76b@yahoo.com> wrote:
>
>
> Hi Greg, it appears to be a timing issue because with the flag (debug ms=1) turned on, the system ran slower and became harder to fail. I ran it several times and finally got it to fail on (osd.0) using default crush map. The attached tar file contains log files for all components on g8ct plus the ceph.conf.
>
> I started with a 1-node cluster on host g8ct (osd.0, osd.1, osd.2) and then added host g13ct (osd.3, osd.4, osd.5)
>
>
>
> id weight type name up/down reweight
> -1 6 root default
> -3 6 rack unknownrack
> -2 3 host g8ct
> 0 1 osd.0 down 1
> 1 1 osd.1 up 1
> 2 1 osd.2 up 1
> -4 3 host g13ct
> 3 1 osd.3 up 1
> 4 1 osd.4 up 1
> 5 1 osd.5 up 1
>
>
>
> The error messages are in ceph.log and ceph-osd.0.log:
>
> ceph.log:2013-01-08 05:41:38.080470 osd.0 192.168.0.124:6801/25571 3 : [ERR] map e15 had wrong cluster addr (192.168.0.124:6802/25571 != my 192.168.1.124:6802/25571)
> ceph-osd.0.log:2013-01-08 05:41:38.080458 7f06757fa710 0 log [ERR] : map e15 had wrong cluster addr (192.168.0.124:6802/25571 != my 192.168.1.124:6802/25571)
Thanks. I had a brief look through these logs on Tuesday and want to
spend more time with them because they have some odd stuff in them. It
*looks* like the OSD is starting out using a single IP for both the
public and cluster networks and then switching over at some point,
which is...odd.
Knowing more details about how your network is actually set up would
be very helpful.
-Greg
^ permalink raw reply
* Re: [PATCH 1/4] arm: vt8500: Add support for Wondermedia WM8750/WM8850
From: Tony Prisk @ 2013-01-10 18:32 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Olof Johansson, vt8500-wm8505-linux-kernel, arm, linux-kernel,
linux-arm-kernel
In-Reply-To: <201301101021.44238.arnd@arndb.de>
On Thu, 2013-01-10 at 10:21 +0000, Arnd Bergmann wrote:
> On Thursday 10 January 2013, Tony Prisk wrote:
> > On Wed, 2013-01-09 at 21:27 +0000, Arnd Bergmann wrote:
> > >
> > > > Should patches in pull-requests have Ack'd lines already?
> >
> > This is what I thought - and the reason I haven't sent a pull-request
> > for the patch's - I haven't had any Ack's :)
> >
>
> Sorry, I think I misunderstood the question then. I meant that if
> you received an Acked-by statement, it should be part of the
> changeset comment by the time you send a pull request.
>
> There is also the rule that patches need to be reviewed on the
> mailing list before you submit them for inclusion. Like all
> rules, this can be bent a little for patches that are obvious
> correct bug fixes, especially when you are the platform
> maintainer. What you can do here is send the patches out to the
> mailing list without any additional Acks and send the pull
> request as the [PATCH 0/X] mail. We can then look at the
> patches if necessary or just pull in the branch straight away.
>
> Arnd
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
All makes sense now - thanks.
Regards
Tony P
^ permalink raw reply
* Re: [PATCH 8/8] Bluetooth: Fix sending incorrect new_settings for mgmt_set_powered
From: Gustavo Padovan @ 2013-01-10 18:31 UTC (permalink / raw)
To: Johan Hedberg; +Cc: linux-bluetooth
In-Reply-To: <1357738180-4128-9-git-send-email-johan.hedberg@gmail.com>
Hi Johan,
* Johan Hedberg <johan.hedberg@gmail.com> [2013-01-09 15:29:40 +0200]:
> From: Johan Hedberg <johan.hedberg@intel.com>
>
> The socket from which a mgmt_set_powered command was received should
> only receive the command response but no new_settings event.
>
> The mgmt_powered() function which is used to handle the situation with
> the HCI_AUTO_OFF flag tries to check for a pending command to know which
> socket to skip the event for, but since the pending command hasn't been
> added this will not happen.
>
> This patch fixes the issue by adding the pending command for the
> HCI_AUTO_OFF case and thereby ensures that mgmt_powered() will skip the
> right socket when sending the new_settings event, but still send the
> proper response to the socket where the command came from.
>
> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
> ---
> net/bluetooth/mgmt.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
Patch has been applied, thanks.
Gustavo
^ permalink raw reply
* Re: [PATCH 5/8 v2] Bluetooth: Fix returning proper command status for start_discovery
From: Gustavo Padovan @ 2013-01-10 18:30 UTC (permalink / raw)
To: Johan Hedberg; +Cc: linux-bluetooth
In-Reply-To: <1357822449-10727-1-git-send-email-johan.hedberg@gmail.com>
Hi Johan,
* Johan Hedberg <johan.hedberg@gmail.com> [2013-01-10 14:54:09 +0200]:
> From: Johan Hedberg <johan.hedberg@intel.com>
>
> Management commands should whenever possible fail with proper command
> status or command complete events. This patch fixes the
> mgmt_start_discovery command to do this for the failure cases where an
> incorrect parameter value was passed to it ("not supported" if the
> parameter value was valid but the controller doesn't support it and
> "invalid params" if it isn't valid at all).
>
> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
> ---
> v2: Use proposed logic for testing for not supported parameters
>
> net/bluetooth/mgmt.c | 46 ++++++++++++++++++++++++++++++----------------
> 1 file changed, 30 insertions(+), 16 deletions(-)
Patch has been applied. Thanks.
Gustavo
^ permalink raw reply
* Re: linux-next: manual merge of the pm tree with the pci tree
From: Bjorn Helgaas @ 2013-01-10 18:30 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: Stephen Rothwell, linux-next, linux-kernel, Yinghai Lu
In-Reply-To: <3580741.9uNSi7V1RO@vostro.rjw.lan>
On Thu, Jan 10, 2013 at 6:12 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> Hi,
>
> On Thursday, January 10, 2013 11:28:36 AM Stephen Rothwell wrote:
>> Hi Rafael,
>>
>> Today's linux-next merge of the pm tree got a conflict in
>> drivers/acpi/pci_root.c between commit 3c449ed00759 ("PCI/ACPI: Reserve
>> firmware-allocated resources for hot-added root buses") from the pci tree
>> and commit 47525cda88f5 ("ACPI / PCI: Fold acpi_pci_root_start() into
>> acpi_pci_root_add()") from the pm tree.
>>
>> I fixed it up (see below) and can carry the fix as necessary (no action
>> is required).
>
> Thanks for the fixup and please carry it for now (the conflict should go away
> when Bjorn pulls from my acpi-scan branch).
I pulled from acpi-scan and put it in my -next branch.
I had done this yesterday, but botched the conflict resolution
(thanks, Stephen, for showing me the correct resolution). So I
recreated my pci/yinghai-survey-resources+acpi-scan branch, re-did the
merge, the force-updated both my
pci/yinghai-survey-resources+acpi-scan and next branches.
Bjorn
^ permalink raw reply
* Ever increasing time offset for HVM domain / Huge amounts of drift
From: Phil Evans @ 2013-01-10 18:27 UTC (permalink / raw)
To: xen-devel@lists.xen.org
[-- Attachment #1.1: Type: text/plain, Size: 2445 bytes --]
Hi,
I am currently running Xen 4.2.1 (this has also happened in 4.2.0 as well). We have been having a major problem with sometimes huge amounts of clock drift in Windows VMs. Sometimes the clock on a VM could suddenly jump by over a week (usually forwards, however time has been known to go backwards as well).
Now I don't profess to know the internals of Xen, however through my investigation I believe I have a degree of knowledge of what could be causing the problem.
The steps to reproduce this (for me at least), is to simply do a manual NTP sync on a Windows VM. Upon monitoring the qemu-dm log file for the VM, I see similar to the following:
Time offset set 489, added offset 480
Time offset set 436, added offset -53
Time offset set 496, added offset 60
Time offset set 494, added offset -2
Time offset set 554, added offset 60
Time offset set 565, added offset 11
Time offset set 606, added offset 41
Time offset set -1974, added offset -2580
Time offset set 1626, added offset 3600
Time offset set 1579, added offset -47
Time offset set 1639, added offset 60
It seems to add the same number of seconds to the offset as has passed since the last sync. The offset just keeps on increasing, eventually resulting in huge numbers equating to days. Occasionally the offset may jump a bit and go down but the general trend is up. Although this does not affect the VM immediately, at some point I am guessing it syncs itself with the CMOS clock (which is now a large number of seconds offset from the actual time), resulting in a huge jump in time. A reboot is a guaranteed way to get the new, incorrect time.
Although I do not understand all of the underlying code, I presume the correct way this should work is it should be comparing the CMOS time that's just been set with the hardware clock on the physical machine, resulting in an offset between the two. This would result in a generally stable number (ideally 0). Obviously it is incorrect behaviour for the number to keep going up. To my mind it looks like it may be somehow getting an inaccurate time from the system (in many cases a fixed time rather than an up-to-date current time).
Does anyone have any light they may be able to shed on this? Is it possible it could be struggling to get an accurate time from the hardware? I have checked on several occasions and both the system time and the BIOS clock are spot on.
Regards,
Phil.
[-- Attachment #1.2: Type: text/html, Size: 5270 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply
* [PATCH 05/14] lib: Add I/O map cache implementation
From: Arnd Bergmann @ 2013-01-10 18:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130110102544.GA5546@avionic-0098.adnet.avionic-design.de>
On Thursday 10 January 2013, Thierry Reding wrote:
> I don't understand how this would help. The encoding is like this:
>
> [27:24] extended register number
> [23:16] bus number
> [15:11] device number
> [10: 8] function number
> [ 7: 0] register number
>
> So it doesn't matter whether I use separate areas per bus or not. As
> soon as the whole extended configuration space needs to be accessed a
> whopping 28 bits (256 MiB) are required.
>
> What you propose would work if only regular configuration space is
> supported. I'm not sure if that's an option.
I mean something like:
struct tegra_bus_private {
...
void __iomem *config_space[16];
};
void tegra_scan_bus(struct pci_bus *bus)
{
int i;
struct tegra_bus_private *priv = bus->dev->private;
for (i=0; i<16; i++)
priv->config_space[i] = ioremap(config_space_phys +
65536 * bus->primary + i * SZ_1M, 65536);
...
}
Arnd
^ permalink raw reply
* Re: [PATCH 05/14] lib: Add I/O map cache implementation
From: Arnd Bergmann @ 2013-01-10 18:26 UTC (permalink / raw)
To: Thierry Reding
Cc: Russell King, linux-pci-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Jason Gunthorpe,
Bjorn Helgaas, linux-tegra-u79uwXL29TY76Z2rM5mHXA, Andrew Murray,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20130110102544.GA5546-RM9K5IK7kjIyiCvfTdI0JKcOhU4Rzj621B7CTYaBSLdn68oJJulU0Q@public.gmane.org>
On Thursday 10 January 2013, Thierry Reding wrote:
> I don't understand how this would help. The encoding is like this:
>
> [27:24] extended register number
> [23:16] bus number
> [15:11] device number
> [10: 8] function number
> [ 7: 0] register number
>
> So it doesn't matter whether I use separate areas per bus or not. As
> soon as the whole extended configuration space needs to be accessed a
> whopping 28 bits (256 MiB) are required.
>
> What you propose would work if only regular configuration space is
> supported. I'm not sure if that's an option.
I mean something like:
struct tegra_bus_private {
...
void __iomem *config_space[16];
};
void tegra_scan_bus(struct pci_bus *bus)
{
int i;
struct tegra_bus_private *priv = bus->dev->private;
for (i=0; i<16; i++)
priv->config_space[i] = ioremap(config_space_phys +
65536 * bus->primary + i * SZ_1M, 65536);
...
}
Arnd
^ permalink raw reply
* Re: [PATCH 05/14] lib: Add I/O map cache implementation
From: Arnd Bergmann @ 2013-01-10 18:26 UTC (permalink / raw)
To: Thierry Reding
Cc: Jason Gunthorpe, Stephen Warren, linux-tegra, Grant Likely,
Rob Herring, Russell King, Bjorn Helgaas, Andrew Murray,
Thomas Petazzoni, devicetree-discuss, linux-kernel,
linux-arm-kernel, linux-pci
In-Reply-To: <20130110102544.GA5546@avionic-0098.adnet.avionic-design.de>
On Thursday 10 January 2013, Thierry Reding wrote:
> I don't understand how this would help. The encoding is like this:
>
> [27:24] extended register number
> [23:16] bus number
> [15:11] device number
> [10: 8] function number
> [ 7: 0] register number
>
> So it doesn't matter whether I use separate areas per bus or not. As
> soon as the whole extended configuration space needs to be accessed a
> whopping 28 bits (256 MiB) are required.
>
> What you propose would work if only regular configuration space is
> supported. I'm not sure if that's an option.
I mean something like:
struct tegra_bus_private {
...
void __iomem *config_space[16];
};
void tegra_scan_bus(struct pci_bus *bus)
{
int i;
struct tegra_bus_private *priv = bus->dev->private;
for (i=0; i<16; i++)
priv->config_space[i] = ioremap(config_space_phys +
65536 * bus->primary + i * SZ_1M, 65536);
...
}
Arnd
^ permalink raw reply
* [REPOST PATCH v3 1/4] mmc: dw_mmc: Add "disable-wp" device tree property
From: Doug Anderson @ 2013-01-10 18:24 UTC (permalink / raw)
To: linux-mmc
Cc: linux-samsung-soc, Thomas Abraham, Kukjin Kim, Olof Johansson,
Arnd Bergmann, Will Newton, Chris Ball, Jaehoon Chung,
Seungwon Jeon, linux-kernel, Doug Anderson, Grant Likely,
Rob Herring, Rob Landley, Abhilash Kesavan, Kyungmin Park,
devicetree-discuss, linux-doc
In-Reply-To: <1354251857-21587-1-git-send-email-dianders@chromium.org>
The "disable-wp" property is used to specify that a given SD card slot
doesn't have a concept of write protect. This eliminates the need for
special case code for SD slots that should never be write protected
(like a micro SD slot or a dev board).
The dw_mmc driver is special in needing to specify "disable-wp"
because the lack of a "wp-gpios" property means to use the special
purpose write protect line. On some other mmc devices the lack of
"wp-gpios" means that write protect should be disabled.
Signed-off-by: Doug Anderson <dianders@chromium.org>
Acked-by: Seungwon Jeon <tgih.jun@samsung.com>
---
Changes in v3:
- New for this version of the patch series. Chose "disable-wp" rather
than the discussed "broken-internal-wp" since it mapped more cleanly
to an existing quirk (and the only reason to specify that the
internal wp is broken is if you're disabling the write protect
anyway).
- Reposted series 3 with Seungwon's ack, since it hasn't been picked
up by anyone.
.../devicetree/bindings/mmc/synopsis-dw-mshc.txt | 12 +++++-
drivers/mmc/host/dw_mmc.c | 36 +++++++++++++++++++-
include/linux/mmc/dw_mmc.h | 4 ++
3 files changed, 49 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/mmc/synopsis-dw-mshc.txt b/Documentation/devicetree/bindings/mmc/synopsis-dw-mshc.txt
index 06cd32d08..726fd21 100644
--- a/Documentation/devicetree/bindings/mmc/synopsis-dw-mshc.txt
+++ b/Documentation/devicetree/bindings/mmc/synopsis-dw-mshc.txt
@@ -26,8 +26,16 @@ Required Properties:
* bus-width: as documented in mmc core bindings.
* wp-gpios: specifies the write protect gpio line. The format of the
- gpio specifier depends on the gpio controller. If the write-protect
- line is not available, this property is optional.
+ gpio specifier depends on the gpio controller. If a GPIO is not used
+ for write-protect, this property is optional.
+
+ * disable-wp: If the wp-gpios property isn't present then (by default)
+ we'd assume that the write protect is hooked up directly to the
+ controller's special purpose write protect line (accessible via
+ the WRTPRT register). However, it's possible that we simply don't
+ want write protect. In that case specify 'disable-wp'.
+ NOTE: This property is not required for slots known to always
+ connect to eMMC or SDIO cards.
Optional properties:
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 323c502..bc0b030 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -74,6 +74,7 @@ struct idmac_desc {
* struct dw_mci_slot - MMC slot state
* @mmc: The mmc_host representing this slot.
* @host: The MMC controller this slot is using.
+ * @quirks: Slot-level quirks (DW_MCI_SLOT_QUIRK_XXX)
* @ctype: Card type for this slot.
* @mrq: mmc_request currently being processed or waiting to be
* processed, or NULL when the slot is idle.
@@ -88,6 +89,8 @@ struct dw_mci_slot {
struct mmc_host *mmc;
struct dw_mci *host;
+ int quirks;
+
u32 ctype;
struct mmc_request *mrq;
@@ -825,7 +828,8 @@ static int dw_mci_get_ro(struct mmc_host *mmc)
struct dw_mci_board *brd = slot->host->pdata;
/* Use platform get_ro function, else try on board write protect */
- if (brd->quirks & DW_MCI_QUIRK_NO_WRITE_PROTECT)
+ if ((brd->quirks & DW_MCI_QUIRK_NO_WRITE_PROTECT) ||
+ (slot->quirks & DW_MCI_SLOT_QUIRK_NO_WRITE_PROTECT))
read_only = 0;
else if (brd->get_ro)
read_only = brd->get_ro(slot->id);
@@ -1785,6 +1789,30 @@ static struct device_node *dw_mci_of_find_slot_node(struct device *dev, u8 slot)
return NULL;
}
+static struct dw_mci_of_slot_quirks {
+ char *quirk;
+ int id;
+} of_slot_quirks[] = {
+ {
+ .quirk = "disable-wp",
+ .id = DW_MCI_SLOT_QUIRK_NO_WRITE_PROTECT,
+ },
+};
+
+static int dw_mci_of_get_slot_quirks(struct device *dev, u8 slot)
+{
+ struct device_node *np = dw_mci_of_find_slot_node(dev, slot);
+ int quirks = 0;
+ int idx;
+
+ /* get quirks */
+ for (idx = 0; idx < ARRAY_SIZE(of_slot_quirks); idx++)
+ if (of_get_property(np, of_slot_quirks[idx].quirk, NULL))
+ quirks |= of_slot_quirks[idx].id;
+
+ return quirks;
+}
+
/* find out bus-width for a given slot */
static u32 dw_mci_of_get_bus_wd(struct device *dev, u8 slot)
{
@@ -1800,6 +1828,10 @@ static u32 dw_mci_of_get_bus_wd(struct device *dev, u8 slot)
return bus_wd;
}
#else /* CONFIG_OF */
+static int dw_mci_of_get_slot_quirks(struct device *dev, u8 slot)
+{
+ return 0;
+}
static u32 dw_mci_of_get_bus_wd(struct device *dev, u8 slot)
{
return 1;
@@ -1828,6 +1860,8 @@ static int dw_mci_init_slot(struct dw_mci *host, unsigned int id)
slot->host = host;
host->slot[id] = slot;
+ slot->quirks = dw_mci_of_get_slot_quirks(host->dev, slot->id);
+
mmc->ops = &dw_mci_ops;
mmc->f_min = DIV_ROUND_UP(host->bus_hz, 510);
mmc->f_max = host->bus_hz;
diff --git a/include/linux/mmc/dw_mmc.h b/include/linux/mmc/dw_mmc.h
index 34be4f4..24dc3a8 100644
--- a/include/linux/mmc/dw_mmc.h
+++ b/include/linux/mmc/dw_mmc.h
@@ -212,6 +212,10 @@ struct dw_mci_dma_ops {
/* Write Protect detection not available */
#define DW_MCI_QUIRK_NO_WRITE_PROTECT BIT(4)
+/* Slot level quirks */
+/* This slot has no write protect */
+#define DW_MCI_SLOT_QUIRK_NO_WRITE_PROTECT BIT(0)
+
struct dma_pdata;
struct block_settings {
--
1.7.7.3
^ permalink raw reply related
* Re: [PATCH net-next v5 01/14] vlan: wrap hw-acceleration calls in separate functions.
From: Stephen Hemminger @ 2013-01-10 18:25 UTC (permalink / raw)
To: Vlad Yasevich; +Cc: mst, netdev, stephen, bridge, shmulik.ladkani, davem
In-Reply-To: <1357751882-8619-2-git-send-email-vyasevic@redhat.com>
On Wed, 9 Jan 2013 12:17:48 -0500
Vlad Yasevich <vyasevic@redhat.com> wrote:
>
> /**
> + * vlan_hw_buggy - Check to see if VLAN hw acceleration is supported.
> + * @dev: netdevice of the lowerdev/hw nic
> + *
> + * Checks to see if HW and driver report VLAN acceleration correctly.
> + */
> +static inline bool vlan_hw_buggy(const struct net_device *dev)
> +{
> + const struct net_device_ops *ops = dev->netdev_ops;
> +
> + if ((dev->features & NETIF_F_HW_VLAN_FILTER) &&
> + (!ops->ndo_vlan_rx_add_vid || !ops->ndo_vlan_rx_kill_vid))
> + return true;
> +
> + return false;
> +}
> +
> +/**
> + * vlan_vid_add_hw - Add the VLAN vid to the HW filter
> + * @dev: netdevice of the lowerdev/hw nic
> + * @vid: vlan id.
> + *
> + * Inserts the vid into the HW vlan filter table if hw supports it.
> + */
> +static inline int vlan_vid_add_hw(struct net_device *dev,
> + unsigned short vid)
> +{
> + const struct net_device_ops *ops = dev->netdev_ops;
> + int err = 0;
> +
> + if ((dev->features & NETIF_F_HW_VLAN_FILTER) &&
> + ops->ndo_vlan_rx_add_vid)
> + err = ops->ndo_vlan_rx_add_vid(dev, vid);
> +
> + return err;
> +}
> +
> +/**
> + * vlan_vid_del_hw - Delete the VLAN vid from the HW filter
> + * @dev: netdevice of the lowerdev/hw nic
> + * @vid: vlan id.
> + *
> + * Delete the vid from the HW vlan filter table if hw supports it.
> + */
> +static inline int vlan_vid_del_hw(struct net_device *dev,
> + unsigned short vid)
> +{
> + const struct net_device_ops *ops = dev->netdev_ops;
> + int err = 0;
> +
> + if ((dev->features & NETIF_F_HW_VLAN_FILTER) &&
> + ops->ndo_vlan_rx_kill_vid)
> + err = ops->ndo_vlan_rx_add_vid(dev, vid);
> +
> + return err;
> +}
> +
I would rather not have all these inline's. This isn't performance critical.
Also, the check for buggy devices should be done inside the vlan code,
not repeated in the functions using the add/remove API. When device is
registered the flag and add/kill should be checked, and if the device driver
is buggy it should fail the register_netdevice.
^ permalink raw reply
* Re: [Bridge] [PATCH net-next v5 01/14] vlan: wrap hw-acceleration calls in separate functions.
From: Stephen Hemminger @ 2013-01-10 18:25 UTC (permalink / raw)
To: Vlad Yasevich; +Cc: mst, netdev, stephen, bridge, shmulik.ladkani, davem
In-Reply-To: <1357751882-8619-2-git-send-email-vyasevic@redhat.com>
On Wed, 9 Jan 2013 12:17:48 -0500
Vlad Yasevich <vyasevic@redhat.com> wrote:
>
> /**
> + * vlan_hw_buggy - Check to see if VLAN hw acceleration is supported.
> + * @dev: netdevice of the lowerdev/hw nic
> + *
> + * Checks to see if HW and driver report VLAN acceleration correctly.
> + */
> +static inline bool vlan_hw_buggy(const struct net_device *dev)
> +{
> + const struct net_device_ops *ops = dev->netdev_ops;
> +
> + if ((dev->features & NETIF_F_HW_VLAN_FILTER) &&
> + (!ops->ndo_vlan_rx_add_vid || !ops->ndo_vlan_rx_kill_vid))
> + return true;
> +
> + return false;
> +}
> +
> +/**
> + * vlan_vid_add_hw - Add the VLAN vid to the HW filter
> + * @dev: netdevice of the lowerdev/hw nic
> + * @vid: vlan id.
> + *
> + * Inserts the vid into the HW vlan filter table if hw supports it.
> + */
> +static inline int vlan_vid_add_hw(struct net_device *dev,
> + unsigned short vid)
> +{
> + const struct net_device_ops *ops = dev->netdev_ops;
> + int err = 0;
> +
> + if ((dev->features & NETIF_F_HW_VLAN_FILTER) &&
> + ops->ndo_vlan_rx_add_vid)
> + err = ops->ndo_vlan_rx_add_vid(dev, vid);
> +
> + return err;
> +}
> +
> +/**
> + * vlan_vid_del_hw - Delete the VLAN vid from the HW filter
> + * @dev: netdevice of the lowerdev/hw nic
> + * @vid: vlan id.
> + *
> + * Delete the vid from the HW vlan filter table if hw supports it.
> + */
> +static inline int vlan_vid_del_hw(struct net_device *dev,
> + unsigned short vid)
> +{
> + const struct net_device_ops *ops = dev->netdev_ops;
> + int err = 0;
> +
> + if ((dev->features & NETIF_F_HW_VLAN_FILTER) &&
> + ops->ndo_vlan_rx_kill_vid)
> + err = ops->ndo_vlan_rx_add_vid(dev, vid);
> +
> + return err;
> +}
> +
I would rather not have all these inline's. This isn't performance critical.
Also, the check for buggy devices should be done inside the vlan code,
not repeated in the functions using the add/remove API. When device is
registered the flag and add/kill should be checked, and if the device driver
is buggy it should fail the register_netdevice.
^ permalink raw reply
* [REPOST PATCH v3 2/4] ARM: dts: Add disable-wp for sd card slot on smdk5250
From: Doug Anderson @ 2013-01-10 18:24 UTC (permalink / raw)
To: linux-mmc
Cc: linux-samsung-soc, Thomas Abraham, Kukjin Kim, Olof Johansson,
Arnd Bergmann, Will Newton, Chris Ball, Jaehoon Chung,
Seungwon Jeon, linux-kernel, Doug Anderson, Russell King,
Rahul Sharma, Arun Kumar K, linux-arm-kernel
In-Reply-To: <1357842269-15062-1-git-send-email-dianders@chromium.org>
The next change will remove the code from the dw_mmc-exynos that added
the DW_MCI_QUIRK_NO_WRITE_PROTECT. Keep existing functionality of
having no write protect pin on smdk5250 by adding the disable-wp
property.
Signed-off-by: Doug Anderson <dianders@chromium.org>
Acked-by: Seungwon Jeon <tgih.jun@samsung.com>
---
Changes in v3:
- New for this version of the patch series.
arch/arm/boot/dts/exynos5250-smdk5250.dts | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index 942d576..75b9d83 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -146,6 +146,7 @@
reg = <0>;
bus-width = <4>;
samsung,cd-pinmux-gpio = <&gpc3 2 2 3 3>;
+ disable-wp;
gpios = <&gpc3 0 2 0 3>, <&gpc3 1 2 0 3>,
<&gpc3 3 2 3 3>, <&gpc3 4 2 3 3>,
<&gpc3 5 2 3 3>, <&gpc3 6 2 3 3>,
--
1.7.7.3
^ permalink raw reply related
* [REPOST PATCH v3 4/4] mmc: dw_mmc: Handle wp-gpios from device tree
From: Doug Anderson @ 2013-01-10 18:24 UTC (permalink / raw)
To: linux-mmc
Cc: linux-samsung-soc, Thomas Abraham, Kukjin Kim, Olof Johansson,
Arnd Bergmann, Will Newton, Chris Ball, Jaehoon Chung,
Seungwon Jeon, linux-kernel, Doug Anderson, Kyungmin Park
In-Reply-To: <1357842269-15062-1-git-send-email-dianders@chromium.org>
On some SoCs (like exynos5250) you need to use an external GPIO for
write protect. Add support for wp-gpios to the core dw_mmc driver
since it could be useful across multiple SoCs.
With this change I am able to make use of the write protect for the
external SD slot on exynos5250-snow.
Signed-off-by: Doug Anderson <dianders@chromium.org>
Acked-by: Seungwon Jeon <tgih.jun@samsung.com>
---
Changes in v3: None
Changes in v2:
- Fixed return type from u32 to int
- Return -EINVAL instead of -1
drivers/mmc/host/dw_mmc.c | 34 ++++++++++++++++++++++++++++++++++
1 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index bc0b030..e7e22ad 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -34,6 +34,7 @@
#include <linux/regulator/consumer.h>
#include <linux/workqueue.h>
#include <linux/of.h>
+#include <linux/of_gpio.h>
#include "dw_mmc.h"
@@ -75,6 +76,7 @@ struct idmac_desc {
* @mmc: The mmc_host representing this slot.
* @host: The MMC controller this slot is using.
* @quirks: Slot-level quirks (DW_MCI_SLOT_QUIRK_XXX)
+ * @wp_gpio: If gpio_is_valid() we'll use this to read write protect.
* @ctype: Card type for this slot.
* @mrq: mmc_request currently being processed or waiting to be
* processed, or NULL when the slot is idle.
@@ -90,6 +92,7 @@ struct dw_mci_slot {
struct dw_mci *host;
int quirks;
+ int wp_gpio;
u32 ctype;
@@ -833,6 +836,8 @@ static int dw_mci_get_ro(struct mmc_host *mmc)
read_only = 0;
else if (brd->get_ro)
read_only = brd->get_ro(slot->id);
+ else if (gpio_is_valid(slot->wp_gpio))
+ read_only = gpio_get_value(slot->wp_gpio);
else
read_only =
mci_readl(slot->host, WRTPRT) & (1 << slot->id) ? 1 : 0;
@@ -1827,6 +1832,29 @@ static u32 dw_mci_of_get_bus_wd(struct device *dev, u8 slot)
" as 1\n");
return bus_wd;
}
+
+/* find the write protect gpio for a given slot; or -1 if none specified */
+static int dw_mci_of_get_wp_gpio(struct device *dev, u8 slot)
+{
+ struct device_node *np = dw_mci_of_find_slot_node(dev, slot);
+ int gpio;
+
+ if (!np)
+ return -EINVAL;
+
+ gpio = of_get_named_gpio(np, "wp-gpios", 0);
+
+ /* Having a missing entry is valid; return silently */
+ if (!gpio_is_valid(gpio))
+ return -EINVAL;
+
+ if (devm_gpio_request(dev, gpio, "dw-mci-wp")) {
+ dev_warn(dev, "gpio [%d] request failed\n", gpio);
+ return -EINVAL;
+ }
+
+ return gpio;
+}
#else /* CONFIG_OF */
static int dw_mci_of_get_slot_quirks(struct device *dev, u8 slot)
{
@@ -1840,6 +1868,10 @@ static struct device_node *dw_mci_of_find_slot_node(struct device *dev, u8 slot)
{
return NULL;
}
+static int dw_mci_of_get_wp_gpio(struct device *dev, u8 slot)
+{
+ return -EINVAL;
+}
#endif /* CONFIG_OF */
static int dw_mci_init_slot(struct dw_mci *host, unsigned int id)
@@ -1957,6 +1989,8 @@ static int dw_mci_init_slot(struct dw_mci *host, unsigned int id)
else
clear_bit(DW_MMC_CARD_PRESENT, &slot->flags);
+ slot->wp_gpio = dw_mci_of_get_wp_gpio(host->dev, slot->id);
+
mmc_add_host(mmc);
#if defined(CONFIG_DEBUG_FS)
--
1.7.7.3
^ permalink raw reply related
* [REPOST PATCH v3 3/4] mmc: dw_mmc: exynos: Remove code for wp-gpios
From: Doug Anderson @ 2013-01-10 18:24 UTC (permalink / raw)
To: linux-mmc
Cc: linux-samsung-soc, Thomas Abraham, Kukjin Kim, Olof Johansson,
Arnd Bergmann, Will Newton, Chris Ball, Jaehoon Chung,
Seungwon Jeon, linux-kernel, Doug Anderson
In-Reply-To: <1357842269-15062-1-git-send-email-dianders@chromium.org>
The exynos code claimed the write protect with devm_gpio_request() but
never did anything with it. That meant that anyone using a write
protect GPIO would effectively be write protected all the time.
The handling for wp-gpios belongs in the main dw_mmc driver and has
been moved there.
Signed-off-by: Doug Anderson <dianders@chromium.org>
Acked-by: Seungwon Jeon <tgih.jun@samsung.com>
---
Changes in v3:
- Totally removed wp-gpios handling from exynos code.
Changes in v2: None
drivers/mmc/host/dw_mmc-exynos.c | 10 ----------
1 files changed, 0 insertions(+), 10 deletions(-)
diff --git a/drivers/mmc/host/dw_mmc-exynos.c b/drivers/mmc/host/dw_mmc-exynos.c
index 4d50da6..72fd0f2 100644
--- a/drivers/mmc/host/dw_mmc-exynos.c
+++ b/drivers/mmc/host/dw_mmc-exynos.c
@@ -175,16 +175,6 @@ static int dw_mci_exynos_setup_bus(struct dw_mci *host,
}
}
- gpio = of_get_named_gpio(slot_np, "wp-gpios", 0);
- if (gpio_is_valid(gpio)) {
- if (devm_gpio_request(host->dev, gpio, "dw-mci-wp"))
- dev_info(host->dev, "gpio [%d] request failed\n",
- gpio);
- } else {
- dev_info(host->dev, "wp gpio not available");
- host->pdata->quirks |= DW_MCI_QUIRK_NO_WRITE_PROTECT;
- }
-
if (host->pdata->quirks & DW_MCI_QUIRK_BROKEN_CARD_DETECTION)
return 0;
--
1.7.7.3
^ permalink raw reply related
* [REPOST PATCH v3 2/4] ARM: dts: Add disable-wp for sd card slot on smdk5250
From: Doug Anderson @ 2013-01-10 18:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1357842269-15062-1-git-send-email-dianders@chromium.org>
The next change will remove the code from the dw_mmc-exynos that added
the DW_MCI_QUIRK_NO_WRITE_PROTECT. Keep existing functionality of
having no write protect pin on smdk5250 by adding the disable-wp
property.
Signed-off-by: Doug Anderson <dianders@chromium.org>
Acked-by: Seungwon Jeon <tgih.jun@samsung.com>
---
Changes in v3:
- New for this version of the patch series.
arch/arm/boot/dts/exynos5250-smdk5250.dts | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index 942d576..75b9d83 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -146,6 +146,7 @@
reg = <0>;
bus-width = <4>;
samsung,cd-pinmux-gpio = <&gpc3 2 2 3 3>;
+ disable-wp;
gpios = <&gpc3 0 2 0 3>, <&gpc3 1 2 0 3>,
<&gpc3 3 2 3 3>, <&gpc3 4 2 3 3>,
<&gpc3 5 2 3 3>, <&gpc3 6 2 3 3>,
--
1.7.7.3
^ permalink raw reply related
* [REPOST PATCH v3 1/4] mmc: dw_mmc: Add "disable-wp" device tree property
From: Doug Anderson @ 2013-01-10 18:24 UTC (permalink / raw)
To: linux-mmc-u79uwXL29TY76Z2rM5mHXA
Cc: Kukjin Kim, linux-doc-u79uwXL29TY76Z2rM5mHXA, Seungwon Jeon,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Jaehoon Chung,
Will Newton, Kyungmin Park,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA, Abhilash Kesavan,
Chris Ball
In-Reply-To: <1354251857-21587-1-git-send-email-dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
The "disable-wp" property is used to specify that a given SD card slot
doesn't have a concept of write protect. This eliminates the need for
special case code for SD slots that should never be write protected
(like a micro SD slot or a dev board).
The dw_mmc driver is special in needing to specify "disable-wp"
because the lack of a "wp-gpios" property means to use the special
purpose write protect line. On some other mmc devices the lack of
"wp-gpios" means that write protect should be disabled.
Signed-off-by: Doug Anderson <dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Acked-by: Seungwon Jeon <tgih.jun-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
---
Changes in v3:
- New for this version of the patch series. Chose "disable-wp" rather
than the discussed "broken-internal-wp" since it mapped more cleanly
to an existing quirk (and the only reason to specify that the
internal wp is broken is if you're disabling the write protect
anyway).
- Reposted series 3 with Seungwon's ack, since it hasn't been picked
up by anyone.
.../devicetree/bindings/mmc/synopsis-dw-mshc.txt | 12 +++++-
drivers/mmc/host/dw_mmc.c | 36 +++++++++++++++++++-
include/linux/mmc/dw_mmc.h | 4 ++
3 files changed, 49 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/mmc/synopsis-dw-mshc.txt b/Documentation/devicetree/bindings/mmc/synopsis-dw-mshc.txt
index 06cd32d08..726fd21 100644
--- a/Documentation/devicetree/bindings/mmc/synopsis-dw-mshc.txt
+++ b/Documentation/devicetree/bindings/mmc/synopsis-dw-mshc.txt
@@ -26,8 +26,16 @@ Required Properties:
* bus-width: as documented in mmc core bindings.
* wp-gpios: specifies the write protect gpio line. The format of the
- gpio specifier depends on the gpio controller. If the write-protect
- line is not available, this property is optional.
+ gpio specifier depends on the gpio controller. If a GPIO is not used
+ for write-protect, this property is optional.
+
+ * disable-wp: If the wp-gpios property isn't present then (by default)
+ we'd assume that the write protect is hooked up directly to the
+ controller's special purpose write protect line (accessible via
+ the WRTPRT register). However, it's possible that we simply don't
+ want write protect. In that case specify 'disable-wp'.
+ NOTE: This property is not required for slots known to always
+ connect to eMMC or SDIO cards.
Optional properties:
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 323c502..bc0b030 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -74,6 +74,7 @@ struct idmac_desc {
* struct dw_mci_slot - MMC slot state
* @mmc: The mmc_host representing this slot.
* @host: The MMC controller this slot is using.
+ * @quirks: Slot-level quirks (DW_MCI_SLOT_QUIRK_XXX)
* @ctype: Card type for this slot.
* @mrq: mmc_request currently being processed or waiting to be
* processed, or NULL when the slot is idle.
@@ -88,6 +89,8 @@ struct dw_mci_slot {
struct mmc_host *mmc;
struct dw_mci *host;
+ int quirks;
+
u32 ctype;
struct mmc_request *mrq;
@@ -825,7 +828,8 @@ static int dw_mci_get_ro(struct mmc_host *mmc)
struct dw_mci_board *brd = slot->host->pdata;
/* Use platform get_ro function, else try on board write protect */
- if (brd->quirks & DW_MCI_QUIRK_NO_WRITE_PROTECT)
+ if ((brd->quirks & DW_MCI_QUIRK_NO_WRITE_PROTECT) ||
+ (slot->quirks & DW_MCI_SLOT_QUIRK_NO_WRITE_PROTECT))
read_only = 0;
else if (brd->get_ro)
read_only = brd->get_ro(slot->id);
@@ -1785,6 +1789,30 @@ static struct device_node *dw_mci_of_find_slot_node(struct device *dev, u8 slot)
return NULL;
}
+static struct dw_mci_of_slot_quirks {
+ char *quirk;
+ int id;
+} of_slot_quirks[] = {
+ {
+ .quirk = "disable-wp",
+ .id = DW_MCI_SLOT_QUIRK_NO_WRITE_PROTECT,
+ },
+};
+
+static int dw_mci_of_get_slot_quirks(struct device *dev, u8 slot)
+{
+ struct device_node *np = dw_mci_of_find_slot_node(dev, slot);
+ int quirks = 0;
+ int idx;
+
+ /* get quirks */
+ for (idx = 0; idx < ARRAY_SIZE(of_slot_quirks); idx++)
+ if (of_get_property(np, of_slot_quirks[idx].quirk, NULL))
+ quirks |= of_slot_quirks[idx].id;
+
+ return quirks;
+}
+
/* find out bus-width for a given slot */
static u32 dw_mci_of_get_bus_wd(struct device *dev, u8 slot)
{
@@ -1800,6 +1828,10 @@ static u32 dw_mci_of_get_bus_wd(struct device *dev, u8 slot)
return bus_wd;
}
#else /* CONFIG_OF */
+static int dw_mci_of_get_slot_quirks(struct device *dev, u8 slot)
+{
+ return 0;
+}
static u32 dw_mci_of_get_bus_wd(struct device *dev, u8 slot)
{
return 1;
@@ -1828,6 +1860,8 @@ static int dw_mci_init_slot(struct dw_mci *host, unsigned int id)
slot->host = host;
host->slot[id] = slot;
+ slot->quirks = dw_mci_of_get_slot_quirks(host->dev, slot->id);
+
mmc->ops = &dw_mci_ops;
mmc->f_min = DIV_ROUND_UP(host->bus_hz, 510);
mmc->f_max = host->bus_hz;
diff --git a/include/linux/mmc/dw_mmc.h b/include/linux/mmc/dw_mmc.h
index 34be4f4..24dc3a8 100644
--- a/include/linux/mmc/dw_mmc.h
+++ b/include/linux/mmc/dw_mmc.h
@@ -212,6 +212,10 @@ struct dw_mci_dma_ops {
/* Write Protect detection not available */
#define DW_MCI_QUIRK_NO_WRITE_PROTECT BIT(4)
+/* Slot level quirks */
+/* This slot has no write protect */
+#define DW_MCI_SLOT_QUIRK_NO_WRITE_PROTECT BIT(0)
+
struct dma_pdata;
struct block_settings {
--
1.7.7.3
^ permalink raw reply related
* RE: [PATCH v3 1/2] pstore: Avoid deadlock in panic and emergency-restart path
From: Seiji Aguchi @ 2013-01-10 18:23 UTC (permalink / raw)
To: Tony Luck
Cc: linux-kernel@vger.kernel.org, dzickus@redhat.com,
ccross@android.com, keescook@chromium.org, cbouatmailru@gmail.com,
Satoru Moriya, dle-develop@lists.sourceforge.net
In-Reply-To: <CA+8MBbKTHQJoeRVUGZr+rcXm+VwOw2vSG31Cwnrg-sc=CzLu9w@mail.gmail.com>
> Acked-by: Tony Luck <tony.luck@intel.com>
>
> [Also Ack for part2 the touches efivars.c]
>
Thanks :)
> -Tony
>
> [Or are you asking me to apply these rather than just Ack them??]
Please apply these to your tree.
Seiji
> -----Original Message-----
> From: Tony Luck [mailto:tony.luck@gmail.com]
> Sent: Thursday, January 10, 2013 1:21 PM
> To: Seiji Aguchi
> Cc: linux-kernel@vger.kernel.org; dzickus@redhat.com; ccross@android.com; keescook@chromium.org; cbouatmailru@gmail.com;
> Satoru Moriya; dle-develop@lists.sourceforge.net
> Subject: Re: [PATCH v3 1/2] pstore: Avoid deadlock in panic and emergency-restart path
>
> On Thu, Dec 20, 2012 at 7:12 AM, Seiji Aguchi <seiji.aguchi@hds.com> wrote:
> > + if (pstore_cannot_block_path(reason)) {
> > + is_locked = spin_trylock_irqsave(&psinfo->buf_lock, flags);
> > + if (!is_locked) {
> > + pr_err("pstore dump routine blocked in %s path, may corrupt error record\n"
> > + , in_nmi() ? "NMI" : why);
> > + }
>
> My only quibble with this patchset is this message. The sentiment is nice, but nobody will see it. kmsg_dump has already picked the
> pieces of log_buf that will be saved to pstore - so this new message won't be included. I suppose it will show up on a serial console -
> but if a user has a serial console, they don't need to use pstore.
>
> But I don't think it is likely to hurt us (to get this far in a panic we already printed a bunch of stuff to the console and I can't think of a
> credible scenario where a few extra bytes would run into a problem that the earlier messages didn't).
>
> So:
>
> Acked-by: Tony Luck <tony.luck@intel.com>
>
> [Also Ack for part2 the touches efivars.c]
>
> -Tony
>
> [Or are you asking me to apply these rather than just Ack them??]
^ permalink raw reply
* Re: tainted warnings with tcp splicing in 3.7.1
From: Rick Jones @ 2013-01-10 18:22 UTC (permalink / raw)
To: Eric Dumazet
Cc: Willy Tarreau, Christian Becker, David Miller,
netdev@vger.kernel.org
In-Reply-To: <1357834825.27446.2205.camel@edumazet-glaptop>
On 01/10/2013 08:20 AM, Eric Dumazet wrote:
> I also want to thanks Rick, as the latest netperf has splice() support.
>
> Thanks Rick !
You are quite welcome - and thank you for helping me get it to actually
work :)
Those wishing to try it themselves should grab the top-of-trunk netperf
bits from http://www.netperf.org/svn/netperf2/trunk . The use of
splice() is gated by a test-specific -V option:
raj@tardy:~/netperf2_trunk/src$ ./netperf -t omni -- -d recv -V
OMNI Receive TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
localhost.localdomain () port 0 AF_INET : copy avoidance : demo
Remote Local Remote Elapsed Throughput Throughput
Send Socket Recv Socket Send Time Units
Size Size Size (sec)
Final Final
1661688 4194304 16384 10.00 26103.14 10^6bits/s
You should see that "copy avoidance" appearing in the test banner. It
will also "take" for things like a migrated TCP_mumble test. For those
cases where you don't see a throughput change, enabling CPU utilization
measurement and looking at that and service demand should show a difference.
happy benchmarking,
rick jones
^ permalink raw reply
* Re: [PATCH v3 1/2] pstore: Avoid deadlock in panic and emergency-restart path
From: Tony Luck @ 2013-01-10 18:20 UTC (permalink / raw)
To: Seiji Aguchi
Cc: linux-kernel@vger.kernel.org, dzickus@redhat.com,
ccross@android.com, keescook@chromium.org, cbouatmailru@gmail.com,
Satoru Moriya, dle-develop@lists.sourceforge.net
In-Reply-To: <A5ED84D3BB3A384992CBB9C77DEDA4D414A2A05C@USINDEM103.corp.hds.com>
On Thu, Dec 20, 2012 at 7:12 AM, Seiji Aguchi <seiji.aguchi@hds.com> wrote:
> + if (pstore_cannot_block_path(reason)) {
> + is_locked = spin_trylock_irqsave(&psinfo->buf_lock, flags);
> + if (!is_locked) {
> + pr_err("pstore dump routine blocked in %s path, may corrupt error record\n"
> + , in_nmi() ? "NMI" : why);
> + }
My only quibble with this patchset is this message. The sentiment is
nice, but nobody will see it. kmsg_dump has already picked the
pieces of log_buf that will be saved to pstore - so this new message
won't be included. I suppose it will show up on a serial console - but
if a user has a serial console, they don't need to use pstore.
But I don't think it is likely to hurt us (to get this far in a panic we already
printed a bunch of stuff to the console and I can't think of a credible
scenario where a few extra bytes would run into a problem that the
earlier messages didn't).
So:
Acked-by: Tony Luck <tony.luck@intel.com>
[Also Ack for part2 the touches efivars.c]
-Tony
[Or are you asking me to apply these rather than just Ack them??]
^ permalink raw reply
* Re: [PATCH 05/14] lib: Add I/O map cache implementation
From: Jason Gunthorpe @ 2013-01-10 18:20 UTC (permalink / raw)
To: Thierry Reding
Cc: Arnd Bergmann, Stephen Warren, linux-tegra, Grant Likely,
Rob Herring, Russell King, Bjorn Helgaas, Andrew Murray,
Thomas Petazzoni, devicetree-discuss, linux-kernel,
linux-arm-kernel, linux-pci
In-Reply-To: <20130110102544.GA5546@avionic-0098.adnet.avionic-design.de>
On Thu, Jan 10, 2013 at 11:25:44AM +0100, Thierry Reding wrote:
> On Thu, Jan 10, 2013 at 09:17:19AM +0000, Arnd Bergmann wrote:
> > On Thursday 10 January 2013, Thierry Reding wrote:
> > > On Wed, Jan 09, 2013 at 04:17:58PM -0700, Jason Gunthorpe wrote:
> > > > On Wed, Jan 09, 2013 at 04:12:31PM -0700, Stephen Warren wrote:
> > > > You could decrease the size of the mapping to only span the bus
> > > > numbers that are configured for use via DT.
> > >
> > > That won't work, unfortunately. The mapping is such that the bus number
> > > is not encoded in the uppermost bits, the extended register number is.
> > > So the only thing that we could do is decrease the size of the extended
> > > register space for *all* devices.
> >
> > But you could still a method to map 16 separate areas per bus, each 65536
> > bytes long, which results in 1MB per bus. That is probably ok, since
> > very few systems have more than a handful of buses in practice.
> >
> > In theory, doing static mappings on a per-page base would let you
> > do 16 devices at a time, but it's probably worth doing at this fine
> > granularity.
>
> I don't understand how this would help. The encoding is like this:
>
> [27:24] extended register number
> [23:16] bus number
> [15:11] device number
> [10: 8] function number
> [ 7: 0] register number
>
> So it doesn't matter whether I use separate areas per bus or not. As
> soon as the whole extended configuration space needs to be accessed a
> whopping 28 bits (256 MiB) are required.
You'd piece a mapping together, each bus requires 16 64k mappings, a
simple 2d array of busnr*16 of pointers would do the trick. A more
clever solution would be to allocate contiguous virtual memory and
split that up..
> > Actually, AER probably needs this, and I believe some broken devices
> > need to mask interrupts using the PCI command word in the config space,
> > it it can happen.
>
> Ugh... that would kill any such dynamic mapping approach. Perhaps if we
> could mark a device as requiring a static mapping we could pin that
> cache entry. But that doesn't sound very encouraging.
AER applies to pretty much every PCI-E device these days.
Jason
^ 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.