On Wednesday 03 November 2010 21:25:28 Jung-uk Kim wrote:
> On Wednesday 03 November 2010 01:51 pm, Jung-uk Kim wrote:
> > On Wednesday 03 November 2010 12:47 pm, John Baldwin wrote:
> > > On Wednesday, November 03, 2010 12:25:37 pm Jung-uk Kim wrote:
> > > > On Wednesday 03 November 2010 08:28 am, John Baldwin wrote:
> > > > > On Tuesday, November 02, 2010 6:32:12 pm Jung-uk Kim wrote:
> > > > > > On Tuesday 02 November 2010 05:26 pm, John Baldwin wrote:
> > > > > > > On Tuesday, November 02, 2010 4:50:18 pm Jung-uk Kim

> > > > > > > > > > > 
> > > > > > > > > > > Linux doesn't set the resource source bits up at
> > > > > > > > > > > all when doing _SRS, so I'd rather just do that.
> > > > > > > > > > > I think what I'd prefer is that we not use the
> > > > > > > > > > > prs_template, perhaps just save the type of the
> > > > > > > > > > > resource and build a new resource object from
> > > > > > > > > > > scratch where the resource is zero'd, the
> > > > > > > > > > > appropriate bits are set and then that resource
> > > > > > > > > > > is appended to the buffer being built.
> > > > > > > > > > 
> > > > > > > > > > "Linux doesn't do it" is wrong if I am reading the
> > > > > > > > > > spec. correctly, i.e., _CRS, _PRS and _SRS must
> > > > > > > > > > have the same format and size.
> > > > > > > > > 
> > > > > > > > > Umm, but we aren't setting up the raw bits for _SRS.
> > > > > > > > > We are creating a list of ACPI_RESOURCE objects that
> > > > > > > > > ACPICA then encodes into a buffer to send to _SRS.
> > > > > > > > 
> > > > > > > > Yes, I understand.  However, ACPICA is expecting the
> > > > > > > > same size of buffer *including* the optional parts if I
> > > > > > > > am reading the code right. Besides, I don't think there
> > > > > > > > is any harm in doing the right thing. ;-)
> > > > > > > 
> > > > > > > To be clear, I am suggesting to take an ACPI_RESOURCE
> > > > > > > object, bzero it, then set the type and the IRQ and
> > > > > > > that's it.  Leave the ResourceSource bits as zero.  The
> > > > > > > size will still be set based on the actual type (or if
> > > > > > > needed we can use the cached size from the template copy
> > > > > > > we save from _PRS).  The point would be to start from a
> > > > > > > zero structure instead of from a copy of what we got from
> > > > > > > _PRS.
> > > > > > 
> > > > > > It may work if we don't use l_prs_template.
> > > > > 
> > > > > Well, we still need much of the info from the _PRS resource
> > > > > (the type, etc.), but I think we should not blindly use the
> > > > > template directly when building the buffer for _SRS.
> > > > 
> > > > Actually, I think we should get the information directly from
> > > > _CRS as ACPI spec. is suggesting.
> > > 
> > > I would be fine with that, but that does not work if _CRS doesn't
> > > work (the acpi_pci_link_srs_from_links() case).
> > 
> > For that case, we must use the template, of course.  In fact, my
> > patch is more useful for this particular case. :-)
> > 
> > > Are we allowed to modify the buffer ACPICA gives us from _CRS and
> > > then pass that back to _SRS?
> > 
> > I believe so.  If we go with that route, we don't have to worry
> > about ResourceSource.StringPtr or acpi_AppendBufferResource()
> > copying stale pointers.
> 
> Please see the attached patch.  It seems working fine. :-)
> 
> Note I had to adjust resource length to prevent reading/writing beyond
> buffer size.  It should work okay for acpi_pci_link_srs_from_links()
> case, I believe.  It's a hack anyway. ;-)
> 

Hi,

The acpi_pci_link2.diff patch also works fine. No more "Bug" statements as per 
Lin and Moore's debug patch. The patch was tested separately from the 
"memset()" patch. Both patches work.

--HPS
_______________________________________________
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Reply via email to