* Re: Udev remove --type failed logic
From: Andrey Borzenkov @ 2011-03-24 3:38 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTin+2CTXo=Vw9K=FUWei7Wa-nKbamu-ExbWG-OdR@mail.gmail.com>
On Thu, Mar 24, 2011 at 5:05 AM, Seblu <seblu@seblu.net> wrote:
> Hello,
>
> I see in TODO from last git commit, that --type failed logic will be
> removed from udev.
>
> I trying to patch an issue in my archlinux with bluetoothd and udev
> rules wich start it.
> One idea was to extend add RUN{fail_event_on_error} in place of RUN,
> to recall it after dbus was started.
>
That is exactly what I have done to fix missing BT after standard
services were removed and replaced by udev activation.
> But it's seems you will remove this feature from udev.
>
> Why remove it?
Hmm ... I presume it is removal of systemd unit, hopefully not removal
of support of option from udevadm. Under systemd this should not be
required indeed under most conditions. And udev never shipped
initscripts, this was always distribution responsibility - here
nothing changes.
> What is your recommendation about those cases?
>
^ permalink raw reply
* Re: Udev remove --type failed logic
From: Kay Sievers @ 2011-03-24 3:59 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTin+2CTXo=Vw9K=FUWei7Wa-nKbamu-ExbWG-OdR@mail.gmail.com>
On Thu, Mar 24, 2011 at 03:05, Seblu <seblu@seblu.net> wrote:
> I see in TODO from last git commit, that --type failed logic will be
> removed from udev.
>
> I trying to patch an issue in my archlinux with bluetoothd and udev
> rules wich start it.
> One idea was to extend add RUN{fail_event_on_error} in place of RUN,
> to recall it after dbus was started.
>
> But it's seems you will remove this feature from udev.
>
> Why remove it?
> What is your recommendation about those cases?
Use a modern init system that can track devices and start stuff
properly on demand. Udev was never the right tool for starting
services, or mounting disks, it should just classify devices and send
events to something that is able to do proper service management.
In case you are stuck with an old init, just trigger the bluetooth
events again from an init script, instead of letting udev take care of
tracking "failed events". Or create your own marker somewhere, that
indicates something needs to be tried again.
The entire concept of "failing events" and globally just re-trigger
them does not make much sense anymore for udev. The code that does
that is still there and will not go away soon, but it should not be
used anymore when possible.
Thanks,
Kay
^ permalink raw reply
* Re: Udev remove --type failed logic
From: Kay Sievers @ 2011-03-24 12:23 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTin+2CTXo=Vw9K=FUWei7Wa-nKbamu-ExbWG-OdR@mail.gmail.com>
On Thu, Mar 24, 2011 at 04:59, Kay Sievers <kay.sievers@vrfy.org> wrote:
> On Thu, Mar 24, 2011 at 03:05, Seblu <seblu@seblu.net> wrote:
>> I see in TODO from last git commit, that --type failed logic will be
>> removed from udev.
>>
>> I trying to patch an issue in my archlinux with bluetoothd and udev
>> rules wich start it.
>> One idea was to extend add RUN{fail_event_on_error} in place of RUN,
>> to recall it after dbus was started.
>>
>> But it's seems you will remove this feature from udev.
>>
>> Why remove it?
>> What is your recommendation about those cases?
> In case you are stuck with an old init, just trigger the bluetooth
> events again from an init script
That's what recent bluez does:
udevadm trigger --subsystem-match=bluetooth --actiond
Not how things should work today where init supports on-demand stuff
-- but it does not need the weird "failed" from udev.
Kay
^ permalink raw reply
* [PATCH] Set PCIE maxpayload for card during hotplug insertion
From: Jordan Hargrave @ 2011-03-24 22:21 UTC (permalink / raw)
To: linux-hotplug
Reference: http://marc.info/?l=linux-hotplug&m\x128932324625063&w=2
The following patch sets the MaxPayload setting to match the parent reading when inserting
a PCIE card into a hotplug slot. On our system, the upstream bridge is set to 256, but when
inserting a card, the card setting defaults to 128. As soon as I/O is performed to the card
it starts receiving errors since the payload size is too small.
Signed-off-by: Jordan_Hargrave@dell.com
---
drivers/pci/hotplug/pcihp_slot.c | 45 ++++++++++++++++++++++++++++++++++++++
1 files changed, 45 insertions(+), 0 deletions(-)
diff --git a/drivers/pci/hotplug/pcihp_slot.c b/drivers/pci/hotplug/pcihp_slot.c
index 80b461c..912d55b 100644
--- a/drivers/pci/hotplug/pcihp_slot.c
+++ b/drivers/pci/hotplug/pcihp_slot.c
@@ -158,6 +158,47 @@ static void program_hpp_type2(struct pci_dev *dev, struct hpp_type2 *hpp)
*/
}
+/* Program PCIE MaxPayload setting on device: ensure parent maxpayload <= device */
+static int pci_set_payload(struct pci_dev *dev)
+{
+ int pos, ppos;
+ u16 pctl, psz;
+ u16 dctl, dsz, dcap, dmax;
+ struct pci_dev *parent;
+
+ parent = dev->bus->self;
+ pos = pci_find_capability(dev, PCI_CAP_ID_EXP);
+ if (!pos)
+ return 0;
+
+ /* Read Device MaxPayload capability and setting */
+ pci_read_config_word(dev, pos + PCI_EXP_DEVCTL, &dctl);
+ pci_read_config_word(dev, pos + PCI_EXP_DEVCAP, &dcap);
+ dsz = (dctl & PCI_EXP_DEVCTL_PAYLOAD) >> 5;
+ dmax = (dcap & PCI_EXP_DEVCAP_PAYLOAD);
+
+ /* Read Parent MaxPayload setting */
+ ppos = pci_find_capability(parent, PCI_CAP_ID_EXP);
+ if (!ppos)
+ return 0;
+ pci_read_config_word(parent, ppos + PCI_EXP_DEVCTL, &pctl);
+ psz = (pctl & PCI_EXP_DEVCTL_PAYLOAD) >> 5;
+
+ /* If parent payload > device max payload -> error
+ * If parent payload > device payload -> set speed
+ * If parent payload <= device payload -> do nothing
+ */
+ if (psz > dmax)
+ return -1;
+ else if (psz > dsz) {
+ dev_info(&dev->dev, "Setting MaxPayload to %d\n", 128 << psz);
+ pci_write_config_word(dev, pos + PCI_EXP_DEVCTL,
+ (dctl & ~PCI_EXP_DEVCTL_PAYLOAD) +
+ (psz << 5));
+ }
+ return 0;
+}
+
void pci_configure_slot(struct pci_dev *dev)
{
struct pci_dev *cdev;
@@ -169,6 +210,10 @@ void pci_configure_slot(struct pci_dev *dev)
(dev->class >> 8) = PCI_CLASS_BRIDGE_PCI)))
return;
+ ret = pci_set_payload(dev);
+ if (ret)
+ dev_warn(&dev->dev, "could not set device max payload\n");
+
memset(&hpp, 0, sizeof(hpp));
ret = pci_get_hp_params(dev, &hpp);
if (ret)
--
1.7.3.4
^ permalink raw reply related
* Re: [PATCH] Set PCIE maxpayload for card during hotplug insertion
From: Kenji Kaneshige @ 2011-03-25 1:06 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1301005267-31006-1-git-send-email-jordan_hargrave@dell.com>
(2011/03/25 7:21), Jordan Hargrave wrote:
> Reference: http://marc.info/?l=linux-hotplug&m\x128932324625063&w=2
>
> The following patch sets the MaxPayload setting to match the parent reading when inserting
> a PCIE card into a hotplug slot. On our system, the upstream bridge is set to 256, but when
> inserting a card, the card setting defaults to 128. As soon as I/O is performed to the card
> it starts receiving errors since the payload size is too small.
>
> Signed-off-by: Jordan_Hargrave@dell.com
>
> ---
> drivers/pci/hotplug/pcihp_slot.c | 45 ++++++++++++++++++++++++++++++++++++++
> 1 files changed, 45 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/pci/hotplug/pcihp_slot.c b/drivers/pci/hotplug/pcihp_slot.c
> index 80b461c..912d55b 100644
> --- a/drivers/pci/hotplug/pcihp_slot.c
> +++ b/drivers/pci/hotplug/pcihp_slot.c
> @@ -158,6 +158,47 @@ static void program_hpp_type2(struct pci_dev *dev, struct hpp_type2 *hpp)
> */
> }
>
> +/* Program PCIE MaxPayload setting on device: ensure parent maxpayload<= device */
> +static int pci_set_payload(struct pci_dev *dev)
> +{
> + int pos, ppos;
> + u16 pctl, psz;
> + u16 dctl, dsz, dcap, dmax;
> + struct pci_dev *parent;
> +
> + parent = dev->bus->self;
> + pos = pci_find_capability(dev, PCI_CAP_ID_EXP);
> + if (!pos)
> + return 0;
You can use pci_pcie_cap(), which just returns dev->pcie_cap, instead of pci_find_capability().
> +
> + /* Read Device MaxPayload capability and setting */
> + pci_read_config_word(dev, pos + PCI_EXP_DEVCTL,&dctl);
> + pci_read_config_word(dev, pos + PCI_EXP_DEVCAP,&dcap);
> + dsz = (dctl& PCI_EXP_DEVCTL_PAYLOAD)>> 5;
> + dmax = (dcap& PCI_EXP_DEVCAP_PAYLOAD);
> +
> + /* Read Parent MaxPayload setting */
> + ppos = pci_find_capability(parent, PCI_CAP_ID_EXP);
> + if (!ppos)
> + return 0;
Ditto.
> + pci_read_config_word(parent, ppos + PCI_EXP_DEVCTL,&pctl);
> + psz = (pctl& PCI_EXP_DEVCTL_PAYLOAD)>> 5;
> +
> + /* If parent payload> device max payload -> error
> + * If parent payload> device payload -> set speed
> + * If parent payload<= device payload -> do nothing
> + */
> + if (psz> dmax)
> + return -1;
> + else if (psz> dsz) {
Maybe just "if" (not "else if") here is easier to read.
> + dev_info(&dev->dev, "Setting MaxPayload to %d\n", 128<< psz);
> + pci_write_config_word(dev, pos + PCI_EXP_DEVCTL,
> + (dctl& ~PCI_EXP_DEVCTL_PAYLOAD) +
> + (psz<< 5));
What about
dctrl = (dctrl & ~PCI_EXP_DEVCTL_PAYLOAD) | (psz << 5);
pci_write_config_word(dev, pos + PCI_EXP_DEVCTL, dctrl);
?
Regards,
Kenji Kaneshige
^ permalink raw reply
* Announcing biosdevname v0.3.8
From: Jordan_Hargrave @ 2011-03-28 7:33 UTC (permalink / raw)
To: linux-hotplug
biosdevname, now version 0.3.8.
Major changes include parsing NPAR data from cards to report virtual
function and the 'pci' prefix has now been changed to 'p'. NICs in
a PCI slot will now be of the form:
pXpY[_Z] where X is PCI slot, Y = port # and Z is virtual function.
Another major change is Matt Domsch is no longer the maintainer of
biosdevname. I have taken over the biosdevname project.
Shortlog:
Jordan Hargrave (6):
Fix debian packaging rules to regenerate configure script Submitted by Narendra
Change pciX to pX for shortened name
Fix manpage typo
Delete CR-LF in script
Change default signing key
Add changes to parse VPD structure for device mapping
Fix pathname
Cleanup and comment NPAR code
--jordan hargrave
Dell Enterprise Linux Engineering
^ permalink raw reply
* RE: [PATCH] Set PCIE maxpayload for card during hotplug insertion
From: Jordan_Hargrave @ 2011-03-28 7:52 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1301005267-31006-1-git-send-email-jordan_hargrave@dell.com>
> -----Original Message-----
> From: Kenji Kaneshige [mailto:kaneshige.kenji@jp.fujitsu.com]
> Sent: Thursday, March 24, 2011 8:07 PM
> To: Hargrave, Jordan
> Cc: linux-hotplug@vger.kernel.org; linux-pci@vger.kernel.org;
> jbarnes@virtuousgeek.org
> Subject: Re: [PATCH] Set PCIE maxpayload for card during hotplug
> insertion
>
> (2011/03/25 7:21), Jordan Hargrave wrote:
> > Reference: http://marc.info/?l=linux-hotplug&m\x128932324625063&w=2
> >
> > The following patch sets the MaxPayload setting to match the parent
> reading when inserting
> > a PCIE card into a hotplug slot. On our system, the upstream bridge
> is set to 256, but when
> > inserting a card, the card setting defaults to 128. As soon as I/O
> is performed to the card
> > it starts receiving errors since the payload size is too small.
> >
> > Signed-off-by: Jordan_Hargrave@dell.com
> >
> > ---
> > drivers/pci/hotplug/pcihp_slot.c | 45
> ++++++++++++++++++++++++++++++++++++++
> > 1 files changed, 45 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/pci/hotplug/pcihp_slot.c
> b/drivers/pci/hotplug/pcihp_slot.c
> > index 80b461c..912d55b 100644
> > --- a/drivers/pci/hotplug/pcihp_slot.c
> > +++ b/drivers/pci/hotplug/pcihp_slot.c
> > @@ -158,6 +158,47 @@ static void program_hpp_type2(struct pci_dev
> *dev, struct hpp_type2 *hpp)
> > */
> > }
> >
> > +/* Program PCIE MaxPayload setting on device: ensure parent
> maxpayload<= device */
> > +static int pci_set_payload(struct pci_dev *dev)
> > +{
> > + int pos, ppos;
> > + u16 pctl, psz;
> > + u16 dctl, dsz, dcap, dmax;
> > + struct pci_dev *parent;
> > +
> > + parent = dev->bus->self;
> > + pos = pci_find_capability(dev, PCI_CAP_ID_EXP);
> > + if (!pos)
> > + return 0;
>
> You can use pci_pcie_cap(), which just returns dev->pcie_cap, instead
> of pci_find_capability().
>
> > +
> > + /* Read Device MaxPayload capability and setting */
> > + pci_read_config_word(dev, pos + PCI_EXP_DEVCTL,&dctl);
> > + pci_read_config_word(dev, pos + PCI_EXP_DEVCAP,&dcap);
> > + dsz = (dctl& PCI_EXP_DEVCTL_PAYLOAD)>> 5;
> > + dmax = (dcap& PCI_EXP_DEVCAP_PAYLOAD);
> > +
> > + /* Read Parent MaxPayload setting */
> > + ppos = pci_find_capability(parent, PCI_CAP_ID_EXP);
> > + if (!ppos)
> > + return 0;
>
> Ditto.
>
> > + pci_read_config_word(parent, ppos + PCI_EXP_DEVCTL,&pctl);
> > + psz = (pctl& PCI_EXP_DEVCTL_PAYLOAD)>> 5;
> > +
> > + /* If parent payload> device max payload -> error
> > + * If parent payload> device payload -> set speed
> > + * If parent payload<= device payload -> do nothing
> > + */
> > + if (psz> dmax)
> > + return -1;
> > + else if (psz> dsz) {
>
> Maybe just "if" (not "else if") here is easier to read.
>
> > + dev_info(&dev->dev, "Setting MaxPayload to %d\n", 128<<
> psz);
> > + pci_write_config_word(dev, pos + PCI_EXP_DEVCTL,
> > + (dctl& ~PCI_EXP_DEVCTL_PAYLOAD) +
> > + (psz<< 5));
>
> What about
>
> dctrl = (dctrl & ~PCI_EXP_DEVCTL_PAYLOAD) | (psz << 5);
> pci_write_config_word(dev, pos + PCI_EXP_DEVCTL, dctrl);
>
> ?
>
> Regards,
> Kenji Kaneshige
Signed-off-by: Jordan Hargrave <Jordan_Hargrave@dell.com>
---
drivers/pci/hotplug/pcihp_slot.c | 44 ++++++++++++++++++++++++++++++++++++++
1 files changed, 44 insertions(+), 0 deletions(-)
diff --git a/drivers/pci/hotplug/pcihp_slot.c b/drivers/pci/hotplug/pcihp_slot.c
index 80b461c..3b628c5 100644
--- a/drivers/pci/hotplug/pcihp_slot.c
+++ b/drivers/pci/hotplug/pcihp_slot.c
@@ -158,6 +158,46 @@ static void program_hpp_type2(struct pci_dev *dev, struct hpp_type2 *hpp)
*/
}
+/* Program PCIE MaxPayload setting on device: ensure parent maxpayload
+<= device */ static int pci_set_payload(struct pci_dev *dev) {
+ int pos, ppos;
+ u16 pctl, psz;
+ u16 dctl, dsz, dcap, dmax;
+ struct pci_dev *parent;
+
+ parent = dev->bus->self;
+ pos = pci_pcie_cap(dev);
+ if (!pos)
+ return 0;
+
+ /* Read Device MaxPayload capability and setting */
+ pci_read_config_word(dev, pos + PCI_EXP_DEVCTL, &dctl);
+ pci_read_config_word(dev, pos + PCI_EXP_DEVCAP, &dcap);
+ dsz = (dctl & PCI_EXP_DEVCTL_PAYLOAD) >> 5;
+ dmax = (dcap & PCI_EXP_DEVCAP_PAYLOAD);
+
+ /* Read Parent MaxPayload setting */
+ ppos = pci_pcie_cap(parent);
+ if (!ppos)
+ return 0;
+ pci_read_config_word(parent, ppos + PCI_EXP_DEVCTL, &pctl);
+ psz = (pctl & PCI_EXP_DEVCTL_PAYLOAD) >> 5;
+
+ /* If parent payload > device max payload -> error
+ * If parent payload > device payload -> set speed
+ * If parent payload <= device payload -> do nothing
+ */
+ if (psz > dmax)
+ return -1;
+ if (psz > dsz) {
+ dev_info(&dev->dev, "Setting MaxPayload to %d\n", 128 << psz);
+ dctl = (dctl & ~PCI_EXP_DEVCTL_PAYLOAD) + (psz << 5);
+ pci_write_config_word(dev, pos + PCI_EXP_DEVCTL, dctl);
+ }
+ return 0;
+}
+
void pci_configure_slot(struct pci_dev *dev) {
struct pci_dev *cdev;
@@ -169,6 +209,10 @@ void pci_configure_slot(struct pci_dev *dev)
(dev->class >> 8) = PCI_CLASS_BRIDGE_PCI)))
return;
+ ret = pci_set_payload(dev);
+ if (ret)
+ dev_warn(&dev->dev, "could not set device max payload\n");
+
memset(&hpp, 0, sizeof(hpp));
ret = pci_get_hp_params(dev, &hpp);
if (ret)
--
1.7.4.1
^ permalink raw reply related
* A question about udev
From: Peter Bašista @ 2011-03-29 12:23 UTC (permalink / raw)
To: linux-hotplug
Hello,
I would like to consult an issue I have. It is, I suppose, related to udev.
I was looking for some mailing list to ask about it and I found
this... I am sorry if I am asking at the wrong place. In that case,
could you please suggest some other spot where can I ask about this?
Thank you.
And now, the issue:
Basically, on my system, the directory /dev/disk/by-uuid is not
created. I don't know why.
I don't know what could have caused it. But I have some suspicion. I
have done some experiments with e2fsprogs (I checked out the newest
git version in order to try the file defragmentation on ext4
partitions). It all went well, I could "make", then "make install" it,
even use it afterwards ... and it worked without any problem,
actually. I was satisfied with it.
But after restart, however, there was no /dev/disk/by-uuid directory
on my system. I started to wonder why. I at first supposed it must
have been the e2fsprogs. So, I "dpkg-reconfigured" the "old" Ubuntu
version of e2fsprogs and expected everything to work well again. But,
unfortunately and to my surprise, it did not change anything.
I was not able to have the /dev/disk/by-uuid directory created ever
since. I tried reinstalling udev as well, installing newer version of
udev and some other things, I can't remember exactly... but nothing
helped. And I am now stuck. I don't know what else to try, where else
to look...
I would appreciate some help here. I would like to know what could be
the cause of /dev/disk/by-uuid directory not being created. I will
readily provide any further information necessary.
The reason why I ask here and not on e2fsprogs mailing list is that I
believe the relation of e2fsprogs to my problem was just a
coincidence. I may as well be wrong, however, but I thought it would
be better to start there.
Sincerely
--
Peter Basista
pbasista@gmail.com
^ permalink raw reply
* Re: Announcing biosdevname v0.3.8
From: Tom Chiverton @ 2011-03-29 15:55 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <5B3AAEAF6B46EA4D955DF7AD46C2C48503989E79@AUSX7MCPS303.AMER.DELL.COM>
On 28 March 2011 08:33, <Jordan_Hargrave@dell.com> wrote:
> a PCI slot will now be of the form:
> pXpY[_Z] where X is PCI slot, Y = port # and Z is virtual function.
Srsly ? The default NIC name on Linux is going to be 'poo poo' (p0p0) ?
--
Tom
^ permalink raw reply
* RE: Announcing biosdevname v0.3.8
From: Jordan_Hargrave @ 2011-03-29 18:17 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <5B3AAEAF6B46EA4D955DF7AD46C2C48503989E79@AUSX7MCPS303.AMER.DELL.COM>
No, since both slot number and port are 1-based, for the first port on a NIC in PCI slot 1, it will be p1p1.
Default NIC name for the first embedded NIC will be em1.
--jordan hargrave
Dell Enterprise Linux Engineering
> -----Original Message-----
> From: Tom Chiverton [mailto:tom.chiverton@gmail.com]
> Sent: Tuesday, March 29, 2011 10:55 AM
> To: linux-desktops
> Cc: Hargrave, Jordan; linux-desktops; linux-hotplug@vger.kernel.org
> Subject: Re: Announcing biosdevname v0.3.8
>
> On 28 March 2011 08:33, <Jordan_Hargrave@dell.com> wrote:
> > a PCI slot will now be of the form:
> > pXpY[_Z] where X is PCI slot, Y = port # and Z is virtual function.
>
> Srsly ? The default NIC name on Linux is going to be 'poo poo' (p0p0) ?
>
> --
> Tom
^ permalink raw reply
* RE: [PATCH] Set PCIE maxpayload for card during hotplug insertion
From: Jordan_Hargrave @ 2011-03-29 21:42 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1301005267-31006-1-git-send-email-jordan_hargrave@dell.com>
Are there any further comments on this diff?
Would it be better to have a separate pcie_get_maxpayload/pcie_set_maxpayload function?
What about cards that fail the 'if (psz > dmax)' test? Technically the code should walk up to the root complex and set the speed there to the least common denominator speed of all children. However if that happens, the performance of other cards/PCI devices in the system maybe adversely affected. Any ideas on how to implement this or if this is desired?
--jordan hargrave
Dell Enterprise Linux Engineering
> -----Original Message-----
> From: Hargrave, Jordan
> Sent: Monday, March 28, 2011 2:53 AM
> Cc: 'linux-hotplug@vger.kernel.org'; 'linux-pci@vger.kernel.org'
> Subject: RE: [PATCH] Set PCIE maxpayload for card during hotplug
> insertion
>
> > -----Original Message-----
> > From: Kenji Kaneshige [mailto:kaneshige.kenji@jp.fujitsu.com]
> > Sent: Thursday, March 24, 2011 8:07 PM
> > To: Hargrave, Jordan
> > Cc: linux-hotplug@vger.kernel.org; linux-pci@vger.kernel.org;
> > jbarnes@virtuousgeek.org
> > Subject: Re: [PATCH] Set PCIE maxpayload for card during hotplug
> > insertion
> >
> > (2011/03/25 7:21), Jordan Hargrave wrote:
> > > Reference: http://marc.info/?l=linux-hotplug&m\x128932324625063&w=2
> > >
> > > The following patch sets the MaxPayload setting to match the parent
> > reading when inserting
> > > a PCIE card into a hotplug slot. On our system, the upstream
> bridge
> > is set to 256, but when
> > > inserting a card, the card setting defaults to 128. As soon as I/O
> > is performed to the card
> > > it starts receiving errors since the payload size is too small.
> > >
> > > Signed-off-by: Jordan_Hargrave@dell.com
> > >
> > > ---
> > > drivers/pci/hotplug/pcihp_slot.c | 45
> > ++++++++++++++++++++++++++++++++++++++
> > > 1 files changed, 45 insertions(+), 0 deletions(-)
> > >
> > > diff --git a/drivers/pci/hotplug/pcihp_slot.c
> > b/drivers/pci/hotplug/pcihp_slot.c
> > > index 80b461c..912d55b 100644
> > > --- a/drivers/pci/hotplug/pcihp_slot.c
> > > +++ b/drivers/pci/hotplug/pcihp_slot.c
> > > @@ -158,6 +158,47 @@ static void program_hpp_type2(struct pci_dev
> > *dev, struct hpp_type2 *hpp)
> > > */
> > > }
> > >
> > > +/* Program PCIE MaxPayload setting on device: ensure parent
> > maxpayload<= device */
> > > +static int pci_set_payload(struct pci_dev *dev)
> > > +{
> > > + int pos, ppos;
> > > + u16 pctl, psz;
> > > + u16 dctl, dsz, dcap, dmax;
> > > + struct pci_dev *parent;
> > > +
> > > + parent = dev->bus->self;
> > > + pos = pci_find_capability(dev, PCI_CAP_ID_EXP);
> > > + if (!pos)
> > > + return 0;
> >
> > You can use pci_pcie_cap(), which just returns dev->pcie_cap, instead
> > of pci_find_capability().
> >
> > > +
> > > + /* Read Device MaxPayload capability and setting */
> > > + pci_read_config_word(dev, pos + PCI_EXP_DEVCTL,&dctl);
> > > + pci_read_config_word(dev, pos + PCI_EXP_DEVCAP,&dcap);
> > > + dsz = (dctl& PCI_EXP_DEVCTL_PAYLOAD)>> 5;
> > > + dmax = (dcap& PCI_EXP_DEVCAP_PAYLOAD);
> > > +
> > > + /* Read Parent MaxPayload setting */
> > > + ppos = pci_find_capability(parent, PCI_CAP_ID_EXP);
> > > + if (!ppos)
> > > + return 0;
> >
> > Ditto.
> >
> > > + pci_read_config_word(parent, ppos + PCI_EXP_DEVCTL,&pctl);
> > > + psz = (pctl& PCI_EXP_DEVCTL_PAYLOAD)>> 5;
> > > +
> > > + /* If parent payload> device max payload -> error
> > > + * If parent payload> device payload -> set speed
> > > + * If parent payload<= device payload -> do nothing
> > > + */
> > > + if (psz> dmax)
> > > + return -1;
> > > + else if (psz> dsz) {
> >
> > Maybe just "if" (not "else if") here is easier to read.
> >
> > > + dev_info(&dev->dev, "Setting MaxPayload to %d\n", 128<<
> > psz);
> > > + pci_write_config_word(dev, pos + PCI_EXP_DEVCTL,
> > > + (dctl& ~PCI_EXP_DEVCTL_PAYLOAD) +
> > > + (psz<< 5));
> >
> > What about
> >
> > dctrl = (dctrl & ~PCI_EXP_DEVCTL_PAYLOAD) | (psz << 5);
> > pci_write_config_word(dev, pos + PCI_EXP_DEVCTL, dctrl);
> >
> > ?
> >
> > Regards,
> > Kenji Kaneshige
^ permalink raw reply
* [ANNOUNCE] udev 167 release
From: Kay Sievers @ 2011-03-30 16:28 UTC (permalink / raw)
To: linux-hotplug
Here comes a new udev version. Thanks to all who have contributed to
this release.
The tarball can be found here:
ftp://ftp.kernel.org/pub/linux/utils/kernel/hotplug/
The development repository can be found here:
http://www.kernel.org/git/?p=linux/hotplug/udev.git;a=summary
The ChangeLog can be found here:
http://www.kernel.org/git/?p=linux/hotplug/udev.git;a=blob;hb=HEAD;f=ChangeLog
udev 167
====
Bugfixes.
The udev runtime data moved from /dev/.udev/ to /run/udev/. The
/run mountpoint is supposed to be a tmpfs mounted during early boot,
available and writable to for all tools at any time during bootup,
it replaces /var/run/, which should become a symlink some day.
If /run does not exist, or is not writable, udev will fall back using
/dev/.udev/.
On systemd systems with initramfs and LVM used, packagers must
make sure, that the systemd and initramfs versions match. The initramfs
needs to create the /run mountpoint for udev to store the data, and
mount this tmpfs to /run in the rootfs, so the that the udev database
is preserved for the udev version started in the rootfs.
The command 'udevadm info --convert-db' is gone. The udev daemon
itself, at startup, converts any old database version if necessary.
The systemd services files have been reorganized. The udev control
socket is bound by systemd and passed to the started udev daemon.
The udev-settle.service is no longer active by default. Services which
can not handle hotplug setups properly need to actively pull it in, to
act like a barrier. Alternatively the settle service can be unconditionally
'systemctl'enabled, and act like a barrier for basic.target.
The fstab_import callout is no longer built or installed. Udev
should not be used to mount, does not watch changes to fstab, and
should not mirror fstab values in the udev database.
udev 166
====
Bugfixes.
New and updated keymaps.
^ permalink raw reply
* How to Install
From: Paulo Eliseu Weber @ 2011-03-30 23:01 UTC (permalink / raw)
To: linux-hotplug
Hi,
How to install on debian kernal 2.6.16?
Thanks,
Paul.
^ permalink raw reply
* Re: How to Install
From: Kay Sievers @ 2011-03-30 23:10 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4D93B631.20604@yahoo.com.br>
On Thu, Mar 31, 2011 at 01:01, Paulo Eliseu Weber
<pauloe.weber@yahoo.com.br> wrote:
> How to install on debian kernal 2.6.16?
Wrong list. This is upstream development of current udev/hotplug.
Nobody remembers deatails about such ancient stuff as Linux 2.6.16
here, sorry.
Kay
^ permalink raw reply
* Re: [ANNOUNCE] udev 167 release
From: Gabor Z. Papp @ 2011-03-31 8:03 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTi=Ff2rrxHeObMMtasxpHPDkET+UneDr8-n6F89h@mail.gmail.com>
* Kay Sievers <kay.sievers@vrfy.org>:
| Here comes a new udev version. Thanks to all who have contributed to
| this release.
$ dmesg
<30>udev[1589]: converting old udev database
<30>udev[1590]: starting version 167
what is/mean <30> before udev[1589]?
^ permalink raw reply
* [PATCH] Add rule for Acer Aspire One ZG8 to use acer-aspire_5720 keymap
From: Lee, Chun-Yi @ 2011-03-31 10:01 UTC (permalink / raw)
To: linux-hotplug
Acer Aspire One ZG8's bluetooth HW key emit 0xD9 scancode, it must map
to KEY_BLUETOOTH like Acer Aspire 5720. So, add rule for Acer Aspire One
ZG8 use acer-aspire_5720 keymap.
Tested on Acer Aspire One ZG8 netbook.
Signed-off-by: Lee, Chun-Yi <jlee@novell.com>
---
| 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
--git a/extras/keymap/95-keymap.rules b/extras/keymap/95-keymap.rules
index 0c3ae38..44d5064 100644
--- a/extras/keymap/95-keymap.rules
+++ b/extras/keymap/95-keymap.rules
@@ -100,6 +100,7 @@ ENV{DMI_VENDOR}="Acer*", ATTR{[dmi/id]product_name}="Aspire 6920", RUN+="keyma
ENV{DMI_VENDOR}="Acer*", ATTR{[dmi/id]product_name}="Aspire 5920G", RUN+="keymap $name acer-aspire_5920g"
ENV{DMI_VENDOR}="Acer*", ATTR{[dmi/id]product_name}="Aspire 5720*", RUN+="keymap $name acer-aspire_5720"
ENV{DMI_VENDOR}="Acer*", ATTR{[dmi/id]product_name}="Aspire 8930", RUN+="keymap $name acer-aspire_8930"
+ENV{DMI_VENDOR}="Acer*", ATTR{[dmi/id]product_serial}="ZG8*", RUN+="keymap $name acer-aspire_5720"
ENV{DMI_VENDOR}="*BenQ*", ATTR{[dmi/id]product_name}="*Joybook R22*", RUN+="keymap $name 0x6E wlan"
--
1.6.0.2
^ permalink raw reply related
* Re: [ANNOUNCE] udev 167 release
From: Kay Sievers @ 2011-03-31 10:08 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTi=Ff2rrxHeObMMtasxpHPDkET+UneDr8-n6F89h@mail.gmail.com>
On Thu, Mar 31, 2011 at 10:03, Gabor Z. Papp <gzp@papp.hu> wrote:
> * Kay Sievers <kay.sievers@vrfy.org>:
>
> | Here comes a new udev version. Thanks to all who have contributed to
> | this release.
>
> $ dmesg
> <30>udev[1589]: converting old udev database
> <30>udev[1590]: starting version 167
>
> what is/mean <30> before udev[1589]?
Seems your dmesg needs to be fixed to recognize full syslog prefixes.
Userspace uses proper facility values now, for dmesg, syslog, the
admin, to be able to properly distinguish kernel messages from
userspace-injected ones.
Udev, and a few other common early-boot tools which write to the
kernel buffer added such facility value. For udev it's LOG_DAEMON
which is 3, the log level is 6, so the prefix <30> is (3*8)+6.
The kernel pretty-print part is here:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;hù90c8d9cde929cbc575098e825d7c29d9f45054
Kay
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] udevd.c: Add 'N:' to optstring in getopt_long
From: Thomas Egerer @ 2011-03-31 13:06 UTC (permalink / raw)
To: linux-hotplug
[-- Attachment #1: Type: text/plain, Size: 138 bytes --]
Signed-off-by: Thomas Egerer <thomas.egerer@secunet.com>
---
udev/udevd.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
[-- Attachment #2: 0001-udevd.c-Add-N-to-optstring-in-getopt_long.patch --]
[-- Type: text/x-patch, Size: 359 bytes --]
diff --git a/udev/udevd.c b/udev/udevd.c
index 1871474..53db44a 100644
--- a/udev/udevd.c
+++ b/udev/udevd.c
@@ -1118,7 +1118,7 @@ int main(int argc, char *argv[])
for (;;) {
int option;
- option = getopt_long(argc, argv, "c:deDthV", options, NULL);
+ option = getopt_long(argc, argv, "c:deDthN:V", options, NULL);
if (option == -1)
break;
^ permalink raw reply related
* Re: [PATCH] udevd.c: Add 'N:' to optstring in getopt_long
From: Martin Pitt @ 2011-03-31 14:30 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4D947C4F.6060301@secunet.com>
Hello Thomas,
Thomas Egerer [2011-03-31 15:06 +0200]:
> - option = getopt_long(argc, argv, "c:deDthV", options, NULL);
> + option = getopt_long(argc, argv, "c:deDthN:V", options, NULL);
This is certainly an inconsistency, but I wonder if we shouldn't
instead just remove the other short options from the optstring?
Neither --help nor the manpage document the short versions, so they
could be considered a kind of implementation detail?
I. e. we should perhaps only support the documented long options.
Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
^ permalink raw reply
* Re: [PATCH] Add rule for Acer Aspire One ZG8 to use acer-aspire_5720
From: Martin Pitt @ 2011-03-31 14:38 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1301565665-407-1-git-send-email-jlee@novell.com>
[-- Attachment #1: Type: text/plain, Size: 407 bytes --]
Hello Lee,
Lee, Chun-Yi [2011-03-31 18:01 +0800]:
> Acer Aspire One ZG8's bluetooth HW key emit 0xD9 scancode, it must map
> to KEY_BLUETOOTH like Acer Aspire 5720. So, add rule for Acer Aspire One
> ZG8 use acer-aspire_5720 keymap.
Thanks! Applied.
Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] udevd.c: Add 'N:' to optstring in getopt_long
From: Kay Sievers @ 2011-03-31 15:21 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4D947C4F.6060301@secunet.com>
On Thu, Mar 31, 2011 at 16:30, Martin Pitt <martin.pitt@ubuntu.com> wrote:
> Hello Thomas,
>
> Thomas Egerer [2011-03-31 15:06 +0200]:
>> - option = getopt_long(argc, argv, "c:deDthV", options, NULL);
>> + option = getopt_long(argc, argv, "c:deDthN:V", options, NULL);
>
> This is certainly an inconsistency, but I wonder if we shouldn't
> instead just remove the other short options from the optstring?
> Neither --help nor the manpage document the short versions, so they
> could be considered a kind of implementation detail?
>
> I. e. we should perhaps only support the documented long options.
There is no real need to have the long and short ones in sync.
Most of the short options are only used on the commandline during
development, and none of them are documented, or there are any real
guarantees about them to stay as they are.
Only the documented long options should be used for anything that is
not a human on the commandline.
Kay
^ permalink raw reply
* Re: [PATCH] udevd.c: Add 'N:' to optstring in getopt_long
From: Kay Sievers @ 2011-03-31 15:29 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4D947C4F.6060301@secunet.com>
On Thu, Mar 31, 2011 at 15:06, Thomas Egerer <thomas.egerer@secunet.com> wrote:
> udev/udevd.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
Applied. But please use the long options is anything that can not cope
with possible changes. The short options are just there to please
humans, not scripts. :)
Thanks,
Kay
^ permalink raw reply
* [BUG] udev 167, build of essential helper progs disabled
From: Juergen Daubert @ 2011-03-31 16:39 UTC (permalink / raw)
To: linux-hotplug
Patch [1] disables the build of all essential helper progs like ata_id,
usb_id etc. if --disable-extras is used, even though the excluded
programs do _not_ depend on special libraries. Not installing these
programs renders udev mostly useless because many installed rules are
using e.g. usb_id.
I'd suggest to revert patch [1].
regards
Juergen
[1] http://git.kernel.org/?p=linux/hotplug/udev.git;a=commit;hê5818f5961446ac32d1b2d165185fffddc4915a
--
Juergen Daubert | mailto:jue@jue.li
Korb, Germany | http://jue.li/crux
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [BUG] udev 167, build of essential helper progs disabled
From: Martin Pitt @ 2011-03-31 17:30 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20110331163908.GA6247@jue.netz>
Hello Juergen,
Juergen Daubert [2011-03-31 18:39 +0200]:
> Patch [1] disables the build of all essential helper progs like ata_id,
> usb_id etc. if --disable-extras is used, even though the excluded
> programs do _not_ depend on special libraries. Not installing these
> programs renders udev mostly useless because many installed rules are
> using e.g. usb_id.
>
> I'd suggest to revert patch [1].
Done in head now, thanks for pointing out. Just discussed on IRC, this
was by and large a misunderstanding; sorry about that!
Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
^ permalink raw reply
* "udevadm settle" and "init"
From: Kay Sievers @ 2011-03-31 18:35 UTC (permalink / raw)
To: linux-hotplug
Hey,
the underlying problem described below, is in no way specific to
systemd, it applies to all modern systems and services, existing ones,
or ones not even developed.
The udev systemd service files for udev do no longer pull-in the
barrier 'udevadm settle'. The udev coldplug run is executed fully
asynchronously in the background along with many other services, and
no other service will be blocked by default, waiting for udev to
populate /dev.
That means: non-hotplug-aware services are likely to break. Services
which assume a static /dev, rely on scanning /dev and finding "all"
devices at a certain point in time, are required to explicitly pull-in
udev-settle.service to paper-over their inability to cope with a
dynamic system. It will block the broken service until udev's coldplug
run has finished and /dev is populated with all devices known at that
time.
It's 2011 and services should cope with hotplug, devices coming and
going at any time, and a constantly changing and re-configuring
environment. No service which wants survive the next years of Linux
evolution should depend on the udev-settle.service barrier though,
please fix your stuff, or the reality might go on without you. :)
There is libudev, which connects your service to meaningful event for
news devices, device changes, and allows you to enumerate all
currently existing devices. Subscribing to events before enumeration
is started will make sure not to miss anything, and to propagate later
changes into the service.
All that even works from python, java, mono, javascript, ... programs,
so there is no excuse anymore to continue to do any of the
much-too-simple things we all did in the past. Just stop making
assumptions like: "booting has finished" or "all devices are there" --
that never really was in the past, and it will never be true in the
future.
Thanks,
Kay
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox