Re: [PATCH] cyber2000fb: New framebuffer_alloc API and class_dev changes

[Russell King <rmk@arm.linux.org.uk>]

On Tue, Sep 16, 2003 at 04:17:13PM +0200, Kronos wrote:
> Good point. I  was thinking  at files  created by  the driver  itself, I
> forgot about  dev attribute. I  can overwrite  .owner of  dev attribute,
> fbmem can't be built as module. Sounds good?

How about we do the job properly first time around?

- fbmem.c is responsible for managing the lifetime of the fb_info structure,
  and the lifetime of the driver-private data is equal to the lifetime
  of the fb_info structure.

- framebuffer_alloc() creates the fb_info and the driver-private data
  in one object, as per your patch.
- fb_add_class_device creates the class device, as per your patch
  (don't you think it'd be a good idea to return the error to the
  driver if class_device_register() fails?)
- fb_remove_class_device unregisters the class device, as per your
  patch.  This should not cause the fb_info structures to be released.
- framebuffer_free() marks the structure available for freeing.
- at some point later, once all references have done, release_fb_info()
  is called.  This releases the memory space allocated by
  framebuffer_alloc().  This callback should _not_ call the driver
  code.

So far, this fits fairly nicely.  Now on to the driver.

- bus-specific ->probe function
  driver calls framebuffer_alloc(), initialises whatever it needs to.
  Driver then calls register_fb() which in turn eventually calls
  fb_add_class_device().

- bus-specific ->remove function
  driver calls unregister_framebuffer() which eventually calls
  fb_remove_class_device().  driver releases its resources, shuts down
  hardware, and generally cleans up.  The very last step that it does
  is call framebuffer_free().

I believe there was an issue concerning EDID stuff with the above method.
If this requires data from the fb_info or another structure whose lifetime
is directly connected to fb_info, then there isn't a problem.  If it
requires something from the driver module, things get a little more
complicated, and there is a solution to this.  I don't see any instances
of this from looking at your fbdev-class_dev-all patch though.

-- 
Russell King (rmk@arm.linux.org.uk)	http://www.arm.linux.org.uk/personal/
Linux kernel maintainer of:
  2.6 ARM Linux   - http://www.arm.linux.org.uk/
  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
  2.6 Serial core


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf