Re: [kernel-hardening] RE: [PATCH] printk: introduce kptr_restrict level 3
On Thu, Oct 06, 2016 at 04:05:53PM +0200, Jann Horn wrote:
> On Thu, Oct 06, 2016 at 01:47:47PM +, Roberts, William C wrote:
> > > -Original Message-
> > > From: Christoph Hellwig [mailto:h...@infradead.org]
> > > Sent: Thursday, October 6, 2016 9:32 AM
> > > To: Roberts, William C
> > > Cc: kernel-harden...@lists.openwall.com; cor...@lwn.net; linux-
> > > d...@vger.kernel.org; linux-ker...@vger.kernel.org
> > > Subject: Re: [PATCH] printk: introduce kptr_restrict level 3
> > >
> > > On Wed, Oct 05, 2016 at 02:04:46PM -0400, william.c.robe...@intel.com
> > > wrote:
> > > > From: William Roberts
> > > >
> > > > Some out-of-tree modules do not use %pK and just use %p, as it's the
> > > > common C paradigm for printing pointers. Because of this,
> > > > kptr_restrict has no affect on the output and thus, no way to contain
> > > > the kernel address leak.
> > >
> > > So what? We a) don't care about out of tree modules and b) you could
> > > just triviall
> > > fix them up if you care.
> >
> > Out of tree modules still affect core kernel security. I would also bet
> > money, that somewhere
> > In-tree someone has put a %p when they wanted a %pK. So this method is just
> > quite error
> > prone. We currently have a blacklist approach versus whitelist.
>
> grep says you have a point:
>
> $ grep -IR 'seq_printf.*%p[^FfSsBRrhbMmIiEUVKNadCDgG].*&'
> drivers/dma/qcom/hidma_dbg.c: seq_printf(s, "dev_trca=%p\n",
> &dmadev->dev_trca);
> drivers/dma/qcom/hidma_dbg.c: seq_printf(s, "dev_evca=%p\n",
> &dmadev->dev_evca);
>
> $ grep -IR 'pr_info.*%p[^FfSsBRrhbMmIiEUVKNadCDgG].*&'
> drivers/misc/lkdtm_heap.c:pr_info("Allocated memory %p-%p\n", base,
> &base[offset * 2]);
>
> $ grep -IR 'pr_err.*%p[^FfSsBRrhbMmIiEUVKNadCDgG].*&'
> drivers/net/ethernet/qlogic/qlge/qlge_dbg.c: pr_err("rx_ring->cqicb = %p\n",
> &rx_ring->cqicb);
Actually, I think I missed something here.
We don't really want to censor pointers in dmesg, right? dmesg can
contain pointers by design - and in particular, when an oops
happens, the register dump will reveal pointers. dmesg should just
be restricted using dmesg_restrict.
(What is annoying, though, is that e.g. Debian's default rsyslog
config sends all KERN_EMERG messages to all active PTYs by default,
meaning that on a system with such a config, making the kernel oops
can be used to leak some ASLR information.)
(And why does __die() in arch/x86/kernel/dumpstack.c use KERN_EMERG
for CONFIG_X86_32, but KERN_ALERT for !CONFIG_X86_32?)
signature.asc
Description: Digital signature
Re: docs: Fixing "sphinxify coccinelle.txt"?
>> Information from a commit like "docs: sphinxify coccinelle.txt and add it >> to dev-tools" caught also my software development attention. >> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/Documentation/coccinelle.txt?id=4b9033a33494ec9154d63e706e9e47f7eb3fd59e >> >> Did an other information from a comment become outdated in the script >> "coccicheck" >> because of such changes for the documentation format? >> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/scripts/coccicheck?id=c802e87fbe2d4dd58982d01b3c39bc5a781223aa#n4 > > How about submitting a patch to fix the problem? Is the published commit (from 2016-08-08 / 2016-08-18) generally questionable as I see it by the interface "cgit" at the moment? * Does this one contain only the deletion of the file "Documentation/coccinelle.txt"? * How should the result from the mentioned action "add it to dev-tools" look like finally? * How could the acknowledgements happen for a software transformation which seems to be incomplete there? I find another data display also interesting and more promising. https://patchwork.kernel.org/patch/9269973/ * Should this patch about the desired file format conversion become available also by the other known interfaces? * Would it have been nicer to include a corresponding update for the file "scripts/coccicheck" there, too? * Do we need to clarify the distribution of the correct version any further? Regards, Markus -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: docs: Fixing "sphinxify coccinelle.txt"?
>>> Information from a commit like "docs: sphinxify coccinelle.txt and add it >>> to dev-tools" caught also my software development attention. >>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/Documentation/coccinelle.txt?id=4b9033a33494ec9154d63e706e9e47f7eb3fd59e >>> >>> Did an other information from a comment become outdated in the script >>> "coccicheck" >>> because of such changes for the documentation format? >>> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/scripts/coccicheck?id=c802e87fbe2d4dd58982d01b3c39bc5a781223aa#n4 >> >> How about submitting a patch to fix the problem? > > Is the published commit (from 2016-08-08 / 2016-08-18) generally questionable > as I see it by the interface "cgit" at the moment? > > * Does this one contain only the deletion of the file > "Documentation/coccinelle.txt"? It seems that I got an inappropriate impression from this kind of data display alone. The display for the changed file name contains only the desired addition. https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/Documentation/dev-tools/coccinelle.rst?id=4b9033a33494ec9154d63e706e9e47f7eb3fd59e > I find another data display also interesting and more promising. > https://patchwork.kernel.org/patch/9269973/ > > * Should this patch about the desired file format conversion become available > also by the other known interfaces? The interface "cgit v0.12" does not indicate the involved "renaming" (similarity index 56%) so far which can be better seen in the downloadable patch file. Regards, Markus -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] scripts/coccicheck: Update reference for the corresponding documentation
From: Markus Elfring
Date: Fri, 7 Oct 2016 16:06:15 +0200
Use the current name (in a comment at the beginning of this script) for
the file which was converted to the documentation format "reStructuredText"
in August 2016.
Fixes: 4b9033a33494ec9154d63e706e9e47f7eb3fd59e ("docs: sphinxify
coccinelle.txt and add it to dev-tools")
Signed-off-by: Markus Elfring
---
scripts/coccicheck | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/coccicheck b/scripts/coccicheck
index c92c1528..ec487b8 100755
--- a/scripts/coccicheck
+++ b/scripts/coccicheck
@@ -1,7 +1,7 @@
#!/bin/bash
# Linux kernel coccicheck
#
-# Read Documentation/coccinelle.txt
+# Read Documentation/dev-tools/coccinelle.rst
#
# This script requires at least spatch
# version 1.0.0-rc11.
--
2.10.1
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] printk: introduce kptr_restrict level 3
> > As a _singlular_ argument, "it's for out-of-tree code" is weak. As an > _additional_ > argument, it has value. Saying "this only helps out-of-tree code" doesn't > carry > much weight. Saying "this helps kernel security, even for out-of-tree code" is > perfectly valid. And a wrinkle in this is that some day, either that > out-of-tree > code, or brand new code, will land in the kernel, and we don't want to > continue > to require authors be aware of an opt-in security feature. The kernel should > protect itself (and all of itself, including out-of-tree or future code) by > default. > I should have made this more clear in my message, this was in my head and I assumed that people would just get it. But I shouldn't have made such an assumption. > And based on my read of this thread, we all appear to be in violent > agreement. :) > "always protect %p" is absolutely the goal, and we can figure out the best > way to > get there. > > -Kees > > -- > Kees Cook > Nexus Security
Re: [PATCHv2] hwmon: Add tc654 driver
On Fri, Oct 07, 2016 at 02:38:44PM +1300, Chris Packham wrote: > Add support for the tc654 and tc655 fan controllers from Microchip. > > http://ww1.microchip.com/downloads/en/DeviceDoc/20001734C.pdf > > Signed-off-by: Chris Packham > --- > > Changes in v2: > - Add Documentation/hwmon/tc654 > - Incorporate most of the review comments from Guenter. Additional error > handling is added. Unused/unnecessary code is removed. I decided not > to go down the regmap path yet. I may circle back to it when I look at > using regmap in the adm9240 driver. > > .../devicetree/bindings/i2c/trivial-devices.txt| 2 + > Documentation/hwmon/tc654 | 26 ++ > drivers/hwmon/Kconfig | 11 + > drivers/hwmon/Makefile | 1 + > drivers/hwmon/tc654.c | 513 > + > 5 files changed, 553 insertions(+) > create mode 100644 Documentation/hwmon/tc654 > create mode 100644 drivers/hwmon/tc654.c > > diff --git a/Documentation/devicetree/bindings/i2c/trivial-devices.txt > b/Documentation/devicetree/bindings/i2c/trivial-devices.txt > index 1416c6a0d2cd..833fb9f133d3 100644 > --- a/Documentation/devicetree/bindings/i2c/trivial-devices.txt > +++ b/Documentation/devicetree/bindings/i2c/trivial-devices.txt > @@ -122,6 +122,8 @@ microchip,mcp4662-502 Microchip 8-bit Dual I2C > Digital Potentiometer with NV Mem > microchip,mcp4662-103Microchip 8-bit Dual I2C Digital Potentiometer > with NV Memory (10k) > microchip,mcp4662-503Microchip 8-bit Dual I2C Digital Potentiometer > with NV Memory (50k) > microchip,mcp4662-104Microchip 8-bit Dual I2C Digital Potentiometer > with NV Memory (100k) > +microchip,tc654 PWM Fan Speed Controller With Fan Fault > Detection > +microchip,tc655 PWM Fan Speed Controller With Fan Fault > Detection > national,lm63Temperature sensor with integrated fan control > national,lm75I2C TEMP SENSOR > national,lm80Serial Interface ACPI-Compatible Microprocessor > System Hardware Monitor > diff --git a/Documentation/hwmon/tc654 b/Documentation/hwmon/tc654 > new file mode 100644 > index ..93796c5c7e79 > --- /dev/null > +++ b/Documentation/hwmon/tc654 > @@ -0,0 +1,26 @@ > +Kernel driver tc654 > +=== > + > +Supported chips: > + * Microship TC654 and TC655 > +Prefix: 'tc654' > +Datasheet: http://ww1.microchip.com/downloads/en/DeviceDoc/20001734C.pdf > + > +Authors: > +Chris Packham > +Masahiko Iwamoto > + > +Description > +--- > +This driver implements support for the Microchip TC654 and TC655. > + > +The TC654 used the 2-wire interface compatible with the SMBUS 2.0 uses > +specification. The TC654 has two (2) inputs for measuring fan RPM and > +one (1) PWM output which can be used for fan control. > + > +Configuration Notes > +--- > +Ordinarily the pwm1_mode ABI is used for controlling the pwm output > +mode. However, for this chip the output is always pwm, and the > +pwm1_mode determines if the pwm output is controlled via the pwm1 value > +or via the Vin analog input. Please describe the supported values here. > diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig > index 45cef3d2c75c..8681bc65cde5 100644 > --- a/drivers/hwmon/Kconfig > +++ b/drivers/hwmon/Kconfig > @@ -907,6 +907,17 @@ config SENSORS_MCP3021 > This driver can also be built as a module. If so, the module > will be called mcp3021. > > +config SENSORS_TC654 > + tristate "Microchip TC654/TC655 and compatibles" > + depends on I2C > + help > + If you say yes here you get support for TC654 and TC655. > + The TC654 and TC655 are PWM mode fan speed controllers with > + FanSense technology for use with brushless DC fans. > + > + This driver can also be built as a module. If so, the module > + will be called tc654. > + > config SENSORS_MENF21BMC_HWMON > tristate "MEN 14F021P00 BMC Hardware Monitoring" > depends on MFD_MENF21BMC > diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile > index aecf4ba17460..c651f0f1d047 100644 > --- a/drivers/hwmon/Makefile > +++ b/drivers/hwmon/Makefile > @@ -122,6 +122,7 @@ obj-$(CONFIG_SENSORS_MAX6697) += max6697.o > obj-$(CONFIG_SENSORS_MAX31790) += max31790.o > obj-$(CONFIG_SENSORS_MC13783_ADC)+= mc13783-adc.o > obj-$(CONFIG_SENSORS_MCP3021)+= mcp3021.o > +obj-$(CONFIG_SENSORS_TC654) += tc654.o > obj-$(CONFIG_SENSORS_MENF21BMC_HWMON) += menf21bmc_hwmon.o > obj-$(CONFIG_SENSORS_NCT6683)+= nct6683.o > obj-$(CONFIG_SENSORS_NCT6775)+= nct6775.o > diff --git a/drivers/hwmon/tc654.c b/drivers/hwmon/tc654.c > new file mode 100644 > index ..cba31cbd3383 > --- /dev/null > +++ b/drivers/hwmon/tc654.c > @@ -0,0 +1,513 @@ > +/* > + * tc654.c - Linux kernel modules for f
Re: [PATCH] scripts/coccicheck: Update reference for the corresponding documentation
On Fri, 7 Oct 2016, SF Markus Elfring wrote:
> From: Markus Elfring
> Date: Fri, 7 Oct 2016 16:06:15 +0200
>
> Use the current name (in a comment at the beginning of this script) for
> the file which was converted to the documentation format "reStructuredText"
> in August 2016.
>
> Fixes: 4b9033a33494ec9154d63e706e9e47f7eb3fd59e ("docs: sphinxify
> coccinelle.txt and add it to dev-tools")
> Signed-off-by: Markus Elfring
Acked-by: Julia Lawall
> ---
> scripts/coccicheck | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/scripts/coccicheck b/scripts/coccicheck
> index c92c1528..ec487b8 100755
> --- a/scripts/coccicheck
> +++ b/scripts/coccicheck
> @@ -1,7 +1,7 @@
> #!/bin/bash
> # Linux kernel coccicheck
> #
> -# Read Documentation/coccinelle.txt
> +# Read Documentation/dev-tools/coccinelle.rst
> #
> # This script requires at least spatch
> # version 1.0.0-rc11.
> --
> 2.10.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH-tip v4 02/10] locking/rwsem: Stop active read lock ASAP
On 10/06/2016 05:47 PM, Dave Chinner wrote: On Thu, Oct 06, 2016 at 11:17:18AM -0700, Davidlohr Bueso wrote: On Thu, 18 Aug 2016, Waiman Long wrote: Currently, when down_read() fails, the active read locking isn't undone until the rwsem_down_read_failed() function grabs the wait_lock. If the wait_lock is contended, it may takes a while to get the lock. During that period, writer lock stealing will be disabled because of the active read lock. This patch will release the active read lock ASAP so that writer lock stealing can happen sooner. The only downside is when the reader is the first one in the wait queue as it has to issue another atomic operation to update the count. On a 4-socket Haswell machine running on a 4.7-rc1 tip-based kernel, the fio test with multithreaded randrw and randwrite tests on the same file on a XFS partition on top of a NVDIMM with DAX were run, the aggregated bandwidths before and after the patch were as follows: Test BW before patch BW after patch % change --- -- randrw1210 MB/s 1352 MB/s +12% randwrite 1622 MB/s 1710 MB/s +5.4% Yeah, this is really a bad workload to make decisions on locking heuristics imo - if I'm thinking of the same workload. Mainly because concurrent buffered io to the same file isn't very realistic and you end up pathologically pounding on i_rwsem (which used to be until recently i_mutex until Al's parallel lookup/readdir). Obviously write lock stealing wins in this case. Except that it's DAX, and in 4.7-rc1 that used shared locking at the XFS level and never took exclusive locks. *However*, the DAX IO path locking in XFS has changed in 4.9-rc1 to match the buffered IO single writer POSIX semantics - the test is a bad test based on the fact it exercised a path that is under heavy development and so can't be used as a regression test across multiple kernels. If you want to stress concurrent access to a single file, please use direct IO, not DAX or buffered IO. Thanks for the update. I will change the test when I update this patch. Cheers, Longman -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/5] rpmsg: smd: Reduce restrictions when finding channel
SMD channels are created by the remotes in "opening" state, but
sometimes as we close and try to reopen them they linger in closing
state.
Following the search for a matching channel the create_ept() will verify
that the channel is in a suitable state, so we can lax the restrictions
of the search function to work around above difference in behaviour.
Signed-off-by: Bjorn Andersson
---
drivers/rpmsg/qcom_smd.c | 15 ---
1 file changed, 4 insertions(+), 11 deletions(-)
diff --git a/drivers/rpmsg/qcom_smd.c b/drivers/rpmsg/qcom_smd.c
index 06fef2b4c814..92efa74a0024 100644
--- a/drivers/rpmsg/qcom_smd.c
+++ b/drivers/rpmsg/qcom_smd.c
@@ -820,20 +820,13 @@ qcom_smd_find_channel(struct qcom_smd_edge *edge, const
char *name)
struct qcom_smd_channel *channel;
struct qcom_smd_channel *ret = NULL;
unsigned long flags;
- unsigned state;
spin_lock_irqsave(&edge->channels_lock, flags);
list_for_each_entry(channel, &edge->channels, list) {
- if (strcmp(channel->name, name))
- continue;
-
- state = GET_RX_CHANNEL_INFO(channel, state);
- if (state != SMD_CHANNEL_OPENING &&
- state != SMD_CHANNEL_OPENED)
- continue;
-
- ret = channel;
- break;
+ if (!strcmp(channel->name, name)) {
+ ret = channel;
+ break;
+ }
}
spin_unlock_irqrestore(&edge->channels_lock, flags);
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/5] rpmsg: Driver for user space endpoint interface
This driver allows rpmsg instances to expose access to rpmsg endpoints
to user space processes. It provides a control interface, allowing
userspace to export endpoints and an endpoint interface for each exposed
endpoint.
The implementation is based on prior art by Texas Instrument, Google,
PetaLogix and was derived from a FreeRTOS performance statistics driver
written by Michal Simek.
The control interface provides a "create endpoint" ioctl, which is fed a
name, source and destination address. The three values are used to
create the endpoint, in a backend-specific way, and a rpmsg endpoint
device is created - with the three parameters are available in sysfs for
udev usage.
E.g. to create an endpoint device for one of the Qualcomm SMD channel
related to DIAG one would issue:
struct rpmsg_endpoint_info info = { "DIAG_CNTL", 0, 0 };
int fd = open("/dev/rpmsg_ctrl0", O_RDWR);
ioctl(fd, RPMSG_CREATE_EPT_IOCTL, &info);
Each created endpoint device shows up as an individual character device
in /dev, allowing permission to be controlled on a per-endpoint basis.
The rpmsg endpoint will be created and destroyed following the opening
and closing of the endpoint device, allowing rpmsg backends to open and
close the physical channel, if supported by the wire protocol.
Cc: Marek Novak
Cc: Matteo Sartori
Cc: Michal Simek
Signed-off-by: Bjorn Andersson
---
Documentation/ioctl/ioctl-number.txt | 1 +
drivers/rpmsg/Makefile | 2 +-
drivers/rpmsg/rpmsg_char.c | 576 +++
drivers/rpmsg/rpmsg_internal.h | 2 +
include/uapi/linux/rpmsg.h | 35 +++
5 files changed, 615 insertions(+), 1 deletion(-)
create mode 100644 drivers/rpmsg/rpmsg_char.c
create mode 100644 include/uapi/linux/rpmsg.h
diff --git a/Documentation/ioctl/ioctl-number.txt
b/Documentation/ioctl/ioctl-number.txt
index 81c7f2bb7daf..08244bea5048 100644
--- a/Documentation/ioctl/ioctl-number.txt
+++ b/Documentation/ioctl/ioctl-number.txt
@@ -321,6 +321,7 @@ Code Seq#(hex) Include FileComments
0xB1 00-1F PPPoX
0xB3 00 linux/mmc/ioctl.h
0xB4 00-0F linux/gpio.h
+0xB5 00-0F uapi/linux/rpmsg.h
0xC0 00-0F linux/usb/iowarrior.h
0xCA 00-0F uapi/misc/cxl.h
0xCA 80-8F uapi/scsi/cxlflash_ioctl.h
diff --git a/drivers/rpmsg/Makefile b/drivers/rpmsg/Makefile
index ae9c9132cf76..5daf1209b77d 100644
--- a/drivers/rpmsg/Makefile
+++ b/drivers/rpmsg/Makefile
@@ -1,3 +1,3 @@
-obj-$(CONFIG_RPMSG)+= rpmsg_core.o
+obj-$(CONFIG_RPMSG)+= rpmsg_core.o rpmsg_char.o
obj-$(CONFIG_RPMSG_QCOM_SMD) += qcom_smd.o
obj-$(CONFIG_RPMSG_VIRTIO) += virtio_rpmsg_bus.o
diff --git a/drivers/rpmsg/rpmsg_char.c b/drivers/rpmsg/rpmsg_char.c
new file mode 100644
index ..a398a63e8d44
--- /dev/null
+++ b/drivers/rpmsg/rpmsg_char.c
@@ -0,0 +1,576 @@
+/*
+ * Copyright (c) 2016, Linaro Ltd.
+ * Copyright (c) 2012, Michal Simek
+ * Copyright (c) 2012, PetaLogix
+ * Copyright (c) 2011, Texas Instruments, Inc.
+ * Copyright (c) 2011, Google, Inc.
+ *
+ * Based on rpmsg performance statistics driver by Michal Simek, which in turn
+ * was based on TI & Google OMX rpmsg driver.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only 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
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "rpmsg_internal.h"
+
+#define RPMSG_DEV_MAX 256
+
+static dev_t rpmsg_major;
+static struct class *rpmsg_class;
+
+static DEFINE_IDA(rpmsg_ctrl_ida);
+static DEFINE_IDA(rpmsg_ept_ida);
+static DEFINE_IDA(rpmsg_minor_ida);
+
+#define dev_to_eptdev(dev) container_of(dev, struct rpmsg_eptdev, dev)
+#define cdev_to_eptdev(i_cdev) container_of(i_cdev, struct rpmsg_eptdev, cdev)
+
+#define dev_to_ctrldev(dev) container_of(dev, struct rpmsg_ctrldev, dev)
+#define cdev_to_ctrldev(i_cdev) container_of(i_cdev, struct rpmsg_ctrldev,
cdev)
+
+struct rpmsg_ctrldev {
+ struct rpmsg_device *rpdev;
+ struct cdev cdev;
+ struct device dev;
+};
+
+struct rpmsg_eptdev {
+ struct device dev;
+ struct cdev cdev;
+
+ struct rpmsg_device *rpdev;
+ struct rpmsg_channel_info chinfo;
+
+ struct mutex ept_lock;
+ struct rpmsg_endpoint *ept;
+
+ spinlock_t queue_lock;
+ struct sk_buff_head queue;
+ wait_queue_head_t readq;
+};
+
+static int rpmsg_eptdev_destroy(struct rp
[PATCH 5/5] rpmsg: smd: Register rpmsg user space interface for edges
Create and register a rpmsg device for use with the rpmsg user space
interface, allowing user space to access SMD channels.
Also provide the "rpmsg_name" device attribute to expose the edge name
in sysfs, allowing the user to write udev rules for specific rpmsg
devices and their children.
Signed-off-by: Bjorn Andersson
---
drivers/rpmsg/qcom_smd.c | 36
1 file changed, 36 insertions(+)
diff --git a/drivers/rpmsg/qcom_smd.c b/drivers/rpmsg/qcom_smd.c
index 92efa74a0024..86856b2b558a 100644
--- a/drivers/rpmsg/qcom_smd.c
+++ b/drivers/rpmsg/qcom_smd.c
@@ -983,6 +983,20 @@ static int qcom_smd_create_device(struct qcom_smd_channel
*channel)
return rpmsg_register_device(rpdev);
}
+static int qcom_smd_create_chrdev(struct qcom_smd_edge *edge)
+{
+ struct qcom_smd_device *qsdev;
+
+ qsdev = kzalloc(sizeof(*qsdev), GFP_KERNEL);
+ if (!qsdev)
+ return -ENOMEM;
+
+ qsdev->edge = edge;
+ qsdev->rpdev.ops = &qcom_smd_device_ops;
+ qsdev->rpdev.dev.parent = &edge->dev;
+ return rpmsg_chrdev_register_device(&qsdev->rpdev);
+}
+
/*
* Allocate the qcom_smd_channel object for a newly found smd channel,
* retrieving and validating the smem items involved.
@@ -1284,6 +1298,21 @@ static void qcom_smd_edge_release(struct device *dev)
kfree(edge);
}
+static ssize_t rpmsg_name_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct qcom_smd_edge *edge = to_smd_edge(dev);
+
+ return sprintf(buf, "%s\n", edge->of_node->name);
+}
+static DEVICE_ATTR_RO(rpmsg_name);
+
+static struct attribute *qcom_smd_edge_attrs[] = {
+ &dev_attr_rpmsg_name.attr,
+ NULL
+};
+ATTRIBUTE_GROUPS(qcom_smd_edge);
+
/**
* qcom_smd_register_edge() - register an edge based on an device_node
* @parent:parent device for the edge
@@ -1305,6 +1334,7 @@ struct qcom_smd_edge *qcom_smd_register_edge(struct
device *parent,
edge->dev.parent = parent;
edge->dev.release = qcom_smd_edge_release;
+ edge->dev.groups = qcom_smd_edge_groups;
dev_set_name(&edge->dev, "%s:%s", dev_name(parent), node->name);
ret = device_register(&edge->dev);
if (ret) {
@@ -1318,6 +1348,12 @@ struct qcom_smd_edge *qcom_smd_register_edge(struct
device *parent,
goto unregister_dev;
}
+ ret = qcom_smd_create_chrdev(edge);
+ if (ret) {
+ dev_err(&edge->dev, "failed to register chrdev for edge\n");
+ goto unregister_dev;
+ }
+
schedule_work(&edge->scan_work);
return edge;
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/5] rpmsg: Support drivers without primary endpoint
Some types of rpmsg drivers does not have a primary endpoint to tie
their existence upon, but wishes to create and destroy endpoints
dynamically, e.g. based on user interactions.
Allow rpmsg drivers to omit a driver callback to signal this case and
make the probe path not create a primary endpoint in this case.
Signed-off-by: Bjorn Andersson
---
drivers/rpmsg/rpmsg_core.c | 32 ++--
1 file changed, 18 insertions(+), 14 deletions(-)
diff --git a/drivers/rpmsg/rpmsg_core.c b/drivers/rpmsg/rpmsg_core.c
index 087d4db896c8..7561941ba413 100644
--- a/drivers/rpmsg/rpmsg_core.c
+++ b/drivers/rpmsg/rpmsg_core.c
@@ -347,27 +347,30 @@ static int rpmsg_dev_probe(struct device *dev)
struct rpmsg_device *rpdev = to_rpmsg_device(dev);
struct rpmsg_driver *rpdrv = to_rpmsg_driver(rpdev->dev.driver);
struct rpmsg_channel_info chinfo = {};
- struct rpmsg_endpoint *ept;
+ struct rpmsg_endpoint *ept = NULL;
int err;
- strncpy(chinfo.name, rpdev->id.name, RPMSG_NAME_SIZE);
- chinfo.src = rpdev->src;
- chinfo.dst = RPMSG_ADDR_ANY;
+ if (rpdrv->callback) {
+ strncpy(chinfo.name, rpdev->id.name, RPMSG_NAME_SIZE);
+ chinfo.src = rpdev->src;
+ chinfo.dst = RPMSG_ADDR_ANY;
- ept = rpmsg_create_ept(rpdev, rpdrv->callback, NULL, chinfo);
- if (!ept) {
- dev_err(dev, "failed to create endpoint\n");
- err = -ENOMEM;
- goto out;
- }
+ ept = rpmsg_create_ept(rpdev, rpdrv->callback, NULL, chinfo);
+ if (!ept) {
+ dev_err(dev, "failed to create endpoint\n");
+ err = -ENOMEM;
+ goto out;
+ }
- rpdev->ept = ept;
- rpdev->src = ept->addr;
+ rpdev->ept = ept;
+ rpdev->src = ept->addr;
+ }
err = rpdrv->probe(rpdev);
if (err) {
dev_err(dev, "%s: failed: %d\n", __func__, err);
- rpmsg_destroy_ept(ept);
+ if (ept)
+ rpmsg_destroy_ept(ept);
goto out;
}
@@ -388,7 +391,8 @@ static int rpmsg_dev_remove(struct device *dev)
rpdrv->remove(rpdev);
- rpmsg_destroy_ept(rpdev->ept);
+ if (rpdev->ept)
+ rpmsg_destroy_ept(rpdev->ept);
return err;
}
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/5] rpmsg: Introduce a driver override mechanism
Similar to other subsystems it's useful to provide a mechanism to force
a specific driver match on a device, so introduce this.
Signed-off-by: Bjorn Andersson
---
drivers/rpmsg/rpmsg_core.c | 3 +++
include/linux/rpmsg.h | 2 ++
2 files changed, 5 insertions(+)
diff --git a/drivers/rpmsg/rpmsg_core.c b/drivers/rpmsg/rpmsg_core.c
index b6ea9ffa7381..087d4db896c8 100644
--- a/drivers/rpmsg/rpmsg_core.c
+++ b/drivers/rpmsg/rpmsg_core.c
@@ -315,6 +315,9 @@ static int rpmsg_dev_match(struct device *dev, struct
device_driver *drv)
const struct rpmsg_device_id *ids = rpdrv->id_table;
unsigned int i;
+ if (rpdev->driver_override)
+ return !strcmp(rpdev->driver_override, drv->name);
+
if (ids)
for (i = 0; ids[i].name[0]; i++)
if (rpmsg_id_match(rpdev, &ids[i]))
diff --git a/include/linux/rpmsg.h b/include/linux/rpmsg.h
index 452d393cc8dd..7ad6c205f110 100644
--- a/include/linux/rpmsg.h
+++ b/include/linux/rpmsg.h
@@ -64,6 +64,7 @@ struct rpmsg_channel_info {
* rpmsg_device - device that belong to the rpmsg bus
* @dev: the device struct
* @id: device id (used to match between rpmsg drivers and devices)
+ * @driver_override: driver name to force a match
* @src: local address
* @dst: destination address
* @ept: the rpmsg endpoint of this channel
@@ -72,6 +73,7 @@ struct rpmsg_channel_info {
struct rpmsg_device {
struct device dev;
struct rpmsg_device_id id;
+ char *driver_override;
u32 src;
u32 dst;
struct rpmsg_endpoint *ept;
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
