Date: Sat, 20 May 2000 15:09:35 -0600 From: Warner Losh <imp@village.org> To: Sergey Babkin <babkin@bellatlantic.net> Cc: Alexander Langer <alex@big.endian.de>, doc@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: request for review: bus_alloc_resource(9) Message-ID: <200005202109.PAA54082@billy-club.village.org> In-Reply-To: Your message of "Sat, 20 May 2000 09:31:34 EDT." <392693B6.1FB6C64C@bellatlantic.net> References: <392693B6.1FB6C64C@bellatlantic.net> <3925C91E.9CD7D9EE@bellatlantic.net> <3924931E.A8471B0@bellatlantic.net> <20000518223846.A16098@cichlids.cichlids.com> <200005182332.RAA97696@harmony.village.org> <200005190116.TAA98120@harmony.village.org> <200005200711.BAA44934@billy-club.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <392693B6.1FB6C64C@bellatlantic.net> Sergey Babkin writes: : Warner Losh wrote: : > : > In message <3925C91E.9CD7D9EE@bellatlantic.net> Sergey Babkin writes: : : > : # If a driver returns a success code which is less than zero, it must : > : # not assume that it will be the same driver which is attached to the : > : # device. In particular, it must not assume that any values stored in : > : # the softc structure will be available for its attach method and any : > : # resources allocated during probe must be released and re-allocated : ^^^^^^^^^^^^^^^^^^^^ : > : # if the attach method is called. If a success code of zero is : > : # returned, the driver can assume that it will be the one attached. : > : > Notice it doesn't say that one can hold RESOURCES past the end of : > probe. Only that values set in the softc (which one should try to : : It says, about the case of negative return value. So I guess that : implies that in case if 0 is returned keeping resources is permitted. I guess I'm on the other side of the fence. It doesn't specifically allow it, so it must be forbidden. I've seen too much hardware docs that say one thing for condition A and one might assume that for A' that wouldn't be the case, but in fact the same condition applies for A' as well. : > avoid) aren't guaranteed to be there if the return value is < 0. It : > can only assume that it will be the driver that is attached. This : > comment is poorly worded anyway and should be changed to explicitly : > state that one shouldn't hold resources at the end of the probe : > routine. : : I suppose that "driver can assume that it will be the one attached" : means that the probe routine will not be called again for this : device, thet the resources won't change and that the attach routine : will be called eventually. Provided with all this keeping the resources : seems to be safe. But of course that's only my interpretation. Yes. I don't think it is safe, and I don't that we should document it as safe. : As far as I remember in prenewbus there were no "official resources". : Yes, I agree that keeping anything allocated when returning : from probe is a bad idea. In prenewbus, one couldn't malloc memory in probe that one didn't return right away. : > : Yes, that's what I said in the first quoted paraghaph: if probe : > : returns <0 (priority arbitration between multiple drivers in a class) : > : or >0 (error) then it must free the resources before exit and don't : > : assume that the contents of struct softc will be presevred between : > : probe and attach. But if probe returns 0 it may keep the resources. : > : > I'm still not sure that I agree. Unless I hear from the new-bus : > meister, I won't feel obligated to necessarily keep this condition in : > the NEWCARD code. I don't think I'll need to violate it, but I will : > if I have to because of how things are allocated in most device : > drivers right now. : : It's not like I'm saying that it MUST keep the resources from probe but : I suppose it's allowed to if it really wants. There might be some cases where it makes sense to do it, but those cases are going to be few and far between, imho. : > : Also some resources have problems with freeing them: for example, : > : if a piece of memory was allocated using bus_dmamem_alloc() with : > : lowaddr of BUS_SPACE_MAXADDR_24BIT then bus_dmamem_free() won't : > : really free it but just throw it away (I suppose contigfree() did not : > : exist when it was written). So it's better to keep these resources : > : between probe and attach if probe returns 0. : > : > No. Absolutely not. One should allocate them once only in the attach : > code. The probe code almost never needs to do a DMA to probe the : > device. Probes are supposed to be non-destructive (eg read only on : > the registers) if at all possible. One shouldn't try to allocate it : > there anyway for the same reason you say we should. If you are using : > it to see if the device exists, and it doesn't, then you can't free : > it. Sounds like a bad way to probe the hardware. The probe routine : : As far as I remember in prenewbus there were no "official resources". : Yes, I agree that keeping anything allocated when returning : from probe is a bad idea. In prenewbus, one couldn't malloc memory in probe that one didn't return right away. : > : Yes, that's what I said in the first quoted paraghaph: if probe : > : returns <0 (priority arbitration between multiple drivers in a class) : > : or >0 (error) then it must free the resources before exit and don't : > : assume that the contents of struct softc will be presevred between : > : probe and attach. But if probe returns 0 it may keep the resources. : > : > I'm still not sure that I agree. Unless I hear from the new-bus : > meister, I won't feel obligated to necessarily keep this condition in : > the NEWCARD code. I don't think I'll need to violate it, but I will : > if I have to because of how things are allocated in most device : > drivers right now. : : It's not like I'm saying that it MUST keep the resources from probe but : I suppose it's allowed to if it really wants. There might be some cases where it makes sense to do it, but those cases are going to be few and far between, imho. : What about the case when device exists but is broken/misconfigured ? : Suppose, someone got the port address right but the DMA channel wrong. : Well, of course, this more intrusive part of probe may as well be moved to : the attach routine. Two cases here. Either you read the DMA channel from the card and ignore what the user has said (which the aha driver does). Or you can't read it from the card, in which case you lose if the user lies to the driver. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200005202109.PAA54082>