v2: teach lockdep about shrinker locking patters (danvet) and
> convert to obj->resv locking (danvet)
> v3: fix get_vaddr locking for legacy userspace (relocs), devcoredump,
> and rd/hangrd
For the series:
Reviewed-by: Kristian H. Kristensen
> Rob Clark (23):
> drm/msm:
On Mon, Oct 19, 2020 at 10:45 PM Rob Clark wrote:
>
> From: Rob Clark
>
> We cannot switch to using obj->resv for locking without first moving all
> the copy_from_user() ahead of submit_lock_objects(). Otherwise in the
> mm fault path we aquire mm->mmap_sem before obj lock, but in the submit
> p
On Mon, Oct 19, 2020 at 10:45 PM Rob Clark wrote:
>
> From: Rob Clark
>
> Move grabbing the bo lock into shrinker, with a msm_gem_trylock() to
> skip over bo's that are already locked. This gets rid of the nested
> lock classes.
>
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/msm/msm_gem.
eat patch set. Daniel has some good points and nothing that
requires big changes, but on the other hand, I'm not sure it's
something that needs to block this set either.
Either way, for the series
Reviewed-by: Kristian H. Kristensen
> Rob Clark (14):
> drm/msm: Use correct drm_gem
use dma_resv_trylock instead of
> trying to play clever games outsmarting lockdep.
>
> I recently wrote an entire blog length rant on why I think
> mutex_lock_nested is too dangerous to be useful:
>
> https://blog.ffwll.ch/2020/08/lockdep-false-positives.html
>
> Not anything abo
patch applies fine, so I guess it was just missed
somewhere. If it could be added to the next 4.14 release, it would be
much appreciated.
BR,
Kristian
ng
my own work-around :)
Kristian
volved!
I just have one question, is there a specific reason for the patch not
being resubmitted or Daniele's work not resumed? I do not use any of
the aggregation-stuff, so I don't know how that is affected by for
example Paul's change. If there is anything I can do to help, please
let me know.
BR,
Kristian
On Tue, Sep 1, 2020 at 8:41 AM Rob Clark wrote:
>
> From: Rob Clark
>
> This reduces the spam in dmesg when we start hitting the shrinker, and
> replaces it with something we can put on a timeline while profiling or
> debugging system issues.
That is a good solution,
Revie
true, true);
> if (ret) {
> DPU_DEBUG_PLANE(pdpu, "Check plane state failed (%d)\n", ret);
Right, I can see how the drm convention of scaling factor being from
dest to src (ie 2x scaling up src to dst is as scale factor of 0.5).
Thanks for fixing this,
Tested-by: Kristian H. Kristensen
Reviewed-by: Kristian H. Kristensen
> --
> 1.9.1
>
Yes, this is a big improvement for the display I have here. Thanks Kalyan.
Tested-by: Kristian H. Kristensen
On Thu, Jun 25, 2020 at 3:21 PM Doug Anderson wrote:
>
> Hi,
>
> On Thu, Jun 25, 2020 at 5:17 AM Kalyan Thota wrote:
> >
> > This change enables dither blo
Здравейте
Аз съм г-н Кристиан Даниелс от Уелс, работя тук в Ломе, с A.D.B-TOGO.
Имаме починал закъснял клиент, който случайно споделя едно и също
фамилно име с вас и всички негови документи на хартия като
относителни, Той остави в банката огромна сума на стойност 2,9 милиона
долара, която остава н
On 20.08.2019 23.38, Rafael J. Wysocki wrote:
On Tuesday, August 20, 2019 3:29:48 PM CEST Rafael J. Wysocki wrote:
On Tue, Aug 20, 2019 at 3:10 PM Kristian Klausen wrote:
On 19.08.2019 22.41, Rafael J. Wysocki wrote:
On Mon, Aug 19, 2019 at 5:47 PM Kristian Klausen wrote:
On 19.08.2019
On 19.08.2019 22.41, Rafael J. Wysocki wrote:
On Mon, Aug 19, 2019 at 5:47 PM Kristian Klausen wrote:
On 19.08.2019 11.05, Rafael J. Wysocki wrote:
On Monday, August 19, 2019 9:59:02 AM CEST Rafael J. Wysocki wrote:
On Fri, Aug 16, 2019 at 10:26 PM Kristian Klausen wrote:
On 02.08.2019
On 19.08.2019 11.05, Rafael J. Wysocki wrote:
On Monday, August 19, 2019 9:59:02 AM CEST Rafael J. Wysocki wrote:
On Fri, Aug 16, 2019 at 10:26 PM Kristian Klausen wrote:
On 02.08.2019 12.33, Rafael J. Wysocki wrote:
Hi All,
On top of the "Simplify the suspend-to-idle control flow&q
On 02.08.2019 12.33, Rafael J. Wysocki wrote:
Hi All,
On top of the "Simplify the suspend-to-idle control flow" patch series
posted previously:
https://lore.kernel.org/lkml/71085220.z6FKkvYQPX@kreacher/
sanitize the suspend-to-idle flow even further.
First off, decouple EC wakeup from the LP
Hi,
On Mon, Jun 24, 2019 at 6:26 PM Bjørn Mork wrote:
> Doh! Right you are. Thanks to both you and Andrey for quick and good
> help.
>
> We obviously have some bad code patterns here, since this apparently
> worked for Kristian by pure luck.
Thanks a lot to everyone for spottin
re than once.
Reviewed-by: Kristian H. Kristensen
> Signed-off-by: Jordan Crouse
> ---
>
> drivers/gpu/drm/msm/msm_iommu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_iommu.c b/drivers/gpu/drm/msm/msm_iommu.c
> index 12bb54c
>
>> * Remove the work altogether.
>>
>> Those are in descending order of (my recommended) preference.
>
> Thanks,
> Domenico
>
> [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919356
>
It was [pointed out] by one of our license group that [hash.h] is
onntrack entry.
Signed-off-by: Kristian Evensen
---
net/netfilter/nfnetlink_queue.c | 68 +
1 file changed, 68 insertions(+)
diff --git a/net/netfilter/nfnetlink_queue.c b/net/netfilter/nfnetlink_queue.c
index c97966298..150c11ff4 100644
--- a/net/netfilter/nfnetli
he bug report.
Disabling MSI interrupts with msi_enable=0 (and Ching's patches) does
resolve the issue, but whether it should be considered a fix or a
workaround is not for me to say.
Regards,
Kristian Rasmussen
Hei,
On Tue, Nov 7, 2017 at 2:02 PM, Bjørn Mork wrote:
> And his should probably go to stable as well? with a
>
> Fixes: 32f7adf633b9 ("net: qmi_wwan: support "raw IP" mode")
Yes, I forgot to add the fixes-tag + comment about stable. Should I submit a v2?
-Kristian
[ 304.031034]
[ 304.032805] ---[ end trace b778c482b3f0bda9 ]---
[ 304.041384] Kernel panic - not syncing: Fatal exception in interrupt
[ 304.051975] Rebooting in 3 seconds..
While the oops is for a 4.9-kernel, I was able to trigger the same oops with
net-next as of yesterday.
Signed-off-by: Kris
Nickey Yang writes:
> This patch correct Feedback divider setting:
> 1、Set Feedback divider [8:5] when HIGH_PROGRAM_EN
> 2、Due to the use of a "by 2 pre-scaler," the range of the
> feedback multiplication Feedback divider is limited to even
> division numbers, and Feedback divider must be greater
nalogix_dp_psr_work(struct work_struct *work)
>
> vact_end = crtc->mode.vtotal - crtc->mode.vsync_start +
> crtc->mode.vdisplay;
We don't need vact_end anymore here.
Kristian
> - ret = rockchip_drm_wait_line_flag(dp->encoder.crtc, vact_end,
> -
ling")
Reported-by: Henning Schild
Signed-off-by: Kristian Evensen
---
drivers/net/usb/cdc_ether.c | 38 +++---
1 file changed, 31 insertions(+), 7 deletions(-)
diff --git a/drivers/net/usb/cdc_ether.c b/drivers/net/usb/cdc_ether.c
index 45e5e43..fe7b288 10064
On Wed, Nov 30, 2016 at 10:51 PM, Bjørn Mork wrote:
> Kristian Evensen writes:
>
>> +void usbnet_cdc_zte_status(struct usbnet *dev, struct urb *urb)
>> +{
>> + struct usb_cdc_notification *event;
>> +
>> + if (urb->actual_length &l
"cdc_ether: Improve ZTE MF823/831/910 handling")
Reported-by: Henning Schild
Signed-off-by: Kristian Evensen
---
drivers/net/usb/cdc_ether.c | 38 +++---
1 file changed, 31 insertions(+), 7 deletions(-)
diff --git a/drivers/net/usb/cdc_ether.c b/drivers
PIDs/MAC addresses. In other words, it seems to be the default
behavior of ZTE CDC Ether devices (thanks Lars Melin).
Signed-off-by: Kristian Evensen
Acked-by: Oliver Neukum
---
drivers/net/usb/cdc_ether.c | 51 +
1 file changed, 51 insertions(+)
dif
evices (thanks Lars Melin).
Signed-off-by: Kristian Evensen
---
drivers/net/usb/cdc_ether.c | 54 +
1 file changed, 54 insertions(+)
diff --git a/drivers/net/usb/cdc_ether.c b/drivers/net/usb/cdc_ether.c
index 7cba2c3..874caad 100644
--- a/drivers/n
On Tue, Jul 19, 2016 at 2:33 PM, Oliver Neukum wrote:
> On Tue, 2016-07-19 at 13:49 +0200, Kristian Evensen wrote:
>> @@ -428,10 +434,47 @@ int usbnet_cdc_bind(struct usbnet *dev, struct
>> usb_interface *intf)
>> return status;
>> }
>>
&g
the bogus MAC have been seen on devices with several
different PIDs/MAC addresses. In other words, it seems to be the default
behavior of ZTE CDC Ether devices (thanks Lars Melin).
Signed-off-by: Kristian Evensen
---
drivers/net/usb/cdc_ether.c | 60 +
1 f
Hi Lars,
On Tue, Jul 19, 2016 at 10:30 AM, Lars Melin wrote:
> On 2016-07-19 13:40, Kristian Evensen wrote:
>
>> I guess I can match on the VID/PID in usbnet, but won't it be cleaner
>> to add a new bind() function (in cdc_ether) which matches the two PIDs
>> an
_ether) which matches the two PIDs
and leave usbnet as is? Or am I misunderstanding how to add this
functionality to usbnet?
-Kristian
tworking core.
I had a look at some other drivers, and I think we need to be very
careful about making setting a random MAC too generic. For example, we
might be unlucky and break the possibly_iphdr()-code/assumption in
qmi_wwan.c. And there is probably more code/assumptions like that in
the network stack.
-Kristian
he networking core? If we go for the latter, what would be
correct place for this piece of code, register_netdevice()?
-Kristian
On Mon, Jul 18, 2016 at 3:50 PM, Oliver Neukum wrote:
> No, you misunderstand me. I don't want quirks if we can avoid it.
> But if you need to do this for rndis_host and cdc_ether and maybe other
> drivers you should not be touching drivers. This belongs into the core
> ethernet code. Your code is
Hi,
On Mon, Jul 18, 2016 at 3:01 PM, Oliver Neukum wrote:
> On Mon, 2016-07-18 at 14:24 +0200, Kristian Evensen wrote:
>> The firmware in the ZTE MF823/831/910 modems/mifis use OS fingerprinting to
>> determine which type of device to export. In addition, these devices export
>
operational state and I can receive/sent traffic without
problems. I also tested with some other cdc_ether devices I have and did
not find any problems/regressions caused by the two general changes.
Signed-off-by: Kristian Evensen
---
drivers/net/usb/cdc_ether.c | 53
From: Kristian Evensen
Some devices of the same type all export the same, random MAC address. This
behavior has been seen on the ZTE MF910, MF823 and MF831, and there are
probably more devices out there. Fix this by generating a valid random MAC
address if we read a random MAC from device.
Also
On Thu, Jul 14, 2016 at 9:54 AM, Kristian Evensen
wrote:
> Hi Bjørn,
>
> On Thu, Jul 14, 2016 at 12:23 AM, Bjørn Mork wrote:
>>
>> Or how about the more generic?:
>>
>> if (bp[0] & 0x02)
>> eth_hw_addr_random(net);
>>
imilar screwups from other vendors too.
Great idea, thanks. After submitting the patch I found some other
devices with a similar bug, and there are probably even more out
there. I will update patch and resubmit.
-Kristian
From: Kristian Evensen
All ZTE MF910 mifis, at least on some revisions, export the same MAC
address (36:4b:50:b7:ef:da). Check for this MAC address and set a random
MAC if detected.
Also, changed the memcpy() to ether_addr_copy(), as pointed out by
checkpatch.
Signed-off-by: Kristian Evensen
From: Kristian Evensen
There seems to be a new version of the Microchip Pick16F1454 with a
different PID (0xf2f7). This device should also be ignored by the HID
driver. The PID was observed with the second version of the Yepkit Ykush
USB hub.
Signed-off-by: Kristian Evensen
---
drivers/hid
Kristian Nielsen writes:
> Benjamin LaHaise writes:
>
>> Linus just pushed out 3.13-rc5 that has changes to aio_migratepage() that
>> should make it much more robust, as well as other fixes. Can you please
>> give it a spin as well and let me know if it works? Than
Benjamin LaHaise writes:
> Linus just pushed out 3.13-rc5 that has changes to aio_migratepage() that
> should make it much more robust, as well as other fixes. Can you please
> give it a spin as well and let me know if it works? Thanks a bunch!
Ok, will do.
- Kristian.
--
To un
st that can be done for now.
Thanks for following up on this!
- Kristian.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
with unpatched -rc4
for some time to check if it appears again? Anything else?
- Kristian.
Dave Jones writes:
> On Mon, Dec 02, 2013 at 06:10:46PM +0800, Gu Zheng wrote:
> > Hi Kristian, Dave,
> >
> > Could you please help to check whether the following patch can f
Gu Zheng writes:
> Hi Kristian, Dave,
>
> Could you please help to check whether the following patch can fix this issue?
> Signed-off-by: Gu Zheng
> ---
> fs/aio.c | 28 ++--
> 1 files changed, 10 insertions(+), 18 deletions(-)
>
Ok. I'
rns up again, or should I
install -rc2 and see if it goes away?
I was not doing anything special at the time, normal desktop load (I was using
the evince pdf viewer).
Let me know if there is anything else I can do to help track this down?
- Kristian.
Full details:
I put my .confi
Jan Kara writes:
> On Mon 03-09-12 10:45:15, Kristian Nielsen wrote:
>> It appears that ext3 and ext4 fdatasync() does not fully sync data to
>> disk. Specifically, when new data is written at the end (so that the file
>> length is increased), not all of the new data i
with eg.
tail -1 append.log
perl -lne '$x = $_ if $_ > $x; END {print $x}' inplace.log
Please let me know if there is any additional information that I can supply to
help.
(BTW, the problem is fixed/worked-around in MariaDB by using fsync() instead
of fdatasync() when
On 10/1/07, Pieter Palmers <[EMAIL PROTECTED]> wrote:
> Stefan Richter wrote:
> >> This duplicates the read cycle timer feature of raw1394 (added in Linux
> >> 2.6.21) in firewire-core's userspace ABI.
> >
> > Kristian and Pieter, does this simple duplic
e is a bitch.
> but drm_zalloc shouldjust alias to drm_calloc really..
drm_calloc calls kcalloc which performs an integer overflow check on the
'n' and 'size' arguments, which isn't needed for drm_zalloc. Small
detail, of course, but I don't see the problem w
On Mon, 2007-06-25 at 16:31 -0400, Steven Rostedt wrote:
> On Mon, 2007-06-25 at 16:07 -0400, Kristian Høgsberg wrote:
>
> > > Maybe we should be looking at something like GENERIC_SOFTIRQ to run
> > > functions that a driver could add. But they would run only on the CPU
&
On Mon, 2007-06-25 at 15:11 -0400, Steven Rostedt wrote:
> On Mon, 2007-06-25 at 14:48 -0400, Kristian Høgsberg wrote:
> ...
> > However, I don't really understand how you can discuss a wholesale
> > replacing of tasklets with workqueues, given the very different
> >
ftirqs or workqueues
on a case by case basis is a better approach. That way we also avoid
the gross wrappers.
Kristian
-
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/
, then
idr_remove_all() to remove all ids, and idr_destroy() to free
up the cached idr_layers.
Signed-off-by: Kristian Hoegsberg <[EMAIL PROTECTED]>
---
include/linux/idr.h |1 +
lib/idr.c | 47 +++
2 files changed, 48 insertions
difference for sparse idrs, but more importantly, it's a nicer
way to iterate through the elements.
The drm subsystem is moving to idr for tracking contexts and drawables, and
with this change, we can use the idr exclusively for tracking these
resources.
Signed-off-by: Kristian Hoegsberg &l
and I
don't think the length of the names is a problem. If you end up
typing the module names too much, you're doing something wrong or
working on the firewire stack, in which case you're screwed anyway :)
Kristian
-
To unsubscribe from this list: send the line "unsubscri
might be
useful on a more general level. It's struct fw_attribute_group in
drivers/firewire/fw-device.h and the implementation is
init_fw_attribute_group in drivers/firewire/fw-device.c. But I agree,
attribute groups require a fair bit of boiler plate code.
cheers,
Kristian
-
To unsubscribe fro
Plus, when the drivers
are loaded as modules, the module name will be in the stack trace. I can
track down the most generic sounding functions and give them a fw_ prefix, but
doing a whole-sale prefixing of static functions will make the source more
noisy and reduce readabilty - I'm not sur
Stefan Richter wrote:
Kristian Høgsberg wrote:
I was trying to be clever and only allocate the host once the device had
been discovered and initialized. I have now changed the code to just
allocate the host up front and use the hostdata mechanism for the
sbp2_device struct, which also
struct sbp2_device *sd = unit->device.driver_data;
+
+ if (sd->scsi_host != NULL) {
+ scsi_remove_host(sd->scsi_host);
+ scsi_host_put(sd->scsi_host);
+ }
+ sd->scsi_host = NULL;
+}
This function seems rather oddly named. And the
soon.
thanks,
Kristian
-
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/
Christoph Hellwig wrote:
On Wed, May 02, 2007 at 05:11:45PM -0400, Kristian H??gsberg wrote:
The firewire-cdev.h file is meant to be a self-contained userspace header
file and shouldn't include other kernel header files. All duplicated
values are standardized ieee1394 values and won&#
new patches soon.
Kristian
-
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/
p down the road are strictly additions anyway. I think it makes
sense to keep the version number there, though, as a way to advertise which
ioctls are present.
Kristian
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTE
close to none of the export functions have kerneldoc
comment blocks. I think we really should have them on something that
is a driver API.
Yeah... I'll sit down and try to document it better.
thanks
Kristian
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
useful things into lib/ so that everyone doesn't invent
their own.
I'll pull in Ivo's patch and add it to the firewire branch.
thanks,
Kristian
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majo
he sbp2 case for the old drivers is
still in there and in the end mkinitrd works with either stack.
Kristian
-
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/majordo
ach than implementing
ad-hoc allocation data structures.
Thanks for the reviews, I'll look through your other emails.
Kristian
-
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/
dn't mind moving it to lib/
though, but nobody else in the kernel is using this bit order.
Kristian
-
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/majordo
ut a #ifndef
__FW_COMMON_DEFINES protection around the duplicate values, I guess, but I'm
just wondering why I never saw a "symbol redefined" warning...
Kristian
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
Adrian Bunk wrote:
On Wed, May 02, 2007 at 02:48:11PM +0200, Stefan Richter wrote:
Olaf Hering wrote:
On Tue, May 01, Kristian Høgsberg wrote:
drivers/firewire/Kconfig | 60 ++
NACK.
Upgrade the current drivers/ieee1394/ with the new code,
Last time I believe I was the only one
ching that list.
...
(If this division seems odd, don't blame Kristian, blame me. :-)
I'm looking forward to comments.
Looks good to me, thanks Stefan. The first three patches don't compile on
their own as they are, but it's a good split of the core stack.
Kristian
-
To un
Olaf Hering wrote:
On Tue, May 01, Kristian Høgsberg wrote:
drivers/firewire/Kconfig | 60 ++
NACK.
Upgrade the current drivers/ieee1394/ with the new code, and keep all
existing module names.
What's your reasoning here? Having different module names allows people to
co
ck is bit-rotting anyway.
- Some SBP-2 (storage) devices fail after significant amounts of IO.
Not clear what the problem is, but I can reproduce it here and am
working on fixing it.
Please pull from the juju branch in Stefans repo:
git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/
the primary reasons for me to write an alternative
stack was to be able to leave linux1394 in maintenence mode. This way
I wont screw up existing functionality in the old stack, and will be
able to make big changes without worrying about porting over every
single driver.
Kristian
-
To unsubscrib
On Mon, 2007-03-05 at 19:32 +0100, Rafael J. Wysocki wrote:
> On Monday, 5 March 2007 15:44, Dmitry Torokhov wrote:
> > On 3/1/07, Kristian Grønfeldt Sørensen <[EMAIL PROTECTED]> wrote:
> > > On Thu, 2007-03-01 at 15:25 -0500, Dmitry Torokhov wrote:
> > > > On
On Thu, 2007-03-01 at 15:25 -0500, Dmitry Torokhov wrote:
> On 3/1/07, Kristian Grønfeldt Sørensen <[EMAIL PROTECTED]> wrote:
> >
> > Hmmm.
> >
> > Now i get this BUG:
> >
>
> Does it die the same way if you just unload the button driver without
>
ld be fixed. */
713 #define ARCH_HAS_PREFETCH
714 static inline void prefetch(const void *x)
715 {
716 alternative_input(ASM_NOP4,
717 "prefetchnta (%1)",
718 X86_FEATURE_XMM,
719 "r" (x));
720
On Thu, 2007-03-01 at 10:01 -0500, Dmitry Torokhov wrote:
> On 3/1/07, Kristian Grønfeldt Sørensen <[EMAIL PROTECTED]> wrote:
> > On Thu, 2007-03-01 at 00:36 -0500, Dmitry Torokhov wrote:
> > >
> > > Please try the patch below.
> >
> > Hmmm. Is the di
gt; >
> > Hm, interesting. Looks like a pointer points to nowhere in
> > input_unregister_device(), but I don't know which one. This may be
> > an evdev problem ...
> >
>
> Please try the patch below.
Hmmm. Is the diff against 2.6.20? All hunks except one fails when i try
On Wed, 2007-02-28 at 01:05 +0100, Rafael J. Wysocki wrote:
> On Wednesday, 28 February 2007 00:12, Kristian Grønfeldt Sørensen wrote:
> > On Tue, 2007-02-27 at 23:34 +0100, Rafael J. Wysocki wrote:
> > > On Tuesday, 27 February 2007 23:23, Kristian Grønfeldt Sørensen wrote:
&g
On Tue, 2007-02-27 at 23:30 +0100, Rafael J. Wysocki wrote:
> On Tuesday, 27 February 2007 23:04, Rafael J. Wysocki wrote:
> > Hi,
> >
> > On Tuesday, 27 February 2007 19:45, Kristian Grønfeldt Sørensen wrote:
> > > Hi.
> > >
> > > P
On Tue, 2007-02-27 at 23:34 +0100, Rafael J. Wysocki wrote:
> On Tuesday, 27 February 2007 23:23, Kristian Grønfeldt Sørensen wrote:
> > On Tue, 2007-02-27 at 23:04 +0100, Rafael J. Wysocki wrote:
> > > Hi,
> > >
> > > On Tuesday, 27 February 2007 19:4
On Tue, 2007-02-27 at 23:04 +0100, Rafael J. Wysocki wrote:
> Hi,
>
> On Tuesday, 27 February 2007 19:45, Kristian Grønfeldt Sørensen wrote:
> > Hi.
> >
> > PROBLEM: "BUG:" when resumimg from suspend-to-ram
> >
> > My laptop have a proble
Pete Zaitcev wrote:
On Thu, 25 Jan 2007 16:18:35 -0500, Kristian Høgsberg <[EMAIL PROTECTED]> wrote:
Indeed, I've just moved to an in-tree development model now. I still think
the out-off-tree model is a good way to prototype, get started and reach
"critical mass" with
Greg KH wrote:
On Thu, Jan 25, 2007 at 03:38:24PM -0800, Pete Zaitcev wrote:
On Thu, 25 Jan 2007 16:18:35 -0500, Kristian H??gsberg <[EMAIL PROTECTED]>
wrote:
I see that ORBs are always allocated with a call (like SKB) and not
embedded into drivers (like URBs). It's great, keep
Stefan Richter wrote:
Pete Zaitcev wrote:
On Thu, 25 Jan 2007 16:18:35 -0500, Kristian Høgsberg <[EMAIL PROTECTED]> wrote:
...
will do a status write to the status address specified in the ORB, at which
point the SBP-2 transaction is complete.
You know, I wanted to use this picture
Pete Zaitcev wrote:
Hi, Kristian:
I only looked briefly at SBP-2, and at submit/callback paths it pulled,
because I do not understand most of the other issues.
Great, thanks for giving this a look-over, much appreciated.
Executive summary: please implement proper ORB cancellation. This is
d resolved the few conflicts
from that. Stefan, I'm still not sure what the work flow should be
here, do you want to just pull these changes or should I send the 13
patches to linux1394-devel?
cheers,
Kristian
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" i
Adrian Bunk wrote:
On Mon, Jan 22, 2007 at 02:41:29PM -0500, Kristian Høgsberg wrote:
Adrian Bunk wrote:
On Thu, Jan 11, 2007 at 10:26:27PM -0800, Andrew Morton wrote:
...
Changes since 2.6.20-rc3-mm1:
...
git-ieee1394.patch
...
git trees
...
This patch contains the following cleanups
I do like how extern inline will never generate code and
that gcc warns on missing prototype for these case is more of a gcc bug. Not
a big deal though, it's more worthwhile to track down real missing prototype
offenders.
- fw-topology.c: make struct fw_node_create static
Looks good.
so what the DRI/DRM layer does for textures etc...
That sounds a lot like what I have now (mmap method, array of pages)
so I'll just stick with that.
thanks,
Kristian
-
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/
fficult, but I
haven't yet figured it out and I'm sure somebody knows it off the top
of his head.
cheers,
Kristian
-
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/
ramming. But even if the write
transactions themselves are split transactions, it is still a low
overheads solution to your problem that avoids messing with
SPLIT_TIMEOUT.
cheers,
Kristian
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
x27;ll trade them for a OHCI controller :) I have a much
more useful way to put PCILynx cards to work using my firewire sniffer
(http://bitplanet.net/nosy).
cheers,
Kristian
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMA
Pieter Palmers wrote:
Kristian Høgsberg wrote:
Hi,
Here's a new set of patches for the new firewire stack. The changes
since the last set of patches address the issues that were raised on
the list and can be reviewed in detail here:
.. for some reason I didn't get patch 3/4 and
1 - 100 of 157 matches
Mail list logo
