* [PATCH v6 12/46] virtio: set FEATURES_OK
From: Michael S. Tsirkin @ 2014-11-27 20:08 UTC (permalink / raw)
To: linux-kernel
Cc: David Miller, cornelia.huck, rusty, nab, pbonzini, thuth, dahi,
Rusty Russell, virtualization, linux-api
In-Reply-To: <1417118789-18231-1-git-send-email-mst@redhat.com>
set FEATURES_OK as per virtio 1.0 spec
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
include/uapi/linux/virtio_config.h | 2 ++
drivers/virtio/virtio.c | 29 ++++++++++++++++++++++-------
2 files changed, 24 insertions(+), 7 deletions(-)
diff --git a/include/uapi/linux/virtio_config.h b/include/uapi/linux/virtio_config.h
index 80e7381..4d05671 100644
--- a/include/uapi/linux/virtio_config.h
+++ b/include/uapi/linux/virtio_config.h
@@ -38,6 +38,8 @@
#define VIRTIO_CONFIG_S_DRIVER 2
/* Driver has used its parts of the config, and is happy */
#define VIRTIO_CONFIG_S_DRIVER_OK 4
+/* Driver has finished configuring features */
+#define VIRTIO_CONFIG_S_FEATURES_OK 8
/* We've given up on this device. */
#define VIRTIO_CONFIG_S_FAILED 0x80
diff --git a/drivers/virtio/virtio.c b/drivers/virtio/virtio.c
index 746d350..9248125 100644
--- a/drivers/virtio/virtio.c
+++ b/drivers/virtio/virtio.c
@@ -160,6 +160,7 @@ static int virtio_dev_probe(struct device *_d)
struct virtio_device *dev = dev_to_virtio(_d);
struct virtio_driver *drv = drv_to_virtio(dev->dev.driver);
u64 device_features;
+ unsigned status;
/* We have a driver! */
add_status(dev, VIRTIO_CONFIG_S_DRIVER);
@@ -183,18 +184,32 @@ static int virtio_dev_probe(struct device *_d)
dev->config->finalize_features(dev);
+ if (virtio_has_feature(dev, VIRTIO_F_VERSION_1)) {
+ add_status(dev, VIRTIO_CONFIG_S_FEATURES_OK);
+ status = dev->config->get_status(dev);
+ if (!(status & VIRTIO_CONFIG_S_FEATURES_OK)) {
+ dev_err(_d, "virtio: device refuses features: %x\n",
+ status);
+ err = -ENODEV;
+ goto err;
+ }
+ }
+
err = drv->probe(dev);
if (err)
- add_status(dev, VIRTIO_CONFIG_S_FAILED);
- else {
- add_status(dev, VIRTIO_CONFIG_S_DRIVER_OK);
- if (drv->scan)
- drv->scan(dev);
+ goto err;
- virtio_config_enable(dev);
- }
+ add_status(dev, VIRTIO_CONFIG_S_DRIVER_OK);
+ if (drv->scan)
+ drv->scan(dev);
+
+ virtio_config_enable(dev);
+ return 0;
+err:
+ add_status(dev, VIRTIO_CONFIG_S_FAILED);
return err;
+
}
static int virtio_dev_remove(struct device *_d)
--
MST
^ permalink raw reply related
* [PATCH v6 08/46] virtio: memory access APIs
From: Michael S. Tsirkin @ 2014-11-27 20:08 UTC (permalink / raw)
To: linux-kernel
Cc: thuth, rusty, Greg Kroah-Hartman, David Drysdale, dahi,
Sakari Ailus, linux-api, pbonzini, Andy Grover, virtualization,
David Miller, =?UTF-8?q?Piotr=20Kr=C3=B3l?=, Alexei Starovoitov
In-Reply-To: <1417118789-18231-1-git-send-email-mst@redhat.com>
virtio 1.0 makes all memory structures LE, so
we need APIs to conditionally do a byteswap on BE
architectures.
To make it easier to check code statically,
add virtio specific types for multi-byte integers
in memory.
Add low level wrappers that do a byteswap conditionally, these will be
useful e.g. for vhost. Add high level wrappers that
query device endian-ness and act accordingly.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
include/linux/virtio_byteorder.h | 59 +++++++++++++++++++++++++++++++++++++++
include/linux/virtio_config.h | 32 +++++++++++++++++++++
include/uapi/linux/virtio_ring.h | 45 ++++++++++++++---------------
include/uapi/linux/virtio_types.h | 46 ++++++++++++++++++++++++++++++
include/uapi/linux/Kbuild | 1 +
5 files changed, 161 insertions(+), 22 deletions(-)
create mode 100644 include/linux/virtio_byteorder.h
create mode 100644 include/uapi/linux/virtio_types.h
diff --git a/include/linux/virtio_byteorder.h b/include/linux/virtio_byteorder.h
new file mode 100644
index 0000000..51865d0
--- /dev/null
+++ b/include/linux/virtio_byteorder.h
@@ -0,0 +1,59 @@
+#ifndef _LINUX_VIRTIO_BYTEORDER_H
+#define _LINUX_VIRTIO_BYTEORDER_H
+#include <linux/types.h>
+#include <uapi/linux/virtio_types.h>
+
+/*
+ * Low-level memory accessors for handling virtio in modern little endian and in
+ * compatibility native endian format.
+ */
+
+static inline u16 __virtio16_to_cpu(bool little_endian, __virtio16 val)
+{
+ if (little_endian)
+ return le16_to_cpu((__force __le16)val);
+ else
+ return (__force u16)val;
+}
+
+static inline __virtio16 __cpu_to_virtio16(bool little_endian, u16 val)
+{
+ if (little_endian)
+ return (__force __virtio16)cpu_to_le16(val);
+ else
+ return (__force __virtio16)val;
+}
+
+static inline u32 __virtio32_to_cpu(bool little_endian, __virtio32 val)
+{
+ if (little_endian)
+ return le32_to_cpu((__force __le32)val);
+ else
+ return (__force u32)val;
+}
+
+static inline __virtio32 __cpu_to_virtio32(bool little_endian, u32 val)
+{
+ if (little_endian)
+ return (__force __virtio32)cpu_to_le32(val);
+ else
+ return (__force __virtio32)val;
+}
+
+static inline u64 __virtio64_to_cpu(bool little_endian, __virtio64 val)
+{
+ if (little_endian)
+ return le64_to_cpu((__force __le64)val);
+ else
+ return (__force u64)val;
+}
+
+static inline __virtio64 __cpu_to_virtio64(bool little_endian, u64 val)
+{
+ if (little_endian)
+ return (__force __virtio64)cpu_to_le64(val);
+ else
+ return (__force __virtio64)val;
+}
+
+#endif /* _LINUX_VIRTIO_BYTEORDER */
diff --git a/include/linux/virtio_config.h b/include/linux/virtio_config.h
index b465c3f..e1c5d2b 100644
--- a/include/linux/virtio_config.h
+++ b/include/linux/virtio_config.h
@@ -4,6 +4,7 @@
#include <linux/err.h>
#include <linux/bug.h>
#include <linux/virtio.h>
+#include <linux/virtio_byteorder.h>
#include <uapi/linux/virtio_config.h>
/**
@@ -199,6 +200,37 @@ int virtqueue_set_affinity(struct virtqueue *vq, int cpu)
return 0;
}
+/* Memory accessors */
+static inline u16 virtio16_to_cpu(struct virtio_device *vdev, __virtio16 val)
+{
+ return __virtio16_to_cpu(virtio_has_feature(vdev, VIRTIO_F_VERSION_1), val);
+}
+
+static inline __virtio16 cpu_to_virtio16(struct virtio_device *vdev, u16 val)
+{
+ return __cpu_to_virtio16(virtio_has_feature(vdev, VIRTIO_F_VERSION_1), val);
+}
+
+static inline u32 virtio32_to_cpu(struct virtio_device *vdev, __virtio32 val)
+{
+ return __virtio32_to_cpu(virtio_has_feature(vdev, VIRTIO_F_VERSION_1), val);
+}
+
+static inline __virtio32 cpu_to_virtio32(struct virtio_device *vdev, u32 val)
+{
+ return __cpu_to_virtio32(virtio_has_feature(vdev, VIRTIO_F_VERSION_1), val);
+}
+
+static inline u64 virtio64_to_cpu(struct virtio_device *vdev, __virtio64 val)
+{
+ return __virtio64_to_cpu(virtio_has_feature(vdev, VIRTIO_F_VERSION_1), val);
+}
+
+static inline __virtio64 cpu_to_virtio64(struct virtio_device *vdev, u64 val)
+{
+ return __cpu_to_virtio64(virtio_has_feature(vdev, VIRTIO_F_VERSION_1), val);
+}
+
/* Config space accessors. */
#define virtio_cread(vdev, structname, member, ptr) \
do { \
diff --git a/include/uapi/linux/virtio_ring.h b/include/uapi/linux/virtio_ring.h
index a99f9b7..61c818a 100644
--- a/include/uapi/linux/virtio_ring.h
+++ b/include/uapi/linux/virtio_ring.h
@@ -32,6 +32,7 @@
*
* Copyright Rusty Russell IBM Corporation 2007. */
#include <linux/types.h>
+#include <linux/virtio_types.h>
/* This marks a buffer as continuing via the next field. */
#define VRING_DESC_F_NEXT 1
@@ -61,32 +62,32 @@
/* Virtio ring descriptors: 16 bytes. These can chain together via "next". */
struct vring_desc {
/* Address (guest-physical). */
- __u64 addr;
+ __virtio64 addr;
/* Length. */
- __u32 len;
+ __virtio32 len;
/* The flags as indicated above. */
- __u16 flags;
+ __virtio16 flags;
/* We chain unused descriptors via this, too */
- __u16 next;
+ __virtio16 next;
};
struct vring_avail {
- __u16 flags;
- __u16 idx;
- __u16 ring[];
+ __virtio16 flags;
+ __virtio16 idx;
+ __virtio16 ring[];
};
/* u32 is used here for ids for padding reasons. */
struct vring_used_elem {
/* Index of start of used descriptor chain. */
- __u32 id;
+ __virtio32 id;
/* Total length of the descriptor chain which was used (written to) */
- __u32 len;
+ __virtio32 len;
};
struct vring_used {
- __u16 flags;
- __u16 idx;
+ __virtio16 flags;
+ __virtio16 idx;
struct vring_used_elem ring[];
};
@@ -109,25 +110,25 @@ struct vring {
* struct vring_desc desc[num];
*
* // A ring of available descriptor heads with free-running index.
- * __u16 avail_flags;
- * __u16 avail_idx;
- * __u16 available[num];
- * __u16 used_event_idx;
+ * __virtio16 avail_flags;
+ * __virtio16 avail_idx;
+ * __virtio16 available[num];
+ * __virtio16 used_event_idx;
*
* // Padding to the next align boundary.
* char pad[];
*
* // A ring of used descriptor heads with free-running index.
- * __u16 used_flags;
- * __u16 used_idx;
+ * __virtio16 used_flags;
+ * __virtio16 used_idx;
* struct vring_used_elem used[num];
- * __u16 avail_event_idx;
+ * __virtio16 avail_event_idx;
* };
*/
/* We publish the used event index at the end of the available ring, and vice
* versa. They are at the end for backwards compatibility. */
#define vring_used_event(vr) ((vr)->avail->ring[(vr)->num])
-#define vring_avail_event(vr) (*(__u16 *)&(vr)->used->ring[(vr)->num])
+#define vring_avail_event(vr) (*(__virtio16 *)&(vr)->used->ring[(vr)->num])
static inline void vring_init(struct vring *vr, unsigned int num, void *p,
unsigned long align)
@@ -135,15 +136,15 @@ static inline void vring_init(struct vring *vr, unsigned int num, void *p,
vr->num = num;
vr->desc = p;
vr->avail = p + num*sizeof(struct vring_desc);
- vr->used = (void *)(((unsigned long)&vr->avail->ring[num] + sizeof(__u16)
+ vr->used = (void *)(((unsigned long)&vr->avail->ring[num] + sizeof(__virtio16)
+ align-1) & ~(align - 1));
}
static inline unsigned vring_size(unsigned int num, unsigned long align)
{
- return ((sizeof(struct vring_desc) * num + sizeof(__u16) * (3 + num)
+ return ((sizeof(struct vring_desc) * num + sizeof(__virtio16) * (3 + num)
+ align - 1) & ~(align - 1))
- + sizeof(__u16) * 3 + sizeof(struct vring_used_elem) * num;
+ + sizeof(__virtio16) * 3 + sizeof(struct vring_used_elem) * num;
}
/* The following is used with USED_EVENT_IDX and AVAIL_EVENT_IDX */
diff --git a/include/uapi/linux/virtio_types.h b/include/uapi/linux/virtio_types.h
new file mode 100644
index 0000000..e845e8c
--- /dev/null
+++ b/include/uapi/linux/virtio_types.h
@@ -0,0 +1,46 @@
+#ifndef _UAPI_LINUX_VIRTIO_TYPES_H
+#define _UAPI_LINUX_VIRTIO_TYPES_H
+/* Type definitions for virtio implementations.
+ *
+ * This header is BSD licensed so anyone can use the definitions to implement
+ * compatible drivers/servers.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * 3. Neither the name of IBM nor the names of its contributors
+ * may be used to endorse or promote products derived from this software
+ * without specific prior written permission.
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL IBM OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ *
+ * Copyright (C) 2014 Red Hat, Inc.
+ * Author: Michael S. Tsirkin <mst@redhat.com>
+ */
+#include <linux/types.h>
+
+/*
+ * __virtio{16,32,64} have the following meaning:
+ * - __u{16,32,64} for virtio devices in legacy mode, accessed in native endian
+ * - __le{16,32,64} for standard-compliant virtio devices
+ */
+
+typedef __u16 __bitwise__ __virtio16;
+typedef __u32 __bitwise__ __virtio32;
+typedef __u64 __bitwise__ __virtio64;
+
+#endif /* _UAPI_LINUX_VIRTIO_TYPES_H */
diff --git a/include/uapi/linux/Kbuild b/include/uapi/linux/Kbuild
index 4c94f31..44a5581 100644
--- a/include/uapi/linux/Kbuild
+++ b/include/uapi/linux/Kbuild
@@ -423,6 +423,7 @@ header-y += virtio_blk.h
header-y += virtio_config.h
header-y += virtio_console.h
header-y += virtio_ids.h
+header-y += virtio_types.h
header-y += virtio_net.h
header-y += virtio_pci.h
header-y += virtio_ring.h
--
MST
^ permalink raw reply related
* [PATCH v6 07/46] virtio: add virtio 1.0 feature bit
From: Michael S. Tsirkin @ 2014-11-27 20:08 UTC (permalink / raw)
To: linux-kernel
Cc: thuth, rusty, linux-api, virtualization, dahi, pbonzini,
David Miller
In-Reply-To: <1417118789-18231-1-git-send-email-mst@redhat.com>
Based on original patches by Rusty Russell, Thomas Huth
and Cornelia Huck.
Note: at this time, we do not negotiate this feature bit
in core, drivers have to declare VERSION_1 support explicitly.
For this reason we treat this bit as a device bit
and not as a transport bit for now.
After all drivers are converted, we will be able to
move VERSION_1 to core and drop it from all drivers.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com>
---
include/uapi/linux/virtio_config.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/uapi/linux/virtio_config.h b/include/uapi/linux/virtio_config.h
index 3ce768c..80e7381 100644
--- a/include/uapi/linux/virtio_config.h
+++ b/include/uapi/linux/virtio_config.h
@@ -54,4 +54,7 @@
/* Can the device handle any descriptor layout? */
#define VIRTIO_F_ANY_LAYOUT 27
+/* v1.0 compliant. */
+#define VIRTIO_F_VERSION_1 32
+
#endif /* _UAPI_LINUX_VIRTIO_CONFIG_H */
--
MST
^ permalink raw reply related
* Re: [PATCH v14 0/3] Add drm driver for Rockchip Socs
From: Daniel Kurtz @ 2014-11-27 19:05 UTC (permalink / raw)
To: Mark yao, Arnd Bergmann
Cc: Dave Airlie, Joerg Roedel, Heiko Stübner, Boris BREZILLON,
Rob Clark, Daniel Vetter, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, Randy Dunlap, Grant Likely,
Greg Kroah-Hartman, John Stultz, Rom Lemarchand,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-doc-u79uwXL29TY76Z2rM5mHXA, LKML, dri-devel,
linux-api-u79uwXL29TY76Z2rM5mHXA, open list:ARM/Rockchip SoC...
In-Reply-To: <5476CDF7.60208-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
On Thu, Nov 27, 2014 at 2:08 AM, Mark yao <mark.yao-TNX95d0MmH7DzftRWevZcw@public.gmane.org> wrote:
>
> On 2014年11月27日 10:12, Dave Airlie wrote:
>>>>
>>>>
>>> Hi Dave
>>> Do you mean that I need send you a branch, based on drm-next, merge with
>>> iommu tree and rockchip drm?
>>
>> Yes, grab drm-next, git pull the arm/rockchip branch from Joerg's
>> tree, put rockchip drm
>> patches on top, send me pull request.
>>
>> I'll validate it then.
>>
>> Dave.
>>
> Hi Dave
> I have send a pull request to you, with Joerg's iommu arm/rockchip branch.
>
> I got a same problem when use "make multi_v7_defconfig" as Heiko said:
> drivers/video/fbdev/Kconfig:5:error: recursive dependency detected!
> drivers/video/fbdev/Kconfig:5: symbol FB is selected by DRM_KMS_FB_HELPER
> drivers/gpu/drm/Kconfig:34: symbol DRM_KMS_FB_HELPER is selected by DRM_ROCKCHIP
> drivers/gpu/drm/rockchip/Kconfig:1: symbol DRM_ROCKCHIP depends on ARM_DMA_USE_IOMMU
> arch/arm/Kconfig:95: symbol ARM_DMA_USE_IOMMU is selected by VIDEO_OMAP3
> drivers/media/platform/Kconfig:96: symbol VIDEO_OMAP3 depends on VIDEO_V4L2
> drivers/media/v4l2-core/Kconfig:6: symbol VIDEO_V4L2 depends on I2C
> drivers/i2c/Kconfig:7: symbol I2C is selected by FB_DDC
> drivers/video/fbdev/Kconfig:59: symbol FB_DDC is selected by FB_CYBER2000_DDC
> drivers/video/fbdev/Kconfig:374: symbol FB_CYBER2000_DDC depends on FB_CYBER2000
> drivers/video/fbdev/Kconfig:362: symbol FB_CYBER2000 depends on FB
>
> I was confused how to solve the recursive dependency, remove depends on ARM_DMA_USE_IOMMU & IOMMU_API?
The "depends on ARM_DMA_USE_IOMMU & IOMMU_API" was suggested by Arnd
Bergmann during code review (originally they were selected).
Removing them definitely fixes the dependency recursion.
Also, since they are both already selected by ROCKCHIP_IOMMU,
everything will build correctly.
So, this sounds good to me, but I am no expert on Kconfig.
-Dan
>
> - Mark
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC] lsm: namespace hooks
From: Lukasz Pawelczyk @ 2014-11-27 17:38 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Vladimir Davydov, Miklos Szeredi, Lukasz Pawelczyk, LKML,
David Howells, Mark Rustad, Matthew Dempsky, Richard Weinberger,
Daeseok Youn, Ingo Molnar, Jeff Kirsher, David Rientjes,
Alex Thorlton, Juri Lelli, Kees Cook, Nikolay Aleksandrov,
Dario Faggioli, Al Viro, James Morris, open list:ABI/API,
Linux Containers, Oleg Nesterov, Paul Moore
In-Reply-To: <871tooy4nc.fsf-JOvCrm2gF+uungPnsOpG7nhyD016LWXt@public.gmane.org>
On czw, 2014-11-27 at 10:44 -0600, Eric W. Biederman wrote:
> Lukasz Pawelczyk <l.pawelczyk-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org> writes:
>
> > On czw, 2014-11-27 at 09:42 -0600, Eric W. Biederman wrote:
> >> We are probably going to need to go a couple rounds with this but at
> >> first approximation I think this functionality needs to be tied to the
> >> user namespace. This functionality already looks half tied to it.
Actually it's not. You can create LSM/Smack namespace without user
namespace and it works properly.
> >> When mounting filesystems with user namespaces priveleges matures a
> >> little more you should be able to use unmapped labels. In the near term
> >> we are looking at filesystems such as tmpfs, fuse and posibly extN.
Ok, I get the idea now. But still think it wouldn't do well with the
Smack namespace. It would basically allow you to operate on something
that the administrator did not allowed you to (by filling the labels'
map).
If the user namespace allows such a thing now I was not aware. I'll have
a look.
> I had two points.
> a) Tie the label mapping to the user namespace, then we don't need any
> new namespaces.
>
> Is there a reason not to tie the label mapping to the user namespace?
I remember that I entertained the idea when I started the work on that
and for some reason went against it.
Right now the major issue I see is that LSM by itself is not defined how
it's going to behave. It's up to a specific LSM module.
E.g. within the Smack namespace filling the map is a privileged
operation. So by tying them up you cripple the ability to create a fully
working user namespace as an unprivileged process.
I want to have Smack namespace be able to map its own label without
privileges (as user namespace can do with its own UID) but for now it's
not the case and I'm not sure it will ever be.
With other LSM implementation other limitations might apply.
Besides a use case (with other LSM modules) when someone might not want
to create an LSM namespace might be valid as well.
>
> Needing to modify every userspace that create containers to know
> about every different lsm looks like a maintenance difficulty I would
> prefer to avoid.
The LSM namespace is only one, it's not like every LSM modules creates a
different namespace. The LSM namespace is created for the LSM module
that is active at the moment. And user space might need to be aware of
them anyway as e.g. Smack requires you to create labels' map. Other
modules might require something different.
BTW: have you read the Smack-namespace readme I pasted in the cover
letter? It describes the idea behind namespace implementation in that
particular module.
--
Lukasz Pawelczyk
Samsung R&D Institute Poland
Samsung Electronics
^ permalink raw reply
* [PATCH v10 04/20] vfio: amba: VFIO support for AMBA devices
From: Antonios Motakis @ 2014-11-27 17:32 UTC (permalink / raw)
To: kvmarm-FPEHb7Xf0XXUo1n7N8X6UoWGPAHP3yOg,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
alex.williamson-H+wXaHxf7aLQT0dZR+AlfA
Cc: open list:VFIO DRIVER, eric.auger-QSEj5FYQhm4dnm+yROfE0A,
marc.zyngier-5wv7dgnIgG8, open list:ABI/API,
will.deacon-5wv7dgnIgG8, open list, Antonios Motakis,
tech-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J,
christoffer.dall-QSEj5FYQhm4dnm+yROfE0A
In-Reply-To: <1417109580-10505-1-git-send-email-a.motakis-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J@public.gmane.org>
Add support for discovering AMBA devices with VFIO and handle them
similarly to Linux platform devices.
Signed-off-by: Antonios Motakis <a.motakis-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J@public.gmane.org>
---
drivers/vfio/platform/vfio_amba.c | 110 ++++++++++++++++++++++++++++++++++++++
include/uapi/linux/vfio.h | 1 +
2 files changed, 111 insertions(+)
create mode 100644 drivers/vfio/platform/vfio_amba.c
diff --git a/drivers/vfio/platform/vfio_amba.c b/drivers/vfio/platform/vfio_amba.c
new file mode 100644
index 0000000..be33fb5
--- /dev/null
+++ b/drivers/vfio/platform/vfio_amba.c
@@ -0,0 +1,110 @@
+/*
+ * Copyright (C) 2013 - Virtual Open Systems
+ * Author: Antonios Motakis <a.motakis-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J@public.gmane.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License, version 2, as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/module.h>
+#include <linux/slab.h>
+#include <linux/vfio.h>
+#include <linux/amba/bus.h>
+
+#include "vfio_platform_private.h"
+
+#define DRIVER_VERSION "0.10"
+#define DRIVER_AUTHOR "Antonios Motakis <a.motakis-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J@public.gmane.org>"
+#define DRIVER_DESC "VFIO for AMBA devices - User Level meta-driver"
+
+/* probing devices from the AMBA bus */
+
+static struct resource *get_amba_resource(struct vfio_platform_device *vdev,
+ int i)
+{
+ struct amba_device *adev = (struct amba_device *) vdev->opaque;
+
+ if (i == 0)
+ return &adev->res;
+
+ return NULL;
+}
+
+static int get_amba_irq(struct vfio_platform_device *vdev, int i)
+{
+ struct amba_device *adev = (struct amba_device *) vdev->opaque;
+ int ret = 0;
+
+ if (i < AMBA_NR_IRQS)
+ ret = adev->irq[i];
+
+ /* zero is an unset IRQ for AMBA devices */
+ return ret ? ret : -ENXIO;
+}
+
+static int vfio_amba_probe(struct amba_device *adev, const struct amba_id *id)
+{
+ struct vfio_platform_device *vdev;
+ int ret;
+
+ vdev = kzalloc(sizeof(*vdev), GFP_KERNEL);
+ if (!vdev)
+ return -ENOMEM;
+
+ vdev->opaque = (void *) adev;
+ vdev->name = kasprintf(GFP_KERNEL, "vfio-amba-%08x", adev->periphid);
+ vdev->flags = VFIO_DEVICE_FLAGS_AMBA;
+ vdev->get_resource = get_amba_resource;
+ vdev->get_irq = get_amba_irq;
+
+ ret = vfio_platform_probe_common(vdev, &adev->dev);
+ if (ret) {
+ kfree(vdev->name);
+ kfree(vdev);
+ }
+
+ return ret;
+}
+
+static int vfio_amba_remove(struct amba_device *adev)
+{
+ struct vfio_platform_device *vdev;
+
+ vdev = vfio_platform_remove_common(&adev->dev);
+ if (vdev) {
+ kfree(vdev->name);
+ kfree(vdev);
+ return 0;
+ }
+
+ return -EINVAL;
+}
+
+static struct amba_id pl330_ids[] = {
+ { 0, 0 },
+};
+
+MODULE_DEVICE_TABLE(amba, pl330_ids);
+
+static struct amba_driver vfio_amba_driver = {
+ .probe = vfio_amba_probe,
+ .remove = vfio_amba_remove,
+ .id_table = pl330_ids,
+ .drv = {
+ .name = "vfio-amba",
+ .owner = THIS_MODULE,
+ },
+};
+
+module_amba_driver(vfio_amba_driver);
+
+MODULE_VERSION(DRIVER_VERSION);
+MODULE_LICENSE("GPL v2");
+MODULE_AUTHOR(DRIVER_AUTHOR);
+MODULE_DESCRIPTION(DRIVER_DESC);
diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
index 4e93a97..544d3d8 100644
--- a/include/uapi/linux/vfio.h
+++ b/include/uapi/linux/vfio.h
@@ -160,6 +160,7 @@ struct vfio_device_info {
#define VFIO_DEVICE_FLAGS_RESET (1 << 0) /* Device supports reset */
#define VFIO_DEVICE_FLAGS_PCI (1 << 1) /* vfio-pci device */
#define VFIO_DEVICE_FLAGS_PLATFORM (1 << 2) /* vfio-platform device */
+#define VFIO_DEVICE_FLAGS_AMBA (1 << 3) /* vfio-amba device */
__u32 num_regions; /* Max region index + 1 */
__u32 num_irqs; /* Max IRQ index + 1 */
};
--
2.1.3
^ permalink raw reply related
* [PATCH v10 02/20] vfio: platform: probe to devices on the platform bus
From: Antonios Motakis @ 2014-11-27 17:32 UTC (permalink / raw)
To: kvmarm-FPEHb7Xf0XXUo1n7N8X6UoWGPAHP3yOg,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
alex.williamson-H+wXaHxf7aLQT0dZR+AlfA
Cc: open list:VFIO DRIVER, eric.auger-QSEj5FYQhm4dnm+yROfE0A,
marc.zyngier-5wv7dgnIgG8, open list:ABI/API,
will.deacon-5wv7dgnIgG8, open list, Antonios Motakis,
tech-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J,
christoffer.dall-QSEj5FYQhm4dnm+yROfE0A
In-Reply-To: <1417109580-10505-1-git-send-email-a.motakis-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J@public.gmane.org>
Driver to bind to Linux platform devices, and callbacks to discover their
resources to be used by the main VFIO PLATFORM code.
Signed-off-by: Antonios Motakis <a.motakis-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J@public.gmane.org>
---
drivers/vfio/platform/vfio_platform.c | 103 ++++++++++++++++++++++++++++++++++
include/uapi/linux/vfio.h | 1 +
2 files changed, 104 insertions(+)
create mode 100644 drivers/vfio/platform/vfio_platform.c
diff --git a/drivers/vfio/platform/vfio_platform.c b/drivers/vfio/platform/vfio_platform.c
new file mode 100644
index 0000000..cef645c
--- /dev/null
+++ b/drivers/vfio/platform/vfio_platform.c
@@ -0,0 +1,103 @@
+/*
+ * Copyright (C) 2013 - Virtual Open Systems
+ * Author: Antonios Motakis <a.motakis-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J@public.gmane.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License, version 2, as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/module.h>
+#include <linux/slab.h>
+#include <linux/vfio.h>
+#include <linux/platform_device.h>
+
+#include "vfio_platform_private.h"
+
+#define DRIVER_VERSION "0.10"
+#define DRIVER_AUTHOR "Antonios Motakis <a.motakis-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J@public.gmane.org>"
+#define DRIVER_DESC "VFIO for platform devices - User Level meta-driver"
+
+/* probing devices from the linux platform bus */
+
+static struct resource *get_platform_resource(struct vfio_platform_device *vdev,
+ int num)
+{
+ struct platform_device *dev = (struct platform_device *) vdev->opaque;
+ int i;
+
+ for (i = 0; i < dev->num_resources; i++) {
+ struct resource *r = &dev->resource[i];
+
+ if (resource_type(r) & (IORESOURCE_MEM|IORESOURCE_IO)) {
+ if (!num)
+ return r;
+
+ num--;
+ }
+ }
+ return NULL;
+}
+
+static int get_platform_irq(struct vfio_platform_device *vdev, int i)
+{
+ struct platform_device *pdev = (struct platform_device *) vdev->opaque;
+
+ return platform_get_irq(pdev, i);
+}
+
+static int vfio_platform_probe(struct platform_device *pdev)
+{
+ struct vfio_platform_device *vdev;
+ int ret;
+
+ vdev = kzalloc(sizeof(*vdev), GFP_KERNEL);
+ if (!vdev)
+ return -ENOMEM;
+
+ vdev->opaque = (void *) pdev;
+ vdev->name = pdev->name;
+ vdev->flags = VFIO_DEVICE_FLAGS_PLATFORM;
+ vdev->get_resource = get_platform_resource;
+ vdev->get_irq = get_platform_irq;
+
+ ret = vfio_platform_probe_common(vdev, &pdev->dev);
+ if (ret)
+ kfree(vdev);
+
+ return ret;
+}
+
+static int vfio_platform_remove(struct platform_device *pdev)
+{
+ struct vfio_platform_device *vdev;
+
+ vdev = vfio_platform_remove_common(&pdev->dev);
+ if (vdev) {
+ kfree(vdev);
+ return 0;
+ }
+
+ return -EINVAL;
+}
+
+static struct platform_driver vfio_platform_driver = {
+ .probe = vfio_platform_probe,
+ .remove = vfio_platform_remove,
+ .driver = {
+ .name = "vfio-platform",
+ .owner = THIS_MODULE,
+ },
+};
+
+module_platform_driver(vfio_platform_driver);
+
+MODULE_VERSION(DRIVER_VERSION);
+MODULE_LICENSE("GPL v2");
+MODULE_AUTHOR(DRIVER_AUTHOR);
+MODULE_DESCRIPTION(DRIVER_DESC);
diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
index 9ade02b..4e93a97 100644
--- a/include/uapi/linux/vfio.h
+++ b/include/uapi/linux/vfio.h
@@ -159,6 +159,7 @@ struct vfio_device_info {
__u32 flags;
#define VFIO_DEVICE_FLAGS_RESET (1 << 0) /* Device supports reset */
#define VFIO_DEVICE_FLAGS_PCI (1 << 1) /* vfio-pci device */
+#define VFIO_DEVICE_FLAGS_PLATFORM (1 << 2) /* vfio-platform device */
__u32 num_regions; /* Max region index + 1 */
__u32 num_irqs; /* Max IRQ index + 1 */
};
--
2.1.3
^ permalink raw reply related
* [REPORT PATCH] driver core: amba: add device binding path 'driver_override'
From: Antonios Motakis @ 2014-11-27 17:25 UTC (permalink / raw)
To: kvmarm-FPEHb7Xf0XXUo1n7N8X6UoWGPAHP3yOg,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
alex.williamson-H+wXaHxf7aLQT0dZR+AlfA,
linux-lFZ/pmaqli7XmaaqVzeoHQ
Cc: will.deacon-5wv7dgnIgG8, tech-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J,
christoffer.dall-QSEj5FYQhm4dnm+yROfE0A,
eric.auger-QSEj5FYQhm4dnm+yROfE0A,
kim.phillips-KZfg59tc24xl57MIdRCFDg, marc.zyngier-5wv7dgnIgG8,
Antonios Motakis, open list:ABI/API, open list
As already demonstrated with PCI [1] and the platform bus [2], a
driver_override property in sysfs can be used to bypass the id matching
of a device to a AMBA driver. This can be used by VFIO to bind to any AMBA
device requested by the user.
[1] http://lists-archives.com/linux-kernel/28030441-pci-introduce-new-device-binding-path-using-pci_dev-driver_override.html
[2] https://www.redhat.com/archives/libvir-list/2014-April/msg00382.html
Signed-off-by: Antonios Motakis <a.motakis-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J@public.gmane.org>
Reviewed-by: Kim Phillips <kim.phillips-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
---
Documentation/ABI/testing/sysfs-bus-amba | 20 ++++++++++++++
drivers/amba/bus.c | 47 ++++++++++++++++++++++++++++++++
include/linux/amba/bus.h | 1 +
3 files changed, 68 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-bus-amba
diff --git a/Documentation/ABI/testing/sysfs-bus-amba b/Documentation/ABI/testing/sysfs-bus-amba
new file mode 100644
index 0000000..e7b5467
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-amba
@@ -0,0 +1,20 @@
+What: /sys/bus/amba/devices/.../driver_override
+Date: September 2014
+Contact: Antonios Motakis <a.motakis-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J@public.gmane.org>
+Description:
+ This file allows the driver for a device to be specified which
+ will override standard OF, ACPI, ID table, and name matching.
+ When specified, only a driver with a name matching the value
+ written to driver_override will have an opportunity to bind to
+ the device. The override is specified by writing a string to the
+ driver_override file (echo vfio-amba > driver_override) and may
+ be cleared with an empty string (echo > driver_override).
+ This returns the device to standard matching rules binding.
+ Writing to driver_override does not automatically unbind the
+ device from its current driver or make any attempt to
+ automatically load the specified driver. If no driver with a
+ matching name is currently loaded in the kernel, the device will
+ not bind to any driver. This also allows devices to opt-out of
+ driver binding using a driver_override name such as "none".
+ Only a single driver may be specified in the override, there is
+ no support for parsing delimiters.
diff --git a/drivers/amba/bus.c b/drivers/amba/bus.c
index 47bbdc1..14bb08b 100644
--- a/drivers/amba/bus.c
+++ b/drivers/amba/bus.c
@@ -18,6 +18,7 @@
#include <linux/pm_domain.h>
#include <linux/amba/bus.h>
#include <linux/sizes.h>
+#include <linux/limits.h>
#include <asm/irq.h>
@@ -43,6 +44,10 @@ static int amba_match(struct device *dev, struct device_driver *drv)
struct amba_device *pcdev = to_amba_device(dev);
struct amba_driver *pcdrv = to_amba_driver(drv);
+ /* When driver_override is set, only bind to the matching driver */
+ if (pcdev->driver_override)
+ return !strcmp(pcdev->driver_override, drv->name);
+
return amba_lookup(pcdrv->id_table, pcdev) != NULL;
}
@@ -59,6 +64,47 @@ static int amba_uevent(struct device *dev, struct kobj_uevent_env *env)
return retval;
}
+static ssize_t driver_override_show(struct device *_dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct amba_device *dev = to_amba_device(_dev);
+
+ if (!dev->driver_override)
+ return 0;
+
+ return sprintf(buf, "%s\n", dev->driver_override);
+}
+
+static ssize_t driver_override_store(struct device *_dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct amba_device *dev = to_amba_device(_dev);
+ char *driver_override, *old = dev->driver_override, *cp;
+
+ if (count > PATH_MAX)
+ return -EINVAL;
+
+ driver_override = kstrndup(buf, count, GFP_KERNEL);
+ if (!driver_override)
+ return -ENOMEM;
+
+ cp = strchr(driver_override, '\n');
+ if (cp)
+ *cp = '\0';
+
+ if (strlen(driver_override)) {
+ dev->driver_override = driver_override;
+ } else {
+ kfree(driver_override);
+ dev->driver_override = NULL;
+ }
+
+ kfree(old);
+
+ return count;
+}
+
#define amba_attr_func(name,fmt,arg...) \
static ssize_t name##_show(struct device *_dev, \
struct device_attribute *attr, char *buf) \
@@ -81,6 +127,7 @@ amba_attr_func(resource, "\t%016llx\t%016llx\t%016lx\n",
static struct device_attribute amba_dev_attrs[] = {
__ATTR_RO(id),
__ATTR_RO(resource),
+ __ATTR_RW(driver_override),
__ATTR_NULL,
};
diff --git a/include/linux/amba/bus.h b/include/linux/amba/bus.h
index c324f57..34a7004 100644
--- a/include/linux/amba/bus.h
+++ b/include/linux/amba/bus.h
@@ -32,6 +32,7 @@ struct amba_device {
struct clk *pclk;
unsigned int periphid;
unsigned int irq[AMBA_NR_IRQS];
+ char *driver_override;
};
struct amba_driver {
--
2.1.3
^ permalink raw reply related
* [PATCH v3 3/6] vfio: introduce the VFIO_DMA_MAP_FLAG_NOEXEC flag
From: Antonios Motakis @ 2014-11-27 17:22 UTC (permalink / raw)
To: kvmarm-FPEHb7Xf0XXUo1n7N8X6UoWGPAHP3yOg,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
alex.williamson-H+wXaHxf7aLQT0dZR+AlfA
Cc: open list:VFIO DRIVER, eric.auger-QSEj5FYQhm4dnm+yROfE0A,
marc.zyngier-5wv7dgnIgG8, open list:ABI/API,
will.deacon-5wv7dgnIgG8, open list, Antonios Motakis,
tech-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J,
christoffer.dall-QSEj5FYQhm4dnm+yROfE0A
In-Reply-To: <1417108976-10113-1-git-send-email-a.motakis-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J@public.gmane.org>
We introduce the VFIO_DMA_MAP_FLAG_NOEXEC flag to the VFIO dma map call,
and expose its availability via the capability VFIO_DMA_NOEXEC_IOMMU.
This way the user can control whether the XN flag will be set on the
requested mappings. The IOMMU_NOEXEC flag needs to be available for all
the IOMMUs of the container used.
Signed-off-by: Antonios Motakis <a.motakis-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J@public.gmane.org>
---
include/uapi/linux/vfio.h | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
index 59d516f..9ade02b 100644
--- a/include/uapi/linux/vfio.h
+++ b/include/uapi/linux/vfio.h
@@ -31,6 +31,7 @@ enum vfio_iommu_cap {
(ex. PCIe NoSnoop stripping) */
VFIO_EEH = 5, /* Check if EEH is supported */
VFIO_TYPE1_NESTING_IOMMU = 6, /* Two-stage IOMMU, implies v2 */
+ VFIO_DMA_NOEXEC_IOMMU = 7,
};
@@ -396,12 +397,17 @@ struct vfio_iommu_type1_info {
*
* Map process virtual addresses to IO virtual addresses using the
* provided struct vfio_dma_map. Caller sets argsz. READ &/ WRITE required.
+ *
+ * To use the VFIO_DMA_MAP_FLAG_NOEXEC flag, the container must support the
+ * VFIO_DMA_NOEXEC_IOMMU capability. If mappings are created using this flag,
+ * any groups subsequently added to the container must support this capability.
*/
struct vfio_iommu_type1_dma_map {
__u32 argsz;
__u32 flags;
#define VFIO_DMA_MAP_FLAG_READ (1 << 0) /* readable from device */
#define VFIO_DMA_MAP_FLAG_WRITE (1 << 1) /* writable from device */
+#define VFIO_DMA_MAP_FLAG_NOEXEC (1 << 2) /* not executable from device */
__u64 vaddr; /* Process virtual address */
__u64 iova; /* IO virtual address */
__u64 size; /* Size of mapping (bytes) */
--
2.1.3
^ permalink raw reply related
* [PATCH v3 1/6] vfio: implement iommu driver capabilities with an enum
From: Antonios Motakis @ 2014-11-27 17:22 UTC (permalink / raw)
To: kvmarm-FPEHb7Xf0XXUo1n7N8X6UoWGPAHP3yOg,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
alex.williamson-H+wXaHxf7aLQT0dZR+AlfA
Cc: open list:VFIO DRIVER, eric.auger-QSEj5FYQhm4dnm+yROfE0A,
marc.zyngier-5wv7dgnIgG8, open list:ABI/API,
will.deacon-5wv7dgnIgG8, open list, Antonios Motakis,
tech-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J,
christoffer.dall-QSEj5FYQhm4dnm+yROfE0A
In-Reply-To: <1417108976-10113-1-git-send-email-a.motakis-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J@public.gmane.org>
Currently a VFIO driver's IOMMU capabilities are encoded as a series of
numerical defines. Replace this with an enum for future maintainability.
Signed-off-by: Antonios Motakis <a.motakis-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J@public.gmane.org>
---
include/uapi/linux/vfio.h | 24 +++++++++++-------------
1 file changed, 11 insertions(+), 13 deletions(-)
diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
index 29715d2..59d516f 100644
--- a/include/uapi/linux/vfio.h
+++ b/include/uapi/linux/vfio.h
@@ -19,22 +19,20 @@
/* Kernel & User level defines for VFIO IOCTLs. */
-/* Extensions */
-
-#define VFIO_TYPE1_IOMMU 1
-#define VFIO_SPAPR_TCE_IOMMU 2
-#define VFIO_TYPE1v2_IOMMU 3
/*
- * IOMMU enforces DMA cache coherence (ex. PCIe NoSnoop stripping). This
- * capability is subject to change as groups are added or removed.
+ * Capabilities exposed by the VFIO IOMMU driver. Some capabilities are subject
+ * to change as groups are added or removed.
*/
-#define VFIO_DMA_CC_IOMMU 4
-
-/* Check if EEH is supported */
-#define VFIO_EEH 5
+enum vfio_iommu_cap {
+ VFIO_TYPE1_IOMMU = 1,
+ VFIO_SPAPR_TCE_IOMMU = 2,
+ VFIO_TYPE1v2_IOMMU = 3,
+ VFIO_DMA_CC_IOMMU = 4, /* IOMMU enforces DMA cache coherence
+ (ex. PCIe NoSnoop stripping) */
+ VFIO_EEH = 5, /* Check if EEH is supported */
+ VFIO_TYPE1_NESTING_IOMMU = 6, /* Two-stage IOMMU, implies v2 */
+};
-/* Two-stage IOMMU */
-#define VFIO_TYPE1_NESTING_IOMMU 6 /* Implies v2 */
/*
* The IOCTL interface is designed for extensibility by embedding the
--
2.1.3
^ permalink raw reply related
* [CFT][PATCH] userns: Avoid problems with negative groups
From: Eric W. Biederman @ 2014-11-27 16:59 UTC (permalink / raw)
To: Linux Containers
Cc: linux-man, Kees Cook, Linux API, Josh Triplett, Andy Lutomirski,
LSM, Michael Kerrisk-manpages, Richard Weinberger,
Casey Schaufler, Andrew Morton,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <546A43CE.2030706-iSGtlc1asvQWG2LlvL+J4A@public.gmane.org>
Classic unix permission checks have an interesting feature. The group
permissions for a file can be set to less than the other permissions
on a file. Occassionally this is used deliberately to give a certain
group of users fewer permissions than the default.
Overlooking negative groups has resulted in the permission checks for
setting up a group mapping in a user namespace to be too lax. Tighten
the permission checks in new_idmap_permitted to ensure that mapping
uids and gids into user namespaces without privilege will not result
in new combinations of credentials being available to the users.
When setting mappings without privilege only the creator of the user
namespace is interesting as all other users that have CAP_SETUID over
the user namespace will also have CAP_SETUID over the user namespaces
parent. So the scope of the unprivileged check is reduced to just
the case where cred->euid is the namespace creator.
For setting a uid mapping without privilege only euid is considered as
setresuid can set uid, suid and fsuid from euid without privielege
making any combination of uids possible with user namespaces already
possible without them.
For setting a gid mapping without privilege only egid on a credential
without supplementary groups is condsidered, as setresgid can set gid,
sgid and fsgid from egid without privilege. The requirement for no
supplementary groups is because CAP_SETUID in a user namespace allows
supplementary groups to be cleared, which unfortunately means allowing
a credential with supplementary groups would allow new combinations
of credentials to exist, and thus would allow defeating negative
groups without permission.
This change should break userspace by the minimal amount needed
to fix this issue.
This should fix CVE-2014-8989.
Cc: stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Signed-off-by: "Eric W. Biederman" <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
---
If people can test and review this change and verify this and verify it
doesn't break anything I can't help breaking I will appreciate it.
kernel/user_namespace.c | 16 ++++++++++++----
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/kernel/user_namespace.c b/kernel/user_namespace.c
index aa312b0dc3ec..b338c42d04fd 100644
--- a/kernel/user_namespace.c
+++ b/kernel/user_namespace.c
@@ -812,16 +812,24 @@ static bool new_idmap_permitted(const struct file *file,
struct user_namespace *ns, int cap_setid,
struct uid_gid_map *new_map)
{
- /* Allow mapping to your own filesystem ids */
- if ((new_map->nr_extents == 1) && (new_map->extent[0].count == 1)) {
+ const struct cred *cred = file->f_cred;
+
+ /* Allow mapping an id without CAP_SETUID and CAP_SETGID when
+ * allowing the root of the user namespace CAP_SETUID or
+ * CAP_SETGID restricted to just that id will not change the
+ * set of credentials available that user.
+ */
+ if ((new_map->nr_extents == 1) && (new_map->extent[0].count == 1) &&
+ uid_eq(ns->owner, cred->euid)) {
u32 id = new_map->extent[0].lower_first;
if (cap_setid == CAP_SETUID) {
kuid_t uid = make_kuid(ns->parent, id);
- if (uid_eq(uid, file->f_cred->fsuid))
+ if (uid_eq(uid, cred->euid))
return true;
} else if (cap_setid == CAP_SETGID) {
kgid_t gid = make_kgid(ns->parent, id);
- if (gid_eq(gid, file->f_cred->fsgid))
+ if (gid_eq(gid, cred->egid) &&
+ (cred->group_info->ngroups == 0))
return true;
}
}
--
1.9.1
^ permalink raw reply related
* Re: [RFC] lsm: namespace hooks
From: Eric W. Biederman @ 2014-11-27 16:44 UTC (permalink / raw)
To: Lukasz Pawelczyk
Cc: Vladimir Davydov, Miklos Szeredi, Lukasz Pawelczyk, LKML,
David Howells, Mark Rustad, Matthew Dempsky, Richard Weinberger,
Daeseok Youn, Ingo Molnar, Jeff Kirsher, David Rientjes,
Alex Thorlton, Juri Lelli, Kees Cook, Nikolay Aleksandrov,
Dario Faggioli, Al Viro, James Morris, open lis t:ABI/API,
Linux Containers, Oleg Nesterov, Paul Moore
In-Reply-To: <1417104439.1805.25.camel-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
Lukasz Pawelczyk <l.pawelczyk-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org> writes:
> On czw, 2014-11-27 at 09:42 -0600, Eric W. Biederman wrote:
>> Lukasz Pawelczyk <l.pawelczyk-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org> writes:
>>
>> > On czw, 2014-11-27 at 16:01 +0100, Richard Weinberger wrote:
>> >> Am 27.11.2014 um 15:44 schrieb Lukasz Pawelczyk:
>> >> > True, the last one is 0x80000000. I did not notice that. Thanks for
>> >> > pointing out.
>> >>
>> >> Isn't this CLONE_IO?
>> >
>> > Yes, I was merely noticing out loud that it's the last bit of 32bit.
>> >
>> > After close look though the 0x00001000 appears to be unused
>> >
>> >> > Any suggestion on what can be done here? New syscal with flags2?
>> >>
>> >> I'm not sure. But a new syscall would be a candidate.
>>
>> We are probably going to need to go a couple rounds with this but at
>> first approximation I think this functionality needs to be tied to the
>> user namespace. This functionality already looks half tied to it.
>>
>> When mounting filesystems with user namespaces priveleges matures a
>> little more you should be able to use unmapped labels. In the near term
>> we are looking at filesystems such as tmpfs, fuse and posibly extN.
>
> I presume you are referring to the Smack namespace readme where I
> mentioned mounts with specifying smack labels in the mount options, not
> to the quote above?
>
> I was referring the to the check here that has been changed to
> smack_ns_privileged() using ns_capable():
> http://lxr.free-electrons.com/source/security/smack/smack_lsm.c#L462
>
> And you can't use an unmapped Smack label inside the namespace, this
> would be completely against its idea.
>
> Anyway, at this point I'm more interested in the LSM namespace. I'll be
> doing an RFC for Smack namespace later.
>
> Unless I misunderstood your mail.
I had two points.
a) Tie the label mapping to the user namespace, then we don't need any
new namespaces.
Is there a reason not to tie the label mapping to the user namespace?
Needing to modify every userspace that create containers to know
about every different lsm looks like a maintenance difficulty I would
prefer to avoid.
b) For filesystems that don't need uid mapping (say ext2 mounted with
user namespace permissions) we shouldn't need LSM mapping either.
Eric
^ permalink raw reply
* Re: [RFC] lsm: namespace hooks
From: Lukasz Pawelczyk @ 2014-11-27 16:07 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Vladimir Davydov, Miklos Szeredi, Lukasz Pawelczyk, LKML,
David Howells, Mark Rustad, Matthew Dempsky, Richard Weinberger,
Daeseok Youn, Ingo Molnar, Jeff Kirsher, David Rientjes,
Alex Thorlton, Juri Lelli, Kees Cook, Nikolay Aleksandrov,
Dario Faggioli, Al Viro, James Morris, open list:ABI/API,
Linux Containers, Oleg Nesterov, Paul Moore
In-Reply-To: <87d288zm3a.fsf-JOvCrm2gF+uungPnsOpG7nhyD016LWXt@public.gmane.org>
On czw, 2014-11-27 at 09:42 -0600, Eric W. Biederman wrote:
> Lukasz Pawelczyk <l.pawelczyk-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org> writes:
>
> > On czw, 2014-11-27 at 16:01 +0100, Richard Weinberger wrote:
> >> Am 27.11.2014 um 15:44 schrieb Lukasz Pawelczyk:
> >> > True, the last one is 0x80000000. I did not notice that. Thanks for
> >> > pointing out.
> >>
> >> Isn't this CLONE_IO?
> >
> > Yes, I was merely noticing out loud that it's the last bit of 32bit.
> >
> > After close look though the 0x00001000 appears to be unused
> >
> >> > Any suggestion on what can be done here? New syscal with flags2?
> >>
> >> I'm not sure. But a new syscall would be a candidate.
>
> We are probably going to need to go a couple rounds with this but at
> first approximation I think this functionality needs to be tied to the
> user namespace. This functionality already looks half tied to it.
>
> When mounting filesystems with user namespaces priveleges matures a
> little more you should be able to use unmapped labels. In the near term
> we are looking at filesystems such as tmpfs, fuse and posibly extN.
I presume you are referring to the Smack namespace readme where I
mentioned mounts with specifying smack labels in the mount options, not
to the quote above?
I was referring the to the check here that has been changed to
smack_ns_privileged() using ns_capable():
http://lxr.free-electrons.com/source/security/smack/smack_lsm.c#L462
And you can't use an unmapped Smack label inside the namespace, this
would be completely against its idea.
Anyway, at this point I'm more interested in the LSM namespace. I'll be
doing an RFC for Smack namespace later.
Unless I misunderstood your mail.
--
Lukasz Pawelczyk
Samsung R&D Institute Poland
Samsung Electronics
^ permalink raw reply
* Re: [PATCH v17 7/7] mm: Don't split THP page when syscall is called
From: Michal Hocko @ 2014-11-27 15:49 UTC (permalink / raw)
To: Minchan Kim
Cc: Andrew Morton, linux-kernel, linux-mm, Michael Kerrisk, linux-api,
Hugh Dickins, Johannes Weiner, Rik van Riel, KOSAKI Motohiro,
Mel Gorman, Jason Evans, zhangyanfei, Kirill A. Shutemov,
Andrea Arcangeli, Kirill A. Shutemov
In-Reply-To: <1413799924-17946-8-git-send-email-minchan@kernel.org>
On Mon 20-10-14 19:12:04, Minchan Kim wrote:
> We don't need to split THP page when MADV_FREE syscall is
> called. It could be done when VM decide really frees it so
> we could avoid unnecessary THP split.
>
> Cc: Andrea Arcangeli <aarcange@redhat.com>
> Acked-by: Rik van Riel <riel@redhat.com>
> Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
> Signed-off-by: Minchan Kim <minchan@kernel.org>
Other than a minor comment below
Reviewed-by: Michal Hocko <mhocko@suse.cz>
> ---
> include/linux/huge_mm.h | 4 ++++
> mm/huge_memory.c | 35 +++++++++++++++++++++++++++++++++++
> mm/madvise.c | 21 ++++++++++++++++++++-
> mm/rmap.c | 8 ++++++--
> mm/vmscan.c | 28 ++++++++++++++++++----------
> 5 files changed, 83 insertions(+), 13 deletions(-)
>
[...]
> diff --git a/mm/madvise.c b/mm/madvise.c
> index a21584235bb6..84badee5f46d 100644
> --- a/mm/madvise.c
> +++ b/mm/madvise.c
> @@ -271,8 +271,26 @@ static int madvise_free_pte_range(pmd_t *pmd, unsigned long addr,
> spinlock_t *ptl;
> pte_t *pte, ptent;
> struct page *page;
> + unsigned long next;
> +
> + next = pmd_addr_end(addr, end);
> + if (pmd_trans_huge(*pmd)) {
> + if (next - addr != HPAGE_PMD_SIZE) {
> +#ifdef CONFIG_DEBUG_VM
> + if (!rwsem_is_locked(&mm->mmap_sem)) {
> + pr_err("%s: mmap_sem is unlocked! addr=0x%lx end=0x%lx vma->vm_start=0x%lx vma->vm_end=0x%lx\n",
> + __func__, addr, end,
> + vma->vm_start,
> + vma->vm_end);
> + BUG();
> + }
> +#endif
Why is this code here? madvise_free_pte_range is called only from the
madvise path and we are holding mmap_sem and relying on that for regular
pages as well.
> + split_huge_page_pmd(vma, addr, pmd);
> + } else if (!madvise_free_huge_pmd(tlb, vma, pmd, addr))
> + goto next;
> + /* fall through */
> + }
>
> - split_huge_page_pmd(vma, addr, pmd);
> if (pmd_trans_unstable(pmd))
> return 0;
>
> @@ -316,6 +334,7 @@ static int madvise_free_pte_range(pmd_t *pmd, unsigned long addr,
> }
> arch_leave_lazy_mmu_mode();
> pte_unmap_unlock(pte - 1, ptl);
> +next:
> cond_resched();
> return 0;
> }
[...]
--
Michal Hocko
SUSE Labs
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [RFC] lsm: namespace hooks
From: Eric W. Biederman @ 2014-11-27 15:42 UTC (permalink / raw)
To: Lukasz Pawelczyk
Cc: Vladimir Davydov, Miklos Szeredi, Lukasz Pawelczyk, LKML,
David Howells, Mark Rustad, Matthew Dempsky, Richard Weinberger,
Daeseok Youn, Ingo Molnar, Jeff Kirsher, David Rientjes,
Alex Thorlton, Juri Lelli, Kees Cook, Nikolay Aleksandrov,
Dario Faggioli, Al Viro, James Morris, open lis t:ABI/API,
Linux Containers, Oleg Nesterov, Paul Moore
In-Reply-To: <1417101060.1805.21.camel-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
Lukasz Pawelczyk <l.pawelczyk-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org> writes:
> On czw, 2014-11-27 at 16:01 +0100, Richard Weinberger wrote:
>> Am 27.11.2014 um 15:44 schrieb Lukasz Pawelczyk:
>> > True, the last one is 0x80000000. I did not notice that. Thanks for
>> > pointing out.
>>
>> Isn't this CLONE_IO?
>
> Yes, I was merely noticing out loud that it's the last bit of 32bit.
>
> After close look though the 0x00001000 appears to be unused
>
>> > Any suggestion on what can be done here? New syscal with flags2?
>>
>> I'm not sure. But a new syscall would be a candidate.
We are probably going to need to go a couple rounds with this but at
first approximation I think this functionality needs to be tied to the
user namespace. This functionality already looks half tied to it.
When mounting filesystems with user namespaces priveleges matures a
little more you should be able to use unmapped labels. In the near term
we are looking at filesystems such as tmpfs, fuse and posibly extN.
Eric
^ permalink raw reply
* Re: [tpmdd-devel] [PATCH v7 08/10] tpm: TPM 2.0 CRB Interface
From: Jarkko Sakkinen @ 2014-11-27 15:40 UTC (permalink / raw)
To: Stefan Berger
Cc: Peter Huewe, Ashley Lai, Marcel Selhorst,
christophe.ricard-Re5JQEeQqe8AvxtiuMwx3w,
josh.triplett-ral2JQCrhuEAvxtiuMwx3w,
linux-api-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
jason.gunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/,
trousers-tech-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <5475DE81.50308-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
On Wed, Nov 26, 2014 at 09:06:57AM -0500, Stefan Berger wrote:
> On 11/11/2014 08:45 AM, Jarkko Sakkinen wrote:
> >tpm_crb is a driver for TPM 2.0 Command Response Buffer (CRB) Interface
> >as defined in PC Client Platform TPM Profile (PTP) Specification.
> >
> >Only polling and single locality is supported as these are the limitations
> >of the available hardware, Platform Trust Techonlogy (PTT) in Haswell
> >CPUs.
> >
> >The driver always applies CRB with ACPI start because PTT reports using
> >only ACPI start as start method but as a result of my testing it requires
> >also CRB start.
> >
> >Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
> >---
> > drivers/char/tpm/Kconfig | 9 ++
> > drivers/char/tpm/Makefile | 1 +
> > drivers/char/tpm/tpm_crb.c | 323 +++++++++++++++++++++++++++++++++++++++++++++
> > 3 files changed, 333 insertions(+)
> > create mode 100644 drivers/char/tpm/tpm_crb.c
> >
> >diff --git a/drivers/char/tpm/Kconfig b/drivers/char/tpm/Kconfig
> >index c54cac3..10c9419 100644
> >--- a/drivers/char/tpm/Kconfig
> >+++ b/drivers/char/tpm/Kconfig
> >@@ -122,4 +122,13 @@ config TCG_XEN
> > To compile this driver as a module, choose M here; the module
> > will be called xen-tpmfront.
> >
> >+config TCG_CRB
> >+ tristate "TPM 2.0 CRB Interface"
> >+ depends on X86 && ACPI
> >+ ---help---
> >+ If you have a TPM security chip that is compliant with the
> >+ TCG CRB 2.0 TPM specification say Yes and it will be accessible
> >+ from within Linux. To compile this driver as a module, choose
> >+ M here; the module will be called tpm_crb.
> >+
> > endif # TCG_TPM
> >diff --git a/drivers/char/tpm/Makefile b/drivers/char/tpm/Makefile
> >index ae56af9..e6d26dd 100644
> >--- a/drivers/char/tpm/Makefile
> >+++ b/drivers/char/tpm/Makefile
> >@@ -22,3 +22,4 @@ obj-$(CONFIG_TCG_INFINEON) += tpm_infineon.o
> > obj-$(CONFIG_TCG_IBMVTPM) += tpm_ibmvtpm.o
> > obj-$(CONFIG_TCG_ST33_I2C) += tpm_i2c_stm_st33.o
> > obj-$(CONFIG_TCG_XEN) += xen-tpmfront.o
> >+obj-$(CONFIG_TCG_CRB) += tpm_crb.o
> >diff --git a/drivers/char/tpm/tpm_crb.c b/drivers/char/tpm/tpm_crb.c
> >new file mode 100644
> >index 0000000..eb221d5
> >--- /dev/null
> >+++ b/drivers/char/tpm/tpm_crb.c
> >@@ -0,0 +1,323 @@
> >+/*
> >+ * Copyright (C) 2014 Intel Corporation
> >+ *
> >+ * Authors:
> >+ * Jarkko Sakkinen <jarkko.sakkinen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
> >+ *
> >+ * Maintained by: <tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>
> >+ *
> >+ * This device driver implements the TPM interface as defined in
> >+ * the TCG CRB 2.0 TPM specification.
> >+ *
> >+ * This program is free software; you can redistribute it and/or
> >+ * modify it under the terms of the GNU General Public License
> >+ * as published by the Free Software Foundation; version 2
> >+ * of the License.
> >+ */
> >+
> >+#include <linux/acpi.h>
> >+#include <linux/highmem.h>
> >+#include <linux/rculist.h>
> >+#include <linux/module.h>
> >+#include <linux/platform_device.h>
> >+#include "tpm.h"
> >+
> >+#define ACPI_SIG_TPM2 "TPM2"
> >+
> >+static const u8 CRB_ACPI_START_UUID[] = {
> >+ /* 0000 */ 0xAB, 0x6C, 0xBF, 0x6B, 0x63, 0x54, 0x14, 0x47,
> >+ /* 0008 */ 0xB7, 0xCD, 0xF0, 0x20, 0x3C, 0x03, 0x68, 0xD4
> >+};
> >+
> >+enum crb_defaults {
> >+ CRB_ACPI_START_REVISION_ID = 1,
> >+ CRB_ACPI_START_INDEX = 1,
> >+};
> >+
> >+enum crb_start_method {
> >+ CRB_SM_ACPI_START = 2,
> >+ CRB_SM_CRB = 7,
> >+ CRB_SM_CRB_WITH_ACPI_START = 8,
> >+};
> >+
> >+struct acpi_tpm2 {
> >+ struct acpi_table_header hdr;
> >+ u16 platform_class;
> >+ u16 reserved;
> >+ u64 control_area_pa;
> >+ u32 start_method;
> >+};
> >+
> >+enum crb_ca_request {
> >+ CRB_CA_REQ_GO_IDLE = BIT(0),
> >+ CRB_CA_REQ_CMD_READY = BIT(1),
> >+};
> >+
> >+enum crb_ca_status {
> >+ CRB_CA_STS_ERROR = BIT(0),
> >+ CRB_CA_STS_TPM_IDLE = BIT(1),
> >+};
> >+
> >+struct crb_control_area {
> >+ u32 req;
> >+ u32 sts;
> >+ u32 cancel;
> >+ u32 start;
> >+ u32 int_enable;
> >+ u32 int_sts;
> >+ u32 cmd_size;
> >+ u64 cmd_pa;
> >+ u32 rsp_size;
> >+ u64 rsp_pa;
> >+} __packed;
> >+
> >+enum crb_status {
> >+ CRB_STS_COMPLETE = BIT(0),
> >+};
> >+
> >+enum crb_flags {
> >+ CRB_FL_ACPI_START = BIT(0),
> >+ CRB_FL_CRB_START = BIT(1),
> >+};
> >+
> >+struct crb_priv {
> >+ unsigned int flags;
> >+ struct crb_control_area *cca;
> >+ unsigned long cca_pa;
> >+};
> >+
> >+#ifdef CONFIG_PM_SLEEP
> >+int crb_suspend(struct device *dev)
> >+{
> >+ return 0;
> >+}
> >+
> >+static int crb_resume(struct device *dev)
> >+{
> >+ struct tpm_chip *chip = dev_get_drvdata(dev);
> >+
> >+ (void) tpm2_do_selftest(chip);
> >+
> >+ return 0;
> >+}
> >+#endif
> >+
> >+static SIMPLE_DEV_PM_OPS(crb_pm, crb_suspend, crb_resume);
> >+
> >+static u8 crb_status(struct tpm_chip *chip)
> >+{
> >+ struct crb_priv *priv = chip->vendor.priv;
> >+ u8 sts = 0;
> >+
> >+ if ((le32_to_cpu(priv->cca->start) & 1) != 1)
>
> Use a #define rather than the magic '1'.
>
>
> >+ sts |= CRB_STS_COMPLETE;
> >+
> >+ return sts;
> >+}
> >+
> >+static int crb_recv(struct tpm_chip *chip, u8 *buf, size_t count)
> >+{
> >+ struct crb_priv *priv = chip->vendor.priv;
> >+ struct crb_control_area *cca;
> >+ unsigned int expected;
> >+ unsigned long offset;
> >+ u8 *resp;
> >+
> >+ cca = priv->cca;
> >+ if (le32_to_cpu(cca->sts) & CRB_CA_STS_ERROR)
> >+ return -EIO;
> >+
> >+ offset = le64_to_cpu(cca->rsp_pa) - priv->cca_pa;
> >+ resp = (u8 *) ((unsigned long) cca + offset);
>
> make sure that count >= 6?
>
> >+ memcpy(buf, resp, 6);
> >+ expected = be32_to_cpup((__be32 *) &buf[2]);
> >+
> >+ if (expected > count)
> >+ return -EIO;
> >+
> >+ memcpy(&buf[6], &resp[6], expected - 6);
> >+
> >+ return expected;
> >+}
> >+
> >+static int crb_do_acpi_start(struct tpm_chip *chip)
> >+{
> >+ union acpi_object *obj;
> >+ int rc;
> >+
> >+ obj = acpi_evaluate_dsm(chip->acpi_dev_handle,
> >+ CRB_ACPI_START_UUID,
> >+ CRB_ACPI_START_REVISION_ID,
> >+ CRB_ACPI_START_INDEX,
> >+ NULL);
> >+ if (!obj)
> >+ return -ENXIO;
> >+ rc = obj->integer.value == 0 ? 0 : -ENXIO;
> >+ ACPI_FREE(obj);
> >+ return rc;
> >+}
> >+
> >+static int crb_send(struct tpm_chip *chip, u8 *buf, size_t len)
> >+{
> >+ struct crb_priv *priv = chip->vendor.priv;
> >+ struct crb_control_area *cca;
> >+ u8 *cmd;
> >+ int rc = 0;
> >+
> >+ cca = priv->cca;
> >+
> >+ if (len > le32_to_cpu(cca->cmd_size)) {
> >+ dev_err(&chip->dev,
> >+ "invalid command count value %x %zx\n",
> >+ (unsigned int) len,
> >+ (size_t) le32_to_cpu(cca->cmd_size));
> >+ return -E2BIG;
> >+ }
> >+
> >+ cmd = (u8 *) ((unsigned long) cca + le64_to_cpu(cca->cmd_pa) -
> >+ priv->cca_pa);
>
> cca = priv->cca per statement above -> cmd = cca + x - cca = x
>
> -> cmd = le64_to_cpu(cca->cmd_pa);
>
> Should do the trick, no ?
Virtual address might be different where CCA is ioremapped.
> >+ memcpy(cmd, buf, len);
> >+
> >+ /* Make sure that cmd is populated before issuing start. */
> >+ wmb();
> >+
> >+ cca->start = cpu_to_le32(1);
> >+ rc = crb_do_acpi_start(chip);
>
> I had commented on this already. Your TPM seems to no implement the ACPI
> specs properly, or rather the ACPI table is wrong.
> You have to check whether the ACPI function needs to be called. The next TPM
> from a different vendor for whom the ACPI start function is not necessary
> will need this check here since it will give a return code indicating
> failure. Then your TPM won't work anymore! I think you should add a check
> into the crb_do_acpi_start for whether this function needs to be called or
> whether your TPM is being used (vendor check?) and run this start function
> then anyway.
Yes, now that you said I remember you commenting this before.
I'll see what I can do and consider this together with the good remarks
that are below.
> >+ return rc;
> >+}
> >+
> >+static void crb_cancel(struct tpm_chip *chip)
> >+{
> >+ struct crb_priv *priv = chip->vendor.priv;
> >+ struct crb_control_area *cca;
> >+
> >+ cca = priv->cca;
> >+ cca->cancel = cpu_to_le32(1);
>
> nit: #define for this ?
>
> >+
> >+ /* Make sure that cmd is populated before issuing start. */
> >+ wmb();
> >+
> >+ if (crb_do_acpi_start(chip))
> >+ dev_err(&chip->dev, "ACPI Start failed\n");
> >+
> >+ cca->cancel = 0;
> >+}
> >+
> >+static bool crb_req_canceled(struct tpm_chip *chip, u8 status)
> >+{
> >+ struct crb_priv *priv = chip->vendor.priv;
> >+
> >+ return (le32_to_cpu(priv->cca->cancel) & 1) == 1;
> >+}
> >+
> >+static const struct tpm_class_ops tpm_crb = {
> >+ .status = crb_status,
> >+ .recv = crb_recv,
> >+ .send = crb_send,
> >+ .cancel = crb_cancel,
> >+ .req_canceled = crb_req_canceled,
> >+ .req_complete_mask = CRB_STS_COMPLETE,
> >+ .req_complete_val = CRB_STS_COMPLETE,
> >+};
> >+
> >+static int crb_acpi_add(struct acpi_device *device)
> >+{
> >+ struct tpm_chip *chip;
> >+ struct acpi_tpm2 *buf;
> >+ struct crb_priv *priv;
> >+ struct device *dev = &device->dev;
> >+ acpi_status status;
> >+ u32 sm;
> >+ int rc;
> >+
> >+ chip = tpmm_chip_alloc(dev, &tpm_crb);
> >+ if (IS_ERR(chip))
> >+ return PTR_ERR(chip);
> >+
> >+ chip->flags = TPM_CHIP_FLAG_TPM2;
> >+
> >+ status = acpi_get_table(ACPI_SIG_TPM2, 1,
> >+ (struct acpi_table_header **) &buf);
> >+ if (ACPI_FAILURE(status)) {
> >+ dev_err(dev, "failed to get TPM2 ACPI table\n");
> >+ return -ENODEV;
> >+ }
> >+
> >+ priv = (struct crb_priv *) devm_kzalloc(dev, sizeof(struct crb_priv),
> >+ GFP_KERNEL);
> >+ if (!priv) {
> >+ dev_err(dev, "failed to devm_kzalloc for private data\n");
> >+ return -ENOMEM;
> >+ }
> >+
> >+ sm = le32_to_cpu(buf->start_method);
>
> I wonder whether you should check whether that ACPI table is big enough to
> allow you accessing its start_method.
>
> if (buf->length < sizeof(struct acpi_tpm2) ) {
> return -EXYZ;
> }
>
> >+
> >+ if (sm == CRB_SM_CRB || sm == CRB_SM_CRB_WITH_ACPI_START)
> >+ priv->flags |= CRB_FL_CRB_START;
>
> You set this flag but you don't seem to check it anywhere.
>
> >+
> >+ if (sm == CRB_SM_ACPI_START || sm == CRB_SM_CRB_WITH_ACPI_START)
> >+ priv->flags |= CRB_FL_ACPI_START;
>
>
> You set this flag but you don't seem to check it anywhere.
>
>
> >+
> >+ priv->cca_pa = le32_to_cpu(buf->control_area_pa);
> >+ priv->cca = (struct crb_control_area *)
> >+ devm_ioremap_nocache(dev, buf->control_area_pa, 0x1000);
> >+ if (!priv->cca) {
> >+ dev_err(dev, "allocating memory failed\n");
> >+ return -ENOMEM;
> >+ }
> >+
> >+ chip->vendor.priv = priv;
> >+
> >+ /* Default timeouts and durations */
> >+ chip->vendor.timeout_a = usecs_to_jiffies(TPM2_TIMEOUT_A);
> >+ chip->vendor.timeout_b = usecs_to_jiffies(TPM2_TIMEOUT_B);
> >+ chip->vendor.timeout_c = usecs_to_jiffies(TPM2_TIMEOUT_C);
> >+ chip->vendor.timeout_d = usecs_to_jiffies(TPM2_TIMEOUT_D);
> >+ chip->vendor.duration[TPM_SHORT] =
> >+ usecs_to_jiffies(TPM2_DURATION_SHORT);
> >+ chip->vendor.duration[TPM_MEDIUM] =
> >+ usecs_to_jiffies(TPM2_DURATION_MEDIUM);
> >+ chip->vendor.duration[TPM_LONG] =
> >+ usecs_to_jiffies(TPM2_DURATION_LONG);
> >+
> >+ chip->acpi_dev_handle = device->handle;
> >+
> >+ rc = tpm2_do_selftest(chip);
> >+ if (rc)
> >+ return rc;
> >+
> >+ return tpm_chip_register(chip);
> >+}
> >+
> >+int crb_acpi_remove(struct acpi_device *device)
> >+{
> >+ struct device *dev = &device->dev;
> >+ struct tpm_chip *chip = dev_get_drvdata(dev);
> >+
> >+ tpm_chip_unregister(chip);
> >+ return 0;
> >+}
> >+
> >+static struct acpi_device_id crb_device_ids[] = {
> >+ {"MSFT0101", 0},
> >+ {"", 0},
> >+};
> >+MODULE_DEVICE_TABLE(acpi, crb_device_ids);
> >+
> >+static struct acpi_driver crb_acpi_driver = {
> >+ .name = "tpm_crb",
> >+ .ids = crb_device_ids,
> >+ .ops = {
> >+ .add = crb_acpi_add,
> >+ .remove = crb_acpi_remove,
> >+ },
> >+ .drv = {
> >+ .pm = &crb_pm,
> >+ },
> >+};
> >+
> >+module_acpi_driver(crb_acpi_driver);
> >+MODULE_AUTHOR("Jarkko Sakkinen <jarkko.sakkinen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>");
> >+MODULE_DESCRIPTION("TPM2 Driver");
> >+MODULE_VERSION("0.1");
> >+MODULE_LICENSE("GPL");
>
> Regards,
> Stefan
/Jarkko
^ permalink raw reply
* Re: [PATCH v3 5/5] tty/serial: Add Spreadtrum sc9836-uart driver support
From: Arnd Bergmann @ 2014-11-27 15:36 UTC (permalink / raw)
To: Lyra Zhang
Cc: Murali Karicheri, Chunyan Zhang, Grant Likely, robh+dt@kernel.org,
Catalin Marinas, gregkh@linuxfoundation.org,
ijc+devicetree@hellion.org.uk, jslaby@suse.cz, Kumar Gala,
Mark Rutland, Pawel Moll, Ramkumar Ramachandra,
rrichter@cavium.com, Will Deacon, gnomes@lxorguk.ukuu.org.uk,
Jonathan Corbet, jason@lakedaemon.net, Mark Brown,
Heiko Stübner, florian.vaussard@epfl.ch
In-Reply-To: <CAAfSe-uWvn4MX-+GKuvvd=G2MTfLDCFeLRoUGWp7vvc81wfu0w@mail.gmail.com>
On Thursday 27 November 2014 23:23:17 Lyra Zhang wrote:
>
> Yes, I saw this way in other serial drivers.
> But, if then, there are two questions for me:
> 1. Why did some serial drivers need an UN_SHARED irq?
A lot of drivers were written before we had shared IRQs, or
were copied from old drivers, or are for hardware that uses
edge-triggered interrupts instead of level-triggered interrupts.
Only level-triggered interrupts can be shared.
> 2. How can we choose a right way?
It never hurts to implement a shared interrupt handler. Only
if you have no way to find out whether the device triggered
the interrupt or not you have to leave out IRQF_SHARED, and then
you won't be able to return IRQ_NONE.
Arnd
^ permalink raw reply
* Re: [PATCH v3 5/5] tty/serial: Add Spreadtrum sc9836-uart driver support
From: One Thousand Gnomes @ 2014-11-27 15:34 UTC (permalink / raw)
To: Lyra Zhang
Cc: Arnd Bergmann, Murali Karicheri, Chunyan Zhang, Grant Likely,
robh+dt@kernel.org, Catalin Marinas, gregkh@linuxfoundation.org,
ijc+devicetree@hellion.org.uk, jslaby@suse.cz, Kumar Gala,
Mark Rutland, Pawel Moll, Ramkumar Ramachandra,
rrichter@cavium.com, Will Deacon, Jonathan Corbet,
jason@lakedaemon.net, Mark Brown, Heiko Stübner,
florian.vaussard@epfl.ch, andrew@lunn.ch
In-Reply-To: <CAAfSe-uWvn4MX-+GKuvvd=G2MTfLDCFeLRoUGWp7vvc81wfu0w@mail.gmail.com>
> Yes, I saw this way in other serial drivers.
> But, if then, there are two questions for me:
> 1. Why did some serial drivers need an UN_SHARED irq?
> 2. How can we choose a right way?
If your hardware can support sharing an IRQ then shared is the right way
- along with the test Arnd suggested. Some hardware lacks the needed
facilities to handle shared interrupt.
Alan
^ permalink raw reply
* Re: [RFC] lsm: namespace hooks
From: Lukasz Pawelczyk @ 2014-11-27 15:24 UTC (permalink / raw)
To: Richard Weinberger
Cc: Vladimir Davydov, Miklos Szeredi, Lukasz Pawelczyk, LKML,
David Howells, Mark Rustad, Matthew Dempsky, Daeseok Youn,
Ingo Molnar, Jeff Kirsher, David Rientjes, Alex Thorlton,
Juri Lelli, Kees Cook, Nikolay Aleksandrov, Dario Faggioli,
Al Viro, James Morris, open list:ABI/API, Linux Containers,
Oleg Nesterov, Paul Moore, linux-security-module
In-Reply-To: <547740A0.4040700-/L3Ra7n9ekc@public.gmane.org>
On czw, 2014-11-27 at 16:17 +0100, Richard Weinberger wrote:
> Am 27.11.2014 um 16:11 schrieb Lukasz Pawelczyk:
> > On czw, 2014-11-27 at 16:01 +0100, Richard Weinberger wrote:
> >> Am 27.11.2014 um 15:44 schrieb Lukasz Pawelczyk:
> >>> True, the last one is 0x80000000. I did not notice that. Thanks for
> >>> pointing out.
> >>
> >> Isn't this CLONE_IO?
> >
> > Yes, I was merely noticing out loud that it's the last bit of 32bit.
> >
> > After close look though the 0x00001000 appears to be unused
>
> This was CLONE_PID.
> I'm not sure if we can reuse this. man 2 clone states "It disappeared in Linux 2.5.16.".
> Maybe one of the CC'd parties can tell more...
Would really like someone to comment on this. I'd like to avoid creating
a new syscall at this point.
According to clone(2):
CLONE_STOPPED has been removed in 2.6.38 and can be reused.
CLONE_PID as you mentioned has been removed in 2.5.16 but since 2.3.21
it could only be used by boot process (PID 0).
So this was really long time ago and effectively regular user space
cannot use it since 2.3.21.
--
Lukasz Pawelczyk
Samsung R&D Institute Poland
Samsung Electronics
^ permalink raw reply
* Re: [PATCH v3 5/5] tty/serial: Add Spreadtrum sc9836-uart driver support
From: Lyra Zhang @ 2014-11-27 15:23 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Murali Karicheri, Chunyan Zhang, Grant Likely, robh+dt@kernel.org,
Catalin Marinas, gregkh@linuxfoundation.org,
ijc+devicetree@hellion.org.uk, jslaby@suse.cz, Kumar Gala,
Mark Rutland, Pawel Moll, Ramkumar Ramachandra,
rrichter@cavium.com, Will Deacon, gnomes@lxorguk.ukuu.org.uk,
Jonathan Corbet, jason@lakedaemon.net, Mark Brown,
Heiko Stübner, florian.vaussard@epfl.ch
In-Reply-To: <3400511.2SONqVcoEr@wuerfel>
2014-11-27 20:57 GMT+08:00 Arnd Bergmann <arnd@arndb.de>:
> On Thursday 27 November 2014 19:59:46 Lyra Zhang wrote:
>> 2014-11-27 2:29 GMT+08:00 Murali Karicheri <m-karicheri2@ti.com>:
>> > On 11/25/2014 07:16 AM, Chunyan Zhang wrote:
>> >>
>> >> Add a full sc9836-uart driver for SC9836 SoC which is based on the
>>
>> >> +#include<linux/clk.h>
>> >
>> > How about sorting this includes? asm/irq.h go first followed linux/ in
>> > alphabatical order?
>>
>> >> +static irqreturn_t sprd_handle_irq(int irq, void *dev_id)
>> >> +{
>> >> + struct uart_port *port = (struct uart_port *)dev_id;
>> >> + u32 ims;
>> >> +
>> >> + ims = serial_in(port, SPRD_IMSR);
>> >> +
>> >> + serial_out(port, SPRD_ICLR, ~0);
>> >> +
>> >> + if (ims& (SPRD_IMSR_RX_FIFO_FULL |
>> >> + SPRD_IMSR_BREAK_DETECT | SPRD_IMSR_TIMEOUT)) {
>> >> + sprd_rx(irq, port);
>> >> + }
>> >> + if (ims& SPRD_IMSR_TX_FIFO_EMPTY)
>> >> + sprd_tx(irq, port);
>> >> +
>> >> + return IRQ_HANDLED;
>> >
>> > You are always returning IRQ_HANDLED and this is registered as a SHARED irq.
>> > Is there a chance this handler is called and the irq event doesn't
>> > belong to this device?
>> >
>> > Murali
>>
>> You are right, this is not a SHARED irq. I'll pass 0 for irqflags when
>> called 'devm_request_irq' in the next version patch.
>
> I think you could also add
>
> if (!ims)
> return IRQ_NONE;
>
> which would make it work on shared interrupt lines.
>
> Arnd
Yes, I saw this way in other serial drivers.
But, if then, there are two questions for me:
1. Why did some serial drivers need an UN_SHARED irq?
2. How can we choose a right way?
Thank you!
Best regards,
Chunyan
^ permalink raw reply
* Re: [RFC] lsm: namespace hooks
From: Richard Weinberger @ 2014-11-27 15:17 UTC (permalink / raw)
To: Lukasz Pawelczyk
Cc: Vladimir Davydov, Miklos Szeredi, Lukasz Pawelczyk, LKML,
David Howells, Mark Rustad, Matthew Dempsky, Daeseok Youn,
Ingo Molnar, Jeff Kirsher, David Rientjes, Alex Thorlton,
Juri Lelli, Kees Cook, Nikolay Aleksandrov, Dario Faggioli,
Al Viro, James Morris, ABI/API, Linux Containers, Oleg Nesterov,
Paul Moore, linux-security-module-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1417101060.1805.21.camel-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
Am 27.11.2014 um 16:11 schrieb Lukasz Pawelczyk:
> On czw, 2014-11-27 at 16:01 +0100, Richard Weinberger wrote:
>> Am 27.11.2014 um 15:44 schrieb Lukasz Pawelczyk:
>>> True, the last one is 0x80000000. I did not notice that. Thanks for
>>> pointing out.
>>
>> Isn't this CLONE_IO?
>
> Yes, I was merely noticing out loud that it's the last bit of 32bit.
>
> After close look though the 0x00001000 appears to be unused
This was CLONE_PID.
I'm not sure if we can reuse this. man 2 clone states "It disappeared in Linux 2.5.16.".
Maybe one of the CC'd parties can tell more...
Thanks,
//richard
^ permalink raw reply
* Re: [RFC] lsm: namespace hooks
From: Lukasz Pawelczyk @ 2014-11-27 15:11 UTC (permalink / raw)
To: Richard Weinberger
Cc: Vladimir Davydov, Miklos Szeredi, Lukasz Pawelczyk, LKML,
David Howells, Mark Rustad, Matthew Dempsky, Daeseok Youn,
Ingo Molnar, Jeff Kirsher, David Rientjes, Alex Thorlton,
Juri Lelli, Kees Cook, Nikolay Aleksandrov, Dario Faggioli,
Al Viro, James Morris, open list:ABI/API, Linux Containers,
Oleg Nesterov, Paul Moore, linux-security-module
In-Reply-To: <54773CE7.5040303-/L3Ra7n9ekc@public.gmane.org>
On czw, 2014-11-27 at 16:01 +0100, Richard Weinberger wrote:
> Am 27.11.2014 um 15:44 schrieb Lukasz Pawelczyk:
> > True, the last one is 0x80000000. I did not notice that. Thanks for
> > pointing out.
>
> Isn't this CLONE_IO?
Yes, I was merely noticing out loud that it's the last bit of 32bit.
After close look though the 0x00001000 appears to be unused
> > Any suggestion on what can be done here? New syscal with flags2?
>
> I'm not sure. But a new syscall would be a candidate.
--
Lukasz Pawelczyk
Samsung R&D Institute Poland
Samsung Electronics
^ permalink raw reply
* Re: [PATCH v4 1/3] perf: Use monotonic clock as a source for timestamps
From: Pawel Moll @ 2014-11-27 15:05 UTC (permalink / raw)
To: Ingo Molnar, Peter Zijlstra
Cc: Richard Cochran, Steven Rostedt, Paul Mackerras,
Arnaldo Carvalho de Melo, John Stultz, Masami Hiramatsu,
Christopher Covington, Namhyung Kim, David Ahern, Thomas Gleixner,
Tomeu Vizoso,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1415292718-19785-2-git-send-email-pawel.moll-5wv7dgnIgG8@public.gmane.org>
On Thu, 2014-11-06 at 16:51 +0000, Pawel Moll wrote:
> Until now, perf framework never defined the meaning of the timestamps
> captured as PERF_SAMPLE_TIME sample type. The values were obtaining
> from local (sched) clock, which is unavailable in userspace. This made
> it impossible to correlate perf data with any other events. Other
> tracing solutions have the source configurable (ftrace) or just share
> a common time domain between kernel and userspace (LTTng).
>
> Follow the trend by using monotonic clock, which is readily available
> as POSIX CLOCK_MONOTONIC.
>
> Also add a sysctl "perf_sample_time_clk_id" attribute which can be used
> by the user to obtain the clk_id to be used with POSIX clock API (eg.
> clock_gettime()) to obtain a time value comparable with perf samples.
>
> Old behaviour can be restored by using "perf_use_local_clock" kernel
> parameter.
>
> Signed-off-by: Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>
It's been 3 weeks without any negative feedback (no feedback at all, but
I take the optimistic view :-)...
How about queuing at least this patch alone for the incoming merge
window? Or at least getting it into -next, with the view at 3.20?
Pawel
^ permalink raw reply
* Re: [RFC] lsm: namespace hooks
From: Richard Weinberger @ 2014-11-27 15:01 UTC (permalink / raw)
To: Lukasz Pawelczyk
Cc: Vladimir Davydov, Miklos Szeredi, Lukasz Pawelczyk, LKML,
David Howells, Mark Rustad, Matthew Dempsky, Daeseok Youn,
Ingo Molnar, Jeff Kirsher, David Rientjes, Alex Thorlton,
Juri Lelli, Kees Cook, Nikolay Aleksandrov, Dario Faggioli,
Al Viro, James Morris, ABI/API, Linux Containers, Oleg Nesterov,
Paul Moore, linux-security-module-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1417099455.1805.17.camel-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
Am 27.11.2014 um 15:44 schrieb Lukasz Pawelczyk:
> On czw, 2014-11-27 at 15:38 +0100, Richard Weinberger wrote:
>> Am 27.11.2014 um 15:35 schrieb Lukasz Pawelczyk:
>>> On czw, 2014-11-27 at 15:18 +0100, Richard Weinberger wrote:
>>>> On Thu, Nov 27, 2014 at 3:01 PM, Lukasz Pawelczyk
>>>> <l.pawelczyk-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org> wrote:
>>>>> -/* 0x02000000 was previously the unused CLONE_STOPPED (Start in stopped state)
>>>>> - and is now available for re-use. */
>>>>> +#define CLONE_NEWLSM 0x02000000 /* New LSM namespace */
>>>>
>>>> FYI, CLONE_NEWCGROUP also claims last flag [1].
>>>
>>> Yes, I'm perfectly aware of that. I've seen those patches.
>>> This is RFC for now and CGROUP NS is not merged yet. I'll rebase when
>>> time comes.
>>
>> Just wanted to indicate that we run out of constants. :)
>
> True, the last one is 0x80000000. I did not notice that. Thanks for
> pointing out.
Isn't this CLONE_IO?
> Any suggestion on what can be done here? New syscal with flags2?
I'm not sure. But a new syscall would be a candidate.
Thanks,
//richard
^ permalink raw reply
* Re: [tpmdd-devel] [PATCH v7 04/10] tpm: rename chip->dev to chip->pdev
From: Jarkko Sakkinen @ 2014-11-27 14:51 UTC (permalink / raw)
To: Stefan Berger
Cc: Peter Huewe, Ashley Lai, Marcel Selhorst,
christophe.ricard-Re5JQEeQqe8AvxtiuMwx3w,
josh.triplett-ral2JQCrhuEAvxtiuMwx3w,
linux-api-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
jason.gunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/,
trousers-tech-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <5474F855.7080207-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
On Tue, Nov 25, 2014 at 04:44:53PM -0500, Stefan Berger wrote:
> On 11/11/2014 08:45 AM, Jarkko Sakkinen wrote:
> >Rename chip->dev to chip->pdev to make it explicit that this not the
> >character device but actually represents the platform device.
> >
> >Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
> >
>
>
> >diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
> >index 69f4003..b3a7c76 100644
> >--- a/drivers/char/tpm/tpm.h
> >+++ b/drivers/char/tpm/tpm.h
> >@@ -98,7 +98,7 @@ struct tpm_vendor_specific {
> > #define TPM_PPI_VERSION_LEN 3
> >
> > struct tpm_chip {
> >- struct device *dev; /* Device stuff */
> >+ struct device *pdev; /* Device stuff */
> > const struct tpm_class_ops *ops;
> >
> > int dev_num; /* /dev/tpm# */
>
> So this is the core requiring the renamings. I assume you got them all and
> none were hidden in #if's or so.
Yup, I basically did :argdo %s/chip->dev/chip->pdev/g for *.[ch].
> Reviewed-by: Stefan Berger <stefanb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
/Jarkko
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox