Atheros 9285 & Atheros AR8131

[John Baldwin]

On 4/7/11 1:25 PM, Nate Lawson wrote:
> On 4/7/2011 6:53 AM, John Baldwin wrote:
>> On 4/6/11 5:51 PM, Nate Lawson wrote:
>>> Wow, awesome work. This is really useful for fixing a common problem.
>>>
>>> Should bus_adjust_resource() be a DEVMETHOD or is this something that
>>> should be done automatically within rman_alloc_resource(), possibly
>>> based on a device flag?
>>
>> Hmm, I had only thought of it as being a wrapper around
>> rman_adjust_resource().  I'm not sure what you mean by adjusting it
>> inside another method?  Note that one of the reasons I have the current
>> method is that different devices may have different restrictions on how
>> resources can grow.  For example, the PCI-PCI memory windows are aligned
>> on 1MB boundaries and are allocated in 1MB chunks while the I/O port
>> windows are aligned and allocated in 4K chunks.
>>
>> I also plan to make use of rman_adjust_resource() for PCI bus
>> renumbering, but in that case resources would only grow at the end, etc.
>>   Given that, I want to keep the logic to determine which kind of
>> adjustment to perform in the relevant driver rather than having rman
>> attempt to use a generic algorithm for expanding a resource and
>> associated rman used for suballocation (if that makes sense).
>
> Yes, that makes sense. It's a question of complexity -- do you push a
> set of rules to rman and have it apply them? Or do you do the adjusting
> in the driver itself, which knows its own restrictions but may end up
> replicating some general purpose code for applying those restrictions?
>
> This seems great for now. I don't have any complaints, just musing about
> the future.

Ahh, ok.  So far my current plans for other places using rmans don't
involve the same set of rules.  However, I would be happy for their to
eventually be a more general version of pcib_grow_window() if we find a
need for it in the future.  I think you could have a helper function at 
that level of granularity perhaps.

-- 
John Baldwin