On Tue, May 03, 2016 at 10:00:17AM +0100, Richard W.M. Jones wrote:
> Running self-tests for a short-lived KVM VM takes 28ms on my laptop.
> This commit adds a flag 'cryptomgr.notests' which allows them to be
> disabled.
>
> However if fips=1 as well, we ignore this flag as FIPS mode mandates
> th
On Wed, May 4, 2016 at 7:24 PM, Zhangjian (Bamvor)
wrote:
> 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 wi
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
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 end
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
>
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/r
Existing drivers and examples are updated to use the
module_rpmsg_driver helper macro.
Signed-off-by: Andrew F. Davis
---
Documentation/rpmsg.txt | 13 +
samples/rpmsg/rpmsg_client_sample.c | 13 +
2 files changed, 2 insertions(+), 24 deletions(-)
diff --git
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/r
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 elim
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,
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
> | \
>EEPRO
Add i2c_lock_bus() and i2c_unlock_bus(), which call the new lock_bus and
unlock_bus ops in the adapter. These funcs/ops take an additional flags
argument that indicates for what purpose the adapter is locked.
There are two flags, I2C_LOCK_ROOT_ADAPTER and I2C_LOCK_SEGMENT, but they
are both implem
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 boar
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 i
Signed-off-by: Peter Rosin
---
Documentation/i2c/i2c-topology | 370 +
MAINTAINERS| 1 +
2 files changed, 371 insertions(+)
create mode 100644 Documentation/i2c/i2c-topology
diff --git a/Documentation/i2c/i2c-topology b/Documentation
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/rt
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 unlo
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 regmap overrides
that makes the i2c accesses unlocked and use
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 ordina
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
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 ++
On 05/04/2016 01:54 PM, Suman Anna wrote:
> 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
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
th
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 fr
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??
regards
Suman
>
> Signed-off-by: Andrew F. Davis
> ---
> Documentation/rpmsg.txt | 1 -
> samples/rpmsg/rpmsg_c
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/unre
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/r
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
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 elim
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
Em Wed, 4 May 2016 10:59:36 -0600
Jonathan Corbet escreveu:
> 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 pos
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 languag
Em Wed, 4 May 2016 19:13:21 +0300
Jani Nikula escreveu:
> 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 th
> 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 numb
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 d
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 w
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'
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 t
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-d
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 need
On Wed, 04 May 2016 16:41:50 +0300
Jani Nikula wrote:
> On Wed, 04 May 2016, Markus Heiser wrote:
> > In reST the directive might look like:
> >
> > -
> > Device Instance and Driver Handling
> > ===
> >
> > .. kernel-doc:: drivers/gpu/drm/drm_drv.c
> >:d
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
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
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 f
On 2016-05-03 23:39, Wolfram Sang wrote:
>> Yes, they look like reasonable complaints.
>
> Thanks for fixing them. I just sent out my latest comments and when you
> fix those and send V8, I'll apply that right away. I think we are safe
> to fix the rest incrementally if needed. Note that I didn'
On Wed, 04 May 2016, Markus Heiser wrote:
>> What do you mean by ".tmpl workflow"?
>
> Sorry for bad naming, I addressed the DOCPROC build process which builds
> the .xml files from .tmpl files ...
Yeah, I know more about this part than I care. I was just wondering what
you refer to with that in
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
Hi Jani,
Am 04.05.2016 um 11:58 schrieb Jani Nikula :
> On Wed, 04 May 2016, Markus Heiser wrote:
>> but I think this will not by very helpful, as long as you miss
>> a similar ".tmpl" workflow for reST documents.
>>
>> I'am working on a reST directive (named: "kernel-doc") to provide a
>> sim
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
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 h
Hi!
On 2016-05-03 23:38, Wolfram Sang wrote:
> On Wed, Apr 20, 2016 at 05:17:56PM +0200, Peter Rosin wrote:
>> Add i2c_lock_bus() and i2c_unlock_bus(), which call the new lock_bus and
>> unlock_bus ops in the adapter. These funcs/ops take an additional flags
>> argument that indicates for what pur
On Wed, 04 May 2016, Markus Heiser wrote:
> but I think this will not by very helpful, as long as you miss
> a similar ".tmpl" workflow for reST documents.
>
> I'am working on a reST directive (named: "kernel-doc") to provide a
> similar ".tmpl" workflow within plain reST. The first step towards
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 se
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 cours
On 05/03/2016 05:04 AM, changbin...@intel.com wrote:
> From: "Du, Changbin"
>
> 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
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
56 matches
Mail list logo
