early branched for F-11
by Kyle McMartin
Just a quick note, we've early branched for F-11... The 2.6.29
based tree for F-11 is located in the F-11/ subdirectory... Make sure
you cvs up the common/ dir as well.
devel/ has been updated for -git7 and will continue to move towards
2.6.30.
regards, Kyle
14 years, 8 months
Re: rpms/kernel/devel linux-2.6-net-fix-another-gro-bug.patch, NONE, 1.1 TODO, 1.59, 1.60 kernel.spec, 1.1482, 1.1483
by Mark McLoughlin
Hi,
On Mon, 2009-03-30 at 08:56 +0000, Mark McLoughlin wrote:
> +* linux-2.6-net-fix-another-gro-bug.patch:
> + virtio_net guest->remote GSO busted with 2.6.29 host
> + https://bugzilla.redhat.com/490266
> + Should be in 2.6.29.1
I took the liberty of just going ahead and building this - pretty
serious bug with a fairly trivial fix from upstream.
Cheers,
Mark.
14 years, 8 months
File conflicts between alsa-firmware and kernel-firmware
by Tim Jackson
I maintain alsa-firmware and the following bug regarding file conflicts
between recent versions of kernel-firmware and alsa-firmware got raised today:
https://bugzilla.redhat.com/show_bug.cgi?id=487873
I'm not really familiar with the kernel package maintenance, nor who/what
governs what firmware goes into kernel-firmware (and indeed how that is
related to the upstream kernel). I had a cursory look at the kernel spec
in CVS but that didn't appear to have any relevant recent changes that
were obvious.
I did a diff between the firmware in alsa-firmware and in
kernel-firmware-2.6.29-0.172.rc6.git4.fc11 and it's clear that although
there are some overlaps, much of the audio firmware in alsa-firmware isn't
in kernel-firmware.
The current conflicting files are:
ess/*
korg/*
sb16/*
yamaha/ds1_ctrl.fw
yamaha/ds1_dsp.fw
yamaha/ds1e_ctrl.fw
Things that are in alsa-firmware but NOT in the above version of
kernel-firmware are:
asihpi/*
digiface*
3g*
ea/*
emu/*
mixart/*
multiface*
pcxhr/*
vx/*
yamaha/yss225_registers.bin
[usx2y, which does something funky so it's not in /lib/firmware]
Either way, it looks like we need to work together on this.
- I'm happy to just drop the conflicting files from alsa-firmware - is
that the right thing to do?
- Are the above audio firmware files in kernel-firmware there to stay?
- Is there a long term goal to bring all the firmware from alsa-firmware
upstream into the kernel-firmware package?
Thanks
Tim
14 years, 8 months
Backport /sys/bus/pci/devices/*/remove_id
by Mark McLoughlin
Hey,
Any objections to pulling in this patch from the linux-next PCI tree?
It adds a sysfs entry which we need for KVM/libvirt PCI device
assignment. See:
https://bugzilla.redhat.com/487103
TODO entry would be:
* linux-2.6-pci-sysfs-remove-id.patch
In jbarnes linux-next tree for 2.6.30
Needed for KVM PCI device assignment
https://bugzilla.redhat.com/487103
Cheers,
Mark.
From: Chris Wright <chrisw(a)sous-sol.org>
Date: Tue, 24 Feb 2009 05:52:23 +0000 (-0800)
Subject: PCI: add remove_id sysfs entry
X-Git-Url: http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Fjbarnes%2Fpci-2.6.git;a=c...
PCI: add remove_id sysfs entry
This adds a remove_id sysfs entry to allow users of new_id to later
remove the added dynid. One use case is management tools that want to
dynamically bind/unbind devices to pci-stub driver while devices are
assigned to KVM guests. Rather than having to track which driver was
originally bound to the driver, a mangement tool can simply:
Guest uses device
Signed-off-by: Chris Wright <chrisw(a)sous-sol.org>
Signed-off-by: Jesse Barnes <jbarnes(a)virtuousgeek.org>
---
diff --git a/Documentation/ABI/testing/sysfs-bus-pci b/Documentation/ABI/testing/sysfs-bus-pci
index e638e15..3d29793 100644
--- a/Documentation/ABI/testing/sysfs-bus-pci
+++ b/Documentation/ABI/testing/sysfs-bus-pci
@@ -41,6 +41,22 @@ Description:
for the device and attempt to bind to it. For example:
# echo "8086 10f5" > /sys/bus/pci/drivers/foo/new_id
+What: /sys/bus/pci/drivers/.../remove_id
+Date: February 2009
+Contact: Chris Wright <chrisw(a)sous-sol.org>
+Description:
+ Writing a device ID to this file will remove an ID
+ that was dynamically added via the new_id sysfs entry.
+ The format for the device ID is:
+ VVVV DDDD SVVV SDDD CCCC MMMM. That is Vendor ID, Device
+ ID, Subsystem Vendor ID, Subsystem Device ID, Class,
+ and Class Mask. The Vendor ID and Device ID fields are
+ required, the rest are optional. After successfully
+ removing an ID, the driver will no longer support the
+ device. This is useful to ensure auto probing won't
+ match the driver to the device. For example:
+ # echo "8086 10f5" > /sys/bus/pci/drivers/foo/remove_id
+
What: /sys/bus/pci/devices/.../vpd
Date: February 2008
Contact: Ben Hutchings <bhutchings(a)solarflare.com>
diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
index 93eac14..87a5ddb 100644
--- a/drivers/pci/pci-driver.c
+++ b/drivers/pci/pci-driver.c
@@ -99,6 +99,52 @@ store_new_id(struct device_driver *driver, const char *buf, size_t count)
}
static DRIVER_ATTR(new_id, S_IWUSR, NULL, store_new_id);
+/**
+ * store_remove_id - remove a PCI device ID from this driver
+ * @driver: target device driver
+ * @buf: buffer for scanning device ID data
+ * @count: input size
+ *
+ * Removes a dynamic pci device ID to this driver.
+ */
+static ssize_t
+store_remove_id(struct device_driver *driver, const char *buf, size_t count)
+{
+ struct pci_dynid *dynid, *n;
+ struct pci_driver *pdrv = to_pci_driver(driver);
+ __u32 vendor, device, subvendor = PCI_ANY_ID,
+ subdevice = PCI_ANY_ID, class = 0, class_mask = 0;
+ int fields = 0;
+ int retval = -ENODEV;
+
+ fields = sscanf(buf, "%x %x %x %x %x %x",
+ &vendor, &device, &subvendor, &subdevice,
+ &class, &class_mask);
+ if (fields < 2)
+ return -EINVAL;
+
+ spin_lock(&pdrv->dynids.lock);
+ list_for_each_entry_safe(dynid, n, &pdrv->dynids.list, node) {
+ struct pci_device_id *id = &dynid->id;
+ if ((id->vendor == vendor) &&
+ (id->device == device) &&
+ (subvendor == PCI_ANY_ID || id->subvendor == subvendor) &&
+ (subdevice == PCI_ANY_ID || id->subdevice == subdevice) &&
+ !((id->class ^ class) & class_mask)) {
+ list_del(&dynid->node);
+ kfree(dynid);
+ retval = 0;
+ break;
+ }
+ }
+ spin_unlock(&pdrv->dynids.lock);
+
+ if (retval)
+ return retval;
+ return count;
+}
+static DRIVER_ATTR(remove_id, S_IWUSR, NULL, store_remove_id);
+
static void
pci_free_dynids(struct pci_driver *drv)
{
@@ -125,6 +171,20 @@ static void pci_remove_newid_file(struct pci_driver *drv)
{
driver_remove_file(&drv->driver, &driver_attr_new_id);
}
+
+static int
+pci_create_removeid_file(struct pci_driver *drv)
+{
+ int error = 0;
+ if (drv->probe != NULL)
+ error = driver_create_file(&drv->driver,&driver_attr_remove_id);
+ return error;
+}
+
+static void pci_remove_removeid_file(struct pci_driver *drv)
+{
+ driver_remove_file(&drv->driver, &driver_attr_remove_id);
+}
#else /* !CONFIG_HOTPLUG */
static inline void pci_free_dynids(struct pci_driver *drv) {}
static inline int pci_create_newid_file(struct pci_driver *drv)
@@ -132,6 +192,11 @@ static inline int pci_create_newid_file(struct pci_driver *drv)
return 0;
}
static inline void pci_remove_newid_file(struct pci_driver *drv) {}
+static inline int pci_create_removeid_file(struct pci_driver *drv)
+{
+ return 0;
+}
+static inline void pci_remove_removeid_file(struct pci_driver *drv) {}
#endif
/**
@@ -852,13 +917,23 @@ int __pci_register_driver(struct pci_driver *drv, struct module *owner,
/* register with core */
error = driver_register(&drv->driver);
if (error)
- return error;
+ goto out;
error = pci_create_newid_file(drv);
if (error)
- driver_unregister(&drv->driver);
+ goto out_newid;
+ error = pci_create_removeid_file(drv);
+ if (error)
+ goto out_removeid;
+out:
return error;
+
+out_removeid:
+ pci_remove_newid_file(drv);
+out_newid:
+ driver_unregister(&drv->driver);
+ goto out;
}
/**
@@ -874,6 +949,7 @@ int __pci_register_driver(struct pci_driver *drv, struct module *owner,
void
pci_unregister_driver(struct pci_driver *drv)
{
+ pci_remove_removeid_file(drv);
pci_remove_newid_file(drv);
driver_unregister(&drv->driver);
pci_free_dynids(drv);
14 years, 8 months
[PATCH] Don't try to use agp symbols if we don't have AGP (*cough*sparc*cough*)
by Tom Callaway
The radeon_buffer.c addition that gets pulled into the DRM driver as
part of Kernel Mode Setting (even if you disable KMS for the Radeon
driver) was assuming that it was safe to use symbols from the AGP code,
but that isn't safe on platforms where __OS_HAS_AGP is 0. Such as
sparc64. :)
This patch gets the code building again. It probably should go into the
actual kms patch, but if you would prefer this go as a separate patch, I
can apply it. With this, we can get rawhide building for sparc64, so I'm
eager to see it applied in one way or another.
Signed-off-by: Tom "spot" Callaway <tcallawa(a)redhat.com>
14 years, 9 months
[PATCH] x86: fix DMI for EFI
by Brian Maly
resolves BZ 488579
Impact: reactivate DMI quirks on EFI hardware
DMI tables are loaded by EFI, so the dmi calls must happen after
efi_init() and not before.
Currently Apple hardware uses DMI to determine the framebuffer mappings
for efifb. Without DMI working you also have no video on MacBook Pro.
This patch resolves the DMI issue for EFI hardware (DMI is now properly
detected at boot), and additionally efifb now loads on Apple hardware
(i.e. video works).
Upstream commit:
http://git.kernel.org/?p=linux/kernel/git/x86/linux-2.6-tip.git;a=commitd...
It would be helpful to have this patch included in Fedora before UEFI
test day (April 9th, 2009), if possible, being that the largest
percentage of UEFI hardware currently on the market is made by Apple. In
that respect, this patch is somewhat important.
Brian
14 years, 9 months
[PATCH] EFI: fix efi_ioremap
by Brian Maly
resolves BZ 466954
efi_ioremap is currently broken in fedora, so systems that have large
efi runtime regions mapped into higher mem are not able to re-map, the
result being the system fails to boot. The core issue is that any region
> 400K cannot currently be remapped with efi_ioremap due to size
limitations within the efi_ioremap code. So when an efi runtime region
is larger than 400K and in higher mem, it is not remapped. Systems most
affected by this issue tend to be made by Apple.
This patch was tested on MacBook Pro (Santa Rosa) and resolves the issue.
Upstream commit:
http://git.kernel.org/?p=linux/kernel/git/x86/linux-2.6-tip.git;a=commitd...
It would be helpful to have this patch included in Fedora before UEFI
test day (April 9th, 2009), if possible, being that the largest
percentage of UEFI hardware currently on the market is made by Apple. In
that respect, this patch is somewhat important.
Brian
------------------------------------------------------------------------
14 years, 9 months