2
was about 650 with jumbos and 550 with standard.
i'd recommend it's networking performance to anyone.
todd underwood
[EMAIL PROTECTED]
On Thu, 1 Mar 2001, Hans Reiser wrote:
> Date: Thu, 01 Mar 2001 02:26:20 +0300
> From: Hans Reiser <[EMAIL PROTECTED]>
> To: "[
sorry for the resend. i sent this earlier today but still haven't seen it,
so i'm resending without attachments.
the originally attached netperf results are at:
http://www.unm.edu/~todd/udp.2.4.0-test9.9000mtu
http://www.unm.edu/~todd/udp.2.4.0-test9.1500mtu
http://www.unm.edu
27;m using sym53c8xx to access two scsi disks in a logical volume.
thanks,
todd underwood
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
imarily for their switch line, not for the
NICs) leaves quite a bit of doubt in my mind about the future of the card
and the openness of the firmware in particular.
todd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
cards on 32-bit cards on a 66MHz bus. i would expect
to get somewhat slower on a 33MHz bus but not catastrophically so
(certainly nothing as slow as 60MB/s or 480Mb/s).
what am i misunderstanding here?
todd
On Mon, 29 Jan 2001, Jeff V. Merkey wrote:
> Date: Mon, 29 Jan 2001 16:49:53 -0
ng a system with a limp PCI bus.
>
> Jeff
i appreciate that. i'm just trying to figure out why the numbers are so
low compared to the network speed you mentioned.
todd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
tion numbers. if they did, lots of fast networks would be less
appealing.
todd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
e source, Specializing in American
Racing wheels, Motegi Wheels, Motto wheels, Riax wheels, Nitto tires,
BF Goodrich tires, Yokohama tires & more. We also offer package deals
shipped directly to your door.
We look forward to partnering together.
Best regards,
Todd Hebert
LA Wheels Dire
he link to the Ethernet controller. Things on the "other" side of the
link are controlled outside of the e1000 driver.
Tushar's first suggestion was to check the PCIe payload settings in the
entire chain. Have you done that? Mismatches will cause hangs.
Todd Fujinaka
Technical Marke
hat the payload sizes match. What I do is "lspci -tvvv" to see what's
connected, then "lspci -s xx:xx.x -vvv" to check the devices on the link.
Thanks.
Todd Fujinaka
Technical Marketing Engineer
LAN Access Division (LAD)
Intel Corporation
todd.fujin...@intel.com
(503) 71
walks the PCIe tree or if the BIOS
just sets all the values to the minimum.
Todd Fujinaka
Technical Marketing Engineer
LAN Access Division (LAD)
Intel Corporation
todd.fujin...@intel.com
(503) 712-4565
-Original Message-
From: Ben Hutchings [mailto:bhutchi...@solarflare.com]
Sent: Tuesd
The only EEPROM I know about or can speak to is the one attached to the 82571
and it doesn't set the MaxPayloadSize. That's done by the BIOS.
Todd Fujinaka
Technical Marketing Engineer
LAN Access Division (LAD)
Intel Corporation
todd.fujin...@intel.com
(503) 712-4565
-Origin
Someone else pointed this out to me locally. If you have a non-client BIOS, you
should be able to set the MaxPayloadSize using setpci. You have to make sure
that you're being consistent throughout all the associated links.
Todd Fujinaka
Technical Marketing Engineer
LAN Access Division
.
Signed-off-by: Todd Poynor
---
include/linux/alarmtimer.h | 4
kernel/time/alarmtimer.c | 39 ++-
2 files changed, 42 insertions(+), 1 deletion(-)
diff --git a/include/linux/alarmtimer.h b/include/linux/alarmtimer.h
index 9069694..a899402 100644
--- a
Add support for clocks CLOCK_REALTIME_ALARM and CLOCK_BOOTTIME_ALARM,
thereby enabling wakeup alarm timers via file descriptors.
Signed-off-by: Todd Poynor
---
fs/timerfd.c | 131 ---
1 file changed, 108 insertions(+), 23 deletions
Enable wakeup alarm timers via file descriptors. Hook up alarmtimer
to timerfd via clocks CLOCK_REALTIME_ALARM and CLOCK_BOOTTIME_ALARM,
and add needed functions to alarmtimer.
fs/timerfd.c | 131 +
include/linux/alarmtimer.h |4 +
k
1 second while the alarm is allowed to be serviced or
other hopefully transient conditions preventing the alarm clear up.
Signed-off-by: Todd Poynor
---
kernel/time/alarmtimer.c | 18 +-
1 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/kernel/time/alarmtimer.c b
SI since I
had heard of problems with the AIC-78xx.
Thanks for any ideas or insight,
Todd Goodman
#
# Automatically generated by make menuconfig: don't edit
#
CONFIG_X86=y
CONFIG_ISA=y
# CONFIG_SBUS is not set
CONFIG_UID16=y
#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
#
Sorry, I was experiencing a senior moment and had the wrong CPU type
configured.
Once corrected everything is right in the world again.
Thanks to Mark Hahn for pointing out my mistake.
Todd
> -Original Message-
> My apologies in advance if I missed this in the archives (I found
minimize disturbing existing power management code. Comments
very much appreciated.
Patch 2/3 is a desktop-oriented example of PowerOP; embedded examples
will follow soon.
--
Todd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [E
01 00:00:00.0
+
+++ linux-2.6.12/drivers/powerop/powerop.c 2005-08-04 19:50:38.0
+
@@ -0,0 +1,253 @@
+/*
+ * PowerOP generic core functions
+ *
+ * Author: Todd Poynor <[EMAIL PROTECTED]>
+ *
+ * 2005 (c) MontaVista Software, Inc. This file is licensed under
+ *
Minimal PowerOP support for Intel Enhanced Speedstep "Centrino"
notebooks. These systems run at an operating point comprised of a cpu
frequency and a core voltage. The voltage could be set from the values
recommended in the datasheets if left unspecified (-1) in the operating
point, as cpufreq do
A minimal example of modifying cpufreq to use PowerOP for reading and
writing power parameters on Intel Centrino platforms. It would be
possible to move voltage table lookups to the PowerOP layer.
Index: linux-2.6.12/arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c
=
s based
on events received (new app running, low battery warning, etc.).
Any opinions on all that? Thanks,
--
Todd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Patrick Mochel wrote:
On Mon, 8 Aug 2005, Todd Poynor wrote:
(apologies for use of obsolete cpufreq mailing list address in my
initial message.)
...
PowerOP is intended to leave all power
policy decisions to higher layers.
What do those higher layers look like? Do you have a userspace
possible combinations of memory/bus/etc.
parameters for each unique cpu frequency. Thanks,
--
Todd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-inf
not be appropriate for all situations. The
notifiers are one example of this: DPM typically minimizes use of
notifiers and requires notifiers to be able to operate in interrupt and
in idle loop context, due to those additional situations in which DPM
manages power parameters.
--
Todd
-
T
nostic purposes, and in
the near future I'll propose alternative interfaces for setting entire
operating points, but the existing cpufreq interfaces will work just
fine regardless.
--
Todd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
w what the next
best choice is and set that operating point instead.
--
Todd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
.
--
Todd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
evel hierarchy of operating point name and single power parameter
attribute would be used, and the ordering into the array is handled by
the generic PowerOP core, which knows how to associate parameter names
with array indices). Older versions of DPM did use interfaces similar
to what you describe
of non-cpu-speed parameters sound interesting, and I'd be
happy to help figure out what to do about those vs. the lower machine
access layer I've discussed up until now. I'll think more about this
real soon now. Thanks,
--
Todd
-
To unsubscribe from this list: send the line &
ags)?
If so, these sorts of machine-specific power parameters are what
PowerOP is trying to address, allowing management of the underlying
machine-specific stuff to upper layers that may be presenting an
abstracted view of power/performance, such as CPU speed or speed ranges,
to the user. Th
process died, and the next bit indicates if the futex is not recoverable.
The rest of the futex contains the pid of the task that owns the futex lock
or zero if the futex is not locked.
Signed-off-by: Todd Kneisel <[EMAIL PROTECTED]>
fs/dcache.c |3
fs/inode.c
assignment any
day now. If anyone would like to see the glibc changes, I can provide
the patch under the Bull HN copyright. The patch applies to glibc-2.3.4.
Todd.
Daniel Walker <[EMAIL PROTECTED]> wrote on 07/05/2005 05:00:32 PM:
>
> You might want to CC Andrew Morton , and Rusty
===
--- /dev/null
+++ linux-2.6.13-rc4/arch/arm/mach-omap1/powerop.c
@@ -0,0 +1,157 @@
+/*
+ * PowerOP support for OMAP1
+ *
+ * Based on DPM OMAP code by Matthew Locke, Dmitry Chigirev, Vladimir
+ * Barinov, and Todd Poynor.
+ *
+ * 2005 (c) MontaVista Software, Inc. This file is
PowerOP is a system power parameter management API submitted for
discussion. PowerOP writes and reads power "operating points",
comprised of arbitrary values, called power parameters, that correspond
to registers, clocks, dividers, voltage regulators, etc. that may be
modified to set a basic power
A PowerOP sysfs UI backend for OMAP1 platforms, adding sysfs attributes
and show/store functions that correspond to the platform power
parameters.
An example usage on an OMAP1510 Innovator which does not have voltage
scaling and ignoring the DSP:
# echo -n 168-168-84 > /sys/powerop/new # DPLL 1
x-2.6.13-rc4/drivers/powerop/powerop_sysfs.c
===
--- /dev/null
+++ linux-2.6.13-rc4/drivers/powerop/powerop_sysfs.c
@@ -0,0 +1,398 @@
+/*
+ * PowerOP sysfs UI
+ *
+ * Author: Todd Poynor <[EMAIL PROTECTED]>
+ *
+ * 2005 (c) Mont
Jordan Crouse wrote:
Todd - do you have a ChangeLog from Take 1? :)
Right, here's what's changed in this version...
The generic structure of an operating point as an array of integers is
dropped. A struct powerop_point is now an entirely backend-defined
struct of arbitrary field
n vs.turbo
mode switching of CPU MHz, and some other exotic features. It has a
very specific set of "product points" validated by Intel that correspond
to the operating point abstraction. If nothing else, it may be
instructive to consider the variety of ways embedded platforms are being
not seem to be the problem.
If you need anymore information, or have questions, or wish me to test
anything, PLEASE feel free to contact me, I would really like to see
this bug resolved. =)
--
Todd Shetter
Feb 8 19:49:31 quark kernel: kernel BUG at filemap.c:81!
Feb 8 19:49:31 quark kernel
Marcelo Tosatti wrote:
On Wed, Feb 09, 2005 at 12:15:03AM -0500, Todd Shetter wrote:
Running slackware 10 and 10.1, with kernels 2.4.26, 2.4.27, 2.4.28,
2.4.29 with highmem 4GB, and highmem i/o support enabled, I get a system
lockup. This happens in both X and console. Happens with and
Marcelo Tosatti wrote:
On Wed, Feb 09, 2005 at 11:30:05AM -0500, Todd Shetter wrote:
Marcelo Tosatti wrote:
On Wed, Feb 09, 2005 at 12:15:03AM -0500, Todd Shetter wrote:
Running slackware 10 and 10.1, with kernels 2.4.26, 2.4.27, 2.4.28,
2.4.29 with highmem 4GB, and highmem i/o
Marcelo Tosatti wrote:
On Wed, Feb 09, 2005 at 03:47:28PM -0500, Todd Shetter wrote:
Running slackware 10 and 10.1, with kernels 2.4.26, 2.4.27, 2.4.28,
2.4.29 with highmem 4GB, and highmem i/o support enabled, I get a
system lockup. This happens in both X and console. Happens with and
Jeff Garzik wrote:
Marcelo Tosatti wrote:
On Wed, Feb 09, 2005 at 11:23:42PM -0500, Todd Shetter wrote:
Marcelo Tosatti wrote:
On Wed, Feb 09, 2005 at 03:47:28PM -0500, Todd Shetter wrote:
Running slackware 10 and 10.1, with kernels 2.4.26, 2.4.27,
2.4.28, 2.4.29 with highmem 4GB, and highmem i
Advertise custom sets of system power states for non-ACPI systems.
Currently, /sys/power/state shows and accepts a static set of choices
that are not necessarily meaningful on all platforms (for example,
suspend-to-disk is an option even on diskless embedded systems, and the
meaning of standby vs.
An example of custom power states for the TI OMAP family.
/sys/power/states supports a state named "deepsleep", which corresponds
to the platform state actually entered by the present-day system suspend
handler. It no longer offers the option of "disk" suspend which would
not normally be available
about replacing the /sys/power/state "standby"
and "mem" values to "sleep", and have a /sys/power/sleep attribute that
tells the methods of sleep available for the platform, much like
suspend-to-disk methods are handled today? So the sleep attribute would
handle &q
ak to allow a choice of actual state
entered. At some more opportune time in the future I'll suggest an
attribute that allows a choice of platform-specific method of
suspend-to-mem, somewhat like the "disk" attribute for suspend-to-disk.
Thanks,
--
Todd
-
To unsubscribe from thi
* Remove duplicate include.
* Avoid "mode set to ''" message when error updating /sys/power/disk.
Signed-off-by: Todd Poynor <[EMAIL PROTECTED]>
--- linux-2.6.11-rc4-orig/kernel/power/disk.c 2005-02-23 09:47:03.0
-0800
+++ linux-2.6.11-rc4-pm/kernel/power/d
I don't think
this would correspond well to hardware-managed CPU power states like
ACPI C states, for example. Thanks,
--
Todd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.ke
ific nature of event triggers
probably makes this quite difficult.
Mac OS X support for some of these concepts is documented at
developer.apple.com, looking for ideas to steal... Thanks,
--
Todd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body o
lock I would imagine), but for
performance I would think a better solution would be to copy the struct
since stale data is probably ok in this case.
Dereferencing a non-existent thread_struct is clearly not ok.
Would anyone familiar with this code care to comment?
--
-todd
-
To unsubscribe from
Alexander Viro wrote:
>
> On Tue, 1 May 2001, Todd Inglett wrote:
>
> > Perhaps this is old news...but...
> >
> > I can easily create a race when reading /proc//stat
> > (fs/proc/{base.c,array.c}) where a rapidly reading application, such as
> > "t
is in this state if the page
reference count is 1. But multiple processes *could* be reading the
same proc file holding additional artificial ref counts.
Hmm...perhaps if I scan the tasklist for my own task? If I am not in
the list I either return an error or faked info. I'll try this
also about mm, file, tty and sig fields. These
appear to be NULLed in do_exit(), but I haven't tracked down tty and sig
yet.
--
-todd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info a
Signed-off-by: Todd Kjos
---
drivers/android/binder.c | 194 +++
1 file changed, 146 insertions(+), 48 deletions(-)
diff --git a/drivers/android/binder.c b/drivers/android/binder.c
index 16288e7..c36e420 100644
--- a/drivers/android/binder.c
+++ b/drivers
This was introduced in the 2015 Nexus devices and should have been
submitted to the kernel then since we keep forward porting it to each
new device.
On Thu, Sep 8, 2016 at 9:12 AM, Todd Kjos wrote:
> In Android systems, the display pipeline relies on low
> latency binder transactions
An -ENOMEM
should be returned in this case, instead of switching over to an
indirect buffer as for non-MMAP_IO requests.
Signed-off-by: Todd Poynor
---
drivers/scsi/sg.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/sg.c b/drivers/scsi/sg.c
index d7f
ation with the mapping.
Signed-off-by: Todd Poynor
---
drivers/scsi/sg.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/sg.c b/drivers/scsi/sg.c
index 3a44b4bc872b..a20718e9f1f4 100644
--- a/drivers/scsi/sg.c
+++ b/drivers/scsi/sg.c
@@ -1233,6 +1233,7
files is removed since we get it every
time.
Signed-off-by: Todd Kjos
---
drivers/android/binder.c | 63 +++-
1 file changed, 30 insertions(+), 33 deletions(-)
diff --git a/drivers/android/binder.c b/drivers/android/binder.c
index fddf76ef5bd6..794
From: Todd Poynor
At device/driver registration time, convert a not-very-informative
info message to a more informative debug message, drop some not overly
helpful debug messages.
Signed-off-by: Todd Poynor
---
drivers/staging/gasket/gasket_core.c | 7 ++-
1 file changed, 2 insertions
From: Todd Poynor
There's no need to take an additional reference on the pci_dev structure
for the pointer copy saved in gasket data structures.
This reverts commit:
8dd8a48b9a7d ("staging: gasket: core: hold reference to pci_dev while used")
Reported-by: Dmitry Torokhov
Sign
From: Todd Poynor
Identify gasket as the subsystem printing various messages.
Add the driver name to appropriate messages to indicate which driver
has a problem.
Signed-off-by: Todd Poynor
---
drivers/staging/gasket/gasket_core.c | 13 +
1 file changed, 9 insertions(+), 4
From: Todd Poynor
More cleanups for the gasket+apex drivers.
Patched changed in v2 from v1:
staging: gasket: core: print driver version code at registration time
staging: gasket: core: move driver loaded log after error cases
Above 2 patches replaced by new patch:
staging
From: Todd Poynor
Remove logs for loading gasket drivers.
Signed-off-by: Todd Poynor
---
drivers/staging/gasket/gasket_core.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/staging/gasket/gasket_core.c
b/drivers/staging/gasket/gasket_core.c
index 2b75f100da4d3..fa477d0c3c74c
From: Todd Poynor
Device enable/disable operations are moving from being initiated through
the gasket framework to being initiated by the gasket device driver.
The driver can perform any processing needed for these operations before
or after the calls into the framework. Neither of these
From: Todd Poynor
Remove gasket wrapping of PCI probe, enable, disable, and remove
functions. Replace with calls to add and remove PCI gasket devices,
to be called by the gasket device drivers.
Signed-off-by: Todd Poynor
---
drivers/staging/gasket/gasket_core.c | 82
From: Todd Poynor
Apex driver moves PCI core calls like probe, enable, and remove from
gasket to apex. Call new functions in gasket to register apex as a PCI
device to the gasket framework.
Signed-off-by: Todd Poynor
---
drivers/staging/gasket/apex_driver.c | 49
From: Todd Poynor
Remaining info-level logs in gasket core converted to debug-level; the
information is not needed during normal system operation.
Signed-off-by: Todd Poynor
---
drivers/staging/gasket/gasket_core.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a
From: Todd Poynor
Gasket device drivers are now in charge of orchestrating the device add
and removal sequences, so the callbacks from the framework to the device
drivers for these events are no longer needed.
Signed-off-by: Todd Poynor
---
drivers/staging/gasket/gasket_core.c | 10
From: Todd Poynor
Stop wrapping PCI core calls like probe, enable, remove, etc. in the
gasket framework, move these calls to the device driver instead. Have
gasket drivers call into framework on init, enable, disable,
etc. sequences, rather than the other way around. Remove the
gasket-to
From: Todd Poynor
If kcalloc() returns NULL in put_mapping(), continue to clean up state,
including dropping the reference on the struct device and free attribute
memory.
Signed-off-by: Todd Poynor
---
drivers/staging/gasket/gasket_sysfs.c | 13 ++---
1 file changed, 6 insertions
From: Todd Poynor
A copy-and-pasted comment from another code sequence is removed from
gasket core init sequence.
Signed-off-by: Todd Poynor
---
drivers/staging/gasket/gasket_core.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/staging/gasket/gasket_core.c
b/drivers/staging
From: Todd Poynor
Move gasket device enable/disable functions from internal calls to
external calls from the gasket device drivers. The device driver will
call these functions at appropriate times in its processing, placing
the device driver in control of this sequence and reducing the need for
From: Todd Poynor
The apex device is left out of reset mode at the end of device
probe/initialize processing. Add a call to enter reset at the end of
the sequence, triggering power gating and other low power features.
Signed-off-by: Todd Poynor
---
drivers/staging/gasket/apex_driver.c | 4
From: Todd Poynor
Keep mutex held across the unregistration operation, until the
driver_desc field of the global table is removed, to prevent a
concurrent accessor from looking up the driver_desc while
gasket_unregister_device() is in the processing of removing it.
Reported-by: Guenter Roeck
From: Todd Poynor
Gasket device drivers now call into the gasket framework to initialize
and de-initialize, rather than the other way around. The calling code
can perform sysfs setup and cleanup actions without callbacks from the
framework. Remove the sysfs setup and cleanup callbacks.
Signed
From: Todd Poynor
The gasket framework no longer provides callbacks to the device driver
for sysfs setup and teardown. Move the sysfs setup code to the device
probe function. Apex does not implement sysfs cleanup code.
Signed-off-by: Todd Poynor
---
drivers/staging/gasket/apex_driver.c | 14
From: Todd Poynor
Gasket framework now places device drivers in charge of calling APIs to
enable and disable gasket device operations. Make the appropriate calls
from the apex driver.
Signed-off-by: Todd Poynor
---
drivers/staging/gasket/apex_driver.c | 12
1 file changed, 12
From: Todd Poynor
Gasket device drivers are now in charge of the device add and remove
sequences; the framework callbacks for these are deleted. Move the
apex device add callback code to the probe function. Apex did not
implement the removal callback.
Signed-off-by: Todd Poynor
---
drivers
From: Todd Poynor
These are not implemented for apex, and are now being removed from the
gasket framework.
Signed-off-by: Todd Poynor
---
drivers/staging/gasket/apex_driver.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/staging/gasket/apex_driver.c
b/drivers/staging/gasket
true;
return false;
Do folks agree that this is incorrect behavior? Does this fix look
appropriate and safe? Other ideas?
-Todd
Fixed a coding style issue.
Signed-off-by: Tom Todd
---
drivers/acpi/bus.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index 84b4a62018eb..73e43d81ec63 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -962,7 +962,7
From: Todd Poynor
Add initcall_debug logs for each driver device probe call, for example:
probe of a380.ramoops returned 1 after 3007 usecs
This replaces the previous code added to report times for deferred
probes. It also reports OF platform bus device creates that were
formerly
ithout changing these bits..
>
> Thanks,
>
> [1] https://www.kernel.org/doc/html/v4.18/driver-api/uio-howto.html
> [2] drivers/staging/gasket/gasket_core.h :: struct gasket_driver_desc
> [3] drivers/staging/gasket/apex_driver.c
> [4] include/linux/uio_driver.h
>
> --
> Darwi
> http://darwish.chasingpointers.com
Thanks -- Todd
annot allocate new
fds in the target (probably due to out of file descriptors),
the transaction is discarded with a log message. In the old
implementation this would have been detected in the sender
context and failed prior to sending.
Signed-off-by: Todd Kjos
---
drivers/android/Kconfig
annot allocate new
fds in the target (probably due to out of file descriptors),
the transaction is discarded with a log message. In the old
implementation this would have been detected in the sender
context and failed prior to sending.
Signed-off-by: Todd Kjos
---
v2: use "%zu" printk fo
annot allocate new
fds in the target (probably due to out of file descriptors),
the transaction is discarded with a log message. In the old
implementation this would have been detected in the sender
context and failed prior to sending.
Signed-off-by: Todd Kjos
---
v2: use "%zu" printk fo
Sorry, forgot to bump the version. Ignore this one.
On Tue, Aug 28, 2018 at 1:43 PM Todd Kjos wrote:
>
> Binder uses internal fs interfaces to allocate and install fds:
>
> __alloc_fd
> __fd_install
> __close_fd
> get_files_struct
> put_files_struct
>
> These were
annot allocate new
fds in the target (probably due to out of file descriptors),
the transaction is discarded with a log message. In the old
implementation this would have been detected in the sender
context and failed prior to sending.
Signed-off-by: Todd Kjos
---
v2: use "%zu" printk fo
On Wed, Aug 29, 2018 at 12:00 AM Christoph Hellwig wrote:
>
> > config ANDROID_BINDER_IPC
> > bool "Android Binder IPC Driver"
> > - depends on MMU
> > + depends on MMU && !CPU_CACHE_VIVT
>
> Thats is a purely arm specific symbol which should not be
> used in common code. Nevermind
From: Todd Poynor
gasket_alloc_dev can retrieve the device name from the parent parameter,
a separate parameter isn't needed for this. Rename the variable to
better reflect its meaning, as the name of the parent device for which a
gasket device is being allocated.
Signed-off-by: Todd P
From: Todd Poynor
Todd Poynor takes over for John Joseph.
Signed-off-by: John Joseph
Signed-off-by: Todd Poynor
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index af64fe0f0b41f..f3466b5c50482 100644
--- a/MAINTAINERS
+++ b
From: Todd Poynor
Pass the gasket driver descriptor to the interrupt init function, rather
than exploding out separate parameters from various fields of that
structure. This allows us to make more localized changes to the types
of interrupts supported (MSIX vs. wire, etc.) without affecting the
From: Todd Poynor
Use of readl() is deprecated; readl_relaxed() with appropriate memory
barriers is preferred. Switch to relaxed reads and writes for better
performance as well. Memory barriers required for I/O vs. normal
memory access on Apex devices have already been explicitly coded in the
From: Todd Poynor
Some explicit memory barriers in the page table code are not necessary,
either because:
(a) The barrier follows a non-relaxed MMIO access that already performs
a read or write memory barrier.
(b) The barrier follows DMA API calls for which the device-visible
effects of IOMMU
From: Todd Poynor
Interrupt types PCI_MSI and PLATFORM_WIRE are unused and unimplemented.
Remove these.
Signed-off-by: Todd Poynor
---
drivers/staging/gasket/gasket_core.h | 11
drivers/staging/gasket/gasket_interrupt.c | 34 +--
2 files changed, 1 insertion
From: Todd Poynor
gasket_perform_mapping() call dma_mapping_error() to determine if
mapping failed.
Signed-off-by: Todd Poynor
---
drivers/staging/gasket/gasket_page_table.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/gasket/gasket_page_table.c
b
1 - 100 of 707 matches
Mail list logo
