* Re: udevadm trigger --type=devices calling ifup on all devices, even devices with ONBOOT=no
From: Kay Sievers @ 2013-09-11 15:42 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <870142449.13579622.1378910415316.JavaMail.root@redhat.com>
On Wed, Sep 11, 2013 at 4:40 PM, Assaf Muller <amuller@redhat.com> wrote:
> When I run "/sbin/udevadm trigger --typeÞvices" on my RHEL 6.4 machine (udev-147-2.46.el6.x86_64),
> udevadm runs ifup on all of the network devices on my machine, including devices who have ONBOOT=no in their ifcfg files.
>
> Is this intended behavior?
This list is about upstream general kernel and userspace development
regarding device management.
You question is Red Hat Enterprise Linux network setup specific.
Please use the Red Hat Support for that, most people here have no idea
about distribution details.
Thanks,
Kay
^ permalink raw reply
* RE: loading 'acpiphp' fails after the sy =?utf-8?
From: Shiro Itou 伊東 @ 2013-09-11 17:46 UTC (permalink / raw)
To: gregkh@linuxfoundation.org
Cc: linux-hotplug@vger.kernel.org, linux-acpi@vger.kernel.org
In-Reply-To: <20130910155103.GB22628@kroah.com>
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+IERhdGU6IFR1ZSwgMTAg
U2VwIDIwMTMgMDg6NTE6MDMgLTA3MDAKPiBGcm9tOiBncmVna2hAbGludXhmb3VuZGF0aW9uLm9y
Zwo+IFRvOiBzaGlyby5pdG91QG91dGxvb2suY29tCj4gQ0M6IGxpbnV4LWhvdHBsdWdAdmdlci5r
ZXJuZWwub3JnOyBsaW51eC1hY3BpQHZnZXIua2VybmVsLm9yZwo+IFN1YmplY3Q6IFJlOiBsb2Fk
aW5nICdhY3BpcGhwJyBmYWlscyBhZnRlciB0aGUgc3lzdGVtIGJvb3Q/4oCPCj4KPiBPbiBUdWUs
IFNlcCAxMCwgMjAxMyBhdCAwODo0MzowNUFNIC0wNzAwLCBTaGlybyBJdG91IOS8iuadsSB3cm90
ZToKPj4gSGkgQWxsLAo+Pgo+PiBJbiBrZXJuZWwgdmVyc2lvbiAzLjAsIHdoZW4g4oCYYXBjaXBo
cOKAmSBkcml2ZXIgbW9kdWxlIGlzIGxvYWRlZCwgYWZ0ZXIKPj4gdGhlIHN5c3RlbSBjb21lcyB1
cCwgaXQgZmFpbHMgd2l0aCBlcnJvciDigJxubyBzdWNoIGRldmljZeKAnS4gV2hlbiBJCj4+IHRy
aWVkIHRvIGRlYnVnIEkgc2VlIHRoYXQgaXQgZmFpbHMgaW4gYWNwaXBocF9nZXRfbnVtX3Nsb3Rz
ICgpCj4+IGZ1bmN0aW9uIHdpdGggZXJyb3IgIlRvdGFsIDAgc2xvdHMiLiBJbiB0aGlzIGNhc2Ug
4oCYYnJpZGdlX2xpc3TigJkgc2VlbQo+PiB0byBiZSBOVUxMLgo+PiBCdXQgd2hlbiB0aGUg4oCY
YWNwaXBocOKAmSBpcyBsb2FkZWQgZHVyaW5nIGJvb3QgdGltZSwgaXQgc2VlbXMgdG8gd29yayBm
aWxlLgo+Cj4gV2hhdCBoYXBwZW5zIGluIHRoZSAzLjExIGtlcm5lbCByZWxlYXNlPyBMb3RzIG9m
IHdvcmsgaGFzIGJlZW4gZG9uZSBpbgo+IHRoaXMgYXJlYSBpbiB0aGUgcGFzdCAyIHllYXJzLCBw
bGVhc2UgdHJ5IGEgbmV3ZXIga2VybmVsLiBJZiB0aGVyZSBhcmUKPiBzdGlsbCBwcm9ibGVtcywg
cGxlYXNlIGxldCB0aGUgbGludXgtcGNpQHZnZXIua2VybmVsLm9yZyBtYWlsaW5nIGxpc3QKPiBr
bm93IGFib3V0IGl0LgoKVGhhbmsgeW91IGZvciByZXBseS4gSSBkaWQgbm90IHRyeSAzLjExIGtl
cm5lbC4gSSB3aWxsIGNoZWNrIDMuMTEga2VybmVsIGFuZCBzZWUuIEJ1dCBJIHVzZSAzLjAga2Vy
bmVsIGFzIGEgcmVxdWlyZW1lbnQuCgpUaGFuayBZb3UsClNoaXJvCgo+Cj4gdGhhbmtzLAo+Cj4g
Z3JlZyBrLWgKPiAtLQo+IFRvIHVuc3Vic2NyaWJlIGZyb20gdGhpcyBsaXN0OiBzZW5kIHRoZSBs
aW5lICJ1bnN1YnNjcmliZSBsaW51eC1ob3RwbHVnIiBpbgo+IHRoZSBib2R5IG9mIGEgbWVzc2Fn
ZSB0byBtYWpvcmRvbW9Admdlci5rZXJuZWwub3JnCj4gTW9yZSBtYWpvcmRvbW8gaW5mbyBhdCBo
dHRwOi8vdmdlci5rZXJuZWwub3JnL21ham9yZG9tby1pbmZvLmh0bWwgCQkgCSAgIAkJICA
^ permalink raw reply
* Re: loading 'acpiphp' fails after the system boot?
From: gregkh @ 2013-09-11 17:58 UTC (permalink / raw)
To: Shiro Itou 伊東
Cc: linux-hotplug@vger.kernel.org, linux-acpi@vger.kernel.org
In-Reply-To: <SNT149-W11D153D65E31824ED6AE2E9A390@phx.gbl>
On Wed, Sep 11, 2013 at 10:46:19AM -0700, Shiro Itou 伊東 wrote:
> ----------------------------------------
> > Date: Tue, 10 Sep 2013 08:51:03 -0700
> > From: gregkh@linuxfoundation.org
> > To: shiro.itou@outlook.com
> > CC: linux-hotplug@vger.kernel.org; linux-acpi@vger.kernel.org
> > Subject: Re: loading 'acpiphp' fails after the system boot?
> >
> > On Tue, Sep 10, 2013 at 08:43:05AM -0700, Shiro Itou 伊東 wrote:
> >> Hi All,
> >>
> >> In kernel version 3.0, when ‘apciphp’ driver module is loaded, after
> >> the system comes up, it fails with error “no such device”. When I
> >> tried to debug I see that it fails in acpiphp_get_num_slots ()
> >> function with error "Total 0 slots". In this case ‘bridge_list’ seem
> >> to be NULL.
> >> But when the ‘acpiphp’ is loaded during boot time, it seems to work file.
> >
> > What happens in the 3.11 kernel release? Lots of work has been done in
> > this area in the past 2 years, please try a newer kernel. If there are
> > still problems, please let the linux-pci@vger.kernel.org mailing list
> > know about it.
>
> Thank you for reply. I did not try 3.11 kernel. I will check 3.11
> kernel and see. But I use 3.0 kernel as a requirement.
Then please contact the people who is in charge of that requirement, as
they are the only ones that can support you, the community can not.
Best of luck,
greg k-h
^ permalink raw reply
* toshiba Satellite P75-A keymap
From: Guillermo Dominguez Duarte @ 2013-09-12 8:02 UTC (permalink / raw)
To: linux-hotplug
Hi
I installed Fedora 19 on my new laptop and was able to configure some
function keys following the instructions
in /usr/share/doc/systemd/README.keymap.txt
Here is the information of the computer:
cat /sys/class/dmi/id/sys_vendor TOSHIBA
cat /sys/class/dmi/id/product_name Satellite P75-A
0xEF brightnessdown # Fn+F2 Brightness down
0xEE brightnessup # Fn+F3 Brightness up
0xA9 switchvideomode # Fn+F4 Switch display outputs, for some reason
it sets 0 brightness when only main display is selected
0xD4 wlan # turn wireless adaptor on/off
I don't know if it matters, but I have to boot using grub commands:
acpi_osi=Linux acpi_backlight=vendor
^ permalink raw reply
* Re: toshiba Satellite P75-A keymap
From: Zbigniew Jędrzejewski-Szmek @ 2013-09-12 12:02 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <CAJ2vxsX0hGg31a1t-E766SX5wrpt4yF4vFjF7w-q9YO+WYZ6xw@mail.gmail.com>
On Thu, Sep 12, 2013 at 01:02:50AM -0700, Guillermo Dominguez Duarte wrote:
> Hi
>
> I installed Fedora 19 on my new laptop and was able to configure some
> function keys following the instructions
> in /usr/share/doc/systemd/README.keymap.txt
>
> Here is the information of the computer:
>
> cat /sys/class/dmi/id/sys_vendor TOSHIBA
> cat /sys/class/dmi/id/product_name Satellite P75-A
Applied to the systemd tree in http://cgit.freedesktop.org/systemd/systemd/commit/?id\x176cceb0.
Zbyszek
^ permalink raw reply
* pciehp & other hot-plug drivers (shpc etc..)
From: Rajat Jain @ 2013-09-29 18:27 UTC (permalink / raw)
To: linux-pci, linux-hotplug
Hello List,
Today all the PCI Hot-plug drivers (shpc, acpihp, cpqhp, ibmhp etc
except pciedhp) directly claim the downstream port bridge device.
Where as in case of pciehp, the PCIe port bus driver claims the bridge
device, and service drivers (aer, pm, pciehp) simply register for the
service with it.
1) Does that mean that in a system where I am using a driver other
than pciehp for hot-plug (eg. shpc), I cannot use service drivers like
AER or PM on the same port (since the device would be claimed by
shpc, it would not be available to port bus driver)?
2) In the same system, can I use SHPC on one port, and pciehp on
another port? I believe not?
Please note that it may not be a realistic scenarios, my intent of
asking is to just understand how things are intended to behave.
Thanks,
Rajat
^ permalink raw reply
* Re: pciehp & other hot-plug drivers (shpc etc..)
From: Greg KH @ 2013-09-30 2:05 UTC (permalink / raw)
To: Rajat Jain; +Cc: linux-pci, linux-hotplug
In-Reply-To: <CADTPrLTuzvj3iSMdNVs2BjDFHsWqjRPM4qDkkpmv+P11LMP0JQ@mail.gmail.com>
On Sun, Sep 29, 2013 at 11:27:23AM -0700, Rajat Jain wrote:
> Hello List,
>
> Today all the PCI Hot-plug drivers (shpc, acpihp, cpqhp, ibmhp etc
> except pciedhp) directly claim the downstream port bridge device.
> Where as in case of pciehp, the PCIe port bus driver claims the bridge
> device, and service drivers (aer, pm, pciehp) simply register for the
> service with it.
>
> 1) Does that mean that in a system where I am using a driver other
> than pciehp for hot-plug (eg. shpc), I cannot use service drivers like
> AER or PM on the same port (since the device would be claimed by
> shpc, it would not be available to port bus driver)?
It depends on your system, and you BIOS, which sets up all of this
stuff. It's up to the kernel to bind to the proper things it exposes.
> 2) In the same system, can I use SHPC on one port, and pciehp on
> another port? I believe not?
Yes you can, but such a system seems really strange, do you know of any
that require it?
> Please note that it may not be a realistic scenarios, my intent of
> asking is to just understand how things are intended to behave.
Again, it depends on your BIOS / hardware. They are the ones that
determine which driver handles this type of thing.
Hope this helps,
greg k-h
^ permalink raw reply
* Forking pciehp
From: Shiro Itou 伊東 @ 2013-10-03 7:24 UTC (permalink / raw)
To: linux-hotplug
SGkgQWxsLAoKCldlIG1ha2Ugc29tZSBwcm9kdWN0IHNwZWNpZmljIGNoYW5nZSB0byAicGNpZWhw
IiBhbmQgd2FudCB0byBnaXZlIG1vZGlmaWVkICJwY2llaHAiIHdpdGggb3VyIHByb2R1Y3QgdG8g
Y3VzdG9tZXIuIEkgcmVhZCBHUEwgYW5kIEkgc2VlIHRoYXQgd2UgaGF2ZSB0byBhZGQgY2hhbmdl
IGxvZyBpbiBsaWNlbnNlIGhlYWRlci4KClNob3VsZCB3ZSBvciBjYW4gd2UgY2hhbmdlIG1vZHVs
ZSBhdXRob3IgdG8gb3VyIGNvbXBhbnkgbmFtZT8gTm93IEkgc2VlIG1hbnkgYXV0aG9ycywgR3Jl
ZywgSUJNLCBJbnRlbCBldGMuIGluIHBjaWVocCBjb2RlLiBPciB3ZSBoYXZlIHRvIGFkZCBvdXIg
Y29tcGFueSB3aXRoIG90aGVyIG5hbWVzPwoKQ2FuIHdlIGNoYW5nZSBkcml2ZXIgdmVyc2lvbj8K
CklzIGNvZGUgaGFzIHRvIGJlIG9wZW5zb3VyY2U/IElmIHllcywgdGhlbiB3aGVyZSB0byBrZWVw
IHRoZSBzb3VyY2UgY29kZT8gSXMgb3VyIGNvbXBhbnkgd2Vic2l0ZSBvayBvciBwdWJsaWMgc291
cmNlIHdlYnNpdGU/CgoKSSB0cmllZCB0byBnZXQgaW5mb3JtYXRpb24gb3RoZXIgcGxhY2UgYWJv
dXQgR1BMIGJ1dCBub3QgZ2V0IHdhbnRlZCBpbmZvcm1hdGlvbi4gU29ycnkgaWYgaXQgaXMgbm90
IGNvcnJlY3QgbWFpbCBsaXN0LgoKUGxlYXNlIGhlbHAuCgoKVGhhbmtzLApTaGlybyAJCSAJICAg
CQkgIA=
^ permalink raw reply
* Re: Forking pciehp
From: gregkh @ 2013-10-03 13:23 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <SNT149-W11A0AD93792AA76B54826E9A170@phx.gbl>
On Thu, Oct 03, 2013 at 12:24:48AM -0700, Shiro Itou 伊東 wrote:
> Hi All,
>
>
> We make some product specific change to "pciehp" and want to give
> modified "pciehp" with our product to customer. I read GPL and I see
> that we have to add change log in license header.
Who is "we"?
And secondly, for all legal questions, please consult a lawyer for your
company, they are the best to answer these questions, not random
developers on a public mailing list.
And no, the GPL does not say you have to add a changelog to the license
header.
> Should we or can we change module author to our company name? Now I
> see many authors, Greg, IBM, Intel etc. in pciehp code. Or we have to
> add our company with other names?
No, no need to change the author, just know about the copyrights of the
other companies and authors and deal with it properly as per copyright
law.
> Can we change driver version?
What did you change? Why not just post your change as a patch and get
it accepted upstream properly for everyone to then use?
Please read the kernel files, Documentation/SubmittingPatches and
Documentation/development-model/ for how kernel development works.
> Is code has to be opensource?
Yes of course, you can not change the license of the file, or the Linux
kernel, why would you think otherwise?
> If yes, then where to keep the source code? Is our company website ok
> or public source website?
That is up to you.
> I tried to get information other place about GPL but not get wanted
> information.
Where did you look, there is lots of public information out there.
But again, you should always ask lawyers about legal things, not
programmers.
Hope this helps,
greg k-h
^ permalink raw reply
* Re: pciehp & other hot-plug drivers (shpc etc..)
From: Rajat Jain @ 2013-10-04 1:08 UTC (permalink / raw)
To: Greg KH; +Cc: linux-pci, linux-hotplug, tom.l.nguyen, yanmin.zhang
In-Reply-To: <20130930020500.GB28774@kroah.com>
Hello,
On Sun, Sep 29, 2013 at 7:05 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
> On Sun, Sep 29, 2013 at 11:27:23AM -0700, Rajat Jain wrote:
>> Hello List,
>>
>> Today all the PCI Hot-plug drivers (shpc, acpihp, cpqhp, ibmhp etc
>> except pciedhp) directly claim the downstream port bridge device.
>> Where as in case of pciehp, the PCIe port bus driver claims the bridge
>> device, and service drivers (aer, pm, pciehp) simply register for the
>> service with it.
>>
>> 1) Does that mean that in a system where I am using a driver other
>> than pciehp for hot-plug (eg. shpc), I cannot use service drivers like
>> AER or PM on the same port (since the device would be claimed by
>> shpc, it would not be available to port bus driver)?
>
> It depends on your system, and you BIOS, which sets up all of this
> stuff. It's up to the kernel to bind to the proper things it exposes.
Actually, I just wanted to understand that on a machine where
shpchp.ko is to be used for hot-plug, can I still use the AER port bus
service driver? My understanding is NO, because shpc will claim the
downstream port bridge, and hence port bus driver will not be able to
claim it?
>
>> 2) In the same system, can I use SHPC on one port, and pciehp on
>> another port? I believe not?
>
> Yes you can, but such a system seems really strange, do you know of any
> that require it?
>
>> Please note that it may not be a realistic scenarios, my intent of
>> asking is to just understand how things are intended to behave.
>
> Again, it depends on your BIOS / hardware. They are the ones that
> determine which driver handles this type of thing.
>
> Hope this helps,
>
> greg k-h
^ permalink raw reply
* [PCIe spec question] How to get PCI express link up / link down notifications?
From: Rajat Jain @ 2013-10-04 1:40 UTC (permalink / raw)
To: linux-pci@vger.kernel.org, linux-hotplug@vger.kernel.org
Cc: Guenter Roeck, kernelnewbies@kernelnewbies.org,
linux-newbie@vger.kernel.org
Hello,
I have a HW which is not compliant with the PCI Express hot-plug (as described in the PCI express spec) because the HP signals from the downstream port are simply not connected. And I have a PCI express endpoint, that in the course of its life, will routinely undergo power-off and power-on on cycles. Hence the PCIe link to this device is expected to come down, and come up as part of regular operation.
I'm reading the PCI express spec trying to understand if it is possible to get notification interrupts, whenever the PCIe link to this device goes down or goes up. Can someone please help me understand if it is possible?
In the link control register, I only see the capability to generate interrupts when "link bandwidth" changes and looking at the text, I doubt if Link down or link up counts as "link bandwidth change". Is there a way to generate and interrupt / notification when the Link goes up or down?
Thanks,
Rajat Jain
^ permalink raw reply
* Re: [PCIe spec question] How to get PCI express link up / link down notifications?
From: Greg KH @ 2013-10-04 2:36 UTC (permalink / raw)
To: Rajat Jain
Cc: linux-pci@vger.kernel.org, linux-hotplug@vger.kernel.org,
Guenter Roeck, kernelnewbies@kernelnewbies.org,
linux-newbie@vger.kernel.org
In-Reply-To: <1fa2fecbcbe147cc83a3011ff23e3d1a@BN1PR05MB123.namprd05.prod.outlook.com>
On Fri, Oct 04, 2013 at 01:40:49AM +0000, Rajat Jain wrote:
> Hello,
>
> I have a HW which is not compliant with the PCI Express hot-plug (as
> described in the PCI express spec) because the HP signals from the
> downstream port are simply not connected. And I have a PCI express
> endpoint, that in the course of its life, will routinely undergo
> power-off and power-on on cycles. Hence the PCIe link to this device
> is expected to come down, and come up as part of regular operation.
What hardware is this? Why not ask the manufacturer of it as they are
the ones in control of this type of thing.
> I'm reading the PCI express spec trying to understand if it is
> possible to get notification interrupts, whenever the PCIe link to
> this device goes down or goes up. Can someone please help me
> understand if it is possible?
Notification where?
thanks,
greg k-h
^ permalink raw reply
* RE: [PCIe spec question] How to get PCI express link up / link down notifications?
From: Rajat Jain @ 2013-10-04 3:31 UTC (permalink / raw)
To: Greg KH
Cc: linux-pci@vger.kernel.org, linux-hotplug@vger.kernel.org,
Guenter Roeck, kernelnewbies@kernelnewbies.org,
linux-newbie@vger.kernel.org
In-Reply-To: <20131004023639.GA3417@kroah.com>
Hello Greg,
>
> On Fri, Oct 04, 2013 at 01:40:49AM +0000, Rajat Jain wrote:
> > Hello,
> >
> > I have a HW which is not compliant with the PCI Express hot-plug (as
> > described in the PCI express spec) because the HP signals from the
> > downstream port are simply not connected. And I have a PCI express
> > endpoint, that in the course of its life, will routinely undergo
> > power-off and power-on on cycles. Hence the PCIe link to this device
> > is expected to come down, and come up as part of regular operation.
>
> What hardware is this? Why not ask the manufacturer of it as they are
> the ones in control of this type of thing.
OK, Understood :-).
Actually my question was generic. For e.g. say I have a topology where root port connects to a PCIe switch-1 that in turn connects to a PCIe switch-2. My question is if the PCIe link between the switch-1 and switch-2 goes down or up for some reason (say a power fault, or due to RESET pin assertion on the switch etc), is there a way to get notification interrupt at the root port or CPU? Essentially I am looking for a notification from downstream port of switch-1, that it saw a change in the link status.
>
> > I'm reading the PCI express spec trying to understand if it is
> > possible to get notification interrupts, whenever the PCIe link to
> > this device goes down or goes up. Can someone please help me
> > understand if it is possible?
>
> Notification where?
Notification to the CPU via the root port.
Thanks a bunch,
Rajat
>
> thanks,
>
> greg k-h
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" 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: [PCIe spec question] How to get PCI express link up / link down notifications?
From: Rajat Jain @ 2013-10-04 6:48 UTC (permalink / raw)
To: Rajat Jain, Greg KH
Cc: linux-pci@vger.kernel.org, linux-hotplug@vger.kernel.org,
Guenter Roeck, kernelnewbies@kernelnewbies.org,
linux-newbie@vger.kernel.org
In-Reply-To: <20131004023639.GA3417@kroah.com>
Hi,
I found the answer to my original question. I found the "Data Link Layer State Changed Enable" bit in the Slot Control register which seems to provide interrupt on link state changes.
6.7.3.3. Data Link Layer State Changed Events
=======================
The Data Link Layer State Changed event provides an indication that the state of the Data Link Layer Link Active bit in the Link Status register has changed. Support for Data Link Layer State Changed events and software notification of these events are required for hot-plug capable Downstream Ports. If this event is supported, the Port sets the status field associated with the event
5 when the value in the Data Link Layer Link Active bit changes.
Thanks a bunch!
Rajat
^ permalink raw reply
* Re: pciehp & other hot-plug drivers (shpc etc..)
From: Bjorn Helgaas @ 2013-10-04 23:01 UTC (permalink / raw)
To: Rajat Jain; +Cc: Greg KH, linux-pci, linux-hotplug, tom.l.nguyen, yanmin.zhang
In-Reply-To: <CADTPrLSpfnY6Z1MgpR=C4SRH7yXJ2BKi3w5ChLpTuWL3zZWx_Q@mail.gmail.com>
On Thu, Oct 03, 2013 at 06:08:15PM -0700, Rajat Jain wrote:
> Hello,
>
> On Sun, Sep 29, 2013 at 7:05 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
> > On Sun, Sep 29, 2013 at 11:27:23AM -0700, Rajat Jain wrote:
> >> Hello List,
> >>
> >> Today all the PCI Hot-plug drivers (shpc, acpihp, cpqhp, ibmhp etc
> >> except pciedhp) directly claim the downstream port bridge device.
> >> Where as in case of pciehp, the PCIe port bus driver claims the bridge
> >> device, and service drivers (aer, pm, pciehp) simply register for the
> >> service with it.
> >>
> >> 1) Does that mean that in a system where I am using a driver other
> >> than pciehp for hot-plug (eg. shpc), I cannot use service drivers like
> >> AER or PM on the same port (since the device would be claimed by
> >> shpc, it would not be available to port bus driver)?
> >
> > It depends on your system, and you BIOS, which sets up all of this
> > stuff. It's up to the kernel to bind to the proper things it exposes.
>
> Actually, I just wanted to understand that on a machine where
> shpchp.ko is to be used for hot-plug, can I still use the AER port bus
> service driver? My understanding is NO, because shpc will claim the
> downstream port bridge, and hence port bus driver will not be able to
> claim it?
I think you are correct, at least in principle. Both pcie_portdriver
and shpc_driver try to claim all PCI bridge devices. pcie_portdrv_probe()
succeeds only for PCIe Root Ports, Upstream Ports, and Downstream Ports.
shpc_probe() succeeds only for bridges with the SHPC capability. If
one of them does claim the bridge, the driver core should not call the
other probe method.
So if you have a PCIe Root Port or switch port that has the SHPC
capability, either pcie_portdrv_probe() or shpc_probe() will fail,
depending on which was called first.
I've never seen such a device, so I don't know whether this is a
problem in practice.
Bjorn
^ permalink raw reply
* udev and w1/wire
From: Max Hille @ 2013-10-05 10:21 UTC (permalink / raw)
To: linux-hotplug
I want to use a 1-wire slave device from user space.
My first approach is to get a symlink like /dev/wire-slave with user
read/write permissions. I have tried this with udev rules but didn't
get it to work so far.
Some additional information about the wire kernel module:
Module name: wire (available in stock Ubuntu 13,04)
Subsystem: w1
creates the following in /sys/:
devices/w1_bus_master1/81-XXXXXXXXXXXX/
where the 81 is a slave device specific identifier. Inside that
directory is a file(?) named "rw" which I can (successfully) use to
communicate with the onewire device.
I have already managed to write a udev rule which sets the permissions
on this "rw" so I can use it from user space. But then I have my
program to search through /sys/ to access the device which does not
seems to be the right way (eg. did not work on my friends Linux Mint).
If it is not possible to create a device node in /dev, I'd be thankful
for alternative solutions.
-- Max
^ permalink raw reply
* Re: udev and w1/wire
From: Greg KH @ 2013-10-05 13:19 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <CAM1NiQpN0AjZmWKLWw-45BR71_Pi9JiuCoA4yKfzs5jHda=CyA@mail.gmail.com>
On Sat, Oct 05, 2013 at 12:21:52PM +0200, Max Hille wrote:
> I want to use a 1-wire slave device from user space.
>
> My first approach is to get a symlink like /dev/wire-slave with user
> read/write permissions. I have tried this with udev rules but didn't
> get it to work so far.
>
> Some additional information about the wire kernel module:
> Module name: wire (available in stock Ubuntu 13,04)
> Subsystem: w1
> creates the following in /sys/:
> devices/w1_bus_master1/81-XXXXXXXXXXXX/
> where the 81 is a slave device specific identifier. Inside that
> directory is a file(?) named "rw" which I can (successfully) use to
> communicate with the onewire device.
>
> I have already managed to write a udev rule which sets the permissions
> on this "rw" so I can use it from user space. But then I have my
> program to search through /sys/ to access the device which does not
> seems to be the right way (eg. did not work on my friends Linux Mint).
>
> If it is not possible to create a device node in /dev, I'd be thankful
> for alternative solutions.
Just use the sysfs file, this driver does not use any device node it
seems, so no need to try to create one that doesn't exist.
Also, the w1 interface is usually through the "connector" subsystem,
which is a network protocol, not a device node. What is wrong with
using that?
greg k-h
^ permalink raw reply
* Enhancing pciehp (was: pcielw An alternate pcie hotplug driver)
From: Rajat Jain @ 2013-10-07 18:58 UTC (permalink / raw)
To: ebiederm@xmission.com, Bjorn Helgaas, linux-pci@vger.kernel.org,
linux-hotplug@vger.kernel.org
Cc: Greg KH, Guenter Roeck, tom.l.nguyen@intel.com,
kristen.c.accardi@intel.com, rajesh.shah@intel.com,
rajatjain.linux@gmail.com
Hello Bjorn / Eric / Folks,
This is to seek suggestions about a problem I'm trying to solve.
The problem
=====1) My company makes routers that have hot-pluggable cards with PCI express interfaces on them. We need to be able to hot-plug those cards, however the cards or the slots do not have the fancy bells & whistles (hot plug elements like MRL, sensor, attention button etc), and hence the hot-plug signals from the PCIe switch aren't really connected.
2) In addition to the above, we have onboard ASICs that are reachable via the PCIe. However, as part of regular operation of a router (e.g. user wants to switch off some ports), the ASICs can be off-lined / on-lined via out-of-band HW pins. The result is that we could see the PCIe link go down or up to that ASIC. This can be thought of as a "virtual" hot-plug of ASIC devices. Since the ASICs are themselves on the board, there is really no slot, and the HP signals again do not make much sense in this case.
What I found
======What I was looking for, was a way to hot-plug and un-plug based on link state changes (since that is pretty much what is available in my case). And I found this:
http://www.spinics.net/lists/linux-pci/msg05783.html
http://www.spinics.net/lists/linux-pci/msg05880.html
My questions
======
a) I was wanting to know if what is the latest on this, or if any progress was made on this? If useful, I am willing to volunteer to work on this. Do you think there is interest in getting this to work? I feel there may be many such systems that are in the same situation.
b) If I wanted to make use of Eric's patch in a way that is useful to the community, what is the best way to move forward? Do you still want to enhance the pciehp to include this functionality? Or a separate service driver (what Eric already has) seems a better idea? I'd appreciate if you could please provide any guidance here.
TIA,
Rajat
^ permalink raw reply
* Re: Enhancing pciehp (was: pcielw An alternate pcie hotplug driver)
From: Bjorn Helgaas @ 2013-10-07 20:31 UTC (permalink / raw)
To: Rajat Jain
Cc: ebiederm@xmission.com, linux-pci@vger.kernel.org,
linux-hotplug@vger.kernel.org, Greg KH, Guenter Roeck,
tom.l.nguyen@intel.com, kristen.c.accardi@intel.com,
rajesh.shah@intel.com, rajatjain.linux@gmail.com
In-Reply-To: <b13ea983a4154c7d9567b171e8316ca9@BLUPR05MB118.namprd05.prod.outlook.com>
On Mon, Oct 7, 2013 at 12:58 PM, Rajat Jain <rajatjain@juniper.net> wrote:
> Hello Bjorn / Eric / Folks,
>
> This is to seek suggestions about a problem I'm trying to solve.
>
> The problem
> =====> 1) My company makes routers that have hot-pluggable cards with PCI express interfaces on them. We need to be able to hot-plug those cards, however the cards or the slots do not have the fancy bells & whistles (hot plug elements like MRL, sensor, attention button etc), and hence the hot-plug signals from the PCIe switch aren't really connected.
The elements you mention are optional per the spec (PCIe r3.0, sec
6.7.1). The lack of them, by itself, should not be enough to force
you to write a new hotplug driver. pciehp is used for ExpressCard
hotplug, and that's a similar situation where there's no MRL, no MRL
sensor, no interlock, no attention button, etc.
What connects the hot-pluggable card to the system? PCI? PCIe?
Something else? If it's PCIe, it seems like you'd make your life
simpler by taking advantage of some or all of the hotplug support that
is likely in the PCIe Root Port or Downstream Port leading to the
slot.
> 2) In addition to the above, we have onboard ASICs that are reachable via the PCIe. However, as part of regular operation of a router (e.g. user wants to switch off some ports), the ASICs can be off-lined / on-lined via out-of-band HW pins. The result is that we could see the PCIe link go down or up to that ASIC. This can be thought of as a "virtual" hot-plug of ASIC devices. Since the ASICs are themselves on the board, there is really no slot, and the HP signals again do not make much sense in this case.
It doesn't really matter that there's no physical slot and the user
can't replace an ASIC with a different one. You can still use the
hotplug signals that *are* relevant, e.g., it sounds like things
related to Hot-Plug Surprise, Presence Detect, and Data Link Layer
State would still make sense.
The current pciehp driver doesn't really do anything with the Data
Link Layer State Changed Enable bit (it looks like we *disable* that
notification, but never *enable* it). It sounds like a reasonable
thing to add to pciehp, though.
Bjorn
^ permalink raw reply
* Re: Enhancing pciehp
From: Eric W. Biederman @ 2013-10-07 22:42 UTC (permalink / raw)
To: Rajat Jain
Cc: Bjorn Helgaas, linux-pci@vger.kernel.org,
linux-hotplug@vger.kernel.org, Greg KH, Guenter Roeck,
tom.l.nguyen@intel.com, kristen.c.accardi@intel.com,
rajesh.shah@intel.com, rajatjain.linux@gmail.com
In-Reply-To: <b13ea983a4154c7d9567b171e8316ca9@BLUPR05MB118.namprd05.prod.outlook.com>
Rajat Jain <rajatjain@juniper.net> writes:
> Hello Bjorn / Eric / Folks,
>
> This is to seek suggestions about a problem I'm trying to solve.
>
> The problem
> =====> 1) My company makes routers that have hot-pluggable cards with PCI express interfaces on them. We need to be able to hot-plug those cards, however the cards or the slots do not have the fancy bells & whistles (hot plug elements like MRL, sensor, attention button etc), and hence the hot-plug signals from the PCIe switch aren't really connected.
>
> 2) In addition to the above, we have onboard ASICs that are reachable via the PCIe. However, as part of regular operation of a router (e.g. user wants to switch off some ports), the ASICs can be off-lined / on-lined via out-of-band HW pins. The result is that we could see the PCIe link go down or up to that ASIC. This can be thought of as a "virtual" hot-plug of ASIC devices. Since the ASICs are themselves on the board, there is really no slot, and the HP signals again do not make much sense in this case.
>
> What I found
> ======> What I was looking for, was a way to hot-plug and un-plug based on link state changes (since that is pretty much what is available in my case). And I found this:
> http://www.spinics.net/lists/linux-pci/msg05783.html
> http://www.spinics.net/lists/linux-pci/msg05880.html
>
> My questions
> ======
> a) I was wanting to know if what is the latest on this, or if any
> progress was made on this? If useful, I am willing to volunteer to
> work on this. Do you think there is interest in getting this to work?
> I feel there may be many such systems that are in the same situation.
Agreed. It appears this is a design that is likely to come up more than
once.
> b) If I wanted to make use of Eric's patch in a way that is useful to
> the community, what is the best way to move forward? Do you still want
> to enhance the pciehp to include this functionality? Or a separate
> service driver (what Eric already has) seems a better idea? I'd
> appreciate if you could please provide any guidance here.
Where I wound up was I unfortunately had not left time in my schedule to
completely rewrite what I had done and to merge that into pciehp.
I wrote pcielw simply because the pciehp driver did not and may still
not work with multiple layers of pci hotplug so I needed to do some deep
digging. Dealing with all of the cases of physical buttons when I did
not have those was prohibitive for my poor schedule.
I work somewhere else now and I don't have this problem so I will not be
looking at this problem again any time soon.
I do agree with Bjorn that one driver that can handle everything is
doable and ideal. So if you are willing to do that work it would be
great. pcielw should certainly work as a proof of concept solution to
any of the problems, and time permitting I am willing to answer
questions of the what was I thinking variety.
Eric
^ permalink raw reply
* Difference between hot-plug on PCIe rootport vs downstream port
From: Rajat Jain @ 2013-10-09 13:36 UTC (permalink / raw)
To: linux-pci@vger.kernel.org, linux-hotplug@vger.kernel.org
Hello,
1) Does the pciehp support hotplug on both rootport and downstream port?
2) What is so different about these that downstream port hotplug was part of the kernel since very long, but root port hotplug was included releatively recently? Are there any added complexities? I couldn't find anything on the net on this. From my understanding it should be exactly similar?
3) I understand the hotplug on downstream port is architecture independent. But is the root port hotplug architecture dependent (assuming that the CPU complies to the PCIe, spec, it shouldn't be, right)?
4) Can you point me to the code where the root port hotplug is implemented?
Thanks,
Rajat
^ permalink raw reply
* Re: Difference between hot-plug on PCIe rootport vs downstream port
From: Bjorn Helgaas @ 2013-10-09 14:50 UTC (permalink / raw)
To: Rajat Jain; +Cc: linux-pci@vger.kernel.org, linux-hotplug@vger.kernel.org
In-Reply-To: <43e5eb8dd8c04af197a01dc974f52924@BLUPR05MB118.namprd05.prod.outlook.com>
On Wed, Oct 9, 2013 at 7:36 AM, Rajat Jain <rajatjain@juniper.net> wrote:
> Hello,
>
> 1) Does the pciehp support hotplug on both rootport and downstream port?
Yes. To be precise, pciehp supports hotplug of PCIe devices below
Root Ports and Downstream Ports.
> 2) What is so different about these that downstream port hotplug was part of the kernel since very long, but root port hotplug was included releatively recently? Are there any added complexities? I couldn't find anything on the net on this. From my understanding it should be exactly similar?
Hotplugging of PCIe devices below Root Ports and Downstream Ports
should be identical.
My guess is that you're confused by the recent addition of PCI *host
bridge* hotplug. This is for hotplugging an entire Root Complex or
other host bridge. A host bridge is not a PCI or PCIe device (though
a Root Complex *contains* Root Ports). It has some platform-specific
interface on the upstream side and a PCI or PCIe interface on the
downstream side. There is no architected way to discover host bridge
existence, apertures, address translation, etc. This is all done via
ACPI or other platform-specific methods, not via PCI mechanisms.
Therefore, hotplug of a host bridge is much different than hotplug of
a PCI device.
> 3) I understand the hotplug on downstream port is architecture independent. But is the root port hotplug architecture dependent (assuming that the CPU complies to the PCIe, spec, it shouldn't be, right)?
The PCIe spec doesn't really apply to CPUs. The above should clarify the rest.
> 4) Can you point me to the code where the root port hotplug is implemented?
Host bridge hotplug is implemented in drivers/acpi/pci_root.c.
Obviously this only applies to arches that use ACPI (currently x86 and
ia64).
Bjorn
^ permalink raw reply
* RE: Difference between hot-plug on PCIe rootport vs downstream port
From: Rajat Jain @ 2013-10-09 17:42 UTC (permalink / raw)
To: Bjorn Helgaas; +Cc: linux-pci@vger.kernel.org, linux-hotplug@vger.kernel.org
In-Reply-To: <CAErSpo5W9=oFo5kEzWQPCj_OePuCtYU8w7RhVRfz9jH-O=XupQ@mail.gmail.com>
> >
> > 1) Does the pciehp support hotplug on both rootport and downstream
> port?
>
> Yes. To be precise, pciehp supports hotplug of PCIe devices below Root
> Ports and Downstream Ports.
>
> > 2) What is so different about these that downstream port hotplug was
> part of the kernel since very long, but root port hotplug was included
> releatively recently? Are there any added complexities? I couldn't find
> anything on the net on this. From my understanding it should be exactly
> similar?
>
> Hotplugging of PCIe devices below Root Ports and Downstream Ports
> should be identical.
Thanks a lot, I think you are right. I got confused between hot-plug of a device on root port, and hot-plug of the root port itself.
No I'm not bothered about the hot-plug of the host bridge itself. I was talking abouthot-plug of a device directly under the root port.
So I' assuming I should be good with pciehp then.
Thanks,
Rajat
^ permalink raw reply
* Fn Keys wrong function
From: Guillermo Dominguez Duarte @ 2013-10-09 23:32 UTC (permalink / raw)
To: linux-hotplug
Hi guys.
Is this the place to report that in my computer, Fn keys that are
suposed to bright up the screen and change the display output are now
making my computer sleep and hibernate respectively?
This dind't happen until one of the kernel updates. I am not sure which one
Thanks
^ permalink raw reply
* Re: Fn Keys wrong function
From: Martin Pitt @ 2013-10-10 4:05 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <CAJ2vxsXA7=VUQ_=KJgJivCW_96u7PDAzjK04g34Kp1azRejtnw@mail.gmail.com>
Hello Guillermo,
Guillermo Dominguez Duarte [2013-10-09 16:32 -0700]:
> Is this the place to report that in my computer, Fn keys that are
> suposed to bright up the screen and change the display output are now
> making my computer sleep and hibernate respectively?
It's a good enough place :) Please tell us which udev version you are
running, install the "evtest" tool, run it, press these two keys, and
copy & paste the whole output.
After that, please run
udevadm info --export-db > /tmp/udev.txt
and attach /tmp/udev.txt, too.
Thanks,
Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
^ 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