cy PCI driver - possible device id's

[Lakhan Shiva]

Hi All,

I am working on converting PCI drivers attachments to be table driven.
I have come across the cy (Cyclades Y PCI serial interface driver) -
/sys/dev/cy/cy_pci.c. There is no explicit vendor/device table in this.
However when we look at the probe function -

static int cy_pci_probe(dev)
> device_t dev;
> {
> u_int32_t device_id;
> device_id = pci_get_devid(dev);
> device_id &= ~0x00060000;
> if (device_id != 0x0100120e && device_id != 0x0101120e)
> return (ENXIO);
> device_set_desc(dev, "Cyclades Cyclom-Y Serial Adapter");
> return (BUS_PROBE_DEFAULT);
> }
>

It makes it evident that it is possible to have the following as the device
id's for this Cyclades Cyclom-Y serial Adapter:

> 0x0100120e
> 0x0102120e
> 0x0104120e
> 0x0106120e
>
> 0x0101120e
> 0x0103120e
> 0x0105120e
> 0x0107120e
>

Can i conclude this or am i missing something here ? Not 100% sure if these
are all valid device id's but Math says that these are the possible
options. Which all from these could be a practical device id ?
As you may infer, i am trying to construct a device id table for the
Cyclades PCI driver.
Useful Ref: https://www.freebsd.org/cgi/man.cgi?query=cy&sektion=4
Thanks,
Lakhan
_______________________________________________
freebsd...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hacke...@freebsd.org"

[Poul-Henning Kamp]

--------

In message <CAHC0YgfPmPmOQVmHD_uY8d7q...@mail.gmail.com>, Lakhan Shiva writes:

>I am working on converting PCI drivers attachments to be table driven.

Can we please invent some kind of "typographic" convention which
allows these tables to be extracted from the kernel source code,
so that we can have an utility which suggests which drivers to
load, by consulting such an extracted table ?

--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

[Lakhan Shiva]

At present we have devmatch infrastructure, which looks at all unattached
devices on the system and compares their plug and play data to that which
has been recorded by kldxref in linker hints and suggests modules to load.

Now, this work is to support this project achieve this in the case of PCI
drivers.

Ref: https://wiki.freebsd.org/AutoLoad

Thanks,
Lakhan

On Jun 5, 2018 11:49 PM, "Poul-Henning Kamp" <p...@phk.freebsd.dk> wrote:

--------
In message <CAHC0YgfPmPmOQVmHD_uY8d7q...@mail.gmail.

[Warner Losh]

On Tue, Jun 5, 2018, 2:22 PM Poul-Henning Kamp <p...@phk.freebsd.dk> wrote:

> --------
> In message <
> CAHC0YgfPmPmOQVmHD_uY8d7q...@mail.gmail.com>,
> Lakhan Shiva writes:
>
> >I am working on converting PCI drivers attachments to be table driven.
>
> Can we please invent some kind of "typographic" convention which
> allows these tables to be extracted from the kernel source code,
> so that we can have an utility which suggests which drivers to
> load, by consulting such an extracted table ?
>

That's exactly what Lakhan is working on. We have the utility (devmatch),
just need to mark the drivers.

Warner

[Poul-Henning Kamp]

--------
In message <CAG6CVpXKGrN_Ee2tBwyLDNgL...@mail.gmail.com>, Conrad Meyer writes:

>We already have exactly this =E2=80=94 a precise convention
>("MODULE_PNP_INFO") and tool ("kldxref" for extracting the data, and
>"devmatch" for suggesting matches), initiated by Warner. This work
>has been ongoing, in stops and starts, for years. Lakhan is
>converting non-compliant drivers to the convention.

Yes, and that's good and great, but it only works if you have
the modules installed on the machine to examine.

For scenarios like NanoBSD it would be nice if devmatch had a
built-in "fall-back" table (created at compile time) to suggest
modules not present in the local filesystem.

[Conrad Meyer]

We already have exactly this — a precise convention

("MODULE_PNP_INFO") and tool ("kldxref" for extracting the data, and
"devmatch" for suggesting matches), initiated by Warner. This work
has been ongoing, in stops and starts, for years. Lakhan is
converting non-compliant drivers to the convention.

Conrad

[Warner Losh]

On Tue, Jun 5, 2018, 4:57 PM Poul-Henning Kamp <p...@phk.freebsd.dk> wrote:

> --------
> In message <
> CAG6CVpXKGrN_Ee2tBwyLDNgL...@mail.gmail.com>,
> Conrad Meyer writes:
>
> >We already have exactly this =E2=80=94 a precise convention
> >("MODULE_PNP_INFO") and tool ("kldxref" for extracting the data, and
> >"devmatch" for suggesting matches), initiated by Warner. This work
> >has been ongoing, in stops and starts, for years. Lakhan is
> >converting non-compliant drivers to the convention.
>
> Yes, and that's good and great, but it only works if you have
> the modules installed on the machine to examine.
>
> For scenarios like NanoBSD it would be nice if devmatch had a
> built-in "fall-back" table (created at compile time) to suggest
> modules not present in the local filesystem.
>

Devmatch can operate on an arbitrary loader.hints file. Just do a GENERIC
buildkernel, install it somewhere. Loader.hints gets created. Copy that
file to the target system and run devmatch...

Warner

[Poul-Henning Kamp]

--------

In message <CANCZdfqn6EMPdF5xEdfvh23Y...@mail.gmail.com>, Warner Losh writes:

>Devmatch can operate on an arbitrary loader.hints file. Just do a GENERIC
>buildkernel, install it somewhere. Loader.hints gets created. Copy that
>file to the target system and run devmatch...

Ahh, that was the bit I was missing...

Cool and Thanks a LOT for doing this.

[Slawa Olhovchenkov]

On Tue, Jun 05, 2018 at 06:19:35PM +0000, Poul-Henning Kamp wrote:

> --------
> In message <CAHC0YgfPmPmOQVmHD_uY8d7q...@mail.gmail.com>, Lakhan Shiva writes:
>
> >I am working on converting PCI drivers attachments to be table driven.
>
> Can we please invent some kind of "typographic" convention which
> allows these tables to be extracted from the kernel source code,
> so that we can have an utility which suggests which drivers to
> load, by consulting such an extracted table ?

... and from /boot/loader too?..

[Warner Losh]

On Thu, Jun 7, 2018, 8:23 AM Slawa Olhovchenkov <s...@zxy.spb.ru> wrote:

> On Tue, Jun 05, 2018 at 06:19:35PM +0000, Poul-Henning Kamp wrote:
>
> > --------
> > In message <
> CAHC0YgfPmPmOQVmHD_uY8d7q...@mail.gmail.com>,
> Lakhan Shiva writes:
> >
> > >I am working on converting PCI drivers attachments to be table driven.
> >
> > Can we please invent some kind of "typographic" convention which
> > allows these tables to be extracted from the kernel source code,
> > so that we can have an utility which suggests which drivers to
> > load, by consulting such an extracted table ?
>
> ... and from /boot/loader
>

Yes.

Warner