In order to get your stuff into shape for official inclusion, or even to make a neat patch, there's administrative work to be done:
Figure out whose pond you've been pissing in. Look at the top of the source files, inside the MAINTAINERS file, and last of all in the CREDITS file. You should coordinate with this person to make sure you're not duplicating effort, or trying something that's already been rejected.
Make sure you put your name and EMail address at the top of any files you create or mangle significantly. This is the first place people will look when they find a bug, or when they want to make a change.
Usually you want a configuration option for your kernel hack. Edit Config.in in the appropriate directory (but under arch/ it's called config.in). The Config Language used is not bash, even though it looks like bash; the safe way is to use only the constructs that you already see in Config.in files (see Documentation/kbuild/config-language.txt). It's good to run "make xconfig" at least once to test (because it's the only one with a static parser).
Variables which can be Y or N use bool followed by a tagline and the config define name (which must start with CONFIG_). The tristate function is the same, but allows the answer M (which defines CONFIG_foo_MODULE in your source, instead of CONFIG_FOO) if CONFIG_MODULES is enabled.
You may well want to make your CONFIG option only visible if CONFIG_EXPERIMENTAL is enabled: this serves as a warning to users. There many other fancy things you can do: see the various Config.in files for ideas.
Edit the Makefile: the CONFIG variables are exported here so you can conditionalize compilation with `ifeq'. If your file exports symbols then add the names to MX_OBJS or OX_OBJS instead of M_OBJS or O_OBJS, so that genksyms will find them.
Document your option in Documentation/Configure.help. Mention incompatibilities and issues here. Definitely end your description with " if in doubt, say N " (or, occasionally, `Y'); this is for people who have no idea what you are talking about.
Put yourself in CREDITS if you've done something noteworthy, usually beyond a single file (your name should be at the top of the source files anyway). MAINTAINERS means you want to be consulted when changes are made to a subsystem, and hear about bugs; it implies a more-than-passing commitment to some part of the code.
Finally, don't forget to read Documentation/SubmittingPatches and possibly Documentation/SubmittingDrivers.