Patch to allow dynamic USB quirks at boot

[Mehmet Erol Sanliturk]

On Wed, Sep 23, 2015 at 9:26 AM, Warner Losh <imp at bsdimp.com> wrote:

> Nearly all the PCI drivers have tables of vendor/device IDs.
> They all have slightly different forms, and none of them use
> a common macro / format like USB. So each driver needs a
> line or two to describe the table so we can extract the data
> from the .ko. Some drivers don't have lists, and those will
> need to be dealt with on a case-by-case basis.
>
> I also have another set of work to do PNP translations at run
> time. The bus will lie about the PNP IDs of the device so that
> drivers can treat new hardware just like old hardware. The obvious
> (and wrong) approach of forcing drivers to "take" devices only
> works for the most trivial drivers as nearly all of them have a
> table that tells about the "quirks" of the hardware since not
> all of that can be determined from registers alone.
>
> Warner
>
>

All over the world , almost all of the products have a "Bar Code"
identifier , which approximately may be considered "Unique" .


Is there a possibility to associate PCI and USB and other devices with
their bar code identifiers  ?


For computers assembled already , it will be necessary to ask to sellers to
supply bar codes of included devices .

By using product bar codes , I think , it will be possible to identify
uniquely a large number of devices .

In that way , it will also be possible to define device characteristics
correctly even they lie about their parameters .



Mehmet Erol Sanliturk





> On Tue, Sep 22, 2015 at 5:38 PM, Mehmet Erol Sanliturk <
> m.e.sanliturk at gmail.com> wrote:
>
>>
>>
>> On Tue, Sep 22, 2015 at 2:38 PM, Warner Losh <imp at bsdimp.com> wrote:
>>
>>> I need help with PCI driver marking. Grab my patches and we can talk.
>>>
>>> Basically, it marks all the .ko modules in a similar way that we do
>>> inter-module
>>> dependencies with plug and play info. kldxref then takes this data and
>>> stuffs
>>> it in loader.hints. I also need to write something that will parse this
>>> data and
>>> either generate a devd.conf file (easy to do from kldxref sources) or
>>> queues
>>> the load drive in the kernel (kinda hard). Bonus points for similar code
>>> in
>>> /boot/loader for any storage device that’s found.
>>>
>>> Warner
>>>
>>>
>>> > On Sep 22, 2015, at 1:12 AM, Mehmet Erol Sanliturk <
>>> m.e.sanliturk at gmail.com> wrote:
>>> >
>>> >
>>> >
>>> > On Mon, Sep 21, 2015 at 11:58 PM, Hans Petter Selasky <hp at selasky.org>
>>> wrote:
>>> > On 09/22/15 00:58, Mehmet Erol Sanliturk wrote:
>>> > On Mon, Sep 21, 2015 at 2:16 PM, Maxime Soulé<btik-fbsd at scoubidou.com>
>>> > wrote:
>>> >
>>> > One of my wishes is to move ALL of the device definition information
>>> for (
>>> > NIC , USB , and other devices ) into files where for each device ( a
>>> unique
>>> > file to dedicated itself containing information presently defined as
>>> preset
>>> > in  internal arrays with one additional information ( at least ) which
>>> > driver will be used for the device ) will be prepared  .
>>> >
>>> >
>>> > Hi Mehmet,
>>> >
>>> > Warner Losh is working on this currently, CC'ed. See:
>>> >
>>> > https://reviews.freebsd.org/D3458
>>> >
>>> > Maybe you want to help out testing?
>>> >
>>> > --HPS
>>> >
>>> >
>>> >
>>> > If I can help in any way , I will do it .
>>> >
>>> >
>>> > Mehmet Erol Sanliturk
>>> >
>>> >
>>>
>>>
>>
>>
>> What does "PCI driver marking" mean ?
>>
>>
>> Mehmet Erol Sanliturk
>>
>>
>>
>>
>