Aneesh Kumar K.V wrote:
>
> Hi Dan,
>
> Dan Williams <dan.j.williams@xxxxxxxxx> writes:
> > +int pci_ide_stream_setup(struct pci_dev *pdev, struct pci_ide *ide,
> > + enum pci_ide_flags flags)
> > +{
> > + struct pci_host_bridge *hb = pci_find_host_bridge(pdev->bus);
> > + struct pci_dev *rp = pcie_find_root_port(pdev);
> > + int mem = 0, rc;
> > +
> > + if (ide->stream_id < 0 || ide->stream_id > U8_MAX) {
> > + pci_err(pdev, "Setup fail: Invalid stream id: %d\n", ide->stream_id);
> > + return -ENXIO;
> > + }
> > +
> > + if (test_and_set_bit_lock(ide->stream_id, hb->ide_stream_ids)) {
> > + pci_err(pdev, "Setup fail: Busy stream id: %d\n",
> > + ide->stream_id);
> > + return -EBUSY;
> > + }
> > +
>
> Considering we are using the hostbridge ide_stream_ids bitmap, why is
> the stream_id allocation not generic? ie, any reason why a stream id alloc
> like below will not work?
So recall that this design is meant to support both native and TSM
initiated IDE establishment. While in the native IDE case the kernel
could just pick a free id, in the TSM case the kernel is told the id
that the TSM picked during its IDE establishment flow.
My expectation is that if Linux ever supports native IDE then
establishment that would be modeled as just another TSM that just
happens to be a kernel software backend rather than a TSM provided by
the platform.
For now this function just sanity checks that the TSM is not handing out
duplicate ids, and to record which of a limited pool of ids is in use.
