Re: [RFC] IRQ handlers run with some high-priority interrupts(not NMI) enabled on some platform

preempt the other interrupt handlers made the difference between a usable clock and one that was pretty unreliable. Brad Boyer f...@allandria.com

Re: [RFC] IRQ handlers run with some high-priority interrupts(not NMI) enabled on some platform

on most models), but it can be in other places on systems that don't use a second VIA chip. On the IIfx, NuBus interrupts get routed through OSS to IRQ_AUTO_3. I don't see any cases that use other interrupt levels, but some of the logic is a little harder to follow. It's not an 8390, but it looks like macmace actually uses two levels. The regular interrupt should show up at IRQ_AUTO_3 and the DMA interrupts at IRQ_AUTO_4. Most Macs only use 4 for serial, but this is an exception. Brad Boyer f...@allandria.com

Re: [PATCH] serial: pmac_zilog: don't init if zilog is not available

so shouldn't it be possible to only run this code when the appropriate entries are present in the right data structures? I didn't look at a lot of the other serial drivers, but some other mac drivers have recently been updated to no longer have MACH_IS_MAC checks due to being converted to platform drivers. Brad Boyer b...@allandria.com

Re: [PATCH] m68k/mac: Allocate IOP message pool and queues dynamically

On Mon, Jul 01, 2013 at 05:48:22PM +1000, Finn Thain wrote: > > On Sun, 30 Jun 2013, Brad Boyer wrote: > > > On Sun, Jun 30, 2013 at 12:02:22PM +0200, Geert Uytterhoeven wrote: > > > > > > if (iop_scc_present) { > > > printk("IOP:

Re: [PATCH] m68k/mac: Allocate IOP message pool and queues dynamically

sted only on the IIfx. That's all JMT had, and at the time it was all I had as well. I have since acquired a Quadra 950. Lots of these comments are just out of date. I know it got tested on either a Quadra 900 or Quadra 950 after that comment was put in the source. Brad Boyer

Re: [PATCH] m68k/mac: Allocate IOP message pool and queues dynamically

On Sun, Jun 30, 2013 at 12:02:22PM +0200, Geert Uytterhoeven wrote: > Currently the IOP message pool and queues are allocated statically, > wasting ca. 5 KiB when running a Mac or multi-platform kernel on a machine > not having a Mac IOP. Convert them to conditional dynamic memory > allocations to

Re: [RFC 0/2] readdir() as an inode operation

as a structure rather than just an offset and be careful about the tracking. The hfs code is almost identical to the hfsplus code in this area. Brad Boyer [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a messa

Re: Versioning file system

are ACL support and SELinux. These both use extended attributes under the covers. It's just not immediately obvious if you aren't looking. Brad Boyer [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a mess

Re: [patch 19/33] NuBus header update

. I did look at it, and NuBus does lend itself to this conversion due to the fact that it does in general have devices that can be detected at runtime and a lot of generic infrastructure. It's just a matter of priorities and a lack of time all around. Brad Boyer [EMAIL PROTECTE

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

believe that the user-space programs should need to know as little as possible about the hardware, and it would be nice to abstract that away from the end user as well. We've moved toward commonality and standarization in other areas, and I think we should here as well. Brad Boyer

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

e who didn't use 8250 was marginalized enough that they got ignored. Brad Boyer [EMAIL PROTECTED] - 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/

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

rt of the losing side because they felt their opinions weren't seriously considered. Please correct me if my impressions of that were wrong. I was not directly involved in such arguments at the time. Brad Boyer [EMAIL PROTECTED] - To unsubscribe from this list: send the line &quo

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

se my opinion on this shows that I didn't come from the x86 side of Linux. The breakdown on this argument seems to have always been that the x86 people wanted 8250 to own ttyS* and most others wanted it shared. I know it was that way when m68k tried to merge in their serial framework that did

Re: [RFC][PATCH] ensure i_ino uniqueness in filesystems without permanent inode numbers (via idr)

tware companies as long as there is a demand for software on Linux, but it isn't exactly supportive. Brad Boyer [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo

Re: [RFC][PATCH] ensure i_ino uniqueness in filesystems without permanent inode numbers (via idr)

o all filesystem implementors whether it's GPL or not. The usual justification for GPL-only is that it's something random modules shouldn't be touching anyway, but it's something that some part of the tree which could be a module needs. Brad Boyer [EMAIL PROTECTED

Re: [PATCH] PPC64 iSeries: cleanup viopath

t; they do on ppc). Actually, there is a small overhead to bytes if you make them signed. That's why char is unsigned by default on ppc. Brad Boyer [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to

Re: [RFD w/info-PATCH] device arguments from lookup, partion code inuserspace

along with their kernel and root filesystem. If I'm missing the boat here, please tell me, but it sure seems like a bad idea to me. Brad Boyer - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More ma

Re: 64-bit block sizes on 32-bit systems

y, it can still be clean and easy to maintain. It's worth it to add a little complexity (particularly as an option) to add a feature that people will be demanding in the relatively near future. It might be a good idea to wait for 2.5, tho... Brad Boyer [EMAIL PROTECTED] P.S.