On Tuesday 10 February 2009, Wartan Hachaturow wrote:
> [drm] Initialized drm 1.1.0 20060810
> pci 0005:01:00.0: enabling device (0140 -> 0143)
> [drm] Initialized radeon 1.29.0 20080528 on minor 0
> [drm] Setting GART location based on new memory map
> [drm] GART aligned down from 0x0401 to 0
: Arnd Bergmann
---
This is the best I could come up with.
--- a/arch/powerpc/platforms/Kconfig
+++ b/arch/powerpc/platforms/Kconfig
@@ -91,15 +91,6 @@ config RTAS_FLASH
tristate "Firmware flash interface"
depends on PPC64 && RTAS_PROC
-config PPC_PMI
- tri
On Tuesday 24 February 2009, Ira Snyder wrote:
> This adds support to Linux for using virtio between two computers linked by
> a PCI interface. This allows the use of virtio_net to create a familiar,
> fast interface for communication. It should be possible to use other virtio
> devices in the futu
On Thursday 26 February 2009, Ira Snyder wrote:
> On Thu, Feb 26, 2009 at 05:15:27PM +0100, Arnd Bergmann wrote:
>
> I think so too. I was just getting something working, and thought it
> would be better to have it "out there" rather than be working on it
> forever. I
On Thursday 26 February 2009, Ira Snyder wrote:
> On Thu, Feb 26, 2009 at 09:37:14PM +0100, Arnd Bergmann wrote:
>
> The registers are part of the board control registers. They don't fit at
> all in the message unit. Doing this in the bootloader seems like a
> logical p
On Friday 27 February 2009, Ira Snyder wrote:
> On Thu, Feb 26, 2009 at 11:34:33PM +0100, Arnd Bergmann wrote:
> > I guess the best option for doing it in Linux then would be to have
> > a board control driver (not sure if this already exists) that exports
> > high-level fu
On Wednesday 18 March 2009, mon...@monstr.eu wrote:
> From: Michal Simek
>
>
> Signed-off-by: Michal Simek
> ---
> arch/microblaze/include/asm/of_device.h | 45 ++
> arch/microblaze/include/asm/of_platform.h | 64 ++
> arch/microblaze/include/asm/prom.h | 313
> arch/mic
On Wednesday 01 April 2009, Benjamin Herrenschmidt wrote:
> On Wed, 2009-04-01 at 11:42 +0200, Geert Uytterhoeven wrote:
> > PPC_CELL_NATIVE selects PPC_OF_PLATFORM_PCI, but not the underlying PCI,
> > causing build failures if PCI is not set.
>
> Maybe it should only select it if PCI is enabled ?
On Wednesday 01 April 2009, Benjamin Herrenschmidt wrote:
> On Wed, 2009-04-01 at 12:45 +0200, Arnd Bergmann wrote:
> > No, QPACE does not have any PCI devices whatsoever.
>
> so something like select PPC_OF_PLATFORM_PCI if PCI would work you
> think ?
Yes, that sounds g
On Thursday 02 April 2009, Harry Ciao wrote:
> +#ifdef CONFIG_EDAC
> +#define CPC925_MC_START0xf800
> +#define CPC925_MC_END 0xf8ff /* sizeof 16MB */
> +/* Register a platform device for CPC925 memory controller */
> +static int __init maple_cpc925_edac_setup(void)
On Thursday 02 April 2009, Harry Ciao wrote:
> Introduce IBM CPC925 EDAC driver source file, which makes use of error
> detections on the IBM CPC925 Bridge and Memory Controller.
>
> Signed-off-by: Harry Ciao
On a very brief review, the driver looks good to me, but please
post the full series to
On Thursday 02 April 2009, Geert Uytterhoeven wrote:
> | arch/powerpc/platforms/built-in.o:(.toc1+0x4e8): undefined reference to
> `pci_io_base'
>
> due to arch/powerpc/platforms/cell/io-workarounds.c. I guess this file
> shouldn't be built when CONFIG_PCI=n?
Right, the I/O workarounds are speci
D_PPC_OF option implicit
and selected only if at least one of USB_OHCI_HCD_PPC_OF_BE
and USB_OHCI_HCD_PPC_OF_LE are set.
Signed-off-by: Arnd Bergmann
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 845479f..07e3e25 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb
ver, that would
> force PCI on for QPACE, which also selects PPC_CELL_NATIVE. So
> instead move the select of PPC_OF_PLATFORM_PCI and PCI under both
> IBM_CELL_BLADE and CELLEB.
>
> Signed-off-by: Michael Ellerman
Yes, this one looks right, thanks for following up on
On Wednesday 22 April 2009, Kumar Gala wrote:
First of all, thanks for bringing this up, I'd love to see get_immrbase() gone.
> arch/powerpc/sysdev/cpm1.c: mpc8xx_immr = ioremap(get_immrbase(),
> 0x4000);
> not sure? ideas?
Nobody has commented on this, so I've taken a brief look a
On Tuesday 21 April 2009, John Williams wrote:
> Some (most?) of the Xilinx drivers currently have this construct:
>
> #ifdef CONFIG_OF
>
> // probe using OF
>
> #else
If there are multiple ways of detecting the device, then
the driver should be compilable on any system that allows
either one.
On Friday 17 April 2009, John Linn wrote:
> Added support for the new xps tft controller. The new core
> has PLB interface support in addition to existing DCR interface.
>
> Removed platform device support as both MicroBlaze and PowerPC
> use device tree.
I just said in another email thread that
On Thursday 21 January 2010, Wolfgang Grandegger wrote:
> The major problem that Anatolij tries to solve are the different
> register layouts of the supported SOCs, MPC52xx and MPC8xx. They use the
> same registers but at different offsets. Therefore we cannot handle
> this with a single "fec_t" st
On Sunday 24 January 2010, Wolfgang Denk wrote:
> In message <4b5c5bdf.6020...@grandegger.com> you wrote:
> >
> > You are probably right and your proposal would likely result in more
> > transparent (less ugly) code. There has been some discussion about
> > unifying FEC drivers when the patches (w
On Thursday 28 January 2010, hank peng wrote:
> On my MPC8548 based board, sometimes kernel printed out the following
> messages, I wonder if it indicates the system is not normal?
>
> pdflush used greatest stack depth: 4048 bytes left
> pdflush used greatest stack depth: 4028 bytes left
> pdflush
On Thursday 25 March 2010, Benjamin Herrenschmidt wrote:
> On Thu, 2010-03-25 at 10:41 +0800, Csdncannon wrote:
> > In my program, the value of the 64-bit time base register is
> > read out, and you will find the later value is even smaller than the
> > earlier value from the log “log_time
On Tuesday 04 May 2010, Takuya Yoshikawa wrote:
>
> Although we can use *_le_bit() helpers to treat bitmaps le arranged,
> having le bit offset calculation as a seperate macro gives us more freedom.
>
> For example, KVM has le arranged dirty bitmaps for VGA, live-migration
> and they are used in
On Wednesday 05 May 2010, Takuya Yoshikawa wrote:
> Date:
> Yesterday 04:59:24
> > That's why the bitmaps are defined as little endian u64 aligned, even on
> > big endian 32-bit systems. Little endian bitmaps are wordsize agnostic,
> > and u64 alignment ensures we can use long-sized bitops on m
On Monday 10 May 2010, Takuya Yoshikawa wrote:
> (2010/05/06 22:38), Arnd Bergmann wrote:
> > On Wednesday 05 May 2010, Takuya Yoshikawa wrote:
> >> There was a suggestion to propose set_le_bit_user() kind of macros.
> >> But what I thought was these have a const
On Monday 18 April 2011, Richard Cochran wrote:
> +static void ixp_rx_timestamp(struct port *port, struct sk_buff *skb)
> +{
> + struct skb_shared_hwtstamps *shhwtstamps;
> + struct ixp46x_ts_regs *regs;
> + u64 ns;
> + u32 ch, hi, lo, val;
> + u16 uid, seq;
> +
> +
andard POSIX clock.
>
> The ancillary clock features are exposed in two different ways, via
> the sysfs and by a character device.
>
> Signed-off-by: Richard Cochran
Acked-by: Arnd Bergmann
___
Linuxppc-dev mailing list
Linuxppc
On Monday 18 April 2011, Richard Cochran wrote:
> On Mon, Apr 18, 2011 at 08:56:03AM +0200, Arnd Bergmann wrote:
> > On Monday 18 April 2011, Richard Cochran wrote:
> > > +
> > > + lo = __raw_readl(®s->channel[ch].src_uuid_lo);
> > > + hi =
On Monday 18 April 2011, Arnd Bergmann wrote:
> On Monday 18 April 2011, Richard Cochran wrote:
> > On Mon, Apr 18, 2011 at 08:56:03AM +0200, Arnd Bergmann wrote:
> > > On Monday 18 April 2011, Richard Cochran wrote:
> > > > +
> > > > + lo
On Thursday 12 May 2011, Will Drewry wrote:
> This change adds a new seccomp mode based on the work by
> a...@chromium.org in [1]. This new mode, "filter mode", provides a hash
> table of seccomp_filter objects. When in the new mode (2), all system
> calls are checked against the filters - first b
On Saturday 14 May 2011, Will Drewry wrote:
> Depending on integration, it could even be limited to ioctl commands
> that are appropriate to a known fd if the fd is opened prior to
> entering seccomp mode 2. Alternatively, __NR__ioctl could be allowed
> with a filter of "1" then narrowed through a
On Thursday 19 May 2011, Timur Tabi wrote:
>
> The ePAPR embedded hypervisor specification provides an API for "byte
> channels", which are serial-like virtual devices for sending and receiving
> streams of bytes.
Why is this using a full tty driver instead of the hvc framework that most
other hy
On Wednesday 01 June 2011, Timur Tabi wrote:
> The Freescale hypervisor management driver provides several services to
> drivers and applications related to the Freescale hypervisor:
>
> 1. An ioctl interface for querying and managing partitions
>
> 2. A file interface to reading incoming doorbel
On Friday 03 June 2011, Timur Tabi wrote:
> Arnd Bergmann wrote:
> > For an ioctl, please follow the normal pattern of defining a separate
> > structure for each case, no union.
> >
> > You can use a void __user * in the common ioctl function, and pass that
> >
On Thursday 02 June 2011, Timur Tabi wrote:
> Arnd Bergmann wrote:
> > I think drivers/misc is not the right place for this, but I'm not completely
> > sure what is. drivers/firmware would be better at least, but virt/fsl might
> > also be ok.
>
> I don&#x
On Thursday 02 June 2011, Scott Wood wrote:
> I wanted to have the hypervisor take an update dtb (we already have special
> meta-properties for things like deletion as part of the hv config
> mechanism). But others on the project wanted to keep it simple, and so
> get/set property it was. :-/
>
>
On Friday 03 June 2011, Timur Tabi wrote:
> Arnd Bergmann wrote:
> >> > I don't think it's correct to think of a hypervisor as firmware, so I
> >> > don't
> >> > think drivers/firmware is better.
> >> >
> >> > I'
On Friday 03 June 2011, Scott Wood wrote:
> On Fri, 3 Jun 2011 17:28:43 +0200
> Arnd Bergmann wrote:
>
> > On Thursday 02 June 2011, Scott Wood wrote:
> > > I wanted to have the hypervisor take an update dtb (we already have
> > > special
> > > meta-p
On Monday 06 June 2011, Timur Tabi wrote:
> Arnd Bergmann wrote:
> > Sorry, I misread your first sentence above. I thought you said that you
> > prefer
> > drivers/firmware over virt/fsl. drivers/misc is definitely the wrong
> > place for this, please choose a bet
On Monday 06 June 2011, Timur Tabi wrote:
> Arnd Bergmann wrote:
> > When we talked about the situation of drivers/misc and drivers/char at
> > one of the recent conferences, a broad consensus was that they are in
> > need of a maintainer, which I foolishly signed up for. Deep
On Monday 06 June 2011 20:15:16 Scott Wood wrote:
> On Mon, 6 Jun 2011 17:53:09 +0200
> Arnd Bergmann wrote:
> > > > > You can't delete anything.
> > > >
> > > > rm, rmdir
> > > >
> > > > > You can't create e
On Tuesday 07 June 2011 01:04:40 Chris Metcalf wrote:
> For context, the most recent patch for the tile driver in question is here:
>
> https://patchwork.kernel.org/patch/843892/
>
> On 6/6/2011 5:23 PM, Konrad Rzeszutek Wilk wrote:
> > On Mon, Jun 06, 2011 at 05:01:36PM -0400, Chris Metcalf wrot
On Tuesday 07 June 2011 18:49:02 Chris Metcalf wrote:
> > You can probably argue that the tile drivers do fit in here as long as
> > they are specific to the hypervisor and not to some SOC specific hardware.
>
> Can you clarify that? I think you're contrasting something like an ARM
> core that w
On Tuesday 07 June 2011 21:20:50 Timur Tabi wrote:
> Arnd Bergmann wrote:
> > For the spi flash driver that goes through the hypervisor abstraction,
> > I think drivers/virt/tile would be better than driver/platform/tile,
> > but we should really have a new "abstr
On Thursday 09 June 2011 00:45:54 Timur Tabi wrote:
> +struct fsl_hv_ioctl_memcpy {
> + __u32 ret;
> + __u32 source;
> + __u32 target;
> + __u64 local_vaddr;
> + __u64 remote_paddr;
> + __u64 count;
> +};
> +struct fsl_hv_ioctl_prop {
> + __u32 ret;
> +
On Thursday 09 June 2011 01:10:09 Randy Dunlap wrote:
> On Wed, 8 Jun 2011 17:45:54 -0500 Timur Tabi wrote:
>
> > Add the drivers/virt directory, which houses drivers that support
> > virtualization environments, and add the Freescale hypervisor management
> > driver.
>
> It can't go in linux/vir
Hi Timur, thanks for addressing the issues I pointed out. Unfortunately, I
have found a few more now:
On Thursday 09 June 2011 21:13:14 Timur Tabi wrote:
> + /* Make sure the application is called the right driver. */
> + if (_IOC_TYPE(cmd) != 0) {
> + pr_debug("fsl-hv: i
On Thursday 09 June 2011 20:55:17 Timur Tabi wrote:
> Arnd Bergmann wrote:
> > Then get rid of all the code that takes apart the ioctl command numbers
> > again and just do a switch/case based on the command.
>
> I still need to keep that code to maintain binary compat
On Thursday 09 June 2011 21:48:58 Randy Dunlap wrote:
> > So is it okay to stick with 0, or do I need to pick a new number?
>
> I wasn't suggesting that you change the 0, just note that it has conflicts,
> like other ioctls do.
We normally don't try to maintain binary compatibility with out of tr
On Thursday 09 June 2011 22:18:28 Timur Tabi wrote:
> > More importantly, the code you have chose (0) conflicts with existing
> > drivers
> > (frame buffer, scsi and wavefront among others). Please chose a free one and
> > add it to Documentation/ioctl/ioctl-number.txt in the same patch.
>
> Ok,
tdown doorbell from a manager partition
>
> 4. A kernel interface for receiving callbacks when a managed partition
>shuts down.
>
> Signed-off-by: Timur Tabi
Acked-by: Arnd Bergmann
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On Friday 10 June 2011, Chris Metcalf wrote:
> This still leaves open the question of what really should go in this new
> directory. Is it just for drivers that manage/control the hypervisor? Or
> is it also for drivers that just use the hypervisor to do I/O of some kind,
> but aren't related to a
On Tuesday 14 June 2011 21:08:50 Ralf Baechle wrote:
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 9adc278..2968751f 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -21,6 +21,7 @@ config ARM
> select HAVE_KERNEL_LZO
> select HAVE_KERNEL_LZMA
> select HA
On Tuesday 14 June 2011 22:25:46 H. Peter Anvin wrote:
> On 06/14/2011 12:08 PM, Ralf Baechle wrote:
> > The PC parallel port Kconfig as acquired one of those messy terms to
> > describe it's architecture dependencies:
> >
> >depends on (!SPARC64 || PCI) && !SPARC32 && !M32R && !FRV && \
>
On Wednesday 15 June 2011, H. Peter Anvin wrote:
> On 06/14/2011 02:33 PM, Arnd Bergmann wrote:
> >>
> >> Why on earth restrict it like that? It's just a device driver, like
> >> more or less any other device driver...
> >
> > I'd say any oth
On Friday 17 June 2011 10:49:16 Dmitry Eremin-Solenikov wrote:
> Add simple cpufreq driver for Maple-based boards (ppc970fx evaluation
> kit and others). Driver is based on a cpufreq driver for 64-bit powermac
> boxes with all pmac-dependant features removed and simple cleanup
> applied.
>
> Signe
On Friday 17 June 2011 13:12:56 Dmitry Eremin-Solenikov wrote:
> > I think new cpufreq drivers should live in drivers/cpufreq, not in arch/.
> > We've
> > started moving other drivers away from arch/x86 and arch/arm already.
>
> What about drivers/cpufreq/powerpc, or it's an unnecessary?
drivers/
This iotype is only used by the legacy_serial code in powerpc, so the
code should live there, rather than be compiled in for every 8250
driver.
Signed-off-by: Arnd Bergmann
Cc: Benjamin Herrenschmidt
Cc: linuxppc-dev@lists.ozlabs.org
Cc: Greg Kroah-Hartman
Cc: linux-ser...@vger.kernel.org
On Friday 01 July 2011, Tabi Timur-B04825 wrote:
> On Thu, Jun 9, 2011 at 4:04 PM, Arnd Bergmann wrote:
> > On Thursday 09 June 2011 22:52:06 Timur Tabi wrote:
> >> Add the drivers/virt directory, which houses drivers that support
> >> virtualization environments, and a
On Thursday 04 August 2011, Geoff Levand wrote:
> > + *
> > + * udbg debug output routine via GELIC UDP broadcasts
> > + * Copyright (C) 2010 Hector Martin
> > + * Copyright (C) 2011 Andre Heider
>
> Some of this seems to be taken from the gelic driver, so shouldn't
> the copyright info from the
On Monday 01 August 2011, Andre Heider wrote:
> This series addresses various issues and extends support when running
> in lpars like GameOS. Included are some patches from Hector Martin, which
> I found useful.
Hi Andre,
I've looked at the entire series and support merging it into 3.2 once
the c
On Saturday 29 May 2010, Josh Boyer wrote:
> On Sat, May 29, 2010 at 01:45:04PM +1000, Benjamin Herrenschmidt wrote:
> >On Tue, 2010-05-25 at 07:00 -0400, Josh Boyer wrote:
> >> On Tue, May 25, 2010 at 05:43:59PM +1000, Benjamin Herrenschmidt wrote:
> >> >Hi folks !
> >> >
> >> >Anybody aware of an
On Wednesday 09 June 2010, Sukadev Bhattiprolu wrote:
> Albert and Randy point out that this would require #ifdefs in the
> application code that intends to be portable across say IA64 and x86.
>
> Can we instead have all architectures specify [base, size] ?
No objections from me on that.
On Thursday 10 June 2010, Steven A. Falco wrote:
> I believe there is a bug in the way the ibm_newemac driver handles the
> SIOCGMIIREG (and SIOCSMIIREG) ioctl. The problem is that emac_ioctl
> is handed a "struct ifreq *rq" which contains a user-land pointer to
> an array of 16-bit integers.
Did
On Thursday 10 June 2010, Steven A. Falco wrote:
> > The ifreq structure passed into the ndo_ioctl function is in kernel
> > space, it gets copied there by net/core/dev.c:dev_ioctl().
> > emac_ioctl only accesses the data in that structure, so a copy_from_user
> > is wrong here as far as I can tell
On Thursday 10 June 2010 21:47:27 Steven A. Falco wrote:
> On 06/10/2010 01:03 PM, Arnd Bergmann wrote:
> > Still unconvinced.
>
> Ok - here is the user-space program I am using to test this. It simply
> uses the ioctl to peek and poke the phy. If I run it on an unmodified
&g
The default for llseek is changing, so we need
explicit operations everywhere.
Signed-off-by: Arnd Bergmann
Cc: Jeremy Kerr
Cc: linuxppc-...@ozlabs.org
---
arch/powerpc/platforms/cell/spufs/file.c | 24 +---
1 files changed, 21 insertions(+), 3 deletions(-)
diff --git a
On Thursday 08 July 2010, Jeremy Kerr wrote:
> > @@ -2151,7 +2166,7 @@ static ssize_t spufs_ibox_info_read(struct file
> > *file, char __user *buf,
> > static const struct file_operations spufs_ibox_info_fops = {
> > .open = spufs_info_open,
> > .read = spufs_ibox_info_read,
> > -
The default for llseek is changing, so we need
explicit operations everywhere.
Signed-off-by: Arnd Bergmann
Cc: Jeremy Kerr
Cc: linuxppc-...@ozlabs.org
---
Same as previous version, but no longer breaking the existing llseek
operation in spufs_*box_info_fops. Pushed out to my bkl/llseek branch
AB-BA deadlock.
Please apply to the respective maintainer trees
if the patches look good.
Arnd Bergmann (12):
staging: autoconvert trivial BKL users to private mutex
isdn: autoconvert trivial BKL users to private mutex
scsi: autoconvert trivial BKL users to private mutex
media: autoconvert
/^\(static\|int\|long\)/istatic
DEFINE_MUTEX(${name}_mutex);
} }" \
-e "s/\(un\)*lock_kernel\>[ ]*()/mutex_\1lock(\&${name}_mutex)/g" \
-e '/[ ]*cycle_kernel_lock();/d'
else
sed -i -e '/include.*\/d' ${file} \
On Friday 16 July 2010 19:57:55 Grant Likely wrote:
> On Fri, Jul 16, 2010 at 10:03 AM, Catalin Marinas
> wrote:
> > On Wed, 2010-07-14 at 00:04 +0100, Grant Likely wrote:
>
> sfr and I were talking about your patch the other day. Just warning
> on incomplete dependencies is enough to make it ac
On Friday 16 July 2010 20:46:17 Linus Torvalds wrote:
> Maybe a full "solver" is unnecessary, for example, but just a simple
> "automatically enable the direct dependencies and scream when it's not
> simple any more" would take care of 99% of the common cases, and then
> warn when it needs some man
On Tuesday 27 July 2010, Grant Likely wrote:
> > I suggest to go back to v2 of your patch where you use asm-generic/of.h.
>
> Stephen suggested dropping asm-generic/of.h. I'm happy to do it either way.
I don't mind adding stuff to asm-generic, but I think in this case it would
be easier to keep
On Monday 16 August 2010, Richard Cochran wrote:
> This patch adds an infrastructure for hardware clocks that implement
> IEEE 1588, the Precision Time Protocol (PTP). A class driver offers a
> registration method to particular hardware clock drivers. Each clock is
> exposed to user space as a char
On Monday 16 August 2010 21:00:03 Richard Cochran wrote:
>
> On Mon, Aug 16, 2010 at 04:26:23PM +0200, Arnd Bergmann wrote:
> > Have you considered integrating the subsystem into the Posix clock/timer
> > framework?
>
> Yes, but see below.
>
> > I can't
On Tuesday 17 August 2010, Richard Cochran wrote:
> > Why did you not want to add syscalls? Adding ioctls instead of syscalls
> > does not make the interface better, just less visible.
>
> I bet that, had I posted patch set with new syscalls, someone would
> have said, "You are adding new syscalls
On Tuesday 17 August 2010, Richard Cochran wrote:
> On Tue, Aug 17, 2010 at 09:25:55AM +0000, Arnd Bergmann wrote:
> > Another difference is that we generally use ioctl for devices that can
> > be enumerated, while syscalls are for system services that are not tied to
> > a
On Wednesday 18 August 2010, Richard Cochran wrote:
> On Tue, Aug 17, 2010 at 01:36:29PM +0200, Arnd Bergmann wrote:
> > On Tuesday 17 August 2010, Richard Cochran wrote:
> > > I've been looking at offering the PTP clock as a posix clock, and it
> > > is not as
On Thursday 19 August 2010, Richard Cochran wrote:
> On Wed, Aug 18, 2010 at 05:12:56PM -0700, john stultz wrote:
> > On Wed, 2010-08-18 at 09:19 +0200, Richard Cochran wrote:
> > > The timer/alarm stuff is "ancillary" and is not at all necessary. It
> > > is just a "nice to have." I will happily r
On Thursday 19 August 2010, Richard Cochran wrote:
>
> On Wed, Aug 18, 2010 at 05:02:03PM +0200, Arnd Bergmann wrote:
> > You might want to use callbacks for these system calls that you
> > can register to at module load time, like it is done for the
> > existing syscall
On Thursday 19 August 2010, Ira W. Snyder wrote:
> Perhaps you were thinking of the vhost example (taken from
> drivers/vhost/Kconfig):
>
> config VHOST_NET
> tristate "Host kernel accelerator for virtio net (EXPERIMENTAL)"
> depends on NET && EVENTFD && (TUN || !TUN) && (MACVTAP |
On Thursday 19 August 2010 17:15:37 Andreas Schwab wrote:
> +SYSCALL(fanotify_init)
> +COMPAT_SYS(fanotify_mark)
why not _SPU? If it doesn't depend on getting signals,
SPUs should be able to use it.
Arnd
___
Linuxppc-dev mailing list
Linuxppc-de
On Saturday 21 August 2010 23:32:23 Andreas Schwab wrote:
> The ioctls are actually compatible, but due to historical mistake the
> numbers differ between 32bit and 64bit.
Looks good to me, but
> +#ifdef CONFIG_COMPAT
> +#define PMU_IOC_GET_BACKLIGHT32 _IOR('B', 1, u32)
> +#define PMU_IOC_SE
On Sunday 22 August 2010, Andreas Schwab wrote:
> The ioctls are actually compatible, but due to historical mistake the
> numbers differ between 32bit and 64bit.
>
> Signed-off-by: Andreas Schwab
Acked-by: Arnd Bergmann
___
Linuxppc-dev
On Thursday 19 August 2010, David Miller wrote:
> From: Benjamin Herrenschmidt
> Date: Thu, 19 Aug 2010 15:23:23 +1000
>
> > Similar here, but using atomic_long_t instead so it works for 32-bit too
> > for me. I suppose we could make that part common indeed.
> >
> > What about asm-generic/rwsem-
On Friday 20 August 2010, Andreas Schwab wrote:
> See arch/powerpc/platforms/cell/spu_callbacks.c.
>
> * 4. They are optional and we can't rely on them being
> *linked into the kernel. Unfortunately, the cond_syscall
> *helper does not work here as it does not add the necessary
> *
On Tuesday 24 August 2010, Benjamin Herrenschmidt wrote:
> On Mon, 2010-08-23 at 15:52 +0200, Arnd Bergmann wrote:
> > On Friday 20 August 2010, Andreas Schwab wrote:
> > > See arch/powerpc/platforms/cell/spu_callbacks.c.
> > >
> > > * 4. They are opti
re. Or do you want me to
> continue pushing my patch as-is and we can look at cleaning up the
> spinlock case separately ?
I'm currently doing too many things at once, please push in your existing
patch for now, we can continue from there.
For the asm-generic patch:
Acked-by: Arnd Bergman
On Friday 27 August 2010, Richard Cochran wrote:
> On Mon, Aug 23, 2010 at 01:21:39PM -0700, john stultz wrote:
> > On Thu, 2010-08-19 at 17:38 +0200, Richard Cochran wrote:
> > > On Thu, Aug 19, 2010 at 02:28:04PM +0200, Arnd Bergmann wrote:
> > > > Have you con
/^\(static\|int\|long\)/istatic
DEFINE_MUTEX(${name}_mutex);
} }" \
-e "s/\(un\)*lock_kernel\>[ ]*()/mutex_\1lock(\&${name}_mutex)/g" \
-e '/[ ]*cycle_kernel_lock();/d'
else
sed -i -e '/include.*\/d' ${file} \
these drivers gives
me reasonable confidence in the approach, since it avoids
typos and other common mistakes from sloppiness.
Stephen, please add
git+ssh://master.kernel.org/pub/scm/linux/kernel/git/arnd/bkl.git trivial
Arnd Bergmann (7):
scsi: autoconvert trivial BKL users to private mutex
mtd
The default for llseek is changing, so we need
explicit operations everywhere.
Signed-off-by: Arnd Bergmann
Cc: Jeremy Kerr
Cc: linuxppc-...@ozlabs.org
---
arch/powerpc/platforms/cell/spufs/file.c | 18 ++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/arch
automatic mass-conversion part when this gets ready
for inclusion in 2.6.37, to accomodate any drivers
that got added without a .llseek method.
Stephen, please add
git+ssh://master.kernel.org/pub/scm/linux/kernel/git/arnd/bkl.git llseek
Arnd Bergmann (15):
drm: use noop_llseek
net/wireless: use
On Wednesday 15 September 2010, valdis.kletni...@vt.edu wrote:
> Show Details
> On Tue, 14 Sep 2010 22:22:28 +0200, Arnd Bergmann said:
>
> > This changes all instances of struct file_operations in
> > the kernel to have a .llseek operation and then changes
> > the
On Wednesday 15 September 2010, Nishanth Aravamudan wrote:
> direct_dma_ops is the default pci dma ops.
>
> No need to call a function to get the pci dma ops, we know they are the
> dma_direct_ops.
>
> Signed-off-by: Milton Miller
> Signed-off-by: Nishanth Aravamudan
Ac
to facilitate diagnostics.
Signed-off-by: Gerhard Stenzel
Signed-off-by: Arnd Bergmann
---
arch/powerpc/platforms/cell/ras.c | 17 ++---
1 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/platforms/cell/ras.c
b/arch/powerpc/platforms/cell/ras.c
index
From: Jan Blunck
This patch removes an unnecessary double check if the dentry returned by
lookup_create() is actually non-negative. Since lookup_create() itself returns
an error in this case just remove the check.
Signed-off-by: Jan Blunck
Signed-off-by: Arnd Bergmann
---
arch/powerpc
Hi Ben,
I have three small fixes for Cell that I'd like you to
add to your powerpc tree.
git pull git.kernel.org:/pub/scm/linux/kernel/git/arnd/cell-2.6.git next
The first two patches might still be good to have in 2.6.30,
the patch from Jan is just a cleanup for 2.6.31.
Thanks,
Arnd <
From: Benjamin Krill
The receive interrupt routine checks the wrong register if the
receive fifo is empty. Further an explicit interrupt acknowledge
write is introduced. In some circumstances another interrupt was
issued.
Signed-off-by: Benjamin Krill
Signed-off-by: Arnd Bergmann
---
drivers
On Tuesday 19 May 2009, Grant Likely wrote:
> 1) Probe the host controller in an of_platform driver. This has the
> advantage of simplicity. The probe routine will get automatically
> called when the PCI host controller device tree node is registered
> with the of_platform bus. The bus parenthoo
501 - 600 of 2112 matches
Mail list logo
