Hi!
> In preparation for temporarily marking pages not present during a
> transition between encrypted and decrypted, use slow_virt_to_phys()
> in the hypervisor callback. As long as the PFN is correct,
This seems to be preparation for something we don't plan to do in
-stable. Please drop.
Best
Hi!
> > > - Need to validate the uAPI and document it before moving
> > >this driver out of staging.
> >
> > > - Stabilize and document its sysfs interface.
> >
> > Would you mind starting with this one?
>
> Do you mean writing the ABI document for it? Surely I can do that,
> but I
Hi!
> - Need to validate the uAPI and document it before moving
>this driver out of staging.
> - Stabilize and document its sysfs interface.
Would you mind starting with this one? We should have existing APIs
for most of functionality described...
We really don't want to merge code wit
Hi!
> > There's currently 6 filesystems that have the same #define. Move it
> > into errno.h so it's defined in just one place.
> >
> > Signed-off-by: Valdis Kletnieks
> > Acked-by: Darrick J. Wong
> > Reviewed-by: Jan Kara
> > Acked-by: Theodore Ts'o
>
> > fs/erofs/internal.h
Hi!
> > No. gdb tells you what the actual offsets _are_.
>
> Ok, reading your reply twice, I think we have different perspectives. I
> don't trust the comments.
>
> The tool I had in mind is pahole that parses dwarf information about the
> structures, the same as gdb does. The actual value of th
Hi!
> > > Rather than they didn't run "gdb" or "pahole" and change it by mistake.
> >
> > I think Christoph is not right here.
> >
> > Using external tools for validation is extra work
> > when necessary for understanding the code.
>
> The advantage of using the external tools that the informat
Hi!
> > +struct erofs_super_block {
> > +/* 0 */__le32 magic; /* in the little endian */
> > +/* 4 */__le32 checksum;/* crc32c(super_block) */
> > +/* 8 */__le32 features;/* (aka. feature_compat) */
> > +/* 12 */__u8 blkszbits; /* support block_size == PAGE_SIZ
Hi!
> The Greybus code has long been "stable" but was living in the
> drivers/staging/ directory to see if there really was going to be
> devices using this protocol over the long-term. With the success of
> millions of phones with this hardware and code in it, and the recent
So, what phones do
Hi!
> > > + /*
> > > + * on-disk error, let's only BUG_ON in the debugging mode.
> > > + * otherwise, it will return 1 to just skip the invalid name
> > > + * and go on (in consideration of the lookup performance).
> > > + */
> > > + DBG_BUGON(qd->name > qd->end);
> >
> > I believe you should
Hi!
> + /*
> + * on-disk error, let's only BUG_ON in the debugging mode.
> + * otherwise, it will return 1 to just skip the invalid name
> + * and go on (in consideration of the lookup performance).
> + */
> + DBG_BUGON(qd->name > qd->end);
I believe you should check f
Hi!
> >> Changelog from v1:
> >> o resend the whole filesystem into a patchset suggested by Greg;
> >> o code is more cleaner, especially for decompression frontend.
> >>
> >> --8<--
> >>
> >> Hi,
> >>
> >> EROFS file system has been in Linux-staging for about a year.
> >> It has been pr
On Thu 2019-07-11 22:57:31, Gao Xiang wrote:
> Changelog from v1:
> o resend the whole filesystem into a patchset suggested by Greg;
> o code is more cleaner, especially for decompression frontend.
>
> --8<--
>
> Hi,
>
> EROFS file system has been in Linux-staging for about a year.
> I
On Wed 2019-06-19 17:46:48, Lukas Schneider wrote:
> This patch fixes the issue reported by checkpatch:
>
> CHECK: usleep_range is preferred over udelay;
> see Doucmentation/timers/timers-howto.txt
>
> It's save to sleep here instead of using busy waiting,
> because we are not in an atomic contex
Hi!
> Use the gpiod interface instead of the deprecated old non-descriptor
> interface in olpc_dcon_xo_1.c.
>
> Signed-off-by: Nishad Kamdar
You may want to cc: lkund...@v3.sk, he was doing great work on OLPC
lately...
Best regards,
On Mon 2018-11-19 11:16:15, David Hildenbrand wrote:
> Let's use pfn_to_online_page() instead of pfn_to_page() when checking
> for saveable pages to not save/restore offline memory sections.
>
> Cc: "Rafael J. Wysocki"
Acked-by: Pavel Machek
--
(english)
Hi!
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> >
> > Easy to maintain when it's sorted.
No / it dep
On Wed 2018-11-14 22:17:04, David Hildenbrand wrote:
> The content of pages that are marked PG_offline is not of interest
> (e.g. inflated by a balloon driver), let's skip these pages.
>
> Cc: "Rafael J. Wysocki"
Acked-by: Pavel Machek
> diff --git a/kernel/p
On Wed 2018-10-10 19:23:00, Lubomir Rintel wrote:
> The battery and the protocol are essentially the same as OLPC XO 1.5,
> but the responses from the EC are LSB first.
>
> Signed-off-by: Lubomir Rintel
Acked-by: Pavel Machek
--
(english) http://www.livejournal.com/~pavelm
On Wed 2018-10-10 19:22:59, Lubomir Rintel wrote:
> This wouldn't work on the DT-based ARM platform. Let's read the EC version
> directly from the EC driver instead.
>
> This makes the driver no longer x86 specific.
>
> Signed-off-by: Lubomir Rintel
Acked-by: Pavel
Hi!
> The global variables for private data are not too nice. I'd like some
> more, and that would clutter the global name space even further.
>
> Signed-off-by: Lubomir Rintel
> Reviewed-by: Andy Shevchenko
Ok...
> - olpc_bat = power_supply_register(&pdev->dev, &olpc_bat_desc, NULL);
> -
On Wed 2018-10-10 19:22:57, Lubomir Rintel wrote:
> Avoid using the x86 OLPC platform specific call to get the board
> version. It won't work on FDT-based ARM MMP2 platform.
>
> Signed-off-by: Lubomir Rintel
> Reviewed-by: Andy Shevchenko
Acked-by: Pavel Machek
AFAICT, th
On Wed 2018-10-10 19:22:56, Lubomir Rintel wrote:
> The XO-1 and XO-1.5 batteries apparently differ in an ability to report
> ambient temperature. Add a different compatible string to the 1.5
> battery.
>
> Signed-off-by: Lubomir Rintel
Acked-by: Pavel Machek
> ---
> a
On Wed 2018-10-10 19:22:55, Lubomir Rintel wrote:
> The XO-1 and XO-1.5 batteries apparently differ in an ability to report
> ambient temperature.
>
> Signed-off-by: Lubomir Rintel
> Reviewed-by: Rob Herring
Acked-by: Pavel Machek
Rob, can you
On Wed 2018-10-10 19:22:53, Lubomir Rintel wrote:
> It is actually plaform independent. Move it to the olpc-ec driver from
> the X86 OLPC platform, so that it could be used by the ARM based laptops
> too.
>
> Signed-off-by: Lubomir Rintel
Acked-by: Pavel Machek
--
On Wed 2018-10-10 19:22:52, Lubomir Rintel wrote:
> Just return ENODEV, so that whoever attempted to use the EC call can
> defer their work.
>
> Signed-off-by: Lubomir Rintel
Acked-by: Pavel Machek
> ---
> drivers/platform/olpc/olpc-ec.c | 7 +--
> 1 file change
On Wed 2018-10-10 19:22:50, Lubomir Rintel wrote:
> There are ARM OLPC machines that use mostly the same drivers, including
> EC infrastructure, DCON and Battery.
>
> While at that, fix Kconfig to allow building this as a module.
>
> Signed-off-by: Lubomir Rintel
Acke
On Wed 2018-10-10 19:22:49, Lubomir Rintel wrote:
> Also, the header is x86 specific, while there are non-x86 OLPC machines.
>
> Signed-off-by: Lubomir Rintel
Acked-by: Pavel Machek
> ---
> drivers/platform/olpc/olpc-ec.c | 1 -
> 1 file changed, 1 deletion(-)
>
&
and when does it wish to respond with a command (the
> cmd-gpio property).
>
> Signed-off-by: Lubomir Rintel
Acked-by: Pavel Machek
> ---
> .../bindings/misc/olpc,xo1.75-ec.txt | 24 +++
> 1 file changed, 24 insertions(+)
> create mode 100644
On Wed 2018-10-10 19:22:47, Lubomir Rintel wrote:
> It doesn't make sense to always have this built-in, e.g. on ARM
> multiplatform kernels. A better way to address the problem the original
> commit aimed to solve is to fix Kconfig.
>
> This reverts commit f48d1496b8537d75776478c6942dd87f34d7f270.
temperature: 236.9 degrees C
>
> Tested on OLPC XO-1 and OLPC XO-1.75 laptops.
>
> [1] include/linux/power_supply.h
> [2] Documentation/power/power_supply_class.txt
>
> Cc: sta...@vger.kernel.org
> Signed-off-by: Lubomir Rintel
Acked-by: Pavel Machek
&g
Hi!
> On Tue, Jul 25, 2017 at 02:30:31PM +0200, Johan Hovold wrote:
> > [ +CC: Rui and Greg ]
>
> Thanks Johan. I only got this because of you.
> > > return ret;
> > > }
> >
> > And while it's fine to take this through linux-media, it would still be
> > good to keep the maintainers on CC.
>
On Tue 2017-06-20 08:05:05, Fabio Estevam wrote:
> On Tue, Jun 20, 2017 at 5:29 AM, Pavel Machek wrote:
>
> > Hmm. I changed the subject to grab Shawn's attetion.
> >
> > But his acks should not be needed for forward progress. Yes, it would
> > be good, but h
Hi!
> >> But as Pavel pointed out, in fact we are missing many
> >> Acks still, for all of the dts source changes (patches
> >> 4-14), as well as really everything else (imx-media staging
> >> driver patches).
> >
> > No Acks needed for the staging part. It's staging, so not held
> > to the same
Hi!
> >> Other than that everything is ready AFAICT.
> >>
> >
> > But as Pavel pointed out, in fact we are missing many
> > Acks still, for all of the dts source changes (patches
> > 4-14), as well as really everything else (imx-media staging
> > driver patches).
>
> No Acks needed for the stagi
Hi!
> >>>Steve,
> >>>
> >>>You need to remove the fim node now that you've moved this to V4L2
> >>>controls.
> >>>
> >>
> >>Yep, I caught this just after sending the v8 patchset. I'll send
> >>a v9 of this patch.
> >
> >This needs ack from devicetree people, then it can be merged. Can you
> >be a
On Thu 2017-06-08 13:36:12, Steve Longerbeam wrote:
>
>
> On 06/08/2017 01:25 PM, Tim Harvey wrote:
> >
> >
> >Steve,
> >
> >You need to remove the fim node now that you've moved this to V4L2 controls.
> >
>
> Yep, I caught this just after sending the v8 patchset. I'll send
> a v9 of this patch.
Hi!
> > > According to the docs V4L2_CID_EXPOSURE_ABSOLUTE is in 100 usec units.
> > >
> > > OTOH V4L2_CID_EXPOSURE has no defined unit, so it's a better fit IMO.
> > > >Way more drivers appear to be using EXPOSURE than EXPOSURE_ABSOLUTE, too.
> > >
> > > Done, switched to V4L2_CID_EXPOSURE. It
Hi!
> >>>+ /* Auto/manual exposure */
> >>>+ ctrls->auto_exp = v4l2_ctrl_new_std_menu(hdl, ops,
> >>>+ V4L2_CID_EXPOSURE_AUTO,
> >>>+ V4L2_EXPOSURE_MANUAL, 0,
> >>>+ V4L2
Hi!
> > > + /* Auto/manual exposure */
> > > + ctrls->auto_exp = v4l2_ctrl_new_std_menu(hdl, ops,
> > > + V4L2_CID_EXPOSURE_AUTO,
> > > + V4L2_EXPOSURE_MANUAL, 0,
> > > + V4L2
Hi!
> >If there's a need for this (there should not be, as the controls are exposed
> >to the user space through the sub-device nodes as the other drivers do), the
> >framework APIs need to be extended.
>
> Right, this gets back to the media framework usability arguments. At least
> myself, Phili
Hi!
> +/* min/typical/max system clock (xclk) frequencies */
> +#define OV5640_XCLK_MIN 600
> +#define OV5640_XCLK_MAX 2400
> +
> +/*
> + * FIXME: there is no subdev API to set the MIPI CSI-2
> + * virtual channel yet, so this is hardcoded for now.
> + */
> +#define OV5640_MIPI_VC 1
Hi!
> That self-referencing mux-controls property looks a bit superfluous:
>
> mux: video-multiplexer {
> mux-controls = <&mux>;
> };
>
> Other than that, I'm completely fine with splitting the compatible into
> something like video-mux-gpio and video-mux-mmio and reusi
Hi!
> > The MUX framework is already in linux-next. Could you use that instead of
> > adding new driver + bindings that are not compliant with the MUX framework?
> > I don't think it'd be much of a change in terms of code, using the MUX
> > framework appears quite simple.
>
> It is not quite clea
On Wed 2017-04-05 13:58:39, Lucas Stach wrote:
> Am Mittwoch, den 05.04.2017, 13:18 +0200 schrieb Pavel Machek:
> > Hi!
> >
> > > + * video stream multiplexer controlled via gpio or syscon
> > > + *
> > > + * Copyright (C) 2013 Pengutronix, Sascha Hauer
Hi!
> +References
> +--
> +
> +[1] "i.MX 6Dual/6Quad Applications Processor Reference Manual"
> +[2] "i.MX 6Solo/6DualLite Applications Processor Reference Manual"
[2] is not present in the text above. [1] is there many times. What is
purpose of this section?
Hi!
> +https://boundarydevices.com/products/nit6x_5mp
I'd use /product/ in url, as it redirects there.
> +https://boundarydevices.com/product/nit6x_5mp_mipi
..and for consistency.
> +The following example configures a direct conversion pipeline to capture
> +from the OV5640, transmitting on M
Hi!
> + * video stream multiplexer controlled via gpio or syscon
> + *
> + * Copyright (C) 2013 Pengutronix, Sascha Hauer
> + * Copyright (C) 2016 Pengutronix, Philipp Zabel
This is actually quite interesting. Same email address for two
people...
Plus, I believe this wants to say that copyrigh
Hi!
> > I do agree with you that MC places a lot of burden on the user to
> > attain a lot of knowledge of the system's architecture.
>
> Setting up the pipeline is not the hard part. One could write a
> script to do that.
Can you try to write that script? I believe it would solve big part of
t
Hi!
> > Making use of the full potential of the hardware requires using a more
> > expressive interface.
>
> That's the core of the problem: most users don't need "full potential
> of the hardware". It is actually worse than that: several boards
> don't allow "full potential" of the SoC capabili
On Mon 2017-03-20 11:30:08, Greg KH wrote:
> On Mon, Mar 20, 2017 at 11:20:32AM +0100, Pavel Machek wrote:
> > Hi!
> >
> > > > > Hah! That's the joy of being a maintainer of a driver in staging.
> > > > > Even
> > > > >
Hi!
> > > Hah! That's the joy of being a maintainer of a driver in staging. Even
> > > if you filter out outreachy, you are going to get a lot of "basic
> > > mistakes" and other type patches cc:ed to you.
> > >
> > > I strongly suggest, that if you all don't like this type of stuff,
> > > eithe
On Fri 2017-03-17 11:42:03, Russell King - ARM Linux wrote:
> On Tue, Mar 14, 2017 at 08:55:36AM +0100, Hans Verkuil wrote:
> > We're all very driver-development-driven, and userspace gets very little
> > attention in general. So before just throwing in the towel we should take
> > a good look at t
Hi!
>
> Hah! That's the joy of being a maintainer of a driver in staging. Even
> if you filter out outreachy, you are going to get a lot of "basic
> mistakes" and other type patches cc:ed to you.
>
> I strongly suggest, that if you all don't like this type of stuff,
> either:
> - work to
Hi!
> > > > mplayer is useful for testing... but that one already works (after you
> > > > setup the pipeline, and configure exposure/gain).
> > > >
> > > > But thats useful for testing, not really for production. Image will be
> > > > out of focus and with wrong white balance.
> > > >
> > > > W
Hi!
> > Well, I believe first question is: what applications would we want to
> > run on complex devices? Will sending control from video to subdevs
> > actually help?
>
> I would say: camorama, xawtv3, zbar, google talk, skype. If it runs
> with those, it will likely run with any other applicati
Hi!
> > > Even if they were merged, if we keep the same mean time to develop a
> > > libv4l plugin, that would mean that a plugin for i.MX6 could take 2-3
> > > years to be developed.
> > >
> > > There's a clear message on it:
> > > - we shouldn't keep pushing for a solution via libv4l.
> >
On Mon 2017-03-13 10:45:38, Russell King - ARM Linux wrote:
> On Mon, Mar 13, 2017 at 11:02:34AM +0100, Hans Verkuil wrote:
> > On 03/11/2017 07:14 PM, Steve Longerbeam wrote:
> > > The event must be user visible, otherwise the user has no indication
> > > the error, and can't correct it by stream
Hi!
> > Mid-layer is difficult... there are _hundreds_ of possible
> > pipeline setups. If it should live in kernel or in userspace is a
> > question... but I don't think having it in kernel helps in any way.
>
> Mid-layer is difficult, because we either need to feed some
> library with knowledge
On Sat 2017-03-11 23:14:56, Russell King - ARM Linux wrote:
> On Sat, Mar 11, 2017 at 08:25:49AM -0300, Mauro Carvalho Chehab wrote:
> > This situation is there since 2009. If I remember well, you tried to write
> > such generic plugin in the past, but never finished it, apparently because
> > it i
On Sun 2017-03-12 07:37:45, Russell King - ARM Linux wrote:
> On Sat, Mar 11, 2017 at 07:31:18PM -0800, Steve Longerbeam wrote:
> >
> >
> > On 03/11/2017 10:59 AM, Russell King - ARM Linux wrote:
> > >On Sat, Mar 11, 2017 at 10:54:55AM -0800, Steve Longerbeam wrote:
> > >>
> > >>
> > >>On 03/11/2
Hi!
> > > The rationale is that we should support the simplest use cases first.
> > >
> > > In the case of the first MC-based driver (and several subsequent
> > > ones), the simplest use case required MC, as it was meant to suport
> > > a custom-made sophisticated application that required fine c
Hi!
> > > Ok, perhaps supporting both subdev API and V4L2 API at the same
> > > time doesn't make much sense. We could disable one in favor of the
> > > other, either at compilation time or at runtime.
> >
> > Right. If the subdev API is disabled, then you have to inherit the subdev
> > control
Hi!
> >>I tend to agree with that.
> >
> >I agree as well.
> >
> >This is in line with how existing drivers behave, too.
>
>
> Well, sounds like there is consensus on this topic. I guess I'll
> go ahead and remove the control inheritance support. I suppose
> having a control appear in two places
Hi!
> diff --git a/include/uapi/media/Kbuild b/include/uapi/media/Kbuild
> index aafaa5a..fa78958 100644
> --- a/include/uapi/media/Kbuild
> +++ b/include/uapi/media/Kbuild
> @@ -1 +1,2 @@
> # UAPI Header export list
> +header-y += imx.h
> diff --git a/include/uapi/media/imx.h b/include/uapi/medi
On Fri 2017-03-10 10:37:21, Steve Longerbeam wrote:
> Hi Hans,
>
> On 03/10/2017 04:03 AM, Hans Verkuil wrote:
> >On 10/03/17 05:52, Steve Longerbeam wrote:
> >>Add a new FRAME_INTERVAL_ERROR event to signal that a video capture or
> >>output device has measured an interval between the reception o
On Fri 2017-03-10 16:17:28, Fabio Estevam wrote:
> On Fri, Mar 10, 2017 at 3:59 PM, Troy Kisky
> wrote:
> > On 3/9/2017 8:52 PM, Steve Longerbeam wrote:
> >> There is a pin conflict with GPIO_6. This pin functions as a power
> >> input pin to the OV5642 camera sensor, but ENET uses it as the h/w
>
Hi!
> Argh! that is indeed a bug at libv4l (and maybe at gstreamer).
>
> I guess that the always_needs_conversion logic was meant to be used to
> really odd proprietary formats, e. g:
>
> /* Vendor-specific formats */
> #define V4L2_PIX_FMT_CPIA1v4l2_fourcc('C', 'P', 'I', 'A') /* cp
Hi!
> > Plus you might want to describe which port correspond to which gpio
> > state/bitfield values...
> >
> > > +struct vidsw {
> >
> > I knew it: it is secretely a switch! :-).
>
> This driver started as a two-input gpio controlled bus switch.
> I changed the name when adding support for bi
Hi!
> From: Philipp Zabel
>
> This driver can handle SoC internal and external video bus multiplexers,
> controlled either by register bit fields or by a GPIO. The subdevice
> passes through frame interval and mbus configuration of the active input
> to the output side.
>
> Signed-off-by: Sasch
On Wed 2017-02-15 18:19:16, Steve Longerbeam wrote:
> v4l2_pipeline_inherit_controls() will add the v4l2 controls from
> all subdev entities in a pipeline to a given video device.
>
> Signed-off-by: Steve Longerbeam
Reviewed-by: Pavel Machek
--
(english) http://www.liv
_ENT_F_MUX``
And you probably want to rename it here, too.
With that fixed:
Reviewed-by: Pavel Machek
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
signature.asc
Description: Digital sig
Hi!
> Some drivers that include phy.h defined LED_OFF which conflicts with
> definition in leds.h. phy led support uses leds.h so the two namespaces are no
> longer isolated.
> The first two patches fix the two net drivers that declared enum constants
> that
> conflict with enum constants in linu
gt;
> v2: take in Eric suggestions for the Documentation
>
> v3: really take in Eric suggestions
>
> Signed-off-by: Gustavo Padovan
> Reviewed-by: Eric Engestrom
Acked-by: Pavel Machek
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karl
On Tue 2016-08-09 08:04:54, Daniel Vetter wrote:
> On Sun, Jul 24, 2016 at 05:00:31PM +0200, Pavel Machek wrote:
> > On Mon 2016-08-08 16:08:12, Gustavo Padovan wrote:
> > > 2016-08-07 Pavel Machek :
> > >
> > > > On Sun 2016-07-24 15:21:11, Greg Kroah-
On Mon 2016-08-08 18:24:17, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> SW_SYNC should never be used by other pieces of the kernel apart from
> sync_debug as it is only a Sync File Validation Framework, so hide any
> info to avoid confuse this with a standard kernel internal API.
> Signed
On Mon 2016-08-08 16:08:12, Gustavo Padovan wrote:
> 2016-08-07 Pavel Machek :
>
> > On Sun 2016-07-24 15:21:11, Greg Kroah-Hartman wrote:
> > > On Mon, Jul 18, 2016 at 04:12:45PM -0300, Gustavo Padovan wrote:
> > > > Hi,
> > > >
> > &g
On Sun 2016-07-24 15:21:11, Greg Kroah-Hartman wrote:
> On Mon, Jul 18, 2016 at 04:12:45PM -0300, Gustavo Padovan wrote:
> > Hi,
> >
> > Do you think there is time to get this in for 4.8?
>
> No, it was too late on my end, due to travel and vacation, sorry. I'll
> queue it up for 4.9-rc1.
Could
Hi!
> From: Gustavo Padovan
>
> Hi Greg,
>
> This is the last step in the Sync Framwork de-stage task. It
Typo: "fram_e_work"
> de-stage
> the SW_SYNC validation framework and the sync_debug info debugfs file.
>
> The first 3 patches are clean up and improvements and the rest is preparation
On Fri 2016-05-06 01:52:04, Jarkko Sakkinen wrote:
> On Mon, May 02, 2016 at 11:37:52AM -0400, Austin S. Hemmelgarn wrote:
> > On 2016-04-29 16:17, Jarkko Sakkinen wrote:
> > >On Tue, Apr 26, 2016 at 09:00:10PM +0200, Pavel Machek wrote:
> > >>On Mon 2016-04-25 2
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!
> We have been following and analyzing this technology since the first
> HASP paper was published detailing its development. We have been
(1)
>
> 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
> fo
Hi!
> -}
> -EXPORT_SYMBOL(sync_file_merge);
> -
> static const char *android_fence_get_driver_name(struct fence *fence)
> {
> struct sync_timeline *parent = fence_parent(fence);
if this is meant to be used outside android, should it select some
better prefix than android_fence_?
Thanks,
On Wed 2016-04-27 13:27:08, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> struct sync_merge_data already have documentation on top of the
> struct definition. No need to duplicate it.
>
> Signed-off-by: Gustavo Padovan
> Reviewed-by: Maarten Lankhorst
> @@ -33,8 +33,8 @@ struct sync_merg
Hi!
On Fri 2016-04-29 23:17:44, Jarkko Sakkinen wrote:
> On Tue, Apr 26, 2016 at 09:00:10PM +0200, Pavel Machek wrote:
> > On Mon 2016-04-25 20:34:07, Jarkko Sakkinen wrote:
> > > The firmware uses PRMRR registers to reserve an area of physical memory
> > > called Encl
Hi!
> > > Preventing cold boot attacks is really just icing on the cake. The
> > > real point of this is to allow you to run an "enclave". An SGX
> > > enclave has unencrypted code but gets access to a key that only it can
> > > access. It could use that key to unwrap your ssh private key and s
On Tue 2016-04-26 21:59:52, One Thousand Gnomes wrote:
> > But... that will mean that my ssh will need to be SGX-aware, and that
> > I will not be able to switch to AMD machine in future. ... or to other
> > Intel machine for that matter, right?
>
> I'm not privy to AMD's CPU design plans.
>
> Ho
Hi!
> >> >> The firmware uses PRMRR registers to reserve an area of physical memory
> >> >> called Enclave Page Cache (EPC). There is a hardware unit in the
> >> >> processor called Memory Encryption Engine. The MEE encrypts and decrypts
> >> >> the EPC pages as they enter and leave the processor
On Tue 2016-04-26 12:05:48, Andy Lutomirski wrote:
> On Tue, Apr 26, 2016 at 12:00 PM, Pavel Machek wrote:
> > On Mon 2016-04-25 20:34:07, Jarkko Sakkinen wrote:
> >> Intel(R) SGX is a set of CPU instructions that can be used by
> >> applications to set aside priva
On Mon 2016-04-25 20:34:07, Jarkko Sakkinen wrote:
> Intel(R) SGX is a set of CPU instructions that can be used by
> applications to set aside private regions of code and data. The code
> outside the enclave is disallowed to access the memory inside the
> enclave by the CPU access control.
>
> Th
Hi!
> > Of course, the maintainer gets the last word regardless of what anyone
> > else thinks.
> >
> > Generally, minimal code is better. Trying to future proof code is a
> > waste of time because you can't predict what will happen in the future.
> > It's way more likely that some pointer you n
Hi!
> > +++ b/drivers/fpga/fpga-mgr.c
> > @@ -0,0 +1,382 @@
> [..]
> > +int fpga_mgr_buf_load(struct fpga_manager *mgr, u32 flags, const char *buf,
> > + size_t count)
> > +{
> > + struct device *dev = &mgr->dev;
> > + int ret;
> > +
> > + if (!mgr)
> > + return -EN
On Thu 2015-08-13 12:37:29, at...@opensource.altera.com wrote:
> From: Alan Tull
>
> Add a document spelling out usage of the simple fpga bus.
>
> Signed-off-by: Alan Tull
Acked-by: Pavel Machek
On Thu 2015-08-13 12:37:27, at...@opensource.altera.com wrote:
> From: Alan Tull
>
> API to support programming FPGA.
I'd do s/fpga/FPGA/ in the comments, too. Otherwise looks ok to me.
Acked-by: Pavel Machek
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, p
FPGA bridges are seen as reset controllers so no special
> framework for FPGA bridges will need to be added.
>
> This supports fpga use where hardware blocks on a fpga will need
> drivers (as opposed to fpga used as an acceleration without drivers.)
>
> Signed-off-by:
On Thu 2015-08-13 12:37:30, at...@opensource.altera.com wrote:
> From: Alan Tull
>
> New bindings document for simple fpga bus.
>
> Signed-off-by: Alan Tull
Acked-by: Pavel Machek
> + onchip_memory2_0:
On Fri 2015-07-24 07:39:15, atull wrote:
> On Fri, 24 Jul 2015, Pavel Machek wrote:
>
> Hi Pavel,
>
> Thanks for your your feedback in cleaning up these docs.
>
> > Hi!
> >
> > > +What:/sys/class/fpga_manager//state
> > > +Date:
Hi!
> +What:/sys/class/fpga_manager//state
> +Date:July 2015
> +KernelVersion: 4.2
> +Contact: Alan Tull
> +Description: Read fpga manager state as a string.
fpga->FPGA.
> + Valid states may vary by manufacturer; superset is:
> +
On Fri 2015-07-17 10:51:12, at...@opensource.altera.com wrote:
> From: Alan Tull
>
> Add a document spelling out usage of the simple fpga bus.
> +The DT overlay includes bindings (documented in bindings/simple-fpga-bus.txt)
> +that specify:
> + * Which fpga manager to use
fpga->FPGA, globally.
On Fri 2015-07-17 10:51:11, at...@opensource.altera.com wrote:
> From: Alan Tull
>
> Add a document on the new FPGA manager core.
>
> --- /dev/null
> +++ b/drivers/staging/fpga/Documentation/fpga-mgr.txt
> @@ -0,0 +1,117 @@
> + FPGA Manager Core
> +
> + Alan Tull 2015
> +
> + Overview
> + -
> +Optional properties:
> +- fpga-mgr : should contain a phandle to a fpga manager.
fpga->FPGA, globally.
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
devel
1 - 100 of 155 matches
Mail list logo
