Bug#628676: firmware-nonfree: add ti-connectivity firmware
On Sun, 5 Jun 2011, Ben Hutchings wrote: This firmware has a very problematic licence. It actually forbids anyone to download the firmware without agreeing to the licence. We have no way to ask users whether they agree to this before even downloading the package. Do not download this unless you intend to comply with its licence is fairly much implicit in *anything* we distribute, isn't it? You only have permission to copy GPL software *if* you comply with its licence. David, I'm rather surprised you accepted firmware into linux-firmware with these terms, as it seems to mean that anyone cloning the repository is expected to accept them. I *do* expect anyone cloning the repository to comply with the indivual licences for the components therein. -- dwmw2 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.LFD.2.02.1106051023040.5554@localhost6.localdomain6
Bug#628676: firmware-nonfree: add ti-connectivity firmware
On Sun, 5 Jun 2011, Ben Hutchings wrote: In reality every transfer over a network involves many transient copies being made. However, I think that legally only the sender tends to be held responsible for distributing or copying. It was sent to me by TI with the express intention of including it in the git tree in that form. I *do* expect anyone cloning the repository to comply with the indivual licences for the components therein. But you also allow anyone to clone it before seeing the licence terms that may disallow that. So far as I know, none of the other licence texts claim to restrict recipients that don't use or redistribute the firmware. If you do nothing with the firmware, but it merely exists in your clone of the git tree (by virtue of TI's having deliberately put it there), what exactly are you restricted from doing? Why is this different to GPL'd firmware on which you violate the licence, and lose your rights? -- dwmw2 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.LFD.2.02.1106051751160.5554@localhost6.localdomain6
Re: alsa-firmware in firmware-linux-non-free package
On Tue, 2010-10-19 at 10:10 +0100, David Henningsson wrote: However I think these firmware images should be added to the linux-firmware.git repository first, as that is the 'upstream' used as a base for most distributions that provide firmware packages. Definitely. And so I offer the same assistance to David Woodhouse as I do to you in Debian - willingness to answer questions etc, to make this happen. You are welcome to help me remind him to actually pick these things up. Where do I pick them up from? The git tree referenced above seems to add to a 'WHENCE.ubuntu' file instead of the main WHENCE file. I'm also thinking of moving to something based on http://wiki.debian.org/Proposals/CopyrightFormat and adding extra metadata about the earliest/latest kernels for which any given firmware file is relevant, as well as a simple 'build' system. -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1287484275.15412.11.ca...@i7.infradead.org
Bug#553024: [PATCH 1/2] phylib: Support phy module autoloading
On Thu, 2010-04-01 at 19:38 -0700, David Miller wrote: Whatever you submit next I'd like to toss into net-next-2.6 so it can cook for a while and maybe we'll backport it so that this bug can be fixed for good upstream and then perhaps even in -stable. When backporting, note that you'll need s/PHY_ID_BCMAC131/0x0143bc70/ in the patch to broadcom.c, because 2.6.32 didn't have a definition for that. There's also trivial change in phy_device_create() which will make the patch fail to apply, but git-cherry-pick copes. -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1270206895.3101.2467.ca...@macbook.infradead.org
Bug#553024: [PATCH 1/2] phylib: Support phy module autoloading
On Thu, 2010-04-01 at 05:34 +0100, Ben Hutchings wrote:
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -188,7 +188,7 @@ struct phy_device* phy_device_create(struct mii_bus *bus,
int addr, int phy_id)
around for long enough for the driver to get loaded. With
MDIO, the NIC driver will get bored and give up as soon
as it finds that there's no driver _already_ loaded. */
- sprintf(modid, phy: PHYID_FMT, PHYID_ARGS(phy_id));
+ sprintf(modid, MDIO_MODULE_PREFIX MDIO_ID_FMT, MDIO_ID_ARGS(phy_id));
request_module(modid);
You forgot to increase the size of the 'modid' storage there, and it
needed to grow by one character. But that's OK. I forgot that
request_module() takes printf-style arguments. So now I've killed the
temporary 'modid' buffer altogether, and I just call
request_module(MDIO_MODULE_PREFIX ...). I dropped the ifdef, too.
-#define PHY_MODULE_PREFIXphy:
+#define MDIO_MODULE_PREFIX mdio:
-#define PHYID_FMT
%d%d%d%d%d%d%d%d%d%d%d%d%d%d%d%d%d%d%d%d%d%d%d%d%d%d%d%d%d%d%d%d
-#define PHYID_ARGS(_id) \
+#define MDIO_ID_FMT
%d%d%d%d%d%d%d%d%d%d%d%d%d%d%d%d%d%d%d%d%d%d%d%d%d%d%d%d%d%d%d%d
+#define MDIO_ID_ARGS(_id) \
(_id)31, ((_id)30) 1, ((_id)29) 1, ((_id)28) 1, \
((_id)27) 1, ((_id)26) 1, ((_id)25) 1, ((_id)24) 1, \
((_id)23) 1, ((_id)22) 1, ((_id)21) 1, ((_id)20) 1, \
@@ -487,11 +487,17 @@ struct platform_device_id {
((_id)7) 1, ((_id)6) 1, ((_id)5) 1, ((_id)4) 1, \
((_id)3) 1, ((_id)2) 1, ((_id)1) 1, (_id) 1
Still tempted to add a %b format to the kernel's printf... some runtimes
have it.
-
-
-struct phy_device_id {
- uint32_t phy_id;
- uint32_t phy_id_mask;
+/**
+ * struct mdio_device_id - identifies PHY devices on an MDIO/MII bus
+ * @phy_id: The result of
+ * (mdio_read(MII_PHYSID1) 16 | mdio_read(PHYSID2)) @phy_id_mask
+ * for this PHY type
+ * @phy_id_mask: Defines the significant bits of @phy_id. A value of 0
+ * is used to terminate an array of struct mdio_device_id.
That last sentence is a lie; I removed it. file2alias.c just ignores the
last entry in the array regardless of what it contains. I have no idea
why we use a 'terminator' in these arrays. Legacy, perhaps?
static int do_phy_entry(const char *filename,
- struct phy_device_id *id, char *alias)
+ struct mdio_device_id *id, char *alias)
I made that 'do_mdio_entry()' for cosmetic reasons.
- sizeof(struct phy_device_id), phy,
+ sizeof(struct mdio_device_id), phy,
And that mdio, not phy, so that it works.
--
dwmw2
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/1270204703.3101.2368.ca...@macbook.infradead.org
Bug#553024: [PATCH 1/2] phylib: Support phy module autoloading
On Thu, 2010-04-01 at 05:34 +0100, Ben Hutchings wrote: On Wed, 2010-03-31 at 02:18 +0100, David Woodhouse wrote: We don't use the normal hotplug mechanism because it doesn't work. It will load the module some time after the device appears, but that's not good enough for us -- we need the driver loaded _immediately_ because otherwise the NIC driver may just abort and then the phy 'device' goes away. Instead, we just issue a request_module() directly in phy_device_create(). [...] Thanks for doing this, David. I had a stab at it earlier when this problem was reported in Debian http://bugs.debian.org/553024. I didn't complete this because (a) I didn't understand all the details of adding new device table type, and (b) I tried to avoid duplicating information, which turns out to be rather difficult in modules with multiple drivers. It shouldn't be _that_ hard. You could contrive a macro which you use inside the driver definition and which takes the phy_id and phy_id_mask as arguments, and has the side-effect of setting up the MODULE_DEVICE_TABLE data. Since you've dealt with (a), and (b) is not really as important, I would just like to suggest some minor changes to your patch 1 (see below). Feel free to fold them in. Your patch 2 would then need the substitutions s/phy_device_id/mdio_device_id/; s/TABLE(phy/TABLE(mdio/. I'll tolerate the silly __u32 crap if I must for consistency, but normally I prefer to write in C. I did think about 'mdio:' for the module alias, but I decided that 'phy:' probably made more sense since these are PHY driver modules and the number is the phy_id. Kernel-doc is good though. -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1270141428.3101.399.ca...@macbook.infradead.org
Re: Building vanilla kernel .debs
On Tue, 2009-10-27 at 20:40 +0100, maximilian attems wrote: hello David, I have a question on howto ship firmware build out of make deb-pkg in linux-2.6. On Mon, 26 Oct 2009, Ben Hutchings wrote: On Mon, 2009-10-26 at 21:27 +0100, Marc Haber wrote: Hi, Is it a feature that the linux-firmware package doesn't have the upstream kernel version in its name? Possibly not. $ make deb-pkg (...) dpkg-deb: building package linux-firmware-image' in ../linux-firmware-image_2.6.31.4.20091026.4_all.deb'. dpkg-deb: building package linux-image-2.6.31.4-zgws1' in ../linux-image-2.6.31.4-zgws1_2.6.31.4.20091026.4_i386.deb'. I could imagine that, a driver in kernel 2.6.x would need different firmware than the same driver in kernel 2.6.y, where it would be very helpful to have multiple firmware packages installed. The linux-firmware repository git://git.kernel.org/pub/scm/linux/kernel/git/dwmw2/linux-firmware.git contains multiple versions of some firmware for just this reason. However, Linux source trees do not. Does the firmware infrastructure cater for this need? tried to pass INSTALL_FW_PATH to modules_install call in scripts/packages/builddep, but this is happily ignored there. is it an anachronism that the INSTALL_FW_PATH defaults to $(INSTALL_MOD_PATH)/lib/firmware and not $(INSTALL_MOD_PATH)/lib/firmware/$(KERNELRELEASE)/ That's intentional. There is no need for it -- the firmware should live in /lib/firmware. If there are incompatible versions of firmware, then they'll have a different filename and can co-exist. The ability to use firmware installed directly from the kernel source tree is intended as a stop-gap; not as a long-term solution. You should be installing the linux-firmware package instead. -- dwmw2 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Building vanilla kernel .debs
On Wed, 2009-10-28 at 10:48 +0100, Marc Haber wrote: On Wed, Oct 28, 2009 at 07:30:47AM +, David Woodhouse wrote: That's intentional. There is no need for it -- the firmware should live in /lib/firmware. If there are incompatible versions of firmware, then they'll have a different filename and can co-exist. This is, however, a challenge for the packaging system. With the current scheme, I cannot have the firmware package for kernel 2.6.x installed while the firmware package for kernel 2.6.y is installed. Right. The newer firmware package ought to be perfectly sufficient for use with the older kernel. If we had this scheme in the past, having a fallback kernel would have been hard or impossible during firmware transitions, which for example the ipw2x00 drivers have gone through multiple times. Please rethink this intention. You misunderstand. Shipping firmware packages built from the kernel is just a transitional thing. You should be using the linux-firmware package instead, which includes old _and_ new firmware. -- dwmw2 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Building vanilla kernel .debs
On Wed, 2009-10-28 at 11:31 +0100, Marc Haber wrote: On Wed, Oct 28, 2009 at 10:17:52AM +, David Woodhouse wrote: On Wed, 2009-10-28 at 10:48 +0100, Marc Haber wrote: On Wed, Oct 28, 2009 at 07:30:47AM +, David Woodhouse wrote: That's intentional. There is no need for it -- the firmware should live in /lib/firmware. If there are incompatible versions of firmware, then they'll have a different filename and can co-exist. This is, however, a challenge for the packaging system. With the current scheme, I cannot have the firmware package for kernel 2.6.x installed while the firmware package for kernel 2.6.y is installed. Right. The newer firmware package ought to be perfectly sufficient for use with the older kernel. It frequently is not. See ipw2x00. ipw2x00 isn't shipped in the kernel source tree, so is completely irrelevant to this discussion. Please, come back when you have an idea what you're talking about. -- dwmw2 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
