Hi,
I've run into the following weird behavior on my system with 2.4.0. I have
the following code:
if (fork() == 0)
{
int Flags,dummy;
if ((Flags = fcntl(STDIN_FILENO,F_GETFL,dummy)) 0)
_exit(100);
if (fcntl(STDIN_FILENO,F_SETFL,Flags | O_NONBLOCK) 0)
_exit(100);
On 12 Apr 2001, Philippe Troin wrote:
Apt I guess ? It has a very strange behavior when backgrounded...
Not really, just want it tries to run dpkg it hangs.
The last read was after the process was forgrounded. The read waits
forever, the non-block flag seems to have gone missing. It is
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
and they are not designed to store page tables
[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
they operate closer to what you
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
the page lookup over PCIE, adding
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 chip
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
both sides of the connection
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 is
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
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
are 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 jguntho...@obsidianresearch.com
---
arch/powerpc/include
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
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.
If you
On Wed, Oct 10, 2012 at 11:24:28AM -0500, Kent Yoder wrote:
Why change the structs to const here? This generates warnings for me:
I should have dropped this, I was added when I added the __devinitdata
annotations..
+
+static struct platform_driver tis_driver = {
.driver = {
On Wed, Oct 10, 2012 at 11:33:24AM -0500, Kent Yoder wrote:
On Sun, Sep 30, 2012 at 05:33:45PM -0600, Jason Gunthorpe wrote:
How to use the TPM is really a user space policy choice, if the
environment wants to use middleware then fine, but it is possible to
make correct TPM apps without
On Wed, Oct 10, 2012 at 10:55:44AM +0100, Dave Martin wrote:
As a side comment, some things such as MAC addresses can be probed and
set from userspace after kernel boot, assuming that you have a way
to fetch the device description blob from userspace. If it's accessible
via MTD I'm guessing
On Mon, Oct 15, 2012 at 08:35:09AM +, peter.hu...@infineon.com wrote:
From: Jason Gunthorpe [mailto:jguntho...@obsidianresearch.com]
Using open/close is an interesting idea, but it wouldn't work. open()
is coded to return EBUSY if another process has it open, rather than
block
On Mon, Oct 15, 2012 at 05:49:22PM +0100, Alan Cox wrote:
Using open/close is an interesting idea, but it wouldn't work. open()
is coded to return EBUSY if another process has it open, rather than
block, and spinning on open would be unacceptable.
Hmm, maybe write a small pass
On Mon, Apr 08, 2013 at 06:08:53PM +0900, Jingoo Han wrote:
I have a question. Now, I am reviewing the Tegra PCIe, Marvell PCIe
patchset. However, in the case of Exynos PCIe, 'downstream I/O' and
'non-prefetchable memory' are different between PCIe0 and PCIe1.
These regions are not shared.
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 m...@redhat.com wrote:
In that case, no, I don't see any reason for LOCAL_WRITE, since the
only RDMA
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 something
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
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 will be done by
the adaptor under
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 address
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
I see two potential issues
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 0x40;
+
On Wed, Mar 27, 2013 at 05:35:48PM +0900, Jingoo Han wrote:
Here is the lspci -vv output.
I tested Exynos PCIe with e1000e lan card.
00:00.0 PCI bridge: Samsung Electronics Co Ltd Device a549 (rev 01) (prog-if
00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV-
On Mon, Mar 04, 2013 at 11:41:04AM -0600, Kent Yoder wrote:
.id_table = tpm_tis_i2c_table,
.probe = tpm_tis_i2c_probe,
.remove = tpm_tis_i2c_remove,
@@ -703,11 +759,12 @@ static struct i2c_driver tpm_tis_i2c_driver = {
.name = tpm_i2c_infineon,
On Tue, Mar 05, 2013 at 02:34:25AM +, Tang, Feng wrote:
Hi Jason,
Sorry, I forgot to add you in cc list in the first place. Please
help to review the patch series, thanks!
Sure, I didn't get CC'd on the patches, so this is an imperfect reply,
but..
Did you consider an approach closer to
On Tue, Mar 05, 2013 at 11:53:02AM +0800, Feng Tang wrote:
// Drops some small precision along the way but is simple..
static inline u64 cyclecounter_cyc2ns_128(const struct cyclecounter *cc,
cycle_t cycles)
{
u64 max = U64_MAX/cc-mult;
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 handle
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 to the pci
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 attention
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) {
+
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
On Tue, Feb 26, 2013 at 07:41:18AM +, Grant Likely wrote:
On Fri, 7 Dec 2012 16:10:17 -0700, Jason Gunthorpe
jguntho...@obsidianresearch.com wrote:
Allow the platform driver to bind through OF. The existing
OF machinery for setting the resource names through OF is used to
configure
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 as
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
jguntho...@obsidianresearch.com wrote:
We've been testing an alternative TPM for our embedded products and
found random kernel boot failures due to time outs after
On Thu, Jan 17, 2013 at 04:22:18PM +, Andrew Murray wrote:
In either of those cases, does it make sense to use the MSI support
outside the scope of the PCI infrastructure? That is, would devices
other than PCI devices be able to generate an MSI?
I've come around to your way of
On Tue, Jan 15, 2013 at 11:50:18AM -0800, John Stultz wrote:
On 01/15/2013 08:09 AM, Feng Tang wrote:
Make the persistent clock check a kernel config option, so that some
platform can explicitely select it, also make CONFIG_RTC_HCTOSYS depends
on its non-existence, which could prevent the
On Mon, Jan 21, 2013 at 10:46:31AM -0800, John Stultz wrote:
What I'd propose is that we break the read_persistent_clock()
functionality up. So we need two interfaces:
1) An interface to access a time value we used to initialize the
system's CLOCK_REALTIME time.
2) An interface to measure
On Tue, Jan 22, 2013 at 12:22:29PM -0800, John Stultz wrote:
How big of an issue is this? Could the RTCTOSYS function be moved to
the moment the RTC driver is registered rather than using a
late_initcall?
It may not be huge. Most early boot items are going to be
CLOCK_MONOTONIC based,
On Tue, Jan 22, 2013 at 04:41:58PM -0800, John Stultz wrote:
Right but to calculate an suspend interval (since they are likely
many orders of magnitude larger then the intervals between timer
interrupts), you need different mult/shift selection. Its splitting
out the mult/shift management
On Tue, Jan 22, 2013 at 05:54:21PM -0800, John Stultz wrote:
complicated part. Additionally, there may be cases where the
timekeeping clocksource is one clocksource and the suspend
clocksource is another. So I think to properly integrate this sort
Does the difference matter? The clocksource
On Tue, Jan 22, 2013 at 07:07:04PM -0800, John Stultz wrote:
But personally, I'm less fond of adding additional state to the
clocksources, as I'm (admittedly, very) slowly trying to go the
other way, and make the clocksources mostly state free. This is in
part to allow for faster timekeeping
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
we currently
-by: Jason Gunthorpe jguntho...@obsidianresearch.com
---
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
If the DT does not include a regs parameter then the null res
would be dereferenced.
Signed-off-by: Jason Gunthorpe jguntho...@obsidianresearch.com
---
drivers/watchdog/orion_wdt.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/watchdog/orion_wdt.c b/drivers
-off-by: Jason Gunthorpe jguntho...@obsidianresearch.com
---
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 jguntho...@obsidianresearch.com
---
.../devicetree/bindings
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
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 jguntho...@obsidianresearch.com
---
drivers/of/address.c | 29 +
1 files changed, 29 insertions(+), 0
be
signed.
Tested on PPC32.
Signed-off-by: Jason Gunthorpe jguntho...@obsidianresearch.com
---
lib/vsprintf.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 39c99fe..41da074 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
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 PNP or OF are compiled in.
Signed-off-by: Jason Gunthorpe jguntho...@obsidianresearch.com
---
drivers/char/tpm/Kconfig |2 +-
drivers/char
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 jguntho
This allows platform_device_add a chance to call insert_resource
on all of the resources from OF. At a minimum this fills in proc/iomem
and presumably makes resource tracking and conflict detection work
better.
Signed-off-by: Jason Gunthorpe jguntho...@obsidianresearch.com
---
drivers
On Wed, Nov 21, 2012 at 08:59:24AM +, peter.hu...@infineon.com wrote:
I just gave the new version a run on my beagleboard with our Infineon SLB9635
TT 1.2 Soft I2C TPM
and it seems to work as expected. (Tested with and without previous startup).
Tested-by: Peter Huewe
On Wed, Nov 21, 2012 at 03:51:04PM +, Grant Likely wrote:
On Wed, 21 Nov 2012 00:24:48 -0700, Jason Gunthorpe
jguntho...@obsidianresearch.com wrote:
This allows platform_device_add a chance to call insert_resource
on all of the resources from OF. At a minimum this fills in proc/iomem
On Wed, Nov 21, 2012 at 06:07:46PM +, Grant Likely wrote:
Which is nesting the generic gpio driver under a larger region..
Try two sibling nodes with overlapping addresses. There are powerpc
device trees doing that even though it isn't legal by the ofw and
epapr specs.
Both my
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 jguntho
On Wed, Nov 21, 2012 at 09:17:54PM +0100, Peter H?we wrote:
Care to change to
+ A TPM error (%zd) occurred attempting to determine the
timeouts\n,
Sorry that I didn't spot it earlier.
Right.. Probably like this in my tree because of:
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 jguntho
This seems to be preferred these days.
Signed-off-by: Jason Gunthorpe jguntho...@obsidianresearch.com
---
drivers/char/tpm/tpm.h | 34 +-
1 files changed, 17 insertions(+), 17 deletions(-)
As discussed with Peter.
diff --git a/drivers/char/tpm/tpm.h b/drivers
'assigned-addresses' is used for certain PCI device type nodes in
lieu of 'reg', since this is enforced by of/address.c, have
of_device_make_bus_id look there as well.
Signed-off-by: Jason Gunthorpe jguntho...@obsidianresearch.com
---
drivers/of/platform.c |2 ++
1 files changed, 2
test
The other TPM vendor we use doesn't show this wonky behaviour:
tpm_tis 7003.tpm_tis: 1.2 TPM (device-id 0xFE, rev-id 70)
Signed-off-by: Jason Gunthorpe jguntho...@obsidianresearch.com
---
drivers/char/tpm/tpm.c | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
diff
On Thu, Nov 22, 2012 at 03:36:21PM +, Grant Likely wrote:
Hmm... I've not tried it with assigned-address. I tried with two sibling
platform devices using just the 'reg' property. That the kernel will
complain about. For powerpc-only, the patch I posted allows the device
to get registered
On Mon, Nov 26, 2012 at 02:03:16PM +, Grant Likely wrote:
On Wed, 21 Nov 2012 14:02:40 -0700, Jason Gunthorpe
jguntho...@obsidianresearch.com wrote:
'assigned-addresses' is used for certain PCI device type nodes in
lieu of 'reg', since this is enforced by of/address.c, have
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-by: Jason Gunthorpe jguntho
On Tue, Dec 18, 2012 at 12:14:33AM +0800, Feng Tang wrote:
Sure, but my view on this is that it has nothing to do with
read_persistent_clock. If the RTC driver can run with IRQs off is a
property of the RTC driver and RTC hardware - it has nothing to do
with the platform. ARM platforms
kirkwood and PPC405
Signed-off-by: Jason Gunthorpe jguntho...@obsidianresearch.com
---
arch/powerpc/kernel/time.c |2 +-
drivers/rtc/Kconfig| 10 +-
drivers/rtc/Makefile |1 +
drivers/rtc/systohc.c | 44
include
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
subsystem completely and generically replaces this
functionality.
Tested on ARM kirkwood and PPC405
Signed-off-by: Jason Gunthorpe jguntho...@obsidianresearch.com
---
drivers/rtc/Kconfig |8
drivers/rtc/Makefile |1 +
drivers/rtc/systohc.c | 30
On Wed, Dec 12, 2012 at 11:40:26AM -0800, John Stultz wrote:
The option also overrides the call to any platform update_persistent_clock
so that the RTC subsystem completely and generically replaces this
functionality.
Tested on ARM kirkwood and PPC405
So I'm initially mixed on this, as it
On Wed, Dec 12, 2012 at 04:18:31PM -0800, John Stultz wrote:
I do, although again, in the case where the arch specific
implementation is better, we end up losing granularity (s390 is
the specific example I'm thinking of), since this prefers the RTC
implementation over the arch specific one.
On Thu, Dec 13, 2012 at 06:00:23PM -0800, John Stultz wrote:
So per Jason's related patch, he's made the point that the
persistent_clock and RTC class functionality are basically exclusive
(well, in his case, he said this with respect to updating the RTC,
not reading it - I don't mean to put
On Fri, Dec 14, 2012 at 11:13:30AM +0800, Feng Tang wrote:
This seems like a great use of that hardware resource, and no doubt
those mach's also have a class RTC driver available talking to
different hardware.
Interesting to know this, thanks for the info. For the x86 desktop
and mobile
On Fri, Dec 14, 2012 at 01:22:50PM -0800, John Stultz wrote:
Although from a timekeeping perspective, the read_persistent_clock()
interface is actually *much* preferred over the rtc HCTOSYS device.
Since read_persistent_clock() has the requirement that its safe to
call with IRQs disabled,
On Fri, Dec 14, 2012 at 08:26:29PM +, Grant Likely wrote:
If the soc_devices are getting triggered on that and they shouldn't be,
then we need a mechanism in the soc_bridge node to kick out of that
behavoir for its children.
Is this what you were thinking?
Not really. I see
kirkwood and PPC405
Signed-off-by: Jason Gunthorpe jguntho...@obsidianresearch.com
---
arch/powerpc/kernel/time.c |2 +-
drivers/rtc/Kconfig|9 +
drivers/rtc/Makefile |1 +
drivers/rtc/systohc.c | 44
include/linux
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
longer needed.
I'm sad to hear
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 a very
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
are 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 jguntho...@obsidianresearch.com
---
arch/powerpc/include
to touch the TPM.
Signed-off-by: Jason Gunthorpe jguntho...@obsidianresearch.com
---
drivers/char/tpm/tpm.c | 41 -
drivers/char/tpm/tpm.h |6 ++
2 files changed, 42 insertions(+), 5 deletions(-)
diff --git a/drivers/char/tpm/tpm.c b/drivers/char
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 PNP or OF are compiled in.
Signed-off-by: Jason Gunthorpe jguntho...@obsidianresearch.com
---
drivers/char/tpm/Kconfig |2 +-
drivers/char
) are already locked proprely
and can run in parallel with the user space interface anyhow.
- Move the user space data buffer and related goop into a
struct tpm_file, create one struct tpm_file per open file.
Signed-off-by: Jason Gunthorpe jguntho...@obsidianresearch.com
---
drivers/char/tpm
*'
Signed-off-by: Jason Gunthorpe jguntho...@obsidianresearch.com
---
include/linux/netfilter_ipv4/ip_tables.h |2 +-
include/linux/netfilter_ipv6/ip6_tables.h |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/netfilter_ipv4/ip_tables.h
b/include/linux
Signed-off-by: Jason Gunthorpe jguntho...@obsidianresearch.com
---
arch/arm/include/asm/memory.h |2 +-
arch/arm/kernel/vmlinux.lds.S | 47
2 files changed, 29 insertions(+), 20 deletions(-)
diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include
On Mon, Oct 01, 2012 at 04:39:53PM +0100, Dave Martin wrote:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x008000 0xc0008000 0x8000 0x372244 0x3a4310 RWE 0x8000
Not related directly to your patch, but I wonder why we don't we see
separate
On Mon, Oct 01, 2012 at 09:07:11AM +, peter.hu...@infineon.com wrote:
Hi Jason,
one quick question:
- TPM_BUFSIZE = 4096,
[...]
+ u8 data_bufferx[2048];
Why do you half the buffer size?
I missed 7f366784f5c2b8fc065 when I rebased the patch, thanks!
Jason
--
To unsubscribe
On Mon, Oct 01, 2012 at 09:17:28AM +, peter.hu...@infineon.com wrote:
Hi Jason,
The TPM will respond to TPM_GET_CAP with TPM_ERR_INVALID_POSTINIT if
TPM_STARTUP has not been issued. This will result in the TPM driver
failing to load and no way to recover. Detect this and automatically
On Mon, Oct 01, 2012 at 12:10:03PM -0500, Kent Yoder wrote:
I'm not familiar enough with how the power management flow works with
the TPM to do this. I don't think that can be the general case
because:
3. If stType = TPM_ST_STATE
a. If the TPM has no state to restore, the TPM MUST
On Mon, Oct 01, 2012 at 06:56:47PM +0100, Dave Martin wrote:
If the kernel is intended to be loadable at a physical address which is
not statically known, no ELF loader that does not ignore the ELF
phdr
In this case you can't really use a standard ELF loader to load the
kernel so,
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 jguntho
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 zImage and
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 jguntho...@obsidianresearch.com
---
drivers/char/tpm/Kconfig |2 +-
drivers/char/tpm
On Thu, Jan 10, 2013 at 11:25:44AM +0100, Thierry Reding wrote:
On Thu, Jan 10, 2013 at 09:17:19AM +, Arnd Bergmann wrote:
On Thursday 10 January 2013, Thierry Reding wrote:
On Wed, Jan 09, 2013 at 04:17:58PM -0700, Jason Gunthorpe wrote:
On Wed, Jan 09, 2013 at 04:12:31PM -0700
1 - 100 of 4366 matches
Mail list logo
