RE: [PATCH 1/2] usb: configfs: allow UDC binding rule configured as binding to *any* UDC

[Du, Changbin]

Hi,
> > On most platforms, there is only one device controller available.
> > In this case, we desn't care the UDC's name. So let's ignore the
> > name by setting 'UDC' to 'any'.
> 
> Hmm libubsgx allows to do this for a very long time. You simply pass
> NULL instead of pointer to usbg_udc.
> 
> It is also possible to do this from command line, just simply:
> 
> $ echo `ls -1 /sys/class/udc | head -n 1` > UDC
> 
> So if we can easily do this from user space what's the benefit of adding
> this special "any" keyword to kernel?
> 
Well, it is just for *easy to use*. Looking up /sys/class/udc mostly
can be skipped. The UDC core support this convenience behavior, 
so why don't we export it with a little change?

> > And also we can change UDC name
> > at any time if it is not binded (no need set to "" first).
> >
> 
> Not sure if:
> 
> $ echo "" > UDC
> 
> is really a problem. Personally I'm quite used to situation in which I
> have to turn the light off before turning it on once again;)
> 
That is not a problem. But just avoid pseudo 'busy'. If gadget is not 
bind, it is free to reconfigure it. So seem no need block re-configuration.

In a word, this patch is just an improvement, not to fix any issues or
add new function.

> Cheers,
> --
> Krzysztof Opasiak
> Samsung R Institute Poland
> Samsung Electronics

Thanks,
Du, Changbin
--
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 24/25] arm64:ilp32: add vdso-ilp32 and use for signal return

[Zhangjian (Bamvor)]

Hi,

On 2016/5/5 7:23, Andrew Pinski wrote:

On Wed, May 4, 2016 at 2:49 PM, Yury Norov  wrote:

On Tue, May 03, 2016 at 08:41:25PM +0800, Zhangjian (Bamvor) wrote:

Hi, all

After apply this patch with my small testcase, the vsyscall of gettimeofday in
ilp32 works in both big endian and small endian. In this patch, I use the
different register and offset for ilp32 and lp64. Actually, the
COMPAT_TVAL_TV_SEC is same as TVAL_TV_SEC(so as to COMPAT_TSPEC_TV_SEC and
TSPEC_TV_SEC). I add it to keep the logic clear. I also change the version
of vdso to 4.6. It should change to 2.6.39 if glibc is not update.



[...]

Hi Bamvor,

It works for me as well. Thank you.
I'll incorporate it in next submission.


We should add the following so we are complaint to the ILP32 ABI
dealing with pointers don't have to be zero extended for arguments,
Note ZERO should most likely be ZERO_PTR or something to do that
effect, I am not so good with names.
#ifdef __LP64__
#define ZERO(n)
#else
#define ZERO(n) mov w##n, w##n
#endif

...
ENTRY(__kernel_gettimeofday)
 .cfi_startproc
 ZERO(0)
 ZERO(1)
...
ENTRY(__kernel_clock_gettime)
 .cfi_startproc
 ZERO(1)
...
ENTRY(__kernel_clock_getres)
 .cfi_startproc
 ZERO(1)

Thanks. I will test and send a new version.

Thanks.

Bamvor

Thanks,
Andrew Pinski



Yury.


--
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 v2 1/4] rpmsg: add THIS_MODULE to rpmsg_driver in rpmsg core

[Andrew F. Davis]

Add register_rpmsg_driver helper macro that adds THIS_MODULE to
rpmsg_driver for the registering driver. We rename and modify
the existing register_rpmsg_driver to enable this.

Signed-off-by: Andrew F. Davis 
Acked-by: Suman Anna 
---
 drivers/rpmsg/virtio_rpmsg_bus.c | 8 +---
 include/linux/rpmsg.h| 6 +-
 2 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c b/drivers/rpmsg/virtio_rpmsg_bus.c
index 1fcd27c..fe03b2a 100644
--- a/drivers/rpmsg/virtio_rpmsg_bus.c
+++ b/drivers/rpmsg/virtio_rpmsg_bus.c
@@ -436,17 +436,19 @@ static struct bus_type rpmsg_bus = {
 };
 
 /**
- * register_rpmsg_driver() - register an rpmsg driver with the rpmsg bus
+ * __register_rpmsg_driver() - register an rpmsg driver with the rpmsg bus
  * @rpdrv: pointer to a struct rpmsg_driver
+ * @owner: owning module/driver
  *
  * Returns 0 on success, and an appropriate error value on failure.
  */
-int register_rpmsg_driver(struct rpmsg_driver *rpdrv)
+int __register_rpmsg_driver(struct rpmsg_driver *rpdrv, struct module *owner)
 {
rpdrv->drv.bus = _bus;
+   rpdrv->drv.owner = owner;
return driver_register(>drv);
 }
-EXPORT_SYMBOL(register_rpmsg_driver);
+EXPORT_SYMBOL(__register_rpmsg_driver);
 
 /**
  * unregister_rpmsg_driver() - unregister an rpmsg driver from the rpmsg bus
diff --git a/include/linux/rpmsg.h b/include/linux/rpmsg.h
index 82a6739..7ff5790 100644
--- a/include/linux/rpmsg.h
+++ b/include/linux/rpmsg.h
@@ -169,7 +169,7 @@ struct rpmsg_driver {
 
 int register_rpmsg_device(struct rpmsg_channel *dev);
 void unregister_rpmsg_device(struct rpmsg_channel *dev);
-int register_rpmsg_driver(struct rpmsg_driver *drv);
+int __register_rpmsg_driver(struct rpmsg_driver *drv, struct module *owner);
 void unregister_rpmsg_driver(struct rpmsg_driver *drv);
 void rpmsg_destroy_ept(struct rpmsg_endpoint *);
 struct rpmsg_endpoint *rpmsg_create_ept(struct rpmsg_channel *,
@@ -177,6 +177,10 @@ struct rpmsg_endpoint *rpmsg_create_ept(struct 
rpmsg_channel *,
 int
 rpmsg_send_offchannel_raw(struct rpmsg_channel *, u32, u32, void *, int, bool);
 
+/* use a macro to avoid include chaining to get THIS_MODULE */
+#define register_rpmsg_driver(drv) \
+   __register_rpmsg_driver(drv, THIS_MODULE)
+
 /**
  * rpmsg_send() - send a message across to the remote processor
  * @rpdev: the rpmsg channel
-- 
2.8.2

--
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 v2 2/4] rpmsg: drop owner assignment from rpmsg_drivers

[Andrew F. Davis]

An rpmsg_driver does not need to set an owner, it will be populated by
the driver core.

Signed-off-by: Andrew F. Davis 
---
 Documentation/rpmsg.txt | 1 -
 samples/rpmsg/rpmsg_client_sample.c | 1 -
 2 files changed, 2 deletions(-)

diff --git a/Documentation/rpmsg.txt b/Documentation/rpmsg.txt
index f7edc3a..1d88426 100644
--- a/Documentation/rpmsg.txt
+++ b/Documentation/rpmsg.txt
@@ -249,7 +249,6 @@ MODULE_DEVICE_TABLE(rpmsg, rpmsg_driver_sample_id_table);
 
 static struct rpmsg_driver rpmsg_sample_client = {
.drv.name   = KBUILD_MODNAME,
-   .drv.owner  = THIS_MODULE,
.id_table   = rpmsg_driver_sample_id_table,
.probe  = rpmsg_sample_probe,
.callback   = rpmsg_sample_cb,
diff --git a/samples/rpmsg/rpmsg_client_sample.c 
b/samples/rpmsg/rpmsg_client_sample.c
index 59b1344..82ed288 100644
--- a/samples/rpmsg/rpmsg_client_sample.c
+++ b/samples/rpmsg/rpmsg_client_sample.c
@@ -77,7 +77,6 @@ MODULE_DEVICE_TABLE(rpmsg, rpmsg_driver_sample_id_table);
 
 static struct rpmsg_driver rpmsg_sample_client = {
.drv.name   = KBUILD_MODNAME,
-   .drv.owner  = THIS_MODULE,
.id_table   = rpmsg_driver_sample_id_table,
.probe  = rpmsg_sample_probe,
.callback   = rpmsg_sample_cb,
-- 
2.8.2

--
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 v2 3/4] rpmsg: add helper macro module_rpmsg_driver

[Andrew F. Davis]

This patch introduces the module_rpmsg_driver macro which is a
convenience macro for rpmsg driver modules similar to
module_platform_driver. It is intended to be used by drivers which
init/exit section does nothing but register/unregister the rpmsg driver.
By using this macro it is possible to eliminate a few lines of
boilerplate code per rpmsg driver.

Signed-off-by: Andrew F. Davis 
---
 include/linux/rpmsg.h | 12 
 1 file changed, 12 insertions(+)

diff --git a/include/linux/rpmsg.h b/include/linux/rpmsg.h
index 7ff5790..ada50ff 100644
--- a/include/linux/rpmsg.h
+++ b/include/linux/rpmsg.h
@@ -182,6 +182,18 @@ rpmsg_send_offchannel_raw(struct rpmsg_channel *, u32, 
u32, void *, int, bool);
__register_rpmsg_driver(drv, THIS_MODULE)
 
 /**
+ * module_rpmsg_driver() - Helper macro for registering an rpmsg driver
+ * @__rpmsg_driver: rpmsg_driver struct
+ *
+ * Helper macro for rpmsg drivers which do not do anything special in module
+ * init/exit. This eliminates a lot of boilerplate.  Each module may only
+ * use this macro once, and calling it replaces module_init() and module_exit()
+ */
+#define module_rpmsg_driver(__rpmsg_driver) \
+   module_driver(__rpmsg_driver, register_rpmsg_driver, \
+   unregister_rpmsg_driver)
+
+/**
  * rpmsg_send() - send a message across to the remote processor
  * @rpdev: the rpmsg channel
  * @data: payload of message
-- 
2.8.2

--
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 24/25] arm64:ilp32: add vdso-ilp32 and use for signal return

[Yury Norov]

On Tue, May 03, 2016 at 08:41:25PM +0800, Zhangjian (Bamvor) wrote:
> Hi, all
> 
> After apply this patch with my small testcase, the vsyscall of gettimeofday in
> ilp32 works in both big endian and small endian. In this patch, I use the
> different register and offset for ilp32 and lp64. Actually, the
> COMPAT_TVAL_TV_SEC is same as TVAL_TV_SEC(so as to COMPAT_TSPEC_TV_SEC and
> TSPEC_TV_SEC). I add it to keep the logic clear. I also change the version
> of vdso to 4.6. It should change to 2.6.39 if glibc is not update.
> 

[...]

Hi Bamvor,

It works for me as well. Thank you.
I'll incorporate it in next submission.

Yury.
--
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 v9 0/9] i2c mux cleanup and locking update

[Wolfram Sang]

On Wed, May 04, 2016 at 10:15:26PM +0200, Peter Rosin wrote:
> Hi!
> 
> I have a pair of boards with this i2c topology:
> 
>GPIO ---|  -- BAT1
> |  v /
>I2C  -+--B---+ MUX
>  |   \
>EEPROM -- BAT2
> 
>   (B denotes the boundary between the boards)
> 
> The problem with this is that the GPIO controller sits on the same i2c bus
> that it MUXes. For pca954x devices this is worked around by using unlocked
> transfers when updating the MUX. I have no such luck as the GPIO is a general
> purpose IO expander and the MUX is just a random bidirectional MUX, unaware
> of the fact that it is muxing an i2c bus. Extending unlocked transfers
> into the GPIO subsystem is too ugly to even think about. But the general hw
> approach is sane in my opinion, with the number of connections between the
> two boards minimized. To put it plainly, I need support for it.
> 
> So, I observe that while it is needed to have the i2c bus locked during the
> actual MUX update in order to avoid random garbage on the slave side, it
> is not strictly a must to have it locked over the whole sequence of a full
> select-transfer-deselect operation. The MUX itself needs to be locked, so
> transfers to clients behind the mux are serialized, and the MUX needs to be
> stable during all i2c traffic (otherwise individual mux slave segments
> might see garbage).
> 
> This series accomplishes this by adding code to i2c-mux-gpio and
> i2c-mux-pinctrl that determines if all involved devices used to update the
> mux are controlled by the same root i2c adapter that is muxed. When this
> is the case, the select-transfer-deselect operations should be locked
> individually to avoid the deadlock. The i2c bus *is* still locked
> during muxing, since the muxing happens as part of i2c transfers. This
> is true even if the MUX is updated with several transfers to the GPIO (at
> least as long as *all* MUX changes are using the i2c master bus). A lock
> is added to i2c adapters that muxes on that adapter grab, so that transfers
> through the muxes are serialized.
> 
> Concerns:
> - The locking is perhaps too complex?
> - I worry about the priority inheritance aspect of the adapter lock. When
>   the transfers behind the mux are divided into select-transfer-deselect all
>   locked individually, low priority transfers get more chances to interfere
>   with high priority transfers.
> - When doing an i2c_transfer() in_atomic() context or with irqs_disabled(),
>   there is a higher possibility that the mux is not returned to its idle
>   state after a failed (-EAGAIN) transfer due to trylock.
> - Is the detection of i2c-controlled gpios and pinctrls sane (i.e. the
>   usage of the new i2c_root_adapter() function in 18/24)?
> 
> The first half (patches 01-15 in v7) of what was originally part of this
> series have already been scheduled for 4.6. So, this is the second half
> (patches 16-24 in v7, patches 1-9 in v9).
> 
> To summarize the series, there is some preparatory locking changes in
> in 1/9 and the real meat is in 3/9. There is some documentation added in
> 4/9 while 5/9 and after are cleanups to existing drivers utilizing
> the new stuff.
> 
> PS. needs a bunch of testing, I do not have access to all the involved hw.
> 
> This second half of the series is planned to be merged with 4.7 and can
> also be pulled from github, if that is preferred:
> 

Applied all to for-next, thanks for keeping at it!



signature.asc
Description: PGP signature

[PATCH v9 3/9] i2c-mux: relax locking of the top i2c adapter during mux-locked muxing

[Peter Rosin]

With a i2c topology like the following

   GPIO ---|  -- BAT1
|  v /
   I2C  -+--+ MUX
 |   \
   EEPROM -- BAT2

there is a locking problem with the GPIO controller since it is a client
on the same i2c bus that it muxes. Transfers to the mux clients (e.g. BAT1)
will lock the whole i2c bus prior to attempting to switch the mux to the
correct i2c segment. In the above case, the GPIO device is an I/O expander
with an i2c interface, and since the GPIO subsystem knows nothing (and
rightfully so) about the lockless needs of the i2c mux code, this results
in a deadlock when the GPIO driver issues i2c transfers to modify the
mux.

So, observing that while it is needed to have the i2c bus locked during the
actual MUX update in order to avoid random garbage on the slave side, it
is not strictly a must to have it locked over the whole sequence of a full
select-transfer-deselect mux client operation. The mux itself needs to be
locked, so transfers to clients behind the mux are serialized, and the mux
needs to be stable during all i2c traffic (otherwise individual mux slave
segments might see garbage, or worse).

Introduce this new locking concept as "mux-locked" muxes, and call the
pre-existing mux locking scheme "parent-locked".

Modify the i2c mux locking so that muxes that are "mux-locked" locks only
the muxes on the parent adapter instead of the whole i2c bus when there is
a transfer to the slave side of the mux. This lock serializes transfers to
the slave side of the muxes on the parent adapter.

Add code to i2c-mux-gpio and i2c-mux-pinctrl that checks if all involved
gpio/pinctrl devices have a parent that is an i2c adapter in the same
adapter tree that is muxed, and request a "mux-locked mux" if that is the
case.

Modify the select-transfer-deselect code for "mux-locked" muxes so
that each of the select-transfer-deselect ops locks the mux parent
adapter individually.

Signed-off-by: Peter Rosin 
---
 drivers/i2c/i2c-core.c  |   1 +
 drivers/i2c/i2c-mux.c   | 152 +---
 drivers/i2c/muxes/i2c-mux-gpio.c|  18 +
 drivers/i2c/muxes/i2c-mux-pinctrl.c |  38 +
 include/linux/i2c-mux.h |   8 ++
 include/linux/i2c.h |   1 +
 6 files changed, 205 insertions(+), 13 deletions(-)

diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index afdee66002db..9da446162529 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -1540,6 +1540,7 @@ static int i2c_register_adapter(struct i2c_adapter *adap)
}
 
rt_mutex_init(>bus_lock);
+   rt_mutex_init(>mux_lock);
mutex_init(>userspace_clients_lock);
INIT_LIST_HEAD(>userspace_clients);
 
diff --git a/drivers/i2c/i2c-mux.c b/drivers/i2c/i2c-mux.c
index 5fa8af715e24..8eee98634cda 100644
--- a/drivers/i2c/i2c-mux.c
+++ b/drivers/i2c/i2c-mux.c
@@ -35,6 +35,25 @@ struct i2c_mux_priv {
u32 chan_id;
 };
 
+static int __i2c_mux_master_xfer(struct i2c_adapter *adap,
+struct i2c_msg msgs[], int num)
+{
+   struct i2c_mux_priv *priv = adap->algo_data;
+   struct i2c_mux_core *muxc = priv->muxc;
+   struct i2c_adapter *parent = muxc->parent;
+   int ret;
+
+   /* Switch to the right mux port and perform the transfer. */
+
+   ret = muxc->select(muxc, priv->chan_id);
+   if (ret >= 0)
+   ret = __i2c_transfer(parent, msgs, num);
+   if (muxc->deselect)
+   muxc->deselect(muxc, priv->chan_id);
+
+   return ret;
+}
+
 static int i2c_mux_master_xfer(struct i2c_adapter *adap,
   struct i2c_msg msgs[], int num)
 {
@@ -47,7 +66,29 @@ static int i2c_mux_master_xfer(struct i2c_adapter *adap,
 
ret = muxc->select(muxc, priv->chan_id);
if (ret >= 0)
-   ret = __i2c_transfer(parent, msgs, num);
+   ret = i2c_transfer(parent, msgs, num);
+   if (muxc->deselect)
+   muxc->deselect(muxc, priv->chan_id);
+
+   return ret;
+}
+
+static int __i2c_mux_smbus_xfer(struct i2c_adapter *adap,
+   u16 addr, unsigned short flags,
+   char read_write, u8 command,
+   int size, union i2c_smbus_data *data)
+{
+   struct i2c_mux_priv *priv = adap->algo_data;
+   struct i2c_mux_core *muxc = priv->muxc;
+   struct i2c_adapter *parent = muxc->parent;
+   int ret;
+
+   /* Select the right mux port and perform the transfer. */
+
+   ret = muxc->select(muxc, priv->chan_id);
+   if (ret >= 0)
+   ret = parent->algo->smbus_xfer(parent, addr, flags,
+   read_write, command, size, data);
if (muxc->deselect)
muxc->deselect(muxc, priv->chan_id);
 
@@ -68,8 +109,8 @@ static int 

[PATCH v9 9/9] [media] rtl2832: regmap is aware of lockdep, drop local locking hack

[Peter Rosin]

Tested-by: Antti Palosaari 
Reviewed-by: Antti Palosaari 
Signed-off-by: Peter Rosin 
---
 drivers/media/dvb-frontends/rtl2832.c  | 30 --
 drivers/media/dvb-frontends/rtl2832_priv.h |  1 -
 2 files changed, 31 deletions(-)

diff --git a/drivers/media/dvb-frontends/rtl2832.c 
b/drivers/media/dvb-frontends/rtl2832.c
index 957523f07f61..bfb6beedd40b 100644
--- a/drivers/media/dvb-frontends/rtl2832.c
+++ b/drivers/media/dvb-frontends/rtl2832.c
@@ -890,32 +890,6 @@ static bool rtl2832_volatile_reg(struct device *dev, 
unsigned int reg)
return false;
 }
 
-/*
- * FIXME: Hack. Implement own regmap locking in order to silence lockdep
- * recursive lock warning. That happens when regmap I2C client calls I2C mux
- * adapter, which leads demod I2C repeater enable via demod regmap. Operation
- * takes two regmap locks recursively - but those are different regmap 
instances
- * in a two different I2C drivers, so it is not deadlock. Proper fix is to make
- * regmap aware of lockdep.
- */
-static void rtl2832_regmap_lock(void *__dev)
-{
-   struct rtl2832_dev *dev = __dev;
-   struct i2c_client *client = dev->client;
-
-   dev_dbg(>dev, "\n");
-   mutex_lock(>regmap_mutex);
-}
-
-static void rtl2832_regmap_unlock(void *__dev)
-{
-   struct rtl2832_dev *dev = __dev;
-   struct i2c_client *client = dev->client;
-
-   dev_dbg(>dev, "\n");
-   mutex_unlock(>regmap_mutex);
-}
-
 static struct dvb_frontend *rtl2832_get_dvb_frontend(struct i2c_client *client)
 {
struct rtl2832_dev *dev = i2c_get_clientdata(client);
@@ -1082,12 +1056,8 @@ static int rtl2832_probe(struct i2c_client *client,
dev->sleeping = true;
INIT_DELAYED_WORK(>i2c_gate_work, rtl2832_i2c_gate_work);
/* create regmap */
-   mutex_init(>regmap_mutex);
dev->regmap_config.reg_bits =  8,
dev->regmap_config.val_bits =  8,
-   dev->regmap_config.lock = rtl2832_regmap_lock,
-   dev->regmap_config.unlock = rtl2832_regmap_unlock,
-   dev->regmap_config.lock_arg = dev,
dev->regmap_config.volatile_reg = rtl2832_volatile_reg,
dev->regmap_config.max_register = 5 * 0x100,
dev->regmap_config.ranges = regmap_range_cfg,
diff --git a/drivers/media/dvb-frontends/rtl2832_priv.h 
b/drivers/media/dvb-frontends/rtl2832_priv.h
index d8f97d14f6fd..c1a8a69e9015 100644
--- a/drivers/media/dvb-frontends/rtl2832_priv.h
+++ b/drivers/media/dvb-frontends/rtl2832_priv.h
@@ -33,7 +33,6 @@
 struct rtl2832_dev {
struct rtl2832_platform_data *pdata;
struct i2c_client *client;
-   struct mutex regmap_mutex;
struct regmap_config regmap_config;
struct regmap *regmap;
struct i2c_mux_core *muxc;
-- 
2.1.4

--
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 v9 6/9] [media] si2168: change the i2c gate to be mux-locked

[Peter Rosin]

From: Antti Palosaari 

The root i2c adapter lock is then no longer held by the i2c mux during
accesses behind the i2c gate, and such accesses need to take that lock
just like any other ordinary i2c accesses do.

So, declare the i2c gate mux-locked, and zap the code that makes the
i2c accesses unlocked. But add a mutex so that firmware commands are
still serialized.

Signed-off-by: Antti Palosaari 
Signed-off-by: Peter Rosin 
---
 Documentation/i2c/i2c-topology|  2 +-
 drivers/media/dvb-frontends/si2168.c  | 83 ---
 drivers/media/dvb-frontends/si2168_priv.h |  1 +
 3 files changed, 22 insertions(+), 64 deletions(-)

diff --git a/Documentation/i2c/i2c-topology b/Documentation/i2c/i2c-topology
index 69b008518454..5e40802f0be2 100644
--- a/Documentation/i2c/i2c-topology
+++ b/Documentation/i2c/i2c-topology
@@ -56,7 +56,7 @@ In drivers/media/
 dvb-frontends/m88ds3103   Parent-locked
 dvb-frontends/rtl2830 Parent-locked
 dvb-frontends/rtl2832 Parent-locked
-dvb-frontends/si2168  Parent-locked
+dvb-frontends/si2168  Mux-locked
 usb/cx231xx/  Parent-locked
 
 
diff --git a/drivers/media/dvb-frontends/si2168.c 
b/drivers/media/dvb-frontends/si2168.c
index 5583827c386e..108a069fa1ae 100644
--- a/drivers/media/dvb-frontends/si2168.c
+++ b/drivers/media/dvb-frontends/si2168.c
@@ -18,53 +18,23 @@
 
 static const struct dvb_frontend_ops si2168_ops;
 
-/* Own I2C adapter locking is needed because of I2C gate logic. */
-static int si2168_i2c_master_send_unlocked(const struct i2c_client *client,
-  const char *buf, int count)
-{
-   int ret;
-   struct i2c_msg msg = {
-   .addr = client->addr,
-   .flags = 0,
-   .len = count,
-   .buf = (char *)buf,
-   };
-
-   ret = __i2c_transfer(client->adapter, , 1);
-   return (ret == 1) ? count : ret;
-}
-
-static int si2168_i2c_master_recv_unlocked(const struct i2c_client *client,
-  char *buf, int count)
-{
-   int ret;
-   struct i2c_msg msg = {
-   .addr = client->addr,
-   .flags = I2C_M_RD,
-   .len = count,
-   .buf = buf,
-   };
-
-   ret = __i2c_transfer(client->adapter, , 1);
-   return (ret == 1) ? count : ret;
-}
-
 /* execute firmware command */
-static int si2168_cmd_execute_unlocked(struct i2c_client *client,
-  struct si2168_cmd *cmd)
+static int si2168_cmd_execute(struct i2c_client *client, struct si2168_cmd 
*cmd)
 {
+   struct si2168_dev *dev = i2c_get_clientdata(client);
int ret;
unsigned long timeout;
 
+   mutex_lock(>i2c_mutex);
+
if (cmd->wlen) {
/* write cmd and args for firmware */
-   ret = si2168_i2c_master_send_unlocked(client, cmd->args,
- cmd->wlen);
+   ret = i2c_master_send(client, cmd->args, cmd->wlen);
if (ret < 0) {
-   goto err;
+   goto err_mutex_unlock;
} else if (ret != cmd->wlen) {
ret = -EREMOTEIO;
-   goto err;
+   goto err_mutex_unlock;
}
}
 
@@ -73,13 +43,12 @@ static int si2168_cmd_execute_unlocked(struct i2c_client 
*client,
#define TIMEOUT 70
timeout = jiffies + msecs_to_jiffies(TIMEOUT);
while (!time_after(jiffies, timeout)) {
-   ret = si2168_i2c_master_recv_unlocked(client, cmd->args,
- cmd->rlen);
+   ret = i2c_master_recv(client, cmd->args, cmd->rlen);
if (ret < 0) {
-   goto err;
+   goto err_mutex_unlock;
} else if (ret != cmd->rlen) {
ret = -EREMOTEIO;
-   goto err;
+   goto err_mutex_unlock;
}
 
/* firmware ready? */
@@ -94,32 +63,23 @@ static int si2168_cmd_execute_unlocked(struct i2c_client 
*client,
/* error bit set? */
if ((cmd->args[0] >> 6) & 0x01) {
ret = -EREMOTEIO;
-   goto err;
+   goto err_mutex_unlock;
}
 
if (!((cmd->args[0] >> 7) & 0x01)) {
ret = -ETIMEDOUT;
-   goto err;
+   goto err_mutex_unlock;
}
}
 
+   mutex_unlock(>i2c_mutex);
return 0;
-err:
+err_mutex_unlock:
+   mutex_unlock(>i2c_mutex);
dev_dbg(>dev, "failed=%d\n", ret);
return ret;
 }

[PATCH v9 5/9] iio: imu: inv_mpu6050: change the i2c gate to be mux-locked

[Peter Rosin]

The root i2c adapter lock is then no longer held by the i2c mux during
accesses behind the i2c gate, and such accesses need to take that lock
just like any other ordinary i2c accesses do.

So, declare the i2c gate mux-locked, and zap the code that makes the
unlocked i2c accesses and just use ordinary regmap_write accesses.

This also happens to fix the deadlock described in
http://patchwork.ozlabs.org/patch/584776/ authored by
Adriana Reus  and submitted by
Daniel Baluta 

--8<--
iio: imu: inv_mpu6050: Fix deadlock between i2c adapter lock and mpu lock

This deadlock occurs if the accel/gyro and the sensor on the auxiliary
I2C (in my setup it's an ak8975) are working at the same time.

Scenario:

  T1T2
   
inv_mpu6050_read_fifo  aux sensor op (eg. ak8975_read_raw)
| |
mutex_lock(_dev->mlock)   i2c_transfer
| |
i2c transaction i2c adapter lock
| |
i2c adapter locki2c_mux_master_xfer
  |
inv_mpu6050_select_bypass
  |
mutex_lock(_dev->mlock)

When we operate on an mpu sensor the order of locking is mpu lock
followed by the i2c adapter lock. However, when we operate the auxiliary
sensor the order of locking is the other way around.

...
--8<--

The reason this patch fixes the deadlock is that T2 does not grab the
i2c adapter lock until the very end (and grabs the newfangled i2c mux
lock where it previously grabbed the i2c adapter lock).

Acked-by: Jonathan Cameron 
Acked-by: Daniel Baluta 
Tested-by: Crestez Dan Leonard 
Signed-off-by: Peter Rosin 
---
 Documentation/i2c/i2c-topology|  2 +-
 drivers/iio/imu/inv_mpu6050/inv_mpu_i2c.c | 52 ++-
 2 files changed, 11 insertions(+), 43 deletions(-)

diff --git a/Documentation/i2c/i2c-topology b/Documentation/i2c/i2c-topology
index 27bfd682808d..69b008518454 100644
--- a/Documentation/i2c/i2c-topology
+++ b/Documentation/i2c/i2c-topology
@@ -50,7 +50,7 @@ i2c-mux-pinctrl   Normally parent-locked, mux-locked 
iff
 i2c-mux-reg   Parent-locked
 
 In drivers/iio/
-imu/inv_mpu6050/  Parent-locked
+imu/inv_mpu6050/  Mux-locked
 
 In drivers/media/
 dvb-frontends/m88ds3103   Parent-locked
diff --git a/drivers/iio/imu/inv_mpu6050/inv_mpu_i2c.c 
b/drivers/iio/imu/inv_mpu6050/inv_mpu_i2c.c
index 3a078df84224..e25f7ef7f0ea 100644
--- a/drivers/iio/imu/inv_mpu6050/inv_mpu_i2c.c
+++ b/drivers/iio/imu/inv_mpu6050/inv_mpu_i2c.c
@@ -24,45 +24,16 @@ static const struct regmap_config inv_mpu_regmap_config = {
.val_bits = 8,
 };
 
-/*
- * The i2c read/write needs to happen in unlocked mode. As the parent
- * adapter is common. If we use locked versions, it will fail as
- * the mux adapter will lock the parent i2c adapter, while calling
- * select/deselect functions.
- */
-static int inv_mpu6050_write_reg_unlocked(struct i2c_client *client,
- u8 reg, u8 d)
-{
-   int ret;
-   u8 buf[2] = {reg, d};
-   struct i2c_msg msg[1] = {
-   {
-   .addr = client->addr,
-   .flags = 0,
-   .len = sizeof(buf),
-   .buf = buf,
-   }
-   };
-
-   ret = __i2c_transfer(client->adapter, msg, 1);
-   if (ret != 1)
-   return ret;
-
-   return 0;
-}
-
 static int inv_mpu6050_select_bypass(struct i2c_mux_core *muxc, u32 chan_id)
 {
-   struct i2c_client *client = i2c_mux_priv(muxc);
-   struct iio_dev *indio_dev = dev_get_drvdata(>dev);
+   struct iio_dev *indio_dev = i2c_mux_priv(muxc);
struct inv_mpu6050_state *st = iio_priv(indio_dev);
int ret = 0;
 
/* Use the same mutex which was used everywhere to protect power-op */
mutex_lock(_dev->mlock);
if (!st->powerup_count) {
-   ret = inv_mpu6050_write_reg_unlocked(client,
-st->reg->pwr_mgmt_1, 0);
+   ret = regmap_write(st->map, st->reg->pwr_mgmt_1, 0);
if (ret)
goto write_error;
 
@@ -71,10 +42,9 @@ static int inv_mpu6050_select_bypass(struct i2c_mux_core 
*muxc, u32 chan_id)
}
if (!ret) {
st->powerup_count++;
-   ret = inv_mpu6050_write_reg_unlocked(client,
-st->reg->int_pin_cfg,
- 

[PATCH v9 8/9] [media] rtl2832_sdr: get rid of empty regmap wrappers

[Peter Rosin]

Tested-by: Antti Palosaari 
Reviewed-by: Antti Palosaari 
Signed-off-by: Peter Rosin 
---
 drivers/media/dvb-frontends/rtl2832_sdr.c | 302 +-
 1 file changed, 132 insertions(+), 170 deletions(-)

diff --git a/drivers/media/dvb-frontends/rtl2832_sdr.c 
b/drivers/media/dvb-frontends/rtl2832_sdr.c
index 6a6b1debe277..47a480a7d46c 100644
--- a/drivers/media/dvb-frontends/rtl2832_sdr.c
+++ b/drivers/media/dvb-frontends/rtl2832_sdr.c
@@ -120,6 +120,7 @@ struct rtl2832_sdr_dev {
unsigned long flags;
 
struct platform_device *pdev;
+   struct regmap *regmap;
 
struct video_device vdev;
struct v4l2_device v4l2_dev;
@@ -164,47 +165,6 @@ struct rtl2832_sdr_dev {
unsigned long jiffies_next;
 };
 
-/* write multiple registers */
-static int rtl2832_sdr_wr_regs(struct rtl2832_sdr_dev *dev, u16 reg,
-   const u8 *val, int len)
-{
-   struct platform_device *pdev = dev->pdev;
-   struct rtl2832_sdr_platform_data *pdata = pdev->dev.platform_data;
-   struct regmap *regmap = pdata->regmap;
-
-   return regmap_bulk_write(regmap, reg, val, len);
-}
-
-#if 0
-/* read multiple registers */
-static int rtl2832_sdr_rd_regs(struct rtl2832_sdr_dev *dev, u16 reg, u8 *val,
-   int len)
-{
-   struct platform_device *pdev = dev->pdev;
-   struct rtl2832_sdr_platform_data *pdata = pdev->dev.platform_data;
-   struct regmap *regmap = pdata->regmap;
-
-   return regmap_bulk_read(regmap, reg, val, len);
-}
-#endif
-
-/* write single register */
-static int rtl2832_sdr_wr_reg(struct rtl2832_sdr_dev *dev, u16 reg, u8 val)
-{
-   return rtl2832_sdr_wr_regs(dev, reg, , 1);
-}
-
-/* write single register with mask */
-static int rtl2832_sdr_wr_reg_mask(struct rtl2832_sdr_dev *dev, u16 reg,
-   u8 val, u8 mask)
-{
-   struct platform_device *pdev = dev->pdev;
-   struct rtl2832_sdr_platform_data *pdata = pdev->dev.platform_data;
-   struct regmap *regmap = pdata->regmap;
-
-   return regmap_update_bits(regmap, reg, mask, val);
-}
-
 /* Private functions */
 static struct rtl2832_sdr_frame_buf *rtl2832_sdr_get_next_fill_buf(
struct rtl2832_sdr_dev *dev)
@@ -559,11 +519,11 @@ static int rtl2832_sdr_set_adc(struct rtl2832_sdr_dev 
*dev)
 
f_sr = dev->f_adc;
 
-   ret = rtl2832_sdr_wr_regs(dev, 0x13e, "\x00\x00", 2);
+   ret = regmap_bulk_write(dev->regmap, 0x13e, "\x00\x00", 2);
if (ret)
goto err;
 
-   ret = rtl2832_sdr_wr_regs(dev, 0x115, "\x00\x00\x00\x00", 4);
+   ret = regmap_bulk_write(dev->regmap, 0x115, "\x00\x00\x00\x00", 4);
if (ret)
goto err;
 
@@ -589,7 +549,7 @@ static int rtl2832_sdr_set_adc(struct rtl2832_sdr_dev *dev)
buf[1] = (u32tmp >>  8) & 0xff;
buf[2] = (u32tmp >>  0) & 0xff;
 
-   ret = rtl2832_sdr_wr_regs(dev, 0x119, buf, 3);
+   ret = regmap_bulk_write(dev->regmap, 0x119, buf, 3);
if (ret)
goto err;
 
@@ -603,15 +563,15 @@ static int rtl2832_sdr_set_adc(struct rtl2832_sdr_dev 
*dev)
u8tmp2 = 0xcd; /* enable ADC I, ADC Q */
}
 
-   ret = rtl2832_sdr_wr_reg(dev, 0x1b1, u8tmp1);
+   ret = regmap_write(dev->regmap, 0x1b1, u8tmp1);
if (ret)
goto err;
 
-   ret = rtl2832_sdr_wr_reg(dev, 0x008, u8tmp2);
+   ret = regmap_write(dev->regmap, 0x008, u8tmp2);
if (ret)
goto err;
 
-   ret = rtl2832_sdr_wr_reg(dev, 0x006, 0x80);
+   ret = regmap_write(dev->regmap, 0x006, 0x80);
if (ret)
goto err;
 
@@ -622,168 +582,169 @@ static int rtl2832_sdr_set_adc(struct rtl2832_sdr_dev 
*dev)
buf[1] = (u32tmp >> 16) & 0xff;
buf[2] = (u32tmp >>  8) & 0xff;
buf[3] = (u32tmp >>  0) & 0xff;
-   ret = rtl2832_sdr_wr_regs(dev, 0x19f, buf, 4);
+   ret = regmap_bulk_write(dev->regmap, 0x19f, buf, 4);
if (ret)
goto err;
 
/* low-pass filter */
-   ret = rtl2832_sdr_wr_regs(dev, 0x11c,
-   
"\xca\xdc\xd7\xd8\xe0\xf2\x0e\x35\x06\x50\x9c\x0d\x71\x11\x14\x71\x74\x19\x41\xa5",
-   20);
+   ret = regmap_bulk_write(dev->regmap, 0x11c,
+   
"\xca\xdc\xd7\xd8\xe0\xf2\x0e\x35\x06\x50\x9c\x0d\x71\x11\x14\x71\x74\x19\x41\xa5",
+   20);
if (ret)
goto err;
 
-   ret = rtl2832_sdr_wr_regs(dev, 0x017, "\x11\x10", 2);
+   ret = regmap_bulk_write(dev->regmap, 0x017, "\x11\x10", 2);
if (ret)
goto err;
 
/* mode */
-   ret = rtl2832_sdr_wr_regs(dev, 0x019, "\x05", 1);
+   ret = regmap_write(dev->regmap, 0x019, 0x05);
if (ret)
goto err;
 
-   ret = rtl2832_sdr_wr_regs(dev, 0x01a, "\x1b\x16\x0d\x06\x01\xff", 6);
+   ret = regmap_bulk_write(dev->regmap, 0x01a,

[PATCH v9 2/9] i2c: muxes always lock the parent adapter

[Peter Rosin]

Instead of checking for i2c parent adapters for every lock/unlock, simply
override the locking for muxes to always lock/unlock the parent adapter
directly.

Signed-off-by: Peter Rosin 
---
 drivers/i2c/i2c-core.c | 21 +++--
 drivers/i2c/i2c-mux.c  | 30 ++
 2 files changed, 33 insertions(+), 18 deletions(-)

diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index 7ef5bd085476..afdee66002db 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -962,12 +962,7 @@ static int i2c_check_addr_busy(struct i2c_adapter 
*adapter, int addr)
 static void i2c_adapter_lock_bus(struct i2c_adapter *adapter,
 unsigned int flags)
 {
-   struct i2c_adapter *parent = i2c_parent_is_i2c_adapter(adapter);
-
-   if (parent)
-   i2c_lock_adapter(parent);
-   else
-   rt_mutex_lock(>bus_lock);
+   rt_mutex_lock(>bus_lock);
 }
 
 /**
@@ -979,12 +974,7 @@ static void i2c_adapter_lock_bus(struct i2c_adapter 
*adapter,
 static int i2c_adapter_trylock_bus(struct i2c_adapter *adapter,
   unsigned int flags)
 {
-   struct i2c_adapter *parent = i2c_parent_is_i2c_adapter(adapter);
-
-   if (parent)
-   return parent->trylock_bus(parent, flags);
-   else
-   return rt_mutex_trylock(>bus_lock);
+   return rt_mutex_trylock(>bus_lock);
 }
 
 /**
@@ -996,12 +986,7 @@ static int i2c_adapter_trylock_bus(struct i2c_adapter 
*adapter,
 static void i2c_adapter_unlock_bus(struct i2c_adapter *adapter,
   unsigned int flags)
 {
-   struct i2c_adapter *parent = i2c_parent_is_i2c_adapter(adapter);
-
-   if (parent)
-   i2c_unlock_adapter(parent);
-   else
-   rt_mutex_unlock(>bus_lock);
+   rt_mutex_unlock(>bus_lock);
 }
 
 static void i2c_dev_set_name(struct i2c_adapter *adap,
diff --git a/drivers/i2c/i2c-mux.c b/drivers/i2c/i2c-mux.c
index 25e9336b0e6e..5fa8af715e24 100644
--- a/drivers/i2c/i2c-mux.c
+++ b/drivers/i2c/i2c-mux.c
@@ -98,6 +98,33 @@ static unsigned int i2c_mux_parent_classes(struct 
i2c_adapter *parent)
return class;
 }
 
+static void i2c_parent_lock_bus(struct i2c_adapter *adapter,
+   unsigned int flags)
+{
+   struct i2c_mux_priv *priv = adapter->algo_data;
+   struct i2c_adapter *parent = priv->muxc->parent;
+
+   parent->lock_bus(parent, flags);
+}
+
+static int i2c_parent_trylock_bus(struct i2c_adapter *adapter,
+ unsigned int flags)
+{
+   struct i2c_mux_priv *priv = adapter->algo_data;
+   struct i2c_adapter *parent = priv->muxc->parent;
+
+   return parent->trylock_bus(parent, flags);
+}
+
+static void i2c_parent_unlock_bus(struct i2c_adapter *adapter,
+ unsigned int flags)
+{
+   struct i2c_mux_priv *priv = adapter->algo_data;
+   struct i2c_adapter *parent = priv->muxc->parent;
+
+   parent->unlock_bus(parent, flags);
+}
+
 struct i2c_mux_core *i2c_mux_alloc(struct i2c_adapter *parent,
   struct device *dev, int max_adapters,
   int sizeof_priv, u32 flags,
@@ -165,6 +192,9 @@ int i2c_mux_add_adapter(struct i2c_mux_core *muxc,
priv->adap.retries = parent->retries;
priv->adap.timeout = parent->timeout;
priv->adap.quirks = parent->quirks;
+   priv->adap.lock_bus = i2c_parent_lock_bus;
+   priv->adap.trylock_bus = i2c_parent_trylock_bus;
+   priv->adap.unlock_bus = i2c_parent_unlock_bus;
 
/* Sanity check on class */
if (i2c_mux_parent_classes(parent) & class)
-- 
2.1.4

--
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 2/4] rpmsg: drop owner assignment from spi_drivers

[Andrew F. Davis]

On 05/04/2016 01:55 PM, Suman Anna wrote:
> On 05/04/2016 01:34 PM, Andrew F. Davis wrote:
>> An rpmsg_driver does not need to set an owner, it will be populated by
>> the driver core.
> 
> spi_drivers in patch subject??
> 

copy/paste error, this is all based on my SPI patches that do this same
thing to that subsystem. Will fix.

Thanks,
Andrew

> regards
> Suman
> 
>>
>> Signed-off-by: Andrew F. Davis 
>> ---
>>  Documentation/rpmsg.txt | 1 -
>>  samples/rpmsg/rpmsg_client_sample.c | 1 -
>>  2 files changed, 2 deletions(-)
>>
>> diff --git a/Documentation/rpmsg.txt b/Documentation/rpmsg.txt
>> index f7edc3a..1d88426 100644
>> --- a/Documentation/rpmsg.txt
>> +++ b/Documentation/rpmsg.txt
>> @@ -249,7 +249,6 @@ MODULE_DEVICE_TABLE(rpmsg, rpmsg_driver_sample_id_table);
>>  
>>  static struct rpmsg_driver rpmsg_sample_client = {
>>  .drv.name   = KBUILD_MODNAME,
>> -.drv.owner  = THIS_MODULE,
>>  .id_table   = rpmsg_driver_sample_id_table,
>>  .probe  = rpmsg_sample_probe,
>>  .callback   = rpmsg_sample_cb,
>> diff --git a/samples/rpmsg/rpmsg_client_sample.c 
>> b/samples/rpmsg/rpmsg_client_sample.c
>> index 59b1344..82ed288 100644
>> --- a/samples/rpmsg/rpmsg_client_sample.c
>> +++ b/samples/rpmsg/rpmsg_client_sample.c
>> @@ -77,7 +77,6 @@ MODULE_DEVICE_TABLE(rpmsg, rpmsg_driver_sample_id_table);
>>  
>>  static struct rpmsg_driver rpmsg_sample_client = {
>>  .drv.name   = KBUILD_MODNAME,
>> -.drv.owner  = THIS_MODULE,
>>  .id_table   = rpmsg_driver_sample_id_table,
>>  .probe  = rpmsg_sample_probe,
>>  .callback   = rpmsg_sample_cb,
>>
> 
--
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 1/4] rpmsg: add THIS_MODULE to rpmsg_driver in rpmsg core

[Suman Anna]

On 05/04/2016 01:34 PM, Andrew F. Davis wrote:
> Add register_rpmsg_driver helper macro that adds THIS_MODULE to
> rpmsg_driver for the registering driver. We rename and modify
> the existing register_rpmsg_driver to enable this.
> 
> Signed-off-by: Andrew F. Davis 

With the multi-trace comment from patch 3 squashed here properly,
Acked-by: Suman Anna 

> ---
>  drivers/rpmsg/virtio_rpmsg_bus.c | 8 +---
>  include/linux/rpmsg.h| 8 +++-
>  2 files changed, 12 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c 
> b/drivers/rpmsg/virtio_rpmsg_bus.c
> index 1fcd27c..fe03b2a 100644
> --- a/drivers/rpmsg/virtio_rpmsg_bus.c
> +++ b/drivers/rpmsg/virtio_rpmsg_bus.c
> @@ -436,17 +436,19 @@ static struct bus_type rpmsg_bus = {
>  };
>  
>  /**
> - * register_rpmsg_driver() - register an rpmsg driver with the rpmsg bus
> + * __register_rpmsg_driver() - register an rpmsg driver with the rpmsg bus
>   * @rpdrv: pointer to a struct rpmsg_driver
> + * @owner: owning module/driver
>   *
>   * Returns 0 on success, and an appropriate error value on failure.
>   */
> -int register_rpmsg_driver(struct rpmsg_driver *rpdrv)
> +int __register_rpmsg_driver(struct rpmsg_driver *rpdrv, struct module *owner)
>  {
>   rpdrv->drv.bus = _bus;
> + rpdrv->drv.owner = owner;
>   return driver_register(>drv);
>  }
> -EXPORT_SYMBOL(register_rpmsg_driver);
> +EXPORT_SYMBOL(__register_rpmsg_driver);
>  
>  /**
>   * unregister_rpmsg_driver() - unregister an rpmsg driver from the rpmsg bus
> diff --git a/include/linux/rpmsg.h b/include/linux/rpmsg.h
> index 82a6739..78e45ce 100644
> --- a/include/linux/rpmsg.h
> +++ b/include/linux/rpmsg.h
> @@ -169,7 +169,7 @@ struct rpmsg_driver {
>  
>  int register_rpmsg_device(struct rpmsg_channel *dev);
>  void unregister_rpmsg_device(struct rpmsg_channel *dev);
> -int register_rpmsg_driver(struct rpmsg_driver *drv);
> +int __register_rpmsg_driver(struct rpmsg_driver *drv, struct module *owner);
>  void unregister_rpmsg_driver(struct rpmsg_driver *drv);
>  void rpmsg_destroy_ept(struct rpmsg_endpoint *);
>  struct rpmsg_endpoint *rpmsg_create_ept(struct rpmsg_channel *,
> @@ -177,6 +177,12 @@ struct rpmsg_endpoint *rpmsg_create_ept(struct 
> rpmsg_channel *,
>  int
>  rpmsg_send_offchannel_raw(struct rpmsg_channel *, u32, u32, void *, int, 
> bool);
>  
> +/*
> + * use a macro to avoid include chaining to get THIS_MODULE
> + */
> +#define register_rpmsg_driver(drv) \
> + __register_rpmsg_driver(drv, THIS_MODULE)
> +
>  /**
>   * rpmsg_send() - send a message across to the remote processor
>   * @rpdev: the rpmsg channel
> 

--
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 3/4] rpmsg: add helper macro module_rpmsg_driver

[Suman Anna]

Hi Andrew,

On 05/04/2016 01:34 PM, Andrew F. Davis wrote:
> This patch introduces the module_rpmsg_driver macro which is a
> convenience macro for rpmsg driver modules similar to
> module_platform_driver. It is intended to be used by drivers which
> init/exit section does nothing but register/unregister the rpmsg driver.
> By using this macro it is possible to eliminate a few lines of
> boilerplate code per rpmsg driver.
> 
> Signed-off-by: Andrew F. Davis 
> ---
>  include/linux/rpmsg.h | 16 +---
>  1 file changed, 13 insertions(+), 3 deletions(-)
> 
> diff --git a/include/linux/rpmsg.h b/include/linux/rpmsg.h
> index 78e45ce..ada50ff 100644
> --- a/include/linux/rpmsg.h
> +++ b/include/linux/rpmsg.h
> @@ -177,13 +177,23 @@ struct rpmsg_endpoint *rpmsg_create_ept(struct 
> rpmsg_channel *,
>  int
>  rpmsg_send_offchannel_raw(struct rpmsg_channel *, u32, u32, void *, int, 
> bool);
>  
> -/*
> - * use a macro to avoid include chaining to get THIS_MODULE
> - */
> +/* use a macro to avoid include chaining to get THIS_MODULE */

This change does not belong to this patch, the modified lines were
introduced in patch 1, so please correct it in that patch.

regards
Suman

>  #define register_rpmsg_driver(drv) \
>   __register_rpmsg_driver(drv, THIS_MODULE)
>  
>  /**
> + * module_rpmsg_driver() - Helper macro for registering an rpmsg driver
> + * @__rpmsg_driver: rpmsg_driver struct
> + *
> + * Helper macro for rpmsg drivers which do not do anything special in module
> + * init/exit. This eliminates a lot of boilerplate.  Each module may only
> + * use this macro once, and calling it replaces module_init() and 
> module_exit()
> + */
> +#define module_rpmsg_driver(__rpmsg_driver) \
> + module_driver(__rpmsg_driver, register_rpmsg_driver, \
> + unregister_rpmsg_driver)
> +
> +/**
>   * rpmsg_send() - send a message across to the remote processor
>   * @rpdev: the rpmsg channel
>   * @data: payload of message
> 

--
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/4] rpmsg: use module_rpmsg_driver in existing drivers and examples

[Andrew F. Davis]

Existing drivers and examples are updated to use the
module_rpmsg_driver helper macro.

Signed-off-by: Andrew F. Davis 
---
 Documentation/rpmsg.txt | 14 +-
 samples/rpmsg/rpmsg_client_sample.c | 13 +
 2 files changed, 2 insertions(+), 25 deletions(-)

diff --git a/Documentation/rpmsg.txt b/Documentation/rpmsg.txt
index 1d88426..b19700c 100644
--- a/Documentation/rpmsg.txt
+++ b/Documentation/rpmsg.txt
@@ -202,7 +202,6 @@ with the payload of the inbound message).
  a pointer to a previously-registered rpmsg_driver struct.
  Returns 0 on success, and an appropriate error value on failure.
 
-
 3. Typical usage
 
 The following is a simple rpmsg driver, that sends an "hello!" message
@@ -254,18 +253,7 @@ static struct rpmsg_driver rpmsg_sample_client = {
.callback   = rpmsg_sample_cb,
.remove = rpmsg_sample_remove,
 };
-
-static int __init init(void)
-{
-   return register_rpmsg_driver(_sample_client);
-}
-module_init(init);
-
-static void __exit fini(void)
-{
-   unregister_rpmsg_driver(_sample_client);
-}
-module_exit(fini);
+module_rpmsg_driver(rpmsg_sample_client);
 
 Note: a similar sample which can be built and loaded can be found
 in samples/rpmsg/.
diff --git a/samples/rpmsg/rpmsg_client_sample.c 
b/samples/rpmsg/rpmsg_client_sample.c
index 82ed288..d0e249c9 100644
--- a/samples/rpmsg/rpmsg_client_sample.c
+++ b/samples/rpmsg/rpmsg_client_sample.c
@@ -82,18 +82,7 @@ static struct rpmsg_driver rpmsg_sample_client = {
.callback   = rpmsg_sample_cb,
.remove = rpmsg_sample_remove,
 };
-
-static int __init rpmsg_client_sample_init(void)
-{
-   return register_rpmsg_driver(_sample_client);
-}
-module_init(rpmsg_client_sample_init);
-
-static void __exit rpmsg_client_sample_fini(void)
-{
-   unregister_rpmsg_driver(_sample_client);
-}
-module_exit(rpmsg_client_sample_fini);
+module_rpmsg_driver(rpmsg_sample_client);
 
 MODULE_DESCRIPTION("Remote processor messaging sample client driver");
 MODULE_LICENSE("GPL v2");
-- 
2.8.2

--
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/4] rpmsg: drop owner assignment from spi_drivers

[Andrew F. Davis]

An rpmsg_driver does not need to set an owner, it will be populated by
the driver core.

Signed-off-by: Andrew F. Davis 
---
 Documentation/rpmsg.txt | 1 -
 samples/rpmsg/rpmsg_client_sample.c | 1 -
 2 files changed, 2 deletions(-)

diff --git a/Documentation/rpmsg.txt b/Documentation/rpmsg.txt
index f7edc3a..1d88426 100644
--- a/Documentation/rpmsg.txt
+++ b/Documentation/rpmsg.txt
@@ -249,7 +249,6 @@ MODULE_DEVICE_TABLE(rpmsg, rpmsg_driver_sample_id_table);
 
 static struct rpmsg_driver rpmsg_sample_client = {
.drv.name   = KBUILD_MODNAME,
-   .drv.owner  = THIS_MODULE,
.id_table   = rpmsg_driver_sample_id_table,
.probe  = rpmsg_sample_probe,
.callback   = rpmsg_sample_cb,
diff --git a/samples/rpmsg/rpmsg_client_sample.c 
b/samples/rpmsg/rpmsg_client_sample.c
index 59b1344..82ed288 100644
--- a/samples/rpmsg/rpmsg_client_sample.c
+++ b/samples/rpmsg/rpmsg_client_sample.c
@@ -77,7 +77,6 @@ MODULE_DEVICE_TABLE(rpmsg, rpmsg_driver_sample_id_table);
 
 static struct rpmsg_driver rpmsg_sample_client = {
.drv.name   = KBUILD_MODNAME,
-   .drv.owner  = THIS_MODULE,
.id_table   = rpmsg_driver_sample_id_table,
.probe  = rpmsg_sample_probe,
.callback   = rpmsg_sample_cb,
-- 
2.8.2

--
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/4] rpmsg: add THIS_MODULE to rpmsg_driver in rpmsg core

[Andrew F. Davis]

Add register_rpmsg_driver helper macro that adds THIS_MODULE to
rpmsg_driver for the registering driver. We rename and modify
the existing register_rpmsg_driver to enable this.

Signed-off-by: Andrew F. Davis 
---
 drivers/rpmsg/virtio_rpmsg_bus.c | 8 +---
 include/linux/rpmsg.h| 8 +++-
 2 files changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c b/drivers/rpmsg/virtio_rpmsg_bus.c
index 1fcd27c..fe03b2a 100644
--- a/drivers/rpmsg/virtio_rpmsg_bus.c
+++ b/drivers/rpmsg/virtio_rpmsg_bus.c
@@ -436,17 +436,19 @@ static struct bus_type rpmsg_bus = {
 };
 
 /**
- * register_rpmsg_driver() - register an rpmsg driver with the rpmsg bus
+ * __register_rpmsg_driver() - register an rpmsg driver with the rpmsg bus
  * @rpdrv: pointer to a struct rpmsg_driver
+ * @owner: owning module/driver
  *
  * Returns 0 on success, and an appropriate error value on failure.
  */
-int register_rpmsg_driver(struct rpmsg_driver *rpdrv)
+int __register_rpmsg_driver(struct rpmsg_driver *rpdrv, struct module *owner)
 {
rpdrv->drv.bus = _bus;
+   rpdrv->drv.owner = owner;
return driver_register(>drv);
 }
-EXPORT_SYMBOL(register_rpmsg_driver);
+EXPORT_SYMBOL(__register_rpmsg_driver);
 
 /**
  * unregister_rpmsg_driver() - unregister an rpmsg driver from the rpmsg bus
diff --git a/include/linux/rpmsg.h b/include/linux/rpmsg.h
index 82a6739..78e45ce 100644
--- a/include/linux/rpmsg.h
+++ b/include/linux/rpmsg.h
@@ -169,7 +169,7 @@ struct rpmsg_driver {
 
 int register_rpmsg_device(struct rpmsg_channel *dev);
 void unregister_rpmsg_device(struct rpmsg_channel *dev);
-int register_rpmsg_driver(struct rpmsg_driver *drv);
+int __register_rpmsg_driver(struct rpmsg_driver *drv, struct module *owner);
 void unregister_rpmsg_driver(struct rpmsg_driver *drv);
 void rpmsg_destroy_ept(struct rpmsg_endpoint *);
 struct rpmsg_endpoint *rpmsg_create_ept(struct rpmsg_channel *,
@@ -177,6 +177,12 @@ struct rpmsg_endpoint *rpmsg_create_ept(struct 
rpmsg_channel *,
 int
 rpmsg_send_offchannel_raw(struct rpmsg_channel *, u32, u32, void *, int, bool);
 
+/*
+ * use a macro to avoid include chaining to get THIS_MODULE
+ */
+#define register_rpmsg_driver(drv) \
+   __register_rpmsg_driver(drv, THIS_MODULE)
+
 /**
  * rpmsg_send() - send a message across to the remote processor
  * @rpdev: the rpmsg channel
-- 
2.8.2

--
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: Kernel docs: muddying the waters a bit

[Jonathan Corbet]

On Wed, 4 May 2016 13:50:35 -0300
Mauro Carvalho Chehab  wrote:

> Em Wed, 4 May 2016 19:13:21 +0300
> Jani Nikula  escreveu:
> > I think we should go for vanilla sphinx at first, to make the setup step
> > as easy as possible for everyone.  
> 
> Vanilla Sphinx doesn't work, as reST markup language is too limited
> to support the docs we have. So, we should either push the needed
> extensions to Sphinx reST or find a way to put it at Kernel tree
> without causing too much pain for the developers, e. g. as something
> that just doing "make htmldoc" would automatically use such extensions
> without needing to actually install the extensions.

It works for everything except the extended media book, right?  Or is there
something I'm missing here?  I am very much interested in having one system
for *all* our docs, but we wouldn't attempt to convert a document can't be
expressed in sphinx.

> > Even if it means still doing that ugly
> > docproc step to call kernel-doc. We can improve from there, and I
> > definitely appreciate your work on making this work with sphinx
> > extensions.  
> 
> I disagree: We should not cause documentation regressions by
> producing incomplete documentation and losing tables because of
> such conversion.

> The quality of the documentation after the change should be *at least*
> equal to the one we current produce, never worse.

Agreed; that's why I think the existing DocBook mechanism should stay in
place until that document will be improved by the change.  But I'd rather
not hold up the entire process for one book, especially since pushing that
process forward can only help in dealing with those final problems.

> > That said, how would it work to include the kernel-doc extension in the
> > kernel source tree? Having things just work if sphinx is installed is
> > preferred over requiring installation of something extra from pypi. (I
> > know this may sound backwards for a lot of projects, but for kernel I'm
> > pretty sure this is how it should be done.)  
> 
> Yeah, using pypi seems an additional undesired step. Aren't there
> any way to make python to use an additional extension at the
> Kernel tree without needing to install it?

Well, sphinx has to come from somewhere too.  But yes, we should be able to
carry extensions in the kernel tree.  But I would still rather upstream it
(to sphinx) if possible, so we're not stuck trying to maintain it across
several sphinx releases.  I don't know how volatile their interfaces are,
but it would be, in any case, the analog of an out-of-tree module...

jon
--
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 v7 16/24] i2c: allow adapter drivers to override the adapter locking

[Wolfram Sang]

> A question on best practices here... I already did a v8 (but only as
> a branch) so I think this will be v9, bit that's a minor detail. The
> real question is what I should do about patches 1-15 that are already
> in next? Send them too? If not, should I send 16-24 with the same old
> patch numbers or should they be numbered 1-9 now? And should such a
> shortened series be rebased on 1-15 in next?
> 
> Or does it not really matter?

Easiest for me is:

Send as v9, only the patches not yet applied, numbered from 1-9, based
on my for-next.



signature.asc
Description: PGP signature

Re: Kernel docs: muddying the waters a bit

[Mauro Carvalho Chehab]

Em Wed, 4 May 2016 08:57:13 -0600
Jonathan Corbet  escreveu:

> On Wed, 4 May 2016 16:18:27 +0200
> Daniel Vetter  wrote:
> 
> > > I'd really like to converge on the markup question, so that we can start
> > > using all the cool stuff with impunity in gpu documentations.
> > 
> > Aside: If we decide this now I could send in a pull request for the
> > rst/sphinx kernel-doc support still for 4.7 (based upon the minimal
> > markdown/asciidoc code I still have). That would be really awesome ...  
> 
> Sorry for my relative absence...I'm still busy dealing with bureaucracy
> an ocean away from home.  I hope to begin emerging from this mess in the
> near future.
> 
> So ... there's the code you have, the work I (+Jani) did, and the work
> Markus has done.  Which would you have me push into 4.7?

IMHO, Markus approach is the one that is providing a better result,
as it added support for missing features that we require for the
media DocBook.

Still, it seems premature to merge it for 4.7.

Markus is getting real progress on converting the media docs to work
with Sphynx, but there are still troubles when the table is big, as,
currently, it is truncating everything that passes the right margin
on some tables.

So, IMHO, the next action item would be to be sure that big tables 
will not be truncated. Assuming that he can fix that in time, we
can merge it for 4.8, and then start porting the documentation to
use it.

Btw, converting the DocBook/media Makefile will require an extra
step, as part of the documentation is generated via scripts (some
C file examples, and include/uapi headers). Those scripts also
warrant that (almost) every API at include/uapi is synchronized
with the DocBook. I use this on my patch review process, in order
to reject patches that don't add the proper documentation updates.

Thanks,
Mauro
--
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: Kernel docs: muddying the waters a bit

[Daniel Vetter]

On Wed, May 4, 2016 at 5:02 PM, Daniel Vetter  wrote:
> On Wed, May 04, 2016 at 08:57:13AM -0600, Jonathan Corbet wrote:
>> On Wed, 4 May 2016 16:18:27 +0200
>> Daniel Vetter  wrote:
>>
>> > > I'd really like to converge on the markup question, so that we can start
>> > > using all the cool stuff with impunity in gpu documentations.
>> >
>> > Aside: If we decide this now I could send in a pull request for the
>> > rst/sphinx kernel-doc support still for 4.7 (based upon the minimal
>> > markdown/asciidoc code I still have). That would be really awesome ...
>>
>> Sorry for my relative absence...I'm still busy dealing with bureaucracy
>> an ocean away from home.  I hope to begin emerging from this mess in the
>> near future.
>>
>> So ... there's the code you have, the work I (+Jani) did, and the work
>> Markus has done.  Which would you have me push into 4.7?
>>
>> The sphinx/rst approach does seem, to me, to be the right one, with the
>> existing DocBook structure remaining in place for those who want/need
>> it.  I'm inclined toward my stuff as a base to work with, obviously :) But
>> it's hackish at best and needs a lot of cleaning up.  It's a proof of
>> concept, but it's hardly finished (one might say it's barely begun...)
>>
>> In the end, I guess, I feel that anything we might try to push for 4.7 is
>> going to look rushed and not ready, and Linus might react accordingly.
>> I'd be more comfortable aiming for 4.8.  I *will* have more time to focus
>> on things in that time frame...  I suspect you're pretty well fed up with
>> this stuff being pushed back, and rightly so.  All I can do is apologize.
>>
>> That said, if you do think there's something out there that is good
>> enough to consider pushing in a week or two, do tell and we can all take
>> a look.
>
> Well I'd just have taken the asciidoc hacks I have currently in my
> topic/kerneldoc branch, converted to sphinx and looked how it fares. It
> should be fairly minimal, and I think the first step we want to do for the
> long-term plan. I hope I can ready something, and then we can look whether
> it's rushed for 4.7 or not.

Ok, discussed this a bit more with Jani on IRC and he really doesn't
like the old design of that branch (it calls the converter for every
kerneldoc comment). So I guess nothing rushed for 4.7, but hopefully
something for 4.8.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
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: Kernel docs: muddying the waters a bit

[Mauro Carvalho Chehab]

Em Wed, 4 May 2016 11:34:08 +0200
Markus Heiser  escreveu:

> Hi all, (hi Jonathan, please take note of my offer below)
> 
> Am 03.05.2016 um 16:31 schrieb Daniel Vetter :
> 
> > Hi all,
> > 
> > So sounds like moving ahead with rst/sphinx is the option that should
> > allow us to address everyone's concerns eventually? Of course the
> > first one won't have it all (media seems really tricky), ...  
> 
> BTW: Mauro mentioned that ASCII-art tables are not diff-friendly ... 
> 
> Am 18.04.2016 um 13:16 schrieb Mauro Carvalho Chehab 
> :
> 
> > With that sense, the "List tables" format is also not good, as
> > one row addition would generate several hunks (one for each column
> > of the table), making harder to review the patch by just looking at
> > the diff.  
> 
> For this, I wrote the "flat-table" reST-directive, which adds 
> missing cells automatically:
> 
> doc:
> http://return42.github.io/sphkerneldoc/articles/table_concerns.html#flat-table
> source: 
> https://github.com/return42/sphkerneldoc/blob/master/doc/extensions/rstFlatTable.py

Yeah, this should address the lack of a proper way to markup cell/row
spans, providing the additional bits for the tables we have at media.

Yet, there are some issues with table conversions. See below.

> 
> I used "flat-table" to migrate all DocBook-XML documents to reST. With this
> directive, I also managed to migrate the complete media book (no more TODOs)
> incl. the large tables like them from subdev-formats:
> 
> https://return42.github.io/sphkerneldoc/books/linux_tv/media/v4l/subdev-formats.html
> 
> (Rendering large tables is a general discussion which should not take place 
> in this MT)

Some tables, like the one here:

https://return42.github.io/sphkerneldoc/books/linux_tv/media/v4l/control.html

are truncated (tested with Mozilla and Chrome), and part of the information is
lost due to that.

Regards,
Mauro
--
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: Kernel docs: muddying the waters a bit

[Jani Nikula]

On Wed, 04 May 2016, Markus Heiser  wrote:
> Correct my, if I'am wrong. I'am a bit unfamiliar with DOCPROC in
> particular with your "MARKDOWNREADY := gpu.xml" process.
>
> As I understood, you convert markdown to docbook within the kernel-doc 
> script using pandoc's executable? ... I don't face this topic. With my 
> modification of kernel-doc I produced pure reST markup from standardize
> kernel-doc markup, no intermediate steps or tools required.

That pandoc thing is a dead end. Forget about it. I think we've all
pretty much agreed we should have kernel-doc produce the lightweight
markup directly since [1].

[1] http://mid.gmane.org/1453106477-21359-1-git-send-email-jani.nik...@intel.com

> Am 04.05.2016 um 17:09 schrieb Jonathan Corbet :
>
>> I think all of this makes sense.  It would be really nice to have the
>> directives in the native sphinx language like that.  I *don't* think we
>> need to aim for that at the outset; the docproc approach works until we can
>> properly get rid of it.  What would be *really* nice would be to get
>> support for the kernel-doc directive into the sphinx upstream.
>
> No need for kernel-doc directive in sphinx upstream, later it will be 
> an extension which could be installed by a simple command like 
> "pip install kernel-doc-extensions" or similar.
>
> I develop these required extension (and more) within my proof of concept
> on github ... this takes time ... if I finished all my tests and all is
> well, I will build the *kernel-doc-extensions* package and deploy it
> on https://pypi.python.org/pypi from where everyone could install this 
> with "pip".

I think we should go for vanilla sphinx at first, to make the setup step
as easy as possible for everyone. Even if it means still doing that ugly
docproc step to call kernel-doc. We can improve from there, and I
definitely appreciate your work on making this work with sphinx
extensions.

That said, how would it work to include the kernel-doc extension in the
kernel source tree? Having things just work if sphinx is installed is
preferred over requiring installation of something extra from pypi. (I
know this may sound backwards for a lot of projects, but for kernel I'm
pretty sure this is how it should be done.)

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center
--
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: Kernel docs: muddying the waters a bit

[Markus Heiser]

Am 04.05.2016 um 15:43 schrieb Daniel Vetter :

> On Wed, May 04, 2016 at 02:40:29PM +0200, Markus Heiser wrote:
>>> On Wed, 04 May 2016, Markus Heiser  wrote:
>>> I'd be *very* hesitant about adding the kind of things you do in
>>> reformat_block_rst to kernel-doc. IMO the extraction from kernel-doc
>>> comments must be as simple as possible with basically pass-through of
>>> the comment blocks to sphinx.
>> 
>> Right, but you forgot, that the current markup in the source code comments
>> is based on the  kernel-doc-nano-HOWTO and I guess no one will migrate all
>> these source code comments to reST markup ;-)
>> 
>> So there is a need to differentiate between *vintage* kernel-doc markup 
>> and reST markup.
>> 
>> My suggestion is to add a tag to the comments, here a short example
>> what this might look like.
>> 
>>  --
>> /**
>> * drm_minor_release - Release DRM minor
>> * @minor: Pointer to DRM minor object
>> *
>> * Release a minor that was previously acquired via drm_minor_acquire().
>> */
>>  --
>> 
>> in short: the vintage style does not need any change and 
>> comments with reST markup has a tag ":reST:" in the first 
>> line(s) ...
>> 
>>  --
>> /**
>> * :reST:
>> *
>> * .. c:function:: void drm_minor_release(struct drm_minor *minor)
>> *
>> *Release DRM minor
>> *
>> *:param struct drm_minor \*minor: Pointer to DRM minor object
>> *
>> */
>>  --
>> 
>> Comments with the ":reST:" tag could be exported and pass-through
>> to sphinx.
>> 
>>> Specifically, do not attempt to detect and
>>> parse elements like lists in kernel-doc.
>> 
>> If your markup in the comments is plain reST, no need to parse, but there
>> are markups in the (vintage) comments which made use of individual 
>> text-markups, e.g. the markup of lists or ASCII-art. 
>> 
>> This individual text-markups has not been converted/rendered in the docbook
>> output, but I wanted to convert this individuals to reST, to render them in
>> Sphinx.
> 
> I think we need to unconfuse what's current standardize kerneldoc markup.
> There's three bits:
> - The header with the one-liner and parameters, i.e.

OK, forget my  example, I don't really want to promote
this way ... I agree, it is better to stay with standardize kernel-doc markup
and provide a "pass through" for the section-content (even if it is mixing 
markups).

Am 04.05.2016 um 15:41 schrieb Jani Nikula :

> Kernel-doc the tool should continue to parse kernel-doc comments at the
> high level like they currently are, according to the kernel-doc
> howto. 

The requirement was unclear for me, thanks to Daniel and 
Jani for clarifying this.


Am 04.05.2016 um 15:43 schrieb Daniel Vetter :

> This is already used widely in kerneldoc included by gpu.tmpl, and
> currently it's asciidoc. Those lists and asciiarts though are _not_
> standard kerneldoc at all. But imo any doc toolchain improvement should
> integrate along those lines.
> 
> For reference, this is what it's supposed to look like with the asciidoc
> support enabled:
> 
> https://dri.freedesktop.org/docs/drm/API-struct-drm-display-mode.html
> 
> Fyi those hacked-up patches to make this happen are available in
> 
> https://cgit.freedesktop.org/drm-intel/log/?h=topic/kerneldoc
> 

Correct my, if I'am wrong. I'am a bit unfamiliar with DOCPROC in
particular with your "MARKDOWNREADY := gpu.xml" process.

As I understood, you convert markdown to docbook within the kernel-doc 
script using pandoc's executable? ... I don't face this topic. With my 
modification of kernel-doc I produced pure reST markup from standardize
kernel-doc markup, no intermediate steps or tools required.

Am 04.05.2016 um 15:41 schrieb Jani Nikula :

> Overall I think we should promote fixing those in the kernel-doc
> comments. Trying to guesswork in kernel-doc tool will leave the source
> littered with bad examples that get proliferated all around. Instead of
> gradually fixing things, we'll end up gradually messing things up even
> more.

I agree with you, lets drop the reformat_block_rst from my kernel-doc script:

* https://github.com/return42/sphkerneldoc/blob/master/scripts/kernel-doc#L1736

and we should have a plain "pass through".

Am 04.05.2016 um 17:09 schrieb Jonathan Corbet :

> I think all of this makes sense.  It would be really nice to have the
> directives in the native sphinx language like that.  I *don't* think we
> need to aim for that at the outset; the docproc approach works until we can
> properly get rid of it.  What would be *really* nice would be to get
> support for the kernel-doc directive into the sphinx upstream.

No need for kernel-doc directive in sphinx upstream, later it will be 
an extension which could be installed by a simple command like 
"pip install kernel-doc-extensions" or similar.

I develop these required extension (and more) within my proof of 

Re: Kernel docs: muddying the waters a bit

[Jani Nikula]

On Wed, 04 May 2016, Jonathan Corbet  wrote:
> The sphinx/rst approach does seem, to me, to be the right one, with the
> existing DocBook structure remaining in place for those who want/need
> it.  I'm inclined toward my stuff as a base to work with, obviously :) But
> it's hackish at best and needs a lot of cleaning up.  It's a proof of
> concept, but it's hardly finished (one might say it's barely begun...)

Thanks. I'll start looking at how to make it less hackish and more
upstreamable.

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Technology Center
--
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: Kernel docs: muddying the waters a bit

[Daniel Vetter]

On Wed, May 04, 2016 at 08:57:13AM -0600, Jonathan Corbet wrote:
> On Wed, 4 May 2016 16:18:27 +0200
> Daniel Vetter  wrote:
> 
> > > I'd really like to converge on the markup question, so that we can start
> > > using all the cool stuff with impunity in gpu documentations.  
> > 
> > Aside: If we decide this now I could send in a pull request for the
> > rst/sphinx kernel-doc support still for 4.7 (based upon the minimal
> > markdown/asciidoc code I still have). That would be really awesome ...
> 
> Sorry for my relative absence...I'm still busy dealing with bureaucracy
> an ocean away from home.  I hope to begin emerging from this mess in the
> near future.
> 
> So ... there's the code you have, the work I (+Jani) did, and the work
> Markus has done.  Which would you have me push into 4.7?
> 
> The sphinx/rst approach does seem, to me, to be the right one, with the
> existing DocBook structure remaining in place for those who want/need
> it.  I'm inclined toward my stuff as a base to work with, obviously :) But
> it's hackish at best and needs a lot of cleaning up.  It's a proof of
> concept, but it's hardly finished (one might say it's barely begun...)
> 
> In the end, I guess, I feel that anything we might try to push for 4.7 is
> going to look rushed and not ready, and Linus might react accordingly.
> I'd be more comfortable aiming for 4.8.  I *will* have more time to focus
> on things in that time frame...  I suspect you're pretty well fed up with
> this stuff being pushed back, and rightly so.  All I can do is apologize.
> 
> That said, if you do think there's something out there that is good
> enough to consider pushing in a week or two, do tell and we can all take
> a look.

Well I'd just have taken the asciidoc hacks I have currently in my
topic/kerneldoc branch, converted to sphinx and looked how it fares. It
should be fairly minimal, and I think the first step we want to do for the
long-term plan. I hope I can ready something, and then we can look whether
it's rushed for 4.7 or not.

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
--
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: Kernel docs: muddying the waters a bit

[Jonathan Corbet]

On Wed, 4 May 2016 16:18:27 +0200
Daniel Vetter  wrote:

> > I'd really like to converge on the markup question, so that we can start
> > using all the cool stuff with impunity in gpu documentations.  
> 
> Aside: If we decide this now I could send in a pull request for the
> rst/sphinx kernel-doc support still for 4.7 (based upon the minimal
> markdown/asciidoc code I still have). That would be really awesome ...

Sorry for my relative absence...I'm still busy dealing with bureaucracy
an ocean away from home.  I hope to begin emerging from this mess in the
near future.

So ... there's the code you have, the work I (+Jani) did, and the work
Markus has done.  Which would you have me push into 4.7?

The sphinx/rst approach does seem, to me, to be the right one, with the
existing DocBook structure remaining in place for those who want/need
it.  I'm inclined toward my stuff as a base to work with, obviously :) But
it's hackish at best and needs a lot of cleaning up.  It's a proof of
concept, but it's hardly finished (one might say it's barely begun...)

In the end, I guess, I feel that anything we might try to push for 4.7 is
going to look rushed and not ready, and Linus might react accordingly.
I'd be more comfortable aiming for 4.8.  I *will* have more time to focus
on things in that time frame...  I suspect you're pretty well fed up with
this stuff being pushed back, and rightly so.  All I can do is apologize.

That said, if you do think there's something out there that is good
enough to consider pushing in a week or two, do tell and we can all take
a look.

Thanks,

jon
--
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: Kernel docs: muddying the waters a bit

[Daniel Vetter]

On Wed, May 4, 2016 at 3:43 PM, Daniel Vetter  wrote:
> I'd really like to converge on the markup question, so that we can start
> using all the cool stuff with impunity in gpu documentations.

Aside: If we decide this now I could send in a pull request for the
rst/sphinx kernel-doc support still for 4.7 (based upon the minimal
markdown/asciidoc code I still have). That would be really awesome ...

Jon?

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
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 v7 16/24] i2c: allow adapter drivers to override the adapter locking

[Wolfram Sang]

Hi Peter,

thanks for the detailed explanation!

> So maybe there should be only one flag, e.g. I2C_LOCK_ROOT_ADAPTER?
> I.e. perhaps leave the future for later?

I think this makes the current code easier understandable at this point,
but I'll leave the decision to you. I am fine with both. Maybe a few
words of explanation would be good if you want to keep both flags.

> Hmmm, I just now realized that you were not really suggesting any
> changes other than to the commit message. Oh well, I can perhaps
> rephrase some of the above in the commit message if you think that
> we should not unnecessarily touch the code at this point...

Yes, updated commit description is enough for me now. If you want to
change to one flag, we should do it incrementally. I think I can apply
this as a fixup until around rc3 I'd say.

> > I think this kerneldoc should be moved to i2c_lock_adapter and/or
> > i2c_lock_bus() which are now in i2c.h. This is what users will use, not
> > this static, adapter-specific implementation. I think it is enough to
> > have a comment here explaining what is special in handling adapters.
> 
> Yes, I was not really satisfied with having documentation on static
> functions. But if I move it, there is no natural home for the current
> i2c_trylock_adapter docs, and I'd hate killing documentation that
> still applies. Do you have a suggestion? Maybe keep that one doc at
> the static i2c_trylock_adapter for now and move it to ->trylock_bus
> when someone decides to write kerneldoc for struct i2c_adapter?

Well, because I think redundancy is acceptable when it comes to
documentation, how about keeping the chunks you already have and copy an
adapted one over to the functions in i2c.h?

Regards,

   Wolfram



signature.asc
Description: PGP signature

Re: [PATCH 0/6] Intel Secure Guard Extensions

[Pavel Machek]

Hi!

> Good morning, I hope everyone's day is starting out well.

:-). Rainy day here.

> > > In the TL;DR department I would highly recommend that anyone
> > > interested in all of this read MIT's 170+ page review of the
> > > technology before jumping to any conclusions :-)
> 
> > Would you have links for 1-5?
> 
> First off my apologies to the list as I loathe personal inaccuracy,
> the MIT review paper is only 117 pages long.  I was typing the last
> e-mail at 0405 in the morning and was scrambling for the opportunity
> to get 50 minutes of sleep so my proofreading was sloppy... :-)

Thanks a lot for the links, I'd still say it was more accurate than
average for the lkml.

Best regards,
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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: [PATCH 0/6] Intel Secure Guard Extensions

[Dr. Greg Wettstein]

On Tue, May 03, 2016 at 05:38:40PM +0200, Pavel Machek wrote:

> Hi!

Good morning, I hope everyone's day is starting out well.

> > I told my associates the first time I reviewed this technology that
> > SGX has the ability to be a bit of a Pandora's box and it seems to be
> > following that course.

> Can you elaborate on the Pandora's box? System administrator should
> be able to disable SGX on the system, and use system to do anything
> that could be done with the older CPUs, right?

Correct, there is certainly the on/off switch.

I viewed it as a Pandora's box secondary to the fact that it was the
first commodity based shrouded TEE that had the opportunity for
significant market penetration.  As such and secondary to its
technical characteristics, it has the potential for both good and bad
and like TXT in the last decade it was/is bound to induce significant
debate secondary to software freedom and potential monopolistic
practices.

> > Intel is obviously cognizant of the risk surrounding illicit uses of
> > this technology since it clearly calls out that, by agreeing to have
> > their key signed, a developer agrees to not implement nefarious or
> > privacy invasive software.  Given the known issues that Certificate

> Yeah, that's likely to work ... not :-(. "It is not spyware, it is
> just collecting some anonymous statistics."

The notion that an enclave can look out but could not be looked into
introduces privacy issues into the conversation, see my reflections on
Pandoras box... :-)

> > domination and control.  They probably have enough on their hands with
> > attempting to convert humanity to FPGA's and away from devices which
> > are capable of maintaining a context of exection... :-)

> Heh. FPGAs are not designed to replace CPUs anytime soon... And
> probably never.

Never is a long time.

Intel has clearly drawn a very significant line in the sand with
respect to FPGA technology if you read Krzanich's reflections
regarding his re-organization of Intel.  Whether or not they are
successful, they are going to declare a demarcation point with respect
to IOT devices which has the potential to impact the industry in
general and security in particular.  On one side are going to be FPGA
based devices and on the other side devices with a context of
execution.

I doesn't require a long stretch of the imagination to see hordes of
IOT devices with specific behaviors burned into them which export
sensor or telemetry data upstream.  Depending on how successful they
are with the Altera acquisition there are potentially positive
economic security factors which could be in play.

All of that is certainly not a conversation specific to SGX though.

> > In the TL;DR department I would highly recommend that anyone
> > interested in all of this read MIT's 170+ page review of the
> > technology before jumping to any conclusions :-)

> Would you have links for 1-5?

First off my apologies to the list as I loathe personal inaccuracy,
the MIT review paper is only 117 pages long.  I was typing the last
e-mail at 0405 in the morning and was scrambling for the opportunity
to get 50 minutes of sleep so my proofreading was sloppy... :-)

The following should provide ample bedstand reading material for those
interested in SGX and TEE's:

1.) HASP/SGX paper:
https://software.intel.com/sites/default/files/article/413939/hasp-2013-innovative-technology-for-attestation-and-sealing.pdf

2.) IAGO threat model:
https://cseweb.ucsd.edu/~hovav/dist/iago.pdf

3.) Haven paper:
http://research.microsoft.com/pubs/223450/osdi2014-haven.pdf

4.) Controlled sidechannel attacks:
http://research.microsoft.com/pubs/246400/ctrlchannels-oakland-2015.pdf

https://software.intel.com/en-us/blogs/2015/05/19/look-both-ways-and-watch-out-for-side-channels

5.) MIT/SGX analysis:
https://eprint.iacr.org/2016/086.pdf

> Thanks,
>   Pavel

No problem, enjoy the reading :-)

Have a good day.

Greg

As always,
Dr. G.W. Wettstein, Ph.D.   Enjellic Systems Development, LLC.
4206 N. 19th Ave.   Specializing in information infra-structure
Fargo, ND  58102development.
PH: 701-281-1686
FAX: 701-281-3949   EMAIL: g...@enjellic.com
--
"One problem with monolithic business structures is losing sight
 of the fundamental importance of mathematics.  Consider committees;
 commonly forgotten is the relationship that given a projection of N
 individuals to complete an assignment the most effective number of
 people to assign to the committee is given by f(N) = N - (N-1)."
-- Dr. G.W. Wettstein
   Guerrilla Tactics for Corporate Survival
--
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: [RESEND PATCH 1/3] rfkill: Create "rfkill-airplane-mode" LED trigger

[Pavel Machek]

Hi!

> This creates a new LED trigger to be used by platform drivers as a
> default trigger for airplane-mode indicator LEDs.
> 
> By default this trigger will fire when RFKILL_OP_CHANGE_ALL is called
> for all types (RFKILL_TYPE_ALL), setting the LED brightness to LED_FULL
> when the changing the state to blocked, and to LED_OFF when the changing
> the state to unblocked. In the future there will be a mechanism for
> userspace to override the default policy, so it can implement its
> own.

If userspace wants to control the manually, it can do just that --
control it manually. There should not be a need to "override the
default policy".
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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