On Mon, Nov 26, 2012 at 02:03:16PM +, Grant Likely wrote:
> On Wed, 21 Nov 2012 14:02:40 -0700, Jason Gunthorpe
> wrote:
> > 'assigned-addresses' is used for certain PCI device type nodes in
> > lieu of 'reg', since this is enforced by of/address.c, hav
On Mon, Nov 26, 2012 at 02:23:56PM -0600, Kent Yoder wrote:
> On Wed, Nov 21, 2012 at 11:50:24PM +0100, Peter Huewe wrote:
> > Am Mittwoch, 21. November 2012, 21:56:45 schrieb Jason Gunthorpe:
> > > This seems to be preferred these days.
> > >
> > > Signed-off
On Thu, Nov 29, 2012 at 04:26:48PM +, Grant Likely wrote:
> Hmmm. okay that makes sense, but something still isn't quite right. So
> of_translate_address should take care of drilling down through the bus
> layers, and when it gets to the PCI node it /should/ use
> of_bus_pci_translate to handl
On Wed, Feb 06, 2013 at 09:46:18AM -0600, Kent Yoder wrote:
> Hi,
>
> Occasionally I get a note from someone who's been pointed to me as
> having the latest version of a driver that isn't upstream. The last
> submitted version of these drivers are usually sitting on the list,
> waiting on atten
On Tue, Jan 29, 2013 at 04:24:07PM +0100, Florian Fainelli wrote:
> - dev->err_interrupt = irq_of_parse_and_map(pdev->dev.of_node, 0);
> + if (pdev->dev.of_node) {
> + dev->regs = of_iomap(pdev->dev.of_node, 0);
> + if (!dev->regs) {
> + dev_er
On Tue, Jan 29, 2013 at 04:24:08PM +0100, Florian Fainelli wrote:
> This patch converts the Marvell MV643XX ethernet driver to use the
> Marvell Orion MDIO driver. As a result, PowerPC and ARM platforms
> registering the Marvell MV643XX ethernet driver are also updated to
> register a Marvell Orion
On Fri, Feb 01, 2013 at 04:38:42PM -0600, Kent Yoder wrote:
> >> > https://github.com/shpedoikal/linux.git tpmdd-01-22-13
> >>
> >> Thanks Kent, I will try to test your branch next week, if I am able.
> >>
> >> Can you also grab
> >>
> >> https://github.com/jgunthorpe/linux/commit/98b2a198b43b41b0
On Thu, Jan 24, 2013 at 11:37:30AM +0800, Feng Tang wrote:
> > I think hard numbers would be needed to show the rtc layer is
> > causing major issues for space constrained kernels, so this
> > trade-off could be properly prioritized. Having duplicate code paths
> > in standard kernels is wasteful
On Tue, Jan 22, 2013 at 05:29:23PM -0600, Kent Yoder wrote:
> Hi Jason,
>
> On Wed, Nov 21, 2012 at 3:15 PM, Jason Gunthorpe
> wrote:
> > We've been testing an alternative TPM for our embedded products and
> > found random kernel boot failures due to time outs aft
On Tue, Feb 26, 2013 at 07:41:18AM +, Grant Likely wrote:
> On Fri, 7 Dec 2012 16:10:17 -0700, Jason Gunthorpe
> wrote:
> > Allow the platform driver to bind through OF. The existing
> > OF machinery for setting the resource names through OF is used to
> > configure t
On Sun, Feb 17, 2013 at 10:49:08AM +, Grant Likely wrote:
> > > The patch introduce a regression on imx6q boot. The IOMUXC block on
> > > imx6q is special. It acts not only a pin controller but also a system
> > > controller with a bunch of system level registers in there. That's why
> > > w
The TPM will respond to TPM_GET_CAP with TPM_ERR_INVALID_POSTINIT if
TPM_STARTUP has not been issued. Detect this and automatically
issue TPM_STARTUP.
This is for embedded applications where the kernel is the first thing
to touch the TPM.
Signed-off-by: Jason Gunthorpe
---
drivers/char/tpm
On Tue, Oct 02, 2012 at 11:23:46AM +0100, Dave Martin wrote:
> > Well, no, it boots ELFs, so it can boot anything, with any memory
> > layout. A 2nd stage loader would be required to boot standard kernels,
> > that loader would be an ELF with 1 section for the 2nd stage, 1
> > section for the zIma
This provides an open firwmare driver binding for tpm_tis. OF
is useful on arches where PNP is not used.
Allow the tpm_tis driver to be selected if OF is compiled in.
Signed-off-by: Jason Gunthorpe
---
drivers/char/tpm/Kconfig |2 +-
drivers/char/tpm/tpm_tis.c | 79
On Wed, Oct 03, 2012 at 11:43:35AM +0100, Dave Martin wrote:
> I'm not sure exactly what you mean by linking the DTB into vmlinux.
> I don't think this is supported upstream, at least for ARM. It could
> be done externally by post-processing vmlinux to add extra sections
> and some boot shim code
On Thu, Oct 04, 2012 at 12:36:37PM +0100, Dave Martin wrote:
> OK, so it is supported, but not for ARM, yet. I'm not sure that
> such a patch would be rejected, since building in a DTB is not
> really that different from building in a command-line.
Maybe I will be able to look at this in a few m
On Thu, Oct 04, 2012 at 12:41:15PM -0500, Kent Yoder wrote:
> I'd rather see us just track the state and do the right thing
> here. If we don't get invalid postinit if we call tpm_startup during
> tpm_tis_init/tpm_tis_i2c_init, then set a flag we switch on here.
At least on my platform it is po
RW BSS sections, which is not the case for PPC.
Teach the ELF loader to check the X bit in the relevant load header and
create 0 filled anonymous mappings that are executable if the load header
requests that.
Signed-off-by: Jason Gunthorpe
---
arch/powerpc/include/asm/page.h| 10
On Tue, Feb 12, 2008 at 06:35:09PM -0800, Christoph Lameter wrote:
> On Tue, 12 Feb 2008, Jason Gunthorpe wrote:
>
> > The problem is that the existing wire protocols do not have a
> > provision for doing an 'are you ready' or 'I am not ready' exchange
>
[mangled CC list trimmed]
On Tue, Feb 12, 2008 at 10:56:26PM -0500, Patrick Geoffray wrote:
> Jason Gunthorpe wrote:
>> I don't know much about Quadrics, but I would be hesitant to lump it
>> in too much with these RDMA semantics. Christian's comments sound like
>>
On Tue, Feb 12, 2008 at 05:01:17PM -0800, Christoph Lameter wrote:
> On Tue, 12 Feb 2008, Jason Gunthorpe wrote:
>
> > Well, certainly today the memfree IB devices store the page tables in
> > host memory so they are already designed to hang onto packets during
> > t
On Tue, Feb 12, 2008 at 02:41:48PM -0800, Roland Dreier wrote:
> > > Chelsio's T3 HW doesn't support this.
>
> > Not so far I guess but it could be equipped with these features right?
>
> I don't know anything about the T3 internals, but it's not clear that
> you could do this without a new ch
On Wed, Feb 13, 2008 at 10:51:58AM -0800, Christoph Lameter wrote:
> On Tue, 12 Feb 2008, Jason Gunthorpe wrote:
>
> > But this isn't how IB or iwarp work at all. What you describe is a
> > significant change to the general RDMA operation and requires changes to
> >
On Wed, Feb 13, 2008 at 06:23:08PM -0500, Pete Wyckoff wrote:
> [EMAIL PROTECTED] wrote on Tue, 12 Feb 2008 20:09 -0800:
> > One other area that has not been brought up yet (I think) is the
> > applicability of notifiers in letting users know when pinned memory
> > is reclaimed by the kernel. This
On Wed, Oct 02, 2013 at 12:09:22AM +0200, Peter H?we wrote:
>Since the tpm_spi_stm_st33, tpm_i2c_nuvoton and tpm_i2c_atmel drivers
>are not yet merged and were heavily improved by you anyway, please
>include this improvement directly in the new drivers.
Okay, it is easy enough to inve
On Wed, Oct 02, 2013 at 12:52:40AM +0200, Peter H?we wrote:
> Am Montag, 23. September 2013, 20:14:38 schrieb Jason Gunthorpe:
> > CLASS-dev.c is a common idiom for Linux subsystems
> >
> > This pulls all the code related to the miscdev into tpm-dev.c and makes it
>
On Wed, Oct 02, 2013 at 01:14:18AM +0200, Peter H?we wrote:
> The makefile patch did fix it.
Great, feel free squash into the broken commit, or I can respin
things.
> (along with a small fix for the tpm_i2c_atmel driver ;)
Hum, I wonder why my compilers didn't whine, x86-64 should have
complain
On Wed, Oct 02, 2013 at 05:35:58PM +0200, Michal Simek wrote:
> +What:/sys/class/fpga_manager/fpga/fpga_config_state
> +Date:October 2013
> +KernelVersion: 3.12
> +Contact: Michal Simek
> +Description:
> + By reading this file you will get cur
On Wed, Oct 02, 2013 at 07:11:14PM -0500, Ashley D Lai wrote:
> > I somewhat have the feeling that we should maybe begin to deprecate
> > the vendor specific 1.1 tpms...
> I agree. If we have a machine to test and it fails then we know we don't
> have a user for this.
Is this driver is only used
On Wed, Oct 02, 2013 at 01:14:18AM +0200, Peter H?we wrote:
> > I botched the makefile changes for the new .c files.
> >
> > I believe it should be like this:
> >
> > obj-$(CONFIG_TCG_TPM) += tpm-core.o
> > tpm-core-y := tpm.o tpm-dev.o tpm-sysfs.o
> >
> > > I added a suitable patch with the ap
On Thu, Oct 03, 2013 at 03:04:37PM -0400, Jason Cooper wrote:
> > I'm wondering: is the clock really disabled if the device is not
> > available (i.e. status == 'ok')? In other words: isn't the
> > !of_device_is_available() test enough?
>
> Well, this stemmed from JasonG's scenario where the seco
On Fri, Oct 04, 2013 at 05:50:01PM +0200, Peter H?we wrote:
> I'm not 100% sure what's the usual procedure for module renames, especially
> since this is visible in userspace.
>
> For users the easiest way would be to rename tpm.c to tpm-core.c and
> leave the module name as it is. In git that'
On Fri, Oct 04, 2013 at 06:28:23PM +0200, Michal Simek wrote:
> > I strongly encourage you to use text strings to indicate the state of
> > the configuration FSM, and I *really* think you should rework things
> > to have an explicit configuration FSM rather than trying to bodge one
> > together wit
On Mon, Sep 30, 2013 at 05:09:51PM -0500, Joel Schopp wrote:
> > So far, nobody I have talked to has offered any strong opinions on
> > what locality should be used or how it should be set. I think finding
> > a developer of trousers may be the most useful to talk about how the
> > ioctl portion o
On Fri, Oct 04, 2013 at 04:33:41PM -0700, Greg Kroah-Hartman wrote:
> > I agree that the firmware interface makes sense when the use of the
> > FPGA is an implementation detail in a fixed hardware configuration,
> > but that is a fairly restricted use case all things considered.
>
> Ideally I tho
On Fri, Oct 04, 2013 at 09:00:28PM -0700, H. Peter Anvin wrote:
> Every FPGA toolchain I know of has a way to emit JAM/STAPL bytecode
> files... and a fair number of programming scenarios need them.
Yes, but now you are talking about JTAG.
JTAG is a very different problem than configuring over t
On Fri, Oct 04, 2013 at 10:34:10PM -0700, H. Peter Anvin wrote:
> I do it all the time.
>
> JAM/STAPL seems to me to be more used for exotic connections to
> serial flash for persistent programming.
The FPGA tools write two kinds of SVF/JAM/STAPL files, one is ment to
be replayed the to FPGA itse
I've prepared this branch:
https://github.com/jgunthorpe/linux/commits/for-tpm
dd783708a8c6fd713c784be68fcbcb7000c43c49
Jason Gunthorpe (11):
tpm: ibmvtpm: Use %zd formatting for size_t format arguments
tpm atmel: Call request_region with the correct base
tpm: Store devna
items into tpm-sysfs.c, tpm-dev.c and tpm-class.c. All that will
be left is tpm command processing and interfacing code.
Signed-off-by: Jason Gunthorpe
---
drivers/char/tpm/Makefile | 2 ++
drivers/char/tpm/{tpm.c => tpm-interface.c} | 0
2 files changed, 2 insertions(+)
rename
them. Further, tpm-bios does
nothing on its own, it has no module_init function.
Thus we remove the exports and merge the modules to simplify things.
The Makefile conditions are changed slightly to match the code,
tpm_ppi is always required if CONFIG_ACPI is set.
Signed-off-by: Jason Gunthorpe
On Sun, Oct 06, 2013 at 12:53:22PM -0700, Joe Perches wrote:
> On Sun, 2013-10-06 at 13:38 -0600, Jason Gunthorpe wrote:
> > This is preparation for making the tpm module multi-file. kbuild does
> > not like having a .c file with the same name as a module. We wish to
> > kee
Hi Will,
I was just testing v3.12-rc1 (on kirkwood) and noticed that strace is
not working:
$ strace /bin/ls
mmap2(0xb6f79000, 9552, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb6f79000
close(3)= 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE,
On Wed, Sep 18, 2013 at 03:15:17PM -0400, Jason Cooper wrote:
> + Jason Gunthorpe
Thanks, looks interesting, we could possibly use this interface if it
met our needs..
> On Wed, Sep 18, 2013 at 05:56:39PM +0200, Michal Simek wrote:
> > This new subsystem should unify all fpga d
On Thu, Sep 19, 2013 at 10:18:03AM -0500, Yves Vandervennet wrote:
> On Thu, Sep 19, 2013 at 5:55 AM, Michal Simek wrote:
>
> >> Is there some way a per-device userspace helper can be added that can
> >> handle adding the headers? Such that different fpga types get different
> >> helpers?
> >
>
On Tue, Oct 08, 2013 at 09:15:55AM +, Fuchs, Andreas wrote:
> Rather than an ioctl, why not provide a different tpm-device per
> locality. This way, the access to the different localities can be
> restricted via standard user/group of the device. i.e. /dev/tpm0l1,
> /dev/tpm0l2, ... or simil
On Wed, Oct 09, 2013 at 01:37:05PM -0700, H. Peter Anvin wrote:
> A very common use case would be where a device contains an FPGA but is
> presented to the user as a product, often having its own device driver
> to drive the programmed device and/or additional logic. From *that*
> point of view i
On Thu, Oct 10, 2013 at 07:42:49AM +, Fuchs, Andreas wrote:
> In any case, I like your idea to split trousers IPC to two distinct
> unix sockets for localities. In this case, we could also split tcsd
> into two processes along with it for accessing the distinct
> char-devices and thereby make
On Fri, Sep 27, 2013 at 03:31:53PM +0200, Michal Simek wrote:
> I expect that you are detecting/specifying in the driver which
> fpga is connected and you also need to know size of this device.
> Then your driver allocate buffer with this size in the kernel
> and streming data to this buffer. When
On Tue, Sep 24, 2013 at 10:28:41AM -0400, Daniel De Graaf wrote:
> On 09/23/2013 06:23 PM, Jason Gunthorpe wrote:
> >On Mon, Sep 23, 2013 at 06:00:46PM -0400, Daniel De Graaf wrote:
> >
> >>In a PC client TPM, normal OS code (as opposed to firmware or microcode)
>
Hi Folks, I hope this is a good CC list for this misbehavior..
I've noticed that tmpfs is eager to expand holes in sparse files and
ends up accounting for that memory as counting against the filesystem
limit.
Specifically, it does this if you try to sendfile() from a holey file,
or mmap(PROT_READ
On Mon, Sep 30, 2013 at 04:36:27PM -0400, Daniel De Graaf wrote:
> >I think using CONFIG_ options would make this feature unavaiable to
> >distro kernel users...
>
> This just moves the problem - now you need a custom initrd instead of
> a custom kernel. Other TPM options like IMA's PCR selection
On Mon, Sep 23, 2013 at 03:10:11PM +0200, Michal Simek wrote:
> > 1) The driver doesn't know what firmware to request. It just knows
> >how to send it to a FPGA.
>
> But dts property in the manager driver which uses this as end driver
> can know that.
I think the device tree maintainers woul
CLASS-dev.c is a common idiom for Linux subsystems
This pulls all the code related to the miscdev into tpm-dev.c and makes it
static. The identical file_operation structs in the drivers are purged and the
tpm common code unconditionally creates the miscdev.
Signed-off-by: Jason Gunthorpe
For some reason this driver thinks that chip->data_buffer needs
to be set before it can call tpm_pm_*. This is not true. data_buffer
is used only by /dev/tpmX, which is why it is managed exclusively
by the fops functions.
Cc: Mathias Leblanc
Signed-off-by: Jason Gunthorpe
---
drivers/char/
This consolidates everything that is only used within tpm-dev.c
into tpm-dev.c and out of the publicly visible struct tpm_chip.
The per-file allocation lays the ground work for someday fixing the
strange forced O_EXCL behaviour of the current code.
Signed-off-by: Jason Gunthorpe
---
drivers
interface the TPM supports at run-time.
Signed-off-by: Jason Gunthorpe
---
drivers/char/tpm/tpm.c | 56 +++--
drivers/char/tpm/tpm.h | 2 --
drivers/char/tpm/tpm_i2c_atmel.c| 2 +-
drivers/char/tpm/tpm_i2c_infineon.c | 2 +-
drivers/char
TPM drivers should not call dev_set_drvdata (or aliases), only the core
code is allowed to call dev_set_drvdata, and it does it during
tpm_register_hardware.
These extra sets are harmless, but are an anti-pattern that many drivers
have copied.
Signed-off-by: Jason Gunthorpe
---
drivers/char
misc_open sets the file->private_date to the misc_dev when calling
open. We can use container_of to go from the misc_dev back to the
tpm_chip.
Future clean ups will move tpm_open into a new file and this change
means we do not have to export the tpm_chip list.
Signed-off-by: Jason Guntho
This builds on the last commit to use the ops structure in the core
and reduce the size of tpm_vendor_specific.
Signed-off-by: Jason Gunthorpe
---
drivers/char/tpm/tpm-sysfs.c| 2 +-
drivers/char/tpm/tpm.c | 35 +--
drivers/char/tpm/tpm.h
This replaces the static initialization of a tpm_vendor_specific
structure in the drivers with the standard Linux idiom of providing
a const structure of function pointers.
Signed-off-by: Jason Gunthorpe
---
drivers/char/tpm/tpm.c | 10 --
drivers/char/tpm/tpm.h
).
Just remove them.
Cc: Daniel De Graaf
Cc: Konrad Rzeszutek Wilk
Signed-off-by: Jason Gunthorpe
---
drivers/char/tpm/xen-tpmfront.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/char/tpm/xen-tpmfront.c b/drivers/char/tpm/xen-tpmfront.c
index 7a7929b..6f2fe2b 100644
--- a
e device startup (tpm_startup, tpm_get_timeoutes)
into core code
If this series is successful I may be able to do some of the above as well.
Jason Gunthorpe (13):
tpm: ibmvtpm: Use %zd formatting for size_t format arguments
tpm atmel: Call request_region with the correct base
tpm: xen-tpmfr
This suppresses compile warnings on 32 bit builds.
Signed-off-by: Jason Gunthorpe
---
drivers/char/tpm/tpm_ibmvtpm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/char/tpm/tpm_ibmvtpm.c b/drivers/char/tpm/tpm_ibmvtpm.c
index 56b07c3..838f043 100644
--- a
request_region being called with 0
as the base address.
I don't know if request_region(0, ..) will fail, if so the
driver has been broken since 2006 and we should remove it
from the tree as it has no users.
Signed-off-by: Jason Gunthorpe
---
drivers/char/tpm/tpm_atmel.c | 2 +-
1 file chang
Just put the memory directly in the chip structure, rather than
in a 2nd dedicated kmalloc.
Signed-off-by: Jason Gunthorpe
---
drivers/char/tpm/tpm.c | 17 ++---
drivers/char/tpm/tpm.h | 1 +
2 files changed, 7 insertions(+), 11 deletions(-)
diff --git a/drivers/char/tpm/tpm.c b
-sysfs.c
@@ -0,0 +1,318 @@
+/*
+ * Copyright (C) 2004 IBM Corporation
+ * Authors:
+ * Leendert van Doorn
+ * Dave Safford
+ * Reiner Sailer
+ * Kylene Hall
+ *
+ * Copyright (C) 2013 Obsidian Reearch Corp
+ * Jason Gunthorpe
+ *
+ * sysfs filesystem inspection interface to the TPM
+ *
+ * This
On Mon, Sep 23, 2013 at 02:54:21PM -0400, Daniel De Graaf wrote:
> On 09/23/2013 02:14 PM, Jason Gunthorpe wrote:
> >CLASS-sysfs.c is a common idiom for linux subsystems.
> >
> >This pulls all the sysfs attribute functions and related code
> >into tpm-sysfs.c. To support
On Mon, Sep 23, 2013 at 04:20:51PM -0400, Daniel De Graaf wrote:
> That's fine; it wasn't really advertised in the description, and was
> mostly added in order to demonstrate the locality security label binding
> in Xen's vtpm-stubdom.
Ok, lets take it out for now then? I'll send a patch.
> >It
The hope is to have a well defined locality API that all the other
locality aware drivers can use, perhaps in 3.13.
Signed-off-by: Jason Gunthorpe
---
drivers/char/tpm/xen-tpmfront.c | 29 -
1 file changed, 29 deletions(-)
Daniel, if you can Ack this..
Konrad: T
On Mon, Sep 23, 2013 at 06:00:46PM -0400, Daniel De Graaf wrote:
> In a PC client TPM, normal OS code (as opposed to firmware or microcode)
> is already restricted to locality 0-2. It may make sense to restrict
> locality 2 to the kernel, which would allow an in-kernel TPM seal
> command to be abl
On Mon, Oct 08, 2012 at 11:24:13AM +0100, Dave Martin wrote:
> Partly this came from some side speculation about whether we could do
> things like privileged read-only permissions on newer CPUs, for preventing
> unintended or undesired writes to the kernel's code or read-only data.
Some other arc
On Mon, Oct 08, 2012 at 11:46:49AM +0100, Dave Martin wrote:
> > Yes, but we still need rely on complex code like I2C/MTD to create a
> > correct DTB, which again puts us back to patching the kernel for that
> > functionality.
>
> I'm still confused as to where this complexity is coming from.
>
On Fri, Nov 30, 2012 at 09:48:05AM +, Grant Likely wrote:
> > If you attempt to stick a 'reg' in a block nested below a
> > 'device_type="pci"' the kernel throws lots of error messsages and
> > generates bad address mappings.
>
> Have you added the appropriate #address-cells and #size-cells t
-by: Jason Gunthorpe
---
drivers/char/tpm/tpm_tis.c | 21 +
1 files changed, 21 insertions(+), 0 deletions(-)
Note: This does not change the requirement of the driver,
request_locality already will bail if valid is not set. All this does
is wait for valid to be set before
If the DT does not include a regs parameter then the null res
would be dereferenced.
Signed-off-by: Jason Gunthorpe
---
drivers/watchdog/orion_wdt.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/watchdog/orion_wdt.c b/drivers/watchdog/orion_wdt.c
index
e which is right.
Signed-off-by: Jason Gunthorpe
---
arch/arm/mach-dove/common.c |5 +-
arch/arm/mach-dove/include/mach/bridge-regs.h |2 +-
arch/arm/mach-dove/include/mach/irqs.h|9 +++-
arch/arm/mach-kirkwood/common.c |6 ++
Allow the platform driver to bind through OF. The existing
OF machinery for setting the resource names through OF is used to
configure the device, so the change is minimally intrusive and
fully featured.
Signed-off-by: Jason Gunthorpe
---
.../devicetree/bindings/gpio/gpio-generic.txt
On Sat, Dec 08, 2012 at 12:26:24PM +0100, Andrew Lunn wrote:
> 1) It should have an IRQ domain, like the other IRQ chips we have.
> 2) It should have a DT binding, like the other IRQ chips we have.
I was going to look at a DT binding for this as a follow on, since
I'll want to bind to these inte
This is for embedded cases where the PCI device may be a complex
SOC with no PCI based partitioning of sub-functionality.
Tested on an ARM kirkwood system
Signed-off-by: Jason Gunthorpe
---
drivers/of/address.c | 29 +
1 files changed, 29 insertions(+), 0 deletions(
subsystem completely and generically replaces this
functionality.
Tested on ARM kirkwood and PPC405
Signed-off-by: Jason Gunthorpe
---
drivers/rtc/Kconfig |8
drivers/rtc/Makefile |1 +
drivers/rtc/systohc.c | 30 ++
include/linux/time.h |1
On Wed, Dec 19, 2012 at 12:54:51PM +, Grant Likely wrote:
> Then it sounds like you really don't want PCI addressing in the
> children. It sounds like the children addresses need to be in the form
> [bar#] [offset-from-base-of-bar]. In that case, you need the
> appropriate
They should be int
On Mon, Nov 19, 2012 at 12:19:38PM -0800, Greg KH wrote:
> On Mon, Nov 19, 2012 at 01:09:21PM -0700, Jason Gunthorpe wrote:
> > On Mon, Nov 19, 2012 at 01:25:56PM -0500, Bill Pemberton wrote:
> > > CONFIG_HOTPLUG is going away as an option so __devexit is no
> > > long
On Mon, Nov 19, 2012 at 02:06:32PM -0800, Greg KH wrote:
> > 5k isn't a lot, but in the context of 'I have to figure out how to
> > trim ~1MB off the 3.6 kernel to run it in our smallest hardware' it is
> > the wrong direction :(
>
> It is only 0.138% in the "wrong" direction. Seriously, that's
On Mon, Nov 19, 2012 at 03:00:06PM -0800, Greg KH wrote:
> I could just leave things alone, with CONFIG_HOTPLUG always enabled, but
> then people will continue to blindly use the __dev* markings, getting it
> wrong at times, but never realizing that they don't do anything anymore.
Well, I was thi
On Sun, Dec 09, 2012 at 02:06:48PM +0100, Sebastian Hesselbarth wrote:
> The main irq controller will be required for sure, but for the secondary
> irq controller we had a discussion long ago. IIRC Gregory proposed to have
> shared irqs handled by timer and watchdog, I was proposing chained irqs.
On Thu, Jun 06, 2013 at 06:27:08PM +0200, Sebastian Hesselbarth wrote:
> This patch set introduces DT-aware irqchip and clocksource drivers for
> Marvell Orion SoCs (Kirkwood, Dove, Orion5x, MV78x00) and corresponding
> patches for Dove and Kirkwood to enable them for DT-boards.
Looks broadly good
On Thu, May 30, 2013 at 02:45:20PM -0700, Stepan Moskovchenko wrote:
> void __init early_init_dt_add_memory_arch(u64 base, u64 size)
> {
> +#ifndef CONFIG_ARM_LPAE
> + if (base > ((phys_addr_t)~0)) {
The #ifdef is probably not necessary here, simply checking that
base/size can be represented
On Fri, Jun 07, 2013 at 01:59:43PM +0200, Arnd Bergmann wrote:
> On Friday 07 June 2013 18:19:40 Jingoo Han wrote:
> > Hi Jason Gunthorpe,
> >
> > I implemented 'Single domain' with Exynos PCIe for last two months;
> > however, it cannot work properly due to t
On Thu, Mar 21, 2013 at 11:39:47AM +0200, Michael S. Tsirkin wrote:
> On Thu, Mar 21, 2013 at 02:13:38AM -0700, Roland Dreier wrote:
> > On Thu, Mar 21, 2013 at 1:51 AM, Michael S. Tsirkin wrote:
> > >> In that case, no, I don't see any reason for LOCAL_WRITE, since the
> > >> only RDMA operations
On Thu, Mar 21, 2013 at 07:15:25PM +0200, Michael S. Tsirkin wrote:
> No because application does this:
> init page
>
> ...
>
> after a lot of time
>
> ..
>
> register
> send
> unregister
>
> so it can not be read only.
mprotect(READONLY)
register
send
unregister
mprotect(WRITABLE)
?
With
On Thu, Mar 21, 2013 at 07:42:37PM +0200, Michael S. Tsirkin wrote:
> It doesn't actually, and our app would sometimes write to these pages.
> It simply does not care which version does the remote get in this case
> since we track writes and resend later.
Heh, somehow I thought you might say that
On Thu, Mar 21, 2013 at 08:16:33PM +0200, Michael S. Tsirkin wrote:
> This is the one I find redundant. Since the write will be done by
> the adaptor under direct control by the application, why does it
> make sense to declare this beforehand? If you don't want to allow
> local write access to me
On Thu, Mar 21, 2013 at 09:15:41PM +0200, Michael S. Tsirkin wrote:
> On Thu, Mar 21, 2013 at 12:41:35PM -0600, Jason Gunthorpe wrote:
> > On Thu, Mar 21, 2013 at 08:16:33PM +0200, Michael S. Tsirkin wrote:
> >
> > > This is the one I find redundant. Since the write w
On Thu, Mar 21, 2013 at 09:22:36PM +0100, Thomas Petazzoni wrote:
> And I'm not sure the SDRAM address decoding windows allows to split the
> first 4 GB of RAM into two areas, one that would be mapped starting at
> physical address 0x0, and another area that would be mapped at a
> different addres
On Thu, Mar 21, 2013 at 10:15:23PM +0100, Thomas Petazzoni wrote:
> Dear Jason Gunthorpe,
>
> On Thu, 21 Mar 2013 14:55:45 -0600, Jason Gunthorpe wrote:
>
> > Or, better, locate all the internal registers above 8G and use
> > contiguous DRAM mapping from 0 -> 8GB
>
On Sat, Mar 23, 2013 at 01:09:18PM +0900, Jingoo Han wrote:
> + pcie0@4000 {
> + compatible = "samsung,exynos5440-pcie";
> + reg = <0x4000 0x4000
> + 0x29 0x1000
> + 0x27 0x1000
> + 0x271000 0x4
On Mon, Jul 29, 2013 at 01:23:39PM -0400, Jason Cooper wrote:
> true, the answer to this problem may be to create a depgraph of the
> nodes based on phandles and child status, then init. However, if the
> goal is to accelerate boot times, then that should not be calculated
> during each boot, esp
On Sat, Jul 27, 2013 at 10:48:26AM +0200, Richard Cochran wrote:
> > Of course all this could have been done in C, but it wasn't/hasn't been..
>
> You have identified the real issue: poor quality of the ARM board
> support process within the kernel. Churn is still churn, whether in DT
> or in pla
On Sat, Jul 27, 2013 at 11:51:06AM -0700, Tomasz Figa wrote:
> Well, it depends on how we use the DT. There are (at least) two possible
> usage scenarios:
>
> a) using DT as direct replacement for board files - this means that you
> are free to say that DTSes are strictly coupled with kern
On Mon, Jul 29, 2013 at 07:16:07PM +0100, Russell King - ARM Linux wrote:
> What does it take? Good practice, care, thought and planning. All
> the qualities which should already be present for kernel _engineers_.
> Not an "lets create something for me, I don't care about anyone else"
> attitude
1 - 100 of 3031 matches
Mail list logo
