Skip to content
Snippets Groups Projects
  • Martin Kepplinger's avatar
    32eca221
    misc: always assign miscdevice to file->private_data in open() · 32eca221
    Martin Kepplinger authored
    
    As of now, a miscdevice driver has to provide an implementation of
    the open() file operation if it wants to have misc_open() assign a
    pointer to struct miscdevice to file->private_data for other file
    operations to use (given the user calls open()).
    
    This leads to situations where a miscdevice driver that doesn't need
    internal operations during open() has to implement open() that only
    returns immediately, in order to use the data in private_data in other
    fops.
    
    This provides consistent behaviour for miscdevice developers and will
    always provide the pointer in private_data. A driver's open() fop would,
    of course, just overwrite it, when using private_data itself.
    
    Signed-off-by: default avatarMartin Kepplinger <martink@posteo.de>
    Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    32eca221
    History
    misc: always assign miscdevice to file->private_data in open()
    Martin Kepplinger authored
    
    As of now, a miscdevice driver has to provide an implementation of
    the open() file operation if it wants to have misc_open() assign a
    pointer to struct miscdevice to file->private_data for other file
    operations to use (given the user calls open()).
    
    This leads to situations where a miscdevice driver that doesn't need
    internal operations during open() has to implement open() that only
    returns immediately, in order to use the data in private_data in other
    fops.
    
    This provides consistent behaviour for miscdevice developers and will
    always provide the pointer in private_data. A driver's open() fop would,
    of course, just overwrite it, when using private_data itself.
    
    Signed-off-by: default avatarMartin Kepplinger <martink@posteo.de>
    Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>