From: Luis R. Rodriguez mcg...@suse.com
This driver uses the same area for MTRR as for the ioremap().
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take
On Thu, Jun 25, 2015 at 09:38:01AM +1000, Benjamin Herrenschmidt wrote:
On Wed, 2015-06-24 at 15:29 -0700, Luis R. Rodriguez wrote:
Nope but at least what made me squint at this being a possible
feature was that in practice when reviewing all of the kernels
pending device drivers using
From: Luis R. Rodriguez mcg...@suse.com
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also ensure the ioremap'd area is requested
From: Luis R. Rodriguez mcg...@suse.com
The driver doesn't use mtrr_add() or arch_phys_wc_add() but
since we know the framebuffer is isolated already on an
ioremap() we can take advantage of write combining for
performance where possible.
In this case there are a few motivations
From: Luis R. Rodriguez mcg...@suse.com
This driver uses strong UC for the MMIO region, and ioremap_wc()
for the framebuffer to whitelist for the WC MTRR what can be changed
to WC. On PAT systems we don't need the MTRR call so just use
arch_phys_wc_add() there, this lets us remove all those
From: Luis R. Rodriguez mcg...@suse.com
This driver uses the same area for MTRR as for the ioremap().
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take
From: Luis R. Rodriguez mcg...@suse.com
Replace a WC MTRR call followed by a UC MTRR hole call
with a single WC MTRR call and use strong UC to protect
the MMIO region and account for the device's architecture
and MTRR size requirements.
The atyfb driver relies on two overlapping MTRRs. It
does
From: Luis R. Rodriguez mcg...@suse.com
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also ensure the ioremap'd area is requested
On Tue, Jun 16, 2015 at 12:40 PM, Luis R. Rodriguez
mcg...@do-not-panic.com wrote:
From: Luis R. Rodriguez mcg...@suse.com
dma_alloc_writecombine()'s call and return value check is tangled in all
in one call. Detangle both calls as we're used to.
Signed-off-by: Luis R. Rodriguez mcg
On Wed, Jun 24, 2015 at 5:52 PM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
On Thu, 2015-06-25 at 02:08 +0200, Luis R. Rodriguez wrote:
OK thanks I'll proceed with these patches then.
As for user mappings,
Which APIs were you considering in this regard BTW?
mmap
From: Luis R. Rodriguez mcg...@suse.com
Boris,
This patchset is part of the long haul of series that addresses removal of
direct use of MTRR and transforms drivers over to use PAT interfaces when
available [0]. Other than this series there is only one more pending series for
that effort
On Fri, Jun 19, 2015 at 3:22 PM, Luis R. Rodriguez mcg...@suse.com wrote:
Tomi, Dave, Andy,
Its' been one month now since posting the last unmodified version
(other than commit log) of this series [0] and no word or follow up
from Ville. The merge window is closing in and other than the PCI
From: Luis R. Rodriguez mcg...@suse.com
PCI BARs tell us whether prefetching is safe, but they don't say anything
about write combining (WC). WC changes ordering rules and allows writes to
be collapsed, so it's not safe in general to use it on a prefetchable
region.
Add pci_iomap_wc
From: Luis R. Rodriguez mcg...@suse.com
Andrew,
Forgive me for the TL;DR, I'm afraid I need to be crystal clear on this
patchset as its the most complex in the entire series. The skinny is that this
patchset addresses a complex work around with APIs now merged upstream going in
for v4.2
From: Luis R. Rodriguez mcg...@suse.com
This lets drivers take advantage of PAT when available. This
should help with the transition of converting video drivers over
to ioremap_wc() to help with the goal of eventually using
_PAGE_CACHE_UC over _PAGE_CACHE_UC_MINUS on x86 on
ioremap_nocache
From: Luis R. Rodriguez mcg...@suse.com
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also ensure the ioremap'd area is requested
From: Luis R. Rodriguez mcg...@suse.com
Now that we have pci_iomap_wc() add the respective
devres helpers. These go unexported for now but
note that should they later be exported this
must go with EXPORT_SYMBOL_GPL().
Cc: Toshi Kani toshi.k...@hp.com
Cc: Andy Lutomirski l...@amacapital.net
Cc
From: Luis R. Rodriguez mcg...@suse.com
This has no functional changes, it just adjusts
the ioremap() call for the framebuffer to use
the same values we later use for the framebuffer,
this will make it easier to review the next change.
The size of the framebuffer varies but since this is
for PCI
On Wed, Jun 24, 2015 at 08:42:23AM +1000, Benjamin Herrenschmidt wrote:
On Fri, 2015-06-19 at 15:08 -0700, Luis R. Rodriguez wrote:
From: Luis R. Rodriguez mcg...@suse.com
PCI BARs tell us whether prefetching is safe, but they don't say anything
about write combining (WC). WC changes
On Tue, Jun 23, 2015 at 12:39 AM, Ingo Molnar mi...@kernel.org wrote:
Same observation as for the other patch: please only warn if the hardware is
present and the driver tries to activate. No need to annoy others.
Will fix, and respin.
Luis
--
To unsubscribe from this list: send the line
On Fri, Jun 26, 2015 at 9:17 AM, Marciniszyn, Mike
mike.marcinis...@intel.com wrote:
Doug,
We have been given the go ahead to start the deprecation process for thie
ipath driver.
That's great! Do you mean removal from Linux?
What do I need to do to get that done?
Feature removal txt file
From: Luis R. Rodriguez mcg...@suse.com
On built-in kernels this warning will always splat as this is part
of the module init. Fix that by shifting the PAT requirement check
out under the code that does the quasi-probe for the device. This
device driver relies on an existing driver to find its
From: Luis R. Rodriguez mcg...@suse.com
The 0-day robot found that the notpat requirement warning was
being triggered on the ivtv driver on the module init path,
that will always trigger on built-in devices. We want that warning
to trigger only if real hardware is found so this moves the ivtv
From: Luis R. Rodriguez mcg...@suse.com
WARN() may confuse users, fix that. ipath_init_one() is part the
device's probe so this would only be triggered if a corresponding
device was found.
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
drivers/infiniband/hw/ipath/ipath_driver.c | 6
On Fri, Jun 26, 2015 at 08:51:58AM +1000, Benjamin Herrenschmidt wrote:
On Thu, 2015-06-25 at 21:40 +, Casey Leedom wrote:
Hhmmm, so what do PowerPC Drivers do when they want to take
advantage of Write Combining? Do their own Endian Swizzling
with the __raw_*() APIs?
Yeah either, we
On Fri, Jun 26, 2015 at 4:54 PM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
On Fri, 2015-06-26 at 15:41 -0700, Luis R. Rodriguez wrote:
It wasn't nullified for the main user at the time, the fb. And I
mentioned an IB adapter or two for which the code had been hand
tuned
From: Luis R. Rodriguez mcg...@suse.com
We are burrying direct access to MTRR code support on
x86 in order to take advantage of PAT. In the future we
also want to make the default behaviour of ioremap_nocache()
to use strong UC, use of mtrr_add() on those systems
would make write-combining void
On Thu, Jun 11, 2015 at 10:49:59AM -0700, Luis R. Rodriguez wrote:
From: Luis R. Rodriguez mcg...@suse.com
Mauro,
since the ivtv patch is already acked by the driver maintainer
and depends on an x86 symbol that went through Boris' tree are you
OK in it going through Boris' tree?
Sorry I
From: Luis R. Rodriguez mcg...@suse.com
Boris,
the following patches make use of the newly exported pat_enabled()
which went in through your tree. All driver and respective subsystem
maintainers have Acked these patches and are OK for them to go in through
your tree. Please let me know
From: Luis R. Rodriguez mcg...@suse.com
We are burrying direct access to MTRR code support on
x86 in order to take advantage of PAT. In the future we
also want to make the default behaviour of ioremap_nocache()
to use strong UC, use of mtrr_add() on those systems
would make write-combining void
From: Luis R. Rodriguez mcg...@suse.com
There is no good reason not to, we eventually delete it as well.
Cc: Toshi Kani toshi.k...@hp.com
Cc: Roland Dreier rol...@kernel.org
Cc: Sean Hefty sean.he...@intel.com
Cc: Hal Rosenstock hal.rosenst...@gmail.com
Cc: Suresh Siddha sbsid...@gmail.com
Cc
The series to bury direct MTRR use is almost all in and on its way to
v4.2. As the pending series continue slowly to be merged I wanted to
take the time to reiterate the justification for these changes in
hopes it may help those still reviewing some of these patches which
are pending and to help
From: Luis R. Rodriguez mcg...@suse.com
dma_alloc_writecombine()'s call and return value check is tangled in all
in one call. Detangle both calls as we're used to.
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
drivers/dma/iop-adma.c | 9 +
1 file changed, 5 insertions(+), 4
On Thu, May 28, 2015 at 5:36 PM, Luis R. Rodriguez
mcg...@do-not-panic.com wrote:
On Wed, May 27, 2015 at 1:04 PM, Luis R. Rodriguez mcg...@suse.com wrote:
On Tue, May 26, 2015 at 12:40:08PM -0500, Bjorn Helgaas wrote:
On Fri, May 22, 2015 at 02:23:41AM +0200, Luis R. Rodriguez wrote:
On Thu
On Mon, Jun 8, 2015 at 4:43 PM, Luis R. Rodriguez mcg...@suse.com wrote:
On Wed, Jun 3, 2015 at 4:50 PM, Luis R. Rodriguez mcg...@suse.com wrote:
Ville,
the x86 patches are in and on their way to the next version of Linux.
Can I trouble you for your review of the atyfb driver changes?
Hey
On Wed, Jun 10, 2015 at 3:11 PM, Tony Luck tony.l...@gmail.com wrote:
On Tue, Jun 2, 2015 at 11:42 AM, Luis R. Rodriguez
mcg...@do-not-panic.com wrote:
From: Luis R. Rodriguez mcg...@suse.com
All the ia64 pvops code is now dead code since both
xen and kvm support have been ripped out [0] [1
On Tue, Jun 9, 2015 at 6:44 AM, Konrad Rzeszutek Wilk
konrad.w...@oracle.com wrote:
On Mon, Jun 08, 2015 at 04:35:35PM -0700, Luis R. Rodriguez wrote:
On Thu, May 28, 2015 at 2:50 PM, Luis R. Rodriguez
mcg...@do-not-panic.com wrote:
On Thu, May 21, 2015 at 11:32 AM, Luis R. Rodriguez mcg
On Thu, May 28, 2015 at 5:48 PM, Luis R. Rodriguez mcg...@suse.com wrote:
On Tue, May 19, 2015 at 1:22 PM, Luis R. Rodriguez
mcg...@do-not-panic.com wrote:
This v2 just changes licence to license as requested by Arend.
Please let me know if there is anything else needed.
Just a friendly
On Thu, Jun 11, 2015 at 05:23:16PM -0600, Toshi Kani wrote:
On Thu, 2015-06-11 at 13:36 -0700, Luis R. Rodriguez wrote:
:
Pending RIP MTRR patches
There are a few pending series so I wanted to provide a status update
on those series.
mtrr: bury MTRR
On Tue, Jun 2, 2015 at 11:33 AM, Luis R. Rodriguez
mcg...@do-not-panic.com wrote:
From: Luis R. Rodriguez mcg...@suse.com
This is needed the following modules:
Linux Kernel Dump Test Tool Module
CONFIG_LKDTMdrivers/misc/lkdtm.c
Since:
mcgrof@ergon ~/linux-next (git::master
On Fri, Jun 12, 2015 at 12:04:14PM +0300, Tomi Valkeinen wrote:
On 04/06/15 19:44, Luis R. Rodriguez wrote:
From: Luis R. Rodriguez mcg...@suse.com
This driver uses the same area for MTRR as for the ioremap_wc(), if
anything it just uses a smaller size in case MTRR reservation fails
On Thu, May 28, 2015 at 10:56:19PM +0100, Al Viro wrote:
On Thu, May 28, 2015 at 11:17:36PM +0200, Luis R. Rodriguez wrote:
... while some of us consider that as pointless posturing and will refuse
to merge such exports regardless.
Can you elaborate why, for those maintainers not aware
On Thu, May 28, 2015 at 09:07:49PM +0100, Al Viro wrote:
On Thu, May 28, 2015 at 11:56:01AM -0700, Luis R. Rodriguez wrote:
From: Luis R. Rodriguez mcg...@suse.com
Current documentation over use case for EXPORT_SYMBOL_GPL()
only acknowledges functions which are an internal implementation
On Thu, May 21, 2015 at 11:32 AM, Luis R. Rodriguez mcg...@suse.com wrote:
On Thu, May 21, 2015 at 04:20:27PM +0800, Michal Marek wrote:
Dne 21.5.2015 v 02:53 Luis R. Rodriguez napsal(a):
From: Luis R. Rodriguez mcg...@suse.com
Michal Marek, Xen folks (David Vrabel, Konrad, Ian), which
From: Luis R. Rodriguez mcg...@suse.com
Current documentation over use case for EXPORT_SYMBOL_GPL()
only acknowledges functions which are an internal implementation
issue, and not really an interface. In practice these days
though we have some maintainers taking on preferences to require
all new
On Thu, May 28, 2015 at 01:09:23PM -0600, Jonathan Corbet wrote:
On Thu, 28 May 2015 11:56:01 -0700
Luis R. Rodriguez mcg...@do-not-panic.com wrote:
+Some maintainers and developers may however have a preference to
+require EXPORT_SYMBOL_GPL() when adding any new APIs
From: Luis R. Rodriguez mcg...@suse.com
The same area used for ioremap() is used for the MTRR area.
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take
From: Luis R. Rodriguez mcg...@suse.com
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also ensure the ioremap'd area is requested
On Wed, May 27, 2015 at 1:04 PM, Luis R. Rodriguez mcg...@suse.com wrote:
On Tue, May 26, 2015 at 12:40:08PM -0500, Bjorn Helgaas wrote:
On Fri, May 22, 2015 at 02:23:41AM +0200, Luis R. Rodriguez wrote:
On Thu, May 21, 2015 at 05:33:21PM -0500, Bjorn Helgaas wrote:
I tentatively put
From: Luis R. Rodriguez mcg...@suse.com
The recent fix to use kstrdup_const() failed to add a
kfree upon failure of name allocation...
Cc: Ming Lei ming@canonical.com
Cc: Seth Forshee seth.fors...@canonical.com
Cc: Kyle McMartin k...@kernel.org
Cc: Greg Kroah-Hartman gre
From: Luis R. Rodriguez mcg...@suse.com
This driver never removed the MTRRs. Fix that.
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Jingoo Han jg1@samsung.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Masanari Iida standby2...@gmail.com
Cc: Suresh Siddha
On Tue, May 19, 2015 at 1:22 PM, Luis R. Rodriguez
mcg...@do-not-panic.com wrote:
This v2 just changes licence to license as requested by Arend.
Please let me know if there is anything else needed.
Luis
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
From: Luis R. Rodriguez mcg...@suse.com
Tomi,
Upon integration onto your tree of the series, [PATCH v3 00/17] framebuffer:
simple conversions to arch_phys_wc_add() the 0 day build bot found a
compilation issue on the gbefb driver. I had test compiled drivers with
allyesconfig and allmodconfig
Me and Julia are working on a paper which evaluates use of Coccinelle
on backports, a preliminary draft of such paper can be found on github
[0]. We are making some tweaks to this, one of which is covering the
uses of Linux backports [1] in the industry, for this we'd like to try
to get feedback
On Mon, Jun 1, 2015 at 1:53 AM, Ingo Molnar mi...@kernel.org wrote:
* Luis R. Rodriguez mcg...@suse.com wrote:
On Fri, May 29, 2015 at 08:41:44AM +0200, Ingo Molnar wrote:
* Luis R. Rodriguez mcg...@do-not-panic.com wrote:
+ gbe_mem = devm_ioremap_wc(p_dev-dev, gbe_mem_phys
On Tue, May 26, 2015 at 12:40:08PM -0500, Bjorn Helgaas wrote:
On Fri, May 22, 2015 at 02:23:41AM +0200, Luis R. Rodriguez wrote:
On Thu, May 21, 2015 at 05:33:21PM -0500, Bjorn Helgaas wrote:
I tentatively put this (and the rest of the series) on a pci/resource
branch. I'm hoping
On Fri, May 29, 2015 at 10:36 AM, Theodore Ts'o ty...@mit.edu wrote:
On Fri, May 29, 2015 at 05:01:00PM +0200, Richard Weinberger wrote:
On Fri, May 29, 2015 at 4:53 PM, Enrico Weigelt, metux IT consult
weig...@melag.de wrote:
Am 29.05.2015 um 04:54 schrieb Luis R. Rodriguez:
Just to clarify
On Fri, May 29, 2015 at 08:41:44AM +0200, Ingo Molnar wrote:
* Luis R. Rodriguez mcg...@do-not-panic.com wrote:
+ gbe_mem = devm_ioremap_wc(p_dev-dev, gbe_mem_phys,
+ gbe_mem_size);
+ gbe_mem = dma_alloc_writecombine(NULL
From: Luis R. Rodriguez mcg...@suse.com
Tomi,
this v5 series goes with the patch 3/17 titled video: fbdev: gbefb:
use arch_phys_wc_add() and devm_ioremap_wc() with a change from
dma_free_coherent() to dma_free_writecombine() for the area now allocated
with dma_alloc_writecombine(). The remaining
From: Luis R. Rodriguez mcg...@suse.com
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also ensure the ioremap'd area is requested
On Mon, Jun 01, 2015 at 01:36:23PM -0600, Toshi Kani wrote:
This patchset adds support of Write-Through (WT) mapping on x86.
The study below shows that using WT mapping may be useful for
non-volatile memory.
http://www.hpl.hp.com/techreports/2012/HPL-2012-236.pdf
The patchset consists of
On Thu, May 28, 2015 at 10:57 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On 29/05/15 03:36, Luis R. Rodriguez wrote:
On Wed, May 27, 2015 at 1:04 PM, Luis R. Rodriguez mcg...@suse.com wrote:
On Tue, May 26, 2015 at 12:40:08PM -0500, Bjorn Helgaas wrote:
On Fri, May 22, 2015 at 02:23
On Fri, May 29, 2015 at 08:48:46AM +0300, Tomi Valkeinen wrote:
On 29/05/15 03:30, Luis R. Rodriguez wrote:
From: Luis R. Rodriguez mcg...@suse.com
Tomi,
Upon integration onto your tree of the series, [PATCH v3 00/17]
framebuffer:
simple conversions to arch_phys_wc_add
On Wed, Apr 29, 2015 at 12:50 PM, Luis R. Rodriguez mcg...@suse.com wrote:
On Tue, Apr 21, 2015 at 1:46 PM, Luis R. Rodriguez
mcg...@do-not-panic.com wrote:
From: Luis R. Rodriguez mcg...@suse.com
If and when this gets enabled the driver could should split
up IO memory space properly
On Thu, May 28, 2015 at 10:00:09PM -0700, Christoph Hellwig wrote:
On Fri, May 29, 2015 at 01:10:44AM +0200, Luis R. Rodriguez wrote:
Great, thanks. This seems to be in alignment with those who have all along
said
they've used EXPORT_SYMBOL() to mean what EXPORT_SYMBOL_GPL() users now use
drivers with PROBE_PREFER_ASYNCHRONOUS is a temporary
measure that allows us to speed up boot process while we validating and
fixing the rest of the drivers and preparing userspace.
This change is based on earlier patch by Luis R. Rodriguez
mcg...@suse.com
Signed-off-by: Dmitry
-Hartman
Sent: Friday, June 26, 2015 12:54 PM
To: Luis R. Rodriguez
Cc: Marciniszyn, Mike; Borislav Petkov; Ingo Molnar; One Thousand Gnomes;
Doug Ledford; linux-r...@vger.kernel.org; linux-kernel@vger.kernel.org
Subject: Re: Deprecating ipath
On Fri, Jun 26, 2015 at 09:23:27AM -0700, Luis
On Fri, Jul 3, 2015 at 10:18 AM, Luis R. Rodriguez mcg...@suse.com wrote:
On Fri, Jul 3, 2015 at 8:36 AM, Greg Kroah-Hartman
gre...@linuxfoundation.org wrote:
On Fri, Jul 03, 2015 at 01:25:25PM +, Dalessandro, Dennis wrote:
-Original Message-
From: linux-rdma-ow
On Fri, Jun 26, 2015 at 12:30 AM, Borislav Petkov b...@suse.de wrote:
On Fri, Jun 26, 2015 at 03:09:27AM +0200, Luis R. Rodriguez wrote:
Sure, mind this as a follow up patch if its too late?
No need, you can send me an updated one - I'll replace it.
Will do!
Luis
--
To unsubscribe from
On Sat, Jul 04, 2015 at 07:09:19AM -0700, Dan Williams wrote:
On Fri, Jul 3, 2015 at 11:30 AM, Luis R. Rodriguez mcg...@suse.com wrote:
On Sat, Jun 27, 2015 at 04:45:25PM -0700, Dan Williams wrote:
On Mon, Mar 30, 2015 at 4:20 PM, Dmitry Torokhov
dmitry.torok...@gmail.com wrote:
Some
On Mon, Jun 29, 2015 at 05:52:18AM -0400, Andy Walls wrote:
On June 29, 2015 2:55:05 AM EDT, Ingo Molnar mi...@kernel.org wrote:
* Andy Walls a...@silverblocksystems.net wrote:
On Fri, 2015-06-26 at 10:45 +0200, Ingo Molnar wrote:
* Luis R. Rodriguez mcg...@suse.com wrote
On Sat, Jun 27, 2015 at 08:00:48AM +1000, Benjamin Herrenschmidt wrote:
On Fri, 2015-06-26 at 16:24 +, Casey Leedom wrote:
Thanks for looking into this Ben. As it stands now, it seems as
if Write Combined mappings simply aren't supported and/or all
driver writers trying to utilize
On Mon, Jun 08, 2015 at 09:57:12PM -0300, Mauro Carvalho Chehab wrote:
Em Mon, 08 Jun 2015 17:20:19 -0700
Luis R. Rodriguez mcg...@do-not-panic.com escreveu:
From: Luis R. Rodriguez mcg...@suse.com
Mauro,
since the ivtv patch is already acked by the driver maintainer
and depends
From: Luis R. Rodriguez mcg...@suse.com
We are burrying direct access to MTRR code support on
x86 in order to take advantage of PAT. In the future we
also want to make the default behaviour of ioremap_nocache()
to use strong UC, use of mtrr_add() on those systems
would make write-combining void
From: Luis R. Rodriguez mcg...@suse.com
Mauro,
since the ivtv patch is already acked by the driver maintainer
and depends on an x86 symbol that went through Boris' tree are you
OK in it going through Boris' tree?
Boris,
provided the outcome of the above maintainer's preference for you
to merge
From: Luis R. Rodriguez mcg...@suse.com
We are burrying direct access to MTRR code support on
x86 in order to take advantage of PAT. In the future we
also want to make the default behaviour of ioremap_nocache()
to use strong UC, use of mtrr_add() on those systems
would make write-combining void
From: Luis R. Rodriguez mcg...@suse.com
There is no good reason not to, we eventually delete it as well.
Cc: Toshi Kani toshi.k...@hp.com
Cc: Roland Dreier rol...@kernel.org
Cc: Sean Hefty sean.he...@intel.com
Cc: Hal Rosenstock hal.rosenst...@gmail.com
Cc: Suresh Siddha sbsid...@gmail.com
Cc
On Fri, May 22, 2015 at 3:33 PM, Herbert Xu herb...@gondor.apana.org.au wrote:
On Sat, May 23, 2015 at 12:22:00AM +0200, Luis R. Rodriguez wrote:
Kind of, the issue actually was a new component which depends on FW_LOADER
and has crypto dependencies. Since the qat crypto driver selects FW_LOADER
On Fri, May 22, 2015 at 02:43:57PM -0700, j...@joshtriplett.org wrote:
On Fri, May 22, 2015 at 09:28:14PM +0200, Luis R. Rodriguez wrote:
So the question still stands -- are there any kconfig options which
depend on EXPERT which enable folks to screw up run time (not just driver
tweaks
On Thu, May 21, 2015 at 10:02:36AM -0700, gre...@linuxfoundation.org wrote:
On Thu, May 21, 2015 at 04:03:02PM +, Woodhouse, David wrote:
On Thu, 2015-05-21 at 08:45 -0700, Greg Kroah-Hartman wrote:
On Thu, May 21, 2015 at 09:05:21AM -0400, Mimi Zohar wrote:
Signatures don't provide
On Thu, May 21, 2015 at 04:20:27PM +0800, Michal Marek wrote:
Dne 21.5.2015 v 02:53 Luis R. Rodriguez napsal(a):
From: Luis R. Rodriguez mcg...@suse.com
Michal Marek, Xen folks (David Vrabel, Konrad, Ian), which tree should
these go through?
Not kbuild, if I may ask :). Otherwise
On Thu, May 21, 2015 at 04:03:02PM +, Woodhouse, David wrote:
On Thu, 2015-05-21 at 08:45 -0700, Greg Kroah-Hartman wrote:
On Thu, May 21, 2015 at 09:05:21AM -0400, Mimi Zohar wrote:
Signatures don't provide any guarantees as to code quality or
correctness. They do provide file
On Thu, May 21, 2015 at 11:23 AM, Luis R. Rodriguez mcg...@suse.com wrote:
Sounds like a great project if you have the freedom and flexibility to
enable such hardware component. Now, if you can save a few bucks on it
per unit, how much would it be exactly? Just curious.
Also, another thing
On Thu, May 21, 2015 at 11:49:17PM +0900, Masahiro Yamada wrote:
Hi,
I am not familiar with xen at all, just some comments
from the build system side.
2015-05-21 3:53 GMT+09:00 Luis R. Rodriguez mcg...@do-not-panic.com:
From: Luis R. Rodriguez mcg...@suse.com
This lets you build
.
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
[Dmitry: split off from another patch, split into 2 parameters, moved
over to core_param_unsafe()]
Signed-off-by: Dmitry Torokhov dmitry.torok...@gmail.com
I've dropped this from my tree as I don't want to add these options
On Wed, May 20, 2015 at 07:21:00PM +0300, Petko Manolov wrote:
On 15-05-20 08:56:21, Andy Lutomirski wrote:
Would it make more sense to permit X.509 chains to be loaded into the
keyring
instead if we actually need that feature? IOW, let userspace (or early
initramfs stuff) extend
[1] https://lkml.org/lkml/2015/5/8/748
[2] https://lkml.org/lkml/2015/5/18/835
Signed-off-by: Luis R. Rodriguez mcg...@do-not-panic.com
---
I realize tree-wide changes are not encourated like this, but
I am doing this as an RFC first to save a few electrons to
spare sending out 21 separate e-mails
On Thu, May 21, 2015 at 3:06 PM, Andy Lutomirski l...@amacapital.net wrote:
Given that, I would say that merely shoving firmware files through the
module verifier as-is would not be okay.
Replacing one dog and pony show for another is what is going on, what
you describe and suggest seems best,
On Tue, May 19, 2015 at 05:41:37PM -0700, Andy Lutomirski wrote:
On Tue, May 19, 2015 at 5:39 PM, Luis R. Rodriguez mcg...@suse.com wrote:
On Tue, May 19, 2015 at 04:42:05PM -0700, Andy Lutomirski wrote:
On Tue, May 19, 2015 at 4:30 PM, Julian Calaby julian.cal...@gmail.com
wrote:
Hi
On Wed, May 20, 2015 at 05:24:46PM +0100, One Thousand Gnomes wrote:
On Wed, 20 May 2015 09:04:26 -0500
Seth Forshee seth.fors...@canonical.com wrote:
On Tue, May 19, 2015 at 10:02:32PM +0200, Luis R. Rodriguez wrote:
This begs the question on how we'd manage keys for firmware signing
On Thu, May 21, 2015 at 03:47:49PM -0700, Andy Lutomirski wrote:
On Thu, May 21, 2015 at 3:31 PM, Luis R. Rodriguez mcg...@suse.com wrote:
Well as good as you are in 10 years we'll have better ones. So when
module signature went into the kernel the real expectation should have
been
On Thu, May 21, 2015 at 2:44 PM, Andy Lutomirski l...@amacapital.net wrote:
One option would be to add another type of verifiable thing. We can
verify modules, and we should add firmware to the types of things that
can be signed. We could add signing keys, too. IOW, you could ask
the
On Thu, May 21, 2015 at 3:24 PM, Andy Lutomirski l...@amacapital.net wrote:
On Thu, May 21, 2015 at 3:16 PM, Luis R. Rodriguez mcg...@suse.com wrote:
On Thu, May 21, 2015 at 3:06 PM, Andy Lutomirski l...@amacapital.net wrote:
Given that, I would say that merely shoving firmware files through
On Thu, May 21, 2015 at 05:33:21PM -0500, Bjorn Helgaas wrote:
I tentatively put this (and the rest of the series) on a pci/resource
branch. I'm hoping you'll propose some clarification about
EXPORT_SYMBOL_GPL().
EXPORT_SYMBOL_GPL() also serves to ensure only GPL modules can
only run that
On Fri, May 22, 2015 at 10:57:11AM -0700, Dmitry Torokhov wrote:
On Fri, May 22, 2015 at 10:43:12AM -0700, Luis R. Rodriguez wrote:
On Fri, May 22, 2015 at 1:44 AM, Takashi Iwai ti...@suse.de wrote:
At Fri, 22 May 2015 10:17:48 +0200,
Paul Bolle wrote:
On Fri, 2015-05-22 at 09:11
, Luis R. Rodriguez wrote:
OK so we obviously care about EXPERT run time issues then, seems to kind
of defeat the purpose of EXPERT though, no? Makes me wonder what major
options
are under EXPERT which most distros need.
Not major, rather tweaking the driver sets. Like expert V4L or HID
On Fri, May 22, 2015 at 1:44 AM, Takashi Iwai ti...@suse.de wrote:
At Fri, 22 May 2015 10:17:48 +0200,
Paul Bolle wrote:
On Fri, 2015-05-22 at 09:11 +0200, Geert Uytterhoeven wrote:
On Fri, May 22, 2015 at 8:53 AM, Borislav Petkov b...@alien8.de wrote:
One thing I forgot last night: what
On Tue, May 19, 2015 at 10:02:15AM +0200, Paul Bolle wrote:
On Tue, 2015-05-19 at 02:09 +0200, Luis R. Rodriguez wrote:
On Mon, May 18, 2015 at 10:45:30PM +0200, Paul Bolle wrote:
[...] so, probably, almost
all .config files have FW_LOADER set. So I think, except for some corner
cases
On Tue, May 19, 2015 at 10:25:24AM +0100, David Howells wrote:
Luis R. Rodriguez mcg...@suse.com wrote:
There's a missing -binary argument here, other than that this works fine.
Good point.
$PKCS7_MESSAGE_FILE_IN_DER_FORM
I however cannot figure out how to use openssl
On Tue, May 19, 2015 at 11:02:44AM +0100, David Howells wrote:
Luis R. Rodriguez mcg...@do-not-panic.com wrote:
+The kernel firmware signing facility enables to cryptographically sign
+firmware files on a system using the same keys used for module signing.
+Firmware files's signatures
1101 - 1200 of 6292 matches
Mail list logo
